2.1.3 Les modèles de contrôle
d'accès basées sur les rôles (RBAC)
Proposées en 1992 par David Ferrailo et Richard Kuhn
[8], les politiques basées sur les rôles sont adaptées pour
les organisations comportant un nombre important d'utilisateurs et d'objets.
Leur principe général est d'introduire un niveau d'indirection
entre utilisateurs et permissions. C'est le concept de rôle qui a
été intercalé entre eux afin de mieux structurer les
droits d'accès. Il représente une fonction dans le cadre d'une
organisation, c'est-à-dire qu'il décrit facilement les
activités qu'un sujet a le droit d'accomplir au sein de cette
organisation. Les sujets ayant reçus l'autorisation de jouer un
rôle, héritent alors des permissions associées à ce
rôle. Ceci dit, d'un côté nous avons des permissions qui
sont accordées aux rôles, et de l'autre côté, des
utilisateurs se voient affecter un ou plusieurs rôles. De ce fait, si un
nouvel employé est recruté dans une organisation, il suffit de
lui assigner un (des) rôle(s) pour que le système l'intègre
automatiquement dans les limites autorisées par la politique de cette
organisation. Ce modèle simplifie l'administration des systèmes,
facilite la compréhension de la structure de l'organisation et
même de la politique de sécurité, réduit la
complexité de gestion des droits d'accès et permet à ce
que les rôles soient organisés de manière à former
une hiérarchie permettant de raffiner les différentes permissions
attribuées à chaque rôle. L'un de ses problèmes
majeurs est le fait que, les utilisateurs ayant le même rôle
obtiennent les mêmes privilèges. Ce qui réduit la
flexibilité des politiques de sécurité 8. On
souhaiterait par exemple que dans certaines organisations telles qu'un
hôpital, un médecin n'ait accès qu'aux dossiers de ses
patients et ce n'est pas exprimable dans RBAC. Le modèle ORBAC
(organisation Based Access Control) a été proposé pour
faire face à cette limite. Il étend le modèle RBAC et
attribut des permissions|obligations|recommandations|interdictions
pour la
8. Pourtant un utilisateur pourrait avoir un rôle
privé.
5
réalisation d'activités dans une organisation par
un rôle dans un contexte donné. 2.1.4 Les modèles
de contrôle d'accès basées sur l'organisation
(OrBAC)
Proposé en 2003 par Abou El Kalam et al [10], le
contrôle d'accès basé sur l'organisation reprend les
principes de rôles du modèle RBAC en offrant en plus, la
possibilité de modifier la politique de sécurité en
fonction d'une circonstance concrète, c'est-à-dire qu'il exprime
facilement les permissions qui dépendent d'un contexte. En dehors des
permissions, il offre la possibilité d'exprimer des obligations, des
interdictions et même des recommandations dépendant bien
évidemment des contextes. Il est centré sur le concept
d'organisation (groupe structuré d'entités actives), et tous ses
autres concepts sont définis par rapport à l'organisation. A
partir des relations ternaires (habilite, utilise et considère), il
définit les relations qui existent entre les entités du niveau
concret (sujets, objets, et actions), du niveau abstrait (rôles, vues et
activités) et l'entité contexte ainsi qui suit [12] :
Les sujets et les rôles
Dans ce modèle, un Sujet peut être un utilisateur
ou une organisation. L'entité Rôle est utilisée
pour structurer le lien entre les sujets et les organisations. La relation
Habilite est introduite entre ces entités. Si
Org est une organisation, s un sujet et r un rôle, alors
Habilite(Org, s, r) signifie que l'organisation Org
habilite le sujet s à jouer le rôle r. D'où
l'exemple Habilite (hôpital général, Marie,
infirmière) : l'hôpital général habilite Marie
dans le rôle d'infirmière.
Les objets et les vues
L'entité Objet représente
principalement les entités non actives. L'entité vue
regroupe un ensemble d'objets qui satisfait une propriété
commune. Elle caractérise la manière dont les objets sont
utilisés dans l'organisation. La relation utilise est
introduite entre ces entités. Si Org est une
organisation, o un objet et v une vue, alors la relation Utilise(Org, o, v)
signifie que Org utilise l'objet o dans la vue v. D'où l'exemple
Utilise (service sécurité réseau, courrier
électronique, dossiers administratif) : le service
sécurité réseau utilise courrier électronique comme
un dossier administratif.
Les actions et les activités
L'entité Action englobe principalement les
actions informatiques comme "lire", "écrire", "envoyer", etc.
L'entité Activité correspond à des actions qui
ont un objectif commun (exemple : consulter, modifier, transmettre, etc.). En
effet, l'objectif ici c'est de pouvoir caractériser des organisations
qui structurent différemment les mêmes activités. Si nous
considérons par exemple l'activité "consultation", elle peut
correspondre à l'action "lire" un fichier dans l'organisation
hôpital général, mais peut tout aussi bien
correspondre à l'action "select" sur une base de données dans
l'hôpital central. La relation Considère est
introduite entre ces entités. Si Org est une
organisation, a une action et A une activité, la relation
Considère(Org, a, A) signifie que Org
considère l'action a comme faisant partie de l'activité
A. D'où l'exemple Considère (hôpital
général, lire, consultation) : l'hôpital
général considère l'action "lire" comme une
consultation.
Les contextes
Le contexte spécifie les circonstances concrètes
dans lesquelles les organisations accordent des permissions (ou interdictions)
à des rôles pour réaliser des activités sur des
vues. Elle a été introduite par la relation
Définit. Si on veut par exemple savoir quand est ce
qu'un utilisateur ou sujet a le droit d'accéder à une
information, La relation Définit(Org, s,
a, 0, c) établit le contexte c définit par l'organisation
Org pour le sujet s, l'action a sur l'objet o. D'où l'exemple
Définit(hôpital général, Marie, lire,
carnet.doc, médecin-traitant) qui signifie que l'hôpital
général définit Marie ayant le droit de lire carnet.doc
car elle est le médecin traitant du patient auquel ce carnet
appartient.
La politique de contrôle d'accès OrBAC est
définie par les relations permission, obligation et interdiction sur
organisation Rôle Activité Vue Contexte. Ainsi,
Permission (Org, r, a, y, c) indique que dans une organisation Org, un
rôle r est autorisé à effectuer une activité a sur
une vue v dans un contexte c. Les autorisations concrètes de type
(sujet, action, objet) quant à eux sont dérivées des
relations Est_permis, Est_interdit, Est_obligatoire et
Est_recommandé. On aura par exemple Est_permis(s,
a, o) qui signifie que le sujet s a la permission de réaliser
l'action a sur l'objet o. La figure ci-dessous résume donc le
modèle de sécurité OrBAC[11].
FIGURE 1 Modèle OrBAC [12]
6
7
L'avantage de ce modèle est qu'il permet d'exprimer des
règles contextuelles qui peuvent être spécifiques à
une organisation. Il permet de spécifier au sein d'une même
organisation structurée en plusieurs sous organisations plusieurs
politiques de sécurité. Contrairement aux autres modèles
qui ne modélisent que des politiques de sécurité se
restreignant à des permissions statiques, OrBAC offre la
possibilité d'exprimer des règles relatives aux permissions,
interdictions, obligations et recommandations. Malheureusement, il ne permet
pas d'assurer qu'il n'y aura pas de conflits dans la politique de
sécurité (par exemple, pour un sujet donné, une action
donnée, et un objet donné, il nous faut détecter et
résoudre une situation dans laquelle il serait possible de
dériver à la fois une permission et une interdiction). Il ne
montre pas comment détecter une violation de la politique de
sécurité et pour finir, ne dit en rien si une politique de
sécurité est cohérente ou pas.
La volonté sous-jacente à cette abondance de
modèles de contrôle d'accès, c'est de proposer une
organisation des droits qui permet de traduire au mieux les politiques de
sécurité ou l'ensemble des règles qui régissent la
façon dont sont protégées les ressources d'un
système. Une fois que nous avons pris connaissance de ces
modèles, il faut implanter celui qui se rapproche le plus de notre
organisation car, le choix d'un modèle a une influence capitale sur les
solutions que nous pouvons obtenir. En vue de se rassurer de sa
sûreté, il faut vérifier que la politique mise en place est
cohérente.
| 
