Azure SQL PaaS和Azure策略交互

有人知道如何通过策略限制添加到SQL防火墙规则的IP地址吗

我已经尝试了一段时间，我的政策如下。。。我什么都试过了——有什么我忽略的吗

    {
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.SQL/servers/firewallRules"
      },
      {
        "Not": {
          "anyOf": [
            {
              "field": "Microsoft.Sql/servers/firewallRules/startIpAddress",
              "in": "[parameters('StartIP')]"
            },
            {
              "field": "Microsoft.Sql/servers/firewallRules/endIpAddress",
              "in": "[parameters('EndIP')]"
            }
          ]
        }
      }
    ]
  },
  "then": {
    "effect": "Deny"
  }
}

但是当我更新防火墙规则时，不管策略分配中提供了什么，它总是抛出一个策略错误

例如，如果我的参数都是“0.0.0.0；8.8.8.8”，我会认为我可以启用Azure服务和8.8.8.8，但事实并非如此-我只是因为策略错误而得到相同的拒绝

如果我只使用0.0.0.0作为分配的参数，我可以配置新的SQL Server，但如果删除了它，我就无法配置新的SQL Server，这让我相信，在某种程度上，该策略是有效的

---

我知道我可以完成整个vnet路由，并使用NSG完成几乎相同的事情；然而，我的组织不想走这条路，而是希望在政策上这样做。

我没有足够的声誉来评论你的问题。但是，在门户中输入分配参数时，请确保小心使用这些参数。如果按指定输入“0.0.0.0；8.8.8.8.8”，则按原样接受字符串。前导空格和尾随空格将搞乱比较

---

您可以使用powershell cmdlet（或类似的Azure CLI命令）检查分配中的确切参数值。为了更方便地使用cmdlet，分配的完整ID将显示在门户中分配的compliance视图中。

啊，不幸的是，我只是在上面添加了空白以进行格式化。在实际参数中，缺少此项。实际上，我已经完全去掉了参数，只是在NotIn块中使用了硬编码值：`“NotIn”：[“0.0.0.0”、“8.8.8.8”、“8.8.9.9”]`使用了相同的旧结果。感谢您的回复。事实证明，Azure门户使用了一种技术上不受支持的方式来修改SQL server防火墙规则，这会导致策略无法正确评估（它正在执行集合PUT）。您应该看到，在使用Powershell、CLI或普通REST PUT时，您的策略的评估是正确的。不幸的是，我不能说什么时候门户实现会改变，或者策略评估会改变来解决这个问题。