Zero Trust einfach erklärt: ZTNA statt klassischem VPN
Zero Trust bedeutet nicht, dass man niemandem mehr vertraut. Es bedeutet, dass Zugriff nicht mehr pauschal gewährt wird, nur weil ein Benutzer im internen Netz, im VPN oder an einem bekannten Standort ist. Jeder Zugriff wird bewusst geprüft: Wer greift zu? Von welchem Gerät? Auf welche Anwendung? Unter welchen Bedingungen?
Zero Trust Network Access, kurz ZTNA, ist eine konkrete Umsetzung dieses Gedankens für Remote Access und private Anwendungen. Statt ein ganzes Netzwerk per VPN zu öffnen, erhält ein Benutzer nur Zugriff auf die Anwendungen oder Ressourcen, die für seine Rolle vorgesehen sind.
Der Artikel erklärt die Grundlagen bewusst herstellerneutral. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access und andere Lösungen setzen ähnliche Prinzipien unterschiedlich um. Entscheidend ist deshalb nicht zuerst das Produkt, sondern das Zugriffsmodell.
Zero Trust und ZTNA einordnen
Zero Trust ist eine Sicherheitsarchitektur. ZTNA ist ein technischer Zugriffspfad innerhalb dieser Architektur.
Zero Trust ist ein Prinzip
Klassische Netzwerke arbeiten oft mit einer stillen Annahme: innen ist vertrauenswürdiger als aussen. Genau diese Annahme ist heute gefährlich. Benutzer arbeiten mobil, Anwendungen liegen in SaaS, Rechenzentrum und Cloud, Geräte wechseln ständig den Standort, und kompromittierte Zugangsdaten sind ein realistisches Szenario.
Zero Trust verschiebt den Fokus von Netzwerkgrenzen zu Identität, Gerät, Anwendung, Daten und Kontext. NIST beschreibt Zero Trust als Architektur, bei der implizites Vertrauen reduziert und Zugriff pro Anfrage bewertet wird. Für die Praxis heisst das: Eine erfolgreiche Anmeldung allein reicht nicht mehr.
ZTNA ist der Zugriff auf konkrete Ressourcen
ZTNA ersetzt breite Netzwerkfreigaben durch ressourcenbasierten Zugriff. Ein Benutzer sieht nicht automatisch ein ganzes Subnetz, sondern nur die Anwendungen, für die eine Policy passt.
Typische ZTNA-Ressourcen sind:
- interne Webanwendungen,
- Admin-Portale,
- RDP- oder SSH-Zugriffe über kontrollierte Wege,
- einzelne TCP-Anwendungen,
- Entwicklungs-, Support- oder Partnerzugriffe,
- SaaS-Anwendungen mit zusätzlicher Zugriffskontrolle.
Damit wird Remote Access feiner steuerbar. Ein kompromittierter Account soll nicht sofort das ganze interne Netzwerk erreichen können.
Warum ZTNA anders ist als VPN
VPN ist nicht automatisch schlecht. Viele Umgebungen brauchen weiterhin Site-to-Site-VPN, Admin-VPN, Spezialprotokolle oder Notfallzugänge. Der Unterschied liegt im Vertrauensmodell.
VPN öffnet oft ein Netzwerk
Ein klassischer Remote-Access-VPN verbindet ein Gerät mit einem internen Netz. Danach entscheiden Routing, Firewall-Regeln, DNS und Segmentierung, was erreichbar ist. Wenn diese Umgebung sauber gebaut ist, kann das funktionieren. In der Praxis sind VPN-Netze aber oft zu breit, historisch gewachsen oder schwer zu prüfen.
Typische Risiken sind:
- Benutzer erhalten Zugriff auf mehr Systeme als nötig.
- Alte VPN-Gruppen bleiben bestehen.
- Split-Tunnel, DNS und Routen sind unklar.
- Malware auf einem VPN-Client kann interne Ziele erreichen.
- Admin-Zugriffe werden über denselben Tunnel wie Benutzerzugriffe geführt.
ZTNA prüft näher an der Anwendung
ZTNA entscheidet pro Anwendung oder Ressource. Eine Policy kann Benutzergruppe, MFA, Gerät, Standort, Risiko, Clientstatus und weitere Bedingungen berücksichtigen. Erst wenn die Bedingungen passen, wird der Zugriff auf genau diese Ressource freigegeben.
Das reduziert die Angriffsfläche, ersetzt aber keine saubere Applikationssicherheit. Eine unsichere Anwendung bleibt unsicher, auch wenn sie hinter ZTNA steht. ZTNA kontrolliert den Zugang, nicht automatisch die Anwendung selbst.
Bausteine einer guten Zero-Trust-Umgebung
Zero Trust wird schwach, wenn es nur als neues Zugangstool eingeführt wird. Der Nutzen entsteht erst durch mehrere Bausteine, die zusammenpassen.
Identität und MFA
Die Identität ist der wichtigste Einstiegspunkt. Benutzer, Gruppen, Rollen und externe Konten müssen sauber gepflegt sein. MFA sollte für kritische Zugriffe Pflicht sein. In Microsoft-Umgebungen ist Microsoft Entra ID oft die zentrale Identitätsquelle; in anderen Umgebungen können andere Identity Provider dieselbe Rolle übernehmen.
Wichtig ist auch das Offboarding. Wenn ein Benutzer das Unternehmen verlässt, darf der Zugriff nicht nur in einer Anwendung, sondern in der zentralen Identität und in allen relevanten Policies verschwinden.
Gerät und Kontext
ZTNA wird stärker, wenn nicht nur der Benutzer, sondern auch das Gerät bewertet wird. Je nach Lösung können Betriebssystem, Gerätestatus, Zertifikat, EDR-Status, Managementstatus, Standort oder Risiko in die Entscheidung einfliessen.
Das ist besonders relevant bei:
- privaten Geräten,
- externen Dienstleistern,
- privilegierten Admin-Zugriffen,
- Zugriff auf Finanz-, HR- oder Produktionssysteme,
- Geräten ohne aktuellen Schutzstatus.
Gateway, Connector oder Cloud-Dienst
ZTNA braucht einen Datenpfad zwischen Benutzer und Anwendung. Je nach Anbieter gibt es Gateways, Connectoren, Tunnel oder Cloud-PoPs. Dieser Teil entscheidet, wo Traffic eintritt, wer den Datenpfad betreibt und welche DNS-, Zertifikats- und Firewall-Regeln nötig sind.
Cloudflare arbeitet oft mit Cloudflare Tunnel und Access Policies. Sophos ZTNA verwendet Sophos Central, ZTNA Gateways und Ressourcen-Policies. Die Architektur ist unterschiedlich, die Grundfrage bleibt gleich: Wie kommt ein Benutzer kontrolliert zur Anwendung, ohne das ganze Netzwerk zu öffnen?
Policies, Logging und Betrieb
Eine ZTNA-Policy muss später noch verständlich sein. Deshalb sollten Namen, Gruppen, Bedingungen und Ausnahmen dokumentiert werden. Logging ist Pflicht, weil man sonst nicht erkennt, ob eine Policy zu breit ist, Benutzer blockiert werden oder ein Zugriff unerwartet häufig genutzt wird.
Wann ZTNA sinnvoll ist
ZTNA passt besonders gut, wenn einzelne Anwendungen gezielt erreichbar sein sollen. Es ist kein Selbstzweck und kein automatischer Ersatz für jede Verbindung.
Gute Einsatzfälle
ZTNA ist meistens sinnvoll für:
- interne Webanwendungen für Mitarbeitende,
- Partner- oder Dienstleisterzugriffe,
- Admin-Portale, die nicht öffentlich erreichbar sein sollen,
- RDP oder SSH über kontrollierte Zugriffspfade,
- Anwendungen mit klaren Benutzergruppen,
- Umgebungen, in denen VPN-Zugriff zu breit geworden ist,
- schrittweise Ablösung alter Remote-Access-Modelle.
Gerade für externe Dienstleister ist ZTNA oft angenehmer als VPN. Man muss kein ganzes Netzwerk freigeben, sondern kann eine konkrete Anwendung mit klarer Policy veröffentlichen.
Wo VPN weiterhin passt
VPN bleibt sinnvoll, wenn ganze Netze verbunden werden müssen, wenn Spezialprotokolle nicht sauber über ZTNA funktionieren oder wenn ein Notfallzugang unabhängig von Cloud-Diensten gebraucht wird. Site-to-Site-Verbindungen, bestimmte OT-Umgebungen, Legacy-Anwendungen und komplexe Admin-Szenarien können weiterhin VPN benötigen.
Die richtige Frage lautet deshalb nicht: “VPN oder ZTNA?” Besser ist: “Welche Ressource braucht welchen Zugriffspfad?”
Anbieter neutral bewerten
ZTNA-Lösungen unterscheiden sich stark. Manche sind sehr gut für browserbasierte Anwendungen, andere für Client-basierte Zugriffe, wieder andere als Teil einer grösseren SSE- oder SASE-Plattform.
Wichtige Auswahlkriterien
Vor der Produktauswahl sollte man diese Punkte klären:
- Welche Anwendungen sollen erreichbar sein?
- Braucht es browserbasierten Zugriff, Client-Zugriff oder beides?
- Welcher Identity Provider ist gesetzt?
- Sollen Geräte posturebasiert geprüft werden?
- Wo liegt der Datenpfad: eigener Standort, Anbieter-Cloud oder beides?
- Wie funktionieren Logs, SIEM-Export und Audit?
- Gibt es klare Notfall- und Break-Glass-Prozesse?
- Wie gut passt die Lösung zu bestehenden Firewalls, EDR, MDM und DNS?
Cloudflare ist oft stark, wenn Access, Tunnel, DNS, Web-Security und globale Edge-Infrastruktur zusammenspielen sollen. Sophos ZTNA passt häufig gut in Umgebungen, die bereits Sophos Central, Sophos Endpoint oder Sophos Firewall stark nutzen. Das ist keine Glaubensfrage, sondern Architekturarbeit.
Nicht jedes Zero Trust ist automatisch besser
Ein schlecht gepflegtes ZTNA ist nur ein moderneres Risiko. Wenn Gruppen zu breit sind, alte Ausnahmen bleiben, Logs niemand liest oder Geräteprüfung nur auf dem Papier existiert, entsteht keine starke Zero-Trust-Umgebung.
Einführung in sinnvoller Reihenfolge
Eine gute Einführung beginnt nicht mit dem Produktklick, sondern mit einer kleinen, gut verstandenen Anwendung.
- Anwendungen inventarisieren und nach Risiko sortieren.
- Benutzergruppen und externe Rollen bereinigen.
- Identity Provider und MFA stabilisieren.
- Eine Pilotanwendung auswählen, die wichtig, aber beherrschbar ist.
- Datenpfad, DNS, Zertifikat und Logging planen.
- Policy mit kleiner Benutzergruppe testen.
- Logs prüfen, Supportfälle sammeln und Benutzererlebnis verbessern.
- Weitere Anwendungen schrittweise migrieren.
- VPN-Zugriffe erst reduzieren, wenn ZTNA im Betrieb funktioniert.
Für Sophos-spezifische Umgebungen passt danach Sophos ZTNA einrichten: Überblick und Reihenfolge. Wenn es konkret um das Gateway geht, hilft Sophos ZTNA Gateway planen und erstellen.
Typische Fehler
ZTNA als reines VPN-Ersatzprojekt behandeln
Wenn nur der Tunnel ersetzt wird, aber Gruppen, Anwendungen, Geräte und Logs unverändert bleiben, entsteht wenig Sicherheitsgewinn. ZTNA sollte pro Ressource geplant werden.
Zu viele Anwendungen auf einmal migrieren
Ein grosser Big-Bang-Rollout ist riskant. Besser ist ein Pilot mit einer echten Anwendung, klaren Erfolgskriterien und sauberem Rückfallweg.
Notfallzugriff vergessen
Identity Provider, DNS, Cloud-Dienst oder Gateway können ausfallen. Für Admins braucht es einen dokumentierten Break-Glass-Zugriff, der stark geschützt, selten genutzt und regelmässig geprüft wird.
Logs nicht betreiben
ZTNA ohne Logging ist schwer zu supporten. Man sollte sehen können, welcher Benutzer auf welche Ressource zugreift, welche Policy greift, warum ein Zugriff blockiert wurde und ob ungewöhnliche Muster entstehen.
Betriebscheckliste
- Anwendungen und Owner dokumentieren.
- Benutzergruppen klein und verständlich halten.
- MFA für kritische Zugriffe erzwingen.
- Geräteprüfung aktiv nutzen, wenn die Lösung sie sauber unterstützt.
- Policies regelmässig gegen echte Nutzung prüfen.
- Logs in ein SIEM oder zentrales Logging übernehmen, wenn der Zugriff kritisch ist.
- Break-Glass-Zugang dokumentieren und testen.
- Alte VPN-Freigaben nach erfolgreicher Migration entfernen.
- Dienstleisterzugriffe mit Ablaufdatum oder Review-Termin versehen.