Disable Azure Storage Shared Key only after every caller identifies itself

Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access.

Source fact: what Microsoft documents

Microsoft’s Shared Key prevention guide says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported.

The source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny.

What the source does not establish

Disabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS.

Applicability questions

• Which applications, scripts, users, managed identities, Azure services, and third parties call the account?
• Do they use account keys, account SAS, service SAS, user-delegation SAS, Entra OAuth, anonymous access, SFTP local users, or SMB identity?
• Does the account host Azure Files, and can each file-access and portal scenario use supported identity authorization?
• Which callers can migrate, which need a separate account, and which are vendor-blocked?
• Who can list account keys or change AllowSharedKeyAccess after enforcement?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Inventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation.
2. Use logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly.
3. Migrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate.
4. Separate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed.
5. Set AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration.

Verification and evidence

• Preserve caller inventory, authorization type, migration owner, RBAC assignments, exceptions, and approval.
• Query the account property and prove it returns false after enforcement.
• Demonstrate Entra-authorized test access succeeds while an account-key or service-SAS test is rejected.
• Monitor policy compliance and failed authorization after rollout; investigate any reenablement.

Official references

• Prevent Shared Key authorization for an Azure Storage account — Microsoft