3.6 Politique de sécurité
3.6.2 Score d’application
A partir des scores d’application des propriétés définis à la section 3.5.4, il est possible de déterminer la qualité de l’application d’une politique en fonction d’un système et d’une configuration donnés. En effet, pour une même politique, on peut comparer la qualité de l’application en se basant sur les applications de chacune de ses propriétés.
Définition 3.6.2: Score d’application de la politique
Soit P une politique de sécurité. On note pi,1in les n propriétés instanciées dont est formée P . On définit le score d’application Sapp(P ) de la politique par :
Sapp(P ) = n X i=1 Sapp(pi) , Sapp(P ) = n X i=1 m X j=1 p X k=1
Sord(pi,j)⇤ Sapp(Ci,j,k) , Sapp(P ) = n X i=1 m X j=1 p X k=1 ✓ Sstat(pi,j)
d(pi,j, pi) + 1⇤ Sapp(Ci,j,k) ◆ , Sapp(P ) = n X i=1 m X j=1 p X k=1 Sstat(pi,j) d(pi,j, pi) + 1⇤ q X l=1 S(c, Ml)⇤d(c, C1 i,j,k) + 1 !
Il est donc possible de comparer la qualité de l’application d’une politique sur plusieurs systèmes en utilisant son score d’application et la règle suivante :
Règle 3.6.3: Comparaison d’applications de politique
Soit P une politique de sécurité. Soient Sapp(P )1 et Sapp(P )2 son score d’application sur deux systèmes différents. Alors, plus le score est élevé, meilleure est l’application.
3.7 Conclusion
Dans ce chapitre, nous avons présenté un langage d’expression des besoins de sécu-rité, visant à être utilisé dans des systèmes hétérogènes tels que ceux de l’informatique en nuage. Ce langage a pour objectif de répondre aux problèmes spécifiques liés aux environ-nements hétérogènes. Il est donc indépendant des ressources à protéger et des mécanismes de sécurité, simple d’utilisation, adaptatif et extensible.
Nous avons tout d’abord introduit la notion de contexte, qui permet d’identifier les ressources de manière indépendante du système de nommage utilisé sur la machine. Grâce à ces contextes, le langage est indépendant des ressources : la politique exprimant les besoins de sécurité de ces ressources est indépendante de leur nom ou des applications utilisées. La politique de sécurité est ainsi portable, puisqu’une même politique peut être utilisée sur des systèmes différents. La politique est complétée par une table d’associations des contextes aux ressources réelles. Cette table dépend du système et des applications utilisées, mais elle peut cependant être générée automatiquement et des tables prédéfinies peuvent être fournies pour les applications usuelles.
Nous avons ensuite défini les capacités qui correspondent aux fonctionnalités des méca-nismes de sécurité. Chaque capacité peut être fournie par plusieurs mécaméca-nismes de sécurité, permettant ainsi au langage d’en être indépendant. Par conséquent, la politique peut être appliquée sur un système par des mécanismes différents, selon ceux qui sont disponibles. Plusieurs contraintes sont définies sur les mécanismes, permettant de paramétrer leur sé-lection selon leurs compatibilités, leurs dépendances et leurs statuts de dominance.
Nous avons également présenté les propriétés qui combinent des capacités afin de fournir des fonctionnalités de sécurité et d’assurance de haut niveau. Ces propriétés sont simples à utiliser, notamment en raison des classes qui peuvent les regrouper et donc simplifier la définition de la politique. En effet, l’utilisation des classes permet au langage d’être adaptatif, puisqu’un appel à une classe génèrera un appel à une propriété en fonction du type des arguments. De plus, les propriétés peuvent être surchargées, s’adaptant ainsi au type de leurs arguments. Enfin, de nouvelles capacités, propriétés et classes peuvent être définies par un expert sécurité, rendant ainsi le langage extensible.
Enfin, nous avons proposé un score d’ordonnancement permettant de sélectionner les ca-pacités et les propriétés les mieux adaptées, et un score d’application permettant d’évaluer l’application des propriétés de sécurité. De plus, les relations entre les différents mécanismes sont gérées grâce à des matrices décrivant leurs compatibilités, dépendances et dominances. Le langage proposé possède donc l’ensemble des caractéristiques nécessaires à son utili-sation dans un système hétérogène. De plus, il propose deux vues permettant une expression simple des besoins de sécurité par l’administrateur de l’architecture logicielle et de la po-litique, tout en donnant la possibilité à un expert en sécurité d’étendre le langage pour adresser un plus large ensemble de problèmes de sécurité. L’administrateur n’a donc pas à se soucier des mécanismes qui sécuriseront son système, mais seulement à se focaliser sur l’expression de ses besoins, en identifiant les ressources à protéger (contextes) et leurs besoins de sécurité (propriétés). Les scores d’application permettent ensuite à l’administra-teur d’avoir un retour sur la qualité de l’application de la politique. Notons qu’une politique peut être exprimée à partir des besoins définis grâce à des méthodes d’analyse des risques (section 2.2.3) et pourrait être transposée dans l’un des langages de la section 2.1.2. Une architecture pouvant appliquer une politique exprimée dans ce langage sera détaillée au chapitre 4 et son implémentation sera décrite au chapitre 5.
Chapitre 4
Architecture et Projection
Dans le chapitre précédent, nous avons défini un langage d’expression des besoins de sécurité pour une architecture en nuage. Afin de pouvoir effectivement protéger l’architec-ture logicielle, les propriétés de sécurité exprimées dans ce langage doivent être traduites et appliquées en utilisant les mécanismes disponibles.
L’application de la politique se faisant dans un environnement d’informatique en nuage, les systèmes concernés sont hétérogènes. De plus, les mécanismes présents pour appliquer les propriétés varient d’un système à l’autre. Par conséquent, il est nécessaire de disposer d’une architecture capable de compiler une politique de sécurité et de la projeter en s’adaptant à l’environnement. En outre, l’informatique en nuage étant un environnement dynamique, l’architecture proposée doit être capable de détecter d’éventuels dysfonctionnements et de prendre les décisions appropriées pour y répondre. La définition d’une telle architecture est l’objectif de ce chapitre, qui présentera les différentes étapes du cycle de vie d’une politique. Ce chapitre commencera par la description de l’architecture globale dans laquelle s’ins-crivent les travaux (section 4.1) avant de présenter l’architecture générale du Security Enfor-cement Engine (section 4.2) qui est chargé d’appliquer et d’assurer la politique de sécurité. Les sections suivantes détailleront les différents éléments du Security Enforcement Engine : le gestionnaire de politique (section 4.3) qui maintient à jour la politique de sécurité et la configuration interne, le moteur d’application (section 4.4) qui compile et projette la politique, le moteur d’assurance (section 4.5) qui traite les informations d’assurance qui lui sont transmises, et le module de scores (section 4.6) qui évalue la qualité de l’application de la politique. Le chapitre 5 présentera l’implémentation de cette architecture.
4.1 Architecture globale
L’architecture proposée dans ce chapitre a pour objectif d’implémenter et de projeter le langage d’expression des besoins de sécurité (chapitre 3) sur des mécanismes de sécurité (section 2.3) afin d’appliquer la politique de sécurité (section 3.6). L’architecture permet-tant de réaliser cette projection est décrite à la figure 4.1 et est basée sur l’architecture proposée dans le cadre du projet Seed4C.
Cette architecture est basée sur un modèle multi-agents [Ferber, 1999, Wooldridge, 2009]. Un agent est présent sur chaque nœud, c’est-à-dire sur chaque machine physique et sur chaque machine virtuelle impliquée dans une architecture logicielle.
L’architecture de Seed4C peut être séparée en six composants principaux :
1. Un outil de modélisation permettant de représenter graphiquement la politique de sécurité ;
Figure 4.1 – Architecture globale basée sur l’architecture Seed4C 2. Un outil de déploiement qui transmet les politiques aux nœuds concernés ; 3. Un moteur d’application qui applique la politique de sécurité ;
4. Un moteur d’assurance qui vérifie que les propriétés sont correctement appliquées ; 5. Des mécanismes de sécurité, utilisés aux étapes 3 et 4, afin d’effectuer les phases
d’application et d’assurance ;
6. Un tableau de bord pour visualiser les résultats de l’assurance.
L’architecture proposée dans cette thèse est fortement basée sur l’architecture dé-finie par l’ensemble des partenaires du projet Seed4C et dont l’approche est détaillée dans [Betgé-Brezetz et al., 2013]. Ainsi, l’apport de cette thèse est formé des parties d’ap-plication et d’assurance des propriétés. La principale différence entre l’architecture Seed4C et celle présentée ici est l’utilisation qui est faite des données d’assurance. Dans le cadre du projet, les informations d’assurance sont récupérées et traitées par des outils de visua-lisation développés par des partenaires et peuvent être renvoyées à l’outil de modévisua-lisation. Dans l’architecture que nous utilisons, les informations d’assurance sont directement in-terprétées par l’agent afin de mettre à jour la politique de chaque nœud en fonction des événements reçus.
De plus, les outils de modélisation et de déploiement (développés par des partenaires de Seed4C) ne sont utilisés que lors de la phase d’initialisation du système. Bien que notre architecture puisse les utiliser, elle en est indépendante et utilise uniquement la politique définie dans le langage du chapitre 3 (cette politique peut aussi être générée par l’outil de modélisation).
L’architecture générale, incluant les phases depuis la modélisation jusqu’à l’application de la politique, a été présentée dans [Bobelin et al., 2014]. L’application des politiques a été détaillée dans [Bousquet et al., 2014] et le processus d’assurance dans [Bobelin et al., 2015]. Dans les sections suivantes, les outils de modélisation et de déploiement sont brièvement introduits, afin de décrire le processus global, mais ne sont pas détaillés car ils ne sont pas l’objet de ce document. Le reste de ce chapitre portera sur les moteurs d’application et d’assurance de la politique.