Chiffrement et données sensibles
AvancéLa protection se joue à plusieurs niveaux : en transit, au repos, et dans les colonnes elles-mêmes.
En transit#
# postgresql.conf
ssl = on
# pg_hba.conf : hostssl impose TLS
hostssl all app_api 10.0.0.0/16 scram-sha-256
Côté client, exigez sslmode=verify-full : il vérifie le certificat et le nom d'hôte.
Au repos#
- Chiffrement du disque/volume (LUKS, chiffrement des services managés) : protège contre le vol de disque, pas contre un accès applicatif.
- PostgreSQL ne fournit pas de chiffrement transparent natif de la base : c'est le rôle de l'infrastructure.
Au niveau des colonnes#
| Donnée | Approche |
|---|---|
| Mots de passe | Jamais en clair : hachage lent (argon2id, bcrypt, scrypt) côté application |
| Jetons d'API, secrets tiers | Chiffrés par l'application avec une clé du gestionnaire de secrets (KMS) |
| Données personnelles sensibles | Minimiser, chiffrer, journaliser les accès ; prévoir suppression/anonymisation (RGPD) |
Piège :
pgcryptochiffre dans la base, mais la clé transite alors par les requêtes (et donc par les logs etpg_stat_statements). Pour les données réellement sensibles, chiffrez côté application.
Audit#
Activez log_connections, log_disconnections et, selon le besoin, l'extension pgaudit pour tracer qui a accédé ou modifié quoi. Ne journalisez pas les valeurs sensibles des requêtes.
Astuce : appliquez le principe de minimisation : la donnée qu'on ne stocke pas ne peut pas fuiter. Une liste de ce que la base contient (données personnelles, secrets, données de paiement) est le point de départ de toute analyse de risque.