Le document aborde la sécurisation des web services, soulignant l'importance du pare-feu XML pour garantir des échanges fiables et sécurisés entre applications. Il met en avant les vulnérabilités des services web face aux attaques diverses, telles que l'injection SQL, et la nécessité d'une infrastructure adaptable pour surveiller, filtrer et protéger les données échangées. La mise en œuvre de mécanismes de sécurité appropriés et l'intégration de normes sont essentielles pour assurer la disponibilité et la conformité des services dans un environnement de plus en plus numérique.

1. La sécurisation des Web Services
Livre Blanc

3. Le parefeu XML sécurise
les échanges entre applications
Livre Blanc
L’entreprise gagne à soigner l’interopérabilité de ses applications si elle veut croiser ses informations, enrichir
ses analyses et conquérir de nouveaux marchés. Dans ce contexte, l’infrastructure Web Services devient un enjeu
crucial. Elle figure au centre de l’interconnexion des systèmes d’informations et des migrations actuelles vers le
cloud computing. De nouveaux moyens de protection sont nécessaires pour fournir des interactions continues,
des échanges fiables et sécurisés de Web Services, qu’ils soient destinés aux partenaires de l’entreprise ou aux
salariés.

4. Page 4
S
avez-vous qui exploite réellement vos Web
Services ? Lorsque la direction informatique donne
le feu vert pour déployer ces composants applicatifs,
c’est pour industrialiser des échanges commerciaux avec des
partenaires, sans intervention humaine. La DSI provoque des
interactions entre deux applications hétérogènes, par exemple
pour consulter le stock d’un fournisseur et répondre à une
commande en ligne avec une date de livraison pertinente.
En coulisse, cette implémentation repose sur plusieurs pro-
tocoles et standards, issus du Web et respectant, le plus
souvent, l’architecture orientée services SOA (les standards
"WS-*"). Les données fournies en réponse à l’invocation du
service sont structurées et représentées en langage XML, là
où une page HTML répond à une requête HTTP de l’utilisateur
d’un navigateur Web.
Le hacker, de son côté, cherche à se faire passer pour une
ressource applicative, par exemple via un contenu malicieux
encapsulé dans un message. Il tente ainsi de sonder les Web
Services exposant des données sensibles, pour récupérer des
mots de passe ou des références bancaires. D’où l’impor-
tance d’identifier soigneusement le deman-
deur comme le fournisseur de services.
A présent, de nombreux mécanismes
d’intrusions se répandent sur Inter-
net ; des boîtes à outils détectent les
dernières vulnérabilités applicatives.
D’autres défis attendent l’exploitant des Web Services. Qu’il
soit hébergeur des serveurs d’applications ou responsable de
la production informatique interne, il doit garantir une disponi-
bilité continue de chaque module communicant. Il s’organise
donc pour diminuer les interventions en cas d’attaque malveil-
lante, de maladresse d’un développeur ou d’un administrateur.
Comment ? En sélectionnant les outils et les procédures rédui-
sant les délais de maintenance, en anticipant les intrusions, en
filtrant les messages et en corrigeant les erreurs.
Garantir la disponibilité du service
La sécurisation des flux de machine à machine devient une
priorité pour tous ceux qui exposent des Web Services à leurs
partenaires. Ils doivent garantir un niveau de disponibilité et
un niveau de conformité constant, le plus élevé possible. Or,
les défenses actuelles suivent un schéma dépassé, sur trois
niveaux. La plupart offrent un périmètre renforcé, nécessaire
mais insuffisant. Il faut passer du correctif logiciel à une ré-
flexion architecturale, prévenir le déni de service, anticiper
les attaques, détecter l’origine précise du problème, puis le
résoudre rapidement.
Naturellement, on ne va pas demander aux yeux humains de
surveiller chaque flux de données émis par le Web Service.
Une nouvelle automatisation doit intervenir au sein d’un équi-
pement intelligent, fiable, simple à configurer et évolutif. •
Sans surveillance, les Web Services restent vulnérables
Les hackers ne se contentent pas d’infiltrer les réseaux. Ils découvrent de nouvelles failles
applicatives chaque jour. Et ils en profitent pour intercepter des données sensibles.
Parmi les attaques répandues sur le niveau applicatif,
l’injection de requêtes SQL permet de de dérober des
données confidentielles. L’injection de requêtes sur
l’annuaire LDAP peut servir à usurper les droits de
l’administrateur, pour prendre la main sur une res-
source partagée, un équipement ou un WebService.
Les scripts d’interception de données figurent dans de
nombreux kits d’attaques. Certains exploitent le format,
l’enveloppe, ou le message XML. D’autres ciblent le
parseur XML qui analyse les messages transmis. Une
infrastructure web non sécurisée expose les serveurs à
de multiples vulnérabilités comme le déni de service, le
détournement de service, la prise de contrôle à distance,
le vol ou l’effacement de données.
Il faut protéger les web services tout comme on a
protégé en leur temps les applications web. Un outil
comme le pare-feu applicatif doit avoir son pendant
dans le référentiel des web services. Agile, polyvalent, ce
« pare-feu XML » permet d’analyser les messages XML
et leur contexte, tout comme les pare-feu l’ont fait pour
les requêtes HTTP standard.
La problématique
Les Web Services évoluent en milieu hostile.
Que fait-on pour les sécuriser ?
<?xml version=»1.0» encoding=»UTF-8»?>
<kml xmlns=»http://earth.google.com/kml/2.0»>
<Response>
<name>rue de la chimie, saint martin d’hères</name>
<Status>
<code>200</code>
<request>geocode</request>
</Status>
<Placemark id=»p1»>
<address>rue de la chimie, 38400 Saint martin d’hères, France</address>

5. Page 5
L
e portefeuille applicatif de l’entreprise évolue vers un
univers de services hétérogènes. Il se compose d’un
nombre croissant d’applications SaaS (Software as
a Service) accessibles à la demande. Les développements
intranet et les applications métiers cohabitent fréquemment
derrière un portail Web. Au final, un nombre croissant de Web
Services sont consommés en interne.
D’autres composants semblables sont exposés aux partenaires
de l’entreprise. Cette tendance s’accentue avec la dématéria-
lisation des procédures, avec le commerce électronique, avec
les réseaux sociaux et les places de marché sur Internet.
Relever des défis critiques
Le rôle du parefeu XML est donc critique. D’une part, pour
garantir la disponibilité et la conformité des flux XML, et d’autre
part pour alerter l’administrateur avant et pendant une attaque,
une panne ou une défaillance de Web Services.
Prenons un exemple concret. Lorsqu’un internaute commande
un produit sur le site web de l’entreprise, l’application mar-
chande lui présente un bon de commande dont les informations
proviennent de plusieurs modules intégrés. En arrière-plan, les
serveurs d’applications invoquent plusieurs Web Services. Dès
qu’elle procède aux premiers échanges automatisés, l’entre-
prise doit maintenir une chaîne cohérente, stable et sécuri-
sée. Elle doit analyser les comportements de chaque module
applicatif, sonder plusieurs niveaux de protocoles réseaux et
web, inspecter les fichiers retournés par chaque composant,
indépendamment du langage de développement.
Le sas de sécurité historique - la DMZ - n’est plus l’unique
point de contrôle nécessaire et suffisant. De même, le pare-
feu réseau perd de son intérêt lorsque les communications
basculent vers le protocole HTTP sur SSL, court-circuitant tout
filtrage de bas niveau pour l’accès aux ressources réseau.
Le pare-feu XML et ses nombreuses fonctionnalités apportent
une instrumentation adaptée aux besoins actuels de sécurisa-
tion des interactions. Il filtre ainsi de façon simple et efficace
tous les flux de données. Conscient de l’état du réseau, cet
équipement matériel facilite le dialogue entre administrateurs
(applicatif, système, réseaux) et RSSI (responsable de la sécu-
rité du système d’information).
Les analyses fournies par le pare-feu XML mettent fin aux
contentieux éventuels. L’entreprise y gagne une disponibilité
de services continue. Elle peut garantir la conformité de ses
échanges automatisés, de machine à machine. Ses incidents
applicatifs ne se reproduisent plus sans fin. •
Anticiper l’attaque, inspecter les flux, délivrer les preuves
Avant, pendant et après l’incident, le parefeu XML surveille, filtre et trace les flux de données.
Ses algorithmes d’inspection et d’analyse procurent une défense et un reporting précieux.
Première étape, le parefeu XML intervient, de façon
préventive, en orchestrant les moyens de sécurité mis à
sa disposition. Il aide à préparer, puis à valider des règles
d’accès sécurisés. Il recense les Web Services puis
procède au diagnostic de niveau de sécurité de chaque
composant. Il permet aux développeurs de s’assurer, de
manière transparente, que leur travail est conforme à la
politique de sécurité des Web Services de l’entreprise.
Une fois déployé, conscient du contexte, il filtre les
messages échangés en temps réel. S’il détecte un
incident ou une intrusion, il bloque à temps les conte-
nus suspects, même si le type d’attaque n’a jamais été
rencontré jusque là. Il surveille les performances des
Web Services, s’assure que ceux-ci sont disponibles et
vont le demeurer.
En cas d’alerte, ou suite à une dégradation de perfor-
mances, ses réponses sont également précieuses. Le
parefeu XML apporte une analyse qui aide à comprendre
pourquoi un WebService ne répond plus ou bien trop
lentement. Grâce aux rapports qu’il délivre, l’administra-
teur peut remonter la trace des échanges jusqu’à trouver
l’origine du problème.
La méthodologie
« Le parefeu XML enrichit considérablement la sécurité des Web Services,
en particulier pour les transactions financières, les échanges de données
privées ou relatives à la propriété intellectuelle » (source : Gartner 2011)
Une protection en trois phases

6. Page 6
L
e parefeu XML renforce les ressources applicatives
et les interactions entre applications. De son côté, le
parefeu réseau filtre les accès aux équipements du
réseau. Les deux dispositifs sont complémentaires.
L’un comme l’autre doivent être configurés pour
faire respecter la politique de sécurité de l’entre-
prise, chacun à leur niveau.
Les Web Services délivrent des données à
l’intérieur de l’entreprise aussi bien que vers
l’extérieur. Par conséquent, le parefeu XML Bee
Ware applique des règles de sécurité distinctes,
selon l’emploi, interne ou externe, des modules appli-
catifs surveillés. Conscient de la topologie du réseau physique,
il sait communiquer avec les dispositifs actifs de l’infrastruc-
ture, pour révéler, en cas d’indisponibilité du service, l’origine
du dysfonctionnement.
Des Web Services intégralement suivis
Une fois installé, l’équipement dédié surveille les flux échangés
entre les serveurs d’applications Web, le contenu des mes-
sages (XML/SOAP, REST) et des attachements. Conforme aux
derniers standards, le parefeu XML Bee Ware protège chaque
WebService en examinant tout son éco-système. En cas
d’interruption ou de dégradation de service, il prévient l’ad-
ministrateur que le niveau de service est altéré, précisant le
module en cause et le segment de réseau concerné. Les
fonctions de reporting et de suivi visuel de l’activité apportent
une visibilité nouvelle aux responsables de l’exploitation
et de la sécurité informatique. Le boîtier analyse, à la volée,
les scripts encapsulés et propose une réaction immédiate. Il
bloque ainsi les attaques en déni de service et garan-
tit que les données fournies par le WebService sont
toujours intactes et conformes au format attendu.
L’exécution de règles de sécurité contribue à
détecter les comportements suspects et les
scripts malicieux. Chaque Web Service est pro-
tégé dans son contexte d’utilisation. L’appliance
Bee Ware se déploie de manière adaptable, en mode
reverse proxy ou transparent proxy. Cela permet un
routage applicatif granulaire vers les applications autorisées,
internes comme externes. Bee Ware renforce ainsi les canaux
de communication intra-entreprise et inter-entreprises.
En pratique, le parefeu XML Bee Ware rejoint très rapidement
le site de production informatique ou bien le datacenter de
l’hébergeur lorsque les traitements sont externalisés. Il n’y
a pas de plateforme serveur à commander ni à configurer,
aucune installation ni aucune mise à niveau manuelle à gérer
pour renforcer les Web Services. En option, le parefeu XML
Bee Ware est disponible sous forme d’appliance virtuelle
VMware. •
Le parefeu XML Bee Ware apporte une visibilité nouvelle
Conforme aux derniers standards des Web Services, simple à porter et à exploiter, le parefeu XML
Bee Ware rejoint tous les sites sensibles. Il protège les applications internes et externes.
Un flux de données XML peut concerner plusieurs par-
tenaires à la fois, chacun exigeant son propre niveau de
sécurité. De l’authentification à la signature électronique,
en passant par les fichiers attachés, le parefeu XML Bee
Ware garantit que toutes les informations sensibles sont
sécurisées, chiffrées avec le bon algorithme, conformé-
ment aux applications et aux politiques de sécurité des
partenaires. « Des portions de message peuvent être
chiffrées différemment, car chaque application du par-
tenaire captera une partie seulement du message. Notre
parefeu XML assure le suivi et la conformité de telles
interactions », précise Jérôme Clauzade, le responsable
produit de Bee Ware.
La réponse technologique
Jérôme Clauzade
Responsable Produit
Bee ware france
Une inspection fine et précise des messages
<?xml version=»1.0» encoding=»UTF-8»?>
<kml xmlns=»http://earth.google.com/kml/2.0»>
<Response>
<name>rue de la chimie, saint martin d’hères</name>
<Status>
<code>200</code>
<request>geocode</request>
</Status>
<Placemark id=»p1»>
<address>rue de la chimie, 38400 Saint martin d’hères, France</address>
<AddressDetails Accuracy=»6» xmlns=»urn:oasis:names:tc:ciq:xsdschema:xAL:2.0»>
<Country>
<CountryNameCode>FR</CountryNameCode>
<CountryName>France</CountryName>
<AdministrativeArea>
<AdministrativeAreaName>Rhône-Alpes</AdministrativeAreaName>
<SubAdministrativeArea>
<SubAdministrativeAreaName>Isère</SubAdministrativeAreaName>
<Locality>
<LocalityName>Saint martin d’hères</LocalityName>
<Thoroughfare>
<ThoroughfareName>Chemin de Malanot</ThoroughfareName>
</Thoroughfare>
<PostalCode>
<PostalCodeNumber>38400</PostalCodeNumber>
</PostalCode>
</Locality>
</SubAdministrativeArea>
</AdministrativeArea>
<?xml version=»1.0» encod
<kml xmlns=»http://eart
<Response>
<name>rue de la chimi
<Status>
<code>200</code>
<request>geocode</
</Status>
<Placemark id=»p1»>
<address>rue de la c
<AddressDetails Accu
<Country>
<CountryNameCo
<CountryName>F
<AdministrativeA
<Administrativ
<SubAdministr
<SubAdminis
<Locality>
<LocalityNa
<Thorough
<Thoroug
</Thorough
<PostalCod
<PostalCo
</PostalCod
</Locality>
</SubAdminist
</Administrative

7. Page 7
Une configuration adaptée au contexte de chaque lien
QoS
R
Réseaux privés
Internet
Applications internes
R&D
Utilisateur
Partenaire
Fournisseur
Entreprise
1
2
2
3
4
1
Adoption des standards de sécurité
L’intégration de la sécurité dans l’envi-
ronnement de développement des Web
Services permet de réduire les délais
de publication. La R&D et la Production
parlent le même langage sécurité •
2
Protection et routage
Les Web Services publiés vers l’entre-
prise ou vers Internet requièrent une
analyse en profondeur des messages,
tant les technologies employées sont
diverses et potentiellement exploitables.
Le support des standards est indispen-
sable (XML, RESTful, JSON, etc.) pour
l’inspection et le routage applicatif •
3
Qualité de service
Les messages en direction des par-
tenaires sont validés par le pare-feu
XML afin de s’assurer que leur format
et leur fréquence ne vont pas acciden-
tellement perturber le Web Service du
partenaire •
4
Continuité de service
Le pare-feu XML garantit la disponibi-
lité des Web Services pour les parte-
naires en les assurant qu’un incident
de production de l’un d’entre eux (bug,
surcharge accidentelle) ne va perturber
l’ensemble du service •
Le déploiement

8. Page 8
S
oftware AG est un éditeur Européen spécialisé dans
l’intégration des partenaires et dans la modernisa-
tion du système d’informations. Sa suite de logiciels
prend en charge la modélisation et l’exécution des processus
métiers de l’entreprise en s’appuyant sur une architecture
SOA, un bus de services et un référentiel unique : l’annuaire
de services.
C’est autour de cet annuaire, précieux pour l’ouverture du
système aux partenaires, que démarre la relation avec l’équi-
pementier Français Bee Ware. Il s’agit de sécuriser les Web
Services exposés, de protéger le système contre les attaques
et les risques principaux, qu’ils viennent de l’extérieur comme
de l’intérieur de l’entreprise et qu’ils impliquent une maladresse
ou une malveillance.
« On doit être certain d’invoquer ou d’exposer des Web
Services sûrs, observe Fabrice Hugues, directeur avant-ventes
de Software AG pour la France et l’Italie. La mise en place de
contrats de services impose des moyens de sécurisation adap-
tés, une gestion de tokens d’authentification et des outils de
suivi des protocoles, à plus bas niveau. Bee Ware éradique le
déni de service, quel que soit le protocole. Grâce au parefeu
XML, on sait qu’aucun code d’injection SQL n’est embarqué
dans un message. WebMethods agit, pour sa part, au niveau
fonctionnel : tel message est-il autorisé à passer ? L’adéqua-
tion des deux solutions nous confère une position unique sur
le marché. »
Avec des règles de sécurité positionnées en un seul et unique
point, l’entreprise gagne une vision centralisée de ses compo-
sants applicatifs. L’annuaire de services est partagé entre le
parefeu XML Bee Ware, la suite WebMethods de Software AG
et l’infrastructure : « l’annuaire est un repère essentiel, un point
focal pour tous les objets que l’on veut exposer à l’extérieur.
Le propriétaire d’un WebService - un responsable CRM par
exemple - peut ainsi exposer un service de création de client
avec toutes ses contraintes, fonctionnelles et techniques »,
illustre Fabrice Hugues.
Des règles de sécurité regroupées
L’équipement de protection des Web Services de Bee Ware
intègre une suite complète de logiciels incluant, le cas échéant,
la partie sécurité de WebMethods : « le parefeu XML Bee Ware
se présente sous la forme d’une appliance matérielle. Le hard-
ware est facile à déployer, très performant. Les mises à jour et
l’exploitation sont très simples. C’est intéressant en terme de
souplesse et de TCO (coût total de possession), surtout dans
un vaste datacenter », note Fabrice Hugues.
La gouvernance de l’architecture SOA passe par celle des
composants applicatifs. Ainsi, même lorsqu’ils sont déployés
chez un prestataire, les Web Services appartiennent toujours à
leur propriétaire. Par conséquent, « c’est à l’entreprise de gérer
ses propres règles de sécurité, techniques et fonctionnelles,
quand bien même l’hébergeur serait impliqué, au niveau de la
sécurisation des protocoles », recommande-t-il. •
Aligner le socle technique sur la sécurité fonctionnelle
L’éditeur de WebMethods a choisi Bee Ware comme expert pour la sécurité des Web Services.
Cette association renforce les interactions des clients communs, des protocoles aux processus.
En terme d’échanges inter-entreprises (B2B), le mode
de communication asynchrone à base de message EDI
ou XML a longtemps été retenu. L’essor du e-Commerce
puis celui du Cloud computing provoquent de plus en
plus d’interactions entre les services. Les applications
mobiles sous iOS, Windows Mobile ou Blackberry
ouvrent aussi de nouveaux canaux à sécuriser. L’info-
gérance des applications professionnelles et les projets
SaaS vont accélérer l’adoption du parefeu XML Bee
Ware. En effet, ces approches multiplient les échanges
avec des tiers, via Internet. L’appliance paramètre,
exécute des règles de sécurité puis audite tout ce qui
circule. Une fois filtrée, l’information est techniquement
valide. Au niveau de l’ESB (Enterprise Service Bus),
aucun doute possible : on peut récupérer cette informa-
tion.
L’écosystème
Fabrice Hugues
Directeur avant-ventes
software ag
Paramétrer, exécuter les règles et auditer
tout ce qui passe

9. Page 9
lexique
ESB
Enterprise Service Bus. Le bus de service d’entreprise aide les applications d’entreprise
d’éditeurs distincts à communiquer entre elles. Il s’appuie sur des standards tels que le
langage XML, l’interface de programmation JMS (Java Message Service) et les Web Services.
REST
Representational State Transfer. Ce style d’architecture - orienté ressources - est retenu pour
réaliser des applications Web et bâtir des échanges standards entre machines à base de Web
Services.
SLA
Service Level Agreement. L’accord de niveau de service précise, dans un contrat établi entre un
prestataire et un client, la qualité de service ainsi que les modalités de performances délivrées.
SOA
Service Oriented Architecture. Cette architecture de médiation s’appuie sur des composants
logiciels ou Web Services pour intégrer entre elles des applications locales ou distantes.
SOAP
Simple Object Access Protocol. Ce protocole d’appels de procédures à distance, défini
initialement par Microsoft et IBM, est une spécification du W3C, le consortium World Wide
Web. Il est utilisée dans le cadre d’architectures SOA pour les WS-*.
WebService
Programme à base de standards ouverts fournissant l’interopérabilité entre des logiciels
exécutés sur des plateformes distinctes. Le consommateur de WebService utilise la logique
implémentée par le fournisseur de ce composant.
WSDL
Web Service Description Language. Interface d’accès au Webservice fondée sur le langage
XML pour préciser comment communiquer afin d’utiliser le composant logiciel.
WS-*
Ensemble de spécifications des Web Services. Par exemple, le protocole WS-Security pour
appliquer de la sécurité aux Web Services ou encore WS-Policy, WS-Trust...
XML
Extensible Markup Language. Ce langage à balises, textuel et structuré, est extensible. Il vise
à automatiser les échanges et entre différents systèmes hétérogènes.
Bee Ware présente son Web Services Firewall, conçu pour donner aux équipes de sécurité
des SI une visibilité nouvelle sur les Web Services. Disponible sous forme d’appliances ou de
machines virtuelles, le Web Services Firewall se déploie en mode mandataire ou transparent
et permet d’inspecter les flux entrants ou ceux à destination des partenaires. Au delà de son
rôle de reconnaissance et d’interception de contenus offensifs, il permet de protéger les
fournisseurs et les consommateurs de Web Services contre les aléas qui peuvent perturber la
production (incidents réseau, saturation, messages corrompus…) Ses fonctions de monitoring
proactif lui permettent d’anticiper les surcharges et de faciliter la continuité des Web Services
qu’il protège.
Le parefeu XML BEE WARE EN Détails

10. Livre Blanc
Pour assurer la continuité et l’évolution des Web Services, quel que soit le mode de consommation (de l’interne ou
depuis l’extérieur), il faut instrumenter l’infrastructure. Le parefeu XML rassure les partenaires lors des échanges
numériques. Il garantit la conformité des flux entre serveurs, bloque les attaques et contenus malicieux. C’est un outil
de conformité, de traçabilité et d’analyse forensique précieux à l’ère du cloud computing et de l’interconnexion des
systèmes d’informations.
Pour en savoir plus
BEE WARE
20 rue Billancourt
92100 Boulogne Billancourt - France
Téléphone : +33 (0)1 74 90 50 90
Fax : +33 (0)4 42 38 28 62
Email : info@bee-ware.net
Web : www.bee-ware.net
SOFTWARE AG FRANCE
Tour Europlaza - 20 avenue André Prothin - La Défense 4
92927 Courbevoie cedex
Téléphone : +33 (0)1 78 99 70 00
Fax: +33 (0)1 47 76 32 62
Email : sales.fr@softwareag.com
Web : www.softwareag.com
Livreblancréalisépar-www.speedfire.com

12. Tous droits réservés - (C)opyright septembre 2011 - © Bee Ware