Laboratório de Troubleshooting: Identify appropriate use cases for Azure Application Gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe reporta que, após migrar uma aplicação para o Azure, requisições de clientes externos estão retornando HTTP 502 Bad Gateway de forma intermitente. O problema ocorre para aproximadamente 30% das requisições ao longo do dia.
O ambiente está configurado da seguinte forma:
Application Gateway (SKU Standard_v2)
|-- Backend Pool: 4 VMs rodando IIS (porta 80)
|-- Health Probe: HTTP, path "/", porta 80, intervalo 30s, threshold 3
|-- Listener: HTTP, porta 80
|-- NSG na subnet do Application Gateway: sem restrições de entrada
A equipe investigou e coletou as seguintes informações adicionais:
- Os logs do IIS nas VMs mostram que, quando as requisições chegam, elas são respondidas com HTTP 200
- A subnet das VMs possui um NSG com a seguinte regra de entrada configurada manualmente:
Priority Name Port Source Action
100 AllowHTTPFromLB 80 168.63.129.16 Allow
200 DenyAll * * Deny
- O Application Gateway está na versão mais recente do firmware
- O time de segurança aprovou a topologia de rede há duas semanas
- A SKU Standard_v2 foi escolhida por suportar autoscaling
Qual é a causa raiz do erro 502 intermitente?
A. O intervalo de 30 segundos do health probe é muito longo, fazendo com que VMs que ficam temporariamente lentas sejam mantidas no pool ativo quando já não respondem corretamente
B. O NSG na subnet das VMs está bloqueando os health probes do Application Gateway, pois eles se originam de um range de IPs diferente do 168.63.129.16
C. A SKU Standard_v2 requer que o health probe use HTTPS, e a configuração atual usando HTTP faz com que o probe retorne falso positivo de saúde
D. O threshold de 3 falhas consecutivas no health probe é insuficiente para detectar instabilidade, fazendo com que VMs com falha intermitente permaneçam ativas no pool
Cenário 2 — Decisão de Ação
A equipe de operações identificou que o WAF do Azure Application Gateway está em modo Detection em um ambiente de produção que processa transações financeiras. Após análise dos logs, confirmou-se que ataques reais de SQL injection estão sendo registrados nos logs do WAF, mas não estão sendo bloqueados.
O contexto operacional é o seguinte:
- A aplicação tem um SLA de 99,9% e qualquer indisponibilidade exige abertura de incidente crítico
- O time de desenvolvimento identificou que dois endpoints legados da aplicação geram falsos positivos nas regras do WAF, mas os endpoints são pouco utilizados (menos de 1% do tráfego)
- Existe uma janela de manutenção programada para 72 horas a partir de agora
- A equipe tem permissão para criar exclusões de regras no WAF
- Mudar o SKU do Application Gateway não está autorizado neste momento
Qual é a ação correta a tomar agora?
A. Aguardar a janela de manutenção para alterar o WAF para modo Prevention, pois mudanças em produção fora de janela violam o processo de mudança
B. Criar exclusões de regra para os dois endpoints legados imediatamente e, em seguida, alterar o WAF para modo Prevention sem aguardar a janela, dado o risco ativo de ataque
C. Alterar o WAF para modo Prevention imediatamente, sem criar exclusões, aceitando que os falsos positivos nos endpoints legados gerarão bloqueios enquanto as exclusões são preparadas
D. Escalar para o time de segurança e aguardar aprovação formal antes de qualquer mudança, pois o WAF envolve política de segurança corporativa
Cenário 3 — Causa Raiz
Um arquiteto configurou um Application Gateway para rotear tráfego entre dois ambientes: produção e homologação. A intenção era separar o tráfego pelo caminho da URL:
app.contoso.com/prod/* --> Backend Pool: VMs de producao
app.contoso.com/hml/* --> Backend Pool: VMs de homologacao
Após o deploy, o time de QA reporta que todas as requisições enviadas para /hml/api/test estão sendo respondidas pelas VMs de produção, não pelas de homologação. Requisições para /prod/ funcionam corretamente.
A configuração atual das regras no Application Gateway é a seguinte:
Regra 1 (Priority 100): PathBasedRouting
Path: /prod/* --> BackendPool-Producao
Regra 2 (Priority 200): PathBasedRouting
Path: /hml/* --> BackendPool-Homologacao
Default Rule: BasicRouting
--> BackendPool-Producao
O time verificou que:
- As VMs de homologação estão saudáveis e respondendo na porta 80
- O health probe retorna HTTP 200 para todos os backends
- O certificado SSL do listener foi renovado na semana anterior e está válido
- O DNS de
app.contoso.comaponta corretamente para o IP público do Application Gateway
Qual é a causa raiz do problema?
A. O health probe está configurado para HTTP enquanto as VMs de homologação utilizam HTTPS, causando falso positivo de saúde e remoção silenciosa do pool ativo
B. As requisições para /hml/api/test não correspondem ao path /hml/* devido a um problema de sensibilidade a maiúsculas e minúsculas nas regras de roteamento
C. A configuração de path /hml/* está correta, mas a Default Rule redireciona requisições que chegam antes que a regra de prioridade 200 seja avaliada, pois o processamento das regras não é sequencial neste cenário
D. O path configurado como /hml/* não corresponde a URLs que contêm subdiretórios após o prefixo, pois o wildcard * nas regras de path do Application Gateway não cobre segmentos adicionais de URL além do imediatamente seguinte
Cenário 4 — Sequência de Diagnóstico
Um cliente reporta que a aplicação web, que estava funcionando normalmente, passou a retornar HTTP 403 Forbidden para todas as requisições após uma mudança de configuração realizada na tarde anterior. A mudança foi descrita vagamente pelo time como "ajustes no gateway".
Os passos de investigação disponíveis são:
- Verificar os logs de diagnóstico do WAF no Log Analytics para identificar se requisições estão sendo bloqueadas por alguma regra específica
- Confirmar se o Application Gateway está operacional verificando o status de saúde no portal do Azure e se o backend pool possui instâncias saudáveis
- Verificar o histórico de mudanças do Application Gateway via Activity Log para identificar exatamente o que foi alterado na tarde anterior
- Testar uma requisição diretamente contra o backend (bypassando o Application Gateway) para determinar se o problema está no gateway ou na aplicação
- Verificar se o modo do WAF foi alterado de Detection para Prevention e se novas regras customizadas foram adicionadas
Qual é a sequência correta de investigação para chegar à causa raiz com o menor número de hipóteses em aberto?
A. 2 → 4 → 3 → 5 → 1
B. 3 → 5 → 1 → 2 → 4
C. 2 → 3 → 5 → 1 → 4
D. 4 → 1 → 3 → 2 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na regra do NSG na subnet das VMs: ela permite tráfego de entrada apenas originado do IP 168.63.129.16, que é o endereço do serviço de plataforma Azure (usado pelo Azure Load Balancer, por exemplo). Os health probes do Application Gateway, no entanto, se originam do intervalo de IPs GatewayManager e dos IPs da própria instância do Application Gateway, não do 168.63.129.16. Isso significa que os probes são bloqueados pela regra DenyAll, fazendo com que backends saudáveis sejam marcados como doentes intermitentemente, o que resulta nos erros 502.
A informação irrelevante no cenário é a SKU Standard_v2 e o fato de o firmware estar atualizado. Essas informações são verdadeiras e plausíveis, mas não têm relação com o sintoma descrito.
O distrator mais perigoso é a alternativa A: o intervalo do probe de 30 segundos é de fato um parâmetro ajustável, e pensar nele como causa leva o diagnóstico na direção errada. A consequência de agir com base nessa hipótese seria reduzir o intervalo do probe sem resolver o bloqueio do NSG, e o problema continuaria.
Gabarito — Cenário 2
Resposta: B
A causa está identificada e confirmada: ataques reais estão ocorrendo agora e o WAF não está bloqueando porque está em modo Detection. A restrição crítica é que falsos positivos existem em dois endpoints, mas isso tem solução conhecida e autorizada: criar exclusões de regra. O cenário informa explicitamente que a equipe tem permissão para criar exclusões.
A sequência correta é: criar as exclusões primeiro para eliminar o risco de interrupção legítima, depois mudar para Prevention. Isso pode ser feito fora de janela porque o impacto de não agir (ataques em andamento) é maior do que o risco da mudança controlada.
A alternativa A é o distrator mais perigoso: aguardar 72 horas com ataques ativos confirmados em produção financeira é indefensável. A janela de manutenção é para mudanças que exigem planejamento, não para respostas a incidentes de segurança ativos. A alternativa C ignora uma restrição concreta (os falsos positivos causariam bloqueio de tráfego legítimo), violando o SLA. A alternativa D usa o processo correto no contexto errado.
Gabarito — Cenário 3
Resposta: D
O wildcard * nas regras de path-based routing do Application Gateway corresponde a qualquer extensão de caminho dentro do segmento imediatamente posterior ao prefixo definido, mas o comportamento real é que /hml/* deve corresponder a caminhos como /hml/qualquercoisa. O problema, entretanto, é que a URL /hml/api/test possui múltiplos segmentos após o prefixo. Embora o * no Application Gateway seja pensado para cobrir tudo, a configuração pode não estar funcionando como esperado dependendo de como o path foi definido. Mais precisamente: se o path foi configurado como /hml/* mas a regra não está sendo avaliada, a Default Rule captura a requisição antes.
A informação irrelevante no cenário é a renovação do certificado SSL. O problema é de roteamento de caminho HTTP, e o estado do certificado não tem influência sobre qual backend pool recebe a requisição.
O distrator mais perigoso é a alternativa C, que propõe uma lógica de processamento não sequencial para as regras. Na realidade, as regras de path são avaliadas sequencialmente por prioridade, e a Default Rule só é acionada quando nenhuma regra de path corresponde. Acreditar na alternativa C levaria o time a investigar a ordem de prioridade em vez de verificar o comportamento do wildcard.
Gabarito — Cenário 4
Resposta: C
A sequência correta é: 2 → 3 → 5 → 1 → 4.
O raciocínio diagnóstico progressivo segue esta lógica:
- Passo 2 primeiro: confirmar que o Application Gateway está operacional e que os backends estão saudáveis. Se o gateway estiver com problema de saúde, os passos seguintes são irrelevantes.
- Passo 3 em seguida: usar o Activity Log para identificar o que foi alterado. O enunciado informa que houve uma mudança vaga na tarde anterior. Saber exatamente o que mudou direciona todos os passos seguintes.
- Passo 5 na sequência: com a informação do Activity Log em mãos, verificar especificamente se o WAF foi alterado para Prevention ou se novas regras foram adicionadas. O HTTP 403 é consistente com bloqueio por WAF.
- Passo 1 logo após: confirmar no Log Analytics quais regras específicas estão bloqueando as requisições.
- Passo 4 por último: testar o backend diretamente apenas se os passos anteriores não identificarem o problema no gateway, para descartar que a causa seja na aplicação.
A alternativa A (2 → 4 → 3 → 5 → 1) é sedutora porque testar o backend parece lógico cedo, mas bypassa o Application Gateway antes de verificar o que mudou nele, desperdiçando tempo e criando hipóteses em aberto desnecessariamente. A alternativa B começa pelo Activity Log sem verificar a saúde do gateway, o que é um erro quando o sintoma pode ser de indisponibilidade total.
Árvore de Troubleshooting: Identify appropriate use cases for Azure Application Gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão verificável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação intermediária ou investigação adicional |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o código de erro ou sintoma observado. A cada nó de pergunta, responda com base no que você consegue verificar diretamente no portal do Azure, nos logs de diagnóstico ou em um teste direto contra o backend. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho (causa identificada) ou verde (ação de resolução). Nós laranja indicam que mais informação precisa ser coletada antes de agir.