Wat is een Zscaler-tenant?
Een Zscaler-tenant is de geïsoleerde instantie van een organisatie in de Zscaler-cloud, met eigen configuratie, eigen beheerders, gebruikers en policy's. Zijn gegevens zijn gescheiden van die van andere organisaties, ook al gebruiken ze allemaal hetzelfde cloudplatform. In ZIA komt de tenant overeen met de organisatie, in ZPA met de klantinstantie. Hij vormt daarmee de hoogste grens voor beheer, contract en gegevensscheiding. Binnen een ZPA-tenant kan het beheer via microtenants verder worden onderverdeeld, zonder dat er een tweede tenant ontstaat. De tenant is dus het kader waarin een organisatie haar Zscaler-diensten exploiteert, en tegelijk de scheidslijn met alle andere.
Zscaler-Tenant in detail
De tenant is de basis van multitenancy. Hij scheidt configuratie, beheerders, gebruikers, policy's en gegevens zo, dat handelingen in de ene tenant in een andere noch zichtbaar noch van invloed zijn. In ZIA spreekt men van de organisatie, in ZPA van de klantinstantie; het uniforme Experience Center bundelt de bijbehorende portalen van een tenant onder één interface. Aan deze grens hangen de zaken die de ene organisatie van de andere onderscheiden: het contract, de licenties, de datasoevereiniteit.
Daarvan te onderscheiden is de microtenant. Hij is geen tweede instantie, maar een beheergebied binnen een ZPA-tenant, gedelegeerd aan beheerders. Wie dus scheiding nodig heeft op contract-, licentie- of gegevensniveau, komt uit op tenant-niveau; wie alleen verantwoordelijkheden binnen een organisatie wil verdelen, gebruikt microtenants. Dit onderscheid goed maken bespaart later verkeerde verwachtingen over wat een grens scheidt.
Waarom telt de Zscaler-tenant in de Zscaler-praktijk?
Voor dienstverleners en concerns is de tenant de centrale beheereenheid. Een managed service provider beheert vaak veel klanttenants, een concern scheidt juridisch zelfstandige vennootschappen in eigen instanties. Daarmee dringt zich een terugkerende vraag op: hoe houdt men het overzicht over meerdere tenants, zonder de scheiding te verzwakken die juist de reden was voor gescheiden tenants? De native weg, apart inloggen op elke instantie, wordt met elke volgende tenant snel omslachtig en foutgevoelig.
Hier wordt de efficiëntie van het beheer bepaald. Een geconsolideerd overzicht over alle tenants verkort de weg, maar mag de grens niet doorboren: elk team moet alleen het gebied zien waarvoor het verantwoordelijk is. Voor bewijsvoering is de tenantgrens eveneens relevant, omdat ze laat zien dat gegevens van verschillende klanten of vennootschappen structureel gescheiden blijven. De kunst is overzicht en scheiding tegelijk te hebben, in plaats van het ene tegen het andere in te ruilen.
Veelvoorkomende foutbronnen
- Tenant met microtenant verward: scheiding van contract, licentie en gegevens ligt op tenant-niveau, niet op de beheergrens.
- Veel tenants beheerd via het wisselen van aanmeldingen: dat kost tijd en verhoogt het risico om in de verkeerde tenant te werken.
- Cross-tenant-overzicht als vanzelfsprekend aangenomen: een overkoepelende blik over tenants ontstaat niet vanzelf, hij moet bewust worden gebouwd.
- Overzicht kwijtgeraakt: zonder duidelijke toewijzing weet niemand meer welke tenant welke configuratie en welke verantwoordelijken heeft.
Zscaler-tenants in de praktijk: wat CentaurNexus bijdraagt
CentaurNexus bundelt meerdere Zscaler-tenants in één cross-tenant-overzicht en maakt ze vanuit één interface bedienbaar, terwijl de structurele scheiding behouden blijft. Gecombineerd met RBAC-domeinafbakening ziet elk team alleen zijn eigen verantwoordelijkheidsgebied, van managed service provider tot concern-helpdesk, zonder Zscaler-beheerdersaccount. Binnen een tenant vullen microtenants de fijnere indeling aan. Zo ontstaat overzicht, zonder de grens op te geven die juist de reden was voor gescheiden tenants. Hoe die samenwerking er in de praktijk uitziet, laat dit artikel zien: Meerdere Zscaler-tenants vanuit één interface beheren.
Verwante begrippen
Veelgestelde vragen over de Zscaler-tenant
Een Zscaler-tenant is de geïsoleerde instantie van een organisatie in de Zscaler-cloud. Hij heeft een eigen configuratie, eigen beheerders, gebruikers en policy's, en zijn gegevens zijn gescheiden van andere organisaties. In ZIA komt hij overeen met de organisatie, in ZPA met de klantinstantie. De tenant is daarmee de hoogste grens voor beheer, contract en gegevensscheiding.
De tenant is de hoogste instantie van een organisatie, met een eigen configuratie en eigen contract. Een microtenant is een beheergebied binnen een ZPA-tenant, gedelegeerd aan beheerders, bijvoorbeeld per land of afdeling. Contract-, licentie- en gegevensscheiding vinden plaats op tenant-niveau, niet op microtenant-niveau.
Typisch bij dienstverleners die meerdere klanten bedienen, en bij concerns met juridisch gescheiden entiteiten. Ook bijzondere eisen aan gegevensscheiding of afwijkende contracten kunnen gescheiden tenants nodig maken. De prijs daarvoor is meer beheerlast, omdat elke instantie eigen administratie en een eigen overzicht vergt.
Een tenant scheidt configuratie, beheerders, gebruikers, policy's en gegevens van elkaar. Wat in de ene tenant gebeurt, is in een andere noch zichtbaar noch van invloed. Deze grens is de basis van multitenancy: ze zorgt ervoor dat organisaties dezelfde cloud gebruiken zonder elkaar te kunnen inzien of beïnvloeden.
De native weg is wisselen tussen de instanties, wat bij veel tenants traag en foutgevoelig wordt. Praktischer is een geconsolideerd overzicht over alle tenants, gecombineerd met een rechtentoewijzing die elk team alleen zijn eigen gebied toont. Zo blijft de scheiding behouden, zonder dat elke informatie een nieuwe aanmelding vereist.
- Zscaler Help Portal: About Your Organization (ZIA) - help.zscaler.com
- Zscaler Help Portal: About Microtenants (ZPA) - help.zscaler.com
Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.