安全性測試的建議
適用於此 Azure 架構完善的架構安全性檢查清單建議：
| SE：11 | 建立綜合測試方案，結合防止安全性問題的方法、驗證威脅預防實作，以及測試威脅偵測機制。 |
|---|
嚴格的測試是良好安全性設計的基礎。 測試是驗證的戰術形式，可確保控件如預期般運作。 測試也是偵測系統中弱點的主動方式。
透過多個觀點的步調和驗證來建立測試嚴謹性。 您應該包含測試平臺和基礎結構的內在觀點，以及測試系統的外部評估，例如外部攻擊者。
本指南提供測試工作負載安全性狀態的建議。 實作這些測試方法，以改善工作負載對攻擊的抵抗，並維護資源的機密性、完整性和可用性。
定義
| 術語 | 定義 |
|---|---|
| 應用程式安全性測試 （AST） | Microsoft安全性開發生命週期 （SDL） 技術，使用白箱和黑箱測試方法來檢查程式代碼中的安全性弱點。 |
| 黑箱測試 | 測試方法，可驗證外部可見的應用程式行為，而不需要瞭解系統內部。 |
| 藍色團隊 | 一支在戰爭遊戲演習中防禦紅隊攻擊的球隊。 |
| 滲透測試 | 測試方法，使用道德駭客技術來驗證系統的安全性防禦。 |
| 紅色團隊 | 一支扮演對手角色的球隊，試圖在戰爭遊戲演習中破解系統。 |
| 安全性開發週期 (SDL) | Microsoft提供的一組做法，可支援安全性保證和合規性需求。 |
| 軟體開發生命週期 （SDLC） | 開發軟體系統的多階段系統程式。 |
| 白箱測試 | 測試方法，其中從業者知道程式代碼的結構。 |
關鍵設計策略
測試是不可談判的策略，尤其是安全性。 它可讓您主動探索並解決安全性問題，然後才能加以惡意探索，並確認您實作的安全性控制是否如設計般運作。
測試的範圍必須包含應用程式、基礎結構和自動化和人為程式。
注意
本指南會區分測試和事件回應。 雖然測試是一種偵測機制，在理想情況下會修正生產環境之前的問題，但不應與事件回應一部分所做的補救或調查混淆。 從安全性事件復原的層面說明於事件回應建議中。
SDL 包含數種類型的測試，可攔截程式代碼中的弱點、驗證運行時間元件，以及使用道德駭客攻擊來測試系統的安全性復原能力。 SDL 是主要移位左活動。 您應該盡早在開發程式中執行靜態程式代碼分析和自動化掃描基礎結構即程式代碼 （IaC） 等測試。
參與測試規劃。 工作負載小組可能不會設計測試案例。 這項工作通常集中在企業中，或由外部安全性專家完成。 工作負載小組應該參與該設計程式，以確保安全性保證與應用程式的功能整合。
請像攻擊者一樣思考。 使用系統遭到攻擊的假設來設計測試案例。 如此一來，您就可以找出潛在的弱點，並據此排定測試的優先順序。
以結構化的方式執行測試，並使用可重複的程式執行測試。 圍繞頻率、測試類型、驅動因素和預定結果，建立測試嚴謹性。
針對作業使用正確的工具。 使用設定為使用工作負載的工具。 如果您沒有工具，請購買此工具。 不要建置它。 安全性工具高度特製化，建置您自己的工具可能會帶來風險。 如果工作負載小組沒有該專業知識，請利用中央 SecOps 小組所提供的專業知識和工具，或透過外部手段。
設定不同的環境。 測試可以分類為破壞性或非破壞性。 非破壞性測試不是侵入性測試。 它們表示有問題，但不會改變功能來補救問題。 破壞性測試是侵入性的，而且可能會藉由從資料庫刪除數據來損害功能。
在生產環境中測試可提供最佳資訊，但造成最多中斷。 您通常只會在生產環境中執行非破壞性測試。 在非生產環境中進行測試通常較不具干擾性，但可能無法準確地以對安全性而言很重要的方式來呈現生產環境的設定。
如果您使用 IaC 和自動化進行部署，請考慮您是否可以建立生產環境的隔離複製品進行測試。 如果您有例行測試的連續程序，建議您使用專用的環境。
請一律評估測試結果。 如果結果不是用來排定動作的優先順序並進行上游改進，則測試會浪費精力。 記錄您發現的安全性指導方針，包括最佳做法。 擷取結果和補救計劃的檔會讓小組了解攻擊者可能嘗試入侵安全性的各種方式。 針對開發人員、系統管理員和測試人員定期進行安全性訓練。
當您設計測試計劃時，請考慮下列問題：
您預期測試要執行的頻率，以及測試如何影響您的環境？
您應該執行哪些不同的測試類型？
定期測試工作負載
定期測試工作負載，以確保變更不會帶來安全性風險，而且沒有任何回歸。 小組也必須準備好回應可能隨時進行的組織安全性驗證。 您也可以執行測試，以回應安全性事件。 下列各節提供測試頻率的建議。
例程測試
例行測試會定期進行，作為標準作業程式的一部分，並符合合規性需求。 各種測試可能會以不同的步調執行，但關鍵是會定期和依排程執行。
您應該將這些測試整合到 SDLC 中，因為它們會在每個階段提供深度防禦。 使測試套件多樣化，以驗證身分識別、數據儲存和傳輸和通道的保證。 在生命週期的不同點執行相同的測試，以確保沒有任何回歸。 例行測試有助於建立初始基準檢驗。 然而，這隻是一個起點。 當您在生命週期的相同時間點發現新問題時，您會新增測試案例。 測試也會隨著重複而改善。
在每個階段，這些測試都應該驗證新增或移除的程序代碼或已變更的組態設定，以偵測這些變更的安全性影響。 您應該使用自動化來改善測試的效能，並與對等檢閱保持平衡。
請考慮在自動化管線或排程的測試回合中執行安全性測試。 您越早發現安全性問題，就越容易找到導致安全性問題的程式代碼或組態變更。
不只依賴自動化測試。 使用手動測試來偵測只有人類專業知識才能攔截的弱點。 手動測試適用於探勘使用案例，並找出未知的風險。
即興測試
臨時測試提供安全性防禦的時間點驗證。 屆時可能會影響工作負載的安全性警示會觸發這些測試。 如果警示提升到緊急狀態，組織授權可能需要暫停和測試思維，以驗證防禦策略的有效性。
即興測試的好處是準備一個真正的事件。 這些測試可以是強制函式來執行使用者驗收測試 （UAT）。
安全性小組可能會稽核所有工作負載，並視需要執行這些測試。 身為工作負載擁有者，您必須協助與安全性小組共同作業。 請與安全性小組交涉足夠的前置時間，以便您做好準備。 向小組和項目關係人確認並傳達這些中斷是必要的。
在其他情況下，您可能需要執行測試和報告系統的安全性狀態，以防範潛在威脅。
取捨：因為即興測試是干擾性事件，因此預期會重設任務，這可能會延遲其他計劃的工作。
風險：未知的風險。 沒有建立的程式或工具，即興測試可能是一次性的工作。 但主要的風險是業務節奏的潛在中斷。 您必須評估這些風險相對於優點。
安全性事件測試
有測試會偵測其來源的安全性事件原因。 必須解決這些安全性缺口，以確保不會重複此事件。
事件也會藉由發現現有的差距來改善一段時間的測試案例。 小組應套用從事件中吸取的教訓，並定期納入改進。
採用各種測試
測試可以依技術和測試方法分類。 將這些類別和方法結合在這些類別內，以取得完整的涵蓋範圍。
藉由新增多個測試和測試類型，您可以發現：
安全性控件或補償控件的差距。
設定錯誤。
可觀察性和偵測方法的間距。
良好的威脅模型化練習可以指向關鍵領域，以確保測試涵蓋範圍和頻率。 如需威脅模型化的建議，請參閱 保護開發生命周期的建議。
這些區段中所述的大部分測試都可以以例行測試的形式執行。 不過，在某些情況下，可重複性可能會產生成本並造成中斷。 仔細考慮這些取捨。
驗證技術堆疊的測試
以下是一些測試類型及其焦點區域的範例。 這份清單並不完整。 測試整個堆疊，包括應用程式堆疊、前端、後端、API、資料庫，以及任何外部整合。
數據安全性：測試數據加密和訪問控制的有效性，以確保數據受到適當保護，免於未經授權的存取和竄改。
網路和連線能力：測試您的防火牆，以確保防火牆只允許預期的、允許和安全流量進入工作負載。
應用程式：透過應用程式安全性測試 （AST） 技術測試原始程式碼，以確保您遵循安全編碼做法，並攔截記憶體損毀和許可權問題等運行時間錯誤。 如需詳細資訊，請參閱這些 社群連結。
身分識別：評估角色指派和條件式檢查是否如預期般運作。
測試方法
測試方法有許多觀點。 建議您藉由模擬真實世界攻擊來啟用威脅搜捕的測試。 他們可以識別潛在的威脅執行者、其技術和對工作負載構成威脅的惡意探索。 盡可能逼真地進行攻擊。 使用您在威脅模型化期間識別的所有潛在威脅向量。
以下是透過真實世界攻擊進行測試的一些優點：
當您讓這些攻擊成為例行測試的一部分時，您可以使用外部檢視方塊來檢查工作負載，並確定防禦可以承受攻擊。
根據他們學到的課程，小組會提升他們的知識和技能水準。 小組可改善情況意識，並可自行評估其回應事件的準備程度。
模擬測試的一些範例包括黑箱和白箱測試、滲透測試和戰爭遊戲練習。
黑箱和白箱測試
這些測試類型提供兩個不同的檢視方塊。 在黑箱測試中，系統的內部不會顯示。 在白箱測試中，測試人員對應用程式有很好的瞭解，甚至能夠存取執行實驗的程式代碼、記錄、資源拓撲和組態。
透過滲透測試模擬攻擊的測試
不屬於組織 IT 或應用程式小組的安全性專家會進行滲透測試或 筆試。 他們會以惡意執行者界定攻擊面的方式來查看系統。 其目標是藉由收集資訊、分析弱點及報告結果來找出安全性缺口。
從業者可能需要存取整個組織中的敏感數據。 請遵循參與規則，以確保不會誤用存取權。 請參閱相關連結中列出的資源。
透過戰爭遊戲練習模擬攻擊的測試
在模擬攻擊的此方法中，有兩個小組：
紅隊是試圖建立真實世界攻擊模型的對手。 如果成功，您可以在安全性設計中找到差距，並評估其缺口的爆破半徑內含。
藍色小組是防禦攻擊的工作負載小組。 他們會測試其偵測、回應和補救攻擊的能力。 他們會驗證已實作以保護工作負載資源的防禦。
如果他們作為例行測試進行，戰爭遊戲練習可以提供持續的可見度和保證，您的防禦工作如設計。 戰爭遊戲練習可能會在工作負載內跨層級進行測試。
模擬實際攻擊案例的熱門選擇是 適用於 Office 365 的 Microsoft Defender 攻擊模擬訓練。
如需詳細資訊，請參閱 攻擊模擬訓練的深入解析和報告。
如需 red-team 和 blue-team 設定的相關信息，請參閱 Microsoft Cloud Red Teaming。
Azure 便利化
Microsoft Sentinel 是結合安全性資訊事件管理 （SIEM） 和安全性協調流程自動化回應 （SOAR） 功能的原生控件。 它會分析來自各種連線來源的事件和記錄。 根據數據源及其警示，Microsoft Sentinel 會建立事件並執行威脅分析以進行早期偵測。 透過智慧型手機分析和查詢，您可以主動尋找安全性問題。 如果有事件，您可以將工作流程自動化。 此外，透過活頁簿範本，您可以透過視覺效果快速取得見解。
如需產品檔，請參閱 Sentinel Microsoft中的搜捕功能。
適用於雲端的 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 為涵蓋常見威脅的應用程式和測試案例提供安全性最佳做法。
安全性檢查清單
請參閱一組完整的建議。