L’insuffisance du modèle RBAC

Le modèle d’habilitation RBAC permet d’établir, au sein du système d’information d’une entreprise, un contrôle d’accès efficace sur les applications et les services IT.

Le modèle d’habilitation RBAC (« Role Based Access Control » en anglais), encore appelé modèle de sécurité RBAC, a commencé à être évoqué en 1992. Il permet d’établir, au sein du système d’information d’une entreprise, un contrôle d’accès efficace sur les applications et les services de ce SI pour ses utilisateurs. Il repose essentiellement sur la définition des rôles à attribuer aux utilisateurs et aux ressources.

Afin de bien comprendre son utilité, partons du modèle d’habilitation IBAC (Identity Based Access Control) qui est moins évolué mais dont RBAC tire son origine.

Le modèle IBAC

Ce modèle est le plus simple et reste adapté lorsque, dans le SI, le nombre d’utilisateurs en fonction des ressources à protéger est très faible.

À chaque utilisateur, il permet de définir des droits d’accès aux ressources du SI, en lecture et en écriture.

Alors que le modèle IBAC ne permet de donner des droits qu’à l’utilisateur, représenté par son compte applicatif, le modèle RBAC s’intéresse d’abord à regrouper les utilisateurs en fonction d’attributs communs.

La gestion des rôles

Il existe différentes approches pour attribuer des rôles aux utilisateurs d’un SI.

La première approche s’attache à identifier les attributs communs des utilisateurs qui accèdent aux mêmes ressources pour en définir les rôles qui correspondent aux droits de ces utilisateurs, souvent à partir de leur fonction ou de leur profil métier.

La seconde approche permet de faire le travail inverse. Il s’agit d’identifier les ressources qui sont associées simultanément, les regrouper afin d’en définir un rôle, pour l’assigner aux utilisateurs qui ont accès à ces mêmes ressources.

La dernière approche est beaucoup plus empirique car elle s’intéresse d’abord à demander aux responsables d’identifier, parmi leurs subordonnés, ceux qui font le même travail. L’étape suivante consiste à vérifier que ces utilisateurs ont les mêmes privilèges et enfin, si c’est le cas, définir un rôle à assigner à ce groupe d’utilisateurs.

Le modèle RBAC

Comme son nom l’indique, le modèle RBAC est construit autour des rôles. Ou plus exactement, les rôles représentent le lien entre les utilisateurs et les ressources.

Dans certains cas, les rôles vont prendre le nom des différents métiers de l’entreprise, tels que comptable, commercial ou ressource humaine, … Dans d’autres cas, les rôles vont plutôt représenter des activités ou des projets en cours d’élaboration. Ils peuvent aussi représenter des personnes physiques comme les agents, les prestataires, les partenaires ou les clients qui, de par leur fonction au sein de l’entreprise, exercent une activité ayant vocation à leur permettre de bénéficier des applications et des ressources mises à disposition par cette même entreprise.

Il n’existe pas de définition générique d’un modèle de droit (basé sur les rôles) qu’une entreprise pourrait utiliser. Le modèle RBAC reste théorique et demande une étude approfondie sur le SI et ses utilisateurs avant de l’exploiter.

Nous voyons fréquemment plusieurs types de rôles dans les entreprises :

• Les rôles utilisateurs ou les profils, représentés par les métiers de l’entreprise par exemple

• Les rôles applicatifs qui déterminent la fonction que l’utilisateur pourra jouer sur le SI pour une application donnée (interrogation du solde, mise à jour des adresses, création de contrats, …)

• Les hiérarchies de rôles qui permettent d’organiser des rôles, définis finement, en rôles plus globaux

Par exemple, un utilisateur qui a le profil commercial et le rôle applicatif « création de contrats » a le droit de créer des contrats pour ses clients. Mais, ce commercial, dans une entreprise implantée dans plusieurs régions, n’aura pas ce droit sur un client qui n’est pas dans son secteur.

Extension du modèle RBAC

Le modèle RBAC atteint rapidement ses limites dès lors que les utilisateurs sont géographiquement différentiables, ou dès lors que l’entreprise est composée de services indépendants.

Par exemple, dans une société de services, les commerciaux sont attachés à des secteurs d’activités : un commercial chargé des affaires de l’industrie ne peut pas créer de contrat pour un client dans le secteur de la banque.

Autre exemple, un conseiller clientèle d’une banque dispose des droits de gestion de patrimoine et de gestion immobilière. Selon l’agence dans laquelle il travaille, il peut soit faire de la gestion de patrimoine soit de la gestion immobilière, soit les deux. Pour lui fournir un poste de travail adapté à ses attributions en fonction de l’agence dans laquelle il travaille, ses droits doivent être comparés aux possibilités offertes par ces agences. Ainsi, même s’il est conseiller en gestion de patrimoine et en gestion immobilière, dans une première agence il disposera d’un poste de travail restreint à la fonction de gestion immobilière – l’agent ne fera que de la gestion immobilière. Dans une autre agence il n’aura que celle de gestion de patrimoine – l’agent ne fera que de la gestion de patrimoine. Enfin, dans une troisième agence, son poste de travail lui proposera les deux fonctionnalités – l’agent pourra faire de la gestion de patrimoine ainsi que de la gestion immobilière.

Pour pallier à cette limitation, nous voyons souvent apparaître la notion de groupe en plus de celle de rôle ou de profil. C’est ce qu’on appelle le RBAC étendu.

La gestion des rôles dans une telle organisation va s’intéresser à :

• Associer des profils, voire des profils de profils, aux utilisateurs

• Associer des rôles, voire des rôles de rôles, aux applications

• Différentier les utilisateurs et les applications en fonction de critères tels que la géographie ou encore le secteur d’activité

Cette extension du modèle RBAC porte le nom de modèle RBAC étendu.

Ce modèle est suffisant pour la plus part des entreprises, mais reste encore nettement insuffisant dans des contextes de travail comme les hôpitaux.

Le modèle ORBAC

Dans un hôpital, un médecin n’est pas présent 24 heures sur 24 pour traiter chacun de ses patients. Pendant ses jours de repos, ses tâches sont assurées par un autre médecin, voire un troisième selon l’organisation en équipe mise au point dans son service. De même, l’équipe infirmière et aide-soignante qui travaille avec lui un jour n’est pas certaine de travailler avec lui le jour d’après, simplement parce qu’il n’est pas toujours possible de gérer chaque personnel médical en fonction d’un médecin, de ses jours de repos et de ses vacances.

L’organisation hospitalière implique donc que l’affectation des droits d’accès aux dossiers médicaux des patients, pour les médecins, les infirmiers et les aides-soignants soit malléable en fonction des jours, et des heures et même des services (chirurgie, urgences, pédiatrie, …).

Voici un exemple de modèle ORBAC, d’après Saidani et Nurcan, qui représente les contraintes contextuelles d’attribution des droits :

Dans ce schéma, l’auteur représente des contraintes externes qui permettent d’étendre le modèle RBAC pour limiter les droits des utilisateurs.

Conclusion

Le modèle RBAC, dans sa forme la plus simple ou la plus complexe, est devenu le modèle de gestion des habilitations le plus employé. Il permet, quand il est compris et maitrisé, d’augmenter la performance opérationnelle d’attribution des droits aux utilisateurs et apporte ainsi une réduction conséquente de coût sur la gestion des identités de l’entreprise.