Au début des services Web, leurs fournisseurs considéraient que la sécurité serait entièrement gérée au niveau de la couche transport, au moyen de SSL/TLS (HTTPS). C’est pourquoi les standards de services Web initiaux n’abordaient pas la sécurité. Mais celle-ci a pris de l’importance dès lors que les services Web se sont multipliés. Une transaction de service Web passe souvent par de nombreuses mains, dont chacune a besoin d’accéder à certaines parties de la transaction mais pas à d’autres.En 2002, IBM, Microsoft et VeriSign ont proposé un standard de sécurité pour répondre à ces besoins. Appelé WS-Security, la spécification résultante est vaste et compliquée parce qu’elle couvre un large éventail d’aspects de sécurité des services Web. En 2004, apparaissait la version 1.1 du standard, plus dépouillée et plus puissante que le premier jet, mais encore volumineuse.
Heureusement, vous pouvez utiliser le standard dans vos applications de services Web sans le comprendre entièrement. WebSphere Application Server (WAS) 5.0 et ultérieure supportent WS-Security et se chargent virtuellement de tout l’aspect configuration. D’autres environnements de développement de services Web ont des fonctionnalités comparables. Une fois que vous aurez compris ce qu’apporte WS-Security et comment il fonctionne, vous pourrez commencer votre propre expérience.
WS-SECURITY : rôle et fonctionnement
Les transactions de services Web contiennent souvent des données sensibles réservées à certains interlocuteurs. Le cryptage SSL/TLS concernant toute la transaction ne fonctionne que si la transaction du service Web intéresse deux parties : un initiateur et un récepteur. Mais les messages de services Web ne vont pas forcément directement au serveur de destination. Ils passent souvent par des intermédiaires : pare-feu d’application, agents de courtage, et autres.
Ces intermédiaires ont besoin d’accéder à certaines parties du contenu SOAP (Simple Object Access Protocol) et peuvent en fait modifier ce contenu. La seule exigence de SOAP vis-à-vis des agents transmettant des messages SOAP, est que la logique du contenu reste homogène. Par conséquent, un intermédiaire peut réécrire le message, changer l’espace vierge, les fins de lignes et même l’ordre des éléments, tant que le XML résultant est l’équivalent logique de l’original. Il est évident que cela exclut tout cryptage de bout en bout ou tout contrôle d’intégrité fondé sur des signatures numériques.
Pour résoudre ce problème, WS-Security offre une double possibilité : protéger certaines parties du message SOAP et prendre en compte les changements susceptibles de se produire quand le message change de mains. Il fournit toute la protection des mécanismes de sécurité classiques, comme SL/TLS et IPSec, tout en permettant aux parties concernées de mener à bien une transaction de service Web.
Téléchargez cette ressource
État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
