威脅模型：安全檢查的邊界與決策

🌏 Read this article in English

本文主張：對於高價值資產、架構快速變動或信任邊界改變的系統，當安全檢查僅聚焦於「完成了多少個項目」而忽略資產定義、信任邊界與攻擊路徑的實際邏輯時，它便容易退化為形式上的合規勾選。威脅模型的核心價值，不在於產出一份完美的文件，而在於透過結構化的思考，在持續維護與落實的前提下，有助於讓資源配置與風險責任轉化為可驗證的決策依據。

成熟的檢查清單（Checklist）在低複雜度與低風險系統中確實具有不可替代的優勢：成本低廉、執行標準化且容易稽核。然而，當系統面對動態變化的架構或高價值資產時，若通用或過時清單的系統假設未重新驗證，單純依賴清單可能造成「控制措施與實際威脅脫節」的邊界落差。這篇文章將探討如何在清單的確定性與威脅模型的靈活性之間，做出基於情境的工程取捨。

從合規檢查到風險決策

安全工程中存在一個值得留意的風險：將「符合規範」等同於「系統安全」。本文所討論的清單，主要是指針對特定標準設計的靜態合規清單與通用安全基準。這種通用清單模式在面對外部審計時非常有效，因為它提供了一種可量化的標準證明方式。然而，當團隊沿用依既有架構設計的通用或過時清單，卻未重新驗證資產、信任邊界、架構變更與技術債時，清單可能保留已不成立的假設：預期的信任邊界不會被突破、資產價值不會隨時間改變，或技術債不會引入新的攻擊面。

本文把威脅模型（Threat Modeling）視為一種結構化的風險決策機制。其目標是在特定前提與限制下，為團隊提供系統安全風險的決策參考。這句話的關鍵在於「前提」與「決策」。在進行威脅建模時，目標通常不是尋找絕對安全的狀態——這在工程上難以成立——而是在具體情境中劃定可驗證的風險邊界。

這種邊界不是憑空設定的，而是基於三個決策面向：

1. 資產價值：哪些數據或服務一旦受損，會導致業務中斷或信任崩塌？
2. 信任邊界：系統內部的哪些元件被預設為「可信」，而這些預設是否依然成立？
3. 攻擊路徑：潛在的攻擊者如何利用跨越信任邊界的資料流、授權缺口或控制措施弱點，達成對資產的破壞？

威脅模型並非為了尋找零風險狀態，而是透過定義資產、邊界與路徑，將抽象的「安全」轉化為可比較、可追蹤的決策輸入。當這三個面向被明確定義後，它們會提供後續威脅識別、排序與控制映射的輸入；只有在緩解措施已映射至特定攻擊路徑，且實作後完成驗證時，安全檢查才可描述為針對該路徑的控制措施驗證。這就是為什麼在高價值資產、架構快速變動或信任邊界改變的系統中，若通用清單的系統假設未被重新驗證，缺乏威脅模型的靜態合規檢查容易退化為形式上的合規：因為它缺少了將「控制措施」與「實際風險」連結的因果結構。

清單的確定性與威脅模型的靈活性

在討論威脅模型的價值時，一個值得重視的反方論點是：成熟的檢查清單（如業界常見的合規基準）具有極高的成本效益，且能提供一致的稽核標準。對於許多低複雜度、低風險系統而言，嚴格執行這些清單不僅足夠，甚至是更優的選擇。

本文採用的工程判準是：當資產敏感度與暴露面已被驗證為低、信任邊界維持穩定、基線控制足以處理已識別風險，且風險承擔方已做出明確的風險接受決策時，可以選擇由清單主導。在工程實踐中，資源永遠是有限的。如果一個內部工具系統僅處理非敏感數據、運行在隔離的網路環境中，而且上述前提經過驗證，投入大量人力進行深度的威脅建模，其邊際效益可能遞減。此時，在該風險接受範圍內，清單提供的「確定性」可以優先於威脅模型帶來的「靈活性」。

然而，關鍵在於如何定義「低複雜度」與「低風險」。一種可能的演進情境是：許多系統在設計初期被歸類為內部工具，但隨著業務發展，它們可能逐漸接觸到核心數據或成為關鍵基礎設施的一部分。如果安全策略完全依賴於初始的清單勾選，而沒有定期的威脅模型更新機制，且清單的系統假設未隨變化重新驗證，系統可能產生「假性安全」的感受：清單項目看似已完成，實際上卻仍可能暴露在未預期的攻擊路徑下。

這裡存在一個明確的取捨（Tradeoff）：

• 選擇清單主導：優勢在於執行成本低、標準統一、易於規模化；劣勢在於當清單更新速度跟不上架構變化時，其覆蓋能力可能受限，且容易忽略特定情境下的獨特風險。
• 選擇威脅模型主導：優勢在於能針對特定資產與架構進行深度風險評估，靈活應對複雜情境；劣勢在於執行成本高、依賴專業人員的判斷力，且結果較難直接用於跨團隊的標準化稽核。

在選擇策略時，判準並非衡量「哪種方法更先進」，而是評估系統當前的風險暴露面與維護成本之間的平衡。當系統的信任邊界開始跨越不同的組織單元或雲端環境時，由於存取路徑與異質權限模型的組合變化超出了通用靜態清單的預設假設，單純依賴清單項目的覆蓋度就會逐漸不足以對應獨特的攻擊路徑，此時威脅模型的靈活性就成為了必要的補償機制。

動態邊界與持續驗證

威脅模型並非一勞永逸的文件，它是一種動態的風險管理工具。若團隊完成建模後便將文件封存於文件庫中，直到下一次審計時才重新翻閱，這種做法會削弱威脅模型的價值，因為它忽略了系統環境的動態變化。

以下是一個代表性的假設情境：某公司的內部員工查詢系統（Intranet App）最初設計為僅在企業內網運行，原模型將企業內網與已驗證員工歸入同一個假定信任區域；這是需要持續驗證與重估的設計假設，而非由身分驗證直接推導出的可信狀態。若當時資產敏感度與暴露面確實偏低、邊界穩定、基線控制充分，且風險承擔方已明確接受剩餘風險，團隊可以選擇由標準安全清單主導。隨著業務轉型，該系統需要開放部分 API 給外部合作夥伴以支援供應鏈管理。這一變動改變了系統的信任模型：原本假定的單一信任區域，轉變為需要重新驗證外部身分、授權與資料流的混合環境。

如果此時沒有重新進行威脅建模，原有的安全控制措施很可能無法覆蓋新的攻擊面。例如，原本依賴內網 IP 白名單的存取控制已不足以處理外部存取（儘管它仍可作為分層網路控制的一部分），需重估外部身分、服務授權與網路控制的合理性；API 閘道器（API Gateway）的速率限制與身分驗證機制可能未被納入初始的設計考量中。這種信任邊界的跨越，使得清單的「確定性」不足以應對新環境下的「靈活性」需求。

技術架構的演進與新依賴項的引入，可能改變系統元件、資料流與信任邊界；外部威脅情勢的改變則不必然改變信任邊界，而是觸發對既有模型中適用威脅、攻擊路徑可行性與排序的重估。若要發揮威脅模型的效益，通常需要維持其持續性（Continuity），將其納入軟體開發生命週期（SDLC）的運作節奏，而非視為一次性專案。當信任邊界發生微小變化時——例如新增一個第三方 API 依賴——團隊可以先局部更新受影響的資料流圖（DFD），定位改變的元件、邊界與資料流，再對影響範圍執行威脅識別與排序、緩解措施審查及驗證；在部署前，先定義控制措施的可觀察驗收結果與失敗停止條件。控制措施部署後，仍需驗證該驗收結果與相關服務健康狀態；若驗證失敗，則依預先定義的復原路徑處置，並維持既有安全邊界，而非在未確認的狀態下保留新暴露面。當團隊落實這種局部的、針對性的建模與處置時，在持續維護與嚴格驗證的條件下，有機會在維持清單基線合規的同時，將資源集中於高風險的信任邊界變革，並提供可驗證模型與實作一致性的觀察條件。

DFD 與工具選擇

若要將威脅模型落實到工程工作流中，本文選擇資料流圖（DFD）作為起點。透過 DFD，開發者可以視覺化系統元件、數據流及其交互作用。根據 OWASP 的建議，DFD 可以使用簡單的符號來建立，並依據系統複雜度決定需要多少張圖：例如先有一張高層級的全域概觀圖，再針對子系統繪製細節圖。

在選擇工具時，可以根據團隊規模與需求進行分層：

• 輕量級/手動：使用 draw.io 或白板進行初步建模，適合快速迭代的設計階段。
• 專用模型工具：例如 OWASP Threat Dragon 提供視覺化介面，適合需要結構化支援的團隊。
• Threat Modeling as Code：對於偏好程式化控制的工程團隊，推薦使用如 pytm 等支援「以程式碼為中心」的建模方式。

這種 as-code 模式允許開發者在腳本中定義資產（Assets）、邊界（Boundaries）與資料流（Data Flows）。例如，透過 Python 腳本將系統元件與數據流向程式化，可以為模型與實作提供共同版控、差異審查與自動檢查的條件，但不保證模型會自動反映程式碼或架構變更。

威脅模型的 as-code 實踐，其核心價值不在於自動化本身，而在於提供降低模型與實作脫節機率的機制。as-code 提供了共同版本控制、差異審查與自動檢查的基礎；只有當團隊持續維護責任歸屬、審查與管線檢查後，這些機制才可能協助偵測或降低漂移。若團隊持續執行這類驗證機制，有機會補充清單在動態環境中覆蓋度的不足。清單提供的是「基線」，而威脅模型提供的是「上下文」。當清單基線與威脅模型情境結合時，在維護責任與審查條件完備的前提下，團隊能保有可稽核的合規標準，同時為高風險區塊提供可被驗證的資源配置依據。

決策矩陣：何時使用何種方法？

為了提供跨情境的工程參考，下表整理了一個基於系統複雜度與風險等級的示例起點：

這個矩陣並非絕對的規則，而是提供一個思考框架。表中所示的年度回顧、季度審計、半年度回顧、持續監控與定期驗證，僅為團隊自訂的示例門檻，並非 OWASP 建議；表內另列的資產、信任邊界、架構、外部依賴、授權模型或重大發布等變更，則是事件觸發條件。團隊在應用時，可以考慮以資產或信任邊界變更作為主要的觸發判準，並根據自身的業務目標、技術債狀況與資源限制動態調整。關鍵在於保持透明度：明確記錄決策背後的假設與風險接受標準，以便未來回顧與修正。

結語：在確定性與靈活性之間尋找平衡

安全工程的本質，是在不確定的威脅環境中尋找相對的穩定。清單提供了這種穩定的基礎，而威脅模型則提供了應對變化的能力。兩者並非互斥，而是相輔相成。

面對新系統時，檢視信任邊界與資產價值是釐清風險決策優先順序的可能起點。當團隊在實踐中落實這些分析流程時，在持續維護前提下，有助於將安全檢查從單純的項目核對，轉化為可追蹤的風險決策過程。資源配置的品質與安全防護的效果，取決於這些機制是否被持續執行與驗證，而非檢查項目的完成數量；對系統風險邊界的清晰度，往往需要透過長期且重複的觀測與維護來達成。

在確定性與靈活性之間尋找平衡，往往取決於團隊當下的資源配置與風險承受度。這是一個值得持續觀察的判斷準則。

Sources

• Threat Modeling – OWASP Cheat Sheet Series — 提供威脅模型定義與 DFD 建模建議