Comment fonctionnent les rôles et les privilèges dans PostgreSQL ?

Question

Accepted Answer

PostgreSQL gère le contrôle d'accès par les **rôles** (qui servent à la fois d'utilisateurs et de groupes) et les **privilèges** (permissions accordées sur les objets). Ce système contrôle qui peut se connecter et ce qu'il peut faire — fondamental pour la sécurité de la base de données.

## Rôles — utilisateurs et groupes unifiés

```sql
-- a role can be a USER (can log in) or a GROUP (collection of permissions)
CREATE ROLE app_user WITH LOGIN PASSWORD 'secret';   -- a login role (a "user")
CREATE ROLE readonly;                                 -- a group role (no login)

-- roles can be members of other roles (inherit their privileges)
GRANT readonly TO app_user;          -- app_user inherits readonly's privileges
```

Dans Postgres, un **rôle** est un concept unifié — il peut se connecter (agissant comme un utilisateur) et/ou contenir d'autres rôles (agissant comme un groupe). Ce modèle flexible gère à la fois les utilisateurs et les groupes de permissions.

## Privilèges — accorder des permissions sur les objets

```sql
-- grant specific privileges on objects
GRANT SELECT ON users TO readonly;                    -- read-only on a table
GRANT SELECT, INSERT, UPDATE, DELETE ON orders TO app_user;  -- full data access
GRANT USAGE ON SCHEMA sales TO app_user;              -- access a schema
GRANT ALL PRIVILEGES ON DATABASE mydb TO admin;

REVOKE INSERT ON orders FROM app_user;                -- take away a privilege
```

Les privilèges (`SELECT`, `INSERT`, `UPDATE`, `DELETE`, `USAGE`, etc.) sont accordés sur les objets (tables, schémas, bases de données) aux rôles — contrôlant précisément ce que chaque rôle peut faire.

## Le principe du moindre privilège

```sql
-- ✅ grant only the permissions each role actually needs
GRANT SELECT ON reports TO analyst;     -- analyst can only READ reports
-- ❌ don't grant ALL PRIVILEGES or superuser broadly — minimize the blast radius
```

**Le moindre privilège** — accorder à chaque rôle uniquement les permissions dont il a besoin — est une pratique de sécurité fondamentale qui limite les dégâts causés par des identifiants compromis ou des erreurs.

## Privilèges par défaut et propriété

```sql
-- the object's OWNER has full control; new objects need explicit grants
ALTER DEFAULT PRIVILEGES IN SCHEMA sales
  GRANT SELECT ON TABLES TO readonly;   -- auto-grant on FUTURE tables
```

## Pourquoi c'est important

Comprendre les rôles et les privilèges de PostgreSQL est important pour la **sécurité de la base de données** — contrôler qui peut accéder à la base de données et ce qu'il peut faire est fondamental pour protéger les données, donc cette connaissance est précieuse pour toute base de données en production.

Comprendre le concept de **rôle** (le modèle unifié de Postgres où les rôles servent à la fois d'utilisateurs — qui peuvent se connecter — et de groupes — collections de permissions que les autres rôles héritent) est nécessaire pour gérer l'accès, car c'est ainsi que vous créez des utilisateurs de base de données et organisez les permissions.

Savoir comment accorder et révoquer les **privilèges** (`SELECT`, `INSERT`, etc.) sur les objets (tables, schémas, bases de données) aux rôles est essentiel pour contrôler précisément ce que chaque utilisateur ou application peut faire.

D'une importance critique est le **principe du moindre privilège** — accorder à chaque rôle uniquement les permissions dont il a vraiment besoin (par exemple, un rôle d'analyste en lecture seule, un rôle d'application avec uniquement l'accès dont il a besoin) plutôt que des permissions larges ou de superutilisateur — qui est une pratique de sécurité fondamentale qui limite les dégâts causés par des identifiants compromis, des bogues ou des erreurs (une défense réelle et importante).

Comprendre les privilèges par défaut et la propriété (le propriétaire de l'objet a le contrôle complet ; les objets futurs peuvent nécessiter des octrois explicites) complète la gestion pratique de l'accès.

Étant donné que la sécurité de la base de données est critique (les bases de données contiennent des données sensibles et précieuses), et étant donné que le contrôle d'accès approprié par les rôles et les octrois de moindre privilège est la manière de protéger ces données et de limiter les risques, comprendre les rôles et les privilèges de PostgreSQL — le modèle de rôle unifié, l'octroi/révocation de privilèges, et particulièrement le principe du moindre privilège — est une connaissance de sécurité importante pour administrer et sécuriser les bases de données en production, une responsabilité fréquemment pertinente et un sujet courant pour quiconque gère l'accès à la base de données.