Azure storage account security: access keys, SAS tokens, and RBAC

At a glance

What this is: This article explains how Azure storage accounts use access keys, SAS tokens, and RBAC, and shows that unmanaged NHI controls can create persistent exposure.

Why it matters: It matters because IAM and NHI teams need to govern credentials, scope, and monitoring together, or storage access becomes harder to contain than the data it protects.

Context

Azure storage accounts are a common data access layer in cloud environments, but the governance problem is not storage capacity, it is how access is granted and revoked. In practice, access keys and SAS tokens behave like NHI credentials, so the security question becomes whether they are issued with least privilege and a usable lifecycle.

The article focuses on the gap between convenience and control. RBAC can reduce broad exposure, but storage accounts still depend on secrets management, token scope, expiration, and visibility to stop access from becoming persistent once credentials leak or permissions drift.

Key questions

Q: What fails when Azure storage accounts rely on long-lived access keys?

A: Long-lived access keys create standing access to the entire storage account, so a single leak can expose data until the key is rotated. Because the keys do not expire automatically, the failure is not only compromise but persistence. Teams need lifecycle control, not just secrecy, to keep the exposure window bounded.

Q: Why do SAS tokens still need governance if they are more scoped than access keys?

A: SAS tokens reduce blast radius only when their permissions, scope, and expiry are tightly controlled. If they are overpermissive or long-lived, they become distributed delegated access paths that are harder to track than one shared key. Governance must cover issuance, expiry, and revocation, not just token creation.

Q: What are the signs that storage account access has become too broad?

A: Warning signs include many unused or rarely reviewed tokens, shared keys that have not been rotated, and storage access that depends on exceptions rather than roles. If teams cannot quickly explain who can mint access, for how long, and for what resource, the account is likely overexposed.

Q: Should teams use RBAC or shared credentials for Azure storage governance?

A: RBAC should be the default because it gives clearer role-based control and reduces reliance on broad shared credentials. Shared access can still be necessary in limited cases, but it should be treated as an exception with tighter expiry, scope, and monitoring. The decision is about reducing credential sprawl, not replacing one control with another.

Technical breakdown

Access keys turn storage accounts into standing-credential targets

Azure storage account access keys are high-power credentials because they provide unrestricted access to the account rather than narrowly scoped permissions. They also do not expire on their own, which means revocation depends on manual or automated rotation. That makes them behave like classic long-lived NHI secrets: if they leak into logs, code, or a pipeline, the exposure continues until one of the paired keys is rotated and dependent tokens are invalidated. The real control problem is not only secrecy, but lifecycle discipline around issuance, rotation, and revocation.

Practical implication: treat storage account keys as standing NHI credentials and enforce rotation plus revocation workflows.

SAS tokens shift control from account access to scoped delegation

Shared Access Signature tokens are designed to narrow access by action, resource, expiry, and network constraints. That makes them safer than broad account keys only when they are issued with tight scope and short duration. But SAS tokens are still derived from an underlying access key, so their security inherits the strength of that key and the monitoring around it. Excessive permissions, long expirations, or token sprawl create a delegated access problem rather than a solved one, because the account can still be reached through many individually scoped entry points.

Practical implication: design SAS issuance as controlled delegation, not as a substitute for key governance.

RBAC reduces blast radius but does not replace secrets governance

Role-Based Access Control helps by assigning access through roles rather than by handing out broad shared credentials. In Azure storage, that is useful for service accounts and service principals because permissions become easier to review and separate. But RBAC does not eliminate the need to manage access keys, SAS tokens, and the systems that mint them. If teams rely on role assignment while leaving secret rotation, token expiry, and audit visibility weak, the account remains exposed through the credential layer even when the permission layer looks orderly.

Practical implication: pair RBAC with secret inventory and lifecycle controls, or the permission model will outpace the credential model.

Threat narrative

Attacker objective: The attacker wants durable access to storage data and the ability to manipulate or exfiltrate it without triggering timely revocation.

1. Entry begins when an access key is leaked or otherwise compromised, giving an attacker direct entry to the storage account.
2. Escalation occurs when the attacker uses that standing credential to generate additional SAS tokens or continue using the original key without immediate detection.
3. Impact follows when the attacker reads, changes, or deletes stored data while maintaining persistent access through the token and key layer.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Storage account security is really NHI governance wrapped around data access. Azure storage does not become safe because access is abstracted behind RBAC if the underlying credentials remain long-lived, overbroad, or invisible. Access keys and SAS tokens are NHI controls in practice, which means lifecycle, scope, and revocation are the real governance levers. Practitioners should treat storage access as an identity problem first and a storage problem second.

Ephemeral delegation only works when expiry and scope are enforced as policy, not preference. SAS tokens are often presented as the safer middle ground between shared keys and role-based access, but that safety depends on short lifetimes, narrow permissions, and bounded resource scope. Once tokens become reusable, long-lived, or easy to mint from a compromised key, the delegation model collapses into distributed standing access. Teams should stop assuming that tokenization alone reduces risk.

Secret visibility is the missing control that turns leakage into persistence. A leaked key is damaging, but a leaked key with no monitoring is what makes the problem systemic. Without contextual inventory and usage telemetry, organisations cannot distinguish legitimate token use from abuse or see when a credential has escaped its intended lifecycle. The practical conclusion is that storage account governance must include detection, not just provisioning.

Azure storage exposes the identity blind spot between permission design and credential reality. RBAC can describe who should access a storage account, but it does not govern how access keys are distributed, how SAS tokens are generated, or when they stop being valid. That gap matters because many cloud programmes measure access policy maturity while leaving secret management as an operational afterthought. Practitioners need to align the permission model with the credential model, or their control story will not survive an audit or an incident.

Long-lived storage credentials create identity blast radius, not just exposure. When one access key can unlock an entire storage account, the compromise boundary is the account itself rather than a single action or object. That means blast radius is determined by credential design and token scope more than by the existence of a role assignment. Teams should minimise the number of credentials that can reach storage at all and narrow the reach of each one.

What this signals

Identity blast radius is the right way to think about Azure storage risk. The issue is not whether an account can be reached, but how much of the storage environment becomes reachable when a single key or token leaks. Programmes that measure only role assignment will miss the larger question of delegated credential reach.

RBAC does not close the secret-management gap. Storage governance still depends on rotation, scoped delegation, and visibility into who can mint or reuse credentials. If those controls sit outside the access model, the environment may look orderly while remaining operationally fragile.

For practitioners

• Enforce short-lived SAS issuance Set a default expiry window for SAS tokens, restrict permissions to the minimum required actions, and limit tokens to specific resources and trusted network paths.
• Rotate access keys as a lifecycle control Maintain a rotation schedule for key1 and key2, invalidate dependent tokens during rotation, and verify that rotation actually removes usable access rather than just replacing one secret with another.
• Inventory every storage credential path Track which service accounts, principals, keys, and token generators can reach each storage account so you can see where standing access still exists.
• Move shared access toward RBAC Reduce reliance on broad shared access where RBAC can enforce finer-grained permissions, and reserve direct credentials for narrowly governed use cases only.

Key takeaways

• Azure storage accounts expose a classic NHI problem: broad credentials can grant far more access than teams intend.
• The main risks are standing access through access keys, overpermissive SAS tokens, and weak monitoring of delegated access.
• Practitioners need to align RBAC, token expiry, and key rotation so the credential layer does not undermine the permission layer.

Key terms

• Access Key: An access key is a broad secret that grants direct access to an Azure storage account. It is typically long-lived and must be rotated manually or through automation because it does not expire on its own. In governance terms, it behaves like standing non-human privilege.
• SAS Token: A Shared Access Signature token is a scoped credential that limits access to specific storage actions, resources, and time windows. It can reduce blast radius compared with an account key, but only if its permissions, expiry, and issuance are controlled as lifecycle events rather than convenience artifacts.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.