ZTNA statt VPN: Remote Access Security neu designen

ZTNA statt VPN ist für viele Unternehmen der logische nächste Schritt, um Remote Access Security neu zu designen: weg vom klassischen Netzwerkzugang, hin zu einem applikationszentrierten Zugriff mit Identitäts- und Gerätekontext. Ein VPN erweitert das interne Netz bis auf den Laptop des Nutzers – praktisch, aber sicherheitstechnisch riskant, weil Laterale Bewegung, Fehlkonfigurationen und zu breite Zugriffsrechte begünstigt werden. Zero Trust Network Access (ZTNA) verfolgt einen anderen Ansatz: Der Benutzer erhält nicht „einmal Zugang zum Netz“, sondern Zugriff auf genau die Anwendungen, die er benötigt – basierend auf Rolle, Gerätezustand, Risiko und Policy. Dadurch werden Regeln präziser, auditierbarer und oft auch betrieblich einfacher, weil weniger Netzwerk-Routen und weniger komplexe Split-Tunnel-Ausnahmen nötig sind. Dieser Artikel erklärt, wie Sie ZTNA statt VPN in der Praxis umsetzen, welche Architekturbausteine Sie dafür brauchen, wie Migrationen ohne Betriebsrisiko gelingen und wie Sie Remote Access so gestalten, dass Sicherheit, Nutzererlebnis und Governance zusammenpassen.

Warum klassisches VPN als Remote-Access-Modell an Grenzen stößt

VPN ist bewährt, aber das Modell „Tunnel ins interne Netz“ ist im Kern ein Netzwerkparadigma aus einer Zeit, in der Anwendungen überwiegend im Rechenzentrum lagen und Endgeräte meist im Unternehmensnetz betrieben wurden. Heute ist das Umfeld dynamischer: SaaS, Multi-Cloud, mobile Endgeräte und externe Partnerzugriffe sind Standard. VPN bringt in diesem Kontext typische Herausforderungen mit sich:

• Netzwerkzugang statt Applikationszugang: Nutzer erhalten häufig Zugriff auf ganze Subnetze, obwohl sie nur eine Webanwendung benötigen.
• Laterale Bewegung: Ein kompromittierter Endpunkt kann sich innerhalb des VPN-Segments weiterbewegen, sofern Segmentierung und Policies nicht sehr strikt sind.
• Komplexität durch Split Tunneling: Ausnahmen für SaaS, interne Dienste, DNS und Proxy führen zu schwer wartbaren Konfigurationen.
• Backhauling und Latenz: Traffic wird unnötig über zentrale Gateways geführt, was Performance und Kosten verschlechtert.
• Betriebsrisiko: Änderungen an VPN-Routen, Zugriffslists oder Authentisierung können großflächige Störungen erzeugen.

Was ZTNA ist und wie es sich von VPN unterscheidet

ZTNA (Zero Trust Network Access) ist ein Zugriffskonzept, bei dem der Zugriff nicht auf das Netzwerk, sondern auf Anwendungen und konkrete Ressourcen gewährt wird. Der Nutzer wird kontinuierlich anhand von Identität und Kontext bewertet. ZTNA wird häufig als Bestandteil von SSE/SASE-Plattformen umgesetzt, kann aber auch als eigenständige Remote-Access-Schicht betrieben werden.

• VPN: „Verbinde mich ins Netz“ – danach regeln Routing und Segmentierung, was erreichbar ist.
• ZTNA: „Greife auf App X zu“ – Policy entscheidet pro App und Kontext, ob Zugriff erlaubt ist.
• Prinzip: Standardmäßig kein Vertrauen; Zugriff wird minimal, kontextbasiert und nachvollziehbar gewährt.

Als strukturierter Referenzrahmen für Zero-Trust-Denken eignet sich NIST SP 800-207 (Zero Trust Architecture).

Die Bausteine einer ZTNA-Architektur

Eine funktionierende ZTNA-Umsetzung besteht aus mehreren Komponenten, die gemeinsam den Zugriff steuern und absichern. Typische Bausteine sind:

• Identity Provider (IdP): Authentisierung, Rollen/Gruppen, MFA, Conditional Access Signale.
• Policy Engine: Bewertet Kontext (User, Device, Risiko, App) und entscheidet über Zugriff.
• ZTNA Connector/Gateway: Stellt den Zugriff auf interne Apps her, ohne diese direkt öffentlich zu exponieren.
• Client oder Clientless Access: Je nach Anwendung (Web-Portal, agent-basierter Zugriff, App-Proxy).
• Telemetry & Logging: Protokolliert Entscheidungen, Sessions, Denies, Risiken und ermöglicht Nachweise.

Wichtig ist die Trennung zwischen „Policy Decision“ und „Policy Enforcement“. Dieses Modell ist in NIST SP 800-207 ausführlich beschrieben.

Designprinzipien: Remote Access neu denken

Damit ZTNA statt VPN in der Praxis funktioniert, sollte der Umstieg nicht nur technisch, sondern konzeptionell erfolgen. Die folgenden Prinzipien helfen, eine stabile Zielarchitektur zu bauen:

• Applikationszentrierung: Zugriff wird pro Anwendung definiert (nicht pro Subnetz).
• Least Privilege: Nur die minimal notwendigen Zugriffe, idealerweise mit Rollen und App-Gruppen.
• Device Posture: Managed/Compliant Geräte bekommen mehr Rechte als BYOD/Unknown.
• Explizite Trust Boundaries: Management-Zugriffe und kritische Systeme werden besonders streng behandelt.
• Auditable by Design: Jede Policy hat Owner, Zweck, Review-/Ablaufdatum und Logs als Evidence.

Use Cases: Wo ZTNA besonders stark ist

ZTNA ist nicht in jedem Szenario automatisch besser als VPN. Der größte Nutzen entsteht dort, wo Nutzer gezielt auf Anwendungen zugreifen sollen und Netzwerkzugang unnötig riskant ist.

• Interne Webanwendungen: Portale, HR/Finance, Ticketing, interne APIs.
• Admin-Interfaces: Management-UIs von Plattformen, Bastion/Jump Hosts, Remote Admin Tools (mit zusätzlicher Kontrolle).
• Partnerzugänge: Externe erhalten Zugriff auf wenige definierte Services statt aufs Netz.
• Remote Work: Konsistenter Zugriff unabhängig vom Standort, ohne komplexes Routing.
• SaaS Governance in Kombination: ZTNA ergänzt SWG/CASB, sodass Web/SaaS und interne Apps einheitlich gesteuert werden.

Wo VPN weiterhin sinnvoll sein kann

In der Praxis läuft es häufig auf ein hybrides Modell hinaus. VPN kann sinnvoll bleiben, wenn echte Netzwerkfunktionen benötigt werden, die sich schwer applikationszentriert abbilden lassen.

• Legacy-Protokolle: Anwendungen, die nicht proxy-freundlich sind oder dynamische Ports nutzen.
• Vollständige Netzadministration: Bestimmte Betriebsszenarien, in denen Layer-3-Zugriff erforderlich ist (aber dann strikt segmentiert und mit PAM/MFA).
• Break-Glass-Szenarien: Notfallzugriff bei IdP-Ausfällen oder als Recovery-Pfad (streng kontrolliert).

Selbst in diesen Fällen lohnt es sich, VPN auf eng definierte Admin- und Sonderrollen zu reduzieren und den Rest über ZTNA zu führen.

Identity und Device Context: Der eigentliche Gewinn

ZTNA entfaltet seinen Nutzen vor allem dann, wenn Policies nicht nur auf „User ja/nein“ basieren, sondern auf Kontext. Dazu gehören:

• Rolle/Gruppe: Abteilung, Applikationsrolle, Partnerrolle, Adminrolle.
• MFA-Status: Zugriff auf kritische Apps nur nach erfolgreicher MFA oder Step-up MFA.
• Gerätezustand: Managed/Compliant vs. Unmanaged; EDR aktiv; Verschlüsselung; Patchstand.
• Risikosignale: Ungewöhnlicher Standort, neues Gerät, erhöhtes Konto-Risiko (sofern IdP/EDR Signale liefert).

Damit werden Policies fachlich erklärbar: „Finance-Rolle auf compliant Gerät darf auf Finance-App“ ist auditfreundlicher als „Subnetz X darf auf Server Y“.

Applikations-Onboarding: So modellieren Sie Zugriff ohne Netzwerkerweiterung

Ein kritischer Erfolgsfaktor ist ein standardisiertes Onboarding neuer Anwendungen in ZTNA. Bewährt hat sich ein Pattern-Ansatz, bei dem jede App in eine Zugriffsklasse fällt:

• Public Web (ohne Auth): selten intern, aber ggf. über DMZ/WAF; nicht typisch für ZTNA.
• Internal Web (SSO-fähig): ideal für ZTNA clientless mit IdP-Integration.
• Client/Thick App: ZTNA mit Agent oder App-Connector; Ports klar definieren.
• Admin/Privileged: ZTNA + MFA + PAM; bevorzugt über Bastion/Jump Host mit Session Controls.

Wichtig ist, pro App klare Abhängigkeiten zu dokumentieren (DNS, Auth, APIs, Datenbanken), damit Policies nicht durch „Service Any“-Ausnahmen aufgeweicht werden.

Enforcement-Modelle: Client, Clientless und App-Proxy

ZTNA kann technisch unterschiedlich umgesetzt werden. Die Wahl beeinflusst Nutzererlebnis, Kompatibilität und Kontrollmöglichkeiten.

• Clientless (Browser-basiert): Gut für Webapps, schnell ausrollbar, häufig mit SSO. Einschränkung: weniger geeignet für komplexe Client-Protokolle.
• Client/Agent-basiert: Flexibel für viele Protokolle; ermöglicht stärkere Device-Posture-Prüfung. Aufwand: Rollout und Betrieb des Clients.
• App-Proxy/Gateway: Zentraler Proxy, der interne Apps erreichbar macht, ohne sie direkt zu exponieren. Erfordert sauberes Connector-Design und High Availability.

In vielen Organisationen ist eine Kombination sinnvoll: Webapps clientless, Spezialprotokolle über Client.

Netzwerk- und Segmentierungsdesign: ZTNA braucht saubere Trust Boundaries

ZTNA reduziert die Notwendigkeit, große Remote-Subnets ins Netz zu routen, ersetzt jedoch keine interne Segmentierung. Im Gegenteil: Eine klare Zonierung macht ZTNA-Policies stabiler, weil die Backends in definierten Bereichen liegen (APP, DB, MGMT, CORE).

• MGMT strikt trennen: Administrative Ziele in eigener Zone/VRF; Zugriff nur für Adminrollen.
• CORE Services schützen: DNS/IAM/PKI/Logging/Backup nur über definierte Pfade.
• DMZ entkoppeln: Public Ingress bleibt DMZ-Thema; ZTNA ist primär für authentisierte Zugriffe auf interne Apps.

Migration: Von VPN zu ZTNA ohne Big Bang

Der Umstieg gelingt am besten über eine stufenweise Migration, die Nutzergruppen und Apps priorisiert. Ein bewährtes Vorgehen:

Phase: Inventarisierung und Policy-Baseline

• Applikationsliste: Welche Apps werden remote genutzt? Welche sind SSO-fähig?
• Nutzergruppen: Standard-User, Power-User, Admins, Partner, Dienstleister.
• Risiko-Klassifizierung: Kritische Apps (Finance, IAM, Admin), mittlere Apps, Low-Risk Apps.

Phase: Pilot und Canary

• Pilotgruppe: IT/Security und eine kleine Business-Gruppe, klare Feedbackkanäle.
• Monitor-Only, wo möglich: Erst Telemetrie und Deny-Gründe beobachten, dann enforce.
• Fallback-Plan: Temporärer VPN-Zugriff für definierte Sonderfälle, aber mit Expiry.

Phase: App-Wellen statt Nutzer-Wellen

• Welle 1: Interne Webapps (SSO), die wenig Sonderprotokolle brauchen.
• Welle 2: Business-kritische Apps mit klaren Abhängigkeiten.
• Welle 3: Legacy/Spezialprotokolle, ggf. über Agent oder Bastion, streng segmentiert.

Security Controls: MFA, PAM und Management Plane Security im ZTNA-Kontext

ZTNA ist kein Ersatz für Privileged Access Controls. Für administrative Zugriffe sollten Sie zusätzliche Schutzschichten einplanen:

• MFA verpflichtend: Mindestens für Adminrollen und kritische Apps; idealerweise Step-up bei Risiko.
• PAM für Admin-Sessions: Just-in-Time, Credential Vaulting, Session Recording (wo zulässig).
• Bastion/Jump Host Pattern: Administrative Protokolle laufen über kontrollierte Einstiegspunkte.
• OOB/Management-VRF: Infrastrukturmanagement bleibt strikt getrennt vom normalen User-Zugriff.

TLS-Inspection und DLP: Wann es Sinn ergibt

Viele ZTNA/SSE-Plattformen können zusätzlich Web- und SaaS-Traffic kontrollieren (SWG/CASB) und TLS-Inspection sowie DLP anbieten. Das ist relevant, wenn Remote Access nicht nur interne Apps betrifft, sondern auch Datenabfluss über SaaS. Für die Praxis gilt:

• Selektiv starten: Nicht alles entschlüsseln; Kategorien und Apps priorisieren.
• Ausnahmen definieren: Technische Inkompatibilitäten (z. B. Certificate Pinning) und sensible Kategorien.
• Fehlermodi festlegen: Verhalten bei Decryption-Fehlern (block/allow/monitor) muss klar sein.

Logging, Monitoring und Audit: Nachweise aus ZTNA gewinnen

Ein Vorteil von ZTNA ist die bessere Nachvollziehbarkeit, weil Entscheidungen pro App und pro Identität getroffen werden. Damit das auditierbar wird, sollten Logs und Metadaten standardisiert sein:

• Policy-Logs: Allow/Deny inkl. User, Gruppe/Rolle, Device-Status, App, Reason Codes.
• Session-Events: Login, MFA, Token-Refresh, Session End, Risk Changes.
• Evidence-Metadaten: Owner, Zweck, ReviewDate/Expiry pro App-Policy.
• Logpipeline-Health: Drops, Lag, Parser-Fehler – sonst sind Nachweise nicht belastbar.

Für auditierbare Prozesse und Verantwortlichkeiten ist ISO/IEC 27001 eine gängige Referenz.

Automatisierte Compliance Checks: ZTNA-Policies gegen Standards prüfen

Damit ZTNA nicht in neue „Policy Sprawl“-Probleme läuft, sollten Standards automatisiert durchgesetzt werden – idealerweise als Teil von Policy-as-Code/GitOps oder als regelmäßige Compliance Scans.

• Owner Pflicht: Keine Policy ohne Verantwortliche.
• ReviewDate Pflicht: Jede App-Policy ist rezertifizierbar.
• Keine breite Ausnahmen ohne Expiry: Bypässe sind timeboxed und begründet.
• Admin-Policies streng: Admin-Zugriff nur mit MFA und compliant device.

Als praxisnahe Mindestkontrollen zur sicheren Konfiguration und kontinuierlichen Pflege eignen sich die CIS Controls.

Typische Stolpersteine beim Umstieg und praktische Gegenmaßnahmen

• Zu viele Legacy-Protokolle unterschätzt: Gegenmaßnahme: Frühzeitig App-Klassen bilden und für Spezialfälle Bastion/Agent planen.
• Device Posture zu hart umgesetzt: Gegenmaßnahme: Remediation-Pfade statt Totalsperre; BYOD klar trennen.
• Unknown/Bypass wird normal: Gegenmaßnahme: Restriktive Default-Policies und ein sauberer Ausnahmeprozess mit Expiry.
• Split Brain zwischen VPN und ZTNA: Gegenmaßnahme: Klare Roadmap und Zielzustand; VPN nur für definierte Sonderfälle.
• Telemetrie fehlt: Gegenmaßnahme: Logging-Standards und SIEM-Anbindung von Anfang an.

KPIs: Erfolg von ZTNA statt VPN messbar machen

• VPN-Reduktionsrate: Anteil Remote Access über ZTNA vs. VPN (nach Nutzergruppen und Apps).
• App Coverage: Anteil kritischer Apps, die über ZTNA erreichbar sind.
• Device Compliance Rate: Anteil Sessions von compliant Geräten bei kritischen Apps.
• Policy Exceptions: Anzahl und Laufzeit von Bypässen/Exceptions (Timeboxing-Qualität).
• Change Failure Rate: Anzahl Rollbacks/Incidents nach Policy-Änderungen.
• User Experience: Latenz, Login-Erfolgsrate, Helpdesk-Tickets im Zusammenhang mit Remote Access.

Praktische Checkliste: Remote Access Security mit ZTNA neu designen

• 1) Zielbild definieren: Welche Nutzergruppen und Apps sollen über ZTNA laufen, welche Sonderfälle bleiben temporär bei VPN?
• 2) IdP und MFA sauber integrieren: Gruppen/Rollen, Conditional Access, Step-up MFA für kritische Apps.
• 3) Device Posture etablieren: Managed/Compliant Signale aus MDM/UEM, BYOD getrennte Pfade.
• 4) App-Onboarding standardisieren: Patterns für Webapps, Client-Apps, Admin-Zugriffe.
• 5) Pilot und Canary: Kleiner Start, Telemetrie sammeln, schrittweise Enforcement.
• 6) Admin-Zugriff besonders absichern: ZTNA + PAM/Bastion + Management-Zone, keine Netzwerkerweiterung für Standardnutzer.
• 7) Logging und Evidence-by-Design: Policy-Metadaten, zentrale Logs, Logpipeline-Health.
• 8) Rezertifizierung und Compliance Checks: ReviewDate/Expiry, Ausnahmen timeboxen, kontinuierliche Pflege.

Outbound-Quellen für Grundlagen und Rahmenwerke

• NIST SP 800-207 (Zero Trust Architecture) für Zero-Trust-Prinzipien und Policy Decision/Enforcement Modelle.
• CIS Controls für praxisnahe Mindestkontrollen zu Zugriffsschutz, Konfigurationsmanagement und Monitoring.
• ISO/IEC 27001 Überblick für auditierbare Prozesse, Verantwortlichkeiten und Evidence-Anforderungen.
• MITRE ATT&CK zur Strukturierung von Bedrohungen und Monitoring-Zielen (z. B. Credential Access, Lateral Movement).

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.