Qu'est-ce que RBAC ?
RBAC (Role-Based Access Control, contrôle d'accès basé sur les rôles) est un modèle d'autorisation qui rattache les droits d'accès à des rôles plutôt qu'à des personnes individuelles. Un rôle regroupe les droits nécessaires à une tâche, par exemple le support First Level ou l'analyste sécurité ; les utilisateurs n'obtiennent leurs droits que par l'attribution de tels rôles. Cela rend les autorisations cohérentes, traçables et faciles à maintenir : qui change de tâche change de rôle, au lieu d'accumuler des droits individuels. RBAC est ainsi l'outil le plus concret pour appliquer le Least Privilege, c'est-à-dire ne donner à chaque personne et à chaque service que les droits strictement nécessaires.
RBAC en détail
Un modèle RBAC se compose de trois éléments : utilisateurs, rôles et autorisations. Les autorisations sont rattachées aux rôles, les utilisateurs aux attributions de rôles ; les droits individuels directs accordés à une personne sont proscrits. En complément, le scoping de domaine s'est imposé : il limite en plus la portion de données sur laquelle un rôle agit, par exemple à un seul site, un seul département ou un seul tenant. Les droits répondent alors à deux questions : que peut faire le rôle, et où cela s'applique-t-il ?
RBAC se distingue d'ABAC (Attribute-Based Access Control), qui décide des accès via des attributs et des conditions comme l'état de l'appareil ou la localisation. En pratique, les deux se complètent : RBAC fournit l'ordre structurel stable, les conditions basées sur les attributs l'affinent au cas par cas. Le modèle de rôles est notamment décrit formellement dans les travaux RBAC du NIST.
Pourquoi RBAC compte-t-il dans l'exploitation Zscaler ?
Les consoles d'administration Zscaler sont puissantes : qui y a accès peut modifier les règles pour toute l'entreprise. Dans de nombreuses organisations, les équipes de helpdesk n'obtiennent donc soit aucune visibilité, et chaque ticket s'escalade, soit des droits trop étendus, et le risque augmente. RBAC résout ce dilemme : la consultation en lecture pour le traitement des cas est un rôle à part, l'intervention administrative en est un autre. Le First Level voit ainsi ce dont il a besoin pour le cas, sans pouvoir rien modifier.
Le modèle compte aussi pour la preuve : NIS2 exige des concepts de contrôle d'accès, DORA une attribution maîtrisée des droits dans le secteur financier. Un modèle de rôles propre avec scoping de domaine répond à la question de l'auditeur, qui peut accéder à quoi et pourquoi, directement à partir de la structure, sans devoir être reconstitué à partir de droits individuels accumulés au fil du temps.
Sources d'erreur courantes
- Prolifération de rôles : si un rôle par personne apparaît dans les faits, le modèle n'est qu'une attribution de droits individuels rebaptisée.
- Droits permanents pour des cas exceptionnels : des rôles étendus accordés pour une tâche ponctuelle restent souvent en place durablement.
- Comptes partagés : des accès partagés détruisent le lien entre actions et personnes, et donc toute piste d'audit.
- Absence de recertification : les attributions de rôles doivent être vérifiées régulièrement, sinon les collaborateurs de longue date accumulent des droits dormants.
RBAC en pratique : ce qu'apporte CentaurNexus
CentaurNexus applique RBAC avec scoping de domaine de façon systématique à l'exploitation Zscaler : les rôles helpdesk obtiennent via User Support Center une vue à 360 degrés en lecture seule sur les utilisateurs, à travers ZIA, ZPA et ZDX, sans nécessiter de droits d'administration Zscaler, et ne voient que le périmètre dont ils sont responsables. Les actions en écriture restent réservées à des rôles dédiés, se valident selon le principe des quatre yeux et sont consignées dans un journal d'audit en append-only. Pour les MSP s'ajoute le Cross-Tenant-Scoping : de nombreux tenants clients réunis dans une seule interface, strictement cloisonnés. Le fonctionnement concret du support sans droits d'administration est décrit dans le guide Support Zscaler sans droits d'administration.
RBAC en exploitation : comment le reconnaître
Les tickets RBAC se ressemblent tous : « Je n'ai pas les droits. » La cause ne vient pourtant presque jamais du rôle seul, mais de l'un de trois endroits.
« Nous avons le même rôle, il voit plus de choses que moi. »
Ce que c'est le plus souvent : Ce n'est alors pas le rôle qui diffère, mais son périmètre. Le même rôle peut pointer vers des tenants, des sites ou des groupes d'objets différents.
Comment le distinguer : Examinez séparément le rôle et le périmètre. Qui ne compare que le rôle ne trouve aucune différence et continue à chercher au mauvais endroit.
« Le rôle est correct, l'action est quand même refusée. »
Ce que c'est le plus souvent : Le plus souvent, une seconde condition s'applique : une exigence de validation à quatre yeux, un droit d'écriture désactivé pour ce tenant, ou une action prévue par principe en lecture seule.
Comment le distinguer : La question n'est pas « ce rôle en a-t-il le droit », mais « cette action est-elle seulement prévue en écriture pour ce tenant ».
« Après la réorganisation, des droits manquent soudainement. »
Ce que c'est le plus souvent : Le grand classique. Les droits dépendent des groupes, les groupes de l'organisation. Si l'affectation change, les droits changent, sans que personne n'ait touché à un rôle.
Comment le distinguer : Ne vérifiez pas l'attribution du rôle, mais l'appartenance au groupe. C'est là qu'a eu lieu le changement.
« Plus personne ne sait pourquoi ce rôle a ce droit. »
Ce que c'est le plus souvent : Un signe d'autorisations accumulées au fil du temps. Des exceptions isolées subsistent après la disparition de leur motif.
Comment le distinguer : C'est une tâche de nettoyage, pas un incident. Elle se planifie, elle ne se traite pas dans un ticket.
Rôle, périmètre et appartenance au groupe sont trois choses différentes. Les confondre dans un ticket coûte des allers-retours supplémentaires à chaque cas de droits d'accès.
Termes associés
Questions fréquentes sur RBAC
RBAC signifie Role-Based Access Control, en français contrôle d'accès basé sur les rôles. Les droits d'accès ne sont pas attribués à des personnes individuelles, mais rattachés à des rôles comme helpdesk ou administrateur ; les utilisateurs obtiennent leurs droits par l'attribution de ces rôles. Cela maintient les autorisations cohérentes et vérifiables, et facilite considérablement l'arrivée, le changement de poste et le départ des collaborateurs.
RBAC décide par les rôles : qui détient le rôle détient les droits associés. ABAC décide par des attributs et des conditions, par exemple l'état de l'appareil, la localisation ou l'heure de la journée, et peut ainsi piloter plus finement, mais aussi de façon plus complexe. En pratique, la combinaison des deux a fait ses preuves : RBAC comme socle stable, les conditions basées sur les attributs comme affinement au cas par cas.
Comme les règles Zscaler concernent toute l'entreprise, le moins de personnes possible devrait détenir des droits d'administration complets. RBAC permet de séparer la consultation en lecture de l'intervention administrative : le helpdesk obtient une vue sur le statut des utilisateurs et des règles pour traiter les cas, tandis que les modifications restent réservées à quelques personnes habilitées. Cela réduit à la fois le risque et les escalades.
Aussi peu que possible, autant que nécessaire. Un petit ensemble de rôles standard organisés par tâche a fait ses preuves, par exemple First Level, Second Level, administration et audit, complété par quelques rôles spéciaux justifiés. Si un rôle par personne apparaît dans les faits, le modèle a échoué et doit être consolidé.
NIS2 n'impose aucun modèle particulier, mais exige des concepts de contrôle d'accès et une gestion maîtrisée des risques ; c'est la transposition nationale respective qui fait foi. RBAC est la voie établie pour mettre en œuvre et démontrer ces exigences, car les rôles et leurs attributions permettent à tout moment de déduire qui peut accéder à quoi, et pourquoi.
- NIST Computer Security Resource Center : Role Based Access Control (page du projet) - csrc.nist.gov
- Directive (UE) 2022/2555 (NIS2), exigences en matière de contrôle d'accès et de gestion des risques - eur-lex.europa.eu
- Portail d'aide Zscaler : documentation officielle sur l'administration basée sur les rôles - help.zscaler.com
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.