Laboratório de Troubleshooting: Configure Azure Storage Firewalls and Virtual Networks
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de dados configurou uma Storage Account para aceitar tráfego apenas de uma sub-rede específica chamada snet-analytics dentro da VNet vnet-prod. A configuração foi aplicada via portal e não houve mensagem de erro durante o processo.
O ambiente é o seguinte:
Storage Account: stprodanalytic01
Região: East US
Replicação: LRS
Ação padrão do firewall: Deny
Regras de rede virtual configuradas: snet-analytics (vnet-prod)
Regras de IP: nenhuma
Exceções: nenhuma habilitada
Uma VM chamada vm-etl-01, localizada exatamente na sub-rede snet-analytics, tenta montar um file share via SMB e recebe o seguinte erro:
Error 0x800704cf: The network path was not found.
A equipe confirma que a VM tem conectividade geral com a internet, que o firewall da VM não bloqueia a porta 445 e que a Storage Account key está correta. A conta de armazenamento foi criada há três dias.
Qual é a causa raiz do problema?
A. A porta 445 está bloqueada em um Network Security Group associado à sub-rede snet-analytics, impedindo o tráfego SMB mesmo com a regra de rede virtual configurada.
B. O service endpoint Microsoft.Storage não está habilitado na sub-rede snet-analytics, fazendo com que o tráfego da VM não seja reconhecido como originado da VNet pela Storage Account.
C. A replicação LRS não é compatível com regras de rede virtual em Storage Accounts criadas recentemente, exigindo um período de propagação de até 72 horas.
D. A ação padrão Deny bloqueia também o tráfego de sub-redes configuradas como regra enquanto a Storage Account está no estado de provisionamento inicial.
Cenário 2 — Decisão de Ação
A causa de um incidente foi identificada: uma Storage Account de produção está recusando conexões de um pipeline de ingestão de dados hospedado em Azure Data Factory. A investigação confirmou que o problema é a ausência do serviço Azure Data Factory na lista de exceções Allow trusted Microsoft services da Storage Account.
O ambiente tem as seguintes restrições:
- A Storage Account serve também uma aplicação web crítica em produção que consome blobs a cada 30 segundos
- A alteração de exceções de firewall em Storage Accounts pode causar uma breve janela de reinicialização das regras de rede, estimada em 5 a 15 segundos
- O time de operações possui permissão de Contributor na Storage Account
- A janela de manutenção oficial é às 02h00, em 6 horas
- O pipeline de ingestão está parado há 40 minutos e acumula dados não processados, mas sem perda definitiva, pois a fonte mantém retenção de 7 dias
Qual é a ação correta a tomar neste momento?
A. Aplicar a exceção imediatamente, pois a janela de breve reinicialização das regras é aceitável e o pipeline está parado há tempo suficiente para justificar o risco.
B. Aguardar a janela de manutenção às 02h00 para aplicar a exceção, pois a aplicação web em produção pode ser afetada pela breve janela de reinicialização das regras.
C. Criar uma segunda Storage Account sem restrições de firewall, redirecionar o Data Factory para ela e migrar os dados após a janela de manutenção.
D. Remover temporariamente a ação padrão Deny da Storage Account para permitir o pipeline e reabilitá-la após a ingestão ser concluída.
Cenário 3 — Causa Raiz
Um administrador relata que uma Storage Account que funcionava normalmente parou de receber logs de diagnóstico do Azure Monitor. O administrador inspeciona o recurso e observa o seguinte estado:
Storage Account: stlogs-monitor-prod
Firewall: habilitado
Ação padrão: Deny
Regras de IP: 203.0.113.45/32
Regras de rede virtual: nenhuma
Exceções habilitadas: Allow storage account key access, Allow blob public access
O administrador também verifica que:
- A configuração de diagnóstico no Azure Monitor aponta corretamente para
stlogs-monitor-prod - A Storage Account está na mesma região que os recursos monitorados
- A conta tem espaço disponível e não atingiu nenhum limite de capacidade
- O IP
203.0.113.45pertence ao laptop do administrador e foi adicionado para testes
Qual é a causa raiz do problema?
A. A regra de IP 203.0.113.45/32 está em conflito com a configuração do Azure Monitor, pois regras de IP explícitas desativam o envio de diagnósticos por serviços internos do Azure.
B. A opção Allow storage account key access está habilitada, o que força o Azure Monitor a autenticar via chave, método que é bloqueado pelo firewall quando a ação padrão é Deny.
C. A exceção Allow trusted Microsoft services não está habilitada, impedindo que o Azure Monitor, que é um serviço confiável da Microsoft, escreva os logs de diagnóstico.
D. A Storage Account não possui regras de rede virtual configuradas, e o Azure Monitor exige obrigatoriamente que a sub-rede de origem esteja registrada como regra de rede virtual para aceitar gravações.
Cenário 4 — Impacto Colateral
Um administrador identifica que desenvolvedores estão acessando uma Storage Account de produção diretamente pela internet usando a storage account key, contornando as políticas de rede. Para corrigir isso imediatamente, o administrador habilita o firewall da Storage Account com ação padrão Deny e não adiciona nenhuma regra adicional, nenhuma exceção e nenhuma regra de rede virtual.
O acesso indevido dos desenvolvedores é imediatamente bloqueado conforme esperado.
Qual consequência secundária essa ação pode causar?
A. A Storage Account passará a rejeitar também os backups realizados pelo Azure Backup, pois a ausência de qualquer regra impede que serviços confiáveis sejam reconhecidos mesmo que a exceção estivesse previamente habilitada.
B. Os blobs existentes na Storage Account serão automaticamente marcados como imutáveis pelo Azure até que pelo menos uma regra de acesso seja configurada, protegendo os dados durante a transição.
C. Serviços do Azure que dependem dessa Storage Account e que não são cobertos pela exceção Allow trusted Microsoft services, como Azure Functions no plano Consumption sem integração VNet, perderão acesso imediatamente.
D. A ação padrão Deny sem regras configuradas ativa automaticamente o modo de auditoria do Azure Policy, gerando alertas de compliance que podem travar operações em outros recursos do mesmo Resource Group.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na própria descrição do problema: a regra de rede virtual foi configurada na Storage Account, mas o cenário não menciona em nenhum momento que o service endpoint Microsoft.Storage foi habilitado na sub-rede snet-analytics. Sem o service endpoint, o tráfego originado da VM não é reconhecido pelo Azure como tráfego de VNet; ele chega à Storage Account aparentando ser tráfego de internet, que é bloqueado pela ação padrão Deny.
A informação sobre a porta 445 e o firewall da VM é relevante para o sintoma SMB, mas é um detalhe irrelevante aqui, pois a equipe já confirmou que a porta 445 não está bloqueada na VM. A alternativa A é um distrator que direciona o diagnóstico para o NSG, que é um equívoco clássico de focar no sintoma de rede sem verificar o pré-requisito do service endpoint. As alternativas C e D descrevem comportamentos que não existem na plataforma, mas são formuladas de forma plausível o suficiente para atrair quem não tem certeza sobre restrições de replicação ou ciclo de provisionamento.
O distrator mais perigoso é a alternativa A: um administrador que fosse investigar o NSG perderia tempo e poderia abrir regras desnecessárias sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica é a aplicação web em produção que consome blobs a cada 30 segundos. Uma breve janela de reinicialização das regras, mesmo que de 5 a 15 segundos, representa um risco real de interrupção para essa aplicação. O pipeline do Data Factory, por outro lado, não está perdendo dados: a fonte mantém retenção de 7 dias, e o atraso de 40 minutos é recuperável. A janela de manutenção existe exatamente para situações como essa, onde a correção é conhecida, mas o custo de aplicá-la agora supera o custo de aguardar.
A alternativa A representa a ação tecnicamente correta aplicada sem considerar a restrição de produção ativa. A alternativa C é uma solução válida em outro contexto, mas é desproporcional e introduz complexidade desnecessária para um problema que tem solução simples na janela de manutenção. A alternativa D é a mais perigosa: remover a ação padrão Deny expõe a Storage Account inteiramente à internet durante o período, o que é uma violação de segurança muito mais grave do que o atraso no pipeline.
Gabarito — Cenário 3
Resposta: C
O estado do firewall mostra claramente que a única exceção habilitada é Allow storage account key access e Allow blob public access, nenhuma das quais cobre o Azure Monitor. A exceção Allow trusted Microsoft services está ausente. O Azure Monitor é listado como um serviço confiável da Microsoft e depende exatamente dessa exceção para conseguir gravar logs em Storage Accounts com firewall restritivo.
A informação sobre o IP do laptop do administrador (203.0.113.45/32) e sobre a capacidade disponível são detalhes irrelevantes incluídos propositalmente. O IP do laptop não interfere na operação do Azure Monitor. A alternativa A é um distrator que induz o diagnóstico errado ao sugerir uma interação inexistente entre regras de IP e o comportamento de serviços internos. A alternativa B confunde o mecanismo de autenticação com o mecanismo de controle de rede, que são camadas independentes. A alternativa D descreve um requisito que não existe: o Azure Monitor não precisa de regra de rede virtual, ele depende da exceção de trusted services.
O erro mais comum nesse cenário é focar nas configurações presentes e esquecer de verificar o que está ausente.
Gabarito — Cenário 4
Resposta: C
Quando o firewall é habilitado com ação padrão Deny e sem nenhuma exceção configurada, todos os caminhos de acesso são bloqueados, incluindo os de serviços do Azure que dependem da Storage Account. Serviços como Azure Functions no plano Consumption, que não possuem integração VNet e não são cobertos pela exceção Allow trusted Microsoft services, perdem acesso imediatamente. Esse é o impacto colateral direto e esperado da ação descrita.
A alternativa A está incorreta porque a exceção Allow trusted Microsoft services não é habilitada automaticamente; ela precisa ser configurada explicitamente. Se não estava habilitada antes, a ação do administrador não a remove. A alternativa B descreve um comportamento que não existe na plataforma: o Azure não marca blobs como imutáveis automaticamente por mudanças de firewall. A alternativa D também descreve um comportamento inexistente: a ação padrão Deny não ativa modos de auditoria automaticamente nem afeta outros recursos do Resource Group.
O impacto colateral real é silencioso e pode não ser imediatamente visível, especialmente se os serviços afetados não tiverem alertas configurados, o que torna essa consequência particularmente crítica em ambientes de produção.
Árvore de Troubleshooting: Configure Azure Storage Firewalls and Virtual Networks
Legenda
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada |
| Azul | Pergunta de diagnóstico, nó de decisão |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária antes de confirmar a causa |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando que o acesso à Storage Account está sendo negado com o firewall ativo. Siga cada pergunta de diagnóstico respondendo sim ou não com base no que você consegue observar diretamente no portal ou via CLI. Os nós de verificação intermediária em laranja indicam pontos onde é necessário confirmar um detalhe antes de concluir a causa. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente associado indica a ação corretiva correspondente.