你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
采用策略驱动的规范措施
使用策略之前,你需要了解它们在 Azure 登陆区域引用实现中的使用位置以及原因。 本文将帮助你了解是否要阻止 DeployIfNotExists (DINE) 或修改策略在 Azure 环境中进行更改。
为何使用 DINE 和修改策略?
DINE 和修改策略是 Azure 登陆区域引用实现中的一部分。 它们可帮助你和组织确保登陆区域(也称为订阅)及其中的资源合规。 随着 Azure 环境的缩放,这些策略还消除了平台和登陆区域团队的操作负担。
例如,假设预配了新的登陆区域订阅,并放置在 "corp" 管理组中。 然后,DINE 和修改策略会针对登陆区域订阅执行以下操作:
- 启用 Microsoft Defender for Cloud。 配置 Defender for Cloud 导出到管理订阅中的中央 Log Analytics 工作区。
- 根据策略分配上配置的策略参数,为不同的受支持产品/服务启用 Defender for Cloud。
- 配置要发送到管理订阅中中央 Log Analytics 工作区的 Azure 活动日志。
- 配置要发送到管理订阅中中央 Log Analytics 工作区的所有资源的诊断设置。
- 为虚拟机 和 Azure 虚拟机规模集(包括 Azure Arc 已连接的服务器)部署 Azure Monitor 代理。 连接管理订阅中的中央 Log Analytics 工作区。
注意
你可随时或在部署 Azure 登陆区域引用实现期间禁用上述选项。
前面的列表显示了作为 Azure 登陆区域加速器的一部分分配的所有策略的子集。 有关可由 Azure 登陆区域引用实现分配的策略的完整列表,请参阅 Azure 登陆区域引用实现中包含的策略。
Azure 登陆区域 bicep 存储库是模块化的。 可以使用 ALZ 默认策略分配模块部署上述默认策略。
所有分配的策略都有助于你和登陆区域所有者保持合规。 不会通过 DINE 或修改策略部署任何实际工作负荷资源。 我们也不建议使用此方法。 有关详细信息,请参阅我们是否应该使用 Azure 策略部署工作负荷?。 只有辅助或支持资源或设置由这些 DINE 策略部署或配置。
Azure 登陆区域引用实现使用 DINE 策略来帮助你在 Azure 环境中实现策略驱动的治理。 但是,可能你无法使用 DINE 或修改策略,或者由于以下原因未准备好启用此类 Azure 策略效果:
- 法规合规性政策、标准或法律限制。
- 严格的变更控制流程,要求对 Azure 环境中每个操作进行人工审批。
- 缺乏专业知识、经验,不了解如何管理和使用 DINE 策略。
- 工作负荷应用程序团队在基础结构中定义所有工作负荷资源配置(包括辅助资源、支持资源和设置)的组织要求(IaC)。
如果适合前面的示例或类似方案,本文将帮助你了解如何采用 Azure 登陆区域概念体系结构并遵循其设计原则。 虽然最初不会使用某些策略,但可以选择在将来逐渐启用它们。 目标是帮助你实现策略驱动的治理。
重要
在整篇文章中,你将看到用于强制模式术语的两个可能值:
- Disabled 或 DoNotEnforce
- Enabled 或 Default
此 Azure 门户为强制模式使用 Disabled 和 Enabled。 Azure 资源管理器 (ARM) 模板和其他 API 接口对相同的选项使用 DoNotEnforce 和 Default。
有关详细信息,请参阅强制模式。
如果仍确定组织无法使用 DINE 或修改策略,本文介绍如何防止 (也称为禁用) 策略自动更改 Azure 环境。
对资源选择器的支持也适用于策略驱动的治理,以确保遵守保险箱部署做法(SDP)。 资源选择器根据资源位置、资源类型或资源是否具有位置等因素逐步推出策略分配的功能。 本文档中可以找到更多内容。
方法概述
下图总结了建议的分阶段方法:
- 将 强制模式 设置为
DoNotEnforce
策略分配:- 通过使用此功能,你可以修改分配的行为,以有效地成为仅审核策略,而无需修改基础策略定义。
- 如果愿意,此方法还允许通过使用修正任务对不符合的资源执行手动修正任务。
- 将强制模式设置为
Default
策略分配,以重新启用 DINE 策略分配在缩小范围上的自动修正:- 可以选择使用整个环境,例如沙盒管理组。
- 或者,可以使用非关键工作负荷订阅。
- 将强制模式设置为
Default
,以在整个 Azure 环境中对剩余的 DINE 策略进行策略分配。
由于法规合规性限制,某些客户永远不能超越阶段 1。 这不是问题,如有必要,支持保持此状态。 其他客户可以进入阶段 2 和阶段 3,以完全采用 DINE 和修改策略,以帮助其 Azure 环境进行策略驱动的治理。
注意
本文中概述的方案和方法不面向大多数客户,也不建议用于大多数客户。 在决定这些策略是否适合你的环境并需要这些策略之前,请查看为何使用 DINE 和修改策略部分。
阶段 1:禁用 DINE 和修改策略自动操作
分配策略时,默认情况下将应用策略定义中定义的效果。 建议保留策略定义。 例如,将策略分配效果保留为 DeployIfNotExists
。
无需更改策略定义或其效果,而是通过使用策略分配上的功能,以最小工作量影响此行为。
使用 Azure 门户将强制模式设置为 Disabled
此屏幕截图显示如何使用策略分配上的 Azure 门户将强制模式设置为已禁用。 Disabled 也称为 DoNotEnforce。
使用 ARM 模板将强制模式设置为 DoNotEnforce
此代码示例演示如何使用 ARM 模板在策略分配上将 enforcementMode
设置为 DoNotEnforce
。 DoNotEnforce
也称为 Disabled
。
{
"type": "Microsoft.Authorization/policyAssignments",
"apiVersion": "2019-09-01",
"name": "PolicyAssignmentName",
"location": "[deployment().location]",
"properties": {
"description": "PolicyAssignmentDescription",
"policyDefinitionId": "[parameters('policyDefinitionId')]",
"enforcementMode": "DoNotEnforce"
… // other properties removed for display purposes
}
}
通过使用强制模式,可以在 Azure 活动日志中查看策略对现有资源的影响,而无需启动策略或触发条目。 此方案通常称为“What If”,与安全部署做法相符。
即使强制模式设置为 DoNotEnforce
, 也可以手动触发修正任务。 可以修正特定的不相容资源。 还可以查看当强制模式设置为 Default
时,DINE 或修改策略将执行哪些操作。
重要
当强制模式设置为 DoNotEnforce
时,不会生成 Azure 活动日志中的条目。 如果要在创建不相容资源时收到通知,请考虑此因素。
永久保持阶段 1 状态
如方法概述部分所述,某些客户可能因为他们的要求需要长时间(甚至永久)保留在阶段 1 中。 此状态有效,客户可以在其中保留任意时间。
可能需要永久或长时间(例如年)保持此状态。 如果是这样,最好采用 AuditIfNotExists
(AINE) 策略效果和关联的定义,并将强制模式设置回 Default
。
注意
通过更改为使用 AINE 策略,并将强制模式设置为 Default
,仍可实现禁用 DINE 策略的相同目标。
从 DINE 更改为 AINE,并将强制模式设置回 Default
作为阶段 1 的长期或永久方法时,将获取策略符合性状态的 Azure 活动日志条目。 可以在整体平台管理操作中基于这些日志条目生成自动化工作流。
你将失去执行手动修正任务的能力。 与 DINE 策略不同,AINE 策略不执行任何自动或手动部署。
请记得更新策略定义,以接受和允许 AuditIfNotExists
策略分配效果。
下表总结了不同类型的策略效果和强制模式组合的选项和含义:
策略效果 | 强制模式 | 活动日志条目 | 修正操作 |
---|---|---|---|
DINE | Enabled 或 Default | 是 | 创建或资源更新后由平台触发的大规模修正。 如果在策略分配之前修改了从属资源或该资源已存在,则需要手动创建修正任务。 |
DINE | Disabled 或 DoNotEnforce | 否 | 需要手动创建修正任务。 |
修改 | Enabled 或 Default | 是 | 在创建或更新期间自动修正。 |
修改 | Disabled 或 DoNotEnforce | 否 | 需要手动创建修正任务。 |
拒绝 | Enabled 或 Default | 是 | 已拒绝创建或更新。 |
拒绝 | Disabled 或 DoNotEnforce | 否 | 允许创建或更新。 所需的手动修正。 |
Audit/AINE | Enabled 或 Default | 是 | 所需的手动修正。 |
Audit/AINE | Disabled 或 DoNotEnforce | 否 | 所需的手动修正。 |
注意
查看对 Azure 策略状态更改事件做出反应中的指南,以了解在计划基于策略状态事件构建自己的自动化时,使用 Azure 事件网格与 Azure Policy 集成是否提供了合适的方法。
阶段 2:在特定策略或缩减作用域上启用 DINE 和修改策略
在此阶段中,你将了解如何在策略分配上将强制模式设置为 Default
。
完成 阶段 1后,确定你想要在特定策略或缩减作用域上测试并试用 DINE 和修改策略的完全自动化功能。 需要使用沙盒管理组或非生产工作负荷订阅。
若要执行此过程,首先需要确定将用于测试并试用 DINE 和修改策略的全自动化功能的策略或缩减作用域。
下表显示了一些建议的作用域和策略示例:
要执行此操作... | 从这些范围中进行选择 | 要使用的示例策略 |
---|---|---|
- 测试 DINE/修改自动修正功能。 - 验证完成的部署过程和 CI/CD 管道(包括测试)是否可能会受到影响。 - 验证工作负荷可能如何受到影响。 |
- 沙盒订阅 - 沙盒管理组 - 非生产工作负荷登陆区域订阅 - 企业级 "canary" 环境 |
- 配置 Azure 活动日志以流式传输到指定的 Log Analytics 工作区。 - 部署 Defender for Cloud。 - 启用用于 VM 或虚拟机规模集的 Azure Monitor。 - 将诊断设置部署到 Azure 服务。 - 可能仅对计划内的特定服务启用。 |
你可能还决定在有限范围或一组资源上使用手动修正任务来测试这些策略对环境的影响。 有关如何创建修正任务的详细信息,请参阅 Azure 策略文档创建修正任务。
确定一个或多个策略,并将其分配到已减少的作用域后,下一步是分配策略并将强制模式设置为 Default
。 保留策略效果(例如 DeployIfNotExists
或 Modify
),就像所选的缩小作用域一样。
使用 Azure 门户将强制模式设置为 Enabled
此屏幕截图显示如何使用策略分配上的 Azure 门户将强制模式设置为 Enabled。 Enabled 也称为 Default。
使用 ARM 模板将强制模式设置为 Default
此代码示例演示如何使用 ARM 模板在策略分配上将 enforcementMode
设置为 Default
。 Default
也称为 Enabled
。
{
"type": "Microsoft.Authorization/policyAssignments",
"apiVersion": "2019-09-01",
"name": "PolicyAssignmentName",
"location": "[deployment().location]",
"properties": {
"description": "PolicyAssignmentDescription",
"policyDefinitionId": "[parameters('policyDefinitionId')]",
"enforcementMode": "Default"
… // other properties removed for display purposes
}
}
测试
此阶段中的最后一步是执行所需的测试。 你需要验证 DINE 或修改策略是否可能会受到影响,以及对工作负荷、代码、工具和过程进行了更改。
执行多个测试来捕获工作负荷的整个生命周期。 你需要确保完全了解 DINE 或修改策略进行的更改。
测试的一些示例包括:
- 初始部署工作负荷。
- 将代码/应用程序部署到工作负荷。
- 第 2 天操作和工作负荷管理。
- 取消工作负荷。
阶段 3:在任何位置启用 DINE 和修改策略
在此阶段中,你将了解如何在策略分配上将强制模式设置为 Default
。
我们假设在阶段 2 结束时进行的测试已成功通过。 或者,你可能已经感到满意,你现在了解了 DINE 或修改策略是如何与工作负荷交互的。 现在,你可以在 Azure 环境的其余部分扩展 DINE 和修改策略的使用。
若要继续,请执行与阶段 2 中的步骤类似的步骤。 这一次,请在整个 Azure 环境的所有 DINE和修改策略上将强制模式设置为 Default
。
下面是在此阶段中执行的步骤的高级概述:
- 删除专门用于 阶段 2 期间测试的分配。
- 在 Azure 环境中,浏览每个 DINE 和修改策略分配,并将强制模式设置为
Default
。 阶段 2 中的示例演示了此过程。 - 按照创建修正任务中的指南,为不符合的现有资源创建修正任务。 如果新资源与策略规则和存在条件匹配,则会自动对其进行修正。
即使在阶段 3 中,我们也建议你在 Azure 环境中将所有 DINE 和修改策略的强制模式设置为 Default
,此选项仍然是可选的。 你可以基于每个策略进行此选择,以满足你的需求和要求。
高级策略管理
若要大规模管理 Azure Policy,请考虑实施 企业策略即代码(EPAC) 来管理策略。 EPAC 提供使用 IaC 的有状态管理体验。 它通常适用于要求复杂的大型策略管理方案。