Chiffrement intégral d'un VPS : LUKS et déverrouillage à distance

Ce que votre hébergeur peut réellement voir

Commencez par la physique plutôt que par la politique : une politique peut changer, la physique non. Sur une machine virtuelle, l'image disque vit sur du matériel que quelqu'un d'autre a installé en baie. Si cette image n'est pas chiffrée, elle est lisible par quiconque finit par détenir le support de stockage : un opérateur ayant accès à l'hyperviseur, un technicien qui remplace un NVMe défaillant dans une paire RAID-1, quiconque reçoit ce disque une fois qu'il est mis au rebut, et — dans le cas que tout le monde a vraiment en tête — quiconque se présente muni d'une ordonnance contraignante d'un tribunal ayant compétence sur la machine. Rien de tout cela ne demande de malveillance ni de porte dérobée. Un volume non chiffré n'est jamais qu'un fichier, et les fichiers se copient.

La deuxième couche, c'est la mémoire. Nos plans VPS reposent sur une virtualisation complète KVM : vous faites tourner votre propre noyau plutôt que d'en partager un — mais l'hyperviseur reste propriétaire de la RAM qu'il vous alloue, et n'importe quel hyperviseur peut techniquement inspecter la mémoire d'un invité. La troisième couche, c'est tout ce qui ne touche jamais le disque : le trafic qui quitte votre interface réseau, les métadonnées émises par votre application, le DNS que vous résolvez. Côté compte, nous conservons très peu de choses par construction — un hash argon2id du mot de passe, votre solde et son grand livre, les spécifications de commande, et des journaux d'accès rotés après 14 jours, sans aucun nom, adresse, numéro de téléphone ou carte nulle part dedans, comme le détaille la page de politique no-KYC. Ne rien détenir sur vous est une garantie différente de l'incapacité à lire votre disque, et une seule des deux est quelque chose que vous pouvez faire respecter vous-même.

Ce que corrige le chiffrement intégral du disque, et ce qu'il ne corrige pas

Le chiffrement intégral du disque est un contrôle pour les données au repos. Il couvre exactement les scénarios évoqués ci-dessus, où un volume change de mains pendant que la machine est éteinte ou que la copie est faite hors ligne : un disque mis au rebut ou renvoyé en RMA, un disque dont on a tiré une image, un volume cloné depuis la couche de stockage, un snapshot à froid pris sous vos pieds. Dans chacun de ces cas, un conteneur LUKS chiffré n'est qu'un bloc opaque, et celui qui le détient a besoin d'une phrase de passe qui n'a jamais existé ailleurs que dans votre tête ou sur votre ordinateur portable. C'est une frontière réelle et solide, et c'est la plus grande amélioration que la plupart des gens puissent apporter à un serveur loué.

Il est tout aussi important d'être franc sur l'autre moitié du tableau. Un serveur en marche a la clé en RAM — c'est ce qui rend le système de fichiers lisible par vos propres processus — donc le chiffrement ne fait rien contre une compromission du root en direct, un processus hostile à l'intérieur de l'invité, un dump mémoire pris pendant que la machine tourne, ou un hyperviseur qui inspecte cette mémoire. Il ne chiffre pas ce qui sort par le port réseau, et il ne sert à rien si votre application écrit des secrets dans un journal que vous expédiez ensuite ailleurs. Si votre modèle de menace exclut réellement l'inspection par l'hyperviseur, la réponse honnête n'est pas un meilleur chiffre : c'est le matériel dédié à partir de $66.00/mois, où il n'y a tout simplement aucun hyperviseur au-dessus de vous. Pour tout ce qui reste en deçà, le chiffrement au repos associé à un hébergeur qui ne retient presque rien couvre les cas réalistes — les termes en jeu ici sont définis dans le glossaire.

Volume de données chiffré, ou root chiffré ?

Il existe deux approches, adaptées à des situations différentes. La première est un volume de données chiffré : le système d'exploitation reste en clair, et vous placez tout ce qui compte — l'état de votre application, votre base de données, votre stockage documentaire, vos clés — dans un conteneur LUKS monté à l'emplacement de votre choix. C'est installable sur une machine déjà en production, cela ne bloque jamais un redémarrage, et cela protège le matériau que n'importe qui voudrait réellement. Ce que cette approche laisse lisible, c'est la forme du système : votre liste de paquets, vos unités systemd, vos vhosts nginx, votre historique de shell, vos journaux.

La seconde est un root chiffré, où tout sauf une petite partition de démarrage se trouve dans le conteneur. Rien de la machine n'est lisible une fois éteinte, ce qui est le résultat que la plupart des gens imaginent quand ils disent vouloir un serveur chiffré. Le prix se paie à chaque démarrage : un redémarrage s'arrête net sur une invite de phrase de passe, sur une console que vous ne pouvez pas voir, tant que vous ne lui avez pas donné un moyen de vous la demander à distance. C'est bien pour cela que la section suivante existe. Une règle simple : chiffrez le root quand vous construisez une machine depuis zéro et pouvez la tester avant qu'elle ne porte quoi que ce soit ; chiffrez un volume de données quand la machine existe déjà et que l'interruption de service coûte cher. Convertir un root en direct sur place avec cryptsetup reencrypt est possible sous LUKS2, mais ce n'est pas quelque chose que nous recommanderions sur un serveur de production que vous ne pouvez pas reconstruire.

Déverrouillage à distance : un minuscule serveur SSH dans l'initramfs

L'astuce qui rend un root chiffré praticable sur une machine distante s'appelle dropbear-initramfs. L'initramfs est le système miniature que le noyau déballe avant que le véritable root n'existe ; comme vous possédez le noyau sur un VPS KVM, vous pouvez y placer un tout petit démon SSH. Au démarrage, la machine active son interface réseau, lance ce démon, et attend. Vous vous connectez, lancez une commande, la phrase de passe déverrouille le conteneur, le démarrage se poursuit vers le vrai système et le minuscule démon disparaît. Vu de l'extérieur, cela ressemble à un serveur qui prend trente secondes de plus et une action délibérée pour revenir en ligne.

Deux détails causent presque tous les ennuis. Le premier est que le serveur SSH de l'initramfs a sa propre clé d'hôte, différente de celle que présente le système en fonctionnement sur la même adresse — donc si vous le laissez sur le port 22, votre client refusera la seconde connexion à cause d'une incohérence de clé d'hôte, à chaque fois. Donnez-lui un port séparé et un fichier known_hosts séparé, et le problème disparaît. Le second est le délai d'expiration : le démon ne doit pas rester là indéfiniment si vous dormez, mais il ne doit pas non plus abandonner avant que vous n'ayez pu atteindre un terminal. Cinq minutes est une valeur par défaut raisonnable. Restreignez la clé pour qu'elle ne puisse rien faire d'autre que déverrouiller, et traitez l'adresse de cet écouteur de démarrage comme quelque chose que vous ne publiez pas — le même réflexe qui traverse garder son nom à l'écart d'un serveur.

Slots de clé, en-têtes, et l'échec que tout le monde rencontre

Un conteneur LUKS2 ne chiffre pas vos données avec votre phrase de passe. Il chiffre une clé maîtresse avec votre phrase de passe, stocke cette copie enveloppée dans un slot de clé de l'en-tête, et chiffre le volume avec la clé maîtresse. La conséquence mérite d'être intégrée : il existe plusieurs slots, donc vous pouvez inscrire une seconde phrase de passe ou un fichier de clé sans rechiffrer le moindre octet, et vous pouvez en révoquer un sans toucher aux autres. L'autre conséquence est plus tranchante — l'en-tête est la donnée. Écrasez les premiers mégaoctets de ce volume et tous les slots disparaissent d'un coup, avec toute perspective de récupération. Sauvegardez l'en-tête, hors de la machine, au moment où vous créez le conteneur, et de nouveau chaque fois que vous ajoutez ou retirez une clé.

Vient ensuite le mode de défaillance que cet hébergeur rend particulièrement cru. Ici, l'inscription se résume à un pseudonyme et un mot de passe, avec huit codes de récupération et aucun e-mail nulle part dans la boucle, précisément pour qu'il n'y ait aucune identité à divulguer — ce qui signifie aussi qu'il n'existe aucune voie de récupération fondée sur l'identité, pour quoi que ce soit, la vôtre y compris. Personne ne peut se porter garant de vous, et personne n'a de copie de votre phrase de passe. Construisez donc la machine chiffrée pendant que vous en avez encore une qui fonctionne, redémarrez-la délibérément et déverrouillez-la à distance avant qu'elle ne porte des données, conservez la sauvegarde de l'en-tête et un second slot de clé quelque part que vous pourriez encore atteindre après avoir perdu votre ordinateur portable, et assurez-vous que votre plan de reprise se termine par un redéploiement et une restauration depuis une sauvegarde plutôt que par quelqu'un d'autre qui tape une phrase de passe à votre place.

Les fuites en périphérie : swap, snapshots et sauvegardes

Un root chiffré avec une partition swap en clair, c'est une porte verrouillée avec la fenêtre ouverte — le noyau va paginer n'importe quoi vers ce swap, y compris du matériel de clé. La solution consiste à régénérer la clé du swap depuis /dev/urandom à chaque démarrage, ce qui ne coûte rien puisque le swap n'a jamais besoin de survivre à un redémarrage. Appliquez le même traitement à /tmp avec tmpfs quand vous le pouvez, désactivez l'hibernation sur un serveur, et réfléchissez à discard avant de l'activer : faire passer le TRIM jusqu'à la couche de stockage est bon pour le disque, mais divulgue le motif des blocs utilisés, ce qui constitue une petite mais réelle fuite d'information sur le taux de remplissage de votre volume, et où.

Les sauvegardes méritent une réflexion à part, car une sauvegarde est une copie de vos données quelque part où le chiffrement que vous venez de configurer n'atteint pas. Notre option de sauvegardes chiffrées quotidiennes stocke des snapshots hors machine sur les plans VPS, et les snapshots manuels — qui vivent sur le même hôte — sont une commodité de retour en arrière plutôt qu'une sauvegarde, comme le formule la FAQ. Si vous considérez l'hébergeur comme faisant partie de votre modèle de menace, chiffrez alors côté client avant que quoi que ce soit ne quitte la machine, avec une clé qui n'y est pas stockée. Cette seule habitude rend aussi le chemin de restauration portable : une sauvegarde que vous seul pouvez lire est une sauvegarde que vous pouvez restaurer n'importe où, y compris sur un plan VPS différent, dans une région différente.

La place du chiffrement dans un modèle de menace offshore

Le chiffrement est l'un de trois contrôles qui échouent indépendamment les uns des autres, ce qui explique précisément pourquoi utiliser les trois n'est pas de la paranoïa mais de l'ingénierie ordinaire. Le premier est ce que l'hébergeur sait de vous — rien, quand le compte est un pseudonyme alimenté par un solde crypto prépayé à partir de $30.00, réparti sur 8 cryptos et variantes réseau couvrant 7 devises, sans carte ni document dans la chaîne ; c'est le sujet de payer son hébergement anonymement. Le deuxième est quelle loi s'applique, ce qui est décidé par l'endroit où se trouve la machine plutôt que par l'endroit où vous vous trouvez, et qui est traité région par région dans quelle localisation offshore choisir ? et sur le plan légal dans comparatif des juridictions d'hébergement offshore.

Le troisième est ce qui est lisible au repos, et celui-là n'appartient qu'à vous — aucun hébergeur ne peut s'en charger à votre place, parce qu'un hébergeur qui détient votre clé n'a pas résolu le problème qui vous inquiétait. Empilez les trois et chacun couvre une défaillance distincte : une fuite d'identité n'expose pas le disque, une surprise juridictionnelle ne livre pas de phrase de passe, et un disque volé ne révèle pas votre nom. Il y a 6 régions parmi lesquelles choisir sur nos localisations, avec un VPS en ligne en environ 15 min ; sur du matériel dédié, livré en 2–12 h avec les identifiants IPMI, vous pouvez aller encore plus loin et démarrer votre propre installateur plutôt que de faire confiance à une image fournie par l'hébergeur.

Performance, et les machines qui ne valent pas la peine d'être chiffrées

La question des performances est en grande partie réglée par le matériel. Chaque VPS de la flotte tourne sur AMD EPYC 9354 avec AES-NI, si bien que aes-xts-plain64 traite les données à plusieurs gigaoctets par seconde et par cœur — bien au-delà de ce qu'une seule charge de travail demande à une grappe NVMe RAID-1. Lancez cryptsetup benchmark sur votre machine et lisez les chiffres plutôt que de faire confiance à un article de blog, y compris le nôtre. Le surcoût réellement mesurable se manifeste en latence plutôt qu'en débit, et uniquement sur les charges de travail déjà limitées par fsync : une base de données relationnelle à forte écriture, une file d'attente de mails chargée, une queue qui valide chaque message. Pour un serveur web, un backend applicatif, un point de terminaison VPN ou un espace de stockage de fichiers, le coût est négligeable.

La question la plus utile est de savoir quelles machines ne méritent pas cette pièce mobile supplémentaire. Une machine qui ne détient aucun état privé ne gagne rien au chiffrement et hérite d'un redémarrage qui ne peut pas aboutir sans surveillance — un miroir statique public, un nœud de cache, un relais intermédiaire Tor dont le seul secret est une clé d'identité que vous pourriez régénérer en une minute. Chiffrez là où il y a quelque chose à perdre : la base de données, le stockage de mails, la cible de sauvegarde, la machine qui termine votre tunnel WireGuard et détient ses clés privées. Décidez machine par machine, pas flotte entière, et notez ce qui est quoi — l'opérateur dans six mois, c'est vous, avec moins de contexte et une nuit de sommeil plus mauvaise.

Étape par étape

1. 01

   Décidez ce que vous protégez, et choisissez l'architecture

   Notez la seule phrase qui compte : quels fichiers feraient mal si une copie de ce volume sortait des locaux. Si la réponse est une base de données et un répertoire de clés, un volume de données chiffré suffit, et vous conservez des redémarrages sans surveillance. Si la réponse est toute la machine raconte une histoire que je préférerais qu'elle ne raconte pas, construisez un root chiffré et acceptez que chaque démarrage ait besoin de vous. Ne commencez pas à taper avant que cette phrase n'existe.

2. 02

   Déployez un VPS neuf et durcissez-le avant tout le reste

   Déployez depuis le panneau — un VPS est en ligne en environ 15 min — et faites d'abord le travail ennuyeux, sur une machine propre, pendant qu'une erreur ne coûte encore rien. SSH par clé uniquement, un pare-feu en default-deny, des mises à jour de sécurité automatiques, et cryptsetup installé.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   Créez le conteneur LUKS2 et installez-y un système de fichiers

   Pour un volume de données, un conteneur adossé à un fichier est l'option la moins invasive, et se comporte à l'identique d'une partition. Dimensionnez-le selon ce qu'il contient, pas selon le disque. Choisissez une phrase de passe que vous pouvez taper de mémoire sous stress — ce n'est pas un mot de passe que vous collerez depuis un gestionnaire sur une machine qui n'a pas encore démarré.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   Inscrivez une seconde clé et sauvegardez l'en-tête hors de la machine

   Un seul slot de clé vous sépare d'une mauvaise journée de la perte totale. Ajoutez une seconde phrase de passe ou un fichier de clé, exportez l'en-tête dans un fichier, et copiez ce fichier quelque part hors du serveur — un volume chiffré sur votre ordinateur portable, ou un stockage hors ligne. Répétez l'export chaque fois que vous modifiez un slot ; une sauvegarde d'en-tête obsolète peut ressusciter une clé que vous pensiez avoir révoquée.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   Pour un root chiffré, installez le démon SSH de l'initramfs

   Pertinent uniquement si le root lui-même est chiffré. Placez votre clé publique là où l'initramfs la trouvera, déplacez l'écouteur hors du port 22 pour qu'il n'entre jamais en collision avec la vraie clé d'hôte, activez l'interface en DHCP, puis reconstruisez. Les chemins ont changé sous Debian 12 : c'est /etc/dropbear/initramfs/ là-bas, et /etc/dropbear-initramfs/ sous Debian 11.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Redémarrez délibérément, pendant que la machine est encore vide

   C'est l'étape que les gens sautent, et regrettent. Redémarrez délibérément, avant qu'il n'y ait des données, et déverrouillez par le réseau exactement comme vous le feriez à trois heures du matin. Gardez l'écouteur de démarrage dans son propre fichier known_hosts pour que sa clé d'hôte n'entre jamais en conflit avec la vraie. Si elle ne revient pas, vous avez perdu une machine de test plutôt qu'une machine de production.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Refermez les fuites en périphérie et rédigez le plan de reprise

   Régénérez la clé du swap depuis /dev/urandom pour que rien de ce qui a été paginé ne survive à un redémarrage, gardez l'hibernation désactivée, et chiffrez les sauvegardes côté client avant qu'elles ne quittent la machine. Rédigez ensuite le runbook de reprise — où vit la sauvegarde de l'en-tête, quel slot correspond à quoi, et le chemin de redéploiement-et-restauration que vous suivrez le jour où déverrouiller ne sera plus une option. Un plan que vous n'avez pas écrit est un plan que vous n'avez pas.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256