Rôles, users et principe du moindre privilège

Prérequis (cursus dev) : tables et SQL, PostgreSQL, utilisateurs et services.

Pourquoi

Une faille applicative hérite des droits de la connexion base. Deux classiques : injection SQL (données utilisateur concaténées dans une requête — voir cursus dev, ch. Sécurité) et RCE (Remote Code Execution : exécution de code arbitraire sur le serveur via la faille). Avec un superuser, RCE = game over total ; avec un rôle cantonné, incident contenu.

Concepts

• Rôle LOGIN : un compte de connexion (CREATE ROLE monapp LOGIN PASSWORD '...'), sans les super-pouvoirs du rôle postgres (créer des rôles, lire toutes les bases).
• \du / \l (psql) : qui est superuser / qui possède quoi. Seul postgres devrait être superuser.
• Socket local : connexion Unix sans réseau (plus rapide, sans mot de passe si configurée) pour l'admin depuis la machine elle-même.

Exemple

CREATE ROLE monapp LOGIN PASSWORD 'mot-de-passe-long-aleatoire';
CREATE DATABASE monapp OWNER monapp;

DATABASE_URL=postgresql://monapp:...@db-interne:5432/monapp — hôte = nom interne, jamais exposé. Mot de passe généré (openssl rand -base64 24), dans un .env à 600, jamais dans git/logs/tickets.

Cas réel

Deux apps sur le même rôle superuser « pour simplifier » : la faille XSS de l'une devient lecture/écriture dans la base de l'autre. Trente secondes de CREATE ROLE auraient suffi.

Pièges

• Mot de passe faible « temporaire » : le temporaire dure toujours.
• postgres utilisé par l'app « parce que ça marchait en local » : le local n'est pas la prod.
• Droits accordés « au cas où » (CREATEDB, etc.) : chaque privilège est une option pour l'attaquant.

À retenir

Un rôle par app, superuser jamais en appli, secrets en 600, schéma en fichiers versionnés (schema_migrations, en transaction).