1 - Introduction

Du troc pur et simple du début de l'humanité aux transactions financières par banques interposées de l'ère moderne, les échanges commerciaux ont toujours existé, seul leurs formes et méthodes d'échange ont changé. Nous avons récemment vu émerger une nouvelle forme pour commercer qui utilise des technologies dont l'essor s'est produit essentiellement dans la deuxième partie des années nonante : le e-commerce.

Le e-commerce est, comme son nom l'indique, du commerce électronique. C'est à dire que l'on a à faire à un ensemble d'échanges numérisés liés à des activités commerciales. Le support principal de ces échanges est l'Internet. Après une courte période du « tout gratuit » sur Internet, les négoces et l'argent ont fait irruptions sur cette scène encore relativement vierge et innocente que représentait le réseau des réseaux pour s'y imposer de plus en plus solidement comme une nouvelle alternative commerciale.

Qui dit échange dit communications et transferts d'informations. Nous étudierons donc par la suite les divers acteurs de ces échanges et les éventuels intermédiaires auxquels ils font appels, les menaces auxquels ils sont confrontés ainsi que les mesures existantes pour s'en prémunir. Du fait des menaces auxquels les divers acteurs du ecommerce sont confrontés, la question de la confiance devient un axe principal à développer au niveau de la communication de l'entreprise ayant des produits ou services à proposer via internet.

Par ailleurs, un phénomène intéressant à étudier est le problème lié à la dématérialisation des échanges ainsi que le fait que les frontières y sont abolies. Ceci engendre un flou juridique qui fut difficile à clarifier et qui pose encore aujourd'hui son lot de situations pour lesquelles il n'y a pas ou peu de législation.

Nous terminerons cette documentation sur « L'introduction à la sécurité e-commerce » par l'étude d'un cas pratique. Il s'agira d'Infomaniak Network SA et nous tenons à remercier M. Fabian Lucchi pour sa collaboration et son amabilité.

2 - Les acteurs du e-commerce

Plusieurs types d'acteurs participent aux commerces électroniques. Chacun possède des besoins propres et est soumis à des menaces particulières. Nous allons ici présenter ces acteurs et leurs envies et soucis auxquels ils sont confrontés.

2.1 - Le client

Le client peut être une personne ou une entreprise souhaitant commander un produit ou un service. Etant un des éléments du e-commerce, il est la cible de menaces. Il doit faire attention à être sur le bon serveur et qu'il va commander ce qu'il veut vraiment et au bon prix. C'est pourquoi il est important que le vendeur sache rassurer le client sur le fait qu'il n'y a pas de risques.

Le client doit s'identifier vis à vis du vendeur et cette opération comporte plusieurs problèmes:

• Il voit le risque que les informations qu'il donne sur Internet soient utilisées à des fins commerciales ou autres (problème de confidentialité des informations personnelles ou financières)

• Il encourt aussi le risque que quelqu'un d'autre qui réussirait à obtenir ces informations se fasse passer pour lui et fasse des commandes qu'il ne souhaite pas ou autres.

C'est pourquoi d'un point de vu sécurité, il faut étudier les problèmes de confiance envers le vendeur, d'identification du client (clé publique PKI), mais aussi il ne faut pas oublier de sensibiliser le client aux problèmes de sécurité au niveau physique et le rendre conscient de ses responsabilités lors de la transaction.

2.2 - Le vendeur

Le vendeur est habituellement une entreprise et doit gérer le site web « catalogue » et sa sécurité, mettre en place un système d'identification du client sûr, gérer les demandes et envoyer les objets de la transaction aux clients ainsi que trouve r une manière d'encaisser.

La gestion du catalogue requiert entre autres de bien réfléchir à :

• La gestion de la sécurité au niveau physique ;

• La gestion de la sécurité au niveau réseau ;

• La gestion des risques de création par une personne mal intentionnée d'une copie du catalogue ou du site à une autre adresse. Une des premières mesures à prendre est d'enregistrer les noms de domaines proches de celui du site web pour éviter les pièges faciles ;

• Au fait qu'aucune personne ne doit pouvoir accéder (en profitant de failles physique ou réseau) à la base de données des produits du catalogue.

Le vendeur pour la gestion de toutes ces données peut faire appel à des intermédiaires techniques.

Il devra aussi faire face aux éventuels client mal intentionnés qui ne paierait pas ou refuserait la transaction tout en gardant la marchandise livrée (répudiation). Pour se décharger de ces problèmes, il peut également choisir d'utiliser les services d'un intermédiaire financier pour encaisser l'argent produit par la vente.

2.3 - L'intermédiaire technique

Les intermédiaire techniques permettent de décharger la somme de travail du vendeur et seront chargé de faire face aux éventuelles menaces liées à leurs fonctions. Les divers intermédiaires techniques auxquels il est possible de faire appel ainsi que leurs responsabilités sont présentés dans le tableau ci-dessous.

2.4 - L'intermédiaire financier

Les intermédiaires financiers permettent de décharger le vendeur des problèmes liés aux transactions financières. Nous présentons dans le tableau ci-dessous les divers intermédiaires financiers et leurs responsabilités comme nous l'avons fait plus haut pour les intermédiaires techniques.

En ce qui concerne le premier type d'intermédiaire, au moment du paiement, le client bascule sur la page de paiement hébergée sur le serveur de la banque gestionnaire des transactions. L'organisme bancaire vérifie en ligne l'autorisation de la transaction, dont le montant est directement viré sur le compte bancaire du vendeur, après validation de sa part. Les transmissions de données s'effectuent sur le réseau bancaire, avec confidentialité des données du client. Ces organismes utilisent pour la plupart les protocoles SET et CSET.

SET est un protocole par lequel il y a une vérification de la transaction avant de l'effectuer. Mais son défaut est le fait qu'il n'y a pas de participation physique ou matérielle à la transaction. Ceci donnant laissant la porte ouverte à la répudiation. D'où l'apparition du C-SET qui n'est autre que l'utilisation d'une carte et d'un lecteur de carte de la part du client qui permet ainsi d'avoir une preuve matérielle comme quoi le client désirait réellement effectué la transaction. Par ailleurs, il est à noter que ce qui pourrait permettre au C-SET de connaître un fort développement est l'utilisation des téléphones mobiles pourvus d'un lecteur de carte. Le client serait alors appelé sur son mobile et il entrerait sa carte et son code secret.

L'idée du porte-monnaie électronique est elle aussi intéressante. L'idée est que le client donne de l'argent en utilisant une méthode de paiement ne faisant pas appel à Internet à une entité qui lui assure ensuite un nombre de « jetons » que le client peut utiliser sur les sites de e-commerce reconnaissant ces « jetons ».

3 - Les menaces

Nous allons étudier ici les diverses menaces plus en détails auxquelles sont soumis les divers acteurs du e-commerce. Le but des menaces sont plus ou moins évidents : on cherche à compromettre la disponibilité, l'intégrité ou la confidentialité des informations d'un site d'e-commerce pour chercher à faire perdre de l'argent ou a en gagner.

3.1 - Les attaques sur les protocoles de communication

Cette catégorie d'attaque exploite les faiblesses des protocoles de base d'Internet tel que TCP/IP et ses « dérivés » comme http, ftp... Les grandes lignes de ce type d'attaques sont :

• Les attaques pour rendre indisponible le serveur ;

• L'écoute des communications et le rejeu ;

• La substitution et manipulation de données ;

• L'utilisation des protocoles non prévus ou le détournement de protocoles.

3.2 - Les attaques sur les systèmes et applications standard

Cette catégorie comprend les attaques qui exploitent les faiblesses au niveau des applications standard du serveur. Ce problème est appuyé par la standardisation des systèmes d'exploitation (Unix, NT, etc..) et des applications standards de communication (messagerie SMTP, navigateur utilisant http ou encore utilisation de SQL pour les bases de données). Les diverses possibilités d'attaques comprises dans cette catégorie sont :

• Les attaques sur des services réseaux non utilisés et non ou faiblement protégé ;

• Les attaques sur la disponibilité du service par utilisation des bugs de ses applications ;

• Les attaques visant à accéder aux systèmes d'informations de l'entreprise.

3.3 - Les attaques sur les informations

Ce dernier type d'attaque vise les informations elles-mêmes. Elles peuvent être utilisé pour obtenir un profit ou même pour introduire des informations fausses sur le site pour décrédibiliser et atteindre l'image de marque de l'entreprise faisant de l'e-commerce. On y trouve plusieurs formes d'attaques :

• Les attaques à la disponibilité du site par saturation ou manipulation des informations ;

• Les attaques visant une appropriation illégale d'informations présentes sur le site et ne devant pas être divulguées ;

• Les modifications malveillantes des informations affichées sur un site afin de désinformer les clients et compromettre la responsabilité de l'entreprise ;

• Les modifications de contenu des transactions visant un bénéfice direct.

3.4 - Quelques attaques

Nous allons regarder de plus près quelques attaques et agressions informatiques auxquelles un site de e-commerce peut être soumis.

3.4.1 - L'écoute passive et le rejeu

La façon de procéder d'une telle attaque est dans un premier temps l'écoute passive (qu'on appelle aussi sniffing) des communications d'un réseau pour tenter d'obtenir les informations d'authentification telles que le login et le mot de passe d'un utilisateur et une fois ceci obtenu, de le renvoyer immédiatement au serveur pour se connecter à la place du véritable utilisateur.

3.4.2 - Substitution et manipulation de données

Le but d'une telle attaque peut être d'effectuer une attaque en déni de service mais peut également avoir pour objectif de modifier les données d'une transaction dans l'intérêt de l'acheteur. Par exemple, si le e-commerce en question utilise des requêtes HTTP POST pour les commandes dans lesquelles se trouveraient le prix à payer, il serait facile pour un pirate d'accéder et de modifier le contenu de la requête POST en sa faveur.

3.4.3 - Virus

L'infection du serveur par un virus peut provoquer son indisponibilité totale ou partielle avec de graves et nuisibles retombées sur son chiffres d'affaires mais aussi, et serait-on tenter de dire surtout, sur son image de marque. Mais plus grave encore est le fait que le serveur peut propager le virus chez ses utilisateurs. Ces derniers ont alors légalement le droit d'attaquer en justice l'e-commerce en question. Ce type d'attaque est rare mais possible.

3.4.4 - Chevaux de Troie

La menace principal due aux chevaux de Troie pour un serveur d'un site de commerce électronique est que le pirate peut d'une part accéder et modifier des informations autant sur les clients que sur les produits ou services proposé par le ecommerce, mais aussi que le serveur peut être utiliser comme relais pour commettre des attaques du type déni de service sur d'autres machines. La responsabilité du e-commerce peut alors être engagée.

3.4.5 - Répudiation

Le problème consiste en qu'un acheteur commande un produit, le reçoive puis nie avoir participer dans la transaction. La marchandise est livrée mais reste impayée. Tout se problème se base sur  les mesures prises par le e-commerce pour s'assurer de produire des signatures électronique suffisantes qui ne puissent être remise en question après une transaction.

3.4.6 - Déni de service et DDoS

Ce type d'attaque vise clairement à rendre indisponible un service informatique, dans notre cas généralement, le serveur. Une méthode fréquemment utilisée est le dépassement de tampon qui consiste à envoyer un message au serveur plus grand que sa capacité de réception. Mais la méthode la plus répandue actuellement de déni de service est le déni de service réparti (DDoS - Distributed Denial of Service). Plusieurs façons de réaliser cette attaque existent, mais globalement ce qui se passe, c'est que le pirate créé un programme qui lui permet de gérer à distance des ordinateurs et leur ordonne à un moment donné d'envoyer tous en même temps des flux de paquets à une même cible. Ceci a pour effet de rendre indisponible la cible qui ne parvient pas à gérer toutes ces demandes.

3.4.7 - Le Spamming

Nous ne parlons pas ici du Spamming fait par une entreprise, car si un e-commerce se livrait à cette pratique, les conséquences seraient désastreuses pour lui-même. Le problème vient donc essentiellement du fait que, pour nuire à un e-commerce, un pirate qui serait parvenu à obtenir la liste des clients, par exemple en piratant le serveur ou la base de données, peut faire du spamming aux clients de ce e-commerce. Le spamming étant, nous vous le rappelons, l'envoie massifs de e- mails à caractère commercial, voire assez douteux.

3.4.8 - Attaques sur la base de données

L'une des attaques possibles a pour principe de modifier indirectement les ordres SQL envoyés au serveur, en y incluant des chaînes de caractères spéciales en lieu et place des paramètres attendus par l'applicatif. Cette technique permet de récupérer des informations confidentielles de la base de données ou simplement des méta données.

On peut par exemple faire un appel normal et on aura dans la barre d'adresse du navigateur : http://serveur/prog?user=nom_user. On peut ensuite faire un appel falsifié du type : http://serveur/prog?user=un_autre_user. A ce moment là, soit on obtient directement des infos concernant l'autre user, soit une erreur qui peut nous donner des indications qui permettent d'apprendre, par exemple, que le nom de user est un paramètre identifiant une table et qu'il y a une table par user, contenant un numéro qui sert de filtre. On peut ainsi obtenir des informations sur la base de données.

On peut également ajouter du SQL supplémentaire en fin de champ d'un formulaire. Si par exemple on a un champ demandant le nom d'une personne et qui fait l'ordre SQL : SELECT col FROM la_table WHERE nom = 'nom_user', et que dans le champ du formulaire on écrit : nom_user';delete from une_autre_table#, alors on aura réussi à détruire une table de la base de données.

Il est aussi possible en utilisant des techniques similaires de s'attribuer des niveaux de privilèges que l'on ne devrait pas avoir. On appelle ce genre de techniques d'attaques sur les bases de données des « Injections (ou inclusion) de SQL ».

4 - Les mesures de sécurisation d'un e-commerce

Nous devons pour sécuriser un site web commercial, penser à prendre des mesures à tous les niveaux, du niveau bêtement physique au niveau de l'application en passant par le serveur. Il est important de sécuriser les niveaux de façon homogène pour être efficaces tout en pensant à prendre les mesures en rapport à son activité. Nous tenons par ailleurs à souligner l'importance de penser au niveau physique, que l'on oublie souvent. Un portable volé dans un bureau peut représenter une sérieuse perte pour une entreprise de e-commerce. Analysons maintenant plus en profondeur les mesures pouvant être prises aux différents niveaux.

4.1 - Protection au niveau physique

Il est indispensable de penser à la sécurité au niveau physique. Dans ce domaine il faut penser à plusieurs points.

L'une des première chose à faire est de ne pas laisser sans surveillance les ordinateurs contenant des informations confidentielles. Si une personne malveillante s'introduit dans un bureau et accède aux mots de passes ou à la base de données, les conséquences qui s'en suivront peuvent être dramatique pour le e-commerce. Selon le niveau d'importance des informations du site, il peut être utile de faire appel à une société de surveillance et de contrôle des accès du bâtiment dans lequel se trouvent les ordinateurs.

Par ailleurs, il faut penser aux risques d'incendies ou de catastrophes qui pourraient détruire des ordinateurs contenant des informations importantes. Il est fortement recommandé de disposer d'un système de rechange dans un lieu différent dans le cas où un problème surviendrait.

4.2 - Protection au niveau du serveur

Il faut que le système d'exploitation du serveur soit correctement installé et paramétré. Il est nécessaire que ceci soit fait en pensant à bien sécuriser les domaines liés à la gestion des divers types d'utilisateurs du serveur en leur assignant les droits correspondants, à la gestion des processus et des systèmes des fichiers.

Par ailleurs, dans la mesure du possible, il est recommandé d'installer le serveur web sur une machine différente des autres applications (telles le serveur de messagerie, le serveur de cache, etc.) afin d'éviter les vulnérabilité liées à ces services.

Enfin, nous conseillons également d'avoir une trace journalière de toutes les actions menées sur le serveur.

4.3 - Protection au niveau du réseau

Aujourd'hui la mise en place d'un firewall est quasiment indispensable. Il permet de limiter les flux réseau ouverts depuis l'extérieur en direction du serveur web et permet ainsi de parer à certains types d'attaques du type déni de service par exemple. Le firewall a aussi l'avantage de journaliser le trafic et de disposer ainsi d'éléments sur ce qui se passe sur le réseau. Par ailleurs, en plus de ses fonctions de filtrages, les firewall d'aujourd'hui disposent aussi de fonctions à la manière des anti-virus qui permettent d'alerter si une attaque reconnue par sa signature ou pas est entré d'être menée.

La deuxième mesure importante pour éviter les risques d'attaques réseau est de bien penser son architecture réseau, de façon à protéger les zones dans lesquels se trouvent les informations sensibles et aussi de faire en sorte que si un pirate parvient à entrer dans le réseau, que ce dernier soit de manière à lui faire perdre du temps. Temps qui peut permettre de repérer et de parer à cette attaque.

Une dernière mesure importante est de faire en sorte que l'écriture des données se fasse toujours de l'intérieur vers l'extérieur et jamais inversement.

4.4 - Protection au niveau de l'application

La première mesure est de contrôler l'intégrité des données, c'est-à-dire de vérifier que le contenu des pages mises à disposition des clients soit correct. Si les pages sont statiques (pages html par exemple), une mesure facile à prendre est de calculer les signatures des fichiers existants et de vérifier qu'elles ne varient pas au cours du temps. Si les pages sont dynamique (par exemple utilisation de php et MySQL), il faut contrôler les éventuelles accès et modification à la base de donnée. Par ailleurs, l'installation d'un anti-virus pour contrôler les fichiers est nécessaire.

La séparation du travail des divers intervenants sur le serveur (administrateur du serveur, créateur des pages, etc.) en diverses applications et si possibles en leur attribuant un ordinateur différent à chacun permet de mieux contrôler les éventuelles attaques sur ces applications.

La journalisation sert à tracer et mémoriser les connexions des clients est également souhaitable. Dans le cas où un problème surviendrait, ce genre de traces permet de mieux analyser la faille et éventuellement de tenter de remonter jusqu'au pirate.

Faire attention et bien maîtriser les fonctionnalités des scripts et programmes exécutés du côté serveur ainsi qu'éviter l'emploi de programme CGI (Common Gateway Interface) s'ils ne sont pas absolument nécessaires, représente également une bonne mesure de sécurité. En effet, les pirates exploitent très fréquemment les faiblesses et vulnérabilités de ces programmes.

En ce qui concerne le transfert de données « sensibles », c'est-à-dire nécessitant un certain niveau de confidentialité, il est fortement recommandé d'utiliser les transferts sécurisés comme SSL, HTTPS, etc.

Enfin, une mesure importante est de bien pensé le système d'authentification des clients. Autant pour éviter que ceux-ci ne réussissent à accéder à des zones non autorisées que pour éviter de rendre facile le travail aux pirates qui chercheraient à s'authentifier à la place d'un utilisateur inscrit.

4.5 - Secure Sockets Layer (SSL)

SSL (que l'on pourrait traduire par couche de sockets sécurisée) est un procédé de sécurisation des transactions effectuées via Internet mis au point par Netscape, en collaboration avec Mastercard, Bank of America, MCI et Silicon Graphics. Il repose sur un procédé de cryptographie par clef publique afin de garantir la sécurité de la transmission de données sur Internet. Le système SSL est indépendant du protocole utilisé. SSL agit telle une couche supplémentaire, permettant d'assurer la sécurité des données, située entre la couche application et la couche transport.

La quasi- intégralité des navigateurs supporte désormais le protocole SSL. Netscape Navigator affiche par exemple un cadenas verrouillé pour indiquer la connexion à un site sécurisé par SSL et un cadenas ouvert dans le cas contraire, tandis que Microsoft Internet Explorer affiche un cadenas uniquement lors de la connexion à un site sécurisé par SSL.

Internet Explorer :

Mozilla :

La transaction sécurisée par SSL se fait selon le schéma suivant:

• Dans un premier temps, le client, se connecte au site marchand sécurisé par SSL et lui demande de s'authentifier. Le client envoie également la liste des systèmes de cryptages qu'il supporte, triée par ordre décroissant de la longueur des clés.

• Le serveur a réception de la requête envoie un certificat au client, contenant la clé publique du serveur, signée par une autorité de certification (CA), ainsi que le nom du système de cryptage le plus haut dans la liste avec lequel il est compatible (la longueur de la clé de chiffrement - 40 bits ou 128 bits - sera celle du système de cryptage commun ayant la plus grande taille de clé). Remarque : actuellement, il est recommandé au d'utiliser des clés 128 bits. Par exemple, le système de e-voting en suisse utilise ce type de clé et les considère comme suffisamment sûr.

• Le client vérifie la validité du certificat (donc l'authenticité du marchand), puis crée une clé secrète aléatoire, chiffre cette clé à l'aide de la clé publique du serveur, puis lui envoie le résultat (la clé de session).

• Le serveur est en mesure de déchiffrer la clé de session avec sa clé privée. Ainsi, les deux entités sont en possession d'une clé commune dont ils sont seuls connaisseurs. Le reste des transactions peut se faire à l'aide de clé de session, garantissant l'intégrité et la confidentialité des données échangées.

4.6 - Les certificats

Les algorithmes de chiffrement asymétrique (clefs publiques, clé de session, signature électronique) sont basés sur le partage entre les différents utilisateurs d'une clé publique.

Toutefois, le mode de partage a une grande lacune : rien ne garantit que la clé est bien celle de l'utilisateur a qui elle est associée. En effet un pirate peut corrompre la clé publique présente dans l'annuaire électronique en la remplaçant par sa clé publique. Ainsi, le pirate sera en mesure de déchiffrer tous les messages ayant été chiffrés avec la clé présente dans l'annuaire.

Ainsi un certificat permet d'associer une clé publique à une entité (une personne, une machine, ...) afin d'en assurer la validité. Le certificat est en quelque sorte la carte d'identité de la clé publique, délivré par un organisme appelé autorité de certification (souvent notée CA pour Certification Authority).

L'autorité de certification est chargée de délivrer les certificats, de leur assigner une date de validité (équivalent à la date limite de péremption des produits alimentaires), ainsi que de révoquer éventuellement des certificats avant cette date en cas de compromission de la clé (ou du propriétaire).

Les certificats sont des petits fichiers divisés en deux parties :

• La partie contenant les informations

• La partie contenant la signature de l'autorité de certification

Les informations contenues dans un certificat sont :

• Le nom de l'autorité de certification

• Le nom du propriétaire du certificat

• La date de validité du certificat

• L'algorithme de chiffrement utilisé

• La clé publique du propriétaire

L'ensemble de ces informations est signé par l'autorité de certification, cela signifie qu'une fonction de hachage crée une empreinte de ces informations, puis ce condensé est chiffré à l'aide de la clé privée de l'autorité de certification; la clé publique ayant été préalablement largement diffusée afin de permettre aux utilisateurs de vérifier la signature avec la clé publique de l'autorité de certification.

Lorsqu'un utilisateur désire communiquer avec une autre personne, il lui suffit de se procurer le certificat du destinataire. Ce certificat contient le nom du destinataire, ainsi que sa clé publique et est signé par l'autorité de certification. Il est donc possible de vérifier la validité du message en appliquant d'une part la fonction de hachage aux informations contenues dans le certificat, en déchiffrant d'autre part la signature de l'autorité de certification avec la clé publique de cette dernière et en comparant ces deux résultats.

4.7 - S/MIME, pour lutter contre la répudiation

Ce protocole utilisant des clés de session pour chiffrer les diverses parties du message de l'e-mail garantit la confidentialité et la non répudiation des échanges par e- mail.

4.8 - Protection contre l'Injection de SQL

Pour éviter les problèmes d'injection de SQL, une mesure simple et très efficace consiste à « sur-quoter » les paramètres d'entrée de la base de données. C'est-à-dire qu'il suffit d'ajouter des « quote » de manière à ce que même si un utilisateur malveillant tente d'ajouter des bouts de codes SQL, ces bouts de codes soient considérés comme des données uniquement.

Par ailleurs, pour la protection des bases de données, il est utile de suivre une grande partie des conseils mentionnés plus haut comme bien penser le système d'authentification, donner les privilèges minimums, etc.

4.9 - Autres mesures diverses

Il est conseillé de toujours effectuer des sauvegardes régulières et disposer de « plans de secours » pour être prêt à faire face à toutes les éventualités.

Il peut être bien d'utiliser le load-balancing (technique de répartition de charge entre plusieurs serveurs). Le principe de fonctionnement est simple, le load balancer (un switch dédié à la répartition de charge) va capter les requêtes des internautes pour les drainer jusqu'au serveur le plus disponible de votre architecture réseau. Ce système peut être mis en place sur une architecture constituée au minimum de deux serveurs web. Le rôle du Load Balancer est de répartir de manière intelligente la charge d'internautes afin d'assurer la meilleure disponibilité et évolutivité des services Internet du e-commerce. Si un serveur ne répond plus, le trafic Internet sera réparti sur les serveurs opérationnels afin d'assurer une continuité du service. En cas de pic de trafic, le load balancer répartira la charge sur l'ensemble des serveurs. En évitant la surcharge d'une machine en particulier, le principe de load balancing permet d'améliorer considérablement les temps de réponse du site. Si le trafic sur votre site internet augmente considérablement, il suffit d'ajouter un serveur supplémentaire derrière le load balancer. Ceci est utile par exemple dans le cas où un de vos serveurs tombait suite à une attaque, de pouvoir continuer sans trop de problèmes.

Dans cet esprit, la redondance des éléments critiques est également fortement recommandée.

5 - Etude de cas

Nous avons étudié le cas d'Infomaniak Network SA. Cette société a été créée en 1996 par M. Fabian Lucchi et M. Boris Siegenthaler. La société se spécialise dans l'hébergement de sites Internet. Depuis janvier 2003, Infomaniak Network SA est le 1er hébergeur de Suisse romande et depuis mars 2004 le 1er hébergeur Suisse pour les .com, .net, .org, .info. Nous tenons à remercier une nouvelle fois M Fabian Lucchi qui a accepté de répondre à nos questions. Voici un résumé des points importants abordés lors de l'interview avec M Lucchi :

Votre système a-t-il déjà subi des agressions informatiques ? Quelles mesures préventives avez-vous pris ?

M. Lucchi : Oui, c'est déjà arrivé. Les portes qui étaient restées ouvertes ont été fermées (au niveau de nos access-lists sur le routeur principal) et nous avons pratiquement banni intégralement nos machines Windows... le passage sous Unix est bien plus sécurisant. Ces mesures ont été complètement suffisantes.

De quels types de sécurisation au niveau physique (surveillances des bureaux, systèmes anti-incendies, etc..) disposez-vous ?

M. Lucchi : Surveillance vidéo avec enregistreur déporté physiquement; surveillance de la salle machine au niveau température et détecteur de fumée via système de pager internationaux (un système automatique d'extinction sera installé début 2005), la clim possède une double valve électrostatique pour couper l'eau en cas de détection de fuite (sur 2 niveaux). L'accès à la salle se fait par un lecteur d'empreinte digitale.

Utilisez-vous une ou des base(s) de données ? Si oui, quelles sont vos mesures de protection de celles-ci ? Est-on déjà parvenu à accéder ou à modifier des éléments de votre ou vos base(s) de données ?

M. Lucchi : Oui, plusieurs. Elles sont répliquées sur des machines physiquement délocalisées, et la communication réseau est bloquée vers ces machines, sauf depuis les hosts qui en ont besoin, donc interne exclusivement. Aucun problème n'a eu lieu, et aucune altération de donnée n'a jamais été constatée. C'est encore des serveurs SQL Microsoft et ce sera dans peu de temps (2 à 3 mois) des clusters MySQL redondants.

Faites vous appels à des organisme de paiement par carte bancaire ? Si oui, sur quels critères vous êtes-vous basés pour faire votre choix ? Si non, quel système de paiement avez-vous choisi ?

M. Lucchi : Oui, nous travaillons avec le Crédit Mutuel pour les encaissement par carte de crédit, et avec la Poste Suisse pour Yellownet. Les critères étaient "intégration avec nos outils" et "coût du service".

Quelle est la part de votre chiffre d'affaires investie dans des mesures de sécurité informatique ?

M. Lucchi : Non calculée... je ne pourrai vous le dire, le montant est peu important en tous les cas car une fois l'infrastructure en place, ce n'est que de la maintenance et plus de l'acquisition.

Quels arguments utilisez-vous pour donner confiance à vos clients ?

M. Lucchi : Le nombre de nos clients... plus de 20000 sites web qui fonctionnent, c'est la preuve que nous faisons bien notre travail. Nos conditions générales ne donnent aucune garantie à part celle du type "best effort". Notre intérêt est de toute façon de fournir le meilleur service possible, sinon nos clients ne restent pas, et nous avons un taux de résiliation vraiment très faible.

Votre entre prise emploie-t-elle un ou des informaticien(s) pour la gestion de votre parc informatique ou faites-vous appels à une ou des société(s) externes spécialisées?

M. Lucchi : Nous traitons tout en interne, 100%. Que ce soit la maintenance informatique hardware ou les développements logiciels spécifiques. Cela dit, le matériel utilisé pour notre plateforme d'hébergement vient de chez Dell et ils assument les interventions sur site. Nous ne nous en servons pas car nous intervenons plus vite qu'eux, mais c'est eux qui échangent le matériel défectueux que nous aurions déjà remplacé.

6 - Conclusion

Nous avons introduit dans ce rapport quelques menaces d'agressions informatiques auxquelles sont soumis les e-commerces et les diverses mesures de sécurités à prendre pour la bonne gestion d'un site de e-commerce. Toutefois, lorsque l'on gère un tel site, il est important de procéder à une veille technologique et de s'informer régulièrement sur les nouvelles menaces pouvant apparaître.

Nous n'avons par ailleurs pas aborder l'aspect des législations du e-commerce et il est de la responsabilité de chacun de s'informer à propos de ce que l'on a le droit ou pas de faire avec un e-commerce, que ce soit du point de vue des méthodes de ventes ou des formes de luttes contre les pirates en passant par les législations sur le contenu du site.

Ce rapport nous a permis de faire un tour d'horizon des problèmes auxquels sont confrontés les site d'e-commerce et de voir qu'un système bien pensé à la base permet d'éviter de grosses dépenses, aussi bien en énergie qu'en termes économiques. Par ailleurs, le contact pris avec M. Lucchi nous a permis de confronter notre étude avec la réalité.

7 - Discussion autour de la documentation

Vous pouvez poser toutes vos questions, vos remarques et vos expériences à propos de l'e-commerce. Pour cela, rendez-vous sur le Forum Sécurité.

8 - Suivi du document

Version 1.0, Le 20 janvier 2007, par Xavier MONNET et Sergio COELHO, Publication du document.