Serverless bedeutet nicht sicherheitslos
Gartner schätzt, dass bis 2026 über 50 % der globalen Unternehmen Produktions-Workloads auf Serverless-Plattformen betreiben werden. Diese Zahl ist beeindruckend – und ein wenig beunruhigend. Denn im Bestreben, schneller zu liefern und Infrastrukturaufwand zu minimieren, überspringen die meisten Teams die grundlegenden Sicherheitsmaßnahmen, die Serverless-Umgebungen vor einer völlig neuen Klasse von Schwachstellen schützen.
Die unbequeme Wahrheit: Traditionelle Perimeter-Sicherheit ist in einem Serverless-Modell nahezu irrelevant. Sie besitzen das Betriebssystem nicht. Sie patchen die Laufzeitumgebung nicht. Was Sie besitzen – und was Angreifer ausnutzen werden – sind Ihre Funktionsberechtigungen, Ihre Ereignisquellen, Ihre Secrets in Umgebungsvariablen und der Blast-Radius, den eine übermäßig permissive IAM-Rolle verursacht.
Was Serverless-Architektur wirklich bedeutet
Serverless Computing ist kein Zauberwerk. Es ist ein verwaltetes Ausführungsmodell, bei dem Code in kurzlebigen, zustandslosen Funktionen läuft, die durch Ereignisse ausgelöst werden – HTTP-Anfragen, Queue-Nachrichten, Datenbankänderungen, geplante Jobs. AWS Lambda, Azure Functions und Google Cloud Functions sind die dominierenden Serverless-Computing-Dienste.
Bei der Serverless-Architektur auf AWS laufen Lambda-Funktionen in isolierten Micro-VMs (Firecracker-basiert). Das Datadog State of Serverless 2026 Report ergab, dass 43 % der Lambda-Funktionen in der Produktion mindestens eine kritische Fehlkonfiguration aufwiesen. Serverless Computing auf Azure folgt ähnlichen Mustern mit Azure Functions und Logic Apps, wobei Azure-spezifische Risiken durch die Komplexität von Managed Identity vs. Service Principal-Konfigurationen verstärkt werden.
Die einzigartige Angriffsfläche von Serverless-Funktionen
Serverless eliminiert keine Angriffsvektoren – es verteilt sie neu. Das Verständnis der MITRE ATT&CK Cloud-Matrix ist hier unerlässlich.
Event-Injection
Das ist das serverlose Äquivalent von SQL-Injection, und es wird kriminell unterschätzt. Wenn eine Lambda-Funktion eine SQS-Nachricht verarbeitet, wird die Event-Payload zum Angriffsvektor, wenn die Funktion Eingaben nicht strikt validiert. Das OWASP Serverless Top 10 listet Injection-Fehler als Risiko Nummer eins. Immer noch Nummer eins.
Übermäßig permissive IAM-Rollen
Hier liegen die meisten Serverless-Verstöße tatsächlich. Eine Lambda-Funktion mit s3:*- und dynamodb:*-Berechtigungen ist keine Principle-of-Least-Privilege – es ist eine offene Einladung. Die Lösung ist nicht kompliziert, erfordert aber Disziplin und Werkzeuge. Statische Analyse gegen IAM-Richtlinien, durchgesetzt durch Policy-as-Code, erkennt diese Fehlkonfigurationen bevor sie die Produktion erreichen.
Abhängigkeits- und Supply-Chain-Risiko
Serverless-Funktionen ziehen Drittanbieter-Abhängigkeiten ein. Ein einziges npm-Paket mit einer bösartigen Version oder eine Python-Bibliothek mit einem ungepatchten CVE kann Schwachstellen einführen. SBOM-Praktiken sind hier unverzichtbar. Tools wie Snyk, Trivy und SAST-Scanning integriert in Ihre CI/CD-Pipeline erkennen diese vor dem Deployment.
Session-Sicherheit in Serverless
Session-Sicherheit in Serverless ist komplex. Umgebungsvariablen in Lambda sind zwar mit AWS KMS verschlüsselt, aber im Klartext für jeden mit den entsprechenden IAM-Berechtigungen sichtbar. Das ist ein Secret-Detection-Problem, das sich als Konfigurationsproblem tarnt.
Reale Angriffsmuster bei Serverless
Ein Fintech-Startup ließ 2025 einen API-Gateway-Endpunkt unauthentifiziert während eines phasenweisen Rollouts. Der Endpunkt löste eine Lambda aus, die Lesezugriff auf eine DynamoDB-Tabelle mit Kunden-PII hatte. Ein automatischer Scanner fand den offenen Endpunkt innerhalb von 72 Stunden. Der Blast-Radius: 180.000 Kundendatensätze – vollständig vermeidbar.
Ein weiteres Muster: Bösartige Lambda-Layer. 2025 dokumentierten Forscher öffentliche Lambda-Layer im AWS Serverless Application Repository mit verschleiertem Code, der Umgebungsvariablen bei jeder Aufruf exfiltrierte. Teams, die gemeinsame Layer ohne Scanning einziehen, sind exponiert.
Serverless-Sicherheit absichern: Der praktische Rahmen
1. Least Privilege auf Funktionsebene durchsetzen
Jede Lambda, jede Azure Function erhält eine eigene Ausführungsidentität mit abgegrenzten Berechtigungen. Automatisieren Sie die Durchsetzung durch Policy-as-Code-Leitplanken, die Deployments mit übermäßig permissiven Rollen in CI/CD scheitern lassen.
2. Event-Quellen als feindlich behandeln
Jede Event-Payload ist potenziell angreifer-kontrolliert. Validieren und bereinigen Sie alle Eingaben vor der Verarbeitung. Wenden Sie Schema-Validierung am Funktions-Eintrittspunkt an.
3. Secret-Management richtig machen
Umgebungsvariablen sind kein Secret-Store. Verwenden Sie AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault. Integrieren Sie Secret Detection in Ihre Pipeline.
4. Kontinuierliches Cloud-Posture-Management
Serverless-Fehlkonfigurationen häufen sich schnell an. Eine dedizierte CSPM-Lösung inventarisiert Ihre Serverless-Ressourcen kontinuierlich und bewertet sie gegen CIS Benchmarks und NIST CSF 2.0-Kontrollen. Statische Punkt-in-Zeit-Audits reichen nicht mehr aus, wenn Funktionen dutzende Male täglich deployt werden.
Serverless-Sicherheit auf AWS vs. Azure
Serverless-Architektur auf AWS und Serverless Computing auf Azure teilen dasselbe konzeptionelle Modell, unterscheiden sich aber erheblich in Implementierungsdetails. Auf AWS sind die primären Sicherheitskontrollen IAM-Ausführungsrollen, VPC-Integration und KMS-Verschlüsselung. Auf Azure sind es Managed Identities, Virtual Network Integration und Azure Key Vault. Microsoft Defender for Cloud – das mit Sicherheitsplattformen wie unserer integriert – bietet einheitliches Posture-Management über Azure Functions hinweg.
Compliance-Implikationen für Serverless-Workloads
DSGVO, SOC 2, PCI DSS und NIS2 haben keine Serverless-spezifischen Klauseln – gelten aber vollständig. Daten, die von einer Lambda-Funktion verarbeitet werden, sind weiterhin Daten nach DSGVO-Artikel 32. Lösungen für Compliance-Automatisierung, die Serverless-Ressourcentypen verstehen, sind für regulierte Branchen nicht mehr optional.
Eine Serverless-Sicherheitskultur aufbauen
Die Teams, die Serverless-Sicherheit richtig machen, sind jene, in denen Entwickler das Sicherheitsmodell verstehen. Das bedeutet Bedrohungsmodellierung für neue Serverless-Workloads, Security Champions in den Teams und ein Cloud-Sicherheitsprogramm, das Serverless als erstklassigen Bürger behandelt. Das NIST CSF 2.0 Govern-Funktion – eingeführt in der 2024-Revision – deckt Sicherheitskultur und organisatorische Verantwortung explizit ab.