Bezpieczeństwo środowisk serverless i funkcji

Przetwarzanie serverless (Functions as a Service, FaaS) umożliwia programistom wdrażanie pojedynczych funkcji wywoływanych przez zdarzenia — żądania HTTP, komunikaty z kolejek, wyzwalacze baz danych lub zaplanowane timery — bez zarządzania podstawowymi serwerami. Do wiodących platform należą AWS Lambda, Google Cloud Functions i Azure Functions. Dostawca chmury zarządza poprawkami, skalowaniem i infrastrukturą. Chociaż zmniejsza to obciążenie operacyjne, zmienia model odpowiedzialności za bezpieczeństwo: dostawca zabezpiecza środowisko uruchomieniowe, ale programista ponosi wyłączną odpowiedzialność za kod funkcji, uprawnienia i konfigurację.

Funkcje serverless mają odrębną powierzchnię ataku w porównaniu z tradycyjnymi aplikacjami: zazwyczaj działają krótkotrwale (od kilku sekund do kilku minut), przez co tradycyjne rozwiązania EDR i monitorowanie sieci są mniej skuteczne; są sterowane zdarzeniami, co oznacza, że wykonanie może wyzwalać wiele różnych źródeł danych wejściowych (zdarzenia S3, API Gateway, SNS); często działają z uprawnieniami IAM umożliwiającymi dostęp do innych zasobów chmurowych; korzystają też z zależności zewnętrznych (pakietów npm i pip), które mogą zawierać złośliwy kod. Powierzchnię ataku wyznaczają dane wejściowe zdarzeń, uprawnienia IAM oraz łańcuchy zaufania zależności.

Najczęstszą podatnością bezpieczeństwa w środowiskach serverless są nadmiernie uprzywilejowane role IAM. Gdy funkcja musi uzyskać dostęp do jednego zasobnika S3, kuszące jest przypisanie uprawnienia s3:* (pełnego dostępu do S3), aby uniknąć błędów uprawnień. Przejęta lub podatna funkcja działająca z taką rolą może wtedy odczytywać, zapisywać i usuwać dane w dowolnym zasobniku na koncie. Ochronę zapewniają rygorystyczne role IAM zgodne z zasadą najmniejszych uprawnień: każda funkcja powinna mieć dedykowaną rolę przyznającą wyłącznie minimalny zestaw uprawnień wymaganych do wykonania konkretnych zadań tej funkcji. Narzędzia takie jak AWS IAM Access Analyzer i Cloudsplaining automatycznie identyfikują nadmiernie uprzywilejowane role Lambda.

Wstrzyknięcie zdarzenia występuje, gdy dane kontrolowane przez atakującego zawarte w ładunku zdarzenia są niebezpiecznie przetwarzane przez kod funkcji. Ponieważ funkcje serverless mogą być wyzwalane przez wiele źródeł zdarzeń — nagłówki HTTP, parametry zapytań, rekordy zmian w bazie danych, treść komunikatów kolejkowych czy wiadomości e-mail — każde z nich może przenosić złośliwy ładunek. Typowe rodzaje wstrzyknięć to: SQL injection, gdy funkcja wykonuje zapytanie do bazy danych z użyciem danych zdarzenia; NoSQL injection (operatory MongoDB w ładunkach JSON); command injection, gdy dane zdarzenia są używane w poleceniach systemu operacyjnego; oraz SSRF (Server-Side Request Forgery), gdy pobierane są adresy URL pochodzące z danych zdarzenia. Walidacja danych wejściowych i zapytania parametryzowane są niezbędnymi mechanizmami ochrony.

Funkcje serverless często zależą od dziesiątek pakietów zewnętrznych. Zależności te wprowadzają ryzyko związane z łańcuchem dostaw: złośliwy lub przejęty pakiet może wykonać dowolny kod w środowisku wykonywania funkcji, uzyskać dostęp do zmiennych środowiskowych (które często zawierają sekrety), nawiązywać wychodzące połączenia sieciowe i używać roli IAM funkcji do uzyskiwania dostępu do zasobów chmurowych. Głośne ataki, takie jak przejęcie pakietu npm event-stream (2018), oraz liczne pakiety typosquattingowe pokazują skalę tego ryzyka. Mechanizmy ochrony obejmują przypinanie zależności, skanowanie SCA w CI/CD oraz ograniczanie liczby zależności do niezbędnego minimum.

Funkcje serverless często otrzymują sekrety za pośrednictwem zmiennych środowiskowych skonfigurowanych w konsoli chmurowej. Te zmienne środowiskowe są widoczne dla każdej osoby mającej dostęp IAM do konfiguracji Lambda i mogą być odczytane przez dowolny kod wykonywany w ramach funkcji. Zalecane praktyki: unikać przechowywania sekretów bezpośrednio w postaci jawnego tekstu w zmiennych środowiskowych; zamiast tego przechowywać identyfikatory ARN lub nazwy sekretów i pobierać sekrety w czasie wykonywania z AWS Secrets Manager lub Parameter Store; włączyć szyfrowanie KMS zmiennych środowiskowych Lambda w stanie spoczynku; nigdy nie rejestrować zmiennych środowiskowych (wiele narzędzi do rejestrowania komunikatów debugowania zrzuca przy błędzie wszystkie zmienne środowiskowe).

Odmowa usługi wymierzona w funkcje serverless może przyjąć formę zalewania wywołaniami — atakujący, który może wielokrotnie wywoływać funkcję, może wyczerpać obowiązujący na koncie limit współbieżności (domyślnie Lambda pozwala na 1000 jednoczesnych wykonań w każdym regionie), uniemożliwiając wykonywanie innych funkcji na koncie. Funkcje przetwarzające dane wejściowe kontrolowane przez użytkownika powinny stosować ograniczanie częstotliwości żądań na poziomie API Gateway, sprawdzać limity rozmiaru ładunku oraz ustawiać odpowiednie wartości limitu czasu, aby zapobiegać niekończącym się wykonaniom. Jeśli rozmiar danych wejściowych nie jest ograniczony, funkcje mogą być również atakowane za pomocą ataków rozwijających typu Billion Laughs podczas analizowania XML/YAML.

Domyślnie funkcje AWS Lambda działają w zarządzanej przez AWS VPC z dostępem do Internetu, ale bez dostępu do zasobów w prywatnej VPC (baz danych RDS, ElastiCache i prywatnych interfejsów API). Aby uzyskać dostęp do zasobów prywatnych, należy skonfigurować Lambdę do działania we własnej VPC, z określonymi podsieciami i grupami zabezpieczeń. Funkcje Lambda dołączone do VPC nie mają jednak domyślnie dostępu do Internetu — w celu obsługi wychodzącego ruchu internetowego potrzebują NAT Gateway. Grupy zabezpieczeń przypisane do funkcji Lambda powinny być zgodne z zasadą najmniejszych uprawnień: zezwalać wyłącznie na określone porty i adresy docelowe. Należy unikać wychodzących reguł 0.0.0.0/0 w grupach zabezpieczeń funkcji produkcyjnych.

Monitorowanie bezpieczeństwa serverless wymaga innych metod niż tradycyjne monitorowanie hostów. Ponieważ funkcje są efemeryczne, agenty działające na hostach są niepraktyczne. Skuteczne monitorowanie wykorzystuje: AWS CloudTrail do rejestrowania wszystkich wywołań API Lambda (wywołań funkcji, zmian konfiguracji i przyjmowania ról); CloudWatch Logs Insights do wyszukiwania anomalnych wzorców w dziennikach wykonywania funkcji; Amazon GuardDuty do wykrywania zagrożeń, w tym nietypowej aktywności sieciowej Lambdy; oraz komercyjne narzędzia bezpieczeństwa przeznaczone dla środowisk serverless, takie jak Protego (obecnie część Check Point) lub monitorowanie serverless firmy Datadog, które instrumentuje funkcje za pomocą warstw i zapewnia wgląd w działanie w czasie wykonywania.

Testowanie bezpieczeństwa serverless wymaga specjalistycznych narzędzi: PureSec CLI (obecnie Check Point) i Prowler skanują konfiguracje chmurowe pod kątem błędnych konfiguracji środowisk serverless; narzędzia DAST mogą testować funkcje wyzwalane przez HTTP pod kątem podatności na wstrzyknięcia; analiza statyczna kodu funkcji za pomocą narzędzi takich jak Bandit (Python) lub wtyczek bezpieczeństwa ESLint wykrywa niebezpieczne wzorce kodu; testy manualne powinny zaś obejmować wyliczenie wszystkich źródeł zdarzeń, które mogą wyzwalać każdą funkcję, oraz przetestowanie każdego z nich za pomocą zniekształconych i złośliwych ładunków. OWASP Serverless Top 10 zawiera kompleksową listę kontrolną podatności właściwych dla architektur serverless.

Przetwarzanie serverless w jeszcze większym stopniu przesuwa model współdzielonej odpowiedzialności w stronę dostawcy. Dostawca chmury odpowiada za: środowisko uruchomieniowe funkcji, poprawki systemu operacyjnego, bezpieczeństwo podstawowej infrastruktury oraz obiekty fizyczne. Klient nadal odpowiada za: bezpieczeństwo kodu funkcji, projektowanie uprawnień IAM, zarządzanie sekretami, walidację danych wejściowych, zarządzanie zależnościami, konfigurację rejestrowania oraz zasady sieciowe. Mniejsza odpowiedzialność za infrastrukturę nie oznacza mniejszej odpowiedzialności za bezpieczeństwo — zmienia jedynie obszar, na którym należy skupić inwestycje w bezpieczeństwo, przede wszystkim na bezpieczeństwie na poziomie aplikacji i IAM.

W tej lekcji poznali Państwo następujące zagadnienia: nadmiernie uprzywilejowane role IAM stanowią główne ryzyko w środowiskach serverless — każda funkcja potrzebuje dedykowanej roli zgodnej z zasadą najmniejszych uprawnień; ataki polegające na wstrzykiwaniu zdarzeń wykorzystują dowolne źródło zdarzeń, które dostarcza kontrolowane przez atakującego dane do funkcji pozbawionych walidacji danych wejściowych; a ryzyko łańcucha dostaw zależności związane z pakietami zewnętrznymi może doprowadzić do przejęcia wykonywania funkcji i uzyskania dostępu do danych uwierzytelniających IAM oraz sekretów. Następnie omówimy skanowanie bezpieczeństwa Infrastructure as Code w celu wykrywania błędnych konfiguracji przed wdrożeniem.