This chapter covers Azure Storage security mechanisms: shared access signatures (SAS), storage account keys, and firewall rules. These are critical for controlling access to storage accounts in a least-privilege manner. On the AZ-104 exam, approximately 10-15% of questions touch storage security, often testing your ability to choose between SAS types, understand key rotation, and configure network access restrictions. Mastering these concepts is essential for securing data in Azure.
Jump to a section
Imagine a gated community (your storage account) with multiple houses (blobs, files, queues, tables). The community has a main gate (firewall) that blocks all traffic by default. To get in, you need either a key card (storage account key) that unlocks every house, or a temporary visitor pass (SAS token) that grants access only to specific houses for a limited time. The community manager (Azure) issues these keys and passes. If you lose your key card, anyone can enter all houses. A SAS token is like a timed visitor pass: it might say 'House 3, back door, 2 PM to 4 PM, can open but not repaint.' The firewall also has a whitelist: only visitors from certain streets (IP ranges) are allowed past the main gate. If you try to enter from an unapproved street, the guard (firewall) turns you away even if you have a valid pass. In production, you might have a delivery truck (Azure service) that needs daily access; you give it a long-term SAS token stored in Azure Key Vault, not a key card.
Overview of Azure Storage Security
Azure Storage provides multiple layers of security. At the network level, firewall rules restrict access to specific IP addresses or virtual networks. At the authentication level, storage account keys and SAS tokens control who can access data. All storage accounts are accessible over HTTPS by default, and encryption at rest is enabled automatically. The exam focuses on understanding when to use each mechanism and how they interact.
Storage Account Keys
Each storage account has two keys: key1 and key2. These are 512-bit random strings that grant full control over the storage account. Anyone with a key can read, write, and delete any data in blobs, files, queues, and tables. They can also regenerate keys, modify firewall rules, and access the account metrics. Because of this power, keys should be treated like passwords and rotated regularly. The two-key design allows rotation without downtime: you can regenerate key1 while applications use key2, then switch to key1 after regeneration.
Shared Access Signatures (SAS)
A SAS is a URI that grants restricted access to storage resources for a limited time. It includes a token containing authentication information. There are three types: - Service SAS: Grants access to a specific resource (e.g., a blob, container, queue). - Account SAS: Grants access to service-level operations (e.g., list containers, create tables) and can also grant service-level access. - User Delegation SAS: A service SAS secured with Azure AD credentials (blob storage only).
A SAS token includes parameters like: - sv: Storage service version - se: Expiry time (UTC) - sr: Resource type (b for blob, c for container, etc.) - sp: Permissions (r for read, w for write, d for delete, l for list, etc.) - spr: Allowed protocol (https only or https,http) - sip: Allowed IP ranges - sig: Signature (HMAC-SHA256 of the string-to-sign using the account key)
Default values: If no expiry is specified, the SAS is valid for one hour (for service SAS) or 24 hours (for account SAS) from creation. You can set expiry up to the maximum allowed (typically 1 year from creation for service SAS, but adjustable).
Stored Access Policies
A stored access policy is a server-side policy that provides an additional layer of control over SAS tokens. You can define a policy on a container, queue, table, or share with start time, expiry time, and permissions. When you create a SAS, you can reference a stored access policy ID. The SAS then inherits the policy's settings. This allows you to revoke a SAS without regenerating the key – simply modify or delete the stored access policy. Without a stored access policy, revoking a SAS requires regenerating the storage account key.
Firewall Rules
Azure Storage firewalls allow you to restrict access to your storage account based on source IP addresses or virtual network service endpoints. By default, all networks are allowed. When you enable firewall rules, you must explicitly allow traffic. You can:
Allow traffic from specific IP addresses (IPv4 or IPv6 ranges)
Allow traffic from selected virtual networks (using service endpoints)
Allow trusted Microsoft services (e.g., Azure Backup, Azure Site Recovery) – this is a special checkbox that bypasses the firewall for specific services
Important: Firewall rules apply to the data plane (blob, file, queue, table) and the management plane (e.g., listing keys) is controlled by Azure RBAC. Also, firewall rules do not block access from within the same region if the client is using a public IP – you must explicitly block all networks and add exceptions.
How It All Interacts
When a client requests access to a storage account: 1. The firewall checks if the request source IP is allowed. If not, the request is denied regardless of authentication. 2. If the request passes the firewall, authentication is checked. If using a storage account key, full access is granted. If using a SAS, the token is validated (signature, expiry, permissions, allowed IPs). 3. If a stored access policy is referenced, the policy's constraints override any overlapping constraints in the SAS token (e.g., if the SAS says expiry in 1 hour but the policy says 30 minutes, the policy wins). 4. If using Azure AD authentication (for blobs and queues), the request is authorized via RBAC.
Configuration and Verification
You can configure these settings via Azure Portal, Azure CLI, or PowerShell.
Generate a SAS token using Azure CLI:
az storage container generate-sas --account-name mystorageaccount --name mycontainer --permissions rwl --expiry 2025-12-31T23:59:00Z --https-onlyCreate a stored access policy using PowerShell:
$ctx = New-AzStorageContext -StorageAccountName "mystorageaccount" -StorageAccountKey (Get-AzStorageAccountKey -ResourceGroupName "myrg" -AccountName "mystorageaccount").Value[0]
New-AzStorageContainerStoredAccessPolicy -Container "mycontainer" -Policy "mypolicy" -Permission rw -StartTime "2025-01-01" -ExpiryTime "2025-12-31" -Context $ctxConfigure firewall rules via Azure CLI:
az storage account network-rule add --account-name mystorageaccount --ip-address 192.168.1.0/24
az storage account update --default-action Deny --name mystorageaccountBest Practices
Use SAS tokens instead of storage account keys for delegated access.
Use stored access policies to enable revocation.
Use HTTPS only for SAS tokens (set --https-only).
Rotate storage account keys regularly (e.g., every 90 days).
Enable firewall rules and block all public access unless necessary.
For production, use managed identities and Azure AD authentication where possible.
Exam-Relevant Details
The maximum SAS expiry time without a stored access policy is 1 year from creation (for service SAS) but can be longer with a policy.
SAS tokens can be restricted to specific IP ranges using the sip parameter.
Account SAS can be used to perform management operations like listing containers, which service SAS cannot.
User delegation SAS requires Azure AD authentication and is only for blob storage.
Firewall rules support up to 200 IP rules and 200 virtual network rules per storage account.
The "Allow trusted Microsoft services" exception includes services like Azure Backup, Azure Site Recovery, and Azure Logic Apps. It does NOT include Azure VMs or other customer workloads.
Enable firewall and deny all
In the Azure Portal, navigate to your storage account's Networking blade. Under Firewalls and virtual networks, select 'Selected networks'. By default, this will deny all traffic except from allowed IPs and VNets. Click 'Add your client IP address' to avoid locking yourself out. Then click Save. This changes the storage account's default action from Allow to Deny, meaning only explicitly permitted sources can connect. The portal uses your current public IP to add an exception.
Add allowed IP ranges
Under the Firewall section, you can add specific IPv4 or IPv6 address ranges. For example, add 203.0.113.0/24 to allow traffic from that subnet. Each rule is a CIDR block. You can add up to 200 IP rules. The firewall checks the source IP of each request; if it matches any rule, the request proceeds to authentication. If not, a 403 (Forbidden) error is returned. The portal also allows you to add virtual network rules by selecting a VNet and subnet that have a Microsoft.Storage service endpoint configured.
Configure a stored access policy
Navigate to the container (or queue, table, share) under the storage account. In the Settings section, select 'Access policy'. Click 'Add policy' and specify a policy ID (e.g., 'readonly'), permissions (e.g., Read, List), start time, and expiry time. The start and expiry times are in UTC. Once saved, the policy exists on the server. You can then create a SAS token that references this policy ID. The SAS token's permissions and expiry are overridden by the policy. To revoke access, you can delete or modify the policy without regenerating keys.
Generate a SAS token with policy
Using Azure Storage Explorer, Azure CLI, or SDK, create a SAS token that includes the `signedidentifier` parameter set to the policy ID. For example, with Azure CLI: `az storage container generate-sas --account-name mystorageaccount --name mycontainer --policy-name mypolicy --https-only`. The generated SAS URI will include `?sv=...&se=...&sr=c&sig=...` but note that the `se` and `sp` parameters are derived from the policy. The token is valid only if the policy exists and hasn't expired. This method allows you to issue multiple tokens with the same policy and revoke them all at once.
Test access with SAS token
Use a tool like curl or a browser to access a blob using the SAS URL. For example: `curl "https://mystorageaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2018-03-28&se=2025-12-31T23%3A59%3A00Z&sr=b&sp=r&sig=..."`. If the SAS is valid and the firewall allows the source IP, the blob content is returned. If the SAS is expired, you get a 403 (AuthenticationFailed). If the firewall blocks the IP, you get a 403 (NetworkAuthenticationFailed) – note the different error message. This distinction is important for troubleshooting.
Enterprise Scenario 1: Secure Data Sharing with External Partners
A company needs to share monthly reports stored in Azure Blob Storage with external auditors. The auditors should only be able to read specific blobs for a limited time. The company creates a container with a stored access policy that allows read and list permissions, valid for 30 days. They then generate a service SAS token referencing that policy and email the SAS URL to the auditors. The storage account firewall is configured to allow only the auditors' office IP range and the Azure portal IP for management. If the auditors' IP changes, the company updates the firewall rule. If the audit is completed early, the company deletes the stored access policy, instantly revoking the SAS. This approach avoids sharing storage account keys and provides granular control.
Enterprise Scenario 2: Application Access with Managed Identity
A web app running on Azure App Service needs to read images from a blob container. Instead of using storage account keys or SAS tokens, the developer enables managed identity for the App Service and assigns the 'Storage Blob Data Reader' role to the identity. The storage account firewall is configured to allow access only from the App Service's outbound IP addresses (using a service endpoint or by adding the App Service's outbound IPs). This eliminates the need to manage keys or SAS tokens. The app uses Azure AD authentication to obtain an access token. This is the most secure approach as it avoids static credentials. However, it requires the storage account to support Azure AD (blob and queue only).
Scenario 3: IoT Device Telemetry Ingestion
A company collects telemetry from thousands of IoT devices that write data to an Azure Storage queue. Each device needs a unique SAS token with write-only permission to a specific queue. The company uses an account SAS because it allows creation of tokens that can write to any queue without knowing the queue name at generation time. The SAS tokens have a short expiry (e.g., 24 hours) and are rotated daily via a background job. The storage account firewall allows only the IoT devices' IP ranges (which are dynamic, so they use a large CIDR block). If a device is compromised, its SAS token can expire naturally, and the device's IP can be blocked via firewall. This setup scales to millions of devices but requires careful planning of token lifetimes and IP ranges.
What AZ-104 Tests on This Topic
Exam objective: Configure Azure Storage security (2.3). The exam focuses on differentiating between SAS types, understanding when to use stored access policies, and configuring firewall rules. You will see scenario-based questions where you must choose the most secure or appropriate access method.
Common Wrong Answers and Traps
Choosing a SAS when a stored access policy is needed: Many candidates think a SAS alone provides revocation capability. Reality: Without a stored access policy, revoking a SAS requires regenerating the storage account key, which breaks all existing SAS tokens. The exam loves to test this: if the requirement is to revoke access without affecting other tokens, you must use a stored access policy.
Selecting an account SAS when a service SAS suffices: Account SAS grants broader permissions (e.g., list containers). If the requirement is only to access a specific blob, a service SAS is more restrictive and thus more secure. The exam will present a scenario where a candidate chooses account SAS for simplicity, but the correct answer is service SAS.
Forgetting the firewall exception for trusted Microsoft services: When configuring firewall rules, candidates often forget to enable 'Allow trusted Microsoft services' for services like Azure Backup. The exam may present a scenario where a backup fails after enabling firewall, and the solution is to enable this exception.
Assuming SAS tokens are secure without HTTPS: The exam may include a question where a SAS token is generated without the HTTPS-only flag. The correct answer is to use HTTPS only to prevent token interception.
Specific Numbers and Terms
Maximum SAS expiry without stored access policy: 1 year from creation.
Default SAS expiry: 1 hour (service), 24 hours (account).
Maximum IP rules: 200 per storage account.
Maximum virtual network rules: 200 per storage account.
Permissions: r (read), w (write), d (delete), l (list), a (add), c (create), u (update), p (process).
User delegation SAS: only for blob storage, uses Azure AD.
Edge Cases
If you use a SAS token with a stored access policy, and the policy is deleted, the SAS token becomes invalid immediately.
If you regenerate a storage account key, all SAS tokens generated with that key (without stored access policy) become invalid.
Firewall rules do not apply to requests from within the same Azure region if the client uses a public IP – you must explicitly add a deny rule.
The 'Allow trusted Microsoft services' exception does not include Azure VMs. If you need to allow a VM, you must add its public IP or use a service endpoint.
How to Eliminate Wrong Answers
If the question mentions 'revoke access without regenerating keys', the answer must involve a stored access policy.
If the question requires the most restrictive access, choose service SAS over account SAS, and choose SAS over account keys.
If the question involves a service like Azure Backup, look for the 'Allow trusted Microsoft services' checkbox.
If the question mentions 'temporary access for a specific client IP', use a SAS token with the sip parameter.
Storage account keys grant full control; use SAS for delegated access.
SAS tokens without a stored access policy cannot be revoked without regenerating keys.
Stored access policies allow centralized management and revocation of SAS tokens.
Firewall rules must explicitly set default action to 'Deny' to block traffic.
Maximum 200 IP rules and 200 virtual network rules per storage account.
User delegation SAS is only for blob storage and uses Azure AD authentication.
Always use HTTPS-only for SAS tokens to prevent interception.
These come up on the exam all the time. Here's how to tell them apart.
Storage Account Key
Full control over storage account
Cannot be scoped to specific resources
Cannot have expiry time
Revocation requires regenerating key
Shared secret, must be stored securely
Shared Access Signature (SAS)
Granular permissions (read, write, etc.)
Scoped to specific resource (blob, container, etc.)
Can have expiry time (up to 1 year without policy)
Can be revoked via stored access policy (if used)
Token can be included in URL, no secret exposure
Service SAS
Grants access to a specific service resource (blob, container, queue, table)
Cannot list containers or tables
Cannot create new containers
More secure for fine-grained access
Can be associated with a stored access policy
Account SAS
Grants access to service-level operations (list, create, etc.)
Can list and create containers/tables/queues
Can also grant access to individual resources
Less secure if not needed
Cannot be associated with a stored access policy
Mistake
SAS tokens can be revoked at any time without regenerating keys.
Correct
Only SAS tokens that reference a stored access policy can be revoked by modifying or deleting the policy. Tokens without a policy cannot be revoked without regenerating the storage account key.
Mistake
Storage account keys and SAS tokens are interchangeable in terms of security.
Correct
Storage account keys grant full control over the entire storage account. SAS tokens are scoped to specific resources and permissions, making them more secure for delegated access.
Mistake
Firewall rules block all traffic by default when enabled.
Correct
When you enable firewall rules, you must set the default action to 'Deny'. The default action is 'Allow' until you change it. Only after setting to 'Deny' does the firewall block all traffic except explicit exceptions.
Mistake
The 'Allow trusted Microsoft services' exception allows all Azure services.
Correct
It only allows specific Microsoft services like Azure Backup, Azure Site Recovery, and Azure Logic Apps. It does not allow Azure VMs, App Service, or other customer workloads.
Mistake
A SAS token with a stored access policy can have longer expiry than the policy allows.
Correct
The stored access policy overrides the SAS token's expiry. If the policy has a shorter expiry, the token expires when the policy says, not when the token's `se` field indicates.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You must use a stored access policy. Create a policy on the container (or queue/table/share) and reference it when generating the SAS token. To revoke, modify or delete the policy. Without a policy, you cannot revoke a SAS token without regenerating the key.
A service SAS grants access to a specific resource like a blob or container. An account SAS grants access to service-level operations like listing containers or creating tables, and can also grant access to resources. Use service SAS for fine-grained access; account SAS for broader administrative tasks.
Yes, but the client's IP must be allowed by the firewall rules. The SAS token itself does not bypass the firewall. The firewall checks the source IP before authentication.
Without a stored access policy, the maximum expiry is 1 year from creation. With a stored access policy, the expiry is determined by the policy, which can be longer (e.g., 10 years). Default expiry without specifying is 1 hour for service SAS and 24 hours for account SAS.
It allows specific Azure services like Azure Backup, Azure Site Recovery, and Azure Logic Apps to access the storage account even if the firewall blocks all other traffic. It does not allow Azure VMs or other customer-owned services.
Yes, for blob and queue storage. You can assign RBAC roles to users or managed identities. This is the most secure method as it avoids static credentials. However, it is not supported for file shares or tables.
All SAS tokens generated with that key (without a stored access policy) become invalid. Any applications using the old key will lose access. You should update applications to use the new key or use the second key during rotation.
You've just covered Securing Azure Storage (SAS, Keys, Firewall) — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?