Déploiement de politiques de sécurité pour systèmes d’information orientés service

Déploiement de politiques de sécurité pour systèmes d’information orientés service

Les architectures orientées service offrent aux entreprises un nouveau modèle pour construire leurs applications IT autour de leurs processus métiers et de les combiner dynamiquement et de manière flexible avec les services d’entreprises partenaires. Ce nouveau paradigme nécessite cependant de repenser la sécurité des applications pour un cadre ouvert et distribué. Dans cet article nous décrivons quelques éléments typiques d’une architecture de sécurité d’un système SOA en illustrant notamment l’emploi de composants typiques tels que PEP et PDP (Policy Enforcement Point et Policy Decision Point) dans le contexte de plusieurs projets menés au CETIC.

La sécurité comme service

Durant la décennie passée, la généralisation du réseau Internet et la croissance importante de sa bande passante a engendré un changement de paradigme dans l’architecture des applications IT. Précédemment structurée sur une logique « client-serveur », les nouvelles architectures sont « orientées-service », c’est-à-dire combinant de manière contrôlée une série de services disponibles dans un environnement distribué ouvert. Les avantages sont nombreux en termes de réutilisabilité, dynamicité, flexibilité ou encore d’évolution. Cependant en terme de sécurité, le bouleversement est important, comme l’illustre la figure 1. Les frontières du système auparavant bien délimitées (en haut : le client, le serveur et le canal de communication) deviennent beaucoup plus ouvertes (en bas : services multiples, inconnus à l’avances, communications multiples entre services et avec les utilisateurs).

Fondamentalement les enjeux restent les mêmes : authentifier les utilisateurs, gérer les autorisations, assurer l’intégrité et la confidentialité des données (notamment en ce qui concerne le respect de la vie privée), imposer un caractère non répudiable aux actions réalisées. Cependant à l’image des architectures SOA, la sécurité ne peut plus être assurée par l’application de manière statique et centralisée : elle doit être fournie comme service.

Changement de paradigme de sécurisation

Dans cet article nous examinerons plus particulièrement les services permettant de gérer les autorisations en exploitant un modèle de politique classique illustré à la figure 2. Lorsqu’un utilisateur veut accéder à une application protégée, la demande est interceptée par le Policy Enforcement Point (PEP). Les informations relatives à l’utilisateur identifié, l’application demandée, les ressources concernées et plus largement le contexte (par exemple l’heure) sont capturés. La demande d’autorisation est transmise au Policy Decision Point (PDP) pour décision. Si l’utilisateur est autorisé suivant les règles définies, le PDP le signale au PEP qui lui accorde l’accès et communique les « credentials » pertinents. Dans le cas contraire, le PEP est aussi averti et aucun « credential » n’est alors communiqué.

Principe du PEP/PDP (tiré du site be-health)

Un exemple d’application : l’infrastructure de service 3WSA

Le projet 3WSA (Wallonia World Wide Space Application) est un projet du pôle aéronautique et spatial Skywin du Plan Marshall wallon. Le projet concerne le développement et la mise en oeuvre de moyens techniques mariant les nouveaux outils des Technologies de l’Information et de la Communication avec les infrastructures existantes et futures de l’Espace (en particulier GALILEO et GMES), afin de répondre aux besoins des décideurs et des citoyens dans les domaines de la sécurité, de l’environnement, de la mobilité, et de la gestion des ressources naturelles.
Au niveau technique, il s’agit de déployer une plateforme orientée service permettant d’orchestrer une série de services géomatiques issu de divers fournisseurs pour produire des chaînes de traitement à haute valeur ajoutée telle que la surveillance de site SEVESO, de ressources naturelles, etc.

D’un point de vue de la sécurité une sécurisation se révèle indispensable pour de multiples raisons :

  • Authentification et contrôle d’accès : seuls les utilisateurs enregistrés de la plateforme ont un accès à l’ensemble des services qui ont été accordés en fonction de leur profil.
  • Confidentialité : des garanties doivent être fournies pour assurer la non-divulgation des données fournies à la chaîne de traitement distribuée, potentiellement sensibles d’un point de vue économique (concurrence) ou de sécurité (emplacement de site spécifiques)
  • Modèle commercial : un modèle de tarification est associé à l’utilisation des services et ceux-ci ne sont accessibles que moyennant le respect du contrat établi. Par exemple une limite de quota peut être imposée relativement à l’utilisation des services.

Dans ce cadre, un schéma PEP/PDP peut être déployé au niveau :

  • de la plateforme d’orchestration qui est le point d’entrée de l’utilisateur et qui permet d’assurer les contraintes globales de sécurité
  • en aval de celle-ci au niveau de chacun des services, donnant une possibilité de contrôle aux gestionnaires de chaque service qui peut par ailleurs aussi donner accès à d’autres intégrateurs.

Au niveau de la spécification des politiques, le langage XACML est approprié car il permet de spécifier des règles et de combiner des règles complexes portant sur l’identité (transmise lors de la requête entrante via un protocole de type SAML), le type de service, la période d’accès, des attributs des ressources manipulées, etc. Par exemple la politique suivante précise que les utilisateurs normaux peuvent accéder à la plateforme entre 9h et 18 et on une limite de ressources à 2,5% des ressources disponibles.

PNG - 245.2 ko
Exemple de politique XACML

Il existe par ailleurs une extension en cours de développement appelée GeoXACML et qui permet de spécifier des politiques d’accès relatives à la teneur des images manipulées. Par exemple : seul un utilisateur accrédité par l’organisation de contrôle de sites SEVESO à le droit d’accéder à un contenu traité en haute résolution de ces sites. Les politiques permettent de marquer les zones sensibles et de les coupler avec l’identité.

Assurer la cohérence des politiques de sécurité au niveau du domaine et de l’infrastructure

La gestion des politiques dans un système ouvert peut rapidement devenir un casse-tête et résulter dans des défauts

  • au niveau de la sécurité : des politiques locales peuvent ne pas assurer une propriété globale de sécurité, permettant par exemple à certains utilisateurs d’accéder à des données qui ne devraient pas leur être accessibles
  • au niveau disponibilité : à l’inverse, des politiques locales trop strictes peuvent engendrer un refus d’autorisation d’accès à un utilisateur légitime.

Un objectif majeur du projet européen FP6 GridTrust était de mettre au point une méthodologie permettant de concevoir des politiques de sécurité globale et ensuite de dériver les règles de politiques locales nécessaires et suffisantes pour assurer la sécurité. La méthode se base sur la spécification de propriétés de haut niveau au niveau du système global, appelé « organisation virtuelle » (VO) et d’en dériver des politiques locales, notamment en XACML. Le projet a suivi une double approche, utilisable de manière complémentaire

  • une approche simplifiée sur des patterns de sécurité fréquents et réutilisables en les instanciant à un contexte particulier.
  • une approche plus formelle, offrant plus de garanties de sécurité, basée sur la spécification formelle de politiques et permettant la dérivation des règles XACML à déployer.
PNG - 59.9 ko
Simulateur de politiques

Perspectives

Les architectures orientées services amènent un important changement de paradigme dans la manière de concevoir les applications dans un environnement ouvert. Au niveau de la sécurité, une nouvelle approche s’avère nécessaire. Dans cet article, nous avons expliqué un des mécanismes permettant de réaliser un contrôle de l’accès basé sur des politiques de sécurité et l’avons illustré sur un projet SOA concret. Une seconde application est détaillée dans l’article relatif à aux activités du CETIC dans le workpackage ’sécurité’ du projet BEinGRID. Le CETIC compte déployer ces compétences dans le cadre du projet eHealth où de telles techniques sont déjà déployées et où une recherche sur les modèles de sécurité adaptés au contexte (ORBAC) est également nécessaire.

N’hésitez-pas à nous contacter par rapport à vos besoins sur ces thématiques.