Les Microtenants divisent un environnement ZPA en périmètres distincts, par exemple par filiale, région ou unité opérationnelle. Sur le plan métier, c'est pertinent : chaque périmètre gère ce qui lui appartient. Sur le plan opérationnel, cela pose la question de savoir comment une équipe centrale peut encore garder une vue d'ensemble, sans affaiblir cette séparation. ZPA Microtenant Control gère plusieurs Microtenants depuis une seule interface, tandis que la séparation structurelle reste intacte.
Pourquoi les environnements sont divisés
Un groupe comptant plusieurs filiales a rarement une seule responsabilité IT. Chaque société a ses propres applications, ses propres responsables et souvent son propre cadre juridique. Les Microtenants reproduisent cette structure au sein de l'environnement ZPA.
Ce n'est pas un gadget technique, mais le reflet de la réalité. Qui est responsable d'une filiale doit pouvoir gérer ses accès, sans empiéter par mégarde sur un périmètre qui ne le concerne pas.
Le problème d'exploitation que cela crée
La séparation recherchée a une conséquence que l'on ne remarque qu'à l'usage. Qui doit répondre à une question transversale se retrouve soudain face à plusieurs environnements séparés.
Ce type de question est plus fréquent qu'il n'y paraît au premier abord. Combien d'accès externes existent à l'échelle du groupe ? Une application donnée est-elle accessible dans plusieurs périmètres ? Où s'applique une règle censée valoir partout ? Chacune de ces questions exigeait jusqu'ici la même démarche : se connecter les uns après les autres, vérifier, noter, additionner.
Ce que fait ZPA Microtenant Control
ZPA Microtenant Control permet de gérer plusieurs Microtenants depuis une seule interface. La vue d'ensemble se construit au niveau de l'interface, pas en fusionnant les périmètres.
C'est le point décisif. La séparation structurelle reste entièrement intacte. Ce qui change, ce n'est pas la délimitation, mais la façon d'en avoir une vue d'ensemble.
Une vue d'ensemble sans mélange
L'objection légitime que l'on peut opposer à toute vue transversale est la suivante : n'affaiblit-elle pas justement la séparation que l'on a mise en place ? La réponse dépend de l'endroit où cette séparation est appliquée.
Si elle n'est imposée que par des connexions séparées, alors oui. Si elle est imposée en dessous, via les rôles et la gestion des données, alors non : chaque personne voit alors exactement les périmètres pour lesquels elle est habilitée, et l'interface commune n'est que la manière dont elle y accède.
Pour qui cela vaut particulièrement la peine
La différence se fait le plus nettement sentir là où une petite équipe centrale gère de nombreux périmètres : dans les groupes disposant d'une IT centrale allégée, et chez les intégrateurs responsables de plusieurs clients.
Là, passer d'un environnement à l'autre n'est pas un simple désagrément, mais une part sensible du temps de travail, dont personne ne profite.
Une interface commune n'est pas une gestion des données commune. Ce qui compte, c'est que la délimitation soit imposée en dessous de l'interface, via les rôles et la gestion des données, et non via des connexions séparées.
Questions fréquentes
Qu'est-ce qu'un Microtenant ZPA ?
Une subdivision au sein d'un environnement ZPA, qui permet de séparer des périmètres de responsabilité, par exemple par filiale, région ou unité opérationnelle.
Que fait ZPA Microtenant Control ?
Il permet de gérer plusieurs Microtenants depuis une seule interface, tout en préservant la séparation structurelle entre les périmètres.
Une interface commune affaiblit-elle la séparation ?
Pas si la délimitation est imposée en dessous de l'interface, via les rôles et la gestion des données. Chaque personne voit alors exactement les périmètres pour lesquels elle est habilitée.
Qui en profite le plus ?
Les organisations où une petite équipe centrale gère de nombreux périmètres : les groupes disposant d'une IT centrale allégée et les intégrateurs comptant plusieurs clients.
Quelles questions deviennent ainsi possibles à traiter ?
Des questions transversales qui nécessitaient jusqu'ici plusieurs connexions : combien d'accès externes existent à l'échelle du groupe, où une application donnée est accessible, si une règle s'applique partout.
Un Microtenant est-il la même chose qu'un tenant Zscaler distinct ?
Non. Un Microtenant est une subdivision au sein d'un environnement ZPA existant, pas un contrat Zscaler distinct ni un tenant séparé. L'environnement ZPA global reste une seule entité, simplement structurée en interne en périmètres de responsabilité.
Un Microtenant peut-il représenter un client individuel d'un intégrateur ?
La structure s'y prête. Un Microtenant représente un périmètre de responsabilité délimité. Qu'il corresponde à une filiale, une région, une unité opérationnelle ou un client final d'un intégrateur dépend de votre propre organisation.
Comment ZPA Microtenant Control se situe-t-il par rapport aux modules Terraform comme zpa_application_segment ?
Ce sont des niveaux différents. Les modules Terraform comme zpa_application_segment provisionnent des objets ZPA individuels. ZPA Microtenant Control se situe un niveau au-dessus : la gestion et la vue d'ensemble de plusieurs Microtenants déjà existants depuis une seule interface.
Sources
Voir ce workflow en contexte
Choisissez le rôle correspondant dans le lanceur de démo. La démonstration utilise des données d'exemple préparées.
Ouvrir le lanceur de démo