Schauen wir uns zunächst einmal an, was in einem Unternehmen im Bereich IT-Sicherheit so alles passieren kann. In der Regel verfügt eine Organisation über eine Perimeterfirewall, die den eingehenden und ausgehenden Datenverkehr schützt – also den sogenannten vertikalen Datenfluss in Nord-Süd-Richtung. Was jedoch häufig fehlt, ist ein entsprechender Schutz für den horizontalen Datenverkehr, also den Ost-West-Datenfluss, der zwischen den internen Servern stattfindet. Betrachten wir dazu einmal ein mögliches Angriffsszenario: Ein Mitarbeiter im Unternehmen erhält eine E-Mail, deren Absender ein Angreifer ist. Die Nachricht enthält einen Anhang, den der Mitarbeiter öffnet und so sein System mit einer Malware infiziert.

In der Folge beginnt die Schadsoftware, sich innerhalb des Unternehmensnetzwerks weiterzuverbreiten von einem System zum nächsten, insbesondere auf den Servern. Da es keinen horizontalen Schutz innerhalb des Netzwerks gibt, kann sich ein Eindringling ungehindert ausbreiten. Schließlich gelangen sensible Unternehmensdaten über einen auf dem Host installierten, unentdeckten Agenten ins Internet zurück an den ursprünglichen Ab- sender der E-Mail, also an den Angreifer. Ob der IT-Abteilung ein solcher Vorfall überhaupt auffällt, ist oft fraglich. Daher ist ein proaktiver Schutz unerlässlich, um solche Sicherheitsvorfälle frühzeitig zu erkennen und den Schaden zu begrenzen.

Nutanix Flow ist tief in den AHV-Hypervisor von Nutanix integriert und bietet eine Absicherung des Ost-West-Datenverkehrs. Damit gemeint ist jener Netzwerkverkehr, der zwischen virtuellen Maschinen innerhalb der Nutanix-Plattform stattfindet – im Gegensatz zur Nord-Süd-Kommunikation, die üblicherweise von Perimeterfirewalls abgesichert wird. Genau hier liegt eine oft unterschätzte Schwachstelle, denn wer einmal Zugang zum internen Netzwerk hat, kann sich meist ungehindert "seitlich bewegen" (lateral movement). Flow setzt genau hier an mit einem verteilten Ansatz direkt auf Ebene der Virtualisierung.

Open-vSwitch-Datenverkehr bezeichnet dabei den Netzwerkdatenfluss, der über den virtuellen Switch "Open vSwitch", kurz OVS, geleitet wird. OVS ist eine softwarebasierte Netzwerkschicht, die virtuelle Maschinen oder Container in KVM netzwerktechnisch miteinander verbindet. Er unterstützt sowohl Layer-2- als auch Layer-3-Funktionalitäten und ermöglicht flexible Netzwerksteuerung, Monitoring und Automatisierung durch Schnittstellen wie etwa OpenFlow.

Die zentrale Steuerung von Flow erfolgt über Prism Central, das als Managementebene für sämtliche Netzwerkkonfigurationen, Sicherheitsrichtlinien und Überwachsungsfunktionen dient. Hier legen Sie Ihre Regeln fest, gruppieren Workloads nach logischen Kriterien und behalten gleichzeitig den Überblick über aktiven Datenverkehr. Die eigentliche Intelligenz der Steuerung liegt in einer Microservice Architektur im Prism Central, dem sogenannten "Network Controller". Dieser kommuniziert mit allen Hosts im Cluster (genau genommen auch Clustern, wenn man es für mehrere aktiviert) und sorgt dafür, dass die in Prism Central definierten Regeln korrekt auf den Komponenten verteilt werden. Die Hosts benötigen dafür keine aufwendige Konfiguration, sondern erhalten die Informationen direkt in einem Plug-in des Open vSwitch (OVS), der bei AHV immer implementiert ist.

Der Layer-2-Datenverkehr bezieht sich auf den Datenaustausch auf der Sicherungsschicht (Layer 2) des OSI-Modells. Diese Schicht ist zuständig für die direkte Kommunikation zwischen Geräten im gleichen Netzwerksegment und verwendet MAC-Adressen zur Adressierung. Typische Protokolle sind ARP, STP und LLDP. Layer-2-Datenverkehr umfasst zum Beispiel das Weiterleiten von Frames innerhalb eines lokalen Netzwerks (LAN), ohne dass dafür eine IP-Adressierung notwendig ist.

Die Durchsetzung der Regeln erfolgt dann auch genau hier, auf der Datenebene, direkt im Hypervisor beziehungsweise auf dem OVS. Aktivieren Sie Flow für einen Cluster, erzeugt der Network Controller auf dem OVS der Hosts eine weitere Bridge namens "brAtlas". Standardmäßig bekommt der Open vSwitch immer die Bridge "br0" für VM-Datenverkehr konfiguriert. Eine Bridge im OVS ist eine logische Instanz, die virtuelle Netzwerkschnittstellen von VMs mit den physischen Netzwerkschnittstellen der Hosts verbindet. Jedes virtuelle Interface einer VM wird dabei als Port auf dieser Bridge behandelt. Der Layer-2-Datenverkehr zwischen VMs kann so entweder direkt auf dem Host verbleiben oder – falls nötig (etwa durch verschiedene VLANs) - über die physischen Schnittstellen an das externe Netzwerk weitergegeben werden.

Während die Funktion von "br0" sich weitestgehend auf klassisches Switching beschränkt, kommt bei "brAtlas" eine entscheidende Erweiterung hinzu: Durch die Verzahnung mit dem Network Controller erhält der OVS die Möglichkeit, Traffic auf Layer 3 und 4 zu erkennen und zu unterbinden. Dadurch lassen Sie auf Basis von Protokollen und Ports direkt Firewallregeln auf dem Host anwenden. Der Traffic muss dabei nicht zu einer Perimeterfirewall fließen, denn sie ist im Switch der Virtualisierungsebene verankert. Durch die Integration in den OVS wird ebenfalls kein Agent in den VMs benötigt, für die VMs selbst ist die Anwendung der Regeln völlig transparent.

Wer mit Nutanix Flow arbeitet, merkt schnell, dass es hier nicht darum geht, IP-basierte Regeln in ewig langen Listen zu pflegen. Vielmehr geht es um die dynamische Definition von Regeln, die logisch umgesetzt werden. Der Schlüssel dazu liegt in dem Konzept der "Kategorien", die im Zentrum der Funktionsweise von Flow stehen.

Anstatt einzelne virtuelle Maschinen manuell mit Regeln zu versehen, erlaubt Flow das Gruppieren von VMs anhand von Kategorien. Diese sind im Prinzip frei definierbare "Key-Value-Pairs", wie zum Beispiel "Applikation: Datenbank" oder "Umgebung: Produktion". Jede VM darf mehreren Kategorien zugewiesen sein, und auch aus diesen entfernt werden, jederzeit und ohne Änderung innerhalb der VM oder Neustart. Das bietet gleich mehrere Vorteile. Zum einen entfällt die Notwendigkeit, sich um IP-Adressen und Subnetze kümmern zu müssen, zum anderen lassen sich Regeln damit auf logischer Ebene erstellen und verwalten – unabhängig davon, wo eine VM gerade läuft. Migrieren Sie VMs also zwischen Clustern innerhalb der gleichen Prism-Central-Instanz, wandern die Security-Einstellungen mit dieser VM an den neuen Standort.

Bei Nutanix dienen VM-Kategorien beziehungsweise VM-Categories dazu, virtuelle Maschinen logisch zu gruppieren, um Verwaltung, Automatisierung und Sicherheit zu vereinfachen. Es handelt sich dabei um einfache Tags oder Labels, die den VMs zugewiesen werden können. Diese Kategorien ermöglichen es dann, Richtlinien unter anderem auch für Netzwerkzugriff zentral auf mehrere VMs gleichzeitig anzuwenden.

Regeln werden in Flow dann zwischen diesen Kategorien formuliert. Sie können zum Beispiel definieren, dass VMs aus der "Applikation: Webserver" mit "Applikation: Middleware" nur über HTTPS/TCP 443 kommunizieren dürfen. Gleichzeitig sollen VMs in "Applikation: Middleware" nur über TCP 5432 mit "Applikation: PostgreSQL" reden. Während Sie in klassischen Sicherheitskonzepten jetzt IP-Adressen oder Hostnamen hinterlegen würden, die Sie dann mit jeder neuen Maschine prüfen oder anpassen, müssen Sie mit Flow nur noch beim Erstellen einer neuen virtuellen Maschine die gleichen Kategorien zuweisen. Sie verringern zeitlichen Aufwand wie auch das Risiko menschlicher Fehler bei manuellen Anpassungen von Firewallregeln.

Ein besonders wichtiger Aspekt dabei: Die Regeln greifen unabhängig von der physischen oder logischen Netzwerktopologie. Also auch dann, wenn sich zwei VMs im selben VLAN oder sogar auf demselben Host befinden. Das unterscheidet Flow deutlich von klassischen Security-Konzepten, in denen eine Trennung oft nur über Subnetze und/oder separate VLANs erfolgt.

Die Richtlinien lassen sich dabei in drei Kategorien unterteilen, die Flow in dieser Reihenfolge evaluiert. Zunächst gibt es die sogenannten "Quarantine Policies", die Sie nutzen, um VMs in Quarantäne zu versetzen, wenn diese sich "auffällig verhalten", oder bereits als kompromittiert gelten. Diese Richtlinien unterscheiden sich nochmal in zwei verschiedenen Varianten "Strict" oder "Forensic". Mit "Strict" unterbinden Sie sämtlichen Datenverkehr unmittelbar. Mit "Forensic" erlauben Sie einzelnen Datenverkehr wieder, etwa um das Verhalten von Schadsoftware nachzuweisen. Das Versetzen in Quarantäne kann manuell durch einen Administrator erfolgen oder bei Erkennung von Schadsoftware über einen API-Call.

Daneben gibt es die "Isolation Policies", die Kategorien vollständig voneinander isolieren. Diese kommen häufig zum Einsatz, wenn Sie Bereiche wie "Entwicklung", "Test" und "Produktion" voneinander trennen möchten. Diese Richtlinien ermöglichen Ihnen nur das Blockieren oder Erlauben von Traffic.

Schließlich wären da noch die "Application Policies". Diese definieren, welcher Verkehr zwischen bestimmten Kategorien erlaubt ist. In unserem Beispiel sind dies die Kategorien "Webserver", "Middleware" und "PostgreSQL". Sie bilden den Kern Ihrer Strategie zur Mikrosegmentierung, indem sie nur explizit Traffic erlauben und alles andere blockieren. Hier finden Sie auch die meiste "Nähe" zu den typischen Firewallregeln – Sie definieren Quelle, Ziel, Port, Protokoll und eine Aktion (Blockieren / Erlauben). Abseits von klassischen Bestandteilen von Firewallregeln, müssen Sie ebenfalls konfigurieren, ob VMs innerhalb dieser Kategorie miteinander kommunizieren dürfen.

Flow schaut also zuerst, ob sich eine VM in Quarantäne befindet. Ist dies nicht der Fall, folgt die Prüfung, ob Quelle und Ziel durch eine Isolation Policy getrennt sind. Hat es der Traffic bis hierher geschafft, evaluiert Flow dann, ob eine Application Policy zur Anwendung kommt. Gibt es keinen positiven Treffer bei einer Regel, darf der Traffic Ihres Workloads fließen.

Unter der Haube arbeitet Flow mit einem klar kontextbasierten Regelwerk. Die Regeln gelten auf Basis von Workload-Kategorien und den definierten Traffic-Parametern, wobei ausschließlich explizit erlaubter Verkehr zugelassen ist. Treffen mehrere Policies auf den gleichen Datenverkehr zu, entscheidet die Richtlinie mit der höheren Priorität. Innerhalb einer Policy werden alle zutreffenden Regeln bewertet und das strengste Ergebnis gilt. Hier besteht ebenso ein Unterschied zu klassischen Firewallregeln, die häufig das "First Match"-Prinzip anwenden.

Ein wichtiges Werkzeug für die erfolgreiche Implementierung von Flow ist die Monitoringfunktion für die Policies. Damit aktivieren Sie die Richtlinien zunächst "passiv". Der Traffic wird zwar analysiert, aber noch nicht geblockt. Die Funktion ist ideal, um herauszufinden, ob eine neue Regel ungewünschte Nebenwirkungen hat, etwa weil ein alter Service in Vergessenheit geraten ist. In der Praxis hat sich der Monitormodus als äußerst hilfreich erwiesen, denn damit können Sie die Richtlinien nach und nach implementieren, ohne unnötige Risiken einzugehen.

In der Theorie klingt Mikrosegmentierung mit Flow ziemlich elegant. In der Praxis stellt sich dann oft die Frage: Wie fange ich an, ohne alles umzubauen und den laufenden Betrieb zu stören? Und genau da zeigt sich ein großer Vorteil von Flow, denn Sie müssen Ihre Infrastruktur nicht umkrempeln. Es werden keine neuen VLANs geplant und auch keine Overlay-Netzwerke eingesetzt, wenn Sie nicht wollen.

Die Mikrosegmentierung in Flow funktioniert unabhängig von der physischen Netzwerkstruktur oder der Zugehörigkeit zu Subnetzen oder VLANs. Die Kontrolle erfolgt ausschließlich über die in Prism Central zugewiesenen Kategorien zu den Workloads. Diese logische Trennung ersetzt klassische Netzwerksegmentierung (oder erweitert diese) und erlaubt einen sehr flexiblen Einstieg. Ein bewährter erster Schritt ist es, den vorhandenen Datenverkehr sichtbar zu machen. Nutanix Flow unterstützt Sie dabei durch eine Traffic-Discovery-Funktion.

Diese zeigt auf, welche Verbindungen zwischen Ihren virtuellen Maschinen tatsächlich bestehen. Gerade in historisch gewachsenen Infrastrukturen ist das oft überraschend: Längst vergessene Services kommunizieren mit undokumentierten Systemen. Diese Dienste erfahren dann häufig unerwünschte Unterbrechungen durch die Implementierung neuer Regeln.

Diese Analyse bildet die Grundlage für Sie, um erste Regeln zu entwerfen. Auch nach der Analyse empfiehlt es sich, die neuen Regeln zunächst im Monitormodus zu betreiben. Wenn Sie sich an die Umsetzung wagen, lassen Sie sich Zeit. Mit dem Monitormodus protokolliert Flow für Sie, welche Verbindungen betroffen wären, hätten Sie diese Regeln durchgesetzt. Betrachten Sie dies als doppelten Boden, falls Abhängigkeiten in der ersten Analyse übersehen wurden. Erst wenn alles nachvollziehbar ist, sollten Sie die Richtlinie auf "Enforce" umstellen und damit nur noch den explizit erlaubten Verkehr zulassen.

An dieser Stelle werfen wir noch einen kurzen Blick auf das Overlay-Networking. Das ist ein Thema, das im Zusammenhang mit Software-defined Networking und Mikrosegmentierung häufig aufkommt – oft verbunden mit der Annahme, dass Mikrosegmentierung nur damit funktioniert. Tatsächlich ist das Gegenteil der Fall: Flow kann auch vollständig in einer klassischen VLAN-basierten Infrastruktur arbeiten.

Overlays sind optional und kommen nur dann ins Spiel, wenn eine zusätzliche logische Trennung (und Abstraktion vom physischen Netzwerk) erforderlich ist; beispielsweise bei Mandantentrennung oder gekapselten Lab/Dev-Umgebungen, die sich gemeinsame physische Netzwerke teilen. Für diese Szenarien nutzt Flow dann Geneve-Tunneling, wobei jeder Host ein Geneve-Tunnel-Endpunkt ist, also als Schnittstelle zum Ein- und Entkapseln des Overlay-Traffics dient. Aber auch wer keine Overlays nutzt, profitiert von denselben Security-Features mit der Mikrosegmentierung in Nutanix Flow.

Geneve-Tunneling steht für "Generic Network Virtualization Encapsulation" und ist ein Netzwerkprotokoll, das für die Kapselung von Datenverkehr in virtualisierten Netzwerken zum Einsatz kommt. Es ermöglicht den Transport von Layer-2- oder Layer-3-Daten über ein IP-Netzwerk, indem es den ursprünglichen Datenverkehr in ein IP-Paket einbettet. Geneve ist flexibel, erweiterbar und wurde als Nachfolger von VXLAN und GRE entwickelt. Es eignet sich besonders für moderne Rechenzentren und Cloudumgebungen, da es dynamische Netzwerkanpassungen und die Integration zusätzlicher Metadaten unterstützt.

Im laufenden Betrieb zeigt sich dann, wie effizient das System im Alltag funktioniert. Neue Workloads erhalten direkt beim Deployment ihre Kategorien, entweder automatisch per Blueprint, Skript oder eben manuell. Ab diesem Moment greifen alle bestehenden Regeln, ohne dass Sie IP-Tabellen oder Gruppenzugehörigkeiten auf Firewalls manuell editieren mussten. Für Operations-Teams bedeutet das weniger Aufwand, weniger Fehlerquellen und schnellere Reaktion auf Change-Requests. Auch Migrationen zwischen verschiedenen AHV-Hosts bleiben transparent, beispielsweise wenn alte Hardware durch neue ersetzt wird.

Über den Network-Controller des Prism Central bekommen die neuen Hosts in den Clustern die gleichen Richtlinien. Migrieren Sie also eine virtuelle Maschine, wandert der Security-Kontext gleich mit. Und auch wenn wir es zuvor erwähnt haben: Die Verarbeitung des Traffics findet weiterhin innerhalb des Hypervisors statt, jetzt eben auf einem neuen. Und das alles, ohne eine Firewall neu konfigurieren, das physische Netzwerk verändern oder Datenverkehr durch ein potenzielles Nadelöhr leiten zu müssen.

Bevor es mit der Analyse und Umsetzung weitergeht, werfen wir noch einmal einen Blick auf die erwähnte Bridge "brAtlas". Zur Erinnerung: Sie wird vom Network-Controller erzeugt und verwaltet die VLANs, die der Mikrosegmentierung dienen. Wenn Sie nicht auf der grünen Wiese starten, existieren häufig schon klassische VLANs (Basic-VLANs). Diese existieren direkt auf der "br0" auf dem vSwitch des AHVs und sind zunächst umzuwandeln. Für den Einstieg in Flow ist das kein Hindernis, denn Basic-VLANs lassen sich einfach in die neuen VLANs migrieren.

Ein häufiges Anwendungsszenario ist die Isolation zwischen Umgebungen mit unterschiedlichem Schutzbedarf. In vielen Rechenzentren teilen sich Entwicklungs-, Test- und Produktionssysteme dieselbe physische Infrastruktur. Ohne klare Trennung entsteht hier ein potenziell großes Einfallstor von einer Umgebung in die nächste. Mit Flow lässt sich die Separierung logisch und ohne zusätzliche Netzwerkschichten durchsetzen. Weisen Sie etwa einer VM die Kategorie "Umgebung: Produktion" zu und einer anderen "Umgebung: Entwicklung", lassen sich über eine Isolation-Policy sämtliche Verbindungen zwischen diesen Kategorien unterbinden. Es spielt dabei keine Rolle, ob sich beide VMs im selben VLAN oder Cluster befinden. So entsteht eine Trennung, wie sie in herkömmlichen Konzepten oft nur mit dedizierten Firewalls, Zonen oder separater Hardware möglich ist.

Ein weiterer, praxisbewährter Aspekt ist die schrittweise Einführung von Mikrosegmentierung. Gerade in gewachsenen Strukturen empfiehlt es sich, nicht sofort ein vollständiges Regelwerk aufzubauen, sondern mit wenigen, klar definierten Regeln zu beginnen. Wie erwähnt, nutzen Sie dazu unbedingt die Traffic-Discovery und aktivieren zunächst den Monitormodus für die Regeln. Beginnen Sie mit zentralen Diensten, die gut definiert und dokumentiert sind, etwa einem Code-Repository oder einer Datenbank. Diese Systeme sind als Beispiel für "klar definierte" Endpunkte zu sehen, mit wenig Variation in den Protokollen, mit denen sie angesprochen werden. Dementsprechend schnell lassen sich diese Systeme durch Application-Policies absichern, ohne andere Workloads zu beeinträchtigen. Parallel beobachten Sie die bestehenden Kommunikationen Ihrer Workloads und leiten daraus weitere Regeln und Kategorien ab. Denken Sie daran: Je kleiner die Veränderung, desto kleiner in der Regel auch die Auswirkung, sollte Ihnen mal ein Fehler unterlaufen.

Besonders greifbar wird der Nutzen von Flow, wenn wir klassische Firewallarchitekturen im Umfeld moderner Applikationen betrachten. Zuvor hatten wir das typische Beispiel der Trennung von Web-, Middleware- und Datenbank-Tier behandelt. Auch wenn Flow für solche Strukturen klare Vorteile bietet, zeigt es sein eigentliches Potenzial vor allem dort, wo Anwendungen dynamischer, verteilter und automatisierter werden. Schauen wir uns einen CI/CD-Usecase mit einer modernen Applikation an: Microservices kommunizieren dabei über einen gemeinsamen Message-Queue-Dienst wie RabbitMQ oder Kafka. Gleichzeitig greifen Build-Runner, beispielweise auf Basis von Jenkins oder GitLab CI, auf interne Repositories und Artefaktserver zu.

Wie bereits erwähnt, erfolgt auch hier die logische Trennung über Kategorien, etwa "CI: Runner" oder "CI: Repository". Die zugehörigen Policies definieren etwa HTTPS-Zugriffe vom Runner auf das Repository oder erlauben die NFS-Kommunikation vom Repository zum Storage-System. Hierfür müssen Sie weder Hostnamen noch IP-Adressen verwalten. Die gesamte Konfiguration erfolgt auf Basis der von Ihnen definierten Logik, nur über die Zugehörigkeit zu Kategorien.

Der Vorteil wird besonders deutlich, wenn Ihre Entwickler über die Deployment Pipelines ständig neue Rollouts ausführen. Flow sorgt dafür, dass auch neu erstellte Workloads automatisch die richtigen Regeln erhalten. Ihren Entwicklern haben Sie dabei nur mitgegeben, dass beim Ausführen des Deployments eine Kategorie für den Workload gesetzt werden muss, der Rest geschieht von allein. Was früher viele manuelle Freigaben und Änderungen an der Firewall erforderte, geschieht nun konsistent, reproduzierbar und automatisiert.

Und es gibt auch noch einen weiteren Aspekt im Zusammenhang mit Flow. In einer Umgebung mit Mikrosegmentierung ist jeder Workload durch granulare, zentral gesteuerte Sicherheitsrichtlinien abgesichert. Durch die Kontrolle des Traffics auf der Ebene des Hypervisors ist eine zusätzliche Firewall im Betriebssystem nicht mehr zwingend erforderlich. Das reduziert in jedem Fall Komplexität, vereinfacht das Management und minimiert Fehlkonfigurationen auf Hostebene. Letztlich verkleinert dies auch den Angriffsvektor, da sich eine Schwachstelle im Betriebssystem nicht zur Freischaltung sämtlichen Traffics für die Maschine nutzen lässt, denn dieser wird dank Flow nicht im Betriebssystem reguliert.

Nutanix Flow liefert mit seiner Integration in die Virtualisierungsebene eine moderne Antwort auf ein altbekanntes Problem: Wie lässt sich der Datenverkehr zwischen Systemen kontrollieren, ohne das Netzwerk neu zu erfinden? Die Stärke des Ansatzes liegt in seiner Nähe zur Infrastruktur, wodurch Regeln dort greifen, wo der Datenverkehr entsteht, und nicht erst an den Perimetern von einzelnen Netzwerken oder ganzen Rechenzentren. Besonders in dynamischen Umgebungen, in denen sich Systeme regelmäßig ändern, neue Applikationen entstehen oder Entwicklungszyklen kurz sind, spielt Flow seine Stärken aus. Kategorien ersetzen starre IP-Konzepte, zentrale Logik tritt an die Stelle voneinander losgelöster Regelwerke.

Admins definieren das Sicherheitsverhalten einheitlich und nachvollziehbar, unabhängig von der Anzahl der Systeme, auf welchem Host diese laufen oder wohin diese gerade verschoben werden. Flow ist kein Ersatz für alle bestehenden Sicherheitsmaßnahmen, aber eine sinnvolle Ergänzung im Inneren der Infrastruktur. Wo klassische Firewalls an ihre Grenzen stoßen, schafft Flow Sichtbarkeit und Kontrolle innerhalb des Clusters – ohne Agenten, separate Appliances und ohne tiefgreifende Änderungen im Netzwerkdesign. Wer sich mit Mikrosegmentierung beschäftigt, erhält mit Flow ein Werkzeug, das auf Effizienz und Klarheit setzt.