Qu'est-ce que le contrôle d'accès basé sur les rôles (RBAC) ?

Le contrôle d’accès basé sur les rôles est un modèle d’autorisation où les permissions s’attachent aux rôles, jamais directement aux utilisateurs. Toute l’idée tient dans cette indirection : rien n’est jamais accordé directement à une personne, si bien qu’un changement d’organisation devient un changement de données — une promotion est une réaffectation de rôle, pas une fouille archéologique parmi des droits éparpillés. Proposé par Ferraiolo et Kuhn en 1992 comme alternative aux modèles discrétionnaire et obligatoire plus anciens, il est devenu le standard ANSI/INCITS 359 et le vocabulaire d’autorisation par défaut des logiciels d’entreprise.

Points clés

Utilisateurs, rôles, permissions — l’indirection à l’œuvre

Permissions                 Rôles                    Utilisateurs
─────────────               ─────────────            ─────────────
posts:read        ─┐
posts:write        ├──▶     Editor          ◀──────  Ada, Grace
posts:publish     ─┘
users:manage      ─┐
billing:view       ├──▶     Admin           ◀──────  Linus
posts:*           ─┘
posts:read        ────▶     Viewer          ◀──────  tous les autres

Ada publie parce qu'Editor porte posts:publish — réaffectez son rôle,
et chaque permission qu'il portait la suit. Une modification, pas N.

Des rôles sous forme de données vivantes, branchés sur les permissions des objets :

// JavaScript / Node.js — Back4app JS SDK
// Roles as data: create a role, add members, grant through it
const roleACL = new Parse.ACL();
roleACL.setPublicReadAccess(true);
const editors = new Parse.Role('Editors', roleACL);
editors.getUsers().add(adaUser);
await editors.save();

// Grant by role, not by user — membership changes in one place
const post = new Parse.Object('Post');
const acl = new Parse.ACL(currentUser);  // owner entry
acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// Flutter / Dart — Back4app Flutter SDK
// Roles as data: create a role, add members, grant through it
final roleACL = ParseACL()..setPublicReadAccess(allowed: true);
final editors = ParseObject('_Role')
  ..set('name', 'Editors')
  ..setACL(roleACL)
  ..addRelation('users', [adaUser]);
await editors.save();

// Grant by role, not by user — membership changes in one place
final post = ParseObject('Post');
final acl = ParseACL(owner: currentUser)  // owner entry
  ..setRoleWriteAccess('Editors', true);  // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// iOS / Swift — Back4app Swift SDK
// Roles as data: create a role, add members, grant through it
var editors = try ParseRole(name: "Editors")
let savedRole = try await editors.save()
try await savedRole.users.add([adaUser]).save() // membership = a relation

// Grant by role, not by user — membership changes in one place
var post = Post()
var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)
acl.setWriteAccess(user: currentUser, value: true)   // owner entry
acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL
post.ACL = acl
try await post.save()

// Android / Kotlin — Back4app Android SDK
// Roles as data: create a role, add members, grant through it
val roleACL = ParseACL()
roleACL.publicReadAccess = true
val editors = ParseRole("Editors", roleACL)
editors.users.add(adaUser)
editors.save()

// Grant by role, not by user — membership changes in one place
val post = ParseObject("Post")
val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry
acl.setRoleWriteAccess("Editors", true)        // RBAC meets the object's ACL
post.acl = acl
post.save()

Le modèle NIST, correctement

La plupart des explications compressent le standard en une liste à puces ; la structure réelle mérite trente secondes. Le RBAC de base définit les utilisateurs, les rôles, les permissions — et les sessions, l’élément oublié : un utilisateur active un sous-ensemble de ses rôles par session, ce qui permet à un administrateur de naviguer par défaut avec des pouvoirs de simple membre et de s’élever délibérément. Les trois règles de l’article original font tenir l’ensemble : n’agir qu’à travers un rôle, ne détenir que des rôles autorisés, ne faire que ce que le rôle actif permet. Le RBAC hiérarchique ajoute l’héritage — les rôles seniors englobent les rôles juniors (Manager ⊇ Employee), ce qui supprime les doublons. Le RBAC contraint ajoute la séparation des tâches : les règles statiques interdisent purement et simplement les affectations de rôles incompatibles (jamais créateur et approbateur de paiements à la fois) ; les règles dynamiques autorisent l’affectation mais interdisent d’activer les deux dans une même session. Et la clarification la plus tranchante du NIST, régulièrement déformée : un groupe est une collection d’utilisateurs ; un rôle est une collection de permissions — le rôle se définit par ce qu’il peut faire, pas par qui en fait partie.

RBAC vs. ACL vs. ABAC

Ce que les pages de résultats des éditeurs enterrent : ces modèles se composent, ils ne s’opposent pas. Les rôles gèrent l’accès qui suit la fonction ; les entrées d’ACL gèrent les exceptions par objet — et la charnière est l’ACE de rôle, une ligne d’ACL qui nomme un rôle plutôt qu’un utilisateur, offrant un contrôle au niveau de l’objet avec une gestion des membres en un seul endroit. Les conditions d’attributs se superposent là où le contexte (heure, tenant, état de l’enregistrement) décide vraiment. “Lequel choisir ?” est généralement la mauvaise question ; “quelle couche prend quelle décision ?”, c’est la conception.

L’explosion des rôles — le mode de défaillance

La maladie caractéristique du RBAC : chaque exception engendre un rôle, puis chaque projet, région et tenant les multiplie — Project-A-Manager-Region-West-ReadOnly — jusqu’à ce que les rôles soient plus nombreux que les utilisateurs et que la réponse de l’audit à “qui peut faire quoi ?” soit “personne ne sait”. La cause profonde est toujours la même : des attributs contextuels encodés sous forme de rôles. Les parades, dans l’ordre : sortez les attributs des noms de rôle (la région et le tenant sont des conditions ou des périmètres, pas des rôles) ; gérez le partage par objet avec des entrées d’ACL, jamais avec des rôles par objet ; cloisonnez les rôles par tenant de façon structurelle plutôt qu’en bricolant des noms ; et auditez — les rôles que personne ne détient, les permissions qu’aucun rôle n’utilise et les droits dont plus personne ne se souvient constituent une dérive, et c’est par la dérive que le moindre privilège meurt en silence. Une heuristique qui fonctionne : si la liste des rôles ne tient plus sur un écran, le modèle absorbe un travail qui revient à une autre couche.

Concevoir les rôles : top-down, bottom-up, ou les deux

Le volet qu’aucune explication bien classée ne couvre : d’où viennent les rôles. L’approche top-down les dérive de l’organisation et de ses processus — interroger les métiers, nommer les fonctions, attribuer des permissions minimales ; précis mais lent. L’approche bottom-up les extrait des droits existants — regrouper qui détient déjà quoi, et des rôles candidats en émergent ; rapide, mais cela blanchit les erreurs passées en politique officielle. La pratique est hybride : extraire des candidats, les valider face aux fonctions, puis appliquer le test 80/20 — une poignée de rôles larges pour le gros de l’organisation, les exceptions étant gérées par des ACL ou des conditions plutôt que par des rôles sur mesure. Et une règle d’implémentation qui survit à toutes les réorganisations : le code doit vérifier des permissions, pas des noms de rôle — can('posts:publish'), pas hasRole('Editor') —, pour que redéfinir un rôle soit un changement de données et non un refactoring, avec une application des règles côté serveur et un refus par défaut.

Cas d’usage courants

• Panneaux d’administration et back-offices — support, modérateur, finance, super-admin : les fonctions se traduisent proprement en rôles.
• Workflows de contenu et de publication — auteur, éditeur, publieur, avec une séparation entre écrire et publier.
• Permissions d’équipe en SaaS B2B — owner/admin/membre/facturation par espace de travail, cloisonnés par tenant.
• Opérations soumises à la conformité — la séparation des tâches sous forme de contraintes de rôle applicables, l’appartenance aux rôles servant de pièce d’audit.
• La porte des rôles sur les couches de données — les rôles comme le “qui” des permissions au niveau de la classe et des politiques au niveau des lignes.

Devriez-vous utiliser le RBAC ? Matrice de décision

Limites et trade-offs

• Le partage par objet est hors périmètre. “Partager ce document avec Ana” n’a pas de réponse RBAC, sauf à créer un rôle par document — cette décision revient aux ACL.
• Même rôle, mêmes pouvoirs. Deux Editors sont indiscernables ; la nuance individuelle exige une autre couche, pas un rôle quasi dupliqué.
• L’ingénierie des rôles est un vrai travail en amont. La sauter produit des rôles qui ne reflètent ni l’organisation ni le modèle de risque — et qui sont copiés à l’infini.
• Des rôles statiques ne voient pas le risque dynamique. L’appartenance à un rôle ne perçoit ni les horaires inhabituels, ni les nouveaux appareils, ni les états sensibles d’un enregistrement ; c’est le territoire des attributs.
• La dérive est l’état stationnaire. Sans recertification périodique, le périmètre des rôles ne fait que grandir ; l’auditabilité du RBAC est une capacité, pas une garantie.

Les rôles sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les rôles y sont des données, pas du code : chacun est un objet de la classe _Role, avec une relation users pour les membres et une relation roles pour l’imbrication — et l’imbrication, c’est une hiérarchie obtenue sans effort, puisque les membres d’un rôle enfant héritent de tout ce qui est accordé à ses rôles parents. Les droits eux-mêmes s’accordent exactement là où l’indique la section sur la composition : les noms de rôle apparaissent dans les permissions au niveau de la classe pour les grandes lignes et dans les entrées d’ACL par objet pour les exceptions — les onglets de code montrent les deux moitiés —, et Back4app applique le résultat à chaque requête REST, GraphQL et Live Query. Comme les rôles sont des objets interrogeables, la gestion des membres, les audits et les interfaces d’administration relèvent du travail ordinaire sur la base de données : prévenir l’explosion des rôles devient une habitude de modélisation, pas un projet de gouvernance.