« On a des backups. » C'est la phrase que tout le monde répète, et c'est exactement là que le ransomware moderne vous attend.
Parce qu'un ransomware sérieux ne se contente plus de chiffrer vos données. Avant de frapper, il cherche vos sauvegardes et les détruit, avec les mêmes droits d'administration qu'il vient de voler. Le jour où vous voulez restaurer, il n'y a plus rien à restaurer.
La vraie question n'est donc pas « est-ce que j'ai des backups ? ». C'est : qu'est-ce qui survit à un attaquant qui a déjà les clés ? Voici les quatre couches que j'ai montées pour qu'il y ait toujours une réponse, et comment je les ai testées.
Le modèle de menace : supposez que l'attaquant est déjà admin
La règle 3-2-1 (trois copies, deux supports, une hors site) est un plancher, pas un plafond. Elle protège contre la panne disque, l'incendie, l'erreur humaine. Elle ne protège pas contre un attaquant qui a pris la main sur votre domaine et qui voit vos trois copies depuis le même compte.
Mon hypothèse de départ est donc la pire : l'attaquant est déjà administrateur, il a les identifiants de sauvegarde, il est sur le réseau. Qu'est-ce qui résiste ? Chaque couche répond à un cas où la précédente a échoué.
Couche 1 : un compte de sauvegarde qui ne peut pas supprimer
Le job de sauvegarde tourne avec un compte qui peut écrire et lire les backups, mais qui n'a aucun droit de suppression ni de purge. Append-only. Concrètement, même si l'attaquant vole les identifiants du compte de sauvegarde, il ne peut pas effacer les backups par l'API : la commande lui est refusée. Le piège à éviter : le rôle « évident » de sauvegarde inclut souvent le droit de purge. Il faut le rôle minimal, pas le rôle pratique.
Couche 2 : le chiffrement à la source
Les backups sont chiffrés avant de quitter la machine, en AES-256-GCM, avec une clé qui vit sur la source (et dans un coffre), jamais sur le serveur de sauvegarde. Deux bénéfices : si le serveur de sauvegarde est compromis, l'attaquant ne récupère que des blocs illisibles ; et contre la double extorsion (« on chiffre, et on menace de publier vos données »), il n'a rien de publiable.
Couche 3 : des instantanés immuables, hors du logiciel de sauvegarde
Imaginons que l'attaquant ne vole pas juste un compte, mais compromette le serveur de sauvegarde lui-même et efface tout par l'API. Il reste une chose qu'il ne contrôle pas : un instantané (snapshot) quotidien du stockage, pris à la couche système de fichiers, en dehors du logiciel de sauvegarde. L'API de backup n'a tout simplement pas de commande pour le supprimer. Immuable, basé sur le temps, invisible depuis l'application.
Couche 4 : une copie hors-ligne
Le dernier rempart est le plus simple et le plus vieux : une copie qui n'est pas branchée. Un support amovible synchronisé une fois par semaine, puis déconnecté, avec une rétention verrouillée. Un ransomware ne chiffre pas ce qu'il ne voit pas sur le réseau, et n'efface pas ce qui n'est pas branché. C'est lent, c'est manuel, c'est increvable.
Le test : un backup jamais restauré est un espoir, pas un backup
Tout ce qui précède ne vaut rien si on ne l'a pas testé. Alors j'ai joué l'attaque. J'ai essayé d'effacer des backups avec le compte de sauvegarde : refusé. J'ai restauré une machine entière depuis un instantané immuable : OK. J'ai vérifié que la copie hors-ligne tenait sa rétention. Et une vérification automatique tourne chaque semaine pour détecter une corruption silencieuse.
Les pièges (que personne ne documente)
Comme toujours, le diable est dans les détails :
- Le rôle de sauvegarde « pratique » qui inclut la purge. On croit limiter le compte, on lui laisse de quoi tout effacer.
- Le support hors-ligne qui fait planter le serveur. Un disque USB a fait crasher le noyau à chaque branchement, jusqu'à blacklister le bon module. Une copie hors-ligne ne sert à rien si elle met le serveur à terre.
- Les notifications. Un backup qui échoue en silence est pire que pas de backup, parce qu'on se croit couvert. Chaque échec doit alerter.
- Le pare-feu trop zélé. La protection anti-brute-force du serveur de sauvegarde s'est mise à bannir le proxy interne, coupant l'accès à tout le monde. Sécuriser, oui, mais sans se verrouiller dehors.
Le bilan
Quatre couches, et une règle simple derrière chacune : elle suppose que la précédente a échoué. Le compte sans suppression tombe ? Le chiffrement protège les données. Le serveur entier tombe ? Les instantanés immuables tiennent. Tout le online tombe ? La copie hors-ligne reste.
Et tout ça tourne sur de l'open-source : un serveur de sauvegarde libre, du ZFS, des scripts versionnés, supervisé et documenté. Une petite équipe peut atteindre un niveau de résilience qu'on associe d'habitude à des solutions à six chiffres. Il ne faut pas un gros budget, il faut un bon modèle de menace.
Le ransomware ne demande pas si vous avez des backups. Il demande si vous pouvez encore les lire après son passage. Ces quatre couches sont ma réponse.