Questão de Segurança da Informação — TLS, SSL e HTTPS — FCC 2025

Terminação SSL em proxy reverso: a arquitetura de balanceamento e segurança

Gabarito: letra D. A estratégia tecnicamente mais adequada é terminar a conexão SSL no proxy reverso, validar as requisições e repassar as comunicações em HTTP interno para os servidores backend. Essa é a prática consagrada de SSL termination (ou terminação TLS), que centraliza o gerenciamento de certificados e o processamento criptográfico no proxy, permitindo que os servidores backend foquem no processamento da aplicação — e, como a rede interna é segura, o tráfego HTTP interno não representa risco relevante.

O cenário descreve um sistema distribuído com proxy reverso, cujo papel é otimizar a arquitetura balanceando desempenho e segurança. O proxy reverso é um intermediário que recebe as requisições dos clientes e as encaminha aos servidores backend, podendo executar funções como balanceamento de carga, cache, filtragem e terminação de SSL/TLS. A terminação SSL consiste em o proxy ser o ponto final da conexão criptografada: ele detém o certificado digital, realiza o handshake TLS com o cliente, descriptografa o tráfego e, em seguida, repassa a requisição já em texto claro (HTTP) para o backend. Essa abordagem concentra o custo computacional da criptografia no proxy, simplifica a gestão de certificados (um único certificado no proxy, em vez de um por servidor) e permite que o proxy inspecione o tráfego para aplicar regras de segurança, como validação de requisições, controle de acesso e proteção contra ataques.

A alternativa correta espelha exatamente essa prática: "terminar a conexão SSL no proxy reverso, validando as requisições, e repassar as comunicações em HTTP interno para os servidores backend". A premissa de que a rede interna é segura é o que torna viável o tráfego HTTP interno — se a rede interna não fosse confiável, seria necessário manter a criptografia até o backend (SSL passthrough ou re-criptografia).

O contraste central desta questão está entre terminação SSL no proxy (a prática recomendada) e SSL passthrough (encaminhar o tráfego criptografado diretamente ao backend). Na terminação, o proxy descriptografa e pode inspecionar o conteúdo; no passthrough, o proxy apenas encaminha os pacotes TLS sem abrir o conteúdo, o que impede a inspeção e exige que cada backend gerencie seu próprio certificado. A banca explora justamente essa confusão: alternativas que descrevem o passthrough ou configurações inseguras como se fossem a melhor prática.

Guarde a fronteira entre terminação SSL (proxy descriptografa, inspeciona e repassa em HTTP) e SSL passthrough (proxy encaminha o tráfego criptografado sem inspecionar): é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Gerenciar SSL individualmente nos servidores backend e usar o proxy apenas para redirecionar com base em portas fixas aumenta a complexidade, não a reduz. Cada backend precisaria de seu próprio certificado e processamento criptográfico, e o proxy perderia a capacidade de inspeção do tráfego. A premissa da alternativa — "reduzindo a complexidade do proxy" — é falsa: a terminação SSL no proxy é que centraliza e simplifica a gestão.

Alternativa B — ❌ Incorreta

A alternativa mistura conceitos incompatíveis: terminação SSH não é uma prática para tráfego web HTTPS (SSH é usado para acesso remoto seguro, não para proteger HTTP), e armazenar em cache todas as requisições dinâmicas é tecnicamente incorreto — requisições dinâmicas, por natureza, não devem ser cacheadas, pois o conteúdo varia a cada solicitação. O cache é apropriado para conteúdo estático. Além disso, "encaminhar apenas requisições autenticadas" é uma função de controle de acesso, não uma estratégia de terminação SSL.

Alternativa C — ❌ Incorreta

Esta alternativa descreve o SSL passthrough: encaminhar os pacotes SSL diretamente aos servidores backend via túnel TCP. Embora seja uma técnica válida em alguns cenários, ela impede a inspeção do tráfego pelo proxy e exige que cada backend gerencie seu próprio certificado — o que contraria a otimização de desempenho e segurança buscada. Além disso, "armazenar os certificados SSL no proxy para validação simplificada" é contraditório: se o proxy não termina a conexão, ele não valida o certificado com o cliente; o certificado é do backend.

Alternativa D — ✅ Correta ⟵ GABARITO

A alternativa descreve com precisão a terminação SSL: o proxy reverso encerra a conexão TLS com o cliente, detendo o certificado e realizando o handshake; valida as requisições (inspeção de conteúdo, regras de segurança, controle de acesso); e repassa o tráfego já descriptografado em HTTP para os servidores backend. Como a rede interna é segura, o HTTP interno não compromete a confidencialidade. Essa é a arquitetura padrão em balanceadores de carga e proxies reversos (como Nginx, HAProxy e AWS ELB), que otimiza desempenho ao concentrar a criptografia no proxy e simplifica a gestão de certificados.

Alternativa E — ❌ Incorreta

A alternativa descreve uma prática insegura: recriptografar com um único certificado autoassinado e desativar a validação de tráfego para melhorar desempenho. Certificados autoassinados não são confiáveis para clientes externos (o navegador exibirá aviso de segurança), e desativar a validação de tráfego elimina justamente a inspeção que o proxy deveria realizar — abrindo brechas para ataques. A terminação SSL correta usa certificados válidos emitidos por autoridades certificadoras confiáveis e mantém a validação ativa.

Gabarito: letra D