Zehn Architekturfragen im Software Defined Networking und wie OpenZiti sie löst.

SDN als Grundlage: Identität statt IP

IP-Adressen und Ports sind ein schlechtes Kontrollprimitiv, sobald Umgebungen wachsen. NAT, überlappende Bereiche nach Fusionen, VLAN-Wildwuchs und tausende Firewall-Regeln machen adressbasierte Zugriffskontrolle fragil und schwer prüfbar. Software Defined Networking trennt die Steuerungsebene von der Datenweiterleitung und Zero Trust nach NIST SP 800-207 nutzt genau diese Trennung, um Vertrauen nicht mehr aus der Netzposition, sondern pro Zugriff aus Identität, Kontext und Richtlinie abzuleiten.

OpenZiti bildet das mit vier Bausteinen ab. Mit einem Controller, der Identitäten, Richtlinien und den Netzzustand verwaltet, mit einer Fabric aus Edge Routern, die den verschlüsselten Verkehr vermascht weiterleitet, mit kryptografischen Identitäten in Form von X.509-Zertifikaten für jeden Nutzer, jedes Gerät und jeden Workload sowie mit Services samt Policies, die festlegen, welche Identität einen Dienst anbieten (bind) oder ansprechen (dial) darf. Wer nicht berechtigt ist, sieht den Dienst nicht einmal in der Serviceliste. Sowohl Client als auch Host bauen ausschließlich ausgehende Verbindungen zur Fabri auf. Niemand lauscht auf eingehenden Verkehr. Hier kann schon auf Netzwerk- Firewall- und Bertriebssystemebene eingehend alles verboten oder sogar verhindert werden. Der Pfad wird erst nach gegenseitiger Authentifizierung per mTLS im Overlay geöffnet und ist Ende-zu-Ende verschlüsselt.

Zehn wiederkehrende Architekturfragen

Die folgenden Punkte sind bewusst als Fragen formuliert, wie sie in Architektur-Workshops fallen. Zu jeder steht, wie OpenZiti antwortet und welche Deployment-Variante (ZTAA, ZTHA, ZTNA) jeweils greift.

1. Wie dämme ich laterale Bewegung ein? In flachen Netzen erreicht ein kompromittierter Host alles, was routbar ist. Das Overlay segmentiert nicht über Topologie, sondern über identitätsbasierte Service Policies: Ohne explizite Berechtigung lässt sich ein Dienst nicht einmal adressieren. Mikrosegmentierung wird damit zur Eigenschaft der Architektur statt zum Nachgedanken aus VLANs und Firewall-Regeln.
2. Wie komme ich ohne offene Ports aus? Jeder eingehende Listener, vom VPN-Konzentrator bis zum exponierten Management-Interface, ist Angrioffsfläche. Dark Services wählen ausschließlich ausgehend. Am Zielsystem bleibt somit auch kein lauschender Port im Underlay. Es kehrt sich sogar die Firewall-Logik um: Statt eingehender Regeln für Gateways und DMZ genügen eine ausgehende Regel Richtung Edge Router und eine in Richtung SDN Controller. Die einzig erreichbaren Punkte bleiben dieser Router und der Controller, welche ausschließlich mTLS-Verbindungen mit gültigem Client-Zertifikat annehmen. Jeder Kommunikationsteilnehmer muss sich darüber authentifizieren, um überhaupt ans Overlay andocken zu können.
3. Wie verbinde ich überlappende IP-Bereiche? Nach Fusionen und in verteilten OT-Landschaften kollidieren Adressräume regelmäßig. Weil das Overlay Dienste über Identität und Namen adressiert und Zugriffe per DNS-Interception abfängt, spielt die darunterliegende IP keine Rolle mehr. Ein Dienst ist unter beliebigem FQDN oder beliebiger IP (gerne auch 127.0.0.1) erreichbar. Aufwendige NAT- oder Re-IP-Projekte, die in gewachsenen Produktionsnetzen oft jahrelang blockieren, entfallen somit.
4. Wie regle ich Remote- und Fremdzugriff auf OT? Breite VPN-Zugänge und geteilte Jump Hosts sind schwer zu begrenzen und kaum nachvollziehbar. OpenZiti vergibt Zugriff pro Identität, pro Dienst und bei Bedarf zeitlich befristet. Jede Verbindung wird mit Identität und Richtlinie protokolliert. Ein Fernwartungszugang zu einer Maschine braucht keine Inbound-Öffnung in der Zellenfirewall mehr, sondern nur noch einen Outbound-Kanal, je nach Gerät als Tunneler (ZTHA) oder über einen Edge Router in der Zone (ZTNA).
5. Wie erreiche ich durchgängige Verschlüsselung? Zu unterscheiden sind zwei Ebenen: mTLS sichert jede Verbindung zwischen den OpenZiti-Komponenten, und die SDKs verschlüsseln die Nutzdaten zusätzlich Ende-zu-Ende über die Fabric (AEAD mit XChaCha20-Poly1305, ephemere Schlüssel, Rotation je Nachricht). Der entscheidende Satz für die Architektur: Die Ende-zu-Ende-Verschlüsselung endet dort, wo das SDK terminiert. Genau deshalb ist Zero Trust Application Access (ZTAA) mit eingebettetem SDK die stärkste Stufe, ZTHA (Host) und ZTNA (Netz) verschieben den Endpunkt bewusst nach außen.
6. Wie werde ich Compliance-Anforderungen gerecht? NIST SP 800-207 verlangt Authentifizierung und Autorisierung je Sitzung - genau das Muster des Overlays. Für abgegrenzte, protokollierte Zugriffszonen (etwa PCI-DSS / Payment Card Industry Data Security Standard) lässt sich der Datenpfad sauber nachweisen. NetFoundry gibt für sein kommerzielles Angebot FIPS-konforme Kryptografie sowie Mappings auf NIST 800-53 und 800-207 an. Für die konkrete Edition und Version ist das beim Hersteller zu prüfen.
7. Wie verbinde ich Cloud, Hybrid und Standorte ohne VPN-Mesh? Das Overlay spannt sich als softwaredefinierte Fabric über Clouds, Rechenzentren und Standorte, ohne dass für jede Beziehung ein Site-to-Site-Tunnel entsteht. Das beendet die kombinatorische Explosion aus Tunneln und Regeln und verlagert die Pfadwahl und das Failover in die Fabric.
8. Wie gebe ich Maschinen, Workloads und KI-Agenten eine Identität? Nicht nur Menschen brauchen Identitäten, sondern jeder Dienst, jeder Container, jeder Agent. Somit wird die Sicherheit der Daten, um die es letztendlich geht erheblich erhöht. Das Overlay vergibt kurzlebige, zertifikatsbasierte Identitäten bis auf Pod-Ebene. Für KI-Workloads stellt das Projekt nach dem Stand von September 2026 zusätzliche Bausteine bereit, etwa Gateways für LLM- und MCP-Verkehr sowie einen Ansatz für Agent-zu-Agent-Kommunikation. Diese sind ebenfalls quelloffen unter Apache 2.0.
9. Wie halte ich die Steuerungsebene verfügbar? Der Controller ist für neue Sessions nötig; bestehende Verbindungen laufen bei einem Ausfall weiter. Mit OpenZiti v2.0 (LTS, seit Mai 2026) ist Controller-Clustering für den allgemeinen Einsatz freigegeben, OIDC ist seither der Standard-Authentifizierungsweg, und die Management-API lässt sich vollständig über das Overlay betreiben, sodass sie selbst keinen offenen Port mehr benötigt (Stand 09/2026). Für produktive Umgebungen mit Verfügbarkeitsanforderungen gehört Clustering von Anfang an in die Planung.
10. Wie sichere ich Nachvollziehbarkeit und Unabhängigkeit? Der gesamte OpenZiti-Kern steht unter Apache 2.0 und ist einsehbar und auditierbar. Offene Protokolle verringern das Lock-in-Risiko. Jede Verbindung ist an eine Identität und eine Richtlinie gebunden und damit protokollierbar, Posture Checks können zusätzlich Gerätezustand, Betriebssystem oder MFA einfordern, bevor eine Session zustande kommt.
11. Wie schaffe ich einen realistischen Einstieg im Brownfield? Nicht jedes System lässt sich anpassen. Die drei Modelle sind frei kombinierbar pro Service und pro Seite: ZTAA (SDK) für Eigenentwicklungen, ZTHA (Tunneler) als Standard für Bestandssoftware auf Windows, Linux, macOS, Android oder im Container. ZTNA (Edge Router in der Zielzone) für Blackboxen wie SPS, HMI-Panels oder Appliances. So beginnt ein Rollout dort, wo er ohne Codeänderung sofort Wirkung zeigt. Zu beachten ist hier, dass das Overley-eigene DNS bei der Einführung ebenso nützlich ist.

Wo auch ein Overlay endet

Wichtig ist auch, die Grenzen zu benennen. Ein Identity-Overlay ist kein SASE-Ersatz: Proxy, Web-Filter, CASB oder DLP bringt es nicht mit, diese können aber ebenso leicht eingebunden werden. Anstatt einer Default-Route einen Procy anzusteuern ist eh die klügere Wahl. Jeder Teilnehmer muss entweder ein SDK einbetten oder einen Tunneler beziehungsweise Edge Router erreichen. Reine Feldgeräte ohne Agentenfähigkeit, die (noch aus den NAC-Projekten bekannten) Label- oder Quittungsdrucker sowie andere Geräte, die nicht "zitifiziert" werden können, werden über einen Router in einer möglichst eng geschnittenen Zone angebunden (gewöhnliches ZTNA). Dann gilt Zero Trust nur bis zur Netzgrenze. Die Sicherheit der letzten Meile hängt an der Segmentierung dahinter.

Zwei Betriebsthemen entscheiden über den Erfolg. Die PKI wird zur zentralen Abhängigkeit: Enrollment, Rotation, Widerruf und die Anbindung an bestehende Identity Provider über OIDC oder externe JWT-Signer müssen vor dem Rollout definiert sein. Ebenso sollte man die Versionsdisziplin einhalten: v2.x-Router arbeiten nur mit v2.x-Controllern, Controller werden vor Routern aktualisiert, und Version 1.6 wird nach Herstellerangaben seit Mai 2026 nur noch als Maintenance-LTS gepflegt (Stand 09/2026); der genaue Patch-Stand der 2.0-Reihe ist beim Projekt zu prüfen. Für deterministische / vorhersagbare Echtzeitprotokolle auf Feldebene bleibt schließlich die lokale Segmentierung zuständig. Das Overlay sichert hier den Zonenübergang, nicht die Fertigungszelle selbst.

Fazit

SDN liefert die Entkopplung, OpenZiti liefert die identitätsbasierte Durchsetzung. Die bewusste Wahl zwischen ZTAA, ZTHA und ZTNA entscheidet, wie stark der Schutz je Dienst ausfällt. Wer nur 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. Viele ZTNA-Anbieter machen genau dies und nicht mehr. Zero Trust ist eben nicht nur Technik, sondern zuerst eine Architektur- und Organisationsentscheidung. Als NetFoundry-Partner für Deutschland begleiten wir diese Entscheidung von der Architektur bis zum Betrieb. Enterprise-Installationen mit Garantie- und Haftungsanforderungen sowie durchgehendne Support (24/7) werden dabei auch durch den Hersteller NetFoundry selbst erbracht und von uns auf Entscheidungs- sowie Architektenebene für Sie begleitet.