Sauvegarde Offline, protection imparfaite

La sauvegarde est un domaine un peu à part dans une infrastructure : d’une part, elle est de plus en plus complexe et, d’autre part, c’est un des rares domaines techniques dont l’obsolescence est beaucoup plus courte que les durées classiques d’amortissement des équipements. Sur le premier point – la complexité –, les infrastructures sont passées en moins de 15 ans de la sauvegarde unitaire par serveur à la sauvegarde centralisée, puis à la sauvegarde sur disque, suivie de la sauvegarde dédupliquée, voire dans certains cas de la sauvegarde en continu (CDP ou Continuous Data Protection). Inutile de dire qu’un domaine que l’on croit simple nécessite en fait une veille technologique permanente.

Sur le second point – la rapidité d’obsolescence –, il faut savoir qu’un système de sauvegarde doit constamment lutter contre trois limites : la fenêtre de sauvegarde (on ne peut pas sauvegarder les données de la journée en plus de 24 heures), le volume des sauvegardes (sauvegarder tous les jours et conserver un an d’historique implique que vos sauvegardes coûtent 365 fois plus cher que vos données) et le temps de restauration (il n’est pas envisageable de mettre trois semaines à restaurer des Files Systems après une attaque). Chaque fois que l’on atteint une de ces trois limites, il faut changer le système pour lever cette limite… jusqu’à la prochaine limite atteinte.

À une époque pas si lointaine, les datacenters des hôpitaux comptaient au plus quelques dizaines de serveurs, avec un chef de salle qui changeait tous les jours la cartouche de sauvegarde de chaque serveur, la mettait au coffre et allait chercher la cassette du lendemain qu’il enfichait dans le lecteur. Le tout serveur par serveur (pour les plus jeunes des lecteurs, c’était aussi l’époque des téléphones à cadran qui faisaient clac-clac-clac-clac, du 3615 Ulla et des Tamagotchi). Et le résultat était à la hauteur, avec un petit détail tout de même : une bande se détériore facilement, si bien qu’il devenait vite impossible de relire celle de la veille, raison pour laquelle il a fallu doubler les bandes. Avec la multiplication des serveurs, la manipulation des bandes a fini par coûter une blinde, et la sauvegarde sur disque est devenue la norme. Bref, si la bande a été abandonnée, c’est pour une bonne raison (certes, les systèmes de sauvegarde sur bande sont très performants, mais ils ont aussi pas mal d’inconvénients tels que le blocage des bras articulés dans les robots – j’ai donné).

Avec la sauvegarde sur disque (et d’ailleurs même si l’on en était resté à la bande), mettre des sauvegardes Offline implique de faire la distinction entre la sauvegarde primaire et la sauvegarde secondaire (copie de la primaire) avec une méthode qui consisterait grosso modo à effectuer la primaire, puis la secondaire, puis déconnecter physiquement la secondaire du LAN. Sauf que, dans un gros établissement avec des centaines et des centaines de serveurs, cela ne fonctionne pas : les sauvegardes tournent en continu, la primaire n’est même pas terminée que le système entame déjà la secondaire. De plus, même si l’on arrivait à séquencer le tout proprement, il faudrait qu’un gugusse aille physiquement déconnecter la prise RJ45 de la secondaire, avec un résultat prévisible : les exploitants vont finir par scripter tout cela, un attaquant potentiel en mode APT va finir par tomber dessus et le désactiver. Bref, l’efficacité du dispositif reste à démontrer.

La première architecture qui répond au besoin de protéger les sauvegardes consiste à positionner le serveur de sauvegarde derrière un firewall avec un filtrage directionnel des IP en laissant le serveur contacter le reste de l’infrastructure pour lancer des sauvegardes et les mettre à l’abri sur son VLAN protégé – mais le contact dudit serveur depuis le LAN serveur est bloqué. Ainsi, un attaquant qui parvient sur le LAN serveur est bloqué par le firewall et ne peut pas atteindre le VLAN de sauvegarde. Sur le papier seulement, car dans les faits les exploitants vont avoir besoin de faire des restaurations régulières, ce qui implique de disposer de PC qui ont accès à ce VLAN de sauvegarde : les prérequis Anssi préconisent un VLAN d’administration isolé du reste du LAN, ce qui signifie donc qu’ils sont en lien à la fois avec le VLAN de sauvegarde et le VLAN serveur, qui constituent par conséquent un point d’attaque potentiel, qu’il faut sécuriser, et c’est sans fin.

L’autre architecture consiste à utiliser des systèmes de sauvegarde en mode CDP journalisé : un fichier est sauvegardé mais, à chaque modification, on ne resauvegarde que le delta, et les blocs initiaux ne sont jamais effacés – on peut d’ailleurs dédoubler simultanément les espaces de stockage avec une désynchronisation des réplications, ce qui complexifie le système, mais il devient quasi inattaquable. Même si un attaquant chiffre les données, seuls de nouveaux blocs en mode delta seront générés puisque les précédents ne sont physiquement pas modifiables. Il suffira de rejouer les logs jusqu’à J-1 pour restaurer entièrement les données.

Les deux architectures décrites ont un point commun : la revue périodique des comptes d’accès au serveur de sauvegarde qui, tout comme d’autres serveurs ultracritiques de l’infrastructure (hyperviseur, SCCM, AV, AD, DNS, DHCP, etc.), doivent être totalement blindés ; trouver un compte admin local avec un mot de passe faible est juste impensable.