Exigences, quotas et limitations ABAC

Cette page répertorie les exigences, les quotas de stratégie et les limitations actuelles pour le contrôle d’accès basé sur les attributs (ABAC) dans le catalogue Unity.

Exigences de calcul

Pour utiliser des stratégies ABAC, vous devez utiliser l’une des configurations de calcul suivantes :

• Informatique sans serveur
• Calcul standard sur Databricks Runtime 16.4 ou version ultérieure
• Calcul dédié sur Databricks Runtime 16.4 ou version ultérieure avec filtrage de contrôle d’accès affiné activé

Pour obtenir des conseils sur l’exécution de charges de travail nécessitant des runtimes plus anciens, consultez Access à partir d’anciens runtimes.

Conditions requises pour les étiquettes régies

Les stratégies ABAC utilisent des balises régies, et non des balises non gouvernementales. Les balises régies sont définies au niveau du compte avec des contrôles d’accès qui déterminent qui peut créer, affecter et gérer ces balises. Pour plus d’informations, consultez balises régies.

Quotas de stratégie

Pour plus d’informations, y compris les quotas de balises régies, consultez Limites de service.

Limitations ABAC

Accès à partir d’anciens runtimes

Le calcul standard et dédié sur les versions databricks Runtime antérieures à la version 16.4 ne peut pas accéder aux tables sécurisées par ABAC. Si vous avez besoin de certaines charges de travail pour continuer à s’exécuter sur un runtime plus ancien, étendez la stratégie ABAC à un groupe spécifique au lieu de l’appliquer à grande échelle. Ajoutez uniquement les utilisateurs ou les principaux que vous souhaitez appliquer à ce groupe et excluez le principal qui exécute l’ancienne charge de travail runtime à l’aide de la EXCEPT clause. Les utilisateurs extérieurs au groupe conservent un accès complet aux tables sous-jacentes. Cela permet à cette charge de travail de continuer à accéder aux tables pendant la transition vers un runtime pris en charge.

Stratégies ABAC sur les vues

Vous ne pouvez pas appliquer de stratégies ABAC directement aux vues. Toutefois, lorsqu’un utilisateur interroge une vue qui référence des tables avec des stratégies ABAC, ces stratégies sont respectées lors de l’accès aux données via la vue.

Les filtres de lignes ABAC et les masques de colonne sur les tables sous-jacentes sont évalués à l’aide de l’identité de l’utilisateur de session, ce qui signifie que la personne exécutant la requête. L’utilisateur voit uniquement les lignes et les valeurs de colonne auxquels ils sont autorisés à accéder, comme défini par les stratégies 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, afin que les utilisateurs puissent interroger des vues sans privilèges directs sur les tables sous-jacentes.

Stratégies ABAC sur les vues matérialisées et les tables de streaming

Lorsqu’un pipeline actualise une vue matérialisée ou une table de diffusion en continu, les stratégies sont évaluées à l’aide de l’identité du propriétaire ou de l’exécution du pipeline. Si cette identité est soumise à la stratégie, la table matérialisée ou de diffusion en continu contient définitivement des données masquées ou filtrées. Databricks recommande de conserver l’identité d’actualisation exemptée à l’aide de la EXCEPT clause et de cibler les consommateurs qui doivent voir les données masquées ou filtrées dans la TO clause.

Tables de partage delta avec des stratégies ou des vues ABAC qui les référencent

Les tables avec des stratégies ou des vues ABAC qui référencent des tables avec des stratégies ABAC peuvent uniquement être partagées via le partage delta si le propriétaire du partage est exempté de la stratégie (répertoriée dans la EXCEPT clause). La stratégie ne régit pas l’accès du destinataire. Les destinataires peuvent appliquer leurs propres stratégies 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 stratégies ABAC à un partage.
• Pour les destinataires de partage, consultez Lire les données sécurisées par ABAC et appliquer des stratégies ABAC.

Pour plus d’informations sur l’utilisation du partage Delta avec ABAC, consultez Partage Delta et ABAC.

Voyage dans le temps et clonage sur des tables avec des stratégies ABAC

Les stratégies ABAC ne peuvent pas être évaluées par rapport aux instantanés de table historiques. Par conséquent, les requêtes de voyage temporelle échouent sur les tables avec des filtres de lignes actifs ou des masques de colonne. Les clones profonds et peu profonds ne sont pas pris en charge sur les tables avec des stratégies ABAC.

Pour activer ces opérations, créez un principal de service ou un groupe et ajoutez-le à la clause de EXCEPT la stratégie. La stratégie n’est pas évaluée pour les principaux exemptés. Ces opérations peuvent donc s’exécuter.

Par exemple, la stratégie suivante masque les colonnes d’informations personnelles pour tous les utilisateurs, à l’exception du etl_service_principal, qui peut exécuter des requêtes de déplacement du temps 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 vectorielle et stratégies ABAC

Les stratégies ABAC sur une table source ne s’appliquent pas aux index de recherche vectorielle créés à partir de cette table. L’index synchronise toutes les lignes de la table source et n’applique pas de stratégies de filtre de lignes ou de masque de colonne lors du traitement des requêtes.

Pour les tables avec des masques de colonne, vous pouvez exclure des colonnes masquées de l’index à l’aide des colonnes pour synchroniser le paramètre.

Plusieurs stratégies sur la même table ou colonne pour le même utilisateur

Un seul filtre de lignes distinct peut être résolu au moment de 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 quand un utilisateur interroge la table, seules les conditions d’une stratégie doivent correspondre. Si plusieurs filtres de lignes ou masques de colonne distincts s’appliquent au même utilisateur et à la même table ou colonne, Azure Databricks bloque l’accès et retourne une erreur. Plusieurs stratégies sont autorisées si elles sont résolues sur le même filtre de lignes ou le même masque de colonne UDF avec les mêmes arguments.

Pour plus d’informations, consultez Règles pour plusieurs filtres et masques.

Schéma des stratégies et des informations ABAC

Il n’existe aucune table de schéma d’informations pour les stratégies ABAC. Les information_schema.row_filters tableaux affichent information_schema.column_masks uniquement les filtres de lignes de niveau table et les masques de colonne. Ils n’affichent pas les définitions de stratégie ABAC ni les filtres et les masques dérivés des stratégies ABAC au moment de l’exécution.

Pour répertorier les stratégies ABAC, utilisez l’API REST du catalogue Unity. Les événements de création, de modification et de suppression de stratégie sont capturés dans la table système du journal d’audit.

ABAC sur le calcul dédié

Pour connaître les limitations d’ABAC sur le calcul dédié, consultez Limitations.

Limitations courantes pour les filtres de lignes au niveau de la table et les filtres de lignes au niveau de la table et les masques de colonne

Pour connaître les limitations générales des filtres de lignes et des masques de colonne qui s’appliquent à la fois aux filtres de lignes ABAC et aux filtres de lignes de niveau table et aux masques de colonne, consultez Limitations.