什么是 Azure Policy？

Azure Policy 可帮助实施组织标准并大规模评估合规性。 Azure Policy 通过其合规性仪表板提供一个聚合视图来评估环境的整体状态，并允许用户按资源、按策略粒度向下钻取。 它还通过对现有资源的批量修正以及对新资源的自动修正，帮助资源符合规范。

Azure Policy 的常见用例包括实施监管来满足资源一致性、法规遵从性、安全性、成本和管理方面的要求。 Azure 环境中已经内置了这些常见用例的策略定义，帮助你入门。

具体而言，可以使用 Azure Policy 强制执行的一些有用的治理操作包括：

• 确保团队仅将 Azure 资源部署到允许的区域
• 强制对分类标记进行一致的应用
• 要求资源将诊断日志发送到 Log Analytics 工作区

所有 Azure Policy 数据和对象都进行了静态加密。 有关详细信息，请参阅 Azure 数据静态加密。

概述

Azure Policy 通过将 Azure 中资源的属性与业务规则进行比较，来评估这些资源。 以 JSON 格式描述的这些业务规则称为策略定义。 为了简化管理，可以组合多个业务规则来构成一个策略计划（有时称为“策略集”）。 构成业务规则后，策略定义或计划将分配到 Azure 支持的任何资源范围，例如管理组、订阅、资源组或单个资源。 分配应用于该分配的资源管理器作用域内的所有资源。 必要时可以排除子范围。 有关详细信息，请参阅 Azure Policy 中的作用域。

Azure Policy 使用 JSON 格式构成评估机制用来确定某个资源是否合规的逻辑。 定义包括元数据和策略规则。 定义的规则可以使用与所需方案完全匹配的函数、参数、逻辑运算符、条件和属性别名。 策略规则确定要评估分配范围内的哪些资源。

了解评估结果

资源将在资源生命周期、策略分配生命周期内的特定时间进行评估，并接受日常进行的合规性评估。 出现以下时机或事件时，就会对资源进行评估：

• 在具有策略分配的范围中创建或更新资源。
• 最近已将策略或计划分配到某个范围。
• 更新了已分配到某个范围的策略或计划。
• 在标准合规性评估周期内（每 24 小时发生一次）。

有关何时以及如何进行策略评估的详细信息，请参阅评估触发器。

控制对评估的响应

处理不合规资源的业务规则根据组织的不同而有很大的不同。 下面以示例方式说明了组织希望平台如何对不合规资源进行响应：

• 拒绝资源更改
• 记录对资源的更改
• 在更改之前改变资源
• 在更改之后改变资源
• 部署相关的合规资源
• 阻止对资源执行的操作

Azure Policy 通过应用效果来实现这其中的每种业务响应方式。 效果在策略定义的“策略规则”部分进行设置。

修正不符合资源

尽管这些效果主要是在创建或更新资源时影响资源，但 Azure Policy 还支持处理现有的不合规资源，而无需改变该资源。 若要详细了解如何使现有资源合规，请参阅修正资源。

入门

Azure Policy 和 Azure RBAC

Azure Policy 和 Azure 基于角色的访问控制 (Azure RBAC) 之间存在一些主要区别。 Azure Policy 通过检查资源管理器中显示的资源属性和某些资源提供程序的属性来评估状态。 Azure Policy 确保资源状态符合业务规则，而不考虑更改是谁做出的或者谁有权做出更改。 通过 DenyAction 效果实施的 Azure Policy 还可以阻止对资源执行某些操作。 某些 Azure Policy 资源（如策略定义、计划定义和分配）对所有用户可见。 此设计提供的透明度使所有用户和服务都能了解其环境中设置了何种策略规则。

Azure RBAC 重点关注如何管理不同范围的用户操作。 如果需要根据用户信息控制某项操作，则 Azure RBAC 是可以使用的适当工具。 即使个人有权执行操作，但如果结果是不合规的资源，Azure Policy 也仍会阻止创建或更新操作。

Azure RBAC 和 Azure Policy 的组合在 Azure 中提供了全范围控制。

Azure Policy 中的 Azure RBAC 权限

在两个资源提供程序中，Azure Policy 有几个称为操作的权限：

• Microsoft.Authorization
• Microsoft.PolicyInsights

许多内置角色可授予对 Azure Policy 资源的权限。 “资源策略参与者”角色包括大多数 Azure Policy 操作。 “所有者”具有完全权限。 “参与者”和“读取者”都有权访问所有 Azure Policy 读取操作。

“参与者”可以触发资源修正，但无法创建或更新定义或分配。 需要“用户访问管理员”以授予 deployIfNotExists 或 modify 分配所需权限的托管标识 。

如果没有任何内置角色具有所需的权限，可创建自定义角色。

Azure Policy 操作可能对 Azure 环境产生重大影响。 只应分配执行任务所需的最小权限集，不应向不需要这些权限的用户授予它们。

Azure Policy 涵盖的资源

尽管可在管理组级别分配策略，但只会评估订阅或资源组级别的资源。

对于某些资源提供程序（例如来宾配置、Azure Kubernetes 服务和 Azure 密钥保管库），可以使用一个更深度的集成来管理设置和对象。 有关详细信息，请转到资源提供程序模式。

管理策略的建议

请记住以下几个要点和提示：

• 从 audit 或 auditIfNotExist 效果而非强制实施（deny、modify、deployIfNotExist）效果开始，以跟踪策略定义对环境中资源的影响。 如果有用于自动缩放应用程序的脚本，那么设置强制实施效果可能会影响此类已经执行的自动化任务。

• 请在创建定义和分配时考虑组织的层次结构。 我们建议在更高级别创建定义，例如管理组或订阅级别。 然后，在下一子级别创建分配。 如果在管理组中创建定义，则可以将分配范围缩小到该管理组中的订阅或资源组。

• 建议创建并分配计划定义（即使从单个策略定义开始）。 这样，便可在以后向计划添加策略定义，而无需增加要管理的分配数。

  • 例如，假设你创建了策略定义 policyDefA 并将其添加到计划定义 initiativeDefC。 如果之后创建了另一个策略定义 policyDefB，其目标类似于 policyDefA，则可在 initiativeDefC 下添加它并一起跟踪它们。

  • 创建计划分配后，添加到该计划中的策略定义也将成为该计划分配的一部分。

  • 评估计划分配后，还会评估计划内的所有策略。 如果需要单独评估某个策略，最好不要将其包含在计划中。

• 将 Azure Policy 资源作为代码进行管理，并手动审核策略定义、计划和分配的更改。 有关建议的模式和工具的详细信息，请参阅将 Azure Policy 作为代码工作流设计。

Azure Policy 对象

策略定义

若要在 Azure Policy 中创建并实施策略，请先创建策略定义。 每种策略定义在其特定的条件下将被强制执行。 并且，在满足条件时将出现定义的效果。

在 Azure Policy 中，我们将提供一些默认可供使用的内置策略。 例如：

• 允许的存储帐户 SKU（拒绝）：确定正在部署的存储帐户是否在 SKU 大小集内。 其效果是拒绝所有不符合定义的 SKU 大小集的存储帐户。
• 允许的资源类型（拒绝）：定义可以部署的资源类型。 其效果是拒绝所有不属于此定义列表的资源。
• 允许的位置（拒绝）：限制新资源的可用位置。 其效果是用于强制执行异地符合性要求。
• 允许的虚拟机 SKU（拒绝）：指定可以部署的虚拟机 SKU 集。
• 将标记添加到资源（修改）：如果部署请求未指定，则应用所需的标记及其默认值。
• 不允许的资源类型（拒绝）：禁止部署资源类型的列表。

若要实现这些策略定义（内置定义和自定义定义），需要将其分配出去。 可通过 Azure 门户、PowerShell 或 Azure CLI 来分配上述任意策略。

策略评估采用多种不同的操作，例如策略分配或策略更新。 有关完整列表，请参阅策略评估触发器。

若要了解有关策略定义结构的详细信息，请查看策略定义结构。

策略参数通过减少必须创建的策略定义数量来帮助简化策略管理。 在创建策略定义时可定义参数，以使其更为通用。 然后就可以为不同方案重复使用该策略定义。 要执行此操作，请在分配策略定义时传入不同的值。 例如，为订阅指定一组位置。

在创建策略定义时定义参数。 在定义参数后，会为它指定一个名称，并且可选择为其提供一个值。 例如，可以为标题为“位置”的策略定义一个参数。 然后，可在分配策略时赋予其不同的值，如“chinanorth2”或“chinaeast2”。

有关策略参数的详细信息，请参阅定义结构 - 参数。

计划定义

计划定义是策略定义的集合，专为实现一个单一的总体目标而量身定制。 计划定义可以简化管理和分配策略定义。 它们通过将一组策略组合为一个单独的项来实现简化。 例如，可以创建一个名为“在 Microsoft Defender for Cloud 中启用监视”的计划，目标是监视 Microsoft Defender for Cloud 实例中的所有可用安全建议。

在此计划中，将具有特定策略定义，例如：

• 监视 Microsoft Defender for Cloud 中未加密的 SQL 数据库 - 用于监视未加密的 SQL 数据库和服务器。
• 监视 Microsoft Defender for Cloud 中的操作系统漏洞 - 用于监视不满足配置基线的服务器。
• 监视 Microsoft Defender for Cloud 中缺失的终结点保护 - 用于监视不具备已安装终结点保护代理的服务器。

类似于策略参数，计划参数通过减少冗余来帮助简化计划管理。 计划参数是计划内的策略定义正在使用的参数。

例如，假设出现这样一种情况，有一个带有两个策略定义（policyA 和 policyB，每个都需要不同类型的参数）的计划定义 - initiativeC：

策略	参数的名称	参数的类型	注意
policyA	allowedLocations	array	此参数要求将值设置为字符串列表，因为参数类型已定义为数组
policyB	allowedSingleLocation	string	此参数要求将值设置为一个字词，因为参数类型已定义为字符串

在此情况下，定义 initiativeC 的计划参数时，有三个选项可供选择：

• 使用此计划中的策略定义参数：在此示例中，allowedLocations 和 allowedSingleLocation 为 initiativeC 的计划参数 。
• 向此计划定义中策略定义的参数提供值。 在此示例中，可以向 policyA 的参数 - allowedLocations 和 policyB 的参数 - allowedSingleLocation 提供位置列表。 此外，也可在分配此计划时提供值。
• 分配此计划时，提供可供使用的值列表选项。 在分配此计划时，从计划内的策略定义继承的参数只能具有此提供列表中的值。

在计划定义中创建值选项时，无法在计划分配期间输入其他值，因为它不属于列表。

若要详细了解计划定义结构，请查看计划定义结构。

分配

分配是指已指定特定范围的策略定义或计划。 此作用域的范围是从管理组到单个资源。 术语“范围”指定义分配到的所有资源、资源组、订阅或管理组。 分配由所有子资源继承。 此设计意味着应用到某个资源组的定义也会应用到该资源组中的资源。 但是，可以从分配中排除子范围。

例如，可以在订阅范围分配一个阻止创建网络资源的定义。 可以排除订阅中用于网络基础结构的资源组。 然后可以向信任的用户授予此网络资源组的访问权限，包括创建网络资源。

另举一例：你可能想要在管理组级别分配资源类型允许列表定义， 然后为子管理组或者甚至直接为订阅分配更宽松的策略（以允许更多资源类型）。 但是，此示例无法实现，因为 Azure Policy 是显式拒绝系统。 你不需要那样做，只需要从管理组级别分配中排除子管理组或订阅， 然后为子管理组或订阅级别分配更宽松的定义。 如果任何分配导致资源被拒绝，则允许该资源的唯一方法是修改拒绝分配。

在评估资源时，策略分配始终使用为其分配的定义或计划的最新状态。 如果已分配的策略定义发生变化，则在评估时，该定义的所有现有分配都将使用更新后的逻辑。

有关通过门户设置分配的详细信息，请参阅创建策略分配以识别 Azure 环境中的不合规资源。 还可以使用 PowerShell 和 Azure CLI 的步骤。 有关分配结构的信息，请参阅分配结构。

Azure Policy 对象的最大计数

Azure Policy 的每个对象类型都有一个最大计数。 对于定义，“范围”条目是指管理组或订阅。 对于分配和例外情况，“范围”条目是指管理组、订阅、资源组或单个资源。

其中	对象	最大计数
作用域	策略定义	500
作用域	计划定义	200
租户	计划定义	2,500
范围	策略或计划分配	200
范围	豁免	1000
策略定义	参数	20
计划定义	策略	1000
计划定义	参数	400
策略或计划分配	排除项 (notScopes)	400
策略规则	嵌套式条件语句	512
修正任务	资源	50,000
策略定义、计划或分配请求正文	字节	1,048,576

策略规则对条件的数量及其复杂性有更多的限制。 有关详细信息，请转到策略规则限制。

后续步骤

现在，你已大致了解 Azure Policy 以及一些关键概念，下面是建议的后续步骤：

• 查看策略定义结构。
• 使用门户分配策略定义。