Concepts fondamentaux 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 et des stratégies régies pour accorder des autorisations basées sur des attributs d’objet plutôt que sur des octrois par objet. Cette page définit les blocs de construction : balises régies, les trois types de stratégies ABAC (filtre de lignes, masque de colonne et GRANT stratégies), les autorisations requises pour les configurer et la séparation des tâches qu’ABAC permet à toutes les équipes.

Consultez le contrôle d’accès basé sur les attributs dans le catalogue Unity pour obtenir une vue d’ensemble de toutes les rubriques ABAC, notamment les didacticiels, la gestion des stratégies, les meilleures pratiques et les limitations.

Qu’est-ce qu’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 stratégies évaluées par rapport aux attributs associés aux objets sécurisables. Dans le catalogue Unity, ces attributs sont représentés par le biais de balises régies. Ces balises régies sont utilisées dans les conditions de stratégie pour faire correspondre les objets de données dans une étendue donnée, comme un catalogue ou un schéma. Cela permet à une stratégie unique d’appliquer automatiquement plusieurs objets de données répondant à ses conditions.

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

ABAC prend en charge la sécurité au niveau des lignes et des colonnes par le biais de stratégies de filtre de lignes et de stratégies de masque de colonne sur les tables, les vues matérialisées et les tables de diffusion en continu. Les stratégies de filtre de lignes limitent les lignes qu’un utilisateur peut voir. Les stratégies de masque de colonne contrôlent la façon dont les valeurs de colonne sont présentées aux utilisateurs. Pour une comparaison avec les filtres de lignes de niveau table et les masques de colonne, consultez Quand utiliser ABAC par rapport aux filtres de lignes de niveau table et aux masques de colonne.

L’ABAC prend également en charge les octrois dynamiques de privilèges via des GRANTstratégies, pour les types d’objets sécurisables pris en charge. Voir les politiques ABACGRANT.

Balises régies

Dans le catalogue Unity, les attributs sont implémentés en tant que balises régies. Les balises régies sont des paires clé-valeur définies au niveau du compte et appliquées aux objets sécurisables du catalogue Unity, tels que les catalogues, les schémas, les tables, les colonnes, les modèles et les volumes, en plus des objets d’espace de travail. Ils représentent des caractéristiques telles que la sensibilité, la classification ou le domaine métier.

Par défaut, les éléments sécurisables héritent des balises de leur catalogue ou schéma parent. Vous pouvez remplacer les balises héritées à chaque niveau, à l’exception du niveau colonne : les balises de colonne n’héritent pas de la table parente et doivent être appliquées directement.

Les balises régies peuvent être référencées dans des conditions de stratégie à l’aide de fonctions intégrées comme has_tag() et has_tag_value(), qui vérifient si une balise donnée est présente sur l’objet de données cible, directement ou via l’héritage des balises.

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

Pour plus d’informations, consultez Balises régies et Appliquer des balises aux objets sécurisables du catalogue Unity.

Politiques

Les stratégies sont attachées à des objets sécurisables dans le catalogue Unity pour définir des règles de contrôle d’accès en fonction des conditions de balise. Voici un exemple :

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 stratégie spécifie :

• Étendue : l’objet sécurisable auquel la stratégie est associée, spécifiée par la clause ON. L’attachement d’une stratégie à un objet sécurisable signifie que les conditions de stratégie sont évaluées pour tous les objets du type spécifié dans la FOR clause, entre cet objet et tous ses descendants.
  • Pour les stratégies de filtre de ligne et de masque de colonne, les étendues de stratégie prises en charge sont CATALOG, SCHEMAou TABLE. Pour les GRANT politiques, les champs de portée des politiques soutenus sont CATALOG et SCHEMA.
  • Les tables, y compris les tables de flux et les vues matérialisées, sont le seul type sécurisé pris en charge pour les politiques de filtre de ligne et de masque de colonne, spécifiées à l’aide de la FOR TABLES clause. GRANT les politiques s’appliquent aux modèles, aux services de modèle, aux services de fournisseur de modèle, aux services MCP et aux services d’agent, et utilisent la clause GRANT <privilege> FOR <securable_type>. Pour la liste complète des types et privilèges de sécurables pris en charge, voir Types et privilèges de sécurables supportés.
  • Une politique attachée à un catalogue s’applique à tous les éléments sécurisables du type spécifié dans la clause FOR au sein de ce catalogue. Une stratégie attachée à un schéma s’applique à tous les objets sécurisables de ce type dans ce schéma. Une stratégie attachée à une table est évaluée uniquement par rapport à cette table.

• Principaux : à qui la politique s’applique et à qui est exemptée. La TO clause spécifie les utilisateurs, les groupes ou les principaux de service soumis à la stratégie. La clause facultative EXCEPT exclut les entités principales spécifiques de cette stratégie.
• Actions : indique si la stratégie applique un filtre de lignes, un masque de colonne ou une allocation de privilèges. Les stratégies de filtre de lignes et de masque de colonne utilisent une fonction définie par l’utilisateur pour implémenter la logique de filtrage ou de masquage. GRANT les politiques n’utilisent pas de UDF. Consultez types de stratégie.
• Conditions : expressions basées sur des balises qui déterminent les tables ou colonnes cibles de la stratégie. Consultez conditions et fonctions intégrées.

Les stratégies sont créées et gérées par le biais de l’interface utilisateur ou par programmation avec des instructions SQL, telles que CREATE POLICY, DROP POLICYSHOW POLICIESou DESCRIBE POLICY, DES API REST, des KITS DE développement logiciel (SDK) Databricks ou Terraform. Consultez Créer et gérer des stratégies ABAC pour obtenir la syntaxe complète et des exemples.

Types de stratégies

ABAC prend en charge trois types de politiques : les politiques de filtrage des lignes, les politiques de masquage des colonnes et les politiques GRANT. Les politiques de filtrage des lignes et de masquage des colonnes nécessitent que UDFs mettent en œuvre la logique de filtrage ou de masquage. GRANT les politiques n’utilisent pas de UDF et accordent des privilèges lorsque leur condition fondée sur les balises correspond aux attributs de l’objet cible.

Stratégies de filtrage des lignes

Les stratégies de filtre de lignes limitent les lignes qu’un utilisateur peut voir dans une table en fonction des valeurs des colonnes identifiées par des balises qui correspondent aux fonctions Conditions et intégrées. La stratégie fait référence à une fonction UDF qui évalue chaque ligne. Lignes où la fonction retourne FALSE sont exclues des résultats de la requête. Les arguments sont passés à la fonction UDF via la clause USING COLUMNS.

Exemple de cas d’usage : Pour un catalogue de ventes, assurez-vous que l’équipe EMEA voit uniquement les enregistrements de vente EMEA sur toutes les tables qui ont une colonne étiquetée region.

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 masque de colonne

Les stratégies de masque de colonne contrôlent les valeurs qu’un utilisateur voit pour des colonnes spécifiques identifiées par des balises qui correspondent aux fonctions intégrées et conditions. La stratégie fait référence à une fonction UDF qui prend la valeur de colonne comme entrée et retourne la valeur d’origine ou une version masquée. La valeur de la colonne masquée est automatiquement liée en tant que premier argument de la clause ON COLUMN, et d'autres arguments peuvent être transmis via USING COLUMNS. Le type de retour doit correspondre ou pouvoir être converti au type de données de la colonne.

Exemple de cas d’usage : Masquer les colonnes SSN marquées avec pii : ssn de sorte que les utilisateurs ne voient ***-**-XXXX (les quatre derniers chiffres uniquement) sauf s’ils appartiennent à un groupe de conformité exempt de la politique.

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 transmet des arguments à la fonction définie par l’utilisateur. Il accepte des alias pour les colonnes qui correspondent à une expression basée sur des balises ou des valeurs constantes (chaînes entre guillemets, littéraux numériques, valeurs booléennes (TRUE/FALSEou NULL), fournies dans l’ordre dans lequel la fonction s’attend. Il accepte également les fonctions d’introspection de balise, qui extraient la valeur d’une balise au moment de la requête et la transmettent à la fonction UDF. Pour les stratégies de masque de colonne, il s’agit d’arguments supplémentaires au-delà de la colonne masquée (qui est liée automatiquement à partir de ON COLUMN). Cela permet à une seule fonction UDF d’être réutilisée entre les stratégies avec différents paramètres.

Les fonctions définies par l’utilisateur SQL sont recommandées pour de meilleures performances. Les fonctions définies par l’utilisateur Python inscrites dans Unity Catalog sont également prises en charge, bien que l’optimiseur de requête ne puisse pas les intégrer ni les optimiser comme il le fait pour les fonctions définies par l’utilisateur SQL. Consultez les considérations relatives aux performances pour obtenir des conseils sur la sélection de la langue UDF.

GRANT Politiques

GRANT les politiques accordent dynamiquement un privilège dans Unity Catalog lorsque leur condition fondée sur les balises correspond aux balises d’un objet sécurisable. Chaque fois qu’un utilisateur tente d’accéder à un objet sécurisable, Unity Catalog identifie toutes les GRANT stratégies dont l’étendue couvre l’objet, vérifie si l’utilisateur se trouve dans la TO liste et non dans la EXCEPT liste, et évalue la condition de WHEN la stratégie par rapport aux balises sur l’élément sécurisable, y compris les balises héritées. Si la stratégie s’applique, Unity Catalog accorde le privilège. Les stratégies GRANT utilisent le même modèle d’évaluation que les stratégies de filtrage des lignes et de masquage de colonnes, sauf qu’elles n’utilisent pas de fonctions définies par l’utilisateur. La condition est exprimée directement dans la définition de la stratégie.

Les privilèges effectifs sur un objet correspondent à la combinaison des autorisations accordées directement et de toutes les stratégies GRANT applicables. Un principal possède un privilège si une stratégie GRANT applicable lui accorde ce privilège, ou si un GRANT direct du même privilège lui a été accordé. Les stratégies GRANT ne peuvent qu’ajouter des droits d’accès. Ils ne peuvent pas révoquer l’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 colonnes qu’une stratégie cible dans son étendue.

• Conditions de table (WHEN clause) : expressions booléennes qui correspondent aux tables en fonction de leurs balises. Si cette clause est omise, elle est remplacée par TRUE, ce qui signifie que la stratégie s’applique à toutes les tables de l’étendue.
• Conditions de colonne (MATCH COLUMNS clause) : une ou plusieurs expressions booléennes séparées par des virgules qui identifient les colonnes cibles de la stratégie. Chaque expression peut être une fonction intégrée unique comme has_tag('pii'), ou une combinaison à l’aide d’opérateurs logiques comme has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Chaque expression peut être associée à un alias (spécifié aprèsAS) qui peut être référencé dans les clauses ON COLUMN et USING COLUMNS. Une stratégie peut inclure jusqu’à 3 expressions de colonne, et toutes doivent correspondre pour que la stratégie s’applique.

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

Pour établir une correspondance en fonction des attributs de l’utilisateur qui exécute la requête plutôt que des balises de ressource, voir Fonctions d’attributs d’identité.

Pour correspondre au contexte d’une requête, comme l’application appelante, voir Fonctions d’attribut contextuel.

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

Exemple : utilisation de deux conditions sur les colonnes. Un customers schéma comporte des tables avec une colonne d’e-mail étiquetée pii : email et une colonne de consentement étiquetée consent_to_contact. La stratégie masque les adresses e-mail, sauf si le client a consenti à être contacté. Il utilise deux conditions de colonne :

1. has_tag_value('pii', 'email') identifie la colonne qui contient des adresses e-mail (colonne à masquer).
2. has_tag('consent_to_contact') identifie la colonne qui contient des informations de consentement (utilisées par la fonction UDF pour décider s’il faut masquer).

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 stratégie s’applique uniquement aux tables qui ont à la fois une colonne étiquetée pii : email et une colonne étiquetée consent_to_contact. Si une table ne possède pas de colonnes correspondant aux deux conditions, la stratégie ne s’applique pas et les données sont retournées non masquées.

Fonctions d’attribut d’identité (Bêta)

Les fonctions d’attribut d’identité évaluent les propriétés de l’utilisateur effectuant la requête, telles que le département, le pays ou le poste de travail. Ces attributs peuvent être provisionnés par votre fournisseur d’identité et référencés directement dans des conditions de stratégie. Cela permet d’exprimer des conditions plus flexibles sans créer des groupes séparés pour chaque combinaison de propriétés identités. Lorsque les informations d’identité changent dans votre fournisseur d’identité, les politiques utilisent les valeurs d’attributs mises à jour, tout comme elles utilisent une nouvelle appartenance au groupe.

Ces fonctions sont prises en charge dans la clause WHEN des politiques de masquage de colonnes.

Gardez à l’esprit les comportements suivants lorsque vous rédigez des politiques qui les utilisent :

• Un attribut manquant se résout en false. Si l’utilisateur n’a aucune valeur pour l’attribut, n’a aucun attribut du tout, ou si l’attribut n’existe pas, la fonction renvoie false au lieu de générer une erreur. Conditionnez la phrase de sorte que ce false résultat limite l’accès. Voir Conditions d’attributs d’identité.
• Les clés et valeurs d’attribut sont sensibles à la casse et comparées exactement : Finance et finance ne correspondent pas.
• Les changements d’attributs ne sont pas instantanés. Les changements dans votre fournisseur d’identité ne sont pas synchronisés immédiatement avec Azure Databricks. Voir attributs d’identité pour plus d’informations.

Pour les attributs pris en charge par Azure Databricks et leur provision, voir attributs d’identité. Pour des exemples d’utilisation des attributs d’identité dans les politiques, voir Masquer une colonne basée sur les attributs de l’utilisateur interrogé.

Fonctions d’attributs contextuelles (Bêta)

Les attributs de contexte sont utilisés pour restreindre l’accès aux données pour les requêtes faites au nom d’un utilisateur via une application OAuth. Cette configuration peut être utilisée pour restreindre l’accès aux données des agents lorsqu’ils agissent au nom d’un utilisateur, tout en gardant ces mêmes données accessibles si l’utilisateur les interroge directement dans l’espace de travail.

Il couvre toute application OAuth, qu’il s’agisse d’une application intégrée comme la CLI Azure Databricks ou d’une application OAuth personnalisée. Il existe deux attributs contextuels différents :

• request.is_on_behalf_of: la chaîne 'true' ou 'false'. Indique si la requête est exécutée au nom d’un utilisateur via une application OAuth. Toute requête provenant d’une application OAuth a cette valeur définie à 'true'.
• request.client_id: l’identifiant client OAuth. Cela peut être utilisé pour cibler un client OAuth spécifique, soit une application OAuth intégrée (par exemple, databricks-cli), soit une application OAuth personnalisée. Le client_id est visible sur la page Connexions des applications dans la console de compte. Pour les applications Databricks, cela peut également être observé sur la page des détails d’autorisation de l’application, sous OAuth2 ID de client de l’application. Ou bien, il peut être interrogé depuis le identity_metadata.acting_resource champ des journaux d’audit.

Ces attributs ne sont pas modifiables par l’utilisateur et sont explicitement fournis par le système ; Un appelant ne les influence que par la manière dont ils s’authentifient. Ces attributs peuvent être utilisés pour identifier des agents externes, pas des agents Génie.

Les attributs de contexte peuvent être utilisés via les fonctions suivantes :

Les clés d’attribut sont insensibles à la casse, et les valeurs sont sensibles à la casse.

Pour apprendre à utiliser ces attributs de contexte afin de contrôler l’accès des agents externes, voir Restreindre l’accès pour les agents externes agissant au nom d’un utilisateur.

Fonctions définies par l’utilisateur (UDF)

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

Fonctions d’introspection des balises

Les fonctions d’introspection d’étiquette extraient la valeur d’une balise régie et la transmettent à une fonction UDF via la USING COLUMNS clause. Étant donné que la fonction UDF reçoit la valeur de balise en tant qu’argument, une seule stratégie et une fonction UDF peuvent gérer plusieurs valeurs d’étiquette, plutôt que d’exiger une stratégie distincte pour chaque valeur d’étiquette. Ces fonctions sont disponibles uniquement pour les stratégies de filtrage de lignes et de masquage de colonnes, car les stratégies GRANT n’utilisent pas de fonctions définies par l’utilisateur.

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

Au moment de la requête, Unity Catalog évalue ces fonctions en fonction des balises de la table ou des colonnes auxquelles la stratégie s’applique : get_tag_value() lit les données de la table qui satisfait à la condition WHEN, et get_column_tag_value() lit les données des colonnes identifiées par MATCH COLUMNS. Elles ne peuvent apparaître que dans la USING COLUMNS clause, et non dans WHEN les MATCH COLUMNS conditions.

Les deux fonctions acceptent la clé de balise sous forme de chaîne littérale. La balise doit être une balise gouvernée, et get_column_tag_value() doit faire référence à un alias existant dans la clause MATCH COLUMNS de la stratégie. Si la balise n’est pas régie ou si l’alias n’est pas valide, la création de stratégie échoue. Si une balise référencée n’est plus régie lorsqu’une requête s’exécute, les requêtes sur les tables cibles de la stratégie échouent lors de l’exécution.

Exemple : une stratégie pour tous les types d’informations personnelles

Sans introspection de balise, le masquage de chaque type d’informations d’identification personnelle (e-mail, SSN, téléphone) nécessite une stratégie et une fonction UDF distinctes pour chaque valeur de balise. Avec get_column_tag_value(), une stratégie unique transmet à une UDF la valeur de la balise pii de la colonne correspondante. La fonction UDF effectue un branchement en fonction de cette valeur :

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') correspond à la valeur de la balise pii de cette colonne (email, ssn, phone, etc.), et mask_pii applique la transformation correspondante. Une nouvelle valeur de balise nécessite seulement une nouvelle branche dans l’UDF, pas une nouvelle stratégie.

Séparation des tâches et des autorisations

La configuration d’ABAC implique plusieurs étapes, chacune avec ses propres exigences d’autorisation. Les organisations peuvent distribuer ces tâches entre des groupes spécialisés en fonction de la façon dont elles choisissent de séparer les tâches. Par exemple, une organisation peut définir une taxonomie de balise de manière centralisée, puis avoir des gestionnaires de données classifier les données, les administrateurs de gouvernance écrivent des stratégies, les créateurs de données créent des objets dans des étendues régies et les consommateurs de données accèdent aux objets régis.

1. Créez la taxonomie des balises. Définissez les clés de balise régies et leurs valeurs autorisées avant que toute personne ne les applique ou écrit des stratégies. Par exemple, créez une sensitivity balise avec des valeurs contrôlées (public, internal, confidential, restricted) ou une pii balise avec des valeurs telles que ssn, emailet phone_number. Consultez Normaliser les attributs et le nommage pour obtenir des recommandations sur les conventions d’affectation de noms et la conception de taxonomie.

   • Autorisations requises : administrateur de compte ou utilisateur disposant CREATE d’autorisations pour les balises au niveau du compte.

2. Étiqueter les ressources de données. Un gestionnaire de données, un créateur de données ou un système de classification IA applique des étiquettes régies aux objets sécurisables du catalogue Unity, tels que les catalogues, les schémas, les tables, les colonnes, les modèles et les volumes. Par exemple, balisez des colonnes qui contiennent des informations d’identification personnelle avec pii : ssn, ou étiquetez un modèle avec lifecycle : production. L’étiquetage correct est la première étape essentielle pour que les stratégies ABAC s’appliquent.

   • Autorisations requises : ASSIGN sur la balise et APPLY TAG sur l’objet.

3. Créez une stratégie. Un administrateur de gouvernance crée une stratégie d’une certaine étendue, comme un catalogue ou un schéma. La stratégie spécifie à qui elle s’applique, quelles conditions elle évalue et l’action à appliquer, comme un filtre de ligne, un masque de colonne ou une allocation de privilèges.

   • Autorisations requises : autorisation MANAGE sur l’objet sécurisable auquel la stratégie est associée, ou la propriété de l’objet. Pour les stratégies de filtrage de lignes et de masquage de colonnes, le privilège EXECUTE sur la fonction définie par l’utilisateur est également requis.

4. Créez 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 été autorisés à accéder. Les nouveaux objets héritent des balises des catalogues et schémas parents. Les créateurs de données ont APPLY TAG également automatiquement sur les objets qu’ils créent, ce qui leur permet d’appliquer des balises supplémentaires. Elles peuvent également 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, il doit é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 stratégies sont définies à des niveaux supérieurs, ce qui Azure Databricks recommande.

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

5. Accès aux objets régis. Lorsqu’un utilisateur tente d’accéder à un objet sécurisable dans l’étendue d’une stratégie, Unity Catalog évalue automatiquement les stratégies applicables. Pour les stratégies de filtre de lignes et de masque de colonne, l’utilisateur voit les données filtrées ou masquées si la table ou les colonnes correspondent aux conditions de la stratégie et que l’utilisateur n’est pas exempté. Pour les GRANT politiques, l’utilisateur obtient le privilège accordé si les conditions correspondent et que l’utilisateur est dans TO et non dans EXCEPT.

   • Autorisations requises : pour les stratégies de filtrage de lignes et de masquage de colonnes, les utilisateurs doivent disposer d’autorisations sur la table, telles que de l’autorisation SELECT, via un octroi direct. Ces stratégies filtrent les enregistrements ou masquent les colonnes des tables que l’utilisateur peut déjà accéder. Ils n’accordent pas d’autorisations par eux-mêmes. GRANT les stratégies accordent elles-mêmes le privilège et s’additionnent à toute autorisation directe sur le même élément sécurisable.

Avantages d’ABAC

• Stratégies réutilisables basées sur des attributs : Une seule stratégie peut s’appliquer à plusieurs objets de données qui correspondent aux mêmes conditions basées sur les attributs, plutôt qu’à être liés à un objet spécifique.

• Application automatique vers de nouveaux objets : Lorsque de nouveaux objets de données sont créés dans l’étendue et marqués avec les attributs appropriés, les stratégies ABAC existantes s’appliquent sans configuration supplémentaire. Les stratégies agissent comme les futures subventions, 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 dans une étendue : Les stratégies 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 façon dont les données similaires sont filtrées ou masquées.

• Maintenance en cours plus faible : Les modifications peuvent être apportées en mettant à jour la logique de stratégie ou les balises régies, plutôt que de revoir chaque objet individuel tel qu’il est nécessaire avec les filtres de lignes au niveau de la table et les masques de colonne.

• Gouvernance centralisée : Étant donné que les stratégies peuvent être définies une fois et appliquées à de nombreux objets de données correspondants, les équipes de gouvernance peuvent gérer des contrôles dans de plus grandes parties du patrimoine de données avec moins de définitions de stratégie.

Ressources supplémentaires

• Étiquettes gouvernées
• Créer une stratégie
• Gérer les privilèges dans le catalogue Unity
• Filtres de lignes et masques de colonne
• Référence de table système du journal d’audit
• Exigences, quotas et limitations pour les stratégies de filtre de lignes et de masque de colonne