these doctorat une architecture de securité

Section 6.6. Tolérance aux pannes et sécurité
fin
tel-00239252, version 1 - 5 Feb 2008
Chaque worker est inclus dans un nœud appartenant au nœud virtuel WorkerVN.
– Seuls les Workers ayant le même certificat d’application que les TasksServers pourront
télécharger des tâches et déposer des résultats.
Au démarrage, un Worker sécurisé va commencer par créer deux autres Workers. Grâce au mécanisme
implicite de propagation dynamique du contexte de sécurité, chacun des deux nouveaux
Workers aura un gestionnaire de sécurité qui contiendra la politique de sécurité de l’application
ainsi qu’un certificat dérivé du certificat d’application. Ils disposeront ainsi des mêmes possibilités
(création de nouveaux Workers et téléchargement des tâches) que leur parent. Les avantages
de cette approche décentralisée sont doubles :
– Elle permet une croissance exponentielle du nombre de Workers,
– mais surtout de distribuer efficacement le coût de la génération des certificats sur tous les
Workers.
L’utilisation de l’architecture pair-à-pair a permis de tester notre mécanisme de sécurité sur
un système dont la gestion de la sécurité peut être considérée comme décentralisée et dynamique.
Les exemples nous ont permis de montrer les réactions du mécanisme de propagation
dynamique du contexte de sécurité couplé avec la combinaison des politiques de sécurité au sein
d’un environnement pair-à-pair. L’analyse des divers cas survenant lors de l’utilisation du système
pair-à-pair montre que notre modèle de sécurité peut être utilisé dans un environnement
dynamique.
6.6 Tolérance aux pannes et sécurité
L’ensemble des diverses ressources utilisables par une application utilisant la bibliothèque
est vaste. Il est possible de déployer une application sur une machine multiprocesseur, sur des
grilles de calcul ou encore sur des réseaux ad-hoc créés à partir d’ordinateurs de bureau. Toutes
ces ressources ne disposent pas des mêmes taux de fiabilité. Ainsi, il est plus probable de voir
disparaître un ordinateur de bureau suite à son redémarrage par son utilisateur principal pour
une raison donnée ou sa déconnexion du réseau que de perdre une machine appartenant à une
grille de calcul pour ces mêmes raisons. Ainsi, du fait de la nature volatile des ressources, une application
peut perdre une partie d’elle même et de ses données suite à l’extinction d’une machine
donnée. Dans ce contexte, l’utilisation d’un protocole de tolérance aux pannes se révèle plus que
nécessaire afin de palier à la volatilité des ressources et de permettre de minimiser l’impact de
la perte d’une partie de l’application sur le temps de calcul global de l’application.
Il est intéressant de noter qu’il n’existe pas qu’un seul type de panne mais plusieurs ; elles
sont classées en quatre catégories majeures [70] que nous présentons brièvement :
– les pannes franches (crash, fail-stop), que l’on appelle aussi arrêt sur défaillance. C’est le cas
le plus simple : on considère qu’un processus peut être dans deux états, soit il fonctionne et
donne le résultat correct, soit il ne fait rien. Il s’agit du type de panne actuellement supporté
par le mécanisme de tolérance aux pannes de ProActive ;
– les pannes par omission (transient, omission failures). Dans ce cas, on considère que le
système peut perdre des messages. Ce modèle peut servir à représenter des défaillances du
réseau plutôt que des processus ;
– les pannes de temporisation (timing, performance failures). Ce sont les comportements
anormaux par rapport à un temps, comme par exemple l’expiration d’un délai de garde ;
– les pannes arbitraires, ou byzantines (malicious, byzantine failures). Cette classe représente
toutes les autres pannes : le processus peut alors faire “n’importe quoi”, y compris
avoir un comportement malveillant.
Le protocole de tolérance aux pannes intégré dans la bibliothèque se classe parmi les protocoles
de points de reprise induits par message, avec reprise asynchrone [11]. Son fonctionnement
est le suivant : chaque objet actif prend périodiquement un point de reprise. Ce point de reprise
est numéroté dans l’ordre croissant. Chaque message émis par un objet actif est annoté du nu-
115