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 des politiques de filtrage des lignes et de masquage des colonnes. Pour les politiques GRANT, consultez les politiques ABAC GRANT.
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 |
|---|---|
Politiques par métastore (tous les objets) | 10 000 |
Politiques par métastore, associées directement (bêta) | 100 |
Politiques par catalogue | 100 |
Politiques par 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
Attributs d’identité dans les conditions de politique
Les fonctions has_identity_attribute_value et has_identity_attribute_tag_match évaluent les attributs d’identité de l’utilisateur exécutant la query. Ils sont pris en charge dans la clause WHEN des politiques de masquage de colonne. Les limitations suivantes s’appliquent :
- Ils ne sont pas pris en charge dans la clause
MATCH COLUMNSdes politiques de masquage de colonne. - Ils ne sont pas pris en charge dans les politiques
GRANTouDENY. - L’interface de création de politique dans Catalog Explorer ne prend pas en charge les fonctions d’attribut. Utilisez SQL pour créer ces politiques.
Pour les modèles d’utilisation, consultez Masquer une colonne en fonction des attributs de l’utilisateur qui effectue la query.
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
Bêta
L'application de politiques ABAC aux vues est en phase de bêta. Pour l'utiliser, un administrateur de compte doit activer l'aperçu ABAC sur les vues depuis la page Aperçus de la console du compte, et vous devez utiliser Databricks Runtime 19 ou une version supérieure. Consultez Gérer les aperçus au niveau du compte.
Les exigences et limitations suivantes s’appliquent aux politiques sur les vues :
- Les vues métriques ne sont pas prises en charge : vous ne pouvez pas appliquer de politiques ABAC aux vues métriques.
- Une seule query peut superposer au plus 20 politiques : une table de base peut avoir une politique, et chaque vue construite au-dessus de celle-ci peut avoir sa propre politique. Lorsqu’une query lit au travers d’une vue, toutes les politiques applicables s’appliquent à chaque niveau de la hiérarchie. Si plus de 20 politiques devaient s’appliquer, la query échoue.
CREATE OR REPLACE VIEWsupprime les tags gouvernés et les politiques directement attachées : le remplacement d'une vue par une instructionCREATE OR REPLACEefface les métadonnées de la vue, ainsi que ses tags gouvernés et toutes les politiques qui y sont directement attachées. Pour préserver les métadonnées, utilisez plutôtALTER VIEW. Si vous utilisezCREATE OR REPLACE, réappliquez les tags et les politiques gouvernés par la suite.- Les colonnes dotées de tags gouvernés ne peuvent pas être supprimées tant que les tags n’ont pas été retirés : tout comme pour les tables de base, les tags gouvernés doivent être retirés de la colonne d’une vue avant de pouvoir supprimer cette dernière. Sinon, les politiques qui dépendent du tag risqueraient d’être supprimées par inadvertance.
- Les politiques ABAC ne peuvent pas être appliquées à une vue partagée du côté du destinataire : lorsque vous partagez une vue via OpenSharing, le destinataire ne peut pas appliquer de politiques ABAC à cette vue partagée. Pour appliquer des politiques du côté du destinataire, partagez plutôt les tables de base et demandez au destinataire de créer des vues locales par-dessus, avec des politiques ABAC sur les tables partagées. Consultez Vues locales pour le destinataire sur des tables partagées.
Politiques ABAC sur les vues matérialisées et les tables de streaming
Lorsqu’un pipeline refresh une vue matérialisée ou une table de streaming, il évalue les politiques en utilisant l’identité du propriétaire du pipeline ou l’identité « run-as ». Si cette identité est soumise à une politique ABAC, la vue matérialisée ou la table de streaming contient en permanence des données masquées ou filtrées. Pour éviter cela, ajoutez le propriétaire du pipeline ou l’identité « run-as » à la clause EXCEPT des politiques ABAC associées à toutes les tables lues pendant le refresh du pipeline. 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.
Clonage de tables avec des politiques ABAC
Les clones profonds et superficiels ne sont pas pris en charge sur les tables dotées de politiques ABAC. Pour cloner une table, utilisez un Service Principal ou un groupe répertorié dans la clause EXCEPT de chaque politique applicable à la table.
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 règle suivante masque les colonnes contenant des informations d’identification personnelle (PII) pour tous les utilisateurs, à l’exception de etl_service_principal, qui peut cloner le tableau :
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 Filtres et masques en conflit.
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.