Microservices sind toll, aber .... Orientierung im Minenfeld der Microservices: Eine Zero-Trust-Sicherheitsstrategie

Websites und Apps haben sich seit ihrem ersten Einsatz sehr stark verändert: Wenn Ihr Unternehmen dafür nicht bereit ist, können Microservices, die Ihre neue Website oder App antreiben, schnell zu einem Minenfeld werden. Denn diese neue Realität birgt einige reale Sicherheitsprobleme.

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

Fujitsu Technology Solutions GmbH

FNT GmbH

Websites und Apps haben sich von relativ engen Anwendungsbereichen und einem zentralen Einstiegspunkt, die in einem einzelnen Rechenzentrum gehostet werden, zu umfangreichen, dynamischen Web-Anwendungen mit Tausenden beweglichen Elementen entwickelt. Nicht unwesentlich verantwortlich dafür ist der Umstieg auf Microservices-Architekturen.

Sie gewähren Websites einerseits mehr Flexibilität, wodurch sich die Kosten und Komplexität für das Hinzufügen neuer Funktionen reduzieren. Sie bieten andererseits eine größere Angriffsoberfläche für sich ständig weiterentwickelnde Exploits. Um diese Herausforderung zu meistern, muss die Bedeutung eines modernen Sicherheitskonzepts überdacht werden.

Im Folgenden wird erläutert, was Microservices mitsamt potentieller Sicherheitsgefahren, die es zu beachten gilt. Zudem wird analysiert, welche Schutzmaßnahmen die Sicherheitsstrategie eines Unternehmens beinhalten muss – ihre automatisierte Verteidigung in einer digitalen Welt, die auf Hunderten oder gar Tausenden Microservices basiert.

Was genau sind Microservices?

Microservices sind eine andere Vorgehensweise zur Software-Entwicklung, die auf einer Reihe von verbundenen, aber dennoch unabhängigen Komponenten basiert, die jeweils eine spezifische Funktion für die gesamte Anwendung liefern. Dieses Konzept steht im Gegensatz zu der traditionellen Vorstellung eines „Monolithen“ oder einer Applikation, die aus einer einzelnen, einheitlichen Codebasis besteht.

Apps, die auf Microservices basieren, unterscheiden sich hinsichtlich der Benutzeroberfläche nicht von monolithischen Applikationen. Im Hintergrund unterteilen Microservices die Applikation jedoch in einzelne Dienste, die in der Regel von kleinen Teams erstellt wurden, von denen jeder einen bestimmten Aspekt davon bereitstellt, was auf einer Website passiert.

Unabhängigkeit ist gefragt

Als Beispiel soll E-Commerce-Website wie die von Amazon dienen: Jede einzelne Benutzeraktion – von der Produktsuche oder der Eingabe von Kundendaten für die Suche bis hin zu Warenkörben, Bezahlvorgängen und vielem mehr – nimmt eine Vielzahl von Microservices in Anspruch, die dafür verantwortlich sind, die Aktion selbst durchzuführen oder mit anderen Diensten zu interagieren, um dem Benutzer ein Ergebnis zu liefern.

Nicht jeder Kunde durchläuft den gleichen Prozess zu demselben Zeitpunkt aus. Wenn mehrere Benutzer gleichzeitig auf unterschiedliche Teile einer Website zugreifen, müssen die Bereiche der Applikation unabhängig voneinander skalieren. Vielleicht gibt es einen Blitzverkauf, bei dem sich viele Benutzer anmelden und gleichzeitig versuchen, ein Produkt zu kaufen, aber nur einen Kunden, der nach Artikeln sucht, die nicht im Sale sind.

Durch Microservices haben Unternehmen die Möglichkeit, das Kundenerlebnis dank der dynamischen und unabhängigen Komponenten gezielt und flexibel zu optimieren. Gleichzeitig werden die Zeit- und Ressourcenaufwendungen für eine grundlegende Umgestaltung einer monolithischen Anwendung oder eine übermäßige Bereitstellung von Computerressourcen vermieden.

Das Minenfeld der Microservices

Microservices haben unzählige Vorteile, bringen aber auch eine Reihe von zu lösenden Sicherheitsherausforderungen mit sich. Mit zunehmender Anzahl der bereitgestellten Diensten, den unabhängigen Teams, die an der Entwicklung beteiligt sind, den Applikationsstapeln und Computerplattformen sowie der beteiligten Rechenzentren und Clouds, vergrößert sich die Angriffsoberfläche und die damit verbundenen Sicherheitsrisiken steigen dramatisch.

Stellen Sie sich eine Cloud-basierte Bank- oder eine Finanzapplikation vor. Die Bank ist stets besorgt über potenzielle Hacks und Datenverluste, weshalb es bereits eine inhärente Komplexität in den soliden Compliance- und Firewall-Regeln gibt, die dazu ausgelegt sind, diese zu verhindern. Ergänzen Sie diese Gleichung um Microservices, bei denen jeder Dienst über eigene Regeln und mehrere zusammenarbeitende Programmierer-Teams verfügt.

So können zahlreiche Möglichkeiten entstehen, dass die Dinge aus den Fugen geraten. Drei Aspekte sollten dabei beleuchtet werden.

• Das erste Problem besteht darin, dass Ihre zukünftige Applikation statt in einer einzelnen, logischen Einheit innerhalb eines einzelnen Servers, auf eine Vielzahl von Servern und Diensten verteilt ist. Diese können sich in unmittelbarer Nähe zueinander befinden oder an komplett unterschiedlichen Orten liegen. In jedem Fall ist die Angriffsoberfläche Ihrer Applikation größer als zuvor.

• Zweitens ist die Bereitstellung von Microservices oftmals mit einer erheblichen Übergangsphase verbunden, in der eine Mischung aus älteren Technologien und neuem Code ausgeführt wird. Inmitten des Migrationsprozesses befindet sich das Unternehmen dann in einer unangenehmen Zwischenposition, da es unter Umständen noch die alte Monolith-App verwendet, während es gleichzeitig bereits die Komponenten in Microservices überführt.
  Dadurch vergrößert sich nicht nur die Angriffsfläche, auch die Teams müssen sich um die Behebung der Sicherheitsrisiken der veralteten Applikation kümmern. Zudem müssen sie lernen, neue Microservices unter Berücksichtigung der Sicherheit zu programmieren und für Konsistenz der Protokolle sowie Sicherheitsmechanismen zwischen der veralteten Monolith-Applikationen und den von ihnen erstellten neuen Microservices zu sorgen.

• Der dritte Aspekt besteht darin, dass verschiedene Teams beteiligt sind. Wenn Team A an einem Microservice arbeitet und Team B einen weiteren programmiert, müssen Sie sicherstellen, dass diese die gleichen bewährten Best Practices verwenden, um einen konsistenten, sicheren Code über die gesamte modulare Architektur zu schreiben.
  Je mehr Teams ihre eigenen Dienste mit unterschiedlichen Programmiersprachen oder Anwendungsstapeln schreiben, desto größer ist die Gefahr für potenzielle Sicherheitsexploits. Das Sicherheitssystem von Unternehmen ist nur so stark wie die schwächste Verbindung und mit Microservices sind viel mehr Verbindungen eingebunden.

Schlachtpläne für eine Null-Toleranz-Sicherheit

Die Notwendigkeit von Sicherheitsmaßnahmen am Einstiegspunkt der Applikation ist leicht zu erkennen. Das ist jedoch nicht das Wichtigste, das sich mit Microservices verändert. Die Herausforderung besteht in der größeren Angriffsfläche hinter den Kulissen und den vielen verschiedenen beteiligten Personen, die eine Auswirkung darauf haben, wie sich die App verhält. Die Lösung beginnt mit der Annahme des so genannten Zero-Trust-Modells.

Mit einfachen Worten bedeutet Zero-Trust, dass es kein Vertrauen gibt. Wenn Sie unter der Annahme agieren, dass die ganze Welt darauf aus ist Ihre App zu hacken, ist es Ihre Aufgabe sicherzustellen, dass zwischen den vielen Microservices, aus denen Ihre Applikation besteht, eine gegenseitige Authentifizierung, Autorisierung, Verschlüsselung und Transparenz besteht.

Die dynamischen und hoch automatisierten Eigenschaften der Microservices erfordern oftmals, dass Apps mehr Verantwortung für die Sicherung ihrer eigenen Sicherheitsgrenzen übernehmen. Sobald Sie Zero-Trust übernommen haben, können Sie einen Schlachtplan aufstellen, um sich im Minenfeld zu orientieren. Nachdem Sie die Grundregeln aufgestellt haben, anhand derer definiert wird, wie Apps und Dienste erstellt werden sollen, müssen Sie festlegen auf welche Weise sich diese gegenseitig identifizieren und das Vertrauen zueinander aufbauen, wie sich diese untereinander verhalten und was passiert, wenn etwas schief läuft.

Das schrittweise Vorgehen

Einer der ersten Schritte, auf die Sie achten müssen, besteht darin, die Koordination so einzusetzen, dass eine starke Authentifizierung gewährleistet und der gesamte Datenverkehr durchgängig verschlüsselt ist. Eine Möglichkeit dafür ist die TLS Termination für Front-End-Routing und das Hinzufügen einer TLS für die Backends mit einer automatisierten Authentifizierung durch digitale Zertifikate. Dadurch wird sichergestellt, dass die Dienste so eingerichtet sind, dass sie nur mit anderen Diensten interagieren, die sie verifizieren können.

Mein Rat: Ziehen Sie außerdem strengere Regeln in Betracht, so dass die Microservices nur andere Dienste erkennen können, die sie kennen sollten.

Nachdem das Grundvertrauen aufgebaut ist, sind Kontrollen hilfreich. Denken Sie darüber nach, wie viel Auslastung ein bestimmter Dienst auf Grundlage der Bandbreite, Verbindungen usw. erwartungsgemäß in Anspruch nehmen sollte. Was ist zu tun, wenn ein Dienst mehr ausgelastet ist als erwartet?

Mein Rat: Ziehen Sie Regeln in Betracht, die Kapazitäten bereitstellen oder verlagern, einen detaillierten Einblick in die Anforderungen bereitstellen, etwa die Transaktionsdetails protokollieren.

Schließlich ist da noch der Punkt der Sichtbarkeit. Letztlich können und werden Fehler auftreten.

Mein Rat: Stellen Sie sicher, dass Sie vollständige Transparenz über Ihre Applikation und eine umfassende Auditierung haben, um nachzuvollziehen, wer welche Aufgaben, wann und in welchem Bereich Ihrer Applikation übernommen hat. Bei einer Sicherheitsverletzung oder einem Datenverlust verfügen Sie so über die Daten, die Sie zur unmittelbaren Identifizierung der Störung benötigen.

Es möchte niemand die Person sein, die einen Anruf vom Vice President oder einem Mitarbeiter von der Führungsetage entgegennimmt, der fragt, „Was zum Teufel ist passiert?“ um dann zu antworten „Ich weiß es nicht.“

Der Autor:

Der Verfasser des Artikels ist Sidney Rabsatt, Vice President Product Management bei Nginx.

(ID:45631513)