Un système de gestion de chantier peut contenir des données commerciales sensibles de plusieurs organisations. L’isolation restreint l’accès à ces données. Chantier Manager utilise des politiques PostgreSQL au niveau des lignes, associées aux contrôles d’accès applicatifs.

Politiques et rôles

PostgreSQL applique les politiques au niveau des lignes aux opérations concernées sur les tables où cette sécurité est activée. Les superutilisateurs et rôles BYPASSRLS contournent ces politiques. Les propriétaires de tables les contournent normalement aussi, sauf activation de FORCE ROW LEVEL SECURITY. Les politiques doivent donc être évaluées avec le rôle applicatif et ses privilèges.

-- Illustrative example / Exemple illustratif
ALTER TABLE work_package ENABLE ROW LEVEL SECURITY;
ALTER TABLE work_package FORCE ROW LEVEL SECURITY;

CREATE POLICY work_package_tenant ON work_package
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Politique illustrative, non extraite du produit. Les privilèges du rôle et la gestion du contexte d’organisation doivent également être examinés.

Validation au démarrage

Le contrôle de démarrage de Chantier Manager en production refuse un rôle applicatif doté de privilèges superutilisateur ou BYPASSRLS. Il vérifie une condition précise de déploiement. À lui seul, il ne prouve pas que toutes les politiques de table ou permissions applicatives sont correctes.

Tester les différentes frontières

Les tests croisés nécessitent au moins deux contextes d’organisation pour vérifier que l’une ne peut pas lire ou modifier les données de l’autre. Les tests de politiques examinent la sécurité et les règles des tables attendues. Les tests avec une seule organisation portent sur le fonctionnement en déploiement dédié ; ils ne démontrent pas la frontière entre organisations.