these doctorat une architecture de securité

Section 5.2. Un modèle de sécurité générique et hiérarchique
Si on reprend le modèle de base de ProActive on s’aperçoit que les entités qui peuvent interagir
sont multiples, nous pouvons, dans un premier temps, identifier au moins les objets actifs
et les runtimes. Cela signifie que nous allons devoir proposer un modèle de sécurité qui puisse
prendre en compte à la fois la particularité des objets actifs en tant, par exemple, qu’entités
mobiles mais aussi celles des runtimes en tant qu’entités capables de contenir d’autres entités
comme les nœuds ou les objets actifs.
Par ailleurs, il est possible d’extraire des différents objets composant une architecture distribuée
(runtimes, nœuds) et des objets actifs un ensemble distinct de fonctionnalités qui vont
servir de base commune à la définition et la création d’une spécification concernant les besoins
de sécurité d’une architecture distribuée. Cet ensemble de fonctionnalités est regroupé sous le
terme d’entité sécurisée et nous définissons une entité sécurisée de la manière suivante :
Définition 10 Entité Sécurisée
Par définition, on nommera une entité sécurisée tout code ou donnée auquel est associé un mécanisme
de sécurité permettant l’interception de toutes les interactions avec l’environnement extérieur.
À une entité sécurisée sont associées une identité et une politique de sécurité. À partir de
sa politique de sécurité, un gestionnaire de sécurité pourra déduire une politique de sécurité pour
une interaction donnée.
tel-00239252, version 1 - 5 Feb 2008
Cette définition permet d’atteindre en partie l’un des objectifs de notre modèle : l’autonomie
dont dispose l’entité sécurisée vis-à-vis de la prise de décision concernant les règles de sécurité.
Du fait que nous nous trouvons dans une architecture répartie, aucun postulat ne peut être fait,
par exemple, sur la connectivité du réseau sous-jacent ou sur tout autre défaillance pouvant survenir
dans une architecture distribuée, le gestionnaire de sécurité doit pouvoir être autonome et
pouvoir prendre les décisions concernant la sécurité de l’objet qu’elle sécurise de manière automatique
sans avoir recours à un serveur de politique centralisé, ou en minimisant les communications
vers des objets se trouvant à distance. En dotant l’entité sécurisée d’une politique de
sécurité, le mécanisme de sécurité va pouvoir utiliser cette politique de sécurité pour prendre les
décisions de sécurité nécessaires vis-à-vis de cette entité sécurisée.
Par ailleurs, on ne fait aucune supposition sur l’objet contenu par l’entité sécurisée. Notre
modèle de sécurité n’est pas intrusif : il ne requiert aucune modification de l’objet sécurisé ni statiquement
en modifiant le code source, ni dynamiquement par réflexivité. Cette approche permet
l’utilisation et la sécurisation des objets java dont le code source n’est pas disponible mais aussi
l’utilisation d’objets écris dans un autre langage (en C, C++, etc) et dont le chargement au sein de
la machine virtuelle a été effectué par la Java Native Interface (JNI). De cette façon, l’objet sécurisé
continue son exécution de manière classique, sans avoir nullement notion d’être sécurisé.
Nous allons maintenant décrire plus en détails ce mécanisme d’interception.
La notion de hiérarchie qui va exister pendant l’exécution d’une application est importante
du point de vue de la sécurité car elle induit qu’une entité sécurisée peut imposer une politique
de sécurité précise aux entités qu’elle contient.
5.2.1 Contrôle d’accès aux entités
Afin de protéger un objet et étant donné qu’on ne peut pas modifier l’objet lui-même, il
convient de sécuriser les échanges de flux entre cet objet et les objets extérieurs c’est-à-dire les
appels de méthodes de et vers cet objet ainsi que les valeurs de retour résultantes de ces appels
de méthodes. En d’autres termes, il faut intercepter tous les messages entrants et sortants.
La figure 5.1 expose la solution retenue. On place un objet d’interception, le gestionnaire
de sécurité, entre les interactions venant du monde extérieur et l’objet protégé. Les messages
entrant et sortant seront interceptés par le gestionnaire de sécurité. Au sein de l’entité les communications
entre l’objet sécurisé et l’objet d’interposition s’effectuent en clair, tandis que les
communications entre le gestionnaire de sécurité et les objets extérieurs à l’entité peuvent être
67