Zum Hauptinhalt springen

VPN zu ZTNA migrieren: Ein praxisorientierter, schrittweiser Leitfaden

Der Wechsel von klassischer Remote-VPN-Konnektivität zu Zero Trust Network Access (ZTNA) erfordert keine disruptive Komplettumstellung auf einmal.

Ein sichererer Ansatz ist eine kontrollierte Migration in Etappen: zunächst verstehen, welche Aufgaben das VPN heute erfüllt, dann Zugriffswege identifizieren, die von ressourcenbezogener Autorisierung profitieren, ZTNA parallel zum bestehenden VPN einführen, den Betrieb validieren und anschließend den VPN-Umfang schrittweise reduzieren.

Das Ziel ist nicht, VPN-Technologie um ihrer selbst willen abzuschaffen. Ziel ist es, unnötig breiten Netzwerkzugriff durch expliziten Zugriff auf tatsächlich benötigte Ressourcen zu ersetzen.

ZTNA und VPN vergleichen · VPN-Ablösung mit ZTXGate

1. Definieren Sie, was tatsächlich migriert wird​

Trennen Sie zunächst das VPN-Produkt von den Zugriffsmustern, die es heute ermöglicht.

Dokumentieren Sie:

  • welche Benutzer und Teams sich remote verbinden
  • welche Anwendungen, Server und Subnetze sie erreichen
  • welche Protokolle benötigt werden
  • welche Benutzer dauerhaften und welche temporären Zugriff haben
  • wie Identitäten geprüft werden
  • ob der Gerätezustand berücksichtigt wird
  • welche Firewall- oder Segmentierungsregeln den VPN-Zugriff einschränken
  • welche Betriebsabläufe vom VPN abhängen

Diese Bestandsaufnahme macht eine wichtige Unterscheidung sichtbar: Manche Verbindungen existieren nur, weil Benutzer eine bestimmte Anwendung benötigen; andere benötigen tatsächlich breitere Netzwerkkonnektivität.

Beide Fälle sollten nicht automatisch denselben Migrationspfad erhalten.

2. Entscheiden Sie, was zu ZTNA wechseln sollte – und was nicht​

ZTNA eignet sich besonders, wenn Zugriff als Beziehung zwischen einer bekannten Identität, einem bekannten Gerät und einer definierten Ressource beschrieben werden kann.

Typische Kandidaten sind:

  • Mitarbeiter mit Zugriff auf private Geschäftsanwendungen
  • Entwickler mit Zugriff auf bestimmte Entwicklungssysteme
  • Administratoren mit Zugriff auf definierte Verwaltungsdienste
  • Auftragnehmer mit begrenztem oder zeitlich befristetem Zugriff
  • Benutzer, die eine einzelne Anwendung erreichen sollen, ohne allgemeinen Subnetzzugriff zu erhalten

Einige VPN-Anwendungsfälle können weiterhin sinnvoll sein, darunter:

  • Site-to-Site-Konnektivität
  • Infrastrukturnetzwerke
  • Workflows, die bewusst umfassende Protokoll- oder Subnetzreichweite benötigen
  • Legacy-Umgebungen, die noch nicht sauber als einzelne Ressourcen modelliert werden können

Eine erfolgreiche Migration muss nicht jeden Netzwerkzugriff in ZTNA überführen.

3. Wählen Sie eine kleine erste Migrationswelle​

Beginnen Sie nicht mit der komplexesten oder geschäftskritischsten Umgebung.

Wählen Sie einen Pilotbereich, in dem:

  • Benutzer klar identifizierbar sind
  • benötigte Ressourcen gut verstanden werden
  • die Zugriffsrichtlinien überschaubar sind
  • das Team verwertbares Feedback geben kann
  • das bestehende VPN während der Evaluierung als kontrollierter Fallback verfügbar bleiben kann

Ein Entwicklungsteam mit wenigen internen Entwicklungsdiensten lässt sich zum Beispiel meist einfacher evaluieren als ein Betriebsteam, das zahlreiche Produktionsnetze verwaltet.

Die erste Welle soll das Zugriffsmodell und den Betriebsprozess beweisen, nicht die gesamte Unternehmensarchitektur.

4. Identität und Gerätevertrauen etablieren​

Klassische VPN-Bereitstellungen authentifizieren häufig einen Benutzer, bevor ein Tunnel aufgebaut wird. ZTNA bringt Identitäts- und Gerätekontext näher an die Autorisierungsentscheidung für jede geschützte Ressource.

Klären Sie vor der Migration:

  • wie Benutzer sich authentifizieren
  • wie Benutzer und Gruppen bereitgestellt werden
  • wie Geräte registriert und identifiziert werden
  • welche Device-Posture-Signale erforderlich sind
  • ob sensible Ressourcen zusätzliche Authentifizierung verlangen
  • wie deaktivierte Benutzer oder widerrufene Geräte Zugriff verlieren

Bei ZTXGate können Identitäten über OIDC und SCIM integriert werden; registrierte Geräte und unterstützte Posture-Integrationen können in Richtlinienentscheidungen einfließen.

Identität und Gerätevertrauen entdecken

5. Ressourcen statt Subnetze modellieren​

Eine VPN-Richtlinie beginnt häufig mit Netzwerkobjekten: Routen, Subnetzen, Ports, Firewall-Zonen und ACLs.

Eine ZTNA-Migration sollte mit der geschützten Ressource beginnen.

Statt zu fragen:

Mit welchem Netzwerk darf sich dieser Benutzer verbinden?

fragen Sie:

Welche Ressource darf dieser Benutzer von welchem Gerät und unter welchen Bedingungen erreichen?

Sinnvolle Ressourcengruppen können Geschäfts- oder Betriebsgrenzen folgen, zum Beispiel:

  • Entwicklungsanwendungen
  • Finanzsysteme
  • Verwaltungsdienste
  • Produktions-Management-Schnittstellen
  • für Auftragnehmer freigegebene Ressourcen

Halten Sie die ersten Richtlinien einfach. Übermäßig komplexe Regeln sind schwer zu prüfen und erschweren die Fehlersuche während der Migration.

6. ZTNA und VPN parallel betreiben​

Eine schrittweise Umstellung ist in der Regel leichter zu betreiben als ein harter Cutover.

Während des Piloten:

  1. bestehendes VPN für genehmigte Fallback-Szenarien verfügbar halten
  2. ausgewählte Ressourcen auf den ZTNA-Pfad verschieben
  3. prüfen, ob Benutzer ihre normale Arbeit über das neue Zugriffsmodell erledigen können
  4. Autorisierung und Audit-Sichtbarkeit mit dem bisherigen Ablauf vergleichen
  5. Abhängigkeiten identifizieren, die in der Bestandsaufnahme fehlten

Der Parallelbetrieb schafft Zeit, verborgene Annahmen zu entdecken – etwa Anwendungen mit Sekundärdiensten, Administratoren mit zusätzlichem Protokollbedarf oder nicht dokumentierte Routenabhängigkeiten.

Fallback sollte jedoch kein Grund sein, beide Pfade dauerhaft offen zu lassen. Er sollte kontrolliert und mit wachsendem Vertrauen in den neuen Pfad reduziert werden.

7. Sicherheit und Betrieb validieren – nicht nur Konnektivität​

Eine Migration ist nicht abgeschlossen, nur weil ein Benutzer eine Anwendung öffnen kann.

Prüfen Sie den gesamten Lebenszyklus:

  • Bereitstellung neuer Benutzer
  • Geräteregistrierung
  • Zugriffsfreigabe
  • Ablauf temporärer Zugriffe
  • Benutzerentfernung
  • Gerätewiderruf
  • fehlgeschlagene Authentifizierung
  • Richtlinienablehnung
  • Audit-Protokolle
  • SIEM-Weiterleitung, falls erforderlich
  • Backup- und Wiederherstellungsverfahren

Testen Sie außerdem das Verhalten bei nicht verfügbaren Abhängigkeiten. Wenn Richtlinien beispielsweise externe Identity-, MDM-, EDR- oder MFA-Dienste nutzen, muss klar sein, was geschieht, wenn diese nicht erreichbar sind.

Das ist besonders für eingeschränkte oder getrennte Umgebungen wichtig.

8. In Wellen migrieren​

Sobald der Pilot stabil ist, wiederholen Sie den Prozess mit weiteren Ressourcengruppen.

Eine mögliche Reihenfolge:

  1. interne Anwendungen mit geringem Risiko
  2. Entwicklungs- und Engineering-Ressourcen
  3. Auftragnehmer- oder Partnerzugriff
  4. Verwaltungsdienste
  5. sensible Produktionsressourcen

Die konkrete Reihenfolge hängt von Ihrer Umgebung ab. Wichtig ist, dass jede Welle klein genug bleibt, damit Richtlinien, Abhängigkeiten und Rückfallpfad verständlich bleiben.

Prüfen Sie nach jeder Welle, ob alte VPN-Berechtigungen eingeschränkt werden können.

9. VPN-Umfang mit wachsender ZTNA-Abdeckung reduzieren​

Wenn ursprüngliche VPN-Berechtigungen nach der Migration unverändert bleiben, bleibt genau der breite Zugriffspfad erhalten, den Sie reduzieren wollten.

Sobald eine Migrationswelle stabil ist:

  • migrierte Benutzer aus unnötigen VPN-Gruppen entfernen
  • nicht mehr benötigte Routen entfernen
  • Firewall-Regeln des alten Zugriffspfads einschränken
  • Ausnahmen dokumentieren, die weiterhin VPN benötigen
  • auf unerwartete Abhängigkeiten von stillgelegten Zugriffspfaden achten

Der Endzustand kann eine vollständige Stilllegung des Remote-Access-VPN oder ein kleinerer VPN-Footprint für bestimmte Netzwerkfälle sein.

Beides kann sinnvoll sein.

10. Klare Abschlusskriterien definieren​

Bevor ein alter Zugriffspfad stillgelegt wird, sollten objektive Prüfungen feststehen.

Bestätigen Sie für jede migrierte Gruppe:

  • alle benötigten Ressourcen sind erfasst
  • Identität und Geräteregistrierung funktionieren zuverlässig
  • Zugriffsrichtlinien wurden validiert
  • temporärer und genehmigter Zugriff verhält sich wie erwartet
  • Monitoring- und Audit-Daten sind verfügbar
  • Support-Mitarbeiter kennen den neuen Ablauf
  • Wiederherstellungsverfahren sind dokumentiert
  • kein benötigter Workflow hängt noch von breitem VPN-Zugriff ab

So verhindern Sie, dass dauerhaft zwei parallele Zugriffssysteme bestehen bleiben.

Beispiel: Eine fokussierte Migration​

Angenommen, ein Entwicklungsteam nutzt derzeit ein VPN für mehrere interne Systeme.

Ausgangslage​

  • VPN bietet Konnektivität zu einem Entwicklungs-Subnetz
  • Firewall-Regeln begrenzen einige Ziele
  • Entwickler authentifizieren sich am VPN
  • Produktionsadministration ist nur einer kleineren privilegierten Gruppe zugänglich

Erste ZTNA-Welle​

Definieren Sie die tatsächlichen Ressourcen:

  • Quellcode-Dienst
  • Entwicklungs-Anwendungsserver
  • Build-System
  • interne Dokumentation

Dann Richtlinien wie:

  • Entwicklungsteam → Entwicklungsressourcen
  • nur registrierte Geräte
  • Produktionsadministration → separat autorisierte Administratoren
  • sensibler Produktionszugriff → zeitlich begrenzt oder genehmigungspflichtig mit stärkerer Verifikation

Das VPN kann vorübergehend für noch nicht migrierte Abhängigkeiten bestehen bleiben. Sobald diese verstanden und überführt sind, kann sein Umfang reduziert werden.

Wo ZTXGate einzuordnen ist​

ZTXGate ist auf expliziten Ressourcenzugriff statt breiter Netzwerkzulassung ausgelegt.

Für eine schrittweise VPN-Migration kann es kombinieren:

  • Benutzer- und Geräteidentität
  • OIDC- und SCIM-Integration
  • Geräteregistrierung und unterstützte Posture-Signale
  • Ressourcenrichtlinien
  • temporären sowie Request-and-Approve-Zugriff
  • Step-Up-Authentifizierung für sensible Ressourcen
  • WireGuard-basierten verwalteten Zugriff
  • lizenzierten clientlosen HTTP/HTTPS-Zugriff für geeignete browserbasierte Anwendungen
  • zentrale Audit-Daten und SIEM-Weiterleitung
  • kunden- oder MSP-betriebene Bereitstellung ohne verpflichtende CoreZT-gehostete Cloud-Control-Plane

ZTXGate kann daher parallel zu einem bestehenden VPN eingeführt und Ressource für Ressource erweitert werden, ohne einen sofortigen netzwerkweiten Austausch zu erzwingen.

ZTXGate entdecken · ZTNA-Architektur entdecken

Migrations-Checkliste​

Vor der nächsten Welle sollten Sie fragen:

  • Haben wir Benutzer und Ressourcen hinter dem aktuellen VPN inventarisiert?
  • Welche Fälle benötigen wirklich weiterhin breite Netzwerkkonnektivität?
  • Sind Identitäts- und Geräte-Lifecycle-Prozesse bereit?
  • Sind Ressourcenrichtlinien einfach genug zur Prüfung?
  • Können neuer und alter Pfad während der Validierung parallel laufen?
  • Haben wir Onboarding, Widerruf, temporären Zugriff, Logging und Wiederherstellung getestet?
  • Können wir den alten VPN-Pfad nach dieser Welle einschränken?
  • Verstehen Support- und Betriebsteams den neuen Ablauf?

Eine VPN-zu-ZTNA-Migration ist am besten beherrschbar, wenn jede Etappe gleichzeitig Unsicherheit und Zugriffsbreite reduziert.

VPN-Ablösung · ZTNA vs VPN · So funktioniert ZTNA · Self-Hosted vs Cloud-ZTNA

Verwandte Leitfäden und nächste Schritte​