these doctorat une architecture de securité

Section 5.5. Négociation Dynamique d’une Politique
Interdit. Ils seront appliqués à toutes les interactions décrites précédemment. Par exemple, la
partie de la règle exposée ci-dessus spécifie que concernant toutes les interactions qui peuvent
engendrer une communication sortante (requête, réponse, migration), les transferts doivent être
authentifiés, l’intégrité des données ne doit pas être assurée, mais cependant le chiffrement de ces
données est optionnel. Il est également possible de spécifier ces attributs sur toutes les communications
entrantes. Cette gestion asymétrique des attributs de sécurité permet de différencier
les deux sortes de flux et ainsi d’augmenter encore l’adaptabilité du mécanisme de sécurité.
Chaque règle peut être interprétée différemment selon la position de l’entité courante dans
la partie identification de cette dernière. En effet, selon sa position, l’entité sera considérée
comme effectuant l’interaction ou comme la subissant. C’est un des rôles du gestionnaire de
sécurité de rechercher dans une règle si l’entité qu’il représente est présente dans un des deux
ensembles d’entités ( ou ) et selon sa position, d’interpréter la règle par rapport à
l’interaction courante. Par exemple, concernant une entité voulant émettre un appel de méthode,
le gestionnaire de sécurité extraira les attributs de sécurité de la balise , si cette
même entité se retrouve à recevoir un appel de méthode, cette fois, le gestionnaire de sécurité
extraira les attributs de sécurité de la balise .
tel-00239252, version 1 - 5 Feb 2008
5.4.3 Conclusion
Les politiques de sécurité présentées dans cette section nous permettent de répondre aux
besoins induits par la structure décentralisée de notre approche. Chaque règle est construite de
manière autonome de sorte que le gestionnaire de sécurité puisse prendre des décisions locales
sans avoir besoin de se référer à un serveur de politique de sécurité.
L’introduction au sein de la règle des propriétés {"Requis","Optionnel","Interdit"} permet d’accorder
au gestionnaire de sécurité la possibilité d’adapter, au besoin, la règle en fonction des
autres règles tout en tenant compte des critères exprimés dans cette dernière.
5.5 Négociation Dynamique d’une Politique
Notre infrastructure de sécurité est prévue pour fonctionner de façon décentralisée, sans aucune
gestion centralisée qui assurerait la correction de toutes les politiques de sécurité contenues
dans toutes les entités du système. Compte tenu de cette décentralisation et même pour une application
simple, il est possible d’obtenir plusieurs politiques de sécurité actives sur plusieurs
niveaux de sécurité pour une interaction donnée. Afin de prendre en compte leurs critères de
sécurité, elles doivent être combinées, vérifiées et négociées dynamiquement.
Nous présentons, dans un premier temps, le protocole que nous avons développé pour l’établissement
de sessions entre les entités sécurisées. Nous détaillerons ensuite les parties liées à
la recherche, au filtrage et à la composition des politiques de sécurité afin d’obtenir une politique
de sécurité pour une interaction donnée.
5.5.1 Protocole d’établissement de session
Le protocole décrit dans cette partie permet l’établissement d’une connexion sécurisée entre
deux entités. Il s’agit d’une version basée sur le protocole Transport Layer Security (TLS) [31]
normalisé par l’Internet Engineering Task Force. La phase de négociation des paramètres de
sécurité a été modifiée afin d’être compatible avec les pré-requis de notre architecture de sécurité.
La figure 5.10 schématise les échanges de messages conduisant à l’établissement d’une session.
Lors d’une interaction entre une entité cliente (celle qui initie l’interaction) vers une entité
serveur (celle qui reçoit l’interaction) les phases suivantes sont mises en œuvre pour aboutir à
une interaction sécurisée :
83