4.2 Storage Firewalls, Private Access, and Network Rules

Network access is not the same as permission

A storage account request must pass network access checks and authorization checks. A user can have Storage Blob Data Contributor and still fail if the account firewall blocks the client IP. A VM can sit in an allowed subnet and still fail if the identity lacks data-plane permissions. This separation is one of the most common AZ-104 troubleshooting patterns.

The storage firewall can allow access from all networks, selected networks, or disabled public network access, depending on the account configuration and service. Selected networks can include public IPv4 address ranges, selected virtual network subnets, and trusted Azure services when the exception is enabled. Private endpoint access is different: it creates a network interface with a private IP address in a VNet for a specific storage subresource, such as blob, file, queue, table, dfs, or web.

Service endpoints and private endpoints are frequently confused. A service endpoint extends the VNet identity to the Azure Storage public endpoint. You still connect to the public FQDN, but the storage firewall can allow the selected subnet. A private endpoint gives the service a private IP in your VNet. Clients should resolve the normal storage account name to the private IP by using a private DNS zone such as privatelink.blob.core.windows.net for blob or privatelink.file.core.windows.net for file.

Portal path example for a firewall rule: Storage account > Security + networking > Networking > Firewalls and virtual networks. Select Enabled from selected virtual networks and IP addresses, add an existing subnet or public IP range, decide whether trusted Azure services are allowed, and save. For a private endpoint, use Storage account > Networking > Private endpoint connections > Private endpoint, then choose the target subresource and integrate with private DNS if Azure DNS is used.

CLI examples:

az storage account update \
  --name staz104prod01 \
  --resource-group rg-storage-prod \
  --default-action Deny

az network vnet subnet update \
  --resource-group rg-network-prod \
  --vnet-name vnet-prod \
  --name snet-app \
  --service-endpoints Microsoft.Storage

az storage account network-rule add \
  --resource-group rg-storage-prod \
  --account-name staz104prod01 \
  --vnet-name vnet-prod \
  --subnet snet-app

Private endpoint example:

az network private-endpoint create \
  --name pe-staz104-blob \
  --resource-group rg-network-prod \
  --vnet-name vnet-prod \
  --subnet snet-private-endpoints \
  --private-connection-resource-id /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-storage-prod/providers/Microsoft.Storage/storageAccounts/staz104prod01 \
  --group-id blob \
  --connection-name peconn-staz104-blob

For production, private endpoints are often paired with disabled or tightly restricted public network access. This is common when on-premises users connect through VPN or ExpressRoute and DNS forwards storage names to Azure private DNS. If DNS is wrong, clients may resolve the public endpoint and then fail because public access is disabled. In that case, the authentication token, SAS token, or access key may be fine, but the network path is wrong.

Troubleshooting tree:

1. Resolve the storage account FQDN from the client. If it returns a public IP when private endpoint access is expected, fix private DNS zone links or conditional forwarding.
2. Test TCP connectivity to port 443. If DNS is private but connectivity fails, inspect routes, NSGs on the private endpoint subnet, firewall appliances, and peering.
3. Check the storage account networking page. If default action is Deny, confirm the subnet rule, IP rule, trusted service exception, or private endpoint approval.
4. Check authentication. A 403 can be a firewall denial, expired SAS, missing RBAC role, disabled shared key, or ACL denial. Use the error text and storage logs where available.
5. Check subresource. A private endpoint for blob does not provide private access to file. Azure Data Lake Storage Gen2 often needs dfs endpoint behavior as well as blob depending on the tool.

Common cases are easy to recognize. A developer connects from home and fails after selected networks is enabled because their home IP is not in the firewall and may change. A VM in an allowed subnet fails because the Microsoft.Storage service endpoint was not enabled before the VNet rule was added. An on-premises client using VPN fails after private endpoint deployment because DNS still points to blob.core.windows.net public records instead of the privatelink zone.

An Azure service fails even though trusted services is checked because that service is not covered or because the managed identity lacks data-plane access.

Choose the smallest rule that meets the requirement. If only a subnet needs access and public endpoints are acceptable, a service endpoint plus VNet rule can be simple. If traffic must stay on private addressing or on-premises users must use private connectivity, choose private endpoints and design DNS. If a single administrator needs temporary access, an IP firewall rule may be enough, but document the public NAT address and remove it when the task ends.