Résumé de thèse ()

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
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]

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 ffffff ff fOPF fff :||||| |||=¬ ∨ ∧→ ↔
; « 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
ER er eErR×=
()
∈∈
{}
,,
. 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 : (U01, 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 »}.