these doctorat une architecture de securité
these doctorat une architecture de securité
these doctorat une architecture de securité
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Section 2.7. Programmation Réflexive<br />
Le modèle <strong>de</strong> combinaison basé sur <strong>une</strong> algèbre <strong>de</strong> sécurité étend le modèle <strong>de</strong> sécurité afin <strong>de</strong><br />
pouvoir exprimer formellement diverses conditions <strong>de</strong> sécurité et introduit <strong>de</strong>s opérateurs permettant<br />
<strong>de</strong> définir <strong>une</strong> algèbre <strong>de</strong> sécurité. McLean dans [85] propose <strong>une</strong> algèbre booléenne pour<br />
les politiques <strong>de</strong> contrôle d’accès multi-niveaux avec gestion dynamique <strong>de</strong>s niveaux <strong>de</strong> sécurité,<br />
et définies sur un même système.<br />
Foley dans [43] propose un modèle <strong>de</strong> combinaison s’appuyant sur le langage <strong>de</strong> spécification Z<br />
qui est un langage basé sur la théorie <strong>de</strong>s ensembles et la logique du premier ordre (cf. [33]). Hosmer<br />
[59] adopte <strong>une</strong> approche ne reposant sur auc<strong>une</strong> relation d’ordre, il introduit la notion <strong>de</strong><br />
métapolitique ou "politique <strong>de</strong> politiques", <strong>une</strong> approche informelle pour décrire, faire collaborer,<br />
ou combiner <strong>de</strong>s politiques <strong>de</strong> sécurité.<br />
2.6.5 Bilan<br />
tel-00239252, version 1 - 5 Feb 2008<br />
Le problème lié à l’existence <strong>de</strong> différentes politiques <strong>de</strong> sécurité dans les systèmes décentralisés<br />
est résolu en composant ces politiques à l’ai<strong>de</strong> d’<strong>une</strong> politique <strong>de</strong> composition. Nous avons<br />
i<strong>de</strong>ntifié <strong>de</strong>ux approches à la composition <strong>de</strong> politique <strong>de</strong> sécurité. La première, l’interopérabilité<br />
<strong>de</strong> politiques <strong>de</strong> sécurité est recommandée dès lors que les systèmes informatiques sont mutuellement<br />
suspicieux. En particulier, l’interopération <strong>de</strong> politiques <strong>de</strong> sécurité ne peut se faire que<br />
lorsque les politiques <strong>de</strong> sécurité sont cohérentes. A l’inverse la secon<strong>de</strong> approche, la combinaison<br />
<strong>de</strong> politiques <strong>de</strong> sécurité, permet <strong>de</strong> composer <strong>de</strong>s politiques <strong>de</strong> sécurité éventuellement incohérentes.<br />
Dans ce cas, la politique résultante est construite à partir <strong>de</strong>s spécifications <strong>de</strong>s politiques<br />
initiales.<br />
La différence fondamentale entre les <strong>de</strong>ux approches repose sur la mise en œuvre <strong>de</strong> la politique<br />
résultante. Lors <strong>de</strong> l’interopérabilité <strong>de</strong> <strong>de</strong>ux politiques <strong>de</strong> sécurité, les mécanismes <strong>de</strong><br />
protection <strong>de</strong> ces politiques sont utilisés afin <strong>de</strong> garantir la politique résultante. Lors <strong>de</strong> la combinaison<br />
<strong>de</strong> <strong>de</strong>ux politiques <strong>de</strong> sécurité, les mécanismes mis en œuvre pour la politique résultante<br />
peuvent être en partie différents <strong>de</strong> ceux <strong>de</strong>s politiques initiales. Il faut toutefois remarquer que<br />
la politique résultant <strong>de</strong> la combinaison ou celle résultant <strong>de</strong> l’interopération <strong>de</strong> <strong>de</strong>ux politiques<br />
<strong>de</strong> sécurité peuvent être i<strong>de</strong>ntiques.<br />
Si on compare toutes ces politiques, on s’aperçoit rapi<strong>de</strong>ment qu’on peut les classer en <strong>de</strong>ux<br />
catégories. La première est celle contenant les politiques <strong>de</strong> contrôle d’accès discrétionnaire. La<br />
<strong>de</strong>uxième catégorie regroupant les politiques <strong>de</strong> contrôle d’accès obligatoire et les politiques à<br />
base <strong>de</strong> rôles. Le facteur différenciant ces <strong>de</strong>ux catégories est la structuration implicite qui est<br />
imposée aux utilisateurs <strong>de</strong> ces divers modèles. Une politique d’accès discrétionnaire ne requiert<br />
auc<strong>une</strong> organisation logique. Contrairement à cela, les membres <strong>de</strong> la <strong>de</strong>uxième catégorie imposent<br />
l’existence d’un d’ordre partiel permettant la classification <strong>de</strong>s sujets. De plus, il faut <strong>une</strong><br />
structure externe afin <strong>de</strong> contenir cet ordre partiel. Le choix d’un modèle <strong>de</strong> politique <strong>de</strong> sécurité<br />
dépend donc fortement du contexte dans lequel les règles <strong>de</strong>vront pouvoir être exprimées.<br />
2.7 Programmation Réflexive<br />
Cette thèse se propose d’utiliser certains aspects <strong>de</strong> la programmation réflexive afin <strong>de</strong> rendre<br />
les mécanismes <strong>de</strong> sécurité orthogonaux au co<strong>de</strong> <strong>de</strong> l’application. Nous présentons tout d’abord<br />
les concepts <strong>de</strong> métaprogrammation et <strong>de</strong> programmation réflexive, puis nous étudions comment<br />
l’utilisation <strong>de</strong> la programmation réflexive peut s’intégrer avec <strong>de</strong>s mécanismes <strong>de</strong> sécurité.<br />
2.7.1 Principes <strong>de</strong> base<br />
Afin d’exposer les principes <strong>de</strong> base <strong>de</strong> la programmation réflexive, nous commençons en introduisant<br />
l’idée fondamentale <strong>de</strong> la métaprogrammation : un programme peut être considéré<br />
comme <strong>une</strong> donnée qui peut faire l’objet d’un traitement <strong>de</strong> la part d’un autre programme.<br />
La faculté <strong>de</strong> pouvoir considérer un programme comme <strong>une</strong> donnée a conduit à la définition<br />
<strong>de</strong>s concepts <strong>de</strong> métaprogrammation, métaprogramme et programme <strong>de</strong> base.<br />
21