Privilèges et objets sécurisables dans le metastore Hive (hérité)

  • Article

Cet article décrit le modèle de privilèges pour le metastore Hive Azure Databricks hérité, qui est intégré à chaque espace de travail Azure Databricks. Il décrit également comment octroyer, refuser et révoquer des privilèges pour les objets dans le metastore Hive intégré. Unity Catalog utilise un modèle différent pour octroyer des privilèges. Consultez Privilèges Unity Catalog et objets sécurisables.

Notes

Le contrôle d’accès aux tables pour les données gérées par le metastore Hive est un modèle de gouvernance des données hérité. Databricks vous recommande de mettre à niveau les tables gérées par le metastore Hive vers le metastore Unity Catalog. Unity Catalog facilite la sécurité et la gouvernance de vos données en fournissant un emplacement central pour administrer et auditer l’accès aux données dans plusieurs espaces de travail de votre compte. Pour en savoir plus sur la différence entre le modèle de privilèges hérité et le modèle de privilège Unity Catalog, consultez Utilisation d’Unity Catalog et du metastore Hive hérité.

Spécifications

Notes

  • Le contrôle d’accès aux données est toujours activé dans Databricks SQL, même si le contrôle d’accès aux tables n’est pas activé pour l’espace de travail.
  • Si le contrôle d’accès aux tables est activé pour l’espace de travail et que vous avez déjà spécifié des listes de contrôle d’accès (privilèges octroyés et refusés) dans l’espace de travail, ces listes de contrôle d’accès sont respectées dans Databricks SQL.

Gérer les privilèges sur les objets dans le metastore Hive

Les privilèges sur les objets de données gérés par le metastore Hive peuvent être accordés par un administrateur d’espace de travail ou par le propriétaire d’un objet. Vous pouvez gérer les privilèges pour les objets de metastore Hive à l’aide de commandes SQL.

Pour gérer les privilèges dans SQL, vous utilisez des instructions GRANT, REVOKE, DENY, MSCK et SHOW GRANTS dans un notebook ou l’éditeur de requête SQL Databricks, à l’aide de la syntaxe :

GRANT privilege_type ON securable_object TO principal

Où :

Pour accorder un privilège à tous les utilisateurs de votre espace de travail, accordez le privilège au groupe users. Par exemple :

GRANT SELECT ON TABLE <schema-name>.<table-name> TO users

Pour plus d’informations sur la gestion des privilèges pour les objets dans le metastore Hive à l’aide des commandes SQL, consultez Privilèges et objets sécurisables dans le metastore Hive.

Vous pouvez également gérer le contrôle d'accès aux tableaux dans une configuration entièrement automatisée à l’aide du fournisseur Databricks Terraform et de databricks_sql_permissions.

Propriété des objets

Lorsque le contrôle d’accès aux tables est activé sur un cluster ou un entrepôt SQL, un utilisateur qui crée un schéma, une table, un affichage ou une fonction en devient le propriétaire. Le propriétaire reçoit tous les privilèges et peut accorder des privilèges à d’autres utilisateurs.

Des groupes peuvent posséder des objets, auquel cas tous leurs membres sont considérés comme leurs propriétaires.

Le propriétaire d’un objet ou un administrateur d’espace de travail peuvent transférer la propriété d’un objet à l’aide de la commande suivante :

ALTER <object> OWNER TO `<user-name>@<user-domain>.com`

Remarque

Lorsque le contrôle d’accès aux tables est désactivé sur un cluster ou un entrepôt SQL, les propriétaires ne sont pas inscrits lors de la création d’un schéma, d’une table ou d’un affichage. Un administrateur d’espace de travail doit attribuer un propriétaire à l’objet à l’aide de la commande ALTER <object> OWNER TO.

Objets sécurisables dans le metastore Hive

Les objets sécurisables sont les suivants :

  • CATALOG : contrôle l’accès à l’ensemble du catalogue de données.

    • SCHEMA : contrôle l’accès à un schéma.
      • TABLE : contrôle l’accès à une table managée ou externe.
      • VIEW : contrôle l’accès aux vues SQL.
      • FUNCTION : contrôle l’accès à une fonction nommée.

  • ANONYMOUS FUNCTION : contrôle l’accès aux fonctions anonymes ou temporaires.

    Notes

    Les objets ANONYMOUS FUNCTION ne sont pas pris en charge dans Databricks SQL.

  • ANY FILE : contrôle l’accès au système de fichiers sous-jacent.

    Avertissement

    Les utilisateurs autorisés à accéder à ANY FILE peuvent contourner les restrictions placées sur le catalogue, les schémas, les tables et les affichages en lisant directement à partir du système de fichiers.

Remarque

Les privilèges sur des affichages temporaires globaux et locaux ne sont pas pris en charge. Les affichages temporaires locaux sont visibles uniquement au sein de la même session, et les affichages créés dans le schéma global_temp sont visibles par tous les utilisateurs partageant un cluster ou un entrepôt SQL. Toutefois, les privilèges sur les tables et affichages sous-jacents référencés par n’importe quel affichage temporaire sont appliqués.

Privilèges que vous pouvez accorder sur les objets de metastore Hive

  • SELECT : octroie l’accès en lecture à un objet.
  • CREATE : offre la possibilité de créer un objet (par exemple, une table dans un schéma).
  • MODIFY : offre la possibilité d’ajouter, de supprimer et de modifier des données dans un objet.
  • USAGE : n’offre aucune possibilité, mais constitue une exigence supplémentaire pour effectuer une action sur un objet de schéma.
  • READ_METADATA : offre la possibilité d’afficher un objet et ses métadonnées.
  • CREATE_NAMED_FUNCTION : offre la possibilité de créer une fonction définie par l'utilisateur nommée dans un catalogue ou un schéma existants.
  • MODIFY_CLASSPATH : offre la possibilité d’ajouter des fichiers au chemin d’accès de la classe Spark.
  • ALL PRIVILEGES : octroie tous les privilèges (se traduit dans tous les privilèges ci-dessus).

Notes

Le privilège MODIFY_CLASSPATH n’est pas pris en charge dans Databricks SQL.

USAGE, privilège

Pour effectuer une action sur un objet de schéma dans le metastore Hive, un utilisateur doit disposer du privilège USAGE sur ce schéma en plus des privilèges nécessaires pour effectuer cette action. Les éléments suivants satisfont à l’exigence associée au privilège USAGE :

  • Être administrateur d’espace de travail
  • Disposer du privilège USAGE sur le schéma ou appartenir à un groupe disposant du privilège USAGE
  • Disposer du privilège USAGE sur le CATALOG ou appartenir à un groupe disposant du privilège USAGE
  • Être le propriétaire du schéma ou figurer qui en est propriétaire

Même le propriétaire d’un objet à l’intérieur d’un schéma doit disposer du privilège USAGE pour pouvoir l’utiliser.

Hiérarchie des privilèges

Lorsque le contrôle d’accès aux tables est activé sur l’espace de travail et sur tous les clusters, les objets SQL dans Azure Databricks sont hiérarchiques, et les privilèges hérités vers le bas. Cela signifie que l’octroi ou le refus d’un privilège sur le CATALOG autorise ou refuse automatiquement le privilège à tous les schémas dans le catalogue. De même, les privilèges accordés sur un objet de schéma sont hérités par tous les objets de ce schéma. Ce modèle est vrai pour tous les objets sécurisables.

Si vous refusez à un utilisateur des privilèges sur une table, cet utilisateur ne peut pas voir celle-ci en tentant d’afficher la liste de toutes les tables dans le schéma. Si vous refusez à un utilisateur des privilèges sur un schéma, cet utilisateur ne peut pas voir que le schéma existe en tentant d’afficher la liste de tous les schémas dans le catalogue.

Fonctions d’affichage dynamique

Azure Databricks comprend deux fonctions utilisateur qui vous permettent d’exprimer dynamiquement des autorisations au niveau des colonnes et des lignes dans le corps d’une définition d’affichage gérée par le metastore Hive.

  • current_user() : retourner le nom d’utilisateur actuel.
  • is_member() : déterminer si l’utilisateur actuel est membre d’un groupe Azure Databricks spécifique au niveau de l’espace de travail.

L’exemple suivant combine les deux fonctions pour déterminer si un utilisateur a l’appartenance au groupe appropriée :

-- Return: true if the user is a member and false if they are not
SELECT
  current_user as user,
-- Check to see if the current user is a member of the "Managers" group.
  is_member("Managers") as admin

Autorisations au niveau des colonnes

Vous pouvez utiliser des affichages dynamiques pour limiter les colonnes qu’un groupe ou un utilisateur spécifique peut voir. Prenons l’exemple suivant, où seuls les utilisateurs appartenant au groupe auditors peuvent voir les adresses e-mail de la table sales_raw. Au moment de l’analyse, Spark remplace l’instruction CASE par le littéral 'REDACTED' ou la colonne email. Ce comportement autorise toutes les optimisations de performances habituelles fournies par Spark.

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN
    is_group_member('auditors') THEN email
    ELSE 'REDACTED'
  END AS email,
  country,
  product,
  total
FROM sales_raw

Autorisations au niveau des lignes

Les affichages dynamiques vous permettent de spécifier des autorisations jusqu’au niveau de la ligne ou du champ. Prenons l’exemple suivant, où seuls les utilisateurs appartenant au groupe managers peuvent voir les montants de transactions (colonne total) supérieurs à 1 000 000 USD :

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  country,
  product,
  total
FROM sales_raw
WHERE
  CASE
    WHEN is_group_member('managers') THEN TRUE
    ELSE total <= 1000000
  END;

Masquage de données

Comme indiqué dans les exemples précédents, vous pouvez implémenter un masquage au niveau des colonnes pour empêcher les utilisateurs de voir des données de colonne spécifiques, sauf s’ils appartiennent au groupe approprié. Étant donné que ces affichages sont du Spark SQL standard, vous pouvez effectuer des types de masquages plus avancés avec des expressions SQL plus complexes. L’exemple suivant permet à tous les utilisateurs d’effectuer une analyse sur des domaines de courrier, et permet aux membres du groupe auditors d’afficher les adresses e-mail complètes des utilisateurs.

-- The regexp_extract function takes an email address such as
-- user.x.lastname@example.com and extracts 'example', allowing
-- analysts to query the domain name

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  region,
  CASE
    WHEN is_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END
  FROM sales_raw