Pourquoi supprimer un fichier ne l’efface pas

Supprimer un fichier indique généralement au système de fichiers que son espace peut être réutilisé. Cela ne détruit pas immédiatement les données, et encore moins leurs copies dans les instantanés, les sauvegardes, les caches ou les réplicas.

→ Lire l’explication complète de la marmotte

Suppression logique et persistance des blocs

Un système de fichiers associe un nom de fichier à des métadonnées, puis ces métadonnées à des blocs de stockage. La suppression retire cette association ou décrémente un compteur de liens. Les blocs sont marqués libres, donc disponibles pour une écriture future. Ils ne sont pas nécessairement écrasés.

Sur ext4, XFS, NTFS ou APFS, récupérer un fichier supprimé dépend de la vitesse à laquelle ses blocs et ses métadonnées sont réutilisés. Un outil de récupération peut lire les blocs encore présents ou reconstruire un fichier à partir de signatures de format. Un fichier supprimé sur un volume peu actif peut donc survivre longtemps. Le système n’a rien fait de mystérieux, il a juste privilégié la performance. Le disque n’est pas un broyeur industriel, malgré ce que promettent certaines interfaces avec une jolie corbeille.

L’ouverture d’un fichier déjà supprimé ajoute une nuance : sous Unix, un processus peut conserver un descripteur ouvert après unlink. L’espace ne sera libéré qu’à la fermeture du dernier descripteur. Un processus compromis, un serveur applicatif mal redémarré ou un journal de débogage ouvert peuvent donc maintenir une donnée prétendument supprimée.

Les métadonnées sont elles-mêmes sensibles. Le nom, la taille, les dates et les permissions peuvent rester dans le journal du système de fichiers, dans les index de recherche ou dans les catalogues de sauvegarde. Détruire le contenu sans traiter les métadonnées laisse parfois assez d’indices pour reconstituer un événement, une identité ou une relation métier.

La position à retenir est nette : la suppression applicative est une opération de gestion d’accès et de cycle de vie. Ce n’est pas une primitive de destruction. Une politique de rétention qui s’arrête à rm n’est pas une politique, c’est un vœu pieux avec des permissions Unix.

SSD, TRIM et copie interne des données

Sur un disque dur magnétique, un écrasement ciblé peut remplacer les secteurs adressés, sous réserve que le contrôleur ne remappe pas silencieusement un secteur défaillant. Sur un SSD (Solid-State Drive), cette hypothèse tombe. Le contrôleur applique l’équilibrage d’usure, déplace les pages, réserve de l’espace interne et gère des blocs non adressables par le système d’exploitation.

Une écriture sur un secteur logique ne garantit donc pas l’écrasement de la cellule physique qui contenait la version précédente. Des pages anciennes peuvent subsister jusqu’au nettoyage interne du contrôleur. Les secteurs réalloués, les blocs de réserve et les zones défaillantes échappent également à l’écriture applicative. Lancer plusieurs passes d’écrasement sur un SSD ne corrige pas ce modèle : cela use le support, allonge la fenêtre d’exposition et produit surtout une facture de remplacement. Le fantasme des trente-cinq passes appartient aux magazines d’une époque où les disques avaient des plateaux et où les slides commerciales avaient moins de dégradés.

La commande TRIM, ou DISCARD sous Linux, informe le support que certaines plages logiques ne sont plus nécessaires. Elle peut accélérer le nettoyage interne et réduire la récupération opportuniste. Elle ne constitue pas une preuve d’effacement : le contrôleur décide du moment et de la manière dont les cellules sont traitées. Un attaquant disposant seulement d’un accès logique ne voit pas forcément les anciennes données, mais une expertise matérielle ne relève pas du même modèle de menace.

Les commandes de sanitation du protocole NVMe (Non-Volatile Memory Express) ou ATA (Advanced Technology Attachment) sont préférables pour remettre un support physique au rebut ou le céder. Elles délèguent la destruction au contrôleur, qui connaît les zones internes. Leur efficacité dépend du micrologiciel, de l’état du support et de la commande réellement exécutée. Il faut conserver le résultat de l’opération, le numéro de série, la version du micrologiciel et le journal de supervision. Une commande lancée n’est pas une commande terminée, détail qui devient étonnamment philosophique quand le support a déjà quitté le bâtiment.

Chiffrement et effacement cryptographique

L’effacement cryptographique consiste à détruire la clé qui permet de déchiffrer les données, plutôt que de tenter d’écraser chaque emplacement où elles ont pu être copiées. C’est la stratégie à retenir pour les environnements modernes, à une condition : toutes les données visées doivent avoir été chiffrées avant leur écriture avec des clés dont la destruction est maîtrisée.

Une DEK (Data Encryption Key) chiffre les données. Une KEK (Key Encryption Key) chiffre ou protège la DEK. Détruire une DEK rend les données associées indéchiffrables, à condition qu’aucune copie de cette DEK ne subsiste dans une sauvegarde de configuration, une mémoire exportée, un instantané de machine virtuelle ou un second gestionnaire de clés. Détruire seulement une KEK ne suffit pas si la DEK a été exportée ou si une autre KEK existe.

Le chiffrement complet de volume, tel que LUKS (Linux Unified Key Setup), rend l’effacement cryptographique très rapide : supprimer tous les emplacements de clés du conteneur rend le volume inaccessible. Cela ne détruit ni les en-têtes sauvegardés, ni les clés déverrouillées en mémoire, ni les données copiées hors du volume. Un export de l’en-tête LUKS est une copie de la porte d’entrée chiffrée, pas un souvenir inoffensif à ranger dans un partage d’équipe.

Pour une application multitenant, une DEK par objet ou par locataire permet un effacement sélectif. Le prix est élevé : inventaire des clés, disponibilité du service de clés, journalisation des usages, sauvegarde des métadonnées de chiffrement et rotation contrôlée. Une clé par ligne de base de données relève davantage de l’exercice de style que de l’architecture, sauf exigence très spécifique et capacité opérationnelle correspondante.

Le compromis central est là : l’écrasement direct vise le support mais échoue sur les copies invisibles et les SSD ; l’effacement cryptographique couvre mieux les copies chiffrées mais dépend absolument de la discipline de gestion de clés. Il faut choisir l’effacement cryptographique par défaut pour les données hébergées, les volumes persistants et les sauvegardes, puis réserver la sanitation matérielle aux supports sortants ou aux supports non chiffrés historiques.

Les fondations cryptographiques sont détaillées dans les ressources de cryptographie. Pour la cartographie des données avant destruction, la section données reste le point de départ : effacer ce qui n’a jamais été inventorié est une activité divinatoire.

Instantanés, sauvegardes et réplication

L’effacement sécurisé échoue le plus souvent hors du volume principal. Les instantanés de stockage, les snapshots de machine virtuelle, les copies de sauvegarde, les journaux de transaction, les exports analytiques et les réplicas asynchrones peuvent tous contenir la version antérieure d’une donnée.

Un instantané par copie sur écriture conserve les blocs anciens tant que l’instantané existe. Écraser le fichier actif ne change donc rien à la copie historique. Une base de données ajoute ses propres mécanismes : journaux de reprise, fichiers temporaires, archives de transactions et réplicas. La suppression d’une ligne peut être répliquée, mais les journaux ayant enregistré la valeur avant suppression peuvent demeurer restaurables pendant la durée de rétention.

La règle est de distinguer deux objectifs :

retirer une donnée de la production active ;
rendre cette donnée irrécupérable depuis toutes les copies conservées.

Le premier objectif peut être immédiat. Le second est borné par la durée de vie maximale des sauvegardes, sauf si chaque jeu de sauvegarde est chiffré avec une clé distincte pouvant être détruite. Chiffrer toutes les sauvegardes avec une clé globale donne une belle apparence de centralisation et une catastrophe parfaitement centralisée le jour où cette clé doit rester disponible pour restaurer autre chose.

Une suppression doit produire un identifiant de demande, une portée, la liste des systèmes concernés, le statut des réplicas et la date théorique de purge des sauvegardes. Il ne s’agit pas de conseil juridique : c’est une exigence d’exploitation. Sans preuve de couverture, personne ne sait si l’effacement a atteint les copies ou seulement l’interface applicative.

Exemple : assainir un support NVMe avant cession

La sanitation NVMe doit être exécutée depuis un environnement où le support n’est pas monté, idéalement un système de maintenance démarré sur un autre média. L’opération est irréversible et vise le périphérique entier.

# Identifier le support cible et vérifier qu'il ne porte aucun système actif.
lsblk -o NAME,SERIAL,MODEL,SIZE,MOUNTPOINTS

# Lire les capacités de sanitation annoncées par le contrôleur NVMe.
sudo nvme id-ctrl /dev/nvme0n1 | grep -i -A3 sanicap

# Déclencher une sanitation par effacement cryptographique si cette action est supportée.
# -a 2 correspond à l'action "Crypto Erase" dans l'interface nvme-cli.
sudo nvme sanitize /dev/nvme0n1 -a 2

# Suivre l'état jusqu'à la fin et archiver la sortie avec le numéro de série.
sudo nvme sanitize-log /dev/nvme0n1

L’outil nvme-cli doit être installé, le support doit être identifié par son numéro de série et aucune couche RAID, LVM (Logical Volume Manager) ou chiffrement ne doit masquer le périphérique visé. Une erreur de cible détruit un volume entier avec une efficacité remarquable, ce qui est précisément le but, mais rarement sur le bon disque quand l’inventaire est approximatif.

Si le contrôleur ne prend pas en charge cette action, utiliser une méthode de sanitation déclarée par le fabricant ou détruire physiquement le support selon le niveau de menace. Une commande blkdiscard ne remplace pas cette procédure : elle transmet une indication de libération, pas une attestation de destruction interne.

Surface d’attaque et conditions d’exploitation

Un attaquant peut exploiter des blocs non réécrits, des snapshots oubliés, des sauvegardes accessibles, des clés récupérées en mémoire ou des copies exportées dans un environnement moins protégé. Le vol d’un support chiffré sans sa clé doit conduire à une exposition limitée ; le vol simultané du support et d’un jeton de déverrouillage rend le chiffrement décoratif.

Les clés doivent être séparées des données, journalisées à chaque usage et rotées selon une procédure qui préserve la capacité de lecture pendant la migration. La rotation ne détruit pas les anciennes clés tant que des données ou sauvegardes en dépendent. Déclarer une clé révoquée sans supprimer ses copies ne produit aucun effet physique. Le mot “révoqué” est parfois employé comme un parfum de sécurité, il ne dissout pas les secrets.

La supervision doit alerter sur les échecs de purge, les sauvegardes hors politique, les instantanés trop anciens et les volumes non chiffrés. Les tests de reprise doivent aussi vérifier le scénario inverse : restaurer une sauvegarde ne doit pas réintroduire une donnée déjà purgée sans signalement. Une procédure d’effacement qui casse toute restauration est mauvaise ; une restauration qui annule silencieusement l’effacement l’est tout autant.

🐝 Ce qui arrive si on s’en passe

Sans procédure d’effacement réellement outillée, la porte reste ouverte à qui récupère un support en fin de vie : disque loué puis rendu, machine revendue, pièce échangée sous garantie, cartouche de sauvegarde sortie du coffre. L’acheteur suivant dispose d’un accès physique illimité et sans contrainte de temps, condition idéale pour une analyse hors ligne. Il manque aussi toute traçabilité : aucune attestation liant un numéro de série à une opération de destruction, donc impossible de démontrer après coup qu’un support était vierge au moment de sa cession, ni de borner l’étendue d’une fuite. La détection disparaît dans le même mouvement, puisque la lecture d’un support cédé ne génère aucun événement côté supervision. Enfin, la reprise devient ambiguë : sans marquage des purges, une restauration réintroduit des données censées avoir disparu, sans que rien ne le signale.

🦫 Explication de la marmotte 🍫

Quand un fichier est supprimé, le système retire surtout son nom de la liste des fichiers visibles. Les zones du disque qui contiennent son contenu peuvent rester présentes jusqu’à ce qu’un autre fichier utilise la même place. Des logiciels spécialisés peuvent parfois retrouver ces zones et reconstruire le contenu.

Écrire des données par-dessus peut fonctionner sur certains anciens disques, mais pas de façon fiable sur les supports électroniques modernes. Leur contrôleur déplace les données en interne pour éviter d’user toujours les mêmes zones. Une ancienne version peut alors rester dans une partie que le système ne peut plus atteindre.

La méthode la plus fiable consiste à chiffrer les données dès le départ. Elles deviennent lisibles seulement avec une clé secrète. Pour détruire les données, il faut alors détruire toutes les copies de cette clé. Si une copie de la clé existe encore dans une sauvegarde, dans la mémoire d’un serveur ou dans un autre système, les données peuvent rester lisibles.

Il faut aussi traiter les copies : sauvegardes, journaux, copies entre serveurs et instantanés créés avant la suppression. Une donnée supprimée du système principal peut encore exister dans ces emplacements. Enfin, avant de céder un disque, une commande de destruction fournie par son fabricant ou une destruction physique peut être nécessaire. L’effacement échoue si la mauvaise cible est choisie, si une copie est oubliée ou si la clé n’est pas réellement détruite.

Pages voisines

La citent

Pourquoi supprimer un fichier ne l'efface pas

Elle cite

: les deux pages se citent l’une l’autre.