Hébergement VPS chiffréLe chiffrement au repos protège une machine éteinte.

Trois états, et celui que l'industrie ne vend pas

On décrit les données comme se trouvant dans l'un de trois états, et cette distinction est le sujet entier de cette page. Au repos, c'est un disque que personne ne lit. En transit, c'est un paquet sur un fil. En cours d'utilisation, c'est un processus qui détient les données en clair dans sa mémoire afin de pouvoir en faire quelque chose.

Les deux premiers sont résolus, et tout fournisseur les vend. Le fil, c'est TLS, et les plateaux sous vos pieds sont presque certainement chiffrés. Très peu de choses sont dites sur le troisième, car c'est là que se tient le fournisseur : un serveur en fonctionnement a son volume déverrouillé, sa clé résidente et ses données en clair. Ce n'est pas un défaut du chiffrement. C'est ce que signifie tourner.

Ce que signifie “chiffré au repos” quand un hébergeur le dit

Le chiffrement au repos côté fournisseur est réel, et cela vaut la peine de l'avoir. Cela signifie que le disque, la grappe de stockage ou le stockage des instantanés est chiffré sous une clé que le fournisseur gère, si bien qu'un disque qui quitte le bâtiment — en panne, remplacé, revendu, volé — devient une brique plutôt qu'une copie de votre base de données. Toute plateforme sérieuse le fait, et cela ne vous coûte rien.

Ce qu'il ne peut pas faire, c'est exclure le fournisseur, puisque le fournisseur détient la clé par définition. C'est un contrôle contre le quai de chargement, pas contre l'opérateur. Un hébergeur qui répond à une question sur son propre accès en décrivant le chiffrement au repos a répondu à une autre question, et le sait généralement.

La version qui exclut réellement le fournisseur est celle où la clé n'arrive jamais. Le compromis est consigné dans le runbook prévu à cet effet : les instantanés sont stockés chiffrés ici, ce parc ne détient aucune clé pour le contenu d'un disque que vous avez chiffré vous-même, et il ne peut donc pas non plus secourir ce disque à votre place. Les deux moitiés de cette phrase sont un seul et même fait, et un hébergeur qui n'offre que la première moitié détient une clé.

Trois machines, trois réponses différentes

“Mon hébergeur peut-il lire mon disque” ne reçoit pas la même réponse sur une instance partagée, sur une machine entière et dans une armoire louée à l'unité. Ces différences méritent d'être exposées, car elles sont généralement vendues comme un seul et même produit, avec seulement des chiffres différents en face.

Aucune de ces lignes n'est un argument contre le produit qui la précède. Ce sont des arguments pour savoir contre quelle menace vous achetez une protection. Un opérateur qui fait tourner l'hyperviseur peut lire la mémoire d'une machine invitée qui s'exécute dessus, et un fournisseur qui prétend le contraire se méprend sur sa propre pile. Ce qu'il lit est soit vos données, soit du bruit, et lequel des deux, c'est ce qu'a décidé, des mois plus tôt, l'endroit où vous avez placé la clé.

La cérémonie de la clé est toute la garantie

Tout ce qui précède se ramène à une seule question opérationnelle : au moment où la machine démarre, d'où vient la clé ? Trois réponses sont utilisées en pratique, et leur solidité n'a rien de comparable.

1. Stockée sur la machine. Un fichier de clé sur le même volume, ou une phrase de passe codée en dur dans un script de provisionnement, pour que le serveur puisse démarrer sans surveillance. C'est du chiffrement en case à cocher : quiconque peut lire le disque peut lire la clé posée juste à côté.
2. Détenue par le fournisseur. Pratique, récupérable, et précisément l'arrangement sur lequel une décision de justice peut agir. La clé existe, quelqu'un la détient, et cette détention est une chose qu'un tribunal peut nommer dans un instrument.
3. Fournie par vous à chaque démarrage. La machine démarre dans un initramfs et ne fait strictement rien tant que vous ne vous connectez pas pour lui transmettre la phrase de passe. La clé n'existe que dans la mémoire de cette machine, seulement pendant qu'elle tourne, et nulle part ailleurs au monde.

Seule la troisième fait sortir la question du registre juridique. Une ordonnance peut contraindre un fournisseur à produire ce qu'il détient ; elle ne peut pas le contraindre à produire une clé qui ne lui a jamais été donnée. C'est une différence de nature, non de degré, et c'est pourquoi le warrant canary signé publié ici porte une affirmation distincte sur l'affaiblissement contraint d'une protection cryptographique. Une promesse sur un comportement et un fait sur de l'arithmétique sont deux instruments différents, et un seul des deux survit à la personne qui l'a formulé.

Ce que le chiffrement intégral du disque laisse encore en clair

Un système de fichiers racine chiffré n'est pas une boîte opaque. Plusieurs éléments se situent en dehors de son périmètre par construction, et savoir lesquels fait toute la différence entre un modèle de menace et une simple impression.

• La chaîne de démarrage. /boot et l'initramfs sont lus avant que quoi que ce soit puisse être déchiffré ; ils sont donc non chiffrés et, sur du matériel loué dont vous ne pouvez pas attester le firmware, non vérifiés. Quiconque peut y écrire peut y placer quelque chose qui capture votre phrase de passe.
• Le swap et l'hibernation. Un espace de swap non chiffré conservera sans broncher des pages de mémoire déchiffrée. Chiffrez-le ou désactivez-le ; il n'existe pas de troisième option sûre.
• La forme de la machine. La taille des partitions, l'en-tête LUKS, la part du volume utilisée, et le simple fait qu'elle est chiffrée.
• Tout ce que détient le processus en cours d'exécution. La base de données dans le cache de pages, la clé privée TLS chargée par le serveur web au démarrage, les variables d'environnement, les sockets ouverts. C'est la plus grande catégorie de la liste, et le chiffrement au repos n'y touche en rien.
• Votre trafic. À qui vous parlez, quand et combien, exactement comme avant. C'est le sujet du guide sans journaux plutôt que de celui-ci.

La chaîne de démarrage est l'élément que l'on sous-estime. Si c'est dans l'initramfs que vous saisissez la phrase de passe, l'initramfs devient une invite d'identifiants sur une machine que vous ne contrôlez pas physiquement — si bien que l'empreinte de sa clé d'hôte SSH compte autant que la phrase de passe elle-même. C'est une clé différente de celle que présente le système une fois démarré, ce qui explique précisément pourquoi une empreinte modifiée au démarrage est acceptée sans broncher. Notez-la la première fois, et vérifiez-la à chaque fois ensuite. Une invite qui a l'air correcte sans l'être : voilà toute l'attaque.

Ce qu'il arrête, et ce qu'il n'arrête pas

Parcourez la colonne du milieu. Le chiffrement est décisif exactement dans les cas où la machine est éteinte ou où la clé n'a jamais été remise, et sans effet dans tous les cas où la machine tourne et où quelqu'un s'y trouve déjà. Ce n'est pas une faiblesse qu'on pourrait contourner par ingénierie. C'est ce qu'est le chiffrement, et une page qui laisse entendre le contraire est en train de vous vendre quelque chose.

Le coût, énoncé avant que vous ne vous engagiez

C'est la section qu'on ne trouve pas sur les pages qui vantent un “hébergement chiffré”, et la raison est que chaque élément qu'elle contient est un désagrément bien réel que vous rencontrerez en moins d'un mois.

• Aucun redémarrage sans surveillance. Une mise à jour du noyau, une coupure d'alimentation ou une migration d'hôte laisse la machine bloquée sur une invite de phrase de passe jusqu'à l'arrivée d'un humain. La disponibilité devient alors une fonction de votre rythme de sommeil.
• Aucun secours. Un fournisseur qui ne peut pas lire le volume ne peut pas le réparer. Les vérifications du système de fichiers, la récupération de données et le “pourriez-vous simplement copier la config depuis ce disque” deviennent votre seule affaire.
• Les sauvegardes sont du texte chiffré. C'est exact, et cela signifie qu'une restauration nécessite aussi la clé. Une sauvegarde que vous ne pouvez pas ouvrir n'est pas une sauvegarde.
• Un en-tête endommagé est fatal. L'en-tête LUKS conserve la clé maîtresse enveloppée dans une petite zone au début du volume. Copiez-le en dehors de la machine dès le premier jour ; sans lui, même une phrase de passe correcte n'ouvre plus rien.
• Un peu de surcharge. Réelle, visible sur un benchmark, et rarement ce qui contraint une charge de travail — tout processeur actuel accélère l'AES matériellement. Mesurez-la sur la machine que vous avez louée plutôt que d'en débattre.

Le mettre en place pour qu'il en vaille la peine

Les commandes se trouvent dans la base de connaissances. Ce qui suit est l'ordre dans lequel les exécuter, ce qui n'est pas, en soi, une commande.

1. Organisez l'accès à la console avant de commencer, pas après. La première erreur survient à l'invite de démarrage, et SSH est précisément ce qui n'y est pas disponible.
2. Chiffrez d'abord un second volume. Des données sur un disque chiffré séparé apportent l'essentiel du bénéfice pour une fraction du risque opérationnel, et cela vous enseigne les modes de défaillance sur une machine qui continue de démarrer seule.
3. Ne placez le système de fichiers racine derrière lui qu'une fois que c'est devenu une routine, avec un petit serveur SSH dans l'initramfs pour recevoir la phrase de passe au démarrage.
4. Notez l'empreinte de la clé d'hôte de l'initramfs dès le premier déverrouillage, et vérifiez-la à chaque fois par la suite. Ce n'est pas la même clé que présente le système une fois démarré, et traiter un changement comme normal, c'est exactement ainsi qu'une phrase de passe se fait récupérer.
5. Sauvegardez l'en-tête LUKS ailleurs que sur cette machine, puis prouvez que la sauvegarde ouvre le volume au lieu de le supposer.
6. Chiffrez ou désactivez le swap, puis vérifiez ce que vous avez réellement construit : lsblk -o NAME,FSTYPE,MOUNTPOINT montre ce qui se trouve derrière le mapper, et ce qui, discrètement, n'y est pas.
7. Redémarrez-la une fois, délibérément, avant qu'il n'y ait dessus quoi que ce soit qui vous manquerait. Un premier redémarrage sans surveillance à trois heures du matin n'est pas le moment d'apprendre la procédure.

Comment vérifier en dix minutes ce qu'un hébergeur affirme sur son chiffrement

Le même test que partout ailleurs sur cette étagère : chaque question ci-dessous a un document pour réponse, ou n'en a pas.

1. Ce qui est chiffré, est-ce la plateforme, le volume ou la machine invitée — et de laquelle des trois parliez-vous ?
2. Qui génère la clé, où vit-elle, et quelle est la procédure quand un client la perd ? Un chemin de récupération est une seconde clé, et une seconde clé est une seconde chose qu'une ordonnance peut exiger de produire.
3. Pouvez-vous apporter votre propre clé et refuser de la partager ? Si la réponse est oui, demandez ce qui casse. Si rien ne casse, c'est que le chiffrement ne servait à rien.
4. Existe-t-il une console qui fonctionne quand la machine ne démarre plus, et est-elle incluse ou facturée à l'heure ?
5. Que dit le fournisseur ne plus pouvoir faire une fois que vous avez chiffré ? Un hébergeur qui prétend offrir à la fois une confidentialité parfaite et un support complet n'a pas réfléchi à la question, ou décrit une clé qu'il détient.

Le dernier est le signe qui ne trompe pas. Toute réponse honnête dans ce domaine coûte quelque chose au fournisseur, et une affirmation qui ne coûte rien décrit un produit, pas une garantie. Ce que ce parc fera et ne fera pas est exposé dans le guide à l'usage des autorités et comptabilisé dans le rapport de transparence.

Questions réellement posées

Chaque prix de ce parc de serveurs est publié intégralement, à un seul endroit. Voir le catalogue complet