Terminazione SSL e sessioni persistenti

La terminazione SSL/TLS significa che il load balancer decritta il traffico HTTPS in ingresso, analizza la richiesta HTTP in chiaro (per prendere decisioni di routing) e quindi, facoltativamente, la cripta nuovamente prima di inoltrarla al backend. Quando la terminazione avviene sull'ALB, i server dell'applicazione possono ricevere traffico HTTP non crittografato dal load balancer, semplificando la configurazione del backend.

La terminazione sul load balancer riduce il carico della CPU sui server dell'applicazione (non è necessario eseguire un handshake TLS per ogni connessione), abilita il routing basato sul contenuto (che richiede la lettura delle intestazioni HTTP) e centralizza la gestione dei certificati.

AWS Certificate Manager (ACM) fornisce, gestisce e rinnova i certificati SSL/TLS senza costi aggiuntivi. ALB e NLB si integrano direttamente con ACM: selezionate un certificato ACM nella configurazione del listener HTTPS e il load balancer lo presenta ai client che si connettono.

I certificati ACM vengono rinnovati automaticamente prima della scadenza: non è necessario rinnovarli manualmente e non si verificano interruzioni dovute a certificati scaduti. Per i certificati pubblici, ACM convalida la proprietà del dominio tramite convalida DNS (record CNAME in Route 53) o convalida tramite e-mail. Per l'uso interno, ACM Private CA può emettere certificati privati.

SNI (Server Name Indication) è un'estensione TLS che consente a un singolo indirizzo IP (e quindi a un singolo listener ALB o NLB) di fornire più certificati TLS per nomi di dominio diversi. Il client include il nome host che sta tentando di raggiungere nel messaggio TLS ClientHello e il load balancer seleziona il certificato appropriato.

ALB supporta SNI nativamente: potete associare più certificati ACM a un singolo listener HTTPS. L'ALB seleziona automaticamente il certificato corretto in base al nome host SNI del client. In questo modo non sono necessari un listener o un load balancer separati per ogni dominio, consentendo il vero virtual hosting con SSL.

ALB e NLB supportano policy di sicurezza SSL configurabili che controllano le versioni del protocollo TLS e le suite di cifratura accettate dal load balancer dai client. AWS fornisce policy predefinite (ad esempio, ELBSecurityPolicy-TLS13-1-2-2021-06) che vengono aggiornate quando vengono scoperte nuove vulnerabilità.

I requisiti di conformità possono imporre versioni TLS specifiche: PCI-DSS 3.2.1 richiede almeno TLS 1.2; molti standard moderni raccomandano di disabilitare completamente TLS 1.0 e 1.1. Utilizzate una policy che escluda i protocolli obsoleti e le suite di cifratura deboli. Preferite policy che includano TLS 1.3 per garantire la perfect forward secrecy e migliori prestazioni.

Su ALB sono disponibili due approcci TLS distinti:

• Terminazione SSL (la più comune): l'ALB decritta il traffico sul load balancer e inoltra HTTP in chiaro alle destinazioni. È semplice, consente di analizzare il routing e riduce l'uso della CPU dei server. Il traffico del backend non è crittografato all'interno del VPC.
• TLS end-to-end: l'ALB decritta il traffico e poi lo cripta nuovamente prima di inoltrarlo alle destinazioni (HTTPS tra ALB e destinazione). Richiede più CPU e certificati sulle destinazioni, ma garantisce la crittografia all'interno del VPC negli scenari con requisiti di conformità rigorosi.

In modalità TLS pass-through per NLB: NLB non decritta affatto il traffico, ma inoltra il TCP grezzo alla destinazione, che gestisce TLS. Il server dell'applicazione gestisce il proprio certificato.

Le sessioni persistenti (chiamate anche affinità di sessione) garantiscono che tutte le richieste dello stesso client vengano instradate costantemente verso la stessa destinazione all'interno di un gruppo di destinazione. Sono necessarie per le applicazioni stateful che memorizzano i dati di sessione nella memoria dei singoli server (anziché in una cache condivisa come ElastiCache).

In assenza di sessioni persistenti, un load balancer stateless potrebbe inviare la richiesta 1 al server A (che memorizza la sessione) e la richiesta 2 al server B (che non dispone dei dati della sessione), facendo apparire l'utente come disconnesso o causando la perdita del contenuto del carrello. Le sessioni persistenti associano un client a una destinazione specifica per la durata della sessione.

ALB supporta due tipi di cookie per le sessioni persistenti:

• Persistenza basata sulla durata (cookie generato dal LB): ALB genera un cookie denominato AWSALB (per ALB) e ne imposta la durata di scadenza. Il cookie contiene un riferimento crittografato alla destinazione. Il client invia questo cookie nelle richieste successive.
• Persistenza basata sull'applicazione: utilizza un cookie esistente impostato dall'applicazione. ALB legge il nome del cookie specificato, genera una versione crittografata nel proprio cookie e la utilizza per il routing persistente, mantenendo al contempo il cookie originale dell'applicazione.

Configurate la persistenza per ogni gruppo di destinazione, con una durata compresa tra 1 secondo e 7 giorni.

Sebbene le sessioni persistenti risolvano il problema delle applicazioni stateful, introducono alcuni compromessi:

• Distribuzione non uniforme del carico: alcune destinazioni possono ricevere più traffico se determinati client sono insolitamente attivi, vanificando lo scopo del load balancing
• Limitazioni della scalabilità: se una destinazione persistente diventa non integra, le sessioni vengono interrotte; il client deve avviare una nuova sessione con una nuova destinazione, perdendo gli eventuali dati di sessione presenti in memoria
• Elasticità ridotta: le sessioni persistenti rendono più difficile svuotare e terminare le istanze durante gli eventi di scale-in

Procedura consigliata: eliminate la necessità di sessioni persistenti esternalizzando lo stato della sessione a ElastiCache o DynamoDB. In questo modo l'applicazione diventa realmente stateless e abilita il pieno scaling orizzontale.

NLB supporta listener TLS sulla porta 443 (o su qualsiasi porta) per la terminazione TLS, in modo simile ad ALB. NLB decritta il traffico, lo ricripta facoltativamente e lo inoltra alle destinazioni. In alternativa, NLB può eseguire il pass-through del traffico TCP crittografato senza decrittarlo, se configurate un listener TCP; in questa modalità, il server dell'applicazione gestisce TLS end-to-end.

La terminazione TLS di NLB con ACM offre gli stessi vantaggi di gestione dei certificati di ALB, ma senza le funzionalità a livello HTTP. Utilizzate la terminazione TLS di NLB quando sono necessari indirizzi IP statici con terminazione TLS o quando il protocollo del backend non è HTTP (ad esempio, un protocollo TCP personalizzato).

Quando una destinazione persistente viene deregistrata (ad esempio durante uno scale-in di Auto Scaling), il connection draining consente di completare le richieste in corso. Tuttavia, le nuove richieste dei client persistenti che conservano ancora il cookie AWSALB relativo alla destinazione in fase di draining vengono assegnate automaticamente a una nuova destinazione; il cookie di persistenza viene invalidato per quel client.

Questa combinazione di ritardo di deregistrazione e invalidazione dei cookie garantisce transizioni graduali: le richieste già avviate e di lunga durata vengono completate, mentre le nuove richieste di quei client vengono reinstradate senza problemi verso destinazioni integre, senza mostrare errori all'utente finale.

Best practice rilevanti per l'esame:

• Utilizzate i certificati ACM per il rinnovo automatico; non gestite mai manualmente i certificati sui load balancer
• Utilizzate policy di sicurezza con TLS 1.2+; disabilitate TLS 1.0/1.1 per la conformità a PCI/HIPAA
• Preferite architetture stateless (sessione in ElastiCache/DynamoDB) alle sessioni persistenti
• Utilizzate SNI su ALB per fornire più domini da un unico listener, senza ricorrere a più certificati su load balancer separati
• Per requisiti di conformità rigorosi (i dati nel VPC devono essere crittografati), utilizzate gruppi di destinazione HTTPS con TLS end-to-end, non solo la terminazione sul load balancer

Verificate la vostra comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione avete imparato che: la terminazione SSL/TLS di ALB con certificati ACM offre il rinnovo automatico e SNI per più domini, le policy di sicurezza SSL controllano la versione TLS e le suite di cifratura ai fini della conformità e le sessioni persistenti instradano gli utenti verso la stessa destinazione per le applicazioni stateful, ma è preferibile sostituirle esternalizzando lo stato della sessione a ElastiCache. Nel prossimo modulo esploreremo gli Auto Scaling Group e i launch template.