Zum Hauptinhalt springen

So funktioniert Zero Trust Network Access mit ZTXGate

ZTNA ist nicht einfach ein verschlüsselter Tunnel oder eine andere Methode, sich mit einem privaten Netzwerk zu verbinden. Der architektonische Unterschied besteht darin, Zugriff explizit rund um Benutzer, Gerät, geschützte Ressource und aktuelle Richtlinienbedingungen zu autorisieren.

ZTXGate bündelt diese Entscheidungen in einer Plattform, die vom Kunden oder einem MSP betrieben werden kann – On-Premises, in Cloud-Infrastruktur, hybrid oder vollständig air-gapped.

Die ZTNA-Entscheidung

Darf dieser Benutzer auf diesem Gerät diese Ressource unter den aktuellen Bedingungen erreichen?

ZTXGate kann dafür Benutzeridentität und -rolle, registriertes Gerät, Device Posture, Netzwerkstandort, Zeit, geschützte Ressource, Zugriffsdauer, Genehmigungsstatus und Step-up-Anforderungen verwenden. Netzwerkverbindung allein gilt nicht als ausreichende Autorisierung.

ZTXGate-Architektur im Überblick

Logische ZTXGate-ZTNA-Architektur mit Identität, Authentifizierung, Geräte- und Kontextsignalen, Richtlinie, WireGuard- oder clientlosem HTTP/HTTPS-Zugriff sowie Audit- und SIEM-Sichtbarkeit

Die Darstellung ist logisch: Die Blöcke beschreiben Sicherheitsverantwortlichkeiten und nicht zwingend einzelne Softwareprozesse.

Identität: Wer fordert Zugriff an?

OIDC kann Authentifizierung und Identity Claims liefern, SCIM kann Lifecycle-Informationen aus unterstützten Identitätssystemen synchronisieren. Identität wird damit ein Richtliniensignal und nicht ein einmaliges Tor zu breitem Netzwerkzugriff.

Identität & Gerätevertrauen entdecken

Gerät: Welches Endgerät fordert Zugriff an?

ZTXGate registriert Benutzergeräte einzeln. Ein verlorenes oder nicht mehr vertrauenswürdiges Gerät kann widerrufen werden, ohne zwingend andere Geräte desselben Benutzers zu deaktivieren. In verbundenen Umgebungen können Signale aus Microsoft Intune, Microsoft Defender for Endpoint, SentinelOne Singularity, CrowdStrike und Jamf einfließen.

Richtlinie: Was darf dieser Benutzer mit diesem Gerät erreichen?

Richtlinien sind auf definierte Ressourcen ausgerichtet. Entwickler können Entwicklungssysteme erreichen, während Produktion gesperrt bleibt; Auftragnehmer können eine Anwendung zeitlich begrenzt erhalten; Administratoren können für sensible Ressourcen Genehmigung und zusätzliche Authentifizierung benötigen.

Verwalteter Zugriff: WireGuard als sicherer Transport

Verwaltete Endgeräte nutzen WireGuard-basierte Konnektivität für autorisierten Netzwerkzugriff. WireGuard liefert den sicheren Transport; ZTXGate ergänzt Identitäts-, Geräte-, Ressourcen-, Lifecycle-, Genehmigungs-, Posture- und Auditkontext. Ein bestehender WireGuard-Tunnel ist daher nicht selbst die Richtlinie.

WireGuard & ZTNA entdecken

Clientless Access: HTTP/HTTPS über den Proxy

Für unterstützte HTTP- und HTTPS-Anwendungen kann ZTXGate clientlosen Zugriff über seinen richtliniendurchsetzenden Proxy bereitstellen. Der Proxy terminiert die eingehende Verbindung und baut die autorisierte Verbindung zur geschützten Anwendung neu auf. Dadurch kann er dort, wo das implementierte Richtlinienmodell es unterstützt, anwendungsbewusste HTTP-Kontrollen anwenden.

Clientless ZTNA entdecken

Kontinuierliche Richtliniendurchsetzung

Eine frühere Freigabe muss nicht dauerhaft gültig bleiben. Ändern sich Zugriffsfenster, Rollen oder Posture-Bedingungen, kann ZTXGate die relevanten Bedingungen weiter auswerten und Zugriff entsprechend widerrufen.

Step-up-Authentifizierung

Sensible Ressourcen können zusätzliche Verifizierung verlangen. Lizenziertes ZTXBAS ist eng als Bibliothek integriert und bietet phishing-resistente biometrische Authentifizierung in verbundenen wie air-gapped Bereitstellungen. In verbundenen Umgebungen können außerdem unterstützte Dienste wie Okta Verify und Duo verwendet werden. Standalone ZTXBAS bleibt ein separates kostenloses Produkt für Anwendungsentwickler.

Audit und Sicherheitssichtbarkeit

ZTXGate zeichnet Zugriffs-, Authentifizierungs- und Richtlinienaktivitäten auf. Ereignisse können mit unterstützten Formaten wie syslog, CEF oder JSON an Monitoring-Umgebungen weitergegeben werden. Audit-Sichtbarkeit ersetzt kein SIEM, liefert ihm jedoch zentralen Zugriffskontext.

Externe Integrationen sind Richtliniensignale, keine Kernabhängigkeiten

OIDC, SCIM, Intune, Defender for Endpoint, SentinelOne, CrowdStrike, Jamf, Okta Verify, Duo und SIEM-Plattformen erweitern den verfügbaren Kontext, wenn sie erreichbar sind. In vollständig air-gapped Umgebungen nutzt ZTXGate die dort vorhandenen Identitäts-, Authentifizierungs-, Geräte- und Monitoring-Fähigkeiten.

Bereitstellungs- und Control-Plane-Modell

ZTXGate kann eigenständig ohne verpflichtende CoreZT-Cloud-Control-Plane betrieben werden. Betreiber ist der Kunde oder ein MSP. Standalone kann die Bereitstellung vollständig air-gapped bleiben; Lizenzierung und Updates erfolgen dann manuell. Für verbundene Bereitstellungen bietet CoreZT optional ZTXHub für zentrale Lizenz- und Softwareupdate-Verwaltung.

Control-Plane-Modell entdecken

Backup und Disaster Recovery

ZTXGate verwendet derzeit keine konventionelle Cluster-HA. Administratoren können periodische Backups konfigurieren und bei Bedarf in eine neue ZTXGate-Bereitstellung wiederherstellen. Das ist ein Backup-and-Restore-Modell, kein Active/Active- oder Active/Passive-Cluster.

Was ZTNA nicht ersetzt

ZTNA bleibt eine Schicht einer größeren Sicherheitsarchitektur. Sichere Anwendungsentwicklung, Betriebssystem-Härtung, lokale Netzwerksegmentierung, Endpoint Protection, Zertifikats- und Schlüsselmanagement, Vulnerability Management, Monitoring, Incident Response sowie Backup und Disaster Recovery bleiben erforderlich.

Architektur weiter erkunden