Microsoft AZ-900: 治理与合规性 — 学习指南

By Laurynas Brazys · 24 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Azure 中的治理通过一套分层的控制措施，使云的使用与业务、安全和法规要求保持一致：这些控制措施包括组织结构、策略、标准化部署、防止意外更改的保护以及持续审计。这些功能在 Azure Resource Manager 控制平面中原生运行，并且可以从单个订阅扩展到大型多租户环境。良好的治理可以减少偏差、强制执行一致性，并在不影响开发人员速度的情况下提供合规性证据。合规性依赖于强大的清单和变更历史记录。Azure 提供跨订阅资源的近实时可见性、规范性的法规映射以及用于定位和分类敏感信息的数据发现功能。最终形成一个可防御的云态势，其中标准一次性定义、自动强制执行、持续提供证据并进行大规模纠正。

Azure Policy：定义、计划、位置控制和修复

Azure Policy 定义了护栏，用于在创建/更新期间（以及此后定期）评估资源配置并强制执行所需状态。策略定义使用条件和效果来评估资源提供程序公开的资源属性。核心效果包括 Deny、Audit、Append、Modify、DeployIfNotExists、AuditIfNotExists 和 Disabled。策略可以在管理组、订阅、资源组或资源范围进行分配，继承机制确保更广泛的分配会向下传递，除非通过 notScopes 排除。计划（Initiative）将相关的策略定义组合成一个带有参数的包，以便进行一致、可重复的分配。例如，一个安全基线计划可以包含要求诊断设置、限制公共终结点、强制执行标记以及审计缺失备份的策略。分配该计划会通过一个操作应用所有包含的策略，并产生单一的合规性视图。“允许的位置” (Allowed locations) 内置策略限制了可以创建资源组和资源的位置，从而防止部署到未经批准的区域，并有助于满足数据驻留和主权要求。当创建请求指向一个禁止的区域时，Deny 效果会在操作到达资源提供程序之前将其阻止，从而确保严格的合规性。当发现偏差时，修复任务会大规模地使资源恢复合规。对于 DeployIfNotExists 和 Modify 策略，策略分配的托管标识用于重新配置不合规的资源（例如，在存储帐户上启用诊断设置或附加所需标记）。修复作业可以限定在很小的范围，也可以跨整个订阅运行，并且合规性结果会按策略和按资源显示，以供审计跟踪。

用途
- 策略定义：评估资源属性的单一规则
- 计划 (策略集)：带有共享参数的策略定义捆绑包
- 分配范围：管理组、订阅、资源组或资源
- 常见效果：Deny、Audit、Append、Modify、DeployIfNotExists、AuditIfNotExists
- 修复要求：分配时需要托管标识；适用于 Modify/DeployIfNotExists
用例
- 策略定义：强制执行 SKU、TLS、标记、专用终结点
- 计划 (策略集)：应用安全或治理基线
- 分配范围：通过继承和排除实现广泛强制执行
- 常见效果：硬性强制执行或仅提供证据的审计
- 修复要求：拥有足以更改目标资源的权限

Azure Blueprints：使用策略、RBAC、资源组和模板打包标准

Azure Blueprints 将治理构件打包，以便组织能够一致地创建合规的环境。蓝图定义可以包括策略分配、Azure 基于角色的访问控制 (RBAC) 分配、资源组定义以及用于预配标准基础架构的部署构件，例如 ARM 模板（包括 Bicep）。参数允许在保留单一版本化事实来源的同时，为每个分配进行定制。蓝图有助于将“必须存在什么以及谁能做什么”与工作负载代码分离开来。例如，一个基线蓝图可以创建分支资源组，将 Reader 角色分配给审计团队，将 Contributor 角色分配给平台团队，部署中心辐射型网络模板，并分配用于诊断和安全的计划。将蓝图分配给一个或多个订阅会按正确顺序应用所有构件并记录合规性状态。版本控制支持受控更新，构件锁定可以在部署后保护关键组件。

主要关注点
- Azure Policy：配置和合规性护栏
- ARM/Bicep 模板：声明式资源部署
- Azure Blueprints：跨订阅打包和治理标准
是否包含 RBAC
- Azure Policy：否（需单独分配）
- ARM/Bicep 模板：否（需单独分配）
- Azure Blueprints：是（角色分配作为构件）
是否包含策略
- Azure Policy：不适用
- ARM/Bicep 模板：否（可以部署策略资源，但不能分配）
- Azure Blueprints：是（策略分配作为构件）
是否创建资源组
- Azure Policy：可以要求/强制执行命名/标记
- ARM/Bicep 模板：可以部署到其中，或通过嵌套部署创建
- Azure Blueprints：是（将 RG 定义为蓝图的一部分构件）
典型用途
- Azure Policy：限制 SKU、强制执行诊断、标记
- ARM/Bicep 模板：预配 VNet、Key Vault、App Service
- Azure Blueprints：通过策略 + RBAC + 基础架构创建合规的登陆区域

组织和标准：管理组、订阅、资源组、命名和标记

Azure 的管理层次结构使治理能够规模化。管理组位于订阅之上，提供了一个应用策略和 RBAC 的位置，这些策略和 RBAC 会被所有子订阅继承。订阅定义了计费、服务配额以及大多数控件的安全边界。资源组用于容纳具有一致生命周期、权限和部署逻辑的资源；每个资源都只属于一个资源组和一个订阅。命名和标记标准将治理意图转化为操作上的清晰性。名称应在服务限制内编码资源类型缩写、工作负载、环境和区域（例如，kv-payroll-prod-eus2）。标记为跨资源的成本分摊、所有权、数据分类和自动化键添加业务上下文（例如，costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential）。具有 Modify 和 Append 效果的 Azure Policy 可强制执行标记的存在性和值模式，并且可以从资源组向资源继承标记。在此处保持一致性可以推动可靠的成本报告、访问审查和生命周期自动化。

管理组
- 用途：跨订阅进行规模化治理
- 常见用途：将策略、RBAC 和计划应用于业务部门或环境
- 可包含：子管理组和订阅
- 关键说明：最多 6 层深度（不包括根）；继承性向下流动
订阅
- 用途：计费和服务边界
- 常见用途：工作负载隔离、成本分离、配额管理
- 可包含：资源组和资源
- 关键说明：此处的策略/RBAC 分配会影响所有包含的资源组
资源组
- 用途：资源的生命周期和权限边界
- 常见用途：一同部署、更新和删除相关资源
- 可包含：资源
- 关键说明：资源只能存在于一个 RG 中；跨 RG/订阅的移动有特定于服务的限制

资源锁和防止意外删除

资源锁提供了防止意外更改的最后一道防线。锁应用于订阅、资源组或资源范围，并向下继承。存在两种锁类型：CanNotDelete 防止删除但允许读取和写入操作，而 ReadOnly 限制所有写入和删除操作（实际上只允许读取操作）。锁可以防止来自门户、CLI、PowerShell、ARM/Bicep 和第三方 IaC 工具的操作。在共享或关键基础设施上使用 CanNotDelete——例如虚拟网络、路由表、DNS 区域、生产环境的 Key Vaults——这样在阻止删除的同时可以继续进行维护。谨慎地对必须保持完全静态的项目使用 ReadOnly，例如已存档的存储帐户或法规证据容器；许多服务需要写入操作才能正常运行，在 ReadOnly 锁下会失败。只有具有足够权限的主体（例如，拥有 Microsoft.Authorization/locks/* 权限的 Owner）才能移除锁，并且移除锁本身是 Activity Log 中的一个可审计操作。

CanNotDelete
- 读取：允许
- 写入/更新：允许
- 删除：阻止
- 典型用例：保护 VNets、路由表、生产环境的 Key Vaults、关键 RG
- 注意事项：允许配置更改；在移除锁之前，删除操作会失败
ReadOnly
- 读取：允许
- 写入/更新：阻止
- 删除：阻止
- 典型用例：保护证据存储、存档存储、不可变配置
- 注意事项：许多服务在 ReadOnly 锁下会中断；更新和缩放操作被阻止

审计、盘点与法规合规性：Resource Graph、Activity Log、Defender for Cloud 和 Microsoft Purview

Azure Resource Graph 使用 Kusto 查询语言 (KQL) 在订阅和管理组级别提供快速、大规模的资源盘点和状态查询。它能够回答诸如哪些存储帐户缺少加密、哪些 VNet 暴露了公网 IP、以及哪些资源不符合策略等问题。查询结果可用于填充仪表板、同步 CMDB 以及驱动修复管道。当与 Cost Management 数据结合使用时，Resource Graph 还可以呈现策略合规性状态、标签分布和成本归因维度。Azure Activity Log 记录针对资源的控制平面操作，包括操作者、操作内容和操作时间，默认保留期为 90 天。可将 Activity Log 转发到 Log Analytics、Azure Storage 或 Event Hubs，以实现长期保留、关联分析和 SIEM 数据引入。变更历史分析可以精确定位配置漂移、支持事件响应并为审计提供证据。Microsoft Defender for Cloud 通过将评估结果映射到 Azure Security Benchmark、ISO/IEC 27001、NIST SP 800-53、PCI DSS 和 CIS 等标准，将技术层面的安全状态转化为法规合规视图。其“法规合规性”仪表板会显示各项控制措施的通过/失败状态、受影响的资源以及修复建议。启用自动预配功能可以在需要时集成代理和策略，而安全分数则提供了一个确定修复优先级的视角。Microsoft Purview 能够发现、分类和编目来自 Azure、多云和本地环境的数据源。通过扫描，它可以在 Azure Storage、SQL、Synapse、Power BI 等众多服务中识别敏感数据（例如，财务信息、个人身份信息 PII、健康信息），并应用内置或自定义的分类器。Purview 数据地图和数据目录提供了数据血缘、所有权和敏感度标签，这些信息与 Microsoft Information Protection 集成，从而能够根据法规要求制定数据丢失防护和访问策略决策。

主要功能
- Azure Resource Graph：大规模的资源盘点和状态查询
- Activity Log：控制平面操作的审计跟踪
- Defender for Cloud (法规合规性)：将安全状态映射到标准并确定修复优先级
- Microsoft Purview：数据发现、分类、编目、血缘分析
范围
- Azure Resource Graph：跨管理组/订阅
- Activity Log：租户级别，可路由到 LA/Storage/Event Hub
- Defender for Cloud (法规合规性)：订阅/租户级别，通过计划分配
- Microsoft Purview：跨数据源 (Azure、M365、本地、多云)
典型输出
- Azure Resource Graph：KQL 查询结果、仪表板、导出文件
- Activity Log：操作者/内容/时间、状态、错误代码
- Defender for Cloud (法规合规性)：合规控制状态、安全分数、建议
- Microsoft Purview：数据资产、敏感度标签、架构、血缘图

实际问题：在 Fabrikam 零售集团实现合规登陆区域的标准化

场景： Fabrikam 零售集团在北美和欧盟运营，有严格的数据驻留和 PCI DSS 合规义务。多个应用团队每月部署工作负载，而之前的临时部署导致了标签不一致、资源位于未经批准的区域以及共享网络资源被偶尔删除等问题。管理层要求建立标准化的、合规的登陆区域，提供持续的控制有效性证据，并能跨存储和分析平台发现敏感数据。

挑战： 设计并实施一种 Azure 治理方法，该方法能够强制执行区域限制，通过策略和 RBAC 实现部署标准化，防止核心基础设施被意外删除，维护资产清单和变更历史，针对 ISO 27001 和 PCI DSS 生成合规报告，并发现和分类敏感数据。

推荐方法：

创建一个管理组层次结构：/Fabrikam 根管理组；其下设子管理组 /Corp (共享服务)、/NA 和 /EU；在每个地理区域下，再添加 /Prod 和 /NonProd。将订阅移动到相应的管理组中。
在管理组级别创建策略计划：(a) 按地理位置设定的允许位置，(b) 带有 Modify/Append 效果的必需标签 (costCenter, owner, dataSensitivity)，(c) 强制核心服务将诊断设置发送到 Log Analytics，(d) 对 PaaS 服务实施 SKU 和公共网络访问限制。将计划分配给 /NA 和 /EU 管理组，并使用适合各区域的参数，同时通过 notScopes 排除紧急访问（break-glass）订阅。
为标准登陆区域打包一个蓝图：项目（artifacts）包括创建中心（hub）和应用资源组，RBAC 分配（为平台团队分配 Network Contributor 角色，为审计团队分配 Reader 角色），用于诊断和标签的策略分配，以及用于部署 vNET、对等互联、Key Vault 和 Log Analytics 的 ARM 模板。对蓝图进行版本控制，并将其分配给所有 Prod 和 NonProd 订阅。
应用资源锁：对中心 VNet、路由表、共享 DNS 区域和 Log Analytics 工作区应用 CanNotDelete 锁；对用于监管数据导出的归档存储账户应用 ReadOnly 锁。验证共享服务订阅的 Owner 角色在计划变更时，可以通过自有审批流程移除锁。
启用从所有订阅到中央 Log Analytics 工作区的活动日志导出，并归档到一个具有七年不可变（基于时间）保留策略的存储账户中。构建 Resource Graph 仪表板，用于按区域和 dataSensitivity 标签列出不合规资源、缺失标签的资源以及资产。
在整个租户中启用 Microsoft Defender for Cloud。选择 ISO/IEC 27001 和 PCI DSS 作为监管标准，打开自动预配功能，并审查建议。根据高严重性发现创建工作项，并跟踪每个订阅的安全分数改进情况。
在 /Corp 共享服务订阅中部署 Microsoft Purview。将 Azure SQL、Storage、Synapse 和 Power BI 注册为数据源。配置计划扫描，使用内置的敏感信息类型并对数据集进行分类。发布数据目录并分配数据所有者。导出发现的敏感度标签，为条件访问和 DLP 策略提供信息。

Azure 方法论依据： 该方法从管理组范围界定入手，使策略和 RBAC 能够可预测地继承，然后通过 Azure Policy 和策略计划强制执行核心控制，以在部署时防止不合规行为。蓝图将策略、RBAC、资源组和基础设施模板打包，以创建一致的登陆区域，同时允许按区域和环境进行参数化。资源锁可以保护关键共享服务免遭意外删除，同时在适当情况下不影响日常配置。集中式的活动日志保留和 Resource Graph 提供了可靠的资产清单和变更证据。Defender for Cloud 提供了实时的监管控制映射和优先的修复建议，而 Microsoft Purview 则发现和分类敏感数据，以支持 Fabrikam 整个分析资产中的 PCI DSS 和数据驻留控制。

← 成本管理与服务经济学 · 所有领域 · 监控、自动化与管理 →

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