Laboratório de Troubleshooting: Azure Firewall Manager Policies
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de rede recebeu reclamações de que uma aplicação crítica hospedada em uma spoke VNet parou de receber tráfego externo após uma janela de manutenção realizada na sexta-feira à noite. O ambiente utiliza Azure Firewall Manager com uma Firewall Policy hierárquica: uma política pai de nível corporativo e uma política filha associada ao hub gerenciado.
Durante a manutenção, foram realizadas as seguintes ações:
- Atualização da política filha com novas regras de aplicação para um novo SaaS
- Adição de um FQDN tag personalizado na política pai
- Renovação do certificado TLS usado pela inspeção de TLS na política filha
- Reinicialização do Azure Firewall via portal
Após a janela, o time verifica o seguinte comportamento:
Connection attempt to 10.20.5.10:443 from 203.0.113.45
Action: Deny
Rule Collection: DefaultDeny
Policy: ChildPolicy-Prod
Matched Rule: None
Threat Intel: No match
O tráfego em questão sempre foi permitido por uma regra de rede na política pai, nunca na filha. A política filha tem Threat Intelligence configurada em modo Alert and Deny. O SKU do firewall é Standard.
Qual é a causa raiz do problema?
A) A reinicialização do Azure Firewall apagou o estado das regras ativas, exigindo reaplicação manual das políticas.
B) A política filha sobrescreveu a regra de rede da política pai porque regras de rede em políticas filhas têm prioridade sobre as da política pai.
C) O certificado TLS renovado na política filha está inválido, causando bloqueio de todo tráfego HTTPS inspecionado.
D) A regra de rede da política pai não é herdada pela política filha porque o firewall associado usa SKU Standard, que não suporta hierarquia de políticas.
Cenário 2 — Decisão de Ação
Você é o arquiteto responsável por uma topologia hub-and-spoke com Azure Virtual WAN. O ambiente possui um Secured Virtual Hub com Azure Firewall gerenciado pelo Firewall Manager. Uma auditoria interna identificou que o seguinte comportamento está ocorrendo:
Source: 10.1.0.5 (Spoke A)
Destination: 10.2.0.8 (Spoke B)
Port: 1433
Action: Allow
Rule: AllowAll-Network
Policy: HubPolicy-Dev
A política HubPolicy-Dev foi associada ao hub de produção por engano durante uma atualização. Ela contém uma regra de rede AllowAll-Network que permite todo tráfego entre spokes sem restrição. A política correta é a HubPolicy-Prod, que contém regras específicas por segmento.
O ambiente está em produção ativa com dezenas de conexões estabelecidas. Não há janela de manutenção disponível nas próximas 6 horas.
Qual é a ação correta a tomar neste momento?
A) Dissociar imediatamente a HubPolicy-Dev do hub e associar a HubPolicy-Prod, aceitando a interrupção momentânea como necessária para restaurar a postura de segurança.
B) Editar a HubPolicy-Dev diretamente, adicionando as regras de restrição da HubPolicy-Prod, sem alterar a associação, até que a janela de manutenção esteja disponível.
C) Criar uma regra de negação com prioridade mais alta dentro da HubPolicy-Dev para bloquear o tráfego irrestrito até que a troca possa ser feita na janela de manutenção.
D) Não realizar nenhuma alteração até a janela de manutenção e registrar o incidente, pois qualquer modificação em produção sem janela pode causar impacto maior do que a vulnerabilidade existente.
Cenário 3 — Causa Raiz
Um administrador reporta que, após associar uma nova Firewall Policy a um Azure Firewall existente via Firewall Manager, as regras de aplicação que permitem acesso a *.microsoft.com pararam de funcionar para um grupo específico de usuários. Os demais usuários não foram afetados.
O ambiente possui as seguintes características:
- Firewall SKU: Premium
- TLS Inspection: habilitada
- A nova política substituiu a anterior, que não tinha TLS Inspection configurada
- O grupo afetado usa dispositivos com um certificado raiz corporativo diferente do padrão da organização
- O certificado intermediário do firewall foi emitido por uma CA interna
- O log do firewall mostra:
Category: AzureFirewallApplicationRule
Action: Deny
Rule: AllowMicrosoftFQDN
Fqdn: login.microsoft.com
Protocol: Https
TlsInspectionEnabled: true
TlsInspectionResult: CertificateValidationFailed
O administrador imediatamente suspeita que a regra de aplicação foi configurada incorretamente. Ele também menciona que o SKU foi atualizado de Standard para Premium há três semanas, mas que tudo estava funcionando até a troca de política.
Qual é a causa raiz do problema?
A) A regra de aplicação AllowMicrosoftFQDN foi configurada sem o protocolo HTTPS, impedindo a inspeção TLS de processar as requisições corretamente.
B) O certificado raiz da CA interna que emitiu o certificado intermediário do firewall não está presente no repositório de certificados confiáveis dos dispositivos do grupo afetado.
C) A atualização de SKU de Standard para Premium gerou incompatibilidade com a política anterior, corrompendo as regras de aplicação herdadas.
D) A habilitação de TLS Inspection na nova política requer que o FQDN *.microsoft.com seja adicionado à lista de exclusão de inspeção TLS, pois FQDNs da Microsoft não suportam interceptação de TLS.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta às 14h37 em um ambiente de produção:
Alert: Azure Firewall - High Threat Intelligence Hit Rate
Hub: SecuredHub-EastUS
Policy: CorporatePolicy-Prod
Period: Last 15 minutes
Threat Intel Hits: 847
Action Configured: Alert Only
Pouco depois, usuários reportam lentidão generalizada no acesso à internet a partir de todas as spokes conectadas ao hub. O firewall está respondendo, mas com latência elevada. O time suspeita que o volume de hits de Threat Intelligence e a lentidão estejam relacionados, mas não tem certeza de como proceder.
Os passos de investigação disponíveis são:
- Verificar nos logs do Diagnostic Settings se os hits de Threat Intelligence correspondem a IPs de destino legítimos ou maliciosos conhecidos
- Analisar as métricas do Azure Firewall no Azure Monitor para identificar throughput, conexões ativas e uso de SNAT ports
- Confirmar se a política está em modo Alert Only ou Alert and Deny para Threat Intelligence
- Verificar se houve mudança recente de configuração na política via Azure Activity Log
- Checar se o SKU do firewall suporta o volume atual de conexões e se há necessidade de escalonamento
Qual é a sequência correta de investigação?
A) 3 -> 1 -> 4 -> 2 -> 5
B) 2 -> 3 -> 1 -> 4 -> 5
C) 4 -> 1 -> 3 -> 2 -> 5
D) 1 -> 4 -> 2 -> 3 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: D
A causa raiz é que o Azure Firewall com SKU Standard não suporta hierarquia de políticas. A herança pai-filho no Firewall Manager é uma funcionalidade exclusiva do SKU Premium. Com o SKU Standard, apenas uma política pode ser associada ao firewall, e ela é aplicada de forma plana, sem herança de uma política pai.
A pista definitiva no enunciado é a combinação de dois elementos: o uso de hierarquia de políticas (política pai e filha) e o SKU Standard declarado explicitamente. O log confirma que o tráfego foi processado apenas pela ChildPolicy-Prod e caiu na regra DefaultDeny, ou seja, a regra da política pai nunca foi avaliada.
A informação irrelevante no cenário é a renovação do certificado TLS. Ela é plausível como suspeita inicial, mas o log mostra que o bloqueio ocorreu em uma regra de rede, antes mesmo de chegar à camada de aplicação onde TLS Inspection atuaria.
O principal erro de raciocínio dos distratores é focar na reinicialização do firewall (A), no certificado (C) ou na precedência de regras filha sobre pai (B). A alternativa B é o distrator mais perigoso: o engenheiro poderia gastar horas revisando prioridades de regras quando o problema é uma limitação de SKU que torna a hierarquia inoperante.
A consequência de agir com base em B seria reordenar regras em ambas as políticas sem efeito, enquanto o ambiente permanece bloqueado.
Gabarito — Cenário 2
Resposta: C
A ação correta é adicionar uma regra de negação de alta prioridade dentro da HubPolicy-Dev para eliminar o acesso irrestrito entre spokes, sem substituir a política associada, até que a janela de manutenção permita a troca controlada.
O contexto de restrição determinante é: ambiente em produção ativa, conexões estabelecidas e ausência de janela de manutenção por 6 horas. A troca imediata de política (A) é tecnicamente correta em termos de segurança, mas ignora a restrição crítica de impacto operacional. Trocar a política associada a um hub no Firewall Manager causa uma atualização de configuração que pode reiniciar conexões ativas e gerar interrupção.
A alternativa B é perigosa porque editar a HubPolicy-Dev para replicar a HubPolicy-Prod é trabalhoso, propenso a erros e torna as duas políticas redundantes, criando complexidade operacional desnecessária. A alternativa D representa paralisia decisória: uma regra AllowAll em produção é uma vulnerabilidade ativa que justifica ação imediata mesmo fora de janela.
A alternativa C equilibra mitigação de risco imediata com estabilidade operacional, que é o critério correto para decisões sem janela de manutenção disponível.
Gabarito — Cenário 3
Resposta: B
A causa raiz é a ausência do certificado raiz da CA interna no repositório de certificados confiáveis dos dispositivos do grupo afetado. Quando o Azure Firewall Premium realiza TLS Inspection, ele intercepta a conexão, decripta e reinspeciona o tráfego, então apresenta ao cliente um novo certificado emitido pela CA interna configurada no firewall. Se o dispositivo do cliente não confia nessa CA, a validação de certificado falha e a conexão é bloqueada.
O log confirma isso com precisão: TlsInspectionResult: CertificateValidationFailed. O fato de apenas o grupo com certificado raiz corporativo diferente ser afetado é a pista definitiva, pois os demais dispositivos já confiam na CA interna.
A informação irrelevante é a menção à atualização de SKU há três semanas. O SKU Premium estava funcionando normalmente antes da troca de política. O problema surgiu com a nova política que habilitou TLS Inspection, não com a atualização de SKU.
O distrator mais perigoso é D: a afirmação de que FQDNs da Microsoft não suportam inspeção TLS é parcialmente verdadeira em contextos específicos, o que torna o distrator convincente. De fato, a Microsoft recomenda configurar exclusões de TLS Inspection para serviços como Microsoft 365 por razões de compatibilidade e desempenho, mas isso não é uma limitação técnica absoluta do produto, e o log mostra claramente que a falha é de validação de certificado no cliente, não de incompatibilidade do serviço de destino.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 3 -> 1 -> 4 -> 2 -> 5.
O raciocínio de diagnóstico progressivo exige começar pela informação mais imediata e determinante antes de ir para análise de métricas e capacidade.
Passo 3 vem primeiro porque o alerta menciona 847 hits com ação Alert Only. Confirmar o modo de Threat Intelligence é o passo mais rápido e direciona todo o diagnóstico: se estiver em Alert Only, os hits não são a causa da lentidão, pois o tráfego não está sendo bloqueado.
Passo 1 vem em seguida para identificar se os IPs são legítimos ou maliciosos. Se forem legítimos, há um falso positivo em escala, o que muda o caminho de ação. Se forem maliciosos, o volume de tentativas pode indicar um ataque em andamento.
Passo 4 verifica mudanças recentes via Activity Log, o que pode explicar tanto o volume de hits quanto a lentidão, caso uma alteração de rota ou política tenha redirecionado tráfego de forma inesperada.
Passo 2 analisa métricas de throughput e conexões, que requerem contexto dos passos anteriores para serem interpretadas corretamente.
Passo 5 por último, porque escalonamento de SKU é uma decisão de capacidade que só faz sentido após excluir causas de configuração e tráfego anômalo.
A alternativa B é o distrator mais atraente porque começa pelas métricas, o que parece lógico diante de lentidão. Porém, iniciar pela análise de métricas sem saber o modo de Threat Intelligence leva o engenheiro a correlacionar lentidão e hits sem o contexto necessário para determinar se essa correlação é real.
Árvore de Troubleshooting: Azure Firewall Manager Policies
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz da árvore) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o comportamento observado é bloqueio inesperado ou lentidão sem bloqueio explícito. Siga as perguntas diagnósticas respondendo com o que você pode verificar diretamente nos logs, nas métricas ou no Activity Log, sem presumir a causa. Cada ramificação elimina uma hipótese ou confirma um caminho até que você chegue a um nó de causa identificada, a partir do qual a ação recomendada correspondente aponta o próximo passo concreto.