Fundamentação Teórica: Configure Azure Storage Firewalls and Virtual Networks

1. Intuição Inicial

Imagine que você tem um cofre em um banco. O banco tem segurança na entrada, mas o cofre em si também tem uma combinação própria. Mesmo que alguém entre no banco, sem a combinação do cofre específico, não consegue acessar o que está dentro.

Por padrão, uma Azure Storage Account é como um cofre que qualquer pessoa com a chave certa (chave de acesso ou SAS token) pode acessar de qualquer lugar do mundo, via internet pública. Se alguém vazar sua chave de acesso, seus dados ficam expostos a partir de qualquer IP do planeta.

O Storage Firewall e as configurações de Virtual Network da Storage Account são a segunda combinação do cofre: mesmo que alguém tenha a chave, só consegue abrir o cofre se estiver fisicamente no local autorizado. Você define exatamente de onde o acesso é permitido: quais redes, quais IPs, quais serviços Azure.

Na prática, isso significa que um storage account de produção pode ser configurado para aceitar conexões apenas de VMs em uma subnet específica, bloqueando qualquer acesso vindo de fora daquele perímetro de rede, incluindo a internet pública.

2. Contexto

Onde Storage Firewalls se encaixam na segurança do Azure

100%

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

O Storage Firewall atua na camada de rede: ele valida de onde a requisição está vindo antes mesmo de checar autenticação e autorização. Uma requisição de um IP não autorizado é bloqueada na rede, sem chegar à camada de autenticação.

Por que Storage Firewalls existem

Por padrão, Storage Accounts têm um endpoint público acessível pela internet (storageaccount.blob.core.windows.net). Isso é conveniente mas representa um vetor de ataque: credenciais vazadas podem ser usadas de qualquer lugar do mundo.

O Storage Firewall resolve isso implementando controle de acesso baseado em origem de rede, complementando os controles de identidade e autorização que já existem.

O que depende do Storage Firewall

Arquiteturas com dados sensíveis que não devem ser acessíveis publicamente
Compliance com PCI-DSS, HIPAA, LGPD que exigem controle de origem de acesso
Padrões de Private Endpoint que eliminam completamente o acesso público
Pipelines de dados que precisam acessar storage de dentro de uma VNet específica

3. Construção dos Conceitos

3.1 Configurações de acesso público: o ponto de partida

A primeira configuração que determina o comportamento do Storage Firewall é o Public Network Access:

Configuração	Comportamento	Quando usar
Enabled from all networks	Acesso público irrestrito (padrão)	Nunca em produção com dados sensíveis
Enabled from selected virtual networks and IP addresses	Firewall ativo com regras específicas	Cenário mais comum para produção
Disabled	Endpoint público desabilitado; acesso só via Private Endpoint	Máxima segurança, dados altamente sensíveis

A transição do padrão ("all networks") para "selected networks" ativa o firewall e bloqueia todo acesso não explicitamente permitido. É uma mudança de comportamento radical: de "tudo permitido" para "tudo negado exceto o que está na lista".

3.2 Os quatro mecanismos de permissão

Quando o firewall está ativo ("selected networks"), há quatro formas de permitir acesso:

100%

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

3.3 Virtual Network Rules (Service Endpoints)

Uma Virtual Network Rule permite que uma subnet específica acesse a Storage Account diretamente, sem passar pela internet pública.

Para funcionar, a subnet precisa ter o Service Endpoint Microsoft.Storage habilitado. O Service Endpoint é uma configuração na subnet que diz ao Azure: "quando tráfego desta subnet for para o storage, use um caminho interno da rede Microsoft, não a internet pública."

100%

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

Como funciona tecnicamente: quando você habilita Service Endpoints na subnet, o tráfego para o storage usa o IP público do storage mas viaja pelo backbone da Microsoft (rede interna), nunca saindo para a internet. A Storage Account, ao ver a requisição, identifica que ela vem de uma subnet com Service Endpoint configurado e permite o acesso se houver uma Virtual Network Rule para aquela subnet.

3.4 IP Rules

IP Rules são listas de IPs públicos ou ranges CIDR que têm permissão de acesso. São usadas para:

Escritórios corporativos com IP fixo
Pipelines de CI/CD rodando fora do Azure
Workstations de administradores com IPs conhecidos

Restrição importante: IP Rules aceitam apenas endereços IPv4 públicos. Não é possível adicionar:

IPs privados (10.x.x.x, 172.16.x.x, 192.168.x.x)
O range 0.0.0.0/0 (permitiria tudo)
Endereços IPv6

Para acesso de redes privadas (VMs em VNet), use Virtual Network Rules, não IP Rules.

3.5 Resource Instances

Resource Instances permitem que instâncias específicas de serviços Azure acessem o storage, com base na identidade gerenciada (Managed Identity) do recurso, não no IP.

Isso é útil para serviços Azure cujos IPs não são fixos ou previsíveis (como Azure Functions, Logic Apps, ADF), onde você não pode usar IP Rules. Em vez de usar Trusted Services (que concede acesso a uma categoria inteira de serviços), você autoriza uma instância específica.

{
  "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

Alguns serviços da Microsoft precisam acessar o storage para funcionar corretamente, como backups, logs de diagnóstico, Azure Monitor. Quando o firewall está ativo, esses serviços também são bloqueados a menos que você habilite o bypass de Trusted Microsoft Services.

Serviços incluídos no bypass de Trusted Services (seleção dos mais relevantes):

Serviço	Tipo de acesso
Azure Backup	Backup e restore de dados
Azure Monitor	Logs de diagnóstico
Azure DevTest Labs	Acessar imagens e artefatos
Azure Event Grid	Notificações de eventos do storage
Azure Networking	Logs de fluxo para NSG
Azure Site Recovery	Replicação para DR
Azure Machine Learning	Acesso a datasets
Azure Data Factory	Movimentação de dados

Atenção: habilitar Trusted Services concede bypass para uma lista de serviços Microsoft pré-definida. Não é possível customizar quais serviços específicos têm bypass (para isso, use Resource Instances).

3.7 Private Endpoints: a alternativa mais segura

Enquanto o Storage Firewall com Service Endpoints usa o endpoint público da Storage Account (com acesso controlado por rede), um Private Endpoint cria uma interface de rede privada diretamente na sua VNet, com um IP privado, para o storage.

100%

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

Com Private Endpoint, o storage tem um endereço IP privado na sua VNet. O DNS resolve storageaccount.blob.core.windows.net para o IP privado dentro da VNet. O tráfego nunca sai para a internet. O endpoint público pode (e deve) ser completamente desabilitado.

Diferença fundamental entre Service Endpoint e Private Endpoint:

Aspecto	Service Endpoint	Private Endpoint
Endpoint público	Ainda usado (IP público do storage)	Pode ser completamente desabilitado
IP na VNet	Não (tráfego usa IP público via backbone)	Sim (IP privado da sua VNet)
Custo	Sem custo adicional	Custo por hora do Private Endpoint + dados
DNS	Resolve para IP público	Resolve para IP privado (requer DNS privado)
Complexidade	Baixa	Média/alta
Nível de segurança	Alto	Máximo

4. Visão Estrutural

Fluxo de avaliação de uma requisição ao Storage

100%

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

Arquitetura típica de produção com Storage Firewall

100%

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

5. Funcionamento na Prática

Ciclo de configuração do Storage Firewall

100%

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

Comportamentos não óbvios críticos

Ao ativar "selected networks", serviços Azure também são bloqueados. Quando você muda de "all networks" para "selected networks", não apenas a internet é bloqueada. Serviços Azure como Azure Backup, Azure Monitor e o próprio portal Azure para visualização de blobs também são bloqueados. Se você não habilitar Trusted Services e não configurar as regras corretas, ferramentas que funcionavam antes param de funcionar imediatamente.

O portal do Azure é bloqueado por padrão ao ativar o firewall. Tentativa de navegar até "Containers" de um storage com firewall ativo, usando um IP não autorizado, retorna erro. Isso surpreende quem está configurando o firewall pelo próprio portal: a ação de salvar as regras pode funcionar, mas navegar pelo conteúdo pode ser imediatamente bloqueado para o IP da máquina do administrador.

Service Endpoints precisam ser habilitados ANTES de adicionar a VNet Rule. O portal avisa sobre isso, mas em automação é comum errar a ordem. Se você tentar adicionar uma VNet Rule para uma subnet que não tem o Service Endpoint Microsoft.Storage habilitado, a operação falha ou a regra não funciona como esperado.

Logging de tentativas bloqueadas não é automático. Por padrão, o Storage Firewall não loga requisições bloqueadas. Para auditar quem está sendo bloqueado e por quê, você precisa configurar explicitamente os Storage Analytics Logs ou enviar logs para um Log Analytics Workspace via Diagnostic Settings.

Private Endpoint requer configuração de DNS privado. Quando você cria um Private Endpoint, o storage tem um IP privado na sua VNet. Mas o DNS público ainda resolve storageaccount.blob.core.windows.net para o IP público. Para que aplicações dentro da VNet resolvam para o IP privado, você precisa de uma Private DNS Zone (privatelink.blob.core.windows.net) integrada à VNet. Sem isso, as aplicações podem continuar tentando usar o IP público (que você desabilitou) e falhando.

Múltiplos Private Endpoints por serviço de storage. Uma Storage Account tem múltiplos sub-serviços (Blob, File, Queue, Table, DFS). Cada um pode ter seu próprio Private Endpoint independente. Se você cria um Private Endpoint apenas para Blob, File ainda é acessível pelo endpoint público (a menos que você também desabilite o endpoint público do File).

6. Formas de Implementação

Portal do Azure

Quando usar: configuração inicial, verificação visual, alterações pontuais

Configurar Storage Firewall pelo portal:

Portal > Storage Account > Networking
Em Firewalls and virtual networks
Selecionar Enabled from selected virtual networks and IP addresses
Add existing virtual network: selecionar VNet e subnet (o portal avisa se Service Endpoint não está habilitado e oferece habilitá-lo)
Add IP range: adicionar IPs ou CIDRs para acesso externo
Habilitar ou não Allow Azure services on the trusted services list
Decidir sobre Allow storage account key access (separado do firewall, mas relevante)
Save

Limitação: não reproduzível, sem controle de versão.

Azure CLI

# Verificar configuração atual de rede do storage
az storage account show \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --query "networkRuleSet" \
  --output json

# Passo 1: Habilitar Service Endpoint na subnet ANTES de criar a VNet Rule
az network vnet subnet update \
  --name "Subnet-App" \
  --vnet-name "vnet-producao" \
  --resource-group "rg-networking" \
  --service-endpoints "Microsoft.Storage"

# Passo 2: Mudar o default action para Deny (ativa o firewall)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --default-action Deny

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

# Passo 4: Adicionar IP Rule (apenas IPs públicos)
az storage account network-rule add \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --ip-address "200.200.200.0/24"

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

# Passo 5: Habilitar bypass para Trusted Services
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --bypass AzureServices Logging Metrics

# Os valores de bypass são: AzureServices, Logging, Metrics, None
# Múltiplos valores são separados por espaço

# Listar todas as regras de rede
az storage account network-rule list \
  --account-name "stgprod001" \
  --resource-group "rg-storage" \
  --output table

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

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

# Desabilitar completamente o acesso público (Private Endpoint only)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --public-network-access Disabled

# Reabilitar acesso público (para emergências)
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --public-network-access Enabled \
  --default-action Allow

# Criar Private Endpoint para 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"

# Criar DNS Zone para resolução privada do blob
az network private-dns zone create \
  --name "privatelink.blob.core.windows.net" \
  --resource-group "rg-networking"

# Vincular DNS Zone à 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

# Criar registro DNS para o 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

# Habilitar Service Endpoint na 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

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

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

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

# Mudar default action para Deny e habilitar bypass
Update-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001" `
  -DefaultAction Deny `
  -Bypass AzureServices,Logging,Metrics

# Ver configuração atual
Get-AzStorageAccountNetworkRuleSet `
  -ResourceGroupName "rg-storage" `
  -Name "stgprod001"

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

Bicep para Storage com Firewall

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stgprod001'
  location: 'brazilsouth'
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    // Nega acesso público por padrão, exceto regras explícitas
    publicNetworkAccess: 'Enabled'
    networkAcls: {
      defaultAction: 'Deny'  // Bloqueia tudo que não está nas regras
      bypass: 'AzureServices,Logging,Metrics'  // Trusted Services
      
      // Virtual Network Rules
      virtualNetworkRules: [
        {
          id: subnetAppId  // Resource ID da subnet com Service Endpoint
          action: 'Allow'
        }
        {
          id: subnetDataId
          action: 'Allow'
        }
      ]
      
      // IP Rules (apenas IPv4 públicos)
      ipRules: [
        {
          value: '200.200.200.0/24'
          action: 'Allow'
        }
        {
          value: '203.0.113.50'
          action: 'Allow'
        }
      ]
      
      // Resource Instances
      resourceAccessRules: [
        {
          tenantId: tenant().tenantId
          resourceId: synapseWorkspaceId
        }
      ]
    }
    
    // Minimiza superficie de ataque
    allowBlobPublicAccess: false
    allowSharedKeyAccess: true  // Considere false para forçar Azure AD
    minimumTlsVersion: 'TLS1_2'
    supportsHttpsTrafficOnly: true
  }
}

7. Controle e Segurança

Propriedade allowSharedKeyAccess

Esta propriedade, separada do firewall, controla se a autenticação por Account Key (chave de 512 bits) é permitida. Quando definida como false, mesmo quem tem a chave não consegue autenticar com ela; somente Azure AD (RBAC) é aceito.

Recomendação de segurança: para storage accounts de produção, considere desabilitar o acesso por Shared Key e forçar autenticação via Azure AD. Isso elimina o risco de vazamento de chaves de acesso.

# Desabilitar autenticação por Account Key
az storage account update \
  --name "stgprod001" \
  --resource-group "rg-storage" \
  --allow-shared-key-access false

Atenção: ao desabilitar Shared Key, SAS Tokens baseados em Account Key também param de funcionar. Apenas User Delegation SAS (baseado em Azure AD) continuará funcionando.

Configurar logs de diagnóstico para auditoria

# Configurar envio de logs do Storage ao 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}
  ]'

Para verificar requisições bloqueadas pelo firewall, use esta query no Log Analytics:

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

Microsoft Defender for Storage

O Microsoft Defender for Storage adiciona uma camada de detecção de ameaças acima do firewall: ele analisa padrões de acesso e detecta atividades anômalas como acesso de IPs suspeitos, download massivo de dados, upload de malware, etc.

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

8. Tomada de Decisão

Service Endpoint vs. Private Endpoint

Critério	Service Endpoint	Private Endpoint
Nível de segurança	Alto	Máximo
Endpoint público desabilitável	Não (ainda em uso)	Sim
IP na VNet	Não	Sim
Custo	Gratuito	~$0,01/hora + transferência de dados
Configuração de DNS	Não necessária	Obrigatória (Private DNS Zone)
Acesso cross-subscription	Limitado	Suportado
Caso de uso ideal	Maioria dos cenários de produção	Dados altamente sensíveis, compliance máximo

Quando usar cada mecanismo de permissão

Situação	Mecanismo	Motivo
VMs em VNet precisam acessar storage	Virtual Network Rule + Service Endpoint	Caminho interno, sem internet pública
Escritório com IP fixo precisa acessar	IP Rule	IP público conhecido e estável
Azure Backup precisa acessar	Trusted Services bypass	Serviço gerenciado sem IP previsível
Função Azure específica precisa acessar	Resource Instance	Acesso por identidade, não por IP
Dados altamente sensíveis (PCI, saúde)	Private Endpoint + disable público	Elimina completamente o endpoint público
Pipeline de CI/CD fora do Azure	IP Rule ou Service Endpoint via VPN	Depende da arquitetura de rede

Bypass values

Bypass	O que permite	Quando habilitar
`AzureServices`	Trusted Services da Microsoft	Quase sempre; sem isso, backups e logs falham
`Logging`	Storage Analytics Logging	Se usar Storage Analytics (legacy)
`Metrics`	Storage Analytics Metrics	Se usar Storage Analytics (legacy)
`None`	Nenhum bypass; todas as regras se aplicam	Apenas com Private Endpoint onde nenhum serviço externo precisa acessar

9. Boas Práticas

Nunca use "Enabled from all networks" em storage accounts de produção com dados sensíveis. O padrão de "all networks" é para conveniência de desenvolvimento, não para produção. Todo storage de produção deve ter o firewall ativo com "selected networks" como mínimo.

Habilite Service Endpoints antes de adicionar VNet Rules. Em pipelines de IaC, a ordem importa. Se você tentar criar uma VNet Rule para uma subnet sem Service Endpoint, a operação falha ou comporta de forma imprevisível. Sempre provisione Service Endpoints primeiro, VNet Rules depois.

Adicione o IP da sua máquina antes de ativar o firewall. Se você está configurando o firewall interativamente pelo portal ou CLI de uma máquina que não está em nenhuma subnet autorizada, adicione seu IP antes de mudar o default action para Deny. Caso contrário, você perde acesso ao storage no meio da configuração.

Combine firewall com desabilitação de acesso anônimo. O firewall controla de onde se pode acessar. allowBlobPublicAccess: false garante que nenhum container pode ser configurado como público. São proteções complementares: o firewall protege de onde, a configuração de acesso público protege o quê pode ser exposto.

Use Private Endpoints para dados de compliance máximo. PCI-DSS, HIPAA, LGPD em cenários de alta sensibilidade geralmente requerem que dados não trafeguem pela internet pública. Private Endpoint com endpoint público desabilitado é a única forma de garantir isso no Azure Storage.

Configure Diagnostic Settings para logs de firewall antes de ativar. Logs de acesso ao storage são essenciais para auditoria. Configure o envio ao Log Analytics antes de ativar o firewall, para que você tenha visibilidade imediata de qualquer problema.

Documente cada regra de firewall com justificativa. Em VNet Rules e IP Rules, não há campo de descrição, mas mantenha um documento de controle: qual regra foi adicionada, por quem, quando e por qual motivo de negócio. Isso é essencial para auditorias e para saber o que pode ser removido com segurança.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Storage inacessível após ativar firewall	Esquecer de adicionar regras para serviços que já usavam o storage	Auditar todos os consumidores antes de ativar o firewall
VNet Rule não funciona após adição	Service Endpoint não estava habilitado na subnet	Verificar e habilitar Service Endpoint antes da VNet Rule
IP privado adicionado em IP Rule e rejeitado	Confundir IP privado com público	IP Rules só aceitam IPv4 públicos; usar VNet Rules para IPs privados
Azure Backup falha após ativar firewall	Não habilitar bypass AzureServices	Sempre incluir AzureServices no bypass
Private Endpoint criado mas conexão falha	DNS não configurado para resolver para IP privado	Criar Private DNS Zone e vincular à VNet
Portal Azure bloqueado para navegar no storage	IP do administrador não está nas regras	Adicionar IP do admin ou habilitar "Add your client IP address"
Acesso de AKS bloqueado	AKS usa IPs que mudam; IP Rule não funciona	Usar VNet Rule da subnet do AKS ou Managed Identity com Resource Instance
Trusted Services habilitado mas serviço ainda bloqueado	O serviço específico não está na lista de Trusted Services	Verificar lista de Trusted Services ou usar Resource Instance

O erro mais custoso em produção

Ativar o firewall do storage sem testar todos os consumidores: um pipeline de processamento de dados que roda à meia-noite começa a falhar silenciosamente porque a subnet onde ele opera não foi adicionada às VNet Rules. Os dados param de ser processados, mas ninguém percebe até o relatório do dia seguinte estar vazio. Por isso, testar todos os fluxos de acesso antes de ativar e monitorar logs nas primeiras 48 horas após a ativação é fundamental.

11. Operação e Manutenção

Verificar e auditar configuração do firewall

# Ver configuração completa de rede
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

# Listar todos os storage accounts com acesso público irrestrito
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 sem firewall
az graph query -q "
Resources
| where type == 'microsoft.storage/storageaccounts'
| where properties.networkAcls.defaultAction == 'Allow'
| project name, resourceGroup, subscriptionId, location"

Monitorar acessos bloqueados

# Query no Log Analytics para ver IPs bloqueados
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"

Limites importantes

Limite	Valor
Virtual Network Rules por Storage Account	200
IP Rules por Storage Account	200
Private Endpoints por Storage Account	Sem limite documentado (prático: alguns por serviço)
Sub-serviços com Private Endpoint independente	Blob, File, Queue, Table, DFS (cada um separado)
Service Endpoints por subnet	Múltiplos (por provider namespace)

12. Integração e Automação

Automação de configuração de firewall em scale

# Aplicar configuração de firewall em todos os storage accounts de um RG
for storage_name in $(az storage account list \
  --resource-group "rg-storage" \
  --query "[].name" -o tsv); do
  
  echo "Configurando firewall para: $storage_name"
  
  # Ativar firewall
  az storage account update \
    --name "$storage_name" \
    --resource-group "rg-storage" \
    --default-action Deny \
    --bypass AzureServices Logging Metrics
  
  # Adicionar VNet Rule padrão
  az storage account network-rule add \
    --account-name "$storage_name" \
    --resource-group "rg-storage" \
    --vnet-name "vnet-producao" \
    --subnet "Subnet-App"
done

Azure Policy para enforçar configurações de firewall

Uma policy que audita (ou nega) storage accounts sem firewall ativo:

# Usando a 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"}}'

Built-in policies relevantes para Storage Networking:

Policy Name	ID	Descrição
Storage accounts should restrict network access	`34c877ad-...`	Audita storage sem firewall
Storage accounts should use private link	`6edd7eda-...`	Audita storage sem Private Endpoint
Storage accounts should prevent shared key access	`8c6a50c6-...`	Audita storage com Shared Key habilitado
Secure transfer to storage accounts should be enabled	`404c3081-...`	Audita storage sem HTTPS obrigatório

Integração com Azure Private DNS Zones

Em organizações com múltiplas VNets e Private Endpoints, o gerenciamento de DNS privado pode ser centralizado:

100%

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

Com uma única Private DNS Zone centralizada vinculada a todas as VNets, todos os Private Endpoints criados registram automaticamente seus IPs privados na zona, e todas as VNets resolvem corretamente.

13. Resumo Final

Pontos essenciais:

O Storage Firewall tem três modos: all networks (padrão, sem restrição), selected networks (firewall ativo com regras), Disabled (apenas Private Endpoint)
Ao ativar "selected networks", tudo é bloqueado exceto o que está explicitamente permitido nas regras
Os quatro mecanismos de permissão são: VNet Rules (subnets com Service Endpoint), IP Rules (IPs públicos IPv4), Resource Instances (serviços Azure por identidade) e Trusted Services (bypass para serviços Microsoft)
IP Rules aceitam apenas IPs públicos IPv4: para subnets privadas, use VNet Rules com Service Endpoint
Service Endpoint deve ser habilitado na subnet antes de criar a VNet Rule no storage
Private Endpoint cria um IP privado na VNet; requer Private DNS Zone para resolução correta

Diferenças críticas:

Service Endpoint vs. Private Endpoint: Service Endpoint usa o endpoint público do storage via backbone Microsoft (sem eliminar o endpoint público); Private Endpoint cria IP privado e permite desabilitar completamente o endpoint público
Trusted Services vs. Resource Instances: Trusted Services é um bypass para uma lista pré-definida de serviços Microsoft (tudo ou nada); Resource Instances permite autorizar uma instância específica de um serviço por identidade
IP Rule vs. VNet Rule: IP Rule para IPs públicos conhecidos (escritórios, CIDRs externos); VNet Rule para recursos dentro de VNets Azure

O que precisa ser lembrado para o AZ-104:

Ao ativar o firewall, o default action muda de Allow para Deny; todo o tráfego não listado é bloqueado
Bypass values: AzureServices (Trusted Services), Logging e Metrics (Storage Analytics); separados da configuração de regras
O limite de regras por storage account é 200 VNet Rules + 200 IP Rules
Private Endpoint requer Private DNS Zone (privatelink.blob.core.windows.net) vinculada à VNet
A propriedade allowSharedKeyAccess: false desabilita autenticação por Account Key, complementando o firewall
Logs de requisições bloqueadas pelo firewall precisam ser configurados explicitamente via Diagnostic Settings

1. Intuição Inicial​

2. Contexto​

Onde Storage Firewalls se encaixam na segurança do Azure​

Por que Storage Firewalls existem​

O que depende do Storage Firewall​

3. Construção dos Conceitos​

3.1 Configurações de acesso público: o ponto de partida​

3.2 Os quatro mecanismos de permissão​

3.3 Virtual Network Rules (Service Endpoints)​

3.4 IP Rules​

3.5 Resource Instances​

3.6 Trusted Microsoft Services​

3.7 Private Endpoints: a alternativa mais segura​

4. Visão Estrutural​

Fluxo de avaliação de uma requisição ao Storage​

Arquitetura típica de produção com Storage Firewall​

5. Funcionamento na Prática​

Ciclo de configuração do Storage Firewall​

Comportamentos não óbvios críticos​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep para Storage com Firewall​

7. Controle e Segurança​

Propriedade allowSharedKeyAccess​

Configurar logs de diagnóstico para auditoria​

Microsoft Defender for Storage​

8. Tomada de Decisão​

Service Endpoint vs. Private Endpoint​

Quando usar cada mecanismo de permissão​

Bypass values​

9. Boas Práticas​

10. Erros Comuns​

O erro mais custoso em produção​

11. Operação e Manutenção​

Verificar e auditar configuração do firewall​

Monitorar acessos bloqueados​

Limites importantes​

12. Integração e Automação​

Automação de configuração de firewall em scale​

Azure Policy para enforçar configurações de firewall​

Integração com Azure Private DNS Zones​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde Storage Firewalls se encaixam na segurança do Azure

Por que Storage Firewalls existem

O que depende do Storage Firewall

3. Construção dos Conceitos

3.1 Configurações de acesso público: o ponto de partida

3.2 Os quatro mecanismos de permissão

3.3 Virtual Network Rules (Service Endpoints)

3.4 IP Rules

3.5 Resource Instances

3.6 Trusted Microsoft Services

3.7 Private Endpoints: a alternativa mais segura

4. Visão Estrutural

Fluxo de avaliação de uma requisição ao Storage

Arquitetura típica de produção com Storage Firewall

5. Funcionamento na Prática

Ciclo de configuração do Storage Firewall

Comportamentos não óbvios críticos

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep para Storage com Firewall

7. Controle e Segurança

Propriedade allowSharedKeyAccess

Configurar logs de diagnóstico para auditoria

Microsoft Defender for Storage

8. Tomada de Decisão

Service Endpoint vs. Private Endpoint

Quando usar cada mecanismo de permissão

Bypass values

9. Boas Práticas

10. Erros Comuns

O erro mais custoso em produção

11. Operação e Manutenção

Verificar e auditar configuração do firewall

Monitorar acessos bloqueados

Limites importantes

12. Integração e Automação

Automação de configuração de firewall em scale

Azure Policy para enforçar configurações de firewall

Integração com Azure Private DNS Zones

13. Resumo Final