當安全控制進入雲端平台後，可以先依照不同的安全領域進行整理，再進一步展開成具體的控制要求，形成一套可以管理與持續維護的安全控制基準。

Microsoft Cloud Security Baseline 如何整理安全控制？

在前面的內容中，我們已經看到 CIS Benchmark 如何透過不同的導入層級與控制分類，協助企業整理大量的安全控制。當這樣的概念進一步進入雲端平台後，面對的情況會更加複雜，因為雲端平台本身包含身分、網路、運算、儲存、資料、監控以及各種平台服務，而每一項服務又可能有不同的安全設定與管理方式。

如果將這些控制直接整理成一份長長的設定清單，雖然可以列出大量要求，但實際管理時仍然不容易理解各項控制之間的關係。因此，Microsoft Cloud Security Baseline 採取的方式，是先從不同的安全領域整理控制，再將各個領域進一步展開成具體的控制要求。這樣一來，企業可以先從整體安全能力的角度理解平台需要管理哪些面向，再進一步確認每一項控制應該如何落實。

圖 22-1 Microsoft Cloud Security Baseline Control Domains

從這張圖可以看到，Microsoft 將雲端安全控制分成 12 個 Control Domains，包括網路安全（Network Security, NS）、身分管理（Identity Management, IM）、特權存取（Privileged Access, PA）、資料保護（Data Protection, DP）、資產管理（Asset Management, AM）、日誌與威脅偵測（Logging and Threat Detection, LT）、事件回應（Incident Response, IR）、安全狀態與弱點管理（Posture and Vulnerability Management, PV）、端點安全（Endpoint Security, ES）、備份與復原（Backup and Recovery, BR）、DevOps 安全（DevOps Security, DS） 以及 AI 安全（AI Security, AI）。

這樣的分類並不是單純將控制項重新排列，而是先建立一個共同的安全管理架構。不同的控制可以先找到所屬的安全領域，再從該領域進一步了解具體需要管理的事項。對架構師而言，這有助於從「平台需要具備哪些安全能力」的角度理解控制，而不是只看到個別設定。

Control Domains：從安全領域整理控制要求

Microsoft Cloud Security Baseline 將安全控制分成不同的 Control Domains，每一個領域都代表雲端平台需要持續管理的一項安全面向。

例如：

• Network Security（NS）：保護網路架構與流量，降低未經授權的存取風險。
• Identity Management（IM）：管理身分與存取權限，落實最小權限與身分治理。
• Privileged Access（PA）：管理高權限帳號與特權操作，降低權限濫用的風險。
• Data Protection（DP）：保護資料生命週期，包括資料分類、加密以及金鑰管理。
• Asset Management（AM）：掌握平台資產與設定，維持資產的可視性與一致性。
• Logging and Threat Detection（LT）：建立日誌蒐集、監控與威脅偵測能力。
• Incident Response（IR）：建立事件處理流程，降低資安事件造成的影響。
• Posture and Vulnerability Management（PV）：持續評估安全狀態，改善弱點與設定風險。
• Endpoint Security（ES）：保護終端裝置與工作負載，降低惡意程式與入侵風險。
• Backup and Recovery（BR）：建立備份與復原能力，維持服務持續運作。
• DevOps Security（DS）：將安全納入開發流程，提升軟體交付的安全性。
• AI Security（AI）：針對 AI 模型與相關服務建立適當的安全控制。

因此，Control Domain 可以先協助企業回答「這一類安全問題應該由哪個領域管理」，再進一步往下確認具體的控制要求。當平台持續增加新的服務時，也可以沿用相同的分類方式，將新的安全需求納入既有的管理架構，而不需要每次都重新建立一套分類方式。

從控制領域進一步展開具體控制

Control Domain 建立的是分類架構，但真正要落實到平台，仍然需要進一步展開成具體的控制要求。以 Data Protection（DP） 為例，資料保護並不是單一項設定，而是包含多個不同的管理要求。

例如，DP 領域可以進一步涵蓋敏感資料識別、資料加密，以及金鑰與憑證管理等控制。這些控制分別處理資料生命週期中的不同安全需求，因此企業可以從 Control Domain 先掌握整體管理方向，再透過個別控制確認實際需要完成哪些工作。

Microsoft 也會為這些控制建立對應的 Control ID，例如 DP-1、DP-2、DP-3 等。透過固定的識別方式，每一項控制都可以被清楚引用，後續無論是制定內部規範、進行安全檢查、執行稽核，或建立自動化檢查，都可以直接對應到相同的控制要求。

這使得安全控制不只是文件中的描述，而可以成為不同團隊共同使用的管理語言。架構師可以依據控制要求規劃平台架構，維運團隊可以確認控制是否落實，稽核人員則可以依據相同的 Control ID 進行查核。

從控制要求到平台實作

當控制要求確定之後，下一個問題就是如何在實際的平台上完成落實。Microsoft Cloud Security Baseline 的另一項特色，就是將控制要求與 Microsoft Cloud 所提供的平台能力建立對應關係，讓企業可以進一步思考每一項控制應該透過哪些服務與技術能力實現。

例如，資料保護可以搭配加密服務與金鑰管理機制，身分管理可以透過 Microsoft Entra ID 建立身分與存取控制，安全監控則可以結合 Microsoft Defender 與 Microsoft Sentinel 建立日誌分析與威脅偵測能力。這些平台服務並不是控制本身，而是協助企業將控制要求落實到實際環境中的技術能力。

因此，可以將整個關係理解成一個由上而下的結構：先從 Control Domain 確認安全管理的領域，再透過 Control ID 定義具體的控制要求，最後依據 Microsoft Cloud 的平台能力選擇適當的實作方式。這樣才能讓安全要求從治理層一路延伸到實際的平台設定與日常維運。

平台持續演進，控制架構仍可延續

雲端平台會持續演進，新的服務不斷推出，既有服務也會持續更新，因此實際採用的技術與設定方式可能隨著平台能力而改變。然而，許多安全管理的核心需求並不會因此消失，例如身分仍然需要受到管理、資料仍然需要受到保護、系統活動仍然需要具備可觀測性，高風險操作也仍然需要受到適當控管。

因此，安全控制基準的價值並不在於固定某一項服務或設定，而是在於建立一套可以延續的控制架構。當平台能力改變時，企業可以重新檢視控制的實作方式，但仍然可以沿用原本的安全領域、控制要求與管理方式。

對架構師而言，這也是理解 Microsoft Cloud Security Baseline 時比較重要的地方：平台服務會改變，但企業需要管理的安全問題與控制目標，可以透過一致的架構持續延續。

小結

Microsoft Cloud Security Baseline 並不是單純列出一份安全設定清單，而是先透過 Control Domains 將雲端平台的安全需求整理成不同的管理領域，再透過 Control ID 將各個領域進一步展開成具體的控制要求，最後對應到 Microsoft Cloud 所提供的平台能力。

這樣的架構，讓安全控制可以從較高層次的治理需求一路延伸到實際的平台實作，也讓不同團隊可以透過相同的控制架構進行規劃、建置、檢查與維護。

對架構師而言，真正需要理解的不是每一個 Control ID 的內容，而是 Control Domain、Control ID 與平台能力之間的關係。當安全領域、控制要求與平台實作建立清楚的對應關係後，安全控制才能真正進入雲端平台的架構設計與日常治理之中。