Ce que le chiffrement d'un disque loué vous apporte réellement
Un serveur a deux états, et le chiffrement du disque n'a un avis que sur l'un des deux. Éteinte, le volume est du texte chiffré : le stockage contient des octets indiscernables de bruit sans la clef. En fonctionnement, le volume est monté, ce qui signifie que la clef maître a été dérivée, chargée en mémoire noyau et laissée là aussi longtemps que la machine tourne. Chaque fichier que le système d'exploitation peut lire, il peut le lire parce que cette clef est résidente. Le chiffrement n'a pas cessé de fonctionner — il fait exactement ce qu'on lui a demandé de faire.
C'est une garantie plus étroite que ce que suggère le marketing, et elle reste utile, parce que les événements qu'elle couvre sont ceux qui arrivent réellement. Un disque est retiré du service et revendu. Un NVMe défaillant repart chez le fabricant sous RMA avec vos données dessus. Un nœud est mis hors tension et ses disques sont imagés. Une archive de sauvegarde quitte les locaux sur un support que personne n'a chiffré. Quelqu'un ayant un accès physique à une baie repart avec la mauvaise chose. Ce n'est pas spectaculaire, et ça représente l'écrasante majorité des expositions réelles — bien plus fréquent que la perquisition sur une machine en fonctionnement que tout le monde imagine.
| Scénario | État de la machine | LUKS aide-t-il ? | Ce qui est exposé |
|---|---|---|---|
| Disque retiré du service, revendu ou renvoyé sous RMA | Éteinte | Oui, complètement | Texte chiffré et en-tête LUKS |
| Nœud mis hors tension, disques imagés | Éteinte | Oui | Texte chiffré, plan de partitionnement, /boot en clair |
| Archive de sauvegarde copiée hors site | n/a | Seulement si l'archive elle-même est chiffrée | Tout ce que contient l'archive, en clair |
| Acquisition à chaud d'une instance en fonctionnement | En fonctionnement | Pratiquement non | Tout — la clef est en RAM |
| Compromission du système en fonctionnement | En fonctionnement | Non | Tout ce que le volume monté expose |
L'hyperviseur fait partie de votre modèle de menace, et le chiffrement ne l'en retire pas
Sur un VPS, votre noyau est un invité (guest). Quiconque exploite l'hyperviseur détient la mémoire de cet invité de la même façon que vous détenez le contenu d'un fichier, et il n'y a aucune étape cryptographique entre les deux. virsh dump écrit la RAM d'un domaine en fonctionnement dans un fichier, en tant qu'opération de routine ; la migration à chaud copie cette même mémoire sur le réseau par conception, parce que c'est exactement ce qu'est une migration. Une clef maître LUKS qui vit dans la mémoire de l'invité se trouve dans tout ça.
Donc la phrase honnête est celle-ci : le chiffrement intégral du disque sur un VPS protège vos données de tout le monde sauf de l'entité qui exploite l'hyperviseur — et d'elle aussi, mais seulement pendant que la machine est éteinte. Tout hébergeur qui prétend que chiffrer le disque de votre invité rend vos données illisibles pour lui sur une instance en fonctionnement décrit une machine qui n'existe pas. Nous préférons l'écrire noir sur blanc plutôt que de vous laisser en déduire quelque chose de plus confortable.
Si le fournisseur fait réellement partie de votre modèle de menace, la réponse n'est pas un chiffrement plus fort. C'est de retirer l'hyperviseur : un serveur dédié fait tourner votre noyau à même le métal, donc lire sa mémoire suppose d'avoir la machine physiquement entre les mains et de monter une attaque de type DMA ou cold-boot contre la RAM — lent, bruyant, et exigeant un niveau d'accès qu'une demande de routine ne confère pas. Le guide VPS contre dédié détaille les autres raisons pour lesquelles ce changement se rentabilise aussi. Les extensions de calcul confidentiel comme AMD SEV-SNP et Intel TDX visent précisément cette faille, mais elles ne sont pas une commodité sur les VPS loués aujourd'hui, et elles déplacent la confiance vers le fabricant du CPU plutôt que de l'éliminer.
Trois façons de le faire, et ce que chacune vous coûte
En pratique, il existe trois configurations, qui arbitrent entre la sécurité et la douleur de vos redémarrages. Une racine chiffrée déverrouillée depuis la console est la plus solide et la plus contraignante : rien ne survit à un redémarrage sans intervention humaine. Une racine chiffrée avec un serveur SSH dans l'initramfs offre la même sécurité avec un déverrouillage à distance, et c'est ce que la plupart des gens devraient mettre en place. Un volume de données chiffré sur une racine en clair est l'option facile, et celle qui déçoit en silence.
Elle déçoit parce qu'une racine en clair collecte vos secrets, que vous le vouliez ou non. Le journal systemd y écrit. Tout comme l'historique du shell, le cache des paquets, les core dumps, /tmp, la racine de données par défaut de Docker, et — celui qui piège presque tout le monde — le swap, qui est l'endroit où va la mémoire d'un processus quand la machine est sous pression. Chiffrer /var/lib/mysql alors que le swap reste non chiffré juste à côté n'est pas une défense partielle, c'est une défense complète avec un trou au milieu.
| Configuration | Déverrouillage | Survit à un redémarrage sans surveillance | Verdict honnête |
|---|---|---|---|
| Racine chiffrée, déverrouillage console | KVM-over-VNC ou IPMI | Non — reste hors service jusqu'à un déverrouillage humain | La plus solide ; correcte pour une machine que vous redémarrez rarement |
| Racine chiffrée, dropbear dans l'initramfs | SSH vers le port de déverrouillage | Non — mais vous pouvez déverrouiller de n'importe où | Le choix par défaut raisonnable |
| Volume de données chiffré, racine en clair | Script ou manuel après le démarrage | Oui | Faible sauf si le swap, les logs et le temporaire sont traités |
| Racine chiffrée, fichier clef sur /boot en clair | Automatique | Oui | Défend contre un disque revendu et rien d'autre |
Installer une racine chiffrée, étape par étape
1. Démarrez un installeur, pas un template. Une image préconstruite ne peut pas vous donner une racine chiffrée, parce que le disque a été écrit avant que vous n'existiez en tant que client. Chaque forfait BitVPS prend en charge la reconstruction depuis ISO, l'upload d'une ISO personnalisée et le netboot, et chaque forfait inclut une console d'urgence KVM-over-VNC — c'est la partie qui compte, parce que vous devez surveiller un installeur qui va poser des questions. Les serveurs dédiés exposent la même capacité via un point d'accès IPMI protégé par VPN, avec montage d'ISO et accès BIOS.
2. Partitionnez avec une petite zone de démarrage en clair. Une petite partition pour /boot ou la partition système EFI, et tout le reste dans un seul conteneur LUKS. Le chargeur de démarrage et l'initramfs doivent être lisibles avant qu'aucune clef n'existe, donc cette partition reste lisible par quiconque image le disque. Concevez votre installation en tenant compte de ce fait plutôt qu'en prétendant le contraire.
3. Créez le conteneur. cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/vda2. LUKS2 avec argon2id est tout l'intérêt de la manœuvre : argon2id est memory-hard, spécifié dans la RFC 9106, et il rend une attaque par force brute hors ligne coûteuse en matériel plutôt que simplement lente en logiciel — la différence entre une ferme de GPU qui mâche votre passphrase et une ferme de GPU qui n'a même pas intérêt à s'y intéresser. Gardez le coût mémoire dans les limites de ce que la machine peut allouer pendant le tout début du démarrage ; sur une instance à 4 GB, un coût réglé sur votre portable à 64 GB échouera tout simplement à déverrouiller.
4. Ouvrez-le et installez. cryptsetup open /dev/vda2 cryptroot, puis LVM ou un système de fichiers directement sur /dev/mapper/cryptroot, puis lancez l'installeur de la distribution dessus avec /boot sur la partition en clair. Debian, Ubuntu, Alpine, Arch, Rocky, Fedora et FreeBSD gèrent tous ce cas ; les pages dm-crypt du wiki Arch sont la référence la plus complète, quelle que soit la distribution que vous utilisez réellement.
5. Placez un serveur SSH dans l'initramfs. Installez dropbear-initramfs, déposez votre clef publique dans /etc/dropbear/initramfs/authorized_keys, et ajoutez un paramètre ip= à la ligne de commande du noyau pour que l'interface se lève avant l'invite de passphrase. Omettez ce paramètre, et vous avez construit une machine qui démarre sur une invite que personne ne peut atteindre.
6. Reconstruisez et redémarrez. update-initramfs -u intègre le serveur, votre clef et les paramètres réseau dans l'image que charge le chargeur de démarrage. Redémarrez ensuite avec la console ouverte, parce que la première tentative est celle qui tourne mal.
7. Déverrouillez et confirmez le passage de relais. Connectez-vous en SSH sur le port de déverrouillage et lancez cryptroot-unlock. L'initramfs présente une clef d'hôte différente de celle du système installé, donc votre client va vous avertir bruyamment à la première connexion — c'est le comportement correct, et un signal utile, pas un obstacle : épinglez cette empreinte dans sa propre entrée known_hosts plutôt que de désactiver la vérification de la clef d'hôte. La coupure de la session est ce qui vous indique que le vrai système a pris le relais.
Déverrouillage à distance, et la question de 4h du matin que personne ne pose en premier
Faites tourner le serveur SSH de l'initramfs sur son propre port — 2222 est la convention — pour que les deux clefs d'hôte n'entrent jamais en collision dans la même entrée known_hosts. Préférez un ip= statique au DHCP : l'initramfs est un environnement minimal, et un aller-retour DHCP qui échoue vous laisse avec une machine allumée, inaccessible, et bloquée sur une invite. Si vous comptez sur IPv6, vérifiez que votre initramfs le configure réellement ; plusieurs distributions ne montent encore que l'IPv4 à ce stade.
Gardez la console comme solution de repli même une fois que le déverrouillage SSH fonctionne. La panne que vous finirez par rencontrer ne sera pas cryptographique, ce sera une mise à jour du noyau qui a reconstruit l'initramfs sans votre clef, ou un paramètre réseau qui a changé sous vos pieds — et à ce moment-là, la seule voie d'entrée est la console KVM-over-VNC fournie avec le forfait. Avoir les deux n'est pas de la redondance, c'est la différence entre un désagrément et une reconstruction complète.
Vient ensuite la question opérationnelle, celle qu'il faut trancher avant de construire tout ceci : une racine chiffrée signifie qu'un redémarrage sans surveillance laisse votre service hors service jusqu'à ce qu'un humain le déverrouille. Maintenance de nœud, kernel panic, coupure d'alimentation — la machine revient sur une invite, pas sur votre application. Si c'est inacceptable pour la charge de travail, ne masquez pas le problème avec un fichier clef sur la partition de démarrage en clair. C'est une serrure avec la clef scotchée sur la porte, et ça ne défend que contre un disque revendu et rien d'autre. Choisissez cette option délibérément si vous le voulez, mais notez dans votre propre runbook que c'est ce que vous avez choisi.
Tout ce qui fuit autour du volume chiffré
Le volume est rarement l'endroit où ça tourne mal. Ce qui tourne mal, c'est ce qui n'a jamais fini par y entrer.
| Fuite | Pourquoi ça arrive | Correctif |
|---|---|---|
| Swap | La mémoire des processus — clefs comprises — déborde sur disque sous pression | Swap à l'intérieur du conteneur, ou un périphérique de swap à clef aléatoire, ou pas de swap du tout |
| Image d'hibernation | Un dump RAM complet écrit sur disque par conception | Désactivez-la sur un serveur ; elle n'a rien à y faire |
| /boot et initramfs en clair | Doivent être lisibles avant qu'aucune clef n'existe | Acceptez-le, et traitez toute modification comme une compromission — vérifiez, ou utilisez Secure Boot là où c'est disponible |
| Journal écrit avant le montage | Les logs de tout début de démarrage atterrissent sur la partition en clair | Vérifiez où votre journal vit réellement avant que le volume ne s'ouvre |
| Racine de données Docker | Par défaut /var/lib/docker, en dehors d'un volume de données rapporté | Déplacez-la à l'intérieur, ou chiffrez la racine à la place |
| Supervision et logs hors machine | Des agents envoient le contenu de fichiers à un tiers en clair | Auditez ce que l'agent envoie avant de faire confiance au volume |
Une propriété à bien clarifier, parce qu'elle est régulièrement survendue : un en-tête LUKS s'annonce lui-même. Quiconque image le disque voit qu'un conteneur chiffré est présent, quel algorithme il utilise, les paramètres du KDF, et combien d'emplacements de clef sont occupés. LUKS vous donne la confidentialité, pas le déni plausible, et bâtir un plan qui repose sur le fait que personne ne remarque le conteneur, c'est bâtir sur du sable.
Passphrases, fichiers clefs et en-têtes détachés
La passphrase, c'est tout le système. Argon2id rend chaque essai coûteux, mais coûteux multiplié par un espace de clefs restreint reste bon marché : cinq ou six mots tirés d'une liste diceware battent un mot de passe de onze caractères avec des substitutions dedans, et l'écart n'est pas serré. Réglez le coût avec --iter-time en fonction de la machine qui déverrouillera réellement le volume, pas celle sur laquelle vous tapez, et ne réutilisez jamais une passphrase qui a ne serait-ce qu'approché un compte KYC.
Un fichier clef supprime la saisie et déplace le problème : cryptsetup luksAddKey en ajoute un dans un emplacement libre, et la seule version qui vaille la peine est celle qui ne repose jamais sur le serveur — conservée sur votre propre machine ou un token matériel, et fournie au déverrouillage via la session SSH. Un en-tête détaché (--header) va plus loin : le périphérique de données devient indiscernable d'octets aléatoires parce que les métadonnées vivent ailleurs. Le revers de la médaille est sans pitié. Perdez l'en-tête et le volume disparaît, définitivement, sans aucun recours possible — alors prenez cryptsetup luksHeaderBackup au sérieux, et stockez cette sauvegarde quelque part d'elle-même chiffré. La FAQ officielle de cryptsetup et la documentation dm-crypt du noyau sont les deux références à lire avant de vous engager sur une disposition.
Et une règle sans exception : la passphrase ne va jamais dans un ticket de support. Ni le nôtre, ni celui de personne d'autre. Rien de ce que nous faisons n'en a besoin, aucune opération que nous pouvons effectuer en votre nom n'en a besoin, et un ticket est une trace écrite dans une base de données. Si un hébergeur vous la demande un jour, c'est la fin de la conversation.
Ce qu'un disque imagé livre réellement
Prenons le cas de la machine éteinte concrètement, parce que le flou n'aide personne ici. Un enquêteur qui dispose d'une image de votre disque a : le texte chiffré, l'en-tête LUKS avec son algorithme, ses paramètres de KDF et son nombre d'emplacements, la table de partitions, la taille de tout, et l'intégralité de la partition de démarrage en clair — votre noyau, votre initramfs, et les horodatages de modification de chaque fichier qu'il contient. Ce dernier point est plus informatif qu'on ne le pense. Les dates d'installation des paquets esquissent une chronologie, et un initramfs contenant une clef dropbear en dit long sur la façon dont la machine était administrée.
Ce qu'il n'a pas, c'est le contenu. Contre un conteneur LUKS2 moderne avec argon2id et une vraie passphrase, l'attaque hors ligne n'est pas une question d'attendre plus longtemps — elle n'est tout simplement pas envisageable. C'est toute la proposition de valeur, et elle est solide.
Le cas de la machine en fonctionnement est l'inverse, et la réponse est courte : tout. Pas parce que le chiffrement a échoué, mais parce que la clef est résidente — c'est la condition même pour qu'un système de fichiers monté fonctionne.
Les instantanés (snapshots) se situent entre les deux, et surprennent les gens. Nos instantanés horaires avec rétention de 7 jours sont au niveau bloc, donc un volume chiffré donne un instantané en texte chiffré — c'est une bonne chose, et le corollaire mord en retour : cet instantané n'est pas non plus une copie que vous pouvez lire sans la passphrase. Perdez la clef, et les instantanés sont exactement aussi irrécupérables que l'original. Prévoyez un chemin de restauration qui inclut la passphrase, sinon vous avez construit sept jours de bruit très fiable. Ce que nous détenons sur vous en dehors du volume est écrit dans la politique de confidentialité, et nous publions chaque semaine un warrant canary signé PGP comme preuve permanente plutôt que comme promesse.
Ce qui décide de l'issue n'est pas cryptographique
Personne n'a jamais perdu de données parce qu'AES-256-XTS a lâché. On les perd parce que la passphrase a été réutilisée depuis un compte d'exchange où était enregistré un passeport, parce que le fichier clef a été laissé sur la partition de démarrage en clair pour que les redémarrages soient silencieux, parce que la sauvegarde hors site était une simple tarball, parce que la passphrase traîne dans l'historique du shell du portable, ou parce qu'un agent de supervision envoyait le contenu de fichiers à un SaaS depuis le début.
Et celui dont on parle peu : un serveur qui n'est jamais éteint passe toute sa vie dans l'état où rien de tout ça n'aide. Une instance avec 400 jours d'uptime a été déchiffrée pendant 400 jours. Si les données sont réellement froides — une archive, une sauvegarde de clef, des registres que vous consultez deux fois par an — gardez-les dans un conteneur que vous ouvrez quand vous en avez besoin et cryptsetup close une fois terminé. Dix secondes de saisie convertissent une exposition permanente en exposition momentanée, et cette conversion vaut plus que n'importe quel paramètre que vous pouvez passer à luksFormat.
Faites correspondre la juridiction au même raisonnement pendant que vous y êtes. Le chiffrement décide de ce qui est lisible ; où se trouve la machine décide qui a le droit de demander, et à travers quelles alliances la demande transite. Les deux ne sont pas interchangeables, et ceux qui font bien les choses les traitent comme une seule et même décision.
Ce que nous fournissons, et ce que nous ne pouvons pas
Chaque forfait à partir du Starter à $8.50 embarque ce qu'une racine chiffrée exige réellement : virtualisation KVM avec root complet, la possibilité de démarrer des ISO personnalisées et le netboot, la reconstruction depuis ISO depuis le panneau, le chargement de modules noyau, et une console d'urgence KVM-over-VNC pour le moment où l'initramfs ne revient pas. Les paliers dédiés ajoutent un point d'accès IPMI protégé par VPN, avec console, power cycle, montage d'ISO et accès BIOS. Rien dans le chiffrement n'est un produit que nous vous vendons — c'est quelque chose que vous construisez, et notre travail est de ne pas se mettre en travers du chemin.
Ce que nous ne pouvons pas faire est plus utile à énoncer. Sur un VPS en fonctionnement, l'hyperviseur peut lire la mémoire de l'invité ; c'est l'architecture, pas un réglage de politique, et aucun chiffrement que vous installez à l'intérieur de l'invité n'y change quoi que ce soit. Ce que nous offrons contre ça, ce n'est pas des mathématiques mais une posture et des preuves : pas de netflow, pas de PCAP, pas de mirroring de NIC, IP de session du panneau purgées à 24 heures, pas de KYC à l'inscription pour que le compte ne soit pas un levier, paiement crypto uniquement pour que la piste de facturation n'en soit pas un non plus, et un canary signé PGP chaque semaine que vous pouvez vérifier vous-même. Seul le matériel dédié retire l'hyperviseur de l'équation, et seule la mise hors tension en retire la RAM.
Si ça se lit comme un argument contre notre propre VPS dans certains modèles de menace, c'est parce que ça en est un. Nous préférons vous vendre la bonne chose deux fois plutôt que la mauvaise une fois. Déployez une instance avec une ISO et testez l'installation sur un Starter pendant un mois ; si la réponse s'avère être du métal, les paliers dédiés démarrent à $39.50 et prennent deux à quatre heures à provisionner plutôt que 41 secondes.
