Connecter MCP à PostgreSQL : pilote lecture seule et permissions minimales

Connecter MCP à PostgreSQL peut aider un assistant à répondre à une question sur un schéma, une donnée de démonstration ou un rapport limité. C’est aussi l’un des cas les plus sensibles : une base peut contenir des données personnelles, des secrets indirects ou des informations métier. Pour un premier essai, n’utilisez jamais le compte de production principal. Créez un environnement de test ou une copie anonymisée, puis un utilisateur dédié qui ne peut lire que le strict nécessaire.

Le bon objectif initial est une lecture simple, par exemple « lister les colonnes de la table de démonstration » ou « compter les entrées fictives ». N’autorisez ni INSERT, ni UPDATE, ni DELETE, ni modification de schéma. Un serveur MCP ne doit pas recevoir une chaîne de connexion d’administrateur simplement parce qu’elle est déjà disponible dans votre environnement.

Ce que vous allez apprendre

Vous allez définir un pilote, créer une identité PostgreSQL à privilèges réduits, limiter le schéma et les requêtes, protéger la configuration et contrôler le premier appel MCP. Vous saurez également quand arrêter : données non anonymisées, besoin de droits d’écriture ou logs impossibles à maîtriser.

Prérequis

Prévoyez une instance PostgreSQL de développement ou une base de test, les droits d’administration nécessaires pour créer un rôle limité et une personne responsable des données. Consultez la documentation du serveur MCP et celle de votre client avant de déclarer une connexion.

Ne copiez pas l’URL réelle de votre base dans une conversation ou un fichier versionné. Un exemple doit rester fictif :

DATABASE_URL="postgresql://mcp_reader:mot-de-passe-local@localhost:5432/demo"

Vérification : aucune valeur active n’apparaît dans le diff, les logs ou la configuration partagée. Si une URL contenant un mot de passe a été exposée, faites tourner le secret selon la procédure de l’équipe.

1. Définir la question et le jeu de données

Écrivez la question que l’assistant doit pouvoir traiter. « Trouver le nombre de projets de démonstration par statut » est un cas concret. « Donner accès à la base » n’est pas un besoin : il ne décrit ni la table, ni les colonnes, ni les limites de données.

Préparez une base de développement avec des données fictives ou anonymisées. Vérifiez que les échantillons ne contiennent pas d’adresse email réelle, de token, de note privée ou de donnée financière non autorisée. Un pilote limité est plus simple à contrôler et permet de tester le comportement du serveur sans risquer un accès aux données de production.

Vérification : vous pouvez nommer les tables visibles, les colonnes autorisées et les catégories de données exclues. Si ce n’est pas possible, le travail de classification précède l’intégration MCP.

2. Créer un rôle PostgreSQL dédié

Un rôle dédié facilite l’audit et la révocation. Il ne doit pas être superutilisateur, propriétaire de la base ni membre d’un groupe trop large. Son accès est limité au schéma et aux objets nécessaires. La syntaxe exacte doit être relue et adaptée avec la documentation PostgreSQL et la politique de votre équipe ; ne lancez pas une commande d’administration dans une base inconnue.

Le principe à retenir est : connexion autorisée, usage d’un schéma précis, SELECT sur des tables ou vues choisies, aucun droit de modification. Les vues peuvent être préférables aux tables brutes quand elles masquent des colonnes sensibles ou limitent les lignes exposées. Un serveur MCP devrait lire cette surface réduite, pas le modèle entier de la base.

Vérification : connectez-vous avec le rôle de test et vérifiez une lecture autorisée, puis une opération interdite dans un environnement de démonstration. Le refus attendu est une preuve que les droits sont réellement limités.

3. Limiter le schéma et les requêtes

Le moindre privilège ne concerne pas seulement les verbes SQL. Limitez aussi les schémas, tables, colonnes et volume de résultat. Une requête qui retourne toutes les lignes d’une table peut dévoiler plus de données que nécessaire, même si elle est en lecture seule.

Privilégiez des outils spécialisés : list_demo_projects ou count_projects_by_status sont plus contrôlables qu’un outil générique qui accepte du SQL libre. Si le serveur doit accepter une requête, imposez une validation stricte, une liste d’opérations autorisées, un délai, une limite de lignes et des journaux sans données sensibles. Ne croyez pas qu’un simple filtrage de mot-clé rend du SQL libre sûr.

Vérification : testez une entrée normale, une requête vide, une tentative d’écriture et une demande trop large. Les trois dernières doivent être refusées ou limitées de manière explicite.

4. Configurer le serveur MCP sans secret exposé

Suivez le format de configuration de votre client et du serveur MCP. Référencez une variable d’environnement, pas une valeur de mot de passe dans un fichier suivi. Notez la version du serveur, le rôle utilisé, les capacités exposées et l’emplacement des logs. Ne démarrez qu’un seul serveur pendant le pilote afin de pouvoir attribuer chaque appel.

Avant le premier lancement, relisez les arguments. Vérifiez que la cible est la base de test, que le nom d’utilisateur est celui du rôle dédié et qu’aucune option n’active une écriture ou une introspection hors périmètre. Un outil qui demande un accès de superutilisateur pour lister un schéma ne convient pas au pilote.

Vérification : la liste des outils du serveur correspond aux lectures prévues. Une capacité imprévue est un motif d’arrêt et de revue, pas une fonctionnalité à essayer par curiosité.

5. Faire une requête d’essai observable

Commencez par l’opération la plus simple, comme compter les lignes de démonstration ou lire une vue dépourvue de donnée personnelle. Vérifiez le nom de l’outil, ses paramètres, la limite de résultat et la sortie. Consignez la date, la base de test, l’utilisateur et le comportement observé.

Les données renvoyées par la base restent des données non fiables dans le contexte d’un assistant. Une colonne textuelle peut contenir une instruction hostile ou un contenu mal formaté. Ne laissez pas cette sortie changer vos règles d’exécution, vos permissions ou vos consignes de sécurité.

Vérification : confirmez dans les logs PostgreSQL ou du serveur, selon la politique retenue, que l’action était bien une lecture avec le rôle dédié. Les logs doivent être utiles sans inclure le mot de passe ni l’intégralité des données retournées.

Problèmes fréquents et solutions

Le serveur réclame un compte administrateur

Ne le fournissez pas. Cherchez une configuration avec rôle dédié, un serveur différent ou une couche d’API qui expose seulement la donnée nécessaire. Un pilote lecture seule ne justifie pas un privilège global.

Les résultats contiennent des données sensibles

Arrêtez le pilote, réduisez la surface via des vues ou des données anonymisées, puis faites valider la nouvelle classification. Ne masque pas seulement l’affichage si la donnée a déjà été transmise.

Une requête libre est nécessaire

Évaluez le besoin comme une tâche de sécurité séparée. Préférez un ensemble de requêtes prédéfinies ou une API analytique limitée plutôt qu’un terminal SQL généraliste.

FAQ

Puis-je utiliser ma base de production ?

Pas pour un premier essai. Utilisez une base de test ou une copie anonymisée, puis soumettez tout accès plus large à une revue dédiée.

Pourquoi créer un utilisateur distinct ?

Il limite les droits, permet d’identifier les appels du serveur et peut être révoqué sans impacter les autres applications.

SELECT est-il toujours sans risque ?

Non. Une lecture peut révéler un grand volume ou une donnée sensible. Limitez les objets, colonnes, lignes et logs.

Comment tester que l’écriture est bloquée ?

Dans la base de démonstration, essayez une opération interdite avec le rôle dédié et vérifiez que PostgreSQL la refuse. Ne faites pas ce test sur une cible inconnue.

Faut-il enregistrer les requêtes MCP ?

La journalisation doit respecter votre politique de données. Conservez le minimum utile pour l’audit et évitez les mots de passe ou résultats sensibles complets.

Conclusion

MCP et PostgreSQL peuvent cohabiter sans ouvrir une base entière à un assistant. Le pilote responsable repose sur une base de test, un rôle dédié en lecture seule, des outils spécialisés et une vérification des résultats. Les droits d’écriture ou les données de production demandent une décision séparée.

Pour comprendre le protocole avant de connecter la base, consultez MCP : définition, fonctionnement et sécurité.

Sources et limites

• PostgreSQL — Database roles and privileges : rôles et privilèges PostgreSQL.
• PostgreSQL — GRANT : attribution de droits à vérifier selon l’environnement.
• Model Context Protocol — security best practices : principes MCP applicables aux données sensibles.

Ce guide ne fournit aucune commande destinée à une base de production et ne valide pas un serveur tiers ou une politique de données.