Concepts clés du contrôle d'accès basé sur les attributs (ABAC)

Le contrôle d'accès basé sur les attributs (ABAC) est un modèle de contrôle d'accès qui utilise des balises régies et des politiques pour accorder des autorisations basées sur les attributs d'objet plutôt que des octrois par objet. Cette page définit les blocs de construction : les tags gouvernés, les trois types de politiques ABAC (filtre de lignes, masque de colonnes et politiques GRANT), les autorisations nécessaires à leur configuration et la séparation des tâches qu'ABAC permet entre les équipes.

Consultez le contrôle d'accès basé sur les attributs dans Unity Catalog pour un aperçu de tous les sujets ABAC, y compris les tutoriels, la gestion des politiques, les meilleures pratiques et les limitations.

Qu'est-ce que l'ABAC ?

Le contrôle d'accès basé sur les attributs (ABAC) est un modèle de contrôle d'accès dynamique où les décisions d'accès sont basées sur des politiques évaluées par rapport aux attributs associés aux objets sécurisables. Dans Unity Catalog, ces attributs sont représentés par des tags régis. Ces tags régis sont utilisés dans les conditions de politique pour faire correspondre les objets de données dans une portée donnée, telle qu'un catalogue ou un schéma. Cela permet à une seule politique de s'appliquer automatiquement à plusieurs objets de données qui remplissent ses conditions.

Par exemple, une politique ABAC pourrait masquer toutes les colonnes balisées PII pour les tables au sein des schémas balisés HR. À mesure que de nouveaux objets de données sont créés et tagués, la politique s’applique automatiquement sans nécessiter de définitions de politiques distinctes pour chaque objet.

ABAC prend en charge la sécurité au niveau des lignes et des colonnes via les politiques de filtrage de lignes et les politiques de masquage de colonnes sur les tables, les vues matérialisées et les tables de streaming. Les politiques de filtrage de lignes restreignent les lignes qu'un utilisateur peut voir. Les stratégies de masque de colonne contrôlent la manière dont les valeurs de colonne sont présentées aux utilisateurs. Pour une comparaison avec les filtres de lignes et masques de colonne au niveau de la table, consultez Quand utiliser ABAC vs les filtres de lignes et les masques de colonne au niveau de la table.

ABAC prend également en charge l'octroi dynamique de privilèges par le biais de **politiques GRANT** (Bêta), actuellement limitées à EXECUTE sur les modèles. Voir les politiques ABAC GRANT pour les modèles (bêta).

Tags gouvernés

Dans Unity Catalog, les attributs sont implémentés en tant que balises gouvernées. Les tags gouvernés sont des paires clé-valeur définies au niveau du compte et appliquées aux objets sécurisables d'Unity Catalog tels que les catalogues, les schémas, les tables, les colonnes, les modèles et les volumes, en plus des objets de l'workspace. Ils représentent des caractéristiques telles que la sensibilité, la classification ou le domaine d'activité.

By default, les éléments sécurisables héritent des balises de leur catalogue ou schéma parent. Vous pouvez remplacer les balises héritées à tous les niveaux, sauf au niveau de la colonne : les balises de colonne n'héritent pas de la table parente et doivent être appliquées directement.

Les tags gouvernés peuvent être référencés dans les conditions de politique à l'aide de fonctions intégrées comme has_tag() et has_tag_value(), qui vérifient si un tag donné est présent sur l'objet de données cible, soit directement, soit par héritage de tag.

Les tags régis sont définis au niveau du compte. Cela signifie que vous pouvez utiliser la même taxonomie de balises sur l'ensemble de votre patrimoine de données dans un compte, y compris sur plusieurs metastores.

Pour plus d'informations, consultez Tags régis et Appliquer des tags aux objets sécurisables d'Unity Catalog.

Politiques

Les politiques sont associées à des objets sécurisables dans Unity Catalog pour définir des règles de contrôle d'accès basées sur les conditions des balises. Voici un exemple :

SQL

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Chaque politique précise :

• Périmètre : L'objet sécurisable auquel la politique est associée, spécifié par la ON clause. Associer une politique à un objet sécurisable signifie que les conditions de la politique sont évaluées pour tous les objets du type spécifié dans la clause FOR, sur cet objet et tous ses descendants.
  • Pour les politiques de filtrage de lignes et de masquage de colonne, les étendues de politique prises en charge sont CATALOG, SCHEMA ou TABLE. Pour les politiques GRANT (bêta), les étendues de politique prises en charge sont CATALOG et SCHEMA.
  • Les tables, y compris les tables de streaming et les vues matérialisées, sont le seul type d'objet sécurisable pris en charge pour les politiques de filtre de lignes et de masque de colonnes, spécifiées à l'aide de la clause FOR TABLES. Les politiques GRANT (bêta) ne prennent en charge que les modèles, spécifiées à l'aide de GRANT EXECUTE FOR MODELS. Consultez les politiques ABAC GRANT pour les modèles (bêta).
  • Une politique attachée à un catalogue s'évalue par rapport à toutes les tables de ce catalogue. Une politique attachée à un schéma s'évalue par rapport à toutes les tables de ce schéma. Une politique attachée à une table s'évalue uniquement par rapport à cette table.

remarque

Databricks recommande d'attacher les stratégies au niveau applicable le plus élevé, généralement le catalogue, afin d'optimiser l'efficacité de la gouvernance. Consultez les meilleures pratiques pour les politiques ABAC.

• Principaux : À qui la politique s'applique et qui en est exempté. La clause TO spécifie les utilisateurs, les groupes ou les Service Principal soumis à la politique. La clause facultative EXCEPT exclut des principaux spécifiques de cette politique.
• Actions : si la politique applique un filtre de ligne, un masque de colonne ou une attribution de privilège. Les politiques de filtre de ligne et de masque de colonne utilisent une fonction définie par l'utilisateur (UDF) pour implémenter la logique de filtrage ou de masquage. Les politiques GRANT (Beta) n'utilisent pas les UDF. Consultez Types de politiques.
• Conditions : Expressions basées sur des tags qui déterminent les tables ou les colonnes ciblées par la stratégie. Consultez Conditions et fonctions intégrées.

Les stratégies sont créées et gérées via l'interface utilisateur ou par programmation avec des instructions SQL, telles que CREATE POLICY, DROP POLICY, SHOW POLICIES ou DESCRIBE POLICY, des API REST, des SDK Databricks ou Terraform. Consultez Créer et gérer des politiques ABAC pour la syntaxe complète et des exemples.

Types de politiques

ABAC prend en charge trois types de stratégies : les stratégies de filtrage des lignes, les stratégies de masquage des colonnes et les stratégies GRANT (bêta). Les stratégies de filtrage des lignes et de masquage des colonnes nécessitent des UDF pour implémenter la logique de filtrage ou de masquage. Les stratégies GRANT n'utilisent pas de UDF et accordent à la place des privilèges lorsque leur condition basée sur les balises correspond aux attributs de l'objet cible.

Politiques de filtre de lignes

Les politiques de filtrage des lignes restreignent les lignes qu'un utilisateur peut voir dans une table en fonction des valeurs des colonnes identifiées par des balises qui correspondent aux Conditions et fonctions intégrées. La politique fait référence à une UDF qui évalue chaque ligne. Les lignes où la fonction renvoie FALSE sont exclues des résultats de la query. Les arguments sont passés à l'UDF via la clause USING COLUMNS.

Exemple de cas d'utilisation : pour un catalogue de ventes, assurez-vous que l'équipe EMEA ne voit que les enregistrements de ventes EMEA dans tous les tableaux qui ont une colonne balisée region.

SQL

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Stratégies de masquage de colonne

Les politiques de masquage de colonne contrôlent les valeurs qu'un utilisateur voit pour des colonnes spécifiques identifiées par des tags qui correspondent aux conditions et fonctions intégrées. La politique fait référence à une UDF qui prend la valeur de la colonne en entrée et renvoie la valeur originale ou une version masquée. La valeur de la colonne masquée est liée automatiquement comme premier argument de la clause ON COLUMN, et des arguments supplémentaires peuvent être transmis via USING COLUMNS. Le type de retour doit correspondre ou être convertible au type de données de la colonne.

Exemple de cas d'utilisation : Masquer les colonnes SSN étiquetées avec pii : ssn afin que les utilisateurs voient ***-**-XXXX (les quatre derniers chiffres uniquement) à moins qu'ils ne fassent partie d'un groupe de conformité exempté de la politique.

SQL

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

La clause USING COLUMNS passe les arguments à l'UDF. Il accepte les alias pour les colonnes qui correspondent à une expression basée sur des tags, ou les valeurs constantes (chaînes de caractères entre guillemets, littéraux numériques, valeurs booléennes (TRUE/FALSE) ou NULL), fournies dans l'ordre attendu par la fonction. Elle accepte également les fonctions d'introspection de tag, qui extraient la valeur d'un tag au moment de la query et la transmettent à l'UDF. Pour les stratégies de masquage de colonnes, ce sont des arguments supplémentaires au-delà de la colonne masquée (qui est liée automatiquement à partir de ON COLUMN). Cela permet de réutiliser une UDF unique dans plusieurs stratégies avec des parameters différents.

Les UDF SQL sont recommandées pour une meilleure performance. Les UDF Python enregistrées dans Unity Catalog sont également prises en charge, bien que l'optimiseur de query ne puisse pas les intégrer ou les optimiser comme il le peut avec les UDF SQL. Consultez Considérations sur les performances pour obtenir des conseils sur la sélection de la langue de l'UDF.

Stratégies GRANT (Bêta)

info

Bêta

Les politiques GRANT sont en Bêta, actuellement limitées à EXECUTE sur les modèles. Consultez les politiques ABAC GRANT pour les modèles (Bêta) pour la syntaxe, des exemples et les limitations de la version Bêta.

Les politiques GRANT accordent dynamiquement un privilège Unity Catalog lorsque leur condition basée sur des tags correspond aux tags d'un objet sécurisable. Chaque fois qu'un utilisateur tente d'accéder à un objet sécurisable, Unity Catalog identifie toutes les politiques GRANT dont le champ d'application couvre l'objet, vérifie si l'utilisateur figure dans la liste TO et non dans la liste EXCEPT, et évalue la condition WHEN de la politique par rapport aux tags de l'objet sécurisable, y compris les tags hérités. Si la politique s'applique, Unity Catalog accorde le privilège. Les politiques GRANT utilisent le même modèle d'évaluation que les politiques de filtrage de lignes et de masquage de colonnes, sauf qu'elles n'utilisent pas d'UDF. La condition est exprimée en ligne dans la définition de la politique.

Les privilèges effectifs sur un objet sont l'union des octrois directs et de toute politique de GRANT applicable. Un principal dispose du privilège si une politique GRANT en vigueur s'applique à ce principal ou si un GRANT direct du même privilège s'applique. Les politiques GRANT ajoutent seulement l'accès. Ils ne peuvent pas révoquer un accès qui a été accordé directement.

Conditions et fonctions intégrées

Les conditions sont des expressions basées sur des balises qui déterminent les tables et les colonnes qu'une politique cible dans son périmètre.

• Conditions de table (WHEN clause) : expressions booléennes qui correspondent aux tables en fonction de leurs tags. S'il est omis, la valeur par default est TRUE, ce qui signifie que la politique s'applique à toutes les tables dans la portée.
• Conditions de colonne (clause MATCH COLUMNS) : une ou plusieurs expressions booléennes séparées par des virgules qui identifient les colonnes ciblées par la stratégie. Chaque expression peut être une seule fonction intégrée comme has_tag('pii'), ou une combinaison utilisant des opérateurs logiques comme has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Chaque expression peut se voir attribuer un alias (spécifié après AS) qui peut être référencé dans les clauses ON COLUMN et USING COLUMNS. Une politique peut inclure jusqu'à 3 expressions de colonne, et toutes doivent correspondre pour que la politique s'applique.

Les deux types de clauses utilisent les fonctions intégrées suivantes, évaluées par Unity Catalog par rapport aux métadonnées sécurisables :

Fonction	Contexte	Description
has_tag('tag_key')	Tables et colonnes	Renvoie true si la ressource a le tag spécifié. Dans les conditions de table (WHEN), vérifie les tags définis directement sur la table ou hérités d'un catalogue ou d'un schéma parent. Dans les conditions de colonne (MATCH COLUMNS), vérifie les tags définis directement sur la colonne uniquement — ne correspond pas aux tags de table.
has_tag_value('tag_key', 'tag_value')	Tables et colonnes	Renvoie la valeur vraie si la ressource possède l'étiquette spécifiée avec la valeur spécifiée. Même comportement de contexte que has_tag().

Fonction	Contexte	Description
has_tag('tag_key')	Tables et colonnes	Renvoie true si la ressource a le tag spécifié. Dans les conditions de table (WHEN), vérifie les tags définis directement sur la table ou hérités d'un catalogue ou d'un schéma parent. Dans les conditions de colonne (MATCH COLUMNS), vérifie les tags définis directement sur la colonne uniquement — ne correspond pas aux tags de table.
has_tag_value('tag_key', 'tag_value')	Tables et colonnes	Renvoie la valeur vraie si la ressource possède l'étiquette spécifiée avec la valeur spécifiée. Même comportement de contexte que has_tag().

Les tags ne se propagent pas des tables aux colonnes. L'utilisation de has_tag() dans une clause MATCH COLUMNS ne correspond qu'aux tags au niveau des colonnes, pas aux tags de la table parente ou de ses ancêtres.

remarque

Les fonctions has_tag et has_tag_value utilisent la convention de nommage snake_case. Les anciennes formes camelCase (hasTag, hasTagValue) continuent de fonctionner mais ne sont pas recommandées. Databricks prévoit de déprécier les formes camelCase lors de la création de nouvelles politiques. Les politiques existantes ne sont pas affectées.

Exemple : utilisation de deux conditions de colonne. Un schéma customers a des tables avec une colonne e-mail étiquetée pii : email et une colonne de consentement étiquetée consent_to_contact. La politique masque les adresses e-mail à moins que le client n'ait consenti à être contacté. Il utilise deux conditions de colonne :

1. has_tag_value('pii', 'email') identifie la colonne qui contient les adresses e-mail (la colonne à masquer).
2. has_tag('consent_to_contact') identifie la colonne qui contient les informations de consentement (utilisées par l'UDF pour décider si le masquage doit être effectué).

SQL

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Cette politique s'applique uniquement aux tables qui ont à la fois une colonne taguée pii : email et une colonne taguée consent_to_contact. Si une table ne comporte pas de colonnes correspondant aux deux conditions, la politique ne s'applique pas et les données sont renvoyées non masquées.

Fonctions définies par l'utilisateur (UDF)

Les politiques de filtre de lignes et de masque de colonnes utilisent des fonctions définies par l'utilisateur (UDF) pour implémenter leur logique de filtrage ou de masquage. Consultez les fonctions définies par l'utilisateur (UDF) SQL et Python dans Unity Catalog pour savoir comment créer et gérer les UDF, et les modèles courants pour le filtrage de lignes et le masquage de colonnes pour des exemples.

Fonctions d'introspection des tags

Les fonctions d'introspection des tags extraient la valeur d'un tag gouverné et la transmettent à une UDF via la clause USING COLUMNS. Étant donné que l'UDF reçoit la valeur du tag comme argument, une seule politique et une seule UDF peuvent gérer plusieurs valeurs de tag, plutôt que de nécessiter une politique distincte pour chaque valeur de tag. Ces fonctions sont disponibles uniquement pour les politiques de filtrage de ligne et de masquage de colonne, car les politiques GRANT n'utilisent pas d'UDF.

La création d'une politique qui utilise ces fonctions nécessite Databricks Runtime 18 ou une version ultérieure. Cette exigence s'applique uniquement à la création de politiques, et non à l'interrogation des tables régies.

remarque

Databricks Runtime 18 est plus récent que Databricks Runtime 18,0, 18,1 et 18,2. Les fonctionnalités qui auraient auparavant été livrées sous forme de version numérotée ultérieure sont désormais livrées sous forme de mises à jour datées pour Databricks Runtime 18 à la place. Pour plus de détails, consultez À propos des notes de version unifiées.

Au moment de la requête, Unity Catalog évalue ces fonctions par rapport aux balises sur la table ou les colonnes auxquelles la politique correspond : get_tag_value() lit à partir de la table qui satisfait la condition WHEN, et get_column_tag_value() lit à partir des colonnes identifiées par MATCH COLUMNS. Elles ne peuvent apparaître que dans la clause USING COLUMNS, pas dans les conditions WHEN ou MATCH COLUMNS.

Fonction	Contexte	Description
get_tag_value('tag_key')	Tables	Retourne la valeur du tag spécifié appliqué à la table accédée, ou hérité de son schéma ou catalogue parent. Retourne NULL si le tag n'est pas appliqué à la table ou à un ancêtre, ou s'il n'a pas de valeur.
get_column_tag_value(column_alias, 'tag_key')	Colonnes	Renvoie la valeur du tag spécifié appliqué directement à une colonne correspondante. Contrairement à get_tag_value(), cette fonction ne consulte pas les tags sur la table parente, car les tags de colonne n'héritent pas. Le premier argument est un alias défini dans la clause MATCH COLUMNS. Renvoie NULL si le tag n'est pas appliqué à la colonne ou n'a pas de valeur.

Fonction	Contexte	Description
get_tag_value('tag_key')	Tables	Retourne la valeur du tag spécifié appliqué à la table accédée, ou hérité de son schéma ou catalogue parent. Retourne NULL si le tag n'est pas appliqué à la table ou à un ancêtre, ou s'il n'a pas de valeur.
get_column_tag_value(column_alias, 'tag_key')	Colonnes	Renvoie la valeur du tag spécifié appliqué directement à une colonne correspondante. Contrairement à get_tag_value(), cette fonction ne consulte pas les tags sur la table parente, car les tags de colonne n'héritent pas. Le premier argument est un alias défini dans la clause MATCH COLUMNS. Renvoie NULL si le tag n'est pas appliqué à la colonne ou n'a pas de valeur.

Les deux fonctions acceptent la clé de tag comme littéral de chaîne. Le tag doit être un tag gouverné, et get_column_tag_value() doit faire référence à un alias qui existe dans la clause MATCH COLUMNS de la politique. Si le tag n’est pas gouverné ou si l’alias n’est pas valide, la création de la politique échoue. Si un tag référencé n’est plus gouverné lors de l’exécution d’une query, les querys effectuées sur les tables cibles de la politique échouent au moment de l’exécution.

Exemple : Une politique pour tous les types de PII.

Sans l'introspection des tags, le masquage de chaque type d'informations personnelles identifiables (e-mail, numéro de sécurité sociale, téléphone) nécessite une politique et une UDF distinctes pour chaque valeur de tag. Avec get_column_tag_value(), une seule politique transmet la valeur du tag pii de la colonne correspondante à une seule UDF. L'UDF se ramifie sur cette valeur :

SQL

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

Pour chaque colonne masquée, get_column_tag_value(col, 'pii') se résout en la valeur du tag pii de cette colonne (email, ssn, phone, etc.), et mask_pii applique la transformation correspondante. Une nouvelle valeur de tag requiert seulement une nouvelle Branch dans l'UDF, pas une nouvelle politique.

Séparation des tâches et des autorisations

La configuration de l’ABAC implique plusieurs étapes, chacune avec ses propres exigences en matière d’autorisations. Les organisations peuvent distribuer ces tâches à des groupes spécialisés selon la façon dont elles choisissent de séparer les fonctions. Par exemple, une organisation peut définir une taxonomie de balises de manière centralisée, puis demander aux data stewards de classer les données, aux administrateurs de la gouvernance de rédiger des politiques, aux créateurs de données de créer des objets dans des périmètres gouvernés, et aux consommateurs de données d’accéder aux objets gouvernés.

1. Créez la taxonomie des tags. Définissez les clés de tag gouvernées et leurs valeurs autorisées avant que quiconque ne les applique ou ne rédige des politiques. Par exemple, créez un tag sensitivity avec des valeurs contrôlées (public, internal, confidential, restricted) ou un tag pii avec des valeurs telles que ssn, email et phone_number. Consultez Standardiser les attributs et la dénomination pour des recommandations sur les conventions de dénomination et la conception de la taxonomie.

   • Autorisations requises : administrateur de compte, ou un utilisateur disposant de l'autorisation CREATE pour les balises au niveau du compte.

2. Balisez les actifs de données. Un data steward, un créateur de données ou un système de classification d'IA applique des étiquettes gouvernées aux objets sécurisables de Unity Catalog tels que les catalogues, les schémas, les tables, les colonnes, les modèles et les volumes. Par exemple, taguez les colonnes qui contiennent des informations personnellement identifiables avec pii : ssn, ou taguez un modèle avec lifecycle : production. Un balisage correct est la première étape essentielle pour que les politiques ABAC s'appliquent.

   • Autorisations requises : ASSIGN sur le tag et APPLY TAG sur l'objet.

attention

Le taggage est une limite de sécurité. Si un utilisateur peut modifier les tags d’un asset de données, il peut modifier les stratégies qui s’y appliquent. Les organisations doivent contrôler qui peut appliquer les tags et auditer les modifications de tags.

3. **Créer une politique.** Un administrateur de gouvernance crée une politique à une portée, telle qu'un catalogue ou un schéma. La politique spécifie à qui elle s'applique, quelles conditions elle évalue et l'action à appliquer, telles qu'un filtre de ligne, un masque de colonne ou un octroi de privilèges.

   • Autorisations requises : l'autorisation MANAGE ou la propriété de l'objet sur l'objet sécurisable auquel la politique est attachée. Pour les politiques de filtrage de lignes et de masques de colonnes, vous devez également disposer du privilège EXECUTE sur l'UDF.

4. **Créer des objets de données.** Les créateurs de données créent des objets sécurisables tels que des tables, des modèles ou des volumes dans les étendues auxquelles ils ont eu accès. Les nouveaux objets héritent des balises des catalogues et schémas parents. Les créateurs de données ont également APPLY TAG automatiquement sur les objets qu'ils créent, afin qu'ils puissent appliquer des tags supplémentaires. Alternativement, ils peuvent s'appuyer sur la classification automatique des données pour gérer l'étiquetage. Si une organisation s'appuie sur les créateurs de données pour étiqueter leurs propres objets, elle devrait établir des pratiques d'étiquetage claires. Les créateurs de données n'ont pas besoin de configurer de contrôles d'accès si les politiques sont définies à des niveaux supérieurs, ce que Databricks recommande.

   • Autorisations requises : CREATE TABLE ou autres privilèges de création pertinents sur l'objet parent.

5. Accéder aux objets régis. Lorsqu’un utilisateur tente d’accéder à un objet sécurisable dans le cadre d’une stratégie, Unity Catalog évalue automatiquement les stratégies applicables. Pour les politiques de filtrage de lignes et de masques de colonnes, l'utilisateur voit des données filtrées ou masquées si la table ou les colonnes correspondent aux conditions de la politique et que l'utilisateur n'est pas exempté. Pour les stratégies GRANT (Bêta), l'utilisateur obtient le privilège accordé si les conditions correspondent et que l'utilisateur se trouve dans TO et non dans EXCEPT.

   • Autorisations requises : pour les politiques de filtre de ligne et de masque de colonne, les utilisateurs doivent se voir accorder des autorisations sur la table, telles que SELECT, par le biais d'une concession d'objet directe. Ces politiques filtrent les enregistrements ou masquent les colonnes pour les tables auxquelles l'utilisateur peut déjà accéder. Elles n'accordent pas d'autorisations par elles-mêmes. Les politiques GRANT (Bêta) octroient elles-mêmes le privilège et s'unissent avec les GRANTs directs sur le même élément sécurisable.

Avantages d'ABAC

• Politiques réutilisables basées sur les attributs : Une seule politique peut s'appliquer à plusieurs objets de données qui correspondent aux mêmes conditions basées sur les attributs, plutôt que d'être liée à un objet spécifique.

• Application automatique aux nouveaux objets : lorsque de nouveaux objets de données sont créés dans le périmètre et marqués avec les attributs pertinents, les politiques ABAC existantes s'appliquent sans configuration supplémentaire. Les politiques agissent comme des autorisations futures, ce qui signifie que les contrôles d'accès s'appliquent automatiquement à mesure que de nouvelles données sont créées et étiquetées de manière appropriée.

• Application cohérente au sein d'une étendue : Les politiques attachées au niveau du catalogue ou du schéma sont évaluées dynamiquement par rapport aux objets de données correspondants dans cette étendue, ce qui supprime les différences dans la manière dont des données similaires sont filtrées ou masquées.

• Maintenance continue réduite : Les modifications peuvent être effectuées en mettant à jour la logique des politiques ou les tags régis, plutôt qu'en révisant chaque objet individuel comme l'exigent les filtres de lignes et les masques de colonnes au niveau de la table.

• Gouvernance centralisée : Parce que les politiques peuvent être définies une seule fois et appliquées à de nombreux objets de données correspondants, les équipes de gouvernance peuvent gérer les contrôles sur de plus grandes parties du patrimoine de données avec moins de définitions de politiques.

Ressources supplémentaires

• Tags gouvernés
• CRÉER UNE POLITIQUE
• Gérer les privilèges dans Unity Catalog
• Filtres de lignes et masques de colonne
• Référence de la table système des Logs d'audit
• Exigences, quotas et limitations pour les politiques de filtrage des lignes et de masquage des colonnes.