Modèle de sécurité pour le secteur de la santé

Transcription

1 Modèle de sécurité pour le secteur de la santé Anas Abou El Kalam Yves Deswarte LAAS-CNRS, 7 avenue du Colonel Roche Toulouse Cedex 4 France { anas.abouelkalam, yves.deswarte}@laas.fr RESUME : Cet article propose un modèle de sécurité suffisamment général pour couvrir toute la diversité des systèmes d information et de communication de la santé (SICS). L un des objectifs de ce modèle est de favoriser l interopérabilité de ces systèmes tout en étant suffisamment souple pour prendre en compte toute amélioration ou changement dans la politique de sécurité. Ce modèle réalise un bon compromis entre le respect du principe du moindre privilège et la flexibilité du contrôle d accès, de façon à ne pas gêner le travail du personnel soignant, tout en préservant les droits des patients, et ce, conformément aux législations nationale et européenne. Pour faciliter l administration de la politique de sécurité, c est-à-dire de gérer la complexité de la gestion des droits d'accès, le modèle utilise des notions de rôle et de groupe. Il définit également, avec précision, les différents types de contextes qui peuvent exister dans les systèmes interopérables et répartis que sont les SICS. Ce modèle décrit la politique de sécurité dans un langage de spécification à la fois simple et expressif, basé sur la logique déontique. ABSTRACT: This paper proposes a security model which is generic enough to cover all the diversity of Health Care Computing and Communication Systems (HCCS). One of the aims of this model is to facilitate the HCCS interoperability, with a sufficient flexibility to take into account any improvement or change in the security policy. This model achieves a good compromise between the respect of the least privilege principle and the flexibility of the access control, in order to facilitate the healthcare professional work, while preserving patient interests, according to national and European legislation. To make security policy management easier and cope with access right complexity, the model is based on two concepts: roles and groups of objects. It also defines precisely the various types of contexts that can exist in really distributed and cooperative systems such as HCCS. This model describes the HCCS security policy in an expressive and simple specification language, which is based on deontic logic. MOTS-CLES : modèle de sécurité, politique de sécurité, RBAC, TMAC, système d informations médicales, logique déontique, UML. KEYWORDS: Security model, security policy, RBAC, TMAC, Health Care Computing and Communication Systems, déontic logic, UML. Technique et science informatiques. Volume 23 - n 3/2004, pages.. à..

2 2 Technique et science informatiques. Vol. 23 n 3/2004 Introduction Les Systèmes d Informations et de Communication en Santé (SICS) permettent de stocker et de gérer des informations médicales, administratives ou sociales relatives à des personnes. Ils exploitent les technologies de l informatique pour permettre aux utilisateurs un accès rapide à ces informations, et ainsi faciliter les actes médicaux, les remboursements, etc. Toutefois, les menaces qui guettent de tels systèmes peuvent engendrer une réticence de la part des patients et des usagers. En effet, l exploitation abusive par un utilisateur malhonnête d un SICS insuffisamment protégé peut rendre possible la divulgation de données personnelles à différents intéressés : employeurs, concurrents, etc. Les erreurs de saisie ou de conception peuvent entraîner des erreurs de diagnostic ou de soins. Les défaillances peuvent empêcher le personnel soignant d accéder à des informations indispensables. Pour atteindre un niveau de protection satisfaisant, il faut définir une politique de sécurité correspondant aux besoins. C est une étape primordiale qui consiste à élaborer un ensemble de règles en fonction d une analyse des risques. Ceci afin de minimiser le risque de dommages indésirables ou de pallier leurs effets. Ainsi, protégera-t-on les informations et les ressources identifiées comme sensibles. Une politique de sécurité se développe selon trois axes : physique, administratif et logique. Le premier précise l environnement physique du système à protéger (les éléments critiques, les mesures prises vis-à-vis du vol et des catastrophes) ; le deuxième décrit les procédures organisationnelles (répartition des tâches, séparation des pouvoirs) ; la troisième décrit les contrôles d accès logiques (qui, quoi, quand, pourquoi, comment) et s intéresse aux fonctions d identification, d authentification et d autorisation mises en œuvre par le système informatique. Les politiques et modèles de sécurité existants étant incapables de couvrir toutes les spécificités des SICS, cet article propose de nouveaux concepts et présente un modèle assurant une meilleure sécurité, sans pour autant altérer les facilités d accès, pour éviter de porter atteinte aux droits des patients ou de gêner le travail des professionnels de santé. L article se recoupe en six sections : la première analyse les besoins de sécurité des SICS ; la deuxième discute les modèles classiques de contrôle d accès ; la troisième explique la politique proposée ; la quatrième spécifie cette politique dans un modèle UML ; la cinquième décrit un langage formel capable de représenter cette politique et la sixième exprime, dans ce nouveau langage, des exemples de règles d accès, de règles de fonctionnement et de propriétés de sécurité des SICS. 1. Analyse des besoins 1.1. Démarche et définitions Un SICS relie des organisations multiples et des utilisateurs ayant des profils différents (professionnels de santé, patients, organismes sociaux), met en jeu des

3 Modèle de sécurité pour le secteur de la santé 3 technologies complexes (communication, traitement, télémédecine, paiement, archivage), manipule des informations sensibles et hétérogènes (médicales, paramédicales, médico-administratives et médico-financières), etc. Indispensable pour gérer la dynamique et maîtriser les dépenses, le système informatique ne doit pas engendrer de dégradation de la sécurité. Au contraire, il doit empêcher l exécution de toute opération non autorisée et protéger les informations sensibles. Les ITSEC [1] définissent la politique de sécurité comme étant l ensemble des lois, règles et pratiques qui régissent la façon dont l information sensible et les autres ressources sont gérées, protégées et distribuées à l intérieur d un système spécifique. Une politique de sécurité s occupe de spécifier simultanément les propriétés désirées et d établir un cadre réglementaire permettant de modifier l état de sécurité du système. Les propriétés de sécurité peuvent être définies comme suit : - confidentialité : non-occurrence de divulgation non autorisée de l information, - intégrité : non-occurrence d altération inappropriée (accidentelle ou frauduleuse) de l information, - disponibilité : garantie de l accès aux informations et aux fonctionnalités du système quand on en a besoin. La méthode présentée ici met en avant la réalisation d un bon compromis entre le respect du principe du moindre privilège et la flexibilité du contrôle d accès. La première étape consiste à s appuyer sur les différentes lois et réglementations pour décrire le système : que veut-on protéger? quelles sont les vulnérabilités du système? quelles menaces doit-on affronter? quels risques encourt-on? quels sont les besoins de sécurité? Les politiques existantes sont ensuite confrontées aux menaces et aux besoins déjà relevés. Le modèle proposé a l originalité de tenir compte du contexte et d être suffisamment souple pour prendre en compte toute amélioration ou mise à jour. Cette politique est représentée par des diagrammes UML, mais aussi dans un langage formel. Diverses indications sur la manière dont cette politique de sécurité peut être mise en œuvre seront également proposées Informations sensibles Les obligations éthiques imposent une protection particulière des données nominatives. On entend par donnée nominative toute donnée décrivant une personne identifiable. Malheureusement, il est souvent possible d identifier un individu par un simple rapprochement de données médicales ou sociales. Par exemple, l âge, le sexe et le mois de sortie du patient d un hôpital, permettent de l isoler dans une population. Les données non nominatives sont également sensibles dans la mesure où leur altération peut induire en erreurs de traitement des données personnelles, des erreurs de diagnostic, de calculs de remboursement, etc. De nombreuses organisations nationales et internationales s intéressent de plus en plus à ce problème complexe aux dimensions légales, éthiques, sociales, organisationnelles et techniques. Par exemple, l'assemblée générale des Nations

4 4 Technique et science informatiques. Vol. 23 n 3/2004 Unies a adopté des directives pour la réglementation des fichiers informatisés contenant des données personnelles [2]. Le Conseil de l Europe a établi des recommandations concernant les banques de données médicales automatisées [3] et les échanges des données de santé [4]. La Commission Européenne a développé la directive [5] relative à la protection des données personnelles et à la libre circulation de ces données. En France, la récente loi du 4 mars 2002 [6] définit les droits des malades et décrit la qualité du système de santé. Le décret [7] restreint les accès aux informations personnelles détenues par les professionnels de santé. Une fois identifiés les types d informations et de ressources à protéger dans les SICS, la section suivante détaille quelques risques spécifiques à ce domaine Risques identifiés L analyse des risques permet la mise en œuvre d une politique de sécurité en identifiant les vulnérabilités résiduelles et en évaluant leurs impacts sur la sécurité du système. Revenons tout d abord sur quelques définitions [8] : - Une attaque est une action malveillante qui tente d exploiter une faiblesse dans le système et de violer un ou plusieurs besoins de sécurité. - Une intrusion est une faute opérationnelle résultant de l exploitation d une vulnérabilité dans le système. - Une menace est une violation potentielle d une propriété de sécurité. - Une vulnérabilité est une faute accidentelle ou intentionnelle (avec ou sans volonté de nuire), introduite dans la spécification, la conception, la configuration ou dans l opération du système. Les couples (menace, vulnérabilité) permettent d identifier les risques auxquels peuvent être soumis les SICS. Par exemple : l attribution des données d un patient à un autre, l utilisation non autorisée des données et des programmes (introduction de virus, destruction illégitime de données), les erreurs de saisie, etc. À cet égard, les directives européennes [5] spécifient que le fournisseur d un service web doit prendre les mesures techniques et organisationnelles (politique de sécurité, par exemple) pour garantir la sécurité de ses services. La résolution [2] met en garde contre les pertes accidentelles d informations, les accès non autorisés et les utilisations illégitimes. La commission d audit britannique et le bureau d évaluation de la technologie du gouvernement américain ont confirmé que le domaine de la santé est l une des cibles les plus attaquées par des utilisateurs malveillants aussi bien internes qu externes (atteinte à la vie privée, fraudes) [9, 10]. En France, le décret [7] identifie des menaces relatives aux accès illégitimes et aux pertes de données. Le code de déontologie médicale [11] et le code de santé publique [12] sensibilisent les professionnels de santé aux risques liés au secret professionnel. Des statistiques [13] ont montré que, dans plus de 30 % des cas, les fichiers médicaux sont indisponibles, et même quand ils sont disponibles, les délais nécessaires pour extraire les informations sont souvent décourageants.

5 Modèle de sécurité pour le secteur de la santé 5 Les intrusions dans les SICS revêtent une importance primordiale. En effet, si les propriétés de sécurité sont violées : - le médecin risque de prendre des décisions portant préjudice aux patients, - la valeur de l information comme base de diagnostic est amoindrie, - un professionnel de santé appelé à justifier ses actions, pourrait être dans l incapacité d utiliser les dossiers informatiques comme preuve Besoins de sécurité Les risques identifiés dans la section précédente justifient directement un besoin de confidentialité, d intégrité et de disponibilité. La confidentialité est à la fois liée au respect du secret professionnel des organismes de santé et à la vie privée des patients. En effet, il n y a pas de traitement médical sans confiance, de confiance sans confidence et de confidence sans secret. Un médecin, par exemple, ne devrait diffuser que des données anonymes lorsqu il utilise son expérience à des fins de publication scientifique. L intégrité peut être mise en cause par des manipulations erronées mais également par la perte de données, accidentelle ou délictueuse. Elle touche également à la validité des données saisies, en particulier, à l éviction des collisions 1 et des doublons 2 lors de la génération de pseudonymes. La disponibilité concerne à la fois le caractère d urgence et la pérennité des données. Les ressources critiques (y compris les données et les services) doivent êtres disponibles aux utilisateurs autorisés, après un temps d attente raisonnable, par exemple pour le médecin en cas d urgence ou dans le cadre de la télémédecine. Par ailleurs, le règlement des archives hospitalières impose des délais de conservation très longs : 70 ans pour les dossiers de pédiatrie, de neurologie, de stomatologie et de maladies chroniques, durée illimitée lorsqu il s agit de maladies héréditaires. De nombreuses propriétés de sécurité peuvent être définies en termes de confidentialité, d intégrité et de disponibilité de l information ou du service luimême, ou encore de méta-informations comme l instant de la réalisation d une action ou l identité de la personne qui a réalisé une tâche [8]. L auditabilité correspond ainsi à la disponibilité et à l intégrité de méta-informations relatives à l existence d une action, à l identité de la personne qui l a réalisée, à l instant de l action. L authenticité d un message est équivalente à l intégrité du contenu du message et de son origine. La non-répudiation correspond à la disponibilité et à l intégrité de l identité de l émetteur, l instant de l émission/réception, etc. 1. Il y a collision lorsqu à partir de données nominatives différentes, on génère un même pseudonyme (qui risque ainsi d être alloué à deux personnes différentes). 2. Il y a doublon lorsque deux pseudonymes différents sont générés pour une même personne.

6 6 Technique et science informatiques. Vol. 23 n 3/ Modèles et politiques classiques de sécurité Deux grandes catégories de politiques de sécurité existent dans la littérature : les politiques discrétionnaires et les politiques obligatoires. Afin de permettre de mieux s adapter à des organisations particulières, d autres politiques ont été définies, en particulier, les politiques basées sur la notion de rôles (Role-Based Access control, ou RBAC) ou celles basées sur la notion d équipes (Team-Based Access control, ou TMAC) Politiques de sécurité discrétionnaires Une politique est dite discrétionnaire si l entité qui possède un objet peut propager et manipuler librement les droits sur cet objet. La gestion des accès aux fichiers du système d exploitation UNIX en est un exemple. Le modèle de Lampson [14], modèle discrétionnaire de base, est structuré en une machine à états où chaque état est un triplet (S,O,M) : S désigne un ensemble de sujets (entités actives), O un ensemble d objets (entités passives) et M une matrice de contrôle d accès. Chaque cellule M(s,o) de cette matrice contient les droits d accès que le sujet s possède sur l objet o. Ce modèle a connu une longue évolution et a été progressivement amélioré pour donner naissance à d autres modèles tels que HRU [15] et Take-Grant [16]. Cette classe de politique de sécurité présente des inconvénients, dont les risques de fuite d informations et d attaque par chevaux de Troie Politiques de sécurité obligatoires Pour résoudre les problèmes des politique discrétionnaires, les politiques obligatoires décrètent des règles incontournables. Ainsi, les politiques multiniveaux affectent-elles aux objets et aux sujets des attributs non modifiables par les usagers, et donc qui limitent leur pouvoir de gérer les accès aux informations qu ils possèdent - en interdisant par exemple à tout sujet de lire une information de classification supérieure - Les politiques dites de Bell et LaPadula [17], visant à assurer la confidentialité, et de Biba [18], s intéressant à l intégrité, en sont les exemples les plus anciens. D autres exemples, moins formalisés, ont été développés pour les systèmes commerciaux [19] et pour les institutions financières [20]. Les politiques obligatoires, très spécifiques aux domaines pour lesquels elles ont été développées, sont très rigides. Leur mise en œuvre impose des contraintes fortes aux organisations et au personnel ayant accès au système d information. De plus, elles sont trop centralisées et mal adaptées à une analyse et une prise de décision en réseau ou au travers de systèmes réellement répartis. Par ailleurs, ces politiques ne permettent pas de prendre facilement en compte à la fois la confidentialité et l intégrité, et à fortiori la disponibilité.

7 2.3. Les contrôles d accès basé sur les rôles Modèle de sécurité pour le secteur de la santé 7 Dans le modèle de contrôle d accès basé sur les rôles (RBAC pour «Role-Based Access Control») [21, 22], les privilèges ne sont plus associés, d'une façon directe aux utilisateurs mais à travers des rôles. Le modèle RBAC peut être raffiné en incluant les concepts de hiérarchie de rôles et de séparation de pouvoirs. Il améliore ainsi les politiques classiques en permettant une administration plus facile et en réduisant les coûts de gestion des droits. Néanmoins, dans RBAC, tous les utilisateurs ayant le même rôle ont les mêmes privilèges. Par conséquent, il n est pas possible de spécifier qu un médecin n a le droit d accéder au dossier médical d un patient que s il traite ce dernier. RBAC doit donc être complété pour assurer un contrôle d accès adapté aux SICS Politique de sécurité par équipes Les politiques basées sur la notion d équipes (TMAC pour «Team-Based Access Control») ont été introduites d une manière générique dans [23]. Le but était de fournir un contrôle d accès pour les systèmes d information ayant des activités nécessitant la collaboration de plusieurs personnes. L entité de base, l équipe, est une abstraction qui encapsule un ensemble d utilisateurs ayant des rôles différents et qui collaborent dans le but d accomplir une tâche commune. C-TMAC [24] est une adaptation de TMAC aux domaines dépendant du contexte tels que celui de la santé. La déduction des privilèges se fait selon les deux règles suivantes : privilège-rôle = Combinaison [privilège-rôle-session, privilège-équipe] privilège-contexte = Filtrage [privilège-rôle, contexte-équipe] Privilège-rôle est une combinaison (union, maximum ou minimum) des privilèges associés au rôle de l utilisateur avec les privilèges de l équipe à laquelle il appartient. Si la combinaison est l union, privilège-rôle correspond à l ensemble des privilèges de tous les membres de l équipe. Si la combinaison est le maximum (respectivement le minimum), privilège-rôle correspond au privilège du membre de l équipe le plus privilégié (respectivement le moins privilégié). Privilège-contexte, l ensemble des privilèges finaux, réduit privilège-rôle en tenant compte du contexte des équipes de l utilisateur. Ce mécanisme présente certaines faiblesses. À titre indicatif, si la combinaison est une union, un utilisateur qui rejoint une équipe renforce les privilèges de cette équipe en lui ajoutant les siens. Ainsi, tous les membres de l équipe auront-ils les mêmes privilèges. Néanmoins, les privilèges finaux du médecin doivent être différents de ceux de l infirmière, même si tous les deux appartiennent à la même équipe de soins. De même, une combinaison correspondant au maximum ou au minimum des privilèges n aurait guère sens dans ce type d application.

8 8 Technique et science informatiques. Vol. 23 n 3/ Politique et modèle proposées L analyse du besoin présenté dans la première section permet de conclure que la décision d accès doit tenir compte du rôle, de la relation de soin existant entre le patient et le professionnel de santé, de son implication dans le processus de soins ainsi que d autres informations contextuelles comme le lieu et le temps [25, 26]. La discussion des politiques actuellement en vigueur permet de conclure qu elles ne couvrent pas toute la richesse des SICS. À cet égard, cet article introduit de nouveaux concepts, justifie leur utilité et montre les relations qui les associent Notion de fonction Le contrôle d accès basé sur les équipes, C-TMAC, considère deux relations binaires (utilisateur, rôle) et (utilisateur, équipe). Un utilisateur peut donc activer n importe lequel de ses rôles dans n importe laquelle de ses équipes. Dans la pratique, même si un utilisateur a le droit de jouer plusieurs rôles, il n a pas forcément le droit de les jouer dans toutes les équipes auxquelles il appartient. La politique présentée dans cet article, traite ce problème en ajoutant la notion de fonction. Une fonction désigne «un rôle joué dans une équipe». Le modèle correspondant considère ainsi une relation ternaire (utilisateur, rôle, équipe). Rôle Equipe 1 1 Correspond à Fait partie de Utilisateur remplit 0..* 0..* 0..* 1..* Fonction Médecin: Rôle Betty: Utilisateur MédecinDansC5: Fonction C5: Team InfirmièreDansC5 : fonction Figure 1-a. diagramme de classe UML représentant la composition des équipes en fonctions Figure 1-b. diagramme d objet UML représentant les instances de fonctions L ébauche du diagramme de classe de la figure 1-a montre qu une équipe est composée de fonctions ; une fonction correspond à un et un seul rôle tandis qu un même rôle peut figurer dans plusieurs fonctions ; les utilisateurs ne sont pas liés aux rôles directement, mais à travers des fonctions. Le diagramme UML de la figure 1-b donne l exemple de l équipe C 5 constituée des deux fonctions : médecin dans C 5 et infirmière dans C 5. La fonction médecin dans C 5 doit être remplie par un utilisateur (dans la figure, Betty) jouant le rôle médecin. Une fonction sert donc à décrire comment une organisation (une équipe, par exemple) peut être constituée.

9 Modèle de sécurité pour le secteur de la santé Concept de groupe d objets La politique présentée distingue les entités physiques utilisées au niveau du contrôle d accès et les entités abstraites utilisées au niveau des règles de sécurité. De même que la fonction est une entité abstraite qui représente les utilisateurs pouvant réaliser les mêmes tâches dans une certaine organisation, le concept de groupe d objets regroupe les objets 3 qui satisfont une propriété commune. Celle-ci peut être, par exemple, l appartenance à une même organisation. L utilité de cette notion est de pouvoir construire des regroupements logiques, selon des critères liés aux droits d accès, de façon à distinguer les objets sur lesquels différents groupes de sujets effectuent les mêmes actions. À titre illustratif, citons l exemple des données administratives des patients hospitalisés à l hôpital de Rangueil, les dossiers des patients traités par l équipe 4 i, etc. L exemple de la figure 2 représente l objet composite ressources de l unité chirurgicale C 5. La première ligne exprime la hiérarchie : ressources de C 5 hérite de la classe ressources d une unité chirurgicale, qui elle-même, hérite de la classe ressource clinique. Le reste de la figure exprime la relation de composition : l objet composite ressources C 5 est composé des groupes d objets : salles de chirurgies de C 5 (contenant deux salles), dossiers de spécialité de C 5 (les n dossiers des patients traités par C 5 ) et postes de C 5 (les 10 ordinateurs de cette unité). Ressource Unité Chirurgie C 5 : Ressource Unité Chirurgie :: Ressource Clinique Salle_Chirurgie : Salle 2 Poste de travail : Ordinateur 10 Dossier_Spécialité : Dossier_Clinique_Patient n Figure 2. Exemple de composition de groupes d objets en UML Outre sa nature intuitive extraite du fonctionnement normal des organisations, la notion de groupe d objets facilite la structuration et établit un lien entre les sujets et les objets qu ils manipulent (fichiers des patients, par exemple), au moyen d actions. Il est normal de centrer le raisonnement du contrôle d accès autour des objets sur lesquels les utilisateurs réalisent des actions (en tenant compte des rôles), plutôt que l inverse. La notion de groupes d objets offre plusieurs avantages : - elle aide à réduire les erreurs d administration. En effet, les entités de structuration (rôles, classes et groupes d objets), ainsi que les associations 3. Le terme «objet» est utilisé ici dans le sens traditionnel des modèles de sécurité, c est-àdire comme conteneur d information. Ceci n est pas incompatible avec l aspect «orientéobjet» de l approche UML décrite dans la suite. 4 En En SQL, les éléments du groupe d objets dossiers des patients traités par l équipe i sont la réponse à la requête : SELECT EquipeTraitante NumDossier FROM Dossier WHERE Dossier. EquipeTraitante=i.

10 10 Technique et science informatiques. Vol. 23 n 3/2004 {Privilège, action} et {action, groupe} restent relativement fixes dans le système d information ; elles sont donc gérées par l administrateur. En revanche, certaines associations {objets, groupe} (exemple : Marie, patiente à l unité C 5 ), changent souvent ; elle peuvent ainsi être gérées localement (l affectation des patients aux unités se fait par le personnel d accueil de l hôpital). - Elle aide à réduire les coûts d administration. D une part, les relations d héritage (composition et hiérarchie) favorisent la propagation des valeurs d attributs des sous-classes vers les super-classes, et les actions sur l agrégat vers les composants. D autre part, le coût des associations {action, objet} (sans passer par le groupe) est de l ordre de N A *N O, tel que N A est le nombre d actions et N O est le nombre d objets (figure 3-a). Alors qu avant la notion de groupe, le coût est N A +N O (figure 3-b), et ceci pour chaque groupe. Action 1 Objet 1 Action 1 Objet 1 Action 2 Objet 2 Action 2 Groupe Objet 2 Action NA Objet NO Action NA Objet NO Figure 3-a. association {action, objet} Figure 3-b. { Action,Groupe,Objet } Ferber et Gutknecht ont développé dans [27] un méta-modèle (AALAADIN) basé sur les Agent-Role-Groupe pour l analyse et la conception des organisations dans les systèmes multi-agents. Dans leur approche, un groupe peut être interprété comme un ensemble d agents (entités pouvant jouer des rôles) qui interagissent dans un processus (autrement dit, une agrégation d agents). Dans ce sens, un utilisateur qui remplit une fonction peut être vu comme un agent qui joue un rôle dans un groupe. Il y a donc une similarité entre certains concepts d AALAADIN et ceux du modèle présenté. Toutefois, des différences peuvent être soulignées, par exemple : - dans AALAADIN, la notion de groupe d objets (ensemble d objets passifs qui satisfont des critères liés aux droits d accès) n apparaît pas clairement, - dans AALAADIN, un agent peut jouer différents rôles dans différents groupes, il peut également être membre de plusieurs groupes au même moment. En revanche, notre modèle permet d ajouter des contraintes liées au contexte comme l exclusion mutuelle. Les différents les types des contextes des SICS sont présentés dans la section suivante Contexte Le contexte peut être défini comme toute information qui caractérise la situation d une entité du système. En l occurrence : qui peut déléguer ou désigner? quand l utilisateur a-t-il le droit d accéder à une information? d où l accès est-il possible? comment, où et pour quelles raisons, les informations sont-elles disponibles? Le

11 Modèle de sécurité pour le secteur de la santé 11 contexte est ainsi, l une des notions utilisées par la politique présentée pour mieux respecter le principe du moindre privilège Contexte de rôle, utilisateur, objet Le contexte du rôle précise les valeurs que doivent prendre certaines variables pour autoriser l utilisateur à jouer le rôle. Il est parfois possible d associer des contraintes aux rôles, par exemple : la cardinalité, pour désigner le nombre maximal d utilisateurs autorisés à jouer le rôle ; l exclusion mutuelle statique, pour spécifier qu un utilisateur ne peut jamais jouer deux rôles (dans le même établissement, être personnel soignant et comptable) ; l exclusion mutuelle dynamique pour obliger l utilisateur à ne pas jouer deux rôles simultanément (médecin à l hôpital et médecin travaillant pour une société d assurance), etc. De telles contraintes contextuelles peuvent être vues comme analogues aux contraintes d intégrité dans le domaine des bases de données [28]. 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 décrit dans cet article (sauf le contexte d utilisation) est vérifié avant d autoriser ou non l accès (vérification en amont). D autres attributs des utilisateurs (outre les rôles) sont parfois nécessaires à l exécution de certaines actions. Citons à titre d exemple les droits temporaires (l affiliation à un corps de santé régional ou national), les autorisations spécifiques ou l expérience dans la pratique de certains types de soins. Les objets (ou les groupes d objets) ont des attributs contextuels spécifiques tels que la durée de conservation des données (par exemple, 70 ans pour les données de neurologie) ou le lieu (les dossiers de spécialité de chacune des unités sont situés et gérés localement sur les ordinateurs de cette unité) Contexte de l utilisation Les entités abstraites de la politique proposée peuvent être divisées en deux niveaux logiques : un premier niveau contenant les rôles et les groupes d objets, et un deuxième niveau schématisant les coalitions. Les équipes en font partie. En réalité, les équipes tout comme les organisations, collaborent dans des processus spécifiques. Le contexte d utilisation est un concept innovant qui regroupe la notion de processus pour gérer les accès normaux, et la notion d objectif d utilisation pour supporter les exceptions, avec plus de responsabilité. Le but est de réaliser un bon compromis entre le respect du principe du moindre privilège et la flexibilité du 5. Le principe du moindre privilège impose que tout utilisateur ne doit pouvoir accéder à un instant donné qu aux informations et services strictement nécessaires pour l accomplissement du travail qui lui a été confié.