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

"Cybersicherheit" deckt ein breites Spektrum an Themen ab, von denen einige Netzwerkprioritäten, Hostprioritäten, Authentifizierung, Identität, Automatisierung, Compliance und mehr umfassen. Die Mikrosegmentierung ist ein Teil dieses umfassenderen Prinzips, aber viele glauben immer noch, dass es eine Herausforderung ist, sie in großem Maßstab zu implementieren.

Alle modernen Workloads enthalten eine integrierte Firewall und einen Portfilter, z. B. iptables unter Linux. Die Konfiguration für einzelne Workloads ist relativ einfach, aber dies in großem Maßstab zu tun, ist oft eine Herausforderung. Und dies bei der sich entwickelnden Migration von monolithischen Workloads zu Microservices macht es noch schwieriger, diese Herausforderung zu operationalisieren. Das Ergebnis ist, dass die Segmentierung auf der Workload-Ebene der Architektur häufig nicht durchgeführt wird, sondern diese Aufgabe einfach der zugrunde liegenden Netzwerkstruktur zur Implementierung überlassen wird. Dieser Ansatz führt zu einem Prioritätenkonflikt, da die Netzwerksegmentierung häufig aus anderen Gründen implementiert wird, als dies für die 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, das menschliche Element so weit wie möglich zu entfernen, denn je mehr ein Mensch in den Betriebsprozess eingebunden ist, desto wahrscheinlicher ist es, dass Fehlkonfigurationen und Fehler auftreten können. Und die Unterstützung umfangreicher Architekturen bedeutet, die Segmentierungsautomatisierung so zu ermöglichen, dass Hindernisse in der Gesamtarchitektur vermieden werden, nachdem eine bestimmte Skalierung erreicht ist.

Diese Anforderungen können auf zwei Arten umgesetzt werden: ein "schwerer" Ansatz oder ein "leichter" 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 besprechen, was wir als "schweren" Ansatz betrachten. Umfangreichere Ansätze, wie z. B. Cisco Tetration, konzentrieren sich auf die Erfassung jedes Pakets aus jedem Workload, die Durchführung von Netzwerkanalysen in der gesamten Netzwerkstruktur und erfordern ein erhebliches Maß an menschlichem Eingreifen bei der Implementierung von Segmentierungsrichtlinien in großem Maßstab. Die Operationalisierung solcher Tools ist recht komplex und kann daher als "schwerfälliger" Ansatz zur Implementierung von Mikrosegmentierung beschrieben werden.

Im Gegensatz dazu wurden "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 der Workload-Ebene und sind bewusst agnostisch, wie das zugrunde liegende Netzwerk implementiert wird, und überlassen die Aufgabe der Netzwerkanalyse den Netzwerktools. Mit diesem Ansatz wird die Implementierung von Segmentierungsrichtlinien rationalisiert, wobei der Schwerpunkt auf der Automatisierung liegt und nur wenig 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 erreicht sie eine operationelle Obergrenze. Irgendwann wird eine komplexe Lösung ein Hindernis dafür darstellen, wie weit die gesamte Workload-Segmentierungsarchitektur skaliert werden kann.

Schwerere, komplexere Lösungen für die Mikrosegmentierung funktionieren bei kleineren Anwendungsfällen, aber wenn diese Anwendungsfälle wachsen, werden sie schließlich den betrieblichen Overhead belasten und eine harte Grenze erreichen. Zu diesem Zeitpunkt bleiben zusätzliche Arbeitslasten oft ungeschützt, und die Automatisierung beginnt zusammenzubrechen. Wenn die Lösung mehr Aufgaben ausführt, wird die Komplexität schließlich zu einer betrieblichen Belastung.

Anbieter von Mikrosegmentierungslösungen veröffentlichen häufig Zahlen, die ihre Obergrenze für verwaltete Workloads widerspiegeln, und diese Zahlen scheinen groß genug zu sein, um das erwartete Wachstum zu bewältigen. Da jedoch immer mehr Unternehmen Hybrid-Cloud-Architekturen einführen, entstehen durch die Virtualisierung viel mehr Workloads als bei herkömmlichen Bare-Metal-Hosts. Und Microservices-Architekturen erzeugen eine erhebliche zusätzliche Anzahl von IP-adressierbaren Entitäten innerhalb eines Hosts, was dazu führt, dass die Gesamtzahl der Workloads schnell ansteigt. Die Anzahl der verwalteten Workloads sollte nicht durch die Tools bestimmt werden, die zur Operationalisierung der Segmentierung verwendet werden. Um einen ununterbrochenen Wachstumszyklus der Arbeitslast zu gewährleisten, sollten Sie niemals davon ausgehen, dass eine kleinere Anzahl ausreicht.

Um die Mikrosegmentierung in einer sich entwickelnden Hybrid-Cloud-Architektur zu automatisieren, sollte die Lösung nicht zusammenbrechen, wenn eine obere Zahl erreicht ist.

Automatisierung ≠ Menschen

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

Illumio, als Beispiel für einen schlanken Ansatz, verwendet das Konzept der vierdimensionalen Labels und des Application Ringfencing, um den Prozess der Anwendung der Segmentierung auf eine Workload zum Zeitpunkt ihrer Einführung zu vereinfachen und zu automatisieren. Es ermöglicht dem Administrator, Segmentierungsgrenzen automatisch vorzuschlagen oder dem Administrator zu ermöglichen, diese Grenzen zu definieren. Dadurch wird das Risiko, dass durch menschliches Eingreifen versehentlich ein Fehler ausgelöst wird, deutlich reduziert.

Die meisten umfangreichen Lösungen, wie z. B. Tetration, enthalten Optionen zum Anwenden von Tags auf Workloads, um sie unabhängig von der IP-Adressierung zu verfolgen. Allerdings ist der Prozess "schwer", komplex und erfordert ein erhebliches Maß an anfänglicher menschlicher Interaktion und Fachwissen, um ihn zu operationalisieren. Und wie Sie sich vorstellen können, ist das Risiko für unbeabsichtigte Fehler umso größer, je mehr ein Prozess menschliches Eingreifen und Fachwissen erfordert.

Wenn Sie die Automatisierung der Workload-Segmentierung planen, sollten Sie diese Regel im Hinterkopf behalten: Je komplexer der Prozess, desto höher das Risiko.

Einführung von Microservices, mehr Workloads erwarten

Die Migration der Anwendungsentwicklung von monolithischen Workloads zu Microservices führt zu einer erheblichen Erhöhung der Anzahl der zu verwaltenden Workloads. Mit dem Aufkommen der Virtualisierung konnte ein einzelner Bare-Metal-Host viele VMs verwalten, von denen jede über eine eigene IP-Adresse verfügte. Und jetzt, mit dem Aufkommen von Microservices, kann jede dieser VMs 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 der Workloads, die überwacht werden müssen, erfordert eine Lösung, die auf sehr große Zahlen skaliertwerden kann.

Visualisierung ist oberstes Gebot

Das Überwachen einer Workload bedeutet zwei grundlegende Dinge: das Erzwingen von Richtlinien und die Visualisierung. Aber wie visualisieren Sie, was Anwendungen über eine große Anzahl von Workloads hinweg miteinander tun? Die Visualisierung der Workload-Kommunikation darf nicht von der Netzwerksegmentierung abhängig sein. Im Fall von Microservices geht der Bedarf an Visualisierung über den VM-zu-VM-Datenverkehr hinaus und muss die Kommunikation zwischen Pods, Knoten und Diensten umfassen, wenn Kubernetes oder OpenShift zur Orchestrierung von Container-Lebenszyklen verwendet werden.

Umfangreiche Lösungen wie Tetration können Richtlinien in einer containerisierten Umgebung durchsetzen, aber die Visualisierung des Anwendungsdatenverkehrs innerhalb dieser Konstrukte ist begrenzt. Diese Lösungen können häufig eine visuelle Karte des Datenverkehrs zwischen Hosts erstellen, aber die Ansicht hört dort auf, und der Datenverkehr zwischen containerisierten Konstrukten innerhalb eines Hosts fehlt. Auf der anderen Seite erweitert eine schlanke Lösung die Transparenz von Bare-Metal-Hosts über VMs bis hin zu allen containerisierten Konstrukten innerhalb eines Hosts. Alle Workloads, ob monolithisch oder containerisiert, sind vollständig sichtbar, wenn Illumio beispielsweise seine Application Dependency Map erstellt.

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 in verschiedenen Computing-Ressourcen weiterentwickeln, sowohl in lokalen Rechenzentren als auch in Public Cloud-Fabrics. Die Visualisierung wird immer wichtiger, da diese Details komplexer und dynamischer werden, um für Menschen lesbare, deklarative Richtlinien zu erstellen und durchzusetzen.

Das Fazit

Bei der Entscheidung, wie die Workload-Segmentierung in großem Umfang 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 das Ziel Geschwindigkeit und Agilität auf dem Wasser ist, gilt das Gleiche für die Art und Weise, wie Mikrosegmentierung in modernen Hybrid Clouds und Compute Fabrics eingesetzt wird. Reduzieren Sie die Komplexität und halten Sie die Lösung "leicht", nicht "schwer".