Contrôle d’accès basés sur les rôles, les groupes d’objets et le contexte : Étude de cas dans les Systèmes d’information et de Communication en Santé Anas ABOU EL KALAM LAAS-CNRS, 7, Avenue du Colonel Roche - 31077 Toulouse [email protected] Yves Deswarte LAAS-CNRS, 7, Avenue du Colonel Roche - 31077 Toulouse [email protected] L'essor récent des réseaux de télécommunications a eu des conséquences significatives sur la pratique médicale : télémédecine, réduction des dépenses, amélioration de la productivité et de la qualité des soins. Par ailleurs, l’informatisation, l’augmentation de la quantité d’informations ainsi que la variété des utilisateurs accroissent le risque d’atteinte à la sûreté de fonctionnement du système d’information et de communication en santé (SICS), et plus particulièrement à la confidentialité, à l’intégrité et à la disponibilité. À cet égard, la sécurité des SICS, devenue à la fois une nécessité et une évidence, se base sur une étude cognitive et organisationnelle traitant des problèmes légaux, éthiques, sociaux, physiques, organisationnels et techniques. Le premier objectif de cet article est d’identifier les besoins en terme de sécurité des SICS, d’exposer l’état de l’art des modèles et politiques de sécurité classiques et de montrer qu’ils s’appliquent mal aux problèmes spécifiques des SICS. Nous proposons donc une extension du modèle RBAC qui répond mieux à ces besoins. Dans un deuxième temps, nous utiliserons une extension de la logique déontique pour représenter notre politique de sécurité enrichie par ces nouveaux concepts. Dans la dernière partie, nous présenterons une spécification de notre politique. Notre point de départ consiste à tirer profit des sources juridiques et techniques représentatives de la sécurité des SICS. Le recensement des législations nationale et européenne conduit à souligner des exigences fortes de sécurité. Pour assurer ces objectifs, des solutions ont été proposées, telles que l’anonymisation réversible lors de l’exploitation de l’information médicale pour l’évaluation, l’épidémiologie et la recherche, l’anonymisation irréversible des données médico-économique, le déploiement d’une nouvelle forme de certificats électroniques, l’utilisation des pare-feux et des mécanismes de détection d’intrusions, etc. Néanmoins, il faut tout d’abord, définir une politique de contrôle d’accès. Cette politique doit exposer l’ensemble des règles qui régissent la façon dont l’information sensible est gérée, protégée et distribuée dans le système. Le modèle associé doit couvrir la richesse des besoins à la fois en confidentialité, intégrité et disponibilité mais aussi de responsabilité et d’interopérabilité des SICS et contribuer à contrer les menaces (accidentelles ou malveillantes) comme il doit pouvoir prendre en compte toute amélioration ou changement dans la politique de sécurité (extensible et modulable). Le langage de spécification doit être à la fois simple et expressif. L’analyse des politiques et modèles existants nous permet de conclure que l’état de l’art actuel est insuffisant. En effet, le contrôle d’accès discrétionnaire (DAC) présente de graves inconvénients vis-à-vis des fuites d’information et des chevaux de Troie. Les politiques obligatoires sont très rigides, leur mise en œuvre impose des contraintes fortes, de plus, elles sont trop centralisées et mal adaptées aux 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 a fortiori la disponibilité. Le contrôle d’accès basé sur les rôles (RBAC) attribue les droits aux utilisateurs en fonction du rôle qu’ils jouent. Les privilèges ne sont plus associés, d'une façon directe aux utilisateurs, mais à travers des rôles. RBAC fournit un bon compromis entre MAC et DAC : il renforce la sécurité des MAC et maintient la flexibilité des DAC. Toutefois, l’application du RBAC aux SICSS est confrontée à plusieurs problèmes et ne couvre pas tous les besoins. Un des problèmes de RBAC est que les utilisateurs ayant le même rôle obtiennent les mêmes privilèges, alors que, dans le domaine de santé, les privilèges doivent être attribués, non seulement selon le rôle du professionnel de santé (PS), mais aussi selon la relation de soin existant entre le PS et le patient, l’implication du PS dans le processus de soins ainsi que d’autres informations contextuelles comme le lieu, le temps, l’urgence, etc. En plus des rôles, mettant en relation des sujets et des privilèges, nous proposons la notion de groupes d’objets, qui met en relation les objets à protéger et les opérations sur ces objets. C’est un terme qui englobe un ensemble d’objets passifs sur lesquels on effectue les mêmes opérations. Les groupes sont associés à une unité, à un projet ou à un processus de soins. Nous pouvons considérer les fichiers des patients ainsi que les ressources d’une unité de soins comme deux groupes d’objets associés à cette unité. Les groupes peuvent être reliés par une relation d’héritage (ressource de l’unité de soins cardiologie est une ressource d’une unité de soins) ou de composition (ressource de l’unité de soins est composée de salles, dossiers, ...). Ces relations favorisent la propagation des valeurs d’attributs des sous-classes vers les super-classes, et les opérations sur l’agrégat vers les composants. Les notions de rôles et de groupes d’objets ont un impact sur des concepts communément utilisés et qui interviennent dans le contrôle d’accès : L’hôpital et l’unité de soins : le système de santé est un ensemble de domaines qui interagissent entre eux : hôpitaux, instituts de recherche, organismes payeurs. L’hôpital est une structure associant plusieurs types d'unités : unités de soins, services administratifs, médico-techniques et logistiques. L'unité de soins, principal site d'accueil des patients, est une unité de lieu où est élaborée une stratégie thérapeutique, mise en œuvre par des équipes soignantes, en consommant des ressources internes et externes et susceptibles de fournir des prestations à d'autres unités. Chacune des unités possède des fonctions et des ressources distinctes et est dotée d'une certaine autonomie. Il est donc essentiel de construire les groupes d’objets associés aux unités (avec les relations d’héritage et de composition) et de définir les droits d’accès, d’abord pour l’équipe de l’unité, puis pour les autres utilisateurs qui coopèrent avec l’unité. Notion de processus de soins : c’est une activité enregistrée dans le serveur et associant la communication entre les unités de soins et les autres secteurs qui interagissent pour accomplir la fonction de soin. Par exemple, dans le cadre du processus de soins « p », le médecin X (sujet1 de l’unitéi) réalise une scanographie (objet1) sur le patient (objet2) et partage/envoie le résultat aux médecins Y de l’unité « j ». Types de dossiers médicaux : chaque acteur n’est concerné que par certaines informations/types du dossier. Les échanges effectués dans le cadre d’un processus de soins concernent le dossier partageable ; ceux faits dans les unités de soins concerne le dossier de spécialité ; les travaux du programme de médicalisation des systèmes d’informations (PMSI) et des instituts de recherche traitent des données anonymisées figurant dans les résumés standardisés de sortie (RSS), etc. Nous nous basons également sur un raffinement de la notion de contexte. Nous distinguons : Contexte du rôle : le temps d’accès (médecin de salle est valide pendant les heures de travail, médecin de nuit est valide la nuit) ; l’exclusion mutuelle statique (un utilisateur ne peut jamais jouer les deux rôles) ou dynamique (interdiction de jouer les deux rôles simultanément). Contexte du groupe d’objets : lieu, temps de conservation des données, règles de priorité, …. Contexte utilisateur : qualifications, agrégation par une certaine autorité, affiliation à un corps de santé, capacité à pratiquer des soins spécifiques ou à utiliser certains types d’appareils, autorisation à travailler pour une autorité ou pour une société d’assurance, etc. Contexte de l’utilisation : il faut réaliser un compromis entre le respect du moindre privilège et les facilités d’accès, de façon à favoriser l’intérêt des patients et de couvrir tous les cas. Par exemple, nous pouvons ajouter une règle qui autorise un médecin qui a déjà traité (dans le passé) un patient de ré-accéder à son dossier, à condition qu’il spécifie comme objectif de cette utilisation « révision du diagnostic ». L’objectif spécifié sera enregistré dans le fichier d’audit afin de détecter les abus de pouvoir et de trancher dans le cas de conflits. Dans le but de faciliter la tâche de spécification et de représenter la hiérarchie des rôles et l’agrégation des groupes, nous avons également utilisé une extension du langage déontique. Elle considère le langage L(Π) désigné par l’ensemble des formules construit par les règles : f := A | ¬f | f ∨ f | f ∧ f | f → f | f ↔ f | Of | Pf | Ff ; « A » un élément de Π, et Π un ensemble d’ensembles, ordonné par la relation d’ordre partiel ⊆ d’inclusion. Le produit cardinal, utilisé pour construire les éléments de Π, est E × R = { (e,r) e∈ E , r∈ R } . Dans la dernière partie de cet article, nous expliquerons cette extension et nous spécifierons les règles de fonctionnement, les règles de sécurité ainsi que les objectifs de sécurité de notre système. Par exemple : la règle suivante signifie que si un agent possède un certificat délivré par une autorité de santé ou s’il est authentifié par sa carte de professionnel de santé (CPS), il joue le rôle PS. (Posséder×Agent×Certificat_ de_ Santé) ∨ (Se_ Loguer×Agent×CPS) → Agent×PS ; Le triplet : (U 0 1 , Médecin_de_Nuit, US4), est une instance de la relation Utilisateur × Rôle × Unité _ de_ Soin qui signifie que { l’utilisateur ayant l’identifiant « U01 » et jouant le rôle « médecin de nuit » au seins de l’unité de soins d’urgence « US4 »}.