ZTNA (Zero Trust Network Access) - Definition & Erklärung

ZTNA (Zero Trust Network Access) ist der moderne Ersatz für traditionelles VPN. Während VPN einem Nutzer vollen Netzwerkzugang gibt (wie einen physischen Büroschlüssel), erlaubt ZTNA nur Zugang zu spezifischen, autorisierten Anwendungen - nach kontinuierlicher Verifikation.

Das Problem mit traditionellem VPN

Traditionelles VPN-Modell: Nutzer verbindet sich → Netzwerk-Tunnel → Zugang zu ALLEM im internen Netzwerk (ähnlich wie Hausschlüssel: einmal drin, überall drin).

Probleme:

Kompromittierter VPN-Account = kompletter Netzwerkzugang
Lateral Movement: Angreifer kann sich durch gesamtes Netz bewegen
Kein Kontext: egal ob Gerät kompromittiert oder Standort verdächtig
Zugriffsrechte nie granular genug
“Castle and Moat” - drinnen = vertrauenswürdig (falsch!)

ZTNA-Prinzip: Never Trust, Always Verify

Nutzer möchte Anwendung A zugreifen → ZTNA-Policy Engine prüft:

Identität (wer ist der User? MFA bestätigt?)
Gerät (compliant? MDM-registriert? kein Jailbreak?)
Kontext (normale Uhrzeit? bekanntes Land? normales Verhalten?)
Berechtigung (darf dieser User Anwendung A zugreifen?)

Erlaubt: Zugang NUR zu Anwendung A (nicht zum gesamten Netzwerk). Verweigert: bei Verdacht, schlechtem Gerätestatus, unbekanntem Standort.

ZTNA vs. VPN

Merkmal	Traditionelles VPN	ZTNA
Zugangsmodell	Netzwerk-Level (alles)	Anwendungs-Level (granular)
Lateral Movement	Möglich nach VPN-Zugang	Nicht möglich (kein Netzwerkzugang)
Gerätestatus	Nicht geprüft	Kontinuierlich geprüft
Standort/Kontext	Nicht bewertet	Risiko-adaptiv
Skalierung	Zentrale Gateways	Cloud-native, keine Hardware
User Experience	Split-Tunnel-Probleme	App-spezifisch, transparent
Zero-Day-VPN-CVE	Angriffsfläche groß	Kein öffentlich exponiertes VPN

ZTNA Architektur

Agent-basiertes ZTNA

Komponenten: Endpoint-Agent (auf jedem Gerät) ↔ ZTNA Control Plane (Cloud) → Policy Engine ↔ Application Connector (vor jeder Anwendung im Rechenzentrum)

Flow: Nutzer → Agent authentifiziert via MFA → Agent sendet User-ID, Gerätestatus, Standort → Policy Engine entscheidet: Zugang zu CRM erlaubt (nicht zu ERP) → Agent öffnet verschlüsselten Tunnel NUR zur CRM-App.

Agentenloses ZTNA (Browser-basiert)

Nutzer öffnet Browser → ZTNA-Portal-URL → Identitätsverifikation (Azure AD, Okta) → Browser-Session mit Proxy-Zugang zu genehmigten Web-Apps. Keine Installation nötig - ideal für Contractor und BYOD-Geräte.

ZTNA-Produkte

Anbieter	Besonderheit
Zscaler Private Access (ZPA)	Marktführer, Cloud-native
Cloudflare Access	Günstig, einfach, hohe Performance
Microsoft Entra Private Access	Azure AD-Integration, M365-nativ
Palo Alto Prisma Access	NGFW-Integration, SASE-Plattform
Cisco Secure Access	Umbrella-Integration
Check Point Harmony Connect	SMB-freundlich

ZTNA als Teil von SASE

SASE (Secure Access Service Edge) kombiniert ZTNA mit anderen Cloud-Sicherheitsfunktionen:

SASE = ZTNA + SWG + CASB + FWaaS + SD-WAN

SWG (Secure Web Gateway): URL-Filtering, SSL-Inspection
CASB: Cloud App Control (Shadow IT, DLP)
FWaaS: Firewall as a Service (Layer 7)
SD-WAN: Optimiertes Routing

Anbieter: Zscaler, Cloudflare One, Netskope, Palo Alto SASE.

Implementierung: Schritt für Schritt

Identität (Woche 1-4): Alle User in MFA-fähiges IAM (Entra ID, Okta); Conditional Access: MFA für alle Anwendungszugriffe
Geräteverwaltung (Woche 4-8): MDM (Intune/Jamf) für alle Geräte; Gerätecompliance-Policies definieren; ZTNA akzeptiert nur konforme Geräte
Anwendungs-Discovery (Woche 8-12): Welche Anwendungen brauchen Remote-Zugang? ZTNA-Connectoren vor jede Anwendung
VPN ersetzen (Woche 12-20): Parallel ZTNA und VPN aktiv; Migration Abteilung für Abteilung; VPN deaktivieren wenn 100% migriert
Zero Trust fortführen: Mikrosegmentierung interne Netzwerke; UEBA, kontinuierliche Risikoanalyse

ZTNA ist der Kern einer Zero Trust Architecture - der erste, wichtigste Schritt weg vom “Castle and Moat” Modell.