These Anas
These Anas
These Anas
THÈSE
Présentée au
Laboratoire d’Analyse et d’Architecture des Systèmes
du Centre National de la Recherche Scientifique
en vue d’obtenir le titre de
Par
Anas Abou El Kalam
LAAS - CNRS
7, avenue du Colonel Roche
31077 Toulouse Cedex 4
Avant-Propos
Les travaux présentés dans ce mémoire ont été effectués au sein du Laboratoire d’Analyse et
d’Architecture des Systèmes du Centre National de la Recherche Scientifique (LAAS - CNRS).
Je tiens à remercier tout d’abord Jean-Claude Laprie, ainsi que Malik Ghalab directeurs
successifs du LAAS-CNRS pendant mon séjour, de m’avoir permis de mener mes recherches
dans ce laboratoire.
Ma reconnaissance se tourne particulièrement vers David Powell, ancien responsable du
groupe Tolérance aux fautes et Sûreté de fonctionnement (TSF) et son successeur Jean Arlat,
pour m’avoir accueilli dans ce groupe de recherche.
Mes plus grands remerciements sont naturellement pour Yves Deswarte, qui m’a encadré tout
au long de ma thèse. Ma considération est inestimable. Ses remarques et critiques pertinentes
m’ont conduit vers la bonne voie. Son soutien m’a permis de ne jamais faiblir et de poursuivre
toujours plus loin mes travaux. Je tiens également à souligner que la confiance qu’il a mise en
moi a été un moteur à ma réussite.
J’exprime ma gratitude à Yves Dutuit, Professeur à l’Université de Bordeaux I, pour
l’honneur qu’il me fait en présidant mon Jury de Thèse, ainsi qu’à :
- Abdelmalek Benzekri, Professeur à l’Université Paul Sabatier ;
- Frédéric Cuppens, Professeur à l’Ecole Nationale Supérieure de Télécommunications
(ENST-Bretagne) ;
- Marc Dacier, Professeur à l’Institut Eurecom Sophia Antipolis, Professeur adjoint à
l’Université de Liège et professeur visiteur à l’Université catholique de Louvain ;
- Yves Deswarte, Directeur de Recherche CNRS ;
- Gilles Trouessin, Directreur de mission Sénior à Ernst & Young Audit ;
pour l’honneur qu’ils me font en participant à mon jury. Je remercie particulièrement
Abdelmalek Benzekri et Marc Dacier qui ont accepté la charge d’être rapporteur.
Je voudrais également remercier l’ensemble des partenaires du projet MP6 avec qui j’ai
beaucoup appris, notamment Gilles Trouessin (responsable du projet MP6) Philippe Balbiani,
Frédéric Cuppens, Claire Saurel, Salem Benferhat, Alexandre Miège, Rania El-Baida et Didier
Vinsonneau. Sans eux, ces travaux n’auraient probablement pas été les mêmes.
Je remercie tout le groupe TSF, les permanents, les doctorants et les stagiaires.
Mes remerciements s’adressent également à l’ensemble des services du LAAS, qui
permettent à chacun de travailler dans les meilleures conditions.
Il m’est agréable de remercier chaleureusement tous ceux qui, en dehors du laboratoire,
m’ont accompagné et soutenu. Je pense particulièrement à Betty qui m’a beaucoup aidé et qui a
partagé avec moi des moments faciles et difficiles durant ces trois années.
Ces avant-propos seraient incomplets sans un remerciement adressé aux membres de ma
famille, en particulier mes parents et mon frère Sidi Mohamed. Ce travail leur appartient à tous.
Je pense également à Haj Alouane, Haj Belkahia, Florian, mes tantes Aziza, Hagiba, Souad,
mes amis Badri, Rachid, Redouane, Noredine, Moustapha ainsi que tous les autres gens
aimables et serviables qui m’ont soutenu et qui ont contribué à mon enrichissement personnel.
Alors que l’informatisation s’impose dans des domaines complexes, coopératifs et largement
distribués comme la télémédecine et les télédéclarations sociales, il est de plus en plus
nécessaire d’avoir confiance dans les traitements et la distribution des données et services
informatiques.
Les Systèmes d’Information et de Communication en Santé et social (SICSS) permettent de
stocker et de gérer des informations médicales, administratives ou sociales relatives à des
personnes ou des entreprises. 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, les télédéclarations sociales, les télépaiements, etc. Toutefois, les menaces
qui pèsent sur de tels systèmes peuvent provoquer la réticence des usagers (patients pour la
sphère médicale, entreprises pour la sphère sociale). En effet, l’exploitation abusive par un
utilisateur malhonnête d’un SICSS insuffisamment protégé peut rendre possible la divulgation
de données personnelles à différents intéressés : employeurs, concurrents, banques, etc. Les
erreurs de saisie ou de conception peuvent entraîner des erreurs de diagnostic, de soins ou de
paiements. Les défaillances peuvent empêcher le personnel soignant d’accéder à des
informations indispensables. Enfin, la peur d’un manque de confidentialité, d’intégrité, de
disponibilité ou d’auditabilité de tels systèmes peut inciter des patients et des entreprises à
refuser de divulguer des informations pourtant vitales.
Pour atteindre un niveau de protection satisfaisant, il convient de définir une politique de
sécurité correspondant aux besoins. En effet, toute démarche de sécurité rigoureuse doit être
inscrite dans une politique claire et documentée. Sa conception est donc une étape primordiale,
qui consiste à identifier les objectifs de sécurité et à élaborer un ensemble de règles en fonction
d’une analyse des risques. Ceci permet de minimiser le risque de dommages indésirables ou de
pallier leurs effets et conduit à protéger 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). Le troisième a trait aux
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. Dans ce mémoire, nous nous intéressons particulièrement aux politiques
d’autorisation (dites aussi politiques de contrôle d’accès).
Les premiers travaux sur l’expression et la mise en œuvre de politiques d’autorisation ont
débuté, il y a plus de vingt ans, principalement dans le domaine de la défense. Pour des raisons
juridiques (responsabilité), éthiques (respect de la vie privée), déontologiques (secret médical,
par exemple), organisationnelles (situations d’urgence, cas particuliers ou non attendus) et
techniques (interconnexion de réseaux locaux, régionaux et nationaux), ce type de politiques de
sécurité est clairement inadapté au monde de la santé ou du social. La conception de politiques
2 Introduction générale
d’autorisation beaucoup plus dynamiques - et pouvant s’adapter aux contextes des activités
médicales ou sociales - est nécessaire. Les modèles et politiques de sécurité, fondés sur le
concept de rôle, sont une première étape pour mieux répondre à de tels besoins sectoriels, mais
ils ne satisfont pas à toutes les spécificités des SICSS. Des modèles et politiques plus récents,
reposant sur les notions d’équipes et de contextes, semblent également intéressants, mais
nécessitent des approfondissements théoriques et des études complémentaires.
Ainsi, les politiques et modèles de sécurité actuels étant incapables de couvrir toute la
richesse des SICSS, il semble nécessaire de proposer de nouveaux concepts et de présenter un
modèle pouvant assurer une meilleure sécurité, sans pour autant gêner le travail des usagers ou
porter atteinte aux droits des patients.
La réflexion s’articule autour de six moments :
Le premier chapitre montre la pertinence d’une étude de sécurité dans la sphère santé-social,
présente la terminologie utilisée, et situe les politiques de sécurité dans l’éventail des stratégies
et outils pour renforcer la sécurité d’un système ou d’une organisation.
Le deuxième chapitre étudie les politiques et modèles de sécurité existants, et montre les
limites de leur application aux SICSS. Elle présente également des projets récents dans ce
domaine et introduit le projet MP6, Modèles et Politiques de Sécurité pour les Systèmes
d’Information et de Communication en Santé et Social, projet dans lequel ont été effectués nos
travaux.
Le troisième chapitre montre comment bâtir une politique de sécurité pour un système ou une
organisation. Cette méthodologie est appliquée en posant les principales briques d’une
politique de sécurité pour les sphères sociale et médicale. À ce niveau de l’étude, les SICSS
seront décrits en détail à travers des règles de fonctionnement, des objectifs de sécurité ainsi
que des règles de sécurité. De par son importance dans les SICSS, le problème
d’anonymisation est enfin abordé en détail. Une étude préalable est nécessaire avant toute
procédure d’anonymisation. Cette étude doit identifier les besoins, les objectifs ainsi que les
exigences en terme d’anonymisation. S’en suivra une présentation des principaux travaux dans
ce domaine, une description d’un ensemble de scénarios récapitulatifs, et des propositions de
solutions mieux adaptées aux besoins actuels et futurs. Les politiques de sécurité décrites
pourraient ainsi être appliquées aussi bien aux données anonymisées qu’aux autres
informations sensibles, ressources et services des SICSS.
Le quatrième chapitre rappelle les concepts de base de notre politique de sécurité. Celle-ci
tient compte du contexte et réalise un bon compromis entre la flexibilité et l’efficacité du
contrôle d’accès. Par ailleurs, une représentation UML (Unified Modeling Language) du
nouveau méta-modèle Or-BAC “Organization-Based Access Control” sera ensuite proposée.
Centré sur l’organisation, Or-BAC offre l’expressivité et la flexibilité nécessaires à la
représentation de politiques de sécurité pour une large gamme d’organisations et de systèmes,
notamment les SICSS.
Le cinquième chapitre présente une vision logique qui servira à formaliser et à raisonner sur
une politique de sécurité fondée sur Or-BAC. À cet égard, un langage approprié (fondé sur la
logique déontique) sera d’abord proposé, et 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. Des idées
sur l’exploitation de ce formalisme - notamment pour la vérification de la cohérence d’une
politique de sécurité ou pour la résolution de conflits - seront également proposées.
Le sixième chapitre commence par présenter une démarche UML pour bâtir une politique de
sécurité associée à Or-BAC. Cette démarche tient compte des aspects conceptuels, statiques et
dynamiques d’une politique de sécurité. Enfin, il s’agira de décrire une concrétisation de nos
idées à travers une implémentation d’un logiciel de contrôle d’accès pour un centre dentaire.
Chapitre 1. Sécurité des systèmes d’information et de
communication en santé et social
Préambule
Ce chapitre repose sur deux motivations. D’une part, fournir la base terminologique
nécessaire à la compréhension de nos travaux, et d’autre part, situer nos centres d’intérêts dans
le vaste domaine de la sécurité.
Aussi, ce chapitre est-il articulé en cinq parties.
C’est par la description de notre champ d’application - les systèmes d’information et de
communication en santé et social (SICSS) - que l’étude débutera. Les SICSS couvrent
l’ensemble des besoins généralement trouvés dans les autres domaines.
Les concepts de la sûreté de fonctionnement, et plus particulièrement ceux de la sécurité
informatique, seront ensuite présentés. Le but est de fournir un support terminologique dans la
définition des politiques de sécurité pour les SICSS, puis dans l’élaboration de modèles
formels de ces politiques.
Suit une brève introduction à la sécurité des systèmes d’information et, à l’instar des ITSEC
[ITSEC 1991], critères européens d’évaluation de la sécurité des systèmes d’information, elle
décrit la sécurité comme l’association de la confidentialité, de l’intégrité et de la disponibilité
vis-à-vis des actions autorisées.
Les ambiguïtés sont ensuite levées sur les notions d’intrusions, d’attaques, de vulnérabilités
et de risques, et des exemples spécifiques aux SICSS seront donnés.
La dernière partie du chapitre détaille les techniques de sécurité les plus utilisées pour faire
face aux intrusions, et pour renforcer la sécurité d’un système ou d’une organisation. Il s’agira
de décrire des mesures comme les politiques de sécurité, les mécanismes de chiffrement, la
détection d’intrusion, etc. Ces mécanismes, aussi robustes soient-ils, ne peuvent sécuriser
efficacement et rigoureusement un système que s’ils s’intègrent dans une démarche globale
fondée sur une politique de sécurité.
4 Chapitre 1 Sécurité des SICSS
1
Net-entreprises est le service proposé en France aux entreprises par l’ensemble des organismes de
protection sociale pour leur permettre d’effectuer, par Internet, leurs déclarations et leurs paiements.
2
Nous considérons une information comme nominative si elle contribue à la description d’individus (ou
entreprises) bien identifiés ou identifiables.
3
Le numéro de SIREN est un numéro attribué par l’INSEE à toute personne physique ou morale qui
exerce une activité professionnelle lors de l’inscription au répertoire national des entreprises.
5
(surtout dans les échéances de déclarations et de paiements), ainsi que la responsabilité des
actions (paiement à échéance par exemple), sont autant de points cruciaux.
Malheureusement, des conflits potentiels peuvent apparaître entre toutes ces exigences de
sécurité des SICSS. En effet, un objectif de confidentialité sur les dossiers médicaux conduit à
définir une règle limitant l’accès au dossier médical d’un patient à son seul médecin traitant.
Pourtant, un objectif de disponibilité peut amener à définir comme règle qu’en cas d’urgence,
n’importe quel médecin puisse y avoir accès. Dans d’autres cas, un professionnel de santé peut
avoir besoin de certaines données indirectement nominatives (par exemple, l’âge,
l’appartenance sociale, ou la région géographique) pour réaliser une étude épidémiologique.
Une telle exigence, liée à la disponibilité, peut entrer en conflit avec des exigences de
confidentialité (par exemple, risque d’inférence non autorisée si ces données indirectement
nominatives sont divulguées).
1.1.4. Menaces pesant sur les informations manipulées par ces systèmes
Les menaces auxquelles les SICSS sont confrontés peuvent causer différents préjudices,
notamment en portant atteinte à la confidentialité des informations concernant les patients et
les organisations, à l’intégrité des données et des programmes, à la disponibilité des services et
des données nécessaires au bon fonctionnement. Plusieurs études et statistiques récentes
montrent l’ampleur de ces menaces. Des enquêtes menées par la commission d’audit
britannique [Audit 1998] et par le bureau d’évaluation de la technologie du gouvernement
américain ont confirmé que le domaine de la santé est l’une des cibles privilégiées d’attaquants
aussi bien internes qu’externes (atteinte à la vie privée, fraudes, etc.) [Woodward 1995]. Plus
récemment, en 2001, un pirate a pu s’emparer du serveur de fichiers d’un hôpital à Seattle (aux
États-Unis) et diffuser sur le Web (securityfocus.com) les fichiers médicaux de cinq mille
patients. Des études plus anciennes [Tufo 1971] révèlent que, dans plus de 30 % des cas, les
fichiers médicaux sont indisponibles, et que même quand ils sont disponibles, les délais
nécessaires pour extraire les informations sont souvent décourageants. Les 26, 27 octobre et le
4 novembre 1992, suite à une surcharge du système informatique, le service des ambulances de
Londres a été bloqué ; causant la mort de vingt personnes. L’enquête a révélé que la transition
vers le système de sauvegarde n’avait pas été correctement préparée.
À cet égard, les vulnérabilités des SICSS peuvent être de natures diverses : fautes de
conception ou de spécification, comme les portes dérobées permettant des infiltrations
malveillantes extérieures (voir 1.4) ; politiques de sécurité ne tenant pas compte de toutes les
manipulations illégitimes ; faiblesses dans le système socio-technique, dues par exemple à une
procédure d’habilitation trop laxiste des personnels ; protection physique insuffisante du
matériel et des ressources ; etc.
En outre, les attaques peuvent aussi bien provenir de l’intérieur (abus de pouvoir, curiosité
allant au-delà de l’utilisation des informations et services strictement nécessaires pour
l’accomplissement du travail) que de l’extérieur (pirate informatique qui tente de lire ou de
modifier une information ou d’usurper l’identité d’un professionnel de santé par exemple).
Une intrusion (attaque au moins particulièrement réussie) peut donner lieu à :
- des divulgations de données personnelles intimes, ou professionnelles secrètes (violation
de la confidentialité) ;
- des erreurs de diagnostic, d’actes médicaux, de télédéclarations, ou de télépaiements
(violation de l’intégrité et de la disponibilité) ;
- l’indisponibilité d’informations cruciales pour les médecins (respectivement les
organismes de protection sociale) qui peuvent en avoir besoin pour leurs patients
(respectivement entreprises) ou pour justifier leurs décisions, si nécessaire (violation de la
disponibilité et de l’auditabilité).
7
Enfin, le manque de confiance peut conduire chaque partenaire d’un SICSS à installer sa
propre politique de sécurité, au détriment d’une interopérabilité pourtant indispensable à
l’échange d’informations entre les usagers des SICSS. Par ailleurs, la peur d’un manque de
confidentialité, d’intégrité, de disponibilité ou d’auditabilité de tels systèmes peut inciter des
patients (ou, dans le domaine social, les entreprises) à refuser de divulguer des informations
pourtant capitales.
[Abou El Kalam et al. 2002c] identifie une liste plus exhaustive de risques spécifiques aux
SICSS, mais aussi à des risques plus généraux, liés à l’utilisation de l’informatique et de la
télématique. Par ailleurs, une caractérisation plus détaillée des besoins des SICSS peut être
trouvée dans [Abou el Kalam & Deswarte 2003a].
DISPONIBILITÉ
FIABILITÉ
SÉCURITÉ - INNOCUITÉ
ATTRIBUTS
CONFIDENTIALITÉ
INTÉGRITÉ
MAINTENABILITÉ
PRÉVENTION DE FAUTES
TOLÉRANCE AUX FAUTES
SÛRETÉ DE MOYENS
FONCTIONNEMENT ÉLIMINATION DES FAUTES
PRÉVISION DES FAUTES
FAUTES
ENTRAVES ERREURS
DÉFAILLANCES
FAUTES ACCIDENTELLES
FAUTES INTENTIONNELLES
NATURE
SANS VOLONTÉ DE NUIRE
FAUTES INTERNES
FRONTIÈRES DU SYSTÈME
FAUTES EXTERNES
FAUTES PERMANENTES
PERSISTANCE
FAUTES TEMPORAIRES
Les fautes d’interaction intentionnelles sans volonté de nuire peuvent résulter de l’action d’un
opérateur soit destinée à faire face à une situation imprévue, soit violant délibérément des
procédures sans avoir réalisé les conséquences malheureuses de son action. Généralement, ces
fautes ne sont identifiées qu’après qu’elles aient causé une défaillance.
Les logiques malignes recouvrent aussi bien des fautes de développement comme les
chevaux de Troie, les portes dérobées, les bombes logiques, ou des fautes opérationnelles
comme les virus et les vers. Ces fautes peuvent être définies comme suit :
- une bombe logique est une partie de programme qui reste dormante dans le système hôte
jusqu’à ce qu’un instant ou un événement survienne, ou que certaines conditions soient
réunies, pour déclencher des effets dévastateurs en son sein ;
- un cheval de Troie est un programme effectuant une fonction illicite tout en donnant
l’apparence d’effectuer une fonction légitime ; la fonction illicite peut être de divulguer ou
d’altérer des informations, ou peut être une bombe logique ;
- une porte dérobée est un moyen de contourner les mécanismes de contrôle d’accès ; il
s’agit d’une faille du système de sécurité due à une faute de conception accidentelle ou
intentionnelle (cheval de Troie en particulier) ;
- un virus est un segment de programme qui, lorsqu’il s’exécute, se reproduit en
s’adjoignant à un autre programme (du système ou d’application), et qui devient ainsi un
cheval de Troie ; un virus peut être porteur d’une bombe logique ;
- un ver est un programme autonome qui se reproduit et se propage à l’insu des utilisateurs ;
un ver peut également être porteur d’une bombe logique.
Les intrusions ne peuvent être couronnées de succès sans l’existence de fautes de conception.
Le caractère externe des intrusions n’exclut pas qu’elles soient tentées par des opérateurs ou
administrateurs du système qui abusent de leur pouvoir. Les intrusions sont détaillées dans 1.4.
1.3.2. Confidentialité
La confidentialité est la propriété d’une information de ne pas être révélée à des utilisateurs
non autorisés à la connaître. Ceci signifie que le système informatique doit :
- empêcher les utilisateurs de lire une information confidentielle (sauf s’ils y sont autorisés),
et
- empêcher les utilisateurs autorisés à lire une information et de la divulguer à d’autres
utilisateurs (sauf autorisation).
Le terme information doit être pris au sens le plus large : il recouvre non seulement les
données elles-mêmes, mais aussi les flux d’information et la connaissance de l’existence des
données ou des communications. Assurer la confidentialité d’un système est donc une tâche
complexe. Il faut analyser tous les chemins qu’une information particulière peut prendre dans
le système pour s’assurer qu’ils sont sécurisés. Il importe également de prendre en compte les
connaissances qu’un ou plusieurs utilisateurs peuvent déduire à partir des informations qu’ils
4
Ce qui est “méta-information” à un niveau d’abstraction donné (par exemple, une application) peut
être une “information” réelle à un niveau plus bas (par exemple, le système d’exploitation).
11
acquièrent. Il faut donc contrôler non seulement les informations présentes dans le système,
mais aussi les liens logiques qui peuvent les relier entre elles ou à des informations publiques.
Les attaques contre la confidentialité consistent à essayer d’obtenir des informations qui
doivent être protégées selon la politique de sécurité, en dépit des moyens de protection et des
règles de sécurité. Par exemple, les écoutes passives consistent à accéder aux données
transmises sur un canal de communication (câble de réseau, par exemple) ou stockée sur un
support vulnérable (disques externes, par exemple). Une telle écoute peut, dans certaines
circonstances, permettre d’accéder à des informations sensibles, comme le mot de passe d’un
utilisateur tapé sur un terminal connecté à un ordinateur central, et qui transite en clair entre ce
terminal et la machine. On voit également que cette attaque peut être particulièrement difficile
à identifier a posteriori étant donné l’absence totale de traces laissées dans le système.
1.3.3. Intégrité
L’intégrité est la propriété d’une information de ne pas être altérée. Cela signifie que le
système informatique doit :
- empêcher une modification5 indue de l’information, c’est-à-dire une modification par des
utilisateurs non autorisés ou une modification incorrecte par des utilisateurs autorisés, et
- faire en sorte qu’aucun utilisateur ne puisse empêcher la modification légitime de
l’information. Par exemple, empêcher la mise à jour périodique d’un compteur de temps
constituerait une atteinte à l’intégrité.
De plus, il faut avoir l’assurance que toute modification de donnée est approuvée et que
chaque programme se comporte de manière correcte (c’est-à-dire conformément aux fonctions
qu’il est censé remplir, y compris dans ses interactions avec les autres processus). Il faut
également s’assurer qu’aucune information ne peut être modifiée par des intermédiaires, que
cette altération soit intentionnelle (par exemple, un utilisateur intervient pour modifier une
communication entre deux autres utilisateurs) ou accidentelle (une donnée modifiée lorsqu’elle
est communiquée via un support de communication non-fiable).
Afin de se prémunir contre les fautes affectant l’intégrité des données, il importe d’intégrer
dans le système des mécanismes permettant d’une part de détecter les modifications des
informations, et d’autre part de contrôler les accès à ces dernières (en gérant les droits d’accès
des programmes et utilisateurs). De plus, un travail de validation en amont peut également être
réalisé pour prévenir les fautes accidentelles.
1.3.4. Disponibilité
La disponibilité est la propriété d’une information d’être accessible lorsqu’un utilisateur
autorisé en a besoin. Cela signifie que le système informatique doit :
- fournir l’accès à l’information pour que les utilisateurs autorisés puissent la lire ou la
modifier, et
- faire en sorte qu’aucun utilisateur ne puisse empêcher les utilisateurs autorisés d’accéder à
l’information.
Ainsi définie, la disponibilité est une notion qui regroupe plusieurs concepts.
La disponibilité à court terme exige que les données (médicales, par exemple) et services
(comme ceux offerts par Net-entreprises) sont des ressources critiques qui peuvent, à un
moment donné, être invoquées par plusieurs utilisateurs, et pour différentes raisons
5
Le terme de modification doit être entendu au sens large, comprenant à la fois la création d’une
nouvelle information, la mise à jour d’une information existante, et la destruction d’une information.
12 Chapitre 1 Sécurité des SICSS
réalise (ou ne réalise pas) une opération. L’analyse du trafic est une attaque contre la
confidentialité de méta-informations de communication, en vue d’obtenir connaissance de
l’existence d’un canal, l’existence d’un message, des identités, des emplacements ou adresses
de l’émetteur et du récepteur d’un message, de la durée de la communication, etc.
L’authenticité est la propriété d’être “vrai”. Pour un message, l’authenticité est équivalente à
l’intégrité à la fois du contenu du message (intégrité des informations) et de son origine (méta-
information), ainsi qu’éventuellement d’autres méta-informations telles que l’instant
d’émission ou le niveau de classification (intégrité des méta-informations). De la même
manière, un document est authentique si son contenu n’a pas été altéré (intégrité des
informations) et optionnellement si l’auteur déclaré est vraiment l’auteur et non un plagiaire, si
la date de publication est correcte (intégrité des méta-informations), etc. De la même manière,
un utilisateur prétendu est authentique si l’identité déclarée est bien la bonne identité de cette
personne. L’authentification est le processus qui donne confiance dans l’authenticité.
L’auditabilité et les propriétés qui en découlent (imputabilité, irréfutabilité, etc.) [Trouessin
2000] correspond à la disponibilité et à l’intégrité d’un ensemble de méta-informations
relatives à l’existence d’une opération, à l’identité de la personne qui a réalisé l’opération, à
l’instant de l’opération, etc.
La propriété de non-répudiation garantit qu’un sujet ayant réalisé une action dans le système
ne puisse nier l’avoir réalisée. La non-répudiation correspond donc à la disponibilité et
l’intégrité de méta-informations telles que l’identité de l’émetteur (et éventuellement l’instant
d’émission) d’un message pour la non-répudiation d’origine, ou telles que la réception et
l’identité du récepteur d’un message pour la non-répudiation de réception.
Vulnérabilité
En définissant une menace comme une violation potentielle d’une propriété de sécurité, les
couples (menace, vulnérabilité) permettent d’identifier les risques auxquels le système étudié
peut être soumis. Une attaque contre la sécurité du système peut provenir de l’intérieur ou de
l’extérieur. Un intrus interne peut être défini comme étant un utilisateur malveillant
appartenant à l’organisation, tandis qu’un intrus externe est une personne n’ayant pas de
privilèges. Il est donc un individu non enregistré comme utilisateur, mais qui tente de pénétrer
le système en trompant ou en contournant les mécanismes d’authentification et d’autorisation.
Voici des exemples d’intrusions, interprétées en termes de vulnérabilités et attaques :
- un intrus externe qui pénètre dans le système en devinant un mot de passe ; la vulnérabilité
se trouve dans la configuration du système, qui permet un mauvais choix de mots de passe
(trop court, vulnérable aux attaques par dictionnaire) ;
- un intrus interne qui abuse de son pouvoir ; la vulnérabilité réside dans la spécification et
la conception ou l’opération du système socio-technique (violation du principe du moindre
privilège6, procédure d’habilitation trop laxiste des personnels, etc.) ;
- un intrus externe qui utilise des moyens d’ingénierie sociale, par exemple en dupant ou
corrompant un utilisateur privilégié pour le pousser à exécuter une action malveillante
avantageuse pour son propre compte ; la vulnérabilité est la présence d’un utilisateur
privilégié corruptible ou trop peu méfiant, ce qui est aussi une faute de conception ou
d’opération du système socio-technique (procédure d’habilitation laxiste, par exemple) ;
- un intrus externe qui méne une attaque en déni de service par surcharge de requêtes
(comme les attaques massives de sites webs en février 2000). La vulnérabilité réside en
partie dans les spécifications mêmes du système puisqu’il est contradictoire d’exiger qu’un
système soit totalement ouvert à des utilisateurs bien intentionnés et fermé aux utilisateurs
malveillants. Ce type particulier d’attaque exploite aussi des fautes de conception ou de
configuration dans les nombreux hôtes connectés à Internet qui ont été piratés pour insérer
des processus zombies, nécessaires au montage d’une attaque distribuée et coordonnée.
Une troisième vulnérabilité, qui empêche de lancer des contre-mesures efficaces, repose
sur une faute de conception de la part des fournisseurs de services Internet qui
n’implémentent pas de filtrage (en entrée et sortie) qui permettrait de tracer efficacement
l’adresse source de l’attaque.
D’une manière générale, un utilisateur malveillant suit l’une des deux logiques suivantes :
soit il contourne les mécanismes qui implémentent la politique7 de sécurité ; soit il exploite les
limites et les failles de cette politique. Cette distinction a un effet direct sur les types
d’intrusions qui touchent le plus les SICSS, notamment :
- les vols de privilèges ou accroissement non autorisé de privilèges ; il s’agit d’un
changement des privilèges d’un utilisateur sans que cela soit autorisé par la politique de
sécurité : par exemple, un utilisateur qui essaye de contourner les mécanismes
d’autorisation pour lire des informations confidentielles ;
- les abus de privilèges ou utilisation abusive des opérations autorisées ; par exemple des
utilisateurs privilégiés comme les administrateurs du système, les opérateurs ou les
officiers de sécurité, peuvent abuser de leurs privilèges pour effectuer des actions
malveillantes.
Par ailleurs, il est intéressant de se pencher également sur les cas où une attaque contre la
sécurité du système peut être accidentelle. Par exemple, le statisticien qui, sans volonté
6
Le principe du moindre privilège impose que tout utilisateur ne doit pouvoir accéder à un instant
donné qu’aux informations strictement nécessaires pour l’accomplissement du travail qui lui a été confié.
7
Une politique de sécurité peut être définie par l’ensemble des règles qui régissent la façon dont
l’information sensible et les autres ressources sont gérées, protégées et distribuées dans le système.
15
préalable de violer la sécurité du système, tombe “par hasard” sur des données qui,
éventuellement par recoupement avec d’autres, dévoilent des informations nominatives
sensibles (auxquelles il n’a pas le droit d’accéder). À ce niveau, aucun acte malveillant n’est
identifié explicitement. Néanmoins, si l’utilisation de ces informations est malveillante, il s’agit
bien d’un abus de pouvoir. Des notions comme les “fautes intentionnelles avec ou sans volonté
de nuire” ou les “divulgations accidentelles d’information” sont donc particulièrement
pertinentes dans l’étude des SICSS [Abou El Kalam et al. 2002b].
structure de l’organigramme ainsi que la répartition des tâches (séparation des environnements
de développement, d’industrialisation et de production des applicatifs) en font partie. Les
propriétés de sécurité recherchées visent, par exemple, à limiter les cumuls ou les délégations
abusives de pouvoir, ou à garantir une séparation des pouvoirs.
La sécurité logique fait référence à la gestion du contrôle d’accès logique, lequel repose sur
un triple service d’identification, d’authentification et autorisation. Elle spécifie qui à le droit
d’accéder à quoi, et dans quelles circonstances. Ainsi, tout utilisateur, avant de se servir du
système, devra décliner son identité (identification) et prouver qu’il est bien la personne qu’il
prétend être (authentification). Une fois la relation établie, les actions légitimes que peut faire
cet utilisateur sont déterminées par la politique d’autorisation (ce type de politiques nous
intéresse particulièrement, et sera décrit en détail dans le chapitre suivant).
L’autorisation consiste à gérer et à vérifier les droits d’accès, en fonction des règles
spécifiées dans la politique de sécurité. On dit qu’un sujet (entité qui demande l’accès, dite
aussi entité active) possède un droit d’accès sur un objet (entité à laquelle le sujet souhaite
accéder, dite aussi entité passive) si et seulement s’il est autorisé à effectuer la fonction d’accès
correspondante sur cet objet. Les droits d’accès peuvent être symboliquement représentés dans
une matrice de droits d’accès dont les lignes représentent les sujets et les colonnes représentent
les objets. Une cellule de la matrice contient donc les droits d’accès d’un sujet sur un objet. La
matrice est gérée conformément aux règles définies dans la politique de sécurité.
L’autorisation est mise en œuvre par des mécanismes de contrôle d’accès. Il est généralement
recommandé d’organiser ces mécanismes de façon à implémenter la notion de “moniteur de
référence”, défini dans le livre orange [TCSEC 1985]. Le moniteur de référence est un
intermédiaire entre les sujets et les objets. Il vérifie que chaque accès d’un sujet vers un objet
est garanti par un droit d’accès dans la matrice de droits d’accès ; en l’absence de ce droit
d’accès, l’accès est refusé. Le moniteur de référence doit être inviolable (il ne doit pas pouvoir
être modifié), incontournable (il ne doit pas être possible d’accéder à un objet sans être contrôlé
par le moniteur de référence), et totalement vérifié (il ne doit comporter aucune faute de
conception ou de réalisation).
Pour être à la fois incontournables et inviolables, il est souhaitable que les contrôles d’accès
soient implémentés par matériel, pour pouvoir contrôler tout accès physique aux informations
(mémoire, disques, canaux de communications, etc.). Le co-processeur LOCK d’Honeywell,
issu d’un projet du NCSC [Saydjari et al. 1989], est un exemple d’implémentation de moniteur
de référence par matériel. La plupart des microprocesseurs modernes offrent des mécanismes
de contrôle d’accès par matériel, en particulier par la gestion de mémoire avec des registres de
segments. Ces registres de segments peuvent être considérés comme des capacités, c’est-à-dire
une implémentation par lignes de la matrice de droits d’accès : les registres de segments
contiennent les références aux objets auxquels le processus en cours (sujet) peut accéder, ainsi
que les droits correspondants (au moins, lire et écrire).
Malheureusement, la plupart des systèmes d’exploitation ne tirent pas parti de ces
mécanismes. Dans Unix, par exemple, les contrôles d’accès sont principalement basés sur des
permissions associées aux fichiers et aux répertoires. Il s’agit donc plutôt d’une
implémentation de la matrice de droits d’accès par colonnes, c’est-à-dire par listes de contrôle
d’accès : à chaque fichier, on associe la liste des sujets (sous Unix, utilisateur ou groupe
d’utilisateur) qui peuvent accéder au fichier et les droits correspondants. Dans ce cas, le
contrôle d’accès se fait uniquement à chaque ouverture de fichier. On est donc assez loin de la
notion de moniteur de référence.
Cette notion de moniteur de référence est très centralisée, et donc difficile à interpréter dans
un système réparti ou sur un réseau. Le livre rouge [TNI 1987] propose un schéma
d’autorisation dans lequel chaque machine possède son propre moniteur de référence. Dans ce
cadre, les accès des sujets aux objets locaux sont contrôlés par le moniteur de référence local,
17
alors que les accès aux objets distants donnent lieu à une coopération entre deux moniteurs de
références. Le moniteur de référence du site, où se trouve le sujet, garantit l’identité du sujet et
éventuellement ses droits. Le moniteur de référence du site de l’objet contrôle l’accès à l’objet
en fonction de l’identité du sujet et éventuellement des droits transmis par l’autre moniteur de
référence et en fonction des droits gérés localement. Dans ce cas, la matrice de droits d’accès
est soit répartie, soit répliquée sur l’ensemble des sites (ce qui rend difficile le maintien de sa
cohérence). Mais le principal inconvénient de ce schéma est que chaque moniteur de référence
doit faire confiance aux autres. Ainsi, si un intrus prend le contrôle d’un site ou si
l’administrateur d’un site est malveillant ou corrompu, il lui est facile, par exemple, de
déguiser8 un sujet local pour obtenir des droits indus sur des objets distants. L’intrusion dans
un site donne donc des privilèges sur d’autres sites.
Des schémas d’autorisation à deux niveaux ont été proposés pour pallier ces inconvénients
[Nicomette & Deswarte 1997 ; Deswarte et al. 2001]. Le premier niveau est constitué d’un
serveur d’autorisation, capable de vérifier les droits de l’utilisateur à lancer une transaction ou
“opération de haut niveau” et de générer des preuves d’autorisation pour l’exécution répartie
de chaque élément de la transaction. Le second niveau est constitué du moniteur de référence
local à chaque site, et qui vérifie que chaque requête (pour exécuter un élément d’une
transaction) est accompagnée d’une preuve d’autorisation valide. Dans ce cas, l’intrusion dans
un site ne donne aucun privilège sur les autres sites. Ce schéma d’autorisation est détaillé à
l’aide d’une modélisation UML dans le quatrième chapitre.
D’une manière générale, les règles de la politique de sécurité sont souvent spécifiées en
terme de permissions (par exemple tout médecin a le droit d’accéder aux dossiers médicaux de
ses patients) et d’interdictions (par exemple, les médecins n’ont pas le droit d’effacer des
diagnostics déjà établis), mais aussi en terme d’obligations (les médecins sont obligés de
garder les dossiers médicaux pendant la durée fixée par la loi). Les politiques de contrôles
d’accès classiques sont restreintes aux autorisations, voire aux interdictions. Et même si
certaines politiques plus récentes spécifient des obligations [Bettini et al. 2002 ; Damianou et
al. 2001], elles n’expliquent pas comment les implémenter. Nous pensons que les obligations
peuvent être implémentées par des traitements automatiques. Un autre exemple concerne
l’implémentation de la propriété de disponibilité. Outre l’aspect allocation des ressources
[Cuppens & Saurel 1999], cette propriété peut être spécifiée par une obligation de fournir des
moyens de tolérance aux fautes comme la redondance ou la diversification logicielle et
matérielle. À présent, ces problèmes sont peu étudiés et méritent un approfondissement
considérable.
Le plus souvent, une politique de sécurité ne peut malheureusement pas contrer toutes les
attaques, et il est parfois possible qu’un utilisateur contourne les mécanismes qui
l’implémentent. Dans d’autres cas, certaines des vulnérabilités d’un système sont tout
simplement dues à des choix délibérés, résultant de compromis entre facilité d’utilisation,
fiabilité, ou coût, d’une part, et sécurité d’autre part.
En outre, la plupart des vulnérabilités sont bien des bogues (bugs, en anglais), dus à la
maladresse des programmeurs, ajoutée à des vérifications insuffisantes. En effet, il n’est pas
toujours facile de prouver que la conception, la configuration, ou la mise en œuvre (par des
mécanismes) d’une politique de sécurité sont conformes aux objectifs de sécurité attendus, et
qu’ils n’introduisent aucune vulnérabilité pouvant être exploitée par un attaquant.
8
Le déguisement (en anglais « masquerade ») consiste à tromper les mécanismes d’authentification
pour se faire passer pour un utilisateur autorisé de façon à obtenir des droits d’accès illégitimes et ainsi
compromettre la confidentialité, l’intégrité ou la disponibilité.
9
Par exemple, l’obligation d’enregistrement des données d’audit peut être mise en œuvre par une action
automatique (enregistrer ces données).
18 Chapitre 1 Sécurité des SICSS
10
Le terme “impossible” est utilisé dans le sens “impossible avec une puissance de calcul raisonnable et
en un temps raisonnable”. En particulier, pour peu que le nombre de clés possibles soit suffisamment
grand, on peut considérer “impossible” l’attaque par “force brute”, qui consiste à essayer
19
plus courant est le RSA, des noms de ses auteurs (Rivest, Shamir, Adleman). Quand on utilise
un chiffre à clé publique pour la confidentialité, la clé de chiffrement Kc peut être connue
publiquement, mais seul celui qui possède la clé de déchiffrement (secrète) Kd peut déchiffrer
le cryptogramme.
Un chiffre est dit hybride s’il combine à la fois les chiffrements symétrique et asymétrique.
Une des manières de faire est la suivante :
- L’émetteur génère aléatoirement une clé symétrique c (clé de session), considéré comme
clé secrète valable pour la transmission en cours, les clés de sessions sont typiquement de
56 bits ou 128 bits.
- L’émetteur chiffre son message M avec cette clé de session (chiffre symétrique, {M}c), et
chiffre cette clé avec la clé publique Kc du destinataire (chiffre asymétrique, {c}Kc), avec
RSA par exemple, cette clé est souvent de 1024 bits ou 2048 bits.
- L’émetteur émet à la fois le message chiffré ({M}c) et la clé de session chiffrée ({c}Kc).
- Le destinataire retrouve la clé de session en utilisant sa clé privée Kd (c = [{c}Kc]Kd).
- Le destinataire déchiffre ensuite le message avec cette clé de session([M = {M}c]c).
systématiquement toutes les clés de déchiffrement possibles jusqu’à trouver la vraie clé. De même, on
considère “impossible” de deviner par hasard la clé.
20 Chapitre 1 Sécurité des SICSS
∑ = signature
M = texte
Génération Vérification
de signature de signature OUI / NON
M = texte
Comme pour le chiffrement, on peut distinguer les signatures symétriques où Ks=Kv et les
signatures à clé publique où Kv est une clé publique (n’importe qui peut vérifier la signature)
alors que Ks est tenue secrète par le signataire. Dans ce cas, il doit être “impossible” de trouver
Ks en connaissant Kv.
Avec une bonne fonction de hachage, il est possible de créer facilement une signature
symétrique : ∑ = H(K | M ), où K est à la fois la clé de génération de signature et la clé de
vérification de la signature. Dans ce cas, la fonction de génération de signature est simplement
l’application de la fonction de hachage sur la clé concaténée avec le texte, et la fonction de
vérification consiste à générer à nouveau une signature de la même façon sur le texte reçu et à
comparer les deux signatures.
Il est également possible de générer des signatures en utilisant des algorithmes de chiffrement
symétriques (par exemple, le DES en mode CBC), c’est le cas des MAC (pour codes
d’authentification de messages en anglais). Cependant, les signatures symétriques présentent
l’inconvénient suivant : la clé doit être partagée entre le signataire et le vérificateur, et tenue
secrète vis-à-vis des tiers. Dans ce cas, signataire et vérificateur doivent se faire mutuellement
confiance.
H!(M) S
-1
H S S OUI /
NON
M H!(M)
M H
Cet inconvénient n’existe pas lorsqu’on utilise des signatures à clé publique, puisque seul le
signataire connaît la clé de génération de signature. Comme il est souhaitable que les signatures
aient une longueur fixe, quelle que soit la longueur du texte à signer, il est préférable de signer
une empreinte du texte plutôt que le texte lui-même. Il faut pour cela choisir une fonction de
hachage de qualité, puisqu’il serait facile, pour un faussaire de réutiliser une signature générée
pour le texte M sur un autre texte M’ ayant la même empreinte que M. L’algorithme DSA (pour
Digital Signature Algorithm), défini dans la norme DSS (pour Digital Signature Standard) est
un exemple d’algorithme de signature à clé publique utilisant une fonction de hachage (voir
figure 1.6). Dans le cas de DSS, la fonction de hachage est SHA.
Il est également possible d’utiliser des algorithmes de chiffrement à clé publique tels que
RSA pour générer et vérifier des signatures sur des empreintes de texte. Dans ce cas, la clé
21
publique Kp est la clé de déchiffrement, utilisée comme clé de vérification, et la clé privée Ks
(maintenue secrète par le signataire) est la clé de chiffrement, utilisée comme clé de génération
de signature11 :
Ks Kv = Kp
M
H ()
1.5.2.1.4 Certificats
Le raisonnement précédemment appliqué (chiffrement et signatures à clés publiques) suppose
l’authenticité des clés publiques, disponibles sur un annuaire ou un serveur web par exemple.
Néanmoins, cette authenticité n’est pas garantie dans un environnement ouvert tel qu’Internet,
et il n’est pas impossible qu’un certain pirate Bob modifie l’annuaire ou le serveur web qui
héberge les clés publiques et remplace ainsi la clé publique d’une certaine Alice par la sienne.
Une fois ce déguisement commis, Bob peut lire les courriers destinés à Alice et signer des
messages en se faisant passer pour Alice. En effet, si un utilisateur envoie un message chiffré à
Alice, il va le chiffrer avec la clé publique de Bob (croyant que c’est la clé d’Alice). Bob
pourra déchiffrer les messages destinés à Alice avec sa clé privée, et lire ainsi le courrier
confidentiel d’Alice. Le raisonnement du scénario de l’usurpation de la signature est le même.
Pour contrer ce type d’attaques et afin d’assurer la validité de la clé publique, il a fallu créer un
mécanisme supplémentaire, le certificat électronique.
Un certificat permet d’établir un environnement de confiance entre deux entités distantes
ayant besoin de communiquer entre elles et de s’échanger des informations non-répudiables
(nécessité de signature) ou confidentielles (application de chiffrement). En effet, un certificat
est souvent destiné à remplir trois rôles : authentification de l’émetteur, garantie de l’intégrité
des documents, et éventuellement un horodatage.
Selon la norme X509 V3, un certificat électronique doit contenir notamment : le nom de
l’autorité de certification, le nom et le prénom de la personne, son entreprise, son adresse
électronique, sa clé publique, les dates de validité du certificat ainsi qu’une signature
électronique (figure 1.8). Cette signature, calculée sur les informations contenues dans le
certificat, est l’empreinte de ces informations chiffrée avec la clé privée de l’autorité de
certification qui a délivré ce certificat.
Quand Alice et Bob veulent communiquer de manière sûre, par exemple lorsqu’elle veut lui
envoyer un message chiffré, le logiciel de messagerie d’Alice a besoin de connaître la clé
11
Nous avons décrit séparément les mécanismes de chiffrement et de signature. Mais il est possible de
cumuler les deux fonctions, par exemple, en envoyant un message chiffré et signé. Les logiciels courants
appliquent la signature avant le chiffrement à l’émission, et le déchiffrement puis la vérification de la
signature à la réception. Toutefois, il est possible d’inverser l’ordre de réalisation de ces opérations.
22 Chapitre 1 Sécurité des SICSS
publique de Bob. S’il ne la connaît pas, il peut interroger l’annuaire électronique pour
récupérer un certificat de Bob. Ce certificat est signé avec une autorité ACBob. Le logiciel de
messagerie peut vérifier la signature de ce certificat pour s’assurer que ce document a bien été
crée par l’autorité ACBob et qu’il n’a pas été modifié. Avec cette assurance, le logiciel de
messagerie peut récupérer la clé publique de Bob contenue dans ce certificat. La vérification du
certificat et l’extraction de la clé publique sont schématisées dans la figure ci-dessous.
Le processus ainsi défini considère une autorité de certification. Celle-ci peut être vue comme
une structure technique et administrative qui :
- génère un couple de clés publique-privée pour elle-même ;
- diffuse la valeur de sa clé publique auprès des structures qu’elle connaît et des annuaires ;
l’un des types d’annuaires reconnus, et implémentés par les principaux outils, est LDAP
(pour Light Directory Access Protocol en anglais) ;
- crée, délivre et révoque les certificats des utilisateurs qu’elle gère.
Une Infrastructure de Gestion de Clés (IGC ou PKI pour Public Key Infrastructure dans la
terminologie anglaise) recouvre l’ensemble des services mis en œuvre pour assurer la gestion
complète des clés publiques, c’est-à-dire l’enregistrement des utilisateurs et la vérification des
attributs, la génération de certificats, la publication des certificats valides et révoqués,
l’identification et l’authentification des utilisateurs, l’archivage des certificats, etc.
Plusieurs composants fondamentaux sont nécessaires pour la mise en œuvre d’une IGC,
notamment :
- l’autorité de certification ;
- l’autorité d’enregistrement, qui est l’autorité de réception des utilisateurs qui désirent
obtenir un certificat ; elle vérifie l’identité du demandeur et ses autres attributs, s’assure
que celui-ci possède bien un couple de clés privée-publique, récupère la clé publique du
demandeur, et transmet ensuite ces informations ainsi que les autres attributs à l’autorité
de certification ;
- un service de publication ou autorité de validation ;
- l’annuaire qui contient les clés publiques, les certificats distribués, ainsi que les listes de
certificats révoqués. Il est généralement basé sur un service LDAP.
également de spécialiser les centres selon la sensibilité des informations traitées : les serveurs
d’informations publiques (non-classifiées) ne devraient pas contenir d’informations classifiées.
De même, les systèmes d’audit doivent être inaccessibles des systèmes qu’ils surveillent (voir
section suivante).
Les “pare-feux” (firewalls en anglais, [Cheswik & Bellovin 1994]) permettent de surveiller et
de restreindre les accès de l’extérieur (par exemple, l’Internet) vers l’intérieur (une machine, un
réseau local, les réseaux d’une entreprise) et l’extérieur (par exemple, l’Internet), mais aussi les
accès de l’intérieur vers l’extérieur. Un pare-feu est donc l’un des mécanismes de contrôle
d’accès qui peut être mis en œuvre pour implémenter les règles de la politique de sécurité.
Un pare-feu comporte essentiellement une fonction de filtrage : il ne laisse passer que les
paquets provenant de certaines adresses autorisées (numéro IP + numéro de port) et à
destination de certaines adresses autorisées. Mais il peut remplir d’autres fonctions
complémentaires, comme la traduction d’adresses (NAT, pour Network Address Translation),
ou jouer le rôle de mandataire d’application. La traduction d’adresses permet de gérer l’espace
d’adressage du réseau interne indépendamment du réseau externe : les adresses internes ne sont
pas connues de l’extérieur, elles sont traduites en adresses externes par le pare-feu. Un
mandataire (proxy en anglais) d’application permet d’interpréter chacune des interactions d’une
application (commandes, requêtes, réponses) pour vérifier que les échanges suivent bien un
protocole autorisé.
1.5.2.3 Audit
L’audit sert à conserver des traces des opérations susceptibles de mettre en cause la sécurité,
de façon à analyser, après coup ou en temps réel, si des malveillances ont lieu ou ont eu lieu et
quels sont les moyens et les méthodes utilisés, de façon à punir les coupables et à corriger les
vulnérabilités. Il faut donc enregistrer toutes les opérations liées à la sécurité, que ces
opérations soient réussies (parce qu’autorisées) ou qu’elles aient échouées (empêchées par les
mécanismes de contrôle d’accès). Les principales opérations à surveiller sont :
- la connexion et la déconnexion des utilisateurs ;
- la création, modification, destruction des informations de sécurité (droits d’accès, mots de
passe, etc.) ;
- les changements de privilèges.
Les journaux d’audit doivent être indestructibles (sauf par les administrateurs de l’audit). Ils
doivent porter sur tous les utilisateurs (y compris les administrateurs et les responsables de la
sécurité) et contenir un maximum d’informations utiles (date et heure, identité de l’utilisateur,
type d’opération, référence de l’information, etc.). Bien évidemment, l’administrateur de
l’audit doit être indépendant des administrateurs du système surveillé, et il est souhaitable que
le système surveillé ne puisse pas accéder au système d’audit.
Les journaux d’audit sont en particulier l’une des sources d’informations des systèmes de
détection d’intrusion.
comportement
détection
normal
d’anomalies
≠
comportement
alertes
observé
=
détection
scénarios d’attaques
d’attaques
Des travaux plus récents tentent de disposer, à terme, d’un système de détection d’intrusions
global. Il prend en entrée aussi bien des données réseaux (provenant des IDS sur réseau) que
des données systèmes (provenant des IDS sur hôte), en les analysant selon une méthode croisée
utilisant à la fois l’approche comportementale et l’approche par scénario [Debar &
Wespi 2001]. En outre, ces travaux font coopérer différents outils afin de tirer partie des forces
de chacun pour limiter le taux de faux négatifs d’une part, et de corréler les alarmes émises afin
de limiter le taux de faux positifs d’autre part :
- Il est très rare qu’une attaque génère une seule alarme. La corrélation permet de grouper
les alarmes relatives à une même attaque, d’étudier les différentes attaques en cours,
d’évaluer globalement la situation et de préparer une réponse appropriée.
- Étant donné que les IDS génèrent de nombreux faux positifs, la corrélation permet, en
utilisant plusieurs sources de données, de vérifier la pertinence des alarmes et d’affiner le
25
Les TCSEC visent d’abord à satisfaire les besoins du DoD (Department of Defense) des
États-Unis, privilégiant ainsi la confidentialité des données militaires. Par ailleurs, le manque
de souplesse et la difficulté de leur mise en œuvre, ont conduit au développement de nouvelles
générations de critères. À titre d’exemple abordons les critères adoptés par la Communauté
Européenne [ITSEC 1991], mais d’autres pays tels que le Canada [CTCPEC 1993] et le Japon
[JCSEC 1992] ont également élaboré leurs propres critères d’évaluation.
Les ITSEC sont le résultat d’harmonisation de travaux réalisés au sein de quatre pays
européens : l’Allemagne, la France, les Pays-Bas et le Royaume-Uni [ITSEC 1991]. La
différence essentielle entre les TCSEC et les ITSEC réside dans la distinction entre
fonctionnalité et assurance. Une classe de fonctionnalité décrit les fonctions que doit mettre en
œuvre un système tandis qu’une classe d’assurance décrit l’ensemble des preuves qu’un
système doit apporter pour montrer qu’il implémente les fonctions qu’il prétend fournir.
Les ITSEC introduisent également la notion de “cible d’évaluation” (TOE pour Target Of
Evaluation). Une TOE rassemble les différents éléments du contexte d’évaluation, dont une
politique de sécurité, une spécification des fonctions requises dédiées à la sécurité, une
définition des mécanismes de sécurité (optionnelle), la cotation annoncée de la résistance
minimum des mécanismes, ainsi que le niveau d’évaluation visé.
Les ITSEC proposent dix classes de fonctionnalités de base :
- les classes de fonctionnalité F-C1, F-C2, F-B1, F-B2, F-B3 sont des classes de
confidentialité qui correspondent aux exigences de fonctionnalité des classes C1 à A1 dans
les TCSEC ;
- la classe de fonctionnalité F-IN concerne les TOE pour lesquelles il y a des exigences
d’intégrité (par exemple, pour les bases de données) ;
- la classe de fonctionnalité F-AV impose des exigences de disponibilité ;
- la classe de fonctionnalité F-DI impose des exigences élevées pour l’intégrité des données
au cours de leur transmission ;
- l’exemple de classe de fonctionnalité F - D C est destinée aux TOE exigeantes en
confidentialité des données au cours de leur transmission ;
- la classe de fonctionnalité F-DX est destinée aux réseaux exigeants en matière de
confidentialité et d’intégrité de l’information.
Les différents critères d’assurance exigés se découpent en deux aspects : les critères
d’assurance d’efficacité et les critères d’assurance de conformité. Ces critères d’assurance se
découpent à nouveau en deux catégories vis-à-vis de la construction et de l’exploitation du
système. Les critères d’assurance de conformité sont définis vis-à-vis de six niveaux
d’exigences, numérotés de E1 à E6, qui correspondent à des contraintes de plus en plus fortes
et définissent le niveau de certification atteint par une TOE. De plus amples détails sur les
ITSEC et les TCSEC peuvent être trouvés dans [Branstad et al. 1990 ; Dacier 1994].
La tentative d’harmonisation des critères canadiens, européens et américains, a donné
naissance aux critères communs (en anglais « Common Critéria for Information Security
Evaluation ») [CC 1999a] qui sont maintenant une norme internationale [ISO 15408]. Ces
critères contiennent deux parties bien distinctes comme dans les ITSEC : fonctionnalité et
assurance. Les critères communs définissent également une cible d’évaluation (TOE) ainsi que
les profils de protection [CC 1999b], déjà existants dans les critères fédéraux américains
[Federal Criteria 1992]. Pour une catégorie de TOE, un profil de protection définit un ensemble
d’exigences de sécurité et d’objectifs, indépendant d’une quelconque implémentation. L’intérêt
de ces profils est double : un développeur peut inclure dans la définition de la TOE un ou
plusieurs profils de protection ; un client désirant utiliser un système ou un produit peut
28 Chapitre 1 Sécurité des SICSS
jour le jour le niveau de sécurité et de prendre des mesures correctives en cas de baisse de ces
indicateurs. Ceci permet d’évaluer la sécurité opérationnelle, c’est-à-dire correspondant à la
façon d’utiliser les systèmes et ses mécanismes de protection, plutôt qu’une vision statique
comme celle donnée par les critères d’évaluation ou par les méthodes classiques d’analyse de
risques. C’est aujourd’hui un domaine de recherche actif, mais qui a jusqu’à présent donné peu
de résultats. C’est le cas de la méthode d’évaluation de la sécurité en calculant le temps et
l’effort nécessaire à un intrus pour violer les objectifs de protection [Dacier 1994]. Cette
méthode utilise un formalisme basé sur les graphes de privilèges (voir 2.2.2.5) et les réseaux de
Petri stochastiques, et se base sur les étapes suivantes :
- détermination des vulnérabilités à prendre en compte, en s’appuyant notamment sur la
politique de sécurité ou sur une liste de vulnérabilités déjà identifiées ;
- quantification de ces vulnérabilités ;
- évaluation quantitative en utilisant la politique de sécurité et une représentation des
vulnérabilités existantes dans le système.
Cette méthode utilise le graphe de privilège comme modèle de représentation des
vulnérabilités d’un système [Dacier 1994 ; Dacier & Deswarte 1994]. Dans le graphe de
privilège, une vulnérabilité correspond à une méthode de transfert de privilèges. Les nœuds du
graphe représentent les différents privilèges qui existent dans le système. Un arc est créé entre
deux nœuds si une méthode, possédant les privilèges du nœud origine, permet d’obtenir ceux
du nœud destination. L’existence d’un arc entre deux nœuds dépend donc de l’état du système
à un instant donné, qui peut ou non permettre l’exploitation d’une certaine vulnérabilité.
Les vulnérabilités, qui doivent tout au début de ce processus être recherchées dans le
système, peuvent avoir des origines variées, comme la mauvaise utilisation des mécanismes de
protection ou les délégations de pouvoirs. Des valeurs quantitatives sont ensuite associées aux
vulnérabilités élémentaires afin de définir des mesures quantitatives de la sécurité globales. Par
exemple, on affecte à chaque arc du graphe des privilèges un poids correspondant à l’effort
nécessaire à un attaquant potentiel pour exploiter la méthode de transfert de privilèges
correspondant à cet arc. Cette notion d’effort regroupe les différentes caractéristiques du
processus d’attaque comme la puissance de calcul disponible pour l’attaquant.
Par ailleurs, les objectifs de sécurité définis par la politique de sécurité permettent d’identifier
les différents nœuds du graphe correspondant aux attaquants et aux cibles potentiels qui sont
pertinents à étudier dans un système donné.
Les travaux effectués par Ortalo ont utilisé cette méthode et ont abouti à l’élaboration du
prototype ÉSOPE (pour Évaluation de la Sécurité Opérationnelle) [Ortalo et al.1999].
Enfin, il est important de noter que les mesures de sécurité que nous avons décrites
(cloisonnement, détection et tolérance aux intrusions, chiffrement, etc.) ne devront pas être
mises en place tant que l’on n’aura pas défini et documenté au préalable une politique de
sécurité. En effet, une démarche sécuritaire repose sur une politique de sécurité pour recenser
les objectifs de sécurité à atteindre, les éléments à protéger ainsi que les risques encourus (et
leurs combinaisons). Ensuite il convient de définir comment le système évolue (face aux
risques identifiés) et quelles sont les mesures préventives et les mécanismes à mettre en place.
L’évaluation de la sécurité permet, par la suite, d’identifier le niveau de sécurité visé et de
savoir (ou prouver) si la politique et les mécanismes de sécurité mis en œuvre permettent bien
d’atteindre le niveau visé.
Chapitre 2. Politiques et modèles de sécurité
Préambule
12
Cette notion d’objet est à prendre dans un sens large. Elle peut recouvrir les notions classiques
d’objet des systèmes dits orientés-objets et incluant les sujets eux-mêmes.
33
13
En raison de sa simplicité, nous avons choisi une notation dérivée du modèle HRU. Celui-ci sera
décrit en détail en 2.2.2.2.
34 Chapitre 2 Politiques et modèles de sécurité
- s2 peut créer un fichier f2 (dans lequel il peut donc écrire) sur lequel il peut donner le droit
de lecture à s3 (s’exécutant pour le compte d’u3) :
(s2, f2, créer) ‘ (s2, f2, écrire) Ÿ (s3, f2, lire)
- s2 peut alors recopier f1dans f2 pour transmettre les informations de f1à s3 à l’insu du
propriétaire s1 :
(s2, f1, lire) Ÿ (s2, f2, écrire) Ÿ (s3, f2, lire) ‘ (s3, k(f1), lire) où (k(f1) désigne une copie de f1)
Une politique discrétionnaire n’est donc applicable que dans la mesure où il est possible de
faire totalement confiance aux utilisateurs et aux sujets qui s’exécutent pour leur compte. Une
telle politique est par là même vulnérable aux abus de pouvoir provoqués par maladresse ou
par malveillance. Ainsi, s’il est possible à un utilisateur d’accéder à certains objets ou d’en
modifier les droits d’accès, il est possible qu’un cheval de Troie s’exécutant pour le compte de
cet utilisateur (à son insu) en fasse de même. De plus, si un utilisateur a le droit de lire une
information, il a (en général) le droit de la transmettre à n’importe qui.
Étant donné un système, une configuration initiale Q 0, et un droit a, on dit que Q 0 est sûr
pour a, s’il n’existe aucune séquence d’opérations qui, exécutée à partir de l’état Q0, peut
amener le droit a dans une cellule particulière (i.e. pas dans n’importe laquelle) de la matrice
de contrôle d’accès dans laquelle a ne se trouve pas déjà. La démonstration de cette propriété
constitue le problème de protection (safety problem). En fait, ce problème revient à vérifier
qu’un schéma d’autorisation est correct vis-à-vis d’un ensemble d’objectifs de sécurité.
Harrison, Ruzzo et Ullman ont démontré deux théorèmes fondamentaux concernant la
complexité du problème de protection :
- le problème de protection est indécidable dans le cas général, c’est-à-dire, étant donné une
matrice d’accès initiale et un ensemble de commandes, il est impossible de savoir si
aucune séquence d’applications de ces commandes n’aura pour conséquence de mettre un
droit particulier dans un endroit de la matrice où il ne se trouvait pas initialement ;
- le problème de protection est décidable pour les systèmes à mono-opération, c’est-à-dire
dont les commandes ne contiennent qu’une seule opération élémentaire.
Le modèle HRU à mono-opération est très pratique à manipuler néanmoins, il reste trop
simple pour couvrir des politiques de sécurité intéressantes. Dans la mesure où il n’y a pas
d’opération élémentaire qui permette simultanément de créer un objet et d’y associer des droits,
le modèle HRU à mono-opération ne permet pas d’exprimer des politiques dans lesquelles les
sujets qui créent des objets se voient attribuer des droits spécifiques sur ces objets.
- la commande “grant” qui permet à un sujet P possédant un droit d’accès a sur Q ainsi que
le droit g sur un autre sujet R, de céder à R le droit a sur Q (que P possède sur Q) ;
Dans ce modèle, le graphe représentant l’état de protection du système, peut être assimilé à la
matrice d’accès, et les quatre règles ci-dessus (dites de réécriture), correspondent au schéma
d’autorisation, c’est-à-dire aux commandes.
P a
P Q
Règle !create!: !P! crée l’objet !Q!
a a-g
P Q P Q
Règle remove!: retire le droit!g de P sur Q!
g g a
P R Q P R Q
a a
Règle grant : P cède le droit a sur Q à R
t a
t a P R Q
P R Q
a
Règle take : P obtient le droit a sur Q
Même si ces règles peuvent paraître simples, leurs combinaisons peuvent mener le système
dans des états d’insécurité. En effet, l’application successive de plusieurs règles (bien choisies)
peut donner d’autres droits à des sujets, ce qui risque de compromettre certains objectifs de
sécurité. L’exemple de la figure 2.2., extrait de [Dacier 1994], montre un graphe de protection
qui contient deux sujets, P et R et un objet O. Dans l’état de protection initial, R possède le
droit a sur O et le droit t sur P. Considérons un objectif de sécurité stipulant que le système est
déclaré non-sûr si P parvient à acquérir le droit a sur O.
a
R O
t
La séquence d’application des règles décrites dans la figure 2.3 indique que le système n’est
pas sûr, alors que ce constat n’est pas directement explicite dans la figure 2.2.
a a a a
R O R O R O R O
t t t a
g g a t
g a
P N P N P N P N
tg tg tg tg
1/ P crée un arc étiqueté 2/ R reprend le droit 3/ R accorde le !droit 4/ P prend le !droit
tg vers un nouveau sujet!N (g sur N) de P (a vers O) à N (a vers O) de N
Figure 2.3 : Exemple d’application des règles de réécriture dans le modèle Take-Grant.
Pour pallier ce type de problème, Jones et al. ont étudié le problème de protection dans le
cadre du modèle Take-Grant [Jones et al. 1976]. Ils définissent le prédicat “can” de la façon
suivante : « P can a Q » est vrai si et seulement s’il existe une séquence de graphes “G1, .., G n”
telle que P ait le droit a sur Q dans le graphe G n. Jones et al. définissent les conditions
nécessaires et suffisantes pour que le prédicat soit satisfait. Ils établissent également l’existence
d’une solution algorithmique de complexité linéaire permettant d’établir si le prédicat est
37
vérifié. Toutefois, les hypothèses sous-jacentes à ce modèle sont assez peu réalistes. En effet, et
comme on peut le constater avec l’exemple présenté, s’il est vrai que P peut parvenir à acquérir
le droit a sur O , il ne peut le faire que si R collabore avec lui. En réalité, il est difficile
d’imaginer que tous les sujets vont collaborer afin de mettre la sécurité en péril. Une telle
hypothèse est donc de pire cas sur le comportement des utilisateurs du système. Plusieurs
raffinements des propriétés démontrables grâce au modèle Take-Grant ont été proposés,
notamment afin de lever cette hypothèse et de se concentrer sur les cas où un utilisateur
[Synder 1981] ou un ensemble d’utilisateurs [Dacier 1993] tentent de mettre en défaut les
objectifs de sécurité. L’étude des propriétés de ce modèle dans des cadres spécifiques a fait
l’objet de nombreux travaux, notamment ceux recensés dans [Dacier 1994].
Sandhu montre qu’il est possible de résoudre le problème de protection dans bon nombre de
cas pratiques, sans perdre de puissance d’expression. Il décrit un algorithme qui permet
d’obtenir un état maximal de protection [Sandhu 1992]. Cet état se caractérise par une matrice
d’accès sur laquelle on ne peut plus exécuter de règles du schéma d’autorisation.
Une version dite “augmentée” de TAM, appelée ATAM, a été proposée [Ammann et Sandhu
1992] afin de fournir un moyen simple de détecter l’absence de droits dans une matrice
d’accès. Pour cela, le modèle ATAM offre la possibilité d’utiliser des tests du type « ai œ
M(s,o) » dans la partie conditionnelle de la commande. La façon de gérer ce type de commande
et de résoudre le problème de protection a également été définie. L’intérêt de cette démarche
consiste à modéliser facilement la séparation des pouvoirs (celle-ci préconise l’intervention de
plusieurs utilisateurs pour mener à bien une certaine tâche).
38 Chapitre 2 Politiques et modèles de sécurité
- si l’opération est une lecture, le niveau de sécurité de l’objet est dominé par le niveau
courant du sujet.
Mais la politique de Bell-Lapabula présente plusieurs inconvénients. Le plus important est la
dégradation du service provoquée par la surclassification des informations. En effet, au cours
de sa vie, le niveau d’une information ne peut que croître : si une information non classifiée est
utilisée par un sujet habilité au secret, tout objet modifié par ce sujet avec cette information
sera classifié secret. Petit à petit, les niveaux de classification des informations croissent de
façon automatique, et il faut les “déclassifier”, manuellement par un officier de sécurité ou par
un processus dit “de confiance” (trusted process) n’obéissant pas aux règles du modèle.
De plus, il est possible de construire un système, appelé Système Z [McLean 1985], qui
vérifie bien les deux propriétés, et qui n’est pourtant pas sûr. Le système Z est un système où
un utilisateur de niveau minimal met les niveaux de tous les sujets et de tous les objets au
niveau minimal, et autorise l’accès de tous les utilisateurs à tous les objets. Ceci est possible
car le niveau d’un objet peut, lui-même, être mémorisé dans un objet ; la valeur de ce dernier
peut donc être modifiée par un utilisateur de niveau minimal (puisque l’écriture dans un niveau
dominant est autorisée).
applicables dans un environnement moins rigide que ceux dans lesquels des politiques de
sécurité comme les politiques multi-niveaux sont utilisées.
(puisqu’il a accès à Y(BanqueA) alors que cette information (initialement concernant C A) est
dans la même classe de conflit d’intérêt de CB (à laquelle il a déjà accédé). La propriété seule,
seule, ne permet pas d’empêcher de telles attaques, tandis que l’attaque ne peut pas réussir si le
système implémente la propriété étoile.
Une approche originale pour la représentation des flux d’information dans un système
consiste à caractériser les dépendances causales qui existent, à différents instants, entre les
objets du système [Bieber & Cppens 1991 ; d’Ausbourg 1994]. Dans ce modèle, un système est
représenté sous forme de points (o, t). Un point désigne, non pas un objet, mais l’état d’un
objet o à l’instant t. Certains de ces points sont des entrées, d’autres des sorties, et tous les
autres constituent des points internes au système. L’ensemble de ces points évolue avec le
temps et cette évolution est due aux transitions élémentaires qui ont eu lieu dans le système.
Une transition élémentaire peut, à un instant t, associer une nouvelle valeur à un objet o en ce
point. Cet instant et cette nouvelle valeur dépendent donc de certains autres points antérieurs.
La dépendance causale de (o, t) vis-à-vis de (o’, t’), avec t’<t est notée « (o’, t’)Æ(o, t) ». La
fermeture transitive de la relation « Æ » (notée « Æ * ») au point (o, t) définit le cône de
causalité en ce point : cône(o,t) = { (o’, t’) tel que (o’, t’) Æ* (o, t) }.
Réciproquement, on définit le cône de dépendance d’un point (o, t) comme un ensemble des
points qui dépendent causalement de (o, t) : dep(o, t) = { (o’, t’) tel que (o, t) Æ* (o’, t’) }.
Les dépendances causales représentent la structure des flux d’information dans le système. Si
un sujet s possède une certaine connaissance du comportement interne du système, il est en
mesure de connaître les dépendances causales. Dans ce cas, en observant une sortie particulière
x0, un sujet s peut être en mesure d’inférer toute information appartenant à cône(x 0)
Réciproquement en altérant une entrée xi du système, s peut éventuellement altérer tous les
points appartenant à dep(xi).
Les objectifs de sécurité de ce modèle peuvent être relatifs à la confidentialité ou à l’intégrité.
Soit la notation suivante :
- Obss, l’ensemble des points qu’un sujet s peut observer, Obss = » cône(x 0 ) ;
xoŒOs
« Joue(Sujet, Rôle) » définissent précisément les permissions accordées à chaque sujet. Un rôle
peut avoir plusieurs permissions et une permission peut être associée à plusieurs rôles. De
même qu’un sujet peut être membre de plusieurs rôles et inversement, un rôle peut être exécuté
par plusieurs sujets. Ainsi, si le docteur Dupont est à la fois chirurgien et directeur de l’hôpital,
en tant que chirurgien, il aura le droit d’accès aux dossiers médicaux, alors qu’en tant que
directeur, il pourra accéder aux informations administratives.
Joue Détient
Sujet 0..n 0..n Rôle 0..n 0..n Permission
Figure 2.4 : Attribution des permissions aux sujets à travers des rôles.
L’une des manières de définir les rôles au sein d’une organisation consiste à regrouper dans
chaque rôle les tâches pouvant exécuter les mêmes opérations, ensuite il s’agit d’identifier les
objets que ces tâches utilisent, puis définir les droits d’accès sur ces objets, c’est-à-dire les
couples (ensemble de droits, objets) et finalement, d’associer ces droits aux rôles. L’affectation
des sujets aux rôles est une tâche à faire séparément, et probablement par d’autres
administrateurs.
Des variantes de RBAC ont essayé de le raffiner, notamment en incluant les concepts de
session, de hiérarchie de rôles et de contraintes sur les rôles [Sandhu 1996] [Sandhu et al.
1996] [Garvila & Barkley 1998] [Ahn & Sandhu 2000] [Ferraiolo et al. 2001]. Dans une même
session, un utilisateur a la possibilité de ne pas activer tous ses rôles, mais uniquement le sous-
ensemble de ses rôles nécessaire à la réalisation de la tâche à accomplir. La hiérarchie de rôles
permet de mettre en place un mécanisme d’héritage des permissions entre les rôles et simplifie
d’autant l’administration de ce modèle. Par exemple, comme les chirurgiens et les
gynécologues sont nécessairement médecins, on assignera des permissions au rôle médecin, et
seulement des permissions supplémentaires au rôle chirurgien, d’une part et au rôle
gynécologue d’autre part. Des contraintes (par exemple, d’où le rôle peut-il être activé, quand
peut-il être activé et quelles sont les données qu’un rôle peut manipuler ?) ont été intégrées
dans des versions récentes de RBAC.
Un modèle de contrôle d’accès reposant sur la notion de rôle, est défini dans [Sandhu 1996]
de la manière suivante14 :
- U , R , P , S, respectivement des ensembles d’utilisateurs, de rôles, de permissions et de
sessions ;
- PA Õ R ¥ P, une relation associant une permission à un rôle ;
- UA Õ U ¥ R, une relation associant un ou plusieurs rôles à un utilisateur ;
- RH Õ R ¥ R, une hiérarchie de rôles partiellement ordonnés ; r ≥ r’ signifie que r’ est un
sous-rôle de r ;
- User : SÆ U, une fonction associant chaque session si à un seul utilisateur User(s i), qui
reste constante pour la durée de vie de la session ;
- « Role : SÆ 2 R », une fonction associant chaque session si à un ensemble de rôles Role(si),
avec : Role(si ) Õ { r ($r' ≥ r) et (User(si ),r') Œ UA} ;
- une collection de contraintes qui détermine si certains éléments du modèle RBAC sont
acceptables (seuls les éléments acceptables sont intégrés dans le modèle).
14
Une modélisation algébrique plus solide de RBAC enrichie par des notions comme les sessions, la
hiérarchie, les contraintes, l’activation des rôles, etc. est donnée dans [Ferraiolo et al. 2001].
49
L’analyse des politiques basées sur les rôles permet de conclure qu’elles sont relativement
faciles à administrer et suffisamment souples pour s’adapter à chaque organisation [Sandhu
1996 ; Ferraiolo et al. 2001]. En effet, la définition des rôles peut refléter la structure de
l’organisation. Les rôles peuvent être structurés de façon hiérarchique, pour simplifier encore
l’affectation des permissions. Avec RBAC, il est facile d’ajouter un utilisateur : il suffit de lui
assigner les rôles qu’il doit jouer dans l’organisation. De même, il est relativement facile de
faire évoluer les tâches suite à la création ou la modification d’un objet : il suffit de mettre à
jour les privilèges des rôles concernés.
Le principal inconvénient de RBAC réside dans la difficulté de gérer et d’implémenter des
règles du type « seuls les médecins traitants peuvent lire les informations médicales du dossier
d’un patient ». Pour résoudre ce problème avec RBAC, il faut soit créer autant de rôles
« médecin traitant du patient X » que de patients, soit mettre en œuvre des règles
supplémentaires dans l’application (par exemple, gestion de la base de données des dossiers
médicaux), règles qui ne sont pas exprimables dans le modèle RBAC.
La figure 2.5 donne une description graphique des concepts de TMAC tels qu’ils ont été
définis dans [Thomas 1997].
Permissions de l’équipe
Rôles de l’équipe Types d’objets
Contexte-
Contexte- Contexte de Objet
Utilisateur
collaboration
Le travail décrit dans [Thomas 1997] reste une introduction innovante de la notion d’équipe
dans la formulation des politiques de sécurité. En effet, dans TMAC, l’appartenance d’un
utilisateur à une équipe donnée lui confère le droit d’accéder aux ressources associées à cette
équipe. Ainsi, les permissions d’un utilisateur dépendent non seulement, du ou des rôles qu’il
joue à un moment donné, mais aussi de l’activité courante de l’équipe à laquelle il appartient.
Dans le domaine médical, par exemple, un médecin n’a le droit de prescrire des médicaments
que pour les patients qu’il traite (le simple fait d’être médecin ne lui donne pas le droit de
prescrire des médicaments pour tous les patients). TMAC peut exprimer ce besoin dans la
mesure où elle voit un médecin comme un membre d’une ou plusieurs équipes. Néanmoins,
Thomas [Thomas 1997] n’a pas spécifié la façon selon laquelle les règles de sécurité seront
représentées, ni comment les permissions seront dérivées.
Identification + authentification
Contexte de l’équipe
Permission-rôle-session Permission-rôle-équipe
Patients :
Select Select
(200, 351)
Champ1, Champ2, Champ1, Champ3, Champ4
Temps :
Champ3 From Patient
From Patient [10h-12h]
Lieu :
(UR1, UR3)
Combinaison = Agrégation
Permission-rôles
Select
Champ1, Champ2, Filtrage
Champ3, Champ4 Permission-Contexte
From Patient Select
Champ1, Champ2, Champ3, Champ4
From Patient
Where PatientID IN (200, 351)
And Temps IN ([10h!; 12h)]
And Lieu IN (UR 1, UR 3)
Permission-Rôle(Chris)=Permission-rôle-session(médecin)⊕Permission-rôles-équipe(Eq-Ur)
= {SELECT Champ1, Champ2, Champ3 FROM patient} » {SELECT Champ1, Champ3,
Champ4 FROM patient}.
En appliquant la règle de filtrage, les permissions finales sont :
Permission-Contexte(Chris) = Permission-rôle(Chris) ƒ contexte-équipe(Eq-Ur)
= SELECT Champ1, Champ2, Champ3, Champ4 FROM patients ;
Where PatientID IN (200, 351) AND temps IN [10h-12h] AND lieu IN (UR1, UR3).
À travers cet exemple très simple, on peut constater que C-TMAC présente certaines
faiblesses. En effet, si la combinaison est une agrégation, un utilisateur qui rejoint une équipe
renforce les permissions de cette équipe en lui ajoutant les siennes : (Permissions-équipe-après
affectation = Permissions-équipe-avant affectation » Permissions(nouvel utilisateur)). Ainsi,
tous les membres de l’équipe auront les mêmes permissions. Néanmoins, dans le secteur
médical, même si les professionnels de santé appartiennent à la même équipe du même hôpital,
ils n’ont pas les mêmes droits d’accès aux mêmes parties des fichiers. Il est évident que les
permissions finales du médecin doivent être différentes de celles de l’infirmière, même si tous
les deux appartiennent à la même équipe de soins. Or, si on reprend l’exemple de la figure 2.6,
en considérant, cette fois-ci, que le médecin se connecte avant l’infirmière, on constatera qu’en
rejoignant l’équipe, l’infirmière a les mêmes permissions que le médecin.
Le cas où la combinaison est le maximum ou le minimum est, lui aussi, non réaliste car la
déduction des permissions (application des deux règles citées précédemment) se fait de la
même manière pour tous les membres d’une équipe donnée. On aura donc le même ensemble
de privilèges pour tous ses membres. De plus, dans le secteur de la santé, que veut dire un
ensemble minimal ou maximal de permissions ?
Par ailleurs, C-TMAC ne spécifie pas explicitement comment dériver les permissions dans le
cas où la combinaison dépendrait de la structure de l’équipe.
générique de permission. Le concept de hiérarchie de rôles est quelque peu ambigu. Il est en
général incorrect de considérer que la hiérarchie de rôles correspond à la hiérarchie
organisationnelle. Par exemple, le directeur d’un hôpital a un rôle administratif supérieur au
rôle de médecin. Pour autant, un directeur d’hôpital n’est pas nécessairement un médecin.
Ainsi, il serait incorrect de considérer que le directeur de l’hôpital hérite des permissions du
rôle de médecin, comme celle de prescrire par exemple.
De plus, il n’est pas possible dans le modèle RBAC d’exprimer des permissions qui
dépendent du contexte. Rappelons que si une certaine permission est accordée à un rôle, alors
tous les utilisateurs qui jouent ce rôle héritent de cette permission. Par conséquent, il n’existe
aucun moyen simple pour spécifier qu’un médecin n’a la permission d’accéder au dossier
médical d’un patient que si ce dernier est son patient [Cheng 1999] [Barkley et al. 1999].
Enfin, C-TMAC présente certaines limites notamment dans la manière de dériver les
permissions. Par ailleurs, dans la quasi-totalité des politiques et modèles étudiés dans ce
chapitre, il n’est possible de définir que des permissions, alors que pour les SICSS, il faudra
exprimer des interdictions, des obligations et parfois des recommandations.
Cette analyse critique constitue le fondement de nos recherches de politiques et modèles
mieux adaptés aux SICSS. Le quatrième chapitre clarifie les points évoqués dans cette section
et présente le modèle Or-BAC, l’alternative que nous proposons pour spécifier les politiques
des SICSS, mais aussi des domaines complexes, interopérables, hétérogènes et fortement
distribués [Abou El Kalam et al. 2003].
personnelles. Le code doit être compatible avec le code de déontologie européen, doit convenir
aux caractéristiques de chaque établissement comme il doit réduire les divergences entre la
théorie et la pratique ». La deuxième directive précise que « le code doit reconnaître les droits
individuels, doit être conforme aux conventions internationales des droits de l’homme et à la
législation nationale au même titre qu’il doit respecter les directives européennes ».
Notre étude de la politique de sécurité de SEISMED nous a permis de constater que
SEISMED manque d’un cadre conceptuel clair et structuré. De plus, cette étude devrait être
complétée par un ensemble de mesures spécifiques à chaque environnement.
les besoins ainsi que les règles de sécurité à appliquer, ceci implique la définition et la
spécification d’une politique de sécurité appropriée aux SICSS.
Le travail jusque là effectué s’attache à prendre en compte les concepts sectoriels particuliers,
tels que l’auditabilité juridico-technique [Trouessin, 2002] issue des responsabilités juridiques
spécifiques (légales, éthiques, déontologiques) pour les politiques de sécurité à respecter ainsi
que des modèles de sécurité adaptés et adaptables aux SICSS. Notre objectif est d’améliorer la
pertinence et l’efficacité des systèmes des secteurs ciblés ainsi que la confiance à accorder à de
tels systèmes. Plusieurs problématiques de recherche seront étudiées, telles les politiques de
sécurité et modèles de politiques de sécurité, politiques d’autorisation et d’anonymisation, et ce
dans les rouages des deux secteurs : médical et social.
Nos travaux sont partiellement soutenus par le Réseau National de Recherche en
Télécommunication, dans le cadre du projet MP6 (Modèles et Politiques de Sécurité pour les
Systèmes d’Information et de Communication en Santé et Social) dont les partenaires sont :
Ernst & Young Audit (coordinateur), ENST-Bretagne, ETIAM, France Telecom R&D, LAAS-
CNRS, MasterSecuritY, ONERA-DTIM, Supélec-Rennes, et UPS-IRIT.
Le projet MP6 est organisé en 9 sous projets :
- SP1 : Administration, gestion et coordination du projet ;
- SP2 : État des lieux sectoriel/conceptuel/terminologique en sécurité pour les SICSS ;
- SP3 : Politiques de sécurité pour les SICSS ;
- SP4 : Modélisations formelles de politiques de sécurité des SICSS ;
- SP5 : Explorations-A “politiques d’autorisation et gestion des droits” ;
- SP6 : Explorations-B “politiques d’anonymisation et gestion des pseudonymes” ;
- SP7 : Explorations-C “détection de risques d’intrusions, déviances et inférences” ;
- SP8 : Intégrations sectorielles pour la sécurité des SICSS ;
- SP9 : Normes et standards, promotion et valorisation.
Nous contribuons aux sous projets 2, 3, 4, 5, 6, 7 et 9.
Chapitre 3. Bâtir une politique de sécurité pour les SICSS
Préambule
3.2.1.1 Scénario
15
Les trois étapes qui seront effectuées dans cette section sont : description d’un scénario représentatif,
identification des informations à protéger, et expression des objectifs de sécurité. Pour éviter toute
redendonce, la quatrième étape “définition des règles de sécurité” sera partiellement décrite ici, et sera
complétée dans les autres chapitres. La cinqième étape “modélisation formelle” sera présentée dans le
chapitre suivant.
63
Réseau de santé
Le concept de rôle est indispensable dans les systèmes d’information médicale. En effet, on
trouve les rôles médecin, infirmière, etc.
Les actions des SICSS peuvent être élémentaires (lire, écrire, etc.) ou composite. Par
exemple, l’action composite “prescrire” correspond à l’exécution des actions élémentaires :
lire les données de séjour hospitalier, consulter l’historique des prescriptions, lire le rapport
infirmier, lire les résultats d’examens, créer l’ordonnance et y écrire des données.
Plus général que la notion d’action composite, un processus de soins fournit le cadre dans
lequel les unités de soins interagissent pour traiter les patients. C’est donc une activité,
enregistrée dans le serveur, identifiée par un patient, un motif de consultation ou
d’hospitalisation, et une ou plusieurs équipes soignantes qui collaborent pour traiter le patient
[Clercq 1998] et [Deliège 2001]. Par exemple, un patient souffrant de douleurs abdominales
(problème) peut se présenter chez son médecin traitant qui fait une première évaluation et
initialise le processus de soins, avant d’envoyer le patient chez un spécialiste pour compléter et
finaliser le diagnostic. Le patient reviendra enfin chez son généraliste pour assurer un suivi du
traitement initié par le spécialiste. Le partage des données de santé de ce patient entre ces
64 Chapitre 3 Bâtir une politique de sécurité pour les SICSS
différents professionnels de santé s’effectue dans le cadre du processus de soins déclaré par le
médecin traitant et constitué des trois plans16 de soins.
Toute l’activité des professionnels de santé est organisée autour du patient. Son dossier
n’apparaît à un acteur de l’unité de soins que sous l’angle des besoins de sa tâche au sein de
l’organisation. Chaque acteur ne sera donc concerné que par certaines parties du dossier. Dans
la littérature, plusieurs types de dossiers ont été cités : le dossier hospitalier, le dossier de
spécialité, le dossier partageable, le dossier biologique, le dossier clinique, le dossier de
transmission, le dossier minimum européen, le dossier d’archives, etc. [Degoulet 1989]. Voici
les types de dossiers les plus importants :
- Le dossier de spécialité : il est très spécifique à l’unité de soins. Sa constitution tient
compte du plan de travail et des contraintes de l’unité à laquelle il appartient. Il existe une
grande variabilité dans son contenu et dans la façon dont il est utilisé.
- Le dossier partageable : ce dossier est dynamique (en cours d’élaboration). Il comprend
l’histoire médicale actuelle du patient (les problèmes actifs) ainsi que les résultats
provisoires et les avis temporaires. Il est le support permettant aux professionnels de santé
participant à un processus de soins, de communiquer et d’échanger des informations.
- Le dossier archive : après la fermeture de chaque processus de soins, le dossier archive est
alimenté par les résumés des dossiers partageables (seules les données objectives
concernant un patient font partie de son dossier et peuvent être conservées dans une base
de données médicales nominatives). Chaque résumé comprend, outre l’identification du
patient, des informations cliniques de synthèse, les pathologies diagnostiquées, les
traitements, la modalité de sortie et la façon dont le suivi de ce patient sera effectué. Ces
informations peuvent être structurées dans les résumés : clinique, infirmier, psychiatrique,
gériatrique, financier et social. Ainsi, contrairement au dossier partageable qui est
dynamique, le dossier archive est stable.
16
Un plan de soin peut être défini comme le résultat d’une consultation (ou d’une hospitalisation). Il
contient les commentaires, les traitements à suivre, etc.
65
3.2.1.4.1 Confidentialité
La confidentialité est à la fois liée au respect du secret professionnel des organismes de santé et
à la vie privée des patients :
- Le respect des données personnelles des patients (intimité) : il n’y a pas de traitement
médical sans confiance, de confiance sans confidence et de confidence sans secret. Ces
secrets ne doivent être confiés qu’aux utilisateurs autorisés. Ainsi, un utilisateur habilité à
66 Chapitre 3 Bâtir une politique de sécurité pour les SICSS
comptabiliser les traitements des médecins ou à faire des statistiques ne devrait pas avoir
le droit d’accéder aux données médicales nominatives des patients. Les utilisations des
données médicales à des fins non épidémiologiques (comme les publications scientifiques)
ne devraient pas permettre d’établir le lien entre les données publiées et la personne
physique concernée, etc.
- La confidentialité des intérêts professionnels : la confidentialité des informations est
d’abord pour les professionnels de santé une obligation personnelle de discrétion envers
les organisations auxquelles ils appartiennent (hôpitaux, organismes payeurs, etc.). Le
nouveau code de déontologie et les directives européennes précisent que ce secret est
absolu, sauf exception clairement définie par la loi.
3.2.1.4.2 Intégrité
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’évitement des collisions17 et des doublons18 lors de la génération de
pseudonymes.
L’obligation d’intégrité est d’abord définie par l’article 29 de la loi du 6 janvier 1978 [Loi
1978] qui enjoint au responsable du fichier de veiller à ce que les informations qui lui sont
confiées ne soient ni déformées ni endommagées. Cette obligation d’intégrité reconnaît
toutefois un droit de rectification. L’article 36 de la loi « informatique et libertés » affirme que
« le titulaire du droit d’accès peut exiger que soient... rectifiées ou effacées les informations le
concernant qui sont inexactes... ou dont la collecte... est interdite ». La charte du patient
hospitalisé ajoute : « le patient hospitalisé exprime ses observations sur les soins et l’accueil et
dispose du droit de demander réparation des préjudices qu’il estimerait avoir subi ». La loi [Loi
2002], relative aux droits des malades, confirme ces droits.
3.2.1.4.3 Disponibilité
L’indisponibilité des données (des patients) et des services est intolérable dans ce type de
systèmes où la vie des patients est en jeu. Le système d’information médicale peut être jugé en
danger, dès lors qu’une information existante peut être non disponible, suite à une défaillance
matérielle ou logicielle, à une suppression intentionnelle ou malveillante ou à une attaque en
déni de service. Dans ce domaine, la disponibilité concerne à la fois le caractère d’urgence et la
pérennité des données :
- La disponibilité à court terme (caractère d’urgence) : les fichiers des patients, les
programmes et les applications du système sont des ressources critiques qui peuvent, à un
moment donné, être invoquées, par plusieurs utilisateurs, et pour différentes raisons
(accomplissement des procédures médicales et administratives, étude de l’efficacité des
processus, etc.). Il est évident que ces ressources doivent être disponibles aux utilisateurs
autorisés. En cas d’urgence par exemple, le médecin du SAMU doit pouvoir y accéder, en
un temps raisonnable et sans rencontrer de problème d’accès ou de rupture du service
délivré par le système. De même, dans le cas de la télémédecine, la gestion de l’état de
santé du patient doit être immédiate alors qu’il s’agit d’échanger en toute protection des
données complexes comme des images, des enregistrements de cardiogrammes, etc.
- La disponibilité à long terme (pérennité) : le maintien à long terme des dossiers médicaux
est un problème primordial pour les systèmes d’information médicale. La CNIL
17
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).
18
Il y a doublon lorsque deux pseudonymes différents sont générés pour une même personne.
67
Figure 3.2 : Accès des catégories d’utilisateurs aux différents types de dossiers médicaux.
Par ailleurs, même si les utilisateurs d’un système d’information médicale doivent
communiquer, coopérer, échanger les informations, utiliser les applications et consulter les
bases de données, ils n’ont pas forcément les mêmes vues. D’une manière générale :
- Les médecins généralistes ont besoin de l’ensemble des données qui leur permettent de
gérer les aspects médicaux des cas qu’ils traitent. Ils peuvent visualiser les diagnostics
antérieurs ainsi que les rapports infirmiers. Ils ont aussi le droit d’éditer le rapport de
consultation.
- Les spécialistes doivent avoir l’accès aux détails relevant de leurs spécialités.
- Le personnel infirmier ne doit pas avoir le droit de prescrire de médicaments, ni le droit
d’accéder à certaines données dépassant les limites de leur rôle dans le système.
Néanmoins, ils ont le droit de rédiger le rapport infirmier.
68 Chapitre 3 Bâtir une politique de sécurité pour les SICSS
- Les pharmaciens doivent pouvoir accéder à la liste des médicaments prescrits, ainsi qu’à
l’historique des prescriptions. Ils n’ont le droit de modifier les ordonnances que pour
substituer un médicament par le générique correspondant. Tout accès s’inscrivant dans
cette exception doit être audité.
Aussi, pouvons-nous déduire que le rôle est certainement l’un des paramètres qui intervient
pour décider quelle partie du dossier est accessible par quel utilisateur. À titre d’exemple, le
médecin traitant (psychologue, gynécologue) est le seul à posséder une partie privée
(commentaire) où il met les données intimes que le patient ne veut pas partager avec une tierce
personne. Cette partie n’est donc accessible que par le médecin et son patient. La figure 3.3
montre l’exemple d’une équipe composée d’un médecin, d’une infirmière et d’une secrétaire
médicale. Le sens de la flèche indique le sens du flux d’informations : « Médecin ‡
Commentaires » indique un accès autorisé en écriture du médecin à la partie
« commentaires » ; « Médecin fl Commentaires » indique un accès autorisé en lecture du
médecin à « commentaires ». L’accès au dossier archive n’est autorisé qu’en lecture dans la
mesure où l’alimentation du dossier archive se fait automatiquement après la fermeture de
chaque processus de soins. Les parties composant le dossier de spécialité diffèrent d’une
équipe à une autre.
D’autres règles d’accès peuvent être déduites directement des textes et loi relatifs aux SICSS.
Par exemple, le texte [BCN 1999] indique que « les opérations de soins ne sont permises
qu’aux utilisateurs qui sont personnels soignants ». La loi [Loi 2002] et son décret
d’application [Décret 2002] donnent au patient le droit de lire son dossier médical : « toute
personne a accès à l’ensemble des informations concernant sa santé … elle peut accéder à ces
informations directement ou indirectement par l’intermédiaire d’un médecin et en obtenir
communication … La présence d’une tierce personne lors de la consultation de certaines
informations peut être recommandée par le médecin …, pour des motifs tenant au risques que
leur connaissance sans accompagnement ferait courir à la personne concernée ». À partir de
cette loi, il est possible de définir des règles de sécurité utilisant une modalité de
recommandation, par exemple :
- il est recommandé que le patient accède à son dossier médical à travers son médecin
traitant ;
- si le patient est mineur ou souffrant de troubles mentaux ou psychologiques, la présence du
tuteur est recommandée.
69
En effet, le médecin est la personne la mieux placée pour comprendre le codage et pour
expliquer le contenu du dossier médical soit à son patient (si son état le permet), soit au tuteur
(dans des conditions bien précises).
Ces règles seront complétées et formalisées dans le cinquième chapitre.
Entreprises
INTERNET
Net-Déclaration 2
OPS 2
http://www.net-entreprises.fr
Net-Déclaration 3
OPS n
Net-Déclaration n
- établissement adhérent : c’est l’établissement qui va utiliser Net-entreprises pour saisir ses
propres déclarations ou le tiers déclarant qui saisit les déclarations d’autres entreprises.
3.2.2.1.2.3 Administrateur
L’administrateur gère les inscriptions pour l’établissement adhérent dont il dépend, sous la
responsabilité du dirigeant de l’établissement. Il s’occupe de la définition :
- des personnes autorisées à utiliser les sites et les services ;
- des services qui seront utilisés ;
- des droits de chaque personne, autorisée pour utiliser des services Net-entreprises.
Accueil
téléphonique
net-xxx
CAT
n
tr atio
m inis
Ad
Primo - inscription
MODULE DE BASE Liste de
révocation
Modification
Site Portail
Accès aux & SIRENE
déclarations Inscription
Abonnement -
Désabonnement REFERENTIELS
Autorité de certification
Notariat technique
web
Push-mail
Courriers
Mails
3.2.2.2.2.2 La primo-inscription
C’est l’inscription du premier administrateur rattaché à un établissement donné. Elle induit
l’adhésion de son établissement à Net-entreprises en fournissant le numéro SIRET de
l’établissement de l’administrateur. L’administrateur spécifie s’il souhaite être déclarant pour
le compte d’un autre établissement en tant qu’établissement de la même entreprise ou en tant
que tiers-déclarant.
3.2.2.3.1.1 Disponibilit
Composant Menace Quelques solutions
Poste de travail de Incompatibilité avec le site ou le Compatibilités des services
l’utilisateur. navigateur du téléservice ; Défaillance selon les systèmes, les
ponctuelle : panne, virus, etc. navigateurs et les versions.
Accès d e Panne modem, impossibilité de se
l’utilisateur à connecter ; indisponibilité du
Internet fournisseur.
75
Quelques règles, relatives à la disponibilité, extraites des conditions d’adhésion aux services
de Net-entreprises peuvent être ajoutées :
- (Article 7) : les données relatives aux télédéclarations sont conservées conformément aux
dispositions légales et conformément aux règles spécifiques à chaque déclaration. Sauf
stipulation contraire et conformément aux règles spécifiques à chaque déclaration, le «
déclarant » pourra consulter par l’intermédiaire de Net-entreprises les données concernant
les télédéclarations préalablement effectuées et pour lesquelles il est inscrit.
- (Article 9) : le service est accessible sept jours sur sept et 24 heures sur 24 pour
l’inscription et les déclarations événementielles, et dans le respect des calendriers
déclaratifs spécifiques à chaque déclaration à échéance. Toute défaillance relevant du site-
portail ou du site déclaratif se traduit par l’émission d’un message indiquant à l’utilisateur
l’indisponibilité du service ou le non-enregistrement des informations saisies. En pareil
cas, celui-ci doit effectuer une nouvelle tentative ou accomplir ses obligations pour la date
limite d’exigibilité par les moyens traditionnels.
76 Chapitre 3 Bâtir une politique de sécurité pour les SICSS
3.2.2.3.1.2 Confidentialité
Information sensible Menace Solutions
Accès en aval : Divulgation, à travers le Contrôle d’accès ; échanges
Informations nominatives téléservice, des informations sécurisés entre le déclarant et le
de nature industrielle ou sensibles à des personnes serveur, par exemple avec des
commerciale comme le externes non mécanismes comme SSL ou
numéro SIRET d’un habilitées (externes au TSL.
travailleur indépendant, système).
les données médicales ; Divulgation par le téléservice Gestion des habilitations avec
Accès en aval : les des informations sensibles à une séparation entre l’identité
salaires des cadres, les des personnes internes non de la personne et le contrôle
données soumises au habilitées ; vol de privilèges ; des droits. Possibilité d’utiliser
secret professionnel. abus de privilèges. des certificats d’attribut accolés
à un certificat de signature.
Confidentialité des mots Perte, divulgation ou vol des Utilisation de moyens matériels
de passe d e mots de passe. (cartes à puce, par exemple)
l’administrateur et des et/ou biométriques
déclarants
Tableau 3.3 : Menaces pouvant porter atteinte à la confidentialité dans le social.
3.2.2.3.1.3 Intégrité
Information à protéger Risque Solution
Information Non-conformité. Contrôle syntaxique ; tout rejet
communiquée à dû à un contrôle doit entraîner
l’application (c’est-à-dire, une alerte de l’utilisateur avec
saisie par l’utilisateur) une demande de correction.
Information qui transite Altération non autorisée Contrôle d’accès ; chiffrement ;
par le réseau etc.
Services et programmes C o n t o u r n e m e n t o u Contrôle d’accès ; signatures ;
offerts par N e t - modification non légitime tests d’intégrité et certification.
entreprises. de la part de l’utilisateur
Tableau 3.4 : Menaces pouvant porter atteinte à l’intégrité dans le social.
3.2.2.3.1.4 Responsabilité
La question de responsabilité dans les téléprocédures est liée à de multiples facteurs : les
textes juridiques en vigueur, les besoins fonctionnels des partenaires au téléservice, les
77
personnes autorisées n’intéressent pas les dirigeants alors qu’elles peuvent intéresser les
administrateurs (protection de la vie privée). Dans ce cas, un dirigeant verra l’historique des
modifications survenues dans son entreprise à l’exception de ces informations.
19
La reconnaissance physique est utilisée dans le sens de rétablissement de la correspondance entre les
identifiants et les personnes physiques.
79
(en l’occurrence, les identifiants) même si le destinataire est légitime. Par exemple, garder
l’anonymat total à l’égard des assurés ou des ayants-droit lors de publications scientifiques, ou
lors de la transmission des informations relatives à l’activité des médecins libéraux vers les
Unions Professionnelles (assemblées de médecins élus par région ou regroupés en sections). Si
le but est de pouvoir effectuer des trajectoires de soins, c’est-à-dire, avoir un suivi permanent
des évolutions des maladies, on utilise un code anonyme, mais toujours le même pour un
patient donné. Enfin, il est parfois souhaitable qu’une autorité puisse croiser les données
anonymisées avec d’autres données anonymes concernant le même individu, ou même lever
l’anonymat dans des cas bien particuliers. Par exemple, dans le cas des études
épidémiologiques, les corrélations entre plusieurs pathologies peuvent nécessiter de remonter
aux identités réelles pour compléter a posteriori les données recueillies antérieurement, et ainsi
affiner ces études.
Notons que, compte tenu des caractéristiques des différents scénarios d’anonymisation, la
méthodologie utilisée dans cette section est légèrement différente de celle appliquée dans les
deux premières études de cas. Ainsi, nous procédons selon les étapes suivantes :
- d’abord, définition de la base terminologique associée au thème “anonymisation” ;
- puis discussion des différentes solutions d’anonymisation utilisées dans les pays
européens ;
- ensuite, définition d’un ensemble de scénarios relatifs au thème d’anonymisation ;
- enfin, pour chacun de ces scénarios, construction d’une démarche d’analyse des besoins :
identification des besoins, objectifs et exigences de sécurité et, dans la mesure du possible,
choix de solutions adaptées.
Un besoin d’anonymisation représente les attentes de l’utilisateur (pas toujours très bien
explicitées). Un objectif d’anonymisation spécifie le niveau de sécurité à atteindre ou les
menaces à éviter (comment satisfaire les exigences ?). Une exigence d’anonymisation
représente la façon d’exprimer le besoin (dans la mesure du possible, très proche d’un
formalisme clair et d’une sémantique non-ambiguë).
Même si tous les scénarios que nous évoquons dans cette section sont extraits du domaine
médical, les besoins d’anonymisation de certaines données sensibles concernant des personnes
ou des entreprises est également un point crucial. La méthodologie que nous proposons pour
l’analyse de la procédure d’anonymisation peut être appliquée aux systèmes de santé, mais
aussi à d’autres secteurs, notamment les secteurs social, bancaire, militaire, etc.
- réversibilité : cacher les données par un simple chiffrement des données. Dans ce cas, il y
a possibilité de remonter depuis les données chiffrées jusqu’aux données nominatives
originelles.
- irréversibilité : c’est le cas réel de l’anonymisation ; une fois remplacés par des
identifiants anonymes, les identifiants nominatifs originels ne sont plus recouvrables ;
cependant, avec les techniques d’attaques par inférence20, les identifiants anonymes, s’ils
sont trop universellement utilisés, risquent de permettre la découverte d’identités mal
cachées, comme on l’explique ci-après ; pour ce type d’anonymisation, la technique
communément utilisée est une fonction de hachage ;
- inversibilité : c’est un cas mixte entre réversibilité et irréversibilité, c’est-à-dire entre le
“techniquement ou cryptographiquement irréversible” et le “organisationnellement et
juridiquement réversible” ; autrement dit, il est impossible en pratique de remonter aux
données nominatives, sauf en appliquant une procédure exceptionnelle sous surveillance
d’une instance légitime (médecin-conseil, médecin inspecteur) garante du respect de la vie
privée des individus concernés ; il s’agit cette fois-ci d’une pseudonymisation au sens des
critères communs.
20
Une inférence est la découverte de données confidentielles non directement accessibles, rendue
possible par la mise en correspondance de plusieurs données légitimement accessibles, révélant tout ou
partie des informations relatives à une personne.
21
Par environnement informatique du système, on entend l’ensemble des utilisateurs, la nature des
attaquants et les types des attaques.
81
raisonnement pourrait ête complété en faisant des hypothèses sur certaines informations,
par exemple, “et s’il avait un cancer, cela expliquerait pourquoi il s’absente du Conseil des
Ministres pour se rendre à l’hôpital Paul Brousse de Villejuif …”.
- probabiliste (ou adductive) : elle parvient à estimer la vraisemblance d’une information
sensible en utilisant les informations accessibles, par exemple, “puisque P est traité à
l’hôpital H, et puisque H est spécialisé dans les maladies M1 et M 2, et puisque à son âge, la
probabilité d’avoir M1 est très faible (10%), alors on peut déduire qu’à 90%, P est atteint
de M2”.
Cette liste n’est pas exhaustive et on peut naturellement imaginer d’autres types de canaux
d’inférence fondés sur d’autres types de raisonnement, tel que le raisonnement par évidence ou
par analogie.
Pour faire face à ce type de menaces et protéger les données personnelles, divers pays se sont
intéressés aux fonctions d’anonymisation des données médicales utilisées à des fins non
directement épidémiologiques.
Réseau des cas de chaînage
d’anonymisations irréversibles
oire
Hist
Perdu
Nullité Opaque Coordonné Coopératif
Ponctuel Unique
Jamais
Dans une attaque par dictionnaire, Bob pourrait appliquer l’algorithme de hachage à une liste
de variables identifiantes (dictionnaire) pour disposer d’une table Tid-Num reliant des variables
identifiantes à des codes anonymes. En faisant un simple rapprochement entre la base de
données médicales anonymes et la table, il pourrait facilement déduire les informations
médicales des personnes dont les noms figurent sur son dictionnaire (figure 3.7).
BDMA
NAi Dmédi
TId-NA
Dictionnaire Dictionnaire de noms Identifiant Anonyme
Application de l’algorithme
Nom1 Nom1 NA1
de Hachage
… …
l’autre côté de la communication, les informations reçues par le DIM sont hachées par le même
algorithme mais avec une seconde clé k2, qui n’est pas communiquée aux hôpitaux : empreinte2
= H(k2 + empreinte1) (voir figure 3.8).
Transmetteur Service chargé du traitement (DIM)
Figure 3.8 : Procédure de double hachage des informations traitées par le DIM.
- le secret k est l’ensemble des coefficients du polynôme : (a0, a1, .., as-1). La figure 3.9
présente un exemple avec s=2 (P(x) = a0 + a1x).
K1 K1
K2 K2 x
. Ks
x
. K2
Fragmentation Dissémination x
K Redondance Ks Ks K1
KN KN
Images conservées
Secret Copies Reconstitution du secret
sur supports distincts
Les images de la clé secrète sont disséminées sur un nombre de supports distincts. La
première image sera placée dans la fonction d’anonymisation (dans le logiciel distribué aux
transmetteurs d’informations), les autres sont données à des personnes de confiance, comme le
responsable de l’application ou le directeur de la CNAM. Ainsi, même s’il existe N images
(fragments) de la clé, la présence de “s -1” personnes de confiance est suffisante pour
reconstituer le secret (figure 3.10).
Comme en Bourgogne, et pour se prémunir contre toute attaque ponctuelle ou par
dictionnaire, la fonction d’anonymisation FOIN est utilisée à deux niveaux : une première fois
dans les hôpitaux, avant de transmettre les données médicales des patients et une deuxième
fois, avant l’archivage de ces données.
Image 2 Image S
De la clé … De la clé
Image 1
Données nominatives De la clé
Procédure de reconstitution
de la clé secrète
Clé secrète
Procédure d’anonymisation
Hachage
Identifiant anonyme
temps. Le choix s’est porté sur un ensemble minimal d’identifiants : la date de naissance, le
sexe, le nom et le prénom.
Puisque la transformation cryptographique doit être appliquée tout le temps et par tous les
hôpitaux, l’utilisation d’une clé secrète n’est pas la solution la mieux adaptée. À l’inverse,
l’utilisation des empreintes22 (hachage des données identifiantes) satisfait mieux ces objectifs,
avec l’inconvénient de ne pas résister aux attaques par dictionnaires. Il convient donc de
chiffrer les données d’identité, d’abord durant la transmission de l’hôpital à l’OFS, ensuite
dans les bases de données. Les étapes de cette procédure sont les suivantes (figure 3.11) :
- Hachage des variables identifiantes : Hachage[Var-ID] = Empreinte.
- Génération en arrière-plan (dans l’ordinateur de l’hôpital) d’une clé de session : c.
- Chiffrement de l’empreinte avec IDEA en employant c : IDEA[Empreinte] c ; et
chiffrement de c par la clé publique de l’OFS, (notée E) en utilisant l’algorithme RSA :
RSA[c]E.
- Transmission de la clé de session (chiffrée), de l’empreinte (chiffrée) et des données
médicales (chiffrées) à l’OFS.
- À la réception, déchiffrement de la clé secrète (de session) c par RSA en employant la clé
privée de l’OFS notée “D” ;
- Déchiffrement de l’empreinte (avec IDEA et la clé c), et re-chiffrement de cette empreinte
avec une clé k (fragmentée) pour donner le lien anonyme utilisé comme code personnel
(code de liaison uniforme) lors du stockage des données médicales au niveau de l’OFS.
22
Rappelons qu’une empreinte a été définie dans la section 3.2.3.4.1 (page 81) comme étant un code
anonyme qui varie d’une identité à une autre mais qui est toujours le même pour un patient donné.
87
- les données transmises sont chiffrées dans la solution suisse, tandis qu’elles ne le sont pas
dans FOIN ;
- FOIN utilise la technique Fragmentation-Redondance-Dissémination qui vise, non
seulement la confidentialité et l’intégrité, mais aussi la disponibilité. Dans la procédure
suisse, même si K est fragmentée en plusieurs parties, elle ne peut être reconstituée qu’en
présence de toutes les personnes disposant de ces fragments (de K). La reconstitution est
faite par un simple ou exclusif “K = K1 ⊕ .. ⊕ KN” C’est donc un cas particulier de FOIN,
où on considère N = s (seuil de reconstitution).
Par ailleurs, les trois opérations effectuées au niveau de l’OFS (retrouver la clé secrète c,
retrouver l’empreinte, et chiffrement avant archivage) ne doivent jamais être visibles aux
utilisateurs de l’OFS. Cependant, comment s’assurer qu’elles ne sont jamais enregistrées sur
aucun support ? Un cheval de Troie opérant pour une personne malveillante, aussi bien interne
qu’externe, pourrait récupérer les valeurs de la clé secrète c ou des empreintes, et effectuer par
la suite une attaque par dictionnaire. Pour pallier ce type de risques, nous pensons que ces
étapes (phase de calcul) doivent être faites par un module matériel bien protégé. Des
mécanismes inviolables de contrôle d’accès, éventuellement matériels, pourront renforcer la
protection de ce module de façon à ce que seules les personnes de confiance puissent réaliser
l’opération composite calcul ; le serveur d’autorisation leur donne les droits correspondants
sans qu’elles puissent lire ou copier, ni l’empreinte, ni les clés secrètes K et c ; des droits
distribués sont donnés aux composants matériels ; chaque composant effectue les opérations
qui lui sont destinées.
Cette analyse montre, les avantages et les faiblesses de chacune des solutions actuelles et
renforce notre volonté d’une démarche analytique préalable des risques, des besoins, des
exigences ainsi que des objectifs de sécurité, avant de recourir aux solutions de sécurité
assurant l’anonymisation. Complétons ainsi cette analyse par une étude détaillée d’un ensemble
de scénarios du domaine médical.
Département d’Information
Médicale (DIM)
Validation
Médecins conseils (sécurité sociale) externe
Étant donné que la finalité du PMSI est purement médico-économique (et non pas
directement épidémiologique), le besoin est de pouvoir effectuer des trajectoires de soins par le
biais d’une pseudonymisation ; l’objectif est une anonymisation irréversible ; et les exigences
sont un chaînage universel (toujours et partout le même identifiant pour un patient donné) ainsi
que la robustesse à la réversion et aux inférences (déductives, inductives, abductives, etc.).
23
Il existe des fichiers directement nominatifs, comportant des informations relatives à des personnes
séropositives, qu’il s’agisse des dossiers médicaux tenus dans les services hospitaliers, les cabinets
médicaux, ou les laboratoires, des fichiers de remboursement détenus par les organismes de sécurité
sociale ou encore des fichiers constitués par les associations d’aides aux personnes séropositives.
Notons toutefois qu’il existe des centres de dépistage anonymes dans lesquels il n’y a aucune possibilité
de retrouver les identités des personnes séropositives.
91
Le tableau 3.6 donne l’exemple d’instance de la relation Analyse que nous considérerons
dans la suite.
Patient H/F Age Mutuelle Leucocyte
Dupont H 30 MMA 6000
Durand F 25 LMDE 3000
Dulac F 35 MMA 7000
Duval H 45 IPECA 5500
Dubois H 55 MGEN 3500
Dumont H 38 MMA 7500
Dupré F 32 IPECA 7200
Dupuis F 50 MGEN 6800
Dufour H 45 MAAF 4000
Dumas H 40 Rempart 3800
Une base de données statistiques (dans le contexte de la sécurité) est une base de données qui
permet d’évaluer des requêtes qui dérivent des informations d’agrégation (par exemple, les
moyennes) mais pas des requêtes qui dérivent des informations particulières, en l’occurrence,
des informations relatives à une personne donnée. Par exemple, si on considère la relation
présentée dans le tableau 3.10, la requête “quelle est la moyenne du taux de leucocytes des
patients ayant plus de 30 ans ?” va être permise alors que la requête “quel est le taux de
leucocytes de Dupont ?” ne le sera pas.
Le problème associé à ce type de base de données réside en ce qu’il est souvent possible de
faire des inférences à partir de requêtes autorisées pour déduire des réponses à des requêtes qui
ne le seraient pas. Comme en fait état [Denning 1979] : « les statistiques contiennent des traces
des informations initiales ; un espion sera capable de reconstruire ces informations par le
traitement d’un nombre suffisant de statistiques ». C’est un cas particulier important de
déduction d’informations sensibles par inférence.
Supposons, par exemple, qu’un utilisateur U soit autorisé à effectuer des requêtes statistiques
(uniquement) et envisage de découvrir le taux de leucocyte de Dubois. Supposons également
que U sache par ailleurs que Dubois est un adhérent masculin de la MGEN. Considérons
maintenant les requêtes 1 et 2 suivantes :
1) SELECT COUNT (Patient)
FROM Analyse
WHERE H/F = ‘H’ AND Mutuelle = ‘MGEN’ ;
Résultat : 1.
de la relation initiale) parce que la compromission ci-dessus peut également être obtenue à
partir de la suite de requêtes 3-6 suivantes :
situations, il faudra remonter aux identités réelles pour que les patients puissent profiter de ces
résultats. Il s’agit ainsi d’une anonymisation inversible, c’est-à-dire un chiffrement avec une
clé (secrète), de telle sorte que seules des personnes habilitées à lever l’anonymat (médecins
conseils, médecins inspecteurs, médecins traitants) détiennent la clé de déchiffrement, et
seulement quand c’est nécessaire (figure 3.15).
Dans le cas des protocoles de recherche sur le cancer, le processus commence par un typage
(stade de la maladie), puis par une identification du protocole correspondant au patient (s’il
existe), enfin, selon le protocole, le patient est enregistré dans un registre régional, national,
voire international. Les études épidémiologiques et statistiques faites sur ces registres peuvent
dégager de nouveaux résultats concernant les patients d’un certain protocole. Dans le but de
raffiner les études et faire avancer la recherche scientifique, il est parfois utile de remonter aux
identités réelles des patients pour les identifier, faire des recoupements entre plusieurs données
déjà recueillies, et les compléter a posteriori.
Dans le cas de maladies génétiques, les études se font sur des données médicales
anonymisées. Toutefois, si de nouveaux résultats sont découverts, il est envisageable de
remonter aux identités des patients, voire de leurs familles pour leur faire de nouveaux tests, ou
de leur faire suivre de nouveaux traitements. Le principe est le même pour les maladies
orphelines.
Détaillons les traitements effectués ainsi que les vues disponibles au niveau des hôpitaux, des
centres de traitements et des utilisateurs finaux.
24
Même si la carte Vitale appartient à l’assuré et donc peut correspondre à plusieurs personnes
(l’assuré et ses ayants-droits), l’identifiant IDpat est individuel. Dès lors, sur une même carte peuvent
figurer plusieurs identifiants correspondants à l’assuré et aux ayants-droit de moins de seize ans. Ceci
sous entend un dispositif de classification de ces identifiants (par numéro d’ordre par exemple).
96 Chapitre 3 Bâtir une politique de sécurité pour les SICSS
par la base de donnée) à la carte ; celle-ci contient déjà IDpat (l’identité du patient donnant son
consentement pour l’exploitation de ses données médicales par le projet). La procédure T1
consiste à appliquer une fonction de hachage (MD5 ou SHA par exemple) à (IDproj | IDpat), la
concaténation de IDproj) et IDpat :
Si on reprend le scénario précédent, l’utilisateur malveillant Bob ne peut revenir aux identités
des personnes car il ne dispose pas de la clé de déchiffrement KpPurpan. En effet, chaque hôpital
détient sa clé Kshôp, tandis que Kphôp n’est détenue que par les projets.
97
Les deux transformations (T1 et T2), effectuées au niveau des hôpitaux, permettent d’avoir
une grande robustesse vis-à-vis d’attaques ayant pour but de lever l’anonymat (ou de faire des
rapprochements) de façon non autorisée. Pour autant, la procédure proposée reste assez
flexible. En effet, si deux hôpitaux (hôpa et hôpb) décident de fusionner un jour, il est tout à fait
possible de relier les données concernant chaque patient ; que ces données proviennent de hôpa
ou de hôpb.
Il suffit que chaque hôpital déchiffre ses données avec sa clé “Kphôp”, puis chiffre le résultat
avec la clé privée K s h ô pab du nouvel hôpital. Si I D Ahôpa(pat|Proj) (respectivement
IDAhôpb(pat|Proj)) désigne un identifiant anonyme au sein de l’hôpital hôpa (respectivement
hôpb) ; “[]K” désignant le déchiffrement avec la clé K :
- Le traitement effectué sur les anciennes données de l’hôpital hôpa est :
{ [IDAhôpa(pat|Proj)] Kphôpa} Kshôpab ;
- Le traitement effectué sur les anciennes données de l’hôpital hôpb est,
{ [IDAhôpb(pat|Proj)] Kphôpb} Kshôpab ;
Ainsi, les codes de liaisons obtenus seront les mêmes dans les deux établissements (pour
chaque base de donnée anonyme associé à un certain projet).
Pour les utilisateurs internes aux établissements de soins, les mécanismes de contrôles
d’accès doivent interdire tout accès non-autorisé, tandis que des mécanismes de détection et de
tolérance aux intrusions doivent renforcer les autres mesures de sécurité.
3.2.3.11.4 Discussion
La solution que nous proposons garantit les points suivants :
- le patient doit donner explicitement son consentement pour toute utilisation non-
obligatoire, mais souhaitable, de ses données ;
- les clés et identifiants utilisés dans les diverses transformations (ID proj , ID pat , Ks hôp ,
Kphôp, IDApat|Proj et IDApat|util) sont détenus par des personnes différentes, et dans des
endroits différents : IDproj ne concerne qu’un projet parmi d’autres ; IDpat est spécifique à
un patient, et cette information n’est connue que par lui ; Kshôp est spécifique à l’hôpital ;
et IDApat|util n’est destinée qu’à un utilisateur (ou type d’utilisateur) d’un projet donné. Il
est donc pratiquement impossible de pouvoir faire des désanonymisations non autorisées ;
- la solution résiste aux attaques par dictionnaire et à tous les niveaux : établissements de
soins, centres de traitements, et utilisateurs finals ;
- la séquence d’anonymisation (anonymisation en cascade) que nous proposons à différents
niveaux, combinée avec des mécanismes de contrôles d’accès, permet de garantir, en toute
robustesse, l’exigence de non inversibilité ;
- les identifiants anonymes générés étant spécifiques à un secteur particulier (projet,
domaine d’activité, centre d’intérêt, branche professionnelle, établissement, etc.), il est
possible d’adapter la solution à chaque secteur (par exemple lorsque le centre de traitement
est le seul utilisateur) ;
- il est possible de fusionner les données de deux (voire de plusieurs) établissements sans
compromettre la flexibilité et la sécurité ;
- la manière selon laquelle l’information est distribuée et utilisée par l’utilisateur final est
importante. Notre solution peut être adoptée pour tenir compte de la finalité du traitement ;
- si un utilisateur final (chercheur dans le domaine des maladies orphelines par exemple)
découvre une information qui nécessiterait de remonter aux identités des patients, il doit
renvoyer ses résultats à l’hôpital qui, lui seul (par l’intermédiaire du professionnel soignant
par exemple), peut établir le lien entre les variables identifiantes, les numéros locaux de
séjours, et les données médicales de ses patients.
Par ailleurs, nous pensons que la solution idéale n’existe pas, et nous suggérons de compléter
notre solution, selon le cas étudié, par une combinaison de solutions techniques et
organisationnelles :
- l’accès aux données doit être parfaitement contrôlé. Une politique de contrôle d’accès doit
être définie et mise en place pour que les données ne soient accessibles qu’aux seuls
utilisateurs habilités ;
- la spécification du système d’information et de l’architecture du réseau doit obéir à une
politique globale de sécurité, et donc doit être adaptée aux besoins ;
- La définition de la politique de sécurité doit inclure une analyse approfondie des risques
d’abduction ;
- la constitution de sous-bases de données régionales ou thématiques doit être contrôlée.
- Il convient d’utiliser (si cela est possible) des anonymisations thématiques, de sorte que
même si un utilisateur parvient à casser l’anonymisation, les risques d’abduction soient
limités à un thème donné ;
- Il faut séparer les données d’identité des renseignements proprement médicaux. Bien
entendu ce mécanisme ne peut être appliqué que dans des contextes particuliers. Un
exemple est donné dans l’annexe B ;
99
Préambule
Dans le chapitre précédent, nous avons proposé une méthode permettant de définir une
politique de sécurité pour des organisations complexes en général et pour les SICSS en
particulier. Nous avons appliqué notre méthodologie à différents scénarios des domaines social
et médical. Nous avons également exprimé le besoin de modéliser la politique de sécurité,
notamment pour contribuer au processus de preuve et de vérification, nécessaire pour avoir une
confiance élevée dans le système.
Après avoir rappelé les lacunes des politiques et modèles de sécurité existants, ce chapitre
commence par présenter les concepts nécessaires pour exprimer des politiques de sécurité pour
des systèmes complexes, coopératifs et distribués comme les SICSS. Le but étant de :
- tenir compte du contexte et de l’interopérabilité,
- prendre en compte toute amélioration, changement ou mise à jour des éléments en relation
avec la sécurité,
- réaliser 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, tout en
respectant les droits des usagers.
Ensuite, nous imbriquons ces concepts pour construire le modèle Or-BAC, dont une
représentation entité-relation a été développée dans le cadre du projet MP6 [Abou El Kalam et
al. 2003a]. Le concept d’organisation est central dans Or-BAC. Celui-ci n’utilise que des
entités abstraites pour exprimer la politique de sécurité, sans se soucier la manière selon
laquelle les différentes sous-organisations implémentent et instancient ces entités (rôles,
groupes, activités, contexte). Cette façon de procéder réduit considérablement la complexité de
la spécification de la politique de sécurité, offre plus de flexibilité et facilite l’interopérabilité
des composants du système ou de l’organisation, sans pour autant compromettre la sécurité.
Par ailleurs, Or-BAC n’est pas restreint aux permissions, mais permet également de définir des
interdictions, des obligations et des recommandations.
La deuxième partie de ce chapitre présente le modèle Or-BAC en utilisant une notation UML
[Abou El Kalam & Deswarte 2004].
102 Chapitre 4 Le modèle Or-BAC
4.1. Motivation
Les politiques et modèles de sécurité qui existent dans la littérature (et que nous avons décrits
dans le chapitre précèdent) ne prennent pas en compte les points suivants :
- des règles qui spécifient des permissions ou des interdictions contextuelles ; pourtant, dans
le domaine médical, les professionnels de santé ont des permissions spéciales dans des
contextes spécifiques comme l’urgence ; de même, les personnes autorisées peuvent, dans
certains cas (échéance par exemple), forcer l’accès à Net-entreprises, pour préparer ou
valider les déclarations, ou pour effectuer des télépaiements ;
- des règles qui spécifient des obligations ou des recommandations : les modèles et
politiques de contrôle d’accès classiques sont généralement limités aux permissions ;
certains incluent des interdictions, et plus récemment quelques modèles de politique de
sécurité ont ajouté des obligations [Bettini et al. 2002, Damianou et al. 2001] ; dans les
SICSS, il convient aussi de prendre en compte des recommandations ;
- des règles spécifiques à l’organisation ; en particulier, l’organisation peut être structurée en
plusieurs sous-organisations, qui ont chacune leur propre politique de sécurité : le système
de santé est organisé en plusieurs domaines (médical, paramédical, recherche, etc.), le
domaine médical regroupe les hôpitaux, les cliniques et les médecins libéraux, chaque
hôpital est organisé en services, etc. ; la politique de sécurité devra ainsi proposer un cadre
homogène, permettant de spécifier plusieurs politiques de sécurité au sein d’une même
organisation ; il est évident que chaque structure de la sphère santé-social doit implémenter
sa propre politique interne de sécurité tout en respectant l’ensemble des contraintes
imposées par la politique globale de sécurité.
La section suivante présente un ensemble de concepts permettant de spécifier une politique
de sécurité capable de prendre en compte ces différents points, et supporter ainsi la richesse, la
complexité et l’hétérogénéité des SICSS.
En outre, nous tenons à préciser que ce mémoire ne décrit pas la version initiale du modèle
Or-BAC (représentation entité-relation, et logique du premier ordre), à laquelle nous avons
contribué dans le cadre du projet MP6 [Abou El Kalam et al. 2003a ; Abou El Kalam et al.
2003b]. En revanche une version qui utilise UML et la logique déontique [Abou El Kalam &
Deswarte 2004] sera présentée ici. Celle-ci nous semble plus détaillée et plus riche en
expressivité.
4.2.1. Organisations
L’organisation est l’entité centrale des politiques et modèles de sécurité que nous proposons.
Dans le domaine médical, nous pouvons considérer les organisations : “clinique du
Languedoc”, “équipe de l’unité des soins intensifs de l’hôpital Rangueil”, etc. De la même
manière, dans le secteur social, les établissements, les entreprises ainsi que les organismes de
protection sociale, sont des exemples d’organisations. Une organisation peut être définie
comme une entité ayant un rôle professionnel ou statutaire bien défini, ou encore, un groupe
structuré d’entités actives, c’est-à-dire de sujets (utilisateurs, équipes, ou autres) jouant certains
rôles (figure 4.1).
Il est important de noter qu’un groupe quelconque de sujets n’est pas nécessairement
considéré comme une organisation. Autrement dit, le fait que chaque sujet joue un rôle dans
l’organisation correspond à un certain accord entre les sujets pour former une organisation.
103
La figure 4.1 exprime que les utilisateurs et les organisations sont considérés comme des
sujets (entités actives), et qu’ils peuvent à ce titre, jouer des rôles. La figure 4.2 donne
l’exemple d’un utilisateur Jean qui joue le rôle “cardiologue”, et de l’organisation US21 qui
joue le rôle “unité de soins intensifs”. De la même manière, dans le cadre de Net-entreprises,
les rôles “personne inscrite”, “personne non-inscrite”, “administrateur”, “mandataire social”,
“dirigeant” et “personne autorisée”, sont joués par des utilisateurs, tandis que les rôles
“établissement déclaré”, “tiers déclarant” sont joués par des organisations.
joue
Sujet Rôle
Utilisateur Organisation
joue
Jean : Utilisateur :: Sujet Cardiologue : Rôle
joue
US21 : Organisation :: Sujet Unité de soins intensifs : Rôle
Figure 4.2 : Ébauche d’un diagramme d’objets représentant les rôles joués par les sujets.
InfirmierDansPurpan AssistantDansRangueil
Pierre:Utilisateur Pierre:Utilisateur
:RdO :RdO
Nous avons fait le choix de représenter l’entité RdO par une classe-association. En effet,
d’une part, un RdO est une association entre le rôle et l’organisation, et d’autre part, il a des
attributs, notamment les identifiants du rôle et de l’organisation. Un RdO possède les
caractéristiques d’une classe et d’une association, et peut à ce titre, participer à d’autres
relations, en l’occurrence la relation qui associe les utilisateurs aux RdO (figure 4.4).
104 Chapitre 4 Le modèle Or-BAC
Rôle Organisation
RdO
Id_Organisation
Joue
0..n 0..n
Utilisateur Id_Rôle
…
Dans la mesure où les vues caractérisent la manière dont les objets sont utilisés dans
l’organisation, nous introduisons la classe-association “Vue dans Organisation”, notée VdO, et
nous associons les objets aux VdO (figure 4.6).
Vue Organisation
VdO
Id_Organisation
0..n 0..n
Objet Id_Vue
…
Cette manière de structurer les organisations, les objets et les vues permet d’exprimer qu’une
même vue peut être définie différemment suivant l’organisation considérée. Le but est de
permettre à des organisations de donner des définitions différentes à une même vue. Supposons
à titre d’exemple que l’hôpital de Purpan utilise un système de fichiers, et que l’hôpital de
Rangueil utilise une base de données ; la vue “dossier médical” peut être définie à Purpan
comme un ensemble de documents textes, tandis qu’à Rangueil, cette même vue correspond à
des attributs ou à des tables de la base. Le premier diagramme d’objets de la figure 4.7 exprime
que “l’hôpital Purpan utilise le fichier F31.txt comme un dossier médical”, tandis que le
deuxième diagramme illustre que “l’hôpital Rangueil utilise la table dossier médical comme un
dossier médical”.
DossMéd:Vue Purpan:Organisation DossMéd: Vue Rangueil:Organisation
Activité Organisation
AdO
Id_Organisation
0..n 0..n
Action Id_Activité
…
Soulignons que le concepteur de la politique de sécurité définit les règles avec des entités
abstraites (rôles, vues et activités), sans se soucier de la manière selon laquelle les
organisations du domaine implémentent ou considèrent les instanciations de ces entités.
4.2.5. Le contexte
D’une manière générale, le contexte peut être défini comme toute information qui caractérise
la situation d’une entité ou qui spécifie les circonstances concrètes dans lesquelles les
organisations accordent des permissions à des rôles pour réaliser des activités sur des vues. En
l’occurrence : qui peut déléguer ? 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 contexte est ainsi l’une des notions utilisées par la politique présentée pour mieux
respecter le principe du moindre privilège25. Dans le domaine médical, le contexte permettra
d’exprimer des notions comme : l’urgence, les processus habituels, l’exclusion mutuelle, les
attributs temporels, etc. En effet, le contexte peut être vu selon différentes facettes, selon qu’il
est relié aux sujets, aux objets ou à l’utilisation elle-même. Une étude détaillée concernant
l’utilisation du contexte dans les applications médicales peut être trouvée dans [Abou el Kalam
& Deswarte 2002] ainsi que dans la norme européenne [CEN 1999].
25
Ce principe consiste à ne donner accès aux utilisateurs autorisés qu’aux seules ressources dont ils ont
besoin pour accomplir leurs tâches, et ce, seulement pendant la durée de ces tâches.
107
- exclusion mutuelle : cette contrainte peut être statique ou dynamique ; une exclusion
mutuelle statique entre deux rôles signifie qu’un utilisateur ne peut jamais jouer ces deux
rôles, par exemple, dans le même établissement, être personnel soignant et comptable ; une
exclusion mutuelle dynamique entre deux rôles signifie que l’utilisateur ne peut pas jouer
les deux rôles simultanément, par exemple, médecin à l’hôpital et médecin travaillant pour
une société d’assurance.
4.2.5.4.1 Processus
Dans le cas d’un processus de soins, le consentement (explicite ou implicite) du patient est
recueilli, et l’activité de soins est enregistrée dans le système par une personne habilitée par
exemple, le médecin traitant. Le processus est ainsi identifié par un patient, un motif et des
organisations qui collaborent pour traiter le patient.
En outre, dans le domaine médical, différents protocoles de processus (processus-types)
peuvent être énumérés. Il suffit qu’une personne habilitée instancie un de ces processus, et les
108 Chapitre 4 Le modèle Or-BAC
4.2.5.4.2 Exception
Dans un cas d’exception, c’est-à-dire pour tout accès au système en dehors d’un processus
habituel, l’utilisateur doit déclarer un objectif d’utilisation. Dans le domaine de la santé, ceci
correspond à des cas non prévus dans les processus de soins, où le consentement du patient est
souvent impossible. Le but est de favoriser la vie des patients et de ne pas faire obstacle au
travail du personnel soignant, tout en engageant la responsabilité de l’utilisateur. De même,
dans la sphère sociale, nous pouvons énumérer des cas d’exception tels que :
- à l’échéance (urgence), les personnes autorisées peuvent forcer le système pour préparer
ou valider les déclarations ou les paiements via les services de Net-entreprises ;
- lors de la sélection des déclarations en mode standard, le système propose à la personne
autorisée une liste de déclarations correspondant au profil de son établissement ; toutefois,
cette liste n’est pas limitative et la personne autorisée peut forcer certains paramètres ;
- il doit être possible de forcer le niveau26 de sécurité pour certains services et dans des
conditions très particulières.
Afin de satisfaire les objectifs cités précédemment (flexibilité et sécurité), nous suggérons
que le système effectue deux types de contrôles dans le cas d’une exception :
- un contrôle a priori : les règles de sécurité doivent spécifier quel utilisateur (ou rôle) a le
droit de déclarer quel objectif, et dans quelles conditions ; par exemple si le médecin est
absent (grève, force majeure), tout professionnel soignant peut déclarer l’objectif
“urgence non habituelle” et accéder au dossier médical du patient ; un autre exemple est
26
Les accès à Net-entreprises sont paramétrés par trois niveaux de sécurité. Si l’utilisateur ne possède pas
le niveau requis pour un service, l’accès lui est refusé, sauf dans le cas d’exception que nous décrivons.
109
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.
VdO
Type_Accès
Booléen : Permission
RdO Booléen : Interdiction
Booléen : Obligation
Booléen : Recommandation
AdO
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”.
Purpan:Organisation CatastropheeDansPurpan
:CdO
LectureDansPurpan
:AdO
Type_Accès
MédecinDansRangueil
:RdO
Permission = vrai DossMedDansPurpan
:VdO
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
111
Organisation CdO
Interdiction VdO
RdO Obligation
Recommandation
Permission
AdO
joue Appartient_à
<<instance de>> Correspond_à
<<instance de>>
0..n
1..n
Tâche_Elémentaire 0..n
O\S
Utilisateur Tâche_Composite
0..n
Equipe
Action Groupe_Objets
RAV Crte-Role
Id_RdO 0..n
Id_VdO Contexte Contraintes
1..n Crte-Vue
Id_AdO
Type d’Accès
Légende Permission Crte-Org
1..n Interdiction
OPA : Objets pouvant être actifs
(patients par exemple) Obligation
Contrôle a priori
O\S :l’ensemble des objets sans Recommandation
1..n 1..n
les sujets {ordonné}
RdO : Rôle dans Organisation Processus Exception 1..n
0..n 1..n
AdO : Activité dans Organisation
VdO : Vue dans Organisation Contrôle a posteriori
Patient Problème
RAV : classe-association entre
RdO, VdO et AdO
Audit Notification
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.
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.
114 Chapitre 4 Le modèle Or-BAC
À cet égard, lorsqu’une politique de sécurité contient des permissions, mais aussi des
interdictions, voire des obligations, il est nécessaire de s’assurer qu’elle ne peut pas générer de
conflit, c’est-à-dire, garantir qu’il n’existe pas de situation dans laquelle un utilisateur aurait
simultanément la permission et l’interdiction d’effectuer une action sur un objet.
Mais tout d’abord, présentons une brève description de la logique du premier ordre et de la
logique modale, et plus particulièrement une de ses branches : la logique déontique.
contenant un opérateur modal. Par exemple, « Nécessairement p » est vrai dans un monde w si
et seulement si « p est vrai dans tous les mondes w’ directement accessibles depuis w ». L’idée
est que tous les mondes (ou états) ne sont pas forcément directement (ou indirectement)
accessibles depuis un monde w. Un monde w permet d’accéder directement à un monde w’,
seulement si toutes les propositions qui sont vraies dans w’ sont vraies dans w. De la même
manière, si une proposition est nécessairement vraie dans un monde w, elle doit être vraie dans
tous les mondes w’ auxquels w permet d’accéder.
5.3.1. Le langage
5.3.1.1 Constantes
Les symboles de constante correspondent aux instances des entités du diagramme. Ainsi, il y
a autant de types q de symboles de constante que d’entités dans notre diagramme, c’est-à-dire :
Organisation, Sujet, Objet, Action, Rôle, Vue, Activité et Contexte. Nous avons par exemple les
symboles de constante de type :
- Organisation, comme Purpan, Rangueil, ICU31, etc.,
- Sujet, comme Jean, Marie, ICU31, etc,
- Objet, comme F31.doc, F32.doc, F33.tex, etc.,
- Action, comme lire, écrire, select, etc.,
- Rôle, comme médecin, infirmière, unité_des_soins_intensifs, etc.,
- Vue, comme dossier_administratif, dossier_médical, dossier_chirurgical, etc.,
- Activité, comme lecture, écriture, consultation, etc.
- Contexte, comme urgence, etc.
Les constantes sont notées par des lettres minuscules comme a, b et c.
5.3.1.2 Variables
Les variables sont notées par des lettres minuscules comme x, y et z. Il y a des variables
individuelles pour chaque type q . Les symboles de constante de type q et les variables
individuelles de type q seront appelés termes-q.
Les symboles de relation de L, notées par des mots commençant par des lettres majuscules P,
Q, R, etc., correspondent aux relations de notre diagramme. Chaque symbole de relation P de L
est considéré comme un type de relation. Par exemple :
- RdO est un symbole de relation de type (Organisation, Sujet, Rôle).
119
5.3.1.4 Fonctions
À ce stade, notre langage n’est pas assez expressif pour pouvoir comparer des entités. Dans
de nombreuses applications, nous désirons dériver des informations concernant certaines
propriétés des entités. D’un point de vue formel, des symboles de fonction sont utilisés pour
décrire les attributs de ces entités. Les symboles de fonction sont notés par des lettres
minuscules comme f, g et h. À chaque symbole de fonction f sont associés un domaine et un
co-domaine (encore appelé domaine image de la fonction). Le domaine et le co-domaine d’un
symbole de fonction dépendent de la nature des attributs qui lui sont associés. Si un symbole de
fonction correspond à l’attribut Nom, alors son domaine est de type Sujet et son co-domaine est
un ensemble de noms. De même, le domaine d’un symbole de fonction correspondant à un
attribut Âge est de type Sujet et son co-domaine est un ensemble d’entiers positifs. Enfin, le
domaine d’un symbole de fonction correspondant à l’attribut Groupe_sanguin est de type Sujet
et son co-domaine est l’ensemble {A, AB, B, O}. Dans la mesure où il est possible que des
sujets n’aient pas de nom ou que leur groupe sanguin soit inconnu, les symboles de fonction du
langage L peuvent n’établir qu’une correspondance partielle entre les domaines et co-domaines
associés. Dans de nombreuses situations, il nous est impossible d’attribuer une valeur unique à
certains attributs d’une entité. Pour répondre à une telle situation d’un point de vue conceptuel,
nous utilisons des symboles de fonction unaires ayant pour co-domaine l’ensemble des parties
d’un ensemble. Pour illustrer ceci, il nous suffit de mentionner le cas de l’attribut
médecin_traitant : le domaine du symbole de fonction associé est de type Sujet et le co-
domaine associé est un ensemble d’ensembles finis de noms.
Afin de dériver les informations représentées par les symboles de fonction, nous devons
introduire des relations binaires concrètes, notées par s , t et m entre les domaines. Le type
d’une relation binaire concrète est le couple correspondant aux domaines sur lesquels la
relation s’applique. L’égalité est probablement la relation binaire concrète la plus simple que
nous aurons à traiter. Considérons les exemples suivants :
- Si t et u sont des termes de type Sujet, alors médecin_traitant(t) = médecin_traitant(u)
signifie que les sujets t et u ont au moins les mêmes médecins traitants.
- Si t et u sont des termes de type Sujet, alors Âge(t) = Âge(u) signifie que les sujets t et u
ont le même âge.
- Si t et u sont des termes de type Sujet, alors Groupe_sanguin(t) = Groupe_sanguin(u)
signifie que les sujets t et u ont le même groupe sanguin.
Bien évidemment, il existe certains cas où d’autres relations binaires doivent être
considérées. Par exemple :
120 Chapitre 4 Le modèle Or-BAC
5.3.2. La sémantique
La sémantique utilisée est définie par le modèle M = < W, ¬, V, D > où :
- W est un ensemble de mondes possibles w ;
- ¬ est une relation d’accessibilité (relation binaire sur W) ;
- D est un domaine. Un domaine est un ensemble non-vide de valeurs ;
- V est une fonction qui donne les valeurs de vérité des éléments du langage : V(Formule
Atomique d’arité n) Œ Dn, V(variable) Œ D, V(constante) Œ D.
Intuitivement, (Bob, médecin, Hôpital-Rangueil) Œ V(w, RdO) » signifie que dans le monde
w, Bob joue le rôle médecin au sein de l’organisation “Hôpital-Rangueil”. De la même
manière, « (Sam, f5.doc) Œ V(w,LIRE) » signifie que dans le monde w, Sam exécute l’action
LIRE sur le fichier f5.doc.
- PpÆ ¬F p : la politique définit explicitement les permissions ; ainsi, toute chose permise
est forcément non interdite (l’inverse n’est pas toujours vrai).
- O(pŸq) ´ O p Ÿ O q : l’obligation de faire la conjonction de p et q est équivalente à
l’obligation de faire p et l’obligation de faire q.
- O p Æ R p et R p Æ P p : tout ce qui est obligatoire est recommandé, tout ce qui est
recommandé est permis. La recommandation est donc une modalité plus forte que la
permission et moins contraignante que l’obligation.
Dans le domaine social, les déclarations (d1, d 2, …) et paiements (p1, p 2, …) effectués par les
organisations adhérentes à Net-entreprise peuvent être considérés comme des objets
appartenant aux vues : déclaration-annuelle-URSSAF, déclaration-trimestrielle-URSSAF,
déclaration-mensuelle-URSSAF, déclaration-annuelle-ASSEDIC, déclaration-trimestrielle-
ASSEDIC, déclaration- mensuelle-ASSEDIC, titre-de-paiement-annuel-URSSAF, titre-de-
paiement- trimestriel-URSSAF, etc. Dans Or-BAC, les instances de la relation
VdO(organisation, o b j e t , vue) sont du type : V d O (Ernst&Young, d31.txt, déclaration-
mensuelle-URSSAF), VdO(CNRS, d32.txt, déclaration-mensuelle-URSSAF).
En outre, les déclarations ainsi que les paiements associés aux unités27 déclarées ou aux
portefeuilles28 peuvent être considérés comme des vues, en l’occurrence: VdO(Ernst&Young,
d33.txt, F déclaration(portefeuille-Grandes-Entreprises)). Dans cette règle, nous avons utilisé une
fonction F déclaration qui s’applique à un ensemble d’organisations et retourne l’ensemble des
déclarations associées à ces organisations.
Dans la sphère sociale, la composition de vues peut être illustrée à travers des instanciations
de la relation : “Sous-Vue(Organisation, Vue, Vue)”, par exemple Sous-Vue (Ernst&Young,
déclarations), Fdéclaration(portefeuille-Grandes-Entreprises)) déclare que dans l’organisation
Ernst&Young, les déclarations associées au portefeuille des grandes entreprises est une
partition de l’ensemble des déclarations.
27
Dans la section 3.2.2.1, nous avons défini une unité déclarée comme étant un sous-ensemble d’un
établissement ou d’une entreprise. Elles peuvent correspondre à des découpages fonctionnels
géographiques ou hiérarchiques. Ainsi, les déclarations concernant les cadres par exemple peuvent être
considérées comme des vues séparées de celles concernant les autres employés.
28
Dans la section 3.2.2.1.3.3, nous avons défini un portefeuille comme étant un ensemble
d’établissements ou d’entreprises associés à une personne autorisée.
124 Chapitre 4 Le modèle Or-BAC
Dans Or-BAC, les associations des actions aux activités dans une certaine organisation sont
données par la relation “AdO”, par exemple :
- AdO(LAAS, sendMail, envoi),
- AdO(LAAS, openfile, consultation) et
- AdO(Ernst&Young, update, écriture).
5.4.1.4 La hiérarchie
L’héritage est un mécanisme qui permet de maîtriser la complexité. La règle : "a"v"c
(Permission(ST1, r1, a, v, c) Æ Permission(ST1, r2, a, v, c) exprime l’héritage des permissions
dans ST1 entre un rôle r1 (par exemple médecin) et un rôle r2 (par exemple chirurgien). Une
autre manière de faire consiste à ajouter le prédicat “Sous-Rôle(Organisation, Rôle, Rôle)”,
ainsi pour spécifier que r 1 hérite des permissions de r2, il suffit d’ajouter l’instance Sous-
rôle(ST1, r1, r2) à cette règle.
Précisons toutefois que dans notre modèle il est possible de spécifier que l’héritage entre
deux rôles donnés ne s’applique qu’à certaines organisations. Nous pouvons par exemple
spécifier qu’à l’hôpital Purpan, le rôle directeur hérite des permissions du rôle médecin :
"a"v"c (Permission(Purpan, médecin, a, v, c) Æ Permission(Purpan, directeur, a, v, c)).
Bien évidemment, l’héritage est spécifié au sein d’une organisation donnée, et nous n’aurions
pas cette règle si, au lieu de considérer l’hôpital Purpan, nous considérions un autre
établissement au sein duquel le directeur n’est pas un médecin. Il est également possible
d’exprimer dans notre modèle l’héritage, entre rôles, d’interdictions, d’obligations et de
recommandations.
Par ailleurs, de la même manière que nous avons spécifié la hiérarchie de rôles, nous pouvons
modéliser la récursivité des vues, des activités et des organisations à travers lesnouveaux
prédicats : “Sous-Vue(Organisation, Vue, Vue)”, “Sous-Activité(Organisation, Activité,
Activité)”, “Sous-Organisation(Organisation, Organisation)”. Par exemple, les vues
dossier_administratif, dossier_médical et dossier_chirurgical sont des sous-vues de la vue
dossier_patient. Ainsi, un rôle qui a la permission de réaliser une activité sur la vue
dossier_patient a également la permission de réaliser la même activité sur les sous-vues
précédemment citées. Ceci s’exprime dans notre langage par la règle suivante : "r"a"c
(Permission(Purpan, r, a, dossier_patient, c) Æ Permission(Purpan, r, a, dossier_administratif,
c)). Il en est de même pour les vues dossier_médical et dossier _chirurgical.
Dans le domaine social, la spécification des accès (en amont) à Net-entreprises distingue
deux rôles “de base” joués par les utilisateurs dans les organisations (section 3.2.2.1, page 69) :
- Personne inscrite,
- Personne non-inscrite.
Rien n’empêche qu’une personne inscrite puisse jouer le rôle de personne non-inscrite.
Inversement, pour qu’une personne non-inscrite devienne inscrite, elle doit remplir certaines
conditions (inscription).
Les rôles : dirigeant, mandataire social, administrateur et personne autorisée, sont des sous-
rôles du rôle personne inscrite, ils héritent donc de ses propriétés (par exemple, l’appartenance
à un établissement adhérent) et de ses privilèges (par exemple, le droit de modification de ses
propres informations). Une relation d’héritage existe également entre le rôle mandataire social
et le rôle dirigeant. Il est possible de faire appel au polymorphisme pour spécifier que le
mandataire social est le dirigeant du siège de l’entreprise. Dans Or-BAC, cette hiérarchie de
rôles peut être modélisée par les règles suivantes :
- Sous-Rôle(Org, Mandataire, Dirigeant),
125
5.4.1.5 Le contexte
Le contexte peut être exprimé par des règles de fonctionnement. En l’occurrence, l’exclusion
mutuelle entre les rôles médecin de nuit et médecin de salle s’exprime par RdO(u, Médecin,
Org)Æ[RdO(u, Médecin-nuit, org)´¬RdO(u, médecin-salle, org)].
Le contexte “équipe traitant” entre un certain patient o, un sujet s et une organisation org peut
être définie de la manière suivante : " s " o "a CdO(org, s, o, a , Equipe-traitante) ´ $r
RdO(org, s, r ) Ÿ N o m(o) Œ Patient(s)). Cette formule peut être interprétée ainsi : dans
l’organisation org, le contexte “équipe traitante” est vrai entre le sujet s et l’objet o si et
seulement si s joue un rôle dans org et si o est un dossier correspondant à un des patients traité
par org.
De la même manière, le contexte “équipe traitante” est défini dans une certaine organisation
ST1 par :
- "s"o"a (Définit(ST1, s, a , o, équipe_traitante) ´ $ r (RdO(ST1, s, r) Ÿ Nom(o) Œ
Patient(ST1)), c’est-à-dire, dans ST1, le contexte “équipe traitante” est vrai entre le sujet s,
l’action a et l’objet o si et seulement si s joue un rôle dans ST1 et si o est un dossier
correspondant à un des patients traité par l’organisation ST1.
Le contexte peut éventuellement dépendre de contraintes temporelles. Le contexte “nuit” par
exemple, peut être spécifié par la règle suivante : “"s"o"a (Définit(org, s, a , o, nuit) ´
Après(20:00) & Avant(08:00)”. L’opérateur “&” désigne la conjonction de contextes ; “Après”
et “Avant” sont deux fonctions qui s’appliquent à des éléments du “temps” et qui retournent des
contextes temporels. Elles peuvent être définies comme suit :
- “"org "s "o"a "tŒTemps, Définit(org, s, a , o, après(t)) ´ temps(Horloge) ≥ t ”.
“Horloge” est une entité capable d’évaluer et de retourner le temps courant.
Le contexte “avant” peut être défini d’une façon similaire par :
- “"org "s "o"a "tŒTemps, Définit(org, s, a, o, après(t)) ´ temps(Horloge) ≥ t”.
L’expression du lieu comme attribut contextuel peut être fait ainsi : “"org "s "o"a
"tŒTemps, Définit(org, s, a , o, Accès-Local) ´ @IP(s) Œ IP-Local(org)”. Cette règle signifie
que le contexte “Accès Local” est vrai dans l’organisation org entre le sujet s l’action a et
l’objet o, si et seulement si l’adresse IP du sujet appartient à un intervalle d’adresses IP internes
à org. Nous considérons que les sujets ont l’attribut “@IP”qui donne l’adresse IP du terminal
126 Chapitre 4 Le modèle Or-BAC
utilisé par le sujet et que les organisations ont l’attribut “IP-Local”qui retourne l’ensemble des
adresses IP internes à cette organisation.
Pour offrir plus de flexibilité, nous avons défini l’objectif d’utilisation comme un contexte
particulier revendiqué par des utilisateurs souhaitant intervenir dans des situations qui sortent
des processus de soins habituels. Un objectif d’utilisation est caractérisé par des conditions a
priori et des conditions a posteriori. À titre d’exemple, détaillons le contexte ContexteUNH :
“Urgence Non Habituelle (UNH)”. Nous proposons de l’exprimer de la manière suivante :
"s"o"a (Définit(ST1, s, a , o, ContexteUNH) ´ Déclarer-Objectif Ÿ Condition-a-priori Ÿ
Condition-a-posteriori, avec :
- Déclarer-Objectif ≡ (créer, s, o’) Ÿ VdO(org, o’, VueUNH) Ÿ Patient-traité(o’)=Nom(o). Dans
cette expression, nous considérons la vue “VueUNH” ayant un attribut “Patient-traité”. Le
sujet déclare l’objectif d’utilisation “urgence non habituelle” s’il insère l’objet o’ dans la vue
VueUNH, et si o correspond bien au patient figurant dans l’objectif déclaré.
- Condition-a-priori ≡ RdO(org, s, Personnel-Soignant). Cette expression signifie que tout
personnel soignant (dans une organisation) peut déclarer l’objectif d’utilisation “urgence
non habituelle” (dans cette organisation).
Condition-a-posteriori ≡ Obligation(o r g , S y s t è m e , E n r e g i s t r e r , VueDonnées-Audit,
ContexteObjectif), c’est-à-dire que le système (rôle) doit enregistrer les données d’urgence.
Les types de contextes existants dans la sphère sociale ne diffèrent pas de ceux énumérés
précédemment, nous nous contentons ainsi de modéliser quelques exemples dans Or-BAC.
Nous commençons par exprimer le contexte temporel “déclaration-à-échéance”. Pour cela,
nous avons tout d’abord besoin de définir la fonction “date” qui s’applique à une action et un
objet, et retourne la date d’exécution de l’action sur l’objet, par exemple “date(envoi, d1.txt)”
désigne la date d’envoi de la déclaration d1.txt à Net-entreprises. Nous définissons par la suite
la fonction “avant-date” qui s’applique à des triplets (d : date, a : action, o : objet), pour
retourner un contexte temporel défini comme suit : "s"o"a CdO(Org, s, a , o, avant-date(d,
a , o) ´ date(a , o)£d, c’est-à-dire, l’action a est exécuté sur l’objet o avant la date d. Nous
avons également besoin de l’attribut “Nbre-salariés” d’une entité “organisation” pour désigner
le nombre de salariés de cette organisation et de l’attribut “mois” d’une entité date, pour
désigner le mois de cette date. Enfin, le contexte “déclaration-à-échéance” peut être défini par
la règle :
"s"o"a (CdO(Org, s, envoi, o, déclaration-à-échéance) ´
[Nbre-salariés(Org) £ 9 Ÿ avant-date(15 [(mois(date) modulo 3) = 1], a, o)] ⁄
[10 £ Nbre-salariés(Org) £ 50 Ÿ avant-date(15 mois(date)+1, a, o)] ⁄
[Nbre-salariés(Org) > 50 Ÿ avant-date(5 février, a, o)].
En effet, une déclaration est considérée à échéance si elle appartient à l’un des trois cas
suivants :
Si le nombre de salariés de l’entreprise ne dépasse pas neuf, la déclaration est trimestrielle et
doit être faite avant le 15 du mois qui suit (c’est-à-dire avant le 15 des mois de janvier, avril,
juillet et octobre) ; sinon, si le nombre de salariés est compris entre dix et cinquante, les
déclarations sont mensuelles et doivent être faites avant le quinze du mois qui suit ; sinon
(nombre de salariés supérieur à cinquante), les déclarations sont mensuelles et doivent être
faites avant le cinq du mois qui suit.
127
29
Par ailleurs, puisque les autres contextes identifiés dans les accès à Net-entreprises sont
similaires à ceux présentés dans le scénario médical de la section précédente, il n’est pas
nécessaire de les décrire à nouveau.
Une autre représentation du contexte associé à Or-BAC dans un langage logique du premier
ordre a été effectuée par Cuppens et Miège [Cuppens & Miège 2003b]. Certaines différences
existent toutefois entre leur vision et la nôtre. En particulier, ils catégorisent différemment le
contexte et ne considèrent pas le contexte d’utilisation.
29
Il s’agit de contextes relatifs au lieu, par exemple le lieu de gestion d’un type de déclarations ou de
référentiels ; ou relatifs à un objectif d’utilisation, par exemple un processus d’accès aux services de Net-
entreprises ou à des cas d’urgences non habituelles où l’utilisateur peut forcer l’accès et effectuer ses
déclarations ou ses paiements.
128 Chapitre 4 Le modèle Or-BAC
Ce récapitulatif nous montre de nouvelles formes de règles, que nous n’avons pas analysé
précédemment. Considérons la règle la plus originale dans les accès aux services de Net-
entreprises : “un administrateur désigne une personne autorisée à effectuer des types de
déclarations selon une certaine modalité pour le compte d’un certain établissement30”.
Cette règle peut être décomposée en deux autres règles :
- une première règle donnant à l’administrateur le droit de désigner (ou révoquer) des
personnes autorisées, c’est-à-dire d’affecter des utilisateurs au rôle personne autorisé ; cette
règles s’appelle règle de délégation (ou d’administration) ;
- une deuxième règle donnant à la personne autorisée le droit d’effectuer des déclarations
pour le compte d’un certain établissement.
Nous proposons de représenter les règles de délégation sous la forme “Permission
(organisation, RdO, AdO, VdO, CdO)”, avec :
- organisation est la structure qui décide de déléguer, c’est-à-dire l’établissement déclarant ;
- RdO est la fonction qui a le pouvoir de désigner, nommer, ou révoquer des personnes
habilitées, dans notre cas, c’est le rôle administrateur dans l’établissement déclarant ;
- AdO correspond à l’activité nomination dans l’établissement déclarant (association d’un
utilisateur à un rôle) ;
- CdO est le processus suivi par l’administrateur pour effectuer cette nomination, notons le
par exemple “inscription de nouvelles personnes autorisées” ;
- VdO est le “schéma de la règle de délégation” ; les objets appartenant à cette vue sont des
règles.
Récapitulons, la règle de délégation (qui autorise l’administrateur à affecter des nominations)
a la forme suivante : “Permission (établissement déclarant, administrateur, désigner ou
révoquer, schéma de la règle de délégation, inscription de nouvelles personnes autorisées)”.
En insérant un objet dans la vue “schéma de la règle de délégation”, l’administrateur désigne
une personne autorisée pour effectuer des types de déclarations, pour une certaine organisation,
selon une certaine modalité. Par conséquent, cette vue particulière, notée “V_schéma-règle-
délégation”, possède les attributs31 suivants :
• org : l’organisation dans laquelle le rôle concerné sera joué, c’est-à-dire
l’établissement déclaré ; " schéma-délégationi Œ V_schéma-règle-délégation,
org(schéma-délégationi) = étab-déclaréa) ;
• rôle : le rôle délégué, c’est-à-dire “personne autorisée” ; Rôle(schéma-délégationi) =
personne-autorisée ;
• sujet : le sujet (Claire, Philippe, …) bénéficiant de la délégation, c’est donc
l’utilisateur qui sera désigné (par l’administrateur) comme personne autorisée ; par
exemple, sujet(schéma-délégationi) = Philippe ;
• activité : l’activité correspondant à l’action que la personne autorisée (Philippe ) peut
effectuer, par exemple activité(schéma-délégationi) = envoyer-formulaire-déclaration ;
• vue : la vue déléguée, c’est-à-dire la vue que la personne autorisée va manipuler ; il
peut s’agir de types de déclarations ou types de titres de paiement, par exemple, les
déclarations URSSAF, DUCS, CSSS, DADS-TDS : vue(schéma-délégationi) =
déclarations-URSSAF, Vue(schéma-délégationj) = titre-paiement-DUCS, etc.
30
Rappelons que l’établissement déclarant et l’établissement déclaré ne sont pas nécessairement les
mêmes, en l’occurrence dans le cas d’un tiers déclarant.
31
Bien évidemment, les attributs de cette vue sont instanciés à chaque fois que l’administrateur désigne
ou révoque une personne autorisée, autrement dit à chaque fois qu’il insère un objet dans cette vue.
130 Chapitre 4 Le modèle Or-BAC
32
Un objectif peut par exemple être : une définition séparée des personnes autorisées, puis de leurs
périmètres d’habilitations, ou à l’inverse, définir ces deux tâches en même temps.
33
Nous avons déjà expliqué dans la section 3.2.3.2.1 que les sous-rôles du rôle personne autorisée
peuvent être : personne autorisée à effectuer les déclarations, personne autorisée à effectuer des
paiements, personne autorisée à consulter les déclarations etc.
131
déclaréa. URA possède trois attributs : sujet (sujet concerné par l’affectation), rôle (auquel le
sujet sera affecté) et org (l’organisation dans laquelle le sujet sera affecté). URA-PA- étab-
déclaréa. est définie comme suit :
- " ura Œ URA VdO(org, ura, URA-PA- étab-déclaréa) Æ RdO(org(ura), sujet(ura),
rôle(ura)) ; avec : “org(ura) = étab-déclaréa” et “rôle(ura) = personne autorisée” (ou l’un
de ses sous-rôles).
La règle autorisant l’administrateur à gérer les rôles des utilisateurs ressemble à celle donnée
dans l’exemple précédent (Permission (établissement-déclarantb, administrateur, gestion,
URA-PA- étab-déclaréa, Processus-habilitation-PA)).
PRA sert à associer des permissions à des rôles. L’association PRA a cinq attributs :
initiateur (organisation où la permission s’applique), rôle (rôle qui bénéficie de la délégation),
privilège (l’activité déléguée), cible (vue concernée par la délégation) et contexte (dans lequel
la règle s’applique). Donner une nouvelle permission à un rôle correspond en fait, à créer un
nouvel objet qui se conforme à l’association PRA. Le lien entre ces objets et la relation
“Permission” est modélisé par :
- "org "contexte,
VdO(org, pra, PRA) Æ Permission (initiateur(pra), rôle(pra), privilège(pra), cible(pra),
contexte(pra)).
Ainsi, la règle où l’administrateur est autorisé à affecter la permission “consulter des
déclarations” au rôle “personne-autorisée” peut être modélisée comme suit :
- (Permission (établissement-déclarantb, administrateur, gestion, PRA-PA- étab-déclaréa,
Processus-habilitation-PA))
La vue PRA-PA- étab-déclaréa est définie par :
- "pra, VdO(établissement-déclarantb, pra, PRA-PA- étab-déclaréa,) ´
VdO(établissement-déclarantb, pra, PRA) Ÿ
initiateur(pra) = étab-déclaréa, Ÿ
rôle(pra) = personne-autorisée Ÿ
privilège (pra) = consultation Ÿ
cible(pra) = déclaration Ÿ
contexte(pra) = processus-vérification.
UPA sert à affecter des permissions à des utilisateurs. Cuppens et Miège distinguent deux cas
différents nommés : UPA1 et UPA2. UPA1 donne à un utilisateur le droit d’associer une
permission à un autre utilisateur pour réaliser une certaine tâche sur un certain objet, tandis que
UPA2 donne à un utilisateur le droit d’associer une permission à un autre utilisateur pour
réaliser une certaine activité sur une vue. Dans le cadre de ce mémoire, nous donnons
seulement un exemple de UPA2. Celle-ci contient cinq attributs : initiateur (organisation dans
laquelle la permission s’applique), sujet (sujet qui bénéficie de la délégation), privilège
(l’action déléguée), cible (l’objet concernée par la délégation) et contexte (dans lequel la
permission s’applique). Afin d’exprimer la règle “le dirigeant de l’entreprise déclarante peut
associer, à l’administrateur, le droit de mettre à jour la table des personnes autorisées”, nous
devons, tout d’abord, définir la vue MJTPA (pour Mise à jour de la Table des Personnes
Autorisée) qui est une sous-vue de UPA2 :
- "upa, VdO(établissement-déclarantb, upa, MJTPA) ´
VdO(établissement-déclarantb, upa, UPA2) Ÿ
RdO(étab-déclaréa, sujet(upa), Personne-autorisée) Ÿ
132 Chapitre 4 Le modèle Or-BAC
privilège(upa) = consultation Ÿ
sous-vue(étab-déclaréa, cible(upa), table-personnes-autorisée).
Notons tout de même que la vision présentée dans [Cuppens & Miège 2003a] considère
l’attribut initiateur comme l’organisation qui décide de la délégation (l’établissement
déclarant) tandis que dans notre vision, il s’agit de l’organisation dans laquelle la permission
d’applique (l’établissement déclaré).
Cette section montre que le langage proposé permet de couvrir la richesse des SICSS,
notamment vis-à-vis de la représentation des permissions, des interdictions, des obligations et
des recommandations. Néanmoins, comme tout langage basé sur la logique déontique, des
questions comme l’interprétation sémantique des formules (modèles de Kripke) s’imposent
fréquemment.
À cet égard, des techniques de déduction automatique, fondées par exemple sur la méthode
des tableaux [Fitting 1993], ont été proposées. Entre autres, ils permettent de vérifier si, partant
d’un état sûr (qui satisfait les objectifs de sécurité), et en appliquant les règles de sécurité, on
retrouve un état (une situation) ou certains objectifs de sécurité sont violés (état non sûr). Un
exemple de l’application de la méthode des tableaux dans le cadre des politiques de sécurité est
donné dans [Ortalo 1998].
Afin de détecter et résoudre les conflits, on peut également utiliser la logique possibiliste.
Rappelons qu’un conflit peut être défini comme une situation dans laquelle un utilisateur aurait
simultanément la permission et l’interdiction, ou l’obligation et l’interdiction, d’effectuer une
action sur un objet (section 4.4.1.2, page 112). Par exemple, l’application d’un enchaînement
de règles permet de déduire qu’un médecin ne traitant pas un patient P n’a pas le droit de
consulter son dossier médical, alors qu’un autre enchaînement de règles permet de déduire
qu’en cas d’urgence, n’importe quel médecin peut lire le dossier médical d’un patient. Ces
deux résultats amènent à un conflit dans le cas où un médecin n’ayant jamais traité un patient
veut lire son dossier alors qu’il y a urgence. Nos partenaires de MP6 proposent d’utiliser la
logique possibiliste [Benferhat et al. 2003] pour résoudre ce type de conflits en associant, aux
formules de la base, des coefficients de confiance allant de 0 à 1. Ainsi, dans notre exemple, si
l’on considère l’urgence comme étant prioritaire, on donne un coefficient x1 pour la première
règle, et x2 pour la deuxième, avec x1< x2. La comparaison des coefficients permet de ne retenir
que la deuxième règle.
Chapitre 6. Application d’Or-BAC aux SICSS et mise en
oeuvre
Préambule
Le modèle Or-BAC a été associé, d’une part, à une spécification UML pouvant guider le
processus de mise en œuvre (chapitre 4), et d’autre part à un formalisme logique (chapitre 5)
pouvant aider à raisonner sur les permissions, obligations, interdiction et recommandation ; à
détecter et résoudre les conflits, etc.
Le présent chapitre propose une démarche progressive fondée sur l’utilisation d’UML
[Muller & Gaertner 2000 ; Booch et al. 1999] pour la définition d’une politique de sécurité -
fondée sur Or-BAC - d’un système ou d’une organisation.
Cette démarche - qui peut être appliquée à différentes organisations - tient compte des
aspects conceptuels, statiques et dynamiques de la politique de sécurité. Nous allons ainsi
montrer comment utiliser les différents diagrammes UML pour : représenter les interactions
entre les utilisateurs et le système ; spécifier les concepts de permission, interdiction ou
obligation ; représenter des processus ; détailler les types de relations ; etc.
La deuxième partie présente l’analyse conceptuelle, organisationnelle et opérationnelle que
nous avons suivi pour mettre en œuvre un logiciel de contrôle d’accès pour un centre de soins
dentaires contenant plusieurs organisations (cabinets, services, etc.). Seuls les aspects décrivant
le passage entre la politique de sécurité (fondée sur Or-BAC) et le contrôle d’accès seront
abordés en détail. L’analyse fonctionnelle du logiciel est donnée en annexe D.
134 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
Cette représentation peut être spécifiée, en UML, à l’aide du diagramme de cas d’utilisation
de la figure 6.1.
136 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
Interrogatoire
34
Dans ce diagramme, on ne s’interesse qu’à la phase d’autorisation. Nous supposons ainsi que les
phases d’identification et d’authentification se sont bien effectuées et que la secrétaire détient une preuve
du succès de ces étapes. Dans la suite de cette section, d’autres diagrammes détailleront les phases
d’identification et d’authentification.
137
Contrôle d'accès :
quelles informations ?
Informations administratives
concernant le patient
Modification informations
Informations sur le patient
Sauvegarde
Afin d’éclaircir les liens entre les différentes phases d’identification, authentification et
autorisation, il nous semble nécessaire de décrire l’enchaînement temporel des étapes du
contrôle d’accès avant d’autoriser (ou non), l’invocation d’un objet local (figure 6.3). Celui de
la figure 6.4 décrit le cas où l’objet invoqué est distant (cas plus général). Ces deux
diagrammes modélisent le schéma d’autorisation développé et implémenté dans le cadre du
projet MAFTIA [Deswarte et al. 2001].
138 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
Demande d'accès
Extraction règles concernées
P?:=Accès(
rôle, demande avec
paramètres d'invocation
objet invoqué, Evaluation paramètres dans règles
contexte,
... ) Résolution conflits
Décision
Si SA distribué
assemblage signatures
Vérification signature
des preuves
Désignation premier
objet à invoquer Stockage preuves
Interception
Invocation
méthode m Extraction capacité associée
de l'objet O1 à cette invocation
avec les
paramètres param Vérification signature capacité
O1.m(param)
Déchiffrement capacité
avec sa clé privée
Contrôle cohérence
Invocation autorisée
Retour invocation
Figure 6.3 : Contrôle d’accès dans le cas d’une invocation d’un objet local.
Dans la figure ci-dessus, l’utilisateur envoie une requête avec un ensemble de paramètres
comme son rôle, l’objet invoqué et le contexte. Le moniteur de référence de sa machine
intercepte la requête et l’envoie au serveur d’autorisation. Ce dernier interroge la politique de
sécurité et extrait les règles qui permettent de décider dans le cas courant. Il évalue les
paramètres de la requête dans ces règles, résout les conflits35 éventuels, et renvoie sa décision
(est-ce-que l’action est permise, interdite, obligatoire ou recommandée ?). Ensuite, il génère un
ensemble de preuves d’autorisation associées à cette action, signe cet ensemble (avec sa clé
privée) et l’envoie au moniteur de référence.
Dans le projet MAFTIA, une preuve d’autorisation est définie comme un n-uplet dont les
éléments sont les capacités donnant le droit à un sujet de réaliser une action. Si l’action
comprend d’autres actions composites, cette preuve contient des coupons. Chaque coupon
regroupe les capacités nécessaires à la réalisation de l’action composite. L’objet qui reçoit une
preuve d’autorisation pour réaliser une action composite, utilise les capacités qui lui sont
destinées, et achemine les autres capacités, aux autres objets intervenant dans le reste de
l’action [Deswarte et al. 2001].
Comme il ne s’agit que d’un accès à un objet local, le moniteur de référence qui reçoit les
preuves d’autorisation est celui du demandeur. Il stocke les preuves, et envoie à l’utilisateur le
nom du premier objet à invoquer. Quand l’utilisateur invoque la méthode de cet objet, le
35
Un conflit peut être, par exemple, le cas où la dérivation d’un ensemble de règles permet d’autoriser
l’accès, alors qu’une autre dérivation impliquant d’autres règles l’interdit.
139
moniteur de référence intercepte cette invocation, extrait les capacités qui lui sont associées,
vérifie leurs signatures, et les déchiffre avec sa clé privée. Il effectue également des contrôles
de cohérence avant d’invoquer l’objet concerné. Le cas général où l’objet invoqué est situé sur
une machine distante est présenté dans la figure 6.4.
Vérification signature
Envoi premier Stockage preuves
objet à invoquer
Interception
Invocation méthode m
de l'objet O1 avec les Envoi capacités
paramètres param chiffrées signées
O1.m(param)
Envoi Acquittement (Ack) signé (accompagné du certificat
Pour que le MR de l'utilisateur puisse vérifier la signature)
Vérification certificat
de l'objet destinataire
OK ? + retour Acquittement
Vérification signature
Déchiffrement capacité
Stockage des coupons (Â capacités)
nécessaires au reste de l'action
Figure 6.4 : Contrôle d’accès dans le cas d’une invocation d’un objet distant.
Il est important de signaler que, dans les schémas classiques de délégation (basés sur la
procuration) un objet transmet à un autre objet certains de ses privilèges pour qu’il puisse
réaliser une tâche en son nom. À l’inverse, le schéma proposé par MAFTIA applique le
principe du moindre privilège car, même si un utilisateur contribue à une action composite, il
ne peut effectuer que les actions qu’il a le droit d’exécuter. Chaque objet exécute sa partie de
l’action avec sa propre identité. Un objet peut donc recevoir des droits ponctuels pour exécuter
une partie de l’action composite, sans nécessiter que l’objet qui les lui transmet possède ces
droits.
La figure 6.5 illustre le diagramme de collaboration correspondant au diagramme de
séquence de la figure 6.6.
140 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
3: Extraction règles
4: Evaluation paramètres
5: Résolution conflits
: Serveur 6: Décision
d'Autorisation (SA) 7: Génération preuves d'autorisation
8: Signature preuves
22: Autorisation
1: Demande d'accès
13: Invocation méthode
: Objet
: Utilisateur
invoqué
Nous venons d’expliquer comment représenter une politique de sécurité à l’aide des cas
d’utilisation. Nous avons détaillé, à travers des diagrammes de séquences, les étapes de
certaines procédures d’accès (cas d’utilisation “gestion” et “contrôle d’accès”). Le diagramme
d’activité36 de la figure 6.6 représente un scénario récapitulatif des phases précédant la décision
d’accès (est ce que l’accès est autorisé, refusé, obligatoire ou recommandé).
Un utilisateur useri commence par s’identifier et s’authentifier. Le système récupère ses
attributs, lui propose de choisir un rôle, récupère et vérifie la hiérarchie et le contexte du rôle
(en l’occurrence l’exclusion mutuelle). L’étape suivante consiste à choisir une organisation (ou
à créer une nouvelle organisation). Dans cet exemple, nous supposons que l’utilisateur a choisi
orgj et rôlek, et que l’organisation est une équipe de soins. Le système vérifie si l’utilisateur a le
droit de jouer rôlek dans orgj, avant de récupérer et de vérifier le contexte de l’organisation
(lieu, certaines règles de fonctionnement, unité de rattachement, etc.). L’utilisateur a ensuite
trois alternatives : choisir un processus de soins parmi les processus enregistrés dans le
serveur et auxquels son organisation participe ; créer un nouveau processus (seulement si rôlek
= médecin) ; ou déclarer, dans des cas particuliers et bien définis, un objectif d’utilisation.
Dans ce dernier cas, le système vérifie les conditions a priori et lance le contrôle a posteriori.
Une requête d’accès tient compte de paramètres tels que : les attributs de la connexion et de
l’utilisateur, de la fonction jouée (rôle dans une organisation), de l’activité à réaliser, ainsi que
du contexte (du rôle, de l’objet, de l’organisation et de l’utilisation prétendue). Le système
extrait la ou les règles de sécurité concernées, évalue ensuite les paramètres de la requête dans
ces règles (instanciation et déduction) et gère les conflits éventuels avant d’accorder ou de
rejeter la requête d’accès.
36
Certes, les diagrammes d’activités sont moins détaillés que les diagrammes de séquences, mais ils
peuvent parfois offrir une vision glogale qui masque certains aspects, facilitant ainsi la compréhension
pour certains types d’utilisateurs finaux.
141
Déconnexion ou modification
[Non OK] [OK]
des paramètres déjà enregistr és
création nouvelle
(équipe, rôle, activit é, contexte)
équipe
Pour résumer, UML définit les cas d’utilisation au moyen de collaborations entre objets du
domaine. Chaque collaboration regroupe un contexte d’objets et une interaction entre ces
objets. Les diagrammes de séquences ainsi que les diagrammes d’activité représentent les
interactions en favorisant l’aspect temporel ; tandis que les diagrammes de collaboration
insistent sur la structure spatiale qui permet la mise en œuvre de la collaboration d’un ensemble
d’objets.
Le contexte d’objets est exprimé de manière particulière dans les diagrammes de
collaboration et de manière générale dans les diagrammes de classe. Pour une application
spécifique, un diagramme de classe, peut être déduit de la manière suivante :
- d’abord représenter les acteurs ainsi que leurs fonctions dans le diagramme de cas
d’utilisation ;
- puis détailler chaque cas d’utilisation à l’aide de diagrammes d’interaction (celui-ci donne
une représentation temporelle des interactions entre les acteurs et le système) ; chaque
diagramme d’interaction correspond à un diagramme de collaboration qui insiste sur
l’aspect spatial des interactions entre objets, instances des acteurs ;
- une ébauche de diagramme de classe est automatiquement déductible à partir d’un
diagramme de collaboration ;
- le diagramme de classes est obtenu automatiquement par un assemblage des différentes
ébauches ;
142 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
37
En UML, un sous-système est défini comme étant un ensemble d’éléments qui représente une unité
comportementale du système physique.
143
Le centre dentaire que nous considérons est une unité de soins (organisation) composée de
trois cabinets (sous-organisation), d’un laboratoire de prothèse (sous-organisation) et de trois
services : réception, administration et comptabilité. Chaque cabinet contient au moins un
chirurgien dentiste (et parfois une assistante) ; le service administratif emploie une ou plusieurs
secrétaires médicales ; au service de comptabilité sont affectés un ou plusieurs comptables ;
tandis qu’un ou plusieurs prothésistes opèrent dans le laboratoire de prothèse. Selon la
terminologie d’Or-BAC, nous avons :
- Les organisations : centre dentaire, cabinet dentairei, cabinet dentairej, cabinet dentairek,
service de réception, service administratif, service de comptabilité et laboratoire de
prothèse.
- Les relations de compositions entre organisations : sous-organisation(centre dentaire,
cabinet dentaire1), … , sous-organisation(centre dentaire, cabinet dentaire3), sous-
organisation(centre dentaire, service administratif), etc.
- Les rôles : administrateur, directeur, professionnel de santé, chirurgien dentiste, secrétaire,
comptable et prothésiste.
- Hiérarchie de rôles : "org Œ Organisation, sous-rôle (org, chirurgien dentiste,
professionnel de santé), sous-rôle(org, secrétaire médicale, professionnel de santé), etc.
- Les rôles joués dans les organisations : RdO(centre dentaire, s1, directeur), RdO(cabinet
dentaire1, s1, chirurgien dentiste), RdO(cabinet dentaire1, s2, assistante dentaire),
RdO(cabinet dentaire2, s3, chirurgien dentiste), RdO(service de réception, s6, secrétaire
médicale), RdO(service administratif, s7, secrétaire médicale), RdO(service de
comptabilité, s8, comptable), RdO(laboratoire de prothèse, s9, prothésiste), etc.
Étant donné que l’administrateur peut ajouter d’autres rôles ou organisations, et que le
directeur peut modifier la table du personnel du centre, la liste présentée ci-dessus n’est pas
limitative et peut évoluer au cours du temps. Toutefois, l’affectation d’un utilisateur à plusieurs
rôles doit respecter les règles d’exclusion mutuelle. Par exemple, un sujet ne peut pas être à la
fois comptable et directeur du centre.
Une analyse fonctionnelle détaillée de notre application est donnée en annexe D. Dans la
suite de cette section, nous ne présentons que certains aspects reliés à la sécurité. Les droits
d’accès implémentés sont ceux présentés dans le tableau 5.1 de la page 129. Nous avons ainsi
les objectifs et les règles de sécurité suivants :
- Objectifs de sécurité :
• il est interdit aux administrateurs, secrétaires, comptables, prothésistes et assistantes
de créer des ordonnances ;
• exceptés les dentistes traitants, les utilisateurs n’ont pas le droit d’accéder à la partie
interrogatoire ;
• seul le directeur peut mettre à jour la table du personnel ;
• les diagnostics ne peuvent jamais être effacés ;
• les opérations de soins ne sont permises qu’aux utilisateurs qui sont personnels
soignants en charge du patient ;
• le comptable a les droits “consultation et création” ainsi que les interdictions “non
mise à jour, non destruction” sur les factures de tous les patients ;
• ..
- Règles de sécurité :
• Dans des cas d’urgence où en plus, le dentiste traitant est absent, tout autre dentiste
peut accéder au dossier médical du patient en déclarant l’objectif d’utilisation urgence
145
Il est important de noter que la table “Rôle-dans-Unité” ne stocke jamais les attributs du rôle,
ni ceux de l’unité ; elle fait seulement référence aux clés étrangères “Id_Rôle” et “Id_Unité”.
La clé primaire de la table “Rôle-dans-Unité” est la concaténation de la clé de la table “Rôle”
et celle de l’unité. En outre, la contrainte “ON DELETE CASCADE” permet de maintenir
l’intégrité référentielle en supprimant automatiquement de la table Rôle-dans-Unité les valeurs
des clés étrangères Id_Rôle ou Id_Unité, à chaque fois que l’une de ces clés est supprimée des
tables “Rôle” ou “Unité”.
146 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
Pour implémenter une classe “B” qui hérite d’une classe “A”, il suffit de créer deux tables
“A” et “B” et de faire référence dans la table “B” à la clé de “A”.
Par ailleurs, les permissions, interdictions, obligations et recommandations sont gérées au
niveau du logiciel de programmation de la manière suivante :
- Les permissions sont implémentées à travers des capacités associées aux profils des RdO.
- La politique mise en œuvre considère que tout ce qui n’est pas explicitement autorisé est
interdit ; dans certains cas, des interdictions sont exprimées à travers des capacités
négatives et sont renforcées par des boîtes de dialogues indiquant à l’utilisateur qu’il n’est
pas autorisé à faire l’action demandée.
- Les obligations sont implémentées par des actions automatiques comme l’enregistrement
(automatique) de certaines données de connexion dans un fichier d’audit ou la fermeture
(automatique) de l’application.
- Les recommandations sont pour le moment implémentées à travers l’affichage d’une boîte
de dialogue avec un message “de recommandation” ainsi qu’un enregistrement
automatique du choix fait par l’utilisateur. Ainsi, nous pensons qu’une recommandation
est une autorisation qui, si elle n’est pas respectée, engage la responsabilité de l’utilisateur
(c’est la raison pour laquelle le système enregistre le choix de l’utilisateur).
À chaque connexion, l’identification et l’authentification se font par vérification, dans la
table “utilisateur”, du “nom de login” et du mot de passe comme indiqué dans la figure 6.9.
" select * from Users where Login = '" & txtlogin.Text & "'", cn,
adOpenKeyset
If rs.RecordCount = 0 Then
MsgBox " L'utlisateur n'existe pas ! "
vbCritical, " Erreur de connexion "
txtlogin.Text = ""
Else
If rs.Fields("Password") <> txtpassword.Text Then
MsgBox " Mot de passe incorrect ! "
Else
loginconnexion = rs!login
passwordconnexion = rs!Password
libuser = rs!Lib_User
profil = rs!Cod_Profil
dateconnexion = rs!Dat_Connexion
heureconnexion = rs!Hr_Connexion
rs.Close
Unload Frm_Connexion
menuprincipal.Show 1
End If
End If
correspondant aux profils inférieurs au profil “5” ont la permission de visualiser (VdO “show”)
les dossiers des patients (éléments de la VdO “frm_patient_U1”).
L’application “contrôle d’accès pour un centre dentaire”, ainsi présentée et modélisée, a été
implémentée en utilisant Visual Basic 6. Elle est disponible sous forme de démonstration.
Outre l’aspect sécurité, son utilisation par tous types d’utilisateurs est facile. Elle répond à nos
besoins : réalisation d’un contrôle d’accès respectant notre politique de sécurité, automatisation
de la recherche d’informations autorisées sur les patients (gain de temps et disponibilité),
possibilité d’ajouts de nouveaux utilisateurs, rôles, organisations, etc. Cette application est,
pour le moment, restreinte à une implémentation logicielle des permissions par des listes de
contrôles d’accès, et des interdictions par des capacités négatives. Elle pourrait être étendue
pour intégrer de nouveaux mécanismes de contrôles d’accès.
Bien évidemment, les apports d’Or-BAC vont au délà de la mise en œuvre décrite ci-dessus ;
et nous sommes actuellement en train d’implémenter Or-BAC dans un environnement -
heterogène et distribué - faisant intervenir deux organisations distantes (deux hôpitaux). Le but
est de montrer qu’Or-BAC fournit un cadre homogène ou chaque organisation spécialise
(implémente) ses entités (activités, vues, etc.) comme elle le souhaite.
La première organisation utilise des documents XML alors que la deuxième utilise une base
de données. Il en découle que la même vue (mais aussi la même activité) est implémentée
différement dans chacun des deux hôpitaux.
Un utilisateur commence par se connecter, puis envoie au serveur d’autorisation (application
client-serveur) son RdO (rôle dans une organisation), ainsi que la VdO (vue dans une
organisation). Leserveur d’autorisation (SA) effectue les tâches suivantes :
- extrait les règles concernées (qui font intervenir le RdO et la VdO) ;
- construit une capacité (un objet au sens orienté-objet) contenant les paramètres utils {RdO,
VdO, (P/I/O/R, Activité1, contexte1), (P/I/O/R, Activité2, Contexte2), .. , (P/I/O/R,
Activitén, Contexten)} ; ce qui signifie que le RdO à la permission, l’interdiction,
l’obligation ou la recommandation de réaliser Activité1, (resp. Activité2, .. Activitén) sur la
VdO dans Contexte1, (resp. Contexte 2, .. Contexte n) ; un contexte peut être une durée de
validité, un processus, etc. ;
- envoie la capacité à l’utilisateur.
L’utilisateur présente cette capacité au moniteur de référence38 de l’objet demandé (une table
de la base de données, par exemple) en précisant l’activité demandée lors de cet accès. Le
moniteur de référence (situé sur la machine de l’objet demandé) déduit l’action à réaliser (à
38
Le moniteur de référence regroupe les mécanismes de protection permettant de garantir le contrôle
d’accès et de flux définis par la politique de sécurité. Toute tentative d’accès est réalisée via le moniteur
de référence qui vérifie que chaque accès d’un sujet vers un objet est garanti par un droit d’accès.
148 Chapitre 6 Application d’Or-BAC aux SICSS et mise en oeuvre
partir de l’activité), vérifie si le contexte est vrai, et donne sa décision (permission, interdiction,
obligation ou recommandation). Cette décision sera traduite par des mécanismes locaux
d’accès.
Pour l’implémentation, nous avons fait les choix suivants (liste non exhaustive) :
- le langage java pour la programmation ;
- l’API JDBC pour l’accès à la base de données ;
- JAVA RMI pour l’invocation des objets distants ; pour un objet client, l’invocation est
effectuée d’une manière transparente qu’elle soit faite sur un objet distant ou local ;
- Un formatage de données avant la transmission et, de l’autre côté de la communication,
une adaptation aux logiciels de la machine locale de l’utilisateur lors de l’accès (pour
visualisation ou modification, par exemple) ; pour cela, on utilise des Applets java ;
- Le serveur d’autorisation contient les règles de la politique de sécurité sous forme
d’enregistrements d’une table ; la centralisation ainsi que l’isolation des règles de la
politique de sécurité du reste de l’application, nous facilitera la tâche de vérification de la
cohérence et de la complétude de cette politique.
Conclusion générale
Ce mémoire présente une démarche rigoureuse - fondée sur une politique de sécurité - pour
mettre en œuvre une sécurité de bon niveau dans les systèmes d’information et de
communication. Cette démarche a été appliquée aux domaines de la santé et des affaires
sociales, qui présentent l’intérêt de combiner de fortes exigences de confidentialité, d’intégrité
et de disponibilité, mais aussi de responsabilité.
En conclusion rappelons la logique adoptée tout au long de ce travail, et résumons les
résultats obtenus.
Tout d’abord, plutôt que de dresser un état de l’art exhaustif des politiques, modèles et
mécanismes de sécurité, nous avons adopté une analyse pragmatique, opposant ces méthodes
aux besoins réels des SICSS. Le but est non seulement de proposer une sécurité robuste et bien
fondée théoriquement, mais aussi flexible et adaptée aux demandes des usagers. Nous avons
également opté pour une diversification des méthodes et outils utilisés pour la construction
(progressive) de chaque solution proposée : visions génie-logiciel et formelle ; modélisation
par MERISE et par UML ; développement d’un langage basé sur la logique du premier ordre,
puis d’un autre basé sur la logique déontique, etc.
Le mémoire s’est organisé autour des axes suivants :
Présentation de l’état des lieux sectoriel, conceptuel et terminologique en sécurité pour les
SICSS. Cette étape commence par une description sectorielle fondée essentiellement sur les
textes juridiques relatifs aux SICSS, puis présente et établit les liens entre les concepts et
termes classiques de la sûreté de fonctionnement en général, et de la sécurité informatique en
particulier.
Discussion de politiques classiques de sécurité. Cette partie étudie en détail les avantages et
les limites de chacune des principales politiques existantes. Une réflexion particulière est
portée à la difficulté de l’application de ces approches aux SICSS : certaines introduisent une
rigidité parfois incompatible avec les usagers, d’autres ne tiennent pas compte du contexte et
ne permettent pas de représenter des interdictions et des recommandations, etc. Dans le même
sens, les modèles actuels sont parfois trop complexes ou difficiles à administrer.
Élaboration de politiques de sécurité pour les SICSS. Nous avons, tout d’abord, montré que
la définition d’une politique de sécurité est une étape nécessaire pour obtenir des systèmes
pouvant satisfaire des exigences de sécurité élevées. Nous avons ensuite proposé une
méthodologie dont les principales étapes sont : la description du système, l’identification des
informations à protéger, la caractérisation des menaces, l’expression des objectifs de sécurité
ainsi que des règles qui déterminent comment l’information sensible et les autres ressources
sont gérées, protégées, et distribuées. Cette démarche est enfin appliquée pour établir une
politique de sécurité dans un exemple de système d’information médicale, et une autre pour un
exemple de la sphère sociale.
Présentation d’un nouveau modèle de sécurité. Pour spécifier les politiques développées,
nous avons proposé, avec nos partenaires des sous-projets 3 et 4 de MP6, le nouveau modèle
150 Conclusion générale
Or-BAC. Celui-ci permet d’exprimer des permissions, des interdictions et des obligations, mais
aussi des recommandations, concept fort utile dans le domaine de la santé. Or-BAC permet
également de prendre en compte des informations de contexte dans l’expression des règles, afin
de spécifier un contrôle d’accès fin et adapté. Il est aussi un moyen de spécifier, dans un cadre
homogène, plusieurs politiques de sécurité pour des organisations différentes devant coopérer.
Modélisation formelle d’Or-BAC. Nous avons opté pour l’utilisation de la logique déontique
pour fournir un cadre permettant de spécifier formellement une politique de sécurité basée sur
Or-BAC. Cette spécification peut éventuellement servir à raisonner sur la politique de sécurité,
sa cohérence, sa complétude, etc. Si la politique de sécurité est représentée dans un langage de
la logique déontique, la méthode des tableaux nous semble idéale pour effectuer de telles
vérifications. Par ailleurs, la logique possibiliste peut servir à résoudre les conflits éventuels
dans la politique de sécurité.
Intégration dans un cadre de génie logiciel. Le modèle Or-BAC est d’abord représenté avec
des diagrammes UML, puis intégré dans une démarche UML globale, couvrant à la fois les
aspects statiques et dynamiques de la sécurité.
Développement d’un logiciel intégrant notre politique d’autorisation. Cette étape distingue
deux types d’analyses : une analyse fonctionnelle (de l’application elle-même) couvrant les
aspects conceptuels, organisationnels et opérationnels, préalable à la mise en œuvre ; puis
indépendamment, une autre analyse sécuritaire éclaircissant le passage entre la politique de
sécurité et les mécanismes de contrôle d’accès utilisés. Un logiciel de gestion d’un centre
dentaire a été implémenté pour démontrer la faisabilité d’une implémentation en vraie grandeur
les différentes facettes d’une politique Or-BAC.
Même si le travail présenté aboutit à une implémentation, un certain nombre de points restent
à étudier. Ainsi, plusieurs perspectives de recherches peuvent être distinguées :
- Développer un scénario plus riche où plusieurs organisations de grandes tailles coopèrent,
et utiliser le formalisme logique associé à Or-BAC pour effectuer un certain nombre de
vérifications sur ce scénario. Les vérifications de la politique de sécurité peuvent porter sur
la consistance, la complétude, la non-existence de canaux d’inférence, etc. Il peut
également s’avérer important d’automatiser le test de la cohérence des politiques de
sécurité, c’est-à-dire la détection des conflits. Ceux-ci peuvent éventuellement être résolus
par la logique possibiliste [Benferhat et al. 2003].
- Afin de faciliter la conception et la manipulation de politiques fondées sur Or-BAC, il
serait souhaitable d’utiliser une représentation graphique dont l’intérêt pratique peut
s’avérer significatif si cette représentation est supportée par un outil d’édition.
- Éclaircir le passage de la politique aux mécanismes de sécurité (capacités distribuées,
interprétations XML, etc.). Dans les bases de données, ce passage serait automatisable
tandis que dans d’autres environnements, la politique serait interprétée dans un serveur
d’autorisation.
- Il est nécessaire d’approfondir les études concernant la propriété de disponibilité, propriété
importante dans bon nombre d’applications émergentes ou futures. Des investigations
doivent être menées tant sur la façon de spécifier formellement le concept de disponibilité
et le problème du déni de service au moyen d’une politique de disponibilité, que sur les
mécanismes capables d’implémenter cette propriété.
Annexe A!: menaces pouvant avoir des
conséquences dans le monde médical
MAHOS
FOIN
Déchiffrement
Cette annexe a pour objectif de présenter de manière synthétique la notation UML. Elle se
décompose en deux parties, la première propose un résumé d’UML, la seconde présente les
différents diagrammes UML utilisés dans le chapitre 4.
39
En fait, tout les objets n’ont pas besoin d’un diagramme des états, seuls les objets actifs en
nécessitent un. Un objet actif est un objet dont les opérations sont contraintes par son état interne.
163
Il est évident que lors de tout projet, la rédaction du code de programme est obligatoirement
devancée d’une méthode d’analyse fournissant une vue détaillée des problèmes à traiter. La
méthode “MERISE”, que nous avons adoptée lors de la réalisation de notre application, est une
méthode de conception et de modélisation des systèmes d’information qui repose sur une
architecture en trois cycles d’abstraction [Matheron 1998] :
- Niveau conceptuel : définit les fonctions réalisées par l’entreprise (en l’occurrence le
centre dentaire). Il répond à la question : “quoi ?” et aide ainsi à comprendre le
fonctionnement et à modéliser les données, les traitements et les communications.
- Niveau logique (ou organisationnel) : complète l’analyse en décrivant les fonctions des
acteurs, “qui ? quand ? où ?”, ainsi que les processus de l’organisation “qui fait quel
traitement, quand et où ?”.
- Niveau physique (ou opérationnel) : finalise le travail en indiquant comment les données et
les programmes sont implémentés et réalisés.
Dans le reste de ce chapitre, nous détaillons chacun de ces niveaux.
(Co)
Telbpatient Tel bureau N E 10
Teldpatient Tel domicile patient N E 10
Telppatient Tel portable patient N E 10
Adresse électronique
Emailpatient AN E 20
patient
Diagpatient Diagnostic du patient AN E 30
Interpatient Interrogatoires du patient AN E 30
Ndentiste Numéro dentiste N E 2
Nmdentiste Nom dentiste A E 10
Prdentiste Prénom dentiste A E 10
Spdentiste Spécialité dentiste A E 10
Numéro carte d’identité du
Ncindentiste AN E 8
dentiste
Sexedentiste Sexe dentiste A E 9
Dndentiste Date naissance dentiste AN E 12
Dtembdentiste Date d’embauche dentiste AN E 12
Ancdentiste Ancienneté dentiste N E 2
Addentiste Adresse dentiste AN Co 30
Telbdentiste Téléphone bureau dentiste N E 10
Tepdentiste Téléphone portable dentiste N E 10
Faxdentiste Fax dentiste N E 10
Adresse électronique
Emaildentiste AN E 20
dentiste
Ntechnicien Numéro technicien N E 2
Nmtechnicien Nom technicien A E 10
Prtechnicien Prénom technicien A E 10
Sexetechnicie
Sexe technicien A E 9
n
Ncintechnicie Numéro carte identité.
AN E 8
n technicien
Date de naissance
Dntechnicien AN Co 12
technicien
Dtembtechnic
Date d’embauche AN E 12
ien
anctechnicien Ancienneté technicien N E 2
Teldtechnicie Téléphone domicile
N E 10
n technicien
Telptechnicie Téléphone portable
N E 10
n technicien
Emailtechnici Adresse électronique
AN E 20
en technicien
166 Annexes
Le graphe de dépendance fonctionnelle correspondant est donné dans la figure D2, utilisant
les codes indiqués dans l’annexe E.
Nord
Nfact Qté -durée
Médicament
Prothèse Soins dentaire
1,1 1,1
Provoque 1 Provoque 2
Facture 1,1 0,1 Intervention 0,1 Ordonnance
Nintervention
Nfacture Dent soignée Nordonnance
Date, H, Ob
1,n
1,n 1,n Médicament
1,n
1,n
Technicien
Type Médicament
Ntechnicien
CodTyMed
Arrivée du patient
Enregistrement patient
Nom et prénom obligatoire
1
Patient enregistré
1et 2
Établissement rendez-vous
Prise en charge temps disponible
Patient traité
Ndossier
Nrdv
Dtrdv
Hrdv
Obrdv
Table : patient
Champ Description Longueur Type Clé
Ndossier Numéro dossier 6 Numérique Oui
Nmpatient Nom patient 10 Texte N
Prpatient Prénom patient 10 Texte N
Foncpatient Fonction patient 9 Texte N
NSSpatient Numéro de sécurité sociale du patient 8 Texte N
Dnpatient Date naissance patient 12 Texte N
Agepatient Age du patient 2 Texte N
171
Table : dentiste
Champ Description Longueur Type Clé
Ndentiste Numéro dentiste 2 Numérique Oui
Nmdentiste Nom dentiste 10 Texte N
Prdentiste Prénom dentiste 10 Texte N
Spdentiste Spécialité dentiste 10 Texte N
Ncindentiste Numéro CIN dentiste 8 Texte N
Sexedentiste Sexe dentiste 9 Texte N
Dndentiste Date naissance 12 Texte N
Agedentiste Age dentiste 2 Texte N
Dtembdentiste Date d’embauche 12 Texte N
Ancdentiste Ancienneté dentiste 2 Texte N
Addentiste Adresse dentiste 30 mémo N
Telddentiste Téléphone bureau du dentiste 10 Texte N
Telpdentiste Téléphone portable du 10 Texte N
dentiste
Faxdentiste Fax dentiste 10 Texte N
Emaildentiste mél dentiste 30 Mémo N
Table : rendez-vous
Champ Description Longueur Type Clé
Nrdv Numéro rendez-vous 2 Numérique Oui
Dtrdv Date rendez-vous 12 Texte N
Hrdv Heure rendez-vous 4 Texte N
Obrdv Observation rendez-vous 30 mémo N
Table intervention
Champ Description Longueur Type Clé
Ninter Numéro intervention 6 Numérique Oui
172 Annexes
Table : facture
Champ Description Longueur Type Clé
Nfact N° facture 6 Numérique Oui
Ninter N° intervention 6 Numérique N
Dtfact Date facture 12 Texte N
Libfact Libellé facture 10 Texte N
Mopay Mode paiement 10 Texte N
Mtfact Montant facturé 5 Numérique N
Avfact Avance de la facture 5 Numérique N
Recfact À recevoir 5 Numérique N
Table : ordmed
Champ Description Longueur Type Clé
Nord N° ordonnance 5 Numérique Oui
Codmed Code médicament 5 Texte Oui
Qtmed Quantité médicament 10 Texte N
Dureemed Durée médicament 2 Numérique N
Références bibliographiques
[Abou El Kalam 2002] A . Abou El Kalam, “Politiques de sécurité pour les systèmes
d’informations médicales”, Cinquièmes Journées Doctorales en Informatiques et Réseaux
(JDIR 2002), Toulouse, 4-6 mars 2002, pp. 201-210.
[Abou El Kalam et al. 2002a] A. Abou El Kalam, F. Cuppens, Y. Deswarte, L. Merrouche, C.
Saurel, G. Trouessin, Modèles et politiques de sécurité des systèmes d’informations et de
communications en santé et en social : Etat des lieux scientifico-technologique, Rapport
LAAS n° 02091, mars 2002, 32 pp.
[Abou El Kalam et al. 2002b] A. Abou El Kalam, Y. Deswarte, D. Powell, Modèles et
politiques de sécurité des systèmes d’informations et de communications en santé et en
social : concepts et terminologie génériques, Rapport LAAS n° 02268, juillet 2002, 22 pp.
[Abou El Kalam et al. 2002c] A. Abou El Kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y.
Deswarte, R. El Baida, F. Nambot, C. Saurel, G. Trouessin, Modèles et politiques de
sécurité des systèmes d’informations et de communications en santé et en social :
informations à protéger et menaces, Rapport LAAS n° 02334, septembre 2002, 34 pp.
[Abou El Kalam & Deswarte 2002] A. Abou El Kalam, Y. Deswarte, “Contrôle d’accès basé
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é”, Actes de la conférence Sécurité et
Architecture des Réseaux (SAR’02), Marrakech, 8-12 juillet 2002, 11pp.
[Abou El Kalam & Deswarte 2003a] A. Abou El Kalam, Y. Deswarte, “Security model for
Health Care Computing and Communication Systems”, 18th International Information
Security Conference (IFIP SEC 2003), Athènes, 26-28 mai 2003, Kluwer Academic
Publishers, pp. 277-288.
[Abou El Kalam et al. 2003a] A. Abou El Kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y.
Deswarte, R. El-Baida, A. Miège, C. Saurel, G. Trouessin “Organization-Based Access
Control”, 4th International Workshop on Policies for Distributed Systems and Networks
(Policy’03), Côme, Italie, 4-6 juin 2003, IEEE Computer Society Press, pp. 120-131.
[Abou El Kalam et al. 2003b] A. Abou El Kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y.
Deswarte, R. El-Baida, A. Miège, C. Saurel, G. Trouessin “Un modèle de contrôle d’accès
basé sur les organisations”, Cahiers francophones de la recherche en sécurité de
l’information, n° 2, Université de Montpellier I, premier trimestre 2003, pp. 30-43.
[Abou El Kalam et al. 2003c] A. Abou El Kalam, Y. Deswarte, G ; Trouessin, E. Cordonnier
"MP6 : Spécification d’un prototype d’anonymisation", septembre 2003, 34 pp, Rapport
LAAS 3525.
[Abou El Kalam et al. 2003d] A. Abou El Kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y.
Deswarte, R. Elbaida, C. Saurel, G. Trouessin, “Modèles et politiques de sécurité des
SICSS”, 1ère Conférence Francophone en Gestion et Ingénierie des Systèmes Hospitaliers
(GISEH), Lyon, janvier 2003, pp.268-277.
174 Références bibliographiques
[CEN 1999] CEN/TC 251/WG I, Norme prENV 13606-3: Health Informatics - Electronic
Healthcare Record Communication, n° 99-046, Comité Européen de Normalisation, 27 mai
1999.
[Chellas 1980] B.F. Chellas, “Modal Logic : An Introduction”, Cambridge University Press,
1980, ISBN 0-521-29515-7, 295 pp.
[Cheng 1999] E. C. Cheng, “An Object-Oriented Organizational Model to Support Dynamic
Role-Based Access Control in Electronic Commerce Applications”, 32nd Annual Hawaii
International Conference on System Sciences (HICSS-32), Maui, Hawaii, 5-8 janvier 1999.
[Cheswik & Bellovin 1994] W.R. Cheswik, S.M. Bellovin, Firewalls and Internet Security,
Addison-Wesley, IBSN 0-201-63357-4, 1994.
[Circulaire 1989] Circulaire DH/PMSI n° 303 du 24 juillet 1989 relative à la généralisation du
Programme de médicalisation (BOMS n° 89/46), Ministère de l’emploi et de la solidarité,
France.
[Circulaire 1998] Circulaire n° 153 du 9 mars 1998 relative à la généralisation dans les
établissements de santé sous dotation globale et ayant une activité de soins de suite ou de
réadaptation d’un recueil de RHS, ministère de l’emploi et de la solidarité, France.
[Clavel et al. 2002] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Marti-Oliet, J. Mesequer, J.
Quesada, “Maude: Specification and Programming in Rewriting Logic”, Theoretical
Computer Science, vol. 285, n°. 2, pp. 187-243, Elsevier, Amsterdam, 2002.
[Clercq 1998] E. De Clercq, D. Deliège et C. Christoph, “Dossier médical, réseaux et système
intégré de soins”, Septièmes Journées Francophones d’Informatique Médicale, Société
Belge d’Informatique Médicale : Santé et réseaux informatiques, Liège, 24-25 avril 1998,
Informatique et Santé, 1998, Springer-Verlag France, vol. 10, pp. 56-64.
[Clark & Wilson 1987] D.Clark, D.Wilson, “A Comparison of Commercial and Military
Computer Security Policies”, IEEE Symposium on Security and Privacy, Oakland,
Californie, 27-29 avril 1987, IEEE Computer Society Press, pp. 184-194.
[Code 1995a] Code de déontologie médicale, décret 95-1000 du 6 septembre 1995.
[Code 1995b] Code de la santé publique, Code de la famille et de l’aide social, Paris, Dalloz,
1995.
[CTCPEC 1993] The Canadian Trusted Computer Product Evaluation Criteria, Canadian
System Security Center, Communication Security Establishment, Governement of Canada,
version 3.0, janvier1993.
[Cuppens & Saurel 1996] F. Cuppens, C. Saurel, “Specifying a Security Policy: a Case Study”,
9th IEEE Computer Security Foundations Workshop, Kenmare, County Kerry, Irlande, 10-
12 juin 1996, IEEE Computer Society Press, pp. 123-134.
[Cuppens & Ortalo 2000] F. Cuppens, R. Ortalo, “A Language to Model a Database for
Detection of Attacks”, 3 rd International Workshop on Recent Advances in Intrusion
Detection (RAID). Toulouse, France, 2-4 octobre 2000, Springer, pp. 197-216.
[Cuppens & Saurel 1999] F. Cuppens, C. Saurel, “Toward a Formalization of Availability and
Denial of Service”, in Information Systems Technology Panel Symposium on Protection
Nato Information Systems in 21st Century, Washington, octobre 1999.
177
[Cuppens & Miège 2003a] F. Cuppens, A. Miège, “Administration Model for Or-BAC”,
Workshop on Metadata for Security, International Federated Conferences (OTM’03),
Sicile, Italie, 3-7 novembre 2003.
[Cuppens & Miège 2003b] F. Cuppens et A. Miège, “Modelling Contexts in the Or-BAC
Model”, 19th Annual Computer Security Applications Conference (ACSAC’03), Las Vegas,
Nevada, 8-12 décembre, 2003, IEEE Computer Society.
[Cuppens 2003] F. Cuppens, “Sécurité des bases de données”, in Sécurité des réseaux et des
systèmes répartis, (Yves Deswarte & Ludovic Mé, eds), Traité IC2, Hermès, ISBN : 02-
7462-0770-2, 264 pp, octobre 2003.
[Cury & Debar 2001] D. Curry et H. Debar, Intrusion Detection Message Exchange Format
Data Model and XML Document Type Definition, draft-ietf-idwgidmef-xml-03.txt, février
2001.
[d’Ausbourg 1994] B. d’Ausbourg, “Implementing Secure Dependencies over a Network by
Designing a Distributed Security SubSystem”, in Third European Symposium on Research
in Computer Security (ESORICS’94), (D. Gollman, Ed.), Brington, United Kingdom,
Lecture Notes in Computer Science n° 875, novembre 1994, ISBN 3-540-58618-0,
Springer-Verlag, pp. 249-266.
[Dacier 1993] M. Dacier, “A Petri Net Representation of the Take-Grant Model”, in Computer
Security Foundations Workshop VI, Franconi, USA, 15-17 juin 1993, IEEE Computer
Society Press, pp. 99-108.
[Dacier 1994] M. Dacier, Vers une évaluation quantitative de la sécurité informatique, Thèse
de doctorat, Institut National Polytechnique de Toulouse, N° 971, 154 pp., 20 décembre
1994 (Rapport LAAS 94488).
[Dacier & Deswarte 1994] M. Dacier et Y. Deswarte, “Privilege Graph: an Extention to the
Typed Access Matrix Model”, in Third European Symposium on Research in Computer
Security (ESORICS’94), (D. Gollman, Ed.), Brington, United Kingdom, Lecture Notes in
Computer Science n° 875, novembre 1994, ISBN 3-540-58618-0, Springer-Verlag, pp.
319-334.
[Damianou et al. 2002] N. Damianou, N. Dulay, E. Lupu et M. Sloman. “The Ponder Policy
Specification Language”, International Workshop on Policies for Distributed Systems and
Neworks (Policy 2001). Bristol, UK, IEE Computer Society Press, pp.18- 38, 29-31 Janvier
2001.
[Debar & Wespi 2001] H. Debar, A. Wespi, “Agregation and Correlation of Intrusion-
Detaction Alerts”, 4th International Workshop on Recent Advances in Intrusion Detection
(RAID), Californie (USA) , 10-12 octobre 2001, Springer, pp. 197-216.
[Décret 1994] Décret n° 94-666 du 27 juillet 1994 relatif aux systèmes d’information médicale
et l’analyse de l’activité des établissements de santé publics et privés sous compétence
tarifaire de l’État, modifié par le décret n° 98-63 du 2 février 1998.
[Décret 2002] Décret 2002-637 du 29 avril 2002 relatif à l’accès aux informations personnelles
détenus par les professionnels et les établissements de santé en application des articles
L.1111-7 et L.1112-1 du code de la santé publique.
[Degoulet 1989] P. Degoulet, J.-C. Stéphan, A. Venot et P.-J. Yvon, Informatique et Gestion
des Unités de Soins - Informatique et Santé – vol. 1, Springer-Verlag France, pp. 257-268,
juin 1989.
178 Références bibliographiques
[Degoulet 1992] Degoulet P., Fieschi M., Traitement de l’information médicale - Méthodes et
applications hospitalières, Collection : Manuels Informatiques Masson - Entreprise, Paris,
1992, 269 pp., ISBN: 2225825149.
[Deliège 2001] D. Deliège, “A Classification System of Social Problems - Concepts and
impact on Gps’ registration of problems”, Second International Conference on Social Work
in Health and Mental Health Care, Melbourne, 12-15 janvier 1998 : 25, Social Work in
Health Care, 2001.
[Denning 1979] D. Denning et P. Denning, “Data Security”. ACM Computer Survey, vol. 11,
n° 3, septembre 1979, ACM Press, ISBN : 0360-0300, pp. 227-249.
[Directive 1995] Directive 95/46/CE du Parlement Européen, adoptée par le Conseil Européen
le 24 juillet 1995, On the protection of individuals with regard to the processing of
personnal data and on the free movement of such data, 1995.
[Directive 2002] Directive du Parlement Européen n° 2002/58/EC concernant “le traitement
des données à caractère personnel et la protection de la vie privée dans le secteur de
télécommunications électroniques”, 12 juillet 2002, Journal Officiel L 201, 31-7-2002, pp.
37-47.
[Deswarte et al. 1999] Y. Deswarte, K. Kanoun , J.C. Laprie, “Diversity Against Accidental
and Deliberate Faults”, in Computer Security, Dependability and Assurance: From Needs
to Solutions, P. Amman, B.H. Barnes, S. Jajodia, E.H. Sibley (Eds.), IEEE Computer
Society Press, 1999, pp.171-181.
[Deswarte et al. 2001] Y. Deswarte, N. Abghour, V. Nicomette, D.Powell, “An Internet
Authorization Scheme using Smartcard-based Security Kernels”, International Conference
on Research in Smart Cards (e-Smart 2001), Cannes (France), 2001, "Smart Card
Programming and Security", I. Attali and T. Jensen (Eds.), Springer-Verlag, LNCS 2140,
pp. 71-82.
[Deswarte et al. 2002] Y. Deswarte, N. Abghour, V. Nicomette, D.Powell, “An Intrusion-
Tolerant Authorization Scheme for Internet Applications”, Supp. to the proceedings of the
2002 Int. Conf. on Dependable Systems & Networks (DSN 2002), Workshop on Intrusion
Tolerant Systems, Washington (USA), 23-26 juin 2002, pp. C1.1-C1.6.
[Deswarte 2003] Y. Deswarte, “La sécurité des systèmes d’information et de communication”,
in Sécurité des réseaux et des systèmes répartis, (Yves Deswarte & Ludovic Mé, eds),
Traité IC2, Hermès, ISBN : 02-7462-0770-2, 264 pp, octobre 2003.
[Fabre et al. 1996] J.C. Fabre, Y. Deswarte, L. Blain, “Tolérance aux fautes et sécurité par
fragmentation-redondance-dissémination”, Technique et Science Informatiques (TSI),
Vol.15, n° 4, 1996, Hermes, pp.405-427.
[Federal Criteria 1992] Federal Criteria for Information Technology Security, National
Institute of Standards and Technology (NIST) and National Security Agency (NSA), vol. I
and II, Draft, 1992.
[Ferraiolo et al. 2001] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn and R. Chandramouli
“A Proposed Standard for Role-Based Access Control”, ACM Transactions on Information
and System Security, vol. 4, n° 3, août 2001.
[Fitting 1993] M. Fitting, “Basic Modal Logic”, Handbook of Logic in Artificial
Intelligence and Logic Programming Logic Foundations, (D.M. Gabbay, C.J. Hogger, J.A.
Robinson, Eds.). Vol. 1/5, pp.365-448, ISBN 0-19-853745-X, Oxford Science Publications,
1993.
179
[Oh & Sandhu 2002] S. Oh, R.S. Sandhu, “A Model for Role Administration Using
Organisation Structure”, in Proceeding of the 7th ACM Symposium on Access Control
Models and Technologies (SACMAT 2002), Monterey, Californie, 3-4 juin 2002, ACM
press, pp. 155-162.
[Ordonnance 1996] Ordonnance n° 96-346 du 24 avril 1996 portant réforme de
“l’hospitalisation publique et privée des systèmes d’information et à l’organisation
médicale dans les hôpitaux publics”.
[Ortalo 1998a] R. Ortalo, “A Flexible Method for Information System Security Policy
Specification”, in 5th European Symposium on Research in Computer Security (ESORICS
98), Louvain-La-Neuve, Belgique, 16-18 Septembre 1998, Lecture Notes in Computer
Science n° 1485, Springer-Verlag, pp. 67-84.
[Ortalo 1998b] R. Ortalo, “Evaluation quantitative de la sécurité des systèmes d’information”,
Thèse de doctorat, Institut National Polytechnique de Toulouse, n° 1418, 166 pp., 18 mai
1998 (Rapport LAAS 98164).
[Ortalo 1999] R. Ortalo, Y. Deswarte, M. Kaâniche, “Experimenting with Quantitative
Evaluation Tools for Monitoring Operational Security”, IEEE Transactions on Software
Engineering, Vol.25, N°5, pp. 633-650, septembre/octobre 1999.
[Powell & Stroud 2003] D. Powell, R. Stroud (Eds.), Malicious- and Accidental-Fault
Tolerance for Internet Applications: Conceptual Model and Architrecture, Final Version,
Rapport LAAS n°03011, Projet IST-1999-11583 MAFTIA, Deliverable D21, janvier 2003,
123 pp., disponible à <http://www.research.ec.org/maftia/deliverables/>.
[Quantin et al. 1898] C. Quantin, H. Bouzelat, FA. Allaert, AM. Benhamiche, J. Faivre et L.
Dusserre, “How to ensure data security of an epidemiological follow-up: quality assessment
of an anonymous record linkage procedure”, International Journal of Medical Informatics
49 (1998) 117-122.
[Rabin 1989] M.O. Rabin, “Efficient Dispersal of Information for Security”, Load Balancing
and Fault Tolerance”, J. of the ACM, vol. 36, n° 2, pp. 335-348, 1989.
[Recommendation 1992] Recommendation of the “Communication of Health Information in
Hospitals”, European Health Commitee CDSP (92)8, Council of Europe, Strasbourg, 21
juin 1992.
[Recommandation 1997] Recommandations du Conseil de l’Europe, R(97)5, On The
Protection of Medical Data Banks, Council of Europe, Strasbourg, 13 février 1997.
[Résolution 1990] Résolution A/RES/45/95 Assemblée générale des Nations Unies, Principes
directeurs pour la réglementation des fichiers personnels informatisés, 14 Décembre 1990.
[Séminaire 2001] Séminaire de la société Française de statistique, Appariements sécurisés et
statistique publique, organisé par le groupe Statistique économique et sociale par Benoît
Riandey (INED-SfdS), 28 février 2001.
[Sandhu 1992] R.S. Sandhu, “Expressive Power of the Schematic Protection Model”, Journal
of Computer Security, vol.1, n° 1, pp. 59-98, 1992.
[Sandhu et al. 1996] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, C.E. Youman, “Role-Based
Access Control Models”, IEEE Computer, vol. 29, n° 2, pp.38-47, février, 1996.
182 Références bibliographiques
[Sandhu 1996] R.S. Sandhu, “Role Hierarchies and Constraints for Lattice-Bases Access
Controls”, in 4th European Symposium on Research in Computer Security (ESORICS’96),
(E. Bertino, H. Kurth, G. Martella, E. Mon,tolivo, Eds.), Rome, Italie, september 25-27,
Lecture Notes in Computer Science 1146, pp. 65-79, ISBN 3-540-61770-1, Springer-
Verlag, 1996.
[Sandhu & Bhamidipati 1997] R.S. Sandhu, V. Bhamidipati, “The URA97 Model for Role-
Based User-Role Assignment”, in Proceeding of IFIP WG 11.3 Workshop on Database
Securiy, Californie, 11-13 août 1997.
[Sandhu & al. 1999] R.S. Sandhu, V. Bhamidipati et Q. Munawer, “The ARBAC97 Model for
Role-Based Administration of Roles”, ACM Transactions on Information and System
Security (TISSEC), vol. 2, n° 1, février 1999, pp. 105-135.
[Sandhu & Munawer 1999] R.S. Sandhu, Q. Munawer, “The ARBAC99 Model for
Administration of Roles”, in Proceeding of the 15th Annual Computer Security Applications
Conference (ACSAC’99), Phoenix, Arizona, 6-10 décembre 1999, IEEE Computer Society,
pp. 229-241.
[Sandhu et al. 2000] R.S. Sandhu, D. Ferraiolo et R. Kuhn, “The NIST Model for Role-Based
Access Control: Towards a Unified Standard”, in 5th ACM Workshop on Role-Based Access
Control, Berlin (Allemagne), pp. 47-63, 2000.
[Saydjari et al. 1989] O.S. Saydjari, J.M. Beckman et J.R. Leaman, “LOCK Trek: Navigating
Unchartered Space”, International Symposium on Security and Privacy, Oakland (CA,
USA), pp. 167-177, IEEE Computer Society Press, 1989.
[SMA 1995] Swedish Medical Association, Information Technology: The Physician and the
Patient, Stockholm, SMA, 1995.
[Solms & Merwe 1994] S.H. von Solms et I. Van der Merwe, “The Management of Computer
Security Profiles Using a Role-Oriented Approach”, Computer & Security, vol.13, n° 8, pp.
673-680,1994.
[Synder 1981] L. Synder, “Theft and Conspiracy in the Take-Grant Model”, Journal of
Computer and System Sciences, vol. 23, pp. 333-347, 1981.
[TCSEC 1995] TCSEC, Trusted Computer System Evaluation Criteria, 122 pp., Department of
Defense (DoD), DoD Standard, DoD 5200.28-STD, 1985.
[Thomas 1997] R.K. Thomas, “TMAC: A primitive for Applying RBAC in Collaborative
Environment”, 2nd ACM Workshop on RBAC, FairFax, Virginia, USA, pp. 13-19, 6-7
novembre 1997.
[TNI 1987] TNI, Trusted Network Interpretation of the Trusted Computer System Evaluation
Criteria, NCSC-TG-005, National Computer Security Center, 31 juillet 1987, 278 pp.
[Totel 1998] E. Totel, “Politique d’intégrité multiniveau pour la protection en ligne de tâches
critiques”, Thèse de doctorat, Institut National Polytechnique de Toulouse, n° 1571, 145
pp., 18 mai 1998 (Rapport LAAS 98533).
[Trouessin 2000] G. Trouessin, Towards Trustworthy Security for Healthcare Information
Systems, Report N°GT/2000.03, CESSI/CNAM, juin 2000.
[Trouessin 2001] G. Trouessin, “Sécurité et intimité des données à caractère personnel”, La
Lettre d’ADELI n° 42, juillet 2001.
183
[Trouessin 2002] G. Trouessin, “L’évolution des normes de sécurité vers plus d’auditabilité des
systèmes d’information”, Colloque AIM à l’HEGP : « Présent et avenir des systèmes
d’information et de communication hospitaliers », 23-24 mai 2002 (à paraître chez
Springer-Verlag).
[Wang 1999] W. Wang, “Team-and-Role-Based Organizational Context and Access Control
for Cooperative Hypermedia Environments”, Proceeding of the 10th ACM Conference on
Hypertext and Hypermedia (Hypertext’99), Darmstadt, Germany, pp. 37-46, February 21-
25, 1999.
[Weissman 1992] C. Weissman, “BLACKER: Security for the DDN, Examples of A1 Security
Engineering Trades”, in EEE Symposium Research in Security ans Privacy, Oakland,
Californie, IEEE Computer Society Press, 4-6 mai 1992, pp. 286-292.
[Willikens et al. 2002] M. Willikens, S. Feriti et M. Masera, “A Context-related Autorisation
and Access Control Method Based on RBAC: A Case Study from the Health Care
Domain”, ACM Symposium on Access Control Models and Technologies, (SACMAT’02),
Californie, U.S.A., 3-4 juin 2002, pp. 177-124.
[Woodward 1995] B. Woodward, “The Computer-Based Patient Record and Confidentiality”,
New England Journal of Medicine, v. 333, n° 21, 1995, pp. 1419-1422.
[Zakinthinos & Lee 1994] A. Zakinthinos, E.S. Lee, “The Composability of Non-Interference”,
Journal of Computer Security, vol. 3, no. 4, pp.269-281, 1994.