Zero Trust Network Access
Identitätsbasiertes Zugriffsmodell, das Anwendungen einzeln absichert und den klassischen VPN-basierten Netzwerkzugang durch granulare, kontextabhängige Zugriffskontrolle ersetzt.
Zero Trust Network Access (ZTNA) ist ein Sicherheitsmodell, das den Zugriff auf Unternehmensanwendungen nicht mehr über Netzwerkzugehörigkeit gewährt, sondern über die Identität des Nutzers, den Zustand des Geräts und den Kontext der Anfrage. Statt einem Benutzer nach VPN-Einwahl Zugang zum gesamten Netzwerk zu geben, vermittelt ZTNA den Zugriff auf einzelne Anwendungen — nach dem Prinzip des Least Privilege. ZTNA ist eine Kernkomponente der SASE-Architektur und die technische Umsetzung des Zero-Trust-Prinzips auf Netzwerkebene.
Wie ZTNA funktioniert
Bei ZTNA verbindet sich der Benutzer nicht mit einem Netzwerk, sondern mit einem Trust Broker — einem Vermittlungsdienst, der Identität und Gerätekontext prüft, bevor er den Zugriff auf eine spezifische Anwendung freigibt. Die Anwendung selbst ist aus dem Internet nicht direkt erreichbar und wird erst nach erfolgreicher Authentifizierung und Autorisierung sichtbar. Dieses Prinzip wird als Software-Defined Perimeter oder Dark Cloud bezeichnet: Was man nicht sehen kann, kann man nicht angreifen.
Die Zugriffsentscheidung berücksichtigt mehrere Faktoren gleichzeitig: Ist der Benutzer per MFA authentifiziert? Erfüllt das Gerät die Compliance-Richtlinien (aktuelles Betriebssystem, aktiver EDR-Agent)? Ist der Zugriffskontext plausibel (Standort, Uhrzeit, Risikolevel)? Nur wenn alle Bedingungen erfüllt sind, wird der Zugriff gewährt — und das bei jeder einzelnen Sitzung erneut.
ZTNA vs. VPN
| Kriterium | Klassisches VPN | ZTNA |
|---|---|---|
| Zugriffsmodell | Netzwerkweit nach Einwahl | Pro Anwendung, kontextbasiert |
| Sichtbarkeit | Gesamtes Netzwerk erreichbar | Nur freigegebene Anwendungen |
| Authentifizierung | Einmalig bei Verbindungsaufbau | Kontinuierlich, kontextabhängig |
| Laterale Bewegung | Möglich nach Kompromittierung | Stark eingeschränkt |
| Skalierung | Engpass am VPN-Konzentrator | Cloud-nativ, elastisch |
| Benutzererfahrung | Split-Tunnel-Probleme, Latenz | Transparenter Zugriff |
In der Praxis sehen wir, dass VPN-Infrastrukturen nach einer Kompromittierung regelmäßig als Einfallstor für laterale Bewegung dienen — genau das Problem, das ZTNA architektonisch löst.
ZTNA-Architekturen
Es gibt zwei grundlegende ZTNA-Ansätze: Agent-basiert und Service-basiert. Beim Agent-basierten Modell läuft ein Client auf dem Endgerät, der den Gerätekontext erfasst und den verschlüsselten Tunnel zum Trust Broker aufbaut. Beim Service-basierten Modell erfolgt der Zugriff über den Browser ohne installierten Agent — ideal für BYOD-Szenarien und externe Partner. Viele Anbieter wie Zscaler Private Access, Cloudflare Access oder Microsoft Entra Private Access unterstützen beide Modelle parallel.
ZTNA und Compliance
Die NIS2-Richtlinie fordert Zugriffskontrollen und Netzwerksegmentierung — ZTNA erfüllt beide Anforderungen, da es den Zugriff granular steuert und das Netzwerk durch Anwendungsisolation segmentiert. Auch ISO 27001 verlangt eine risikobasierte Zugriffssteuerung, die ZTNA durch kontextabhängige Policies direkt abbildet. In Kombination mit Conditional Access entsteht eine lückenlose Zugriffskontrolle, die sowohl technische als auch regulatorische Anforderungen erfüllt.
Relevanz für KMUs
ZTNA ist für den Mittelstand besonders attraktiv, weil es bestehende VPN-Infrastruktur schrittweise ablösen kann, ohne einen Big-Bang-Umstieg zu erfordern. Cloud-basierte Lösungen wie Cloudflare Access oder Microsoft Entra Private Access erfordern keine eigene Infrastruktur und skalieren mit dem Unternehmen. Der pragmatische Einstieg beginnt mit den kritischsten internen Anwendungen — etwa ERP- oder Finanzsystemen — die zuerst auf ZTNA migriert werden, während weniger kritische Systeme vorerst über das bestehende VPN erreichbar bleiben. In Assessments finden wir regelmäßig, dass bereits dieser erste Schritt die Angriffsfläche erheblich reduziert.