Le chiffrement au repos : contre quoi il protège et contre quoi il ne protège pas

Ce que c'est

« Chiffrement au repos » désigne plusieurs niveaux distincts. La documentation de PostgreSQL cite ces options pour un serveur de base de données : le chiffrement de la partition de données au niveau du bloc ou du système de fichiers (sous Linux, typiquement dm-crypt avec LUKS, géré par cryptsetup), le chiffrement de colonnes spécifiques avec pgcrypto, où le client fournit la clé et le serveur déchiffre, et le chiffrement côté client, où le serveur ne voit jamais les données en clair. Les plateformes cloud ajoutent un chiffrement de volume géré par le fournisseur, avec des clés stockées dans un service de gestion de clés. La documentation énonce clairement la limite du chiffrement de partition : il empêche la lecture des données non chiffrées à partir des disques si ceux-ci ou l'ordinateur sont volés, mais il ne protège pas contre des attaques pendant que le système de fichiers est monté, car le système d'exploitation fournit alors une vue non chiffrée des données ; et pour monter le volume, la clé doit être communiquée à l'hôte, ce qui signifie parfois qu'elle y est stockée.

Pourquoi c'est important

Les questionnaires demandent « les données sont-elles chiffrées au repos ? », et une réponse positive est souvent interprétée comme une protection contre les violations de données. Une attaque qui passe par l'application ou par ses identifiants touche un système en fonctionnement, où le chiffrement de volume est transparent. Savoir quel niveau arrête quelle menace évite à la fois un faux sentiment de sécurité et une complexité inutile.

Comment l'appliquer

• Menace : disques volés ou mis hors service, supports de sauvegarde perdus, instantanés copiés vers le mauvais compte. Contrôle : chiffrement intégral du volume, sauvegardes chiffrées, et une clé stockée ailleurs que sur le disque chiffré.
• Menace : un administrateur de base de données ou un intrus sur l'hôte lisant certains champs sensibles. Contrôle : chiffrement de colonnes avec des clés détenues par l'application, en acceptant que le texte en clair et la clé soient brièvement présents sur le serveur (modèle pgcrypto), ou chiffrement côté client, qui renonce à la recherche et à l'indexation côté serveur sur ces champs.
• Clés : l'aide-mémoire OWASP sur le stockage cryptographique recommande de stocker les clés séparément des données, d'envelopper la clé de chiffrement des données (DEK) avec une clé de chiffrement de clé (KEK) conservée ailleurs, et de conserver les clés retirées aussi longtemps que d'anciennes sauvegardes peuvent en avoir besoin.
• Consigner, pour chaque classe de données, quel niveau la protège contre quoi ; inclure les sauvegardes, les exports et les journaux, qui constituent souvent la copie non chiffrée.

Pièges

Chiffrer une colonne, puis indexer, rechercher ou journaliser son contenu en clair. Perdre la KEK, ce qui équivaut à perdre les données. Considérer le chiffrement géré par le fournisseur, où celui-ci détient la clé, comme une protection contre le fournisseur lui-même ou contre quiconque détient les identifiants du compte. Supposer qu'un volume chiffré rend les exports chiffrés : la sortie de pg_dump, les fichiers CSV exportés et les fichiers journaux sont en clair, sauf s'ils sont chiffrés séparément.

Les clés dans les journaux d'instructions

Une clé transmise à pgcrypto à l'intérieur d'une instruction SQL est écrite partout où le texte de l'instruction est écrit : le journal serveur sous log_statement = 'all' ou log_min_duration_statement, pg_stat_activity.query, les fichiers d'historique client et tout proxy de journalisation. Les paramètres liés sont eux aussi journalisés par défaut depuis PostgreSQL 13, sauf si log_parameter_max_length vaut 0. Le déchiffrement de colonnes côté serveur exige donc que la journalisation des instructions et des paramètres soit désactivée pour le rôle qui fournit les clés, et que l'accès aux journaux soit traité comme un accès aux clés ; si cela ne peut pas être garanti, il faut utiliser le chiffrement côté client, où la clé n'atteint jamais le serveur.