建立安全性基準的建議
適用於 Azure 架構完善的架構安全性檢查清單建議：
| SE：01 | 建立符合合規性需求、業界標準和平臺建議的安全性基準。 定期根據基準測量工作負載架構和作業，以維持或改善一段時間的安全性狀態。 |
|---|
本指南說明建立安全性基準的建議。 安全性基準是一份檔，可指定貴組織的最小安全性需求，以及跨範圍的期望。 良好的安全性基準可協助您：
- 保護您的數據和系統安全。
- 符合法規需求。
- 將監督的風險降至最低。
- 降低缺口和後續業務影響的可能性。
安全性基準應該在整個組織中廣泛發佈，讓所有項目關係人都了解預期。
本指南提供根據內部和外部因素設定安全性基準的建議。 內部因素包括商務需求、風險和資產評估。 外部因素包括產業基準和法規標準。
定義
| 詞彙 | 定義 |
|---|---|
| 基準 | 工作負載必須具備的最低安全性能供性層級，以避免遭到惡意探索。 |
| 基準 | 表示組織想要的安全性狀態的標準。 經過一段時間的評估、測量和改善。 |
| 控制項 | 工作負載的技術或操作控制，有助於防止攻擊並增加攻擊者成本。 |
| 法規需求 | 一組商務需求，由業界標準驅動，法律與當局強加。 |
關鍵設計策略
安全性基準是結構化檔，可定義工作負載必須滿足的一組安全性準則和功能，以提高安全性。 在更成熟的形式中，您可以擴充基準，以包含一組用來設定護欄的原則。
基準應視為測量安全性狀態的標準。 目標應始終全面實現，同時保持廣闊的範圍。
您的安全性基準絕對不應該是臨機操作的工作。 業界標準、合規性（內部或外部）或法規需求、區域需求，以及雲端平臺基準是基準的主要驅動因素。 範例包括因特網安全性中心（CIS）控制中心、國家標準與技術研究所（NIST），以及平臺驅動標準，例如Microsoft雲端安全性基準（MCSB）。 所有這些標準都會被視為基準的起點。 藉由納入商務需求的安全性需求來建置基礎。
如需上述資產的連結，請參閱 相關連結。
藉由在業務和技術領導者之間達成共識來建立基準。 基準不應限制為技術控件。 它也應該包含管理和維護安全性狀態的操作層面。 因此，基準檔也會作為組織對工作負載安全性投資的承諾。 安全性基準文件應該廣泛散發在您的組織內，以確保對工作負載的安全性狀態有意識。
隨著工作負載的成長和生態系統的發展，保持基準與變更保持同步，以確保基本控件仍然有效非常重要。
建立基準是一個有條理的程式。 以下是程序的相關一些建議：
資產清查。 識別工作負載資產的利害關係人，以及這些資產的安全性目標。 在資產清查中，依安全性需求和關鍵性分類。 如需數據資產的相關信息，請參閱 數據分類的建議。
風險評估。 識別與每個資產相關聯的潛在風險，並排定其優先順序。
合規性需求。 基準這些資產的任何法規或合規性，並套用產業最佳做法。
設定標準。 定義並記錄每個資產的特定安全性組態和設定。 可能的話，範本化或尋找可重複的自動化方式，以一致地在整個環境中套用設定。
訪問控制和驗證。 指定角色型訪問控制 （RBAC） 和多重要素驗證 （MFA） 需求。 記錄資產層級的存取權是否足夠。 一律從最低許可權原則開始。
修補程式管理。 在所有資源類型上套用最新版本，以加強攻擊。
文件和通訊。 記錄所有設定、原則和程式。 將詳細數據傳達給相關項目關係人。
強制執行和問責。 建立與安全性基準不相容的明確強制執行機制和後果。 讓個人和小組負責維護安全性標準。
持續監視。 透過可觀察性評估安全性基準的有效性，並加班改善。
定義基準
以下是一些應該屬於基準的常見類別。 下列清單並不詳盡。 其用途為檔範圍的概觀。
法規合規性
工作負載可能會受限於特定產業區段的法規合規性、可能會有一些地理限制等等。 請務必瞭解法規規格中所提供的需求，因為這些需求會影響設計選擇，而且在某些情況下必須包含在架構中。
基準應包含針對法規需求定期評估工作負載。 利用平臺提供的工具，例如 適用於雲端的 Microsoft Defender，可識別不符合規範的區域。 請與組織的合規性小組合作，以確保符合和維護所有需求。
架構元件
基準需要工作負載主要元件的規範性建議。 這些通常包括網路、身分識別、計算和數據的技術控制。 參考平臺所提供的安全性基準，並將遺漏的控件新增至架構。
開發流程
基準必須有下列相關建議：
- 系統分類。
- 已核准的資源類型集。
- 追蹤資源。
- 強制執行使用或設定資源的原則。
開發小組必須清楚瞭解安全性檢查的範圍。 例如，威脅模型化是確保程式碼和部署管線中識別潛在威脅的需求。 請特別瞭解管線中的靜態檢查和弱點掃描，以及小組執行這些掃描的頻率。
如需詳細資訊，請參閱 威脅分析的建議。
開發程式也應該針對各種測試方法及其步調設定標準。 如需詳細資訊，請參閱 安全性測試的建議。
Operations
基準必須設定使用威脅偵測功能的標準，並針對指出實際事件的異常活動引發警示。 威脅偵測必須包含工作負載的所有層級，包括可從惡意網路連線到的所有端點。
基準應包含設定事件回應程序的建議，包括通訊和復原計劃，以及哪些程式可以自動化以加速偵測和分析。 如需範例，請參閱 Azure 的安全性基準概觀。
事件回應也應該包含復原計劃和該計劃的需求，例如定期採取和保護備份的資源。
您可以使用平臺所提供的業界標準和建議來開發數據外泄計劃。 然後，小組有一個全面的計劃，在發現缺口時要遵循。 此外，請洽詢您的組織，以查看是否有網路保險的涵蓋範圍。
訓練
開發和維護安全性訓練計劃，以確保工作負載小組具備適當的技能，以支援安全性目標和需求。 小組需要基本的安全性訓練，但是您可以使用可從貴組織取得的內容來支援特殊角色。 角色型安全性訓練合規性和參與演練是安全性基準的一部分。
套用基準
使用基準來推動計劃，例如：
準備設計決策。 建立安全性基準，並在開始架構設計程式之前發佈它。 請確定小組成員很早就完全瞭解貴組織的期望，這可避免因缺乏明確性而造成成本高昂的重新作業。 您可以使用基準準則作為組織已認可的工作負載需求，並針對這些條件約束設計和驗證控件。
測量您的設計。 根據目前的基準來評分目前的決策。 基準會設定準則的實際閾值。 記錄任何延遲或視為長期可接受的偏差。
磁碟驅動器改善。 雖然基準設定了可達成的目標，但總會有差距。 排定待辦專案差距的優先順序，並根據優先順序進行補救。
根據基準追蹤進度。 針對設定基準持續監視安全性措施至關重要。 趨勢分析是檢閱一段時間安全性進度的好方法，而且可能會顯示與基準的一致偏差。 盡可能使用自動化，從各種來源、內部和外部提取數據，以解決目前的問題，併為未來的威脅做好準備。
設定護欄。 可能的話，您的基準準則必須有護欄。 護欄會根據內部因素和外部因素，強制執行必要的安全性設定、技術和作業。 內部因素包括商務需求、風險和資產評估。 外部因素包括基準、法規標準和威脅環境。 護欄有助於將不當監督和懲罰性罰款的風險降到最低。
探索自定義選項的 Azure 原則，或使用 CIS 基準檢驗或 Azure 安全性效能評定等內建計劃來強制執行安全性設定和合規性需求。 請考慮從基準建立 Azure 原則和計劃。
定期評估基準
持續針對理想狀態累加改善安全性標準，以確保持續降低風險。 進行定期審查，以確保系統處於最新狀態，並符合外部影響。 基準的任何變更都必須正式、同意，並透過適當的變更管理程序傳送。
根據新的基準測量系統，並根據其相關性和對工作負載的影響來排定補救優先順序。
藉由制定符合組織標準的稽核和監視合規性，確保安全性狀態不會隨著時間而降低。
Azure 便利化
Microsoft雲端安全性基準 （MCSB） 是一個完整的安全性最佳做法架構，可讓您作為安全性基準的起點。 將其與提供基準輸入的其他資源一起使用。
如需詳細資訊，請參閱 雲端安全性基準Microsoft簡介。
使用 適用於雲端的 Microsoft Defender （MDC） 法規合規性儀錶板來追蹤這些基準，並在偵測到基準以外的模式時收到警示。 如需詳細資訊，請參閱 自定義法規合規性儀錶板中的一組標準。
有助於建立和改善基準的其他功能：
範例
此邏輯圖表顯示架構元件的範例安全性基準，包括網路、基礎結構、端點、應用程式、數據和身分識別，以示範如何安全地保護常見的IT環境。 其他建議指南是以此範例為基礎。
基礎結構
常見的IT環境，具有具有基本資源的內部部署層。
Azure 安全性服務
Azure 安全性服務和功能，依其保護的資源類型。
Azure 安全性監視服務
除了簡單的監視服務之外，Azure 上提供的監視服務，包括安全性資訊事件管理 （SIEM） 和安全性協調流程自動化回應 （SOAR） 解決方案和 適用於雲端的 Microsoft Defender。
威脅
不論方法或矩陣式 Mitre 攻擊矩陣或網路殺傷鏈結為何，此層都會提出建議並提醒您組織可能根據組織對威脅的擔憂來對應威脅。
相關連結
社群連結
安全性檢查清單
請參閱一組完整的建議。