> Tech > Délivrer la solution

Délivrer la solution

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Les trois objectifs de WS-Security sont les suivants : confidentialité, intégrité et non-répudiation. La confidentialité et l’intégrité veillent bien sûr à garder le secret d’un message. Mais aussi à vérifier que chaque intervenant est bien qui il déclare être et que seuls des intervenants autorisés peuvent apporter des changements logiques

Délivrer la solution

à un message de services Web sur son trajet. Quant à la non-répudiation, elle empêche les interlocuteurs de nier le fait que la transaction a bien eu lieu.

A cette fin, WS-Security enrichit le protocole SOAP de plusieurs nouveaux objets, qui s’associent pour transmettre un jeton de sécurité entre le client et le serveur. Le jeton de sécurité peut être fort simple (mot de passe crypté) ou très compliqué (certificat numérique). Son rôle est de protéger le coeur du message SOAP, en laissant les autres parties du message ouvertes à l’inspection par les pare-feu, les passerelles, les équilibreurs de charge, et les routeurs de services Web.

WS-Security repose sur quatre termes clés : acteur, revendication jeton de sécurité, et signature numérique. Un acteur est toute partie de la transaction autorisée à lire ou modifier une partie protégée de cette transaction. Les routeurs, les commutateurs et les pare-feu de réseaux ordinaires ne sont pas des acteurs. En revanche, sont acteurs les clients, les serveurs, les courtiers, les pare-feu d’application XML, et les équilibreurs de charge. Une revendication est une assertion faite par un acteur, comme son identité. Une collection de revendications est souvent regroupée en un jeton de sécurité. De tels jetons ne sont valides que s’ils incluent la signature numérique d’un tiers approuvé, comme une CA (Certificate Authority) publique.

Un message SOAP est constitué d’un jeu d’étiquettes <soapenv :Envelope> global, qui contient les deux principales sections de l’enveloppe SOAP, l’en-tête et le corps. La section corps contient à son tour le bloc principal de SOAP. Toutefois, WS-Security n’affecte pas directement le corps : il y fait référence indirectement. WS-Security XML apparaît à l’intérieur de la section en-tête de SOAP. Il peut y avoir plusieurs sections de sécurité, une pour chaque acteur intervenant dans la sécurité de la transaction.

Un jeton de sécurité est placé entre des étiquettes XML <SignedInfo>, avec des attributs décrivant la signature numérique et/ou le cryptage utilisé pour protéger le corps du message. L’info signée comporte trois parties : un algorithme de « canonicalisation », un algorithme de signature numérique, et une sous-section de référence, laquelle décrit les algorithmes transform et digest utilisés. Heureusement, cette information est en grande partie figée et vous n’aurez jamais à la générer par programme. Il suffit de savoir que si un acteur avance une revendication qui ne peut pas être prouvée par la signature autorisée requise, la transaction du service Web sera rejetée par la première partie qui détectera le défaut.

En supposant que le message passe le test de signature numérique, indiquant par là qu’il est resté intact pendant son trajet, le destinataire du message peut commencer à décrypter le corps du message (s’il est crypté, car le cryptage est facultatif). Pour cela, le destinataire a besoin de clés. Elles apparaissent dans une section <Keys> séparée. Bien entendu, l’envoi des clés de cryptage réelles n’aurait pas de sens : un intrus pourrait simplement les lire puis les appliquer au contenu crypté pour récupérer le message en texte clair. Au lieu de cela, WS-Security supporte diverses méthodes PKI (public key infrastructure) pour une distribution de clés en toute sécurité. Il n’est pas question d’entrer ici dans les détails de ces méthodes, mais toutes utilisent une cryptographie de clé publique, dans laquelle chaque partenaire a une paire de clés publique/privée. Cette paire de clés code un certificat numérique ou un ticket Kerberos, que le destinataire prévu pourra traiter pour récupérer les clés de décryptage nécessaires pour lire le message.

La section Keys ne transporte pas uniquement des clés, mais des certificats numériques entiers. Les certificats numériques sont des références électroniques signées par une entité indépendante appelée CA (Certificate Authority). Les CA peuvent être publiques ou privées. VeriSign, l’un des auteurs de WS-Security, est un exemple de CA publique. Votre propre entreprise peut être une CA privée habilitée à créer des certificats à usage strictement interne. Cependant, pour que WS-Security donne toute sa mesure, la CA sera très certainement publique, puisque les services Web sont là pour qu’une entreprise puisse fournir un service à une autre.

WS-Security supporte également l’utilisation des tickets Kerberos. Les tickets Kerberos ont une durée de vie définie qui interdit leur réutilisation. Ils protègent donc parfaitement les transactions que vous souhaitez rendre invalides si elles ne s’effectuent pas dans un certain délai. Un intrus pourrait récupérer le certificat numérique à partir d’un message SOAP et l’utiliser pour tenter de futures attaques sur un serveur. En revanche, les tickets Kerberos ne sont plus d’aucune utilité une fois expirés.

WS-Security est une route à deux voies. Quand un serveur de services Web destinataire a traité les parties de l’entête de WS-Security, ce destinataire peut décrypter le message lui-même et le traiter comme il le ferait normalement. La réponse au client utilise la même sémantique WS-Security, et donc le client jouit des mêmes garanties et protections que le serveur.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010