azure-security-benchmark

Microsoft Cloud Security Benchmark（MCSB）

Microsoft Cloud Security Benchmark（MCSB，Azure Security Benchmark 的后继者）是 Microsoft 官方制定的云安全最佳实践规范，其中的控制项映射到 CIS、NIST SP 800-53、PCI DSS 和 ISO 27001，并由 Microsoft Defender for Cloud 原生监控。MCSB 是 Defender for Cloud 中的默认计划——你已经在按此标准接受评分。

何时使用

当用户需要一套受认可且与框架映射的云安全基线、需要将合规义务转化为具体的 Azure 控制措施，或想要确定从哪些 Defender for Cloud 建议入手时，请使用此技能。

以下情况不要使用此技能：

• Defender for Cloud 的具体修复工作（使用 defender-for-cloud-hardening）
• Azure Policy 编写详情（使用 azure-policy）
• 特定工作负载的威胁建模（使用 threat-modelling）

首先选择合适的 MCSB 控制域

MCSB 有 12 个控制域。不要试图并行解决所有问题——请按风险 + 依赖关系选择：

优先级	域	排序原因	典型的首要行动
P0	身份管理 + 特权访问	身份是新的边界；管理员账号遭入侵 = 游戏结束	强制启用 MFA，通过 PIM 移除常驻的全局管理员权限
P0	日志记录与威胁检测	没有可见性就无法响应	在订阅上启用诊断设置 + Sentinel/Defender
P1	网络安全	限制被入侵身份造成的影响范围	NSG 默认拒绝，为 PaaS 使用专用终结点
P1	数据保护	加密、密钥管理、分类	为核心数据使用客户管理的密钥，应用敏感度标签
P1	资产管理	看不到就无法保护	标记策略 + 资源清单
P2	安全态势与漏洞管理	持续改进闭环	接入 Defender for Servers，每周审查安全分数
P2	终结点安全 + 备份与恢复	弹性基线	Defender for Endpoint + Azure Backup 和不可变保管库
P2	事件响应	流程成熟度	编写运行手册 + 使用 Defender XDR / Sentinel 开展桌面演练
P3	DevOps 安全	将控制前移	使用 GitHub Advanced Security，或使用带有 Defender for DevOps 的 Azure DevOps
P3	治理与策略	确保其他领域持续有效	Azure Policy + 管理组结构

经验法则： 对于成熟的租户，MCSB 安全分数达到 65-75% 是现实的工作目标；>85% 通常意味着你正在审计并不适用于工作负载的建议。在追求 100% 之前先进行验证。

方法

1. 确认 MCSB 是当前基线 — 在 Defender for Cloud → Regulatory compliance 中， MCSB 默认已启用，但租户可能已将其禁用。如果未启用，请重新启用。 验证：Regulatory compliance 仪表板显示“Microsoft cloud security benchmark”为 当前启用的标准，并显示当前通过／失败百分比。
2. 建立 Secure Score 基线 — 记录每个订阅和每个控制域的当前分数。 这是你要提升的指标；没有基线，就无法向领导层证明进展。 验证：开始修复前，已截图或导出每个订阅的 Secure Score。
3. 将 MCSB 映射到你必须遵循的框架 — 不要把 CIS、NIST、ISO、PCI 当作彼此独立的工作流。使用 MCSB 作为规范实施方案，并通过各框架的 映射来证明合规性。将相当于 4 次审计的工作量减少到 1 次。 验证：Regulatory compliance 仪表板显示你必须遵循的框架与 MCSB 并列， 且可查看重叠部分。
4. 根据上方的优先级表进行分类 — 先处理所有订阅中的 P0 域。 在每个域内，按Secure Score 影响（降序）和 受影响资源数（降序）对建议排序。对大多数团队来说，每个域的前 5 项就是本季度的工作。
5. 使用服务基线确定实施细节 — MCSB 控制项较为抽象 （“启用传输中加密”）。各服务的安全基线会将其转换为 具体的 Azure 配置（例如，App Service：TLS 1.2 最低版本，启用仅 HTTPS）。设计修复方案前，务必先阅读 服务基线。 验证：已部署的资源通过 Defender for Cloud 中的服务基线检查。
6. 使用 Azure Policy 强制执行 — 仅有建议无法防止回归。将 每项已修复的控制项先设为Audit 模式的策略并运行 2 周，然后再改为 Deny 或 DeployIfNotExists。这样才能防止后续部署拉低你的分数。 验证：违反策略的测试部署会被阻止（Deny）或自动修复 （DeployIfNotExists）。
7. 管理计划 — 为每个 MCSB 控制域指定负责人。在安全委员会每月 审查 Secure Score。临近合规审计时，每季度核对一次框架映射。

护栏

• MCSB 是基线，不是工作负载威胁模型。 Secure Score 达到 100% 并不意味着 你的应用程序安全——这只表示你的平台配置符合默认要求。请结合 threat-modelling 评估工作负载特定风险。
• Secure Score 是方向性指标，不是绝对标准。 某些建议并不适用于所有 工作负载（例如，对于没有 SQL 的租户，“启用 Microsoft Defender for SQL”就无关紧要）。 请使用“不适用”流程，而不是忽略这些建议。
• 建议会影响成本。 启用 Defender 计划、客户管理的密钥和 不可变备份保管库会产生实际的 Azure 费用。大规模启用前先进行成本测算。
• 不要在生产环境中依赖 Quick Fix。 Defender for Cloud 的自动修复 Quick Fix 很适合开发／测试环境；在生产环境中，应先检查底层的 Bicep／ARM 更改。
• 先映射，再修复。 如果未先完成框架映射就开始修复冲刺，下次审计人员到来时就会重复投入。
• 服务基线可能滞后于平台。 将基线视为可靠的默认标准，但也要查看 服务自身的“Security best practices”文档，了解更新的指导。

常见反模式

• “追求 100% 的安全分数。” 超过约 75-85% 后，收益会逐渐减少；团队会因审查不适用 的建议而精疲力竭。
• “将 MCSB 和 CIS 当作两个独立项目。” 工作量翻倍；MCSB 就是实施层， CIS 只是众多输出映射之一。
• “不做预算就启用所有 Defender 计划。” 下个月账单会让人措手不及，接着就会 手忙脚乱地禁用计划——这会拉低分数，也会损害项目的公信力。
• “只有建议，没有策略。” 今天修复，明天新部署就会导致问题复发。 策略才能让修复措施持续生效。
• “忽略不适用项。” 本应正式排除的建议会拉低分数，掩盖真正的差距。

示例提示词

• 将我的 Azure 控制映射到 Microsoft Cloud Security Benchmark (MCSB)。
• MCSB 如何与 CIS 和 NIST 控制对齐？
• 根据 MCSB 使用 Defender for Cloud 法规合规性仪表板。
• 我应该优先处理哪些 MCSB 控制域？
• 我的租户设定怎样的安全分数目标才切实可行？
• 使用 Azure Policy 强制执行 MCSB 控制。

Microsoft Learn

• MCSB 概述：https://learn.microsoft.com/security/benchmark/azure/overview
• 简介与控制：https://learn.microsoft.com/security/benchmark/azure/introduction
• 服务安全基线：https://learn.microsoft.com/security/benchmark/azure/security-baselines-overview
• 法规合规性仪表板：https://learn.microsoft.com/azure/defender-for-cloud/regulatory-compliance-dashboard
• Defender for Cloud 中的安全分数：https://learn.microsoft.com/azure/defender-for-cloud/secure-score-security-controls
• 快速修复：https://learn.microsoft.com/azure/defender-for-cloud/implement-security-recommendations