CloudFront z WAF i Lambda@Edge

AWS WAF (Web Application Firewall) filtruje i monitoruje żądania HTTP/HTTPS docierające do dystrybucji CloudFront. Dołączając Web ACL WAF do dystrybucji, mogą Państwo blokować typowe ataki na aplikacje internetowe — wstrzykiwanie SQL, skrypty międzywitrynowe (XSS), złośliwe boty i ataki z zestawu OWASP Top 10 — zanim dotrą do źródła.

WAF działa na brzegu sieci CloudFront, dlatego złośliwe żądania są odrzucane w najbliższej lokalizacji brzegowej, zamiast docierać do ALB lub serwera aplikacji. Zmniejsza to obciążenie backendu i zatrzymuje ataki bliżej ich źródła.

Web ACL WAF zawiera uporządkowane reguły i grupy reguł, które dopasowują atrybuty żądania i wykonują działanie (Allow, Block, Count, CAPTCHA). Reguły są oceniane zgodnie z priorytetem; wykonywane jest działanie pierwszej pasującej reguły.

AWS udostępnia zarządzane grupy reguł — gotowe zestawy reguł utrzymywane przez AWS i sprzedawców z AWS Marketplace. Zestaw AWS Managed Rules - Core Rule Set obejmuje OWASP Top 10 bez konieczności konfiguracji. AWS aktualizuje zarządzane grupy reguł w miarę pojawiania się nowych zagrożeń, zmniejszając obciążenie operacyjne.

Reguły oparte na częstotliwości w WAF zliczają żądania z każdego źródłowego adresu IP w 5-minutowym oknie. Jeśli adres IP przekroczy próg (np. 2000 żądań w ciągu 5 minut), WAF blokuje kolejne żądania z tego adresu do czasu, aż częstotliwość spadnie. Reguły oparte na częstotliwości chronią przed atakami brute force, przejmowaniem danych uwierzytelniających oraz prostymi atakami DDoS polegającymi na masowym pobieraniu danych.

AWS WAF Bot Control to zarządzana grupa reguł, która klasyfikuje ruch na kategorie: zweryfikowane boty (Googlebot, Bingbot), scrapery, narzędzia monitorujące i ruch generowany przez ludzi. Mogą Państwo skonfigurować różne działania dla poszczególnych kategorii — zezwolić botom wyszukiwarek, poddać nieznane boty weryfikacji CAPTCHA oraz blokować złośliwe scrapery.

Web ACL WAF mają zakres CLOUDFRONT (globalny, do użycia z CloudFront) albo REGIONAL (do użycia z ALB, API Gateway, AppSync lub pulami użytkowników Cognito w określonym regionie). Web ACL WAF o zakresie CloudFront muszą być tworzone w regionie us-east-1, niezależnie od miejsca, z którego pochodzi ruch, ponieważ CloudFront jest zarządzany z tego regionu.

To ważna pułapka egzaminacyjna: jeśli utworzą Państwo Web ACL WAF w eu-west-1 i spróbują dołączyć go do CloudFront, operacja się nie powiedzie. Web ACL WAF dla CloudFront należy zawsze tworzyć w us-east-1.

Lambda@Edge umożliwia uruchamianie funkcji Lambda w języku Node.js lub Python w lokalizacjach brzegowych CloudFront w odpowiedzi na zdarzenia CloudFront. Funkcje są wykonywane w ciągu milisekund od żądania użytkownika, bez kierowania ruchu z powrotem do centralnego regionu w celu przetworzenia.

Funkcje Lambda@Edge są wdrażane w regionie us-east-1, ale automatycznie replikowane do wszystkich lokalizacji brzegowych CloudFront na całym świecie. Dzięki temu kod jest wykonywany możliwie blisko użytkownika, co umożliwia personalizację, uwierzytelnianie i testy A/B na brzegu sieci przy minimalnym narzucie opóźnienia.

Funkcje Lambda@Edge mogą przechwytywać żądania i odpowiedzi CloudFront w czterech punktach cyklu życia:

• Viewer Request: po otrzymaniu żądania od użytkownika przez CloudFront, przed sprawdzeniem pamięci podręcznej — do uwierzytelniania, przekierowań i modyfikowania nagłówków
• Origin Request: po chybieniu pamięci podręcznej, przed przekazaniem żądania do źródła — do przepisywania adresów URL i dodawania niestandardowych nagłówków do źródła
• Origin Response: po otrzymaniu odpowiedzi ze źródła, przed zapisaniem jej w pamięci podręcznej — do dodawania nagłówków bezpieczeństwa i modyfikowania odpowiedzi
• Viewer Response: przed wysłaniem odpowiedzi do użytkownika przez CloudFront — do dodawania lub modyfikowania nagłówków odpowiedzi

AWS oferuje dwie opcje obliczeń na brzegu sieci, które różnią się kompromisami:

• CloudFront Functions: wykonywanie w czasie poniżej milisekundy, tylko JavaScript, bardzo niski koszt (około 1/6 ceny), działanie wyłącznie podczas zdarzeń Viewer Request i Viewer Response, limit czasu obliczeń wynoszący 1 ms, brak dostępu do VPC/sieci
• Lambda@Edge: czas wykonywania do 30 sekund (Viewer) / 30 sekund (Origin), Node.js lub Python, wszystkie cztery punkty wyzwalania, możliwość wykonywania żądań sieciowych oraz dostęp do treści żądań i odpowiedzi

CloudFront Functions należy używać do prostego modyfikowania nagłówków, normalizacji adresów URL i obliczania klucza pamięci podręcznej. Lambda@Edge należy wybierać w przypadku złożonej logiki wymagającej wywołań sieciowych, dłuższego czasu obliczeń lub przetwarzania po stronie źródła.

Typowe wzorce Lambda@Edge na egzaminie SAA-C03:

• Weryfikacja JWT na brzegu sieci: funkcja Viewer Request weryfikuje nagłówek Authorization; nieautoryzowane żądania zwracają kod 401 bez kontaktowania się ze źródłem
• Testy A/B: Viewer Request przypisuje użytkowników do grupy A lub B (za pomocą ciasteczka) i modyfikuje żądanie tak, aby pobrać /a/page.html lub /b/page.html
• Przepisywanie adresów URL: Origin Request przepisuje przyjazne adresy URL na rzeczywiste ścieżki plików w S3
• Dynamiczna zmiana rozmiaru obrazów: Origin Request tworzy żądanie do Lambdy przetwarzającej obraz, a Origin Response zapisuje zmieniony obraz w pamięci podręcznej
• Nagłówki bezpieczeństwa HTTP: Viewer Response dodaje nagłówki CSP, HSTS i X-Frame-Options

Lambda@Edge ma kilka ograniczeń w porównaniu ze standardową usługą Lambda:

• Funkcje muszą znajdować się w regionie us-east-1
• Brak obsługi VPC (brak dostępu do zasobów w VPC)
• Brak zmiennych środowiskowych (konfigurację należy umieścić w kodzie funkcji lub pobrać z Parameter Store podczas zimnego startu)
• Brak możliwości korzystania z warstw Lambda
• Limit czasu dla zdarzeń Viewer: 5 sekund; limit czasu dla zdarzeń Origin: 30 sekund
• Limit rozmiaru pakietu wdrożeniowego: 1 MB (zdarzenia Viewer) / 50 MB (zdarzenia Origin)

Ograniczenia te sprawiają, że Lambda@Edge nie nadaje się do długotrwałych obliczeń, operacji zależnych od VPC ani funkcji wymagających dynamicznej konfiguracji przy każdym wdrożeniu.

WAF i Lambda@Edge pełnią różne role w zakresie bezpieczeństwa i wzajemnie się uzupełniają:

• WAF: blokowanie ataków na podstawie sygnatur (SQL injection, XSS, znani szkodliwi użytkownicy, ograniczanie liczby żądań) — zarządzane reguły automatycznie obsługują typowe ataki
• Lambda@Edge: niestandardowa logika bezpieczeństwa związana z logiką biznesową (weryfikacja JWT, sprawdzanie sesji, weryfikacja tokenów dostępu) — elastyczna, ale wymagająca nakładu pracy programistycznej

Architektura obrony wielowarstwowej: WAF najpierw blokuje znane wzorce ataków; Lambda@Edge weryfikuje uwierzytelnianie na poziomie logiki biznesowej; podpisane adresy URL i pliki cookie CloudFront ograniczają dostęp do treści; OAC zapewnia prywatność S3. Każda warstwa niezależnie zapobiega innej klasie ataków.

Monitoruj warstwę bezpieczeństwa na brzegu sieci za pomocą następujących narzędzi:

• Logi WAF: włącz pełne rejestrowanie żądań do S3, CloudWatch Logs lub Kinesis Firehose, aby sprawdzać, które reguły zostały dopasowane i jaki ruch został zablokowany
• Metryki WAF: BlockedRequests, AllowedRequests, CountedRequests dla każdej reguły w CloudWatch
• Logi Lambda@Edge: grupy CloudWatch Logs są tworzone w każdym regionie, w którym wykonywana jest funkcja; użyj CloudWatch Insights do wykonywania zapytań obejmujących wiele regionów
• CloudFront Real-Time Logs: przesyłaj logi dostępu do Kinesis w celu ich natychmiastowej analizy (w przeciwieństwie do standardowych logów dostępu, które są agregowane co kilka minut)

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedziałeś się, że: AWS WAF blokuje typowe ataki na aplikacje internetowe na brzegu CloudFront, korzystając z zarządzanych i niestandardowych grup reguł; Lambda@Edge uruchamia niestandardowy kod globalnie w czterech punktach wyzwalania CloudFront; a CloudFront Functions zapewnia wykonywanie w czasie krótszym niż milisekunda dla prostej logiki po stronie użytkownika. Listy ACL WAF dla CloudFront muszą być tworzone w regionie us-east-1. W następnej części omówimy Application Load Balancer, Network Load Balancer i Gateway Load Balancer.