Tierney - stock.adobe.com
Serverless Computing: Typische Security-Fehler vermeiden
Sollen serverlose Anwendungen wirksam abgesichert werden, erfordert dies neue Abläufe, Überlegungen und auch Werkzeuge. Bei der Umstellung werden häufig typische Fehler gemacht.
Serverless Computing ist nicht nur eine neue Technologie, die vieles erleichtert, sondern sie erfordert auch ein Umdenken der IT-Sicherheit. Der bekannte und für aktuelle Architekturen klassische Weg zum Schutz der IT-Umgebungen funktioniert hier nicht mehr.
Daher besteht eine hohe Chance, dass viele Fachleute derzeit – zum Beginn der Umstellung auf serverlose Systeme – tatsächlich einige Fehler gemacht haben und machen. Sechs häufige Fehler, die einfach vermieden werden können, erklären wir im Folgenden.
Fehler 1: Die Web Application Firewall kümmert sich um alle Sicherheitsbelange sämtlicher Anwendungen
Traditionell befinden sich Web Application Firewalls (WAF) am Rande des Netzwerkperimeters, also direkt am Internetübergang raus aus der Firmenumgebung. Dort schützen sie Web- oder Anwendungsdienste, die lokal oder in der Cloud aufgesetzt werden.
Jedoch bedeutet das nicht, dass die WAF die vollständige Absicherung aller Anwendungen bewältigen kann. Sie ist lediglich in der Lage, HTTP(S)-Verkehr zu inspizieren und Funktionen zu schützen, die vom API-Gateway-ausgelöst wurden. Anders ausgelöste Ereignisse innerhalb des Cloud-Netzwerks bleiben dagegen weitestgehend ungeschützt.
Die WAF hilft daher nicht, wenn den Funktionen folgende Ereignisse vorausgehen:
- Cloud-Storage-Ereignisse (zum Beispiel AWS S3, Google Cloud Storage, Azure Blob Storage)
- Stream-Datenverarbeitung (zum Beispiel AWS Kinesis)
- Datenbankänderungen (zum Beispiel AWS DynamoDB, Azure CosmosDB)
- Code-Änderungen (zum Beispiel AWS CodeCommit)
- Benachrichtigungen (zum Beispiel SMS, E-Mails, IoT)
Die Schlussfolgerung lautet nicht, dass eine WAF als erste Verteidigungslinie nutzlos wäre – ganz im Gegenteil. Doch es darf nicht der Fehler unterlaufen, die WAF als Schutzprogramm zu verstehen, das sich um alles kümmert. Andernfalls klaffen gefährliche Sicherheitslücken im Netzwerk und diese kann nur eine spezialisierte Sicherheitslösung schließen.
Fehler 2: Unbearbeitete Funktionsberechtigungen
Richtlinien festzulegen, die mehr Spielraum lassen, als ihn die Funktion eigentlich benötigt, ist ein üblicher Fehler der serverlosen Sicherheit. Das Ziel aber sollte eine Politik der so gering wie möglich gehaltenen Zugriffsberechtigungen für Funktionen sein.
Wenn es nicht gelingt, die Wichtigkeit einzelner Funktionen und die Toleranz von Berechtigungen zu minimieren, wird die Angriffsfläche der IT-Architektur größer als nötig. Führungskräfte und Entwickler müssen sich zusammen jede der geschriebenen Funktionen anschauen und prüfen, was jede Funktion tut und welche Berechtigungen sie wirklich braucht. So lassen sich Rollen und Richtlinien präzise gestalten.
Fehler 3: Nicht jede Code-Zeile ist eine selbst geschriebene
Ein Irrglaube, der häufig zu Schwachstellen in serverlosen Systemen führt, besagt, dass jeder Code in einer Anwendung ein eigener ist, also selbst geschrieben. Dem ist mitnichten so.
Bei dem, was wir als Vergiftung des Brunnens (Poisoning the Well) bezeichnen, wollen die Angreifer durch einen vorgelagerten Angriff (Upstream-Attack) sich langfristig in einer Anwendung einnisten, denn: Cloud-native Anwendungen bestehen in der Regel aus vielen Modulen und Bibliotheken.
Die Module enthalten oft viele andere Module, weswegen es nicht ungewöhnlich ist, dass eine einzige serverlose Funktion in sich Zehntausende von Code-Zeilen aus verschiedenen externen Quellen vereint – selbst dann, wenn die eigenen Entwickler weniger als 100 Zeilen geschrieben haben.
Mittlerweile bestehen mehr als 70 Prozent der Anwendungs-Quellcodes aus Open-Source-Inhalten. Angreifer versuchen darum, ihren bösartigen Code in gemeinsame Projekte, wie denen auf der bekannten Open-Source-Webseite GitHub, einzubinden. Nachdem die Cyberkriminellen auf diese Weise sozusagen den Brunnen vergiftet haben, warten sie geduldig, bis die neue Version ihren Weg in die Cloud-Anwendungen findet. Viele Application Security Controls binden daher Werkzeuge, wie Source Code Analysis (SCA), früh in den Entwicklungsablauf ein.
Im Jahr 2017 veröffentlichte Black Duck Software, ein Unternehmen, das SCA-Lösungen vermarktet und verkauft, einen umfangreichen Bericht dazu. Forscher fanden heraus, dass von 1.000 häufig im Unternehmen verwendeten Anwendungen 96 Prozent Open-Source-Software verwenden und über 60 Prozent Sicherheitslücken aufgrund dieser Komponenten aufwiesen – einige der gefundenen Fehler waren zum damaligen Zeitpunkt über vier Jahre alt.
Fehler 4: Zu glauben, volle Kontrolle über alle Funktionen zu haben
Glauben ist gut, aber etwas zu wissen ist besser. Sich darauf zu verlassen, dass man alles im Griff hat, reicht bei serverlosen Systemen nicht. Zwar können Code-Schwachstellen durch sorgfältige Integration der Anwendungssicherheit in die CI/CD-Pipeline gemildert werden, aber es ist schwierig sicherzustellen, dass wirklich alle Funktionen das CI/CD durchlaufen.
Schädliche Funktionen können sich auf vielen Wegen – wie ein abtrünniger Mitarbeiter – einschleichen, was die Sicherung von serverlosen Anwendungen erschwert. Außerdem könnten die Workstations der Entwickler ein Ziel der Angreifer sein, statt der eingesetzten Anwendungen selbst.
Jedoch neigen Entwickler weniger dazu, anfällig für Phishing-Betrügereien zu sein als andere. Dennoch ist das sehr gefährlich: Der Zugriff auf eine Workstation würde es Angreifern ermöglichen, bösartige Funktionen über legitime Kanäle zu verbreiten. Solche Funktionen könnten unbemerkt arbeiten und verheerenden Schaden anrichten.
Fehler 5: Die falschen Anzeichen für einen Angriff im Blick
Sichtbarkeit ist ein wichtiges Schlagwort und Prinzip in der IT-Sicherheit geworden. Gemeint ist der klare Blick über alles, was im Netzwerk vor sich geht. Diese Sichtbarkeit aufrecht zu erhalten, wird mit serverlosen Systemen schwieriger. Die Umstellung erhöht die Menge von Informationen und die Anzahl der Ressourcen erheblich, weswegen viele Unternehmen die Daten kaum mehr umfangreich auslesen und sinngebend interpretieren können.
Die Gewinnung von Erkenntnissen aus diesem Datenberg ist also eine Herausforderung, und infolgedessen auch die Sicherung serverloser Anwendungen, denn: Da die Anzahl der Funktionen von Hunderten auf Tausende ansteigt, ist es schwieriger festzustellen, ob sich alles in den IT-Umgebungen so verhält, wie es soll.
Bereits ein paar hundert Funktionen können täglich Milliarden von Ereignissen im Protokoll hinterlegen. Hier die wirklich wichtigen und relevanten Signale herauszufiltern ist aufwendig.
„Die Sicherung von serverlosen Anwendungen erfordert eine Vielzahl neuer Werkzeuge, Abläufe und strategischer Überlegungen.“
Christine Schönig, Check Point
Sogar dann, wenn ein Unternehmen die geschulten Fachleute hat, die sich mit den Angriffsmustern bereits auskennen, die einzigartig für serverlose Anwendungen sind, ist das Erfassen und Zuordnen dieser Daten kompliziert – und nicht skalierbar.
Hier helfen künstliche Intelligenz und maschinelles Lernen. Sie machen den großen Unterschied aus, weil sie Wege finden, die Sicherheit in der Cloud automatisiert zu erhöhen, was die Geschwindigkeit stark erhöht und die Mitarbeiter entlastet.
Fehler 6: Funktionen ewig laufen lassen
Serverlose Funktionen sind eigentlich dazu gedacht, die Angriffsfläche dadurch zu reduzieren, dass sie nur eine kurze Lebensdauer haben und somit nur für kurze Zeit von Angreifern missbraucht werden könnten. Die Funktionen sollten darum ein straffes Laufzeit-Profil erhalten, obwohl es natürlich oft schwierig ist, das Ende einer Funktion genau zu terminieren. Doch ist eine gute Annäherung besser, als die Zügel schießen zu lassen.
Wie lange eine Funktion laufen sollte, lässt sich nicht auf alle Funktionen allgemein übertragen. Die maximale Lebenszeit einer Funktion kann sehr spezifisch für diese bestimmte Funktion sein. IT-Fachleute müssen daher das konfigurierte Ende mit dem tatsächlichen Ende im Vergleich betrachten. Um sich die Arbeit zu erleichtern setzen viele Entwickler die Zeitspanne auf die maximal zulässige Länge. Das jedoch ist keine kluge Entscheidung.
Wenn ein Angreifer mit einer Schadcodeinjektion erfolgreich ist, steht ihm unter diesen Umständen viel Zeit zur Verfügung, um die Funktionen zu seinen Zwecken zu nutzen und Schaden anzurichten. Bei kurzen Laufzeiten müssen die Verbrecher dagegen ständig erneut angreifen, was Sicherheitsexperten als Täglich-grüßt-das-Murmeltier-Angriff (Groundhog Day Attack) bezeichnen. Auf diese Weise wird die Attacke sehr auffällig und kann einfacher entdeckt werden – und gestoppt.
Ein Umdenken ist erforderlich
Die Sicherung von serverlosen Anwendungen erfordert eine Vielzahl neuer Werkzeuge, Abläufe und strategischer Überlegungen. Gewohnte Prozesse und Vorgehensweisen, selbst bekannte Sicherheitslösungen lassen sich nicht nahtlos auf die neue IT-Architektur übertragen.
Es gilt einen neuen Weg der IT-Sicherheit zu beschreiten, der jedoch am Ende mit vielen Vorteilen aufwartet – unter anderem einer stark reduzierten Angriffsfläche gegenüber klassischen IT-Infrastrukturen bei korrekter Einführung von serverlosen Systemen.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
