Self-Hosted Zero Trust Network Access
Betreiben Sie Ihre Zugriffsplattform in Infrastruktur, die von Ihrem Unternehmen oder MSP betrieben wird.
ZTXGate bietet Zero Trust Network Access, ohne für den Kernbetrieb eine zwingende, von CoreZT gehostete Cloud-Control-Plane zu benötigen. Stellen Sie es On-Premises, in einer Cloud-VM, über hybride Infrastruktur hinweg oder innerhalb einer isolierten Umgebung bereit.
Was Self-Hosted ZTNA bedeutet
Bei ZTXGate bedeutet Self-Hosted, dass die Software in Infrastruktur läuft, die vom Kunden oder von einem MSP im Auftrag des Kunden betrieben wird.
Der Betreiber der Bereitstellung bestimmt, wo ZTXGate läuft, wie der Host abgesichert wird, mit welchen Netzwerken er verbunden ist, welche Identity- und Security-Integrationen verwendet werden, welche Ressourcen geschützt sind und wie Zugriffsrichtlinien definiert werden.
ZTXGate ist kommerziell unterstützte Software, die außerhalb einer zwingenden, von CoreZT gehosteten Access-Control-Plane bereitgestellt wird. Self-Hosted bedeutet nicht, dass das Produkt Open Source ist.
Die Zugriffsplattform nahe an Ihren Ressourcen halten
On-Premises
Betreiben Sie ZTXGate in einem Rechenzentrum, Büro oder einer anderen vom Kunden oder MSP betriebenen Umgebung.
Cloud
Stellen Sie ZTXGate auf einer Linux-VM neben cloudgehosteter Infrastruktur bereit.
Hybrid
Verwenden Sie dasselbe Zugriffsmodell für Ressourcen, die zwischen On-Premises- und Cloud-Umgebungen verteilt sind.
Air-Gapped
Stellen Sie ZTXGate in isolierten Umgebungen bereit, in denen die zentrale Zugriffsplattform nicht von einem externen Cloud-Dienst abhängen darf.
Keine zwingende vendor-gehostete Cloud-Control-Plane
Einige ZTNA-Architekturen hängen für Kontrolle, Richtlinien, Identity Brokering, Traffic Handling oder andere Funktionen von einem durch den Anbieter betriebenen Cloud-Dienst ab.
ZTXGate kann vom Kunden oder von einem MSP betrieben werden. Zentrale Richtlinien- und Zugriffsdurchsetzung läuft innerhalb dieser ZTXGate-Bereitstellungsumgebung.
Das kann wichtig sein, wenn eine Organisation Infrastruktur unter eigener operativer Kontrolle halten möchte, interne oder regulatorische Bereitstellungsanforderungen besitzt, Anwendungen unabhängig von einer externen SaaS-Control-Plane betreiben will oder Internetkonnektivität bewusst eingeschränkt hat.
Das bedeutet nicht, dass jede optionale Integration ohne externe Konnektivität funktioniert. Wird ZTXGate mit einem externen Identity Provider, einer MDM- oder EDR-Plattform, einem SIEM-Dienst oder einem Drittanbieter-Authentifizierungsdienst konfiguriert, hängt diese Integration naturgemäß davon ab, dass der entsprechende Dienst erreichbar ist.
Control-Plane-Modell entdecken
Architektur unter Ihrer Kontrolle
Verwaltete Endgeräte verwenden WireGuard-basierte Konnektivität für autorisierten Zugriff über ZTXGate. Die Plattform kann außerdem clientlosen HTTP/HTTPS-Zugriff unterstützen, wenn dieses Zugriffsmodell passend ist.
Entscheidend ist, dass die Autorisierung über die gewählte ZTXGate-Bereitstellungsumgebung erfolgt und keine von CoreZT gehostete Access Plane voraussetzt.
Self-Hosted bedeutet nicht von bestehenden Systemen isoliert
In verbundenen Umgebungen kann ZTXGate in bereits verwendete Systeme integriert werden:
- Identity: OIDC-Authentifizierung und SCIM-Provisionierung
- Gerätesicherheit: unterstützte MDM- und EDR-Posture-Signale
- Authentifizierung: ZTXBAS in allen Bereitstellungsmodellen sowie Okta Verify Push und Duo Push, wenn diese Cloud-Dienste erreichbar sind
- SIEM: Syslog-, CEF- und JSON-Export
Diese Integrationen sind optionale Komponenten rund um die vom Kunden oder MSP betriebene Zugriffsplattform.
Standalone oder zentral verwaltet mit ZTXHub
ZTXGate benötigt für den Betrieb keinen zentralen CoreZT-Dienst. Eine Standalone-Bereitstellung kann Zugriff lokal verwalten, auch in einer vollständig air-gapped Umgebung.
Für verbundene Bereitstellungen, die Softwareupdates und Lizenzierung zentral verwalten möchten, ist ZTXHub ein optionaler Dienst, der CoreZT gehört und von CoreZT betrieben wird.
Wird ZTXHub nicht verwendet, bleibt ZTXGate unabhängig. Lizenzierung und Softwareupdates werden dann manuell durchgeführt.
| Betriebsmodell | Standalone ZTXGate | ZTXGate mit optionalem ZTXHub |
|---|---|---|
| Kernzugriff | Betrieb durch Kunde oder MSP | Betrieb durch Kunde oder MSP |
| CoreZT-gehostete Control Plane erforderlich | Nein | Nein |
| Lizenzverwaltung | Manuell | Zentral über CoreZT-betriebenes ZTXHub |
| Softwareupdate-Verwaltung | Manuell | Zentral über CoreZT-betriebenes ZTXHub |
| Vollständig air-gapped | Unterstützt | Für vollständige Isolation Standalone-Modus verwenden |
ZTXBAS in jedem Bereitstellungsmodell
Wird ZTXBAS mit ZTXGate lizenziert, ist es eng als Bibliothek integriert und benötigt keine separate ZTXBAS-Serverbereitstellung. Es funktioniert in verbundenen, On-Premises-, hybriden und vollständig air-gapped ZTXGate-Umgebungen.
Damit steht eine phishing-resistente biometrische Authentifizierung zur Verfügung, die innerhalb derselben Bereitstellungsgrenze verbleiben kann. Cloudabhängige MFA-Dienste wie Okta Verify und Duo bleiben verfügbar, wenn ihre jeweiligen Dienste erreichbar sind.
Self-Hosted ZTNA vs. Cloud-Delivered ZTNA
Keines der beiden Modelle ist automatisch für jede Organisation richtig.
| Aspekt | Cloud-Delivered ZTNA | Self-Hosted ZTXGate |
|---|---|---|
| Kontrollinfrastruktur | Vom Anbieter betrieben | Vom Kunden oder MSP betrieben |
| Infrastrukturwartung | Primär Verantwortung des Anbieters | Verantwortung von Kunde oder MSP |
| Bereitstellungsort | Durch Anbieterarchitektur vorgegeben | Von Kunde oder MSP gewählt |
| Externe Dienstabhängigkeit | Meist Bestandteil des Dienstes | Kernbetrieb benötigt keine CoreZT-gehostete Control Plane |
| Air-gapped Betrieb | Architekturabhängig | Unterstütztes Bereitstellungsmodell |
| Operative Kontrolle | Mit Anbieter geteilt | Unter Kontrolle von Kunde oder MSP |
| Skalierung und Verfügbarkeit | Vom Anbieter verwaltetes Servicemodell | Kunde plant Kapazität und Resilienz |
Cloud-Delivered ZTNA kann den Aufwand für Infrastrukturmanagement reduzieren. Self-Hosted ZTNA bietet mehr Kontrolle darüber, wo die Zugriffsplattform betrieben wird.
Self-Hosted bedeutet auch mehr Verantwortung
Mehr Kontrolle über die Infrastruktur bringt operative Verantwortung mit sich.
Die Organisation, die ZTXGate betreibt, ist auch für angemessene Praktiken rund um Host-Sicherheit, Betriebssystempflege, Netzwerkkonfiguration, Backups, Wiederherstellung, Verfügbarkeitsplanung, Administratorzugriff, Monitoring und Produktupdates verantwortlich.
Dies ist ein bewusster Trade-off.
Moderne Identity ohne Aufgabe der Bereitstellungskontrolle
Eine vom Kunden oder MSP betriebene Zugriffsplattform kann weiterhin moderne Identity-Dienste nutzen. In verbundenen Umgebungen kann ZTXGate Benutzer über einen OIDC Identity Provider authentifizieren und SCIM zur Synchronisierung des Identity-Lifecycle verwenden.
Wo die Zugriffsplattform läuft und welches Identity-System die Organisation verwendet, sind getrennte Architekturentscheidungen.
Gerätevertrauen
ZTXGate registriert einzelne Benutzergeräte und kann Geräteidentität in Richtlinien einbeziehen. Wo unterstützte externe Posture-Dienste verfügbar sind, können auch Compliance- oder Risikoinformationen zu Zugriffsentscheidungen beitragen.
In isolierten Umgebungen verwenden Richtlinien naturgemäß die dort verfügbaren Identity-, Geräte- und Sicherheitssignale.
Air-Gapped und nicht verbundene Umgebungen
Die zentrale ZTXGate-Zugriffsplattform kann ohne Abhängigkeit von einer CoreZT-gehosteten Cloud-Control-Plane bereitgestellt werden.
Eine air-gapped Architektur muss jedoch als Ganzes betrachtet werden. Internetgehostete Identity-, MDM-, EDR-, SIEM- oder Push-Authentifizierungsdienste benötigen Konnektivität, wenn sie Teil der Bereitstellung sind.
ZTXGate macht eine externe Abhängigkeit nicht innerhalb eines Air Gaps verfügbar; es ermöglicht der zentralen Zugriffsplattform selbst, innerhalb der isolierten Umgebung zu verbleiben.
Backup und Disaster Recovery
ZTXGate bietet kein konventionelles HA-Clustering. Stattdessen kann das Administrationsportal regelmäßige Backups der Bereitstellung erstellen.
Geht eine Bereitstellung verloren, kann ein Backup in eine frische ZTXGate-Installation eingespielt werden, um die konfigurierte Umgebung schnell wiederherzustellen. Dies ist ein Backup-and-Restore-Disaster-Recovery-Modell, kein Active/Active- oder Active/Passive-Failover.
Organisationen sollten Backup-Kopien schützen und Ersatzinfrastruktur sowie Wiederherstellungsverfahren gemäß ihren eigenen Recovery-Zielen planen.
Wer sollte Self-Hosted ZTNA in Betracht ziehen?
ZTXGate kann gut passen, wenn:
- Ihre Organisation bereits Linux-Infrastruktur betreibt
- private Anwendungen hauptsächlich On-Premises oder in vom Kunden/MSP betriebener Cloud-Infrastruktur liegen
- der Kernzugriff nicht von einer vendor-gehosteten Control Plane abhängen soll
- Sie hybride Infrastruktur betreiben
- isolierte oder air-gapped Umgebungen unterstützt werden müssen
- der Bereitstellungsort eine architektonische oder regulatorische Rolle spielt
- Ihr Team Infrastruktureigentum einem vollständig vom Anbieter betriebenen SaaS-Modell vorzieht
Ein Cloud-Delivered Service kann sinnvoller sein, wenn Ihre Organisation Infrastrukturverantwortung und Wartung ausdrücklich auslagern möchte.
Häufig gestellte Fragen
Ist ZTXGate Open Source?
Nein. ZTXGate ist kommerziell lizenzierte und unterstützte Software, die in Infrastruktur des Kunden oder MSP betrieben wird.
Benötigt ZTXGate ein CoreZT-Cloud-Konto für den Kernzugriff?
Der Kernzugriff benötigt keine zwingende, von CoreZT gehostete Cloud-Control-Plane. Bestimmte verbundene Integrationen hängen naturgemäß von ihren jeweiligen Diensten ab.
Kann ZTXGate On-Premises oder in einer Public Cloud laufen?
Ja. Beide sind unterstützte Bereitstellungsmodelle.
Kann ZTXGate in einer air-gapped Umgebung betrieben werden?
ZTXGate kann in isolierten Umgebungen ohne CoreZT-gehostete Cloud-Control-Plane bereitgestellt werden. Welche Funktionen verfügbar sind, hängt davon ab, welche Identity-, Authentifizierungs-, Posture-, Monitoring- und unterstützenden Systeme innerhalb dieser Umgebung erreichbar sind.
Beseitigt Self-Hosting den operativen Aufwand?
Nein. Kunde oder MSP, die die Bereitstellung betreiben, sind für Absicherung und Wartung der ZTXGate-Host-Infrastruktur verantwortlich.
Benötigen wir ZTXHub?
Nein. ZTXHub ist optional und wird von CoreZT betrieben. Standalone-Bereitstellungen verwenden manuelle Abläufe für Lizenzierung und Softwareupdates; verbundene Bereitstellungen können ZTXHub zur zentralen Verwaltung verwenden.
Bietet ZTXGate Hochverfügbarkeit?
Nicht im konventionellen Clustering-Sinn. ZTXGate verwendet ein Backup-and-Restore-Disaster-Recovery-Modell, bei dem eine gespeicherte Konfiguration in eine frische Bereitstellung wiederhergestellt werden kann.
Zero Trust dort halten, wo Ihre Infrastruktur betrieben wird
Wenn Ihre Organisation ressourcenbezogenen Zero-Trust-Zugriff benötigt und die Zugriffsplattform gleichzeitig innerhalb der von Ihrem Team oder MSP betriebenen Infrastruktur halten möchte, bietet ZTXGate ein Self-Hosted-Bereitstellungsmodell.
ZTXGate entdecken · Self-Hosted vs Cloud ZTNA · On-Premises ZTNA · Air-Gapped ZTNA · Sicherheit & Vertrauen entdecken