5.2 Storage Firewalls and Access Policies
Key Takeaways
- Storage firewall rules restrict the public data-plane endpoint by IP ranges, virtual network subnets (with service endpoints), resource instances, and optional trusted Microsoft service exceptions.
- Private endpoints (Private Link) place storage access on a private IP in your VNet; combining private endpoints with disabled public network access is the strongest network isolation pattern.
- SAS types differ by signing credential: user delegation (Entra), service (account key, one service), and account (account key, multi-service)—prefer user delegation and short lifetimes.
- Stored access policies on containers/shares enable revocable service SAS; ad hoc key-signed SAS without a policy cannot be selectively revoked without regenerating keys.
- Data-plane Azure RBAC roles (Storage Blob Data Reader/Contributor/Owner, etc.) authorize Entra principals independently of control-plane Contributor on the storage resource.
Network Boundary Plus Authorization
Identity alone is not enough. SC-500 expects you to configure Azure Storage firewall rules, use private endpoints, and manage access policies (SAS and RBAC). A request succeeds only when network path and authorization both allow it.
Default posture for many accounts is still “public endpoint reachable from any network, if the caller has a key or token.” Hardening flips the default to deny, then allows known sources.
Storage Firewall Rules
The storage firewall governs access to the account’s public endpoint. When network rules are active, only listed sources may connect; other public traffic receives denial (typically HTTP 403), even with a valid key or token.
| Rule type | What it allows | Notes |
|---|---|---|
| IP network rules | Public IPv4 ranges (on-prem NAT, partner egress) | Up to hundreds of rules per account; not for private RFC1918 ranges as “client IPs” in the usual sense |
| Virtual network rules | Specific subnets with Microsoft.Storage (same region) or Microsoft.Storage.Global (cross-region) service endpoints | Up to hundreds of VNet rules; subnet traffic uses private source IPs via service endpoint |
| Resource instance rules | Specific Azure resource instances that cannot be VNet-isolated | Same Entra tenant; RBAC still applies |
| Trusted service exceptions | Documented Microsoft services operating outside your VNet | Strong auth still required; not “all of Azure” |
How VNet rules work
- On the subnet, enable a storage service endpoint.
- On the storage account, add a virtual network rule for that subnet.
- Traffic stays on the Azure backbone to the service; the firewall treats the subnet as trusted for network purposes.
- Clients in the subnet still need authorization (Entra role, SAS, or key if Shared Key remains enabled).
Cross-region: Use Microsoft.Storage.Global when the storage account is not in the same region as the VNet. Only one of the Storage / Storage.Global endpoint types associates with a subnet at a time.
DR tip: Pre-create VNets/subnets and rules in the paired region so RA-GRS secondary access still works through planned network paths during regional events.
IP rules and SAS interaction
- IP allow lists admit public clients (branch offices, build agents with stable egress).
- A SAS can also constrain
sip(signed IP), but a SAS never expands access beyond the firewall—if the firewall denies the source, the SAS does not help. - After service endpoints are in use, subnet traffic no longer presents the public IP of the VM to the storage firewall the same way; manage access with VNet rules rather than guessing host public IPs.
Trusted Microsoft services
When the firewall denies public access by default, first-party services (backup, logging sinks, certain analytics, and other documented services) may need the trusted services exception to reach the account. Critical exam points:
- Bypass is a network exception for listed services, not a permission grant.
- The service still authenticates and must be authorized.
- Services not on the trusted list (many customer-hosted or DevOps Microsoft-hosted agent scenarios) need private endpoints, self-hosted agents on allowed VNets, or IP rules.
Private Endpoints for Storage
A private endpoint assigns a private IP from your VNet to a storage sub-resource (blob, file, queue, table, web, dfs, and so on) via Azure Private Link.
| Aspect | Service endpoint + firewall | Private endpoint |
|---|---|---|
| Data path | To public VIP, restricted by source network | To private IP in your address space |
| Public endpoint | Often still enabled | Can set public network access = Disabled |
| DNS | Public FQDN | Private DNS zone (privatelink.*) integration required |
| SC-500 “most secure isolation” | Intermediate | Usually the preferred answer |
Hardening pattern for sensitive data:
- Deploy private endpoints for required sub-resources in hub/spoke or workload VNets.
- Link private DNS zones to all consuming VNets.
- Set public network access to Disabled (or equivalent deny-all public).
- Validate that apps resolve
*.blob.core.windows.net(or dfs/file equivalents) to private addresses. - Keep RBAC least privilege; network isolation does not replace authorization.
Exam trap: Private endpoints are per sub-resource. A blob private endpoint does not automatically private the file endpoint. Map each protocol your apps use.
Shared Access Signatures (SAS): Types and Risks
A SAS is a signed query string granting time-bounded, permission-bounded access without sharing the full account key with the end client. Azure defines three types:
| Type | Signed with | Scope | Stored access policy? | Microsoft preference |
|---|---|---|---|---|
| User delegation SAS | User delegation key obtained via Entra ID | Blob (incl. DFS), queue, table, files (supported surfaces) | No (ad hoc only) | Preferred when SAS is needed |
| Service SAS | Account key | One service (blob or file or queue or table) | Yes, optional | Acceptable with policy + short life |
| Account SAS | Account key | One or more services; can include service-level ops | No (ad hoc only) | Most powerful key-signed form—use sparingly |
Risks
- A leaked SAS is usable by anyone who holds the URI until expiry (or revocation).
- Azure Storage does not inventory every SAS ever minted—generation is often client-side and not centrally audited as “SAS created.”
- Long-lived account/service SAS equal standing credentials.
- Write+read SAS can drive large egress bills if abused.
- Rotating account keys revokes key-signed SAS but also breaks legitimate clients; user-delegation SAS survives key rotation.
Best practices (exam checklist)
- Prefer user delegation SAS over key-signed types.
- Always distribute SAS over HTTPS.
- Least privilege: single blob read beats container read/write/delete.
- Short expiry on ad hoc SAS (often ≤1 hour when no stored policy).
- Use stored access policies for service SAS so you can revoke by deleting/altering the policy.
- Configure a SAS expiration policy on the account to warn/log over-long service/account SAS.
- Have a revocation plan before issuing production SAS.
- Disable Shared Key when you want to prevent key-signed SAS creation for blob/queue workloads.
Stored Access Policies
A stored access policy lives on a container, file share, queue, or table and defines start, expiry, and permissions for service SAS tokens that reference the policy ID.
| Benefit | Detail |
|---|---|
| Revocation | Delete, rename, or expire the policy → associated service SAS stop working without regenerating account keys |
| Central edit | Adjust lifetime/permissions for many issued SAS at once |
| Limit | Typically five stored access policies per container (service) |
Not supported for user-delegation SAS or account SAS—those are ad hoc only. For user-delegation SAS revocation, revoke the user delegation key (invalidates signatures tied to that key) or rely on short lifetimes and removing the principal’s Entra permissions.
Scenario: Partners receive service SAS for a landing container. Bind each SAS to a stored access policy with write-only permission and a 24-hour window. If a URI leaks, delete the policy immediately rather than rotating keys for the whole account.
Data-Plane RBAC Roles
When using Entra authorization, assign Azure RBAC roles scoped to the subscription, resource group, storage account, or container (where supported). Distinguish planes:
| Plane | Typical roles | What they do |
|---|---|---|
| Control plane | Owner, Contributor, Reader, Storage Account Contributor | Manage the resource (SKU, networking, keys list/regenerate depending on role) |
| Data plane | Storage Blob Data Reader / Contributor / Owner; Queue Data *; Table Data *; File Data SMB * roles | Read/write data objects |
Common blob data roles:
| Role | Typical use |
|---|---|
| Storage Blob Data Reader | Read/list blobs only |
| Storage Blob Data Contributor | Read/write/delete blobs; not change container RBAC ownership broadly |
| Storage Blob Data Owner | Full data access including POSIX-like ownership scenarios on hierarchical namespace |
| Storage Account Key Operator Service Role | Manage keys without full subscription Owner |
Critical trap: Contributor on the storage account can manage settings and often list/regenerate keys, which yields full data access via Shared Key—even without a “Blob Data Contributor” role. Disabling Shared Key and using data-plane roles closes that elevation path. Apps should use managed identity + Storage Blob Data Contributor (or Reader), not account keys in configuration.
Combining Controls (Reference Architecture)
| Layer | Control |
|---|---|
| Identity | Entra; disable Shared Key |
| Authorization | Data-plane RBAC least privilege |
| Delegation | User-delegation SAS or policy-backed service SAS only when needed |
| Network | Private endpoints + public access disabled; or firewall with VNet/IP rules |
| Exceptions | Trusted services only when required |
| Recovery | Soft delete / immutability (section 5.1) |
| Detection | Defender for Storage (section 5.3) |
SC-500 Exam Traps (Firewall & Access)
- Firewall allows network path; it does not replace RBAC/SAS/keys.
- Service endpoints ≠ private endpoints.
- Trusted services ≠ every Azure service.
- User-delegation SAS does not use account keys and is preferred.
- Stored access policies revoke service SAS only.
- Control-plane Contributor is not “safe” while Shared Key remains enabled.
Security requires that blob traffic from an application subnet never use the storage account’s public endpoint. Which configuration best meets the requirement?
Which SAS type is secured with Microsoft Entra credentials rather than the storage account key?
A service SAS bound to a stored access policy may have been leaked. What is the best immediate revocation action that avoids rotating account keys for all applications?
An application’s managed identity must upload blobs but must not manage storage account firewall settings or list account keys. Which assignment is most appropriate?