Le chiffrement de disque sur une machine qui ne vous appartient pas

Tout hébergeur qui vend de la confidentialité affirme que ses disques sont chiffrés. C’est généralement vrai, et cela répond généralement à une question que personne n’a posée. Le chiffrement doit composer avec trois états, et un serveur passe toute sa vie active dans celui que le chiffrement intégral du disque ne couvre pas. Voici où passe réellement la limite, ce qui se trouve de chaque côté, et laquelle des deux formules vendues sous les mêmes quatre mots vous laisse effectivement la clé.

Trois états, et celui que personne ne chiffre

On décrit une donnée comme se trouvant dans l’un de trois états, et le secteur a réglé les deux premiers de façon convaincante. Les données au repos reposent sur un disque que rien ne lit actuellement : le chiffrement intégral du disque règle le problème, tout comme le chiffrement de base de données ou de stockage objet qui vient s’y ajouter. Les données en transit traversent un réseau : TLS règle le problème, et si bien qu’un certificat mal délivré fait désormais l’actualité. Les données en cours d’utilisation sont chargées dans la mémoire d’un processus en cours d’exécution — c’est là que chaque octet servi par votre serveur doit se trouver, même brièvement, pour pouvoir être servi.

L’expression chiffrement au repos est exacte, et elle l’est d’une manière qu’il est facile de lire sans y prêter attention. Elle décrit l’état de vos données pendant que la machine est éteinte. Or un serveur est une machine dont tout le métier consiste précisément à ne pas être éteinte. Pendant les mois qu’il passe en fonctionnement, ses volumes sont ouverts, ses fichiers de base de données sont lisibles par tout processus tournant sous le bon utilisateur, et le chiffrement ne fait rien d’autre qu’attendre une coupure de courant.

La seconde chose que ces quatre mots dissimulent, c’est à qui appartient la clé. Deux formules totalement différentes se cachent derrière eux. Un hébergeur peut chiffrer la couche de stockage avec des clés qu’il gère lui-même : cela protège son propre processus de mise au rebut et réduit son exposition en cas de violation, et cela vous protège bel et bien contre un disque qui quitterait le bâtiment — mais la partie qui détient la clé est justement celle sur laquelle portait votre question. Ou bien le volume peut être chiffré à l’intérieur de votre propre machine, avec une clé qui n’existe nulle part ailleurs que dans votre tête et dans la mémoire d’un noyau en cours d’exécution. Seule la seconde formule change ce qu’un tiers est capable d’obtenir, et c’est elle seule dont il est question dans le reste de ce guide.

Rien de tout cela ne plaide contre le chiffrement des disques. Cela plaide pour savoir lequel des huit scénarios ci-dessous vous couvrez, et lequel vous ne couvrez pas. Un chiffrement qui arrête une seule chose réelle vaut la peine d’exister ; un chiffrement dont vous croyez qu’il en arrête huit est pire que rien, parce que cette croyance met fin à la conversation.

Où vit la clé pendant que la machine tourne

Quand vous déverrouillez un volume LUKS, la phrase de passe que vous tapez n’est pas la clé. Elle déballe une clé maîtresse stockée dans l’en-tête du volume, et cette clé maîtresse est ensuite conservée en mémoire du noyau jusqu’à la fermeture du volume ou la coupure d’alimentation de la machine. Chaque lecture et chaque écriture y passe. Il n’existe aucune configuration d’un disque chiffré fonctionnel dans laquelle la clé se trouverait ailleurs pendant que le disque est utilisé — ce n’est pas un détail d’implémentation que l’on pourrait corriger, c’est ce que signifie utiliser un disque chiffré.

Sur du matériel vous appartenant, cette mémoire se trouve dans un boîtier, dans une pièce que vous contrôlez, et l’attaque qui la vise est exotique : présence physique, et les quelques secondes de rémanence que gardent les puces mémoire après la coupure du courant. Sur un serveur virtuel, la situation diffère en nature, pas seulement en degré. La mémoire de votre noyau est une région de la mémoire de l’hôte. L’hyperviseur peut y accéder par définition, puisque c’est précisément en y accédant qu’il vous l’a attribuée au départ. Trois opérations parfaitement ordinaires la lisent :

• Une migration à chaud. Déplacer une machine virtuelle en fonctionnement d’un hôte physique à un autre copie sa mémoire pendant qu’elle tourne. C’est une fonctionnalité — c’est ainsi qu’un hôte se fait maintenir sans vous redémarrer — et votre clé maîtresse se trouve dans les pages copiées.
• Un snapshot qui inclut la mémoire. Un snapshot du disque seul, d’un volume que vous avez chiffré vous-même, ne contient que du texte chiffré et rien d’autre. Un snapshot qui permet à la machine de reprendre exactement là où elle en était contient la clé, parce que la clé fait partie de ce qui constitue « exactement là où elle en était ».
• Un dump mémoire. La mémoire de votre machine invitée vit dans l’espace d’adressage d’un processus sur l’hôte. Lire la mémoire de ce processus est une opération de débogage courante, et l’outillage est livré avec la pile de virtualisation plutôt que de devoir être introduit en douce.

Rien de tout cela n’affirme que votre hébergeur fait quoi que ce soit de tout ça. Cela affirme que ces opérations ne demandent aucune coopération de votre part, ne laissent aucune trace visible, et sont indiscernables d’une maintenance ordinaire de la plateforme. C’est la seule propriété qui mérite de figurer dans un modèle de menace : non pas ce que quelqu’un fait, mais ce qu’il est capable de faire sans que vous le sachiez. Le même raisonnement, une couche plus loin, explique pourquoi le registre et le proxy placés devant vous appartiennent à la même liste que l’hôte.

Le problème du redémarrage, et le raccourci qui l’annule

Un volume racine chiffré doit être déverrouillé avant que le système ne démarre assez loin pour accepter une connexion SSH. Sur un ordinateur portable, vous tapez la phrase de passe au clavier. Sur une machine à deux mille kilomètres, dans un bâtiment où vous n’avez jamais mis les pieds, aucun clavier n’est à votre portée au moment où il le faudrait. Chaque réponse pratique à cela est un compromis — et l’une des quatre solutions ci-dessous n’en est pas un, mais donne seulement l’apparence d’en avoir fait un.

Quatre façons de déverrouiller un volume racine chiffré sur une machine distante

Méthode	Redémarrage sans surveillance	Arrête un disque volé	Ce que cela vous coûte
SSH dans l’image de démarrage	Non	Oui	Un serveur SSH minimal à l’intérieur de l’initramfs vous permet de vous connecter et de taper la phrase de passe. La machine reste éteinte jusqu’à ce qu’un humain soit éveillé et joignable. C’est l’option honnête, et son coût est bien réel : un redémarrage à quatre heures du matin est une panne jusqu’à ce que quelqu’un s’en aperçoive.
Clé liée au réseau	Oui	Partiellement	La machine récupère sa clé de déverrouillage au démarrage auprès d’un serveur que vous faites tourner ailleurs, et vous pouvez refuser de servir une clé à une machine qui a bougé ou que vous n’avez pas redémarrée vous-même. Le serveur de clés doit rester disponible, et il doit se trouver quelque part hors de portée de la même réquisition — sinon vous avez réparti la clé entre deux portes qui n’ont qu’une seule serrure.
Fichier de clé dans l’image de démarrage	Oui	Non	La clé se trouve dans l’initramfs, l’initramfs se trouve sur une partition de démarrage non chiffrée, et cette partition se trouve sur le disque que vous étiez censé protéger. Quiconque prend le disque prend la clé avec. Cette configuration est courante, elle démarre à merveille, et elle ne défend absolument contre rien.
Scellée dans un TPM	Oui	Partiellement	Sur du matériel vous appartenant, une véritable puce de sécurité ne libère la clé qu’à une chaîne de démarrage restée intacte. Sur un serveur virtuel, cette puce est émulée par l’hôte, si bien que sceller une clé dedans revient à la remettre précisément à la partie contre laquelle vous cherchiez à la protéger.

La troisième ligne mérite qu’on s’y attarde. C’est là que l’on aboutit quand l’exigence a été formulée comme les disques doivent être chiffrés, sans que personne ne demande pourquoi. L’audit passe. Le périphérique bloc est bel et bien chiffré. La clé voyage sur le même bout de métal, dans un fichier qu’un shell de secours lira en environ quatre secondes.

C’est aussi la différence pratique la plus nette entre une machine virtuelle louée et une machine qui vous appartient. Sur du matériel dédié, l’interface de gestion hors bande vous donne une console qui survit à un redémarrage, si bien que la première ligne cesse d’être une panne pour devenir une interruption de deux minutes — et le problème de la puce émulée de la quatrième ligne disparaît, puisque la puce est soudée sur une carte plutôt qu’écrite en logiciel par la partie même contre laquelle vous vous protégez.

Ce que le chiffrement intégral du disque achète réellement

La même question, posée de huit façons. La colonne qui compte est la dernière, parce que dans chaque ligne où le chiffrement n’aide pas, autre chose aide — et nommer cette autre chose est tout l’intérêt de l’exercice.

Huit scénarios, et si le chiffrement intégral du disque change l’issue

Scénario	Le chiffrement aide	Ce qui décide réellement
Un disque est retiré du service, revendu ou renvoyé sous garantie	Oui	Rien d’autre ne couvre ce cas. Les disques quittent les data centers en permanence, l’effacement sécurisé est un processus, et les processus échouent en silence. C’est le scénario pour lequel le chiffrement intégral du disque a été inventé, et contre lui, il fonctionne exactement comme promis.
La machine est éteinte et le disque retiré	Oui	La même protection, avec la même limite, et cette limite tient dans le mot éteinte. Une machine prise pendant qu’elle tourne est une machine prise déverrouillée, ses volumes ouverts et sa clé résidente.
Une copie de sauvegarde se trouve ailleurs	Partiellement	Le chiffrement du volume source ne fait rien pour une copie des données. Ce qui décide, c’est si la sauvegarde a été chiffrée avant de partir, avec une clé qui n’est pas stockée sur la machine sauvegardée.
La plateforme prend un snapshot	Partiellement	Un snapshot du disque seul, d’un volume que vous avez chiffré vous-même, n’est que du texte chiffré, inutilisable sans votre phrase de passe. Un snapshot qui capture l’état de la mémoire capture la clé avec. Les deux s’appellent pourtant « snapshot ».
Quelqu’un obtient un shell sur la machine en fonctionnement	Non	Le volume est déjà ouvert, et un intrus lit des fichiers plutôt que des blocs. Les correctifs, le moindre privilège et des identifiants non réutilisés d’un service à l’autre décident de cette ligne, et le chiffrement n’y contribue en rien.
L’opérateur de l’hôte, ou quiconque détient ses accès	Non	Seul un chiffrement dont la clé n’entre jamais du tout dans la machine. Le chiffrement matériel de la mémoire est la seule exception, et il est désactivé par défaut partout, ce qui est traité dans la section suivante.
Une réquisition est signifiée à l’hébergeur	Partiellement	La juridiction décide qui peut demander et sur quelle base ; le chiffrement décide ce qu’une réponse pourrait contenir. Notre position publiée tient en deux phrases distinctes, et toutes deux comptent : nous ne détenons pas les clés de chiffrement de nos clients et ne pouvons pas les produire, et un volume non chiffré sur un serveur virtuel exige toujours une réquisition nommant ce service précis.
Vous devez déclarer une violation de données	Partiellement	Si vos utilisateurs sont dans l’UE, l’article 32 du RGPD cite nommément le chiffrement parmi les mesures attendues de vous, et l’article 34 lève l’obligation de notifier les personnes concernées — jamais l’autorité de contrôle — lorsque les données ont été rendues inintelligibles. Que cela s’applique dépend entièrement de l’endroit où se trouvait la clé au moment où les données sont sorties.

Au-dessus du disque : ce qui survit à un hôte hostile

Tout ce qui précède concerne une couche qui s’arrête au périphérique bloc. Trois éléments se trouvent au-dessus, et à eux trois, ils constituent les seules réponses aux cinquième, sixième et septième lignes de ce tableau.

Chiffrer au-dessus de l’application, pas en dessous

Le chiffrement au niveau du champ signifie que l’application chiffre une valeur avant qu’elle n’atteigne la base de données, et la déchiffre après l’avoir relue. Un dump de la base ne rend que du texte chiffré, quel que soit celui qui l’a pris et par quel chemin. Cela vous coûte la possibilité de rechercher ou d’indexer les colonnes chiffrées, ce qui explique pourquoi cela ne concerne que les quelques champs qui le méritent — corps de messages, documents déposés, jetons tiers — et non l’ensemble. Le bout de cette route, c’est le chiffrement de bout en bout : la clé appartient à l’utilisateur, le serveur ne détient jamais de texte en clair, et un hôte hostile n’obtient rien parce qu’il n’y a rien à obtenir. C’est la seule architecture de cette page réellement indifférente à qui fait tourner le métal, et c’est une décision produit bien avant d’être une décision d’infrastructure.

Les sauvegardes sont une décision à part, pas une conséquence

La façon la plus courante dont des données quittent une machine chiffrée, c’est une sauvegarde. Un snapshot poussé vers du stockage objet, un dump de base synchronisé vers un second hébergeur, une archive rapatriée sur un poste de travail — aucun n’hérite quoi que ce soit du volume dont il provient. Chiffrez au moment même où la donnée est écrite dans la sauvegarde, avec une clé conservée quelque part que la machine elle-même ne peut pas atteindre, afin qu’un serveur compromis ne puisse pas déchiffrer sa propre histoire. Restaurez-en ensuite une, sur une machine différente, avant d’en avoir besoin : une sauvegarde chiffrée que vous ne pouvez pas ouvrir est une manière étonnamment nette de tout perdre d’un coup. Une copie dans un autre pays est aussi une copie soumise à un autre corpus de règles, soit une seconde juridiction que vous avez choisie sans vous en rendre compte.

Le chiffrement de la mémoire, et pourquoi vous ne l’avez probablement pas

L’état que personne ne chiffre a bel et bien une réponse matérielle. Les extensions d’informatique confidentielle — SEV-SNP chez AMD, TDX chez Intel — chiffrent la mémoire et l’état des registres de la machine invitée sous une clé détenue par un processeur de sécurité séparé plutôt que par l’hyperviseur, si bien qu’un hôte qui fait un dump de la mémoire ne récupère que du texte chiffré. C’est réel, et c’est disponible. C’est aussi étroit : SEV-SNP exige du silicium EPYC de troisième génération ou plus récent, l’hôte doit être configuré pour cela délibérément, et l’invité doit attester qu’il en dispose. Presque aucun serveur virtuel généraliste ne le propose, et aucun ne le propose en silence. Partez du principe que vous ne l’avez pas, sauf si un hébergeur vous le confirme par écrit et sait vous expliquer comment vérifier vous-même l’attestation.

Une configuration honnête sur ses limites

Rien de tout cela ne débouche sur ne vous embêtez pas. Cela débouche sur une configuration dont vous pouvez énoncer les limites à voix haute sans ciller.

1. Notez le scénario unique contre lequel vous vous défendez (5 min). Un disque retiré du service, une machine saisie pendant qu’elle tourne, un hôte hostile, une réquisition judiciaire, une violation à déclarer. Ils appellent des réponses différentes, et une configuration visant les cinq à la fois n’en atteint fiablement aucun.
2. Placez le chiffrement là où se trouve votre clé (décision). Si l’hébergeur détient la clé, vous avez acheté une protection contre un disque qui quitte le bâtiment, et rien de plus. Si vous voulez davantage, le volume doit être déverrouillé depuis l’intérieur de la machine invitée, par vous, avec quelque chose que la plateforme ne voit jamais.
3. Chiffrez le volume de données plutôt que la racine (mise en place). Une racine chiffrée signifie que chaque redémarrage vous attend. Un volume chiffré séparé, contenant le répertoire de la base de données, les fichiers déposés et les secrets, laisse la machine revenir toute seule pendant que la partie sensible reste fermée jusqu’à ce que vous l’ouvriez. C’est le compromis que la plupart des petites plateformes devraient adopter, et presque personne ne l’écrit noir sur blanc.
4. Ne laissez jamais le fichier de clé sur la partition de démarrage non chiffrée (règle). Si la machine démarre sans surveillance, sans serveur de clés ni console, la clé se trouve sur le disque ; il n’existe pas de troisième possibilité. C’est un compromis acceptable quand un disque volé est véritablement tout votre modèle de menace, et de l’aveuglement volontaire dans tous les autres cas.
5. Chiffrez les sauvegardes au moment de leur écriture, avec une clé conservée ailleurs (mise en place). Restaurez-en ensuite une sur une machine différente, un jour où rien n’est en feu.
6. Dites ce que vous couvrez, en une phrase (5 min). Quelque chose comme : un attaquant qui retire ce disque de la baie n’obtient rien, et quiconque a un accès root sur la machine en fonctionnement ou sur son hôte obtient tout. Si cette phrase est inconfortable à écrire, c’est parce qu’elle est vraie.

Deux de ces six points sont des décisions, quatre sont de la mise en place. Les décisions prennent un après-midi et la mise en place prend une heure, et cette heure ne vaut rien sans l’après-midi. Faire les choses dans l’autre ordre, c’est comme cela qu’on finit dans la troisième ligne du premier tableau, avec une machine qui passe l’audit et ne protège de personne.

Savoir contre quel scénario vous vous défendez est une question de modélisation des menaces avant d’être une question de chiffrement, et la version en une heure de cet exercice produit la phrase de l’étape six presque comme sous-produit. Si la réponse s’avère être une réquisition judiciaire plutôt qu’un disque, la couche qui décide de l’issue ne se trouve pas du tout sur votre disque — c’est la question de savoir quel droit atteint votre hébergeur, et comment le vérifier avant de lui faire confiance.

Rédigé par les ingénieurs qui exploitent la plateforme, et relu aujourd’hui. Si quelque chose ici est faux ou obsolète, dites-le depuis le panel — c’est de là que vient environ la moitié de ces pages.