Configure Access to Storage

What it is

Access to a storage account is controlled at two levels. The network level decides which clients can reach the account at all. The authorization level decides what a client that reaches it may do.

For authorization you can use Microsoft Entra ID and RBAC, a shared access signature (SAS), or the account access keys.

How it works

Storage firewalls and virtual networks

By default a storage account accepts connections from any network. In the Networking settings you can change this to accept connections only from selected virtual networks and IP addresses. Everything else is denied.

• Virtual network rules allow chosen subnets. The subnet needs a service endpoint for Microsoft.Storage.
• IP rules allow public IPv4 address ranges. Private address ranges cannot be used in IP rules.
• Exceptions can allow trusted Microsoft services, such as Azure Backup, to reach the account.
• A private endpoint gives the account a private IP address in your virtual network, so traffic never uses the public endpoint.

Shared access signatures

A SAS is a URL token that grants limited access for a limited time. It defines which resource, which permissions, the start and expiry time, and optionally the allowed IP addresses and protocol.

The identity that creates a user delegation SAS needs an Azure role that allows it to request a user delegation key.

Stored access policies

A stored access policy defines the start time, expiry and permissions of a SAS in one place, on a container, share, queue or table. A service SAS can then refer to the policy. You can set up to five policies at a time on one resource.

The benefit is control. To revoke every SAS linked to a policy, delete the policy or change its expiry to a time in the past. A SAS that has no stored access policy cannot be revoked, except by regenerating the account key that signed it. A stored access policy does not work with an account SAS.

Access keys

Each storage account has two access keys. Either key gives full access to everything in the account. Two keys exist so that you can rotate without downtime: switch applications to key 2, then regenerate key 1.

Keep keys in Azure Key Vault, rotate them regularly and avoid them where possible. You can turn off key authorization for the account so that only Microsoft Entra authorization is accepted. Regenerating a key also invalidates every SAS that was signed with it.

Identity based access for Azure Files

Azure Files over SMB can use identities instead of the account key. The identity source can be on premises Active Directory Domain Services, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for hybrid identities.

Access is then checked at two levels.

1. Share level: an Azure role such as Storage File Data SMB Share Contributor, assigned to the user or group.
2. File and folder level: the usual Windows ACL permissions on the files themselves.

Choosing an authorization method

What a SAS URL contains

A SAS is appended to the resource URL as parameters.

https://contoso.blob.core.windows.net/docs/report.pdf?sv=2022-11-02&sp=r&se=2026-12-31T00:00:00Z&sr=b&sig=<signature>

sp lists the permissions, se is the expiry time, sr is the resource type and sig is the signature. A user delegation SAS can be created from the command line with the --as-user option.

Troubleshooting a 403 error

When a client reaches the account but is refused, check these causes in order.

How the exam asks about this

• "Revoke a SAS you have already issued." Delete the stored access policy, or regenerate the key if there is none.
• "Allow only a virtual network to reach the account." A firewall rule with a service endpoint.
• "Reach the account over a private address." A private endpoint.
• "Which SAS is signed with Entra credentials?" The user delegation SAS.
• Azure Files access with identities needs a share-level role and file-level ACLs.