Was unterscheidet ZTNA von einem klassischen VPN?
Ein klassisches Remote-Access-VPN erweitert den Netzwerkzugang bis zum Endgerät. ZTNA bewertet den Zugriff auf eine konkrete Ressource anhand von Identität, Gerätekontext und Policy. Dadurch kann die erreichbare Angriffsfläche kleiner werden. ZTNA ist aber kein automatischer Komplett-Ersatz für jedes VPN und muss an Anwendungen und Betriebsabläufe angepasst werden.
Das konkrete Problem: Nach der Anmeldung ist zu viel Netzwerk sichtbar
In vielen Umgebungen authentifiziert ein VPN den Benutzer am Gateway und weist anschließend eine interne Adresse sowie Netzwerk-Routen zu. Welche Anwendungen tatsächlich benötigt werden, wird häufig erst durch nachgelagerte Firewall-Regeln begrenzt. Über Jahre entstehen dadurch breite Zugriffsgruppen, schwer verständliche Routing-Abhängigkeiten und ein großer Prüfaufwand bei Änderungen.
Das wird besonders sichtbar bei externen Dienstleistern, administrativen Zugängen, übernommenen Unternehmensbereichen und Anwendungen in mehreren Clouds. Ein einzelner Zugangspfad muss dann Identität, Endgerät, Netzwerk, DNS, Firewall, Applikation und Supportprozess gleichzeitig beherrschen.
Ein externer Dienstleister benötigt Zugriff auf zwei interne Webanwendungen. Das vorhandene VPN stellt jedoch eine Verbindung in ein größeres Netzsegment her. Zusätzliche Firewalls begrenzen den Zugriff, doch Verantwortlichkeiten und Fehleranalyse verteilen sich auf mehrere Teams. ZTNA kann den Zugriff direkt an den beiden Anwendungen ausrichten – wenn Identität, Applikationssegmentierung und Connector-Pfad sauber vorbereitet sind.
ZTNA und VPN im technischen Vergleich
| Entscheidungsfeld | Klassisches VPN | ZTNA |
|---|---|---|
| Ziel des Zugriffs | Netzwerk oder Netzsegment | Definierte Anwendung oder Ressource |
| Policy-Kontext | Häufig Identität plus Netzwerk- und Gruppenregeln | Identität, Gerät, Anwendung und weitere kontextbezogene Signale |
| Erreichbarkeit | Interne Adressräume werden zum Endgerät geroutet | Anwendung wird über einen kontrollierten Vermittlungspfad erreichbar |
| Laterale Bewegung | Muss durch Segmentierung und Firewalls begrenzt werden | Kann durch anwendungsbezogene Zugriffspfade reduziert werden |
| Legacy-Protokolle | Oft breit kompatibel | Muss je Protokoll und Produktfunktion geprüft werden |
| Betrieb | Gateway, Kapazität, Patches, Routing und Firewallregeln | Identitäten, App-Segmente, Connector, Policies und Telemetrie |
Wann ist ZTNA der bessere nächste Schritt?
- Externe und privilegierte Zugriffe: Dienstleister oder Administratoren sollen nur definierte Ressourcen erreichen.
- Hybride Anwendungen: Anwendungen liegen im Rechenzentrum, in mehreren Clouds oder in getrennten Unternehmensbereichen.
- Reduzierte Angriffsfläche: Private Anwendungen sollen nicht als allgemein erreichbare Netzwerkdienste exponiert werden.
- Feingranulare Policies: Identität, Gerät und Anwendung sollen in einer nachvollziehbaren Zugriffsentscheidung zusammenlaufen.
- VPN-Betriebsaufwand: Gateways, Kapazität, Routing und wiederkehrende Störungen binden unverhältnismäßig viele Ressourcen.
Wann bleibt ein VPN vorerst sinnvoll?
Ein VPN kann weiterhin erforderlich sein, wenn Anwendungen oder Administrationswerkzeuge echten Netzwerkzugang voraussetzen, nicht unterstützte Protokolle verwenden oder die benötigte Identitäts- und Gerätesicht noch fehlt. Auch Notfall-, Maschinen- und Sonderzugriffe benötigen häufig einen separaten Migrations- oder Koexistenzpfad.
Wichtige Abgrenzung: Nicht jedes VPN ist per se unsicher und nicht jede ZTNA-Einführung ist automatisch Zero Trust. Entscheidend sind der tatsächliche Policy-Umfang, die erreichbaren Ressourcen, die Qualität der Identitäten und Geräteinformationen sowie der laufende Betrieb.
Die fünf Architekturfragen vor einer Ablösung
- Welche Anwendungen? FQDN, Ports, Protokolle, Abhängigkeiten, Servergruppen und Datenflüsse erfassen.
- Welche Identitäten? Mitarbeiter, Externe, Servicekonten und privilegierte Rollen sauber trennen.
- Welche Geräte? Managed, BYOD, Server, mobile Geräte und ihre Posture-Signale unterscheiden.
- Welche Zugriffspolitik? Anwendungsbedarf, Least Privilege, Sitzungsdauer, Risiko und Ausnahmen festlegen.
- Welcher Betriebsweg? Monitoring, Helpdesk, Eskalation, Change, Fallback und Verantwortlichkeiten definieren.
Wie eine Migration mit Zscaler ZPA aussehen kann
Discovery & Architektur
VPN-Nutzergruppen, Anwendungen, Protokolle, Abhängigkeiten und Sonderfälle erfassen. Ergebnis: Migrationsgruppen statt unkontrolliertem Big Bang.
Repräsentativer Pilot
Eine geeignete Anwendung mit realen Identitäten, Endgeräten, App Connectorn und Policies testen. Nutzererlebnis, Sicherheit und Support messbar prüfen.
Wellen und Betrieb
Anwendungen nach Risiko und Komplexität migrieren, Koexistenz bewusst begrenzen und Runbooks, Monitoring sowie Rückfallpfade übergeben.
Wie SourcingBlox unterstützt
SourcingBlox verbindet die Architekturentscheidung mit der praktischen Einführung. Wir erstellen das Anwendungs- und Zugriffsmodell, planen ZPA-Komponenten und Policies, strukturieren Pilot und Migrationswellen und bereiten den späteren Betrieb vor. Wenn gewünscht, unterstützen wir anschließend Changes, Troubleshooting und Governance als klar abgegrenzten Managed Service.
Häufige Fragen
Kann ZTNA ein VPN vollständig ersetzen?
In vielen anwendungsbezogenen Zugriffsszenarien ja. Ob eine vollständige Ablösung sinnvoll ist, hängt von Protokollen, Anwendungen, Sonderzugriffen und Notfallwegen ab. Das Ergebnis kann auch eine zeitlich begrenzte Koexistenz sein.
Ist Zscaler ZPA ein VPN?
ZPA ist ein Zero-Trust-Network-Access-Dienst. Der Zugriff wird an Anwendungen und Policies ausgerichtet, nicht an einem pauschalen Netzwerkzugang. Die konkrete Eignung muss je Anwendung geprüft werden.
Was geschieht mit Legacy-Anwendungen?
Sie werden nicht automatisch ausgeschlossen. Zuerst werden Protokolle, Namensauflösung, Abhängigkeiten und Zugriffsmuster getestet. Nicht geeignete Anwendungen erhalten einen eigenen Modernisierungs- oder Übergangspfad.
Was ist ein sinnvoller Pilot?
Eine geschäftlich relevante, aber beherrschbare Anwendung mit klarer Nutzergruppe und repräsentativen Geräte- und Identitätsbedingungen. Ein reiner Labortest zeigt zu wenig über Betrieb und Support.
Einen VPN-Zugriff in einen belastbaren ZTNA-Pilot übersetzen.
Wir wählen gemeinsam einen repräsentativen Zugriffspfad und klären Anwendungen, Identitäten, Geräte, Policies, Connector und Betriebsanforderungen.
Verwandte Inhalte
Technische Primärquellen
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 1800-35: Implementing a Zero Trust Architecture
- CISA: Modern Approaches to Network Access Security
Prüfdatum: 25. Juli 2026. Konkrete Produkt-, Protokoll- und Lizenzunterstützung muss vor Umsetzung gegen die aktuelle Zscaler-Dokumentation und den jeweiligen Tenant geprüft werden.