Crypto de Disque et Sauvegardes: VeraCrypt, LUKS et Strategie 3-2-1 Resiliente

Un ordinateur portable vole dans le train, un disque saisi, un ransomware qui chiffre chaque partage reseau a 03:12 : trois scenarios, une question. Quelqu un peut-il atteindre vos donnees, et pouvez-vous vous-meme les recuperer apres une perte totale ? La crypto de disque et une strategie de sauvegarde 3-2-1 resiliente sont les deux faces d une meme piece : confidentialite contre le vol, disponibilite contre la perte. Ce billet montre concretement comment chiffrer avec LUKS et VeraCrypt, comment gerer les cles pour de vrai, et comment construire des sauvegardes pour que ni un voleur ni un ransomware ni votre propre erreur ne vous ruinent.

D abord le modele de menace

Chiffrer sans modele de menace, c est du theatre crypto. Le chiffrement de disque complet protege les donnees at rest : materiel vole ou saisi eteint. Il ne protege pas le systeme en fonctionnement ou la cle est en RAM, ni contre un malware avec root, ni contre une attaque cold-boot sur un appareil deverrouille, ni contre la coercition quand on vous arrache la passphrase. Definissez donc clairement contre qui vous vous defendez, comme on le derive dans OPSEC pour Chercheurs en Securite: Modele de Menace Personnel. Le modele dicte le choix : LUKS standard suffit-il, avez-vous besoin de volumes caches, avez-vous besoin d une isolation stricte comme dans Tails, Whonix ou Qubes OS: Lequel Choisir pour Chaque Scenario d'OPSEC.

Monter LUKS sur Linux correctement

Sous Linux, LUKS2 est le standard. A la creation, ce qui compte est la derivation de cle : cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --pbkdf argon2id /dev/nvme0n1p3. Argon2id est memory-hard et ralentit massivement le brute force, contrairement au vieux PBKDF2. Verifiez avec cryptsetup luksDump qu argon2id et un cout memoire raisonnable sont vraiment actifs. LUKS offre huit keyslots : utilisez-en un pour la passphrase, un pour un keyfile dans un coffre, un comme recovery d urgence garde hors ligne. Faites tourner les slots compromis avec luksKillSlot. Pour les serveurs, combinez LUKS avec l hygiene de boot et le moindre privilege comme dans Hardening de Serveur Linux: CIS Benchmark Applique Sans Casser la Prod, sinon le disque chiffre protege un systeme en marche plein de trous.

VeraCrypt, volumes caches et deni plausible

VeraCrypt brille en multiplateforme (Windows, macOS, Linux) et avec des conteneurs plutot que des partitions entieres. Un conteneur .hc est un fichier monte comme volume chiffre, ideal pour des jeux de donnees sensibles et transportables. La fonction phare est le volume cache : dans un volume externe se trouve un second dont l existence ne peut pas etre prouvee cryptographiquement. Sous coercition, vous revelez la passphrase du volume externe, contenant des donnees leurres plausibles, tandis que le volume cache reste invisible. C est puissant mais fragile : ecrivez trop dans le volume externe et vous ecrasez le cache. VeraCrypt est aussi deliberement lent a la derivation (nombre d iterations eleve), ce qui rend le brute force couteux. Choisissez une passphrase longue et a haute entropie, car aucun nombre d iterations ne sauve un mot de passe faible.

Une gestion de cles qui tient

La cle est la vraie surface d attaque, pas l algorithme. Une passphrase de six mots Diceware aleatoires bat n importe quel mot de passe malin mais court. Separez savoir et possession : passphrase dans la tete plus un keyfile sur une YubiKey ou une cle offline. Pour le deverrouillage sans surveillance de serveurs, liez la cle a un TPM avec une politique PCR de sorte que le disque ne demarre que si la chaine de mesure du firmware est inchangee ; Clevis et systemd-cryptenroll l automatisent. Gardez une recovery key physiquement separee et hors ligne. La meme pensee resistante a la coercition, y compris des mecanismes de duress, est approfondie dans Crypto Personnelle: Hardware Wallets, Passphrase et Backup Resistant a la Coercition. Retenez : une cle perdue sans recovery signifie une perte de donnees garantie, une cle fuitee signifie une compromission garantie.

La regle 3-2-1 et son extension

La regle 3-2-1 est le coeur de toute strategie resiliente : trois copies de vos donnees, sur deux types de media differents, dont une hors site. Concretement : les donnees vives, une sauvegarde locale sur un autre disque ou un NAS, et une copie geographiquement separee dans une cible cloud ou offsite chiffree. L extension moderne est 3-2-1-1-0 : le un supplementaire designe une copie hors ligne ou immuable, le zero designe zero erreur dans les restaurations verifiees. Cette unique copie hors ligne est precisement la difference entre survivre et couler quand un ransomware chiffre chaque disque accessible. Une sauvegarde que le ransomware peut aussi chiffrer n est pas une sauvegarde, c est un deuxieme otage.

Chiffrer les sauvegardes avec restic et borg

Le logiciel de sauvegarde doit chiffrer cote client avant que les donnees quittent l appareil. restic et BorgBackup font exactement cela : deduplication plus chiffrement, de sorte que la cible (S3, un serveur tiers, un disque externe) ne voit jamais que du chiffre. Avec restic vous creez un repo avec restic init, sauvegardez avec restic backup /donnees et prunez avec une politique de retention comme --keep-daily 7 --keep-weekly 4 --keep-monthly 12. La cle du repo n est jamais televersee au fournisseur, ce qui est decisif quand la cible offsite n est pas de confiance. Borg propose la meme chose avec borg init --encryption=repokey-blake2. Les deux vous laissent traiter la cible de sauvegarde comme potentiellement hostile, le seul defaut sain pour des copies offsite.

Sauvegardes immuables et hors ligne contre le ransomware

La question decisive avec le ransomware est : l hote compromis peut-il detruire ses propres sauvegardes ? Si oui, vous n en avez aucune. Rendez au moins une copie immuable ou physiquement hors ligne. Dans le cloud vous utilisez S3 Object Lock en mode compliance ou l immuabilite de Backblaze B2, de sorte que meme des credentials voles ne peuvent pas supprimer les objets avant l expiration de la fenetre de retention. En local, faites tourner deux disques externes avec un toujours dans l armoire, physiquement deconnecte. Ajoutez des repos append-only (restic via un rest-server avec --append-only) pour qu un client compromis puisse ecrire mais pas supprimer. Detectez tot les suppressions massives inhabituelles ou les vagues de chiffrement avec une detection dans le style de Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection.

Tests de restauration, sinon pas de sauvegarde

Une sauvegarde jamais restauree est un espoir, pas une sauvegarde. Planifiez des drills de restauration reguliers : restaurez un fichier au hasard, puis un dossier entier, puis un systeme complet dans une VM et comparez les hashes. Avec restic vous verifiez l integrite du repo via restic check --read-data-subset=10% et repetez la vraie restauration avec restic restore latest --target /restore-test. Documentez le temps de restauration (RTO) et la perte de donnees maximale toleree (RPO) pour que personne ne devine lors d un vrai evenement. Le zero de 3-2-1-1-0 designe exactement cela : zero erreur dans une restauration verifiee. Sans ce test, vous decouvrez la sauvegarde cassee la nuit meme ou vous en avez besoin.

Erreurs courantes

Cinq pieges reviennent encore et encore. Un : une passphrase faible sur une crypto forte, ce qui annule tout l effort. Deux : la cle est a cote des donnees, comme un keyfile sur la meme partition non chiffree. Trois : des sauvegardes dans le meme perimetre de confiance, si bien qu un attaquant avec acces les efface aussi. Quatre : des restaurations jamais testees qui echouent lors d un vrai evenement sur un mot de passe oublie ou un repo corrompu. Cinq : remplir sans soin le volume externe VeraCrypt et ecraser le cache. Chacun de ces pieges transforme une strategie apparemment sure en illusion. La bonne nouvelle : les cinq s evitent avec de la discipline plutot qu avec une technologie couteuse.

Checklist pratique

Un : LUKS2 avec argon2id, verifie via luksDump. Deux : une passphrase d au moins six mots Diceware, separee d un keyfile que vous possedez. Trois : donnees sensibles de transport dans des conteneurs VeraCrypt, avec volume cache quand la coercition est un risque. Quatre : honorez 3-2-1, etendu a 3-2-1-1-0 avec une copie hors ligne ou immuable. Cinq : chiffrez les sauvegardes cote client avec restic ou borg, traitez la cible comme hostile. Six : Object Lock ou append-only contre le ransomware. Sept : definissez une politique de retention et prunez. Huit : un drill de restauration mensuel avec comparaison de hashes, RTO et RPO documentes. Neuf : gardez la recovery key hors ligne et physiquement separee. Vivez ces neuf points et vous survivez au vol, a la saisie et au ransomware.

FAQ

Le chiffrement de disque complet suffit-il seul ? Non. Il ne protege que les donnees at rest. Un systeme en marche et deverrouille, un malware avec root, ou un portable ouvert avec la cle en RAM ne sont pas couverts. Combinez la crypto de disque avec le hardening systeme, un auto-lock court, et des sauvegardes chiffrees et separees.

Sauvegarde cloud ou copie offsite a soi ? Les deux sont legitimes tant que vous chiffrez cote client et que la cle n atteint jamais le fournisseur. Le cloud vous donne une geo-separation facile et l immuabilite via Object Lock ; un disque externe tournant dans un autre batiment vous donne un controle total. L ideal est de combiner les deux.

Conclusion

La crypto de disque et les sauvegardes resolvent deux problemes distincts et aussi importants l un que l autre : personne ne lit vos donnees, et vous ne les perdez jamais. LUKS2 avec argon2id et VeraCrypt avec volumes caches couvrent la confidentialite ; une strategie 3-2-1-1-0 vecue honnetement, avec chiffrement cote client et au moins une copie immuable hors ligne, couvre la disponibilite. Takeaway pratique : chiffrez le premier disque aujourd hui, montez le premier repo restic avec une cible offsite aujourd hui, et faites le premier vrai test de restauration cette semaine. Une securite jamais repetee n est qu une rumeur sur votre propre resilience.