En exposant des services web, l’entreprise permet à n’importe qui de manipuler ses applications directement depuis internet. D’autant que l’API de chaque service est parfaitement décrite dans un fichier WSDL. La mise en place d’un dispositif de sécurité et d’authentification est donc un enjeu capital.Proposée par IBM, Microsoft et Verisign, WS-Security permet à deux partenaires d’échanger des messages Soap en toute sécurité sur l’internet grand public en les cryptant à l’aide de XML Encryption, et en les signant à l’aide de XML Signature, de tickets Kerberos ou de certificat X509. Soutenu par l’Oasis, WS-Security propose de transporter le contexte de sécurité dans les en-têtes Soap afin de pouvoir authentifier et sécuriser le message. Mais les produits qui supportent cette spécification restent peu nombreux.
Risque majeur : le pillage des données
Pour l’heure, la majorité des projets applique donc les recettes des sites marchands aux services web. L’authentification est prise en charge au niveau applicatif (login et mot de passe), et les échanges sont sécurisés au niveau du transport. SSL fournit un premier niveau de confidentialité. Certaines sociétés, telles que B2Boost, renforcent ce dispositif à l’aide de certificats côté client. Ce mécanisme en place, les entreprises ne craignent plus les attaques traditionnelles. Le principal danger vient des pilleurs de données. Dans ce domaine, plusieurs approches permettent de limiter les risques. La première consiste à ajouter des règles dans son pare-feu et à filtrer les adresses IP pour ne laisser passer que ses partenaires. Malheureusement, “le filtrage sur adresse IP fixe complexifie le déploiement et la consommation des services web”, remarque Michaël Tartar, consultant chez Andersen. La seconde approche repose sur un filtrage des messages Soap en fonction de règles métier. On peut, par exemple, limiter le nombre d’appels possibles d’une méthode dans un laps de temps donné. Les premiers pare-feu dédiés à cette tâche sont récemment apparus chez des fournisseurs tels que Reactivity, Westbridge, Vordel ou Quadrasis.Coupe-feu et filtrage des paquets Soap sont toutefois inefficaces face à une attaque par déni de service, qui, dans le cas d’une interconnexion de composants applicatifs, peut avoir de lourdes conséquences. Heureusement, les services web actuellement déployés reposent, pour la plupart, sur une architecture asynchrone à base de middleware orienté messages (MOM) et ne représentent qu’une infime partie des accès aux composants sous-jacents. La couche des services web est une façade derrière laquelle se situent les applications de l’entreprise, et donc susceptible de jouer le rôle de fusible : elle s’écroulera sous la charge, mais n’aura pas d’impact sur le fonctionnement global des services exposés, les appels s’accumulant dans la pile du MOM.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
