通过Azure CLI分配Azure Security Benchmark政策时参数JSON怎么写

Azure Security Benchmark（ASB）属于Azure官方预置的政策倡议（Policy Set Definition），它的参数文件结构和单条独立政策的参数文件结构有明显区别，多数编写报错都是因为直接套用单条政策的参数格式导致的。

核心编写原则 #

• 绝对不要从零手写参数结构，第一步先拉取当前环境下目标ASB倡议的原生参数骨架：执行az policy set-definition show --name ASBID，把输出结果里的parameters字段结构完整复制出来，作为你参数文件的基础。
• 参数层级、键名必须和拉取到的原生结构完全对齐，Azure CLI对参数键的匹配是严格区分大小写、空格、特殊字符的，哪怕多打一个空格都会出现参数不识别的问题。
• 你需要调整的单条政策效果配置，本质是修改倡议参数结构里对应到该政策的效果类参数值，不需要深入嵌套到单条政策的规则定义层级。

标准文件结构示例 #

调整完效果参数的JSON文件大致结构如下，所有键名请以你实际拉取的ASB定义结构为准：

{
  "parameters": {
    // 对应ASB下各政策的效果配置，可设置为AuditIfNotExist/Audit/Disabled
    "unencryptedVmAuditEffect": {
      "value": "AuditIfNotExists"
    },
    "vmSizeRestrictionEffect": {
      "value": "Audit"
    },
    "sqlTransparentDataEncryptionEffect": {
      "value": "Disabled"
    },
    // 保留ASB内置的通用必填参数，不需要自定义的情况下可以留空值，避免参数缺失报错
    "defaultLogAnalyticsWorkspace": {
      "value": {
        "location": "",
        "workspaceId": "",
        "workspaceKey": ""
      }
    }
  }
}

高频踩坑说明 #

• 不要直接把单条政策的原生参数名放到顶层：ASB在封装内部嵌套的单条政策时，会把每个单条政策的参数做一层重命名，常见格式是[政策全称][参数名]，比如"Allowed resource types[effect]"，这类带方括号、空格的键名必须完全原样保留，不能自行简化命名。
• 即便你把某个依赖工作区的政策效果设为Disabled，也不要删掉对应的工作区参数，否则Azure CLI会判定参数缺失导致创建失败，只需要参数值填空字符串即可兼容。
• 参数文件里不要包含政策规则、定义范围这类非参数内容：分配层面的参数文件只需要传递键值对形式的参数值，不需要复写整个政策逻辑。

无风险校验方法 #

写完JSON文件后不要直接执行创建命令，可以加上--what-if参数做预校验：
az policy assignment create --what-if --name "Name" --display-name "Name" --scope /providers/Microsoft.Management/managementGroups/MyMG --policy-set-definition ASBID --params ".\my.parameters.json"
这个命令不会真正创建政策分配，只会校验参数格式、结构是否和目标政策定义匹配，根据输出的报错信息调整JSON即可，不需要反复做无效的创建尝试。

内容的提问来源于stack exchange，提问作者Shaun Satterthwaite