Pular para o conteúdo principal

Laboratório Técnico: Identify appropriate use cases for Azure Application Gateway

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe de arquitetura precisa expor três aplicações web internas ao tráfego externo. Cada aplicação roda em um conjunto diferente de VMs e deve ser acessada por caminhos distintos: /app1, /app2 e /app3, todos sob o mesmo endereço IP público. Além disso, o time de segurança exige inspeção de tráfego HTTP malicioso antes que as requisições cheguem aos backends.

Qual combinação de funcionalidades do Azure Application Gateway atende diretamente a esses dois requisitos?

A. Roteamento baseado em host com múltiplos listeners e Network Security Groups (NSGs) nas subnets dos backends

B. Roteamento baseado em caminho de URL com múltiplos backend pools e Web Application Firewall (WAF)

C. Roteamento baseado em caminho de URL com múltiplos backend pools e Azure Firewall integrado ao Application Gateway

D. Múltiplos listeners com redirecionamento de URL e Microsoft Defender for Cloud habilitado no subscription

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

Um desenvolvedor relata que, após configurar o Azure Application Gateway, as requisições HTTPS dos clientes chegam corretamente ao gateway, mas os servidores de backend estão recebendo apenas tráfego HTTP simples. O time alegou que isso foi intencional para simplificar os certificados nos backends.

Cliente --> HTTPS (TLS 1.2) --> Application Gateway --> HTTP --> Backend Pool (VMs)

Qual é o nome correto do mecanismo configurado nesse cenário e qual é o risco direto associado a ele?

A. TLS Passthrough — o gateway não consegue inspecionar o conteúdo das requisições, tornando o WAF ineficaz

B. SSL Offloading — o tráfego entre o gateway e os backends trafega sem criptografia, expondo dados internos se a rede não for confiável

C. End-to-End TLS — a ausência de certificado no backend faz com que o gateway recuse as conexões automaticamente

D. Backend SSL Termination — os backends precisam de um certificado autoassinado instalado no gateway para funcionar

Questão 3 — Verdadeiro ou Falso​

O Azure Application Gateway pode ser usado como substituto direto do Azure Load Balancer em qualquer cenário, pois opera nas camadas 4 e 7 do modelo OSI simultaneamente, oferecendo todas as capacidades de balanceamento do Load Balancer acrescidas de recursos de aplicação.

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

Uma empresa de e-commerce possui um site que serve tanto a loja principal (loja.contoso.com) quanto o portal do parceiro (parceiros.contoso.com). Ambos os domínios devem responder no mesmo endereço IP público e ser roteados para backend pools completamente distintos.

O arquiteto propõe a seguinte configuração no Application Gateway:

Listener 1: loja.contoso.com       --> Backend Pool A (frontend da loja)
Listener 2: parceiros.contoso.com  --> Backend Pool B (portal de parceiros)

Qual funcionalidade do Application Gateway está sendo aplicada nessa configuração?

A. Roteamento baseado em caminho de URL, utilizando regras de path-based routing para separar os domínios

B. Roteamento baseado em cabeçalho HTTP personalizado, inspecionando o header X-Forwarded-Host

C. Roteamento por múltiplos sites, utilizando listeners com hostname para direcionar tráfego por nome de domínio

D. Redirecionamento de URL, convertendo requisições de um domínio para o outro antes de encaminhar ao backend

Questão 5 — Múltipla Escolha​

Uma organização precisa garantir que sua aplicação web pública seja protegida contra ataques como SQL injection e cross-site scripting (XSS). A solução deve ser gerenciada com o mínimo de manutenção de regras pela equipe interna.

Qual é a abordagem mais adequada utilizando o Azure Application Gateway?

A. Habilitar o WAF no Application Gateway no modo Prevention com um ruleset gerenciado (OWASP ou DRS), deixando a atualização das regras sob responsabilidade da Microsoft

B. Habilitar o WAF no Application Gateway no modo Detection e criar regras personalizadas para SQL injection e XSS manualmente

C. Configurar NSGs na subnet do Application Gateway com regras de negação para os padrões de ataque conhecidos

D. Integrar o Application Gateway ao Microsoft Sentinel para detecção automática de ataques e bloqueio em tempo real via playbooks

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

O roteamento baseado em caminho de URL permite que um único listener distribua requisições para diferentes backend pools com base no sufixo do caminho (ex.: /app1, /app2). Combinado ao WAF, que inspeciona o tráfego HTTP/HTTPS em busca de ameaças conhecidas antes de encaminhar ao backend, os dois requisitos são atendidos nativamente pelo Application Gateway.

  • A alternativa A erra ao usar NSGs para inspeção de tráfego da camada de aplicação: NSGs operam na camada de rede e não inspecionam conteúdo HTTP.
  • A alternativa C confunde responsabilidades: o Azure Firewall é um serviço separado, e sua integração não substitui o WAF embutido no Application Gateway para proteção de aplicações web.
  • A alternativa D usa redirecionamento de URL, que altera destinos, não distribui tráfego por caminhos; o Defender for Cloud não realiza inspeção inline de requisições HTTP.

Gabarito — Questão 2​

Resposta: B

O cenário descreve SSL Offloading (também chamado de SSL Termination): o Application Gateway encerra a sessão TLS com o cliente e encaminha as requisições ao backend em HTTP puro. O risco direto é que o tráfego interno entre o gateway e os backends trafega sem criptografia. Em redes onde a subnet do backend não é totalmente confiável ou isolada, dados sensíveis ficam expostos.

  • A alternativa A descreve TLS Passthrough, que é o oposto: o gateway não decripta o tráfego. Nesse modo, o WAF de fato não consegue inspecionar o conteúdo, mas não é o que o cenário representa.
  • A alternativa C descreve End-to-End TLS, onde o tráfego é criptografado também no trecho gateway-backend. Isso não corresponde ao comportamento descrito.
  • A alternativa D inventa um termo que não corresponde a nenhuma funcionalidade real do Application Gateway.

Gabarito — Questão 3​

Resposta: Falso

O Application Gateway opera exclusivamente na camada 7 do modelo OSI. Ele não possui capacidades de camada 4 como o Azure Load Balancer, que roteia tráfego TCP/UDP arbitrário sem necessidade de protocolo HTTP/HTTPS. Cenários que exigem balanceamento de protocolos não-HTTP (ex.: SMTP, FTP, conexões TCP genéricas) não podem ser atendidos pelo Application Gateway. Os dois serviços são complementares e projetados para casos de uso distintos, não substitutos.

Gabarito — Questão 4​

Resposta: C

A funcionalidade utilizada é o roteamento por múltiplos sites (multi-site hosting). Nela, cada listener é configurado com um hostname específico, e o Application Gateway usa o cabeçalho Host da requisição HTTP para determinar qual regra de roteamento aplicar e, consequentemente, qual backend pool receber o tráfego.

  • A alternativa A confunde os dois tipos de roteamento: path-based routing diferencia por caminho de URL (/caminho), não por nome de domínio.
  • A alternativa B descreve inspeção de cabeçalhos customizados, que não é o mecanismo nativo usado para roteamento por hostname no Application Gateway.
  • A alternativa D descreve redirecionamento, que encaminha o cliente para outra URL, não distribui tráfego para backends distintos.

Gabarito — Questão 5​

Resposta: A

Habilitar o WAF no modo Prevention com um ruleset gerenciado (como OWASP CRS ou Default Rule Set) é a abordagem que combina proteção ativa contra SQL injection e XSS com mínima manutenção interna. A Microsoft é responsável por atualizar e publicar novas versões dos rulesets, reduzindo o esforço operacional da equipe.

  • A alternativa B usa o modo Detection, que apenas registra os ataques sem bloqueá-los, tornando-a inadequada para proteção efetiva.
  • A alternativa C usa NSGs, que operam na camada de rede e não têm capacidade de identificar padrões de ataque em payloads HTTP.
  • A alternativa D mistura responsabilidades: o Microsoft Sentinel é uma ferramenta de SIEM/SOAR. Playbooks podem automatizar respostas, mas não realizam inspeção inline e em tempo real de requisições HTTP da forma que o WAF faz nativamente.