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

At a glance

What this is: This is an analysis of Azure storage account access patterns, showing that access keys and SAS tokens create material NHI risk when rotation, scoping, and monitoring are weak.

Why it matters: It matters because IAM teams must govern storage access as a non-human identity problem, where standing secrets, token sprawl, and lifecycle controls determine blast radius across cloud programmes.

👉 Read Oasis Security's analysis of Azure storage account access keys and SAS tokens

Context

Azure storage accounts centralise blobs, file shares, queues, and tables behind credentials that can be reused at scale. In practice, that makes them a Non-Human Identity governance problem as much as a storage problem, because access often depends on keys and tokens rather than interactive user authentication.

The security gap is not storage itself, but the control model around access keys and SAS tokens. When those credentials are long-lived, over-scoped, or poorly monitored, they behave like persistent machine identities with broad blast radius, which is why storage account governance belongs in NHI lifecycle and secrets management programmes.

Key questions

Q: How should security teams govern Azure storage account secrets?

A: Security teams should treat Azure storage account secrets as lifecycle objects, not static configuration. That means inventorying access keys and SAS tokens, assigning ownership, enforcing expiry or rotation, and logging every issuance path. The goal is to make storage access observable, revocable, and limited to the minimum operational need.

Q: Why do storage account access keys create more risk than RBAC alone?

A: Access keys create more risk because they are broad, long-lived secrets that bypass the granular intent of RBAC. If an application or attacker gets a key, they can reach the whole storage account until the key is rotated. RBAC still matters, but it does not neutralize leaked credential exposure.

Q: What do teams get wrong about SAS tokens in Azure storage?

A: Teams often mistake SAS tokens for low-risk temporary access, then issue them with wide permissions or long expirations. That turns a scoped credential into a durable access path. Good governance requires tracking the token’s owner, purpose, expiry, and downstream reuse, not just generating it on demand.

Q: How do I know if storage access controls are actually working?

A: Look for short-lived credentials, clear ownership, low use of shared access, and a complete log of token issuance and rotation. If storage is reachable through secrets that nobody can confidently attribute, review, or revoke, the control model is failing even if the account is technically protected.

Technical breakdown

Access keys create standing privilege in Azure storage

Azure storage access keys are broad credentials that authorize full access to the account unless the key is rotated or disabled. Because there are typically two keys, operators can rotate one while keeping service continuity, but the governance burden remains high: each key is effectively a standing secret with no inherent expiry. That makes compromise especially damaging when keys are embedded in applications, scripts, or pipeline variables. The problem is not only leakage, but the persistence of trust after leakage, because access continues until the key is explicitly invalidated.

Practical implication: treat storage account keys as high-risk NHI secrets and enforce rotation, inventory, and exception handling.

SAS tokens narrow scope, but only if policy is tight

Shared Access Signature tokens improve granularity by limiting access by resource, action, time, and sometimes network conditions. In theory, that reduces blast radius compared with account keys. In practice, a long-lived or over-permissive SAS token can recreate the same risk profile as a leaked key, especially if it can mint additional access or is distributed through automation without tracking. The token is only safer when its permissions and lifetime are explicitly constrained and monitored as part of the identity lifecycle, not treated as a temporary convenience artifact.

Practical implication: use SAS token policy as a control boundary, then audit permissions, expiry, and issuance paths continuously.

RBAC helps, but it does not replace secret governance

Role-Based Access Control is relevant because it can reduce the need for shared access patterns, but RBAC does not eliminate the need to govern the identities that actually reach storage. Service principals, managed identities, and application credentials still need lifecycle controls, usage visibility, and revocation discipline. This is where teams often overestimate policy strength and underestimate credential reality. If the storage account can still be reached by a secret outside the role model, the access path remains exposed even when RBAC appears clean on paper.

Practical implication: pair RBAC with secret discovery, credential rotation, and usage monitoring for every storage-facing identity.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 in disguise. The article shows that Azure storage access depends on long-lived credentials, token scoping, and rotation discipline, which makes the control problem about identity lifecycle rather than data location. That aligns directly with OWASP-NHI and zero trust thinking: the resource is not the weak point, the credential is. Practitioners should treat storage access as governed machine identity.

Standing access keys are the real blast-radius multiplier. Access keys grant unrestricted access without granular scope or inherent expiry, which means any leakage creates a persistent trust problem until rotation occurs. This is the kind of credential design that expands compromise impact faster than most storage teams expect. The practical conclusion is that unmanaged standing secrets, not the storage service itself, define the exposure window.

SAS token sprawl creates a lifecycle gap, not just a permissions gap. The article highlights that SAS tokens can be precise, but precision collapses when tokens are over-scoped, long-lived, or issued without monitoring. That is a named failure mode: ephemeral credential trust debt. Once teams create many short-lived-looking tokens that are not actually governed as lifecycle objects, the environment accumulates invisible access paths. Practitioners should interpret token issuance as lifecycle governance, not merely access provisioning.

RBAC is necessary, but it does not answer who still holds secret-level access. The vendor’s guidance to favour RBAC over shared access is directionally correct, but the deeper lesson is that storage security fails when identity governance stops at authorization policy and ignores credential reality. A clean role model can coexist with leaked keys, unmanaged service principals, and untracked SAS issuance. Security teams should assume the credential layer can outlive the policy layer unless they govern both.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• That same survey found only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader governance lens, read Ultimate Guide to NHIs for the lifecycle controls that should frame storage-facing credentials as managed identities.

What this signals

Ephemeral credential trust debt: Azure storage teams often create the appearance of temporary access while accumulating durable risk through untracked SAS issuance, overlooked service principals, and slow key rotation. When credentials are easier to mint than to retire, identity governance becomes a hidden storage control plane issue, not just an access management task.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, the same structural weakness applies to storage accounts that still depend on long-lived keys. Teams should expect pressure to unify secret governance across humans, workloads, and AI-enabled automation.

Azure storage will keep exposing the gap between policy intent and credential reality unless organisations can tie every access path to an owner, expiry, and revocation workflow. That means aligning storage administration with NHI lifecycle management rather than treating keys and tokens as one-off infrastructure details.

For practitioners

• Inventory every storage-facing secret Map access keys, SAS tokens, service principals, and managed identities that can reach Azure storage accounts. Classify them by business owner, expiry, scope, and rotation method so you can see which credentials function as standing privilege.
• Shorten SAS token lifetimes and scopes Issue SAS tokens only for the minimum resource and action set required, and keep expirations short enough to limit reuse if a token is exposed. Add network and protocol restrictions where the workload allows it.
• Rotate storage access keys on a fixed cycle Use key1 and key2 rotation as an operational control, not an occasional response step. Validate that applications, scripts, and automation pipelines actually consume the replacement key before retiring the old one.
• Monitor SAS issuance and usage as identity events Log who generated each SAS token, what scope it carries, and where it is used. Review token creation and access patterns for anomalies that indicate hidden persistence or overly broad delegation.
• Reduce reliance on shared access paths Prefer RBAC where feasible, then remove unused service accounts and principals that can still authenticate to storage. This closes the gap between policy intent and actual credential exposure.

Key takeaways

• Azure storage accounts become an NHI governance problem when access depends on long-lived keys and untracked SAS tokens.
• The evidence in the article points to standing secrets, broad permissions, and weak visibility as the main sources of storage risk.
• Teams that want lower blast radius need ownership, expiry, and rotation discipline around every storage-facing credential.

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.
• Standing Privilege: Standing privilege is persistent access that remains valid until someone explicitly removes or rotates it. In storage environments, access keys and over-broad SAS tokens are common examples because they can outlive the business need that created them, expanding exposure if they are leaked or reused.
• Credential Lifecycle Governance: Credential lifecycle governance is the discipline of assigning, monitoring, rotating, and revoking secrets and non-human access paths from creation to retirement. For storage accounts, it means treating keys, tokens, and service identities as governed objects with owners, expiry, and audit trails.

Deepen your knowledge

Azure storage account governance and NHI lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for storage keys, SAS tokens, or service principals, it is worth exploring.

This post draws on content published by Oasis Security: What Are Storage Accounts And How To Secure Them? Read the original.