適用於此 Power Platform Well-Architected 的安全性檢查清單建議：
| SE:09 | 建立全面的測試方案，結合預防安全問題、驗證威脅防禦實施和測試威脅檢測機制的方法。 |
|---|
嚴格的測試是良好安全設計的基礎。 測試是一種戰術形式的驗證，以確保控制措施能如預期運作。 測試也是偵測系統漏洞的主動方法。
透過節奏和多角度驗證來建立測試的嚴格性。 您應該包括測試平台和基礎結構的由內而外的觀點以及像外部攻擊者一樣測試系統的由外而內的評估。
本指南提供了測試工作負載安全狀況的建議。 實施這些測試方法可以提高工作負載對攻擊的抵抗力，並維護資源的機密性、完整性和可用性。
定義
| 詞彙 | 定義 |
|---|---|
| 應用程式安全測試 (AST) | 一種 Microsoft 安全開發生命週期 (SDL) 技術，使用白盒和黑盒測試方法來檢查程式碼中的安全漏洞。 |
| 黑盒測試 | 一種測試方法，無需了解系統內部即可驗證外部可見的應用程式行為。 |
| 藍隊 | 在戰爭遊戲演習中防禦紅隊攻擊的團隊。 |
| 滲透測試 | 一種使用道德駭客技術來驗證系統安全防禦的測試方法。 |
| 紅隊 | 在戰爭遊戲演習中扮演對手角色並試圖入侵系統的團隊。 |
| 安全性開發週期 (SDL) | Microsoft 提供的一組支援安全保證和合規性要求的做法。 |
| 軟體開發生命週期 (SDLC) | 開發軟體系統的多階段、系統化過程。 |
| 白盒測試 | 一種測試方法，其中程式碼結構為人所知。 |
關鍵設計原則
測試是一種不可協商的策略，尤其是對於安全性而言。 它允許您在安全問題被利用之前主動發現和解決安全問題，並驗證您實施的安全控制是否按設計執行。
測試範圍必須包括應用程式、基礎結構以及自動化和手動流程。
注意
本指南區分了測試和事件響應。 儘管測試是一種理想情況下可以在生產之前修復問題的偵測機制，但不應將其與做為事件回應的一部分進行的補救或調查混為一談。 安全事件回應建議中描述了從安全事件中復原的方面。
參與測試計劃。 工作負載團隊可能不會設計測試案例。 此任務通常集中在企業內部或由外部安全專家完成。 工作負載團隊應參與該設計過程，以確保安全保證與應用程式的功能整合。
像攻擊者一樣思考。 假設系統已受到攻擊來設計測試案例。 這樣，您就可以發現潛在的漏洞並相應地確定測試的優先順序。
以結構化方式和可重複的過程來執行測試。 圍繞節奏、測試類型、驅動因素和預期結果建立嚴格的測試。
使用適合工作的正確工具。 使用配置為處理工作負載的工具。 如果您沒有工具，請購買工具。 不要組建它。 安全工具是高度專業化的，建立自己的工具可能會帶來風險。 利用中央 SecOps 團隊提供的專業知識和工具，如果工作負載團隊不具備該專業知識，則可以利用外部手段。
設定單獨的環境。 測試可分為破壞性測試和非破壞性測試。 無損偵測不是侵入性的。 它們表明存在問題，但不會改變功能來修復問題。 破壞性測試是侵入性的，可能會透過從資料庫中刪除資料來損壞功能。
生產環境中的測試可以為您提供最好的訊息，但會造成最大的干擾。 您傾向於僅在生產環境中進行無損測試。 非生產環境中的測試通常破壞性較小，但可能無法以對安全性很重要的方式準確地表示生產環境的配置。
您可以使用環境複製功能建立生產環境的獨立複製。 如果您設定了部署管線，您也可以將解決方案部署到專用測試環境。
始終評估測試結果。 如果測試結果不用於確定操作的優先順序並在上游進行改進，那麼測試就是一種浪費。 記錄您發現的安全準則，包括最佳做法。 擷取結果和補救計劃的文檔可以讓團隊了解攻擊者可能嘗試破壞安全的各種方式。 為開發人員、管理員和測試人員定期進行安全訓練。
當您設計測試計劃時，請考慮以下問題：
- 您預計測試執行的頻率如何？
- 您應該執行哪些不同的測試類型？
您預計測試執行的頻率是多少？
定期測試工作負載，以確保變更不會帶來安全風險，並且不會出現任何回歸。 團隊也必須準備好回應可能隨時進行的組織安全驗證。 您也可以執行一些測試來回應安全事件。 以下部分提供了有關測試頻率的建議。
常規檢查
例行測試定期進行，做為標準作業程序的一部分並滿足合規性要求。 各種測試可能以不同的節奏執行，但關鍵是它們是定期按計劃進行的。
您應該將這些測試整合到您的 SDLC 中，因為它們在每個階段提供深度防禦。 使測試套件多樣化，以驗證身分、資料儲存和傳輸以及通訊管道的保證。 在生命週期的不同點進行相同的測試，以確保不存在任何回歸。 例行測試有助於建立初始基準。 但這只是一個起點。 當您在生命週期的同一點發現新問題時，您可以新增新的測試案例。 測試也會隨著重複而改善。
在每個階段，這些測試應驗證新增或刪除的程式碼或已變更的配置設置，以便偵測這些變更的安全性影響。 您應該透過自動化來提高測試的效率，並與同儕審查相平衡。
考慮將安全測試做為自動化管道或計劃測試執行的一部分來執行。 越早發現安全性問題，就越容易找到導致這些問題的程式碼或設定變更。
不要僅依賴自動化測試。 使用手動測試來偵測只有人類專業知識才能發現的漏洞。 手動測試非常適合探索性使用案例和發現未知風險。
臨時測試
臨時測試提供安全防禦的時間點驗證。 可能影響當時工作負載的安全警報會觸發這些測試。 如果警報升級為緊急情況，組織授權可能需要暫停和測試的心態來驗證防禦策略的有效性。
臨時測試的好處是為真實事件做好準備。 這些測試可以強制執行使用者驗收測試 (UAT)。
安全團隊可能會審核所有工作負載並根據需要執行這些測試。 做為工作負載擁有者，您需要促進安全團隊並與安全團隊合作。 與安全團隊協商足夠的準備時間，以便您做好準備。 承認並向您的團隊和利害關係人傳達這些中斷是必要的。
在其他情況下，您可能需要執行測試並報告系統針對潛在威脅的安全狀態。
權衡：由於即興測試是破壞性事件，因此預計會重新確定任務的優先順序，這可能會延遲其他計劃的工作。
風險：存在未知的風險。 如果沒有既定的流程或工具，臨時測試可能只是一次性的工作。 但主要風險是業務節奏的潛在中斷。 您需要相對於收益來評估這些風險。
安全事件測試
有一些測試可以從源頭偵測安全事件的原因。 必須解決這些安全漏洞，以確保事件不再重演。
隨著時間的推移，事件還可以透過發現現有差距來改進測試案例。 團隊應吸取從事件中學到的教訓並定期進行改進。
有哪些不同類型的測試？
測試可以按技術和測試方法進行分類。 將這些類別和這些類別中的方法結合起來以獲得完整的覆蓋範圍。
透過新增多個測試和測試類型，您可以發現：
- 安全控制或補償控制方面的差距。
- 設定錯誤。
- 可觀測性和偵測方法的差距。
良好的威脅建模練習可以指出關鍵領域，以確保測試覆蓋範圍和頻率。 有關威脅建模的建議，請參閱保護開發生命周期的建議。
這些部分中所述的大多數測試都可以做為常規測試執行。 然而，在某些情況下，可重複性可能會產生成本並導致中斷。 仔細考慮這些取捨。
驗證技術堆疊的測試
以下是測試類型及其重點領域的一些範例。 此列表並不詳盡。 測試整個堆疊，包括應用程式堆疊、前端、後端、API、資料庫和任何外部整合。
- 數據安全：測試數據加密和訪問控制的有效性，以確保數據得到適當的保護，防止未經授權的訪問和篡改。
- 網路和連接：測試防火牆，確保它們僅允許預期、允許和安全的流量進入工作負載。
- 應用程式：通過應用程式安全測試 (AST) 技術測試原始程式碼，以確保遵循安全編碼實踐並捕獲記憶體損壞和許可權問題等運行時錯誤。
- 標識：評估角色分配和條件檢查是否按預期工作。
測試方法
關於測試方法有很多觀點。 我們建議透過模擬現實世界的攻擊來進行威脅追蹤的測試。 他們可以識別潛在的威脅參與者、他們的技術以及對工作負載構成威脅的漏洞。 讓攻擊盡可能真實。 使用您在威脅建模期間識別的所有潛在威脅向量。
以下是透過真實攻擊進行測試的一些優點：
- 當您將這些攻擊做為常規測試的一部分時，您可以使用由外向內的視角來檢查工作負載並確保防禦能夠抵禦攻擊。
- 根據他們學到的經驗教訓，團隊提升了他們的知識和技能水平。 團隊提高了態勢感知能力，並可以自我評估他們應對事件的準備。
模擬測試的一些例子包括黑盒和白盒測試、滲透測試和戰爭遊戲練習。
黑盒和白盒測試
這些測試類型提供了兩種不同的視角。 在黑盒測試中，系統的內部結構是看不見的。 在白盒測試中，測試人員對應用程式有很好的了解，甚至可以存取程式碼、日誌、資源拓撲和配置來進行實驗。
透過滲透測試模擬攻擊的測試
不屬於組織 IT 或應用程式團隊的安全專家進行滲透測試。 他們以惡意行為者範圍攻擊面的方式看待系統。 他們的目標是透過收集資訊、分析漏洞並報告結果來發現安全漏洞。
從業人員可能需要存取整個組織中的敏感資料。 遵循參與規則以確保存取權限不會被濫用。 請參閱相關信息 中列出的資源。
透過戰爭遊戲練習模擬攻擊的測試
在這種模擬攻擊方法中，有兩個團隊：
- 紅隊是試圖模擬真實世界攻擊的對手。 如果他們成功了，您會發現安全設計中的漏洞並評估其漏洞的爆炸半徑遏制。
- 藍隊是防禦攻擊的工作負載隊。 他們測試自己偵測、回應和修復攻擊的能力。 他們驗證為保護工作負載資源而實施的防禦措施。
如果做為例行測試進行，戰爭遊戲可以提供持續的可見性並確保您的防禦按設計工作。 戰爭遊戲練習可能會在您的工作負載中進行跨級別的測試。
模擬真實攻擊場景的流行選擇是用於攻擊模擬訓練的 Microsoft Defender Office 365。
有關詳細資訊，請參閱攻擊模擬訓練的深入分析和報告。
有關紅隊和藍隊設置的資訊，請參閱 Microsoft Cloud 紅隊。
Power Platform 簡易化
Microsoft Power Platform Microsoft Sentinel 解決方案允許客戶偵測各種可疑活動，例如：
- 從未經授權的地理位置執行 Power Apps
- Power Apps 銷毀可疑資料
- 大量刪除 Power Apps
- 透過 Power Apps 發動的網路釣魚攻擊
- 離職員工進行的 Power Automate 流程活動
- Microsoft Power Platform 連接器已新增至環境中
- 更新或移除 Microsoft Power Platform 資料原則
有關詳細資訊，請參閱 Microsoft Sentinel 解決方案的 Microsoft Power Platform 概述。
有關產品文件，請參閱 Microsoft Sentinel 中的搜尋功能。
Microsoft Defender for Cloud 提供針對各個技術領域的漏洞掃描。 有關詳細資訊，請參閱使用 Microsoft Defender 漏洞管理啟用漏洞掃描。
DevSecOps 的實踐將安全測試整合為持續改進思維的一部分。 戰爭遊戲是一種常見做法，已融入 Microsoft 的業務節奏。 有關詳細資訊，請參閱 DevOps 中的安全性 (DevSecOps)。
Azure DevOps 支援可做為持續整合/持續部署 (CI/CD) 管道的一部分進行自動化的第三方工具。 有關詳細資訊，請參閱使用 Azure 和 GitHub 啟用 DevSecOps。
相關資訊
您可以在 Microsoft 服務信任入口網站上找到最新的滲透測試和安全性評估。
Microsoft 對 Microsoft 雲端服務進行了廣泛的測試。 此測試包括滲透測試，結果發佈在您組織的服務信任入口網站上。 您的組織可以對 Microsoft Power Platform 和 Microsoft Dynamics 365 服務執行您自己的滲透測試。 所有滲透測試都必須遵循 Microsoft 雲端滲透測試參與規則。 請務必記住，在許多情況下，Microsoft Cloud 使用共用基礎架構來託管您的資產和屬於其他客戶的資產。 您必須限制對您的資產的所有滲透測試，並避免對周圍的其他客戶造成意想不到的後果。
遵循參與規則以確保存取權限不會被濫用。 深入瞭解如何規劃和執行模擬攻擊：
您可以在 Azure 中模擬拒絕服務 (DoS) 攻擊。 請務必遵循 Azure DDoS 防護模擬測試中列出的策略。
安全性檢查清單
請參閱完整的建議集。