Sicherheit serverloser Architekturen und Funktionen

Serverloses Computing (Functions as a Service, FaaS) ermöglicht es Entwicklern, einzelne Funktionen bereitzustellen, die durch Ereignisse – HTTP-Anfragen, Nachrichten aus Warteschlangen, Datenbank-Trigger oder zeitgesteuerte Aufrufe – ausgelöst werden, ohne die zugrunde liegenden Server verwalten zu müssen. Zu den führenden Plattformen gehören AWS Lambda, Google Cloud Functions und Azure Functions. Der Cloud-Anbieter übernimmt Patching, Skalierung und Infrastruktur. Das verringert zwar den betrieblichen Aufwand, verschiebt jedoch das Modell der Sicherheitsverantwortung: Der Anbieter sichert die Laufzeitumgebung, während der Entwickler allein für Funktionscode, Berechtigungen und Konfiguration verantwortlich ist.

Serverlose Funktionen weisen im Vergleich zu herkömmlichen Anwendungen eine besondere Angriffsfläche auf: Funktionen sind typischerweise kurzlebig (Sekunden bis Minuten), wodurch herkömmliche EDR- und Netzwerküberwachung weniger wirksam sind; sie sind ereignisgesteuert, das heißt, viele verschiedene Eingabequellen (S3-Ereignisse, API Gateway, SNS) können ihre Ausführung auslösen; häufig werden sie mit IAM-Berechtigungen ausgeführt, die den Zugriff auf andere Cloud-Ressourcen ermöglichen; außerdem verwenden sie Abhängigkeiten von Drittanbietern (npm-, pip-Pakete), die schädlichen Code enthalten können. Die Angriffsfläche wird durch Ereigniseingaben, IAM-Berechtigungen und Vertrauenskapazitäten der Abhängigkeiten bestimmt.

Die häufigste Sicherheitslücke bei serverlosen Architekturen sind übermäßig privilegierte IAM-Rollen. Wenn Entwickler den Zugriff einer Funktion auf einen S3-Bucket benötigen, ist es verlockend, s3:* (vollständigen S3-Zugriff) zuzuweisen, um Berechtigungsfehler zu vermeiden. Eine kompromittierte oder verwundbare Funktion mit dieser Rolle kann dann jeden Bucket im Konto lesen, beschreiben oder löschen. Die Abwehrmaßnahme sind strikt nach dem Prinzip der geringsten Berechtigungen ausgestaltete IAM-Rollen: Jede Funktion sollte über eine eigene Rolle verfügen, die nur die für die spezifischen Aufgaben dieser Funktion erforderlichen Mindestberechtigungen gewährt. Tools wie AWS IAM Access Analyzer und Cloudsplaining erkennen übermäßig privilegierte Lambda-Rollen automatisch.

Eine Ereignisinjektion liegt vor, wenn vom Angreifer kontrollierte Daten in einer Ereignis-Payload vom Funktionscode unsicher verarbeitet werden. Da serverlose Funktionen durch viele Ereignisquellen ausgelöst werden können – HTTP-Header, Query-Parameter, Datenbankänderungsdatensätze, Nachrichtentexte aus Warteschlangen und E-Mail-Inhalte –, kann jede dieser Quellen schädliche Payloads enthalten. Häufige Injektionstypen sind: SQL-Injection, wenn die Funktion eine Datenbank mit Ereignisdaten abfragt, NoSQL-Injection (MongoDB-Operatoren in JSON-Payloads), Command Injection, wenn Ereignisdaten in Betriebssystembefehlen verwendet werden, und SSRF (Server-Side Request Forgery), wenn URLs aus Ereignisdaten abgerufen werden. Eingabevalidierung und parametrisierte Abfragen sind unverzichtbare Schutzmaßnahmen.

Serverlose Funktionen hängen häufig von Dutzenden Paketen von Drittanbietern ab. Diese Abhängigkeiten bergen Risiken für die Software-Lieferkette: Ein bösartiges oder kompromittiertes Paket kann in der Ausführungsumgebung der Funktion beliebigen Code ausführen, auf Umgebungsvariablen (die häufig Secrets enthalten) zugreifen, ausgehende Netzwerkverbindungen herstellen und die IAM-Rolle der Funktion zum Zugriff auf Cloud-Ressourcen verwenden. Angriffe wie die Kompromittierung des event-stream-npm-Pakets (2018) und zahlreiche Typosquatting-Pakete verdeutlichen dieses Risiko. Zu den Schutzmaßnahmen gehören das Fixieren von Abhängigkeiten, SCA-Scans in CI/CD und eine möglichst geringe Anzahl an Abhängigkeiten.

Serverlose Funktionen erhalten Secrets häufig über in der Cloud-Konsole konfigurierte Umgebungsvariablen. Diese Umgebungsvariablen sind für alle Personen mit IAM-Zugriff auf die Lambda-Konfiguration sichtbar und können von jedem Code innerhalb der Funktion gelesen werden. Bewährte Vorgehensweisen: Speichern Sie Secrets nicht direkt als Klartext in Umgebungsvariablen; speichern Sie stattdessen ARNs oder Secret-Namen und rufen Sie die Secrets zur Laufzeit aus AWS Secrets Manager oder dem Parameter Store ab; aktivieren Sie die KMS-Verschlüsselung für ruhende Lambda-Umgebungsvariablen; und protokollieren Sie niemals Umgebungsvariablen (viele Debug-Logger geben bei Fehlern alle Umgebungsvariablen aus).

Ein Denial-of-Service-Angriff auf serverlose Funktionen kann in Form einer Überflutung mit Aufrufen erfolgen: Ein Angreifer, der eine Funktion wiederholt auslösen kann, kann das Parallelitätslimit des Kontos ausschöpfen (der Standardwert von Lambda beträgt 1.000 gleichzeitig ausgeführte Funktionen pro Region), sodass andere Funktionen im Konto nicht mehr ausgeführt werden können. Funktionen, die benutzerkontrollierte Eingaben verarbeiten, sollten auf der Ebene des API Gateway eine Ratenbegrenzung implementieren, die maximale Payload-Größe validieren und geeignete Timeout-Werte festlegen, um unkontrolliert lange Ausführungen zu verhindern. Funktionen können außerdem durch Expansion-Angriffe nach dem Muster von Billion Laughs beim Parsen von XML/YAML angegriffen werden, wenn die Eingabegröße nicht begrenzt ist.

Standardmäßig laufen AWS-Lambda-Funktionen in einer von AWS verwalteten VPC mit Internetzugriff, haben jedoch keinen Zugriff auf Ressourcen in Ihrer privaten VPC (RDS-Datenbanken, ElastiCache, private APIs). Für den Zugriff auf private Ressourcen muss Lambda so konfiguriert werden, dass es innerhalb Ihrer VPC mit bestimmten Subnetzen und Sicherheitsgruppen ausgeführt wird. An VPCs angebundene Lambda-Funktionen haben jedoch standardmäßig keinen Internetzugriff – für ausgehenden Internetverkehr benötigen sie ein NAT Gateway. Für Sicherheitsgruppen, die Lambda-Funktionen zugewiesen sind, sollte das Prinzip der geringsten Berechtigungen gelten: Erlauben Sie nur die spezifischen erforderlichen Ports und Ziele. Vermeiden Sie ausgehende Regeln mit 0.0.0.0/0 in Sicherheitsgruppen von Produktionsfunktionen.

Die Überwachung der Sicherheit serverloser Architekturen erfordert andere Ansätze als die herkömmliche Host-Überwachung. Da Funktionen kurzlebig sind, ist der Einsatz hostbasierter Agents unpraktisch. Eine wirksame Überwachung verwendet: AWS CloudTrail zur Protokollierung aller Lambda-API-Aufrufe (Aufrufe, Konfigurationsänderungen, Rollenübernahmen); CloudWatch Logs Insights zur Abfrage von Funktionsprotokollen auf anomale Muster; Amazon GuardDuty zur Bedrohungserkennung, einschließlich ungewöhnlicher Lambda-Netzwerkaktivitäten; sowie kommerzielle, für serverlose Architekturen entwickelte Sicherheitstools wie Protego (jetzt Teil von Check Point) oder die serverlose Überwachung von Datadog, die Funktionen über Layers instrumentiert und dadurch Einblick in die Laufzeit ermöglicht.

Sicherheitstests für serverlose Architekturen erfordern spezielle Tools: PureSec CLI (jetzt Check Point) und Prowler scannen Cloud-Konfigurationen auf Fehlkonfigurationen in serverlosen Umgebungen; DAST-Tools können HTTP-ausgelöste Funktionen auf Injektionslücken testen; die statische Analyse von Funktionscode mit Tools wie Bandit (Python) oder ESLint-Sicherheits-Plugins erkennt unsichere Codierungsmuster; und bei manuellen Tests sollten Sie alle Ereignisquellen erfassen, die jede Funktion auslösen können, und jede davon mit fehlerhaften und schädlichen Payloads testen. Die OWASP Serverless Top 10 bietet eine umfassende, auf serverlose Architekturen zugeschnittene Checkliste für Sicherheitslücken.

Serverloses Computing verlagert das Modell der geteilten Verantwortung noch stärker zum Anbieter. Der Cloud-Anbieter ist verantwortlich für: die Laufzeitumgebung der Funktion, Betriebssystem-Patches, die Sicherheit der zugrunde liegenden Infrastruktur und die physischen Einrichtungen. Der Kunde bleibt verantwortlich für: die Sicherheit des Funktionscodes, das Design der IAM-Berechtigungen, die Verwaltung von Secrets, die Eingabevalidierung, die Verwaltung von Abhängigkeiten, die Logging-Konfiguration und Netzwerkrichtlinien. Die geringere Verantwortung für die Infrastruktur bedeutet keine geringere Sicherheitsverantwortung – sie verschiebt lediglich den Schwerpunkt der Sicherheitsinvestitionen, vor allem auf die Sicherheit auf Anwendungsebene und die IAM-Sicherheit.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Übermäßig privilegierte IAM-Rollen stellen das größte Risiko bei serverlosen Architekturen dar – jede Funktion benötigt eine eigene Rolle mit den geringstmöglichen Berechtigungen. Angriffe durch Ereignisinjektion nutzen jede Ereignisquelle aus, die von Angreifern kontrollierte Daten an Funktionen ohne Eingabevalidierung übermittelt, und das Risiko der Abhängigkeiten in der Software-Lieferkette durch Pakete von Drittanbietern kann die Ausführung einer Funktion kompromittieren und dadurch Zugriff auf IAM-Anmeldedaten und Secrets ermöglichen. Als Nächstes behandeln wir das Scannen der Sicherheit von Infrastructure as Code, um Fehlkonfigurationen vor der Bereitstellung zu erkennen.