Gérer plusieurs tenants Zscaler depuis une seule interface

Les MSP, les intégrateurs et l'IT des grands groupes exploitent rarement un seul tenant Zscaler. Qui gère plusieurs tenants se heurte à de nombreuses connexions, à des changements de contexte permanents et à l'absence de vue unifiée. Voici comment regrouper l'exploitation dans une seule interface, sans renoncer à une séparation stricte des tenants.

Le problème : de nombreux tenants, de nombreuses connexions, aucune vue commune

Zscaler s'adapte excellemment par tenant. Mais dès que vous gérez plusieurs tenants, par exemple en tant que MSP avec un portefeuille d'environnements clients ou en tant que groupe avec des tenants séparés par filiale ou par région, la friction se déplace du produit vers l'exploitation. Chaque tenant a son propre portail d'administration, ses propres identifiants et son propre contexte.

Au quotidien, cela signifie : un agent du helpdesk prend en charge un ticket, mais doit d'abord découvrir à quel tenant appartient l'utilisateur concerné, s'y connecter séparément, s'orienter dans le bon périmètre et documenter l'opération. Au ticket suivant, le jeu recommence, souvent dans un autre tenant. Ces changements de contexte coûtent du temps, augmentent le taux d'erreur et rendent laborieux un reporting propre et transversal aux tenants.

S'ajoute la question des droits. Pour que le helpdesk soit tout simplement opérationnel, il reçoit souvent des accès plus larges que ce qu'exige l'opération individuelle. Avec un seul tenant, c'est déjà délicat. Sur tout un portefeuille, cela devient un véritable enjeu de gouvernance : qui a eu le droit de voir ou de modifier quoi, dans quel tenant, et quand ?

La solution : un cockpit cross-tenant basé sur l'OneAPI Zscaler

CentaurNexus est une console unique pour les flux Zscaler pris en charge, dont l'exploitation en production pour les clients européens se fait entièrement sur STACKIT dans l'UE, avec des trajets de protection des données documentés. Il s'appuie sur l'OneAPI officielle de Zscaler et ajoute une couche d'exploitation et de gouvernance pour plusieurs tenants gérés. La plateforme Zscaler reste la source de vérité.

Au lieu de cinq, dix portails d'administration séparés ou plus, votre équipe travaille dans une seule interface. Le changement entre tenants devient un filtre, pas une nouvelle connexion. Recherche, constat et modifications demandées suivent la même logique d'utilisation, quel que soit le tenant concerné.

Recherche à 360 degrés sur l'ensemble des tenants

Le cœur pour le helpdesk est le constat utilisateur à 360 degrés. User Support Center et Unified Support Center regroupent le statut d'un utilisateur sur ZIA, ZPA et ZDX en une seule vue : affectation de politique, chemins d'accès, qualité d'expérience et anomalies en un coup d'œil. Le point décisif pour l'exploitation multi-tenant est que cette recherche fonctionne sur l'ensemble des tenants autorisés. L'agent recherche un utilisateur et arrive dans le bon contexte, sans savoir au préalable dans quel tenant chercher.

Important ici : ce constat fonctionne en lecture seule, sans accorder de véritables droits d'administration Zscaler. Le helpdesk obtient la visibilité nécessaire à son travail, pas les clés de l'ensemble de la configuration.

RBAC-Domain-Scoping : chacun ne voit que son périmètre

Pour que la centralisation n'affaiblisse pas la séparation, le RBAC-Domain-Scoping s'applique. Chaque utilisateur est limité exactement aux tenants et périmètres pour lesquels il est autorisé. Une équipe de helpdesk qui ne suit qu'un client précis ne voit que les données de ce client. Les rôles MSP peuvent travailler de façon contrôlée sur plusieurs clients, si le mandat le prévoit.

Cette limite est appliquée techniquement, pas seulement masquée visuellement. La séparation des tenants est une isolation stricte au niveau des données, de sorte qu'un utilisateur ne peut pas accéder par des détours ou des requêtes directes à des données pour lesquelles il n'est pas autorisé. Exploitation centralisée et séparation nette ne s'excluent donc pas, elles sont appliquées ensemble.

Validations à quatre yeux et traçabilité complète

La visibilité seule ne suffit pas dans l'exploitation ; à un moment donné, des modifications doivent avoir lieu. Pour que cela reste maîtrisable sur plusieurs tenants, les actions d'écriture sont modélisées comme des opérations à demander. Un agent soumet une demande, un rôle autorisé la valide. Cette procédure de validation définie par la politique du tenant peut être rendue obligatoire là où les modifications sont sensibles.

Chaque action d'écriture est auditable. Qui a demandé, validé ou exécuté quoi, quand et dans quel tenant est documenté de façon traçable. Pour les environnements réglementés et pour la collaboration entre MSP et client, cet audit-trail fait souvent la différence entre un modèle d'exploitation viable et une discussion de justification permanente.

Voici à quoi ressemble le processus helpdesk en pratique

L'effet est immédiat : un traitement plus rapide grâce à moins de changements de contexte, une visibilité clairement limitée par rôle et un journal propre sur l'ensemble des tenants. Le helpdesk devient opérationnel sans que quiconque ne devienne administrateur généralisé sur des tenants étrangers.

Analyses pour l'exploitation cross-tenant

Au-delà du simple helpdesk, le cockpit fournit des analyses par tenant, par exemple sur des règles orphelines ou conflictuelles. Les corrections proposées incluent le contexte et l'impact et suivent le chemin de validation défini par la politique de chaque tenant. Chaque modification reste ainsi traçable.

Le contexte du tenant avant chaque action

Une vue d'exploitation commune ne doit pas brouiller les frontières entre tenants. Avant chaque lecture, ticket, export et écriture, il doit être sans ambiguïté pour quel client géré l'opération s'applique. Les rôles et les contrôles au niveau des lignes limitent l'accès aux tenants réellement attribués au MSP.

Les filtres enregistrés, les tâches récemment ouvertes et les notifications restent eux aussi liés au tenant. Un changement de contexte client réinitialise visiblement la sélection active. Une décision ne peut ainsi pas migrer discrètement vers un autre tenant.

Des processus reproductibles avec une responsabilité propre à chaque client

Les MSP profitent de schémas d'exploitation communs pour l'onboarding, le helpdesk, les validations, les rapports et les revues. Un modèle standardise le déroulement au sein de la politique du tenant client. Le rôle responsable, la limite de validation, les sources de données et le périmètre contractuel restent propres à chaque client.

La recette utilise au moins deux tenants de test séparés avec des rôles et des sources différents. Lectures, écritures, exports, rattachement ITSM et audit doivent préserver la séparation, aussi bien en cas de succès qu'en cas d'échec.