Qu'est-ce que la sécurité au niveau des lignes ?

La sécurité au niveau des lignes (RLS) est un contrôle d'accès aux bases de données qui limite les lignes d'une table qu'un utilisateur peut lire ou modifier en fonction de son identité, de son rôle ou du contexte de sa session.

Au lieu de restreindre l'accès à des tables entières ou à des colonnes spécifiques, la RLS filtre les données ligne par ligne. Le moteur de base de données applique automatiquement le filtre au moment de la requête, de sorte que la même règle s'applique quel que soit l'outil utilisé par l'utilisateur pour accéder aux données.

La RLS fait partie du contrôle d'accès de précision, aux côtés de :

• La sécurité au niveau des colonnes
• Le masquage des données
• Les autorisations au niveau de la table

Par exemple, un commercial peut interroger la table des commandes de l'entreprise mais ne voir que les commandes de la région qui lui est attribuée, même si la table contient les données de toutes les régions. L'utilisateur écrit une instruction SELECT normale, et le moteur ne renvoie que les lignes qu'il est autorisé à voir.

La RLS est désormais un élément fondamental pour le SaaS multi-tenant, la ségrégation régionale des données et les cas d'usage de conformité. Cet article explique comment fonctionne la RLS, ses avantages, ses limites et son fonctionnement sur la plateforme Databricks.

Comment fonctionne la sécurité au niveau des lignes ?

La sécurité au niveau des lignes fonctionne en appliquant une règle de filtrage, souvent appelée politique ou prédicat, à une table. Lorsqu'un utilisateur exécute une requête, le moteur de base de données applique automatiquement ce filtre et ne renvoie que les lignes que l'utilisateur est autorisé à voir.

En pratique, la RLS fonctionne généralement en trois étapes :

1. L'utilisateur exécute une requête : L'utilisateur écrit une requête standard sans ajouter lui-même de filtres de sécurité.
2. La base de données vérifie l'identité de l'utilisateur : Le moteur évalue l'utilisateur à l'aide d'une fonction intégrée telle que CURRENT_USER, d'une variable de session définie par l'application ou d'une table de correspondance qui associe les utilisateurs et les groupes aux données autorisées.
3. Le moteur filtre le résultat : Le prédicat RLS renvoie TRUE pour les lignes que l'utilisateur peut voir et FALSE pour tout le reste. Seules les lignes qui passent le prédicat sont renvoyées.

Comme l'application se fait au niveau de la base de données, la même règle s'applique de manière cohérente à tous les chemins d'accès, y compris les tableaux de bord BI, les notebooks, le SQL ad-hoc, les API et les outils tiers. C'est cette cohérence qui fait la force de la RLS : une seule règle, appliquée partout, imposée par le moteur.

La plupart des moteurs font également la distinction entre l'application en lecture et en écriture. Un prédicat de lecture contrôle ce qu'une requête SELECT renvoie. Un prédicat d'écriture, souvent défini séparément avec une clause WITH CHECK, contrôle les lignes qu'un utilisateur peut insérer, mettre à jour ou supprimer.

Les deux prédicats peuvent être identiques, mais ce n'est pas obligatoire. For exemple, un utilisateur peut être autorisé à lire les lignes de toutes les régions, mais ne peut insérer des lignes que pour sa propre région. Il est important de définir les deux aspects lorsqu'une table accepte des écritures, car l'omission de la vérification d'écriture est l'une des erreurs de configuration de la RLS les plus courantes en production.

Sécurité au niveau des lignes vs sécurité au niveau des colonnes et autres contrôles d'accès

La RLS est l'un des nombreux contrôles d'accès fins, et en production, elle est presque toujours associée à d'autres. Le tableau ci-dessous montre comment chaque contrôle s'intègre.

Ces contrôles sont conçus pour se superposer. Une configuration typique utilise des autorisations au niveau de la table pour contrôler qui peut y accéder, la RLS pour définir les lignes visibles, et la sécurité au niveau des colonnes ou le masquage des données pour protéger les champs sensibles au sein de ces lignes. Le fait de les traiter comme une pile plutôt que comme un menu d'alternatives rend la gouvernance à la fois auditable et résiliente. Une mauvaise configuration dans une couche ne compromet pas les autres.

Cas d'usage courants de la sécurité au niveau des lignes

La RLS est le moyen standard d'imposer qui peut voir quoi dans une table partagée, en filtrant les lignes en fonction des attributs d'un utilisateur par rapport à une colonne clé telle que la région, le tenant ou la classification. La plupart des équipes y ont recours lorsqu'un même jeu de données doit servir plusieurs publics ayant des règles de visibilité différentes.

• SaaS multi-tenant : Isolez les données de chaque client dans des tables partagées à l'aide d'une colonne tenant_id et du contexte de session. Cela évite le coût opérationnel d'un schéma ou d'une base de données par tenant tout en maintenant les données de chaque client entièrement séparées au moment de la requête.
• Ségrégation régionale : Restreignez les données de ventes, de RH ou de commandes afin que les utilisateurs ne voient que les enregistrements de leur pays ou région, sans diviser la table sous-jacente par zone géographique.
• Accès par département : Donnez aux équipes de finance, de marketing et d'opérations l'accès à la même table mais à des lignes différentes, mappées par une colonne de département ou de centre de coûts.
• Conformité réglementaire : Appliquez les règles de résidence des données, par exemple en limitant la visibilité des enregistrements de l'UE au seul personnel basé dans l'UE en vertu du GDPR, ou en restreignant les catégories protégées en vertu de HIPAA, CCPA ou de réglementations sectorielles spécifiques.
• Données de santé et cliniques : Permettez aux cliniciens de partager une table de patients tout en ne voyant que leurs propres patients, prenant ainsi en charge l'accès minimal nécessaire requis par HIPAA sans dupliquer les enregistrements dans des silos.
• Portails partenaires et fournisseurs : Partagez un jeu de données unique entre des partenaires externes tout en filtrant chacun sur ses propres enregistrements, afin qu'une seule table de référence puisse alimenter des dizaines de vues destinées aux partenaires.

Comment implémenter la sécurité au niveau des lignes : 4 étapes

Le modèle général est cohérent sur toutes les plateformes, la syntaxe spécifique au fournisseur étant intégrée là où c'est nécessaire.

1. Identifier la logique de filtrage : Décidez de ce qui détermine l'accès : l'ID utilisateur, l'appartenance à un groupe, la région, l'ID du tenant ou une table de correspondance. La logique de filtrage doit pouvoir être dérivée du contexte de session ou d'une recherche stable, et non de valeurs que l'utilisateur contrôle au moment de la requête.
2. Ajouter ou confirmer la colonne clé : Assurez-vous que la table possède une colonne que le filtre peut utiliser, telle que tenant_id, region ou owner_id. Si aucune colonne de ce type n'existe encore, prévoyez un backfill avant la mise en œuvre de la politique, et envisagez d'indexer la colonne pour que le prédicat reste peu coûteux.
3. Définir la politique ou le filtre de ligne : Écrivez le prédicat qui renvoie TRUE pour les lignes que l'utilisateur est autorisé à voir, et une vérification distincte pour les écritures si la table les accepte. Conservez la logique en SQL autant que possible. La plupart des moteurs optimisent mieux les prédicats SQL que les appels de fonction dans d'autres langages.
4. Tester avec plusieurs identités d'utilisateurs : Exécutez des requêtes sous différents rôles et confirmez que les bonnes lignes apparaissent et que rien ne fuite entre les tenants. Incluez un test négatif : un utilisateur sans lignes correspondantes devrait voir un résultat vide, pas une erreur, et un utilisateur privilégié devrait être testé séparément pour confirmer le comportement de contournement du propriétaire.

Avantages de la sécurité au niveau des lignes

Le déplacement de la logique d'accès vers la couche de données s'avère payant de plusieurs manières concrètes. En résumé, la base de données devient la source de vérité pour l'accès, plutôt que chaque application qui touche aux données.

• Logique centralisée : Les règles d'accès résident avec les données, et non éparpillées dans le code de l'application ou les outils BI.
• Application cohérente : La même règle s'applique qu'un utilisateur effectue une requête depuis un notebook, un tableau de bord ou une API.
• Défense en profondeur : La RLS ajoute une deuxième couche de protection si les vérifications au niveau de la couche applicative sont contournées ou comportent des bugs.
• Code d'application plus simple : Les développeurs n'ont pas besoin d'ajouter manuellement des clauses WHERE dans chaque requête.
• Audits plus faciles : Les équipes de conformité peuvent examiner une seule politique au lieu de retracer la logique d'accès à travers différents systèmes.

Limites et risques de la sécurité au niveau des lignes

La RLS est puissante, mais elle comporte des pièges bien connus que les équipes doivent anticiper. La plupart d'entre eux n'apparaissent qu'en production ou lors d'un audit, il est donc utile de les connaître à l'avance.

Contournement par les administrateurs et les propriétaires

Dans de nombreuses bases de données, les propriétaires de tables et les administrateurs disposant de privilèges élevés contournent la RLS par défaut. PostgreSQL, par exemple, nécessite le paramètre FORCE ROW LEVEL SECURITY pour appliquer les politiques au propriétaire de la table, et des paramètres similaires existent dans d'autres moteurs. Il s'agit d'un constat d'audit courant : partez du principe que les utilisateurs privilégiés voient toutes les lignes, à moins que votre configuration ne force explicitement l'application de la politique à leur intention. Testez la politique à partir d'une session privilégiée, et pas seulement d'une session standard, avant de la valider.

Pas de masquage de colonnes ou de résumés

La RLS filtre les lignes, mais elle ne masque pas les colonnes et ne bloque pas les résultats agrégés. Un analyste qui ne peut pas voir les enregistrements individuels de l'EU peut toujours exécuter SELECT COUNT(*) sur la table non filtrée si la RLS n'est pas associée à des restrictions sur les colonnes ou les agrégats. Associez la RLS à la sécurité au niveau des colonnes ou au masquage des données pour combler cette lacune, et demandez-vous si les requêtes d'agrégation elles-mêmes doivent être gouvernées pour les tables les plus sensibles.

Impact sur les performances

Chaque requête se voit appliquer le prédicat RLS, ce qui peut ralentir les performances si la logique de filtrage est complexe ou si la colonne clé n'est pas indexée. Indexez les colonnes auxquelles la politique fait référence et gardez le prédicat aussi simple que possible. Privilégiez des expressions CASE simples plutôt que des sous-requêtes ou des recherches dans des tables de correspondance au sein du filtre. Si le moteur le prend en charge, matérialisez la correspondance utilisateur-lignes dans une petite table bien indexée plutôt que de la calculer à la volée.

Complexité du débogage

Les ensembles de résultats vides générés par la RLS sont identiques à l'absence de données correspondantes. Les développeurs à la recherche d'une ligne manquante passent souvent des heures avant de se rendre compte que la politique l'a filtrée. Enregistrez l'identité de l'utilisateur effectif et la version de la politique pendant le développement, donnez aux ingénieurs un moyen de vérifier si la RLS est active lorsque les résultats semblent incorrects, et documentez la politique au même endroit que le schéma de la table pour qu'elle soit facile à trouver.

Règles d'écriture mal configurées

Les politiques RLS ont souvent deux volets : une clause USING qui filtre ce que les utilisateurs peuvent lire et une clause WITH CHECK qui contrôle ce qu'ils peuvent insérer ou mettre à jour. Définir l'un sans l'autre est une erreur classique : un filtrage en lecture sans contrôle d'écriture permet aux utilisateurs d'insérer ou de mettre à jour des lignes dont ils ne devraient pas être propriétaires. Définissez toujours les deux volets lorsque la table accepte des écritures, et effectuez un test côté écriture dans le cadre de la révision de la politique.

La sécurité au niveau des lignes sur la plateforme Databricks

Sur la plateforme Databricks, la sécurité au niveau des lignes est gérée par des filtres de lignes dans Unity Catalog, la couche de gouvernance unifiée de Databricks pour les données et l'IA. Le fonctionnement est simple : définissez une fonction SQL personnalisée (UDF) qui renvoie « true » pour les lignes qu'un utilisateur donné est autorisé à voir, puis associez-la à la table cible. Le filtre s'exécute automatiquement au moment de la requête, en utilisant l'identité de l'utilisateur actuel ou le contexte de la session pour déterminer les lignes à renvoyer.

Les filtres de lignes sont appliqués de manière cohérente dans Databricks SQL, les notebooks, les jobs et les outils de BI connectés, sans qu'aucune logique personnalisée ne soit requise par interface. Ils fonctionnent en parallèle avec les masques de colonnes pour un contrôle d'accès complet et précis, et chaque requête qui touche une table filtrée est capturée dans les journaux d'audit et de lignage d'Unity Catalog, de sorte que les équipes de gouvernance et de sécurité peuvent voir exactement quelles politiques s'appliquent à quelles tables et quels utilisateurs ont effectué quelles requêtes.

Foire aux questions

Qu'est-ce que la sécurité dynamique au niveau des lignes ? La RLS dynamique évalue la règle d'accès au moment de la requête en utilisant l'identité de l'utilisateur actuel ou le contexte de la session, de sorte que la même politique renvoie des résultats différents pour différents utilisateurs. Toutes les implémentations modernes de la RLS fonctionnent de cette manière, y compris les politiques ABAC, les filtres de lignes et les vues dynamiques de Databricks.

Quelle est la différence entre la sécurité au niveau des lignes et la sécurité au niveau des colonnes ? La RLS restreint les lignes qu'un utilisateur peut voir ; la sécurité au niveau des colonnes restreint les colonnes, généralement pour masquer des champs sensibles comme le salaire ou les numéros de sécurité sociale. La plupart des déploiements en production utilisent les deux conjointement.

La sécurité au niveau des lignes suffit-elle à elle seule à sécuriser les données sensibles ? Non. La RLS gère la visibilité des lignes mais ne masque pas les valeurs des colonnes, ne bloque pas les requêtes d'agrégation et ne remplace pas la gestion des identités et des accès. Associez-la à la sécurité au niveau des colonnes, aux autorisations au niveau des tables et aux journaux d'audit dans le cadre d'une stratégie de défense en profondeur.

Comment Databricks implémente-t-il la sécurité au niveau des lignes ? Via Unity Catalog, avec trois options : les politiques ABAC, les filtres de lignes au niveau des tables et les vues dynamiques. L'ABAC est recommandé pour la gouvernance à grande échelle ; les filtres de lignes et les vues dynamiques sont disponibles pour des besoins plus spécifiques.

La sécurité au niveau des lignes affecte-t-elle les performances des requêtes ? Oui, mais l'impact est généralement gérable. Gardez la logique de la politique simple, indexez les colonnes auxquelles la politique fait référence et préférez les UDF SQL aux UDF Python. Analysez le profil des requêtes avant et après les modifications de politique pour détecter rapidement les régressions.

Démarrez avec le contrôle d'accès précis sur Databricks

La sécurité au niveau des lignes est plus efficace lorsqu'elle s'intègre dans un modèle de gouvernance plus large qui couvre également les colonnes, le masquage, le lignage et l'audit. Découvrez comment Unity Catalog réunit la sécurité au niveau des lignes, le masquage des colonnes et la gouvernance unifiée sur la plateforme Databricks.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original