</>
Plan du cours — 50/64

Rôles et privilèges

Avancé

PostgreSQL gère l'accès avec un seul concept, le rôle : un rôle peut représenter un utilisateur, un groupe, ou une application.

CREATE ROLE lecture NOLOGIN;                                    -- un groupe : ne se connecte pas
GRANT CONNECT ON DATABASE ma_base TO lecture;
GRANT USAGE ON SCHEMA public TO lecture;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO lecture;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO lecture;   -- pour les futures tables

CREATE ROLE app_api LOGIN PASSWORD '...' IN ROLE lecture;       -- un compte qui hérite de « lecture »
GRANT INSERT, UPDATE ON commandes TO app_api;                   -- privilèges supplémentaires ciblés

Le principe du moindre privilège#

RôleDroits
Propriétaire du schéma / migrationsCREATE, ALTER, DROP : utilisé uniquement par l'outil de migration
Application (app_api)SELECT, INSERT, UPDATE, DELETE sur les tables nécessaires, jamais de DDL
Reporting / analystesSELECT seulement, idéalement sur une réplique
Superutilisateur (postgres)Administration, jamais utilisé par une application

Bonnes pratiques#

  • Un rôle par application ou service, pas un compte partagé pour tout.
  • Révoquer les droits par défaut du schéma public : REVOKE CREATE ON SCHEMA public FROM PUBLIC; (déjà le cas par défaut depuis PostgreSQL 15).
  • Ne jamais connecter une application avec un superutilisateur.
  • Stocker les mots de passe dans un gestionnaire de secrets, avec rotation.
  • Authentification : scram-sha-256 (défaut moderne), TLS obligatoire, et règles pg_hba.conf restreintes par réseau.

Piège : donner ALL PRIVILEGES à l'utilisateur de l'application « pour que ça marche » transforme une injection SQL ou une fuite d'identifiants en compromission totale du schéma (DROP TABLE).

← Leçon précédenteSuperviser une base en productionLeçon suivante →Injection SQL et requêtes paramétrées