Mehrere Zscaler-Mandanten aus einer Oberfläche verwalten

MSPs, Systemhäuser und Konzern-IT betreiben selten nur einen Zscaler-Tenant. Wer mehrere Mandanten managt, kämpft mit vielen Logins, ständigem Kontextwechsel und fehlendem einheitlichen Blick. So bündeln Sie den Betrieb in einer Oberfläche, ohne die harte Mandantentrennung aufzugeben.

Das Problem: viele Tenants, viele Logins, kein gemeinsamer Blick

Zscaler skaliert exzellent pro Mandant. Sobald Sie aber mehrere Tenants betreuen, etwa als MSP mit einem Portfolio aus Kundenumgebungen oder als Konzern mit getrennten Tenants je Tochtergesellschaft oder Region, verlagert sich die Reibung vom Produkt in den Betrieb. Jeder Mandant hat sein eigenes Admin-Portal, seine eigenen Zugangsdaten und seinen eigenen Kontext.

Im Alltag heißt das: Ein Helpdesk-Mitarbeiter nimmt ein Ticket an, muss aber erst herausfinden, zu welchem Tenant der betroffene Nutzer gehört, sich dort separat anmelden, sich im richtigen Bereich orientieren und den Vorgang dokumentieren. Beim nächsten Ticket beginnt das Spiel von vorne, oft in einem anderen Mandanten. Diese Kontextwechsel kosten Zeit, erhöhen die Fehlerquote und machen ein sauberes, tenant-übergreifendes Reporting mühsam.

Hinzu kommt die Rechtefrage. Damit der Helpdesk überhaupt arbeitsfähig ist, bekommt er oft breitere Zugriffe, als der einzelne Vorgang erfordert. Bei einem einzigen Tenant ist das schon heikel. Über ein ganzes Portfolio hinweg wird es zu einem echten Governance-Thema: Wer durfte wann was in welchem Mandanten sehen oder ändern?

Die Lösung: ein Cross-Tenant-Cockpit auf Basis der Zscaler OneAPI

CentaurNexus ist ein souveränes Single Pane of Glass für Zscaler, mit Produktivbetrieb für EU-Kunden vollständig auf STACKIT in der EU und dokumentierten Datenschutz- und Datenwegen. Es baut ausschließlich auf der offiziellen Zscaler OneAPI auf und ergänzt den Betrieb um eine Steuerungsebene, die mehrere Tenants gleichzeitig bedienbar macht. Die Zscaler-Plattform bleibt die Quelle der Wahrheit, das Cockpit legt eine einheitliche Arbeits- und Governance-Schicht darüber.

Statt fünf, zehn oder mehr getrennter Admin-Portale arbeitet Ihr Team in einer Oberfläche. Der Wechsel zwischen Mandanten wird zu einem Filter, nicht zu einem neuen Login. Suche, Befund und beantragte Änderungen laufen über dieselbe Bedienlogik, egal welcher Tenant gerade betroffen ist.

360-Grad-Suche über Tenants hinweg

Der Kern für den Helpdesk ist der 360-Grad-Nutzerbefund. User Support Center und Unified Support Center bündeln den Status eines Nutzers über ZIA, ZPA und ZDX in einer Ansicht: Richtlinienzuordnung, Zugriffspfade, Erlebnisqualität und Auffälligkeiten auf einen Blick. Der entscheidende Punkt für Multi-Tenant-Betrieb ist, dass diese Suche über die berechtigten Mandanten hinweg funktioniert. Der Mitarbeiter sucht nach einem Nutzer und landet im richtigen Kontext, ohne vorher zu wissen, in welchem Tenant er suchen muss.

Wichtig dabei: Dieser Befund funktioniert lesend, ohne breite Zscaler-Adminrechte zu vergeben. Der Helpdesk erhält Sichtbarkeit für seine Arbeit, nicht die Schlüssel zur gesamten Konfiguration.

RBAC-Domain-Scoping: jeder sieht nur seinen Bereich

Damit Zentralisierung nicht zur Aufweichung der Trennung wird, greift RBAC-Domain-Scoping. Jeder Benutzer ist auf genau die Mandanten und Bereiche begrenzt, für die er autorisiert ist. Ein Helpdesk-Team, das nur einen bestimmten Kunden betreut, sieht auch nur dessen Daten. MSP-Rollen können kontrolliert über mehrere Kunden hinweg arbeiten, wenn das Mandat es vorsieht.

Diese Grenze wird technisch erzwungen und nicht bloß optisch ausgeblendet. Die Mandantentrennung ist eine harte Isolation auf Datenebene, sodass ein Benutzer nicht durch Umwege oder direkte Abfragen an Daten gelangt, für die er keine Berechtigung hat. Zentrale Bedienung und saubere Trennung schließen sich damit nicht aus, sie werden zusammen durchgesetzt.

Freigaben nach Tenant-Policy und nachvollziehbare Auditierbarkeit

Sichtbarkeit allein reicht im Betrieb nicht, irgendwann müssen Änderungen passieren. Damit das über mehrere Tenants hinweg beherrschbar bleibt, sind schreibende Aktionen als beantragbare Vorgänge modelliert. Ein Mitarbeiter stellt einen Antrag, eine berechtigte Rolle gibt ihn frei. Dieses Freigabeverfahren der Tenant-Policy lässt sich dort verpflichtend machen, wo Änderungen sensibel sind.

Jede schreibende Aktion ist auditierbar. Wer hat wann in welchem Mandanten was beantragt, freigegeben oder ausgeführt, ist nachvollziehbar dokumentiert. Für regulierte Umgebungen und für die Zusammenarbeit zwischen MSP und Kunde ist dieser Audit-Trail oft der Unterschied zwischen einem tragfähigen Betriebsmodell und einer ständigen Rechtfertigungsdiskussion.

So sieht der Helpdesk-Vorgang in der Praxis aus

Der Effekt ist unmittelbar: schnellere Bearbeitung durch weniger Kontextwechsel, klar begrenzte Sichtbarkeit pro Rolle und ein sauberes Protokoll über alle Mandanten. Der Helpdesk wird handlungsfähig, ohne dass jemand pauschal zum Admin über fremde Tenants wird.

Analysen für den mandantenübergreifenden Betrieb

Über den reinen Helpdesk hinaus liefert das Cockpit mandantenbezogene Analysen, etwa zu verwaisten oder konflikthaften Regeln. Vorgeschlagene Korrekturen werden mit Kontext und Auswirkung dargestellt und über den Freigabeweg der jeweiligen Tenant-Policy umgesetzt. So bleibt jede Änderung nachvollziehbar.

Mandantenkontext vor jeder Aktion

Ein gemeinsamer Betreiberblick darf Tenantgrenzen nicht verwischen. Vor jedem Read, Ticket, Export und Write muss eindeutig sein, für welchen verwalteten Kunden der Vorgang gilt. Rollen und RLS begrenzen den Zugriff auf die Tenants, die dem MSP tatsächlich zugeordnet sind.

Auch gespeicherte Filter, zuletzt geöffnete Vorgänge und Benachrichtigungen bleiben tenantgebunden. Ein Wechsel des Kundenkontexts setzt die aktive Auswahl sichtbar neu. Dadurch kann eine Entscheidung nicht unbemerkt in einen anderen Tenant übernommen werden.

Wiederholbare Abläufe mit kundenspezifischer Verantwortung

MSPs profitieren von gemeinsamen Arbeitsmustern für Onboarding, Helpdesk, Freigaben, Reports und Reviews. Die Vorlage beschreibt den Ablauf, ersetzt aber nicht die Tenant-Policy des Kunden. Zuständige Rolle, Freigabegrenze, Datenquellen und Vertragsumfang bleiben kundenspezifisch.

Für die Abnahme werden mindestens zwei getrennte Testtenants mit unterschiedlichen Rollen und Quellen verwendet. Reads, Writes, Exporte, ITSM-Zuordnung und Audit müssen die Trennung in Erfolgs- und Fehlerfällen erhalten.