DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir

Chaque modèle de contrôle d’accès répond à une seule question, et c’est elle qui doit guider le choix. Les sigles et la mode du moment viennent après. Cette page compare DAC, MAC, RBAC, ABAC et ReBAC sous cet angle, dit lequel retenir pour quel niveau de décision, comment les empiler sans se contredire, et où chacun casse en production.

→ Lire l’explication complète de la marmotte

Cinq modèles, cinq questions d’autorisation

Un modèle de contrôle d’accès est une façon de formuler la règle qui relie un sujet (personne, service), une action et une ressource. Les cinq modèles courants ne s’opposent pas sur la technique. Ils diffèrent par l’information qu’ils regardent pour décider.

Modèle	Question à laquelle il répond	Qui écrit la règle	Exemple canonique
DAC (Discretionary Access Control)	À qui appartient la ressource, et qu’a-t-il décidé de partager ?	Le propriétaire de l’objet	Permissions Unix, ACL (Access Control List) NTFS, partage de document
MAC (Mandatory Access Control)	Quel niveau de classification ou quelle étiquette autorise ce flux ?	L’autorité centrale, jamais l’utilisateur	SELinux (Security-Enhanced Linux), AppArmor, niveaux Bell-LaPadula
RBAC (Role-Based Access Control)	Quelle fonction la personne occupe-t-elle ?	L’administrateur des rôles	Rôles Kubernetes, groupes applicatifs
ABAC (Attribute-Based Access Control)	Dans quel contexte la demande arrive-t-elle ?	L’auteur de politiques	« département = finance ET poste géré ET heure ouvrée »
ReBAC (Relationship-Based Access Control)	Quel lien existe entre la personne et l’objet ?	L’application, qui écrit les relations dans le graphe	« éditeur du dossier parent », modèle Zanzibar

DAC laisse le propriétaire décider. C’est le modèle par défaut des systèmes de fichiers : sur Unix, le propriétaire d’un fichier peut faire chmod 666 sans demander l’avis de personne. Sa faiblesse est structurelle. Tout programme lancé par l’utilisateur hérite de ses droits, donc un cheval de Troie peut recopier un fichier confidentiel dans un répertoire lisible par tous, et DAC trouvera ça parfaitement légitime. Les mécanismes Unix sont détaillés dans Permissions et processus Linux.

MAC retire la décision à l’utilisateur. Une étiquette (niveau de classification, type SELinux, catégorie) est attachée au sujet et à l’objet, et une politique centrale arbitre les flux. Le modèle de Bell-LaPadula (1973) formalise la confidentialité (« pas de lecture vers le haut, pas d’écriture vers le bas »), Biba formalise l’intégrité en sens inverse ; les deux sont traités dans Bell-LaPadula, Biba et Clark-Wilson. MAC est le seul des cinq qui résiste au propriétaire malveillant ou compromis, ce qui explique sa présence dans les noyaux et sa rareté dans les applications métier.

RBAC attache les permissions à des rôles et les rôles aux personnes. Le modèle RBAC96 de Sandhu et ses coauteurs (1996) distingue RBAC0 (rôles plats), RBAC1 (hiérarchie), RBAC2 (contraintes, dont la séparation des tâches) et RBAC3 (les deux) ; la norme ANSI INCITS 359-2004 en reprend la substance sous d’autres noms (noyau, hiérarchie, séparation statique et dynamique des tâches). Son atout majeur : la question de revue « qui peut faire quoi ? » se résout par une jointure, ce qui le rend auditable.

ABAC évalue des attributs du sujet, de la ressource, de l’action et de l’environnement contre une politique. Le NIST (National Institute of Standards and Technology) l’a décrit dans la SP 800-162 (2014) ; XACML (eXtensible Access Control Markup Language) 3.0, puis Rego (OPA, Open Policy Agent) et Cedar en sont les langages. ABAC exprime presque tout, y compris ce qu’on n’aurait pas dû exprimer.

ReBAC décide à partir d’un graphe : l’utilisateur U a accès au document D parce qu’il est membre du groupe G, qui est éditeur du dossier F, qui contient D. C’est le modèle des outils collaboratifs et du partage fin. Le fonctionnement, la cohérence et le modèle Zanzibar sont détaillés dans ReBAC et Zanzibar. Le responsable légal qui ne doit voir que les bulletins de l’enfant dont il a la charge en fournit un cas d’école, traité dans la sécurité des données d’élèves mineurs : un parent n’est pas un rôle, c’est une relation.

Le compromis central : expressivité contre auditabilité

Le choix d’un modèle se paie sur un axe unique. Plus le modèle est expressif, plus la question inverse devient chère : « pour cette ressource, qui a accès ? ».

En RBAC, la réponse est une liste de membres de rôles, calculable et révisable par un humain. C’est ce qui permet les campagnes de revue d’accès et la vérification de séparation des tâches décrites dans la page Gouvernance des identités.

En ReBAC, la réponse existe mais demande un parcours de graphe (l’opération expand ou lookup des moteurs de type Zanzibar). Elle reste calculable, avec un coût qui croît avec la profondeur des relations.

En ABAC, la question inverse n’a en général pas de réponse énumérable : une politique qui dépend de l’heure, de la posture du poste et de l’adresse IP source ne produit pas de liste de personnes, elle produit une fonction. Une revue d’accès ABAC revient donc à relire du code de politique. Les auditeurs acceptent d’ailleurs assez mal un « la liste des accès dépend de la météo » comme réponse à « qui peut lire la paie ? ».

La position de cette page : RBAC pour les droits de fonction, ReBAC pour les droits sur les objets, ABAC uniquement comme filtre contextuel restrictif, MAC comme socle système. Cette répartition garde la question de revue calculable là où les régulateurs la posent (les fonctions et les privilèges), et réserve l’expressivité aux décisions que personne ne revoit ligne à ligne (« Alice peut-elle commenter ce document ? »). Elle cesse d’être valable quand la décision dépend fondamentalement d’attributs de la donnée (classification, finalité RGPD, résidence) : là, ABAC devient porteur et la revue doit porter sur les politiques et sur la qualité des attributs.

L’arbre suivant se lit de haut en bas : on part de la question réelle que l’autorisation doit trancher, et on aboutit au modèle porteur.

Combiner les modèles sans se contredire

En production, personne n’utilise un seul modèle, et c’est sain. Une requête typique traverse plusieurs couches : MAC sur le nœud qui exécute le conteneur, RBAC dans l’orchestrateur et dans l’application, ReBAC pour l’objet manipulé, ABAC pour le contexte de la session. La difficulté n’est pas l’empilement, c’est l’ordre de combinaison.

Trois règles évitent les incohérences :

Chaque couche ne peut que restreindre. Le droit effectif est l’intersection des couches, jamais l’union. Une politique ABAC qui « ouvre » ce que RBAC a fermé crée deux sources de vérité, et la revue d’accès n’en voit qu’une. Le calcul du droit effectif à travers groupes et héritages est traité dans Héritage des permissions.
L’algorithme de combinaison est explicite. XACML nomme les options (deny-overrides, permit-overrides, first-applicable) ; Cedar impose qu’un forbid l’emporte toujours sur un permit. Un moteur où l’absence de règle applicable produit autre chose qu’un refus est une faille en attente.
Une seule décision par requête, prise par un point unique. Le schéma ci-dessous montre la séparation classique entre le PEP (Policy Enforcement Point), qui intercepte, et le PDP (Policy Decision Point), qui décide à partir du PIP (Policy Information Point) et des politiques publiées par le PAP (Policy Administration Point).

On y lit surtout que les attributs viennent du PIP, côté serveur, et jamais de la requête du client.

L’erreur la plus fréquente de cette architecture : laisser plusieurs PEP implémenter chacun « un peu » d’autorisation. La passerelle vérifie le rôle, l’application vérifie le propriétaire de l’objet sur trois endpoints sur quatre, et le quatrième devient une vulnérabilité BOLA (Broken Object Level Authorization), décrite dans BOLA et contrôle d’accès objet dans les API.

La sécurité au niveau des lignes comme point d’application

La RLS (Row-Level Security) des bases de données est l’endroit où un modèle abstrait devient une clause WHERE que personne ne peut oublier. PostgreSQL (depuis la version 9.5), SQL Server, Oracle (Virtual Private Database) l’implémentent. La politique RLS est presque toujours de l’ABAC (attribut de session comparé à une colonne, par exemple l’identifiant de locataire) ou du ReBAC dénormalisé (jointure sur une table de relations).

Son intérêt est architectural : le contrôle s’applique même aux requêtes écrites à la main, aux outils de reporting et au code qui a oublié le filtre. Son piège l’est tout autant : la base ne connaît pas l’utilisateur final, seulement le rôle de connexion et ce que l’application lui a déclaré. La RLS ne vaut donc que ce que vaut l’attribut de session.

Exemple : isolation par locataire avec la RLS PostgreSQL

L’extrait suivant applique une politique ABAC (l’attribut app.tenant_id de la transaction doit égaler la colonne tenant_id). Il fonctionne dès PostgreSQL 9.5 ; la remarque sur les vues plus bas suppose PostgreSQL 15 ou ultérieur.

-- Table multi-locataires
CREATE TABLE factures (
  id        bigserial PRIMARY KEY,
  tenant_id uuid    NOT NULL,
  montant   numeric NOT NULL
);

-- Active la RLS, y compris pour le propriétaire de la table
ALTER TABLE factures ENABLE ROW LEVEL SECURITY;
ALTER TABLE factures FORCE ROW LEVEL SECURITY;

-- USING filtre la lecture, WITH CHECK bloque l'écriture hors locataire
CREATE POLICY isolation_locataire ON factures
  USING      (tenant_id = current_setting('app.tenant_id', true)::uuid)
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- Rôle applicatif sans BYPASSRLS, ni propriétaire, ni superutilisateur
CREATE ROLE app_web LOGIN NOBYPASSRLS;
GRANT SELECT, INSERT, UPDATE ON factures TO app_web;
GRANT USAGE ON SEQUENCE factures_id_seq TO app_web;

-- Côté application, dans chaque transaction
BEGIN;
SET LOCAL app.tenant_id = '6f1c2b0e-0000-4000-8000-000000000001';
SELECT id, montant FROM factures;   -- ne voit que ce locataire
COMMIT;

Points à vérifier avant de considérer l’isolation acquise :

current_setting(..., true) renvoie NULL si le paramètre n’a jamais été défini : la comparaison donne NULL, donc aucune ligne. Le défaut est fermé, ce qui est le bon sens. Si le paramètre a été défini puis réinitialisé dans la session, il vaut une chaîne vide et la conversion en uuid échoue : la requête tombe en erreur, ce qui reste fermé.
SET LOCAL et non SET : avec un pool de connexions en mode transaction (PgBouncer, par exemple), un SET de session survit à la transaction et le client suivant hérite du locataire précédent. C’est la fuite inter-locataires la plus banale qui soit, et elle passe tous les tests unitaires parce que les tests n’ont qu’un locataire.
Les superutilisateurs et les rôles BYPASSRLS ignorent toute politique. Sans FORCE ROW LEVEL SECURITY, le propriétaire de la table aussi.
Une vue créée sans security_invoker = true (PostgreSQL 15 et ultérieur) s’exécute avec les droits de son propriétaire et peut contourner la RLS de la table sous-jacente.

Prérequis de plateforme et de mise en œuvre

Avant de choisir un modèle, plusieurs fondations doivent exister, faute de quoi le modèle le plus élégant décide sur du sable.

Une source d’autorité pour chaque donnée de décision. Le rôle vient du système RH ou de l’IGA (Identity Governance and Administration), le département d’un référentiel, la relation de l’application métier. Un attribut sans propriétaire est un attribut faux à terme. Les comptes sans propriétaire sont traités dans Comptes orphelins.
Des identifiants stables. ReBAC et ABAC référencent des sujets et des objets ; un identifiant réattribué (adresse de messagerie recyclée, identifiant d’objet réutilisé) transfère silencieusement les droits de l’ancien porteur.
Une authentification fiable en amont. Tous les modèles supposent que le sujet est bien celui qu’il prétend être (voir Authentification).
Des jetons dont on maîtrise le contenu. Quand rôles ou attributs voyagent dans un jeton OIDC (OpenID Connect) ou JWT (JSON Web Token), leur durée de vie fixe le délai de révocation ; voir Cycle de vie des jetons.
Côté outillage : un moteur de politiques versionnable (OPA, Cedar, moteur XACML), un moteur ReBAC si le graphe dépasse ce qu’une table de jointure supporte (OpenFGA, SpiceDB), un noyau avec SELinux ou AppArmor en mode bloquant pour le socle MAC.

Surface d’attaque par modèle et contre-mesures

Modèle	Attaques connues	Contre-mesures
DAC	Cheval de Troie exécuté avec les droits de l’utilisateur ; propagation de droits par le propriétaire ; partage public par erreur ; adjoint confus (programme privilégié qui agit pour un appelant)	MAC en socle, `umask` restrictif, détection des partages publics, comptes de service distincts des humains
MAC	Mauvais étiquetage à l’import ; mode permissif laissé actif « temporairement » ; règles d’exception larges générées par `audit2allow` ; canaux cachés	Mode bloquant contrôlé par la supervision, revue des modules de politique ajoutés, étiquetage à la source
RBAC	Explosion des rôles (plus de rôles que de personnes, le stade où le modèle a été inventé une seconde fois en pire) ; accumulation de droits lors des mobilités ; rôle « admin » fourre-tout ; mappage groupe IdP vers rôle trop large	Rôles bornés par fonction, contraintes de séparation, revues périodiques, accès juste à temps pour les rôles privilégiés
ABAC	Attribut fourni par le client (en-tête, paramètre) et cru par le PDP ; attribut périmé en cache ; « aucune règle applicable » traité comme un accord ; politique contradictoire illisible	Attributs uniquement depuis le PIP, TTL (Time To Live) de cache courts sur les attributs sensibles, défaut à refus, tests de politiques automatisés
ReBAC	« Nouvel ennemi » (décision prise sur un état du graphe antérieur à une révocation) ; relations orphelines après suppression d’objet ; graphe très profond qui sert de déni de service	Jetons de cohérence (zookies), suppression des relations dans la même transaction que l’objet, profondeur de parcours bornée

Une mise en garde transversale : la révocation d’un rôle ou d’une relation ne se propage pas aux décisions déjà mises en cache ni aux jetons déjà émis. Le délai réel de révocation est le maximum entre la durée de vie du jeton, le TTL du cache de décision et le délai de synchronisation du référentiel. Ce chiffre doit être connu, écrit, et accepté par le propriétaire du risque.

Ce que les modèles de contrôle d’accès ne garantissent pas

L’authentification. Un modèle d’autorisation décide pour un sujet donné ; si l’identité est usurpée, il autorise l’usurpateur avec une rigueur exemplaire.
L’application du contrôle. Un modèle sans point d’application systématique est une documentation. Le défaut d’application au niveau objet relève du code, pas du modèle.
L’usage légitime des données. Un utilisateur autorisé qui exporte tout le portefeuille clients reste autorisé. La détection d’usage anormal vient de la journalisation et de l’analyse comportementale, pas du modèle.
La gouvernance. Aucun modèle ne retire un droit devenu inutile. La revue d’accès, la gestion des départs et la séparation des tâches relèvent de l’IGA (voir Gouvernance des identités), et les comptes partagés détruisent l’imputabilité quel que soit le modèle.
La protection contre l’administrateur du modèle. Celui qui écrit les politiques ou les relations peut s’accorder n’importe quoi. Ce risque se traite par la séparation des plans de contrôle et l’approbation à deux personnes des changements de politique.

Conditions d’exploitation

Politiques comme code. Les politiques ABAC, les définitions de rôles et le schéma ReBAC se versionnent, se relisent et se testent comme du code applicatif. Un jeu de tests de décision (« Alice, rôle comptable, poste non géré, lecture paie : refus attendu ») doit tourner à chaque modification. Le PAP ne publie que des politiques signées, et la clé de signature suit les règles de gestion de clés du site (voir Cryptographie).

Disponibilité du PDP. Un PDP centralisé est une dépendance critique. Deux choix s’offrent : PDP embarqué (bibliothèque ou conteneur adjacent, politiques distribuées) ou PDP distant avec cache. Dans les deux cas, l’indisponibilité doit produire un refus. Un mode dégradé qui accorde « pour ne pas bloquer la production » transforme une panne en ouverture totale, et l’attaquant n’a plus qu’à provoquer la panne.

Journal des décisions. Chaque décision journalise le sujet, l’action, la ressource, la version de politique et le résultat. Sans la version de politique, une décision passée devient inexplicable dès la modification suivante. Ces journaux contiennent des données personnelles et suivent la durée de conservation définie pour la traçabilité.

Sauvegarde et reprise. Le graphe ReBAC et le référentiel d’attributs sont des données de sécurité de premier rang : leur perte bloque tout le monde, leur restauration à une date antérieure ressuscite des droits révoqués. La reprise doit rejouer les révocations survenues depuis la sauvegarde, ou à défaut forcer une resynchronisation depuis les sources d’autorité avant réouverture du service.

Supervision. Indicateurs à suivre : taux de refus par politique (un pic signale une régression, une chute brutale signale une règle trop ouverte), latence du PDP, nombre de rôles par personne, relations sans objet existant, et pour MAC, toute bascule en mode permissif.

FAQ

RBAC est-il dépassé face à ABAC et ReBAC ?

Non. RBAC reste le seul des trois dont la revue d’accès produit une liste de personnes, ce qu’exigent la plupart des référentiels de conformité. Il devient insuffisant pour les droits sur les objets individuels ; c’est là qu’intervient ReBAC, en complément et non en remplacement.

Faut-il un moteur ReBAC dédié ou une table de relations suffit-elle ?

Une table de jointure avec une politique RLS suffit tant que les relations ont un ou deux niveaux et que l’application est unique. Un moteur dédié se justifie quand plusieurs services partagent le même graphe, quand l’héritage est profond, ou quand la cohérence face aux révocations doit être garantie entre services.

Où placer DAC dans une architecture moderne ?

Comme modèle de partage à faible enjeu (un utilisateur partage son document), encadré par une politique qui l’empêche de franchir une frontière de classification. Jamais comme seul modèle sur des données réglementées.

🐝 Ce qui arrive si on s’en passe

Sans modèle choisi explicitement, chaque développeur code sa propre règle, et le droit effectif devient la somme de conditions dispersées que personne ne peut énumérer. La question « qui peut lire cette donnée ? » n’a plus de réponse calculable : la revue d’accès certifie des groupes sans savoir ce qu’ils ouvrent, et la séparation des tâches ne se vérifie plus. Un endpoint oublié suffit à exposer les objets d’un autre utilisateur, puisqu’aucun point unique ne refuse par défaut. Une révocation retire le rôle dans l’annuaire mais laisse intactes les vérifications locales qui ne le consultent pas. Après un incident, aucun journal ne relie une décision à la règle qui l’a produite, et l’enquête reconstitue l’autorisation à la main.

🦫 Explication de la marmotte 🍫

Quand une personne demande à lire ou modifier une information dans un logiciel, le logiciel doit décider : oui ou non. Il existe cinq grandes manières de prendre cette décision. La première laisse le propriétaire du fichier choisir avec qui il le partage. La deuxième colle une étiquette de secret sur les personnes et sur les données, et une règle fixée par les responsables interdit à une personne de lire plus secret que son niveau. La troisième regarde le métier de la personne : un comptable reçoit les droits prévus pour les comptables. La quatrième regarde les circonstances : l’heure, l’ordinateur utilisé, le service de la personne. La cinquième regarde le lien entre la personne et l’objet : membre de l’équipe qui possède ce dossier, donc accès à ses documents. Dans un vrai système, on empile plusieurs de ces règles, et chacune ne peut que retirer des droits, jamais en ajouter. Un seul programme prend la décision finale et refuse quand il ne sait pas. Les problèmes arrivent quand une information utilisée pour décider est fausse ou vieille : une personne partie qui garde son métier dans l’annuaire, une donnée envoyée par l’utilisateur lui-même et crue sans vérification, un droit retiré mais encore gardé en mémoire quelques minutes. Il faut aussi pouvoir répondre à la question « qui a accès à cette donnée ? », ce qui est facile avec les métiers et difficile avec les circonstances.

Pages voisines

DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir

Elle cite

: les deux pages se citent l’une l’autre.

DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir

DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir

Cinq modèles, cinq questions d’autorisation

Le compromis central : expressivité contre auditabilité

Combiner les modèles sans se contredire

La sécurité au niveau des lignes comme point d’application

Exemple : isolation par locataire avec la RLS PostgreSQL

Prérequis de plateforme et de mise en œuvre

Surface d’attaque par modèle et contre-mesures

Ce que les modèles de contrôle d’accès ne garantissent pas

Conditions d’exploitation

FAQ

RBAC est-il dépassé face à ABAC et ReBAC ?

Faut-il un moteur ReBAC dédié ou une table de relations suffit-elle ?

Où placer DAC dans une architecture moderne ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines