5.1 Storage Account Security Fundamentals

Why Storage Security Dominates SC-500 Weighting

Secure storage, databases, and networking is the heaviest SC-500 domain (25–30%). Under that domain, Microsoft explicitly measures implement security for storage accounts: account configuration, firewalls, Defender for Storage, and access policies. This section covers the fundamentals—authentication model, encryption, transport security, public access, immutability, and soft delete—that every hardened account needs before you layer network ACLs or threat detection.

A storage account is the control boundary for Blobs (including Data Lake Storage Gen2), Files, Queues, and Tables. Misconfiguration here is a common path to data exfiltration: a leaked account key, open public blob container, or HTTP-only client can undermine every identity control you built with Entra and Key Vault.

---

Shared Key vs Microsoft Entra ID Authorization

Azure Storage supports two primary authorization models for data-plane requests (who can read/write blobs, files, queues, tables):

Shared Key realities

When a storage account is created, Azure generates two 512-bit account access keys. Either key can authorize Shared Key requests and can sign account SAS and service SAS tokens. Anyone who can list keys (Owner, Contributor, Storage Account Key Operator Service Role, or custom roles with Microsoft.Storage/storageAccounts/listkeys/action) effectively owns the data plane.

Risks examiners expect you to recite:

• Keys are long-lived secrets—rotation is manual or Key Vault–orchestrated, not identity lifecycle.
• Regenerating a key invalidates all account/service SAS signed with that key (user-delegation SAS is unaffected).
• Keys bypass Conditional Access–style identity controls unless Shared Key is disabled.
• Embedding keys in apps, pipelines, or git is a classic breach pattern.

Microsoft recommendation: Use Entra ID with managed identities for blob, queue, and table data whenever possible. For Azure Files SMB, prefer identity-based authentication (Kerberos / Entra). When temporary delegated access is required without a full proxy, prefer a user delegation SAS (Entra-signed) over key-signed SAS.

Disable Shared Key access

You can disallow Shared Key authorization on the storage account. After that setting is on:

• Requests authorized only with account keys are rejected.
• Only Entra-authenticated (and properly authorized) requests succeed for supported scenarios.
• Conditional Access policies on storage become meaningful because clients must present Entra tokens.

Exam trap: Disabling Shared Key breaks clients that still use connection strings with account keys, classic Storage Explorer Shared Key mode, and key-signed SAS. Plan migration to Entra RBAC or user-delegation SAS first. Some trusted Microsoft service paths may still appear as Shared Key in logs—understand trusted access vs your application traffic.

---

Encryption at Rest: Microsoft-Managed vs Customer-Managed Keys

Azure Storage encrypts all data at rest by default with 256-bit AES. You always get encryption; the design choice is who manages the encryption keys.

With CMK, Azure Storage uses a data encryption key (DEK) that is wrapped by your key encryption key (KEK) in Key Vault. Disabling or deleting the KEK can render data inaccessible—pair CMK vaults with soft-delete and purge protection (see Key Vault chapter).

Exam trap: CMK is not “extra encryption on top of none.” MMK already encrypts. CMK changes key custody and lifecycle, not the fact of encryption. Client-side encryption is a third option (app encrypts before upload) and is independent of account encryption settings.

Infrastructure encryption

Infrastructure encryption enables a second 256-bit AES encryption layer at the infrastructure level (double encryption). Critical constraints:

• Must be enabled at storage account creation—you generally cannot turn it on later for an existing account.
• Adds a second platform layer; still works with MMK or CMK for the service layer.
• Choose when compliance language explicitly requires double encryption at rest.

Scenario: A regulated workload needs customer key control and double encryption. Create the account with infrastructure encryption enabled, configure CMK to a purge-protected Key Vault key, and disable Shared Key once apps use managed identities.

---

Secure Transfer Required and Minimum TLS

Secure transfer required

When Secure transfer required is enabled (strongly recommended; on by default for new accounts in modern API versions):

• All requests must use HTTPS.
• HTTP requests are rejected.

This stops cleartext credential and data exposure on the wire. Always leave this on for production.

Minimum TLS version

Independently, configure the minimum TLS version accepted by the storage account (for example TLS 1.2). Clients negotiating a lower version fail. SC-500-aligned baselines use TLS 1.2 or higher; reject TLS 1.0/1.1.

Also require HTTPS-only when minting SAS tokens so the token itself is not sent in cleartext.

---

Disable Public (Anonymous) Blob Access

Anonymous public access lets unauthenticated clients read containers/blobs if a container ACL is set to blob or container public level. Even if no container is currently public, account-level allow for public access is a latent risk: a single mis-set ACL exposes data on the internet.

Best practice: Set the account property to disable public blob access (prevent anonymous access). Only re-enable for deliberate static-website or public-media designs, and prefer CDN + controlled origins over broad public containers for sensitive data.

Exam trap: “Public access disabled” is an account setting that blocks anonymous ACL elevation. It is separate from the storage firewall (network allow list) and from private endpoints. You need both identity and network hardening for defense in depth.

---

Immutable Storage (WORM) Overview

Immutable storage stores blob data in a WORM (Write Once, Read Many) state:

Policies can apply at the container (version-level or container-level immutability depending on account capabilities) for compliance archives, financial records, and forensic evidence. Immutability protects against ransomware operators and rogue admins who try to wipe or encrypt data in place—deletes and overwrites are blocked while the policy is locked as configured.

Note for exams: Resource locks on the storage account protect against account deletion/config change, not against deleting blobs inside the account. Immutable policies and soft delete address data durability; locks address resource lifecycle.

---

Soft Delete for Blobs, Containers, and Files

Soft delete is a recovery safety net:

Configure retention long enough for detection (often 7–14+ days; match organizational RPO). Soft delete does not replace backups or immutability for compliance, but it is the fastest fix for “oops, deleted the wrong container.”

Related controls: Point-in-time restore for containers, blob versioning, and change feed improve recoverability and audit trails. Enable diagnostics so restore operations and deletes are attributable.

Hardening Baseline (Fundamentals Checklist)

1. Prefer Entra + managed identity; disable Shared Key when ready
2. MMK default; CMK + purge-protected vault when policy requires customer keys
3. Infrastructure encryption only if required—and only at create
4. Secure transfer on; minimum TLS 1.2+
5. Disable public blob access at account level
6. Soft delete for blobs/containers/files with adequate retention
7. Immutable policies for regulated “cannot alter” data
8. Rotate keys if Shared Key remains; store secrets in Key Vault—not source control

SC-500 Exam Traps (Fundamentals)

• Shared Key = full data power; Contributor who can list keys is effectively data-plane admin.
• Disabling Shared Key is the step that forces Entra-only data access—not merely “using RBAC somehow.”
• CMK ≠ enabling encryption for the first time; encryption is always on.
• Infrastructure encryption cannot be bolted on later in typical designs.
• Account locks ≠ blob immutability.
• Public access setting and firewall are different layers.