Un petit billet sur le Cloud computing pour répondre publiquement à une remarque que l’on m’a faite récemment : « après tout, je suis dans le Cloud et alors, qu’est-ce que je risque ? Les solutions sont redondées et la sécurité meilleure que celle que je peux assurer en interne. Où est le problème ? »

Soyons clairs : une prestation par exemple en mode SaaS opérée dans le Cloud peut être un formidable accélérateur de business pour l’opérateur économique, bénéficiant ainsi des économies d’échelle, de puissance parfaitement adaptée à ses besoins, scalable, etc.

Il n’en reste pas moins qu’il ne faut pas confondre vitesse et précipitation, et le contrat tout comme l’audit des prestations peuvent se révéler essentiels, comme les deux exemples ci-dessous vont le montrer.

Bien sûr, il est essentiel d’opérer un inventaire préalable et précis des données envoyées dans le Cloud, de déterminer à qui précisément elles sont confiées, dans quel pays elles seront traitées et avec quel niveau de sécurité (en prévoyant les problématiques de notification des brèches de sécurité), notamment pour des raisons de protection des données à caractère personnel, mais aussi pour des questions d’intelligence économique (pour l’application de lois étrangères aux données du Cloud, voir notamment cet article sur le « Patriot Cloud »).

De même, il est nécessaire de respecter les approches et visions des régulateurs intervenant dans la sphère d’activité considérée (cf. par exemple la position de l’ACPR en matière de Cloud et la notion d’externalisation de prestations de services essentielles ou PSEE au sens de l’arrêté du 3 novembre 2014).

Mais il est également essentiel d’étudier avec attention le contenu du contrat parfois un peu hâtivement signé et rarement – si ce n’est jamais – négocié.

Pour étayer ce propos, il suffira de mentionner le jugement de la première chambre du tribunal de commerce de Paris du 12 juillet 2011 : à l’occasion de l’externalisation de la plate-forme de messagerie électronique d’une société dans le Cloud (« le client »), des dysfonctionnements sont intervenus après sa mise en place. Le client avait émis des réserves lors de celle-ci, mais elles avaient été levées quelques semaines plus tard. Toutefois, plusieurs mois après, deux incidents étaient intervenus, le second ayant privé le client de messagerie pendant cinq jours. Considérant ce délai inacceptable et au vu de l’apparente incapacité du prestataire à résoudre durablement son problème, le client avait souhaité résilier le contrat aux torts du prestataire.

Or la lecture du contrat – et en particulier de son article 10 – apprenait que le prestataire avait non pas un ou deux jours, mais trente jours (!) pour résoudre l’incident, ce qu’il avait fait en l’occurrence.

Le client a donc été considéré comme ayant rompu abusivement le contrat et a été condamné à payer l’indemnité de résiliation conformément au contrat (égale au montant des trimestres restant à courir, soit 44 324,86 € plus les intérêts), sans compter les dépens du procès et 5 000 € au titre de l’article 700 du CPC.

Dans cette affaire, le contrat s’est appliqué dans toute sa rigueur… face à une société cliente qui avait visiblement minorée les risques contractuels, puisque considérant, au moment du blocage de sa messagerie, qu’un délai de rétablissement six fois inférieur au délai souscrit était finalement déjà bien trop !

L’affaire Code Spaces montre quant à elle que l’on peut avoir le meilleur contrat du monde… face à un prestataire n’appliquant pas les règles d’un bon professionnel, cela ne sert pas à grand-chose : l’audit est donc incontournable !

Rappelons que Code Spaces offrait l’hébergement en ligne de code source, sous-traitant en réalité l’hébergement sur Amazon AWS. Or ce service a été victime d’attaques informatiques diverses s’étant soldées par la prise de contrôle par les pirates de l’interface d’administration du service sur Amazon AWS.

Face à Code Spaces qui essayait de reprendre le contrôle de cette interface, les pirates ont choisi la politique de la terre brûlée. L’équipe de Code Spaces n’a pu alors que constater la terrible conséquence : « La majeure partie de nos données, de nos backups, les données de configuration des serveurs virtuels et les backups hors-site ont étés partiellement ou totalement détruits« .

Il semble en effet que ce service, se présentant sous le slogan très commercial et particulièrement vendeur de « solide comme le roc » et de « sécurisé » (« Rock Solid, Secure and Affordable Svn Hosting, Git Hosting and Project Management« ), n’avait pas fait le minimum de diligences qu’un professionnel de l’hébergement aurait faites, c’est-à-dire notamment de sauvegarder les fichiers de ses clients sur des médias non accessibles du réseau (sauvegarde « à froid »), sans parler de mieux protéger l’accès à leur interface de contrôle Amazon.

Le contrat pouvait en l’occurrence promettre monts et merveilles, il n’aurait pas empêché l’issue : la fermeture du service et la perte de la majorité des fichiers pour les clients. Mais c’est là que l’audit, réalisé par le client ou un tiers reconnu, aurait pu pointer les fatales négligences et avertir les clients plus précautionneux avant qu’il ne soit trop tard…

Bien d’autres aspects, que ce soit sur le plan de la gestion des risques, sur le plan technique ou sur le plan juridique, sont à sécuriser dans le cadre d’un projet Cloud et le but de ce billet n’est bien sûr pas d’être exhaustif.

En synthèse, gardons en tête que le contrat, comme les audits préalables et ultérieurs deviennent d’autant plus essentiels que la pression réglementaire s’intensifie sur les épaules de l’entreprise (obligations en terme de sécurité, de protection des données, de service rendu au client, etc.). La confiance envers ses prestataires « infonuagiques » n’exclut pas le contrôle !

Tagged on:     

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *