Die digitale Transformation bringt Neuerungen mit sich \u2013 mitunter die, dass zunehmend mehr Anwendungen in der Cloud betrieben werden. Das bringt nat\u00fcrlich Vorteile mit sich: Der Wartungsaufwand beispielsweise sinkt deutlich, sodass auch Kosten sinken k\u00f6nnen. Doch gilt es, sich auch mit der IT-Sicherheit auseinanderzusetzen \u2013 und das machen wir f\u00fcr Sie in diesem Beitrag. Nachdem wir gekl\u00e4rt haben, was Serverless-Anwendungen und Cloud Computing \u00fcberhaupt sind, besprechen wir auch die Vor- und Nachteile von Serverless Security. Nachdem wir h\u00e4ufigen Fehlern auf die Spur gekommen sind, geben wir konkrete Empfehlungen und Best Practices-Ans\u00e4tze an Sie weiter.<\/p>\n
Als serverlose Funktionen bezeichnet man Codesnippets, die ereignisbasiert in vollst\u00e4ndig verwalteten Infrastrukturen ausgef\u00fchrt werden. Mit Serverless-Architekturen ist es m\u00f6glich, komplexe Anwendungssysteme aufbauen zu k\u00f6nnen \u2013 und zwar ohne sich ums Managen der Infrastruktur k\u00fcmmern zu m\u00fcssen: Cloud-Provider \u00fcbernehmen Aspekte wie Skalierung, Verf\u00fcgbarkeit oder Provisionierung. Um serverlose Anwendungen abzusichern, braucht es eine Vielzahl neuer Abl\u00e4ufe, strategischer \u00dcberlegungen sowie Werkzeuge. Bauen Anwendende weiter auf altbekannte Prozesse oder Vorgehensweisen, ist die Sicherheit langfristig nicht mehr gew\u00e4hrleistet.<\/p>\n
Eine Anwendung besteht in der Serverless-Welt zumeist aus Hunderten von Funktionen. Jede von ihnen ist f\u00fcr sich genommen relativ einfach, im Zusammenspiel jedoch ergibt die Anwendung ein Gesamtsystem meist komplexerer Natur. Wie Sie schon in dieser Einf\u00fchrung zur Serverless Security sehen, ergeben sich aus diesem Prinzip viele Vor-, aber auch Nachteile bez\u00fcglich der IT-Sicherheit.<\/p>\n
Kommen wir zun\u00e4chst 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\u00fcmmern, stehen Nutzenden deutlich mehr Ressourcen zur Verf\u00fcgung \u2013 das ist der wohl sichtbarste Vorteil. Ein weiterer ist die m\u00f6gliche Feinkonfiguration: Serverlose Architekturen schrauben die Anzahl m\u00f6glicher Funktionen wesentlich in die H\u00f6he. Das hat zur Folge, dass auch etliche Rollen durch ein Identity and Access Management (IAM) festgelegt werden k\u00f6nnen. Das mag vielen Organisationen zun\u00e4chst nicht unbedingt vorteilhaft erscheinen. Jedoch gelingt es durch die Wahl passender Tools und Prozesse, um jede Funktion sogenannte \u201eShrink Wrapped Permissions\u201c zu bauen. Damit ergibt sich eine Weiterentwicklung des Zero Trust-Ansatzes: Jede Funktion kann ausschlie\u00dflich auf jene Ressourcen bzw. Dienste zugreifen, die ihr gestattet werden. Bei richtiger Konfiguration verhindert dieses \u201eLeast Privilege Principle\u201c zahlreiche Cyberangriffe auf Anwendungen.<\/p>\n
In der Praxis kann die Vielzahl an Rechten Verwirrung stiften und wird gerne mit einer allowAll-Policy umgangen. \u00dcbergreifende Recht sind jedoch nicht Sinn der Sache, denn mit diesen w\u00fcrden die Tore f\u00fcr Angriffe ge\u00f6ffnet werden. Besser ist das Finden passender \u2013 n\u00e4mlich minimaler \u2013 Berechtigungen; der Aufwand lohnt sich! \u00c4ndert sich beizeiten die Logik von Funktionen, k\u00f6nnen die Rechte jederzeit angepasst werden. Dieses Least Privilege Principle sollte auch f\u00fcr 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.<\/p>\n
Bestehende Konzepte zeichnen sich oft durch gro\u00dfe Container aus, die vollgestopft sind mit Vollmachten und Zugriffsrechten. Bei der Serverlosen Architektur hilft ein Umdenken: Funktionen in hoher Anzahl sorgen daf\u00fcr, dass die Wirkung jeder einzelnen recht begrenzt ist \u2013 jeder Funktion wird ausschlie\u00dflich eine kleine Aktion zugestanden. Somit existieren die kleinen Funktionen sehr kurz bevor sie anschlie\u00dfend neu geladen werden. Daraus ergibt sich der Vorteil, dass Angreifende Funktionen nur sehr kurz missbrauchen k\u00f6nnen, bevor sie wieder verschwinden. Daher gilt es, die Lebensspanne von Funktionen so kurz wie m\u00f6glich zu konfigurieren, sodass viele Angriffe fast schon unm\u00f6glich gemacht werden.<\/p>\n
Die Kehrseite dieser Medaille ist, dass auch Angreifende dazulernen: Bei kurzen Laufzeiten greifen Cyberkriminelle st\u00e4ndig erneut an. Dies wird als \u201eT\u00e4glich-gr\u00fc\u00dft-das-Murmeltier-Angriff\u201c bzw. \u201eGroundhog Day Attack\u201c bezeichnet. Attacken dieser Art sind sehr auff\u00e4llig, sodass das Entdecken und entsprechende Stoppen recht einfach erfolgen kann.<\/p>\n
Durch die Protokolle der einzelnen Mikrodienste erh\u00f6ht sich die Transparenz. Weiter haben Kontrollprogramme deutlich mehr M\u00f6glichkeiten, etwaige Anomalien aufzusp\u00fcren. Sicherheitsteams wird also erm\u00f6glicht, Anomalien z\u00fcgiger zu entdecken und gegenzusteuern.<\/p>\n
Doch Serverless Security hat auch mit Nachteilen zu k\u00e4mpfen: Etwa das Mehr an Protokollen, denn die entstehende Transparenz kann vor- und nachteilig eingesch\u00e4tzt werden. Die entstehende Transparenz ist zweifellos ein Vorteil, der Weg dahin f\u00fchrt jedoch \u00fcber viele, viele Protokolle: Hunderte Funktionen bedeuten Hunderte Protokolle. Daf\u00fcr existieren jedoch L\u00f6sungen \u2013 mitunter XDR; ein Sicherheitskonzept, mit dem es gelingt, eine gro\u00dfe Menge an Informationen sinnvoll zu bewerten. Weitere Informationen dazu erhalten Sie in unserem Blogbeitrag \u201eXDR: Extended Detection and Response\u201c<\/a>.<\/p>\n Viele Funktionen k\u00f6nnen auch die Angriffsfl\u00e4che selbst erh\u00f6hen, denn somit ergeben sich zahlreiche Einstiegspunkte f\u00fcr Angreifende. Davon sind einige f\u00fcr Hacker leichter zug\u00e4nglich als andere. Die feingranularen Berechtigungskonzepte jedoch bringen maximale Kontrolle f\u00fcr die Funktionen, sodass ein effizientes IAM die Angriffsfl\u00e4che wieder verkleinern kann.<\/p>\n Ein Nachteil kann auch sein, dass feste Firmen-Perimeter sowie Rechenzentren als Grenzen der Firmen-IT wegfallen. Bislang war das Innere und das \u00c4u\u00dfere eines Firmennetzwerks fest definiert \u2013 Serverless Security \u00e4ndert diese Auffassung. Liegen die Grenzen in jeder Funktion? In jeder Ressource? \u2013 Hier gilt es, zu definieren, nicht zuletzt, um Rechtsfragen zu kl\u00e4ren.<\/p>\n Damit die Vorteile auch als solche verstanden werden k\u00f6nnen, gilt es, einige typische Fehler zu vermeiden. So wird beispielsweise oft angenommen, die Web Application Firewall (WAF) w\u00fcrde sich um die Sicherheit s\u00e4mtlicher Anwendungen k\u00fcmmern. Die WAF befindet sich klassischerweise am Internet\u00fcbergang hinaus aus der Firmen-Infrastruktur. Sie sch\u00fctzt Web- sowie Anwendungsdienste, sichert jedoch nicht alle Anwendungen ab. Die WAF dient der Inspektion des HTTPS-Verkehrs und sch\u00fctzt Funktionen, die vom API-Gateway ausgel\u00f6st wurden. Wurden Ereignisse im Cloud-Netzwerk anderweitig ausgel\u00f6st, sind sie nicht durch die WAF gesch\u00fctzt. Die WAF darf also nicht als einziges Schutzprogramm verstanden werden; Sicherheitsl\u00fccken im Netzwerk lassen sich mit spezialisierten Sicherheitsl\u00f6sungen schlie\u00dfen.<\/p>\n Ein zweiter h\u00e4ufiger Fehler sind unbearbeitete Funktionsberechtigungen \u2013 die in den Vorteilen bereits angesprochenen Berechtigungen. Funktionen sollten nicht mehr Spielraum haben, als sie eigentlich ben\u00f6tigen \u2013 oder andersherum: Halten Sie Zugriffsberechtigungen f\u00fcr Funktionen so gering wie m\u00f6glich. Schauen Sie sich jede einzelne der Funktionen an, pr\u00fcfen Sie, was diese macht und welche Berechtigungen daf\u00fcr notwendig sind. So k\u00f6nnen Sie die Rollen und Zugriffsberechtigungen pr\u00e4zise konfigurieren \u2013 und Anpassungen sind im Nachhinein weit weniger aufwendig.<\/p>\n Um Serverless Security einf\u00fchren zu k\u00f6nnen, m\u00fcssen Organisationen weiter verstehen, dass der Code von Anwendungen nicht zwangsl\u00e4ufig ein selbst geschriebener sein muss. Cloud-Anwendungen bestehen zumeist aus zahlreichen Modulen und Bibliotheken. Ein Modul inkludiert h\u00e4ufig 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\u00e4ufiger, b\u00f6sartigen Code in Community-Projekte einzubinden. Das kann \u00fcber Open Source-Websites wie GitHub durchaus gelingen. Findet dann die neue Version ihren Weg in Cloud-Anwendungen, kommt der b\u00f6sartige Code mit. Werkzeuge wie Source Code Analysis (SCA) \u2013 fr\u00fchzeitig in den Entwicklungsprozess eingebunden \u2013 k\u00f6nnen hier eine L\u00f6sung darstellen.<\/p>\n Ein weiterer h\u00e4ufig anzutreffender Fehler ist es, den falschen Anzeichen f\u00fcr Angriffe zu trauen. Wie in den Vor- und Nachteilen der Serverless Security beschrieben, erh\u00f6ht das Prinzip die Sichtbarkeit und Transparenz. Da sich die Menge an Informationen massiv erh\u00f6ht, haben einige Unternehmen kaum noch M\u00f6glichkeiten, die Daten umfangreich auszulesen und sinnvoll zu interpretieren. K\u00fcnstliche Intelligenz (KI) und maschinelles Lernen (ML) helfen: Sie k\u00f6nnen die Sicherheit in der Cloud automatisiert erh\u00f6hen und Mitarbeitende beim Auswerten von Protokollen effizient unterst\u00fctzen.<\/p>\n Verfolgen Sie zum Erh\u00f6hen der Sicherheit den Zero Trust-Ansatz: Zugriffsrechte werden fest beschr\u00e4nkt, das Unternehmensnetzwerk wird segmentiert. So lassen sich Sch\u00e4den, die nach erfolgreichen Angriffen folgen, limitieren. Weiterf\u00fchrende Informationen finden Sie in unserem Artikel \u201eZero Trust: Kein blindes Vertrauen f\u00fcr mehr Sicherheit\u201c<\/a>.<\/p>\n Mit Tools zur Code-Analyse (SCA, s. o.) k\u00f6nnen Sie eigenen sowie fremden Code \u00fcberwachen. So bewahren Sie ein Grundma\u00df an Sicherheit und verhindern das Einschleusen von Schadcode. Setzen Sie zudem erg\u00e4nzend auf XDR, k\u00f6nnen Sie Ihre gesamte IT-Infrastruktur zum Teil KI-basiert automatisiert \u00fcberwachen lassen.<\/p>\n <\/p>\n 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\u00fcrfen. Verlassen Sie sich nicht nur auf die vollmundigen Werbeversprechen von Cloud-Providern, sondern pr\u00fcfen Sie verschiedene M\u00f6glichkeiten. Passen Sie auch Ihre IT-Sicherheitsstrategie der neuen Architektur an \u2013 und arbeiten Sie von Beginn an so genau wie m\u00f6glich, denn nur dann ist bei serverlosen Funktionen auch Sicherheit mit an Bord.<\/p>\nDie h\u00e4ufigsten Fehler bei\u00a0Serverless Security<\/h3>\n
Empfehlungen f\u00fcr Serverless Security<\/h3>\n
Serverless Security: Ein neuer Weg mit neuen Konzepten<\/h2>\n