Laboratório de Troubleshooting: Design an Azure Firewall Deployment
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de redes implantou um Azure Firewall Standard na sub-rede AzureFirewallSubnet da VNet hub vnet-hub-eastus. As VNets spoke vnet-app e vnet-data estão conectadas via peering à VNet hub. Uma UDR foi aplicada a ambas as VNets spoke redirecionando 0.0.0.0/0 para o IP privado do firewall.
Após a implantação, os administradores relatam que VMs nas VNets spoke conseguem se comunicar com a internet normalmente, mas o tráfego entre as duas VNets spoke está sendo descartado sem nenhuma mensagem de erro explícita.
O administrador verifica as regras configuradas no Azure Firewall e encontra o seguinte:
Regras de rede:
Nome: Allow-Internet-Outbound
Origem: 10.0.0.0/8
Destino: *
Protocolo: TCP
Porta: 80,443
Acao: Allow
Regras de aplicacao: nenhuma configurada
Regras NAT: nenhuma configurada
Informações adicionais coletadas:
- O peering entre
vnet-hub-eastuse as VNets spoke está comAllow forwarded traffichabilitado - O Azure Firewall está no estado
Runninge com throughput dentro do limite esperado - O Log Analytics Workspace foi associado ao firewall há duas semanas
- A sub-rede
AzureFirewallSubnettem tamanho/26
Qual é a causa raiz do problema observado?
A. O peering entre as VNets spoke e a VNet hub está configurado incorretamente porque a opção Use remote gateways não está habilitada.
B. Não existe uma regra de rede no Azure Firewall que permita explicitamente o tráfego entre os prefixos das VNets spoke, e o comportamento padrão do firewall é negar tudo que não foi permitido.
C. O Log Analytics Workspace foi associado recentemente e ainda não está capturando os logs de fluxo negado, impedindo o diagnóstico correto.
D. A sub-rede AzureFirewallSubnet com tamanho /26 é insuficiente para o Azure Firewall Standard e está causando descarte de pacotes.
Cenário 2 — Sequência de Diagnóstico
Um engenheiro recebe o chamado: o Azure Firewall está permitindo tráfego que deveria ser bloqueado por uma regra de aplicação recém-criada. O tráfego em questão é HTTP para um domínio específico a partir de uma VM na VNet spoke.
Os passos disponíveis para a investigação são:
- (P) Verificar nos logs do Azure Firewall (categoria
AzureFirewallApplicationRule) se o tráfego aparece como permitido ou negado e qual regra foi aplicada - (Q) Confirmar que a UDR da subnet da VM está redirecionando o tráfego para o IP privado do firewall
- (R) Verificar a prioridade da coleção de regras que contém a regra de bloqueio em relação às demais coleções de regras de aplicação
- (S) Confirmar que a regra de aplicação está configurada com o FQDN correto e o protocolo HTTP na porta 80
- (T) Testar a conectividade a partir da VM para o domínio bloqueado usando
curlou navegador
Qual é a sequência correta de investigação?
A. T → P → Q → S → R
B. Q → T → P → R → S
C. P → Q → S → T → R
D. T → Q → P → S → R
Cenário 3 — Causa Raiz
A equipe de segurança configurou uma Firewall Policy no Azure Firewall Premium com uma regra de aplicação para inspecionar e bloquear tráfego TLS de saída para a categoria de sites classificada como Malware. O ambiente tem as seguintes características:
- O Azure Firewall Premium está implantado na VNet hub
- A Firewall Policy tem TLS Inspection habilitada
- Foi criado um certificado raiz autoassinado para a inspeção TLS e armazenado no Key Vault
- A regra de aplicação aponta para a categoria
Malwarecom açãoDeny - VMs nas VNets spoke continuam conseguindo acessar sites classificados como malware sem bloqueio
O time de operações verifica os logs e encontra o seguinte:
Category: AzureFirewallApplicationRule
Action: Allow
Rule: Default-Allow-Web
RuleCollection: AllowWeb-Collection
TargetUrl: http://known-malware-site.example.com
Protocol: Http:80
O administrador de segurança menciona que o certificado raiz foi importado para o Key Vault há três dias. O throughput do firewall está dentro do esperado. A identidade gerenciada do firewall tem acesso ao Key Vault.
Qual é a causa raiz do problema observado?
A. O certificado raiz autoassinado foi importado para o Key Vault recentemente e ainda não foi sincronizado com o Azure Firewall Premium.
B. O tráfego registrado nos logs usa o protocolo HTTP na porta 80, que não é tráfego TLS. A inspeção TLS e a regra de categoria de malware se aplicam apenas a tráfego HTTPS, portanto outra regra de permissão está sendo aplicada antes.
C. A identidade gerenciada do firewall não tem permissões suficientes no Key Vault para acessar o certificado, fazendo com que a inspeção TLS falhe silenciosamente e o tráfego seja permitido.
D. A Firewall Policy com TLS Inspection habilitada é incompatível com regras de categoria de ameaças no Azure Firewall Premium, e as duas funcionalidades não podem ser usadas simultaneamente.
Cenário 4 — Decisão de Ação
A equipe de arquitetura identificou que o Azure Firewall implantado em produção está no SKU Standard e precisa ser migrado para o SKU Premium para habilitar a inspeção TLS e o filtro por categoria de ameaças. O firewall está em operação ativa, processando todo o tráfego de saída de 12 VNets spoke. A migração precisa ocorrer com a menor janela de indisponibilidade possível.
A causa está identificada: o SKU Standard não suporta os recursos necessários. O contexto adicional é:
- Existe uma Firewall Policy do tipo Standard já associada ao firewall atual
- O ambiente possui um segundo ambiente de staging com configuração idêntica
- O time de Change Management exige janela de manutenção aprovada para qualquer alteração que afete o plano de dados
- O time de redes tem acesso completo ao Azure e pode executar a migração
Qual é a ação correta a tomar neste momento?
A. Excluir o Azure Firewall Standard atual, provisionar um novo Azure Firewall Premium no mesmo lugar e reatribuir todas as UDRs das VNets spoke para o novo IP privado do firewall Premium.
B. Atualizar o SKU do Azure Firewall existente diretamente pelo portal do Azure de Standard para Premium, mantendo o mesmo IP e as mesmas UDRs sem interrupção.
C. Migrar a Firewall Policy existente do tipo Standard para o tipo Premium, associar ao firewall atual e aguardar a sincronização automática dos novos recursos.
D. Provisionar um novo Azure Firewall Premium em paralelo, migrar a Firewall Policy para o tipo Premium, validar no ambiente de staging, e planejar a cutover com janela de manutenção aprovada atualizando as UDRs no momento da transição.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O Azure Firewall opera com uma política de negação implícita: qualquer tráfego que não seja explicitamente permitido por uma regra de rede, de aplicação ou NAT é descartado. A regra existente, Allow-Internet-Outbound, permite apenas tráfego TCP nas portas 80 e 443 com destino a qualquer endereço, o que cobre comunicação com a internet. Não existe nenhuma regra que permita tráfego entre os prefixos das VNets spoke, como de 10.1.0.0/16 para 10.2.0.0/16. Todo esse tráfego chega ao firewall via UDR e é silenciosamente descartado por ausência de regra correspondente.
A pista confirmatória está na ausência de regras que cubram comunicação leste-oeste entre as VNets spoke. O tráfego para a internet funciona porque existe uma regra para ele; o tráfego spoke-a-spoke falha porque não existe.
Informações irrelevantes: O Log Analytics Workspace associado há duas semanas não afeta o comportamento do firewall. A sub-rede /26 é o tamanho mínimo recomendado para o Azure Firewall e está correto. O peering com Allow forwarded traffic está adequado.
O distrator mais perigoso é o A, que leva o administrador a modificar configurações de peering que estão corretas, perdendo tempo enquanto o problema real, a ausência de regra de rede, permanece sem solução.
Gabarito — Cenário 2
Resposta: B
A sequência correta é Q → T → P → R → S:
- Antes de qualquer teste, é preciso confirmar que o tráfego da VM está de fato passando pelo firewall via UDR (Q). Se a UDR estiver ausente ou incorreta, o firewall nunca verá o tráfego e qualquer investigação nas regras será inútil.
- Com a rota confirmada, reproduz-se o comportamento (T) para garantir que o problema ainda ocorre e gerar entradas nos logs.
- Consultam-se os logs (P) para verificar qual regra foi efetivamente aplicada ao tráfego.
- Com o nome da regra e da coleção identificados nos logs, verifica-se a prioridade (R) para entender se outra coleção com prioridade mais alta está permitindo o tráfego antes da regra de bloqueio.
- Confirma-se a configuração exata da regra (S) para validar FQDN e protocolo.
A alternativa A pula a verificação da UDR e vai direto ao teste, o que pode gerar resultados enganosos. A alternativa C começa pelos logs sem antes reproduzir o problema, o que pode resultar em logs sem entradas recentes. A alternativa D verifica a UDR depois do teste, invertendo a ordem lógica.
Gabarito — Cenário 3
Resposta: B
O log registra o acesso ao site como Protocol: Http:80, ou seja, tráfego HTTP puro na porta 80, não HTTPS. A inspeção TLS do Azure Firewall Premium intercepta e inspeciona apenas tráfego TLS/HTTPS. Regras de categoria de ameaças que dependem de inspeção de conteúdo também operam sobre tráfego HTTPS. Tráfego HTTP na porta 80 não passa pela cadeia de inspeção TLS e é avaliado apenas pelas regras de aplicação comuns sem inspeção de conteúdo. Como existe uma regra Allow com prioridade mais alta cobrindo tráfego HTTP, o acesso é permitido antes de qualquer análise de categoria.
A pista confirmatória está no campo Protocol: Http:80 nos logs, que revela que o tráfego não é TLS e portanto nunca seria interceptado pela funcionalidade de TLS Inspection.
Informações irrelevantes: A data de importação do certificado, o throughput e as permissões da identidade gerenciada são detalhes que não influenciam o diagnóstico, pois o problema não envolve TLS.
O distrator mais perigoso é o C, que leva o administrador a investigar permissões do Key Vault e possivelmente conceder acessos desnecessários, quando a causa real é a natureza não-TLS do tráfego.
Gabarito — Cenário 4
Resposta: D
A ação correta é provisionar o Azure Firewall Premium em paralelo, validar no ambiente de staging e executar a cutover em janela de manutenção aprovada. Essa abordagem atende a todas as restrições do cenário: minimiza indisponibilidade ao manter o firewall atual operacional até o momento da transição, respeita o processo de Change Management, e permite validação prévia no staging antes de afetar produção.
A alternativa A requer excluir o firewall existente antes de provisionar o novo, o que implica interrupção total de todo o tráfego das 12 VNets spoke durante o provisionamento. A alternativa B é tecnicamente inválida: o Azure Firewall não suporta upgrade de SKU in-place de Standard para Premium; são recursos distintos que precisam ser criados separadamente. A alternativa C também é inválida: uma Firewall Policy do tipo Standard não pode ser convertida para Premium; é necessário criar uma nova policy Premium e reconfigurar as regras.
O erro de raciocínio central nos distratores A e B é assumir que existe um caminho de migração in-place quando, na prática, a transição entre SKUs exige implantação de um novo recurso.
Árvore de Troubleshooting: Design an Azure Firewall Deployment
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar a árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no ambiente. O primeiro passo obrigatório é confirmar que o tráfego está de fato chegando ao firewall via UDR, pois sem essa confirmação qualquer investigação nas regras pode ser irrelevante. Em seguida, verifique os logs antes de qualquer alteração, pois eles revelam qual regra foi aplicada e em qual direção. Siga o caminho correspondente ao comportamento observado: tráfego bloqueado indevidamente aponta para ausência de regras ou incompatibilidade de SKU; tráfego permitido indevidamente aponta para problemas de prioridade de coleções, protocolo não coberto pela inspeção ou falha na cadeia de TLS Inspection.