celui d’un médecin qui a traité autrefois un patient et qui souhaite ré-accéder à son dossier en spécifiant comme objectif révision du diagnostic ;
- un contrôle a posteriori : pour plus de flexibilité, le système peut autoriser certains accès, avec un ensemble minimal de vérifications (contrôle a priori) ; pour renforcer la sécurité, nous proposons des contrôles supplémentaires, qui seront réalisés a posteriori, notamment à travers les fonctionnalités d’audit et éventuellement par des notifications automatiques des patients ou des médecins traitants ; l’analyse des enregistrements d’audit permet de vérifier a posteriori le bien fondé des décisions prises (par exemple, le caractère d’urgence non habituel) ; à cet égard, notre démarche spécifie ce type de contrôle à l’intérieur de la politique de sécurité, au même titre que les contrôles a priori.
Notons que certaines contraintes contextuelles décrites dans ce mémoire, notamment celles sur les rôles, peuvent être vues comme analogues aux contraintes d’intégrité dans le domaine des bases de données [Godfrey et al. 1998]. Toutefois, les contraintes d’intégrité sont des obligations qui valident les opérations après leurs exécutions (vérification en aval), alors que le contexte que nous décrivons (sauf le contexte d’utilisation) est vérifié avant d’autoriser ou non l’accès (vérification en amont).
Les concepts de base que nous venons de présenter sont des briques nécessaires et suffisantes pour construire Or-BAC. Dans la section suivante, nous montrons comment les assembler et les relier pour représenter la politique de sécurité à l’aide de ce modèle.
Chapitre 4 Le modèle Or-BAC 110
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(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>>
Chapitre 4 Le modèle Or-BAC 112
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 Equipe
0..n 1..n
0..n
Sujet 1..n
x x
x x
x x Chef de clinique Equipe i Equipe j
Le sujet : équipe d’une clinique
Tâche_Elémentaire Utilisateur
Type d’Accès Permission Interdiction Obligation Recommandation
Eléments en état passif
O\S
Contrôle a priori
Exception
Contrôle a posteriori Problème
Patient Equipe
OPA
Groupe_Objets
Notification Audit
Contraintes
Processus
Contexte
Crte-Role Crte-Vue Crte-Org Tâche_Composite
Sujet
Objet
RAV Id_RdO Id_VdO Id_AdO
{ordonné}
Rôle
Activité
Vue
Id_Org Id_Rôle
AdO Id_Org Id_Act
VdO Id_Org Id_Vue Organisation
Légende OPA : Objets pouvant être actifs (patients par exemple) O\S :l’ensemble des objets sans les sujets
RdO : Rôle dans Organisation AdO : Activité dans Organisation VdO : Vue dans Organisation RAV : classe-association entre RdO, VdO et AdO
0..n
0..n 0..n
0..n 1..n 0..n
1..n 1..n
1..n
1..n
0..n
0..n 0..n
0..n 0..n
1..n 1..n
1..n Action
Récursivité des activités Récursivité
des sujets
RdO
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.
Chapitre 4 Le modèle Or-BAC 114