Chiffrer un disque VPS avec LUKS : le guide honnête

1. Le modèle de menace, avant tout

Tout chiffrement répond à une question : contre qui, et dans quel état ? LUKS protège les données au repos — c'est-à-dire quand la machine est éteinte ou que le volume est fermé. Concrètement, sur un VPS, il protège contre :

• la lecture du disque hors ligne (image de stockage récupérée alors que le volume est fermé) ;
• la saisie physique du serveur éteint ou du seul volume de données ;
• la réutilisation du disque : effacer un volume LUKS, c'est détruire la clé maîtresse, rendant les octets illisibles — un « secure erase » logiciel réel.

Et il ne protège pas contre ce que beaucoup croient qu'il protège :

• l'hyperviseur. Quand votre VPS tourne, sa mémoire vive contient les données en clair, et l'hyperviseur peut y lire ou y écrire. C'est vrai chez nous comme chez AWS, et ce n'est pas une opinion : c'est l'architecture de la virtualisation.
• les snapshots mémoire, les migrations à chaud, les images du disque prises à chaud pendant que le volume est ouvert : à ce moment-là, le chiffrement n'existe plus.
• tout ce qui touche à l'hébergeur lui-même, tant que la machine tourne. Confiance en l'hébergeur = problème distinct, que le chiffrement de disque ne résout pas.

La règle à graver : LUKS sur un VPS protège le disque éteint, jamais la machine allumée. Si votre modèle d'adversaire est « quelqu'un saisit le serveur arrêté » ou « le stockage finit dans une mauvaise main », LUKS est excellent. Si votre adversaire est « l'hébergeur lit mes données », la réponse n'est pas LUKS : c'est le chiffrement applicatif côté client (vos fichiers chiffrés avant d'arriver sur le serveur) ou le choix d'un hébergeur en qui vous avez confiance structurelle — juridiction, historique, absence de KYC qui réduit ce qui peut fuiter.

2. Les deux stratégies possibles

Stratégie A — volume de données chiffré (recommandée)

Le système reste en clair (il ne contient rien de sensible : la configuration, les binaires), seul un volume dédié — partition, volume secondaire ou LVM — est chiffré. Avantages concrets : le serveur démarre seul jusqu'au réseau et à SSH, vous montez le coffre à la main quand vous en avez besoin, et une erreur de passphrase ne bloque jamais le démarrage. C'est ce que nous détaillons ci-dessous.

Stratégie B — chiffrement intégral dès l'installation

L'installateur Debian propose « Utiliser un disque entier avec chiffrement LVM » (LUKS1 par défaut, LUKS2 selon les versions). Tout est chiffré, y compris la racine ; chaque démarrage exige la passphrase via la console, faute de quoi le serveur reste bloqué au démarrage — y compris après un reboot non planifié à 4 h du matin, y compris si vous perdez l'accès à la console. Réservez-la aux menaces où le système lui-même est sensible, et assumez la dépendance totale à la console web. C'est d'ailleurs pour cela que nos images KVM embarquent l'accès console : sans lui, la stratégie B serait un pari suicidaire.

Le faux confort du fichier de clé

/etc/crypttab accepte un keyfile à la place d'une passphrase : le volume se déverrouille tout seul au démarrage. Mais un keyfile stocké sur le disque système en clair annule précisément la protection recherchée — quiconque lit l'image du disque système lit le keyfile, puis le volume. Vous avez remplacé un vrai chiffrement par de l'obfuscation. Deux usages légitimes du keyfile existent malgré tout : le stocker sur un autre serveur (monté par réseau au démarrage) — complexe —, ou le garder sur une partition séparée. À défaut, la passphrase saisie à la main reste la seule option honnête.

3. Prérequis

• KVM VPSPLEX sous Debian 12 ou Ubuntu 24.04, accès root
• Un volume dédié (second disque, partition ou LV) — ne chiffrez pas la racine en place
• Accès à la console web du tableau de bord — pour la saisie de passphrase si vous configurez le déverrouillage au démarrage
• Une sauvegarde à jour avant de toucher aux partitions — nos excuses pour l'évidence, mais celle-là coûte des serveurs

Toute opération sur cryptsetup détruit le contenu du volume ciblé. Vérifiez trois fois le périphérique avant chaque commande luksFormat : une fois lancée, aucune passphrase ne ramène les anciennes données.

4. Créer et ouvrir le volume chiffré

apt install -y cryptsetup
lsblk -f
# Identifiez le bon périphérique : /dev/sdb, /dev/vdb ou /dev/sda3 selon votre plan

# Formatage LUKS2 (AES-256 en XTS = valeurs par défaut, affichées ici pour la pédagogie)
# TOUT LE CONTENU DU VOLUME SERA DÉTRUIT
cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha256 --iter-time 2000 /dev/sdb

# La commande vous demande : "YES" en majuscules, puis la passphrase (longue ! pas stockée sur le serveur !)
# Ouverture : le volume devient accessible sous /dev/mapper/coffre
cryptsetup open /dev/sdb coffre

mkfs.ext4 -L coffre /dev/mapper/coffre
mkdir -p /srv/coffre
mount /dev/mapper/coffre /srv/coffre
df -h /srv/coffre

La passphrase : 20 caractères minimum, générée par votre gestionnaire de mots de passe, jamais stockée sur ce serveur — ni dans un fichier, ni dans l'historique shell, ni dans vos notes. C'est le seul secret qui sépare vos données d'une image de disque égarée. --iter-time 2000 (2 s de dérivation PBKDF2) rend la recherche exhaustive hors de prix, même pour un attaquant qui posséderait l'image du volume.

Vérifiez la création avec cryptsetup luksDump /dev/sdb : vous devez voir Version: 2, le chiffrement aes-xts-plain64, la clé à 512 bits et vos slots de passphrase.

5. Persistance : crypttab, fstab et le vrai coût du reboot

Deux fichiers rendent le volume permanent. Dans /etc/crypttab, le mot-clé none à la troisième colonne signifie « demander la passphrase » ; dans /etc/fstab, le montage suit automatiquement le déverrouillage :

# <nom>  <périphérique>  <keyfile>  <options>
# none = passphrase demandée au boot ; discard = TRIM pass-through sur NVMe
coffre  UUID=3f5c8a12-9b7e-4c21-a5d8-72e1c94f6b03  none  luks,discard

# Le point de montage final
/dev/mapper/coffre  /srv/coffre  ext4  defaults,noatime  0 2

# Récupérez l'UUID LUKS (PAS celui du système de fichiers)
cryptsetup luksUUID /dev/sdb
# Insérez-le dans /etc/crypttab, puis testez :
umount /srv/coffre
cryptsetup close coffre
cryptsetup open /dev/sdb coffre && mount /srv/coffre
# Si ça remonte, le couple crypttab/fstab est correct

Le vrai coût, assumé : avec cette configuration, chaque redémarrage s'arrête sur la console avec coffre: (press TAB for hints) et attend votre passphrase. Une mise à jour de noyau appliquée la nuit laisse le serveur en attente jusqu'à votre intervention — systemd finit par basculer en mode de secours (emergency). Si vous ne pouvez pas vous le permettre, vous avez trois options honnêtes : monter le volume à la demande par SSH après le démarrage (option noauto dans fstab — notre recommandation par défaut), accepter le keyfile sur le système (et son obfuscation), ou chiffrer côté applicatif plutôt que côté bloc.

6. Gérer les clés LUKS sans se piéger

LUKS2 offre 32 emplacements de clé (keyslots) : plusieurs passphrases peuvent déverrouiller le même volume. Le cas d'usage : une passphrase « d'exploitation » pour vous, une seconde conservée ailleurs (gestionnaire de mots de passe, coffre physique) en cas d'oubli — oubliez les deux, et le volume est définitivement illisible, y compris pour nous.

# Ajouter une seconde passphrase (on vous demande une passphrase existante, puis la nouvelle)
cryptsetup luksAddKey /dev/sdb

# Inventaire des slots occupés et des chiffrements
cryptsetup luksDump /dev/sdb

# Révoquer une passphrase (supprime un keyslot — vérifiez d'abord qu'il en reste un autre !)
cryptsetup luksRemoveKey /dev/sdb

# Sauvegarde de l'en-tête LUKS (si l'en-tête est corrompu, tout est perdu)
cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /root/coffre-header.img
chmod 600 /root/coffre-header.img
# Sortez ce fichier du serveur : il ne doit PAS rester à côté du volume chiffré

Nuance importante sur la sauvegarde d'en-tête : elle contient la clé maîtresse chiffrée par vos passphrases. Seule, elle ne révèle rien ; entre de mauvaises mains, elle permet de casser vos passphrases hors ligne. Conclusion identique pour les deux : sortez-la du serveur, chiffrez-la, et retenez que la restauration (luksHeaderRestore) ne sauvera jamais un volume dont la passphrase est perdue.

7. Ce que le chiffrement ne règle pas — et les alternatives

Trois fuites classiques annulent discrètement vos efforts :

• Le swap en clair. Le noyau peut y écrire des pages mémoire contenant vos données — ou des fragments de clés. Soit vous chiffrez le swap (un volume LUKS dédié, priorité haute dans fstab), soit vous le supprimez, soit vous acceptez la fuite explicitement.
• Les core dumps et /tmp. Un service qui plante peut écrire vos données en clair dans /var/crash. Sur un serveur de données sensibles : ulimit -c 0, /tmp en tmpfs, et réflexion sur ce qui journalise quoi.
• Les sauvegardes. Un backup d'un volume ouvert, copié tel quel, est un backup en clair — exactement le piège que restic évite en chiffrant côté client avant l'envoi (voir notre guide sauvegardes).

Et quand le chiffrement de bloc est le mauvais outil, voici les bonnes alternatives :

Exemple avec gocryptfs — chiffrement par fichier, montage à la demande, parfait pour un dossier « sensible » au milieu d'un système classique :

apt install -y gocryptfs
mkdir -p /srv/coffre-gocrypt /mnt/clair
gocryptfs -init /srv/coffre-gocrypt
# Notez bien la phrase de récupération affichée — c'est la seule

# Montage à la demande ; démontage = données à nouveau illisibles
gocryptfs /srv/coffre-gocrypt /mnt/clair
# ... travail dans /mnt/clair ...
fusermount -u /mnt/clair

8. Notre recommandation pratique

Sur VPSPLEX, le schéma qui tient la route pour la plupart des usages : système en clair, volume de données en LUKS2, monté à la demande via SSH (option noauto), avec la sauvegarde restic chiffrée que vous devriez déjà avoir. Vous gardez : un serveur qui boote seul, des données illisibles quand le volume est fermé, un reboot planifié qui ne dépend pas de votre présence à la console.

Réservez le chiffrement intégral au démarrage par console aux serveurs « chambre forte » — machines éteintes par défaut, allumées pour une opération, éteintes ensuite ; c'est un profil rare, et c'est précisément celui où la contrainte de la passphrase devient une propriété plutôt qu'un défaut. Pour tout le reste, rappelez-vous la hiérarchie de la confiance : la juridiction du serveur et l'absence de KYC protègent votre identité ; LUKS protège le disque éteint ; seul le chiffrement que vous appliquez vous-même, avant l'envoi, protège vos données de l'hébergeur.

Questions fréquentes