Was ist ein ZPA-Microtenant?
Ein ZPA-Microtenant ist ein abgegrenzter Verwaltungsbereich innerhalb eines Tenants von Zscaler Private Access. Er wird über eine Authentifizierungs-Domain definiert und an Admins delegiert, typischerweise je Land, Abteilung oder Tochtergesellschaft. Der Microtenant-Admin verwaltet App-Segmente, Connectoren und Richtlinien seines Bereichs eigenständig und sieht Dashboards und Logs nur für die eigenen Nutzer. Standardmäßig bleiben die Ressourcen verschiedener Microtenants voneinander getrennt; einzelne App-Segmente lassen sich gezielt teilen. Microtenants lösen damit ein Organisationsproblem: dezentrale Verantwortung, ohne dafür separate Zscaler-Tenants betreiben zu müssen.
ZPA-Microtenant im Detail
Die Zuständigkeitsgrenzen sind klar gezogen. Innerhalb seines Bereichs verwaltet der delegierte Admin laut Zscaler-Dokumentation App-Segmente und Segment-Gruppen, Server und Server-Gruppen, App Connectoren samt Gruppen sowie die Richtlinien für die eigenen Nutzer. Zentrale Grundlagen bleiben dem Default-Microtenant vorbehalten: IdP-Konfiguration, SAML-Attribute, Enrollment-Zertifikate und die Verwaltung der Microtenants selbst; für delegierte Admins sind diese Bereiche nur lesbar.
Aktiviert wird die Funktion über den Zscaler-Support. Zu den dokumentierten Grenzen gehören: keine Unterstützung bei aktivierter Disaster-Recovery-Funktion, einzelne Funktionen wie AppProtection nur für reguläre Tenants, und beim Löschen eines Microtenants werden auch dessen Log-Receiver entfernt. Für Zugriffe über Bereichsgrenzen hinweg teilt der Admin App-Segmente explizit, die Trennung bleibt der Regelfall.
Warum sind Microtenants im Zscaler-Betrieb wichtig?
Microtenants beantworten eine Frage, die in Konzernen und bei Dienstleistern ständig auftaucht: Wie bekommt jede Einheit Verantwortung für ihren Bereich, ohne dass jemand den Überblick über das Ganze verliert? Die delegierte Administration verkürzt Wege, weil die Tochtergesellschaft ihre App-Segmente selbst pflegt, statt jede Änderung zentral zu beantragen. Gleichzeitig begrenzt die Bereichsgrenze den Schaden von Fehlern und die Sichtbarkeit von Logs auf die eigene Einheit.
Der Preis ist Koordinationsaufwand: Wer verwaltet was, welche Segmente sind geteilt, welche Grundlagen liegen zentral? Ohne dokumentierte Antwort entstehen Ping-Pong-Tickets zwischen zentraler IT und Bereichs-Admins. Und wer zusätzlich mehrere echte Tenants betreibt, etwa als Dienstleister für viele Kunden, braucht darüber noch eine Ebene: den konsolidierten Blick über alle Tenants und ihre Microtenants hinweg.
Typische Fehlerquellen
- Microtenant mit Tenant verwechselt: Erwartungen an Vertrags-, Lizenz- oder Datentrennung gehören auf die Tenant-Ebene, nicht auf die Verwaltungsgrenze.
- Zuständigkeiten unklar: Für IdP, SAML-Attribute und Zertifikate ist der Default-Microtenant zuständig; Bereichs-Admins warten sonst auf Rechte, die sie nie bekommen.
- Geteilte App-Segmente ohne Inventar: Nach Umstrukturierungen weiß niemand mehr, welcher Bereich welche Segmente mit wem teilt.
- Disaster-Recovery-Planung ohne Blick in die Doku: Die Kombination mit Microtenants wird laut Zscaler nicht unterstützt und gehört früh ins Architektur-Review.
Microtenants in der Praxis: so hilft CentaurNexus
CentaurNexus verwaltet mehrere ZPA-Microtenants mandantenfähig aus einer Oberfläche: Die Funktion Microtenants zeigt die Bereiche nebeneinander, während die strukturelle Trennung erhalten bleibt. Kombiniert mit RBAC-Domain-Scoping sieht jedes Team nur seinen Zuständigkeitsbereich, vom Konzern-Helpdesk bis zum Bereichs-Admin der Tochtergesellschaft, ohne Zscaler-Admin-Konto. Für Dienstleister kommt die Cross-Tenant-Sicht dazu, die mehrere Kunden-Tenants unter einem Dach bedienbar macht. Wie das Zusammenspiel in der Praxis aussieht, zeigt der Beitrag Mehrere Zscaler-Mandanten aus einer Oberfläche verwalten.
Verwandte Begriffe
Häufige Fragen zum ZPA-Microtenant
Der Tenant ist die oberste Instanz eines Unternehmens im Zscaler-Dienst mit eigener Konfiguration und eigenem Vertrag. Ein Microtenant ist ein Verwaltungsbereich innerhalb eines ZPA-Tenants: Er wird über eine Authentifizierungs-Domain abgegrenzt und an Admins delegiert, etwa je Land, Abteilung oder Tochtergesellschaft. Es entsteht kein zweiter Tenant, sondern eine Zuständigkeitsgrenze im bestehenden.
Laut Zscaler-Dokumentation verwaltet er die Konfiguration seines Bereichs eigenständig: App-Segmente und Segment-Gruppen, Server und Server-Gruppen, App Connectoren samt Gruppen sowie die Richtlinien für die eigenen Nutzer. Dashboards und Logs zeigen ausschließlich den eigenen Bereich. App-Segmente lassen sich bei Bedarf mit anderen Microtenants teilen.
Zentrale Grundlagen verwaltet nur der Admin des Default-Microtenants: die IdP-Konfiguration, SAML-Attribute, Enrollment-Zertifikate und das Anlegen der Microtenants selbst. Für Custom-Microtenant-Admins sind diese Bereiche nur lesbar. Diese Arbeitsteilung verhindert, dass delegierte Bereiche die gemeinsame Authentifizierungs-Basis des Tenants verändern.
Standardmäßig nicht: Nutzer erreichen die Ressourcen ihres eigenen Microtenants und die des globalen Bereichs, nicht aber die anderer Microtenants. Wo ein Zugriff gewollt ist, teilt der Admin einzelne App-Segmente gezielt mit anderen Microtenants. So bleibt die Trennung der Regelfall und die Freigabe die dokumentierte Ausnahme.
Die Funktion wird laut Dokumentation über den Zscaler-Support für die Organisation freigeschaltet. Zu beachten sind die dokumentierten Grenzen: Mit aktivierter Disaster-Recovery-Funktion werden Microtenants nicht unterstützt, einzelne Funktionen wie AppProtection bleiben regulären Tenants vorbehalten, und das Löschen eines Microtenants entfernt auch dessen Log-Receiver.
- Zscaler Help Portal: About Microtenants - help.zscaler.com
- Zscaler Help Portal: Configuring Microtenants - help.zscaler.com
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.