Filtrer les données de table sensibles à l’aide de filtres de lignes et de masques de colonne

Article
11/07/2024

Cet article fournit des conseils et des exemples d’utilisation de filtres de lignes, de masques de colonne et de tables de mappage pour filtrer les données sensibles dans vos tables. Ces fonctionnalités nécessitent Unity Catalog.

Qu’est-ce que les filtres de lignes ?

Les filtres de lignes vous permettent d’appliquer un filtre à une table afin que les requêtes retournent seulement les lignes qui correspondent aux critères du filtre. Vous implémentez un filtre de lignes en tant que fonction SQL définie par l’utilisateur. Les fonctions Python et Scala définies par l’utilisateur sont également prises en charge, mais seulement quand elles sont encapsulées dans des fonctions SQL définies par l’utilisateur.

Qu’est-ce que les masques de colonne ?

Les masques de colonne vous permettent d’appliquer une fonction de masquage à une colonne de table. La fonction de masquage est évaluée au moment de l’exécution de la requête, en remplaçant chaque référence de la colonne cible par les résultats de la fonction de masquage. Pour la plupart des cas d’usage, les masques de colonne déterminent s’il faut retourner la valeur de colonne d’origine ou la censurer en fonction de l’identité de l’utilisateur appelant. Les masques de colonne sont des expressions écrites en tant que fonctions SQL définies par l’utilisateur, ou en tant que fonctions Python et Scala définies par l’utilisateur, qui sont encapsulées dans des fonctions SQL définies par l’utilisateur.

Une seule fonction de masquage peut être est appliquée à chaque colonne de table. La fonction de masquage prend la valeur non masquée de la colonne comme entrée et retourne la valeur masquée comme résultat. La valeur de retour de la fonction de masquage doit être du même type que la colonne masquée. La fonction de masquage peut également prendre des colonnes supplémentaires en tant que paramètres d’entrée et les utiliser dans sa logique de masquage.

Quelle est la différence entre ces filtres et les vues dynamiques ?

Les vues dynamiques, les filtres de lignes et les masques de colonne vous permettent d’appliquer une logique complexe aux tables et de traiter leurs décisions de filtrage au moment de l’exécution de la requête.

Une vue dynamique est une vue abstraite et en lecture seule d’une ou plusieurs tables sources. L’utilisateur peut accéder à une vue dynamique sans devoir accéder directement aux tables sources. La création d’une vue dynamique définit un nouveau nom de table qui ne doit pas correspondre au nom des tables sources ou d’autres tables et vues présentes dans le même schéma.

En revanche, l’association d’un filtre de lignes ou d’un masque de colonne à une table cible applique la logique correspondante directement à la table elle-même sans introduire de nouveaux noms de table. Les requêtes suivantes peuvent continuer à faire référence directement à la table cible en utilisant son nom d’origine.

Utilisez des vues dynamiques si vous avez besoin d’appliquer une logique de transformation telle que des filtres et des masques aux tables en lecture seule, et s’il est acceptable pour les utilisateurs de faire référence aux vues dynamiques à l’aide de différents noms. Si vous voulez filtrer des données quand vous les partagez en utilisant Delta Sharing, vous devez utiliser des vues dynamiques. Utilisez des filtres de lignes et des masques de colonne si vous souhaitez filtrer ou calculer des expressions sur des données spécifiques, mais fournissez toujours aux utilisateurs l’accès aux tables à l’aide de leurs noms d’origine.

Avant de commencer

Pour ajouter des filtres de lignes et des masques de colonne à des tables, vous devez disposer des éléments suivants :

Un espace de travail activé pour Unity Catalog.
Une fonction inscrite dans Unity Catalog. Il peut s’agir d’une fonction SQL définie par l’utilisateur, ou d’une fonction Python ou Scala définie par l’utilisateur, inscrite dans Unity Catalog et encapsulée dans une fonction SQL définie par l’utilisateur. Pour plus d’informations, consultez Présentation des fonctions définies par l’utilisateur, Clause de masque de colonne et Clause ROW FILTER.

Vous devez aussi satisfaire aux exigences suivantes :

Pour affecter une fonction qui ajoute des filtres de lignes ou des masques de colonne à une table, vous devez disposer du privilège EXECUTE sur la fonction, du privilège USE SCHEMA sur le schéma et du privilège USE CATALOG sur le catalogue parent.
Pour ajouter des filtres ou des masques lorsque vous créez une table, vous devez avoir le privilège CREATE TABLE sur le schéma.
Pour ajouter des filtres ou des masques à une table existante, vous devez également être le propriétaire de la table ou avoir les privilèges MODIFY et SELECT sur la table.

Pour accéder à une table qui a des filtres de lignes ou des masques de colonne, votre ressource de calcul doit répondre à une des exigences suivantes :

Un entrepôt SQL.
Mode d’accès partagé sur Databricks Runtime 12.2 LTS ou une version ultérieure.
Mode d’accès utilisateur unique sur Databricks Runtime 15.4 LTS ou version ultérieure.

Vous ne pouvez pas lire les filtres de lignes ou les masques de colonne à l’aide du calcul mono-utilisateur sur Databricks Runtime 15.3 ou inférieur.

Pour tirer parti du filtrage des données fourni dans Databricks Runtime 15.4 LTS et les versions ultérieures, vous devez également vérifier que votre espace de travail permet le calcul serverless, car la fonctionnalité de filtrage des données qui prend en charge les filtres de lignes et les masques de colonnes s’exécute sur le calcul serverless. Vous pouvez donc être facturé pour les ressources de calcul serverless lorsque vous utilisez le calcul d’un seul utilisateur pour lire des tables qui utilisent des filtres de lignes ou des masques de colonne. Consultez le contrôle d’accès affiné sur le calcul d’un seul utilisateur.

Appliquer un filtre de lignes

Pour créer un filtre de lignes, vous écrivez une fonction SQL définie par l’utilisateur pour définir la stratégie de filtre, puis vous l’appliquez à une table. Chaque table ne peut avoir qu’un seul filtre de ligne. Un filtre de lignes accepte zéro ou plusieurs paramètres d’entrée où chaque paramètre d’entrée est lié à une colonne de la table correspondante.

Vous pouvez appliquer un filtre de lignes en utilisant des commandes Catalog Explorer ou SQL. Les instructions Catalog Explorer supposent que vous avez déjà créé une fonction et qu’elle est inscrite dans Unity Catalog. Les instructions SQL incluent des exemples de création d’une fonction de filtre de lignes et de son application à une table.

Explorateur de catalogues

Dans votre espace de travail Azure Databricks, cliquez sur Catalogue.
Parcourez ou recherchez la table que vous voulez filtrer.
Sous l’onglet Vue d’ensemble, cliquez sur Filtre de lignes : Ajouter un filtre.
Dans la boîte de dialogue Ajouter un filtre de lignes, sélectionnez le catalogue et le schéma qui contiennent la fonction de filtre, puis sélectionnez la fonction.
Dans la boîte de dialogue développée, affichez la définition de fonction, puis sélectionnez les colonnes de table qui correspondent aux colonnes incluses dans l’instruction de la fonction.
Cliquez sur Ajouter.

Pour supprimer le filtre de la table, cliquez sur fx Filtre de ligne, puis cliquez sur Supprimer.

SQL

Pour créer un filtre de lignes et l’ajouter à une table existante, utilisez CREATE FUNCTION, puis appliquez la fonction en utilisant ALTER TABLE. Vous pouvez également appliquer une fonction quand vous créez une table en utilisant CREATE TABLE.

Créez le filtre de lignes :

CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {filter clause whose output must be a boolean};

Appliquez le filtre de lignes à une table en utilisant un nom de colonne :

ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<column_name>, ...);

Autres exemples de syntaxe :

Appliquez le filtre de ligne à une table à l’aide d’un littéral constant qui correspond à un paramètre de fonction :
```
ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<constant_literal>, ...);
```
Supprimez un filtre de lignes d’une table :
```
ALTER TABLE <table_name> DROP ROW FILTER;
```

Modifiez un filtre de lignes :

Run a DROP FUNCTION statement to drop the existing function, or use CREATE OR REPLACE FUNCTION to replace it.

Supprimer un filtre de ligne :
```
ALTER TABLE <table_name> DROP ROW FILTER;
DROP FUNCTION <function_name>;
```
Remarque

Vous devez exécuter la commande ALTER TABLE ... DROP ROW FILTER avant de supprimer la fonction. Si vous ne le faites pas, la table sera dans un état inaccessible.

Si la table devient inaccessible de cette façon, modifiez la table et supprimez la référence de filtre de ligne orpheline à l’aide de ALTER TABLE <table_name> DROP ROW FILTER;.

Consultez aussi Clause ROW FILTER.

Exemples de filtre de lignes

Cet exemple crée une fonction SQL définie par l’utilisateur qui est appliquée aux membres du groupe admin dans la région US.

Quand cet exemple de fonction est appliqué à la table sales, les membres du groupe admin peuvent accéder à tous les enregistrements de la table. Si la fonction est appelée par un non-administrateur, la condition RETURN_IF échoue et l’expression region='US' est évaluée, en filtrant la table pour afficher uniquement les enregistrements dans la région US.

CREATE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');

Appliquez la fonction à une table en tant que filtre de ligne. Les requêtes suivantes de la table sales retournent ensuite un sous-ensemble de lignes.

CREATE TABLE sales (region STRING, id INT);
ALTER TABLE sales SET ROW FILTER us_filter ON (region);

Désactivez le filtre de ligne. Les futures requêtes utilisateur de la table sales retournent ensuite toutes les lignes de la table.

ALTER TABLE sales DROP ROW FILTER;

Créez une table avec la fonction appliquée en tant que filtre de lignes dans le cadre de l’instruction CREATE TABLE. Les futures requêtes de la table sales retournent ensuite un sous-ensemble de lignes.

CREATE TABLE sales (region STRING, id INT)
WITH ROW FILTER us_filter ON (region);

Appliquer un masque de colonne

Pour appliquer un masque de colonne, créez une fonction (UDF), puis appliquez-la à une colonne de table.

Vous pouvez appliquer un masque de colonne en utilisant des commandes Catalog Explorer ou SQL. Les instructions Catalog Explorer supposent que vous avez déjà créé une fonction et qu’elle est inscrite dans Unity Catalog. Les instructions SQL incluent des exemples de création d’un masque de colonne et de son application à une colonne de table.

Explorateur de catalogues

Dans votre espace de travail Azure Databricks, cliquez sur Catalogue.
Parcourez ou recherchez la table.
Sous l’onglet Vue d’ensemble, recherchez la ligne à laquelle vous voulez appliquer le masque de colonne, puis cliquez sur l’icône de modification Masque.
Dans la boîte de dialogue Ajouter un masque de colonne, sélectionnez le catalogue et le schéma qui contiennent la fonction de filtre, puis sélectionnez la fonction.
Dans la boîte de dialogue développée, affichez la définition de la fonction. Si la fonction inclut des paramètres en plus de la colonne à masquer, sélectionnez les colonnes de table vers lesquelles vous voulez caster ces paramètres de fonction supplémentaires.
Cliquez sur Ajouter.

Pour supprimer le masque de colonne de la table, cliquez sur fx Masque de colonne dans la ligne de la table, puis cliquez sur Supprimer.

SQL

Pour créer un masque de colonne et l’ajouter à une colonne de table existante, utilisez CREATE FUNCTION et appliquez la fonction de masquage en utilisant ALTER TABLE. Vous pouvez également appliquer une fonction quand vous créez une table en utilisant CREATE TABLE.

Vous utilisez SET MASK pour appliquer la fonction de masquage. Dans la clause MASK, vous pouvez utiliser l’une des fonctions d’exécution intégrées d’Azure Databricks ou appeler d’autres fonctions définies par l’utilisateur. Inspecter l’identité de l’utilisateur appelant exécutant la fonction en utilisant current_user( ) ou obtenir les groupes dont il est membre en utilisant is_account_group_member( ) sont des cas d’usage courants. Pour plus d’informations, consultez Clause de masque de colonne et Fonctions intégrées.

Créer un masque de colonne :

CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {expression with the same type as the first parameter};

Appliquez le masque de colonne à une colonne d’une table existante :

ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS <additional_columns>;

Autres exemples de syntaxe :

Appliquez le masque de colonne à une colonne d’une table existante à l’aide d’un littéral constant qui correspond à un paramètre de fonction :
```
ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS (<constant_name>, ...);
```

Supprimer un masque de colonne d’une colonne dans une table :

ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;

Modifier un masque de colonne : appliquez DROP à la fonction existante ou utilisez CREATE OR REPLACE TABLE.
Supprimer un masque de colonne :
```
ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
DROP FUNCTION <function_name>;
```
Remarque

Vous devez exécuter la commande ALTER TABLE avant de supprimer la fonction ou la table sera dans un état inaccessible.

Si la table devient inaccessible de cette façon, modifiez la table et supprimez la référence de masque orpheline à l’aide ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;de .

Exemples de masque de colonne

Dans cet exemple, vous créez une fonction définie par l’utilisateur qui masque la colonne ssn afin que seuls les utilisateurs membres du groupe HumanResourceDept puissent voir les valeurs de cette colonne.

CREATE FUNCTION ssn_mask(ssn STRING)
  RETURN CASE WHEN is_member('HumanResourceDept') THEN ssn ELSE '***-**-****' END;

Appliquez la nouvelle fonction à une table en tant que masque de colonne. Vous pouvez ajouter le masque de colonne au moment de la création de la table ou après.

--Create the `users` table and apply the column mask in a single step:

CREATE TABLE users (
  name STRING,
  ssn STRING MASK ssn_mask);

--Create the `users` table and apply the column mask after:

CREATE TABLE users
  (name STRING, ssn STRING);

ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask;

Les requêtes sur cette table retournent désormais des valeurs de colonne ssn masquées lorsque l’utilisateur qui exécute les requêtes n’est pas membre du groupe HumanResourceDept :

SELECT * FROM users;
  James  ***-**-****

Pour désactiver le masque de colonne afin que les requêtes retournent les valeurs d’origine dans la colonne ssn :

ALTER TABLE users ALTER COLUMN ssn DROP MASK;

Utiliser des tables de mappage pour créer une liste de contrôle d’accès

Pour obtenir une sécurité au niveau des lignes, envisagez de définir une table de mappage (ou une liste de contrôle d’accès). Chaque table de mappage est une table de mappage complète qui encode les lignes de données de la table d’origine accessibles à certains utilisateurs ou groupes. Les tables de mappage sont utiles, car elles offrent une intégration simple à vos tables de faits via des jointures directes.

Cette méthodologie s’avère utile pour répondre à de nombreux cas d’usage avec des exigences personnalisées. Voici quelques exemples :

Imposer des restrictions basées sur l’utilisateur connecté tout en tenant compte de différentes règles pour des groupes d’utilisateurs spécifiques.
Création de hiérarchies complexes, telles que des structures organisationnelles, nécessitant différents ensembles de règles.
Réplication de modèles de sécurité complexes à partir de systèmes sources externes.

En adoptant des tables de mappage de cette façon, vous pouvez résoudre efficacement ces scénarios difficiles et garantir des implémentations de sécurité robustes au niveau des lignes et des colonnes.

Exemples de table de mappage

Utiliser une table de mappage pour vérifier si l’utilisateur actuel se trouve dans une liste :

USE CATALOG main;

Créer une table de mappage :

DROP TABLE IF EXISTS valid_users;

CREATE TABLE valid_users(username string);
INSERT INTO valid_users
VALUES
  ('fred@databricks.com'),
  ('barney@databricks.com');

Créer un nouveau filtre :

Remarque

Tous les filtres s’exécutent avec les droits de définition, à l’exception des fonctions qui vérifient le contexte utilisateur (par exemple, les fonctions CURRENT_USER et IS_MEMBER) qui s’exécutent en tant qu’appelant.

Dans cet exemple, la fonction vérifie si l’utilisateur actuel se trouve dans la valid_users table. Si l’utilisateur est trouvé, la fonction retourne « true ».

DROP FUNCTION IF EXISTS row_filter;

CREATE FUNCTION row_filter()
  RETURN EXISTS(
    SELECT 1 FROM valid_users v
    WHERE v.username = CURRENT_USER()
);

L’exemple ci-dessous applique le filtre de lignes lors de la création de la table. Vous pouvez également ajouter le filtre ultérieurement à l’aide d’une instruction ALTER TABLE. Lorsque vous appliquez à une table entière, utilisez la syntaxe ON (). Pour une ligne spécifique, utilisez ON (row);.

DROP TABLE IF EXISTS data_table;

CREATE TABLE data_table
  (x INT, y INT, z INT)
  WITH ROW FILTER row_filter ON ();

INSERT INTO data_table VALUES
  (1, 2, 3),
  (4, 5, 6),
  (7, 8, 9);

Sélectionnez des données dans la table. Cela ne doit retourner des données que si l’utilisateur se trouve dans la table valid_users.

SELECT * FROM data_table;

Créez une table de mappage comprenant des comptes qui doivent toujours avoir accès à toutes les lignes de la table, quelles que soient les valeurs de colonne :

CREATE TABLE valid_accounts(account string);
INSERT INTO valid_accounts
VALUES
  ('admin'),
  ('cstaff');

Créez maintenant une fonction UDF SQL qui retourne true si les valeurs de toutes les colonnes de la ligne sont inférieures à cinq, ou si l’utilisateur appelant est membre de la table de mappage ci-dessus.

CREATE FUNCTION row_filter_small_values (x INT, y INT, z INT)
  RETURN (x < 5 AND y < 5 AND z < 5)
  OR EXISTS(
    SELECT 1 FROM valid_accounts v
    WHERE IS_ACCOUNT_GROUP_MEMBER(v.account));

Enfin, appliquez la fonction UDF SQL à la table en tant que filtre de ligne :

ALTER TABLE data_table SET ROW FILTER row_filter_small_values ON (x, y, z);

Prise en charge et limitations

Les filtres de lignes et les masques de colonne ne sont pas pris en charge avec toutes les fonctionnalités Azure Databricks ou sur toutes les ressources de calcul. Cette section répertorie les fonctionnalités et limitations prises en charge.

Fonctionnalités et formats pris en charge

Cette liste de fonctionnalités prises en charge n’est pas exhaustive. Certains éléments sont répertoriés parce qu’ils n’ont pas été pris en charge pendant la préversion publique.

Le SQL et les notebooks Databricks pour les charges de travail SQL sont pris en charge.
Les commandes DML exécutées par des utilisateurs avec MODIFY sont prises en charge. Les filtres et les masques sont appliqués aux données lues par des instructions UPDATE et DELETE, et ils ne sont pas appliqués aux données qui sont écrites (y compris INSERTINSERT).
Formats de données pris en charge :
- Delta et Parquet pour les tables managées et externes.
- Plusieurs autres formats de données pour les tables étrangères inscrites dans Unity Catalog en utilisant Lakehouse Federation.
Les paramètres de stratégie peuvent inclure des expressions constantes (chaînes, numériques, intervalles, booléens, nulles).
Les fonctions SQL, Python et Scala définies par l’utilisateur sont prises en charge en tant que fonctions de filtre de lignes ou de masque de colonne dès lors qu’elles sont inscrites dans Unity Catalog. Les fonctions Python et Scala définies par l’utilisateur doivent être encapsulées dans une fonction SQL définie par l’utilisateur.
Vous pouvez créer des vues sur des tables qui référencent des masques de colonne ou des filtres de lignes, mais vous ne pouvez pas ajouter des masques de colonne ou des filtres de lignes à une vue.
Les flux de données de modification Delta Lake sont pris en charge dès lors que le schéma est compatible avec les filtres de lignes et les masques de colonne qui s’appliquent à la table cible.
Les tables étrangères sont prises en charge.
L’échantillonnage de table est pris en charge.
Les instructions MERGE sont prises en charge quand les tables sources, les tables cibles ou les deux utilisent des filtres de lignes et des masques de colonne. Ceci inclut des tables avec des fonctions de filtre de lignes qui contiennent des sous-requêtes simples ; il existe cependant des limitations, listées dans la section qui suit.
Les vues matérialisées Databricks SQL et les tables de streaming Databricks SQL supportent les filtres de ligne et les masques de colonne (Public Preview) :
- Vous pouvez ajouter des filtres de lignes et des masques de colonne à une vue matérialisée Databricks SQL ou une table de diffusion en continu. Cette opération doit être effectuée de manière déclarative lorsque la vue matérialisée ou la table de diffusion en continu est définie. Consultez CREATE MATERIALIZED VIEW ou CREATE STREAMING TABLE.
- Vous pouvez définir des vues matérialisées Databricks SQL ou des tables de diffusion en continu sur des tables qui incluent des filtres de lignes et des masques de colonne.
Les vues matérialisées et les tables de diffusion en continu déclarées et publiées dans Delta Live Tables prennent en charge les filtres de lignes ou les masques de colonne (préversion publique) :
- Vous pouvez ajouter des filtres de lignes et des masques de colonne à une vue matérialisée Delta Live Tables ou une table de diffusion en continu.
- Vous pouvez définir des vues matérialisées Delta Live Tables ou des tables de diffusion en continu sur des tables qui incluent des filtres de lignes et des masques de colonne.
Consultez Publier des tables avec des filtres de lignes et des masques de colonne.

Considérations relatives aux performances

Les filtres de lignes et les masques de colonne offrent des garanties sur la visibilité de vos données en garantissant qu’aucun utilisateur ne peut afficher le contenu des valeurs des tables de base avant le filtrage et les opérations de masquage. Ils sont conçus pour fonctionner correctement en réponse aux requêtes dans les cas d’usage les plus courants. Dans les applications moins fréquentes, où le moteur de requête doit choisir entre optimiser le niveau de performance des requêtes et protéger contre les fuites d’informations à partir des valeurs filtrées/masquées, il prendra toujours la décision la plus sûre au détriment d’un impact sur le niveau de performance des requêtes. Pour réduire cet impact sur le niveau de performance, appliquez les principes suivants :

Utiliser des fonctions de stratégie simples : les fonctions de stratégie avec moins d’expressions fonctionnent généralement 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.
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 seront généralement plus performantes.
Éviter d’ajouter des filtres de lignes avec trop de conjonctions AND : étant donné que chaque table ne prend en charge l’ajout que d’un filtre de lignes au maximum, une approche courante consiste à combiner plusieurs fonctions de stratégie souhaitées avec AND. Toutefois, pour chaque conjonction, les chances d’augmenter la ou les conjonctions incluent des composants mentionnés ailleurs dans cette table qui pourraient avoir un impact sur le niveau de performance (telles que l’utilisation de tables de mappage). Utilisez moins de conjonctions pour améliorer le niveau de performance.
Utiliser des expressions déterministes qui ne peuvent pas lever d’erreurs dans les stratégies 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 pousser les opérations avec ces expressions (telles que les filtres) trop loin dans le plan de requête, afin d’éviter la possibilité d’erreurs telles que « division par zéro » qui révèlent des informations sur les valeurs avant les opérations de filtrage et/ou de masquage. Utilisez des expressions déterministes et qui ne lèvent jamais d’erreurs, telles que try_divide dans cet exemple.
Exécuter des requêtes de test sur votre table pour évaluer le niveau de performance : construisez des requêtes réalistes qui représentent la charge de travail attendue pour votre table avec des filtres de lignes et/ou des masques de colonne et mesurez le niveau de performance. 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.

Limitations

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 à des tables depuis des versions non prises en charge de ces runtimes, aucune donnée n’est retournée.
Delta Sharing ne fonctionne pas avec des masques de sécurité ou de colonne au niveau des lignes.
Vous ne pouvez pas appliquer une sécurité au niveau des lignes ou des masques de colonnes à une vue.
Voyage dans le temps 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 colonne avec des dépendances circulaires jusqu’aux stratégies d’origine ne sont pas prises en charge.
Les clones profonds et les clones superficiels ne sont pas pris en charge.
Les instructions MERGE ne prennent pas en charge les tables avec des stratégies de filtre de lignes qui contiennent des imbrications, des agrégations, des fenêtres, des limites ou des fonctions non déterministes.
Les API Delta Lake ne sont pas prises en charge.

Limitation du calcul d’un seul utilisateur

Vous ne pouvez pas accéder à une table qui a des filtres de lignes ou des masques de colonne à partir d’une ressource de calcul utilisateur unique sur Databricks Runtime 15.3 ou inférieur. Vous pouvez utiliser le mode d’accès utilisateur unique sur Databricks Runtime 15.4 LTS ou version ultérieure, si votre espace de travail est activé pour le calcul serverless. Pour plus d’informations, consultez Contrôle d’accès affiné sur le calcul d’un seul utilisateur.

Partager via

Filtrer les données de table sensibles à l’aide de filtres de lignes et de masques de colonne

Qu’est-ce que les filtres de lignes ?

Qu’est-ce que les masques de colonne ?

Quelle est la différence entre ces filtres et les vues dynamiques ?

Avant de commencer

Appliquer un filtre de lignes

Explorateur de catalogues

SQL

Exemples de filtre de lignes

Appliquer un masque de colonne

Explorateur de catalogues

SQL

Exemples de masque de colonne

Utiliser des tables de mappage pour créer une liste de contrôle d’accès

Exemples de table de mappage

Prise en charge et limitations

Fonctionnalités et formats pris en charge

Considérations relatives aux performances

Limitations

Limitation du calcul d’un seul utilisateur

Commentaires

Ressources supplémentaires