你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Policy 计划定义结构

使用计划可组合多个相关策略定义,以简化分配和管理,因为可将组作为单个项使用。 例如,可以将相关标记策略组合为单个计划。 将应用计划,而非单独分配每个策略。

使用 JSON 创建策略计划定义。 策略计划定义包含以下各项的元素:

下面的示例演示如何创建用于处理 costCenterproductName 这两个标记的计划。 它使用两个内置策略来应用默认标记值。

{
    "properties": {
        "displayName": "Billing Tags Policy",
        "policyType": "Custom",
        "description": "Specify cost Center tag and product name tag",
        "version" : "1.0.0",
        "metadata": {
            "version": "1.0.0",
            "category": "Tags"
        },
        "parameters": {
            "costCenterValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for Cost Center tag"
                },
                "defaultValue": "DefaultCostCenter"
            },
            "productNameValue": {
                "type": "String",
                "metadata": {
                    "description": "required value for product Name tag"
                },
                "defaultValue": "DefaultProduct"
            }
        },
        "policyDefinitions": [{
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "definitionVersion": "1.*.*"
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "costCenter"
                    },
                    "tagValue": {
                        "value": "[parameters('costCenterValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/1e30110a-5ceb-460c-a204-c1c3969c6d62",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            },
            {
                "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
                "parameters": {
                    "tagName": {
                        "value": "productName"
                    },
                    "tagValue": {
                        "value": "[parameters('productNameValue')]"
                    }
                }
            }
        ]
    }
}

Azure Policy 内置项和模式位于 Azure Policy 示例

Metadata

可选 metadata 属性存储关于策略计划定义的信息。 客户可在 metadata 中定义对其组织有用的任何属性和值。 但是,Azure Policy 和内置项使用一些常见属性。

常见元数据属性

  • version(字符串):跟踪有关策略计划定义的内容版本的详细信息。 对于内置对象,此元数据版本遵循内置对象的版本属性。 建议使用此元数据版本的版本属性。

  • category(字符串):确定在 Azure 门户中的哪个类别下显示策略定义。

    注意

    对于法规符合性计划,category 必须是“法规符合性”。

  • preview(布尔值):如果策略计划定义为“预览版”,则为 true 或 false 标志。

  • deprecated(布尔值):如果策略计划定义被标记为“已弃用”,则为 true 或 false 标志。

版本(预览版)

内置策略计划可以托管具有相同的 definitionID 的多个版本。 如果未指定版本号,则所有体验都将显示最新版本的定义。 若要查看内置的特定版本,它必须在 API、SDK 或 UI 中指定。 若要在分配中引用特定版本的定义,请参阅分配中的定义版本

Azure Policy 服务使用 versionpreviewdeprecated 属性,将变更的状态和级别传达给内置策略定义或计划。 version 的格式为:{Major}.{Minor}.{Patch}。 当策略定义处于预览状态时,后缀“preview”将追加到 version 属性,并被视为一个布尔值。 在一个策略定义被弃用时,使用 "deprecated": "true" 将弃用捕获为定义元数据中的布尔值。

  • 主要版本(例如:2.0.0):引入重大更改,如主要规则逻辑更改、移除参数、默认添加强制效果。
  • 次要版本(例如:2.1.0):引入诸如次要规则逻辑更改等更改、添加新参数允许的值、更改为角色定义 ID、添加或删除计划内的定义。
  • 补丁版本(例如:2.1.4):引入字符串或元数据更改和紧急安全方案(很少见)。

内置计划已进行版本控制,也可以在内置或自定义计划内引用内置策略定义的特定版本。 有关详细信息,请参阅“引用定义和版本”。

在预览版中,通过门户创建计划时,将无法为内置策略定义引用指定版本。 通过门户创建的自定义计划中的所有内置策略引用都默认为最新版本的策略定义。

有关 Azure Policy 版本控制内置项的方式的详细信息,请参阅“内置版本控制”。 若要详细了解策略“已弃用”或“处于预览状态”的含义,请参阅处于预览状态和已弃用的策略

参数

参数可减少策略定义的数量,有助于简化策略管理。 可以将参数想象成窗体上的字段 - nameaddresscitystate。 这些参数始终不变,但其值会基于窗体中的各填写内容变化。 构建策略计划时,参数同样适用。 通过在策略计划定义中包含参数,可以在包含的策略中重复使用该参数。

注意

一旦分配计划后,就不能再更改计划级别参数。 因此,建议在定义参数时设置 defaultValue。

参数属性

参数有下述可以在策略计划定义中使用的属性:

  • name:参数的名称。 由策略规则中的 parameters 部署函数使用。 有关详细信息,请参阅使用参数值
  • type:确定参数是否为“字符串”、“数组”、“对象”、“布尔值”、“整数”、“浮点数”或者“日期/时间”。
  • metadata:定义主要由 Azure 门户用来显示用户友好信息的子属性:
    • description:(可选)说明参数用途。 可以用来提供可接受值的示例。
    • displayName:在门户中显示的用于参数的友好名称。
    • strongType:(可选)通过门户分配策略定义时使用。 提供上下文感知列表。 有关详细信息,请参阅 strongType
  • defaultValue:(可选)设置分配的参数的值(如果值未给定)。
  • allowedValues:(可选)提供参数在分配过程中所接受值的数组。

例如,可以定义策略计划定义,以限制各种包含的策略定义中的资源位置。 allowedLocations 可以是该策略计划定义的一个参数。 然后,该参数可用于每个包含的策略定义,并在分配策略计划期间定义。

"parameters": {
    "init_allowedLocations": {
        "type": "array",
        "metadata": {
            "description": "The list of allowed locations for resources.",
            "displayName": "Allowed locations",
            "strongType": "location"
        },
        "defaultValue": [ "westus2" ],
        "allowedValues": [
            "eastus2",
            "westus2",
            "westus"
        ]
    }
}

将参数值传递到策略定义

声明要将哪些计划参数传递到计划定义的 policyDefinitions 数组中的哪些包含的策略定义。 尽管参数名称可以是相同的,但在计划中使用与策略定义中不同的名称可以简化代码以提升可读性。

例如,可以将之前定义的 init_allowedLocations 计划参数传递到多个包含的策略定义及其参数 sql_locations 和 vm_locations,如下所示 :

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

此示例引用 init_allowedLocations 参数,该参数已在参数属性中演示过。

strongType

metadata 属性中,可以使用 strongType 来提供 Azure 门户中的一个包含选项的多选列表。 strongType 可以是受支持的资源类型,也可以是允许值。 若要确定“资源类型”是否对“strongType”有效,请使用 Get-AzResourceProvider

支持部分不是由 Get-AzResourceProvider 返回的资源类型。 这些资源类型为:

  • Microsoft.RecoveryServices/vaults/backupPolicies

strongType 的非资源类型允许值有:

  • location
  • resourceTypes
  • storageSkus
  • vmSKUs
  • existingResourceGroups

策略定义

计划定义的 policyDefinitions 部分是一个数组,其中现有策略定义包含在该计划中。 如将参数值传递到策略定义中所述,此属性是将计划参数传递到策略定义的位置。

策略定义属性

每个表示策略定义的数组元素具有以下属性:

  • policyDefinitionId(字符串):要包含的自定义或内置策略定义的 ID。
  • policyDefinitionReferenceId(字符串):包含的策略定义的短名称。
  • parameters:(可选)用于将计划参数作为该策略定义中的属性传递到包含的策略定义的名称/值对。 有关详细信息,请参阅参数
  • definitionVersion:(可选)要引用的内置定义的版本。 如果未指定任何版本,则它将引用分配时的最新主版本,并自动引入任何次要更新。 有关详细信息,请参阅“定义版本
  • groupNames(字符串数组):(可选)策略定义所属的组。 有关详细信息,请参阅策略组

下面是 policyDefinitions 的一个示例,它有两个包含的策略定义,会向这两个策略定义分别传递相同的计划参数:

"policyDefinitions": [
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0ec8fc28-d5b7-4603-8fec-39044f00a92b",
        "policyDefinitionReferenceId": "allowedLocationsSQL",
        "definitionVersion": "1.2.*"
        "parameters": {
            "sql_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/aa09bd0f-aa5f-4343-b6ab-a33a6a6304f3",
        "policyDefinitionReferenceId": "allowedLocationsVMs",
        "parameters": {
            "vm_locations": {
                "value": "[parameters('init_allowedLocations')]"
            }
        }
    }
]

策略定义组

可对计划定义中的策略定义进行分组和分类。 Azure Policy 的法规符合性(预览版)功能使用此属性将定义分组到“控件”和“符合性域”中。 此信息在 policyDefinitionGroups“数组”属性中定义。 可以在 Microsoft 创建的“policyMetadata”对象中找到更多分组详细信息。 有关信息,请参阅元数据对象

策略定义组参数

policyDefinitionGroups 中的每个“数组”元素必须具有以下两个属性:

  • name(字符串)[必填]:“组”的短名称。 在“法规符合性”中,为“控件”的短名称。 此属性的值由 policyDefinitions 中的 groupNames 使用。

  • category(字符串):组所属的层次结构。 在“法规符合性”中,为控件的“符合性域”。

  • displayName(字符串):“组”或“控件”的易记名称。 由门户使用。

  • description(字符串):“组”或“控件”所涵盖内容的说明。

  • additionalMetadataId(字符串):包含有关“控件”和“符合性域”的其他详细信息的 policyMetadata 对象的位置。

    注意

    客户可能会指向现有的 policyMetadata 对象。 但是,这些对象为“只读”,且仅由 Microsoft 创建。

NIST 内置计划定义中的 policyDefinitionGroups 属性示例如下所示:

"policyDefinitionGroups": [
    {
        "name": "NIST_SP_800-53_R4_AC-1",
        "additionalMetadataId": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1"
    }
]

元数据对象

Microsoft 创建的法规符合性内置项包含有关每个控件的其他信息。 此信息:

  • 显示在 Azure 门户中“法规符合性”计划的“控件”概述中。
  • 通过 REST API 提供。 请参阅 Microsoft.PolicyInsights 资源提供程序和 policyMetadata 操作组
  • 通过 Azure CLI 提供。 请参阅 az policy metadata 命令。

重要

“法规符合性”的元数据对象为“只读”,不能由客户创建。

策略分组的元数据在 properties 节点中包含以下信息:

  • metadataId:与分组相关的“控件 ID”。
  • category(必填):“控件”所属的“符合性域”。
  • title(必填):“控件 ID”的易记名称。
  • owner(必填):标识负责 Azure 中控件的人员:“客户”、“Microsoft”、“共享”。
  • description:有关控件的其他信息。
  • requirements:有关实现控件责任的详细信息。
  • additionalContentUrl:有关控件的更多信息的链接。 此属性通常是在符合性标准中涵盖这个控件的文档部分的链接。

下面是“policyMetadata”对象的示例。 此示例元数据属于“NIST SP 800-53 R4 AC-1”控件。

{
  "properties": {
    "metadataId": "NIST SP 800-53 R4 AC-1",
    "category": "Access Control",
    "title": "Access Control Policy and Procedures",
    "owner": "Shared",
    "description": "**The organization:**    \na. Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:  \n1. An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and  \n2. Procedures to facilitate the implementation of the access control policy and associated access controls; and  \n
\nb. Reviews and updates the current:  \n1. Access control policy [Assignment: organization-defined frequency]; and  \n2. Access control procedures [Assignment: organization-defined frequency].",
    "requirements": "**a.**  The customer is responsible for developing, documenting, and disseminating access control policies and procedures. The customer access control policies and procedures address access to all customer-deployed resources and customer system access (e.g., access to customer-deployed virtual machines, access to customer-built applications).  \n**b.**  The customer is responsible for reviewing and updating access control policies and procedures in accordance with FedRAMP requirements.",
    "additionalContentUrl": "https://nvd.nist.gov/800-53/Rev4/control/AC-1"
  },
  "id": "/providers/Microsoft.PolicyInsights/policyMetadata/NIST_SP_800-53_R4_AC-1",
  "name": "NIST_SP_800-53_R4_AC-1",
  "type": "Microsoft.PolicyInsights/policyMetadata"
}

后续步骤