Encerramento de SSL e sessões persistentes

Terminação de SSL/TLS significa que o balanceador de carga descriptografa o tráfego HTTPS recebido, inspeciona a solicitação HTTP em texto simples (para tomar decisões de roteamento) e, opcionalmente, criptografa a solicitação novamente antes de encaminhá-la ao backend. Quando a terminação ocorre no ALB, seus servidores de aplicação podem receber tráfego HTTP não criptografado do balanceador de carga, simplificando a configuração do backend.

A terminação no balanceador de carga reduz a sobrecarga de CPU nos servidores de aplicação (não há handshake TLS para cada conexão), permite o roteamento baseado em conteúdo (que exige a leitura dos cabeçalhos HTTP) e centraliza o gerenciamento de certificados.

O AWS Certificate Manager (ACM) provisiona, gerencia e renova certificados SSL/TLS sem custo adicional. ALB e NLB integram-se diretamente ao ACM: você seleciona um certificado do ACM na configuração do listener HTTPS, e o balanceador de carga o apresenta aos clientes que se conectam.

Os certificados do ACM são renovados automaticamente antes do vencimento — sem renovação manual e sem indisponibilidade causada por certificados expirados. Para certificados públicos, o ACM valida a propriedade do domínio por meio da validação de DNS (registro CNAME no Route 53) ou da validação por e-mail. Para uso interno, o ACM Private CA pode emitir certificados privados.

SNI (Server Name Indication) é uma extensão TLS que permite que um único endereço IP (e, portanto, um único listener ALB ou NLB) disponibilize vários certificados TLS para diferentes nomes de domínio. O cliente inclui no handshake ClientHello do TLS o nome do host que está tentando acessar, e o balanceador de carga seleciona o certificado apropriado.

O ALB oferece suporte nativo a SNI: você pode anexar vários certificados do ACM a um único listener HTTPS. O ALB seleciona automaticamente o certificado correto com base no nome do host SNI do cliente. Isso elimina a necessidade de um listener ou balanceador de carga separado para cada domínio, permitindo hospedagem virtual com SSL.

ALB e NLB oferecem suporte a políticas de segurança SSL configuráveis, que controlam quais versões do protocolo TLS e conjuntos de cifras o balanceador de carga aceita dos clientes. A AWS fornece políticas predefinidas (por exemplo, ELBSecurityPolicy-TLS13-1-2-2021-06), que são atualizadas à medida que novas vulnerabilidades são descobertas.

Os requisitos de conformidade podem determinar versões específicas do TLS: PCI-DSS 3.2.1 exige no mínimo TLS 1.2; muitos padrões modernos recomendam desabilitar completamente TLS 1.0 e 1.1. Use uma política que exclua protocolos obsoletos e conjuntos de cifras fracos. Dê preferência a políticas que incluam TLS 1.3 para obter sigilo de encaminhamento e desempenho.

Há duas abordagens distintas de TLS no ALB:

• Terminação de SSL (mais comum): o ALB descriptografa no balanceador de carga e encaminha HTTP simples aos destinos. É simples, permite a inspeção para roteamento e reduz o uso de CPU do servidor. O tráfego do backend não é criptografado dentro da VPC.
• TLS de ponta a ponta: o ALB descriptografa e depois criptografa novamente antes de encaminhar aos destinos (HTTPS entre o ALB e o destino). Consome mais CPU e exige certificados nos destinos, mas garante a criptografia dentro da VPC em cenários de conformidade rigorosa.

No modo de passagem de TLS do NLB: o NLB não descriptografa nada — ele encaminha o TCP bruto ao destino, que lida com o TLS. O servidor de aplicação gerencia seu próprio certificado.

Sessões persistentes (também chamadas de afinidade de sessão) garantem que todas as solicitações do mesmo cliente sejam encaminhadas consistentemente ao mesmo destino dentro de um grupo de destino. Isso é necessário para aplicações com estado que armazenam dados de sessão na memória de servidores individuais (em vez de usar um cache compartilhado como o ElastiCache).

Sem sessões persistentes, um balanceador de carga sem estado pode enviar a solicitação 1 ao servidor A (que armazena a sessão) e a solicitação 2 ao servidor B (que não tem os dados da sessão), fazendo o usuário parecer desconectado ou perder o conteúdo do carrinho. As sessões persistentes vinculam um cliente a um destino específico durante a sessão.

O ALB oferece suporte a dois tipos de cookies de sessão persistente:

• Persistência baseada em duração (cookie gerado pelo LB): o ALB gera um cookie chamado AWSALB (para ALB) e define uma duração de expiração. O cookie contém uma referência criptografada ao destino. O cliente envia esse cookie nas solicitações seguintes.
• Persistência baseada na aplicação: usa um cookie existente definido pela sua aplicação. O ALB lê o nome do cookie que você especifica, gera uma versão criptografada em seu próprio cookie e a usa para o roteamento persistente, preservando o cookie original da aplicação.

Configure a persistência por grupo de destino, com duração de 1 segundo a 7 dias.

Embora as sessões persistentes resolvam o problema de aplicações com estado, elas introduzem algumas compensações:

• Distribuição desigual de carga: alguns destinos podem receber mais tráfego se determinados clientes estiverem excepcionalmente ativos, comprometendo o objetivo do balanceamento de carga
• Limitações de escalabilidade: se um destino persistente ficar não íntegro, as sessões serão interrompidas — o cliente precisará iniciar uma nova sessão com um novo destino, perdendo os dados da sessão mantidos na memória
• Elasticidade reduzida: sessões persistentes dificultam a drenagem e o encerramento de instâncias durante eventos de redução de escala

Prática recomendada: elimine a necessidade de sessões persistentes externalizando o estado da sessão para o ElastiCache ou o DynamoDB. Isso torna sua aplicação realmente sem estado e permite a escalabilidade horizontal completa.

O NLB oferece suporte a listeners TLS na porta 443 (ou em qualquer porta) para terminação de TLS, de forma semelhante ao ALB. O NLB descriptografa o tráfego, opcionalmente o criptografa novamente e o encaminha aos destinos. Como alternativa, o NLB pode passar o tráfego TCP criptografado sem descriptografá-lo se você configurar um listener TCP — nesse modo, o servidor de aplicação gerencia o TLS de ponta a ponta.

A terminação TLS do NLB com ACM oferece os mesmos benefícios de gerenciamento de certificados do ALB, mas sem os recursos da camada HTTP. Use a terminação TLS do NLB quando precisar de IPs estáticos com terminação TLS ou quando o protocolo do backend não for HTTP (por exemplo, um protocolo TCP personalizado).

Quando um destino persistente é removido do registro (por exemplo, durante uma redução de escala do Auto Scaling), a drenagem de conexões permite que as solicitações em andamento sejam concluídas. No entanto, novas solicitações de clientes persistentes que ainda tenham o cookie AWSALB do destino em drenagem são atribuídas automaticamente a um novo destino — o cookie de persistência é invalidado para esse cliente.

Essa combinação de atraso de remoção do registro e invalidação do cookie garante transições controladas: as solicitações existentes de longa duração são concluídas, enquanto as novas solicitações desses clientes são redirecionadas suavemente para destinos íntegros, sem parecerem erros para o usuário final.

Práticas recomendadas relevantes para a prova:

• Use certificados do ACM para renovação automática — nunca gerencie certificados manualmente nos balanceadores de carga
• Use políticas de segurança de TLS 1.2+; desabilite TLS 1.0/1.1 para conformidade com PCI/HIPAA
• Dê preferência a arquiteturas sem estado (sessão no ElastiCache/DynamoDB) em vez de sessões persistentes
• Use SNI no ALB para disponibilizar vários domínios a partir de um listener, sem vários certificados em balanceadores de carga separados
• Para conformidade rigorosa (dados dentro da VPC devem ser criptografados): use grupos de destino HTTPS com TLS de ponta a ponta, não apenas terminação no balanceador de carga

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: a terminação de SSL/TLS do ALB com certificados do ACM fornece renovação automática e SNI para vários domínios; as políticas de segurança SSL controlam a versão do TLS e os conjuntos de cifras para fins de conformidade; e as sessões persistentes encaminham os usuários ao mesmo destino em aplicações com estado, mas é melhor substituí-las pela externalização do estado da sessão para o ElastiCache. A seguir, exploraremos grupos de Auto Scaling e modelos de inicialização.