Or-BAC (pour Organization-Based Access Control) est un modèle de sécurité qui prend en compte la richesse et les particularités des SICSS. Il peut également être appliqué à une gamme très large d’applications complexes, interopérables et distribuées.
Une première représentation d’Or-BAC avec un modèle entité-relation - à laquelle nous avons contribué dans le cadre du projet MP6 - peut être trouvée dans [Abou El Kalam et al.
2003a ; Abou El Kalam et al. 2003b]. Dans ce mémoire, nous proposons une description plus détaillée en utilisant UML. Le modèle UML permet de surmonter le manque d’expressivité du modèle entité-relation, notamment : la récursivité, les différents types de relations (dépendance, agrégation, héritage), le comportement dynamique, etc.
Dans la section précédente, nous avons présenté les classes associations RdO, VdO et AdO.
Selon le besoin et les niveaux d’abstraction, ces concepts peuvent servir à : - structurer les sujets, les objets et les actions par des entités abstraites ;
- identifier les rôles, vues et activités présents dans chacune des organisations du système ; - spécifier qu’un utilisateur peut jouer différents rôles dans différentes organisations, mais
pas forcément les mêmes rôles dans chacune de ces organisations ; montrer qu’une même vue peut correspondre à des objets différents selon les organisations ; montrer qu’une même activité peut être implémentée différemment dans des organisations différentes ; etc.
- masquer la manière selon laquelle les organisations implémentent les activités, instancient les vues ou utilisent les rôles.
Par ailleurs, Or-BAC considère des permissions, des interdictions, des obligations et des recommandations, et tient compte du contexte dans lequel une requête est faite. La notion de
“contexte dans organisation”, notée CdO peut être définie de la même manière que les RdO, VdO et AdO.
Dans le modèle Or-BAC, une politique définit des règles du type : dans le CdO c, l’organisation org accorde au RdO r la permission (ou l’interdiction ou l’obligation ou la recommandation) de réaliser l’AdO a sur la VdO v. Nous relions ainsi les entités
“organisation, RdO, VdO, AdO et CdO” avec une classe-association notée “type d’accès” et
qui correspond à une permission, obligation, interdiction ou recommandation (figure 4.10).
Bien évidemment, cette manière de faire inclut le cas particulier où la règle ne concerne qu’une seule organisation ; dans ce cas, le CdO peut préciser que les organisations (du RdO, VdO, et AdO) sont identiques.
Figure 4.10 : Ébauche du diagramme de classe représentant les règles de sécurité.
D’une manière générale, une politique de sécurité comporte des faits du type : Permission(Purpan, Médecin-Dans-Rangueil, Lecture-Dans-Purpan, DossierMédical-Dans-Purpan, Catastrophe-Dans-Purpan) et Permission(DossierMédical-Dans-Purpan, Médecin, Lecture, Dossier-médical, Médecin-traitant). La première règle implique deux organisations différentes et signifie que
“l’hôpital Purpan accorde aux médecins de l’hôpital de Rangueil la permission de consulter n’importe lequel de leurs dossiers médicaux dans le contexte catastrophe (figure 4.11). La deuxième règle est plus restrictive et exprime que “l’hôpital Purpan accorde aux médecins la permission de consulter les dossiers médicaux des patients dont ils sont les médecins traitants”.
Figure 4.11 : Ébauche du diagramme d’objet représentant une règle de permission.
En outre, la politique de sécurité doit spécifier les conditions qui permettent de constater tel ou tel contexte dans telle ou telle organisation (CdO). Au moment de la requête, et avant d’accorder ou rejeter l’accès, le système doit vérifier (ou calculer) le contexte courant en fonction des relations qui existent entre le sujet demandant l’accès, l’objet invoqué, l’action demandée, et l’organisation impliquée.
Il est important de souligner que, dans Or-BAC, les règles de sécurité ne sont pas spécifiées pour chaque objet, sujet et action, mais seulement en utilisant des entités abstraites : organisations, rôles, vues, activités et contextes. Pour autant, le contrôle d’accès de bas niveau doit permettre de décrire les actions concrètes que réalisent les sujets sur les objets.
Nous distinguons ainsi deux niveaux d’abstraction (figure 4.12) :
- niveau abstrait, portant uniquement des entités abstraites (organisation, rôle, vue, activité, contexte) ; la politique de sécurité y est exprimée à travers la classe association type d’accès (permission, obligation, interdiction ou recommandation);
- niveau concret, portant sur des autorisations (ou obligations ou interdictions ou recommandations) concrètes associées, dans le contexte courant, à un utilisateur ui, un
RdO
VdO
Organisation CdO
AdO Type_Accès
Booléen : Permission Booléen : Interdiction Booléen : Obligation Booléen : Recommandation
MédecinDansRangueil :RdO
LectureDansPurpan :AdO Purpan:Organisation
DossMedDansPurpan :VdO CatastropheeDansPurpan
:CdO
Type_Accès Permission = vrai
objet oj et une action ak. Ces faits (permission, obligation, interdiction ou recommandation) sont déduits, à un moment donné, par instanciation des règles de la politique de sécurité.
Figure 4.12 : Les deux niveaux d’abstraction du modèle Or-BAC.
En regroupant les ébauches de diagrammes de classe présentées précédemment, on obtient le diagramme de classe correspondant à Or-BAC (figure 4.13). Celui-ci s’explique ainsi :
Les éléments du système sont partitionnés en deux catégories : les éléments acteurs (auxquels la politique de sécurité attribue des droits) ou sujets et les entités passives ou objets, sur lesquels des actions sont effectuées. L’ensemble des objets contient des éléments qui ne peuvent jamais être des sujets (machines dossiers, etc.). Ces objets sont notés “O\S”. De même, puisque les sujets peuvent eux-mêmes être manipulés, ils forment une partition de l’ensemble des objets, ils sont ainsi notés : Objets qui Peuvent être Actifs “OPA”. En particulier, les patients sont considérés comme des objets (lorsque l’infirmière leur fait une injection par exemple) qui peuvent être actifs en consultant leurs dossiers médicaux.
Par ailleurs, le modèle présenté considère une structure récursive sur les objets, les sujets, les activités et les organisations. Par exemple, les équipes sont aussi des sujets qui peuvent jouer des rôles et avoir des droits. L’ébauche du diagramme de classe de la figure 4.14-a montre d’une part que les utilisateurs, comme les équipes, sont des sujets (relation d’héritage) et d’autre part que les équipes sont composées de sujets, c’est-à-dire d’utilisateurs et d’autres équipes (relation de composition). La figure 6.14-b donne la vision ensembliste correspondante. Cette manière de faire assure la flexibilité et la récursivité, dans la mesure où il est possible de former des équipes, qui à leur tour peuvent être regroupées pour former des équipes plus grandes et ainsi de suite.
Niveau concret «!entités du monde réel!»
Niveau abstrait «!politique de sécurité!»
VdO
Organisation CdO
AdO Interdiction Obligation Recommandation Permission RdO
Pierre
:Sujet
F31.doc
:Objet
Lire
:Action
Purpan:
Organisation
<<instance de>> joue Correspond_à Appartient_à
Urgence
:Contexte
<<instance de>>
Figure 4.13 : Représentation UML du modèle Or-BAC.
Figures 4.14 (a et b) : Exemple de récursivité.
Les RAV (Rôle, Activité, Vue) ainsi que les autorisations peuvent êtres modélisés par des classes-associations. Tout processus est composé d’un ensemble ordonné de RAV. Il est identifié par un patient et un problème (la relation de dépendance exprime que toute modification du problème ou du patient entraîne un changement dans le processus). Une exception (ou objectif d’utilisation) est reliée à deux types de contrôles : un contrôle a priori et à un contrôle a posteriori. Un contexte est relié à des contraintes sur les rôles, les vues ou les organisations. Les autorisations sont attribuées à des RAV en tenant compte du contexte. Ce sont donc des classes-associations qui relient RAV et contexte et qui ont comme attribut soit une permission, soit une obligation, soit une recommandation, soit une interdiction.
Notons que le méta-modèle Or-BAC que nous avons présenté peut être appliqué, non seulement aux SICSS, mais aussi à une large gamme d’organisations et de systèmes.
Utilisateur
Chapitre 5. Choix d’un formalisme pour Or-BAC
Préambule
Dans le chapitre précédent, nous avons présenté les concepts de base du modèle Or-BAC et nous avons proposé une représentation UML d’Or-BAC. Cette représentation offre des outils graphiques qui doivent guider le processus de spécification et de mise en œuvre de la politique de sécurité du système étudié (ce processus sera détaillé dans le chapitre 6).
Néanmoins, la simplicité de la représentation UML cache une réelle complexité de modélisation. À l’inverse, une représentation formelle doit fournir une spécification plus précise et non-ambiguë, comme elle devrait permettre une analyse plus rigoureuse notamment de la complexité, de l’adéquation entre le service attendu et la description opérationnelle, etc.
À cet égard, l’outil MagicDraw permet de traduire une spécification UML en langage formel Maude [Clavel et al. 2002]. Celui-ci offre des méthodes et des outils pour la vérification, le model checking, le calcul de complexité, etc.
L’objet de ce chapitre est de présenter un autre formalisme logique capable de modéliser les règles de fonctionnement, les objectifs de sécurité ainsi que les règles de sécurité. Ce formalisme permet d’étudier un autre volet de la vérification formelle, en offrant des outils d’aide au raisonnement sur les permissions, les interdictions, les obligations et les recommandations.
Aussi, ce chapitre est-il articulé en quatre parties.
Il commencera par présenter l’intérêt d’une approche formelle : consultation d’une politique de sécurité, étude de la cohérence de cette politique, vérification des propriétés attendues, etc.
Ensuite, il détaille les différents langages susceptibles de représenter une politique de sécurité fondée sur Or-BAC, en l’occurrence la logique du premier ordre, la logique modale, et notamment une de ses branches, la logique déontique. Celle-ci a l’avantage d’utiliser des permissions, des interdictions ainsi que des obligations.
Enfin, nous proposons un formalisme logique (fondé sur la logique déontique) pour Or-BAC.
Ce formalisme sera ensuite utilisé pour représenter les règles de fonctionnement, les objectifs de sécurité ainsi que les règles de sécurité des SICSS. Par ailleurs, nous présentons des idées sur les méthodes (méthode des tableaux, logique possibiliste) d’exploitation de ce formalisme, notamment pour effectuer des vérifications et pour détecter et résoudre des conflits.