Sicherheitsauswirkungen von Serverless – von der Infrastruktur bis zu OWASP

Serverless (FaaS) begegnet naturgemäß einigen der größten Sicherheitsbedenken unserer Zeit. Da die Infrastrukturverwaltung entfällt, werden die damit verbundenen Sicherheitsaufgaben an den Plattformanbieter übertragen. Angreifer geben jedoch nicht einfach auf, sondern passen sich an die neue Welt an. Genauer gesagt verlagert FaaS den Fokus von Servern auf die von OWASP hervorgehobenen Sicherheitsprobleme auf Anwendungsebene – und Verteidiger sollten ihre Prioritäten entsprechend anpassen.

In diesem Beitrag geht es darum, bei welchen Sicherheitsproblemen Serverless hilft und bei welchen nicht. Jede dieser Stichpunktkategorien wäre wahrscheinlich einen eigenen Beitrag wert (den ich vielleicht später schreibe!). Hier halte ich mich jedoch mit Details zu Abhilfemaßnahmen und Risikomanagement zurück und konzentriere mich auf das Gesamtbild.

Hier ein kurzer Überblick über die kritischen Bereiche.

Sehen wir uns nun die Details an!

Wie hilft Serverless der Sicherheit?

Serverless überträgt die Verantwortung für die Serververwaltung vom Anwendungsverantwortlichen auf den Plattformanbieter. Diese lästigen Server sind bekanntermaßen schwer abzusichern, doch die Experten, die die Plattformen verwalten, beherrschen das sehr gut. Deshalb werden im Folgenden die drei größten Sicherheitsbedrohungen aufgeführt, die Serverless deutlich mindert.

1. Keine ungepatchten Server, keine anfälligen Binärdateien

Vor allem aber beseitigt Serverless praktisch die Hauptursache erfolgreicher Exploits: ungepatchte Server. Auf solchen Servern laufen Binärdateien mit bekannten Schwachstellen, weil die neuesten Sicherheitsupdates für diese Abhängigkeiten nicht installiert wurden. Nach den meisten Schätzungen sind Abhängigkeiten mit bekannten Schwachstellen heute für die große Mehrheit erfolgreicher Exploits verantwortlich.

Serverless macht es zwar nicht überflüssig, Ihre Server aktuell zu halten, überträgt diese Aufgabe aber an den Plattformanbieter. Die Serververwaltung gehört zu dessen Kernkompetenzen, daher ist die Wahrscheinlichkeit gering, dass die Systeme nicht auf dem neuesten Stand sind.

2. Denial-of-Service wird zum Abrechnungsproblem

Denial-of-Service-Angriffe verhindern, dass ein Server legitime Anfragen verarbeitet, und werden so lange wiederholt, bis alle Server, die eine Anfrage bearbeiten können, nicht mehr verfügbar sind. Bei FaaS werden Server bedarfsgerecht bereitgestellt und wieder verworfen (plattformabhängige Leistungsoptimierungen lasse ich hier außer Acht). Dadurch verliert die Vorstellung, „einen Server lahmzulegen“, ihre Bedeutung. Sobald eine neue Anfrage eintrifft – ob legitim oder nicht –, stellt die Plattform einen Server bereit und führt die angeforderte Funktion aus.

Dabei ist zu beachten: Serverless beseitigt DoS zwar konzeptionell als Bedrohung für die Verfügbarkeit, Plattformen setzen jedoch bestimmte Parallelitätslimits. AWS Lambda begrenzt die Zahl standardmäßig derzeit auf 600 gleichzeitig ausgeführte Funktionen. Außerdem kann ein DoS-Angriff weiterhin eine enorme Nutzungsrechnung verursachen – fast so unangenehm wie der Angriff selbst. Unterschätzen Sie daher weder die Ausführungszeit noch ReDoS-Schwachstellen.

3. Unveränderlichkeit verhindert kompromittierte Server

Bei vielen Angriffen ist das Ausnutzen einer Schwachstelle lediglich der erste Schritt. Statt die Angriffe zu wiederholen, versuchen Angreifer, den Server zu kompromittieren und dort einen Schadagenten zu installieren, um von dort aus weitere und tiefgreifendere Angriffe durchzuführen. Zu den verheerendsten Angriffen zählen die Datenschutzverletzungen bei Sony und Target, bei denen solche kompromittierten Server eine Rolle spielten.

Bei FaaS sind Server unveränderlich und kurzlebig. Dadurch entfällt automatisch die Möglichkeit, dass ein kompromittierter Server über längere Zeit bestehen bleibt. Dieser Schutz verringert zwar kaum die Wahrscheinlichkeit eines erfolgreichen Angriffs, schränkt aber die Möglichkeiten nach einem Exploit erheblich ein – und damit auch den möglichen Schaden.

Welche Sicherheitsprobleme bleiben unverändert?

Wie wir gesehen haben, nimmt Serverless Anwendungsverantwortlichen einige große Bedrohungen ab. Bedeutet das, dass Angreifer einfach auf Anwendungen auf Serverless-Basis verzichten? Natürlich nicht.

Hier sind die drei wichtigsten Sicherheitsprobleme, bei denen Serverless nicht hilft. FaaS verschärft diese Probleme zwar nicht, aber durch den Wegfall der zuvor genannten Bedrohungen rücken sie auf der Prioritätenliste der Angreifer ganz nach oben. Daher ist es wichtiger denn je, diese Risiken zu beachten und zu beheben.

4. Schwachstellen in Ihrem Code bleiben bestehen

Serverless nimmt Ihnen den größten Teil der „Umgebungsgeräusche“ ab, doch Ihr eigener Code bleibt – einschließlich seiner Schwachstellen. Schwachstellen auf Anwendungsebene (z. B. Cross-Site-Scripting, SQL-Injection) bleiben bei Ausnutzung gravierend. Abhilfemaßnahmen (z. B. Eingabevalidierung, programmgesteuerter Datenbankzugriff) sind nach wie vor entscheidend.

Die Best Practices bleiben dieselben wie zuvor. Verwenden Sie statische (SAST) und dynamische (DAST) Sicherheitstests, erleichtern Sie die Eingabevalidierung und bevorzugen Sie nach Möglichkeit Positivlisten usw. Der OWASP Top Ten-Leitfaden enthält viele hilfreiche Empfehlungen zu diesem Thema, ebenso wie das Cheat Sheet.

5. Anfällige Anwendungsabhängigkeiten sind enthalten

Auf den ersten Blick scheinen FaaS-Funktionen nur aus Ihrem Code zu bestehen – das stimmt jedoch nicht ganz. Funktionen enthalten auch Anwendungsabhängigkeiten, die von npm (Node.js), PyPI (Python), Maven (Java) oder anderen relevanten Plattformen eingebunden werden. Diese Codepakete sind wie kleine Infrastrukturkomponenten, die in Ihre Anwendung integriert sind.

Anwendungsabhängigkeiten ähneln den häufig ausgenutzten Serverabhängigkeiten. Sie sind weit verbreitet und werden monatlich milliardenfach heruntergeladen. Es ist schwierig nachzuverfolgen, welche Pakete Sie verwenden, und sie weisen häufig Schwachstellen auf, die regelmäßig neu bekannt werden. Angreifer nutzen bereits anfällige Anwendungsabhängigkeiten aus. Da ihnen der einfache Weg über anfällige Serverabhängigkeiten verwehrt bleibt, werden sie diese ähnlichen Ziele mit voller Kraft angreifen.

Bekannte Schwachstellen lassen sich für Sie genauso leicht aufspüren wie für Angreifer. Um Anwendungsabhängigkeiten abzusichern, benötigen Sie Zugriff auf eine gute Datenbank und automatisierte Tools, die kontinuierlich verhindern, dass neue anfällige Pakete hinzukommen, und Sie über neu bekannt gewordene Probleme informieren. Snyk macht diesen gesamten Prozess denkbar einfach – ich empfehle Ihnen, es auszuprobieren! Alternativ wählen Sie das Tool, das am besten zu Ihnen und Ihrer Plattform passt. Vernachlässigen Sie dieses Problem jedoch nicht.

6. Daten im Ruhezustand sind genauso zugänglich

Nicht zuletzt hält Serverless Angreifer nicht von Ihrer Datenbank fern. Erlangt ein Angreifer über eine der oben genannten Schwachstellen, durch offengelegte Zugangsdaten, einen kompromittierten Insider oder auf anderem Wege Zugriff auf Ihre Daten, hat FaaS darauf keinerlei Einfluss.

Wenn Sie sensible Informationen speichern, sollten Sie sie unbedingt ordnungsgemäß verschlüsseln. Open-Source-Kryptografiealgorithmen sind allgemein verfügbar, und es gibt keinen guten Grund, sie nicht zu nutzen. Vermeiden Sie außerdem die Versuchung, allen Zugriff auf Ihre Datenbank zu gewähren (selbst Lesezugriff!), und beschränken Sie ihn stattdessen auf die Personen und Systeme, die ihn am dringendsten benötigen. FaaS ermöglicht hier eine feinere Granularität, indem der Zugriff auf die Funktionen beschränkt wird, die unmittelbar mit der Datenbank arbeiten. Machen Sie Ihre Datenspeicher schließlich nicht direkt über das Internet zugänglich. Wie die jüngsten Vorfälle mit MongoDB und die ausdrücklichen Hinweise von Redis gezeigt haben, sind diese Systeme für den internen Einsatz konzipiert.

Ich habe dieses Problem als „unverändert“ eingestuft, da Serverless der Datensicherheit im Ruhezustand nicht schadet. Da Funktionen jedoch immer zustandslos sind, werden Zustände – einschließlich der darin gespeicherten sensiblen Daten – in manchen Fällen von einem lokalen Speicher (z. B. Dateisystem oder Arbeitsspeicher) in einen Netzwerkspeicher (z. B. Redis oder Warteschlangen) verschoben. Wenden Sie auf solche temporären Speicher dieselben Datenschutzmaßnahmen an wie auf dauerhafte Speicher wie eine Datenbank.

Welche Sicherheitsprobleme verschärft Serverless?

Serverless schafft keine neuen Sicherheitsprobleme, verstärkt jedoch einige davon. Die dadurch begünstigte Architektur führt dazu, dass wir bestimmte Vorgehensweisen häufiger nutzen – und damit auch die darin enthaltenen Sicherheitsprobleme stärker in den Vordergrund rücken. Sehen wir uns die drei wichtigsten Bereiche an, in denen Serverless die Sicherheit erschwert.

7. Drittanbieterdienste und Daten während der Übertragung

FaaS führt nicht dazu, dass Sie mehr Daten speichern, aber ganz sicher dazu, dass Sie mehr Daten übertragen. Daten, die traditionell auf dem Rechner blieben, werden nun häufig zwischen Funktionen hin- und hergeschickt und zwischen einzelnen Aufrufen leicht verändert. Darüber hinaus führt die Granularität und Zustandslosigkeit zu einer verstärkten Nutzung von Drittanbieterdiensten, wodurch Daten erneut über das Netzwerk gesendet und empfangen werden müssen.

Bei jeder Datenübertragung besteht das Risiko, dass Daten offengelegt oder manipuliert werden. Außerdem vertrauen wir bei jeder Kommunikation implizit darauf, dass die andere Partei mit den gesendeten und empfangenen Daten verantwortungsvoll umgeht. Das eröffnet die Möglichkeit, dieses Vertrauen zu missbrauchen. Da wir bei FaaS häufiger kommunizieren, müssen wir diesem Risiko mehr Aufmerksamkeit schenken und uns besser dagegen schützen.

Datensicherheit ist ein weites Feld, doch ich empfehle, sich auf zwei Bereiche zu konzentrieren: Verschlüsselung und Vertrauen. Verschlüsseln Sie zunächst alle Daten mit HTTPS oder Schlüsseln und einem KMS. Beide Verfahren ermöglichen außerdem eine gewisse Überprüfung der Identität Ihres Kommunikationspartners. Zweitens sollten Sie allen Eingaben aus einer Funktion oder einem Dienst misstrauen, mit dem Sie kommunizieren – selbst wenn es sich um eine andere Funktion handelt. Vertraut eine Funktion einer anderen implizit, ganz zu schweigen von einem Drittanbieterdienst, entsteht schnell eine fragile Kette, die zusammenbricht, sobald eine Komponente bösartig oder kompromittiert wird.

8. Mehr Flexibilität führt zu einer größeren Angriffsfläche

Einer der größten Vorteile von Serverless ist die Flexibilität: Der Kontrollfluss lässt sich auf den Client verlagern, und zusätzliche Anwendungsfälle können unterstützt werden, ohne den serverseitigen Code anzupassen. Mehr Flexibilität bedeutet jedoch auch mehr Möglichkeiten für Angreifer, Ihr System zu unbeabsichtigten Aktionen zu bringen. Wie Mark Nunnikhoven es treffend formuliert: „Entwickler konzentrieren sich darauf, ein Problem zu lösen. Sicherheit betrachtet, wofür diese Lösungen sonst noch verwendet werden können.“

Die einzige Möglichkeit, diesem Problem zu begegnen, besteht darin, jede Funktion als eigenen Sicherheitsbereich zu behandeln. Das bedeutet, dass jede Funktion Eingaben und Ausgaben bereinigen, ihre Daten schützen und ihren Code sowie ihre Abhängigkeiten absichern muss. Die meisten Systeme haben heute einen klar abgegrenzten Sicherheitsbereich, aber ein offenes Inneres. FaaS erweitert diesen Bereich erheblich und erfordert dadurch ein breiteres Spektrum an Schutzmaßnahmen.

Zum Glück bietet FaaS zwei hervorragende Möglichkeiten, einen solchen umfassenden Schutz umzusetzen. Erstens sind Funktionen von Natur aus kleiner. Dadurch lässt sich – wenn auch nicht ohne Weiteres – genauer festlegen, was sie tun dürfen und was nicht. Diese Vorgaben können dann im Code und in Unit-Tests durchgesetzt werden. Zweitens werden Funktionen typischerweise über das API-Gateway von externen Parteien aufgerufen. Dort können Sie ein Modell oder Schema für den Aufruf definieren, das strengere Einschränkungen für zulässige Eingaben und Ausgaben ermöglicht. Nutzen Sie diese Möglichkeiten und sichern Sie jede Funktion einzeln ab.

9. Sicherheitsüberwachung wird extrem schwierig

Serverless macht die Bereitstellung von Code unglaublich einfach. Eine Funktion in der Produktion bereitzustellen, ist praktisch kostenlos, und die Ausführungskosten sind so gering und kleinteilig, dass eine Funktion mit wenig Aufrufen auf Ihrer Rechnung kaum auffällt. Es gibt also keinen finanziellen Anreiz, eine Funktion nicht bereitzustellen oder sie nach der Bereitstellung wieder zu entfernen. Erschwerend kommt hinzu, dass sich nur schwer nachvollziehen lässt, wer eine Funktion nutzt. Dadurch ist es riskant, sie nach der Bereitstellung zu entfernen, und es kann passieren, dass Tausende selten genutzte Funktionen bereitgestellt werden.

Die geringere Hürde für Deployments steigert die Produktivität erheblich, schafft aber auch einen Albtraum für die Sicherheit. Jede bereitgestellte Funktion ist ein potenzielles Angriffsziel und kann Schwachstellen enthalten, über die Angreifer in Ihre privaten Netzwerke eindringen, Ihre Datenbank manipulieren oder in Ihrem Namen Angriffe ausführen können. Die in diese Funktionen eingebundenen Anwendungsabhängigkeiten veralten mit der Zeit, und neue Schwachstellen werden darin entdeckt – so lassen sich solche Exploits leicht automatisieren. Die Komplexität der Überwachungssysteme ist der Grund dafür, dass sich anfällige Abhängigkeiten so leicht ausnutzen und so schwer verhindern lassen.

Hinzu kommt, dass vorhandene Sicherheitsüberwachungslösungen in einer Serverless-Umgebung nicht funktionieren. Die meisten dieser Lösungen benötigen einen Agent auf dem (nun nicht mehr vorhandenen) langlebigen Server, verursachen beim Start und während der Laufzeit einen für FaaS zu hohen Overhead und lassen sich nicht nach Bedarf so skalieren wie Serverless-Plattformen. Außerdem sind diese Lösungen logisch um eine End-to-End-Anwendung herum aufgebaut. Ihre Logik und Benutzeroberfläche sind nicht für die extreme Granularität von Serverless ausgelegt.

Diese Herausforderung betrifft das gesamte Ökosystem und erfordert neue Lösungsansätze. Behalten Sie genau im Blick, welche Funktionen bereitgestellt werden, wer sie nutzt und welche Abhängigkeiten sie verwenden. Auch wenn die Betriebskosten einer Funktion niedrig sind, sollten Sie die Gesamtbetriebskosten berücksichtigen – einschließlich des erhöhten Risikos, dass ungenutzter, anfälliger oder veralteter Code in der Produktionsumgebung verbleibt.

Langfristig müssen sich Laufzeitüberwachungslösungen für die Sicherheit weiterentwickeln und an den Betrieb ohne Agents, mit geringem Overhead und in massiv skalierbarem Umfang anpassen. Wir brauchen außerdem Alternativen zu Infrastrukturüberwachungslösungen, mit denen sich anfällige Anwendungsabhängigkeiten über alle Funktionen hinweg nachverfolgen lassen und die Sie dabei unterstützen, problematische Funktionen zu aktualisieren oder zu entfernen. Wir bei Snyk leisten unseren Beitrag und arbeiten daran, unsere CI/CD-Lösung für anfällige Anwendungsabhängigkeiten so zu erweitern, dass sie bereitgestellte Funktionen direkt überwacht – geben Sie uns Bescheid, wenn Sie an der Beta teilnehmen möchten!

Zusammenfassung

Serverless ist großartig und revolutioniert die Art und Weise, wie wir Anwendungen betreiben. Gleichzeitig bringt Serverless einen ähnlich tiefgreifenden Umbruch für die Sicherheit mit sich: Bestimmte Sicherheitsprobleme werden behoben, andere verschärft und die Prioritäten für alle übrigen neu geordnet. In diesem Beitrag habe ich versucht, die drei wichtigsten Bereiche zusammenzufassen, in denen FaaS im Vergleich zu anderen Cloud-Computing-Techniken besser, gleichwertig oder schlechter für die Websicherheit ist. Die folgende kurze Tabelle fasst sie zusammen:

Da Serverless noch neu ist, haben wir die Chance, Sicherheitspraktiken und -tools zu einem selbstverständlichen Bestandteil der Entwicklung von Serverless-Anwendungen zu machen. Ich persönlich freue mich darauf, zu sehen, wie Serverless sein enormes Potenzial sowohl für den Betrieb als auch für die Sicherheit entfaltet.