Zero Trust in der Praxis: Vom „VPN-Denken“ zu ZTNA – ohne das Business zu stören

Über Jahre war die Standardantwort für Remote Access simpel: „VPN nutzen.“ Das funktionierte, solange der Perimeter klar war, die meisten Anwendungen im internen Netzwerk lagen und Geräte weitgehend gemanagt waren.

In 2025/2026 ist diese Realität verschwunden. Anwendungen verteilen sich auf SaaS, Rechenzentrum und Cloud. Mitarbeitende arbeiten überall. Externe benötigen Zugriff. Geräte sind heterogen. Und Angreifer wissen: ein kompromittierter Account reicht oft aus, um sich intern weiterzubewegen.

Zero Trust ist kein Produkt, das man kauft. Es ist ein Betriebsmodell: niemals standardmäßig vertrauen, immer verifizieren, Least Privilege umsetzen und Zugriff kontinuierlich bewerten. ZTNA (Zero Trust Network Access) ist der praktische Weg, Remote Access in diesem Modell umzusetzen.

Warum „VPN-Denken“ zum Risiko wird

VPN erweitert das interne Netzwerk zu Remote-Nutzern. Das ist bequem – erweitert aber auch die Angriffsfläche. Sobald ein Gerät verbunden ist, erhält es häufig breite Netzwerkreichweite, und Sicherheit wird zur Daueraufgabe: patchen, segmentieren, lateral movement erkennen.

• VPN ist Netzwerkzugriff: Nutzer bekommen oft mehr Reichweite als nötig
• Kompromittierte Credentials werden schnell zu „internem Zugang“
• VPN-Policies sind oft statisch (IP-Bereiche, Gruppen) und träge
• Lateral Movement wird leichter, sobald der Angreifer „drin“ ist
• Vertrauen wird konzentriert: ein Tunnel kann viele Türen öffnen

Das Problem ist nicht, dass VPN immer schlecht ist. Das Problem ist, VPN als zentrale Zugriffstrategie zu nutzen – ohne Identity-Controls, Device Checks und strikte App-Authorization.

Was ZTNA tatsächlich verändert

ZTNA dreht das Modell um: statt Zugriff auf ein Netzwerk zu geben, gibt es Zugriff auf eine konkrete Anwendung oder Ressource – basierend auf Identität, Kontext und Device Posture. Nutzer „treten nicht dem Netzwerk bei“, sondern erhalten einen kontrollierten, protokollierten Pfad zu dem, was sie nutzen dürfen.

• Applikationszugriff statt Netzwerkzugriff
• Identity-first: SSO + MFA + Risiko-Policies entscheiden
• Device Posture: compliant = mehr Zugriff, nicht compliant = eingeschränkt
• Kontinuierliche Verifizierung: Sessions/Risiko können neu bewertet werden
• Bessere Auditierbarkeit: wer hat was wann von wo genutzt

Die 5 Bausteine eines echten Zero-Trust-Rollouts

Eine erfolgreiche Migration ist nicht „VPN durch ZTNA ersetzen“. Es ist eine stufenweise Verbesserung der Zugriffskontrollen über Identität, Geräte, Apps, Netzwerk und Logging. Diese fünf Bausteine sind die Mindestbasis:

• Identität: SSO, phishing-resistente MFA-Optionen, Conditional Access
• Device Posture: MDM/EDR-Signale, Compliance-Regeln, managed vs unmanaged
• App-Policies: per App autorisieren, Least Privilege, Segmentierung
• Netzwerksegmentierung: Lateral Movement reduzieren, wo Netzwerkzugriff bleibt
• Observability: zentrale Logs, Alerts, Audit Trails, kontinuierliche Verbesserung

Tabelle: VPN vs. ZTNA – Unterschiede im Alltag

Reality Check: App-Inventar und Access Map

Bevor Sie Technologie anfassen, kartieren Sie die Zugriffsrealität. Viele Unternehmen stellen fest, dass VPN weit mehr ist als „Remote Work“: es kompensiert fehlendes SSO, unklare Verantwortlichkeiten und alte Netzwerkannahmen.

• Top-20 interne Apps + Nutzergruppen erfassen
• Trennen: Web Apps, Client/Server, Legacy, File Shares, Admin Access
• Abhängigkeiten mappen: Datenbanken, interne APIs, Jump Hosts
• Sensitivität klassifizieren: HR/Finance/Admin vs allgemein
• Nutzergruppen definieren: Mitarbeitende, Admins, Externe, Partner

Das ist Ihre Zero-Trust-Access-Map. Ohne diese Map wird ZTNA zum zufälligen Rollout, der Workflows bricht.

Identity-First: Das Zentrum der Kontrolle

Zero Trust funktioniert, wenn Identität die Steuerungsebene ist: SSO wo möglich, MFA überall, und Conditional-Access-Policies, die Business-Risiko abbilden.

• MFA für Remote Access und kritische Apps verpflichtend
• Privileged Access stärker als Standardzugriff
• Kontext nutzen: Standort, Device Compliance, Risikosignale
• Shared Accounts abbauen oder stark isolieren
• Least Privilege: Zugriff pro App statt pro Subnetz

Device Posture: Der häufigste blinde Fleck

Im VPN-Modell reicht oft Authentifizierung, um reinzukommen. Im Zero-Trust-Modell muss das Gerät Vertrauen verdienen. Typische Checks: OS-Version, Verschlüsselung, EDR, Compliance.

• Managed Devices: mehr Zugriff bei strenger Compliance
• Unmanaged/BYOD: Zugriff bewusst begrenzen oder zusätzliche Controls
• Veraltete OS-Versionen und riskante Konfigurationen blockieren
• EDR/MDM-Signale als Zugriffskriterium nutzen (nicht nur Monitoring)

Legacy Apps: Big-Bang vermeiden

Legacy ist der Hauptgrund, warum VPN „für immer“ bleibt. Migrieren Sie nach Applikationstyp, nicht nach Wunschbild.

• Quick Wins: Web Apps, Portale, interne Dashboards (zuerst)
• Mittel: RDP/SSH über kontrollierte Gateways mit Policies
• Schwer: Legacy-Protokolle und Thick Clients (isolieren, segmentieren, überwachen, Migrationsplan)

Wenn Modernisierung heute nicht geht, reduzieren Sie den Blast Radius: wer darf ran, von welchen Geräten, und alles sauber loggen.

Praktischer Plan: 30/60/90 Tage

Ziel ist Kontinuität: Nutzer können arbeiten, Support ist vorbereitet, Security wird messbar besser.

• Tag 0–30 (Design & Pilot): Inventar, Identity Readiness, Posture-Regeln, Pilotgruppe, Helpdesk-Schulung, Logging-Baseline
• Tag 31–60 (Quick Wins migrieren): Top Web Apps auf ZTNA, MFA + Posture enforce, App-Policies bauen, Ausnahmen dokumentieren
• Tag 61–90 (Skalieren & härten): Teams erweitern, Admin Access migrieren, VPN-Scope reduzieren, Legacy segmentieren, Break-Glass etablieren

Break-Glass & Business Continuity

Jedes Zero-Trust-Programm braucht einen sicheren Notfallpfad. Ohne ihn führt die erste Störung zu Panik und Policy-Rollbacks.

• Break-Glass-Accounts: minimal, streng kontrolliert, überwacht
• Recovery-Workflows: Geräteverlust, MFA-Reset, dringender Zugriff
• Zeitlich begrenzte Ausnahmen statt dauerhafter Downgrades
• Change Management: Freigaben für High-Risk-Zugriffsänderungen

Fortschritt beweisen: Metriken, die zählen

Sie brauchen Nachweise vor und nach dem Rollout – sonst bleibt Zero Trust ein Narrativ.

• Rückgang der VPN-Nutzung (Sessions, Bandbreite, Nutzer)
• Blockierte Sign-ins (Risk/Non-Compliance) und deren Ursachen
• Anzahl Apps mit per-App-Policies
• Reduzierung von broad network access (erreichbare Subnetze pro Rolle)
• Mean time to detect/contain verdächtige Zugriffe
• Helpdesk-Volumen: Passwort-Resets, VPN-Probleme (vorher/nachher)

Checklist: Wie eine „gute“ ZTNA-Policy aussieht

• Jede App hat Owner + klare Access Policy (nicht nur „VPN Users“)
• Privileged Access ist stärker und separat auditierbar
• Unmanaged Devices sind bewusst eingeschränkt
• Ausnahmen sind dokumentiert, befristet und werden reviewed
• Logs sind zentral, durchsuchbar und erklären Policy-Entscheidungen

Nützliche Referenzen

• NIST SP 800-207 (Zero Trust Architecture): https://csrc.nist.gov/publications/detail/sp/800-207/final
• CISA Zero Trust Maturity Model: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model
• Google BeyondCorp: https://cloud.google.com/beyondcorp
• Microsoft Zero Trust: https://www.microsoft.com/security/business/zero-trust

Fazit: Zero Trust ist ein sichereres Betriebsmodell – kein Disruption-Projekt

Die besten Zero-Trust-Migrationen sind „langweilig“ – im positiven Sinn. Sie stören das Business nicht, reduzieren den Blast Radius, machen Zugriffe auditierbar und verbessern die Security messbar Schritt für Schritt.

Wenn Sie ZTNA als kontrolliertes Programm umsetzen – Identität, Device Posture, per-App-Policies, Segmentierung und klare Metriken – verlassen Sie das VPN-Denken ohne Chaos und mit nachvollziehbarer Risikoreduktion.