Droits d'accès

Attribuer des rôles personnalisés sans partager les droits super admin

Le moyen le plus rapide de rendre quelqu'un opérationnel, ce sont les droits complets. Le moyen que l'on regrette plus tard est le même.

20 août 2026 · CentaurNexus · Temps de lecture environ 6 minutes

Cette page a été traduite automatiquement à partir de l'original allemand. Certaines formulations peuvent donc s'en écarter. Vous pouvez consulter la version allemande ou anglaise d'origine. Vous avez repéré une erreur ? Signalez-la-nous.
Attribuer des rôles personnalisés sans partager les droits super admin
CentaurNexus : attribuer des rôles personnalisés sans partager les droits super admin
L'essentiel en bref
Quiconque doit travailler dans l'exploitation Zscaler a besoin de droits. Comme des droits graduels demandent du travail et que les droits complets fonctionnent immédiatement, de nombreuses organisations se retrouvent avec un parc de comptes administrateur bien plus large que nécessaire. Des rôles graduels ne résolvent pas seulement une question de sécurité : ils rendent tout simplement possible de confier des tâches au helpdesk ou à des collègues juniors, sans devoir repenser le risque à chaque transmission.

Pourquoi les droits complets sont si tentants

Une nouvelle collègue doit travailler dans l'exploitation Zscaler. Elle a besoin d'un accès, sinon elle ne peut pas commencer. La question de savoir exactement quels droits prend du temps à trancher, et elle se repose à chaque cas particulier.

Les droits complets résolvent le problème immédiatement et entièrement. Ils fonctionnent toujours, pour n'importe quelle tâche, sans ajustement. Cette commodité est la véritable raison pour laquelle les comptes administrateur se multiplient, pas la négligence.

Le prix à payer n'arrive que plus tard, et ailleurs : lors d'un entretien d'audit, d'une analyse d'incident, ou au moment où quelqu'un modifie par mégarde quelque chose qu'il ne voulait même pas toucher.

Le véritable bénéfice n'est pas la sécurité

Les rôles graduels sont généralement traités comme un sujet de sécurité. C'est trop restrictif. Leur principal bénéfice est de rendre la délégation possible tout court.

Tant que toute participation suppose des droits complets, chaque transmission de tâche est une décision de risque. Le helpdesk peut-il prendre en charge ce diagnostic ? Seulement s'il devient administrateur pour cela, donc plutôt pas. La tâche reste au deuxième niveau, alors qu'elle n'y a pas sa place.

Avec des droits graduels, la question du risque devient une question de périmètre : de quelle vue ce rôle a-t-il besoin pour accomplir cette tâche ? On peut y répondre, et la tâche peut ensuite aller là où elle est traitée efficacement.

La lecture est le besoin le plus fréquent

Une grande partie du travail quotidien consiste à vérifier. Où ça bloque, quelle règle s'applique, quel est l'état de cet appareil. Pour tout cela, personne n'a besoin de droits d'écriture.

Cette observation est le raccourci le plus pratique vers un découpage de rôles sensé. Qui sépare les activités de lecture de celles d'écriture a résolu la plus grande partie du problème, sans devoir concevoir un modèle de droits très fin.

Ce qu'il advient des droits d'écriture

Pour les modifications, reste la question de savoir qui a le droit de les effectuer. Un second niveau aide ici : toute modification ne doit pas nécessairement prendre effet immédiatement. Les interventions critiques peuvent être soumises à une validation à quatre yeux.

Le droit de préparer une modification se dissocie ainsi du droit de la valider. Une collègue junior peut travailler sans que chacune de ses modifications ne devienne immédiatement effective, et apprend ainsi sur des cas réels.

Ce que le parc de comptes révèle sur l'organisation

Une bonne première étape est une question simple : combien de comptes disposent de droits complets, et combien de personnes en ont réellement besoin au quotidien ? L'écart entre ces deux chiffres est généralement plus important qu'attendu.

Cet écart n'est pas un reproche adressé aux personnes concernées. C'est le résultat prévisible du fait que les droits complets sont la voie de moindre résistance. Le combler est donc moins une question de discipline qu'une question d'outil.

Le chiffre qui surprend
Comptez les comptes disposant de droits d'administrateur complets, puis les personnes qui en ont réellement besoin chaque jour. La différence indique l'ampleur de la tâche.

Questions fréquentes

Pourquoi de nombreux comptes super admin posent-ils problème ?

Parce que chacun d'eux signifie un accès complet à tout, y compris à des domaines avec lesquels la personne n'a jamais affaire. Une intervention accidentelle ou un compte compromis a alors un effet sans limite.

Quelle est la première étape la plus pratique ?

Séparer les activités de lecture de celles d'écriture. Une grande partie du travail quotidien consiste à vérifier et ne nécessite aucun droit d'écriture.

Quel est le lien entre attribution des droits et délégation ?

Tant que la participation suppose des droits complets, chaque transmission de tâche est une décision de risque. Des droits graduels transforment cette question de risque en question de périmètre et rendent la délégation possible.

Comment gérer les droits de modification ?

Via un second niveau : les modifications critiques peuvent être soumises à une validation à quatre yeux. Le droit de préparer une modification se sépare ainsi du droit de la valider.

Dois-je pour cela concevoir un modèle de droits très fin ?

Non. La plus grande partie du bénéfice découle déjà de la séparation entre activités de lecture et d'écriture. Des graduations plus fines peuvent suivre plus tard.

Qu'est-ce que le RBAC ?

RBAC signifie Role-Based Access Control, soit contrôle d'accès basé sur les rôles. Plutôt que d'attribuer des droits individuels à chaque personne, chaque personne reçoit un rôle, et ce rôle détermine ce qu'elle peut voir et faire. Cela rend les droits traçables et plus faciles à gérer qu'une liste d'autorisations individuelles accumulées au fil du temps.

La séparation entre lecture et écriture s'applique-t-elle aussi à l'accès via l'API Zscaler ?

Oui. CentaurNexus lit la configuration Zscaler via l'API officielle Zscaler OneAPI, et cet accès est délimitable par rôle au sein de CentaurNexus. Un rôle disposant uniquement de droits de lecture ne voit donc, même via la connexion API, que les domaines qui lui sont autorisés.

La séparation des rôles fonctionne-t-elle aussi pour ZPA, ou seulement pour ZIA ?

Oui. Le principe des droits graduels s'applique de la même façon aux workflows ZIA, ZPA et ZDX pris en charge. Un rôle n'est pas limité à un seul service Zscaler, mais taillé sur mesure pour la tâche que la personne doit accomplir.

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