these doctorat une architecture de securité

Chapitre 5. Une architecture de sécurité de haut niveau
5.3.4 Conclusion
Dans cette partie, nous avons présenté le modèle d’authentification qui a été créé afin d’identifier
les diverses entités de notre système. L’introduction d’un certificat d’application permet la
différenciation des diverses applications lancées par un utilisateur et ainsi de créer un contexte
de sécurité qui sera propagé à tous les membres d’une même application.
Le chaînage de certificats induit une composition hiérarchique des certificats qui, comme nous
allons le montrer dans la suite du manuscrit, autorise une grande souplesse dans l’écriture de
règles de sécurité.
5.4 Politiques de sécurité décentralisées et adaptatives
Nous nous intéressons ici à la manière d’exprimer les règles de sécurité qui vont gouverner le
comportement des entités sécurisées.
tel-00239252, version 1 - 5 Feb 2008
5.4.1 Vers une politique de contrôle d’accès discrétionnaire
La partie 2.6 de ce manuscrit nous a permis d’introduire les divers types de politiques de sécurité
existants. Notre choix s’est porté sur la politique de contrôle d’accès discrétionnaire pour
plusieurs raisons. Tout d’abord, ce type de politique est le plus simple à mettre en œuvre, nous
devons garder à l’esprit que les règles de sécurité peuvent être écrites par des utilisateurs qui ne
maîtrisent pas forcément tous les concepts ni toutes les terminologies propres à la sécurité.
Ensuite, en accord avec notre modèle, la création puis la gestion par le mécanisme de sécurité
des politiques sont réalisées de manière décentralisée. Chaque acteur pouvant écrire sa propre
politique de sécurité sans avoir à interagir avec un autre acteur, il est ainsi inapproprié d’utiliser
une politique de sécurité à base de rôles qui suppose une gestion soit coordonnée, soit centralisée,
de la définition des divers rôles existants. La même remarque peut être utilisée concernant le
contrôle d’accès obligatoire car il se base sur des niveaux d’autorisation dont la gestion doit être
soit centralisée, soit coordonnée entres les divers sites participants.
5.4.2 Anatomie d’une politique de sécurité
Une politique de sécurité nous permet d’exprimer les conditions de sécurité à appliquer pour
un cas précis. Pour cela, elle doit nous permettre, tout d’abord, d’identifier un ensemble d’entités
sécurisées représentant l’ensemble des sujets initiant l’interaction et un autre ensemble d’entités
sécurisées représentant l’ensemble des entités cibles de l’interaction. Une fois les différents
ensembles clairement identifiés, il faut pouvoir exprimer les règles de sécurité qui s’appliqueront
sur cette interaction.
La syntaxe des règles de sécurité a tout d’abord été définie au sein d’un langage créé pour
nous permettre d’écrire simplement les règles de sécurité. La grammaire de ce langage est donnée
en annexe A. La bibliothèque ayant évolué vers l’utilisation du XML pour ses fichiers de
configuration et par soucis de cohérence, ce langage a été par la suite remplacé par un schema
qui a permis de conserver l’expressivité de notre langage tout en étant au format XML. Cependant
la plupart des articles que nous avons écrit reprennent le langage créé initialement car il a
l’avantage d’être plus concis et lisible que la syntaxe XML.
Chaque politique de sécurité se décompose en trois parties bien précises comme le montre la
figure 5.9. La première partie permet de définir les identités des divers acteurs (entités sources et
entités cibles) de la politique. La deuxième partie décrit les interactions sur laquelle la politique
de sécurité va imposer des restrictions. La troisième partie concerne les échanges de flux de
données et la façon de les transmettre sur le réseau.
78