Suite de notre article sur le Cloud Computing, ses avantages, ses enjeux et les problématiques. Focus sur les précautions à prendre pour le DSI qui recourt à une offre « Cloud« .

(cf. première partie)

media_file_157
3. Des problématiques contractuelles renouvelées

3.1 La sécurité et la confidentialité du système d’information

Avec le Cloud Computing, l’entreprise n’a plus besoin d’investir de colossales sommes dans la constitution de son SI, qui est considérablement allégé puisque le réseau demeure tandis que l’entreprise peut supprimer ses serveurs et son infrastructure d’hébergement. Puisqu’il n’y a plus de serveur ni de salle blanche à sécuriser, les dépenses de verrouillage des bases de données disparaissent également. Certes, la situation n’est pas toujours aussi simple, et certaines offres proposent des serveurs équipés de machines virtuelles permettant l’utilisation distante.

Mais l’impératif de sécurité, lui, demeure. C’est d’ailleurs la principale objection des entreprises à l’adoption de solutions Cloud : quid de la sécurité et de la confidentialité des données, dès lors qu’elles ne sont plus stockées intra muros ?

La question n’est pas neuve, puisqu’elle se posait déjà dans des termes très voisins pour les prestations d’hébergement et d’infogérance – à ceci près qu’en mode ASP, la liaison est dédiée et peut donc faire l’objet de sécurisations complémentaire. En mode SaaS, les données passent par internet. L’infrastructure utilisée par le prestataire doit donc impérativement présenter des dispositifs de sécurité logicielle et matérielle (verrous et codes d’accès, badges, habilitations, systèmes anti-intrusion, anti-incendie, etc…). Le Cloud Provider est confronté à des demandes que l’infogérant connaissait déjà parfaitement, mais elles acquièrent une acuité nouvelle.

La question n’est pas neuve, mais elle est double : (i) quelle est la sécurisation des infrastructures sur lesquelles, in fine, les données et applications sont hébergées ? (ii) quelle est la sécurisation des réseaux publics par lesquels données et instructions transitent ?

La sécurité des infrastructures du prestataire

De fait, s’agissant des grands acteurs de l’informatique qui investissent le domaine du Cloud, on peut penser que les datacenters mis à disposition bénéficient des solutions de sécurisation dernier cri, ne serait-ce qu’en raison du préjudice d’image terrible qu’ils subiraient si leurs infrastructures Cloud étaient trop dangereuses. On a pu le constater récemment lorsque des entreprises comme Sony ou Nintendo ont essuyé des fuites de données colossales relatives aux utilisateurs de leurs solutions de jeux online.

L’entreprise ne doit pas s’en remettre aux seuls arguments commerciaux des prestataires : il est capital que le client qui externalise son infrastructure informatique, et en particulier ses bases de données, vérifie et au besoin exige du prestataire la mise en œuvre d’une solution de redondance (duplication de l’infrastructure afin de permettre la continuité de service sans interruption en cas de chute du premier système), une solution de résilience (ou « crash recovery »), et un système de gestion des habilitations et de traçabilité des accès, afin de prévenir et réprimer les éventuelles intrusions ou fuites de données.

En France, l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) et le Syntec ont édité des recommandations en matière de sécurisation des systèmes recourant aux offres Cloud. L’ANSSI comme le Syntec ont énuméré les principaux risques (perte de la maîtrise du système d’information et de visibilité sur les données, risques liés aux interventions à distance ou à l’hébergement mutualisé), avant de lister leurs préconisations (réclamer par contrat un hébergement dédié et non mutualisé, exiger un taux de disponibilité, la traçabilité des logs d’accès et de transaction, élaborer un plan d’assurance qualité tout au long du contrat, etc.).

A cet égard, la mutualisation des ressources informatiques véhicule le risque que les agissements d’un client aient un impact sur les données d’un autre client hébergé sur la même infrastructure, notamment si le premier client provoque une anomalie privant le second client du service. Il convient donc de prévoir au contrat, en cas de mutualisation, la prohibition absolue de toute intrusion non autorisée par l’hébergeur ou par un autre client mutualisé, et idéalement, obtenir du prestataire une garantie que les activités des autres clients n’auront aucun impact sur le service qu’il commande.

Une bonne solution consiste, pour le client, à établit un plan d’assurance sécurité (PAS), regroupant ses prérequis en la matière, et qu’il peut soumettre au prestataire en même temps que ses besoins fonctionnels. A l’instat du classique plan d’assurance qualité (PAQ), ce document peut acquérir valeur contractuelle et s’imposer comme référentiel de sécurité.

Du côté du prestataire, il est impératif d’exiger du client qu’il soit responsable des données qu’il envoie sur le réseau et fait héberger sur ses serveurs, car dès lors que ces serveurs sont mutualisées, il existe un risque que les données défectueuses d’un client corrompent les données des autres clients. La partition entre données de différents clients est donc importante pour les deux parties au contrat, et le client doit être sensibilisé aux risques que ses données peuvent faire courir aux tiers.

On mesure à quel point ces recommandations sont aux antipodes du principe du contrat d’adhésion. Le client ne peut pas s’en remettre à une offre standardisée, sauf à ce que cette offre réponde déjà à l’ensemble de ces préconisations. Et le prestataire doit attirer l’attention du client sur la responsabilité de ce dernier sur ses données. Le prestataire a tout intérêt, d’ailleurs, à proposer un « plan d’assurance sécurité » à ceux de ses clients qui n’en disposeraient pas : il les rassurerait ainsi sur la question de la sécurité en montrant qu’il s’agit d’une préoccupation spécifique au sein de son offre commerciale.

C’est donc au sein du contrat que les niveaux de sécurité et de confidentialité doivent être stipulés : l’entreprise acceptera d’autant mieux de transférer ses données « dans les nuages »… si le nuage est blindé.

Il est indispensable que le contrat de service aborde l’ensemble des précautions techniques et organisationnelles de sécurisation, et établisse clairement la répartition des responsabilités entre le client et le prestataire. La notion de « matrice des responsabilités », si utile dans les grands contrats d’implémentation d’ERP, demeure donc très pertinente également pour les services distants.

De cette matrice des tâches découlera fort logiquement, pour le juriste, une répartition des responsabilités (notamment en termes d’obligation de moyens ou de résultat, de gestion des habilitations, de sauvegarde…), et la nécessité de tracer, pour le client comme pour le Cloud Provider, la parfaite exécution des tâches et précautions leur incombant respectivement en matière de sécurité et de gestion des habilitations. Une clause d’audit peut également être prévue, mais là encore on imagine mal les contrats standards des plus grands Cloud Providers la prévoir spontanément…

Ainsi, quel est le risque exact de défaillance d’un prestataire Cloud ? Bien entendu, ce risque varie d’un prestataire à l’autre. Mais contrairement aux idées reçues, le recours au Cloud Computing n’est pas forcément, en soi, une fragilisation de la protection des données : il faut bien comprendre que les datacenters mis à contribution sont particulièrement sécurisés, les dispositifs de supervision, de redondance et de résilience sont robustes. C’est le cas du « Cloud centralisé », peut-être un peu moins s’agissant du « Cloud disséminé » puisqu’un nombre important de clients partagent les infrastructures nombreuses, ce qui peut augmenter les sources potentielles de défaillance.

Mais la sécurisation des infrastructures du prestataire n’est pas la seule en cause. Il ne sert à rien d’exiger du prestataire que ses datacenters soient des forteresses imprenables, si le système d’information résiduel du client est ouvert aux quatre vents.

La sécurisation de l’infrastructure résiduelle du client

Le Cloud Computing impacte très directement la politique de sécurité et de confidentialité de l’entreprise. Si les bases de données ne sont plus hébergées en son sein, en revanche les accès doivent être quant à eux parfaitement balisés et sécurisés. De même, le Cloud a un impact sur la Charte informatique de l’entreprise, qu’il faut réviser et adapter à ce nouveau contexte de dématérialisation des ressources informatiques, dans lequel le code d’accès compte infiniment plus que le badge. La charte informatique doit donc appréhender le caractère critique des identifiants, et habituer le personnel à des comportements vertueux.

Dans le même temps, la PSSI devient une préoccupation centrale de l’entreprise, et la DSI, qui peut relâcher son attention en termes de maintenance technique, doit au contraire redoubler d’efforts en matière de sécurisation des connexions. La PSSI est d’autant plus importante si l’entreprise est un groupe commerçant, dont le SI est connecté à de nombreux points de vente sur le territoire, ou utilisé par de nombreux services différents dotés d’habilitations en conséquence.

Le contrat de service devrait donc, idéalement, comporter une clause permettant au professionnel de rappeler, dans le cadre de son obligation de conseil, qu’il est capital pour le client de mener en interne une conduite du changement afin de sensibiliser son personnel aux conséquences de la dématérialisation, mais aussi et surtout de sécuriser ses propres accès : gestion de logs, listes blanches ou noires d’applications, contrôle du téléchargement, gestion automatisée des évènements, journalisation des accès, gestion rigoureuse des habilitations, etc.

Pourtant, ces précautions techniques et contractuelles ne sont pas suffisantes. Le Cloud implique le recours au réseau internet, qui par définition n’est pas protégé. Certes, les protocoles sécurisés de type « https » utilisent un algorithme de chiffrement et un certificat d’authentification, mais de simples stratégies de piratage suffisent à contourner la protection.

La sécurité des communications ne doit pas devenir un élément de défiance face aux services distants,
mais appelle une conscientisation des entreprises et des particuliers encore bien trop embryonnaire.

La sécurisation du réseau ?

Le talon d’Achille du Cloud Computing n’est donc pas à proprement parler la sécurité des infrastructures utilisées par les prestataires pour héberger données, applications et architectures virtuelles, mais la sécurité du chemin emprunté entre ces datacenters distants et l’entreprise : c’est l’internet qui constitue la zone de risque. Ainsi, de plus en plus de prestataires se lancent dans l’activité de sécurisation des réseaux. On constate l’éclosion d’offres « UTM » (traitement unifié de la menace), essentiellement logicielles (antivirus, firewalls, VPN, chiffrement SSL, PKI, contrôle d’accès conformes aux standards internationaux tels que les Critères Communs ISO/CEI 15408).

D’autres se lancent dans la multiplication d’offres de « Cloud privé », qui, par opposition au « Cloud public », désigne un réseau intégralement privé détenu par le Cloud Provider (ex : « Virtual Private Cloud » d’Amazon). Dans le « Cloud privé », la dépendance envers le prestataire est totale, mais on élimine une grande partie des risques de sécurité liés à l’emploi du réseau internet. Schématiquement, le « Cloud Privé » est au Cloud Computing ce que le VPN est au Net – et semble remporter les suffrages de nombreux DSI selon les études les plus récentes.

De ce fait, certains acteurs comme IBM se lancent dans des offres « réseaux hybrides », afin d’interconnecter les « Clouds privés » et le « Cloud public », en tablant sur la diversité des systèmes d’information et de la coexistence de réseaux physiques et de réseaux virtuels. Les conditions de ces interconnexions doivent alors faire l’objet de clauses spécifiques dans les contrats de services.

On peut également songer à des contrats qui imposent aux parties de sécuriser les réseaux situés sous leur responsabilité (réseau interne de l’entreprise, réseau couvert par le prestataire jusqu’à internet) et de mettre en place une prestation de cryptographie. Le client peut ainsi exiger un chiffrement des transactions distantes conforme aux meilleurs standards en vigueur, voire documenter les conditions de cette sécurisation (clé de chiffrement, certificats numériques, etc…). Partant, il faut donc conseiller à tout client qui recourt au SaaS ou plus généralement au Cloud de s’interroger sur la nécessité d’une prestation autonome de renforcement de ses communications électroniques (VPN, chiffrement) et d’inclure dans sa réflexion globale le coût et la complexité de cette sécurisation.

On le voit, si un client s’en remet à un prestataire Cloud pour assurer le traitement, la sécurité et la confidentialité de ses données, alors le contrat devient l’outil de maîtrise par excellence, l’instrument qui permet au client de conserver un minimum de contrôle.

Mais tout hébergeur, tout infogérant sait une chose : il est impossible de sécuriser l’internet. Ces professionnels, qui prenaient soin de signaler dans leurs contrats qu’ils sont soumis aux aléas techniques inhérents aux communications électroniques, savent que le risque zéro est une chimère, et que seule la traçabilité permet de conférer un minimum de protection aux clients. C’est donc sur la traçabilité que le client doit également exiger des réponses du Cloud Provider.

La nécessaire traçabilité des actions

Compte tenu de l’opacité qui accompagne, pour le client, l’externalisation de son SI vers une infrastructure dont il ignore la composition et la localisation, la traçabilité des actions du prestataire et du respect de tous les niveaux de service devient capitale, et le contrat de service doit également lui faire la part belle. Les métriques (SLA, RTO, RPO, etc…) deviennent particulièrement importantes, et doivent être définies avec soin par le client avant d’être contractualisées.

Surtout, il est capital que ces informations de traçabilité soient transmises au client lui-même. Il doit pouvoir contrôler a posteriori toute intrusion, toute utilisation de son infrastructure informatique virtualisée ou de son application en ligne, ne serait-ce que pour être en mesure d’établir la preuve d’un comportement illicite dont il serait victime (de la part d’un tiers mal intentionné ou même de l’hébergeur indélicat).Il est également vivement recommandé que le client s’aménage par contrat un accès propre à l’ensemble des indicateurs relatifs à son SI.

Rappelons au passage que même s’il ne s’agit pas pour le client de prouver une intrusion ou une fuite, il peut être sollicité par la justice pour répondre d’actes commis par ses salariés via son système d’information virtualisé. Il est donc là encore très important pour lui de disposer des traces de connexion. Il n’est donc pas possible de s’en remettre entièrement à la supervision du Cloud Provider, contrairement aux apparences : les traces d’accès sont vitales en cas de contentieux. La protection du système d’information virtualisé, ainsi que la protection du secret d’affaires et des données des salariés, dépendent donc directement de ces précautions.

3.2 La continuité des services

Lorsque le logiciel est installé sur l’environnement du client, c’est en cas de dysfonctionnement dudit logiciel que le client recourait à la maintenance corrective de l’éditeur – ou d’un tiers-mainteneur. En revanche, avec le Cloud, le risque est devenu l’indisponibilité du service. On raisonne donc moins en termes de conformité qu’en termes d’accessibilité : l’anomalie n’est plus (forcément) un bug logiciel, mais (plutôt) une rupture d’accès.

Dans les contrats d’infogérance ou d’hébergement, la notion de continuité du service faisait déjà l’objet d’attentions particulières. Dans les années 90, à mesure que les prestations de ce type se sont affinées, les professionnels ont pu définir des métriques permettant de quantifier un taux de disponibilité acceptable, aujourd’hui de l’ordre de 98 ou 99%.

Néanmoins, passer d’une logique de conformité à une logique de disponibilité supprime en toute hypothèse la notion d’obligation de résultat : tout infogérant prend soin de réserver les aléas liés aux communications électroniques, les risques d’engorgement, de chute de bande passante, etc. pour ne s’engager, très logiquement, que dans le cadre d’une obligation de moyens.

Avec le Cloud, la défaillance est toujours possible, et s’analyse donc en termes de disponibilité. La grande force du Cloud, du moins s’il est authentique, est de répartir les ressources nécessaires (bande passante, espace-mémoire) sur un grand nombre de CPU parfois très distants entre eux, ce qui a pour effet de faciliter la redondance, et surtout d’augmenter encore la fiabilité du système. Le taux de disponibilité peut avoisiner les 100%, dans la mesure où cette dissémination des ressources assure un service quasiment constant.

Ceci n’empêche nullement le client d’exiger des niveaux de service, bien au contraire. C’est ici que se juge l’adéquation du service à ce qu’en attend le client, qui doit pouvoir traiter à distance de grandes quantités de données, comme si son SI était toujours hébergé dans ses locaux. On retrouve ici des métriques liées aux temps d’indisponibilité (SLA, GTI, GTR, volumétries, etc.) qui doivent être contractualisées et s’imposer au prestataire.

Il est donc très important pour le client de ne pas se contenter des performances annoncées par le prestataire, et d’exiger par contrat qu’un taux de disponibilité soit constamment maintenu et que des SLA soient définis et respectés. On ne raisonne donc plus en termes de maintenance corrective, mais de rétablissement du service.

De même, les mises à jour de logiciels ne se posent plus en termes de renouvellement ou de commande de nouvelles licences, mais sont implémentées directement sur le service, sans interruption de disponibilité, ce qui accélère encore la maintenance évolutive des logiciels et le déploiement des mises à jour et nouvelles versions majeures. Mais il est alors très légitime pour le prestataire de refuser de maintenir des versions trop anciennes des logiciels, ou de décliner toute garantie de compatibilité, si le client refuse ou reporte l’installation de ces mises à jour. On retrouve ici une certaine forme de « captivité », mais elle est indispensable au maintien de la sécurité et de la pérennité du service.

Il est donc indispensable d’accompagner le contrat de services d’une grille des SLA, exposant l’ensemble des indices de contrôle de la solution informatique Cloud, les moyens de les mesurer, les mesures d’urgence à adopter, et idéalement, les pénalités à appliquer si le taux de disponibilité n’est pas au rendez-vous.

3.3 La réversibilité des services

Autre question cruciale liée au Cloud : la réversibilité du service. Il s’agit de la restitution au client de l’ensemble des éléments externalisés (données, applications), ainsi que la transmission de compétences au personnel du client (ou d’un nouveau prestataire) en cas de résiliation ou de défaillance du précédent.

Le Cloud Computing peut singulièrement renforcer la situation de dépendance par rapport au prestataire, puisque celui-ci n’est plus seulement chargé d’un déploiement ou d’une maintenance : c’est lui qui héberge les données, gère les accès et permet les transactions. Le client doit donc impérativement prévoir la fin de contrat, et la possibilité pour lui de recouvrer l’ensemble de ses données et applications le plus simplement et le plus rapidement possible.

Cette dépendance existait déjà du temps de l’infogérance, il ne s’agit pas non plus ici d’une nouvelle problématique juridique. Cependant le Cloud amplifie bien cette dépendance puisqu’à la dépendance technique s’ajoute aujourd’hui une dépendance fonctionnelle quasiment totale.

Il est impératif que le contrat de service prévoie une clause de réversibilité comportant notamment la description des formats standards d’hébergement et les API utilisées, ainsi qu’un plan de réversibilité régulièrement tenu à jour dès le début du contrat. La réversibilité doit également s’accompagner de l’engagement ferme du Cloud Provider de détruire toute copie des données, et toute trace du SI du client, après l’exécution de la réversibilité.

Les conditions d’archivage et d’accès aux données hébergées à distance doivent également faire l’objet de stipulations contractuelles spécifiques, interdisant au Cloud Provider toute copie des données pour son compte ou le compte d’autres clients, et plus généralement toute réexploitation des données du client. Le prestataire préfèrera quant à lui laisser au client la charge de l’archivage, car cela représente une responsabilité particulière (durée de l’archivage compatible avec les obligations légales du client, intégrité des données conservées, etc.).

Mais l’enjeu le plus important est ici l’indépendance du client, qui doit pouvoir poursuivre ses activités sans interruption même en cas de changement de Cloud Provider. L’idéal est de prévoir un accès aux codes sources du prestataire pendant une durée déterminée à la fin du contrat, sans que le prestataire ne puisse y opposer ses droits de propriété intellectuelle – mais la complexité des offres Cloud rend cette exigence plus théorique.

C<’est avant tout le plan de réversibilité, érigé en document contractuel par la clause de réversibilité, qui devra prévoir toutes les conséquences du changement de prestataire ou de la ré-internalisation du SI, afin d’éviter de dramatiques interruptions d’exploitation ou des pertes de données. Dans le cadre de leur obligation de conseil et pour rassurer leurs prospects, les prestataires doivent être extrêmement proposants en la matière.

Il incombe donc au DSI, dans tous les cas, de se rapprocher de sa direction juridique pour vérifier que les conditions contractuelles du service envisagé respectent ses exigences en termes de sécurité et de réversibilité (cf. infra).

Une question complémentaire se pose aux DSI : que faire des infrastructures préexistantes, que l’entreprise a peut-être amorties mais qui représentent des immobilisations encombrantes, dont l’utilité disparaît… au moins jusqu’à une éventuelle ré-internalisation !

(à suivre)