Évaluation de la stratégie et comportement d’exécution

Cette page explique comment les stratégies ABAC sont évaluées au moment de la requête, notamment :

• Comment les conflits entre plusieurs stratégies sont gérés
• Fonctionnement de la conversion de type pour le masque de colonne
• Quelles mesures de protection empêchent l’exposition des données lorsque des étiquettes ou des fonctions dont dépend une stratégie sont supprimées

Évaluation et application des stratégies

Lorsqu’un utilisateur interroge une table, l’évaluation ABAC se poursuit en deux étapes : l’évaluation de la stratégie dans le catalogue Unity et l’application de la stratégie dans databricks Runtime.

Différents utilisateurs peuvent voir des résultats différents de la même requête, car l’évaluation de la stratégie dépend de l’identité de l’utilisateur, des appartenances aux groupes et des balises sur les données auxquels ils accèdent. Les modifications apportées à l’appartenance au groupe ou aux affectations d’étiquettes modifient dynamiquement les stratégies effectives au moment de la requête.

Évaluation de la stratégie (catalogue Unity)

Unity Catalog effectue les étapes suivantes à l’aide des métadonnées de sécurisation (par exemple, les attributions de balises régies) ainsi que de l’identité et des appartenances aux groupes de l’utilisateur effectuant la requête :

1. Identifie toutes les stratégies dont l’étendue couvre la table interrogée.
2. Pour chacune de ces stratégies, vérifiez si l’utilisateur effectuant la requête se trouve dans la TO liste et non dans la EXCEPT liste.
3. Pour chaque stratégie, évalue les conditions de table et de colonne par rapport aux balises sur l’objet interrogé, y compris les balises héritées. Les conditions de colonne doivent correspondre à au moins une colonne.
4. Si la stratégie s’applique, détermine le filtre de lignes ou le masque de colonne effectif et l’envoie au Runtime Databricks dans le cadre des métadonnées de la table.

Application de la stratégie (Databricks Runtime)

Le planificateur de requêtes Databricks Runtime traduit le filtre de lignes ou le masque de colonne effectif en vue sécurisée en plus des analyses de table qui appliquent le filtrage et le masquage pendant l’exécution de la requête. Il s’agit du même mécanisme d’application que celui utilisé pour les filtres de lignes de niveau table et les masques de colonne.

Conception par défaut de fermeture

ABAC suit un modèle de fermeture en cas d'échec, où Azure Databricks a pour défaut de refuser l'accès s'il ne peut pas vérifier la sécurité. Azure Databricks autorise uniquement l’accès aux tables sécurisées par ABAC lorsqu’elle peut appliquer en toute sécurité toutes les stratégies applicables. Cela s’applique aux versions de calcul non prises en charge, aux opérations spécifiques sur les données de table sous-jacentes et aux situations où les dépendances d’une stratégie (balises ou fonctions) ont été supprimées.

Versions de calcul non prises en charge

Les stratégies ABAC nécessitent Databricks Runtime 16.4 ou version ultérieure, ou un calcul sans serveur. 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 (l’accès est refusé) pour empêcher l’exposition des données non protégées.

Sur le mode d’accès dédié, Azure Databricks délègue l’application au calcul sans serveur pour garantir que les contrôles d’accès granulaires sont appliqués. Pour permettre aux utilisateurs sur des environnements d'exécution plus anciens 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 lignes ou les masques de colonne. Ces opérations échouent plutôt que de contourner l'application des règles. Pour les exécuter, le principal doit être répertorié dans la EXCEPT clause de chaque politique ABAC qui s’applique à la table. Les principaux exemptés ne sont pas soumis à la stratégie. Par conséquent, Azure Databricks n’a pas besoin de l’appliquer et peut autoriser l’opération en toute sécurité.

Les opérations qui nécessitent l’exemption du principal en cours d’exécution incluent les actualisations de pipeline, les processus de sauvegarde et les flux de travail administratifs tels que les suivants :

• Accès aux tables sécurisées par ABAC à partir du calcul exécutant les versions databricks Runtime inférieures à 16.4
• Requêtes de voyage dans le temps
• Clonage profond et peu profond
• Partage Delta, où le propriétaire du partage doit être dispensé de la politique et disposer des autorisations requises pour le partage Delta. Notez que la stratégie ne régit pas l’accès du destinataire.
• Création et synchronisation d’index de recherche vectorielle

Pour plus d’informations sur ces limitations et d’autres limitations, consultez les exigences, quotas et limitations ABAC.

Suppression des dépendances de stratégie

Les stratégies ABAC dépendent des balises régies et des fonctions définies par l’utilisateur. Si l’une de ces dépendances est supprimée alors qu’une stratégie les référence toujours, les requêtes sur les tables couvertes par la portée de cette stratégie échouent.

Suppression de balise réglementée

Si vous supprimez une balise régie qui est référencée par une stratégie ABAC, toutes les requêtes sur l'objet auquel la stratégie est attachée et ses objets enfants échouent par une erreur INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY. Cela se produit même si la balise n’a pas été appliquée aux tables interrogées.

Lorsqu’une balise régie est supprimée, elle devient une balise non gérée. Les restrictions de valeur autorisées sont supprimées, et toute personne avec APPLY TAG peut modifier des valeurs sans le privilège ASSIGN.

Pour résoudre l’erreur, restaurez la balise supprimée, ou mettez à jour ou supprimez la stratégie qui le référence. Consultez Créer et gérer des balises régies.

Suppression d’une colonne marquée

Azure Databricks empêche la suppression d’une colonne qui a une balise régie appliquée. Pour supprimer la colonne, un utilisateur disposant ASSIGN de la balise et APPLY TAG de l’objet doit d’abord supprimer la balise, puis la colonne peut être supprimée.

Cela s’applique aux pipelines déclaratifs et à d’autres flux de travail automatisés qui modifient les schémas de table. Si un pipeline tente de supprimer une colonne marquée, l’opération échoue. Pour débloquer le pipeline, un utilisateur disposant des autorisations d’étiquette requises doit supprimer la balise, exécuter le pipeline afin que la modification du schéma réussisse, puis réapplique la balise aux colonnes pertinentes. Si la balise n'est pas réappliquée, les requêtes sur les données échoueront, car la stratégie est toujours en vigueur, mais la balise attendue n'est plus présente sur l'objet.

Suppression de la fonction référencée par la stratégie

Si une UDF référencée par une stratégie est supprimée alors que la stratégie est toujours dans l’étendue, les requêtes sur les tables de cette étendue échouent avec UC_DEPENDENCY_DOES_NOT_EXIST. Pour résoudre ce problème, restaurez la fonction ou mettez à jour la politique pour référencer une autre UDF.

Règles pour plusieurs filtres et masques

Un seul filtre de lignes distinct peut être appliqué au moment de la requête pour une table et un utilisateur donnés. De même, un seul masque de colonne distinct par colonne peut être résolu au moment de l’exécution pour une colonne et un utilisateur donnés. Cela empêche les résultats ambigus.

Si plusieurs filtres ou masques distincts s’appliquent au même utilisateur et à la même table (ou colonne), Azure Databricks bloque l’accès et retourne 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 possède déjà un filtre de lignes ou un masque de colonne appliqué manuellement est en conflit avec tout filtre ou masque défini par ABAC sur la même cible.
• La clause d'un filtre de lignes USING COLUMNS fait référence à un alias MATCH COLUMNS correspondant à plusieurs colonnes. La USING COLUMNS clause transmet les valeurs de colonne à la fonction UDF. Si un MATCH COLUMNS alias dans la USING COLUMNS clause correspond à plusieurs colonnes, le moteur ne peut pas déterminer la colonne à transmettre à la fonction UDF et la requête échoue avec une erreur.
• Une colonne masquée est référencée dans la USING COLUMNS clause d’une autre stratégie. Si une colonne est masquée par une stratégie, elle ne peut pas être utilisée comme argument d’entrée dans la USING COLUMNS clause d’une autre stratégie.

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 politiques qui référencent la même fonction UDF avec les mêmes arguments se résolvent en le même filtre ou masque et ne sont pas en conflit.

Résolution des conflits de stratégie

Lorsque Azure Databricks détecte plusieurs filtres ou masques distincts lors de l’évaluation de stratégie pour un utilisateur donné, il lève 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 le problème :

1. Utilisez SHOW EFFECTIVE POLICIES pour voir toutes les politiques qui s'appliquent à la table.
2. Vérifiez INFORMATION_SCHEMA.ROW_FILTERS et identifiez INFORMATION_SCHEMA.COLUMN_MASKS les filtres de ligne au niveau de la table ou les masques de colonne qui peuvent entrer en conflit.
3. Vérifiez les stratégies qui se chevauchent dans leurs TO/EXCEPT principaux et WHEN/MATCH COLUMNS conditions.
4. Résoudre par :
   • Affinement des conditions de politique. Mettre à jour WHEN ou MATCH COLUMNS clauses pour être plus spécifiques afin que les stratégies distinctes ciblent différentes tables ou colonnes.
   • Ajustement des balises régies. Passez en revue les affectations de balises sur des colonnes ou des tables qui déclenchent des correspondances de stratégie involontaires et les supprimez ou les mettez à jour.
   • Ajustement des éléments principaux. Mettez à jour les clauses TO/EXCEPT afin que chaque utilisateur soit couvert par au plus une stratégie par table (pour les filtres de lignes) ou par colonne (pour les masques de colonne).
   • Politiques de restructuration. Consolidez les stratégies qui se chevauchent en une seule stratégie ou fractionnez les stratégies générales en stratégies distinctes, explicitement ciblées.

Conversion automatique des types pour les masques de colonne

Azure Databricks convertit automatiquement les entrées et sorties des fonctions de masquage de colonnes issues des politiques ABAC. La valeur de colonne d’entrée est castée pour correspondre au type de paramètre de la fonction mask, et la sortie de la fonction est castée pour correspondre au type de données de la colonne cible. Cela garantit la cohérence des types et le comportement de requête fiable lors du masquage des colonnes. La conversion automatique fonctionne comme suit :

1. Exécution de la fonction de masquage : lorsque l’évaluation de la stratégie 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 : Azure Databricks convertit la valeur de la colonne d'entrée afin de correspondre au type de paramètre de la fonction et convertit la sortie de la fonction afin de correspondre au type de données de la colonne cible.
3. Retour de résultat : le résultat correctement typé est retourné à la requête.

Si les types d’entrée ou de sortie ne sont pas compatibles, le cast échoue et la requête retourne une erreur d’exécution. Le casting suit les normes ANSI SQL pour les opérations CAST (détails de compatibilité complète), avec un ajout : à partir de Databricks Runtime 18.1 et versions ultérieures, les politiques de masque de colonne ABAC permettent la conversion de structures en VARIANT, ce qui n'est généralement pas pris en charge dans SQL standard.

Vous devez vérifier que les fonctions de masque retournent des types compatibles avec les colonnes cibles. Consultez les fonctions de masquage compatibles avec Cast pour obtenir des exemples et l’approche VARIANT pour un masquage flexible selon les types de colonnes.