VPN durch ZTNA ersetzen: der sicherere Ansatz für hybrides Arbeiten

Warum VPN ein Sicherheitsrisiko geworden ist

VPN-Architekturen ruhen auf einer einfachen Annahme: Jeder, der einen Tunnel ins Unternehmensnetzwerk aufbauen kann, wird darin operieren zu dürfen. Diese Annahme versagt in modernen Umgebungen in vier konkreten Weisen.

Laterale Bewegung. Sobald ein Angreifer einen VPN-Berechtigungsnachweis kompromittiert (Phishing, Credential Stuffing, Malware am Endpunkt), hat er Netzwerk-Level-Zugriff. Von diesem Standpunkt aus ist die laterale Bewegung zu sensiblen Systemen weitgehend ungehindert, weil der Perimeter ihm vertraut hat.

Übermäßig breiter Zugriff. VPNs gewähren Zugriff auf Netzwerksegmente, nicht auf spezifische Anwendungen. Ein Benutzer, der eine Anwendung benötigt, erhält Sicht auf alles in seinem Subnetz. Das Least-Privilege-Prinzip fehlt strukturell.

Leistung und Skalierung. VPN-Konzentratoren sind physische oder virtuelle Engpässe. Mit dem Wachstum der hybriden Belegschaft stapelten Unternehmen Appliances und fügten Komplexität zur Skalierung hinzu. Die Leistung verschlechtert sich, die Support-Last steigt.

Audit-Unsichtbarkeit. VPN-Logs zeigen typischerweise erfolgreiche Verbindungen, nicht was während der Sitzung getan wurde. Ein Auditor, der fragt "auf welche Anwendungen hat Auftragnehmer X gestern zugegriffen?", erhält bestenfalls ungenaue Antworten.

Wie ZTNA funktioniert: Least Privilege, kontinuierliche Verifizierung und Geräte-Posture

ZTNA kehrt das VPN-Modell um. Statt Netzwerkzugriff zu gewähren, gewährt ZTNA Anwendungszugriff. Der Benutzer authentifiziert sich, die Plattform bewertet den Kontext, die Plattform erstellt eine begrenzte, zeitlich befristete, anwendungsspezifische Verbindung. Alles andere bleibt unsichtbar.

Die technischen Bausteine sind Identität, Kontext und Posture. Identität bedeutet starke Authentifizierung, typischerweise einschließlich MFA und Integration mit dem Unternehmens-Identity-Provider. Kontext umfasst Standort, Tageszeit, Anfragemuster und Verhaltensbaseline. Posture bedeutet Echtzeit-Verifizierung des Geräts: OS-Version, Patch-Level, Endpunkt-Schutzstatus, Zertifikatsgültigkeit.

Wenn sich ein Faktor mitten in der Sitzung ändert (Geräte-Posture verschlechtert sich, Verhalten weicht von der Baseline ab, Standort verschiebt sich unerwartet), wird die Zugriffsentscheidung neu bewertet. Sitzungen, die gültig begannen, können dynamisch widerrufen werden.

Universal ZTNA von Cato: eine Richtlinie für jeden, überall

Die meisten ZTNA-Produkte werden auf eine bestehende Infrastruktur aufgesetzt: ein separates Gateway, eine separate Policy-Engine, ein separater Client. Universal ZTNA auf der Cato SASE Plattform ist anders. Es läuft als native Fähigkeit auf derselben cloud-nativen Plattform, die SD-WAN, SSE und AI Security liefert.

Die praktischen Implikationen sind wichtig. Eine Policy-Engine bedeutet ein einziges Policy-Framework für Büromitarbeiter, Remote-Mitarbeiter, Auftragnehmer, Lieferanten und Maschinenidentitäten. Ein Client (oder clientless über Browser für unverwaltete Geräte) bedeutet geringere Endpunkt-Komplexität. Ein Audit-Trail bedeutet, dass alle Zugriffsentscheidungen, unabhängig von der Benutzerkategorie, im selben Datenspeicher landen.

Für Unternehmen, die drei separate Zugriffsregime verwaltet haben (VPN für Mitarbeiter, separates Portal für Auftragnehmer, föderierter Zugriff für Partner), konsolidiert Universal ZTNA dies in ein operatives Modell.

BYOD und Auftragnehmer: der vergessene Angriffsvektor

Die meisten VPN-Architekturen handhaben verwaltete Geräte einigermaßen gut. Wo sie versagen, ist bei BYOD und Auftragnehmern: persönliche Handys, Auftragnehmer-Laptops, Lieferanten-Engineer-Workstations. Entweder erhalten sie denselben Netzwerkzugriff wie verwaltete Geräte (ein echtes Risiko) oder sie erhalten ein umständliches separates Portal, das Benutzer zu Umgehungen drängt.

ZTNA handhabt dies elegant. Posture-Checks unterscheiden in Echtzeit verwaltete von unverwalteten Geräten; Richtlinien passen den Zugriffsumfang entsprechend an. Ein Auftragnehmer auf einem unverwalteten Laptop kann ohne VPN nur Lesezugriff auf den Projekt-Dateifreigabe erhalten; der Unternehmens-Engineer auf einem verwalteten Laptop erhält vollen Zugriff plus andere Ressourcen. Dasselbe Policy-Framework, unterschiedliche Bewertungsergebnisse.

Hier wird auch die Supply-Chain-Sicherheitsverpflichtung von NIS2 konkret. ZTNA produziert die Nachweise, die Aufsichtsbehörden erwarten: welcher Lieferant, mit Zugriff worauf, wann, mit welcher Geräte-Posture.

ZTNA und NIS2: nachweisbare Zugangskontrolle für Auditoren

NIS2 Artikel 21 verlangt Zugangskontrolle und Identitätsmanagement. Die Aufsichtsbehörde erwartet Nachweise, nicht Richtlinien auf Papier. ZTNA erzeugt diese Nachweise als Nebenprodukt des normalen Betriebs: jede Zugriffsentscheidung mit Identität, Gerät, Kontext und Policy-Referenz protokolliert.

Für Compliance-Berichte ist das der Unterschied zwischen einer mehrwöchigen Nachweissammlung über zwölf Tools und einem Konsolen-Export. Wir entpacken die breitere NIS2-Compliance-Geschichte in unserem Artikel über NIS2 und SASE.

Migration: parallel laufen, dann VPN ausmustern

Eine pragmatische ZTNA-Migration führt VPN und ZTNA drei bis sechs Monate parallel. Hochwertige Anwendungen wechseln zuerst zu ZTNA; das Support-Team überwacht die Benutzererfahrung und verfeinert Richtlinien. Sobald das erste Set von Anwendungen auf ZTNA stabil ist, folgt das nächste Set. Die VPN-Ausmusterung erfolgt, wenn die Anwendungsabdeckung vollständig ist.

Das Cato-Implementierungsmuster spiegelt dies wider: Universal ZTNA aktiviert sich, ohne das Legacy-VPN sofort zu deaktivieren. Kunden steuern die Migrationszeitlinie basierend auf ihrer operativen Bereitschaft, nicht auf einem Anbieter-Cutover-Zeitplan.