Meerdere Zscaler-tenants vanuit één interface beheren

MSP's, systeemhuizen en enterprise-IT beheren zelden slechts één Zscaler-tenant. Wie meerdere tenants beheert, worstelt met veel logins, voortdurende contextwissels en het ontbreken van een eenduidig overzicht. Zo bundelt u het beheer in één interface, zonder de harde tenantscheiding op te geven.

Het probleem: veel tenants, veel logins, geen gezamenlijk overzicht

Zscaler schaalt uitstekend per tenant. Zodra u echter meerdere tenants beheert, bijvoorbeeld als MSP met een portfolio aan klantomgevingen of als concern met gescheiden tenants per dochteronderneming of regio, verschuift de wrijving van het product naar het beheer. Elke tenant heeft zijn eigen beheerportaal, zijn eigen inloggegevens en zijn eigen context.

In de dagelijkse praktijk betekent dat: een helpdeskmedewerker neemt een ticket aan, maar moet eerst uitzoeken tot welke tenant de betrokken gebruiker behoort, zich daar apart aanmelden, zich in het juiste gebied oriënteren en het proces documenteren. Bij het volgende ticket begint het spel opnieuw, vaak in een andere tenant. Deze contextwissels kosten tijd, verhogen het foutpercentage en maken een schone, tenant-overstijgende rapportage omslachtig.

Daar komt de rechtenvraag bij. Om de helpdesk überhaupt werkbaar te maken, krijgt deze vaak bredere toegang dan de individuele handeling vereist. Bij één tenant is dat al lastig. Over een heel portfolio wordt het een echt governance-vraagstuk: wie mocht wanneer wat zien of wijzigen in welke tenant?

De oplossing: een cross-tenant cockpit op basis van de Zscaler OneAPI

CentaurNexus is een single pane of glass voor ondersteunde Zscaler-workflows, met productie-omgeving voor EU-klanten volledig op STACKIT in de EU en gedocumenteerde privacy- en datapaden. Het bouwt voort op de officiële Zscaler OneAPI en voegt een beheer- en governancelaag toe voor meerdere beheerde tenants. Het Zscaler-platform blijft de bron van waarheid.

In plaats van vijf, tien of meer gescheiden beheerportalen werkt uw team in één interface. Wisselen tussen tenants wordt een filter, geen nieuwe login. Zoeken, bevindingen en aangevraagde wijzigingen verlopen via dezelfde bedieningslogica, ongeacht welke tenant op dat moment aan de orde is.

360-gradenzoekfunctie over tenants heen

De kern voor de helpdesk is de 360-gradenbevinding van de gebruiker. User Support Center en Unified Support Center bundelen de status van een gebruiker over ZIA, ZPA en ZDX in één weergave: policytoewijzing, toegangspaden, ervaringskwaliteit en bijzonderheden in één oogopslag. Het beslissende punt voor multi-tenantbeheer is dat deze zoekfunctie over de geautoriseerde tenants heen werkt. De medewerker zoekt naar een gebruiker en komt in de juiste context terecht, zonder vooraf te weten in welke tenant hij moet zoeken.

Belangrijk hierbij: deze bevinding werkt read-only, zonder brede Zscaler-beheerdersrechten toe te kennen. De helpdesk krijgt zichtbaarheid voor zijn werk, niet de sleutels tot de volledige configuratie.

RBAC-Domain-Scoping: iedereen ziet alleen zijn eigen gebied

Zodat centralisatie de scheiding niet verzwakt, geldt RBAC-Domain-Scoping. Elke gebruiker is precies beperkt tot de tenants en gebieden waarvoor hij is geautoriseerd. Een helpdeskteam dat slechts één bepaalde klant ondersteunt, ziet ook alleen de gegevens van die klant. MSP-rollen kunnen gecontroleerd over meerdere klanten heen werken, als het mandaat dat toestaat.

Deze grens wordt technisch afgedwongen en niet alleen visueel verborgen. Tenantscheiding is een harde isolatie op gegevensniveau, zodat een gebruiker niet via omwegen of directe query's bij gegevens komt waarvoor hij niet is geautoriseerd. Centrale bediening en nette scheiding sluiten elkaar dus niet uit, ze worden samen afgedwongen.

Goedkeuringen volgens het vierogenprincipe en volledige auditeerbaarheid

Zichtbaarheid alleen is in het beheer niet genoeg; op een gegeven moment moeten wijzigingen plaatsvinden. Om dit over meerdere tenants beheersbaar te houden, zijn schrijvende acties gemodelleerd als aan te vragen processen. Een medewerker dient een aanvraag in, een geautoriseerde rol keurt deze goed. Deze goedkeuringsprocedure, vastgelegd in het tenantbeleid, kan verplicht worden gesteld waar wijzigingen gevoelig liggen.

Elke schrijvende actie is auditeerbaar. Wie wat, wanneer en in welke tenant heeft aangevraagd, goedgekeurd of uitgevoerd, wordt navolgbaar gedocumenteerd. Voor gereguleerde omgevingen en voor de samenwerking tussen MSP en klant is deze audittrail vaak het verschil tussen een houdbaar beheermodel en een voortdurende verantwoordingsdiscussie.

Zo ziet het helpdeskproces er in de praktijk uit

Het effect is direct: snellere afhandeling door minder contextwissels, duidelijk begrensde zichtbaarheid per rol en een schoon logboek over alle tenants. De helpdesk wordt slagvaardig zonder dat iemand een algehele beheerder over andermans tenants wordt.

Analyses voor tenant-overstijgend beheer

Naast de pure helpdeskfunctie levert het cockpit tenantgebonden analyses, bijvoorbeeld over verweesde of conflicterende regels. Voorgestelde correcties worden getoond met context en impact en verlopen via de goedkeuringsweg van het betreffende tenantbeleid. Zo blijft elke wijziging navolgbaar.

Tenantcontext vóór elke actie

Een gezamenlijk beheerdersoverzicht mag tenantgrenzen niet vervagen. Vóór elke read, ticket, export en write moet ondubbelzinnig zijn voor welke beheerde klant het proces geldt. Rollen en rijniveaubeperkingen begrenzen de toegang tot de tenants die daadwerkelijk aan de MSP zijn toegewezen.

Ook opgeslagen filters, recent geopende taken en meldingen blijven tenantgebonden. Een wissel van klantcontext zet de actieve selectie zichtbaar terug. Zo kan een beslissing niet ongemerkt naar een andere tenant overlopen.

Herhaalbare processen met klantspecifieke verantwoordelijkheid

MSP's profiteren van gedeelde werkpatronen voor onboarding, helpdesk, goedkeuringen, rapporten en reviews. Een sjabloon standaardiseert het verloop binnen het tenantbeleid van de klant. Verantwoordelijke rol, goedkeuringsgrens, databronnen en contractomvang blijven klantspecifiek.

Voor de acceptatie worden minstens twee gescheiden testtenants met verschillende rollen en bronnen gebruikt. Reads, writes, exports, ITSM-koppeling en audit moeten de scheiding behouden, zowel bij succes als bij falen.