L’ingénierie de la sécurité

Dans cette section, nous présentons les principaux travaux qui intègrent les aspects re-latifs à la sécurité lors d’un processus de développement logiciel. Nous nous intéressons particulièrement aux travaux qui présentent une approche IDM. Le génie logiciel touche la spécification, la conception, le développement, l’implémentation, le test et l’évolution des systèmes logiciels. La sécurité dirigée par les modèles (Model-Driven Security (MDS)) [ Ba-sin et al., 2006] est l’application des techniques du génie logiciel lors de la conception de systèmes sécurisés.

La sécurité dirigée par les modèles vise à concevoir, dans un premier temps, des sys-tèmes sécurisés indépendamment de la plateforme utilisée [Basin et al.,2006] et [Hafner et Breu,2008]. La recherche dans le domaine des MDS est un sujet très actif qui vise la concep-tion de systèmes sécurisé. Dans ce qui suit nous présentons d’une façon non exhaustive les principaux travaux de recherche qui proposent des solutions pour le développement d’ap-plications sécurisées indépendamment de l’utilisation des patrons.

En 2002, David Bassin et al. [Lodderstedt et al.,2002] introduisent pour la première fois le terme de «sécurité dirigée par les modèles » (Model-driven Security). Comme première application, ces mêmes auteurs ont proposé la génération des politiques de contrôle d’accès à partir des contraintes d’autorisation abstraites écrites en OCL (Object Constraint Langage). L’approche proposée est intéressante et flexible. En effet le DSL (Domain Specific Language)

proposé pour introduire la sécurité est appelé SecureUML. L’approche présentée dans Se-cureUML consiste à modéliser les politiques de contrôle d’accès pour montrer comment celles-ci peuvent être intégrées dans un processus de développement logiciel dirigé par les modèles. La solution proposée par SecureUML se base sur un modèle élargi de contrôle d’accès basé sur les rôles en utilisant le modèle RBAC (Role-Based Access Control) pour la spécification et l’application de la sécurité. SecureUML définit un vocabulaire pour an-noter des modèles UML avec des informations pertinentes relatives aux contrôles d’accès. Dans cette approche, les auteurs proposent un processus dirigé par les modèles composé de deux phases qui sont (1) la définition des politiques de contrôle d’accès (en utilisant le contrôle d’accès basé sur les rôles (RBAC)) et (2) la transformation vers des configurations de descripteur de déploiement J2EE.

Le méta-modèle SecureUML est représenté par la figure 4.1. SecureUML est défini comme une extension du méta-modèle UML. Les concepts de RBAC (Role Based Access Control) sont représentés directement en tant que artefacts de méta-modèle. Les auteurs ont introduit neuf concepts dans le méta-modèle. Parmi ces concepts on trouve l’utilisateur, le rôle et l’autorisation ainsi que les relations entre eux. SecureUML est également représenté sous forme de profil UML avec les mécanismes d’extension en utilisant les stéréotypes.

Figure 4.1 — Représentation du méta-modèle de secureUML comme décrit par Bassin

et al [Lodderstedt et al.,2002]. Il s’agit d’une extension du méta-modèle UML avec les concepts de RBAC

De leurs côté, Christian Wolter et al. [Wolter et al.,2008], [Wolter et al.,2009] définissent des politiques, de haut niveau, pour assurer des objectifs de sécurité comme l’authentifica-tion et la confidentialité dans les architectures orientées services. Les objectifs de sécurité ont été représentés avec des notations graphiques dans des modèles de processus métier dans le but de transformer les exigences de sécurité en politiques de sécurité concrètes. Comme résultats de ce premier travail, les auteurs ont proposé le modèle nommé "Security Policy Model"(figure4.2). Ce modèle est capable d’assurer différentes exigences de sécurité comme l’authentification ou le contrôle d’accès.

Figure 4.2 — Représentation du méta-modèle de secureUML comme décrit par Bassin

et al [Lodderstedt et al.,2002]. Il s’agit d’une extension du méta-modèle UML avec les concepts de RBAC

liée aux entités concernées. L’entité de base dans un modèle de politique de sécurité est un objet. Un objet est défini comme une entité capable de participer à une interaction avec d’autres objets. Cette interaction peut impliquer un ensemble d’informations qui sont échan-gée set elle aura toujours un effet, qui peut être composé à partir du changement d’état d’un objet ou d’informations dans un système. L’effet peut, mais ne doit pas nécessairement, être lié à l’objet qui a initié l’interaction. Par exemple, un objet pourrait être une application et un autre objet pourrait être un service pour stocker les données. Le processus d’accès à ce service serait l’interaction résultante dans laquelle les données sont stockées ou une infor-mation est renvoyée à l’application. Après avoir défini ce modèle de politique de sécurité ainsi que des modèles de contrainte de sécurité, comme le modèle de contraintes d’auto-risation, les auteurs génèrent des politiques avec le standard "eXtensible Access Control Markup Language" (XACML). Ils produisent aussi une configuration de sécurité pour les services Web "Apache-axe2". Le modèle de politique de sécurité met en correspondance les besoins de sécurité avec les modèles de contraintes de sécurité.

Dans plusieurs de leurs travaux, Fumiko Satoh et al. [Satoh et al., 2006],[Satoh et al., 2008b], [Satoh et al.,2008a], [Satoh et Yamaguchi,2007] proposent des solutions génériques pour le développement d’applications sécurisées en se basant sur la sécurité dirigée par les modèles. Dans [Satoh et al.,2006], ils introduisent des annotations de sécurité pour définir les exigences de sécurité dans les modèles du système logiciel. La politique de sécurité pour l’authentification est générée en respectant la norme "WS-Security Policy" en utilisant un modèle d’infrastructure de sécurité appelé " Security Infrastructure Model "(SIM). Ce mo-dèle contient les mécanismes de sécurité pris en charge par la plate-forme cible. Pour gérer la transformation de modèles, ils utilisent des templates prédéfinis pour atteindre les objectifs de sécurités requis. En utilisant ces templates, ils sont en mesure de générer des politiques de sécurité exécutables pour chaque exigence de sécurité.

Les mêmes auteurs proposent une approche visant la génération des configurations de sécurité pour IBM WAS [Satoh et Yamaguchi, 2007]. Ce travail touche la mise en corres-pondance directe entre "IBM-WAS Deployment Descriptor (DD)" et WS-Security Policy. Les

auteurs proposent l’utilisation d’un modèle de mise en correspondance ou de transforma-tion intermédiaire. Ce modèle permet à une politique de sécurité d’être transformée en une variété de configurations, y compris IBM WAS DD. Cette approche a été reprise dans [Satoh et al.,2008b] et [Satoh et al.,2008a], dans lesquels les mêmes auteurs ont pris pour cible la composition sécurisée du Service Component Architecture Composites (SCA) [OSOA] en utilisant SCA framework.

Parmi les travaux fondamentaux qui touchent le domaine de la sécurité dirigée par les modèles, on trouve aussi ceux de Jan Juerjens et. al. [Juerjens, 2002], [Juerjens, 2003], [Best et al.,2007]. Ces auteurs proposent une extension du standard UML pour la validation des protocoles de sécurité appelés UMLsec [Juerjens,2002]. La figure4.3présente une des-cription détaillée des différents stéréotypes proposés. Étant donné qu’UMLsec est un profil UML, il définit la sécurité en utilisant des valeurs marquées et des contraintes associées aux éléments du méta-modèle. Un certain nombre de risques (delete, read, insert, access pour les liens) et de types d’éléments (un lien de type Internet supporte les risques delete, read, insert ; un lien de type encrypted ne supporte que le risque delete) sont prédéfinis. Il définit aussi des contraintes sur les éléments exprimant les règles de fonctionnement et la politique de sécurité, qui permettent l’évaluation des aspects sécurité d’une conception du système.

Figure 4.3 — Un extrait du profil UMLsec proposé par Jan Juerjens et.al [Juerjens,2002].

L’idée dans UMLsec est que les protocoles ou les mécanismes de sécurité ne doivent pas être insérés à l’aveuglette dans les systèmes, mais les aspects de la sécurité devraient être pris en compte dans le processus global de développement du système. Cela implique l’obli-gation de considérer la sécurité depuis la définition des exigences jusqu’à la mise en ?uvre (déploiement). Les auteurs prennent en compte les différents types de modèles UML à diffé-rents niveaux d’abstraction pour capturer les aspects de sécurité. L’idée est qu’un dévelop-peur d’applications, qui n’est pas un expert en sécurité pourrait utiliser ces modèles comme guide pour connaître les risques de sécurité et les vulnérabilités à différents stades de

déve-loppement de son système. Des exemples de diagrammes UML ont été illustrés dans leurs travaux comme le diagramme de classes UML (définition des niveaux de sécurité pour les attributs et les fonctions), le diagramme d’état transition (sécurité des flux d’information), le diagramme de séquence (sécurité des messages pour échanger des données) et le dia-gramme de déploiement (étiquettes de sécurité sur les composants de système physique). Cependant, les auteurs ne tiennent pas compte du raffinement successif des modèles ni de la génération du code.

De leur côté Michael Hafner et Ruth Breu [Hafner, 2006], [Hafner et al.,2006] ont pro-posé un framework appelé SECTET pour l’ingénierie de la sécurité dirigée par les modèles. Afin d’utiliser ce Framework, ils ont proposé un langage de définition de politiques appelé SECTET-PL. Ce langage permet la définition des exigences de sécurité dans les modèles fonctionnels. Les politiques de contrôle d’accès abstraites sont décrites en SECTET-PL, et sont ensuite transformées en code XACML [M. Alam et Unterthiner, 2007], [Alam et al., 2009]. Dans cette approche, semblable à l’approche de David Basin [Basin et al.,2006], [ Lod-derstedt et al.,2002], la politique abstraite est directement convertie en code, ce qui signifie que l’expert du domaine doit avoir une connaissance suffisante de la sécurité pour utili-ser ce framework, dès les premières phases du développement du système, dans le modèle fonctionnel. Les principales contributions des travaux autour de SECTET sont : un langage spécifique au domaine appelé SECTET-DSL (utilisé pour modéliser des workflows inter-organisationnels), et le langage de définition de politique SECTET-PL [Hafner et al.,2005a], [Hafner et al.,2005b].

Pour Ulrich Lang et al. [Reznik et al.,2007], [Lang et Schreiner,2002], l’expert en sécurité doit définir la politique de sécurité de haut niveau et générer le code correspondant. Dans cet article, ces auteurs proposent un middleware spécifique appelé SecureMiddleware. Ce middleware étend le modèle de composant CORBA avec différentes propriétés non fonc-tionnelles comme la sécurité ou la reconfiguration. Les politiques de haut niveau sont spé-cifiées dans un langage de définition de la politique (Policy Definition Language (PDL)). L’approche par composants utilise des QoSEnablers, qui sont responsables d’assurer un type spécifique de Qualité de Services(QoS) tels que la sécurité. Les QoSEnabler renforcent les politiques de contrôle d’accès dans le middleware. Dans cette approche, la transforma-tion ainsi que la mise à jour est effectuée par un OpenPMF (Policy Management Frame-work).Pour simplifier le développement d’applications à base de composants CORBA, un sous-ensemble d’UML appelé eUML et un profil de politique de sécurité appelé eUML-Sec ont été proposés. Le méta-modèle eUML contient deux packages principaux, Générique et Présentation, comme le montre la figure ci-dessous (figure 4.4). Le premier paquetage couvre la partie de modélisation générique (basé sur le méta-modèle UML 2.0) et le second comprend des concepts supplémentaires, qui définissent des informations de modélisation graphique d’un élément UML ainsi que le diagramme UML qui en résulte.

Cependant, cette approche s’adresse uniquement aux applications à base de composant CORBA. La généricité de l’approche proposé sur d’autres modèles de composants n’est pas explicitée. Le profil généré est également limité pour le modèle à composant CORBA. Ces différentes restrictions limitent la portée de cette démarche.

Figure 4.4 — Aperçu du métamodèle eUML proposé par Ulrich Lang et al. [Reznik et al.,

2007].