Entwickeln Sie robuste, sichere Microservices mit Mikrosegmentierung

Dieser Artikel erschien ursprünglich in Der neue Stack.

Vor etwa 10 bis 12 Jahren erlebte die Softwarewelt einen Wandel in den architektonischen Aspekten von Unternehmensanwendungen. Architekten und Softwarehersteller begannen, sich von den riesigen, eng miteinander verbundenen, monolithischen Anwendungen, die in privaten Rechenzentren bereitgestellt wurden, zu einer stärker auf Microservices ausgerichteten Architektur zu bewegen, die in einer öffentlichen Cloud-Infrastruktur gehostet wurde. Die inhärente verteilte Natur von Microservices ist eine neue Sicherheitsherausforderung in der öffentlichen Cloud. In den letzten zehn Jahren haben Unternehmen trotz der zunehmenden Einführung einer auf Microservices ausgerichteten Architektur für den Aufbau skalierbarer, autonomer und robuster Unternehmensanwendungen in der Cloud im Vergleich zu herkömmlichen Rechenzentren oft Schwierigkeiten, sich vor dieser neuen Angriffsfläche zu schützen. Dazu gehören auch Bedenken hinsichtlich der Mehrinstanzenfähigkeit und mangelnder Transparenz und Kontrolle über die Infrastruktur sowie die Betriebsumgebung. Dieser architektonische Wandel macht es schwieriger, Sicherheitsziele zu erreichen, insbesondere angesichts der Tatsache, dass der Schwerpunkt auf schnelleren containerbasierten Bereitstellungen liegt.

Der Zweck dieses Artikels besteht darin, zu verstehen, was Mikrosegmentierung ist und wie sie Softwarearchitekten, DevOps-Ingenieure und IT-Sicherheitsarchitekten in die Lage versetzen kann, sichere und belastbare Microservices zu entwickeln. Insbesondere werde ich das besprechen Netzwerksicherheit Herausforderungen im Zusammenhang mit dem beliebten Container-Orchestrierungsmechanismus Kubernetes, und ich werde den Wert der Mikrosegmentierung veranschaulichen, um laterale Bewegungen im Falle einer Sicherheitsverletzung zu verhindern.

Sicherheitsherausforderungen bei der Bereitstellung von Microservices

Eine Microservice-orientierte Architektur erfordert die Aufteilung von Anwendungen in kleinere, lose gekoppelte Dienste. Aufgrund des verteilten Charakters dieser Dienste verfügen sie oft über eigene Datenspeicher. Jeder dieser Dienste wird unabhängig voneinander mithilfe eines Containers bereitgestellt. Dieser bietet einen Mechanismus, mit dem eine Anwendung alles von Objektcode, Drittanbieterbibliotheken, Betriebssystemen, Tools und anderen Abhängigkeiten paketieren kann. Sobald alles Notwendige verpackt ist, bieten Container die Ausführungsumgebung, um sie reibungslos ausführen zu können. Diese Container werden mit Orchestratoren wie Kubernetes verwaltet.

Nach der weit verbreiteten Vorstellung ist das Container-Ökosystem darauf ausgelegt, Sicherheit durch Isolierung durchzusetzen. Die Isolierung zwischen Containern bietet jedoch nicht unbedingt die erforderlichen Sicherheitsgrenzen. Kubernetes bietet mehrere Sicherheitsfunktionen wie Authentifizierung, Autorisierung, Netzwerkrichtlinien und Pod-Sicherheitsstandard usw. Aber leider bieten weder Container noch Kubernetes standardmäßig Sicherheit. Kubernetes-Bereitstellungen geben in ihrer Standardkonfiguration der Funktionalität Vorrang vor der Sicherheit. Daher weiß ein Entwickler oder ein Zuverlässigkeitsingenieur, der für die Erstellung, Verschiebung und Zerstörung dieser Container verantwortlich ist, möglicherweise nicht immer, wie die Sicherheit von Bereitstellungen gewährleistet werden kann. Schauen wir uns einige der wichtigen Aspekte von Kubernetes aus Netzwerk- und Sicherheitsperspektive genauer an:

1. Namespace: In Kubernetes ist ein Namespace eine logische Methode, um Cluster-Ressourcen in einen virtuellen Raum für mehrere Benutzer aufzuteilen. Im Gegensatz zu Linux erzwingt es keine Netzwerksegmentierung. Bitte beachten Sie, dass ein Namespace keine Sicherheitsgrenze darstellt und Dienste in einem Namespace daher auf Dienste in einem anderen Namespace zugreifen können.
2. Netzwerkpolitik: Die Kubernetes-Netzwerkrichtlinie ist ein anwendungsspezifisches Konstrukt, das die Layer-3- und Layer-4-Kommunikation zwischen Namespaces, Pods und IP-Adressblöcken ermöglicht. Wenn Kubernetes installiert ist, ist die Netzwerkrichtlinie standardmäßig nicht verfügbar. Man muss Netzwerk-Plugins installieren und konfigurieren, um Netzwerkrichtlinien durchzusetzen, bevor Pods erstellt werden. Es ist auch erwähnenswert, dass Netzwerkrichtlinien nicht auf Serviceebene durchgesetzt werden können. Dies ist aus Sicherheitsgründen ein erhebliches Manko, da die Zugriffskontrolle nicht auf Dienste ausgedehnt werden kann.
3. Sicherheitsstandard für Pods: In einem Cluster unterstützen Pods mehrere Container, die sich dieselbe physische oder virtuelle Maschine teilen. Sie ermöglichen den Datenaustausch und die Kommunikation zwischen den Containern innerhalb des Pods. Ein Pod-Sicherheitsstandard ermöglicht es einem Administrator, Ressourcen und deren Berechtigungen mithilfe eines fein abgestuften Autorisierungsmodells zu kontrollieren. Für diese Sicherheitskontrolle ist ein Zugangscontroller erforderlich, der standardmäßig nicht aktiviert ist. Ein privilegierter Pod bietet Administratorzugriff auf alle Container. Infolgedessen kann der Angreifer, der Zugriff auf privilegierte Container erhält, Administratorzugriff auf Hostressourcen erhalten.
4. Geheimer Speicher: Kubernetes speichert sensible und vertrauliche Informationen wie Passwörter, OAuth-Token und SSH-Schlüssel als Geheimnisse in einer Base-64-kodierten Form, die als Klartext betrachtet wird. Die Autorisierungsrichtlinie, die verwendet wird, um den Zugriff auf Geheimnisse einzuschränken, ist standardmäßig nicht konfiguriert. Diese werden über Umgebungsvariablen oder Manifestdateien gemeinsam genutzt, was ebenfalls als unsichere Praxis für den Umgang mit Geheimnissen gilt. In Ermangelung einer Standardverschlüsselung ruhender Geheimnisse und des Fehlens einer robusten Verwaltung von Geheimnissen werden Geheimnisse zu einem attraktiven Ziel für laterale Weitergabe.

Seitliche Bewegung und der böswillige Insider

Aufgrund des verteilten Charakters von Microservices ist Konnektivität äußerst wichtig. Insbesondere müssen Container und Pods in der Lage sein, über Namespaces hinweg miteinander zu kommunizieren. Die Standardnetzwerkrichtlinien auf Clusterebene implementieren jedoch nicht unbedingt die Prinzip der geringsten Privilegien aus der Box. Daher kann unberechtigter impliziter Zugriff auf gemeinsam genutzte Ressourcen unabhängig von der Art und Weise, wie Sie Ihren Code sichern, nicht verboten werden. Infolgedessen kann die Anwendung anfällig für seitliche Bewegungen innerhalb des Clusters werden. Die Mikrosegmentierung ermöglicht die Implementierung einer granularen Zugriffskontrolle, indem sichere Zonen um jeden Microservice auf Container-, Pod- und Cluster-Ebene eingerichtet werden. Dadurch wird der Explosionsradius erheblich reduziert und die Widerstandsfähigkeit erhöht, um sich nach einem erfolgreichen Angriff zu erholen.

Die zweite große Bedrohung, die das Sicherheitsmodell des bestehenden Kubernetes-Frameworks in Bezug auf Microservices darstellt, ist ein böswilliger Insider. Aus der Sicht eines Angreifers sind mehrere Fehlkonfigurationen möglich, wenn die Sicherheit standardmäßig nicht verfügbar ist. In Ermangelung strenger Zugriffskontroll- oder Autorisierungsrichtlinien können Angriffe wie Serverseitige Anforderungsfälschung (SSRF) ermöglichen es dem Angreifer, einen authentifizierten Zugriff auf einen Pod zu nutzen, um unbefugten Zugriff auf Ressourcen in einem anderen Pod zu erhalten.

Wie oben besprochen, haben wir festgestellt, dass keine angemessenen Sicherheitskontrollen verfügbar sind, um Geheimnisse standardmäßig zu schützen. Geheimnisse nicht zu verschlüsseln und zu rotieren sowie den Zugriff auf Geheimnisse nicht einzuschränken, sind in der Tat unabhängige Probleme, aber da es keine Sicherheitskontrolle gibt (in diesem Fall fehlende Verschlüsselung), wird die zweite Sicherheitskontrolle (d. h. die Beschränkung des Zugriffs auf die geheimen Speicher) entscheidend, um die Ausnutzung durch einen böswilligen Insider (z. B. einen verärgerten Administrator) zu verhindern.

Einführung von Cyber-Resilienz mit Mikrosegmentierung

Im Zusammenhang mit Sicherheit ist Resilienz die Fähigkeit, sich nach einem einfachen Ausfall aufgrund von Angriffen oder katastrophalen Ereignissen wie Sicherheitsverletzungen schnell zu erholen. Der erste Schritt beim Aufbau widerstandsfähiger Microservices besteht darin, zu verstehen, was wir vor dem Angreifer schützen möchten und wie wir die Auswirkungen begrenzen können, falls das Asset oder die Ressource kompromittiert wird. Die Mikrosegmentierung hilft uns dabei, die Ressourcen zu ermitteln, auf denen wichtige Daten oder kritische fehlertolerante Systeme gespeichert sind. Außerdem bietet sie einen Mechanismus, um den Zugriff auf der Grundlage der geringsten Rechte zu sperren. Auf diese Weise werden die anderen nicht beeinträchtigt, selbst wenn eine wichtige Ressource kompromittiert wird.

Der moderne Softwareentwicklungszyklus von heute legt besonderen Wert auf die schnelle Bereitstellung von Funktionen. Diese Funktionen werden in der Produktion noch schneller über Container bereitgestellt, meistens von denselben Entwicklern oder DevOps. Wenn wir alle Arten von Sicherheitslücken berücksichtigen, für die der Code von Microservices, Bibliotheken von Drittanbietern und anderen Abhängigkeiten, Containern oder Clustern anfällig ist, wie können wir dann all diese Angriffe identifizieren und verhindern? Die Antwort besteht darin, den Zugriff auf kritische Ressourcen zu blockieren und mithilfe der Mikrosegmentierung nur dann zuzulassen, wenn dies erforderlich ist.

Beginnen Sie mit der Mikrosegmentierung

Für den Einstieg in die Mikrosegmentierung gibt es keine Einheitsstrategie, aber im Folgenden finden Sie einige bewährte Methoden, wenn Sie ein Mikrosegmentierungsprojekt für Microservices starten:

1. Kenntnis der Microservice-Entwurfsmuster und Verwendung einer Mikrosegmentierungsvorlage

Die Kenntnis der Entwurfsmuster ermöglicht ein tieferes Verständnis der architektonischen Komponenten, des Datenflusses und der Ressourcen, die wichtige Daten enthalten. Basierend auf diesen häufig verwendeten Entwurfsmustern kann man entsprechende Mikrosegmentierungsvorlagen erstellen. Sobald diese Vorlagen vom Sicherheits- und Netzwerkteam überprüft wurden, können sie einfach wiederverwendet und schneller skaliert werden.

Im Gegensatz zu den riesigen, eng gekoppelten Monolith-Anwendungen folgen die Anwendungen, die auf einer Microservice-orientierten Architektur basieren, einem oder mehreren bestimmten Entwurfsmustern. Bei diesen Entwurfsmustern kann es sich um eines der folgenden handeln:

• Bei Zerlegungsmustern werden Anwendungen auf der Grundlage von Geschäftsfunktionen in Subdomänen oder Transaktionen aufgeteilt.
• Integrationsmuster umfassen Entwurfsmuster für die Serviceintegration wie API-Gateway, Aggregator, verkettete Microservices usw.
• Datenbankmuster konzentrieren sich auf die Position von Datenbanken in der Gesamtarchitektur der Anwendungen. Beispiele hierfür sind Datenbanken pro Dienst, gemeinsam genutzte Datenbanken, Event Sourcing usw.
• Beobachtbarkeitsmuster bestehen aus Entwurfsmustern, die sich auf Prüfung, Protokollierung und Überwachung konzentrieren, wie z. B. Protokollaggregation, verteilte Ablaufverfolgung, Integritätsprüfung usw.
• Übergreifende Problemmuster helfen bei der Verwaltung von Funktionen auf Anwendungsebene wie Sicherheit, Fehlertoleranz, Service-to-Service-Kommunikation und Konfigurationsmanagement an einem zentralen Ort. Beispiele hierfür sind Schutzschalter, Service Discovery usw.

(Weitere Informationen zu verschiedenen Microservice-Designmustern finden Sie unter hier.)

2. Auswahl des richtigen Mikrosegmentierungsansatzes

Derzeit gibt es auf dem Markt mehrere Anbieter von Mikrosegmentierungen mit unterschiedlichen Lösungsansätzen. Im Großen und Ganzen lassen sich Mikrosegmentierungstechniken in zwei Kategorien einteilen:

1. Technologieunabhängige Mikrosegmentierungslösungen basieren entweder auf Wirkstoffen oder Firewalls der nächsten Generation.
2. Technologieabhängige Mikrosegmentierungslösungen basieren auf dem Hypervisor oder den Network Fabrics.

Microservices verwenden einen unterschiedlichen Technologie-Stack, und die schnellere Bereitstellung erfordert eine schnelle Skalierbarkeit. Daher wäre eine technologieunabhängige Mikrosegmentierungslösung — allerdings eine, die speziell auf ein Container-Ökosystem zugeschnitten ist und Cluster, Pods, Container und Services segmentieren kann — die optimale Wahl.

3. Sichtbarkeit des Netzwerks

Die Fähigkeit, segmentierte Anwendungen und den Verkehrsfluss zu visualisieren, ist ein integraler Bestandteil von Mikrosegmentierungslösungen. Visibility bietet dem Administrator, den Sicherheitsarchitekten und dem Chief Security Officer (CSO) einen Überblick über das gesamte Netzwerk aus einer Hand.

4. Einfach zu bedienende zentrale Steuerung

Die Erstellung einer Richtlinie für jede Anwendung kann zunächst eine schwierige Aufgabe sein. Dies erfordert eine Reihe von Gesprächen mit den IT-, Netzwerk- und Sicherheitsarchitekten. Eine zentrale Steuerung zur Erleichterung der Erstellung und Durchsetzung von Richtlinien trägt zur Beschleunigung des Prozesses bei. Die Nutzung der Segmentierungsvorlagen, die an das Microservice-Designmuster angepasst sind, kann ebenfalls hilfreich sein.

5. Leistung sollte nicht der Engpass sein

Die Anwendung von Mikrosegmentierungsrichtlinien erfordert die Analyse des Datenverkehrs und die effektive Implementierung von Richtlinien in Echtzeit. Der Angreifer kann Leistungsverzögerungen nutzen, um den Angriff weiter zu manifestieren. Daher ist es äußerst wichtig, die Leistung zu testen, insbesondere bei latenzempfindlichen Microservices.

Fazit

In diesem Blogbeitrag habe ich einige der Sicherheitsbedenken erörtert, die sich aus Container- und Kubernetes-basierten Bereitstellungsmechanismen ergeben, die von Microservices verwendet werden. Das Wort „Resilienz“ fällt langsam aus, wenn wir die Microservices in der Produktion während des gesamten CI/CD-Lebenszyklus kontinuierlich und schneller bereitstellen, ohne viel darüber nachzudenken, den Zugriff auf kritische Ressourcen einzuschränken. Die Mikrosegmentierung bietet einen starken Zugriffskontrollmechanismus, der die Auswirkungen von Sicherheitsverletzungen minimiert. Es fördert auch die Widerstandsfähigkeit der Unternehmensanwendungen durch die Implementierung sicherer Mikrozonen.

Wenn Mikrosegmentierung richtig geplant und durchgeführt wird, stellt sie sicherlich eine robuste Barriere gegen laterale Bewegungen in der Welt der Microservices dar. Es ist schwierig, Microservices abzusichern, während sie schnell voranschreiten, aber es ist wichtig, innezuhalten und über die Implementierung von Sicherheit und Resilienz in großem Maßstab nachzudenken und dies proaktiv mit allen Beteiligten zu planen.