Lexique d'exploitation Zscaler & Zero Trust · Gouvernance & souveraineté

Qu'est-ce qu'un ZPA-Microtenant ?

Définition

Un ZPA-Microtenant est un périmètre d'administration délimité au sein d'un tenant de Zscaler Private Access. Il est défini via un domaine d'authentification et délégué à des admins, typiquement par pays, service ou filiale. Le Microtenant-Admin gère de façon autonome les App-Segments, connecteurs et règles de son périmètre, et ne voit les tableaux de bord et les logs que pour ses propres utilisateurs. Par défaut, les ressources des différents Microtenants restent séparées les unes des autres ; certains App-Segments peuvent être partagés de façon ciblée. Les Microtenants résolvent ainsi un problème d'organisation : une responsabilité décentralisée, sans devoir exploiter des tenants Zscaler séparés pour cela.

ZPA-Microtenant en détail

Les frontières de responsabilité sont clairement tracées. Au sein de son périmètre, l'admin délégué gère, selon la documentation Zscaler, les App-Segments et les groupes de segments, les serveurs et les groupes de serveurs, les App Connectors ainsi que leurs groupes, et les règles pour ses propres utilisateurs. Les fondations centrales restent réservées au Default-Microtenant : configuration IdP, attributs SAML, certificats d'enrôlement et la gestion des Microtenants eux-mêmes ; pour les admins délégués, ces domaines sont uniquement consultables en lecture.

La fonctionnalité s'active via le support Zscaler. Parmi les limites documentées : pas de prise en charge lorsque la fonction de reprise après sinistre est activée, certaines fonctions comme AppProtection réservées aux tenants réguliers, et la suppression d'un Microtenant entraîne aussi celle de ses Log Receivers. Pour les accès au-delà des frontières de périmètre, l'admin partage explicitement des App-Segments ; la séparation reste la règle.

Pourquoi les Microtenants comptent-ils dans l'exploitation Zscaler ?

Les Microtenants répondent à une question qui revient sans cesse dans les groupes et chez les prestataires : comment donner à chaque unité la responsabilité de son périmètre sans que personne ne perde la vue d'ensemble ? L'administration déléguée raccourcit les circuits, car la filiale gère elle-même ses App-Segments au lieu de demander chaque changement au niveau central. Dans le même temps, la frontière du périmètre limite les dégâts des erreurs et la visibilité des logs à la seule unité concernée.

Le prix à payer est un effort de coordination : qui gère quoi, quels segments sont partagés, quelles bases restent centrales ? Sans réponse documentée, des tickets font des allers-retours entre l'IT centrale et les admins de périmètre. Et qui exploite en plus plusieurs tenants réels, par exemple comme prestataire pour de nombreux clients, a besoin d'un niveau supplémentaire : une vue consolidée sur tous les tenants et leurs Microtenants.

Sources d'erreur courantes

Les Microtenants en pratique : ce qu'apporte CentaurNexus

CentaurNexus administre plusieurs ZPA-Microtenants de façon multi-tenant depuis une seule interface : la fonction Microtenants affiche les périmètres côte à côte, tout en préservant la séparation structurelle. Combinée au scoping de domaine RBAC, chaque équipe ne voit que son propre périmètre de responsabilité, du helpdesk du groupe jusqu'à l'admin de périmètre de la filiale, sans compte administrateur Zscaler. Pour les prestataires s'ajoute la vue cross-tenant, qui rend plusieurs tenants clients pilotables sous un même toit. La forme concrète que prend cette collaboration est décrite dans l'article Gérer plusieurs tenants Zscaler depuis une seule interface.

Voyez dans la démonstration en direct comment les Microtenants et la vue cross-tenant rendent lisible une responsabilité décentralisée.Voir la démonstration

Termes associés

Questions fréquentes sur le ZPA-Microtenant

Quelle est la différence entre Tenant et Microtenant ?

Le tenant est l'instance suprême d'une entreprise dans le service Zscaler, avec sa propre configuration et son propre contrat. Un Microtenant est un périmètre d'administration au sein d'un tenant ZPA : il est délimité via un domaine d'authentification et délégué à des admins, par exemple par pays, service ou filiale. Il n'en résulte pas un second tenant, mais une frontière de responsabilité au sein de l'existant.

Que peut gérer un Microtenant-Admin ?

Selon la documentation Zscaler, il gère de façon autonome la configuration de son périmètre : App-Segments et groupes de segments, serveurs et groupes de serveurs, App Connectors avec leurs groupes, ainsi que les règles pour ses propres utilisateurs. Les tableaux de bord et les logs n'affichent que son propre périmètre. Les App-Segments peuvent, si besoin, être partagés avec d'autres Microtenants.

Quels réglages restent réservés au Default-Microtenant ?

Seul l'admin du Default-Microtenant gère les fondations centrales : la configuration IdP, les attributs SAML, les certificats d'enrôlement et la création des Microtenants eux-mêmes. Pour les admins de Custom-Microtenant, ces domaines sont uniquement consultables en lecture. Cette répartition du travail empêche que des périmètres délégués modifient le socle d'authentification commun du tenant.

Des utilisateurs de différents Microtenants peuvent-ils accéder aux mêmes applications ?

Pas par défaut : les utilisateurs accèdent aux ressources de leur propre Microtenant et à celles du périmètre global, mais pas à celles des autres Microtenants. Là où un accès est souhaité, l'admin partage certains App-Segments de façon ciblée avec d'autres Microtenants. La séparation reste ainsi la règle, et le partage l'exception documentée.

Comment les Microtenants sont-ils activés et à quoi faut-il faire attention ?

Selon la documentation, la fonctionnalité est activée pour l'organisation via le support Zscaler. Il faut tenir compte des limites documentées : les Microtenants ne sont pas pris en charge lorsque la fonction de reprise après sinistre est activée, certaines fonctions comme AppProtection restent réservées aux tenants réguliers, et la suppression d'un Microtenant entraîne aussi celle de son Log Receiver.

Sources & pour aller plus loin :

Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.