Le contrôle d'accès basé sur les rôles (RBAC) paraît simple sur un tableau blanc : déterminer les fonctions qui existent, construire un rôle pour chacune, puis affecter les personnes à des rôles plutôt que de leur attribuer des droits un par un. La plupart des déploiements RBAC ne font pas réellement cela. Ils construisent plutôt les rôles autour de titres de poste — parce que les titres sont déjà bien rangés et étiquetés dans le système des ressources humaines, alors que la fonction réelle derrière un titre est plus désordonnée et que personne n'est chargé de la décrire.
Le problème est que titres et fonctions divergent presque immédiatement. Un titre est un enregistrement RH à évolution lente, mis à jour au rythme des promotions. Une fonction est ce que quelqu'un fait réellement ce trimestre — remplacer un collègue, mener un projet hors de son mandat habituel, hériter d'un système que personne d'autre ne veut posséder. Construire le modèle d'accès sur l'étiquette plutôt que sur le comportement, c'est modéliser quelque chose qui était déjà légèrement faux dès le premier jour et qui devient plus faux chaque mois qui suit.
Le symptôme visible est l'explosion des rôles. Une fois qu'un rôle générique « Analyste » s'avère inadapté pour la moitié des personnes qui le portent, la solution qui semble évidente est de créer un rôle plus précis — « Analyste senior, région Ouest, rapports seulement » — plutôt que de se demander pourquoi le rôle a été construit autour d'un titre dès le départ. Quelques centaines de rôles plus tard, le catalogue de rôles est plus long que la liste de droits qu'il devait simplifier, et personne ne peut dire ce qu'un rôle donné accorde réellement sans l'ouvrir et en lire les permissions brutes. À ce stade, le processus de revue d'accès, censé être le filet de sécurité, devient un simple tampon d'approbation — revoir mille rôles étroitement définis que personne ne comprend pleinement n'est pas vraiment différent de revoir directement les droits bruts, sauf que cela prend plus de temps et paraît plus officiel.
La sortie n'est pas une convention de nommage plus astucieuse pour les rôles. C'est construire le modèle à partir de deux directions et les réconcilier : de haut en bas, à partir de ce qu'une fonction est censée pouvoir toucher, et de bas en haut, à partir de ce que les personnes exerçant cette fonction utilisent réellement au quotidien. L'écart entre ces deux vues, voilà où vit le véritable modèle d'accès — pas dans ce que l'organigramme appelle quelqu'un par hasard. Souvent, les deux vues sont en désaccord de façon instructive : la conception descendante dit qu'une fonction a besoin d'un accès en lecture à un système, les données ascendantes montrent que personne dans cette fonction ne l'a ouvert depuis un an, et voilà une vraie question à poser plutôt qu'une hypothèse à automatiser.
Rien de tout cela ne survit comme projet ponctuel. Un modèle de rôles construit une fois puis laissé de côté commence à pourrir dès que l'organisation change de forme en dessous de lui, ce qui arrive immédiatement. Il exige la même discipline d'entretien que tout ce qui se dégrade au contact de la réalité — un passage récurrent qui vérifie si la correspondance fonction-rôle décrit encore ce que les gens font, pas une présentation du déploiement initial que tout le monde continue de citer deux réorganisations plus tard.
Le RBAC n'est pas la mauvaise idée. Il est simplement nommé d'après le mauvais nom quand le « rôle » du contrôle d'accès basé sur les rôles décrit un titre plutôt qu'une fonction. Corrigez ce que le rôle représente réellement, et le reste du modèle tient tout seul.