Serverless Security schützt Workloads, bei denen Cloud-Anbieter die Infrastruktur betreiben, während Code, Konfigurationen und Zugriffsrechte weiterhin in Eurer Verantwortung bleiben.
Serverless reduziert den Betriebsaufwand und bietet automatische Skalierung sowie isolierte Ausführungsumgebungen. Gleichzeitig entstehen neue Angriffsflächen und komplexere Berechtigungsstrukturen.
Zu den häufigsten Bedrohungen gehören:
Event-Injection-Angriffe
überprivilegierte Funktionen
Supply-Chain-Risiken durch Abhängigkeiten
Billing-Angriffe (Denial-of-Wallet)
Best Practices für Serverless Security umfassen:
minimale Berechtigungen
API-Gateways zur Zugriffskontrolle
frühzeitiges Code-Scanning
kontinuierliches Monitoring
Wiz bietet agentless Full-Stack-Transparenz für Serverless-Workloads und hilft Euch, tatsächlich ausnutzbare Risiken schneller zu identifizieren und zu priorisieren.
Grundlagen des Serverless Computing
Serverless Computing ist ein Cloud-Ausführungsmodell, bei dem Entwicklungsteams Code schreiben und bereitstellen, ohne sich um die zugrunde liegende Infrastruktur zu kümmern. Cloud-Anbieter übernehmen automatisch Server-Bereitstellung, Skalierung und Wartung.
Dadurch entfällt ein Großteil klassischer Infrastrukturaufgaben wie Betriebssystem-Patching oder Runtime-Wartung. Serverless bedeutet aber nicht automatisch schwachstellenfrei – es entstehen neue Sicherheitsherausforderungen, die spezialisierte Ansätze erfordern.
Sicherheit bleibt auch bei Serverless Computing ein zentrales Thema.
Ein Cloud-Security-Alliance-Report von 2023 zeigte: Über 70 % der Unternehmen haben noch immer keine dedizierten Serverless-Security-Kontrollen implementiert. Das Shared-Responsibility-Modell verlagert zwar einige Sicherheitsverantwortlichkeiten auf den Cloud-Anbieter – beseitigt aber nicht alle Sicherheitsbedenken auf eurer Seite.
Uncover Vulnerabilities Across Your Clouds and Workloads
Learn why CISOs at the fastest growing companies choose Wiz to secure their cloud environments.
Serverless Security erklärt
Serverless Security ist die Disziplin, ereignisgesteuerte, funktionsbasierte Workloads und die aufgerufenen Managed Cloud Services zu schützen – durch Absicherung von Code, Konfigurationen, Identitäten, Daten und Runtime-Verhalten.
Im Shared-Responsibility-Modell patcht und betreibt der Cloud-Anbieter die Infrastruktur (Betriebssystem, Runtimes, Skalierung). Ihr seid verantwortlich für Anwendungslogik und Abhängigkeiten, Berechtigungen und Zugriffspfade, Secrets und Datenschutz, Service-Konfigurationen sowie Event-Trigger.
Da Serverless kurzlebig und stark verteilt ist, konzentriert sich effektive Serverless Security auf:
Zugriff nach dem Prinzip der geringsten Berechtigung für jede Funktion und jeden Service.
Input- und Event-Validierung verhindern Injection und Missbrauch.
Secret-Management und Vermeidung unbeabsichtigter Zustände schützen sensible Daten.
Supply-Chain-Hygiene über Libraries und CI/CD hinweg minimiert externe Risiken.
Netzwerk- und Exposure-Kontrollen (API-Gateways, privates Networking, sichere Function-URLs) begrenzen die Angriffsfläche.
Runtime-Monitoring, Logging und Tracing ermöglichen schnelle Erkennung und Reaktion auf Anomalien.
Kosten- und Rate-Safeguards dämmen Denial-of-Wallet-Angriffe ein.
Vorteile von Serverless-Architekturen
Serverless-Architekturen bieten überzeugende Vorteile, die die Adoption in Unternehmen vorantreiben:
Flexible Managed Services
On-Demand-Abrechnung eliminiert Kosten, wenn Funktionen nicht laufen. Ihr zahlt nur für die tatsächliche Ausführungszeit, nicht für ungenutzte Infrastruktur.
FaaS-Plattformen unterstützen mehrere Programmiersprachen ohne Infrastrukturmanagement. So könnt ihr komplette Backends aufbauen und gleichzeitig OS-Wartung, Sicherheits-Patches und fixe monatliche Serverkosten vermeiden.
Verbesserte Sicherheit
Serverless-Umgebungen bieten mehrere Sicherheitsvorteile:
Managed Infrastructure Security: Cloud-Anbieter übernehmen OS- und Runtime-Patching. Das reduziert euren Sicherheitswartungsaufwand erheblich.
Zustandslose Ausführung: Funktionen laufen isoliert ohne persistenten Zustand. Das begrenzt, was Angreifer zwischen Ausführungen abgreifen können.
Reduzierte Angriffsfläche: Kleinere Code-Footprints und zweckgebundene Funktionen erleichtern das Prinzip der geringsten Berechtigung und das Tracking potenzieller Schwachstellen.
On-Demand-Abrechnung
On-Demand-Abrechnung ist ein enormer Vorteil für euer Budget. Ihr zahlt nur für das, was ihr nutzt. Läuft eine Funktion nicht oder sind keine Daten in einer Datenbank, fallen auch keine Kosten an. Eine einzelne Serverless-Ausführung mag teurer sein als auf traditioneller Infrastruktur, die den ganzen Monat voll ausgelastet ist – aber dieses Szenario ist selten. Es macht also Sinn, das Risiko ungenutzter Infrastruktur auf den Cloud-Anbieter zu verlagern.
What is Cloud Vulnerability Management? CVM That Prioritizes Real Risk, Not Just CVEs
Mehr lesen
Sicherheitsanforderungen für Serverless-Apps
Trotz vieler Vorteile bringt Serverless neue Sicherheitsanforderungen mit sich.
Unternehmen betreiben häufig Hunderte von Funktionen über mehrere Cloud-Services hinweg. Dadurch wächst:
die Angriffsfläche
die Komplexität von Berechtigungen
der Bedarf an umfassendem Monitoring
Jede Funktion kann einen potenziellen Einstiegspunkt für Angreifer darstellen und erfordert separate Zugriffskontrollen.
Mit steigender Anzahl von Funktionen nimmt die Sicherheitskomplexität stark zu, wodurch traditionelle Monitoring-Ansätze oft nicht mehr ausreichen.
Häufige Serverless-Sicherheitsbedrohungen
Es gibt mehrere Gründe, warum eine Serverless-Architektur anfällig für Sicherheitslücken sein kann. Hier sind die sieben häufigsten:
1. Erweiterte Angriffsfläche
Serverless-Architekturen können aus Dutzenden, manchmal sogar Hunderten von kleinen Services bestehen, die eine einzelne Anwendung bilden. Das birgt aus mehreren Gründen Risiken:
Mehr Services bedeuten mehr kognitive Last für die Engineering-Teams. Obwohl die Managed-Natur dieser Services die Last etwas verringert, können Probleme übersehen werden, wenn die Anzahl der Services eine kritische Masse erreicht.
Jede Serverless-Funktion lässt sich leicht öffentlich exponieren und schafft so einen Einstiegspunkt in euer System. Behaltet jede Serverless-Funktion im Blick, damit sie nicht zur Schwachstelle wird.
Berechtigungen für viele Services zu verwalten kann ein Vollzeitjob sein, wenn Ihr nicht von Anfang an einen vernünftigen Prozess implementiert. Sonst ist es verlockend, bei nahenden Deadlines jeder Funktion vollen Zugriff zu geben.
2. Event-Data-Injection
Injection-Schwachstellen sind ein Problem für öffentlich exponierte Services. Denkt an JavaScript-Injections für HTML, SQL-Injections für relationale Datenbanken und Event-Injections für Serverless-Architekturen.
Wenn Ihr vom Benutzer gelieferte Teile Eurer Event-Daten ohne Bereinigung in Befehle integriert, wird Eure App anfällig für Injection-Angriffe. Beispiel: Wenn ihr ein Skript per String-Concatenation baut und eine URL oder einen Dateinamen aus Benutzereingaben verwendet, führt ihr erhebliches Risiko ein.
3. Überprivilegierte Funktionen
Wenn Ihr das Prinzip der geringsten Berechtigung gilt, verfügt jede Funktion nur über die minimal erforderlichen Zugriffsrechte. Theoretisch ist das bei Serverless einfacher als bei monolithischen Anwendungen, da Serverless-Funktionen klein, klar abgegrenzt und zweckgebunden sind.
In der Praxis kommt es jedoch häufig vor, dass Funktionen mehr Berechtigungen erhalten als notwendig. Gründe dafür sind zum Beispiel:
unzureichendes Verständnis der verfügbaren IAM-Berechtigungen
Zeitdruck während der Entwicklung
fehlende regelmäßige Berechtigungsprüfungen
Eine Analyse zeigte beispielsweise, dass 85 % der Credentials innerhalb eines 90-Tage-Zeitraums gar nicht genutzt werden.Ein weiteres Problem entsteht, wenn eine große Funktion später in mehrere kleinere Funktionen aufgeteilt wird. In solchen Fällen behalten neue Funktionen oft die ursprünglichen, zu weitreichenden Berechtigungen, obwohl sie nur einen kleinen Teil davon benötigen.
4. Kompromittierter Drittanbieter-Code
Während OS- und Runtime-Wartung in der Verantwortung Eures Anbieters liegt, müsst Ihr Libraries und Frameworks auswählen und Euren Anwendungscode aktuell halten. Supply-Chain-Angriffe nehmen zu. Wenn Ihr Euch auf Drittanbieter-Abhängigkeiten verlasst, ohne deren Sicherheit zu prüfen, installiert Ihr möglicherweise etwas, das Eure Funktionen kompromittiert. Der State of Code Security Report 2025 von Wiz ergab, dass 61 % der Unternehmen Secrets in öffentlichen Repositorys exponiert haben – das unterstreicht die Risiken unzureichenden Dependency-Managements.
5. Unbeabsichtigter Zustand
Serverless-Funktionen gelten häufig als zustandslos (stateless). In der Praxis stimmt das jedoch nicht vollständig. Bei einem Cold-Start lädt die Runtime eure Funktion von Grund auf neu. Aber wenn eure Funktion nicht lange genug inaktiv war, um aus dem Speicher entladen zu werden, und ein weiteres Event erhält, verwendet die Runtime eine bereits geladene Funktion wieder. Alles, was ihr im Code außerhalb einer Handler-Funktion macht, wird gecacht und zu einem Zustand, der anfällig für Sicherheitslücken sein könnte.
6. Side-Channel-Angriffe
Viele Teams gehen davon aus, dass Services innerhalb einer Virtual Private Cloud (VPC) automatisch sicher sind, weil sie nicht direkt aus dem Internet erreichbar sind. Diese Annahme verleitet dazu, internen Services mehr Privilegien zu geben als nötig. Das ist ein großes Problem: Ein externer Angreifer hat viele Tools in seinem Arsenal, selbst ohne direkten Zugang. Und selbst gepeerte VPCs können gefährdet sein.
7. Billing-Angriffe
On-Demand zu zahlen ist großartig, aber es gibt Schattenseiten. Ein Denial-of-Wallet-Angriff (DoW) zielt darauf ab, eine App offline zu nehmen, indem Nutzungsgebühren so lange in die Höhe getrieben werden, bis der Besitzer kein Geld mehr hat, um sie zu bezahlen. Laut OWASP sind DoW-Angriffe bei Serverless eine größere Bedrohung als DoS-Angriffe.
Best Practices für Serverless Security
Effektive Serverless Security erfordert proaktive Maßnahmen, die die einzigartigen Herausforderungen funktionsbasierter Architekturen adressieren. Diese sieben Praktiken bieten umfassenden Schutz:
1. Minimale Berechtigungen vergeben
Wendet konsequent das Least-Privilege-Prinzip an.
Wenn eine Funktion keinen Schreibzugriff benötigt, sollte sie auch keinen erhalten.
Wenn eine Funktion nur auf einen einzelnen Bucket zugreifen muss, sollte sie keinen Zugriff auf Buckets erhalten.
Hunting for signs of persistence in the cloud: an IR guide following the CircleCI incident
Mehr lesen
2. API-Gateways nutzen
Exponiert nicht alle Eure Serverless-Funktionen direkt öffentlich – nutzt stattdessen ein API-Gateway. So habt Ihr nur einen Einstiegspunkt in Eurer Anwendung und könnt den öffentlichen Zugriff zentral verwalten.
3. Command Query Responsibility Separation einsetzen
Teilt eure Funktionen in lesende und schreibende Funktionen auf. Das macht den Code-Footprint jeder Funktion kleiner und leichter zu überwachen. Und wenn eine der beiden kompromittiert wird, bleiben die anderen wahrscheinlich unbetroffen.
4. Euren Code scannen
Befolgt den Shift-Left-Ansatz (frühzeitige Sicherheitsprüfung im Entwicklungsprozess) und löst eure Probleme früh in der Entwicklung. Nutzt Code-Security-Scanner, die in der IDE und eurer CI/CD-Pipeline laufen, um Probleme zu erkennen, bevor sie in die Cloud gelangen.
5. Monitoring, Logging und Tracing priorisieren
Nutzt Monitoring- und Observability-Tools in der Produktion. Sonst habt Ihr keine Möglichkeit herauszufinden, was schiefgelaufen ist, wenn Ihr gehackt wurdet. Monitoring, Logging und Tracing sind essenzielle Bestandteile der laufenden Wartung.
6. Function-URLs absichern
Wenn API-Gateways keine Option sind und Sie Ihre Function-URLs verwenden müssen, stellen Sie sicher, dass diese abgesichert sind. Wir haben einen detaillierten Guide in unserem Blog veröffentlicht – Schaut ihn Euch an!
Lambda-Function-URLs mögen einfach sein, aber wie jede andere extern exponierte Ressource in eurer Cloud-Umgebung müssen sie ordnungsgemäß abgesichert werden. Während Funktionen hinter einem API-Gateway oder Load Balancer auf die sichere Konfiguration dieser Frontend-Services angewiesen sind, müssen Function-URLs eigenständig abgesichert werden. Fehlkonfigurierte Instanzen könnten ein attraktives Ziel für böswillige Akteure sein, die Schaden anrichten oder auf sensible Daten zugreifen wollen.
7. Agentless Scanning nutzen
Moderne Cloud-Umgebungen bestehen oft aus mehreren Technologien und Architekturmustern.
Selbst wenn ihr überwiegend Serverless nutzt, können weiterhin Container, virtuelle Maschinen oder andere Cloud-Services Teil eurer Infrastruktur sein.
Deshalb ist umfassende Transparenz über die gesamte Umgebung hinweg entscheidend.
Agentless-Scanning-Ansätze ermöglichen es, Risiken in verschiedenen Workload-Typen zu erkennen, ohne zusätzliche Agents installieren zu müssen.
Agentless Scanning Best Practices
Agentless scanning inspects cloud environments for security risks without installing software agents on workloads, using cloud provider APIs and snapshot analysis instead
Mehr lesen
Serverless Security mit Wiz
Umfassende Serverless Security erfordert spezialisierte Tools, die sowohl traditionelle als auch neue Serverless-Bedrohungen adressieren. Wiz bietet End-to-End-Schutz für Serverless-Workloads, einschließlich Container wie AWS Fargate und Azure Container Apps.
Die Wiz-Plattform liefert kritische Serverless-Security-Funktionen:
Erweiterte Transparenz: Der Wiz-Runtime-Sensor bietet jetzt tiefe Einblicke in Serverless-Container-Prozesse, selbst ohne direkten Host-Zugriff.
Bedrohungserkennung und Response: Echtzeit-Erkennungs- und Response-Funktionen ermöglichen es Euch, Bedrohungen schnell zu identifizieren und zu entschärfen.
Benutzerdefinierte Regelerstellung: Ihr könnt maßgeschneiderte Regeln erstellen, um verdächtige Prozesse und Netzwerkverhalten zu erkennen – mit der Möglichkeit, spezifische Response-Aktionen auszulösen.
Runtime-Hunting: Der Sensor überwacht alle Serverless-Container-Events und zentralisiert diese Daten. Das ermöglicht proaktives Threat-Hunting und vereinfacht Untersuchungen.
Schwachstellen-Validierung: Wiz hilft bei der Priorisierung von Remediation-Maßnahmen, indem identifiziert wird, welche Schwachstellen in der Runtime-Umgebung tatsächlich ausnutzbar sind.
Diese Erweiterung der Cloud-nativen Sicherheitsplattform von Wiz stellt sicher, dass ihr robuste Sicherheitsmaßnahmen über eure gesamte Cloud-Infrastruktur aufrechterhalten könnt – vom Code bis zur Runtime – ohne die Agilität und Skalierbarkeitsvorteile von Serverless-Architekturen zu opfern.
Uncover Vulnerabilities Across Your Clouds and Workloads
Learn why CISOs at the fastest growing companies choose Wiz to secure their cloud environments.