3.1.1.2. Configure Network Access to Storage Accounts

3.1.1.2. Configure Network Access to Storage Accounts

💡 First Principle: Securing a storage account begins with controlling network access, fundamentally minimizing the attack surface by ensuring data is only accessible from authorized networks and services.

Scenario: You have a production web application running on Azure Virtual Machines within a Virtual Network. This application needs to access an Azure Storage Account to store images. You want to ensure that only your web application can access this storage account, and that traffic does not go over the public internet.

What It Is: Network access to storage accounts refers to the configuration settings that define which networks or services are allowed to connect to your Azure Storage.

Restricting Access:

• Firewall Rules:
  • Specify allowed public IP addresses or address ranges.
  • Use this to permit only trusted on-premises or external networks, blocking all others.
• Virtual Network (VNet) Service Endpoints:
  • Enable secure connections from Azure VNets to storage accounts over the Azure backbone, without exposing the account to the public internet (traffic still resolves to the storage account's public IP, but is restricted to the selected subnets — only a Private Endpoint assigns a private IP from your VNet).
  • Ideal for scenarios where VNet resources need access but private IP mapping is not required.
• Azure Private Link (Private Endpoints):
  • Assigns a private IP from your VNet to the storage account, making it accessible only within your private network.
  • This offers the highest isolation and is preferred for sensitive or regulated workloads.

When to Use Each Option:

Visual: Storage Account Network Access Options

Shared Access Signatures (SAS) and Stored Access Policies

Network rules decide where a request may come from. A shared access signature (SAS) decides what the holder of a URL may do and until when. The token rides on the resource URI, and Azure Storage checks its signature on every request, so whoever holds the URL holds the access. That makes one question decisive before you hand a SAS to anyone: how will you take it back?

Microsoft recommends a user delegation SAS wherever you can use one, because no account key is involved.

Ad hoc SAS vs. policy-backed SAS: An ad hoc SAS carries its start time, expiry time, and permissions inside the URI, and any SAS type can be ad hoc. A service SAS can instead reference a stored access policy defined on the container, file share, queue, or table, and it inherits the start time, expiry time, and permissions from that policy. Because the policy lives on the server, you can change or cancel it after the token has been handed out.

Stored access policy rules the exam leans on:

• Five per container: You can set at most five stored access policies on a container, file share, queue, or table at one time. Setting more returns 400 (Bad Request).
• Service SAS only: A user delegation SAS or an account SAS must be ad hoc. Neither can reference a stored access policy.
• Each constraint lives in one place: Put the start time, expiry time, and permissions on the SAS or on the policy, never on both. A SAS generated with --policy-name omits any value the policy already defines.
• Allow 30 seconds: A new or updated policy can take up to 30 seconds to take effect. During that window, requests with an associated SAS can fail with 403 (Forbidden).
• Three ways to revoke: Delete the policy, rename its signed identifier, or move its expiry time into the past. Each change immediately affects every SAS bound to that policy and nothing else.

Practical Implementation: A Policy-Backed SAS with Azure CLI

# Create a read/list stored access policy on the container
az storage container policy create \
  --account-name contosodata \
  --container-name partner-drop \
  --name partner-read \
  --permissions rl \
  --expiry 2026-12-31T23:59:00Z

# Issue a SAS that inherits its permissions and expiry from the policy
az storage container generate-sas \
  --account-name contosodata \
  --name partner-drop \
  --policy-name partner-read

# Revoke every SAS tied to the policy without touching the account keys
az storage container policy delete \
  --account-name contosodata \
  --container-name partner-drop \
  --name partner-read

In the portal, open the container's Access policy pane (from the container's ... menu) and select + Add policy under Stored access policies to set an identifier, permissions, and start and expiry times.

Revocation options compared:

Visual: Choosing a SAS

⚠️ Exam Trap: "Revocable" and "most secure" point to different SAS types. When a scenario demands revoking one partner's access without rotating keys, the answer is a service SAS with a stored access policy. When it demands no account keys at all, the answer is a user delegation SAS, which can't use a stored access policy.

⚠️ Common Pitfall: Leaving a storage account open to "All networks" by default. This is a significant security risk and should be restricted as soon as possible.

Key Trade-Offs:

• Ease of Access (Public) vs. Security (Private): Public endpoints are easy to access from anywhere but less secure. Private endpoints provide the strongest security but require more network configuration.

Reflection Question: How does strategically choosing between Firewall Rules, Virtual Network Service Endpoints, and Azure Private Link (Private Endpoints) fundamentally control network access to storage accounts, minimizing the attack surface and strengthening your overall security posture?