Azure Blob Storage Security Checklist 2026: Entra ID, RBAC, and Shared Key Hardening

By Syed Zada Abrar · andraxpentester.in

Misconfigured object storage still drives a large share of cloud data exposure. On Azure, the familiar failure mode is the same pattern defenders see elsewhere: anonymous read left open “just for a demo,” account keys shared across apps, and management roles mistaken for data-plane access. This checklist is a defensive walkthrough of Azure Blob Storage security with Microsoft Entra ID and Azure RBAC best practices—aligned to official Microsoft Learn guidance, not folklore.

Use it as a remediation and review aid for accounts you own or are authorized to harden. Pair it later with the AWS S3 / IAM hardening checklist (companion piece — publish separately).

Who this is for

Cloud and app teams who own storage accounts and need a repeatable hardening pass
Security engineers building control baselines for Blob + Entra ID
Learners mapping AWS S3 mental models to Azure’s data-plane RBAC model

Out of scope: attack recipes, unauthorized scanning of third-party tenants, or “how to dump blobs” content.

Checklist at a glance

Priority	Control	Target state
P0	Anonymous / public blob access	Disallowed at account (`AllowBlobPublicAccess = false`)
P0	Shared Key authorization	Disallowed when Entra ID path is ready (`AllowSharedKeyAccess = false`)
P0	Data-plane authorization	Microsoft Entra ID + least-privilege Blob data roles
P1	Workload identity	Managed identities instead of embedded keys
P1	Logging	Diagnostic settings for StorageRead / StorageWrite / StorageDelete
P1	Threat detection	Defender for Storage awareness / enablement plan
P2	Network & transport	HTTPS required, TLS minimum, firewall / private endpoints
P2	Resilience	Soft delete, immutability where business data needs WORM

1. Disable anonymous access (and keep it disabled)

Microsoft’s stance is unambiguous: anonymous read to containers and blobs is optional, risky, and should be remediating by default. Setting the storage account’s AllowBlobPublicAccess property to false forces authorization for blob requests regardless of any container-level public setting.

Do this

Inventory accounts where allowBlobPublicAccess is true or where containers still show public access levels.
Set account-level anonymous access to disallowed before you chase individual containers—the account setting overrides container settings.
If a genuine public static-content need exists, isolate it in a dedicated storage account reserved for anonymous scenarios; keep application and sensitive data accounts locked down.

Static website caveat: Even when account anonymous blob access is disallowed, the special $web container used for Azure static websites can remain publicly accessible. Do not assume AllowBlobPublicAccess = false covers $web—treat static hosting as its own public surface (dedicated account + explicit review). 4. Prefer Azure Policy to deny creation or updates that re-enable anonymous access.

Verify (authorized admin context)

Bash

az storage account show \
  --name <account> \
  --resource-group <group> \
  --query "{anonymous:allowBlobPublicAccess,sharedKey:allowSharedKeyAccess}"

Official references: Anonymous read access overview, Remediate anonymous read access, Authorize data access.

2. Prefer Entra ID; prevent Shared Key when ready

Shared Key (account access key) authorization is powerful and blunt: anyone with the key can authorize against the account. Microsoft recommends disallowing Shared Key once clients can use Microsoft Entra ID or a user-delegation SAS, and using managed identities for hosted workloads.

Migration pattern (safe order)

Inventory clients that still sign with account keys (apps, scripts, CI, legacy SDKs).
Move each client to Entra ID auth (managed identity, service principal, or interactive user) with a Blob data role—not only a management role.
Prove successful Entra ID traffic in logs (AuthenticationType / OAuth) before flipping the switch.
Set AllowSharedKeyAccess to false. Expect HTTP 403 on subsequent Shared Key requests.

Before you flip the switch: Disallowing Shared Key can break Azure Files shares and some platform/tooling paths that still depend on account keys until Entra (or other) auth paths are ready. Inventory those clients first. 5. Keep a break-glass runbook: who can temporarily re-enable Shared Key, for how long, and how you audit that window.

If you must keep Shared Key temporarily: store keys in Azure Key Vault, rotate on a schedule, and never commit keys to source control. Treat that as debt, not a steady state.

Official references: Prevent Shared Key authorization, Security recommendations for Blob Storage.

3. Azure RBAC scope: management vs data plane

A common Azure surprise: Owner / Contributor / Storage Account Contributor on the control plane does not automatically grant blob data access via Microsoft Entra ID. Data access needs an explicit Blob data role assignment.

Built-in data roles (typical)

Storage Blob Data Reader — read only
Storage Blob Data Contributor — read / write / delete blobs (still not account admin)
Narrower custom roles when built-ins are too broad

Scope discipline

Scope	When to use
Container	Preferred for apps that only need one container
Storage account	Shared multi-container app with clear ownership
Resource group / subscription	Rare for data roles; high blast radius

Always assign to the narrowest security principal: prefer a managed identity or group over a long-lived individual assignment at subscription scope.

Official references: Authorize access with Microsoft Entra ID, Assign an Azure role for blob data access.

Managed identities instead of secrets

For Azure-hosted workloads (App Service, Functions, VMs, AKS with workload identity patterns, and similar), use a managed identity so the platform obtains Entra tokens without you shipping keys.

System-assigned: lifecycle tied to one resource; good when the identity should die with the resource.
User-assigned: reusable across identical replicas; often lower RBAC churn for fleets.

Grant the identity only the Blob data role it needs at container or account scope. Allow time for RBAC propagation before declaring a migration “failed.”

Official references: Managed identities overview, Managed identity best practice recommendations.

SAS hygiene (when temporary delegated access is required)

Prefer user-delegation SAS (backed by Entra credentials) over account-key service SAS.
Least privilege on permissions; short expiry; HTTPS-only.
Have a revocation plan (revoke user-delegation key or stored access policy).
Unassociated service SAS: keep expiry short (Microsoft’s Blob security recommendations commonly cite one hour or less—re-check that Learn page at publish; the durable rule is prefer user-delegation SAS over account-key SAS).

4. Logging and Defender for Storage awareness

Diagnostic logging (your audit trail)

Resource logs are not collected until you create a diagnostic setting. For Blob, enable categories such as StorageRead, StorageWrite, and StorageDelete and route them to Log Analytics (or another approved sink).

Use logs to answer: when, who, what, how authorized? Microsoft’s monitoring guidance highlights fields like TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, and Uri—useful when you are verifying that Shared Key traffic has actually stopped.

Official references: Monitor Azure Blob Storage, Best practices for monitoring Blob Storage.

Microsoft Defender for Storage

Defender for Storage adds agentless threat detection over data- and control-plane telemetry (activity monitoring, optional malware scanning, sensitive data threat detection). Importantly, activity monitoring does not require you to enable diagnostic logs—but you still want logs for your own investigations, compliance queries, and Shared Key / anonymous residual checks.

Plan enablement at subscription scope for coverage of existing and new accounts, with exclusions only where justified. Treat malware scanning as a cost-controlled feature (per-GB with caps), not a silent default.

Official references: What is Microsoft Defender for Storage, Security recommendations for Blob Storage.

5. Network and transport baselines (short pass)

These sit beside identity controls; they do not replace them.

Require secure transfer (HTTPS) on every account.
Set a minimum TLS version appropriate to your policy.
Prefer private endpoints or storage firewalls / VNet rules over “public internet + key.”
Allow trusted Microsoft services only when required for platform features (backups, logging destinations, etc.).

Details: Security recommendations — Networking.

6. Operational checklist you can run this week

Copy into a ticket or runbook:

Multi-cloud note

If your org already hardened S3 with IAM, Block Public Access, and GuardDuty/malware patterns, map controls 1:1: anonymous → public access block; Shared Key → long-lived access keys; Entra data roles → bucket policies + IAM; Defender for Storage → your AWS detection stack. Keep both checklists in one cluster so reviewers see consistent object-storage posture. Companion piece: AWS S3 / IAM hardening checklist (companion piece — publish separately).

For hands-on Azure lab-style practice on andraxpentester.in, start from authorized tutorials under /tutorials/ once those modules ship—not from production tenants you do not own.

Sources

Overview: Remediating anonymous read access for blob data — Microsoft Learn
Remediate anonymous read access to blob data — Microsoft Learn
Prevent Shared Key authorization for an Azure Storage account — Microsoft Learn
Authorize operations for data access — Microsoft Learn
Authorize access to blobs using Microsoft Entra ID — Microsoft Learn
Assign an Azure role for access to blob data — Microsoft Learn
What are managed identities for Azure resources? — Microsoft Learn
Managed identity best practice recommendations — Microsoft Learn
Security recommendations for Blob storage — Microsoft Learn
Monitor Azure Blob Storage — Microsoft Learn
Best practices for monitoring Azure Blob Storage — Microsoft Learn
What is Microsoft Defender for Storage? — Microsoft Learn