Pourquoi l’administration des accès basés sur les rôles est-elle si ardue ?

D’un point de vue théorique, cette approche consiste à placer les utilisateurs non plus dans des groupes, mais dans des rôles correspondant à leur fonction réelle. La magie de la chose est que les utilisateurs accèdent ainsi à tous les fichiers, dossiers, bases de données, boîtes à lettres et éléments similaires dont ils ont besoin.

RBA, Role-Based Access

J’ai récemment eu une conversation à bâtons rompus avec des clients qui n’appréhendent pas complètement la complexité des accès basés sur les rôles (ou RBA, Role-Based Access) et, pour lesquels, le terme rôle n’est qu’une autre appellation des groupes natifs dans Windows. Malheureusement, cette vision est complètement erronée.

Bien évidemment, vous pouvez créer un groupe de sécurité de domaine intitulé « commerciaux maison », auquel cas vous avez un rôle désignant une fonction. Ce groupe peut même constituer une liste de distribution pratique et vous ferez ainsi d’une pierre deux coups. En supposant que les seules ressources auxquelles les membres du groupe accèdent sont des fichiers, dossiers et, peut-être, des bases de données SQL Server, vous pouvez fort bien avoir mis en place des accès RBA. Néanmoins, toutes ces ressources doivent alors résider sur un domaine unique ou des domaines de confiance et il faut que vous ayez entièrement confiance dans vos administrateurs. Les conditions à remplir sont donc nombreuses et montre bien que les groupes d’utilisateurs n’ont rien à voir avec l’administration basée sur les rôles.

Les groupes constituent une implémentation technique, alors que l’approche RBA représente un élément logique de votre réseau, qui s’appuie sur une stratégie. Prenez le temps d’examiner les choses et vous verrez que c’est vrai. Que se passe-t-il lorsqu’une nouvelle personne arrive dans l’entreprise ? Une des premières questions posées est, « de quels accès cette personne a-t-elle besoin ? » La réponse est généralement « Le même accès que Bob, ou Joe, ou qui que ce soit occupant une fonction similaire. Vous devez alors déterminer les accès octroyés à Bob. En général, ce dernier étant membre de plusieurs groupes d’utilisateurs, il faut commencer à dupliquer les appartenances. Toute cette démarche n’a rien à voir avec l’administration basée sur les rôles, laquelle procède comme suit :

1. Il est inutile de connaître les mécanismes d’autorisations sous-jacents pour rattacher la personne au rôle approprié.
2. Les personnes chargées de superviser les autorisations (par ex., les administrateurs) n’ont pas forcément besoin de contrôler les appartenances aux rôles.

Ce deuxième point est important car il constitue une séparation des attributions. Tandis qu’il est en mesure de modifier une appartenance à un groupe d’utilisateurs, l’administrateur ne doit pas pouvoir changer l’appartenance à un rôle. Ce droit indique que les groupes d’utilisateurs seuls ne forment pas l’administration basée sur les rôles.