Que protège réellement le chiffrement au repos

Le chiffrement au repos réduit l’impact d’une perte de support, d’une copie de sauvegarde ou d’un accès physique au stockage. Il ne protège pas une donnée dès qu’un processus autorisé la déchiffre, et il ne corrige ni une identité compromise ni une application bavarde.

→ Lire l’explication complète de la marmotte

Chiffrement au repos et modèle de menace

Le chiffrement au repos vise un adversaire qui obtient les octets stockés sans obtenir simultanément la clé de déchiffrement. Cela couvre le vol d’un disque, la récupération d’un serveur mis au rebut, une image de machine virtuelle exportée, un snapshot copié, une sauvegarde exfiltrée ou l’accès non autorisé à un volume détaché.

La distinction est brutale, mais elle évite beaucoup de slides décoratives : si l’attaquant peut exécuter du code sous l’identité du service qui lit les données, le chiffrement au repos ne bloque pas la lecture. Le processus demande la clé, déchiffre, puis remet le contenu à l’attaquant. La cryptographie a fait son travail. Le contrôle d’accès a échoué.

Le chiffrement complet de disque, ou FDE (Full Disk Encryption), protège généralement un volume entier lorsque le système est éteint ou verrouillé. Il est approprié pour les postes administrateurs, les serveurs physiques et les volumes de machines virtuelles. Il ne sépare pas les locataires, les bases de données ni les applications lorsque le système a démarré. Une fois le volume monté, le noyau fournit les blocs déchiffrés aux processus autorisés. Le disque chiffré qui est déjà monté face à un compte root compromis est un coffre dont la porte est ouverte et dont le gardien a disparu.

Le chiffrement applicatif protège plus loin dans la pile. L’application chiffre une colonne, un objet ou un document avant son écriture dans la base ou le stockage objet. Cette séparation peut empêcher un administrateur de base de données, un export logique ou une fuite de snapshot de lire les champs protégés. En contrepartie, elle complique l’indexation, les recherches, le débogage et les migrations. Chiffrer chaque valeur avec une solution miracle de marché produit souvent une base impossible à requêter, puis une exception d’accès en clair. Le buzzword survit, les données aussi, mais pas dans le bon sens.

La recommandation est de combiner les niveaux selon la menace :

utiliser le chiffrement de volume pour limiter l’exposition des supports, snapshots et équipements perdus ;
utiliser le chiffrement applicatif pour les données dont l’administrateur du stockage ne doit pas disposer ;
isoler les clés de déchiffrement du stockage chiffré ;
traiter l’accès au service déchiffreur comme une frontière de sécurité majeure.

Cette dernière frontière relève aussi de l’architecture cyber et de la gestion des identités. Une clé bien protégée ne compense pas un rôle applicatif attribué trop largement.

Clés de chiffrement, enveloppe et séparation des accès

Une architecture exploitable utilise le chiffrement par enveloppe. Chaque objet, fichier ou groupe de données reçoit une DEK (Data Encryption Key), une clé de données symétrique. La DEK chiffre les données avec AES (Advanced Encryption Standard), habituellement dans un mode authentifié tel qu’AES-GCM (Galois/Counter Mode). La DEK est ensuite chiffrée par une KEK (Key Encryption Key), une clé de chiffrement de clés, conservée dans un service distinct.

Le compromis central est là : plus la clé est distante et contrôlée, plus l’exfiltration de stockage devient coûteuse pour l’attaquant, mais plus la disponibilité du déchiffrement dépend de ce contrôle distant. Il faut accepter ce coût pour les données sensibles. Conserver la clé à côté du volume chiffré ne constitue pas une architecture de sécurité, seulement une cachette avec une étiquette.

Un KMS (Key Management Service) centralise les politiques d’usage des KEK, les journaux d’accès et la rotation. Un HSM (Hardware Security Module) conserve les clés dans un composant matériel conçu pour empêcher leur extraction. Le HSM n’empêche pas un appel de déchiffrement autorisé : il protège la matière de la clé, pas la décision métier. Pour ce sujet, la page sur le module cryptographique matériel et PKCS#11 complète les contraintes d’intégration.

La rotation doit distinguer deux opérations :

faire tourner la KEK, puis rechiffrer les DEK emballées ;
faire tourner les DEK, puis rechiffrer les données elles-mêmes.

La première opération est rapide si les DEK sont stockées avec leurs métadonnées de chiffrement. La seconde est coûteuse, car chaque donnée doit être relue et réécrite. Confondre les deux conduit à promettre une rotation de données alors qu’on a seulement changé l’enveloppe. C’est un peu comme repeindre l’étiquette d’un coffre en espérant modifier son contenu.

AES-GCM fournit confidentialité et intégrité des données chiffrées, à condition qu’un nonce, ou valeur unique par chiffrement, ne soit jamais réutilisé avec la même DEK. La réutilisation d’un nonce sous AES-GCM peut révéler des relations entre messages et fragiliser l’authentification. Si l’application génère ces valeurs, elle doit disposer soit d’un générateur aléatoire robuste, soit d’un compteur persistant et partagé entre les nœuds. Un compteur local dans un déploiement actif-actif finit toujours par rencontrer son jumeau. La physique des clusters reste hostile aux vœux pieux.

Les métadonnées doivent être authentifiées avec la donnée : identifiant d’objet, version de schéma, locataire, algorithme et identifiant de clé. Sans cela, un attaquant capable de modifier le stockage peut tenter de substituer un chiffré à un autre. Le mécanisme d’authentification doit alors refuser le déchiffrement au lieu de retourner une donnée plausible et empoisonnée.

Chiffrement de volume LUKS : exemple reproductible

Sur Linux, LUKS (Linux Unified Key Setup) fournit un chiffrement de volume reposant généralement sur le sous-système dm-crypt. Il convient aux disques de données et aux supports amovibles. Il ne fournit pas de séparation entre applications exécutées sur le même hôte.

Prérequis : cryptsetup version 2.x, un périphérique bloc dédié, une console permettant la saisie d’un secret, et une sauvegarde vérifiée des données existantes. La commande suivante détruit le contenu du périphérique ciblé. Ce n’est pas une métaphore.

# Initialiser un volume LUKS2 avec AES-XTS et une phrase de passe demandée au terminal.
# Remplacer /dev/sdb uniquement après vérification du périphérique cible.
sudo cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 /dev/sdb

# Ouvrir le volume chiffré sous le nom donnees_chiffrees.
sudo cryptsetup open /dev/sdb donnees_chiffrees

# Créer un système de fichiers, puis le monter.
sudo mkfs.ext4 /dev/mapper/donnees_chiffrees
sudo mount /dev/mapper/donnees_chiffrees /mnt/donnees

L’en-tête LUKS contient les paramètres nécessaires à l’ouverture du volume et les emplacements de clés chiffrées. Sa sauvegarde est indispensable, mais elle doit être protégée comme une donnée sensible : perdre l’en-tête peut rendre le volume irrécupérable, le divulguer facilite les attaques hors ligne contre une phrase de passe faible.

Une phrase de passe humaine doit être réservée aux cas où une présence humaine est réellement attendue au démarrage. Pour un service automatisé, utiliser une clé aléatoire stockée dans un mécanisme de scellement matériel ou récupérée auprès d’un gestionnaire de clés après authentification de la machine. Placer cette clé dans /etc, dans une image de conteneur ou dans une variable de pipeline transforme le chiffrement en exercice de décoration industrielle.

Limites du chiffrement au repos et contre-mesures

Le chiffrement au repos ne protège pas les données en mémoire. Un dump mémoire, un débogueur attaché, un compte administrateur sur l’hôte ou une bibliothèque compromise peuvent obtenir les données après déchiffrement. Réduire ce risque impose l’isolation des charges, le durcissement de l’hôte, des privilèges minimaux et la surveillance des accès aux processus sensibles.

Il ne protège pas les données en transit. Les flux entre applications, bases, services de clés et sauvegardes nécessitent un chiffrement réseau avec authentification mutuelle. Le stockage chiffré ne rend pas acceptable une réplication en clair. Les couches se complètent, elles ne se remplacent pas, malgré ce que suggère parfois une architecture dessinée à coups de cadenas bleus.

Il ne protège pas contre un utilisateur légitime qui exporte ce qu’il est autorisé à lire. Pour cela, il faut des droits fins, des limites d’export, une journalisation exploitable et parfois des contrôles métier. Le chiffrement ne décide pas si un export CSV est abusif. Il chiffre très consciencieusement le CSV avant de le remettre à la personne autorisée.

Il ne garantit pas la disponibilité. Une KEK supprimée, un HSM indisponible ou une politique KMS modifiée trop largement peut rendre les données définitivement inaccessibles. La reprise doit donc tester, séparément :

la restauration des données chiffrées ;
la restauration des métadonnées et des DEK emballées ;
l’accès aux KEK historiques ;
les autorisations nécessaires au déchiffrement ;
le délai de remise en service accepté.

Une sauvegarde sans les clés, ou avec des clés restaurées sans leurs politiques d’accès, est un objet archéologique. Très bien conservé, totalement inutilisable.

La supervision doit journaliser chaque refus et chaque usage de clé : identité appelante, opération, identifiant de clé, ressource concernée et résultat. Les journaux ne doivent pas contenir de données en clair ni de DEK. Les alertes utiles portent sur les déchiffrements inhabituels, les accès à des clés anciennes, les pics de refus et les modifications de politiques.

Les principes de cryptographie restent applicables : ne pas inventer de format, ne pas dériver une clé avec une fonction maison, ne pas recycler un nonce et ne pas réutiliser une clé de données pour plusieurs finalités. Le chiffrement au repos est une propriété d’architecture, pas une case cochée par un algorithme.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement au repos, un support sorti du parc reste lisible tel quel : un disque renvoyé en garantie, une baie revendue ou un snapshot partagé par erreur livre son contenu à qui le monte, sans authentification ni trace côté service d’origine. L’effacement cryptographique devient impossible : supprimer une clé ne suffit plus à rendre illisible une sauvegarde soumise à une rétention longue, il faut retrouver et écraser chaque copie. La journalisation des usages de clés disparaît avec elle, et avec elle le signal de détection associé (déchiffrements inhabituels, accès à des clés anciennes, pics de refus). Enfin, la frontière décrite entre stockage et service déchiffreur s’efface : l’administrateur du stockage, l’export logique et la copie de volume accèdent aux mêmes octets que l’application, sans qu’aucune décision d’autorisation ne soit sollicitée.

🦫 Explication de la marmotte 🍫

Le chiffrement au repos transforme des données stockées en contenu illisible sans une clé secrète. Cette clé permet de retrouver le texte ou le fichier original. Le système chiffre les données avant de les écrire sur un disque, dans une sauvegarde ou dans un espace de stockage distant. Quand une application autorisée doit les lire, elle demande la clé, déchiffre les données et les utilise.

Il existe souvent deux niveaux de clés. Une première clé chiffre directement les données. Une seconde clé protège la première. Cette séparation permet de changer la seconde clé sans réécrire toutes les données. Les clés doivent être conservées dans un système différent du stockage, avec des règles qui déterminent quelles machines et quels services peuvent les utiliser.

Cette protection fonctionne si quelqu’un vole un disque, copie une sauvegarde ou récupère un fichier de stockage sans obtenir les clés. Elle échoue si l’attaquant prend le contrôle d’une application déjà autorisée à lire les données, car cette application peut demander le déchiffrement. Elle ne protège pas non plus une donnée affichée à une personne qui possède déjà l’autorisation de la consulter.

Une panne du système qui conserve les clés peut empêcher toute lecture. Une sauvegarde doit donc contenir les données chiffrées, les informations permettant de savoir comment les déchiffrer, et un moyen contrôlé de retrouver les anciennes clés. Sans ces trois éléments, la restauration échoue.

Pages voisines

La citent

Que protège réellement le chiffrement au repos

Elle cite

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

Que protège réellement le chiffrement au repos

Que protège réellement le chiffrement au repos

Chiffrement au repos et modèle de menace

Clés de chiffrement, enveloppe et séparation des accès

Chiffrement de volume LUKS : exemple reproductible

Limites du chiffrement au repos et contre-mesures

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines