Laboratório Técnico: Configure rule sets for WAF on Azure Front Door
Questões
Questão 1 — Múltipla Escolha
Uma equipe de segurança precisa garantir que o WAF no Azure Front Door utilize sempre as definições de ameaças mais recentes disponíveis para o ruleset gerenciado OWASP. Ao revisar a configuração atual, o arquiteto observa que a política está usando um ruleset com versão fixa. Qual abordagem atende ao requisito de manter as definições sempre atualizadas sem intervenção manual recorrente?
A) Atualizar manualmente o ruleset para a versão mais recente do OWASP CRS sempre que uma nova versão for publicada pela Microsoft
B) Substituir o ruleset OWASP por um ruleset do tipo Microsoft_DefaultRuleSet na versão com atualização automática habilitada
C) Habilitar o modo Prevention no WAF, pois esse modo aplica automaticamente as atualizações de ruleset sem necessidade de reconfiguração
D) Criar um script de automação via Azure Policy que recria a política de WAF mensalmente com a versão mais recente do ruleset
Questão 2 — Cenário Técnico
Um engenheiro está configurando uma política de WAF no Azure Front Door e precisa bloquear requisições que contenham um cabeçalho HTTP específico com valor suspeito, comportamento esse que não é coberto pelo ruleset gerenciado ativo. A configuração atual é:
Managed Ruleset: Microsoft_DefaultRuleSet 2.1
WAF Mode: Prevention
Custom Rules: none
Qual é a abordagem correta para implementar esse bloqueio?
A) Adicionar uma exclusão ao ruleset gerenciado para que ele avalie o cabeçalho HTTP em questão com regras adicionais
B) Criar uma Custom Rule com condição de correspondência no campo de cabeçalho HTTP e ação de Block
C) Alterar o ruleset gerenciado para o OWASP CRS 3.2, que possui cobertura nativa para cabeçalhos HTTP suspeitos
D) Configurar uma regra de origem no perfil do Front Door para rejeitar requisições com esse cabeçalho antes de chegarem ao WAF
Questão 3 — Múltipla Escolha
Ao configurar uma política de WAF no Azure Front Door, um arquiteto precisa desabilitar uma regra específica do ruleset gerenciado que está causando falsos positivos em uma rota crítica da aplicação, mas sem afetar o comportamento das demais rotas protegidas pelo mesmo perfil do Front Door. Qual recurso permite esse nível de granularidade?
A) Criar uma segunda política de WAF sem a regra problemática e associá-la ao perfil do Front Door em substituição à política atual
B) Usar exclusões de regra no nível da política de WAF para desabilitar a regra específica em todas as rotas do perfil
C) Associar políticas de WAF distintas a endpoints ou rotas diferentes dentro do mesmo perfil do Front Door
D) Configurar o modo Detection apenas para a regra problemática, mantendo as demais em modo Prevention
Questão 4 — Cenário Técnico
Uma organização opera o Azure Front Door com WAF em modo Prevention usando o ruleset Microsoft_DefaultRuleSet 2.1. A equipe de desenvolvimento reporta que uma API específica começa a receber erros HTTP 403 após uma atualização da aplicação. Os logs do WAF mostram o seguinte padrão:
RuleId: 942100
Action: Block
MatchVariable: RequestBody
MatchValue: SELECT * FROM users
A equipe confirma que a requisição é legítima e que o valor faz parte de um payload de busca textual enviado por usuários. Qual é a solução mais adequada e com menor impacto na postura de segurança?
A) Desabilitar completamente a regra 942100 na política de WAF para todas as requisições do perfil
B) Alterar o WAF para o modo Detection para que as requisições não sejam mais bloqueadas
C) Configurar uma exclusão na regra 942100 para o campo RequestBody apenas no caminho da API afetada
D) Criar uma Custom Rule com prioridade 1 que permita todas as requisições destinadas ao caminho da API
Questão 5 — Verdadeiro ou Falso
No Azure Front Door, uma política de WAF pode ter simultaneamente um ruleset gerenciado ativo e múltiplas Custom Rules configuradas, e as Custom Rules são sempre avaliadas antes das regras do ruleset gerenciado, independentemente da ação definida nas Custom Rules.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Microsoft_DefaultRuleSet está disponível em versões com suporte a atualização automática no Azure Front Door. Ao selecionar esse ruleset com a opção de atualização automática, a Microsoft aplica novas versões de forma gerenciada, eliminando a necessidade de intervenção manual. Esse comportamento é específico do Front Door e não está disponível da mesma forma no Application Gateway.
Os demais distratores representam equívocos comuns: o modo Prevention (opção C) controla o comportamento de bloqueio, não a atualização de rulesets. Scripts via Azure Policy (opção D) adicionam complexidade operacional desnecessária quando o recurso nativo já resolve o problema. A atualização manual (opção A) atende ao requisito funcionalmente, mas contradiz a exigência de eliminar intervenção manual recorrente.
Gabarito — Questão 2
Resposta: B
Custom Rules são o mecanismo correto para implementar lógica de bloqueio baseada em critérios específicos que o ruleset gerenciado não cobre. Elas permitem definir condições sobre qualquer componente da requisição HTTP, incluindo cabeçalhos, com ação de Block, Allow, Log ou Redirect.
Exclusões (opção A) servem para isentar partes da requisição da avaliação de regras existentes, não para adicionar novas regras de avaliação. Trocar o ruleset gerenciado (opção C) não resolve o problema porque nenhum ruleset gerenciado padrão trata de cabeçalhos customizados específicos da aplicação. Regras de origem no perfil do Front Door (opção D) não possuem capacidade de inspeção de conteúdo HTTP na camada 7 com a granularidade descrita.
Gabarito — Questão 3
Resposta: C
No Azure Front Door (perfil Standard ou Premium), é possível associar políticas de WAF distintas a diferentes rotas dentro do mesmo perfil, permitindo que cada rota tenha sua própria política com configurações independentes. Isso possibilita desabilitar uma regra problemática apenas na rota afetada sem impactar as demais.
Substituir a política inteira (opção A) resolveria o falso positivo, mas removeria a regra globalmente, afetando todas as rotas. Exclusões no nível da política (opção B) também se aplicam globalmente a todas as rotas associadas àquela política. O modo Detection por regra individual (opção D) não é um recurso disponível; o modo Detection é aplicado à política inteira, não a regras individuais.
Gabarito — Questão 4
Resposta: C
Configurar uma exclusão para a regra 942100 especificamente no campo RequestBody e restrita ao caminho da API afetada é a abordagem com menor impacto na postura de segurança. As exclusões no WAF do Front Door permitem definir o escopo exato (variável de correspondência, operador e seletor) para que apenas o contexto legítimo seja isentado da avaliação, mantendo a regra ativa para todos os demais cenários.
Desabilitar a regra completamente (opção A) remove a proteção contra SQL Injection para todas as requisições do perfil. Alterar para Detection (opção B) desativa o bloqueio de todos os ataques, não apenas o falso positivo. Criar uma Custom Rule de Allow com prioridade 1 (opção D) é excessivamente amplo e pode permitir requisições genuinamente maliciosas direcionadas ao mesmo caminho.
Gabarito — Questão 5
Resposta: Verdadeiro
No Azure Front Door, o motor de avaliação do WAF sempre processa as Custom Rules antes das regras do ruleset gerenciado. Essa ordem é fixa e independe do tipo de ação definida na Custom Rule (Block, Allow, Log ou Redirect). Essa característica é fundamental para o design de políticas: uma Custom Rule de Allow com prioridade adequada pode ser usada para isentar tráfego confiável antes que ele seja avaliado pelo ruleset gerenciado, evitando falsos positivos de forma controlada. Compreender essa ordem de avaliação é essencial para projetar políticas que combinem corretamente os dois mecanismos sem comportamentos inesperados.