Comment configurer une partition SWAP chiffrée sur une installation Debian 12 existante

Il est judicieux de chiffrer la partition d'échange (swap) sur un système Debian 12 existant afin d'empêcher l'écriture en clair des pages mémoire, des mots de passe, des fragments de documents et autres données transitoires sur le disque. Pour une machine ne nécessitant pas d'hibernation, Debian propose une solution simple : chiffrer la partition d'échange avec dm-crypt et générer une nouvelle clé de chiffrement aléatoire à chaque démarrage.

Ce guide utilise cette architecture. Il suppose l'utilisation de Debian 12 « bookworm », d'une partition swap dédiée et de systemd comme système d'initialisation. Les commandes sont volontairement prudentes, car une erreur dans le chemin d'accès à un périphérique de stockage peut entraîner l'écrasement de la mauvaise partition. Lisez attentivement les points de décision, puis remplacez les identifiants de périphérique par les vôtres plutôt que de copier aveuglément les valeurs d'exemple.

La documentation de cryptsetup de Debian décrit en détail le swap chiffré et recommande de désactiver le swap, d'ajouter la partition à /etc/crypttabla liste des périphériques mappés /dev/urandom, de basculer /etc/fstabvers le périphérique mappé, puis de réactiver le swap. Consultez le fichier README de cryptsetup de Debian . Le manuel crypttab(5) de Debian 12 documente également les champs crypttab et les options dm-crypt simples.

Faut-il utiliser un swap chiffré à clé aléatoire ?

Utilisez-le lorsque vous souhaitez chiffrer l'espace d'échange et que vous n'avez pas besoin de mise en veille prolongée. La clé est régénérée à chaque démarrage, rendant ainsi l'ancien contenu de l'espace d'échange illisible après l'arrêt du système. C'est précisément le niveau de sécurité recherché par la plupart des installations de bureau et de serveur.

N'utilisez pas cette configuration si vous utilisez l'hibernation, la mise en veille prolongée, la veille hybride ou la mise en veille prolongée suivie d'une hibernation. La reprise nécessite le déchiffrement de la même image d'hibernation au prochain démarrage. Une nouvelle clé aléatoire rend cette opération impossible. Debian indique clairement que l'échange de clés aléatoires ne peut pas servir de périphérique de reprise. La documentation de Debian 12 relative à la reprise d'hibernation par systemd montre également que la reprise dépend d'un périphérique de reprise persistant.

Si l'hibernation est nécessaire, utilisez plutôt une solution de chiffrement persistant, comme un périphérique d'échange basé sur LUKS avec une configuration de déverrouillage et de reprise appropriée. Cette configuration est différente et n'est pas abordée dans ce guide.

Votre espace d'échange est-il déjà protégé par un chiffrement de disque ?

Vérifiez avant toute modification. Si votre volume logique d'échange se trouve déjà dans un conteneur chiffré LUKS, l'ajout d'une couche dm-crypt supplémentaire risque de n'apporter que peu d'avantages pratiques tout en augmentant la complexité.

swapon --show
lsblk -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS,PARTUUID

Examinez le périphérique affiché swapon --showet suivez ses parents dans lsblk. Une configuration non chiffrée classique peut apparaître /dev/sda3directement comme type swap. Une installation LVM chiffrée peut, quant à elle, afficher le swap sous un crypto_LUKSparent.

Cette distinction est importante car cet article traite de la conversion d'une partition d'échange dédiée non chiffrée . Si swapon --showle système signale un fichier d'échange, suivez la procédure spécifique à ce type de fichier. Si l'échange est déjà chiffré, déterminez d'abord si une seconde couche de chiffrement est réellement nécessaire.

Que devez-vous enregistrer avant de désactiver le swap ?

Notez le chemin exact de la partition, sa taille et son PARTUUID . Un PARTUUID identifie l'entrée de la table de partitions et reste utile même après que la signature d'échange à l'intérieur de la partition soit remplacée par des données chiffrées.

Par exemple:

sudo blkid /dev/sda3
ls -l /dev/disk/by-partuuid/

Vous pouvez voir un résultat contenant une valeur telle que :

PARTUUID="11111111-2222-3333-4444-555555555555"

Dans les exemples ci-dessous, le chemin stable correspondant est :

/dev/disk/by-partuuid/11111111-2222-3333-4444-555555555555

Évitez de vous fier à /dev/sda3l'énumération des disques, car elle pourrait changer. Évitez également d'utiliser l'ancien UUID du système de fichiers swap comme identifiant source à long terme : la configuration du swap chiffré recrée la signature du swap sur le périphérique chiffré mappé, de sorte que l'ancien UUID brut du swap ne constitue pas l'identité persistante correcte pour la partition sous-jacente.

1. Comment préparer le système en toute sécurité ?

Installez cryptsetup s'il n'est pas déjà présent, puis sauvegardez les deux fichiers de configuration que vous allez modifier.

sudo apt update
sudo apt install cryptsetup
sudo cp -a /etc/crypttab /etc/crypttab.before-encrypted-swap 2>/dev/null || true
sudo cp -a /etc/fstab /etc/fstab.before-encrypted-swap

Si /etc/crypttabelle n'existe pas encore, ce n'est pas un problème ; créez-la lorsque vous modifierez la configuration.

Ensuite, assurez-vous que le système dispose de suffisamment de mémoire disponible pendant la courte période où le swap est désactivé. Désactivez ensuite uniquement la partition de swap que vous convertissez. Utiliser le même périphérique est plus sûr que swapoff -asur une machine avec plusieurs zones de swap.

sudo swapoff /dev/sda3
swapon --show

Ne pas exécuter de commande mkswapsur la partition brute après cette étape. La signature de swap doit être créée sur le périphérique mappeur chiffré, et non sur la partition de stockage non chiffrée.

2. Que doit contenir le fichier /etc/crypttab ?

Créez ou modifiez /etc/crypttabet ajoutez une entrée pour le mappage de l'espace d'échange chiffré. La procédure suivante est conforme à la documentation Debian cryptsetup :

cswap /dev/disk/by-partuuid/11111111-2222-3333-4444-555555555555 /dev/urandom plain,cipher=aes-xts-plain64,size=256,swap

Remplacez l'exemple de PARTUUID par celui de votre système.

Les champs signifient :

• cswapest le nom du mappeur, créant /dev/mapper/cswap.
• Le deuxième champ correspond à la partition d'échange sous-jacente.
• /dev/urandomfournit une nouvelle clé aléatoire à chaque création du mappage.
• plainsélectionne un en-tête dm-crypt simple plutôt qu'un en-tête LUKS persistant.
• cipher=aes-xts-plain64,size=256rend explicites les paramètres plain-dm-crypt au lieu de dépendre de valeurs par défaut susceptibles de changer.
• swapindique à l'intégration cryptsetup que ce périphérique mappé est un espace d'échange et doit être initialisé en conséquence.

Le manuel crypttab de Debian indique que, contrairement à LUKS, dm-crypt ne stocke pas les métadonnées relatives au chiffrement, au hachage ou à la taille de la clé dans un en-tête. C'est pourquoi il est utile de consigner explicitement le chiffrement et la taille de la clé. Le manuel documente également discardles implications en matière de sécurité, tout en soulignant leur importance : n'ajoutez pas cette fonctionnalité simplement parce que le périphérique de stockage est un SSD, à moins d'avoir soigneusement évalué les risques.

3. Quels changements ont été apportés au fichier /etc/fstab ?

Recherchez l'ancienne ligne d'échange non chiffrée /etc/fstab. Elle peut utiliser un UUID, un chemin d'accès au périphérique ou un autre identifiant persistant. Par exemple :

UUID=OLD-SWAP-UUID none swap sw 0 0

Remplacez-le par le périphérique chiffré mappé :

/dev/mapper/cswap none swap sw 0 0

Ne laissez pas les deux entrées actives. Si la partition brute et la /dev/mapper/cswappartition d'échange sont toutes deux activées, le chiffrement de la partition devient inutile et vous risquez de perturber l'activation au démarrage.

Le manuel fstab(5) de Debian définit le format de l'entrée swap, tandis que swapon(8) explique comment les entrées marquées comme swap sont activées.

4. Comment l'activer et le vérifier avant de redémarrer ?

Après avoir enregistré les deux fichiers, démarrez le mappage chiffré, puis activez l'entrée d'échange. La documentation cryptsetup de Debian utilise :

sudo cryptdisks_start cswap
sudo swapon -a

Vérifiez maintenant les trois couches :

swapon --show
sudo cryptsetup status cswap
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS

Un résultat correct devrait indiquer que le swap est activé /dev/mapper/cswap, et non directement sur la partition d'origine. cryptsetup status cswapLe mappage devrait être signalé comme actif.

Si cryptdisks_startcette option n'est pas disponible dans votre installation, n'utilisez pas de commandes destructives. Vérifiez que le cryptsetuppaquet est bien installé et que la syntaxe de crypttab est valide. Vous pouvez également laisser le processus de démarrage normal de Debian créer le mappage après avoir terminé la configuration de reprise ci-dessous. Debian 12 utilise des générateurs systemd pour traduire la configuration crypttab et fstab en unités de démarrage.

5. Faut-il désactiver la reprise après hibernation ?

Oui, si cette partition était configurée comme périphérique de reprise du système. Une clé aléatoire ne peut pas déchiffrer une image d'hibernation écrite avec la clé précédente. Les instructions de Debian concernant le swap chiffré indiquent explicitement aux administrateurs de désactiver la reprise lors de la conversion de l'ancienne partition de swap de reprise en swap chiffré avec une clé aléatoire.

Vérifiez la configuration actuelle :

grep -R "^[[:space:]]*RESUME=" /etc/initramfs-tools/conf.d/ 2>/dev/null

S'il s'agit de la partition d'échange que vous venez de convertir, définissez la reprise sur aucun :

echo "RESUME=none" | sudo tee /etc/initramfs-tools/conf.d/resume
sudo update-initramfs -u

C'est à ce stade que update-initramfs -ucela entre en jeu. Il n'est pas nécessaire de reconstruire l'initramfs simplement parce qu'une entrée de swap post-démarrage normale a été modifiée ; en revanche, il est nécessaire de le mettre à jour lors de la suppression d'une ancienne cible de reprise d'hibernation que l'initramfs pourrait sinon tenter d'utiliser.

Test de redémarrage : qu’est-ce qui prouve que la configuration fonctionne ?

Redémarrez uniquement une fois l'activation en direct réussie et les fichiers de configuration corrects :

sudo reboot

Une fois le système redémarré, exécutez :

swapon --show
sudo cryptsetup status cswap
lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
cat /proc/swaps

Les critères clés de réussite sont simples :

• /dev/mapper/cswapest actif en tant qu'échange.
• La partition de stockage brute n'est pas directement répertoriée comme partition d'échange active.
• cryptsetup status cswapsignale un mappage dm-crypt actif en clair.
• La machine démarre sans demander de phrase de passe d'échange ; la clé aléatoire est générée automatiquement.

Vous pouvez également redémarrer deux fois et comparer le comportement du mappage. Le principe de cette conception est que la clé de chiffrement est éphémère ; le contenu de la mémoire d'échange du démarrage précédent n'est pas récupérable après la recréation du mappage.

Que se passe-t-il si la machine passe en mode d'urgence ?

Les causes les plus fréquentes sont un chemin d'accès incorrect au périphérique de sauvegarde, une faute de frappe dans la commande `/etc/swap` /etc/crypttabou une /etc/fstabligne pointant encore vers l'ancien espace d'échange brut. Démarrez en mode de récupération ou utilisez un environnement de secours, montez le système de fichiers racine en lecture-écriture et restaurez les sauvegardes si nécessaire.

Les vérifications utiles comprennent :

sudo cryptsetup status cswap
systemctl status systemd-cryptsetup@cswap.service
systemctl status dev-mapper-cswap.swap
journalctl -b -u systemd-cryptsetup@cswap.service

Les noms d'unités peuvent être échappés différemment pour les noms de mappeurs inhabituels ; utilisez donc cette méthode systemctl list-units '*cryptsetup*'si le nom de service exact n'est pas évident.

Qu’en est-il de la mise au rebut des SSD ?

N'activez pas la fonction de suppression par défaut dans le seul but d'optimiser les performances théoriques d'un SSD. La documentation de crypttab de Debian indique que le passage de requêtes de suppression via un périphérique chiffré présente des risques de sécurité. Le manuel de swapon de Debian précise également que la suppression peut améliorer les performances sur certains SSD, mais que ce n'est souvent pas le cas. Si vous en avez besoin, évaluez d'abord votre modèle de stockage et les risques associés, puis activez-la de manière réfléchie.

Un espace d'échange chiffré est-il toujours utile si le système de fichiers racine n'est pas chiffré ?

Oui, mais il faut bien comprendre les limites. Le chiffrement de la partition d'échange protège les pages mémoire écrites sur cette partition. Il ne chiffre pas les fichiers enregistrés sur un système de fichiers racine ou personnel non chiffré, l'historique du shell, les caches d'applications, les fichiers de vidage mémoire, les fichiers temporaires ni les journaux. Si l'objectif est une protection étendue contre la divulgation de données suite au vol d'un disque, le chiffrement complet du disque ou du système de fichiers offre une protection plus complète.

Liste de vérification finale

• Vérifiez que la cible est une partition d'échange dédiée non chiffrée, et non un fichier d'échange, et qu'elle n'est pas déjà protégée par un périphérique parent chiffré.
• Enregistrez un chemin de partition stable tel que /dev/disk/by-partuuid/....
• Désactivez le swap brut avant de configurer dm-crypt.
• Ajoutez une entrée random-key plain-dm-crypt à /etc/crypttab.
• Pointez /etc/fstabuniquement vers /dev/mapper/cswap.
• Activez le mappage et vérifiez-le avant de redémarrer.
• Si l'ancien swap était un périphérique de reprise, configurez RESUME=noneet exécutez update-initramfs -u.
• Après le redémarrage, vérifiez que seul le mappeur chiffré est actif en tant que swap.

Pour les systèmes Debian 12 qui n'hibernent pas, cette approche permet de réduire la taille de la configuration et d'éviter le stockage d'une clé d'échange persistante. Le choix crucial n'est pas de déterminer quelle commande de chiffrement exécuter, mais plutôt si l'échange à clé aléatoire correspond à vos exigences en matière de gestion de l'alimentation. Une fois ce point tranché, il suffit d'effectuer une migration contrôlée de la partition d'échange brute vers un mappage dm-crypt recréé de manière sécurisée à chaque démarrage.