OpenZiti

OpenZiti ist eine Open-Source-Zero-Trust-Netzwerkplattform, die Netzwerkdienste für unbefugte Benutzer unsichtbar macht. Jede Verbindung – ob von einem Benutzer, einem Dienst, einem Gerät oder einer Workload – wird durch kryptografische Identität authentifiziert, durch Richtlinien autorisiert und Ende‑zu‑Ende verschlüsselt.

OpenZiti funktioniert sowohl mit vorhandenen Anwendungen (mithilfe von leichten Tunnelern ohne Codeänderungen) als auch mit neuen Anwendungen (mithilfe von eingebetteten SDKs für das stärkste Zero‑Trust‑Modell). Dadurch ist es sowohl für Brownfield‑ als auch für Greenfield‑Entwicklungen praktisch einsetzbar.

Erstellt und gesponsert von NetFoundry. Lizenziert unter Apache 2.0.

Inhaltsverzeichnis

• Anwendungsfälle
• Wichtige Fähigkeiten
• Drei Bereitstellungsmodelle
• Erste Schritte
• Architektur
• Zero Trust, Dark Services und Ende‑zu‑Ende-Verschlüsselung
• SDKs
• Community & Support
• Mitwirken
• Anwender
• Managed Service

Anwendungsfälle

OpenZiti ermöglicht es Ihnen, Zero‑Trust überall für jeden Anwendungsfall zu erweitern – einschließlich Nicht‑Mensch‑Workloads und Workflows über mehrere Netzwerke und Dritte hinweg. Im Folgenden sind einige häufige Anwendungsfälle aufgeführt.

VPNs ersetzen

Bereitstellung eines sicheren Zugriffs auf interne Dienste ohne VPN‑Clients, Split‑Tunneling‑Probleme oder Engpässe durch Konzentratoren. Jeder Dienst wird einzeln autorisiert. Es gibt kein Problem „Einmal drin, alles erreichbar“.

Dark APIs und Dienste

APIs und Dienste für das Internet unsichtbar machen. Keine lauschenden Ports = keine Angriffsfläche. Autorisierte Clients verbinden sich über OpenZiti; alle anderen sehen nichts.

IoT und Nicht‑Mensch‑Identität

Jedes Gerät, jeder Sensor und jede Maschine erhält eine eindeutige kryptografische Identität. Das Identitätsmodell von OpenZiti funktioniert für Nicht‑Mensch‑Workloads genauso gut wie für menschliche Benutzer und bietet eine starke Authentifizierung für die Maschine‑zu‑Maschine‑Verbindungen, die den Großteil des modernen Netzwerkverkehrs ausmachen.

Zero‑Trust‑Workloads

Sichere Kommunikation zwischen Workloads über Clouds und Umgebungen hinweg. Dienste authentifizieren sich gegenseitig mit kryptografischer Identität, nicht mit Netzwerkstandort. Keine gemeinsamen Geheimnisse, keine IP‑Whitelists, keine grundlegende Autorität.

Agentische KI

Sichere Kommunikation zwischen Agent und Dienst bzw. zwischen Agenten mit kryptografischer Identität für jeden KI‑Teilnehmer. MCP‑Server, Tool‑Endpunkte und private LLMs bleiben unsichtbar (dark), ohne lauschende Ports oder öffentliche URLs. Agenten authentifizieren sich mit starken, eindeutigen Identitäten und erreichen nur die Ressourcen, die die Richtlinie erlaubt – so erhalten autonome Workflows den benötigten Zugriff, ohne grundlegende Autorität über alles andere.

Multi‑Cloud- und Hybridkonnektivität

Ein Overlay‑Netzwerk über AWS, Azure, GCP, On‑Prem‑Rechenzentren und Edge‑Standorte. Keine cloud‑spezifischen Netzwerktools, keine VPN‑Tunnel zwischen Umgebungen, keine komplexen Peering‑Vereinbarungen.

Zugriff auf selbst gehostete Dienste

Zugriff auf Home‑Lab‑ oder selbst gehostete Dienste wie Nextcloud, Home Assistant, Medienserver und Entwicklungsumgebungen von überall. Keine offenen Router‑Ports, kein dynamisches DNS, keine Abhängigkeit von Drittanbieter‑Tunnel‑Diensten. Sie kontrollieren den gesamten Pfad.

Kubernetes und Dienste über Cluster hinweg

Verbinden von Diensten über Kubernetes‑Cluster hinweg ohne komplexe Ingress‑Regeln, Service‑Mesh‑Sidecars oder VPN‑Tunnel zwischen Clustern. Funktioniert über Kubernetes hinaus und unterstützt die Verbindung von Kubernetes‑Diensten mit VMs, Bare‑Metal, IoT‑Geräten oder allem anderen im Overlay.

Wichtige Fähigkeiten

Drei Bereitstellungsmodelle

OpenZiti unterstützt drei Zero‑Trust‑Modelle. Sie können sie in einem einzigen Netzwerk mischen und im Laufe der Zeit zwischen ihnen migrieren.

Netzwerkzugriff

Stellen Sie einen OpenZiti‑Edge‑Router in einer vertrauenswürdigen Netzwerkzone bereit. Der Datenverkehr gelangt von authentifizierten Clients in das Overlay und tritt in das private Netzwerk aus, in dem die Dienste laufen.

• Codeänderungen: Keine
• Agent auf dem Diensthost: Kein
• Sicherheitsmodell: Identitätsbasierter Zugriff an der Netzwerkgrenze. Ähnlich wie ein Gateway, jedoch mit kryptografischer Identität und verschlüsseltem Transport.

Hostzugriff

Führen Sie einen OpenZiti‑Tunneller auf demselben Host wie Ihren Dienst aus. Der Tunneller übernimmt Identität, Authentifizierung und Verschlüsselung. Der Dienst muss nur Verbindungen von localhost akzeptieren.

• Codeänderungen: Keine
• Einrichtung: Tunneller installieren, Identität eintragen
• Sicherheitsmodell: Vertrauensgrenze auf Betriebssystemebene. Der Dienst ist für das Netzwerk unsichtbar (dark) und nur über den Tunneller erreichbar.

Anwendungszugriff (Stärkste Variante)

Betten Sie ein OpenZiti‑SDK direkt in die Client‑ und/oder Server‑Anwendungen ein. Die Anwendung selbst besitzt die kryptografische Identität und verschlüsselt den Datenverkehr prozessintern. Es existieren keine lauschenden Ports, nicht einmal auf localhost.

• Codeänderungen: Ja
• Sicherheitsmodell: Am stärksten. Ende‑zu‑Ende-Verschlüsselung prozessintern. Vollständig unsichtbar (dark). Identität auf Anwendungsebene, nicht auf Netzwerk‑ oder Hostebene.

Wo anfangen: Viele Teams beginnen mit Hostzugriff (Tunneller) für bestehende Dienste. Die Bereitstellung dauert Minuten ohne Codeänderungen. Für Neuentwicklungen oder sicherheitskritische Workloads bietet Anwendungszugriff (SDKs) die stärkste Zero‑Trust‑Haltung.

Erste Schritte

Die folgenden Schnellstartanleitungen zeigen, wie Sie ein lokales OpenZiti‑Netzwerk für Entwicklung, Tests und Lernzwecke einrichten. Für Produktionsbereitstellungen lesen Sie bitte die Produktdokumentation unter https://netfoundry.io/docs/openziti/category/deployments/.

Schnellstart mit Docker

Der schnellste Weg, ein lokales OpenZiti‑Netzwerk zum Laufen zu bringen:

wget https://get.openziti.io/dock/all-in-one/compose.yml
docker compose up

Dies startet einen Controller, einen Edge‑Router und die Ziti‑Konsole in einem einzigen Compose‑Stack. Die Konsole ist unter https://localhost:1280/zac/ erreichbar. Von dort aus können Sie Identitäten erstellen, Dienste definieren und Zugriffsrichtlinien konfigurieren.

Weitere Details, einschließlich Speicheroptionen, Umgebungsvariablen und CLI‑Nutzung, finden Sie im All-in-One-Docker-Schnellstart.

Schnellstart mit der CLI

Laden Sie die neueste ziti‑Binärdatei von GitHub Releases herunter und führen Sie dann Folgendes aus:

ziti edge quickstart

Dadurch wird ein lokales Entwicklungsnetzwerk gestartet: Controller, Router und eine Standard‑Admin‑Identität. Ideal zum Testen und Lernen.

Um die Ziti Admin Console (ZAC) zu einem laufenden Controller hinzuzufügen:

ziti ops console download --location /opt/openziti/console
ziti ops console configure /path/to/controller.yml --all --location /opt/openziti/console
# starten Sie den Controller neu, öffnen Sie dann https://<controller-address>/zac/

Oder ZAC lokal bereitstellen, ohne die Controller‑Konfiguration zu ändern:

ziti run console --version latest
# öffnet https://127.0.0.1:8443. Zeigen Sie damit von Ihrem Browser aus auf einen beliebigen Controller

Mehr erfahren

Architektur

Das Overlay‑Netzwerk von OpenZiti läuft auf vorhandener Infrastruktur: jedes IP‑Netzwerk, jede Cloud, jede Kombination. Die Kernkomponenten:

Controller

Der Controller ist die Management‑Ebene. Er übernimmt:

• Identitätsverwaltung: Ausstellung und Überprüfung kryptografischer Identitäten (x509‑Zertifikate) für jeden Teilnehmer im Netzwerk
• Richtliniendurchsetzung: Definition, welche Identitäten auf welche Dienste und über welche Edge‑Router zugreifen dürfen
• Netzwerkzustand: Verfolgung von Routern, Diensten und Topologie; Bereitstellung einer REST‑API und einer webbasierten Admin‑Konsole zur Verwaltung

Edge‑Router

Edge‑Router bilden die Datenebene – ein Mesh‑Fabric, das verschlüsselten Datenverkehr zwischen Endpunkten transportiert.

• Öffentliche Router sind aus dem Internet erreichbar und dienen als Einstiegspunkte in das Netzwerk
• Private („Dark“) Router werden innerhalb privater Netzwerke eingesetzt und stellen nur ausgehende Verbindungen her

Router erkennen sich automatisch gegenseitig, bilden Mesh‑Verbindungen und nutzen intelligentes Routing, um den besten Pfad basierend auf Latenz, Durchsatz und Kosten auszuwählen.

Endpunkte: SDKs und Tunneller

Endpunkte sind die Art und Weise, wie Anwendungen und Benutzer sich mit dem OpenZiti‑Netzwerk verbinden:

• SDKs (Go, C, Python, Node.js, Java, Swift, C#): Betten Sie Zero‑Trust direkt in Ihre Anwendung ein. Die Anwendung selbst besitzt die Identität und übernimmt die Verschlüsselung. Kein Sidecar, kein Agent, keine lauschenden Ports.

• Tunneller (Linux, Windows, macOS, iOS, Android): Leichte Anwendungen, die OpenZiti‑Konnektivität für unveränderte Software bereitstellen. Der Datenverkehr wird abgefangen und transparent über das Overlay geleitet. Keine Codeänderungen erforderlich.

Zero Trust, Dark Services und Ende‑zu‑Ende-Verschlüsselung

Zero Trust und Anwendungssegmentierung

Jeder Teilnehmer (z. B. Benutzer, Dienst, Gerät, Workload) in einem OpenZiti‑Netzwerk trägt eine eindeutige kryptografische Identität, die durch x509‑Zertifikate gestützt wird. Wenn eine Verbindung versucht wird, überprüft OpenZiti:

1. Die Identität ist gültig und registriert
2. Es existiert eine Richtlinie, die dieser Identität den Zugriff auf den angeforderten Dienst gewährt
3. Die Verbindung erfolgt über einen autorisierten Edge‑Router

Wenn eine dieser Prüfungen fehlschlägt, wird die Verbindung verweigert. Wenn der Zugriff später widerrufen wird, werden aktive Verbindungen sofort beendet. Es gibt kein implizites Vertrauen basierend auf dem Netzwerkstandort. Im selben LAN zu sein, gewährt nicht mehr Zugriff als über das Internet – es sei denn, die Richtlinie erlaubt es explizit.

Dieses Modell bietet eine Zero‑Trust‑Anwendungssegmentierung: Jeder Dienst wird unabhängig autorisiert. Der Zugriff auf einen Dienst gewährt keinen Zugriff auf einen anderen.

Dark Services

Ein „Dark Service“ hat keine offenen Ports. Er hört auf keiner Netzwerkschnittstelle auf eingehende Verbindungen. Stattdessen baut der Dienst (oder ein neben ihm laufender Tunneller) eine ausgehende Verbindung zu einem OpenZiti‑Edge‑Router auf und registriert sich. Clients erreichen ihn nur über das OpenZiti‑Fabric, nach Authentifizierung und Autorisierung.

Was das in der Praxis bedeutet:

• Portscans finden nichts: Es gibt keine lauschenden Ports zu entdecken
• Keine Angriffsfläche: Man kann nichts ausnutzen, was man nicht erreichen kann
• DDoS‑Resistenz: Es gibt keinen öffentlichen Endpunkt, den man überfluten könnte
• Unsichtbar für unbefugte Benutzer: Nur Identitäten mit passender Richtlinie wissen überhaupt, dass der Dienst existiert
• NAT‑ und Firewall‑freundlich: Alle Verbindungen sind ausgehend, daher sind CG‑NAT, Double‑NAT und restriktive Firewalls kein Problem

Edge‑Router können ebenfalls unsichtbar (dark) sein. Private Router stellen nur ausgehende Verbindungen her, sodass keine eingehenden Firewall‑Regeln in Ihrem privaten Netzwerk erforderlich sind.

Ende‑zu‑Ende-Verschlüsselung

Mit OpenZiti‑SDKs wird der Datenverkehr von der sendenden Anwendung bis zur empfangenden Anwendung verschlüsselt – unter Verwendung von libsodium für den Datenpfad und mTLS für die Identitätsauthentifizierung. Selbst wenn Router oder zwischengeschaltete Netzwerke kompromittiert werden, kann der Datenverkehr nicht entschlüsselt oder manipuliert werden.

Mit Tunnelern erstreckt sich die Verschlüsselung über den Pfad von Tunneller zu Tunneller (oder von Tunneller zu SDK) und bietet Maschine‑zu‑Maschine‑Verschlüsselung ohne Anwendungsänderungen.

SDKs

Betten Sie Zero‑Trust‑Netzwerke direkt in Ihre Anwendungen ein:

Alle SDKs sind unter der OpenZiti‑GitHub‑Organisation aufgeführt.

Sicherheit

OpenZiti ist ein sicherheitsorientiertes Projekt. Die verantwortungsvolle Offenlegung von Sicherheitslücken hilft uns, die Plattform und ihre Benutzer zu schützen.

Melden einer Sicherheitslücke: Wenn Sie ein Sicherheitsproblem entdecken, lesen Sie bitte unsere Richtlinie zur Offenlegung von Sicherheitslücken für vollständige Details. Sensible Probleme sollten an [email protected] gemeldet werden. Nicht sensible Probleme können als GitHub‑Issues im entsprechenden Repository eingereicht werden. Sie sollten innerhalb von 7 Tagen eine Antwort erhalten.

Wie wir mit Sicherheitslücken umgehen: Unser Prozess zur Reaktion auf Sicherheitsvorfälle in Produkten beschreibt, wie gemeldete Sicherheitslücken kategorisiert, dokumentiert und behoben werden – einschließlich der Koordination von CVE‑Veröffentlichungen mit Korrekturen.

Safe Harbor: OpenZiti und NetFoundry werden keine rechtlichen Schritte gegen Personen einleiten, die in gutem Glauben Sicherheitslücken erforschen und melden. Wir ermutigen zu Sicherheitsforschung und schreiben gemeldete Erkenntnisse in Hinweisen und Versionshinweisen ihren Meldern zu.

Community & Support

OpenZiti hat eine aktive und wachsende Community:

• Discourse‑Forum: Stellen Sie Fragen, teilen Sie Projekte, erhalten Sie Hilfe von der Community und den Maintainern
• YouTube: Tutorials, Demos und tiefergehende Inhalte
• Blog: Projektupdates und technische Artikel
• Twitter/X: Neuigkeiten und Ankündigungen

Mitwirken

Das OpenZiti‑Projekt begrüßt Beiträge – einschließlich Code, Dokumentation, Fehlermeldungen und Feedback.

Wichtige Repositories

Aus dem Quellcode erstellen

Siehe das Lokale Entwicklungstutorial für Build‑Anweisungen.

Entwicklerdokumentation

• Entwicklerübersicht
• Lokale Entwicklung
• Lokale Bereitstellung
• Controller‑PKI
• Versionshinweise

Anwender

OpenZiti wird in der Produktion von Organisationen eingesetzt, darunter DeltaSecure (Managed SOC), Resulticks (Marketingautomatisierung), Chirp Wireless (IoT/Telekommunikation), GIGO Dev (Cloud‑Entwicklungsumgebungen), OSMIT (Managed IT/DSGVO‑Compliance) und Open‑Source‑Projekte wie zrok und BlueBubbles.

Die vollständige Liste finden Sie unter: ADOPTERS.md. Nutzen Sie OpenZiti? Wir würden Sie gerne hinzufügen – eröffnen Sie ein Issue oder reichen Sie einen PR ein.

Managed Service

Für Zero‑Trust‑Netzwerke ohne Verwaltung Ihrer eigenen Infrastruktur bietet NetFoundry einen vollständig verwalteten, global verteilten OpenZiti‑Netzwerkdienst mit SLAs, Unternehmenssupport und einem globalen Fabric aus Edge‑Routern.

OpenZiti wird von NetFoundry, Inc entwickelt und als Open Source veröffentlicht.