時事：把「可能已被入侵」放進架構設計
查核日期：2026-10-18。攻擊與營運中斷值得列入日常設計、演練與預算；這不代表可以接受資料外洩，也不能只憑幾則新聞判定整個產業的事故發生率。本章用近期事件與歷史案例，練習回答：一個帳號、一個 Agent 或一家供應商失守，損害能否被限制？
日本「一千多萬筆會員」：近期有兩起相符案例
Section titled “日本「一千多萬筆會員」：近期有兩起相符案例”| 案例與公告日期 | 官方已確認的事實 | 公告中的不確定性與界線 |
|---|---|---|
| 燒肉 King（焼肉きんぐ），2026-10-05 | 10 月 2 日確認不正存取、3 日確認外洩；10,788,963 筆會員資料受影響，包括會員編號、姓名、電郵、電話 | 詳細入侵原因仍在調查。公告稱登入密碼等未外洩，且公司不持有信用卡等付款資訊 |
| 日本 Burger King，2026-10-15 | 10 月 2–7 日遭不正存取，13 日確認外洩；約 1,118 萬筆，包含會員 ID、聯絡與部分個人屬性資料 | 詳細原因仍在調查；公司不持有信用卡號，當時未確認登入密碼外洩 |
來源：物語公司 10 月 5 日公告、日本 Burger King 10 月 15 日公告 PDF。數字的單位是公告中的「筆／件」，不能直接當成不重複的自然人人數。
兩者都符合「一千多萬筆」的描述，因此先並列，不擅自認定原先提到的是哪一家。也不能由「會員系統外洩」推定就是 SQL injection、物件授權漏洞或 AI 攻擊；要等調查證據。
**帶回架構的問題：**一個前端登入流程，為什麼需要存取哪些個資？後端每一次讀取是否限制對象、欄位、筆數與用途？即使使用合法帳號，異常大量讀取能否被發現並中止？這些是我們的設計提問，不是上述公司的已確認缺陷。
平台與醫療：資料外洩之外，還有服務停止
Section titled “平台與醫療：資料外洩之外，還有服務停止”以下為 2024 年事件的歷史對照，並非本週新發生的攻擊。
| 案例 | 已公開的影響 | 課堂要追問的架構問題 |
|---|---|---|
| KADOKAWA／Niconico：2024-06-08 發生障礙，08-05 公告調查結果 | 勒索軟體等攻擊造成服務障礙；確認 254,241 人的個資外洩，涉及員工、交易對象與學校關係人等，不能稱為全數 Niconico 會員。公告推測與員工帳號遭竊有關，當時具體取得途徑仍不明 | 員工身分、平台工作負載、學校資料與備份管理，是否應有不同的信任邊界？ |
| Synnovis 與英國 NHS：2024-06-03 遭攻擊；NHS 於 2025-11-10 更新說明 | 病理檢驗供應商遭勒索攻擊，超過 11,000 次門診及非緊急處置預約延後；服務至 2024 年 12 月完全恢復。資料碎片化使外洩範圍調查歷時逾一年 | 關鍵供應商停擺時，哪些服務仍能安全持續？資料目錄是否能協助辨識受影響的資料與責任人？ |
來源：KADOKAWA 2024-08-05 公告 PDF、NHS England：Synnovis 事件更新。供應商遇襲造成醫院受影響，不等於每一家醫院都被直接入侵。
七項架構重構：把防護變成可驗證的行為
Section titled “七項架構重構：把防護變成可驗證的行為”以下是本課從案例提出的設計建議，不是任何一家受害公司的鑑識結論。
| 設計問題 | 可落實的控制 | 學員要提出的證據 |
|---|---|---|
| 進入內網後能做多少事？ | 驗證人與工作負載身分；按租戶、資源與動作授權；分離執行權與政策管理權 | 撤銷身分或關係後，後續請求確實被擋；另一租戶不受影響 |
| 憑證外流能用多久？ | 任務所需的最小權限、短效憑證、撤銷與輪替；限制哪些工作負載能再次發證 | 新連線失敗；另外測試既有連線、快取與長任務的撤權行為 |
| 一次合法查詢能帶走多少？ | 必要欄位、資料保留期限、敏感欄位遮罩、匯出額度、異常讀取告警與出口控制 | 能指出資料流向、最大可讀範圍，以及停止大量匯出的條件 |
| Agent 的建議何時變成行動？ | 模型只提出請求，由工具閘道執行授權、參數驗證與額度檢查；把外部文件當資料 | 外部文件要求「匯出所有會員／提高額度」時，伺服器仍拒絕未授權動作 |
| 一個元件失守會波及哪裡？ | 隔離租戶、資料庫角色、管理介面與供應商連線；備份權限獨立於一般應用 | 證明低權限工作負載不能管理備份或修改授權政策 |
| 誰能證明發生過什麼？ | 關聯任務 ID、授權結果、憑證租約、匯出量與付款事件；另存受保護稽核紀錄 | 查得到操作鏈；日誌沒有密碼、卡號或不必要個資，應用無法自行抹除關鍵證據 |
| 主要系統不可用時怎麼辦？ | 定義降級、停止與轉人工條件；異地／離線或不可變備份；在乾淨環境演練恢復 | 實測恢復時間、資料損失窗口、資料完整性與恢復後對帳 |
NIST 的零信任原則不因「在內網」或「公司設備」就給予隱含信任；Tailscale 連線仍需要應用授權。CISA 建議隔離、離線加密備份與定期恢復測試。這些控制共同降低風險，不能保證不會再有事故。NIST SP 800-207、CISA #StopRansomware Guide。
四個工具能幫什麼，還缺什麼？
Section titled “四個工具能幫什麼，還缺什麼？”- **OpenFGA：**表達與檢查資源授權。模型及服務本身也要保護，所有讀寫路徑都要執行檢查。
- **OpenBao：**管理憑證生命週期。若攻擊者仍控制發證身分，短效到期後可能再取新憑證；還要隔離工作負載並撤銷發證權。
- **OpenMetadata：**整理欄位、用途、責任人與資料關係。目錄的完整性取決於維護，不能單靠它阻止資料外傳。
- **OpenTelemetry：**關聯執行證據。採樣與遺失會使 trace 不完整；它不是不可竄改稽核庫、入侵阻擋系統或財務帳本。
因此，本課的四個工具只涵蓋部分控制。端點防護、修補、備份、災難復原、身分管理與應變責任仍要設計。尤其「OpenBao 重啟後恢復」與「遭入侵後在乾淨環境恢復」是不同驗收；目前沙盒只驗證前者。
15 分鐘桌上演練：一個 Agent 身分已外洩
Section titled “15 分鐘桌上演練：一個 Agent 身分已外洩”**虛構情境：**09:00 發現某採購 Agent 異常讀取資料；其付款請求狀態不明。09:05 供應商的檢驗或交付服務也不可用。你不能假設換掉一把密碼就已清除入侵。
每組先決定，再展開提示。醫療情境的持續營運決定由合格業務與臨床責任人制定，課堂不模擬醫療處置。
第一輪：立即關閉全部服務，還是只封鎖來源 IP？
兩者都不應是唯一選項。先辨識受影響身分、工作負載與資料範圍；隔離該工作負載、停止新任務與發證、撤銷相關授權並保留證據。僅封鎖 IP 未必擋得住被竊身分。全站停止是否必要，要依擴散風險與關鍵服務影響決定，寫明決策者。
第二輪：付款逾時，Agent 是否可以換一個編號再送一次？
先查原請求狀態並對帳，保留原冪等鍵。網路逾時不代表付款失敗；換新鍵可能重複扣款。凍結工具、撤銷憑證與已完成交易的處理，是不同步驟。Mercury 案例的實際可用控制仍以其官方介面為準。
第三輪：有昨晚備份，現在就能恢復營運嗎？
先確認備份可讀、完整且來源可信，排除持續入侵，使用乾淨環境與新憑證。恢復後核對資料、付款與待處理任務。請寫出 RTO（目標恢復時間）與 RPO（可接受資料損失時間窗口），再用演練結果驗證；「有備份」不等於達標。
前 5 分鐘決定隔離與服務邊界，中間 5 分鐘處理付款、證據與恢復，最後 5 分鐘說明誰負責及如何驗收。用自己的產品畫圖，標出「可繼續、暫停、人工處理」三種狀態。
對應既有沙盒的安全練習
Section titled “對應既有沙盒的安全練習”- 執行自己的訂單查詢，再撤銷查看權；確認後續任務被拒絕且不發證。
- 取得短效憑證，執行「跨學員 schema」測試；確認資料庫拒絕。
- 撤銷租約，確認新連線失敗；不要把結果外推為所有既有連線都被中止。
- 注入教學錯誤，查看 trace 與撤銷步驟；重送同一模擬付款編號，確認不重複扣款。
這些練習只操作自己的合成資料。供應商中斷、備份還原、不可變稽核與遭入侵後重建仍是桌上設計題，沒有宣稱已在沙盒實作。
商業模式也要回答「失敗時誰付代價」
Section titled “商業模式也要回答「失敗時誰付代價」”採購方可把資料範圍、復原演練、事件證據與退出移轉能力列為驗收項目。供應方則要把隔離、備份、保留紀錄、人工例外與恢復成本放進報價；按任務或成果計費時，必須定義重試、重複付款、服務中斷及補償。
可討論的產品方向包括：受控 Agent 工具閘道、具備預算與對帳的代辦服務、可驗證恢復的託管方案。這些是待驗證的商業假設，不能以「裝了四個工具」承諾零事故。
交付：架構與韌性工作紙。每組加答：若明天真的出事，哪一項證據能支持你今天向客戶做的承諾？