Storage accounts should prevent shared key access

What does the recommendation "Storage accounts should prevent shared key access" check?

Flags any storage account where the 'allowSharedKeyAccess' property is null or true, meaning requests can still be authorised with the two account access keys (Shared Key) or with a service SAS token signed by those keys. The property is unset by default and behaves as enabled until you explicitly write false, which is why so many accounts trip this control. It inspects only the account-level authorisation setting: it does not rotate or revoke the keys, does not tell you whether any client still depends on them, and says nothing about network firewall rules, infrastructure encryption or anonymous blob access, each of which is a separate recommendation. A pass here means Shared Key is provably off, not that the account is fully hardened.

Why does "Storage accounts should prevent shared key access" matter?

Account access keys are two long-lived, all-or-nothing secrets that grant full data-plane control over every container, file share, queue and table in the account. Unlike Microsoft Entra ID, they carry no per-user identity, no conditional access, no multi-factor enforcement and no granular RBAC, so a single key leaked in a config file, source repository, log line or connection string hands an attacker total read and write access with no audit trail tying any action to a person. Keys are also rarely rotated in practice, so the exposure window after a leak is often measured in years. Setting 'allowSharedKeyAccess' to false makes Azure Storage reject every Shared Key request and every key-signed SAS request, so only Entra-authorised callers succeed. Access then becomes attributable to an identity, governed by conditional access, and revocable in seconds by removing a role assignment rather than re-keying every dependent application at once.

How do I fix "Storage accounts should prevent shared key access"?

1. Audit first: run 'az storage account update --name <account> --resource-group <rg> --allow-shared-key-access false' only after confirming no application, SAS token or tool still relies on the keys, since flipping it breaks key-based callers immediately.
2. Migrate clients to Microsoft Entra ID by assigning data-plane roles such as Storage Blob Data Contributor to the managing identity or service principal, then re-test before disabling Shared Key.
3. Enforce it at scale by assigning the built-in policy by its exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Storage accounts should prevent shared key access'].name" -o tsv); az policy assignment create --name no-shared-key --policy "$pid" --scope <scope>. Bake 'allowSharedKeyAccess: false' into your Bicep or Terraform storage module so new accounts ship locked down.

# 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"