安全性測試的建議

  • 發行項

適用于此 Azure Well-Architected Framework 安全性檢查清單建議：

SE：11 建立完整的測試計劃，結合防止安全性問題的方法、驗證威脅防護實作，以及測試威脅偵測機制。

嚴格測試是良好安全性設計的基礎。 測試是一種策略性形式的驗證，可確保控制項如預期般運作。 測試也是偵測系統中弱點的主動方式。

透過多個觀點的步調和驗證，建立測試嚴謹度。 您應該包含測試平臺和基礎結構的外景觀點，以及測試系統的外部評估，例如外部攻擊者。

本指南提供測試工作負載安全性狀態的建議。 實作這些測試方法，以改善工作負載對攻擊的抗拒，並維護資源的機密性、完整性和可用性。

定義

詞彙 定義
AST) (應用程式安全性測試 Microsoft 安全性開發生命週期 (SDL) 技術，使用白箱和黑箱測試方法來檢查程式碼中的安全性弱點。
黑箱測試 測試方法，可驗證外部可見的應用程式行為，而不知道系統內部。
藍色小組 在 war 遊戲練習中防禦紅隊攻擊的小組。
滲透測試 使用道德駭客技術來驗證系統安全性防禦的測試方法。
紅色團隊 一個小組，扮演敵人的角色，並嘗試在遊戲練習中入侵系統。
安全性開發生命週期 (SDL) Microsoft 所提供的一組做法，可支援安全性保證和合規性需求。
SDLC) (軟體發展生命週期 用於開發軟體系統的多階段系統化程式。
白箱測試 測試方法，其中程式碼的結構已知。

主要設計策略

測試是不可分類的策略，特別是針對安全性。 它可讓您主動探索並解決安全性問題，才能加以利用，並確認您所實作的安全性控制項如設計般運作。

測試的範圍必須包含應用程式、基礎結構，以及自動化和人為程式。

注意

本指南會區分測試和事件回應。 雖然測試是一種偵測機制，在理想情況下會在生產環境之前修正問題，但不應該與在事件回應中完成的補救或調查混淆。 從安全性事件復原的層面說明于 事件回應建議中。

SDL 包含數種類型的測試，可攔截程式碼中的弱點、驗證執行時間元件，以及使用道德駭客入侵來測試系統的安全性復原能力。 SDL 是一項關鍵移轉左活動。 您應該儘快在開發程式中執行靜態程式碼分析和自動化掃描基礎結構即程式碼 (IaC) 。

參與測試規劃。 工作負載小組可能不會設計測試案例。 該工作通常集中于企業中，或由外部安全性專家完成。 工作負載小組應該參與該設計程式，以確保安全性保證會與應用程式的功能整合。

想像一下攻擊者。 使用假設系統遭到攻擊來設計您的測試案例。 如此一來，您可以找出潛在的弱點，並據以排定測試的優先順序。

以結構化方式和可重複的程式執行測試。 在步調、測試類型、駕駛因素和預定結果周圍建置您的測試嚴謹度。

針對作業使用正確的工具。 使用設定為使用工作負載的工具。 如果您沒有工具，請購買此工具。 請勿建置它。 安全性工具高度特製化，建置您自己的工具可能會帶來風險。 如果工作負載小組沒有該專業知識，請利用中央 SecOps 小組所提供的專業知識和工具，或利用外部方式。

設定個別的環境。 測試可分類為破壞性或非破壞性。 非破壞性測試並不具破壞性。 它們表示發生問題，但不會改變功能來補救問題。 破壞性測試是入侵性的，而且可能會藉由從資料庫刪除資料來損害功能。

在生產環境中進行測試會為您提供最佳資訊，但會造成最多中斷。 您通常只會在生產環境中執行非破壞性測試。 在非生產環境中進行測試通常較不具干擾性，但可能不會以安全性很重要的方式來正確代表生產環境的設定。

如果您使用 IaC 和自動化進行部署，請考慮您是否可以建立生產環境的隔離複製品進行測試。 如果您有例行測試的連續程式，建議您使用專用的環境。

一律評估測試結果。 如果未使用結果來排定動作的優先順序，並讓上游改善，測試就會浪費心力。 記載您發現的安全性指導方針，包括最佳做法。 擷取結果和補救計畫的檔會教育小組可能嘗試入侵安全性的各種方式。 為開發人員、系統管理員和測試人員進行週期性安全性訓練。

當您設計測試計劃時，請考慮下列問題：

  • 您預期測試的執行頻率，以及其如何影響您的環境？

  • 您應該執行哪些不同的測試類型？

您預期測試的執行頻率為何？

定期測試工作負載，以確定變更不會帶來安全性風險，而且沒有任何回歸。 小組也必須準備好回應可能隨時進行的組織安全性驗證。 另外還有測試可供您執行，以回應安全性事件。 下列各節提供測試頻率的建議。

常式測試

例行測試會定期進行，作為標準作業程式的一部分，並符合合規性需求。 各種測試可能會以不同的步調執行，但關鍵在於會定期和排程執行。

您應該將這些測試整合到 SDLC 中，因為它們會在每個階段提供深度防禦。 讓測試套件能夠確認身分識別、資料儲存和傳輸和通道的保證。 在生命週期的不同點執行相同的測試，以確保沒有任何回歸。 例行測試有助於建立初始基準測試。 不過，這只是起點。 當您在生命週期的相同點發現新問題時，您會新增新的測試案例。 測試也會使用重複來改善。

在每個階段，這些測試都應該驗證已新增或移除的程式碼或已變更的組態設定，以偵測這些變更的安全性影響。 您應該使用自動化來改善測試的效力，並與對等檢閱平衡。

請考慮在自動化管線或排程的測試回合中執行安全性測試。 您發現安全性問題越快越好，就更容易找到造成安全性問題的程式碼或組態變更。

不只依賴自動化測試。 使用手動測試來偵測只有人類專業知識可以攔截的弱點。 手動測試適用于探勘使用案例，並尋找未知的風險。

隨插即用測試

即時測試提供安全性防禦的時間點驗證。 此時可能會影響工作負載的安全性警示會觸發這些測試。 如果警示呈報緊急狀態，組織要求暫停和測試思維，以驗證防禦策略的有效性。

即時測試的優點是實際事件的準備。 這些測試可以是強制函式，以在 UAT) (執行使用者接受度測試。

安全性小組可能會稽核所有工作負載，並視需要執行這些測試。 身為工作負載擁有者，您必須協助與安全性小組共同作業。 與安全性小組交涉足夠的前置時間，以便您做好準備。 請確認並與您的小組和專案關係人溝通這些中斷是必要的。

在其他情況下，您可能需要執行測試，並報告系統的安全性狀態，以防範潛在威脅。

取捨：因為即時測試是干擾性事件，所以預期會重新決定工作，這可能會延遲其他計劃性工作。

風險：未知的風險。 在沒有建立的程式或工具的情況下，模擬測試可能是一次性的工作。 但主要風險是業務節奏的潛在中斷。 您必須評估這些風險相對於權益。

安全性事件測試

有一項測試會偵測其來源的安全性事件原因。 必須解決這些安全性缺口，以確保事件不會重複。

事件也會藉由發現現有的差距來改善一段時間的測試案例。 小組應套用從事件學到的課程，並定期納入改進。

不同類型的測試為何？

測試可以依技術和測試方法分類。 將這些類別和方法結合在這些類別內，以取得完整的涵蓋範圍。

藉由新增多個測試和測試類型，您可以發現：

  • 安全性控制項或補償控制項的間距。

  • 設定錯誤。

  • 可觀察性和偵測方法的間距。

良好的威脅模型化練習可以指向關鍵區域，以確保測試涵蓋範圍和頻率。 如需威脅模型化的建議，請參閱 保護開發生命週期的建議。

這些章節所述的大部分測試都可以以例行測試的形式執行。 不過，在某些情況下，可重複性可能會產生成本，並造成中斷。 仔細考慮這些取捨。

驗證技術堆疊的測試

以下是一些測試類型及其焦點區域的範例。 這份清單並不完整。 測試整個堆疊，包括應用程式堆疊、前端、後端、API、資料庫，以及任何外部整合。

  • 資料安全性：測試資料加密和存取控制的有效性，以確保資料受到適當保護，免于未經授權的存取和竄改。

  • 網路和連線能力：測試防火牆，以確保它們只允許預期、允許且安全的工作負載流量。

  • 應用程式：透過應用程式安全性測試來測試原始程式碼 (AST) 技術，以確保您遵循安全的編碼做法，並攔截執行時間錯誤，例如記憶體損毀和許可權問題。 如需詳細資訊，請參閱這些 社群連結。

  • 身分識別：評估角色指派和條件式檢查是否如預期般運作。

測試方法

測試方法有許多觀點。 我們建議藉由模擬真實世界攻擊來啟用威脅搜捕的測試。 他們可以識別潛在的威脅執行者、其技術，以及對工作負載造成威脅的惡意探索。 盡可能讓攻擊更實際。 使用您在威脅模型化期間識別的所有潛在威脅向量。

以下是透過真實世界攻擊進行測試的一些優點：

  • 當您將這些攻擊設為例行測試的一部分時，您會使用外部觀點來檢查工作負載，並確定防禦可以承受攻擊。

  • 根據他們學到的課程，小組會升級其知識與技能等級。 小組可改善情況感知，並可自行評估其整備程度以回應事件。

風險：一般測試可能會影響效能。 如果破壞性測試刪除或損毀資料，可能會發生商務持續性問題。 也會有與資訊暴露相關的風險;請務必維護資料的機密性。 在您完成測試之後，請確定資料的完整性。

模擬測試的一些範例包括黑箱和白箱測試、滲透測試和遊戲練習。

黑箱和白箱測試

這些測試類型提供兩個不同的檢視方塊。 在黑箱測試中，系統的內部不會顯示。 在白箱測試中，測試人員對於應用程式有良好的瞭解，甚至能夠存取程式碼、記錄、資源拓撲，以及用於進行實驗的組態。

風險：這兩種類型之間的差異是預先成本。 白箱測試在瞭解系統所花費的時間方面可能很昂貴。 在某些情況下，白箱測試需要您購買特殊工具。 黑箱測試不需要增加時間，但可能不是有效的。 您可能需要投入額外的心力來找出問題。 這是投資取捨的時間。

透過滲透測試模擬攻擊的測試

不屬於組織 IT 或應用程式小組的安全性專家會進行滲透測試或 畫筆測試。 他們會以惡意執行者的範圍界定受攻擊面的方式查看系統。 其目標是藉由收集資訊、分析弱點，以及報告結果來找出安全性差距。

取捨：滲透測試是暫時的，而且在中斷和貨幣投資方面可能很昂貴，因為畫筆測試通常是協力廠商專業人員的付費供應專案。

風險：畫筆測試練習可能會影響執行時間環境，而且可能會中斷正常流量的可用性。

練習者可能需要存取整個組織中的敏感性資料。 遵循參與規則，以確保存取不會誤用。 請參閱 相關連結中列出的資源。

透過遊戲練習模擬攻擊的測試

在此模擬攻擊方法中，有兩個小組：

  • 紅色小組是攻擊者嘗試建立真實世界攻擊的模型。 如果成功，您會在安全性設計中找到差距，並評估其缺口的彈射半徑內含專案。

  • 藍色小組是防禦攻擊的工作負載小組。 他們會測試其偵測、回應及補救攻擊的能力。 他們會驗證已實作以保護工作負載資源的防禦。

如果它們是以例行測試的形式進行，則遊戲練習可以提供持續可見度，並保證您的防禦工作如設計般運作。 War 遊戲練習可能會在您的工作負載內跨層級進行測試。

模擬實際攻擊案例的熱門選擇是適用於 Office 365 的 Microsoft Defender攻擊模擬訓練。

如需詳細資訊，請參閱攻擊模擬訓練的深入解析和報告。

如需 red-team 和 blue-team 設定的相關資訊，請參閱 Microsoft Cloud Red Teaming。

Azure 設施

Microsoft Sentinel 是一種原生控制項，結合了安全性資訊事件管理 (SIEM) 和安全性協調流程自動化回應 (SOAR) 功能。 其會分析來自各種連線來源的事件和記錄。 根據資料來源及其警示，Microsoft Sentinel 會建立事件，並執行威脅分析以進行早期偵測。 透過智慧型分析和查詢，您可以主動搜捕安全性問題。 如果有事件，您可以將工作流程自動化。 此外，透過活頁簿範本，您可以透過視覺效果快速取得見解。

如需產品檔，請參閱 Microsoft Sentinel 中的搜捕功能。

Microsoft Defender for Cloud 提供各種技術區域的弱點掃描。 如需詳細資訊，請參閱使用 Microsoft Defender 弱點管理 啟用弱點掃描 - 雲端Microsoft Defender。

DevSecOps 的做法會將安全性測試整合為持續且持續改善思維的一部分。 War 遊戲練習是整合至 Microsoft 企業節奏的常見作法。 如需詳細資訊，請參閱 DevOps 中的安全性 (DevSecOps) 。

Azure DevOps 支援可在持續整合/持續部署管線中自動化的協力廠商工具。 如需詳細資訊，請參閱 使用 Azure 和 GitHub 啟用 DevSecOps - Azure DevOps。

請遵循參與規則，以確保不會誤用存取權。 如需規劃和執行模擬攻擊的指引，請參閱下列文章：

您可以在 Azure 中模擬拒絕服務 (DoS) 攻擊。 請務必遵循 Azure DDoS 保護模擬測試中配置的原則。

應用程式安全性測試：工具、類型和最佳做法 - GitHub 資源 描述可測試應用程式建置時間和執行時間防禦的測試方法類型。

滲透測試執行標準 (PTES) 包含常見案例和建立基準所需進行活動的相關方針。

OWASP 前十名 |OWASP Foundation 為涵蓋常見威脅的應用程式和測試案例提供安全性最佳做法。

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單