Pular para o conteúdo principal

Laboratório Técnico: Configure detection or prevention mode

Questões​

Questão 1 — Múltipla Escolha​

Um administrador precisa avaliar o impacto de novas regras de um Azure Application Gateway com WAF antes de colocá-las em produção. O ambiente está recebendo tráfego real e qualquer bloqueio indevido causaria impacto nos usuários. Qual modo de operação do WAF atende a esse requisito e qual é o comportamento esperado?

A) Modo Prevention, pois registra e bloqueia apenas o tráfego que viola as regras, sem afetar o restante
B) Modo Detection, pois monitora o tráfego e registra violações nos logs sem bloquear nenhuma requisição
C) Modo Detection, pois bloqueia requisições suspeitas e gera alertas para revisão posterior
D) Modo Prevention, pois encaminha o tráfego suspeito para quarentena sem interromper o fluxo principal

Questão 2 — Cenário Técnico​

Uma equipe configurou um Azure Front Door com WAF Policy e associou a política a um endpoint de produção. Após a implantação, o time de segurança relata que ataques de SQL Injection estão sendo detectados nos logs, mas nenhum deles está sendo bloqueado. O trecho abaixo representa a configuração atual da política:

{
  "policySettings": {
    "enabledState": "Enabled",
    "mode": "Detection",
    "redirectUrl": null,
    "customBlockResponseStatusCode": 403
  }
}

Qual é a causa direta do comportamento observado?

A) A propriedade customBlockResponseStatusCode está configurada incorretamente; o valor correto seria 200
B) A política WAF está no modo Detection, que registra as violações mas não executa ações de bloqueio
C) A política não está corretamente associada ao endpoint; o campo redirectUrl precisa ser preenchido
D) O WAF do Azure Front Door não suporta detecção de SQL Injection sem a adição manual de regras customizadas

Questão 3 — Verdadeiro ou Falso​

Quando uma WAF Policy associada a um Azure Application Gateway é alterada do modo Detection para o modo Prevention, todas as requisições que anteriormente apenas geravam logs passam a ser bloqueadas imediatamente, sem necessidade de reinicialização do gateway ou reconfiguração das regras existentes.

Questão 4 — Múltipla Escolha​

Considere dois ambientes com WAF configurados da seguinte forma:

AmbienteRecursoModoRegras Gerenciadas
ProdApplication GatewayPreventionOWASP 3.2 ativas
StagingApplication GatewayDetectionOWASP 3.2 ativas

Uma requisição com payload de Cross-Site Scripting (XSS) é enviada para ambos os ambientes simultaneamente. Qual é o comportamento esperado?

A) Ambos os ambientes bloqueiam a requisição, pois as regras OWASP 3.2 são idênticas
B) O ambiente Prod bloqueia e retorna erro 403; o ambiente Staging registra a violação nos logs e encaminha a requisição normalmente
C) O ambiente Staging bloqueia a requisição localmente e aguarda aprovação manual antes de encaminhar
D) Ambos registram a violação nos logs, mas apenas o ambiente Prod envia um alerta para o Microsoft Defender for Cloud

Questão 5 — Cenário Técnico​

Uma organização migrou seu WAF do modo Detection para o modo Prevention em um Azure Application Gateway. Dois dias após a mudança, a equipe de suporte reporta que um sistema de parceiro legado está recebendo erros 403 ao tentar consumir uma API protegida pelo gateway. O sistema parceiro não foi alterado. Os logs do WAF mostram o seguinte padrão:

RuleId: 942100
Action: Blocked
Message: SQL Injection Attack Detected via libinjection
RequestUri: /api/parceiro/consulta

Qual é a abordagem mais adequada para resolver o problema sem comprometer a postura de segurança dos demais endpoints?

A) Reverter o WAF para o modo Detection em toda a política para restaurar o funcionamento do parceiro
B) Criar uma exclusão de regra (rule exclusion) para a RuleId 942100 aplicada especificamente ao caminho /api/parceiro/consulta, preservando a proteção nos demais endpoints
C) Desativar completamente o conjunto de regras OWASP no Application Gateway e substituir por regras customizadas
D) Alterar o customBlockResponseStatusCode para 200 na política WAF para que o parceiro não receba erro de bloqueio

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O modo Detection é projetado exatamente para cenários de avaliação em ambientes com tráfego real. Ele inspeciona todas as requisições, registra as violações nos logs de diagnóstico e no Log Analytics, mas não executa qualquer ação de bloqueio. Isso permite que o administrador analise falsos positivos antes de ativar o modo Prevention.

A alternativa A inverte o comportamento dos modos: Prevention é quem bloqueia, não Detection. As alternativas C e D descrevem comportamentos que não existem na implementação do WAF do Azure: Detection nunca bloqueia, e Prevention não tem mecanismo de quarentena com encaminhamento paralelo. Escolher Prevention nesse cenário causaria bloqueios imediatos em produção, incluindo potenciais falsos positivos.

Gabarito — Questão 2​

Resposta: B

O campo "mode": "Detection" na configuração da WAF Policy é o determinante direto do comportamento. Independentemente de quais regras estejam ativas ou de como os demais campos estão configurados, uma política em modo Detection nunca executa ações de bloqueio: ela apenas avalia o tráfego e registra as correspondências de regras.

A alternativa A é um distrator plausível, mas o código de status 403 é válido e não interfere no modo de operação. A alternativa C é incorreta porque redirectUrl é opcional e relevante apenas para redirecionamentos personalizados, não para o funcionamento do bloqueio. A alternativa D é falsa: SQL Injection é coberto pelo conjunto de regras gerenciadas padrão (DRS/OWASP) sem necessidade de regras customizadas.

Gabarito — Questão 3​

Resposta: Verdadeiro

A transição entre os modos Detection e Prevention em uma WAF Policy do Application Gateway é uma alteração de configuração que entra em vigor imediatamente, sem reinicialização do gateway. As regras gerenciadas já estavam ativas e avaliando o tráfego em modo Detection; ao mudar para Prevention, o mecanismo de execução passa a aplicar a ação de bloqueio (Block) para as mesmas correspondências que antes apenas geravam logs.

Esse comportamento reforça a importância de analisar os logs detalhadamente durante o período em Detection antes de promover para Prevention, pois falsos positivos que eram invisíveis ao usuário final se tornam erros 403 imediatamente após a mudança.

Gabarito — Questão 4​

Resposta: B

O modo de operação do WAF é o único fator que diferencia o comportamento dos dois ambientes nesse cenário, já que as regras são idênticas. Em Prevention, a violação resulta em bloqueio com resposta de erro (tipicamente 403) antes que a requisição alcance o backend. Em Detection, a mesma violação é registrada nos logs, mas a requisição é encaminhada normalmente ao backend.

A alternativa A é o equívoco mais comum: muitos assumem que regras iguais produzem comportamentos iguais, ignorando que o modo determina a ação executada. A alternativa C descreve um fluxo de aprovação manual que não existe no WAF do Azure. A alternativa D confunde integração com Defender for Cloud com o comportamento intrínseco dos modos, que não interfere em notificações externas.

Gabarito — Questão 5​

Resposta: B

A solução correta para um falso positivo em um caminho específico é criar uma exclusão de regra direcionada, que remove a avaliação da RuleId 942100 apenas para as requisições correspondentes ao caminho /api/parceiro/consulta. Essa abordagem cirúrgica preserva a proteção ativa para todos os demais endpoints e regras.

A alternativa A resolve o sintoma revertendo toda a postura de segurança do ambiente, o que é tecnicamente incorreto em produção. A alternativa C é desproporcional e elimina a proteção gerenciada para todos os endpoints sem necessidade. A alternativa D é um equívoco importante: alterar o código de resposta para 200 não desativa o bloqueio; a requisição ainda seria barrada pelo WAF, apenas retornaria um status HTTP diferente ao cliente, o que não resolve o problema funcional do parceiro.