Laboratório de Troubleshooting: Seleção de SKU do Azure Firewall
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de segurança reporta que o Azure Firewall implantado na hub VNet não está filtrando tráfego com base em categorias de URL, como bloquear sites de jogos de azar ou redes sociais. O firewall está respondendo normalmente a regras de aplicação e rede, e os logs estão sendo enviados corretamente ao Log Analytics Workspace. A equipe menciona que o recurso foi provisionado há três semanas usando um template ARM existente na organização, originalmente criado para um ambiente de desenvolvimento. O endereço IP público está configurado como estático e a política de firewall está associada corretamente.
O gerente de segurança afirma que a filtragem por categoria de URL foi aprovada no design da solução e consta na documentação do projeto.
Qual é a causa raiz do problema?
A) A política de firewall está associada ao recurso errado e precisa ser revinculada à VNet correta.
B) O SKU implantado é o Standard, que não suporta filtragem por categoria de URL, recurso exclusivo do SKU Premium.
C) O Log Analytics Workspace não está configurado para receber logs de categoria de URL, impedindo o processamento das regras.
D) O endereço IP público estático impede a inspeção de tráfego criptografado necessária para categorização de URL.
Cenário 2 — Decisão de Ação
Uma empresa de serviços financeiros opera um ambiente Azure com Azure Firewall Standard em produção, protegendo cargas de trabalho críticas de processamento de pagamentos. Após um incidente de segurança investigado pelo time de resposta, identificou-se que o vetor de ataque explorou tráfego TLS criptografado que passou sem inspeção pelo firewall. A causa raiz foi formalmente documentada: o SKU Standard não realiza inspeção TLS.
O ambiente de produção atende 40.000 transações por hora. Qualquer interrupção deve ser comunicada ao regulador com antecedência mínima de 72 horas. A equipe tem uma janela de manutenção aprovada para daqui a 5 dias. Existe um ambiente de homologação idêntico disponível.
Qual é a ação correta a tomar neste momento?
A) Realizar o upgrade do SKU diretamente no recurso de firewall em produção, aproveitando que o Azure permite upgrade in-place sem downtime.
B) Provisionar um Azure Firewall Premium no ambiente de homologação, validar a configuração com inspeção TLS ativa e planejar a migração para a janela de manutenção aprovada.
C) Configurar uma política de inspeção TLS na instância Standard atual para mitigar o risco imediatamente enquanto a migração é planejada.
D) Substituir imediatamente o firewall em produção pelo SKU Premium, pois o risco regulatório de operar com a vulnerabilidade conhecida supera o risco de interrupção.
Cenário 3 — Causa Raiz
Um arquiteto de rede recebe um chamado relatando que o Azure Firewall está recusando conexões de saída para um serviço SaaS corporativo que utiliza um domínio com certificado autoassinado. O firewall está configurado com uma regra de aplicação permitindo o FQDN do serviço na porta 443. A regra existia antes do problema começar e não foi alterada. Os logs mostram a seguinte entrada:
Action: Deny
Rule Collection: App-RC-SaaS
Rule: Allow-SaaS-Portal
Protocol: HTTPS
TargetFqdns: saas-portal.contoso-partner.com
ThreatIntelMode: Alert
A equipe informa que o certificado do serviço SaaS foi renovado pelo fornecedor na semana anterior. Outros FQDNs na mesma regra de aplicação funcionam normalmente. O time de infraestrutura menciona que houve uma atualização de política de firewall dois dias antes do incidente.
Qual é a causa raiz do problema?
A) A atualização de política de firewall removeu acidentalmente a regra de aplicação que permitia o FQDN afetado.
B) O firewall está no SKU Premium com inspeção TLS ativa e está rejeitando o certificado autoassinado do serviço SaaS durante o handshake TLS.
C) O modo ThreatIntel configurado como Alert está bloqueando ativamente o IP de destino do serviço SaaS por reputação.
D) A regra de aplicação não cobre o protocolo correto e deve ser reconfigurada para incluir HTTP além de HTTPS.
Cenário 4 — Sequência de Diagnóstico
Um cliente relata que após migrar de Azure Firewall Standard para Premium, algumas aplicações internas pararam de funcionar corretamente. O sintoma observado é que conexões HTTPS para determinados backends internos são encerradas com erro de certificado no cliente. A equipe suspeita que a inspeção TLS introduzida no novo SKU seja a origem do problema, mas ainda não confirmou.
Os seguintes passos de investigação estão disponíveis:
- P: Verificar se a Intermediate CA configurada no firewall é confiável pelos clientes afetados
- Q: Revisar os logs de firewall para identificar quais conexões estão sendo bloqueadas ou terminadas
- R: Confirmar se a política de firewall tem inspeção TLS habilitada e quais regras de aplicação estão no escopo
- S: Verificar se os backends afetados possuem certificados válidos emitidos por uma CA pública ou privada confiável
- T: Comparar o comportamento entre clientes afetados e não afetados para isolar a variável determinante
Qual é a sequência correta de investigação?
A) R, Q, T, S, P
B) Q, R, S, P, T
C) T, R, Q, P, S
D) P, S, R, Q, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A filtragem por categoria de URL é uma funcionalidade exclusiva do Azure Firewall Premium. O SKU Standard suporta filtragem por FQDN, regras de rede e aplicação, mas não realiza categorização de URL com base em inteligência de ameaças enriquecida. O detalhe crítico no enunciado é que o template ARM era originalmente destinado a um ambiente de desenvolvimento, onde tipicamente o SKU Standard é usado por questões de custo. O fato de o firewall estar respondendo normalmente a outras regras confirma que o recurso está operacional, o que descarta falhas de configuração geral.
A informação sobre o Log Analytics Workspace é irrelevante para este diagnóstico: logs funcionando corretamente indicam conectividade e configuração adequada de diagnóstico, mas não têm relação com a capacidade do SKU de processar categorias de URL. O endereço IP público estático também não tem qualquer relação com a funcionalidade de categorização.
O distrator mais perigoso é a alternativa C, pois direciona o diagnóstico para a camada de observabilidade quando o problema está na camada de capacidade do produto. Atuar nessa hipótese levaria a horas de investigação no workspace sem resultado.
Gabarito — Cenário 2
Resposta: B
O cenário impõe duas restrições críticas que eliminam as demais alternativas: a exigência de notificação regulatória com 72 horas de antecedência e a existência de uma janela de manutenção aprovada em 5 dias. Qualquer ação que afete a produção antes da janela viola a restrição regulatória.
A alternativa A é tecnicamente incorreta: o Azure Firewall não suporta upgrade in-place entre SKUs Standard e Premium. Seria necessário provisionar um novo recurso. A alternativa C é tecnicamente impossível: o SKU Standard não possui suporte a inspeção TLS independentemente da política configurada. A alternativa D ignora deliberadamente a restrição regulatória documentada no cenário.
A ação correta é usar o ambiente de homologação para validar a nova configuração com inspeção TLS, identificar eventuais impactos nas aplicações e executar a migração na janela aprovada com comunicação adequada ao regulador.
Gabarito — Cenário 3
Resposta: B
O log exibido mostra uma negação em uma regra que estava previamente funcionando, afetando apenas um FQDN específico cujo certificado foi renovado. Quando o Azure Firewall Premium opera com inspeção TLS ativa, ele realiza um proxy TLS transparente: termina a conexão do cliente, inspeciona o conteúdo e abre uma nova conexão com o backend. Se o certificado do backend não for confiável pela cadeia de CAs configurada no firewall, a conexão é bloqueada.
O detalhe determinante é a combinação de dois eventos simultâneos: renovação do certificado pelo fornecedor e operação do firewall no SKU Premium. A renovação pode ter introduzido um certificado autoassinado ou emitido por uma CA não configurada como confiável no firewall.
A informação sobre a atualização de política dois dias antes é propositalmente irrelevante: outros FQDNs na mesma regra funcionam normalmente, o que elimina a hipótese de alteração acidental de regra. O modo ThreatIntel configurado como Alert não bloqueia tráfego, apenas registra alertas, o que torna a alternativa C incorreta. A alternativa D é implausível porque a regra já existia e cobria HTTPS corretamente antes do problema.
Gabarito — Cenário 4
Resposta: A
A sequência correta é R, Q, T, S, P, que segue a lógica de diagnóstico progressivo do mais abrangente para o mais específico.
O primeiro passo é confirmar se a inspeção TLS está realmente habilitada na política e quais regras estão no escopo (R), pois sem isso não é possível afirmar que a inspeção TLS é a causa. Em seguida, os logs revelam quais conexões específicas estão sendo afetadas e por qual motivo declarado (Q). Com as conexões identificadas, compara-se o comportamento entre clientes afetados e não afetados para isolar a variável determinante (T), como versão do cliente TLS ou cadeia de certificados aceita. Depois, verifica-se a validade e a cadeia de confiança dos certificados dos backends afetados (S). Por fim, confirma-se se a CA intermediária do firewall está na lista de confiança dos clientes (P), que é a causa mais provável de erro de certificado no cliente quando inspeção TLS está ativa.
A sequência B começa pelos logs antes de confirmar se a inspeção TLS está sequer ativa, o que pode levar a uma análise de logs sem contexto. A sequência D começa pelo passo mais específico antes de estabelecer o contexto geral, invertendo a lógica de eliminação progressiva.
Árvore de Troubleshooting: Seleção de SKU do Azure Firewall
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada da investigação |
| Azul | Pergunta diagnóstica, decisão baseada no que foi observado |
| Vermelho | Causa identificada, origem confirmada do problema |
| Verde | Ação recomendada ou resolução aplicável |
| Laranja | Validação ou verificação intermediária antes de agir |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando que o firewall não executa uma funcionalidade esperada. A primeira ramificação determina o SKU atual, pois muitas falhas de capacidade têm origem direta na escolha de SKU. A partir daí, siga as perguntas de diagnóstico respondendo apenas com o que foi observado ou verificado, sem pular etapas. Cada caminho termina em uma causa nomeada e uma ação específica, evitando correções aplicadas sem diagnóstico confirmado.