Kaum eine Technologie hat den Fernzugriff so geprägt wie das VPN. Ein verschlüsselter Tunnel ins Firmennetz, und der Laptop im Homeoffice verhält sich, als stünde er im Büro. Über zwei Jahrzehnte war das die Antwort auf eine einfache Frage: Wie kommen Beschäftigte von außen sicher an interne Systeme? Genau dieses Versprechen wird im Zero-Trust-Modell zum Problem. Das VPN steht im Schatten von Zero Trust, und das aus guten Gründen. Wer verstehen will, warum, muss sich ansehen, was ein VPN technisch wirklich tut und welches Vertrauensmodell es dabei stillschweigend voraussetzt.
Wie ein VPN wirklich arbeitet
Technisch stellt ein Remote-Access-VPN einen verschlüsselten Tunnel zwischen Endgerät und einem Einwahlpunkt her, meist einer Appliance oder einem Konzentrator am Rand des Firmennetzes. Als Protokolle dienen klassisch IPsec oder TLS, moderner auch WireGuard. Nach dem Verbindungsaufbau bekommt das Gerät eine interne IP-Adresse samt Routen. Ab diesem Moment ist es Teil des Netzwerks: Es kann Subnetze erreichen, Dienste ansprechen und Namensauflösung nutzen wie ein Rechner im Büro.
Ob dabei der gesamte Datenverkehr durch den Tunnel läuft (Full Tunnel) oder nur der Verkehr Richtung Firmennetz (Split Tunnel), ist eine Konfigurationsfrage mit Nebenwirkungen. Full Tunnel schickt auch private Cloud- und Web-Nutzung durchs Rechenzentrum und kostet Performance. Split Tunnel entlastet die Leitung, nimmt dem Unternehmen aber die Sicht auf einen Teil des Verkehrs. Beide Varianten ändern nichts am Kern: Das VPN vermittelt Zugriff auf Netzebene. Es beantwortet die Frage „Darf dieses Gerät in dieses Netz?“, nicht die Frage „Darf diese Person jetzt, mit diesem Gerät, auf diese eine Anwendung?“.
Das Vertrauensmodell dahinter
Dieses Design stammt aus der Ära des Perimeters: außen gefährlich, innen vertrauenswürdig. Der Tunnel verlängert das vertrauenswürdige Innen bis ins Wohnzimmer. Wer die Einwahl schafft, hat den Vertrauensbeweis erbracht, und zwar einmalig, zu Beginn der Sitzung. Danach prüft in der Regel niemand mehr nach.
Zero Trust dreht diese Annahme um. Kein Nutzer, kein Gerät und kein Netzsegment gilt automatisch als vertrauenswürdig; jeder Zugriff wird einzeln bewertet, und die Bewertung gilt nicht für immer, sondern für genau diese Anfrage. Ein Modell, das nach erfolgreichem Login pauschal und dauerhaft vertraut, passt dazu strukturell nicht. Es lässt sich härten, mit MFA vor der Einwahl etwa, aber der Konstruktionsfehler bleibt: Die Prüfung findet am Anfang statt, das Vertrauen wirkt bis zum Ende der Sitzung.
Vier Schwächen, die sich nicht wegkonfigurieren lassen
Implizites Vertrauen nach dem Verbindungsaufbau. Steht der Tunnel, sind Nutzer und Gerät akzeptiert. Gestohlene Zugangsdaten, etwa aus einer Phishing-Kampagne, reichen damit für den Sprung ins Netz. In flachen Netzen beginnt dort die laterale Bewegung: vom ersten kompromittierten Konto über erreichbare Dateiserver bis zur Domänenverwaltung. Dazu kommt ein unbequemer Befund aus der Praxis: VPN-Gateways selbst sind beliebte Angriffsziele. Schwachstellen in verbreiteten Appliances standen in den vergangenen Jahren mehrfach am Anfang größerer Vorfälle, weil ein einziges ungepatchtes Gerät den Weg ins gesamte Netz öffnete. Die Komponente, die schützen soll, vergrößert die Angriffsfläche.
Identität und Gerätezustand bleiben unscharf. Ein klassisches VPN prüft Zugangsdaten, bestenfalls ein Client-Zertifikat. Ob das Gerät gepatcht ist, ob die Festplatte verschlüsselt ist, ob ein EDR-Agent läuft, ob es überhaupt ein Firmengerät ist: Diese Fragen bleiben offen. Für Dienstleister-Zugänge und private Geräte wiegt das doppelt, denn gerade dort ist der Gerätezustand am wenigsten kontrollierbar. Das VPN transportiert, statt zu bewerten.
Skalierung und Performance. Der Konzentrator ist ein physischer Engpass: begrenzte Lizenzen, begrenzte Bandbreite, begrenzte Rechenleistung für die Verschlüsselung. Solange die Anwendungen im eigenen Rechenzentrum liefen, war der Umweg über die Zentrale logisch. Heute liegen Mail, CRM und Kollaboration in der Cloud, und der Tunnel erzwingt einen Umweg: vom Homeoffice ins Rechenzentrum, von dort zur SaaS-Anwendung und zurück. Dieses Backhauling kostet Latenz und Nutzerzufriedenheit. Spätestens seit dem Frühjahr 2020 kennt fast jede IT-Abteilung das Muster, dass die VPN-Kapazität zum Flaschenhals der gesamten Remote-Arbeit wird.
Grobe Zugriffskontrolle, wenig Sichtbarkeit. Berechtigungen auf Netzebene heißen: Firewall-Regeln, IP-Bereiche, Portfreigaben. Den Zugriff einer einzelnen Rolle auf eine einzelne Anwendung abzubilden, wird damit schnell zur Pflege von Regelwerken, die niemand mehr vollständig versteht. Und die Protokolle des VPN zeigen Tunnelmetadaten, nicht Anwendungsaktionen. Wer wissen will, welcher Nutzer in welcher Anwendung was getan hat, schaut beim VPN in die falsche Datenquelle. Für die Erkennung von Anomalien fehlt schlicht das Material.
ZTNA: Zugriff pro Anwendung statt pro Netz
Die Alternative ist kein „besseres VPN“, sondern ein anderes Zugriffsmodell. ZTNA geht auf das Konzept des Software Defined Perimeter zurück, das die Cloud Security Alliance schon vor Jahren beschrieb. Die Architektur besteht aus einem Vermittler (Broker) und leichtgewichtigen Konnektoren vor den Anwendungen. Der entscheidende Kniff: Die Konnektoren bauen ausschließlich ausgehende Verbindungen zum Broker auf. Die Anwendungen selbst haben keine offenen eingehenden Ports und sind aus dem Internet nicht auffindbar. Was nicht sichtbar ist, lässt sich schlecht scannen und noch schlechter angreifen.
Der Zugriff läuft dann pro Anfrage: Der Broker prüft Identität (idealerweise mit MFA aus dem zentralen Identitätsanbieter), Gerätezustand, Standort und Kontext und entscheidet, ob genau diese Person genau diese Anwendung sehen darf. Alle anderen Anwendungen bleiben für sie unsichtbar. Die Bewertung endet nicht mit dem Login: Ändert sich der Kontext, etwa weil der EDR-Agent stoppt oder das Gerät aus dem Compliance-Zustand fällt, kann die Sitzung neu bewertet oder beendet werden. Aus „einmal drin, immer drin“ wird eine fortlaufende Entscheidung.
Wie fein sich kontextbasierte Autorisierung treiben lässt, zeigt abseits des Netzwerkzugriffs ein Werkzeug wie HashiCorp Vault: Zugriffsrichtlinien pro Rolle und Anwendung, kurzlebige statt statischer Zugangsdaten, lückenlose Auditierung. Dasselbe Denkmuster, angewandt auf Secrets statt auf Sitzungen, und ein guter Beleg dafür, dass Zero Trust ein Architekturprinzip ist und kein einzelnes Produkt.
VPN und ZTNA im direkten Vergleich
| Kriterium | Remote-Access-VPN | ZTNA |
|---|---|---|
| Zugriffsebene | Netz (IP, Routen, Subnetze) | einzelne Anwendung |
| Vertrauensprüfung | einmalig beim Verbindungsaufbau | pro Anfrage, fortlaufend neu bewertet |
| Gerätezustand | kaum berücksichtigt | Teil jeder Zugriffsentscheidung |
| Sichtbarkeit von außen | Gateway mit offenen Ports | Anwendungen unsichtbar, nur ausgehende Verbindungen |
| Verkehrsführung | Backhauling über die Zentrale | direkter Weg zur Anwendung |
| Protokollierung | Tunnelmetadaten | Nutzer, Gerät und Anwendung pro Zugriff |
Mikrosegmentierung als Innenseite derselben Idee
ZTNA regelt den Weg von außen nach innen. Bleibt die Frage, was passiert, wenn doch einmal etwas durchkommt, über eine Schwachstelle, einen Innentäter oder ein kompromittiertes Dienstkonto. Hier setzt Mikrosegmentierung an: Sie unterteilt das Netz in streng abgeschottete Segmente bis hinunter auf Workload-Ebene und erlaubt nur die Kommunikation, die ein Dienst nachweislich braucht. Einem Angreifer nimmt das genau die Bewegungsfreiheit, die ein flaches Netz hinter dem VPN-Tunnel bietet. Beides zusammen, anwendungsbezogener Zugriff von außen und Segmentierung im Inneren, ist der technische Kern von Zero Trust.
Der realistische Übergang
Kaum ein Unternehmen schaltet sein VPN an einem Stichtag ab, und das muss auch niemand. Bewährt hat sich ein Vorgehen in Etappen:
- Bestandsaufnahme: Welche Anwendungen erreichen Beschäftigte heute über das VPN, wer nutzt sie, wie kritisch sind sie? Ohne dieses Inventar wird jede Migration zum Blindflug.
- Pilot mit klarem Schnitt: Eine überschaubare Nutzergruppe und zwei, drei web-basierte Anwendungen hinter ZTNA nehmen. Webanwendungen sind der dankbarste Startpunkt, weil sie ohne Client-Sonderfälle auskommen.
- Koexistenz mit Richtung: Neue Anwendungen grundsätzlich hinter ZTNA veröffentlichen, Bestandsanwendungen Welle für Welle nachziehen. Das VPN bleibt übergangsweise für den Rest, wird aber sichtbar kleiner.
- Rückbau: Wenn nur noch wenige Legacy-Fälle übrig sind, lohnt der ehrliche Blick: Braucht dieser Dienst wirklich Netzzugriff, oder ist sein Lebensende ohnehin absehbar?
Ein paar Stolpersteine gehören auf den Zettel. Anwendungen mit serverinitiierten Verbindungen, alte Fat Clients und exotische Protokolle brauchen Sonderbehandlung. Fernwartung durch Dritte gehört früh auf die ZTNA-Liste, weil dort Identitäts- und Geräteprüfung den größten Sicherheitsgewinn bringt. Und die Kopplung ganzer Standorte war nie die Stärke des Remote-Access-VPN; sie ist im Managed SD-WAN besser aufgehoben. Wer den Aufbau des Zugriffsmodells nicht selbst stemmen will, bezieht Zero-Trust-Zugriff als Managed SASE/SSE-Service und lässt die Segmentierung im Inneren gleich mitplanen.
Das VPN verschwindet damit nicht über Nacht. Es rückt nur dorthin, wo es inzwischen hingehört: in den Schatten.
Passende Managed Services
- SASE/SSE – ZTNA, Secure Web Gateway und DLP als Managed Service, der klassische VPN-Zugänge schrittweise ablöst.
- Mikrosegmentierung – Sichtbarkeit und Least-Privilege-Regeln bis auf Workload-Ebene gegen laterale Bewegung.
- Managed SD-WAN – sichere Standortvernetzung, die Site-to-Site-VPNs ablöst.