Durcissement des bases de données : PostgreSQL et MySQL en production

Une base de données de production est l'endroit où résident les joyaux de la couronne, ce qui fait du durcissement des bases de données l'une des activités les plus rentables dans lesquelles une équipe défensive puisse investir. PostgreSQL et MySQL sont robustes et, dans leur état par défaut ou configuré à la hâte, exposent plus qu'ils ne le devraient. Ce guide adopte le point de vue de la blue team : il explique la surface d'exposition d'une base de production, comment les attaques contre les entrepôts de données se déroulent à haut niveau et — l'essentiel — les contrôles, la télémétrie et les détections concrets qui gardent les données confidentielles, intègres et disponibles. Le cadrage reste : comprendre pour défendre, pas pour exploiter.

Pourquoi le durcissement des bases de données compte#

Les applications sont corrigées, les pare-feu reçoivent des règles et les terminaux reçoivent de l'EDR, pourtant la base de données se trouve souvent derrière tout cela avec une posture de confiance par défaut. C'est précisément pourquoi elle est ciblée : un seul identifiant faible, un compte applicatif surprivilégié ou une sauvegarde non chiffrée peut livrer l'ensemble du jeu de données d'un coup. Durcir la base réduit la valeur de tout autre point d'ancrage, car même un attaquant qui atteint le segment réseau se heurte encore à l'authentification, au moindre privilège, au chiffrement et à la surveillance. Voyez-le comme une défense en profondeur appliquée au seul actif dont la compromission est généralement l'objectif réel de l'intrusion.

La surface d'exposition d'une base de production#

La surface d'exposition a plusieurs visages. Il y a le visage réseau — le port sur lequel le moteur écoute et qui peut l'atteindre. Il y a le visage authentification — comment les identités se prouvent et la force de ces preuves. Il y a le visage autorisation — ce que chaque rôle peut lire, écrire ou administrer. Il y a le visage données au repos — fichiers, tablespaces et sauvegardes sur le disque. Et il y a le visage observabilité — si quiconque remarquerait un accès anormal. Une base durcie resserre chacun d'eux ; une installation par défaut en laisse plusieurs grands ouverts, le plus souvent en écoutant sur toutes les interfaces et en faisant implicitement confiance aux connexions locales.

Comment les attaques contre les bases se déroulent à haut niveau#

Conceptuellement, une intrusion visant les données suit un arc reconnaissable. L'adversaire atteint d'abord une position depuis laquelle la base est adressable — un serveur applicatif, un hôte de rebond ou un port exposé. Il tente ensuite de s'authentifier, que ce soit via des identifiants réutilisés trouvés ailleurs, un mot de passe faible ou par défaut, ou un compte applicatif aux droits excédentaires. Une fois connecté, il énumère schémas et privilèges en cherchant le chemin le plus court vers les tables sensibles ou vers une capacité administrative. Enfin il tente l'extraction massive ou la persistance. Chaque étape correspond à un contrôle défensif, c'est pourquoi le durcissement se planifie mieux comme une série de barrières le long de cet arc que comme un mur unique.

Authentification et contrôle d'accès#

Commencez par éliminer la confiance par défaut. Dans PostgreSQL, revoyez pg_hba.conf afin qu'aucune règle n'utilise la méthode trust sauf sur des sockets locaux strictement contrôlés, et préférez scram-sha-256 pour l'authentification par mot de passe. Dans MySQL, supprimez les comptes anonymes et tout compte à mot de passe vide ou par défaut, et préférez des plugins d'authentification robustes. Donnez à chaque personne et à chaque application son propre rôle nommé, jamais un superutilisateur partagé. Là où la plateforme le permet, intégrez un fournisseur d'identité central ou une authentification par certificat à courte durée pour que les identifiants soient renouvelables et révocables. Imposez des politiques de mot de passe robustes et, pour l'accès administratif, exigez l'authentification multifacteur au niveau du bastion devant la base.

Exposition réseau et chiffrement en transit#

Liez le moteur aux interfaces spécifiques qu'il doit servir, pas à toutes les adresses, et placez-le dans un segment réseau privé accessible uniquement depuis la couche applicative et les bastions d'administration. Utilisez des pare-feu d'hôte et des groupes de sécurité réseau comme deuxième barrière afin qu'une mauvaise configuration n'expose pas le port au réseau plus large. Exigez TLS pour chaque connexion et désactivez le repli non chiffré : dans PostgreSQL imposez des règles hostssl et mettez ssl = on ; dans MySQL exigez un transport sécurisé. Validez les certificats côté client afin qu'un homme du milieu ne puisse pas discrètement rétrograder ou intercepter la session. Traitez toute connexion de base en clair en production comme un incident à corriger, pas comme une commodité tolérable.

Moindre privilège et permissions de schéma#

Les comptes surprivilégiés sont le constat le plus fréquent dans les revues de bases. Les comptes applicatifs tournent souvent en propriétaires ou superutilisateurs alors qu'ils n'ont besoin que de select, insert, update et delete sur quelques tables. Accordez le minimum, révoquez le reste et utilisez l'héritage de rôles pour rester gérable. Dans PostgreSQL, soyez délibéré avec le schéma public et les privilèges par défaut, et envisagez la sécurité au niveau des lignes pour les données multi-locataires. Dans MySQL, limitez les grants à des bases et tables précises plutôt que des grants avec joker. Séparez le compte qui exécute les migrations de celui qui sert le trafic, afin qu'une compromission applicative quotidienne ne confère pas automatiquement le pouvoir de modifier le schéma.

Chiffrement au repos et gestion des secrets#

Protéger les données sur le disque ferme le chemin où un attaquant ou une sauvegarde perdue livre le jeu de données directement. Activez le chiffrement au niveau du stockage ou du système de fichiers pour le répertoire de données et, surtout, chiffrez les sauvegardes avec des clés gérées séparément de l'hôte de la base. N'incorporez jamais de mots de passe de base dans le code source ni dans des fichiers de configuration versionnés ; récupérez-les à l'exécution depuis un gestionnaire de secrets avec journalisation des accès. Renouvelez les identifiants de façon planifiée et immédiatement après toute exposition suspectée. La règle directrice : posséder un disque, un instantané ou une archive de sauvegarde ne doit pas suffire à lire les données sans posséder aussi des clés détenues sous contrôle séparé.

Détection : journalisation et surveillance#

Durcir sans détecter vous laisse aveugle aux tentatives qui passent. Dans PostgreSQL, activez la journalisation des connexions et déconnexions, journalisez les authentifications échouées et envisagez l'extension pgaudit pour un audit au niveau des instructions des objets sensibles. Dans MySQL, activez le plugin de journal d'audit et les journaux général ou de requêtes lentes selon le besoin, et capturez les événements de connexion échouée. Envoyez ces journaux à un SIEM central et alertez sur les signaux significatifs : un pic d'échecs d'authentification, une connexion depuis un hôte inattendu ou à une heure inhabituelle, des attributions de privilèges, des volumes de résultats importants ou inhabituels évoquant une extraction massive, et toute modification de la configuration d'audit. Surveillez la santé de la chaîne de journalisation elle-même.

Sauvegarde, restauration et intégrité#

La disponibilité et l'intégrité font partie de la sécurité, elles n'en sont pas séparées. Maintenez des sauvegardes testées et chiffrées avec une rétention définie, et stockez au moins une copie dans un endroit qu'un attaquant compromettant le système primaire ne peut atteindre ni supprimer. Répétez la restauration régulièrement ; une sauvegarde jamais restaurée est un espoir, pas un contrôle. Protégez les sauvegardes avec la même discipline de moindre privilège et de surveillance que la base vive, car un dépôt de sauvegardes non gardé n'est qu'une seconde copie, plus discrète, de tout. Pour la résilience aux rançongiciels, un stockage de sauvegarde immuable ou en écriture unique garantit qu'un intrus disposant d'un accès à la base ne peut pas aussi détruire les moyens de restauration.

Pièges courants#

Les erreurs récurrentes incluent laisser le moteur écouter sur toutes les interfaces, conserver des comptes d'administration par défaut ou partagés, accorder aux utilisateurs applicatifs bien plus qu'il ne faut, et stocker des chaînes de connexion à mots de passe incorporés dans des dépôts. Les équipes activent souvent le chiffrement en transit sans jamais l'imposer, si bien que les clients retombent discrètement en clair. D'autres chiffrent le volume vif mais laissent les sauvegardes en clair. Une lacune de détection fréquente est une journalisation qui existe mais n'est jamais transférée ni relue, et ne sert donc qu'à l'autopsie après incident. Enfin, méfiez-vous des raccourcis de performance qui désactivent l'authentification ou l'audit pour un traitement par lots et ne sont jamais réactivés.

Liste de contrôle de durcissement#

Un point de départ défensif : (1) supprimer la confiance par défaut, les comptes anonymes et par défaut ; (2) imposer des identifiants robustes, renouvelés et par identité avec MFA sur les chemins administratifs ; (3) lier à des interfaces précises dans un segment privé derrière des pare-feu d'hôte et réseau ; (4) exiger et valider TLS pour chaque connexion ; (5) appliquer le moindre privilège à chaque rôle et séparer comptes de migration et d'exécution ; (6) chiffrer les données au repos et chiffrer les sauvegardes avec des clés gérées séparément ; (7) tirer les secrets d'un gestionnaire, jamais du contrôle de versions ; (8) activer l'audit des connexions, des échecs de connexion et des instructions et le transférer vers un SIEM ; (9) alerter sur les anomalies d'authentification, les changements de privilèges et l'extraction massive ; (10) conserver des sauvegardes testées, immuables et hors du primaire et répéter la restauration.

FAQ : le chiffrement en transit suffit-il sur un réseau privé ?#

Non. Un réseau privé réduit l'exposition mais n'élimine ni le déplacement latéral, ni la mauvaise configuration, ni un initié sur le même segment. Le chiffrement en transit protège la session de l'interception et de la rétrogradation quel que soit l'emplacement de la frontière réseau, et il doit se combiner au moindre privilège, au chiffrement au repos et à la surveillance. La défense en profondeur suppose que n'importe quelle couche, y compris le périmètre réseau, peut échouer.

FAQ : l'application doit-elle utiliser un superutilisateur par commodité ?#

Jamais en production. Un compte applicatif ne doit détenir que les droits de manipulation de données dont il a réellement besoin sur les objets précis qu'il touche. Tourner en superutilisateur signifie que toute compromission de la couche applicative — une faille d'injection, un jeton volé — devient immédiatement une compromission totale de la base. Séparez les comptes d'exécution, de migration et d'administration pour que le rayon d'action d'un seul identifiant reste contenu.

Conclusion#

Durcir PostgreSQL et MySQL en production consiste à placer des barrières le long de tout le chemin qu'un adversaire parcourrait vers les données : une authentification qui résiste à la réutilisation, une isolation réseau qui limite la portée, un moindre privilège qui contient chaque point d'ancrage, un chiffrement qui neutralise disques et sauvegardes volés, et une détection qui transforme l'accès anormal silencieux en une alerte bruyante. Rien de tout cela n'est exotique et, ensemble, ces mesures transforment l'actif le plus précieux du parc d'une cible molle en une cible surveillée et défendable. Traitez la liste comme vivante, revoyez-la après chaque changement et chaque incident, et vérifiez la configuration réelle plutôt que de vous fier à celle prévue.