Zum Hauptinhalt springen

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:

On-Premises-ZTXGate-Zugriffsfluss: Benutzer und Gerät passieren Identitäts-, Geräte-, Richtlinien-, Durchsetzungs- und Audit-Kontrollen, bevor eine autorisierte On-Premises-Ressource erreicht wird

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.

ZTXBAS entdecken

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.

BetriebsmodellStandalone ZTXGateZTXGate mit optionalem ZTXHub
KernzugriffBetrieb durch Kunde oder MSPBetrieb durch Kunde oder MSP
CoreZT-gehostete Cloud-AbhängigkeitNicht erforderlichFür ZTXGate-Kernzugriff nicht erforderlich
LizenzverwaltungManuellZentral über CoreZT-betriebenes ZTXHub
Softwareupdate-VerwaltungManuellZentral über CoreZT-betriebenes ZTXHub
Air-gapped BereitstellungUnterstütztAbhä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.

AspektCloud-Delivered ZTNAOn-Premises ZTXGate
KontrollinfrastrukturPrimär vom Anbieter betriebenVom Kunden oder MSP betrieben
BereitstellungsortDurch Servicearchitektur vorgegebenVom Kunden oder MSP gewählt
InfrastrukturwartungPrimär AnbieterKunde oder MSP
Lokaler AnwendungstrafficArchitekturabhängigKann innerhalb der gewählten Umgebung bleiben
Externe DienstabhängigkeitMeist integraler BestandteilKernzugriff benötigt keine CoreZT-gehostete Control Plane
Air-gapped BetriebArchitekturabhängigUnterstütztes Standalone-Modell
Recovery-ModellAnbieter-/serviceabhängigBackup 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.