3.1.1. Storage Account Security Configuration and Firewall Rules
💡 First Principle: Every storage account ships with a powerful, account-wide credential — the shared key — that grants full access to everything in the account and, unlike a scoped RBAC role, can't be limited to specific containers or operations. Security configuration for storage is largely about moving away from that credential and narrowing what remains.
Core hardening steps include disabling shared key access where possible (forcing callers to Microsoft Entra ID + RBAC instead), requiring secure transfer (HTTPS-only), and enabling infrastructure encryption for defense in depth on top of the default encryption at rest. Shared Access Signature (SAS) tokens grant time-bound, scoped access without exposing the account key itself, but a SAS token is a bearer credential — anyone holding it can use it — so scope (which resources, which operations) and expiry matter enormously. Firewall rules restrict the account to specific IP ranges, selected virtual networks, or (tightest) exclusively private endpoints.
⚠️ Exam Trap: Issuing a new, tightly scoped SAS doesn't revoke a leaked one. Azure Storage doesn't track SAS tokens, so an ad hoc SAS stays valid until it expires. To kill a leaked service or account SAS, rotate the account key that signed it, which also breaks every other SAS signed with that key; a service SAS tied to a stored access policy can instead be revoked by deleting or changing that policy (an account SAS can't use one); a user delegation SAS is revoked by revoking the user delegation keys. Then re-issue narrowly scoped, short-lived tokens, preferably user delegation SAS.
Reflection Question: Why does disabling shared key access on a storage account force every existing connection-string-based application to be re-architected, and what Phase 2 concept would you reach for as the replacement?
