Cloud-Workload-Segmentierung
Cloud-Workload-Segmentierung ist eine Sicherheitspraxis, die den Datenverkehr zwischen einzelnen Arbeitslasten innerhalb eines Cloud-Netzwerks, wie einem VPC oder VNet, steuert. Es legt Richtlinien auf Arbeitslastebene fest, sodass der Angreifer bei einer kompromittierten Arbeitslast nicht frei auf die anderen umliegenden zugreifen kann. Wenn diese Richtlinie detailliert genug ist, um einzelne Arbeitslasten oder Prozesse zu isolieren, nennen die Leute es Cloud-Workload-Mikrosegmentierung.
Was ist der Unterschied zwischen Nord-Süd- und Ost-West-Verkehr in der Cloud?
Cloud-Sicherheit teilt den Datenverkehr oft in zwei Richtungen auf. Der Nord-Süd-Verkehr bewegt sich in der Cloud-Umgebung am Rand der Cloud. Ost-West-Verkehr bewegt sich seitwärts zwischen Arbeitslasten innerhalb desselben Netzwerks.
Native Cloud-Steuerungen steuern Nord-Süd gut. AWS Security Groups und Azure Network Security Groups (NSGs) entscheiden, was von außen an eine Arbeitslast gelangen darf. Aber sie tun viel weniger, um die Ost-West-Pfade innerhalb eines VPC oder VNet zu überwachen. Workloads im selben Subnetz können oft frei miteinander kommunizieren, unabhängig von den Perimeterregeln.
Diese Ost-West-Lücke ist wichtig, weil die meisten Angriffe nicht an der ersten Maschine enden. Ein Angreifer, der auf einer Arbeitslast landet, sucht nach einem Weg, die nächste zu erreichen – und die danach. Sicherheitsteams nennen dies seitliche Bewegung. Ransomware verhält sich genauso und breitet sich von Host zu Host aus, sobald es drinnen ist. Cloud-Workload-Segmentierung ist eine Form der Lateralbewegungsprävention in der Cloud und zentral zur Eindämmung der lateralen Bewegung von Ransomware: Sie begrenzt, wie weit eine Infektion sich ausbreiten kann.
Warum reichen AWS Security Groups und Azure NSGs nicht aus, um seitliche Bewegungen zu stoppen?
Sicherheitsgruppen und NSGs sind Zugriffskontrollen. Sie entscheiden, was mit einer Arbeitslast verbunden ist. Das ist eine nützliche Aufgabe, aber eine andere Aufgabe als die Eindämmung eines Durchbruchs, sobald ein Angreifer bereits drinnen ist.
Hier ist die Lücke in praktischer Hinsicht. Native Kontrollen werden zwischen Instanzen oder Subnetzen im VPC nicht im großen Maßstab durchgesetzt, sodass zwei Workloads im selben Subnetz sich meist ohne Einschränkung erreichen können. Sie vereinheitlichen sich auch nicht über Wolken hinweg. AWS, Azure und GCP haben jeweils ihre eigene Kontrollebene, Regelsyntax und Konsole, sodass ein Team, das alle drei betreibt, mehrere Richtlinienmodelle gleichzeitig jonglieren muss. Und sie geben dir keine sichere Möglichkeit, die Wirkung einer Regel zu testen, bevor sie live geht. Du erfährst, was eine Änderung kaputt macht, nachdem du sie verschickt hast.
Lift-and-Shift-Migrationen verschlimmern das. Wenn Teams Anwendungen direkt aus dem Rechenzentrum in die Cloud verlagern, kommen alte Ost-West-Verbindungen dazu. Niemand überprüft sie erneut, und sie bleiben standardmäßig offen.
Die Antwort ist die Segmentierung innerhalb des VPC selbst. Diese interne VPC-Segmentierung geht über Sicherheitsgruppen hinaus und erhöht die Kontrolle auf Workload-Ebene. Es gibt dir Cloud-Breach Containment: Sobald ein Angreifer drin ist, begrenzt die Richtlinie, wohin er reisen kann.
Ist die Segmentierung der Cloud-Arbeitsbelastung dasselbe wie eine Cloud-Firewall?
Nein. Eine Cloud-Firewall, wie eine Sicherheitsgruppe oder NSG, ist eine Perimeter-Zugriffskontrolle, die entscheidet, was von außen an eine Arbeitslast gelangen darf. Cloud-Workload-Segmentierung fügt eine Policy-Ebene zwischen den Arbeitslasten innerhalb des Perimeters hinzu, sodass ein bereits vorhandener Datenbruch enthalten ist, was eine Firewall allein nicht kann.
Wie funktioniert die Segmentierung von Cloud-Arbeitslasten eigentlich?
Die meisten Cloud-Segmentierungstools teilen einige Kernideen, auch wenn die Details unterschiedlich sind.
Richtlinien auf Arbeitsbelastungsebene. Anstatt sich nur auf Netzwerkgrenzen zu verlassen, platziert Segmentierung bei jeder Arbeitslast einen Kontrollpunkt. Manche Tools machen das mit einem leichtgewichtigen Agenten auf dem Betriebssystem. Andere lesen Cloud-Flow-Logs und schreiben Regeln direkt in native Controls wie NSGs und Sicherheitsgruppen, ohne dass der Agent überhaupt auf der Workload ist. Viele Plattformen unterstützen beide Wege, sodass Teams pro Workload den richtigen auswählen können.
Identitätsbasierte Politik. IP-Adressen ändern sich ständig in der Cloud. Workloads skalieren auf, verkleinern, verschieben sich und werden neu eingesetzt. Regeln, die mit IP-Adressen verknüpft sind, brechen, wenn das passiert. Moderne Segmentierung verknüpft Politik also mit der Workload-Identität und verwendet Bezeichnungen wie "Web Tier", "Production" oder "Datenbank". Die Richtlinie folgt dann der Arbeitsbelastung, wohin sie auch geht.
Politikmodellierung vor Durchsetzung. Das Einschalten der Durchsetzung ist der riskante Teil. Eine falsche Regel kann den Datenverkehr blockieren, den eine echte Anwendung benötigt. Bessere Tools erlauben es dir, Richtlinien zuerst im Entwurfsmodus zu schreiben, die mit echtem beobachtetem Datenverkehr getestet werden. Man kann sehen, welche Flows eine Regel blockieren und welche Anwendungen sie berühren würde, und das alles, bevor irgendetwas live geht. So können Teams zu normalen Arbeitszeiten arbeiten, anstatt auf ein Wechselfenster zu warten.
Graduierte Durchsetzung. Teams schalten selten direkt um und "blockieren alles". Ein gängiger Weg besteht darin, zunächst einige riskante oder Klartextdienste zu entfernen und dann auf ein Standard-Deny-Modell hinzuarbeiten, das nur bekannten Datenverkehr zulässt. Dieser Endzustand entspricht den Zero-Trust-Prinzipien: Least Privilege und kein implizites Vertrauen zwischen den Workloads.
Kann Cloud-Workload-Segmentierung KI-Geschwindigkeits- und Lateralbewegungsangriffe stoppen?
Die Angreifer sind schneller geworden. KI-unterstützte Werkzeuge helfen ihnen, die Umgebung zu kartieren und innerhalb von Minuten einen Weg darüber zu finden. Das ist KI-Angriff seitliche Bewegung mit Maschinengeschwindigkeit, und das ändert das Problem des Verteidigers. Wenn die Eindämmung darauf wartet, dass ein Mensch die Bedrohung erkennt und eine neue Regel schreibt, ist der Angreifer in der Regel bereits weitergezogen.
Hier hilft die ständige Segmentierung. Es handelt sich um eine Form der KI-schnellen Eindämmung von Sicherheitsverletzungen: automatisierte, arbeitslastbezogene Kontrolle, die bereits vor einem Vorfall vorhanden ist. Wenn die Richtlinie im Voraus festgelegt ist, gilt sie unabhängig davon, wie der Angreifer hineingekommen ist. Es muss den spezifischen Exploit nicht erkennen. Egal, ob der Eindringling eine gestohlene Zugangsdaten, ein Fernzugriffstool oder einen Zero-Day-Exploit verwendet hat – die Segmentierung begrenzt dennoch die Ausbreitung. Manche Teams nennen dies schwachstellen-agnostische Eindämmung, weil die Kontrolle auf den Weg und nicht auf den Fehler achtet.
Ein Beispiel aus der Praxis ist Microsoft. Nach dem Midnight Blizzard-Nation-State-Angriff setzte Microsoft Illumio über zig Millionen von Arbeitslasten ein, um seitliche Bewegungen in seiner hybriden Infrastruktur zu beobachten und einzudämmen. Es war das erste Mal, dass das Unternehmen öffentlich eine Drittanbieter-Sicherheitsplattform als Teil seiner internen Verteidigung benannte.
Worin unterscheidet sich Cloud-Workload-Segmentierung von Mikrosegmentierung, CDR und Zero Trust?
Cloud-Workload-Segmentierung liegt fast an einigen Begriffen, die Menschen oft verwechseln.
Netzwerksegmentierung vs. Mikrosegmentierung. Die traditionelle Netzwerksegmentierung teilt ein Netzwerk in große Zonen, oft entlang der Nord-Süd-Linien. Die Mikrosegmentierung wird feiner und legt Richtlinien zwischen einzelnen Workloads fest. Mikrosegmentierung ist eine Möglichkeit, granularere und dynamischere Zugriffsrichtlinien zu erstellen als traditionelle Netzwerksegmentierung.
Segmentierung vs. Cloud-Erkennung und -Reaktion (CDR). CDR beobachtet Bedrohungen, die sich bereits in der Umgebung bewegen, und alarmiert das Team. Segmentierung begrenzt, wo diese Bedrohungen überhaupt bewegen können. Die beiden funktionieren gut zusammen: Die Erkennung zeigt an, dass sich jemand im Inneren befindet, und die Segmentierung begrenzt, wie weit er kommt.
Segmentierung und Zero Trust. Zero Trust ist ein Sicherheitsmodell, das auf Least Privilege und ohne implizites Vertrauen basiert. Zero-Trust-Workload-Segmentierung ist eine der Hauptmethoden, mit denen Teams dieses Modell umsetzen, indem sie die Least-Privileg-Politik zwischen einzelnen Workloads anwendet.
Wie geht Illumio die Cloud-Workload-Segmentierung an?
Illumio ist ein Unternehmen zur Eindämmung von Sicherheitsverletzungen, und Cloud-Workload-Segmentierung ist ein zentraler Bestandteil seiner Plattform. Ein paar Details für Leser, die Optionen in diesem Bereich abwägen.
Illumio erzwingt labelbasierte Richtlinien über AWS, Azure, GCP, Rechenzentren, Container und Endpunkte von einer Steuerebene aus. Es unterstützt agentenlose Bereitstellungen, die VPC- und VNet-Flussprotokolle lesen und Richtlinien in native Cloud-Steuerungen schreiben. Es bietet außerdem einen agentenbasierten Modus für Workloads, die eine Steuerung auf Betriebssystemebene benötigen. Dieser Agent läuft im Benutzerraum. Es sitzt nicht im Inline mit dem Verkehr und inspiziert keine Pakete, und die Richtlinie gilt auch bei Neustarts und Neustarts. Draft-Mode-Modellierung ermöglicht es Teams, Regeln gegen echten Verkehr zu testen, bevor die Durchsetzung live geht.
Anfang 2026 wurde Illumio im Gartner Peer Insights Voice of the Customer-Bericht für Netzwerksicherheitsmikrosegmentierung als Customers' Choice ausgezeichnet – einer von nur zwei Anbietern, die diese Auszeichnung in diesem Zeitraum erhielten.
Häufig gestellte Fragen
Was ist Cloud-Workload-Segmentierung?
Es ist die Praxis, den Datenverkehr zwischen einzelnen Workloads innerhalb eines Cloud-Netzwerks wie einem VPC oder VNet zu steuern. Es fügt eine Richtlinienschicht auf Workload-Ebene hinzu, über einen Betriebssystemagenten oder indem Regeln in native Cloud-Kontrollen geschrieben werden, sodass eine kompromittierte Arbeitslast nicht frei andere im selben Subnetz erreichen kann. Wenn die Richtlinie granular genug wird, um einzelne Workloads zu isolieren, nennt man es Mikrosegmentierung.
Was ist der Unterschied zwischen Nord-Süd- und Ost-West-Verkehr?
Nord-Süd-Verkehr bewegt sich in eine Cloud-Umgebung an seinem Rand. Ost-West-Verkehr bewegt sich seitwärts zwischen Arbeitslasten innerhalb desselben Netzwerks. Native Cloud-Firewalls konzentrieren sich auf Nord-Süd. Ost-West ist der Ort, an dem Angreifer reisen, sobald sie drinnen sind, und es ist die Traffic-Cloud-Segmentierung, die die Segmentierung steuern soll.
Ist die Segmentierung der Cloud-Arbeitsbelastung dasselbe wie eine Cloud-Firewall?
Nein. Eine Cloud-Firewall, wie eine Sicherheitsgruppe oder NSG, ist eine Perimeter-Zugriffskontrolle, die entscheidet, was von außen an eine Arbeitslast gelangen darf. Cloud-Workload-Segmentierung fügt eine Policy-Ebene zwischen den Arbeitslasten innerhalb des Perimeters hinzu, sodass ein bereits vorhandener Datenbruch enthalten ist, was eine Firewall allein nicht kann.
Wie sichert man Ost-West-Verkehr in einem Cloud-VPC oder VNet?
Du fügst eine Segmentierung auf Arbeitsbelastungsebene hinzu. Das bedeutet, an jeder Arbeitslast einen Kontrollpunkt zu platzieren, entweder mit einem leichtgewichtigen Agenten auf dem Betriebssystem oder indem man Cloud-Flow-Logs liest und Richtlinien in native Controls wie NSGs und Sicherheitsgruppen schreibt. Gute Tools ermöglichen es Ihnen, die Auswirkungen einer Regel vor der Durchsetzung einer Regel mit realem Verkehr zu modellieren, damit Sie nicht versehentlich eine funktionierende Anwendung kaputtmachen.
Warum reichen AWS Security Groups und Azure NSGs für sich allein nicht aus?
Sie sind Zugangskontrollen, keine Schutzinstrumente für Brucheindämmungen. Sie entscheiden, was von außen an eine Arbeitslast gelangen kann, aber sie verhindern nicht, dass eine kompromittierte Arbeitslast ihre Nachbarn im selben Subnetz erreicht. Sie vereinheitlichen sich auch nicht über Wolken hinweg und bieten dir keine sichere Möglichkeit, eine Regel zu testen, bevor sie live geht. Die Segmentierung fügt die fehlende Ost-West-Kontrolle hinzu.
Was ist der Unterschied zwischen Cloud Detection and Response (CDR) und Mikrosegmentierung?
CDR entdeckt bereits Bedrohungen in der Umgebung und alarmiert das Team. Mikrosegmentierungsgrenzen, wo sich diese Bedrohungen überhaupt bewegen können. Die beiden ergänzen sich. Wenn ein Angriff schneller voranschreitet, als eine Person reagieren kann, ist die bereits vorhandene Eindämmung wichtiger.
Kann Mikrosegmentierung KI-gesteuerte Angriffe stoppen?
Ja. Obwohl es einen Angreifer nicht daran hindern kann, einzudringen, begrenzt es, wie weit er sich ausbreitet, sobald er es tut, und das ohne zu warten, bis jemand die Bedrohung zuerst identifiziert. KI-unterstützte Angriffe bewegen sich innerhalb von Minuten über ein Netzwerk, schneller als eine manuelle Antwort mithalten kann. Da die Segmentierungsrichtlinie bereits vorhanden ist, enthält sie den Explosionsradius unabhängig davon, welches Exploit oder welche Zugangsdaten der Angreifer verwendet hat, und ohne darauf zu warten, dass jemand zuerst die Bedrohung identifiziert.
Verwandte Begriffe
Mikrosegmentierung, Lateralbewegung, Zero Trust, Breach Containment, Ost-West-Verkehr, Cloud-Erkennung und -Reaktion (CDR).
.png)


%20(1).webp)
.webp)














