Im Sturm erobert das neue Konzept einer IT-Architektur, die ohne klassisches Server-Modell auskommt, die Unternehmen. Dennoch gibt es viele, die vor der Idee zurückschrecken. Grund genug für eine genaue Erklärung.
Häufig kommt die Idee, serverlose Architekturen einzuführen, auf den Tisch, wenn Entwickler in Unternehmen erkennen, dass klassische Container-Systeme durch die Mikro-Funktionen des neuen Konzepts unterstützt würden. Der Unterschied besteht darin, dass bisher viele Funktionen, also Befehle, in einem Container zusammengefasst werden und dieser Container damit viele Zugriffsrechte, wie auch Handlungsmöglichkeiten, in sich vereint – für Angreifer ein gefundenes Fressen. Nun aber werden Funktionen einzeln erstellt und können nur die eine Tätigkeit durchführen, für die sie geschaffen wurden, sodass Hacker nur diese eine Funktion in die Hände bekommen, nicht aber eine große Sammlung. Außerdem sind diese Mikrofunktionen sehr kurzlebig, bevor sie nicht mehr funktionieren und automatisch neu erschaffen werden, was den Angriff eines Hackers ebenfalls enorm erschwert. Container dagegen bestehen sehr lange. Viele Fachleute hören in genanntem Zusammenhang zum ersten Mal von Serverless Computing und für sie sind es verständlicherweise böhmische Dörfer. Doch es verbirgt sich ein enorm leistungsfähiges Konstrukt dahinter.

Was Serverless Computing ist

Im Grunde genommen ist der Begriff Serverless, also serverlos, eine Fehlbezeichnung, denn es ist natürlich ein Server in jeden Funktionsaufruf der IT-Architektur eigebunden. Was also ist Serverless tatsächlich? Es ist eine neue Stufe in der Entwicklung von Mikro-Funktionen, der es gelingt, die Prinzipien der raschen Implementierung und Infrastructure-as-Code auf Funktionsebene zusammenzubringen. Auf diese Weise lassen sich die Funktionen und ihre Auswirkungen wesentlich genauer bestimmen, als in den bisher genutzten, service-orientierten Konzepten. Daher nannten sich frühe Ausführungen dessen, was nun als Serverless Computing um die Welt geht, Functions-as-a-Service (FaaS). Diese gingen aus den ähnlich gestalteten Vorgängern hervor, die sich Backend-as-a-Service (BaaS) nannten und deren Ziel es bereits gewesen war, die IT-Infrastruktur zu verkleinern, die nötig ist, um eine Anwendung auf den Markt zu bringen.

Die Entwicklung des Konzepts reagiert also von Beginn an auf zwei Bedürfnisse der Unternehmenslenker: Erstens, so schnell, wie möglich, einen Markt für das neue Produkt finden zu können und daher zweitens, den Aufwand zu reduzieren, der bis zur Marktreife eines Produkts betrieben werden muss. Serverless antwortet darauf mit einer On-Demand-Infrastruktur, wodurch der bekannte Server, der ständig laufen muss, entfällt. Zu diesem Zweck wird meist auf einen Anbieter solcher Serverless-Computing-Umgebungen zurückgegriffen, wie Amazon Web Services mit AWS Lambda, Google Cloud Platform, Microsoft Azure oder OpenFaaS. Implementierung, Anpassung und DevOps werden dann über Drittanbieterprogramme erreicht, die in der Lage sind, die Basis von AWS oder Azure einzustellen. Dadurch können die Entwickler, wie in der klassischen Server-Umgebung, die Applikationen konfigurieren und kontrollieren.

Wie Mikro-Funktionen arbeiten

Serverless Computing benötig, unabhängig davon, welcher Umgebungs-Anbieter eingesetzt wird, stets sogenannte Auslöser (Triggers). Diese sind mit Ereignissen in der IT-Infrastruktur des Anbieters verbunden (Events), wie die Frage nach einer bestimmten URL, und integrieren sich reibungslos in das vorhandene technische Rüstzeug eines Unternehmens. Die Auslöser wiederum erschaffen einen Container von Funktionen – und zwar im Mikro-Bereich – um Anfragen zu bearbeiten. Damit verschwindet die Notwendigkeit, eine Skalierung der bekannten großen Container mit großen Funktionen im Zuge des Wachstums eines Unternehmens zu ermöglichen. Außerdem müssen sich die Entwickler nicht mehr auf die Wartung der IT-Architektur konzentrieren und haben Zeit für die Anwendungsverwaltung.

Wie es um die IT-Sicherheit steht

Serverless Computing bringt natürlich neuartige Bedrohungen mit sich und erfordert eine neue Strategie zur Absicherung der IT. Zu Beginn muss dafür gesorgt werden, dass die Richtlinien auf allen Systemen umgesetzt werden und die Absicherung einheitlich gestaltet wird. Das gilt auch für Korrekturen, wenn Sicherheitslücken gefunden wurden.

Hinzu kommt eine hohe Komplexität, weil die Anwendungen auf mehrere dieser Mikro-Funktionen verteilt und angewiesen sind. Aus diesem Grund kann auch die sogenannte Sichtbarkeit leiden, also der Einblick in den Netzwerkverkehr. Es reicht nicht mehr aus, die Aktivitäten der Funktionen schlicht in ein Logging einzutragen, weil Fehler sich über mehrere Mikro-Funktionen verteilen können. Daher versagen auch herkömmliche Tools, die nicht auf diese Komplexität einer IT-Architektur ausgelegt sind.

Eine weitere Bedrohung resultiert aus der Tatsache, dass die IT-Sicherheit des Serverless Computing über Identity-and-Access-Management-Rollen (IAM-Rollen), also Zugriffsrechte, geregelt wird. Wenn diese Rollen mit zu vielen Zugangsrechten ausgestattet werden, kann eine manipulierte Funktion über diese Rolle großen Schaden anrichten. Es muss daher dringend das Prinzip der Geringsten Zugriffsrechte (least privilege) gelten.

Die aufgezählten Gefahren verdeutlichen, dass der Umstieg auf Serverless Computing nichts als Mischform und halbherzig geschehen darf, wenn die Absicherung der IT-Infrastruktur nicht darunter leiden soll. Stattdessen muss von der ersten Funktion an, die geschrieben wird, der Fokus auf den Besonderheiten der neuen Architektur liegen. Es hilft ungemein, eine umfangreiche IT-Sicherheitsarchitektur zu implementieren, die mit Serverless Computing umgehen kann, Künstliche Intelligenz (KI) für ihre Komponenten (unter anderem die Analyse und ThreatIntelligence) nutzt und Prozesse automatisiert, statt einzelne Lösung wild durcheinander zu sammeln. Konsolidierung statt Wildwuchs ist das Schlagwort.

Kurze Geschichte des Serverless Computing

Das Konzept einer Architektur ohne eigenen Server ging direkt aus zwei DevOps-Trends hervor. Zum einen war dies der Versuch, Server schlanker zu gestalten, was mit Backend-as-a-Service als Konzept versucht wurde, wie unter Parse, Backand und Firebase. Zum anderen wanderten die Implementierung weg vom Prinzip des One-Server-per-Service-Modells (Ein Server je Dienst) hin zur Bündelung mehrerer dieser Services in Containern – anfangs als virtuelle Maschinen und später, wie auch aktuell, als programmierbare Container über die Software Docker.

Die Prägung des Begriffes Serverless Computing erfolgte dann durch AWS Lambda auf der re:invent-Messe 2014, wo es als komplette IT-Architektur vorgestellt wurde. Wenige Monate später zogen Google und Microsoft mit eigenen Angeboten nach. Damit rückte Serverless Computing aus der Nische heraus. Zusätzlich entstanden über die Zeit natürlich Programme von Drittanbietern, wie Serverless Framework, um Entwickler zu unterstützen und die besonderen Anforderungen abzudecken.

Stand der Dinge

Mittlerweile hat sich jeder große Betreiber einer Cloud-Infrastruktur mit einer eigenen serverlosen Architektur in den Konkurrenz-Kampf eingemischt, von IBM OpenWhisk zu Oracle Cloud Native Functions. Hinzu kommen die Open-Source-Angebot, wie OpenFaaS, die sich für Einrichtungen und Unternehmen eignen, die ihre IT-Infrastruktur zeitgleich zur laufenden Entwicklung ausbauen müssen. Aus diesem Grund erleben Programme und Sicherheitslösungen von Drittanbietern eine Blütezeit, weil die Adaption des Serverless Computing zunimmt und somit der Bedarf an spezialisierter Software wächst.

Herausforderungen der neuen Technologie

Neben der zahlreichen Vorteile, die Serverless Computing bereit hält, gibt es natürlich Bereiche, die schwieriger zu handhaben sind. DevSecOps-Teams müssen daher ihre Herangehensweise überdenken, vor allem in den Kategorien: Entwicklung neuer Features und Funktionen, Benutzerfreundlichkeit und Veraltung der IT-Infrastruktur.

Beginnen wir damit, die Entwicklung und ihre Prozesse in den Blick zu nehmen, dann zeigt sich sofort, dass viele Tools, die serverlose Architekturen unterstützen, selbst noch in der Entwicklung sind. Microsoft Azure und AWS Serverless Application Model bieten zwar Hilfe an, aber kompakte Programmpakete (Suites) existieren noch nicht für serverlose Anwendungen in vollem Umfang – das gilt ebenso für die IT-Sicherheit und Compliance.

Das Debugging von serverlosen Funktionen kann mühselig sein, wenn Hardware-Grenzen erreicht werden (hardware-edge-cases) und es unmöglich ist, die genutzte Hardware zu replizieren. Die Verfolgung verschiedener Funktionsaufrufe ist außerdem schwierig umzusetzen, ohne jede Anfrage hardware-hungriger zu gestalten. Die Überwachung (monitoring) von Fehlern ist komplex, weil es unmöglich ist, die Ursachen zu ermitteln. Sogar den schlichten Einblick in den Netzwerkverkehr in großem Umfang zu erreichen, ist herausfordernd.

Verzwickter macht es die ambivalente Natur der Serverless-Technologie: Es können Container und die darin enthaltenen Funktionen aufgrund ihrer für die IT-Sicherheit vorteilhaften Kurzlebigkeit noch nicht existieren, wenn eine Anfrage gestellt wird. Das führt zu einer kleinen Verzögerung, bis diese gebaut wurden, was als Kaltstart bezeichnet wird. Diese Verzögerung ist zwar gering – 0,1 Sekunden im Durchschnitt im Jahr 2017 und seitdem gesunken – doch mehrere zusammengenommen können die Benutzerfreundlichkeit empfindlich negativ beeinträchtigen.

Schließlich werden nicht alle Auslöser (Triggers) von den verschiedenen Serverless-Anbietern gleich gebaut. Das erfordert zwingend den Rückgriff auf Drittanbieter und ihre Programme. Technisch ist das zwar kein entscheidendes Problem, doch verlagern sich damit Wartung und Kompatibilitätsprobleme – also Teile der Architektur – ebenfalls zu Dritten, wodurch die Fehleranfälligkeit steigt. Der Erfolg der eigenen Anwendungen entgleitet einem Unternehmen damit zum Teil.

Überlegungen zur Absicherung

Wenn eine serverlose Architektur frisch eingerichtet wurde und viele Funktionen gleichzeitig entstehen, haben diese ab Werk meist das Maximum an Zugriffsrechten gewährt bekommen. Die Idee der Mikro-Funktion ist es aber, so wenig Privilegien je Funktion wie möglich zu definieren. Dieses Problem muss von der IT-Sicherheitsabteilung dem DevOps-Team zugleich angegangen werden. Folgende Themen müssen dringend bedacht werden:

• Verwaltung der Zugriffsrechte: Die gigantische Zahl serverloser Mikro-Funktionen, die interagieren, erfordern sehr viel Aufwand, um sie korrekt zu konfigurieren. Sogar dann, wenn Funktionen während der Entwicklung bereits korrekt eingestellt wurden, können kleine Änderungen an der Server-Konfiguration zu Fehlern führen und Anwendungen offen gegen Angriffe hinterlassen.
• Ende des gewohnten Perimeters: Jede Funktion ist unabhängig von anderen und bewegt sich damit in einem eigenen Perimeter, der durch ihre Privilegien definiert wird. Die üblichen Filter-Lösungen werden damit wirkungslos.
• Gefährliche Abhängigkeiten der Applikationen: Befehlszeilen (Code) wird über wesentlich mehr kleine Geräte verteilt und jedes importiert seinen eigenen Satz von Datenbanken. Dies gestaltet den Umgang mit möglichen Schwachstellen schwierig.
• Schlechter Code: Da die Instanzen zwischen Entwicklern und der Produktion, also den Ausführenden, abnehmen, sinkt die Chance, Fehler in Codes und Konfigurationen rechtzeitig zu entdecken.
• Denial-of-Service-Attacken: Serverless Computing erlaubt zwar viel weitgefasstere Grenzen für Anwendungen, doch die Skalierung kann nicht ins Unendliche getrieben werden. Ein Hacker kann also weiterhin eine DoS-Attacke erfolgreichen durchführen, wenn er das neue Limit ausreizen kann.

Hinzu kommt der Paradigmen-Wechsel in der Entwicklung von Web-Applikation in Richtung von Single-Page-Applications und dieser Wandel erfordert ein gleichzeitiges Umdenken in der IT-Sicherheit des Serverless Computing. Ohne eine intelligente Security-Automatisierung, die sich um die Richtlinien-Konfiguration, Compliance, Auditierung und Zugriffsrechte kümmert – noch bevor die Funktionen entstanden und einsatzbereit sind – geht es nicht mehr. Dieser Ansatz, kombiniert mit modernen Sicherheitslösungen zu Scanning und Analyse, sowie einer zuverlässigen KI dahinter, befähigt schlussendlich Unternehmen, die Herausforderungen der IT-Sicherheit des Serverless Computing zu meistern – und zwar während des laufenden Betriebes.

Zukunft des Serverless Computing

Die wachsende Zahl von Anbietern und Drittanbietern, die das Angebot erweitern und die Handhabung vereinfachen, wird die Preise sinken lassen und die Funktionalität stetig erweitern. Das gibt Unternehmen und Einrichtungen die Möglichkeit an die Hand, langfristig eine bislang unbekannte Flexibilität ihrer IT-Architektur zu erreichen. Diese Erweiterung des Marktes erlaubt es Entwicklern zudem, den Quell-Code der serverlosen Architekturen stärker zu verändern und eigene Abstrahierungen zu erstellen, um Multi-Cloud-Umgebungen besser einbinden zu können. Auf diese Weise erhalten sie auch die breite Palette von Funktionen, um die Sichtbarkeit und Nachverfolgbarkeit zu erzielen, die bislang ein Problem der serverlosen Architekturen sind.

Der größte Fortschritt aber kann im Bereich der Überwachung der IT-Infrastruktur erzielt werden, denn: aufgrund der steigenden Zahl von Anwendungen, die aus unabhängigen Mikro-Funktionen gebaut wurden, ist die Kontrolle des Datenflusses sehr vielschichtig und schwierig geworden. Spezialisierte Anbieter von Sicherheitslösungen reagieren bereits auf diesen Bedarf und implementieren automatische Überwachung in ihre Software, um die gewünschte Sichtbarkeit zu ermöglichen.

Wichtig zu erwähnen ist noch, dass die Vielzahl serverloser Funktionen es sehr schwierig macht, die vielen Fehler in der IT-Absicherung und Compliance zu beheben, die Maschinelles Lernen, Anomalie-Detektion, Compliance-Überwachung, benutzerdefinierte Regeln und Regularien (wie die DSGVO) finden und mit sich bringen. Die resultierenden Protokolle werden von diesen IT-Sicherheitsarchitekturen automatisch registriert, blockiert und in einer CI/CD-Vorlage präsentiert, um die Entwickler dabei zu unterstützen, ihre Antworten auf die erkannten Probleme sicher auszurollen.

Zusammengenommen sorgen all diese Verbesserungen, die korrekt eingerichtetes Serverless Computing mit sich bringt, einer wesentlich schnelleren Markteinführung von Neuerungen (Time-to-Market). Außerdem können Zwischenfälle der IT-Sicherheit auf Entwicklerebene bearbeitet werden, wodurch die IT-Sicherheit früher in den DevOps-Zyklus eingebunden werden kann, als bislang möglich.

Übergang in die serverlose Welt

Serverless Computing befindet sich in einer Phase des starken und stetigen Wachstums. Es ist eines der heißen Themen dieser Tage, weil die zugrunde liegende Technologie und angeschlossene Produkte derzeit sehr schnell entwickelt und verbessert werden. Das führt zwar zu neuen Bedrohungen und Herausforderungen, die bedacht und gemeistert sein wollen, doch ist das mit einem guten Plan zur Einführung des Konzepts möglich. Dieser wiederum steht und fällt mit der IT-Sicherheit und den geeigneten Sicherheitslösungen von spezialisierten Drittanbietern – die im besten Fall eine umfangreiche IT-Sicherheitsarchitektur mit zentraler Plattform und Automatisierung durch KI-Techniken anbieten können. Auf diese Weise wirkt Serverless Computing wie ein Antrieb der Digitalisierung und wird eine rasche Verkürzung der Markteinführung (Time-to-Market) zur Folge haben.