M ISE E N ΠU V R E D E PO L IT IQ U E S D E
C O N TR Ô LE D ’ACC ÈS FO RM ELLES P O U R D E S
A PPL IC A T IO N S B A SÉ E S S U R U N E A R C H IT E C T U R E
O R IE N T É E SERVICES
par
Michel Embe Jiague
Thèse en cotutelle présentée
au Département d’informatique en vue
de l’obtention du grade de Philosophiæ doctor (Ph.D .)
FACULTÉ DES SCIENCES, UNIVERSITÉ DE SHERBROOKE
à l ’École Doctorale MSTIC en vue
de l’obtention du grade de Docteur
UNIVERSITÉ PARIS-EST
1+1
Library and Archives Canada Published Héritage Branch Bibliothèque et Archives Canada Direction du Patrimoine de l'édition 395 Wellington Street Ottawa ON K 1A0N 4 Canada 395, rue Wellington Ottawa ON K1A 0N4 CanadaYour file Votre référence ISBN: 978-0-494-93271-1 Our file Notre référence ISBN: 978-0-494-93271-1
NOTICE:
The author has granted a non-
exclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by
télécomm unication or on the Internet, loan, distrbute and sell theses
worldwide, for commercial or non- commercial purposes, in microform, paper, electronic and/or any other formats.
AVIS:
L'auteur a accordé une licence non exclusive permettant à la Bibliothèque et Archives Canada de reproduire, publier, archiver, sauvegarder, conserver, transmettre au public par télécomm unication ou par l'Internet, prêter, distribuer et vendre des thèses partout dans le monde, à des fins com merciales ou autres, sur support microforme, papier, électronique et/ou autres formats.
The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.
L'auteur conserve la propriété du droit d'auteur et des droits moraux qui protégé cette thèse. Ni la thèse ni des extraits substantiels de celle-ci ne doivent être imprimés ou autrement
reproduits sans son autorisation.
In compliance with the Canadian Privacy A ct some supporting forms may have been removed from this thesis.
W hile these forms may be included in the document page count, their removal does not represent any loss of content from the thesis.
Conform ém ent à la loi canadienne sur la protection de la vie privée, quelques
form ulaires secondaires ont été enlevés de cette thèse.
Bien que ces form ulaires aient inclus dans la pagination, il n'y aura aucun contenu manquant.
Le 19 décembre 2012
le ju ry a accepté la thèse de Monsieur Michel Embe Jiague dans sa version finale.
M em bres du ju ry Professeur R ichard St-Denis
Codirecteur de recherche Département d ’inform atique
Université de Sherbrooke
Professeure Régine Laleau Codirectrice de recherche
Laboratoire d ’Algorithmique, Complexité et Logique U niversité Paris 12
Professeur Frédéric Gervais Codirecteur de recherche Université Paris-Est Créteil
Professeur Froduald K abanza Président rapporteur Département d ’informatique
Université de Sherbrooke
Professeur M ohand-Said Hacid Rapporteur
U niversité de Lyon
Professeur Béchir Ktari Évaluateur externe
< dédicaces > <grand-mère-bien-aimée>Mami Oli</ grand-mère-bien-aimée> <fils-adoré>Natou</fils-adoré> </dédicaces>
S om m aire
La sécurité des systèmes d ’inform ation devient un enjeu préoccupant pour les organisations ta n t publiques que privées, car de tels systèm es sont pour la plupart universellement accessibles à p a rtir de navigateurs Web. P arm i tous les aspects liés à la sécurité des systèmes d ’information, c’est celui de la sécurité fonctionnelle qui est étudié dans cette thèse sous l’angle de la mise en œ uvre de politiques de contrôle d ’accès dans une architecture orientée services. L ’élém ent de base de la solution pro posée est un modèle générique qui intro d u it les concepts essentiels pour la conception de gestionnaires d ’exécution de politiques de contrôle d ’accès et qui étab lit une sé paration n ette entre le système d ’inform ation et les mécanismes de contrôle d ’accès. L’instanciation de ce modèle conduit à un cadre d ’applications qui com porte, entre autres, un filtre de contrôle d ’accès dynamique. C ette thèse présente également deux m éthodes systém atiques d ’im plém entation de ce filtre à p a rtir de politiques écrites en ASTD, une n otation graphique formelle basée sur les statecharts augm entés d ’opé rateurs d ’une algèbre de processus. La n otation ASTD est plus expressive que la norme RBAC et ses extensions. La première m éthode repose sur une transform ation de politiques de contrôle d ’accès, instanciées à p a rtir de patron s de base exprimés en ASTD, en des processus BPEL. La deuxième m éthode est basée sur une in terpréta tion de spécifications ASTD par des processus B PEL. Dans les deux cas, les processus B PEL s’exécutent dans un m oteur d ’exécution B PEL et interagissent avec le système d ’information. Ces deux m éthodes p erm etten t une im plém entation autom atique d ’un cadre d ’applications à p a rtir de la spécification de départ. Finalem ent, un prototype a été réalisé pour chacune des deux m éthodes afin de m ontrer leur faisabilité au niveau fonctionnel et de com parer leurs perform ances au niveau système.
So m m a i r e
M o ts-c lé s: systèm e d ’inform ation, sécurité fonctionnelle, contrôle d ’accès, architec tu re orientée services, m éthode de spécification formelle, service Web, transform ation de spécifications, interprétation de spécifications.
R em erciem en ts
Ce travail est le résultat d ’un long parcours. Je veux profiter de ces quelques m ots pour exprimer m a gratitu d e à toutes les personnes exceptionnelles qui ont contribué de près ou de loin à son aboutissem ent. Je pense bien sûr to u t d ’ab o rd à des en seignants exceptionnels. Richard St-Denis et Marc Frappier de l’Université de Sher brooke, Régine Laleau et Frédéric Gervais de l’U niversité Paris-E st, merci ! Merci pour vos conseils éclairés. En effet, je ne saurais dénom brer le nom bre de fois où vos indi cations m ’ont perm is de trouver des solutions à des problèmes rencontrés. Merci pour votre implication et votre soutien financier, car sans ceux-ci ce travail de recherche ne serait pas achevé. Enfin, merci pour votre patience e t l’opportunité que vous m ’avez offertes. Je tiens aussi à exprim er m a g ratitu d e à mes collègues de d o cto rat, Jérémy et Pierre, dont la coopération a été un élément indispensable à cette thèse.
Je tiens ensuite à remercier particulièrem ent m a famille. Papa, m am an, mes frères et soeurs, Gwladys l’élue de mon cœur, m ’ont accompagné pendant mes études docto rales par leurs encouragements incessants, leurs vœux bienveillants et leurs prières. Je remercie également mes amis, d ’ici et d ’ailleurs, pour le soutien moral et la patience q u ’ils ont manifestés à mon égard. Enfin, à ceux qui ne sont pas mentionnés mais qui m ’ont soutenu du ran t cette thèse, merci.
A b rév ia tio n s
ACIT Availability, Confidentiality, Integrity and Traceability
ACL Access Control List
ASM A bstract-S tate Machine
ASTD Algebraic S tate Transition Diagram
BPEL Business Process Execution Language
CSP C om m unicating Sequential Processes
EB Entity-B ased Black-Box
EBSEC EB3SECure
ESB Enterprise Service Bus
DAC Discretionary Access Control
DOM Document O bject Model
GTRBAC Generalized Temporal Role-Based Access Control
GUID Globally Unique IDentifier
HTTP HyperText Transfer Protocol
LOTOS Language Of Tem poral Ordering Spécification
MAC M andatory Access Control
MDE Model-Driven Engineering
NIST N ational In stitu te of S tandards and Technology
OASIS Organization for the Advancement of S tru ctu red Inform ation S tandards
Ab r é v i a t i o n s
PAP Policy A dm inistration Point
PDP Policy Décision Point
PEM Policy Enforcement M anager
PEP Policy Enforcement Point
PIP Policy Inform ation Point
POSIX P ortable O perating System Interface
RBAC Role-Based Access C ontrol
SELKIS SEcure heaL th care networKs Inform ation Systems
SGBD systèm e de gestion de base de données
SOA Service O riented A rchitecture
SOAP Simple O bject Access Protocol
SoD Séparation of D uty
SQL S tructured Q uery Language
UML Unified Modeling Language
URL Uniform Resource Locator
W-RBAC Workflow Role-Based Access Control
W3C W orld W ide W eb Consortium
WfMS Workflow M anagem ent System
WSDL Web Service Définition Language
X-GTRBAC XML Generalized Tem poral Role-Based Access Control
XACML eXtensible Access C ontrol M arkup Language
XML eXtensible M arkup Language
XPath XML P a th Language
XSD XML Schéma Docum ent
XSL Extensible Stylesheet Language
T able d es m a tières
S o m m a ire iii
R e m er c iem en ts v
A b r é v ia tio n s v i
T able d es m a tiè r e s v iii
L iste d es figu res x iii
L iste d e s ta b le a u x x v ii L iste d es p ro g ra m m es x v iii In tr o d u ctio n 1 1 C o n c e p ts d e b a se 13 1.1 Le langage ASTD ... 13 1.2 A pplications SOA ... 19 1.2.1 Services W e b ... 21
1.2.2 Im plém entation d ’une application S O A ... 23
1.3 Le protocole SOAP ... 23
1.4 Le langage W S D L ... 25
1.5 Le langage de processus B P E L ... 28
1.5.1 Interface d ’un processus B P E L ... 29
Ta b l e d e s m a t i è r e s
1.6 C o n clu sio n... 33
2 C o n trô le d ’a ccès d a n s les s y s tè m e s d ’in fo r m a tio n 34 2.1 Politique de contrôle d ’a c c è s ... 34
2.1.1 Politique de contrôle d ’accès s t a t i q u e ... 34
2.1.2 Politique de contrôle d ’accès d y n a m iq u e ... 35
2.2 Form alisation du contrôle d ’a c c è s ... 35
2.3 Listes de contrôle d ’a c c è s ... 36
2.4 M atrices de contrôle d ’a c c è s ... 37
2.5 Modèle de B e ll-L a P a d u la ... 40
2.6 Contrôle d ’accès basé sur les r ô le s ... 42
2.7 La m éthode E B 3SEC ... 45
2.8 P atro n s de contrôle d ’a c c è s ... 49
2.9 C o n clu sio n... 52
3 É ta t d e l ’art 53 3.1 La norme X A C M L ... 53
3.1.1 Structure d ’un docum ent X A C M L ... 53
3.1.2 Requête et réponse d ’autorisation ... 55
3.1.3 C om posants d ’un P E M ... 55
3.1.4 Discussion ... 58
3.2 Im plém entations du contrôle d ’a c c è s ... 58
3.2.1 Le cadre d ’applications X -G T R B A C ... 59
3.2.2 Cadre d ’applications W -RBAC pour les w o rk flo w s ... 61
3.2.3 Discussion ... 66
3.3 Transform ation de m o d è le s ... 67
3.3.1 Vérification de processus B P E L ... 68
3.3.2 Développement de processus B PEL c o r r e c t s ... 70
3.3.3 Discussion ... 71
4 M o d è le g én ériq u e d ’u n P E M 72 4.1 A rchitecture et composants d ’un P E M ... 72
4.1.1 Com posants actifs de l’architecture ... 73 ix
Ta b l e d e s m a t i è r e s
4.1.2 Échange informel de m essag es... 73
4.1.3 Différentes architectures possibles ... 74
4.2 Spécification du PEM par m étam odélisation ... 77
4.2.1 Diagrammes de s é q u e n c e s ... 77
4.2.2 Diagrammes de c la s s e s ... 81
4.3 Instances du m é ta m o d è le ... 86
4.4 C o n clu sio n... 93
5 T ra n sfo rm a tio n d ’u n e p o litiq u e d e c o n tr ô le d ’a c cè s 94 5.1 Vue globale de l’algorithm e de transform ation ... 95
5.2 Évolution de l’algorithm e de tra n sfo rm a tio n ... 96
5.3 Règles de tr a n s f o r m a tio n ... 97
5.3.1 Le c o n trô le u r... 97
5.3.2 Les opérations des p ro cessu s... 98
5.3.3 Les liens de p a r t e n a i r e ... 99
5.4 Transform ation d ’une spécification A S T D ... 102
5.4.1 N otation ... 102
5.4.2 Transform ation de stru ctu res ASTD en processus B PEL . . . . 103
5.4.3 Transform ation de la stru ctu re A STD choix quantifié ... 104
5.4.4 Transform ation de la stru ctu re A STD ferm eture de Kleene . . 107
5.4.5 Transform ation de la stru ctu re ASTD g a r d e ... 110
5.4.6 Transform ation de la stru ctu re ASTD s é q u e n c e ... 112
5.4.7 Transform ation de la stru ctu re ASTD synchronisation paramétrée 115 5.4.8 Transform ation de la stru ctu re ASTD a u to m a te ... 117
5.5 G énération des types X S D ... 122
5.6 G énération du docum ent d ’interfaces W S D L ... 124
5.7 C on clu sio n ... 127
6 In te r p r é ta tio n d ’u n e p o litiq u e d e c o n tr ô le d ’a ccès 129 6.1 A rchitecture du filtre de contrôle d ’accès dynam ique ... 130
6.1.1 Processus B PEL F i l t e r... 130
6.1.2 Processus B PEL A S T D ... 132
6.1.3 Processus B PEL des structures A S T D ... 134 x
Ta b l e d e s m a t i è r e s
6.2 La stru ctu re et le form at de d o n n é e s ... 134
6.2.1 Document XML d ’une spécification A S T D ... 135
6.2.2 D ocum ent XML de l ’é ta t d ’une spécification A S T D ... 139
6.2.3 E n v iro n n em en t... 142
6.2.4 Ensemble de v a le u rs... 144
6.2.5 G arde et p r é d i c a t ... 146
6.3 Interactions entre les processus B P E L ... 148
6.4 Interprétation de spécifications A S T D ... . 151
6.5 C o nclu sio n ... 155
7 E x p é r im e n ta tio n 156 7.1 Description des jeux d ’e s s a i... 156
7.2 Environnem ents de t e s t ... 161
7.3 Tests unitaires ... 161
7.3.1 La stru ctu re ASTD a u to m a te ... 162
7.3.2 La stru ctu re ASTD ferm eture de K l e e n e ... 165
7.3.3 La stru ctu re ASTD séquence ... 166
7.3.4 La stru ctu re ASTD c h o i x ... 167
7.3.5 La stru ctu re ASTD synchronisation p a r a m é tr é e ... 168
7.3.6 La stru ctu re ASTD a p p e l ... 169
7.3.7 La stru ctu re ASTD g a r d e ... 170
7.3.8 La stru ctu re ASTD choix q u a n tifié ... 171
7.3.9 La stru ctu re ASTD synchronisation q u a n tifié e ... 173
7.3.10 Conclusion sur les tests u n ita ir e s ... 173
7.4 Tests de p e r f o r m a n c e ... 175
7.4.1 Description de l’étude de cas ... 175
7.4.2 Données d ’essai . 180
7.4.3 R ésultats d ’ex p érien c e s... 183
7.4.4 Conclusion sur les te sts de p e rfo rm a n c e ... 183
7.5 Conclusion g é n é r a l e ... 185
C o n clu sio n 186
Ta b l e d e s m a t i è r e s
A M é ta m o d è le X S D d e la n o ta tio n A S T D 190
B E x tr a it d u fichier W S D L 203
C S p éc ifica tio n s A S T D d e s p o litiq u e s d e la b a n q u e 206
L iste d es figures
1.1 Exemple d ’une stru ctu re ASTD a u to m a te ... 14
1.2 Exemple d ’une stru ctu re ASTD s é q u e n c e ... 15
1.3 Diagramme de classes d ’un systèm e d ’in f o r m a tio n ... 16
1.4 Spécification ASTD d ’une b ib lio th è q u e ... 17
1.5 Technologies des services W e b ... 21
1.6 Interactions avec un service Web ... 22
1.7 Im plém entation d ’une application SOA ... 23
1.8 Exemple de gestionnaires S O A P ... 25
1.9 Structure d ’un docum ent W SDL selon deux versions ... 26
1.10 Exemple d ’un processus B P E L ... 30
2.1 Diagramme entité-relation d ’un modèle à la R B A C ... 44
2.2 Diagramme de classes d ’un modèle EB 3SEC ... 46
2.3 P atro n ASTD pour la p e r m is s io n ... 50
2.4 P atron ASTD pour l’i n t e r d i c t i o n ... 50
2.5 P atron ASTD pour l’o b l i g a t i o n ... 51
2.6 P atro n ASTD pour la séparation des d e v o i r s ... 52
3.1 Modèle d ’une politique X A C M L ... 54
3.2 Diagramme de flux de données X A C M L ... 57
3.3 A rchitecture de com posants pour une décision X - G T R B A C ... 61
3.4 M étamodèle W O -R B A C ... 63
3.5 Interactions entre les com posants et les u t i l i s a t e u r s ... 64
3.6 Transform ations de modèles dans M D E ... 68
Li s t e d e s f i g u r e s
4.1 Échange typique de m essages... 74
4.2 A rchitecture centralisée du P E M ... 75
4.3 A rchitecture décentralisée du P E M ... 76
4.4 A rchitecture hybride du P E M ... 76
4.5 Diagramme de séquences : PDP au plus h au t n i v e a u ... 78
4.6 Exemple d ’une hiérarchie de PDP dans le dom aine m é d ic a l... 79
4.7 Diagramme de séquences : PDP à un niveau in te r m é d ia ir e ... 80
4.8 Diagramme de séquences : PDP au plus bas n iv e a u ... 81
4.9 Diagramme de classes : com posants du P E M ... 82
4.10 Diagramme de classes : hiérarchie de m e s s a g e s ... 83
4.11 Diagramme de classes : param ètres de contrôle d ’a c c è s ... 83
4.12 Diagramme de classes : contrôle d ’accès s t a t i q u e ... 84
4.13 Diagramme de classes : contrôle d ’accès d y n a m iq u e ... 85
4.14 Diagramme de classes : hiérarchie de P D P ... 86
4.15 Schéma d ’une politique de contrôle d ’accès s t a t i q u e ... 87
4.16 Schéma d ’une politique de contrôle d ’accès d y n a m i q u e ... 89
4.17 Classes instances des param ètres de contrôle d ’a c c è s ... 89
4.18 Instanciation des com posants actifs de contrôle d ’a c c è s ... 90
4.19 Diagrammes d ’instanciation des f i l t r e s ... 91
5.1 Prétraitem ent des cycles d ’une spécification ASTD ... 95
5.2 Schéma du c o n tr ô le u r ... 98
5.3 Exemple de liens de p a rte n a ire ... 100
5.4 Branche de la stru ctu re choix q u a n tifié ... 106
5.5 Branche Tkf R de la stru ctu re ferm eture de Kleene ... 109
5.6 Branche de la stru ctu re garde ... 111
5.7 Branche de la stru ctu re séquence ... 114
5.8 Branche de la stru ctu re synchronisation p a r a m é tr é e ... 116
5.9 Cas 1 : transition sortan te u n iq u e ... 118
5.10 Cas 2 : plusieurs transitions sortantes ... 119
5.11 Cas 3 : aucune transition s o r ta n te ... 119
6.1 Vue d ’ensemble du filtre de contrôle d ’accès d y n a m iq u e ... 130 xiv
Li s t e d e s f i g u r e s
6.2 A rchitecture du filtre de contrôle d ’accès dynam ique ... 131
6.3 Processus F i l t e r ... 132
6.4 Processus ASTD... 133
6.5 Processus Q C h o i c e ... 134
6.6 Définition de l’élément S p é c i f i c a t i o n ... 135
6.7 Schéma XSD des stru ctu res A S T D ... 136
6.8 Exemple d ’une stru ctu re ASTD choix q u a n tifié ... 138
6.9 Schéma XSD des é tats d ’une stru ctu re A S T D ... 141
6.10 Éléments XML de l’é ta t d ’une synchronisation q u a n tifié e ... 142
6.11 Exemples de p ré d ic a ts ... 146
6.12 A rbre syntaxique a b strait du prédicat 3 > x * 2 + 1 ... 147
6.13 G raphe d ’interactions entre les processus du filtre de contrôle d ’accès 148 6.14 Interactions entre les processus F i l t e r et ASTD ... 149
6.15 Interactions entre les processus ASTD et Q C h o i c e ... 150
6.16 Interactions entre Q C h o ic e et G u a r d à travers A S T D ... 150
6.17 Évolution des identifiants des p r o c e s s u s ... 151
6.18 Organigram m e de l’opération E x é c u t é du processus Q C h o ic e . . . 153
6.19 Organigram m e de l’opération I s F i n a l du processus Q C h o ic e . . . 154
6.20 Organigram m e de l’opération IS du processus Q C h o i c e ... 155
7.1 C réation du filtre de contrôle d ’a c c è s ... 158
7.2 E xtraction des spécifications du filtre de contrôle d ’a c c è s ... 159
7.3 Création des fichiers projet s o a p U I ... 160
7.4 Spécifications d ’une stru ctu re ASTD a u to m a te ... 162
7.5 Histogramm e des tem ps moyens de l’autom ate AUT1 ... 164
7.6 Histogramme des tem ps moyens de Y automate AUT2 ... 164
7.7 Spécification d ’une stru ctu re ASTD ferm eture de K l e e n e ... 165
7.8 Histogramme des tem ps moyens de la stru ctu re K L E 1 ... 165
7.9 Spécification d ’une stru ctu re ASTD s é q u e n c e ... 166
7.10 Histogramme des tem ps moyens de la stru ctu re S E Q 1 ... 166
7.11 Spécification d ’une stru ctu re ASTD c h o i x ... 167
7.12 Histogramme des tem ps moyens de la stru ctu re C H O l... 167
Li s t e d e s f i g u r e s
7.13 Spécification d ’une stru ctu re ASTD synchronisation paramétrée . . . . 168
7.14 Histogramme des tem ps moyens de la stru ctu re S Y N 1 ... 169
7.15 Spécification d ’une stru ctu re ASTD a p p e l... 169
7.16 Histogramme des tem ps moyens de la stru ctu re C A L 1 ... 170
7.17 Spécification d ’une stru ctu re ASTD g a r d e ... 171
7.18 Histogramme des tem ps moyens de la stru ctu re GR1 ... 171
7.19 Spécification d ’une structu re ASTD choix q u a n t i f i é ... 172
7.20 Histogram me des tem ps moyens de la stru ctu re Q C H 1... 172
7.21 Spécification d ’une stru ctu re ASTD synchronisation quantifiée . . . . 173
7.22 Histogramme des tem ps moyens de la stru ctu re Q S Y N 1... 174
7.23 Diagramme de classes du systèm e d ’inform ation de la b a n q u e 175 7.24 Spécification ASTD de la règle 2 ... 178
7.25 Système sécurisé de la banque d é p lo y é ... 181
7.26 Nombre de clients virtuels actifs en fonction du tem ps ... 182
7.27 R ésultats des tests de c h a r g e ... 184
L iste d es ta b le a u x
2.1 Exemple d ’une m atrice de contrôle d ’accès ... 38
2.2 O pérations de modification de m atrices de contrôle d ’a cc è s... 40
2.3 Niveaux de sécurité pour des o b je ts ... 42
2.4 Données d ’une politique de contrôle d ’accès RBAC ... 44
4.1 Données d ’une politique de contrôle d ’accès s ta tiq u e ... 88
7.1 Caractéristiques des machines de l’e x p é rie n c e ... 161
7.2 Param ètres des tests u n i t a i r e s ... 162
7.3 Exécution sans persistance pour la spécification AUTl ... 163
7.4 Listes des opérations permises pour chaque r ô l e ... 178
7.5 Statistiques sur la base de d o n n é e s ... 180
7.6 Param ètres des tests de c h a rg e ... 182
L iste d es p rogram m es
1.1 Document XML d ’une stru ctu re ASTD a u t o m a t e ... 18
1.2 M étamodèle d ’une stru ctu re ASTD a u to m a te ... 19
1.3 Document XML de l’é ta t d ’une stru ctu re ASTD a u to m a te ... 19
1.4 Requête S O A P ... 24
1.5 Réponse S O A P ... 24
1.6 E x trait d ’un docum ent W S D L ... 27
1.7 Activités de com m unication B P E L ... 31
1.8 Exemple de l’activité a s s i g n ... 33
2.1 Exemple d ’ACL pour des f i c h i e r s ... 36
3.1 Requête X A C M L ... 56
3.2 Réponse X A C M L ... 56
4.1 Requête SQL du prédicat statique ... 92
5.1 Algorithme de création du contrôleur B P E L ... 98
5.2 D éclaration d ’un type de lie n ... 100
5.3 Utilisation d ’un lien de partenaire dans le contrôleur p a r e n t ... 101
5.4 Utilisation d ’un lien de partenaire dans le contrôleur e n f a n t ... 101
5.5 Fonctions de création des liens de p a r t e n a i r e ... 101
5.6 Transform ation d ’une s p é c ific a tio n ... 102
5.7 Transform ation d ’une stru ctu re A S T D ... 103
5.8 Transform ation de la stru ctu re choix q u a n t i f i é ... 104
5.9 Branche S t o p du contrôleur du choix q u a n tifié ... 105
5.10 Transform ation de la stru ctu re ferm eture de K l e e n e ... 107
5.11 Branche S t o p du contrôleur de la ferm eture de K le e n e ... 108
5.12 Transform ation de la stru ctu re g a r d e ... 110 xviii
Li s t e d e s p r o g r a m m e s
5.13 Transform ation de la stru ctu re séquence . ... 112
5.14 Branche S t o p du contrôleur de la sé q u e n c e ... 113
5.15 Transform ation de la structure synchronisation param étrée... 115
5.16 Transform ation de la structure a u to m a te ... 117
5.17 Cas d ’un é ta t avec une seule transition s o r t a n t e ... 118
5.18 Cas d ’é ta ts successifs chacun avec une seule tran sitio n sortante . . . . 118
5.19 Cas d ’un é ta t avec plusieurs transitions sortantes ... 119
5.20 Cas d ’un é ta t sans transition s o r t a n t e ... 119
5.21 Fonction T * ... 120
5.22 Fonction T j ... 121
5.23 Document XSD du filtre de contrôle d ’accès dynam ique ... 123
5.24 Document WSDL du filtre de contrôle d ’accès d y n a m iq u e ... 125
5.25 Procédure de création des services W e b ... 127
6.1 Encodage XML d ’une stru ctu re A S T D ... 139
6.2 Encodage XML de l’é ta t d ’une stru ctu re A S T D ... 139
6.3 Un environnement XML avec trois v a ria b les... 143
6.4 Environnem ent mis à jo u r pour une stru ctu re q u a n t i f i é e ... 143
6.5 Document XML pour la mise à jour d ’un e n v iro n n e m e n t... 144
6.6 Nouvel en v iro n n e m en t... 145
6.7 Définition de l’ensemble de quantification d ’une v a r i a b l e ... 145
6.8 Liste de valeurs pour le type R ô l e s ... 146
6.9 Encodage XML du prédicat 3 > x * 2 + 1 ... 147
6.10 Requête SOAP de l’opération E x é c u t é ... 152
7.1 Fichier des données d ’e s s a i ... 157
7.2 Spécification ASTD de la règle 2 . . ... 179
A .l Document XSD du métam odèle de la n o tatio n A S T D ... 190
B .l Éléments b i n d i n g du fichier W S D L ... 203
C .l Politique de contrôle d ’accès B a n k A C P o li c y B a la n c e ... 206
C.2 Politique de contrôle d ’accès B a n k A C P o l i c y S o D O b l ... 209
C.3 Politique de contrôle d ’accès B a n k A C P o li c y W ith d r a w ... 221
In tr o d u c tio n
La décennie des années 1980 ont vu un accroissement significatif du nom bre de sys tèmes d ’inform ation [51]. Ceux-ci offrent une solution à la prolifération des données d ’entreprise. Ils p erm etten t en effet d 'acquérir des données au moyen d ’une interface utilisateur sur le bureau ou à travers le réseau, ou encore au moyen d ’une interface de type service. Ces données sont stockées dans des bases de données ou des dépôts de données. Les systèmes d ’inform ation peuvent ensuite traiter ces données suivant les besoins de leurs utilisateurs et perm ettre de visualiser des données de natu res diverses. Un autre type de systèmes, très orienté vers les utilisateurs, a pris de l’expansion ces dernières années. Il s’agit des réseaux sociaux, qui to u t comme les systèmes d ’infor mation, collectent un volume im portant de données soumises à de fortes contraintes de respect de la vie privée. En effet, leur principale fonction est le partag e d ’infor m ations — de n atu re privée très souvent — entre des groupes d ’utilisateurs formés au to u r d ’un intérêt ou lien commun. C et intérêt ou lien peut être la famille, l’am itié, un sport, une institu tio n d ’enseignement ou le même lieu d ’habitation.
C o n te x te
De nos jours les utilisateurs des systèmes d ’inform ation y accèdent de plus en plus de n ’im porte où. Dans les entreprises, les utilisateurs accèdent aux systèmes p ar des term inaux qui peuvent être des clients m atériels légers ou encore des clients logiciels (applications Web ou Java par exemple). Il existe aussi des clients em barqués dans des term inaux, tels que les téléphones intelligents, qui sont continuellem ent connec tés ou qui utilisent un mode différé de synchronisation aux systèmes centraux. Il se pose donc de nom breux problèmes de sécurité des systèmes et de leurs données. Ces
In t r o d u c t i o n
problèmes sont d ’au tan t plus nom breux que les moyens d ’accès aux systèm es d ’infor m ation le sont, car ceux-ci constituent les vecteurs d ’a tta q u e les plus courants. Les ingénieurs doivent donc protéger ces systèmes et leurs données contre les attaq u es physiques au niveau du m atériel et les attaq u es au niveau du logiciel. La redondance de certains équipem ents réseau perm et dans certains cas de contrecarrer des attaq u es de type déni de service. Dans [35] p ar exemple, elle est utilisée pour offrir une certaine protection des données. C ette même technique peu t être utilisée pour lu tte r contre les pannes matérielles des systèmes. Les attaq u es de ty p e « M an-in-the-M iddle » peuvent être bloquées p ar des techniques qui utilisent de m anière appropriée un protocole de communication adéquat et la cryptographie. Schneier [46] passe en revue de nom breux protocoles et algorithm es de cryptographie. Il explore aussi leur utilisation dans le b u t d ’obtenir la confidentialité des données. D ans les systèmes d ’inform ation, les mesures de sécurité mises en place doivent assurer les propriétés A CIT : disponibilité (Availa- bility en anglais), confidentialité (Confidentiality en anglais), intégrité (Integrity en anglais) et traçabilité (Traceability en anglais). La disponibilité est la capacité du système à rendre le service pour lequel il est déployé conformément à ses spécifica tions techniques non fonctionnelles. La confidentialité est la propriété d ’un système qui n ’autorise l’accès à ses ressources q u ’aux utilisateurs accrédités, h'1 intégrité est l’aptitu d e du système à pouvoir m aintenir les données dans un é ta t cohérent et à éventuellement reprendre son fonctionnement norm al en cas de panne, c’est-à-dire sans que les données soient corrompues. La traçabilité renvoie à la capacité d ’un système à fournir des inform ations sur les événements survenus (modification ou sup pression de données, accès à une donnée ou à un traitem en t particulier p ar exemple). Ces informations peuvent p erm ettre l’au d it du systèm e ou même la récupération en cas de panne.
La plupart des systèmes m etten t en place un protocole d ’authentification. Celui-ci a pour but de ne perm ettre l’utilisation du systèm e que p ar des utilisateurs légi times. Toutefois, une fois un utilisateur authentifié, les menaces de sécurité restent toujours im portantes pour les systèmes et leurs données. Une solution est d ’appli quer un contrôle d ’accès adéquat aux actions effectuées et aux données accédées par l’utilisateur. Le contrôle d ’accès a d ’ailleurs toujours été utilisé dans une certaine me
In t r o d u c t i o n
sure pour lim iter la vue d ’un utilisateur du systèm e (données e t traitem ents) vis-à-vis du système dans son ensemble. En particulier, p ar rap p o rt au x propriétés ACIT, le contrôle d ’accès garantit en partie les propriétés de disponibilité et de confidentialité.
N otre thèse fait partie de deux projets de recherche sur la sécurité fonctionnelle des systèmes d ’inform ation qui assure, p ar des moyens utilisés au niveau application, l’accès aux ressources des systèmes selon les conditions prévues. Le projet canadien EB3SECure (EB 3SEC) cible la sécurité fonctionnelle des systèm es d’inform ation d ’ins titu tio n s financières. Le projet français SELKIS, acronyme pou r « SEcure heaL th care networKs Inform ation Systems », cible aussi la sécurité fonctionnelle, mais celle des systèmes d ’inform ation des établissem ents de santé. Ils ont pour b u t l’élaboration de langages, m éthodes et procédés p erm ettan t d ’obtenir des systèmes d ’inform ation dont l’aspect sécuritaire intègre les caractéristiques disponibilité et confidentialité de ACIT et dont le développement s ’effectue de m anière indépendante d u systèm e visé
[13, 14].
P r o b lé m a tiq u e
Dans de nombreux secteurs de la société tels que la santé et la finance, les activi tés sont régies p ar des réglem entations gouvernem entales strictes. À celles-ci peuvent aussi s ’ajouter des règles internes de l’entreprise q u ’elle s’impose pour mener à bien ses affaires dans le cadre de ce que la loi perm et. Les entreprises, qui doivent se confor mer à ces deux catégories de règles de n atu re légale, m etten t en place des systèmes d ’inform ation qui intègrent de telles règles d ’une façon ou d ’une autre. Mais généra lement dans les im plém entations des systèmes d ’inform ation, le code des program m es associé aux règles légales est entrelacé avec celui associé aux règles d ’affaires. Les changements apportés aux program mes deviennent des opérations coûteuses, voire risquées puisqu’elles entraînent la dégradation des systèmes [7, 48]. Ces changem ents interviennent d ’au tan t plus que les programmes auxquels ils s’appliquent sont issus de réglem entations qui sont sujettes à des modifications fréquentes. En effet, les lois sont définies par des instances qui les m ettent à jo u r suivant les besoins de la société, les avancées technologiques ou encore les changem ents de gouvernement. De même, les
In t r o d u c t i o n
politiques internes des entreprises sont influencées p ar les changem ents de direction à la tê te de celles-ci.
Un autre problème est l’inverse de celui décrit précédem m ent. En effet, il p e u t être requis pour des entreprises de prouver la conform ité de leurs systèmes d ’inform ation aux lois en vigueur. C ’est-à-dire que les systèmes d ’inform ation tra ite n t les données et respectent les niveaux d ’accès à l’inform ation prévus p ar les réglem entations. D ans les deux cas, une solution consiste en la form ulation des règles de contrôle d ’accès dans une notation particulière. C ette n otation se doit d ’avoir une sém antique formelle. C ette caractéristique de la notation offre des pistes de solutions intéressantes, entre autres, à ce dernier problème.
En pratique, dans l’industrie du logiciel, la solution d ’im plém entation privilégiée est le contrôle d ’accès basé sur les rôles (Role-Based Access C ontrol (RBAC) en anglais). C ette m éthode largem ent répandue a d ’ailleurs donné lieu à une norme [32]. L ’idée sous-jacente de cette technique est d ’associer les ressources dont on veut contrôler l’accès (cela p eut être des actions/fonctions du système, des données) à des rôles. Ces rôles perm ettent ainsi de définir des niveaux d ’accès pour des parties du système. Les utilisateurs sont donc ensuite liés aux rôles et la sém antique de cette liaison est q u ’ils ne pourront accéder q u ’aux ressources du systèm e rattachées à leurs rôles. Le système doit donc être pourvu de mécanismes nécessaires à la mise en œ uvre d ’une politique de contrôle d ’accès. Pour un systèm e d ’inform ation, la politique de contrôle d ’accès est l’ensemble des règles qui précisent les privilèges des utilisateurs pour l’ac cès aux ressources du système. Dans le cadre du contrôle d ’accès basé sur les rôles, la politique correspond, en plus des associations ab straites entre les ressources, les rôles et les utilisateurs, aux valeurs concrètes pour ces entités. RBAC a donné lieu à de nombreuses évolutions pour prendre en com pte de nouveaux besoins, notam m ent l’ajout de la séparation des devoirs, qui est une contrainte qui empêche q u ’un u ti lisateur d ’un système initie un processus et le valide. C ependant, RBAC ne dispose pas de constructions adaptées pour exprim er de façon native les contraintes de type séparation des devoirs, ou plus généralem ent des contraintes dynamiques ou statiques qui n ’entrent pas dans le schéma usuel des politiques RBAC. Une contrainte est consi
In t r o d u c t i o n
dérée comme dynamique lorsque son évaluation tient com pte, en plus de l’é ta t actuel du système, de l’historique d ’événements survenus dans le système. C ette faiblesse du pouvoir expressif de RBAC peut être comblée par l’utilisation d ’une n o tatio n basée sur les traces d ’actions. C ’est ce qui a été proposé dans le cadre des projets EB 3SEC et SELKIS.
Avec des politiques de contrôle d ’accès qui utilisent cette nouvelle notation, de nou veaux mécanismes de mise en œ uvre doivent être trouvés. Le travail de c ette thèse s’attaq u e donc à la problém atique de ces moyens de mise en œuvre, particulièrem ent dans le cas des applications ayant une architecture orientée services (Service O riented A rchitecture (SOA) en anglais). Ces mécanismes de mise en œ uvre vont se trad u ire dans la pratique par un cadre d ’applications qui com porte un filtre de contrôle d ’accès dynamique, composant indispensable pour m ettre en vigueur les politiques de contrôle d ’accès ayant des aspects dynamiques. Ce cadre d ’applications doit être dérivé, auto m atiquem ent a u ta n t que possible, de la politique de contrôle d ’accès. Bien q u ’obtenu de façon autom atique, un cadre d ’applications doit être viable et opérationnel pour le système d ’inform ation auquel il est destiné en production. L ’autom atisation dans ce cas doit assurer que le cadre d ’applications est conforme à to u te politique de contrôle d ’accès et exempt de défauts. C ette autom atisation vise aussi à simplifier la m ainte nance des programmes de mise en application des règles de sécurité.
O b jectifs
Le principal objectif de cette thèse est de valider l’approche globale proposée dans les projets EB3SEC et SELKIS qui s ’inscrivent dans le dom aine de la sécurité fonc tionnelle des systèmes d ’inform ation, plus particulièrem ent celui du contrôle d ’accès. En effet, cette approche consiste, d ’une p art, en l’utilisation de m éthodes formelles pour la spécification de politiques de contrôle d ’accès, et d ’autre p art, en l’implé- m entation correcte de ces politiques dans les applications cibles. La finalité de notre travail consiste à vérifier que les im plém entations des solutions proposées dans cette thèse sont réalisables et viables dans le contexte de systèmes d ’inform ation de type SOA. Cet objectif se décline en trois sous-objectifs précis.
In t r o d u c t i o n
Prem ièrem ent, il s’agit de définir un modèle générique qui spécifie les concepts nécessaires pour la mise en oeuvre du contrôle d ’accès dans les applications de type SOA. Ce modèle est représenté p ar un m étam odèle qui décrit les principaux concepts d ’un « Policy Enforcement M anager » (PEM ). C ette description doit com prendre, entre autres, une vue du fonctionnem ent de chacun des éléments d u m étamodèle, ainsi que leurs relations les uns p ar rap p o rt aux autres. Les instances de ce m éta modèle doivent pouvoir m ettre en œ uvre non pas une seule politique, mais plusieurs politiques de contrôle d ’accès de façon sim ultanée et flexible. En effet, dans le milieu de la santé p ar exemple, il arrive des situations d ’urgence pendant lesquelles les poli tiques usuelles des établissem ents de santé sont suspendues et des règles particulières s ’appliquent. Tout comme en cas d ’une catastrophe, les organisations impliquées dis posent de procédures d ’accès à l’inform ation qui sont différentes de celles utilisées en situation normale. Le m étam odèle doit prendre en com pte cette particularité. Il doit aussi clairement dégager les responsabilités de chaque composant. E n particulier, il doit perm ettre une séparation n ette entre l’application/les données contrôlées et les mécanismes de contrôle. C ette séparation doit être telle que les changements au niveau de l’application contrôlée entraînent peu ou pas — dans l’idéal — de modifications aux mécanismes de mise en œuvre du contrôle d ’accès. Une telle séparation doit aussi exister entre les com posants du PEM . En effet, la m odification d ’une politique de contrôle d ’accès ne doit pas entraîner des modifications profondes sur les composants du PEM.
Deuxièmement, il s ’agit d ’identifier et de réaliser de possibles im plém entations du PEM basées sur des technologies qui s’intégrent le m ieux à des applications SOA. Ces im plém entations doivent p erm ettre la gestion aisée de politiques de contrôle d ’accès. Elles doivent aussi requérir un m inimum d ’effort pour passer de l’étape de spécifica tion à l’étape de déploiement sans toutefois com prom ettre les perform ances du cadre d ’applications de contrôle d ’accès. Deux m éthodes d ’im plém entation ont été retenues, chacune avec ses propres avantages et inconvénients. Les politiques de contrôle d ’ac cès considérées sont exprimées avec des notations formelles, notam m ent la n otation « Algebraic S tate Transition Diagram » (ASTD) [21]. C ette notation graphique est dotée d ’une sém antique formelle. Ses éléments sont hérités des statech arts [30] et
In t r o d u c t i o n
sont fortem ent influencés p ar les opérateurs du langage d ’expressions de processus EB3 [24]. La première im plém entation visée considère la transform ation, la plus au tom atique possible, de politiques de contrôle d ’accès vers un composant autonom e dans le cadre d ’applications de contrôle d ’accès. La seconde im plém entation consiste en Y interprétation directe de politiques de contrôle d ’accès, c ’est-à-dire l’exécution de celles-ci p ar le PEM sans transform ation dans une représentation interm édiaire. Un composant particulier du PE M a la responsabilité d ’utiliser cette interp rétatio n pour effectuer la mise en œ uvre de politiques de contrôle d ’accès. Les deux im plém enta tions doivent perm ettre une réutilisation des règles qui composent les politiques de contrôle d ’accès.
Troisièmement, il s ’agit d ’évaluer, à p a rtir d ’une étu d e expérim entale, l’exactitude et la viabilité de chacune des m éthodes d ’im plém entation proposées dans un envi ronnem ent semblable à celui d ’un environnem ent de production en entreprise. C ette évaluation s’effectue à l’aide d ’un banc d ’essai. De plus, les im plém entations sont comparées l’une à l’autre. C ette com paraison se fait par la mise en opposition des résultats de tests de perform ance effectués pour les deux im plém entations sous des conditions similaires voire identiques.
M é th o d o lo g ie
La méthodologie adoptée pour s ’a tta q u er à notre problèm e com porte trois phases : conceptuelle, algorithm ique et expérim entale. D urant la phase conceptuelle, un cadre d ’applications pour le développement du contrôle d ’accès dans des applications SOA est élaboré. Il se dérive à p a rtir d ’un modèle générique qui définit tous les com posants nécessaires au contrôle d ’accès ainsi que leurs interactions, e t cela dans l’optique où les politiques de contrôle d ’accès peuvent être hiérarchiques. Ce modèle générique est décrit par un m étam odèle en utilisant la notatio n UML [41, 42], notam m ent à travers des diagrammes de classes et des diagram m es de séquences. UML est l’une des notations graphiques les plus utilisées en ingénierie du logiciel. Elle perm et non seulement d ’analyser et de concevoir des applications (orientées objet pour la plu p art), mais aussi de représenter des métam odèles de telles applications. Dans le cadre de
In t r o d u c t i o n
cette thèse, ce modèle générique est basé sur les concepts proposés p ar la norme d ’un langage XML défini par l’« O rganization for th e Advancement of S tructured Information Standards » (OASIS) 1 et nommé « eX tensible Access Control M arkup Language » (XACML) [39]. Ce langage perm et d ’exprim er des politiques de contrôle d ’accès. C ette norme propose aussi une architecture cadre p o u r la mise en oeuvre du contrôle d ’accès. Ce sont les principaux élém ents de cette architecture qui sont repris et constituent les pivots du modèle générique proposé. Ces principaux élém ents sont le « Policy Enforcem ent Point » (P E P ) et le « Policy Décision Point » (P D P ). Le P E P est le point focal du mécanisme de mise en œ uvre de politiques de contrôle d ’accès. Il reçoit les requêtes d ’accès aux ressources ou services d ’une application et, suivant les politiques en vigueur, autorise l’exécution de la requête. Le com posant P D P est responsable du calcul des décisions d ’autorisation pour les requêtes reçues au niveau du com posant P E P .
La phase algorithm ique, basée sur une instance du m étam odèle, donne une forme concrète au traitem en t effectué p ar le filtre de contrôle d ’accès dynamique, un des composants du métamodèle. Les données d ’entrée à ce traitem en t sont des politiques de contrôle d ’accès exprimées à l’aide de la n o tatio n formelle ASTD, car leur mise en application dans le cadre du métam odèle se fait à travers le filtre de contrôle d ’accès dynam ique qui calcule au niveau de granularité le plus fin, pour une requête donnée, une décision d ’autorisation. Deux m éthodes sont examinées to u r à tour.
D ’abord le mécanisme de la transform ation est détaillé sous la forme d ’un algo rithm e qui tra d u it des politiques de contrôle d ’accès exprimées en ASTD en un en semble de processus écrits dans le langage B PE L [40] et qui s’exécutent dans un m oteur d ’exécution BPEL, une au tre norme de l’OASIS. Il s ’agit là aussi d ’un lan gage XML pour l’im plém entation de processus qui vont interagir avec leur environne ment par le mécanisme de services Web. La transform ation proposée prend la forme d ’un algorithm e qui m et en correspondance les élém ents de la notation ASTD et des constructions du langage BPEL. Les lim itations de cet algorithme sont considérées, et en particulier les restrictions sur les politiques de contrôle d ’accès acceptées p ar
1. Site Web de OASIS : www.oasis-open.org/org
In t r o d u c t i o n
l’algorithm e ainsi que des pistes de solutions de contournem ent sont envisagées. L ’al gorithm e génère aussi des docum ents auxiliaires selon les form ats « Web Service Défi nition Language » (W SDL) 2 et « XML Schéma D ocum ent » (XSD) 34 qui contiennent respectivem ent la définition des interfaces et la déclaration des types nécessaires au bon fonctionnement des processus BPEL.
Ensuite, Y interprétation est utilisée pour im plém enter une autre approche du filtre de contrôle d ’accès dynamique. A cet égard, l’é ta t initial d ’une politique de contrôle d ’accès, toujours exprimée avec la notation ASTD, est calculé. Cet é ta t évolue en suite en fonction des requêtes, aux ressources contrôlées, acceptées par la spécification. Dans ce cas de figure, une requête est vue comme une action de l’environnem ent et la décision d ’autorisation rendue est positive si la requête est acceptée dans l’é ta t courant de la spécification. L ’interpréteur est composé d ’un ensemble de processus BPEL et de quelques docum ents XML tels q u ’un docum ent d ’interfaces W SDL, un docum ent de types XSD et des docum ents en form at « Extensible Stylesheet Lan guage Transform ation » (XSLT) 5. Il comprend notam m ent un processus B PEL pour chaque type de structure ASTD et chacun de ces processus, en tan t que service, offre les opérations E x é c u t é , I s F inal et IS. L’opération E x é c u t é calcule un nouvel état pour une spécification, un é ta t et une requête reçus en param ètres. L’opération
IsFinal déterm ine si l’é ta t d ’une spécification est final et l’opération IS « initial
state » calcule l’é ta t initial d ’une spécification ASTD. Les docum ents XSLT réalisent des calculs sur des données XML q u ’il n ’est pas possible d ’effectuer directem ent avec les éléments du langage BPEL, essentiellement à cause des limites de celui-ci.
Enfin, la phase expérim entale compare les deux m éthodes d ’im plém entation du filtre de contrôle d ’accès dynamique. À cet égard, les deux solutions retenues du filtre sont développées et déployées dans le m oteur d ’exécution « O rchestration D irector Engine » (ODE) 6. Ce m oteur d ’exécution est un projet de la fondation Apache du
2. Standard WSDL du W 3C: w w w .w 3.org/T R /w sdl
3. Structures de données de la norme X SD : w w w .w 3.org/T R /xm lschem a-l 4. Types de données de la norme XSD : w w w .w 3.org/T R /xm lschem a-2 5. Standard XSLT du W 3C : w w w .w 3.org/T R /xslt
6. Site Web du moteur ODE : ode.apache.org
In t r o d u c t i o n
logiciel (Apache Software Foundation en a n g lais)7. Il p e u t être aisément installé dans un conteneur d ’applications tel que Apache T o m c a t8. Le déploiement des proces sus B PEL se fait à chaud — sans redém arrage de l ’application Web ODE ou du conteneur Tom cat — par une simple copie de fichiers et nécessite uniquem ent une déclaration des processus (puisqu’ils sont exposés comme des services Web) dans un fichier XML. Deux types de test sont effectués pour chacun des filtres déployés dans ODE. Les tests de fonctionnalité valident les im plém entations de ces filtres tan d is que les tests de performance donnent une vue précise du com portem ent de celles-ci sous certaines conditions. D urant ces tests, des m étriques relatives aux tem ps d ’exécution et à la taille des données échangées sont évaluées. Les valeurs de ces m étriques sont interprétées pour com parer les im plém entations de façon objective.
C o n trib u tio n s
Les résultats de notre thèse s ’inscrivent dans le cadre des projets E B 3SEC et SELKIS sous deux hypothèses principales. La prem ière soutient que la spécification des politiques de contrôle d ’accès aux ressources d ’u n système d ’inform ation dans un langage d ’expressions de processus comme ASTD contribue à pallier les faiblesses des m éthodes actuelles dans ce domaine. La seconde prétend q u ’une séparation n ette entre le système d ’inform ation et les mécanismes de contrôle d ’accès constitue une solution qui facilite la m aintenance des systèmes d ’inform ation par ra p p o rt à leurs politiques de contrôle d ’accès, réduisant ainsi l’entropie de ces systèmes. Une telle so lution est aussi viable non seulement dans l’écriture de politiques de contrôle d ’accès, mais aussi dans leur déploiement, leur exécution et leur maintenance.
Deux solutions originales de filtre de contrôle d ’accès dynamique constituent l ’ap po rt principal de cette thèse. Bien que les deux solutions suggèrent d ’im plém enter un filtre de contrôle d ’accès dynam ique avec un ensemble de processus B PE L , elles diffèrent p ar les m éthodes utilisées : la transform ation de spécifications ASTD et l’interprétation de spécifications ASTD. Dans le prem ier cas, comme il n ’a pas été
7. Site Web de la fondation Apache : apache.org
8. Site Web du conteneur d ’applications Tomcat : tom cat.apache.org
In t r o d u c t i o n
possible d ’associer tous les éléments syntaxiques de la n o tatio n ASTD à ceux du lan gage B PEL à cause des lim itations de ce langage, q u atre patrons de politiques de contrôle d ’accès ont été considérés. Bien que cette restriction puisse p ara ître sévère, les quatre patrons retenus perm ettent d ’exprim er les contraintes d ’accès usuellem ent rencontrées dans la pratique. La solution proposée est complète p ar ra p p o rt à ces patrons. Elle inclut aussi la génération de docum ents auxiliaires nécessaires au bon fonctionnement des processus BPEL. Dans le second cas, un processus B PEL, avec ses docum ents auxiliaires, est associé à chaque type de structures ASTD. Un proces sus B PEL perm et donc l’interprétation de to u te stru ctu re du type correspondant. Au to tal douze processus B PEL ont été ainsi développés afin de constituer une machine virtuelle complète d ’exécution de spécifications ASTD.
Un au tre apport de cette thèse est la définition d ’un modèle générique d ’un gestion naire d ’exécution de politiques de contrôle d ’accès ou PEM qui, une fois instancié, a permis de bien situer le contexte dans lequel les deux solutions de filtre de contrôle d ’accès dynamique ont été élaborées, celui d ’applications dont l ’architecture est orien tée services. Ainsi, dans ce contexte, le filtre de contrôle d ’accès dynam ique est vu comme un service, to u t comme les processus B PEL qui le composent, et cela dans les deux m éthodes retenues. Une des caractéristiques de ce modèle est q u ’il est suffisam m ent général pour servir de base à d ’autres cadres d ’applications différents de celui proposé dans cette thèse, à savoir les applications de type SOA.
Le dernier ap po rt de cette thèse est un banc d ’essai complet qui perm et de corrobo rer dans une certaine mesure les hypothèses de départ. Il com porte l’im plém entation de deux prototypes, un pour chaque solution du filtre de contrôle d ’accès dynam ique. Il inclut aussi un ensemble exhaustif de jeux d ’essai de différentes grandeurs et de nombreux scripts qui perm ettent le déploiement de chaque solution, l ’exécution de jeux d ’essai et la génération autom atique de tableaux ou graphiques en form at Latex à p artir des statistiques recueillies. Les conclusions tirées, ainsi que les statistiq u es obtenues, de cette étude expérim entale constituent des résultats intéressants, puis q u ’elles pourront servir à évaluer la pertinence d ’approches similaires considérant les limites actuelles des technologies Web, en particulier B PEL, et des m éthodes formelles dans la mise en œ uvre de solutions logicielles.
In t r o d u c t i o n
O rgan isation de la th è se
Le reste de la thèse est organisé comme suit. Le chapitre 1 présente les notions nécessaires à la lecture de cette thèse. E ntre autres, la n o tatio n ASTD, les systèmes d ’inform ation dans un environnement SOA et le langage B PEL sont abordés. Le cha p itre 2 décrit les différentes techniques de contrôle d ’accès utilisées dans le contexte des systèmes d ’information. Le chapitre 3 situe notre solution par rap p o rt aux travaux du domaine. Le chapitre 4 introduit le modèle générique qui détaille les com posants de l ’architecture d ’un PEM dans le cas de systèm es d ’inform ation de type SOA. Le chapitre 5 donne les détails sur l’im plém entation d ’un PEM qui m et en œ uvre des politiques de contrôle d ’accès formelles. Il présente l’essence d ’un algorithm e de tra n s form ation de politiques de contrôle d ’accès. Le chapitre 6 présente un filtre de contrôle d ’accès dynam ique qui fait usage de l ’in terp rétation de spécifications formelles. E n fin, le chapitre 7 décrit les prototypes de filtre de contrôle d ’accès dynam ique réalisés à p a rtir des algorithmes des deux chapitres précédents. Des mesures effectuées pen dant leur exécution sont aussi détaillées et commentées. Une conclusion term ine cette thèse.
C h a p itre 1
C o n cep ts d e b a se
La revue des éléments nécessaires à la compréhension de cette thèse inclut une description de la notation formelle ASTD utilisée pour spécifier des politiques de contrôle d ’accès, les applications SOA comme architecture des systèmes d ’inform ation, le protocole « Simple Object Access Protocol » (SOAP) pour les échanges de messages entre les services Web, le langage « Web Service Définition Language » (WSDL) pour spécifier les interfaces des processus et le langage de processus « Business Process Execution Language » (BPEL) pour l ’im plém entation des solutions proposées dans cette thèse.
1.1
Le lan gage A S T D
Le langage ASTD [23] est une notatio n formelle qui combine une représentation gra phique et les opérateurs des notations telles que CSP [31] et LOTOS [8]. La définition complète des structures ASTD, incluant la représentation m athém atique et graphique des structures et des é tats ASTD ainsi que la sém antique formelle, est disponible dans le rap p o rt [21]. Une spécification ASTD est un ensemble fini de structures ASTD dont l’une, nommée m ain, est marquée comme la stru ctu re ASTD principale. L’exécution d ’une spécification ASTD est intuitive. L 'éta t initial de la stru ctu re ASTD principale est calculé et les événements reçus de l’environnem ent font évoluer l’é ta t courant de la
1.1. L e l a n g a g e A S T D
A U T 1 , a u t | A U T 1 , a u t
< § )
-(a) Structure autom ate (b) É tats successifs de l ’autom ate
Figure 1.1 - Exemple d ’une stru cture ASTD automate
spécification vers un nouvel é ta t en fonction de la spécification elle-même (l’ensemble des structures ASTD qui la composent). Il existe neuf stru ctu res ASTD.
Une stru ctu re ASTD p eu t être de ty p e automate (aut). D ans ce cas, l’autom ate contient des structures élémentaires ou encore d ’autres structu res A STD qui sont liées p ar des transitions t(~x)[^], où t est l’événement ou l’action, ~x est l’ensemble des param ètres de l’événement et 0 est un prédicat optionnel qui doit être évalué à vrai pour déclencher la transition. Une stru ctu re ASTD autom ate est, dans sa ver sion simplifiée, un système d ’états-transitions avec la possibilité de p aram étrer les transitions p ar des variables et d ’ajo u ter des conditions d ’exécution à celles-ci. La figure 1.1a illustre une stru ctu re A STD autom ate nommée A U T 1 . Elle a deux tran si tions sans param ètres t\ et t 2 qui doivent être exécutées en séquence. La figure 1.1b m ontre l’évolution de l’é ta t de cette stru ctu re ASTD depuis l’état initial après les occurrences des événements ti et t 2. L’é ta t initial de la stru c tu re ASTD autom ate de l’exemple est q0 comme le m ontre le je to n présent dans cet é ta t dans la p artie gauche de la figure 1.1b. D ’après la spécification à la figure 1.1a, seule la transitio n t\ est possible dans cet é tat. Après l’occurrence de l’événement il y a u n changem ent d ’é ta t de qo à q\ comme le m ontre le jeto n dans l’é ta t q\ (voir la p artie m édiane de la figure 1.1b). De même, après l ’occurrence de l’événement t 2, l’é ta t courant de la stru ctu re ASTD automate passe de l’é ta t q\ à l’é ta t q2 et le je to n se retrouve dans ce dernier é ta t comme l’illustre la partie droite de la figure 1.1b.
Une stru ctu re ASTD séquence (<£>) perm et l’exécution l’une après l’au tre de deux structures ASTD qui en sont membres. L’é ta t de la stru ctu re ASTD séquence est celui de la structure en cours d ’exécution. Q uant cet é ta t est celui de la prem ière
sous-1.1. L e l a n g a g e A S T D S E Q 1 , ❖ A U T 1 , a u t | AUT 2, au t | -N -V A U T l, au t A U T 2 , a u t |
<•)
J -®
—®
(a) Structure séquence (b) É tats successifs de la séquence
Figure 1.2 - Exemple d ’une stru ctu re ASTD séquence
structure, le passage à l’é ta t initial de la seconde sous-structure est possible si l’état de la première sous-structure est final. Dans l ’exemple présenté par la figure 1.2a, la stru ctu re ASTD principale est la séquence S E Q 1 et elle com porte deux sous-structures ASTD automate qui seront exécutées en séquence. La figure 1.2b illustre l’évolution de l’é ta t de la stru ctu re ASTD séquence depuis son é ta t initial ju sq u ’à son é ta t final. C ette évolution se fait à la suite des occurrences successives des événements ti et £2
-Une stru ctu re ASTD choix (|) perm et l’exécution au choix d ’une stru ctu re parm i plusieurs sous-structures ASTD membres. Une telle stru ctu re ASTD offre la possibi lité d ’exécuter les transitions de toutes les sous-structures et, une fois le choix de la sous-structure à exécuter effectué, les autres sous-structures sont ignorées lors d ’oc currences futures d ’événements. Le choix de la sous-structure est déterm iné p ar la première occurrence d ’un événement acceptable.
Une stru ctu re ASTD ferm eture de Kleene (*) spécifie l’exécution répétitive de sa sous-structure ASTD. Son é ta t est celui de la sous-structure. Pour que l’exécution puisse rep artir depuis son é ta t initial, il fau t que l’é ta t courant soit final.
Une structure ASTD garde (=>) est composée d ’une sous-structure ASTD et d ’un prédicat. Ce dernier doit être évalué à vrai po u r que la sous-structure puisse s’exécuter.
La stru ctu re ASTD appel ({)) est l ’équivalent de l’appel d ’u ne fonction d ’un langage de program m ation. E n effet, celle-ci perm et d ’exécuter une stru cture ASTD définie dans la spécification englobante, en lui passant les param ètres requis.
1.1. L e l a n g a g e A S T D
0. . *
B o o k L e n d M e m b e r
Figure 1.3 - Diagramme de classes d ’un systèm e d ’inform ation
Une stru ctu re ASTD synchronisation paramétrée (| [{•••}] |) perm et l ’exécution de plusieurs sous-structures ASTD to u t en synchronisant cette exécution su r les événe m ents spécifiés dans un ensemble d ’événements synchrones A . C ette stru c tu re a une version quantifiée (| [{•••}] | x : T ) qui com porte une unique sous-structure ASTD, c’est-à-dire qu ’elle perm et d ’exécuter, en parallèle ou de m anière entrelacée (||| x : T), la sous-structure pour différentes valeurs de la variable de quantification.
La dernière stru ctu re ASTD est le choix quantifié (j x : T ) qui p erm et l ’exécution de la sous-structure pour une unique valeur de la variable de quantification (d ’où l’appellation choix quantifié).
La m éthode de spécification ASTD, qui inclut le langage ASTD, a été proposée dans la perspective d ’être utilisée pour modéliser des systèmes d ’inform ation. La spé cification complète d ’un système com prend en plus de la description des ASTD, un modèle UML des entités du système et la définition des attributs de ces entités. Dans cet ensemble de modèles, la spécification ASTD vient préciser le com portem ent des différentes entités du système et chaque tran sitio n de la spécification modifie éven tuellem ent des a ttrib u ts de ces entités. Le diagram m e de classes de la figure 1.3 montre la relation entre les entités B o o k et M e m b e r du systèm e d ’inform ation d ’une bibliothèque. Pour modéliser le com portem ent du processus de prêt de livres de cette bibliothèque, on peu t lui ajouter la spécification ASTD de la figure 1.4. La stru ctu re ASTD automate de la figure 1.4b m ontre le com portem ent des instances de l’entité
B o o k : un livre est acquis (événement Acquire), ensuite il p eut être em prunté un
certain nombre de fois (structure ASTD l o a n ) et enfin il est retiré de la bibliothèque (événement Discard). La spécification ASTD automate de la figure 1.4d modélise le cycle d ’un prêt. Celui-ci débute p ar l ’em prunt d ’un livre p a r u n membre (événement
Lend). Le prêt p eut être ensuite renouvelé un certain nom bre de fois (événement
