these doctorat une architecture de securité

Chapitre 5. Une architecture de sécurité de haut niveau
tel-00239252, version 1 - 5 Feb 2008
et regroupe toutes les fonctions de sécurité nécessaires au bon fonctionnement du mécanisme de
sécurité.
Il contient plusieurs objets aux fonctions bien distinctes comme :
– le gestionnaire des sessions qui contient les diverses sessions établies avec les autres entités.
Ces sessions contiennent les différents paramètres de sécurité nécessaires à la communication
avec une entité distante ;
– le serveur de politique de sécurité sert de base de donnée contenant les politiques de sécurité
de l’entité. Ce sont ces politiques qui gouvernent l’établissement de sessions vers les autres
entités ;
– le serveur d’identité contient les divers éléments permettant d’établir l’identité de l’entité,
notamment son certificat publique, sa clé privée.
Une session représente une connexion établie ou en cours d’établissement entre deux entités.
Une session contient :
– un identifiant : un numéro de session. Ce numéro sert à identifier une session existant entre
deux entités ;
– un objet contenant la clé de session et ses paramètres d’initialisation ;
– une date d’expiration de la session ;
– l’identité de l’entité distante ;
– la politique de sécurité négociée entre les deux entités.
Pour une communication donnée entre deux entités, l’objet Session existe à la fois chez l’entité
client mais aussi chez l’entité serveur, ces deux sessions comportent le même identifiant. Il est
utilisé lors du transfert de messages chiffrés afin de retrouver la session et donc la clé permettant
le déchiffrement du message.
5.2.3 Les entités sécurisées dans ProActive
L’entité sécurisée est notre élément de base sur lequel nous pouvons exprimer des politiques
de sécurité. Cependant, la définition d’une entité sécurisée est une définition générique et il faut
maintenant pouvoir tenir compte de la spécificité propre à chaque objet qui va être sécurisé. En
effet, d’un point de vue technique, tous les objets partagent au minimum la possibilité de recevoir
et d’émettre des appels de méthodes. Nous allons présenter les divers types d’entités sécurisées
qu’il est possible de trouver au sein de la bibliothèque et leurs caractéristiques propres.
Les objets actifs sécurisés
Les premiers objets auxquels nous pensons lors de la sécurisation d’une application sont les
composants de cette application : les objets actifs. Un objet actif peut effectuer des appels de
méthode sur d’autres objets actifs ou sur des runtimes ou en recevoir comme tout objet Java normal.
Cependant il possède aussi des comportements propres comme, par exemple, la possibilité
de migrer d’un nœud vers un autre. L’entité sécurisée dans son comportement initial n’est plus
suffisante. A la simple interception des requêtes et des réponses, il faut maintenant ajouter la
gestion de la mobilité d’un objet actif. Il faut non seulement pouvoir spécifier des règles de sécurité
concernant la migration mais aussi introduire un algorithme permettant de gérer à la fois la
migration et la sécurisation d’un objet actif. Nous présentons et discutons le modèle retenu dans
la partie 6.3 de ce manuscrit.
Les nœuds sécurisés
Initialement les nœuds servent à nommer les divers lieux d’exécution disponibles qu’ils soient
locaux ou distants et à accueillir les objets actifs. Notre approche étend cette fonctionnalité initiale
en lui ajoutant les notions de sécurité nécessaires. Ainsi d’un simple conteneur passif d’objets
actifs, le nœud devient un acteur du mécanisme de sécurité de la bibliothèque. Il est capable
pour chacune de ses fonctionnalités de rechercher au sein de sa politique de sécurité si l’action
entreprise par l’entité sécurisée tierce peut être autorisée ou non ainsi que les attributs de sécurité
à utiliser pour le chiffrement des communications.
70