Comment chiffrer ses credentials de base de données en local

Un développeur backend accumule rapidement une dizaine d'identifiants de base de données: PostgreSQL local, MySQL d'intégration, Mongo de staging, Redis sur un bastion, parfois un SQL Server distant via SSH. La tentation est de tout poser à plat dans un fichier de config, un .env, ou directement dans la commande shell qui finit dans l'historique. C'est rapide, c'est lisible, et c'est exactement ce qu'un malware cherche en premier sur une machine compromise.

Le sujet de cet article est concret: comment stocker ces credentials localement sans qu'ils traînent en clair, et quels mécanismes sont fiables. On va passer en revue les fichiers de config classiques, le keychain de l'OS, les gestionnaires de mots de passe en ligne de commande, et les vaults intégrés aux clients de base de données.

Le piège des fichiers de config en clair

Le .pgpass de PostgreSQL, le .my.cnf de MySQL, ou les fichiers .env des projets node ou Python posent tous le même problème: les mots de passe sont en clair sur le disque. La seule protection est la permission de fichier (0600 sur Unix). C'est suffisant contre un autre utilisateur du système, pas contre un processus malveillant qui tourne sous votre propre compte.

Un second risque, plus discret, est la fuite par sauvegarde: dotfiles synchronisés sur un repo Git, snapshots Time Machine, indexation par un outil de recherche desktop. Un mot de passe en clair dans un fichier touché par une de ces routines finit potentiellement ailleurs que sur la machine locale. La règle de base est donc simple: pas de mot de passe en clair dans un fichier persisté, sauf si le fichier lui-même est dans un volume chiffré dédié et exclu de toute synchronisation.

Les variables d'environnement sont une amélioration marginale: elles ne sont pas écrites sur le disque par le shell lui-même, mais elles apparaissent dans /proc/<pid>/environ sous Linux, dans l'inspection des processus sous macOS, et dans le contexte de tout sous-processus. Pour un usage ponctuel en CI c'est acceptable; pour la machine d'un développeur qui ouvre dix shells par jour, c'est insuffisant.

Le keychain de l'OS comme socle

Chaque système d'exploitation expose un service de stockage de secrets natif: Keychain sur macOS, gnome-keyring ou kwallet via libsecret sur Linux, Credential Manager sur Windows. Le principe est commun: les secrets sont chiffrés au repos avec une clé dérivée du mot de passe utilisateur, et l'accès passe par une API qui vérifie l'identité du processus appelant. Sur macOS et Windows, le système peut aussi demander une confirmation interactive (Touch ID, Hello, ou re-saisie du mot de passe).

L'avantage pratique est triple: le secret n'est jamais en clair sur le disque, l'OS gère le chiffrement et le déverrouillage automatique à la session, et un autre utilisateur de la machine ne peut pas le lire. L'inconvénient principal est l'absence de portabilité: un keychain reste lié à une session OS, on ne le synchronise pas entre machines tel quel.

En pratique, on accède au keychain de plusieurs façons. En ligne de commande, security add-generic-password sur macOS, secret-tool store sur Linux, cmdkey /add sur Windows. Depuis du code, la plupart des langages exposent un binding: keyring en Python, keytar en Node, la crate keyring en Rust. Tous abstraient les trois backends derrière une API commune.

Les gestionnaires de mots de passe en CLI

Quand on veut partager des credentials entre plusieurs machines ou avec une équipe, le keychain de l'OS ne suffit plus. Les gestionnaires de mots de passe comme 1Password, Bitwarden ou pass exposent une CLI qui permet de récupérer un secret à la demande dans un script ou un alias shell. Le secret reste chiffré dans le coffre central, et n'est déchiffré que dans le contexte de l'appel.

Le pattern typique est un alias ou une fonction shell qui récupère le mot de passe juste avant de lancer la commande, sans jamais l'exporter dans l'environnement persistant. Avec 1Password CLI, ça donne par exemple un appel op read 'op://Personal/postgres-prod/password' injecté dans la commande au moment de l'exécution. Le secret n'est jamais écrit dans un fichier.

Ce modèle a deux mérites: il centralise les credentials dans un endroit auditable, et il force un déverrouillage explicite via Touch ID, biométrie ou mot de passe maître. Le compromis est une dépendance à un service externe pour accéder à ses bases locales, ce qui n'est pas toujours souhaitable pour une base de dev qui doit rester accessible hors-ligne.

Le vault d'un client de base de données

Les clients desktop modernes prennent en charge le stockage des credentials directement. Deux approches coexistent. La première, utilisée par DBeaver, consiste à chiffrer les connexions enregistrées avec un mot de passe maître. Tout est stocké dans les fichiers de l'application, mais le contenu n'est lisible qu'après déverrouillage. La seconde, retenue par QoreDB et d'autres clients récents, consiste à déléguer le stockage des secrets au keychain de l'OS et à ne garder sur le disque que les métadonnées de connexion (hôte, port, nom d'utilisateur, options TLS).

Le choix entre les deux dépend du contexte. Le mot de passe maître a l'avantage d'être portable: on peut copier les fichiers de config sur une autre machine et le coffre suit. Le keychain de l'OS, lui, n'oblige pas l'utilisateur à retenir un mot de passe supplémentaire, profite de l'intégration biométrique du système, et n'expose jamais les secrets dans un fichier qu'un outil de sauvegarde pourrait aspirer. Pour un usage desktop mono-utilisateur, c'est la voie la plus simple et la plus sûre.

Dans QoreDB, c'est cette seconde approche qui est implémentée. Quand vous sauvegardez une connexion, les métadonnées partent dans un fichier JSON dans le dossier de configuration de l'app, et le mot de passe va dans le keychain via la crate keyring. Le mot de passe SSH, la passphrase d'une clé privée, et le mot de passe d'un proxy suivent le même chemin. Un vault lock optionnel, basé sur Argon2id, ajoute une couche supplémentaire qui force un déverrouillage explicite avant toute lecture de credentials, indépendamment de la session OS.

Un workflow concret

Pour la plupart des développeurs travaillant sur une machine personnelle, la combinaison qui marche bien est la suivante. Les bases locales et les bases de dev cloud passent par le client desktop, qui sauvegarde les credentials dans le keychain. Les bases de production accessibles depuis la CLI passent par un gestionnaire de mots de passe avec un alias shell qui récupère le secret à la volée. Les credentials en CI restent dans le système de secrets de l'orchestrateur, jamais dans le repo.

Quelques règles d'hygiène complètent l'approche. Tourner les mots de passe régulièrement, surtout après le départ d'un membre de l'équipe. Utiliser des comptes distincts par environnement, pour qu'une fuite de credentials dev ne donne pas accès à la prod. Activer le 2FA sur les bases qui le supportent, et préférer les méthodes d'auth basées sur les certificats ou IAM quand c'est possible. Et auditer régulièrement les fichiers du home qui pourraient contenir des secrets oubliés: un grep -r 'password=' ~/ révèle souvent des choses qu'on ne soupçonnait pas.

Conclusion

Chiffrer ses credentials de base de données en local ne demande pas d'outillage complexe. Le keychain de l'OS résout la majorité des cas pour un développeur seul. Un gestionnaire de mots de passe ajoute la dimension équipe et le partage contrôlé. Un client de base de données qui s'appuie sur ces briques, plutôt que de réinventer son propre stockage, hérite naturellement de leurs garanties. L'erreur à éviter reste la même qu'il y a vingt ans: laisser un mot de passe en clair dans un fichier de config et espérer que les permissions Unix feront le travail.