Exigences, quotas et limitations pour les politiques de filtrage de lignes et de masquage de colonnes
Cette page couvre les exigences, les quotas et les limitations pour les politiques de filtre de ligne et de masque de colonne. Pour les politiques GRANT (Bêta), consultez les politiques GRANT ABAC pour les modèles (Bêta).
Cette page répertorie les exigences, les quotas de politiques et les limitations actuelles pour les politiques de filtrage de ligne et de masquage de colonne ABAC dans Unity Catalog.
Exigences en matière de compute
Pour utiliser les politiques ABAC, vous devez utiliser l'une des configurations de compute suivantes :
- Compute serverless
- Compute Standard sur Databricks Runtime 16,4 ou une version ultérieure
- Compute dédié sur Databricks Runtime 16,4 ou version supérieure avec filtrage de contrôle d'accès précis activé
Pour obtenir des conseils sur l'exécution des workloads qui nécessitent des environnements d'exécution plus anciens, consultez Accès depuis des environnements d'exécution plus anciens.
Exigence de tags gouvernés
Les politiques ABAC utilisent des tags gouvernés, et non des tags non gouvernés. Les tags gouvernés sont définis au niveau du compte avec des contrôles d'accès qui déterminent qui peut les créer, les assigner et les gérer. Pour plus de détails, voir Tags gouvernés.
Après avoir attribué ou modifié un tag, la modification peut prendre quelques minutes pour prendre effet.
Quotas de politique
Ressource | Limite |
|---|---|
Stratégies par métastore. | 10 000 |
Stratégies par catalogue ou schéma | 100 |
Politiques par table | 50 |
Principaux par politique (s'applique aux clauses | 20 |
Conditions de colonne par clause | 3 |
Pour plus de détails, y compris les quotas de tags gouvernés, consultez les limites de service.
Limites d'ABAC
Accès depuis des environnements d'exécution plus anciens
Le compute standard et dédié sur les versions de Databricks Runtime antérieures à 16,4 ne peut pas accéder aux tables sécurisées par ABAC. Si vous avez besoin que certaines charges de travail continuent de s'exécuter sur un ancien runtime, appliquez la politique ABAC à un groupe spécifique au lieu de l'appliquer de manière générale. Ajoutez uniquement les utilisateurs ou les principaux auxquels vous souhaitez que la politique s'applique à ce groupe, et excluez le principal qui exécute la charge de travail de l'ancien runtime en utilisant la clause EXCEPT. Les utilisateurs extérieurs au groupe conservent un accès complet aux tables sous-jacentes. Cela permet à ce workload de continuer à accéder aux tables pendant que vous passez à un runtime pris en charge.
Politiques ABAC sur les vues
Vous ne pouvez pas appliquer les politiques ABAC directement aux vues. Cependant, lorsqu'un utilisateur interroge une vue qui fait référence à des tables avec des politiques ABAC, ces politiques sont respectées lors de l'accès aux données via la vue.
Les filtres de ligne et les masques de colonne ABAC sur les tables sous-jacentes sont évalués à l'aide de l'**identité de l'utilisateur de la session**, c'est-à-dire la personne qui exécute la query. L'utilisateur ne voit que les lignes et les valeurs de colonne auxquelles il est autorisé à accéder, telles que définies par les politiques ABAC sur les tables de base. Les vérifications d'accès aux tables de base et les vérifications d'accès aux dépendances utilisent l'identité du propriétaire de la vue, de sorte que les utilisateurs peuvent query des vues sans privilèges directs sur les tables sous-jacentes.
Le même modèle d'identité d'utilisateur de session s'applique lorsque les tables avec des politiques ABAC sont consultées via des fonctions.
Le modèle d’identité de l’utilisateur de session a été introduit parallèlement à la publication de l’ABAC GA. Auparavant, les politiques étaient évaluées à l’aide de l’identité du propriétaire de la vue ou du définisseur de fonction. Pour plus d’informations, consultez les notes de version d’avril 2026.
Politiques ABAC sur les vues matérialisées et les tables de streaming
Les politiques ABAC sur les vues matérialisées et les tables de streaming ne sont prises en charge que lorsque le propriétaire du pipeline et l'identité d'exécution sont exempts de la politique. Lorsqu'un pipeline refresh une vue matérialisée ou une table de streaming, les stratégies sont évaluées à l'aide de l'identité du propriétaire du pipeline ou de l'identité d'exécution. Si cette identité est soumise à une politique ABAC, le refresh du pipeline échoue.
Pour éviter les échecs de refresh, ajoutez le propriétaire du pipeline ou l'identité d'exécution à la clause EXCEPT de chaque politique ABAC appliquée aux tables source. Utilisez la clause TO pour spécifier quels utilisateurs et groupes reçoivent des données masquées ou filtrées.
Tables OpenSharing avec des politiques ABAC ou des vues qui y font référence
Les tables avec des politiques ABAC ou les vues qui référencent des tables avec des politiques ABAC ne peuvent être partagées via OpenSharing que si le propriétaire du partage est exempt de la politique (listé dans la clause EXCEPT). La politique ne régit pas l’accès du destinataire. Les destinataires peuvent appliquer leurs propres politiques ABAC aux tables partagées pour appliquer le contrôle d’accès de leur côté.
- Pour les fournisseurs de partage, consultez Ajouter des tables et des schémas sécurisés par des politiques ABAC à un partage.
- Pour les destinataires de partage, consultez Lire les données sécurisées par ABAC et appliquer les politiques ABAC.
Pour plus de détails sur l'utilisation d'OpenSharing avec ABAC, voir OpenSharing et ABAC.
Time travel et le clonage sur les tables avec des politiques ABAC
Les stratégies ABAC ne peuvent pas être évaluées par rapport aux instantanés de table historiques, de sorte que les queries de time travel échouent sur les tables avec des filtres de ligne ou des masques de colonne actifs. Les clones profonds et superficiels ne sont pas non plus pris en charge sur les tables avec des politiques ABAC.
Pour activer ces opérations, créez un Service Principal ou un groupe et ajoutez-le à la clause EXCEPT de la politique. La politique n'est pas évaluée pour les principaux exemptés, de sorte que ces opérations peuvent s'exécuter.
Les principaux exemptés voient les données non filtrées et démasquées. Seules les identités de confiance exemptées, telles que les Service Principal utilisées pour les charges de travail ETL ou de pipeline.
Par exemple, la politique suivante masque les colonnes PII pour tous les utilisateurs sauf les etl_service_principal, qui peuvent exécuter des query time travel et des Opérations de clonage :
CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;
Index de recherche AI et politiques ABAC
Les stratégies ABAC sur une table source ne s'appliquent pas aux index de recherche IA créés à partir de cette table. L'index synchronise toutes les lignes de la table source et n'applique pas les politiques de filtre de lignes ou de masque de colonnes lors de l'exécution des query.
Pour les tables avec des masques de colonne, vous pouvez exclure les colonnes masquées de l'index en utilisant le paramètre colonnes à synchroniser.
Plusieurs politiques sur la même table ou colonne pour le même utilisateur
Un seul filtre de ligne distinct peut être résolu à l'exécution pour une table donnée et un utilisateur donné, et un seul masque de colonne distinct peut être résolu pour une colonne donnée et un utilisateur donné. Vous pouvez définir plusieurs stratégies, mais lorsqu'un utilisateur query la table, seules les conditions d'une stratégie doivent correspondre. Si plusieurs filtres de ligne ou masques de colonne distincts s'appliquent au même utilisateur et à la même table ou colonne, Databricks bloque l'accès et renvoie une erreur. Plusieurs stratégies sont autorisées si elles se résolvent en la même UDF de filtre de ligne ou de masque de colonne avec les mêmes arguments.
Pour plus de détails, consultez les Règles pour les filtres et masques multiples.
Politiques ABAC et schéma d'information
Il n'y a pas de table de schéma d'informations pour les politiques ABAC. Les tables information_schema.row_filters et information_schema.column_masks affichent uniquement les filtres de ligne et masques de colonne au niveau de la table. Ils n'affichent pas les définitions de politique ABAC ni les filtres et masques dérivés des politiques ABAC au moment de l'exécution.
Pour lister les politiques ABAC, utilisez l'API REST de Unity Catalog. Les événements de création, de modification et de suppression de stratégies sont enregistrés dans la table système des logs d'audit.
ABAC sur compute dédié.
Pour les limitations d'ABAC sur compute dédié, voir Limitations.
Limitations communes à ABAC et aux filtres de ligne et masques de colonne au niveau de la table
Pour les limitations générales des filtres de ligne et des masques de colonne qui s'appliquent à la fois à ABAC et aux filtres de ligne et aux masques de colonne au niveau de la table, consultez les Limitations.