Terminación SSL y sesiones persistentes

La terminación de SSL/TLS significa que el load balancer descifra el tráfico HTTPS entrante, inspecciona la solicitud HTTP en texto sin cifrar (para tomar decisiones de enrutamiento) y, opcionalmente, vuelve a cifrar la solicitud antes de reenviarla al backend. Cuando la terminación se realiza en el ALB, los servidores de la aplicación pueden recibir tráfico HTTP sin cifrar desde el load balancer, lo que simplifica la configuración del backend.

La terminación en el load balancer reduce la carga de CPU de los servidores de aplicaciones (no es necesario realizar un handshake TLS por conexión), permite el enrutamiento basado en contenido (que requiere leer los encabezados HTTP) y centraliza la gestión de certificados.

AWS Certificate Manager (ACM) aprovisiona, administra y renueva certificados SSL/TLS sin coste adicional. ALB y NLB se integran directamente con ACM: seleccione un certificado de ACM en la configuración del listener HTTPS y el load balancer lo presentará a los clientes que se conecten.

Los certificados de ACM se renuevan automáticamente antes de caducar; no es necesario renovarlos manualmente y no se producen interrupciones debido a certificados caducados. Para los certificados públicos, ACM valida la propiedad del dominio mediante validación DNS (registro CNAME en Route 53) o validación por correo electrónico. Para uso interno, ACM Private CA puede emitir certificados privados.

SNI (Server Name Indication) es una extensión de TLS que permite que una sola dirección IP (y, por tanto, un solo listener de ALB o NLB) proporcione varios certificados TLS para distintos nombres de dominio. El cliente incluye el nombre de host al que intenta acceder en el mensaje TLS ClientHello, y el load balancer selecciona el certificado adecuado.

ALB admite SNI de forma nativa: puede asociar varios certificados de ACM a un único listener HTTPS. El ALB selecciona automáticamente el certificado correcto según el nombre de host SNI del cliente. Esto elimina la necesidad de usar un listener o load balancer independiente por dominio y permite un verdadero hosting virtual con SSL.

ALB y NLB admiten políticas de seguridad SSL configurables que controlan qué versiones del protocolo TLS y qué conjuntos de cifrado acepta el load balancer de los clientes. AWS proporciona políticas predefinidas (por ejemplo, ELBSecurityPolicy-TLS13-1-2-2021-06) que se actualizan cuando se descubren nuevas vulnerabilidades.

Los requisitos de cumplimiento pueden exigir versiones específicas de TLS: PCI-DSS 3.2.1 requiere como mínimo TLS 1.2; muchos estándares modernos recomiendan deshabilitar por completo TLS 1.0 y 1.1. Use una política que excluya protocolos obsoletos y conjuntos de cifrado débiles. Dé preferencia a las políticas que incluyan TLS 1.3 por su secreto perfecto hacia adelante y su rendimiento.

Dos enfoques de TLS distintos en ALB:

• Terminación de SSL (la más habitual): el ALB descifra el tráfico en el load balancer y reenvía HTTP sin cifrar a los destinos. Es sencilla, permite inspeccionar el tráfico para el enrutamiento y reduce el uso de CPU del servidor. El tráfico del backend no está cifrado dentro de la VPC.
• TLS de extremo a extremo: el ALB descifra el tráfico y luego lo vuelve a cifrar antes de reenviarlo a los destinos (HTTPS entre el ALB y el destino). Consume más CPU y requiere certificados en los destinos, pero garantiza el cifrado dentro de la VPC para escenarios con requisitos estrictos de cumplimiento.

En el modo de transferencia directa de TLS de NLB, NLB no descifra el tráfico; reenvía el TCP sin procesar al destino, que se encarga de TLS. El servidor de la aplicación administra su propio certificado.

Las sesiones persistentes (también llamadas afinidad de sesión) garantizan que todas las solicitudes del mismo cliente se enruten sistemáticamente al mismo destino dentro de un grupo de destinos. Esto es necesario para aplicaciones con estado que almacenan los datos de sesión en la memoria de servidores individuales (en lugar de usar una caché compartida como ElastiCache).

Sin sesiones persistentes, un load balancer sin estado podría enviar la solicitud 1 al servidor A (que almacena la sesión) y la solicitud 2 al servidor B (que no tiene los datos de la sesión), lo que haría que el usuario apareciera como desconectado o perdiera el contenido del carrito. Las sesiones persistentes vinculan un cliente a un destino específico durante la sesión.

ALB admite dos tipos de cookies para sesiones persistentes:

• Persistencia basada en duración (cookie generada por LB): ALB genera una cookie denominada AWSALB (para ALB) y establece una duración de caducidad. La cookie contiene una referencia cifrada al destino. El cliente envía esta cookie en las solicitudes posteriores.
• Persistencia basada en la aplicación: utiliza una cookie existente establecida por su aplicación. ALB lee el nombre de cookie que usted especifique, genera una versión cifrada en su propia cookie y la utiliza para el enrutamiento persistente, al tiempo que conserva la cookie original de la aplicación.

Configure la persistencia por grupo de destinos, con una duración de entre 1 segundo y 7 días.

Aunque las sesiones persistentes resuelven el problema de las aplicaciones con estado, también implican ciertas desventajas:

• Distribución desigual de la carga: algunos destinos pueden recibir más tráfico si determinados clientes tienen una actividad inusualmente alta, lo que contradice el objetivo del balanceo de carga
• Limitaciones de escalado: si un destino persistente deja de estar saludable, las sesiones se interrumpen; el cliente debe iniciar una nueva sesión con otro destino y pierde los datos de sesión almacenados en memoria
• Menor elasticidad: las sesiones persistentes dificultan vaciar y terminar instancias durante eventos de reducción de escala

Práctica recomendada: elimine la necesidad de sesiones persistentes externalizando el estado de sesión a ElastiCache o DynamoDB. Esto hace que su aplicación sea realmente sin estado y permite un escalado horizontal completo.

NLB admite listeners TLS en el puerto 443 (o en cualquier otro puerto) para la terminación de TLS, de forma similar a ALB. NLB descifra el tráfico, opcionalmente lo vuelve a cifrar y lo reenvía a los destinos. Como alternativa, NLB puede transferir directamente el tráfico TCP cifrado sin descifrarlo si configura un listener TCP; en este modo, el servidor de la aplicación gestiona TLS de extremo a extremo.

La terminación de TLS de NLB con ACM ofrece las mismas ventajas de gestión de certificados que ALB, pero sin funciones de la capa HTTP. Use la terminación de TLS de NLB cuando necesite direcciones IP estáticas con terminación de TLS o cuando el protocolo del backend no sea HTTP (por ejemplo, un protocolo TCP personalizado).

Cuando se anula el registro de un destino persistente (por ejemplo, durante una reducción de escala de Auto Scaling), el drenaje de conexiones permite que se completen las solicitudes en curso. Sin embargo, las nuevas solicitudes de clientes persistentes que aún conservan la cookie AWSALB del destino en proceso de drenaje se asignan automáticamente a un nuevo destino; la cookie de persistencia se invalida para ese cliente.

Esta combinación del retraso de anulación del registro y la invalidación de cookies garantiza transiciones fluidas: las solicitudes existentes de larga duración terminan, mientras que las nuevas solicitudes de esos clientes se redirigen progresivamente a destinos en buen estado sin que el usuario final perciba errores.

Prácticas recomendadas relevantes para el examen:

• Use certificados de ACM para la renovación automática; nunca gestione certificados manualmente en los load balancers
• Use políticas de seguridad de TLS 1.2+; deshabilite TLS 1.0/1.1 para cumplir con PCI/HIPAA
• Dé preferencia a las arquitecturas sin estado (sesiones en ElastiCache/DynamoDB) frente a las sesiones persistentes
• Use SNI en ALB para servir varios dominios desde un solo listener, sin necesidad de usar varios certificados en load balancers independientes
• Para un cumplimiento estricto (los datos dentro de la VPC deben estar cifrados), use grupos de destinos HTTPS con TLS de extremo a extremo, no solo la terminación en el load balancer

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que: la terminación de SSL/TLS de ALB con certificados de ACM proporciona renovación automática y SNI para varios dominios; las políticas de seguridad SSL controlan la versión de TLS y los conjuntos de cifrado para el cumplimiento; y las sesiones persistentes enrutan a los usuarios al mismo destino en aplicaciones con estado, pero es preferible sustituirlas por la externalización del estado de sesión a ElastiCache. A continuación, exploraremos los grupos de Auto Scaling y las plantillas de lanzamiento.