Ein einziges kompromittiertes Notebook im VPN-Tunnel reicht, damit ein Angreifer sich seitlich durch ganze Netzwerksegmente bewegt — laterale Bewegung gehört zu den am häufigsten dokumentierten Angriffstechniken (MITRE ATT&CK). Mit wachsendem Homeoffice und mehr Cloud-Diensten wird das klassische VPN zur Last: Gateways werden zum Flaschenhals, der Durchsatz bricht ein, und die Angriffsfläche wächst mit jedem Tunnel. Eine VPN ZTNA Migration ersetzt den Pauschalzugang durch granulare, identitätsbasierte Verbindungen zu einzelnen Anwendungen.
Kurz erklärt: Die Migration läuft in sechs Phasen: Anwendungen inventarisieren, Identitäts- und Geräteprüfung einrichten, einen ZTNA-Connector (Software-Brücke im Netz) neben dem VPN betreiben, erste Nutzergruppen umziehen, Zugriffsrichtlinien verfeinern und zuletzt das VPN abschalten. Der Parallelbetrieb beider Systeme verhindert Ausfälle.
Dieser Leitfaden zeigt jeden Schritt im Detail. Wer den Einstieg plant, findet passende ZTNA- und VPN-Lösungen in der Kategorie Network Security oder grenzt die Optionen direkt im Produktberater ein.
Warum das VPN im Mittelstand an Grenzen stößt
Ein VPN baut einen verschlüsselten Tunnel zwischen Gerät und Firmennetz auf. Das Problem liegt im Modell dahinter: Wer einmal im Tunnel ist, gilt als vertrauenswürdig und sieht je nach Konfiguration große Teile des internen Netzes. Diese implizite Vertrauensstellung ist die Schwachstelle, die Ransomware-Gruppen für laterale Bewegung ausnutzen.
Dazu kommt die Skalierung. Jeder Tunnel läuft über ein zentrales Gateway. Bei 80 gleichzeitigen Homeoffice-Verbindungen wird die Appliance zum Engpass, und der Zugriff auf Cloud-Anwendungen nimmt unnötige Umwege über das Rechenzentrum. Zero Trust Network Access dreht das Prinzip um: Statt Netzzugang gibt es Anwendungszugang. Jede Anfrage wird einzeln gegen Identität, Gerätestatus und Richtlinie geprüft — niemand erhält mehr Reichweite als nötig. Was ZTNA grundsätzlich vom VPN unterscheidet, vertieft unser Überblick ZTNA als VPN-Alternative. Diese „never trust, always verify“-Logik beschreibt das NIST in der Zero-Trust-Architektur SP 800-207 als Referenzmodell.
VPN vs. ZTNA: der Unterschied auf einen Blick
Die folgende Tabelle stellt beide Ansätze für die Kernkriterien gegenüber, die im Mittelstand über die Entscheidung bestimmen.
| Kriterium | Klassisches VPN | ZTNA |
|---|---|---|
| Zugriffsmodell | Netzwerk-Ebene (Subnetz) | Anwendungs-Ebene (einzelne App) |
| Vertrauensannahme | Implizit nach Login | Pro Anfrage neu geprüft |
| Laterale Bewegung | Möglich innerhalb des Segments | Standardmäßig unterbunden |
| Sichtbarkeit der Infrastruktur | Interne IP-Bereiche sichtbar | Anwendungen bleiben verborgen |
| Geräteprüfung | Optional, oft nur Zertifikat | Kontinuierlich (Patch-Stand, EDR) |
| Skalierung | Gateway als Flaschenhals | Cloud-vermittelt, lastunabhängig |
Wichtig: ZTNA ersetzt nicht zwingend jede VPN-Funktion an Tag eins. Site-to-Site-Verbindungen zwischen Standorten bleiben oft bestehen, während der Nutzer-Fernzugriff zuerst migriert wird.
VPN-ZTNA-Migration: Wie läuft die Umstellung in 6 Schritten ab?
Die Umstellung gelingt im Parallelbetrieb: ZTNA-Connector und VPN laufen eine Zeit lang gemeinsam, Nutzergruppen ziehen schrittweise um, und erst wenn alle Anwendungen erreichbar sind, wird das VPN deaktiviert. Dieser Ansatz hält das Risiko niedrig und erlaubt jederzeit ein Zurückrollen einzelner Gruppen ohne Komplettausfall.
Die sechs Schritte im Detail
- Anwendungen inventarisieren. Erfassen Sie jede Ressource, auf die heute per VPN zugegriffen wird: Fileserver, ERP, interne Web-Apps, Remote-Desktop-Hosts. Notieren Sie Protokoll, Port und die berechtigten Nutzergruppen. Diese Liste ist die Grundlage jeder späteren Richtlinie.
- Identität und Gerätestatus anbinden. ZTNA prüft bei jeder Verbindung, wer zugreift und von welchem Gerät. Verbinden Sie den ZTNA-Dienst mit Ihrem Identity Provider (dem zentralen Login-Dienst, etwa Microsoft Entra ID) und definieren Sie Mindestkriterien wie aktive Festplattenverschlüsselung oder einen laufenden EDR-Agenten (Endpoint Detection and Response, die kontinuierliche Endpunktüberwachung).
- ZTNA-Connector neben dem VPN ausrollen. Installieren Sie den Connector in jedem Netz, das Anwendungen bereitstellt. Er baut eine ausgehende Verbindung zum ZTNA-Broker auf, sodass keine eingehenden Ports geöffnet werden müssen. Das VPN bleibt in dieser Phase voll funktionsfähig.
- Erste Nutzergruppe umziehen. Wählen Sie eine kleine, technisch sichere Pilotgruppe — oft die IT selbst. Veröffentlichen Sie zwei bis drei unkritische Anwendungen über ZTNA und lassen Sie die Gruppe eine Woche parallel testen. Sammeln Sie Feedback zu Latenz und Bedienung.
- Richtlinien verfeinern und ausweiten. Übertragen Sie die Erkenntnisse auf den Regelsatz: Wer darf welche App, unter welchen Gerätebedingungen, zu welchen Zeiten? Rollen Sie die Anwendungen gruppenweise aus, bis alle VPN-Nutzer über ZTNA arbeiten.
- VPN abschalten. Erst wenn jede Anwendung über ZTNA erreichbar ist und die Tunnel-Statistik keine aktiven Sitzungen mehr zeigt, deaktivieren Sie den Fernzugriffs-VPN. Behalten Sie reine Standort-Tunnel bei, falls sie weiterhin gebraucht werden.
Eine Lösung wie Sophos ZTNA lässt sich über dieselbe Konsole wie die Firewall verwalten, was den Parallelbetrieb für kleinere IT-Teams vereinfacht. Einen Überblick über alle Zero-Trust-Optionen bietet die Kategorie VPN und ZTNA.
Häufige Stolperfallen bei der VPN-ZTNA-Migration
Drei Fehler tauchen in Migrationsprojekten immer wieder auf:
- Big-Bang statt Parallelbetrieb. Das VPN am Wochenende komplett abzuschalten und montags auf ZTNA zu hoffen, endet selten gut. Jede vergessene Anwendung wird zum Totalausfall für die betroffene Abteilung.
- Richtlinien zu grob fassen. Wer pauschal „alle dürfen alles“ einstellt, baut das alte VPN-Modell unter neuem Namen nach. Der Sicherheitsgewinn entsteht erst durch anwendungsgenaue Regeln.
- Geräteprüfung weglassen. ZTNA ohne Gerätestatus prüft nur die Identität — ein gestohlenes Passwort reicht dann weiterhin. Die kontinuierliche Prüfung von Patch-Stand und Endpunktschutz ist der eigentliche Hebel.
Wer parallel die Endpunktabsicherung modernisiert, sollte die Managed Services prüfen, um Geräteprüfung und Monitoring aus einer Hand abzudecken.
Was die Migration für Compliance und NIS2 bedeutet
Zero Trust ist kein gesetzlicher Zwang, deckt sich aber mit den Anforderungen vieler Rahmenwerke an Zugriffskontrolle und Segmentierung. Die granulare Protokollierung jeder Anwendungssitzung erleichtert Nachweise gegenüber Prüfern. Jeder Zugriff lässt sich lückenlos einer einzelnen Identität zuordnen. Wer ohnehin an seiner Sicherheitsstrategie arbeitet, findet in der NIS2-Checkliste für KMU eine strukturierte Übersicht der relevanten Maßnahmen. Eine pauschale Konformitätszusage ersetzt das nicht — die konkrete Bewertung bleibt Aufgabe der internen Compliance.
FAQ
Kann ich VPN und ZTNA gleichzeitig betreiben?
Ja, der Parallelbetrieb ist sogar der empfohlene Migrationsweg. ZTNA-Connector und VPN-Gateway stören sich nicht. Nutzergruppen ziehen schrittweise um, und das VPN wird erst abgeschaltet, wenn alle Anwendungen über ZTNA erreichbar sind.
Brauche ich für ZTNA neue Hardware?
In der Regel nicht. Moderne ZTNA-Dienste arbeiten cloud-vermittelt; der Connector läuft als Software auf einem vorhandenen Server oder einer virtuellen Maschine. Bei integrierten Lösungen übernimmt eine bestehende Firewall die Vermittlung.
Wie lange dauert eine VPN-ZTNA-Migration?
Für ein KMU mit 50 bis 100 Anwendern sind je nach Anzahl der Anwendungen vier bis acht Wochen realistisch — inklusive Pilotphase und schrittweisem Rollout. Der größte Zeitfaktor ist die saubere Inventarisierung der Anwendungen in Schritt eins.
Ersetzt ZTNA auch Site-to-Site-VPNs zwischen Standorten?
Nicht zwingend. ZTNA adressiert primär den Nutzer-Fernzugriff. Feste Verbindungen zwischen Niederlassungen können als Site-to-Site-Tunnel bestehen bleiben, während der mobile Zugriff auf ZTNA umzieht.
Was passiert, wenn der Identity Provider ausfällt?
Da jede Anfrage gegen die Identität geprüft wird, ist der Identity Provider kritisch. Planen Sie Hochverfügbarkeit ein und definieren Sie ein Notfallverfahren. Cloud-basierte Identitätsdienste bringen entsprechende Redundanz meist bereits mit.
Fazit
Die Umstellung von VPN auf ZTNA ist weniger ein Technologie- als ein Strukturprojekt: Der Parallelbetrieb nimmt das Risiko, die anwendungsgenauen Richtlinien bringen den Sicherheitsgewinn. Wer mit einer kleinen Pilotgruppe startet und das VPN erst am Ende abschaltet, migriert ohne Ausfall. Unsicher, welche ZTNA-Lösung zu Ihrer bestehenden Infrastruktur passt? Der Produktberater grenzt anhand weniger Angaben die passenden Optionen ein.
Sophos im Cyber Shop konfigurieren
Endpoint, Firewall, MDR, XDR — alle Lizenzen mit DACH-Mittelstand-Staffelpreisen.
