Storage Account Security: Firewall, Access Policies…

Storage security, end to end

Simple explanation

Azure Storage is the foundation under most Azure workloads — blob containers for application data, file shares, queues, tables. Locking it down on SC-500 means controlling four things:

Network — public access, selected networks, or Private Endpoint only
Authentication — Microsoft Entra ID + Azure RBAC (preferred) vs storage account key (legacy) vs Shared Access Signatures
Data protection — encryption at rest with platform or customer-managed keys, soft delete + versioning + immutability
Threat protection — Microsoft Defender for Storage detects anomalous access, malicious uploads (malware scanning), data exfiltration patterns

Storage firewall and network access

Storage firewall options — production should be selected networks or Private Endpoint only
Network mode	What it allows	When to pick
Allow access from all networks	Any IP on the internet	Almost never for production — accept only with Entra-based auth + IP-scoped SAS + extensive Defender alerts
Allow access from selected virtual networks and IP addresses	VNet service endpoints (`Microsoft.Storage`) on selected subnets + explicit public IP/CIDR ranges + trusted-services exception	Good middle ground when consumers are mixed (some VNets, some specific external services)
Disabled (Private Endpoint only)	Only resources with a private endpoint can reach the storage account	Highest assurance — public surface fully closed, all access via private DNS

Trusted Microsoft services

When the firewall is set to “selected networks”, a separate toggle controls whether trusted Microsoft services (Backup, Defender for Cloud, Azure Monitor, Site Recovery, etc.) can bypass the firewall using their first-party identities. The exam pattern: regulated workloads disable public access entirely AND disable trusted services bypass, requiring those services to use a Private Endpoint route.

Authentication: RBAC vs storage key vs SAS

Storage access methods — Entra + RBAC is the SC-500 default; stored access policies add revocation control
Method	How it works	When to use
Microsoft Entra ID + Azure RBAC	Caller authenticates with Entra token; Azure RBAC data-plane roles (`Storage Blob Data Contributor`, etc.) authorise. Audit per-caller in storage logs.	Default for production — combined with managed identity gives the no-stored-credential pattern
Storage account key	Bearer key (two per account — primary and secondary) granting full access to all data planes. No identity, no audit attribution beyond 'the key'.	Only legacy compatibility — disable account-key access where possible
Shared Access Signature (SAS)	Signed URL with embedded permissions, scope, and expiry. Service SAS (account-key-signed), user-delegated SAS (Entra-signed — much better), account SAS (account-level scope).	Time-bounded delegated access to a specific resource — user-delegated SAS preferred
Stored access policies	Server-side policy referenced by SAS — lets you centrally revoke SAS by removing the policy.	Whenever SAS is unavoidable — gives you a server-side kill switch

The ‘disable account key access’ switch

A modern storage account has a defaultToOAuthAuthentication and allowSharedKeyAccess set of switches at the account level. Setting allowSharedKeyAccess: false blocks ALL key-based access (including service SAS, which is signed with the key) at the storage layer — forcing all callers to use Entra. This is the strongest version of the no-stored-credential pattern for storage.

Encryption and data protection

Encryption at rest — always on with Microsoft-managed keys by default. Customer-managed keys (CMK) via Key Vault for customer key custody; rotation policies supported. Infrastructure encryption adds a second encryption layer for double protection.
Soft delete for blob and container (configurable retention period). Recovers from accidental deletes.
Blob versioning — every overwrite or delete creates a new version; rollback by promoting an older version.
Immutable blob storage — write-once, read-many policy via time-based retention or legal hold. Used for compliance / WORM (Write Once Read Many) workloads.

Microsoft Defender for Storage

Two tiers:

Defender for Storage (per-storage-account or per-transaction) — alerts on anomalous access patterns, atypical geography, mass-delete, ransomware patterns, suspicious access from anonymous IPs.
Defender for Storage — malware scanning on upload (next-gen plan) — scans every uploaded blob with Microsoft anti-malware at the moment of upload; quarantines/alerts on detection.

Plan enabled per subscription or per storage account. Alerts surface in Defender for Cloud and route to Defender XDR + Sentinel via connectors.

Scenario: Esme locks down Northwind Bank’s customer-data storage

Network: Private Endpoint only. Public access disabled. Private endpoint in the banking VNet; privatelink.blob.core.windows.net DNS zone linked.
Authentication: allowSharedKeyAccess: false — no key-based access. Microsoft Entra + Azure RBAC only. Banking app’s managed identity has Storage Blob Data Contributor on the specific container.
CMK via Northwind’s HSM-backed Key Vault. Annual rotation policy with 30-day grace.
Data protection: blob versioning + soft delete (30 days). For transaction-archive containers, immutable retention (7 years time-based).
Defender for Storage with malware scanning on upload — every uploaded blob scanned. Alerts to Sentinel.
Stored access policies — for the one SAS use case (a third-party fraud-screening service that can’t use Entra yet), Esme creates a stored access policy with 1-hour validity and read-only on a single container. She can revoke by deleting the policy.

Audit closes. Customer-data storage is reachable only from the banking VNet, only by Entra-authenticated callers, with HSM-protected keys, malware-scanned uploads, and a revocable SAS for the legacy integration.