Étape 05 — Isolation, RBAC & RLS
Prouver techniquement que l’architecture multi-clubs ne fuit pas d’un tenant vers un autre.
Pourquoi cette étape est prioritaire pour P&P ?
P&P héberge plusieurs clubs. Une erreur qui permet au Club A de lire les données du Club B est l’un des scénarios les plus graves. On teste donc l’autorisation au niveau applicatif et une seconde barrière directement dans PostgreSQL avec RLS.
Lire la section complète, copier une commande à la fois, vérifier le résultat attendu, puis seulement continuer.
- RBAC : permissions attribuées via des rôles.
- RLS : règles PostgreSQL qui filtrent les lignes accessibles.
- Tenant : organisation cliente ; ici, typiquement un club.
1. Risque n°1 : fuite inter-club
Le test le plus important de P&P est simple à formuler : un utilisateur du Club A ne doit jamais lire ou modifier une ressource du Club B.
2. Séparer les rôles PostgreSQL
Le rôle utilisé par l’application ne doit pas être propriétaire des tables et ne doit pas posséder BYPASSRLS. Utiliser un rôle distinct pour les migrations.
-- À adapter aux noms de votre base et de vos rôles CREATE ROLE pnp_migrator LOGIN; CREATE ROLE pnp_app LOGIN; -- Le rôle de migration possède les objets ; pnp_app reçoit seulement -- les droits DML nécessaires au runtime.
3. Activer RLS sur une table pilote
ALTER TABLE members ENABLE ROW LEVEL SECURITY;
ALTER TABLE members FORCE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON members
USING (club_id = current_setting('app.current_club_id', true)::int)
WITH CHECK (club_id = current_setting('app.current_club_id', true)::int);club_id doivent correspondre au schéma réel.4. Positionner le tenant par transaction
BEGIN; SET LOCAL app.current_club_id = '15'; -- requêtes applicatives du tenant 15 COMMIT;
Avec un pool de connexions, écrire un test qui prouve qu’un contexte de tenant ne fuit jamais vers la requête suivante.