SSL-terminering og klebrige økter

SSL/TLS-terminering betyr at lastbalansereren dekrypterer innkommende HTTPS-trafikk, undersøker den dekrypterte HTTP-forespørselen (for å ta rutingbeslutninger) og deretter eventuelt krypterer forespørselen på nytt før den videresendes til backend. Når termineringen skjer på ALB-en, kan applikasjonsserverne motta ukryptert HTTP-trafikk fra lastbalansereren, noe som forenkler konfigurasjonen av backend.

Terminering på lastbalansereren reduserer CPU-belastningen på applikasjonsserverne (ingen TLS-håndtrykk for hver tilkobling), muliggjør innholdsbasert ruting (som krever lesing av HTTP-topptekster) og sentraliserer sertifikathåndteringen.

AWS Certificate Manager (ACM) klargjør, administrerer og fornyer SSL/TLS-sertifikater uten ekstra kostnad. ALB og NLB integreres direkte med ACM: De velger et ACM-sertifikat i konfigurasjonen av HTTPS-lytteren, og lastbalansereren presenterer det for klienter som kobler til.

ACM-sertifikater fornyes automatisk før de utløper – ingen manuell fornyelse og ingen nedetid på grunn av utløpte sertifikater. For offentlige sertifikater validerer ACM domeneeierskap via DNS-validering (CNAME-post i Route 53) eller e-postvalidering. For intern bruk kan ACM Private CA utstede private sertifikater.

SNI (Server Name Indication) er en TLS-utvidelse som gjør det mulig for én IP-adresse (og dermed én ALB- eller NLB-lytter) å betjene flere TLS-sertifikater for ulike domenenavn. Klienten inkluderer vertsnavnet den forsøker å nå, i TLS-meldingen ClientHello, og lastbalansereren velger riktig sertifikat.

ALB støtter SNI innebygd: De kan knytte flere ACM-sertifikater til én HTTPS-lytter. ALB velger automatisk riktig sertifikat basert på klientens SNI-vertsnavn. Dette eliminerer behovet for en separat lytter eller lastbalanserer per domene og muliggjør ekte virtuell hosting med SSL.

ALB og NLB støtter konfigurerbare SSL-sikkerhetspolicyer som styrer hvilke TLS-protokollversjoner og krypteringspakker lastbalansereren godtar fra klienter. AWS tilbyr forhåndsdefinerte policyer (for eksempel ELBSecurityPolicy-TLS13-1-2-2021-06) som oppdateres når nye sårbarheter oppdages.

Etterlevelseskrav kan fastsette bestemte TLS-versjoner: PCI-DSS 3.2.1 krever minst TLS 1.2; mange moderne standarder anbefaler å deaktivere TLS 1.0 og 1.1 fullstendig. Bruk en policy som utelukker utdaterte protokoller og svake krypteringspakker. Foretrekk policyer som inkluderer TLS 1.3 for fremoverrettet hemmelighold og bedre ytelse.

To ulike TLS-tilnærminger på ALB:

• SSL-terminering (vanligst): ALB dekrypterer på lastbalansereren og videresender vanlig HTTP til målene. Dette er enkelt, muliggjør inspeksjon for ruting og reduserer CPU-belastningen på serverne. Backend-trafikken er ukryptert i VPC-en.
• U ende-til-ende-TLS: ALB dekrypterer og krypterer deretter trafikken på nytt før den videresendes til målene (HTTPS mellom ALB og målet). Dette krever mer CPU og sertifikater på målene, men sikrer kryptering i VPC-en i situasjoner med strenge etterlevelseskrav.

I pass-through-modus for TLS på NLB dekrypterer ikke NLB trafikken i det hele tatt – den videresender rå TCP til målet, som håndterer TLS. Applikasjonsserveren administrerer sitt eget sertifikat.

Klebrige økter (også kalt øktbinding) sikrer at alle forespørsler fra samme klient konsekvent rutes til samme mål i en målgruppe. Dette er nødvendig for tilstandsfulle applikasjoner som lagrer øktdata i minnet på individuelle servere (i stedet for i en delt hurtigbuffer som ElastiCache).

Uten klebrige økter kan en tilstandsløs lastbalanserer sende forespørsel 1 til server A (som lagrer økten) og forespørsel 2 til server B (som ikke har øktdata). Da kan brukeren bli logget ut eller miste innholdet i handlekurven. Klebrige økter binder en klient til et bestemt mål så lenge økten varer.

ALB støtter to typer informasjonskapsler for klebrige økter:

• Varighetsbasert klebrighet (LB-generert informasjonskapsel): ALB genererer en informasjonskapsel med navnet AWSALB (for ALB) og angir en utløpsvarighet. Informasjonskapselen inneholder en kryptert referanse til målet. Klienten sender denne informasjonskapselen med påfølgende forespørsler.
• Applikasjonsbasert klebrighet: bruker en eksisterende informasjonskapsel som applikasjonen har angitt. ALB leser navnet på informasjonskapselen De angir, genererer en kryptert versjon i sin egen informasjonskapsel og bruker den til klebrig ruting, samtidig som den opprinnelige informasjonskapselen fra applikasjonen bevares.

Konfigurer klebrighet per målgruppe, med en varighet fra 1 sekund til 7 dager.

Selv om klebrige økter løser problemet med tilstandsfulle applikasjoner, medfører de noen avveininger:

• Ujevn belastningsfordeling: enkelte mål kan motta mer trafikk hvis noen klienter er uvanlig aktive, slik at hensikten med lastbalansering svekkes
• Begrensninger ved skalering: hvis et klebrig mål blir uheldig, brytes øktene – klienten må starte en ny økt med et nytt mål og mister eventuelle øktdata som lå i minnet
• Redusert elastisitet: klebrige økter gjør det vanskeligere å tømme og avslutte instanser under hendelser med nedskalering

Beste praksis: Fjern behovet for klebrige økter ved å flytte økttilstanden til ElastiCache eller DynamoDB. Da blir applikasjonen virkelig tilstandsløs og kan skaleres horisontalt fullt ut.

NLB støtter TLS-lyttere på port 443 (eller en hvilken som helst port) for TLS-terminering, på samme måte som ALB. NLB dekrypterer trafikken, krypterer den eventuelt på nytt og videresender den til målene. Alternativt kan NLB videresende kryptert TCP-trafikk uten å dekryptere den hvis De konfigurerer en TCP-lytter – i denne modusen håndterer applikasjonsserveren TLS fra ende til ende.

TLS-terminering med NLB og ACM gir de samme fordelene ved sertifikathåndtering som ALB, men uten funksjoner på HTTP-laget. Bruk TLS-terminering med NLB når De trenger statiske IP-adresser med TLS-terminering, eller når backend-protokollen ikke er HTTP (for eksempel en egendefinert TCP-protokoll).

Når et klebrig mål avregistreres (for eksempel under en nedskalering av Auto Scaling), gjør tilkoblingstømming det mulig å fullføre forespørsler som allerede er under behandling. Nye forespørsler fra klebrige klienter som fortsatt har AWSALB-informasjonskapselen for målet som tømmes, tildeles imidlertid automatisk et nytt mål – klebrighetskapselen ugyldiggjøres for denne klienten.

Denne kombinasjonen av avregistreringsforsinkelse og ugyldiggjøring av informasjonskapselen sikrer en smidig overgang: Eksisterende langvarige forespørsler fullføres, mens nye forespørsler fra disse klientene rutes jevnt videre til friske mål uten at sluttbrukeren opplever feil.

Beste praksis som er relevant for eksamen:

• Bruk ACM-sertifikater for automatisk fornyelse – administrer aldri sertifikater manuelt på lastbalanserere
• Bruk sikkerhetspolicyer med TLS 1.2+; deaktiver TLS 1.0/1.1 for PCI-/HIPAA-etterlevelse
• Foretrekk tilstandsløse arkitekturer (økter i ElastiCache/DynamoDB) fremfor klebrige økter
• Bruk SNI på ALB for å betjene flere domener fra én lytter, uten flere sertifikater på separate lastbalanserere
• Ved strenge etterlevelseskrav (data i VPC-en må være kryptert): Bruk HTTPS-målgrupper med ende-til-ende-TLS, ikke bare terminering på lastbalansereren

I denne leksjonen har De lært at ALB SSL/TLS-terminering med ACM-sertifikater gir automatisk fornyelse og SNI for flere domener, at SSL-sikkerhetspolicyer styrer TLS-versjon og krypteringspakker av hensyn til etterlevelse, og at klebrige økter ruter brukere til samme mål for tilstandsfulle applikasjoner, men at de helst bør erstattes ved å flytte økttilstanden til ElastiCache. Neste tema er Auto Scaling-grupper og startmaler.