Do not apply "* should restrict network access" and "* should have firewall enabled" to Private-Link Resources

[benjaminpieplow]

Details of the scenario you tried and the problem that is occurring

When deploying a resource in a Corporate-Connected landing zone, standard practice is to configure publicNetworkAccess=Disabled. This prevents the resource from communicating over the public endpoint. However, according to Configure Azure Storage firewalls and virtual networks,

The Azure Storage firewall provides access control for the public endpoint of your storage account.
This, as far as my testing was able to confirm, does not apply to connections made to the Private Link endpoint. Meaning, when a resource is deployed with publicNetworkAccess=Disabled, the presence of networkAcls.ipRules or state of networkAcls.defaultAction has no influence on the connectivity to the endpoint. This behavior appears to be mirrored across all resources using networkAcls.

The policy logic recommending the use of ACLs does not reflect this; specifically, it does not consider whether publicNetworkAccess has been disabled on the resource. This leads to Audit/Deny actions being taken on resources (up to and including Defender for Cloud recommendations) to enable the firewall on resources which would get no benefit from the configuration change. This can be found in the following policies:

• Azure Key Vault should have firewall enabled
• Configure key vaults to enable firewall
• [Preview]: Azure Key Vault Managed HSM should disable public network access
• [Preview]: Configure Azure Key Vault Managed HSM to disable public network access
• [Preview]: Container Registry should use a virtual network service endpoint
• Key Vault should use a virtual network service endpoint
• Storage accounts should restrict network access
• Storage accounts should restrict network access using virtual network rules
• Storage Accounts should restrict network access through network ACL bypass configuration only.

Some resources, for example CognitiveServices, have already adopted this change, see Azure AI Services resources should restrict network access.

Verbose logs showing the problem

Or the evaluation logic?

"if": {
  "allOf": [
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    {
      "anyOf": [
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        },
        {
          "count": {
            "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]"
          },
          "greaterOrEquals": 1
        }
      ]
    }
  ]
},

Suggested solution to the issue

Adding a check for the presence of publicNetworkAccess=Disabled would resolve this.

"if": {
  "allOf": [
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    {
      "anyOf": [
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        },
        {
          "count": {
            "field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]"
          },
          "greaterOrEquals": 1
        }
      ]
    },
    {
      "field": "Microsoft.Storage/storageAccounts/publicNetworkAccess",
      "notEquals": "Disabled"
    }
  ]
},

If policy is Guest Configuration - details about target node

[benjaminpieplow]

This could also be extended to "* should use private link" policies. For example, "Storage accounts should use private link" does not evaluate for a requirement for private link.