SC-500 Azure Storage Account Security: Firewall, Defender for Storage, Encryption, SAS and Access

A handful of storage account settings decide what any request can do before data roles or SAS tokens are even considered, so they are the first thing to harden. Each one answers a different question, and confusing them is the most common mistake.

Anonymous blob access

A container's anonymous access level (Private, Blob or Container) only matters while the account allows anonymous access. Fixing containers one by one works but must be repeated for every new container; disabling the account-level setting closes all of them at once. Disabling public network access is a different layer: it blocks the internet path for everyone, including legitimate callers who sign in with Entra ID.

To enforce the rule across many subscriptions, assign Azure Policy at a management group. Pick the effect by the outcome you need:

• Deny (the built-in policy that disallows storage account public access) makes a non-compliant create or update fail with a policy error the deployer sees, and leaves compliant accounts alone.
• Audit on the same policy only reports non-compliance.
• Modify (the separate built-in policy Configure your Storage account public access to be disallowed) changes the request so the account ends up compliant. It hardens silently; the deployment does not fail.

Microsoft Defender for Storage detects threats; it doesn't prevent a misconfiguration from being deployed.

Cross-tenant replication

Accounts created on or after 15 December 2023 disallow cross-tenant replication by default. Older accounts allow it unless the AllowCrossTenantReplication property is set to false. Azure Storage refuses to set it to false while the account still takes part in a cross-tenant object replication policy, so you delete that policy first and then disallow the setting. A built-in Azure Policy definition can then prevent cross-tenant replication at scale. The separate Permitted scope for copy operations setting (preview at the time of writing) limits copy sources, not replication policies.

Setting Allow storage account key access to Disabled makes the account reject every request authorized with an account key, which includes service SAS and account SAS, because both are signed with an account key. Requests authorized with Microsoft Entra ID keep working, and so do user delegation SAS tokens, which are signed with a key obtained through Entra ID.

Measure before you disallow

Microsoft's guidance is to find out who still uses keys first:

• Metrics Explorer: the Transactions metric split or filtered by the Authentication dimension shows how many requests use account keys or SAS. It's aggregate and anonymous.
• Resource logs: a diagnostic setting that sends StorageBlobLogs (and the other services' logs) to a Log Analytics workspace records each request's authentication type with details such as caller IP address and user agent, so you can identify the clients.

Azure Resource Graph reports configuration (for example which accounts still allow Shared Key), not who calls them. A built-in Azure Policy definition audits or denies accounts that allow Shared Key access.

Why it matters for Conditional Access

Conditional Access evaluates requests for Microsoft Entra tokens. A key-signed request carries no Entra token, so it bypasses Conditional Access entirely. Microsoft therefore states that protecting a storage account with Conditional Access requires disallowing Shared Key authorization. Network settings (public network access) and transport settings (secure transfer) don't change the authorization path.

Account key expiration policy (rotation reminder)

If keys stay enabled, a key expiration policy sets a rotation interval and flags keys older than it. It needs each key's keyCreationTime; accounts created before that property was tracked show it as null, and the portal's Set rotation reminder option is unavailable until you regenerate both keys once. The built-in policy Storage account keys should not be expired then reports compliance across subscriptions. Key expiration is about account keys; it is unrelated to the SAS expiration policy.

All Azure Storage data is encrypted at rest with 256-bit AES by default using Microsoft-managed keys; customer-managed keys (CMK) let you own and control the key that protects the account's encryption key. With CMK, Azure Storage wraps and unwraps the account encryption key with your key in Azure Key Vault or Key Vault Managed HSM.

CMK prerequisites

• The key vault must have soft delete and purge protection enabled. Soft delete alone isn't enough; Azure Storage refuses a key from a vault without purge protection.
• The storage account reaches the vault through a managed identity (user-assigned, or system-assigned for an existing account). With the Azure RBAC permission model, assign it Key Vault Crypto Service Encryption User, scoped to the key for least privilege. That role grants get, wrap and unwrap only; Key Vault Crypto Officer is far broader, and Key Vault Secrets User covers secrets, not keys.

Key versions and rotation

If the key in use is disabled, deleted or its access is removed, Azure Storage can no longer unwrap the account encryption key and data operations fail with 403 for every caller: Entra users with data roles, key holders and SAS users alike. Re-enabling the key restores access with no data loss. That makes disabling the key an emergency lock that works beneath every authorization method, unlike regenerating account keys or disallowing Shared Key, which leave Entra-authorized callers working.

Infrastructure encryption

Infrastructure encryption adds a second layer of encryption at rest, at the infrastructure level, with a different algorithm and a different key from the service-level encryption. It can only be enabled when the account is created; for an existing account, create a new account with it enabled and move the data. CMK changes who owns the service-level key; it doesn't add a second layer.

Encryption scopes: different keys inside one account

An encryption scope lets you encrypt specific containers or blobs with their own key, so one storage account can hold data protected by several keys. Account-level encryption, whether Microsoft-managed, a single CMK or a cross-tenant CMK, applies one key to the whole account; encryption scopes are the tool when different tenants or clients in one account each need their own key.

• Each scope uses a Microsoft-managed key or a customer-managed key in Key Vault. Disabling a scope, or revoking its customer-managed key, affects only data written with that scope.
• A request can name a scope per blob upload, or a container can have a default encryption scope that applies to its blobs.
• A container's default scope can prohibit overrides: uploads that specify a different scope then fail, so every blob in the container is guaranteed to use that scope.
• A default encryption scope can be set only when the container is created. To move existing data under an enforced scope, create a new container with that default and copy the blobs into it.

Azure Policy evaluates resource configuration, not individual blob uploads, so it can't enforce which scope each upload uses.

Immutable storage for Azure Blob Storage keeps blobs in a write once, read many (WORM) state: they can be created and read, but not modified or deleted, while a policy applies. You configure it on the container's Access policy page (the same page that holds stored access policies, which are unrelated) or at blob version level.

Append workloads under retention

Under a container-level time-based retention policy, Append Block is blocked unless you enable allowProtectedAppendWrites (append blobs) or allowProtectedAppendWritesAll (append and block blobs). With it, new blocks can be added but existing data can't change, which suits audit logs. Choose the setting while the policy is still unlocked: once locked, it can't be changed.

What isn't immutability

Azure resource locks (ReadOnly, CanNotDelete) protect the storage account resource on the management plane. They don't stop data-plane writes or deletes of blobs. Version-level immutability requires blob versioning and is incompatible with point-in-time restore.

Recovery features: soft delete, versioning and point-in-time restore

Blob data protection features let you recover from accidental or malicious deletes and overwrites, and each one covers a different object. Picking the right one depends on whether the container or the blobs inside it are affected.

Point-in-time restore prerequisites and limits

• Requires blob soft delete, blob versioning and change feed to be enabled first.
• The restore window must be shorter than the blob soft delete retention (for example 7 days with 14-day soft delete).
• Supported for block blobs in standard general-purpose v2 accounts without a hierarchical namespace.
• It can't restore a deleted container, so pair it with container soft delete. Container soft delete is recommended, not a prerequisite.
• It is incompatible with version-level immutability.

The Azure Storage firewall decides which networks can reach the account's public endpoint; it is a network layer that sits in front of authorization, not a replacement for it. A request must pass the firewall and be authorized (data role, SAS or key).

Public network access modes

• Enabled from all networks: no network filtering.
• Enabled from selected virtual networks and IP addresses: the default action becomes deny, and only the rules and exceptions you add are allowed.
• Disabled: only private endpoint traffic is intended to reach the account (private endpoints and their DNS are covered in the network services lesson). IP and virtual network rules stop applying. However, if you switch from selected networks to Disabled, any resource instance rules and exceptions you configured, including the trusted services exception, remain in effect; remove them to close those paths.

Rule types

Choosing the right rule

• On-premises or branch users behind NAT: the firewall sees the public NAT address, so add that address as an IP rule; their internal private range is never visible and is rejected anyway.
• VMs or App Service with regional virtual network integration in the same region: use a virtual network rule for the subnet with the service endpoint, because IP rules don't see same-region traffic.
• A single instance of an Azure PaaS service that has no subnet in your network: a resource instance rule, plus an RBAC data role for its managed identity.
• An NSG on a client subnet filters only that subnet's traffic; it doesn't restrict who else can reach the storage account.

Templates can show a defaultAction of Allow alongside public network access Disabled; Disabled still wins for traffic, but the mismatch can make Defender for Cloud and Advisor report the account as open, so keep them consistent.

Microsoft Defender for Storage is the Defender for Cloud plan that detects threats to storage accounts: suspicious activity, malware uploads and attempts to exfiltrate sensitive data. It detects and responds; it doesn't block misconfigured deployments the way Azure Policy Deny does.

Where to enable it

• Subscription level (recommended): protects every existing and future storage account in the subscription. You can exclude specific accounts (for example a load-testing account) so they don't incur charges, or override settings per account.
• Account level: protects only the accounts you choose, so new accounts are missed.
• Resource groups are not an enablement scope.
• At scale with Azure Policy, assigned at a management group:

A DeployIfNotExists assignment covers new subscriptions automatically; run a remediation task to bring existing subscriptions into compliance.

Plan settings

• Activity monitoring: analyses control-plane and data-plane telemetry for anomalies. It needs no diagnostic settings or resource logs.
• Sensitive data threat detection: prioritises alerts on accounts holding sensitive data, using Microsoft Purview sensitive information types. It is included in Defender for Storage at no extra cost; Defender CSPM's sensitive data discovery is a separate plan.
• Malware scanning: billed per GB scanned, with a configurable monthly cap in GB per storage account (set at subscription or account level) to limit spend. Next section.

Defender for Storage malware scanning scans blobs for malware with Microsoft Defender Antivirus and reports a verdict for each scanned blob. It runs on upload (near real time, as blobs are written) or on demand (scanning existing blobs, and files, when you trigger it).

Where results go

Responding to malicious blobs

• Built-in automated remediation soft-deletes a blob that scanning flags as malicious: it disappears from the container but stays recoverable for forensics, with nothing to build or run.
• A custom quarantine (Event Grid triggering a function or Logic App) is flexible but is code to maintain.
• An ABAC condition on the scan-result index tag can block reads but leaves the file in place and inherits the tag's lack of tamper resistance. Blob versioning keeps history but leaves the malicious blob current.

Limits to know

• On-upload scanning covers Blob Storage; it doesn't scan files written to Azure Files.
• Append blobs and page blobs aren't supported; block blobs are.
• Blobs up to 50 GB are supported, including archives such as ZIP files.
• Server-side encryption, including customer-managed keys, doesn't stop scanning. Client-side encrypted content can't be meaningfully scanned because the service can't decrypt it.
• Accounts reached through private endpoints are supported.

Access to storage data is authorized on the data plane, so the right roles are the Storage * Data roles; control-plane roles manage the account resource and grant no data access on their own. Least privilege has two dimensions: the role's permissions and its scope (management group, subscription, resource group, account, or a single container, queue, table or file share).

So an audit that finds users reading blobs with no data role usually points to a listKeys role. The fixes are to remove those role assignments or to disallow Shared Key so keys stop working. Queue, Table and File data roles cover only their own service.

ABAC role assignment conditions

Azure attribute-based access control adds a condition to a role assignment, such as Storage Blob Data Reader, so the data action is granted only when attributes match, for example a blob index tag value, a container name or a blob path. Scopes stop at the container, so when the right set of blobs is spread across containers, a role at account scope with a condition on a blob index tag grants exactly those blobs and nothing else. Conditions apply to data actions, so a control-plane role such as Reader has nothing to condition.

A shared access signature (SAS) is a signed URL token that grants limited, time-bound access to storage resources, and there are three kinds that differ in how they are signed and therefore how they are revoked.

Microsoft recommends the user delegation SAS because no account key is involved. Its permissions are the intersection of what the SAS states and what the requester's data roles allow. Because the Get User Delegation Key operation acts on the storage account, an identity whose data role is scoped to one container also needs Storage Blob Delegator (or another role with that action) at account scope or higher; the container-scoped data role still limits what every SAS can grant. Rotating account keys does nothing to a user delegation SAS, and revoking user delegation keys does nothing to key-signed SAS.

Stored access policies

A stored access policy is defined on a container, queue, table or file share and holds the start time, expiry and permissions for the service SAS tokens that reference it.

• Works with service SAS only; user delegation SAS and account SAS can't use one.
• Editing the policy changes every linked SAS (shorten, extend, change permissions); deleting it revokes them, with no key rotation.
• Up to five policies per container, queue, table or share. Changes take effect within about 30 seconds.
• A SAS refers to the policy by its signed identifier. If you delete a policy and create a new one with the same identifier, old tokens validate again against the new policy. Use a new identifier instead.

SAS expiration policy

A SAS expiration policy sets a recommended upper limit on SAS validity for the account and applies to all three SAS types.

• The action is Log by default: out-of-policy requests still succeed and a SasExpiryStatus value is written to the resource logs. Set it to Block to reject them.
• Once a policy exists, every SAS must include a signed start time; a SAS without one is out of policy even if its interval is short.
• The Block action isn't supported for a service SAS associated with a stored access policy, so keep those policies short-lived.
• The Azure Policy definition that requires SAS expiration policies checks configuration only; it doesn't evaluate individual requests.

Identity-based access to Azure file shares over SMB uses two layers: share-level permissions granted with Azure RBAC, then directory and file-level Windows ACLs (NTFS permissions). The effective access is the more restrictive of the two. Identity sources are on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for hybrid identities.

• Share-level roles set the ceiling for the whole share; Windows ACLs refine access per folder and file. A group that must write in one folder and read elsewhere needs a share role that allows writing, then ACLs that give Modify on that folder and Read elsewhere.
• To change Windows ACLs over SMB with an identity rather than by mounting with the storage account key, the identity needs SMB Share Elevated Contributor. A key mount acts as a superuser and bypasses ACLs.
• Share-level RBAC is assigned to Microsoft Entra identities. A default share-level permission applies to every authenticated identity, which is how identities with no Entra object, such as a gMSA or computer account, get share access. Windows ACLs still control file access, so choose the lowest default that works.
• Blob data roles don't apply to SMB file access.