Was ist serverlose Sicherheit?

Serverless bezieht sich auf ein Cloud-natives Entwicklungsmodell im Cloud-Computing, das es Entwicklern ermöglicht, Anwendungen und Dienste zu erstellen und auszuführen, ohne die Infrastruktur oder die serverseitige IT verwalten zu müssen. Anwendungen im serverlosen Modell stützen sich auf eine Kombination aus verwalteten Cloud-Diensten und Functions as a Service (FaaS), die von der Notwendigkeit abstrahieren, die Infrastruktur und die virtuellen Maschinen zu verwalten, zu patchen und zu sichern.

Vorteile der serverlosen Architektur

Bis 2020 werden laut O'Reilly 40% der Organisationen eine serverlose Architektur vollständig eingeführt haben. In den letzten Jahren hat sich Serverless zu einer dominierenden Anwendungsausführungsumgebung entwickelt. Der State of Cloud Native Security Report 2024 zeigt ein weiteres Wachstum am Horizont, da 70 % der Umfrageteilnehmer einen Anstieg der Nutzung in den nächsten 24 Monaten planten.

Die Einführung eines serverlosen Modells ist für die Anwendungsentwicklung in mehrfacher Hinsicht von Vorteil:

  • Geringerer operativer Aufwand: Da keine Server verwaltet werden müssen, müssen sich Entwickler und DevOps nicht um die Skalierung der Infrastruktur, die Installation und Wartung von Agenten oder andere infrastrukturbezogene Vorgänge kümmern.
  • Erhöhte Agilität: Da serverlose Anwendungen in hohem Maße auf verwaltete Dienste für Dinge wie Datenbanken und Authentifizierung angewiesen sind, können sich die Entwickler auf die eigentliche Geschäftslogik der Anwendung konzentrieren, die typischerweise auf einem FaaS wie AWS® Lambda oder Google Cloud Functions läuft.
  • Geringere Kosten: Bei den meisten Diensten, die in serverlosen Anwendungen verwendet werden, zahlt der Kunde nur für die Nutzung. Bei AWS Lambda zum Beispiel zahlen die Kunden für die Ausführung ihrer Funktionen. Dies wirkt sich in der Regel erheblich auf die Kosten aus, da sie nicht wie bei virtuellen Maschinen für ungenutzte Kapazitäten bezahlen müssen.
Komponenten des severless Modells
Abbildung 1: Komponenten des severless Modells

 

Serverlose Anwendungen erfordern serverlose Sicherheit

Mit jedem größeren Fortschritt in der Softwareentwicklung und im IT-Betrieb verändern sich auch die Angriffsvektoren und Sicherheitsrisiken. In den Anfängen der Virtualisierung auf Containernmussten sich Sicherheitsexperten anpassen und neue Wege finden, um ihre Infrastruktur zu härten, zu verteidigen und zu verwalten. Das Konzept einer serverlosen Anwendung stellt einen der größten Paradigmenwechsel dar, den es im Bereich der Anwendungssicherheit je gab.

Traditionell schützen Organisationen ihre Anwendungen, indem sie sich auf Infrastruktur- und Netzwerk-basierte Tools verlassen. Sie würden den Datenverkehr mit einer Firewall überprüfen, versuchen, bösartige Aktivitäten mit einem Intrusion Detection System zu erkennen oder Anwendungen mit der RASP-Technologie (Runtime Application Self-Protection) schützen. Auch mit Containern können sich Organisationen bis zu einem gewissen Grad auf die Sicherheit der zugrunde liegenden Infrastruktur verlassen.

Eine serverlose Anwendung besteht aus verteilten Cloud-Diensten, die zusammenarbeiten, wie z.B. ein S3-Bucket, das eine Lambda-Funktion auslöst, die wiederum DynamoDB® auslöst. In dieser Architektur ist kein Platz für Firewalls, IDS/IPS-Tools oder jegliche Art von Instrumentierungsagenten oder serverbasierten Schutzmethoden. Anstatt sich auf Netzwerkinspektion und Zugriffskontrolllisten zu konzentrieren, verlagert das serverlose Modell den Schwerpunkt der Sicherheit auf IAM-Berechtigungen, verhaltensorientierten Schutz und starken Code.

Anwendung im severless Modell
Abbildung 2: Anwendung im severless Modell

 

Serverlose Angriffsvektoren

Die Einführung von Serverless Security verschafft Anwendungen einen großen Sicherheitsvorsprung, da sich Organisationen nicht mehr um die Sicherheit von Infrastruktur, Netzwerk oder Host kümmern müssen. Es sind jedoch neue Angriffsvektoren aufgetaucht, und bekannte Angriffe wurden für serverlose Umgebungen neu konzipiert. Werfen wir einen Blick auf ein Beispiel (die vollständige Liste finden Sie in der Top 12 Risks for Serverless Applicationsder Cloud Security Alliance):

Ereignisdaten-Injektion

Injection-Fehler in Anwendungen, die bisher zu den häufigsten Risiken gehören, wurden in vielen Leitfäden zur sicheren Codierung ausführlich behandelt. Auf einer hohen Ebene treten Injektionsfehler auf, wenn nicht vertrauenswürdige Eingaben direkt an einen Interpreter übergeben werden, bevor sie ausgeführt oder ausgewertet werden. Im Kontext der serverlosen Architektur sind Funktions-Ereignisdaten-Injektionen jedoch nicht strikt auf direkte Benutzereingaben beschränkt (z.B. Eingaben aus einem Web-API-Aufruf). Die meisten serverlosen Architekturen bieten eine Vielzahl von Ereignisquellen, die die Ausführung einer serverlosen Funktion auslösen können.

Beispiele für Injektionsquellen für Ereignisdaten sind:

  • Cloud-Speicherereignisse (z.B. AWS S3®, Azure Blob Storage, Google Cloud Storage)
  • NoSQL-Datenbankereignisse (z.B. AWS DynamoDB, Azure Cosmos DB®)
  • SQL-Datenbank-Ereignisse
  • Stream-Verarbeitungsereignisse (z. B. Amazon Kinesis®)
  • Code-Änderungen und neue Repository-Code-Commits
  • HTTP-API-Aufrufe

Jeder Ereigniseingang kann verschiedene Nachrichtenformate enthalten, und verschiedene Teile dieser Ereignismeldungen können von Angreifern kontrollierte oder anderweitig gefährliche Eingaben enthalten. Die Vielzahl von Ereignisquellen vergrößert die potenzielle Angriffsfläche und macht den Schutz von serverlosen Funktionen vor Injektionen von Ereignisdaten komplexer. Dies gilt insbesondere deshalb, weil serverlose Architekturen nicht so gut verstanden werden wie Webumgebungen, in denen Entwickler wissen, welchen Nachrichtenteilen nicht vertraut werden sollte (z. B. GET/POST-Parameter, HTTP-Header usw.).

Angriffsfläche für die Injektion von Ereignisdaten
Abbildung 3: Angriffsfläche für die Injektion von Ereignisdaten

 

Schutz von serverlosen Anwendungen

Effektive serverlose Sicherheit konzentriert sich auf die Gewährleistung der Code-Integrität, strenge Berechtigungen und Verhaltensanalysen.

  • Zugang und Berechtigungen: Pflegen Sie Least-Privileged-Zugriff für serverlose Funktionen und andere Dienste. Wenn zum Beispiel eine AWS Lambda-Funktion auf eine DynamoDB-Tabelle zugreifen muss, stellen Sie sicher, dass sie nur die spezifische Aktion ausführen kann, die die Geschäftslogik erfordert.
  • Scannen auf Schwachstellen: Stellen Sie die Integrität des Codes und der Infrastruktur-als-Code-Vorlage sicher, indem Sie regelmäßig nach anfälligen Abhängigkeiten von Drittanbietern, Konfigurationsfehlern und übermäßig zulässigen Rollen suchen.
  • Laufzeitschutz: Verwenden Sie den Laufzeitschutz, um böswillige Ereigniseingaben und anomales Funktionsverhalten zu erkennen, und schränken Sie bei Bedarf die Fähigkeit jeder Funktion ein, auf Dateien, Hosts und das Internet zuzugreifen und Kindprozesse zu starten.

 

Serverlose FAQs

Serverloses Computing, auch bekannt als serverlose Architektur, ist ein Ansatz für das Softwaredesign, der es Ingenieuren ermöglicht, Anwendungen zu erstellen und auszuführen, ohne die zugrunde liegende Infrastruktur verwalten zu müssen. Stattdessen provisionieren Cloud-Anbieter Server, auf denen Anwendungen, Datenbanken und Speichersysteme für digitale oder cloudnative Organisationen laufen.
Function-as-a-Service, ist ein Cloud-Computing-Dienst, der es Kunden ermöglicht, Code als Reaktion auf Ereignisse auszuführen, ohne die komplexen...
Bei der serverlosen Architektur handelt es sich um eine FaaS, bei der Entwickler den Anwendungscode in Form von einzelnen Funktionen schreiben, die als Reaktion auf HTTP-Anfragen oder ähnliche Ereignisse bestimmte Aufgaben ausführen. Sobald die Funktionen auf dem Konto des Cloud-Anbieters bereitgestellt sind, führt der Cloud-Anbieter die Funktion auf einem von ihm bereitgestellten Server aus.
Beispiele für serverlose Dienste, die von Cloud-Anbietern angeboten werden, sind Google Cloud Functions, AWS Lambda und Microsoft Azure Functions.
Zurück Cloud-Sicherheit ist eine geteilte Verantwortung
Weiter Was ist Policy-as-Code?