Microsoft AZ-500: 安全态势管理和治理 — 学习指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

属于 Microsoft Azure Security Engineer Associate AZ-500 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 中的安全态势管理与治理是一门持续评估、确定优先级并强制执行配置的学科，旨在降低跨订阅和跨云的风险，同时保持可证明的合规性。有效的设计融合了用于态势可见性和保护的 Microsoft Defender for Cloud、用于预防性和纠正性护栏的 Azure Policy、用于可扩展继承的登陆区域治理，以及用于证明控制措施的审计级日志记录。其运营目标是实现可辩护的风险降低：决策由暴露面和影响驱动，通过代码强制执行，通过设计继承，并通过不可变日志来证明。

Microsoft Defender for Cloud：架构、计划和建议

Defender for Cloud (MDC) 从 Azure、混合云和多云环境中提取信号，将它们关联为安全分数、建议和警报，并能协调修复。应在管理组 (MG) 根级别进行设计，以便计划和策略能够继承到所有订阅；仅使用订阅来限定例外范围。对于多云环境，应在租户根级别（或一个专用的“安全”订阅）部署适用于 AWS 和 GCP 的原生 MDC 连接器，使用最低权限帐户和集中式自动预配来标准化代理部署和数据收集。

计划的选择由风险驱动：

• Defender for Servers：计划 1 提供漏洞评估和基础强化；计划 2 增加了 Microsoft Defender for Endpoint (MDE)、即时 (JIT) VM 访问、威胁和行为分析以及文件完整性监控。对暴露于互联网或承载特权的宿主机使用计划 2；对低暴露风险的服务器池使用计划 1。
• Defender for Storage：检测 Blob、文件和 ADLS Gen2 上的异常访问和恶意软件。按帐户启用，并将扫描目标对准高风险容器（例如，公共入口），以管理成本，同时覆盖入口点。
• Defender for SQL：对于 Azure SQL，启用威胁检测和漏洞评估，并检测基线偏差；对于计算机上的 SQL（包括已启用 Arc 的），则增加了基于代理的保护。在生产数据库上广泛启用；建立正常模式的基线以减少噪音。
• Defender for Containers：通过镜像漏洞扫描（ACR 和运行时）、Kubernetes 审计分析和运行时威胁检测来保护 AKS 和已启用 Arc 的 Kubernetes。通过 Azure Policy 附加组件强制执行 Kubernetes 策略 (Gatekeeper/OPA)。集成 CI/CD 扫描，在部署前阻止严重 CVE。
• Defender for Key Vault：检测异常的机密访问和数据泄露模式。使用 Azure RBAC 进行保管库管理，并使用数据平面访问策略（或 RBAC 数据操作）以实现最低权限的机密操作。
• Defender for DNS：检测基于 DNS 的数据泄露和命令与控制。优先部署在具有互联网出口的辐射 VNet 上；无需代理。
• Defender for DevOps：连接 Azure DevOps 和 GitHub 组织，以评估代码仓库、机密、IaC 错误配置以及管道的强化情况。对拉取请求中的高严重性错误配置使用阻止策略，以实现风险降低的左移。

安全建议统一了计划的发现结果和 Azure Policy 的评估结果。通过以下方式将其运营化：

• 在 MG 范围启用计划的自动预配。
• 将“高严重性、暴露于互联网”的建议视为带有 SLO 的变更控制工作项。
• 将治理例外记录为带有到期时间和理由的策略豁免。

安全分数、合规性与工作流自动化

安全分数将“控制措施”（相关安全要求的组合）聚合为一个标准化的百分比。每个控制措施都有一定的分数，这些分数会分配到其“改进操作”中。分数影响反映了风险降低的潜力和受影响资源的范围。按以下方式确定优先级：

• 每单位工作的最高潜在分数影响（快速制胜：例如，为所有者启用 MFA，限制存储的公共访问）。
• 攻击面暴露（公共端点、特权身份、薄弱的网络边界）。
• 映射到相同操作的法规义务（最大化合规性提升）。

使用带有修复指南、快速修复和 Logic App 自动化的改进操作。通过带有到期时间的“无法修复”或“通过设计缓解”的豁免来跟踪残留风险，以强制定期重新验证。

MDC 中的法规合规性将配置和建议映射到标准（例如，Azure Security Benchmark、CIS、NIST）。在 MG 范围选择所需的标准；避免每个订阅的配置漂移。将合规性仪表板视为策略即代码报告：每个绿色的控制措施都应能追溯到一个策略、计划或自动化配置。对于需要流程证据的控制措施族（例如，事件响应），链接工作簿可视化图表和工单 ID 以支持审计。

工作流自动化将态势与行动联系起来。典型模式：

• 触发器：业务关键型订阅上的建议变为不正常 → 操作：开启一个 P1 工单，通知 SecOps，并自动创建一个修复任务。
• 触发器：生产资源上出现新的高严重性警报 → 操作：隔离端点 (MDE)，隔离存储对象，或通过策略修复禁用公共访问。

策略驱动的治理与登陆区域

Azure Policy 是用于应对云漂移的预防性和纠正性护栏系统。关键要素：

• 定义：包含条件和效果的规则。常见效果包括 Deny、Audit、Append、Modify、DeployIfNotExists、AuditIfNotExists 和 Disabled。对不可协商的护栏使用 Deny（例如，禁止在网卡上使用公共 IP）。使用 DeployIfNotExists 自动安装所需的代理或扩展（例如，反恶意软件或 MDE）。
• 计划：一组经过精心策划的策略定义，已参数化以便于一致地分配（例如，Azure Security Benchmark 计划）。
• 分配：首先将范围限定在管理组，然后是订阅或资源组以进行有针对性的覆盖。在监控后，为硬性强制策略启用“强制模式”。
• 豁免：使用 Waiver（已接受风险）或 Mitigated（有补偿性控制）类别。始终设置过期时间以确保重新评估。
• 修复任务：DeployIfNotExists 和 Modify 需要修复任务来配置现有资源。将策略分配的托管标识授予目标范围的 Contributor 权限（并根据需要授予数据平面权限）。

强制在 Windows VM 上安装反恶意软件扩展的策略框架示例：

{
  "properties": {
    "displayName": "Deploy antimalware on Windows VMs",
    "policyType": "Custom",
    "mode": "Indexed",
    "parameters": {},
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "type", "equals": "Microsoft.Compute/virtualMachines" },
          { "field": "Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration", "exists": "true" }
        ]
      },
      "then": {
        "effect": "DeployIfNotExists",
        "details": {
          "type": "Microsoft.Compute/virtualMachines/extensions",
          "name": "IaaSAntimalware",
          "roleDefinitionIds": ["/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"],
          "deploymentScope": "resourceGroup",
          "existenceCondition": { "field": "name", "equals": "IaaSAntimalware" },
          "deployment": { "properties": { "mode": "incremental", "template": { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "resources": [] } } }
        }
      }
    }
  }
}

登陆区域治理用于组织继承和职责分离：

• 管理组：构建清晰的层次结构（租户根 → 平台 → 公司/在线 → 环境，如生产/非生产）。在管理组级别分配计划和 RBAC，以最大化继承并最小化每个订阅的漂移。发现特权角色并将其载入 PIM；配置 PIM 需要全局管理员权限。
• 订阅组织：按环境和工作负载的关键性进行分离，以隔离爆炸半径和预算。使用原型（例如，“关键任务 AKS”、“数据平台”），并预先分配计划和 RBAC。
• 标记：标准化必需的标记（Owner、CostCenter、DataSensitivity、Environment），并通过 Modify/Append 强制执行以实现规范化；当生产环境中缺少必需标记时，拒绝资源创建。
• 资源锁：CanNotDelete 用于保护关键的共享服务；ReadOnly 用于防止任何 PUT 操作。谨慎使用，且仅在策略强化之后使用。请注意，对虚拟机或其资源组施加 ReadOnly 锁会阻止启动已解除分配的虚拟机并阻碍配置更改。

对于遗留的蓝图需求，采用“策略即代码”方法，结合使用 ARM/Bicep、模板规格和计划分配，以大规模实现类似蓝图的一致性部署。

安全清单、云应用、数据治理和审计

大规模的清单盘点与合规性管理可利用 Azure Resource Graph (ARG) 和 Policy 合规性报告。ARG 查询可为数百万资源提供近乎实时的状态视图：

securityresources
| where type =~ 'microsoft.security/assessments'
| where properties.status.code == 'Unhealthy'
| summarize unhealthy=count() by tostring(properties.displayName)
| order by unhealthy desc

将资源状态与标签进行关联，以便按数据敏感度进行分类：

resources
| where type == 'microsoft.compute/virtualmachines'
| project id, name, resourceGroup, subscriptionId, dataSensitivity = tostring(tags['DataSensitivity'])
| join kind=leftouter (
  securityresources
  | where type =~ 'microsoft.security/assessments'
  | where properties.status.code == 'Unhealthy'
  | summarize issues=count() by tolower(tostring(properties.resourceDetails.Id))
) on $left.id == $right['tolower_tostring_properties_resourceDetails_Id']
| project name, dataSensitivity, issues = coalesce(issues, 0)
| order by issues desc

Defender for Cloud Apps (MDCA) 用于治理 SaaS 风险：

• 应用发现：通过 Cloud Discovery 引入防火墙/代理日志，或与 Defender for Endpoint 集成以实现基于端点的发现。按风险评分和使用情况对应用进行分类；标记为“已批准”/“未批准”，以驱动条件访问和代理阻止策略。
• 会话控制：使用 Conditional Access App Control 代理敏感操作的会话。应用实时策略来阻止下载、监控上传、编辑内容或为有风险的会话或非托管设备添加水印。
• 治理操作：在 Microsoft 365 中隔离或标记文件，撤销 OAuth 应用许可，移除外部共享，暂停高风险用户，并通知应用所有者。自动化定期强制执行以防止配置漂移。

Microsoft Purview 将治理范围扩展到数据层面：

• 数据地图与扫描：注册并扫描 Azure Storage、SQL、Synapse 和多云存储，以发现资产和数据血缘。使用内置和自定义分类器进行分类。
• 敏感度标签与保护：应用带有加密和使用权限的标签；根据内容和上下文自动标记。在 Microsoft 365 中强制执行基于标签的访问，并与 DLP 集成以防止数据外泄。
• 策略对齐：将 Purview 敏感度映射到标签（例如 DataSensitivity），并通过 Azure Policy 驱动补偿性控制（例如，要求“高度机密”存储使用 Private Endpoints）。

审计跟踪必须是防篡改且完整的：

• Azure Activity Log：记录订阅范围内的控制平面操作。通过诊断设置将其流式传输到 Log Analytics 并归档到 Storage。将长期副本保留在订阅之外的中央“Security-Logs”订阅中，以最大限度地减少内部威胁。
• 资源诊断设置：为关键提供程序（Key Vault、Storage、SQL、AKS、Network Security Groups）启用，以捕获数据平面和服务日志。路由到 Log Analytics 用于检测，路由到 Storage 用于保留。
• 日志的不可变存储：使用具有基于时间的保留策略或法定保留（WORM）的 Blob Storage。启用 allowProtectedAppendWritesAll，以便在强制执行不可变性的同时，诊断服务可以继续追加日志。配置生命周期策略以控制成本，但绝不在规定的保留期内删除。这为满足法规证据和事件取证要求提供了基础。

实践问题场景

全球零售商 Contoso 正在启用两个新的生产订阅，必须标准化安全状况，实现 Azure Security Benchmark 合规，并以不可变的方式保留日志七年，同时最大限度地减少运营摩擦。

1. 在管理组级别建立治理

• 创建一个 Prod 管理组，并将两个订阅置于其下。
• 理由：继承可确保一致的策略、Defender 计划和 RBAC，避免了各订阅的配置漂移，并减少了配置债。

2. 分配安全计划和 Defender for Cloud 计划

• 分配 Azure Security Benchmark 计划，并对存储和 SQL 的公共 IP 设置 Deny 策略；在 Prod 管理组级别启用 Defender for Servers Plan 2、Storage、SQL、Containers、Key Vault 和 DNS。
• 理由：各计划可解锁高级检测功能；该计划将控制措施编码为护栏。在管理组范围进行分配可保证统一的强制执行和一致的安全分数计算。

3. 实施策略驱动的自动化和豁免

• 添加 DeployIfNotExists 策略，以在需要时自动安装 MDE 和 Log Analytics 代理；为现有资源创建修复任务。对无法立即接入的旧版 VM 使用带有到期时间的豁免。
• 理由：DeployIfNotExists 将指导方针转化为实际行动；有时间限制的豁免在不阻塞关键运营的同时，保持了合规性推进的势头。

4. 配置由安全分数驱动的修复工作流

• 在 Defender for Cloud 中创建一个 Logic App 工作流，对于 Prod 环境中任何分数影响超过 3% 的改进建议项变为不健康状态时，自动创建 P1 工单，并自动通知资源所有者。
• 理由：分数影响将修复工作与可衡量的风险降低联系起来，而自动化则无需人工分类即可强制执行 SLO。

5. 集中管理具有不可变性的审计日志

• 为每个订阅的 Activity Log 和关键资源（Key Vault、Storage、SQL、AKS）创建诊断设置，将日志发送到一个中央 Log Analytics 工作区和一个配置了七年基于时间的保留策略并启用了 allowProtectedAppendWritesAll 的 Storage 帐户。
• 理由：集中化简化了检测和合规工作；不可变存储提供了审计和取证所需的不可否认性。

6. 治理 SaaS 使用和出口风险

• 将 Defender for Cloud Apps 连接到 Defender for Endpoint 以进行应用发现；标记未批准的高风险应用，并对访问已批准应用的非托管设备强制执行 Conditional Access App Control。
• 理由：减少影子 IT 风险，并强制执行实时会话控制，而不干扰受管设备的使用体验。

7. 通过 Purview 嵌入数据治理

• 在 Purview 中注册 Contoso 的 Storage 和 SQL 资产，运行扫描，并自动应用敏感度标签。将标签映射到一个 Environment 和 DataSensitivity 标签策略，该策略要求“高度机密”存储必须使用 Private Endpoints。
• 理由：数据感知策略可确保在发现敏感数据的地方自动应用网络强化措施，从而闭环连接数据治理与基础设施安全。

← 密钥管理、加密技术和证书 · 所有领域 · Microsoft Sentinel 和安全运营 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →