Theoretical Foundation: Configure Azure Storage Firewalls and Virtual Networks

1. Initial Intuition

Imagine you have a safe in a bank. The bank has security at the entrance, but the safe itself also has its own combination. Even if someone enters the bank, without the specific safe combination, they cannot access what's inside.

By default, an Azure Storage Account is like a safe that anyone with the right key (access key or SAS token) can access from anywhere in the world via the public internet. If someone leaks your access key, your data becomes exposed from any IP on the planet.

The Storage Firewall and Virtual Network configurations of the Storage Account are the second combination of the safe: even if someone has the key, they can only open the safe if they are physically in the authorized location. You define exactly from where access is allowed: which networks, which IPs, which Azure services.

In practice, this means that a production storage account can be configured to accept connections only from VMs in a specific subnet, blocking any access coming from outside that network perimeter, including the public internet.

2. Context

Where Storage Firewalls fit in Azure security

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

The Storage Firewall operates at the network layer: it validates where the request is coming from before even checking authentication and authorization. A request from an unauthorized IP is blocked at the network level, without reaching the authentication layer.

Why Storage Firewalls exist

By default, Storage Accounts have a public endpoint accessible via the internet (storageaccount.blob.core.windows.net). This is convenient but represents an attack vector: leaked credentials can be used from anywhere in the world.

The Storage Firewall solves this by implementing network origin-based access control, complementing the identity and authorization controls that already exist.

What depends on the Storage Firewall

Architectures with sensitive data that should not be publicly accessible
Compliance with PCI-DSS, HIPAA, LGPD that require access origin control
Private Endpoint patterns that completely eliminate public access
Data pipelines that need to access storage from within a specific VNet

3. Concept Construction

3.1 Public access configurations: the starting point

The first configuration that determines Storage Firewall behavior is Public Network Access:

Configuration	Behavior	When to use
Enabled from all networks	Unrestricted public access (default)	Never in production with sensitive data
Enabled from selected virtual networks and IP addresses	Active firewall with specific rules	Most common scenario for production
Disabled	Public endpoint disabled; access only via Private Endpoint	Maximum security, highly sensitive data

The transition from default ("all networks") to "selected networks" activates the firewall and blocks all access not explicitly permitted. It's a radical behavior change: from "everything allowed" to "everything denied except what's on the list".

3.2 The four permission mechanisms

When the firewall is active ("selected networks"), there are four ways to allow access:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

### 3.3 Virtual Network Rules (Service Endpoints)

A **Virtual Network Rule** allows a specific subnet to access the Storage Account directly, without going through the public internet.

To work, the subnet needs to have the **Service Endpoint** `Microsoft.Storage` enabled. The Service Endpoint is a configuration on the subnet that tells Azure: "when traffic from this subnet goes to storage, use an internal Microsoft network path, not the public internet."

```mermaid
graph LR
    VM["VM in Subnet-App\n(Service Endpoint enabled)"] -->|"Azure internal path\n(not public internet)"| Storage["Storage Account\nVNet rule for Subnet-App"]
    Internet["User on internet"] -->|"Blocked by firewall"| Storage

    style VM fill:#2e7d32,stroke:#1b5e20,color:#fff
    style Internet fill:#d32f2f,stroke:#b71c1c,color:#fff
    style Storage fill:#1565c0,stroke:#0d47a1,color:#fff

How it works technically: when you enable Service Endpoints on the subnet, traffic to storage uses the public IP of the storage but travels through Microsoft's backbone (internal network), never going out to the internet. The Storage Account, upon seeing the request, identifies that it comes from a subnet with Service Endpoint configured and allows access if there's a Virtual Network Rule for that subnet.

3.4 IP Rules

IP Rules are lists of public IPs or CIDR ranges that have access permission. They are used for:

Corporate offices with fixed IP
CI/CD pipelines running outside Azure
Administrator workstations with known IPs

Important restriction: IP Rules only accept public IPv4 addresses. It's not possible to add:

Private IPs (10.x.x.x, 172.16.x.x, 192.168.x.x)
The range 0.0.0.0/0 (would allow everything)
IPv6 addresses

For private network access (VMs in VNet), use Virtual Network Rules, not IP Rules.

3.5 Resource Instances

Resource Instances allow specific instances of Azure services to access storage, based on the resource's managed identity (Managed Identity), not on IP.

This is useful for Azure services whose IPs are not fixed or predictable (like Azure Functions, Logic Apps, ADF), where you cannot use IP Rules. Instead of using Trusted Services (which grants access to an entire category of services), you authorize a specific instance.

{
  "resourceInstances": [
    {
      "resourceType": "Microsoft.Synapse/workspaces",
      "resourceId": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Synapse/workspaces/synapse-prod-001",
      "tenantId": "<tenant-id>"
    }
  ]
}

3.6 Trusted Microsoft Services

Some Microsoft services need to access storage to function properly, such as backups, diagnostic logs, Azure Monitor. When the firewall is active, these services are also blocked unless you enable the Trusted Microsoft Services bypass.

Services included in the Trusted Services bypass (selection of most relevant):

Service	Type of access
Azure Backup	Backup and restore data
Azure Monitor	Diagnostic logs
Azure DevTest Labs	Access images and artifacts
Azure Event Grid	Storage event notifications
Azure Networking	Flow logs for NSG
Azure Site Recovery	Replication for DR
Azure Machine Learning	Access to datasets
Azure Data Factory	Data movement

Attention: enabling Trusted Services grants bypass to a pre-defined list of Microsoft services. It's not possible to customize which specific services have bypass (for that, use Resource Instances).

3.7 Private Endpoints: the most secure alternative

While the Storage Firewall with Service Endpoints uses the Storage Account's public endpoint (with network-controlled access), a Private Endpoint creates a private network interface directly in your VNet, with a private IP, for the storage.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

With Private Endpoint, the storage has a private IP address in your VNet. DNS resolves storageaccount.blob.core.windows.net to the private IP within the VNet. Traffic never goes out to the internet. The public endpoint can (and should) be completely disabled.

Fundamental difference between Service Endpoint and Private Endpoint:

Aspect	Service Endpoint	Private Endpoint
Public endpoint	Still used (storage's public IP)	Can be completely disabled
IP in VNet	No (traffic uses public IP via backbone)	Yes (private IP from your VNet)
Cost	No additional cost	Cost per hour of Private Endpoint + data
DNS	Resolves to public IP	Resolves to private IP (requires private DNS)
Complexity	Low	Medium/high
Security level	High	Maximum

4. Structural View

Request evaluation flow to Storage

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Typical production architecture with Storage Firewall

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Practical Operation

Storage Firewall configuration cycle

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

### Critical non-obvious behaviors

**When activating "selected networks", Azure services are also blocked.**
When you change from "all networks" to "selected networks", not only the internet is blocked. Azure services like Azure Backup, Azure Monitor and the Azure portal itself for blob visualization are also blocked. If you don't enable Trusted Services and don't configure the correct rules, tools that worked before immediately stop working.

**The Azure portal is blocked by default when activating the firewall.**
Attempting to navigate to "Containers" of a storage with active firewall, using an unauthorized IP, returns an error. This surprises those configuring the firewall through the portal itself: the action of saving rules may work, but browsing content may be immediately blocked for the administrator's machine IP.

**Service Endpoints need to be enabled BEFORE adding the VNet Rule.**
The portal warns about this, but in automation it's common to get the order wrong. If you try to add a VNet Rule for a subnet that doesn't have the `Microsoft.Storage` Service Endpoint enabled, the operation fails or the rule doesn't work as expected.

**Logging of blocked attempts is not automatic.**
By default, the Storage Firewall doesn't log blocked requests. To audit who is being blocked and why, you need to explicitly configure **Storage Analytics Logs** or send logs to a Log Analytics Workspace via Diagnostic Settings.

**Private Endpoint requires private DNS configuration.**
When you create a Private Endpoint, the storage has a private IP in your VNet. But public DNS still resolves `storageaccount.blob.core.windows.net` to the public IP. For applications within the VNet to resolve to the private IP, you need a **Private DNS Zone** (`privatelink.blob.core.windows.net`) integrated with the VNet. Without this, applications may continue trying to use the public IP (which you disabled) and fail.

**Multiple Private Endpoints per storage service.**
A Storage Account has multiple sub-services (Blob, File, Queue, Table, DFS). Each can have its own independent Private Endpoint. If you create a Private Endpoint only for Blob, File is still accessible through the public endpoint (unless you also disable File's public endpoint).

---

## 6. Implementation Methods

### Azure Portal

**When to use:** initial configuration, visual verification, point changes

**Configure Storage Firewall through portal:**
1. Portal > Storage Account > **Networking**
2. In **Firewalls and virtual networks**
3. Select **Enabled from selected virtual networks and IP addresses**
4. **Add existing virtual network:** select VNet and subnet (portal warns if Service Endpoint isn't enabled and offers to enable it)
5. **Add IP range:** add IPs or CIDRs for external access
6. Enable or not **Allow Azure services on the trusted services list**
7. Decide on **Allow storage account key access** (separate from firewall, but relevant)
8. **Save**

**Limitation:** not reproducible, no version control.

---

### Azure CLI

```bash
# Check current network configuration of storage
az storage account show \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --query "networkRuleSet" \
  --output json

# Step 1: Enable Service Endpoint on subnet BEFORE creating VNet Rule
az network vnet subnet update \
  --name "Subnet-App" \
  --vnet-name "vnet-producao" \
  --resource-group "rg-networking" \
  --service-endpoints "Microsoft.Storage"

# Step 2: Change default action to Deny (activates firewall)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --default-action Deny

# Step 3: Add Virtual Network Rule
az storage account network-rule add \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --vnet-name "vnet-producao" \
  --subnet "Subnet-App"

# Step 4: Add IP Rule (only public IPs)
az storage account network-rule add \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --ip-address "200.200.200.0/24"

# Add individual IP
az storage account network-rule add \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --ip-address "203.0.113.50"

# Step 5: Enable bypass for Trusted Services
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --bypass AzureServices Logging Metrics

# Bypass values are: AzureServices, Logging, Metrics, None
# Multiple values are separated by space

# List all network rules
az storage account network-rule list \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --output table

# Remove a VNet Rule
az storage account network-rule remove \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --vnet-name "vnet-producao" \
  --subnet "Subnet-App"

# Remove an IP Rule
az storage account network-rule remove \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --ip-address "200.200.200.0/24"

# Completely disable public access (Private Endpoint only)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --public-network-access Disabled

# Re-enable public access (for emergencies)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --public-network-access Enabled \
  --default-action Allow

# Create Private Endpoint for Blob
az network private-endpoint create \
--name "pe-stgprod001-blob" \
  --resource-group "rg-storage" \
  --vnet-name "vnet-producao" \
  --subnet "Subnet-PrivateEndpoints" \
  --private-connection-resource-id "/subscriptions/<sub-id>/resourceGroups/rg-storage/providers/Microsoft.Storage/storageAccounts/stgprod001" \
  --group-id "blob" \
  --connection-name "stgprod001-blob-connection"

# Create DNS Zone for private blob resolution
az network private-dns zone create \
  --name "privatelink.blob.core.windows.net" \
  --resource-group "rg-networking"

# Link DNS Zone to VNet
az network private-dns link vnet create \
  --name "link-vnet-producao" \
  --resource-group "rg-networking" \
  --zone-name "privatelink.blob.core.windows.net" \
  --virtual-network "vnet-producao" \
  --registration-enabled false

# Create DNS record for the Private Endpoint
az network private-endpoint dns-zone-group create \
  --name "stgprod001-blob-dns" \
  --resource-group "rg-storage" \
  --endpoint-name "pe-stgprod001-blob" \
  --private-dns-zone "privatelink.blob.core.windows.net" \
  --zone-name "blob"

Azure PowerShell

# Enable Service Endpoint on subnet
$subnet = Get-AzVirtualNetworkSubnetConfig `
  -Name "Subnet-App" `
  -VirtualNetwork (Get-AzVirtualNetwork -Name "vnet-producao" -ResourceGroupName "rg-networking")

$vnet = Get-AzVirtualNetwork -Name "vnet-producao" -ResourceGroupName "rg-networking"
Set-AzVirtualNetworkSubnetConfig `
  -Name "Subnet-App" `
  -VirtualNetwork $vnet `
  -AddressPrefix $subnet.AddressPrefix `
  -ServiceEndpoint "Microsoft.Storage" |
Set-AzVirtualNetwork

# Configure Storage Firewall
$storageAccount = Get-AzStorageAccount `
  -Name "stgprod001" `
  -ResourceGroupName "rg-storage"

# Add VNet Rule
Add-AzStorageAccountNetworkRule `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001" `
  -VirtualNetworkResourceId (Get-AzVirtualNetworkSubnetConfig -Name "Subnet-App" -VirtualNetwork $vnet).Id

# Add IP Rule
Add-AzStorageAccountNetworkRule `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001" `
  -IPAddressOrRange "200.200.200.0/24"

# Change default action to Deny and enable bypass
Update-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001" `
  -DefaultAction Deny `
  -Bypass AzureServices,Logging,Metrics

# View current configuration
Get-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001"

# Remove VNet Rule
Remove-AzStorageAccountNetworkRule `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001" `
  -VirtualNetworkResourceId "<subnet-resource-id>"

Bicep for Storage with Firewall

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stgprod001'
  location: 'brazilsouth'
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    // Deny public access by default, except explicit rules
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      defaultAction: 'Deny'  // Block everything not in rules
      bypass: 'AzureServices,Logging,Metrics'  // Trusted Services
      
      // Virtual Network Rules
      virtualNetworkRules: [
        {
          id: subnetAppId  // Resource ID of subnet with Service Endpoint
          action: 'Allow'
        }
        {
          id: subnetDataId
          action: 'Allow'
        }
      ]
      
      // IP Rules (only public IPv4)
      ipRules: [
        {
          value: '200.200.200.0/24'
          action: 'Allow'
        }
        {
          value: '203.0.113.50'
          action: 'Allow'
        }
      ]
      
      // Resource Instances
      resourceAccessRules: [
        {
          tenantId: tenant().tenantId
          resourceId: synapseWorkspaceId
        }
      ]
    }
    
    // Minimize attack surface
    allowBlobPublicAccess: false
    allowSharedKeyAccess: true  // Consider false to force Azure AD
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
  }
}

7. Control and Security

allowSharedKeyAccess Property

This property, separate from the firewall, controls whether Account Key authentication (512-bit key) is allowed. When set to false, even those who have the key cannot authenticate with it; only Azure AD (RBAC) is accepted.

Security recommendation: for production storage accounts, consider disabling Shared Key access and forcing authentication via Azure AD. This eliminates the risk of access key leakage.

# Disable Account Key authentication
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --allow-shared-key-access false

Warning: when disabling Shared Key, SAS Tokens based on Account Key also stop working. Only User Delegation SAS (based on Azure AD) will continue to work.

Configure diagnostic logs for auditing

# Configure Storage logs to Log Analytics
az monitor diagnostic-settings create \
  --name "storage-network-logs" \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-storage/providers/Microsoft.Storage/storageAccounts/stgprod001/blobServices/default" \
  --workspace "<log-analytics-workspace-id>" \
  --logs '[
    {"category": "StorageRead", "enabled": true},
    {"category": "StorageWrite", "enabled": true},
    {"category": "StorageDelete", "enabled": true}
  ]'

To check requests blocked by the firewall, use this query in Log Analytics:

StorageBlobLogs
| where StatusCode == 403
| project TimeGenerated, CallerIpAddress, OperationName, Uri, StatusCode, StatusText
| order by TimeGenerated desc

Microsoft Defender for Storage

Microsoft Defender for Storage adds a threat detection layer above the firewall: it analyzes access patterns and detects anomalous activities such as access from suspicious IPs, massive data downloads, malware uploads, etc.

# Enable Defender for Storage
az security atp storage update \
  --resource-group "rg-storage" \
  --storage-account "stgprod001" \
  --is-enabled true

8. Decision Making

Service Endpoint vs. Private Endpoint

Criteria	Service Endpoint	Private Endpoint
Security level	High	Maximum
Public endpoint disableable	No (still in use)	Yes
IP in VNet	No	Yes
Cost	Free	~$0.01/hour + data transfer
DNS configuration	Not required	Mandatory (Private DNS Zone)
Cross-subscription access	Limited	Supported
Ideal use case	Most production scenarios	Highly sensitive data, maximum compliance

When to use each permission mechanism

Situation	Mechanism	Reason
VMs in VNet need storage access	Virtual Network Rule + Service Endpoint	Internal path, no public internet
Office with fixed IP needs access	IP Rule	Known and stable public IP
Azure Backup needs access	Trusted Services bypass	Managed service without predictable IP
Specific Azure Function needs access	Resource Instance	Access by identity, not by IP
Highly sensitive data (PCI, healthcare)	Private Endpoint + disable public	Completely eliminates public endpoint
CI/CD pipeline outside Azure	IP Rule or Service Endpoint via VPN	Depends on network architecture

Bypass values

Bypass	What it allows	When to enable
`AzureServices`	Microsoft Trusted Services	Almost always; without this, backups and logs fail
`Logging`	Storage Analytics Logging	If using Storage Analytics (legacy)
`Metrics`	Storage Analytics Metrics	If using Storage Analytics (legacy)
`None`	No bypass; all rules apply	Only with Private Endpoint where no external service needs access

9. Best Practices

Never use "Enabled from all networks" in production storage accounts with sensitive data. The "all networks" default is for development convenience, not for production. Every production storage should have an active firewall with "selected networks" as minimum.

Enable Service Endpoints before adding VNet Rules. In IaC pipelines, order matters. If you try to create a VNet Rule for a subnet without Service Endpoint, the operation fails or behaves unpredictably. Always provision Service Endpoints first, VNet Rules after.

Add your machine's IP before activating the firewall. If you're configuring the firewall interactively through the portal or CLI from a machine not in any authorized subnet, add your IP before changing the default action to Deny. Otherwise, you'll lose access to the storage mid-configuration.

Combine firewall with anonymous access disabling. The firewall controls from where access is allowed. allowBlobPublicAccess: false ensures no container can be configured as public. These are complementary protections: the firewall protects from where, the public access configuration protects what can be exposed.

Use Private Endpoints for maximum compliance data. PCI-DSS, HIPAA, LGPD in high-sensitivity scenarios typically require data not to travel over the public internet. Private Endpoint with disabled public endpoint is the only way to guarantee this in Azure Storage.

Configure Diagnostic Settings for firewall logs before activation. Storage access logs are essential for auditing. Configure Log Analytics delivery before activating the firewall, so you have immediate visibility of any issues.

Document each firewall rule with justification. In VNet Rules and IP Rules, there's no description field, but maintain a control document: which rule was added, by whom, when, and for which business reason. This is essential for audits and to know what can be safely removed.

10. Common Errors

Error	Why it happens	How to avoid
Storage inaccessible after firewall activation	Forgot to add rules for services already using storage	Audit all consumers before activating firewall
VNet Rule doesn't work after addition	Service Endpoint wasn't enabled on subnet	Check and enable Service Endpoint before VNet Rule
Private IP added to IP Rule and rejected	Confusing private IP with public	IP Rules only accept public IPv4; use VNet Rules for private IPs
Azure Backup fails after firewall activation	Not enabling AzureServices bypass	Always include AzureServices in bypass
Private Endpoint created but connection fails	DNS not configured to resolve to private IP	Create Private DNS Zone and link to VNet
Azure portal blocked from browsing storage	Admin IP not in rules	Add admin IP or enable "Add your client IP address"
AKS access blocked	AKS uses changing IPs; IP Rule doesn't work	Use VNet Rule from AKS subnet or Managed Identity with Resource Instance
Trusted Services enabled but service still blocked	Specific service not in Trusted Services list	Check Trusted Services list or use Resource Instance

The most costly production error

Activating storage firewall without testing all consumers: a data processing pipeline that runs at midnight starts failing silently because the subnet where it operates wasn't added to VNet Rules. Data processing stops, but no one notices until the next day's report is empty. Therefore, testing all access flows before activation and monitoring logs for the first 48 hours after activation is fundamental.

11. Operation and Maintenance

Check and audit firewall configuration

# View complete network configuration
az storage account show \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --query "{
    DefaultAction: networkRuleSet.defaultAction,
    Bypass: networkRuleSet.bypass,
    VNetRules: networkRuleSet.virtualNetworkRules,
    IPRules: networkRuleSet.ipRules,
    PublicAccess: publicNetworkAccess
  }" \
  --output json

# List all storage accounts with unrestricted public access
az resource list \
  --resource-type "Microsoft.Storage/storageAccounts" \
  --query "[].id" -o tsv | \
xargs -I {} az storage account show --ids {} \
  --query "{Name: name, DefaultAction: networkRuleSet.defaultAction}" \
  --output table

# Via Resource Graph: storage accounts without firewall
az graph query -q "
Resources
| where type == 'microsoft.storage/storageaccounts'
| where properties.networkAcls.defaultAction == 'Allow'
| project name, resourceGroup, subscriptionId, location"

Monitor blocked access

# Query in Log Analytics to see blocked IPs
az monitor log-analytics query \
  --workspace "<workspace-id>" \
  --analytics-query "
StorageBlobLogs
| where StatusCode == 403
| where TimeGenerated > ago(24h)
| summarize count() by CallerIpAddress, OperationName
| order by count_ desc
| limit 20"

Important limits

Limit	Value
Virtual Network Rules per Storage Account	200
IP Rules per Storage Account	200
Private Endpoints per Storage Account	No documented limit (practical: several per service)
Sub-services with independent Private Endpoint	Blob, File, Queue, Table, DFS (each separate)
Service Endpoints per subnet	Multiple (by provider namespace)

12. Integration and Automation

Scale firewall configuration automation

# Apply firewall configuration to all storage accounts in an RG
for storage_name in $(az storage account list \
  --resource-group "rg-storage" \
  --query "[].name" -o tsv); do
  
  echo "Configuring firewall for: $storage_name"
  
  # Activate firewall
  az storage account update \
    --name "$storage_name" \
    --resource-group "rg-storage" \
    --default-action Deny \
    --bypass AzureServices Logging Metrics
  
  # Add default VNet Rule
  az storage account network-rule add \
    --account-name "$storage_name" \
    --resource-group "rg-storage" \
    --vnet-name "vnet-producao" \
    --subnet "Subnet-App"
done

Azure Policy to enforce firewall configurations

A policy that audits (or denies) storage accounts without active firewall:

# Using the built-in policy: "Storage accounts should restrict network access"
az policy assignment create \
  --name "storage-network-restriction" \
  --display-name "Storage accounts must restrict network access" \
  --policy "34c877ad-507e-4c82-993e-3452a6e0ad3c" \
  --scope "/subscriptions/<sub-id>" \
  --params '{"effect": {"value": "Audit"}}'

Relevant built-in policies for Storage Networking:

Policy Name	ID	Description
Storage accounts should restrict network access	`34c877ad-...`	Audits storage without firewall
Storage accounts should use private link	`6edd7eda-...`	Audits storage without Private Endpoint
Storage accounts should prevent shared key access	`8c6a50c6-...`	Audits storage with Shared Key enabled
Secure transfer to storage accounts should be enabled	`404c3081-...`	Audits storage without mandatory HTTPS

Integration with Azure Private DNS Zones

In organizations with multiple VNets and Private Endpoints, private DNS management can be centralized:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

With a single centralized Private DNS Zone linked to all VNets, all Private Endpoints created automatically register their private IPs in the zone, and all VNets resolve correctly.

13. Final Summary

Essential points:

Storage Firewall has three modes: all networks (default, no restriction), selected networks (active firewall with rules), Disabled (Private Endpoint only)
When activating "selected networks", everything is blocked except what is explicitly allowed in the rules
The four permission mechanisms are: VNet Rules (subnets with Service Endpoint), IP Rules (IPv4 public IPs), Resource Instances (Azure services by identity) and Trusted Services (bypass for Microsoft services)
IP Rules accept only IPv4 public IPs: for private subnets, use VNet Rules with Service Endpoint
Service Endpoint must be enabled on the subnet before creating the VNet Rule on storage
Private Endpoint creates a private IP in the VNet; requires Private DNS Zone for correct resolution

Critical differences:

Service Endpoint vs. Private Endpoint: Service Endpoint uses the storage public endpoint via Microsoft backbone (without eliminating the public endpoint); Private Endpoint creates private IP and allows completely disabling the public endpoint
Trusted Services vs. Resource Instances: Trusted Services is a bypass for a pre-defined list of Microsoft services (all or nothing); Resource Instances allows authorizing a specific service instance by identity
IP Rule vs. VNet Rule: IP Rule for known public IPs (offices, external CIDRs); VNet Rule for resources within Azure VNets

What needs to be remembered for AZ-104:

When activating the firewall, the default action changes from Allow to Deny; all unlisted traffic is blocked
Bypass values: AzureServices (Trusted Services), Logging and Metrics (Storage Analytics); separate from rules configuration
The limit of rules per storage account is 200 VNet Rules + 200 IP Rules
Private Endpoint requires Private DNS Zone (privatelink.blob.core.windows.net) linked to the VNet
The allowSharedKeyAccess: false property disables Account Key authentication, complementing the firewall
Logs of requests blocked by the firewall need to be configured explicitly via Diagnostic Settings

1. Initial Intuition​

2. Context​

Where Storage Firewalls fit in Azure security​

Why Storage Firewalls exist​

What depends on the Storage Firewall​

3. Concept Construction​

3.1 Public access configurations: the starting point​

3.2 The four permission mechanisms​

3.4 IP Rules​

3.5 Resource Instances​

3.6 Trusted Microsoft Services​

3.7 Private Endpoints: the most secure alternative​

4. Structural View​

Request evaluation flow to Storage​

Typical production architecture with Storage Firewall​

5. Practical Operation​

Storage Firewall configuration cycle​

Azure PowerShell​

Bicep for Storage with Firewall​

7. Control and Security​

allowSharedKeyAccess Property​

Configure diagnostic logs for auditing​

Microsoft Defender for Storage​

8. Decision Making​

Service Endpoint vs. Private Endpoint​

When to use each permission mechanism​

Bypass values​

9. Best Practices​

10. Common Errors​

The most costly production error​

11. Operation and Maintenance​

Check and audit firewall configuration​

Monitor blocked access​

Important limits​

12. Integration and Automation​

Scale firewall configuration automation​

Azure Policy to enforce firewall configurations​

Integration with Azure Private DNS Zones​

13. Final Summary​

1. Initial Intuition

2. Context

Where Storage Firewalls fit in Azure security

Why Storage Firewalls exist

What depends on the Storage Firewall

3. Concept Construction

3.1 Public access configurations: the starting point

3.2 The four permission mechanisms

3.4 IP Rules

3.5 Resource Instances

3.6 Trusted Microsoft Services

3.7 Private Endpoints: the most secure alternative

4. Structural View

Request evaluation flow to Storage

Typical production architecture with Storage Firewall

5. Practical Operation

Storage Firewall configuration cycle

Azure PowerShell

Bicep for Storage with Firewall

7. Control and Security

allowSharedKeyAccess Property

Configure diagnostic logs for auditing

Microsoft Defender for Storage

8. Decision Making

Service Endpoint vs. Private Endpoint

When to use each permission mechanism

Bypass values

9. Best Practices

10. Common Errors

The most costly production error

11. Operation and Maintenance

Check and audit firewall configuration

Monitor blocked access

Important limits

12. Integration and Automation

Scale firewall configuration automation

Azure Policy to enforce firewall configurations

Integration with Azure Private DNS Zones

13. Final Summary