Approche globale de protection

3.2 Approche globale de protection

Dans cette partie, nous proposons une approche globale de protection obligatoire des serveurs d’application Web. Cette approche doit répondre à deux contraintes principales : la solution de protection obligatoire doit être suffisamment fine tout en étant simple à administrer. Elle fait donc intervenir deux composants principaux, résolvant chacun une de ces deux contraintes. De plus, notre approche globale de protection obligatoire permet de contrôler les actions des sujets sur les objets tels que définies dans notre modèle général de serveur d’application Web, c’est pourquoi celui-ci a été défini en premier.

Avantage de l’approche

Tout d’abord, notre approche de protection obligatoire permet de contrôler précisément les accès des clients aux objets hébergés par un serveur d’applications Web. Pour cela, nous avons proposé dans la partie 3.1 un modèle de représentation abstrait des serveurs d’ap-plications Web s’adaptant au caractère extensible du Web. Notre approche de protection obligatoire utilise ce modèle pour obtenir une représentation fine des sujets et des objets intervenant dans l’ensemble des requêtes HTTP entrantes sur le serveur d’application Web.

La protection obligatoire dynamique est, dans notre approche de protection obligatoire, le composant chargé d’appliquer sur le serveur les règles d’autorisations présentes dans la politique de sécurité.

Figure 3.4 – Approche globale de protection.

De plus, pour répondre à la contrainte de facilité d’administration de la protection obligatoire, nous proposons une méthode de calcul des politiques de sécurité pour les applications hébergées sur un serveur Web. Cette méthode permet de calculer une politique de sécurité à partir d’un modèle spécifique d’application Web et d’un modèle spécifique de workflows proposés ensuite. Dans notre approche, le calculateur de politique est le composant qui calcule et fournit au mécanisme de protection obligatoire dynamique la politique à appliquer sur le serveur d’applications Web.

La figure 3.4 présente notre modèle global de protection d’un serveur d’applications Web.

3.2.1 Protection obligatoire dynamique

Le rôle principal de notre protection obligatoire est de décider, pour chaque action d’un sujet sur un objet du serveur, si celle-ci est légitime vis-à-vis de la politique de sécurité à

3.2. APPROCHE GLOBALE DE PROTECTION

appliquer.

La politique de sécurité appliquée sur un serveur Web représente l’ensemble des accès, d’un sujet sur un objet du serveur, autorisés sur ce serveur. Tout accès non exprimé dans la politique de sécurité est automatiquement rejeté. Les règles d’accès sont exprimées au moyen d’un langage de protection dédié et de bas niveau qui permet de représenter différents types d’accès tout en étant extensible pour s’adapter à des modèles spécifiques d’application Web.

Notre protection obligatoire doit donc fournir un mécanisme permettant d’empêcher qu’une action non autorisée par la politique de sécurité ne soit effectuée. Pour chaque requête HTTP entrante sur le serveur Web, le mécanisme de protection doit déterminer le type d’action requise et doit également définir les contextes de sécurité sujets et objets relatifs à la requête entrante. Ainsi, un ensemble de règles potentielles d’accès est calculé dynamiquement à chaque requête, et celles-ci sont comparées à la politique de sécurité pour décider de l’autorisation ou de l’interdiction de l’accès demandé.

Cependant, notre protection obligatoire est indépendante des applications qu’elle contr-ôle sur le serveur. Elle laisse libre l’application protégée pour la façon de définir les sujets.

Par exemple, ceux-ci peuvent être stockés par les applications dans les sessions utilisateurs, dans le cache applicatif ou encore dans une base de données. Ainsi, notre modèle introduit pour chaque application du serveur un adaptateur applicatif qui assurera la liaison entre la protection obligatoire et les applications du serveur.

Adaptateur applicatif

L’adaptateur applicatif est chargé de calculer, pour une requête entrante sur le ser-veur d’application, les valeurs des paramètres permettant de représenter le contexte de sécurité sujet relatif à cette requête. Celui-ci est fourni par chaque application protégée, qui définit librement sa propre notion de sujet. Il est donc capable de calculer les infor-mations nécessaires au calcul du contexte de sécurité sujet. L’adaptateur applicatif doit fournir des méthodes pour permettre au moniteur de référence d’obtenir les informations lui permettant de calculer le contexte sujet associé à la requête.

Lors d’une requête entrante, le moniteur de référence interroge l’adaptateur applicatif en lui fournissant l’état de la requête entrante. L’adaptateur lui retourne la liste des para-mètres identifiant le sujet associé à cette requête. Le moniteur de référence peut calculer les contextes de sécurités sujets associés à cette requête et prendre la décision d’autorisation de l’action requise.

3.2.2 Calculateur de politique

Nous proposons un calculateur de politique de protection obligatoire qui fonctionne en deux étapes.

Tout d’abord, nous définissons un modèle spécifique d’application web qui permet de définir un modèle d’accès spécifique proche du langage d’expression des politiques mais qui impose quatre niveaux de structuration (applications, services, fonctionnalités, ressources) pour l’application contrairement au modèle général qui n’en présente que trois. L’avantage conceptuel de ce modèle d’application spécifique est de pouvoir être projeté sur notre modèle général d’application tout en respectant l’approche proposée par SOA. En ce sens, notre modèle spécifique d’application peut être vu comme une simplification du modèle SOA.

3.2. APPROCHE GLOBALE DE PROTECTION

L’intérêt est que, le modèle d’accès spécifique étant proche de notre langage de protec-tion, ce modèle d’accès spécifique permet de calculer automatiquement les règles d’accès tout en restant de haut niveau et donc plus facilement analysable. Ce modèle d’accès spéci-fique peut être comparé à un langage d’assemblage vis-à-vis d’un langage binaire exécutable qui lui est comparable à notre langage de règles. Il est clairement plus simple d’analyser et d’utiliser un langage d’assemblage que d’analyser et de comprendre un binaire. De même dans notre cas, il est plus simple d’analyser et de comprendre notre modèle d’accès spéci-fique que les règles d’accès de bas niveau exprimées dans notre langage (proche d’un jeu d’instruction d’un processeur de contrôle d’accès).

Ensuite, nous proposons un modèle d’accès spécifique de workflow qui peut être pro-jeté sur notre modèle d’accès spécifique. L’avantage conceptuel de ce modèle d’accès spé-cifique de workflow est de respecter les principes rencontrés dans de nombreux logiciels de workflows tout en étant proche de BPEL/XPDL. Ainsi, ce modèle d’accès spécifique de workflow peut être vu comme une simplification de BPEL/XPDL. L’intérêt pratique est de permettre d’automatiser complètement le calcul de la politique pour les systèmes de work-flows. Ainsi, nous obtenons à moindre effort une politique de contrôle d’accès obligatoire qui respecte parfaitement le workflow défini. Nous évitons ainsi de nombreuses attaques basées sur le manque de contrôle d’accès et leurs fragilités.

Le calcul des politiques est ainsi automatisé en deux temps. Dans un premier temps, le modèle d’accès spécifique de workflow issu des environnements de workflows est projeté automatiquement sur notre modèle spécifique d’accès. Dans un second temps, notre modèle spécifique d’accès d’application ainsi calculé est projeté automatiquement sur une politique au moyen de notre langage de règles.