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: A SAS token generated with a far-future expiry date and broad permissions (read/write/delete across an entire container) is a common wrong-configuration scenario — the fix isn't usually "regenerate the account key" (that invalidates every SAS derived from it, including legitimate ones) but scoping and re-issuing the specific SAS with tighter permissions and a short expiry.
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?
