Chiffrement intégral du disque sur un VPS

Le chiffrement intégral du disque répond exactement à une question : que récupère un adversaire lorsqu'il détient votre stockage et que la machine est éteinte ? Toute autre question que vous pourriez avoir — ce que l'hébergeur peut voir, ce qui se passe si un serveur en cours d'exécution est saisi, si vos sauvegardes sont sûres — a une réponse différente, et les traiter comme une seule est la façon dont on finit avec un chiffrement qui ne protège rien.

Cette distinction mérite d'être posée sans détour, car « chiffré avec LUKS » apparaît sur chaque page d'hébergement axée confidentialité de ce secteur, la nôtre incluse. C'est un contrôle réel, il ne coûte presque rien à faire tourner, et c'est aussi le contrôle le plus survendu de l'hébergement. Ce guide couvre ce que le chiffrement au repos empêche réellement sur un serveur loué, les trois montages qui valent la peine d'être déployés et les commandes pour chacun, les deux réglages qui comptent vraiment sur un petit VPS, et la poignée d'erreurs qui transforment tout l'exercice en décoration.

Ce que le chiffrement au repos protège réellement

Le chiffrement au repos signifie que les octets sur le support de stockage sont du texte chiffré tant que le volume est fermé. C'est une affirmation étroite, et sa valeur dépend d'une seule variable : où se trouve la clé au moment où l'adversaire arrive.

Lisez cela comme une définition plutôt que comme une déception. Éliminer la classe d'exposition liée au disque retiré vaut une heure de travail précisément parce que c'est la classe contre laquelle vous n'avez aucune autre défense, et celle qui survient sans que personne ne vous vise : le matériel tombe en panne et repart, les baies sont mises au rebut, les volumes sont réattribués au locataire suivant. Le chiffrement transforme tout cela en non-événement.

Pourquoi un VPS n'est pas un ordinateur portable

Sur un ordinateur portable, la conception va de soi. Vous tapez une phrase de passe au démarrage, la clé n'existe qu'en RAM tant que la machine est éveillée, et l'éteindre met fin à l'histoire. Un serveur n'a personne devant la console. Quelque chose doit fournir la clé à chaque démarrage, et chaque candidat pour ce « quelque chose » échange de la disponibilité contre de la protection :

• Un humain la tape. Le montage le plus solide, car la clé ne repose jamais sur la machine — mais le serveur ne peut pas revenir d'un redémarrage sans vous, et il vous faut un accès avant même que le système d'exploitation existe.
• La machine la détient. Pratique, et dans la plupart des configurations bricolées maison, contre-productif : un fichier de clé sur le même disque virtuel signifie que quiconque détient le disque détient la clé.
• Une autre machine la transmet. Déverrouillage lié au réseau, généralement Clevis avec un serveur Tang. Le serveur ne se déverrouille que tant qu'il peut encore joindre un hôte que vous contrôlez, ce qui est une propriété réellement utile — et un déplacement de la confiance, pas son élimination.

Il existe une deuxième différence que la plupart des guides passent sous silence. Sur un VPS, /boot et l'initramfs sont en clair, ils résident sur un stockage que l'hébergeur contrôle en dernier ressort, et il n'existe aucune chaîne de démarrage que vous puissiez vérifier — pas de TPM qui vous appartienne, pas de démarrage mesuré, rien à attester. Un hébergeur qui voudrait votre phrase de passe pourrait altérer l'initramfs et la récupérer la prochaine fois que vous déverrouillez. Ce n'est la description d'aucune pratique de notre part ; c'est la description de ce que l'architecture permet, la seule façon honnête de raisonner sur un ordinateur que vous louez. Notre comparatif VPS contre dédié parcourt la même frontière de confiance du côté matériel, et notre réponse honnête sur l'anonymat offshore applique la même rigueur au discours marketing qui l'entoure.

Les trois montages qui valent la peine d'être déployés

Il n'existe pas une seule configuration correcte — il y a celle dont vous pouvez assumer le mode de défaillance. Ces trois montages couvrent l'essentiel des cas réels.

Commencez par le premier, sauf raison précise de ne pas le faire. Il apporte l'essentiel de la protection pour une fraction du risque opérationnel, et possède la seule propriété qui manque aux deux autres : rien en lui ne peut empêcher le serveur de revenir en ligne. Le montage trois est le seul où la phrase de passe est un fait que l'hébergeur ne peut pas atteindre plutôt qu'une promesse qu'il fait, ce qui explique pourquoi nos serveurs dédiés appliquent LUKS dès l'installation, avec une phrase de passe que nous ne voyons jamais.

Chiffrer un volume de données sur un VPS en cours d'exécution

C'est le montage à privilégier en premier. Rien n'est réinstallé, rien ne change dans le processus de démarrage, et si vous faites une erreur, le pire résultat est un fichier conteneur que vous jetez. Quinze minutes sur un serveur Debian ou Ubuntu déjà en service.

• Installez l'outillage. apt install cryptsetup. Si votre offre vous a fourni un second périphérique bloc, utilisez-le directement et sautez l'étape suivante.
• Créez un conteneur. Sur un VPS à disque unique, la solution pratique est un fichier : fallocate -l 40G /var/lib/vault.img. Il se comporte comme un disque et peut être agrandi plus tard.
• Formatez-le en LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Gardez les valeurs par défaut pour le chiffrement ; la section ci-dessous couvre le seul paramètre qui vaut la peine d'être ajusté sur un petit serveur.
• Ouvrez-le et posez un système de fichiers. cryptsetup open /var/lib/vault.img vault vous donne /dev/mapper/vault ; puis mkfs.ext4 /dev/mapper/vault et mount /dev/mapper/vault /srv/vault.
• Déplacez les données qui comptent, puis pointez les services dessus. Un bind mount, ou un rsync effectué service arrêté, est généralement plus propre que des liens symboliques — les bases de données en particulier détestent qu'on les suive à la trace.
• Sauvegardez l'en-tête LUKS. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, puis déplacez ce fichier hors du serveur. Quelques kilo-octets corrompus au début du conteneur détruisent définitivement chaque octet qui suit, et c'est la seule assurance qui existe.
• Fermez-le et vérifiez que vous pouvez rouvrir. umount /srv/vault && cryptsetup close vault, puis rouvrez-le à partir de vos notes plutôt que de votre mémoire. Faites-le avant qu'il n'y ait quoi que ce soit de précieux à l'intérieur.

Après un redémarrage, le coffre reste fermé jusqu'à ce que vous vous connectiez et l'ouvriez. Ce n'est pas une limitation à contourner — c'est tout l'intérêt de la manœuvre. Un volume qui s'ouvre tout seul est un volume dont la clé se trouve sur la machine.

Chiffrement intégral de la racine avec déverrouillage distant par SSH

Quand l'exigence est que rien de lisible ne survive à une saisie machine éteinte — journaux, historique du shell, listes de paquets, la forme même de ce que vous faites tourner — le système de fichiers racine doit lui aussi se trouver dans le conteneur. Le problème devient alors de faire parvenir une phrase de passe à une machine qui n'a pas encore démarré, et la réponse est un minuscule serveur SSH vivant dans l'initramfs.

• Installez chiffré dès le départ. Démarrez l'installateur de la distribution via l'import d'ISO personnalisé et choisissez un partitionnement guidé avec LVM chiffré. Convertir un système de fichiers racine en place, en cours d'exécution, est possible mais ne vaut pas le risque.
• Ajoutez le serveur SSH de préamorçage. apt install dropbear-initramfs, puis placez votre clé publique dans /etc/dropbear/initramfs/authorized_keys. Il s'agit d'un jeu de clés distinct de votre SSH habituel — utilisez une clé dédiée.
• Verrouillez-le. Dans /etc/dropbear/initramfs/dropbear.conf, définissez DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s" : pas de connexion par mot de passe, pas de redirection de port, un port dédié, et un délai d'inactivité pour qu'une session bloquée ne retienne pas le démarrage indéfiniment.
• Donnez un réseau à l'initramfs. Ajoutez un paramètre ip= statique à GRUB_CMDLINE_LINUX dans /etc/default/grub — la forme est ip=address::gateway:netmask::interface:off. Compter sur le DHCP à ce stade est ce qui fait qu'on se retrouve verrouillé dehors.
• Reconstruisez et redémarrez. update-initramfs -u && update-grub, puis redémarrez et connectez-vous avec ssh -p 2222 root@your-server et exécutez cryptroot-unlock. Votre client vous avertira d'une clé d'hôte inconnue : l'initramfs a la sienne propre, ce qui est normal et mérite d'être épinglé dans une entrée known_hosts séparée.
• Testez le chemin de secours avant d'en dépendre. Installez une mise à jour du noyau, redémarrez, déverrouillez de nouveau. Les mises à niveau du noyau régénèrent l'initramfs, et c'est précisément à ce moment qu'une mauvaise configuration se révèle.

Les deux réglages qui comptent, et le piège du petit VPS

LUKS2 utilise par défaut AES-XTS avec une clé de 512 bits et une dérivation de clé Argon2id. Les deux sont corrects. Ajuster le chiffrement à la main revient généralement à obtenir quelque chose de plus lent et de plus faible à la fois, et internet regorge de lignes de commande copiées qui font exactement cela. Deux points méritent néanmoins votre attention.

La performance n'est pas un problème, jusqu'à ce qu'elle le devienne

Vérifiez l'accélération matérielle avec grep -m1 -o aes /proc/cpuinfo et mesurez avec cryptsetup benchmark. Sur tout CPU doté d'AES-NI — c'est-à-dire chacun de nos nœuds — AES-XTS traite plusieurs gigaoctets par seconde et par cœur, largement au-dessus de ce que délivre un seul disque virtuel, si bien que le coût visible se limite à quelques pourcents de CPU sous forte charge d'E/S et à une légère hausse de latence. Sans AES-NI, la situation s'inverse et le chiffrement devient le goulot d'étranglement ; c'est le seul cas où un chiffrement alternatif est une décision réelle plutôt qu'un réflexe copié sans réflexion.

La mémoire d'Argon2id est ce qui mord

Argon2id est délibérément gourmand en mémoire, et cryptsetup le calibre au moment du formatage en fonction de la RAM de la machine sur laquelle vous formatez. Formatez un volume sur une station de travail de 32 Go, déplacez-le vers un VPS de 1 Go, et le déverrouillage peut échouer purement et simplement, car la mémoire que réclame la dérivation de clé n'est pas disponible — pire encore dans un initramfs, où bien moins de mémoire est accessible que dans un système en cours d'exécution. Sur les petites instances, fixez-le : cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb le plafonne à 256 Mo. Plus bas constitue une réduction réelle de la résistance à une attaque par force brute hors ligne, compensez donc avec une phrase de passe plus longue.

Un drapeau optionnel mérite une décision consciente plutôt qu'un copier-coller : --allow-discards transmet le TRIM au périphérique sous-jacent, ce qui est bon pour l'usure du SSD et les performances en régime stable, mais révèle aussi quelle proportion du volume est utilisée et à peu près où. Il est désactivé par défaut. Activez-le en sachant ce qu'il révèle.

Swap, journaux, instantanés — ce que l'on oublie

Un coffre chiffré autour duquel du contenu en clair continue de fuiter est l'échec le plus courant de tous, et il reste invisible jusqu'à ce que quelqu'un regarde.

• Le swap. Tout ce qui est en mémoire peut être paginé sur le disque, y compris ce que vous avez soigneusement placé dans le coffre. Désactivez le swap, ou donnez-lui une clé aléatoire à chaque démarrage avec une ligne /etc/crypttab telle que swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Tout ce qui écrit là où vous n'avez pas regardé. /var/log, /tmp, le répertoire de données de la base, /var/lib/docker, l'historique du shell, les journaux systemd. Chiffrer /srv/vault pendant que PostgreSQL écrit dans /var/lib/postgresql n'accomplit précisément rien. Recensez avant de chiffrer.
• Les instantanés. Un instantané au niveau bloc d'un volume chiffré est du texte chiffré, donc sans danger. Un instantané qui capture l'état de la mémoire est un objet entièrement différent et peut contenir la clé. Sachez lequel des deux prend le panneau de votre hébergeur avant de l'utiliser.
• Les sauvegardes. La destination est le mauvais endroit pour résoudre ce problème. Des outils comme restic et BorgBackup chiffrent à la source avec une clé que la cible ne voit jamais, ce qui explique pourquoi un serveur de sauvegarde peut être une machine ordinaire dans une autre juridiction plutôt qu'une machine de confiance.
• Le contenu en clair que vous avez déjà envoyé ailleurs. Le chiffrement au repos n'est pas rétroactif. Tout ce qui a déjà été copié, envoyé par e-mail ou synchronisé ailleurs se trouve en dehors de la limite que vous tracez maintenant.

Où vit la clé, c'est toute la conception

Chaque montage ci-dessus est en réalité une déclaration sur la garde de la clé. Quatre options existent et elles ne sont pas équivalentes :

• Dans votre tête, tapée à chaque démarrage. Protection maximale, friction opérationnelle maximale. La machine est réellement illisible sans vous.
• Dans un fichier sur la machine chiffrée. Protège contre une revente naïve du disque et rien d'autre. Si ce fichier repose sur un /boot en clair, il ne protège absolument rien — l'erreur la plus courante du chiffrement auto-hébergé.
• Sur une machine que vous contrôlez, récupérée par le réseau. Clevis lié à un serveur Tang : clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. Le serveur démarre sans intervention tant qu'il peut joindre son point d'ancrage, et refuse de se déverrouiller ailleurs. Excellent pour des flottes de serveurs sans écran, et cela fait de l'hôte Tang la chose qu'il faut défendre.
• Dans un TPM. Pertinent sur du matériel que vous possédez. Sur un VPS, le TPM virtuel est fourni par le même hyperviseur que vous essayez d'exclure — il résout donc la commodité, pas la confiance.

Un test tranche la plupart des conceptions : si la machine peut atteindre une invite de connexion sans vous, la clé se trouve sur la machine. Cela peut être un compromis parfaitement raisonnable — de nombreuses charges de travail veulent des redémarrages sans intervention bien plus qu'une résistance à un adversaire déterminé. Faites ce choix délibérément, et ne décrivez pas le résultat comme quelque chose qu'il n'est pas.

Ce que votre hébergeur peut voir, et où la juridiction prend le relais

Sur un VPS, un hyperviseur se trouve sous vous. Nous ne lisons pas la mémoire des invités, et nous ne conservons aucun journal de trafic, de connexion ou de DNS, ni aucune trace console — mais ce sont des politiques, et le cadre honnête est qu'un VPS vous demande de vous y fier. Sur du métal nu, il n'y a aucun hyperviseur entre vous et le silicium : un chiffrement intégral du disque configuré dès l'installation, avec une phrase de passe que nous ne recevons jamais, est une propriété physique de la machine plutôt qu'une garantie de notre part. C'est cette différence, et non le choix du chiffrement, qui constitue le vrai choix.

C'est pourquoi le chiffrement et la juridiction forment les deux moitiés d'une même réponse. Le chiffrement détermine ce que vaut une copie de votre disque ; la juridiction détermine qui peut contraindre la production de la machine, par quelle procédure et avec quelle rapidité. Nous opérons dans sept pays — Islande, Suisse, Panama, Roumanie, Moldavie, Pays-Bas et Russie — et le raisonnement pour choisir entre eux figure dans notre guide des juridictions, ou sous une forme plus courte via le sélecteur de juridiction et la page des localisations.

La partie que le chiffrement ne peut pas toucher est la divulgation sous contrainte, car elle vise votre personne plutôt que le matériel. Le Royaume-Uni, la France et l'Australie comptent parmi les pays dont la loi peut exiger d'une personne qu'elle produise une clé de déchiffrement, sous peine de sanction en cas de refus. Cette exposition suit l'endroit où vous vous trouvez, pas celui où se trouve le serveur, et aucune configuration sur la machine n'y change quoi que ce soit. S'inscrire sans documents d'identité limite d'emblée l'ampleur de la trace écrite qui existe — la raison pratique et peu glorieuse pour laquelle l'hébergement no-KYC et le chiffrement finissent dans la même conversation — mais ce n'est pas une défense face à un tribunal qui connaît déjà votre nom.

Neuf erreurs qui transforment le chiffrement en décoration

• Déverrouillage automatique depuis un fichier de clé sur le même disque. La majorité des serveurs « chiffrés », et l'équivalent de laisser la clé sur la serrure.
• Chiffrer un volume que les données sensibles n'atteignent jamais. Le coffre est vide et la base de données ne s'y trouve pas.
• Ne jamais sauvegarder l'en-tête LUKS. Un secteur endommagé au début du conteneur, et chaque octet qui suit disparaît définitivement.
• Ne jamais tester le chemin de déverrouillage. Puis une mise à niveau du noyau régénère l'initramfs, et le redémarrage suivant devient une opération de sauvetage.
• Formater sur une grande machine et déverrouiller sur une petite. Argon2id réclame une mémoire que le VPS ne peut pas fournir, et le volume ne s'ouvrira pas.
• Choisir une phrase de passe comme un mot de passe de connexion. Rien ne limite le débit d'une attaque hors ligne, hormis la fonction de dérivation de clé. C'est la longueur qui achète du temps.
• Migrer du contenu en clair vers le chiffrement en supposant que l'original a disparu. Sur du stockage virtualisé, l'écrasement n'efface pas de façon fiable.
• Envoyer la phrase de passe par le même canal que celui utilisé pour administrer la machine. L'OpSec serveur couvre le problème de corrélation que cela crée.
• Confondre le chiffrement de votre hébergeur avec le vôtre. « Toute l'infrastructure est chiffrée au repos » — la nôtre incluse — protège l'infrastructure. Seule une clé que vous détenez vous protège de l'infrastructure.

Alors, est-ce que ça vaut le coup sur un VPS ?

Oui, avec des attentes calibrées. Pour une heure de travail et un coût d'exécution négligeable, un volume de données chiffré élimine toute une classe d'exposition à laquelle vous ne pouvez pas remédier autrement, et l'élimine de façon permanente : matériel mis au rebut, stockage réattribué, machine éteinte sous la garde de quelqu'un d'autre. Faites au moins cela sur chaque serveur contenant quoi que ce soit d'important, juste après la checklist de durcissement de la première heure.

Ce que cela ne fait pas, c'est transformer un ordinateur loué en votre ordinateur. Si votre modèle de menace inclut l'hébergeur lui-même comme adversaire, aucun chiffrement ne corrige cela — la réponse est un matériel dédié où la clé est saisie via IPMI et ne passe jamais par un hyperviseur, une juridiction choisie à dessein, et la discipline de ne rien mettre sur un serveur qui n'a pas besoin d'y être. Adapter le contrôle à la menace réelle, c'est toute la différence entre la confidentialité et son apparence.