VPN oder Zero Trust? Remote-Access im Vergleich

Seit COVID-19 ist Remote-Arbeit Standard - und VPNs haben eine Krise. Ransomware-Gruppen wissen: VPN-Zugang = Netzwerk-Zugang. Kompromittierter VPN-User = freie Fahrt im internen Netz. Zero Trust verspricht das Gegenteil: “never trust, always verify” - nie vertrauen, immer prüfen, auch für Remote-User. Aber ist das für jedes Unternehmen sinnvoll?

Das VPN-Problem

Das klassische VPN-Modell ist einfach: Remote User → VPN-Gateway → Internes Netz. Wer einmal drin ist, hat Zugriff auf alles - Fileserver, Datenbanken, interne Apps, andere PCs. VPN bedeutet “Wer drin ist, darf alles”, und laterale Bewegung für einen Angreifer ist damit trivial.

Warum VPN ein Sicherheitsrisiko geworden ist

1. VPN-Schwachstellen sind kritisch

• Pulse Secure VPN (CVE-2021-22893): Unauthenticated RCE
• Fortinet SSL-VPN (CVE-2023-27997): Heap Overflow, keine Authentifizierung nötig
• Citrix NetScaler (Citrix Bleed): MFA-Bypass
• Mehr als 50 % der KRITIS-Angriffe 2024 erfolgten über VPN-Schwachstellen

2. Kompromittierter VPN-User

Ein Angreifer mit VPN-Zugang erhält vollen Netzwerk-Zugang. Lateral Movement erfolgt ohne weitere Hürden, und Ransomware verbreitet sich direkt im internen Netz.

3. Split Tunneling

Wenn aktiviert, läuft nicht der gesamte Traffic über das VPN. Ein Angreifer auf einem kompromittierten Gerät kann dann sowohl das lokale Netz als auch das VPN-Netz erreichen.

4. Keine Anwendungs-Isolation

VPN gewährt Netzwerk-Zugang, nicht App-Zugang. Ein User der eigentlich nur das ERP braucht, bekommt trotzdem Zugriff auf alles.

Statistik: 53 % aller erfolgreichen Ransomware-Angriffe 2024 starteten über VPN (Coveware Ransomware Report Q4 2024).

Zero Trust Network Access (ZTNA) - Das Prinzip

Kernprinzipien

“Never Trust, Always Verify”

Kein implizites Vertrauen aufgrund der Netzwerk-Position. Jeder Zugriff wird zu jeder Zeit verifiziert. Auch interne User sind nicht automatisch vertrauenswürdig.

“Least Privilege Access”

User erhalten Zugriff ausschließlich auf die App, die sie benötigen - nicht auf das gesamte Netz. Zugriff wird wenn möglich zeitlich begrenzt.

Überprüfungsparameter bei ZTNA

1. Identität: Wer ist der User? (MFA, Identity Provider)
2. Gerät: Ist das Gerät compliant? (MDM, Endpoint-Health)
3. Kontext: Zeit, Ort, Risiko-Score der Aktivität
4. Anwendung: Welche Anwendung wird benötigt?
5. Verhalten: Normal oder anomal?

Beispiel einer ZTNA-Entscheidung

Zugang erlaubt - alle Checks bestanden:

• Request: Max Muster möchte auf Salesforce CRM zugreifen
• Identität: MFA bestätigt
• Gerät: Windows, Patch-Stand aktuell, EDR aktiv
• Kontext: Login aus Deutschland, Bürozeiten, bekannte IP
• Berechtigung: Max hat Salesforce-Berechtigung
• Ergebnis: Zugang erlaubt - nur auf Salesforce, nicht auf das gesamte Netz

Zugang verweigert - Checks fehlgeschlagen:

• Gerät: iOS, ungemanaged, kein MDM
• Kontext: Login aus Russland um 03:00 Uhr
• Ergebnis: Zugang verweigert, Alert, SOC wird informiert

VPN vs. ZTNA im direkten Vergleich

Eigenschaft	Klassisches VPN	ZTNA
Zugriffsmodell	Netzwerk-Zugang	App-Zugang
Lateral Movement	Einfach möglich	Verhindert (kein Netz-Zugang)
User Experience	Langsam, Client erforderlich	Schnell, oft klientlos (Browser)
Gerätecheck	Selten	Immer (Endpoint-Health-Check)
Identitätscheck	Login + Passwort	MFA + risikobasiert + Gerätecheck
Kontext-sensitiv	Nein	Ja (Zeit, Ort, Verhalten)
Anwendungs-Sicht	Keine	Pro-Anwendung granular steuerbar
Legacy Apps	Gut unterstützt	Eingeschränkt (HTTP/HTTPS-Fokus)
Komplexität	Gering	Hoch (IdP, MDM, Policies erforderlich)
Kosten	Gering	Höher (Lizenzkosten + Setup)
Für KMU	Oft ausreichend	Ab ca. 100 Mitarbeitern sinnvoll

VPN ist noch ausreichend wenn:

• Das Team klein ist (unter 50 User)
• Alle Geräte gemanaged sind (MDM vorhanden)
• MFA für das VPN aktiviert ist - nicht optional
• Netz-Segmentierung dahinter besteht (VPN gibt nicht Zugang zu allem)
• Kritische Apps eigene App-Level-Authentifizierung haben
• Die VPN-Software aktuell gepatcht ist

ZTNA ist besser wenn:

• Viele Remote-User vorhanden sind (mehr als 50)
• BYOD-Geräte (ungemanagte Geräte) eingesetzt werden
• Viele SaaS-Apps im Einsatz sind
• Compliance-Anforderungen bestehen (DSGVO, NIS2, ISO 27001)
• Es bereits Sicherheitsvorfälle über VPN gegeben hat
• M365 oder Google Workspace die Hauptumgebung ist

ZTNA-Produkte im Vergleich

Microsoft Entra Private Access (für M365-Kunden)

Integration in Entra ID (ehemals Azure AD) über Conditional Access Policies mit granularen Regeln. Der Global Secure Access Client läuft auf Windows, Mac, iOS und Android. Wenn M365 bereits vorhanden ist, wird kein weiterer Identity Provider benötigt. Die Lösung ist Teil von Microsoft 365 E3/E5 oder Entra ID P1/P2.

Conditional Access Beispiel:

Wenn: App = SAP, User = Buchhaltung
Und:  Device = Compliant (Intune), Land = DE
Und:  Risiko = Niedrig (Microsoft Threat Intelligence)
Dann: Zugang ERLAUBT

Wenn: App = Admin-Konsole
Und:  Device NICHT Compliant
Dann: Zugang VERWEIGERT + SOC-Alert

Cloudflare Zero Trust (ZTNA + CASB + SWG)

Cloudflare Access ermöglicht App-Zugang ohne VPN. Cloudflare Gateway übernimmt DNS-Filterung und Content-Inspection. Das CASB-Modul bietet Sichtbarkeit in die SaaS-Nutzung. Cloudflare Tunnel ist das wichtigste Feature für KMU: eigene Apps können veröffentlicht werden, ohne einen einzigen Port in der Firewall zu öffnen. Die App verbindet sich ausgehend zu Cloudflare, und der User greift darüber auf die App zu.

• Kosten: Free-Tier bis 50 User, danach ab 7 USD/User/Monat
• Ideal für: KMU die kein M365 nutzen

Zscaler Private Access (ZPA) - Enterprise

Marktführer für Enterprise ZTNA als Teil der SASE-Plattform (Secure Access Service Edge). Die komplexe Policy-Engine bietet maximale Granularität, ist aber für KMU zu komplex und zu teuer (ab 15 USD/User/Monat).

WireGuard-basierte ZTNA (Tailscale, Twingate)

Tailscale: WireGuard-Mesh-VPN als ZTNA-Hybrid mit Peer-to-Peer-Architektur (kein zentrales Gateway). Free-Tier: 3 User und 100 Geräte. Team-Preis: 6 USD/User/Monat. Besonders geeignet für kleine Teams und Entwickler.

Twingate: App-Level-Zugang ohne Client-Installation (Browser-Option verfügbar). Free für 5 User, danach 5 USD/User/Monat. Gut für BYOD-Szenarien.

Migrationsstrategie: VPN zu ZTNA

Phase 1 - Analyse (Woche 1-4)

• Inventur: Welche Anwendungen werden über VPN genutzt?
• Klassifikation: Welche sind webbasiert? Legacy? Welches Protokoll?
• User-Segmentierung: Wer braucht welchen Zugang?
• ZTNA-Produkt evaluieren und auswählen

Phase 2 - Pilot (Monat 2-3)

• 10-20 User als Pilot-Gruppe
• Webbasierte Apps zuerst über ZTNA publizieren
• Feedback sammeln und User schulen
• MDM/Geräte-Compliance-Check einrichten

Phase 3 - Rollout (Monat 3-6)

• Alle webbasierten Apps auf ZTNA umstellen
• VPN-Zugang auf Legacy-Apps beschränken (Übergangslösung)
• ZTNA-Logs ins SIEM integrieren und überwachen

Phase 4 - Legacy-Migration (Monat 6-12)

• Legacy-Apps ZTNA-fähig machen oder App-Gateway nutzen
• VPN-Scope weiter einschränken
• Ziel: VPN nur noch für absolute Ausnahmen

Parallel zu allen Phasen

• MFA für VPN sofort aktivieren, falls noch nicht geschehen - VPN ohne MFA ist eine Einladung für Brute-Force und Credential-Stuffing
• Netz-Segmentierung umsetzen: auch mit VPN kein Flat-Network mehr
• EDR auf allen Remote-Geräten installieren
• SIEM-Alert bei VPN-Logins von ungewöhnlichen Standorten einrichten

---

Die Antwort ist nicht VPN ODER Zero Trust - sondern der richtige Ansatz für die eigene Situation. Für viele KMU ist ein gehärtetes VPN mit MFA und Netz-Segmentierung der erste Schritt. AWARE7 analysiert die aktuelle Remote-Access-Architektur und empfiehlt konkrete Verbesserungen.

Sicherheitsanalyse anfragen | Zero Trust Beratung