Self-Hosted vs Cloud-Delivered ZTNA
„Cloud-ZTNA“ und „Self-Hosted ZTNA“ wirken wie zwei einfache Kategorien. Tatsächlich gibt es mehrere Architekturen dazwischen. Die hilfreichere Frage lautet:
Wer betreibt die Control Plane, wo fließt der Anwendungsverkehr und welche Funktionen bleiben verfügbar, wenn externe Dienste ausfallen?
Dieser Leitfaden vergleicht die wesentlichen Modelle, ohne eines pauschal als überlegen darzustellen.
Vier häufige Betriebsmodelle
1. Cloud-Delivered ZTNA
Der Anbieter betreibt Management, Richtlinien und Zugriff als Cloud-Plattform. Das reduziert Infrastrukturarbeit für den Kunden und kann vom Anbieter verwaltete Verfügbarkeit und geografische Reichweite bieten.
2. Anbieter-Control-Plane + Kunden-Connectors
Der Anbieter betreibt zentrale Koordination und Richtlinien, während der Kunde Connectoren, Gateways oder Service Edges nahe privater Anwendungen bereitstellt. Der Datenverkehr kann je nach Produkt über Kundenkomponenten, Anbieter-Edges, direkte Peer-Pfade oder Kombinationen fließen.
3. Self-Hosted ZTNA
Kunde oder MSP betreibt Control- und Enforcement-Infrastruktur. Das schafft mehr Bereitstellungskontrolle, überträgt aber auch mehr Verantwortung für Wartung, Backup, Verfügbarkeit und Monitoring.
4. Standalone / Disconnected ZTNA
Die Plattform kann ohne verpflichtenden Anbieter-Control-Service arbeiten. Dieses Modell ist für dauerhaft isolierte, stark eingeschränkte oder vollständig air-gapped Umgebungen relevant.
Eigentum und Betrieb der Control Plane
Die Control Plane verwaltet typischerweise Konfiguration, Identitäten, Ressourcen, Richtlinien, Autorisierung und administrative Workflows. In Cloud-Diensten betreibt der Anbieter diese Ebene; beim Self-Hosting Kunde oder MSP. Keines ist automatisch sicherer — die Vertrauensgrenzen und Verantwortlichkeiten unterscheiden sich.
Fragen Sie: Wer darf administrieren? Wo liegt die Konfiguration? Welche externen Dienste braucht eine Richtlinienentscheidung? Was funktioniert bei Internetausfall? Welche Verantwortung trägt Anbieter, Kunde oder MSP?
Datenpfad
Der Standort der Control Plane sagt nicht automatisch, wo Anwendungsverkehr fließt. Ein Cloud-gemanagtes Produkt kann direkten Verkehr zwischen kundeneigenen Komponenten erlauben; ein anderes leitet über Anbieter-Edges. Bei Self-Hosting kann das Gateway in kundeneigener Infrastruktur liegen. Prüfen Sie daher getrennt, wo Richtlinien koordiniert werden und wo Anwendungsverkehr tatsächlich verläuft.
Internetabhängigkeit
Ein verbundener Dienst kann sehr verfügbar sein und dennoch Cloud-Zugriff für Management, neue Autorisierungen, Authentifizierungskoordination oder andere Funktionen benötigen. Für normale Unternehmensumgebungen kann das sinnvoll sein. Getrennte Umgebungen benötigen eine andere Antwort.
„Funktioniert bei kurzem Ausfall“ ist nicht dasselbe wie „kann dauerhaft air-gapped betrieben werden“.
Identität und Authentifizierung
Cloud-ZTNA integriert häufig Cloud Identity Provider. Self-Hosted-Produkte können externe Identity Provider, lokale Benutzer oder beides unterstützen. Eine air-gapped Architektur muss Identitäts- und Authentifizierungsverfahren nutzen, die innerhalb der getrennten Umgebung verfügbar sind. Dasselbe gilt für MFA: Ein Cloud-Push-Dienst kann ohne Konnektivität keine Transaktion abschließen.
Updates und Lizenzierung
Bei Cloud-Produkten liegt der Software-Lifecycle größtenteils beim Anbieter. Self-Hosted-Produkte benötigen ein Update-Modell, etwa Repositories, Managed Update Services oder manuelle Pakete. Getrennte Umgebungen brauchen kontrollierte Offline-Verfahren für Updates und Lizenzierung, wenn diese sonst externe Konnektivität erfordern würden.
Verfügbarkeit und Disaster Recovery
Cloud-Dienste liefern typischerweise Anbieter-Redundanz. Self-Hosting verlagert mehr Verantwortung auf den Betreiber. Produkte können Cluster, Active/Passive, verteilte Komponenten oder Backup-and-Restore verwenden — diese Modelle sind nicht gleichwertig. Käufer sollten nach der konkreten Architektur fragen statt generische Begriffe wie „HA“ oder „Resilienz“ zu akzeptieren.
Operative Verantwortung
| Bereich | Cloud-Delivered | Self-Hosted / Kunde oder MSP |
|---|---|---|
| Control-Plane-Infrastruktur | Anbieter | Kunde oder MSP |
| Plattform-Patching | Primär Anbieter | Kunde/MSP nach Anbieterprozess |
| Skalierung | Primär Anbieter | Kunde/MSP |
| Backups | Primär Anbieter-Service | Kunde/MSP |
| Monitoring-Verfügbarkeit | Anbieter + Kundenintegration | Kunde/MSP |
| Internetabhängigkeit | Produktabhängig, oft relevant | Produktabhängig; möglicherweise vermeidbar |
| Air-Gap-Eignung | Produktabhängig | Möglich, wenn Architektur es unterstützt |
Mehr Kontrolle bedeutet beim Self-Hosting zugleich mehr Verantwortung.
Compliance und Datenkontrolle
Manche Organisationen bevorzugen Cloud-ZTNA wegen standardisiertem, global verfügbarem Betrieb. Andere müssen Infrastruktur wegen isolierter Netzwerke, interner Architekturvorgaben, regulierter Umgebungen, Verträgen oder Daten-/Abhängigkeitsanforderungen innerhalb definierter Grenzen halten. Die richtige Entscheidung hängt von konkreten Anforderungen ab.
Wo ZTXGate einzuordnen ist
ZTXGate läuft in Infrastruktur, die vom Kunden oder MSP betrieben wird. Der Kernzugriff benötigt keine verpflichtende CoreZT-Cloud-Control-Plane.
Standalone ZTXGate: kann vollständig air-gapped bleiben; Lizenzierung und Updates sind manuell; integriertes ZTXBAS kann bei Lizenzierung innerhalb der getrennten Umgebung arbeiten.
ZTXGate mit optionalem ZTXHub: ZTXGate bleibt kunden- oder MSP-betrieben; ZTXHub gehört CoreZT und wird von CoreZT betrieben; es zentralisiert Softwareupdates und Lizenzverwaltung und ist für den Kernzugriff optional.
Resilienz: ZTXGate bietet derzeit kein konventionelles HA-Clustering. Periodische Backups können in eine neue Bereitstellung wiederhergestellt werden. Das ist Backup-and-Restore-DR, kein automatisches Failover.
Self-Hosted ZTNA entdecken · Keine verpflichtende Cloud-Control-Plane
Fragen an jeden ZTNA-Anbieter
- Wer betreibt die Control Plane?
- Wo fließt der Datenverkehr?
- Welche Kundenkomponenten sind nötig?
- Was geschieht bei Ausfall der Anbieter-Cloud?
- Kann das System dauerhaft getrennt arbeiten?
- Welche Identity-/Posture-Funktionen benötigen externe Dienste?
- Wie werden Updates bereitgestellt?
- Wie funktioniert Lizenzierung offline?
- Wie sieht das tatsächliche Verfügbarkeitsmodell aus?
- Wer ist für Backups und DR verantwortlich?
- Welche Funktionen benötigen Endgeräte-Software?
- Welche Verantwortung bleibt bei Kunde oder MSP?
Diese Antworten sagen meist mehr über das Betriebsmodell aus als das Etikett „ZTNA“.