ZTNA für Verteidigung: Zero-Trust-Architektur und Policy-Engine

Das Perimeter-VPN war drei Jahrzehnte lang die primäre Fernzugriffskontrolle für Verteidigungsnetze. Ein Benutzer authentifiziert sich am VPN-Gateway, ein Tunnel wird aufgebaut, und der Benutzer erhält breiten netzwerkschichtigen Zugriff auf Ressourcen innerhalb des Perimeters. Dieses Modell wurde für eine Welt entworfen, in der Anwendungen in einem einzigen Rechenzentrum liefen und Benutzer von organisatorisch kontrollierten Standorten aus zugriffen. In einer modernen Verteidigungsumgebung – in der Workloads souveräne Cloud, taktische Edge und air-gapped klassifizierte Enclaves umspannen und Benutzer von verwalteten und halbverwalteten Geräten aus vielen Standorten zugreifen – bringt die VPN-Architektur Risiken mit sich, die ihre Konstrukteure nie vorhergesehen hatten. Zero-Trust-Netzwerkzugriff (ZTNA) ist der architektonische Ersatz: Zugriff auf Anwendungsebene, vermittelt über einen identitätsbewussten Proxy und bedingt durch die fortlaufende Verifikation, wer sich verbindet und welches Gerät verwendet wird. Dieser Artikel untersucht die technischen Mechaniken von ZTNA für die Verteidigung: wie Identitäts- und Gerätesignale erfasst und ausgewertet werden, wie die Policy-Engine Zugriffsentscheidungen erzeugt und wie ZTNA über das gesamte Spektrum von nicht klassifizierten Netzen bis zu air-gapped klassifizierten Enclaves eingesetzt wird.

Warum das Legacy-VPN für Verteidigungs-Zero-Trust versagt

Das grundlegende Problem des VPN in einem Zero-Trust-Kontext ist nicht die Verschlüsselung – VPN-Tunnel sind kryptografisch belastbar. Das Problem ist, was das VPN nach dem Aufbau der Verschlüsselung gewährt. Wenn sich ein Benutzer an einem VPN-Gateway authentifiziert und der Tunnel steht, erhält das Gerät des Benutzers eine Netzwerkadresse innerhalb der Verteidigungs-Enclave und kann jede Ressource in diesem Subnetz erreichen, die keine eigene hostbasierte Firewall hat. Das VPN hat ein einzelnes Authentifizierungsereignis beim Tunnelaufbau durchgeführt und eine implizite, dauerhafte Vertrauensentscheidung getroffen: Dieser Benutzer und dieses Gerät dürfen für die Dauer der Sitzung auf das gesamte Netzwerksegment zugreifen.

Implizites Vertrauen nach der Authentifizierung. Die VPN-Authentifizierung ist ein Tor, keine fortlaufende Auswertung. Ist das Tor einmal passiert, wird das Vertrauen nicht neu bewertet, bis die Sitzung endet oder eine Zeitüberschreitung eintritt. Wird das Konto des Benutzers mitten in der Sitzung kompromittiert, infiziert sich das Gerät während der Sitzung mit Schadsoftware oder lässt der Benutzer das Gerät mit aktivem Tunnel unbeaufsichtigt, stellt das VPN den Enclave-Zugriff weiter bereit, bis ein Administrator die Sitzung manuell beendet oder der Tunnel abläuft. In einer Verteidigungsumgebung, in der Sitzungen oft einen ganzen Arbeitstag dauern, ist das ein ausgedehntes Fenster unentdeckten Risikos.

Flaches Netzwerk mit großer Wirkungsfläche. Ein VPN setzt den Benutzer auf ein Netzwerksegment. Flache Ost-West-Konnektivität innerhalb dieses Segments bedeutet, dass eine kompromittierte VPN-Sitzung nicht nur die intendierte Anwendung erreicht, sondern jeden Dienst, jede Datenbank und jede Verwaltungsschnittstelle im Subnetz. Der Angreifer, der ein VPN-Zugangsdatum stiehlt, erhält einen Fußpunkt mit derselben Netzwerkreichweite wie der legitime Benutzer – oder einer breiteren, da die VPN-Richtlinie den Subnet-internen Verkehr selten einschränkt. Das ist das Wirkungsflächenproblem: Eine einzige kompromittierte Berechtigung setzt das gesamte flache Netzwerksegment der Gefahr aus.

Keine Durchsetzung feingranularer Zugriffsrichtlinien. VPN-Zugriffsrichtlinien sind grob: Ein Benutzer darf entweder eine Verbindung zu einem VPN-Profil aufbauen oder nicht. Das Profil kann ein VLAN oder Subnetz zuweisen, aber die Durchsetzung von Richtlinien je Anwendung, je Ressource oder je Aktion innerhalb des Tunnels ist keine VPN-Fähigkeit. Die Zugriffskontrolle im Tunnel ist an die eigene Authentifizierungsmechanik jeder Anwendung delegiert – die im Anwendungsportfolio sehr unterschiedlich streng sein kann. ZTNA verlagert die Zugriffsrichtlinie in eine zentrale Policy-Engine, die einheitliche Regeln über alle Anwendungen hinweg anwendet, ausgewertet zum Zeitpunkt jeder Zugriffsanfrage statt einmalig beim Sitzungsaufbau. Das verwandte Konzept der Zero-Trust-Mikrosegmentierung für die Verteidigung adressiert die laterale Bewegung im Netzwerk nach der Zugriffsentscheidung und ergänzt so die ZTNA-Schicht am Perimeter.

ZTNA-Architektur: Proxy- gegen Endpunkt-Agent-Modelle

ZTNA-Implementierungen teilen sich nach der Art der Datenverkehrserfassung in zwei primäre Architekturmuster: das Reverse-Proxy-Modell (clientlos) und das Endpunkt-Agent-Modell. Beide Modelle teilen eine logische Grundstruktur – einen Policy-Durchsetzungspunkt, einen Identitätsbroker, einen Geräte-Trust-Dienst und einen Sitzungsproxy –, unterscheiden sich aber darin, wo die Erfassung erfolgt und welche Tiefe der Geräteeinblick erreichbar ist.

Reverse-Proxy-ZTNA (clientlos)

Beim Reverse-Proxy-Modell wird auf dem Endpunkt keine Software installiert. Der ZTNA-Dienst veröffentlicht einen Proxy-Endpunkt – typischerweise eine URL in der Domäne der Organisation –, der vor jeder geschützten Anwendung steht. Der Benutzer ruft die Proxy-URL im Browser auf, authentifiziert sich über den Identitätsbroker (mit CAC/PIV-Berechtigung und abgeschlossener MFA) und erhält ein kurzlebiges Sitzungstoken. Der Proxy validiert das Token bei jeder Anfrage und leitet authentifizierte, autorisierte Anfragen an das Anwendungs-Backend weiter. Das Gerät des Benutzers wird nie in das Anwendungsnetzwerk gesetzt; nur der Proxy hat einen Netzwerkpfad zum Backend.

Die Hauptbeschränkung des clientlosen Modells ist die Protokollabdeckung: Es funktioniert naturgemäß für HTTPS-Anwendungen und kann RDP und SSH über browserbasierte Clients abwickeln (HTML5-RDP/SSH-Gateways), unterstützt aber keine beliebigen TCP/UDP-Protokolle oder Thick-Client-Anwendungen mit proprietären Protokollen. Auch der Einblick in den Geräte-Trust ist ohne Agenten begrenzter: Der Proxy kann TLS-Client-Zertifikate und Browser-User-Agent-Zeichenketten prüfen, aber den EDR-Integritätsstatus oder TPM-Attestation ohne lokale Agentenunterstützung nicht verifizieren.

Endpunkt-Agent-ZTNA

Das Agentenmodell installiert einen schlanken Daemon auf dem verwalteten Endpunkt. Der Agent läuft fortlaufend, fängt Datenverkehr an geschützte Anwendungsadressen ab (über einen lokalen virtuellen Netzwerkadapter oder einen paketfilter auf Betriebssystemebene), führt Geräte-Trust-Prüfungen lokal durch und baut einen verschlüsselten Tunnel zur ZTNA-Service-Edge auf. Geschützter Anwendungsdatenverkehr durchläuft diesen Tunnel statt des offenen Internets oder eines VPN. Das Anwendungs-Backend erhält Verbindungen vom ZTNA-Proxy statt direkt vom Endpunkt – die Backend-Netzwerkadresse wird dem Endpunkt nie offengelegt.

Agentenbasiertes ZTNA unterstützt jedes Anwendungsprotokoll, ermöglicht reichhaltige Geräte-Trust-Signale (EDR-Integration, TPM-Attestation, Patch-Konformität) und erlaubt Split-Tunnel-Routing, bei dem nur geschützter Anwendungsdatenverkehr den ZTNA-Tunnel durchläuft, während allgemeiner Internetverkehr direkt ausgeht. Für verwaltete Verteidigungsendpunkte ist das Agentenmodell die Standardwahl, weil die Gerätezustandsanforderungen für den Zugriff auf klassifizierte Anwendungen ohne lokale Einblicke auf Agentenebene nicht erfüllbar sind.

Cloudbasiertes gegen vor Ort betriebenes ZTNA

Cloudbasiertes ZTNA betreibt Kontrollebene und Sitzungsproxy in einem Multi-Tenant-Clouddienst. Dieses Modell passt zu nicht klassifizierten Programmen, deren Anwendungen in kommerziellen oder Behörden-Cloud-Umgebungen laufen. Für klassifizierte Programme – IL4, IL5 und air-gapped IL6 – muss die ZTNA-Kontrollebene innerhalb der akkreditierten Grenze betrieben werden. Vor Ort betriebenes ZTNA platziert Policy-Engine, Identitätsbroker und Sitzungsproxy innerhalb der klassifizierten Enclave. Anwendungsdatenverkehr verlässt die klassifizierte Grenze nie. Die externen Abhängigkeiten der Kontrollebene – Zertifikatsvalidierung, EDR-Integritätsabfragen, Identitätsanbieter-Lookups – müssen sich alle innerhalb des akkreditierten Netzes ohne Internetzugang auflösen lassen.

Identitätssignale: Wer sich verbindet

ZTNA-Zugriffsentscheidungen hängen von der Identität des sich verbindenden Benutzers ab. Für Verteidigungspersonal verankert die Identitätsprüfung in dem physischen Berechtigungsnachweis, den das Personalsystem der Organisation ausgibt – die CAC- oder PIV-Smartcard – und wird um rollen- und gruppenbezogene Attribute aus dem Verzeichnis ergänzt.

CAC/PIV-Zertifikatsprüfung

Die CAC (Common Access Card) und die PIV-Karte (Personal Identity Verification) tragen ein X.509-Identitätszertifikat, das von der genehmigten PKI der Organisation ausgestellt wurde. Die ZTNA-Zertifikatsprüfung umfasst: die Übermittlung des Zertifikats an den ZTNA-Identitätsbroker über TLS-Client-Authentifizierung; die Validierung der Zertifikatskette gegen den genehmigten Trust Anchor (die Root- und Zwischen-CAs im Trust-Store der Organisation); die Prüfung des Zertifikats gegen die Zertifikatssperrliste (CRL) oder den OCSP-Responder, um zu bestätigen, dass es nicht widerrufen wurde; und das Extrahieren des Subject Distinguished Name oder UPN aus dem Zertifikat zur Identifizierung des Benutzerprinzips.

Die Verfügbarkeit von CRL und OCSP innerhalb einer Air-Gap-Umgebung ist ein häufiger operativer Schwachpunkt. Ist der CRL-Verteilungspunkt nur aus dem nicht klassifizierten Netz erreichbar, die ZTNA-Bereitstellung aber klassifiziert, schlagen Zertifikatssperrprüfungen fehl oder laufen in eine Zeitüberschreitung. Air-Gap-ZTNA-Bereitstellungen erfordern einen CRL-Caching-Proxy innerhalb der klassifizierten Grenze, der CRL-Aktualisierungen periodisch über den domänenübergreifenden Transfermechanismus synchronisiert.

Multi-Faktor-Authentifizierung für den ZTNA-Zugriff

Die CAC-PIN-Eingabe erfüllt die MFA-Anforderung „etwas, das Sie haben, plus etwas, das Sie wissen“ für die meisten Programme. Als besonders sensibel eingestufte Anwendungen können jedoch einen zusätzlichen Faktor über die CAC hinaus verlangen – einen TOTP-Code, eine Push-Benachrichtigung an eine registrierte Authenticator-App oder einen Hardware-Sicherheitsschlüssel. Die ZTNA-Policy-Engine kann MFA-Stufen je Anwendung durchsetzen: Standard-CAC-PIN für allgemeine Anwendungen, CAC-PIN plus TOTP für sensible Führungsanwendungen und einen zeitlich begrenzten Freigabe-Workflow außerhalb des Bandes für privilegierten Administrationszugriff. Diese MFA-Staffelung je Anwendung ist mit einer flachen VPN-Richtlinie nicht erreichbar.

Identitätsanbieter-Integration: LDAP und Active Directory

Die Zertifikatsauthentifizierung identifiziert den Benutzerprinzip, trägt aber weder aktuelle Rollen- noch Gruppenmitgliedschaften – diese werden im Verzeichnis verwaltet und können sich unabhängig von der Zertifikatsausstellung ändern. Die ZTNA-Policy-Engine fragt den Identitätsanbieter – LDAP oder Active Directory – zum Zeitpunkt jeder Zugriffsanfrage ab, um die aktuellen Gruppenmitgliedschaften und Rollenzuweisungen des Benutzers aufzulösen. Die aufgelösten Attribute werden zu Richtlinien Eingaben: Ein Benutzer muss Mitglied der Active-Directory-Gruppe „analysts-secret“ sein, um auf die klassifizierte Analyseanwendung zuzugreifen – unabhängig davon, was sein Zertifikat sagt. Wird der Benutzer aus der Gruppe in Active Directory entfernt, wird seine nächste Zugriffsanfrage auf die Analyseanwendung von der ZTNA-Policy-Engine abgelehnt, ohne Zertifikatssperrung oder VPN-Richtlinienänderung. Diese attributbasierte Zugriffskontrolle, getragen von Echtzeit-Verzeichnisabfragen, ist eine Grundlagenfähigkeit der Identitätsgovernance, die Verteidigungsorganisationen anwenden, um den Lebenszyklus der Zugriffskontrolle zu straffen.

Geräte-Trust-Signale: Welches Gerät sich verbindet

Die Benutzeridentität ist im Verteidigungs-ZTNA-Modell eine notwendige, aber keine hinreichende Bedingung für den Zugriff. Ein legitimer Benutzer auf einem kompromittierten oder nicht konformen Gerät birgt ein Risiko, das die Benutzeridentität allein nicht mindern kann. Die Geräte-Trust-Bewertung sammelt und prüft Signale über das sich verbindende Gerät unabhängig von der Identitätsbehauptung des Benutzers.

Gerätezertifikat

Das erste Geräte-Trust-Signal ist das Maschinenzertifikat: ein Zertifikat, das die Geräte-PKI der Organisation dem Endpunkt bei der Registrierung ausstellt. Das Maschinenzertifikat belegt, dass das Gerät von einem autorisierten MDM- oder Gerätemanagementsystem registriert wurde und zu diesem Zeitpunkt ein verwaltetes Asset war. Der ZTNA-Agent legt das Gerätezertifikat neben dem Benutzerzertifikat beim Sitzungsaufbau vor. Die Policy-Engine validiert die Geräte-Zertifikatskette gegen den Trust Anchor der Geräte-PKI, prüft den Sperrstatus und bestätigt, dass die Gerätekennung im Zertifikat mit der Geräteidentität im MDM-Bestand übereinstimmt.

EDR-Integritätsstatus

Der auf dem Gerät laufende Endpoint-Detection-and-Response-Agent (EDR) pflegt eine Echtzeitbewertung des Bedrohungszustands des Geräts. Der ZTNA-Agent fragt den lokalen EDR-Agenten oder die API der EDR-Managementplattform nach einem Integritätsnachweis: Läuft der EDR-Agent, ist seine Threat-Intelligence-Datenbank aktuell und gibt es aktive Bedrohungen in Quarantäne oder Remediation? Ein Gerät mit veralteter EDR-Signaturdatenbank ist für recente Bedrohungsfamilien praktisch blind – die ZTNA-Richtlinie sollte ein solches Gerät als nicht konform behandeln und den Zugriff entweder verweigern oder bis zur EDR-Aktualisierung auf eine Stufe mit eingeschränktem Zugriff begrenzen. Ein aktives Quarantäneereignis während einer Sitzung löst ein Ereignis der kontinuierlichen Auswertung aus, das zur sofortigen Sitzungsaussetzung führen kann.

Patch-Konformitätsprüfung

Der Patch-Stand von Betriebssystem und Anwendungen wird von der MDM-Plattform oder aus dem lokalen Bestand installierter Patches des ZTNA-Agenten abgefragt. Die ZTNA-Policy-Engine vergleicht den Patch-Zustand des Geräts mit einem definierten Minimum: Zum Beispiel müssen alle kritischen und hochgradigen CVEs der letzten 30 Tage gepatcht sein, bevor der Zugriff auf klassifizierte Anwendungen erlaubt wird. Geräte mit Patch-Rückstand werden auf einen Remediation-Hinweis statt auf die angeforderte Anwendung umgeleitet. Die Patch-Konformitätsprüfung deckt auch Drittanbieteranwendungen im verwalteten Softwarebestand des Geräts ab – ein ungepatchter Webbrowser oder PDF-Reader auf einem verwalteten Gerät stellt einen Angriffsvektor dar, selbst wenn das Betriebssystem vollständig gepatcht ist.

Hardware-Attestation über TPM 2.0

Für verwaltete Verteidigungsendpunkte mit TPM-2.0-Modul kann der ZTNA-Agent ein TPM-Attestationszitat anfordern – eine kryptografisch signierte Messung der Boot-Kette des Geräts, erzeugt vom TPM und überprüfbar gegen ein bekanntermaßen gültiges Referenzmanifest. Die Attestation belegt, dass das Gerät von einem autorisierten Firmware- und OS-Abbild gestartet wurde und die Boot-Kette seit der letzten Attestation nicht manipuliert wurde. Diese Kontrolle ist relevant zur Erkennung von Boot-Schadsoftware – Rootkits und Bootkits, die unterhalb des Betriebssystems persistieren und von einem EDR-Agenten auf Betriebssystemebene nicht erkannt würden. TPM-Attestation erfordert, dass die ZTNA-Kontrollebene für jedes Gerätemodell der verwalteten Flotte ein Referenzmanifest vorhält; das Manifest wird bei der Geräteregistrierung angelegt und bei autorisierten Firmware-Änderungen aktualisiert.

Engine für kontinuierliche Richtlinienauswertung

Die Policy-Engine ist der entscheidende Kern der ZTNA-Architektur. Sie empfängt Zugriffsanfragen – vom Sitzungsproxy, wenn ein Benutzer eine Verbindung initiiert, und von der Auswertungsschleife während einer aktiven Sitzung – und gibt eine Zugriffsentscheidung zurück: erlauben, verweigern oder Stufen-Anforderung (zusätzliche Authentifizierung vor der Freigabe).

Policy-as-Code mit OPA und Rego

Verteidigungs-ZTNA-Bereitstellungen profitieren davon, die Zugriffsrichtlinie als Code statt als im GUI konfigurierte Regeln auszudrücken. Open Policy Agent (OPA) mit der Richtliniensprache Rego ist das dominierende Framework für dieses Muster. Eine Rego-Richtlinie für ZTNA kodiert alle Zugriffsbedingungen deklarativ: die erforderlichen Benutzergruppen, den minimalen Geräte-Konformitätsgrad, die erlaubten Zugriffszeiten, die erforderliche MFA-Stufe und den Risiko-Schwellenwert. Richtlinien sind in einem Quell-Repository versioniert, durchlaufen denselben Änderungskontrollprozess wie Anwendungscode und werden über eine CI/CD-Pipeline auf die OPA-Engine ausgerollt. Jede Richtlinienänderung hat einen Autor, einen Prüfvermerk, einen Ausrollzeitpunkt und lässt sich mit einem einzigen Pipeline-Rollback auf eine frühere Version zurücksetzen. Diese Nachvollziehbarkeit ist ein wesentlicher Vorteil gegenüber Firewall-Regeln je Anwendung, die ohne Versionskontrolle anwachsen.

Kontextabhängige Zugriffsentscheidungen

ZTNA-Richtlinienentscheidungen können kontextuelle Signale über Identität und Geräte-Trust hinaus einbeziehen. Zeitbezogene Richtlinien beschränken den Zugriff auf sensible Anwendungen auf definierte Arbeitszeitfenster und verkleinern so das Expositionsfenster für Berechtigungsmissbrauch außerhalb normaler Arbeitszeiten. Geolokations- oder Netzwerkquellen-Richtlinie – von wo aus der Benutzer sich verbindet – kann die Policy-Engine auswerten: Eine klassifizierte Anwendung könnte den Zugriff nur von organisatorisch verwalteten Netzwerk-Ausgangspunkten oder bestimmten genehmigten Fernzugriffsorten erlauben. Die Risiko-Score-Integration erlaubt der Policy-Engine, ein numerisches Risikosignal einer User-and-Entity-Behavior-Analytics-Plattform (UEBA) zu verarbeiten: Hat das Zugriffsverhalten des Benutzers in den letzten 24 Stunden einen hohen Anomalie-Risiko-Score erzeugt, hebt die Engine die Zugriffsschwelle an und verlangt Stufen-MFA, bevor sie den Zugriff auf sensible Anwendungen freigibt.

Neubewertung des Sitzungsrisikos

Die traditionelle Zugriffskontrolle trifft eine Entscheidung beim Sitzungsstart und kehrt nicht zu ihr zurück. Die ZTNA-Kontinuierlichkeitsauswertung bewertet die Zugriffsentscheidung während der gesamten Sitzung in einem konfigurierbaren Abfrageintervall neu. Die Auswertungsschleife fragt den Identitätsanbieter nach Kontostatusänderungen (Kontosperrung oder Gruppenentzug seit Sitzungsbeginn), die EDR-Plattform nach neuen Bedrohungsereignissen auf dem Gerät, den Geräte-Konformitätsdienst nach Patch-Statusänderungen und den Risikobewertungsdienst nach Änderungen des Anomalie-Scores. Überschreitet eine Änderung einen Richtlinien-Schwellenwert, reagiert die Engine verhältnismäßig: Eine moderate Risikoerhöhung löst eine Stufen-MFA-Herausforderung ohne Sitzungsbeendigung aus; ein kritisches Ereignis – Kontosperrung, aktive EDR-Bedrohung, Zertifikatssperrung – löst die sofortige Sitzungsbeendigung aus. Das Modell der kontinuierlichen Auswertung bedeutet: Ein Angreifer, der ein Gerät mitten in der Sitzung kompromittiert, trifft auf ein Erkennungsfenster, das durch das Abfrageintervall begrenzt ist, nicht durch die gesamte Sitzungsdauer. Dieselben Grundsätze, die Programme zum privilegierten Zugriffsmanagement in der Verteidigung leiten – Just-in-Time-Zugriff, Sitzungsaufzeichnung und Echtzeit-Neubewertung des Risikos – gelten unmittelbar für das ZTNA-Design der kontinuierlichen Auswertung bei Sitzungen mit hohen Privilegien.

ZTNA für klassifizierte Netze: IL4/IL5-Einsatz

Kommerzielle cloudbasierte ZTNA-Dienste laufen in Multi-Tenant-Shared-Infrastruktur, die für klassifizierte Workloads nicht zugelassen ist. Verteidigungsprogramme auf den Auswirkungsstufen IL4 (Controlled Unclassified Information) und IL5 (National Security Systems) benötigen ein ZTNA-Einsatzmodell, das Kontrollebene und Anwendungsdatenverkehr innerhalb der akkreditierten Grenze hält.

Vor Ort betriebenes ZTNA für air-gapped klassifizierte Umgebungen

Eine Vor-Ort-ZTNA-Bereitstellung für ein klassifiziertes Netz repliziert die funktionalen Komponenten eines Cloud-ZTNA-Dienstes innerhalb der klassifizierten Enclave. Policy-Engine, Identitätsbroker, Sitzungsproxy und Geräte-Trust-Dienst werden alle als Vor-Ort-Rechen-Workloads betrieben – entweder auf dedizierter Hardware oder innerhalb des klassifizierten Kubernetes-Clusters. Alle Abhängigkeiten der Kontrollebene lösen sich innerhalb der Enclave: Der Identitätsanbieter ist die klassifizierte Active-Directory-Instanz, die EDR-Managementkonsole wird vor Ort betrieben, die Zertifizierungsstelle und der CRL-Dienst arbeiten innerhalb des Air-Gap, und kein Richtlinienauswertungsaufruf verlässt die Grenze des klassifizierten Netzes.

Die operativen Herausforderung, die für Air-Gap-ZTNA einzigartig ist, ist die Verteilung von Richtlinienaktualisierungen. In einem Cloud-ZTNA-Dienst werden Richtlinienänderungen zentral ausgerollt und verbreiten sich in Sekunden. In einer Air-Gap-Umgebung müssen Richtlinienaktualisierungen über den autorisierten Softwaretransfermechanismus geliefert werden – typischerweise ein Medientransferprozess durch die Akkreditierungsgrenze. Das bedeutet: ZTNA-Richtlinienänderungen erfordern vorausschauende Planung und lassen sich nicht mit der unter einer Minute liegenden Latenz von Cloud-Bereitstellungen anwenden. Der Änderungskontrollprozess für Air-Gap-ZTNA-Richtlinien muss diese Vorlaufzeit einrechnen, und Notfalländerungen (zum Beispiel der sofortige Entzug des Zugriffs eines kompromittierten Benutzers) müssen einen beschleunigten Weg durch den im Sicherheitsplan des Programms definierten Änderungskontrollprozess haben.

Design des domänenübergreifenden ZTNA-Proxys

Manche Verteidigungsanwendungsfälle verlangen von Benutzern in einem Netz niedrigerer Klassifizierung den Zugriff auf eine bestimmte, gefilterte Sicht auf Daten eines Systems höherer Klassifizierung – ein bereinigtes Lagebild, eine deklassifizierte Nachrichtendienste-Zusammenfassung oder einen nur lesbaren Datenfeed. Ein domänenübergreifender ZTNA-Proxy löst das, indem er ZTNA-Zugriffskontrolle mit domänenübergreifender Inhaltsprüfung an der Klassifizierungsgrenze kombiniert. Der Proxy empfängt die Zugriffsanfrage des Benutzers aus dem nicht klassifizierten Netz, verifiziert Identität und Geräte-Trust gegen die nicht klassifizierte ZTNA-Policy-Engine und fragt dann die klassifizierte Anwendung im Namen des Benutzers über die Cross-Domain-Lösung an. Die CDS-Komponente prüft den Inhalt der Anwendungsantwort, wendet die Freigaberegeln für die Klassifizierung der Daten an und filtert oder schwärzt Elemente, die für die Freigabe an den nicht klassifizierten Anforderer nicht autorisiert sind. Nur die gefilterte Antwort wird an die Benutzersitzung im nicht klassifizierten Netz zurückgegeben. Der Proxy muss als Teil der ATOs beider Netze und der domänenübergreifenden Autorisierung akkreditiert sein, wobei die ZTNA-+-CDS-Architektur ausdrücklich als kombinierte Kontrolle beschrieben ist.

Migration von Legacy-VPN zu ZTNA

Die VPN-zu-ZTNA-Migration in einem Verteidigungsprogramm ist ein operativer Übergang, der die Zugriffskontinuität für missionskritische Anwendungen bewahren und die Zugriffskontrolle schrittweise verschärfen muss. Eine phasenweise Migrationsstrategie, die VPN und ZTNA während der Übergangsphase parallel betreibt, ist der Standardansatz.

Phasenweise Migrationsstrategie

Die Migration verläuft in drei Phasen. In der ersten Phase wird die ZTNA-Infrastruktur bereitgestellt und für die Identitäts- und Geräte-Trust-Integration validiert, aber es werden keine Anwendungen eingebunden, und die Nutzer greifen weiterhin über das VPN auf alle Anwendungen zu. Eine Pilotnutzergruppe – typischerweise das IT- und Sicherheitsteam – testet den ZTNA-Zugriff auf eine Anwendung geringer Kritikalität, um den durchgängigen Ablauf zu validieren, bevor Missionsnutzer einbezogen werden. In der zweiten Phase werden Anwendungen in Prioritätsreihenfolge in ZTNA eingebunden. Während dieser Phase bleibt das VPN als Rückfallebene für noch nicht eingebundene Anwendungen verfügbar. Die Nutzer werden auf das ZTNA-Zugriffsportal und den Agenten geschult, bevor ihre primären Anwendungen auf ZTNA umgestellt werden. In der dritten Phase wird, sobald alle Anwendungen im Umfang eingebunden sind und die Pilotnutzerschaft den Zugriff validiert hat, der VPN-Zugriff für die migrierte Nutzergruppe entzogen. Das VPN-Gateway bleibt in der Endphase nur für Anwendungen verfügbar, die ausdrücklich nicht in den ZTNA-Umfang fallen (falls vorhanden), und wird abgeschaltet, wenn die verbleibenden Anwendungen die Einbindung abschließen.

Reihenfolge der Anwendungseinbindung

Anwendungen werden in einer Reihenfolge in ZTNA eingebunden, die das Risiko minimiert und von frühen Einbindungen lernt, bevor komplizierte Fälle angegangen werden. Beginnen Sie mit internen Webportalen und Dashboards – HTTPS-Anwendungen mit browserbasierten Frontends, die naturgemäß mit Reverse-Proxy-ZTNA funktionieren und breite Nutzergruppen haben, die schnell Rückmeldung geben. Gehen Sie als Nächstes zu Produktivitätsanwendungen über: E-Mail-Weboberflächen, Dokumentenmanagement-Portale, interne Wikis. Wenden Sie sich danach den Anwendungskategorien zu, die das Agentenmodell erfordern: per RDP genutzte Windows-Server, per SSH genutzte Linux-Systeme, Thick-Client-C2- oder Missionsanwendungen. Für zuletzt bleiben die komplexesten Integrationen vorbehalten: Anwendungen mit nicht standardisierten Authentifizierungsmechanismen, hochkritische Echtzeitsysteme und jede Anwendung, die derzeit auf VPN-IP-basierter Zugriffskontrolle statt auf Authentifizierung auf Anwendungsschicht beruht.

Nutzerschulung für ZTNA-Zugriffsmuster

Die ZTNA-Nutzererfahrung unterscheidet sich spürbar vom VPN. Nutzer, die das VPN gewohnt sind, verbinden sich einmal am Tagesanfang und greifen den Rest des Tages transparent auf alle Anwendungen zu. Mit ZTNA greift der Nutzer über das ZTNA-Portal oder über agentenabgefangene Verbindungen auf Anwendungen zu und kann im Tagesverlauf auf Stufen-MFA-Herausforderungen treffen, wenn die kontinuierliche Auswertung eine Risikoänderung erkennt. Die Schulung muss drei Verhaltensänderungen adressieren. Erstens das Zugriffsportal: wohin navigieren, um Anwendungen zu finden, und wie die Authentifizierung per CAC abläuft. Zweitens der Agent: wie der ZTNA-Agent in der Taskleiste erscheint, was seine Statusanzeigen bedeuten und wie Probleme gemeldet werden. Drittens die Stufen-Authentifizierung: wie eine MFA-Herausforderung mitten in der Sitzung aussieht (damit Nutzer eine legitime Stufen-Aufforderung nicht für einen Phishing-Versuch halten) und wie sie abgeschlossen wird. Programme, die vor der Einbindung des ersten Missionsnutzers in Nutzerschulung investieren, sehen deutlich geringere Helpdesk-Ticket-Volumina und schnellere Akzeptanz als Programme, die ZTNA ohne Schulungsprogramm ausrollen.