Wie Zero Trust Network Access funktioniert
Zero Trust Network Access (ZTNA) ist ein Architekturansatz zur Steuerung des Zugriffs von Benutzern und Geräten auf Anwendungen und andere geschützte Ressourcen.
Der Kerngedanke ist einfach:
Zugriff sollte ausdrücklich für die angeforderte Ressource autorisiert werden, statt aus dem Netzwerkstandort oder einer bereits bestehenden Verbindung zu einem privaten Netzwerk abgeleitet zu werden.
ZTNA ist daher weder ein einzelnes Protokoll noch eine einzige Produktarchitektur oder ein bestimmtes Bereitstellungsmodell. Anbieter setzen das Konzept unterschiedlich um.
Der ZTNA-Entscheidungsablauf
1. Anforderer identifizieren
Vor der Autorisierung muss das System wissen, wer oder was Zugriff anfordert. Bei menschlichen Benutzern kann die Identität etwa aus einem OIDC Identity Provider, einem Unternehmensverzeichnis, lokalen Identitätsdaten oder anderen Authentifizierungssystemen stammen.
Identität ist nicht Autorisierung. Der erfolgreiche Nachweis, wer ein Benutzer ist, sollte nicht automatisch Zugriff auf jede private Ressource gewähren.
2. Gerät identifizieren
Ein Benutzer kann mehrere Endgeräte mit unterschiedlichem Sicherheitszustand besitzen. Ein ZTNA-System kann das Gerät separat über Registrierung, Zertifikate oder Geräteschlüssel, MDM-/EDR-Signale oder andere Posture-Prüfungen erfassen. So lässt sich ein registrierter Unternehmenslaptop von einem unbekannten Endgerät desselben Benutzers unterscheiden.
3. Kontext sammeln
Zusätzlicher Kontext kann angeforderte Ressource, Rolle oder Gruppe, Device Posture, Standort, Zeit, Zugriffsdauer, vorherige Genehmigung und erforderliche Step-up-Authentifizierung umfassen. Nicht jedes Produkt benötigt jedes Signal. Entscheidend ist, dass Zugriff explizit und richtliniengesteuert ist und nicht allein deshalb entsteht, weil ein Endgerät „innen“ ist.
4. Richtlinienentscheidung treffen
Die Richtlinien-Engine beantwortet beispielsweise:
Darf dieser Benutzer auf diesem Gerät unter den aktuellen Bedingungen auf diese Ressource zugreifen?
Beispiele sind Entwickler → Entwicklungsserver, Finance → Buchhaltungsanwendung, Anbieter → ein Wartungsportal bis Freitag oder Administrator → Produktionskonsole erst nach Genehmigung.
5. Entscheidung durchsetzen
ZTNA braucht einen Enforcement Point zwischen Anforderer und Ressource. Übliche Modelle sind:
Client und Gateway / Connector
Ein Endgeräte-Client stellt sichere Konnektivität über Gateway, Connector oder eine ähnliche Durchsetzungskomponente her. Das eignet sich für Protokolle mit Netzwerkzugriffsbedarf.
Clientloser Proxy
Für browserbasierte Anwendungen kann ein HTTP/HTTPS-Proxy Benutzer authentifizieren und autorisieren, ohne Tunnelsoftware auf dem Endgerät zu installieren.
Peer-orientiertes Networking
Manche Produkte verwenden koordinierte Peer-to-Peer-Netzwerke, bei denen eine zentrale Richtlinie die Kommunikationsrechte verteilt.
Alle Modelle können ZTNA umsetzen, solange Ressourcenzugriff explizit autorisiert bleibt.
6. Zugriffsumfang begrenzen
ZTNA ist mehr als Verschlüsselung. Sicherer Transport schützt Daten während der Übertragung; ZTNA muss zusätzlich bestimmen, was der authentifizierte Anforderer erreichen darf. Enge Ressourcenrichtlinien können unnötige Exposition und laterale Bewegung reduzieren. Netzwerksegmentierung und Host-Kontrollen bleiben dennoch wertvolle Defense-in-Depth-Maßnahmen.
7. Zugriff neu bewerten
Bedingungen ändern sich: temporäre Fenster laufen ab, Konten werden deaktiviert, Posture kann sich verschlechtern oder Rollen ändern. Eine ZTNA-Architektur sollte auf relevante Änderungen reagieren können, statt anzunehmen, dass eine einmal erfolgreiche Verbindung unbegrenzt gültig bleibt.
8. Ereignisse aufzeichnen
Nützliche Aufzeichnungen enthalten Identität, Gerät, Ressource, Authentifizierungsereignis, Richtlinienergebnis, Zugriffszeit sowie Widerruf oder Ablehnung. Sie unterstützen Untersuchungen, Access Reviews, Troubleshooting und SIEM-Workflows.
ZTNA ist nicht nur MFA
MFA stärkt die Authentifizierung, definiert aber nicht die Ressourcenautorisierung. Ein Benutzer kann MFA erfolgreich bestehen und trotzdem für eine bestimmte Anwendung nicht berechtigt sein.
ZTNA ist nicht nur ein VPN-Protokoll
WireGuard, IPsec und TLS können sicheren Transport liefern. Ein Tunnel kennt jedoch nicht automatisch Geschäftsrollen, Device Compliance, temporäre Genehmigungen oder Ressourcenzuordnungen. Diese Autorisierungsfragen gehören zum umgebenden Zugriffssystem.
Erfahren Sie, wie WireGuard in ZTNA passt
Control Plane und Data Plane
Die Control Plane verwaltet typischerweise Konfiguration, Identitäten und Gruppen, Ressourcen, Richtlinien, Koordination von Schlüsseln oder Autorisierung und administrative Workflows. Die Data Plane transportiert oder proxyt den eigentlichen Anwendungsverkehr.
Einige Anbieter betreiben beide Ebenen als Cloud-Dienst, andere nur die Control Plane mit Kunden-Connectors, und manche erlauben Self-Hosting oder Betrieb ohne verpflichtende Anbieter-Cloud.
Self-Hosted und Cloud-ZTNA vergleichen
Übliche ZTNA-Bereitstellungsmodelle
- Cloud-delivered: Anbieter betreibt Control Service und oft verteilte Enforcement-Infrastruktur.
- Anbieter-Control-Plane + Kunden-Connectors: zentrale Koordination beim Anbieter, Connectoren nahe privater Anwendungen.
- Self-hosted: Kunde oder MSP betreibt Management- und Enforcement-Infrastruktur.
- Standalone / disconnected: Zugriffssystem kann ohne verpflichtenden Anbieter-Control-Service arbeiten und dauerhaft isoliert betrieben werden.
Jedes Modell hat andere Trade-offs bei Betrieb, Verfügbarkeit, Datenkontrolle und Internetabhängigkeit.
Wo ZTXGate einzuordnen ist
ZTXGate nutzt eine vom Kunden oder MSP betriebene Zugriffsplattform. Der verwaltete Zugriff verwendet WireGuard-basierten Transport; lizenzierter Clientless Access kann unterstützte HTTP/HTTPS-Anwendungen proxyen. Identität, Gerät, Ressource, Posture, Zeit, Genehmigungsstatus und zusätzliche Authentifizierung können in Richtlinien einfließen.
ZTXGate kann eigenständig ohne verpflichtende CoreZT-Cloud-Control-Plane betrieben werden, auch air-gapped. Verbundene Bereitstellungen können optional das von CoreZT betriebene ZTXHub für zentrale Lizenz- und Softwareupdate-Verwaltung nutzen.
ZTXGate-Architektur entdecken · ZTXGate entdecken