Zero-Trust-Netzwerke in der Private Cloud

Zero Trust ist einer jener Begriffe, die so oft benutzt wurden, dass sie nichts mehr zu bedeuten drohen. Anbieter prägen ihn auf Produkte, Analysten bauen Rahmenwerke darum, und irgendwo im Lärm geht die eigentliche Idee verloren. Schneidet man das Marketing weg, ist Zero Trust erfrischend einfach: Hören Sie auf anzunehmen, dass etwas in Ihrem Netzwerk sicher ist, nur weil es sich darin befindet. Jede Anfrage auf den Zugriff auf eine Ressource muss authentifiziert, autorisiert und verifiziert werden — jedes Mal, unabhängig davon, woher sie kommt.

Dieses Prinzip ist leicht ausgesprochen und überraschend anspruchsvoll umzusetzen, besonders in einer Private Cloud, in der Dutzende Dienste ständig miteinander sprechen. Dieser Artikel betrachtet, was Zero Trust jenseits der Schlagworte wirklich bedeutet und wie seine Prinzipien speziell für den Verkehr innerhalb einer Private Cloud gelten — den Ost-West-Verkehr, den klassische Sicherheitsmodelle nahezu vollständig ignorieren.

Das Problem mit Burg und Burggraben

Jahrzehntelang folgte Netzwerksicherheit einem Burg-und-Burggraben-Modell. Ein starker Perimeter — Firewalls, VPNs, Angriffserkennung — bewachte die Grenze zwischen dem vertrauenswürdigen internen Netz und dem feindlichen Internet. War man einmal drinnen, galt man als vertrauenswürdig. Man konnte mehr oder weniger mit allem sprechen.

Der Fehler dieses Modells ist brutal und gut dokumentiert. Sobald ein Angreifer hineingelangt — ein abgefischter Zugang, ein kompromittierter Server, ein böswilliger Insider —, bietet der Perimeter keinen weiteren Schutz. Er kann sich seitlich bewegen, von Maschine zu Maschine durch das weiche Innere springen, weil ihn drinnen nichts hinterfragt. Die meisten ernsthaften Eindrüche sind kein einzelner dramatischer Mauerdurchbruch; sie sind ein kleiner anfänglicher Brückenkopf, gefolgt von stiller Seitwärtsbewegung hin zu den Daten, auf die es ankommt. Die Burg hält das Tor verschlossen und lässt zugleich jede Innentür weit offen.

Drei Prinzipien, die Zero Trust wirklich ausmachen

Unter dem Marketing ruht Zero Trust auf einigen konkreten Prinzipien, die man klar benennen sollte.

Niemals vertrauen, immer prüfen

Keiner Anfrage wird aufgrund ihrer Herkunft vertraut. Eine Verbindung aus dem Inneren des Rechenzentrums wird mit derselben Strenge behandelt wie eine aus dem öffentlichen Internet. Identität und Berechtigung werden bei jedem Zugriff geprüft, nicht einmalig am Perimeter.

Geringstes Privileg

Jede Identität — Nutzer, Dienst oder Workload — erhält genau den Zugriff, den sie für ihre Aufgabe braucht, und nicht mehr. Ein Web-Frontend, das einen Datenbankport erreichen muss, sollte diesen erreichen können, und nur diesen. Der Wirkungsradius einer einzelnen Kompromittierung wird bewusst klein gehalten.

Von einem Eindringen ausgehen

Planen Sie so, als sei ein Angreifer bereits drinnen, denn irgendwann wird einer es sein. Diese Haltung verlagert den Aufwand vom reinen Draußenhalten hin zum Begrenzen dessen, was jemand drinnen anrichten kann, und zum schnellen Entdecken. Es ist der Unterschied zwischen einer einzigen harten Schale und vielen inneren Kontrollpunkten.

Warum der Ost-West-Verkehr das eigentliche Schlachtfeld ist

In einer Private Cloud berührt der überwältigende Großteil des Netzwerkverkehrs nie den Perimeter. Er ist ost-westlich: virtuelle Maschinen, die mit anderen virtuellen Maschinen sprechen, Anwendungsschichten, die Datenbanken aufrufen, Microservices, die quer über die Fabric miteinander plaudern. Eine klassische Firewall am Rand sieht nichts davon, was bedeutet, dass Seitwärtsbewegung in einem blinden Fleck stattfindet.

Genau hier verdient sich Zero Trust innerhalb der Cloud seinen Lohn. Statt eines Perimeters schaffen Sie viele kleine — Mikroperimeter — um einzelne Workloads oder Gruppen von Workloads. Jeder Dienst darf nur mit den konkreten Diensten sprechen, die er legitim braucht. Ein Angreifer, der eine virtuelle Maschine kompromittiert, stellt fest, dass sie weder den Datenbank-Cluster noch den Identitätsdienst noch ihre Nachbarn frei erreichen kann, weil diese Verbindungen von vornherein nie erlaubt waren. Die Seitwärtsbewegung, die aus einem Brückenkopf eine Katastrophe macht, hat schlicht keinen Ort, an den sie gehen könnte.

Die Bausteine in einer Private Cloud

Diese Prinzipien in eine laufende Private Cloud zu übersetzen, beruht auf einer Handvoll zusammenwirkender Mechanismen.

Identität ist das Fundament. Jeder Nutzer und, ebenso wichtig, jeder Workload braucht eine starke, überprüfbare Identität. Dienst-zu-Dienst-Kommunikation sollte sich über Zugangsdaten oder Zertifikate authentifizieren, nicht über implizites Vertrauen auf Basis einer IP-Adresse. In OpenStack stellt Keystone das Identitätsrückgrat für Nutzer und Dienste bereit, und rollenbasierte Zugriffskontrolle regelt, wer was tun darf.

Mikrosegmentierung ist die Art, wie das geringste Privileg auf der Netzwerkebene Wirklichkeit wird. Statt breiter Netzzonen definieren Sie feingranulare Richtlinien darüber, welche Workloads kommunizieren dürfen. In OpenStack wird dies natürlich über Sicherheitsgruppen ausgedrückt — zustandsbehaftete Firewall-Regeln pro Instanz —, gestützt auf Neutron und OVN, die die Regeln direkt an jedem Hypervisor durchsetzen statt an einem fernen Flaschenhals. Default-Deny ist das Ziel: Nichts ist erlaubt, sofern es nicht ausdrücklich gestattet wurde.

Verschlüsselung im Transit stellt sicher, dass selbst der Verkehr innerhalb der Fabric geschützt ist, sodass ein passiver Angreifer, der einen Beobachtungspunkt im Netz gewinnt, wenig erfährt. Und durchgängiges Logging und Monitoring machen das Prinzip des angenommenen Eindringens handhabbar — man kann nicht auf Seitwärtsbewegung reagieren, die man nicht sieht.

Ein praktischer Weg zu Zero Trust

Zero Trust ist ein in Etappen erreichtes Ziel, kein über Nacht umgelegter Schalter, und der Versuch, alles auf einmal zu tun, ist die Art, wie solche Programme ins Stocken geraten.

Eine sinnvolle Reihenfolge beginnt mit Sichtbarkeit: Kartieren Sie, welche Workloads tatsächlich mit welchen sprechen, denn man kann keine Least-Privilege-Richtlinie für Verkehr schreiben, den man nicht versteht. Als Nächstes bringen Sie die Identität in Ordnung — starke Authentifizierung für Nutzer wie Dienste. Dann führen Sie Default-Deny-Mikrosegmentierung schrittweise ein, beginnend bei Ihren sensibelsten Werten (der Datenbankschicht, dem Geheimnisspeicher, dem Identitätsdienst) und weiten sich nach außen aus. Ergänzen Sie Verschlüsselung und umfassendes Logging. Mit jedem Schritt wird das Innere schwerer zu durchqueren, und entscheidend liefert jeder Schritt für sich Wert, statt dass das gesamte Gebäude fertig sein müsste.

Die häufigen Fallstricke vermeiden

Zwei Fehlermuster kehren wieder. Das erste ist, Zero Trust als Produkt zu behandeln, das man kauft, statt als Architektur, die man baut — keine einzelne Appliance liefert es. Das zweite ist übereifrige Segmentierung, die legitimen Verkehr unterbricht und so viel Reibung erzeugt, dass Teams Ausnahmen herauszuschneiden beginnen, bis die Richtlinie bedeutungslos ist. Das Heilmittel für beides ist, die Arbeit auf echten Verkehrsdaten zu gründen und die Richtlinie schrittweise im Modus erst beobachten, dann durchsetzen auszurollen, sodass man weiß, wie normal aussieht, bevor man zu blockieren beginnt.

Wo die Plattform den Unterschied macht

Zero Trust ist weit leichter zu erreichen, wenn die zugrunde liegende Plattform für feingranulare, identitätsbewusste Kontrolle gebaut ist, statt auf ein flaches Netz nachträglich aufgesetzt zu werden. Eine Private Cloud auf Basis von OpenStack liefert die Primitive bereits: Keystone für die Identität, Sicherheitsgruppen und OVN für die am Hypervisor durchgesetzte Mikrosegmentierung und eine softwaredefinierte Fabric, in der die Richtlinie dem Workload folgt, statt an physische Ports geheftet zu sein.

Auf diesem Fundament baut clouditiv. Unsere souveräne Private Cloud betreibt OpenStack 2025.2 mit Neutron- und OVN-Netzwerk, Default-Deny-Sicherheitsgruppen, verschlüsseltem Ost-West-Verkehr und Beobachtbarkeit über die gesamte Fabric mit Prometheus und Grafana, alles auf Infrastruktur, die Daten in Deutschland hält und sich an ISO 27001 und BSI C5 ausrichtet. Zero Trust verlangt weiterhin bewusstes Design — es ist nicht automatisch —, doch von einer Plattform mit diesen eingebauten Fähigkeiten auszugehen, macht daraus statt eines heldenhaften Projekts eine Konfigurationsdisziplin.

Nichts vertrauen, alles prüfen

Der bleibende Wert von Zero Trust liegt darin, dass es die Sicherheit daran ausrichtet, wie Eindrüche tatsächlich ablaufen. Angreifer setzen auf das weiche Innere vertrauenswürdiger Netze; Zero Trust beseitigt diese Weichheit, indem es für jede Verbindung Identität und Berechtigung verlangt, das Privileg auf das Minimum schrumpft und davon ausgeht, dass ein Eindringen bereits geschehen ist. In einer Private Cloud bedeutet das, den Ost-West-Verkehr mit Mikrosegmentierung so zu kontrollieren, dass ein einzelner kompromittierter Workload genau das bleibt — ein einzelner. Es ist kein Produkt und keine Ziellinie, sondern eine Disziplin, und in einer Ära unerbittlicher Seitwärtsbewegungsangriffe ist es zur Grundlinie dafür geworden, Private-Cloud-Sicherheit ernst zu nehmen.