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