these doctorat une architecture de securité

Section 5.5. Négociation Dynamique d’une Politique
tel-00239252, version 1 - 5 Feb 2008
sur l’entité cliente (celles de l’entité elle-même et des entités englobantes). Une fois
les informations de localisation de l’entité cliente et de l’entité serveur récupérées, le
mécanisme de sécurité de l’entité cliente peut interroger toutes les entités englobantes
afin d’obtenir les règles de sécurité à appliquer sur l’interaction.
(c) Le mécanisme de sécurité du client calcule la politique de sécurité résultante à partir
de l’ensemble de politiques récupérées côté client.
2. Un message (3) est ensuite expédié à l’entité serveur contenant les chaînes de certificats
identifiant les entités contenant l’entité cliente, la chaîne de certificats identifiant l’entité
cliente et la politique de sécurité calculée par l’entité cliente.
3. L’entité serveur reçoit la politique de sécurité demandée par l’entité cliente. L’entité serveur
:
(a) récupère à son tour toutes les politiques de sécurité qui correspondent à l’interaction
qui va avoir lieu, les combine afin d’obtenir une politique de sécurité résultante. Cette
politique représente la politique de sécurité que requiert l’entité serveur.
(b) compare la politique de sécurité requise par l’entité cliente à la politique calculée localement.
Si ces politiques divergent, l’interaction est arrêtée et une exception est levée.
Si les politiques sont identiques, un objet Session représentant l’interaction est créé. Si
les politiques sont compatibles, elles doivent une dernière fois être combinées pour former
la politique de sécurité finale avant de créer l’objet Session. Cet objet sera utilisé
ultérieurement pour toutes les actions de sécurité (chiffrement, signature) qui pourront
être requises pour cette interaction spécifique.
(c) retourne à l’entité cliente (4) les informations de sécurité nécessaires (SessionID, politique
de sécurité finale)
4. Le client vérifie que la politique retournée est bien compatible avec sa politique locale et
crée, à son tour, un objet de type Session. Cet objet va exécuter les actions de sécurité
requises par la politique de sécurité commune. L’entité cliente engendre une clé de session
et l’envoie au serveur (5).
5. L’entité serveur finalise sa session en y ajoutant la clé de session et envoie le message [Fin]
(6) à l’entité cliente.
6. l’entité cliente valide la session, et l’interaction peut être poursuivie.
Ce protocole d’établissement de session présuppose l’existence d’un mécanisme externe capable
de récupérer et de sélectionner toutes les règles de sécurité sur une entité afin de les combiner
entre elles dans le but de générer une politique de sécurité résultante intégrant les critères
de toutes les politiques s’appliquant à l’interaction.
En effet, il est possible pour un acteur donné d’écrire une politique de sécurité générale pour
son application et de vouloir une politique de sécurité précise pour un sous-ensemble de sa politique
de sécurité générale. L’algorithme de recherche le plus simple aurait été d’arrêter la recherche
à la première politique rencontrée qui correspond à l’interaction. Cette solution simple et
peu coûteuse en ressources système possède plusieurs inconvénients. Tout d’abord, le fait qu’une
seule règle puisse être sélectionnée impose au concepteur de la politique de sécurité de décrire
tous les cas possibles qu’il voudrait prendre en compte et d’ordonner les politiques de sécurité selon
un ordre précis. Deuxièmement, la dynamicité de l’approche laisse supposer que des cas non
prévus initialement par le concepteur de la politique puissent mener à l’utilisation des règles trop
génériques. Pour toutes ces raisons, nous avons choisi de doter notre mécanisme de sécurité d’algorithmes
plus intelligents. Ces algorithmes sont au nombre de trois : l’algorithme de sélection
des politiques de sécurité, l’algorithme de filtrage et en dernier l’algorithme de composition des
politiques de sécurité afin d’obtenir une politique de sécurité finale pour une interaction donnée.
5.5.2 Algorithme de sélection
Lors d’une interaction, plusieurs entités peuvent être impliquées du fait de la structuration
hiérarchique de notre modèle (figure 5.11).
85