Contrôle d'accès basé sur les relations (ReBAC)
Le contrôle d'accès basé sur les relations, ou ReBAC (Relationship-Based Access Control), est un modèle d'autorisation dans lequel les décisions reposent sur les relations entre sujets, ressources et autres entités.
- Acronyme
- ReBAC
- Synonyme
- Relationship-Based Access Control
Définition
Le contrôle d'accès basé sur les relations, ou ReBAC, est une approche d'autorisation dans laquelle l'accès est déterminé par des relations de type propriétaire de, manager de, membre de, approbateur de, délégué par, éditeur de ou parent de. ReBAC signifie Relationship-Based Access Control. Au lieu de s'appuyer principalement sur des rôles ou des attributs, le ReBAC se concentre sur la manière dont les entités sont connectées. Ce modèle est particulièrement utile dans les systèmes collaboratifs, les plateformes de contenu, la santé, le partage B2B, l'administration déléguée et les environnements multi-tenant où l'accès dépend de l'ownership, de hiérarchies ou de relations métier. Le ReBAC permet souvent d'exprimer plus naturellement des permissions au niveau objet et des schémas de délégation que le RBAC traditionnel.
Comment fonctionne le ReBAC ?
Le ReBAC représente les faits utiles à l'autorisation sous forme de relations entre des sujets et des ressources. Une permission peut être directe — « Alice est propriétaire du document » — ou découler d'une chaîne de relations.
Si le modèle autorise les membres de l'équipe propriétaire à consulter les documents du dossier, Alice peut obtenir cette permission sans qu'un droit individuel soit créé pour chaque document.
Les systèmes inspirés de Google Zanzibar représentent couramment ces relations sous forme de relationship tuples et évaluent ensuite si un chemin de relations satisfait la permission demandée.
- Alice
- membre de
- Équipe Finance
- propriétaire de
- Dossier Budget
Pourquoi c'est important
Le ReBAC est très pertinent pour les applications modernes où l'autorisation dépend de qui est relié à quoi, et pas uniquement d'un rôle organisationnel. Il est particulièrement naturel lorsque le partage, l'ownership, la délégation ou la hiérarchie des ressources font directement partie du fonctionnement métier de l'application.
Le point de vue d'Ariovis
Le ReBAC est un excellent modèle lorsque les relations constituent naturellement la réalité métier de l'autorisation.
Ariovis évite en revanche de faire d'un moteur d'autorisation un nouveau référentiel de toute la réalité du SI lorsque ce n'est pas nécessaire. Une décision peut aussi dépendre de l'identité, d'attributs, du contexte, du risque, de la classification de la ressource ou d'informations détenues par les applications métier.
Dans ces situations, nous privilégions une approche pilotée par politiques, capable d'agréger les bonnes données au moment de la décision. ReBAC et PBAC ne sont d'ailleurs pas nécessairement concurrents : une relation peut devenir l'une des informations évaluées par une politique.
Offres associées
Les pièges courants
- Les équipes sous-estiment parfois la gouvernance des relations : qui les crée, qui les met à jour et quelle source en fait foi ? Les héritages et chaînes de relations indirectes peuvent également compliquer l'analyse d'une décision. Un modèle ReBAC doit donc rester explicable, maintenable et correctement synchronisé avec les systèmes qui portent la réalité métier.
Architectures et technologies associées
- Google ZanzibarArchitecture de référence
Système d'autorisation publié par Google, conçu pour gérer de manière cohérente des relations et permissions à grande échelle. Zanzibar a fortement influencé les architectures ReBAC modernes.
- OpenFGAMoteur d'autorisation ReBAC
Projet open source inspiré des principes de Zanzibar, reposant sur des modèles d'autorisation et des relations entre utilisateurs et objets.
- SpiceDBSystème d'autorisation inspiré de Zanzibar
Système open source de permissions relationnelles développé par AuthZed et directement inspiré de l'architecture Google Zanzibar.
Pour aller plus loin
- ReBAC vs PBAC : modéliser les relations ou interroger les bonnes données ?Notre lecture architecturale : quand la relation est la bonne donnée, et quand la politique doit orchestrer plusieurs sources de vérité.
- Autorisation fine et dynamiqueComment Ariovis conçoit, intègre et opère des décisions d'autorisation contextuelles.
- PBAC : La nouvelle génération du contrôle des accèsPDP, PEP, PAP et PIP : le prolongement naturel vers une approche pilotée par politiques.
- Comprendre la granularité de l'autorisation d'accèsLa granularité est une dimension distincte, qui peut se superposer aux différents modèles d'autorisation.
Explorer la même catégorie
Ces notions prennent tout leur sens dans un projet réel.
Le premier échange permet de comprendre votre contexte, vos systèmes et la prochaine décision utile.