Zum Hauptinhalt springen

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.

BetriebsmodellStandalone ZTXGateZTXGate mit optionalem ZTXHub
KernzugriffBetrieb durch Kunde oder MSPBetrieb durch Kunde oder MSP
CoreZT-gehostete Control Plane erforderlichNeinNein
LizenzverwaltungManuellZentral über CoreZT-betriebenes ZTXHub
Softwareupdate-VerwaltungManuellZentral über CoreZT-betriebenes ZTXHub
Vollständig air-gappedUnterstütztFü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.

ZTXBAS entdecken

Self-Hosted ZTNA vs. Cloud-Delivered ZTNA

Keines der beiden Modelle ist automatisch für jede Organisation richtig.

AspektCloud-Delivered ZTNASelf-Hosted ZTXGate
KontrollinfrastrukturVom Anbieter betriebenVom Kunden oder MSP betrieben
InfrastrukturwartungPrimär Verantwortung des AnbietersVerantwortung von Kunde oder MSP
BereitstellungsortDurch Anbieterarchitektur vorgegebenVon Kunde oder MSP gewählt
Externe DienstabhängigkeitMeist Bestandteil des DienstesKernbetrieb benötigt keine CoreZT-gehostete Control Plane
Air-gapped BetriebArchitekturabhängigUnterstütztes Bereitstellungsmodell
Operative KontrolleMit Anbieter geteiltUnter Kontrolle von Kunde oder MSP
Skalierung und VerfügbarkeitVom Anbieter verwaltetes ServicemodellKunde 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