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

Cette page présente ABAC, comment elle utilise des balises, des stratégies et des fonctions définies par l’utilisateur pour contrôler les lignes que les utilisateurs peuvent voir et comment les valeurs de colonne sont présentées et ses avantages. Cette page couvre également les autorisations requises pour configurer ABAC et la séparation des tâches qu’elle permet à l’ensemble des é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 éléments 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.

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 éléments sécurisables du catalogue Unity, tels que les catalogues, les schémas, les tables et les colonnes, 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 balises héritent des catalogues et schémas parents par rapport aux tables, mais pas des tables aux colonnes. Vous pouvez remplacer les balises héritées à n’importe quel niveau, mais les balises au niveau des colonnes 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'entité sécurisable où la politique est attachée, spécifiée par la ON clause. L'attachement d'une politique à un élément sécurisable signifie que les conditions de politique sont évaluées pour tous les objets du type spécifié dans la clause FOR, sur cet élément sécurisable et tous leurs descendants.
  • Les étendues de stratégie prises en charge aujourd’hui sont CATALOG, SCHEMAou TABLE.
  • Les tables, y compris les tables de diffusion en continu et les vues matérialisées, sont actuellement le seul type sécurisable pris en charge, spécifié à l’aide de la FOR TABLES clause.
  • Une stratégie attachée à un catalogue est évaluée par rapport à toutes les tables de ce catalogue. Une stratégie attachée à un schéma est évaluée par rapport à toutes les tables de 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 ou un masque de colonne. L’action est implémentée par une fonction définie par l’utilisateur (UDF) qui définit la logique de filtrage ou de masquage. 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 deux types de stratégie : les stratégies de filtre de lignes et les stratégies de masque de colonne. Les deux nécessitent des fonctions définies par l’utilisateur pour implémenter la logique de filtrage ou de masquage.

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 USING COLUMNS clause transmet des arguments à la fonction UDF. 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. 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 (UDF) sont recommandées pour de meilleures performances. Les fonctions définies par l’utilisateur Python inscrites dans le catalogue Unity 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.

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. S'il est omis, la valeur par défaut est 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 :

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 de colonne. 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é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 les fonctions définies par l’utilisateur 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.

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 interrogent les résultats.

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 balises régies aux catalogues, schémas, tables ou colonnes. Par exemple, balisez des colonnes qui contiennent des informations d’identification personnelle avec pii : ssn. 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 politique à une portée, telle qu’un catalogue ou un schéma. La stratégie spécifie à qui elle s’applique, quelles conditions elle évalue et la fonction UDF qui implémente la logique de filtrage ou de masquage.

   • Autorisations requises : MANAGE autorisation ou propriété d’objet sur l’élément sécurisable où la stratégie est attachée (catalogue, schéma ou table) et EXECUTE privilège sur la fonction UDF.

4. Créez des objets de données. Les créateurs de données créent des tables dans les étendues auxquelles ils ont été autorisés à accéder. Les nouvelles tables héritent des balises des objets parents tels que les catalogues et les schémas. 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. Interroger des données. Lorsqu’un consommateur de données interroge une table dans l’étendue de la stratégie, la stratégie est évaluée automatiquement. Si la table ou les colonnes correspondent aux conditions de la stratégie et que l’utilisateur n’est pas exempté, le consommateur voit les données filtrées ou masquées.

   • Autorisations requises : les utilisateurs doivent disposer d’autorisations sur la table, telles que SELECT, par le biais d’un octroi direct d’objet. Les politiques de filtrage de lignes et les politiques de masquage de colonnes ABAC n'accordent pas d'autorisations par elles-mêmes. Ils filtrent uniquement les enregistrements ou masquent les colonnes des tables auxquelles un utilisateur peut déjà accéder.

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.

Plus d’informations

• Balises régies
• CREATE POLICY
• Gérer les privilèges dans le catalogue Unity
• Filtres de lignes et masques de colonne
• Informations de référence sur la table système du journal d’audit
• Exigences, quotas et limitations ABAC