什么是 Azure Policy？

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

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

可以使用 Azure Policy 强制执行的一些有用的治理作包括：

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

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

Azure Policy 通过将 Azure 中资源的属性与业务规则进行比较，来评估这些资源。 以 JSON 格式描述的这些业务规则称为策略定义。 为了简化管理，可以将多个业务规则组合在一起，形成 策略计划，也称为 policySet。

形成业务规则后，策略定义或计划将分配给 Azure 支持的任何资源范围。 例如， 管理组、订阅、 资源组或单个资源。 分配应用于该分配的资源管理器作用域内的所有资源。 必要时可以排除子范围。 有关详细信息，请参阅 Azure Policy 中的作用域。

Azure Policy 使用 JSON 格式来形成评估用以确定资源是否合规的逻辑。 定义包括元数据和策略规则。 定义的规则可以使用函数、参数、逻辑运算符、条件和属性别名，以精确匹配您想要的方案。 策略规则确定要评估分配范围内的哪些资源。

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

• 在具有策略分配的范围中创建或更新资源。
• 某个范围被指派了新的策略或项目。
• 更新了已分配到某个范围的策略或项目。
• 每 24 小时发生一次的标准符合性评估周期。

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

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

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

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

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

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 在两个资源提供程序中具有多个称为“操作”的权限：

• Microsoft.Authorization
• Microsoft.PolicyInsights

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

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

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

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

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

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

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

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

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

• 建议创建并分配计划定义（即使从单个策略定义开始）。 此方法使你以后能够向计划添加策略定义，而无需增加要管理的分配数。

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

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

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

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

这些对象包括策略定义、计划定义和分配。

在 Azure Policy 中创建和实施策略的过程从创建策略定义开始。 每个策略定义都有强制实施的条件。 并且，在满足条件时将出现定义的效果。

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

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

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

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

若要了解有关策略定义结构的详细信息，请查看 Azure Policy 定义结构基础知识。

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

创建策略定义时定义参数。 参数的定义包括参数名称和可选值。 例如，可以为标题为“位置”的策略定义一个参数。 然后，可在分配策略时赋予其不同的值，如“chinanorth2”或“chinaeast2”。

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

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

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

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

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

例如，在以下方案中，你有一个计划定义 initiativeC，其中策略定义 policyA 和 policyB 需要不同类型的参数：

定义 initiativeC 的计划参数时，有三个选项：

• 使用此计划中的策略定义的参数：在此示例中， allowedLocations 并 allowedSingleLocation 成为 initiativeC 的计划参数。
• 将策略定义的参数值设置在此方案定义中。 在此示例中，可以提供 policyA 参数 allowedLocations 和 policyBallowedSingleLocation 的位置列表。 在分配该倡议时，您也可以提供数值。
• 分配此计划时，提供可供使用的值列表选项。 在分配此计划时，从计划内的策略定义继承的参数只能具有此提供列表中的值。

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

若要了解有关计划定义结构的详细信息，请查看 Azure Policy 计划定义结构。

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

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

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

在评估资源时，策略分配始终使用其所分配的定义或举措的最新状态。 如果分配的策略定义已更改，则评估时，该定义的所有现有分配都使用更新的逻辑。

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

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

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

现在，你已大致了解 Azure Policy 和一些关键概念，请使用以下链接了解有关该服务的详细信息。

• Azure Policy 术语表。
• Azure Policy 定义结构基础知识。
• 快速入门：创建策略分配以使用 Azure 门户标识不合规的资源。