Access to storage accounts with firewall and virtual network configurations should be restricted

What does the recommendation "Access to storage accounts with firewall and virtual network configurations should be restricted" check?

Flags storage accounts whose firewall leaves the public endpoint open to every network. Specifically it checks that 'networkAcls.defaultAction' is set to 'Deny', so only explicitly allowed virtual network subnets, IP ranges or resource instances can reach the account. It looks at the firewall posture only: it does not check whether anonymous blob access is disabled, whether the public endpoint is switched off entirely via 'publicNetworkAccess', or whether a private endpoint exists. An account can still serve traffic over the internet here, just from a narrowed allow-list rather than from anywhere.

Why does "Access to storage accounts with firewall and virtual network configurations should be restricted" matter?

When the default action is 'Allow', the storage firewall is effectively off and the blob, file, queue and table endpoints answer requests from any IP on the planet. Authentication keys, SAS tokens and shared keys then become the only thing standing between an attacker and your data, so one leaked key or token grants access from any coffee-shop network. Restricting the firewall to known subnets and office IP ranges shrinks that exposure dramatically: a stolen credential is useless unless the request also originates from a trusted network, which turns a single-factor leak into a far harder two-condition attack and keeps casual internet scanning off the account entirely.

How do I fix "Access to storage accounts with firewall and virtual network configurations should be restricted"?

1. Add the networks that legitimately need access first, so you do not lock out running workloads: 'az storage account network-rule add --resource-group <rg> --account-name <name> --vnet-name <vnet> --subnet <subnet>' for VNet subnets and the same command with '--ip-address <cidr>' for office or NAT ranges.
2. Flip the firewall to deny by default once the allow-list is in place: 'az storage account update --resource-group <rg> --name <name> --default-action Deny --bypass AzureServices'. The '--bypass AzureServices' keeps trusted first-party services such as backup and Monitor working; drop it only if you have a reason to.
3. Enforce it everywhere by assigning the built-in audit policy. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Storage accounts should restrict network access'].name" -o tsv); az policy assignment create --name restrict-storage-network --policy "$pid" --scope /subscriptions/<sub-id>. In Bicep, set 'networkAcls: { defaultAction: 'Deny', bypass: 'AzureServices' }' on the account resource.

# Close the highest-impact storage exposure first: anonymous read AND plain HTTP.
for acct in $(az storage account list \
    --query "[?allowBlobPublicAccess].name" -o tsv); do
  az storage account update --name "$acct" \
    --allow-blob-public-access false \
    --https-only true \
    --min-tls-version TLS1_2
  echo "$acct: anonymous access disabled, secure transfer required, min TLS 1.2"
done

# Ratchet it shut: deny any future account that allows anonymous access.
az policy assignment create \
  --name deny-anon-blob \
  --policy 13e6c4f1-e83f-4b50-a677-2cf6e2b9c885 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"