Chiffrer un VPS a l'air de se résumer à une ligne de commande — cryptsetup luksFormat, terminé — avant de tranquillement ne pas tenir la promesse que tout le monde croyait avoir achetée. Sur une machine louée, un hyperviseur tourne sous votre noyau, donc le modèle de menace n'est pas celui pour lequel le chiffrement intégral de disque a été pensé. Voici la version honnête : ce que LUKS neutralise sur un VPS, ce qu'il ne neutralise pas, les deux chemins de déploiement qui fonctionnent, et comment déverrouiller une racine chiffrée en SSH pour ne jamais rester à la porte de votre propre serveur.
Ce que le chiffrement vous apporte réellement sur un serveur loué
Le chiffrement intégral protège les données au repos. Cette formule contient plus de nuances qu'il n'y paraît, et sur un VPS, ça vaut la peine de préciser quels moments comptent comme du repos et lesquels non — c'est dans cet écart que la plupart des attentes se brisent.
Matériel mis au rebut
Les disques tombent en panne, sont remplacés, et quittent la baie. Un volume LUKS sur un disque mort n'est qu'un bloc de bruit pour quiconque le manipule ensuite. Le chiffrement règle ce cas complètement.
Un volume détaché ou copié
Si un volume est retiré de votre instance, cloné, ou imagé pendant que la machine est éteinte, le résultat est du texte chiffré et un en-tête — pas vos fichiers.
Une machine en fonctionnement
Une fois le volume ouvert, la clé maîtresse vit dans la mémoire du noyau. Un accès au niveau de l'hyperviseur peut en principe l'atteindre. Le chiffrement augmente le coût ici ; il ne ferme pas la porte.
Vos propres erreurs
Le swap non chiffré, les sauvegardes en clair et les logs écrits avant le montage restent tous hors du périmètre chiffré. La plupart des fuites réelles sur des serveurs chiffrés viennent de là, pas de l'algorithme.
Formulez clairement cette limite pour pouvoir vous en accommoder : tant que le volume est déverrouillé, la clé se trouve en RAM sur du matériel qui ne vous appartient pas. LUKS sur un VPS répond solidement à l'accès hors ligne, et partiellement à l'accès en direct. Associez-le à une juridiction en laquelle vous avez vraiment confiance — voir /offshore-hosting — plutôt que d'en faire un substitut à cette confiance.
Choisissez la forme avant de taper la moindre commande
Quatre configurations couvrent presque tous les besoins réels. Se tromper de choix coûte une réinstallation complète, donc décidez maintenant plutôt qu'à mi-parcours.
Chemin A — chiffrer un volume de données sur un serveur déjà en service
C'est la version que la plupart des gens veulent réellement : dix minutes de travail, aucune réinstallation, et tout ce qui compte finit à l'intérieur du périmètre chiffré. Attachez d'abord un second volume — sur une offre /storage, c'est le grand disque ; sur un /vps standard, vous pouvez en ajouter un au moment du déploiement.
- 1
Identifiez le périphérique cible
Lancez lsblk et confirmez que le périphérique que vous vous apprêtez à formater est bien le vide. luksFormat détruit tout ce qui s'y trouve, sans possibilité de retour en arrière.
- 2
Créez le conteneur LUKS2
cryptsetup luksFormat --type luks2 /dev/vdb vous demande de taper YES en majuscules, puis de définir une phrase de passe. Choisissez-en une que vous pouvez retaper correctement sur une console sans historique et sans écho.
- 3
Ouvrez-le et posez un système de fichiers
cryptsetup open /dev/vdb cryptdata crée /dev/mapper/cryptdata. Faites ensuite mkfs.ext4 /dev/mapper/cryptdata et montez-le là où les données vivront, par exemple /srv/data.
- 4
Décidez comment il se déverrouille au démarrage
Soit vous tapez la phrase de passe après chaque redémarrage, soit vous ajoutez un fichier de clé avec cryptsetup luksAddKey et le stockez sur la racine. Le fichier de clé est pratique et strictement plus faible — soyez clair sur le compromis que vous faites.
- 5
Câblez crypttab et fstab
Ajoutez le mappage dans /etc/crypttab en utilisant UUID= plutôt qu'un nom de périphérique, puis montez depuis /etc/fstab avec nofail pour qu'un déverrouillage échoué ne bloque jamais le démarrage.
Si le fichier de clé se trouve sur la racine non chiffrée, soyez précis sur ce que vous avez réellement : le volume est protégé contre un disque qui quitte la baie ou qui est détaché de votre instance, mais pas contre une copie de la VM entière — parce que cette copie contient la clé. Toute protection plus forte exige que la phrase de passe vienne de l'extérieur du serveur.
Chemin B — une racine chiffrée depuis une ISO personnalisée
Quand l'exigence est qu'il n'existe rien de lisible sur la machine quand elle est éteinte, la racine elle-même doit se trouver à l'intérieur de LUKS. Cela suppose une installation neuve pilotée depuis la console, chez un fournisseur qui vous laisse démarrer votre propre ISO.
- 1
Démarrez l'installeur depuis la console
Montez une ISO netinst Debian ou Ubuntu comme ISO personnalisée et pilotez l'installation en VNC ou en série. Rien de tout cela ne fonctionne en SSH — il n'y a encore aucun système auquel se connecter.
- 2
Utilisez le partitionnement guidé avec LVM chiffré
L'installeur laisse un petit /boot en clair, parce que quelque chose doit s'exécuter avant que le volume ne s'ouvre, et place la racine et le swap à l'intérieur d'un seul conteneur LUKS.
- 3
Choisissez une phrase de passe que vous pouvez taper à l'aveugle
Vous la retaperez en SSH à chaque redémarrage, sans écho et sans autocomplétion. Une phrase de passe de cinq mots vaut mieux qu'une soupe de symboles ici.
- 4
Configurez le déverrouillage distant avant de vous déconnecter
Une racine fraîchement chiffrée restera indéfiniment bloquée sur l'invite de phrase de passe dès le prochain redémarrage. Configurez le déverrouillage distant dans la même session, pendant que la console est encore sous vos yeux.
Sur les offres avec 1 à 2 Go de RAM, la dérivation de clé Argon2id par défaut peut demander plus de mémoire que n'en a l'initramfs, et le déverrouillage échoue au démarrage même si la phrase de passe est correcte. Plafonnez-la au moment du formatage avec cryptsetup luksFormat --pbkdf-memory 262144, ou inspectez un en-tête existant avec cryptsetup luksDump avant de faire confiance à une petite instance pour redémarrer sans surveillance.
Déverrouillage distant en SSH avec dropbear-initramfs
Une racine chiffrée a besoin d'une phrase de passe avant même que le système d'exploitation n'existe. dropbear-initramfs place un minuscule serveur SSH à l'intérieur de l'initramfs pour que vous puissiez la fournir depuis n'importe où — la différence entre un serveur chiffré et une brique chiffrée.
- 1
Installez le paquet
apt install dropbear-initramfs. Il s'accroche à la génération de l'initramfs et est automatiquement reconstruit dans chaque future image de noyau.
- 2
Autorisez une clé, et une seule commande
Placez votre clé publique dans /etc/dropbear/initramfs/authorized_keys — sur Debian 11 et versions antérieures, /etc/dropbear-initramfs/authorized_keys. Préfixez la ligne avec no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" pour qu'une clé volée ne donne accès à rien d'autre qu'une invite.
- 3
Donnez un réseau à l'initramfs
DHCP fonctionne là où le fournisseur le propose ; sinon, ajoutez un paramètre statique ip=ADDRESS::GATEWAY:NETMASK::eth0:off à GRUB_CMDLINE_LINUX et lancez update-grub. Terminez avec update-initramfs -u -k all pour que le changement atterrisse dans l'image.
- 4
Testez un redémarrage complet avant d'en dépendre
Redémarrez avec la console du fournisseur ouverte dans une autre fenêtre, connectez-vous, entrez la phrase de passe et regardez le démarrage se poursuivre. Un chemin de déverrouillage jamais testé n'est pas une fonctionnalité, c'est une future panne.
L'initramfs porte sa propre clé d'hôte SSH, différente de celle que présente le système une fois démarré, donc votre client vous avertira d'un changement de clé d'hôte à chaque redémarrage. Faites tourner dropbear sur un port séparé via DROPBEAR_OPTIONS dans /etc/dropbear/initramfs/dropbear.conf, ou connectez-vous avec ssh -o HostKeyAlias=box-initramfs, et enregistrez les deux empreintes.
La gestion des clés est là où le chiffrement de disque échoue le plus souvent
L'algorithme n'est pas le maillon faible, et ne l'a jamais été. Tout désastre récupérable impliquant LUKS se résume à une clé ou à un en-tête, donc traitez les deux comme de l'infrastructure à part entière.
- Sauvegardez l'en-tête immédiatement — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — et stockez-le hors du serveur. Un en-tête endommagé par un dd malheureux, c'est une perte de données définitive, même avec une phrase de passe parfaite.
- Utilisez deux emplacements de clé. LUKS2 vous en offre 32 : votre phrase de passe dans l'un, une longue clé de récupération aléatoire dans l'autre, conservée dans un gestionnaire de mots de passe. Un seul emplacement est un point unique de défaillance auto-infligé.
- Faites la rotation dans le bon ordre sur une machine distante — ajoutez la nouvelle clé avec luksAddKey, vérifiez qu'elle ouvre bien le volume, puis retirez l'ancienne avec luksKillSlot. Jamais l'inverse.
- Gardez la phrase de passe et les informations de connexion du serveur à des endroits séparés. Une seule note compromise ne devrait pas livrer à la fois l'adresse et la clé.
Ce que le chiffrement coûte en performance
Le surcoût est réel, mais généralement invisible. Mesurez-le sur la machine que vous avez réellement, plutôt que de vous fier à un benchmark d'une autre décennie.
Ce que les gens oublient
Un volume chiffré qui laisse fuir du contenu en clair sur ses bords donne un faux sentiment de sécurité, ce qui est pire que pas de sécurité du tout. Verrouillez ces cinq points avant de considérer le travail terminé.
- Le swap. Une partition de swap non chiffrée peut contenir des fragments de tout ce qui est passé par la mémoire. Chiffrez-la avec une clé aléatoire fraîche à chaque démarrage via une entrée /dev/urandom dans /etc/crypttab.
- Les logs écrits avant le montage. Tout ce qui est journalisé pendant que le volume chiffré est encore fermé atterrit sur la racine en clair. Pointez les logs applicatifs et de base de données vers un chemin situé à l'intérieur du périmètre chiffré.
- Les sauvegardes. Copier le contenu d'un volume chiffré vers un stockage objet en clair annule tout l'exercice. Chiffrez la sauvegarde indépendamment avec restic, borg ou age, et conservez ces clés ailleurs.
- Les instantanés (snapshots). Un instantané pris par le fournisseur capture le disque, pas votre RAM, donc le volume LUKS y reste sous forme de texte chiffré — mais tout ce qui traîne sur la racine non chiffrée est capturé exactement tel quel.
- Discard. Faire passer l'option discard à travers LUKS garde le trim NVMe fonctionnel, mais publie quels blocs sont inutilisés, ce qui laisse fuir le taux de remplissage du système de fichiers et, à peu près, sa forme. Choisissez-la délibérément, pas en copiant une configuration.
Là où l'hébergeur compte encore
Le chiffrement est la couche que vous contrôlez : elle détermine à quel point il est coûteux de lire vos données une fois la machine éteinte ou un disque sorti du bâtiment. La couche autour — qui peut contraindre l'accès au matériel, et quelles traces relient le serveur à vous — appartient au fournisseur et à sa juridiction. Six de nos quinze régions sont des juridictions de niveau confidentialité ; /locations les recense, et /offshore-hosting détaille ce que ça change réellement.
Trois capacités du fournisseur décident si les chemins ci-dessus sont même envisageables : le démarrage sur ISO personnalisée, sans lequel le Chemin B est impossible ; un accès console hors bande pour le redémarrage où le déverrouillage distant ne suffit pas ; et une inscription qui n'a jamais lié la machine à votre identité légale au départ. Chaque offre /offshore-vps et /storage ici démarre sur ISO personnalisée, inclut un accès console, et se facture depuis un solde crypto prépayé sans KYC — un disque chiffré ne repose donc pas sur une piste papier qui vous nomme déjà. /guides explique honnêtement ce qu'un hébergeur peut voir, et ce qu'il ne peut pas.
La checklist de déploiement
- Nommez d'abord la menace : les disques mis au rebut, les volumes détachés et les images hors ligne sont ce à quoi répond le chiffrement — un hyperviseur actif, non.
- Chiffrez un volume de données (Chemin A) si le serveur tourne déjà ; réinstallez depuis une ISO personnalisée (Chemin B) uniquement quand la racine elle-même doit être chiffrée.
- LUKS2 avec aes-xts-plain64, et plafonnez la mémoire Argon2id sur toute offre en dessous de 2 Go de RAM.
- La phrase de passe dans un emplacement de clé, une longue clé de récupération aléatoire dans un autre, les deux stockées hors du serveur.
- Effectuez une sauvegarde de l'en-tête LUKS avant d'écrire le premier octet de données réelles.
- dropbear-initramfs sur un port non standard, clé uniquement, restreint à la commande cryptroot-unlock.
- Testez un cycle complet de redémarrage et déverrouillage avec la console du fournisseur encore ouverte à côté de vous.
- Des sauvegardes chiffrées hors site, plus un exercice de restauration — une sauvegarde jamais testée est un espoir, pas une sauvegarde.
Le chiffrement de disque empêche-t-il mon hébergeur de lire mes données ?
Au repos, oui : une fois la machine éteinte, le volume est du texte chiffré et la phrase de passe n'a jamais quitté votre tête. Pendant que le serveur tourne avec le volume ouvert, la clé maîtresse est en RAM sur du matériel exploité par le fournisseur. Le chiffrement ferme toutes les voies hors ligne — disques mis au rebut, volumes détachés, images à froid — et augmente le coût du reste. Il complète une juridiction de confiance plutôt que d'en tenir lieu.
Puis-je chiffrer un VPS existant sans le réinstaller ?
Un volume de données séparé, oui, en une dizaine de minutes — c'est le Chemin A décrit plus haut. Le système de fichiers racine, réalistement non. cryptsetup reencrypt peut convertir un système de fichiers sur place, mais une connexion coupée ou une coupure de courant en plein milieu, sur une machine distante, laisse un serveur qui ne démarre plus et une longue nuit devant vous. Réinstaller depuis une ISO personnalisée est plus rapide et bien plus sûr.
Combien de performance LUKS coûte-t-il ?
Moins que ce que la plupart des gens imaginent. Avec AES-NI, AES-XTS coûte quelques pourcents sur des charges mixtes typiques, et cryptsetup benchmark sur un cœur EPYC moderne rapporte plusieurs GB/s. Le cas visible, ce sont les entrées-sorties séquentielles mono-thread face à un NVMe rapide, où un seul cœur peut saturer avant le disque. Benchmarkez votre propre instance plutôt que de deviner.
Que se passe-t-il si j'oublie la phrase de passe ?
Les données sont perdues. Il n'existe aucun mécanisme de récupération, aucune clé maîtresse côté fournisseur, et aucun ticket de support qui puisse annuler ça — cette propriété est précisément l'objectif de la conception. Protégez-vous avec un second emplacement de clé contenant une clé de récupération aléatoire, et avec une sauvegarde de l'en-tête LUKS stockée ailleurs que sur le serveur.
Faire tourner SSH dans l'initramfs est-il risqué ?
C'est une exposition petite et bien comprise. dropbear ne tourne que pendant les quelques secondes avant que votre système de fichiers racine n'existe, n'accepte que des clés publiques, et peut être restreint à une seule commande forcée qui ne fait rien d'autre que demander une phrase de passe. Sur un port non standard, avec la clé d'hôte de l'initramfs enregistrée séparément, le risque pratique est minime, face à la certitude d'être bloqué dehors sans lui.
