Chiffrement de partitions avec LUKS : les erreurs avant le formatage
Sur un serveur ou un ordinateur portable, LUKS protège les données lorsque le disque est éteint ou séparé de la machine. Mais une erreur de cible, une phrase de passe perdue ou un en-tête endommagé peut rendre les fichiers définitivement inaccessibles.
Avant de lancer cryptsetup, il faut donc vérifier le partitionnement, préparer une copie des données et choisir une méthode de récupération réaliste. Ces précautions évitent les erreurs de configuration les plus coûteuses en sécurité Linux.
Identifier le bon disque avant luksFormat
La commande cryptsetup luksFormat initialise un volume et écrase les informations présentes sur le périphérique choisi. Une confusion entre un disque de données et une partition système peut donc provoquer une perte immédiate, sans que LUKS puisse restaurer les anciens fichiers.
Examinez d’abord les périphériques avec lsblk -f et vérifiez leur taille, leur système de fichiers et leurs points de montage. La cible doit être démontée, sauvegardée et identifiée par son nom ou son UUID avant toute opération destructive.
Contrôles à effectuer avant le chiffrement :
- Confirmation de la cible avec lsblk et les informations de montage
- Sauvegarde testée des fichiers présents sur le volume
- Vérification que la partition n’est ni montée ni utilisée
- Choix explicite du format LUKS2 dans cryptsetup
Sur une machine de test, l’administrateur peut d’abord répéter la procédure avec un disque virtuel vierge. Ce test rend visibles les étapes de formatage, d’ouverture et de création du système de fichiers, sans risquer les données de production.
LUKS2 : éviter les erreurs de formatage et de montage
Respecter l’ordre des opérations cryptsetup
Une fois la cible vérifiée, l’ordre des opérations protège l’en-tête et garantit que le système de fichiers se trouve au bon endroit. Il faut initialiser le volume, l’ouvrir, puis créer le système de fichiers sur le périphérique de correspondance.
Après l’ouverture, le volume apparaît généralement sous /dev/mapper/nom_choisi. Formater le périphérique brut au lieu de ce mapping peut écraser des métadonnées LUKS et compromettre l’accès au volume.
Les étapes à valider dans l’ordre :
- Initialiser la partition avec le format LUKS2
- Ouvrir le volume et vérifier son mapping dans /dev/mapper
- Créer le système de fichiers sur le mapping déverrouillé
- Monter, tester, démonter, puis fermer proprement le volume
Une équipe qui prépare un volume nommé « coffre » devrait confirmer que le système de fichiers est créé sur /dev/mapper/coffre, et non sur la partition chiffrée elle-même. Cette vérification simple prévient une erreur fréquente lors des interventions rapides.
| Étape | Cible correcte | Erreur à éviter |
|---|---|---|
| Initialisation | Partition ou disque dédié | Choisir le disque système par méprise |
| Ouverture | Mapping sous /dev/mapper | Confondre mapping et périphérique brut |
| Formatage | Mapping déverrouillé | Lancer mkfs sur la partition LUKS |
| Fermeture | Volume démonté puis fermé | Retirer le disque encore utilisé |
Pour approfondir les gestes d’administration, une recherche vidéo ciblée peut compléter la documentation de la distribution utilisée.
Gestion des clés LUKS et sauvegarde de l’en-tête
Prévoir plusieurs méthodes de déverrouillage
La gestion des clés ne se limite pas au choix d’une phrase de passe. LUKS2 permet plusieurs emplacements de clés, ce qui autorise l’ajout d’une méthode de secours sans remplacer nécessairement les accès déjà configurés.
Un fichier-clé facilite parfois le déverrouillage automatisé, mais il ne doit pas rester accessible sur le même disque non chiffré. Sinon, le vol du disque peut également donner à un tiers le moyen de l’ouvrir.
Options à organiser selon les accès nécessaires :
- Phrase de passe robuste, conservée dans un gestionnaire sécurisé
- Accès de secours testé et réservé aux personnes autorisées
- Fichier-clé stocké séparément du volume qu’il ouvre
- Révocation immédiate des accès devenus inutiles
La sauvegarde de l’en-tête est tout aussi essentielle : cet en-tête contient les métadonnées nécessaires au déverrouillage. Une copie hors ligne et protégée peut aider à récupérer un volume après une corruption, mais elle ne remplace pas une sauvegarde des fichiers.
Traitez cette copie comme un secret. Toute personne possédant une sauvegarde d’en-tête et une phrase de passe valide peut potentiellement accéder aux données ; il faut donc contrôler son stockage et ses accès.
| Élément | Rôle | Précaution |
|---|---|---|
| Phrase de passe | Ouvrir un emplacement de clé | Prévoir une conservation sûre et un secours |
| Fichier-clé | Automatiser certains déverrouillages | Le stocker hors du disque non chiffré |
| En-tête LUKS | Conserver les métadonnées du volume | Garder une copie protégée hors système |
| Sauvegarde des fichiers | Restaurer les données supprimées ou perdues | Tester régulièrement la restauration |
Déverrouillage au démarrage et récupération de données
Configurer crypttab sans fragiliser le démarrage
Lorsque le volume doit être disponible après redémarrage, /etc/crypttab décrit son déverrouillage et /etc/fstab son montage. Les entrées doivent viser l’UUID du volume chiffré et le mapping déverrouillé, jamais un système de fichiers supposé présent sur le disque brut.
Avec la valeur « none », le système peut demander une phrase de passe au démarrage. Un fichier-clé ou un mécanisme matériel peut automatiser l’accès, à condition d’évaluer les conséquences d’un accès physique à la machine et de tester la procédure après modification de l’initramfs.
À vérifier lors d’un déverrouillage automatique :
- UUID exact du volume et nom de mapping cohérent
- Entrées crypttab et fstab compatibles avec la distribution
- Initramfs régénéré après les changements nécessaires
- Redémarrage de validation effectué avant mise en production
Les solutions réseau comme Clevis et Tang peuvent faciliter l’ouverture d’un serveur autorisé à joindre un service de confiance. Elles ne suppriment pas le besoin d’évaluer le réseau, les accès physiques et les procédures de secours.
Limiter les pertes lors d’un incident
La récupération de données dépend de la cause : une phrase de passe incorrecte, un mapping déjà ouvert et un en-tête corrompu ne se traitent pas de la même façon. Évitez les commandes de réparation improvisées, qui risquent d’écraser des métadonnées encore récupérables.
LUKS protège principalement les données au repos. Une fois le volume ouvert et monté, les processus autorisés sur le système peuvent lire les fichiers en clair ; le chiffrement ne remplace donc ni les mises à jour, ni le contrôle des comptes, ni les sauvegardes.
Une vérification régulière des accès, des copies d’en-tête et des restaurations transforme le chiffrement en protection exploitable. Sans ces essais, une configuration apparemment fonctionnelle peut échouer précisément au moment où les données deviennent urgentes.
Pour comparer les procédures de démarrage et les méthodes de récupération, privilégiez une démonstration consacrée à la version de votre distribution.
