Laboratório de Troubleshooting: Map requirements to features and capabilities of Azure Firewall
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança implantou o Azure Firewall Premium em um hub de conectividade centralizado. O firewall está configurado com uma política de firewall hierárquica: uma política pai definida pela equipe de segurança corporativa e uma política filha gerenciada pela equipe de aplicação.
O ambiente possui os seguintes elementos:
- Política pai com regras de rede bloqueando tráfego entre spokes por padrão
- Política filha com uma regra de aplicação permitindo
*.storage.azure.comna porta 443 - IDPS habilitado no modo Alert and Deny
- Uma rota definida pelo usuário (UDR) no spoke apontando o next hop para o IP privado do firewall
- Threat Intelligence configurado no modo Alert Only
Os desenvolvedores relatam que chamadas HTTPS para minhaconta.blob.core.windows.net estão sendo bloqueadas, mesmo após a criação da regra de aplicação na política filha. Os logs do firewall mostram:
Action: Deny
Rule Collection: Default Deny
Rule: DeniedByDefault
Target FQDN: minhaconta.blob.core.windows.net
Protocol: HTTPS:443
Source: 10.1.2.5
O time de rede confirma que a UDR está corretamente aplicada e que o tráfego está chegando ao firewall. A assinatura do Azure tem 12 outros firewalls em produção, todos com SKU Standard.
Qual é a causa raiz do bloqueio observado?
A) O IDPS no modo Alert and Deny está interceptando e bloqueando o tráfego TLS antes da regra de aplicação ser avaliada.
B) A regra de aplicação na política filha está sendo sobrescrita pela política pai, porque regras de rede na política pai têm precedência sobre regras de aplicação na política filha.
C) A regra de aplicação usa *.storage.azure.com, mas o FQDN de destino pertence ao domínio core.windows.net, portanto o padrão não corresponde ao destino real.
D) O Threat Intelligence em modo Alert Only não bloqueia tráfego, mas registra um falso positivo que aparece no log como Deny.
Cenário 2 — Decisão de Ação
A causa raiz foi identificada: o Azure Firewall Standard de uma empresa precisa inspecionar o tráfego de saída de máquinas virtuais para a internet, mas a equipe de segurança exige que o firewall decodifique e inspecione o conteúdo de sessões TLS para detectar malware em downloads HTTPS.
O contexto operacional é o seguinte:
- O firewall atual é SKU Standard, implantado há 18 meses em produção
- Não há janela de manutenção disponível nas próximas 72 horas
- O ambiente usa uma política de firewall clássica, sem hierarquia
- A equipe de segurança aprovou formalmente o requisito e registrou o chamado
- Existe um certificado CA intermediário válido disponível no Azure Key Vault
Qual é a ação correta a tomar neste momento?
A) Habilitar a inspeção TLS diretamente na política de firewall atual, apontando para o certificado no Key Vault, sem alterar o SKU.
B) Fazer upgrade do firewall para o SKU Premium e habilitar a inspeção TLS na política, aproveitando a janela de oportunidade antes das 72 horas.
C) Documentar o requisito como pendente e aguardar a próxima janela de manutenção para realizar o upgrade para Premium e configurar a inspeção TLS.
D) Criar um segundo firewall com SKU Premium em paralelo, migrar gradualmente o tráfego e habilitar a inspeção TLS no novo recurso sem afetar o ambiente atual.
Cenário 3 — Causa Raiz
Uma organização usa o Azure Firewall para controlar o tráfego de saída de uma subnet de workloads para a internet. O firewall está configurado com as seguintes regras:
Regra de rede (prioridade 100):
Name: Allow-DNS
Source: 10.2.0.0/16
Destination: 8.8.8.8
Port: 53/UDP
Action: Allow
Regra de aplicação (prioridade 200):
Name: Allow-Updates
Source: 10.2.0.0/16
Target FQDNs: windowsupdate.microsoft.com, update.microsoft.com
Protocol: HTTPS:443
Action: Allow
Os servidores na subnet 10.2.1.0/24 não conseguem baixar atualizações do Windows. O time de operações verifica que a resolução DNS está funcionando corretamente: nslookup windowsupdate.microsoft.com retorna IPs válidos a partir das VMs. O ping para 8.8.8.8 também funciona. O Azure Monitor mostra que o firewall está saudável e processando tráfego normalmente. A subnet de workloads não tem NSG aplicado.
Firewall log:
Action: Deny
Rule: DeniedByDefault
Source IP: 10.2.1.15
Destination IP: 13.107.4.52
Destination Port: 443
Protocol: TCP
Qual é a causa raiz do bloqueio?
A) A regra de rede Allow-DNS está consumindo todo o processamento UDP do firewall, causando atraso no processamento das regras de aplicação para TCP.
B) As regras de aplicação exigem que o proxy DNS do firewall seja utilizado para resolução de FQDN. Como as VMs estão usando 8.8.8.8 diretamente via regra de rede, o firewall não consegue associar o IP de destino ao FQDN permitido.
C) A ausência de NSG na subnet impede que o tráfego TCP:443 seja roteado corretamente ao firewall.
D) A prioridade 200 da regra de aplicação é numericamente maior que 100 da regra de rede, fazendo com que a regra de rede seja sempre avaliada primeiro e bloqueie o tráfego HTTPS.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe a seguinte reclamação: aplicações em um spoke não conseguem alcançar um endpoint interno em outro spoke, mesmo que uma regra de rede no Azure Firewall permita explicitamente o tráfego entre os dois prefixos.
Os passos de investigação disponíveis são:
- Verificar nos logs do Azure Firewall se o tráfego está chegando ao firewall e qual regra está sendo aplicada
- Confirmar se a UDR no spoke de origem tem o next hop apontado para o IP privado do firewall
- Verificar se existe uma rota mais específica no effective routes da NIC da VM de origem que bypass o firewall
- Confirmar se o prefixo de destino do outro spoke está incluído no escopo da regra de rede permitida
- Verificar se o tráfego de retorno do spoke de destino também passa pelo firewall ou retorna por caminho direto
Qual sequência de investigação segue a lógica correta de diagnóstico progressivo?
A) 1 → 2 → 4 → 3 → 5
B) 2 → 3 → 1 → 4 → 5
C) 4 → 1 → 2 → 3 → 5
D) 3 → 2 → 4 → 1 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A regra de aplicação foi criada com o padrão *.storage.azure.com, mas o FQDN de destino real é minhaconta.blob.core.windows.net. Esses são domínios distintos: blob.core.windows.net é o endpoint público do Azure Blob Storage, não um subdomínio de storage.azure.com. O padrão wildcard *.storage.azure.com cobre FQDNs como minhaconta.storage.azure.com, que é o endpoint do Azure Data Lake Storage Gen1 ou de recursos expostos via Private Link com DNS customizado, não o endpoint padrão do Blob Storage. O log confirma isso ao mostrar que a negação vem da regra padrão, indicando que nenhuma regra de permissão correspondeu ao destino.
A informação sobre os 12 outros firewalls com SKU Standard é irrelevante e foi incluída para desviar a atenção. O IDPS e o Threat Intelligence também são distratores: o IDPS no modo Alert and Deny bloquearia após a regra ser correspondida, não antes de uma tentativa de correspondência, e o Threat Intelligence em modo Alert Only nunca bloqueia tráfego por definição.
O distrator mais perigoso é a alternativa B. Ela confunde a hierarquia de políticas com a ordem de avaliação entre tipos de regra. Regras de rede na política pai têm precedência sobre regras de rede na política filha, mas regras de aplicação e de rede são tipos distintos. Agir com base nesse distrator levaria o administrador a modificar a política pai sem resolver o problema real, potencialmente introduzindo permissões desnecessariamente amplas.
Gabarito — Cenário 2
Resposta: C
A inspeção TLS é uma funcionalidade exclusiva do Azure Firewall Premium. O firewall atual é SKU Standard e não suporta essa capacidade, independentemente de certificados disponíveis no Key Vault. A alternativa A é tecnicamente impossível: não existe opção de habilitar inspeção TLS em um firewall Standard.
A alternativa B representa a ação tecnicamente correta, mas ignora uma restrição crítica do cenário: não há janela de manutenção disponível nas próximas 72 horas. Um upgrade de SKU em produção sem janela de manutenção pode causar interrupção de tráfego e viola as práticas de gestão de mudanças. Agir com base na alternativa B seria a decisão mais perigosa do conjunto.
A alternativa D é uma abordagem válida em ambientes que exigem zero downtime, mas o cenário não descreve essa restrição como motivadora, e criar um segundo firewall sem janela de manutenção tampouco está autorizado pelo contexto.
A alternativa C é a ação correta dado o conjunto de restrições: o requisito está aprovado e documentado, mas a execução deve ocorrer na próxima janela de manutenção, respeitando o processo de mudança. Segurança e disponibilidade devem ser equilibradas, não tratadas de forma unilateral.
Gabarito — Cenário 3
Resposta: B
O Azure Firewall usa seu próprio proxy DNS interno para resolver FQDNs em regras de aplicação. Quando uma regra de aplicação especifica um FQDN como destino, o firewall precisa resolver esse FQDN para IPs no momento em que o tráfego chega, a fim de comparar o IP de destino do pacote com os IPs que o FQDN resolve. Se a VM está usando um servidor DNS externo diretamente (8.8.8.8 via regra de rede), o firewall não tem visibilidade sobre qual FQDN aquele IP de destino representa. O resultado é que o pacote TCP:443 chega ao firewall com destino 13.107.4.52, sem correspondência com nenhuma regra de aplicação, e cai na regra padrão de negação.
O log confirma exatamente esse comportamento: o pacote é negado por DeniedByDefault com destino em um IP puro, sem FQDN associado na avaliação.
A resolução DNS funcionando nas VMs é a informação irrelevante do cenário. O fato de o nslookup retornar resultados corretos significa apenas que as VMs conseguem resolver nomes, não que o firewall tem esse mapeamento em seu proxy DNS para fins de avaliação de regras.
O distrator mais perigoso é a alternativa D, que inverte a lógica de prioridade. Números menores representam maior prioridade no Azure Firewall: prioridade 100 é avaliada antes da 200. Atuar com base nessa alternativa levaria a reordenar regras sem efeito sobre o problema real.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 2 → 3 → 1 → 4 → 5, pois segue a lógica de validar o plano de dados antes de analisar logs e depois antes de validar a configuração da regra em si.
O passo 2 confirma se o tráfego está sendo direcionado ao firewall via UDR. Sem isso, qualquer investigação nos logs do firewall seria inconclusiva, pois o tráfego pode simplesmente nunca estar chegando lá. O passo 3 verifica se há uma rota mais específica que bypasse a UDR, o que é um problema comum em ambientes com peering direto entre spokes ou com rotas aprendidas via BGP. Somente após confirmar que o tráfego está chegando ao firewall faz sentido consultar os logs (passo 1) para saber qual regra está sendo aplicada. Com essa informação, verifica-se no passo 4 se o prefixo de destino está coberto pela regra. O passo 5, sobre o caminho de retorno, é o mais avançado e só faz sentido após todos os anteriores, pois assimetria de roteamento pode causar timeouts sem aparecer nos logs de saída do firewall.
A alternativa A começa pelos logs antes de confirmar que o tráfego chega ao firewall, o que pode levar a uma conclusão falsa de que a regra está correta enquanto o tráfego simplesmente não passa pelo firewall. A alternativa C começa pela regra, ignorando que o problema pode estar no roteamento. A alternativa D começa pela rota mais específica, saltando a validação da UDR primária, o que inverte a ordem natural de prioridade do diagnóstico.
Árvore de Troubleshooting: Azure Firewall
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| 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 que descreve o sintoma observado e responda cada pergunta com base no que você pode verificar diretamente no ambiente: logs do firewall, tabelas de rotas efetivas, configuração de políticas e modo de operação de funcionalidades como IDPS e Threat Intelligence. Cada ramificação elimina uma classe de causas e aprofunda o diagnóstico até chegar a uma causa identificada em vermelho ou a uma ação corretiva em verde. Não pule níveis: a ordem das perguntas reflete a dependência lógica entre as hipóteses.