共用方式為

威脅分析建議

  • 發行項

適用於此 Power Platform Well-Architected 安全檢查表建議：

SE：02 通過使用威脅建模來整合安全設計，以防止破壞安全性的實施。

在工作負載的設計階段，用於識別威脅、攻擊、漏洞和對策的全面分析至關重要。 威脅建模是一項工程實踐，包括定義安全要求、識別和緩解威脅以及驗證這些緩解措施。 您可以在應用程式開發或生產的任何階段使用此技術，但它在新功能的設計階段最有效。

本指南介紹了有關執行威脅建模的建議，以便您可以快速識別安全漏洞並設計安全防禦。

定義

詞彙 定義
軟體開發生命週期 (SDLC) 開發軟體系統的多階段、系統化過程。
STRIDE 用於對威脅類型進行分類的 A Microsoft 定義分類法。
威脅模型 識別應用程式和系統中潛在安全漏洞、降低風險和驗證安全控制的過程。

關鍵設計原則

威脅建模是組織應將其整合到其 SDLC 中的關鍵流程。 威脅建模不僅僅是開發人員的任務。 這是以下人員之間的共同責任：

  • 工作負載團隊，負責系統的技術面。
  • 業務利益相關者，了解業務成果並對安全性有既得利益。

在關鍵工作負載的業務需求方面，組織領導階層和技術團隊之間經常存在脫節。 這種脫節可能會導致不必要的結果，特別是對於安全投資。

進行威脅建模練習時要考慮業務和技術要求。 工作負載團隊和業務利害關係人必須就工作負載的特定安全需求達成一致，以便他們能夠在對策上進行充分的投資。

安全需求做為威脅建模整個過程的指南。 為了使其成為有效的練習，工作負載團隊應該具有安全思維並接受威脅建模工具的培訓。

了解練習的範圍

清楚地了解範圍對於有效的威脅建模至關重要。 它有助於將精力和資源集中在最關鍵的領域。 此策略涉及定義系統的邊界、盤點需要保護的資產以及了解安全控制所需的投資水準。

收集有關每個元件的資訊

工作負載架構圖是收集資訊的起點，因為它提供了系統的視覺化表示。 此圖突顯了系統的技術尺寸。 例如，它顯示使用者流程、資料如何在工作負載的不同部分中移動、資料敏感等級和資訊類型以及身分存取路徑。

這種詳細的分析通常可以深入了解設計中的潛在漏洞。 了解每個元件的功能及其依賴關係非常重要。

評估潛在威脅

從外到內的角度分析每個元件。 例如，攻擊者如何輕鬆存取敏感資料？ 如果攻擊者獲得了對環境的存取權限，他們是否可以橫向移動並可能存取甚至操縱其他資源？ 這些問題可協助您了解攻擊者如何利用工作負載資產。

使用行業方法對威脅進行分類

對威脅 進行分類的一種方法是 STRIDE， Microsoft 安全開發生命週期使用它。 將威脅分類可協助您了解每種威脅的性質並使用適當的安全控制措施。

緩解威脅

記錄所有已識別的威脅。 對於每種威脅，定義安全控制以及在這些控制失敗時對攻擊的回應。 定義一個流程和時間表，最大限度地減少工作負載中任何已識別漏洞的暴露，從而確保這些漏洞得到解決。

使用假設突破方法。 它可以幫助識別設計中所需的控制，以在主要安全控制失敗時減輕風險。 評估主要控制失效的可能性有多大。 如果失敗了，潛在的組織風險有多大？ 另外，補償控制的有效性如何？ 根據評估，應用深度防禦措施來解決安全控制的潛在故障。

以下是範例：

提出此問題 要確定控制...
連線是否透過 Microsoft Entra ID 進行身分驗證，並使用安全團隊核准的現代安全協定：

- 使用者和應用程式之間？

- 應用程式元件和服務之間？

- 在使用者和 Copilot 之間？		 防止對應用程式元件和資料進行未經授權的存取。
您是否僅限制需要在應用程式中寫入或修改資料的帳戶的存取權限？ 防止未經授權的資料篡改或更改。
是否透過 Azure Monitor 或類似解決方案記錄應用程式活動並將其饋送到安全資訊和事件管理 (SIEM) 系統？ 快速偵測和調查攻擊。
關鍵資料是否受到安全團隊核准的加密保護？ 防止未經授權複製靜態資料。
入站和出站網路流量是否隔離到安全團隊核准的網域？ 防止未經授權的資料複製。
是否透過在環境中使用 IP 防火牆來保護應用程式免受來自外部/公共位置 (例如咖啡店) 的存取？ 防止未經授權的公共場所的存取。
應用程式是否儲存登入憑證或金鑰以存取其他應用程式、資料庫或服務？ 確定攻擊是否可以使用您的應用程式來攻擊其他系統。
應用程式控制是否允許您滿足監管要求？ 保護使用者的私人資料並避免合規罰款。

追蹤威脅建模結果

我們強烈建議您使用威脅建模工具。 工具可以自動執行識別威脅的過程，並產生所有已識別威脅的綜合報告。 請務必將結果傳達給所有有興趣的團隊。

將結果做為工作負載團隊待辦事項的一部分進行追蹤，以便及時問責。 將任務分配給負責減輕威脅建模所識別的特定風險的個人。

當您為解決方案新增功能時，請更新威脅模型並將其整合到程式碼管理流程中。 如果您發現安全問題，請確保有一個根據嚴重性對問題進行分類的流程。 該過程應可協助您確定何時以及如何修復問題 (例如，在下一個發佈週期或更快的發佈中)。

定期審查業務關鍵型工作負載需求

定期與執行發起人會面以確定要求。 這些審查提供了調整期望並確保為該計劃分配營運資源的機會。

Power Platform 簡易化

Power Platform 是以安全設計的文化和方法建立。 通過 Microsoft行業領先的 安全開發生命週期 （SDL）和 威脅建模 實踐，文化和方法都得到了不斷加強。

威脅建模檢閱程序可確保在設計階段發現威脅、降低威脅並進行驗證，以確保威脅已降低。

威脅建模也會將所有已透過連續定期查看的服務變更進行為活動。 依靠 STRIDE 模型 ，可協助解決最常見的不安全設計問題。

Microsoft的 SDL 相當於 OWASP 軟體保障成熟度模型 （SAMM）。 兩者都是建立在安全設計對 Web 應用程式安全性有整數的前提上。

有關詳細資訊，請參閱 Power Platform 中的 OWASP 十大風險：緩解措施。

範例

此範例建立在用於建立安全基線的建議中建立的資訊技術 (IT) 環境的基礎上。 這種方法提供了對不同 IT 場景中威脅情勢的廣泛了解。

開發生命週期角色。 開發生命週期涉及許多角色，包括開發人員、測試人員、終端使用者和管理員。 所有這些都可能受到損害，並因故意建立的漏洞或威脅而使您的環境面臨風險。

潛在的攻擊者。 攻擊者認為有多種工具可以隨時輕鬆使用來探索您的漏洞並發動攻擊。

安全控制。 作為威脅分析的一部分，識別 Microsoft用於保護解決方案的 Azure、Azure 和安全 Power Platform 服務以及這些解決方案的有效性。

日誌收集。 來自 Power Platform 工作負載中包含的資源和其他元件 (例如 Azure 資源和內部部署元件) 的日誌可能會發送到 Application Insights Purview Microsoft ，以便您可以瞭解所開發解決方案的行為並嘗試捕獲初始漏洞。

安全資訊事件管理 (SIEM) 解決方案。 Microsoft 甚至可以在解決方案的早期階段添加 Sentinel，以便您可以構建一些分析查詢來緩解威脅和漏洞，從而在生產中預測您的安全環境。

安全性檢查清單

請參閱完整的建議集。

安全檢查表