Laboratório de Troubleshooting: Associate a WAF Policy
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de plataforma implantou um Azure Front Door Premium com três endpoints configurados para distribuir tráfego entre aplicações de diferentes unidades de negócio. Uma WAF Policy no modo Prevention foi criada com regras gerenciadas do conjunto Microsoft_DefaultRuleSet 2.1 e associada ao perfil do Front Door.
Após a implantação, o time de segurança confirma que o endpoint app-financeiro.contoso.com está sendo protegido corretamente pelo WAF. Porém, o time de QA reporta que tentativas de ataque simuladas contra app-rh.contoso.com e app-operacoes.contoso.com não estão sendo bloqueadas, e os logs do WAF não mostram nenhum registro de tráfego para esses dois endpoints.
O arquiteto responsável verifica a configuração e encontra o seguinte estado no portal:
WAF Policy: WafPolicy-FrontDoor-Prod
Mode: Prevention
Associated Resources:
- Endpoint: app-financeiro.contoso.com (Enabled)
- Endpoint: app-rh.contoso.com (Not configured)
- Endpoint: app-operacoes.contoso.com (Not configured)
Managed Rules:
Microsoft_DefaultRuleSet 2.1: Enabled
Custom Rules: None
O arquiteto também menciona que os três endpoints foram criados no mesmo perfil do Front Door Premium e que a política WAF foi configurada antes da criação dos endpoints de RH e operações. O SKU do Front Door é Premium, que é obrigatório para associação com WAF. A assinatura tem cota suficiente para WAF policies adicionais.
Qual é a causa raiz do problema?
A) A política WAF do Azure Front Door aplica proteção apenas ao primeiro endpoint configurado no perfil, exigindo criação de políticas separadas para cada endpoint adicional.
B) Os endpoints app-rh.contoso.com e app-operacoes.contoso.com não foram associados à política WAF após sua criação, portanto o tráfego destinado a eles não é inspecionado.
C) A política WAF foi criada antes dos endpoints de RH e operações, o que impede a associação retroativa com endpoints criados posteriormente no mesmo perfil.
D) O SKU Premium do Front Door suporta apenas uma associação de política WAF por perfil, exigindo que os três endpoints compartilhem três políticas distintas em vez de uma única.
Cenário 2 — Causa Raiz
Um engenheiro de rede recebeu a tarefa de associar uma WAF Policy existente a um Application Gateway v2 que foi recém-provisionado em uma nova subscription. A política WAF, chamada WafPolicy-AppGW-Corp, foi criada há seis meses na subscription de produção original e está sendo reutilizada para o novo ambiente.
O engenheiro tenta associar a política ao Application Gateway pelo portal e recebe o seguinte erro:
Error: The WAF policy 'WafPolicy-AppGW-Corp' cannot be associated with the
Application Gateway 'AppGW-NewSub-East'. Ensure the policy and the gateway
are in the same region and subscription.
Code: WafPolicyAssociationFailed
Target: /subscriptions/NEW-SUB-ID/resourceGroups/rg-appgw/providers/
Microsoft.Network/applicationGateways/AppGW-NewSub-East
O engenheiro verifica que o Application Gateway está na região East US e foi provisionado com SKU WAF_v2. A política WafPolicy-AppGW-Corp foi criada originalmente na região West Europe e está na subscription de produção original. A nova subscription está na mesma tenant do Microsoft Entra ID. O engenheiro confirma que tem permissão de Network Contributor em ambas as subscriptions.
Qual é a causa raiz do problema?
A) O papel Network Contributor não tem permissão suficiente para associar políticas WAF entre subscriptions, exigindo o papel Security Admin na subscription de origem.
B) A política WAF WafPolicy-AppGW-Corp está em uma subscription e região diferentes do Application Gateway de destino, e políticas WAF para Application Gateway não podem ser associadas entre subscriptions ou regiões.
C) A política WAF foi criada há seis meses e expirou o período de validade para novas associações, exigindo recriação da política na nova subscription.
D) O SKU WAF_v2 do Application Gateway requer que a política WAF seja criada com o tipo Regional, mas a política original foi criada como tipo Global, incompatível com a associação.
Cenário 3 — Decisão de Ação
O time de segurança de uma empresa identificou que um Application Gateway v2 em produção está operando com uma WAF Policy associada em nível de Gateway que foi criada há dois anos e usa o conjunto de regras OWASP CRS 3.0. Uma auditoria determinou que a política deve ser atualizada para OWASP CRS 3.2 e que dois dos cinco listeners do gateway precisam de configurações de exclusão distintas que não podem ser implementadas em uma política única de nível de Gateway.
A causa foi confirmada: a arquitetura atual não suporta os requisitos de granularidade por listener com uma única política de nível de Gateway. A solução exige a criação de políticas individuais associadas em nível de Listener para os dois listeners que precisam de exclusões específicas, mantendo a política de Gateway para os demais.
O ambiente está em produção ativa com SLA de 99,9%. A equipe tem uma janela de manutenção disponível em 72 horas. Nenhuma mudança de configuração em produção é permitida fora de janelas aprovadas, conforme política interna.
Qual é a ação correta a tomar neste momento?
A) Criar as duas políticas de nível de Listener com OWASP CRS 3.2 e as exclusões necessárias, associá-las aos listeners correspondentes e atualizar a política de Gateway agora, aproveitando que a janela de manutenção está próxima e o impacto é mínimo.
B) Atualizar a política de Gateway existente de CRS 3.0 para CRS 3.2 imediatamente, sem alterar a estrutura de associação, e aguardar a janela de manutenção para criar e associar as políticas de nível de Listener.
C) Preparar as duas novas políticas de nível de Listener com OWASP CRS 3.2 e as exclusões necessárias, atualizar a política de Gateway para CRS 3.2, e executar todas as associações durante a janela de manutenção em 72 horas.
D) Criar as duas políticas de nível de Listener em modo Detection, associá-las aos listeners agora fora da janela de manutenção para validar as exclusões com tráfego real, e migrar para Prevention durante a janela de manutenção.
Cenário 4 — Impacto Colateral
Um administrador identificou que um Azure Front Door Premium estava utilizando uma WAF Policy compartilhada entre cinco endpoints de diferentes aplicações. Para atender a um requisito de isolamento de segurança, o administrador criou políticas WAF individuais para cada endpoint e as associou corretamente, desassociando em seguida a política compartilhada de todos os cinco endpoints.
O resultado imediato foi confirmado: cada endpoint passou a usar sua política dedicada, e os logs do WAF mostram que o tráfego está sendo inspecionado corretamente por cada política individual.
Qual consequência secundária essa ação pode causar?
A) A desassociação da política compartilhada dos cinco endpoints causa exclusão automática da política WAF original, removendo o histórico de logs associado a ela.
B) As cinco novas políticas WAF individuais geram um volume cinco vezes maior de dados de log no Log Analytics Workspace vinculado, podendo impactar os custos de ingestão e retenção de logs dependendo da configuração do workspace.
C) Endpoints do Azure Front Door Premium sem política WAF associada durante o intervalo entre desassociação e associação da nova política ficam temporariamente sem inspeção, expondo o tráfego nesse período.
D) A criação de cinco políticas WAF individuais no lugar de uma política compartilhada ultrapassa o limite de políticas WAF por assinatura no Azure Front Door Premium, causando falha silenciosa nas políticas criadas por último.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A causa raiz é que os endpoints app-rh.contoso.com e app-operacoes.contoso.com simplesmente não foram associados à política WAF. No Azure Front Door Premium, a associação entre uma WAF Policy e um endpoint é explícita e individual. A criação de um endpoint no perfil não gera associação automática com políticas WAF existentes, independentemente de quantos outros endpoints do mesmo perfil já estejam associados.
A pista definitiva está no próprio output de configuração fornecido no enunciado: os dois endpoints aparecem com status Not configured na seção de recursos associados da política. Não há ambiguidade possível: a política existe, o SKU é compatível, e os endpoints existem no perfil. A ausência de registros de log para esses endpoints confirma que o tráfego não está sendo inspecionado.
A informação irrelevante é a menção à cota de WAF policies adicionais na assinatura. Esse detalhe poderia sugerir que a solução exige criação de novas políticas, mas o problema é apenas de associação, não de quantidade de políticas disponíveis.
O principal erro de raciocínio dos distratores é assumir limitações técnicas que não existem: A inventa uma restrição de "primeiro endpoint apenas", C inventa uma restrição de criação sequencial, e D inventa uma restrição de uma política por perfil. O distrator mais perigoso é D, porque levaria o engenheiro a criar políticas adicionais desnecessárias, aumentando complexidade operacional e custo, sem resolver o problema real que é apenas uma associação ausente.
Gabarito — Cenário 2
Resposta: B
A causa raiz é uma restrição fundamental de escopo das políticas WAF para Application Gateway: elas são recursos regionais e devem estar na mesma região e na mesma subscription do Application Gateway ao qual serão associadas. O erro retornado pelo portal confirma isso textualmente. A política WafPolicy-AppGW-Corp está na região West Europe e na subscription original, enquanto o Application Gateway está na região East US e em uma subscription diferente.
A pista mais objetiva é o próprio bloco de erro, que declara explicitamente: "Ensure the policy and the gateway are in the same region and subscription." Não há interpretação necessária, o sistema já identificou e descreveu a causa.
A informação irrelevante é a menção à mesma tenant do Microsoft Entra ID. Compartilhar uma tenant não cria nenhuma ponte de compatibilidade entre recursos em subscriptions diferentes para fins de associação de WAF Policy. A tenant é irrelevante para esse tipo de restrição de escopo de recurso.
O distrator mais perigoso é A, porque o papel Network Contributor e suas permissões são um vetor de diagnóstico natural quando há falha de associação entre recursos em subscriptions diferentes. Um engenheiro menos experiente poderia solicitar elevação de permissões, tentativas com roles mais amplos como Owner, e abrir chamados de suporte sobre permissões antes de perceber que o problema é de escopo geográfico e de subscription, não de autorização.
Gabarito — Cenário 3
Resposta: C
A ação correta é preparar todas as políticas e atualizações antecipadamente e executar todas as mudanças durante a janela de manutenção em 72 horas. Isso respeita a restrição crítica do cenário: nenhuma mudança de configuração em produção fora de janelas aprovadas.
A alternativa A viola diretamente a política interna ao executar mudanças fora da janela, mesmo argumentando que o impacto é mínimo. Em ambientes com SLA de 99,9%, a justificativa de impacto mínimo não substitui a conformidade com processos aprovados. A alternativa B realiza apenas parte do trabalho fora da janela, o que também viola a política interna e deixa o ambiente em estado intermediário inconsistente, com CRS 3.2 na política de Gateway mas sem as políticas de Listener criadas.
A alternativa D é tecnicamente interessante como abordagem de validação, mas também viola a política interna ao realizar associações fora da janela, ainda que em modo Detection. O modo Detection não isenta a ação da restrição de mudança em produção.
O ponto crítico que diferencia C das demais é que preparar as políticas sem associá-las não constitui uma mudança de produção: recursos podem ser criados em paralelo sem impacto. A execução das associações e da atualização da política de Gateway é o que deve ocorrer na janela. Essa distinção entre preparação e ativação é fundamental em ambientes com controle de mudanças formal.
Gabarito — Cenário 4
Resposta: C
O impacto colateral real é a janela de exposição gerada pelo intervalo entre a desassociação da política compartilhada e a conclusão da associação das políticas individuais. No Azure Front Door Premium, um endpoint sem política WAF associada recebe tráfego sem inspeção. Se a desassociação da política compartilhada e a associação das políticas individuais não forem operações atômicas ou simultâneas, há um período em que um ou mais endpoints ficam desprotegidos.
A alternativa A é falsa: desassociar uma política WAF de recursos não causa sua exclusão. Políticas WAF são recursos independentes que persistem mesmo sem associações ativas.
A alternativa B é tecnicamente plausível como preocupação de custo em ambientes com alto volume de tráfego, mas não é uma consequência direta e imediata da ação descrita. Além disso, o enunciado confirma que o tráfego já estava sendo logado pela política compartilhada, portanto o volume de eventos no Log Analytics não aumentaria de forma proporcional ao número de políticas, apenas seria distribuído entre elas.
A alternativa D inventa uma limitação que não existe para esse cenário. O limite de políticas WAF por assinatura no Azure é alto o suficiente para que cinco políticas não representem risco de quota em um único Front Door, e o produto não causa falha silenciosa em políticas criadas além de um número arbitrário.
A consequência prática deste cenário é que operações de migração de política WAF devem ser planejadas para minimizar ou eliminar o intervalo de desassociação, idealmente associando as novas políticas antes de remover a política existente, quando a arquitetura permitir sobreposição temporária.
Árvore de Troubleshooting: Associate a WAF Policy
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 problema se manifesta como um erro durante a tentativa de associação ou como tráfego que chega ao recurso sem inspeção do WAF. Esses dois caminhos iniciais separam problemas de compatibilidade e escopo de recurso dos problemas de cobertura de associação. Siga cada pergunta respondendo apenas com o que é verificável diretamente no portal ou nos logs de diagnóstico, sem presumir a causa, até alcançar um nó de causa identificada com a ação correspondente.