these doctorat une architecture de securité

Chapitre 5. Une architecture de sécurité de haut niveau
– ces modifications ne garantissent pas directement la correction du code de sécurité ajouté,
ni celle de la politique de sécurité de l’application qui en résulte ;
– les besoins de l’application en termes de sécurité seront exprimés au sein du code de l’application
et paramétrables seulement en modifiant le code source ;
– ce code devra être répliqué pour chaque application ayant les mêmes besoins.
La présentation de la librairie ProActive nous a permis de mettre en évidence les avantages d’implanter
au sein de la librairie, le code de gestion de réservation et d’accès au ressources, la gestion
des divers protocoles de communications, de migration, . . . .
Le premier but de cette thèse est de fournir un modèle de sécurité capable de gérer les vulnérabilités
inhérentes aux applications distribuées selon les postulats énoncés précédemment.
Afin de faciliter son utilisation, ce modèle doit être transparent au code métier de l’application,
configurable en dehors de celui-ci.
tel-00239252, version 1 - 5 Feb 2008
Le deuxième postulat concerne la confiance du code du niveau méta de la bibliothèque. On
supposera que ce code n’effectuera pas d’actions invalidant la politique de sécurité de l’application.
Ce code évoluant au même niveau que le code gérant la sécurité, il lui serait possible
d’outrepasser ses droits et d’effectuer des actions contraires à la politique de sécurité. On se
place ici dans la même hypothèse que celle faîte par le standard EJB.
Lors du développement d’une application capable d’utiliser une grille de calcul, le développeur
ne connaît pas la façon dont un utilisateur va déployer cette application. Il ne peut faire que des
suppositions et donc il lui est difficile de coder le comportement en terme de sécurité de l’application.
En effet, l’utilisateur peut aussi bien déployer l’application sur une seule machine d’une
grappe de calcul, sur l’ensemble des machines de cette même grappe ou alors sur un ensemble
de grappes de calcul (grille de calcul). Les besoins en terme de sécurité vont ainsi varier selon le
déploiement de l’application. Par exemple, nous pouvons supposer que, lors d’un déploiement au
sein d’une même grappe de calcul, seule l’authentification entre les diverses parties de l’application
est nécessaire. Si cette même application utilise plusieurs grappes de calcul interconnectées
par un réseau public, alors il est possible de vouloir simplement de l’authentification entre les
nœuds d’une même grappe mais que lors de communications inter-grappes, la confidentialité et
l’intégrité doivent être rajoutées.
Le deuxième but de cette thèse est ainsi de fournir un moyen à l’utilisateur de pouvoir configurer
la sécurité de l’application selon le déploiement de cette dernière.
Finalement, les applications distribuées utilisant des grilles de calcul peuvent, au cours de
leur exécution, acquérir dynamiquement de nouvelles ressources afin de s’y déployer pour augmenter
la puissance de calcul à leur disposition. Cependant cette dynamicité ne doit pas compromettre
la sécurité.
Le troisième but de cette thèse est d’intégrer cette notion de dynamicité des applications
distribuées au sein du modèle de sécurité proposé afin de ne pas limiter la dynamicité de ce type
d’applications. Cela impose de garantir la politique de sécurité de l’application tout au long de
son exécution.
5.2 Un modèle de sécurité générique et hiérarchique
Le chapitre précédent nous a permis de décrire la bibliothèque ProActive et nous avons vu
comment une application java s’exécute lorsque qu’elle est liée à la bibliothèque. À ce point, aucune
notion de sécurité n’a été prise en compte.
Selon le principe du contrôle d’accès présenté dans la section 2.3, il faut, pour que le moniteur
de référence puisse prendre une décision, pouvoir authentifier les deux parties en présence lors
d’une interaction.
66