Évaluation des politiques de filtrage de lignes et de masques de colonnes et comportement d'exécution

remarque

Cette page décrit le comportement d'évaluation et d'exécution des politiques de filtrage de lignes et de masquage de colonnes, qui utilisent des UDF et sont appliquées par le Databricks Runtime pendant l'exécution des requêtes. Pour les politiques GRANT (Bêta), consultez les politiques GRANT ABAC pour les modèles (Bêta).

Cette page explique comment les politiques ABAC sont évaluées au moment de la query, notamment :

• Comment sont gérés les conflits entre plusieurs règles
• Fonctionnement de la conversion de type de masque de colonne
• Quelles mesures de protection empêchent l'exposition des données lorsque les tags ou les fonctions dont dépend une politique sont supprimés

Évaluation et application des politiques

Lorsqu'un utilisateur interroge une table, l'évaluation ABAC se déroule en deux étapes : l'évaluation des politiques dans Unity Catalog et l'application des politiques dans le Databricks Runtime.

Différents utilisateurs peuvent voir des résultats différents de la même query, car l'évaluation de la politique dépend de l'identité de l'utilisateur, de ses appartenances à des groupes et des tags sur les données auxquelles il accède. Les modifications apportées à l'appartenance à un groupe ou aux attributions de tags modifient dynamiquement les politiques effectives au moment de la query.

Évaluation des politiques (Unity Catalog)

Unity Catalog effectue les étapes suivantes à l'aide des métadonnées de l'objet sécurisable (par exemple, les attributions de tags régies) et de l'identité et des appartenances aux groupes de l'utilisateur qui effectue la query :

1. Identifie toutes les règles dont la portée couvre la table query.
2. Pour chacune de ces politiques, vérifie si l'utilisateur qui effectue la requête se trouve dans la liste TO et non dans la liste EXCEPT.
3. Pour chaque politique, évalue les conditions de table et de colonne par rapport aux tags sur l'objet interrogé, y compris les tags hérités. Les conditions de colonne doivent correspondre à au moins une colonne.
4. Si la politique s'applique, elle détermine le filtre de ligne ou le masque de colonne effectif et l'envoie au Databricks Runtime dans le cadre des métadonnées de la table.

Application des stratégies (Databricks Runtime)

Le planificateur de query Databricks Runtime traduit le filtre de ligne ou le masque de colonne effectif en une vue sécurisée au-dessus des analyses de table qui appliquent le filtrage et le masquage pendant l'exécution de la query. Il s’agit du même mécanisme d’application utilisé pour les filtres de lignes et les masques de colonnes au niveau de la table.

Conception à sécurité intégrée

ABAC suit un modèle de sécurité fermé par default, où Databricks refuse l'accès s'il ne peut pas vérifier la sécurité. Databricks n'autorise l'accès aux tables sécurisées par ABAC que s'il peut appliquer en toute sécurité toutes les politiques applicables. Cela s'applique aux versions de compute non prises en charge, aux Opérations spécifiques sur les données de table sous-jacentes et aux situations où les dépendances (tags ou fonctions) d'une politique ont été supprimées.

Versions de compute non prises en charge

Les politiques ABAC nécessitent Databricks Runtime 16.4 ou une version ultérieure, ou un Serverless compute. Si un utilisateur tente d'accéder à une table sécurisée par ABAC à partir d'une version non prise en charge, la requête échoue en mode fermé (l'accès est refusé) afin d'éviter l'exposition de données non protégées.

En mode d'accès dédié, Databricks délègue l'application au compute serverless pour garantir que les contrôles d'accès précis sont appliqués. Pour permettre aux utilisateurs sur d'anciens runtimes d'accéder à ces tables, vous devez les exempter explicitement des politiques.

Opérations non prises en charge sur les données protégées

Certaines opérations sont incompatibles avec les filtres de ligne ou les masques de colonne. Ces opérations échouent plutôt que de contourner l'application. Pour les exécuter, le principal doit être répertorié dans la clause EXCEPT de chaque politique ABAC qui s'applique à la table. Les principaux exemptés ne sont pas soumis à la politique, donc Databricks n'a pas besoin de l'appliquer et peut autoriser l'opération en toute sécurité.

Les Opérations qui exigent que le mandant exécutant soit exempté incluent les refreshs de pipeline, les processus de sauvegarde et les workflows administratifs tels que les suivants :

• Accès aux tables sécurisées par ABAC à partir de compute exécutant des versions de Databricks Runtime antérieures à 16.4
• Requêtes Time travel
• Clonage profond et superficiel
• OpenSharing, où le propriétaire du partage doit être exempté de la politique et disposer des autorisations OpenSharing requises. Notez que la politique ne régit pas l'accès du destinataire.
• Création et synchronisation d'index de recherche IA

Pour plus de détails sur ces limitations et d'autres, consultez Exigences, quotas et limitations pour les politiques de filtrage des lignes et de masquage des colonnes.

Dépendances de la politique supprimées

Les politiques ABAC dépendent des tags gouvernés et des UDF. Si l'une de ces dépendances est supprimée alors qu'une politique y fait toujours référence, les queries sur les tables comprises dans la portée de la politique échouent.

Suppression du tag gouverné

Si vous supprimez un tag gouverné que référence une politique ABAC, toutes les queries envers l'objet où la politique est attachée et ses objets enfants échouent avec une erreur INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY. Cela se produit même si l'étiquette n'a pas été appliquée aux tables interrogées.

Lorsqu'une balise gouvernée est supprimée, elle devient une balise non gouvernée. Les restrictions de valeurs autorisées sont supprimées, et toute personne disposant de APPLY TAG peut modifier les valeurs sans le privilège ASSIGN.

attention

L'UI et l'API n'empêchent pas la suppression d'un tag gouverné référencé dans une politique ABAC. Avant de supprimer un tag gouverné, assurez-vous qu'aucune politique ABAC ne s'y réfère.

Pour résoudre l'erreur, restaurez le tag supprimé, ou mettez à jour ou supprimez la politique qui y fait référence. Consultez Créer et gérer les tags gouvernés.

Suppression d'une colonne qui est étiquetée

Databricks empêche la suppression d'une colonne à laquelle un tag gouverné est appliqué. Pour supprimer la colonne, un utilisateur avec ASSIGN sur le tag et APPLY TAG sur l'objet doit d'abord supprimer le tag, puis la colonne peut être supprimée.

Ceci est pertinent pour les pipelines déclaratifs et autres workflows automatisés qui modifient les schémas de table. Si une pipeline tente de supprimer une colonne étiquetée, l'Opérations échoue. Pour débloquer le pipeline, un utilisateur disposant des autorisations de tag requises doit supprimer le tag, exécuter le pipeline pour que la modification de schéma réussisse, puis réappliquer le tag aux colonnes pertinentes. Si le tag n'est pas réappliqué, les queries sur les données échoueront car la politique est toujours applicable mais le tag attendu n'est plus sur l'objet.

Suppression d'une fonction référencée par une politique

Si une UDF référencée par une politique est supprimée alors que la politique est toujours dans le périmètre, les queries sur les tables de ce périmètre échouent avec UC_DEPENDENCY_DOES_NOT_EXIST. Pour résoudre le problème, restaurez la fonction ou mettez à jour la politique pour référencer une UDF différente.

Règles pour les filtres et masques multiples

Un seul filtre de ligne distinct peut être appliqué au moment de la query pour une table et un utilisateur donnés. De même, un seul masque de colonne distinct par colonne peut être résolu à l'exécution pour une colonne et un utilisateur donnés. Ceci évite les résultats ambigus.

Si plusieurs filtres ou masques distincts s'appliquent au même utilisateur et à la même table (ou colonne), Databricks bloque l'accès et renvoie une erreur. Par exemple :

• Un filtre ou un masque au niveau de la table est en conflit avec une stratégie ABAC. Une table ou une colonne qui a déjà un filtre de ligne ou un masque de colonne appliqué manuellement entre en conflit avec tout filtre ou masque défini par l'ABAC sur la même cible.
• La clause USING COLUMNS d'un filtre de ligne fait référence à un alias MATCH COLUMNS qui correspond à plusieurs colonnes. La clause USING COLUMNS transmet les valeurs de colonne à l'UDF. Si un alias MATCH COLUMNS dans la clause USING COLUMNS correspond à plus d'une colonne, le moteur ne peut pas déterminer quelle colonne passer à la UDF, et la query échoue avec une erreur.
• Une colonne masquée est référencée dans la USING COLUMNS clause d’une autre politique. Si une colonne est masquée par une politique, elle ne peut pas être utilisée comme argument d’entrée dans la clause USING COLUMNS d’une autre politique.

Plusieurs stratégies ABAC peuvent coexister pour la même table ou colonne si elles entraînent le même filtre ou masque effectif. Par exemple, deux stratégies qui référencent la même UDF avec les mêmes arguments se résolvent en un même filtre ou masque, et n'entrent pas en conflit.

Dépannage des conflits de politiques

Lorsque Databricks détecte plusieurs filtres ou masques distincts lors de l'évaluation de la politique pour un utilisateur donné, il génère une erreur INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERS ou COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS et bloque l'accès à la table jusqu'à ce que le conflit soit résolu.

Pour diagnostiquer et résoudre :

1. Utilisez SHOW EFFECTIVE POLICIES pour consulter toutes les stratégies qui s'appliquent à la table.
2. Vérifiez INFORMATION_SCHEMA.ROW_FILTERS et INFORMATION_SCHEMA.COLUMN_MASKS pour identifier les filtres de ligne ou les masques de colonne au niveau de la table qui pourraient être en conflit.
3. Vérifiez quelles politiques se chevauchent dans leurs principaux TO/EXCEPT et leurs conditions WHEN/MATCH COLUMNS.
4. Résolu par :
   • Affinage des conditions de politique. Mettez à jour les clauses WHEN ou MATCH COLUMNS pour être plus spécifique afin que les politiques distinctes ciblent différentes tables ou colonnes.
   • Réglage des tags gouvernés. Examinez les affectations de tags sur les colonnes ou les tables qui Trigger des correspondances de politiques inattendues et supprimez-les ou mettez-les à jour.
   • Ajustement des Principals. Mettez à jour les clauses TO/EXCEPT afin que chaque utilisateur soit couvert par au plus une politique par table (pour les filtres de lignes) ou par colonne (pour les masques de colonnes).
   • Restructuration des politiques. Regroupez les politiques qui se chevauchent en une seule politique, ou divisez les politiques générales en politiques distinctes et explicitement ciblées.

Conversion de type automatique pour les masques de colonne.

Databricks convertit automatiquement l'entrée et la sortie des fonctions de masquage de colonne résolues à partir des stratégies ABAC. La valeur de la colonne d'entrée est transtypée pour correspondre au type de paramètre de la fonction de masque, et la sortie de la fonction est transtypée pour correspondre au type de données de la colonne cible. Cela garantit la cohérence des types et un comportement de query fiable lors du masquage des colonnes. Le transtypage automatique fonctionne comme suit :

1. Exécution de la fonction de masquage : Lorsque l'évaluation de la politique détermine que le masquage s'applique, la fonction de masquage s'exécute sur les valeurs de colonne correspondantes.
2. Conversion de type automatique : Databricks convertit la valeur de la colonne d’entrée pour qu’elle corresponde au type de parameter de la fonction, et convertit la sortie de la fonction pour qu’elle corresponde au type de données de la colonne cible.
3. Retour du résultat : Le résultat correctement typé est renvoyé à la query.

Si les types d'entrée ou de sortie ne sont pas compatibles, le cast échoue et la query renvoie une erreur d'exécution. Le cast suit les standards ANSI SQL pour les opérations CAST (détails de compatibilité complète), avec une addition : sur Databricks Runtime 18,1 et supérieur, les politiques de masque de colonne ABAC peuvent caster des structs en VARIANT, ce qui n'est pas pris en charge en SQL général.

Vous devez vous assurer que les fonctions de masque retournent des types compatibles avec les colonnes cibles. Consultez Fonctions de masquage compatibles avec le transtypage pour des exemples et l'approche VARIANT pour un masquage flexible des différents types de colonnes.