Rançongiciel et sauvegarde : pourquoi le stockage immuable fait la différence

Comment se déroule une attaque aujourd'hui

L'époque où un rançongiciel chiffrait un PC et laissait un mot est révolue. Une attaque moderne dure des jours, voire des semaines :

1. Entrer : un e-mail d'hameçonnage, un mot de passe fuité, une vulnérabilité dans un VPN ou un serveur non mis à jour.
2. Explorer : l'attaquant parcourt le réseau, cherche des droits d'administrateur et surtout : cherche les sauvegardes.
3. Neutraliser les sauvegardes : le serveur de sauvegarde est chiffré, le NAS effacé, le bucket cloud vidé avec la clé qui se trouvait sur le serveur, la durée de conservation mise à zéro.
4. Chiffrer : ce n'est qu'alors que les systèmes de production sont chiffrés, souvent la nuit ou le week-end.
5. Extorquer : payer pour la clé, et souvent aussi payer pour que les données volées ne soient pas publiées.

L'étape 3 est la raison pour laquelle des organisations qui avaient « une sauvegarde » paient quand même. La sauvegarde existait, mais partageait le sort de la production.

Les trois points faibles

Accessible. Une sauvegarde montée comme lecteur réseau, ou dont le serveur est dans le même domaine, n'est pour l'attaquant qu'un dossier de plus.

Effaçable. Un bucket cloud ou un dépôt de sauvegarde dont la clé est sur le serveur peut être vidé par ce même serveur. Et qui a les droits d'administrateur de votre outil de sauvegarde peut réduire la conservation à zéro.

Invisible. Personne ne remarque que les sauvegardes d'hier sont soudain trois fois plus grosses parce que tout est chiffré, ou que la conservation a été modifiée la semaine dernière.

Ce que fait le stockage immuable

L'object lock en mode compliance sur du stockage S3 donne à chaque version de chaque objet une date d'expiration. Jusqu'à cette date, personne ne peut effacer ou écraser la version : aucun administrateur, aucun attaquant avec des droits d'administrateur, aucun fournisseur de stockage. Une suppression n'est qu'un marqueur ; les données restent jusqu'à la fin de la période.

Cela règle le deuxième point faible, mais seulement si c'est bien configuré :

• en mode compliance, pas en mode governance (qu'un administrateur peut lever) ;
• avec le versionnage activé, sinon écraser reste une perte ;
• avec une durée de conservation plus longue que le temps qu'un attaquant passe à l'intérieur sans être remarqué, trente jours au minimum.

Les droits de votre logiciel de sauvegarde

Le premier point faible se règle par le principe de l'ajout seul. Le logiciel sur votre serveur reçoit une clé qui permet d'écrire et de lire, mais pas de supprimer. Le nettoyage des anciennes versions est fait par un système séparé, avec une autre clé, sur une machine que l'attaquant ne peut pas atteindre. S'il vole la clé de l'agent, il peut tout au plus écrire davantage.

Zekura fonctionne ainsi : l'agent ne peut rien effacer, un worker séparé fait la maintenance, et même ce worker ne peut pas passer sous la période de verrouillage.

Reconnaître une attaque dans vos sauvegardes

Le troisième point faible, l'invisibilité, est là où les sauvegardes deviennent une arme inattendue. Le chiffrement a une signature : soudain, tout change. Une sauvegarde nocturne qui contient normalement 2 % de nouvelles données en contient d'un coup 90 %. Qui mesure cela dispose d'une alarme qui se déclenche avant que l'attaquant n'envoie son message.

Zekura appelle cela la détection d'anomalies : si la part de nouvelles données bondit, une alerte critique est émise, c'est inscrit dans la chaîne de preuve, et un blocage est placé sur le nettoyage pour que les instantanés d'avant le chiffrement subsistent à coup sûr. En plus, Zekura compte chaque jour les marqueurs de suppression sur le stockage et compare avec ce que la chaîne justifie ; des marqueurs inexpliqués sont une alarme.

Ce qui vous protège contre votre propre administrateur

Non par méfiance envers lui, mais parce que l'attaquant peut prendre le contrôle de son compte. Tout ce qui affaiblit votre protection (désactiver une tâche, raccourcir une conservation, retirer un système) ne doit pas prendre effet immédiatement. Chez Zekura, un délai de 72 heures s'applique : tout le monde est averti, le changement est en attente avec un bouton d'annulation, et la demande comme l'exécution entrent dans la chaîne. Trois jours, c'est assez pour remarquer un compte détourné.

Liste de contrôle contre les rançongiciels

• Au moins une copie est-elle sous object lock en mode compliance, au moins trente jours ?
• Le logiciel sur votre serveur ne peut-il pas supprimer ? En êtes-vous sûr, ou le supposez-vous ?
• La sauvegarde est-elle chiffrée avant de partir, et la clé n'est-elle pas sur le même serveur ?
• Recevez-vous une alarme quand la quantité de nouvelles données explose ?
• Le raccourcissement d'une durée de conservation ne prend-il effet qu'après un délai ?
• Restaure-t-on réellement chaque semaine, pour savoir que la restauration fonctionne avant d'en avoir besoin ?

Pour sentir comment cela se joue : dans RestoreRush, le rançongiciel frappe au moment où vous pensez avoir fini.

Questions fréquentes

Une bande hors ligne n'est-elle pas plus sûre que l'object lock ?

Une bande dans un coffre est vraiment inaccessible, et c'est une force. Mais elle est rarement testée, lente à restaurer et exige de la discipline. L'object lock en mode compliance donne le même « personne n'y touche » avec des tests automatiques quotidiens. Les deux ensemble, c'est excellent.

Le stockage immuable protège-t-il aussi du vol de données ?

Non. C'est le rôle du chiffrement avant envoi, avec une clé que vous seul détenez. Voir le guide sur le zéro connaissance.

Et si l'attaquant est à l'intérieur depuis des semaines ?

C'est pour cela que la durée de conservation compte : vous devez pouvoir revenir à avant l'intrusion. Trente jours est le minimum ; qui peut se le permettre garde des versions hebdomadaires pendant des mois.