Was ist ZTNA? Zero-Trust-Zugriff als Ersatz für das VPN

Was ist ZTNA? Zero Trust Network Access ist ein Zugriffsmodell, das Benutzer nicht mit dem Netzwerk, sondern ausschließlich mit der Anwendung verbindet, für die sie berechtigt sind, und dabei Identität, Sicherheitszustand des Geräts und Kontext in jeder Sitzung neu prüft. Es ersetzt den klassischen VPN-Ansatz „einmal anmelden, Zugang zum gesamten Netz“.

Was ist ZTNA und was bedeutet Zero Trust?

ZTNA überträgt den Grundsatz „keinem Benutzer, keinem Gerät und keinem Netzwerkstandort wird implizit vertraut“ auf den Fernzugriff. Der Benutzer weist zunächst seine Identität nach, das Gerät durchläuft eine Prüfung seines Sicherheitszustands, und erst dann wird eine Verbindung zu genau der Anwendung geöffnet, die die Richtlinie erlaubt – nur für diese Sitzung. Der Rest des Netzes bleibt für den Benutzer unsichtbar.

Zero Trust ist kein Produkt, sondern ein Architekturansatz. Die maßgebliche Definition stammt vom US-amerikanischen National Institute of Standards and Technology in der Veröffentlichung NIST SP 800-207 Zero Trust Architecture. Vereinfacht lauten ihre Grundprinzipien:

• Alle Datenquellen und Rechendienste gelten als Ressourcen; vom Drucker bis zum ERP-Server muss alles geschützt werden.
• Jede Kommunikation wird unabhängig vom Netzwerkstandort abgesichert; eine Anfrage aus dem internen LAN ist ebenso verdächtig wie eine aus dem Internet.
• Zugriff wird pro Sitzung und nach dem Prinzip der minimalen Rechte vergeben.
• Zugriffsentscheidungen beruhen auf dynamischen Richtlinien, die Identität, Anwendung, Gerätezustand und Verhaltenssignale gemeinsam bewerten.
• Das Unternehmen überwacht Integrität und Sicherheitszustand aller Assets, die es besitzt oder nutzt.
• Authentifizierung und Autorisierung werden vor jedem Zugriff strikt durchgesetzt und bei Bedarf erneuert.
• Gesammelte Netzwerk-, Asset- und Verkehrsdaten dienen der kontinuierlichen Verbesserung des Sicherheitsniveaus.

Dasselbe Dokument beschreibt eine logische Architektur aus drei Komponenten: die Policy Engine, die über den Zugriff entscheidet, den Policy Administrator, der diese Entscheidung in eine Verbindungsanweisung übersetzt, und den Policy Enforcement Point, der den Weg zwischen Benutzer und Ressource öffnet und schließt. ZTNA ist diese Architektur, angewendet auf mobile und hybride Mitarbeitende. Sie löst dasselbe Problem wie ein VPN – jemanden außerhalb des Büros sicher mit einer internen Anwendung zu verbinden –, allerdings mit einem anderen Vertrauensmodell.

Warum reicht das klassische VPN nicht mehr aus?

Ein klassisches Remote-Access-VPN authentifiziert den Benutzer einmal und macht ihn anschließend zum Mitglied des internen Netzes; Zugriff wird auf ein Netzsegment gewährt, nicht auf eine Anwendung. Dieses implizite Vertrauen macht aus einem einzigen kompromittierten Konto einen Ausgangspunkt für laterale Bewegung und hält ein aus dem Internet erreichbares VPN-Portal dauerhaft im Visier von Angreifern.

Das VPN trägt die Annahmen seiner Entstehungszeit in sich: Anwendungen liegen im Rechenzentrum, der Benutzer arbeitet an einem Firmengerät und das Innere des Netzes ist sicher. Keine dieser drei Annahmen gilt in der heutigen hybriden Arbeitswelt. Die vier Schwachstellen, die wir in Projekten am häufigsten sehen, sind:

• Zu weiter Zugriff: Ein Benutzer, der nur die Buchhaltungsanwendung braucht, sieht in den meisten Installationen nach dem Tunnelaufbau auch das gesamte Server-VLAN.
• Einmalige Prüfung: Nach der Anmeldung bleibt der Tunnel offen, auch wenn das Gerät infiziert wird oder der Benutzer in ein anderes Netz wechselt.
• Blindheit gegenüber dem Gerät: Ein klassisches VPN weiß nicht, ob auf dem verbundenen Gerät ein Virenschutz läuft, ob das Betriebssystem aktuell ist oder ob die Festplatte verschlüsselt ist.
• Exponierte Angriffsfläche: Ein VPN-Portal ist per Definition für jeden erreichbar; eine Schwachstelle darin gefährdet die gesamte Organisation, bis ein Patch verfügbar ist.

Diese Lage hat auch die Produktstrategie von Fortinet verändert. Laut den Fortinet-Versionshinweisen wurde der SSL-VPN-Tunnelmodus ab FortiOS 7.6.3 entfernt und durch IPsec VPN ersetzt, das auch über TCP-Port 443 betrieben werden kann; bestehende Konfigurationen werden beim Upgrade nicht übernommen. Bei einigen Einstiegsmodellen begann die Entfernung bereits in früheren Versionen, prüfen Sie daher die Versionshinweise für Ihr konkretes Modell. Die Migrationsschritte haben wir in unserem Beitrag über die Abschaffung von SSL VPN in FortiOS 7.6 und den Migrationsplan zusammengestellt; um Ihre aktuelle Konfiguration zu verstehen, bleibt unser Leitfaden zur FortiGate-VPN-Konfiguration ein guter Ausgangspunkt.

Wie funktioniert ZTNA?

Bei ZTNA hängt die Zugriffsentscheidung nicht vom Netzwerkstandort ab, sondern von drei Eingaben: der verifizierten Benutzeridentität, dem aktuellen Sicherheitszustand des Endgeräts und der angefragten Anwendung. Ein Entscheidungspunkt erzeugt die Richtlinie; ein Durchsetzungspunkt öffnet die Verbindung nur zur Zielanwendung, nur für diese Sitzung, und schließt sie, sobald sich die Bedingungen ändern.

Der Ablauf ist bei den meisten Herstellern ähnlich:

1. Anfrage: Der Benutzer öffnet eine interne Anwendung. Der ZTNA-Agent auf dem Gerät oder – beim browserbasierten Zugriff – ein Reverse Proxy fängt die Anfrage ab.
2. Authentifizierung: Der Benutzer wird gegen den Unternehmensverzeichnisdienst geprüft (Active Directory, Entra ID, SAML-Anbieter); Multi-Faktor-Authentifizierung ist fester Bestandteil dieses Schritts.
3. Gerätezustand: Der Agent meldet Betriebssystemversion, Virenschutzstatus, Festplattenverschlüsselung, Domänenmitgliedschaft und ähnliche Merkmale; daraus werden Tags.
4. Richtlinienentscheidung: Passt „Benutzer der Gruppe Finanzen + aktuelles, vom Unternehmen verwaltetes Gerät + ERP-Anwendung“ zu einer Regel, wird der Zugriff gewährt, andernfalls verweigert.
5. Verbindung: Der Verkehr wird über das Anwendungsgateway ausschließlich zur Zielanwendung geleitet. Die Anwendung ist nie direkt aus dem Internet erreichbar, und der Benutzer kann nicht in den Rest des Netzes routen.
6. Kontinuierliche Bewertung: Verschlechtert sich der Gerätezustand – wird etwa der Virenschutz deaktiviert –, entfällt der Tag und die Sitzung wird richtliniengemäß beendet.

Daraus ergeben sich zwei Folgen. Erstens werden Anwendungen „dunkel“: Ein externer Scan zeigt weder einen offenen Port noch eine Anmeldeseite. Zweitens hängen Sicherheitskontrollen an der Verbindung, nicht an der Person; derselbe Benutzer erreicht vom Firmen-Notebook das ERP-System, vom privaten Tablet aber nur die Webmail-Oberfläche. In einem klassischen VPN lässt sich diese Unterscheidung nur mit komplexen Regelwerken abbilden – und meist nur unvollständig.

VPN und ZTNA im Vergleich

Der grundlegende Unterschied zwischen VPN und ZTNA ist das Vertrauensmodell: VPN gewährt Zugang zum Netz und prüft einmal; ZTNA gewährt Zugang zur Anwendung und prüft fortlaufend. Die folgende Tabelle stellt die zehn Kriterien gegenüber, nach denen Entscheider am häufigsten fragen; jede Zeile fasst das typische Verhalten zusammen, das wir in Projekten beobachten.

Die Tabelle zeigt, dass ZTNA kein „besseres VPN“ ist, sondern ein anderes Vertrauensmodell. Dennoch ist das VPN nicht tot: Für IPsec-Tunnel zwischen Standorten, einige ältere UDP-basierte Anwendungen und Szenarien wie VoIP bleibt IPsec VPN das richtige Werkzeug. In einem sauberen Design bestehen beide eine Zeit lang nebeneinander; ZTNA übernimmt den Benutzerzugriff, IPsec den Site-to-Site- und Ausnahmeverkehr.

Die Fortinet-ZTNA-Architektur: FortiClient, EMS und FortiGate-Anwendungsgateway

Die Fortinet-ZTNA-Architektur besteht aus drei Komponenten: dem FortiClient-ZTNA-Agenten auf dem Endgerät, FortiClient EMS, das Identität und Gerätezustand in Tags übersetzt, und dem FortiGate als ZTNA-Anwendungsgateway, das die Zugriffsentscheidung durchsetzt. Die Struktur wurde mit FortiOS 7.0 eingeführt; die vorhandenen IPS-, Virenschutz- und Webfilter-Profile des FortiGate gelten auch für ZTNA-Verkehr.

Die Aufgabenverteilung der Komponenten sieht so aus:

Fortinet beschreibt den Ablauf so: Der FortiGate verbindet sich über einen Security-Fabric-Connector mit EMS und synchronisiert die ZTNA-Tags automatisch; EMS übermittelt Tag-Änderungen über eine persistente Verbindung sofort. Sicherheitszustands-Tags beruhen auf Prüfungen wie: Ist ein Virenschutz installiert, welche Betriebssystemversion läuft, ist das Gerät an der Domäne angemeldet, läuft ein bestimmter Prozess, welchen Wert hat ein Registrierungsschlüssel, welches Schwachstellenniveau hat das Gerät und liegt eine bekannte CVE vor. Der FortiGate kann diese Tags in ZTNA-Regeln, Firewall-Richtlinien und NAC-Richtlinien verwenden. Die grundlegenden Einrichtungsschritte sind im FortiOS-Administrationshandbuch von Fortinet dokumentiert.

Der Zugriff wird in zwei Formen bereitgestellt. Der HTTPS-Access-Proxy stellt Webanwendungen sowie in HTTPS gekapselte RDP-, SSH- oder VNC-Sitzungen über Browser oder Agent bereit. TCP-Forwarding ermöglicht für nicht webbasierte Client-Server-Anwendungen, dass FortiClient Anfragen an bestimmte Zieladressen und Ports abfängt und an das Anwendungsgateway weiterleitet. So laufen etwa ein ERP-Client oder ein Datenbank-Verwaltungswerkzeug ohne Netzwerktunnel. Soll auch der Verkehr von Standorten und der Internetausgang in dieses Modell überführt werden, ist unser Beitrag zu SASE und dem FortiSASE-Ansatz die logische Fortsetzung dieses Artikels.

Wie plant man die Migration von VPN zu ZTNA?

Die Migration von VPN zu ZTNA ist kein Umschalten über Nacht, sondern ein schrittweises Programm aus Inventur, Identität, Endgeräten und Pilotanwendung, in dem das VPN eine Zeit lang parallel weiterläuft. In unseren Projekten kostet nicht die Technik die meiste Zeit, sondern die Klärung, welcher Benutzer tatsächlich welche Anwendung braucht.

1. Inventur von Anwendungen und Benutzern: Listen Sie jede über das VPN erreichte Anwendung, ihr Protokoll (HTTPS, RDP, SSH, Datenbank, Dateifreigabe) und die Benutzergruppen auf. Ihre VPN-Logs sind die ehrlichste Quelle dieser Inventur.
2. Identitätsinfrastruktur: Ein sauberer Verzeichnisdienst, eine klare Gruppenstruktur und Multi-Faktor-Authentifizierung sind Voraussetzungen für ZTNA. Verwaiste Konten und Gruppen, in denen alle Mitglied sind, machen jede Richtlinie wertlos.
3. Vorbereitung der Endgeräte: FortiClient EMS wird installiert, der Agent zunächst auf vorhandene Geräte verteilt und die Zustands-Tags im Überwachungsmodus gesammelt. Der Gerätezustand stützt sich auf eine verlässliche Endpunktschutz-Schicht; welche Schicht nötig ist, erläutern wir in unserem Beitrag zu den Unterschieden zwischen EDR, XDR und MDR.
4. Pilot: Beginnen Sie mit ein oder zwei Webanwendungen und einer freiwilligen Benutzergruppe. Diese Phase testet Richtlinienlogik und Benutzererlebnis mit geringem Risiko.
5. Ausweitung: Nehmen Sie über TCP-Forwarding-Regeln RDP, SSH und Client-Server-Anwendungen hinzu; beantworten Sie für jede Anwendung die Frage „wer, mit welchem Gerätezustand“ einzeln. Für ein schlankes Regelwerk gelten die Prinzipien des FortiGate-Richtlinienmanagements auch hier.
6. Umgang mit Ausnahmen: Für UDP-basierte oder ältere Anwendungen, die ZTNA nicht abdeckt, behalten Sie IPsec VPN mit eng gefasstem Umfang bei.
7. Abschaltung des VPN-Portals: Sobald Benutzer- und Anwendungsumfang abgedeckt sind, deaktivieren Sie das alte Portal und binden die Zugriffslogs an ein zentrales Log-Management an.

Diese Reihenfolge gilt auch für Organisationen, die sich nach FortiOS 7.6 zwangsläufig von SSL VPN verabschieden; der einzige Unterschied ist, dass der erste Schritt meist mit einem Upgrade-Zeitplan zusammenfällt.

Ist ZTNA für KMU realistisch?

ZTNA ist nicht nur etwas für Großunternehmen. Ein KMU mit vorhandenem FortiGate kann durch Ergänzung von FortiClient und EMS das ZTNA-Anwendungsgateway auf demselben Gerät aktivieren. Die Kosten hängen von der Anzahl der Endgeräte ab, davon, ob EMS in der Cloud oder lokal läuft, und davon, ob für den Standortverkehr FortiSASE nötig ist; eine konkrete Summe ergibt sich erst aus einem Angebot nach der Bestandsaufnahme.

In unserer Praxis zeigen sich drei Situationen, in denen ZTNA auch in kleinen und mittleren Unternehmen sinnvoll ist. Erstens externe Dienstleister sowie Berater aus Buchhaltung oder Recht: Ihnen ein VPN zu geben heißt, das ganze Netz zu öffnen; mit ZTNA sehen sie nur die betreffende Anwendung. Zweitens die Zugriffskontrolle auf personenbezogene Daten: Minimale Rechte und detaillierte Zugriffsprotokolle entsprechen der Berechtigungsmatrix und der Protokollierung, die der türkische Datenschutzrat (KVKK) in seinem Leitfaden zur Sicherheit personenbezogener Daten beschreibt; unter der Voraussetzung, dass Sie die aktuelle Rechtslage und den offiziellen Leitfaden prüfen, liefert ZTNA die technische Umsetzung dieser Maßnahmen. Drittens das Ransomware-Risiko: Dass ein Angreifer mit einem VPN-Konto ins Netz gelangt und den Backup-Server erreicht, wird bei ZTNA konstruktionsbedingt verhindert.

Als Sora Yazılım arbeiten wir als unabhängiger Lösungspartner: Im Erstgespräch erfassen wir Ihren vorhandenen FortiGate, Ihre Benutzerprofile und Ihr Anwendungsinventar, legen gemeinsam die Grenzen zwischen ZTNA und IPsec fest, übernehmen die Implementierung und führen die Pflege der Richtlinien auf Wunsch als Managed Service fort.

Häufig gestellte Fragen

Ersetzt ZTNA das VPN vollständig?

Für den Fernzugriff von Benutzern auf Anwendungen ja; ZTNA bietet hier engere Rechte und bessere Transparenz. Für Site-to-Site-Verbindungen zwischen Standorten, ältere UDP-basierte Anwendungen und manche VoIP-Szenarien bleibt IPsec VPN relevant. In den meisten Organisationen laufen beide eine Zeit lang parallel.

Braucht ZTNA zwingend eine Agent-Software?

Nein. Für Webanwendungen ist agentenloser Zugriff über den Browser möglich; für die Prüfung des Gerätezustands und für nicht webbasierte Anwendungen ist jedoch ein Agent nötig. In der Fortinet-Architektur ist das FortiClient, dessen Zustandsdaten über FortiClient EMS in Tags umgewandelt werden.

Braucht man für ZTNA auf dem FortiGate eine zusätzliche Lizenz?

Das ZTNA-Anwendungsgateway ist eine integrierte Funktion von FortiOS. Für die Endgeräte werden FortiClient- und für die Zentrale FortiClient-EMS-Lizenzen benötigt. Da der Lizenzumfang je nach Version und Paket variiert, sollte er anhand aktueller Fortinet-Dokumente geprüft und im Angebot genau festgelegt werden.

Was ist der Unterschied zwischen ZTNA und SASE?

ZTNA ist eine einzelne Funktion, die den sicheren Zugriff von Benutzern auf interne Anwendungen regelt. SASE ist ein breiterer Rahmen, der ZTNA mit Secure Web Gateway, CASB, Firewall as a Service und SD-WAN kombiniert und aus der Cloud bereitstellt. FortiSASE liefert ZTNA als Teil dieses Gesamtpakets.

Wie unterstützt ZTNA die Einhaltung von Datenschutzvorgaben?

ZTNA beschränkt den Zugriff auf Anwendungen mit personenbezogenen Daten nach Identität, Gerät und Anwendung und protokolliert jeden Zugriff. Das passt zu Berechtigungsmatrix und Protokollierung im KVKK-Leitfaden zur Datensicherheit; Compliance ist jedoch ein Gesamtbild, prüfen Sie die aktuelle Rechtslage und den offiziellen Leitfaden.

Gibt es während der Migration Ausfälle für die Benutzer?

Bei guter Planung nicht. In der Pilotphase bleibt das VPN aktiv, Benutzer wechseln Anwendung für Anwendung zu ZTNA und können bei Problemen noch am selben Tag zum VPN zurückkehren. Das Ausfallrisiko ist am höchsten, wenn der Agent massenhaft verteilt wird, bevor die Identitätsinfrastruktur bereit ist.

Fazit

ZTNA verändert das Vertrauensmodell des Fernzugriffs: Anwendung statt Netz, fortlaufende Bewertung statt einmaliger Prüfung, von außen unsichtbare Ressourcen statt eines exponierten Portals. Der von NIST SP 800-207 gezeichnete Rahmen nimmt bei Fortinet mit dem Trio aus FortiClient, EMS und FortiGate-Anwendungsgateway konkrete Gestalt an; die Entfernung des SSL-VPN-Tunnelmodus in FortiOS 7.6.3 hat diesen Wechsel für viele Organisationen terminiert. Die richtige Reihenfolge lautet Inventur, Identität, Endgerät, Pilot und schrittweise Ausweitung.

Wenn Sie gemeinsam bewerten möchten, wie Ihre aktuelle VPN-Umgebung zu ZTNA migriert werden kann, vereinbaren Sie ein kostenloses Erstgespräch; wir erstellen Ihnen ein Angebot für den passenden Umfang an FortiClient, EMS und FortiSASE.