Protéger les données au repos : disque, base, sauvegarde

Chiffrer des données stockées paraît simple : on active une option, une icône de cadenas apparaît, l’audit est content. La question utile est ailleurs : contre qui ce chiffrement protège-t-il, et qui voit encore les données en clair ? La réponse dépend entièrement de la couche où il s’applique, du disque jusqu’au champ d’une base, et de l’endroit où vivent les clés. Ce chapitre parcourt ces couches, l’organisation des clés par enveloppe, les compromis de la recherche sur données chiffrées, puis les sauvegardes et la destruction.

→ Lire l’explication complète de la marmotte

Ce que signifie au repos

Une donnée est « au repos » quand elle est stockée plutôt qu’en transit sur un réseau ou en cours de traitement en mémoire. Le périmètre est plus large qu’il n’y paraît. Le disque d’un serveur ou d’un portable en est le cas évident. La base de données stocke ses tables, mais aussi ses journaux de transactions, ses fichiers temporaires et ses réplicas. Un objet cloud, dans un service de stockage comme S3, vit sur des disques que l’on ne voit jamais. Le backup (sauvegarde) est une copie conçue pour durer et pour voyager. L’archive est une copie conservée longtemps, souvent pour des raisons légales. Le snapshot (instantané) est une copie à un instant donné d’un volume ou d’une machine virtuelle, créée en un clic et oubliée en deux.

Chaque copie hérite des données, mais pas toujours de leur protection. Un instantané de disque chiffré peut être partagé avec un autre compte ; une sauvegarde exportée en clair vers un prestataire échappe au chiffrement de la base d’origine. Le premier travail consiste donc à dresser la liste des copies, pas celle des cadenas.

Couches de chiffrement

Le chiffrement du disque complet (FDE, Full Disk Encryption) chiffre chaque secteur : LUKS avec dm-crypt sous Linux, BitLocker sous Windows, FileVault sous macOS. Le mode standard est AES-XTS (norme IEEE 1619), un mode à ajustement où le numéro de secteur sert de paramètre, ce qui permet de chiffrer chaque secteur indépendamment sans changer sa taille. XTS n’apporte aucune authentification : une modification d’un secteur chiffré produit un clair corrompu, pas une erreur. Le FDE protège contre le vol d’une machine éteinte, d’un disque retiré ou d’un équipement mis au rebut. Dès que le système est démarré et le volume déverrouillé, il ne protège plus rien contre un processus, un administrateur ou un attaquant présent sur la machine : tous lisent en clair. Une machine en veille, dont la clé reste en mémoire, est en ce sens une machine ouverte.

Le chiffrement de fichier ou d’archive protège un objet indépendamment du disque qui le porte : un fichier chiffré avec age ou GnuPG reste protégé quand il est copié sur une clé USB ou envoyé par courriel. Le format compte : l’ancien chiffrement ZIP, dit ZipCrypto, se casse par une attaque à clair connu, alors que les archives AES de 7-Zip ou le chiffrement d’outils de sauvegarde comme restic ou BorgBackup reposent sur des constructions modernes.

Le chiffrement de base existe en deux saveurs. Le TDE (Transparent Data Encryption), proposé par Oracle ou SQL Server, chiffre les fichiers de la base sur disque : protection équivalente au FDE, centrée sur les fichiers et les sauvegardes de la base, mais transparente pour toute requête SQL, y compris celle d’un attaquant qui a volé un compte applicatif. Le chiffrement par colonne ou par champ chiffre certaines valeurs individuellement : le numéro de sécurité sociale est stocké chiffré, le reste en clair.

Le chiffrement applicatif place l’opération dans le code métier : la base, ses administrateurs et ses sauvegardes ne voient que des chiffrés. Le chiffrement côté client pousse la logique jusqu’au poste de l’utilisateur, si bien que le serveur lui-même ne voit jamais le clair. Plus la couche est haute, plus le cercle de ceux qui voient le clair se réduit, et plus la recherche, le tri et le débogage deviennent difficiles. Il n’existe pas de bonne couche universelle, seulement une couche adaptée à une menace donnée.

Le chiffrement par enveloppe (envelope encryption) organise les clés de ces couches hautes. Chaque objet ou chaque enregistrement est chiffré par une DEK (Data Encryption Key, clé de chiffrement de données) aléatoire. Cette DEK est elle-même chiffrée par une KEK (Key Encryption Key, clé de chiffrement de clés) conservée dans un KMS (Key Management System, système de gestion de clés) ou un HSM, et seule la DEK chiffrée est stockée à côté des données. La KEK ne quitte jamais le KMS, qui applique ses propres contrôles d’accès et journalise chaque déchiffrement. La rotation de la KEK n’oblige à rechiffrer que les DEK, quelques dizaines d’octets chacune, pas des téraoctets de données. Cette organisation crée aussi une séparation des privilèges : l’administrateur de la base possède les chiffrés, l’application possède le droit de demander un déchiffrement, et l’équipe sécurité gouverne la KEK. Le détail est repris dans la page sur le chiffrement par enveloppe et la distinction KEK et DEK.

Recherche et formats

Chiffrer un champ avec un mode aléatoire, comme AES-GCM avec un nonce neuf, empêche toute recherche : deux chiffrements de la même valeur diffèrent. Le chiffrement cherchable accepte une fuite contrôlée pour retrouver cette capacité. Le chiffrement déterministe produit toujours le même chiffré pour la même valeur et permet la recherche par égalité. Un index aveugle (blind index) stocke à côté du chiffré une empreinte HMAC de la valeur, calculée avec une clé distincte, et la requête porte sur cette empreinte.

Le prix est la fuite : l’égalité devient visible. Sur une colonne à faible cardinalité, comme le sexe, la situation familiale ou le département de naissance, l’analyse de fréquence suffit à retrouver les valeurs en comparant la distribution des chiffrés avec des statistiques publiques ; des travaux publiés en 2015 l’ont démontré sur des données réelles. Le chiffrement qui préserve l’ordre fuit encore davantage, puisqu’il permet de trier et donc de situer chaque valeur. Les schémas plus avancés, comme le chiffrement interrogeable de certaines bases documentaires, réduisent la fuite sans l’annuler. Toute recherche sur données chiffrées doit donc s’accompagner d’un modèle de fuite écrit : ce que voit l’administrateur de la base, ce que révèle une requête, ce qu’apprend un observateur des journaux.

Le FPE (Format-Preserving Encryption, chiffrement préservant le format) produit un chiffré de même forme que le clair : un numéro de carte de 16 chiffres devient un autre nombre de 16 chiffres. Le NIST le normalise dans la publication SP 800-38G, avec le mode FF1. Il répond à des contraintes métier : colonnes typées, applications historiques, contrôles de format qu’on ne peut pas modifier. Il repose sur le chiffrement paramétrable (tweakable encryption), où un paramètre public, l’ajustement, change la permutation sans changer la clé ; on peut ainsi chiffrer différemment le même numéro selon le client ou la colonne. Les petits domaines restent son point faible : chiffrer un champ de 2 chiffres revient à permuter 100 valeurs, ce qui se devine par simple recensement.

Sauvegarde et destruction

La clé de backup doit vivre ailleurs que les sauvegardes qu’elle protège, et survivre à la perte du système principal. Une clé stockée uniquement sur le serveur sauvegardé disparaît avec lui, précisément le jour où la sauvegarde devient utile. On la conserve dans un KMS distinct, sous forme partagée entre plusieurs détenteurs ou dans un coffre hors ligne, selon les méthodes décrites dans la page sur le partage de secret.

Le test de restauration est la seule preuve qu’une sauvegarde existe. Il porte sur la totalité de la chaîne : récupération de la clé, déchiffrement, restauration sur une machine vierge, vérification applicative. La rétention fixe combien de temps chaque copie est conservée ; elle doit être compatible avec les obligations légales du secteur, que seuls les juristes de l’organisation peuvent préciser, et avec la rotation des clés : une clé retirée doit rester disponible tant qu’une sauvegarde chiffrée avec elle est conservée.

La perte irréversible d’une clé rend toutes les données qu’elle protège illisibles, définitivement. Cette propriété, catastrophique par accident, devient un outil quand elle est volontaire : c’est l’effacement cryptographique (crypto-shredding). Avec une DEK par client, supprimer la DEK rend illisibles toutes les données de ce client, y compris dans les sauvegardes et les instantanés impossibles à modifier. La rotation combine les deux logiques : on chiffre les nouvelles données avec la nouvelle clé, on rechiffre progressivement les DEK, puis on détruit l’ancienne KEK quand plus aucune copie n’en dépend. La destruction de clés est détaillée dans la page sur l’effacement cryptographique.

Exemples et ateliers

Chiffrer un champ sensible avec enveloppe. Le schéma suivant, en Python avec la bibliothèque cryptography, montre la structure ; l’appel au KMS est représenté par une fonction.

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def chiffrer_champ(valeur: bytes, id_enreg: bytes) -> dict:
    dek = AESGCM.generate_key(bit_length=256)
    nonce = os.urandom(12)
    chiffre = AESGCM(dek).encrypt(nonce, valeur, id_enreg)  # id lié en données associées
    dek_chiffree = kms_chiffrer(dek)                          # la KEK reste dans le KMS
    return {"nonce": nonce, "chiffre": chiffre, "dek": dek_chiffree}

L’identifiant de l’enregistrement est passé en données associées : un chiffré copié d’une ligne vers une autre échouera au déchiffrement, ce qui empêche d’attribuer à un client le dossier d’un autre.

Concevoir une sauvegarde restaurable. La sauvegarde quotidienne est chiffrée avec une clé dédiée, distincte de celle de production ; une copie part hors site, une copie est immuable pendant 30 jours ; la clé est partagée entre trois détenteurs selon un seuil de 2 ; une restauration complète est testée chaque trimestre sur une machine vierge par une personne différente de celle qui a écrit la procédure.

Analyser les fuites d’un index chiffré. Une table de 50 000 clients comporte un index aveugle sur la situation familiale. Une poignée de valeurs distinctes seulement, avec des fréquences publiées par la statistique publique : les personnes mariées et les célibataires forment de loin les deux plus gros effectifs, les personnes veuves ou divorcées des minorités nettes. Les deux empreintes les plus fréquentes se départagent difficilement, mais les situations rares se reconnaissent immédiatement. Conclusion : cette colonne ne doit pas être indexée, ou alors l’index doit être tronqué de façon à créer volontairement des collisions.

Écrire un runbook de perte de clé. Il répond à quelques questions : quelles données deviennent illisibles, quelles copies de la clé existent et où, qui peut autoriser leur récupération, combien de temps la reconstruction prend, et que dire aux métiers si aucune copie n’est récupérable.

Pièges classiques

Stocker la clé dans la même base que les données chiffrées, dans une table voisine ou un fichier de configuration du même serveur, transforme le chiffrement en formalité : qui vole la base vole la clé. Confondre FDE et protection contre l’application fait croire qu’une injection SQL se heurtera au chiffrement du disque ; elle passera au travers sans même le remarquer. Ne jamais tester les sauvegardes, c’est découvrir pendant l’incident que la clé a été tournée l’an dernier et que l’ancienne n’a pas été conservée. Faire de la recherche chiffrée sans modèle de fuite, enfin, revient à publier une version légèrement floutée de la colonne en se croyant protégé.

À ne pas confondre

Chiffrement disque et chiffrement applicatif : le premier protège contre la perte du support, le second contre ceux qui accèdent au système en fonctionnement. Recherche chiffrée et confidentialité totale : chercher implique de révéler au moins des égalités. FPE et anonymisation : un numéro chiffré par FPE reste une donnée personnelle, réversible par qui détient la clé ; c’est une pseudonymisation au sens du RGPD (Règlement général sur la protection des données). Perte de clé et suppression réglementaire : l’effacement cryptographique peut satisfaire une demande d’effacement si la clé est réellement détruite partout et qu’aucune copie du clair ne subsiste ; une clé égarée sans procédure ne prouve rien à personne.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement au repos, chaque copie devient une copie lisible : l’instantané de disque oublié, la sauvegarde partie chez un prestataire, l’archive restée sur un espace de stockage mal réglé livrent leur contenu à qui les récupère, sans aucune attaque sur l’application. La suppression d’une donnée exige alors de retrouver toutes ses copies une par une, alors qu’avec des clés bien séparées la destruction de la clé suffit. Et une sauvegarde chiffrée dont la clé n’a jamais été testée ne vaut guère mieux : elle protège parfaitement les données, y compris contre leur propriétaire.

🦫 Explication de la marmotte 🍫

Des données « au repos » sont des données stockées : sur un disque, dans une base, dans un espace de stockage en ligne, dans une sauvegarde, une archive ou une photographie instantanée d’un disque. Les chiffrer consiste à les rendre illisibles sans la clé, et cela peut se faire à plusieurs niveaux.

Le chiffrement du disque entier protège contre le vol du matériel éteint. Dès que le système démarre et déverrouille le disque, tous les programmes lisent les données en clair : il ne protège donc pas contre une application piratée. Plus le chiffrement se fait près de l’application, par fichier, par base, par champ ou directement chez le client, moins il y a de programmes et de personnes qui voient les données en clair.

Le chiffrement par enveloppe organise les clés : chaque donnée est chiffrée avec sa propre clé, et ces clés sont elles-mêmes chiffrées par une clé principale rangée ailleurs. Changer la clé principale ne demande alors de rechiffrer que les petites clés.

Chercher dans des données chiffrées reste possible avec des index spéciaux, mais ces index laissent deviner certaines informations, par exemple que deux fiches contiennent la même valeur. Le chiffrement qui préserve le format garde l’allure de la donnée, comme le nombre de chiffres, sans pour autant l’anonymiser.

Enfin, les sauvegardes ont leurs propres clés et doivent être restaurées pour de vrai, régulièrement. Perdre une clé rend les données définitivement illisibles, ce qui peut aussi servir à les détruire volontairement.

Pages voisines

La citent

Protéger les données au repos : disque, base, sauvegarde

Elle cite

Protéger les données au repos : disque, base, sauvegarde

Protéger les données au repos : disque, base, sauvegarde

Ce que signifie au repos

Couches de chiffrement

Recherche et formats

Sauvegarde et destruction

Exemples et ateliers

Pièges classiques

À ne pas confondre

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines