ABAC : Attribute-Based Access Control
Sécurité
ABAC : Attribute-Based Access Control. « Contrôle d'accès fondé sur les attributs », par analogie avec le videur qui ne regarde pas votre nom sur une liste, mais votre âge, votre tenue et l'heure qu'il est.
Principe : Une politique compare des attributs au moment de la demande : ceux de l'identité (service, niveau d'habilitation), de la ressource (classification, propriétaire, locataire), de l'action (lire, supprimer) et du contexte (heure, réseau, état du poste). La décision tombe à chaque requête, pas une fois pour toutes à l'attribution d'un rôle.
Face au RBAC : Là où le RBAC multiplie les rôles pour chaque combinaison (« comptable de la filiale B en lecture seule »), l'ABAC exprime la règle une fois : « un comptable lit les factures de sa propre filiale ». Les deux se combinent souvent, le rôle devenant un attribut parmi d'autres.
Architecture : Le modèle décrit par le NIST (SP 800-162) sépare le point d'application, qui intercepte la demande, du point de décision, qui évalue la politique. XACML en est la norme historique ; des moteurs de politiques plus récents reprennent le même découpage.
Le prix : Répondre à la question « qui peut accéder à ce dossier ? » devient difficile, car la réponse dépend des valeurs d'attributs au moment de la demande. La politique est élégante, l'audit beaucoup moins, et les auditeurs n'ont pas l'habitude de se contenter de l'élégance.
Ce qui arrive si on s'en passe
Sans contrôle fondé sur les attributs, les règles qui dépendent du contexte (même filiale, même client hébergé, classification du document, heure ou poste utilisé) doivent être codées en dur dans chaque application ou transformées en rôles toujours plus nombreux. Les rôles finissent par dépasser le nombre d'utilisateurs, plus personne ne sait lesquels sont encore utiles, et les droits s'accumulent. Dans une application partagée entre plusieurs clients, une vérification oubliée dans un seul écran suffit à laisser un client lire les données d'un autre. À l'inverse, un ABAC mal gouverné pose son propre risque : des attributs faux ou périmés dans l'annuaire donnent des décisions fausses, et les droits effectifs deviennent impossibles à relire. Des attributs de source fiable et une politique centralisée, testée et versionnée bornent ces deux dérives.
Explication de la marmotte
Pour entrer dans une salle de cinéma, on ne vérifie pas ton nom sur une liste : on regarde si tu as un billet pour ce film, pour cette séance, et si tu as l'âge demandé. En informatique, cette méthode décide qui peut ouvrir un fichier en regardant plusieurs informations à la fois : qui tu es, dans quel service tu travailles, de quel fichier il s'agit, et même l'heure ou l'ordinateur utilisé. Une seule règle bien écrite remplace ainsi des dizaines de listes. L'inconvénient, c'est qu'il devient plus difficile de savoir d'un coup d'œil qui a le droit d'entrer.
Où ce terme est utilisé
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir (20 occurrences)
- Mettre en œuvre les revues d’accès IGA et la SoD (4 occurrences)
- Contrôler les accès d’un assistant IA interne (3 occurrences)
- Prévenir les BOLA dans une API métier (3 occurrences)
- ReBAC Zanzibar pour les autorisations relationnelles fines (3 occurrences)
- Masquage dynamique pour tests et développement (2 occurrences)