Autorisation

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.

  1. Alice
  2. membre de
  3. Équipe Finance
  4. propriétaire de
  5. 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.

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 Zanzibar
    Architecture 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.

  • OpenFGA
    Moteur 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.

  • SpiceDB
    Systè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.

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.