Thse de Doctorat DAnas ABOU EL KALAM

MODLES ET POLITIQUES DE SECURITE POUR LES DOMAINES DE LA SANTE ET DES AFFAIRES SOCIALES

Rapport LAAS N 03578

Anne 2003 THSE Prsente au Laboratoire dAnalyse et dArchitecture des Systmes du Centre National de la Recherche Scientifique en vue dobtenir le titre de Docteur de lInstitut National Polytechnique de Toulouse Spcialit : Informatique

Par

Anas Abou El Kalam

MODLES ET POLITIQUES DE SECURITE POUR LES DOMAINES DE LA SANTE ET DES AFFAIRES SOCIALES

Soutenue le 04 dcembre 2003 devant le jury : Prsident Rapporteurs Examinateurs Yves DUTUIT Abdelmalek BENZEKRI Marc DACIER Frdric CUPPENS Yves DESWARTE Gilles TROUESSIN

Rapport LAAS N 03578 LAAS - CNRS 7, avenue du Colonel Roche 31077 Toulouse Cedex 4

Avant-Propos

Les travaux prsents dans ce mmoire ont t effectus au sein du Laboratoire dAnalyse et dArchitecture des Systmes du Centre National de la Recherche Scientifique (LAAS - CNRS). Je tiens remercier tout dabord Jean-Claude Laprie, ainsi que Malik Ghalab directeurs successifs du LAAS-CNRS pendant mon sjour, de mavoir permis de mener mes recherches dans ce laboratoire. Ma reconnaissance se tourne particulirement vers David Powell, ancien responsable du groupe Tolrance aux fautes et Sret de fonctionnement (TSF) et son successeur Jean Arlat, pour mavoir accueilli dans ce groupe de recherche. Mes plus grands remerciements sont naturellement pour Yves Deswarte, qui ma encadr tout au long de ma thse. Ma considration est inestimable. Ses remarques et critiques pertinentes mont conduit vers la bonne voie. Son soutien ma permis de ne jamais faiblir et de poursuivre toujours plus loin mes travaux. Je tiens galement souligner que la confiance quil a mise en moi a t un moteur ma russite. Jexprime ma gratitude Yves Dutuit, Professeur lUniversit de Bordeaux I, pour lhonneur quil me fait en prsidant mon Jury de Thse, ainsi qu : Abdelmalek Benzekri, Professeur lUniversit Paul Sabatier ; Frdric Cuppens, Professeur lEcole Nationale Suprieure de Tlcommunications (ENST-Bretagne) ; Marc Dacier, Professeur lInstitut Eurecom Sophia Antipolis, Professeur adjoint lUniversit de Lige et professeur visiteur lUniversit catholique de Louvain ; Yves Deswarte, Directeur de Recherche CNRS ; Gilles Trouessin, Directreur de mission Snior Ernst & Young Audit ;

pour lhonneur quils me font en participant mon jury. Je remercie particulirement Abdelmalek Benzekri et Marc Dacier qui ont accept la charge dtre rapporteur. Je voudrais galement remercier lensemble des partenaires du projet MP6 avec qui jai beaucoup appris, notamment Gilles Trouessin (responsable du projet MP6) Philippe Balbiani, Frdric Cuppens, Claire Saurel, Salem Benferhat, Alexandre Mige, Rania El-Baida et Didier Vinsonneau. Sans eux, ces travaux nauraient probablement pas t les mmes. Je remercie tout le groupe TSF, les permanents, les doctorants et les stagiaires. Mes remerciements sadressent galement lensemble des services du LAAS, qui permettent chacun de travailler dans les meilleures conditions. Il mest agrable de remercier chaleureusement tous ceux qui, en dehors du laboratoire, mont accompagn et soutenu. Je pense particulirement Betty qui ma beaucoup aid et qui a partag avec moi des moments faciles et difficiles durant ces trois annes.

Ces avant-propos seraient incomplets sans un remerciement adress aux membres de ma famille, en particulier mes parents et mon frre 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 mont soutenu et qui ont contribu mon enrichissement personnel. tous ces gens-l, je serais ternellement reconnaissant. Merci.

TABLE DES MATIERES

INTRODUCTION GNRALE ...........................................................................................................1 CHAPITRE 1. 1.1. SCURIT DES SYSTMES DINFORMATION ET DE COMMUNICATION EN SANT ET SOCIAL ...........................................................................................................3

CARACTRISTIQUES DES SYSTMES DINFORMATION ET DE COMMUNICATION EN SANT ET SOCIAL ..............................................................................................................4 1.1.1. Dfinition et enjeux .................................................................................................4 1.1.2. Complexit des SICSS .............................................................................................4 1.1.3. Diversit des exigences de scurit ........................................................................5 1.1.4. Menaces pesant sur les informations manipules par ces systmes......................6 1.2. CONCEPTS DE LA SRET DE FONCTIONNEMENT .............................................................7 1.2.1. Dfinitions de base ..................................................................................................7 1.2.2. Les fautes dues lhomme ......................................................................................8 1.3. LA SCURIT DES SYSTMES DINFORMATION .................................................................9 1.3.1. Introduction : dfinition de la scurit ...................................................................9 1.3.2. Confidentialit .......................................................................................................10 1.3.3. Intgrit..................................................................................................................11 1.3.4. Disponibilit ..........................................................................................................11 1.3.5. Autres facettes de la scurit ................................................................................12 1.4. INTRUSIONS, ATTAQUES, VULNRABILITS ...................................................................13 1.5. TECHNIQUES ET MCANISMES POUR SCURISER UN SYSTME ......................................15 1.5.1. Politiques de scurit ............................................................................................15 1.5.2. Autres contre-mesures...........................................................................................18
1.5.2.1 1.5.2.2 1.5.2.3 1.5.2.4 1.5.2.5 1.5.2.6 Mcanismes cryptographiques......................................................................................18 Cloisonnement et pare-feux ..........................................................................................22 Audit...............................................................................................................................23 Dtection dintrusions ...................................................................................................23 Tolrance aux intrusions ...............................................................................................25 valuation de la scurit................................................................................................26

CHAPITRE 2.

POLITIQUES ET MODLES DE SCURIT ...........................................................31

2.1. CLASSIFICATION DES POLITIQUES ET MODLES DE SCURIT .......................................32 2.2. POLITIQUES ET MODLES DAUTORISATION DISCRTIONNAIRES (DAC).......................33 2.2.1. Prsentation des DAC ...........................................................................................33 2.2.2. Modles associs aux DAC ...................................................................................34
2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.2.5 Modle de Lampson ......................................................................................................34 Modle HRU..................................................................................................................34 Modle Take-Grant........................................................................................................35 Modle TAM .................................................................................................................37 Graphe de privilges......................................................................................................38

2.3. POLITIQUES ET MODLES DAUTORISATION OBLIGATOIRES (MAC)..............................39 2.3.1. Les politiques multi-niveaux .................................................................................39

2.3.1.1 2.3.1.2

Politique du DoD et modle de Bell-LaPadula............................................................ 39 Politique dintgrit de Biba......................................................................................... 41

2.3.2. Politiques de Clark et Wilson................................................................................42 2.3.3. Politique de la muraille de Chine .........................................................................44 2.4. POLITIQUES DE CONTRLE DE FLUX ...............................................................................45 2.5. POLITIQUES DE CONTRLE DINTERFACES .....................................................................46 2.6. POLITIQUES ET MODLES DE SCURIT PAR RLES (RBAC)..........................................47 2.7. POLITIQUES ET MODLES DE SCURIT PAR QUIPES (TMAC)......................................49 2.7.1. Dfinition de TMAC ..............................................................................................49 2.7.2. C-TMAC : Context-TMAC ....................................................................................50 2.8. APPLICATION DE CES APPROCHES AUX SICSS...............................................................53 2.8.1. Discussion des politiques et modles existants ....................................................53 2.8.2. Politiques de scurit pour les SICSS...................................................................54
2.8.2.1 2.8.2.2 2.8.2.3 2.8.2.4 2.8.2.5 Politique de scurit de SEISMED .............................................................................. 54 Politique de scurit de la BMA................................................................................... 55 Politique de scurit de la SMA ................................................................................... 56 Recommandations de la FMAG ................................................................................... 56 Conclusion et prsentation du projet MP6................................................................... 56

CHAPITRE 3.

BTIR UNE POLITIQUE DE SCURIT POUR LES SICSS ....................................59

3.1. MTHODOLOGIE DE NOTRE APPROCHE...........................................................................60 3.1.1. Description dun scnario reprsentatif...............................................................60 3.1.2. Identification des informations protger ...........................................................60 3.1.3. Expression des objectifs de scurit .....................................................................61 3.1.4. Dfinition des rgles de scurit...........................................................................61 3.1.5. Modlisation formelle............................................................................................61 3.2. DE LA DESCRIPTION DES SICSS AUX BESOINS DE SCURIT SATISFAIRE ..................62 3.2.1. tude de cas 1 : Sphre mdicale .........................................................................62
3.2.1.1 3.2.1.2 3.2.1.3 3.2.1.4 3.2.1.5 Scnario ......................................................................................................................... 62 Informations protger................................................................................................. 64 Risques identifis .......................................................................................................... 65 Besoins de scurit........................................................................................................ 65 Rglement de scurit ................................................................................................... 67

3.2.2.
3.2.2.1 3.2.2.3

tude de cas 2 : Sphre sociale ............................................................................69

Scnario daccs en amont............................................................................................ 69 Ressources protger, menaces, exigences et rgles de scurit ............................... 74

Scnario daccs en aval.................................................................................................................. 72

3.2.3.
3.2.3.1 3.2.3.2 3.2.3.3 3.2.3.4 3.2.3.5

tude de cas 3 : Analyse de diffrents scnarios danonymisation dinformations mdicales ......................................................................................78

Problmatique de lanonymisation............................................................................... 78 Notion dobjectifs danonymisation............................................................................. 79 Notion dexigences danonymisation........................................................................... 80 Lanonymisation dans les pays europens ................................................................... 81 Scnario 1 : transfert des donnes mdicales............................................................... 87

3.2.3.6 3.2.3.7 3.2.3.8 3.2.3.9 3.2.3.10 3.2.3.11

Scnario 2 : unions professionnelles.............................................................................88 Scnario 3 : Programme de Mdicalisation des Systmes dInformation PMSI ...89 Scnario 4 : traitement des maladies dclaration obligatoire....................................90 Scnario 5 : traitements des donnes statistiques.........................................................91 Scnario 6 : tudes pidmiologiques focalises .........................................................93 Une nouvelle solution gnrique...................................................................................94

CHAPITRE 4.

LE MODLE OR-BAC .....................................................................................101

4.1. MOTIVATION .................................................................................................................102 4.2. CONCEPTS DE BASE DU MODLE OR-BAC...................................................................102 4.2.1. Organisations ......................................................................................................102 4.2.2. Rle dans Organisation (RdO) ...........................................................................103 4.2.3. Vue dans Organisation (VdO) ............................................................................104 4.2.4. Activit dans Organisation (AdO) ......................................................................105 4.2.5. Le contexte...........................................................................................................106
4.2.5.1 4.2.5.2 4.2.5.3 4.2.5.4 Contexte et contraintes du rle....................................................................................106 Contexte dobjet...........................................................................................................107 Attributs dutilisateurs .................................................................................................107 Contexte de lutilisation ..............................................................................................107

4.3.

REPRSENTATION DOR-BAC EN UML.......................................................................109 CHOIX DUN FORMALISME POUR OR-BAC....................................................113

CHAPITRE 5.

5.1. INTRT DUNE APPROCHE FORMELLE .........................................................................114 5.1.1. Consultation dune politique de scurit............................................................114 5.1.2. Cohrence dune politique de scurit ...............................................................114 5.1.3. Proprits attendues dune politique de scurit...............................................115 5.1.4. Compltude et interoprabilit ...........................................................................115 5.2. CHOIX DUN LANGAGE DE BASE POUR FORMALISER OR-BAC....................................115 5.2.1. Logique de premier ordre ...................................................................................116 5.2.2. Logique modale ...................................................................................................116 5.2.3. Logique dontique ...............................................................................................117 5.3. LANGAGE PROPOS POUR OR-BAC .............................................................................118 5.3.1. Le langage ...........................................................................................................118
5.3.1.1 5.3.1.2 5.3.1.3 5.3.1.4 Constantes ....................................................................................................................118 Variables ......................................................................................................................118 Formules atomiques.....................................................................................................119 Fonctions......................................................................................................................119

5.3.2. La smantique......................................................................................................120 5.3.3. Les conditions de vrit.......................................................................................120 5.4. UTILISATION DU LANGAGE PROPOS POUR SPCIFIER UNE POLITIQUE DE SCURIT..121 5.4.1. Spcification des rgles de fonctionnement........................................................121
5.4.1.1 5.4.1.2 5.4.1.3 5.4.1.4 Les sujets et les rles ...................................................................................................121 Les objets et les vues ...................................................................................................122 Les actions et les activits ...........................................................................................123 La hirarchie ................................................................................................................124

5.4.1.5 5.4.1.6

Le contexte .................................................................................................................. 125 Les contraintes............................................................................................................. 127

5.4.2. 5.4.3. CHAPITRE 6.

Spcification des objectifs de scurit ................................................................127 Spcification des rgles de scurit ....................................................................128 APPLICATION DOR-BAC AUX SICSS ET MISE EN OEUVRE .........................133

6.1. DMARCHE UML..........................................................................................................134 6.2. SPCIFICATION DES CONCEPTS DE LA POLITIQUE DE SCURIT ...................................142 6.2.1. Concepts structurels ............................................................................................142 6.2.2. Concepts comportementaux ................................................................................143 6.3. EXEMPLE DE MISE EN UVRE .......................................................................................143 CONCLUSION GNRALE...........................................................................................................149 ANNEXE A : MENACES POUVANT AVOIR DES CONSQUENCES DANS LE MONDE MDICAL ....151 A1. MENACES POUVANT PORTER ATTEINTE LA CONFIDENTIALIT .................................151 A2. MENACES POUVANT PORTER ATTEINTE LINTGRIT ...............................................153 A3. MENACES POUVANT PORTER ATTEINTE LA DISPONIBILIT.......................................155 A4. MENACES POUVANT PORTER ATTEINTE LAUDITABILIT .........................................156 ANNEXE B : ANONYMISATION DES DONNES DU PMSI..........................................................157 B1. TRAITEMENTS RALISS AU NIVEAU DES SERVICES ADMINISTRATIFS ........................158 B1.1 Constitution du fichier VID-HOSP .....................................................................158 B1.2 Constitution du fichier ANO-HOSP et transmission au DIM............................158 B2. TRAITEMENTS RALISS AU NIVEAU DU DIM..............................................................158 B2.1 Constitution du fichier HOSP-PMSI...................................................................158 B2.2 Constitution du fichier anonyme chanable........................................................158 B2.3 Traitements raliss au niveau de lARH ...........................................................159 ANNEXE C : INTRODUCTION UML .......................................................................................160 C1. UML EN RSUM ..........................................................................................................160 C2. LES DIAGRAMMES UML ...............................................................................................161 C2.1 Les cas dutilisation.............................................................................................161 C2.2 Les modles structuraux......................................................................................161 C2.3 Les modles comportementaux ...........................................................................162 ANNEXE D : CONTRLE DACCS POUR UN CENTRE DENTAIRE ..............................................164 D1. ANALYSE CONCEPTUELLE ............................................................................................164 D1.1 Dictionnaire de donnes......................................................................................164 D1.2 Rgles de gestion .................................................................................................166 D1.3 Modle conceptuel de communication................................................................167 D1.4 Modle conceptuel de donnes ...........................................................................168 D1.5 Modle conceptuel de traitement ........................................................................168 D2. ANALYSE LOGIQUE .......................................................................................................169 D3. ANALYSE PHYSIQUE......................................................................................................170 RFRENCES BIBLIOGRAPHIQUES.............................................................................................173

INDEX DES FIGURES

Figure 1.1 : Larbre de la sret de fonctionnement........................................................................8 Figure 1.2 : Les classes de fautes lmentaires................................................................................8 Figure 1.3 : Intrusion interprte comme une faute composite.....................................................13 Figure 1.4 : Chiffrement et dchiffrement. ....................................................................................18 Figure 1.5 : Gnration et vrification de signature. .....................................................................20 Figure 1.6 : Principe de la signature par DSA. ..............................................................................20 Figure 1.7 : Signature par chiffre cl publique. ..........................................................................21 Figure 2.1 : Rgles de rcriture du modle Take-Grant ..............................................................36 Figure 2.2 : Un exemple simple dtat de protection dans le modle Take-Grant. ......................36 Figure 2.3 : Exemple dapplication des rgles de rcriture dans le modle Take-Grant............36 Figure 2.4 : Attribution des permissions aux sujets travers des rles. .......................................48 Figure 2.5 : Illustration des concepts de TMAC............................................................................50 Figure 2.6 : Activation des permissions selon C-TMAC. .............................................................52 Figure 3.1 : Organisation et domaines dun rseau de sant. ........................................................63 Figure 3.2 : Accs des catgories dutilisateurs aux diffrents types de dossiers mdicaux. ......67 Figure 3.3 : Accs aux parties des dossiers selon le rle...............................................................68 Figure 3.4 : Scnario social. ...........................................................................................................69 Figure 3.5 : Scnario daccs en aval.............................................................................................72 Figure 3.6 : Anonymisation en cascade : de luniversalit jusqu lunicit................................81 Figure 3.7 : Attaque par dictionnaire..............................................................................................82 Figure 3.8 : Procdure de double hachage des informations traites par le DIM.........................83 Figure 3.9 : Fragmentation-Redondance-Dissmination de la cl secrte....................................84 Figure 3.10 : Procdure FOIN. .......................................................................................................84 Figure 3.11 : Transformation des donnes identifiantes en Suisse. ..............................................86 Figure 3.12 : change de donnes chiffres entre professionnels de sant. .................................87 Figure 3.14 : Frontires des donnes nominatives, anonymes et anonymisables.........................90 Figure 3.15 : Anonymisation dans le cadre des tudes pidmiologiques focalises. .................94 Figure 4.1 : Relation dhritage entre les organisations et les sujets. .........................................103 Figure 4.2 : bauche dun diagramme dobjets reprsentant les rles jous par les sujets. ......103 Figure 4.3 : bauches de diagrammes dobjets reprsentant des instances de RdO. .................103 Figure 4.4 : bauche du diagramme de classe reprsentant la classe association RdO. ............104 Figure 4.5 : Similitudes entre les rles et les vues.......................................................................104 Figure 4.6 : bauche du diagramme de classe reprsentant la classe association VdO.............105

Figure 4.7 : bauches de diagrammes dobjets reprsentant des instances de VdO. .................105 Figure 4.8 : bauche du diagramme de classe reprsentant la classe association AdO.............106 Figure 4.9 : bauches de diagrammes dobjets reprsentant des instances dAdO....................106 Figure 4.10 : bauche du diagramme de classe reprsentant les rgles de scurit...................110 Figure 4.11 : bauche du diagramme dobjet reprsentant une rgle de permission.................110 Figure 4.12 : Les deux niveaux dabstraction du modle Or-BAC.............................................111 Figure 4.13 : Reprsentation UML du modle Or-BAC. ............................................................112 Figures 4.14 (a et b) : Exemple de rcursivit.............................................................................112 Figure 6.1: Exemple de diagramme de cas dutilisation..............................................................136 Figure 6.2-a : Exemple de diagramme de squence. ...................................................................137 Figure 6.2-b : diagramme de collaboration correspondant..........................................................137 Figure 6.3 : Contrle daccs dans le cas dune invocation dun objet local..............................138 Figure 6.4 : Contrle daccs dans le cas dune invocation dun objet distant...........................139 Figure 6.5: Diagramme de collaboration (invocation dun objet distant)...................................140 Figure 6.6 : Diagramme dactivit rsumant les scnarios daccs. ...........................................141 Figure 6.7: Exemple de reprsentation UML dune rgle de scurit. .......................................143 Figure 6.8 : Implmentation des RdO en bases de donnes. .......................................................145 Figure 6.9 : Phases didentification et dauthentification............................................................146 Figure 6.10 : Exemple dimplmentation dune rgle de scurit. .............................................147 Figure B1 : Schma rcapitulatif des anonymisations du PMSI .................................................157 Figure D1 : Modle conceptuel de communication de notre application. ..................................167 Figure D2 : Graphe de dpendance fonctionnelle correspondant notre application................167 Figure D3: Modle conceptuel de donnes correspondant notre application. .........................168 Figure D4 : Exemple de modle conceptuel de traitement pour notre application. ...................169 Figure D5 : Modle logique de donnes pour notre application. ................................................170

INDEX DES TABLEAUX

Tableau 2.1 : Format dune commande HRU................................................................................35 Tableau 2.2 : Oprations lmentaires de HRU. ...........................................................................35 Tableau 2.3 : Oprations lmentaire de TAM. ............................................................................37 Tableau 2.4 : Format dune commande TAM. ..............................................................................37 Tableau 3.1 : Accs en aval aux services de Net-entreprises........................................................74 Tableau 3.2 : Menaces pouvant porter atteinte la disponibilit dans le social. .........................75 Tableau 3.3 : Menaces pouvant porter atteinte la confidentialit dans le social. ......................76 Tableau 3.4 : Menaces pouvant porter atteinte lintgrit dans le social...................................76 Tableau 3.5 : Menaces pouvant porter atteinte la responsabilit dans le social. .......................77 Tableau 3.6 : Instances de la relation Analyse. .............................................................................92 Tableau 5.1 : Droits associs chaque rle de notre scnario social. ........................................128 Tableau 6.1 : Forme textuelle dun exemple de politique de scurit. .......................................135

Introduction gnrale

Alors que linformatisation simpose dans des domaines complexes, coopratifs et largement distribus comme la tlmdecine et les tldclarations sociales, il est de plus en plus ncessaire davoir confiance dans les traitements et la distribution des donnes et services informatiques. Les Systmes dInformation et de Communication en Sant et social (SICSS) permettent de stocker et de grer des informations mdicales, administratives ou sociales relatives des personnes ou des entreprises. Ils exploitent les technologies de linformatique pour permettre aux utilisateurs un accs rapide ces informations, et ainsi faciliter les actes mdicaux, les remboursements, les tldclarations sociales, les tlpaiements, etc. Toutefois, les menaces qui psent sur de tels systmes peuvent provoquer la rticence des usagers (patients pour la sphre mdicale, entreprises pour la sphre sociale). En effet, lexploitation abusive par un utilisateur malhonnte dun SICSS insuffisamment protg peut rendre possible la divulgation de donnes personnelles diffrents intresss : employeurs, concurrents, banques, etc. Les erreurs de saisie ou de conception peuvent entraner des erreurs de diagnostic, de soins ou de paiements. Les dfaillances peuvent empcher le personnel soignant daccder des informations indispensables. Enfin, la peur dun manque de confidentialit, dintgrit, de disponibilit ou dauditabilit de tels systmes peut inciter des patients et des entreprises refuser de divulguer des informations pourtant vitales. Pour atteindre un niveau de protection satisfaisant, il convient de dfinir une politique de scurit correspondant aux besoins. En effet, toute dmarche de scurit rigoureuse doit tre inscrite dans une politique claire et documente. Sa conception est donc une tape primordiale, qui consiste identifier les objectifs de scurit et laborer un ensemble de rgles en fonction dune analyse des risques. Ceci permet de minimiser le risque de dommages indsirables ou de pallier leurs effets et conduit protger les informations et les ressources identifies comme sensibles. Une politique de scurit se dveloppe selon trois axes : physique, administratif et logique. Le premier prcise lenvironnement physique du systme protger (les lments critiques, les mesures prises vis--vis du vol et des catastrophes). Le deuxime dcrit les procdures organisationnelles (rpartition des tches, sparation des pouvoirs). Le troisime a trait aux contrles daccs logiques (qui, quoi, quand, pourquoi, comment) et sintresse aux fonctions didentification, dauthentification et dautorisation mises en uvre par le systme informatique. Dans ce mmoire, nous nous intressons particulirement aux politiques dautorisation (dites aussi politiques de contrle daccs). Les premiers travaux sur lexpression et la mise en uvre de politiques dautorisation ont dbut, il y a plus de vingt ans, principalement dans le domaine de la dfense. Pour des raisons juridiques (responsabilit), thiques (respect de la vie prive), dontologiques (secret mdical, par exemple), organisationnelles (situations durgence, cas particuliers ou non attendus) et techniques (interconnexion de rseaux locaux, rgionaux et nationaux), ce type de politiques de scurit est clairement inadapt au monde de la sant ou du social. La conception de politiques

Introduction gnrale

dautorisation beaucoup plus dynamiques - et pouvant sadapter aux contextes des activits mdicales ou sociales - est ncessaire. Les modles et politiques de scurit, fonds sur le concept de rle, sont une premire tape pour mieux rpondre de tels besoins sectoriels, mais ils ne satisfont pas toutes les spcificits des SICSS. Des modles et politiques plus rcents, reposant sur les notions dquipes et de contextes, semblent galement intressants, mais ncessitent des approfondissements thoriques et des tudes complmentaires. Ainsi, les politiques et modles de scurit actuels tant incapables de couvrir toute la richesse des SICSS, il semble ncessaire de proposer de nouveaux concepts et de prsenter un modle pouvant assurer une meilleure scurit, sans pour autant gner le travail des usagers ou porter atteinte aux droits des patients. La rflexion sarticule autour de six moments : Le premier chapitre montre la pertinence dune tude de scurit dans la sphre sant-social, prsente la terminologie utilise, et situe les politiques de scurit dans lventail des stratgies et outils pour renforcer la scurit dun systme ou dune organisation. Le deuxime chapitre tudie les politiques et modles de scurit existants, et montre les limites de leur application aux SICSS. Elle prsente galement des projets rcents dans ce domaine et introduit le projet MP6, Modles et Politiques de Scurit pour les Systmes dInformation et de Communication en Sant et Social, projet dans lequel ont t effectus nos travaux. Le troisime chapitre montre comment btir une politique de scurit pour un systme ou une organisation. Cette mthodologie est applique en posant les principales briques dune politique de scurit pour les sphres sociale et mdicale. ce niveau de ltude, les SICSS seront dcrits en dtail travers des rgles de fonctionnement, des objectifs de scurit ainsi que des rgles de scurit. De par son importance dans les SICSS, le problme danonymisation est enfin abord en dtail. Une tude pralable est ncessaire avant toute procdure danonymisation. Cette tude doit identifier les besoins, les objectifs ainsi que les exigences en terme danonymisation. Sen suivra une prsentation des principaux travaux dans ce domaine, une description dun ensemble de scnarios rcapitulatifs, et des propositions de solutions mieux adaptes aux besoins actuels et futurs. Les politiques de scurit dcrites pourraient ainsi tre appliques aussi bien aux donnes anonymises quaux autres informations sensibles, ressources et services des SICSS. Le quatrime chapitre rappelle les concepts de base de notre politique de scurit. Celle-ci tient compte du contexte et ralise un bon compromis entre la flexibilit et lefficacit du contrle daccs. Par ailleurs, une reprsentation UML (Unified Modeling Language) du nouveau mta-modle Or-BAC Organization-Based Access Control sera ensuite propose. Centr sur lorganisation, Or-BAC offre lexpressivit et la flexibilit ncessaires la reprsentation de politiques de scurit pour une large gamme dorganisations et de systmes, notamment les SICSS. Le cinquime chapitre prsente une vision logique qui servira formaliser et raisonner sur une politique de scurit fonde sur Or-BAC. cet gard, un langage appropri (fond sur la logique dontique) sera dabord propos, et sera ensuite utilis pour reprsenter les rgles de fonctionnement, les objectifs de scurit ainsi que les rgles de scurit des SICSS. Des ides sur lexploitation de ce formalisme - notamment pour la vrification de la cohrence dune politique de scurit ou pour la rsolution de conflits - seront galement proposes. Le sixime chapitre commence par prsenter une dmarche UML pour btir une politique de scurit associe Or-BAC. Cette dmarche tient compte des aspects conceptuels, statiques et dynamiques dune politique de scurit. Enfin, il sagira de dcrire une concrtisation de nos ides travers une implmentation dun logiciel de contrle daccs pour un centre dentaire.

Chapitre 1. Scurit des systmes dinformation et de communication en sant et social

Prambule
Ce chapitre repose sur deux motivations. Dune part, fournir la base terminologique ncessaire la comprhension de nos travaux, et dautre part, situer nos centres dintrts dans le vaste domaine de la scurit. Aussi, ce chapitre est-il articul en cinq parties. Cest par la description de notre champ dapplication - les systmes dinformation et de communication en sant et social (SICSS) - que ltude dbutera. Les SICSS couvrent lensemble des besoins gnralement trouvs dans les autres domaines. Les concepts de la sret de fonctionnement, et plus particulirement ceux de la scurit informatique, seront ensuite prsents. Le but est de fournir un support terminologique dans la dfinition des politiques de scurit pour les SICSS, puis dans llaboration de modles formels de ces politiques. Suit une brve introduction la scurit des systmes dinformation et, linstar des ITSEC [ITSEC 1991], critres europens dvaluation de la scurit des systmes dinformation, elle dcrit la scurit comme lassociation de la confidentialit, de lintgrit et de la disponibilit vis--vis des actions autorises. Les ambiguts sont ensuite leves sur les notions dintrusions, dattaques, de vulnrabilits et de risques, et des exemples spcifiques aux SICSS seront donns. La dernire partie du chapitre dtaille les techniques de scurit les plus utilises pour faire face aux intrusions, et pour renforcer la scurit dun systme ou dune organisation. Il sagira de dcrire des mesures comme les politiques de scurit, les mcanismes de chiffrement, la dtection dintrusion, etc. Ces mcanismes, aussi robustes soient-ils, ne peuvent scuriser efficacement et rigoureusement un systme que sils sintgrent dans une dmarche globale fonde sur une politique de scurit.

Chapitre 1 Scurit des SICSS

1.1. Caractristiques des systmes dinformation et de communication en sant et social

Cette section a pour but de caractriser, trs brivement, les SICSS, domaine dapplication tudi tout au long de ce mmoire. Une analyse plus dtaille de ces systmes sera donne dans le troisime chapitre.

1.1.1. Dfinition et enjeux

Les systmes dinformation et de communication en sant et social (SICSS) permettent de stocker et de grer des informations mdicales, administratives ou sociales concernant des individus ou des entreprises. Ils doivent faciliter les tches de leurs utilisateurs : mdecins, secrtaires mdicales, infirmiers, agents dassurances maladie, ou encore usagers de Netentreprises1, tous en charge de traitements tels les diagnostics, les actes mdicaux, les soins, les remboursements et les dclarations sociales. Ces systmes manipulent, entre autres, des donnes caractre personnel et souvent nominatives2. Citons, titre dexemple, les informations dcrivant les situations mdicales (historique des pathologies et allergies, diagnostics, actes mdicaux, rsultats biologiques), administratives (identit et coordonnes, situation familiale, numro de SIREN3, salaires) ou sociales (prestations financires et sociales). Les SICSS exploitent les progrs des technologies de linformatique et des rseaux pour permettre aux utilisateurs un accs rapide aux informations, et ainsi faciliter et contrler la prise en charge (mdicale, administrative ou sociale) des patients et des ayant-droits. Ils servent aussi allger la charge administrative qui pse sur les petites et moyennes entreprises et notamment la procdure de cration des entreprises, le bulletin de paie, le calcul des charges sociales, les mesures fiscales, comptables et statistiques, etc. Toutefois, la mise en uvre de ces technologies met en danger les donnes gres par les SICSS. En loccurrence, le march des informations nominatives intresse nombre dorganisations : industries pharmaceutiques, compagnies dassurances, banques, employeurs, presse, stratges politiques, etc. Les SICSS sont donc des cibles privilgies pour des individus malintentionns, susceptibles dexploiter toute vulnrabilit du systme pour violer les exigences de scurit.

1.1.2. Complexit des SICSS

Les SICSS sont des systmes riches en fonctionnalits, complexes, sensibles, htrognes et exigeant un niveau lev dinteroprabilit. En effet, les SICSS : - relient des organisations multiples et des utilisateurs ayant des profils diffrents ; dans le domaine mdical, il sagit de professionnels de sant, hpitaux et organismes payeurs ; dans la sphre sociale, il sagit des organismes de protection sociale, entreprises et banques ;

Net-entreprises est le service propos en France aux entreprises par lensemble des organismes de protection sociale pour leur permettre deffectuer, par Internet, leurs dclarations et leurs paiements. 2 Nous considrons une information comme nominative si elle contribue la description dindividus (ou entreprises) bien identifis ou identifiables. 3 Le numro de SIREN est un numro attribu par lINSEE toute personne physique ou morale qui exerce une activit professionnelle lors de linscription au rpertoire national des entreprises.

mettent en jeu des technologies complexes comme la communication, le traitement dinformation, la tlmdecine, le tlpaiement et larchivage ; - manipulent des informations sensibles et htrognes ; il sagit de donnes textuelles ou graphiques, dimages et denregistrements de cardiogrammes, etc. ; le caractre, souvent personnel, de ces informations, oblige prendre des prcautions particulires, afin dassurer leur protection, notamment durant toute manipulation (accs, transfert, stockage) ; - ncessitent une coopration de ses utilisateurs qui changent les informations, consultent les bases de donnes, et utilisent les applications mdicales, paramdicales, mdicoadministratives et mdico-financires ; en effet, les mdecins, hpitaux, pharmacies et laboratoires doivent pouvoir schanger des informations mdicales afin de favoriser laide au diagnostic ou la recherche pidmiologique ; les services dtude et de recherche pidmiologique envoient aux mdecins des statistiques dactivit et leur fournissent une aide la dcision. Les mdecins envoient les feuilles de soins lectroniques aux rgimes dassurance maladie et reoivent, en change, des accuss de rception, etc. La diversit des organisations dans lesquelles de telles applications doivent tre mises en uvre ainsi que les interactions entre les applications, ncessitent une grande flexibilit dans la dfinition des politiques de scurit. Ces interactions sont exigeantes en matire de scurit, notamment en intgrant des droits, des interdictions, des obligations et des recommandations, attribus chacun des acteurs et issus des responsabilits quils doivent exercer. -

1.1.3. Diversit des exigences de scurit

Selon les domaines dapplication, les exigences de scurit peuvent varier pour ce qui concerne limportance relative de chacune des proprits de scurit : disponibilit, intgrit, disponibilit et auditabilit (voir section 3 du prsent chapitre). Ainsi, dans le domaine militaire par exemple, et plus gnralement dans le domaine gouvernemental, laccent est mis principalement sur la confidentialit, lintgrit tant le plus souvent estime comme secondaire et la disponibilit tant encore plus nglige : la divulgation dune information est considre comme plus grave que son altration ou son indisponibilit. Dans le domaine financier, quil sagisse dapplications bancaires ou de comptabilit des entreprises, lintgrit est de loin le souci majeur, bien plus que la disponibilit, la confidentialit tant encore dun moindre souci. En effet, une altration de linformation, quil sagisse de fraude ou dune faute accidentelle, peut avoir des consquences financires dmesures. Le manque de disponibilit est gnralement dune gravit moindre. Quant aux pertes lies au manque de confidentialit, elles sont gnralement difficiles valuer financirement et le plus souvent considres comme ngligeables devant les risques lis laltration des donnes. linverse, les SICSS se caractrisent par leurs fortes exigences, souvent simultanes, de confidentialit , dintgrit et de disponibilit , mais aussi dauditabilit . En effet, dans le domaine mdical, lintgrit (des diagnostics, par exemple) et la disponibilit (caractre durgence) peuvent parfois tre vitales, au sens strict du terme, mais la confidentialit est plus quune obligation lgale : laccs des informations mdicales peut avoir des implications financires importantes vis--vis dun employeur ou dun assureur, mais peut aussi tre la source dun chantage. La proprit dauditabilit est galement trs importante pour renforcer la responsabilit des personnels soignants. De la mme manire, dans le domaine social, la confidentialit des donnes concernant les personnes et les entreprises, lintgrit des tldclarations et des tlpaiements, la disponibilit des tlservices de Net-entreprises

Chapitre 1 Scurit des SICSS

(surtout dans les chances de dclarations et de paiements), ainsi que la responsabilit des actions (paiement chance par exemple), sont autant de points cruciaux. Malheureusement, des conflits potentiels peuvent apparatre entre toutes ces exigences de scurit des SICSS. En effet, un objectif de confidentialit sur les dossiers mdicaux conduit dfinir une rgle limitant laccs au dossier mdical dun patient son seul mdecin traitant. Pourtant, un objectif de disponibilit peut amener dfinir comme rgle quen cas durgence, nimporte quel mdecin puisse y avoir accs. Dans dautres cas, un professionnel de sant peut avoir besoin de certaines donnes indirectement nominatives (par exemple, lge, lappartenance sociale, ou la rgion gographique) pour raliser une tude pidmiologique. Une telle exigence, lie la disponibilit, peut entrer en conflit avec des exigences de confidentialit (par exemple, risque dinfrence non autorise si ces donnes indirectement nominatives sont divulgues).

1.1.4. Menaces pesant sur les informations manipules par ces systmes
Les menaces auxquelles les SICSS sont confronts peuvent causer diffrents prjudices, notamment en portant atteinte la confidentialit des informations concernant les patients et les organisations, lintgrit des donnes et des programmes, la disponibilit des services et des donnes ncessaires au bon fonctionnement. Plusieurs tudes et statistiques rcentes montrent lampleur de ces menaces. Des enqutes menes par la commission daudit britannique [Audit 1998] et par le bureau dvaluation de la technologie du gouvernement amricain ont confirm que le domaine de la sant est lune des cibles privilgies dattaquants aussi bien internes quexternes (atteinte la vie prive, fraudes, etc.) [Woodward 1995]. Plus rcemment, en 2001, un pirate a pu semparer du serveur de fichiers dun hpital Seattle (aux tats-Unis) et diffuser sur le Web (securityfocus.com) les fichiers mdicaux de cinq mille patients. Des tudes plus anciennes [Tufo 1971] rvlent que, dans plus de 30 % des cas, les fichiers mdicaux sont indisponibles, et que mme quand ils sont disponibles, les dlais ncessaires pour extraire les informations sont souvent dcourageants. Les 26, 27 octobre et le 4 novembre 1992, suite une surcharge du systme informatique, le service des ambulances de Londres a t bloqu ; causant la mort de vingt personnes. Lenqute a rvl que la transition vers le systme de sauvegarde navait pas t correctement prpare. cet gard, les vulnrabilits des SICSS peuvent tre de natures diverses : fautes de conception ou de spcification, comme les portes drobes permettant des infiltrations malveillantes extrieures (voir 1.4) ; politiques de scurit ne tenant pas compte de toutes les manipulations illgitimes ; faiblesses dans le systme socio-technique, dues par exemple une procdure dhabilitation trop laxiste des personnels ; protection physique insuffisante du matriel et des ressources ; etc. En outre, les attaques peuvent aussi bien provenir de lintrieur (abus de pouvoir, curiosit allant au-del de lutilisation des informations et services strictement ncessaires pour laccomplissement du travail) que de lextrieur (pirate informatique qui tente de lire ou de modifier une information ou dusurper lidentit dun professionnel de sant par exemple). Une intrusion (attaque au moins particulirement russie) peut donner lieu : - des divulgations de donnes personnelles intimes, ou professionnelles secrtes (violation de la confidentialit) ; - des erreurs de diagnostic, dactes mdicaux, de tldclarations, ou de tlpaiements (violation de lintgrit et de la disponibilit) ; - lindisponibilit dinformations cruciales pour les mdecins (respectivement les organismes de protection sociale) qui peuvent en avoir besoin pour leurs patients (respectivement entreprises) ou pour justifier leurs dcisions, si ncessaire (violation de la disponibilit et de lauditabilit).

Enfin, le manque de confiance peut conduire chaque partenaire dun SICSS installer sa propre politique de scurit, au dtriment dune interoprabilit pourtant indispensable lchange dinformations entre les usagers des SICSS. Par ailleurs, la peur dun manque de confidentialit, dintgrit, de disponibilit ou dauditabilit de tels systmes 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 spcifiques aux SICSS, mais aussi des risques plus gnraux, lis lutilisation de linformatique et de la tlmatique. Par ailleurs, une caractrisation plus dtaille des besoins des SICSS peut tre trouve dans [Abou el Kalam & Deswarte 2003a].

1.2. Concepts de la sret de fonctionnement

Les SICSS, ainsi prsents, touchent un domaine sensible, ncessitant une confiance leve dans les services dlivrs. Cette confiance ne peut tre obtenue que si les SICSS sont srs de fonctionnement. Cette section prsente les concepts et termes classiques usuels de la sret de fonctionnement et de la scurit informatiques, et ceux spcifiques, ncessaires pour apprhender les atypismes et particularits des SICSS.

1.2.1. Dfinitions de base

La sret de fonctionnement dun systme informatique est la proprit qui permet ses utilisateurs de placer une confiance justifie dans le service quil leur dlivre [Laprie 1995]. Selon les applications auxquelles le systme est destin, laccent peut tre mis sur diffrentes facettes de la sret de fonctionnement, ce qui revient dire que la sret de fonctionnement peut tre vue selon des proprits diffrentes mais complmentaires, qui permettent de dfinir ses attributs : - le fait dtre prt lutilisation conduit la disponibilit ; - la continuit du service conduit la fiabilit ; - la non-occurrence de consquences catastrophiques pour lenvironnement conduit la scurit-innocuit ; - la non-occurrence de divulgations non-autorises de linformation conduit la confidentialit ; - la non-occurrence daltrations inappropries de linformation conduit lintgrit ; - laptitude aux rparations et aux volutions conduit la maintenabilit. Les entraves la sret de fonctionnement sont de trois ordres : dfaillances, erreurs et fautes. Il y a dfaillance lorsque le service dlivr dvie du service attendu. Lerreur est la partie de ltat du systme susceptible dentraner une dfaillance. Et la faute est la cause adjuge ou suppose de lerreur. Les moyens de la sret de fonctionnement sont de deux ordres : dune part les mthodes permettant de fournir au systme laptitude dlivrer un service conforme au service attendu, dautre part celles permettant de donner une confiance justifie dans cette aptitude. Lobtention de la sret de fonctionnement se fait par prvention des fautes ; ce qui consiste empcher par construction loccurrence ou lintroduction de fautes, et par tolrance aux fautes, qui permet par redondance de fournir un service conforme en dpit de fautes. Les mthodes de validation de la sret de fonctionnement se classent en limination des fautes, correspondant la rduction, par vrification, du nombre et de la gravit des fautes, et en prvision des fautes, cest--dire lvaluation de la prsence et de la cration de fautes et de leurs consquences futures (figure 1.1).

8
DISPONIBILIT FIABILIT

Chapitre 1 Scurit des SICSS

ATTRIBUTS

SCURIT - INNOCUIT CONFIDENTIALIT INTGRIT MAINTENABILIT PRVENTION DE FAUTES

SRET DE FONCTIONNEMENT

MOYENS

TOLRANCE AUX FAUTES LIMINATION DES FAUTES PRVISION DES FAUTES FAUTES

ENTRAVES

ERREURS DFAILLANCES

Figure 1.1 : Larbre de la sret de fonctionnement.

1.2.2. Les fautes dues lhomme

Les fautes, ainsi que leurs sources sont extrmement diverses. Les principales facettes selon lesquelles on peut les classer sont leur cause, leur nature, leur phase de cration ou doccurrence, leur situation par rapport aux frontires du systme, et leur persistance (figure 1.2).
CAUSE PHNOMNOLOGIQUE FAUTES PHYSIQUES FAUTES DUES LHOMME FAUTES ACCIDENTELLES NATURE FAUTES INTENTIONNELLES SANS VOLONT DE NUIRE FAUTES INTENTIONNELLEMENT NUISIBLES PHASE DE CRATION OU D'OCCURRENCE FAUTES DE DVELOPPEMENT FAUTES OPRATIONNELLES FAUTES INTERNES FRONTIRES DU SYSTME FAUTES EXTERNES FAUTES PERMANENTES PERSISTANCE FAUTES TEMPORAIRES

FAUTES

Figure 1.2 : Les classes de fautes lmentaires Quand on sintresse la scurit informatique en gnral et celle des SICSS en particulier, la principale classe de fautes prendre en compte est celle des fautes dues lhomme, quelles soient intentionnelles ou accidentelles . Ces fautes donnent lieu quatre classes de fautes combines : - les fautes de conception, qui sont des fautes de dveloppement accidentelles ou intentionnelles sans volont de nuire ; - les fautes dinteraction, qui sont des fautes externes, accidentelles ou intentionnelles sans volont de nuire ; - les logiques malignes, qui sont des fautes internes intentionnellement nuisibles ; - les intrusions, qui sont des fautes oprationnelles externes intentionnellement nuisibles. Les fautes de conception intentionnelles sans volont de nuire rsultent gnralement de compromis effectus durant la conception, dans un souci de conserver au systme un niveau de performances acceptable, de faciliter son utilisation, ou encore pour des raisons conomiques.

Les fautes dinteraction intentionnelles sans volont de nuire peuvent rsulter de laction dun oprateur soit destine faire face une situation imprvue, soit violant dlibrment des procdures sans avoir ralis les consquences malheureuses de son action. Gnralement, ces fautes ne sont identifies quaprs quelles aient caus une dfaillance. Les logiques malignes recouvrent aussi bien des fautes de dveloppement comme les chevaux de Troie, les portes drobes, les bombes logiques, ou des fautes oprationnelles comme les virus et les vers. Ces fautes peuvent tre dfinies comme suit : - une bombe logique est une partie de programme qui reste dormante dans le systme hte jusqu ce quun instant ou un vnement survienne, ou que certaines conditions soient runies, pour dclencher des effets dvastateurs en son sein ; - un cheval de Troie est un programme effectuant une fonction illicite tout en donnant lapparence deffectuer une fonction lgitime ; la fonction illicite peut tre de divulguer ou daltrer des informations, ou peut tre une bombe logique ; - une porte drobe est un moyen de contourner les mcanismes de contrle daccs ; il sagit dune faille du systme de scurit due une faute de conception accidentelle ou intentionnelle (cheval de Troie en particulier) ; - un virus est un segment de programme qui, lorsquil sexcute, se reproduit en sadjoignant un autre programme (du systme ou dapplication), et qui devient ainsi un cheval de Troie ; un virus peut tre porteur dune bombe logique ; - un ver est un programme autonome qui se reproduit et se propage linsu des utilisateurs ; un ver peut galement tre porteur dune bombe logique. Les intrusions ne peuvent tre couronnes de succs sans lexistence de fautes de conception. Le caractre externe des intrusions nexclut pas quelles soient tentes par des oprateurs ou administrateurs du systme qui abusent de leur pouvoir. Les intrusions sont dtailles dans 1.4.

1.3. La scurit des systmes dinformation

1.3.1. Introduction : dfinition de la scurit
Dans le domaine de linformatique, le mot scurit peut couvrir plusieurs acceptions [Deswarte 2003]. La premire correspond la scurit-innocuit (en anglais safety) et concerne la prvention de catastrophes : dans ce sens, un systme informatique aura une scurit satisfaisante si aucune de ses dfaillances ventuelles ne peut provoquer de dgts importants, ou si celles de ses dfaillances qui peuvent provoquer des dgts importants sont suffisamment peu probables. Ce type de scurit est bien videmment une exigence majeure lorsque le bon fonctionnement du systme informatique est ncessaire pour la sauvegarde de vies humaines ou de lenvironnement, ou encore dintrts financiers importants. Cest en particulier le cas des systmes tels que les systmes de transport ou de contrle des centrales nuclaires. Une seconde acception du terme de scurit correspond au mot anglais security et concerne la capacit du systme informatique rsister des agressions externes physiques (incendie, inondation, bombes, etc.) ou logiques (erreurs de saisie, intrusions, piratages, logique malicieuse, etc.). Cest gnralement le sens choisi par les spcialistes de laudit de scurit, lorsquils doivent, pour une entreprise donne, valuer les risques lis linformatique. Mais plutt que de dfinir la scurit vis--vis des consquences de la non-scurit (au sens safety) ou vis--vis des agressions contre la scurit (au sens security), il semble prfrable, linstar des ITSEC [ITSEC 1991], de considrer la scurit comme la combinaison de trois proprits : la confidentialit, lintgrit et la disponibilit de linformation. Notons que ces trois proprits se rapportent linformation, et le terme dinformation doit tre pris ici dans son sens le plus large, couvrant non seulement les donnes et les programmes, mais aussi les

10

Chapitre 1 Scurit des SICSS

flux dinformation, les traitements et la connaissance de lexistence de donnes, de programmes, de traitements, de communications, etc. Cette notion dinformation doit aller jusqu couvrir le systme informatique lui-mme, dont parfois lexistence doit tre tenue secrte. Pour tre plus prcis, on distinguera informations et mta-informations ; les informations correspondant des donnes identifies, alors que les mta-informations renvoient des informations indirectes relies aux informations ou aux services4. Voici quelques exemples de mta-informations : - linstant de dlivrance dun service, ou de cration ou destruction dune information ; - lidentit de la personne qui a ralis une opration : le crateur dune information, lauteur dun document, lmetteur ou le rcepteur dune information, etc. ; - lemplacement dune information, dune entit de communication, dun terminal, etc. ; - lexistence dune information ou dun service ; - lexistence dun transfert dinformation, dun canal de communication, ou dun message ; - loccurrence dune opration ; - le niveau de sensibilit dune information ou dune mta-information ; - la certitude ou le niveau de crdibilit dune information ou dune mta-information ; La scurit, telle quelle est ici apprhende, implique dempcher la ralisation doprations illgitimes contribuant mettre en dfaut les proprits de confidentialit, dintgrit et de disponibilit, mais aussi de garantir la possibilit de raliser les oprations lgitimes dans le systme. Assurer la scurit du systme, cest assurer que les proprits retenues sont vrifies, autrement dit, garantir la non-occurrence de dfaillances vis--vis de ces proprits. Par ailleurs, mme si le prsent mmoire tudie la scurit sous la vision des ITSEC, il parat vident que la scurit-innocuit est une proprit importante pour les SICSS, et par consquent, elle demeure un but global atteindre. En effet, la scurit des SICSS traite des problmes du type : mauvaise identification des patients, modification illgitime dun diagnostic (manque dintgrit), retard ou absence de donnes dans des cas urgents critiques (manque de disponibilit), etc. Puisque ces problmes peuvent porter atteinte la vie des patients, ils concernent la scurit-innocuit, et donc, cette vision de la scurit (scuritinnocuit) sera galement prsente dans ce travail, en tout cas de manire implicite.

1.3.2. Confidentialit
La confidentialit est la proprit dune information de ne pas tre rvle des utilisateurs non autoriss la connatre. Ceci signifie que le systme informatique doit : - empcher les utilisateurs de lire une information confidentielle (sauf sils y sont autoriss), et - empcher les utilisateurs autoriss lire une information et de la divulguer dautres utilisateurs (sauf autorisation). Le terme information doit tre pris au sens le plus large : il recouvre non seulement les donnes elles-mmes, mais aussi les flux dinformation et la connaissance de lexistence des donnes ou des communications. Assurer la confidentialit dun systme est donc une tche complexe. Il faut analyser tous les chemins quune information particulire peut prendre dans le systme pour sassurer quils sont scuriss. Il importe galement de prendre en compte les connaissances quun ou plusieurs utilisateurs peuvent dduire partir des informations quils

4 Ce qui est mta-information un niveau dabstraction donn (par exemple, une application) peut tre une information relle un niveau plus bas (par exemple, le systme dexploitation).

11

acquirent. Il faut donc contrler non seulement les informations prsentes dans le systme, mais aussi les liens logiques qui peuvent les relier entre elles ou des informations publiques. Les attaques contre la confidentialit consistent essayer dobtenir des informations qui doivent tre protges selon la politique de scurit, en dpit des moyens de protection et des rgles de scurit. Par exemple, les coutes passives consistent accder aux donnes transmises sur un canal de communication (cble de rseau, par exemple) ou stocke sur un support vulnrable (disques externes, par exemple). Une telle coute peut, dans certaines circonstances, permettre daccder des informations sensibles, comme le mot de passe dun 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 particulirement difficile identifier a posteriori tant donn labsence totale de traces laisses dans le systme.

1.3.3. Intgrit
Lintgrit est la proprit dune information de ne pas tre altre. Cela signifie que le systme informatique doit : - empcher une modification5 indue de linformation, cest--dire une modification par des utilisateurs non autoriss ou une modification incorrecte par des utilisateurs autoriss, et - faire en sorte quaucun utilisateur ne puisse empcher la modification lgitime de linformation. Par exemple, empcher la mise jour priodique dun compteur de temps constituerait une atteinte lintgrit. De plus, il faut avoir lassurance que toute modification de donne est approuve et que chaque programme se comporte de manire correcte (cest--dire conformment aux fonctions quil est cens remplir, y compris dans ses interactions avec les autres processus). Il faut galement sassurer quaucune information ne peut tre modifie par des intermdiaires, que cette altration soit intentionnelle (par exemple, un utilisateur intervient pour modifier une communication entre deux autres utilisateurs) ou accidentelle (une donne modifie lorsquelle est communique via un support de communication non-fiable). Afin de se prmunir contre les fautes affectant lintgrit des donnes, il importe dintgrer dans le systme des mcanismes permettant dune part de dtecter les modifications des informations, et dautre part de contrler les accs ces dernires (en grant les droits daccs des programmes et utilisateurs). De plus, un travail de validation en amont peut galement tre ralis pour prvenir les fautes accidentelles.

1.3.4. Disponibilit
La disponibilit est la proprit dune information dtre accessible lorsquun utilisateur autoris en a besoin. Cela signifie que le systme informatique doit : - fournir laccs linformation pour que les utilisateurs autoriss puissent la lire ou la modifier, et - faire en sorte quaucun utilisateur ne puisse empcher les utilisateurs autoriss daccder linformation. Ainsi dfinie, la disponibilit est une notion qui regroupe plusieurs concepts. La disponibilit court terme exige que les donnes (mdicales, par exemple) et services (comme ceux offerts par Net-entreprises) sont des ressources critiques qui peuvent, un moment donn, tre invoques par plusieurs utilisateurs, et pour diffrentes raisons

5 Le terme de modification doit tre entendu au sens large, comprenant la fois la cration dune nouvelle information, la mise jour dune information existante, et la destruction dune information.

12

Chapitre 1 Scurit des SICSS

(accomplissement des procdures mdicales et administratives, tude de lefficacit, etc.). Il est vident que ces ressources doivent tres disponibles aux utilisateurs autoriss dans des dlais acceptables. La criticit de ces donnes dpend souvent de lapplication. En cas durgence par exemple, le mdecin du SAMU, doit pouvoir y accder, en un temps raisonnable et sans tre confront des difficults daccs ou une rupture du service dlivr par le systme. Lorsquon sintresse la disponibilit de donnes persistantes, on parle volontiers de prennit pour insister sur la dure de leur validit plutt que sur une accessibilit immdiate. En effet, certaines donnes doivent tre conserves pendant des dures trs longues voire illimites. Les exemples sont multiples : donnes des maladies hrditaires dans le domaine mdical et actes authentiques dans le domaine social. Prserver les fichiers est une tche ardue : au-del des capacits des supports darchivage et des choix pralables des formats et logiciels, la majorit des techniques actuelles ne permettent pas de garantir la restitution des informations que pour une dure limite en raison de leur obsolescence rapide. Il est certes possible de faire passer les informations dun support un autre, au fur et mesure des volutions, mais la rcupration devra tre scurise et linformation devra rester intgre. Par ailleurs, lindisponibilit peut tre due un acte malveillant ou une faute accidentelle. Une attaque contre un systme peut avoir simplement pour but dempcher le systme de remplir le service pour lequel il a t conu. Il sagit alors dune attaque par dni de service. Ces attaques consistent faire en sorte que les actions du systme ne correspondent plus ce lon attend de lui, soit parce que le rsultat des actions effectues par le systme est erron (service incorrect), soit parce que ce rsultat nest pas disponible en temps voulu (retard ou arrt du service). La premire catgorie dattaque est troitement lie lintgrit, tant donn quelle consiste modifier linformation prsente dans le systme cible, afin quil fournisse un rsultat erron. La deuxime catgorie peut galement trouver sa source dans une attaque contre lintgrit des donnes ou du systme, dont lobjectif est dinterrompre le traitement de linformation (ou tout au moins de le retarder), comme dans le cas de la destruction dun lien de communication. Cependant ce type dattaque peut galement tre mis en uvre en perturbant le fonctionnement temporel du systme, en surchargeant certaines des ressources dont il dpend, ou en surchargeant le systme lui-mme. De telles attaques peuvent, par exemple tre mises en uvre par une machine MA qui inonde constamment un rseau R, celuici tant utilis par une machine MB pour remplir un certain service. Enfin, il est important de noter que loccurrence doprations illgitimes nest pas forcment le signe dune action intentionnellement nuisible dun utilisateur. Des fautes accidentelles mettant en danger la scurit du systme peuvent parvenir du fait quun utilisateur, autoris et bien intentionn, ignore certaines des proprits attendues du systme ou ne matrise pas compltement toutes les implications des oprations quil effectue. En particulier, le dbranchement dun cble par une manuvre maladroite peut amener un serveur de fichiers ne plus rpondre, ce qui porte atteinte la proprit de disponibilit.

1.3.5. Autres facettes de la scurit

La scurit peut parfois reprsenter dautres caractristiques, telles que lintimit, lauthenticit, lauditabilit, la prennit, lexclusivit, la protection contre la copie illicite de logiciels, etc. Nous conjecturons que toutes les proprits de scurit peuvent tre exprimes en terme de disponibilit, dintgrit et de confidentialit appliques des informations et des mta-informations [Deswarte 2003]. Ainsi lintimit, pour traduire le terme anglo-saxon de privacy , concerne le respect des liberts individuelles et la protection de la vie prive. Elle se rapporte directement la confidentialit dinformations (donnes caractre personnel) et de mta-informations (identit de lutilisateur qui a effectu une certaine opration, qui a mis ou reu un certain message, etc.). Lanonymat correspond la confidentialit de lidentit de la personne, par exemple, qui

13

ralise (ou ne ralise pas) une opration. Lanalyse du trafic est une attaque contre la confidentialit de mta-informations de communication, en vue dobtenir connaissance de lexistence dun canal, lexistence dun message, des identits, des emplacements ou adresses de lmetteur et du rcepteur dun message, de la dure de la communication, etc. Lauthenticit est la proprit dtre vrai. Pour un message, lauthenticit est quivalente lintgrit la fois du contenu du message (intgrit des informations) et de son origine (mtainformation), ainsi quventuellement dautres mta-informations telles que linstant dmission ou le niveau de classification (intgrit des mta-informations). De la mme manire, un document est authentique si son contenu na pas t altr (intgrit des informations) et optionnellement si lauteur dclar est vraiment lauteur et non un plagiaire, si la date de publication est correcte (intgrit des mta-informations), etc. De la mme manire, un utilisateur prtendu est authentique si lidentit dclare est bien la bonne identit de cette personne. Lauthentification est le processus qui donne confiance dans lauthenticit. Lauditabilit et les proprits qui en dcoulent (imputabilit, irrfutabilit, etc.) [Trouessin 2000] correspond la disponibilit et lintgrit dun ensemble de mta-informations relatives lexistence dune opration, lidentit de la personne qui a ralis lopration, linstant de lopration, etc. La proprit de non-rpudiation garantit quun sujet ayant ralis une action dans le systme ne puisse nier lavoir ralise. La non-rpudiation correspond donc la disponibilit et lintgrit de mta-informations telles que lidentit de lmetteur (et ventuellement linstant dmission) dun message pour la non-rpudiation dorigine, ou telles que la rception et lidentit du rcepteur dun message pour la non-rpudiation de rception.

1.4. Intrusions, attaques, vulnrabilits

Prcdemment, nous avons expliqu que les fautes qui peuvent porter atteinte aux proprits de scurit peuvent tre accidentelles, comme elles peuvent tre intentionnelles, avec ou sans volont de nuire. Ds lors, il sagira de dtailler cette deuxime catgorie de fautes et de prsenter la terminologie ncessaire son tude dans le cadre des SICSS. Une intrusion est dfinie comme tant une faute oprationnelle, externe, intentionnellement nuisible, rsultant de lexploitation dune vulnrabilit dans le systme [Powell & Stroud 2003]. Lusage courant du mot intrusion couvre le fait de pntrer illgalement ou sans y tre convi dans un lieu, une socit, etc. En outre, le systme peut tre attaqu (que ce soit par un intrus interne ou externe) sans succs. Dans ce cas, lattaque existe, mais la protection est suffisamment efficace pour empcher lintrusion. Il existe toujours deux causes sous-jacentes une intrusion (figure 1.3) : - une action malveillante ou attaque qui tente dexploiter une faiblesse dans le systme et de violer un ou plusieurs besoins de scurit ; - au moins une faiblesse, faille ou vulnrabilit , qui est une faute accidentelle ou intentionnelle (avec ou sans volont de nuire), introduite dans la spcification, la conception ou la configuration du systme.
Attaque Intrus Systme Intrusion Vulnrabilit Intrus, concepteur ou oprateur Erreur

Figure 1.3 : Intrusion interprte comme une faute composite.

14

Chapitre 1 Scurit des SICSS

En dfinissant une menace comme une violation potentielle dune proprit de scurit, les couples (menace, vulnrabilit) permettent didentifier les risques auxquels le systme tudi peut tre soumis. Une attaque contre la scurit du systme peut provenir de lintrieur ou de lextrieur. Un intrus interne peut tre dfini comme tant un utilisateur malveillant appartenant lorganisation, tandis quun intrus externe est une personne nayant pas de privilges. Il est donc un individu non enregistr comme utilisateur, mais qui tente de pntrer le systme en trompant ou en contournant les mcanismes dauthentification et dautorisation. Voici des exemples dintrusions, interprtes en termes de vulnrabilits et attaques : - un intrus externe qui pntre dans le systme en devinant un mot de passe ; la vulnrabilit se trouve dans la configuration du systme, qui permet un mauvais choix de mots de passe (trop court, vulnrable aux attaques par dictionnaire) ; - un intrus interne qui abuse de son pouvoir ; la vulnrabilit rside dans la spcification et la conception ou lopration du systme socio-technique (violation du principe du moindre privilge6, procdure dhabilitation trop laxiste des personnels, etc.) ; - un intrus externe qui utilise des moyens dingnierie sociale, par exemple en dupant ou corrompant un utilisateur privilgi pour le pousser excuter une action malveillante avantageuse pour son propre compte ; la vulnrabilit est la prsence dun utilisateur privilgi corruptible ou trop peu mfiant, ce qui est aussi une faute de conception ou dopration du systme socio-technique (procdure dhabilitation laxiste, par exemple) ; - un intrus externe qui mne une attaque en dni de service par surcharge de requtes (comme les attaques massives de sites webs en fvrier 2000). La vulnrabilit rside en partie dans les spcifications mmes du systme puisquil est contradictoire dexiger quun systme soit totalement ouvert des utilisateurs bien intentionns et ferm aux utilisateurs malveillants. Ce type particulier dattaque exploite aussi des fautes de conception ou de configuration dans les nombreux htes connects Internet qui ont t pirats pour insrer des processus zombies, ncessaires au montage dune attaque distribue et coordonne. Une troisime vulnrabilit, qui empche de lancer des contre-mesures efficaces, repose sur une faute de conception de la part des fournisseurs de services Internet qui nimplmentent pas de filtrage (en entre et sortie) qui permettrait de tracer efficacement ladresse source de lattaque. Dune manire gnrale, un utilisateur malveillant suit lune des deux logiques suivantes : soit il contourne les mcanismes qui implmentent la politique7 de scurit ; soit il exploite les limites et les failles de cette politique. Cette distinction a un effet direct sur les types dintrusions qui touchent le plus les SICSS, notamment : - les vols de privilges ou accroissement non autoris de privilges ; il sagit dun changement des privilges dun utilisateur sans que cela soit autoris par la politique de scurit : par exemple, un utilisateur qui essaye de contourner les mcanismes dautorisation pour lire des informations confidentielles ; - les abus de privilges ou utilisation abusive des oprations autorises ; par exemple des utilisateurs privilgis comme les administrateurs du systme, les oprateurs ou les officiers de scurit, peuvent abuser de leurs privilges pour effectuer des actions malveillantes. Par ailleurs, il est intressant de se pencher galement sur les cas o une attaque contre la scurit du systme peut tre accidentelle. Par exemple, le statisticien qui, sans volont
6 Le principe du moindre privilge impose que tout utilisateur ne doit pouvoir accder un instant donn quaux informations strictement ncessaires pour laccomplissement du travail qui lui a t confi. 7 Une politique de scurit peut tre dfinie par lensemble des rgles qui rgissent la faon dont linformation sensible et les autres ressources sont gres, protges et distribues dans le systme.

15

pralable de violer la scurit du systme, tombe par hasard sur des donnes qui, ventuellement par recoupement avec dautres, dvoilent des informations nominatives sensibles (auxquelles il na pas le droit daccder). ce niveau, aucun acte malveillant nest identifi explicitement. Nanmoins, si lutilisation de ces informations est malveillante, il sagit bien dun abus de pouvoir. Des notions comme les fautes intentionnelles avec ou sans volont de nuire ou les divulgations accidentelles dinformation sont donc particulirement pertinentes dans ltude des SICSS [Abou El Kalam et al. 2002b].

1.5. Techniques et mcanismes pour scuriser un systme

Afin dliminer les vulnrabilits, contrer les attaques, et garantir un niveau lev de protection du rseau et du systme dinformation, on peut utiliser des services, des mcanismes, des outils et des procdures que lon nomme, de faon gnrale, des solutions ou des mesures de scurit. Par exemple, un service didentification et dauthentification aide rduire le risque dintrusion dans un systme. Les politiques de scurit seront prsentes comme un dispositif ncessaire pour renforcer la scurit des systmes. Puis il conviendra daborder succinctement la manire avec laquelle on peut les construire et les implmenter. Nous expliquons galement dautres contre-mesures pour renforcer la scurit comme les mcanismes cryptographiques, le cloisonnement, laudit, la dtection dintrusion et la tolrance aux intrusions.

1.5.1. Politiques de scurit

Dans un systme informatique, lautorisation a pour but de ne permettre que les actions lgitimes, cest--dire empcher quun utilisateur puisse excuter des oprations qui ne devraient pas lui tre permises [Deswarte 2003]. Pour dfinir quelles sont les oprations autorises et celles qui sont interdites, il faut tablir une politique de scurit ou doctrine de scurit . Les ITSEC [ITSEC 1991] dfinissent une politique de scurit comme tant lensemble des lois, rgles et pratiques qui rgissent la faon dont linformation sensible et les autres ressources sont gres, protges et distribues lintrieur dun systme spcifique . cet gard, pour construire une politique de scurit il faut : - dune part, dfinir un ensemble de proprits de scurit qui doivent tre satisfaites par le systme ; par exemple une information classifie ne doit pas tre transmise un utilisateur non habilit la connatre, et - dautre part, tablir un schma dautorisation , qui prsente les rgles permettant de modifier ltat de protection du systme ; par exemple le propritaire dune information peut accorder un droit daccs pour cette information nimporte quel utilisateur. Si la politique dautorisation est cohrente, il ne doit pas tre possible, partant dun tat initial sr (cest--dire satisfaisant les proprits de scurit), datteindre un tat dinscurit (cest-dire un tat o les proprits de scurit ne sont pas satisfaites) en appliquant le schma dautorisation. Comme on la dj expliqu (voir 1.3), les proprits de scurit peuvent tre dfinies en fonction de la confidentialit, lintgrit ou la disponibilit dinformations ou de mta-informations. Une politique de scurit peut se dvelopper dans trois directions distinctes : les politiques de scurit physique, administrative et logique. La politique de scurit physique prcise un ensemble de procdures et de moyens qui protgent les locaux et les biens contre des risques majeurs (incendie, inondation, etc.) et contrlent les accs physiques aux matriels informatiques et de communication (gardiens, ...). La politique de scurit administrative dfinit un ensemble de procdures et moyens qui traite de tout ce qui ressort de la scurit dun point de vue organisationnel au sein de lentreprise. La

16

Chapitre 1 Scurit des SICSS

structure de lorganigramme ainsi que la rpartition des tches (sparation des environnements de dveloppement, dindustrialisation et de production des applicatifs) en font partie. Les proprits de scurit recherches visent, par exemple, limiter les cumuls ou les dlgations abusives de pouvoir, ou garantir une sparation des pouvoirs. La scurit logique fait rfrence la gestion du contrle daccs logique, lequel repose sur un triple service didentification, dauthentification et autorisation. Elle spcifie qui le droit daccder quoi, et dans quelles circonstances. Ainsi, tout utilisateur, avant de se servir du systme, devra dcliner son identit (identification) et prouver quil est bien la personne quil prtend tre (authentification). Une fois la relation tablie, les actions lgitimes que peut faire cet utilisateur sont dtermines par la politique dautorisation (ce type de politiques nous intresse particulirement, et sera dcrit en dtail dans le chapitre suivant). Lautorisation consiste grer et vrifier les droits daccs, en fonction des rgles spcifies dans la politique de scurit. On dit quun sujet (entit qui demande laccs, dite aussi entit active) possde un droit daccs sur un objet (entit laquelle le sujet souhaite accder, dite aussi entit passive) si et seulement sil est autoris effectuer la fonction daccs correspondante sur cet objet. Les droits daccs peuvent tre symboliquement reprsents dans une matrice de droits daccs dont les lignes reprsentent les sujets et les colonnes reprsentent les objets. Une cellule de la matrice contient donc les droits daccs dun sujet sur un objet. La matrice est gre conformment aux rgles dfinies dans la politique de scurit. Lautorisation est mise en uvre par des mcanismes de contrle daccs. Il est gnralement recommand dorganiser ces mcanismes de faon implmenter la notion de moniteur de rfrence , dfini dans le livre orange [TCSEC 1985]. Le moniteur de rfrence est un intermdiaire entre les sujets et les objets. Il vrifie que chaque accs dun sujet vers un objet est garanti par un droit daccs dans la matrice de droits daccs ; en labsence de ce droit daccs, laccs est refus. Le moniteur de rfrence doit tre inviolable (il ne doit pas pouvoir tre modifi), incontournable (il ne doit pas tre possible daccder un objet sans tre contrl par le moniteur de rfrence), et totalement vrifi (il ne doit comporter aucune faute de conception ou de ralisation). Pour tre la fois incontournables et inviolables, il est souhaitable que les contrles daccs soient implments par matriel, pour pouvoir contrler tout accs physique aux informations (mmoire, disques, canaux de communications, etc.). Le co-processeur LOCK dHoneywell, issu dun projet du NCSC [Saydjari et al. 1989], est un exemple dimplmentation de moniteur de rfrence par matriel. La plupart des microprocesseurs modernes offrent des mcanismes de contrle daccs par matriel, en particulier par la gestion de mmoire avec des registres de segments. Ces registres de segments peuvent tre considrs comme des capacits, cest--dire une implmentation par lignes de la matrice de droits daccs : les registres de segments contiennent les rfrences aux objets auxquels le processus en cours (sujet) peut accder, ainsi que les droits correspondants (au moins, lire et crire). Malheureusement, la plupart des systmes dexploitation ne tirent pas parti de ces mcanismes. Dans Unix, par exemple, les contrles daccs sont principalement bass sur des permissions associes aux fichiers et aux rpertoires. Il sagit donc plutt dune implmentation de la matrice de droits daccs par colonnes, cest--dire par listes de contrle daccs : chaque fichier, on associe la liste des sujets (sous Unix, utilisateur ou groupe dutilisateur) qui peuvent accder au fichier et les droits correspondants. Dans ce cas, le contrle daccs se fait uniquement chaque ouverture de fichier. On est donc assez loin de la notion de moniteur de rfrence. Cette notion de moniteur de rfrence est trs centralise, et donc difficile interprter dans un systme rparti ou sur un rseau. Le livre rouge [TNI 1987] propose un schma dautorisation dans lequel chaque machine possde son propre moniteur de rfrence. Dans ce cadre, les accs des sujets aux objets locaux sont contrls par le moniteur de rfrence local,

17

alors que les accs aux objets distants donnent lieu une coopration entre deux moniteurs de rfrences. Le moniteur de rfrence du site, o se trouve le sujet, garantit lidentit du sujet et ventuellement ses droits. Le moniteur de rfrence du site de lobjet contrle laccs lobjet en fonction de lidentit du sujet et ventuellement des droits transmis par lautre moniteur de rfrence et en fonction des droits grs localement. Dans ce cas, la matrice de droits daccs est soit rpartie, soit rplique sur lensemble des sites (ce qui rend difficile le maintien de sa cohrence). Mais le principal inconvnient de ce schma est que chaque moniteur de rfrence doit faire confiance aux autres. Ainsi, si un intrus prend le contrle dun site ou si ladministrateur dun site est malveillant ou corrompu, il lui est facile, par exemple, de dguiser8 un sujet local pour obtenir des droits indus sur des objets distants. Lintrusion dans un site donne donc des privilges sur dautres sites. Des schmas dautorisation deux niveaux ont t proposs pour pallier ces inconvnients [Nicomette & Deswarte 1997 ; Deswarte et al. 2001]. Le premier niveau est constitu dun serveur dautorisation, capable de vrifier les droits de lutilisateur lancer une transaction ou opration de haut niveau et de gnrer des preuves dautorisation pour lexcution rpartie de chaque lment de la transaction. Le second niveau est constitu du moniteur de rfrence local chaque site, et qui vrifie que chaque requte (pour excuter un lment dune transaction) est accompagne dune preuve dautorisation valide. Dans ce cas, lintrusion dans un site ne donne aucun privilge sur les autres sites. Ce schma dautorisation est dtaill laide dune modlisation UML dans le quatrime chapitre. Dune manire gnrale, les rgles de la politique de scurit sont souvent spcifies en terme de permissions (par exemple tout mdecin a le droit daccder aux dossiers mdicaux de ses patients) et dinterdictions (par exemple, les mdecins nont pas le droit deffacer des diagnostics dj tablis), mais aussi en terme dobligations (les mdecins sont obligs de garder les dossiers mdicaux pendant la dure fixe par la loi). Les politiques de contrles daccs classiques sont restreintes aux autorisations, voire aux interdictions. Et mme si certaines politiques plus rcentes spcifient des obligations [Bettini et al. 2002 ; Damianou et al. 2001], elles nexpliquent pas comment les implmenter. Nous pensons que les obligations peuvent tre implmentes par des traitements automatiques. Un autre exemple concerne limplmentation de la proprit de disponibilit. Outre laspect allocation des ressources [Cuppens & Saurel 1999], cette proprit peut tre spcifie par une obligation de fournir des moyens de tolrance aux fautes comme la redondance ou la diversification logicielle et matrielle. prsent, ces problmes sont peu tudis et mritent un approfondissement considrable. Le plus souvent, une politique de scurit ne peut malheureusement pas contrer toutes les attaques, et il est parfois possible quun utilisateur contourne les mcanismes qui limplmentent. Dans dautres cas, certaines des vulnrabilits dun systme sont tout simplement dues des choix dlibrs, rsultant de compromis entre facilit dutilisation, fiabilit, ou cot, dune part, et scurit dautre part. En outre, la plupart des vulnrabilits sont bien des bogues (bugs, en anglais), dus la maladresse des programmeurs, ajoute des vrifications insuffisantes. En effet, il nest pas toujours facile de prouver que la conception, la configuration, ou la mise en uvre (par des mcanismes) dune politique de scurit sont conformes aux objectifs de scurit attendus, et quils nintroduisent aucune vulnrabilit pouvant tre exploite par un attaquant.
Le dguisement (en anglais masquerade ) consiste tromper les mcanismes dauthentification pour se faire passer pour un utilisateur autoris de faon obtenir des droits daccs illgitimes et ainsi compromettre la confidentialit, lintgrit ou la disponibilit. 9 Par exemple, lobligation denregistrement des donnes daudit peut tre mise en uvre par une action automatique (enregistrer ces donnes).
8

18

Chapitre 1 Scurit des SICSS

1.5.2. Autres contre-mesures

Dans certains cas, la politique de scurit peut tre incomplte (ne couvre pas tous les accs possibles, consquence dune faute de conception ou dun choix dlibr), contournable ou mal implmente (sa conception est non-conforme la vie oprationnelle). Il convient donc de renforcer la scurit par dautres contre-mesures, tels les mcanismes cryptographiques, la certification, la dtection dintrusion ou la tolrance aux intrusions.

1.5.2.1 Mcanismes cryptographiques

La cryptologie se compose de la cryptographie , lart dcrire des secrets pour les rendre inintelligibles des tiers, et de la cryptanalyse, lart de retrouver les secrets cachs dans des informations inintelligibles. Il ne sera ici question que des lments de cryptographie, qui sont la base de nombreux mcanismes de scurit : le chiffrement, le hachage et la signature.

1.5.2.1.1 Chiffrement et dchiffrement

Les fonctions de base de la cryptographie sont le chiffrement et le dchiffrement. Le chiffrement vise assurer la confidentialit dinformations ; il consiste transformer un texte en clair en un cryptogramme, laide dun chiffre (ou algorithme de chiffrement) et dune cl de chiffrement. Le dchiffrement consiste transformer le cryptogramme en un texte en clair identique celui dorigine, laide dun algorithme de dchiffrement et dune cl de dchiffrement (figure 1.4).
cl de chiffrement Kc cl de dchiffrement Kd M = texte clair Dchiffrement

M = texte clair

C = cryptogramme Chiffrement

Figure 1.4 : Chiffrement et dchiffrement. Par convention, on notera lopration de chiffrement par des accolades : M C = {M}Kc O M est le message en clair, C le cryptogramme et Kc la cl de chiffrement. De mme, on notera lopration de dchiffrement par des crochets, avec Kd comme cl de dchiffrement : C M = [C]Kd On parle de chiffre symtrique si Kd=Kc. Tous les chiffres connus jusquen 1976 taient symtriques. Les chiffres symtriques sont encore trs utiliss pour la confidentialit, en raison de leurs performances (on peut chiffrer plusieurs centaines de mgabits par seconde avec des matriels spcialiss). Le DES (Data Encryption Standard ) et plus rcemment lAES (Advanced Encryption Standard ) sont deux des chiffres symtriques les plus courants [Menezes et al. 1996]. Si, linverse, Kc et Kd sont diffrents, et si, connaissant lun, il est impossible10 de trouver lautre, on parle de chiffre cl publique (ou asymtrique). Le chiffre cl publique le
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 cls possibles soit suffisamment grand, on peut considrer impossible lattaque par force brute, qui consiste essayer
10

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 possde la cl de dchiffrement (secrte) Kd peut dchiffrer le cryptogramme. Un chiffre est dit hybride sil combine la fois les chiffrements symtrique et asymtrique. Une des manires de faire est la suivante : - Lmetteur gnre alatoirement une cl symtrique c (cl de session), considr comme cl secrte valable pour la transmission en cours, les cls de sessions sont typiquement de 56 bits ou 128 bits. - Lmetteur chiffre son message M avec cette cl de session (chiffre symtrique, {M}c), et chiffre cette cl avec la cl publique Kc du destinataire (chiffre asymtrique, {c}Kc), avec RSA par exemple, cette cl est souvent de 1024 bits ou 2048 bits. - Lmetteur met la fois le message chiffr ({M}c) et la cl de session chiffre ({c}Kc). - Le destinataire retrouve la cl de session en utilisant sa cl prive Kd (c = [{c}Kc]Kd). - Le destinataire dchiffre ensuite le message avec cette cl de session([M = {M}c]c).

1.5.2.1.2 Fonctions de hachage

Une fonction de hachage sens unique (one-way hash function, en anglais) permet de gnrer une empreinte de taille fixe n (par exemple 128 bits) partir dun message de taille quelconque. Lempreinte doit tre une caractristique du texte et il doit y avoir une trs faible probabilit (de lordre de 2-n) que deux messages diffrents aient la mme empreinte. La fonction de hachage H doit donc tre conue de telle sorte que : - connaissant M, il est facile de calculer lempreinte H(M) ; - connaissant H(M), il doit tre impossible de trouver M ; - connaissant H(M), il doit tre impossible de trouver un texte M diffrent de M et ayant la mme empreinte : H(M) = H(M) ; Notons que les fonctions de hachage ne reposent sur aucun secret. Nanmoins, ce sont bien les mthodes de la cryptologie qui permettent de crer de bonnes fonctions de hachage, telles que MD5 et SHA-1, les deux fonctions actuellement les plus utilises.

1.5.2.1.3 Signature et contrles dintgrit

La signature sert garantir lintgrit dinformations. Elle est obtenue en appliquant un texte une fonction de gnration de signature utilisant une cl de signature Ks. La vrification de signature se fait laide dun algorithme de vrification de signature et dune cl de vrification Kv (figure 1.5). Lintgrit du texte est garantie par le fait que si le texte ou la signature sont modifis entre la gnration et la vrification, lalgorithme de vrification doit rendre une rponse ngative. Cette intgrit repose uniquement sur la fonction de gnration de signature.

systmatiquement toutes les cls de dchiffrement possibles jusqu trouver la vraie cl. De mme, on considre impossible de deviner par hasard la cl.

20
cl de signature Ks = signature Gnration de signature Vrification de signature M = texte cl de vrification Kv

Chapitre 1 Scurit des SICSS

M = texte

OUI / NON

Figure 1.5 : Gnration et vrification de signature. Comme pour le chiffrement, on peut distinguer les signatures symtriques o Ks = Kv et les signatures cl publique o Kv est une cl publique (nimporte qui peut vrifier la signature) alors que Ks est tenue secrte 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 crer facilement une signature symtrique : = H ( K | M ), o K est la fois la cl de gnration de signature et la cl de vrification de la signature. Dans ce cas, la fonction de gnration de signature est simplement lapplication de la fonction de hachage sur la cl concatne avec le texte, et la fonction de vrification consiste gnrer nouveau une signature de la mme faon sur le texte reu et comparer les deux signatures. Il est galement possible de gnrer des signatures en utilisant des algorithmes de chiffrement symtriques (par exemple, le DES en mode CBC), cest le cas des MAC (pour codes dauthentification de messages en anglais). Cependant, les signatures symtriques prsentent linconvnient suivant : la cl doit tre partage entre le signataire et le vrificateur, et tenue secrte vis--vis des tiers. Dans ce cas, signataire et vrificateur doivent se faire mutuellement confiance.
Gnration de signature Ks Vrification de signature Kv S S S

H
M

(M)

-1

OUI / NON

(M)

Figure 1.6 : Principe de la signature par DSA. Cet inconvnient nexiste pas lorsquon utilise des signatures cl publique, puisque seul le signataire connat la cl de gnration de signature. Comme il est souhaitable que les signatures aient une longueur fixe, quelle que soit la longueur du texte signer, il est prfrable de signer une empreinte du texte plutt que le texte lui-mme. Il faut pour cela choisir une fonction de hachage de qualit, puisquil serait facile, pour un faussaire de rutiliser une signature gnre pour le texte M sur un autre texte M ayant la mme empreinte que M. Lalgorithme DSA (pour Digital Signature Algorithm), dfini dans la norme DSS (pour Digital Signature Standard) est un exemple dalgorithme 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 dutiliser des algorithmes de chiffrement cl publique tels que RSA pour gnrer et vrifier des signatures sur des empreintes de texte. Dans ce cas, la cl

21

publique Kp est la cl de dchiffrement, utilise comme cl de vrification, et la cl prive Ks (maintenue secrte par le signataire) est la cl de chiffrement, utilise comme cl de gnration de signature11 : Gnration : = {H (M)}Ks
Gnration de signature

Vrification : H (M) = ?= []Kp

Vrification de signature

Ks

Kv = Kp S = {H (M)}Ks

()

H (M)

{ }Ks

[ ]Kv

H (M)

=?

OUI / NON

()

Figure 1.7 : Signature par chiffre cl publique.

1.5.2.1.4 Certificats
Le raisonnement prcdemment appliqu (chiffrement et signatures cls publiques) suppose lauthenticit des cls publiques, disponibles sur un annuaire ou un serveur web par exemple. Nanmoins, cette authenticit nest pas garantie dans un environnement ouvert tel quInternet, et il nest pas impossible quun certain pirate Bob modifie lannuaire ou le serveur web qui hberge les cls publiques et remplace ainsi la cl publique dune certaine Alice par la sienne. Une fois ce dguisement commis, Bob peut lire les courriers destins 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 cest la cl dAlice). Bob pourra dchiffrer les messages destins Alice avec sa cl prive, et lire ainsi le courrier confidentiel dAlice. Le raisonnement du scnario de lusurpation de la signature est le mme. Pour contrer ce type dattaques et afin dassurer la validit de la cl publique, il a fallu crer un mcanisme supplmentaire, le certificat lectronique. Un certificat permet dtablir un environnement de confiance entre deux entits distantes ayant besoin de communiquer entre elles et de schanger des informations non-rpudiables (ncessit de signature) ou confidentielles (application de chiffrement). En effet, un certificat est souvent destin remplir trois rles : authentification de lmetteur, garantie de lintgrit des documents, et ventuellement un horodatage. Selon la norme X509 V3, un certificat lectronique doit contenir notamment : le nom de lautorit de certification, le nom et le prnom de la personne, son entreprise, son adresse lectronique, sa cl publique, les dates de validit du certificat ainsi quune signature lectronique (figure 1.8). Cette signature, calcule sur les informations contenues dans le certificat, est lempreinte de ces informations chiffre avec la cl prive de lautorit de certification qui a dlivr ce certificat. Quand Alice et Bob veulent communiquer de manire sre, par exemple lorsquelle veut lui envoyer un message chiffr, le logiciel de messagerie dAlice a besoin de connatre la cl
11 Nous avons dcrit sparment les mcanismes 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 lmission, et le dchiffrement puis la vrification de la signature la rception. Toutefois, il est possible dinverser lordre de ralisation de ces oprations.

22

Chapitre 1 Scurit des SICSS

publique de Bob. Sil ne la connat pas, il peut interroger lannuaire lectronique pour rcuprer un certificat de Bob. Ce certificat est sign avec une autorit ACBob. Le logiciel de messagerie peut vrifier la signature de ce certificat pour sassurer que ce document a bien t cre par lautorit ACBob et quil na pas t modifi. Avec cette assurance, le logiciel de messagerie peut rcuprer la cl publique de Bob contenue dans ce certificat. La vrification du certificat et lextraction de la cl publique sont schmatises dans la figure ci-dessous.
Autorit de certification : ACBob Prnom: Bob Nom: Dupond Email: bob.dupond@entreprise.fr Date de validit: Du 01/10/93 au
01/10/94 Certificat valide Cl publique de Bob Dupond : A5:3F:F9:E2

Hachage

Empreinte 1

Egalit ?
Cl publique de lautorit de certification

Si oui

Cl publique: A5:3F:F9:E2 . Signature: 9B:C5:11:..:F5

Dchiffrement

Empreinte 2

Figure 1.8 : Vrification de certificat et rcupration de la cl publique Le processus ainsi dfini considre une autorit de certification. Celle-ci peut tre vue comme une structure technique et administrative qui : - gnre un couple de cls publique-prive pour elle-mme ; - diffuse la valeur de sa cl publique auprs des structures quelle connat et des annuaires ; lun des types dannuaires reconnus, et implments par les principaux outils, est LDAP (pour Light Directory Access Protocol en anglais) ; - cre, dlivre et rvoque les certificats des utilisateurs quelle gre. Une Infrastructure de Gestion de Cls (IGC ou PKI pour Public Key Infrastructure dans la terminologie anglaise) recouvre lensemble des services mis en uvre pour assurer la gestion complte des cls publiques, cest--dire lenregistrement des utilisateurs et la vrification des attributs, la gnration de certificats, la publication des certificats valides et rvoqus, lidentification et lauthentification des utilisateurs, larchivage des certificats, etc. Plusieurs composants fondamentaux sont ncessaires pour la mise en uvre dune IGC, notamment : - lautorit de certification ; - lautorit denregistrement, qui est lautorit de rception des utilisateurs qui dsirent obtenir un certificat ; elle vrifie lidentit du demandeur et ses autres attributs, sassure que celui-ci possde bien un couple de cls prive-publique, rcupre la cl publique du demandeur, et transmet ensuite ces informations ainsi que les autres attributs lautorit de certification ; - un service de publication ou autorit de validation ; - lannuaire qui contient les cls publiques, les certificats distribus, ainsi que les listes de certificats rvoqus. Il est gnralement bas sur un service LDAP.

1.5.2.2 Cloisonnement et pare-feux

Le cloisonnement est un bon principe de scurit : isoler tout ce qui na pas besoin de communiquer. Par exemple, il est bon disoler les systmes de dveloppement des systmes dexploitation : cela rend plus difficiles les fraudes par les dveloppeurs de logiciels. Il est bon

23

galement de spcialiser les centres selon la sensibilit des informations traites : les serveurs dinformations publiques (non-classifies) ne devraient pas contenir dinformations classifies. De mme, les systmes daudit doivent tre inaccessibles des systmes quils surveillent (voir section suivante). Les pare-feux (firewalls en anglais, [Cheswik & Bellovin 1994]) permettent de surveiller et de restreindre les accs de lextrieur (par exemple, lInternet) vers lintrieur (une machine, un rseau local, les rseaux dune entreprise) et lextrieur (par exemple, lInternet), mais aussi les accs de lintrieur vers lextrieur. Un pare-feu est donc lun des mcanismes de contrle daccs qui peut tre mis en uvre pour implmenter les rgles de la politique de scurit. Un pare-feu comporte essentiellement une fonction de filtrage : il ne laisse passer que les paquets provenant de certaines adresses autorises (numro IP + numro de port) et destination de certaines adresses autorises. Mais il peut remplir dautres fonctions complmentaires, comme la traduction dadresses (NAT, pour Network Address Translation), ou jouer le rle de mandataire dapplication. La traduction dadresses permet de grer lespace dadressage du rseau interne indpendamment du rseau externe : les adresses internes ne sont pas connues de lextrieur, elles sont traduites en adresses externes par le pare-feu. Un mandataire (proxy en anglais) dapplication permet dinterprter chacune des interactions dune application (commandes, requtes, rponses) pour vrifier que les changes suivent bien un protocole autoris.

1.5.2.3 Audit
Laudit sert conserver des traces des oprations susceptibles de mettre en cause la scurit, de faon analyser, aprs coup ou en temps rel, si des malveillances ont lieu ou ont eu lieu et quels sont les moyens et les mthodes utiliss, de faon punir les coupables et corriger les vulnrabilits. Il faut donc enregistrer toutes les oprations lies la scurit, que ces oprations soient russies (parce quautorises) ou quelles aient choues (empches par les mcanismes de contrle daccs). Les principales oprations surveiller sont : - la connexion et la dconnexion des utilisateurs ; - la cration, modification, destruction des informations de scurit (droits daccs, mots de passe, etc.) ; - les changements de privilges. Les journaux daudit doivent tre indestructibles (sauf par les administrateurs de laudit). Ils doivent porter sur tous les utilisateurs (y compris les administrateurs et les responsables de la scurit) et contenir un maximum dinformations utiles (date et heure, identit de lutilisateur, type dopration, rfrence de linformation, etc.). Bien videmment, ladministrateur de laudit doit tre indpendant des administrateurs du systme surveill, et il est souhaitable que le systme surveill ne puisse pas accder au systme daudit. Les journaux daudit sont en particulier lune des sources dinformations des systmes de dtection dintrusion.

1.5.2.4 Dtection dintrusions

Il existe deux types de systmes de dtection dintrusions (ou IDS pour Intrusion Detection System) : - les IDS sur rseau (Network Based IDS), qui observent les paquets circulant sur le rseau ; ce sont des machines indpendantes ddies la dtection dintrusions ; - les IDS sur hte (Host Based IDS), qui observent le comportement du systme, en particulier les appels systmes, ou qui analysent les informations daudit ; il sagit alors de fonctions intgres au systme quils observent.

24

Chapitre 1 Scurit des SICSS

Les techniques de dtection dintrusions se rpartissent en deux classes (figure 1.9) : dtection danomalies, aussi appele approche comportementale, et dtection dattaques, dite galement approche par scnario. La dtection danomalies ( anomaly detection en anglais) consiste comparer le comportement observ dun utilisateur une rfrence de comportement normal de cet utilisateur. Toute dviation entre les deux comportements dclenche une alerte. Diffrentes mthodes ont t proposes pour dfinir ce qui est normal : des outils statistiques, des systmes experts, des mthodes inspires de limmunologie, des approches baysiennes, etc. La dtection dattaques ( misuse detection en anglais) est fonde sur la comparaison du comportement observ avec une rfrence correspondant des scnarios dattaques connus. Le principe consiste considrer que tout ce qui est dcrit dans la base dattaques est reconnu comme intrusif ; le reste est considr comme normal. De nombreux outils du march utilisent cette approche, on peut citer titre dexemple, RealSecure, NFR, Dragon et Snort. Ces deux types de dtection se distinguent par leurs taux thoriques de fausses alertes (faux positifs) et de non-dtections (faux ngatifs). Dans le cas de la dtection danomalies, on peut en gnral rgler le gain du dtecteur (par analogie avec les systmes radar), pour choisir un point de fonctionnement correspondant un bon compromis entre ces deux taux. Les techniques de dtection dattaques, quant elles, ont lavantage didentifier quel type dattaque est en cours (avec relativement peu de faux positifs, du moins en thorie), mais ne permettent de dtecter que les symptmes dattaques connues. Dans les deux cas, il ne sagit que de contrles de vraisemblance, donc imparfaits. En fait, il faut considrer que les IDS sont surtout une aide ladministration de la scurit : sans IDS, ladministrateur ne peut dtecter les attaques que par leurs effets.
comportement normal

dtection danomalies

comportement observ alertes

=
scnarios dattaques dtection dattaques

Figure 1.9 : Techniques de dtection dintrusions Des travaux plus rcents tentent de disposer, terme, dun systme de dtection dintrusions global. Il prend en entre aussi bien des donnes rseaux (provenant des IDS sur rseau) que des donnes systmes (provenant des IDS sur hte), en les analysant selon une mthode croise utilisant la fois lapproche comportementale et lapproche par scnario [Debar & Wespi 2001]. En outre, ces travaux font cooprer diffrents outils afin de tirer partie des forces de chacun pour limiter le taux de faux ngatifs dune part, et de corrler les alarmes mises afin de limiter le taux de faux positifs dautre part : - Il est trs rare quune attaque gnre une seule alarme. La corrlation permet de grouper les alarmes relatives une mme attaque, dtudier les diffrentes attaques en cours, dvaluer globalement la situation et de prparer une rponse approprie. - tant donn que les IDS gnrent de nombreux faux positifs, la corrlation permet, en utilisant plusieurs sources de donnes, de vrifier la pertinence des alarmes et daffiner le

25

diagnostic par le croisement de plusieurs alarmes ou la recherche dinformations complmentaires. Le cot de la collecte et de lanalyse dinformations par un outil de dtection dintrusions est dautant plus lev que la source dinformations est prcise. La corrlation permet dadapter la quantit dinformations collectes aux menaces potentielles dont les alarmes indiquent la prsence.

1.5.2.5 Tolrance aux intrusions

Il est illusoire de croire quon peut viter les attaques sur les systmes de grandes tailles. De mme il est impossible dliminer toutes les vulnrabilits. Il faut donc sattendre ce que certaines attaques russissent, cest--dire produisent des intrusions. Dailleurs, le terme intrusion doit tre pris dans un sens large, puisquil ne faut pas considrer que tous les intrus sont externes. Un grand nombre dentre eux sont des utilisateurs enregistrs qui tentent dtendre leurs privilges, voire des utilisateurs privilgis qui abusent de leurs privilges. Puisquil est invitable que des intrusions se produisent, il serait intressant de tolrer les intrusions, cest--dire de faire en sorte que lintrusion dans une partie du systme nait pas de consquence sur sa scurit. Pour cela, on pourrait utiliser les techniques dveloppes dans le cadre plus gnral de la tolrance aux fautes. Mais cela pose deux problmes principaux : - si un attaquant a russi sintroduire dans une partie du systme, il ne doit pas lui tre trop facile de russir la mme attaque sur une autre partie ; cela signifie que chaque partie soit suffisamment scurise et, de prfrence, quelle soit diversifie, cest--dire que ses constituants ne prsentent pas les mmes vulnrabilits [Deswarte et al.1999] ; - il ne faut pas quune seule intrusion dans une partie du systme fournisse lattaquant des informations sensibles ; ceci est dautant plus important que la redondance, ncessaire la tolrance aux fautes, peut fournir plus doccasions dattaques aux pirates ventuels. Une technique de tolrance aux intrusions a t dveloppe pour prserver la confidentialit tout en permettant de tolrer les fautes accidentelles et les intrusions, y compris par des utilisateurs privilgis : la fragmentation-redondance-dissmination, [Fabre et al.1996]. Cette technique est fonde sur le principe dutilisation de la rpartition dun systme sur un rseau local de faon ce quune intrusion ne mette pas en dfaut la confidentialit, lintgrit ou la disponibilit du systme. La fragmentation consiste donc dcouper les informations sensibles en fragments de telle sorte quun fragment isol ne contienne pas dinformation significative (confidentialit). On ajoute de la redondance ces fragments de faon ce que la modification ou la destruction de fragments nempche pas la reconstruction de linformation (intgrit et disponibilit). Enfin, la dissmination vise ce quune intrusion ne donne accs qu des fragments isols. La dissmination peut tre topologique, en utilisant des sites de stockage diffrents, ou en transmettant les fragments sur des canaux de communications indpendants. Elle peut tre temporelle, en transmettant des fragments dans un ordre alatoire et en y ajoutant ventuellement des faux fragments de bourrage. La dissmination peut aussi porter sur les privilges, en exigeant la coopration de plusieurs personnes ayant des privilges diffrents pour accomplir une opration (sparation des pouvoirs). Lorsque la confidentialit nest pas critique, on peut utiliser des mthodes classiques de tolrance aux fautes, comme la dtection et la correction derreurs, ou le masquage derreurs. Dans ce contexte, la dtection derreurs peut reposer sur des techniques de dtection dintrusions, ou sur la comparaison de plusieurs excutions diversifies. La correction derreurs repose alors sur la reprise (r-excution partir de sauvegardes) ou sur la poursuite (on rtablit le systme dans une configuration correcte). Le masquage derreurs consiste avoir suffisamment dexemplaires des donnes et des excutions pour pouvoir corriger les dgts causs par les intrusions.

26

Chapitre 1 Scurit des SICSS

Rcemment, le projet europen MAFTIA (pour Malicious and Accidental-Fault Tolerance for Internet Applications) visait faciliter les dveloppements dapplications Internet tolrant les intrusions [Powell & Stroud. 2003]. Des protocoles et des intergiciels ont t dvelopps pour grer plus facilement les communications de groupe tolrant les fautes (y compris les fautes byzantines). Ces protocoles et intergiciels ont, en particulier, permis le dveloppement de tierces parties de confiance (par exemple, une autorit de certification) qui tolrent les intrusions (y compris de certains des administrateurs). Des mthodes de dtection dintrusions rpartie sur Internet ont t tudies avec une attention particulire, puisque la dtection dintrusions contribue la tolrance aux intrusions, mais cest aussi lune des cibles privilgies des attaquants. Il faut donc faire en sorte que ces mcanismes de dtection tolrent eux-mmes les intrusions.

1.5.2.6 valuation de la scurit

Il est important dvaluer la scurit des systmes dinformation et de communication, pour savoir si on a obtenu un niveau de scurit satisfaisant, pour identifier les points les plus critiques surveiller ou corriger, et enfin pour estimer sil est rentable de mettre en uvre telle ou telle dfense supplmentaire. Trois grandes mthodes dvaluation de la scurit peuvent tre distingues : lutilisation des critres dvaluation, lanalyse des risques ainsi que les mthodes dvaluation quantitative de la scurit.

1.5.2.6.1 Critres dvaluation

Les premiers critres dvaluation de la scurit ont t dfinis aux Etats-Unis dans ce qui est couramment appel le Livre Orange ou TCSEC (Trusted Computer System Evaluation Criteria ) [TCSEC 1985], ou dans les diffrentes interprtations associes des livres de diverses couleurs qui laccompagnent, comme le Livre Rouge ou T N I (Trusted Network Interpretation of the TCSEC) [TNI 1987]. Ces critres, fonds la fois sur des listes de fonctions de scurit remplir et sur les techniques employes pour la vrification, conduisent classer les systmes en sept catgories (D , C1 , C2 , B1 , B2 , B3 , A1). Pour chaque niveau, quatre familles de critres sont dfinies, traitant de la politique dautorisation, de laudit, de lassurance et de la documentation : - La politique dautorisation stipule une politique prcise suivre (discrtionnaire ou obligatoire) en fonction des diffrents niveaux de certifications viss. La politique obligatoire impose est celle dfinie par Bell-LaPadula [Bell-LaPadula 1976] (voir 2.2). - Les critres daudit prcisent les fonctions requises en matire didentification, dauthentification et daudit des actions. - Les critres dassurance fixent des recommandations concernant des mthodes de conception et de vrification utilises afin daugmenter la confiance de lvaluateur, il sagit de garantir que le systme implmente bien la fonctionnalit quil prtend avoir. - Les critres de documentation spcifient les documents qui doivent tre fournis avec le produit lors de lvaluation. Les caractristiques principales des diffrents niveaux dfinis par le livre orange sont ainsi : - un systme class au niveau D est un systme qui na pas t valu ; - jusquau niveau C1 et C2, le systme peut utiliser une politique discrtionnaire ; - pour les niveaux B1, B2, et B3 le systme utilise une politique obligatoire ; - un systme class A1 est fonctionnellement quivalant un systme class B3, sauf quil est caractris par lutilisation de mthodes formelles de vrification pour prouver que les contrles utiliss permettent bien dassurer la protection des informations sensibles.

27

Les TCSEC visent dabord satisfaire les besoins du DoD (Department of Defense) des tats-Unis, privilgiant ainsi la confidentialit des donnes militaires. Par ailleurs, le manque de souplesse et la difficult de leur mise en uvre, ont conduit au dveloppement de nouvelles gnrations de critres. titre dexemple abordons les critres adopts par la Communaut Europenne [ITSEC 1991], mais dautres pays tels que le Canada [CTCPEC 1993] et le Japon [JCSEC 1992] ont galement labor leurs propres critres dvaluation. Les ITSEC sont le rsultat dharmonisation de travaux raliss au sein de quatre pays europens : lAllemagne, la France, les Pays-Bas et le Royaume-Uni [ITSEC 1991]. La diffrence essentielle entre les TCSEC et les ITSEC rside dans la distinction entre fonctionnalit et assurance. Une classe de fonctionnalit dcrit les fonctions que doit mettre en uvre un systme tandis quune classe dassurance dcrit lensemble des preuves quun systme doit apporter pour montrer quil implmente les fonctions quil prtend fournir. Les ITSEC introduisent galement la notion de cible dvaluation (TOE pour Target Of Evaluation). Une TOE rassemble les diffrents lments du contexte dvaluation, dont une politique de scurit, une spcification des fonctions requises ddies la scurit, une dfinition des mcanismes de scurit (optionnelle), la cotation annonce de la rsistance minimum des mcanismes, ainsi que le niveau dvaluation vis. Les ITSEC proposent dix classes de fonctionnalits 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 dintgrit (par exemple, pour les bases de donnes) ; - la classe de fonctionnalit F-AV impose des exigences de disponibilit ; - la classe de fonctionnalit F-DI impose des exigences leves pour lintgrit des donnes au cours de leur transmission ; - lexemple de classe de fonctionnalit F - D C est destine aux TOE exigeantes en confidentialit des donnes au cours de leur transmission ; - la classe de fonctionnalit F-DX est destine aux rseaux exigeants en matire de confidentialit et dintgrit de linformation. Les diffrents critres dassurance exigs se dcoupent en deux aspects : les critres dassurance defficacit et les critres dassurance de conformit. Ces critres dassurance se dcoupent nouveau en deux catgories vis--vis de la construction et de lexploitation du systme. Les critres dassurance de conformit sont dfinis vis--vis de six niveaux dexigences, numrots de E1 E6, qui correspondent des contraintes de plus en plus fortes et dfinissent le niveau de certification atteint par une TOE. De plus amples dtails sur les ITSEC et les TCSEC peuvent tre trouvs dans [Branstad et al. 1990 ; Dacier 1994]. La tentative dharmonisation des critres canadiens, europens et amricains, a donn naissance aux critres communs (en anglais Common Critria for Information Security Evaluation ) [CC 1999a] qui sont maintenant une norme internationale [ISO 15408]. Ces critres contiennent deux parties bien distinctes comme dans les ITSEC : fonctionnalit et assurance. Les critres communs dfinissent galement une cible dvaluation (TOE) ainsi que les profils de protection [CC 1999b], dj existants dans les critres fdraux amricains [Federal Criteria 1992]. Pour une catgorie de TOE, un profil de protection dfinit un ensemble dexigences de scurit et dobjectifs, indpendant dune quelconque implmentation. Lintrt de ces profils est double : un dveloppeur peut inclure dans la dfinition de la TOE un ou plusieurs profils de protection ; un client dsirant utiliser un systme ou un produit peut

28

Chapitre 1 Scurit des SICSS

galement demander ce quil corresponde un profil de protection particulier, vitant ainsi de donner une liste exhaustive des fonctionnalits et des assurances quil exige.

1.5.2.6.2 Analyse des risques

Un risque peut tre vu comme un vnement redout, auquel on peut attribuer une frquence doccurrence et un cot. La littrature dfinit diffrentes notions relatives aux risques comme lvaluation, la gestion et lanalyse des risques [Dacier 1994]. Dans notre travail, nous nous intressons ce dernier concept, car plus large, et englobant les deux autres. Lanalyse des risques est une discipline destine mettre en uvre une politique de scurit en tenant compte des vulnrabilits rsiduelles, en valuant leurs impacts sur la scurit, et en calculant les rapports cots/bnfices apparaissant dans une organisation [ISO 17799]. Dune manire gnrale, une analyse des risques peut tre faite selon les tapes suivantes : - lidentification des actifs, cest--dire les lments protger dans le systme ; - pour chaque actif, lidentification des menaces correspondantes (contre qui ou quoi on veut protger les actifs ?) ; - lanalyse des consquences de la ralisation dune menace sur lactif du systme ; - le calcul des risques : pour chaque menace, calculer le risque quelle reprsente ; ce risque tant valu comme gal la frquence doccurrences de la menace multiplie par la consquence financire de sa ralisation ; - lvaluation des parades possibles qui identifient les contre-mesures utilisables pour parer une menace ainsi que leur efficacit et leur cot ; - la proposition dun choix de parades optimales du point de vue du rapport cot/efficacit pour lamlioration du niveau existant de scurit ; - la formulation dun plan de scurit qui constitue le rsultat final de ltude incluant le compte-rendu des rsultats prcdents et un plan de mise en uvre des nouvelles mesures de protection choisies.` La ralisation de ces diffrentes tapes peut seffectuer sous divers modes opratoires. titre dexemple, on peut citer les approches bases sur : - les listes de contrle qui partent des parades disponibles et tudient la ncessit de leur mise en place ; - lidentification de scnarios dattaques, qui prennent en compte non seulement la possibilit de russir exploiter une vulnrabilit, mais galement la probabilit de russir exploiter une succession dattaques ; - lvaluation quantitative qui partant de lidentification exhaustive des actifs, des vulnrabilits et des menaces, propose une quantification des risques ; cette approche sera tudie en dtail dans la section suivante. Le principal problme de lanalyse des risques reste celui de la collecte des donnes. Soit la mthode se veut exhaustive et devient alors extrmement coteuse en temps et en effort, soit elle utilise une mthode de slection et sen remet alors en pratique la qualit de lexpertise de lvaluateur. De plus la majorit des organisations ne dispose pas dune modlisation relle de leurs fonctionnements. Par consquent, les valuations des effets des menaces et des vulnrabilits sur la scurit demeurent peu efficaces ou tout au moins difficiles.

1.5.2.6.3 valuation quantitative

Dans cette section, nous dtaillons une mthode dvaluation de la scurit qui utilise les indicateurs quantitatifs de la scurit, de faon permettre aux administrateurs de surveiller au

29

jour le jour le niveau de scurit et de prendre des mesures correctives en cas de baisse de ces indicateurs. Ceci permet dvaluer la scurit oprationnelle, cest--dire correspondant la faon dutiliser les systmes et ses mcanismes de protection, plutt quune vision statique comme celle donne par les critres dvaluation ou par les mthodes classiques danalyse de risques. Cest aujourdhui un domaine de recherche actif, mais qui a jusqu prsent donn peu de rsultats. Cest le cas de la mthode dvaluation de la scurit en calculant le temps et leffort ncessaire un intrus pour violer les objectifs de protection [Dacier 1994]. Cette mthode utilise un formalisme bas sur les graphes de privilges (voir 2.2.2.5) et les rseaux de Petri stochastiques, et se base sur les tapes suivantes : - dtermination des vulnrabilits prendre en compte, en sappuyant notamment sur la politique de scurit ou sur une liste de vulnrabilits dj identifies ; - quantification de ces vulnrabilits ; - valuation quantitative en utilisant la politique de scurit et une reprsentation des vulnrabilits existantes dans le systme. Cette mthode utilise le graphe de privilge comme modle de reprsentation des vulnrabilits dun systme [Dacier 1994 ; Dacier & Deswarte 1994]. Dans le graphe de privilge, une vulnrabilit correspond une mthode de transfert de privilges. Les nuds du graphe reprsentent les diffrents privilges qui existent dans le systme. Un arc est cr entre deux nuds si une mthode, possdant les privilges du nud origine, permet dobtenir ceux du nud destination. Lexistence dun arc entre deux nuds dpend donc de ltat du systme un instant donn, qui peut ou non permettre lexploitation dune certaine vulnrabilit. Les vulnrabilits, qui doivent tout au dbut de ce processus tre recherches dans le systme, peuvent avoir des origines varies, comme la mauvaise utilisation des mcanismes de protection ou les dlgations de pouvoirs. Des valeurs quantitatives sont ensuite associes aux vulnrabilits lmentaires afin de dfinir des mesures quantitatives de la scurit globales. Par exemple, on affecte chaque arc du graphe des privilges un poids correspondant leffort ncessaire un attaquant potentiel pour exploiter la mthode de transfert de privilges correspondant cet arc. Cette notion deffort regroupe les diffrentes caractristiques du processus dattaque comme la puissance de calcul disponible pour lattaquant. Par ailleurs, les objectifs de scurit dfinis par la politique de scurit permettent didentifier les diffrents nuds du graphe correspondant aux attaquants et aux cibles potentiels qui sont pertinents tudier dans un systme donn. Les travaux effectus par Ortalo ont utilis cette mthode et ont abouti llaboration du prototype SOPE (pour valuation de la Scurit Oprationnelle) [Ortalo et al.1999]. Enfin, il est important de noter que les mesures de scurit que nous avons dcrites (cloisonnement, dtection et tolrance aux intrusions, chiffrement, etc.) ne devront pas tre mises en place tant que lon naura pas dfini et document au pralable une politique de scurit. En effet, une dmarche scuritaire repose sur une politique de scurit pour recenser les objectifs de scurit atteindre, les lments protger ainsi que les risques encourus (et leurs combinaisons). Ensuite il convient de dfinir comment le systme volue (face aux risques identifis) et quelles sont les mesures prventives et les mcanismes mettre en place. Lvaluation de la scurit permet, par la suite, didentifier le niveau de scurit vis et de savoir (ou prouver) si la politique et les mcanismes de scurit mis en uvre permettent bien datteindre le niveau vis.

Chapitre 2. Politiques et modles de scurit

Prambule
Le prcdent chapitre a prsent les dfinitions relatives la notion de sret de fonctionnement. La scurit a t prsente comme la combinaison de trois proprits : la confidentialit, lintgrit et la disponibilit de linformation. Ensuite, les principales techniques et mesures de scurit ont t dfinies, et lanalyse a montr lintrt des politiques dautorisation dans la construction de la scurit dun systme ou dune organisation. Examinons maintenant les grandes familles de politiques de scurit ainsi que les principaux modles de scurit reprsents dans la littrature ; en loccurrence les politiques discrtionnaires, obligatoires, base de rles, ainsi que les modles HRU, Take-Grant, TAM, graphe des privilges, etc. Nous valurons les avantages et les limites de ces modles et politiques de scurit, puis les confrontons aux spcificits des SICSS, dj identifies. Les rsultats de projets rcents, sintressant aux problmes de la scurit dans le domaine mdical, et plus prcisment aux politiques de scurit, seront galement abords. Enfin, la discussion des politiques actuellement en vigueur permettra de conclure quelles ne couvrent pas toute la richesse des SICSS. Sur le plan rglementaire, les bases et textes lgaux existent, mme sils ne sont pas assez formaliss ou formalisables, de mme quils ne sont pas encore appliqus ou applicables dans les pays europens. Sur le plan technique, les notions de rles et dquipes sont prometteurs. Nanmoins, elles ncessitent une adaptation considrable et doivent tre compltes par de nouveaux concepts.

32

Chapitre 2 Politiques et modles de scurit

2.1. Classification des politiques et modles de scurit

On considre gnralement trois volets de dfenses pour assurer la scurit des systmes dinformation et de communication : physique, administrative et logique. Dans ce chapitre, on sintresse la scurit logique, et plus particulirement aux contrles daccs, dfinis travers les politiques dautorisations. Dun point de vue conceptuel, il sagit : - dune part, de dfinir un ensemble dobjectifs de scurit satisfaire. Ces objectifs portent sur la confidentialit, lintgrit et la disponibilit, et stipulent un ensemble de contraintes sur ces proprits ; - dautre part, de spcifier un ensemble de rgles dcrivant les actions autorises (ou non), et ce conformment aux objectifs soulevs. Lensemble de ces rgles dfinit un schma dautorisation [Sandhu 1992]. La plupart des politiques de scurit reposent sur les notions de sujets, dobjets et de droits daccs. Un sujet est une entit active, correspondant un processus qui sexcute pour le compte dun utilisateur. Dans ce contexte, un utilisateur est une personne physique connue du systme informatique et enregistre comme utilisateur ; ou un serveur, sorte de personne morale reprsentant des fonctions de service automatiques, tel que le serveur dimpression, serveur de base de donnes, serveur de messagerie, etc. Un objet12 est une entit considre comme passive qui contient ou reoit des informations. un instant donn, un sujet a un droit daccs sur un objet si et seulement si le processus correspondant au sujet est autoris excuter lopration correspondant ce type daccs sur cet objet. Les politiques de scurit, ou plus prcisment leurs schmas dautorisation, se classent en deux grandes catgories : les politiques discrtionnaires (ou DAC pour Discretionary Access Control ) et les politiques obligatoires (ou MAC pour Mandatory Access Control). Il existe galement des variantes de ces politiques qui peuvent mieux sadapter des organisations particulires, comme les politiques bases sur la notion de rles (ou RBAC pour Role-Based Access Control ) ou encore sur la notion dquipes (ou TMAC pour TeaM-based Access Control ). Idalement, il faut construire une politique de scurit de telle sorte quaucune squence valide dapplications des rgles (du schma dautorisation) ne puisse amener le systme dans un tat tel quun objectif de scurit soit viol. Ceci suppose lutilisation dune mthode formelle de construction des rgles du schma dautorisation, partir dune spcification formelle des objectifs de scurit. Les politiques dautorisation les plus cites dans la littrature sont gnralement associes un modle de scurit. Dune manire gnrale, un modle peut tre dfini comme un formalisme (souvent mathmatique) qui offre une vue subjective mais pertinente de la ralit. On modlise pour mieux comprendre le systme quon dveloppe, cest--dire pour visualiser ses proprits, spcifier sa structure ou son comportement, documenter et guider sa construction, etc. partir de l, un modle de scurit peut tre dfini comme un formalisme permettant de reprsenter, de faon claire et non-ambigu, la politique de scurit. Il aide labstraire (afin de rduire sa complexit) et faciliter sa comprhension, comme il peut servir vrifier que cette politique est complte et cohrente, et que la mise en uvre par le systme de protection est conforme aux proprits attendues du systme. Les modles de scurit existants peuvent tre classs en deux grandes familles : - des modles gnraux, qui sont plutt des mthodes de description formelle, pouvant sappliquer toute sorte de politiques. Cest par exemple le cas de :

12 Cette notion dobjet est prendre dans un sens large. Elle peut recouvrir les notions classiques dobjet des systmes dits orients-objets et incluant les sujets eux-mmes.

33

modles de machines tats, reprsentant le systme comme un ensemble dtats et de transitions qui, partir dun tat courant et une valeur dentre, dtermine le nouvel tat du systme ; on peut considrer que cette famille englobe les autres (chacune se distingue par la faon de reprsenter un tat, la fonction de transition, ou encore lensemble des tats qui satisfont la politique de scurit) ; modles bass sur les matrices daccs, manipulant les trois concepts fondamentaux que sont les sujets, les objets et les actions ; les lments qui se situent au croisement de la ligne L et de la colonne C correspondent aux droits que possde le sujet correspondant L sur lobjet de C ; les modles de Lampson [Lampson 1971], HRU [HRU 1976] et Take-Grant [Jones et al. 1976] sont des exemples des premiers modles reprsents par des machines tats ou des matrices daccs ; - des modles spcifiques, dvelopps pour reprsenter une politique dautorisation particulire ; citons titre dexemple : les modles fonds sur les treillis, qui affectent chaque utilisateur et chaque objet un niveau de scurit prcis ; ce type de modle a t associ aux politiques multiniveaux de Bell-LaPadula [Bell-LaPadula 1976] et de Biba [Biba 1977] (voir 2.3) ; dautres modles (gnralement moins formaliss), comme celui de Clark et Wilson [Clark & Wilson 1987] dvelopp pour les organisations commerciales, celui de la muraille de Chine [Brewer & Nash 1989] visant reprsenter les conflits dintrts dans les institutions financires, ou ceux base de rle [Sandhu et al. 2000], adapts plusieurs types dorganisations, et qui utilisent des rles comme entit intermdiaire entre les sujets et les permissions. Par la suite, il conviendra de dtailler chacune de ces politiques et chacun de ces modles de scurit. Chaque classe de politiques sera associe aux modles qui lont reprsente, ou qui sont susceptibles de la reprsenter.

2.2. Politiques et modles dautorisation discrtionnaires (DAC)

2.2.1. Prsentation des DAC
Dans le cas dune politique discrtionnaire, les droits daccs chaque information sont manipuls librement par le responsable de linformation (gnralement le propritaire), sa discrtion. Les droits peuvent tre accords par ce responsable chaque utilisateur, des groupes dutilisateurs, ou bien aux deux. Ceci peut parfois amener le systme dans un tat dinscurit (cest--dire contraire aux objectifs de scurit qui ont t choisis). Prenons un exemple simple, reposant sur les mcanismes de protection dUnix. Dans un tel systme, les droits daccs un fichier sont dfinis et modifiables librement par lutilisateur propritaire du fichier (et donc par les processus qui sexcutent pour son compte). Supposons que le schma dautorisation se dfinisse (informellement) de la manire suivante : u n utilisateur peut crer des fichiers dont il devient alors propritaire ; le propritaire dun fichier peut dcider quels utilisateurs sont autoriss lire ses fichiers. Dautre part, supposons que la politique exige de respecter lobjectif suivant : les utilisateurs qui nont pas le droit de lire un fichier ne doivent pas pouvoir en connatre le contenu. Une telle politique nest pas ralisable par des mcanismes dautorisation discrtionnaire, parce que13 :

13 En raison de sa simplicit, nous avons choisi une notation drive du modle HRU. Celui-ci sera dcrit en dtail en 2.2.2.2.

34

Chapitre 2 Politiques et modles de scurit

si s 1 est un sujet sexcutant pour le compte de lutilisateur u1 propritaire du fichier f1, il peut donner au sujet s2 (sexcutant pour le compte du2) le droit de lecture sur f1 : (s1, f1, propritaire) (s2, f1, lire) s2 peut crer un fichier f2 (dans lequel il peut donc crire) sur lequel il peut donner le droit de lecture s3 (sexcutant pour le compte du3) : (s2, f2, crer) (s2, f2, crire) (s3, f2, lire) s2 peut alors recopier f1dans f2 pour transmettre les informations de f1 s3 linsu du propritaire s1 : (s2, f1, lire) (s2, f2, crire) (s3, f2, lire) (s3, k(f1), lire) o (k(f1) dsigne une copie de f1)

Une politique discrtionnaire nest donc applicable que dans la mesure o il est possible de faire totalement confiance aux utilisateurs et aux sujets qui sexcutent pour leur compte. Une telle politique est par l mme vulnrable aux abus de pouvoir provoqus par maladresse ou par malveillance. Ainsi, sil est possible un utilisateur daccder certains objets ou den modifier les droits daccs, il est possible quun cheval de Troie sexcutant pour le compte de cet utilisateur ( son insu) en fasse de mme. De plus, si un utilisateur a le droit de lire une information, il a (en gnral) le droit de la transmettre nimporte qui.

2.2.2. Modles associs aux DAC

Cette section prsente les premiers modles conus ou utiliss pour reprsenter les politiques discrtionnaires. Notons tout de mme que ces modles peuvent ventuellement tre utiliss pour reprsenter et formaliser dautres types de politiques. Nanmoins, pour des raisons principalement chronologiques, il a sembl plus pertinent de les inclure dans cette section.

2.2.2.1 Modle de Lampson

La notion de matrice de contrle daccs, ddie la reprsentation des droits daccs (autorisations), a t introduite par Lampson ds 1971 [Lampson 1971]. La structure de ce modle est celle dune machine tats o chaque tat est un triplet (S,O,M) avec : S dsignant un ensemble de sujets, O un ensemble dobjets et M une matrice de contrle daccs. Chaque cellule M (s,o) de cette matrice contient les droits daccs que le sujet s possde sur lobjet o . Les droits correspondent gnralement des actions lmentaires comme lire ou crire. La matrice des droits daccs nest pas fige. En effet, si de nouveaux objets, de nouveaux sujets ou de nouvelles actions sont ajoutes dans le systme, il devient alors ncessaire denregistrer toutes les permissions accordes pour ces nouvelles entits. Par consquent, la mise jour dune politique de scurit exprime par ce modle est quelque peu fastidieuse. Enfin, ce modle ne permet pas dexprimer directement des interdictions ou des obligations. Le modle de Lampson a t progressivement amlior pour donner naissance dautres modles tels que HRU [HRU 1976] et Take-Grant [Jones et al. 1976].

2.2.2.2 Modle HRU

Le modle HRU sest intress la complexit de la tche de vrification des proprits assures par une politique dautorisation. Comme dans le modle de Lampson, HRU utilise une matrice daccs classique, la diffrence rside en ce que HRU prcise les commandes qui peuvent lui tre appliques. Les seules oprations possibles sont donnes dans le tableau 2.1. Le format des commandes est prsent dans le tableau 2.2, o x i est un paramtre de la commande, a(i) A est un droit, et opi est une des six oprations lmentaires possibles.

35

Enter a into M(s, o) Create subject s Create object o

delete a from M(s, o) destroy subject s destroy object o

Tableau 2.1 : Format dune commande HRU.

Command a(x1, x2, .., xk) If aM(s, o) and aM(s, o) and and a(m)M(s(m), o(m)) Then op1 ; op2 ; .. ; opn End

Tableau 2.2 : Oprations lmentaires de HRU. tant donn un systme, une configuration initiale Q 0, et un droit a , on dit que Q 0 est sr pour a , sil nexiste aucune squence doprations qui, excute partir de ltat Q0, peut amener le droit a dans une cellule particulire (i.e. pas dans nimporte laquelle) de la matrice de contrle daccs dans laquelle a ne se trouve pas dj. La dmonstration de cette proprit constitue le problme de protection (safety problem). En fait, ce problme revient vrifier quun schma dautorisation est correct vis--vis dun ensemble dobjectifs de scurit. Harrison, Ruzzo et Ullman ont dmontr deux thormes fondamentaux concernant la complexit du problme de protection : - le problme de protection est indcidable dans le cas gnral, cest--dire, tant donn une matrice daccs initiale et un ensemble de commandes, il est impossible de savoir si aucune squence dapplications de ces commandes naura pour consquence de mettre un droit particulier dans un endroit de la matrice o il ne se trouvait pas initialement ; - le problme de protection est dcidable pour les systmes mono-opration, cest--dire dont les commandes ne contiennent quune seule opration lmentaire. Le modle HRU mono-opration est trs pratique manipuler nanmoins, il reste trop simple pour couvrir des politiques de scurit intressantes. Dans la mesure o il ny a pas dopration lmentaire qui permette simultanment de crer un objet et dy associer des droits, le modle HRU mono-opration ne permet pas dexprimer des politiques dans lesquelles les sujets qui crent des objets se voient attribuer des droits spcifiques sur ces objets.

2.2.2.3 Modle Take-Grant

Diverses volutions issues du modle HRU ont tent de dterminer un modle suffisamment expressif pour reprsenter des politiques dautorisation sophistiques, mais pour lequel le problme de protection reste dcidable . Le modle Take-Grant [Jones et al. 1976] est constitu dun graphe dont les nuds sont des sujets ou des objets, et des rgles de modification de ce graphe. Il peut tre vu comme une variante dHRU ceci prs quil restreint les diffrentes commandes en les rpartissant en quatre catgories (figure 2.1 ; o P et R sont des sujets, Q est un sujet ou un objet) : - la commande create qui permet de crer un objet et dattribuer initialement un droit daccs un sujet sur cet objet ; - la commande remove qui permet de retirer un droit daccs dun sujet sur un objet ; - la commande take, reprsente par un arc tiquet t entre un sujet P et un sujet (ou objet) R, indique que P peut prendre tous les droits que R possde ;

36

Chapitre 2 Politiques et modles de scurit

la commande grant qui permet un sujet P possdant un droit daccs a sur Q ainsi que le droit g sur un autre sujet R, de cder R le droit a sur Q (que P possde sur Q) ;

Dans ce modle, le graphe reprsentant ltat de protection du systme, peut tre assimil la matrice daccs, et les quatre rgles ci-dessus (dites de rcriture), correspondent au schma dautorisation, cest--dire aux commandes.
P Rgle P create : P a Q

cre lobjet P

Q
a-g Q

Rgle remove : retire le droit g de P sur Q P g R Q P g R

a a

Rgle grant : P cde le droit a sur Q R P t R

a a

Rgle take : P obtient le droit a sur Q

Figure 2.1 : Rgles de rcriture du modle Take-Grant Mme si ces rgles peuvent paratre simples, leurs combinaisons peuvent mener le systme dans des tats dinscurit. En effet, lapplication successive de plusieurs rgles (bien choisies) peut donner dautres droits des sujets, ce qui risque de compromettre certains objectifs de scurit. Lexemple 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 ltat de protection initial, R possde le droit a sur O et le droit t sur P. Considrons un objectif de scurit stipulant que le systme est dclar non-sr si P parvient acqurir le droit a sur O.
R t P

Figure 2.2 : Un exemple simple dtat de protection dans le modle Take-Grant. La squence dapplication des rgles dcrites dans la figure 2.3 indique que le systme nest pas sr, alors que ce constat nest pas directement explicite dans la figure 2.2.
R t P

R t P

a
g tg

R t P

O g a

R t P

a a
tg

O g a N

tg

tg

1/ P cre un arc tiquet 2/ R reprend le droit 3/ R accorde le droit 4/ P prend le droit (a vers O) de N (a vers O) N tg vers un nouveau sujet N (g sur N) de P

Figure 2.3 : Exemple dapplication des rgles de rcriture dans le modle Take-Grant. Pour pallier ce type de problme, Jones et al. ont tudi le problme de protection dans le cadre du modle Take-Grant [Jones et al. 1976]. Ils dfinissent le prdicat can de la faon suivante : P can a Q est vrai si et seulement sil existe une squence de graphes G1, .., G n telle que P ait le droit a sur Q dans le graphe G n. Jones et al. dfinissent les conditions ncessaires et suffisantes pour que le prdicat soit satisfait. Ils tablissent galement lexistence dune solution algorithmique de complexit linaire permettant dtablir si le prdicat est

37

vrifi. Toutefois, les hypothses sous-jacentes ce modle sont assez peu ralistes. En effet, et comme on peut le constater avec lexemple prsent, sil est vrai que P peut parvenir acqurir le droit a sur O , il ne peut le faire que si R collabore avec lui. En ralit, il est difficile dimaginer que tous les sujets vont collaborer afin de mettre la scurit en pril. Une telle hypothse est donc de pire cas sur le comportement des utilisateurs du systme. Plusieurs raffinements des proprits dmontrables grce au modle Take-Grant ont t proposs, notamment afin de lever cette hypothse et de se concentrer sur les cas o un utilisateur [Synder 1981] ou un ensemble dutilisateurs [Dacier 1993] tentent de mettre en dfaut les objectifs de scurit. Ltude des proprits de ce modle dans des cadres spcifiques a fait lobjet de nombreux travaux, notamment ceux recenss dans [Dacier 1994].

2.2.2.4 Modle TAM

Sinspirant du modle HRU, Sandhu a prsent un modle appel TAM (Typed Access Matrix ) [Sandhu 1992]. Dans TAM, chaque objet appartient un certain type qui ne peut changer. Les commandes utilisent cette notion de type. Un modle de scurit utilisant TAM est compos dun ensemble fini A de droits, dun ensemble de types dobjets t et dun ensemble fini de types de sujets ts (ts t). Ces lments sont utiliss pour dfinir ltat de protection laide dune matrice de contrle daccs type. Le schma dautorisation est constitu de A, t, et dune collection finie de commandes TAM. Les oprations primitives de TAM sont donnes dans le tableau 2.3 (tsts ; tt). Les commandes TAM sont prsentes dans le tableau 2.4, o, xi:ti exprime que le paramtre xi est de type ti.
Enter a into M(s, o) Create subject s of type ts Create object o of type t delete a from M(s, o) destroy subject s of type ts destroy object o of type t

Tableau 2.3 : Oprations lmentaire de TAM.

Command a(x1 : t1, x2 : t2, .., xk : tk) If aM(s,o) and aM(s,o) and and a(m)M(s(m),o(m)) Then op1 ; op2 ; ; opn End

Tableau 2.4 : Format dune commande TAM. Sandhu montre quil est possible de rsoudre le problme de protection dans bon nombre de cas pratiques, sans perdre de puissance dexpression. Il dcrit un algorithme qui permet dobtenir un tat maximal de protection [Sandhu 1992]. Cet tat se caractrise par une matrice daccs sur laquelle on ne peut plus excuter de rgles du schma dautorisation. Une version dite augmente de TAM, appele ATAM, a t propose [Ammann et Sandhu 1992] afin de fournir un moyen simple de dtecter labsence de droits dans une matrice daccs. Pour cela, le modle ATAM offre la possibilit dutiliser des tests du type ai M(s,o) dans la partie conditionnelle de la commande. La faon de grer ce type de commande et de rsoudre le problme de protection a galement t dfinie. Lintrt de cette dmarche consiste modliser facilement la sparation des pouvoirs (celle-ci prconise lintervention de plusieurs utilisateurs pour mener bien une certaine tche).

38

Chapitre 2 Politiques et modles de scurit

2.2.2.5 Graphe de privilges

Dacier et Deswarte ont propos une extension du modle ATAM afin daugmenter son efficacit, notamment dans le cas de schmas dautorisation particuliers [Dacier & Deswarte 1994]. En effet, ils ont montr que lintroduction de privilges Ad-hoc dans un modle TAM peut amliorer sa complexit algorithmique dans certaines situations bien prcises. Puis ils ont propos un autre modle, le graphe de privilges, dans lequel un privilge est dfini comme tant un ensemble de droits S quun sujet s peut possder sur un objet o . Les nuds du graphe sont des ensembles de privilges que possdent chaque utilisateur sur des ensembles dobjets, autrement dit, des ensembles de triplets (U , O , S A) o U reprsente un sujet, O un objet et SA un ensemble de droits. Pour chaque type dobjets q , S q dsigne lensemble des objets de type q. Lexistence dun arc dun premier ensemble de privilges vers un second indique que la possession de ce premier ensemble permet dacqurir le second, par application dune ou plusieurs rgles du schma dautorisation [Dacier & Deswarte 1994 ; Dacier 1994]. Par exemple, lapplication de la rgle un sujet b peut accorder tous les droits en lecture quil a sur un objet de type obj3 crerait un nud que lon peut dfinir de la faon suivante : N = {(b, O, lecture) | O Sobj3 lecture [b,O]}. Ce nud reprsente un sous-ensemble des privilges que b possde effectivement dans la matrice daccs lorsque la rgle est applique, mais ce sous-ensemble nest pas fig. En effet, une telle dfinition dsigne galement les droits insrs dans la matrice aprs que le nud a t cr. Ceci est possible puisque le contenu du nud nest jamais numr mais seulement dfini. partir dun tat initial, lapplication successive des rgles du schma dautorisation conduirait lobtention (pour tout sujet U ) de MU, lensemble maximal de privilges que U pourrait obtenir. Cet ensemble correspond la ligne de la matrice reprsentant ltat maximal, au sens de TAM. En pratique, la construction du graphe de privilge (ses nuds et ses arcs) se fait progressivement par application des rgles qui composent le schma dautorisation. Pour cela, Dacier et Deswarte ajoutent deux oprations primitives aux six autres dfinies dans TAM : make_edge et make_node. La premire cre un nud tandis que la deuxime cre un arc dans le graphe ( conditions que ceux-ci nexistent pas dj). Lensemble des oprations est dabord utilis pour rcrire les rgles du schma dautorisation sous forme de commandes. Il est important de noter qu aucun moment, M U ne devrait tre calcul, et que le problme de protection revient tout simplement trouver un chemin dans le graphe des privilges selon le processus suivant : - pour chaque sujet U dans ltat de protection initial, crer un noeud dfini par : NU = {(U , O , SA) | O S t (S a = (A [U ,O ])) SA } ; (S a dsigne lensemble des droits de type a ), tout moment, cette dfinition reprsentera les privilges prsents dans la matrice pour cet utilisateur ; - appliquer les commandes jusqu atteindre un tat maximal, dans ce cas, ltat maximal est caractris la fois par le graphe construit et par la matrice daccs associe ; - reformuler le problme de protection en termes de deux ensembles de nuds conflictuels et chercher si un chemin existe entre ces deux ensembles. En outre, dans leur modle graphe de privilges, Dacier et Deswarte ont pu tablir les conditions ncessaires qui, si elles sont satisfaites, permettent davoir un gain considrable en complexit algorithmique par rapport TAM. Ces conditions ainsi quune application de ce modle dans le cadre du systme dexploitation UNIX sont donnes dans [Dacier 1994].

39

2.3. Politiques et modles dautorisation obligatoires (MAC)

Certes les politiques discrtionnaires prsentent plusieurs inconvnients, notamment les fuites dinformations et la vulnrabilit aux chevaux de Troie. Pour pallier ce type de problmes, les politiques obligatoires dcrtent des rgles incontournables destines forcer le respect des exigences de scurit. Ainsi, les politiques multi-niveaux affectent aux objets et aux sujets des niveaux non-modifiables par les usagers, et donc qui limitent leur pouvoir de grer les accs aux donnes quils possdent. Les politiques de Bell et LaPadula visant assurer la confidentialit, et celle de Biba sintressant lintgrit, en sont les exemples les plus anciens. Dautres politiques ont t dveloppes pour les systmes commerciaux et pour les institutions financires.

2.3.1. Les politiques multi-niveaux 2.3.1.1 Politique du DoD et modle de Bell-LaPadula

La politique multi-niveaux de Bell-LaPadula est une politique obligatoire, dveloppe pour le DoD (Department of Defense) des Etats-Unis [Bell-LaPadula 1976]. Elle a t mise au point au moment o les efforts se concentraient pour concevoir un systme dexploitation multiutilisateurs. Les permissions daccs sont dfinies travers une matrice de contrle daccs et un ensemble de niveaux de scurit. Cette politique considre seulement les flux dinformations qui se produisent quand un sujet observe ou modifie un objet. Destine au domaine militaire, la proprit assurer est la confidentialit. Le modle associ la politique de Bell-LaPadula est fond sur la notion de treillis. Il sappuie sur lassociation de diffrents niveaux aux sujets (niveaux dhabilitation) et aux objets (niveaux de classification). Chaque niveau n = (cl, C) est caractris par ses deux attributs : - C : un compartiment dfini par un ensemble de catgories, par exemple {nuclaire, dfense}. - cl : une classification prise dans un ensemble totalement ordonn, par exemple : {nonclassifi, confidentiel, secret}. Pour un objet o , la classification c(o) est un moyen de reprsenter le danger que peut constituer la divulgation de linformation contenue dans cet objet ; pour un sujet s, cest une habilitation h(s ) qui dsigne la confiance qui lui est accorde. Les niveaux constituent un treillis partiellement ordonn par une relation de dominance note et dfinie par : si n = (cl, C) et n = (cl, C) ; n n (n domine n) si et seulement si cl cl et C C Les objectifs de scurit de cette politique sont les suivants : interdire toute fuite dinformation dun objet possdant une certaine classification vers un objet possdant un niveau de classification infrieur ; - interdire tout sujet possdant une certaine habilitation dobtenir des informations dun objet dun niveau de classification suprieur cette habilitation. Le schma dautorisation associ ces objectifs de scurit en dcoule directement. On considre que lon peut distinguer vis--vis de la confidentialit, parmi les diffrentes oprations quun sujet peut effectuer sur un objet, les oprations de lecture et dcriture, et on introduit les rgles suivantes, incontournables mme par les propritaires des informations : Proprit simple : un sujet si ne peut lire un objet oj que si son habilitation h(si) domine la classification c(oj) de lobjet : (si, oj, lire) h(si) c(oj) Proprit toile : un sujet ne peut lire un objet o j et en crire un autre o k que si la classification dok domine celle doj : (si, oj, lire) (si, ok, crire) c(ok) c(oj)

40

Chapitre 2 Politiques et modles de scurit

La proprit simple interdit de lire des informations dune classification suprieure lhabilitation, et la proprit toile empche les flux dinformation dune classification donne vers une classification infrieure, ce qui constituerait une fuite dinformation : on peut vrifier facilement que si h(sn) < c(o i), il nexiste pas de suites {i,j,...,k} et {l,m,...,n} telles que : (sl, oi, lire) (sl, oj, crire) (sm, oj, lire) ... (sx, ok, crire) (sn, ok, lire). En effet, ceci conduirait (par les deux proprits) : c(oi) c(oj) h(sm) ... c(ok) h(sn) c(oi) h (sn), ce qui est contraire lhypothse de dpart. Le modle permet donc de mettre en vidence la cohrence de la politique, cest--dire que le schma dautorisation ne peut conduire un tat o la proprit une information classifie ne doit pas tre transmise un utilisateur non habilit la connatre ne soit pas respecte. Afin doffrir plus dexpressivit, dautres variantes de ce modle ont t introduites, notamment en traduisant les notions dobservation et de modification de linformation, non seulement par les oprations lmentaires : lire, et crire, mais aussi par excuter, ajouter : - excuter : accs sans modification ni observation ; - lire : observer sans modifier ; - ajouter (append) : modification sans observation, par exemple dans le cas des critures dans les fichiers daudits (audit logs), ou en ajoutant un chemin dans le fichier de configuration (autoexec.bat, par exemple) lors dune installation dun logiciel ; crire : observation et modification. Le modle peut tre reprsent par une machine tats o chaque tat est dfini par un triplet (S,O,M), o : - S : un ensemble de sujets ; - O : un ensemble dobjets ; - A : un ensemble doprations daccs ; A = {excuter, lire, ajouter, crire} ; - un ensemble de niveaux de scurit muni dune relation dordre partiel ; - B : lensemble de tous les tats possibles ; - M : lensemble des matrices (Mso)s S ; o O, F Ls Lc Lo : lensemble des niveaux de scurit ; dans un tat donn, fs est le plus haut niveau de scurit quun sujet peut avoir ; fc est le niveau courant de chaque sujet ; fo est la classification de lobjet. Les deux rgles de contrle daccs sont : - La proprit simple : un tat est sr si et seulement si, pour chaque sujet s qui observe un objet o , le niveau de scurit maximal du sujet domine le niveau de scurit de lobjet. Formellement, un tat satisfait la proprit simple si : "(s, o, a) b a {lire, crire} fo(o) fs(s). La proprit toile : un tat est sr si et seulement si, pour chaque sujet s qui modifie un objet o , le niveau de scurit de o domine le niveau courant de scurit de s. Formellement, un tat est sr si : "(s, o, a) b, a {ajouter, crire} fc(s) fo(o)

Dune manire plus prcise : Si lopration est un ajout, elle ne sera possible que si le niveau de scurit de lobjet domine le niveau courant de scurit du sujet ; - si lopration consiste crer un objet et dcrire dedans, le niveau de scurit de lobjet est gal au niveau courant de scurit du sujet ; -

41

si lopration est une lecture, le niveau de scurit de lobjet est domin par le niveau courant du sujet. Mais la politique de Bell-Lapabula prsente plusieurs inconvnients. Le plus important est la dgradation du service provoque par la surclassification des informations. En effet, au cours de sa vie, le niveau dune information ne peut que crotre : si une information non classifie est utilise 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 faon automatique, et il faut les dclassifier, manuellement par un officier de scurit ou par un processus dit de confiance (trusted process) nobissant pas aux rgles du modle. De plus, il est possible de construire un systme, appel Systme Z [McLean 1985], qui vrifie bien les deux proprits, et qui nest pourtant pas sr. Le systme Z est un systme o un utilisateur de niveau minimal met les niveaux de tous les sujets et de tous les objets au niveau minimal, et autorise laccs de tous les utilisateurs tous les objets. Ceci est possible car le niveau dun objet peut, lui-mme, tre mmoris dans un objet ; la valeur de ce dernier peut donc tre modifie par un utilisateur de niveau minimal (puisque lcriture dans un niveau dominant est autorise). -

2.3.1.2 Politique dintgrit de Biba

Dautres politiques obligatoires ont t dveloppes pour le maintien de lintgrit. Cest le cas de la politique propose par Biba [Biba 1977]. Celle-ci applique lintgrit un modle analogue celui de Bell-LaPadula pour la confidentialit. chaque sujet s on affecte un niveau dintgrit is(s), correspondant la confiance quon a dans ce sujet et chaque objet o possde un niveau dintgrit io(o), correspondant au niveau dintgrit du sujet qui la cr. Les objectifs de scurit de cette politique visent : - interdire toute propagation dinformation dun objet situ un certain niveau dintgrit vers un objet situ un niveau dintgrit suprieur ; - et interdire tout sujet situ un certain niveau dintgrit de modifier un objet possdant un niveau dintgrit suprieur. Le schma dautorisation dcoule de la recherche de ces proprits, en considrant des labels dintgrit et le fait que les oprations peuvent tre regroupes en trois classes : observation, modification et invocation. - Un sujet ne peut modifier un objet que si le label dintgrit du sujet domine le label dintgrit de lobjet : (si, oj, modifier) io(oj) is(si). Un sujet ne peut observer un objet que si le label dintgrit de lobjet domine le label dintgrit du sujet : (si, oj, observer) is(si) io(oj). Un sujet s i ne peut invoquer un sujet sj que si le label dintgrit de s i domine le label dintgrit de sj : (si, sj, invoquer) is(sj) is(si).

Ces rgles garantissent quune information ne pourra pas polluer celle dun niveau dintgrit suprieur. Cela dit, le modle de Biba prsente un inconvnient analogue celui de Bell-LaPadula : la dgradation des niveaux dintgrit. Si une information dun niveau dintgrit donn est utilise par un sujet dun niveau infrieur, tous les objets modifis ou crs par ce sujet partir de cette information seront dun niveau dintgrit infrieur. Il faut alors remonter artificiellement le niveau dintgrit de certains objets par des sujets de confiance, autoriss violer la politique de scurit. Cette politique a t tendue par Totel pour permettre la collaboration de logiciels de diffrents niveaux de criticit dans un mme systme [Totel 1998].

42

Chapitre 2 Politiques et modles de scurit

2.3.2. Politiques de Clark et Wilson

Dans lenvironnement commercial, la prvention contre les modifications non autorises de linformation (essentiellement contre les fraudes et les erreurs) est un atout primordial. Et mme si un utilisateur est autoris manipuler certaines donnes, cela ne doit pas pouvoir entraner une perte ou une falsification des actifs (capitaux, informations). Afin de rpondre ce type dobjectifs, Clark et Wilson proposent un autre type de politique obligatoire pour lintgrit [Clark & Wilson 1987]. Celle-ci vise assurer les besoins suivants : - Une cohrence (uniformit interne) des donnes faisant partie de ltat interne du systme. Ce type de cohrence peut tre impos par le systme de calcul. - Une cohrence entre ltat interne du systme informatique et le monde rel quil reprsente. La politique de Clark et Wilson repose sur deux anciens principes bien connus : les transactions bien formes et la sparation des pouvoirs. Le concept de transactions bien formes stipule que les utilisateurs nont pas le droit de manipuler les donnes dune manire arbitraire, mais seulement au travers des procdures de transformation spcifiques, prservant lintgrit des donnes. Une procdure de transformation peut tre par exemple un programme qui applique le principe de lquilibre de la balance en comptabilit (toute modification dans les grands livres de la comptabilit doit figurer dans les deux parties de la balance). Le concept de sparation des pouvoirs ( separation of duty) est lun des mcanismes classiques de contrle de fraudes et des erreurs. Il est fond sur la rpartition des oprations entre plusieurs parties, et lattribution des droits diffrents, mais complmentaires, diffrentes catgories de personnes. Dans certaines entreprises par exemple, lachat dune marchandise ncessite lintervention du service commercial qui fait la commande, du service de contrle qui vrifie lacquisition de la marchandise et du service financier qui paye les fournisseurs. Notons que toutes ces oprations sont accompagnes, la fois de traces papiers (bon de commande, bon de livraison, facture), et de traces informatiques. Une excution convenable de lopration globale implique une cohrence entre les reprsentations interne et externe des donnes, cest-dire la correspondance entre les procdures informatiques et celles du monde rel. Bien quvidentes, ces rgles ncessitent des techniques pour leur mise en uvre au niveau du systme informatique. Les procdures (transactions bien formes) manipulant les donnes doivent tre examines et bien tablies ; la capacit les installer et les modifier doit tre contrle ; la validit des donnes doit toujours faire lobjet dune vrification ; laffectation des droits aux utilisateurs ainsi que la sparation des pouvoirs doivent tres menes bien, etc. Pour cela, la politique de Clark et Wilson commence par sparer les donnes manipules en deux groupes : les donnes contraintes (notes CDI pour Constrained Data Items) et les donnes non contraintes (notes UDI pour Unconstrained Data Items). Le premier groupe dsigne les donnes soumises des rgles de manipulation strictes visant conserver leur intgrit. En effet, les diffrentes oprations de transformation doivent permettre de garantir que lintgrit des donnes contraintes persiste. Le deuxime groupe concerne les donnes dont lintgrit nest pas garantie et qui peuvent tre manipules arbitrairement. Ces donnes sont importantes car elles reprsentent la manire selon laquelle une nouvelle information est introduite dans le systme, comme les entres tapes par lutilisateur sur le clavier. Afin de reprsenter les rgles appliques dans leur politique de scurit, Clark et Wilson dfinissent leur modle de la manire suivante : - lensemble des utilisateurs, U = {u1, u2, } ; - lensemble des donnes contraintes, CDI = {CDI1, CDI2, } ; - lensemble des donnes non contraintes, UDI = {UDI1, UDI2, } ;

43

un ensemble doprations de vrification de lintgrit des donnes, IVP = {IVP1, IVP2, }. Ainsi, les CDI sont certifies par des IVP ; lensemble des oprations de transformation des donnes (Transformation Procedures, en anglais), TP = {TP1, TP 2, ...} ; les CDI ne peuvent tre manipules que par des TP ; une relation c liant chaque opration de transformation TPi, un sous ensemble c de CDI ; c prcise les donnes que lopration peut manipuler ;

Une relation u liant chaque utilisateur u et chaque opration de transformation TPi, un sous-ensemble de CDI ; u prcise les donnes contraintes quun utilisateur est autoris manipuler (par le biais de TPi). Lobjectif de cette politique de scurit est de garantir lintgrit des donnes contraintes et de satisfaire le principe de sparation de pouvoirs. Pour mettre en uvre la politique dintgrit, les rgles obligatoires du modle de Clark et Wilson imposent que : - les CDI soient dans un tat valide, vrifi par les IVP ; - toutes les oprations de TP doivent tre certifies ; si une donne contrainte est valide avant lexcution dune opration TPi, elle reste toujours valide aprs lexcution de TPi ; de plus, les oprations de TP ne peuvent tre effectues que sur des donnes contraintes spcifies par c ; chaque utilisateur neffectue des oprations de transformation sur des donnes contraintes que si celles-ci lui sont associes par u ; la relation u doit tre certifie afin de reflter les besoins de sparation de pouvoirs ;

le systme doit authentifier lidentit de chaque utilisateur souhaitant excuter une opration de TP ; - avant dtre excutes, les oprations de TP doivent enregistrer leurs identifiants dans les journaux daudit ; ceux-ci sont considrs comme donnes contraintes ; - chaque opration TPi qui accepte une donne UDIj en entre doit garantir que, quelle que soit la valeur de UDIj, soit TPi neffectue que des transformations conduisant une donne contrainte valide CDIk, soit UDIj est rejete. En dpit de sa prsentation relativement informelle, le modle de Clark et Wilson met en avant clairement un certain nombre de proccupations qui peuvent apparatre dans une organisation commerciale. Tout dabord, ce modle sintresse lassurance de la proprit dintgrit par le biais de lutilisation de procdures de transformation certifies. Il sensibilise ainsi la certification, activit importante lors de la conception dun systme. En outre, ce modle met en vidence deux proccupations importantes dans bon nombre de structures : la traabilit, cest--dire la possibilit de reconstituer les actions importantes du point de vue des objectifs de scurit, et la sparation des pouvoirs. Enfin, ce modle de scurit admet, quoi que de manire un peu implicite, la possibilit que le systme dvie de son fonctionnement normal. En effet, si les proprits dintgrit ne sont pas satisfaites un moment donn, lexistence de procdures de validation de lintgrit, ajoute au fait que les donnes non-contraintes sont acceptes par certaines procdures de transformations, offre des moyens de dtection dune infraction aux objectifs de scurit et de retour vers un tat satisfaisant. Lexistence dun historique de lexcution du systme permet alors didentifier les comportements errons qui ont pu tre lorigine dune violation des objectifs de scurit (par exemple, une faute dans limplmentation dune opration, non dtecte par la certification). Ce souci de fournir, outre des mcanismes garantissant la scurit du systme, des mcanismes capables de fonctionner en labsence de proprits de scurit attendues pour le systme, participe la volont de dfinir des politiques de scurit

44

Chapitre 2 Politiques et modles de scurit

applicables dans un environnement moins rigide que ceux dans lesquels des politiques de scurit comme les politiques multi-niveaux sont utilises.

2.3.3. Politique de la muraille de Chine

La politique dite de la Muraille de Chine [Brewer & Nash 1989] est une politique obligatoire pour maintenir la confidentialit des informations. Elle correspond une rglementation, impose aux agents de change britanniques, pour rsoudre les problmes de scurit lis aux conflits dintrt dans les institutions financires. Dans ce type dorganisations, un grand intrt est port au cloisonnement des diffrentes informations concernant des clients concurrents. En effet, si un organisme financier est amen traiter des oprations pour le compte de deux clients en concurrence directe, le personnel de cet organisme ne doit pouvoir accder quaux informations concernant lun de ces deux clients. Au dpart, lutilisateur a le libre choix, mais une fois que les informations dun client connues, tout accs aux informations concernant lautre doit tre interdit. Sa dcision dresse donc devant lui une barrire quil ne peut plus franchir, do le nom de muraille. La formalisation de cette politique ncessite lidentification de trois ensemble : C, lensemble des compagnies ; S , lensemble des sujets (analystes financiers) ; et O , lensemble des objets (fichiers). Le systme classe linformation en trois niveaux hirarchiques : - le niveau le plus bas contient les donnes de toutes les compagnies ; - le niveau intermdiaire, regroupe les objets qui concernent la mme compagnie ; - le niveau suprieur regroupe les donnes des compagnies en comptition. chaque objet, sont associs le nom de la compagnie laquelle il appartient ainsi que la classe de conflit dintrt qui contient ses donnes. Ce modle considre deux fonctions : - la fonction X, tel que X(oi) dsigne la classe de conflit dintrt de oi. Autrement dit, pour un objet donn, X fournit lensemble de toutes les compagnies en comptition autour de cet objet ; - la fonction Y, tel que Y(oj) dsigne lensemble des donnes de la compagnie de oj. Une information est aseptise si elle a t purge des dtails sensibles et elle nest pas sujette des restrictions daccs. Pour ce type dinformation, on a : X(o) = . Notons quun conflit dintrt peut surgir, non seulement cause des objets consults un moment donn, mais aussi en raison des accs antrieurs. Pour enregistrer lhistorique des actions, le modle utilise une matrice Nso dfinie par : N(s,o) = 1 si s a dj accd o ; N(s,o) = 0 sinon. Lobjectif de cette politique de scurit est de garantir quaucun utilisateur naccde simultanment des donnes appartenant des ensembles en conflit dintrt. Cet objectif est obtenu en imposant les deux rgles suivantes : (1) Proprit simple : laccs est accord un sujet seulement si lobjet demand appartient au mme ensemble de donnes de compagnie lintrieur de la muraille (comme un objet dj lu), ou une classe de conflit dintrt compltement diffrente. (2) Proprit toile : un sujet s est autoris crire dans un objet o, si laccs est autoris par la proprit simple ; et si s ne peut lire aucun objet o appartenant un ensemble de donnes de compagnies diffrent de celui de o, et contenant des donnes non aseptises. tudions cette deuxime proprit travers un exemple simple. Supposons que le systme gre une banque BanqueA ; deux compagnies en comptition CA et CB ; deux sujets (analystes) A1 et A2 et trois fichiers (pour simplifier, on les note Y(CA), Y(CB) et Y(BanqueA)). La proprit toile ninterdit pas le fait que A1 ait accs {Y(CA), Y(BanqueA)} et que A2 ait accs {Y(CB), Y(BanqueA)}. Mais si A 1 lit Y(C A) et lcrit dans Y(BanqueA), A 2 peut lire cette information

45

(puisquil a accs Y(BanqueA) alors que cette information (initialement concernant C A) est dans la mme classe de conflit dintrt de CB ( laquelle il a dj accd). La proprit seule, seule, ne permet pas dempcher de telles attaques, tandis que lattaque ne peut pas russir si le systme implmente la proprit toile.

2.4. Politiques de contrle de flux

Contrairement celles qui les ont prcdes, les politiques de contrles de flux proposent des solutions pour lidentification et llimination des canaux cachs. Un canal cach est un chemin de communication pouvant tre exploit par un processus de transfert dinformation de telle sorte quil contourne les mcanismes de contrle daccs, et quainsi il viole la politique de scurit. Par exemple, il est parfois possible de transmettre de linformation, non pas au travers dun tampon, mais grce au message derreur qui est retourn par le systme lorsque le tampon est plein. Le pige peut sappuyer sur la convention que libre = 1 et plein = 0 , et un cheval de Troie peut ainsi transmettre une suite de bits lutilisateur malveillant. Dans ce cas, on dit que cet change dinformations a utilis un canal cach. Dune manire gnrale, on distingue deux types de canaux cachs : les canaux de mmoire et les canaux temporels. Les canaux de mmoire sont constitus par des moyens de mmorisation partags entre des utilisateurs dhabilitations diffrentes. Si le systme obit une politique obligatoire, il interdit bien videmment lutilisation de moyens directs tels que la mmoire partage, lenvoi de messages, le partage de fichiers, la rutilisation de tampon ou de fichier temporaire, etc. Un canal cach de stockage est lutilisation (dtourne) dun mcanisme qui permet un processus dcrire une information qui peut tre lue par un autre processus. En fait, il est gnralement possible didentifier et de supprimer tous les canaux cachs de stockage. Lanalyse des canaux cachs de stockage (avec estimation de leur bande passante) est dailleurs exige ds le niveau B2 du Livre Orange [TCSEC 1985]. Les canaux temporels sont plus difficiles identifier et analyser. En fait, ds lors quune ressource matrielle (unit centrale, mmoire, rseau, disque, ) ou logicielle (verrou, smaphore, systme de fichiers, ) est partage entre des utilisateurs dhabilitation diffrente et quil existe une horloge commune suffisamment prcise, il est possible de crer un canal temporel en modulant lusage de la ressource. Un exemple classique est celui de disques partags : lutilisateur privilgi peut positionner le bras du disque sur le cylindre extrieur (pour transmettre un 1 ) ou sur le cylindre intrieur (pour transmettre un 0 ) ; lutilisateur non privilgi peut alors positionner le bras du mme disque sur le cylindre intrieur : selon le temps de rponse, il saura sil sagit dun 1 ou dun 0 . Certains canaux temporels, bass sur des ressources partages matrielles, peuvent atteindre des vitesses de transmission de plusieurs mgabits par seconde si aucune prcaution nest prise [Hu 1991]. Comme il nest en pratique pas possible de supprimer tous les canaux cachs (en particulier temporels), on sattachera en rduire la bande passante, en rduisant le plus possible le nombre de ressources partages, en affectant les ressources partages pendant des dures fixes, en faisant fluctuer les horloges, etc. Mais ces techniques de rduction de bande passante ont une influence ngative sur les performances du systme. Il faut donc chercher un compromis satisfaisant. Selon le Livre Orange, une bande passante de 100 bits par seconde est inacceptable pour des canaux cachs dun systme quon prtend sr. En revanche, une bande passante dun dixime de bit par seconde ou mme dun bit par seconde peut tre tolre si le canal correspondant peut tre surveill par le systme daudit Les politiques de contrle de flux grent le problme des canaux cachs en considrant, non seulement des oprations de lecture et dcriture sur des objets, mais galement des flux dinformations entre sujets. Elles sattachent donc spcifier les canaux de transmission prsents dans le systme, prciser les canaux lgitimes et identifier les canaux cachs.

46

Chapitre 2 Politiques et modles de scurit

Une approche originale pour la reprsentation des flux dinformation dans un systme consiste caractriser les dpendances causales qui existent, diffrents instants, entre les objets du systme [Bieber & Cppens 1991 ; dAusbourg 1994]. Dans ce modle, un systme est reprsent sous forme de points (o , t). Un point dsigne, non pas un objet, mais ltat dun objet o linstant t. Certains de ces points sont des entres, dautres des sorties, et tous les autres constituent des points internes au systme. Lensemble de ces points volue avec le temps et cette volution est due aux transitions lmentaires qui ont eu lieu dans le systme. Une transition lmentaire peut, un instant t, associer une nouvelle valeur un objet o en ce point. Cet instant et cette nouvelle valeur dpendent donc de certains autres points antrieurs. La dpendance causale de (o, t) vis--vis de (o, t), avec t<t est note (o, t)(o, t) . La fermeture transitive de la relation (note * ) au point (o , t ) dfinit le cne de causalit en ce point : cne(o,t) = { (o, t) tel que (o, t) * (o, t) }. Rciproquement, on dfinit le cne de dpendance dun point (o , t) comme un ensemble des points qui dpendent causalement de (o, t) : dep(o, t) = { (o, t) tel que (o, t) * (o, t) }. Les dpendances causales reprsentent la structure des flux dinformation dans le systme. Si un sujet s possde une certaine connaissance du comportement interne du systme, il est en mesure de connatre les dpendances causales. Dans ce cas, en observant une sortie particulire x0, un sujet s peut tre en mesure dinfrer toute information appartenant cne ( x 0) Rciproquement en altrant une entre xi du systme, s peut ventuellement altrer tous les points appartenant dep(xi). Les objectifs de scurit de ce modle peuvent tre relatifs la confidentialit ou lintgrit. Soit la notation suivante : - Obss, lensemble des points quun sujet s peut observer, Obss = cne ( x 0 ) ;
xoOs

Rs, lensemble des points que s a le droit dobserver ; Alts, lensemble des points quil peut modifier, Alt s = cne ( x i ) ; xi As - Ws, lensemble des points que s a le droit de modifier dans le systme; Le systme est considr sr vis--vis de la confidentialit si s ne peut observer que les objets quil a le droit dobserver, cest--dire si Obss Rs. De la mme manire, le systme est sr vis--vis de lintgrit si s ne peut agir que sur les objets quil a le droit de modifier, cest-dire, si Alts Ws. En considrant un ensemble de niveaux associs aux sujets et aux objets, la proprit Obss Rs relative la confidentialit peut tre obtenue en imposant deux rgles analogues celles dfinies dans la politique de Bell-LaPadula : - un sujet nest autoris observer que les objets dont la classification est domine par son habilitation ; - si un objet o dpend causalement dun objet o, alors la classification de o doit dominer la classification de o. Ce modle est particulirement intressant parce quil introduit une nouvelle manire de formaliser les flux dinformations dans un systme. Lintrt principal de cette formalisation rside dans son aspect minimal : la notion de dpendance causale permet de dcrire de manire strict un flux dinformations. Toutefois, les implmentations de ce modle qui ont t ralises semblent limites des applications assez spcifiques [Calas 1995].

2.5. Politiques de contrle dinterfaces

Les politiques de contrle dinterfaces spcifient des restrictions sur les entres et les sorties du systme qui permettent dobtenir des proprits de scurit. Ce type de politiques de

47

scurit sintresse plus directement au comportement dynamique du systme et sappuie sur des mthodes de modlisation trs gnrales. Elles considrent une reprsentation du systme incluant les diffrents sujets et lensemble des traces dexcutions associes ces sujets. Une trace est dfinie comme lhistorique des entres, cest--dire la suite ordonne de tous les tats successifs du systme entre chaque entre (ou commande) [Jacob 1988]. Certaines commandes particulires dterminent les sorties du systme effectues par un utilisateur, et on sintresse principalement aux proprits que le systme possde vis--vis de toutes ses sorties. La principale qualit de cette approche trs abstraite est davoir permis des avances significatives dans la comprhension des problmes de formalisation poss par la scurit. Un certain nombre de proprits importantes ont pu tre tudies et compares en se basant sur ces modlisations trs gnrales des systmes [McLean 1990 ; Bieber & Cuppens 1992 ; Zakinthinos & Lee 1994]. Les principales proprits identifies dans la littrature, et qui constituent les diffrents objectifs de scurit, sont relatives la notion de non-interfrence. La non-interfrence stipule quun groupe dutilisateurs utilisant un certain nombre de commandes ninterfre pas avec un autre groupe, si ce que fait le premier groupe na aucun effet sur ce que le deuxime groupe peut observer. Les premiers modles assurant la noninterfrence ont t tablis par Goguen et Meseguer [Goguen & Meseguer 1984]. Leur modle montre que la scurit est assure si les entres dun niveau N ninterfrent pas avec les sorties observables un niveau qui ne domine pas N . Autrement dit, les sorties dont le niveau ne domine pas N sont les mmes que lon considre les entres de niveau N ou non. Cette proprit sapplique aux systmes dterministes. McCullough [McCullough 1987] a propos de gnraliser ce modle pour prendre en compte le non-dterminisme. Les sorties ne sont plus considres comme fonction des entres, mais on identifie plusieurs sorties possibles pour des entres donnes. Lensemble de ces sorties est appel futur possible. La proprit de scurit est ainsi : les futurs possibles dun niveau qui ne domine pas N sont les mmes que lon considre les entres de niveau N ou non.

2.6. Politiques et modles de scurit par rles (RBAC)

Certes, les politiques de contrles de flux ou dinterfaces sont importantes dun point de vue comprhension et spcification de certains types de systmes. Nanmoins, leur mise en uvre est trs difficile et dailleurs, les implmentations qui en ont t faites demeurent limites. Par ailleurs, les politiques obligatoires, en particulier les politiques multi-niveaux, imposent des contraintes fortes sur les organisations. Les relations dordre partiel quelles utilisent sont mal adaptes la ralit des entreprises : peut-on dire quune information du service commercial est plus secrte ou plus critique que celle qui provient du bureau dtude ? Ce nest pas sur de tels critres quil convient de contrler les flux dinformation. Les politiques discrtionnaires sont elles aussi mal adaptes : elles sont trop laxistes, en gnral, et permettent difficilement de garantir des proprits de scurit. Dautre part, il faut constamment redfinir les rgles, chaque fois quun nouvel utilisateur ou un nouvel objet est introduit dans le systme. Les politiques discrtionnaires sont donc trs difficiles administrer. linverse, les politiques bases sur les rles (RBAC, pour Role-Based Access Control [Sandhu 2000 ; Solms & Merwe 1994 ; Lawrence 1993]) visent faciliter ladministration de la scurit. Un rle reprsente de faon abstraite une fonction identifie dans lorganisation (par exemple, chef de service, ingnieur dtude, etc.). chaque rle, on associe des permissions (ou privilges), ensemble de droits correspondant aux tches qui peuvent tre ralises par chaque rle. Enfin, et contrairement aux modles qui ont prcd RBAC (HRU, par exemple), les permissions ne sont plus associes dune faon directe aux sujets, mais travers des rles. Les deux relations de la figure 2.4 Dtient(Rle , Permission) et

48

Chapitre 2 Politiques et modles de scurit

Joue(Sujet, Rle) dfinissent prcisment les permissions accordes chaque sujet. Un rle peut avoir plusieurs permissions et une permission peut tre associe plusieurs rles. De mme quun sujet peut tre membre de plusieurs rles et inversement, un rle peut tre excut par plusieurs sujets. Ainsi, si le docteur Dupont est la fois chirurgien et directeur de lhpital, en tant que chirurgien, il aura le droit daccs aux dossiers mdicaux, alors quen tant que directeur, il pourra accder aux informations administratives.
Sujet
0..n

Joue

0..n

Rle

0..n

Dtient

0..n

Permission

Figure 2.4 : Attribution des permissions aux sujets travers des rles. Lune des manires de dfinir les rles au sein dune organisation consiste regrouper dans chaque rle les tches pouvant excuter les mmes oprations, ensuite il sagit didentifier les objets que ces tches utilisent, puis dfinir les droits daccs sur ces objets, cest--dire les couples (ensemble de droits, objets) et finalement, dassocier ces droits aux rles. Laffectation des sujets aux rles est une tche faire sparment, et probablement par dautres administrateurs. Des variantes de RBAC ont essay de le raffiner, notamment en incluant les concepts de session , de hirarchie de rles et de contraintes sur les rles [Sandhu 1996] [Sandhu et al. 1996] [Garvila & Barkley 1998] [Ahn & Sandhu 2000] [Ferraiolo et al. 2001]. Dans une mme session, un utilisateur a la possibilit de ne pas activer tous ses rles, mais uniquement le sousensemble de ses rles ncessaire la ralisation de la tche accomplir. La hirarchie de rles permet de mettre en place un mcanisme dhritage des permissions entre les rles et simplifie dautant ladministration de ce modle. Par exemple, comme les chirurgiens et les gyncologues sont ncessairement mdecins, on assignera des permissions au rle mdecin, et seulement des permissions supplmentaires au rle chirurgien, dune part et au rle gyncologue dautre part. Des contraintes (par exemple, do le rle peut-il tre activ, quand peut-il tre activ et quelles sont les donnes quun rle peut manipuler ?) ont t intgres dans des versions rcentes de RBAC. Un modle de contrle daccs reposant sur la notion de rle, est dfini dans [Sandhu 1996] de la manire suivante14 : - U , R , P , S , respectivement des ensembles dutilisateurs, de rles, de permissions et de sessions ; - PA R P, une relation associant une permission un rle ; UA U R, une relation associant un ou plusieurs rles un utilisateur ; RH R R, une hirarchie de rles partiellement ordonns ; r r signifie que r est un sous-rle de r ; User : S U , une fonction associant chaque session si un seul utilisateur User (s i), qui reste constante pour la dure de vie de la session ; Role : S 2 R , une fonction associant chaque session si un ensemble de rles Role(si), avec : Role(si ) { r ($r ' r ) et (User (si ), r ') UA} ; une collection de contraintes qui dtermine si certains lments du modle RBAC sont acceptables (seuls les lments acceptables sont intgrs dans le modle).

14 Une modlisation algbrique plus solide de RBAC enrichie par des notions comme les sessions, la hirarchie, les contraintes, lactivation des rles, etc. est donne dans [Ferraiolo et al. 2001].

49

Lanalyse des politiques bases sur les rles permet de conclure quelles sont relativement faciles administrer et suffisamment souples pour sadapter chaque organisation [Sandhu 1996 ; Ferraiolo et al. 2001]. En effet, la dfinition des rles peut reflter la structure de lorganisation. Les rles peuvent tre structurs de faon hirarchique, pour simplifier encore laffectation des permissions. Avec RBAC, il est facile dajouter un utilisateur : il suffit de lui assigner les rles quil doit jouer dans lorganisation. De mme, il est relativement facile de faire voluer les tches suite la cration ou la modification dun objet : il suffit de mettre jour les privilges des rles concerns. Le principal inconvnient de RBAC rside dans la difficult de grer et dimplmenter des rgles du type seuls les mdecins traitants peuvent lire les informations mdicales du dossier dun patient . Pour rsoudre ce problme avec RBAC, il faut soit crer autant de rles mdecin traitant du patient X que de patients, soit mettre en uvre des rgles supplmentaires dans lapplication (par exemple, gestion de la base de donnes des dossiers mdicaux), rgles qui ne sont pas exprimables dans le modle RBAC.

2.7. Politiques et modles de scurit par quipes (TMAC)

2.7.1. Dfinition de TMAC
Le modle TMAC (pour TeaM-based Access Control en anglais) a t formul pour la premire fois en 1997 par Thomas [Thomas 1997 ; Wang 1999]. Le but tait alors de fournir un contrle daccs pour les systmes ayant des activits de collaboration. cet gard, lentit de base, lquipe, est une abstraction qui encapsule un ensemble dutilisateurs, qui ont des rles diffrents et qui collaborent dans le but daccomplir une tche ou datteindre un objectif commun. Dune part, les utilisateurs appartenant une quipe donne devront avoir accs lensemble des ressources utilises par lquipe et dautre part, les permissions dun utilisateur devront tre drives des permissions accordes aux rles quil joue. Le concept TMAC distingue lattribution et lactivation des permissions. Les permissions attribues sont, par exemple, celles associes un utilisateur lorsquil choisit un rle au moment de la connexion ; les permissions actives sont celles qui dpendent des variables environnementales (lieu, temps, etc.), elles peuvent donc changer selon le contexte. Le pouvoir dintgrer les informations contextuelles, lors de la dcision daccs, permet au modle TMAC dtre flexible et dexprimer des politiques daccs pouvant fournir des permissions plus fines que celles de RBAC. Selon TMAC, le contexte de collaboration dune quipe donne doit tenir compte de deux types de contexte : - contexte utilisateur : les utilisateurs qui forment lquipe un moment donn ; - contexte objet : les instances dobjets que lquipe utilise pour accomplir sa tche. Dans TMAC [Thomas 1997], une quipe t est dfinie par : - TU, ses membres ; - TR , lensemble des rles que les membres de lquipe peuvent jouer (TR R), o R dsigne lensemble des rles prsents dans le systme dinformation ; - h TR, un rle particulier nomm responsable de lquipe ; OT, un ensemble dobjets associs lquipe ; TP, un ensemble de permissions associes lquipe (TP TR OT). UC, un contexte-utilisateur (UC TR TU) ; OC, un contexte-objet (OC OT O), o O dsigne lensemble des objets.

50

Chapitre 2 Politiques et modles de scurit

La figure 2.5 donne une description graphique des concepts de TMAC tels quils ont t dfinis dans [Thomas 1997].
Rles de lquipe
Permissions de lquipe

Types dobjets
ContexteObjet

ContexteUtilisateur

Contexte de collaboration

Membres de lquipe

Instances dobjets

Figure 2.5 : Illustration des concepts de TMAC. Le travail dcrit dans [Thomas 1997] reste une introduction innovante de la notion dquipe dans la formulation des politiques de scurit. En effet, dans TMAC , lappartenance dun utilisateur une quipe donne lui confre le droit daccder aux ressources associes cette quipe. Ainsi, les permissions dun utilisateur dpendent non seulement, du ou des rles quil joue un moment donn, mais aussi de lactivit courante de lquipe laquelle il appartient. Dans le domaine mdical, par exemple, un mdecin na le droit de prescrire des mdicaments que pour les patients quil traite (le simple fait dtre mdecin ne lui donne pas le droit de prescrire des mdicaments pour tous les patients). TMAC peut exprimer ce besoin dans la mesure o elle voit un mdecin comme un membre dune ou plusieurs quipes. Nanmoins, Thomas [Thomas 1997] na pas spcifi la faon selon laquelle les rgles de scurit seront reprsentes, ni comment les permissions seront drives.

2.7.2. C-TMAC : Context-TMAC

C-TMAC (pour Context-TeaM Based Access Control en anglais) [Georgiadis et al. 2001] est une amlioration de TMAC qui fournit, de manire explicite, les rgles dactivation des permissions selon le contexte. C-TMAC utilise un mlange de RBAC et TMAC, et consiste en cinq entits : utilisateurs, rles, permissions, quipes et contextes. Durant une session, les permissions dun utilisateur reprsentent lunion des permissions de tous les rles quil a activ. Par ailleurs, dans le contexte sont incluses des informations concernant lactivit de son quipe, ainsi que des informations contextuelles comme le temps. Trs proche de la spcification de RBAC, le modle C-TMAC dfinit les lments suivants : - U , R , P , S , T, C dsignent respectivement lensemble des utilisateurs, rles, permissions, sessions, quipes et contextes ; - PRS P R est une relation plusieurs plusieurs associant les permissions aux rles ; URS U R est une relation plusieurs plusieurs associant les utilisateurs aux rles ; CTS C T est une relation plusieurs plusieurs associant les contextes aux quipes ; UTS U T est une relation plusieurs plusieurs associant les utilisateurs aux quipes ; Session-User : SU, une fonction associant chaque session si un utilisateur User(si) ; Session-Role : S 2 R, une fonction associant chaque session si un ensemble de rles Roles(si), avec : Rles(si) {r | (User(si), r) URS} ; Session-Team : S2T, une fonction associant chaque session si un ensemble dquipes Team(si) avec : Team(si) {t | (User(si), t) UTS} ;

51

Team-User : T2 , une fonction associant chaque quipe ti un ensemble dutilisateurs User(ti), avec : User(ti) {u | (u, ti) UTS} $sj : user(sj)=u} ;

Team-Role : T2R, une fonction associant chaque quipe ti un ensemble de rles Role(t i ) { r | (user (t i ), r ) URS} ; les permissions de lquipe ti sont notes permissionrle-quipe . Elles sont dduites partir de la formule r roles(ti) = {p | (p,r) PRS} . Celle-ci dsigne la combinaison (reprsente dans la formule par loprateur ) des permissions de tous les rles des utilisateurs appartenant lquipe. Lensemble permission-rle-quipe dpend de la notion de combinaison. Selon C-TMAC, une combinaison correspond lun des trois cas suivants : - si la combinaison est une agrgation, permission-rle-quipe est lunion des permissions des rles des utilisateurs appartenant lquipe ; - si la combinaison est un maximum (resp. minimum) : permission-rle-quipe est gal lensemble maximal (resp. minimal) des permissions des membres de lquipe ; - dans dautres cas non spcifis dans [Georgiadis et al. 2001], la combinaison peut dpendre de la structure courante de lquipe. Selon C-TMAC, la drivation des permissions (et donc laccs aux ressources) suit la procdure suivante : Aprs son identification et son authentification, lutilisateur slectionne un sous-ensemble de rles et dquipes auxquels il a droit. Lensemble des permissions de lutilisateur (permissionrle-session ) est combin avec lensemble des permissions de lquipe (permission-rlequipe) comme indiqu dans les deux tapes ci-dessous : tape 1 : considrons un utilisateur ayant activ un sous-ensemble de rles et participant un sous-ensemble dquipes. Initialement, les permissions de ses rles sont drives partir des formules suivantes : permission-rle = permission-rle-session permission-rle-quipe tape 2 : les permissions finales sont drives partir du contexte de lquipe et des permissions des rles. C-TMAC utilise ainsi loprateur de filtrage pour restreindre les permissions acquises travers les rles jous : permission-contexte = permission-rle contexte-quipe Afin de rendre le contrle daccs dynamique, cette deuxime rgle dduit lensemble final des permissions dun utilisateur, en utilisant le contexte courant de son quipe comme filtre. Cette manire de faire permet dextraire des sous-ensembles de permission-rle en sappuyant sur les valeurs des variables contextuelles de lquipe : le lieu, le temps, le patient trait, etc. tudions le fonctionnement de C-TMAC dans un contexte mdical, environnement o plusieurs quipes peuvent tre impliques dans des processus dynamiques composs de plusieurs tches. Soit lexemple dun patient trait dans le service de mdecine gnrale. Suite une attaque cardiaque, il est transfr durgence lunit de soins cardiologiques. La tche de lquipe de cardiologie (traiter les patients cardiaques) est excute durant un intervalle de temps donn et dans un endroit spcifique (lunit de cardiologie). Les variables contextuelles sont ainsi, le temps, le lieu et le patient. La procdure est dcrite dans la figure ci-dessous.

52
Identification + authentification

Chapitre 2 Politiques et modles de scurit

Activation des rles Permission-rle-session Select

Champ1, Champ2, Champ3

Participations des quipes Permission-rle-quipe Select

Champ1, Champ3, Champ4

Contexte de lquipe

Patients :
(200, 351)

From Patient

From Patient Combinaison = Agrgation Permission-rles Select

Champ1, Champ2, Champ3, Champ4

Temps : [10h-12h] Lieu : (UR1, UR3)

Filtrage

Permission-Contexte Select
Champ1, Champ2, Champ3, Champ4

From Patient

From Patient Where PatientID IN (200, 351) And Temps IN ([10h ; 12h)] And Lieu IN (UR 1, UR 3)

Figure 2.6 : Activation des permissions selon C-TMAC. Dans cet exemple, on suppose que : la base de donnes contient la table Patient (patientID, Champ1, Champ2, Champ3, Champ4) ; - les paramtres du contexte, PatientID, temps et lieu ; - les permissions associes aux rles mdecin, cadre-infirmire et infirmire sont : Permissions(mdecin) : SELECT Champ1, Champ2, Champ3 FROM Patient, Privilges(cadre-infirmire) : SELECT Champ1, Champ3, Champ4 FROM Patient, Privilges(infirmire) : SELECT Champ1, Champ4 FROM Patient. Dans lexemple, on suppose quil existe des quipes assurant le service des urgences : Eq-Ur localises dans la salle (UR 1) ou dans la salle (UR 3), ainsi quune quipe de soins primaires (GN2). Le contexte associ Eq-Ur est : PatientID IN : (200, 351) AND temps IN [10h-12h] AND lieu IN (UR1, UR3). Supposons maintenant que Mary et Helen ont commenc leur session s1 et s 2 et quelles activent leurs rles cadre-infirmire et infirmire respectivement au sein de Eq-Ur. On obtient alors, Team-User(Eq-Ur) = [Mary, Helen] Team-Role(Eq-Ur) = [cadre-infirmire, infirmire]. Les permissions de Eq-Ur sont dduites partir de lunion des permissions des rles des utilisateurs qui y participent, cest--dire : Permission-rle-quipe(Eq-Ur) = SELECT Champ1, Champ3, Champ4 FROM Patient. Supposons par ailleurs, que Chris commence une session s3 et quil active le rle mdecin au sein de lquipe Eq-Ur. On a donc : Team-User(Eq-Ur) = [Chris, Mary, Helen] ; Team-Role(Eq-Ur) = [mdecin, cadre-infirmire, infirmire], et

53

Permission-Rle(Chris)=Permission-rle-session(mdecin)Permission-rles-quipe(Eq-Ur) = {SELECT Champ1, Champ2, Champ3 FROM patient } {SELECT Champ1, Champ3, Champ4 FROM patient}. En appliquant la rgle de filtrage, les permissions finales sont : Permission-Contexte(Chris) = Permission-rle(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 trs simple, on peut constater que C-TMAC prsente certaines faiblesses. En effet, si la combinaison est une agrgation, un utilisateur qui rejoint une quipe renforce les permissions de cette quipe en lui ajoutant les siennes : (Permissions-quipe-aprs affectation = Permissions-quipe-avant affectation Permissions(nouvel utilisateur)). Ainsi, tous les membres de lquipe auront les mmes permissions. Nanmoins, dans le secteur mdical, mme si les professionnels de sant appartiennent la mme quipe du mme hpital, ils nont pas les mmes droits daccs aux mmes parties des fichiers. Il est vident que les permissions finales du mdecin doivent tre diffrentes de celles de linfirmire, mme si tous les deux appartiennent la mme quipe de soins. Or, si on reprend lexemple de la figure 2.6, en considrant, cette fois-ci, que le mdecin se connecte avant linfirmire, on constatera quen rejoignant lquipe, linfirmire a les mmes permissions que le mdecin. Le cas o la combinaison est le maximum ou le minimum est, lui aussi, non raliste car la dduction des permissions (application des deux rgles cites prcdemment) se fait de la mme manire pour tous les membres dune quipe donne. On aura donc le mme ensemble de privilges 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 spcifie pas explicitement comment driver les permissions dans le cas o la combinaison dpendrait de la structure de lquipe.

2.8. Application de ces approches aux SICSS

2.8.1. Discussion des politiques et modles existants
Ltat de lart actuel des politiques et modles de scurit semble insuffisant pour rsoudre les spcificits du contrle daccs dans les SICSS. En effet, le contrle daccs discrtionnaire prsente de graves inconvnients concernant notamment des fuites dinformation, au contraire, les politiques obligatoires sont trs rigides et trs spcifiques aux domaines pour lesquels elles ont t dveloppes. De plus, elles sont trop centralises et mal adaptes une analyse et une prise de dcision en rseau ou au travers de systmes rellement rpartis. Par ailleurs, ces politiques ne permettent pas de prendre facilement en compte la fois les exigences de confidentialit, dintgrit, et a fortiori de disponibilit, exigences incontournables des SICSS. En outre, la nature distribue et inter-organisationnelle, la diversit des flux et la varit des objets et des sujets des SICSS augmentent la complexit de ces systmes. Les politiques de contrle dinterface ainsi que les politiques de contrle de flux sont, par consquent, difficiles implmenter dans le contexte des SICSS. linverse, le concept de rle fournit une classification des sujets et offre ainsi un dbut de rflexion prometteur. En effet, ltude de la fonction de scurit ne peut tre implmente et mise en uvre efficacement que si toutes les entits de notre spcification (et non seulement les sujets) sont structures convenablement. Le modle RBAC, seul, semble insuffisant pour supporter toute la richesse des SICSS. Tout dabord, le concept de permission est primitif. En effet, dans le modle RBAC, rien nest prcis sur lusage ou la structure des permissions, considrant quelles dpendent de lapplication concrte du modle. Il serait prfrable dajouter au modle une structure

54

Chapitre 2 Politiques et modles de scurit

gnrique de permission. Le concept de hirarchie de rles est quelque peu ambigu. Il est en gnral incorrect de considrer que la hirarchie de rles correspond la hirarchie organisationnelle. Par exemple, le directeur dun hpital a un rle administratif suprieur au rle de mdecin. Pour autant, un directeur dhpital nest pas ncessairement un mdecin. Ainsi, il serait incorrect de considrer que le directeur de lhpital hrite des permissions du rle de mdecin, comme celle de prescrire par exemple. De plus, il nest pas possible dans le modle RBAC dexprimer des permissions qui dpendent du contexte. Rappelons que si une certaine permission est accorde un rle, alors tous les utilisateurs qui jouent ce rle hritent de cette permission. Par consquent, il nexiste aucun moyen simple pour spcifier quun mdecin na la permission daccder au dossier mdical dun patient que si ce dernier est son patient [Cheng 1999] [Barkley et al. 1999]. Enfin, C-TMAC prsente certaines limites notamment dans la manire de driver les permissions. Par ailleurs, dans la quasi-totalit des politiques et modles tudis dans ce chapitre, il nest possible de dfinir 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 modles mieux adapts aux SICSS. Le quatrime chapitre clarifie les points voqus dans cette section et prsente le modle Or-BAC, lalternative que nous proposons pour spcifier les politiques des SICSS, mais aussi des domaines complexes, interoprables, htrognes et fortement distribus [Abou El Kalam et al. 2003].

2.8.2. Politiques de scurit pour les SICSS

Les caractristiques des SICSS prcdemment dfinies font apparatre un rel besoin dtude de la scurit de tels systmes. travers plusieurs projets, des associations mdicales, des organismes de standardisation ainsi que des quipes de recherche ont montr lintrt des politiques de scurit pour les SICSS. Ils ont men des investigations et ont propos des politiques et mcanismes de scurit pour les systmes dinformation mdicales. Nanmoins, les politiques dveloppes sont trs gnrales, trs disparates et nont gnralement pas abouti un cadre finalis, pratique, transportable (transfrable) et couvrant toute la richesse des SICSS. Un premier pas a t franchi par llaboration de la directive europenne 95/46/EC [Directive 1995] concernant la protection des donnes personnelles et la libre circulation de ces donnes. Or, cette directive ne fournit quun cadre (lgal) harmonisant les lgislations des pays de la communaut europenne. Combler le foss qui existe entre la politique gnrale dcrite par la lgislation et les politiques concrtes, modlisables et applicables dans les organisations reste un grand dfi relever. Intressons-nous quelques travaux rcents relatifs aux politiques de scurit pour le domaine mdical.

2.8.2.1 Politique de scurit de SEISMED

SEISMED ( Secure Environment for Information Systems in MEDicine) est un projet europen sinscrivant dans le programme AIM (Advanced Informatics in Medicine). Il sest intress au dveloppement de directives visant lamlioration de la scurit dans les systmes dinformation hospitaliers europens. Le consortium SEISMED a publi une politique de scurit gnrique qui repose sur neuf principes [Katsikas 1996]. Chaque principe est dtaill par un ensemble de directives. Pour donner une ide de la forme de ces principes et directives, dtaillons le premier : un code de bonne conduite concernant la protection des donnes des patients doit tre adopt par chaque tablissement de sant . Ce principe est dcrit par deux directives. La premire prcise que chaque tablissement de sant doit publier ce code et exposer les grandes lignes des rglementations concernant la manipulation des donnes

55

personnelles. Le code doit tre compatible avec le code de dontologie europen, doit convenir aux caractristiques de chaque tablissement comme il doit rduire les divergences entre la thorie et la pratique . La deuxime directive prcise que le code doit reconnatre les droits individuels, doit tre conforme aux conventions internationales des droits de lhomme et la lgislation nationale au mme titre quil doit respecter les directives europennes . Notre tude de la politique de scurit de SEISMED nous a permis de constater que SEISMED manque dun cadre conceptuel clair et structur. De plus, cette tude devrait tre complte par un ensemble de mesures spcifiques chaque environnement.

2.8.2.2 Politique de scurit de la BMA

LA BMA (British Medical Association) a publi en 1996 un livre intitul La scurit dans les systmes dinformations cliniques [BMA 1996]. Ce document expose une politique de scurit qui doit tre suivie par tous les membres de lassociation. Elle fait rfrence aux dclarations parues dans la brochure Good Medical Practice du UK General Medical Council. Sadressant aux personnels soignants, cette brochure prcise que les patients ont le droit dexiger que vous ne transmettiez aucune information que vous dduisez dans le cadre de votre profession, sauf sils expriment leur consentement . Le document publi par le BMA [BMA 1996] tablit un certain nombre de rgles assurant le principe de consentement du malade. Une version plus technique a t publie dans [Anderson 1996a, Anderson 1996b]. Suite aux divergences entre le National Health Service et le British Medical Association, une confrence a t organise en juin 1996 Cambridge et a permis de confirmer neuf principes. P1 : contrle daccs. Chaque dossier mdical devrait tre marqu avec une liste de contrle daccs dsignant les personnes ou groupes de personnes qui peuvent y accder. P2 : ouverture dun dossier mdical. Un mdecin peut ouvrir un dossier avec son nom et celui du patient dans la liste de contrle daccs. Lorsquun patient a t transfr, il peut ajouter cette liste le (ou les) mdecin(s) en charge du patient. P3 : contrle. Lun des mdecins de la liste de contrle daccs doit tre dsign comme responsable, lui seul peut modifier la liste de contrle daccs en y ajoutant des personnels soignants, et uniquement des personnels soignants. P4 : consentement et notification. Le mdecin responsable doit informer le patient des noms figurant sur la liste de contrle daccs de son dossier. Il est galement tenu de linformer de toute modification ou transfert de responsabilit. Le consentement explicite du malade doit tre obtenu, sauf dans les cas durgence et dans les cas dexemption imposs par la loi. P5 : persistance. Personne ne doit pouvoir effacer un dossier mdical avant sa date dexpiration. P6 audit. Tous les accs aux dossiers mdicaux doivent tre consigns avec le nom du sujet, la date et lheure. Une trace de toutes les modifications doit galement tre conserve. P7 : flux dinformations. Une information issue dun dossier A peut tre ajoute un dossier B si et seulement si la liste de contrle daccs de B contient celle de A. P8 : contrle de lagrgation . Des mesures efficaces empchant lagrgation des informations personnelles de sant doivent tre mises en place. P9 : sous-systme de scurit ou base de confiance ( TCB). Les systmes informatiques qui hbergent les informations mdicales doivent avoir un sous-systme de scurit qui applique ces principes dune manire efficace. Certes, la politique de la BMA a mis en avant des points importants de la scurit des systmes mdicaux. Nanmoins, elle est loin dtre complte, dfinissant les objectifs et les rgles de scurit, et couvrant toutes les spcificits des SICSS.

56

Chapitre 2 Politiques et modles de scurit

2.8.2.3 Politique de scurit de la SMA

La SMA (Swedish Medical Association) a publi dans la brochure Information Technology: The Physician and The Patient [SMA 1995] des principes thiques ainsi quun ensemble gnrique de rgles traitant du problme des accs aux fichiers des patients. Parmi ces principes, on retiendra : - le principe dautodtermination : le patient a le droit de dcider pour lui-mme ; - le principe de non-dommage : toute action causant des dommages doit tre empche ; - le principe dintrt : toute action prise doit apporter un gain supplmentaire ; - le principe de solidarit : les ressources ne doivent tre utilises que si le besoin le justifie ; - le principe defficacit : les ressources doivent tre utilises de faon optimale et efficace. Les principes de la SMA devraient sappliquer aux accs aux dossiers mdicaux, la scurit du rseau et des transmissions des donnes des patients, la gestion de lorganisation et lamlioration de la qualit, etc. Nanmoins, mme si le document de la SMA soulve des problmes thiques assez importants, la notion de politique de scurit napparat pas de manire claire et explicite. Aucune rgle du contrle daccs ni mesure prendre pour la protection de donnes mdicales nest annonce. Tout ce que la SMA fournit, cest sa position, sous forme de dclarations concernant les problmes et dfis de scurit dans ce domaine.

2.8.2.4 Recommandations de la FMAG

Lassociation mdicale allemande (Bundesrztekammer) a publi des recommandations de scurit intitules recommandations concernant les obligations de confidentialit mdicale, protection et traitement des donnes dans le contexte des pratiques mdicales [FMAG 1996]. Ce document fournit des conseils aux professionnels de sant, leur montre comment implmenter les lois concernant la protection des donnes prives en Allemagne et dfinit les obligations vis--vis du maintien et du traitement des donnes mdicales. La politique de scurit propose repose sur un ensemble de principes destins aux praticiens, et qui touchent au droit et lintimit des patients, la confidentialit des donnes mdicales, lenregistrement et la documentation des traitements et des rsultats, au droit du patient tre inform des rsultats et des tests, etc. Ces recommandations ne doivent pas tre considres comme une politique de scurit part entire. Leur but est de spcifier les obligations ainsi que les responsabilits des professionnels de sant en respectant lutilisation des technologies de linformation.

2.8.2.5 Conclusion et prsentation du projet MP6

Outre les travaux noncs ci-dessus, plusieurs projets europens (ISHTAR, TrustHealth, DIABCARD, MedSec, Harp, EUROMED-ETS, HANSA, PRIDEH et DRIVE) se sont penchs sur les problmes de scurit des SICSS. Certaines tudes ont port en particulier sur les cartes puces, les mcanismes biomtriques et les infrastructures de gestion de cls. En matire de politiques et modles de scurit, lanalyse prsente montre que les rsultats ne sont pas encore compltement satisfaisants. Des mcanismes classiques (authentification [Blobel & Pharow 2001], autorisation, contrle daccs, chiffrement) existent tant au niveau des rseaux pour fournir la scurit ncessaire des communications, quau niveau des systmes informatiques pour apporter la scurit des systmes manipulant des informations sensibles. Pour mettre en uvre efficacement ces mcanismes, il est indispensable de dfinir prcisment

57

les besoins ainsi que les rgles de scurit appliquer, ceci implique la dfinition et la spcification dune politique de scurit approprie aux SICSS. Le travail jusque l effectu sattache prendre en compte les concepts sectoriels particuliers, tels que lauditabilit juridico-technique [Trouessin, 2002] issue des responsabilits juridiques spcifiques (lgales, thiques, dontologiques) pour les politiques de scurit respecter ainsi que des modles de scurit adapts et adaptables aux SICSS. Notre objectif est damliorer la pertinence et lefficacit des systmes des secteurs cibls ainsi que la confiance accorder de tels systmes. Plusieurs problmatiques de recherche seront tudies, telles les politiques de scurit et modles de politiques de scurit, politiques dautorisation et danonymisation, et ce dans les rouages des deux secteurs : mdical et social. Nos travaux sont partiellement soutenus par le Rseau National de Recherche en Tlcommunication, dans le cadre du projet MP6 (Modles et Politiques de Scurit pour les Systmes dInformation et de Communication en Sant et Social) dont les partenaires sont : Ernst & Young Audit (coordinateur), ENST-Bretagne, ETIAM, France Telecom R&D, LAASCNRS, MasterSecuritY, ONERA-DTIM, Suplec-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 scurit pour les SICSS ; - SP3 : Politiques de scurit pour les SICSS ; - SP4 : Modlisations formelles de politiques de scurit des SICSS ; - SP5 : Explorations-A politiques dautorisation et gestion des droits ; - SP6 : Explorations-B politiques danonymisation et gestion des pseudonymes ; - SP7 : Explorations-C dtection de risques dintrusions, dviances et infrences ; - SP8 : Intgrations sectorielles pour la scurit des SICSS ; - SP9 : Normes et standards, promotion et valorisation. Nous contribuons aux sous projets 2, 3, 4, 5, 6, 7 et 9.

Chapitre 3. Btir une politique de scurit pour les SICSS

Prambule
Lensemble des concepts, de la sret de fonctionnement en gnral et de la scurit en particulier, ncessaires la comprhension de ce mmoire ont t dfinis. Un tat des lieux des types et des complexits des modles et politiques de scurit qui existent, notamment ceux mis en uvre rellement dans les SICSS a t prsent. On a donc constat que ces politiques de scurit ne couvrent pas toute la richesse des SICSS. Il convient ainsi de dvelopper dautres politiques plus adaptes. Il semble vident que la conception et la ralisation de systmes srs ncessite, tout dabord, le dveloppement de mthodes pour dfinir prcisment des politiques de scurit. Ce chapitre commence ainsi par proposer une mthodologie de travail dont les principales tapes sont les suivantes : description du systme, identification des informations protger et la caractrisation des menaces, et dfinition de la politique de scurit en exprimant les besoins de scurit ainsi que les rgles qui dterminent comment linformation sensible et les autres ressources sont gres, protges, et distribues dans le systme. Il sagit galement dappliquer cette dmarche pour driver une politique de scurit pour un exemple de systme dinformation mdicale, et une autre pour un exemple du domaine social. Une troisime tude de cas consiste dfinir la base terminologique ncessaire ltude du problme de lanonymisation des donnes mdicales, o il est question des diffrents travaux existant, dune tude des solutions implmentes dans les pays europens, et dun ensemble de scnarios servant un objectif global de respect de la vie prive. Une dmarche progressive danalyse des besoins danonymisation est propose. Celle-ci commence par poser des questions pertinentes afin de dfinir les attentes, passe par lidentification des risques encourus, des objectifs et des exigences danonymisation, et aboutit des solutions-types adaptes aux besoins. Par la suite, il sagira dune procdure danonymisation en cascade diffrents niveaux (hpitaux, centres de traitements et utilisateurs finaux) et de montrer comment cette procdure innovante permet de dgager plusieurs avantages, notamment : la rsistance aux attaques par dictionnaire, les anonymisations sectorielles, la possibilit de fusions flexibles et scurises des donnes de plusieurs tablissements, etc. Pour son efficacit, lanonymisation pose des problmes particuliers (pour les SICSS) qui mritent dtre tudis sparment. Nanmoins, une fois anonymises, les donnes sont considres comme objets sensibles auxquels sapplique la politique de scurit. Ainsi ce chapitre a une double vocation, - dordre sectoriel, puisque la mthodologie de construction de notre politique de scurit est illustre par des exemples issus des secteurs sant et social ; - dordre plus gnral, car notre dmarche et nos solutions ne sont pas restreintes aux seuls secteurs de la sant et du social, mais peuvent tre appliques diffrents types de systmes.

60

Chapitre 3 Btir une politique de scurit pour les SICSS

3.1. Mthodologie de notre approche

Lobjectif de la scurit des systmes dinformation et de communication est de garantir quaucun prjudice ne puisse violer les objectifs de scurit. Il sagit alors de diminuer la probabilit de voir les menaces se concrtiser, en limiter les consquences ventuelles, et en cas de problme, revenir un fonctionnement normal des cots et dans des dlais acceptables. Dans la construction de nos politiques de scurit, la dmarche que nous allons suivre consiste rpondre un certain nombre de questions : quel systme veut-on scuriser et quelles lois et rglementations rgissent ces systmes ? Que veut-on protger ? Quelles sont les vulnrabilits de ce systme ? Quelles menaces doit-on affronter ? Quels risques encourt-on ? Quels sont les besoins de scurit ? Quelles sont les rgles de scurit qui permettent de satisfaire ces besoins, de faire face aux menaces, et dassurer la protection du systme ?

3.1.1. Description dun scnario reprsentatif

Certaines politiques de scurit prsentes prcdemment, comme les politiques de contrle dinterface (voir 2.6), font le choix de dfinir les proprits de scurit attendues indpendamment de la description du systme lui-mme. Cette manire de faire considre que la description du fonctionnement interne du systme nest pas ncessaire. Nanmoins, la mise en uvre dune politique de ce type conduit gnralement imposer des contraintes fortes sur le fonctionnement de lorganisation, ce qui soulve des difficults, notamment au niveau du rendement ou de la qualit de service. linverse, notre construction de la politique de scurit des SICSS intgre une description partielle du systme considr. En effet, il semble que, compte tenu de la complexit des organisations, de la diversit des flux ainsi que des spcificits et des rglementations socio-sanitaires des SICSS, il est ncessaire dtablir un scnario reprsentatif et de prciser les lois en vigueur, avant didentifier clairement les informations protger, les menaces, les objectifs de scurit, ainsi que les rgles de scurit. Le scnario dcrit ne sera pertinent vis--vis de la scurit que sil permet dexprimer : - les lments de base de la politique de scurit, notamment la classification des utilisateurs (rles, groupes), les types daccs possibles, les ressources, etc. ; - les rgles de description du fonctionnement du systme, afin de pouvoir en dterminer limpact sur les objectifs de scurit ; ll sagit de spcifier les flux dinformations, les processus, la hirarchie de rles ainsi que les contraintes organisationnelles, etc.

3.1.2. Identification des informations protger

La deuxime tape consiste identifier, de manire claire et non ambigu, les informations et les autres ressources sensibles, leur niveau de criticit en fonction de menaces particulires, ainsi que le risque de perte totale ou partielle de ces ressources. Les types dinformations protger sont caractriss en fonction de leur contenu informationnel, cest--dire de leur smantique. On sintresse en particulier aux liens logiques susceptibles dexister entre informations, de manire anticiper des problmes dinfrence de donnes sensibles partir de donnes non-protges. Ensuite nous tudions contre qui ou contre quoi ces informations doivent tre protges ? Cest--dire identifier les menaces auxquelles sont potentiellement soumis de tels systmes dinformation. Il y aura lieu de tenir compte des diffrents modes de fonctionnement (aspects organisationnels) et des diverses rglementations en vigueur dans les domaines de la sant ou du social, ainsi que dans les domaines adjacents concerns par de tels systmes dinformation.

61

3.1.3. Expression des objectifs de scurit

Il sagit de dcrire les objectifs de scurit, pour faire face aux risques identifis prcdemment et satisfaire ainsi les exigences de scurit. Ces objectifs sexprimeront notamment en terme de proprits de scurit (confidentialit, intgrit et disponibilit), attendues pour ce systme. Ces objectifs seront dfinis au niveau du systme dinformation, en tenant compte des caractristiques multiples de son environnement. Les objectifs de scurit doivent dterminer prcisment ce qui est permis, interdit, obligatoire et recommand dans le systme. Ceci peut conduire dfinir quune certaine catgorie dinformation doit tre inaccessible pour une certaine catgorie dutilisateurs : par exemple, interdire au pharmacien de crer des ordonnances, interdire aux professionnels de sant de transmettre des dossiers mdicaux vers des pays qui ne disposent pas dune lgislation de protection des donnes [Directive 1995], autoriser les agents des services payeurs accder aux donnes financires, etc. Un tat du systme qui satisfait lensemble des objectifs de scurit est videmment un tat sr, autrement dit, considr comme acceptable du point de vue de la scurit.

3.1.4. Dfinition des rgles de scurit

Afin de complter la spcification de la politique de scurit, il est important dexprimer un ensemble de rgles visant dfinir comment le systme peut voluer sans compromettre les objectifs de scurit identifis. Lexpression de ces rgles doit prendre en compte les diffrentes structures organisationnelles dans lesquelles sont dploys les systmes dinformation, ainsi que les contextes dutilisation de nature propre au domaine de la sant (comme la notion durgence) ou du social (comme lauthenticit dune tldclaration sociale). Imaginons une rgle de scurit : en cas durgence, tout professionnel soignant a le droit daccder aux donnes mdicales dun patient, mais en parallle, le systme doit enregistrer les paramtres de laccs dans le fichier daudit. Les tches dcrites jusquici, devront aboutir une spcification explicite : - dun ensemble de rgles de fonctionnement des SICSS ; - dune liste dinformations et services protger et des menaces qui psent sur ces informations ou services ; - dobjectifs de scurit exprimant les besoins de confidentialit, dintgrit et de disponibilit, telles quils sont considrs dans le contexte du systme tudi ; - dun ensemble de rgles de scurit exprimant qui a accs quoi et dans quelles conditions.

3.1.5. Modlisation formelle

Aprs sa spcification, la politique de scurit doit tre formellement dcrite notamment pour pouvoir : - lever les ambiguts sur la spcification ; - interroger la politique de scurit ; - manipuler la politique de scurit par des transformations mathmatiques et avec lassistance doutils de preuve afin den vrifier la cohrence et la compltude ; - tudier les problmes dinteroprabilit entre plusieurs politiques ; - avoir la preuve que la spcification assure les proprits de scurit ; - vrifier que limplmentation du systme dinformation, et en particulier des mcanismes de contrle daccs, permet bien de garantir les proprits de scurit souhaites.

62

Chapitre 3 Btir une politique de scurit pour les SICSS

3.2. De la description des SICSS aux besoins de scurit satisfaire

Dans cette section, il sagit dappliquer aux SICSS les trois premire tches prcdemment dcrites15 afin de fournir une asise solide la dfinition des politiques de scurit adaptes aux SICSS.

3.2.1. tude de cas 1 : Sphre mdicale 3.2.1.1 Scnario 3.2.1.1.1 Description et rgles de fonctionnement
Un systme dinformation mdicale peut tre dfini comme un systme ddi la sant. Il possde des moyens fiables assurant la communication, le traitement, le stockage ainsi que larchivage des informations mdicales, paramdicales, mdico-administratives et mdicofinancires. Un tel systme relie un grand nombre dutilisateurs ayant des responsabilits et des centres dintrts diffrents. Les flux dinformations entre ces diffrentes catgories dutilisateurs peuvent se rsumer comme suit : - Entre professionnels de sant et rgime dassurance maladie : envoi des lots de feuilles de soins lectroniques et change des accuss de rception logiques. - Entre professionnels de sant : mdecins, hpitaux, pharmacies et laboratoires peuvent schanger des informations mdicales afin de favoriser laide au diagnostic et la recherche pidmiologique. - Entre professionnels de sant et dautres rseaux : les services dtude et de recherche pidmiologique envoient aux mdecins des statistiques dactivit et leur fournissent une aide la prescription. - Accs simplifi au rseau Internet, afin de bnficier des services offerts par les sites Web mdicaux et de disposer des meilleures informations sur la sant. - Accs aux informations des ministres et aux informations juridiques et fiscales concernant les professionnels de sant. Par ailleurs, il est possible de spcifier dautres rgles de fonctionnement, notamment : - La hirarchie des rles, par exemple : tout mdecin (ou infirmire ou aide soignante) est aussi considr comme personnel soignant ; un utilisateur est considr comme professionnel de sant seulement sil est personnel soignant ou personnel paramdical, ou personnel administratif ou htelier dans un centre de soin (cabinet mdical, hpital, clinique), autrement dit, titulaire dune Carte de Professionnel de Sant (CPS) ; les personnes travaillant dans une pharmacie ou dans un laboratoire font partie du personnel paramdical. - Lactivation des rles, par exemple : tout utilisateur qui se connecte avec sa carte de professionnel de sant joue le rle dans lorganisation mentionne sur cette carte. - Le contexte des rles, par exemple un utilisateur ne peut pas tre la fois comptable et mdecin dans le mme hpital.

Les trois tapes qui seront effectues dans cette section sont : description dun scnario reprsentatif, identification des informations protger, et expression des objectifs de scurit. Pour viter toute redendonce, la quatrime tape dfinition des rgles de scurit sera partiellement dcrite ici, et sera complte dans les autres chapitres. La cinqime tape modlisation formelle sera prsente dans le chapitre suivant.

15

63

3.2.1.1.2 Entits de base

Afin de simplifier et afin dviter toute redondance inutile, il ne parat pas ncessaire de dcrire toutes les entits de base des systmes dinformation mdicale. Celles-ci seront dcrites plus en dtail lors de la dfinition du modle dans le chapitre suivant et dans la reprsentation de la politique de scurit dans ce modle. Le systme de sant peut tre vu comme un ensemble dorganisations qui interagissent : hpitaux, instituts de recherche, organismes payeurs, etc. (figure 3.1). Lhpital est une structure associant plusieurs types dunits : units de soins, pharmacie, services administratifs, mdico-techniques et logistiques ([Degoulet 1992 - Ch 11][Degoulet 1989]). En loccurrence, lunit de soins, principal site daccueil des patients, est dfinie comme tant une entit physique dont la fonction est de produire des soins mdicaux (diagnostic, thrapie, valuation). Il peut sagir dun service, dun regroupement de services dans le cadre dun dpartement ou au contraire dune unit fonctionnelle lintrieur dun service. Une unit de soins suppose la prsence dune quipe soignante place sous une responsabilit bien dtermine et prenant en charge des patients.
Rseau de sant
Domaine Clinique Mdical Clinique Paramdical Hpital Domaine financier
Mutuelle

Autre
Recherche

Scurit Sociale Laboratoire Units dexploitation

Pharmacie Units de soins

Services administratifs Services logistiques

Dpartement dInformation Mdicale

Figure 3.1 : Organisation et domaines dun rseau de sant. Le concept de rle est indispensable dans les systmes dinformation mdicale. En effet, on trouve les rles mdecin, infirmire, etc. Les actions des SICSS peuvent tre lmentaires (lire, crire, etc.) ou composite . Par exemple, laction composite prescrire correspond lexcution des actions lmentaires : lire les donnes de sjour hospitalier, consulter lhistorique des prescriptions, lire le rapport infirmier, lire les rsultats dexamens, crer lordonnance et y crire des donnes. Plus gnral que la notion daction composite, un processus de soins fournit le cadre dans lequel les units de soins interagissent pour traiter les patients. Cest donc une activit, enregistre dans le serveur, identifie par un patient, un motif de consultation ou dhospitalisation, et une ou plusieurs quipes soignantes qui collaborent pour traiter le patient [Clercq 1998] et [Delige 2001]. Par exemple, un patient souffrant de douleurs abdominales (problme) peut se prsenter chez son mdecin traitant qui fait une premire valuation et initialise le processus de soins, avant denvoyer le patient chez un spcialiste pour complter et finaliser le diagnostic. Le patient reviendra enfin chez son gnraliste pour assurer un suivi du traitement initi par le spcialiste. Le partage des donnes de sant de ce patient entre ces

64

Chapitre 3 Btir une politique de scurit pour les SICSS

diffrents professionnels de sant seffectue dans le cadre du processus de soins dclar par le mdecin traitant et constitu des trois plans16 de soins. Toute lactivit des professionnels de sant est organise autour du patient. Son dossier napparat un acteur de lunit de soins que sous langle des besoins de sa tche au sein de lorganisation. Chaque acteur ne sera donc concern que par certaines parties du dossier. Dans la littrature, plusieurs types de dossiers ont t cits : le dossier hospitalier, le dossier de spcialit, le dossier partageable, le dossier biologique, le dossier clinique, le dossier de transmission, le dossier minimum europen, le dossier darchives, etc. [Degoulet 1989]. Voici les types de dossiers les plus importants : - Le dossier de spcialit : il est trs spcifique lunit de soins. Sa constitution tient compte du plan de travail et des contraintes de lunit laquelle il appartient. Il existe une grande variabilit dans son contenu et dans la faon dont il est utilis. - Le dossier partageable : ce dossier est dynamique (en cours dlaboration). Il comprend lhistoire mdicale actuelle du patient (les problmes actifs) ainsi que les rsultats provisoires et les avis temporaires. Il est le support permettant aux professionnels de sant participant un processus de soins, de communiquer et dchanger des informations. - Le dossier archive : aprs la fermeture de chaque processus de soins, le dossier archive est aliment par les rsums des dossiers partageables (seules les donnes objectives concernant un patient font partie de son dossier et peuvent tre conserves dans une base de donnes mdicales nominatives). Chaque rsum comprend, outre lidentification du patient, des informations cliniques de synthse, les pathologies diagnostiques, les traitements, la modalit de sortie et la faon dont le suivi de ce patient sera effectu. Ces informations peuvent tre structures dans les rsums : clinique, infirmier, psychiatrique, griatrique, financier et social. Ainsi, contrairement au dossier partageable qui est dynamique, le dossier archive est stable.

3.2.1.2 Informations protger

Plusieurs organisations nationales et internationales sintressent de plus en plus la scurit des SICSS, problme complexe aux dimensions lgales, thiques, sociales, organisationnelles et techniques. Par exemple, lAssemble gnrale des Nations-Unies a adopt des directives pour la rglementation des fichiers informatiss contenant des donnes personnelles [Rsolution 1990]. Le Conseil de lEurope a mis des recommandations concernant les banques de donnes mdicales automatises [Recommandation 1992] et les changes des donnes de sant dans les hpitaux [Recommandation 1997]. La Commission Europenne a dvelopp la directive [Directive 1995] relative la protection des donnes personnelles et la libre circulation de ces donnes. En France, la rcente loi du 4 mars 2002 [Loi 2002] dfinit les droits des malades et dcrit la qualit du systme de sant. Le dcret [Dcret 2002] restreint les accs aux informations personnelles dtenues par les professionnels de sant. Un des points importants qui peut tre extrait de cette rglementation concerne la protection de la vie prive, et plus particulirement les donnes nominatives. On entend par donne nominative toute donne personnelle permettant une identification, directe ou indirecte, dun individu [loi 1978]. Voici quelques types de donnes nominatives : - gnrales (situation en matire de vaccinations, histoire mdicale, traitements chroniques) ; - contacts (donnes relatives une consultation particulire) ;

16 Un plan de soin peut tre dfini comme le rsultat dune consultation (ou dune hospitalisation). Il contient les commentaires, les traitements suivre, etc.

65

archives (protocoles dexamens, rapports de spcialistes, ) ; socio-administratives (donnes relatives lassurance maladie, au rgime dinvalidit) ; indications personnelles du mdecin traitant (hypothses, rflexions). Une donne nominative peut tre de nature diverse : - objective (rsultat dune analyse ou dun test) ; - affirmative (conscutive une interprtation : par exemple, diagnostic) ; - provisoire (hypothse de travail non valide mais toutefois consigne dans un document tel le dossier partageable). Par ailleurs, dautres donnes non-nominatives peuvent tre prsentes dans un SICSS : des valeurs de norme pour les formules sanguines, des rgles dattribution de droits sociaux, etc. Ces donnes prsentent un intrt moindre pour cette tude du point de vue de la confidentialit. Nanmoins la violation de leur intgrit peut induire en erreurs des traitements des donnes personnelles, des diagnostics, des calculs de remboursement, etc. -

3.2.1.3 Risques identifis

Les couples (menace, vulnrabilit) permettent didentifier les risques auxquels peuvent tre soumis les SICSS. Les intrusions dans les SICSS revtent une importance primordiale. En effet, si les proprits de scurit sont violes : - le mdecin risque de prendre des dcisions portant prjudice aux patients, - la valeur de linformation comme base de diagnostic est amoindrie, - dans un cadre mdico-lgal, un professionnel de sant appel justifier ses actions, pourrait se trouver dans lincapacit dutiliser les dossiers informatiques comme preuve. Diverses rglementations se sont intresses lidentification des risques auxquels sont confronts les SICSS et y proposer des solutions. Les directives europennes [Directive 1995] spcifient que le fournisseur dun service web doit prendre toutes les mesures techniques et organisationnelles (dont la dfinition de la politique de scurit) pour garantir la scurit de ses services. La rsolution [Rsolution 1990] met en garde contre les pertes accidentelles dinformations, les accs non autoriss et les utilisations illgitimes. En France, le dcret [Dcret 2002] identifie des menaces relatives aux accs illgitimes et aux pertes de donnes. Le code de dontologie mdicale [Code 1995a] et le code de sant publique [Code 1995b] sensibilisent les professionnels de sant aux risques lis au secret professionnel. En se basant sur ces textes, une liste de menaces et de vulnrabilits a t tablie. Celle-ci est donne en annexe A, selon une classification en fonction des proprits de scurit auxquelles loccurrence des menaces peut porter atteinte. Le type, lorigine ainsi que les consquences de lintrusion sont galement mentionns. Une liste plus exhaustive incluant des menaces plus gnriques est prsente dans [Abou El Kalam et al. 2002c]

3.2.1.4

Besoins de scurit

Les risques identifis justifient un besoin de confidentialit, dintgrit et de disponibilit.

3.2.1.4.1 Confidentialit
La confidentialit est la fois lie au respect du secret professionnel des organismes de sant et la vie prive des patients : - Le respect des donnes personnelles des patients (intimit) : il ny a pas de traitement mdical sans confiance, de confiance sans confidence et de confidence sans secret. Ces secrets ne doivent tre confis quaux utilisateurs autoriss. Ainsi, un utilisateur habilit

66

Chapitre 3 Btir une politique de scurit pour les SICSS

comptabiliser les traitements des mdecins ou faire des statistiques ne devrait pas avoir le droit daccder aux donnes mdicales nominatives des patients. Les utilisations des donnes mdicales des fins non pidmiologiques (comme les publications scientifiques) ne devraient pas permettre dtablir le lien entre les donnes publies et la personne physique concerne, etc. La confidentialit des intrts professionnels : la confidentialit des informations est dabord pour les professionnels de sant une obligation personnelle de discrtion envers les organisations auxquelles ils appartiennent (hpitaux, organismes payeurs, etc.). Le nouveau code de dontologie et les directives europennes prcisent que ce secret est absolu, sauf exception clairement dfinie par la loi.

3.2.1.4.2 Intgrit
Lintgrit peut tre mise en cause par des manipulations errones mais galement par la perte de donnes, accidentelle ou dlictueuse. Elle touche galement la validit des donnes saisies, en particulier, lvitement des collisions17 et des doublons18 lors de la gnration de pseudonymes. Lobligation dintgrit est dabord dfinie par larticle 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 confies ne soient ni dformes ni endommages. Cette obligation dintgrit reconnat toutefois un droit de rectification. Larticle 36 de la loi informatique et liberts affirme que le titulaire du droit daccs peut exiger que soient... rectifies ou effaces 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 laccueil et dispose du droit de demander rparation des prjudices quil estimerait avoir subi . La loi [Loi 2002], relative aux droits des malades, confirme ces droits.

3.2.1.4.3 Disponibilit
Lindisponibilit des donnes (des patients) et des services est intolrable dans ce type de systmes o la vie des patients est en jeu. Le systme dinformation mdicale peut tre jug en danger, ds lors quune information existante peut tre non disponible, suite une dfaillance matrielle ou logicielle, une suppression intentionnelle ou malveillante ou une attaque en dni de service. Dans ce domaine, la disponibilit concerne la fois le caractre durgence et la prennit des donnes : - La disponibilit court terme (caractre durgence ) : les fichiers des patients, les programmes et les applications du systme sont des ressources critiques qui peuvent, un moment donn, tre invoques, par plusieurs utilisateurs, et pour diffrentes raisons (accomplissement des procdures mdicales et administratives, tude de lefficacit des processus, etc.). Il est vident que ces ressources doivent tre disponibles aux utilisateurs autoriss. En cas durgence par exemple, le mdecin du SAMU doit pouvoir y accder, en un temps raisonnable et sans rencontrer de problme daccs ou de rupture du service dlivr par le systme. De mme, dans le cas de la tlmdecine, la gestion de ltat de sant du patient doit tre immdiate alors quil sagit dchanger en toute protection des donnes complexes comme des images, des enregistrements de cardiogrammes, etc. - La disponibilit long terme (prennit) : le maintien long terme des dossiers mdicaux est un problme primordial pour les systmes dinformation mdicale. La CNIL
17

Il y a collision lorsqu partir de donnes nominatives diffrentes, on gnre un mme pseudonyme (qui risque ainsi dtre allou deux personnes diffrentes). Il y a doublon lorsque deux pseudonymes diffrents sont gnrs pour une mme personne.

18

67

(Commission Nationale de lInformatique et des Liberts) comme le Conseil de lEurope ont toujours affirm que les informations nominatives ne devaient pas tre conserves dans un systme informatique plus longtemps que ne le ncessite la finalit dclare des traitements. Ceci ne soulve pas de grandes difficults pour les informations destines des recherches temporaires. Mais ce nest pas le cas des dossiers hospitaliers, puisque le rglement des archives hospitalires impose des dlais de conservation trs longs : soixante-dix ans pour les dossiers de pdiatrie, de neurologie, de stomatologie et de maladies chroniques , illimits lorsquil sagit de maladies hrditaires. Prserver les fichiers est une tche qui nest pas simple. Dune part, au-del du problme des capacits des supports denregistrement, nous navons pas besoin dinformation identifie inutile (simple erreur, diagnostic rvis). Dautre part, il ne faut pas faciliter lcrasement des donnes, notamment les fautes professionnelles et les traces juridiques. La politique de la British Medical Association (BMA) prsente deux solutions ce problme [BMA 1996] : la premire est la mise jour des fichiers par ajout plutt que par effacement. Les versions les plus rcentes doivent tre prsentes en priorit. La destruction doit tre rserve aux fichiers dont la dure de vie, dtermine par la loi, est expire ; la deuxime solution peut consister autoriser les destructions condition quun des mcanismes, tels que laudit, puisse reconstituer les fichiers dans nimporte lequel de ses tats antrieurs.

3.2.1.5 Rglement de scurit

La description du scnario (voir 3.2.1.1) a montr que lorsque le patient se rend chez son mdecin de famille, ce dernier cre un processus de soins. Ce processus est matrialis par un dossier partageable contenant les informations temporaires changes entre les professionnels de sant en charge du patient. la clture du processus de soins, un rsum du dossier partageable met jour le dossier archive. La figure 3.2 explique que les membres des diffrentes quipes qui collaborent pour traiter le patient ont accs aux dossiers archives et partageables, tandis que chacune de ces quipes, possde un dossier de spcialit non accessible aux autres.
Mdecin de famille Dossier partageable Dossier de spcialit Equipe soignante Equipes dun Processus Dossier archive

Figure 3.2 : Accs des catgories dutilisateurs aux diffrents types de dossiers mdicaux. Par ailleurs, mme si les utilisateurs dun systme dinformation mdicale doivent communiquer, cooprer, changer les informations, utiliser les applications et consulter les bases de donnes, ils nont pas forcment les mmes vues. Dune manire gnrale : - Les mdecins gnralistes ont besoin de lensemble des donnes qui leur permettent de grer les aspects mdicaux des cas quils traitent. Ils peuvent visualiser les diagnostics antrieurs ainsi que les rapports infirmiers. Ils ont aussi le droit dditer le rapport de consultation. - Les spcialistes doivent avoir laccs aux dtails relevant de leurs spcialits. - Le personnel infirmier ne doit pas avoir le droit de prescrire de mdicaments, ni le droit daccder certaines donnes dpassant les limites de leur rle dans le systme. Nanmoins, ils ont le droit de rdiger le rapport infirmier.

68

Chapitre 3 Btir une politique de scurit pour les SICSS

Les pharmaciens doivent pouvoir accder la liste des mdicaments prescrits, ainsi qu lhistorique des prescriptions. Ils nont le droit de modifier les ordonnances que pour substituer un mdicament par le gnrique correspondant. Tout accs sinscrivant dans cette exception doit tre audit. Aussi, pouvons-nous dduire que le rle est certainement lun des paramtres qui intervient pour dcider quelle partie du dossier est accessible par quel utilisateur. titre dexemple, le mdecin traitant (psychologue, gyncologue) est le seul possder une partie prive (commentaire) o il met les donnes intimes que le patient ne veut pas partager avec une tierce personne. Cette partie nest donc accessible que par le mdecin et son patient. La figure 3.3 montre lexemple dune quipe compose dun mdecin, dune infirmire et dune secrtaire mdicale. Le sens de la flche indique le sens du flux dinformations : Mdecin Commentaires indique un accs autoris en criture du mdecin la partie commentaires ; Mdecin Commentaires indique un accs autoris en lecture du mdecin commentaires . Laccs au dossier archive nest autoris quen lecture dans la mesure o lalimentation du dossier archive se fait automatiquement aprs la fermeture de chaque processus de soins. Les parties composant le dossier de spcialit diffrent dune quipe une autre. Dossier de spcialit Equipe Commentaires Ordonnance Donnes durgence Rapport Infirmier Donnes de Gestion
(N SS, N chambre, N lit, )

Dossier Archive Identit Mdecin Rsum clinique Rsum infirmier Rsum psychique Secrtaire Mdicale Rsum social Rsum financier

Infirmire

Facture

Figure 3.3 : Accs aux parties des dossiers selon le rle. Dautres rgles daccs peuvent tre dduites directement des textes et loi relatifs aux SICSS. Par exemple, le texte [BCN 1999] indique que les oprations de soins ne sont permises quaux utilisateurs qui sont personnels soignants . La loi [Loi 2002] et son dcret dapplication [Dcret 2002] donnent au patient le droit de lire son dossier mdical : toute personne a accs lensemble des informations concernant sa sant elle peut accder ces informations directement ou indirectement par lintermdiaire dun mdecin et en obtenir communication La prsence dune tierce personne lors de la consultation de certaines informations peut tre recommande par le mdecin , pour des motifs tenant au risques que leur connaissance sans accompagnement ferait courir la personne concerne . partir de cette loi, il est possible de dfinir des rgles de scurit utilisant une modalit de recommandation, par exemple : - il est recommand que le patient accde son dossier mdical travers son mdecin traitant ; - si le patient est mineur ou souffrant de troubles mentaux ou psychologiques, la prsence du tuteur est recommande.

69

En effet, le mdecin est la personne la mieux place pour comprendre le codage et pour expliquer le contenu du dossier mdical soit son patient (si son tat le permet), soit au tuteur (dans des conditions bien prcises). Ces rgles seront compltes et formalises dans le cinquime chapitre.

3.2.2. tude de cas 2 : Sphre sociale

La figure 3.4 illustre le schma global des changes dans le cadre de Net-entreprises [GIP 2002a ; GIP 2002b]. Dans le premier chapitre, nous avons expliqu que Net-entreprises est le service propos aux entreprises par lensemble des organismes de protection sociale pour leur permettre deffectuer, par Internet, leurs dclarations et leurs paiements. Le site Net-entreprises est donc un site permettant laccs lensemble des dclarations (net-xxx) destines diffrents Organismes de Protection Sociale (OPS). La figure 3.4 est divise en deux parties. Une partie montre les liens entre les entreprises et le site portail de Net-entreprises et une autre partie dcrit les flux entre Net-entreprises et les autres organismes tels que les organismes de protection sociale.

Entreprises

Personne Autorise INTERNET

Net-Dclaration 1

OPS 1

Net-Dclaration 2 OPS 2

http://www.net-entreprises.fr

Net-Dclaration 3

OPS n Net-Dclaration n

Accs en amont

Accs en aval

Figure 3.4 : Scnario social.

3.2.2.1 Scnario daccs en amont 3.2.2.1.1 Typologie des entreprises

Dans la partie accs en amont de la figure ci-dessus, plusieurs types de structures organisationnelles peuvent tre distingus, selon que lentreprise est compose dun ou de plusieurs tablissements, selon quelle effectue elle-mme ses dclarations ou quelle les dlgue un tiers, etc. : - entreprises mono-tablissement (un seul N de SIRET, numro qui identifie ltablissement de lentreprise) ; - entreprises multi-tablissements : plusieurs tablissements dont lun est le sige social ; - tiers dclarant (centres de gestion agrs ou cabinets dexpertise comptable) : tablissements habilits par lentreprise saisir et transmettre ses dclarations sociales ; - units dclares : des sous-ensembles dun tablissement ou dune entreprise ; elles peuvent correspondre des dcoupages fonctionnels gographiques ou hirarchiques (ltablissement souhaite que les dclarations concernant une certaine partie du personnel soient effectues sparment des autres) ;

70

Chapitre 3 Btir une politique de scurit pour les SICSS

tablissement adhrent : cest ltablissement qui va utiliser Net-entreprises pour saisir ses propres dclarations ou le tiers dclarant qui saisit les dclarations dautres entreprises.

3.2.2.1.2 Rles fonctionnels dans lentreprise

3.2.2.1.2.1 Mandataire social

Cest le dirigeant du sige de lentreprise. Du fait quil est le reprsentant lgal, il est inform par courrier des inscriptions (aux services de Net-entreprises) effectues pour son entreprise. Lorsque ces personnes sont autorises effectuer des dclarations pour des entreprises extrieures, le mandataire de lentreprise laquelle appartiennent ces personnes sera lui aussi tenu inform. 3.2.2.1.2.2 Dirigeant dtablissement

Le dirigeant dtablissement est le responsable dun tablissement. Pour une entreprise mono-tablissement, ce rle se confond avec celui de mandataire social. Au regard de Netentreprises, les dirigeants acteurs dans les processus fonctionnels sont les dirigeants des tablissements adhrents. Le rle du dirigeant est, pour ce qui concerne linscription, un rle de supervision des informations connues par Net-entreprises. 3.2.2.1.2.3 Administrateur

Ladministrateur gre les inscriptions pour ltablissement adhrent dont il dpend, sous la responsabilit du dirigeant de ltablissement. Il soccupe de la dfinition : - des personnes autorises utiliser les sites et les services ; - des services qui seront utiliss ; - des droits de chaque personne, autorise pour utiliser des services Net-entreprises. 3.2.2.1.2.4 Personne autorise (PA)

La personne autorise est celle dsigne par ladministrateur pour : effectuer les dclarations via Net-entreprises ou consulter des dclarations ancienne, ou effectuer des tlpaiements.

3.2.2.1.3 Exemple de processus

Globalement, on distingue trois types de processus : le processus dinscription proprement dit ; les processus daccs aux services scuriss de Net-entreprises (sites dclaratifs), avec bien videmment, une authentification des utilisateurs et une vrification des habilitations ; - les processus dinformation et dalertes : envoi de courriers lectroniques, gestion des alertes, dont certaines sont personnalises et envoyes ou non aux dclarants. Dtaillons quelques exemples de processus. 3.2.2.1.3.1 Le processus dinscription de ladministrateur

Net-entreprises est un service accessible aux entreprises pour dclarer et ventuellement payer des cotisations sociales. La premire tape est linscription dun administrateur qui est un pralable obligatoire.

71

Ce processus se droule en deux tapes : - Linscription de ladministrateur lui-mme. - Linscription, par ce nouvel administrateur, de personnes autorises ainsi que la dfinition de leurs droits daccs aux services offerts par Net-entreprises. Ladministrateur peut interrompre son inscription en fin dtape 1 et reprendre ultrieurement ltape 2. Selon que lorganisation (dclare) est mono ou multi-tablissements, cette deuxime tape peut prendre deux formes relativement diffrentes : processus dinscription monotablissement, ou processus dinscription multi-tablissements. 3.2.2.1.3.2 Le processus dinscription mono-tablissement

Le processus est men par un administrateur dj inscrit. La dfinition des personnes autorises et de leurs droits peut se faire selon lune des deux filires (mthodes) suivantes : - flash : inscription standard et rapide choix multiples ; - guide : filire complte, permettant de faire des inscriptions sur mesure. 3.2.2.1.3.3 Le processus dinscription multi-tablissements

Il sagit de linscription dutilisateurs par un administrateur afin de grer les droits daccs aux dclarations de plusieurs tablissements de son entreprise. Ladministrateur : - dsigne une ou plusieurs personnes autorises ; - cre un ou plusieurs portefeuilles (ensemble dtablissements de la mme entreprise) ; - affecte chaque personne autorise la gestion dun portefeuille. Comme dans le cas dun mono-tablissement, ladministrateur a le choix entre une filire guide ou flash. 3.2.2.1.3.4 Le processus dinscription tiers-dclarant

Il sagit de linscription dutilisateurs par un administrateur (appartenant un centre agre ou un cabinet dexpertise comptable) qui souhaite autoriser des personnes dclarer pour dautres entreprises que la sienne. Ce type dinscription affecte des entreprises des portefeuilles dentreprise. Ces portefeuilles sont constitus de la liste des entreprises que va devoir grer une personne autorise. Les deux filires possibles sont : - la filire de masse : cette filire est destine aux tiers-dclarants grant un ensemble dentreprises clientes assez consquent ; ce processus de dfinition de droits daccs aux dclarations nest pas effectu en ligne, il sappuie sur lenvoi, par courrier lectronique, de fichiers partir desquels des oprateurs saisissent les droits daccs aux dclarations ; - la filire guide : cette filire donne la possibilit lutilisateur daffecter les droits daccs aux personnes autorises par tapes, enchanes une une. En ralit, chacun de ces processus ncessite des traitements plus complexes que ceux dcrits dans cette section, les dtails peuvent tre trouvs dans [Abou El Kalam et al. 2003c].

72

Chapitre 3 Btir une politique de scurit pour les SICSS

3.2.2.2 Scnario daccs en aval

Le scnario en back-office est rsum dans la figure 3.5
Accueil tlphonique

CAT

net-xxx

OPS/ONPS
atio n

SI OPS de production

istr min Ad

Accueil Primo - inscription Modification Accs aux dclarations Abonnement Dsabonnement

GIP MDS

MODULE DE BASE Site Portail & Inscription

SIRENE

Liste de rvocation

REFERENTIELS Autorit de certification

Notariat technique

web
Push-mail

Courriers Mails

Figure 3.5 : Scnario daccs en aval.

3.2.2.2.1 Les acteurs

Dans ce scnario, plusieurs organismes entrent en scne, notamment : Les OPS ou ONPS (Organismes Nationaux de Protection Sociale) sont les organismes rcepteurs dune ou plusieurs dclarations sociales, quelle quen soit la nature. Ils ont comme tches principales de : fournir, via le site, des informations et alertes aux entreprises inscrites ; daccder des informations telles que les statistiques ou la base des inscrits, via des outils de requte et de grer la partie du rfrentiel OPS qui les concerne. Ce rfrentiel contient la liste des OPS, leur groupe dappartenance, leur ONPS de rattachement, leur adresse et ventuellement une adresse de page web (URL). Le rfrentiel sera utilis pour linscription lors du choix des organismes destinataires. - Le GIP-MDS (Groupement dIntrt Public, Modernisation des Dclarations Sociales) est la structure de pilotage dont se sont dots les organismes de protection sociale pour permettre aux entreprises deffectuer leurs dclarations sociales au moyen de tlservices. Outre la gestion du site www.net-entreprises.fr, le GIP a pour vocation de contribuer la diffusion des bonnes pratiques, de coordonner les travaux des organismes pour les diffrentes dclarations, de fournir des informations et alertes aux entreprises et dutiliser des services transversaux, comme laccs des statistiques, des bases de donnes ou des outils de requte sur les informations disponibles sur le site. - Les fournisseurs de rfrentiels. Il existe trois grands types de rfrentiels : Le gestionnaire du rfrentiel des entreprises (liste des OPS, leurs groupes dappartenance, leurs ONPS de rattachement) : il est gr par lINSEE travers le fichier SIRENE. Ce rfrentiel est dupliqu la CNAVTS (Caisse Nationale dAssurance Vieillesse des Travailleurs Salaris). Aujourdhui, cest cette copie qui est utilise (par le site dinscription hberg par cet ONPS), car elle est enrichie dinformations issues de lexploitation annuelle des dclarations, des informations -

73

releves par le service dinspection des accidents du travail et dautres informations issues du dialogue avec les autres OPS. Rfrentiels bancaires : ils sont grs par la banque de France. Ce rfrentiel est transmis de faon rgulire Net-entreprises pour permettre des contrles sur les numros de codes de guichet et de banque. Autorits de certification : elles mettent et grent les certificats lectroniques utiliss pour la scurisation des accs et changes dans le cadre de Net-entreprises.

3.2.2.2.2 Les services

Les utilisateurs se connectant Net-entreprises via Internet arrivent dabord sur une page daccueil gnrique. Cette page daccueil est un point de passage oblig pour accder lensemble des services du site, notamment le service dinscription et les services dclaratifs. 3.2.2.2.2.1 Accueil et informations en ligne

Ce service est destin aussi bien aux inscrits quaux personnes souhaitant sinscrire. Il sert effectuer des oprations de diffrentes natures : dmonstration, simulation de cotisation ou de dclaration, actualits, consultation dinformations sur les partenaires et lorganisation de Netentreprises, gestion des demandes de renseignements sur Net-entreprises, dpt de commentaires et consultation des conditions gnrales dinscription. 3.2.2.2.2.2 La primo-inscription

Cest linscription du premier administrateur rattach un tablissement donn. Elle induit ladhsion de son tablissement Net-entreprises en fournissant le numro SIRET de ltablissement de ladministrateur. Ladministrateur spcifie sil souhaite tre dclarant pour le compte dun autre tablissement en tant qutablissement de la mme entreprise ou en tant que tiers-dclarant. 3.2.2.2.2.3 Dfinition des habilitations par ladministrateur

Une fois inscrit, ladministrateur peut inscrire et grer un ensemble de personnes et leur affecter des droits pour effectuer des dclarations ou payer des cotisations pour leurs tablissements, dautres tablissements de la mme entreprise, ou dautres entreprises. 3.2.2.2.2.4 Lattribution dun mot de passe pour les personnes inscrites

Ce service sadresse aux personnes dj inscrites ne possdant plus le moyen daccder leur Accueil Personnalis. Diffrentes causes sont possibles : - ils ne se souviennent plus du mot de passe qui leur sertt de cl dauthentification ; - le mot de passe nest plus valide (lorsquil atteint la fin de sa priode de validit) ; - ils ont gar le certificat enregistr par Net-entreprises qui leur sert de cl dauthentification ; - le certificat nest plus valide (expir ou rvoqu). 3.2.2.2.2.5 Abonnement ou dsabonnement un service dinformation

Ce service sadresse aux utilisateurs ntant pas forcment inscrits Net-entreprises (les journaliste, par exemple) mais souhaitant tout de mme recevoir de linformation par courrier lectronique concernant Net-entreprises.

74

Chapitre 3 Btir une politique de scurit pour les SICSS

3.2.2.2.2.6

Des fonctionnalits dadministration du site

Il sagit des statistiques sur les inscriptions, statistiques techniques, la gestion de rfrentiels, la gestion de linformation diffuse, les lments de supervision, etc. Le tableau 3.1 rsume les fonctionnalits de ces services et prsente les accs. Service Dmonstration Description Accs

Permet de se procurer le logiciel de partir de lAccueil dmonstration dcrivant les fonctionnalits Gnrique ; accessible offertes par Net-entreprises tous. Donne laccs une fonctionnalit de partir de lAccueil simulation de dclaration (ou de cotisation) Gnrique ; accessible parmi celles accessibles sur le site tous. Permet de tester les dveloppements effectus partir de lAccueil sur les logiciels destins laborer les fichiers Gnrique ; accessible transmissibles tous les diteurs de logiciel. Pour des utilisateurs non inscrits Net- partir de lAccueil entreprises qui souhaitent tre informs par Gnrique ; accessible courrier lectronique des nouvelles tous. concernant le site ou les dclarations. Permet lutilisateur de disposer, partir du partir de lAccueil mme service, de lensemble des informations Gnrique ; accessible concernant les partenaires et lorganisation de tous. Net-entreprises. Tableau 3.1 : Accs en aval aux services de Net-entreprises.

Accs la simulation de dclaration ou de cotisation Qualification des logiciels

Abonnement ou dsabonnement aux services dalertes Consultation dinformations sur Netentreprises

3.2.2.3 Ressources protger, menaces, exigences et rgles de scurit

Afin de ne pas alourdir ce mmoire, il a sembl prfrable de classer directement les ressources protger, ainsi que les menaces auxquelles elles sont confrontes, en fonction des proprits de scurit (disponibilit, confidentialit, lintgrit et responsabilit). 3.2.2.3.1.1 Composant Disponibilit Menace Quelques solutions

Poste de travail de Incompatibilit avec le site ou le Compatibilits des services lutilisateur. navigateur du tlservice ; Dfaillance selon les systmes, les ponctuelle : panne, virus, etc. navigateurs et les versions. Accs d e Panne modem, impossibilit de se lutilisateur connecter ; indisponibilit du Internet fournisseur.

75

Accs au serveur Indisponibilit physique : absence de dadministration connexion des serveurs au rseau ; par Internet insuffisance de la bande passante (critique si elle se rpte dans le temps ou si elle intervient dans les heures prcdant lchance des tldclarations ou tlpaiements). Application dadministration (tlservices, inscription, dclarations). Surcharge (encombrement), indisponibilit suite un problme technique de une faute de conception ou une attaque.

Contraintes auprs de lhbergeur daccs multiples au rseau, de bande passante suffisante, sites de secours ; solutions organisationnelles comme le report des dates des chances. Tolrance aux fautes (traitement de fautes, et des erreurs) ; tests de charges ; contrer les attaques de DoS par une inscription pralable au tlservice, de faon filtrer les accs ultrieurs;

Informations temporaires (avant validation) saisies par lutilisateur. Tldclarations (ou tlrglements ou accuss de rception) pour consultation ultrieure ou pour preuve.

Perte des informations avant que le Sauvegardes page page des processus relatif ce service ne soit informations utiles. entirement valid ; interruption inattendue dun processus. Indisponibilit des donnes suite une suppression illgitime ou un problme technique matriel ou logiciel ; non-conservation des donnes relatives aux tldclarations ou aux tlrglements. Conservation (par Netentreprises) des donnes conformment aux dispositions lgales relatives chaque dclaration ; conservation des accuss de rception par le dclarant.

Tableau 3.2 : Menaces pouvant porter atteinte la disponibilit dans le social. Quelques rgles, relatives la disponibilit, extraites des conditions dadhsion aux services de Net-entreprises peuvent tre ajoutes : - (Article 7) : les donnes relatives aux tldclarations sont conserves conformment aux dispositions lgales et conformment aux rgles spcifiques chaque dclaration. Sauf stipulation contraire et conformment aux rgles spcifiques chaque dclaration, le dclarant pourra consulter par lintermdiaire de Net-entreprises les donnes concernant les tldclarations pralablement effectues et pour lesquelles il est inscrit. - ( Article 9) : le service est accessible sept jours sur sept et 24 heures sur 24 pour linscription et les dclarations vnementielles, et dans le respect des calendriers dclaratifs spcifiques chaque dclaration chance. Toute dfaillance relevant du siteportail ou du site dclaratif se traduit par lmission dun message indiquant lutilisateur lindisponibilit 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 dexigibilit par les moyens traditionnels.

76

Chapitre 3 Btir une politique de scurit pour les SICSS

3.2.2.3.1.2

Confidentialit Menace Divulgation, travers le tlservice, des informations sensibles des personnes externes non habilites (externes au systme). Divulgation par le tlservice des informations sensibles des personnes internes non habilites ; vol de privilges ; abus de privilges. Solutions Contrle daccs ; changes scuriss entre le dclarant et le serveur, par exemple avec des mcanismes comme SSL ou TSL. Gestion des habilitations avec une sparation entre lidentit de la personne et le contrle des droits. Possibilit dutiliser des certificats dattribut accols un certificat de signature.

Information sensible Accs en aval : Informations nominatives de nature industrielle ou commerciale comme le numro SIRET dun travailleur indpendant, les donnes mdicales ; Accs en aval : les salaires des cadres, les donnes soumises au secret professionnel.

Confidentialit des mots Perte, divulgation ou vol des Utilisation de moyens matriels de passe d e mots de passe. (cartes puce, par exemple) ladministrateur et des et/ou biomtriques dclarants Tableau 3.3 : Menaces pouvant porter atteinte la confidentialit dans le social. Quelques rgles, relatives la confidentialit, extraites des conditions dadhsion: (Article 1) : linscription confre au reprsentant de lemployeur ou du tiers dclarant mandat par lemployeur le statut dadministrateur, et lui permet de dsigner les personnes de son choix (personnes autorises) pour effectuer une ou plusieurs dclarations (ou tlrglements). Ces personnes sont ci-aprs dnommes le dclarant. - (Article 2) : seule (s) la ou les personne(s) autorise(s) dsignes par ladministrateur Netentreprises peuvent effectuer la ou les dclaration(s) ou accder aux services scuriss pour lesquels elles sont inscrites. 3.2.2.3.1.3 Intgrit Risque Solution Contrle syntaxique ; tout rejet d un contrle doit entraner une alerte de lutilisateur avec une demande de correction. Contrle daccs ; chiffrement ; etc.

Information protger

Information Non-conformit. communique lapplication (cest--dire, saisie par lutilisateur) Information qui transite Altration non autorise par le rseau

Services et programmes C o n t o u r n e m e n t o u Contrle daccs ; signatures ; offerts par N e t - modification non lgitime tests dintgrit et certification. entreprises. de la part de lutilisateur Tableau 3.4 : Menaces pouvant porter atteinte lintgrit dans le social. 3.2.2.3.1.4 Responsabilit

La question de responsabilit dans les tlprocdures est lie de multiples facteurs : les textes juridiques en vigueur, les besoins fonctionnels des partenaires au tlservice, les

77

solutions techniques et organisationnelles mises en uvres ainsi que le niveau de risque considr comme acceptable. Lidentification des responsabilits sintresse, entre autres, aux diffrents motifs de litiges concernant linformation ou la mta-information : - existence de la dclaration (mta-information) ; - contenu de la dclaration (information) : ce qui est saisi et envoy dune part, et ce qui est reu dautre part ; - moment de la dclaration (mta-information) sachant que tout retard entrane des pnalits. Risque Ladministration considre navoir pas reu une dclaration que lusager affirme avoir effectu. Lusager na rien envoy alors que ladministration a reu une dclaration Description Le dclarant est a priori responsable, et il ne peut dgager la responsabilit quen apportant la preuve de la dfaillance de ladministration. Solution La dlivrance dun accus de rception soit en mode EFI (envoi immdiat) ou EDI (asynchrone, par exemple, par envoi de courrier lectronique aprs vrification de la conformit du format).

Deux cas possibles : mauvaise Mcanismes dauthentification foi du dclarant ou usurpation ( c e r t i f i c a t , mcanismes malveillante de lidentit de biomtriques, etc.). lusager (fausse dclaration ; demande de mutation)

Tableau 3.5 : Menaces pouvant porter atteinte la responsabilit dans le social. La disponibilit long terme de certaines mta-informations peut contribuer assurer la proprit de non-rpudiation. En loccurrence, le stockage des accuss de rception permet de se prmunir contre les litiges. Ainsi, lors dun dsaccord sur le contenu de lchange, le dclarant pourra prsenter laccus de rception (envoy par le tlservice) mentionnant les caractristiques principales du fichier. De la mme manire, la sauvegarde des modles de courriers faire parvenir aux centres des impts, permet de se prmunir contre certaines dfaillances. Lintgrit joue galement un rle important dans la non-rpudiation. En effet, la signature lectronique de laccus de rception aura une valeur probante plus forte (non sign, il pourrait tre falsifi). De mme, lintgrit de lidentit de lmetteur est trs importante car, si lidentification est trs simple (par exemple en utilisant le nom patronymique, la raison sociale ou le numro SIRET), le systme est confront des risques de doublons, de confusions ou mme dusurpations des identits. Par ailleurs, dans les applications du domaine social, il est ncessaire de tracer les modifications des informations des bases de donnes (des OPS, rfrentiels, etc.). Cette fonction notariale peut tre tendue au traage des actions effectues par lutilisateur, en particulier chaque changement de page ou dcran, en prenant en compte les impacts sur les performances et les volumes de stockage. Outre le fait quelles permettent le suivi des oprations effectues par les utilisateurs sur le site, les informations notariales servent galement effectuer des statistiques. Elles devront tre accessibles aux OPS, au GIP-MDS (Groupement dIntrt Public, Modernisation des Dclarations Sociales), au CAT (Centre dAccueil Tlphonique) ainsi qu certains internautes au moyen du service Consultation de lhistorique des modifications . Bien videmment, il est ncessaire de pouvoir isoler ces types dinformations : les modifications sur les noms, prnoms, et courriers lectroniques des

78

Chapitre 3 Btir une politique de scurit pour les SICSS

personnes autorises nintressent pas les dirigeants alors quelles peuvent intresser les administrateurs (protection de la vie prive). Dans ce cas, un dirigeant verra lhistorique des modifications survenues dans son entreprise lexception de ces informations.

3.2.3. tude de cas 3 : Analyse de diffrents scnarios danonymisation dinformations mdicales 3.2.3.1 Problmatique de lanonymisation
Bien que linstauration du rseau de soins facilite la communication des donnes entre diffrentes structures, elle pose des problmes concrets de scurit. Dune part, lusage dinformations mdicales nominatives pour les soins impose davoir lassurance de lidentit des personnes auxquelles se rapportent ces informations. Dautre part, en facilitant lchange, le partage et le traitement des donnes de sant entre acteurs, la reconnaissance physique19 du patient peut contribuer briser le secret mdical ou permettre dinfrer des informations confidentielles, par exemple en constituant des listes de personnes atteintes de certaines maladies (informations dont des socits dassurance, entre autres, pourraient tirer profit). Les lgislations internationale [Rsolution 1990] et europenne [Directive 2002 ; Directive 1995 ; Recommandation 1997] visent protger les donnes personnelles et interdisent tout croisement de fichiers. De mme, en France, la loi informatique, fichiers et liberts [Loi 1978] accorde une protection particulire aux donnes nominatives. Il existe toutefois une certaine nuance entre donne nominative et donne caractre personnel. Nous pensons quune donne peut tre non-nominative tout en restant personnelle, alors que certains travaux ne font pas la diffrence entre donne nominative et donne caractre personnel lorsquils considrent que, aprs anonymisation, une donne nominative (devenue anonyme) ne peut plus tre vue comme tant caractre personnel. Ceci nest pas toujours exact dans la mesure o, il est parfois possible, de r-identifier des donnes anonymises. Ainsi des donnes anonymises peuvent perdre ou non leur caractre anonyme, de mme que des donnes nominatives peuvent perdre leur caractre nominatif. Mais dans tous les cas, nominatives, anonymes ou anonymises, ces donnes restent caractre personnel. Les anglo-saxons parlent dailleurs de de-identification au lieu danonymisation. Malheureusement, il est souvent possible didentifier un individu par un simple rapprochement de donnes personnelles de nature mdicale ou sociale. Par exemple, lge, le sexe et le mois de sortie de lhpital, permettent disoler le patient dans une population restreinte ; la donne de deux dates (voire de deux semaines) daccouchement pour une femme permet de lisoler dans une population plus grande (typiquement, la population dun pays comme la France). Dailleurs, le domaine de linfrence dinformation dans les bases de donnes a t tudi depuis de nombreuses annes, et il a fait lobjet dune abondante littrature [Cuppens 2003]. Selon les besoins, le choix en terme de protection de donnes peut faire appel des solutions techniques comme le hachage et le chiffrement, ou organisationnelles comme les politiques de contrle daccs et les anonymisations thmatiques. Un premier niveau de confidentialit peut tre assur en chiffrant les donnes transmises, de faon ce quelles ne soient dchiffres que par le ou les destinataires lgitimes. Par exemple, ce peut tre le cas dun change de donnes mdicales entre le laboratoire danalyses mdicales et le mdecin traitant. Dans dautres cas, on souhaite garder lanonymat de certaines donnes
19 La reconnaissance physique est utilise dans le sens de rtablissement de la correspondance entre les identifiants et les personnes physiques.

79

(en loccurrence, les identifiants) mme si le destinataire est lgitime. Par exemple, garder lanonymat total lgard des assurs ou des ayants-droit lors de publications scientifiques, ou lors de la transmission des informations relatives lactivit des mdecins libraux vers les Unions Professionnelles (assembles de mdecins lus par rgion ou regroups en sections). Si le but est de pouvoir effectuer des trajectoires de soins, cest--dire, avoir un suivi permanent des volutions des maladies, on utilise un code anonyme, mais toujours le mme pour un patient donn. Enfin, il est parfois souhaitable quune autorit puisse croiser les donnes anonymises avec dautres donnes anonymes concernant le mme individu, ou mme lever lanonymat dans des cas bien particuliers. Par exemple, dans le cas des tudes pidmiologiques, les corrlations entre plusieurs pathologies peuvent ncessiter de remonter aux identits relles pour complter a posteriori les donnes recueillies antrieurement, et ainsi affiner ces tudes. Notons que, compte tenu des caractristiques des diffrents scnarios danonymisation, la mthodologie utilise dans cette section est lgrement diffrente de celle applique dans les deux premires tudes de cas. Ainsi, nous procdons selon les tapes suivantes : dabord, dfinition de la base terminologique associe au thme anonymisation ; puis discussion des diffrentes solutions danonymisation utilises dans les pays europens ; - ensuite, dfinition dun ensemble de scnarios relatifs au thme danonymisation ; - enfin, pour chacun de ces scnarios, construction dune dmarche danalyse des besoins : identification des besoins, objectifs et exigences de scurit et, dans la mesure du possible, choix de solutions adaptes. Un besoin danonymisation reprsente les attentes de lutilisateur (pas toujours trs bien explicites). Un objectif danonymisation spcifie le niveau de scurit atteindre ou les menaces viter (comment satisfaire les exigences ?). Une exigence danonymisation reprsente la faon dexprimer le besoin (dans la mesure du possible, trs proche dun formalisme clair et dune smantique non-ambigu). Mme si tous les scnarios que nous voquons dans cette section sont extraits du domaine mdical, les besoins danonymisation de certaines donnes sensibles concernant des personnes ou des entreprises est galement un point crucial. La mthodologie que nous proposons pour lanalyse de la procdure danonymisation peut tre applique aux systmes de sant, mais aussi dautres secteurs, notamment les secteurs social, bancaire, militaire, etc.

3.2.3.2 Notion dobjectifs danonymisation

Lanonymisation peut tre dfinie comme une mesure visant empcher de dterminer lidentit relle dune personne ou, du moins, ne rendre cette dtermination possible quau prix defforts dmesurs. La terminologie des critres communs [CC 1999a] dfinit la pseudonymisation comme une anonymisation telle que la personne concerne puisse tre tenue comme responsable de ses actes. En pratique, cela signifie que la pseudonymisation est une anonymisation rversible, cest--dire permettant des personnes dment autorises cet effet de retrouver lidentit relle de la personne concerne. La chanabilit peut tre dfinie comme la proprit de pouvoir dterminer que diffrentes informations correspondent une mme personne, sans ncessairement connatre lidentit relle de cette personne. Un objectif danonymisation est dfini en fonction de lune des trois proprits suivantes applicables la fonction danonymisation [Trouessin 2001 ; Abou El Kalam et al. 2003c] :

80

Chapitre 3 Btir une politique de scurit pour les SICSS

rversibilit : cacher les donnes par un simple chiffrement des donnes. Dans ce cas, il y a possibilit de remonter depuis les donnes chiffres jusquaux donnes nominatives originelles. irrversibilit : cest le cas rel de lanonymisation ; une fois remplacs par des identifiants anonymes, les identifiants nominatifs originels ne sont plus recouvrables ; cependant, avec les techniques dattaques par infrence20, les identifiants anonymes, sils sont trop universellement utiliss, risquent de permettre la dcouverte didentits mal caches, comme on lexplique ci-aprs ; pour ce type danonymisation, la technique communment utilise est une fonction de hachage ; inversibilit : cest un cas mixte entre rversibilit et irrversibilit, cest--dire entre le techniquement ou cryptographiquement irrversible et le organisationnellement et juridiquement rversible ; autrement dit, il est impossible en pratique de remonter aux donnes nominatives, sauf en appliquant une procdure exceptionnelle sous surveillance dune instance lgitime (mdecin-conseil, mdecin inspecteur) garante du respect de la vie prive des individus concerns ; il sagit cette fois-ci dune pseudonymisation au sens des critres communs.

3.2.3.3 Notion dexigences danonymisation

Des informations sur lenvironnement21 informatique du systme tudi permettent de complter lanalyse du besoin. En loccurrence, mme si les informations sont anonymes, un utilisateur malveillant peut construire divers types de raisonnement pour dduire des informations confidentielles. Les exigences danonymisation sont exprimes en terme de chanage (continuit de lanonymisation) et de robustesse (sret de lanonymisation). Le chanage permet dassocier un ou plusieurs identifiants anonymes une mme personne physique. Comme indiqu sur la figure 3.6, un chanage peut tre temporel (toujours, parfois, jamais) ; gographique (international, national, rgional, local) ; ou spatio-temporel (par exemple, toujours et partout, parfois et partout, local et jamais) [AFNOR 1997]. La robustesse dun systme danonymisation est constitue de lensemble des caractristiques satisfaire vis--vis dattaques ayant pour but de lever lanonymat de faon non-autorise. Il peut sagir dune robustesse la rversion concernant la possibilit ou limpossibilit dinverser la fonction danonymisation, mais il peut aussi sagir dune robustesse linfrence qui consiste dterminer des informations nominatives partir dlments dinformations purement anonymes. En gnral, une infrence peut tre : - dductive : elle utilise la logique du premier ordre (valeurs : oui, non ; oprateurs : et, ou) pour dduire des informations confidentielles non accessibles ; par exemple, si un certain patient fait un test de dpistage puis dans les quelques jours qui suivent, il fait un test de dosage, alors le rsultat du dpistage tait positif ; - inductive : sapparente souvent des raisonnements de type loi des grands nombres sans forcment lappliquer sur de grandes chelles ; cela consiste par exemple, induire quun tel patient est trs certainement atteint de telle pathologie compte tenu du fait quil lui est prescrit tels mdicaments comme il est dusage pour cette pathologie ; - abductive : lorsquun raisonnement classique utilisant les informations explicitement stockes dans le systme dinformations ne permet pas dinfrer dinformations, mais ce
Une infrence est la dcouverte de donnes confidentielles non directement accessibles, rendue possible par la mise en correspondance de plusieurs donnes lgitimement accessibles, rvlant tout ou partie des informations relatives une personne. 21 Par environnement informatique du systme, on entend lensemble des utilisateurs, la nature des attaquants et les types des attaques.
20

81

raisonnement pourrait te complt en faisant des hypothses sur certaines informations, par exemple, et sil avait un cancer, cela expliquerait pourquoi il sabsente du Conseil des Ministres pour se rendre lhpital Paul Brousse de Villejuif . - probabiliste (ou adductive) : elle parvient estimer la vraisemblance dune information sensible en utilisant les informations accessibles, par exemple, puisque P est trait lhpital H, et puisque H est spcialis dans les maladies M1 et M 2, et puisque son ge, la probabilit davoir M1 est trs faible (10%), alors on peut dduire qu 90%, P est atteint de M2. Cette liste nest pas exhaustive et on peut naturellement imaginer dautres types de canaux dinfrence fonds sur dautres types de raisonnement, tel que le raisonnement par vidence ou par analogie. Pour faire face ce type de menaces et protger les donnes personnelles, divers pays se sont intresss aux fonctions danonymisation des donnes mdicales utilises des fins non directement pidmiologiques.
Hist oire

Rseau des cas de chanage danonymisations irrversibles

Eternel
Toujours

Totalit

Perptuel

Uniforme

Universel

Annuel
Parfois

Partialit

Prenne

Universifi

Ubiquiste

Ponctuel
Jamais

Nullit

Perdu Opaque Unique

Coordonn

Coopratif

Local
Ici

Nullit

Rgional
Autour

Partialit

National
Partout

Totalit

Gographie

Figure 3.6 : Anonymisation en cascade : de luniversalit jusqu lunicit.

3.2.3.4 Lanonymisation dans les pays europens 3.2.3.4.1 Lanonymisation en France

En 1995, le CHU de Dijon, ainsi que dautres tablissements de sant de la rgion Bourgogne ont choisi lalgorithme de hachage SHA (Standard Hash Algorithm) pour transformer, dune manire irrversible (anonymisation), les variables didentification : nom, prnom, date de naissance et sexe. Le but est dobtenir un identifiant strictement anonyme, mais toujours le mme pour un patient donn [Quantin et al. 1998]. Nanmoins, mme si SHA est mathmatiquement irrversible, il ne rsiste pas aux attaques ponctuelle ou par dictionnaire . En effet, supposons quun tiers malveillant, Bob, a accs une base de donnes mdicale anonyme BDMA. Dans une attaque ponctuelle, Bob voudrait, par exemple, savoir si Alice a le SIDA. La premire tape consiste appliquer lalgorithme de hachage aux variables identifiantes dAlice afin dobtenir lidentifiant anonyme associ Alice : NAAlice. La deuxime tape consiste chercher si NAAlice existe dans la base de donne anonyme des personnes ayant le SIDA BDMASIDA.

82

Chapitre 3 Btir une politique de scurit pour les SICSS

Dans une attaque par dictionnaire, Bob pourrait appliquer lalgorithme de hachage une liste de variables identifiantes (dictionnaire) pour disposer dune table Tid-Num reliant des variables identifiantes des codes anonymes. En faisant un simple rapprochement entre la base de donnes mdicales anonymes et la table, il pourrait facilement dduire les informations mdicales des personnes dont les noms figurent sur son dictionnaire (figure 3.7).
BDMA
Identifiant Anonyme Donnes mdicales

NAi Dmdi

Dictionnaire Utilisateur malveillant qui fait un rapprochement de donnes pour infrer des informations nonautorises

Identifiant Anonyme

Donnes mdicales

Nomi NAi

Dmdi

TId-NA
Dictionnaire Dictionnaire de noms Identifiant Anonyme

Nom1 Nomn

Application de lalgorithme de Hachage

Nom1 Nomn

NA1

NAn

Figure 3.7 : Attaque par dictionnaire. Pour illustrer la procdure danonymisation utilise dans la rgion Bourgogne, considrons maintenant le cas o les hpitaux transmettent des donnes mdicales au Dpartement dInformations Mdicales (DIM). Celui-ci effectue des analyses mdico-conomiques, avant darchiver toutes les donnes mdicales de tous les patients (aux niveaux des agences rgionales dhospitalisation par exemple). Si on nutilise quune fonction de hachage du ct des hpitaux, les personnes en charge des traitements statistiques et mdico-conomiques (au DIM) peuvent remonter aux identits par une simple attaque ponctuelle (ils disposent des donnes mdicales anonymes et de lalgorithme de hachage). Par ailleurs, du ct du DIM, si on nutilise quune fonction de hachage avant larchivage, les employs des hpitaux pourront retrouver les identifiants (utiliss dans les archives) de nimporte lequel de leurs patients, ainsi que toutes les informations concernant ce patient, y compris celles provenant des autres tablissements (rappelons que la loi [Loi 2002] donne au patient le droit dinterdire que certaines de ces donnes soient communiques dautres professionnels de sant voir section 3.2.2.1.5). Pour prvenir ce type dattaques, deux cls ont t ajoutes lalgorithme de hachage SHA. La premire cl k1, utilise par tous les metteurs des donnes (hpitaux et mdecins), est concatne lidentit. Une fonction de hachage est ensuite applique au rsultat : empreinte1 = H(k1 | identit). Cette opration produit une empreinte qui varie dune identit lautre, mais qui est toujours la mme pour un patient donn. Les informations transmises au centre de traitement des fichiers (DIM) en vue de leur rapprochement sont ainsi devenues strictement anonymes et les personnes qui assurent les traitements centraliss ne peuvent pas lever lanonymat laide dune attaque par dictionnaire puisquelles ne connaissent pas la cl k1. De

83

lautre ct de la communication, les informations reues par le DIM sont haches par le mme algorithme mais avec une seconde cl k2, qui nest pas communique aux hpitaux : empreinte2 = H(k2 + empreinte1) (voir figure 3.8).
Transmetteur dchiffrement Premier hachage cl secrte K1 Message transmettre M1 Service charg du traitement (DIM) Message reu Deuxime hachage cl secrte K2 Chiffrement

Figure 3.8 : Procdure de double hachage des informations traites par le DIM. Le protocole prsent en Bourgogne savre complexe et risqu. En effet, il ncessite une distribution de la mme cl secrte tous les fournisseurs dinformations (mdecins libraux, hpitaux, cliniques, etc.), tout en supposant que cette cl doit rester secrte. Certes, une personne qui ne connat pas une des cls secrtes (k1 ou k2) est dans limpossibilit deffectuer les transformations. Nanmoins, si une cl est corrompue, le niveau de scurit est considrablement rduit. De mme, si un jour il savre que lalgorithme (ou la longueur de la cl) nest plus efficace, comment faire le rapprochement entre les identifiants avant et aprs changement de lalgorithme ou de la cl (sachant que les empreintes dpendent de la cl suppose tre toujours la mme et chez tous les fournisseurs dinformations) ? Si ce problme survient, la seule solution envisageable consiste appliquer une autre transformation toute la base de donnes, solution qui nest gure aise. tudions prsent une autre procdure qui a t labore par le CESSI de la CNAM-TS pour le PMSI (Programme de Mdicalisation des Systmes dInformation) priv : la procdure FOIN (Fonction dOccultation dInformations Nominatives). Comme en Bourgogne, la procdure de la CNAM utilise une fonction de hachage sens unique (SHA) avec une cl des deux cts. Loriginalit de cette mthode rside dans lutilisation de la technique de Fragmentation-Redondance-Dissmination ou FRD [Fabre et al. 1996]. Les tapes de cette technique de tolrance aux intrusions, dj explique, sont les suivantes : dcouper linformation (cl secrte) en fragments de telle sorte que des fragments isols ne puissent fournir dinformation significative ; - ajouter de la redondance pour empcher que la modification ou destruction de quelques fragments nait pas de consquence pour les utilisateurs autoriss ; - isoler les fragments les uns des autres par dissmination de sorte quune intrusion (la corruption dune partie de la cl secrte) dans une partie du systme ne fournisse que des fragments isols. En utilisant cette technique de FRD pour protger la cl secrte ncessaire la fonction danonymisation, FOIN fragmente la cl secrte en N images de telle sorte quelle ne peut tre reconstruite qu partir dun certain nombre s (dit seuil de reconstitution) dimages diffrentes. En fait, cette notion de seuil repose sur le schma seuil de Shamir qui peut se rsumer ainsi : le partage du secret k (cl secrte) est fait sur N images distinctes ; il seffectue laide dun polynme P(x) de degr s-1, s tant le seuil de reconstruction : P(x) = a0 + a1x + .. + as-1xs-1 ; il suffit de rassembler s images distinctes parmi les N images pour permettre de recalculer le secret k ; les calculs se font dans un corps de Galois (corps fini offrant certaines proprits mathmatiques) ;

84

Chapitre 3 Btir une politique de scurit pour les SICSS

le secret k est lensemble des coefficients du polynme : (a0, a1, .., as-1). La figure 3.9 prsente un exemple avec s=2 (P(x) = a0 + a1x).
K1 K2 . . Dissmination Fragmentation K Redondance Ks KN Secret Copies K1 K2
x x Ks x K1 K2

Ks KN

Images conserves sur supports distincts

Reconstitution du secret

Figure 3.9 : Fragmentation-Redondance-Dissmination de la cl secrte. Les images de la cl secrte sont dissmines sur un nombre de supports distincts. La premire image sera place dans la fonction danonymisation (dans le logiciel distribu aux transmetteurs dinformations), les autres sont donnes des personnes de confiance, comme le responsable de lapplication ou le directeur de la CNAM. Ainsi, mme sil existe N images (fragments) de la cl, la prsence de s -1 personnes de confiance est suffisante pour reconstituer le secret (figure 3.10). Comme en Bourgogne, et pour se prmunir contre toute attaque ponctuelle ou par dictionnaire, la fonction danonymisation FOIN est utilise deux niveaux : une premire fois dans les hpitaux, avant de transmettre les donnes mdicales des patients et une deuxime fois, avant larchivage de ces donnes.
Image 2 De la cl Donnes nominatives Image S De la cl Image 1 De la cl Procdure de reconstitution de la cl secrte Cl secrte
Procdure danonymisation

Variables identifiantes et cl secrte Hachage Identifiant anonyme

Figure 3.10 : Procdure FOIN. Nanmoins, le cas o s = 2 est confront aux mmes faiblesses de la procdure du CHU de Dijon. Si en plus, N > 2, les images seront dtenues par N personnes et nimporte laquelle pourra reconstituer la cl (puisquune des deux images ncessaires est prsente dans le logiciel). De plus, la technique de FRD ne rsout que le problme du stockage longue dure. En effet, la clef reste vulnrable au vol par un utilisateur malveillant qui russit la lire ou la copier lorsquil lutilise durant les traitements.

85

3.2.3.4.2 Lanonymisation des donnes sur le cancer en Allemagne

Le RNC (Rpertoire National du Cancer) allemand est un registre pidmiologique fond en 1953. De nos jours, il contient les donnes de plus de deux millions de patients atteints du cancer. Le but majeur est de pouvoir effectuer des statistiques mdicales et des recherches pidmiologiques sur le cancer. Dans les annes quatre-vingt, et pour des raisons techniques, seuls les fichiers centraliss ont t informatiss. Pour chaque cas, les dtails suivants ont t enregistrs : identification personnelle du patient ; tablissement, historique, stade, diagnostic et thrapie ; autres traitements et suivis mdicaux ; historique individuel et familial ; dcs et rsultat de lautopsie. La procdure denregistrement transite par deux tapes et travers deux institutions [Blobel 1996] : Dans un premier temps, un site de confiance rassemble les donnes auprs des mdecins, dentistes et centres de suivi. Les donnes identifiantes sont dabord chiffres par une cl de session IDEA gnre alatoirement. Cette cl est elle-mme chiffre par une cl publique RSA dune longueur minimale de 640 bits. Par ailleurs, et pour permettre une association non-ambigu des informations au fichier du patient, un identifiant anonyme est gnr partir de certaines donnes personnelles du patient. Cet identifiant est en fait gnr par lapplication de la procdure de hachage sens unique MD 5, suivi dun algorithme de chiffrement symtrique (IDEA). Cet identifiant est le mme, sur tout le territoire allemand, pour un patient donn. Le format obtenu est nomm format de chanage. - Le site de confiance transmet au site denregistrement la fois les donnes didentit sous forme chiffre et les donnes pidmiologiques en clair. Le site denregistrement enregistre le fichier dans la base de donnes du NCR et rassemble les donnes appartenant au mme patient. Il procde de la manire suivante : un numro alatoire est ajout lidentifiant, et le rsultat est chiffr par IDEA. Le format obtenu est nomm format de stockage. Sur demande et pour des raisons scientifiques, lexploitation des donnes anonymises du registre est possible, mais restreinte en temps (dure) et en quantit (nombre de fois). Dans certains cas particuliers, un comit de conseil peut autoriser le dchiffrement des donnes identifiantes. Nous commenterons cet exemple aprs avoir prsent celui de la Suisse assez similaire.

3.2.3.4.3 Le traitement statistique des donnes mdicales en Suisse

Du point de vue statistique, il nest pas ncessaire de savoir qui appartient un fichier mdical. Nanmoins, en Suisse, lOffice Fdral des Statistiques (OFS), responsable de la collecte des donnes mdicales auprs des hpitaux, a besoin de reconnatre si deux fichiers diffrents correspondent la mme personne. Limplmentation suisse propose de hacher les identifiants dans les hpitaux avant de les transmettre lOFS ; puis la rception, les donnes mdicales sont chiffres par la cl secrte de lOFS [Jeanneret et al. 2001] (figure 3.11). La premire tape consiste remplacer les donnes didentit par un identifiant personnel, le code anonyme de lien. Les donnes sur lesquelles le calcul repose doivent tre disponibles et constantes dans le temps. Trop de restrictions sur le choix peut conduire des collisions, tandis quune multitude de donnes peuvent tre non disponibles ou, du moins, changer au cours du

86

Chapitre 3 Btir une politique de scurit pour les SICSS

temps. Le choix sest port sur un ensemble minimal didentifiants : la date de naissance, le sexe, le nom et le prnom. Puisque la transformation cryptographique doit tre applique tout le temps et par tous les hpitaux, lutilisation dune cl secrte nest pas la solution la mieux adapte. linverse, lutilisation des empreintes22 (hachage des donnes identifiantes) satisfait mieux ces objectifs, avec linconvnient de ne pas rsister aux attaques par dictionnaires. Il convient donc de chiffrer les donnes didentit, dabord durant la transmission de lhpital lOFS, ensuite dans les bases de donnes. Les tapes de cette procdure sont les suivantes (figure 3.11) : Hachage des variables identifiantes : Hachage[Var-ID] = Empreinte. Gnration en arrire-plan (dans lordinateur de lhpital) dune cl de session : c. Chiffrement de lempreinte avec IDEA en employant c : IDEA [ Empreinte ] c ; et chiffrement de c par la cl publique de lOFS, (note E ) en utilisant lalgorithme RSA : RSA[c]E. Transmission de la cl de session (chiffre), de lempreinte (chiffre) et des donnes mdicales (chiffres) lOFS. la rception, dchiffrement de la cl secrte (de session) c par RSA en employant la cl prive de lOFS note D ; Dchiffrement de lempreinte (avec IDEA et la cl c), et re-chiffrement de cette empreinte avec une cl k (fragmente) pour donner le lien anonyme utilis comme code personnel (code de liaison uniforme) lors du stockage des donnes mdicales au niveau de lOFS.
Donnes identifiantes
Hachage sens unique Transfert de la cl secrte c utilise par l'hpital pour crypter les empreintes

cl secrte c
Chiffrement avec RSA en employant E la cl publique de lOFS

Empreinte
Chiffrement avec IDEA en employant la cl secrte c

H p i t a l C a n t o n

Les donnes brutes sont rcoltes et exploites par les offices cantonaux; vrifications de base

Code de liaison = empreinte crypte

cl secrte c crypte

Empreinte
Dchiffrement suivi dun rechiffrement (uniforme) Chiffrement avec IDEA en employant la cl secrte K (fragmente)

Dchiffrement avec RSA en employant D la cl prive de lOFS

cl secrte c

O F S

Code de liaison uniforme (pour archivage)

Figure 3.11 : Transformation des donnes identifiantes en Suisse. Les solutions allemandes et suisses se ressemblent, cest pourquoi on se contentera de discuter la deuxime. Comparons la procdure suisse et la fonction FOIN de la CNAM-TS :

22 Rappelons quune empreinte a t dfinie dans la section 3.2.3.4.1 (page 81) comme tant un code anonyme qui varie dune identit une autre mais qui est toujours le mme pour un patient donn.

87

les donnes transmises sont chiffres dans la solution suisse, tandis quelles ne le sont pas dans FOIN ; - FOIN utilise la technique Fragmentation-Redondance-Dissmination qui vise, non seulement la confidentialit et lintgrit, mais aussi la disponibilit. Dans la procdure suisse, mme si K est fragmente en plusieurs parties, elle ne peut tre reconstitue quen prsence de toutes les personnes disposant de ces fragments (de K). La reconstitution est faite par un simple ou exclusif K = K1 .. KN Cest donc un cas particulier de FOIN, o on considre N = s (seuil de reconstitution). Par ailleurs, les trois oprations effectues au niveau de lOFS (retrouver la cl secrte c , retrouver lempreinte, et chiffrement avant archivage) ne doivent jamais tre visibles aux utilisateurs de lOFS. Cependant, comment sassurer quelles ne sont jamais enregistres sur aucun support ? Un cheval de Troie oprant pour une personne malveillante, aussi bien interne quexterne, pourrait rcuprer les valeurs de la cl secrte 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 matriel bien protg. Des mcanismes inviolables de contrle daccs, ventuellement matriels, pourront renforcer la protection de ce module de faon ce que seules les personnes de confiance puissent raliser lopration composite calcul ; le serveur dautorisation leur donne les droits correspondants sans quelles puissent lire ou copier, ni lempreinte , ni les cls secrtes K et c ; des droits distribus sont donns aux composants matriels ; chaque composant effectue les oprations qui lui sont destines. Cette analyse montre, les avantages et les faiblesses de chacune des solutions actuelles et renforce notre volont dune dmarche analytique pralable des risques, des besoins, des exigences ainsi que des objectifs de scurit, avant de recourir aux solutions de scurit assurant lanonymisation. Compltons ainsi cette analyse par une tude dtaille dun ensemble de scnarios du domaine mdical. -

3.2.3.5 Scnario 1 : transfert des donnes mdicales

La sensibilit des informations changes entre professionnels de sant (par exemple, le laboratoire danalyses et le mdecin) met en vidence le besoin de confidentialit et dintgrit des donnes transitant sur le rseau de soins. La figure 3.12 schmatise une des solutions qui consiste utiliser un chiffrement asymtrique. Ainsi, en supposant que le destinataire lgitime est le seul disposer de la cl prive, personne dautre ne peut dchiffrer le message transitant par le rseau et ainsi accder aux donnes personnelles en clair.
Professionnel de sant (PS1) (M)C2
Chiffrement avec la cl publique de PS2 Transmission

Professionnel de sant (PS2) [(M)C2] C2-1 = M

Dchiffrement avec sa cl prive

Figure 3.12 : change de donnes chiffres entre professionnels de sant. Si les donnes transmises sont volumineuses, il est prfrable dutiliser un chiffrement hybride, cest--dire : - Du ct de lmetteur : gnrer alatoirement une cl de session, considr comme cl secrte valable pour la transmission en cours ; chiffrer le message avec cette cl de session, et chiffrer cette cl avec la cl publique du destinataire ; enfin mettre la fois le message chiffr et la cl de session chiffre ;

88

Chapitre 3 Btir une politique de scurit pour les SICSS

Du ct du destinataire : dchiffrer la cl de session en utilisant sa cl prive, et dchiffrer par la suite le message avec cette cl de session. Le chiffrement des donnes mdicales transitant sur le rseau est actuellement une pratique courante entre les professionnels de sant, notamment en utilisant S-MIME. Selon la classification donne prcdemment, lobjectif est une anonymisation rversible, tandis que lexigence est la robustesse linversion. -

3.2.3.6 Scnario 2 : unions professionnelles

Le transfert des donnes relatives aux activits des mdecins vers les unions professionnelles se fait des fins dvaluation de lactivit des mdecins. Une premire exigence consiste donc cacher les identits du patient et du mdecin. Toutefois, lanonymat des mdecins doit pouvoir tre lev pour lvaluation de leurs comportements en vue de la qualit de soins. En effet, larticle L4134-4 du code de la sant publique ainsi que larticle 81 de la loi 94-43 [Loi 94] prcisent que les mdecins conventionns exerant titre libral dans la circonscription de lunion sont tenus de faire parvenir lunion les informations mentionnes larticle L. 161-29 du code de la scurit sociale relatives leur activit, sans que ces informations puissent tre nominatives lgard des assurs sociaux ou de leurs ayants-droit ou, dfaut, condition quelles ne comportent ni leur nom, ni leur prnom, ni leur numro dinscription au Rpertoire national didentification des personnes physiques. Ces informations ne sont pas nominatives lgard des mdecins . Ces textes ajoutent que Lanonymat (des mdecins) ne peut tre lev quafin danalyser les rsultats dtudes menes dans le cadre de lvaluation des comportements et des pratiques professionnelles en vue de la qualit des soins . Les objectifs sont alors : lanonymisation inversible de lidentit du mdecin ; seule une autorit habilite valuer les comportements des mdecins pourrait rtablir les identits relles des mdecins ; - lanonymisation inversible des donnes nominatives du patient, seuls les mdecinsconseils de la scurit sociale pourront lever cet anonymat ; en effet, larticle L161-29 du code de la scurit sociale ajoute : seuls les praticiens-conseils et les personnels sous leur autorit ont accs aux donnes nominatives (des patients) issues du traitement susvis, lorsquelles sont associes au numro de code dune pathologie diagnostique . Cette manire de faire vite les risques suivants (au niveau des unions professionnelles) : un utilisateur malhonnte qui tente davoir plus de dtails sur les activits dun mdecin alors que la finalit de son traitement ne le justifie pas ; par exemple, dans le cadre dune tude relative au fonctionnement du systme de sant, il nest pas ncessaire daccder aux identits (respect du principe du moindre privilge) ; - atteinte lintimit des patients dans la mesure o ceux-ci peuvent confier des informations certains professionnels de sant, sans pour autant avoir forcment envie de les communiquer aux autres professionnels de sant ou personnes en charge des traitements au sein des unions. Le scnario dcrit dans cette section est rsum dans la figure 3.13. -

89
Mdecin libral
Evaluation des comportements et pratiques professionnels
Chiffrement des identits des mdecins avec une cl publique (ventuellement fragmente) dune autorit habilite valuer le comportement des mdecins & Chiffrement des donnes nominatives des patients avec une cl publique dune autorit habilite lever leur anonymat (mdecins conseils de la scurit sociale par exemple)

Unions Professionnelles
Chiffrement par la cl publique du DIM

Rapport des activits professionnelles

Dchiffrement par la cl prive du DIM

Dpartement dInformation Mdicale (DIM)

Figure 3.13 : Manipulations des identits au niveau des unions professionnelles.

3.2.3.7 Scnario 3 : Programme de Mdicalisation des Systmes dInformation PMSI

Le Programme de Mdicalisation des Systmes dInformation (PMSI) est un systme danalyse de lactivit des tablissements de sant dont la finalit est lallocation des ressources tout en diminuant les ingalits budgtaires. Le PMSI a t expriment depuis 1983, et gnralis dans les hpitaux publics et privs participant au service public par la circulaire du 24 juillet 1989 [Circulaire 1989] pour lactivit de MCO (Mdecine, Chirurgie, Obsttrique). Son utilisation des fins budgtaires a t formalise par la circulaire du 7 dcembre 1996 [Ordonnance 1996]. Il a t tendu aux tablissements privs par les ordonnances du 24 avril 1996. La circulaire du 9 mars 1998 [Circulaire 1998] a gnralis le PMSI aux tablissements publics ayant une activit de Soins, de Suite et de Radaptation. Une multitude de textes ont t labors pour rglementer le fonctionnement du PMSI. Citons titre indicatif, la loi du 31 juillet 1991 [Loi 1991], le dcret du 27/07/94 [Dcret 1994] ainsi que les arrts des 20/09/1994, 22/07/1996 et 29/07/1998 [Arrt 1998]. Dans la pratique, chaque sjour dun patient donne lieu un recueil standardis de donnes de nature administrative (dates dentre et de sortie, date de naissance, nom et prnom, par exemple) et de nature mdicale (diagnostics, actes cods). Les sjours sont ensuite classs selon lindicateur mdico-conomique Groupe Homogne de Malades (GHM). Les patients dun GHM donn sont considrs comme ayant mobilis des ressources de mme ampleur. Chaque anne une chelle des cots affecte un cot relatif chaque GHM, mesur en points ISA pour Indice Synthtique dActivit. Les donnes du PMSI des tablissements publics sont anonymises, puis transmises semestriellement aux Agences Rgionales de lHospitalisation (ARH) qui les utilisent pour lallocation budgtaire. Celles des tablissements privs sont transmises trimestriellement la CNAM-TS (Caisse Nationale de lAssurance Maladie des Travailleurs Salaris), en attendant de devenir un outil dallocation de ressources. Plus prcisment, tout sjour hospitalier effectu dans la partie court sjour dun tablissement fait lobjet dun Rsum de Sortie Standardis (RSS), constitu dun ou plusieurs Rsums dUnit Mdicale (RUM). Le RUM contient des donnes (administratives et mdicales) concernant le sjour dun patient dans une unit mdicale donne. partir des RUM rcuprs et valids, le Dpartement dInformation Mdicale (DIM) construit le fichier des Rsums de Sortie Standardiss (RSS) laide dun logiciel regroupeur. Les services des statistiques et des tudes pidmiologiques reoivent du mdecin responsable du Dpartement dInformations Mdicales (DIM), les donnes mdicales et administratives figurant sur les Rsums de Sortie Anonymiss (RSA). La procdure gnrale est donne sur la figure 3.14, tandis que les dtails du fonctionnement du PMSI sont donns en annexe B.

90
Informations nominatives (RUM, RSS, dossier mdical, etc.)
Informations nominatives Drogation au secret mdical Validation Statistiques Epidmiologie
Confrontation RSS/dossier Drogation au secret mdical

Chapitre 3 Btir une politique de scurit pour les SICSS

Informations anonymes (sous rserve de drogation) (RSA, RHA, RSAc, etc.)

Mdecins des units de soins

ARH (Agence Rgionale dHospitalisation) CPAM (Caisse primaire de lAssurance Maladie) CNAM (Caisse Nationale de lAssurance Maladie)

DIM

DRASS (Direction Rgionale des Affaires Sanitaires et Sociales)

Mdecins conseils (scurit sociale) Mdecins inspecteurs (sant publique)

Validation externe

Figure 3.14 : Frontires des donnes nominatives, anonymes et anonymisables. tant donn que la finalit du PMSI est purement mdico-conomique (et non pas directement pidmiologique), le besoin est de pouvoir effectuer des trajectoires de soins par le biais dune pseudonymisation ; lobjectif est une anonymisation irrversible ; et les exigences sont un chanage universel (toujours et partout le mme identifiant pour un patient donn) ainsi que la robustesse la rversion et aux infrences (dductives, inductives, abductives, etc.).

3.2.3.8 Scnario 4 : traitement des maladies dclaration obligatoire

Les maladies dont la surveillance est ncessaire la conduite et lvaluation de la politique de sant publique (le SIDA, par exemple), ou qui ncessitent une intervention urgente locale (mningite, cholra, rage) sont des maladies dclaration obligatoire. lorigine, les fichiers des patients sropositifs sont nominatifs23, mais ils sont anonymiss (anonymisation irrversible) avant toute transmission. Les besoins sont divers : prvention, production de soins, veille sanitaire, analyses pidmiologiques, etc. Lobjectif principal est lirrversibilit de la fonction danonymisation. Le chanage universel et la robustesse la rversion et aux attaques par infrence constituent les principales exigences. cet gard, le type de protection doit dpendre des objectifs. En effet, sagit-il dobtenir, anne par anne, un tat exhaustif du nombre de sropositifs pour connatre les tendances et lvolution de lpidmie, ou dvaluer, de faon globale, limpact des actions de prvention ? Sagit-il encore dinstituer une vritable surveillance pidmiologique de lvolution des cas dinfection par le VIH, du stade de la dcouverte de la sropositivit, lapparition ventuelle du SIDA avr ? Dans ce cas, lobjectif est de mesurer de faon fine limpact des actions thrapeutiques et de prvention ncessitant un suivi des cas, en particulier un rapprochement avec le systme de dclaration obligatoire des personnes sropositives. Ce choix dobjectifs comporte des consquences importantes tant sur la nature des donnes susceptibles dtre collectes que sur leur dure de conservation et les liens ventuels avec dautres systmes de surveillance. Il implique en consquence des choix en terme de protection de donnes.
23

Il existe des fichiers directement nominatifs, comportant des informations relatives des personnes sropositives, quil sagisse des dossiers mdicaux tenus dans les services hospitaliers, les cabinets mdicaux, ou les laboratoires, des fichiers de remboursement dtenus par les organismes de scurit sociale ou encore des fichiers constitus par les associations daides aux personnes sropositives. Notons toutefois quil existe des centres de dpistage anonymes dans lesquels il ny a aucune possibilit de retrouver les identits des personnes sropositives.

91

Appliquer lanonymisation la source et disposer de mesures de scurit adquates ne dispensent pas de sinterroger sur la pertinence des autres informations appeles figurer sur la dclaration de sropositivit. Il sagit en particulier, du code postal de rsidence, la profession et lorigine gographique. - Le code postal de domicile : si lobjectif est de mieux cibler les actions de prvention locale, sa collecte semble ncessaire. Nanmoins, la pertinence du recueil de cette donne nest pas ce jour rellement dmontre. En outre, sa collecte et son expiration pourraient tre de nature permettre une localisation gographique prcise surtout dans les petites communes. Ds lors le recueil sous une forme aussi dtaille que le code postal du lieu de rsidence des personnes sropositives peut paratre excessif au regard des objectifs recherchs et il est probablement plus judicieux dutiliser le code du dpartement au lieu du code postal. - La profession : mme si elle peut constituer une indication de la situation sociale des personnes sropositives afin de mieux cibler les actions de prvention, il ne parat pas ncessaire de disposer du dtail de la profession prcise des personnes concernes. Ds lors, une simple mention des catgories socio-professionnelles selon la nomenclature de lINSEE parat tre pertinente. - Lorigine gographique : il serait peut-tre suffisant de mentionner si la personne est originaire dun pays o la transmission htrosexuelle est prdominante ou si elle a eu des relations sexuelles avec une personne originaire ou ayant vcu dans un pays o la contamination htrosexuelle est prdominante. Actuellement en France, il semble que le but est dassurer un suivi des cas et de mesurer lvolution du SIDA. Il est donc ncessaire de collecter des donnes individualises afin de permettre de dtecter les doublons, de vrifier les donnes auprs des professionnels de sant, etc. En ce qui concerne lappauvrissement des donnes, lInstitut de Veille Sanitaire a montr que lutilisation dinformations indirectement nominatives figurant sur les dclarations du SIDA (initiales du nom et prnom, date de naissance, dpartement de domicile) permet de reprer plus de 99% des doublons (la suppression des initiales rduirait ce chiffre 20% de doublons). Un appauvrissement trop important des donnes peut donc fausser les statistiques et remettre en cause la fiabilit scientifique de la surveillance pidmiologique.

3.2.3.9 Scnario 5 : traitements des donnes statistiques

En aucun cas, les donnes mdicales caractre personnel ne peuvent tre manipules pour des traitements des fins non-pidmiologiques, en loccurrence, des traitements purement statistiques ou des fins de publications scientifiques. cet gard, non seulement ces donnes doivent tre anonymises, mais il doit tre impossible de les r-identifier. Ainsi, simposent lirrversibilit de lanonymisation ainsi que la robustesse aux infrences. En effet, mme aprs anonymisation, les identits peuvent tre dduites par un statisticien en combinant plusieurs requtes ou en compltant son raisonnement par des hypothses ou par des informations externes au systme. Pour illustrer ce type dattaques, tudions un exemple extrait de [Cuppens 2003]. Soit une base de donnes relationnelles, interroge sous SQL, et contenant la relation Analyse(Patient, H/F, Age, Mutuelle, Leucocyte). Pour un patient donn, Analyse fournit : - des informations dordre administratif, savoir sil sagit dun homme ou dune femme (attribut H/F), son ge (attribut ge) et le nom de sa mutuelle (attribut Mutuelle), - les rsultats danalyses mdicales, savoir lattribut leucocyte, qui donne pour chaque patient son taux de leucocytes par mm3 de sang. Pour simplifier la prsentation de lexemple, nous considrons seulement cet attribut leucocyte, mais la dmarche que nous prsentons sappliquerait naturellement pour driver dautres rsultats dune analyse mdicale (par exemple taux dhmoglobine, plaquette, ure, sucre, etc.).

92

Chapitre 3 Btir une politique de scurit pour les SICSS

Le tableau 3.6 donne lexemple dinstance de la relation Analyse que nous considrerons dans la suite.
Patient Dupont Durand Dulac Duval Dubois Dumont Dupr Dupuis Dufour Dumas H/F H F F H H H F F H H 30 25 35 45 55 38 32 50 45 40 Age Mutuelle MMA LMDE MMA IPECA MGEN MMA IPECA MGEN MAAF Rempart Leucocyte 6000 3000 7000 5500 3500 7500 7200 6800 4000 3800

Tableau 3.6 : Instances de la relation Analyse. Une base de donnes statistiques (dans le contexte de la scurit) est une base de donnes qui permet dvaluer des requtes qui drivent des informations dagrgation (par exemple, les moyennes) mais pas des requtes qui drivent des informations particulires, en loccurrence, des informations relatives une personne donne. Par exemple, si on considre la relation prsente dans le tableau 3.10, la requte quelle est la moyenne du taux de leucocytes des patients ayant plus de 30 ans ? va tre permise alors que la requte quel est le taux de leucocytes de Dupont ? ne le sera pas. Le problme associ ce type de base de donnes rside en ce quil est souvent possible de faire des infrences partir de requtes autorises pour dduire des rponses des requtes 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 dun nombre suffisant de statistiques . Cest un cas particulier important de dduction dinformations sensibles par infrence. Supposons, par exemple, quun utilisateur U soit autoris effectuer des requtes statistiques (uniquement) et envisage de dcouvrir le taux de leucocyte de Dubois. Supposons galement que U sache par ailleurs que Dubois est un adhrent masculin de la MGEN. Considrons maintenant les requtes 1 et 2 suivantes : 1) SELECT COUNT (Patient) FROM Analyse WHERE H/F = H AND Mutuelle = MGEN ; Rsultat : 1. 2) SELECT SUM (Leucocyte) FROM Analyse WHERE H/F = H AND Mutuelle = MGEN ; Rsultat : 3500. La scurit de la base de donnes a t clairement compromise, mme si lutilisateur U a mis uniquement des requtes statistiques autorises. Comme le montre lexemple, si lutilisateur peut trouver une expression boolenne qui identifie un certain individu, alors les informations concernant cet individu ne sont plus scurises. Ce fait suggre que le systme doit refuser de rpondre une requte pour laquelle la cardinalit de lensemble des statistiques est infrieure une certaine borne b . De mme, il suggre que le systme devrait galement refuser de rpondre si cette cardinalit est suprieure une borne N - b (o N est la cardinalit

93

de la relation initiale) parce que la compromission ci-dessus peut galement tre obtenue partir de la suite de requtes 3-6 suivantes : 3) SELECT COUNT (Patient) FROM Analyse Rsultat : 10. 4) SELECT COUNT (Patient) FROM Analyse WHERE NOT (H/F = H AND Rsultat : 9 ; 10 - 9 = 1. 5) SELECT SUM (Leucocyte) FROM Analyse Rsultat : 54300. 6) SELECT SUM (Leucocyte) FROM Analyse WHERE NOT (H/F = H AND Rsultat : 50800 ; 54300 50800 = 3500.

Mutuelle = MGEN) ;

Mutuelle = MGEN) ;

Malheureusement, se contenter de restreindre les requtes celles pour lesquelles lensemble des statistiques possde une cardinalit c telle que b c N - b nest pas une solution pour viter la compromission en gnral. Dautres exemples peuvent tre trouv dans [Cuppens 2004]. La rfrence [Denning 1979] montre que, pour pratiquement toutes les bases de donnes statistiques, un traceur global peut toujours tre trouv. Un traceur global est une expression boolenne qui peut tre utilise pour trouver la rponse toute requte non-autorise, cest-dire une requte faisant intervenir une expression inadmissible. Ainsi la scurit dans les bases de donnes statistiques est un problme rel. Plusieurs suggestions apparaissent dans la littrature, mais il est difficile de dcider si lune dentre elles est vraiment satisfaisante. Par exemple, une solution serait la permutation des donnes, cest-dire les valeurs des attributs des n-uplets sont permutes de sorte que la prcision globale de la statistique est conserve. Mais mme si une valeur particulire (par exemple, un taux de leucocytes particulier) est identifie, il nexiste aucun moyen de savoir quel individu appartient cette valeur. La difficult inhrente cette approche rside dans la recherche des ensembles dentres dont les valeurs peuvent tre permutes de cette faon. Une autre solution pourrait tre le brouillage, qui consiste modifier les rponses aux requtes statistiques en y ajoutant du bruit alatoire pour rendre plus difficile le recoupement entre requtes.

3.2.3.10 Scnario 6 : tudes pidmiologiques focalises

Le PMSI traite des informations mdico-administratives, conomiques et statistiques, afin de raliser des analyses pertinentes des bases de donnes rgionales et nationales (voir annexe B). Naturellement, les donnes traites sont anonymes, et mme si elles sont souvent chanables, il ny a gnralement aucun moyen de lever lanonymat. linverse, dans dautres types dtudes, il est souvent souhaitable de revenir lidentit relle des patients afin damliorer la qualit des soins. Prenons titre dexemple, certaines tudes pidmiologiques focalises : protocoles de recherche en cancer, maladies gntiques ou maladies rares (dites aussi orphelines). Si, par exemple, ces tudes pidmiologiques mettent en vidence la situation suivante : les patients de la catgorie C ayant subi certains traitements T avant ont une esprance de vie considrablement rduite sils ne suivent pas le traitement T recouvrement. Dans de telles

94

Chapitre 3 Btir une politique de scurit pour les SICSS

situations, il faudra remonter aux identits relles pour que les patients puissent profiter de ces rsultats. Il sagit ainsi dune anonymisation inversible, cest--dire un chiffrement avec une cl (secrte), de telle sorte que seules des personnes habilites lever lanonymat (mdecins conseils, mdecins inspecteurs, mdecins traitants) dtiennent la cl de dchiffrement, et seulement quand cest ncessaire (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 (sil existe), enfin, selon le protocole, le patient est enregistr dans un registre rgional, national, voire international. Les tudes pidmiologiques et statistiques faites sur ces registres peuvent dgager de nouveaux rsultats concernant les patients dun certain protocole. Dans le but de raffiner les tudes et faire avancer la recherche scientifique, il est parfois utile de remonter aux identits relles des patients pour les identifier, faire des recoupements entre plusieurs donnes dj recueillies, et les complter a posteriori. Dans le cas de maladies gntiques, les tudes se font sur des donnes mdicales anonymises. Toutefois, si de nouveaux rsultats sont dcouverts, il est envisageable de remonter aux identits des patients, voire de leurs familles pour leur faire de nouveaux tests, ou de leur faire suivre de nouveaux traitements. Le principe est le mme pour les maladies orphelines.
Etudes pidmiologiques, diagnostiques et statistiques en anatomopathologique (protocoles de recherche sur le cancer, maladies orphelines ou gntiques, etc.)

Centre de recherche Laboratoires danalyses Centre dinformation et de statistiques en anatomie pathologique

Hpitaux

Etudes pidmiologiques focalises

Cliniques

Mdecins
Anonymisation inversible :

Echange de donnes anonymes

Possibilit de lever lanonymat dans des cas spcifiques visant un objectif global damlioration des soins

Figure 3.15 : Anonymisation dans le cadre des tudes pidmiologiques focalises.

3.2.3.11 Une nouvelle solution gnrique 3.2.3.11.1 Schma gnral

Les avantages et les faiblesses des diffrentes procdures danonymisation qui existent dans les pays europens ont t discuts. Par ailleurs, on a montr, travers des scnarios, que toute anonymisation ncessite une tude pralable judicieuse, identifiant de manire claire et explicite les besoins, les objectifs ainsi que les exigences de scurit atteindre. cet gard, la fonction danonymisation doit tre adapte aux diffrents composants de la dmarche prsente. Cette analyse a permis daboutir une solution qui peut aider les diffrents acteurs en informatique de sant mieux dfinir les objectifs et exigences en ce qui concerne lanonymisation des identifiants des personnes, et proposer des solutions adaptes aux attentes. La figure 3.16 schmatise notre proposition [Abou El Kalam et al. 2003c, Abou El Kalam et al. 2004a, Abou El Kalam et al. 2004b].

95
Hpital
BD Administrative

Centre de traitement
Le projet Proja

Utilisateur final

(Donnes identifiantes, Numro local de sjour)

Kphosp

DB pour Proja

IDProja
Carte VITALE

'
IDpat

T2-1 :

(IDA (pat|Proja), Donnes mdicales pour Proja)

T3

DB pour Userx

Identifiant anonyme spcifique chaque utilisateur + Donnes filtres

T1 : IDApat|Proj = H(IDproj | IDpat)

Kshosp
BD anonyme pour Proja

IDApat|Proj = [IDAhosp(pat|Proj)] Kphosp

{IDApat|Proj} Kshosp DB Mdicale

T2 :

(IDAhosp(pat|Proja), Donnes mdicales pour Proja)

BD anonyme pour Projb

Le projet Projb DB pour Projb

DB pour UserY

'
T2-1

(Numro local de sjour, Donnes mdicales)

T1 ; T2

T3

Lgende : (T1) Hachage : (T2) Chiffrement ' : (T2-1) Dchiffrement : (T3) Filtrage

Figure 3.16 : Procdure danonymisation propose. Dtaillons les traitements effectus ainsi que les vues disponibles au niveau des hpitaux, des centres de traitements et des utilisateurs finaux.

3.2.3.11.2 Transformations au niveau des tablissements de soins

lhpital, trois types de bases de donnes peuvent tre distingues : une base de donne administrative accessible par les personnels administratifs, chacun selon ses fonctions ; une base de donne mdicale dont laccs est restreint aux personnels soignants (en charge des patients) ; ainsi que des bases de donnes anonymes, chacune contient les informations ncessaires et suffisantes pour un projet donn. Un projet dsigne une entit de traitement des donnes anonymes tel le PMSI, le DIAM (Dispositif Informationnel de lAssurance Maladie), les associations de personnes diabtiques, les centres des tudes cliniques, etc. Le passage de la base de donnes mdicale une base anonyme (destine un certain projet) ncessite lapplication de deux transformations, T1 et T2, aux donnes transfrer. La transformation T1 : consiste obtenir IDApat|Proj, un identifiant anonyme par personne et par projet, partir des deux identifiants : - IDproj, lidentifiant du projet, qui est dtenu par les tablissements de soins (hpitaux, cliniques) ; - IDpat, lidentifiant anonyme unique et individuel du patient, nous suggrons que cet identifiant soit dtenu par le patient sur la carte Vitale24 ; une longueur de 128 bits nous parat suffisante pour viter des collisions (risque que deux personnes diffrentes aient le mme identifiant). Au niveau de lhpital, et lors de lalimentation des bases de donnes anonymes (par projet), lutilisateur (employ de lhpital par exemple) envoie IDproj (lidentifiant du projet concern

24 Mme si la carte Vitale appartient lassur et donc peut correspondre plusieurs personnes (lassur et ses ayants-droits), lidentifiant IDpat est individuel. Ds lors, sur une mme carte peuvent figurer plusieurs identifiants correspondants lassur et aux ayants-droit de moins de seize ans. Ceci sous entend un dispositif de classification de ces identifiants (par numro dordre par exemple).

96

Chapitre 3 Btir une politique de scurit pour les SICSS

par la base de donne) la carte ; celle-ci contient dj IDpat (lidentit du patient donnant son consentement pour lexploitation de ses donnes mdicales par le projet). La procdure T1 consiste appliquer une fonction de hachage (MD5 ou SHA par exemple) (IDproj | IDpat), la concatnation de IDproj) et IDpat : (T1) IDApat|Proj = H(IDproj | IDpat)

La transformation T1, ralise au sein de la carte Vitale du patient, et produisant lempreinte H(IDproj | IDpat), vise les objectifs suivants : un patient napparat dans une base de donne anonyme que si cela est obligatoire (par exemple pour le PMSI) ou sil donne son consentement travers la fourniture de son identifiant (pour une tude de nature mdico-commerciale, par exemple) ; - lidentifiant anonyme IDA pat|Proj nutilise aucun secret dont la divulgation porterait atteinte la vie prive des autres personnes (contrairement lutilisation dune cl secrte commune pour tous les patients). De plus, puisque le calcul de lempreinte IDApat|Proj seffectue au niveau de la carte, ID pat reste toujours au sein de la carte ; il nest jamais stock isolement ; et il nest utilis que pour crer une entre dans la base anonyme pour un projet donn (au niveau de lhpital) ; - puisque IDproj est spcifique chaque projet, les risques de rapprochements non-autoriss des donnes de deux projets diffrents sont carts, ou du moins sont peu vraisemblables ; de plus, les bases de donnes anonymes (par projet) sont isoles de lextrieur de lhpital et sont soumises des mesures strictes de contrle daccs ; - il est possible que chaque projet puisse faire des rapprochements de donnes concernant un mme patient (car pour un patient donn et un projet donn, lempreinte IDApat|Proj est toujours la mme). Nanmoins, la transformation T1 ne permet pas de se prmunir contre certaines attaques o les intrus essayent de faire des rapprochements dinformations (concernant un projet donn) dtenus par deux hpitaux diffrents. En effet, supposant que le patient Paul a t trait Rangueil et Purpan, et que dans chacun de ces deux hpitaux, Bob est consentant de lutilisation de ses donnes pour un projet Proj. Supposant quun employ de Purpan, nomm Bob, sait que lempreinte X (=IDAPaul|Proj) correspond Paul. Supposant en plus, que Bob arrive semparer de la base de donne anonyme, concernant le projet Proj, et dtenue par Rangueil. Dans ce cas, lutilisateur malveillant Bob peut facilement tablir le lien entre le patient Paul et ses donnes mdicales (concernant le projet Proj) dtenues par Rangueil (mais aussi celles dtenues par Purpan, puisque Bob travaille Purpan). Afin de contrer ce type dattaques, nous introduisant la transformation asymtrique T2 a u niveau de lhpital. Ainsi, avant de stocker les donnes dans les bases de donnes anonymes spcifiques chaque projet, lhpital chiffre (chiffrement asymtrique) lidentifiant IDApat|Proj avec une cl Kshp spcifique lhpital ; ({}K dsigne un chiffrement avec K) : (T2) IDAhp(pat|Proj) = {IDApat|Proj} Kshp

Si on reprend le scnario prcdent, lutilisateur malveillant Bob ne peut revenir aux identits des personnes car il ne dispose pas de la cl de dchiffrement KpPurpan. En effet, chaque hpital dtient sa cl Kshp, tandis que Kphp nest dtenue que par les projets.

97

Les deux transformations (T1 et T2), effectues au niveau des hpitaux, permettent davoir une grande robustesse vis--vis dattaques ayant pour but de lever lanonymat (ou de faire des rapprochements) de faon non autorise. Pour autant, la procdure propose reste assez flexible. En effet, si deux hpitaux (hpa et hpb) dcident de fusionner un jour, il est tout fait possible de relier les donnes concernant chaque patient ; que ces donnes proviennent de hpa ou de hpb. Il suffit que chaque hpital dchiffre ses donnes avec sa cl Kphp, puis chiffre le rsultat avec la cl prive K s h pab du nouvel hpital. Si I D Ahpa(pat|Proj) (respectivement IDAhpb(pat|Proj )) dsigne un identifiant anonyme au sein de lhpital hpa (respectivement hpb) ; []K dsignant le dchiffrement avec la cl K : - Le traitement effectu sur les anciennes donnes de lhpital hpa est : { [IDAhpa(pat|Proj)] Kphpa} Kshpab ; Le traitement effectu sur les anciennes donnes de lhpital hpb est, { [IDAhpb(pat|Proj)] Kphpb} Kshpab ;

Ainsi, les codes de liaisons obtenus seront les mmes dans les deux tablissements (pour chaque base de donne anonyme associ un certain projet). Pour les utilisateurs internes aux tablissements de soins, les mcanismes de contrles daccs doivent interdire tout accs non-autoris, tandis que des mcanismes de dtection et de tolrance aux intrusions doivent renforcer les autres mesures de scurit.

3.2.3.11.3 Transformations au niveau des centres de traitements

Les donnes contenues dans les bases de donnes anonymes (au niveau des tablissements) subissent des transformations qui dpendent de lidentifiant anonyme IDA proj|pat et de la cl Kshp. Pour retrouver les donnes qui lui sont destines, chaque centre de traitement (correspondant un projet) dchiffre les donnes qui lui sont envoyes par la cl Kphp de lhpital transmetteur : [IDAhp(pat|Proj)] Kphp et daprs (T2), = [ {IDApat|Proj} Kshp ] Kphp = IDApat|Proj Le centre de traitement retrouve ainsi les informations suffisantes et ncessaires aux traitements quil effectue. Ces informations sont associes aux identifiants anonymes IDApat|Proj, ce qui permet chaque projet de chaner les donnes de chaque patient. Par ailleurs, avant leur distribution aux utilisateurs finaux (recherche scientifique cibles, publications, Web, presse), et afin de respecter le plus possible le principe du moindre privilge, les informations transfres peuvent ventuellement subir un traitement de filtrage cibl pour chaque catgorie dutilisateurs. Il peut, par exemple, sagir dune agrgation, dun appauvrissement des donnes, etc. Si de plus, lobjectif de scurit est dinterdire deux (ou plusieurs) utilisateurs finaux de recouper les informations, il convient dappliquer une autre anonymisation (hachage, avec MD5 par exemple) avec une cl secrte Kutil|proj. IDApat|util = H(IDApat|Proj | Kutil|proj) Dans ce cas, si le but est de permettre lutilisateur de faire des chanages dans le temps (par projet), la cl Kutil|proj doit tre stocke au niveau du centre de traitement, de faon pouvoir la rutiliser, chaque fois que celui-ci souhaite transmettre dautres informations cet utilisateur. linverse, si le centre souhaite empcher le chanage dans le temps par les utilisateurs, la cl est gnre alatoirement chaque distribution.

98

Chapitre 3 Btir une politique de scurit pour les SICSS

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 nonobligatoire, mais souhaitable, de ses donnes ; - les cls et identifiants utiliss dans les diverses transformations (ID proj , ID pat , Ks hp , Kphp, IDApat|Proj et IDApat|util) sont dtenus par des personnes diffrentes, et dans des endroits diffrents : IDproj ne concerne quun projet parmi dautres ; IDpat est spcifique un patient, et cette information nest connue que par lui ; Kshp est spcifique lhpital ; et IDApat|util nest destine qu un utilisateur (ou type dutilisateur) dun projet donn. Il est donc pratiquement impossible de pouvoir faire des dsanonymisations non autorises ; - la solution rsiste aux attaques par dictionnaire et tous les niveaux : tablissements de soins, centres de traitements, et utilisateurs finals ; - la squence danonymisation (anonymisation en cascade) que nous proposons diffrents niveaux, combine avec des mcanismes de contrles daccs, permet de garantir, en toute robustesse, lexigence de non inversibilit ; - les identifiants anonymes gnrs tant spcifiques un secteur particulier (projet, domaine dactivit, centre dintrt, branche professionnelle, tablissement, etc.), il est possible dadapter la solution chaque secteur (par exemple lorsque le centre de traitement est le seul utilisateur) ; - il est possible de fusionner les donnes de deux (voire de plusieurs) tablissements sans compromettre la flexibilit et la scurit ; - la manire selon laquelle linformation est distribue et utilise par lutilisateur final est importante. Notre solution peut tre adopte pour tenir compte de la finalit du traitement ; - si un utilisateur final (chercheur dans le domaine des maladies orphelines par exemple) dcouvre une information qui ncessiterait de remonter aux identits des patients, il doit renvoyer ses rsultats lhpital qui, lui seul (par lintermdiaire du professionnel soignant par exemple), peut tablir le lien entre les variables identifiantes, les numros locaux de sjours, et les donnes mdicales de ses patients. Par ailleurs, nous pensons que la solution idale nexiste pas, et nous suggrons de complter notre solution, selon le cas tudi, par une combinaison de solutions techniques et organisationnelles : - laccs aux donnes doit tre parfaitement contrl. Une politique de contrle daccs doit tre dfinie et mise en place pour que les donnes ne soient accessibles quaux seuls utilisateurs habilits ; - la spcification du systme dinformation et de larchitecture du rseau doit obir une politique globale de scurit, et donc doit tre adapte aux besoins ; - La dfinition de la politique de scurit doit inclure une analyse approfondie des risques dabduction ; - la constitution de sous-bases de donnes rgionales ou thmatiques doit tre contrle. - Il convient dutiliser (si cela est possible) des anonymisations thmatiques, de sorte que mme si un utilisateur parvient casser lanonymisation, les risques dabduction soient limits un thme donn ; - Il faut sparer les donnes didentit des renseignements proprement mdicaux. Bien entendu ce mcanisme ne peut tre appliqu que dans des contextes particuliers. Un exemple est donn dans lannexe B ; -

99

Nous prconisons lutilisation de solutions complmentaires comme lappauvrissement des donnes ; - Il faut surveiller les utilisations qui sont faites des donnes, en dfinissant et en mettant en uvre des outils de dtection dintrusion ; en particulier, ces outils doivent permettre de dtecter les requtes, voire les enchanements de requtes, ayant un but malveillant (infrence de donnes, abus de pouvoir, etc.) ; - nous prconisons galement lutilisation dautres techniques comme le brouillage ou le filtrage, de faon ne pas rpondre des requtes statistiques si linformation demande est trop prcise ; etc. Dans cette section, nous avons analys le problme danonymisation dans le domaine mdical et nous avons propos des solutions flexibles et adaptes aux besoins, objectifs et exigences de scurit de ce domaine. Compte tenu de la ressemblance entre la nature, la structure, et le fonctionnement des domaines mdical et social, nous pouvons constater que cette dmarche est tout fait applicable dans la sphre sociale. Par ailleurs, les donnes anonymises (ou anonymes) doivent tre recenses comme sensibles et donc doivent tre intgrs dans la description de la politique de scurit. Ainsi, avec des donnes nominatives ou non, on revient au problme global qui est la dfinition et la spcification de la politique de scurit. Rappelons que dans la premire section de ce chapitre nous suggrons une mthodologie pour tablir des politiques de scurit. La premire tape consiste obtenir certains lments de description structurels (comme les rles) ou fonctionnels (comme les processus), identifier de manire explicite les informations protger (anonymes ou pas), et caractriser les menaces (altration, infrence, etc.). La deuxime tape sappuie sur ces descriptions pour formuler les objectifs de scurit en terme de confidentialit, dintgrit et de disponibilit des ressources et services de lorganisation. Un rglement de scurit vient ensuite dcrire comment lorganisation fonctionne tout en satisfaisant les objectifs de scurit tracs. -

Chapitre 4. Le modle Or-BAC

Prambule
Dans le chapitre prcdent, nous avons propos une mthode permettant de dfinir une politique de scurit pour des organisations complexes en gnral et pour les SICSS en particulier. Nous avons appliqu notre mthodologie diffrents scnarios des domaines social et mdical. Nous avons galement exprim le besoin de modliser la politique de scurit, notamment pour contribuer au processus de preuve et de vrification, ncessaire pour avoir une confiance leve dans le systme. Aprs avoir rappel les lacunes des politiques et modles de scurit existants, ce chapitre commence par prsenter les concepts ncessaires pour exprimer des politiques de scurit pour des systmes complexes, coopratifs et distribus comme les SICSS. Le but tant de : - tenir compte du contexte et de linteroprabilit, - prendre en compte toute amlioration, changement ou mise jour des lments en relation avec la scurit, - raliser un bon compromis entre le respect du principe du moindre privilge et la flexibilit du contrle daccs, de faon ne pas gner le travail du personnel, tout en respectant les droits des usagers. Ensuite, nous imbriquons ces concepts pour construire le modle Or-BAC, dont une reprsentation entit-relation a t dveloppe dans le cadre du projet MP6 [Abou El Kalam et al . 2003a]. Le concept dorganisation est central dans Or-BAC. Celui-ci nutilise que des entits abstraites pour exprimer la politique de scurit, sans se soucier la manire selon laquelle les diffrentes sous-organisations implmentent et instancient ces entits (rles, groupes, activits, contexte). Cette faon de procder rduit considrablement la complexit de la spcification de la politique de scurit, offre plus de flexibilit et facilite linteroprabilit des composants du systme ou de lorganisation, sans pour autant compromettre la scurit. Par ailleurs, Or-BAC nest pas restreint aux permissions, mais permet galement de dfinir des interdictions, des obligations et des recommandations. La deuxime partie de ce chapitre prsente le modle Or-BAC en utilisant une notation UML [Abou El Kalam & Deswarte 2004].

102

Chapitre 4 Le modle Or-BAC

4.1. Motivation
Les politiques et modles de scurit qui existent dans la littrature (et que nous avons dcrits dans le chapitre prcdent) ne prennent pas en compte les points suivants : - des rgles qui spcifient des permissions ou des interdictions contextuelles ; pourtant, dans le domaine mdical, les professionnels de sant ont des permissions spciales dans des contextes spcifiques comme lurgence ; de mme, les personnes autorises peuvent, dans certains cas (chance par exemple), forcer laccs Net-entreprises, pour prparer ou valider les dclarations, ou pour effectuer des tlpaiements ; - des rgles qui spcifient des obligations ou des recommandations : les modles et politiques de contrle daccs classiques sont gnralement limits aux permissions ; certains incluent des interdictions, et plus rcemment quelques modles de politique de scurit 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 rgles spcifiques lorganisation ; en particulier, lorganisation peut tre structure en plusieurs sous-organisations, qui ont chacune leur propre politique de scurit : le systme de sant est organis en plusieurs domaines (mdical, paramdical, recherche, etc.), le domaine mdical regroupe les hpitaux, les cliniques et les mdecins libraux, chaque hpital est organis en services, etc. ; la politique de scurit devra ainsi proposer un cadre homogne, permettant de spcifier plusieurs politiques de scurit au sein dune mme organisation ; il est vident que chaque structure de la sphre sant-social doit implmenter sa propre politique interne de scurit tout en respectant lensemble des contraintes imposes par la politique globale de scurit. La section suivante prsente un ensemble de concepts permettant de spcifier une politique de scurit capable de prendre en compte ces diffrents points, et supporter ainsi la richesse, la complexit et lhtrognit des SICSS. En outre, nous tenons prciser que ce mmoire ne dcrit pas la version initiale du modle Or-BAC (reprsentation 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 dontique [Abou El Kalam & Deswarte 2004] sera prsente ici. Celle-ci nous semble plus dtaille et plus riche en expressivit.

4.2. Concepts de base du modle Or-BAC

4.2.1. Organisations
Lorganisation est lentit centrale des politiques et modles de scurit que nous proposons. Dans le domaine mdical, nous pouvons considrer les organisations : clinique du Languedoc, quipe de lunit des soins intensifs de lhpital Rangueil, etc. De la mme manire, dans le secteur social, les tablissements, les entreprises ainsi que les organismes de protection sociale, sont des exemples dorganisations. Une organisation peut tre dfinie comme une entit ayant un rle professionnel ou statutaire bien dfini, ou encore, un groupe structur dentits actives, cest--dire de sujets (utilisateurs, quipes, ou autres) jouant certains rles (figure 4.1). Il est important de noter quun groupe quelconque de sujets nest pas ncessairement considr comme une organisation. Autrement dit, le fait que chaque sujet joue un rle dans lorganisation correspond un certain accord entre les sujets pour former une organisation.

103

La figure 4.1 exprime que les utilisateurs et les organisations sont considrs comme des sujets (entits actives), et quils peuvent ce titre, jouer des rles. La figure 4.2 donne lexemple dun utilisateur Jean qui joue le rle cardiologue, et de lorganisation US21 qui joue le rle unit de soins intensifs. De la mme manire, dans le cadre de Net-entreprises, les rles personne inscrite, personne non-inscrite, administrateur, mandataire social, dirigeant et personne autorise, sont jous par des utilisateurs, tandis que les rles tablissement dclar, tiers dclarant sont jous par des organisations.
Sujet
joue

Rle

Utilisateur

Organisation

Figure 4.1 : Relation dhritage entre les organisations et les sujets.

Jean : Utilisateur :: Sujet US21 : Organisation :: Sujet
joue joue

Cardiologue : Rle Unit de soins intensifs : Rle

Figure 4.2 : bauche dun diagramme dobjets reprsentant les rles jous par les sujets.

4.2.2. Rle dans Organisation (RdO)

Le contrle daccs bas sur les quipes, C-TMAC (section 2.7, page 55), considre deux relations binaires (utilisateur, rle) et (utilisateur, quipe). Un utilisateur peut donc activer nimporte lequel de ses rles dans nimporte laquelle de ses quipes. Dans la pratique, mme si un utilisateur a le droit de jouer plusieurs rles, il na pas forcment le droit de les jouer dans nimporte laquelle de ces quipes. Le modle Or-BAC traite ce problme en ajoutant la notion de rle dans organisation note RdO. La figure 4.3 illustre lexemple dun utilisateur Pierre qui joue les RdO infirmier lhpital de Purpan, radiologue assistant lhpital de Rangueil, mais pas forcment radiologue assistant dans Purpan, ni infirmier dans Rangueil. Selon une modlisation C-TMAC, ces rles pourraient tre autoriss, mme sils ne sont pas conformes la ralit.
Infirmier:Rle Purpan:Organisation InfirmierDansPurpan :RdO Assistant:Rle Rangueil:Organisation AssistantDansRangueil :RdO

Pierre:Utilisateur

Pierre:Utilisateur

Figure 4.3 : bauches de diagrammes dobjets reprsentant des instances de RdO. Nous avons fait le choix de reprsenter lentit RdO par une classe-association. En effet, dune part, un RdO est une association entre le rle et lorganisation, et dautre part, il a des attributs, notamment les identifiants du rle et de lorganisation. Un RdO possde les caractristiques dune classe et dune association, et peut ce titre, participer dautres relations, en loccurrence la relation qui associe les utilisateurs aux RdO (figure 4.4).

104

Chapitre 4 Le modle Or-BAC

Rle

Organisation

RdO
Utilisateur
Joue 0..n 0..n

Id_Organisation Id_Rle

Figure 4.4 : bauche du diagramme de classe reprsentant la classe association RdO.

4.2.3. Vue dans Organisation (VdO)

Dans le modle Or-BAC, les objets reprsentent des entits non actives comme les fichiers, les formulaires imprims, etc. Dans le domaine mdical, nous avons ainsi considrer des objets comme les dossiers administratifs ou les dossiers mdicaux des patients. Nous avons dj expliqu que les rles sont des entits abstraites qui permettent de structurer les sujets et de faciliter la mise jour de la politique de scurit quand un nouvel utilisateur est ajout. Dans la mesure o il est galement ncessaire de structurer les objets et dajouter de nouveaux objets au systme, nous considrons quune entit (abstraite) comparable au rle pour les sujets est ncessaire pour les objets. Nous lappelons vue. Ainsi, de la mme manire que les sujets ayant une fonction commune sont reprsents dans la politique de scurit par des rles, les objets qui satisfont une proprit commune sont spcifis travers des vues. Les vues sont donc pour les objets ce que sont les rles pour les sujets (figure 4.5).
sujet i
Objet m

...

...

Sujet j

Rle r

Perm p

Action a

Vue v

Objet n

Figure 4.5 : Similitudes entre les rles et les vues. Outre sa nature intuitive extraite du fonctionnement normal des organisations, la notion de vue offre plusieurs autres avantages : - Elle facilite la structuration et permet dabstraire les objets dans la spcification de la politique de scurit. - Elle aide rduire les erreurs dadministration. En effet, des entits comme les rles, et les vues, ainsi que des associations comme (action , vue ) et (rle, permission) restent relativement fixes dans le systme dinformation ; elles sont donc gres par ladministrateur. En revanche, certaines associations comme (objet, vue), par exemple, laffectation de nouveaux dossiers aux vues correspondantes, changent souvent ; elle peuvent ainsi tre gres localement (par le personnel daccueil de lhpital par exemple). - Elle aide rduire les cots dadministration. Le cot des associations (action, objet) (sans passer par la vue) est de lordre de NA*NO, o NA est le nombre dactions et NO est le nombre dobjets. Alors quavec la notion de vue, le cot est NA+NO, et ceci pour chaque vue.

105

Dans la mesure o les vues caractrisent la manire dont les objets sont utiliss dans lorganisation, nous introduisons la classe-association Vue dans Organisation, note VdO, et nous associons les objets aux VdO (figure 4.6).
Vue Organisation

VdO
Id_Organisation

Objet

0..n

0..n

Id_Vue

Figure 4.6 : bauche du diagramme de classe reprsentant la classe association VdO. Cette manire de structurer les organisations, les objets et les vues permet dexprimer quune mme vue peut tre dfinie diffremment suivant lorganisation considre. Le but est de permettre des organisations de donner des dfinitions diffrentes une mme vue. Supposons titre dexemple que lhpital de Purpan utilise un systme de fichiers, et que lhpital de Rangueil utilise une base de donnes ; la vue dossier mdical peut tre dfinie Purpan comme un ensemble de documents textes, tandis qu Rangueil, cette mme vue correspond des attributs ou des tables de la base. Le premier diagramme dobjets de la figure 4.7 exprime que lhpital Purpan utilise le fichier F31.txt comme un dossier mdical, tandis que le deuxime diagramme illustre que lhpital Rangueil utilise la table dossier mdical comme un dossier mdical.
DossMd:Vue Purpan:Organisation DossMd: Vue Rangueil:Organisation

F31.doc:Objet

DossMedDansPurpan:VdO

Table-DossMed:Objet

DossMedDansRangueil:VdO

Figure 4.7 : bauches de diagrammes dobjets reprsentant des instances de VdO.

4.2.4. Activit dans Organisation (AdO)

Les politiques de scurit spcifient les accs aux entits passives accords aux entits actives et rgulent les actions opres sur le systme. Dans notre politique, lentit Action englobe principalement les actions informatiques comme lire, crire, etc. De la mme manire que les rles et les vues sont des abstractions des sujets et des objets, nous dfinissons une nouvelle entit utilise comme abstraction des actions : lentit Activit. Les activits pourront tre lecture, modification, etc. Ainsi, les rles associent des sujets qui remplissent les mmes fonctions, les vues regroupent des objets qui satisfont une proprit commune, et par analogie, les activits correspondent des actions qui ont un objectif commun. Par ailleurs, de la mme manire que nous avons prsent les notions de RdO et VdO, nous introduisons lentit activit dans organisation (note AdO ) comme classes-associations entre les activits et les organisations (figure 4.8). Remarquons que l encore, lobjectif est de permettre des organisations de structurer diffremment les mmes activits. Si nous considrons lactivit lecture, celle-ci peut correspondre, dans lorganisation Purpan, laction lire un fichier, mais peut tout aussi bien correspondre laction select dans Rangueil (figure 4.9).

106

Chapitre 4 Le modle Or-BAC

Activit

Organisation

AdO
Id_Organisation

Action

0..n

0..n

Id_Activit

Figure 4.8 : bauche du diagramme de classe reprsentant la classe association AdO.

Lecture:Activit Purpan:Organisation Lecture: Activit Rangueil:Organisation

Read:Action

LectureDansPurpan:VdO

Select:Action

LectureDansRangueil:VdO

Figure 4.9 : bauches de diagrammes dobjets reprsentant des instances dAdO. Soulignons que le concepteur de la politique de scurit dfinit les rgles avec des entits abstraites (rles, vues et activits), sans se soucier de la manire selon laquelle les organisations du domaine implmentent ou considrent les instanciations de ces entits.

4.2.5. Le contexte
Dune manire gnrale, le contexte peut tre dfini comme toute information qui caractrise la situation dune entit ou qui spcifie les circonstances concrtes dans lesquelles les organisations accordent des permissions des rles pour raliser des activits sur des vues. En loccurrence : qui peut dlguer ? Quand lutilisateur a-t-il le droit daccder une information ? Do laccs est-il possible ? Comment, o et pour quelles raisons, les informations sont-elles disponibles ? Le contexte est ainsi lune des notions utilises par la politique prsente pour mieux respecter le principe du moindre privilge25. Dans le domaine mdical, le contexte permettra dexprimer des notions comme : lurgence, les processus habituels, lexclusion mutuelle, les attributs temporels, etc. En effet, le contexte peut tre vu selon diffrentes facettes, selon quil est reli aux sujets, aux objets ou lutilisation elle-mme. Une tude dtaille concernant lutilisation du contexte dans les applications mdicales peut tre trouve dans [Abou el Kalam & Deswarte 2002] ainsi que dans la norme europenne [CEN 1999].

4.2.5.1 Contexte et contraintes du rle

En gnral, le contexte du rle prcise des valeurs que doivent prendre certaines variables contextuelles pour autoriser, interdire, obliger ou recommander un utilisateur de jouer un rle donn. Par exemple : - instant daccs : le rle mdecin de salle est valide pendant les heures normales de travail tandis que le rle mdecin de garde est valide la nuit ; - cardinalit : cest une contrainte sur le nombre maximal ou minimal dutilisateurs autoriss jouer un certain rle, que ce soit directement ou indirectement ( travers lhritage) ;

25

Ce principe consiste ne donner accs aux utilisateurs autoriss quaux seules ressources dont ils ont besoin pour accomplir leurs tches, et ce, seulement pendant la dure de ces tches.

107

exclusion mutuelle : cette contrainte peut tre statique ou dynamique ; une exclusion mutuelle statique entre deux rles signifie quun utilisateur ne peut jamais jouer ces deux rles, par exemple, dans le mme tablissement, tre personnel soignant et comptable ; une exclusion mutuelle dynamique entre deux rles signifie que lutilisateur ne peut pas jouer les deux rles simultanment, par exemple, mdecin lhpital et mdecin travaillant pour une socit dassurance.

4.2.5.2 Contexte dobjet

Comme les rles, les objets (ou dune manire gnrale les vues) ont des attributs contextuels spcifiques. Par exemple : - la dure de conservation des donnes : donnes de neurologie (70 ans), maladies hrditaires (illimite), etc. ; - le lieu : les dossiers de spcialits de chacune des units sont situs et grs localement dans les ordinateurs de cette unit ; dans certains cas, laccs ce type de dossier ne peut se faire que localement ; de manire gnrale, certaines organisations des SICSS associent leurs objets (donnes, ressources) les emplacements o ils sont situs et grs.

4.2.5.3 Attributs dutilisateurs

Dans la pratique, certains attributs des utilisateurs peuvent tre utiliss pour obliger ou recommander lexcution dune certaine action, interdire ou accorder des autorisations spcifiques ou des droits temporaires. Nous pouvons citer par exemple : - laffiliation un corps de sant rgional, national, ou international ; - lexprience dans la pratique de certains types particuliers de soins comme lacupuncture ; etc.

4.2.5.4 Contexte de lutilisation

Une entit peut tre concrte ou abstraite. Lensemble des entits abstraites de la politique propose peut lui-mme tre partitionn en deux niveaux logiques : un premier niveau contenant les rles, les vues et les activits, et un deuxime niveau schmatisant les coalitions (ou les collaborations). Les organisations en font partie. En ralit, les organisations (les quipes de soins, par exemple) collaborent dans des processus spcifiques. Le contexte dutilisation est un concept innovant qui utilise la notion de processus pour grer les accs normaux, et la notion dobjectif dutilisation pour supporter les exceptions, avec plus de responsabilit. Le but est de raliser un bon compromis entre le respect du principe du moindre privilge et la flexibilit du contrle daccs. Tout accs doit donc tre inscrit soit dans un processus, soit dans une exception dclarant un objectif spcifique de lutilisation prtendue. Les autorisations finales seront ainsi diffrentes selon que lutilisateur aura dclar tel ou tel objectif dutilisation.

4.2.5.4.1 Processus
Dans le cas dun processus de soins, le consentement (explicite ou implicite) du patient est recueilli, et lactivit de soins est enregistre dans le systme par une personne habilite par exemple, le mdecin 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 mdical, diffrents protocoles de processus (processus-types) peuvent tre numrs. Il suffit quune personne habilite instancie un de ces processus, et les

108

Chapitre 4 Le modle Or-BAC

accs sinscriront dans ce cadre. titre dexemple, le processus demande davis neurochirurgical en urgence peut tre constitu des tapes suivantes : - arrive du patient aux urgences o il est accueilli par linfirmire ; - examen clinique par le mdecin urgentiste ; - ralisation dun scanner par un radiologue et un manipulateur radio ; - ralisation des examens de biologie ; - prise en compte des rsultats du scanner et demande davis neurochirurgical ; - le radiologue donne son avis lurgentiste ; - le biologiste donne son avis sur les examens de biologie ; - le neurochirurgien de lhpital distant donne son avis lurgentiste ; - le neurochirurgien de lhpital distant accepte le transfert du patient ; - sortie administrative du patient ; - prparation de laccueil du patient dans le service de neurochirurgie ; - accueil du patient dans le service de neurochirurgie ; - visite au patient et organisation de la prise en charge ; - intervention chirurgicale en neurochirurgie. Par analogie, dans Net-entreprises, systme reprsentatif du secteur social, nous trouvons des processus bien cadrs comme le processus dinscription ou le processus daccs aux services scuriss. Ces processus ont t partiellement dcrits dans la section 3.2.2.1.3, et sont donns plus en dtail dans [GIP 2002b].

4.2.5.4.2 Exception
Dans un cas dexception, cest--dire pour tout accs au systme en dehors dun processus habituel, lutilisateur doit dclarer un objectif dutilisation. Dans le domaine de la sant, ceci correspond des cas non prvus 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 lutilisateur. De mme, dans la sphre sociale, nous pouvons numrer des cas dexception tels que : - lchance (urgence), les personnes autorises peuvent forcer le systme pour prparer ou valider les dclarations ou les paiements via les services de Net-entreprises ; - lors de la slection des dclarations en mode standard, le systme propose la personne autorise une liste de dclarations correspondant au profil de son tablissement ; toutefois, cette liste nest pas limitative et la personne autorise peut forcer certains paramtres ; - il doit tre possible de forcer le niveau26 de scurit pour certains services et dans des conditions trs particulires. Afin de satisfaire les objectifs cits prcdemment (flexibilit et scurit), nous suggrons que le systme effectue deux types de contrles dans le cas dune exception : - un contrle a priori : les rgles de scurit doivent spcifier quel utilisateur (ou rle) a le droit de dclarer quel objectif, et dans quelles conditions ; par exemple si le mdecin est absent (grve, force majeure), tout professionnel soignant peut dclarer lobjectif urgence non habituelle et accder au dossier mdical du patient ; un autre exemple est

26

Les accs Net-entreprises sont paramtrs par trois niveaux de scurit. Si lutilisateur ne possde pas le niveau requis pour un service, laccs lui est refus, sauf dans le cas dexception que nous dcrivons.

109

celui dun mdecin qui a trait autrefois un patient et qui souhaite r-accder son dossier en spcifiant comme objectif rvision du diagnostic ; - un contrle a posteriori : pour plus de flexibilit, le systme peut autoriser certains accs, avec un ensemble minimal de vrifications (contrle a priori) ; pour renforcer la scurit, nous proposons des contrles supplmentaires, qui seront raliss a posteriori, notamment travers les fonctionnalits daudit et ventuellement par des notifications automatiques des patients ou des mdecins traitants ; lanalyse des enregistrements daudit permet de vrifier a posteriori le bien fond des dcisions prises (par exemple, le caractre durgence non habituel) ; cet gard, notre dmarche spcifie ce type de contrle lintrieur de la politique de scurit, au mme titre que les contrles a priori. Notons que certaines contraintes contextuelles dcrites dans ce mmoire, notamment celles sur les rles, peuvent tre vues comme analogues aux contraintes dintgrit dans le domaine des bases de donnes [Godfrey et al. 1998]. Toutefois, les contraintes dintgrit sont des obligations qui valident les oprations aprs leurs excutions (vrification en aval), alors que le contexte que nous dcrivons (sauf le contexte dutilisation) est vrifi avant dautoriser ou non laccs (vrification en amont). Les concepts de base que nous venons de prsenter sont des briques ncessaires et suffisantes pour construire Or-BAC. Dans la section suivante, nous montrons comment les assembler et les relier pour reprsenter la politique de scurit laide de ce modle.

4.3. Reprsentation dOr-BAC en UML

Or-BAC (pour Organization-Based Access Control) est un modle de scurit qui prend en compte la richesse et les particularits des SICSS. Il peut galement tre appliqu une gamme trs large dapplications complexes, interoprables et distribues. Une premire reprsentation dOr-BAC avec un modle entit-relation - laquelle nous avons contribu dans le cadre du projet MP6 - peut tre trouve dans [Abou El Kalam et al. 2003a ; Abou El Kalam et al. 2003b]. Dans ce mmoire, nous proposons une description plus dtaille en utilisant UML. Le modle UML permet de surmonter le manque dexpressivit du modle entit-relation, notamment : la rcursivit, les diffrents types de relations (dpendance, agrgation, hritage), le comportement dynamique, etc. Dans la section prcdente, nous avons prsent les classes associations RdO, VdO et AdO. Selon le besoin et les niveaux dabstraction, ces concepts peuvent servir : - structurer les sujets, les objets et les actions par des entits abstraites ; - identifier les rles, vues et activits prsents dans chacune des organisations du systme ; - spcifier quun utilisateur peut jouer diffrents rles dans diffrentes organisations, mais pas forcment les mmes rles dans chacune de ces organisations ; montrer quune mme vue peut correspondre des objets diffrents selon les organisations ; montrer quune mme activit peut tre implmente diffremment dans des organisations diffrentes ; etc. - masquer la manire selon laquelle les organisations implmentent les activits, instancient les vues ou utilisent les rles. Par ailleurs, Or-BAC considre des permissions, des interdictions, des obligations et des recommandations, et tient compte du contexte dans lequel une requte est faite. La notion de contexte dans organisation, note CdO peut tre dfinie de la mme manire que les RdO, VdO et AdO. Dans le modle Or-BAC, une politique dfinit des rgles du type : dans le CdO c , lorganisation org accorde au RdO r la permission (ou linterdiction ou lobligation ou la recommandation) de raliser lAdO a sur la VdO v . Nous relions ainsi les entits organisation, RdO , VdO , AdO et CdO avec une classe-association note type daccs et

110

Chapitre 4 Le modle Or-BAC

qui correspond une permission, obligation, interdiction ou recommandation (figure 4.10). Bien videmment, cette manire de faire inclut le cas particulier o la rgle ne concerne quune seule organisation ; dans ce cas, le CdO peut prciser que les organisations (du RdO, VdO, et AdO) sont identiques.
Organisation CdO

Type_Accs

VdO

RdO

Boolen : Permission Boolen : Interdiction Boolen : Obligation Boolen : Recommandation

AdO

Figure 4.10 : bauche du diagramme de classe reprsentant les rgles de scurit. Dune manire gnrale, une politique de scurit comporte des faits du type : Permission(Purpan, Mdecin-Dans-Rangueil, Lecture-Dans-Purpan, DossierMdical-DansPurpan, Catastrophe-Dans-Purpan) et Permission(Purpan, Mdecin, Lecture, Dossier-mdical, Mdecin-traitant). La premire rgle implique deux organisations diffrentes et signifie que lhpital Purpan accorde aux mdecins de lhpital de Rangueil la permission de consulter nimporte lequel de leurs dossiers mdicaux dans le contexte catastrophe (figure 4.11). La deuxime rgle est plus restrictive et exprime que lhpital Purpan accorde aux mdecins la permission de consulter les dossiers mdicaux des patients dont ils sont les mdecins traitants.
Purpan:Organisation CatastropheeDansPurpan :CdO

Type_Accs
MdecinDansRangueil :RdO

LectureDansPurpan :AdO

Permission = vrai

DossMedDansPurpan :VdO

Figure 4.11 : bauche du diagramme dobjet reprsentant une rgle de permission. En outre, la politique de scurit doit spcifier les conditions qui permettent de constater tel ou tel contexte dans telle ou telle organisation (CdO). Au moment de la requte, et avant daccorder ou rejeter laccs, le systme doit vrifier (ou calculer) le contexte courant en fonction des relations qui existent entre le sujet demandant laccs, lobjet invoqu, laction demande, et lorganisation implique. Il est important de souligner que, dans Or-BAC, les rgles de scurit ne sont pas spcifies pour chaque objet, sujet et action, mais seulement en utilisant des entits abstraites : organisations, rles, vues, activits et contextes. Pour autant, le contrle daccs de bas niveau doit permettre de dcrire les actions concrtes que ralisent les sujets sur les objets. Nous distinguons ainsi deux niveaux dabstraction (figure 4.12) : - niveau abstrait, portant uniquement des entits abstraites (organisation, rle, vue, activit, contexte) ; la politique de scurit y est exprime travers la classe association type daccs (permission, obligation, interdiction ou recommandation); - niveau concret, portant sur des autorisations (ou obligations ou interdictions ou recommandations) concrtes associes, dans le contexte courant, un utilisateur ui, un

111

objet oj et une action a k. Ces faits (permission , obligation, interdiction ou recommandation ) sont dduits, un moment donn, par instanciation des rgles de la politique de scurit.
Niveau abstrait politique de scurit Organisation CdO

Interdiction

VdO

RdO

Obligation Recommandation Permission

AdO

<<instance de>>

joue

Correspond_ <<instance de>>

Appartient_

Purpan:
Organisation

Pierre
:Sujet

Lire
:Action

Urgence
:Contexte

F31.doc
:Objet

Niveau concret entits du monde rel

Figure 4.12 : Les deux niveaux dabstraction du modle Or-BAC. En regroupant les bauches de diagrammes de classe prsentes prcdemment, on obtient le diagramme de classe correspondant Or-BAC (figure 4.13). Celui-ci sexplique ainsi : Les lments du systme sont partitionns en deux catgories : les lments acteurs (auxquels la politique de scurit attribue des droits) ou sujets et les entits passives ou objets, sur lesquels des actions sont effectues. Lensemble des objets contient des lments qui ne peuvent jamais tre des sujets (machines dossiers, etc.). Ces objets sont nots O\S. De mme, puisque les sujets peuvent eux-mmes tre manipuls, ils forment une partition de lensemble des objets, ils sont ainsi nots : Objets qui Peuvent tre Actifs OPA. En particulier, les patients sont considrs comme des objets (lorsque linfirmire leur fait une injection par exemple) qui peuvent tre actifs en consultant leurs dossiers mdicaux. Par ailleurs, le modle prsent considre une structure rcursive sur les objets, les sujets, les activits et les organisations. Par exemple, les quipes sont aussi des sujets qui peuvent jouer des rles et avoir des droits. Lbauche du diagramme de classe de la figure 4.14-a montre dune part que les utilisateurs, comme les quipes, sont des sujets (relation dhritage) et dautre part que les quipes sont composes de sujets, cest--dire dutilisateurs et dautres quipes (relation de composition) . La figure 6.14-b donne la vision ensembliste correspondante. Cette manire de faire assure la flexibilit et la rcursivit, dans la mesure o il est possible de former des quipes, qui leur tour peuvent tre regroupes pour former des quipes plus grandes et ainsi de suite.

112
Rle

Chapitre 4 Le modle Or-BAC

0..n 0..n
Organisation

0..n

0..n

Vue

0..n

RdO Id_Org Id_Rle

AdO Id_Org Id_Act

VdO Id_Org Id_Vue

Rcursivit des sujets

Sujet

Rcursivit des activits

0..n
Activit

Elments en tat passif

1..n

Objet

OPA

1..n
Utilisateur

Tche_Elmentaire

0..n

O\S

Tche_Composite

0..n
Equipe RAV Id_RdO Id_VdO Id_AdO Action Groupe_Objets Crte-Role

0..n 1..n
Type dAccs Permission Interdiction Obligation Recommandation Processus

Contexte

Contraintes

Crte-Vue Crte-Org

Lgende OPA : Objets pouvant tre actifs (patients par exemple) O\S :lensemble des objets sans les sujets RdO : Rle dans Organisation AdO : Activit dans Organisation VdO : Vue dans Organisation RAV : classe-association entre RdO, VdO et AdO

1..n

Contrle a priori

{ordonn}

1..n
Exception Problme

1..n 1..n 1..n

Contrle a posteriori

0..n
Patient

Audit

Notification

Figure 4.13 : Reprsentation UML du modle Or-BAC.

Sujet Le sujet : quipe dune clinique
1..n

Equipe j x x x

Equipe i x x

Utilisateur

0..n

x Chef de clinique

Equipe

Figures 4.14 (a et b) : Exemple de rcursivit. Les RAV (Rle, Activit, Vue) ainsi que les autorisations peuvent tres modliss par des classes-associations. Tout processus est compos dun ensemble ordonn de RAV. Il est identifi par un patient et un problme (la relation de dpendance exprime que toute modification du problme ou du patient entrane un changement dans le processus). Une exception (ou objectif dutilisation) est relie deux types de contrles : un contrle a priori et un contrle a posteriori. Un contexte est reli des contraintes sur les rles, les vues ou les organisations. Les autorisations sont attribues 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 mta-modle Or-BAC que nous avons prsent peut tre appliqu, non seulement aux SICSS, mais aussi une large gamme dorganisations et de systmes.

Chapitre 5. Choix dun formalisme pour Or-BAC

Prambule
Dans le chapitre prcdent, nous avons prsent les concepts de base du modle Or-BAC et nous avons propos une reprsentation UML dOr-BAC. Cette reprsentation offre des outils graphiques qui doivent guider le processus de spcification et de mise en uvre de la politique de scurit du systme tudi (ce processus sera dtaill dans le chapitre 6). Nanmoins, la simplicit de la reprsentation UML cache une relle complexit de modlisation. linverse, une reprsentation formelle doit fournir une spcification plus prcise et non-ambigu, comme elle devrait permettre une analyse plus rigoureuse notamment de la complexit, de ladquation entre le service attendu et la description oprationnelle, etc. cet gard, loutil MagicDraw permet de traduire une spcification UML en langage formel Maude [Clavel et al. 2002]. Celui-ci offre des mthodes et des outils pour la vrification, le model checking, le calcul de complexit, etc. Lobjet de ce chapitre est de prsenter un autre formalisme logique capable de modliser les rgles de fonctionnement, les objectifs de scurit ainsi que les rgles de scurit. Ce formalisme permet dtudier un autre volet de la vrification formelle, en offrant des outils daide au raisonnement sur les permissions, les interdictions, les obligations et les recommandations. Aussi, ce chapitre est-il articul en quatre parties. Il commencera par prsenter lintrt dune approche formelle : consultation dune politique de scurit, tude de la cohrence de cette politique, vrification des proprits attendues, etc. Ensuite, il dtaille les diffrents langages susceptibles de reprsenter une politique de scurit fonde sur Or-BAC, en loccurrence la logique du premier ordre, la logique modale, et notamment une de ses branches, la logique dontique. Celle-ci a lavantage dutiliser des permissions, des interdictions ainsi que des obligations. Enfin, nous proposons un formalisme logique (fond sur la logique dontique) pour Or-BAC. Ce formalisme sera ensuite utilis pour reprsenter les rgles de fonctionnement, les objectifs de scurit ainsi que les rgles de scurit des SICSS. Par ailleurs, nous prsentons des ides sur les mthodes (mthode des tableaux, logique possibiliste) dexploitation de ce formalisme, notamment pour effectuer des vrifications et pour dtecter et rsoudre des conflits.

114

Chapitre 4 Le modle Or-BAC

5.1. Intrt dune approche formelle

Le principal atout de lutilisation dune approche formelle dans la spcification dune politique de scurit rside dans llimination dun certain nombre des ambiguts de la spcification, et daider ladministrateur spcifier, dfinir et formaliser la politique de scurit. Les profits en sont multiples : lanalyse des problmes dinteroprabilit entre plusieurs politiques, linterrogation de la politique par des requtes concernant les accs, ou la manipulation de la spcification par des transformations mathmatiques et avec lassistance doutils de preuve, notamment pour vrifier la cohrence de la politique de scurit [Cuppens & Saurel 1996]. Ceci est particulirement important dans les SICSS car, plus encore que dans dautres domaines dapplications, les politiques des SICSS doivent permettre dassurer simultanment les proprits de confidentialit, dintgrit, de disponibilit et dauditabilit, dans un univers dynamique o les droits des utilisateurs doivent pouvoir varier selon le contexte courant. Lassociation dun formalisme logique la dfinition de politiques de scurit est donc fort utile, notamment pour fournir lutilisateur les services que nous dcrivons ci-dessous.

5.1.1. Consultation dune politique de scurit

Une politique de scurit peut faire lobjet de plusieurs requtes du type : tant donnes certaines caractristiques contextuelles, quelles sont pour un utilisateur jouant un certain rle, les permissions (interdictions, obligations ou recommandations) en matire daction sur un (des) objet(s) donn(s), ou de dlgation de privilges une autre personne jouant un autre rle ? Qui a des privilges (et lesquels) sur un (des) objet(s) donn(s), et dans quel contexte ? Dans quel contexte tel utilisateur a-t-il tel privilge sur tel objet ou telle dlgation de privilges ? Qui peut dlguer quel privilge un individu jouant un rle donn, dans un contexte donn ?

5.1.2. Cohrence dune politique de scurit

En se basant sur un langage logique, avec une syntaxe et une smantique bien prcises, il est possible de vrifier la cohrence de la politique de scurit. Globalement, on peut distinguer quatre types dincohrence dans la politique de scurit : - Il peut savrer que certains objectifs de scurit soient contradictoires les uns avec les autres. - De la mme manire, plusieurs rgles de scurit prsentes dans la politique peuvent ellesmmes se contredire. - Il est parfois possible que les rgles de fonctionnement entrent en conflit avec les objectifs et les rgles de scurit qui ont t dfinis. - Enfin, tant donn que les rgles de scurit permettent de savoir comment un tat de scurit peut voluer, et que les objectifs de scurit permettent de savoir si un tat est sr, il est a priori souhaitable que lon puisse vrifier sil nest pas possible, partant dun tat sr et en appliquant les rgles de scurit, datteindre un tat non-sr (cest--dire, un tat qui compromet lun des objectifs de scurit). Notons que ce type de vrification peut tre difficile, car il correspond la rsolution du problme de protection, indcidable dans le cas gnral [Harrison et al. 1976] (voir 2.2.2.2).

115

cet gard, lorsquune politique de scurit contient des permissions, mais aussi des interdictions, voire des obligations, il est ncessaire de sassurer quelle ne peut pas gnrer de conflit, cest--dire, garantir quil nexiste pas de situation dans laquelle un utilisateur aurait simultanment la permission et linterdiction deffectuer une action sur un objet.

5.1.3. Proprits attendues dune politique de scurit

Il est ncessaire de sassurer quavec une politique de scurit dfinie et cohrente, il nexiste pas de situation dans laquelle un utilisateur peut violer une proprit de scurit exige. Par exemple : - un utilisateur peut apprendre une information alors quil na pas lautorisation de la connatre (confidentialit), - il peut crer, modifier ou dtruire une information alors quil nen a pas lautorisation (intgrit). Il peut tre intressant didentifier les lments de la politique provoquant le non respect des proprits de scurit souhaites, cest--dire les sous-ensembles minimaux de rgles qui gnrent lincohrence dans certaines situations. Par ailleurs, la modlisation formelle dune politique de scurit demeure primordiale si lon souhaite vrifier que limplmentation du systme dinformation, et en particulier des mcanismes de contrle daccs, permet bien de garantir les proprits de scurit souhaites.

5.1.4. Compltude et interoprabilit

Lobjectif dune politique de scurit est de dfinir les rgles respecter pour protger le systme contre les menaces identifies lors de lanalyse des risques. Le problme de la compltude dune politique de scurit peut tre vu comme celui de lexhaustivit du rglement correspondant. Ceci peut tre vrifi en montrant que, face chaque risque identifi, il existe une rgle spcifie dans la politique de scurit qui dfinit la conduite tenir face ce risque. Des problmes de fusion de politiques de scurit peuvent galement se poser, par exemple dans le cadre dune restructuration entre deux organismes. Un premier aspect concerne la dfinition de rles et de structures organisationnelles qui soient compatibles. Un autre aspect concerne ensuite la dtection de conflits dans la politique obtenue par fusion, puis la proposition dune mthode permettant de rsoudre ces conflits. Des problmes analogues se posent si lon souhaite faire interoprer deux organisations dotes chacune de sa propre politique de scurit.

5.2. Choix dun langage de base pour formaliser Or-BAC

Le choix dun langage formel pour la spcification dune politique de scurit seffectue tout dabord en fonction du domaine dapplication de ce langage. Il semble indispensable de choisir un langage permettant, dune part, de reprsenter naturellement des notions comme celles de permission, dobligation, dinterdiction et de recommandation que lon retrouve dans une politique de scurit de manire gnrale, et dautre part, de capturer les particularits et les concepts du systme tudi, cest--dire des SICSS. Avec nos partenaires des sous-projets 3 et 4 du projet MP6, nous avons propos dassocier Or-BAC un formalisme logique fond sur la logique de premier ordre [Abou El Kalam et al. 2003]. Dans ce mmoire, nous proposons un autre formalisme fond sur la logique dontique [Abou El Kalam & Deswarte 2003]. Ce langage a t labor avec la contribution de Philippe Balbiani de lIRIT.

116

Chapitre 4 Le modle Or-BAC

Mais tout dabord, prsentons une brve description de la logique du premier ordre et de la logique modale, et plus particulirement une de ses branches : la logique dontique.

5.2.1. Logique de premier ordre

La logique des propositions est ltude des raisonnements dont la forme est constitue par des variables propositionnelles (p, q , r, ) et des connecteurs interpropositionnels tels que et : (), ou ( ), non ( ), si alors ( ). Malheureusement, ce type de logique ne permet pas deffectuer des raisonnements comme le fameux syllogisme de Socrate : tous les hommes sont mortels , or Socrate est un homme, donc Socrate est mortel En effet, la logique des propositions, ne peut pas exprimer une assertion du type : tous les hommes sont mortels. Cest pourquoi la logique de premier ordre a t introduite [Kleen 1967]. Elle reprend lensemble des lments de la logique propositionnelle et y ajoute des constantes (a, b , c, ), des variables (x, y , z, ), des prdicats (relations), des fonctions {f( x , y , ..), g(y , z,), ...)}, des quantificateurs universel "et existentiel $, etc. Les constantes sont des symboles directement mis en correspondance avec les objets que lon dcrit ou sur lesquels on veut raisonner. Les variables peuvent tre instancies dans un ensemble de constantes. Les fonctions prennent comme arguments des variables ou des constantes pour retourner des valeurs prises parmi lensemble de constantes possibles. Les mots constitus des variables, des constantes et des fonctions appliques ces variables ou constantes forment les termes du langage : t1 :=x ; t2:=f(x, y, b) ; t3:=a, etc. Les prdicats (P(t1, .., t n), Q(t1, .., t n), ...) sont des relations qui ont pour arguments les termes du langage. Le langage prdicatif comporte toutes les formules bien formes partir des formules atomiques (y := P(t1, .., tn), j := (t1 = tn), ...), des connecteurs dyadiques de la logique propositionnelle {, , , , } ainsi que des quantificateurs (" et $). Si y et j sont des formules bien formes du langage L, alors yj, yj , y, j, yj , "xy, $xj, etc., sont des formules bien formes.

5.2.2. Logique modale

La logique modale est une extension de la logique classique dans laquelle, en plus des connecteurs boolens, on trouve les connecteurs intensionnels de la ncessit ( ) et de la possibilit (). Plus prcisment, elle constitue un cadre formel pour ltude de ces notions, en fournissant, outre une reprsentation explicite de celles-ci par des oprateurs modaux (pour la ncessit et pour la possibilit), la possibilit dtudier leurs aspects intentionnels et dductifs, ainsi que leurs aspects extensionnels par la smantique des mondes possibles (dite smantique de Kripke). La logique modale, prise au sens large, est aujourdhui lun des meilleurs outils danalyse scientifique pour ltude de divers concepts considrs comme philosophiques. Ce sont principalement ceux de la ncessit, de la possibilit, de lobligation, de la permission, du futur, du pass, du temps en gnral, du savoir, de la croyance, etc. En effet, selon le type de la modalit, diverses logiques modales peuvent tre distingues [Chella 1980 ; Catach 1989]. On trouve les modalits : - Ontiques : il est (ncessaire, possible, contingent, impossible) que p . - Temporelles : il (sera, a t) (toujours, un moment donn) vrai que p . - Epistmiques : x (sait, croit, doute) que p . - Dynamiques : il (sera, a t) (ncessaire, possible, impossible) en faisant que p . - Dontiques : il est (obligatoire, permis, interdit) que p . Ces modalits, auxquelles il est opportun dajouter la recommandation, nous intressent plus particulirement. Une intrprtation intuitive de toute logique modale [Kripke 1959 ; Kripke 1963] peut tre fonde sur un modle smantique comprenant un ensemble de mondes diffrents, dans lesquels on considre la valeur de vrit des diffrentes propositions, notamment des propositions

117

contenant un oprateur modal. Par exemple, Ncessairement p est vrai dans un monde w si et seulement si p est vrai dans tous les mondes w directement accessibles depuis w . Lide est que tous les mondes (ou tats) ne sont pas forcment directement (ou indirectement) accessibles depuis un monde w . Un monde w permet daccder directement un monde w , seulement si toutes les propositions qui sont vraies dans w sont vraies dans w. De la mme manire, si une proposition est ncessairement vraie dans un monde w, elle doit tre vraie dans tous les mondes w auxquels w permet daccder.

5.2.3. Logique dontique

La logique modale est appele logique dontique lorsque les formules A et A sont lues il est obligatoire que A et il est permis que A respectivement. Le concept dinterdiction nest pas oubli puisque la formule A exprime justement linterdiction de A. Plus prcisment, si F est un ensemble de propositions atomiques a , b , c, , si , , , et dsignent les connecteurs boolens habituels, et si O , P et F dsignent les trois oprateurs modaux de la logique dontique (obligation, permission, interdiction), le langage de la logique dontique not LO(F) est lensemble des formules (ou expressions) construit par les rgles suivantes : - si pF, p est une formule, si p et q sont des formules, p, pq, pq, pq sont des formules, si p est une formule, Op, Pp et Fp sont des formules. En notation EBNF (Extended Backus Normal Form), LO peut tre donn sous la forme : f ::= a |f | ff | ff | ff | Of | Pf | Ff | o a LO(F) est une proposition atomique ; f est une formule du langage dontique LO(F). Une formule modale est une formule contenant au moins un des oprateurs modaux O, P et F . Les formules Op, P p et F p dsignent respectivement, il est obligatoire que p, il est permis que p, il est interdit que p. La smantique associe une logique modale normale est appele smantique de Kripke, ou encore smantique des mondes possibles [Kripke 1963]. Un modle de Kripke M est un triplet (W,,V) o W est un ensemble de mondes possibles w, est une relation binaire sur W appele relation daccessibilit,et V : WF {vrai, faux} est une fonction qui donne pour chaque monde wW la valeur de vrit V(w,p) de la proposition atomique p.

=M w p note le fait que la proposition p soit vraie dans un monde w dans le modle M . Cette
valeur de vrit est dfinie de la manire suivante, qui tend le calcul propositionnel habituel : si pF, = M w p si est seulement si V(w,p) =vrai,
M =M w p si est seulement si on na pas = w p , M M =M w ( p q) si est seulement si = w p ou = w q ,

=M =M w Op si est seulement si "w' W / ww' , w' p Cette dernire dfinition peut se traduire par : il est obligatoire que p est vraie dans un dans tous les mondes w directement accessibles depuis monde w si est seulement si p est vraie w. Si on considre que loprateur P est le dual de loprateur O , cest--dire P p = Op , on peut facilement dduire la valeur de vrit de Pp.
-

118

Chapitre 4 Le modle Or-BAC

=M w Pp si est seulement si $w ' W / ww ' ,

=M w' p

La dfinition dun systme logique ncessite la considration daxiomatiques et de rgles dinfrence. titre dexemple, nous citons : : p (dite Rgle de Ncessit ou RN), qui signifie que si le systme La rgle dinfrence Op contient p (lhypothse), il contient Op (la conclusion). Laxiome K : O(pq) (OpOq). Laxiome D : O p P q . Si une logique dontique inclut cet axiome, alors la relation daccessibilit est srielle, cest--dire : $w W / $w' W / ww' .

5.3. Langage propos pour Or-BAC

Dans la section 3.3, nous avons reprsent Or-BAC laide dUML. Notre langage dontique L doit fournir une syntaxe permettant dexprimer les instances des relations existantes entre les entits. Chaque expression de L contiendra des symboles extraits dun vocabulaire particulier classs en quatre groupes : les symboles de constante, les variables individuelles, les symboles de relation et les symboles de fonction.

5.3.1. Le langage 5.3.1.1 Constantes

Les symboles de constante correspondent aux instances des entits du diagramme. Ainsi, il y a autant de types q de symboles de constante que dentits dans notre diagramme, cest--dire : Organisation, Sujet, Objet, Action, Rle, 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., - Rle, comme mdecin, infirmire, unit_des_soins_intensifs, etc., - Vue, comme dossier_administratif, dossier_mdical, dossier_chirurgical, etc., - Activit, comme lecture, criture, consultation, etc. - Contexte, comme urgence, etc. Les constantes sont notes par des lettres minuscules comme a, b et c.

5.3.1.2 Variables
Les variables sont notes 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 appels termes-q. Les symboles de relation de L, notes par des mots commenant par des lettres majuscules P, Q , R, etc., correspondent aux relations de notre diagramme. Chaque symbole de relation P de L est considr comme un type de relation. Par exemple : - RdO est un symbole de relation de type (Organisation, Sujet, Rle).

119

VdO est un symbole de relation de type (Organisation, Sujet, Vue). Est_permis, Est_interdit, Est_obligatoire, Est_recommand sont des symboles de relation de type (Sujet, Objet, Action).

5.3.1.3 Formules atomiques

Avec les prdicats, les actions dfinissent les lments fondamentaux du langage. Par exemple : TRANSMETTRE(u, f, u) : permet u de transmettre le fichier f u ; CREEROrg(u, org) : permet de crer une organisation. Au moyen des prdicats et des actions, on peut dfinir les formules atomiques : si A est un prdicat ou une action de type l 1, .., ln et si t1, .., tn sont des termes de type l1, .., ln alors A(t1, .., tn) est une formule atomique. Par exemple, le prdicat RdO(Bob, mdecin, Hpital-Rangueil) ; et laction LIRE(Bob, F5.doc) sont des dormules atomiques.

5.3.1.4 Fonctions
ce stade, notre langage nest pas assez expressif pour pouvoir comparer des entits. Dans de nombreuses applications, nous dsirons driver des informations concernant certaines proprits des entits. Dun point de vue formel, des symboles de fonction sont utiliss pour dcrire les attributs de ces entits. Les symboles de fonction sont nots par des lettres minuscules comme f, g et h . chaque symbole de fonction f sont associs un domaine et un co-domaine (encore appel domaine image de la fonction). Le domaine et le co-domaine dun symbole de fonction dpendent de la nature des attributs qui lui sont associs. Si un symbole de fonction correspond lattribut Nom, alors son domaine est de type Sujet et son co-domaine est un ensemble de noms. De mme, le domaine dun symbole de fonction correspondant un attribut ge est de type Sujet et son co-domaine est un ensemble dentiers positifs. Enfin, le domaine dun symbole de fonction correspondant lattribut Groupe_sanguin est de type Sujet et son co-domaine est lensemble {A , AB , B , O }. Dans la mesure o il est possible que des sujets naient pas de nom ou que leur groupe sanguin soit inconnu, les symboles de fonction du langage L peuvent ntablir quune correspondance partielle entre les domaines et co-domaines associs. Dans de nombreuses situations, il nous est impossible dattribuer une valeur unique certains attributs dune entit. Pour rpondre une telle situation dun point de vue conceptuel, nous utilisons des symboles de fonction unaires ayant pour co-domaine lensemble des parties dun ensemble. Pour illustrer ceci, il nous suffit de mentionner le cas de lattribut mdecin_traitant : le domaine du symbole de fonction associ est de type Sujet et le codomaine associ est un ensemble densembles finis de noms. Afin de driver les informations reprsentes par les symboles de fonction, nous devons introduire des relations binaires concrtes, notes par s , t et m entre les domaines. Le type dune relation binaire concrte est le couple correspondant aux domaines sur lesquels la relation sapplique. Lgalit est probablement la relation binaire concrte la plus simple que nous aurons traiter. Considrons les exemples suivants : - Si t et u sont des termes de type Sujet , alors mdecin_traitant(t) = mdecin_traitant(u) signifie que les sujets t et u ont au moins les mmes mdecins 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 mme 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 mme groupe sanguin. Bien videmment, il existe certains cas o dautres relations binaires doivent tre considres. Par exemple :

120

Chapitre 4 Le modle Or-BAC

Si t et u sont des termes de type Sujet, alors mdecin_traitant(t) mdecin_traitant(u) signifie que les sujets t et u ont un mdecin traitant en commun.

Si t et u sont des termes de type Sujet, alors ge(t) < ge(u) signifie que le sujet t est plus jeune que le sujet u. - Si t et u sont des termes de type Sujet , alors Groupe_sanguin(t) ~ Groupe_sanguin(u) signifie que les groupes sanguins de t est compatible avec celui de u. Le langage est gnr par la rgle de grammaire suivante, donne en notation EBNF, o f dsigne une formule : f := A(t1, .., tn) | f | ff | ff | Of | Pf | Ff | Rf.

5.3.2. La smantique
La smantique utilise est dfinie par le modle M = < W, , V, D > o : W est un ensemble de mondes possibles w ; est une relation daccessibilit (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 vrit des lments du langage : V(Formule Atomique darit n) Dn, V(variable) D, V(constante) D.

Intuitivement, (Bob, mdecin, Hpital-Rangueil) V(w, RdO) signifie que dans le monde w , Bob joue le rle mdecin au sein de lorganisation Hpital-Rangueil . De la mme manire, (Sam, f5.doc ) V(w,LIRE) signifie que dans le monde w, Sam excute laction LIRE sur le fichier f5.doc.

5.3.3. Les conditions de vrit

En plus des conditions de vrit classiques relatives aux oprateurs , , , le langage prsent ajoute une condition de vrit qui permet de dterminer si une formule atomique est vraie dans un monde donn : Par exemple,

=M w A (t 1,.., tn ) ssi (V(t1), .., V(tn)) V(w, A).

=M w RdO ( Bob, mdecin, Hpital-Rangueil) ssi (Bob, mdecin, Hpital-

Rangueil) V(w, RdO). En outre, les oprateurs modaux permettent de modifier les proprits de la relation daccessibilit entre les diffrents mondes du modle associ la spcification. Ils indiquent si deux mondes doivent ou non tre accessibles lun depuis lautre. Rappelons la signification des formules dontiques (section 5.2.3) : M =M w Of ssi " w W tel que wRw, = w ' f : f est vrai dans tous les mondes accessibles

partir de w. M =M w Pf ssi $ wW tel que wRw, = w ' f : il existe au moins un monde accessible partir

de w o f est vrai.

M =M F f ssi " w W tel que wRw, = w ' f : f nest vrai dans aucun des mondes w

accessibles partir de w . Le langage propos accepte quelques axiomes, notamment :

FpOp : linterdiction de faire quelque chose est quivalente lobligation de ne pas le

faire.

121

Pp F p : la politique dfinit explicitement les permissions ; ainsi, toute chose permise

est forcment non interdite (linverse nest pas toujours vrai).

O(pq) O p O q : lobligation de faire la conjonction de p et q est quivalente

lobligation de faire p et lobligation 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 lobligation.

5.4. Utilisation du langage propos pour spcifier une politique

5.4.1. Spcification des rgles de fonctionnement
Le but de la spcification des rgles de fonctionnement et des rgles de scurit est de dfinir les diffrents flux dinformations et les contrles daccs. Il ne sagit de reprsenter que le fonctionnement pertinent vis--vis de la scurit afin de pouvoir, ultrieurement, dterminer limpact sur les objectifs de scurit. La description se fait par le biais des oprateurs de la logique propositionnelle. Au niveau de la smantique, les rgles de fonctionnement dfinissent la structure (dite de Kripke) interne des mondes. Ce sont des axiomes ne contenant pas doprateurs modaux. Ils nont donc aucun impact sur les caractristiques de la relation entre les mondes du modle. En revanche, chaque monde est tel quil constitue un tat de fait compatible avec les rgles de fonctionnement. Ainsi, la rgle q r signifie que dans tout monde w o q est vrai, r lest aussi.

5.4.1.1 Les sujets et les rles

Les rles jous dans les organisations sont facilement reprsentables dans le langage propos laide du prdicat RdO. Supposons titre dexemple que lhpital Purpan habilite plusieurs sujets : Jean dans le rle de directeur, Marie dans le rle dassistante administrative, ST1 dans le rle dquipe chirurgicale et RT2 dans le rle dquipe radiologique. Dans notre langage, ces faits sont reprsents par des instances de la relation RdO : - RdO(Purpan, Jean, directeur), - RdO(Purpan, Marie, assistante_administrative), - RdO(Purpan, ST1, quipe_chirurgicale) et - RdO (Purpan, RT2, quipe_radiologique). Dans ces faits, directeur, assistante_administrative, quipe_chirurgicale et quipe_radiologique sont des rles. Nous considrons par ailleurs quun attribut Patient associ lentit Sujet indique quels sont les patients dun sujet. Par consquent, notre langage inclut une fonction partielle Patient ayant pour domaine Sujet et pour co-domaine un ensemble densembles finis de noms. Par exemple, les fonctions Patient(Purpan) et Patient(Michelle) retournent respectivement la liste des patients de lhpital Purpan et la liste des patients de Michelle qui est un professionnel soignant. Dans le domaine social, Net-entreprises est une organisation o les entreprises (organisations) jouent les rles : tiers-dclarant , tablissement-dclar et tablissementadhrent. En loccurrence : - RdO(Net-entreprises, Ernst&Young, tiers-dclarant) : pour Net-entreprises, Ernst&Young est (entre autres) un centre de gestion agr faire des dclarations pour des entreprises.

122

Chapitre 4 Le modle Or-BAC

RdO(Net-entreprises, Hpital-Rangueil, tablissement-dclar) : Net-entreprises considre lhpital de Rangueil comme un tablissement dclar. - RdO(Net-entreprises, Hpital-Rangueil, tablissement-adhrent) : lhpital de Rangueil est une organisation adhrente Net-entreprises. Puisque tout tablissement dclarant ou dclar doit tre inscrit Net-entreprises, une relation dhritage existe entre ces rles : Sous-Rle(Net-entreprises, tiers-dclarant, tablissement-adhrent) ; et Sous-Rle(Net-entreprises, tablissement-dclar, tablissementadhrent). -

5.4.1.2 Les objets et les vues

Considrons les objets appartenant aux vues suivantes : - dossier_administratif : les objets qui appartiennent cette vue fournissent des informations administratives concernant les patients comme leur nom, leur adresse, leur ge et leur numro de scurit sociale ; - dossier_mdical : cette vue correspond au dossier mdical des patients, elle contient les donnes durgence, lhistorique des consultations et des hospitalisations, etc. ; - dossier_chirurgical : cette vue correspond aux dossiers de spcialit grs par lquipe chirurgicale. Les objets appartenant ces vues ont un attribut Nom. Si F31.doc est un dossier appartenant une de ces vues, Nom(F31.doc) fournit le nom du patient correspondant. Nous supposons galement que les dossiers sont directement grs par lhpital Purpan qui utilise un systme de fichier par exemple. Ceci se traduit dans notre modle par des faits de la forme : - VdO(Purpan, F31.doc, dossier_administratif), - VdO(Purpan, F32.doc, dossier_mdical), et - VdO(Purpan, F33.doc, dossier_chirurgical). Si ST1, lquipe chirurgicale et R T2, lquipe radiologique, partagent la mme base de donnes gre par lhpital Purpan. Cela signifie quelles utilisent les mmes vues que lhpital. Ceci peut sexprimer de la manire suivante : - "o"v (VdO(Purpan, o, v) VdO(ST1, o, v)), "o"v (VdO(Purpan, o, v) VdO(RT2, o, v)). partir des trois vues dossier_administratif , dossier_mdical , dossier_chirurgical, nous dfinissons une quatrime vue, appele dossier_patient . Nous supposons quelle a trois attributs dossier_administratif, dossier_mdical et dossier_chirurgical tels que : - "o (VdO(Purpan, o, dossier_patient) $o1$o2$o3 (VdO(Purpan, o1, dossier_administratif) VdO(Purpan, o2, dossier_mdical ) VdO(Purpan, o3, dossier_chirurgical) dossier_administratif(o) = o1 dossier_mdical(o) = o2 dossier_chirurgical(o) = o3 Nom(o1) = Nom(o2) = Nom(o3)). La vue dossier_patient correspond au dossier mdical complet du patient. Dans une base de donnes relationnelle, nous obtiendrions le dossier patient par une jointure des vues dossier_administratif, dossier_mdical, dossier_chirurgical suivant lattribut Nom.

123

Dans le domaine social, les dclarations (d1, d 2, ) et paiements (p1, p 2, ) effectus par les organisations adhrentes Net-entreprise peuvent tre considrs comme des objets appartenant aux vues : dclaration-annuelle-URSSAF, dclaration-trimestrielle-URSSAF, dclaration-mensuelle-URSSAF, dclaration-annuelle-ASSEDIC, dclaration-trimestrielleASSEDIC, dclaration- mensuelle-ASSEDIC, titre-de-paiement-annuel-URSSAF, titre-depaiement- 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, dclarationmensuelle-URSSAF), VdO(CNRS, d32.txt, dclaration-mensuelle-URSSAF). En outre, les dclarations ainsi que les paiements associs aux units27 dclares ou aux portefeuilles28 peuvent tre considrs comme des vues, en loccurrence: VdO(Ernst&Young, d33.txt, F dclaration(portefeuille-Grandes-Entreprises)). Dans cette rgle, nous avons utilis une fonction F dclaration qui sapplique un ensemble dorganisations et retourne lensemble des dclarations associes ces organisations. Dans la sphre sociale, la composition de vues peut tre illustre travers des instanciations de la relation : Sous-Vue(Organisation, Vue, Vue), par exemple Sous-Vue (Ernst&Young, dclarations), Fdclaration(portefeuille-Grandes-Entreprises)) dclare que dans lorganisation Ernst&Young, les dclarations associes au portefeuille des grandes entreprises est une partition de lensemble des dclarations.

5.4.1.3 Les actions et les activits

Nous ne considrons dans les exemples ci-dessous que les activits correspondant des accs directs aux dossiers, par exemple, la cration, la consultation et lcriture. Si nous supposons que les dossiers sont grs par lhpital dans une base de donnes relationnelle, ces activits correspondent respectivement aux actions insert, select, update, etc. Ceci est reprsent par les trois faits suivants : - AdO(Purpan, insert, creation), - AdO(Purpan, select, consultation) et - AdO(Purpan, update, criture). Dans le domaine social, diffrentes activits peuvent tre distingues, titre dexemple nous citons : - Lecture : pour visualiser une dclaration, un titre de paiement, un compte URSSAF, etc. - Lecture-criture (ou modification) : pour prparer une dclaration, modifier une dclaration dj signe ou envoye, etc. - Suppression, pour effacer une donne, ou radier une entreprise dun service. - Signature dune dclaration ou dun tl-rglement. - Envoi dune dclaration ou dun accus de rception. - Validation des informations saisies. Les processus o nintervient quun seul sujet peuvent tre vus comme des activits composites, par exemple : labonnement ou le dsabonnement un service ; la primoinscription dun administrateur ; la nomination ou la rvocation dune personne autorise ; etc.
27 Dans la section 3.2.2.1, nous avons dfini une unit dclare comme tant un sous-ensemble dun tablissement ou dune entreprise. Elles peuvent correspondre des dcoupages fonctionnels gographiques ou hirarchiques. Ainsi, les dclarations concernant les cadres par exemple peuvent tre considres comme des vues spares de celles concernant les autres employs. 28 Dans la section 3.2.2.1.3.3, nous avons dfini un portefeuille comme tant un ensemble dtablissements ou dentreprises associs une personne autorise.

124

Chapitre 4 Le modle Or-BAC

Dans Or-BAC, les associations des actions aux activits dans une certaine organisation sont donnes 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 hirarchie
Lhritage est un mcanisme qui permet de matriser la complexit. La rgle : "a"v"c (Permission(ST1, r1, a, v, c ) Permission(ST1, r2, a, v, c) exprime lhritage des permissions dans ST1 entre un rle r1 (par exemple mdecin) et un rle r2 (par exemple chirurgien). Une autre manire de faire consiste ajouter le prdicat Sous-Rle(Organisation, Rle, Rle), ainsi pour spcifier que r 1 hrite des permissions de r2, il suffit dajouter linstance Sousrle(ST1, r1, r2) cette rgle. Prcisons toutefois que dans notre modle il est possible de spcifier que lhritage entre deux rles donns ne sapplique qu certaines organisations. Nous pouvons par exemple spcifier qu lhpital Purpan, le rle directeur hrite des permissions du rle mdecin : "a"v"c (Permission(Purpan, mdecin, a, v, c) Permission(Purpan, directeur, a, v, c)). Bien videmment, lhritage est spcifi au sein dune organisation donne, et nous naurions pas cette rgle si, au lieu de considrer lhpital Purpan, nous considrions un autre tablissement au sein duquel le directeur nest pas un mdecin. Il est galement possible dexprimer dans notre modle lhritage, entre rles, dinterdictions, dobligations et de recommandations. Par ailleurs, de la mme manire que nous avons spcifi la hirarchie de rles, nous pouvons modliser la rcursivit des vues, des activits et des organisations travers lesnouveaux prdicats : Sous-Vue ( Organisation, Vue, Vue ), Sous-Activit(Organisation, Activit, Activit), Sous-Organisation(Organisation, Organisation). Par exemple, les vues dossier_administratif, dossier_mdical et dossier_chirurgical sont des sous-vues de la vue dossier_patient . Ainsi, un rle qui a la permission de raliser une activit sur la vue dossier_patient a galement la permission de raliser la mme activit sur les sous-vues prcdemment cites. Ceci sexprime dans notre langage par la rgle suivante : "r"a"c (Permission(Purpan, r, a, dossier_patient, c) Permission(Purpan, r , a, dossier_administratif, c)). Il en est de mme pour les vues dossier_mdical et dossier _chirurgical. Dans le domaine social, la spcification des accs (en amont) Net-entreprises distingue deux rles de base jous par les utilisateurs dans les organisations (section 3.2.2.1, page 69) : - Personne inscrite, - Personne non-inscrite. Rien nempche quune personne inscrite puisse jouer le rle de personne non-inscrite. Inversement, pour quune personne non-inscrite devienne inscrite, elle doit remplir certaines conditions (inscription). Les rles : dirigeant, mandataire social, administrateur et personne autorise, sont des sousrles du rle personne inscrite, ils hritent donc de ses proprits (par exemple, lappartenance un tablissement adhrent) et de ses privilges (par exemple, le droit de modification de ses propres informations). Une relation dhritage existe galement entre le rle mandataire social et le rle dirigeant . Il est possible de faire appel au polymorphisme pour spcifier que le mandataire social est le dirigeant du sige de lentreprise. Dans Or-BAC, cette hirarchie de rles peut tre modlise par les rgles suivantes : - Sous-Rle(Org, Mandataire, Dirigeant),

125

Sous-Rle(Org, Dirigeant, Personne-inscrite), Sous-Rle(Org, Administrateur, Personne-inscrite), Sous-Rle(Org, Personne-autorise, Personne-inscrite). Si diffrentes personnes autorises accdent diffrents services, le rle personne autorise est dcompos en plusieurs sous-rles. Autrement dit, si dans une certaine organisation, les personnes qui prparent les dclarations, diffrent de celles qui les envoient (les modifient, ou les payent), il est ncessaire de considrer autant de sous rles que de sous tches distinctes des personnes autorises. Nous pouvons ainsi dduire les rgles de hirarchie de rles suivantes : - Sous-Rle(Org, Personne-autorise-Prparer-Dclaration, Personne-inscrite), - Sous-Rle(Org, Personne-autorise-Valider-Dclaration, Personne-inscrite), - Sous-Rle(Org, Personne-autorise-Visualiser-Dclaration, Personne-inscrite), - Sous-Rle(Org, Personne-autorise-Prparer-Paiement, Personne-inscrite), - Sous-Rle(Org, Personne-autorise-Valider- Paiement, Personne-inscrite), - Sous-Rle(Org, Personne-autorise-Visualiser- Paiement, Personne-inscrite). -

5.4.1.5 Le contexte
Le contexte peut tre exprim par des rgles de fonctionnement. En loccurrence, lexclusion mutuelle entre les rles mdecin de nuit et mdecin de salle sexprime par RdO (u, Mdecin, Org)[RdO(u, Mdecin-nuit, org)RdO(u, mdecin-salle, org)]. Le contexte quipe traitant entre un certain patient o, un sujet s et une organisation org peut tre dfinie de la manire 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 interprte ainsi : dans lorganisation org, le contexte quipe traitante est vrai entre le sujet s et lobjet o si et seulement si s joue un rle dans org et si o est un dossier correspondant un des patients trait par org. De la mme manire, le contexte quipe traitante est dfini dans une certaine organisation ST1 par : - "s"o"a (Dfinit(ST1, s, a , o, quipe _ traitante ) $ r (RdO(ST1, s, r) Nom ( o ) Patient(ST1)), cest--dire, dans ST1, le contexte quipe traitante est vrai entre le sujet s, laction a et lobjet o si et seulement si s joue un rle dans ST1 et si o est un dossier correspondant un des patients trait par lorganisation ST1. Le contexte peut ventuellement dpendre de contraintes temporelles. Le contexte nuit par exemple, peut tre spcifi par la rgle suivante : "s"o"a (Dfinit(org, s, a , o, nuit) Aprs(20:00) & Avant(08:00). Loprateur & dsigne la conjonction de contextes ; Aprs et Avant sont deux fonctions qui sappliquent des lments du temps et qui retournent des contextes temporels. Elles peuvent tre dfinies comme suit : - "org "s "o"a "tTemps, Dfinit(org, s, a , o, aprs(t) ) temps (Horloge) t . Horloge est une entit capable dvaluer et de retourner le temps courant. Le contexte avant peut tre dfini dune faon similaire par : - "org "s "o"a "tTemps, Dfinit(org, s, a, o, aprs(t)) temps(Horloge) t. Lexpression du lieu comme attribut contextuel peut tre fait ainsi : "org "s "o"a "tTemps, Dfinit(org, s, a , o, Accs-Local) @IP(s) IP-Local(org). Cette rgle signifie que le contexte Accs Local est vrai dans lorganisation org entre le sujet s laction a et lobjet o, si et seulement si ladresse IP du sujet appartient un intervalle dadresses IP internes org. Nous considrons que les sujets ont lattribut @IPqui donne ladresse IP du terminal

126

Chapitre 4 Le modle Or-BAC

utilis par le sujet et que les organisations ont lattribut IP-Localqui retourne lensemble des adresses IP internes cette organisation. Pour offrir plus de flexibilit, nous avons dfini lobjectif dutilisation comme un contexte particulier revendiqu par des utilisateurs souhaitant intervenir dans des situations qui sortent des processus de soins habituels. Un objectif dutilisation est caractris par des conditions a priori et des conditions a posteriori. titre dexemple, dtaillons le contexte ContexteUNH : Urgence Non Habituelle (UNH). Nous proposons de lexprimer de la manire suivante : "s"o"a (Dfinit(ST1, s, a , o, ContexteUNH) Dclarer-Objectif Condition-a-priori Condition-a-posteriori, avec : - Dclarer-Objectif ( crer, s, o ) VdO(org, o, VueUNH) Patient-trait(o)=Nom(o). Dans cette expression, nous considrons la vue VueUNH ayant un attribut Patient-trait. Le sujet dclare lobjectif dutilisation urgence non habituelle sil insre lobjet o dans la vue VueUNH, et si o correspond bien au patient figurant dans lobjectif dclar. - Condition-a-priori RdO(org, s, Personnel-Soignant). Cette expression signifie que tout personnel soignant (dans une organisation) peut dclarer lobjectif dutilisation 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 , VueDonnes-Audit, ContexteObjectif), cest--dire que le systme (rle) doit enregistrer les donnes durgence. Les types de contextes existants dans la sphre sociale ne diffrent pas de ceux numrs prcdemment, nous nous contentons ainsi de modliser quelques exemples dans Or-BAC. Nous commenons par exprimer le contexte temporel dclaration--chance. Pour cela, nous avons tout dabord besoin de dfinir la fonction date qui sapplique une action et un objet, et retourne la date dexcution de laction sur lobjet, par exemple date(envoi, d1.txt) dsigne la date denvoi de la dclaration d1.txt Net-entreprises. Nous dfinissons par la suite la fonction avant-date qui sapplique des triplets (d : date, a : action, o : objet), pour retourner un contexte temporel dfini comme suit : "s"o"a CdO(Org, s, a , o, avant-date(d, a , o) date(a , o)d, cest--dire, laction a est excut sur lobjet o avant la date d . Nous avons galement besoin de lattribut Nbre-salaris dune entit organisation pour dsigner le nombre de salaris de cette organisation et de lattribut mois dune entit date, pour dsigner le mois de cette date. Enfin, le contexte dclaration--chance peut tre dfini par la rgle : "s"o"a (CdO(Org, s, envoi, o, dclaration--chance) [Nbre-salaris(Org) 9 avant-date(15 [(mois(date) modulo 3) = 1], a, o)] [10 Nbre-salaris(Org) 50 avant-date(15 mois(date)+1, a, o)] [Nbre-salaris(Org) > 50 avant-date(5 fvrier, a, o)]. En effet, une dclaration est considre chance si elle appartient lun des trois cas suivants : Si le nombre de salaris de lentreprise ne dpasse pas neuf, la dclaration est trimestrielle et doit tre faite avant le 15 du mois qui suit (cest--dire avant le 15 des mois de janvier, avril, juillet et octobre) ; sinon, si le nombre de salaris est compris entre dix et cinquante, les dclarations sont mensuelles et doivent tre faites avant le quinze du mois qui suit ; sinon (nombre de salaris suprieur cinquante), les dclarations sont mensuelles et doivent tre faites avant le cinq du mois qui suit.

127

Par ailleurs, puisque les autres contextes identifis dans les accs Net-entreprises sont similaires ceux prsents dans le scnario mdical de la section prcdente, il nest pas ncessaire de les dcrire nouveau. Une autre reprsentation du contexte associ Or-BAC dans un langage logique du premier ordre a t effectue par Cuppens et Mige [Cuppens & Mige 2003b]. Certaines diffrences existent toutefois entre leur vision et la ntre. En particulier, ils catgorisent diffremment le contexte et ne considrent pas le contexte dutilisation.

29

5.4.1.6 Les contraintes

Lutilisation de contraintes a t utilise dans le contrle daccs base de rle RBAC [Sandhu et al. 1996]. Les contraintes sont exprimes dans notre modle par des rgles sappliquant diverses relations. Nous donnons les rgles suivantes titre dexemple : "s (RdO(Purpan, s, quipe_chirurgicale) ($s1 RdO(s, s1, chirurgien) $s2 RdO(s, s2, anesthsiste) $s3 RdO(s, s3, infirmier)) . Cette rgle indique que si lhpital Purpan habilite s comme quipe chirurgicale, alors s habilite un chirurgien, un anesthsiste et une infirmire. Autrement dit, lhpital de Purpan, toute quipe chirurgicale doit tre constitue dau moins un chirurgien, un anesthsiste et une infirmire. Dans le formalisme logique associ Or-BAC il est galement possible de spcifier lexclusion mutuelle entre les rles (contrainte contextuelle), notamment pour modliser des situations du type : au sein de lhpital Purpan, aucun sujet s ne peut tre habilit la fois comme chirurgien et comme anesthsiste : "s (RdO(Purpan, s, chirurgien) RdO(Purpan, s, anesthsiste)). Dans Net-entreprises diffrentes contraintes peuvent tre numres, notamment celle interdisant de mettre un mme tablissement ou une mme entreprise dans deux portefeuilles diffrents. Ceci peut se traduire par la rgle : "Org [VdO(Org, o, Fdclaration(portefeuilleX)) (VdO(Org, o, Fdclaration(portefeuilleY)) (Fdclaration(portefeuilleX) Fdclaration(portefeuilleY)].

5.4.2. Spcification des objectifs de scurit

Les objectifs de scurit sont exprims par lutilisation doprateurs modaux. Ces oprateurs permettent de modifier les proprits de la relation daccessibilit entre les diffrents mondes du modle. Ils indiquent si deux mondes doivent tre accessibles lun depuis lautre. F[RdO(u, Pharmacien,_)CREER(u, ordonnance)] est un objectif de scurit reli aux proprits de confidentialit et dintgrit. Il correspond donc au point de vue de la scurit au souci dinterdire une certaine formule. Plus prcisment,il indique que, dans aucun des mondes accessibles, on ne peut trouver un utilisateur qui joue le rle pharmacien et qui cre une ordonnance.

29 Il sagit de contextes relatifs au lieu, par exemple le lieu de gestion dun type de dclarations ou de rfrentiels ; ou relatifs un objectif dutilisation, par exemple un processus daccs aux services de Netentreprises ou des cas durgences non habituelles o lutilisateur peut forcer laccs et effectuer ses dclarations ou ses paiements.

128

Chapitre 4 Le modle Or-BAC

5.4.3. Spcification des rgles de scurit

Du point de vue formel, une rgle de scurit est une formule modale dont les diffrentes clauses ne sont pas toutes des formules modales (par exemple : rPq). Elle reflte la manire dont ltat de scurit est en relation avec les diffrentes permissions, obligations, interdictions et recommandations qui existent dans le systme. Dans le langage propos, les rgles de scurit prennent essentiellement la forme suivante : "s"a"o"r"a"v"c P(org, r, a, v, c) RdO(org, s, r) VdO(org, o, v) AdO(org, a, a) CdO(org, s, a, o, c) Est_permis(s, a, o) : Si lorganisation org, dans le contexte c, accorde la permission au rle r de raliser lactivit a sur la vue v, si org habilite le sujet s dans le rle r, si org utilise lobjet o dans la vue v, si org considre laction a comme faisant partie de lactivit a et si au sein org le contexte c est vrai entre s, a et o, alors le sujet s a la permission de raliser laction a sur lobjet o. Cette manire de faire couvre parfaitement les diffrents cas daccs qui se prsentent dans le domaine mdical. Nanmoins, dans la sphre sociale, les rgles de scurit sont un peu diffrentes. En effet, Le tableau 5.1 rappelle les diff.rents accs possibles : Rle {Type} Types daccs autoriss

Personne n o n - Demand e de renseignement ; abonnement ou dsabonnement ; lecture inscrite actualits ; dpt de commentaires ; informations : techniques et informations dordre gnral sur les partenaires et le fonctionnement de {revendiqu} Net-entreprises ; accs au plan du site. Personne inscrite Dirigeant { attribu et anonyme par dfaut} ;{revendiqu pour tre nominatif} Mandataire social {revendiqu} Administrateur {revendiqu} Personne autorise {attribu} Informations et alertes personnalises ; modification de ses propres informations dinscription ou dauthentification. Vision densemble sur ladhsion de son tablissement Netentreprises : visualisation de lhistorique des modifications ; consultation des personnes autorises et de leurs droits ; rinitialisation de ladministrateur ; radiation de ltablissement ; limitation du nombre dadministrateurs ; interdiction (ou leve dinterdiction) de toute nouvelle inscription pour son tablissement. Radiation de son entreprise ; limitation du nombre dadministrateurs ; interdiction (ou leve dinterdiction) de toute inscription pour son entreprise. Inscription ; gestion des personnes autorises et de leurs droits daccs aux dclarations : nomination ou rvocation de ces personnes, consultation ou modification de leurs droits, dfinition de leurs primtres dhabilitation ; rsiliation de son inscription. Accs (prparation, validation ou visualisation) aux dclarations ou aux paiements

Tableau 5.1 : Droits associs chaque rle de notre scnario social.

129

Ce rcapitulatif nous montre de nouvelles formes de rgles, que nous navons pas analys prcdemment. Considrons la rgle la plus originale dans les accs aux services de Netentreprises : un administrateur dsigne une personne autorise effectuer des types de dclarations selon une certaine modalit pour le compte dun certain tablissement30. Cette rgle peut tre dcompose en deux autres rgles : - une premire rgle donnant ladministrateur le droit de dsigner (ou rvoquer) des personnes autorises, cest--dire daffecter des utilisateurs au rle personne autoris ; cette rgles sappelle rgle de dlgation (ou dadministration) ; - une deuxime rgle donnant la personne autorise le droit deffectuer des dclarations pour le compte dun certain tablissement. Nous proposons de reprsenter les rgles de dlgation sous la forme Permission (organisation, RdO, AdO, VdO, CdO), avec : - organisation est la structure qui dcide de dlguer, cest--dire ltablissement dclarant ; - RdO est la fonction qui a le pouvoir de dsigner, nommer, ou rvoquer des personnes habilites, dans notre cas, cest le rle administrateur dans ltablissement dclarant ; - AdO correspond lactivit nomination dans ltablissement dclarant (association dun utilisateur un rle) ; - CdO est le processus suivi par ladministrateur pour effectuer cette nomination, notons le par exemple inscription de nouvelles personnes autorises ; - VdO est le schma de la rgle de dlgation ; les objets appartenant cette vue sont des rgles. Rcapitulons, la rgle de dlgation (qui autorise ladministrateur affecter des nominations) a la forme suivante : Permission (tablissement dclarant, administrateur, dsigner ou rvoquer, schma de la rgle de dlgation, inscription de nouvelles personnes autorises). En insrant un objet dans la vue schma de la rgle de dlgation, ladministrateur dsigne une personne autorise pour effectuer des types de dclarations, pour une certaine organisation, selon une certaine modalit. Par consquent, cette vue particulire, note V_schma-rgledlgation, possde les attributs31 suivants : org : lorganisation dans laquelle le rle concern sera jou, cest--dire ltablissement dclar ; " schma-dlgationi V_ schma-rgle-dlgation, org(schma-dlgationi) = tab-dclara) ; rle : le rle dlgu, cest--dire personne autorise ; Rle(schma-dlgationi) = personne-autorise ; sujet : le sujet (Claire, Philippe, ) bnficiant de la dlgation, cest donc lutilisateur qui sera dsign (par ladministrateur) comme personne autorise ; par exemple, sujet(schma-dlgationi) = Philippe ; activit : lactivit correspondant laction que la personne autorise (Philippe ) peut effectuer, par exemple activit(schma-dlgationi) = envoyer-formulaire-dclaration ; vue : la vue dlgue, cest--dire la vue que la personne autorise va manipuler ; il peut sagir de types de dclarations ou types de titres de paiement, par exemple, les dclarations URSSAF, DUCS, CSSS, DADS-TDS : vue(schma-dlgationi) = dclarations-URSSAF, Vue(schma-dlgationj) = titre-paiement-DUCS, etc.

30 Rappelons que ltablissement dclarant et ltablissement dclar ne sont pas ncessairement les mmes, en loccurrence dans le cas dun tiers dclarant. 31 Bien videmment, les attributs de cette vue sont instancis chaque fois que ladministrateur dsigne ou rvoque une personne autorise, autrement dit chaque fois quil insre un objet dans cette vue.

130

Chapitre 4 Le modle Or-BAC

contexte : le contexte (ou processus, ou cadre) dans lequel la dclaration ou le paiement sera effectu, par exemple, contexte(schma-dlgationj) = processus-depaiement, contexte(schma-dlgationj) = processus-de-dclaration, etc. Pour rsumer, les deux rgles dont nous avons besoin sont : Premire rgle : - Permission (tablissement dclarant, administrateur, dsigner ou rvoquer, schma de la rgle de dlgation, inscription de nouvelles personnes autorises) ; Deuxime rgle qui spcifie la forme logique de la vue schma de la rgle de dlgation. Nous la dfinissons de la manire suivante : - " schma-dlgationi V_schma-rgle-dlgation VdO(org, schma-dlgationi, schma-rgle-dlgation) RdO(tab-dclara, Philippe, Personne-autorise) Permission(tab-dclara, P e r s o n n e - a u t o r i s e , envoyer-formulaire-dclaration , dclarations-URSSAF, processus-de-dclaration) Mme si le principe reste toujours le mme, la manire selon laquelle ce type de rgles peut tre exprim nest pas unique. Elle dpend troitement du fonctionnement et des objectifs32 de lorganisation (entreprise) tudie. cet gard, il faut dabord avoir des rponses aux questions suivantes (qui dpendent de lorganisation) : - Est ce que lon considre les sous-rles33 du rle personne autorise ou pas ? - Si oui, est ce que les privilges associs aux sous-rles sont stables (toujours les mmes)? Dans ce cas, il serait prfrable de dcomposer la rgle ci-dessus en deux parties : dans une premire tape, il faut associer les permissions aux rles, tandis que dans la deuxime tape, on affecte les utilisateurs aux rles (les sous-rles du rle personnes autoris) ; sinon, il serait galement possible dassocier directement des permissions aux utilisateurs. - Est ce que lon considre que la vue dclaration et diffrente de la vue paiement, ou linverse, on considre une vue type de dclaration mais avec deux modalits diffrentes : dclarer et payer. Cette analyse nous conduit discuter le problme dadministration des droits, sujet intressant qui a fait lobjet dtudes rcentes, et qui est souvent associ un modle de contrle daccs. En loccurrence, les modles ARBAC97 Administration Role-Based Acces Control [Sandhu & Bhaidipati1997 ; Sandhu & Bhaidipati1999], ARBAC99 [Sandhu & Munawer 1999] ainsi que ARBAC02 [Oh & Sandhu 2002] ont t associs au modle RBAC, tandis que le modle AdOr-BAC (Administration Model for Or-BAC) a t associ au modle Or-BAC [Cuppens & Mige 2003a]. Les modles dadministration associs R B A C considrent les associations : URA (User Role Administration), PRA (Permission Role Administration) tandis que AdOr-BAC redfinit ces deux associations et ajoute lassociation UPA User Permission Administration . Analysons, travers des exemples adapts notre scnario social, comment AdOr-BAC prsente ces trois associations : URA sert affecter des utilisateurs des rles. Modliser des rgles du type ladministrateur est autoris affecter un utilisateur au rle Personne Autorise (PA) dans ltablissement dclare tab-dclara, ncessite la cration des vues URA et URA-PA- tabUn objectif peut par exemple tre : une dfinition spare des personnes autorises, puis de leurs primtres dhabilitations, ou linverse, dfinir ces deux tches en mme temps. 33 Nous avons dj expliqu dans la section 3.2.3.2.1 que les sous-rles du rle personne autorise peuvent tre : personne autorise effectuer les dclarations, personne autorise effectuer des paiements, personne autorise consulter les dclarations etc.
32

131

dclara. URA possde trois attributs : sujet (sujet concern par laffectation), rle (auquel le sujet sera affect) et org (lorganisation dans laquelle le sujet sera affect). URA-PA- tabdclara. est dfinie comme suit : " ura URA VdO ( org , ura, URA-PA- tab-dclara) RdO ( org(ura), sujet(ura), rle(ura)) ; avec : org(ura) = tab-dclara et rle( ura) = personne autorise (ou lun de ses sous-rles). La rgle autorisant ladministrateur grer les rles des utilisateurs ressemble celle donne dans lexemple prcdent (Permission (tablissement-dclarantb, administrateur, gestion , URA-PA- tab-dclara, Processus-habilitation-PA)). PRA sert associer des permissions des rles. Lassociation PRA a cinq attributs : initiateur (organisation o la permission sapplique), rle (rle qui bnficie de la dlgation), privilge (lactivit dlgue), cible (vue concerne par la dlgation) et contexte (dans lequel la rgle sapplique). Donner une nouvelle permission un rle correspond en fait, crer un nouvel objet qui se conforme lassociation PRA. Le lien entre ces objets et la relation Permission est modlis par : - "org "contexte, VdO ( org , pra , PRA ) Permission (initiateur(pra ), rle (pra ), privilge(pra ), cible(pra), contexte(pra)). Ainsi, la rgle o ladministrateur est autoris affecter la permission consulter des dclarations au rle personne-autorise peut tre modlise comme suit : - (Permission (tablissement-dclarantb, administrateur, gestion, PRA-PA- tab-dclara, Processus-habilitation-PA)) La vue PRA-PA- tab-dclara est dfinie par : "pra, VdO(tablissement-dclarantb, pra, PRA-PA- tab-dclara,) VdO(tablissement-dclarantb, pra, PRA) initiateur(pra) = tab-dclara, rle(pra) = personne-autorise privilge (pra) = consultation cible(pra) = dclaration contexte(pra) = processus-vrification. UPA sert affecter des permissions des utilisateurs. Cuppens et Mige distinguent deux cas diffrents nomms : UPA1 et UPA2. UPA1 donne un utilisateur le droit dassocier une permission un autre utilisateur pour raliser une certaine tche sur un certain objet, tandis que UPA2 donne un utilisateur le droit dassocier une permission un autre utilisateur pour raliser une certaine activit sur une vue. Dans le cadre de ce mmoire, nous donnons seulement un exemple de UPA2. Celle-ci contient cinq attributs : initiateur (organisation dans laquelle la permission sapplique), sujet (sujet qui bnficie de la dlgation), privilge (laction dlgue), cible (lobjet concerne par la dlgation) et contexte (dans lequel la permission sapplique). Afin dexprimer la rgle le dirigeant de lentreprise dclarante peut associer, ladministrateur, le droit de mettre jour la table des personnes autorises, nous devons, tout dabord, dfinir la vue MJTPA (pour Mise jour de la Table des Personnes Autorise) qui est une sous-vue de UPA2 : - "upa, VdO(tablissement-dclarantb, upa, MJTPA) VdO(tablissement-dclarantb, upa, UPA2) RdO(tab-dclara, sujet(upa), Personne-autorise)

132

Chapitre 4 Le modle Or-BAC

privilge(upa) = consultation sous-vue(tab-dclara, cible(upa), table-personnes-autorise). Notons tout de mme que la vision prsente dans [Cuppens & Mige 2003a] considre lattribut initiateur comme lorganisation qui dcide de la dlgation (ltablissement dclarant) tandis que dans notre vision, il sagit de lorganisation dans laquelle la permission dapplique (ltablissement dclar). Cette section montre que le langage propos permet de couvrir la richesse des SICSS, notamment vis--vis de la reprsentation des permissions, des interdictions, des obligations et des recommandations. Nanmoins, comme tout langage bas sur la logique dontique, des questions comme linterprtation smantique des formules (modles de Kripke) simposent frquemment. cet gard, des techniques de dduction automatique, fondes par exemple sur la mthode des tableaux [Fitting 1993], ont t proposes. Entre autres, ils permettent de vrifier si, partant dun tat sr (qui satisfait les objectifs de scurit), et en appliquant les rgles de scurit, on retrouve un tat (une situation) ou certains objectifs de scurit sont viols (tat non sr). Un exemple de lapplication de la mthode des tableaux dans le cadre des politiques de scurit est donn dans [Ortalo 1998]. Afin de dtecter et rsoudre les conflits, on peut galement utiliser la logique possibiliste. Rappelons quun conflit peut tre dfini comme une situation dans laquelle un utilisateur aurait simultanment la permission et linterdiction, ou lobligation et linterdiction, deffectuer une action sur un objet (section 4.4.1.2, page 112). Par exemple, lapplication dun enchanement de rgles permet de dduire quun mdecin ne traitant pas un patient P na pas le droit de consulter son dossier mdical, alors quun autre enchanement de rgles permet de dduire quen cas durgence, nimporte quel mdecin peut lire le dossier mdical dun patient. Ces deux rsultats amnent un conflit dans le cas o un mdecin nayant jamais trait un patient veut lire son dossier alors quil y a urgence. Nos partenaires de MP6 proposent dutiliser la logique possibiliste [Benferhat et al. 2003] pour rsoudre ce type de conflits en associant, aux formules de la base, des coefficients de confiance allant de 0 1. Ainsi, dans notre exemple, si lon considre lurgence comme tant prioritaire, on donne un coefficient x1 pour la premire rgle, et x2 pour la deuxime, avec x1< x2. La comparaison des coefficients permet de ne retenir que la deuxime rgle.

Chapitre 6. Application dOr-BAC aux SICSS et mise en oeuvre

Prambule
Le modle Or-BAC a t associ, dune part, une spcification UML pouvant guider le processus de mise en uvre (chapitre 4), et dautre part un formalisme logique (chapitre 5) pouvant aider raisonner sur les permissions, obligations, interdiction et recommandation ; dtecter et rsoudre les conflits, etc. Le prsent chapitre propose une dmarche progressive fonde sur lutilisation dUML [Muller & Gaertner 2000 ; Booch et al. 1999] pour la dfinition dune politique de scurit fonde sur Or-BAC - dun systme ou dune organisation. Cette dmarche - qui peut tre applique diffrentes organisations - tient compte des aspects conceptuels, statiques et dynamiques de la politique de scurit. Nous allons ainsi montrer comment utiliser les diffrents diagrammes UML pour : reprsenter les interactions entre les utilisateurs et le systme ; spcifier les concepts de permission, interdiction ou obligation ; reprsenter des processus ; dtailler les types de relations ; etc. La deuxime partie prsente lanalyse conceptuelle, organisationnelle et oprationnelle que nous avons suivi pour mettre en uvre un logiciel de contrle daccs pour un centre de soins dentaires contenant plusieurs organisations (cabinets, services, etc.). Seuls les aspects dcrivant le passage entre la politique de scurit (fonde sur Or-BAC) et le contrle daccs seront abords en dtail. Lanalyse fonctionnelle du logiciel est donne en annexe D.

134

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

6.1. Dmarche UML

Avant de spcifier une politique de scurit sous une forme compatible avec Or-BAC, il faut tout dabord dcrire cette politique (fonctionnement pertinent vis--vis de la scurit, analyse des risques, objectifs de scurit, rgles de scurit, etc.). Pour cela, nous proposons de suivre la dmarche suivante : La premire tape consiste dterminer le besoin. Cette tape a t dcrite dans le troisime chapitre. Rappelons tout de mme quelle se base sur les informations recueillies sur le systme (textes et lois juridiques, documents dcrivant lorganisation, etc.) pour identifier les ressources protger, les menaces, les objectifs de scurit ainsi que les rgles de scurit. La dtermination du besoin correspond ainsi une description, dans un langage trs proche des utilisateurs, de la politique de scurit quon veut modliser et mettre en place. La deuxime tape consiste reprsenter le besoin. Dans une dmarche classique, et pour des raisons de simplification et de dcouplage, lespace des besoins est segment selon les points de vue de chaque acteur (catgorie dutilisateurs : rles, quipes, organisations). Cette segmentation permet dexprimer, acteur par acteur, les attentes (en terme de services, fonctions) vis--vis du systme. La dcomposition des besoins en acteurs est appele dcomposition en cas dutilisation. Chaque cas dutilisation apparat comme une classe de scnarios. Chaque scnario (instance de cas dutilisations) est, en ralit, une squence dvnements (interactions entre les utilisateurs et le systme) qui peut tre reprsente par un diagramme de squences. Si les cas secondaires (particuliers) sont nombreux, lutilisation des cas dutilisation est moins pertinente et il nous semble plus judicieux dopter pour une reprsentation plus abstraite laide des diagrammes dtat-transition . En amont des cas dutilisation, les diagrammes dactivits peuvent reprsenter clairement les acteurs et leurs responsabilits dans le fonctionnement. Lors de la construction des cas dutilisation, il faut se poser des questions du type : Quelles sont les tches de chaque acteur ? Quelles informations doit-il crer, modifier, dtruire, lire ? Lacteur devra-t-il informer le systme des changements externes ? Le systme devra-t-il informer lacteur des changements internes ? La troisime tape est lanalyse du domaine. La modlisation par les cas dutilisation suit un critre de dcomposition fonctionnel. Si ce critre de dcomposition est conserv lors du passage larchitecture, le systme sera difficilement extensible. Ltape de lanalyse du domaine doit ainsi assurer la transition vers une vision objet , puis montrer comment les groupes dobjets collaborant (initialement issus du domaine et complts par des objets de conceptions) ralisent les interactions dcrites dans les diagrammes de squences (qui documentent les cas dutilisation). Bien videmment, la vision oriente-objet, intgre ce niveau de lanalyse, tient compte des principes dencapsulation, dabstraction et de polymorphisme. En outre, une modlisation UML repose sur une consolidation mutuelle de deux points de vue complmentaires : dynamique et statique. Les aspects dynamiques sont reprsents par des diagrammes de squences et de collaborations (pour les cas particuliers) et par des diagrammes dtats-transitions ou dactivits (pour les cas gnraux). Les aspects statiques sont exprims sous la forme de cas particuliers, dans les diagrammes objets (comme charpente de diagrammes de collaboration) et sous la forme de cas gnraux dans les diagrammes de classes. Lanalyse du domaine est complte par deux autres tapes : la description de linteraction Homme-Machine (IHM) et le dploiement du code excutable (reprsentation des lments de

135

ralisation : fichiers, modules, bibliothques, etc., puis description de lenvironnement dexcution). Les cas dutilisation sont dcrits de manire textuelle, agrments de quelques diagrammes dinteraction. ce stade de la modlisation, les interactions reprsentent les principaux vnements qui se produisent. Plus tard, lors de la conception, ces vnements seront traduits en messages qui dclenchent des actions. Dans un premier temps, seuls les scnarios nominaux (processus de soins) sont dcrits. Nous rappelons que ltude des cas dutilisation a pour objectif de dterminer ce que chaque acteur attend du systme, et que la dtermination des besoins est base sur la reprsentation de linteraction entre les acteurs et le systme. Pour faciliter la comprhension, lapplication de notre dmarche sappuie sur un exemple simple, que nous allons tendre au cours de lanalyse. Le tableau 6.1 rsume les fonctions accomplies par chaque acteur (nous limitons ltude aux rles, le mme raisonnement peut tre suivi pour les autres acteurs : quipes et organisations) [Abou El Kalam & Deswarte 2004].
Acteur Rle dans organisation Supervision du centre Directeur Activit Lecture (R) Modalit daccs Vue Donnes de gestion administrative, technique et comptable Table associant les individus aux rles quils jouent dans le centre Fichier des rendez-vous Dossier du patient sauf la partie interrogatoire Toutes les informations y compris la partie interrogatoire Ordonnance Informations administratives Facture, fichiers de comptabilit

Mise jour de la table du personnel

Professionnel de sant Prise des rendez-vous (dentiste, secrtaire) Soins durgence Dentiste non-traitant Soins : consultation, diagnostic Prescription Enregistrement et gestion des informations administratives Facturation et gestion comptable

Lecture, criture (W), mise jour (U), destruction (D) R, W, U, non-destruction R R, W, U, non-destruction

Dentiste traitant

Secrtaire Comptable

R, W, non-destruction R, U, W, D R, W

Tableau 6.1 : Forme textuelle dun exemple de politique de scurit. Cette reprsentation peut tre spcifie, en UML, laide du diagramme de cas dutilisation de la figure 6.1.

136
Interrogatoire << include >> Soins Dentiste traitant << extend >> Si conditions d'urgence << include >> << include >> << include >>

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

Consultation Supervision Diagnostic

Prescription

MAJ table personnel << include >>

Directeur

Dentiste Non traitant

Soins d'urgences

<< include >> << include >> Contrle daccs << include >>

<< include >> << include >> Gestion administrative Secrtaire

<< include >>

Facturation Comptable

Professionnel de sant

RDV

Figure 6.1: Exemple de diagramme de cas dutilisation. Dans ce diagramme de cas dutilisation, nous distinguons deux types de relations : - la relation extend dont le cas dutilisation source est soins durgence et le cas dutilisation destination est soins ; cette relation indique que, si les conditions durgences sont vrifies, le comportement du cas dutilisation soins durgence ajoute son comportement au cas dutilisation soins ; autrement dit, les soins ne sont dcrts soins durgence que si certaines conditions sont vrifies; - la relation include qui permet de dcomposer des comportements partageables entre plusieurs cas dutilisation ; dans notre cas par exemple, toutes les fonctions doivent passer par la phase contrle daccs. Pour capturer les aspects temporels des interactions entre objets, chaque cas dutilisation est ensuite dcrit laide dun diagramme de squence. titre dexemple, nous dtaillons deux cas dutilisation : - gestion utilise par la secrtaire pour modifier les informations dun patient (figures 5.2a et 5.2-b) ; - contrle daccs, inclus dans chacun des cas dutilisation de la figure 6.1. La figure 6.2-a exprime les squences ncessaires lexcution du cas dutilisation gestion. La secrtaire demande au systme dinformation de lui fournir les informations quelle souhaite modifier34. Sa requte passe par une phase de contrle daccs que nous dtaillons dans la figure 6.3. Si cette tape est russie, le systme lui fournit la liste des patients auxquels elle peut accder. Une fois le patient choisi, le systme affiche les informations concernant ce patient, auxquelles linfirmire a le droit daccder. Dans ce cas, il sagit dinformations dordre administratif. Aprs modification, le systme effectue les sauvegardes demandes. Cet enchanement doprations est dabord dcrit par un diagramme de squence (figure 6.2-a). Celui-ci peut automatiquement tre traduit en un diagramme de collaboration (figure 6.2-b). Nous expliquons par la suite que ces deux diagrammes permettent de capturer deux aspects complmentaires : temporel et spatial.

34 Dans ce diagramme, on ne sinteresse qu la phase dautorisation. Nous supposons ainsi que les phases didentification et dauthentification se sont bien effectues et que la secrtaire dtient une preuve du succs de ces tapes. Dans la suite de cette section, dautres diagrammes dtailleront les phases didentification et dauthentification.

137
: Secrtaire : Base de donnes

Demande modification informations d'un patient Contrle d'accs Liste des patients auxquels elle peut accder Choix d'un patient Contrle d'accs : quelles informations ? Informations administratives concernant le patient Modification informations Informations sur le patient Sauvegarde

Figure 6.2-a : Exemple de diagramme de squence.

7: Modification informations

2: Contrle daccs 5: Contrle d'accs : quelles information ? 9: Sauvegarde

Sec1 /Secrtaire: Utilisateur

1: Demande modification infos patient 4: Choix d'un patient 8: Informations sur le patient
BD

3: Liste patients auxquels elle peut accder 6: Informations administratives concernant le patient

Figure 6.2-b : diagramme de collaboration correspondant. Afin dclaircir les liens entre les diffrentes phases didentification, authentification et autorisation, il nous semble ncessaire de dcrire lenchanement temporel des tapes du contrle daccs avant dautoriser (ou non), linvocation dun objet local (figure 6.3). Celui de la figure 6.4 dcrit le cas o lobjet invoqu est distant (cas plus gnral). Ces deux diagrammes modlisent le schma dautorisation dvelopp et implment dans le cadre du projet MAFTIA [Deswarte et al. 2001].

138
: Utilisateur : Moniteur de Rfrence

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

Objet invoqu : Serveur dAutorisation

Demande d'accs P?:=Accs( rle, objet invoqu, contexte, ... )

Extraction rgles concernes demande avec paramtres d'invocation Evaluation paramtres dans rgles Rsolution conflits Dcision Gnration preuves d'autorisation preuves signes par la cl prive du SA Signature preuves

Si SA distribu assemblage signatures Vrification signature des preuves Stockage preuves Interception Extraction capacit associe cette invocation Vrification signature capacit Dchiffrement capacit avec sa cl prive Contrle cohrence Invocation autorise Retour invocation

Dsignation premier objet invoquer

Invocation mthode m de l'objet O1 avec les paramtres param O1.m(param)

Figure 6.3 : Contrle daccs dans le cas dune invocation dun objet local. Dans la figure ci-dessus, lutilisateur envoie une requte avec un ensemble de paramtres comme son rle, lobjet invoqu et le contexte. Le moniteur de rfrence de sa machine intercepte la requte et lenvoie au serveur dautorisation. Ce dernier interroge la politique de scurit et extrait les rgles qui permettent de dcider dans le cas courant. Il value les paramtres de la requte dans ces rgles, rsout les conflits35 ventuels, et renvoie sa dcision (est-ce-que laction est permise, interdite, obligatoire ou recommande ?). Ensuite, il gnre un ensemble de preuves dautorisation associes cette action, signe cet ensemble (avec sa cl prive) et lenvoie au moniteur de rfrence. Dans le projet MAFTIA, une preuve dautorisation est dfinie comme un n-uplet dont les lments sont les capacits donnant le droit un sujet de raliser une action. Si laction comprend dautres actions composites, cette preuve contient des coupons. Chaque coupon regroupe les capacits ncessaires la ralisation de laction composite. Lobjet qui reoit une preuve dautorisation pour raliser une action composite, utilise les capacits qui lui sont destines, et achemine les autres capacits, aux autres objets intervenant dans le reste de laction [Deswarte et al. 2001]. Comme il ne sagit que dun accs un objet local, le moniteur de rfrence qui reoit les preuves dautorisation est celui du demandeur. Il stocke les preuves, et envoie lutilisateur le nom du premier objet invoquer. Quand lutilisateur invoque la mthode de cet objet, le
35 Un conflit peut tre, par exemple, le cas o la drivation dun ensemble de rgles permet dautoriser laccs, alors quune autre drivation impliquant dautres rgles linterdit.

139

moniteur de rfrence intercepte cette invocation, extrait les capacits qui lui sont associes, vrifie leurs signatures, et les dchiffre avec sa cl prive. Il effectue galement des contrles de cohrence avant dinvoquer lobjet concern. Le cas gnral o lobjet invoqu est situ sur une machine distante est prsent dans la figure 6.4.
: Utilisateur : Moniteur de rfrence (MR) Machine utilisateur : Serveur d'Autorisation (SA) Extraction rgles Evaluation paramtres dans rgles Rsolution conflits Dcision Gnration preuves d'autorisation Envoi preuves signes Vrification signature Envoi premier objet invoquer Stockage preuves Signature preuves : MR Objet invoqu Objet invoqu

P?:=Accs( Demande d'accs rle, objet invoqu, contexte, ... )

demande avec paramtres invocation

Invocation mthode m de l'objet O1 avec les paramtres param O1.m(param)

Interception Envoi capacits chiffres signes Envoi Acquittement (Ack) sign (accompagn du certificat Pour que le MR de l'utilisateur puisse vrifier la signature) Vrification certificat de l'objet destinataire OK ? + retour Acquittement Vrification signature Dchiffrement capacit Stockage des coupons ( capacits) ncessaires au reste de l'action Contrles de cohrence : compatibilit des paramtres d'invocation avec ceux de la capacit, nonce, premption capacit ...

Retour

Invocation autorise

Retour

Figure 6.4 : Contrle daccs dans le cas dune invocation dun objet distant. Il est important de signaler que, dans les schmas classiques de dlgation (bass sur la procuration) un objet transmet un autre objet certains de ses privilges pour quil puisse raliser une tche en son nom. linverse, le schma propos par MAFTIA applique le principe du moindre privilge car, mme si un utilisateur contribue une action composite, il ne peut effectuer que les actions quil a le droit dexcuter. Chaque objet excute sa partie de laction avec sa propre identit. Un objet peut donc recevoir des droits ponctuels pour excuter une partie de laction composite, sans ncessiter que lobjet qui les lui transmet possde ces droits. La figure 6.5 illustre le diagramme de collaboration correspondant au diagramme de squence de la figure 6.6.

140

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

3: Extraction rgles 4: Evaluation paramtres 5: Rsolution conflits 6: Dcision : Serveur d'Autorisation (SA) 7: Gnration preuves d'autorisation 8: Signature preuves 9: Envoie preuves signes 18: Vrification signature capacits 19: Dchiffrement capacits 20: Stockage coupons 21: Contrle cohrence

2: Envoi demande

10: Vrification signature preuves 11: Stockage preuves 15: Envoie capacits chiffres signes 14: Interception invocation 17: Retour Ack : MR : Moniteur de rfrence (MR) Objet invoqu Machine utilisateur 16: Ack sign 12: Envoie premier objet invoquer 24: Retour 23: Retour 22: Autorisation

1: Demande d'accs 13: Invocation mthode : Utilisateur : Objet invoqu

Figure 6.5: Diagramme de collaboration (invocation dun objet distant). Nous venons dexpliquer comment reprsenter une politique de scurit laide des cas dutilisation. Nous avons dtaill, travers des diagrammes de squences, les tapes de certaines procdures daccs (cas dutilisation gestion et contrle daccs). Le diagramme dactivit36 de la figure 6.6 reprsente un scnario rcapitulatif des phases prcdant la dcision daccs (est ce que laccs est autoris, refus, obligatoire ou recommand). Un utilisateur useri commence par sidentifier et sauthentifier. Le systme rcupre ses attributs, lui propose de choisir un rle, rcupre et vrifie la hirarchie et le contexte du rle (en loccurrence lexclusion mutuelle). Ltape suivante consiste choisir une organisation (ou crer une nouvelle organisation). Dans cet exemple, nous supposons que lutilisateur a choisi orgj et rlek, et que lorganisation est une quipe de soins. Le systme vrifie si lutilisateur a le droit de jouer rlek dans orgj, avant de rcuprer et de vrifier le contexte de lorganisation (lieu, certaines rgles de fonctionnement, unit de rattachement, etc.). Lutilisateur a ensuite trois alternatives : choisir un processus de soins parmi les processus enregistrs dans le serveur et auxquels son organisation participe ; crer un nouveau processus (seulement si rlek = mdecin) ; ou dclarer, dans des cas particuliers et bien dfinis, un objectif dutilisation. Dans ce dernier cas, le systme vrifie les conditions a priori et lance le contrle a posteriori. Une requte daccs tient compte de paramtres tels que : les attributs de la connexion et de lutilisateur, de la fonction joue (rle dans une organisation), de lactivit raliser, ainsi que du contexte (du rle, de lobjet, de lorganisation et de lutilisation prtendue). Le systme extrait la ou les rgles de scurit concernes, value ensuite les paramtres de la requte dans ces rgles (instanciation et dduction) et gre les conflits ventuels avant daccorder ou de rejeter la requte daccs.

Certes, les diagrammes dactivits sont moins dtaills que les diagrammes de squences, mais ils peuvent parfois offrir une vision glogale qui masque certains aspects, facilitant ainsi la comprhension pour certains types dutilisateurs finaux.

36

141
Identification et authentification valides Rcupration des attributs de l'utilisateur Choix R le Vrification du r le jou

Dbut
Rcupration param tres connexion (instant de connexion, adresse IP, ...)

[Non OK] [OK] Rcupration et V rification du contexte, des contraintes et de la hi rarchie de rle [Non OK] [OK, possibilit cration nouvelle quipe] Vrifier si le r le jou est mdecin [OK, quipe existe] Choix Equipe existante

Dconnexion ou modification des paramtres dj enregistr s (quipe, rle, activit , contexte)

[Non OK]

[OK] cration nouvelle quipe

Fin
Excution Opration

[Non OK]

[OK]

Vrification de la fonction : Rle dans organisation/ quipe

[Non OK] [OK]

Autorisation action [OK]

[Non OK] [Non OK]

Rcupration des lments en relation avec l'quipe: unit , groupe, etc. [exception] [OK, possibilit cration d'un nouveau processus] Vrifier si le rle est mdecin [OK, Equipe participe un processus] Choix processus [OK] Processus cr Participation processus Prparation contr le a posteriori Dclaration Objectif d'utilisation Contrle a priori

Extraction r gle, valuation param tres dans rgles, gestion des conflits

Choix activit rcuprer composition de groupes, hirarchie de classes ... Choix Objet/groupe

Enregistrement du contexte de l'utilisation (objectif ou processus)

Figure 6.6 : Diagramme dactivit rsumant les scnarios daccs. Pour rsumer, UML dfinit les cas dutilisation au moyen de collaborations entre objets du domaine. Chaque collaboration regroupe un contexte dobjets et une interaction entre ces objets. Les diagrammes de squences ainsi que les diagrammes dactivit reprsentent les interactions en favorisant laspect temporel ; tandis que les diagrammes de collaboration insistent sur la structure spatiale qui permet la mise en uvre de la collaboration dun ensemble dobjets. Le contexte dobjets est exprim de manire particulire dans les diagrammes de collaboration et de manire gnrale dans les diagrammes de classe. Pour une application spcifique, un diagramme de classe, peut tre dduit de la manire suivante : - dabord reprsenter les acteurs ainsi que leurs fonctions dans le diagramme de cas dutilisation ; - puis dtailler chaque cas dutilisation laide de diagrammes dinteraction (celui-ci donne une reprsentation temporelle des interactions entre les acteurs et le systme) ; chaque diagramme dinteraction correspond un diagramme de collaboration qui insiste sur laspect spatial des interactions entre objets, instances des acteurs ; - une bauche de diagramme de classe est automatiquement dductible partir dun diagramme de collaboration ; - le diagramme de classes est obtenu automatiquement par un assemblage des diffrentes bauches ;

142

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

enfin, liminer les associations redondantes et ajuster le modle. Lutilisation dUML pour spcifier une politique de scurit permet de montrer les deux niveaux dabstraction du modle Or-BAC : - niveau abstrait ( description gnrale au niveau spcification), reprsent par des diagrammes de squences, de classes, de cas dutilisations, etc. ; - niveau concret qui reprsente les entits du monde rel (description spcifique au niveau instance), laide de diagrammes dobjets et de diagrammes de collaboration ; ce niveau reprsente une instance particulire dune interaction avec les objets, les liens, les stimulus (instances de messages) changs, etc. -

6.2. Spcification des concepts de la politique de scurit

6.2.1. Concepts structurels
Plusieurs sections du quatrime chapitre expliquent les dtails de modlisation des entits dune politique de scurit associe Or-BAC (pages 101 110). En loccurrence, ils montrent que les RdO (Rle dans Organisation), VdO, AdO et CdO sont des classes associations entre lorganisation dune part, et le rle, la vue, lactivit et le contexte. Un rle (mdecin par exemple) est modlis par une classe dont le nom est celui du rle (mdecin). Les attributs de la classe dcrivent les proprits qui caractrisent les objets jouant le rle, cest--dire, les objets ayant un comportement similaire celui identifi par le rle. La spcialisation entre rles peut tre modlise par un hritage (entre ces rles). Une organisation a t dfinie comme tant un groupe structur dentits actives (section 4.2.1, page 110). Elle peut donc tre modlise par une composition dobjets du systme, ou par llment de spcification UML sous-systme37. Les objets du systme sont modliss par des objets UML. Chaque objet appartient toujours une classe qui peut changer au cours du temps. En loccurrence, le fait quun objet puisse tre tantt actif (un patient qui consulte son dossier mdical, et joue ce titre le rle patient) tantt passif (lorsque linfirmire lui fait une injection par exemple) est parfaitement modlisable laide de lhritage multiple entre classes. Les strotypes dUML peuvent galement tre utiliss pour prciser la smantique de certains lments comme les organisations, les rles, etc. Les contraintes peuvent tre exprimes de plusieurs manires : - par des contraintes de multiplicit sur les relations ou sur les classes ; par exemple pour restreindre le nombre dutilisateurs jouant un rle ou appartenant une organisation, contraindre la structure dune organisation, etc. ; - par des expressions du langage OCL (Object Constraint Languge) ; celui-ci permet dexprimer de manire formelle, des contraintes sous forme dexpressions boolennes prdfinies ou personnalises, par exemple, les contraintes sur le comportement dun certain rle ; nanmoins, le langage OCL reste peu expressif, il ne dispose pas dune smantique explicite et ne permet pas dexprimer certaines contraintes importantes pour la scurit comme les contraintes temporelles ; - par du pseudo-code ou en langage naturel, bien entendu, de manire informelle.

37 En UML, un sous-systme est dfini comme tant un ensemble dlments qui reprsente une unit comportementale du systme physique.

143

6.2.2. Concepts comportementaux

Afin de modliser les actions avec UML, il est possible dutiliser les changes de messages entre objets (invocation dune mthode, par exemple). Dans les cas o lon souhaite modliser les interactions entre des organisations, les actions peuvent tre modlises par des transitions entre des diagrammes dobjets. Bien videmment, la transition doit tre tiquete par la rgle de scurit dfinissant la modalit (permission, interdiction, obligation ou recommandation) de laction, Si cette modalit est conditionnelle (par exemple, de la forme : il est permis que X seulement si Y), les conditions sont donnes par des expressions logiques (dans une notation proche du langage OCL). Comme indiqu sur la figure 6.7, une rgle de scurit est reprsente par une relation de dpendance entre deux sous-systmes : - La relation de dpendance est labellise par le nom de la rgle et possde une note avec la condition de garde. - Le sous-systme avant reprsente les conditions ncessaires pour que laction soit ralise, tandis que le sous-systme aprs reprsente les effets de laction sur le systme.
Sous-systme Avant O1 : C1 {attr1 = X} O2 : C2 {attr2 = Y}

Rgle de scurit

Sous-systme Aprs O1 : C1 {attr1 = Z} O3 : C3 O2 : C2 {attr2 = X+Y}

Condition de garde (if .)

Figure 6.7: Exemple de reprsentation UML dune rgle de scurit. Il est vident que la smantique et la nature des composants de la transition (sous-systmes avant et aprs, conditions de garde) dpendent de la modalit de cette rgle. Ainsi : - Une permission est reprsente par une transition dont le sous-systme avant et les conditions de garde dterminent le scnario des actions permises ainsi que les participants (organisations, rles, etc.) ce scnario ; tandis que le sous-systme aprs reprsente les effets de laction. - Une obligation interne est modlise par un ensemble dactions que le systme doit assumer. Par exemple, lobligation de redmarrer une machine quand un vnement se produit. - Une rgle dobligation externe, cest--dire une obligation due des entits externes au systme, peut tre modlise par des chiens de garde observant les violations possibles de lobligation et dterminant un plan de reprise (actions correctrices, par exemple) appropri (activable en cas de violation). - Une rgle dinterdiction peut tre modlise de manire similaire aux permissions (rgle conditionnelle), mais sans tat aprs.

6.3. Exemple de mise en uvre

Nous avons dcrit le mta-modle Or-BAC en utilisant deux visions : une vision logique qui sert raisonner sur la politique de scurit, et une vision gnie-logiciel qui guide le processus de mise en uvre. Dans le cadre du projet MP6, nous tudions actuellement la premire tche, tandis que dans cette section, nous prsentons comment nous avons implment la politique de scurit associe Or-BAC dans un cas concret du domaine mdical : centre de soins dentaires multiorganisationnel.

144

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

Le centre dentaire que nous considrons est une unit de soins (organisation) compose de trois cabinets (sous-organisation), dun laboratoire de prothse (sous-organisation) et de trois services : rception, administration et comptabilit. Chaque cabinet contient au moins un chirurgien dentiste (et parfois une assistante) ; le service administratif emploie une ou plusieurs secrtaires mdicales ; au service de comptabilit sont affects un ou plusieurs comptables ; tandis quun ou plusieurs prothsistes oprent dans le laboratoire de prothse. Selon la terminologie dOr-BAC, nous avons : - Les organisations : centre dentaire, cabinet dentairei, cabinet dentairej, cabinet dentairek, service de rception, service administratif, service de comptabilit et laboratoire de prothse. - Les relations de compositions entre organisations : sous-organisation(centre dentaire, cabinet dentaire1), , sous-organisation (centre dentaire, cabinet dentaire3), sousorganisation(centre dentaire, service administratif), etc. - Les rles : administrateur, directeur, professionnel de sant, chirurgien dentiste, secrtaire, comptable et prothsiste. - Hirarchie de rles : "org Organisation, sous-rle ( org , chirurgien dentiste, professionnel de sant), sous-rle(org, secrtaire mdicale, professionnel de sant), etc. - Les rles jous 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 rception, s6, secrtaire mdicale), RdO(service administratif, s7, secrtaire mdicale), RdO (service de comptabilit, s8, comptable), RdO(laboratoire de prothse, s9, prothsiste), etc. tant donn que ladministrateur peut ajouter dautres rles ou organisations, et que le directeur peut modifier la table du personnel du centre, la liste prsente ci-dessus nest pas limitative et peut voluer au cours du temps. Toutefois, laffectation dun utilisateur plusieurs rles doit respecter les rgles dexclusion mutuelle. Par exemple, un sujet ne peut pas tre la fois comptable et directeur du centre. Une analyse fonctionnelle dtaille de notre application est donne en annexe D. Dans la suite de cette section, nous ne prsentons que certains aspects relis la scurit. Les droits daccs implments sont ceux prsents dans le tableau 5.1 de la page 129. Nous avons ainsi les objectifs et les rgles de scurit suivants : - Objectifs de scurit : il est interdit aux administrateurs, secrtaires, comptables, prothsistes et assistantes de crer des ordonnances ; excepts les dentistes traitants, les utilisateurs nont pas le droit daccder la partie interrogatoire ; seul le directeur peut mettre jour la table du personnel ; les diagnostics ne peuvent jamais tre effacs ; les oprations de soins ne sont permises quaux utilisateurs qui sont personnels soignants en charge du patient ; le comptable a les droits consultation et cration ainsi que les interdictions non mise jour, non destruction sur les factures de tous les patients ; .. - Rgles de scurit : Dans des cas durgence o en plus, le dentiste traitant est absent, tout autre dentiste peut accder au dossier mdical du patient en dclarant lobjectif dutilisation urgence

145

non habituelle ; en mme temps, le systme enregistre automatiquement les paramtres de laccs dans le fichier daudit. Les autres accs doivent sinscrire dans des processus habituels dcrits par le modle conceptuel de traitement. Dune manire gnrale, le logiciel que nous avons mis en uvre ralise deux types de contrles : - Contrle daccs respectant la politique de scurit associe Or-BAC. En effet, il prend en considration : les rles jous dans les organisations, les diffrents types du contexte, les vues, etc. - Contrle de cohrence et vrification de la validit des donnes saisies. Pour implmenter les entits de notre application, nous avons fait le choix dutiliser une base de donnes sous SQL. Nous avons ainsi les tables : utilisateur, intervention, rendez-vous, mdicament, ordonnance, etc. (voir spcification fonctionnelle en annexe D). Compte tenu de la grande quantit de donnes grer et de lhtrognit de ces donnes, ce choix nous semble le plus adapt. linverse, les mcanismes de contrle daccs SQL tant insuffisants pour ce type dapplications, nous les avons grs au niveau du langage de programmation (Visual Basic 6). Dans la spcification du modle Or-BAC en UML, les notions les plus importantes sont des classes (les rles, par exemple) ou des classes-associations (les RdO Rles dans Organisation, par exemple). Dans limplmentation, une classe devient une table ayant comme champs, les attributs de la classe ; tandis quune classes-associations C entre deux classes A et B devient une table ayant comme cl primaire la concatnation des cls de A et B. La figure 6.8 donne lexemple de la classe association Rle-dans-Unit.
CREATE TABLE Rle ( Id_Md Number (5), PRYMARY KEY (Id_Rle) ) CREATE TABLE Unit ( Id_Unit Number (5), PRYMARY KEY (Id_Unit) )

Rle

Unit

Rle-Dans-Unit

CREATE TABLE Rle-Dans-Unit ( Id_Md Number (5) REFERENCES Mdecin (Id_Rle) ON DELETE CASCADE, Id_Md Number (5) REFERENCES Unit (Id_ Unit) ON DELETE CASCADE, PRYMARY KEY (Id_Rle, Id_Unit ))

Figure 6.8 : Implmentation des RdO en bases de donnes. Il est important de noter que la table Rle-dans-Unit ne stocke jamais les attributs du rle, ni ceux de lunit ; elle fait seulement rfrence aux cls trangres Id_Rle et Id_Unit. La cl primaire de la table Rle-dans-Unit est la concatnation de la cl de la table Rle et celle de lunit. En outre, la contrainte ON DELETE CASCADE permet de maintenir lintgrit rfrentielle en supprimant automatiquement de la table Rle-dans-Unit les valeurs des cls trangres Id_Rle ou Id_Unit, chaque fois que lune de ces cls est supprime des tables Rle ou Unit.

146

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

Pour implmenter une classe B qui hrite dune classe A, il suffit de crer deux tables A et B et de faire rfrence dans la table B la cl de A. Par ailleurs, les permissions, interdictions, obligations et recommandations sont gres au niveau du logiciel de programmation de la manire suivante : - Les permissions sont implmentes travers des capacits associes aux profils des RdO. - La politique mise en uvre considre que tout ce qui nest pas explicitement autoris est interdit ; dans certains cas, des interdictions sont exprimes travers des capacits ngatives et sont renforces par des botes de dialogues indiquant lutilisateur quil nest pas autoris faire laction demande. - Les obligations sont implmentes par des actions automatiques comme lenregistrement (automatique) de certaines donnes de connexion dans un fichier daudit ou la fermeture (automatique) de lapplication. - Les recommandations sont pour le moment implmentes travers laffichage dune bote de dialogue avec un message de recommandation ainsi quun enregistrement automatique du choix fait par lutilisateur. Ainsi, nous pensons quune recommandation est une autorisation qui, si elle nest pas respecte, engage la responsabilit de lutilisateur (cest la raison pour laquelle le systme enregistre le choix de lutilisateur). chaque connexion, lidentification et lauthentification se font par vrification, 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

Figure 6.9 : Phases didentification et dauthentification. Remarquons que durant les phases didentification et dauthentification, lutilisateur se voit dj attribuer un profil. En effet, chaque nom de login correspond un profil ; celui-ci est un numro qui correspond un role dans une organization RdO. Les rgles de scurit sont codes au niveau du langage de programmation en associant chaque profil des permissions (ou interdictions ou obligations ou recommandations) de raliser des activits sur des vues. La figure 6.10 exprime que seuls les utilisateurs jouant des RdO

147

correspondant aux profils infrieurs au profil 5 ont la permission de visualiser (VdO show) les dossiers des patients (lments de la VdO frm_patient_U1).
If profil < 5 Then frm_patient_U1.Show 1 Else MsgBox "Vous n'tes pas autoris accder la gestion des patients ...", vbCritical End If

Figure 6.10 : Exemple dimplmentation dune rgle de scurit. Lapplication contrle daccs pour un centre dentaire, ainsi prsente et modlise, a t implmente en utilisant Visual Basic 6. Elle est disponible sous forme de dmonstration. Outre laspect scurit, son utilisation par tous types dutilisateurs est facile. Elle rpond nos besoins : ralisation dun contrle daccs respectant notre politique de scurit, automatisation de la recherche dinformations autorises sur les patients (gain de temps et disponibilit), possibilit dajouts de nouveaux utilisateurs, rles, organisations, etc. Cette application est, pour le moment, restreinte une implmentation logicielle des permissions par des listes de contrles daccs, et des interdictions par des capacits ngatives. Elle pourrait tre tendue pour intgrer de nouveaux mcanismes de contrles daccs. Bien videmment, les apports dOr-BAC vont au dl de la mise en uvre dcrite ci-dessus ; et nous sommes actuellement en train dimplmenter Or-BAC dans un environnement heterogne et distribu - faisant intervenir deux organisations distantes (deux hpitaux). Le but est de montrer quOr-BAC fournit un cadre homogne ou chaque organisation spcialise (implmente) ses entits (activits, vues, etc.) comme elle le souhaite. La premire organisation utilise des documents XML alors que la deuxime utilise une base de donnes. Il en dcoule que la mme vue (mais aussi la mme activit) est implmente diffrement dans chacun des deux hpitaux. Un utilisateur commence par se connecter, puis envoie au serveur dautorisation (application client-serveur) son RdO (rle dans une organisation), ainsi que la VdO (vue dans une organisation). Leserveur dautorisation (SA) effectue les tches suivantes : - extrait les rgles concernes (qui font intervenir le RdO et la VdO) ; - construit une capacit (un objet au sens orient-objet) contenant les paramtres utils {RdO, VdO, (P/I/O/R, Activit1, contexte1), (P/I/O/R, Activit2, Contexte2), .. , (P/I/O/R, Activitn, Contexten)} ; ce qui signifie que le RdO la permission, linterdiction, lobligation ou la recommandation de raliser Activit1, (resp. Activit2, .. Activitn) sur la VdO dans Contexte1, (resp. Contexte 2, .. Contexte n) ; un contexte peut tre une dure de validit, un processus, etc. ; - envoie la capacit lutilisateur. Lutilisateur prsente cette capacit au moniteur de rfrence38 de lobjet demand (une table de la base de donnes, par exemple) en prcisant lactivit demande lors de cet accs. Le moniteur de rfrence (situ sur la machine de lobjet demand) dduit laction raliser (
38

Le moniteur de rfrence regroupe les mcanismes de protection permettant de garantir le contrle daccs et de flux dfinis par la politique de scurit. Toute tentative daccs est ralise via le moniteur de rfrence qui vrifie que chaque accs dun sujet vers un objet est garanti par un droit daccs.

148

Chapitre 6 Application dOr-BAC aux SICSS et mise en oeuvre

partir de lactivit), vrifie si le contexte est vrai, et donne sa dcision (permission, interdiction, obligation ou recommandation). Cette dcision sera traduite par des mcanismes locaux daccs. Pour limplmentation, nous avons fait les choix suivants (liste non exhaustive) : - le langage java pour la programmation ; - lAPI JDBC pour laccs la base de donnes ; - JAVA RMI pour linvocation des objets distants ; pour un objet client, linvocation est effectue dune manire transparente quelle soit faite sur un objet distant ou local ; - Un formatage de donnes avant la transmission et, de lautre ct de la communication, une adaptation aux logiciels de la machine locale de lutilisateur lors de laccs (pour visualisation ou modification, par exemple) ; pour cela, on utilise des Applets java ; - Le serveur dautorisation contient les rgles de la politique de scurit sous forme denregistrements dune table ; la centralisation ainsi que lisolation des rgles de la politique de scurit du reste de lapplication, nous facilitera la tche de vrification de la cohrence et de la compltude de cette politique.

Conclusion gnrale

Ce mmoire prsente une dmarche rigoureuse - fonde sur une politique de scurit - pour mettre en uvre une scurit de bon niveau dans les systmes dinformation et de communication. Cette dmarche a t applique aux domaines de la sant et des affaires sociales, qui prsentent lintrt de combiner de fortes exigences de confidentialit, dintgrit et de disponibilit, mais aussi de responsabilit. En conclusion rappelons la logique adopte tout au long de ce travail, et rsumons les rsultats obtenus. Tout dabord, plutt que de dresser un tat de lart exhaustif des politiques, modles et mcanismes de scurit, nous avons adopt une analyse pragmatique, opposant ces mthodes aux besoins rels des SICSS. Le but est non seulement de proposer une scurit robuste et bien fonde thoriquement, mais aussi flexible et adapte aux demandes des usagers. Nous avons galement opt pour une diversification des mthodes et outils utiliss pour la construction (progressive) de chaque solution propose : visions gnie-logiciel et formelle ; modlisation par MERISE et par UML ; dveloppement dun langage bas sur la logique du premier ordre, puis dun autre bas sur la logique dontique, etc. Le mmoire sest organis autour des axes suivants : Prsentation de ltat des lieux sectoriel, conceptuel et terminologique en scurit pour les SICSS . Cette tape commence par une description sectorielle fonde essentiellement sur les textes juridiques relatifs aux SICSS, puis prsente et tablit les liens entre les concepts et termes classiques de la sret de fonctionnement en gnral, et de la scurit informatique en particulier. Discussion de politiques classiques de scurit. Cette partie tudie en dtail les avantages et les limites de chacune des principales politiques existantes. Une rflexion particulire est porte la difficult de lapplication de ces approches aux SICSS : certaines introduisent une rigidit parfois incompatible avec les usagers, dautres ne tiennent pas compte du contexte et ne permettent pas de reprsenter des interdictions et des recommandations, etc. Dans le mme sens, les modles actuels sont parfois trop complexes ou difficiles administrer. laboration de politiques de scurit pour les SICSS. Nous avons, tout dabord, montr que la dfinition dune politique de scurit est une tape ncessaire pour obtenir des systmes pouvant satisfaire des exigences de scurit leves. Nous avons ensuite propos une mthodologie dont les principales tapes sont : la description du systme, lidentification des informations protger, la caractrisation des menaces, lexpression des objectifs de scurit ainsi que des rgles qui dterminent comment linformation sensible et les autres ressources sont gres, protges, et distribues. Cette dmarche est enfin applique pour tablir une politique de scurit dans un exemple de systme dinformation mdicale, et une autre pour un exemple de la sphre sociale. Prsentation dun nouveau modle de scurit. Pour spcifier les politiques dveloppes, nous avons propos, avec nos partenaires des sous-projets 3 et 4 de MP6, le nouveau modle

150

Conclusion gnrale

Or-BAC. Celui-ci permet dexprimer 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 lexpression des rgles, afin de spcifier un contrle daccs fin et adapt. Il est aussi un moyen de spcifier, dans un cadre homogne, plusieurs politiques de scurit pour des organisations diffrentes devant cooprer. Modlisation formelle dOr-BAC. Nous avons opt pour lutilisation de la logique dontique pour fournir un cadre permettant de spcifier formellement une politique de scurit base sur Or-BAC. Cette spcification peut ventuellement servir raisonner sur la politique de scurit, sa cohrence, sa compltude, etc. Si la politique de scurit est reprsente dans un langage de la logique dontique, la mthode des tableaux nous semble idale pour effectuer de telles vrifications. Par ailleurs, la logique possibiliste peut servir rsoudre les conflits ventuels dans la politique de scurit. Intgration dans un cadre de gnie logiciel. Le modle Or-BAC est dabord reprsent avec des diagrammes UML, puis intgr dans une dmarche UML globale, couvrant la fois les aspects statiques et dynamiques de la scurit. Dveloppement dun logiciel intgrant notre politique dautorisation. Cette tape distingue deux types danalyses : une analyse fonctionnelle (de lapplication elle-mme) couvrant les aspects conceptuels, organisationnels et oprationnels, pralable la mise en uvre ; puis indpendamment, une autre analyse scuritaire claircissant le passage entre la politique de scurit et les mcanismes de contrle daccs utiliss. Un logiciel de gestion dun centre dentaire a t implment pour dmontrer la faisabilit dune implmentation en vraie grandeur les diffrentes facettes dune politique Or-BAC. Mme si le travail prsent aboutit une implmentation, un certain nombre de points restent tudier. Ainsi, plusieurs perspectives de recherches peuvent tre distingues : - Dvelopper un scnario plus riche o plusieurs organisations de grandes tailles cooprent, et utiliser le formalisme logique associ Or-BAC pour effectuer un certain nombre de vrifications sur ce scnario. Les vrifications de la politique de scurit peuvent porter sur la consistance, la compltude, la non-existence de canaux dinfrence, etc. Il peut galement savrer important dautomatiser le test de la cohrence des politiques de scurit, cest--dire la dtection des conflits. Ceux-ci peuvent ventuellement tre rsolus par la logique possibiliste [Benferhat et al. 2003]. - Afin de faciliter la conception et la manipulation de politiques fondes sur Or-BAC, il serait souhaitable dutiliser une reprsentation graphique dont lintrt pratique peut savrer significatif si cette reprsentation est supporte par un outil ddition. - claircir le passage de la politique aux mcanismes de scurit (capacits distribues, interprtations XML, etc.). Dans les bases de donnes, ce passage serait automatisable tandis que dans dautres environnements, la politique serait interprte dans un serveur dautorisation. - Il est ncessaire dapprofondir les tudes concernant la proprit de disponibilit, proprit importante dans bon nombre dapplications mergentes ou futures. Des investigations doivent tre menes tant sur la faon de spcifier formellement le concept de disponibilit et le problme du dni de service au moyen dune politique de disponibilit, que sur les mcanismes capables dimplmenter cette proprit.

Annexe A : menaces pouvant avoir des consquences dans le monde mdical

A1. Menaces pouvant porter atteinte la confidentialit

Origine du problme Faute de conception. Menace Vulnrabilit Consquence Divulgation informations concernant personne. des une

Accs par d e s Le nom du patient utilisateurs externes est utilis comme non autoriss aux identifiant. donnes hberges sur le serveur dun hpital. Divulgation non autorise des donnes personnelles ; risque dinfrences, etc. Manque de restriction daccs aux utilisateurs (internes) du systme.

Agrgation et centralisation des donnes dans un dossier accessible par un grand nombre dutilisateurs. Faute de conception surtout pour les oprations du systme sociotechnique. Faute de conception surtout pour les oprations du systme sociotechnique ; logique maligne.

Le dossier devient une ressource prcieuse divulguer, plus facilement accessible que des dossiers multiples disperss ; risque de corruption des utilisateurs internes.

Accs plus largement M a n q u e de rparti a u x restriction daccs informations aux utilisateurs du mdicales. systme.

Faire modifier les dcisions qui doivent tre prises (embauches, prts, ). Risque de pressions politiques pour faire lgaliser lautorisation daccs des entits non ncessairement mdicales, pour exploitation des fins non mdicales (revente, etc.).

Agrgation Constitution de bases dinformations et de donnes convoites. non prise en compte du consentement du patient. Faute de conception surtout pour les oprations du systme sociotechnique.

Contrle daccs insuffisant ; absence ou insuffisance de la politique de scurit

152

Annexes

Origine du problme

Menace

Vulnrabilit

Consquence de Divulgation d e dinformations personnelles. Risque de divulgation des tiers non autoriss

Faute d e Possibilit daccs Possibilits conception ; faute direct un ensemble de c r o i s e m e n t dinteraction ; donnes. donnes. logique maligne. Faute d e Pressions directes ou conception surtout indirectes sur le patient pour les oprations du systme sociotechnique Faute d e Possibilit, pour un conception ou de assureur possdant un dveloppement simple lecteur de carte, de visualiser certaines informations sans carte CPS (Carte de Professionnel de Sant).

Certaines informations (par exemple, les informations ncessaires en cas durgence) restent de libre accs.

Risque de divulgation dinformations compromettantes pour lindividu comme certaines maladies invalidentes.

Faute d e Interconnexion entre Utilisation du NIR Perte des liberts conception ou de fichiers fiscaux et comme identifiant individuelles dveloppement mdicaux par le NIR. dans diffrentes bases de donnes. Logique maligne Faute dinteraction et parfois conception. Vol de donnes Accs non intentionnel. de Administrateur non digne de confiance : les droits de ladministrateur peuvent dpasser largement son besoin. Chevaux de Troie. Manque de restrictions daccs ou non respect du principe du moindre privilge. Manque protection. d e Utilisation dlictueuse de ces donnes. Divulgation non intentionnelle de ces donnes. Ladministrateur peut accder des informations quil na pas connatre.

Pour grer un systme informatique, il est ncessaire davoir un administrateur de la base. Logique maligne. Faute de conception

Utilisation dun T r a n s m i s s i o n de logiciel pig. donnes sensibles vers lextrieur, via le logiciel pig.

Mise en rseau des Risque dattaque de Rseau local pas A t t e i n t e s aux systmes mdicaux lextrieur ; risques assez protg. proprits de scurit ou systme mdical dusurpations didentit (divulgation ou sur rseau local reli utilisation illicite Internet. Logiques dinformations malignes sensibles etc.).

153

Origine du problme

Menace

Vulnrabilit

Consquence Atteinte la du confidentialit et lintgrit Possibilit de lire les messages dont le mdecin est destinataire ou metteur (rsultats laboratoires, avis dautres mdecins sur un certain cas, etc.).

Logiques malignes ; Interception possible Protection Fautes de conception des messages changs insuffisante par c o u r r i e r rseau. lectronique.

Stockage de la cl Risque de vol ou S t o c k a g e non prive dun mdecin piratage de cette cl scuris de la cl. sur un disque dur prive. lors de sa gnration par une socit commerciale en ligne. Logiques malignes ; fautes de conception. Utilisation dun algorithme de chiffrement non publi et donc peuttre non vrifi comme solide. Longueur insuffisante des cls. Logiques malignes ; Fautes de conception. Stockage de dossiers mdicaux centraliss sur sites web. Logiques malignes.

Possibilit d e Algorithme Possibilit de lire les dchiffrement o u vulnrable ou non messages dont le dcryptage par des robuste. mdecin est personnes non destinataire ou autorises. metteur. Possibilit d e Longueur dcryptage par des insuffisante personnes n o n cls. autorises. Violation de la des confidentialit et de lintgrit.

Attaques possibles de Architecture ces sites par des c e n t r a l i s de visiteurs (par exemple, dossiers mdicaux en utilisant les traitements invisibles avec Html). Utilisation de ces informations par un mdecin outrepassant sa fonction ou son besoin. Divulgation non autorise des informations situes sur ces dossiers.

Stockage clat des dossiers mdicaux sur les sites de diverses institutions. Faute de conception

A2. Menaces pouvant porter atteinte lintgrit

Origine Non intentionnel (exemple : erreur de saisie entre angine et angiome) ou malveillance. Faute dinteraction Menace Information introduite ou devenue fausse dans le systme. Vulnrabilit Absence de mcanisme de contrle des donnes saisies. Consquence Prise par le mdecin de dcisions errones causant du tort au patient ; erreur de diagnostic ; etc.

154

Annexes

Origine Rtention dlibre, par le patient, dinformations le concernant relative son tat de sant ou sa situation sociale, en vertu du principe du droit loubli (antcdent pathologique, pisode sociosanitaire antrieur). Faute dinteraction humaine. Non intentionnel

Menace Peur (par le patient) de violation de son intimit sociosanitaire ; perte de confiance en ce qui concerne la capacit du systme dinformation mdical ou social garantir la confidentialit des informations sensibles confies par lui. Risque possible de mauvais diagnostic, ordonnances, traitements.

Vulnrabilit Absence dans le systme de certaines informations pourtant ncessaires dun point de vue mdical.

Consquence Risque direct de non mise disposition par le patient dinformations sur son tat de sant ou, par lassur de la prcarit de sa situation sociale : informations pertinentes, dont peut en juger un mdecin ou une assistante sociale ; risque indirect de manque de pertinence du protocole de soins, des traitements ou de la prise en charge sociale.

Erreurs de conception ou de programmation des logiciels un des des ou

Faute d e Suppression conception ou de i l l g i t i m e dveloppement ; donnes. fautes dinteraction ; logique maligne.

Insuffisance de la Possibilit pour d e politique utilisateur deffacer dautorisation. dossiers montrant ngligences escroqueries.

Non intentionnel. Manipulations Absence Faute dinteraction. e r r o n e s d e s contrles donnes ou des logiciels. Faute d e Vol de donnes conception ; logique maligne.

d e Utilisation errone des donnes, des rsultats, des logiciels ; erreurs de diagnostic, etc. Utilisation errone ou impossible des informations.

Non intentionnel ou Feu, inondation, S t o c k a g e d u Risque de destruction malveillance dtrioration, etc. matriel non protg des informations. physiquement. Non intentionnel Mauvaise Absence de (exemple : patient identification du contrles g ou perturb) ou patient. (notamment de malveillance lidentification et de (usurpation lauthentification). didentit) Attribution errone de diagnostics, attribution errone ou illicite de soins ou de remboursements.

Mise en rseau des Plus grand risque M a n q u e d e Atteintes aux proprits systmes mdicaux. d a t t a q u e s d e protection vis--vis de scurit lextrieur des attaques extrieures.

155

Origine Logique maligne.

Menace Virus destins altrer malicieusement les dossiers mdicaux.

Vulnrabilit

Consquence

Manque de Altration des protections contre informations du dossier les logiques malignes.

Faute d e Interception, Logiciels de courrier A l t r a t i o n des conception ; modification des lectronique non informations contenues logique maligne. courriers scuriss dans les messages lectroniques. Stockage de dossiers mdicaux centraliss sur sites web. Attaques ou intrusions possibles de ces sites par des visiteurs. Architecture centralis suffisamment scurises. Atteinte lintgrit du n o n SICSS visit ; prise de contrle de lordinateur du visiteur, par le concepteur du site visit ; etc.

A3. Menaces pouvant porter atteinte la disponibilit

Origine Informatique ou tlmatique. Logique maligne ; Faute de conception. Menace Dfaillance informatique ou sabotage ou attaque entranant une information non disponible dans le systme. Attaques ou intrusions possibles de ces sites par des visiteurs ; etc. Dcs du mdecin ; perte du code et donc risque de discontinuit des soins sur le patient. Vulnrabilit Possibilit de retarder ou causer un dysfonctionnement du systme. Consquence Prise par le mdecin de dcisions errones causant du tort au patient ; erreur de diagnostic ; impossibilit dutiliser un dossier informatique comme preuve. Atteinte la disponibilit du SICSS visit ; prise de contrle de lordinateur, ou attaque du disque dur du visiteur.

Stockage de dossiers mdicaux centraliss sur sites web. Logique maligne Mise en place de de mcanismes didentification. Faute dinteraction ; Faute de conception ou de dveloppement

Architecture centralis non suffisamment scurise.

Mise en place dun Perte des donnes des mcanisme patients. dauthentification nayant pas prvu ce cas.

Mise en rseau des A t t a q u e s de systmes lextrieur (DDoS) mdicaux. Logique maligne

Risques dintrusions extrieurs (protection insuffisante).

Atteintes aux proprits de scurit.

156

Annexes

Peur du manque de confidentialit. Crainte dune faute de conception

Impossibilit dchange dinformations entre les institutions de sant.

Chaque institution R i s q u e de installe son propre interoprabilit. systme de confidentialit

non-

A4. Menaces pouvant porter atteinte lauditabilit

Origine Contexte durgence Logique maligne Menace Abus de pouvoir ; Utilisation abusive de droits valables en contexte durgence. Vulnrabilit Non respect du principe du moindre privilge ; politique de scurit non adquate. Consquence

Pour grer un systme informatique, il est ncessaire davoir un administrateur de la base. L o g i q u e maligne Non consentement du patient faire figurer des informations mdicales le concernant dans son dossier mdical ; dfaut dauthentification dune intervention sur le dossier mdical ; dfaut dauthenticit dune modification du dossier mdical ; dfaut dintgrit dun dossier mdical ;

Administrateur Manque de traabilit D i v u l g a t i o n ou non digne de et de procdures a l t r a t i o n de confiance q u i dissuasives. donnespersonnelles. abuse de ses pouvoirs.

Information manquante dans le systme, ou devenue fausse suite une malveillance (intrusion, accs trop libre, etc.)

Absence de trace ; absence dimputation ; dfaut dopposabilit ; absence de signature lectronique ; absence de justification authentique rendant probante la ncessit de : (i) dcider dun protocole de soins particulier appliquer, (ii) t a b l i r une prescription particulire et atypique, (iii) omettre certains mdicaments habituellement recommands en pareil situation (ici, cause dallergies non mentionnes, ou dantcdent non rappels,), etc.

Impossibilit dutiliser un dossier mdical (ou social, par analogie) informatis comme preuve pour justifier une dcision, une attitude ou une action pour un professionnel de sant (ou par un assistant social, par analogie).

157

Annexe B : Anonymisation des donnes du PMSI

Dans le cadre du PMSI (Programme de Mdicalisation des Systmes dInformation), tout tablissement de sant rend compte de son activit au moyen de rsums de sjour (RSS) pour les hospitalisations de court-sjour MCO, au moyen de rsums hebdomadaires (RHS) pour les sjours en soins de suite ou de radaptation. Le chanage des sjours est le complment ncessaire du dispositif de recueil dinformations. Il a deux rles essentiels : la validation de la qualit du codage des informations fournies ; la ralisation danalyses pertinentes des bases de donnes rgionales et nationales. Comme indiqu sur le schma rcapitulatif de la figure B1, la procdure se dveloppe en deux tapes : le numro de scurit sociale est anonymis et coupl avec un numro administratif. Le bureau des admissions (ou des frais de sjour) cre (en utilisant le logiciel MAGIC, Module danonymisation et de gestion des informations de chanage), partir du fichier des numros de scurit sociale des patients admis, un fichier de numros anonymes. Le fichier obtenu devra tre coupl au fichier des numros administratifs confrs ces patients lors de leur admission. Le rsultat de cette procdure est la production dun fichier dnomm ANO-HOSP ; - un second couplage est effectu par le dpartement dinformation mdicale (DIM) : le mdecin responsable du DIM met en relation le fichier ANO-HOSP, reu du service des admissions, et le fichier labor par ses soins, qui opre la liaison entre le numro de RSS et le numro administratif. Cette protection danonymisation des rsums est renforce, au niveau de lARH (Agence Rgionale dHospitalisation), dune nouvelle procdure de hachage des numros anonymes. Service Administratif

Fichier VID-HOSP
- Variables Identifiantes - N Local de Sjour MAGIC FOIN

DIM

Fichier HOSP-PMSI
- N Local de Sjour - N Sjour PMSI

Fichier PMSI (RUM/RHS) - N sjour PMSI -

Fichier ANO-HOSP
- N Anonyme - N Local de Sjour

Gnrateur de Rsums anonymes

ARH Fichier Anonyme Chanable (2) - N Anonyme (2)

Fichier Anonyme Chanable (1) (RSAc/RHAc)

- N Anonyme (1) - Chiffrement

MAHOS FOIN Dchiffrement

Figure B1 : Schma rcapitulatif des anonymisations du PMSI

158

Annexes

B1. Traitements raliss au niveau des services administratifs B1.1 Constitution du fichier VID-HOSP
Ce fichier est ralis par les services administratifs de ltablissement. Il est constitu des variables suivantes : numro de scurit sociale (celui de louvrant droit), celui-ci est recueilli au niveau du service des admissions, afin de remplir les informations de sjours transmises aux caisses dassurance maladie (ou pour facturation) ; date de naissance et sexe de la personne admise et non celui de lassur ; variable identifiant le sjour hospitalier (numro administratif local de sjour qui nest rien dautre que le numro fourni par le service des admissions de ltablissement pour identifier le sjour du patient).

B1.2 Constitution du fichier ANO-HOSP et transmission au DIM

Le logiciel MAGIC constitue partir du fichier VID-HOSP, le fichier ANO-HOSP contenant : un numro de patient anonymis, celui-ci est constitu par le module FOIN ; un numro local de sjour. Ce fichier (ANO-HOSP) devra tre transmis au DIM de ltablissement. MAGIC effectue les contrles suivants : conformit des diffrentes variables ; absence de doublon sur le numro dhospitalisation dans le fichier VID-HOSP. Une cl dintgrit sera gnre pour sassurer quaucune modification du fichier ANOHOSP naura t ralise entre sa gnration et son utilisation.

B2. Traitements raliss au niveau du DIM B2.1 Constitution du fichier HOSP-PMSI

Le DIM ralise un fichier contenant les correspondances entre le numro de sjour PMSI (numro de RSS, numro sjour SSR) et le numro didentification de sjour administratif. Ce fichier est en gnral, dj utilis par les DIM pour permettre de faire la liaison entre les donnes saisies pour le PMSI et le dossier mdical.

B2.2 Constitution du fichier anonyme chanable

Cette tape produit un fichier anonyme contenant un identifiant permettant le chanage des sjours pour un patient donn sur lensemble de la France. Un couplage en cascade seffectue tout dabord entre les fichiers ANO-HOSP et HOSP-PMSI puis entre les fichiers de donnes PMSI et le fichier HOSP-PMSI. Le premier couplage seffectue sur la variable numro local de sjour le second sur la variable numro sjour PMSI. Lors de ltape de couplage, le logiciel danonymisation ralise les contrles suivants : - contrle des variables du fichier HOSP-PMSI ;

159

vrification de labsence de doublons sur le numro dhospitalisation dans le fichier HOSP-PMSI ; vrification que les numros PMSI prsents dans HOSP-PMSI sont bien dans le fichier PMSI et vice-versa ; vrification que les numros locaux de sjours prsents dans le fichier ANO-HOSP sont bien dans HOSP-RSS.

B2.3 Traitements raliss au niveau de lARH

Lors de la rception des fichiers par lARH (Agence Rgionale dHospitalisation), les tapes suivantes seront ralises : dchiffrement du fichier ; ralisation dune deuxime anonymisation du numro (anonyme), cre dans ltablissement ; - traitements MAHOS traditionnels. La deuxime anonymisation est ncessaire pour que les numros calculs dans ltablissement ne soient pas ceux utiliss dans les bases nationales. -

160

Annexes

Annexe C : Introduction UML

Cette annexe a pour objectif de prsenter de manire synthtique la notation UML. Elle se dcompose en deux parties, la premire propose un rsum dUML, la seconde prsente les diffrents diagrammes UML utiliss dans le chapitre 4.

C1. UML en rsum

UML a t standaris par lOMG (Object Management Group) en novembre 1997. Les objectifs dUML sont : - proposer aux utilisateurs un langage visuel prs lemploi permettant de dvelopper et dchanger des modles orient-objet adapts la modlisation des systmes informatiques ; - fournir des mcanismes dextension et de spcialisation des concepts de base afin de sadapter tout les types dapplications informatiques ; - permettre des spcifications indpendantes dun langage de programmation ou dun processus de dveloppement donn ; - offrir une base smantique formelle pour la comprhension du modle ; - encourager lutilisation et le dveloppement doutils de gnie-logiciel. UML est constitu de neuf modles semi-formels, appels diagrammes. Il est complt par un langage de dfinition de contrainte, lOCL (Object Constraint Language). Ce dernier permet de dfinir des contraintes entre les diffrents lments de la notation (attributs, classes, objets, etc.). Les diffrents modles dUML sont : - les modles fonctionnels (diagramme de cas dutilisation), permettent de capturer les besoins fonctionnels ; - les modles structuraux (diagramme de classes et diagramme dobjets),dcrivent laspect statique des objets,leurs structures, leurs attributs,leurs interfaces ainsi que leurs relations statiques au sein du systme ; - les modles comportementaux (digrammes de squences, de collaboration, dactivits et dtats) mettent laccent sur le rle des objets dans le systme : leurs mthodes (services quils rendent), interactions, collaborations avec les autres objets ainsi que leurs comportement au cours du temps ; - les modles dimplmentation (diagramme de composant et de dploiement) permettent de dcrire une architecture matrielle et de dfinir larchitecture physique. Ils reprsentent les relations entre logiciel et matriel.

161

C2. Les diagrammes UML C2.1 Les cas dutilisation

Les cas dutilisation dcrivent les fonctionnalits du systme (ou dun sous-systme) dun point de vu dun utilisateur, et recentre lexpression des besoins sur ce dernier. Les cas dutilisation sont donc utiles pour reprsenter ce que doit faire un systme par rapport son environnement. Les entits de lenvironnement extrieures au systme sont appeles acteurs. Un diagramme de cas dutilisation reprsente un ou plusieurs cas dutilisation, les acteurs impliqus dans ces fonctionnalits ainsi que les relations entre les acteurs et les cas dutilisation. Un cas dutilisation est reprsent par un identificateur textuel dans une ellipse un acteur par une icne strotype de personnage et les relations par des traits. Les relations peuvent tre des associations entre un acteur et un cas dutilisation, des gnralisations entre les acteurs, et des gnralisations, extensions et inclusions entre cas dutilisation. Les associations faisant intervenir un acteur et un cas dutilisation sont en trait plein et non directionnel. La gnralisation entre acteur est indique par une flche triangulaire ferme, oriente vers lacteur le plus gnral. Une gnralisation entre cas dutilisation est indique par une flche triangulaire ferme, oriente vers le cas dutilisation le plus gnral. Les autres associations entre cas dutilisation (extension et inclusion) sont en pointills, avec une flche et prciss par les strotypes <<extend>> ou <<include>> : - A <<extend>> B signifie que le comportement de A peut tre tendu et que B peut faire appel au comportement de A. - A <<include>> B signifie que le comportement de B est toujours prsent dans A.

C2.2 Les modles structuraux

Les diagrammes de classes et dobjets reprsentent la structure statique dun systme. Dans le cas gnral, une classe est reprsente par un rectangle divis en trois compartiments. La case suprieure contient le nom, la case mdiane contient les attributs et enfin la case infrieur contient les oprations de classe. Par convention la notation O /R :C dsigne un objet appel O , instance de la classe C , ayant pour rle R. les arguments O et /R sont optionnels. Une autre faon de diffrencier objet et classe est de souligner le nom de lobjet dans ce cas, seul le nom de classe dont il est instance est donn. Des relations (ou associations) peuvent tre dcrites entre classes. Les relations entre objet sont des instances dassociation et sont appeles lien. Une relation est reprsente par un trait entre deux classes. Elle est caractrise par un nom et/ou deux rles (un pour chaque classe associe).Une indication de cardinalit peut tre rajoute prs des deux rle de lassociation. Les associations les plus importantes sont celles qui reprsentent une agrgation ou une gnralisation. L agrgation est une association non symtrique spcifiant quune classe est compose dautres classes (classes composites). Elle est reprsente par un losange vide du ct de lagrgat. La composition est une agrgation forte, pour laquelle la destruction de lobjet compos entrane celle des objets composites. Dans ce cas, le losange est noir. Lhritage (ou gnralisation) se reprsente par une flche triangulaire vide pointant vers le pre.

162

Annexes

C2.3 Les modles comportementaux

Un diagramme dinteractions exprime le comportement qui rsulte dune communication dun groupe dinstances. Cet ensemble dinteractions peut tre organis autour dun cas dutilisation, dune ou plusieurs oprations ralises par plusieurs objets. Le but est de dcrire comment les objets collaborent au cours du temps et quelles responsabilits ils assument. Il existe deux type diagrammes dinteraction proposant chacun une prsentation diffrente : - Les diagrammes de squence reprsentent des interactions entre objets, en instant sur la chronologie des envois de messages. Les objets intervenant dans linteraction sont matrialiss par une ligne de vie, et les messages changs au cours du temps sont mentionns sous une forme textuelle. En UML, les interactions et les informations changes sont appels messages. Un message est constitu par lmission par le demandeur de services dun vnement, et par la rception de cet vnement par le fournisseur de services. Lmission dun vnement se fait par une action. - Les diagrammes de collaboration montrent les relations entre les objets et sont prfrables pour comprendre la responsabilit de chaque objet dans le contexte de linteraction dcrite. En revanche, ils ne montrent pas le temps sur une chelle spare. En gnral un diagramme de collaboration est utilis comme canevas pour dcrire un ensemble de diagramme de squence, chaque diagramme de squence tant une histoire possible. Par ailleurs, les diagrammes des tats peuvent tre utiliss pour modliser le comportement des objets, des classes, des sous systmes ou des acteurs39. Comme toutes les approches de type systme de transition, la notion dtat et de transition en sont le fondement. Ltat reprsente lensemble des valeurs des variables du systme un instant donn. Le changement dtat est reprsent par une transition, cest dire une modification dune ou de plusieurs variables du systme. Une transition peut tre provoque, soit par un vnement interne (expiration dun dlai ou fin dune activit, par exemple), soit par un vnement externe (type de stimulus). Elle peut aussi correspondre une action du systme sur lenvironnement (type de rponse). Une transition peut contenir des paramtres. La syntaxe est la suivante : Nom-Evnement (Paramtre_Evnement) [Garde]/Actions. Chacun de ces champs est optionnel. Des donnes, alors paramtres, peuvent tre associes un vnement. La transition est franchie ds que lvnement survient, et que la garde (expression logique boolenne) est vraie. Lors de franchissement, des actions peuvent tre effectues. Chaque action est spare par une virgule,les actions sont alors excutes en squence. Une action peut tre lappel dune opration, lenvoi dun signal, la cration ou la destruction dune instance, lenvoi des valeurs dune variable, ou enfin larrt dune opration. Des actions peuvent tre aussi associes aux tats. Leur dfinition se fait suivant la notation Nom_Action /. Liste_Action. Pour un tat, trois mots clef sont rservs au nom dune action : - Entry / Liste_Action qui dfinit les actions que lobjet doit effectuer ds quil atteint ltat, - Exit / Liste_Action pour dcrire les actions effectuer lorsque lobjet sort de cet tat, - Do / Liste_Action qui dfinit la liste des actions effectues tant que lobjet reste dans ltat auquel est associ cette action. En outre, un tat historique, not H , permet de rintgrer le dernier sous-tat quitt lorsquune transition portant sur un tat composite dj atteint auparavant est sensibilise.
En fait, tout les objets nont pas besoin dun diagramme des tats, seuls les objets actifs en ncessitent un. Un objet actif est un objet dont les oprations sont contraintes par son tat interne.
39

163

Cette possibilit autorise la reprsentation de la notion de reprise aprs une interruption. Ltat historique*, not H*, permet de rintgrer ltat de plus bas niveau dans la hirarchie de dcomposition. Enfin, des diagrammes dactivits, variante des diagrammes dtats-transitions, peuvent complter la modlisation du comportement du systme et de ses entits. Dans un diagramme dtats-transitions, les tats et les transitions sont mis en avant alors que dans un diagramme dactivits, ce sont les activits et les transitions qui sont mises en avant. Les deux types de diagrammes permettent ainsi davoir deux vues diffrentes sur les automates donns. Un diagramme dactivit visualise un graphe dactivits qui modlise le comportement interne dune mthode (la ralisation dune opration), dun cas dutilisation ou plus gnralement dun processus. Dans ce type de diagrammes, un tat-action modlise une tape dans lexcution dun algorithme ou dun workflow. Elle est reprsente par un triangle arrondi, comme un tat, mais plus tir horizontalement avec des ctes convexes droite et gauche. Les tats actions sont relis par des transitions, souvent automatiques, reprsents par des flches. tant donn que le travail dcrit dans ce mmoire nutilise pas les modles dimplmentation dUML, nous nallons pas dtailler les diagrammes de composants ni les diagrammes de dploiement. Une description plus riche dUML peut tre trouve dans [Muller & Gaertner 2000 ; Booch et al. 1999].

164

Annexes

Annexe D : Contrle daccs pour un centre dentaire

Il est vident que lors de tout projet, la rdaction du code de programme est obligatoirement devance dune mthode danalyse fournissant une vue dtaille des problmes traiter. La mthode MERISE, que nous avons adopte lors de la ralisation de notre application, est une mthode de conception et de modlisation des systmes dinformation qui repose sur une architecture en trois cycles dabstraction [Matheron 1998] : - Niveau conceptuel : dfinit les fonctions ralises par lentreprise (en loccurrence le centre dentaire). Il rpond la question : quoi ? et aide ainsi comprendre le fonctionnement et modliser les donnes, les traitements et les communications. - Niveau logique (ou organisationnel) : complte lanalyse en dcrivant les fonctions des acteurs, qui ? quand ? o ?, ainsi que les processus de lorganisation qui fait quel traitement, quand et o ?. - Niveau physique (ou oprationnel) : finalise le travail en indiquant comment les donnes et les programmes sont implments et raliss. Dans le reste de ce chapitre, nous dtaillons chacun de ces niveaux.

D1. Analyse conceptuelle

Lanalyse conceptuelle que nous avons tablie pour notre application consiste fournir le dictionnaire de donnes, les rgles de gestion, ainsi que les trois modles conceptuels : le modle conceptuel de communication, le modle conceptuel de donnes et le modle conceptuel de traitement.

D1.1 Dictionnaire de donnes

Lanalyse conceptuelle commence par le regroupement des donnes recenses dans ce qui est communment nomm un dictionnaire de donnes. Lannexe E prsente le dictionnaire correspondant notre application. Code Ndossier Nmpatient Prpatient Fonctpatient NSS Dnpatient Adpatient Dsignation Numro dossier du patient Nom patient Prnom patient Fonction patient Type Numrique (N) Alphanumrique (AN) A A Nature Longueur lmentaire 6 (E) E E E E E Concatn (Co) 10 10 10 15 10 30

Numro scurit sociale du N patient Date naissance patient Adresse patient N AN

165

(Co) Telbpatient Teldpatient Telppatient Emailpatient Diagpatient Interpatient Ndentiste Nmdentiste Prdentiste Spdentiste Ncindentiste Sexedentiste Dndentiste Ancdentiste Addentiste Telbdentiste Tepdentiste Faxdentiste Emaildentiste Ntechnicien Nmtechnicien Prtechnicien Sexetechnicie n Ncintechnicie n Dntechnicien Dtembtechnic ien anctechnicien Teldtechnicie n Telptechnicie n Emailtechnici en Tel bureau Tel domicile patient Tel portable patient Adresse patient lectronique N N N AN AN AN N A A A E E E E E E E E E E E E E E E Co E E E E E E E E E Co E E E E E 10 10 10 20 30 30 2 10 10 10 8 9 12 12 2 30 10 10 10 20 2 10 10 9 8 12 12 2 10 10 20

Diagnostic du patient Interrogatoires du patient Numro dentiste Nom dentiste Prnom dentiste Spcialit dentiste

Numro carte didentit du AN dentiste Sexe dentiste Date naissance dentiste Anciennet dentiste Adresse dentiste Tlphone bureau dentiste Tlphone portable dentiste Fax dentiste Adresse dentiste lectronique A AN AN N AN N N N AN N A A A

Dtembdentiste Date dembauche dentiste

Numro technicien Nom technicien Prnom technicien Sexe technicien

Numro carte identit. AN technicien Date de technicien naissance AN AN N N N AN

Date dembauche Anciennet technicien Tlphone technicien Tlphone technicien Adresse technicien domicile portable lectronique

166

Annexes

faxtechnicien Nrdv Dtrdv Hrdv Obrdv Ninter Dentsoigne Dtinter Hinter Mtcons Pltrait Nord Dtord Nfact Dtfact Libfact Mopay Mtfact Avfact Recfact Npro Libpro Typro Ppro Typesoin Intypesoin Libradio Pradio Codmed Libmed Formemed Codetymed Libtymed

Fax technicien Numro rendez-vous Date rendez-vous Heure rendez-vous Observation rendez-vous Numro intervention Dent soigne Date Intervention Heure Intervention Motif de consultation Plan de traitement Numro ordonnance Date ordonnance Numro facture Date facture Libelle facture Mode paiement Montant factur Avance de la facture recevoir de la facture Numro prothse Libell prothse Type prothse Prix prothse Type soin effectu Intitul type soin Libell radio Prix radio Code mdicament Libell mdicament Forme mdicament Code type mdicament Libell type mdicament

N N AN N AN N A AN N AN AN N AN N AN A A N N N N A A N A A A N N A A N An

E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E E

9 2 12 4 30 10 3 12 4 30 30 10 12 10 12 20 8 5 5 5 2 10 10 5 15 20 10 3 3 10 10 2 10

D1.2 Rgles de gestion

La deuxime tape de lanalyse conceptuelle consiste identifier les rgles de gestion associes lapplication. Les rgles que nous avons implment sont les suivantes : chaque intervention est procde d un rendez-vous ;

167

chaque intervention produit un sous-ensemble dactes de lensemble suivant :{ordonnance, facture, rendez-vous} ; chaque facture correspond une seule intervention ; une intervention peut correspondre zro ou plusieurs soins dentaires, ou zro ou plusieurs prothses ; un mdicament appartient un type de mdicament ; une ordonnance peut contenir un ou plusieurs mdicaments ; une intervention est faite par un et un seul dentiste ; un cabinet doit contenir au moins un chirurgien dentiste, celui-ci peut tre aid par des assistantes mdicales ; la hirarchie de rles ainsi que les rgles dexclusion mutuelle voques prcdemment ; etc.

D1.3 Modle conceptuel de communication

Le Modle Conceptuel de Communication est un schma qui reprsente les changes de flux de produits, de personnes, de valeurs ou dinformations entre les intervenants internes (au sein du centre) et externes (patients). La figure D1 dtaille les flux soulevs dans notre application.
1
patient

2 3 4

Service rception

11

5 6
Service interventions (cabinets)

10
Service comptabilit

8 9

1 : demande fiche de renseignement 2 : rcolte informations du patient (fiche remplir) 3 : rendre fiche remplie 4 : tablissement rendez-vous 5 : dclaration cas urgents 6 : rponse 7 : prescription ordonnance 8 : demande rendez-vous suivant 9 : transfert facture 10 : impression facture 11 : rglement

Figure D1 : Modle conceptuel de communication de notre application. Le graphe de dpendance fonctionnelle correspondant est donn dans la figure D2, utilisant les codes indiqus dans lannexe E.
Patient Ndossier Facture Ninter Dtrdv-Hrdv Intervention Rdv Nrdv Ordonnance Nord Nfact Prothse Technicie n Npro Ntechnicien Soins dentaire Type mdicament Tysoin Codmen Qt -dure Mdicament Dentiste Ndentiste

Figure D2 : Graphe de dpendance fonctionnelle correspondant notre application.

168

Annexes

D1.4 Modle conceptuel de donnes

Le Modle Conceptuel de Donnes (MCD) permet davoir une description statique de lensemble des donnes manipules par lorganisation ainsi que les relations entre ces donnes (figure D3).
Patient Rendez-vous Dentiste

Ndossier

1,n

Demande Dtrdv, Hrdv, Obrdv

1,n

Nrdv 1,n 0,n

Passe Faite par

Ndentiste

1,1
Facture

1,1 0,1
Provoque 2
Ordonnance

1,1

Provoque 1

0,1

Intervention

Nfacture

Nintervention Dent soigne Date, H, Ob

Nordonnance

0,1
Concerne 2

0,1
Concerne 1

1,n
Contient Qtmed, dure med, Ob

1,n 1,n
Prothse

1,n
Soins dentaire

Mdicament

1,1
Nprothse Faite par

Cod mdicament

TySoin Int soin

1,1
Appartient

1,n
Technicien Ntechnicien

1,n
Type Mdicament

CodTyMed

Figure D3: Modle conceptuel de donnes correspondant notre application.

D1.5 Modle conceptuel de traitement

Le Modle Conceptuel de Traitement (MCT) donne une description dynamique de lorganisation en dcrivant les diffrents processus. Un processus tant une succession dactivits dclenches par des vnements et produisant des rsultats. La figure D4 donne lexemple dun processus qui commence par larrive du patient et qui sachve par une intervention. Dans ce mmoire, et pour viter toute lourdeur, nous nallons pas dtailler les processus spcifiques aux soins dentaires : extraction simple dune dent ; extraction par alvolectomie ; obturation lamalgame 1f, 2f ou 3f ; radio rtro alvolaire, etc.

169

Aprs avoir prsent lanalyse conceptuelle correspondant notre application, nous dtaillons lanalyse logique (ou organisationnelle) ainsi que lanalyse physique (ou oprationnelle).
Arrive du patient

Recherche dans la table des patients Existant inexistant

Patient Existant 2

Patient Inexistant

Enregistrement patient Nom et prnom obligatoire 1 1et 2 tablissement rendez-vous Prise en charge temps disponible

Patient enregistr

Patient trait

Figure D4 : Exemple de modle conceptuel de traitement pour notre application.

D2. Analyse logique

Les modles que nous venons de dcrire sont indpendants des choix organisationnels (fichiers ou bases de donnes) et de programmation (langage). linverse, le Modle Logique de Donnes (MLD) est une reprsentation du modle conceptuel en terme dorganisation de donnes, il traduit les donnes automatises et leurs liens dans un formalisme plus proche du langage choisi pour la programmation. Le MLD qui correspond notre choix dimplmentation est donn dans la figure D5.

170
Patient Rendez-vous Dentistes

Annexes

Ndossier
Rdv Patient

Nrdv
Ndossier

Ndentiste

Nrdv Dtrdv Hrdv Obrdv

Factures

Interventions

Ordonnances

Nfacture Nintervention

Nintervention

Nordonnance

Ndentiste Nrdv Type soin Nprothse

Dent soigne Date, H, Ob

Nintervention

Ord md.

Nordonnance

Cod mdicament Q md., Dure md., Ob

Prothses Soins dentaire

Nprothse

Ntechnicien

Type soin Int soin

Mdicaments

Cod mdicament

Cod type md.

Techniciens Ntechnicien

Type Mdicaments

Cod type md.

Figure D5 : Modle logique de donnes pour notre application.

D3. Analyse physique

La dernire tape de notre analyse consiste prsenter la vue oprationnelle de notre application travers un modle physique de donnes. Celui-ci prsente lensemble des donnes issues du modle logique de donnes sous formes de tables. Quelques-unes des tables de notre implmentation sont prsentes ci-dessous: Table : patient Champ Ndossier Nmpatient Prpatient Foncpatient NSSpatient Dnpatient Agepatient Nom patient Prnom patient Fonction patient Numro de scurit sociale du patient Date naissance patient Age du patient Description Numro dossier Longueur 6 10 10 9 8 12 2 Type Numrique Texte Texte Texte Texte Texte Texte N N N N N N Cl Oui

171

Adpatient Sexepatient Telbpatient Teldpatient Telppatient Faxpatient Emailpatient Diagpatient Interpatient

Adresse du patient Sexe du patient Tlphone bureau du patient Tlphone domicile du patient Tlphone portable du patient Fax du patient Email du patient Diagnostic patient Interrogatoire patient Table : dentiste

30 8 10 10 10 10 20 30 30

Texte Texte Texte Texte Texte Texte Mmo Mmo Mmo

N N N N N N N N N

Champ Ndentiste Nmdentiste Prdentiste Spdentiste Ncindentiste Sexedentiste Dndentiste Agedentiste Dtembdentiste Ancdentiste Addentiste Telddentiste Telpdentiste Faxdentiste Emaildentiste

Description Numro dentiste Nom dentiste Prnom dentiste Spcialit dentiste Numro CIN dentiste Sexe dentiste Date naissance Age dentiste Date dembauche Anciennet dentiste Adresse dentiste Tlphone bureau du dentiste Tlphone dentiste Fax dentiste ml dentiste portable

Longueur 2 10 10 10 8 9 12 2 12 2 30 10 du 10 10 30

Type Numrique Texte Texte Texte Texte Texte Texte Texte Texte Texte mmo Texte Texte Texte Mmo Oui N N N N N N N N N N N N N N

Cl

Table : rendez-vous Champ Nrdv Dtrdv Hrdv Obrdv Description Numro rendez-vous Date rendez-vous Heure rendez-vous Observation rendez-vous 2 12 4 30 Table intervention Champ Ninter Description Numro intervention 6 Longueur Type Numrique Oui Cl Longueur Texte Texte mmo Type Numrique N N N Cl Oui

172

Annexes

Dentsoigne Dtinter Hinter Mtcons Pltrait

Dentsoigne Date intervention Heure intervention Motif de consultation Plan de traitement

3 12 4 30 30 Table : facture

Mmo Texte Texte mmo Mmo

N N N N N

Champ Nfact Ninter Dtfact Libfact Mopay Mtfact Avfact Recfact

Description N facture N intervention Date facture Libell facture Mode paiement Montant factur Avance de la facture recevoir 6 6

Longueur

Type Numrique Numrique Texte Texte Texte Numrique Numrique Numrique N N N N N N N

Cl Oui

12 10 10 5 5 5 Table : ordmed

Champ Nord Codmed Qtmed Dureemed

Description N ordonnance Code mdicament Quantit mdicament Dure mdicament 5 5

Longueur

Type Numrique Texte Texte Numrique

Cl Oui Oui N N

10 2

Rfrences bibliographiques

[Abou El Kalam 2002 ] A . Abou El Kalam, Politiques de scurit pour les systmes dinformations mdicales, Cinquimes Journes Doctorales en Informatiques et Rseaux (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, Modles et politiques de scurit des systmes dinformations 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, Modles et politiques de scurit des systmes dinformations et de communications en sant et en social : concepts et terminologie gnriques, 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, Modles et politiques de scurit des systmes dinformations et de communications en sant et en social : informations protger et menaces, Rapport LAAS n 02334, septembre 2002, 34 pp. [Abou El Kalam & Deswarte 2002] A. Abou El Kalam, Y. Deswarte, Contrle daccs bas sur les rles, les groupes dobjets et le contexte : tude de cas dans les systmes dinformation et de communication en sant, Actes de la confrence Scurit et Architecture des Rseaux (SAR02), 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), Athnes, 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. Mige, C. Saurel, G. Trouessin Organization-Based Access Control, 4th International Workshop on Policies for Distributed Systems and Networks (Policy03), Cme, 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. Mige, C. Saurel, G. Trouessin Un modle de contrle daccs bas sur les organisations, Cahiers francophones de la recherche en scurit de linformation, 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 : Spcification dun prototype danonymisation ", 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, Modles et politiques de scurit des SICSS, 1re Confrence Francophone en Gestion et Ingnierie des Systmes Hospitaliers (GISEH), Lyon, janvier 2003, pp.268-277.

174

Rfrences bibliographiques

[Abou El Kalam et al. 2003e] A. Abou El Kalam, P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, R. Elbaida, C. Saurel, G. Trouessin, Modles et politiques de scurit des systmes d'information et de communication en sant et social, paratre dans la revue Sant et Systmique, dition Herms, 2004, 21 pp. [Abou El Kalam & Deswarte 2004a] A. Abou El Kalam, Y. Deswarte, Modles de scurit pour le secteur de la sant, Technique et Science Informatique (TSI ), Vol. 23, n 3 (thmatique scurit informatique), mars 2004, Hermes, 30 pp. (Rapport LAAS 02433). [Abou El Kalam et al. 2004a] A. Abou El Kalam, Y. Deswarte, G. Trouessin, E. Cordonnier, Une dmarche mthodologique pour lanonymisation de donnes personnelles sensibles, 2me Confrence Francophone en Gestion et Ingnierie des Systmes Hospitaliers, Mons, 911 septembre 2004. [Abou El Kalam et al. 2004b] A. Abou El Kalam, Y. Deswarte, G. Trouessin, E. Cordonnier, Gestion des donnes mdicales anonymises, Symposium SSTIC sur la Scurit des Technologies de lInformation et des Communications, Rennes, 2-4 juin 2004. [AFNOR 1997] AFNOR, document de normalisation franaise, Fascicule de Documentation FD S 97-560. [Ahn & Sandhu 2000] G. Ahn and R. Sandhu, Role-Based Authorization Constraints Specification, ACM Transactions on Information and System Security (TISSEC), vol. 3, n 4, novembre 2000, pp. 207-226. [Ammann & Sandhu 1992] P.E. Ammann et R.S. Sandhu, Implementing Transaction Control Expressions by checking for Absence of Access Rights, Proceedings of the 8th Annual Computer Security Applications Conference, San Antonio (Texas, USA), 30 novembre 4 dcembre 1992, IEEE Computer Society Press, pp. 131-140. [Anderson 1980] J.P. Anderson, Computer Security Threat Monitoring and Surveillance, Technical report, James P. Anderson Company, Fort Washington, Pennsylvania, 1980. [Anderson 1996a] R.J. Anderson, Clinical System Security : Interim Guidelines, in British Medical Journal, vol. 312, n 7023, janvier 1996, pp. 109-111. [Anderson 1996b] R.J. Anderson, A Security Policy Model for Clinical Information Systems, IEEE Symposium on Security and Privacy, Oakland, Californie, 6-8 mai 1996, IEEE Computer Society Press, pp. 30-43. [Arrt 1998] Arrt du 29 juillet 1998 relatif au recueil et traitement des donnes dactivit mdicale par les tablissements de sant publics et privs financs par dotation globale vises larticle L. 710-16-1 du mme code et la transmission aux agences rgionales de lhospitalisation et ltat dinformations issues de ce traitement (JO, 26 aot 1998). [Audit 1998] Audit Commission, Ghost in the Machine - An Analysis of IT Fraud and Abuse, Audit Commission Publications, United Kingdom, ISBN 1-86240-05603, 1998. [Barkley et al. 1999] J. Barkley, K. Beznosoz et J. Uppal, Supporting Relationships in Access Control Using Role Based Access Control, Proceedings of the ACM workshop on RBAC, Fairfax, Virginia, USA, 28-29 octobre 1999, pp. 55-65. [BCN 1999] Droits daccs au dossier mdical informatis, Bulletin du Conseil National du 12 dcembre 1998, BCN n 84, juin 1999, ministre de la sant publique, 14 pp. [Bell-LaPadula 1996] D.E. Bell, L.J. LaPadula, Secure Computer Systems : Unified Exposition and Multics Interpretation, Rapport technique, MTR 2997 Rev. 1, MITRE corp., Bedford (Massachussetts, USA), 1976.

175

[Benferhat et al. 1998] S. Benferhat, D. Dubois, H. Prade, Practical Handling of ExceptionTeinted Rules and Independence Information in Possibilistic Logic. Applied Intelligence, vol. 9, 1998, pp.101-127. [Benferhat et al. 2003] S. Benferhat, R. El Baida, F. Cuppens, A Stratification-Based Approach for Handling Conflicts in Access Control, 8th ACM Symposium on Access Control Models and Technologies, Cme, Italy, 2-3 juin 2003, 189-2003, ACM press. [Bettini et al. 2002] C. Bettini, S. Jajodia, X. S. Wang et D. Wijesekera, Obligation Monitoring in Policy Management, International Workshop, Policies for Distributed Systems and Neworks (Policy 2002), Monterey, Californie, 5-7 juin 2002, IEEE Computer Society Press, pp. 2-12. [Biba 1977] K.J.Biba, Integrity Consideration for Secure Computer Systems, The MITRE Corporation, Technical Report ESD-TR-76-372 & MTR-3153, 1977. [Bieber & Cppens 1991] P. Bieber et F. Cuppens, A Definition of Secure Dependencies with the Logic of Security, 4th IEEE Computer Security Foundations Workshop (CSFW 91), Franconia, New Hampshire, USA, 18-20 June 1991, Proceedings. IEEE Computer Society Press, pp. 2-11. [Bieber & Cppens 1992] P. Bieber et F. Cuppens, A Logical View of Secure Dependencies, Journal of Computer Security, vol. 1, n. 1, 1992, pp. 99-129. [Blobel 1996] B Blobel, Clinical Record Systems in Oncology. Experiences and Developments on Cancer Registers in Eastern Germany, in Personal Medical Information Security, Engineering and Ethics, R.J. Anderson (Editor), Springer-Verlag, ISBN 3-54063244-1, pp. 3956, 1997. [Blobel & Pharow 2001] B.Blobel et P.Pharow, The Need and Practice of User Authentication and TTP Services in Distributed Health Information Systems, 16th International Conference on Information Security (IFIP/SEC01), Paris, France, 11-13 juin 2001, Kluwer Academic Publishers, pp. 61-76. [BMA 1996] Security in Clinical Information Systems, British Medical Association, London, ISBN 0-7279-1048-5, 1996. [Booch et al. 1999] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language. User Guide, 1999, Addison Wesley, ISBN : 0-201-57168-4, 482 pp. [Branstad et al. 1990] M.A. Branstad, C.P. Pfleeger, D. Brewer, C. Jahl, H. Kurth, Apparent Differences Between the US TCSEC and the European ITSEC, 14th National Computer Security Conference, octobre 1990, pp. 45-58. [Brewer & Nash1989] D. Brewer, M. Nash, The Chinese Wall Security Policy, IEEE Symposium on Security and Privacy, Oakland, Californie, 1-3 mai 1989, IEEE Computer Society Press, pp. 206-214. [Catach 1989] L. Catach, Les logiques multimodales, Thse de doctorat, Universit de Pierre et Marie Curie (Paris 6), Paris, France, 1989, 312 pp. [CC 1999a] Common Criteria for Information Technology Security Evaluation, Part 1 : Introduction and general model, 60 p., ISO/IEC 15408-1 (1999). [CC 1999b] Common Criteria for Information Technology Security Evaluation, Part 4 : Predifined Protection Profiles, 166 pp., ISO/IEC 15408-1 (1999).

176

Rfrences bibliographiques

[CEN 1999] CEN/TC 251/WG I, Norme prENV 13606-3: Health Informatics - Electronic Healthcare Record Communication, n 99-046, Comit Europen 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 gnralisation du Programme de mdicalisation (BOMS n 89/46), Ministre de lemploi et de la solidarit, France. [Circulaire 1998] Circulaire n 153 du 9 mars 1998 relative la gnralisation dans les tablissements de sant sous dotation globale et ayant une activit de soins de suite ou de radaptation dun recueil de RHS, ministre de lemploi 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. Delige et C. Christoph, Dossier mdical, rseaux et systme intgr de soins, Septimes Journes Francophones dInformatique Mdicale, Socit Belge dInformatique Mdicale : Sant et rseaux informatiques, Lige, 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 dontologie mdicale, dcret 95-1000 du 6 septembre 1995. [Code 1995b] Code de la sant publique, Code de la famille et de laide 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, 1012 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 & Mige 2003a] F. Cuppens, A. Mige, Administration Model for Or-BAC, Workshop on Metadata for Security, International Federated Conferences (OTM 03), Sicile, Italie, 3-7 novembre 2003. [Cuppens & Mige 2003b] F. Cuppens et A. Mige, Modelling Contexts in the Or-BAC Model, 19th Annual Computer Security Applications Conference (ACSAC03), Las Vegas, Nevada, 8-12 dcembre, 2003, IEEE Computer Society. [Cuppens 2003] F. Cuppens, Scurit des bases de donnes, in Scurit des rseaux et des systmes rpartis, (Yves Deswarte & Ludovic M, eds), Trait IC2, Herms, ISBN : 027462-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, fvrier 2001. [dAusbourg 1994] B. dAusbourg, 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 scurit informatique, Thse de doctorat, Institut National Polytechnique de Toulouse, N 971, 154 pp., 20 dcembre 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 (ESORICS94), (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 IntrusionDetaction Alerts, 4th International Workshop on Recent Advances in Intrusion Detection (RAID), Californie (USA) , 10-12 octobre 2001, Springer, pp. 197-216. [Dcret 1994] Dcret n 94-666 du 27 juillet 1994 relatif aux systmes dinformation mdicale et lanalyse de lactivit des tablissements de sant publics et privs sous comptence tarifaire de ltat, modifi par le dcret n 98-63 du 2 fvrier 1998. [Dcret 2002] Dcret 2002-637 du 29 avril 2002 relatif laccs aux informations personnelles dtenus 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. Stphan, A. Venot et P.-J. Yvon, Informatique et Gestion des Units de Soins - Informatique et Sant vol. 1, Springer-Verlag France, pp. 257-268, juin 1989.

178

Rfrences bibliographiques

[Degoulet 1992] Degoulet P., Fieschi M., Traitement de linformation mdicale - Mthodes et applications hospitalires, Collection : Manuels Informatiques Masson - Entreprise, Paris, 1992, 269 pp., ISBN: 2225825149. [Delige 2001] D. Delige, 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 Europen, adopte par le Conseil Europen 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 Europen n 2002/58/EC concernant le traitement des donnes caractre personnel et la protection de la vie prive dans le secteur de tlcommunications 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 IntrusionTolerant 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 scurit des systmes dinformation et de communication, in Scurit des rseaux et des systmes rpartis, (Yves Deswarte & Ludovic M, eds), Trait IC2, Herms, ISBN : 02-7462-0770-2, 264 pp, octobre 2003. [Fabre et al. 1996] J.C. Fabre, Y. Deswarte, L. Blain, Tolrance aux fautes et scurit par fragmentation-redondance-dissmination, 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, aot 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

[FMAG 1996] Bundesarztekammer. Empfehlungen zu arztlicher Schweigepflicht, Datenschutz und Datenverarbeitung in der Arztpraxis. Koln: Bundesarztekammer, 1996 (en allemand). [Fray 1986] J.M. Fray, Y. Deswarte, D. Powell, Intrusion-Tolerance Using Fine-Grain Fragmentation-Scattering, Proc. Int. Symp. on Security and Privacy, pp. 194-201, Oakland, Californie, USA, IEEE Computer Society Press, mai 1986. [Garvila & Barkley 1998] S.I. Gavrila, J.F. Barkley, Formal Specification for Role Based Access Control, Third ACM Workshop on RBAC, Fairfax, Virginia, USA, 22-23 octobre 1998. [Georgiadis et al. 2001] C.K. Georgiadis, L. Mavridis, G. Pangalos, R.K. Thomas, Flexible Team-Based Access Control Using Contexts, ACM Symposium on Access Control Models and Technologies, (SACMAT01), Chantilly, Virginia, USA, 3-4 mai 2001, pp. 21-27. [Godfrey et al. 1998] P. Godfrey, J. Grant, J. Gryz, J.Minker, Integrity Constraints: Semantics and Applications, in Logics for Databases and Information Systems, J. Chomiki et J. Minker (Eds.), Kluwer Academic Publishers, 1998, ISBN 0-7923-8129-7. [HRU 1976] M.A. Harrison, W.L. Ruzzo et J.D. Ullman, Protection in Operating Systems, Communication of the ACM, 19(8), pp. 461-471, aot 1976. [Hu 1991] W-M. Hu, Reducing Timing Channels with Fuzzy Time, in Proceedigns of the 1991 IEEE Symposium on Research in Security and Privacy, Oakland (CA), 20-22 mai 1991, pp.8-20. [ISO 15408] Common Criteria for Information Technology Security Evaluation, norme ISO/CEI 15408, version 2.1, aot 1999. [ITSEC 1991] ITSEC , Information Technology Security Evaluation Criteria, v 1.2, 136 pp., ISBN 92-826-3005-6, Office des publications officielles des Communauts Europennes, Luxembourg, 1991. [Jacob 1988] J. Jacob, Security Specification, IEEE Symposium on Security and Privacy, 1821 Avril 1988, Oakland, Californie, IEEE Computer Society, pp. 14-23. [JCSEC 1992] JCSEC, The Japanese Computer Security Evaluation Criteria Functionality Requirements, Ministry of International Trade and Industry, Draft V1.0, aot 1992. [Jeanneret et al. 2001] J.P. Jeanneret, D. Olivier, J. Chiffelle, How to Protect Patients Rigottes to Mdical Secret in Official statistic, Information Security Solutions Europe Conference (ISSE), London, UK, 26-28 Septembre 2001. [Jones et al. 1976] A.K. Jones, R.J. Lipton, L. Snyder, A Linear Time Algorithm for Deciding Security, 17th Annual Symposium on Fundations of Computer Science, Houston, USA, 1976. [Joseph 1988] M.K. Joseph, A. Avizienis, A Fault Tolerance Approach to Computer Viruses, Proc. Int. Symp. on Security and Privacy, Oakland, Californie, USA, IEEE Computer Society Press, mai 1988, pp. 52-58. [Katsikas 1996] S. Katsikas, D. Gritzalis, High Level Security Policy Guidelines. in: Data Security for Health Care, SEISMED Consortium (Eds.), IOS Press, 1996. [Kleene 1967] S. Kleene, Mathematical Logic, John Wiley & Sons, 1967, traduit en franais par A. Largeault sous le titre Logique mathmatique, A. Colin, Paris, ISBN : 0198500483, 1972.

180

Rfrences bibliographiques

[Kripke 1959] S. Kripke, A Comleteness Theorem in Modal Logic, Journal of Philosophical Logic, vol. 24, 1959, pp. 1-14. [Kripke 1963] S. Kripke, Semantical Consideration in Modal Logic, Acta Philosophical Logic, vol. 16, 1963, pp. 83-94. [Laprie 1995] J.-C. Laprie, J.Arlat, J.-P. Blanquart, A. Costes, Y. Crouzet, Y. Deswarte, J.-C. Fabre, H. Guillermain, M. Kaniche, K. Kanoun, C. Mazet, D. Powell, C. Rabjac et P. Thvenod, Guide de la sret de fonctionnement, 324 pp., Editions Cpadus, Toulouse 1995. [Lampson 1971] B. Lampson, Protection, 5th Princeton Symposium on Information Sciences and Systems, 1971. [Landwehr 1983] C.E. Landwehr, The Best Available Technologies for Computer Security, IEEE Computer, vol. 16, n 7, pp. 86-100, juillet 1983. [Lawrence 1993] L.G.Lawrence, The Role of Roles, Computer & Security, vol.12, n 1, pp. 16-21, 1993. [Loi 1978] Loi 78-17 du 6 janvier 1978 relative lInformatique, aux fichiers et aux liberts, Journal officiel de la Rpublique franaise, pp. 227-231, dcret dapplication 78-774 du 17 juillet 1978, pp. 2906-2907. [Loi 1991] Loi 91-748 du 31 juillet 1991 portant rforme hospitalire. [Loi 1994] Loi 94-43 du 18 janvier 1994 relative la sant publique et la protection sociale, article 8. [Loi 2002] Loi 2002-303 du 4 mars 2002 relative aux droits des malades et la qualit du systme de sant, article L. 1111-7. [Matheron 1998] Jean-Paul Matheron. Comprendre MERISE ; outils conceptuels et organisationnels, 1998, Editions Eyrolles, 5me dition, ISBN n 2-212-07502-2. [McLean 1985] J. McLean, A comment of the basic security theorem of Bell and LaPadulla. Information Processing Letters, vol. 2, n 2, pp. 67-70, Fvrier 1985. [McLean 1990] J. McLean, Security Models and Information Flow. IEEE Symposium on Research in Security and Privacy, Oakland, California, pp. 180-187, IEEE Computer Society Press, 1990. [Menezes et al. 1996] A.J. Menezes, P.C. Van Oorshot, S.A. Vanstone, Handbook of Applied Crytography, CRC Press, ISBN 0-8493-8523-7, 1996. [Michel & M 2001] C. Michel et L. M, ADeLe: an Attack Description Language for Knowledgebased Intrusion Detection, in Proceedings of the 16th International Conference on Information Security (IFIP/SEC01), Paris, France, 11-13 juin 2001, Kluwer Academic Publishers, juin 2001, pp. 353-365. [Nicomette 1996] V. Nicomette, La protection dans les systmes objets rpartis, Thse de doctorat, Institut National Polytechnique de Toulouse, n 1252, 177 pp., 17 dcembre 1996 (Rapport LAAS 96496). [Muller & Gaetner 2000] P.A. Muller, N. Gaertner, Modlisation objet avec UML, 2000, Eyrolles, ISBN : 2-212-09122-2, 520 pp. [Nicomette & Deswarte1997] V. Nicomette, Y. Deswarte, An Authorization Scheme for Distributed Object Systems, in Proc. Int. Symposium on Security and Privacy, Oakland (CA, USA), mai 1997, IEEE Computer Society Press, pp. 21-30.

181

[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 rforme de lhospitalisation publique et prive des systmes dinformation et lorganisation mdicale dans les hpitaux 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 scurit des systmes dinformation, Thse de doctorat, Institut National Polytechnique de Toulouse, n 1418, 166 pp., 18 mai 1998 (Rapport LAAS 98164). [Ortalo 1999] R. Ortalo, Y. Deswarte, M. Kaniche, Experimenting with Quantitative Evaluation Tools for Monitoring Operational Security, IEEE Transactions on Software Engineering, Vol.25, N5, 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 n03011, 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 lEurope, R(97)5, On The Protection of Medical Data Banks, Council of Europe, Strasbourg, 13 fvrier 1997. [Rsolution 1990] Rsolution A/RES/45/95 Assemble gnrale des Nations Unies, Principes directeurs pour la rglementation des fichiers personnels informatiss, 14 Dcembre 1990. [Sminaire 2001] Sminaire de la socit Franaise de statistique, Appariements scuriss et statistique publique, organis par le groupe Statistique conomique et sociale par Benot Riandey (INED-SfdS), 28 fvrier 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, fvrier, 1996.

182

Rfrences bibliographiques

[Sandhu 1996] R.S. Sandhu, Role Hierarchies and Constraints for Lattice-Bases Access Controls, in 4th European Symposium on Research in Computer Security (ESORICS96), (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, SpringerVerlag, 1996. [Sandhu & Bhamidipati 1997] R.S. Sandhu, V. Bhamidipati, The URA97 Model for RoleBased User-Role Assignment, in Proceeding of IFIP WG 11.3 Workshop on Database Securiy, Californie, 11-13 aot 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, fvrier 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 (ACSAC99), Phoenix, Arizona, 6-10 dcembre 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 dintgrit multiniveau pour la protection en ligne de tches critiques, Thse 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 NGT/2000.03, CESSI/CNAM, juin 2000. [Trouessin 2001] G. Trouessin, Scurit et intimit des donnes caractre personnel, La Lettre dADELI n 42, juillet 2001.

183

[Trouessin 2002] G. Trouessin, Lvolution des normes de scurit vers plus dauditabilit des systmes dinformation, Colloque AIM lHEGP : Prsent et avenir des systmes dinformation et de communication hospitaliers , 23-24 mai 2002 ( paratre 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 ( Hypertext99), Darmstadt, Germany, pp. 37-46, February 2125, 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, (SACMAT02), 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.