建立安全性基準的建議

  • 發行項

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

SE：01 建立符合合規性需求、業界標準和平臺建議的安全性基準。 定期根據基準測量工作負載架構和作業，以持續或改善一段時間的安全性狀態。

本指南說明建立安全性基準的建議。 安全性基準是一份檔，可指定貴組織跨範圍的最低安全性需求和期望。 良好的安全性基準可協助您：

  • 保護您的資料和系統安全。
  • 符合法規需求。
  • 將監督的風險降到最低。
  • 降低缺口和後續商務效果的可能性。

安全性基準應該在整個組織中廣泛發佈，讓所有專案關係人都瞭解預期。

本指南提供根據內部和外部因素設定安全性基準的建議。 內部因素包括商務需求、風險和資產評估。 外部因素包括產業基準和法規標準。

定義

詞彙 定義
基準 工作負載必須具備的最低安全性能供性層級，以避免遭到惡意探索。
基準 標準，表示組織對的安全性狀態表示該狀態。 經過一段時間的評估、測量和改善。
控制項 工作負載的技術或操作控制可協助防止攻擊並增加攻擊者成本。
法規需求 一組商務需求，由業界標準驅動，該法律與授權單位會強制執行。

主要設計策略

安全性基準是結構化檔，可定義工作負載必須滿足的一組安全性準則和功能，以提高安全性。 在更成熟的形式中，您可以擴充基準，以包含一組用來設定防護措施的原則。

基準應該視為測量安全性狀態的標準。 目標應該一律是完整的成就，同時保持廣泛的範圍。

您的安全性基準絕對不應該是臨機操作的工作。 業界標準、合規性 (內部或外部) 或法規需求、區域需求，以及雲端平臺基準是基準的主要因素。 範例包括網際網路安全性 (CIS) 控制中心、國家標準和技術 (NIST) 和平臺驅動標準，例如 Microsoft 雲端安全性基準 (MCSB) 。 所有這些標準都會被視為基準的起點。 藉由納入商務需求的安全性需求來建置基礎。

如需上述資產的連結，請參閱 相關連結。

藉由在商務和技術領導者之間取得共識，以建立基準。 基準不應限制為技術控制項。 它也應該包含管理和維護安全性狀態的操作層面。 因此，基準檔也會作為組織對工作負載安全性投資的承諾。 安全性基準檔應該廣泛散發在您的組織內，以確保對工作負載的安全性狀態有意識。

隨著工作負載成長和生態系統發展，請務必讓基準與變更保持同步，以確保基本控制項仍然有效。

建立基準是一個有方法的程式。 以下是程式的相關一些建議：

  • 資產清查。 識別工作負載資產的利害關係人，以及這些資產的安全性目標。 在資產清查中，依安全性需求和重要性分類。 如需資料資產的相關資訊，請參閱 資料分類的建議。

  • 風險評估。 識別與每個資產相關聯的潛在風險，並排定其優先順序。

  • 合規性需求。 針對這些資產建立任何法規或合規性的基準，並套用業界最佳做法。

  • 設定標準。 定義並記錄每個資產的特定安全性組態和設定。 可能的話，請範本化或尋找可重複的自動化方式，以一致地在整個環境中套用設定。

  • 存取控制和驗證。 指定角色型存取控制 (RBAC) 和多重要素驗證 (MFA) 需求。 記錄 足夠的存取 權在資產層級的意義。 一律從最低許可權的原則開始。

  • 修補程式管理。 在所有資源類型上套用最新版本，以強化攻擊。

  • 檔和通訊。 記錄所有設定、原則和程式。 將詳細資料傳達給相關的專案關係人。

  • 強制執行和責任。 針對不符合安全性基準的規範，建立明確的強制執行機制和結果。 讓個人和小組負責維護安全性標準。

  • 持續監視。 透過可觀察性評估安全性基準的有效性，並隨著時間改善。

基準的組成

以下是一些應該屬於基準的常見類別。 下列清單並不詳盡。 其用途為檔範圍的概觀。

法規合規性

工作負載可能會受限於特定產業區段的法規合規性、可能有一些地理限制等等。 請務必瞭解法規規格中所提供的需求，因為這些需求會影響設計選擇，在某些情況下必須包含在架構中。

基準應包含針對法規需求定期評估工作負載。 利用平臺提供的工具，例如適用于雲端的 Microsoft Defender，可識別不符合規範的區域。 請與組織的合規性小組合作，以確保符合和維護所有需求。

架構元件

基準需要工作負載主要元件的規範性建議。 這些通常包括網路、身分識別、計算和資料的技術控制。 參考平臺所提供的安全性基準，並將遺漏的控制項新增至架構。

請參閱 範例。

開發流程

基準必須有下列相關建議：

  • 系統分類。
  • 已核准的資源類型集。
  • 追蹤資源。
  • 強制執行使用或設定資源的原則。

開發小組必須清楚瞭解安全性檢查的範圍。 例如，威脅模型化是確保程式碼和部署管線中識別潛在威脅的需求。 請特別瞭解管線中的靜態檢查和弱點掃描，以及小組需要如何定期執行這些掃描。

如需詳細資訊，請參閱 威脅分析的建議。

開發程式也應該針對各種測試方法及其步調設定標準。 如需詳細資訊，請參閱 安全性測試的建議。

Operations

基準必須設定使用威脅偵測功能的標準，並針對指出實際事件的異常活動提出警示。 威脅偵測需要包含工作負載的所有層級，包括可從惡意網路連線到的所有端點。

基準應該包含設定事件回應程式的建議，包括通訊和復原計畫，以及哪些程式可以自動化以加速偵測和分析。 如需範例，請參閱 Azure 的安全性基準概觀。

事件回應也應該包含復原方案和該計畫的需求，例如定期進行和保護備份的資源。

您可以使用平臺所提供的產業標準和建議來開發資料外泄計畫。 然後，小組就會有一個完整的計畫，在探索到缺口時要遵循。 此外，請洽詢您的組織，以查看是否有網路功能涵蓋範圍。

訓練

開發和維護安全性訓練計畫，以確保工作負載小組具備適當的技能，以支援安全性目標和需求。 小組需要基本安全性訓練，但您可以使用貴組織的內容來支援特殊角色。 角色型安全性訓練合規性和參與演練是安全性基準的一部分。

使用基準

使用基準來推動計畫，例如：

  • 準備進行設計決策。 在您開始架構設計程式之前，請先建立安全性基準並加以發佈。 請確定小組成員已充分瞭解貴組織的期望，以避免因缺乏清楚起見而造成成本高昂的重新工作。 您可以使用基準準則作為組織承諾的工作負載需求，並針對這些條件約束設計和驗證控制項。

  • 測量您的設計。 根據目前的基準對目前決策進行評分。 基準會設定準則的實際臨界值。 記錄延遲或視為長期可接受的任何偏差。

  • 磁片磁碟機改善。 雖然基準會設定可達成的目標，但一律會有差距。 排定待辦專案中的差距，並根據優先順序進行補救。

  • 根據基準追蹤進度。 針對設定基準持續監視安全性措施是不可或缺的。 趨勢分析是檢閱一段時間安全性進度的好方法，而且可能會顯示與基準一致的偏差。 盡可能使用自動化，從各種來源提取資料、內部和外部，以解決目前的問題並準備未來威脅。

  • 設定護欄。 可能的話，您的基準準則必須有護欄。 護欄會根據內部因素和外部因素，強制執行必要的安全性設定、技術和作業。 內部因素包括商務需求、風險和資產評估。 外部因素包括基準測試、法規標準和威脅環境。 護欄有助於將不小心監督和不合規的懲罰風險降到最低。

探索自訂選項的Azure 原則，或使用 CIS 基準測試或 Azure 安全性基準等內建計畫來強制執行安全性設定和合規性需求。 請考慮從基準建立 Azure 原則和計畫。

定期評估基準

以累加方式改善安全性標準，以達成理想的狀態，以確保持續降低風險。 進行定期檢閱，以確保系統處於最新狀態且符合外部影響。 基準的任何變更都必須是正式、同意，並透過適當的變更管理程式傳送。

根據新的基準測量系統，並根據其相關性和對工作負載的影響來排定補救的優先順序。

藉由利用組織標準的稽核和監視合規性，確保安全性狀態不會隨著時間降低。

Azure 指導

Microsoft 雲端安全性效能評定 (MCSB) 是一個完整的安全性最佳做法架構，可用來作為安全性基準的起點。 將其與提供基準輸入的其他資源搭配使用。

如需詳細資訊，請參閱 Microsoft 雲端安全性基準簡介。

使用 Cloud (MDC) 法規合規性儀表板的 Microsoft Defender來追蹤這些基準，並在偵測到基準以外的模式時收到警示。 如需詳細資訊，請參閱 在法規合規性儀表板中自訂標準集。

有助於建立和改善基準的其他功能：

範例

此邏輯圖表顯示架構元件的範例安全性基準，其中包含網路、基礎結構、端點、應用程式、資料和身分識別，以示範如何安全地保護常見的 IT 環境。 其他建議指南是以這個範例為基礎。

此圖顯示具有架構元件之組織安全性基準 IT 環境的範例。

基礎結構

常見的 IT 環境，具有具有基本資源的內部部署層。

Azure 安全性服務

Azure 安全性服務和功能，其所保護的資源類型。

Azure 安全性監視服務

Azure 上提供的監視服務超越簡單的監視服務，包括安全性資訊事件管理 (SIEM) 和安全性協調流程自動化回應 (SOAR) 解決方案和雲端Microsoft Defender。

威脅

不論方法或矩陣式 Mitre 攻擊矩陣或網路終止鏈結為何，此層都會提出建議和提醒，根據貴組織對於威脅的疑慮來對應威脅。

組織一致性

雲端採用架構提供中央小組關於使用建議範本建立基準的指引：

安全性檢查清單

請參閱一組完整的建議。

安全性檢查清單