Azure Blob Storage Hardening Cheat Sheet

The AWS S3 checklist's Azure counterpart — access, network, encryption, and recovery, mapped to Microsoft's own cloud security benchmark controls where one exists. Baseline as of September 2026.

Blob Storage is Azure's equivalent gravity well for misconfiguration — same failure mode as S3 (a container left public, a key that never rotates), different console. This is a working checklist pulled from Microsoft's own current guidance, not a substitute for reading it.

Worth flagging: the static website gotcha

Disabling anonymous public access at the account level (allowBlobPublicAccess = false) does not cover everything. The $web container used by Azure's static website feature stays publicly readable even with that setting off, as long as the static website feature itself is enabled. If you turned on static website hosting once and forgot about it, that container is still open. Disable the static website endpoint on any account that isn't actively using it.

Access control

• [ ] Anonymous public read access disabled at the storage account (allowBlobPublicAccess = false) — blocks every container from going public regardless of its own setting
• [ ] Existing containers audited for anonymous access, not just new ones blocked going forward
• [ ] Azure AD (Entra ID) credentials used for data-plane access instead of storage account keys — assign RBAC roles like Storage Blob Data Reader / Contributor rather than sharing a key
• [ ] Local authentication methods for data-plane access restricted or disabled where the workload allows it
• [ ] User-delegation SAS preferred over service SAS — it's signed with an Entra credential, so revoking that credential immediately invalidates every SAS issued from it
• [ ] Where a service SAS is unavoidable, it's scoped to a stored access policy — otherwise revoking it means rotating the account key, which breaks every other SAS in the account too
• [ ] For Data Lake Storage: RBAC for coarse access, ACLs for fine-grained — not ACLs carrying the whole permission model on their own

Network

• [ ] Private endpoints (Private Link) deployed for storage accounts instead of relying on the public endpoint
• [ ] Public network access disabled at the account level once private endpoints are in place
• [ ] Static website endpoint disabled when not in use (see callout above)
• [ ] Publicly served blob content fronted with Azure Front Door (managed TLS + WAF) — Storage's own custom-domain feature has no managed certificate support

Encryption

• [ ] Secure transfer (HTTPS) required — on by default; confirm it hasn't been turned off
• [ ] Minimum TLS version enforced for the storage account
• [ ] Data at rest encrypted by default with Microsoft-managed keys — move to customer-managed keys in Key Vault if compliance requires it
• [ ] Encryption scopes used for per-container/per-blob key isolation in multitenant accounts
• [ ] Client-side encryption for anything that must never touch the server as plaintext

Versioning & recovery

• [ ] Blob versioning enabled
• [ ] Soft delete enabled for both blobs and containers — configured separately, so check both
• [ ] Point-in-time restore enabled for block blob accounts (requires versioning + soft delete + change feed all enabled together)
• [ ] Immutable storage (time-based retention or legal hold) configured for regulated data — validate the retention duration first, since locking the policy is a one-way commitment
• [ ] Azure Backup (operational backup) enabled for blob data

Logging, monitoring & detection

• [ ] Microsoft Defender for Storage enabled — malware scanning plus anomaly detection on the account
• [ ] Change feed enabled — an ordered, unchangeable log of every blob change, useful for both point-in-time restore and forensics
• [ ] Storage logs alerted on AuthenticationType == "Anonymous" after disabling anonymous access — catches a misconfigured client or an active probe
• [ ] Object replication and copy operations restricted to trusted source accounts and tenants — a real, easy-to-miss exfiltration path (copying data into an attacker-controlled account elsewhere)
• [ ] Resource logs routed to Log Analytics or a dedicated, immutable storage account for long-term retention

A note on the source baseline

The control IDs cited from Microsoft's docs here (NS-2, IM-1, DP-3/DP-4/DP-5, LT-1, LT-4, BR-1, and similar) come from the Microsoft cloud security benchmark rather than CIS numbering — Microsoft's own Storage security baseline page currently notes it's still built on benchmark v1.0 and may lag the latest guidance in places, so treat it as a cross-reference, not the primary source. The Secure your Azure Blob Storage page is the one Microsoft keeps current, and it's the primary source for everything above.

Same tool, same job

Cloud Custodian (this issue's OSS Spotlight) isn't AWS-only — its azure.storage resource type covers exactly this kind of check. The same pattern from the S3 cheat sheet applies here: codify the access-control items above as YAML policies instead of re-auditing them by hand every quarter.

Sources: Microsoft Learn — Secure your Azure Blob Storage · Microsoft Learn — Azure security baseline for Storage