1.2 Sécurité des Web-Services
1.2.2 Protection des Web Services et du contenu des messages
John Viega et Jeremy Epstein ([VE06]) montrent que l’application des stan- dards de sécurité n’est pas suffisant. L’ensemble de ces mécanismes en ne contro- lant que l’accès aux services ne permet pas de contrôler les messages échangés. Du fait de ces limitations de nombreuses attaques sont possibles contre les Web Ser- vicesen particulier lorsque n’importe quel utilisateur peut s’enregistrer afin d’utili- ser un service. Le lecteur intéressé trouvera une description de différentes attaques possibles contre les Web Services dans [VE06, JGHL07, MH06].
Ces attaques peuvent être le fruit de failles dans les standards de sécurité. Ainsi les auteurs de [BFG04] proposent une sémantique formelle de WS-SecurityPolicy permettant ainsi de vérifier la cohérence des politiques produites avec cette spé- cification. Les auteurs de [BFG05] se sont intéressés à la spécification et à la vé- rification de protocoles cryptographiques pour XML, en particulier ceux utilisés par WS-Security. Cependant le plus souvent ces attaques sont dues à une mau- vaise utilisation des standards de sécurité. Ainsi les auteurs de [BFGO05] ont construit un outil permettant de rechercher les vulnérabilités dans une architec- ture de Web-Services dont la sécurité est spécifiée à l’aide de WS-SecurityPolicy et de proposer le cas échéant des solutions permettant de palier ces vulnérabilités. Afin de faciliter la mise en place de WS-Security, les auteurs de [YCTU07] pro- posent une API facilitant l’utilisation de WS-Security par les programmeurs. Les auteurs de [SY07] proposent quant à eux un framework permettant de transformer des politiques WS-SecurityPolicy en spécification WS-Security. Enfin, les auteurs de [GJD07] proposent une passerelle implémentant les spécifications WS-Security, permettant ainsi de découpler les mécanismes de sécurité de l’implémentation des services.
Ainsi de nombreux travaux ont cherché à compléter les standards de sécurité des Web Services. Cependant, ces standards n’ont pas été prévus pour fonctionner directement avec les orchestrations de service. C’est pourquoi des travaux ont cher- ché à étendre les fonctionnalités de sécurité aux orchestrations de service et plus particulièrement aux problèmes de sécurité liés aux orchestrations faisant interve- nir plusieurs entités différentes.
Ainsi les auteurs de [CFH05] proposent une approche permettant de concilier les exigences de sécurité des utilisateurs et fournisseurs de service. Ils définissent un langage permettant de spécifier ces exigences, en particulier en matière du choix des algorithmes de chiffrement ou de signature. Ces définitions permettent ensuite de construire des programmes BPEL respectant l’ensemble de ces contraintes. Les auteurs de [FMS07] proposent le même type d’approche, mais en exprimant direc-
1.3 Bilan 15
tement ces contraintes dans les programmes BPEL à l’aide d’un langage spécifique appelé Secure BPEL. Les auteurs de [BDF06] proposent une approche formelle de ce problème en considérant un λ-calcul enrichi permettant de décrire des or- chestrations de services. Une analyse statique permet ensuite de vérifier que les orchestrations répondent à ces exigences.
Ces travaux permettent d’assurer la protection des messages échangés par les Web Servicesen respectant les exigences des différentes parties en matière de confi- dentialité et d’intégrité. Cependant ces travaux de permettent pas de protéger les données au cours d’une orchestration de services lorsque celle-ci implique plu- sieurs partenaires. Ainsi par exemple au cours d’une vente en ligne rien ne permet de garantir que les coordonnées bancaires d’un client ne soient transmises qu’à la banque. C’est pourquoi les auteurs de [SP07] et de [JG09] proposent d’encapsu- ler des flux chiffrés à l’aide de WS-Security dans des programmes BPEL. Cette solution basée sur l’emploi de chiffrement symétrique ne permet néanmoins pas de gérer plusieurs destinataires différents pour une information donnée. Afin de permettre de multiples destinataires à une information les auteurs de [MJS11] en- codent chaque donnée à protéger à l’aide d’une clé symétrique. Ils utilisent ensuite le chiffrement asymétrique afin de chiffrer cette clé avec la clé publique de chaque destinataire de l’information. La clé de chiffrement est donc dans ce cas envoyée chiffrée avec l’information.
1.3 Bilan
Les travaux présentés permettent de répondre ponctuellement à des problèmes de confidentialité et d’intégrité en se basant sur les spécifications standard des Web Services. Ils permettent ainsi de protéger les communications entre différents Web Serviceset de protéger la confidentialité des informations lorsque plusieurs entités sont impliquées. Cependant ces travaux seraient incomplets sans une politique de sécurité dédiée aux problématiques de sécurité des Web Services. C’est pourquoi dans le chapitre suivant nous présenterons les modèles classiques de politique de sécurité, leur adaptation aux architectures orientées services, ainsi que les modèles de politique de sécurité développés afin de répondre aux problématiques particu- lières des SOA.
Chapitre 2
Politique de sécurité pour les
architectures orientées services
Nous avons montré dans le chapitre précédent que les standards de sécurité développés pour les Web-Services permettaient de protéger l’intégrité et la confi- dentialité des messages échangés. Cependant ces travaux ne se sont pas intéressés à la mise en place de politiques de sécurité dédiées aux architectures orientées ser- vices.
Dans le cadre de ce chapitre nous nous intéressons à la mise en place du contrôle d’accès dans les architectures orientées services. De nombreux modèles de contrôle d’accès ont été proposés. Les modèles traditionnels de sécurité peuvent être classés en deux grandes familles, les modèles d’accès discrétionnaires (DAC - Discretionary Access Control) et les modèles d’accès obligatoires (MAC - Manda- tory Access Control). La section 2.1 présente l’utilisation de ces modèles dans les architectures orientées services. Plus récemment d’autres modèles plus flexibles ont été définis comme le modèle RBAC (Role-Based Access Control). Celui-ci est présenté dans la section 2.2. Enfin, dans la section 2.3, nous présentons des mo- dèles de contrôle d’accès spécifiquement étudiés pour les architectures orientées services.