Notifications
Clear all
Topic starter
06/06/2026 2:05 am
TL;DR: Azure storage accounts rely on access keys, SAS tokens, and RBAC, but weak rotation, excessive permissions, and poor visibility can turn convenient access into persistent exposure, according to Oasis Security. The core issue is that storage security still depends on secrets governance, not just role assignment.
NHIMG editorial — based on content published by Oasis Security: What Are Storage Accounts And How To Secure Them?
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every storage-facing secret Map access keys, SAS tokens, service principals, and managed identities that can reach Azure storage accounts.
- 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.
- Rotate storage access keys on a fixed cycle Use key1 and key2 rotation as an operational control, not an occasional response step.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for disabling shared access where RBAC can replace it.
- Specific recommendations for configuring SAS token permissions, HTTPS-only access, IP restrictions, and short expiry periods.
- The vendor's workflow for key rotation and lifecycle management across Azure storage accounts.
- Contextual mapping and audit workflow details for storage-facing non-human identities.
👉 Read Oasis Security's analysis of Azure storage account access keys and SAS tokens →
Azure storage accounts and NHI risk: are your controls enough?
Explore further
06/06/2026 3:34 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Azure storage account security: access keys, SAS tokens, and RBAC
