Securing Storage: Keys, SAS & Firewalls
Storage accounts hold your most valuable data. Learn the five ways to control access — account keys, SAS tokens, stored access policies, firewalls, and identity-based access — and when to use each.
How storage access works
Securing a storage account is like securing a bank vault with multiple layers.
Layer 1: Account keys — the master key. Anyone with it has full access. Keep it secret. Layer 2: SAS tokens — temporary, limited-access passes. Like giving a courier a time-limited pass to pick up one specific package. Layer 3: Firewalls — only allow access from specific networks or IP addresses. Layer 4: Identity-based access — use Entra ID to grant specific permissions to specific people (most secure).
Access methods compared
| Method | Scope | Best For |
|---|---|---|
| Account key | Full access to everything | Backend services, legacy apps |
| SAS token | Specific resource, time-limited, permission-limited | Temporary client access, external sharing |
| Stored access policy | Manages SAS tokens centrally (can revoke) | Controlling SAS lifecycle at container/share level |
| Entra ID + RBAC | Per-user/group permissions via roles | Production applications, human access |
| Storage firewall | Network-level restriction | Restricting access to specific VNets/IPs |
Account keys
Every storage account has two access keys (Key1 and Key2). Either key grants full access to the entire storage account.
Why two keys? For key rotation without downtime:
- Apps use Key1
- Regenerate Key2 (it changes)
- Update apps to use Key2
- Regenerate Key1
- Now both keys are new, and there was zero downtime
Exam tip: Key rotation best practices
The exam tests whether you understand key rotation. Two keys exist specifically so you can rotate without downtime. If a question says “regenerate key1 while applications are using key1” — the answer is “applications will break until they’re updated to use the new key.” Always switch apps to key2 FIRST, then regenerate key1.
Also: consider disabling shared key access entirely and using Entra ID authentication instead. You can do this in the storage account’s Configuration settings.
Shared Access Signatures (SAS)
A SAS token is a URI that grants restricted access rights to storage resources. It specifies what can be accessed, what operations are allowed, and when the access expires.
Three types of SAS:
| SAS Type | Scope | Key It Uses |
|---|---|---|
| Account SAS | Entire storage account (services, containers, objects) | Account key |
| Service SAS | Specific service (blob, file, table, or queue) | Account key |
| User delegation SAS | Blob and container only | Entra ID credentials (most secure) |
SAS parameters:
sv— storage service versionss— services (blob, file, table, queue)srt— resource types (service, container, object)sp— permissions (read, write, delete, list, etc.)se— expiry timest— start timesig— signature (cryptographic hash)
Exam tip: User delegation SAS is the most secure
When the exam asks for the “most secure” SAS option, the answer is usually User delegation SAS. It uses Entra ID credentials instead of the account key, meaning you don’t risk exposing the master key. However, it only works for Blob Storage.
Stored access policies
A stored access policy provides additional control over SAS tokens. Instead of embedding all constraints in the SAS URI, you create a policy on the container (or share, table, queue) and link the SAS to it.
Key benefit: You can revoke a stored access policy, which immediately invalidates all SAS tokens linked to it. Without a stored access policy, the only way to revoke a SAS is to regenerate the account key (which breaks everything else using that key).
| Without Stored Access Policy | With Stored Access Policy |
|---|---|
| SAS constraints baked into the URI | Constraints defined in the policy |
| Cannot revoke individual SAS | Can revoke by deleting/modifying the policy |
| Must regenerate account key to revoke | Granular revocation |
Storage firewalls and virtual networks
The storage firewall controls which networks can access the storage account endpoints.
Options:
- Allow access from all networks (default — least secure)
- Allow access from selected virtual networks and IP addresses — VNet rules + IP rules
- Disable public access — only private endpoints can reach it
VNet service endpoints allow VNet subnets to access storage over the Azure backbone (not the public internet). The storage firewall references the VNet/subnet to allow access.
Real-world: Meridian Financial's storage security
Meridian Financial’s production storage accounts use:
- Shared key access: Disabled (Entra ID only)
- Firewall: Selected networks only (production VNet subnets)
- Data access: Entra ID RBAC roles (Storage Blob Data Reader/Contributor)
- Temporary external access: User delegation SAS with stored access policies
- All requests require HTTPS (HTTP disabled)
This layered approach means even if someone gets the storage account name, they can’t access it without being on the right network AND having the right Entra ID permissions.
Identity-based access for Azure Files
Azure Files supports identity-based authentication for SMB file shares using:
- On-prem AD DS (via Entra Connect)
- Microsoft Entra Domain Services (managed domain service)
- Microsoft Entra Kerberos (for hybrid identities)
This means users can mount Azure File shares with their existing AD credentials — just like on-prem file servers.
Knowledge check
TechCorp Solutions needs to give a third-party analytics vendor temporary read-only access to blobs in a specific container for 7 days. The security team requires the ability to revoke access immediately if needed. What should Alex configure?
Meridian Financial wants to ensure their production storage account can ONLY be accessed from VMs running in their production VNet. What should they configure?
🎬 Video coming soon