VPN oder Zero Trust Network Access: was noch für die Appliance spricht
Vier ausgenutzte VPN-Schwachstellen in zwei Jahren haben die Frage verschoben: nicht ob, sondern wofür die Appliance bleibt. Sechs Kriterien, ein Fazit.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Kurz gesagt
Für den Zugriff von Beschäftigten und Dienstleistern auf Web- und TCP-Anwendungen ist ein ZTNA-Dienst dem klassischen Remote-Access-VPN überlegen: kein offener Port nach außen, Zugriff je Anwendung statt je Netz, Bewertung von Nutzer und Gerät bei jeder Anfrage. Die VPN-Appliance bleibt dort, wo Standortkopplung, Legacy-Protokolle oder Produktionsanlagen einen echten Netzzugang brauchen, dann aber mit IPsec, MFA und ohne Verwaltungsoberfläche am Internet. Die meisten Häuser betreiben beides und müssen entscheiden, was über welchen Weg läuft.
Stand dieser Seite: 04.10.2026
01 Worum es geht
Die Appliance am Netzrand ist das Ziel, nicht der Schutz
Der Ablauf wiederholt sich seit 2024 alle paar Monate: Ein Hersteller veröffentlicht einen Hinweis zu einer kritischen Schwachstelle im VPN-Portal, die bereits ausgenutzt wird, und Admins haben ein Wochenende, um zu patchen und nach Spuren zu suchen. Palo Alto GlobalProtect mit CVE-2024-3400, Fortinet FortiOS mit CVE-2024-55591, Ivanti Connect Secure mit CVE-2025-22457 und Cisco ASA mit CVE-2025-20333 stehen alle im Katalog ausgenutzter Schwachstellen der US-Behörde CISA.
Der Preis liegt nicht im Patchen, sondern in dem, was ein kompromittiertes VPN bedeutet. Wer durch das Portal kommt, steht im Netz, oft mit Zugriff auf ganze Segmente, weil Remote-Access-VPN Netze verbindet und nicht Anwendungen freigibt. Von dort laufen Erkundung, Bewegung zum Domänencontroller und Verschlüsselung. Für NIS2-Einrichtungen ist das zugleich ein meldepflichtiger Vorfall und ein Verstoß gegen § 30 Abs. 2 Nr. 9 und 10 BSIG, die Zugriffskontrolle und Multi-Faktor- oder kontinuierliche Authentifizierung verlangen.
Gleichzeitig verschwinden Optionen. Fortinet hat mit FortiOS 7.6.3 den SSL-VPN-Tunnelmodus auf allen FortiGate-Modellen aus GUI und CLI entfernt; die Einstellungen werden beim Upgrade nicht übernommen. Die Anbieter von ZTNA-Diensten werben derweil mit Preisen je Nutzer und Monat, die sich bei tausend Beschäftigten zu einer Summe addieren, die niemand im Budget hatte. Die Entscheidung ist deshalb keine Glaubensfrage, sondern eine Inventurfrage: Welche Anwendungen laufen heute durch den Tunnel, und welche davon brauchen wirklich ein Netz?
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
02 Der direkte Vergleich
Sechs Kriterien, an denen sich die Wahl entscheidet
Verglichen werden drei Wege, die in den meisten Häusern nebeneinander in Betrieb sind: das klassische Remote-Access-VPN über eine Appliance, ein ZTNA-Dienst aus der Cloud wie Microsoft Entra Private Access, Zscaler Private Access oder Cloudflare Access, und ZTNA auf der eigenen Firewall, wie Fortinet es mit Universal ZTNA auf FortiGate und FortiClient umsetzt.
Remote-Access-VPN
Eine Appliance am Netzrand nimmt IPsec- oder SSL-Verbindungen an und stellt den Client in ein internes Netzsegment; der Zugriff wird über Firewall-Regeln und Routing begrenzt.
ZTNA-Dienst aus der Cloud
Ein Broker des Anbieters vermittelt je Anwendung zwischen Client und einem Connector im eigenen Netz; keine eingehenden Ports, Entscheidung je Anfrage anhand von Identität, Gerät und Richtlinie.
ZTNA auf der eigenen Firewall
Die vorhandene Firewall arbeitet als Zugriffsproxy je Anwendung und wertet Geräte-Tags eines Endpoint-Agenten aus; der Datenpfad bleibt im eigenen Haus.
| Entscheidungsfrage | Remote-Access-VPN | ZTNA-Dienst aus der Cloud | ZTNA auf der eigenen Firewall |
|---|---|---|---|
| Wie groß ist die Angriffsfläche am Netzrand? | Schwäche Die Appliance muss am Internet lauschen, und genau diese Dienste trafen CVE-2024-3400, CVE-2024-55591, CVE-2025-22457 und CVE-2025-20333, alle im CISA-Katalog ausgenutzter Schwachstellen. Härtung senkt das Risiko, beseitigt den offenen Port aber nicht. | Stärke Der Connector im eigenen Netz baut nur ausgehende Verbindungen zum Broker auf; am eigenen Netzrand lauscht nichts. Die Angriffsfläche wandert zum Anbieter, der sie für alle Kunden gleichzeitig pflegt, und wird dort zum Klumpenrisiko. | Kommt darauf an Die Firewall bleibt am Netzrand und nimmt weiterhin Verbindungen an, nun als Proxy je Anwendung statt als Tunnelendpunkt. Der Zugriff dahinter ist enger, die lauschende Komponente aber dieselbe Geräteklasse, die zuletzt betroffen war. |
| Wie viel Netz bekommt, wer durch ist? | Schwäche Der Client steht in einem Segment und erreicht alles, was Firewall-Regeln nicht ausdrücklich sperren. In gewachsenen Umgebungen sind diese Regeln breit. Seitwärtsbewegung zum Domänencontroller ist der klassische zweite Schritt nach einem kompromittierten VPN-Konto. | Stärke Freigegeben wird eine Anwendung über Name, Adresse und Port, nicht ein Netz. Wer das ERP erreichen darf, sieht den Dateiserver daneben nicht. Entra Private Access koppelt das an Conditional Access, sodass dieselbe Richtlinie für Cloud- und interne Anwendungen gilt. | Stärke Auch hier wird je Anwendung freigegeben, über Proxy-Regeln und Geräte-Tags. Der Vorteil: Dieselbe Firewall segmentiert auch den internen Verkehr, sodass Fernzugriff und interne Zugriffe nach einer Logik behandelt werden. |
| Laufen Legacy-Protokolle, Drucker und servergestartete Verbindungen? | Stärke Ein Tunnel auf Netzebene transportiert alles: SMB, RDP, Drucker, VoIP, Datenbankclients, Verbindungen, die der Server zum Client öffnet, und das Protokoll des Herstellers ohne Dokumentation. Genau deshalb bleibt das VPN dort, wo diese Dinge gebraucht werden. | Kommt darauf an Web-, TCP- und UDP-Anwendungen laufen mit Client-Agent gut; Entra Private Access deckt beliebige TCP- und UDP-Ports ab. Schwierig werden servergestartete Verbindungen, Broadcasts im Subnetz und Anwendungen, die feste Client-Adressen voraussetzen. Jede davon braucht einen Test vor der Migration. | Kommt darauf an Als Proxy je Anwendung gelten dieselben Grenzen wie beim Cloud-Dienst. Weil dieselbe FortiGate aber auch IPsec kann, lässt sich der Rest als gehärtetes VPN daneben betreiben, ohne zweite Appliance. Für den Übergang ist das praktisch, für die Architektur ein Kompromiss. |
| Wie gut fließen Identität, Gerätezustand und laufende Bewertung in die Entscheidung ein? | Kommt darauf an MFA ist über RADIUS oder SAML nachrüstbar und nach § 30 Abs. 2 Nr. 10 BSIG ohnehin Pflicht. Der Gerätezustand wird höchstens beim Verbindungsaufbau geprüft, und einmal verbunden bleibt die Sitzung bestehen, bis sie abläuft. Eine Änderung des Risikos erreicht den Tunnel nicht. | Stärke Identität, Gerätekonformität und Risikosignale entscheiden bei jeder Anfrage. Bei Entra Private Access greifen Conditional-Access-Richtlinien je Anwendung, und über Continuous Access Evaluation wirkt ein Widerruf der Sitzung nahezu in Echtzeit. Das ist die laufende Bewertung, die das BSI-Positionspapier beschreibt. | Stärke Geräte-Tags des Endpoint-Agenten zu Patchstand, Virenschutz und Verschlüsselung fließen in die Proxy-Regel ein und werden fortlaufend aktualisiert. Die Identität kommt über SAML aus dem Verzeichnis. Was fehlt, ist die Kopplung an die Risikosignale des Identitätsanbieters. |
| Welchen Nachweis liefern die Protokolle? | Kommt darauf an Das Protokoll zeigt, wer wann einen Tunnel aufgebaut hat und welche Adresse er bekam. Was danach im Netz passierte, steht in Firewall- und Serverprotokollen, die jemand zusammenführen muss. Die Frage, wer auf welche Anwendung zugegriffen hat, kostet einen Nachmittag im SIEM. | Stärke Jeder Zugriff ist ein Ereignis mit Nutzer, Gerät, Anwendung, Richtlinie und Entscheidung. Wer wann auf das ERP zugegriffen hat, ist eine Abfrage statt einer Korrelation. Für Nachweise nach § 30 Abs. 1 BSIG oder gegenüber einem Auditor ist das der kürzeste Weg. | Stärke Die Firewall protokolliert je Proxy-Regel mit Nutzer und Geräte-Tag, und die Protokolle liegen im eigenen Haus. Der Nachweis ist ähnlich gut wie beim Cloud-Dienst, solange die Protokolle zentral gesammelt und nicht nach Tagen auf dem Gerät überschrieben werden. |
| Was kostet der Weg an Lizenzen, Betrieb und Abhängigkeit? | Kommt darauf an Die Appliance ist bezahlt und die Lizenz je Nutzer oft inklusive. Dagegen stehen Patch-Wochenenden, der Austausch beim Herstellerwechsel und erzwungene Migrationen wie die von SSL-VPN auf IPsec mit FortiOS 7.6.3. Die Abhängigkeit vom Hersteller ist genauso da, nur weniger sichtbar. | Schwäche Es fällt ein Preis je Nutzer und Monat an, bei Entra Private Access zusätzlich zur vorausgesetzten P1- oder P2-Lizenz, und der Dienst wird zur Voraussetzung für jeden internen Zugriff. Ein Anbieterwechsel heißt, alle Anwendungsdefinitionen und Richtlinien neu zu bauen. | Kommt darauf an Die Funktion ist in der Firewall-Lizenz enthalten, der Endpoint-Agent und seine Verwaltung kommen dazu. Die Abhängigkeit richtet sich auf einen Hersteller für Firewall, Agent und Verwaltung zugleich. Für Häuser, die diese Plattform ohnehin betreiben, ist das der günstigste Einstieg, für alle anderen ein Plattformwechsel. |
Wie groß ist die Angriffsfläche am Netzrand?
Die Appliance muss am Internet lauschen, und genau diese Dienste trafen CVE-2024-3400, CVE-2024-55591, CVE-2025-22457 und CVE-2025-20333, alle im CISA-Katalog ausgenutzter Schwachstellen. Härtung senkt das Risiko, beseitigt den offenen Port aber nicht.
Der Connector im eigenen Netz baut nur ausgehende Verbindungen zum Broker auf; am eigenen Netzrand lauscht nichts. Die Angriffsfläche wandert zum Anbieter, der sie für alle Kunden gleichzeitig pflegt, und wird dort zum Klumpenrisiko.
Die Firewall bleibt am Netzrand und nimmt weiterhin Verbindungen an, nun als Proxy je Anwendung statt als Tunnelendpunkt. Der Zugriff dahinter ist enger, die lauschende Komponente aber dieselbe Geräteklasse, die zuletzt betroffen war.
Wie viel Netz bekommt, wer durch ist?
Der Client steht in einem Segment und erreicht alles, was Firewall-Regeln nicht ausdrücklich sperren. In gewachsenen Umgebungen sind diese Regeln breit. Seitwärtsbewegung zum Domänencontroller ist der klassische zweite Schritt nach einem kompromittierten VPN-Konto.
Freigegeben wird eine Anwendung über Name, Adresse und Port, nicht ein Netz. Wer das ERP erreichen darf, sieht den Dateiserver daneben nicht. Entra Private Access koppelt das an Conditional Access, sodass dieselbe Richtlinie für Cloud- und interne Anwendungen gilt.
Auch hier wird je Anwendung freigegeben, über Proxy-Regeln und Geräte-Tags. Der Vorteil: Dieselbe Firewall segmentiert auch den internen Verkehr, sodass Fernzugriff und interne Zugriffe nach einer Logik behandelt werden.
Laufen Legacy-Protokolle, Drucker und servergestartete Verbindungen?
Ein Tunnel auf Netzebene transportiert alles: SMB, RDP, Drucker, VoIP, Datenbankclients, Verbindungen, die der Server zum Client öffnet, und das Protokoll des Herstellers ohne Dokumentation. Genau deshalb bleibt das VPN dort, wo diese Dinge gebraucht werden.
Web-, TCP- und UDP-Anwendungen laufen mit Client-Agent gut; Entra Private Access deckt beliebige TCP- und UDP-Ports ab. Schwierig werden servergestartete Verbindungen, Broadcasts im Subnetz und Anwendungen, die feste Client-Adressen voraussetzen. Jede davon braucht einen Test vor der Migration.
Als Proxy je Anwendung gelten dieselben Grenzen wie beim Cloud-Dienst. Weil dieselbe FortiGate aber auch IPsec kann, lässt sich der Rest als gehärtetes VPN daneben betreiben, ohne zweite Appliance. Für den Übergang ist das praktisch, für die Architektur ein Kompromiss.
Wie gut fließen Identität, Gerätezustand und laufende Bewertung in die Entscheidung ein?
MFA ist über RADIUS oder SAML nachrüstbar und nach § 30 Abs. 2 Nr. 10 BSIG ohnehin Pflicht. Der Gerätezustand wird höchstens beim Verbindungsaufbau geprüft, und einmal verbunden bleibt die Sitzung bestehen, bis sie abläuft. Eine Änderung des Risikos erreicht den Tunnel nicht.
Identität, Gerätekonformität und Risikosignale entscheiden bei jeder Anfrage. Bei Entra Private Access greifen Conditional-Access-Richtlinien je Anwendung, und über Continuous Access Evaluation wirkt ein Widerruf der Sitzung nahezu in Echtzeit. Das ist die laufende Bewertung, die das BSI-Positionspapier beschreibt.
Geräte-Tags des Endpoint-Agenten zu Patchstand, Virenschutz und Verschlüsselung fließen in die Proxy-Regel ein und werden fortlaufend aktualisiert. Die Identität kommt über SAML aus dem Verzeichnis. Was fehlt, ist die Kopplung an die Risikosignale des Identitätsanbieters.
Welchen Nachweis liefern die Protokolle?
Das Protokoll zeigt, wer wann einen Tunnel aufgebaut hat und welche Adresse er bekam. Was danach im Netz passierte, steht in Firewall- und Serverprotokollen, die jemand zusammenführen muss. Die Frage, wer auf welche Anwendung zugegriffen hat, kostet einen Nachmittag im SIEM.
Jeder Zugriff ist ein Ereignis mit Nutzer, Gerät, Anwendung, Richtlinie und Entscheidung. Wer wann auf das ERP zugegriffen hat, ist eine Abfrage statt einer Korrelation. Für Nachweise nach § 30 Abs. 1 BSIG oder gegenüber einem Auditor ist das der kürzeste Weg.
Die Firewall protokolliert je Proxy-Regel mit Nutzer und Geräte-Tag, und die Protokolle liegen im eigenen Haus. Der Nachweis ist ähnlich gut wie beim Cloud-Dienst, solange die Protokolle zentral gesammelt und nicht nach Tagen auf dem Gerät überschrieben werden.
Was kostet der Weg an Lizenzen, Betrieb und Abhängigkeit?
Die Appliance ist bezahlt und die Lizenz je Nutzer oft inklusive. Dagegen stehen Patch-Wochenenden, der Austausch beim Herstellerwechsel und erzwungene Migrationen wie die von SSL-VPN auf IPsec mit FortiOS 7.6.3. Die Abhängigkeit vom Hersteller ist genauso da, nur weniger sichtbar.
Es fällt ein Preis je Nutzer und Monat an, bei Entra Private Access zusätzlich zur vorausgesetzten P1- oder P2-Lizenz, und der Dienst wird zur Voraussetzung für jeden internen Zugriff. Ein Anbieterwechsel heißt, alle Anwendungsdefinitionen und Richtlinien neu zu bauen.
Die Funktion ist in der Firewall-Lizenz enthalten, der Endpoint-Agent und seine Verwaltung kommen dazu. Die Abhängigkeit richtet sich auf einen Hersteller für Firewall, Agent und Verwaltung zugleich. Für Häuser, die diese Plattform ohnehin betreiben, ist das der günstigste Einstieg, für alle anderen ein Plattformwechsel.
Was passt wann
- Wenn Beschäftigte und Dienstleister vor allem Web- und TCP-Anwendungen brauchen
- gehört dieser Zugriff auf einen ZTNA-Dienst, und das VPN wird für diese Gruppe abgeschaltet statt daneben weiterbetrieben.
- Wenn Standorte gekoppelt werden, Produktionsanlagen gewartet werden oder Protokolle ein Netz voraussetzen
- bleibt die VPN-Appliance, aber mit IPsec und Zertifikaten statt SSL-Portal, mit MFA, ohne Verwaltungsoberfläche am Internet und mit einer Patchfrist in Stunden.
- Wenn ihr FortiGate oder eine vergleichbare Plattform mit Endpoint-Agent schon betreibt
- ist ZTNA auf der eigenen Firewall der Zwischenschritt mit dem geringsten Umbau, der die Freigabe je Anwendung einführt, ohne einen neuen Anbieter ins Haus zu holen.
- Wenn niemand sagen kann, welche Anwendungen heute durch den Tunnel laufen
- ist jede Produktentscheidung verfrüht; die Inventur aus den Firewall-Protokollen kommt zuerst.
03 Was du mitnimmst
Wie du die Entscheidung triffst, ohne sie zu bereuen
Sechs Festlegungen stehen vor jeder Produktauswahl. Wer sie überspringt, kauft ein ZTNA-Abonnement und betreibt zwei Jahre später das alte VPN daneben, nur ohne Plan.
Was Zero Trust Network Access anders macht
- 01 Nutzer und Gerät prüfen
- 02 Richtlinie je Anwendung
- 03 Kein offener Port
- 04 Sitzung laufend bewerten
- 05 Jeden Zugriff protokollieren
Erst zählen, was durch den Tunnel geht
Zieh für vier Wochen die Firewall- oder NetFlow-Protokolle des VPN-Segments und sortiere nach Zielsystem und Protokoll. Das Ergebnis ist fast immer dasselbe: wenige Webanwendungen, RDP und SSH auf Verwaltungsserver, SMB auf Dateiserver, ein Drucker, ein ERP-Client mit eigenem Protokoll. Diese Liste entscheidet, was auf ZTNA wechseln kann und was im VPN bleibt.
Identität vor Netz: MFA und Gerätezustand zuerst
Beide Wege stehen und fallen mit der Identität. Vor jedem Umbau gehören Phishing-resistente MFA für alle Fernzugriffe, eine Regel für den Gerätezustand und ein Verzeichnis als Quelle der Wahrheit. Microsoft Entra Private Access setzt Conditional Access voraus; ein VPN mit SAML-Anbindung kann dieselbe Richtlinie nutzen. Wer Identität zuerst ordnet, kann den Netzweg später tauschen, ohne die Regeln neu zu schreiben.
Keine Verwaltungsoberfläche am Internet
Die ausgenutzten Schwachstellen der letzten zwei Jahre saßen überwiegend in Webportalen und Verwaltungsdiensten am WAN-Interface. Egal, welcher Weg bleibt: Verwaltungszugänge gehören hinter ein getrenntes Management-Netz, SSL-VPN-Webportale werden abgeschaltet oder durch IPsec mit Zertifikaten ersetzt, und ein Patch für das Gerät am Netzrand hat eine Frist von Stunden. Das gilt für VPN und für eine Firewall mit ZTNA-Proxy gleich.
Zugriff je Anwendung als Zielbild festschreiben
Das BSI-Positionspapier zu Zero Trust vom Juli 2023 und NIST SP 800-207 beschreiben dasselbe Ziel: kein implizites Vertrauen, minimale Rechte, und über jede Anfrage wird anhand von Identität, Gerät und Kontext entschieden. Übersetzt heißt das: Eine Buchhalterin bekommt Zugriff auf das ERP und das Intranet, nicht auf das Subnetz, in dem beides steht. Schreib dieses Zielbild fest, auch für den Teil, der vorerst im VPN bleibt.
Den Ausfall des Brokers einplanen
Ein ZTNA-Dienst ist ein Cloud-Dienst. Fällt der Broker des Anbieters aus, erreicht niemand mehr interne Anwendungen, auch die Admins nicht. Plane einen zweiten Weg für wenige Personen, etwa ein gehärtetes IPsec-VPN mit Zertifikat und Hardware-Token, das im Normalbetrieb gesperrt ist. Prüfe außerdem, über welche Rechenzentren der Anbieter euren Verkehr leitet und ob das zu euren Anforderungen an Datenstandort und Vertraulichkeit passt.
Die Kosten über drei Jahre rechnen, nicht über die Lizenz
Ein ZTNA-Dienst kostet je Nutzer und Monat; Microsoft Entra Private Access setzt eine Entra-ID-P1- oder P2-Lizenz voraus und kommt als eigener Plan oder in der Microsoft Entra Suite dazu. Dagegen stehen beim VPN die Appliance, der Support, Patch-Wochenenden, Ausfallzeit beim Zwangsupgrade und das Risiko, das im Vorfall Geld kostet. Stell beide Rechnungen über drei Jahre nebeneinander, mit dem Personalaufwand als größtem Posten.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Warum die VPN-Appliance zum bevorzugten Ziel geworden ist
Ein Remote-Access-VPN muss aus dem Internet erreichbar sein. Diese Erreichbarkeit betrifft nicht nur den Tunnelendpunkt, sondern bei SSL-VPN-Lösungen auch ein Webportal mit Anmeldemaske, Client-Download und oft Resten einer Verwaltungsoberfläche. Jeder dieser Dienste ist Code, der ungeprüfte Eingaben aus dem Internet verarbeitet, und genau dort saßen die Schwachstellen. CVE-2024-3400 traf das GlobalProtect-Portal von Palo Alto, CVE-2024-55591 die Verwaltungsoberfläche von FortiOS, CVE-2025-22457 Ivanti Connect Secure und CVE-2025-20333 den VPN-Webserver von Cisco ASA und FTD. Dass alle vier im CISA-Katalog ausgenutzter Schwachstellen stehen, heißt: Diese Lücken wurden in echten Netzen genutzt, teils bevor ein Patch existierte.
Für den Betrieb folgt daraus eine unbequeme Regel: Ein Gerät am Netzrand wird am Tag des Herstellerhinweises gepatcht, und nach jedem Hinweis prüft jemand, ob die Lücke schon vorher ausgenutzt wurde. Fortinet hat für den SSL-VPN-Tunnelmodus die Konsequenz selbst gezogen. Seit FortiOS 7.6.3 ist er auf allen FortiGate-Modellen in GUI und CLI nicht mehr verfügbar, und die Einstellungen werden beim Upgrade nicht übernommen. Fortinet verlangt deshalb, die Konfiguration vor dem Upgrade auf IPsec zu migrieren.
Was Zero Trust Network Access konkret anders macht
NIST SP 800-207 beschreibt Zero Trust als Architektur, in der ein Richtlinienpunkt jede Zugriffsentscheidung anhand von Identität, Gerät und Kontext trifft und ein Durchsetzungspunkt zwischen Nutzer und Ressource sie umsetzt. Das BSI-Positionspapier vom Juli 2023 fasst die Grundsätze in drei Sätzen: Es wird von einem erfolgreichen Einbruch ausgegangen, es gibt kein implizites Vertrauen, und Rechte werden minimal vergeben. ZTNA ist die Umsetzung dieser Grundsätze für den Fernzugriff.
Im eigenen Netz läuft ein Connector, der nur ausgehende Verbindungen zu einem Broker aufbaut. Auf dem Client fängt ein Agent Anfragen an definierte Anwendungen ab und leitet sie über den Broker, der den Identitätsanbieter fragt und die Richtlinie anwendet. Bei Microsoft Entra Private Access, das mit Entra Internet Access unter dem Namen Global Secure Access läuft, ist dieser Richtlinienpunkt Conditional Access. Was ZTNA nicht ist: ein Ersatz für Segmentierung im Netz, für Berechtigungen in der Anwendung oder für das Patchen der Server dahinter. Es ordnet den Zugang, nicht die Ziele.
Wo das VPN bleibt und wie es dann aussieht
Standortkopplung über Site-to-Site-IPsec ist kein Fernzugriff und bleibt, was sie ist. Produktionsnetze mit Anlagen, deren Hersteller zur Fernwartung einen Netzzugang verlangt, bleiben vorerst am VPN. Protokolle, bei denen der Server die Verbindung zum Client öffnet, Broadcasts im Subnetz voraussetzen oder feste Client-Adressen brauchen, laufen über ZTNA-Dienste nur mit Aufwand oder gar nicht. Und für den Fall, dass der Broker ausfällt, braucht eine kleine Gruppe von Admins einen Weg ins Netz, der nicht vom Broker abhängt.
Für diesen Rest gilt ein anderer Betriebsstandard als für das VPN von 2019. Dazu gehören IPsec mit Zertifikaten statt SSL-Portal mit Passwort, MFA nach § 30 Abs. 2 Nr. 10 BSIG, eine Verwaltungsoberfläche ausschließlich aus dem Management-Netz, ein eigenes Segment je Nutzergruppe hinter dem Tunnel, Protokolle ins SIEM und eine Patchfrist in Stunden. Ein so betriebenes VPN ist kein Rückschritt, sondern der Teil der Architektur, der ehrlich benennt, was noch ein Netz braucht.
Der Übergang in vier Etappen
Die erste Etappe ist die Inventur: vier Wochen Firewall- oder NetFlow-Protokolle des VPN-Segments, sortiert nach Ziel und Protokoll, mit einem Namen je Anwendung und einem Verantwortlichen. Die zweite Etappe ordnet die Identität: MFA für alle Fernzugriffe, Gerätezustand als Bedingung, Gruppen im Verzeichnis, die Anwendungen statt Netzen entsprechen.
Die dritte Etappe verlagert Webanwendungen und gängige TCP-Anwendungen auf den ZTNA-Dienst, Gruppe für Gruppe, mit einer Woche Parallelbetrieb und einer klaren Regel, wann das VPN für diese Gruppe abgeschaltet wird. Die vierte Etappe schrumpft das VPN auf den Rest, härtet es nach dem beschriebenen Standard und dokumentiert für jede verbleibende Anwendung, warum sie ein Netz braucht und wann das überprüft wird. Wer die vierte Etappe auslässt, betreibt zwei Systeme ohne Grenze dazwischen, und das ist schlechter als jedes der beiden allein.
Dazu passende Kurse
Wenn der Übergang bei euch beide Welten für längere Zeit nebeneinander bedeutet, findest du bei cmt Firewall- und Fernzugriffskurse für Admins, die VPN und ZTNA parallel betreiben.
Für Teams, die die laufende Bewertung von Sitzungen und Risikosignalen vertiefen wollen, gibt es Zero-Trust-Architektur mit KI-gestützter Bewertung von Zugriffen als eigenen Schwerpunkt.
Wer vor dem Update auf FortiOS 7.6.3 steht und den Tunnelmodus ablösen muss, findet bei cmt FortiGate-Kurse für den Umstieg von SSL-VPN auf IPsec und Universal ZTNA, die das Vorgehen an der eigenen Konfiguration zeigen.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
04 Konkrete Kurse
Wo du genau das übst
- FortiOS Administrator
- Workshop zu Check Point Remote Access
- CompTIA CloudNetX: CNX-001-Training mit Labs
- pfSense Grundkurs: Firewall, VPN, Routing
Weitere Kurse aus diesem Bereich
Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle IT-Security-Schulungen mit Terminen.
Stimmen aus den Kursen
Was Teilnehmende über die Kurse in diesem Bereich sagen
Sehr guter Dozent, spannend erklärt und mit vielen Praxisbeispielen!
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Super Dozent mit vielen Praxisbeispielen so dass ich mich gleich für den folge Kurs interessiere.
05 Fragen
Häufige Fragen
Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.
Ist ZTNA nicht einfach ein VPN in der Cloud?
Reicht MFA auf dem bestehenden VPN, um die NIS2-Anforderungen zu erfüllen?
Was passiert mit unserem FortiGate-SSL-VPN beim Update auf FortiOS 7.6.3?
Brauchen wir für Microsoft Entra Private Access zusätzliche Lizenzen?
Funktionieren RDP, SMB und Netzwerkdrucker über einen ZTNA-Dienst?
Was passiert, wenn der ZTNA-Anbieter ausfällt?
Passt thematisch dazu
Wer den Begriff zuerst ohne Produktbezug verstehen will, findet im Glossar die Definition von Zero Trust als Sicherheitsmodell, bevor es hier um Fernzugriff geht.
Für den Teil des Fernzugriffs, der im VPN bleibt, lohnt der Blick darauf, wie Netzwerksegmentierung die Reichweite eines Tunnels begrenzt, denn sie ist die Maßnahme, die den Schaden eines kompromittierten Kontos klein hält.
Entra Private Access folgt denselben Richtlinien wie der Zugriff auf Cloud-Anwendungen; der Microsoft-365-Bereich zeigt Schritt für Schritt, wie sich Conditional Access in Microsoft 365 sicher einrichten lässt.
Quellen
- Fortinet Docs, SSL VPN tunnel mode no longer supported in FortiOS 7.6.3
- Microsoft Learn, What is Global Secure Access? (Microsoft Entra Private Access und Internet Access, Lizenzvoraussetzungen)
- BSI, Positionspapier Zero Trust (Juli 2023)
- NIST, SP 800-207 Zero Trust Architecture
- CISA, Known Exploited Vulnerabilities Catalog (CVE-2024-3400, CVE-2024-55591, CVE-2025-22457, CVE-2025-20333)
- gesetze-im-internet.de, § 30 BSIG Risikomanagementmaßnahmen (Nr. 9 Zugriffskontrolle, Nr. 10 Multi-Faktor-Authentifizierung)
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Security-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Beide Wege an echten Geräten betreiben, nicht nur vergleichen
In den Firewall- und Fernzugriffskursen bei cmt baust du IPsec-Tunnel, Zugriffsregeln je Anwendung und die Anbindung an das Verzeichnis an eigenen Geräten auf, mit Trainern, die Migrationen von SSL-VPN auf IPsec und auf ZTNA selbst durchgeführt haben.
Verwandte Themen
- pfSense oder OPNsense: welche Open-Source-Firewall in den Betrieb passt
- Phishing-resistente MFA: wie die Faktoren funktionieren und welche standhalten
- Privileged Identity Management in Entra ID einrichten: Adminrechte nur auf Zeit
- Post-Quanten-Kryptografie: wer die Umstellung bis 2030 verantwortet und wo sie beginnt