13.05.2014 Views

these doctorat une architecture de securité

these doctorat une architecture de securité

these doctorat une architecture de securité

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!