Sequence 8 — Network Security: Firewalls, VNets & Private Endpoints

Prerequisites: Sequences 1-7 (storage accounts, redundancy, authorization with keys/SAS/Entra). · What you'll be able to do: (1) lock down a storage account's public endpoint with firewall rules; (2) allow trusted networks via IP ranges, VNet service endpoints, resource instances and trusted-service exceptions; (3) deploy a private endpoint and explain the privatelink DNS flow; (4) decide service endpoint vs. private endpoint. · Est. time: ~16 min.

Network rules are a perimeter control: they decide which networks may reach the account. They are not authentication. Network rules + authorization always stack — a request must pass the firewall and present a valid access key, SAS, or Microsoft Entra credential (Sequences 6-7). Passing the firewall never grants data access by itself.

1. The two endpoints of a storage account

Every storage account is reachable through two distinct front doors:

Two baseline hardening settings apply regardless of which path you use:

• Secure transfer required — accept HTTPS only; reject HTTP. On by default; recommended on. (Exception: NFS Azure file shares secured at the network level.)
• Firewall rules affect the public endpoint only. They do not affect private-endpoint traffic.

2. Public network access: the master switch

Before any firewall rule matters, you set the account's default public network access to one of three states:

Key fact: Firewall rules only have effect once the default action is Deny ("selected networks"). On the open default, your carefully crafted rules do nothing. In PowerShell/CLI this is literally -DefaultAction Deny / --default-action Deny.

Lock-out warning: flipping to Deny can cut off you and your apps. Add your allowed sources (or a private endpoint) first, then set Deny.

# Lock down: deny by default, keep trusted-Azure-services + logging/metrics on
az storage account update \
  --resource-group myresourcegroup --name mystorageaccount \
  --default-action Deny \
  --bypass AzureServices Logging Metrics

3. The four firewall rule types

Once on "selected networks", you grant access with four kinds of rules. They are OR-combined: a request is allowed if it matches any rule; otherwise it is denied.

IP network rules

For clients outside any VNet — e.g. an on-premises office's internet-facing public IP, or an ExpressRoute Microsoft-peering NAT IP. Use individual addresses or CIDR blocks.

az storage account network-rule add \
  --resource-group myresourcegroup --account-name mystorageaccount \
  --ip-address 203.0.113.0/24

Gotcha: if a subnet has a service endpoint for Storage, its traffic arrives with a private source IP, so IP rules no longer apply to it — use a VNet rule for that subnet instead.

Virtual network rules (service endpoints)

A VNet rule trusts a subnet. The subnet must have the Microsoft.Storage (same region) or Microsoft.Storage.Global (cross-region) service endpoint enabled — only one of the two per subnet.

The portal creates the service endpoint automatically when you add the subnet; CLI/PowerShell need two steps (enable endpoint, then add rule). Adding the rule needs the Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action permission (held by Storage Account Contributor).

# 1) Enable the service endpoint on the subnet
az network vnet subnet update \
  --resource-group myresourcegroup --vnet-name myvnet --name mysubnet \
  --service-endpoints "Microsoft.Storage.Global"

# 2) Add a VNet rule referencing that subnet
subnetid=$(az network vnet subnet show -g myresourcegroup --vnet-name myvnet --name mysubnet --query id -o tsv)
az storage account network-rule add -g myresourcegroup --account-name mystorageaccount --subnet $subnetid

DR tie-in: VNet rules also cover the RA-GRS read-only secondary. Pre-create paired-region VNets with Storage service endpoints so access survives a regional failover (see Sequence 3). Microsoft.Storage.Global also enables access from a paired region.

Subnet pitfall: delete a subnet and its rule is dropped; recreating a subnet of the same name does not restore access — you must re-add the rule explicitly.

Resource instance rules

Some PaaS resources (e.g. a Logic App, Azure ML workspace, Synapse) can't be pinned to a stable IP or VNet. Allow them by their system-assigned managed identity / resource ID. The resource's RBAC role assignments still govern what operations it may perform.

Trusted-service exception

A toggle (bypass) that lets allowlisted Microsoft first-party services reach the account from outside your network boundary — commonly to write resource logs/metrics or for backup/Defender. These services authenticate strongly. Keep Logging and Metrics in the bypass so diagnostics keep flowing.

4. How the rules are evaluated

Mental model: once restricted, the firewall is default-deny with explicit allows (OR). There is no "deny rule" to override an allow — you simply don't list a source. And clearing the firewall is never enough to reach data — authorization (Step Z) is the second gate.

SAS note: a SAS that pins an IP range only narrows the token's reach. It can never widen access beyond the network rules — the firewall is checked first.

5. Private endpoints (Azure Private Link)

A private endpoint is a network interface in your VNet that gets a private IP from your subnet and maps it to one storage service of the account over Private Link. Traffic rides the Microsoft backbone — it never touches the public internet.

Key properties:

• Per-service (per target sub-resource). You need a separate private endpoint for each service you use: blob, dfs (Data Lake), file, queue, table, web (static site). If you use Data Lake, create endpoints for both dfs and blob — some ADLS operations redirect to blob.
• Same code, no changes. Apps keep the same connection string and the same authorization (key/SAS/Entra). Do not connect via the raw privatelink URL.
• Consent flow, not firewall. Approval happens through the Private endpoints tab (auto-approved if you own the account). When a private endpoint exists, its VNet's traffic is always allowed — even if public access is Disabled.
• Not on general-purpose v1. Use GPv2 (Standard or Premium).
• For RA-GRS read access to the secondary, create a separate private endpoint for the secondary; but failover needs none — the endpoint auto-reconnects to the new primary.
• Private endpoints carry an extra cost (Private Link pricing) but give maximum isolation.

Creating a private endpoint does not auto-close the public endpoint. To fully isolate, also set the firewall to Deny / Disabled.

The DNS implication (this is the exam-favorite detail)

Creating the private endpoint rewrites DNS so the normal hostname resolves to the private IP from inside the VNet, while still resolving publicly from outside. A privatelink CNAME is inserted, and Azure (by default) creates a private DNS zone linked to the VNet with the A record pointing to the private IP.

Recommended private DNS zones per service:

With custom/on-prem DNS, you must delegate the privatelink subdomain to the Azure private DNS zone or add the A records yourself, so on-prem clients (over VPN/ExpressRoute private peering) resolve to the private IP.

6. Service endpoints vs. private endpoints — when to choose which

Choose service endpoints for quick, free lock-down of in-Azure VNet workloads. Choose private endpoints when you need a private IP, on-premises private access, or public access fully Disabled. They coexist — a subnet can use a service endpoint for one account and a private endpoint for another.

(Preview) Permitted scope for copy operations can restrict copy sources to the same Entra tenant or Private Link VNet, blocking data infiltration.

Key takeaways

• Network rules ≠ auth. Both gates must pass: firewall AND (key/SAS/Entra).
• Three public-access states: all networks (open default) · selected networks (deny-by-default + allows) · Disabled (private endpoints only).
• Rules do nothing until default action = Deny. Allow your sources first, then Deny — or lock yourself out.
• Four rule types: IP (public ranges/CIDR, no RFC 1918), VNet (subnet + Microsoft.Storage / Microsoft.Storage.Global service endpoint), resource instance (by identity), trusted-service bypass. Rules are OR / default-deny.
• Service endpoint enabled ⇒ subnet uses a private source IP ⇒ IP rules stop applying to it.
• Private endpoint = private IP in your VNet via Private Link, per service, traffic on Microsoft backbone, VNet always allowed even if public Disabled. DNS: privatelink zone, same connection string. Data Lake ⇒ need both dfs + blob.
• Service endpoint = free, public IP, subnet-level; Private endpoint = paid, private IP, on-prem-capable, max isolation.

Exercises

1. (Recall) What are the three values of the storage account's public network access setting?
2. (Recall) You added an IP rule and a VNet rule but traffic from the internet is still wide open. What single setting did you forget?
3. (Applied) A subnet has the Microsoft.Storage service endpoint enabled, yet your IP network rule for that subnet's egress IP no longer works. Why?
4. (Applied) You enabled a private endpoint for the blob service on a Data Lake Storage (GPv2 hierarchical) account, but Create Directory operations fail. What's missing?
5. (Scenario) Security requires zero public internet exposure, access only from an Azure VNet and an on-premises site over ExpressRoute, using existing app connection strings unchanged. Which network design do you implement, and what must you configure for on-prem DNS?
6. (Concept) A client says "the firewall allows my IP, so the data should be readable without credentials." Correct them.

Coming up next

Sequence 9 — Identity-Based Access for Azure Files: enabling Microsoft Entra / on-prem AD DS authentication over SMB, share-level and NTFS permissions, and how identity layers on top of the network controls you just built.