Filtres de lignes et masques de colonne

Cette page fournit des conseils sur l’utilisation de filtres de lignes et de masques de colonne pour filtrer les données sensibles dans vos tables.

Qu’est-ce que les filtres de lignes ?

Les filtres de lignes vous permettent de contrôler les lignes auxquelles un utilisateur peut accéder dans une table en fonction de la logique personnalisée. Au moment de la requête, un filtre de lignes évalue une condition et retourne uniquement les lignes qui le répondent. Cela est couramment utilisé pour implémenter la sécurité au niveau des lignes, par exemple, en limitant les utilisateurs aux enregistrements d’une région, d’un service ou d’un compte spécifique.

Les filtres de lignes sont définis en tant que fonctions définies par l’utilisateur SQL et peuvent également incorporer la logique Python ou Scala lorsqu’ils sont encapsulés dans une fonction UDF SQL. Vous pouvez appliquer des filtres de lignes par table ou de manière centralisée via des stratégies ABAC à l’aide de balises régies.

Qu’est-ce que les masques de colonne ?

Les masques de colonne contrôlent les valeurs que les utilisateurs voient dans des colonnes spécifiques, en fonction de leur personne. Au moment de la requête, le masque remplace chaque référence à une colonne par le résultat d’une fonction de masquage. Cela permet aux données sensibles, telles que les SSN ou les e-mails, d’être régérées ou transformées en fonction de l’identité ou du rôle de l’utilisateur.

Chaque colonne peut avoir un masque. Le masque doit être défini comme une fonction UDF SQL qui retourne une valeur du même type que la colonne masquée. La fonction UDF SQL peut éventuellement appeler Python ou Scala UDFs pour implémenter une logique de masquage complexe. Les masques de colonne peuvent également prendre d’autres colonnes comme entrées, par exemple, pour varier le comportement en fonction de plusieurs attributs.

Comme les filtres de lignes, les masques de colonne peuvent être appliqués par table ou gérés de manière centralisée via des stratégies ABAC. Ils fonctionnent au moment de la requête et s’intègrent en toute transparence à sql, notebooks et tableaux de bord standard.

Quand devez-vous utiliser des vues dynamiques et des filtres et des masques ?

Les vues dynamiques, les filtres de lignes et les masques de colonne vous permettent d’appliquer une logique de filtrage ou de transformation au moment de la requête, mais elles diffèrent dans la façon dont elles sont gérées, étendues et exposées aux utilisateurs.

• Utilisez des vues dynamiques lorsque vous avez besoin d’une couche en lecture seule sur une ou plusieurs tables sources, en particulier pour le partage de données ou l’application d’une logique entre plusieurs entrées.
• Utilisez des filtres de lignes et des masques de colonne lorsque vous souhaitez appliquer une logique directement à une table, sans modifier le nom de la table ou introduire de nouveaux objets. Ils peuvent être gérés à l’aide de stratégies ABAC (recommandées) ou manuellement sur des tables.

Pour obtenir une comparaison complète, consultez les méthodes de contrôle d’accès comparées.

Comment appliquer des filtres et des masques

Vous pouvez implémenter des filtres de lignes et des masques de colonne de deux façons principales :

• Utilisation de stratégies ABAC (préversion publique) : appliquez des filtres et des masques de manière centralisée à l’aide de balises régies et de stratégies réutilisables. Cette approche est mise à l’échelle entre les catalogues et les schémas et réduit la nécessité d’une configuration table par table. Les stratégies ABAC sont plus sécurisées que les stratégies manuelles au niveau de la table, car elles peuvent être définies par des administrateurs de niveau supérieur et ne peuvent pas être remplacées par les propriétaires de tables, ce qui permet d’appliquer des contrôles d’accès centralisés. Ils sont également plus performants dans de nombreux cas, car le filtrage et la logique de masquage dans les stratégies ABAC sont évalués plus efficacement que dans les fonctions définies par l’utilisateur spécifiques à la table. Databricks recommande d’utiliser ABAC pour la plupart des cas d’usage. Pour appliquer des filtres et des masques à l’aide d’ABAC, consultez le contrôle d’accès basé sur les attributs du catalogue Unity (ABAC).

• Affectation manuelle par table : appliquez des filtres et des masques en affectant directement des fonctions à des tables et colonnes individuelles. Cette méthode peut utiliser des tables de mappage ou une autre logique personnalisée. Il permet un contrôle précis et spécifique à la table, mais est plus difficile à mettre à l’échelle et à maintenir. Pour plus d’informations, consultez Appliquer manuellement des filtres de lignes et des masques de colonne.

recommandations en matière de performances

Les filtres de lignes et les masques de colonne contrôlent la visibilité des données en garantissant que les utilisateurs ne peuvent pas afficher le contenu des valeurs des tables de base avant de filtrer et de masquer les opérations. Ils fonctionnent correctement en réponse aux requêtes dans des cas d’usage courants. Dans les applications moins courantes, où le moteur de requête doit choisir entre optimiser les performances des requêtes et protéger contre la fuite d’informations à partir des valeurs filtrées/masquées, il prendra toujours la décision sécurisée au détriment d’un impact sur les performances des requêtes. Pour réduire cet impact sur les performances, appliquez les recommandations suivantes :

• Utiliser des fonctions de stratégie simples : fonctions de stratégie avec moins d’expressions fonctionnent souvent mieux que des expressions plus complexes. Évitez d’utiliser des tables de mappage et des sous-requêtes d’expression en faveur de fonctions CASE simples.
• Limitez le nombre de masques de colonne et de fonctions de masquage : Plusieurs masques de colonne uniques sur de grandes tables peuvent nuire aux performances des requêtes. Chaque masque distinct nécessite une évaluation pendant les requêtes, ce qui augmente la surcharge de traitement. Appliquez des masques uniquement aux colonnes qui contiennent des données véritablement sensibles et réutilisez les fonctions de masquage, le cas échéant.
• Réduire le nombre d’arguments de fonction : Azure Databricks ne peut pas optimiser les références de colonne à la table source résultant d’arguments de fonction de stratégie, même si ces colonnes ne sont pas utilisées dans la requête. Utilisez des fonctions de stratégie avec moins d’arguments, car les requêtes de ces tables fonctionnent mieux.
• Évitez d’ajouter des filtres de lignes avec trop de conjoncts AND : Étant donné qu’un seul filtre de lignes distinct peut être résolu au moment de l’exécution pour un utilisateur et une table donnés, une approche commune consiste à combiner plusieurs fonctions de stratégie souhaitées avec AND. Toutefois, avec chaque conjonction supplémentaire, les chances augmentent que ces conjonctions incluent des composants mentionnés ailleurs dans ce tableau, qui pourraient affecter les performances (comme les tables de mappage). Utilisez moins de conjonctions pour améliorer le niveau de performance.
• Utiliser des expressions déterministes qui ne peuvent pas provoquer d’erreurs dans les politiques de table et les requêtes de ces tables : Certaines expressions peuvent lever des erreurs si les entrées fournies ne sont pas valides, telles que la division ANSI. Dans ce cas, le compilateur SQL ne doit pas envoyer (push) les opérations avec ces expressions (telles que les filtres) trop loin dans le plan de requête pour éviter la possibilité d’erreurs telles que « division par zéro » qui révèlent des informations sur les valeurs avant le filtrage et/ou les opérations de masquage. Utilisez des expressions déterministes qui ne lèvent jamais d’erreurs, telles que try_divide.
• Préférez SQL aux fonctions définies par l'utilisateur (UDF) Python : Les fonctions définies par l'utilisateur (UDF) Python sont généralement moins performantes que SQL et offrent moins d'opportunités d'optimisation. Si vous devez utiliser Python, marquez explicitement les fonctions définies par l'utilisateur comme DETERMINISTIC lorsqu'elles n'impliquent pas de logique non déterministe ni de dépendances.
• Exécutez des requêtes de test sur votre table pour évaluer les performances : Créez des requêtes réalistes qui représentent la charge de travail attendue pour votre table avec des filtres de lignes ou des masques de colonne et mesurez les performances. Apportez de petites modifications aux fonctions de stratégie et observez leurs effets jusqu’à atteindre un bon équilibre entre le niveau de performance et l’expressivité de la logique de filtrage et de masquage.

Pour plus de bonnes pratiques et d’exemples de fonctions définies par l’utilisateur, consultez les bonnes pratiques des fonctions définies par l'utilisateur pour les politiques ABAC.

Limites

• Les versions Databricks Runtime inférieures à la version 12.2 LTS ne prennent pas en charge les filtres de lignes ou les masques de colonnes. Ces runtimes échouent de manière sécurisée, ce qui signifie que si vous essayez d’accéder aux tables à partir de ces runtimes, aucune donnée n’est retournée.
• Les fournisseurs de partage Delta ne peuvent pas partager des tables avec une sécurité au niveau des lignes ou des masques de colonnes. Toutefois, les destinataires du partage Delta peuvent appliquer des filtres de lignes et des masques de colonne uniquement aux tables partagées et aux tables étrangères, et non aux tables de diffusion en continu ou aux vues matérialisées.
• Les tables Iceberg managées ne prennent pas en charge les filtres de lignes ou les masques de colonne.
• Vous ne pouvez pas utiliser le catalogue REST Iceberg ou les API REST Unity pour accéder aux tables avec des filtres de lignes ou des masques de colonne.
• Vous ne pouvez pas appliquer une sécurité au niveau des lignes ou des masques de colonnes à une vue.
• Temps de trajet ne fonctionne pas avec des masques de sécurité au niveau des lignes ou des colonnes.
• L’accès basé sur le chemin à des fichiers dans des tables avec des stratégies n’est pas pris en charge.
• Les stratégies de filtre de lignes ou de masque de colonnes avec des dépendances circulaires jusqu’aux stratégies d’origine ne sont pas prises en charge.
• Les filtres de lignes et les masques de colonne ne peuvent pas référencer les tables qui ont également des filtres de lignes actifs ou des masques de colonne. Dans les configurations ABAC, vous pouvez contourner ce problème en excluant le responsable de la fonction de politique de la politique de la table référencée.
• Les clones profonds et superficiels ne sont pas pris en charge sur les tables qui ont une sécurité au niveau des lignes ou des masques de colonne.
• MERGE les instructions ne prennent pas en charge les tables avec des stratégies de filtre de lignes ou de masque de colonne qui contiennent des imbrications, des agrégations, des fenêtres, des limites ou des fonctions non déterministes.
• Les versions databricks Runtime inférieures à la version 17.2 ne prennent pas en charge DELETE, UPDATEet MERGE sur les tables partitionnée avec des stratégies de filtre de ligne ou de masque de colonne définies sur la colonne de partition.
• Les API Delta Lake ne sont pas prises en charge.

Limitation du mode d’accès dédié

Vous ne pouvez pas accéder à une table avec des filtres de lignes ou des masques de colonnes depuis une ressource de calcul d’accès dédié sur Databricks Runtime 15.3 ou antérieur. Vous pouvez utiliser le mode d’accès dédié sur Databricks Runtime 15.4 LTS ou version ultérieure si votre espace de travail est activé pour le calcul serverless. Toutefois, seules les opérations de lecture sont prises en charge sur Databricks Runtime 15.4 à 16.2. Les opérations d’écriture (y compris INSERT, UPDATEet DELETE) nécessitent Databricks Runtime 16.3 ou version ultérieure et doivent utiliser des modèles pris en charge tels que MERGE INTO.

Pour plus d’informations, consultez Contrôle d’accès affiné sur le calcul dédié.