VPN oder ZTNA? Sophos ZTNA und Conditional Access im Zusammenspiel

Sophos ZTNA vs. VPN — so steht die Frage meist im Suchfeld, aber so gestellt ist sie schon halb falsch. Die Kurzantwort vorab: ZTNA und das klassische VPN lösen dieselbe Aufgabe — Zugriff von außen auf interne Ressourcen — auf verschiedenen Ebenen: Das VPN gewährt Netzzugang, ZTNA vermittelt Anwendungszugriff, geprüft je Zugriff anhand von Identität, Gerätezustand und Richtlinie. Und Conditional Access, die Microsoft-Seite der Medaille, macht für M365 und SaaS längst genau das, was ZTNA für private Anwendungen tut. Die eigentliche Kunst liegt im Zusammenspiel: Wer beide Welten versteht, baut eine Architektur mit einer Identität und einer Policy-Logik — statt doppelter Kontrollen an der einen und Lücken an der anderen Stelle. Dieser Artikel erklärt, warum das VPN in die Kritik geraten ist, wie Sophos ZTNA funktioniert, was Conditional Access beisteuert, wie beides ineinandergreift — und wie die Migration ohne Big Bang gelingt.

Warum das klassische VPN in die Kritik geraten ist

Zunächst Gerechtigkeit für den Angeklagten: Das VPN hat drei Jahrzehnte lang zuverlässig geliefert und tut es — mit MFA gehärtet — weiterhin. Die Kritik zielt nicht auf die Verschlüsselung, sondern auf das Vertrauensmodell dahinter. Ein VPN prüft einmal, beim Tunnelaufbau: Wer bist du? Danach steht der Tunnel, oft stundenlang, und der Benutzer ist im Netz — mit allem, was das Segment hergibt. Die Firewall-Regeln begrenzen den Radius, aber das Grundprinzip bleibt: Der Netzwerkstandort »drinnen« gilt als Vertrauensbeweis. Genau dieses Prinzip haben die Vorfälle der letzten Jahre demontiert: Kompromittierte Endgeräte bringen den Angreifer durch den legitimen Tunnel mit hinein, gestohlene Zugangsdaten machen ihn zum scheinbaren Mitarbeiter, und einmal drin, beginnt die Seitwärtsbewegung — vom VPN-Segment zum Dateiserver, vom Dateiserver zum Domain Controller.

Dazu kommen die Alltagsprobleme: Dienstleister bekommen für eine einzige Wartungsanwendung einen Netztunnel, dessen tatsächliche Reichweite niemand mehr genau kennt; private Geräte im Homeoffice bringen ihren ungeprüften Zustand mit in den Tunnel; und die VPN-Konzentratoren selbst sind als exponierte Angriffsfläche in den letzten Jahren unangenehm oft in Schwachstellenmeldungen aufgetaucht — quer durch alle Hersteller. Die Antwort der Branche heißt Zero Trust: Vertraue keinem Netzwerkstandort, prüfe jeden Zugriff. Wichtig für die Praxis-Reihenfolge: Nichts davon macht das MFA-gehärtete VPN aus dem vorigen Artikel [LINK: B2] überflüssig — es macht es zur Etappe. Erst die offene Tür schließen, dann die Architektur modernisieren.

ZTNA-Funktionsweise bei Sophos

Zero Trust Network Access dreht das Zugriffsmodell um: Statt eines Tunnels ins Netz vermittelt ein Broker den Zugriff auf einzelne, definierte Anwendungen — und prüft dabei jedes Mal drei Dinge: die Identität (wer?), den Gerätezustand (womit?) und die Richtlinie (darf der das?). Bei Sophos besteht die Lösung aus drei Bausteinen. Erstens der ZTNA-Agent auf dem Endgerät — praktischerweise in den Sophos-Endpoint-Agenten integriert, wer also Intercept X im Einsatz hat, rollt keine zweite Software aus; für reine Web-Anwendungen geht es auf Wunsch sogar agentenlos über den Browser. Zweitens das ZTNA-Gateway, das vor den Anwendungen sitzt und die vermittelten Verbindungen terminiert — als virtuelle Maschine, in der Cloud, oder am elegantesten: direkt integriert auf der XGS-Firewall, ohne zusätzliche Hardware. Drittens die Verwaltung über Sophos Central, wo Anwendungen, Richtlinien und Benutzergruppen definiert werden.

Der Clou steckt in zwei Details. Detail eins: Als Identitätsanbieter dient Entra ID — die ZTNA-Anmeldung läuft also über login.microsoftonline.com, mit allem, was dort hängt: MFA, Conditional Access, Offboarding, Sign-in-Logs. Detail zwei: der Security Heartbeat. Das ZTNA-Gateway kennt den Gesundheitszustand des Sophos-Endpoints in Echtzeit — meldet der Endpoint eine aktive Bedrohung, wechselt der Heartbeat auf Rot, und der nächste Anwendungszugriff wird schlicht verweigert, bis das Gerät bereinigt ist. Vertrauen ist damit nicht nur fein granular, sondern widerruflich — der fundamentale Unterschied zum Tunnel, der offen bleibt, bis ihn jemand kappt. Die erste Skizze stellt genau diese Frage in den Mittelpunkt: Wann wird eigentlich geprüft?

Skizze 1: Das VPN prüft einmal beim Aufbau — ZTNA bei jedem Anwendungszugriff, mit dem Gerätezustand als laufendem Mitentscheider.

Conditional Access: die Microsoft-Seite der Medaille

Wer Microsoft 365 betreibt, hat das Zero-Trust-Prinzip längst im Haus — es heißt dort Conditional Access und ist die Richtlinien-Maschine hinter jeder Entra-Anmeldung. Das Funktionsprinzip: Bei jeder Anmeldung sammelt Entra ID Signale — wer meldet sich an, an welcher Anwendung, von welchem Gerät (verwaltet? konform?), von welchem Standort, mit welchem Risikoprofil — und die Richtlinien übersetzen diese Signale in Entscheidungen: Zugriff gewähren, MFA verlangen, nur mit konformem Gerät, oder blockieren. Für die Cloud-Welt ist das exakt die ZTNA-Logik: Zugriff je Anwendung, geprüft anhand von Identität, Gerät und Kontext. Deshalb die vielleicht wichtigste Botschaft dieses Artikels: Für M365 und SaaS brauchst du kein ZTNA-Produkt — Conditional Access ist dort bereits das ZTNA, und der Verkehr dorthin gehört auch nicht durchs VPN geschleift, sondern direkt ins Internet.

Was Conditional Access nicht kann: die private Anwendungswelt. Das ERP auf dem Server im Keller, das DMS, der RDP-Host — die melden sich nicht bei Entra ID an, also kann keine Richtlinie greifen. Genau diese Lücke füllt ZTNA: Es zieht die privaten Anwendungen in die Entra-Anmeldewelt hinein, indem der Zugriff über den Broker läuft, der sich seinerseits die Identität von Entra bestätigen lässt — inklusive aller Conditional-Access-Prüfungen. Der Vollständigkeit halber gehört gesagt: Microsoft hat mit Entra Private Access inzwischen ein eigenes ZTNA im Portfolio, das denselben Ansatz verfolgt. Die Sophos-Variante punktet in XGS-Umgebungen mit zwei Argumenten — dem Gateway ohne Zusatzhardware auf der Firewall und dem Security Heartbeat als Gerätezustands-Signal, das tiefer blickt als der Intune-Konformitätsstatus. Wer beide Welten evaluiert, sollte beide Argumente gegen die eigene Lizenzlage halten.

Zusammenspiel und Abgrenzung: Sophos ZTNA vs. VPN und Conditional Access

Jetzt das Gesamtbild, und es ist erfreulich aufgeräumt: Eine Identität, zwei Pfade. Für Microsoft 365 und SaaS gehen die Benutzer direkt ins Internet — Conditional Access prüft bei der Anmeldung, kein Tunnel weit und breit; das entlastet nebenbei die Firewall und deckt sich mit Microsofts Konnektivitätsprinzipien. Für private Anwendungen vermittelt ZTNA — die Anmeldung läuft über dieselbe Entra-Identität mit denselben Conditional-Access-Richtlinien, ergänzt um den Heartbeat als Sophos-spezifisches Gerätesignal, und das Gateway auf der XGS öffnet exakt die freigegebene Anwendung. Das VPN schließlich schrumpft zur Spezialwerkzeug-Rolle: breiter, protokolloffener Netzzugriff für Administratoren und die dokumentierten Fälle, die kein App-Modell abbildet — MFA-gesichert und mit bewusst kleinem Radius. Die Architektur-Skizze zeigt beide Pfade; die Entscheidungsmatrix danach übersetzt sie in die Frage, die im Projekt wirklich gestellt wird: Welcher Anwendungstyp läuft worüber?

Skizze 2: Cloud-Dienste direkt mit Conditional Access, private Apps über ZTNA — beide Pfade durch dieselbe Entra-Anmeldung, keine doppelte Policy-Welt.

Migrationsstrategie: VPN schrittweise ablösen

Der häufigste Fehler bei ZTNA-Projekten ist der Versuch, das VPN an einem Stichtag abzuschalten — der zweithäufigste, nie anzufangen, weil der Stichtag so unmöglich wirkt. Der gangbare Weg dazwischen: das VPN aushungern statt abschalten. Phase null ist dabei keine ZTNA-Phase, sondern Pflicht davor: das bestehende VPN mit Entra-MFA härten (siehe [LINK: B2]), denn die offene Tür schließt man vor dem Umbau, nicht währenddessen. Phase eins ist die App-Inventur — und hier lohnt Ehrlichkeit mit den eigenen Logs: Welche Ziele werden über das VPN tatsächlich angesprochen, von wem, wie oft? Das Ergebnis überrascht fast immer (dazu gleich der Praxis-Kasten) und liefert die Priorisierung frei Haus: Die fünf meistgenutzten Anwendungen plus sämtliche Dienstleister-Zugänge sind die Pilotkandidaten mit dem größten Gewinn.

Phase zwei baut das Fundament — ZTNA in Sophos Central einrichten, das Gateway auf der XGS aktivieren, Entra als Identitätsanbieter anbinden, die Conditional-Access-Richtlinien auf die neuen Apps ausdehnen. Phase drei pilotiert mit den Kandidaten aus der Inventur, allen voran den externen Zugängen: Der Dienstleister, der bisher einen Netztunnel hatte und künftig genau seine Wartungsanwendung sieht, ist der schnellste vorzeigbare Sicherheitsgewinn des ganzen Projekts. Phase vier zieht in Wellen die Benutzergruppen um — und hier steckt die entscheidende Disziplin: Mit jedem Umzug wird die VPN-Berechtigung der Gruppe tatsächlich entzogen, nicht »sicherheitshalber« belassen. Am Ende steht Phase fünf, das Zielbild: ZTNA für die Benutzer, ein kleines, MFA-gesichertes Rest-VPN für Administration und dokumentierte Legacy-Fälle. Der Zeitstrahl fasst die Reise zusammen, die Tabelle hängt Meilensteine dran.

Skizze 3: Fünf Phasen vom gehärteten VPN zum ZTNA-Schwerpunkt — der VPN-Radius schrumpft mit jeder Welle.

FAQ — häufige Fragen zu Sophos ZTNA, VPN und Conditional Access

Ersetzt ZTNA das VPN vollständig?

Für die meisten Benutzer: ja, und zwar besser. Für die Umgebung als Ganzes: fast nie zu hundert Prozent — und das ist in Ordnung. ZTNA deckt den Anwendungszugriff ab: Web-Apps, RDP, SSH und generell TCP-basierte Anwendungen, die sich als definierte Ressource fassen lassen. Was übrig bleibt, sind die breiten Fälle: Administratoren, die protokolloffen ins Netz müssen, Netzwerk-Troubleshooting, und die Legacy-Ecke mit Anwendungen, die kein App-Modell abbildet. Für diesen Rest bleibt ein kleines VPN bestehen — MFA-gesichert, mit eng geschnittenen Regeln und dokumentierten Berechtigungen, idealerweise jährlich rezertifiziert. Das realistische Zielbild heißt also nicht »VPN abgeschaltet«, sondern »VPN geschrumpft auf den begründeten Rest« — und genau daran lässt sich der Projekterfolg auch messen: an der Zahl der Konten, die den Netztunnel noch brauchen.

Brauche ich ZTNA, wenn ich Conditional Access habe?

Kommt darauf an, wo deine Anwendungen wohnen. Conditional Access ist die Zero-Trust-Maschine für alles, was sich bei Entra ID anmeldet — Microsoft 365, SaaS-Dienste, per SSO angebundene Cloud-Anwendungen. Dort brauchst du kein zusätzliches ZTNA-Produkt; die Richtlinien prüfen Identität, Gerät und Kontext bereits bei jeder Anmeldung. Die Lücke beginnt bei den privaten Anwendungen: Das ERP im eigenen Rechenzentrum, das DMS, der RDP-Host kennen Entra ID nicht — für sie greift keine Richtlinie, und genau diese Lücke füllt ZTNA, indem es den Zugriff über einen Broker leitet, der sich die Identität von Entra bestätigen lässt. Die Faustregel: nur Cloud-Anwendungen → Conditional Access reicht; private Anwendungen im Spiel → ZTNA ergänzt die Richtlinienwelt dorthin, wo sie allein nicht hinkommt. Doppelt kontrolliert wird dabei nichts — beide Pfade nutzen dieselbe Anmeldung.

Welche Lizenzen brauche ich für Sophos ZTNA?

Drei Posten, von denen zwei oft schon bezahlt sind. Erstens die ZTNA-Lizenz selbst: pro Benutzer und Jahr, bezogen und verwaltet über Sophos Central — sie ist ein eigenständiges Produkt und ausdrücklich nicht in der Xstream-Subscription der Firewall enthalten. Zweitens die Infrastruktur, und hier wird es freundlich: Das Gateway läuft ohne Zusatzkosten direkt auf der XGS (oder als VM/Cloud-Instanz), und der Agent steckt im regulären Sophos-Endpoint-Agenten — mit Intercept X im Haus entfällt jeder zusätzliche Rollout. Drittens die Microsoft-Seite: Entra ID als Identitätsanbieter, für Conditional-Access-Richtlinien in der P1-Ausbaustufe, die in Microsoft 365 Business Premium und den Enterprise-Plänen bereits steckt. Preisstände ändern sich — die konkrete Kalkulation gehört mit dem Distributor gerechnet, aber die Struktur bleibt: Die Benutzerlizenz ist der laufende Posten, der Rest ist meist vorhanden.

Funktioniert ZTNA für RDP und Legacy-Anwendungen?

Für RDP: ja, und sogar besonders gut — der Zugriff auf definierte RDP-Hosts über den ZTNA-Agenten ist einer der dankbarsten Anwendungsfälle, weil das zugreifende Gerät per Heartbeat geprüft wird und der Host aus dem Netz verschwindet, statt als erreichbares Ziel herumzustehen; für größere Terminalserver- und AVD-Landschaften gelten eigene Spielregeln, die der Artikel zu RDS und AVD [LINK: B11] behandelt. Auch SSH und generell TCP-basierte Anwendungen mit klarem Ziel funktionieren sauber über den Agenten; reine Web-Anwendungen gehen sogar agentenlos. Ehrlich wird es bei der echten Legacy-Ecke: Anwendungen mit wilden dynamischen Ports, UDP-Eigenbau-Protokollen oder Server-zu-Client-Rückverbindungen sperren sich gegen das App-Modell — die bleiben Kandidaten für das geschrumpfte Rest-VPN, dokumentiert und mit Ablösedatum versehen. Die Inventur-Phase klärt vorab, wer in welche Schublade gehört; unangenehme Überraschungen gibt es fast nur ohne sie.

Wie starte ich die Migration ohne Big Bang?

Mit einer Reihenfolge, die den Druck rausnimmt: Erst das bestehende VPN mit Entra-MFA härten — damit ist das akute Risiko vom Tisch und die Migration darf sich Zeit nehmen. Dann die App-Inventur aus den Firewall-Logs: Was wird über das VPN wirklich genutzt, von wem, wie oft? Typisch decken drei bis fünf Anwendungen achtzig Prozent der Zugriffe ab — das ist deine Pilotliste, ergänzt um sämtliche Dienstleister-Zugänge, die den schnellsten Sicherheitsgewinn liefern. Danach Fundament (Gateway auf der XGS, Entra als IdP), Pilot, und Wellen: Gruppe für Gruppe umziehen, und mit jedem Umzug die VPN-Berechtigung tatsächlich entziehen — das ist der Schritt, der aus einem Parallelbetrieb eine Migration macht. Realistischer Horizont für einen Mittelständler: sechs bis zwölf Monate bis zum Zielbild, ohne dass je ein Stichtag-Drama nötig wäre. Das VPN wird nicht abgeschaltet, es wird ausgehungert.

Was passiert mit Site-to-Site-Verbindungen?

Kurz: nichts — und das ist die richtige Antwort. ZTNA regelt den Zugriff von Benutzern auf Anwendungen; Site-to-Site-Tunnel verbinden Standorte auf Geräteebene, authentifiziert über Zertifikate oder Pre-Shared Keys zwischen den Firewalls, ganz ohne Benutzerkontext. Diese Verbindungen bleiben von der ZTNA-Einführung unberührt und laufen als IPsec-Kopplung weiter wie gehabt — ihre Härtung (starke Schlüssel, besser Zertifikate, saubere Zonen- und Regelarchitektur für den Standortverkehr) ist Thema des Multi-Site-Artikels [LINK: A1]. Eine indirekte Berührung gibt es trotzdem, und sie ist erfreulich: Wenn Dienstleister und Heimarbeitsplätze von Netztunneln auf ZTNA umziehen, schrumpft die Zahl der benutzerbezogenen Tunnel deutlich — übrig bleibt die aufgeräumte Welt aus Standort-Kopplungen einerseits und App-Vermittlung andererseits, und beides hat klar getrennte Zuständigkeiten. Verwechslungsgefahr besteht nur auf Folien, nicht in der Konfiguration.

Fazit: Nicht VPN gegen ZTNA — sondern jede Kontrolle an ihren Platz

Die Ausgangsfrage »VPN oder ZTNA?« löst sich bei genauem Hinsehen in eine Arbeitsteilung auf: Conditional Access ist das Zero Trust der Cloud-Welt und längst im Haus; ZTNA verlängert dieselbe Logik zu den privaten Anwendungen — mit der Entra-Identität als gemeinsamem Fundament und dem Security Heartbeat als Sophos-Bonus; und das VPN schrumpft zum Spezialwerkzeug für Administration und dokumentierte Ausnahmen, MFA-gesichert und klein. Wer diese Arbeitsteilung baut, bekommt genau das, was die Kernbotschaft verspricht: keine doppelten Kontrollen, keine Lücken — und eine Migration, die als Aushungern funktioniert statt als Stichtag. Der Weg dorthin beginnt unspektakulär: Logs lesen, Inventur machen, mit den Dienstleister-Zugängen anfangen. Der Rest ist Fleiß in Wellen.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Die Pflicht-Etappe vor jeder Migration — das VPN mit Entra-MFA härten — steht in [LINK: B2]. Wie Conditional Access, Entra ID und die Identitätslandschaft insgesamt zusammenspielen, vertieft der Entra-ID-Pillar [LINK: Entra-ID-Pillar]. Und für den dankbarsten ZTNA-Anwendungsfall jenseits einzelner RDP-Hosts — Terminalserver- und AVD-Landschaften — lohnt der Blick in [LINK: B11].