Was ist ZTNA? Zero Trust Network Access erklärt

Souveränen Zero-Trust-Zugriff aufbauen? WZ-IT baut self-hosted ZTNA-Plattformen für verteilte Standorte, Remote-Teams und OT. Zur Remote-Management-Plattform

ZTNA (Zero Trust Network Access) gewährt Zugriff pro Anwendung oder Ressource - auf Basis von Identität, Gerätezustand und Kontext - statt wie ein klassisches VPN Zugriff auf das ganze Netz zu geben. Das Leitprinzip ist default-deny: Nichts ist erreichbar, bis eine Policy es ausdrücklich erlaubt. Ein Policy-Broker prüft jede Anfrage vor dem Verbindungsaufbau gegen die Identität (über einen Identity Provider), den Gerätezustand und Kontextfaktoren wie Standort oder Uhrzeit. ZTNA ist die praktische Umsetzung der Zero Trust Architecture, wie sie NIST SP 800-207 (2020) beschreibt: kein implizites Vertrauen aufgrund von Netzposition.

Inhaltsverzeichnis

• Die Prinzipien von Zero Trust
• Wie ZTNA funktioniert
• ZTNA vs. VPN im Vergleich
• Souveränes, self-hosted ZTNA aufbauen
• Einsatz: Remote-Workforce und OT
• Anbieter und der EU-Angle
• ZTNA bei WZ-IT
• Weiterführende Guides

---

Die Prinzipien von Zero Trust

Zero Trust verschiebt die Verteidigung vom statischen Netzperimeter hin zu Nutzern, Geräten und einzelnen Ressourcen. Die NIST-Definition ist klar: keinem Asset oder Konto wird allein aufgrund seiner physischen oder Netzposition vertraut. Daraus folgen vier Kernprinzipien:

• Never trust, always verify: Jede Anfrage wird neu geprüft, unabhängig davon, ob sie aus dem Büro-LAN oder dem Internet kommt. Es gibt kein "vertrauenswürdiges internes Netz".
• Least Privilege: Identitäten erhalten nur den minimal nötigen Zugriff, pro Sitzung und pro Ressource - nicht pauschal das ganze Subnetz.
• Mikrosegmentierung: Ressourcen werden einzeln abgeschottet. Wer auf eine Anwendung zugreifen darf, sieht deshalb noch lange nicht die Nachbarsysteme.
• Kein implizites Netzvertrauen: Das Netz gilt grundsätzlich als kompromittiert. Authentifizierung und Autorisierung von Nutzer und Gerät finden vor jeder Sitzung statt.

Der unmittelbare Sicherheitsgewinn ist die Eindämmung lateraler Bewegung: Selbst wenn ein Gerät kompromittiert wird, erreicht der Angreifer nur die explizit freigegebene Ressource statt das flache Netz.

Wie ZTNA funktioniert

ZTNA setzt diese Prinzipien mit drei zusammenspielenden Bausteinen um:

• Policy Decision/Enforcement Point (Broker): Eine zentrale Steuerungsebene entscheidet pro Anfrage, ob ein Zugriff erlaubt ist, und setzt diese Entscheidung möglichst nah an der Ressource durch. Sie wertet Identität, Gerätezustand (Posture) und Kontext aus.
• Identität über einen IdP: Die Identitätsprüfung lagert ZTNA an einen Identity Provider aus, angebunden per OIDC/OAuth2 - mit SSO und MFA. So gilt überall dieselbe, zentral verwaltete Identität.
• Outbound-only, kein offener Inbound: Ein Connector oder Agent am Standort baut die Verbindung aktiv nach außen zum Broker auf. Dienste bleiben "dark" und sind aus dem Internet nicht erreichbar; es muss kein Port aus dem Internet geöffnet werden. Das verkleinert die Angriffsfläche drastisch.

Zwei Zugriffsmuster sind üblich: agentenbasiert (ein Client auf dem Endgerät bringt den Nutzer ins identitätsbasierte Overlay - typisch für Infrastruktur- und Server-Zugriff) und serviceinitiiert/clientlos (Zugriff auf eine Web-App über einen Identity-aware Proxy im Browser, ganz ohne Client am Endgerät).

ZTNA vs. VPN im Vergleich

Ein klassisches VPN authentifiziert einmal beim Login und vertraut dem Gerät danach im Netz - mit breitem Zugriff. ZTNA prüft kontinuierlich und gibt nur einzelne Anwendungen frei. Gartner prognostizierte, dass bis 2025 mindestens 70 % der neuen Fernzugriffs-Deployments überwiegend über ZTNA statt klassischem VPN laufen - gegenüber unter 10 % Ende 2021 (Gartner Market Guide for Zero Trust Network Access, 2022).

ZTNA ersetzt das VPN dabei nicht zwingend über Nacht. Gartner rät zum schrittweisen Umstieg, oft beginnend mit externen Dienstleistern und einzelnen Nutzergruppen.

Souveränes, self-hosted ZTNA aufbauen

ZTNA ist kein Produkt eines einzelnen Anbieters, sondern ein Architekturmuster - und genau deshalb lässt es sich vollständig aus quelloffenen, self-hostbaren Bausteinen aufbauen. Ein bewährter Stack:

• NetBird als identitätsbasiertes WireGuard-Overlay: Es verbindet Geräte, Server und Standorte default-deny, mit Access Policies, Mikrosegmentierung und Posture Checks (OS-Version, Client-Version, Standort). Die gesamte Control Plane ist self-hostbar. Details im Leitfaden Was ist NetBird? und auf unserer NetBird-Expertise.
• IdP für Identität: Authentik oder Keycloak liefern SSO und MFA per OIDC. Damit kommt die "verify"-Komponente aus eigener Hand - die zentrale Identitätsquelle für alle Policies.
• Pangolin für clientlosen App-Zugriff: Der identity-aware Reverse-Proxy veröffentlicht interne Web-Anwendungen browserbasiert, mit Authentifizierung vor der App und Zugriff nur auf explizit freigegebene Dienste. Die Community Edition ist quelloffen unter AGPL-3.0 (eine kostenpflichtige Enterprise Edition läuft unter der Fossorial Commercial License) - siehe Pangolin-Expertise und der Guide interne Dienste ohne VPN veröffentlichen.

Diese Kombination deckt beide Zugriffsmuster ab: agentenbasiert für Infrastruktur (NetBird) und clientlos für Web-Apps (Pangolin), beides identitätsgebunden über denselben IdP. Steuerungsebene, Schlüssel und Audit-Daten bleiben in der EU.

Einsatz: Remote-Workforce und OT

Zwei Szenarien profitieren besonders. Bei der Remote-Workforce lösen sich Mitarbeiter und externe Dienstleister vom Full-Tunnel-VPN: Statt jedem das gesamte Firmennetz zu öffnen, erhält jede Identität nur die Anwendungen, die sie braucht. Externe Auftragnehmer sind ein klassischer Einstiegspunkt, weil ihr Zugriff besonders risikobehaftet ist.

In der OT (Operational Technology) ist Mikrosegmentierung der Schlüssel. Produktionsanlagen, Maschinen und IoT-Geräte laufen historisch in flachen, schwach segmentierten Netzen. ZTNA bricht das auf: Ein Techniker erreicht pro Identität nur die freigegebene Maschine oder HMI, nie das gesamte Anlagennetz. Standorte binden sich outbound-only an, ohne offene Ports, und jeder Zugriff ist auditierbar. Genau dieser Schritt - weg vom flachen VPN, hin zu identitätsbasiertem Pro-Ressource-Zugriff - ist der zentrale Trend im sicheren Fernzugriff und relevant für regulatorische Anforderungen wie die NIS2-Richtlinie. Dieser Beitrag ist allgemeine Information und keine Rechtsberatung.

Anbieter und der EU-Angle

Den ZTNA-Markt prägen große, meist cloud-basierte Plattformen: Zscaler Private Access, Cloudflare Access und Palo Alto Prisma Access. Sie sind ausgereift, binden den Zugriff aber an die Cloud des Anbieters - Identitäts-, Verbindungs- und Audit-Daten laufen über deren Infrastruktur, häufig außerhalb der EU.

Für souveränitäts- und regulierungssensible Umgebungen ist das self-hosted Modell die Alternative: derselbe Zero-Trust-Ansatz, aber mit quelloffenen Bausteinen (NetBird, Pangolin, Authentik/Keycloak) vollständig in eigener Infrastruktur in der EU. Sie behalten die Kontrolle über Schlüssel, Policies und Logs - ohne funktionale Abstriche beim Zero-Trust-Modell.

ZTNA bei WZ-IT

Bei WZ-IT bauen wir ZTNA als souveräne, self-hosted Plattform: NetBird als verschlüsseltes, identitätsbasiertes Netz-Backend, ein IdP wie Authentik für SSO/MFA, Pangolin oder ein Browser-Gateway für clientlosen App- und Maschinenzugriff - alles default-deny und auditierbar. Standorte werden outbound-only angebunden, ohne offene Ports. Wie das produktiv für verteilte Anlagen aussieht, zeigt die Case Study ABCO Water Systems in Australien. Konzeption, Aufbau und Betrieb übernehmen wir auf Wunsch komplett im Rahmen unserer Remote-Management-Plattformen.

Weiterführende Guides

• Was ist NetBird? - identitätsbasiertes Overlay als ZTNA-Backend
• Interne Dienste ohne VPN veröffentlichen - clientloser App-Zugriff
• NIS2-konformer Fernzugriff - Regulierung und Zero Trust
• NetBird-Expertise und Authentik-Expertise

Souveränen Zero-Trust-Zugriff für Standorte, Teams oder OT aufbauen? Lernen Sie uns kennen oder sehen Sie sich unsere Remote-Management-Plattformen an.