Guide du serveur de chiffrement complet de disque LUKS

LUKS (Linux Unified Key Setup) chiffre l'intégralité d'un périphérique bloc Linux, rendant ainsi son contenu illisible sans la clé principale. Un disque volé, un châssis mis hors service, un disque de sauvegarde oublié : aucun de ces éléments n'expose vos données une fois que LUKS est correctement configuré. Cet article explique comment déployer le chiffrement complet de disque LUKS sur un serveur, y compris la configuration LVM, la gestion des clés, le déverrouillage à distance et les modes de défaillance qui empêchent les utilisateurs d'accéder à leurs propres données.

L'implémentation de référence utilisée ici est LUKS2 avec LVM à l'intérieur du conteneur chiffré, sur un serveur Linux équipé d'AES-NI dans le processeur. Cette combinaison prend en charge toutes les charges de travail modernes, offre de bonnes performances et répond aux exigences en matière de données au repos des normes HIPAA, PCI-DSS, RGPD et SOC 2.

Pourquoi LUKS2, et que vérifier en premier lieu

LUKS effectue le chiffrement au niveau de la couche de périphériques blocs à l'aide de dm-crypt, la clé principale étant stockée dans des emplacements de clés (keyslots) au sein de l'en-tête LUKS. Cette séparation est importante : vous pouvez faire tourner les phrases de passe ou ajouter de nouvelles clés sans avoir à rechiffrer le disque.

LUKS2 est actuellement la valeur par défaut. Il prend en charge jusqu’à 32 emplacements de clés, des métadonnées au format JSON, le rechiffrement en ligne et le chiffrement authentifié via le --integrity drapeau. LUKS1 prend en charge 8 emplacements de clés et convient aux systèmes plus anciens, mais les nouveaux déploiements devraient commencer avec LUKS2.

La perte de performances avec AES-NI est généralement inférieure à 5 % sur le matériel moderne. Vérifiez avant de commencer :

grep -o aes /proc/cpuinfo | head -1
cryptsetup benchmark

Si grep ne renvoie rien, votre processeur ne dispose pas d'AES-NI et le chiffrement sera limité par le processeur en cas d'E/S intensives. cryptsetup benchmark affiche le débit par algorithme de chiffrement, ce qui vous permet de choisir le plus rapide pris en charge par votre matériel. Vérifiez également que cryptsetup est installé et que le dm-crypt module du noyau est disponible. Les deux sont fournis par défaut sur Ubuntu, Debian, RHEL et Arch.

Disposition des disques

Deux partitions ne sont pas chiffrées : la partition système EFI (512 Mo FAT32) et /boot (1 à 2 Go, ext4 ou xfs). GRUB doit lire ces deux partitions avant de pouvoir demander le mot de passe. Tout le reste se trouve à l'intérieur du conteneur LUKS.

La configuration recommandée est LVM à l'intérieur de LUKS : un conteneur LUKS contenant un groupe de volumes LVM, avec des volumes logiques pour la racine, la zone d'échange et toutes les partitions de données. Cela permet de garder les métadonnées LVM chiffrées et de redimensionner ou de créer des instantanés des volumes sans toucher à la couche LUKS. LUKS sur LVM fonctionne également, mais cela expose la structure du groupe de volumes.

ext4 est le choix par défaut sûr pour le volume racine. xfs gère mieux les fichiers volumineux et les écritures parallèles, ce qui est important pour les serveurs multimédia, de messagerie et de bases de données. Pour les SSD et NVMe, ajoutez l'option discard option dans /etc/crypttab pour activer TRIM. TRIM révèle quels secteurs sont utilisés, ce qui constitue une petite fuite d'informations. Pour la plupart des charges de travail, cela vaut la peine au vu des avantages en termes de répartition de l'usure. Si votre modèle de menace inclut une analyse forensic du périphérique, désactivez-le.

Configuration de LUKS avec LVM

Identifiez le disque cible avec lsblk et effacez toutes les métadonnées existantes :

wipefs -a /dev/sdX

Vous pouvez éventuellement le réécrire avec des données aléatoires afin que les blocs chiffrés ne soient pas distinguables de l'espace vide :

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress

Initialisez le conteneur LUKS2. Utilisez --sector-size 4096 pour les disques NVMe et les SSD modernes dotés de secteurs physiques de 4 Ko :

cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/sdX
cryptsetup luksOpen /dev/sdX cryptdata

Sauvegardez immédiatement l'en-tête, avant d'y enregistrer la moindre donnée :

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header-backup.img

Créez un LVM sur le conteneur déverrouillé, puis formatez les volumes logiques :

pvcreate /dev/mapper/cryptdata
vgcreate vg_secure /dev/mapper/cryptdata
lvcreate -L 50G -n lv_root vg_secure
lvcreate -L 8G -n lv_swap vg_secure
 
mkfs.xfs /dev/vg_secure/lv_root
mkswap /dev/vg_secure/lv_swap

Ajoutez une entrée à /etc/crypttab en utilisant l'UUID, et non /dev/sdX, qui peut changer entre deux redémarrages. Récupérez-le avec blkid /dev/sdX:

cryptdata UUID=<your-uuid> none luks,discard

Puis montez via /etc/fstab:

/dev/vg_secure/lv_root  /  xfs  defaults,noatime  0 1

Régénérez l'initramfs afin que les hooks de chiffrement soient chargés au démarrage :

# Debian/Ubuntu
update-initramfs -u -k all
 
# RHEL/Fedora
dracut -f --regenerate-all

Redémarrez, entrez la phrase de passe et confirmez la configuration avec cryptsetup status cryptdata et lsblk -f. Ce dernier devrait afficher crypto_LUKS comme FSTYPE sur la partition chiffrée.

Gestion des clés et déverrouillage à distance

LUKS2 prend en charge 32 emplacements de clés. Utilisez-en au moins trois dès le départ : une phrase de passe d'administrateur, une clé de récupération stockée hors ligne (imprimée et mise sous clé, ou sur une clé USB chiffrée dans un coffre-fort), et un fichier de clés pour le déverrouillage automatisé des volumes de données secondaires. Limitez-vous aux 95 caractères ASCII imprimables, car les caractères non ASCII provoquent des problèmes de disposition du clavier à l'invite de démarrage qui sont extrêmement difficiles à déboguer. Changez la phrase de passe d'administrateur chaque fois qu'une personne ayant accès quitte l'équipe.

Affichez les emplacements actifs avec cryptsetup luksDump /dev/sdX, ajoutez une clé avec cryptsetup luksAddKey, et en révoquez une avec cryptsetup luksKillSlot. Protégez tous les fichiers de clés avec des permissions strictes :

chmod 0400 /etc/luks/keyfile.bin

Pour les serveurs sans interface graphique dans des centres de données distants, l'invite de mot de passe pose problème. Il existe trois façons de gérer cela :

Dropbear exécute un petit serveur SSH dans l'initramfs. Vous vous connectez via SSH après le démarrage et saisissez la phrase de passe manuellement. Clevis avec Tang utilise un chiffrement de disque lié au réseau : le serveur se déverrouille tant qu'il peut atteindre un serveur Tang sur le réseau de confiance. Tang ne stocke pas votre clé, il fournit une moitié d'un échange McCallum-Relyea. Utilisez plusieurs serveurs Tang avec le sss pin pour que le déverrouillage fonctionne toujours si l'un d'entre eux est hors ligne. La liaison TPM 2.0 via systemd-cryptenroll lie la clé au PCR 7 (état de démarrage sécurisé), de sorte que le serveur ne se déverrouille que si le micrologiciel et le chargeur d'amorçage n'ont pas été altérés. Conservez toujours un emplacement de clé avec mot de passe comme solution de secours lorsque vous utilisez TPM, car les mises à jour du micrologiciel modifient les valeurs PCR.

Renforcement de la sécurité et prévention des blocages

Utilisez des phrases de passe d'au moins 20 caractères. Activez le chiffrement authentifié avec --integrity dès luksFormat si votre modèle de menace inclut la falsification des données plutôt que la simple confidentialité. Cela entraîne un coût d'amplification d'écriture, donc effectuez d'abord des tests de performance.

Ne clonez pas un conteneur LUKS d'une machine à l'autre. La clé de volume est copiée en même temps, donc changer la phrase de passe sur un hôte ne protégera pas l'autre. Reformatez chaque disque individuellement.

Pour une mise hors service sécurisée, cryptsetup erase /dev/sdX efface tous les emplacements de clés en quelques millisecondes, rendant le disque irrécupérable sans destruction physique. Cela constitue à lui seul un argument de poids en faveur du chiffrement systématique par défaut.

Modes de défaillance courants :

Le mode de défaillance le plus critique est la corruption de l'en-tête. Si l'en-tête LUKS est perdue ou corrompue, les données sont perdues. Il n'y a pas de récupération possible, sauf en restaurant à partir d'une sauvegarde de l'en-tête. Stockez une copie sur un support distinct, idéalement à deux emplacements, et jamais sur le disque chiffré lui-même. Pour les volumes secondaires non critiques, ajoutez nofail à /etc/crypttab afin qu'un montage raté ne bloque pas le démarrage.

Les serveurs dédiés FDC sont livrés avec du matériel prenant en charge AES-NI et le chiffrement complet du disque dès leur sortie de l'emballage. Configurez un serveur dédié lorsque vous êtes prêt à le déployer.