Les modèles de contrôle d’accès
2.4 Le modèle RBAC
RBAC : Role-Based Access Control (contrôle d’accès basé sur les rôles) [21] est un modèle de contrôle d’accès organisé différemment des modèles DAC et MAC. Les éléments de ce modèle sont : les utilisateurs (users), les sujets (subjects), les rôles (roles), les objets (objects), lesopérations (opera-tions) et les permissions (permissions).
Un utilisateur est une personne qui interagit avec le système informa-tique. Par exemple dans les systèmes d’exploitation, un utilisateur se connecte à partir de son compte. Une instance du dialogue entre un utilisateur et le système avec lequel il interagit est appeléesession. Normalement, le rôle est la fonction que l’utilisateur occupe au sein d’une entreprise.
Un sujet est un processus qui agit dans une sessoin au nom d’un utili-sateur. Il s’agit par exemple d’un programme lancé dans une session de cet utilisateur. Un utilisateur peut donc avoir plusieurs sujets.
Un objet représente une entité passive du système, Il s’agit de fichiers, dossiers, imprimantes etc. Une opération est un processus actif invoqué par un sujet sur un objet (accéder à un fichier, modifier des données, etc).
L’autorisation d’effectuer une action dans le système est une permission.
Dans RBAC une permission combine un objet et une opération.
Les permissions dans RBAC sont accordées aux rôles. Les utilisateurs et les sujets héritent ensuite de ces permissions en fonction des rôles qu’ils jouent dans une entreprise. Dans le standard NIST (National Institute of Standards and Technology), le modèle RBAC est constitué de trois niveaux :
– Le noyau RBAC (Core RBAC) qui contient les fonctionnalités de base du modèle
– RBAC hiérarchique (Hierarchical RBAC) qui introduit une hiérarchie de rôles
– RBAC avec contraintes (Constrained RBAC) qui permet de spécifier des contraintes pour l’application des permissions.
2.4.1 Le noyau RBAC
Le noyau RBAC définit la structure de base du modèle RBAC. Les rôles sont affectés aux utilisateurs et les permissions aux rôles. La Figure 2.3 pré-sente les relations entre les éléments du modèle.U A(User Assignment) dé-signe la relation qui existe entre les utilisateurs et les rôles.P A(Permission Assignment) relie les permissions aux rôles.
Figure 2.3 – Core RBAC (extrait de [6])
2.4.2 RBAC hiérarchique
RBAC hiérarchique ajoute en plus des composantes du noyau RBAC une hiérarchie entre les rôles. C’est un moyen de représenter les niveaux de responsabilité dans une entreprise. Dans la Figure 2.4, la relationRH (Role Hierarchy) représente l’hiérarchie entre les rôles.
Figure 2.4 – RBAC hiérarchique (extrait de [6])
Si un rôler2 hérite der1 alors l’utilisateur qui joue le rôler2 aura en plus des permissions qui lui sont accordées, les permissions de r1. Par exemple si on considère que le chef du département informatique est avant tout un simple employé d’entreprise, alors il a en plus des permissions accordées aux simples employés, les permissions liées au rôlechef du département informa-tique.
2.4.3 RBAC avec contraintes
Ce modèle permet de définir des contraintes afin d’éviter d’éventuels conflits dans l’affectation des rôles. On parle deséparation de pouvoirs (SoD : Separtion of duty).
Séparation statique de pouvoirs
La séparation statique de pouvoirs (SSoD : Static Separation of Duty) permet d’éviter les conflits que peuvent engendrer l’affectation des rôles aux sujets. Il s’agit d’empêcher à un sujet de jouer des rôles en conflits. La nécés-sité de gérer les conflits est également liée à la hiérarchie qui peut exister entre
les rôles. En effet pour respecter une certainne cohérence, les contraintes de séparation doivent être établies de façon à éviter que des rôles en hiérachie soient également en conflits. Avec la SSoD si le rôle chef du département informatique est en conflit avec le rôle gestionnaire des équipements infor-matiques, il faut vérifier qu’un utilisateur n’a pas un de ces rôles, avant de lui attribuer le second.
Figure 2.5 – RBAC avec contraintes de séparation de pouvoirs (extrait de [6])
Séparation dynamique de pouvoirs
La séparation dynamique de pouvoirs (DSoD : Dynamic Separation of Duty) permet d’empêcher à un utilisateur de jouer des rôles en conflit au même moment. En effet il existe des situations où différents rôles en conflit doivent être attribués à un utilisateur. Pour résoudre ce genre de problèmes, des rôles en conflits peuvent être affectés à un utilisateur, mais dans des sessions différentes. Un même sujet peut donc jouer les rôleschef du dépar-tement d’informatique et gestionnaire des équipements informatiques dans des sessions différentes.
La Figure 2.5 présente le modèle RBAC avec contraintes. On remarque
dans cette figure que les contraintes SOD sont appliquées à la hiérarchie des rôles (RH) et à l’attribution d’un rôle à un utilisateur (UA).
2.4.4 Conclusion sur le modèle RBAC
Le modèle RBAC a été largement discuté dans la littérature. Il permet d’avoir une relation stable entre la sécurité des données, la structure d’une organisation et les tâches dans une organisation. Plusieurs exemples que nous donnerons dans notre travail seront liés à ce modèle. Nous présenterons dans le chapitre suivant une méthode de modélisation de politiques de sécurité qui se base également sur ce modèle.
2.5 Conclusion
Dans ce chapitre nous avons discuté de quelques modèles de contrôle d’ac-cès. Chacun de ces modèles permet de présenter des règles de contrôle d’accès suivant un objectif particulier. Les modèles de contrôle d’accès hybrides sont le résultat de la combinaison de modèles de contrôle d’accès comme ceux présentés dans ce chapitre. Il est donc important de fournir des méthodes pour spécifier ces modèles. On retrouve par conséquent dans la littérature, des méthodes de modélisation formelles (avec des langages logiques) et des méthodes de modélisation semi-formelles (avec des aspects graphiques). Le but de ces méthodes est de permettre des modélisations sans ambiguïtés pour les méthodes formelles et de faciliter la compréhension et l’interprétation des modèles, pour les méthodes semi-formelles. Nous présenterons donc dans le chapitre suivant quelques méthodes de modélisation semi-formelles de règles de contrôle d’accès.