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 LESDOMAINES DE LA SANTE ET DES AFFAIRESSOCIALES

Soutenue le 04 dcembre 2003 devant le jury :

Prsident Yves DUTUIT

Rapporteurs Abdelmalek BENZEKRI

Marc DACIER

Examinateurs 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 etdArchitecture des Systmes du Centre National de la Recherche Scientifique (LAAS - CNRS).Je tiens remercier tout dabord Jean-Claude Laprie, ainsi que Malik Ghalab directeurssuccessifs du LAAS-CNRS pendant mon sjour, de mavoir permis de mener mes recherchesdans ce laboratoire.

Ma reconnaissance se tourne particulirement vers David Powell, ancien responsable dugroupe 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 toutau long de ma thse. Ma considration est inestimable. Ses remarques et critiques pertinentesmont conduit vers la bonne voie. Son soutien ma permis de ne jamais faiblir et de poursuivretoujours plus loin mes travaux. Je tiens galement souligner que la confiance quil a mise enmoi a t un moteur ma russite.

Jexprime ma gratitude Yves Dutuit, Professeur lUniversit de Bordeaux I, pourlhonneur 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 particulirementAbdelmalek Benzekri et Marc Dacier qui ont accept la charge dtre rapporteur.

Je voudrais galement remercier lensemble des partenaires du projet MP6 avec qui jaibeaucoup appris, notamment Gilles Trouessin (responsable du projet MP6) Philippe Balbiani,Frdric Cuppens, Claire Saurel, Salem Benferhat, Alexandre Mige, Rania El-Baida et DidierVinsonneau. 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, quipermettent 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 apartag avec moi des moments faciles et difficiles durant ces trois annes.

Ces avant-propos seraient incomplets sans un remerciement adress aux membres de mafamille, 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 gensaimables 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. SCURIT DES SYSTMES DINFORMATION ET DE COMMUNICATION EN SANTET SOCIAL ...........................................................................................................3

1.1. CARACTRISTIQUES DES SYSTMES DINFORMATION ET DE COMMUNICATION ENSANT 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 Mcanismes cryptographiques......................................................................................18 1.5.2.2 Cloisonnement et pare-feux ..........................................................................................22 1.5.2.3 Audit...............................................................................................................................23 1.5.2.4 Dtection dintrusions ...................................................................................................23 1.5.2.5 Tolrance aux intrusions ...............................................................................................25 1.5.2.6 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 Modle de Lampson ......................................................................................................34 2.2.2.2 Modle HRU..................................................................................................................34 2.2.2.3 Modle Take-Grant........................................................................................................35 2.2.2.4 Modle TAM .................................................................................................................37 2.2.2.5 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 Politique du DoD et modle de Bell-LaPadula............................................................ 39 2.3.1.2 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 Politique de scurit de SEISMED .............................................................................. 54 2.8.2.2 Politique de scurit de la BMA................................................................................... 55 2.8.2.3 Politique de scurit de la SMA ................................................................................... 56 2.8.2.4 Recommandations de la FMAG ................................................................................... 56 2.8.2.5 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 Scnario ......................................................................................................................... 62 3.2.1.2 Informations protger................................................................................................. 64 3.2.1.3 Risques identifis .......................................................................................................... 65 3.2.1.4 Besoins de scurit........................................................................................................ 65 3.2.1.5 Rglement de scurit ................................................................................................... 67

3.2.2. tude de cas 2!: Sphre sociale ............................................................................69 3.2.2.1 Scnario daccs en amont............................................................................................ 69 Scnario daccs en aval.................................................................................................................. 72 3.2.2.3 Ressources protger, menaces, exigences et rgles de scurit ............................... 74

3.2.3. tude de cas 3!: Analyse de diffrents scnarios danonymisationdinformations mdicales ......................................................................................78

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

3.2.3.6 Scnario 2!: unions professionnelles.............................................................................88 3.2.3.7 Scnario 3!: Programme de Mdicalisation des Systmes dInformation PMSI ...89 3.2.3.8 Scnario 4!: traitement des maladies dclaration obligatoire....................................90 3.2.3.9 Scnario 5 : traitements des donnes statistiques.........................................................91 3.2.3.10 Scnario 6!: tudes pidmiologiques focalises .........................................................93 3.2.3.11 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 Contexte et contraintes du rle....................................................................................106 4.2.5.2 Contexte dobjet...........................................................................................................107 4.2.5.3 Attributs dutilisateurs .................................................................................................107 4.2.5.4 Contexte de lutilisation ..............................................................................................107

4.3. REPRSENTATION DOR-BAC EN UML.......................................................................109 CHAPITRE 5. CHOIX DUN FORMALISME POUR OR-BAC....................................................113 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 Constantes ....................................................................................................................118 5.3.1.2 Variables ......................................................................................................................118 5.3.1.3 Formules atomiques.....................................................................................................119 5.3.1.4 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 Les sujets et les rles ...................................................................................................121 5.4.1.2 Les objets et les vues ...................................................................................................122 5.4.1.3 Les actions et les activits ...........................................................................................123 5.4.1.4 La hirarchie ................................................................................................................124

5.4.1.5 Le contexte .................................................................................................................. 125 5.4.1.6 Les contraintes............................................................................................................. 127

5.4.2. Spcification des objectifs de scurit ................................................................127 5.4.3. Spcification des rgles de scurit ....................................................................128

CHAPITRE 6. 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 largementdistribus comme la tlmdecine et les tldclarations sociales, il est de plus en plusncessaire davoir confiance dans les traitements et la distribution des donnes et servicesinformatiques.

Les Systmes dInformation et de Communication en Sant et social (SICSS) permettent destocker et de grer des informations mdicales, administratives ou sociales relatives despersonnes ou des entreprises. Ils exploitent les technologies de linformatique pour permettreaux utilisateurs un accs rapide ces informations, et ainsi faciliter les actes mdicaux, lesremboursements, les tldclarations sociales, les tlpaiements, etc. Toutefois, les menacesqui psent sur de tels systmes peuvent provoquer la rticence des usagers (patients pour lasphre mdicale, entreprises pour la sphre sociale). En effet, lexploitation abusive par unutilisateur malhonnte dun SICSS insuffisamment protg peut rendre possible la divulgationde donnes personnelles diffrents intresss : employeurs, concurrents, banques, etc. Leserreurs de saisie ou de conception peuvent entraner des erreurs de diagnostic, de soins ou depaiements. Les dfaillances peuvent empcher le personnel soignant daccder desinformations indispensables. Enfin, la peur dun manque de confidentialit, dintgrit, dedisponibilit 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 descurit correspondant aux besoins. En effet, toute dmarche de scurit rigoureuse doit treinscrite 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 fonctiondune analyse des risques. Ceci permet de minimiser le risque de dommages indsirables ou depallier leurs effets et conduit protger les informations et les ressources identifies commesensibles.

Une politique de scurit se dveloppe selon trois axes : physique, administratif et logique.Le premier prcise lenvironnement physique du systme protger (les lments critiques, lesmesures prises vis--vis du vol et des catastrophes). Le deuxime dcrit les procduresorganisationnelles (rpartition des tches, sparation des pouvoirs). Le troisime a trait auxcontrles daccs logiques (qui, quoi, quand, pourquoi, comment) et sintresse aux fonctionsdidentification, dauthentification et dautorisation mises en uvre par le systmeinformatique. Dans ce mmoire, nous nous intressons particulirement aux politiquesdautorisation (dites aussi politiques de contrle daccs).

Les premiers travaux sur lexpression et la mise en uvre de politiques dautorisation ontdbut, il y a plus de vingt ans, principalement dans le domaine de la dfense. Pour des raisonsjuridiques (responsabilit), thiques (respect de la vie prive), dontologiques (secret mdical,par exemple), organisationnelles (situations durgence, cas particuliers ou non attendus) ettechniques (interconnexion de rseaux locaux, rgionaux et nationaux), ce type de politiques descurit est clairement inadapt au monde de la sant ou du social. La conception de politiques

Introduction gnrale 2

dautorisation beaucoup plus dynamiques - et pouvant sadapter aux contextes des activitsmdicales ou sociales - est ncessaire. Les modles et politiques de scurit, fonds sur leconcept de rle, sont une premire tape pour mieux rpondre de tels besoins sectoriels, maisils 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, maisncessitent des approfondissements thoriques et des tudes complmentaires.

Ainsi, les politiques et modles de scurit actuels tant incapables de couvrir toute larichesse des SICSS, il semble ncessaire de proposer de nouveaux concepts et de prsenter unmodle pouvant assurer une meilleure scurit, sans pour autant gner le travail des usagers ouporter 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 stratgieset outils pour renforcer la scurit dun systme ou dune organisation.

Le deuxime chapitre tudie les politiques et modles de scurit existants, et montre leslimites de leur application aux SICSS. Elle prsente galement des projets rcents dans cedomaine et introduit le projet MP6, Modles et Politiques de Scurit pour les SystmesdInformation et de Communication en Sant et Social, projet dans lequel ont t effectus nostravaux.

Le troisime chapitre montre comment btir une politique de scurit pour un systme ou uneorganisation. Cette mthodologie est applique en posant les principales briques dunepolitique de scurit pour les sphres sociale et mdicale. ce niveau de ltude, les SICSSseront dcrits en dtail travers des rgles de fonctionnement, des objectifs de scurit ainsique des rgles de scurit. De par son importance dans les SICSS, le problmedanonymisation est enfin abord en dtail. Une tude pralable est ncessaire avant touteprocdure danonymisation. Cette tude doit identifier les besoins, les objectifs ainsi que lesexigences en terme danonymisation. Sen suivra une prsentation des principaux travaux dansce domaine, une description dun ensemble de scnarios rcapitulatifs, et des propositions desolutions mieux adaptes aux besoins actuels et futurs. Les politiques de scurit dcritespourraient ainsi tre appliques aussi bien aux donnes anonymises quaux autresinformations sensibles, ressources et services des SICSS.

Le quatrime chapitre rappelle les concepts de base de notre politique de scurit. Celle-citient compte du contexte et ralise un bon compromis entre la flexibilit et lefficacit ducontrle daccs. Par ailleurs, une reprsentation UML (Unified Modeling Language) dunouveau mta-modle Or-BAC Organization-Based Access Control sera ensuite propose.Centr sur lorganisation, Or-BAC offre lexpressivit et la flexibilit ncessaires lareprsentation 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 surune politique de scurit fonde sur Or-BAC. cet gard, un langage appropri (fond sur lalogique dontique) sera dabord propos, et sera ensuite utilis pour reprsenter les rgles defonctionnement, les objectifs de scurit ainsi que les rgles de scurit des SICSS. Des idessur lexploitation de ce formalisme - notamment pour la vrification de la cohrence dunepolitique de scurit ou pour la rsolution de conflits - seront galement proposes.

Le sixime chapitre commence par prsenter une dmarche UML pour btir une politique descurit associe Or-BAC. Cette dmarche tient compte des aspects conceptuels, statiques etdynamiques dune politique de scurit. Enfin, il sagira de dcrire une concrtisation de nosides travers une implmentation dun logiciel de contrle daccs pour un centre dentaire.

Chapitre 1. Scurit des systmes dinformation et decommunication en sant et social

Prambule

Ce chapitre repose sur deux motivations. Dune part, fournir la base terminologiquencessaire la comprhension de nos travaux, et dautre part, situer nos centres dintrts dansle 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 decommunication en sant et social (SICSS) - que ltude dbutera. Les SICSS couvrentlensemble des besoins gnralement trouvs dans les autres domaines.

Les concepts de la sret de fonctionnement, et plus particulirement ceux de la scuritinformatique, seront ensuite prsents. Le but est de fournir un support terminologique dans ladfinition des politiques de scurit pour les SICSS, puis dans llaboration de modlesformels 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, elledcrit la scurit comme lassociation de la confidentialit, de lintgrit et de la disponibilitvis--vis des actions autorises.

Les ambiguts sont ensuite leves sur les notions dintrusions, dattaques, de vulnrabilitset de risques, et des exemples spcifiques aux SICSS seront donns.

La dernire partie du chapitre dtaille les techniques de scurit les plus utilises pour faireface aux intrusions, et pour renforcer la scurit dun systme ou dune organisation. Il sagirade dcrire des mesures comme les politiques de scurit, les mcanismes de chiffrement, ladtection dintrusion, etc. Ces mcanismes, aussi robustes soient-ils, ne peuvent scuriserefficacement et rigoureusement un systme que sils sintgrent dans une dmarche globalefonde sur une politique de scurit.

Chapitre 1 Scurit des SICSS 4

1.1. Caractristiques des systmes dinformation et decommunication en sant et social

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

1.1.1. Dfinition et enjeux

Les systmes dinformation et de communication en sant et social (SICSS) permettent destocker et de grer des informations mdicales, administratives ou sociales concernant desindividus ou des entreprises. Ils doivent faciliter les tches de leurs utilisateurs : mdecins,secrtaires mdicales, infirmiers, agents dassurances maladie, ou encore usagers de Net-entreprises1, tous en charge de traitements tels les diagnostics, les actes mdicaux, les soins, lesremboursements et les dclarations sociales.

Ces systmes manipulent, entre autres, des donnes caractre personnel et souventnominatives2. 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) ousociales (prestations financires et sociales).

Les SICSS exploitent les progrs des technologies de linformatique et des rseaux pourpermettre aux utilisateurs un accs rapide aux informations, et ainsi faciliter et contrler laprise en charge (mdicale, administrative ou sociale) des patients et des ayant-droits. Ils serventaussi allger la charge administrative qui pse sur les petites et moyennes entreprises etnotamment la procdure de cration des entreprises, le bulletin de paie, le calcul des chargessociales, les mesures fiscales, comptables et statistiques, etc.

Toutefois, la mise en uvre de ces technologies met en danger les donnes gres par lesSICSS. En loccurrence, le march des informations nominatives intresse nombredorganisations : industries pharmaceutiques, compagnies dassurances, banques, employeurs,presse, stratges politiques, etc. Les SICSS sont donc des cibles privilgies pour des individusmalintentionns, susceptibles dexploiter toute vulnrabilit du systme pour violer lesexigences de scurit.

1.1.2. Complexit des SICSS

Les SICSS sont des systmes riches en fonctionnalits, complexes, sensibles, htrognes etexigeant un niveau lev dinteroprabilit. En effet, les SICSS :

- relient des organisations multiples et des utilisateurs ayant des profils diffrents ; dans ledomaine mdical, il sagit de professionnels de sant, hpitaux et organismes payeurs ;dans la sphre sociale, il sagit des organismes de protection sociale, entreprises etbanques ;

1 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 (ouentreprises) bien identifis ou identifiables.

3 Le numro de SIREN est un numro attribu par lINSEE toute personne physique ou morale quiexerce une activit professionnelle lors de linscription au rpertoire national des entreprises.

5

- mettent en jeu des technologies complexes comme la communication, le traitementdinformation, la tlmdecine, le tlpaiement et larchivage ;

- manipulent des informations sensibles et htrognes ; il sagit de donnes textuelles ougraphiques, dimages et denregistrements de cardiogrammes, etc. ; le caractre, souventpersonnel, de ces informations, oblige prendre des prcautions particulires, afindassurer leur protection, notamment durant toute manipulation (accs, transfert,stockage) ;

- ncessitent une coopration de ses utilisateurs qui changent les informations, consultentles bases de donnes, et utilisent les applications mdicales, paramdicales, mdico-administratives et mdico-financires ; en effet, les mdecins, hpitaux, pharmacies etlaboratoires doivent pouvoir schanger des informations mdicales afin de favoriser laideau diagnostic ou la recherche pidmiologique ; les services dtude et de recherchepidmiologique envoient aux mdecins des statistiques dactivit et leur fournissent uneaide la dcision. Les mdecins envoient les feuilles de soins lectroniques aux rgimesdassurance maladie et reoivent, en change, des accuss de rception, etc.

La diversit des organisations dans lesquelles de telles applications doivent tre mises enuvre ainsi que les interactions entre les applications, ncessitent une grande flexibilit dans ladfinition 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 quiconcerne 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 domainegouvernemental, laccent est mis principalement sur la confidentialit, lintgrit tant le plussouvent estime comme secondaire et la disponibilit tant encore plus nglige : ladivulgation dune information est considre comme plus grave que son altration ou sonindisponibilit.

Dans le domaine financier, quil sagisse dapplications bancaires ou de comptabilit desentreprises, lintgrit est de loin le souci majeur, bien plus que la disponibilit, laconfidentialit tant encore dun moindre souci. En effet, une altration de linformation, quilsagisse de fraude ou dune faute accidentelle, peut avoir des consquences financiresdmesures. Le manque de disponibilit est gnralement dune gravit moindre. Quant auxpertes lies au manque de confidentialit, elles sont gnralement difficiles valuerfinancirement 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, deconfidentialit, dintgrit et de disponibilit, mais aussi dauditabilit. En effet, dans ledomaine mdical, lintgrit (des diagnostics, par exemple) et la disponibilit (caractredurgence) peuvent parfois tre vitales, au sens strict du terme, mais la confidentialit est plusquune obligation lgale : laccs des informations mdicales peut avoir des implicationsfinancires importantes vis--vis dun employeur ou dun assureur, mais peut aussi tre lasource dun chantage. La proprit dauditabilit est galement trs importante pour renforcerla responsabilit des personnels soignants. De la mme manire, dans le domaine social, laconfidentialit des donnes concernant les personnes et les entreprises, lintgrit destldclarations et des tlpaiements, la disponibilit des tlservices de Net-entreprises

Chapitre 1 Scurit des SICSS 6

(surtout dans les chances de dclarations et de paiements), ainsi que la responsabilit desactions (paiement chance par exemple), sont autant de points cruciaux.

Malheureusement, des conflits potentiels peuvent apparatre entre toutes ces exigences descurit 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 peutavoir 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 deconfidentialit (par exemple, risque dinfrence non autorise si ces donnes indirectementnominatives 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 etles organisations, lintgrit des donnes et des programmes, la disponibilit des services etdes donnes ncessaires au bon fonctionnement. Plusieurs tudes et statistiques rcentesmontrent lampleur de ces menaces. Des enqutes menes par la commission dauditbritannique [Audit 1998] et par le bureau dvaluation de la technologie du gouvernementamricain ont confirm que le domaine de la sant est lune des cibles privilgies dattaquantsaussi bien internes quexternes (atteinte la vie prive, fraudes, etc.) [Woodward 1995]. Plusrcemment, en 2001, un pirate a pu semparer du serveur de fichiers dun hpital Seattle (auxtats-Unis) et diffuser sur le Web (securityfocus.com) les fichiers mdicaux de cinq millepatients. Des tudes plus anciennes [Tufo 1971] rvlent que, dans plus de 30 % des cas, lesfichiers mdicaux sont indisponibles, et que mme quand ils sont disponibles, les dlaisncessaires pour extraire les informations sont souvent dcourageants. Les 26, 27 octobre et le4 novembre 1992, suite une surcharge du systme informatique, le service des ambulances deLondres a t bloqu ; causant la mort de vingt personnes. Lenqute a rvl que la transitionvers le systme de sauvegarde navait pas t correctement prpare.

cet gard, les vulnrabilits des SICSS peuvent tre de natures diverses : fautes deconception ou de spcification, comme les portes drobes permettant des infiltrationsmalveillantes extrieures (voir 1.4) ; politiques de scurit ne tenant pas compte de toutes lesmanipulations illgitimes ; faiblesses dans le systme socio-technique, dues par exemple uneprocdure dhabilitation trop laxiste des personnels ; protection physique insuffisante dumatriel et des ressources ; etc.

En outre, les attaques peuvent aussi bien provenir de lintrieur (abus de pouvoir, curiositallant au-del de lutilisation des informations et services strictement ncessaires pourlaccomplissement du travail) que de lextrieur (pirate informatique qui tente de lire ou demodifier 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 (violationde 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 lesorganismes de protection sociale) qui peuvent en avoir besoin pour leurs patients(respectivement entreprises) ou pour justifier leurs dcisions, si ncessaire (violation de ladisponibilit et de lauditabilit).

7

Enfin, le manque de confiance peut conduire chaque partenaire dun SICSS installer sapropre politique de scurit, au dtriment dune interoprabilit pourtant indispensable lchange dinformations entre les usagers des SICSS. Par ailleurs, la peur dun manque deconfidentialit, dintgrit, de disponibilit ou dauditabilit de tels systmes peut inciter despatients (ou, dans le domaine social, les entreprises) refuser de divulguer des informationspourtant capitales.

[Abou El Kalam et al. 2002c] identifie une liste plus exhaustive de risques spcifiques auxSICSS, mais aussi des risques plus gnraux, lis lutilisation de linformatique et de latlmatique. Par ailleurs, une caractrisation plus dtaille des besoins des SICSS peut tretrouve 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 levedans les services dlivrs. Cette confiance ne peut tre obtenue que si les SICSS sont srs defonctionnement. Cette section prsente les concepts et termes classiques usuels de la sret defonctionnement et de la scurit informatiques, et ceux spcifiques, ncessaires pourapprhender les atypismes et particularits des SICSS.

1.2.1. Dfinitions de base

La sret de fonctionnement dun systme informatique est la proprit qui permet sesutilisateurs 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 diffrentesfacettes de la sret de fonctionnement, ce qui revient dire que la sret de fonctionnementpeut tre vue selon des proprits diffrentes mais complmentaires, qui permettent de dfinirses 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 laconfidentialit ;

- 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 etfautes. Il y a dfaillance lorsque le service dlivr dvie du service attendu. Lerreur est lapartie de ltat du systme susceptible dentraner une dfaillance. Et la faute est la causeadjuge ou suppose de lerreur.

Les moyens de la sret de fonctionnement sont de deux ordres : dune part les mthodespermettant de fournir au systme laptitude dlivrer un service conforme au service attendu,dautre part celles permettant de donner une confiance justifie dans cette aptitude. Lobtentionde la sret de fonctionnement se fait par prvention des fautes ; ce qui consiste empcher parconstruction loccurrence ou lintroduction de fautes, et par tolrance aux fautes, qui permetpar redondance de fournir un service conforme en dpit de fautes. Les mthodes de validationde la sret de fonctionnement se classent en limination des fautes, correspondant larduction, 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 consquencesfutures (figure 1.1).

Chapitre 1 Scurit des SICSS 8

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 selonlesquelles on peut les classer sont leur cause, leur nature, leur phase de cration oudoccurrence, leur situation par rapport aux frontires du systme, et leur persistance (figure1.2).

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, quellessoient intentionnelles ou accidentelles. Ces fautes donnent lieu quatre classes de fautescombines :

- les fautes de conception, qui sont des fautes de dveloppement accidentelles ouintentionnelles sans volont de nuire ;

- les fautes dinteraction, qui sont des fautes externes, accidentelles ou intentionnelles sansvolont 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 decompromis effectus durant la conception, dans un souci de conserver au systme un niveau deperformances acceptable, de faciliter son utilisation, ou encore pour des raisons conomiques.

FAUTES PHYSIQUES

FAUTES DUES LHOMME CAUSE PHNOMNOLOGIQUE

FAUTES ACCIDENTELLES

FAUTES INTENTIONNELLESSANS VOLONT DE NUIRE

FAUTES INTENTIONNELLEMENT NUISIBLES

NATURE

FAUTESFAUTES DE DVELOPPEMENT

FAUTES OPRATIONNELLES

PHASE DE CRATION OU D'OCCURRENCE

FAUTES INTERNES

FAUTES EXTERNES FRONTIRES DU SYSTME

FAUTES PERMANENTES

FAUTES TEMPORAIRES PERSISTANCE

SRET DEFONCTIONNEMENT

ATTRIBUTS

DISPONIBILIT

FIABILITSCURIT - INNOCUIT CONFIDENTIALIT

INTGRIT

MAINTENABILIT

PRVENTION DE FAUTESTOLRANCE AUX FAUTES

LIMINATION DES FAUTES

PRVISION DES FAUTES

MOYENS

ENTRAVESFAUTESERREURSDFAILLANCES

9

Les fautes dinteraction intentionnelles sans volont de nuire peuvent rsulter de laction dunoprateur soit destine faire face une situation imprvue, soit violant dlibrment desprocdures sans avoir ralis les consquences malheureuses de son action. Gnralement, cesfautes ne sont identifies quaprs quelles aient caus une dfaillance.

Les logiques malignes recouvrent aussi bien des fautes de dveloppement comme leschevaux de Troie, les portes drobes, les bombes logiques, ou des fautes oprationnellescomme 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 htejusqu ce quun instant ou un vnement survienne, ou que certaines conditions soientrunies, pour dclencher des effets dvastateurs en son sein ;

- un cheval de Troie est un programme effectuant une fonction illicite tout en donnantlapparence deffectuer une fonction lgitime ; la fonction illicite peut tre de divulguer oudaltrer des informations, ou peut tre une bombe logique ;

- une porte drobe est un moyen de contourner les mcanismes de contrle daccs ; ilsagit dune faille du systme de scurit due une faute de conception accidentelle ouintentionnelle (cheval de Troie en particulier) ;

- un virus est un segment de programme qui, lorsquil sexcute, se reproduit ensadjoignant un autre programme (du systme ou dapplication), et qui devient ainsi uncheval 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 ouadministrateurs 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 concernela prvention de catastrophes : dans ce sens, un systme informatique aura une scuritsatisfaisante 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 suffisammentpeu probables. Ce type de scurit est bien videmment une exigence majeure lorsque le bonfonctionnement du systme informatique est ncessaire pour la sauvegarde de vies humainesou de lenvironnement, ou encore dintrts financiers importants. Cest en particulier le casdes 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 concernela capacit du systme informatique rsister des agressions externes physiques (incendie,inondation, bombes, etc.) ou logiques (erreurs de saisie, intrusions, piratages, logiquemalicieuse, 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 senssafety) 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 troisproprits : la confidentialit, lintgrit et la disponibilit de linformation. Notons que cestrois proprits se rapportent linformation, et le terme dinformation doit tre pris ici dansson sens le plus large, couvrant non seulement les donnes et les programmes, mais aussi les

Chapitre 1 Scurit des SICSS 10

flux dinformation, les traitements et la connaissance de lexistence de donnes, deprogrammes, de traitements, de communications, etc. Cette notion dinformation doit allerjusqu couvrir le systme informatique lui-mme, dont parfois lexistence doit tre tenuesecrte. Pour tre plus prcis, on distinguera informations et mta-informations ; lesinformations correspondant des donnes identifies, alors que les mta-informationsrenvoient des informations indirectes relies aux informations ou aux services4. Voiciquelques 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 doprationsillgitimes contribuant mettre en dfaut les proprits de confidentialit, dintgrit et dedisponibilit, mais aussi de garantir la possibilit de raliser les oprations lgitimes dans lesystme. 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 paratvident que la scurit-innocuit est une proprit importante pour les SICSS, et parconsquent, elle demeure un but global atteindre. En effet, la scurit des SICSS traite desproblmes du type : mauvaise identification des patients, modification illgitime dundiagnostic (manque dintgrit), retard ou absence de donnes dans des cas urgents critiques(manque de disponibilit), etc. Puisque ces problmes peuvent porter atteinte la vie despatients, ils concernent la scurit-innocuit, et donc, cette vision de la scurit (scurit-innocuit) 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 utilisateursnon 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 dautresutilisateurs (sauf autorisation).

Le terme information doit tre pris au sens le plus large : il recouvre non seulement lesdonnes elles-mmes, mais aussi les flux dinformation et la connaissance de lexistence desdonnes ou des communications. Assurer la confidentialit dun systme est donc une tchecomplexe. Il faut analyser tous les chemins quune information particulire peut prendre dansle systme pour sassurer quils sont scuriss. Il importe galement de prendre en compte lesconnaissances 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 quidoivent tre protges selon la politique de scurit, en dpit des moyens de protection et desrgles de scurit. Par exemple, les coutes passives consistent accder aux donnestransmises sur un canal de communication (cble de rseau, par exemple) ou stocke sur unsupport vulnrable (disques externes, par exemple). Une telle coute peut, dans certainescirconstances, permettre daccder des informations sensibles, comme le mot de passe dunutilisateur tap sur un terminal connect un ordinateur central, et qui transite en clair entre ceterminal 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 lesystme informatique doit :

- empcher une modification5 indue de linformation, cest--dire une modification par desutilisateurs non autoriss ou une modification incorrecte par des utilisateurs autoriss, et

- faire en sorte quaucun utilisateur ne puisse empcher la modification lgitime delinformation. Par exemple, empcher la mise jour priodique dun compteur de tempsconstituerait une atteinte lintgrit.

De plus, il faut avoir lassurance que toute modification de donne est approuve et quechaque programme se comporte de manire correcte (cest--dire conformment aux fonctionsquil est cens remplir, y compris dans ses interactions avec les autres processus). Il fautgalement sassurer quaucune information ne peut tre modifie par des intermdiaires, quecette altration soit intentionnelle (par exemple, un utilisateur intervient pour modifier unecommunication entre deux autres utilisateurs) ou accidentelle (une donne modifie lorsquelleest communique via un support de communication non-fiable).

Afin de se prmunir contre les fautes affectant lintgrit des donnes, il importe dintgrerdans le systme des mcanismes permettant dune part de dtecter les modifications desinformations, et dautre part de contrler les accs ces dernires (en grant les droits daccsdes programmes et utilisateurs). De plus, un travail de validation en amont peut galement treralis pour prvenir les fautes accidentelles.

1.3.4. Disponibilit

La disponibilit est la proprit dune information dtre accessible lorsquun utilisateurautoris en a besoin. Cela signifie que le systme informatique doit :

- fournir laccs linformation pour que les utilisateurs autoriss puissent la lire ou lamodifier, 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, unmoment 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.

Chapitre 1 Scurit des SICSS 12

(accomplissement des procdures mdicales et administratives, tude de lefficacit, etc.). Il estvident que ces ressources doivent tres disponibles aux utilisateurs autoriss dans des dlaisacceptables. La criticit de ces donnes dpend souvent de lapplication. En cas durgence parexemple, le mdecin du SAMU, doit pouvoir y accder, en un temps raisonnable et sans treconfront des difficults daccs ou une rupture du service dlivr par le systme.

Lorsquon sintresse la disponibilit de donnes persistantes, on parle volontiers deprennit 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 voireillimites. Les exemples sont multiples : donnes des maladies hrditaires dans le domainemdical et actes authentiques dans le domaine social. Prserver les fichiers est une tcheardue : au-del des capacits des supports darchivage et des choix pralables des formats etlogiciels, la majorit des techniques actuelles ne permettent pas de garantir la restitution desinformations que pour une dure limite en raison de leur obsolescence rapide. Il est certespossible de faire passer les informations dun support un autre, au fur et mesure desvolutions, 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 deremplir 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 celon 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 ouarrt du service). La premire catgorie dattaque est troitement lie lintgrit, tant donnquelle consiste modifier linformation prsente dans le systme cible, afin quil fournisse unrsultat erron. La deuxime catgorie peut galement trouver sa source dans une attaquecontre lintgrit des donnes ou du systme, dont lobjectif est dinterrompre le traitement delinformation (ou tout au moins de le retarder), comme dans le cas de la destruction dun liende communication. Cependant ce type dattaque peut galement tre mis en uvre enperturbant le fonctionnement temporel du systme, en surchargeant certaines des ressourcesdont il dpend, ou en surchargeant le systme lui-mme. De telles attaques peuvent, parexemple tre mises en uvre par une machine MA qui inonde constamment un rseau R, celui-ci tant utilis par une machine MB pour remplir un certain service.

Enfin, il est important de noter que loccurrence doprations illgitimes nest pas forcmentle signe dune action intentionnellement nuisible dun utilisateur. Des fautes accidentellesmettant en danger la scurit du systme peuvent parvenir du fait quun utilisateur, autoris etbien intentionn, ignore certaines des proprits attendues du systme ou ne matrise pascompltement toutes les implications des oprations quil effectue. En particulier, ledbranchement 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 delogiciels, etc. Nous conjecturons que toutes les proprits de scurit peuvent tre exprimes enterme de disponibilit, dintgrit et de confidentialit appliques des informations et desmta-informations [Deswarte 2003].

Ainsi lintimit, pour traduire le terme anglo-saxon de privacy, concerne le respect desliberts individuelles et la protection de la vie prive. Elle se rapporte directement laconfidentialit dinformations (donnes caractre personnel) et de mta-informations (identitde 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 laconfidentialit de mta-informations de communication, en vue dobtenir connaissance delexistence dun canal, lexistence dun message, des identits, des emplacements ou adressesde 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 (mta-information), ainsi quventuellement dautres mta-informations telles que linstantdmission ou le niveau de classification (intgrit des mta-informations). De la mmemanire, un document est authentique si son contenu na pas t altr (intgrit desinformations) et optionnellement si lauteur dclar est vraiment lauteur et non un plagiaire, sila 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 cettepersonne. Lauthentification est le processus qui donne confiance dans lauthenticit.

Lauditabilit et les proprits qui en dcoulent (imputabilit, irrfutabilit, etc.) [Trouessin2000] correspond la disponibilit et lintgrit dun ensemble de mta-informationsrelatives 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 systmene puisse nier lavoir ralise. La non-rpudiation correspond donc la disponibilit etlintgrit de mta-informations telles que lidentit de lmetteur (et ventuellement linstantdmission) dun message pour la non-rpudiation dorigine, ou telles que la rception etlidentit 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 propritsde scurit peuvent tre accidentelles, comme elles peuvent tre intentionnelles, avec ou sansvolont de nuire. Ds lors, il sagira de dtailler cette deuxime catgorie de fautes et deprsenter la terminologie ncessaire son tude dans le cadre des SICSS.

Une intrusion est dfinie comme tant une faute oprationnelle, externe, intentionnellementnuisible, rsultant de lexploitation dune vulnrabilit dans le systme [Powell & Stroud2003]. Lusage courant du mot intrusion couvre le fait de pntrer illgalement ou sans y treconvi dans un lieu, une socit, etc.

En outre, le systme peut tre attaqu (que ce soit par un intrus interne ou externe) sanssuccs. Dans ce cas, lattaque existe, mais la protection est suffisamment efficace pourempcher 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 devioler un ou plusieurs besoins de scurit ;

- au moins une faiblesse, faille ou vulnrabilit, qui est une faute accidentelle ouintentionnelle (avec ou sans volont de nuire), introduite dans la spcification, laconception ou la configuration du systme.

Figure 1.3 : Intrusion interprte comme une faute composite.

AttaqueIntrus Intrusion Erreur

Vulnrabilit

Intrus, concepteur ou oprateur

Systme

Chapitre 1 Scurit des SICSS 14

En dfinissant une menace comme une violation potentielle dune proprit de scurit, lescouples (menace, vulnrabilit) permettent didentifier les risques auxquels le systme tudipeut tre soumis. Une attaque contre la scurit du systme peut provenir de lintrieur ou delextrieur. Un intrus interne peut tre dfini comme tant un utilisateur malveillantappartenant lorganisation, tandis quun intrus externe est une personne nayant pas deprivilges. Il est donc un individu non enregistr comme utilisateur, mais qui tente de pntrerle 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 vulnrabilitse 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 etla conception ou lopration du systme socio-technique (violation du principe du moindreprivilge6, procdure dhabilitation trop laxiste des personnels, etc.) ;

- un intrus externe qui utilise des moyens dingnierie sociale, par exemple en dupant oucorrompant un utilisateur privilgi pour le pousser excuter une action malveillanteavantageuse pour son propre compte ; la vulnrabilit est la prsence dun utilisateurprivilgi corruptible ou trop peu mfiant, ce qui est aussi une faute de conception oudopration 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 enpartie dans les spcifications mmes du systme puisquil est contradictoire dexiger quunsystme soit totalement ouvert des utilisateurs bien intentionns et ferm aux utilisateursmalveillants. Ce type particulier dattaque exploite aussi des fautes de conception ou deconfiguration dans les nombreux htes connects Internet qui ont t pirats pour insrerdes processus zombies, ncessaires au montage dune attaque distribue et coordonne.Une troisime vulnrabilit, qui empche de lancer des contre-mesures efficaces, reposesur une faute de conception de la part des fournisseurs de services Internet quinimplmentent pas de filtrage (en entre et sortie) qui permettrait de tracer efficacementladresse 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 leslimites et les failles de cette politique. Cette distinction a un effet direct sur les typesdintrusions qui touchent le plus les SICSS, notamment :

- les vols de privilges ou accroissement non autoris de privilges ; il sagit dunchangement des privilges dun utilisateur sans que cela soit autoris par la politique descurit : par exemple, un utilisateur qui essaye de contourner les mcanismesdautorisation pour lire des informations confidentielles ;

- les abus de privilges ou utilisation abusive des oprations autorises ; par exemple desutilisateurs privilgis comme les administrateurs du systme, les oprateurs ou lesofficiers de scurit, peuvent abuser de leurs privilges pour effectuer des actionsmalveillantes.

Par ailleurs, il est intressant de se pencher galement sur les cas o une attaque contre lascurit 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 dontlinformation 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 nominativessensibles (auxquelles il na pas le droit daccder). ce niveau, aucun acte malveillant nestidentifi explicitement. Nanmoins, si lutilisation de ces informations est malveillante, il sagitbien dun abus de pouvoir. Des notions comme les fautes intentionnelles avec ou sans volontde nuire ou les divulgations accidentelles dinformation sont donc particulirementpertinentes 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 deprotection du rseau et du systme dinformation, on peut utiliser des services, desmcanismes, des outils et des procdures que lon nomme, de faon gnrale, des solutions oudes mesures de scurit. Par exemple, un service didentification et dauthentification aide rduire le risque dintrusion dans un systme. Les politiques de scurit seront prsentescomme un dispositif ncessaire pour renforcer la scurit des systmes. Puis il conviendradaborder succinctement la manire avec laquelle on peut les construire et les implmenter.Nous expliquons galement dautres contre-mesures pour renforcer la scurit comme lesmcanismes cryptographiques, le cloisonnement, laudit, la dtection dintrusion et la tolranceaux intrusions.

1.5.1. Politiques de scurit

Dans un systme informatique, lautorisation a pour but de ne permettre que les actionslgitimes, cest--dire empcher quun utilisateur puisse excuter des oprations qui nedevraient pas lui tre permises [Deswarte 2003]. Pour dfinir quelles sont les oprationsautorises et celles qui sont interdites, il faut tablir une politique de scurit ou doctrine descurit. Les ITSEC [ITSEC 1991] dfinissent une politique de scurit comme tant lensemble des lois, rgles et pratiques qui rgissent la faon dont linformation sensible etles autres ressources sont gres, protges et distribues lintrieur dun systmespcifique . cet gard, pour construire une politique de scurit il faut :

- dune part, dfinir un ensemble de proprits de scurit qui doivent tre satisfaites par lesystme ; par exemple une information classifie ne doit pas tre transmise unutilisateur non habilit la connatre, et

- dautre part, tablir un schma dautorisation, qui prsente les rgles permettant demodifier ltat de protection du systme ; par exemple le propritaire dune informationpeut 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 initialsr (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 schmadautorisation. Comme on la dj expliqu (voir 1.3), les proprits de scurit peuvent tredfinies en fonction de la confidentialit, lintgrit ou la disponibilit dinformations ou demta-informations.

Une politique de scurit peut se dvelopper dans trois directions distinctes : les politiques descurit physique, administrative et logique.

La politique de scurit physique prcise un ensemble de procdures et de moyens quiprotgent les locaux et les biens contre des risques majeurs (incendie, inondation, etc.) etcontrlent les accs physiques aux matriels informatiques et de communication (gardiens, ...).

La politique de scurit administrative dfinit un ensemble de procdures et moyens qui traitede tout ce qui ressort de la scurit dun point de vue organisationnel au sein de lentreprise. La

Chapitre 1 Scurit des SICSS 16

structure de lorganigramme ainsi que la rpartition des tches (sparation des environnementsde dveloppement, dindustrialisation et de production des applicatifs) en font partie. Lesproprits de scurit recherches visent, par exemple, limiter les cumuls ou les dlgationsabusives de pouvoir, ou garantir une sparation des pouvoirs.

La scurit logique fait rfrence la gestion du contrle daccs logique, lequel repose surun triple service didentification, dauthentification et autorisation. Elle spcifie qui le droitdaccder quoi, et dans quelles circonstances. Ainsi, tout utilisateur, avant de se servir dusystme, devra dcliner son identit (identification) et prouver quil est bien la personne quilprtend tre (authentification). Une fois la relation tablie, les actions lgitimes que peut fairecet utilisateur sont dtermines par la politique dautorisation (ce type de politiques nousintresse particulirement, et sera dcrit en dtail dans le chapitre suivant).

Lautorisation consiste grer et vrifier les droits daccs, en fonction des rglesspcifies dans la politique de scurit. On dit quun sujet (entit qui demande laccs, diteaussi entit active) possde un droit daccs sur un objet (entit laquelle le sujet souhaiteaccder, dite aussi entit passive) si et seulement sil est autoris effectuer la fonction daccscorrespondante sur cet objet. Les droits daccs peuvent tre symboliquement reprsents dansune matrice de droits daccs dont les lignes reprsentent les sujets et les colonnes reprsententles objets. Une cellule de la matrice contient donc les droits daccs dun sujet sur un objet. Lamatrice est gre conformment aux rgles dfinies dans la politique de scurit.

Lautorisation est mise en uvre par des mcanismes de contrle daccs. Il est gnralementrecommand dorganiser ces mcanismes de faon implmenter la notion de moniteur derfrence, dfini dans le livre orange [TCSEC 1985]. Le moniteur de rfrence est unintermdiaire entre les sujets et les objets. Il vrifie que chaque accs dun sujet vers un objetest garanti par un droit daccs dans la matrice de droits daccs ; en labsence de ce droitdaccs, laccs est refus. Le moniteur de rfrence doit tre inviolable (il ne doit pas pouvoirtre modifi), incontournable (il ne doit pas tre possible daccder un objet sans tre contrlpar le moniteur de rfrence), et totalement vrifi (il ne doit comporter aucune faute deconception ou de ralisation).

Pour tre la fois incontournables et inviolables, il est souhaitable que les contrles daccssoient 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 moniteurde rfrence par matriel. La plupart des microprocesseurs modernes offrent des mcanismesde contrle daccs par matriel, en particulier par la gestion de mmoire avec des registres desegments. Ces registres de segments peuvent tre considrs comme des capacits, cest--direune implmentation par lignes de la matrice de droits daccs : les registres de segmentscontiennent les rfrences aux objets auxquels le processus en cours (sujet) peut accder, ainsique les droits correspondants (au moins, lire et crire).

Malheureusement, la plupart des systmes dexploitation ne tirent pas parti de cesmcanismes. Dans Unix, par exemple, les contrles daccs sont principalement bass sur despermissions associes aux fichiers et aux rpertoires. Il sagit donc plutt duneimplmentation de la matrice de droits daccs par colonnes, cest--dire par listes de contrledaccs : chaque fichier, on associe la liste des sujets (sous Unix, utilisateur ou groupedutilisateur) qui peuvent accder au fichier et les droits correspondants. Dans ce cas, lecontrle daccs se fait uniquement chaque ouverture de fichier. On est donc assez loin de lanotion de moniteur de rfrence.

Cette notion de moniteur de rfrence est trs centralise, et donc difficile interprter dansun systme rparti ou sur un rseau. Le livre rouge [TNI 1987] propose un schmadautorisation dans lequel chaque machine possde son propre moniteur de rfrence. Dans cecadre, 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 derfrences. Le moniteur de rfrence du site, o se trouve le sujet, garantit lidentit du sujet etventuellement ses droits. Le moniteur de rfrence du site de lobjet contrle laccs lobjeten fonction de lidentit du sujet et ventuellement des droits transmis par lautre moniteur derfrence et en fonction des droits grs localement. Dans ce cas, la matrice de droits daccsest soit rpartie, soit rplique sur lensemble des sites (ce qui rend difficile le maintien de sacohrence). Mais le principal inconvnient de ce schma est que chaque moniteur de rfrencedoit faire confiance aux autres. Ainsi, si un intrus prend le contrle dun site ou siladministrateur dun site est malveillant ou corrompu, il lui est facile, par exemple, dedguiser8 un sujet local pour obtenir des droits indus sur des objets distants. Lintrusion dansun 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 dunserveur dautorisation, capable de vrifier les droits de lutilisateur lancer une transaction ouopration de haut niveau et de gnrer des preuves dautorisation pour lexcution rpartiede chaque lment de la transaction. Le second niveau est constitu du moniteur de rfrencelocal chaque site, et qui vrifie que chaque requte (pour excuter un lment dunetransaction) est accompagne dune preuve dautorisation valide. Dans ce cas, lintrusion dansun 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 enterme de permissions (par exemple tout mdecin a le droit daccder aux dossiers mdicaux deses patients) et dinterdictions (par exemple, les mdecins nont pas le droit deffacer desd