SSL-terminering och klistriga sessioner

SSL/TLS-terminering innebär att lastbalanseraren dekrypterar inkommande HTTPS-trafik, granskar den dekrypterade HTTP-förfrågan (för routningsbeslut) och sedan eventuellt krypterar om förfrågan innan den vidarebefordras till backend. När termineringen sker i ALB kan applikationsservrarna ta emot okrypterad HTTP-trafik från lastbalanseraren, vilket förenklar konfigurationen av backend.

Terminering i lastbalanseraren minskar CPU-belastningen på applikationsservrarna (inget TLS-handskakningsförfarande för varje anslutning), möjliggör innehållsbaserad routing (som kräver att HTTP-huvuden läses) och centraliserar certifikatshanteringen.

AWS Certificate Manager (ACM) tillhandahåller, hanterar och förnyar SSL/TLS-certifikat utan extra kostnad. ALB och NLB integreras direkt med ACM: du väljer ett ACM-certifikat i konfigurationen av HTTPS-lyssnaren, och lastbalanseraren presenterar det för anslutande klienter.

ACM-certifikat förnyas automatiskt innan de löper ut – ingen manuell förnyelse och inga driftavbrott på grund av utgångna certifikat. För offentliga certifikat validerar ACM domänägarskapet via DNS-validering (en CNAME-post i Route 53) eller e-postvalidering. För intern användning kan ACM Private CA utfärda privata certifikat.

SNI (Server Name Indication) är ett TLS-tillägg som gör det möjligt för en enda IP-adress (och därmed en enda ALB- eller NLB-lyssnare) att betjäna flera TLS-certifikat för olika domännamn. Klienten inkluderar värdnamnet den försöker nå i TLS-meddelandet ClientHello, och lastbalanseraren väljer rätt certifikat.

ALB har inbyggt stöd för SNI: du kan koppla flera ACM-certifikat till en enda HTTPS-lyssnare. ALB väljer automatiskt rätt certifikat baserat på klientens SNI-värdnamn. Det eliminerar behovet av en separat lyssnare eller lastbalanserare per domän och möjliggör verklig virtuell hosting med SSL.

ALB och NLB stöder konfigurerbara SSL-säkerhetspolicyer som styr vilka TLS-protokollversioner och chiffersviter lastbalanseraren accepterar från klienter. AWS tillhandahåller fördefinierade policyer (till exempel ELBSecurityPolicy-TLS13-1-2-2021-06) som uppdateras när nya sårbarheter upptäcks.

Efterlevnadskrav kan föreskriva specifika TLS-versioner: PCI-DSS 3.2.1 kräver minst TLS 1.2; många moderna standarder rekommenderar att TLS 1.0 och 1.1 inaktiveras helt. Använd en policy som utesluter föråldrade protokoll och svaga chiffersviter. Föredra policyer som inkluderar TLS 1.3 för framåtsekretess och bättre prestanda.

Det finns två olika TLS-metoder för ALB:

• SSL-terminering (vanligast): ALB dekrypterar trafiken i lastbalanseraren och vidarebefordrar vanlig HTTP till målen. Det är enkelt, möjliggör inspektion för routing och minskar CPU-belastningen på servrarna. Backend-trafiken är okrypterad i VPC:n.
• Ändpunkt-till-ändpunkt-TLS: ALB dekrypterar trafiken och krypterar sedan om den innan den vidarebefordras till målen (HTTPS mellan ALB och målet). Detta kräver mer CPU och certifikat på målen, men säkerställer kryptering i VPC:n i scenarier med strikta efterlevnadskrav.

I NLB:s läge för TLS-genomströmning dekrypterar NLB inte alls – det vidarebefordrar rå TCP till målet, som hanterar TLS. Applikationsservern hanterar sitt eget certifikat.

Sticky sessions (även kallat session affinity) säkerställer att alla förfrågningar från samma klient konsekvent dirigeras till samma mål inom en målgrupp. Detta behövs för tillståndsfulla applikationer som lagrar sessionsdata i minnet på enskilda servrar (i stället för i en delad cache som ElastiCache).

Utan sticky sessions kan en tillståndslös lastbalanserare skicka förfrågan 1 till server A (som lagrar sessionen) och förfrågan 2 till server B (som saknar sessionsdata). Då kan användaren verka vara utloggad eller förlora innehållet i sin varukorg. Sticky sessions binder en klient till ett specifikt mål under sessionens varaktighet.

ALB stöder två typer av cookies för sticky sessions:

• Varaktighetsbaserad sticky routing (cookie som genereras av lastbalanseraren): ALB genererar en cookie med namnet AWSALB (för ALB) och anger en giltighetstid. Cookien innehåller en krypterad referens till målet. Klienten skickar denna cookie med efterföljande förfrågningar.
• Applikationsbaserad sticky routing: använder en befintlig cookie som sätts av din applikation. ALB läser namnet på cookien som du anger, genererar en krypterad version i sin egen cookie och använder den för sticky routing, samtidigt som den ursprungliga applikationscookien bevaras.

Konfigurera sticky routing per målgrupp, med en varaktighet från 1 sekund till 7 dagar.

Sticky sessions löser problemet med tillståndsfulla applikationer, men medför kompromisser:

• Ojämn trafikfördelning: vissa mål kan få mer trafik om vissa klienter är ovanligt aktiva, vilket motverkar syftet med lastbalansering
• Begränsningar vid skalning: om ett sticky-mål blir felaktigt bryts sessionerna – klienten måste starta en ny session med ett nytt mål och förlorar sessionsdata som lagrats i minnet
• Minskad elasticitet: sticky sessions gör det svårare att tömma och avsluta instanser under nedskalning

Bästa praxis är att eliminera behovet av sticky sessions genom att flytta sessionsdata till ElastiCache eller DynamoDB. Då blir applikationen verkligen tillståndslös och kan skalas horisontellt fullt ut.

NLB stöder TLS-lyssnare på port 443 (eller valfri port) för TLS-terminering, på liknande sätt som ALB. NLB dekrypterar trafiken, krypterar eventuellt om den och vidarebefordrar den till målen. Alternativt kan NLB vidarebefordra krypterad TCP-trafik utan att dekryptera den om du konfigurerar en TCP-lyssnare – i detta läge hanterar applikationsservern TLS från ändpunkt till ändpunkt.

NLB TLS-terminering med ACM ger samma fördelar för certifikathantering som ALB, men saknar funktioner på HTTP-lagret. Använd NLB TLS-terminering när du behöver statiska IP-adresser med TLS-terminering eller när backend-protokollet inte är HTTP (till exempel ett anpassat TCP-protokoll).

När ett sticky-mål avregistreras (till exempel under en nedskalning av Auto Scaling) gör anslutningstömning det möjligt för pågående förfrågningar att slutföras. Nya förfrågningar från sticky-klienter som fortfarande har AWSALB-cookien för det mål som töms tilldelas dock automatiskt ett nytt mål – sticky-cookien ogiltigförklaras för klienten.

Den här kombinationen av fördröjd avregistrering och ogiltigförklarade cookies säkerställer smidiga övergångar: befintliga långvariga förfrågningar slutförs, medan nya förfrågningar från dessa klienter omdirigeras smidigt till friska mål utan att visas som fel för slutanvändaren.

Bästa praxis som är relevant för provet:

• Använd ACM-certifikat för automatisk förnyelse – hantera aldrig certifikat manuellt på lastbalanserare
• Använd säkerhetspolicyer med TLS 1.2+; inaktivera TLS 1.0/1.1 för PCI-/HIPAA-efterlevnad
• Föredra tillståndslösa arkitekturer (sessioner i ElastiCache/DynamoDB) framför sticky sessions
• Använd SNI i ALB för att betjäna flera domäner från en lyssnare utan flera certifikat på separata lastbalanserare
• För strikta efterlevnadskrav (data i VPC:n måste vara krypterad): använd HTTPS-målgrupper med TLS från ändpunkt till ändpunkt, inte bara terminering i lastbalanseraren

I den här lektionen har du lärt dig att ALB:s SSL/TLS-terminering med ACM-certifikat ger automatisk förnyelse och SNI för flera domäner, att SSL-säkerhetspolicyer styr TLS-version och chiffersviter för efterlevnad, samt att sticky sessions dirigerar användare till samma mål för tillståndsfulla applikationer men helst bör ersättas genom att sessionsdata flyttas till ElastiCache. Härnäst går vi igenom Auto Scaling Groups och startmallar.