Pular para o conteúdo principal

Laboratório Técnico: Configure TLS Termination and End-to-End TLS Encryption

Questões​

Questão 1 — Múltipla Escolha​

Você está configurando um Azure Application Gateway para expor uma aplicação web interna. O requisito de segurança determina que o tráfego entre o gateway e os servidores de backend deve permanecer criptografado, mas o certificado instalado nos backends é autoassinado e não pertence a uma CA pública reconhecida.

Qual é a configuração correta para que o Application Gateway aceite esse certificado de backend sem rejeitar a conexão?

A) Habilitar a opção "Use well-known CA certificate" nas configurações HTTP do backend
B) Instalar o certificado raiz autoassinado como um Trusted Root Certificate nas configurações HTTP do backend
C) Configurar um listener HTTPS com o certificado autoassinado do backend no frontend do gateway
D) Associar um SSL Policy personalizado que desabilite a verificação de cadeia de certificados no backend

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

Um engenheiro configurou o Application Gateway com o seguinte comportamento pretendido: receber conexões HTTPS dos clientes na porta 443, descriptografar o tráfego, inspecionar os cabeçalhos HTTP e reencaminhar o tráfego para os backends também na porta 443 com nova criptografia TLS.

Após o deploy, os logs mostram que o backend está recebendo tráfego na porta 80 em texto claro, contrariando o requisito.

Frontend listener : HTTPS / porta 443
Backend setting   : Protocol = HTTP, Port = 80
Backend pool      : app-server-01:80

Qual é a causa direta do comportamento observado?

A) O Application Gateway não suporta reencriptação para backends na mesma porta do listener
B) A Backend HTTP Setting foi configurada com protocolo HTTP em vez de HTTPS, desabilitando a reencriptação
C) O SSL Policy aplicado ao listener impede que a conexão de saída use TLS
D) O backend pool aponta para a porta 80, o que sobrescreve o protocolo definido na Backend HTTP Setting

Questão 3 — Verdadeiro ou Falso​

No Azure Application Gateway v2, quando a configuração de end-to-end TLS está ativa e o certificado do servidor de backend é emitido por uma CA publicamente confiável (reconhecida pelo Mozilla Trusted CA Store), não é necessário fazer upload manual de nenhum certificado raiz ou intermediário nas configurações HTTP do backend para que a conexão TLS seja estabelecida com sucesso.

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

Uma equipe precisa usar o Azure Front Door para publicar uma API com os seguintes requisitos:

  • Clientes externos acessam via HTTPS com um domínio customizado
  • O tráfego entre o Front Door e o origin server deve ser obrigatoriamente criptografado
  • O certificado do origin server é gerenciado internamente e emitido por uma CA privada corporativa

Após a configuração, conexões de clientes externos funcionam, mas o Front Door retorna erro 502 ao tentar alcançar o origin.

Qual é a causa mais provável?

A) O Front Door não suporta origens com certificados de CA privada em nenhum cenário
B) O domínio customizado não foi validado via CNAME, impedindo a negociação TLS com o origin
C) O Front Door não consegue validar o certificado do origin porque a CA privada não é reconhecida, e a verificação de certificado de origin não foi desabilitada
D) O protocolo HTTPS não está disponível para origens em redes privadas sem integração com Private Link

Questão 5 — Múltipla Escolha​

Ao configurar uma SSL Policy no Azure Application Gateway, qual é a diferença funcional entre usar a política Predefined e a política Custom?

A) A política Predefined define automaticamente o certificado TLS do listener, enquanto a Custom permite usar certificados de terceiros
B) A política Predefined seleciona um conjunto fixo de protocolos e cipher suites mantido pela Microsoft, enquanto a Custom permite escolher explicitamente quais protocolos e cipher suites serão aceitos
C) A política Custom aplica-se apenas a conexões de backend, enquanto a Predefined se aplica apenas ao frontend
D) A política Predefined utiliza TLS 1.3 exclusivamente, enquanto a Custom permite incluir versões mais antigas como TLS 1.0

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

Em cenários de end-to-end TLS, o Application Gateway precisa validar o certificado apresentado pelo servidor de backend durante o handshake TLS. Quando esse certificado é autoassinado ou emitido por uma CA privada, ele não pertence a nenhuma cadeia de confiança publicamente reconhecida. Para que o gateway confie nesse certificado, é necessário fazer o upload do certificado raiz (ou do próprio certificado autoassinado, que é sua própria âncora de confiança) como Trusted Root Certificate dentro das configurações HTTP do backend.

A opção A se aplica apenas quando o certificado do backend foi emitido por uma CA pública reconhecida; nesse caso, o flag "Use well-known CA certificate" dispensa o upload manual. As opções C e D representam equívocos comuns: o certificado do listener protege a conexão com o cliente, não com o backend, e não existe uma SSL Policy que desabilite a verificação de cadeia de certificados de backend como mecanismo suportado oficialmente.

Gabarito — Questão 2​

Resposta: B

O ponto de controle para o comportamento da conexão entre o Application Gateway e o backend é a Backend HTTP Setting. Nela, o campo Protocol determina se a conexão de saída usará HTTP ou HTTPS, independentemente do protocolo configurado no listener de entrada. Quando esse campo está definido como HTTP, o gateway descriptografa o tráfego recebido e o encaminha em texto claro, caracterizando uma terminação TLS simples, não end-to-end.

A opção D é um distrator frequente: a porta definida no backend pool é usada para roteamento, mas o protocolo de encriptação é determinado exclusivamente pela Backend HTTP Setting. A opção C é implausível porque o SSL Policy controla versões de protocolo e cipher suites aceitos no frontend, não bloqueia conexões de saída.

Gabarito — Questão 3​

Resposta: Verdadeiro

O Application Gateway v2 foi atualizado para confiar automaticamente em certificados de backend emitidos por CAs presentes no Mozilla Trusted CA Store, que inclui as principais autoridades públicas do mercado. Nesse caso, o comportamento é análogo ao de qualquer cliente TLS moderno: a cadeia de confiança é resolvida automaticamente sem intervenção manual.

Esse comportamento é significativo porque representa uma diferença importante em relação ao Application Gateway v1, que exigia o upload do certificado em todos os cenários de end-to-end TLS, incluindo CAs públicas. Confundir o comportamento entre as duas versões é um erro recorrente e pode levar a configurações desnecessariamente complexas em ambientes que já utilizam v2 com certificados de CAs reconhecidas.

Gabarito — Questão 4​

Resposta: C

O Azure Front Door realiza validação do certificado TLS apresentado pelo origin server durante o handshake. Quando esse certificado é emitido por uma CA privada corporativa, o Front Door não consegue construir uma cadeia de confiança até uma âncora reconhecida, resultando em falha de conexão manifestada como erro 502 Bad Gateway.

A solução nesse cenário envolve desabilitar a verificação do certificado de origin na configuração de origem do Front Door (opção disponível, mas que deve ser usada com consciência dos riscos) ou substituir o certificado do origin por um emitido por uma CA pública.

A opção A é incorreta porque o Front Door suporta origens com CA privada desde que a verificação seja ajustada. A opção B é um distrator que confunde a validação de domínio customizado do lado do cliente com a validação de certificado de origem. A opção D é incorreta porque HTTPS para origens privadas é suportado com ou sem Private Link, desde que o certificado seja válido ou a verificação seja configurada adequadamente.

Gabarito — Questão 5​

Resposta: B

A distinção fundamental entre as políticas Predefined e Custom está no nível de controle sobre os protocolos TLS e os cipher suites aceitos. Com uma política Predefined, o administrador escolhe um perfil mantido pela Microsoft (como AppGwSslPolicy20220101S), que inclui um conjunto fixo e atualizado de protocolos e algoritmos considerados seguros para aquele nível. Com a política Custom, o administrador especifica explicitamente quais versões de protocolo (ex.: TLS 1.2, TLS 1.3) e quais cipher suites serão habilitados.

A opção D representa um equívoco comum: nenhuma política Predefined é exclusivamente TLS 1.3; todas as políticas predefinidas atuais suportam pelo menos TLS 1.2. As opções A e C descrevem comportamentos que simplesmente não existem; a SSL Policy não tem relação com a identidade do certificado nem com a direção da conexão (frontend versus backend).