Laboratório de Troubleshooting: Configure Azure Firewall Rules
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações configurou regras no Azure Firewall para permitir que VMs na sub-rede 10.20.1.0/24 acessem um serviço SaaS externo via HTTPS. O administrador criou a seguinte regra de aplicação:
Firewall Policy: policy-prod
Rule Collection: Allow-SaaS-Access
Tipo: Application
Prioridade: 200
Acao: Allow
Regra:
Nome: Allow-SaaS-HTTPS
Origem: 10.20.1.0/24
Protocolo: Https:443
FQDN de destino: *.salesforce.com
Após a configuração, as VMs continuam sem conseguir acessar login.salesforce.com. O administrador verifica os logs e encontra:
Category: AzureFirewallApplicationRule
Action: Deny
Rule: Default Deny
RuleCollection: Default
SourceIP: 10.20.1.4
TargetUrl: login.salesforce.com
Protocol: Http:80
Informações adicionais:
- O navegador das VMs está configurado para redirecionar HTTP para HTTPS automaticamente
- A UDR da sub-rede aponta corretamente para o IP privado do firewall
- A Firewall Policy está associada ao firewall correto
- O workspace do Log Analytics foi provisionado há 30 dias
Qual é a causa raiz do problema observado?
A. O FQDN *.salesforce.com é um wildcard e o Azure Firewall não suporta curingas em regras de aplicação, portanto a regra está sendo ignorada.
B. O log mostra que o tráfego bloqueado usa o protocolo HTTP na porta 80, e a regra criada cobre apenas HTTPS na porta 443, deixando o tráfego HTTP sem cobertura.
C. A prioridade 200 da coleção de regras é muito alta e uma coleção com prioridade mais baixa, avaliada antes, está negando o tráfego.
D. O Log Analytics Workspace provisionado há 30 dias está com retenção expirada e os logs exibidos são de uma captura anterior, não do tráfego atual.
Cenário 2 — Decisão de Ação
A equipe de segurança identificou que uma regra de rede no Azure Firewall está permitindo tráfego TCP na porta 3389 a partir de 0.0.0.0/0 para toda a sub-rede 10.10.0.0/24. A regra foi criada há seis meses durante um período de testes e nunca foi removida. O ambiente é de produção ativa, com VMs críticas na sub-rede afetada.
A causa está identificada: a regra de permissão de RDP exposta para a internet deve ser removida. O contexto adicional é:
- O time de operações acessa as VMs exclusivamente via Azure Bastion, que está implantado e funcional
- A política de Change Management exige aprovação formal para alterações em regras de firewall de produção
- O CISO da organização foi notificado do risco e está acompanhando o incidente
- Não há nenhuma janela de manutenção programada para as próximas 72 horas
Qual é a ação correta a tomar neste momento?
A. Remover imediatamente a regra de RDP sem aguardar aprovação, documentando a ação após a remoção, pois o risco de segurança justifica a exceção ao processo.
B. Solicitar aprovação emergencial ao Change Management para remoção da regra, apresentando o risco identificado pelo CISO como justificativa para tramitação urgente.
C. Criar uma regra de negação explícita com prioridade mais alta que a regra de RDP existente para bloquear o tráfego imediatamente, sem remover a regra original.
D. Aguardar a próxima janela de manutenção programada para remover a regra, pois qualquer alteração fora de janela viola a política de Change Management.
Cenário 3 — Causa Raiz
Uma empresa configurou regras de rede e de aplicação no Azure Firewall para controlar o tráfego de saída de suas VMs. O time de desenvolvimento reporta que tentativas de conexão com um servidor de banco de dados externo na porta 1433 estão sendo bloqueadas, mesmo após o administrador afirmar que criou uma regra de rede permitindo esse tráfego.
O administrador apresenta a configuração atual da Firewall Policy:
Rule Collection Group: RCG-Prod (prioridade 100)
Rule Collection: Allow-Internet-Apps (Application, prioridade 100, Allow)
Regra: Allow-Web
Origem: 10.0.0.0/8
Protocolo: Http:80, Https:443
FQDN: *
Rule Collection: Allow-DB-Outbound (Network, prioridade 200, Allow)
Regra: Allow-SQL
Origem: 10.30.1.0/24
Destino: 203.0.113.50
Protocolo: TCP
Porta: 1433
Rule Collection: Deny-All-Outbound (Network, prioridade 300, Deny)
Regra: Block-All
Origem: *
Destino: *
Protocolo: Any
Porta: *
Os logs mostram que o tráfego TCP porta 1433 de 10.30.1.8 para 203.0.113.50 está sendo negado pela regra Block-All da coleção Deny-All-Outbound.
Informações adicionais:
- A VM
10.30.1.8foi migrada para a sub-rede10.30.1.0/24há dois dias - O certificado TLS da Firewall Policy foi renovado na semana passada
- A regra
Allow-SQLtem prioridade 200 e a regraBlock-Alltem prioridade 300
Qual é a causa raiz do problema observado?
A. A renovação do certificado TLS da Firewall Policy na semana passada causou uma reinicialização interna das regras, e a regra Allow-SQL foi desativada temporariamente.
B. No Azure Firewall, regras de aplicação são sempre avaliadas antes de regras de rede, independentemente da prioridade configurada. A regra Allow-Web de aplicação está interceptando e negando o tráfego na porta 1433 antes que a regra de rede Allow-SQL seja avaliada.
C. A prioridade numérica das coleções é avaliada em ordem crescente dentro do mesmo tipo de regra. Como Allow-SQL tem prioridade 200 e Deny-All-Outbound tem prioridade 300, a regra de permissão deveria ser avaliada primeiro. O problema está em um conflito de origem na regra Allow-SQL.
D. No Azure Firewall, regras de rede são sempre avaliadas antes de regras de aplicação. A coleção Deny-All-Outbound de rede com prioridade 300 é avaliada depois de Allow-DB-Outbound com prioridade 200, portanto a regra Allow-SQL deveria estar funcionando. O problema está na configuração do IP de destino.
Cenário 4 — Impacto Colateral
Para simplificar o gerenciamento de regras, um administrador decide consolidar todas as regras de rede do Azure Firewall em uma única coleção de regras chamada Allow-All-Internal com ação Allow e prioridade 100, removendo as coleções anteriores mais granulares. O resultado imediato é que toda a conectividade interna entre VNets passa a funcionar sem bloqueios.
Qual consequência secundária essa ação pode causar?
A. O Azure Firewall passará a negar todo o tráfego de saída para a internet porque a remoção das coleções anteriores eliminou as regras NAT que realizavam o SNAT do tráfego de saída.
B. Tráfego que antes era bloqueado intencionalmente por regras granulares, como acesso a portas administrativas ou entre segmentos de rede que não deveriam se comunicar, passa a ser permitido, eliminando controles de segmentação que existiam por política.
C. As regras de aplicação existentes na Firewall Policy deixam de ser avaliadas porque regras de rede com ação Allow e prioridade 100 têm precedência absoluta sobre qualquer regra de aplicação.
D. O Azure Firewall entra em modo degradado quando uma única coleção de regras de rede contém mais de 50 regras, causando latência adicional e eventual descarte de pacotes.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log é a pista definitiva: o tráfego bloqueado usa Protocol: Http:80, não HTTPS. O que está acontecendo é que o navegador das VMs tenta primeiro uma conexão HTTP na porta 80 antes de ser redirecionado para HTTPS. Essa requisição HTTP inicial chega ao firewall, não é coberta pela regra Allow-SaaS-HTTPS que especifica apenas Https:443, e é negada pela política padrão de negação implícita.
O wildcard *.salesforce.com é perfeitamente suportado em regras de aplicação do Azure Firewall, o que descarta a alternativa A. A prioridade 200 não indica necessariamente que outra coleção tem prioridade mais alta, e os logs mostram explicitamente Rule: Default Deny, não uma regra customizada, o que descarta a alternativa C. A retenção do Log Analytics não afeta a exibição de logs recentes nem o comportamento do firewall, descartando a alternativa D.
O distrator mais perigoso é o A, pois leva o administrador a acreditar que precisa reescrever a regra com um FQDN diferente, quando a solução real é simplesmente adicionar Http:80 ao protocolo da regra existente ou criar uma regra adicional para HTTP.
Gabarito — Cenário 2
Resposta: B
A ação correta é solicitar aprovação emergencial ao Change Management. Essa abordagem respeita o processo estabelecido enquanto comunica adequadamente a urgência do risco. O CISO já foi notificado, o que fornece respaldo executivo para uma tramitação acelerada. O time de operações não depende da porta 3389 para acesso às VMs, pois utiliza exclusivamente o Azure Bastion, o que significa que a remoção da regra não causará impacto operacional.
A alternativa A ignora o processo de Change Management sem justificativa suficiente, pois existe um caminho formal de aprovação emergencial disponível. A alternativa C é tecnicamente válida como medida imediata de mitigação, mas deixa a regra original no firewall, criando desordem na política e risco de reversão acidental. A alternativa D ignora completamente o risco de segurança identificado e notificado ao CISO, sendo inaceitável diante de uma exposição ativa.
O ponto central é que processos de Change Management geralmente possuem mecanismos de aprovação emergencial exatamente para situações como essa, e utilizá-los é a resposta profissionalmente correta.
Gabarito — Cenário 3
Resposta: B
No Azure Firewall, a ordem de avaliação entre tipos de regra é fixa e independe da prioridade configurada nas coleções: regras NAT são avaliadas primeiro, depois regras de rede, e por último regras de aplicação. No entanto, existe uma exceção crítica: regras de aplicação são avaliadas antes de regras de rede para tráfego HTTP e HTTPS. Nesse cenário, a coleção de aplicação Allow-Internet-Apps com a regra Allow-Web cobre o protocolo Http:80 e Https:443 com FQDN * e origem 10.0.0.0/8, que inclui 10.30.1.8. O tráfego TCP porta 1433, porém, não é HTTP nem HTTPS, então essa explicação não se aplica diretamente.
A causa real é que dentro da avaliação de regras de rede, a prioridade é avaliada em ordem crescente: menor número = maior prioridade. Allow-DB-Outbound tem prioridade 200 e Deny-All-Outbound tem prioridade 300. A regra Allow-SQL deveria ser avaliada antes de Block-All. O problema está no fato de que a alternativa B descreve o comportamento correto do mecanismo: regras de aplicação têm precedência sobre regras de rede para tráfego web, mas para porta 1433 o mecanismo de avaliação é puramente de rede, e Allow-SQL com prioridade 200 deveria prevalecer sobre Block-All com prioridade 300.
Informação irrelevante: A renovação do certificado TLS não afeta a avaliação de regras de rede e não desativa regras existentes.
A alternativa mais perigosa é a D, que leva o administrador a modificar o IP de destino da regra Allow-SQL quando o problema real está na lógica de avaliação entre tipos de regra, fazendo com que o troubleshooting se aprofunde na direção errada.
Gabarito — Cenário 4
Resposta: B
O impacto colateral real e relevante é a eliminação de controles de segmentação intencionais. Quando as coleções granulares existiam, elas implementavam o princípio de menor privilégio: apenas os fluxos necessários eram permitidos, e tudo o mais era negado implicitamente. Ao substituir tudo por uma única regra Allow abrangente, o administrador eliminou barreiras que impediam comunicação entre segmentos que não deveriam se falar, como VMs de desenvolvimento acessando recursos de produção, ou servidores web acessando diretamente bancos de dados sem passar por uma camada de aplicação.
A alternativa A é falsa: o SNAT de saída no Azure Firewall é uma função do serviço que não depende de regras de rede específicas para funcionar. A alternativa C é falsa: regras de rede e de aplicação coexistem e são avaliadas de forma independente; uma regra de rede Allow não desativa a avaliação de regras de aplicação. A alternativa D é falsa: o Azure Firewall não possui esse limite de degradação por quantidade de regras em uma coleção.
O impacto descrito na alternativa B é o mais silencioso e perigoso, pois a conectividade funciona e nenhum alerta é disparado, mas a postura de segurança da rede foi comprometida de forma invisível.
Árvore de Troubleshooting: Configure Azure Firewall Rules
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 ponto de partida obrigatório é confirmar que o tráfego está chegando ao firewall via UDR, pois sem isso qualquer investigação nas regras é inútil. Em seguida, consulte os logs para identificar qual regra foi aplicada e qual protocolo foi registrado: essa informação define o caminho a seguir. Se o tráfego está sendo negado, verifique se o protocolo e a porta no log coincidem com a regra criada e se existe uma coleção de maior prioridade sobrepondo a regra de permissão. Se o tráfego está sendo permitido indevidamente, verifique sobreposição de coleções e a presença de regras granulares que possam ter sido eliminadas.