Risiken von Serverless Computing Lambda Security und Serverlose Angriffe
Anbieter zum Thema
Serverlose Implementierungen schaffen Effizienz, Flexibilität und Freiheit für Entwickler. Deutlich zeigt sich das an der Leistungsfähigkeit von Amazon Web Services (AWS) Lambda. Die Möglichkeit, neue Anwendungen schnell zu starten, ohne eine größere Infrastrukturverwaltung und einen höheren Overhead-Aufwand zu schaffen, eröffnet also Chancen – aber schafft neue Herausforderungen zugleich.

Mit Serverlosen Implementierungen wie AWS Lambda können Entwickler viel schneller als zuvor arbeiten und Code für jede Art von Anwendung oder Backend-Dienst skalieren. Eine Bereitstellung oder Serververwaltung ist nicht mehr erforderlich. Bei der Nutzung von serverlosen Anwendungen geben die Administratoren allerdings die Kontrolle über den größten Teil der Sicherheitsmodule an einen Cloud-Provider ab, im Guten wie im Schlechten. Sie besitzen keine Möglichkeit mehr zum OS Hardening, Admin-Rechte, SSH und Segmentation. Die Ausnahme, wo sie die Kontrolle behalten, ist die Konfiguration der Struktur und die genaue Anwendung – von dort aber muss die Sicherheit kommen.
Neue Angriffswege liegen offen
AWS Lambda verändert mit seinen serverlosen Funktionen, die kurzlebig sind und darum wenig Angriffsfläche bieten, die Art und Weise, wie Angreifer an diese Systeme herangehen. Zum einen starten sie kontinuierliche stateless (zustandlosen) Angriffe, bei denen sie eine oder mehrere Anwendungsschwächen gezielt ausnutzen. Damit versuchen sie einen kleinen Teil des Gesamtangriffs durchzuführen, und wiederholen den Vorgang so oft, bis der Angriff abgeschlossen ist.
Zum anderen umgehen sie den vorgelagerten Schutz mit Supply-Chain-Injection-Angriffen. Hierbei nutzen Angreifer die Abhängigkeit der Funktionen von Drittanbieter-Code aus, indem sie eines dieser Module suchen, das sich selbst nur unzureichend schützt und daher auf Sicherheitslösungen von Herstellern angewiesen ist. Der Angreifer injiziert dann seinen Code in dieses Modul und wartet darauf, dass der Angriff auf die Funktionen durchdringt.
Ziel ist es stets und bleibt es: Erfolgreiche Eindringlinge sollten nicht länger als ein paar Minuten in einem System bleiben können, bis sie entdeckt werden. Die Tatsache, dass Cloud-Anbieter absichtlich nur vage angeben, wie und wann sie serverlose Laufzeiten erneut verwenden, führt zu der Tatsache, dass die eigentlich kurzlebigen Funktionen in Wirklichkeit stunden- oder sogar tagelang in Betrieb sein können. Aufgrund dessen müssen Unternehmen davon ausgehen, dass ein Angreifer sicherlich einen Weg finden wird, um in einem System zu bleiben und größeren Schaden anzurichten, wenn er nicht gezielt daran von Sicherheitslösungen gehindert wird.
Nur eine Zeile veränderter Code hat fatale Auswirkungen
Ein Beispiel für eine mögliche Attacke: Wenn ein Angreifer eine Evaluations-Anweisung verändert. Im Grunde genommen kann er nur zusätzliche Zeilen in die jeweilige Tabelle einfügen. Der Schaden sieht auf den ersten Blick also gering aus, sogar dann, wenn der gefälschte Container noch länger so bestehen bleibt. Was aber wäre, wenn ein Angreifer seine Daten an eine Lambda-Funktion sendet?
Anstatt nur einige Zahlungsinformationen zu erhalten, injiziert dieser Workload tatsächlich etwas Code in die Funktion. Von nun an wird der Angreifer jedes Mal, wenn ein Benutzer seine Kreditkarteninformationen an die Anwendung weitergibt, eine Kopie davon erhalten. Wenn der Angreifer schlau ist, wird er versuchen, so viele Container wie möglich zu infizieren. Dies kann er dadurch erreichen, dass er diesen Angriff mehrere hundert Mal parallel sendet und dabei viele Container gleichzeitig fälscht.
Die Herausforderung besteht also darin, dass es eine einmalige Lastspitze von einer oder mehrerer Angriffs-Workloads gibt. Danach folgt nichts, was als bösartig eingestuft werden könnte. Unbemerkt könnten auf diese Weise über Stunden oder Tage sensible Daten abfließen, ohne dass der Administrator des Containers dies bemerkt.
Best Practices für Least Privilege
Sehr schwierig wird es, diese Herausforderungen zu bestehen, da IT-Sicherheit in gewisser Weise das Gegenteil der Software-Entwicklung ist. Sicherheit ist der Prozess der Begrenzung, während Software-Entwicklung schafft, erweitert und ermöglicht. Der Instinkt eines Entwicklers ist es, Hindernisse zu beseitigen. Ihm zu vermitteln, dass er sich einigen Beschränkungen der Sicherheit wegen unterwerfen soll, ist eine enorme Aufgabe für die Kommunikation. Ein Teil der AWS Lambda Security Best Practices beinhaltet daher, dass Entwickler darüber nachdenken sollten, was sie für ihre Prozesse eigentlich nicht brauchen und deshalb weglassen könnten. Außerdem einige zusätzliche Schwierigkeiten:
- Sicherheit braucht Zeit, Entwickler aber haben wenig Zeit.
- Die Sicherheit kommt den Entwicklern früher oder später in die Quere, also ist es für sie am einfachsten, eine Wildcard zu verwenden.
- Mangelnde Sichtbarkeit, um zu wissen, welche Berechtigungen die Entwickler überhaupt benötigen – und welche nicht – erschwert die Kontrolle.
- Mangelnde Granularität der Definition von Zugangsberechtigungen kompliziert die Bewachung der sensiblen Bereiche.
- Mangel an Bewusstsein oder Achtsamkeit für das Problem erschwert die Kommunikation.
- Zu viele Ressourcen werden gebunden.
Vorteile des Serverless Computings für die IT-Sicherheit
Serverlose Strukturen erfordern zwar eine komplette Umstellung des Sicherheitsansatzes, bringen aber eine Vielzahl von Möglichkeiten zur Schaffung besserer, granularer und kontextbezogener Sicherheit mit sich. Ein Vergleich mit Containern bietet sich an: Wenn ein großer Container viele Funktionen ausführt, dann müssen die Verantwortlichen ihn in die Lage versetzen, viele Dinge zu tun. Der Umstieg auf kleinere Mikrodienste ermöglicht es dagegen, feinkörnigeres Identity and Access Management einzusetzen, um genauer zu verwalten, wer einen Zugriff auf bestimmte Bereiche erhält. Noch wichtiger ist dabei, dass ein erfolgreicher Angreifer, der eine Schwachstelle in einer der Funktionen ausnutzt, nur Zugriff auf die begrenzten Möglichkeiten dieser Funktion erhält. Der große Bauchladen von Berechtigungen aus denen er in Ruhe wählen konnte, den jeder große Container vor sich her trug, bleibt ihm verwehrt.
Sicherheitsrichtlinien können also gezielt auf jede dieser kleinen Einheiten angewendet werden. AWS Lambda, wie die meisten Cloud-Anbieter, ermöglicht es den Unternehmen auf diese Weise, die Angriffsfläche ihrer IT-Systeme deutlich zu verkleinern.
Schutz durch einfache organisatorische Maßnahmen möglich
Noch mehr Sicherheit erreichen Unternehmen beim Betreiben von serverlosen IT-Systemen über Anbieter, wie AWS Lambda, mit den folgenden Ratschlägen:
- IT-Verantwortliche sollten den Entwicklern überzeugend vermitteln, von Beginn ihrer Arbeit an nur sicheren Code zu schreiben.
- Die Anwendungen sollten von modernen und an serverlose Strukturen angepasste Sicherheitslösungen spezialisierter Anbieter geschützt werden. Diese müssen unbedingt in der Lage sein, auch die sehr gefährlichen Zero-Day-Attacken zu blockieren.
- Der Einsatz von Sicherheitswerkzeugen, die Container jeder Größe zwingen, sich regelmäßig zu erneuern, bevor sie und ihre Funktionen zu lange leben, verkleinert die Angriffsfläche enorm.
Fazit: Serverless Computing sicher nutzen und profitieren
Letztlich stellen serverlose Architekturen einen sehr willkommenen technologischen Sprung nach vorn in der Software-Entwicklung dar. Sie stehen dabei gleichermaßen für Herausforderungen als auch Chancen bei der Absicherung von Anwendungen. Es ist daher von entscheidender Bedeutung, sämtliche Risiken für die IT-Sicherheit zu betrachten und stets die Augen offen zu halten. Die IT-Verantwortlichen müssen außerdem sicherstellen, dass durchgängig die richtigen Werkzeuge und Verhaltensweisen von allen Beteiligten eingesetzt und an den Tag gelegt werden, um die Systeme, Benutzer und Daten zu schützen.
Über die Autorin: Christine Schönig ist Regional Director Security Engineering CER bei Check Point Software Technologies.
(ID:46742896)