Aller au contenu principal
Dernière mise à jour le

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

Cet article décrit le modèle de privilèges pour le Hive metastore hérité de Databricks, qui est intégré à chaque workspace Databricks. Il décrit également comment accorder, refuser et révoquer des privilèges pour les objets du Hive metastore intégré. Unity Catalog utilise un modèle différent pour l'octroi de privilèges. Consultez Référence des privilèges Unity Catalog.

remarque

Le contrôle d'accès aux tables pour les données gérées par le Hive metastore est un modèle de gouvernance des données hérité. Databricks vous recommande de mettre à niveau les tables gérées par le Hive metastore vers le metastore Unity Catalog. Unity Catalog simplifie 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 à travers 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èges de Unity Catalog, consultez Utiliser le Hive metastore hérité en parallèle avec Unity Catalog.

Exigences​

remarque
  • 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 le Workspace.
  • Si le contrôle d'accès aux tables est activé pour le workspace et que vous avez déjà spécifié des ACL (privilèges accordés et refusés) dans le workspace, ces ACL sont respectées dans Databricks SQL.

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

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

Pour gérer les privilèges en SQL, vous utilisez les instructions GRANT, REVOKE, DENY, MSCK et SHOW GRANTS dans un Notebook ou l'éditeur de query Databricks SQL, en utilisant la syntaxe :

SQL
GRANT privilege_type ON securable_object TO principal

Où :

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

SQL
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 Hive metastore à l'aide des commandes SQL, consultez Privilèges et objets sécurisables dans le Hive metastore.

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

Propriété de l'objet​

Lorsqu'le contrôle d'accès aux tables est activé sur un cluster ou un SQL Warehouse, un utilisateur qui crée un schéma, une table, une vue ou une fonction en devient le propriétaire. Le propriétaire se voit octroyer tous les privilèges et peut accorder des privilèges à d'autres utilisateurs.

Les groupes peuvent posséder des objets, auquel cas tous les membres de ce groupe sont considérés comme des propriétaires.

Soit le propriétaire d'un objet, soit un administrateur Workspace peut transférer la propriété d'un objet en utilisant la commande suivante :

SQL
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 SQL warehouse, les propriétaires ne sont pas enregistrés lors de la création d'un schéma, d'une table ou d'une vue. Un administrateur de Workspace doit attribuer un propriétaire à l'objet à l'aide de la commande ALTER <object> OWNER TO.

Objets sécurisables dans le Hive metastore​

Les objets sécurisables sont :

  • CATALOG: contrôle l'accès à l'intégralité du data catalog.

    • SCHEMA: contrôle l’accès à un schéma.
      • TABLE: contrôle l'accès à une table géré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.

remarque

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

  • ANY FILEContrôle l'accès au système de fichiers sous-jacent.
attention

Les utilisateurs auxquels l'accès à ANY FILE est accordé peuvent contourner les restrictions imposées sur le catalogue, les schémas, les tables et les vues en lisant directement à partir du système de fichiers.

remarque

Les privilèges sur les vues temporaires globales et locales ne sont pas pris en charge. Les vues temporaires locales ne sont visibles que dans la même session, et les vues créées dans le schéma global_temp sont visibles par tous les utilisateurs partageant un cluster ou un SQL Warehouse. Cependant, les privilèges sur les tables et vues sous-jacentes référencées par toute vue temporaire sont appliqués.

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

  • SELECT: donne un accès en lecture à un objet.
  • CREATE: permet de créer un objet (une table dans un schéma, par exemple).
  • MODIFY: donne la possibilité d'ajouter, de supprimer et de modifier des données vers ou depuis un objet.
  • USAGE: ne confère aucune capacité, mais constitue une exigence supplémentaire pour effectuer toute action sur un objet de schéma.
  • READ_METADATA: donne la possibilité de visualiser un objet et ses métadonnées.
  • CREATE_NAMED_FUNCTION: permet de créer une UDF nommée dans un catalogue ou un schéma existant.
  • MODIFY_CLASSPATH: permet d'ajouter des fichiers au chemin de classe Spark.
  • ALL PRIVILEGES: donne tous les privilèges (converti en tous les privilèges ci-dessus).
remarque

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

PrivilègeUSAGE​

Pour effectuer une action sur un objet de schéma dans le Hive metastore, un utilisateur doit disposer du privilège USAGE sur ce schéma, en plus du privilège d'effectuer cette action. L'une des conditions suivantes satisfait à l'exigence USAGE :

  • Soyez un administrateur de Workspace
  • Avoir le privilège USAGE sur le schéma ou faire partie d'un groupe ayant le privilège USAGE sur le schéma
  • Disposez du privilège USAGE sur le CATALOG ou faites partie d'un groupe disposant du privilège USAGE
  • Être le propriétaire du schéma ou faire partie d'un groupe propriétaire du schéma

Même le propriétaire d'un objet dans 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 le workspace et sur tous les clusters, les objets SQL dans Databricks sont hiérarchiques et les privilèges sont hérités vers le bas. Cela signifie que l’octroi ou le refus d’un privilège sur le CATALOG accorde ou refuse automatiquement le privilège à tous les schémas du 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 les privilèges d'un utilisateur sur une table, l'utilisateur ne pourra pas voir la table en essayant de lister toutes les tables dans le schéma. Si vous refusez les privilèges d'un utilisateur sur un schéma, l'utilisateur ne pourra pas voir que le schéma existe en essayant de lister tous les schémas dans le catalogue.

Fonctions de vue dynamique​

Databricks inclut deux fonctions utilisateur qui vous permettent d'exprimer des autorisations au niveau des colonnes et des lignes de manière dynamique dans le corps d'une définition de vue gérée par le Hive metastore.

  • current_user(): renvoie le nom d'utilisateur actuel.
  • is_member(): déterminer si l'utilisateur actuel est membre d'un groupe Databricks spécifique au niveau du Workspace.

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

SQL
-- 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 vues dynamiques pour limiter les colonnes qu'un groupe ou un utilisateur spécifique peut voir. Considérez l'exemple suivant où seuls les utilisateurs qui appartiennent 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 permet toutes les optimisations de performance habituelles fournies par Spark.

SQL
-- 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​

À l'aide de vues dynamiques, vous pouvez spécifier des autorisations jusqu'au niveau de la ligne ou du champ. Considérez l'exemple suivant, où seuls les utilisateurs appartenant au groupe managers peuvent voir les montants de transaction (colonne total) supérieurs à 1 000 000,00 $ :

SQL
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 le montrent 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 bon groupe. Étant donné que ces vues sont des Spark SQL standard, vous pouvez effectuer des types de masquage plus avancés avec des expressions SQL plus complexes. L'exemple suivant permet à tous les utilisateurs d'effectuer des analyses sur les domaines de messagerie, mais permet aux membres du groupe auditors de voir les adresses e-mail complètes des utilisateurs.

SQL
-- 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
Sur cette page