How to Audit Azure Storage Accounts for Public Access and Shared Keys

Retrospective: this article looks back at events from October 2022, written in 2026 with the benefit of hindsight.

Azure Storage accounts can be exposed through anonymous blob access, overly permissive shared keys and SAS tokens, or public network endpoints. Here is how to audit them.

Step 1: Inventory with Azure Resource Graph

Resources
| where type =~ "microsoft.storage/storageaccounts"
| project name, resourceGroup, subscriptionId,
    allowBlobPublicAccess = properties.allowBlobPublicAccess,
    allowSharedKeyAccess = properties.allowSharedKeyAccess,
    publicNetworkAccess = properties.publicNetworkAccess,
    minimumTlsVersion = properties.minimumTlsVersion

Step 2: Disable anonymous blob access

Set Allow Blob anonymous access to Disabled on every storage account unless it intentionally serves public content. For public content, prefer Azure Front Door or a CDN with a private origin.

Step 3: Disable shared key authorization

Shared keys grant full access and are hard to audit. Move applications to Entra ID authentication (managed identities with RBAC roles like Storage Blob Data Reader), then set Allow storage account key access to Disabled.

Step 4: Control SAS tokens

If you must use SAS, prefer user delegation SAS (signed with Entra ID credentials) and short expiry times. Configure a SAS expiration policy on storage accounts.

Step 5: Restrict network access

Use private endpoints or firewall rules, and set public network access to Disabled for internal data.

Step 6: Enforce with Azure Policy

Assign built-in policies to deny public blob access, require secure transfer, require minimum TLS 1.2 and audit shared key access.

Step 7: Monitor

Enable Defender for Storage and diagnostic logs.

Verify

Every storage account should show anonymous access disabled, with shared key and public network access disabled unless justified.