Serverless Security: Neue Herausforderungen beim Absichern von Anwendungen

Die digitale Transformation bringt Neuerungen mit sich – mitunter die, dass zunehmend mehr Anwendungen in der Cloud betrieben werden. Das bringt natürlich Vorteile mit sich: Der Wartungsaufwand beispielsweise sinkt deutlich, sodass auch Kosten sinken können. Doch gilt es, sich auch mit der IT-Sicherheit auseinanderzusetzen – und das machen wir für Sie in diesem Beitrag. Nachdem wir geklärt haben, was Serverless-Anwendungen und Cloud Computing überhaupt sind, besprechen wir auch die Vor- und Nachteile von Serverless Security. Nachdem wir häufigen Fehlern auf die Spur gekommen sind, geben wir konkrete Empfehlungen und Best Practices-Ansätze an Sie weiter.

Serverless Security: Was ist damit gemeint?

Als serverlose Funktionen bezeichnet man Codesnippets, die ereignisbasiert in vollständig verwalteten Infrastrukturen ausgeführt werden. Mit Serverless-Architekturen ist es möglich, komplexe Anwendungssysteme aufbauen zu können – und zwar ohne sich ums Managen der Infrastruktur kümmern zu müssen: Cloud-Provider übernehmen Aspekte wie Skalierung, Verfügbarkeit oder Provisionierung. Um serverlose Anwendungen abzusichern, braucht es eine Vielzahl neuer Abläufe, strategischer Überlegungen sowie Werkzeuge. Bauen Anwendende weiter auf altbekannte Prozesse oder Vorgehensweisen, ist die Sicherheit langfristig nicht mehr gewährleistet.

Eine Anwendung besteht in der Serverless-Welt zumeist aus Hunderten von Funktionen. Jede von ihnen ist für sich genommen relativ einfach, im Zusammenspiel jedoch ergibt die Anwendung ein Gesamtsystem meist komplexerer Natur. Wie Sie schon in dieser Einführung zur Serverless Security sehen, ergeben sich aus diesem Prinzip viele Vor-, aber auch Nachteile bezüglich der IT-Sicherheit.

Die Vorteile von Serverless Security

Kommen wir zunächst zu den Pluspunkten der Serverless Security: Da sich Cloud-Provider um die Sicherheit der Cloud-Server, des Betriebssystems, um die Laufzeit und um das Patchen kümmern, stehen Nutzenden deutlich mehr Ressourcen zur Verfügung – das ist der wohl sichtbarste Vorteil. Ein weiterer ist die mögliche Feinkonfiguration: Serverlose Architekturen schrauben die Anzahl möglicher Funktionen wesentlich in die Höhe. Das hat zur Folge, dass auch etliche Rollen durch ein Identity and Access Management (IAM) festgelegt werden können. Das mag vielen Organisationen zunächst nicht unbedingt vorteilhaft erscheinen. Jedoch gelingt es durch die Wahl passender Tools und Prozesse, um jede Funktion sogenannte „Shrink Wrapped Permissions“ zu bauen. Damit ergibt sich eine Weiterentwicklung des Zero Trust-Ansatzes: Jede Funktion kann ausschließlich auf jene Ressourcen bzw. Dienste zugreifen, die ihr gestattet werden. Bei richtiger Konfiguration verhindert dieses „Least Privilege Principle“ zahlreiche Cyberangriffe auf Anwendungen.

In der Praxis kann die Vielzahl an Rechten Verwirrung stiften und wird gerne mit einer allowAll-Policy umgangen. Übergreifende Recht sind jedoch nicht Sinn der Sache, denn mit diesen würden die Tore für Angriffe geöffnet werden. Besser ist das Finden passender – nämlich minimaler – Berechtigungen; der Aufwand lohnt sich! Ändert sich beizeiten die Logik von Funktionen, können die Rechte jederzeit angepasst werden. Dieses Least Privilege Principle sollte auch für den Zugriff auf Third Party-Systeme aus der Cloud heraus greifen: Es werden Rollen mit minimalen Berechtigungen erstellt und den entsprechend zugreifenden Serverless Functions zugewiesen.

Bestehende Konzepte zeichnen sich oft durch große Container aus, die vollgestopft sind mit Vollmachten und Zugriffsrechten. Bei der Serverlosen Architektur hilft ein Umdenken: Funktionen in hoher Anzahl sorgen dafür, dass die Wirkung jeder einzelnen recht begrenzt ist – jeder Funktion wird ausschließlich eine kleine Aktion zugestanden. Somit existieren die kleinen Funktionen sehr kurz bevor sie anschließend neu geladen werden. Daraus ergibt sich der Vorteil, dass Angreifende Funktionen nur sehr kurz missbrauchen können, bevor sie wieder verschwinden. Daher gilt es, die Lebensspanne von Funktionen so kurz wie möglich zu konfigurieren, sodass viele Angriffe fast schon unmöglich gemacht werden.

Die Kehrseite dieser Medaille ist, dass auch Angreifende dazulernen: Bei kurzen Laufzeiten greifen Cyberkriminelle ständig erneut an. Dies wird als „Täglich-grüßt-das-Murmeltier-Angriff“ bzw. „Groundhog Day Attack“ bezeichnet. Attacken dieser Art sind sehr auffällig, sodass das Entdecken und entsprechende Stoppen recht einfach erfolgen kann.

Durch die Protokolle der einzelnen Mikrodienste erhöht sich die Transparenz. Weiter haben Kontrollprogramme deutlich mehr Möglichkeiten, etwaige Anomalien aufzuspüren. Sicherheitsteams wird also ermöglicht, Anomalien zügiger zu entdecken und gegenzusteuern.

Die Nachteile von Serverless Security

Doch Serverless Security hat auch mit Nachteilen zu kämpfen: Etwa das Mehr an Protokollen, denn die entstehende Transparenz kann vor- und nachteilig eingeschätzt werden. Die entstehende Transparenz ist zweifellos ein Vorteil, der Weg dahin führt jedoch über viele, viele Protokolle: Hunderte Funktionen bedeuten Hunderte Protokolle. Dafür existieren jedoch Lösungen – mitunter XDR; ein Sicherheitskonzept, mit dem es gelingt, eine große Menge an Informationen sinnvoll zu bewerten. Weitere Informationen dazu erhalten Sie in unserem Blogbeitrag „XDR: Extended Detection and Response“.

Viele Funktionen können auch die Angriffsfläche selbst erhöhen, denn somit ergeben sich zahlreiche Einstiegspunkte für Angreifende. Davon sind einige für Hacker leichter zugänglich als andere. Die feingranularen Berechtigungskonzepte jedoch bringen maximale Kontrolle für die Funktionen, sodass ein effizientes IAM die Angriffsfläche wieder verkleinern kann.

Ein Nachteil kann auch sein, dass feste Firmen-Perimeter sowie Rechenzentren als Grenzen der Firmen-IT wegfallen. Bislang war das Innere und das Äußere eines Firmennetzwerks fest definiert – Serverless Security ändert diese Auffassung. Liegen die Grenzen in jeder Funktion? In jeder Ressource? – Hier gilt es, zu definieren, nicht zuletzt, um Rechtsfragen zu klären.

Die häufigsten Fehler bei Serverless Security

Damit die Vorteile auch als solche verstanden werden können, gilt es, einige typische Fehler zu vermeiden. So wird beispielsweise oft angenommen, die Web Application Firewall (WAF) würde sich um die Sicherheit sämtlicher Anwendungen kümmern. Die WAF befindet sich klassischerweise am Internetübergang hinaus aus der Firmen-Infrastruktur. Sie schützt Web- sowie Anwendungsdienste, sichert jedoch nicht alle Anwendungen ab. Die WAF dient der Inspektion des HTTPS-Verkehrs und schützt Funktionen, die vom API-Gateway ausgelöst wurden. Wurden Ereignisse im Cloud-Netzwerk anderweitig ausgelöst, sind sie nicht durch die WAF geschützt. Die WAF darf also nicht als einziges Schutzprogramm verstanden werden; Sicherheitslücken im Netzwerk lassen sich mit spezialisierten Sicherheitslösungen schließen.

Ein zweiter häufiger Fehler sind unbearbeitete Funktionsberechtigungen – die in den Vorteilen bereits angesprochenen Berechtigungen. Funktionen sollten nicht mehr Spielraum haben, als sie eigentlich benötigen – oder andersherum: Halten Sie Zugriffsberechtigungen für Funktionen so gering wie möglich. Schauen Sie sich jede einzelne der Funktionen an, prüfen Sie, was diese macht und welche Berechtigungen dafür notwendig sind. So können Sie die Rollen und Zugriffsberechtigungen präzise konfigurieren – und Anpassungen sind im Nachhinein weit weniger aufwendig.

Um Serverless Security einführen zu können, müssen Organisationen weiter verstehen, dass der Code von Anwendungen nicht zwangsläufig ein selbst geschriebener sein muss. Cloud-Anwendungen bestehen zumeist aus zahlreichen Modulen und Bibliotheken. Ein Modul inkludiert häufig zahlreiche weitere Module, sodass deutlich wird: Eine einzelne serverlose Funktion vereint Zehntausende Codezeilen, die aus verschiedenen Quellen stammen. Viele Anwendungsquellcodes bestehen aus Open Source-Inhalten. Angreifende versuchen immer häufiger, bösartigen Code in Community-Projekte einzubinden. Das kann über Open Source-Websites wie GitHub durchaus gelingen. Findet dann die neue Version ihren Weg in Cloud-Anwendungen, kommt der bösartige Code mit. Werkzeuge wie Source Code Analysis (SCA) – frühzeitig in den Entwicklungsprozess eingebunden – können hier eine Lösung darstellen.

Ein weiterer häufig anzutreffender Fehler ist es, den falschen Anzeichen für Angriffe zu trauen. Wie in den Vor- und Nachteilen der Serverless Security beschrieben, erhöht das Prinzip die Sichtbarkeit und Transparenz. Da sich die Menge an Informationen massiv erhöht, haben einige Unternehmen kaum noch Möglichkeiten, die Daten umfangreich auszulesen und sinnvoll zu interpretieren. Künstliche Intelligenz (KI) und maschinelles Lernen (ML) helfen: Sie können die Sicherheit in der Cloud automatisiert erhöhen und Mitarbeitende beim Auswerten von Protokollen effizient unterstützen.

Empfehlungen für Serverless Security

Verfolgen Sie zum Erhöhen der Sicherheit den Zero Trust-Ansatz: Zugriffsrechte werden fest beschränkt, das Unternehmensnetzwerk wird segmentiert. So lassen sich Schäden, die nach erfolgreichen Angriffen folgen, limitieren. Weiterführende Informationen finden Sie in unserem Artikel „Zero Trust: Kein blindes Vertrauen für mehr Sicherheit“.

Mit Tools zur Code-Analyse (SCA, s. o.) können Sie eigenen sowie fremden Code überwachen. So bewahren Sie ein Grundmaß an Sicherheit und verhindern das Einschleusen von Schadcode. Setzen Sie zudem ergänzend auf XDR, können Sie Ihre gesamte IT-Infrastruktur zum Teil KI-basiert automatisiert überwachen lassen.

Serverless Security: Ein neuer Weg mit neuen Konzepten

Sie sehen: Serverless Security ist ein spannender Ansatz, der jedoch ein Umdenken verlangt: Weg von starren Unternehmensgrenzen hin zu einer Vielzahl serverloser Funktionen, die Schutz bedürfen. Verlassen Sie sich nicht nur auf die vollmundigen Werbeversprechen von Cloud-Providern, sondern prüfen Sie verschiedene Möglichkeiten. Passen Sie auch Ihre IT-Sicherheitsstrategie der neuen Architektur an – und arbeiten Sie von Beginn an so genau wie möglich, denn nur dann ist bei serverlosen Funktionen auch Sicherheit mit an Bord.