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.
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.
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 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: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?
Suggested solution to the issue
Adding a check for the presence of
publicNetworkAccess=Disabled
would resolve this.If policy is Guest Configuration - details about target node