Laboratório Técnico: Implement a WAF policy
Questões
Questão 1 — Múltipla Escolha
Uma equipe precisa proteger dois recursos distintos: um Azure Application Gateway que serve uma aplicação web interna e um Azure Front Door que distribui uma aplicação global para usuários externos. Ambos exigem políticas WAF independentes com regras customizadas diferentes. Qual afirmação descreve corretamente a relação entre WAF Policies e esses recursos?
A) Uma única WAF Policy pode ser associada simultaneamente a um Application Gateway e a um Front Door, desde que esteja no mesmo grupo de recursos
B) WAF Policies para Application Gateway e para Front Door são tipos distintos e não são intercambiáveis; cada recurso exige uma política do tipo correspondente
C) WAF Policies são globais por padrão e se aplicam automaticamente a todos os recursos de entrega de aplicação na assinatura
D) É possível usar a mesma WAF Policy em ambos os recursos, desde que o SKU do Application Gateway seja WAF_v2 e o Front Door seja do tier Premium
Questão 2 — Cenário Técnico
Um administrador criou uma WAF Policy para um Azure Application Gateway WAF_v2 e adicionou uma regra customizada com a seguinte configuração:
Nome: BlockBadBot
Prioridade: 10
Tipo de correspondência: RequestHeaders
Header: User-Agent
Operador: Contains
Valor: BadBot
Ação: Block
Após associar a política ao Application Gateway, o administrador percebe que requisições com o User-Agent BadBot/2.0 ainda estão chegando ao backend. O WAF está em modo Prevention. Qual é a causa mais provável?
A) Regras customizadas com ação Block não são suportadas no modo Prevention; elas funcionam apenas em modo Detection
B) A WAF Policy foi criada, mas não foi associada a um listener específico ou ao Application Gateway como um todo, permanecendo sem efeito
C) O operador Contains não é válido para correspondência em headers; o correto seria Equals
D) A prioridade 10 é reservada para regras gerenciadas OWASP e não pode ser usada por regras customizadas
Questão 3 — Múltipla Escolha
Ao implementar uma WAF Policy no Azure Front Door Premium, um arquiteto precisa proteger endpoints de diferentes clientes com conjuntos de regras distintos. Cada cliente possui seu próprio domínio personalizado associado ao Front Door. Qual é a granularidade de associação suportada pelo Azure Front Door ao vincular WAF Policies?
A) A WAF Policy é associada ao perfil do Front Door como um todo, aplicando-se igualmente a todos os domínios e rotas
B) A WAF Policy pode ser associada individualmente a cada security policy, que por sua vez é vinculada a domínios e rotas específicos dentro do perfil
C) A WAF Policy é associada diretamente ao origin group, filtrando o tráfego antes de ele ser enviado ao backend
D) Cada WAF Policy é associada a uma regra de roteamento (route rule), permitindo controle por caminho de URL, mas não por domínio
Questão 4 — Verdadeiro ou Falso
Em uma WAF Policy associada a um Azure Application Gateway, regras customizadas são sempre avaliadas antes das regras gerenciadas do conjunto OWASP, independentemente do valor de prioridade definido na regra customizada.
Questão 5 — Cenário Técnico
Uma empresa implementou uma WAF Policy no Azure Front Door Premium com o conjunto de regras gerenciadas DRS 2.0 ativo. Após a implantação, o time de desenvolvimento reporta que requisições legítimas de um parceiro estão sendo bloqueadas. A investigação dos logs revela:
RuleSetType: Microsoft_DefaultRuleSet
RuleSetVersion: 2.0
RuleId: 920300
Action: Block
Details: Request Missing an Accept Header
RequestUri: /api/v2/data
O parceiro confirmou que o sistema legado dele não envia o header Accept nas requisições. A empresa precisa resolver o bloqueio apenas para esse endpoint, sem desativar a regra globalmente. Qual é a abordagem correta?
A) Criar uma regra customizada com prioridade menor que todas as regras gerenciadas para permitir explicitamente o caminho /api/v2/data antes da avaliação do DRS
B) Configurar uma exclusão de regra (rule exclusion) na WAF Policy, limitando a exclusão da RuleId 920300 ao caminho de requisição /api/v2/data
C) Desativar o conjunto de regras DRS 2.0 e recriar manualmente todas as regras necessárias, omitindo apenas a 920300
D) Associar uma segunda WAF Policy sem o DRS 2.0 ao domínio do parceiro, mantendo a política original nos demais domínios
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
WAF Policies são criadas com um escopo de recurso específico: Regional (para Application Gateway e Azure CDN) ou Global (para Azure Front Door). Uma política criada para Application Gateway não pode ser associada ao Front Door e vice-versa, pois os tipos de recurso e os modelos de configuração são incompatíveis. Essa distinção é estrutural, não configurável.
A alternativa A é incorreta porque a restrição não é de grupo de recursos, mas de tipo de política. A alternativa C descreve um comportamento que não existe: WAF Policies nunca são aplicadas automaticamente. A alternativa D é o distrator mais perigoso, pois mistura SKUs corretos com uma premissa falsa: mesmo com os SKUs adequados, os tipos de política permanecem incompatíveis entre si.
Gabarito — Questão 2
Resposta: B
No Azure Application Gateway, criar uma WAF Policy e associá-la ao recurso são duas operações distintas. Uma política criada mas não associada a um listener ou ao gateway como um todo permanece inativa, sem avaliar nenhum tráfego, independentemente do modo configurado. Esse é um dos erros operacionais mais comuns na implementação de WAF Policies.
A alternativa A é tecnicamente incorreta: regras customizadas com ação Block funcionam plenamente em modo Prevention. A alternativa C é falsa: Contains é um operador válido e amplamente usado para correspondência em headers. A alternativa D é um distrator plausível, mas a prioridade em regras customizadas é um valor definido pelo usuário para ordenar a avaliação entre as próprias regras customizadas; não existe reserva de faixas para regras gerenciadas.
Gabarito — Questão 3
Resposta: B
No Azure Front Door Premium, a associação de WAF Policies é feita por meio de security policies. Uma security policy vincula uma WAF Policy a um conjunto específico de domínios e rotas dentro do perfil, permitindo que diferentes domínios de clientes recebam políticas distintas. Essa granularidade é o mecanismo correto para o cenário descrito.
A alternativa A descreve um modelo de associação global que não reflete a arquitetura atual do Front Door Premium. A alternativa C é incorreta: a associação ao origin group não existe como mecanismo de WAF; origin groups representam os backends, não os pontos de entrada do tráfego. A alternativa D é parcialmente plausível, mas a associação por rota sozinha não permite discriminar por domínio, que é o requisito central do cenário.
Gabarito — Questão 4
Resposta: Verdadeiro
A ordem de avaliação em uma WAF Policy do Application Gateway é determinística: regras customizadas são sempre avaliadas antes das regras gerenciadas, independentemente do valor de prioridade atribuído. O campo de prioridade nas regras customizadas define apenas a ordem de avaliação entre as próprias regras customizadas, não sua posição em relação ao conjunto gerenciado.
Essa característica é relevante porque permite que regras customizadas de Allow ou Block atuem como exceções ou bloqueios antecipados antes que o motor OWASP processe a requisição. Ignorar essa ordem pode levar a comportamentos inesperados, como uma regra de Allow customizada que jamais é alcançada porque o administrador assume que o OWASP avalia primeiro.
Gabarito — Questão 5
Resposta: B
A exclusão de regra (rule exclusion) é o mecanismo projetado exatamente para esse cenário: desabilitar a avaliação de uma regra gerenciada específica para um subconjunto de requisições, sem afetar o comportamento global da política. É possível escopar a exclusão por caminho de requisição, header, cookie ou parâmetro de query string, tornando a solução precisa e cirúrgica.
A alternativa A é um equívoco comum: regras customizadas de Allow avaliadas antes do DRS podem contornar as regras gerenciadas para aquele tráfego, mas essa abordagem é mais frágil, exige manutenção maior e não é o mecanismo recomendado para falsos positivos em regras gerenciadas. A alternativa C é desproporcional e elimina toda a proteção gerenciada. A alternativa D seria tecnicamente viável se o Front Door Premium suportasse a associação de políticas distintas por domínio, o que ele suporta, tornando essa alternativa plausível. Porém, ela é mais complexa e introduz sobrecarga operacional desnecessária quando a exclusão de regra resolve o problema de forma direta e mantida em uma única política.