HTTPS protège-t-il les données stockées en base (données au repos) ?
Réponse courte
Non. TLS/HTTPS sécurise les données en transit entre client et serveur ; une fois reçues, elles sont déchiffrées et traitées en clair par l'application, puis stockées selon la configuration de la base. Protéger les données au repos est un sujet distinct — chiffrement de disque/colonne, un KMS et le contrôle d'accès. Confondre « on utilise HTTPS » avec « nos données stockées sont chiffrées » est une idée fausse courante et dangereuse.
« On est chiffrés — on utilise HTTPS » est l'une des demi-vérités les plus répandues en sécurité. HTTPS est essentiel, mais il résout exactement un problème, et les données stockées n'en font pas partie.
Ce que HTTPS/TLS protège réellement
TLS établit un canal chiffré entre deux extrémités — généralement un navigateur et un serveur web. Il fournit confidentialité et intégrité des données en transit, plus l'authentification du serveur via des certificats. Pendant que les octets traversent le réseau, un attaquant sur le câble (Wi-Fi public, proxy malveillant, FAI) ne voit que du chiffré. C'est tout son rôle : protéger la conversation entre client et serveur.
Où s'arrête la protection
TLS est terminé au serveur (ou sur un répartiteur de charge / reverse proxy en amont). À cette frontière, la clé de session déchiffre la requête en clair, et l'application la traite en clair : parsing JSON, logique métier, construction de SQL. Quand l'application écrit en base, ce qui atterrit sur le disque dépend entièrement de la configuration du stockage — par défaut, en clair. La clé de session TLS n'atteint jamais le disque ; elle était éphémère et disparaît à la fermeture de la connexion.
Les données au repos sont un contrôle distinct
Protéger les données stockées exige ses propres mécanismes :
- Chiffrement de disque ou de volume (LUKS, BitLocker) contre le vol de disques.
- Transparent Data Encryption (TDE) ou chiffrement de colonne/champ dans la base.
- Un service de gestion de clés (KMS) ou un HSM pour que les clés ne soient pas à côté des données.
- Contrôle d'accès et moindre privilège pour que seuls les bons acteurs lisent les lignes.
Ils défendent contre des menaces différentes de TLS : une sauvegarde volée, un compte DBA compromis, un attaquant qui a déjà un shell sur la machine.
Pourquoi l'idée fausse est dangereuse
Les réponses séduisantes mais fausses imaginent que la clé TLS « suit » les données jusqu'au disque, ou que le certificat continue de les protéger au repos. Il n'en est rien — TLS est point à point et éphémère. Les équipes qui confondent sécurité de transport et sécurité de stockage sautent entièrement le chiffrement au repos, puis divulguent des bases en clair. Le bon modèle mental : HTTPS protège le trajet ; le chiffrement au repos protège la destination. Il faut les deux.
Questions de suivi probables
- Quelles technologies protègent réellement les données au repos, et où vit la clé ?
- À quel moment du cycle de vie de la requête le déchiffrement TLS a-t-il lieu ?
- En quoi le chiffrement de bout en bout diffère-t-il du chiffrement de transport comme HTTPS ?