RLS : Row-Level Security
Sécurité
Mécanisme de contrôle d'accès dans PostgreSQL qui filtre les lignes visibles selon le rôle connecté.
Principe : RLS applique des politiques de sécurité au niveau des lignes d'une table, limitant l'accès aux données selon des règles définies par rôle.
Configuration : Les politiques RLS s'activent par table et s'écrivent en SQL, permettant un filtrage dynamique et granulaire des enregistrements.
Cas d'usage : Utile pour isoler les données multi-utilisateurs dans une même base sans multiplier les bases ou schémas.
Ce qui arrive si on s'en passe
Sans sécurité au niveau des lignes, une base partagée entre plusieurs utilisateurs ou clients confie tout l'isolement à l'application : une clause WHERE oubliée dans une seule requête suffit à afficher les données de tout le monde. Une injection SQL, un outil d'analyse branché directement sur la base ou un développeur pressé contournent de même un filtrage qui n'existe que dans le code. Des politiques mal écrites, ou un rôle propriétaire de la table qui en est exempté par défaut, produisent le même effet avec la fausse assurance d'une protection activée. Le cloisonnement confié à la seule bonne volonté du code a l'élégance d'un mur mitoyen en papier peint.
Explication de la marmotte
Imagine que tu as un grand classeur avec plein de feuilles, mais que chaque feuille contient des informations différentes pour chaque élève de ta classe. Le système dont on parle fait en sorte que quand tu ouvres ce classeur, tu ne vois que les feuilles qui te concernent, pas celles des autres. C’est comme si une porte magique ne laissait passer que les pages qui t’appartiennent, pour que tu ne puisses pas lire ce qui ne te regarde pas. Cela aide à garder les informations privées et bien rangées.
Où ce terme est utilisé
- DAC, MAC, RBAC, ABAC ou ReBAC : quel modèle choisir (6 occurrences)
- Prévenir les BOLA dans une API métier (3 occurrences)
- RGPD : exigences d’architecture et contrôles techniques (2 occurrences)