ZTNAund VPN.
VPN und ZTNA regeln den Fernzugriff auf interne Systeme. Ein VPN verbindet ein Gerät über einen verschlüsselten Tunnel mit dem Firmennetz. ZTNA verbindet eine geprüfte Identität gezielt mit einzelnen freigegebenen Anwendungen und bezieht Gerätezustand und Kontext in jede Zugriffsentscheidung ein. Das verkleinert die Angriffsfläche und erschwert seitliche Bewegungen im Netz. Voraussetzung sind ein verlässliches Anwendungsinventar, Identitätskontext und klare Zugangsregeln.
Vom Netz zur Anwendung.
ZTNA ist besonders sinnvoll für hybride Arbeit, Drittzugänge und private Anwendungen in Rechenzentrum oder Cloud. Der Zugang wird abhängig von Nutzer, Gerät, Kontext und Zielanwendung vermittelt. Das Modell verschiebt aber die Arbeit in Applikationszuordnung und Policy-Design.
Nicht bloss ein neues VPN.
VPN vermittelt typischerweise Netzwerkzugang. ZTNA begrenzt ihn auf definierte Anwendungen. PAM steuert privilegierte Zugriffe, IGA die Berechtigungsentscheidung und SASE die breitere Access-Architektur. Diese Disziplinen überschneiden sich, ersetzen sich aber nicht.
Erst prüfen, dann verbinden.
Ein Remote-Access-VPN baut einen verschlüsselten Tunnel vom Endgerät zu einem Gateway am Rand des Firmennetzes. Verbreitet sind zwei Verfahren: IPsec mit dem Schlüsselaustausch IKEv2 und SSL- beziehungsweise TLS-VPN, das über Port 443 läuft und deshalb auch in restriktiven Netzen durchkommt. Nach der Anmeldung erhält das Gerät eine interne Adresse und erreicht, was die Firewall-Regeln dahinter erlauben, oft ganze Netzbereiche. Das Gateway selbst ist aus dem Internet erreichbar und damit ein bevorzugtes Angriffsziel. Ein Teil der Hersteller stellt deshalb vom proprietären SSL-Tunnel auf standardbasiertes IPsec um, das sich ebenfalls über TCP 443 transportieren lässt.[1,2,3]
ZTNA (Zero Trust Network Access) vermittelt den Zugriff je Anwendung statt je Netz. Das Modell stammt aus der Zero-Trust-Architektur nach NIST SP 800-207: Ein Policy Decision Point entscheidet anhand von Identität, Gerätezustand und Kontext, ein Policy Enforcement Point setzt den Entscheid durch. In der verbreitetsten Bauform baut ein Connector im Rechenzentrum nur ausgehende Verbindungen zum Vermittlungsdienst auf. Die Anwendung hat damit keinen offenen Eingang ins Internet, und ein Benutzer sieht nur die Anwendungen, für die er freigegeben ist. Single Packet Authorization geht einen Schritt weiter: Das Gateway antwortet erst, wenn das erste Paket kryptografisch gültig ist.[4,5,6]
Der Zugriff läuft entweder über einen Client, der Verkehr für freigegebene Ziele abfängt und tunnelt, oder clientlos über einen identitätsbewussten Reverse-Proxy im Browser, auch für SSH- oder RDP-Sitzungen. Overlay-Netze auf Basis von WireGuard verbinden Geräte direkt miteinander; ein zentraler Management-Server verteilt Schlüssel und Richtlinien. Der Gerätezustand, etwa Betriebssystemstand, Verschlüsselung oder EDR-Status, fliesst bei der Anmeldung und je nach Produkt auch während der Sitzung in den Entscheid ein.[7,8,9,10]
Beim Betrieb gibt es zwei Modelle. Cloud-Dienste betreiben Controller und Vermittlung beim Anbieter, das Unternehmen betreibt nur die Connectoren. Selbst betriebene Plattformen halten Controller und Gateway im eigenen Rechenzentrum; mehrere davon sind Open Source.[6,11]
| Merkmal | Remote-Access-VPN | ZTNA |
|---|---|---|
| Was erreicht wird | Netzbereich nach Firewall-Regel | Einzelne Anwendung nach Richtlinie |
| Sichtbarkeit aus dem Internet | Gateway mit offenem Port | Anwendung ohne offenen Eingang, Connector baut nach aussen auf |
| Gerätezustand | Prüfung meist bei Verbindungsaufbau | Teil jedes Entscheids, je nach Produkt auch in der Sitzung |
| Entscheidungspunkt | Gateway und nachgelagerte Firewall | Controller als Policy Decision Point |
| Ausfall des Vermittlers | Kein Zugang über dieses Gateway | Kein Zugang zu allen angebundenen Anwendungen |
| Typischer Einsatz | Vollzugriff, Altanwendungen, Standortkopplung | Drittzugriff, Administrationsoberflächen, BYOD |
Typische Probleme
| Problem | Wie man es löst |
|---|---|
| Exponierte Gateways | VPN-Gateways und andere Edge-Geräte sind wiederholt Ziel aktiv ausgenutzter Schwachstellen; der Katalog der US-Behörde CISA führt solche Fälle bei Gateways vieler Hersteller, und mehrere nationale Cyberbehörden haben 2025 gemeinsame Schutzmassnahmen für Edge-Geräte veröffentlicht. Verwaltungszugang nur aus dem Admin-Netz, Patches innert Stunden und Integritätsprüfungen fest einplanen.[13,14] |
| Ausfall des Vermittlungsdienstes | Ist ein cloudbasierter Entscheidungs- oder Durchsetzungspunkt nicht erreichbar, etwa nach einem Bedienfehler beim Anbieter, scheitern Zugriffe auf alle angebundenen Anwendungen; NIST SP 800-207 führt solche Störungen als eigene Bedrohung. Notfallzugang ohne den Dienst definieren und testen.[4] |
| Fehlendes Anwendungsinventar | ZTNA braucht bekannte Anwendungen, Owner und Nutzergruppen. Mit Drittzugängen und Administrationsoberflächen beginnen und das VPN erst abschalten, wenn die Protokolle keine Nutzung mehr zeigen. |
| Verzögerte Gerätesicht | Gerätezustände werden in Intervallen abgefragt und zwischengespeichert, Änderungen wirken teils erst nach Minuten. Intervalle bewusst festlegen und kritische Anwendungen strenger takten.[15] |
| Pflichtmigration bei Versionswechseln | Entfällt ein VPN-Modus, werden alte Konfigurationen beim Upgrade nicht übernommen. Herstellerankündigungen verfolgen und die Migration vor dem Upgrade testen.[2] |
Auswahlfragen
| Frage | Worauf die Antwort hinweisen sollte |
|---|---|
| Wer betreibt Controller, Vermittlung und Protokolle, und wo? | Die Antwort sollte Standorte, Betreiber und die Möglichkeit eines Eigenbetriebs klar nennen. |
| Wie verhält sich der Zugang bei einem Ausfall des Dienstes? | Erwartet werden Aussagen zu laufenden Sitzungen, zu neuen Anmeldungen und zu einem dokumentierten Notfallweg. |
| Wann wird der Gerätezustand geprüft? | Gute Antworten unterscheiden Prüfung bei Verbindung, periodisch und bei Änderung, mit konkreten Intervallen. |
| Welche Protokolle und Anwendungen funktionieren clientlos? | Die Antwort sollte Web, SSH, RDP und Nicht-Web-Protokolle getrennt aufführen. |
| Wie schnell schliesst der Hersteller Schwachstellen am Gateway? | Erwartet werden Patch-Fristen, ein Hinweisdienst und Werkzeuge zur Integritätsprüfung. |
| Wie wird ein Entzug wirksam? | Austritte und Rollenwechsel im Identity Provider sollten bestehende Sitzungen innert Minuten beenden. |
Betrieb und Verantwortung
Netzwerk- oder Security-Betrieb pflegt Gateways, Connectoren und Richtlinien; das IAM-Team liefert Identitäts- und Gerätesignale, die Anwendungsverantwortlichen bestätigen Nutzergruppen und Abhängigkeiten. Sicherheitsmeldungen der Hersteller werden täglich ausgewertet, Sitzungsdaten gehen ins zentrale Logging. Sinnvolle Kennzahlen sind der Anteil privater Anwendungen nur über ZTNA, Freigaben ohne Owner oder Ablaufdatum, Zugriffe über das alte VPN je Monat und die Zeit vom Hersteller-Patch bis zur Installation am Gateway.
Regulatorischer Bezug
ISO/IEC 27001:2022 adressiert das Thema in Annex A über 5.15 «Access control», 6.7 «Remote working», 8.5 «Secure authentication» und 8.20 «Networks security». NIS2 nennt in Art. 21 Abs. 2 lit. i Konzepte für die Zugriffskontrolle und in lit. j Multi-Faktor- oder kontinuierliche Authentisierung; DORA verlangt in Art. 9 Abs. 4 lit. c, den logischen Zugang auf das Erforderliche zu beschränken. In Deutschland beschreibt der IT-Grundschutz-Baustein NET.3.3 «VPN» Planung, Betrieb und Absicherung von VPN-Zugängen.[16,17,18,19,20,21,3]
Quellen: [1] cisco.com · [2] docs.fortinet.com · [3] bsi.bund.de · [4] csrc.nist.gov · [5] twingate.com · [6] appgate.com · [7] pomerium.com · [8] developers.cloudflare.com · [9] docs.netbird.io · [10] docs.netbird.io · [11] github.com · [12] zscaler.com · [13] nsa.gov · [14] cisa.gov · [15] developers.cloudflare.com · [16] isms.online · [17] isms.online · [18] isms.online · [19] isms.online · [20] nis-2-directive.com · [21] digital-operational-resilience-act.com
Sechzehn Werkzeuge im Vergleich.
Der Markt umfasst ZTNA-Dienste aus der Cloud, bei denen ein Connector im Firmennetz ausgehende Verbindungen zum Dienst aufbaut, ZTNA-Plattformen mit eigenem Controller und Gateway für den Betrieb im eigenen Rechenzentrum, darunter Open-Source-Projekte, und klassische Remote-Access-VPN auf Firewalls und Gateways, die zunehmend um anwendungsbezogenen Zugriff und Gerätechecks ergänzt werden. Mit NCP (Nürnberg) und genua (Kirchheim bei München, Bundesdruckerei-Gruppe) sind Anbieter aus Deutschland vertreten; genuconnect ist vom BSI für VS-NfD, NATO RESTRICTED und RESTREINT UE zugelassen. Die VPN-Seite verändert sich: Fortinet ersetzt ab FortiOS 7.6.3 den SSL-VPN-Tunnelmodus durch IPsec.
Ohne Client: Zugriff ohne Client · Mit Client: Zugriff mit Client · Gerätezustand: Gerätezustand fliesst in den Zugriffsentscheid ein · VPN: klassisches VPN IPsec/SSL · Segmentierung: Anwendungssegmentierung · Self-Hosted: Self-Hosted Gateway/Controller · Open Source: Open Source. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Zscaler Private Access (ZPA)
Zscaler
Zugriff auf private Anwendungen in Rechenzentrum und Cloud für Mitarbeitende, Dritte und Geräte im OT-Umfeld.
ZPA vermittelt direkte Eins-zu-eins-Verbindungen zwischen berechtigten Benutzern und einzelnen Anwendungen; Benutzer gelangen nicht ins Firmennetz, Anwendungen sind aus dem Internet nicht erreichbar.
Inline-Inspektion des Verkehrs zu privaten Anwendungen mit DLP (Exact Data Match, Indexed Data Match) über alle Ports und Protokolle; Zugriffsregeln können Gerätezustandsprüfungen (Posture-Profile) und Risikowerte der Benutzer als Bedingung verlangen.
App-Segmente mit KI-gestützten Vorschlägen für Segmente und Richtlinien; Segmentierung Benutzer-zu-App und App-zu-App.
Cloud-Dienst mit schlanker Software auf dem Gerät und Browser Access für clientlosen Zugriff.
Clientloser Zugriff von Dritten und BYOD-Geräten auf RDP-, SSH- und VNC-Systeme, Ablösung von VPN und VDI.
Anwendungen bleiben aus dem Internet unsichtbar, und Freigaben gelten je Anwendung.
Selbst betriebene Vermittlungsknoten sind auf der Produktseite nicht beschrieben; die Vermittlung läuft über die Zscaler-Cloud, Gerätezustandsprüfungen setzen den Client Connector voraus.
Cloudflare Access (Cloudflare One)
Cloudflare
ZTNA für selbst betriebene, SaaS- und Nicht-Web-Anwendungen für Mitarbeitende und Dritte.
App-Connector-Tunnel verbinden interne Ressourcen ausgehend mit dem Cloudflare-Netz; der Geräte-Client leitet Verkehr standardmässig über WireGuard-Tunnel.
Kontextbezogene Regeln nach IdP-Gruppe, Standort, Gerätezustand und Sitzungsdauer; Gerätezustand wird in einstellbaren Intervallen abgefragt.
Mehrere Identity Provider gleichzeitig, auch soziale IdPs für Dritte und generische SAML- und OIDC-Anbindung; Verteilung des Clients per MDM.
Cloud-Dienst; Audit-Logs zum Verbindungsstatus der Tunnel und zu neu registrierten DNS-Einträgen.
Clientloser Zugriff auf Webanwendungen sowie browserbasiertes SSH, VNC und RDP für Dienstleister.
Clientloser Zugriff reicht bis zu browserbasierten SSH-, VNC- und RDP-Sitzungen.
Änderungen des Gerätezustands wirken mit Verzögerung: Gateway-Regeln nutzen einen Cache, der nur alle fünf Minuten aktualisiert wird, zusätzlich zum Abfrageintervall.
Microsoft Entra Private Access
Microsoft
Zugriff auf private Ressourcen in Hybrid- und Multi-Cloud-Umgebungen für beliebige Ports und Protokolle, aufbauend auf dem Entra Application Proxy.
Quick Access fasst die FQDNs und IP-Bereiche zusammen, die immer über den Dienst laufen; einzelne Global-Secure-Access-Apps erlauben Per-App-Zugriff mit eigenen Richtlinien.
Conditional Access steuert den Zugriff je App, auch für Altanwendungen ohne moderne Authentisierung.
Der Microsoft Entra Private Network Connector vermittelt die Verbindung zwischen Dienst und interner Ressource.
Cloud-Dienst im Entra Admin Center, lizenziert über die Entra Suite oder einzeln.
Microsoft-zentrierte Organisationen, die das VPN durch identitätsbasierten Zugriff ablösen und Richtlinien zeitlich begrenzen.
Zugriffsentscheide nutzen direkt Conditional Access und Gruppen aus Entra ID.
Clientloser Zugriff ist in den geprüften Dokumenten nicht beschrieben; der Gerätezustand fliesst über Conditional Access ein und setzt für konforme Geräte Intune oder eine Partner-MDM voraus.
Twingate
Twingate
Identitätsbasierter Zugriff für Benutzer, Dienste und KI-Agenten auf Ressourcen in privaten Netzen und Clouds.
Controller, Relay, Connector und Client sind getrennte Komponenten; der Connector hinter der Firewall hält nur ausgehende Verbindungen zu Relays.
Der Client erhält eine vom Controller signierte Liste erlaubter Ressourcen (ACL); der Connector prüft Signatur, Tunnel und ACL bei jeder Verbindung.
Authentisierung immer über einen externen Identity Provider, Benutzer werden aus dem IdP synchronisiert; Gerätechecks steuern den Zugriff.
DNS-Anfragen für geschützte Ressourcen löst der Connector im Zielnetz auf; Relays speichern nur die anonyme Connector-ID.
Ablösung eines VPN für TCP- und UDP-Anwendungen ohne Anpassung der Anwendungen, über einen transparenten Proxy im Client.
Getrennte, gegenseitig geprüfte ACLs auf Client und Connector begrenzen den Zugriff zweifach.
Controller und Relays betreibt der Anbieter; clientloser Zugriff ist in den geprüften Dokumenten nicht beschrieben.
AppGate ZTNA (vormals Appgate SDP)
Appgate
Zugriff auf IaaS, SaaS, Microservices, private Cloud und Altsysteme aus einer Richtlinien-Engine, einschliesslich Ablösung von Site-to-Site-VPN.
Der Controller ist Policy Decision Point, das Gateway Policy Enforcement Point; das Gateway baut je Sitzung Mikro-Firewalls auf, der Verkehr läuft direkt und nicht über eine Fremd-Cloud.
Single Packet Authorization macht Ressourcen für Unberechtigte unsichtbar; Posture-Checks und ein Risiko-Scoring bewerten Benutzer, Gerät und Kontext.
Zugriff per Client oder über ein Portal im Browser; Verwaltung über Dashboard oder API.
Appliances als virtuelle Maschine ohne Aufpreis oder als Hardware; Betrieb selbst gehostet oder als Dienst, bei dem nur der Controller in der Cloud liegt.
Organisationen, die Controller und Gateway selbst betreiben und den Verkehr nicht über eine fremde Cloud leiten wollen.
Controller und Gateways lassen sich vollständig im eigenen Betrieb führen.
Der Eigenbetrieb verlangt Betrieb, Hochverfügbarkeit und Aktualisierung der Appliances durch das eigene Team.
OpenZiti
NetFoundry (Projektträger)
Zero-Trust-Overlay-Netz für bestehende Anwendungen über Tunneler oder für eigene Anwendungen über eingebettete SDKs.
Der Controller bildet die Management Plane mit Identitäten und Richtlinien, Edge Router bilden die Data Plane als verschlüsseltes Mesh; private («dark») Router haben keine offenen Eingänge.
Feingranulare Autorisierung mit Posture-Checks; mit SDK hält die Anwendung selbst eine kryptografische Identität.
Tunneler für Linux, Windows, macOS, iOS und Android binden unveränderte Software an.
Selbst betrieben mit Support von NetFoundry oder als von NetFoundry betriebener Cloud-Dienst.
Entwicklungsteams, die Zero-Trust-Zugriff direkt in Anwendungen einbauen oder Dienste ohne offene Ports betreiben.
Anwendungen können Zero-Trust-Verbindungen über SDKs selbst aufbauen, ohne separaten Client.
Einbettung per SDK und Eigenbetrieb des Overlays erfordern Entwicklungs- und Betriebsaufwand.
NetBird
NetBird
Verbindung von Benutzern, Hybrid-Cloud- und Edge-Ressourcen über ein WireGuard-basiertes Peer-to-Peer-Netz für Linux, Windows, macOS, Mobilgeräte, Container und Router.
Der Management-Server verwaltet Netzstatus und öffentliche Schlüssel; Peers bauen direkte WireGuard-Verbindungen auf, der Signal-Dienst vermittelt verschlüsselt, ohne Inhalte zu sehen.
Posture-Checks prüfen Geräte beim Verbinden und erneut während der Sitzung, sobald sich Systemdaten ändern; das Netz wird dann neu berechnet.
Anmeldung über Identity Provider mit SSO und MFA; Richtlinien segmentieren den Zugriff je Ressource.
Management als Cloud-Dienst von NetBird oder selbst betrieben.
Ablösung klassischer VPN-Gateways für Ressourcen, die über mehrere Clouds und On-Premises verteilt sind.
Gerätechecks werden während der Sitzung neu bewertet, und das Management lässt sich selbst betreiben.
Die Lizenz ist zweigeteilt: Management, Signal und Relay stehen unter AGPLv3, was Änderungen und Weitergabe an Bedingungen knüpft.
Pomerium (Core, Zero, Enterprise)
Pomerium
Identitätsbewusster Proxy für interne Anwendungen, Server, Dienste und Workloads in Cloud, On-Premises und hybrid.
Pomerium fängt den Verkehr ab und prüft jede Anfrage gegen Identity Provider, Richtlinien und Gerätekontext, bevor sie zum Dienst geleitet wird.
Identität, Gerätezustand und Anfragekontext werden laufend verifiziert, nicht nur bei der Anmeldung.
Anbindung an den bestehenden Identity Provider; TLS, DNS, Speicher und Skalierung bleiben in der Hand des Betreibers.
Core ist die selbst betriebene Data Plane; Zero betreibt die Control Plane als Dienst, Enterprise hält sie im eigenen Betrieb.
Clientloser Zugriff auf interne Webanwendungen nach dem BeyondCorp-Modell, ohne VPN.
Jede einzelne Anfrage wird authentisiert und autorisiert, ohne Client-Software.
Der Ansatz ist auf Proxy-Zugriff ausgelegt; für Anwendungen, die einen Netztunnel brauchen, beschreibt die Übersicht keinen Client.
GlobalProtect
Palo Alto Networks
Fernzugriff für mobile Benutzer über Palo-Alto-Firewalls der nächsten Generation oder über Prisma Access.
IPsec-Tunnel mit Always-on-Verbindung; bei Ausfall des IPsec-Tunnels lässt sich die App so konfigurieren, dass sie getrennt bleibt.
Host Information Profile (HIP) prüft Gerätezustand und Sicherheitslage vor der Verbindung; benutzerbasierte Zugriffskontrolle.
Authentisierung über LDAP, SAML, Kerberos, RADIUS, TACACS+ und Client-Zertifikate.
Client- oder clientlose Bereitstellung; Inspektion des gesamten Verkehrs mobiler Anwendungen durch die Sicherheitsdienste.
Unternehmen mit Palo-Alto-Firewalls, die Fernzugriff an bestehende Richtlinien binden und schrittweise zu Prisma Access wechseln.
Derselbe Client funktioniert gegen eigene Firewalls und gegen den Cloud-Dienst.
Der Zugriff erfolgt auf Netzebene mit Firewall-Richtlinien; anwendungsbezogene Freigaben beschreibt die Produktseite für den Weg über Prisma Access (ZTNA).
Cisco Secure Client (mit Secure Firewall und Secure Access)
Cisco
VPN-Client für Windows, macOS und Linux (einschliesslich AnyConnect) mit Zero-Trust-Access-Modul ab Version 5.1.3.62.
Tunnel über SSL (TLS 1.2 und DTLS 1.2) oder IPsec IKEv2; Always-on wählt automatisch den besten Zugangspunkt.
ISE Posture prüft das Gerät clientseitig; Secure Firewall Posture (vormals HostScan) läuft nach der Verbindung zur Secure Firewall ASA.
Verteilung über Secure Firewall ASA, Threat Defense oder ISE; Per-App-VPN auf iOS, Android und Samsung Knox.
Headends im eigenen Betrieb oder ZTNA und VPN as a Service über Cisco Secure Access, dort auch clientlos.
Organisationen mit AnyConnect- und Secure-Firewall-Bestand, die einzelne Anwendungen auf ZTNA umstellen.
VPN und ZTNA laufen im selben Client, sodass der Wechsel Anwendung für Anwendung erfolgen kann.
Secure Firewall Posture ist auf Android, iOS, ChromeOS und UWP nicht verfügbar.
FortiGate VPN und ZTNA mit FortiClient (EMS)
Fortinet
FortiClient als einheitlicher Agent für ZTNA, Fernzugriff per VPN und Endpunktschutz; FortiOS bietet zusätzlich Agentless VPN über den Browser.
Ab FortiOS 7.6.3 ersetzt standardbasiertes IPsec den proprietären SSL-VPN-Tunnelmodus; IPsec kann über TCP-Port 443 laufen.
EMS bildet virtuelle Gruppen nach Sicherheitszustand der Endpunkte, die FortiGate in Firewall-Richtlinien dynamisch auswertet; Posture-Checks gelten auch am FortiOS Access Proxy.
Integration in die Fortinet Security Fabric, etwa automatische Übergabe von Dateien an FortiSandbox.
Gateways auf eigenen FortiGates; zentrale Verwaltung über FortiClient EMS oder FortiClient Cloud.
Fortinet-Umgebungen, die VPN und anwendungsbezogenen ZTNA-Zugriff mit demselben Agenten betreiben.
VPN, ZTNA und Endpunktschutz teilen einen Agenten und eine Verwaltung.
Konfigurationen des SSL-VPN-Tunnelmodus werden beim Upgrade auf 7.6.3 nicht übernommen und müssen vorher manuell auf IPsec migriert werden.
Check Point Remote Access VPN
Check Point
Fernzugriff für Remote- und Mobilgeräte auf Unternehmensnetze, mit Clients für Windows und macOS.
Client-to-Site-VPN über IPsec oder Zugriff über ein SSL-VPN-Portal aus jedem Browser.
Multifaktor-Authentisierung, Prüfung der Endpunkt-Compliance und Verschlüsselung aller übertragenen Daten.
Remote Access ist in jede Check-Point-Netzwerkfirewall integriert.
Betrieb auf den eigenen Security Gateways ohne separates System.
Organisationen mit Check-Point-Gateways, die Fernzugriff über die bestehende Firewall-Infrastruktur bereitstellen.
Fernzugriff nutzt die bestehenden Gateways und deren Richtlinien.
Der Zugriff erfolgt auf Netzebene; anwendungsbezogene ZTNA-Freigaben beschreibt die Produktseite nicht.
Ivanti Connect Secure (mit Ivanti Zero Trust Access)
Ivanti
SSL-VPN mit Layer-3-VPN, Per-App-VPN, On-Demand- und Always-on-Zugriff sowie clientlosem Browserzugriff auf veröffentlichte Anwendungen und virtuelle Desktops.
Läuft auf der Ivanti Security Appliance (ISA) als Hardware, virtuelle Appliance (ESXi, KVM, Hyper-V) oder in Azure, AWS und Google Cloud; Split Tunneling nach FQDN oder Netz.
Secure Boot, TPM/vTPM und Integritätsprüfung der Gateways; integrierte Web Application Firewall für HTTP-Verkehr am Gateway.
Ivanti Zero Trust Access gewährt anwendungsbezogenen Zugriff nach Identität, Gerätezustand und Anwendungskontext; zentrale Verwaltung über Ivanti Neurons for Secure Access.
ICS 25.x auf Oracle Linux 9 mit FIPS-140-3-zertifiziertem Modul.
Organisationen mit komplexen Fernzugriffsanforderungen, die VPN und Zero-Trust-Zugriff über einen Client betreiben.
VPN-Varianten, clientloser Zugriff und ZTNA sind in einem Gateway-Produkt kombiniert.
Das Gateway ist aus dem Internet erreichbar und muss wie jedes VPN-Gateway zeitnah gepatcht und überwacht werden.
OpenVPN Access Server
OpenVPN Inc.
Selbst betriebener Business-VPN-Server auf Linux, aufgebaut auf dem Open-Source-Projekt OpenVPN (Community Edition unter GPLv2).
Verschlüsselte Verbindung zu privaten Netzen über das Internet; Data Channel Offload (DCO) beschleunigt den Datenkanal.
Authentisierung über PAM, RADIUS, LDAP, SAML, lokal oder eigene Verfahren, mit eingebauter MFA und mehreren Methoden je Benutzergruppe.
Bereitstellung auf physischen Servern oder bei den grossen Public-Cloud-Anbietern.
Betrieb vollständig in der eigenen Umgebung; kostenloser Plan mit zwei Verbindungen, darüber Lizenz nach Verbindungen.
Mittelstand und Teams mit eigener Betriebsverantwortung, die ein VPN auf eigener Infrastruktur führen.
Vollständig selbst betrieben, auf breit eingesetzter offener Protokollbasis.
Gerätechecks und anwendungsbezogene Freigaben beschreibt die Produktseite nicht; Härtung, Updates und Logging liegen beim Betreiber.
NCP Secure Enterprise (VPN Server, Clients, Management)
NCP engineering
IPsec-VPN-Gateway mit zugehörigen VPN-Clients und zentralem Management eines Herstellers mit Sitz in Nürnberg.
RFC-konformes IPsec mit IKEv2 (inklusive MOBIKE), Seamless Roaming und Rekeying; VPN Path Finder weicht auf HTTPS über Port 443 aus, wenn IPsec-Ports blockiert sind.
Endpoint Policy Enforcement prüft vordefinierte Sicherheitsparameter des Endgeräts für eingehende Verbindungen.
Authentisierung mit OTP-Token, X.509-Zertifikaten, EAP-Verfahren; Verwaltung über das Enterprise-Management-Plug-in oder die Weboberfläche.
Betrieb hinter der Firewall in der DMZ, direkt am Internet oder als virtuelle Appliance; Mandantenfähigkeit.
Organisationen in Deutschland und Europa, die IPsec-Fernzugriff mit europäischem Hersteller und eigenem Betrieb wollen.
Path Finder hält IPsec-Verbindungen auch in Netzen mit blockierten VPN-Ports aufrecht.
Anwendungsbezogene Freigaben (ZTNA) beschreibt das Datenblatt nicht; der Zugriff erfolgt auf Netzebene.
genuconnect und genuconnect Enterprise
genua (Bundesdruckerei-Gruppe)
VPN-Software-Client für Laptops und Tablets mit Windows 10 oder 11, der mobile Geräte über ein genuscreen-Gateway an das Unternehmensnetz anbindet.
IPsec mit Multifaktor-Authentisierung; der Client baut VPN-Verbindungen automatisch auf.
genuconnect ist seit 30.06.2021 vom BSI für VS-NfD, NATO RESTRICTED und RESTREINT UE zugelassen; genuconnect Enterprise bietet VS-NfD-nahe Sicherheit.
Interoperabel mit Festplattenverschlüsselung, Device-Kontrolle und Endpoint Protection; kompatibel mit gängigen Rollout-Mechanismen.
Skaliert laut Hersteller auf mehr als 100 000 VPN-Clients; Entwicklung und Produktion in Deutschland.
Behörden, KRITIS-Betreiber und Industrie; der Wechsel auf die VS-NfD-Version erfordert nur den zugelassenen Client und eine Smartcard.
Zugelassene Variante für eingestufte Informationen, mit Umstieg ohne neue Hardware.
Ausgelegt für Windows-Endgeräte; Gerätechecks und anwendungsbezogene Freigaben beschreibt das Datenblatt nicht.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- Tailscale: WireGuard-basiertes Overlay mit Gerätechecks; Client Open Source, Koordinationsserver proprietär (selbst betreibbar nur über das Community-Projekt Headscale)
- Netskope One Private Access, Prisma Access (ZTNA), HPE Aruba Networking SSE: ZTNA als Teil einer SSE-Plattform; in der Klasse SASE und SSE geführt
- SonicWall Remote Access VPN, WatchGuard Mobile VPN: VPN-Zugänge aus Firewall-Portfolios
- WireGuard, strongSwan: Open-Source-VPN-Protokoll bzw. IPsec-Implementierung; Bausteine ohne Richtlinien- und Benutzerverwaltung
- LANCOM Advanced VPN Client: VPN-Client eines deutschen Herstellers
- OpenVPN CloudConnexa: Cloud-Variante von OpenVPN; laut Herstellerseite unterscheidet sie sich in einigen Funktionen vom Access Server, nicht separat geprüft
Anwendung für Anwendung,
nicht Netz für Netz.
- Anwendungen nach Nutzergruppe und Schutzbedarf inventarisieren. Mit Drittzugängen und Administrationsoberflächen beginnen, weil dort der Nutzen am grössten ist.
- Policy aus Identität, Gerätezustand und Zielanwendung ableiten. Die Standardregel lautet «verweigern», jede Freigabe hat einen Owner.
- VPN und ZTNA parallel betreiben und Anwendungen schrittweise umstellen. Das alte Netzwerkprofil wird erst abgeschaltet, wenn die Zugriffsprotokolle keine Nutzung mehr zeigen.
- Notfallzugang ohne ZTNA-Dienst definieren, offline dokumentieren und halbjährlich testen. Ein Ausfall des Vermittlers darf den Betrieb nicht blockieren.
- Anteil privater Anwendungen, die nur noch über ZTNA erreichbar sind
- Anzahl Freigaben ohne benannten Owner oder ohne Ablaufdatum
- Anzahl Zugriffe über das alte VPN je Monat
Das Anwendungsteam bestätigt Nutzergruppen und Abhängigkeiten, Netzwerk- oder Security-Betrieb pflegt Connectoren und Policy. IAM stellt die Identitäts- und Gerätesignale bereit.
ISO/IEC 27001:2022 Annex A 8.20 (Netzwerksicherheit), 8.22 (Trennung von Netzwerken), 5.15 (Zugangssteuerung) und 6.7 (Remote-Arbeit) stützen den Ansatz.
DORA Art. 9 Abs. 4 lit. c verlangt, den logischen Zugang zu Informations- und IKT-Assets auf das Erforderliche zu beschränken; NIS2 Art. 21 Abs. 2 lit. i und lit. j nennen Konzepte für die Zugriffskontrolle sowie Multi-Faktor- oder kontinuierliche Authentifizierung.
ZTNA vergibt kein Vertrauen und ersetzt keine Anwendungssicherheit. Eine verwundbare Anwendung bleibt verwundbar, wenn sie über einen Vermittler erreichbar ist; ZTNA verkleinert nur, wer sie überhaupt erreicht.
Mit einer privaten Anwendung.
Eine geeignete Pilotanwendung hat klaren Owner, definierte Nutzergruppen und bekannte Abhängigkeiten. Der Test muss zeigen, dass ein berechtigter Benutzer arbeitet, ein unberechtigter Benutzer die Anwendung nicht einmal erreicht und der Zugriff im Audit nachvollziehbar bleibt.
- Eine Anwendung mit internen, externen und privilegierten Nutzern abbilden
- Geräte- und Identitätskontext gezielt verändern
- Autorisierte und verweigerte Zugriffe im Audit prüfen
- Rückfall, Notfallzugang und Entzug einer Berechtigung testen
Security Tool Navigator · Gebiet 05
Im Gebiet Network Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Network Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.