« Est-ce que vous chiffrez les données au repos ? » C’est sans doute la question de sécurité qu’on nous pose le plus, souvent présentée comme une case à cocher dans un appel d’offres. La réponse honnête n’est ni « oui » ni « non » : c’est « contre quelle menace ? ».
Parce que derrière l’expression rassurante « chiffrement au repos » se cache un malentendu tenace. Beaucoup l’imaginent comme un coffre-fort qui protégerait les données en permanence. En réalité, sur un serveur en production, les données ne sont presque jamais « au repos ». Ce guide remet les pendules à l’heure, sans balayer le sujet d’un revers de main : le chiffrement au repos a une vraie utilité, mais pas celle qu’on croit.
Faits clés
- Ce que le chiffrement au repos protège : le vol physique d’un disque, sa panne et son retour SAV, sa mise au rebut.
- Ce qu’il ne protège PAS : un serveur en marche compromis, un accès applicatif volé, un ransomware, les données en transit.
- Le piège : quand un système tourne, il déchiffre à la volée, et la clé vit en mémoire (RAM).
- Sur une VM : chiffrer un disque dont la clé est sur la même machine, qui se déverrouille seule au démarrage, n’apporte presque rien.
- Ce qui compte vraiment pour des données sensibles : le chiffrement applicatif dont vous détenez la clé, et le chiffrement en transit.
« Au repos » : une expression trompeuse
Le chiffrement au repos (encryption at rest) désigne le chiffrement des données quand elles sont stockées, par opposition au chiffrement en transit (quand elles circulent sur le réseau). L’image du « repos » suggère des données endormies, protégées.
Sauf qu’un serveur d’hébergement tourne 24 heures sur 24. Votre base de données répond à des requêtes en continu, vos fichiers sont lus et écrits en permanence. Pour que tout cela fonctionne, le système doit pouvoir lire les données : il les déchiffre à la volée, en temps réel, et la clé de déchiffrement est chargée en mémoire vive. Tant que la machine est allumée, les données sont, de fait, en clair pour qui contrôle le système.
Sur un serveur en production, les données ne dorment jamais. Le chiffrement « au repos » ne protège donc que les moments où le disque est réellement au repos : éteint, débranché, ou sorti de la machine.
Ce que le chiffrement au repos protège vraiment
Attention : dire que c’est mal compris ne veut pas dire que c’est inutile. Le chiffrement au repos a un rôle précis et légitime — protéger les données quand le support physique échappe au contrôle :
Un disque (ou un serveur) dérobé dans un datacenter. Sans la clé, son contenu est illisible. C’est le scénario type pour lequel le chiffrement au repos a été conçu.
Un disque tombe en panne et part en garantie chez le fabricant. S’il était chiffré, les données résiduelles restent inexploitables par un tiers.
En fin de vie, détruire la clé suffit à rendre le disque définitivement illisible : un effacement cryptographique, plus rapide et plus sûr qu’un écrasement.
Pour ces cas, le chiffrement au repos est pertinent, et il peut aussi cocher une exigence de conformité. Mais remarquez le point commun : dans tous ces scénarios, le disque est hors tension ou hors de la machine. Jamais en production.
Ce qu’il ne protège pas (et c’est là que ça se joue)
La plupart des incidents réels ne sont pas des vols de disque. Ce sont des intrusions sur des systèmes allumés. Et là, le chiffrement au repos ne sert à rien :
- Un serveur compromis : l’attaquant qui obtient un accès sur la machine en marche voit les données déchiffrées, exactement comme le système légitime.
- Un identifiant ou une clé applicative volée : l’application sert les données en clair à qui présente les bons accès.
- Un ransomware : il chiffre vos données par-dessus les vôtres ; votre propre chiffrement au repos n’y change rien.
- Les données en transit : le chiffrement au repos ne protège pas ce qui circule sur le réseau. C’est le rôle du chiffrement en transit (TLS).
Autrement dit : la menace la plus probable (l’intrusion sur un système actif) est justement celle que le chiffrement au repos ne couvre pas.
Le piège particulier de la machine virtuelle
Datacampus ne fait que du serveur virtuel (des VM), pas de la mise à disposition de disques physiques individuels. Ce détail change tout :
D’abord, vous ne touchez jamais le disque physique : votre VM voit un disque virtuel, abstrait du matériel. Chiffrer ce disque virtuel depuis l’intérieur de la VM, avec une clé stockée sur cette même VM et un déverrouillage automatique au démarrage, revient à poser la clé sous le paillasson : elle est là, à côté de la serrure. Un serveur qui doit redémarrer seul à 3 heures du matin sans personne pour saisir une phrase de passe… a forcément sa clé à portée.
Ensuite, dans toute virtualisation, l’hyperviseur a techniquement accès aux ressources de la VM (dont sa mémoire). Le chiffrement intra-VM ne vous protège donc pas de l’hébergeur : ce qui vous protège de l’hébergeur, c’est le choix d’un hébergeur de confiance, soumis au droit français, et le chiffrement applicatif dont vous gardez seul la clé.
La vraie question : contre quelle menace ?
Plutôt que « est-ce chiffré au repos », la bonne question est « de quoi je veux me protéger ». À chaque menace, sa parade :
| Menace | Parade efficace | Chiffrement au repos ? |
|---|---|---|
| Vol / rebut d’un disque physique | Chiffrement au repos, sécurité physique du datacenter | Utile |
| Interception sur le réseau | Chiffrement en transit (TLS) | Hors sujet |
| Intrusion sur un serveur en marche | Durcissement, MFA, supervision, moindre privilège | Inopérant |
| Ransomware | Sauvegardes immuables, hors ligne | Inopérant |
| Accès illégitime aux données sensibles | Chiffrement applicatif / bout-en-bout à clé client | Insuffisant seul |
Ce qui protège réellement vos données sensibles
Si vos données sont vraiment sensibles, le chiffrement qui change la donne est celui dont vous — et vous seul — détenez la clé :
Les données sont chiffrées avant d’arriver sur le serveur, avec une clé que vous gardez. Même l’hébergeur ne peut pas les lire. C’est le modèle d’outils comme le chiffrement côté client de Nextcloud ou de coffres type Cryptomator.
Indispensable et systématique : il protège vos données pendant qu’elles circulent entre vos utilisateurs et le serveur. C’est la base, non négociable.
MFA, moindre privilège, cloisonnement : contre l’intrusion sur un système actif, c’est ce qui compte, pas le chiffrement du disque.
Contre le ransomware, la seule défense qui tient : des sauvegardes qu’on ne peut ni modifier ni supprimer, isolées du système de production.
La position de Datacampus, sans bullshit
On ne vend pas de poudre de perlimpinpin « chiffrement au repos » pour cocher une case et vous faire dormir tranquille à tort. Notre approche :
- Le chiffrement en transit (TLS) est systématique sur nos services.
- La protection contre le vol physique repose d’abord sur la sécurité d’accès de notre datacenter Cassin1 et sur notre stockage distribué en objet (voir plus bas), en France, sous seul droit français — pas sur un argument marketing.
- Pour vos données vraiment sensibles, on vous oriente vers le chiffrement applicatif à clé client (vous seul détenez la clé), le seul qui vous protège même de votre hébergeur.
- Et on vous dit la vérité sur le modèle de menace, plutôt que de vous vendre une illusion de coffre-fort.
Il y a aussi un point d’architecture qu’on aime rappeler. Chez Datacampus, tout le stockage est en objet, réparti sur de grands clusters Ceph. Une donnée n’est jamais posée telle quelle sur un disque : elle est découpée en multiples objets, dispersés sur des dizaines de disques de plusieurs machines, selon l’algorithme de répartition CRUSH. Conséquence concrète : voler un disque, ou même plusieurs, ne sert à rien. Sans la carte de répartition (la CRUSH map), les métadonnées du cluster et l’ensemble des autres disques, on ne récupère que des fragments éparpillés, inexploitables. Le scénario classique du « disque volé qu’on relit sur un autre ordinateur » ne s’applique tout simplement pas à notre architecture.
C’est dans la continuité de notre conviction sur la souveraineté des données : ce qui compte, ce n’est pas un label rassurant, c’est qui peut techniquement et juridiquement accéder à vos données.
TL;DR, ce qu’il faut retenir
- « Au repos » est trompeur : un serveur 24/7 déchiffre en continu, clé en mémoire.
- Le chiffrement au repos protège le vol physique, la panne SAV et la mise au rebut d’un disque.
- Il ne protège pas un serveur compromis, un accès volé, un ransomware, ni les données en transit.
- Sur une VM, chiffrer en interne avec clé locale et déverrouillage auto n’apporte presque rien.
- La bonne question : contre quelle menace ? À chaque menace sa parade.
- Pour des données sensibles : chiffrement applicatif à clé client + TLS + contrôle d’accès + sauvegardes immuables.
Vous avez une exigence de chiffrement dans un cahier des charges et vous voulez savoir ce qui a vraiment du sens pour votre cas ? Parlez-en avec notre équipe : on vous dira ce qui protège réellement, et ce qui ne sert qu’à rassurer.
FAQ — Chiffrement des données au repos
Qu’est-ce que le chiffrement des données au repos ?
C’est le chiffrement des données lorsqu’elles sont stockées sur un support (disque), par opposition au chiffrement en transit (sur le réseau) et au chiffrement applicatif. Il vise à rendre les données illisibles quand le support physique échappe au contrôle : vol, panne, mise au rebut.
Le chiffrement au repos protège-t-il un serveur piraté ?
Non. Quand le serveur est allumé, il déchiffre les données à la volée et la clé est en mémoire. Un attaquant qui prend le contrôle du système en marche voit les données en clair, comme le système légitime. Le chiffrement au repos ne protège que le disque hors tension ou sorti de la machine.
Faut-il chiffrer le disque d’une machine virtuelle ?
Chiffrer le disque depuis l’intérieur d’une VM, avec une clé stockée sur cette même VM et un déverrouillage automatique au démarrage, n’apporte presque rien : la clé est juste à côté de la serrure. Et l’hyperviseur a de toute façon accès aux ressources de la VM. Pour se protéger réellement, il faut du chiffrement applicatif à clé client.
Quelle différence entre chiffrement au repos, en transit et de bout en bout ?
Le chiffrement au repos protège les données stockées ; le chiffrement en transit (TLS) protège les données qui circulent sur le réseau ; le chiffrement de bout en bout (ou applicatif à clé client) chiffre les données avant qu’elles n’atteignent le serveur, si bien que même l’hébergeur ne peut pas les lire. C’est ce dernier qui offre la meilleure protection pour les données sensibles.
Le RGPD impose-t-il le chiffrement au repos ?
Le RGPD (article 32) cite le chiffrement parmi les mesures techniques « appropriées » pour sécuriser les données, mais ne l’impose pas nommément ni dans une forme précise. Ce qui est exigé, c’est une sécurité adaptée au risque : le chiffrement au repos peut y contribuer, mais ne suffit pas à lui seul à démontrer la conformité.
Comment protéger réellement des données sensibles chez un hébergeur ?
En combinant : chiffrement applicatif ou de bout en bout dont vous détenez seul la clé, chiffrement en transit (TLS) systématique, contrôle d’accès strict (MFA, moindre privilège), sauvegardes immuables contre le ransomware, et le choix d’un hébergeur de confiance soumis au seul droit français.
Le vol d’un disque chez Datacampus permet-il de lire mes données ?
Non. Chez Datacampus, tout le stockage est en objet sur de grands clusters Ceph : chaque donnée est découpée en multiples fragments dispersés sur des dizaines de disques de plusieurs machines, selon l’algorithme CRUSH. Un ou plusieurs disques volés, sans la carte de répartition (CRUSH map), les métadonnées du cluster et l’ensemble des autres disques, ne contiennent que des fragments éparpillés et inexploitables.
Pour aller plus loin :
• CNIL — Chiffrement, hachage, signature
• ANSSI — Recommandations relatives à TLS (chiffrement en transit)
• Sur datacampus.fr : CLOUD Act vs RGPD · Héberger ses données en France · Nextcloud infogéré · Le datacenter Cassin1