these doctorat une architecture de securité

Chapitre 5. Une architecture de sécurité de haut niveau
Suivant ces politiques de sécurité, lorsqu’une scène va être rendue les données sont normalement
transférées vers les moteurs de rendu par le contrôleur. Cependant selon leur localisation
(grappe de calcul A ou B) les attributs de sécurité différeront. Les communications vers les moteurs
de rendu de la grappe de calcul A se feront selon la règle 1 tandis que les communications
vers les moteurs de rendu de la grille de calcul B se feront suivant la composition des règles 1 et
3.
La migration d’un moteur de rendu au sein d’un ordinateur vers un autre de la même grappe
se fera selon la règle 2 tandis que la migration de ce même moteur de rendu entre les deux
grappes se fera selon la composition des règles 2 et 3. Si un moteur de rendu de la grappe de
calcul B migre vers la grappe de calcul A, les futures communications entre ce moteur de rendu
et le contrôleur se feront selon la règle 1. Parallèlement, si un moteur de rendu de la grappe de
calcul A migre vers la grappe de calcul B, les futures communications entre ce moteur de rendu
et le contrôleur se feront selon la composition des règles 1 et 3.
Si l’utilisateur B se trouve au sein de la grappe de calcul B, les communications se feront selon
la composition des règles 3 et 5b.
tel-00239252, version 1 - 5 Feb 2008
5.6.5 Conclusion
L’externalisation du mécanisme de définition des politiques de sécurité permet d’adapter la
politique de sécurité d’une application au type de déploiement utilisé. Cette approche facilite le
déploiement d’une infrastructure sécurisée et la mise en place d’un contexte de sécurité autour
d’une application qui n’a pas conscience d’être sécurisée.
5.7 Propagation dynamique du contexte de sécurité
La section précédente a permis de présenter l’intégration de la sécurité au sein du processus
de déploiement. L’approche permet la mise en place d’une architecture sécurisée lors du déploiement
d’une application afin d’établir un contexte de sécurité autour de l’application. Cependant
une application est une entité dynamique et, lors de son exécution, elle peut être amenée à créer
de nouveaux runtimes, nœuds, objets actifs. Le mécanisme présenté dans cette section s’inscrit
dans la continuité du mécanisme de déploiement d’une infrastructure sécurisée par le biais des
descripteurs de déploiement. Ce mécanisme permet d’assurer le confinement des nouveaux éléments
de l’application et la propagation de la politique de sécurité à ces nouveaux éléments.
On s’intéresse essentiellement à une application dont la politique de sécurité est imposée lors
de son déploiement. Cependant, le mécanisme que nous allons décrire est aussi compatible avec
toute application qui gère explicitement sa sécurité en utilisant notre mécanisme de sécurité.
Tout code applicatif est exécuté sous l’identité d’une entité sécurisée (un objet actif). Une
entité sécurisée est conçue pour être autonome et pouvoir gérer de manière décentralisée sa
propre sécurité. Elle doit aussi s’assurer que le code applicatif ne va pas introduire des failles
dans la sécurité de l’application, notamment lors de la création de nouveaux objets. Parmi les
objets que le code applicatif est capable de créer, on retrouve :
– les objets Java, qu’ils soient actifs ou passifs ;
– les nœuds qui sont un élément de l’application.
Un objet passif ne possède pas de gestionnaire de sécurité, il dépend du gestionnaire de sécurité
de l’entité sécurisée qui le contient et qui lui impose sa politique de sécurité. La création
d’un objet passif ne requiert aucune interaction de la part du mécanisme de sécurité.
À l’inverse, un objet actif ou un nœud sont des entités sécurisées qui possèdent un gestionnaire
de sécurité et une identité (un certificat). Lorsque du code applicatif instancie un objet actif,
le mécanisme de sécurité doit pouvoir, à partir des informations locales, générer une nouvelle entité
sécurisée qui devra apparaître comme appartenant à la même application.
94