L’incendie survenu chez OVH Strasbourg nous rappelle que tout peut arriver à tout moment. Quelles mesures auraient pu être prises pour éviter toute perte de données et interruption de service? C’est ce que nous allons essayer de voir ici.
Contrairement aux autres centres d’OVH, les datacenters de Strasbourg n’étaient pas dotés de solutions d’extinction, ce qui parait assez surprenant. Le modèle low cost d’OVH est, du coup, très sérieusement pointé du doigt par rapport à d’autres hébergeurs qui, eux, ont investi dans des systèmes anti-incendie et respectent des normes et des certifications plus exigeantes.
La prévision de l’incendie a donc été quasi-nulle pour le bâtiment totalement détruit (lire l'article "Incendie de OVH SBG2 incident évitable ?"). La question pour la majorité des responsables des sites est de pouvoir les relancer et surtout de pouvoir récupérer les données. Toutes les données ne sont pas nécessairement perdues selon que les entreprises avaient ou non mis des systèmes de backup et des PRA (plans de reprise d’activité) en place de leur propre chef ou chez OVH. À savoir que les sauvegardes de données de SBG2 chez OVH étaient localisées dans SBG1, sur le même site géographique. C’est une erreur tactique fondamentale qui va à l’encontre des bonnes pratiques, bien surprenante de la part du fournisseur de Cloud. Et comme cet autre bâtiment a lui aussi subi l’attaque des flammes et a été en partie endommagé, certaines de ces données sont irrémédiablement perdues – sauf si les clients ont eu la bonne idée de faire des sauvegardes de leur côté, ce qui n’est apparemment pas le cas de tous aux dernières nouvelles.
Il ne faut pas oublier que, globalement, la responsabilité de la conception et de la mise en place d’un plan de reprise d’activité incombe aux entreprises et organismes clients, et non au fournisseur de service cloud ou à l’hébergeur. Seule l’activation du PRA et son exécution peuvent être partagées entre le fournisseur et le client, à moins que OVH ne se soit spécifiquement et explicitement engagé à garantir la sauvegarde des données du client. Suite à cette catastrophe d’une ampleur sans précédent dans le milieu du Cloud et de l’hébergement, plusieurs clients ayant perdu tout ou partie de leurs données ont pointé du doigt la responsabilité de l’hébergeur. Certes, il est possible voire très probable que la protection du bâtiment détruit ait été très insuffisante. Néanmoins, ces accusations reposent sur une méconnaissance de la chaîne de responsabilité. Toute entreprise se doit normalement de prendre les mesures utiles afin de protéger ses données et garantir la continuité de son activité en cas de sinistre, même si OVH ne les a pas clairement mis en garde.
Les trois bonnes pratiques absolument nécessaires à la protection des données
Les principes de bonne gestion en matière de sauvegarde de données et de continuité d’activité ne sont pas vraiment nouvelles. Encore faut-il les appliquer consciencieusement pour se prémunir contre tout sinistre. Ces trois bonnes pratiques sont les suivantes :
• en premier lieu, il est indispensable de lire très rigoureusement les contrats liés à l’externalisation de ses données. La responsabilité de chaque partie en cas de sinistre doit être clairement précisée. Au passage, il est préférable pour une entreprise française ou européenne que la compétence soit attribuée à un tribunal sous juridiction européenne;
• quel que soit le contrat signé avec le prestataire, il convient d’observer très scrupuleusement la règle de sauvegarde du 3/2/1, consistant à disposer d’au moins trois copies de ses données, à stocker ces copies sur (au moins) deux supports différents et enfin à conserver au moins une copie de la sauvegarde en dehors du site de production. Ces sauvegardes doivent être déconnectées d’Internet (stratégie d’air gap) pour éviter tout risque de corruption ou cryptage des données par une cyberattaque sophistiquée de type cryptolocker. C’est malheureusement ce que n’a pas fait OVH en stockant les sauvegardes sur le même site.
• enfin, la conception et mise en place d’un PRA (plan de reprise d’activité) est cruciale pour récupérer et pouvoir exploiter ses données rapidement après un incident. Les entreprises doivent prévoir l’éventuelle reconstruction de leur infrastructure informatique et la remise en route de leurs applications en cas de sinistre. Toute activité considérée comme critique doit être clairement identifiée lors de l’élaboration du PRA. Chacune de ces activités doit faire l’objet d’un plan définissant précisément les besoins humains et matériels et les coûts liés au déclenchement de ce plan. Ce dernier doit définir la PMDA (Perte maximale de données autorisées) et le DMIA (dDélai maximal d’interruption autorisé).
Le mythe de la responsabilité partagée
En choisissant une offre «as a service», les entreprises délèguent la gestion de tout ou partie de leur infrastructure à un fournisseur de services cloud. Quel que soit le type de délégation choisie, IaaS, PaaS ou SaaS, la responsabilité de la protection des données reste par défaut à la charge de l’entreprise qui en est propriétaire. Parmi les applications les plus connues des offres Saas vous trouvez Dropbox, Microsoft 365 ou encore Salesforce. Concernant Microsoft 365, Microsoft assure, certes, un niveau de protection minimum des données. Néanmoins, les entreprises clientes doivent prévoir des protections autonomes supplémentaires de leur propre initiative. Elles doivent prendre connaissance de manière précise du ou des lieux où sont hébergées leurs données et applications (notamment les serveurs primaires), des lieux de réplications éventuels (serveurs secondaires) et des chemins d’accès aux données et procédures de redémarrage des applications prévues en cas de sinistre, les PDMA et DIMA contractuelles associées évoquées plus haut. Elles doivent aussi exiger avec fermeté d’être informées en cas d’évolution de l’architecture en cours de contrat. C’est typiquement, même si cela est facile à dire après coup, ce qu’auraient dû faire les clients d’OVH, surtout ceux dont les données, perdues dans l’incendie de SBG2, étaient stockées dans la partie de SBG1 détruite.
La très forte dépendance des organisations à leur informatique et plus spécifiquement à leurs données doit conduire à prioriser les investissements en sauvegarde et en cybersécurité. Encore une fois, sauvegarde et PRA doivent constituer le rempart ultime contre tout sinistre éventuel.
Des questions incontournables
La rapidité et l’ampleur de cet incendie sans précédent dans le monde des datacenters a soulevé des interrogations tant chez les professionnels du risque et de la sécurité incendie qu’au sein même de la profession de l’hébergement de data et du Cloud. Le système d’extinction de feu a-t-il bien fonctionné? La détection de feu doit en principe déclencher automatiquement le système d’extinction. On ne dispose que de quelques minutes pour étouffer le feu. Dix minutes après, il est déjà trop tard. Dans ses datacenters d’Amérique du Nord, OVH utilise des sprinkler, système qui asperge d’eau les baies depuis le plafond. C’est plutôt efficace mais assez ravageur sur les serveurs. Ce système d’extinction est obligatoire aux États-Unis mais pas en Europe où on lui préfère généralement deux autres méthodes alternatives. La plus ancienne consiste à projeter dans l’air un gaz inerte constitué d’un mélange d’azote et d’argon. Celui-ci vient capter l’oxygène indispensable à la combustion et coupe ainsi le feu. Le gaz est éjecté depuis des bouteilles sous pression. Cette solution est très bien adaptée aux petites surfaces. Pour les grandes surfaces, il faut beaucoup de bouteilles et d’espace pour les stocker. Cela rend alors cette solution très onéreuse car même si le feu se limite à un seul endroit, tout l’air de la salle doit être traité. C’est pourquoi la solution récente la plus employée est le brouillard d’eau. Cette technique consiste à projeter des microgouttelettes d’eau qui viennent absorber la chaleur dans l’air et éteindre le feu par étouffement. Il offre l’avantage d’adapter le traitement par zone. C’est le système employé par Scaleway et par OVH en Europe, mais pas sur tous ses sites. Ce n’était malheureusement pas le cas pour SBG1 et SBG2, a priori.
Résilience et redondance pour un PRA efficace
Au-delà du retour d’expérience malheureux que cet incendie provoquera sans doute chez OVH, avec les éventuels changements nécessaires à exécuter dans les autres data centers du groupe, cette histoire illustre les enjeux de redondance – duplication des sauvegardes sur plusieurs sites géographiques) – et de résilience – résistance aux aléas et réactivité pour remettre en route les systèmes, soit un PRA efficace, en résumé. Cela doit être particulièrement le cas pour les services les plus critiques ou les plus souverains. La perte temporaire de la plate-forme Data.gouv.fr en constitue un exemple criant, même si elle a pu être rétablie assez rapidement. Cela peut passer par la nécessité, si l’on entre dans l’une ou l’autre de ces deux catégories, de faire appel à deux prestataires distincts, et non à un seul, au cas où l’un des deux ferait défaut. Le minimum légal est, sinon d’avoir deux prestataires, au moins d’avoir plusieurs sauvegardes éloignées géographiquement et un PRA efficace testé en amont, permettant une remise en route très rapide voire immédiate. Cela peut éventuellement consister à passer par un prestataire pour l’hébergement et, pour ce qui est de la sauvegarde, d’opter pour une autre société. Les gros hébergeurs peuvent certes proposer des abonnements et des options spécifiques pour procéder à des sauvegardes automatiques et les stocker dans plusieurs centres. Si ce n’est le cas ,ou si le client n’a pas choisi ce type de contrat, il faut alors que le responsable d’exploitation du service déploie une autre stratégie. Il est facile de faire des reproches à OVH, qui a certainement manqué de clairvoyance dans sa gestion du risque, mais la responsabilité finale ne lui incombe pas concernant la perte de données si aucun contrat signé ne le précise nommément. Et quand bien même, il vaut mieux avoir plusieurs cordes à son arc, et pas toutes rangées au même endroit. Tout ceci nécessite un minimum d’investissement. Quand un tel désastre survient, il est un peu tard pour pleurer et se dire qu’il aurait dû être fait. Les économies réalisées sur la réplication, la sauvegarde et le PRA peuvent finalement avoir un prix très élevé, allant jusqu’à la fermeture d’une entreprise, et ce n’est pas qu’une vue de l’esprit.
Les cygnes noirs
Au niveau mondial, une entreprise sur trois aurait déjà connu une perte de données irréversible. Ces pertes peuvent être liées à des catastrophes naturelles, à des erreurs humaines, des vols ou attaques de données de type cryptolocker ou encore à des pannes matérielles. Ces événements aux conséquences dévastatrices souvent difficiles à prévoir sont appelés des cygnes noirs. Les cyberattaques sont cependant, de par leur fréquence en constante augmentation, à mettre de côté, la probabilité de rencontrer ce type d’incident étant de plus en plus élevée. Ce ne sont donc plus vraiment des cygnes noirs, mais tout juste des corbeaux ou des merles moqueurs.
Gérer soi-même ses sauvegardes et son PRA
Il faut avant toute chose lutter contre une idée largement répandue surtout dans les petites organisations. Le fait de confier l’hébergement de ses données, de ses applications ou de ses serveurs à un prestataire de cloud computing n'inclut pas de facto la protection de son écosystème de données. Ce point est clairement mentionné dans les conditions générales de vente des hébergeurs tout comme dans celui des fournisseurs d’applications en mode cloud. La responsabilité de la conception et mise en place d’un PRA incombe donc aux entreprises, et non au fournisseur de service cloud ou à l’hébergeur. Seule l’activation du PRA et son exécution peuvent être partagées entre le fournisseur et le client.
Une violation de données selon la Cnil
La destruction d’un datacenter est susceptible de constituer une violation de données, avec le lot d’obligations légales que cela implique. La Cnil en a fait le rappel dans une publication datée du 21 mars. Dans son article, la Cnil ne vise pas spécifiquement OVH et ne fait que rappeler des points de droit et des obligations des responsables de traitement. Notamment que ceux-ci doivent documenter la violation dans un registre, tandis que les sous-traitants doivent informer leurs clients afin qu’ils s’acquittent de ladite obligation.
Sur les notifications à la Cnil et la communication aux personnes, la Cnil précise que celle-ci n’est pas nécessaire si un PRA est mis en œuvre, ou si un PCA a permis la continuité des activités. De même, si les données ont été restaurées à partir de sauvegardes et qu’il n’y a pas de conséquence significative sur les personnes.
Mais, dans le cas de perte définitive des données personnelles, ou si celles-ci sont restées indisponibles sur une période significative, la Cnil doit être notifiée. « Le niveau de risque s’évalue notamment en tenant compte du type de données concernées et des conséquences potentielles de la violation – par exemple, la perte définitive de données de santé d’un patient est susceptible de présenter un risque élevé. » G. P.