Best Practices für die Workload-Segmentierung: schlank und schlank oder schwer und komplex?

„Cybersicherheit“ deckt ein breites Themenspektrum ab, von denen einige Netzwerkprioritäten, Host-Prioritäten, Authentifizierung, Identität, Automatisierung, Compliance und vieles mehr umfassen. Mikrosegmentierung ist ein Teil dieses umfassenderen Prinzips, aber viele glauben immer noch, dass es eine Herausforderung ist, es in großem Maßstab umzusetzen.

Alle modernen Workloads enthalten eine integrierte Firewall und einen Portfilter, wie z. B. iptables unter Linux. Dies für einzelne Workloads zu konfigurieren ist relativ einfach, aber in großen Maßstäben ist dies oft eine Herausforderung. Und wenn man das bei der zunehmenden Migration von monolithischen Workloads zu Microservices tut, wird die Operationalisierung dieser Herausforderung noch schwieriger. Das Ergebnis ist, dass die Segmentierung auf der Workload-Ebene der Architektur häufig nicht erfolgt, sondern diese Aufgabe einfach der zugrunde liegenden Netzwerkstruktur mit der Implementierung überlassen wird. Dieser Ansatz führt zu einem Prioritätenkonflikt, da die Netzwerksegmentierung häufig aus anderen Gründen implementiert wird, als es bei der Workload-Segmentierung erforderlich ist.

Zwei wichtige Anforderungen für die Segmentierung auf Workload-Ebene sowohl in Hybrid-Cloud- als auch in Microservices-Architekturen sind die Automatisierung und die Unterstützung umfangreicher Architekturen. Automatisierung bedeutet, dass der Faktor Mensch so weit wie möglich ausgeschlossen wird, denn je mehr ein Mensch in den Betriebsprozess involviert ist, desto wahrscheinlicher ist es zu Fehlkonfigurationen und Fehlern. Und die Unterstützung umfangreicher Architekturen bedeutet, die Segmentierungsautomatisierung so zu ermöglichen, dass Hindernisse in der Gesamtarchitektur vermieden werden, wenn eine bestimmte Größenordnung erreicht ist.

Diese Anforderungen können auf zwei Arten umgesetzt werden: mit einem „schweren“ Ansatz oder einem „leichten“ Ansatz. Vergleichen wir diese beiden Ansätze, um herauszufinden, welcher für Sie und Ihr Unternehmen am sinnvollsten ist.

Eine Geschichte von zwei Ansätzen zur Mikrosegmentierung

Lassen Sie uns zunächst einen unserer Meinung nach „schweren“ Ansatz erörtern. Schwerwiegendere Ansätze, wie beispielsweise Cisco Tetration, konzentrieren sich darauf, jedes Paket aus jedem Workload zu erfassen, Netzwerkanalysen in der gesamten Netzwerkstruktur durchzuführen und bei der Umsetzung der Segmentierungsrichtlinien in großem Maßstab ein erhebliches Maß an menschlichem Eingreifen zu erfordern. Die Operationalisierung solcher Tools ist recht komplex und kann daher als „schwerfälliger“ Ansatz zur Implementierung von Mikrosegmentierung bezeichnet werden.

Im Gegensatz dazu waren „leichte“ Ansätze wie Illumio speziell für die Mikrosegmentierung entwickelt. Sie wurden nicht als ein Produkt geboren und später in ein anderes Produkt umgewandelt. Sie konzentrieren sich ausschließlich auf die Segmentierung auf Workload-Ebene und sind bewusst unabhängig davon, wie das zugrunde liegende Netzwerk implementiert wird, sodass die Netzwerkanalyse den Netzwerktools überlassen wird. Mit diesem Ansatz wird die Umsetzung der Segmentierungsrichtlinien rationalisiert, wobei der Schwerpunkt auf der Automatisierung liegt und kaum oder gar kein menschliches Eingreifen erforderlich ist.

Wann wird die Segmentierung meine Architektur kaputt machen?

Es ist eine Binsenweisheit, aber es lohnt sich, sie zu wiederholen: Je komplexer die Lösung, desto eher wird sie eine operationelle Obergrenze erreichen. Irgendwann kommt es bei einer komplexen Lösung zu einem Hindernis, wie weit die gesamte Workload-Segmentierungsarchitektur skaliert werden kann.

Schwerere, komplexere Lösungen für die Mikrosegmentierung eignen sich für kleinere Anwendungsfälle, aber wenn diese Anwendungsfälle zunehmen, werden sie irgendwann den betrieblichen Aufwand belasten und an eine harte Grenze stoßen. An diesem Punkt bleiben zusätzliche Workloads oft ungeschützt und die Automatisierung beginnt zu versagen. Wenn die Lösung mehr Aufgaben erfüllt, wird die Komplexität letztendlich zu einer betrieblichen Belastung.

Anbieter von Mikrosegmentierungen veröffentlichen häufig Zahlen, die ihre Obergrenze an verwalteten Workloads widerspiegeln, und diese Zahlen scheinen groß genug zu sein, um dem erwarteten Wachstum Rechnung zu tragen. Da jedoch immer mehr Unternehmen Hybrid-Cloud-Architekturen einführen, verursacht die Virtualisierung viel mehr Workloads, als dies bei herkömmlichen Bare-Metal-Hosts der Fall ist. Und Microservices-Architekturen erzeugen eine erhebliche zusätzliche Anzahl von IP-adressierbaren Entitäten innerhalb eines Hosts, wodurch die Gesamtzahl der Workloads schnell ansteigt. Die Anzahl der verwalteten Workloads sollte nicht von den Tools bestimmt werden, die zur Operationalisierung der Segmentierung verwendet werden. Gehen Sie niemals davon aus, dass eine geringere Anzahl ausreicht, um einen ununterbrochenen Workload-Wachstumszyklus zu gewährleisten.

Um die Mikrosegmentierung in jeder sich entwickelnden Hybrid-Cloud-Architektur zu automatisieren, sollte die Lösung nicht zusammenbrechen, nachdem eine bestimmte Obergrenze erreicht ist.

Automatisierung ≈ Menschen

Automatisierung erfordert eine schlanke, optimierte Architektur. Ein großer Prozentsatz der Sicherheitslücken in jeder Cloud-Umgebung ist auf ehrliche Fehler von Administratoren zurückzuführen. Da die Lebenszyklen von Workloads immer dynamischer werden und die Bereiche, in denen sie sich in Netzwerksegmenten befinden, immer kurzlebiger werden, wird es immer wichtiger, Sicherheitsprozesse zu automatisieren und das erhebliche Risiko zu beseitigen, das durch menschliche Eingriffe in den Betriebsprozess entsteht.

Illumio verwendet als Beispiel für einen leichten Ansatz das Konzept von vierdimensionale Beschriftungen und Anwendungs-Ringfencing, um den Prozess der Anwendung der Segmentierung auf einen Workload zum Zeitpunkt seiner Einführung zu vereinfachen und zu automatisieren. Es ermöglicht, Segmentierungsgrenzen automatisch vorzuschlagen oder es dem Administrator zu ermöglichen, diese Grenzen zu definieren. Dadurch wird das Risiko, dass durch menschliches Eingreifen versehentlich ein Fehler verursacht wird, erheblich reduziert.

Die meisten umfangreichen Lösungen, wie Tetration, bieten Optionen zum Anbringen von Tags auf Workloads, um sie unabhängig von der IP-Adressierung zu verfolgen. Allerdings ist der Prozess „schwer“, komplex und erfordert zunächst ein erhebliches Maß an menschlicher Interaktion und Fachwissen, um ihn operationalisieren zu können. Und wie Sie sich vorstellen können, ist das Risiko unbeabsichtigter Fehler umso größer, je mehr ein Prozess menschliches Eingreifen und Fachwissen erfordert.

Beachten Sie bei der Planung der Automatisierung der Workload-Segmentierung diese Regel: Je komplexer der Prozess, desto höher das Risiko.

Microservices einführen, mehr Workloads erwarten

Die Migration der Anwendungsentwicklung von monolithischen Workloads zu Microservices hat den Effekt, dass die Anzahl der zu verwaltenden Workloads erheblich steigt. Mit dem Aufkommen der Virtualisierung konnte ein einziger Bare-Metal-Host viele virtuelle Maschinen verwalten, von denen jede ihre eigene IP-Adresse hatte. Und jetzt, mit dem Aufkommen von Microservices, kann jede dieser virtuellen Maschinen viele containerisierte Konstrukte hosten, was zu noch mehr IP-Adressen führt.

Wenn jede Entität in einem Netzwerk mit einer IP-Adresse als Workload definiert ist, kann eine Microservices-Umgebung die Anzahl der Workloads explodieren lassen. Die schiere Anzahl von Workloads, die überwacht werden müssen, erfordert eine Lösung, die auf sehr große Zahlen skalieren.

Visualisierung ist von größter Bedeutung

Die Überwachung einer Arbeitslast bedeutet zwei grundlegende Dinge: die Durchsetzung von Richtlinien und die Visualisierung. Aber wie visualisieren Sie, was Anwendungen bei einer großen Anzahl von Workloads gegenseitig antun? Die Visualisierung der Workload-Kommunikation kann nicht abhängig sein von Netzwerksegmentierung. Im Fall von Microservices geht der Bedarf an Visualisierung über den Datenverkehr von VM zu VM hinaus und muss auch die Kommunikation zwischen Pods, Knoten und Diensten umfassen, wenn Kubernetes oder OpenShift zur Orchestrierung von Container-Lebenszyklen verwendet werden.

Schwere Lösungen wie Tetration können Richtlinien in einer containerisierten Umgebung durchsetzen, aber die Visualisierung des Anwendungsverkehrs innerhalb dieser Konstrukte ist begrenzt. Diese Lösungen können oft eine visuelle Karte des Datenverkehrs zwischen Hosts erstellen, aber die Ansicht endet dort, und der Verkehr zwischen containerisierten Konstrukten innerhalb eines Hosts fehlt. Auf der anderen Seite erweitert eine schlanke Lösung die Sichtbarkeit von Bare-Metal-Hosts bis hin zu virtuellen Rechnern und allen containerisierten Konstrukten innerhalb eines Hosts. Alle Workloads, ob monolithisch oder containerisiert, sind vollständig sichtbar, wenn Illumio beispielsweise ihre Anwendungsabhängigkeitskarte.

Die Visualisierung des gesamten Anwendungsdatenverkehrs und -verhaltens, unabhängig davon, wie er gehostet wird, ist unerlässlich, da sich Ihre Workloads in der Hybrid Cloud und verschiedenen Rechenressourcen sowohl in lokalen Rechenzentren als auch in öffentlichen Cloud-Fabrics weiterentwickeln. Die Visualisierung wird immer wichtiger, da diese Details komplexer und dynamischer werden, um sie zu erstellen und durchzusetzen menschenlesbare, deklarative Politik.

Die Quintessenz

Bei der Entscheidung, wie die Workload-Segmentierung skaliert und automatisiert implementiert werden soll, ist ein schlanker und optimierter Ansatz die einzig praktikable Option. Ähnlich wie der Einsatz eines Schnellboots manchmal die bessere Wahl ist als der Einsatz eines Schlachtschiffs, wenn Geschwindigkeit und Agilität auf dem Wasser das Ziel sind, gilt dasselbe für die Art und Weise, wie Mikrosegmentierung in modernen Hybrid-Clouds und Compute-Fabrics eingesetzt wird. Reduzieren Sie die Komplexität und achten Sie darauf, dass die Lösung „leicht“ und nicht „schwer“ ist.