these doctorat une architecture de securité

Chapitre 3. Étude d’intergiciels sécurisés pour le calcul distribué
tel-00239252, version 1 - 5 Feb 2008
FIG. 3.13 – Architecture .Net Remoting avec gestion transparente de la sécurité
En conclusion, la modularité de la plateforme permet notamment d’utiliser des mécanismes
d’authentification personnalisé qui authentifieraient automatiquement l’utilisateur de la partie
cliente lors d’invocations sur le serveur. Cependant, même si cette solution apporte assez de
souplesse pour intégrer notre vision d’une architecture sécurisée transparente, elle impose notamment
la création de fichiers de configuration spécifiques ainsi que l’implantation de diverses
classes représentant les divers MessageSinks. On peut regretter que des classes génériques fournissant
les fonctions de base de la sécurité (authentification des utilisateurs, intégrité, confidentialité
des messages) ne soient pas fournir de base avec le CLR.
3.6 Bilan
Dans ce chapitre, nous avons évalué les services de sécurité présents au sein d’un panel significatif
d’intergiciels orientés applications distribuées dont Legion, Globus (OGSA), CORBA, la
plateforme .NET et la spécification EJB. Le tableau 3.2 résume les caractéristiques de chaque
intergiciel.
Cette étude a permis de mettre en valeur les approches et solutions proposées par chacun
d’entre eux. Bien qu’ils n’adressent pas de la même façon les problèmes liés à la sécurité, ils
permettent tous de mettre en place des applications sécurisées. Cependant, dans le contexte
qui nous intéresse, à savoir le niveau de transparence des mécanismes de sécurité vis-à-vis du
code source de l’application, tous ces intergiciels ne fournissent pas nativement les mécanismes
nécessaires permettant sa mise en œuvre.
En effet, ces intergiciels se veulent les plus génériques possible afin de répondre aux attentes
de la majorité des développeurs. Pour cela, ils intègrent le plus grand nombre de technologies
relatives aux concepts de sécurité : cryptosystèmes à clés symétriques ou asymétriques, gestion
des certificats (PKI), algorithme de hachages, . . . . Ces algorithmes et protocoles sont certes prouvés
et vérifiés cependant ils n’ont pas été conçus pour supporter la dynamicité requise par les
applications distribuées (création d’objets distants, changement de politiques de sécurité suite à
la migration d’une activité, négociation dynamique de politique de sécurité, ...). Cette tâche est
laissée au programmeur qui doit gérer par lui-même la distribution des clés, la définition de la
politique de sécurité de chaque entité en présence, . . . .
De plus, l’intégration de ces protocoles au sein du code source des applications fige en quelque
46