RBAC (Role-Based), ABAC (Attribute-Based) et ReBAC (Relationship-Based) sont les trois piliers des autorisations modernes. Chacun répond à des besoins spécifiques : simplicité, granularité ou relations complexes.
1. RBAC — Role-Based Access Control
📌 Principe
Les permissions sont attribuées à des rôles, et les utilisateurs reçoivent des rôles. C'est le modèle le plus répandu (IAM cloud, bases de données, OS).
Exemple : Rôle "Auditeur" → lecture seule sur tous les logs. Rôle "Admin" → tous droits.
✅ Avantages
- Simple à comprendre et à implémenter
- Performant (vérification rapide)
- Facile à auditer (liste des rôles)
⚠️ Limites
- Évolution explosive du nombre de rôles (role explosion)
- Inadapté aux règles contextuelles (heure, localisation, etc.)
- Difficile à gérer pour des accès très granulaires
2. ABAC — Attribute-Based Access Control
📌 Principe
Les décisions d'accès se basent sur des attributs (utilisateur, ressource, environnement). Une politique s'exprime sous forme de règles logiques.
Exemple : "Un médecin peut accéder au dossier d'un patient si la date est dans les 30 jours suivant la consultation ET si le patient a consenti."
✅ Avantages
- Granularité extrême (filtrage fin)
- Contextuel (heure, IP, risque, etc.)
- Pas de multiplication des rôles
⚠️ Limites
- Complexité de gestion des politiques (XACML, Rego)
- Performance potentiellement moindre
- Courbe d'apprentissage élevée
3. ReBAC — Relationship-Based Access Control
📌 Principe
Popularisé par Google Zanzibar, ReBAC s'appuie sur les relations entre utilisateurs et ressources ou entre ressources elles-mêmes. On utilise des graphes d'autorisations.
Exemple : "Alice est propriétaire du document D. Bob est éditeur du dossier F qui contient D → Bob peut modifier D."
✅ Avantages
- Idéal pour l'héritage et les relations imbriquées
- Scale horizontalement (ex: Google Drive, Slack)
- Supporte les "groupes de groupes" naturellement
⚠️ Limites
- Plus complexe à implémenter que RBAC simple
- Nécessite une base de données de graphe ou un moteur dédié (OpenFGA, Oso, Zanzibar)
- Latence potentielle sur grands graphes (optimisation requise)
📊 Comparaison synthétique
| Critère | RBAC | ABAC | ReBAC |
|---|---|---|---|
| Base de la décision | Rôles | Attributs | Relations |
| Granularité | Moyenne | Très fine | Fine + héritage |
| Performance | Élevée | Moyenne | Élevée (avec cache) |
| Complexité admin | Faible | Élevée | Moyenne |
| Contextuel (heure, IP) | Non | Oui | Partiel (via attributs) |
| Exemple standard | IAM AWS | XACML, OPA | Google Zanzibar, OpenFGA |
🤔 Comment choisir ?
👉 RBAC par défaut : si votre application a des rôles bien définis (admin, utilisateur, support) et peu de cas particuliers.
👉 ABAC si : vous avez besoin de règles contextuelles ou de politiques très granulaires (secteur médical, financier).
👉 ReBAC si : votre modèle métier repose sur des relations hiérarchiques (dossiers, organisations, partages) et vous avez besoin d'héritage des permissions.
💡 Astuce hybride
La plupart des systèmes combinent : RBAC pour les permissions larges + ReBAC pour les relations entre ressources, ou ABAC pour certaines conditions (ex: MFA requis).
✅ Checklist pour implémenter un modèle d'accès
- ☑️ Lister les actions possibles (lecture, écriture, suppression, partage)
- ☑️ Identifier les ressources (documents, projets, API)
- ☑️ Définir les utilisateurs et leurs attributs (rôle, service, localisation)
- ☑️ Tracer les relations naturelles (propriétaire, membre, éditeur, viewer)
- ☑️ Choisir le moteur (PostgreSQL + RLS, OpenFGA, OPA, Casbin, Oso)
- ☑️ Ne pas sur-ingénierier : RBAC simple reste très efficace
- ☑️ Tester les performances avec des graphes de grande taille (si ReBAC)