Terminacja SSL i sesje sticky

Terminowanie SSL/TLS oznacza, że load balancer odszyfrowuje przychodzący ruch HTTPS, analizuje jawną treść żądania HTTP (w celu podjęcia decyzji dotyczących routingu), a następnie opcjonalnie ponownie szyfruje żądanie przed przekazaniem go do backendu. Gdy terminowanie odbywa się na ALB, serwery aplikacji mogą odbierać od load balancera nieszyfrowany ruch HTTP, co upraszcza konfigurację backendu.

Terminowanie na load balancerze zmniejsza obciążenie procesora serwerów aplikacji (brak uzgadniania TLS dla każdego połączenia), umożliwia routing na podstawie treści (wymagający odczytywania nagłówków HTTP) oraz centralizuje zarządzanie certyfikatami.

AWS Certificate Manager (ACM) udostępnia, zarządza i odnawia certyfikaty SSL/TLS bez dodatkowych opłat. ALB i NLB integrują się bezpośrednio z ACM: podczas konfiguracji listenera HTTPS należy wybrać certyfikat ACM, a load balancer będzie przedstawiać go łączącym się klientom.

Certyfikaty ACM są automatycznie odnawiane przed wygaśnięciem — nie wymagają ręcznego odnowienia i zapobiegają przestojom spowodowanym wygaśnięciem certyfikatów. W przypadku certyfikatów publicznych ACM weryfikuje własność domeny za pomocą walidacji DNS (rekord CNAME w Route 53) lub walidacji e-mail. Do użytku wewnętrznego ACM Private CA może wystawiać certyfikaty prywatne.

SNI (Server Name Indication) to rozszerzenie TLS, które umożliwia pojedynczemu adresowi IP (a tym samym pojedynczemu listenerowi ALB lub NLB) obsługę wielu certyfikatów TLS dla różnych nazw domen. Klient umieszcza nazwę hosta, z którym próbuje się połączyć, w komunikacie TLS ClientHello, a load balancer wybiera odpowiedni certyfikat.

ALB natywnie obsługuje SNI: do pojedynczego listenera HTTPS można dołączyć wiele certyfikatów ACM. ALB automatycznie wybiera właściwy certyfikat na podstawie nazwy hosta SNI klienta. Eliminuje to potrzebę używania osobnego listenera lub load balancera dla każdej domeny i umożliwia pełny hosting wirtualny z użyciem SSL.

ALB i NLB obsługują konfigurowalne zasady bezpieczeństwa SSL, które określają, jakie wersje protokołu TLS i zestawy szyfrów load balancer akceptuje od klientów. AWS udostępnia wstępnie zdefiniowane zasady (np. ELBSecurityPolicy-TLS13-1-2-2021-06), które są aktualizowane po wykryciu nowych luk w zabezpieczeniach.

Wymagania dotyczące zgodności mogą narzucać określone wersje TLS: PCI-DSS 3.2.1 wymaga co najmniej TLS 1.2; wiele współczesnych standardów zaleca całkowite wyłączenie TLS 1.0 i 1.1. Należy używać zasad wykluczających przestarzałe protokoły i słabe zestawy szyfrów. Warto wybierać zasady obejmujące TLS 1.3, zapewniający utajnianie przekazywania i lepszą wydajność.

Na ALB stosuje się dwa odrębne podejścia do TLS:

• Terminowanie SSL (najczęstsze): ALB odszyfrowuje ruch na load balancerze i przekazuje do celów zwykły HTTP. Jest to proste rozwiązanie, umożliwia analizę na potrzeby routingu i zmniejsza obciążenie procesora serwera. Ruch backendu w obrębie VPC jest nieszyfrowany.
• TLS end-to-end: ALB odszyfrowuje ruch, a następnie ponownie szyfruje go przed przekazaniem do celów (między ALB a celem używany jest HTTPS). Rozwiązanie to wymaga więcej zasobów procesora i certyfikatów na celach, ale zapewnia szyfrowanie w obrębie VPC w scenariuszach wymagających ścisłej zgodności.

W trybie TLS pass-through dla NLB NLB w ogóle nie odszyfrowuje ruchu — przekazuje surowy TCP do celu, który obsługuje TLS. Serwer aplikacji zarządza własnym certyfikatem.

Sesje trwałe (nazywane również powinowactwem sesji) zapewniają, że wszystkie żądania tego samego klienta są konsekwentnie kierowane do tego samego celu w ramach grupy docelowej. Jest to konieczne w przypadku aplikacji stanowych, które przechowują dane sesji w pamięci poszczególnych serwerów (zamiast we współdzielonej pamięci podręcznej, takiej jak ElastiCache).

Bez sesji trwałych bezstanowy load balancer może wysłać żądanie 1 do serwera A (który przechowuje sesję), a żądanie 2 do serwera B (który nie ma danych sesji), przez co użytkownik zostanie wylogowany lub utraci zawartość koszyka. Sesje trwałe wiążą klienta z określonym celem na czas trwania sesji.

ALB obsługuje dwa typy plików cookie dla sesji trwałych:

• Trwałość zależna od czasu (plik cookie generowany przez LB): ALB generuje plik cookie o nazwie AWSALB (dla ALB) i ustawia czas jego wygaśnięcia. Plik cookie zawiera zaszyfrowane odwołanie do celu. Klient wysyła ten plik cookie przy kolejnych żądaniach.
• Trwałość oparta na aplikacji: wykorzystuje istniejący plik cookie ustawiony przez aplikację. ALB odczytuje wskazaną nazwę pliku cookie, generuje jej zaszyfrowaną wersję we własnym pliku cookie i używa jej do trwałego routingu, zachowując oryginalny plik cookie aplikacji.

Trwałość należy konfigurować dla każdej grupy docelowej; czas trwania może wynosić od 1 sekundy do 7 dni.

Sesje trwałe rozwiązują problem aplikacji stanowych, ale wiążą się z pewnymi kompromisami:

• Nierównomierny rozkład obciążenia: niektóre cele mogą otrzymywać więcej ruchu, jeśli określeni klienci są wyjątkowo aktywni, co niweczy cel równoważenia obciążenia
• Ograniczenia skalowania: jeśli trwały cel stanie się niesprawny, sesje zostaną przerwane — klient musi rozpocząć nową sesję z nowym celem i utraci dane sesji przechowywane w pamięci
• Mniejsza elastyczność: sesje trwałe utrudniają opróżnianie i kończenie instancji podczas zmniejszania skali

Dobra praktyka: należy wyeliminować potrzebę stosowania sesji trwałych przez przeniesienie stanu sesji do ElastiCache lub DynamoDB. Dzięki temu aplikacja staje się rzeczywiście bezstanowa i możliwe jest pełne skalowanie horyzontalne.

NLB obsługuje listenery TLS na porcie 443 (lub dowolnym innym) do terminowania TLS, podobnie jak ALB. NLB odszyfrowuje ruch, opcjonalnie szyfruje go ponownie i przekazuje do celów. Alternatywnie NLB może przekazywać dalej zaszyfrowany ruch TCP bez odszyfrowywania, jeśli skonfiguruje się listener TCP — w tym trybie serwer aplikacji obsługuje TLS end-to-end.

Terminowanie TLS przez NLB z użyciem ACM zapewnia takie same korzyści w zakresie zarządzania certyfikatami jak ALB, ale bez funkcji warstwy HTTP. Terminowanie TLS przez NLB należy stosować, gdy potrzebne są statyczne adresy IP z terminowaniem TLS lub gdy backend używa protokołu innego niż HTTP (np. niestandardowego protokołu TCP).

Gdy trwały cel zostaje wyrejestrowany (np. podczas zmniejszania skali Auto Scaling), opróżnianie połączeń umożliwia zakończenie żądań będących w toku. Jednak nowe żądania od klientów z aktywnym plikiem cookie AWSALB wskazującym opróżniany cel są automatycznie przypisywane do nowego celu — plik cookie trwałości dla tego klienta zostaje unieważniony.

To połączenie opóźnienia wyrejestrowania i unieważnienia pliku cookie zapewnia płynne przejście: istniejące żądania długotrwałe mogą się zakończyć, a nowe żądania tych klientów są płynnie przekierowywane do sprawnych celów, bez wyświetlania użytkownikowi końcowemu błędów.

Dobre praktyki istotne na egzaminie:

• Należy używać certyfikatów ACM z automatycznym odnawianiem — nie należy ręcznie zarządzać certyfikatami na load balancerach
• Należy używać zasad bezpieczeństwa TLS 1.2+; TLS 1.0/1.1 należy wyłączyć na potrzeby zgodności z PCI/HIPAA
• Należy preferować architektury bezstanowe (sesje w ElastiCache/DynamoDB) zamiast sesji trwałych
• Należy używać SNI w ALB do obsługi wielu domen z jednego listenera, bez używania wielu certyfikatów na oddzielnych load balancerach
• W przypadku ścisłych wymagań zgodności (dane w VPC muszą być szyfrowane) należy używać grup docelowych HTTPS z szyfrowaniem TLS end-to-end, a nie tylko terminowania na load balancerze

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

W tej lekcji dowiedzieli się Państwo, że: terminowanie ALB SSL/TLS z certyfikatami ACM zapewnia automatyczne odnawianie oraz SNI dla wielu domen, zasady bezpieczeństwa SSL określają wersję TLS i zestawy szyfrów na potrzeby zgodności, a sesje trwałe kierują użytkowników do tego samego celu w aplikacjach stanowych, lecz najlepiej zastąpić je przeniesieniem stanu sesji do ElastiCache. Następnie omówimy grupy Auto Scaling i szablony uruchamiania.