Une donnée informatique, ça brûle

Le 10 mars dernier, plusieurs datacenters d'OVHcloud prenaient feu à Strasbourg. Si l'incident a rapidement été maitrisé, les dégâts ont été importants, tout comme les conséquences pour les clients. Alors que la société tire les premiers enseignements, retour sur quelques fondamentaux de la protection des données.

Hier, Octave Klaba et Michel Paulin prenaient la parole pour faire le point 50 jours après « l'incident à SBG », pendant lequel plusieurs datacenters de l'hébergeur ont été dégradés ou détruits. L'enquête judiciaire, qui doit déterminer les causes et responsabilités de l'incendie, est toujours en cours.

Incendie de Strasbourg : OVHcloud veut devenir « hyper-résilient »

Désormais, 118 000 des 120 000 services touchés ont été restaurés, une page dédiée étant régulièrement mise à jour pour faire le point sur la situation. Une FAQ est aussi disponible. L'entreprise passe désormais à la phase des gestes commerciaux, des remises ou remboursements devant être envoyés aux clients concernés d'ici peu.

Les deux dirigeants évoquent au passage l'équipe de support renforcée ou celle mise en place spécifiquement pour répondre sur les réseaux sociaux. Les 15 000 serveurs fabriqués en urgence dans l'usine de Croix, les 200 personnes qui ont été mobilisées sur le site (elles sont une centaine désormais). Il faut maintenant préparer la suite.

Et cela tient en un mot : « hyper résilience ». Avec l'incident de Strasbourg, la stratégie de sauvegarde mise en place a en effet montré ses limites. Il faut donc désormais rassurer sur ce point. Une « mini-région » située dans une nouvelle zone géographique non précisée va ainsi être construite, composée de quatre datacenters, devant assurer toutes les sauvegardes internes, mais aussi être mise à disposition des clients, sans surcoût.

Klaba parle ainsi de sauvegardes « gratuites » (sans plus de précisions), ajoutant qu'OVHcloud veut devenir « un expert de la protection de données », ouvert à toutes les solutions du marché. Plusieurs dizaines de millions d'euros sont investis dans ce sens, l'entreprise promettant aussi de revoir la conception de ses datacenters.

Cela concernera les nouveaux bien entendu, mais aussi les actuels qui doivent être mis à jour en conséquence. Enfin, une région située dans la couronne de Paris va être créée, composée de trois datacenters éloignés de 10 à 30 km chacun, avec une réplication constante. Un standard du genre, que la société semble vouloir systématiser.

Protection des données, sécurité : trop souvent délaissés

Si les choses avancent dans le bon sens, cela nous rappelle qu'à force de dématérialiser, certains ont oublié que l’informatique, même lorsqu'elle est vendue à travers le concept de « cloud », repose sur du matériel physique. En gestion de risques, l’information est un « actif primordial » s’appuyant sur un « actif support » (matériel, logiciel, etc.). Le stockage et le transfert de l’information utilisent du matériel qui peut brûler, être dégradé, volé, corrompu, saisi, etc. Il doit donc être protégé, car il est sensible aux sinistres en tout genre.

Notre dossier sur la protection des données en datacenter :

• Une donnée informatique, ça brûle
• Datacenter et incendie : règles à suivre, normes et assurances (à venir)

La sécurité informatique est mal-aimée en informatique : trop souvent mise de côté, on ne se rend compte de son importance que lorsqu’on subit une attaque majeure telle qu’un ransomware virulent. Quant à la sécurité physique, elle fait figure de mal-aimée de la sécurité informatique, encore plus souvent négligée, et lorsqu’elle est prise en compte, cela se fait à reculons. Or le vol de disque dur ou l’explosion d’alimentation électrique ne datent pas d’hier.

Quand on a la responsabilité d’applications informatiques, on est tenu de prendre les mesures appropriées pour assurer une qualité de service compatible avec les exigences du métier : seul le propriétaire du business peut déterminer ce qu’il est important de sauver ou la durée d’indisponibilité acceptable.

Une fois cela défini et connu, il faut faire les choix d’architecture (informatique) et de fournisseurs adaptés, avec une gestion des risques rigoureuse. Par exemple, si notre application est critique, il ne faut pas mettre tous ses œufs dans le même panier et la perte d’un datacenter est un scénario à envisager et à anticiper.

Si vous avez attendu d'être touché par un cas comme celui d’OVHcloud pour vous poser la question de la protection de vos données, il est trop tard. Si des sauvegardes sont prévues avec votre hébergement, il aurait été judicieux de vérifier par avance qu’elles ne sont pas sur le même site géographique, car les offres basiques des fournisseurs en ce domaine se limitent souvent à un espace FTP dont on ne connaît pas la localisation.

Mais surtout, c'est à vous de les (faire) réaliser au bon moment et au bon endroit. On répètera encore les règles de base, sans oublier qu’une sauvegarde n’est réussie que lorsque la restauration a fonctionné correctement ! Pensez donc également à les vérifier régulièrement, en simulant des scénarios catastrophes par exemple.

L'importance de connaître ce que l'on achète

L'un des points « positifs » de l'incendie d'OVHcloud à Strasbourg est donc qu'il incite les acteurs, impactés ou non par le problème, à se poser la question de la manière dont leurs données sont protégées. Et à faire le point sur les pratiques en la matière, notamment chez les hébergeurs qui communiquent plus ouvertement. 

L'autre géant français de l'hébergement, Scaleway, a notamment détaillé ce qu'il mettait en œuvre, revenant par la suite sur les raisons qui ont motivé certains de ses choix. On pense notamment à la redondance à travers les différentes zones de disponibilité d'une région, au nombre de trois dans l'idéal, mais ce n'est pas toujours le cas.

Comme le rappelle Arnaud de Bermingham dans ce billet de blog, les datacenters (DC) sont un lieu physique où se trouvent les équipements (serveurs, connexions, alimentation électrique, refroidissement). Il s'agit de l'une « des localisations physiques d’une zone de disponibilité ». Ces dernières, nommées AZ, se composent d’un ou plusieurs datacenters « situés dans une zone géographique d'environ 5 km avec une latence interne maximale de 1.4 ms et à minimum 50 km d’une autre zone de disponibilité de la même région ».

Scaleway donne l'exemple de fr-par-1 « constituée des datacenters DC2 et de DC3 et la zone de disponibilité fr-par-2 est constituée du datacenter DC5 ». fr-par-3 arrivera « prochainement » reposant sur le prochain datacenter DC4.

Enfin, les régions regroupent plusieurs AZ avec un réseau « unique qui est dissocié (non interconnecté) des autres régions ». La filiale d'Iliad compte trois régions : Amsterdam, Paris et Varsovie. Exception pour la première : son réseau n'est pas dissocié « pour des raisons historiques est aussi un lieu de peering pour la région Paris ».

Si « le design cloud public idéal s’appuie généralement sur trois zones de disponibilité dans une même région » (dans un rayon de 200 km) ce n'est pas toujours le cas et c'est à prendre en compte : 

« Ceci n’a aucun impact sur les produits IaaS. Pour les produits PaaS, le niveau de disponibilité et la résistance à un sinistre ainsi obtenu ne sont pas aussi optimaux qu’avec un design à trois zones de disponibilité. Ce point a été identifié depuis longtemps mais nous avons toujours refusé catégoriquement le compromis qui consiste à avoir plusieurs zones de disponibilité, cluster ou datacenter virtuel dans le même datacenter physique.

Pour éviter d’induire nos clients en erreur, nous leur recommandons systématiquement de construire leurs infrastructures sur plusieurs régions, ce qui est la solution la plus élégante pour avoir un service redondé et haute disponibilité.

Les investissements sont déjà validés depuis le début d’année, avec l’ouverture en 2021, de trois nouvelles zones de disponibilité additionnelles sur nos trois régions actuelles. Notre stack logicielle PaaS est conçue dans cette optique et sera redéployée en conséquence d’ici la fin d'année. »

Un discours qui montre bien que derrière la simplicité du « tout Cloud », la réalité est plus complexe. Les clients se doivent donc de comprendre ce qu'ils achètent. On regrette d'ailleurs que les obligations légales en matière d'information à ce sujet ne soient pas plus strictes. Une problématique qui ne touche pas qu'à la question de la protection des données d'ailleurs, comme on le voit régulièrement avec les vCPU et l'overprovisionning.

Qui est responsable de quoi ?

En cas de sinistre se pose la question de la responsabilité. Ici, tout dépend du contrat, et là encore il vaut mieux le lire dans son ensemble, petites lignes comprises, avant qu’il ne soit trop tard. 

En ce qui concerne les sauvegardes et les mesures liées à la continuité et la reprise d’activité, on a rarement affaire à des paragraphes cachés et écrits en tout petit : ce sont des points mis en avant, bien en évidence, car ce sont d’excellents arguments marketing. Il est toutefois rare qu’un fournisseur assure 100 % de fiabilité.

Et même si c'était le cas, cela ne signifierait pas que le service fonctionnera 100 % du temps : simplement que s’il ne fonctionne pas comme prévu, vous aurez droit à un dédommagement, variable d’un produit à l’autre, et le plus souvent à hauteur du prix du service et non de l’importance du service dans votre business. 

La nuance est d’importance : si vous générez 10 000 euros de chiffre d’affaires avec une infrastructure à 100 euros par mois, et que le service est indisponible durant 3 jours au-delà de ce qui est garanti, alors vous aurez droit à 10 euros (3 jours de service). Ceux qui sont surpris des montants de dédommagement face à tout un business arrêté sont ceux qui n’ont pas lu le contrat ni compris la répartition des responsabilités.

Si l’offre concerne de l’infrastructure (serveur dédié principalement), le client a généralement la charge de son exploitation. À lui donc de s’assurer des sauvegardes, transferts, de la répartition géographique de ses machines, et du redéploiement de son infrastructure en cas de sinistre. Si l’offre concerne un produit ou un service (PaaS, SaaS, hébergement mutualisé, VPS, instance cloud), le fournisseur peut s’occuper de la redondance, de la duplication, mais ça n’est pas systématique et c’est toujours plus cher.

Les fournisseurs les plus matures vous proposent plusieurs zones géographiques avec chacune plusieurs datacenters, le tout plus ou moins bien relié. En cas de destruction de l’un d’eux, on peut toujours se rabattre sur un autre datacenter ou sur une autre zone géographique assez facilement.

Selon le contrat, ça sera au client ou au fournisseur de mettre en œuvre le plan de continuité d’activité (PCA), mais une bonne architecture prévoit un déploiement sur plusieurs sites : au minimum un site de production et un site séparé de sauvegarde, mais on peut prévoir plusieurs sites sur une même zone géographique, dupliquer les zones géographiques, etc. Plus il y a de briques similaires, remplissant le même rôle, mais suffisamment indépendantes les unes des autres, plus on peut espérer s’approcher d’une disponibilité à 100 %.

L’infogérance est une forme de sous-traitance qui peut prendre en charge cette partie, mais dans ce cas vous laissez les clés de votre infrastructure à un tiers. Vous pouvez accepter un tel risque... ou pas.