Azure Storage Access for AZ-104: Firewalls, SAS and Azure Files

Introduction

Configuring Azure Storage access for AZ-104 means combining network restrictions with least-privilege data authorization. This lesson opens the skills area Implement and manage storage (15–20% of the exam) with the objective configure access to storage. The study guide lists: configure Azure Storage firewalls and virtual networks, create and use shared access signature (SAS) tokens, configure stored access policies, manage access keys, and configure identity-based access for Azure Files.

Storage accounts allow public-network connectivity by default, but that does not mean their data permits anonymous access. A leaked credential can expose data when network and authorization checks both permit the request. An administrator therefore has two jobs: control where requests may come from (network layer) and control who may do what (authorization layer). This lesson covers both, and shows how to choose among the four ways of authorizing a request: Microsoft Entra ID, Shared Key (account access keys), shared access signatures, and anonymous public access.

After this lesson you will be able to lock a storage account to specific networks, issue time-limited and revocable SAS tokens, rotate keys without downtime, and enable identity-based authentication for SMB file shares.

Learning objectives

• Configure the storage firewall with selected virtual networks, IP rules, resource instance rules and exceptions.
• Distinguish service endpoints from private endpoints for storage access.
• Create user delegation, service and account SAS tokens and choose the safest one.
• Use stored access policies to revoke or change SAS tokens after issue.
• Rotate access keys and understand why disabling Shared Key authorization improves security.
• Configure identity-based authentication for Azure Files and the share-level and NTFS permissions it needs.

Apply the distinction between management and data roles from Azure RBAC roles and scopes throughout these examples.

Authorization options at a glance

Exam tip: When a scenario asks for the most secure way to give an application access to blobs, the answer is nearly always Microsoft Entra ID with a managed identity and a Storage Blob Data role. When temporary access for an external party is needed, the answer is a user delegation SAS.

Storage firewalls and virtual networks

By default, a storage account accepts connections from clients on any network. In Networking you choose the public network access mode:

• Enabled from all networks: default; any client with valid credentials can connect.
• Enabled from selected virtual networks and IP addresses: the firewall denies everything except the networks and addresses you list.
• Disabled: blocks ordinary public-endpoint access; use private endpoints for clients. Audit and remove previously configured trusted-service exceptions or resource-instance rules that are not required, because these can retain access.

Firewall rules

When the firewall is on, you can allow:

• Virtual network rules: specific subnets with an Azure Storage service endpoint enabled (Microsoft.Storage for regional access or Microsoft.Storage.Global for cross-region access). A subnet can use one of these endpoint types at a time. Traffic then travels over the Azure backbone with the subnet identity.
• IP network rules: public IPv4 addresses or CIDR ranges, for example your office egress address. Private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not allowed in IP rules; to reach storage from private addresses you use a service endpoint or a private endpoint instead.
• Resource instance rules: specific Azure resources (for example one Azure Synapse workspace or one Data Factory) identified by resource ID in the storage account's tenant, with data permissions assigned to their managed identity.
• Exceptions: Allow trusted Microsoft services, and allow read access to storage logging and metrics. Trusted services include Azure Backup, Azure Site Recovery and Azure Monitor, for example.

az storage account update --name stcontosoprod01 --resource-group rg-data \
  --public-network-access Enabled --default-action Deny

az storage account network-rule add --account-name stcontosoprod01 \
  --resource-group rg-data --ip-address 203.0.113.0/24

az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --service-endpoints Microsoft.Storage

subnetId="$(az network vnet subnet show --resource-group rg-net \
  --vnet-name vnet-app --name snet-web --query id --output tsv)"
az storage account network-rule add --account-name stcontosoprod01 \
  --resource-group rg-data --subnet "$subnetId"

Important behaviors:

• Storage network rules restrict data-plane traffic through the public endpoint, including REST and SMB. They do not filter private-endpoint traffic or ARM management requests; configure private-endpoint routing, DNS and authorization separately.
• The firewall evaluates the source of the request. A VM in a different region than the storage account that uses its public IP address is evaluated by that public address, and same-region traffic from a VM's public IP is not matched by IP rules because it arrives via private Azure addresses. This is why a subnet rule via service endpoint, not an IP rule, is used for Azure VMs.
• The portal, Azure Storage Explorer and tools running on your laptop are also blocked unless your client IP is added. A frequent support case is "I locked the account and now I cannot see the data in the portal."
• Virtual network rules can reference subnets across subscriptions and Microsoft Entra tenants when the administrator has the necessary permissions. Resource-instance rules, in contrast, require the same tenant. Enable the appropriate service endpoint on the subnet first.

Service endpoints versus private endpoints

Use a private endpoint when you need on-premises access, data exfiltration protection or to disable the public endpoint. Use a service endpoint when the clients are in Azure subnets and the simplest, free option is enough.

For the routing and DNS design behind private access, see securing Azure virtual network access.

Worked example: locking down a data account

Scenario. Contoso's account stcontosoprod01 holds order exports. Only the application subnet snet-web and a finance analyst working from the office (203.0.113.40) should reach it. Azure Backup must still be able to back up its file shares.

Steps.

1. In Networking, select Enabled from selected virtual networks and IP addresses (default action Deny).
2. Enable the Microsoft.Storage service endpoint on snet-web, then add the subnet under Virtual networks.
3. Add 203.0.113.40 as an IP rule.
4. Under Exceptions, keep Allow Azure services on the trusted services list to access this storage account checked so that Azure Backup keeps working.
5. Give the allowed application and analyst the required data roles, configure Azure Backup's permissions, then test both network and authorization. With valid credentials, the VM in snet-web succeeds and a laptop on an unapproved network fails. The trusted-service exception does not itself grant access to the files.

Why not a private IP rule? Private ranges cannot be used in IP rules, and snet-web uses 10.1.0.0/24, so a subnet rule via service endpoint is the correct tool. Why not disable public access? That would also block the analyst, who is not on a private network, unless a VPN and a private endpoint are added, which is more than required.

Access keys

Each storage account has two access keys (key1, key2), each 512-bit. Anyone holding an enabled key has broad data-plane access and can sign service or account SAS tokens. Keys cannot be scoped per application, and they do not grant ARM management permissions or bypass network restrictions.

• Two keys exist so you can rotate without downtime: update applications to key2, regenerate key1, then repeat the next cycle.
• Regenerating a key immediately invalidates every account SAS and every service SAS signed with it, and breaks any application or connection string still using it.
• Store keys in Azure Key Vault. A storage account can be configured with a key expiration policy that flags keys (in Azure Policy and Advisor reports) that are older than a set number of days. A key expiration policy is a reminder, not automatic rotation or key invalidation. Key Vault's legacy managed-storage-account-key feature is deprecated; use a maintained rotation workflow for clients that still need keys, or migrate to Entra authorization.
• Microsoft recommends disabling Shared Key authorization (allowSharedKeyAccess = false) when all clients can use Entra ID. After you disable it, requests signed with a key, service SAS and account SAS are denied; user delegation SAS requests on Blob Storage continue to work. Check dependencies first, since some features and tools (for example, certain Azure Files and legacy tooling scenarios) still depend on keys.

az storage account keys renew --account-name stcontosoprod01 --resource-group rg-data --key key1
az storage account update --name stcontosoprod01 --resource-group rg-data --allow-shared-key-access false

Shared access signatures

A shared access signature (SAS) is a signed URI (the token is the query string) that delegates restricted access to storage resources. The token carries the allowed services/resource types, permissions, start and expiry time, allowed IP range, allowed protocol (HTTPS only) and a signature.

The three SAS types

Microsoft recommends the user delegation SAS wherever possible, because it avoids account-key credentials. Removing the signer's permissions or revoking delegation keys invalidates affected tokens, but cached keys and RBAC assignments mean revocation is not necessarily immediate. Current REST documentation includes Queue, Table and Azure Files; some older overview pages and clients retain narrower support. Confirm client compatibility for those services. User-bound delegation SAS (sduoid, version 2025-07-05 or later) additionally requires the designated user's Entra token; an ordinary user delegation SAS remains a bearer credential.

A deliberately shortened, line-wrapped SAS URI illustrates the fields below; it is not a usable token:

https://stcontosoprod01.blob.core.windows.net/exports/orders.csv
  ?sv=2024-11-04&spr=https&st=2026-10-27T08:00Z&se=2026-10-27T12:00Z
  &sr=b&sp=r&sip=203.0.113.0-203.0.113.255&sig=...

Reading it: sr=b a single blob, sp=r read-only, valid four hours, only from the office range, HTTPS only.

expiry="$(date -u -d '+2 hours' '+%Y-%m-%dT%H:%MZ')"
az storage blob generate-sas --account-name stcontosoprod01 --container-name exports \
  --name orders.csv --permissions r --expiry "$expiry" \
  --https-only --auth-mode login --as-user

Run this example in Bash with GNU date, such as Azure Cloud Shell. The --auth-mode login --as-user combination creates a user delegation SAS using your Entra identity, with no key.

Key facts:

• Azure does not keep an inventory of issued SAS tokens. If you have the token, you can inspect its fields, but cannot enumerate every issued token from the account. Revocation depends on the type: rotate the signing account key, modify/delete a referenced stored policy, or revoke user delegation keys/change the signer's permissions. Network controls can block requests separately.
• A SAS cannot grant more than its signer holds; for a user delegation SAS, the signer needs a role with generateUserDelegationKey rights, such as Storage Blob Delegator, plus data permissions. The delegation-key permission must apply at storage-account scope or above, even when data access is scoped to one container. Token validity must fit within the delegation key's maximum seven-day lifetime.
• Always use short expiry, minimal permissions, HTTPS only and, where possible, an IP range.

Stored access policies

A stored access policy defines start time, expiry time and permissions on the container, file share, queue or table, and a service SAS can reference it by its si (signed identifier) value instead of embedding those values.

Why it matters: an ad hoc service SAS with embedded permissions and expiry has no stored policy to revoke; rotating its signing account key invalidates it. If it references a stored policy, you can modify or delete the policy to change or revoke every associated service SAS, allowing for propagation.

• A container, share, queue or table can hold up to five stored access policies.
• Stored access policies apply only to service SAS. Account SAS and user delegation SAS cannot reference them.
• Creating or updating a container policy can take up to 30 seconds to propagate. Omitting an immediate start time helps with clock skew, but does not eliminate propagation delay.

az storage container policy create --account-name stcontosoprod01 --container-name exports \
  --name partner-read --permissions rl --expiry 2026-12-31T00:00Z \
  --account-key "$AZURE_STORAGE_KEY"

az storage blob generate-sas --account-name stcontosoprod01 --container-name exports \
  --name orders.csv --policy-name partner-read --https-only \
  --account-key "$AZURE_STORAGE_KEY"

These service-SAS examples assume Shared Key is allowed and the signing key has been securely supplied through AZURE_STORAGE_KEY; do not embed a real key in source files. To revoke the policy-linked tokens, delete that named policy:

az storage container policy delete --account-name stcontosoprod01 \
  --container-name exports --name partner-read --account-key "$AZURE_STORAGE_KEY"

Worked example: revoking a partner's access

Scenario. A logistics partner receives a SAS URL for the exports container valid for 90 days. After 10 days the contract is canceled. The SAS was signed with key1 as a service SAS and embeds its own permissions and expiry. You must stop access today without disrupting the company's own applications that use the account key.

Reasoning.

1. The SAS embeds its parameters, so there is no policy to delete.
2. Regenerating the account key would invalidate the SAS but would also break the internal applications that use that key. The requirement forbids that disruption, unless they were moved to key2 first.
3. Best path: inventory key1 dependencies, switch those applications to key2 and confirm they have reloaded the credential; then regenerate key1, which invalidates the SAS signed with key1.
4. For the future: issue partner access as a service SAS tied to a stored access policy, or better, a user delegation SAS with a short lifetime. Then revocation means deleting a policy or revoking the delegation key.

Why other options are weaker. Waiting for 90 days leaves the partner with access. Deleting the container destroys data. A firewall can separately restrict allowed source networks, but does not revoke this token. It is an allow-list, and blocking a shared egress address might disrupt other clients. Rotating the known signing key after migrating its dependencies meets the requirement.

Identity-based access for Azure Files

Azure Files shares over SMB can authenticate users with identities instead of the storage account key. Three identity sources are supported:

The current Entra Kerberos setup guide documents cloud-only users in Azure Public and lists supported Windows versions and updates. It does not extend cloud-only support to Azure Government or Azure China. Azure Files also documents keyless SMB access for application managed identities: enable SMBOAuth, use supported clients and assign the documented Storage File Data SMB MI Admin role. That application flow is separate from the three user identity sources and can coexist with them.

For normal user access through the SMB Share roles, authorization has two layers, and both must allow the operation:

1. Share-level permission (Azure RBAC): assign Storage File Data SMB Share Reader, Storage File Data SMB Share Contributor, Storage File Data SMB Share Elevated Contributor (can also change NTFS permissions), to users or groups on the share or account. Privileged/admin roles can bypass ACL checks and should be reserved for the documented administrative scenarios.
2. File/directory-level permission (Windows NTFS ACLs): set with icacls or Windows File Explorer with an identity authorized to modify ACLs. A storage account key is an administrative alternative, not a mandatory first mount. For cloud-only users, follow the documented portal/REST ACL workflow instead of assuming Windows File Explorer supports it.

Practical rules:

• SMB requires TCP port 445 open between client and storage. Many ISPs and some corporate networks block outbound 445; use a VPN or ExpressRoute path to a file private endpoint when internet egress blocks this port. A private endpoint alone does not tunnel around an ISP block: SMB still uses TCP 445 over the private route.
• Enable identity-based authentication on the account (az storage account update --name "$accountName" --resource-group "$resourceGroup" --enable-files-aadkerb true for Entra Kerberos), complete the documented application consent and client prerequisites, then assign roles and configure ACLs.
• The storage account key still works as a super-admin credential. A user mounting with the key bypasses identity-based checks, so protect the keys.
• Azure Files NFS shares do not use these identity sources; they use network controls and POSIX UID/GID permissions, including the configured root-squash behavior.
• Default share-level permission can be set for all authenticated identities when you do not want per-user assignments.

For share configuration and blob data protection beyond access control, continue with Azure Files and Azure Blob Storage.

Pitfalls and exam tips

• Private IP addresses cannot go in a storage IP rule. Use a service endpoint or private endpoint.
• Service endpoint vs private endpoint: on-premises access or fully disabling the public endpoint means private endpoint.
• Regenerating a key kills every SAS signed by it. Rotate with two keys to avoid downtime.
• Only service SAS can use stored access policies, and only five per resource.
• User delegation SAS is the recommended SAS, signed with Entra credentials, valid up to seven days.
• Disabling Shared Key denies account and service SAS but not blob user delegation SAS.
• For Azure Files: share-level RBAC and NTFS permissions are both required; port 445 must be reachable.
• A firewall that "locks you out" of the portal means your client IP or network is not in the rules.
• Do not confuse Storage Account Contributor (management plane; can list keys) with a Storage Blob Data role (data plane).

Mini case study: Tailwind Traders' HR documents

Tailwind Traders stores HR documents in the blob container hr of sthrdocs01 and shares an Azure Files share payroll with finance PCs. Requirements:

1. The HR web app (App Service with managed identity) reads and writes blobs; no secrets in configuration.
2. Auditors from an external firm need read access to one blob for 48 hours, through the corporate VPN, whose public egress is 198.51.100.0/24.
3. Finance users with hybrid identities synced from AD DS, using supported Entra-joined laptops, must mount payroll with their own accounts, and only the finance group may change files.
4. The account must not be reachable from the internet except from the corporate network 198.51.100.0/24.

Solution.

1. Assign Storage Blob Data Contributor on the container to the web app's managed identity. No keys, no SAS.
2. Generate a user delegation SAS (sp=r, sr=b, 48-hour expiry, sip=198.51.100.0-198.51.100.255, HTTPS only). Restrict sip to the corporate VPN egress range. Revoking delegation keys or the signer's permissions can invalidate it, subject to cache propagation.
3. Enable Entra Kerberos identity-based authentication for the account, assign Storage File Data SMB Share Contributor to the finance group at share scope, leave broad default share access disabled, and set directory/file ACLs so only finance can modify. Do not grant unrelated users access. Provide the private file endpoint and VPN routing/DNS needed for TCP 445.
4. Set the firewall to selected networks with an IP rule for 198.51.100.0/24 and integrate App Service with a VNet that can reach an approved blob private endpoint, with working private DNS. The managed identity grants data access but does not bypass the firewall. The auditors use the permitted corporate VPN egress; finance reaches the file private endpoint through its VPN. Remove unused network exceptions and disable Shared Key after validating all dependencies.

Commentary. Notice that no requirement needed account keys. Each need maps to the narrowest tool: managed identity RBAC for an application, user delegation SAS for a temporary external user, identity-based SMB for people, and the firewall for the network boundary.

Key terms

• Storage firewall: network rules that restrict which sources can connect to the account.
• Service endpoint: subnet-level route to a public Azure service using the subnet's identity.
• Private endpoint: private IP in your VNet mapped to one storage sub-resource.
• Access key: 512-bit shared secret with full account access.
• SAS: signed URI granting limited, time-bound access.
• User delegation SAS: SAS signed with Entra credentials.
• Stored access policy: server-side definition a service SAS can reference, enabling revocation.
• Entra Kerberos: identity-based SMB authentication for supported clients and hybrid or cloud-only user identities.

Summary checklist

• I can configure firewall rules with subnets, IP ranges, resource instances and trusted services.
• I can say when to use a service endpoint versus a private endpoint.
• I can rotate access keys with no downtime and explain what regeneration breaks.
• I can differentiate user delegation, service and account SAS and pick the safest.
• I know how stored access policies enable revocation, and their limits.
• I can describe the two permission layers for identity-based access to Azure Files.
• I know port 445 must be open for SMB.

Official sources

• Study guide for Exam AZ-104 (opens in a new tab)

• Grant limited access with shared access signatures (opens in a new tab)

• Prevent authorization with Shared Key (opens in a new tab)

• Authorize operations for data access (opens in a new tab)

• What's new in Azure Files and Azure File Sync (opens in a new tab)

• Configure Azure Storage firewalls and virtual networks (opens in a new tab)

• Create a user delegation SAS: current REST capabilities and revocation (opens in a new tab)

• Azure CLI user delegation SAS example (opens in a new tab)

• Storage firewall limitations (opens in a new tab)

• Set Container ACL and stored-policy propagation (opens in a new tab)

• Configure Microsoft Entra Kerberos for Azure Files (opens in a new tab)

• Managed identities for SMB Azure Files (opens in a new tab)

• Key Vault data types and deprecated managed storage keys (opens in a new tab)