ZTNA-Implementierungsleitfaden: Vom Entwurf bis zum Produktivbetrieb

Ein Zero-Trust-Network-Access-Projekt (ZTNA) ist dann erfolgreich, wenn Zugriffsentscheidungen eindeutiger werden, ohne die tägliche Arbeit unnötig zu erschweren.

Dafür reicht es nicht, nur ein Gateway zu installieren. Eine produktive Implementierung muss Identitäten, Geräte, geschützte Ressourcen, Richtlinien, Zugriffswege, Protokollierung, Support und Wiederherstellung zu einem gemeinsamen Betriebsmodell verbinden.

Dieser Leitfaden konzentriert sich darauf, ZTNA in kontrollierten Schritten einzuführen. Er ergänzt die Architekturerklärung in So funktioniert ZTNA und den Migrationsablauf im VPN-zu-ZTNA-Migrationsleitfaden.

1. Ergebnis definieren, bevor Richtlinien erstellt werden​

Beginnen Sie mit dem Zugriffsproblem, das gelöst werden soll.

Sinnvolle Implementierungsziele sind zum Beispiel:

• breite Remote-VPN-Berechtigungen durch ressourcenbezogenen Zugriff ersetzen
• dauerhafte Berechtigungen für sensible Systeme reduzieren
• Auftragnehmerzugriff vom Mitarbeiterzugriff trennen
• Identitäts- und Gerätekontext in Autorisierungsentscheidungen einbeziehen
• die Audit-Sichtbarkeit für den Zugriff auf private Ressourcen verbessern
• On-Premises-, Self-Hosted- oder getrennte Umgebungen unterstützen

Starten Sie nicht mit einer großen Richtlinienmatrix. Legen Sie zuerst das Geschäftsziel sowie die betroffenen Benutzer und Ressourcen fest.

Ein Pilotprojekt mit klaren Grenzen lässt sich leichter validieren als ein Vorhaben mit dem Ziel „Zero Trust überall ausrollen“.

2. Identitäten, Geräte und Ressourcen inventarisieren​

ZTNA-Entscheidungen setzen voraus, dass Anforderer, Endpunkt und Ziel bekannt sind.

Erstellen Sie drei Inventare.

Identitäten​

Dokumentieren Sie:

• Mitarbeiter- und Administratorgruppen
• Auftragnehmer und temporäre Benutzer
• Identitätsquelle und Authentifizierungsmethode
• Eigentümerschaft von Gruppen oder Rollen
• Prozesse für Eintritt, Rollenwechsel und Austritt
• Anforderungen an privilegierten oder genehmigungspflichtigen Zugriff

Geräte​

Dokumentieren Sie:

• verwaltete und nicht verwaltete Endgeräte
• Verfahren zur Geräteaufnahme
• relevante Betriebssysteme
• Eigentumsmodell der Geräte
• verfügbare MDM- oder EDR-Posture-Signale
• Geräte, die den üblichen Managed-Access-Pfad nicht nutzen können

Ressourcen​

Dokumentieren Sie:

• Anwendungen und Server
• erforderliche Protokolle und Ports
• fachlichen Eigentümer
• Sensitivität
• Benutzergruppen mit tatsächlichem Zugriffsbedarf
• Abhängigkeiten von weiteren Diensten

Definieren Sie eine Ressource nicht nur als Subnetz, wenn der tatsächliche Bedarf der Zugriff auf eine einzelne Anwendung oder einen Server ist.

3. Das Bereitstellungsmodell bewusst auswählen​

ZTNA-Produkte können Kontroll- und Durchsetzungskomponenten an unterschiedlichen Orten betreiben. Entscheiden Sie vor dem Rollout, welches Betriebsmodell zur Umgebung passt.

Zu klärende Fragen sind:

• Wer betreibt die Zugriffsplattform: Ihr Unternehmen, ein MSP oder der Anbieter?
• Muss der Kernzugriff auch ohne Internetverbindung weiter funktionieren?
• Befinden sich geschützte Systeme in isolierten oder Air-Gapped-Netzen?
• Welche externen Identitäts-, Posture-, Monitoring- oder Authentifizierungsdienste dürfen Abhängigkeiten sein?
• Wie funktionieren Updates, Lizenzierung, Backups und Disaster Recovery?

Bei ZTXGate kann die Kernplattform vom Kunden oder einem MSP ohne verpflichtende CoreZT-gehostete Cloud-Control-Plane betrieben werden. Verbundene Installationen können optional ZTXHub für zentralisiertes Software-Update- und Lizenzmanagement nutzen; Standalone-Installationen verwenden manuelle Abläufe.

Self-Hosted und Cloud-ZTNA vergleichen

4. Identitätslebenszyklus vor Zugriffsrichtlinien etablieren​

Authentifizierung weist eine Identität nach. Provisionierung und Lifecycle-Kontrollen bestimmen, ob diese Identität noch existieren sollte und welchen organisatorischen Kontext sie trägt.

Vor produktivem Zugriff sollte festgelegt werden:

• wo Benutzer angelegt werden
• wie Gruppen oder Rollen zugewiesen werden
• wie Identitätsänderungen die ZTNA-Plattform erreichen
• wie Zugriff beim Austritt eines Benutzers entfernt wird
• wie temporäre Identitäten ablaufen
• welche Authentifizierungsmethoden für normalen und sensiblen Zugriff geeignet sind

ZTXGate kann OIDC für Authentifizierung sowie SCIM für Provisionierung und Synchronisierung des Identitätslebenszyklus verwenden.

Identität und Gerätevertrauen erkunden

5. Geräteaufnahme und Gerätevertrauen gestalten​

Eine Benutzeridentität allein sagt nicht, von welchem Endpunkt eine Anfrage stammt.

Definieren Sie:

• wie Geräte aufgenommen werden
• ob bestimmte Ressourcen nur von registrierten Geräten erreichbar sein dürfen
• was bei Austausch oder Verlust eines Geräts geschieht
• wie Gerätezugriff widerrufen wird
• ob für ausgewählte Ressourcen Posture-Informationen erforderlich sind

In verbundenen Umgebungen kann ZTXGate Posture-Informationen aus unterstützten Integrationen wie Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne Singularity, CrowdStrike und Jamf verwenden.

Behandeln Sie Posture als Richtlinieneingabe, nicht als Ersatz für Identität oder Ressourcenautorisierung.

6. Ressourcen am tatsächlichen Zugriffszweck modellieren​

Das Ressourcenmodell sollte abbilden, was ein Benutzer tatsächlich erreichen darf.

Anstatt einer Entwicklungsgruppe Zugriff auf ein gesamtes Netzwerksegment zu geben, können beispielsweise die benötigten Dienste separat definiert werden:

• Quellcodeverwaltung
• Build-System
• Entwicklungs-Applikationsserver
• interne Dokumentation

Produktionsadministration bleibt dann eine eigene Ressource mit eigenem Richtlinienumfang.

Für jede Ressource sind folgende Fragen hilfreich:

• Wem gehört sie?
• Wer benötigt Zugriff?
• Von welchen Geräten?
• Über welches Protokoll?
• Unter welchen Zeit- oder Genehmigungsbedingungen?
• Ist zusätzliche Authentifizierung erforderlich?

Eine kleinere Anzahl verständlicher Richtlinien ist meist leichter zu betreiben als ein dichtes Regelwerk voller Ausnahmen.

7. Für jede Ressource den passenden Zugriffsweg wählen​

Nicht jede Ressource benötigt denselben Zugriffsmechanismus.

Bei ZTXGate sind zwei Zugriffsmuster besonders wichtig:

Verwalteter Zugriff​

Verwaltete Endgeräte verwenden WireGuard-basierte Konnektivität für autorisierte Ressourcen. Der Tunnel stellt den sicheren Transport bereit; die ZTXGate-Richtlinie bestimmt, welche Ressourcen tatsächlich erreichbar sind.

Dieser Weg eignet sich, wenn der Endpunkt Netzwerkprotokollzugriff auf die geschützte Ressource benötigt.

Clientloser Webzugriff​

Lizenzierter clientloser Zugriff kann private HTTP- und HTTPS-Anwendungen proxien, sodass autorisierte Benutzer sie über den Browser erreichen können, ohne WireGuard auf dem Endgerät zu installieren.

Das ist für geeignete Webanwendungen sinnvoll, unter anderem in bestimmten Auftragnehmer- und Drittanbieter-Szenarien.

Wählen Sie den Zugriffsweg anhand der Ressourcenanforderung, anstatt jede Anwendung durch denselben Mechanismus zu zwingen.

WireGuard & ZTNA · Clientless ZTNA

8. Mit einfachen Richtlinien beginnen​

Eine erste Richtlinie sollte sich in einem Satz erklären lassen.

Zum Beispiel:

Mitglieder der Entwicklungsrolle dürfen von registrierten Geräten auf die Entwicklungsanwendung zugreifen.

Fügen Sie weitere Bedingungen erst hinzu, wenn sie eine reale Anforderung lösen.

Je nach Ressource kann eine Richtlinie Folgendes berücksichtigen:

• Identität und Rolle
• registriertes Gerät
• verfügbare Geräte-Posture
• Netzwerkstandort
• Zeit
• Ressource
• Zugriffsdauer
• Genehmigungsstatus
• Anforderungen an zusätzliche Authentifizierung

Für sensible Ressourcen können temporärer Zugriff, Request-and-Approve-Abläufe und Step-up-Authentifizierung eingesetzt werden.

Übernehmen Sie historische VPN- oder Firewall-Regeln nicht automatisch. Eine ZTNA-Einführung ist eine Gelegenheit, Berechtigungen ohne klaren Geschäftszweck zu entfernen.

9. Audit und Monitoring in den Pilot integrieren​

Verschieben Sie Sichtbarkeit nicht auf die Zeit nach dem Rollout.

Während des Piloten sollte überprüft werden, ob Betreiber folgende Fragen beantworten können:

• Wer hat Zugriff versucht?
• Welches Gerät war beteiligt?
• Welche Ressource wurde angefordert?
• Wurde die Anfrage erlaubt oder abgelehnt?
• Welche Richtlinienbedingung beeinflusste die Entscheidung?
• Wann wurde temporärer Zugriff erteilt oder beendet?
• Können relevante Ereignisse an den Monitoring-Workflow des Unternehmens weitergeleitet werden?

ZTXGate unterstützt Audit-Datensätze und kann relevante Ereignisse über unterstützte Formate und Transporte an SIEM-Plattformen weiterleiten.

SIEM-Integration erkunden

10. Fehler- und Ablehnungsfälle validieren​

Eine erfolgreiche Verbindung beweist nur den Happy Path.

Testen Sie negative Fälle gezielt:

• Benutzer besitzt nicht die erforderliche Rolle
• nicht registriertes oder widerrufenes Gerät
• Posture-Bedingung nicht erfüllt
• temporärer Zugriff abgelaufen
• Genehmigungsanfrage abgelehnt
• Step-up-Authentifizierung fehlgeschlagen
• externe Identitäts- oder Posture-Abhängigkeit nicht verfügbar
• Ressource nicht verfügbar

Das erwartete Ergebnis sollte für Security- und Support-Teams nachvollziehbar sein.

In getrennten Umgebungen sollte das System in dem Konnektivitätszustand getestet werden, in dem es tatsächlich betrieben wird. Externe Cloud-Dienste können keine Richtliniensignale liefern, wenn sie nicht erreichbar sind.

11. Mit einer klar begrenzten Benutzergruppe pilotieren​

Wählen Sie einen Pilotbereich mit bekannten Zugriffsanforderungen und beherrschbarem Rollback.

Ein sinnvoller Pilot umfasst typischerweise:

• eine oder zwei Benutzergruppen
• eine kleine Anzahl Ressourcen
• klar benannte Ressourcenverantwortliche
• definierte Supportkontakte
• messbare Erfolgskriterien

Validieren Sie die tägliche Arbeit, bevor Sie den Umfang erweitern.

Erfolgskriterien können sein:

• Benutzer erreichen alle genehmigten Ressourcen
• nicht autorisierte Ressourcen bleiben unerreichbar
• Eintritts-/Austrittsänderungen greifen korrekt
• Gerätewiderruf funktioniert
• temporärer Zugriff endet wie vorgesehen
• Betreiber finden die erforderlichen Audit-Daten
• Supportmitarbeiter können häufige Fehler diagnostizieren

12. In Wellen ausrollen​

Nach dem Pilot werden Benutzer und Ressourcen in kontrollierten Wellen hinzugefügt.

Eine mögliche Reihenfolge ist:

1. weniger kritische interne Anwendungen
2. Entwicklungs- und Engineering-Ressourcen
3. Auftragnehmer- oder Partnerzugriff
4. administrative Dienste
5. sensible Produktionssysteme

Die richtige Reihenfolge hängt von Ihrem Unternehmen ab. Entscheidend ist, dass jede Welle klein genug bleibt, um sie zu verstehen, zu testen und bei Bedarf zurückzunehmen.

Wenn ZTNA VPN-Zugriff ersetzt, sollte der alte VPN-Umfang nach Stabilisierung jeder Welle reduziert werden, statt breite Doppelberechtigungen dauerhaft bestehen zu lassen.

13. Betrieb und Wiederherstellung vorbereiten​

Produktives ZTNA benötigt auch nach dem ersten Rollout ein Betriebsmodell.

Definieren Sie Verantwortlichkeiten für:

• Eigentümerschaft und Überprüfung von Zugriffsrichtlinien
• Benutzer- und Gerätelebenszyklus
• Genehmigung temporären Zugriffs
• Identitäts- und Posture-Integrationen
• Umgang mit Zertifikaten und Schlüsseln
• Log-Aufbewahrung und SIEM-Weiterleitung
• Software-Updates
• Schutz von Backups
• Tests der Wiederherstellung

ZTXGate verwendet ein Backup-und-Restore-Modell für Disaster Recovery statt konventioneller geclusterter Hochverfügbarkeit. Administratoren sollten daher planen, wie Backups geschützt und wie bei Bedarf eine Ersatzinstallation wiederhergestellt wird.

Sicherheit & Vertrauen

14. Richtlinien nach dem Rollout überprüfen​

ZTNA sollte nicht zu einer neuen Sammlung dauerhafter Berechtigungen werden, die niemand mehr überprüft.

Planen Sie Reviews für:

• Benutzer, die eine Ressource nicht mehr benötigen
• Geräte, die widerrufen werden sollten
• Rollen, die zu breit geworden sind
• temporäre Ausnahmen, die dauerhaft geworden sind
• ungenutzte Ressourcen
• Abhängigkeiten von externen Diensten
• Richtlinien mit wiederholten Ablehnungen oder Supportfällen

Ziel ist, Zugriff am aktuellen Geschäftsbedarf auszurichten und nicht an historischer Bequemlichkeit.

Beispiel für eine Implementierungsreihenfolge​

Eine praktische erste Einführung könnte so aussehen:

Wo ZTXGate hineinpasst​

ZTXGate kombiniert die beschriebenen Bausteine in einer vom Kunden oder MSP betriebenen ZTNA-Plattform:

• OIDC-Authentifizierung und SCIM-Provisionierung
• individuelle Geräteaufnahme
• unterstützte MDM-/EDR-Posture-Signale
• ressourcenbezogene Zugriffsrichtlinien
• kontinuierliche Durchsetzung bei Änderungen relevanter Richtlinienbedingungen
• WireGuard-basierter verwalteter Zugriff
• lizenzierter clientloser HTTP/HTTPS-Zugriff
• temporärer und genehmigungspflichtiger Zugriff
• Optionen für Step-up-Authentifizierung
• Audit-Daten und SIEM-Weiterleitung
• On-Premises-, Cloud-, Hybrid- und Air-Gapped-Bereitstellungsoptionen
• optionales ZTXHub für zentralisiertes Update- und Lizenzmanagement

Eine sinnvolle Implementierung beginnt dennoch klein: Identitäts- und Gerätelebenszyklus etablieren, eine begrenzte Zahl Ressourcen definieren, einfache Richtlinien erstellen, positive und negative Fälle validieren und erst dann erweitern, wenn das Betriebsmodell funktioniert.

VPN-zu-ZTNA-Migration · So funktioniert ZTNA · ZTNA-Architektur

Verwandte Leitfäden und nächste Schritte​

• So funktioniert ZTNA — wiederholen Sie das grundlegende ZTNA-Entscheidungsmodell.
• VPN-zu-ZTNA-Migrationsleitfaden — planen Sie Parallelbetrieb und schrittweisen Rückbau breiter VPN-Zugriffe.
• Self-Hosted vs Cloud-ZTNA — wählen Sie Betriebs- und Abhängigkeitsmodell.