Sommaire
Edito
Tribune
Temps fort
Succès
Paroles d'experts
Solutions
Sondage Express
Agenda
En bref
Version PDF
 

Abonnez-vous à
Bull Direct :

Votre email

Archives
Mai 2006
Parole d'expert

La sécurité des services Web : défis et perspectives
Par Pierre Caubit, architecte sécurité, Bull Services

Dans le cadre du programme ITEA (Information Technology for European Advancement), Pierre Caubit a dirigéla partie sécurité de LASCOT (LArge Scale COllaborative decision support Technology), une plate-forme middleware d’aide à la décision en situation de crise, destinée aux grands industriels ou services publics gérant des risques. Il intervient comme architecte et expert sur de grands projets de sécurité en Europe.

A l’heure où les systèmes d’information (SI) doivent gagner en ouverture et flexibilité, les architectures SOA (Service Oriented Architecture) sont devenues un axe d’évolution technologique majeur. Leur principe est simple, même si l’implémentation peut être complexe : découper les applications en services d'entreprise, c'est-à-dire constituer un portefeuille applicatif de services (ex : commande, demande d’achat, calcul de prix, etc.) que l'on peut agréger et recombiner simplement, selon les besoins métier. Les atouts : faciliter la valorisation systématique du patrimoine applicatif et simplifier les échanges entre des environnements hétérogènes. On peut ainsi « réutiliser » ce qui a déjà été défini et déployé, afin de réduire les coûts d'intégration et d'améliorer la réactivité face à l'évolution des besoins métiers. Non seulement en interne, mais aussi vers les partenaires, les fournisseurs, les clients, etc.
Le socle de spécifications techniques pour exposer ces services est celui des services Web. Si ces évolutions offrent beaucoup de perspectives, elles créent aussi de nouveaux risques. D’où de nouveaux besoins de sécurité en matière de disponibilité, intégrité, confidentialité et preuve.

Bull s’est impliqué dans cette évolution fondamentale dès l’émergence de ces nouveaux concepts, au début des années 2000. Outre des études et expérimentations de sécurisation d’échanges SOAP basés sur les premiers ‘drafts’ des standards XML pour de grandes banques, l’effort central de Bull a été accompli par la réalisation d’une infrastructure de sécurité XML dans le cadre du projet LASCOT du programme européen ITEA, permettant de bâtir une infrastructure ouverte, adaptable facilement à tout contexte. En s’appuyant sur ces technologies, un des objectifs majeurs de Bull est d’aider ses clients à déployer des infrastructures middlewares SOA sécurisée sous Java, en utilisant des briques technologiques ouvertes et sûres.

Les Web Services ouvrent une nouvelle dimension de simplicité dans l’implémentation de processus complexes. Gages de systèmes d’information plus flexibles, ils permettent une véritable révolution conceptuelle dans la définition des 'applications'. Celles-ci vont ainsi pouvoir progressivement se ‘virtualiser’ en de multiples Web Services distribués, entraînant en même temps la virtualisation des systèmes d’information eux-mêmes.

Web Services : une architecture souple
Les services Web permettent de déployer des applications distribuées exploitant des composants distants et hétérogènes. L'architecture technique associée, toujours en cours de normalisation, est fondée sur un modèle en couches : transport, découverte des services, échange et communication, description de processus complexes, contrats, etc. À chaque couche sont associés des langages de description spécifiques, basés sur le standard XML (eXtended Markup Langage). Simple et extensible, ce dernier s'est imposé comme le standard pour le déploiement de services Web, grâce à sa plus grande souplesse par rapport aux anciennes méthodes de description de composants proposées par DCOM et Corba.
La mise en oeuvre des services Web repose sur le modèle classique de publication (publish), localisation (find) et appel (bind) de composants distribués. Les requêtes et les données échangées entre services sont véhiculées grâce au protocole SOAP. Compatible avec de nombreux protocoles de transport (HTTP, SMTP, POP3, FTP, etc.), SOAP véhicule des appels de procédures distantes exprimés en XML: adresse du destinataire, nom de la procédure à exécuter et paramètres attendus et retournés.

service Web

Les services Web accessibles sur un réseau sont décrits grâce au service WSDL. S'appuyant comme SOAP sur XML, WSDL permet de décrire l'interface d'accès aux services Web à laquelle il n'impose aucune installation de contenu (EJB, servlets, composants DCOM).
La localisation dynamique des services Web est enfin facilitée par le standard UDDI, qui permet de construire des services d'annuaires privés dont l'utilisation est limitée à un ensemble clairement identifié d'entreprises susceptibles de s'échanger des services applicatifs: Intranet, Extranet, applications de type B-to-B. Réparti sur les sites de multiples fournisseurs, cet annuaire offre une vue logique des services disponibles. UDDI s'appuie également sur XML pour décrire les informations permettant de publier et de localiser chaque service.

De nouvelles exigences de sécurité
En même temps qu'une indispensable ouverture, les Web Services introduisent de nouveaux risques de sécurité. Cette évolution profonde fait naître un besoin fondamental : garantir la confiance que l'on peut accorder au fournisseur de services dans ce type de relations.
En particulier, il convient d'établir un véritable « contrat de service » officialisant la relation de confiance à instaurer entre une entité cliente et une entité fournisseur de services. Ce contrat de service précisera le type de service attendu par le client, les éléments d'identification (identification de l'entité client, identité de l'application client, caractéristiques de l'application cliente), que les applications du client seront capables de présenter afin que le fournisseur puisse déterminer le niveau d'accès à ses ressources. Clients et fournisseurs devront adapter leurs solutions de sécurité existantes pour atteindre le niveau de service attendu.

modéle sécurité

SAML, le standard de sécurité pivot pour l’authentification et l’autorisation d’accès

Un tel modèle de sécurité est proposé par le standard de sécurité logique SAML (Security Assertion Markup Language) proposé par le groupement OASIS (Organization for the Advancement of Structured Information Standards).

SAML apporte une approche novatrice et essentielle en séparant la gestion des demandeurs et des ressources, en déléguant la gestion des utilisateurs et des applications clientes à leur entité de rattachement et en proposant un nouveau modèle de contrôle d'accès aux applications.

SAML définit des structures de sécurité présentées comme preuves (on utilise le terme d'assertions), ainsi que le protocole d'échange qui permet de solliciter et délivrer ces assertions. En outre, la dernière version du standard SAML (version 2.0 de mars 2005) intègre les principes et les mécanismes de fédération/dé-fédération d'identité préconisés par Liberty Alliance.
L'objectif principal de SAML est de spécifier un modèle de sécurité attendu par les Web Services. Cependant, SAML étant un standard de haut niveau, il est aussi utilisable dans un environnement HTTP 'classique'. Dans ce cas, il permet d'authentifier un utilisateur et assure l'identification unique (SSO ou Single Sign-On).

Des standards complémentaires
Outre SAML, d'autres spécifications viennent compléter ce standard pivot, tels que WS-Security, XACML, XKMS, XML-Signature, etc. Notamment, les contrôles et les décisions d'accès peuvent être assurés par des mécanismes propriétaires ou bien peuvent utiliser le protocole et l'assertion d'autorisation SAML et les mécanismes de décision spécifiés par le standard XACML (eXtensible Access Control Markup Language).

  • WS-Security, propagation des éléments de sécurité des W.S. - WS-Security vise à assurer la compatibilité des éléments de sécurité échangés par les Web Services. La structure WS-Security se place dans l'entête des messages SOAP.
  • XACML, description des politiques d’accès aux ressources - La finalité de l'authentification du client est de permettre l'autorisation d'accès à des ressources sur des critères sûrs. Après l’habilitation individuelle, puis les groupes d’utilisateurs, on a vu apparaître l’utilisation des rôles portés par le modèle RBAC (Role based Access Control). L'évolution introduite par SAML propose une généralisation du concept de rôle et a démontré sa réelle efficacité opérationnelle. Il s'agit d'utiliser l'ensemble des caractéristiques de l'utilisateur comme critères d'habilitation. Dans la lignée des nouveaux standards de sécurités, OASIS propose XACML pour décrire les règles d'accès aux ressources de manière standard, en XML. Ce standard ne concerne pas l'interopérabilité entre organisations indépendantes mais vise à assurer la portabilité et la pérennité des politiques de contrôle d'accès décrites et utilisées dans une organisation. XACML apporte une puissance de description des règles d'accès hors de portée des solutions classiques.
  • XKMS, gestion simplifiée des certificats numériques - Les nouveaux standards de sécurité s'appuient la signature voire le chiffrement numérique des structures XML échangées. Ces opérations s'appuient essentiellement sur l'utilisation des algorithmes de clés asymétriques et les certificats X509 associés. XKMS (XML Key Management Specification) vise à simplifier et généraliser la gestion des clés numériques classiquement effectuée par des PKI (Public Key Infrastructure) afin d'accélérer le déploiement des applications et processus qui utilisent ce type de service. XKMS spécifie des relations de confiance basées sur des clés, leur certification, leur vérification, etc.
  • XML-Signature & Encryption - Signature et chiffrement numérique des structures XML - La signature numérique et les éléments associés au chiffrement d’une structure sont décrits dans des structures XML standardisées. Cette standardisation permet à tout récepteur de vérifier une signature numérique et à tout destinataire de déchiffrer une information qui lui est destinée. Il s’agit d’assurer l’interopérabilité des opérations de signature et de chiffrement.

Les schémas suivant démontrent la cohérence de ces standards, et leur interdépendance fonctionnelle et technique. Il s'agit d'une chaîne cohérente de services, chaque niveau (maillon) nécessitant le niveau inférieur (maillon inférieur).

cohérence des standards

interdépendance des standards

Sécurité des Web Services : de nouveaux défis
Un des grands défis de ces nouveaux standards de sécurité est de parvenir à les traduire en solutions homogènes. La constitution d’une solution simple et efficace demande une maîtrise technique et une capacité de synthèse certaines.
L'infrastructure de sécurité doit en effet simplifier la sécurisation des applications Web accédées par les utilisateurs depuis des navigateurs et assurer la gestion globale de la sécurité par des administrateurs qui ne sont pas des spécialistes de tel ou tels environnement (Java, ...). Une implémentation efficace doit ainsi être capable de masquer la technique, à la fois aux applications qui l'utilisent et aux administrateurs de sécurité.

  • Assurer un contrôle de sécurité non intrusif. Selon Bull, le principal défi que doivent relever les infrastructures de sécurité est de rendre simple, voire transparente la mise en œuvre des nouveaux standards de sécurité XML. Nous estimons en effet que l'adoption de ces standards par les administrations et les entreprises sera d'autant plus rapide que leur mise en œuvre sera aisée et ne perturbera pas les applications déjà en place.
  • Automatiser la gestion des certificats. La sécurité des Web Services repose sur la signature numérique des structures XML échangées. Cette signature exploite les techniques de cryptographie à clés symétriques et les certificats numériques x509. La sécurité repose sur la solidité des techniques utilisées pour générer et conserver les clés ainsi que sur l'efficacité de la gestion et du contrôle des certificats numériques utilisés. L’automatisation efficace de ces opérations est essentielle.
  • Simplifier l’administration de la sécurité. La mise à disposition d'une administration unifiée et intuitive ainsi que de fonctions de supervision est indispensable. Le succès de la mise en place des nouveaux services de sécurité dépendra essentiellement de la simplicité et de l'efficacité de ces outils.

Bull : une architecture de sécurité XML avancée
Bull a mené plusieurs projets de R&D pour répondre à ces problématiques. Ces travaux ont d’ailleurs débouché sur la conception et l’intégration de diverses solutions, disponibles aujourd’hui d’une part au travers du module ‘Secure Access Manager - J2EE Edition’ de sa filiale Evidian, et d’autre part au travers d’un framework modulaire adaptable à tout type d’environnement client. Ce framework est porté par Bull Services dans le cadre de projets d’intégration spécifiques.
Ces solutions permettent notamment de répondre aux trois défis mentionnés précédemment :

  • Assurer un contrôle de sécurité non intrusif. Les mécanismes de sécurité implémentés par Bull, basés sur Java J2EE et sur les standards XML, permettent d'assurer le contrôle d'accès aux applications sans interférer avec elles. Il s'agit de mécanismes non intrusifs dont peuvent bénéficier les contrôles de sécurité. Ainsi, les applications n'ont pas à développer de fonctions particulières pour assurer leur sécurité ou même à appeler des fonctions particulières de sécurité. Elles peuvent être 'posées' sur leur infrastructure applicative sans se préoccuper des problématiques de sécurité.
  • Automatiser la gestion des certificats. Pour ce faire, Bull a conçu des modules logiciels qui intègrent et étendent les possibilités offertes par les serveurs XKMS : d’une part des mécanismes simplifiés de génération, révocation, renouvellement, vérification de certificats, de manière à assurer la continuité de service des composants de sécurité et des applications et d’autre part des mécanismes de génération de paires de clés et de conservation des clés privées dans des environnements protégés (qui peuvent être des dispositifs matériels spécialisés).
  • Simplifier l’administration de la sécurité. Enfin, Bull met en œuvre un serveur de configuration qui permet d'administrer les caractéristiques de chaque composant à partir du référentiel central de sécurité. Ce mécanisme permet un déploiement et une gestion très simplifiés de l’ensemble des composants de l’infrastructure. Ainsi, l'installation initiale d'un composant de sécurité nécessite un minimum d'information : identité, code d'accès, point d'accès à un serveur de configuration. Les informations détaillées de configuration sont reçues du serveur de configuration.

L'objectif des infrastructures de sécurité ainsi conçues est d’assurer l'intéropérabilité des couches fonctionnelles de sécurité équivalentes, d’assurer l'intégration des différentes couches de sécurité, et de mettre en oeuvre une administration de la sécurité qui offre une vision cohérente et maîtrisable de la sécurité

Le schéma suivant présente l'architecture générale de sécurité XML de Bull et de ses principaux composants.

architecture globale

Des implémentations par Bull de ces standards de sécurité émergeants ont été conduites dans le cadre de plusieurs projets. Outre la dimension recherche menée dans le cadre d’ITEA (projet LASCOT), différentes études de conseil en matière de sécurité des SI et des Web Services ont été menées auprès de grands ministères et de la DCSSI ces trois dernières années. Des implémentations avancées ont notamment été réalisées pour l’évolution de la solution de sécurité Cerbère du Ministère de l’Equipement vers SAML et WS-Security. Bull a en outre développé depuis 2002 un partenariat avec Deutsche Post pour l’introduction progressive de ces nouveaux principes dans son infrastructure de sécurité orientée Web Services, une des plus ambitieuses en Europe, avec l’offre Evidian Secure Access Manager – J2EE.

Ces technologies de sécurité ont aussi été placées au coeur de BSOA, la plate-forme middleware applicative Java intégrée de Bull, à base de composants du monde libre (JOnAS, …) et de composants spécifiques. Une plate-forme particulièrement ouverte pour assurer la conception, le développement, le déploiement, l'administration d'une Architecture Orientée Services (SOA). L’objectif : mettre en œuvre dès aujourd’hui le meilleur des nouvelles technologies de demain, de manière très flexible et pragmatique et s’appuyant sur des solutions ouvertes et modulaires.

En matière de R&D et à la suite de son projet LASCOT et de ses travaux dans le cadre de l’ITEA, Bull conduit en outre des réflexions afin d’évaluer l’apport de techniques sémantiques (Web Sémantique et ontologies) pour faciliter la mise en œuvre de ces nouvelles technologies.

C’est un enjeu majeur pour les prochaines années. En effet, les nouveaux projets lancés par les administrations (projets de e-gouvernement) font de plus en plus état d’échanges avec des partenaires indépendants (autres administrations, organismes divers, etc.) et souhaitent dans ces conditions s’appuyer sur des mécanismes reconnus capables de supporter cette ouverture. Dans cette démarche, l’utilisation des Web Services et de mécanismes capables d’assurer leur sécurisation est le plus souvent exigée. La réponse apportée à cette attente doit privilégier l’efficacité fonctionnelle et l’adaptabilité de la solution proposée. La composante sécurité, bien qu’indispensable, ne doit pas imposer une surcharge significative du déploiement et de l’administration de la solution. Les opportunités technologiques que constituent l’infrastructure Internet, XML, les Web Services et les analyses sémantiques devraient favoriser l’automatisation et la fiabilisation des processus techniques.

 

Glossaire

    SAML            
    SOAP            
    SSL               
    TLS               
    UDDI             
    XACML          
    XKMS                  
    XML 
                 

Security Assertion Markup Language
Simple Object AccessProtocol
Security Socket Layer
Transport Layer Security
Universal Description, Discovery, and Integration
Extensible Access Control Markup Language
XML Key Management Specification
Extensible Markup Language

 

 

 

 

 

 

 

Contact  |  Site map  |  Legal  |  Privacy