On-Premises Zero Trust Network Access
Bringen Sie Zero-Trust-Zugriff zu Anwendungen und Infrastruktur, die bereits in Ihrem Rechenzentrum, Büro, Standort oder privaten Umfeld betrieben werden.
ZTXGate läuft innerhalb der von Ihnen betriebenen Infrastruktur. So können Sie identitäts-, geräte- und ressourcenbewussten Zugriff anwenden, ohne den Kernzugriff von einer CoreZT-gehosteten Cloud-Control-Plane abhängig zu machen.
Was On-Premises ZTNA bedeutet
On-Premises ZTNA hält die Zugriffsplattform nahe bei den Anwendungen und Systemen, die sie schützt.
Statt jede Zugriffsentscheidung durch einen vom Anbieter betriebenen Cloud-Dienst zu leiten, kann ZTXGate auf Linux-Infrastruktur laufen, die vom Kunden oder MSP innerhalb der Umgebung betrieben wird, in der die geschützten Ressourcen bereits vorhanden sind.
Dieses Modell kann sinnvoll sein, wenn:
- wichtige Anwendungen in einem privaten Rechenzentrum verbleiben
- interne Systeme unter lokaler operativer Kontrolle bleiben sollen
- Internetkonnektivität begrenzt oder bewusst eingeschränkt ist
- der Bereitstellungsort eine architektonische oder regulatorische Rolle spielt
- dieselben Richtlinien für lokale und entfernte Benutzer gelten sollen
On-Premises beschreibt wo die Zugriffsplattform läuft. Es bedeutet nicht, dass die umgebende Umgebung von Cloud-Identity-, MDM-, EDR-, SIEM- oder anderen Diensten getrennt sein muss, wenn die Organisation diese verwenden möchte.
Zero Trust sollte auch innerhalb des Netzwerks gelten
Die physische Präsenz in einem Unternehmensnetzwerk sollte nicht automatisch bestimmen, welche Ressourcen ein Benutzer erreichen darf.
ZTXGate hält den Zugriff an Benutzer, Gerät, Ressource und Richtlinie ausgerichtet – unabhängig davon, ob der Benutzer remote arbeitet oder bereits innerhalb eines Büro- oder Rechenzentrumsnetzes ist.
Ein Entwickler kann für Entwicklungssysteme autorisiert werden, ohne Zugriff auf nicht verwandte Produktionsressourcen zu erhalten. Ein Finance-Benutzer kann genehmigte Anwendungen erreichen, ohne allein wegen interner Netzwerkkonnektivität als vertrauenswürdig zu gelten.
Dieselben Richtlinienkonzepte können deshalb für lokalen und entfernten Zugriff gelten.
Wie ZTXGate On-Premises betrieben wird
Eine typische Bereitstellung platziert ZTXGate auf Linux-Infrastruktur, die vom Kunden betrieben wird.
Verwaltete Endgeräte nutzen WireGuard-basierte Konnektivität, wenn Tunnelzugriff passend ist. HTTP- und HTTPS-Anwendungen können alternativ über den clientlosen ZTXGate-Proxy bereitgestellt werden, wenn browserbasierter Zugriff geeigneter ist.
Auf hoher Ebene:
Die geschützte Anwendung muss nicht öffentlich erreichbar werden, nur weil Benutzer Remote Access benötigen.
Lokalen Traffic lokal halten
Wenn ZTXGate und die geschützten Ressourcen in derselben Umgebung bereitgestellt werden, muss der Zugriff nicht über einen CoreZT-gehosteten Dienst zurückgeführt werden.
Das kann den Traffic-Pfad für private Anwendungen vereinfachen und hilft Organisationen, die Kontrolle darüber zu behalten, wo die Zugriffsinfrastruktur betrieben wird.
Externe Integrationen bleiben optionale Architekturentscheidungen. Beispielsweise kann eine Organisation einen cloudgehosteten Identity Provider verwenden, während ZTXGate und der Anwendungstraffic On-Premises bleiben.
Vorhandene Identity- und Gerätesysteme nutzen
Eine vom Kunden oder MSP betriebene Bereitstellung benötigt kein separates Identity-Silo.
In verbundenen Umgebungen kann ZTXGate integriert werden mit:
- OIDC Identity Providern für Authentifizierung
- SCIM für Benutzer-Lifecycle-Synchronisierung
- unterstützten MDM- und EDR-Plattformen für Device Posture
- SIEM-Plattformen für Ereignissichtbarkeit
- unterstützten Step-Up-Authentifizierungsmethoden
Die Zugriffsplattform bleibt On-Premises, während diese Integrationen dort eingesetzt werden, wo sie sinnvoll sind.
In Umgebungen, in denen externe Dienste nicht verfügbar sind, kann ZTXGate stattdessen mit den Diensten und Sicherheitssignalen arbeiten, die innerhalb dieser Umgebung erreichbar sind.
ZTXBAS über alle Bereitstellungsmodelle hinweg
Wird ZTXBAS mit ZTXGate lizenziert, ist es eng als Bibliothek integriert und funktioniert in verbundenen, On-Premises- und vollständig air-gapped Umgebungen, ohne einen separaten ZTXBAS-Server zu benötigen.
Das ist nützlich, wenn eine Organisation phishing-resistente biometrische Authentifizierung möchte, ohne diesen Authentifizierungspfad von einem Internet-gehosteten MFA-Dienst abhängig zu machen.
Cloudabhängige Optionen wie Okta Verify oder Duo bleiben für verbundene Bereitstellungen verfügbar, sofern diese Dienste erreichbar sind.
Standalone oder zentral verwaltet
ZTXGate kann als Standalone-Bereitstellung betrieben werden.
Verbundene Bereitstellungen können optional ZTXHub verwenden, einen Dienst, der CoreZT gehört und von CoreZT betrieben wird. ZTXHub ermöglicht zentrale Verwaltung von Softwareupdates und Lizenzen über mehrere Bereitstellungen hinweg.
Entscheidend ist: ZTXHub ist optional.
Control-Plane-Modell entdecken
Eine Bereitstellung ohne ZTXHub kann ZTXGate weiterhin unabhängig betreiben, auch in isolierten Umgebungen. Lizenzierung und Softwareupdates werden in diesem Modell manuell gehandhabt.
| Betriebsmodell | Standalone ZTXGate | ZTXGate mit optionalem ZTXHub |
|---|---|---|
| Kernzugriff | Betrieb durch Kunde oder MSP | Betrieb durch Kunde oder MSP |
| CoreZT-gehostete Cloud-Abhängigkeit | Nicht erforderlich | Für ZTXGate-Kernzugriff nicht erforderlich |
| Lizenzverwaltung | Manuell | Zentral über CoreZT-betriebenes ZTXHub |
| Softwareupdate-Verwaltung | Manuell | Zentral über CoreZT-betriebenes ZTXHub |
| Air-gapped Bereitstellung | Unterstützt | Abhängig von gewählter Hub-/Netzwerkarchitektur |
Ressourcenbezogener Zugriff
On-Premises bedeutet nicht die Rückkehr zu breitflächigem Netzwerkvertrauen.
ZTXGate-Richtlinien können berücksichtigen:
- Benutzeridentität
- Rolle
- registriertes Gerät
- Device Posture, sofern verfügbar
- Netzwerkstandort
- Zeit
- Ressource
- Zugriffsdauer
So können private Anwendungen On-Premises verbleiben und gleichzeitig explizit autorisierter Zugriff umgesetzt werden.
Temporärer und genehmigter Zugriff
Sensible On-Premises-Systeme benötigen häufig nur gelegentlichen Administrations- oder Troubleshooting-Zugriff statt permanenter Berechtigungen.
ZTXGate unterstützt temporären und Request-and-Approve-Zugriff, damit ein autorisierter Genehmiger ein definiertes Zeitfenster freigeben kann und die Berechtigung danach automatisch abläuft.
Dies kann für Produktionssysteme, Administrationsanwendungen, temporäre Projekte und Arbeiten durch Drittparteien eingesetzt werden.
Backup und Disaster Recovery
ZTXGate bietet kein konventionelles High-Availability-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-HA.
Organisationen sollten Backup-Frequenz, Backup-Schutz, Ersatzinfrastruktur und Wiederherstellungsverfahren entsprechend ihren Recovery-Zielen planen.
On-Premises ZTNA vs. Cloud-Delivered ZTNA
Keines der Modelle ist automatisch für jede Organisation richtig.
| Aspekt | Cloud-Delivered ZTNA | On-Premises ZTXGate |
|---|---|---|
| Kontrollinfrastruktur | Primär vom Anbieter betrieben | Vom Kunden oder MSP betrieben |
| Bereitstellungsort | Durch Servicearchitektur vorgegeben | Vom Kunden oder MSP gewählt |
| Infrastrukturwartung | Primär Anbieter | Kunde oder MSP |
| Lokaler Anwendungstraffic | Architekturabhängig | Kann innerhalb der gewählten Umgebung bleiben |
| Externe Dienstabhängigkeit | Meist integraler Bestandteil | Kernzugriff benötigt keine CoreZT-gehostete Control Plane |
| Air-gapped Betrieb | Architekturabhängig | Unterstütztes Standalone-Modell |
| Recovery-Modell | Anbieter-/serviceabhängig | Backup und Restore in frische Bereitstellung |
Cloud-Delivered ZTNA kann Infrastrukturmanagement reduzieren. On-Premises ZTNA bietet mehr Kontrolle über Platzierung und Betrieb.
Wo On-Premises ZTNA passt
ZTXGate kann eine Evaluierung wert sein für:
- private Rechenzentrumsanwendungen
- interne Administrationsoberflächen
- Büro- oder Standortinfrastruktur
- hybride Umgebungen mit wichtigen On-Premises-Ressourcen
- eingeschränkte Netzwerke
- Organisationen, die Sicherheitsinfrastruktur selbst betreiben möchten
Für vollständig getrennte Umgebungen siehe Air-Gapped ZTNA.
Für das umfassendere Bereitstellungsmodell siehe Self-Hosted ZTNA.
Häufig gestellte Fragen
Benötigt On-Premises ZTNA Internetzugang?
Der Kernbetrieb von ZTXGate benötigt keine CoreZT-gehostete Cloud-Control-Plane. Externe Integrationen benötigen nur dann Konnektivität, wenn Sie diese Dienste verwenden.
Können lokale Benutzer mit denselben Richtlinien wie Remote-Benutzer gesteuert werden?
Ja. Richtlinien können sich auf Identität, Gerät, Ressource und Kontext konzentrieren, statt lokale Netzwerkpräsenz als ausreichende Autorisierung zu behandeln.
Können wir weiterhin unseren Cloud Identity Provider verwenden?
Ja, wenn der Identity-Dienst erreichbar ist. Der On-Premises-Betrieb von ZTXGate verhindert die Nutzung von Cloud-Identity-Diensten nicht.
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, sodass eine gespeicherte Konfiguration in eine frische Bereitstellung wiederhergestellt werden kann.
Zugriff nahe an den Systemen halten, die Sie betreiben
Bringen Sie Zero-Trust-Richtlinien zu On-Premises-Anwendungen, ohne die Zugriffsplattform in einen vendor-gehosteten Cloud-Dienst zu zwingen.