Laboratório de Troubleshooting: Map requirements to features and capabilities of Azure Application Gateway
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que, após uma migração bem-sucedida para o Azure, a aplicação portal.contoso.com está inacessível via HTTPS. O Application Gateway foi implantado há três dias e funcionou corretamente nos primeiros dois dias. Não houve alterações na aplicação nem nos backend pools desde a implantação.
O analista verifica os logs de diagnóstico e encontra a seguinte entrada:
[ERROR] Backend health probe failed
Target: 10.1.2.10:443
Protocol: HTTPS
Status: Connection timeout
Probe path: /healthcheck
Last success: 2026-03-25T14:32:00Z
Informações coletadas pelo analista:
- O certificado TLS configurado no listener do Application Gateway expira em 2027
- O Network Security Group (NSG) associado à subnet do Application Gateway permite tráfego de entrada nas portas 80 e 443
- O backend pool contém duas instâncias de VM (10.1.2.10 e 10.1.2.11)
- O time de segurança informa que aplicou uma nova política de NSG na subnet do backend ontem à tarde
- A aplicação nas VMs utiliza porta 443 com certificado autoassinado
Qual é a causa raiz da falha observada?
A) O certificado TLS do listener do Application Gateway expirou, impedindo o estabelecimento de novas conexões HTTPS.
B) O NSG aplicado na subnet do backend está bloqueando as sondas de saúde originadas pelo Application Gateway.
C) O probe de saúde está configurado com o protocolo incorreto; como o backend usa certificado autoassinado, o probe deve usar HTTP em vez de HTTPS.
D) O Application Gateway atingiu o limite de instâncias de backend suportadas pelo SKU atual.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a regra de roteamento principal do Application Gateway está associada a um HTTP Settings object que aponta para a porta 8080 do backend, mas as instâncias de backend foram reconfiguradas pela equipe de desenvolvimento para escutar na porta 443. O ambiente é de produção com SLA ativo e há usuários conectados no momento.
O engenheiro responsável tem permissão de Contributor no recurso do Application Gateway e precisa restaurar o serviço o mais rápido possível, sem causar interrupção adicional aos usuários que estão com sessões ativas.
Qual é a ação correta a tomar neste momento?
A) Excluir o HTTP Settings object atual e criar um novo apontando para a porta 443, pois objetos HTTP Settings não permitem edição após criação.
B) Editar a porta de backend no HTTP Settings object existente de 8080 para 443 e aplicar a alteração, que entrará em vigor sem reinicialização do gateway.
C) Reiniciar o Application Gateway para forçar a renegociação das conexões com o backend na nova porta.
D) Criar um novo Application Gateway com a configuração correta e atualizar o DNS para apontar para o novo recurso, garantindo zero downtime.
Cenário 3 — Causa Raiz
Uma aplicação de e-commerce hospedada atrás de um Application Gateway com WAF_v2 começa a apresentar erros HTTP 403 para um subconjunto específico de usuários. Os demais usuários acessam normalmente. O time de desenvolvimento confirma que não houve alterações no código da aplicação nas últimas 72 horas.
O analista coleta os seguintes dados dos logs do Application Gateway:
[WAF] Action: Blocked
RuleId: 942100
RuleGroup: REQUEST-942-APPLICATION-ATTACK-SQLI
ClientIP: 189.45.12.33
URI: /busca?q=produto%27+OR+%271%27%3D%271
Message: SQL Injection Attack Detected via libinjection
[WAF] Action: Blocked
RuleId: 942100
RuleGroup: REQUEST-942-APPLICATION-ATTACK-SQLI
ClientIP: 201.76.88.14
URI: /busca?q=notebook%27+OR+%271%27%3D%271
Message: SQL Injection Attack Detected via libinjection
O gerente de produto informa que as reclamações vêm de usuários que utilizam a funcionalidade de busca avançada, que permite o uso do caractere apóstrofo em termos de pesquisa por nome de produto.
O WAF está operando no modo Prevention. O time de segurança confirma que o conjunto de regras gerenciadas (OWASP CRS 3.2) está ativo sem customizações.
Qual é a causa raiz dos erros 403?
A) O Application Gateway está com um bug na versão atual do firmware que causa falsos positivos na regra 942100 para qualquer requisição com caracteres especiais na query string.
B) O WAF está bloqueando requisições legítimas porque a regra 942100 interpreta o padrão de busca com apóstrofo como uma tentativa de injeção SQL, e não há exclusão de regra configurada para esse caminho.
C) O modo Prevention está ativado incorretamente; o comportamento esperado seria apenas registrar as requisições, não bloqueá-las, indicando erro de configuração do modo de operação.
D) Os usuários afetados estão sendo bloqueados por uma política de geo-restrição aplicada automaticamente pelo WAF ao detectar IPs brasileiros.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O Application Gateway está respondendo HTTP 502 Bad Gateway para todas as requisições de um listener específico, mas os demais listeners do mesmo gateway funcionam normalmente."
Os passos de investigação disponíveis são:
- Verificar o estado de saúde do backend pool associado ao listener com falha na aba "Backend health" do portal
- Confirmar se o listener com falha está associado a uma regra de roteamento ativa
- Verificar nos logs de diagnóstico se há erros de probe para as instâncias do backend pool específico
- Validar se o HTTP Settings object associado à regra aponta para a porta e protocolo corretos do backend
- Acessar diretamente uma das instâncias do backend pool via IP privado para confirmar se a aplicação responde
Qual é a sequência correta de investigação para este sintoma?
A) 1 → 3 → 4 → 5 → 2
B) 2 → 1 → 3 → 4 → 5
C) 3 → 1 → 2 → 5 → 4
D) 5 → 4 → 1 → 3 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva no enunciado é o momento da falha: o serviço funcionou corretamente por dois dias e parou após a aplicação de uma nova política de NSG na subnet do backend, realizada ontem à tarde. O log confirma que as sondas de saúde estão em timeout, não retornando erro de certificado ou de protocolo.
O Application Gateway envia probes de saúde a partir de endereços IP dentro de sua própria subnet. Para que esses probes alcancem as instâncias de backend em outra subnet, o NSG da subnet do backend deve permitir tráfego de entrada originado da subnet do Application Gateway. Uma nova política restritiva aplicada à subnet do backend é a única mudança correlacionada temporalmente com o início da falha.
A alternativa A é um distrator claro: o enunciado afirma explicitamente que o certificado do listener expira em 2027. A alternativa C representa um equívoco técnico: o Application Gateway suporta backends com certificados autoassinados via configuração de certificado raiz confiável no HTTP Settings; isso não exige mudar o protocolo do probe para HTTP. A alternativa D é tecnicamente implausível dado o contexto e não é suportada por nenhum dado apresentado. Agir com base na alternativa C seria especialmente perigoso porque removeria a criptografia entre o gateway e o backend sem resolver a causa real.
Gabarito — Cenário 2
Resposta: B
O HTTP Settings object no Application Gateway é um recurso editável. A porta de backend pode ser alterada diretamente no objeto existente sem necessidade de exclusão e recriação. A alteração entra em vigor após o processo de aplicação da configuração, que no Application Gateway v2 ocorre sem reinicialização do processo de data plane, preservando as conexões ativas.
A alternativa A está errada porque parte de uma premissa falsa: HTTP Settings objects podem ser editados. Excluir e recriar o objeto seria desnecessário e introduziria risco de inconsistência durante a janela de recriação. A alternativa C é a mais perigosa: reiniciar o Application Gateway em produção com usuários ativos causaria interrupção imediata de todas as sessões, violando a restrição explícita do cenário. A alternativa D seria uma solução válida em um contexto de falha catastrófica sem possibilidade de edição, mas representa sobreengenharia desnecessária aqui e introduz complexidade operacional e risco de propagação de DNS sem justificativa.
Gabarito — Cenário 3
Resposta: B
Os logs são a evidência central: o WAF está operando no modo Prevention e a regra 942100 do grupo SQLI está bloqueando requisições que contêm o padrão ' OR '1'='1 na query string. Esse padrão é de fato característico de SQL Injection clássico e é detectado pela engine libinjection usada no OWASP CRS.
O problema real é um falso positivo: usuários legítimos que digitam nomes de produtos com apóstrofe estão gerando URIs que, quando codificadas em URL, reproduzem o padrão detectado pela regra. A solução correta seria criar uma exclusão de regra (rule exclusion) para o argumento de query string q no caminho /busca, ou configurar uma regra personalizada que permita explicitamente esse padrão para esse contexto.
A informação sobre a ausência de alterações no código nas últimas 72 horas é propositalmente irrelevante: o problema não está na aplicação, mas na interação entre o comportamento legítimo da funcionalidade de busca e as regras do WAF.
A alternativa C representa um erro conceitual grave: o modo Prevention é o comportamento correto documentado e esperado; bloqueio ativo é sua função, não um defeito de configuração. A alternativa D introduz um conceito inexistente: o WAF não aplica geo-restrição automática por país sem configuração explícita. O distrator mais perigoso é o A, pois poderia levar o operador a procurar uma atualização de firmware em vez de investigar e corrigir a exclusão de regra.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico para HTTP 502 em um listener específico segue o princípio de eliminação progressiva do mais externo para o mais interno, validando cada camada antes de avançar.
O primeiro passo (2) confirma se o listener está de fato vinculado a uma regra ativa: sem essa confirmação, todos os passos seguintes podem estar investigando a configuração correta e ignorando um problema de associação de recursos. O segundo passo (1) usa a visão consolidada de saúde do backend, que é o indicador mais direto para HTTP 502. O terceiro passo (3) aprofunda o diagnóstico nos logs para identificar o padrão específico de falha do probe. O quarto passo (4) valida se a configuração de porta e protocolo no HTTP Settings é compatível com o que o backend espera. O quinto passo (5), acessar diretamente a instância de backend, é o mais operacionalmente custoso e deve ser reservado para confirmar que o problema está no backend e não na cadeia de configuração do gateway.
A sequência A pula a validação da regra de roteamento e inicia pelo estado de saúde sem contexto. A sequência C começa pelos logs antes de validar a existência da regra, invertendo a lógica de triagem. A sequência D começa pelo passo mais custoso (acesso direto ao backend) antes de qualquer triagem no próprio gateway, o que desperdiça tempo e pode levar a conclusões incorretas se o backend estiver saudável e o problema for de configuração do gateway.
Árvore de Troubleshooting: Map requirements to features and capabilities of Azure Application Gateway
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica (decisão binária ou de estado) |
| Laranja | Validação ou verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o sintoma observado: o gateway está retornando um erro HTTP, não está respondendo, ou está bloqueando usuários específicos. A partir daí, siga as perguntas diagnósticas respondendo com base no que é verificável no portal ou nos logs. Cada ramificação elimina hipóteses progressivamente até chegar a uma causa identificada (em vermelho), da qual parte uma ação concreta de resolução (em verde). Nós em laranja indicam onde coletar mais dados antes de seguir adiante.