威脅場景一：傳輸竊聽

攻擊方式

攻擊者在 SDK 和 collector 之間的網路路徑上攔截未加密的 HTTP 流量。同網段的 ARP spoofing、WiFi sniffing、或中間人（MITM）proxy。

暴露的資料

事件的完整 JSON payload — 包括 redaction 後殘留的資訊（使用者行為、系統狀態、error message）。API key 或 basic auth credential 如果在 HTTP header 中明文傳送，也會被攔截。

防護

使用 HTTPS 加密傳輸（Transport 安全）。所有 SDK 到 collector 的通訊走 TLS — 自簽憑證在自用場景足夠，公開部署用 Let’s Encrypt。

威脅場景二：儲存入侵

攻擊方式

攻擊者取得 collector server 的存取權限（SSH 入侵、容器逃逸、雲端 IAM 權限提升），直接讀取儲存的事件檔案。

暴露的資料

所有歷史事件 — 包含 redaction 處理後的事件。如果 redaction 不完整（遺漏了某些敏感欄位），歷史事件中可能包含 secret。

防護

最小化儲存：只保留必要期限的資料，過期自動刪除（GDPR 最小化原則）。攻擊者能取得的資料量與保留期間成正比。

檔案系統加密：LUKS（Linux）或 FileVault（macOS）對整個磁碟加密。Server 關機後磁碟資料無法被讀取。

access log 監控：記錄所有對事件儲存的存取操作（Collector Access Control）。異常存取（非工作時間、非預期的 IP）觸發告警。

威脅場景三：Endpoint 濫用

攻擊方式

攻擊者取得 SDK 的 API key（從 client 端的程式碼或設定檔中提取），大量寫入垃圾事件或惡意 payload。

影響

資料汙染：合法事件和垃圾事件混在一起，分析結果不可靠。

資源耗盡：大量寫入消耗 collector 的儲存和處理能力。

注入攻擊：如果 collector 的查詢介面沒有做好輸入驗證，惡意 payload 中的特殊字元可能觸發 injection。

防護

Rate limit：每個 API key 的寫入速率限制。正常的 SDK 行為有可預測的寫入頻率（每分鐘 N 個事件），超出正常範圍的寫入被拒絕。

Schema validation：collector 只接受符合定義 schema 的事件。格式異常的 payload 在寫入前被丟棄。

API key 輪替：如果 API key 被洩漏，輪替 key 讓舊 key 失效。SDK 端更新新 key 後恢復正常。

威脅場景四：內部越權存取

攻擊方式

有 collector 讀取權限的人（開發者、維運人員）存取超出自己職責範圍的事件資料。例如開發者查看行為分析資料（只應該看 debug 資料），或前端開發者查看 server-side 的 error 事件。

防護

角色分離：不同用途的資料用不同的存取權限（Collector Access Control）。Debug 資料和行為分析資料分開授權。

去識別化：即使有存取權限，看到的也是去識別化後的資料（去識別化策略）。IP 截斷、user agent 簡化、stack trace 路徑清理 — 降低資料的個人可識別性。

access log 審計：所有讀取操作記錄在 access log 中，定期 review。

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Transport 層保護 → Transport 安全
• Collector 端保護 → Collector Access Control 實作
• 去識別化技術 → 去識別化策略
• Client-side SDK 認證的多層緩解策略 → Client-side SDK 認證

寫資安 mitigation 必須對稱：每段「防什麼」要配「不防什麼」、不能單邊寫。 讀者沒拿到「不防 Y」、會用 universal validity 詮釋 mitigation——預設「防 X」涵蓋整個 threat space、實際只是 X 的 subset。Threat model 的 boundary 是 mitigation 論述的一部分、不是補充說明、不能省。

差別在於讀者實作時的覆蓋判斷——前者讀完跳過 endpoint 驗證、後者讀完知道要補 Y。

情境

資安寫作有兩個誘因會讓 threat model boundary 被省略：

1. 正向陳述優先規範（AGENTS.md 原則二）會誤把「不防 Y」歸類為負面句、批量改寫時刪掉、跟 #94 正向改寫保留對照論據 同病
2. 章節篇幅控制會把 threat boundary 當成「進階補充」往後丟、留主章節「乾淨主旨」

兩者都會產出 universal-flavored 的 mitigation 句子。讀者讀「使用 X 即可保護 Y」時、Y 會被腦補成「所有 Y 相關攻擊」、X 跟 Y 之間的 scope 配對被 silent 地放大成 universal。

實際資安章節（backend/07-security-data-protection/）會出現的形態：

1判讀訊號：登入驗證節奏失衡
2前置控制面：authentication / incident-severity

這個寫法把 threat 抽象成「節奏失衡」、把 mitigation 抽象成「authentication」——對熟手 OK、對學習者讀完會以為「用 authentication 就擋節奏失衡」、實作時不會去問 authentication 的局部 scope（防 credential 弱、不防 session 重放、不防 supply chain 信任傳導）。

理想做法

每個 mitigation 句子強制走「對稱論述」結構：

對稱論述模板

1[Mitigation X] 防 [in-scope threat A]、
2不防 [out-of-scope threat B]（[B 的補強路由 / 外部引用]）。

三個欄位都要填：

• In-scope threat：X 真正擋的攻擊類型（具體、不抽象）
• Out-of-scope threat：讀者最容易誤以為 X 也擋的攻擊（讀者直覺會 extrapolate 的方向）
• 補強路由：Y 該由什麼補（其他章節 / 外部標準 / 已知條件）、不能只丟「自己想辦法」

例（HTTPS 章節）：

1HTTPS 防中間人「讀取」傳輸內容（passive eavesdrop）、
2不防 endpoint 「身分驗證」失效（compromised CA / cert pinning bypass）、
3endpoint 信任靠 cert pinning + CT log monitoring 補（見 7.5）。

例（per-IP rate limit）：

1per-IP rate limit 擋「單來源」連續嘗試（brute force from single host）、
2不擋「分散來源」嘗試（botnet / credential stuffing）、
3分散攻擊靠 reputation-based filtering + adaptive challenge 補（見 7.3）。

對稱不是「補負面」、是「scope 顯式化」

跟 #94 正向改寫保留對照論據 同骨：「不防 Y」不是負向陳述、是 mitigation 的 scope qualifier。把 contrast 寫進句子、不是違反「正向陳述優先」、是讓主句的 X claim 站得住。

主句仍然承載 X 的 mitigation claim（正向）、不防 Y 是 scope qualifier、不是論述主體——結構符合「正向陳述優先」、語意保留 boundary。

Threat model 的層級對應

對稱論述要在三個層級保持一致：

三個層級任一缺、reader 都可能 silent universal 詮釋。實作 audit 時三層分別檢查、不是只看句子。

沒這樣做的麻煩

Reader 用 universal 詮釋、實作覆蓋永遠是 worst case

人類讀句子時、預設的 scope 是 universal、不是 minimal——這是語言學跟認知偏差的結合。「使用 X 防 Y」讀者預設 X 防整個 Y space。要讓讀者預設 minimal、必須顯式給 boundary——這跟物件的 type narrowing 同骨：沒寫 narrowing predicate、預設 widest type。

跟 #100 false sense of security 主軸對應——universal 詮釋是 false sense 的主要產地。

Reviewer 跟原作者對 mitigation 的 scope 認知會 silent drift

含糊 threat model 的 mitigation 段、不同 reviewer 讀會 reconstruct 出不同的 in-scope 集合。原作者腦中是 [A, B]、reviewer 讀成 [A, B, C, D]、實作者實作為 [A, B, C, D, E]——三個人對同一段話的覆蓋認知都不同、且都覺得自己對。對稱寫法讓 scope 變成 fact、不是 reconstruction。

多 mitigation 疊加時的 gap 永遠看不到

多個 mitigation 各自寫 in-scope、不寫 out-of-scope、疊加時的 gap（哪個 threat 沒人擋）就看不到。對稱寫法讓每個 mitigation 都有顯式 boundary、疊加 audit 時可以做集合運算（聯集 in-scope 應涵蓋 threat space、否則有 gap）。沒對稱寫法、audit 工具只能憑感覺、無法量化覆蓋。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：所有資安 mitigation 論述（auth / crypto / 傳輸 / 防護 / 標準引用）；高風險領域的「方法論述」（concurrency primitive 的 ordering 保證、distributed consensus 的 failure mode）
• 不適用：純歷史 / 概念介紹文章（不教 mitigation、不需 threat model）、研究探討（讀者預期自行 explore boundary）
• 邊界：「對稱論述」≠「列出所有不防的 threat」——只列讀者直覺會 extrapolate 的方向、不是 enumerate 整個 threat space。判別準則：「讀者讀完 X 防 A 之後、心裡最可能誤以為 X 也防的 B 是什麼？」——B 就是該寫的 out-of-scope
• 過度對稱反例：每個 mitigation 列十個 out-of-scope threat、文體變 audit-driven（為了 audit checklist 而寫）、不是 reader-driven（為讓讀者建立可驗證 mental model 而寫）；單一 mitigation 的 out-of-scope 通常 1-2 個直覺 extrapolation 方向就夠、列 10 個 = 把 audit 模板當成寫作目標、退化成 #67 寫作便利度反向

本卡是資安 audit 第一個維度（threat model）、配 #102 mitigation 對位、#103 context-dependence、#104 citation 形成完整的 audit dimension 集合。