威脅分析的建議
適用於此 Azure 架構完善的架構安全性檢查清單建議：
| SE：02 | 使用強化、大部分自動化且可稽核的軟體供應鏈，維護安全的開發生命週期。 使用威脅模型化來納入安全設計，以防止安全性失敗的實作。 |
|---|
相關指南： 保護開發生命周期的建議
識別威脅、攻擊、弱點和計數器措施的完整分析，在工作負載的設計階段非常重要。 威脅模型化 是一項工程練習，包括定義安全性需求、識別和減輕威脅，以及驗證這些風險降低措施。 您可以在應用程式開發或生產的任何階段使用這項技術，但在新功能的設計階段中效果最有效。
本指南說明執行威脅模型化的建議，讓您可以快速識別安全性缺口，並設計安全性防禦。
定義
| 術語 | 定義 |
|---|---|
| 軟體開發生命週期 （SDLC） | 開發軟體系統的多階段系統程式。 |
| STRIDE | 分類威脅類型的Microsoft定義分類法。 |
| 威脅分析模型 | 識別應用程式和系統中潛在安全性弱點、降低風險及驗證安全性控制的程式。 |
關鍵設計策略
威脅模型化是組織應該整合到其 SDLC 的關鍵程式。 威脅模型化不只是開發人員的工作。 這是兩者之間的共同責任：
- 負責系統技術層面的工作負載小組。
- 業務項目關係人，他們了解業務成果，並且對安全性具有既得利益。
組織領導階層和技術小組之間通常會中斷與重要工作負載商務需求之間的連線。 這種中斷可能會導致不必要的結果，特別是安全性投資。
當工作負載小組執行威脅模型化練習時，應該同時考慮商務和技術需求。 工作負載小組和商務專案關係人必須就工作負載的安全性特定需求達成一致，才能對對策進行足夠的投資。
安全性需求可作為威脅模型化整個程式的指南。 若要讓它成為有效的練習，工作負載小組應該具備安全性思維，並在威脅模型化工具中訓練。
了解練習的範圍
清楚瞭解範圍對於有效威脅模型化至關重要。 它有助於將精力和資源集中在最重要的領域。 此策略涉及定義系統的界限、清查需要保護的資產，以及瞭解安全性控制所需的投資層級。
收集每個元件的相關信息
工作負載架構圖表是收集資訊的起點，因為它提供系統的視覺表示法。 此圖表會醒目提示系統的技術維度。 例如，它會顯示使用者流程、數據透過網路移動的方式、數據敏感度層級和資訊類型，以及身分識別存取路徑。
此詳細分析通常可提供設計中潛在弱點的深入解析。 請務必瞭解每個元件及其相依性的功能。
評估潛在威脅
從外部觀點分析每個元件。 例如，攻擊者如何輕鬆存取敏感數據？ 如果攻擊者取得環境的存取權，他們是否可以橫向移動，甚至可能存取或甚至操作其他資源？ 這些問題可協助您了解攻擊者如何利用工作負載資產。
使用產業方法分類威脅
分類威脅的其中一種方法是 STRIDE，Microsoft安全性開發生命週期會使用。 分類威脅可協助您瞭解每個威脅的性質，並使用適當的安全性控制。
減輕威脅
記錄所有已識別的威脅。 針對每個威脅，如果這些控件失敗，請定義安全性控件和攻擊的回應。 定義程式與時間軸，以將工作負載中任何已識別弱點的暴露程度降到最低，讓這些弱點無法解除回應。
使用假設缺口方法。 它可協助識別設計中所需的控件，以在主要安全性控件失敗時降低風險。 評估主要控制項失敗的可能性。 如果失敗，潛在組織風險的程度為何？ 此外，補償控件的有效性為何？ 根據評估，套用深度防禦措施來解決安全性控制的潛在失敗。
以下是範例：
| 新增此問題 | 若要判斷控制項... |
|---|---|
| 透過 Microsoft Entra ID、傳輸層安全性 （TLS） 與相互驗證的連線，或安全性小組核准的另一種新式安全性通訊協定進行驗證： - 在使用者與應用程式之間？ - 在應用程式元件和服務之間？ |
防止未經授權的應用程式元件和數據存取。 |
| 您是否限制只有需要寫入或修改應用程式中數據的帳戶存取權？ | 防止未經授權的資料篡改或改變。 |
| 應用程式活動是否透過 Azure 監視器或類似的解決方案記錄並饋送至安全性資訊和事件管理 （SIEM） 系統？ | 快速偵測並調查攻擊。 |
| 重要數據是否受到安全性小組核准的加密保護？ | 防止未經授權複製待用資料。 |
| 輸入和輸出網路流量是否透過TLS加密？ | 防止未經授權複製傳輸中的資料。 |
| 應用程式是否透過 Azure DDoS 保護等服務來保護不受分散式阻斷服務 （DDoS） 攻擊？ | 偵測設計來多載應用程式的攻擊，使其無法使用。 |
| 應用程式存放區登入認證或金鑰是否可存取其他應用程式、資料庫或服務？ | 識別攻擊是否可以使用您的應用程式來攻擊其他系統。 |
| 應用程式控制是否可讓您滿足法規需求？ | 保護使用者的私人數據，並避免合規性罰款。 |
追蹤威脅模型化結果
強烈建議您使用 威脅模型化工具。 工具可將識別威脅的程式自動化，併產生所有已識別威脅的完整報告。 請務必將結果傳達給所有感興趣的小組。
追蹤結果作為工作負載小組待辦專案一部分，以及時追究責任。 將工作指派給負責減輕威脅模型識別的特定風險的人員。
當您將新功能新增至解決方案時，請更新威脅模型，並將其整合到程式碼管理程式碼管理程式中。 如果您發現安全性問題，請確定有一個程式可根據嚴重性將問題分級。 此程式應該可協助您判斷問題補救時機和方式（例如，在下一個發行週期或更快速的版本中）。
定期檢閱業務關鍵性工作負載需求
定期與執行贊助者會面，以定義需求。 這些檢閱提供一個機會來配合預期，並確保作業資源配置與計劃。
Azure 便利化
Microsoft安全性開發生命週期提供威脅模型化工具，以協助威脅模型化程式。 這項工具可供免費使用。 如需詳細資訊，請參閱 威脅模型化頁面。
範例
此範例是以安全性基準 （SE：01） 中建立的資訊技術 （IT） 環境為基礎。 此方法可讓您廣泛瞭解不同IT案例的威脅環境。
開發生命週期角色。 開發生命週期涉及許多角色，包括開發人員、測試人員、最終使用者和系統管理員。 所有這些可能都會遭到入侵，並透過故意建立的弱點或威脅，讓您的環境面臨風險。
潛在的攻擊者。 攻擊者會考慮隨時輕鬆使用的各種工具，以探索您的弱點並開始攻擊。
安全性控制。 在威脅分析中，識別要用來保護您的解決方案的 Azure 安全性服務，以及這些解決方案的有效性。
記錄收集。 來自 Azure 資源和某些內部部署元件的記錄可能會傳送至 Azure Log Analytics，因此您可能會瞭解所開發解決方案的行為，並嘗試擷取初始弱點。
安全性資訊事件管理 （SIEM） 解決方案。 Microsoft Sentinel 即使在解決方案的初期階段也可以新增，因此您可以建置一些分析查詢來減輕威脅和弱點，並預期您在生產環境中時的安全性環境。
適用於雲端的 Microsoft Defender 可能會提出一些安全性建議，以改善安全性狀態。
相關連結
社群連結
Open Web Application Security Project (OWASP) 已記錄應用程式的威脅模型化方法。
安全性檢查清單
請參閱一組完整的建議。