適用於此 Azure Well-Architected Framework 安全性檢查清單建議：
| 東南：11 | 建立一套結合預防安全問題、驗證威脅防護實作及測試威脅偵測機制的測試方案。 |
|---|
嚴格的測試是良好安全設計的基礎。 測試也是偵測系統漏洞的主動方法。
透過多角度的節奏和驗證，建立測試的嚴謹性。 包含由內而外的觀點來測試平台與基礎設施，以及由外而內的評估，像外部攻擊者一樣測試系統。
本文的關鍵策略建立在 OE：09 《測試架構策略》中所述的基礎測試實務之上。 先看那篇文章。 本指南提供測試工作負載安全狀態的建議。 實作這些測試方法，以提高工作負載對攻擊的抵抗力，並維護資源的機密性、完整性和可用性。
術語
| 術語 | 定義 |
|---|---|
| 應用程式安全性測試 （AST） | 一種 Microsoft 安全性開發生命週期 （SDL） 技術，使用白盒和黑盒測試方法來檢查程式碼中的安全性弱點。 |
| 黑盒測試 | 一種測試方法，可在不了解系統內部的情況下驗證外部可見的應用程式行為。 |
| 白盒測試 | 一種測試方法，其中從業人員知道代碼的結構。 |
| 紅隊 | 一個扮演對手角色並試圖在戰爭演習中破解系統的團隊。 |
| 藍隊 | 一支在兵棋演習中防禦紅隊攻擊的隊伍。 |
| 滲透測試 | 一種使用道德駭客技術來驗證系統安全防禦的測試方法。 |
| 安全性開發生命週期 （SDL） | Microsoft 提供的一組做法，支援安全性保證和合規性需求。 |
與資安專家合作設計測試
參與測試計劃。 通常，組織會集中管理這項任務。 確保你的團隊參與設計流程，確保安全保障與應用程式功能相符。
建立假設違規的心態。 設計測試案例時，假設系統正遭受攻擊，攻擊者仍在環境中運作。 模擬你的測試，以反映真實的攻擊情境，例如在被入侵的應用程式虛擬機中驗證橫向移動的遏制。 這樣你就能發現潛在的漏洞，並相應地優先排序測試。
分享架構圖、威脅模型及其他相關文件，以有效測試工作負載。
根據威脅建模與關鍵流程優先排序測試
威脅建模是識別工作負載中潛在威脅與漏洞的關鍵實務。 利用你的威脅模型中的嚴重性評分來優先排序並擴大你的測試範圍。 針對您最關鍵流程的最高嚴重性威脅，理應獲得最廣泛的保護。
涵蓋工作負載的整體攻擊面。 評估身份、應用程式代碼、基礎設施控制、第三方元件、函式庫與服務，以及自動化且人工化的流程，如核准工作流程與存取審查。
先從身分與存取控制著手，因為一旦身分遭到入侵，就能繞過大多數後續防禦機制。 接著驗證網路邊界，最後是應用層防禦。
優先處理認證、敏感資料或金融交易的流程。 針對每個關鍵流程，識別威脅模型中嚴重性評分最高的威脅。 建立以風險為導向的測試案例，將每個威脅對應到旨在緩解其的控制措施。
良好的威脅建模練習會指出測試覆蓋率與頻率的關鍵領域。 如需威脅模型化的建議，請參閱 保護開發生命週期的建議。
風險：陳舊的威脅模型可能導致測試不一致。 定期更新您的威脅模型，以反映工作量與威脅環境的變化。
善用第三方專業
內部團隊可能有盲點。 外部專家和群眾協作研究人員會以攻擊者的角度審視你的工作負載。 請聘請專業專家從對手角度測試你的工作量，並提供最新攻擊技術與趨勢的見解。
避免對您的工作負載授予過於寬鬆的存取權限。 只給予外部測試人員其特定參與所需的存取權限。 黑盒滲透測試不需要程式碼或內部存取，而白盒審查則需要原始碼、設計文件或日誌。
在啟動程式前，評估你的團隊是否有能力進行外部報告的分流處理。 接著，建立漏洞懸賞計畫或社群回報安全問題的機制。 對每個已回報的發現進行分類研判，將已確認的漏洞回饋到威脅模型中，並新增測試案例以偵測任何回歸問題。
測試合規控制並產生可審計的證據
合規不是一次性的審查。 將每一項監管控制項視為可測試的要求，以便在稽核人員查核時，您始終備有最新的證據。
找出你的工作量必須符合的法規。 將每個監管控制對應到特定的測試案例。 安排測試以定期節奏執行，且在每次上線前進行。 將測試結果存放在可稽核的地點，方便隨時產生證據。
取捨： 針對法規控管的測試可能會拖慢作業流程。 例如，部署前的測試會增加管線延遲。 此外，執行這些作業的成本也會增加。 優先進行審計與風險影響最高的控制測試。
保護測試資產
測試資產本身就是一個攻擊面。 保護其機密性、完整性與可用性，避免測試暴露敏感資訊或開啟新的攻擊途徑。
- 使用未經消毒或合成的資料，且不含個人識別資訊（PII）或生產資料。
- 只保留測試資料到需要的時間，並安全刪除。
- 確認跨區域測試環境中是否執行跨境資料駐留規則。
- 產生專用的測試憑證、API 金鑰和憑證。 將它們存放在獨立的金鑰庫實例中，並有自己的存取政策。
- 建立隔離的測試環境，鏡像生產環境的安全控制，如網路安全群組（NSG）、基於角色的存取控制（RBAC）政策、防火牆及資料遺失防護（DLP）規則。 應用與生產相同的分段指引。 欲了解更多資訊，請參閱 分群策略建議。
定期對測試資產進行漏洞掃描
以與生產資源相同的節奏掃描測試資產的漏洞，包括測試程式碼、基礎設施即程式碼（IaC）、容器與虛擬機映像檔、資料庫及管線。 使用能整合於開發與部署工作流程的工具來自動化這些檢查。
為工作負載建立持續測試週期
將安全測試視為一項持續的活動，隨著威脅、程式碼與配置演變，保持工作負載的安全狀態與時俱進。 按時程執行測試，避免變更帶來安全風險或回溯。 要準備好應對組織隨時可能發生的安全驗證，以及由安全事件觸發的測試。 下列章節說明規劃時應考量的週期。
例行測試
例行測試為您的工作負載的安全狀態設定基準。 以固定頻率進行，作為標準作業程序的一部分，並符合合規要求。 你可能會以不同的節奏進行各種測試，但關鍵是要定期且有固定時間進行。
使測試套件多樣化，以驗證身分、資料儲存和傳輸以及通訊管道的保證。 當你在生命週期的同一階段發現新問題時，加入新的測試案例。
不要只依賴自動化測試。 利用手動測試找出只有人類專業才能發現的漏洞，並進行未知風險的探索性工作。
即興測試
即興測試提供安全防禦的即時驗證。 當時可能影響工作負載的安全警示會觸發這些測試。 組織授權可能需要暫停和測試的心態，以驗證警報升級為緊急情況時防禦策略的有效性。
臨時測試的好處是為真實事件做好準備。 這些測試可以是強制執行使用者驗收測試 （UAT） 的功能。
安全性小組可能會稽核所有工作負載，並視需要執行這些測試。 身為工作負載擁有者，您需要協助並與安全團隊合作。 與安全團隊協商足夠的前置時間，以便做好準備。 承認並與您的團隊和利害關係人溝通這些中斷是必要的。
在其他情況下，您可能需要執行測試，並針對潛在威脅報告系統的安全性狀態。
安全事件測試
使用能從安全事件源頭偵測原因的測試。 解決這些安全漏洞，防止事件再次發生。
事故也會透過揭露現有的差距，逐漸改善測試案例。 團隊應應用從事件中學到的經驗教訓，並定期納入改進措施。
備註
本指南區分了測試和事件回應。 雖然測試是一種偵測機制，理想上是在生產環境前解決問題，但不要將其與事件回應中進行的修復或調查混淆。 從安全事件復原的層面在 事件回應建議中說明。
驗證整個攻擊面的安全控管
運用多種測試方法，以獲得完整覆蓋，並發現安全控制的漏洞、錯誤配置，以及可觀察性與偵測的弱點。 本節所述的大多數測試都可以作為例行測試執行。 然而，重複性可能會產生成本並造成干擾。 請仔細考慮這些取捨。
測試加密控制。 加密失敗是無聲的。 資料看似受保護，直到資料外洩揭露真相。
- 確認加密是被強制執行的，而不只是設定而已。
- 每次金鑰輪換、憑證更新及基礎設施變更後，請重新測試。
測試網路控制。 網路邊界是實施網路分段的地方。
- 在任何網路拓撲變更後都要測試它們。
- 確認預設拒絕規則是否成立，且允許的流量路徑是否符合你的架構意圖。
測試應用程式代碼。 應用層防禦是攻擊者取得資料前的最後一道邊界。
- 驗證部署中的應用程式是否能抵抗常見攻擊模式，而非僅在建置時掃描原始碼。
- 對原始碼執行應用程式安全測試（AST）技術，以確認安全的編碼實務，並捕捉執行時錯誤，如記憶體損毀與權限問題。 詳情請參閱 社群連結。
模擬基於身份的攻擊並驗證偵測
基於身份的攻擊是最常見的初始攻擊向量。 模擬這些攻擊，以驗證你的身份控制系統是否有效，且你的監控能捕捉事件。
存取控制是第一道防線。 每次角色或政策變更後，並依自動化排程進行測試。 模擬常見攻擊模式，確認你的控制系統執行最低權限並抵抗繞過嘗試。
設計測試時請考慮以下攻擊模式：
- 繞過授權
- 代幣盜竊與重播
- 跨帳戶或服務的橫向調動
- 權限升級
驗證每個控制項的兩側：
- 正面案例：授權使用者成功。
- 負面案例：未經授權的嘗試會被封鎖並記錄。
測試威脅偵測與警示
沒有觸發警報的偵測功能幾乎沒有價值。 在每次安全控制驗證中測試監控與警示功能，並驗證偵測攻擊的機制是否如預期運作。
執行攻擊的端對端模擬，然後確認偵測流程的每個階段：
- 驗證安全事件如登入嘗試、權限變更及令牌操作是否被詳細記錄。
- 確認您的安全資訊與事件管理（SIEM）平台或安全作業儀表板是否與相關事件相關。
- 建立警示服務等級協議（SLA），並測試警示是否可執行並在該時間內出現。
- 確認非管理員帳號無法竄改或刪除日誌。
- 確認每次模擬攻擊的偵測機制都會觸發。 例如，如果你模擬了有效流量模式的分散式阻斷服務（DDoS）攻擊，請確認速率限制能偵測並減輕該攻擊。
對於已成熟的工作負載，應將治理防護機制作為例行測試的一部分加以驗證。 刻意引入不安全的設定，並驗證管線是否能偵測並回應。 確認 Azure 原則 或 landing zone 限制會強制落實預期的保護措施。 通常由平台或資安團隊執行這些測試，而非工作負載團隊。
透過對抗者導向測試強化防禦
使用可透過模擬真實世界攻擊來支援威脅獵捕的測試。 這些測試能識別潛在的威脅行為者、其技術及對工作負載構成威脅的漏洞利用。 使攻擊盡可能地逼真。 使用您在威脅建模期間識別的所有潛在威脅向量。
以下是透過真實世界攻擊進行測試的一些優點：
- 當您將這些攻擊作為例行測試的一部分時，您會使用由外而內的視角來檢查工作負載，並確保防禦能夠承受攻擊。
- 根據所學課程，團隊會提升他們的知識與技能水平。 該團隊提高了態勢感知能力，並可以自我評估他們應對事件的準備情況。
模擬測試的一些例子包括黑盒和白盒測試、滲透測試和兵棋演習。
黑盒和白盒測試
這些測試類型提供了兩種不同的觀點。 在黑盒測試中，系統的內部結構不可見。 在白盒測試中，測試人員對應用程式有很好的了解，甚至可以存取程式碼、日誌、資源拓撲和配置來進行實驗。
透過滲透測試模擬攻擊的測試
不屬於組織 IT 或應用程式團隊的安全專家會進行滲透測試或 滲透測試。 他們以惡意行為者分析攻擊面的方式來查看系統。 他們的目標是透過收集資訊、分析漏洞和報告結果來發現安全漏洞。
從業人員可能需要存取整個組織中的敏感資料。 請遵循參與規則，以確保存取權不會被濫用。 請參閱 相關連結中列出的資源。
通過兵棋演習模擬攻擊的測試
在這種模擬攻擊方法論中，有兩隊參與：
紅隊扮演對手，嘗試模擬真實世界的攻擊。 如果他們成功了，您會發現安全設計中的差距，並評估其安全漏洞的爆炸半徑遏制。
藍隊是防禦攻擊的工作負載團隊。 他們測試其偵測、回應和修復攻擊的能力。 它們驗證保護工作負載資源的防禦措施。
如果你定期進行這些測試，戰爭演習能持續提供可見性，並確保你的防禦系統如設計般運作。 模擬戰爭遊戲演習可能會在您的工作負載中進行跨層級測試。
模擬真實攻擊案例的熱門選擇是適用於 Office 365 的 Microsoft Defender 攻擊 模擬訓練。
如需詳細資訊，請參閱 攻擊模擬訓練的深入解析和報告。
如需紅隊和藍隊設定的相關資訊，請參閱 Microsoft 雲端紅隊。
Azure 支援服務
Microsoft Sentinel 是結合安全性資訊事件管理 （SIEM） 和安全性協調流程自動回應 （SOAR） 功能的原生控制項。 它分析來自各種連接來源的事件和日誌。 根據數據源及其警示，Microsoft Sentinel 會建立事件並執行威脅分析以及早偵測。 透過智慧分析和查詢，您可以主動搜尋安全性問題。 如果發生事件，您可以自動化工作流程。 此外，透過使用工作簿範本，你也能透過視覺化快速獲得洞見。
如需產品文件，請參閱 Microsoft Sentinel 中的偵查功能。
適用於雲端的 Microsoft Defender 提供各種技術領域的弱點掃描。 如需詳細資訊，請參閱 使用 Microsoft Defender 弱點管理啟用弱點掃描 - 適用於雲端的 Microsoft Defender。
DevSecOps 的實踐將安全測試整合為持續和持續改進思維的一部分。 戰爭遊戲演習是一種常見的做法，已融入 Microsoft 的業務節奏中。 如需詳細資訊，請參閱 DevOps 中的安全性 （DevSecOps）。
Azure DevOps 支援第三方工具，你可以自動化這些工具，作為持續整合/持續部署流程的一部分。 如需詳細資訊，請參閱 使用 Azure 和 GitHub 啟用 DevSecOps - Azure DevOps。
相關連結
請遵循參與規則，以確保存取權不會被濫用。 如需規劃和執行模擬攻擊的指引，請參閱下列文章：
您可以在 Azure 中模擬阻斷服務 （DoS） 攻擊。 請務必遵循 Azure DDoS 防護模擬測試中列出的原則。
社群連結
應用程式安全性測試：工具、類型和最佳做法 - GitHub 資源 描述可測試應用程式建置時間和執行階段防禦的測試方法類型。
滲透測試執行標準 （PTES） 提供常見案例和建立基準所需活動的指導方針。
OWASP 前十名 |OWASP Foundation 為涵蓋常見威脅的應用程式和測試案例提供安全最佳實務。
安全性檢查清單
請參閱一組完整的建議。