OpenZiti als Zero-Trust-Ersatz für VPNs? Architektur-Trade-offs im Vergleich

Das eigentliche Problem mit VPNs ist Erreichbarkeit

Ein klassisches VPN löst ein Transportproblem: Es baut einen verschlüsselten Tunnel zwischen zwei Netzen oder zwischen Client und Netz. Was es nicht löst, ist das Zugriffsproblem. Nach erfolgreicher Authentifizierung befindet sich der Client logisch im Zielnetz und kann dort alles adressieren, was Firewall-Regeln und Routing zulassen. In der Praxis sind diese Regeln über Jahre gewachsen und selten so eng, wie die Dokumentation behauptet.

Hinzu kommt der Perimeter selbst. Ein VPN-Gateway muss auf UDP 500/4500 oder TCP 443 lauschen, damit Clients es erreichen. Jeder lauschende Port ist scannbar, jede Schwachstelle in der VPN-Software ist damit direkt aus dem Internet angreifbar. Die Häufung kritischer Lücken in VPN-Appliances der letzten Jahre war kein Zufall, sondern eine direkte Folge dieser Architektur: Was erreichbar ist, wird irgendwann ausgenutzt.

Zero Trust nach NIST SP 800-207 setzt genau hier an. Vertrauen wird nicht mehr aus der Netzposition abgeleitet, sondern pro Zugriff aus Identität, Kontext und Richtlinie. Ein Overlay wie OpenZiti setzt dieses Prinzip technisch um, allerdings nicht auf eine einzige Weise.

Grundbausteine: Controller, Fabric, Identität, Service

Bevor die Modelle verglichen werden, lohnt ein kurzer Blick auf die Bestandteile. Ein OpenZiti-Netz besteht aus einem Controller, der Identitäten, Richtlinien und den Netzzustand verwaltet, sowie aus Edge Routern, die gemeinsam die sogenannte Fabric bilden, ein vermaschtes Overlay mit eigener Pfadwahl und Failover. Jeder Teilnehmer, ob Nutzer, Gerät oder Workload, besitzt eine kryptografische Identität in Form eines X.509-Zertifikats, das beim Enrollment ausgestellt wird.

Anwendungen werden nicht als IP-Adressen und Ports, sondern als Services modelliert. Eine Service Policy legt fest, welche Identitäten einen Service anbieten (bind) und welche ihn ansprechen (dial) dürfen. Wer keine Berechtigung hat, bekommt den Service beim Abruf der Serviceliste gar nicht erst angezeigt. Posture Checks können zusätzlich u.A. Gerätezustand, Betriebssystem, laufende Prozesse oder MFA einfordern, bevor eine Session zustande kommt.

Der entscheidende Punkt für die Architektur: Sowohl der Client als auch die Seite, die den Service hostet, bauen ausschließlich ausgehende Verbindungen zur Fabric auf. Niemand lauscht auf eingehenden Verkehr, weder am Perimeter noch am Zielsystem.

Dark Services: keine offenen Ports, nur Outbound

Aus dieser Eigenschaft ergibt sich das Konzept der Dark Services. Ein Dienst, der nur über OpenZiti erreichbar ist, hat auf Netzebene keinen lauschenden Port mehr. Er ist für Portscans unsichtbar, für Massenscanner aus dem Internet nicht existent und auch aus dem lokalen Netz nur noch für den Prozess erreichbar, der die Ziti-Identität hält. Services auf einem Server könenn auf localhost / 127.0.0.1 ihren Dinest anbieten und nich an der über das Netzwerk erreichbaren IP-Adresse.

Diese Services wiederum können unter einer beliebeigen IP oder einem belibiegen (auch weltfremden) FQDN vom Client aufgerufen werden. Für die Firewall-Konfiguration bedeutet das eine Umkehrung der gewohnten Logik. Statt eingehender Regeln für VPN-Gateways, Jump Hosts und DMZ-Systeme genügt eine einzige ausgehende Regel Richtung Edge Router. In OT-Umgebungen ist das ein erheblicher Vorteil: Ein Fernwartungszugang zu einer Maschine erfordert keine Inbound-Öffnung mehr in der Zellenfirewall, sondern lediglich einen Outbound-Kanal aus der Zelle heraus. Damit verschwindet die Angriffsfläche, um die sich viele Diskussionen zu IEC 62443 Conduits eigentlich drehen.

Die Kehrseite gehört ebenfalls auf den Tisch: Der Edge Router, an dem sich Clients und Hosts anmelden, muss selbst erreichbar sein. Er ist der einzige lauschende Punkt der Architektur. Sein Angriffsprofil ist allerdings deutlich schmaler als das eines VPN-Gateways, weil er ausschließlich mTLS-Verbindungen mit gültigen, vom eigenen Controller ausgestellten Client-Zertifikaten akzeptiert. Ohne Zertifikat kommt kein Handshake zustande, und ohne Handshake gibt es keine Protokollfläche, an der ein Angreifer ansetzen könnte.

Das Internet kann über einen "zitified" Internet-Proxy erreichbar gemacht werden und eine Default-Route wird nicht mehr benötigt. Erreichbarkeit auf untererer Netzwerkebene bzw. auf dem Underlay? Fehlanzeige.

Zwei Verschlüsselungsebenen, die man auseinanderhalten muss

Wer die drei Modelle bewerten will, muss zwischen zwei Ebenen unterscheiden, die in Marketingtexten gern vermischt werden.

Link-Verschlüsselung mit mTLS

Jede Verbindung zwischen zwei OpenZiti-Komponenten, also Client zu Router, Router zu Router und Router zu Controller, ist mit mutual TLS gesichert. Beide Seiten weisen sich mit Zertifikaten aus, es gibt keine anonyme Seite. Das schützt den Transport zwischen zwei Hops. Es schützt theoretisch aber nicht davor, dass ein kompromittierter Router den Verkehr im eigenen Speicher sieht, denn dort wird entschlüsselt und neu verschlüsselt.

Ende-zu-Ende-Verschlüsselung über die Fabric

Zusätzlich verschlüsseln OpenZiti-SDKs daher auch die Nutzdaten bereits an der Quelle und entschlüsseln sie erst am Ziel. Die Fabric transportiert nur Chiffrat. Technisch kommt libsodium mit XChaCha20-Poly1305 zum Einsatz, ein AEAD-Verfahren mit 256 Bit Schlüsselstärke. Der Schlüsselaustausch läuft über ephemere Schlüsselpaare, die beim Bind und beim Dial erzeugt werden; der Controller vermittelt lediglich die öffentlichen Schlüssel. Nach jeder Nachricht werden Sende- und Empfangsschlüssel rotiert, was Forward Secrecy auf Nachrichtenebene ergibt. Der Overhead ist mit 17 Byte pro Nachricht und einer zusätzlichen 24-Byte-Nachricht beim Sitzungsaufbau gering.

Der entscheidende Satz lautet: Ende-zu-Ende-Verschlüsselung endet dort, wo das SDK endet bzw. terminiert. Und genau das unterscheidet die drei Modelle.

Die drei Modelle im Vergleich

OpenZiti ordnet jede Deployment-Architektur einem von drei Edge-Access-Modellen zu. Das Kriterium ist jeweils, wo Zero Trust durchgesetzt wird und wo die Verschlüsselung terminiert.

ZTAA: Zero Trust Application Access (SDK-Integration)

Das SDK wird direkt in die Anwendung eingebettet, sowohl auf Client- als auch auf Serverseite. Die Anwendung selbst hält die Identität, öffnet die Verbindung zur Fabric und terminiert die Ende-zu-Ende-Verschlüsselung im eigenen Prozess. Es gibt keinen lauschenden Socket auf dem Host, kein Betriebssystem-Routing, keine lokale Netzkonfiguration, die ein anderer Prozess mitnutzen könnte. Selbst Schadsoftware auf demselben Rechner sieht den Dienst nicht, weil er außerhalb des Ziti-Prozesses schlicht nicht existiert.

Der Preis ist Integrationsaufwand. Der Quellcode muss angepasst werden. Aber SDKs und Anwendungsbeispiele existieren genug unter anderem für Go, C, Java, Python, .NET, Node.js und Swift auf der Webseite von Openziti. Man erkennt sofort: es ist sehr einfach und kein Hexenwerk. Für Bestandssoftware, Herstellerprodukte oder SPS-Steuerungen ist das oft keine Option. ZTAA ist die richtige Wahl für Eigenentwicklungen, interne APIs, Agenten, Microservices und überall dort, wo die stärkste Absicherung gefordert ist.

ZTHA: Zero Trust Host Access (Tunneler)

Kann die Anwendung nicht geändert werden, übernimmt ein Tunneler auf dem Host die Rolle des SDK. Er läuft als Dienst, hält die Identität und stellt den Ziti-Service über ein lokales TUN-Interface, DNS-Interception oder einen lokalen Proxy bereit. Auf der Serverseite hostet der Tunneler den Service und leitet den Verkehr an den Dienst auf localhost oder ein benachbartes System weiter. Es gibt Tunneler für Windows, macOS, Linux, iOS, Android und als Container.

Die Ende-zu-Ende-Verschlüsselung reicht jetzt von Tunneler zu Tunneler, also von Host zu Host. Zwischen Tunneler und Anwendung liegt eine unverschlüsselte Strecke, die aber den Host nicht verlässt. Zero Trust wird auf Host-Ebene durchgesetzt: Identität und Posture Checks gelten pro Gerät, nicht pro Prozess. Damit können andere Prozesse auf demselben Host den lokal bereitgestellten Service potenziell mitnutzen. Für die meisten Unternehmensanwendungen ist das ein akzeptabler Kompromiss und in der Praxis der Standardweg, um Bestandssoftware ohne Codeänderung anzubinden.

Zudem kann ein Tunneler auch als Forwarder genutzt werden. Dort terminiert ein liste- oder bind-dienst, von/auf dem dann Daten ins Underlay weitergeleitet werden können. Aus alten NAC-Zeiten kennen einige noch die berühmten Labeldrucker und Quittungsdrucker, die nicht mit Zertifikaten arbeiten können. Auch ein normales Kopiergerät oder andere "dumme" Geräte können sehr sicher mit eingebunden werden. Der Tunneler erfüllt dann die gleichen Anforderungen, wie der im nächsten Kapitel erwähnte Edge-Router.

ZTNA: Zero Trust Network Access (Edge Router in der Zielzone)

Lässt sich auf dem Zielsystem nichts installieren, weil es sich um eine SPS, ein HMI-Panel, eine Appliance oder ein veraltetes Betriebssystem handelt, wird ein Edge Router mit aktivierter Tunneler-Funktion in der vertrauten Netzzone platziert. Der Router terminiert die OpenZiti-Verbindung und spricht das Zielsystem über das normale LAN an. Die Ende-zu-Ende-Verschlüsselung endet am Router, das letzte Stück läuft im Klartext des jeweiligen Protokolls, sofern die Anwendung nicht selbst verschlüsselt.

Zero Trust gilt hier nur bis zur Netzgrenze. Die Sicherheit der letzten Meile hängt vollständig von der Segmentierung dahinter ab: Ist die Zone eng geschnitten, ist das Risiko überschaubar; ist es ein flaches Produktionsnetz, gewinnt man gegenüber einem VPN vor allem am Perimeter, nicht innerhalb der Zone. Dieses Modell entspricht funktional am ehesten einem Site-to-Site- oder Client-to-Site-VPN und ist für Brownfield-OT-Umgebungen häufig der einzige realistische Einstieg.

Entscheidungskriterien aus der Architekturperspektive

Die drei Modelle schließen sich nicht aus. Im Gegenteil: Sie können fröhlich gemixt kombiniert werden. Für den Admin in der Weboberfläche des Controllers sieht das nicht anders oder schwierig aus. Ein Client mit Tunneler (ZTHA) kann problemlos einen Service ansprechen, der auf der Gegenseite per Edge Router (ZTNA) oder per SDK (ZTAA) gehostet wird. Die Modelle werden pro Service und pro Seite gewählt, nicht pro Netz. Für die Auswahl haben sich in Projekten folgende Fragen bewährt:

• Kann ich den Code ändern? Dann SDK, mindestens auf der Serverseite. Eigenentwicklungen ohne SDK-Anbindung verschenken die stärkste Schutzstufe. NetFoundry OpenZiti wurde für Zero trust entwickelt und hat mit ZTAA den Sicherheits-Vorteil, den die meißten Anbieter nicht erreichen können.
• Kann ich auf dem Host etwas installieren? Dann Tunneler. Das gilt für Arbeitsplätze, Server, Jump Hosts und Edge-Rechner in der Produktion gleichermaßen. Ein Docker-Container auf einem Mikrotik-Router ist z.B. ebenso möglich, wie ein Windows-Installationsprogramm.
• Ist das Ziel eine Blackbox? Dann Edge Router in einer möglichst kleinen Zone. Die Zone sollte so geschnitten sein, dass der Router nur die Systeme erreicht, die tatsächlich als Service veröffentlicht werden.
• Wo darf Klartext liegen? Bei ZTAA nirgends außerhalb des Prozesses, bei ZTHA auf dem Host, bei ZTNA in der Zone. Diese Antwort gehört in die Risikobewertung, bevor über Produkte gesprochen wird. Wir allen wissen, dass viele andere global Player nur mit ZTNA werben können, da sie ursprünglich aus ganz anderen Bereichen des Netzwerks oder der IT-Sicherheit kommen.
• Welche Posture Checks sind möglich? Gerätebezogene Prüfungen setzen einen Tunneler oder ein SDK auf dem Endgerät voraus. Ein reines ZTNA-Setup auf beiden Seiten kann den Zustand der Endgeräte nicht bewerten.

Trade-offs, die in Ratgebern fehlen

Ein Overlay ersetzt nicht die Netzsegmentierung, es macht sie sichtbar. Wer ZTNA mit einem Edge Router in einem flachen Netz betreibt, hat die Zugriffskontrolle am Perimeter verbessert, aber das Zonenkonzept nach IEC 62443 nicht erledigt. Der Router sollte deshalb bewusst als Conduit modelliert und mit Host-Firewall und ACLs auf die freigegebenen Ziele beschränkt werden. Wenn nur Verbindungen für das Overlay auf dem Underlay erlaubt sein solen, dann kann man zusätzlich nur eine Hand voll Firewallregeln und ganz wenige Routen erlauben und auf Switch-Ebene mit private VLANs arbeiten, um das Underlay maximal zu schützen.

Die PKI wird zur zentralen Abhängigkeit. Jede Identität ist ein Zertifikat, jede Verbindung ein mTLS-Handshake. Enrollment, Rotation, Widerruf und die Anbindung an bestehende Identity Provider über OIDC oder externe JWT-Signer sind Betriebsprozesse, die vor dem Rollout definiert sein müssen. Wer das unterschätzt, hat nach zwölf Monaten ein Zertifikatsproblem statt eines VPN-Problems. Zu beachten ist auch, dass ein Ausrollen einer eigenen PKI auf den Endgräten erheblich aufwendiger ist, als die von der Fabric generierte PKI, deren Parameter durch Variablen haarklein vorab gesetzt werden können.

Latenz und Durchsatz verhalten sich anders als bei einem direkten IPsec-Tunnel. Der Verkehr läuft über die Fabric, im Regelfall über mindestens einen Edge Router. Für interaktive Protokolle, Fernwartung und die meisten Geschäftsanwendungen ist das unkritisch, für Echtzeitprotokolle auf Feldebene ist OpenZiti ohnehin nicht der richtige Ort, dort bleibt es bei lokaler Segmentierung. Mehr Edge-Router können die Multi-Path-Kapazität erhöhen oder die Wege der Paket vekürzen, je nach Einsatztyp- und Ort.

Und schließlich die Controller-Verfügbarkeit: Der Controller ist für neue Sessions erforderlich, bestehende Verbindungen laufen bei Ausfall weiter. In der Active-LTS-Linie 2.0.x ist Controller-Clustering enthalten; für produktive Umgebungen mit Verfügbarkeitsanforderungen sollte es von Anfang an eingeplant werden.

Fazit

Ein VPN beantwortet die Frage, wie zwei Netze verbunden werden. OpenZiti beantwortet die Frage, welche Identität welchen Dienst ansprechen darf, und macht alles andere unsichtbar. Der Ersatz gelingt aber nur, wenn das Modell bewusst gewählt wird: ZTAA für Eigenentwicklungen, ZTHA als Standard für Bestandssysteme, ZTNA als Einstieg für Blackboxen in klar geschnittenen Zonen. Wer stattdessen einen Edge Router vor ein flaches Netz stellt und das Ergebnis Zero Trust nennt, hat lediglich das VPN-Gateway gegen ein Gateway ohne offene Ports getauscht. Das ist ein Fortschritt, aber noch keine Zero-Trust-Architektur. Zero Trust ist nicht nur Technik, NetFoundry OpenZiti ist (meiner Meinung nach) die derzeit beste verfügbare Zero-Trust-Technik und ergänzt das unbedingt vorhandene Zero-Trust-Prinzip mit der Architektur, den organisatorischen Entscheidungen uvm.