Rôles, schémas et isolation des tenants

Comprendre le mécanisme

Les droits d’un rôle définissent les opérations possibles sur les objets. Un rôle applicatif ne devrait pas hériter de privilèges d’administration inutiles. Les schémas organisent les noms ; search_path participe à la résolution et doit être maîtrisé dans les contextes sensibles. RLS ajoute des politiques par ligne, mais les rôles superuser ou BYPASSRLS et, normalement, le propriétaire de la table constituent des cas particuliers.

Raisonner et vérifier

Un test réalisé avec le propriétaire peut masquer une erreur de politique. Utilisez le rôle runtime non propriétaire et définissez le contexte de tenant depuis une identité fiable, pas un champ client arbitraire. FORCE ROW LEVEL SECURITY soumet le propriétaire aux politiques dans son périmètre, sans neutraliser tous les privilèges spéciaux. Vérifiez lecture et écriture ainsi que les requêtes de maintenance.

Définir le moindre privilège utile

Le rôle runtime doit posséder les opérations nécessaires au service, pas automatiquement les pouvoirs d’un administrateur SQL. Un privilège excessif élargit les conséquences d’une erreur ou d’une compromission. Inventoriez connexions, lectures, écritures et opérations de schéma. Les tests doivent démontrer un usage nominal et un refus pertinent ; une authentification à la base ne donne pas à elle seule un droit sur chaque table.

Propriété SQL et rôle métier

Le propriétaire d’une table est un concept du moteur distinct d’un utilisateur métier nommé administrateur. Ne confondez pas ces deux modèles lors de la conception des accès. Si le compte applicatif possède les objets, certaines protections peuvent se comporter autrement que pour un compte runtime limité. Une revue doit donc noter le rôle SQL réel et ses attributs, au lieu de conclure à partir du seul nom visible dans l’interface.

Comprendre les exceptions au modèle RLS

Une politique RLS doit être évaluée avec les rôles et paramètres effectifs. Le propriétaire est normalement exempté de certaines restrictions, sauf configuration adaptée ; superutilisateurs et capacités de contournement demandent aussi une revue. FORCE ROW LEVEL SECURITY n’est pas une formule remplaçant tout modèle de privilège. Décrivez qui crée, possède et interroge les tables, puis vérifiez ce que chaque contexte peut réellement voir.

Démontrer l’isolation avec deux tenants

Un test avec un seul tenant ne peut pas montrer une fuite inter-tenant. Préparez deux ensembles reconnaissables et consultez chacun avec son contexte fiable. Vérifiez aussi les écritures et les références croisées pertinentes. Le résultat attendu doit inclure l’absence des données tierces, pas seulement la présence des bonnes lignes. Une interface filtrée peut masquer une requête serveur trop large si le test ne regarde pas la réponse brute.

Privilèges de connexion, schéma et objet

Un droit de connexion n’équivaut pas à SELECT sur toutes les tables, et un droit sur une table ne décrit pas nécessairement la possibilité de résoudre le schéma concerné. Lisez les portées des privilèges avant de modifier une configuration. Un refus ne doit pas être corrigé en accordant tous les droits sans analyse. Cherchez l’opération requise et le périmètre minimal qui permet ce parcours.

Le contexte d’une connexion réutilisée

Un pool réutilise des connexions dont certains états peuvent survivre à une requête. Si un paramètre de session désigne un tenant, il doit être établi depuis une identité fiable et correctement nettoyé selon le contrat de réutilisation. Un champ client libre ne doit pas choisir le tenant de confiance. Testez deux requêtes successives sur la même connexion avec des tenants différents pour révéler une contamination d’état.

Protéger les credentials de base

Le DSN et les paramètres de connexion peuvent contenir des secrets donnant accès à un large ensemble de données. Leur injection par environnement ne rend pas leur affichage public acceptable. Limitez les logs, les accès de diagnostic et les copies d’artefact. En cas d’exposition, retirez la capacité compromise selon une procédure de rotation ; effacer seulement une ligne d’un fichier courant ne supprime pas les anciennes copies.

Revoir SECURITY DEFINER et la résolution des noms

Une fonction SECURITY DEFINER s’exécute dans un contexte de privilèges qui demande une analyse précise. Les noms résolus, le chemin de recherche et les objets accessibles peuvent influencer ce qu’elle appelle réellement. Ne supposez pas que l’option garantit à elle seule une isolation sûre. Limitez les capacités exposées et testez les entrées ainsi que les contextes où un utilisateur moins privilégié peut l’invoquer.

Séparer migration et exploitation courante

Créer ou modifier le schéma demande parfois des privilèges inutiles à une API après son déploiement. Utiliser le même compte pour tout rend la frontière moins précise. Définissez un rôle de migration et un rôle runtime selon le besoin, avec distribution et rotation de secrets adaptées. Vérifiez le service une fois les capacités temporaires retirées ; un démarrage réussi avec des droits administrateur ne suffit pas.

Tester le rôle effectivement déployé

Une requête réussie en superutilisateur ne prouve pas le comportement du compte applicatif. Les protections peuvent être contournées ou les permissions beaucoup plus larges. Conservez dans la preuve le rôle, ses attributs et la configuration testée. Une suite d’isolation doit être exécutée avec le contexte runtime pertinent et montrer les refus attendus, tout en gardant un parcours nominal qui confirme que le service reste utilisable.

Atelier guidé : lire, expliquer et vérifier le code

-- Connexion réutilisée par un pool :
SET app.tenant_id = 'tenant-a';
SELECT current_setting('app.tenant_id');
-- La même connexion sert ensuite une demande tenant-b.

La configuration de l’atelier place un tenant dans un paramètre de session, puis indique que la connexion est réutilisée. La valeur ne connaît pas automatiquement l’identité du prochain appelant. Si aucune remise en contexte correcte n’est faite, une requête suivante peut hériter d’un état qui ne lui appartient pas. Lire ce paramètre avec current_setting ne valide pas sa provenance.

Construisez un essai à deux clients sur un pool de laboratoire. Le premier établit son contexte, puis le second effectue une lecture sur la connexion rendue disponible. Vérifiez que les lignes du premier restent absentes du résultat du second. Répétez l’exercice avec le rôle runtime réel et documentez comment la valeur de tenant est dérivée de l’identité, installée puis nettoyée.

RLS : le rôle qui exécute la requête compte

Une politique RLS correcte ne suffit pas si le rôle runtime bénéficie d’une exemption. Le propriétaire de table contourne normalement RLS ; dans le cas posé, il peut donc voir tous les tenants même sans superuser ni attribut BYPASSRLS.

Utilisez de préférence un rôle d’exécution non propriétaire, avec permissions minimales, et un rôle séparé pour les migrations. FORCE ROW LEVEL SECURITY peut soumettre le propriétaire aux politiques dans le cas concerné, mais ne transforme pas les superusers ou rôles BYPASSRLS en rôles ordinaires. Documentez ces distinctions au lieu de parler simplement de RLS activé.

Testez avec les credentials réellement utilisés par l’application, puis changez de tenant. Un test effectué avec le rôle de migration ne démontre pas l’isolation du runtime et peut même masquer sa configuration. Vérifiez également la provenance du contexte tenant utilisé par la politique : un paramètre libre envoyé par le client ne constitue pas un contexte autorisé.

Points de vigilance : Le propriétaire bénéficie normalement d’une exemption. FORCE le soumet aux politiques ; superuser et BYPASSRLS restent des cas distincts. RLS peut limiter les lignes visibles par SELECT. Une politique peut filtrer les lignes sans prédicat explicite dans chaque SELECT ; son contexte doit néanmoins être fiable. Un index ne désactive pas le contrôle d’accès par ligne.