these doctorat une architecture de securité

Section 8.2. Perspectives
tel-00239252, version 1 - 5 Feb 2008
même application), nous pouvons supposer que la politique de sécurité de l’application a été
établie de manière cohérente afin de ne pas introduire de faille de sécurité au sein de l’application.
Cependant, notre modèle permet également à des entités sécurisées contenues
dans des contextes de sécurité différents d’interagir. Dans ce cas précis, une fois la donnée
transmise, elle peut être utilisée par l’entité qui l’a reçue sans aucune contrainte. Elle ainsi
être transmise à une autre entité lors d’un appel de méthode. Il est ainsi possible d’exporter
des données en dehors de leur contexte de sécurité initial si la politique de sécurité le
permet. Au vu de ces explications, il parait intéressant d’étudier l’adjonction d’un mécanisme
de contrôle de flux afin combler cette potentielle brèche de sécurité. Les premières
réflexions sur cette possible extension nous ont conduit essayer de reprendre le principe des
entités sécurisées afin de transformer les données en entités sécurisées. Cette solution est
similaire à l’approche des Secure Meta Objects introduite en 2.7.4.
Si cette solution semble prometteuse, elle comporte néanmoins des inconvénients. Tout
d’abord, elle va augmenter considérablement le nombre d’objets puisque nous comptons
associer une entité sécurisée à toute donnée expédiée lors d’un appel de méthode. Deuxièmement,
cette approche suppose qu’à tout instant, le moniteur de référence est capable de
calculer la politique de sécurité associée à une donnée. Ceci suppose que chaque donnée soit
associée à une ou plusieurs politiques de sécurité. Enfin, il existe une limitation venant directement
du langage Java et qui concerne les types primitifs. Jusqu’en Java 1.4, ces types
ne pouvaient être réifiés, dès lors il nous est impossible d’y associer une entité sécurisée.
Depuis la version 1.5, Java introduit les mécanismes d’autoboxing permettant la conversion
automatique d’un type primitif vers un objet wrapper représentant un entier et inversement.
Cependant il ne nous semble pas possible de conserver les méta-objets associés à un
objet lors de sa conversion en type primitif.
– Reconfiguration dynamique des entités sécurisées
Nous avons vu qu’une entité sécurisée est associé à une politique de sécurité lors de sa
création. Afin de permettre à cette entité sécurisée de réagir à la dynamicité de son environnement,
il faut être capable de modifier dynamiquement la politique de sécurité associée
à l’entité. Par exemple, lorsque l’entité sécurisée fournit un service, il n’est pas concevable
de devoir arrêter puis recréer le service lors de changement dans la politique de sécurité.
La mise à jour de la politique de sécurité d’une entité est d’une mise en œuvre assez simple.
Cependant, la mise à jour de la politique de sécurité d’une entité sécurisée peut avoir des
répercussions surtout si cette entité appartient à une application distribuée. Dans le cadre
d’une application sécurisée, nous avons fait en sorte que toutes les entités sécurisées partagent
la même politique de sécurité afin de garantir une politique de sécurité cohérente
pour l’application. Ainsi, la mise à jour d’une entité devrait être répercutée sur toutes les
entités composant l’application. Le problème principal consiste donc à mettre à jour toutes
ces entités en même temps ce qui suppose d’avoir un mécanisme de recherche et/ou de localisation.
– Service web sécurisé
L’exportation d’un objet actif en tant que service web permet à ce dernier d’être contacté
par des objets par n’importe quel type de processus et pas seulement des objets actifs. De
plus, le standard des services web définit ses propres mécanismes de sécurité WS-Security.
Une perspective serait d’établir une passerelle entre notre modèle de sécurité et celui des
services web. Elle permettrait de faire communiquer un service web sécurisé avec un service
web représentant un objet actif et inversement. Le service web sécurisé devra interagir
directement avec les mécanismes de sécurité des objets actifs et s’intégrer de manière transparente
avec le mécanisme de sécurité afin de proposer un ensemble de sécurité homogène
et cohérent. Ce modèle doit assurer la sécurité des messages de et vers un objet actif en
se basant sur les standards utilisés au sein de la bibliothèque ProActive et des web services.
Le deuxième objectif serait l’importation automatique d’un service web sécurisé au
sein d’un code écrit avec ProActive . Le service web sera vu comme un objet actif au sein du
code. Pour cela, il faudra écrire un mécanisme de wrapper qui respecte la sémantique de la
bibliothèque tout en établissant un lien sécurisé vers le service web.
133