RBAC vs ABAC : quand recourir à chacun en pratique ?
Réponse courte
Le RBAC accorde des permissions via des rôles assignés aux utilisateurs — simple à raisonner mais sujet à l'explosion des rôles à mesure que les cas particuliers se multiplient. L'ABAC évalue des politiques sur les attributs de l'utilisateur, de la ressource, de l'action et de l'environnement, ce qui permet des décisions fines et contextuelles au prix de la complexité. La plupart des systèmes matures les combinent : des rôles pour les octrois grossiers, des attributs et des politiques pour les détails conditionnels.
Les modèles de contrôle d'accès décident qui peut faire quoi sur quelle ressource. RBAC et ABAC sont les deux que l'on vous demandera de comparer, et la bonne réponse est rarement « choisissez-en un ».
RBAC : le rôle comme unité d'octroi
Dans le contrôle d'accès basé sur les rôles, les permissions sont regroupées en rôles, et les rôles sont assignés aux utilisateurs. Un rôle billing-admin porte les permissions de lire les factures et d'émettre des remboursements ; quiconque dans ce rôle en hérite. C'est facile à auditer (« qui est dans billing-admin ? ») et se mappe proprement sur les fonctions métier.
Le mode de défaillance est l'explosion des rôles. Chaque « mais ce groupe d'utilisateurs a besoin de presque la même chose, sauf que... » engendre un nouveau rôle. Quelques centaines d'utilisateurs peuvent finir derrière des milliers de rôles qui se chevauchent et que personne ne comprend pleinement, ce qui sabote discrètement le moindre privilège.
ABAC : des politiques sur les attributs
Le contrôle d'accès basé sur les attributs évalue une politique au moment de la requête sur des attributs : le sujet (service, habilitation, statut d'emploi), la ressource (classification, propriétaire, région), l'action et l'environnement (heure, posture de l'appareil, IP source). Une règle comme « autoriser la lecture si user.department == resource.department et device.compliant == true » exprime en un énoncé ce qui prendrait de nombreux rôles RBAC.
Le coût est la complexité : il vous faut une source fiable pour chaque attribut, les politiques deviennent plus difficiles à raisonner, et « pourquoi cela a-t-il été refusé ? » peut être peu évident.
En pratique : combinez-les
La plupart des systèmes matures utilisent des rôles pour les octrois grossiers et des attributs/politiques pour les détails conditionnels — parfois appelé PBAC ou policy-as-code (p. ex. OPA/Rego, conditions AWS IAM). Le RBAC répond à « quel métier exercez-vous », l'ABAC répond à « dans ce contexte précis, est-ce autorisé ».
Ce que recherchent les recruteurs : vous savez nommer l'explosion des rôles et la confiance dans les attributs comme les vrais compromis, et vous proposez une superposition plutôt que d'en faire un choix dogmatique.
Questions de suivi probables
- Qu'est-ce que « l'explosion des rôles » et comment l'ABAC aide-t-il à l'éviter ?
- Comment combineriez-vous le RBAC et l'ABAC dans un même système ?
- Où stockez-vous et faites-vous confiance aux attributs dont dépend l'ABAC ?