The storage key that ignores your RBAC
Azure storage account keys grant full access to everything in the account, never expire, and bypass Entra RBAC entirely. Here is why a single leaked key is a whole-account breach, and how to remove it.
You can have airtight RBAC and still lose every file in a storage account, because the account key does not answer to RBAC.
What it is
An Azure storage account has two account keys that grant full access to everything in it: all blobs, files, queues, and tables. Shared-key authentication bypasses Entra RBAC and conditional access. An attacker who can list the keys, through a role like Storage Account Contributor, a key leaked in code, or one pulled from Key Vault, reads or exfiltrates every object and can even mint SAS tokens from the key. This is T1552 (unsecured credentials) into T1530 (data from cloud storage).
Why it works
The key is not a user, so an RBAC deny assignment does not apply to it. The keys do not expire. One key is the whole account.
How to detect it
In the Azure Activity log, watch for ListStorageAccountKeys or key regeneration by a principal that does not normally do it. In the storage diagnostic logs, watch for shared-key data access from a new origin and bulk reads across containers.
The fix that holds
Disable shared-key access so the account requires Entra authentication. Apply least-privilege storage RBAC, restrict the account to a private endpoint or firewall, and prefer user-delegation SAS over account-key SAS. If a key is ever exposed, regenerate both keys, because there are two.
Practice it
We built a storage account-key abuse scenario in GraphLattice Range so teams learn why an RBAC deny does nothing here, and what containment actually looks like.