Configure Access to Azure Storage: SAS, Keys & Firewalls (AZ-104)

Access to an Azure storage account is governed by two separate questions: can you reach the endpoint (networking) and are you authorized (data-plane authorization). You must answer both, and the exam frequently splits a scenario across them.

The networking layer is the storage firewall: by default a storage account accepts connections from any network, but you can lock it to selected virtual networks and public IP ranges, admit specific Azure services through exceptions, or expose it only through private endpoints.

The authorization layer offers three mechanisms, and choosing correctly is the heart of this topic:

• Access keys (Shared Key) — two account-wide keys that grant full control of everything in the account. Powerful and dangerous.
• Shared access signature (SAS) tokens — signed URLs that grant scoped, time-limited access to specific resources.
• Microsoft Entra ID with Azure RBAC — identity-based access where users and applications authenticate with Entra credentials and receive data-plane role assignments. This is the option Microsoft recommends.

These layers combine: even a valid SAS is refused if the firewall blocks the caller's network, and an open firewall grants nothing without a key, SAS, or role assignment. Firewall denials also surface as authorization-style errors (403), so a request that fails right after a network change is often a firewall problem, not a permissions one. Always separate the network decision from the authorization decision — a question about IP restrictions is a firewall question, while a question about who may read a blob is an authorization question.

The storage firewall decides which networks may connect to the account's public endpoint. You change the account's Public network access setting from Enabled from all networks to Enabled from selected virtual networks and IP addresses (deny by default, then allow what you list), or to Disabled, which leaves private endpoints as the only way in.

The rule types

Same-region traffic ignores IP rules. Requests from Azure resources in the same region as the storage account use private Azure addresses, so an IP rule for a VM's public IP never matches them. To admit a same-region VM, use a virtual network rule (with a service endpoint on its subnet), a private endpoint, or a resource instance rule / trusted services exception for an Azure service.

Portal data access comes from your browser. When you browse containers or file shares in the Azure portal, the data requests originate from your own client IP. Lock the firewall down without adding that IP and the portal shows an authorization-style error even though you hold the right role.

Private endpoints

A private endpoint gives the account a private IP address inside your virtual network, so traffic never uses the public endpoint and is reachable over peering, VPN and ExpressRoute. A private endpoint targets one sub-resource — blob, file, queue, table, dfs or web — so an account used privately for blobs and SMB file shares needs two endpoints. Each sub-resource has its own private DNS zone (for example privatelink.blob.core.windows.net, privatelink.file.core.windows.net). Clients must resolve the account name to the private IP: a VM in a peered virtual network that still resolves the public IP needs the zone linked to its own virtual network (or a DNS forwarder that uses the zone). With private endpoints in place you usually set public network access to Disabled.

Exceptions: trusted services versus resource instances

Allow Azure services on the trusted services list keeps platform features such as Azure Backup, Azure Monitor and Event Grid working after you lock the account down. For services that use trusted access based on managed identity (Data Factory, Synapse, Azure AI services and others), the exception only applies when the service authenticates with its managed identity — a connection configured with an account key or another secret is not covered by it — and the identity still needs a data-plane role such as Storage Blob Data Contributor to touch the data. When you want the firewall to admit one specific resource rather than every instance of a service, add a resource instance rule instead.

In short, only known public IP ranges maps to an IP rule, only one subnet maps to a virtual network rule backed by a service endpoint, no public exposure maps to a private endpoint, and admit one specific resource, not the whole service maps to a resource instance rule.

Every storage account is created with two access keys, key1 and key2. Each key grants full, unrestricted control of the entire account — every blob, file, queue and table, with permission to read, write and delete. A key cannot be scoped to a single container or made read-only; possession of a key is total power over the account. This is why keys are described as all-or-nothing and are the highest-risk credential in Azure Storage. Requests signed with a key use Shared Key authorization.

Two keys exist to enable rotation without downtime: applications use key1; to rotate, you switch them to key2, regenerate key1, and later repeat in the other direction. Because one key stays valid while you regenerate the other, running clients never break. Store keys in Azure Key Vault rather than in app settings, and rotate on a schedule and immediately after any exposure.

Regenerating a key immediately invalidates every SAS signed with it, because account SAS and service SAS are both signed by an account key; a SAS cannot be re-signed with the other key. That is both a risk (you can break legitimate SAS holders) and the blunt emergency tool for revoking every ad-hoc SAS at once. A user delegation SAS is unaffected, because no account key signs it.

Key expiration policy

A key expiration policy sets a rotation interval in days. Keys older than the interval are flagged as due for rotation (in the portal and through Azure Policy), but nothing is rotated automatically — it is a reminder, not a rotation mechanism. To rotate automatically you build it yourself — for example Key Vault with Event Grid and Azure Functions — though moving clients to Microsoft Entra ID removes the need for keys altogether.

Disallowing Shared Key authorization

To remove keys from the picture entirely, set Allow storage account key access to Disabled (the AllowSharedKeyAccess property set to false). The account then rejects every request authorized with Shared Key:

Check clients before flipping the switch: Azure Monitor metrics split requests by authorization type, so you can find anything still using Shared Key. Rotation and key expiration policies do not block key use; only disallowing Shared Key does.

A shared access signature (SAS) is a signed token, appended to a resource URL as a query string, that grants scoped, time-limited access without sharing an account key. A request that carries a SAS is authorized by the token — its signature and constraints (plus, for a user delegation SAS, the signer's RBAC rights) — not by the caller's own identity or role assignments.

There are three kinds of SAS, and the exam tests the distinction:

Reading a SAS URL

Every SAS encodes its constraints as query parameters. Knowing the main ones lets you read a token and spot why it fails:

Least privilege means the narrowest sr, only the permissions needed, a short expiry, spr=https and, where the client's address is known, sip.

Start time and clock skew. If st is set to the issuing server's current time, a client or storage front end whose clock differs slightly can reject a just-issued token as not yet valid, and the same link works minutes later. Set st about 15 minutes in the past, or omit it so the token is valid immediately — but only when no SAS expiration policy is set, because that policy treats a SAS without a start time as out of policy.

SAS expiration policy

A SAS expiration policy on the storage account sets an upper limit on the validity interval (se minus st) of any SAS — account, service or user delegation. A SAS is out of policy when its interval exceeds the limit or it has no start time. The policy is enforced when a token is used, not when it is created: someone creating a longer SAS only sees a warning.

• Log (the default) — requests made with an out-of-policy SAS are allowed and recorded in the resource logs (with a diagnostic setting configured).
• Block — requests made with an out-of-policy SAS are denied, whenever the token was issued, including tokens issued before the policy was set.

A user delegation SAS can never last more than seven days anyway, so a policy longer than seven days has no effect on it. The Block action does not apply to a service SAS that references a stored access policy.

A user delegation SAS is signed with a user delegation key that a Microsoft Entra identity requests from the storage service, so no account key is ever handled. It is the SAS type Microsoft recommends, and it keeps working when Shared Key authorization is disallowed.

• Lifetime: a user delegation key is valid for at most seven days, and a SAS cannot outlive the key that signed it. The effective expiry is the earlier of the token's se and the key's expiry.
• Rights: the token grants only the intersection of its sp permissions and the RBAC data rights of the identity that requested the key. Nothing stops the signer from putting permissions in sp that it does not hold — the token is created — but any request that needs those permissions fails with an authorization error when the token is used. Fix it by giving the signer a data role that includes the operation, at a scope that covers the target.
• Requesting the key: the identity needs the generateUserDelegationKey action. Storage Blob Delegator grants only that action and has no data actions, so on its own it lets the identity request a key but not sign a SAS that can actually read or write anything; the data rights come from a data-plane role.
• Revocation: revoke all user delegation keys for the account (for example Revoke-AzStorageAccountUserDelegationKeys or az storage account revoke-delegation-keys), which invalidates every user delegation SAS at once, or remove the signer's role assignment so the intersection becomes empty (role changes can take a few minutes to propagate).
• No stored access policies: a user delegation SAS cannot reference a stored access policy.

So a requirement for the most secure SAS, secured with Entra credentials or account keys must not be used points to a user delegation SAS, while a token that must be revocable per container through a policy points to a service SAS.

A plain (ad-hoc) service SAS carries its permissions and times inside the signed string, so once issued it stays valid until it expires — short of regenerating the account key, which kills every SAS signed with that key across the account.

A stored access policy solves this. You define a named policy on a container (or file share, queue or table) and issue a service SAS that references the policy by name (si). The service checks the policy on each request, so you can:

• Revoke every SAS bound to it by deleting the policy, renaming it, or setting its expiry to the past — without touching account keys or any other container's tokens.
• Change the policy — extend or bring forward its expiry, or reduce its permissions — and every linked SAS inherits the change, keeping the same URLs.

Changes are not instant: Microsoft documents that creating, changing or deleting a stored access policy can take up to 30 seconds to take effect.

Where each field lives. Start time, expiry time and permissions must each be specified in either the token or the policy — never both, or the request fails authorization. Only values held in the policy can be changed after issue, so a design that must later cut permissions or move the expiry puts sp, st and se in the policy and leaves them out of the tokens.

A container, share, queue or table supports up to five stored access policies at a time. Policies apply only to a service SAS; account SAS and user delegation SAS cannot use them.

The authorization choice usually comes down to whether the caller can have an Entra identity and how easily you must revoke it.

Data-plane versus control-plane roles

Entra authorization to data needs a data-plane role. Control-plane roles such as Reader and Contributor manage the storage account resource; Reader alone reads no data. Contributor (and Reader and Data Access) can reach data only by listing the account keys — which is full access, so neither is a least-privilege data role.

Assign data roles at the narrowest scope that works — a single container or queue is a valid scope. In line with Microsoft's recommendations (Entra ID first; user delegation SAS when a SAS is needed), a practical order from most to least preferred is Entra RBAC, user delegation SAS, service SAS (ideally with a stored access policy), then access keys.

Azure Files SMB shares can authenticate users with their own identities over Kerberos instead of the storage account key, which is what makes them a drop-in replacement for an on-premises file server. You enable one identity source on the storage account — an account can use only one at a time, and switching sources briefly interrupts identity-based access.

The deciding factor is usually where the clients are and how they are joined. AD DS authentication needs line of sight to a domain controller, and Entra Domain Services needs clients joined to the managed domain; Entra Kerberos needs neither, because Entra ID issues the Kerberos tickets. Because an account has only one source, a mixed fleet of Entra joined and hybrid joined clients is served by the one source that supports both — Entra Kerberos.

Share-level and file-level permissions

Access is checked twice. Share-level permissions come from Azure RBAC roles assigned to users or groups:

• Storage File Data SMB Share Reader — read over SMB.
• Storage File Data SMB Share Contributor — read, write and delete over SMB.
• Storage File Data SMB Share Elevated Contributor — Contributor plus modifying Windows ACLs (NTFS permissions), needed to edit permissions in File Explorer with an identity rather than the account key.

Instead of assigning a role to every group, you can set a default share-level permission on the account; it applies to all authenticated identities on every file share in the account, leaving fine-grained control to NTFS. It starts as None (no access). When an identity also holds a specific SMB Share role, it gets the higher of the two — so a broad default can lift users above the role you assigned them.

Directory- and file-level permissions are standard Windows NTFS ACLs. Effective access is the more restrictive of the two layers: the share-level permission is a ceiling that NTFS cannot raise, and NTFS can only narrow what the share allows. A user whose NTFS rights include write still cannot change files through a read-only share-level permission, and a share role that allows write does not override an NTFS entry that grants only read. Troubleshoot by checking both layers.

Do not confuse the SMB roles with Storage File Data Privileged Reader / Privileged Contributor: those authorize access to file data over the REST API with Entra OAuth tokens and override NTFS ACLs. They are not share-level permissions for SMB mounts.

A partner company needs read-only access to the blobs in one container for the next two weeks, they have no identity in your Microsoft Entra tenant, and you must be able to cut off their access early if the project is cancelled.

Because the partner signs in with nothing of yours, you hand them a URL. A user delegation SAS would avoid account keys, but it cannot be revoked per container — only by revoking every user delegation key in the account or the signer's role — and it is capped at seven days, so it would need reissuing. The design that fits is a service SAS scoped to that container with read and list permissions, bound to a stored access policy that holds the permissions and the two-week expiry, with the token itself carrying only the policy name (si), plus spr=https and, if known, the partner's sip range.

Every requirement is met: access is scoped, read-only, time-limited and revocable. If the project is cancelled you delete the policy and, within about 30 seconds, the SAS stops working — no key regeneration and no impact on any other client. If the project is extended, you move the policy's expiry and the partner keeps the same URL. This only works while Shared Key authorization is allowed on the account; if your security baseline disallows it, the user delegation SAS is the remaining option.