these doctorat une architecture de securité

Chapitre 6. Implantation dans ProActive : une approche transparente
méro du dernier point de reprise. Cette approche suppose la présence d’un support de stockage
stable accessible par tous les objets de l’application. Ce support est présent sous la forme d’ un
serveur qui centralise les points de reprise des divers objets de l’application : le serveur de checkpoint
(figure 6.11). Il reçoit les informations en provenance de tous les objets actifs de l’application
qu’il surveille et a la charge de redémarrer les objets actifs en panne dans leur dernier état stable
connu si un problème survient lors de l’exécution.
tel-00239252, version 1 - 5 Feb 2008
FIG. 6.11 – Tolérance aux pannes et sécurité
Nous allons maintenant étudier la réaction du protocole de tolérance face à une panne franche
et les implications vis-à-vis du mécanisme de sécurité.
Dans un premier temps, intéressons nous aux communications existantes. Les objets actifs
doivent envoyer une image de leur état au serveur de checkpoint. Dans le cas où ce serveur est
un objet actif, cette communication se résume à un appel de méthode depuis un objet actif vers un
autre. Nous avons déjà vu que le mécanisme de sécurité est capable d’intercepter et d’appliquer
les attributs de sécurité nécessaires à une telle communication. La sécurisation des communications
entre un objet actif et son serveur de checkpoint se fait de manière transparente. Le serveur
de checkpoint reçoit les images et les stocke sans avoir conscience du protocole de sécurité sousjacent.
Lors d’une panne, le serveur de checkpoint doit redémarrer l’application (tous les objets) au
dernier état stable connu, y compris l’objet actif en panne. Son redémarrage se fera sur un nœud
différent de son nœud initial. La création des objets actifs est dépendante de l’autorisation que
possède le serveur de checkpoint vis-à-vis de la création d’un objet actif sur le nœud de secours.
Comme dans le cas de la création d’un objet actif par un autre, cette autorisation est tributaire
d’une part des politiques de sécurité des entités contenant le serveur et de celle du serveur et,
d’autre part, des politiques de sécurité des entités contenant le nœud cible ainsi que la politique
de ce dernier. De plus, le transfert de l’image se fera de manière sécurisée comme n’importe quelle
création d’objet actif sur un runtime distant.
La deuxième étape lors du redémarrage d’un objet actif consiste à ré-émettre un certain
nombre de messages (requêtes et réponses) émis avant la panne et désignés comme devant être
réémis par le protocole de tolérance aux pannes. Ces messages sont conservés de manière non
chiffrée au sein de l’image de l’objet actif. Au moment de leur ré-émission, ces messages le seront
selon la politique de sécurité de l’objet actif et des entités englobantes en fonction de sa nouvelle
localisation et de la nouvelle localisation de l’objet cible dans le cas où il aurait été redémarré sur
un autre nœud que son nœud initial.
L’analyse de ce scénario de redémarrage de l’application utilisant à la fois le protocole de tolérance
aux pannes et l’architecture de sécurité montre qu’il est possible de combiner ces deux
fonctionnalités. Il est néanmoins nécessaire de donner au serveur de checkpoint les droits et au-
116