Privilèges des objets de données

Le modèle de gouvernance des données Azure Databricks vous permet d’accorder, de refuser et de révoquer l’accès à vos données à partir de Spark SQL par programmation. Ce modèle vous permet de contrôler l’accès aux objets sécurisables tels que les catalogues, les bases de données, les tables, les vues et les fonctions. Il permet également un contrôle d’accès affiné (à un sous-ensemble particulier d’une table, par exemple) en définissant des privilèges sur des vues dérivées créées à partir de requêtes arbitraires. l’analyseur de requêtes Azure Databricks SQL applique ces stratégies de contrôle d’accès au moment de l’exécution sur les clusters Azure Databricks avec le contrôle d’accès à la table activé et tous les points de terminaison de SQL.

Cet article décrit les privilèges, les objets et les règles de propriété qui composent le modèle de gouvernance des données Azure Databricks. Elle explique également comment accorder, refuser et révoquer des privilèges d’objet.

Spécifications

La configuration requise pour la gestion des privilèges d’objets dépend de votre environnement :

Databricks de science & des données et Databricks machine learning

Databricks SQL

Consultez la page Configuration requise pour l’administration de démarrage rapide.

Modèle de gouvernance des données

Cette section décrit le modèle de gouvernance des données Azure Databricks. L’accès aux objets de données sécurisables est régi par des privilèges.

Objets sécurisables

Les objets sécurisables sont les suivants :

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

    • DATABASE: contrôle l’accès à une base de données.
      • 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 ANONYMOUS FUNCTION.

    Remarque

    FUNCTIONles ANONYMOUS FUNCTION objets et 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 bases de données, les tables et les vues en lisant directement à partir du système de fichiers.

Privilèges

  • SELECT: donne un accès en lecture à un objet.
  • CREATE: donne la possibilité de créer un objet (par exemple, une table dans une base de données).
  • MODIFY: donne la possibilité d’ajouter, de supprimer et de modifier des données vers ou à partir d’un objet.
  • USAGE: n’offre aucune capacité, mais est une condition supplémentaire pour effectuer une action sur un objet de base de données.
  • READ_METADATA: donne la possibilité d’afficher un objet et ses métadonnées.
  • CREATE_NAMED_FUNCTION: donne la possibilité de créer une FDU nommée dans une base de données ou un catalogue existant.
  • MODIFY_CLASSPATH: donne la possibilité d’ajouter des fichiers au chemin d’accès de la classe Spark.
  • ALL PRIVILEGES: donne tous les privilèges (est traduit dans tous les privilèges ci-dessus).

Remarque

CREATE_NAMED_FUNCTIONles MODIFY_CLASSPATH privilèges et ne sont pas pris en charge dans les SQL Databricks.

USAGE limités

Pour effectuer une action sur un objet de base de données, un utilisateur doit disposer du USAGE privilège sur cette base de données en plus du privilège permettant d’effectuer cette action. L’une des conditions suivantes est satisfaite USAGE :

  • Être un administrateur
  • Disposer du USAGE privilège sur la base de données ou être dans un groupe qui possède le USAGE privilège sur la base de données
  • Disposer du USAGE privilège sur le CATALOG ou se trouver dans un groupe disposant du USAGE privilège
  • Être le propriétaire de la base de données ou se trouver dans un groupe propriétaire de la base de données

Même le propriétaire d’un objet à l’intérieur d’une base de données doit disposer du USAGE privilège pour pouvoir l’utiliser.

Par exemple, un administrateur peut définir un finance groupe et une accounting base de données à utiliser. Pour configurer une base de données que seule l’équipe Finance peut utiliser et partager, un administrateur effectue les opérations suivantes :

CREATE DATABASE accounting;
GRANT USAGE ON DATABASE accounting TO finance;
GRANT CREATE ON DATABASE accounting TO finance;

Avec ces privilèges, les membres du finance groupe peuvent créer des tables et des vues dans la accounting base de données. mais ne peut pas partager ces tables ou vues avec un principal qui n’a pas de USAGEaccounting base de données.

Databricks de la science & des données et comportement de la version de Databricks Runtime
  • Les clusters exécutant Databricks Runtime 7,3 LTS et versions ultérieures appliquent le USAGE privilège.
  • Les clusters exécutant Databricks Runtime 7,2 et versions antérieures n’appliquent pas le USAGE privilège.
  • Pour vous assurer que les charges de travail existantes fonctionnent sans modification, dans les espaces de travail qui utilisaient USAGE le contrôle d’accès à la table avant l’introduction de ont le USAGE privilège CATALOG accordé au users groupe. Si vous souhaitez tirer parti du USAGE privilège, vous devez exécuter puis, le cas REVOKE USAGE ON CATALOG FROM usersGRANT USAGE ... échéant.

Hiérarchie des privilèges

lorsque le contrôle d’accès à la table 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 sont 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 à toutes les bases de données dans le catalogue. De même, les privilèges accordés sur un DATABASE objet sont hérités par tous les objets de cette base de données. Ce modèle est vrai pour tous les objets sécurisables.

Si vous refusez des privilèges d’utilisateur sur une table, l’utilisateur ne peut pas voir la table en tentant de répertorier toutes les tables de la base de données. Si vous refusez des privilèges d’utilisateur sur une base de données, l’utilisateur ne peut pas voir que la base de données existe en tentant de répertorier toutes les bases de données du catalogue.

Propriété des objets

lorsque le contrôle d’accès à la table est activé sur un cluster ou un point de terminaison de SQL, un utilisateur qui crée une base de données, une table, une vue ou une fonction devient son propriétaire. Le propriétaire reçoit 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 propriétaires.

La propriété détermine si vous pouvez ou non accorder des privilèges sur des objets dérivés à d’autres utilisateurs. Par exemple, supposons que l’utilisateur A possède la table T et accorde SELECT le privilège de l’utilisateur B sur la table t. Espacé Bien que l’utilisateur B puisse sélectionner la table T, l’utilisateur B ne peut pas accorder de SELECT privilège sur la table t à l’utilisateur C. étant donné que l’utilisateur A est toujours le propriétaire de la table sous-jacente T. En outre, l’utilisateur B ne peut pas contourner Cette restriction consiste simplement à créer une vue V sur la table T et à accorder des privilèges sur SELECT vue à utilisateur C. Lorsque Azure Databricks vérifie les privilèges de l’utilisateur C pour accéder à la vue V, il vérifie également que le propriétaire de V et de la table sous-jacente T est le même. Si les propriétaires ne sont pas les mêmes, l’utilisateur C doit possèdent également SELECT des privilèges sur la table sous-jacente T.

Lorsque le contrôle d’accès à la table est désactivé sur un cluster, aucun propriétaire n’est inscrit lorsqu’une base de données, une table, une vue ou la fonction est créée. Pour tester si un objet a un propriétaire, exécutez SHOW GRANT ON <object-name> . Si vous ne voyez pas d’entrée avec ActionType OWN , l’objet n’a pas de propriétaire.

Assigner un propriétaire à un objet

Le propriétaire d’un objet ou d’un administrateur peut transférer la propriété d’un objet à l’aide de la ALTER <object> OWNER TO `<user-name>@<user-domain>.com` commande :

ALTER DATABASE <database-name> OWNER TO `<user-name>@<user-domain>.com`
ALTER TABLE <table-name> OWNER TO `group_name`
ALTER VIEW <view-name> OWNER TO `<user-name>@<user-domain>.com`

Utilisateurs et groupes

Les administrateurs et les propriétaires peuvent accorder des privilèges aux utilisateurs et aux groupes. Chaque utilisateur est identifié de manière unique par son nom d’utilisateur dans Azure Databricks (qui est généralement mappé à son adresse de messagerie). Tous les utilisateurs sont implicitement inclus dans le groupe « tous les utilisateurs », représenté comme users dans SQL.

Remarque

Vous devez placer les spécifications de l’utilisateur dans les battements ( ` ` ), et non dans les guillemets simples ( ' ' ).

Opérations et privilèges

Dans Azure Databricks, les utilisateurs administrateurs peuvent gérer tous les privilèges d’objet, avoir tous les privilèges accordés sur tous les éléments sécurisables et modifier le propriétaire de n’importe quel objet. Les propriétaires d’un objet peuvent effectuer n’importe quelle action sur cet objet, peuvent accorder des privilèges sur cet objet à d’autres principaux et transférer la propriété de l’objet à un autre principal. La seule limite aux privilèges d’un propriétaire concerne les objets dans une base de données ; pour interagir avec un objet dans une base de données, l’utilisateur doit également disposer de USAGE cette base de données.

le tableau suivant mappe SQL opérations aux privilèges requis pour effectuer cette opération.

Remarque

  • À tout endroit où un privilège sur une table, une vue ou une fonction est requis, USAGE est également requis sur la base de données dans laquelle il se trouve.
  • À tout endroit où une table est référencée dans une commande, un chemin d’accès peut également être référencé. Dans ces instances SELECTMODIFY , ou est obligatoire sur la ANY FILEUSAGE base de données et un autre privilège sur la table.
  • La propriété de l’objet est représentée ici comme OWN privilège.
Opération Privilèges requis
CLONE Capacité à SELECT partir de la table en cours de clonage, CREATE sur la base de données et MODIFY si la table est remplacée.
COPY INTO SELECT sur en ANY FILE cas de copie à partir d’un chemin d’accès, MODIFY sur la table en cours de copie dans.
CREATE BLOOMFILTER INDEX OWN sur la table en cours d’indexation.
CREATE DATABASE CREATE sur le CATALOG .
CREATE TABLE OWNUSAGE , Ou à la fois et CREATE sur la base de données.
CREATE VIEW OWNUSAGE , Ou à la fois et CREATE sur la base de données.
CREATE FUNCTION (externe) OWNOu USAGE et CREATE_NAMED_FUNCTION sur la base de données. Si une ressource est spécifiée, MODIFY_CLASSPATH on CATALOG est également requis.
CREATE FUNCTION (SQL) OWNOu USAGE et CREATE_NAMED_FUNCTION sur la base de données. Si une ressource est spécifiée, MODIFY_CLASSPATH on CATALOG est également requis.
ALTER DATABASE OWN sur la base de données.
ALTER TABLE Généralement OWN sur la table. MODIFY Si vous ajoutez ou supprimez uniquement des partitions.
ALTER VIEW OWN sur la vue.
DROP BLOOMFILTER INDEX OWN sur la table.
DROP DATABASE OWN sur la base de données.
DROP TABLE OWN sur la table.
DROP VIEW OWN sur la vue.
DROP FUNCTION OWN sur la fonction.
EXPLAIN READ_METADATA sur les tables et les vues.
DESCRIBE TABLE READ_METADATA sur la table.
DESCRIBE HISTORY OWN sur la table.
SELECT SELECT sur la table.
INSERT MODIFY sur la table.
RESTAURER LA TABLE MODIFY sur la table.
UPDATE MODIFY sur la table.
MERGE INTO MODIFY sur la table.
DELETE FROM MODIFY sur la table.
TRUNCATE TABLE MODIFY sur la table.
OPTIMIZE MODIFY sur la table.
VACUUM MODIFY sur la table.
FSCK REPAIR TABLE MODIFY sur la table.
MSCK OWN sur la table.
GRANT OWN sur l’objet.
SHOW GRANT OWN sur l’objet ou l’utilisateur soumis à l’octroi.
DENY OWN sur l’objet.
REVOKE OWN sur l’objet.

Important

Lorsque vous utilisez le contrôle d’accès aux tables, DROP TABLE les instructions respectent la casse. Si un nom de table est en minuscules et que le DROP TABLE fait référence au nom de la table à l’aide de la casse mixte ou en majuscules, l' DROP TABLE instruction échoue.

Gérer les privilèges des objets

Vous utilisez les GRANT opérations,, DENYREVOKE , MSCK et SHOW GRANT pour gérer des privilèges d’objet.

Remarque

  • Un propriétaire ou un administrateur d’un objet peut effectuer GRANT des DENY opérations,, REVOKE et SHOW GRANT . Toutefois, un administrateur ne peut pas refuser des privilèges ou révoquer des privilèges d’un propriétaire.

  • Un principal qui n’est pas un propriétaire ou un administrateur peut effectuer une opération uniquement si le privilège requis a été accordé.

  • Pour accorder, refuser ou révoquer un privilège pour tous les utilisateurs, spécifiez le mot clé après TO . Par exemple,

    GRANT SELECT ON ANY FILE TO users
    

Exemples

GRANT SELECT ON DATABASE <database-name> TO `<user>@<domain-name>`
GRANT SELECT ON ANONYMOUS FUNCTION TO `<user>@<domain-name>`
GRANT SELECT ON ANY FILE TO `<user>@<domain-name>`

SHOW GRANT `<user>@<domain-name>` ON DATABASE <database-name>

DENY SELECT ON <table-name> TO `<user>@<domain-name>`

REVOKE ALL PRIVILEGES ON DATABASE default FROM `<user>@<domain-name>`
REVOKE SELECT ON <table-name> FROM `<user>@<domain-name>`

GRANT SELECT ON ANY FILE TO users

Fonctions d’affichage dynamique

Azure Databricks comprend deux fonctions utilisateur qui vous permettent d’exprimer de manière dynamique les autorisations au niveau des colonnes et des lignes dans le corps d’une définition de vue.

  • current_user(): retourne le nom d’utilisateur actuel.
  • is_member(): déterminer si l’utilisateur actuel est membre d’un is_member()de Azure Databricks spécifique.

Remarque

Disponible dans Databricks Runtime 7,3 LTS et versions ultérieures. Toutefois, pour utiliser ces fonctions dans Databricks Runtime 7,3 LTS, vous devez définir la configuration Spark .

Prenons l’exemple suivant, qui combine les deux fonctions pour déterminer si un utilisateur dispose de 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

Permettre aux administrateurs de définir des privilèges de granularité fine pour plusieurs utilisateurs et groupes au sein d’une même vue est à la fois expressif et puissant, tout en économisant la surcharge d’administration.

Autorisations au niveau des colonnes

Grâce aux vues dynamiques, il est facile de limiter les colonnes qu’un utilisateur ou un groupe spécifique peut voir. Prenons l’exemple suivant, dans lequel seuls les utilisateurs qui appartiennent au auditors groupe peuvent voir les adresses de messagerie à partir de la sales_raw table. Au moment de l’analyse, Spark remplace l' CASE instruction 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_member('auditors') THEN email
    ELSE 'REDACTED'
  END AS email,
  country,
  product,
  total
FROM sales_raw

Autorisations au niveau des lignes

À l’aide des vues dynamiques, vous pouvez spécifier des autorisations jusqu’au niveau de la ligne ou du champ. Prenons l’exemple suivant, où seuls les utilisateurs qui appartiennent au managers groupe sont en mesure de voir les montants des transactions ( total colonne) supérieurs à $1 000 000,00 :

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

Masquage de données

Comme indiqué dans les exemples précédents, vous pouvez implémenter le masquage au niveau des colonnes pour empêcher les utilisateurs de voir des données de colonne spécifiques, sauf s’ils se trouvent dans le groupe approprié. étant donné que ces vues sont des SQL Spark 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 une analyse sur les domaines de messagerie, mais permet aux membres du auditors groupe d’afficher les adresses de messagerie 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_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END
  FROM sales_raw

Forum Aux Questions (FAQ)

Comment faire accorder, refuser ou révoquer un privilège pour tous les utilisateurs ?

Spécifiez le mot clé users après TO ou FROM . Par exemple :

GRANT SELECT ON TABLE database.table TO users

J’ai créé un objet, mais je ne peux pas le Rechercher, le supprimer ou le modifier.

cette erreur peut se produire si vous avez créé cet objet sur un cluster ou un point de terminaison de SQL sans contrôle d’accès à la table activé. À le contrôle d’accès à la table est désactivé sur un cluster ou un point de terminaison SQL, les propriétaires ne sont pas inscrits lorsqu’une base de données, une table ou une vue est créer. Un administrateur doit assigner un propriétaire à l’objet à l’aide de la commande suivante :

ALTER [DATABASE | TABLE | VIEW] <object-name> OWNER TO `<user-name>@<user-domain>.com`;

Comment faire accorder des privilèges sur les vues temporaires globales et locales ?

Les privilèges sur les vues temporaires globales et locales ne sont pas pris en charge. Temporaire locale les vues sont visibles uniquement au sein de la même session, et les vues créées dans la global_temp base de données sont visible pour tous les utilisateurs qui partagent un cluster ou un point de terminaison de SQL. Toutefois, les privilèges sur les tables et les vues sous-jacentes référencé par n’importe quel affichage temporaire est appliqué.

Comment faire accorder à un utilisateur ou à un groupe des privilèges sur plusieurs tables à la fois ?

Une instruction Grant, Deny ou REVOKE ne peut être appliquée qu’à un seul objet à la fois. La méthode recommandée l’organisation et l’octroi de privilèges sur plusieurs tables à un principal s’effectue via des bases de données. Octroi d’un SELECT le privilège principal d’une base de données accorde implicitement ces SELECT privilèges principaux sur toutes les tables et vues de cette base de données. Par exemple, si une base de données D contient des tables T1 et T2, et une l’administrateur émet la GRANT commande suivante :

GRANT USAGE, SELECT ON DATABASE D TO `<user>@<domain-name>`

Le principal <user>@<domain-name> peut sélectionner les tables T1 et T2, ainsi que toutes les tables et vues créées dans la base de données D à l’avenir.

Comment faire accorder des privilèges utilisateur sur toutes les tables à l’exception d’une seule ?

Vous accordez des SELECT privilèges à la base de données, puis vous refusez SELECT le privilège pour la table spécifique pour laquelle vous souhaitez restreindre l’accès.

GRANT USAGE, SELECT ON DATABASE D TO `<user>@<domain-name>`
DENY SELECT ON TABLE D.T TO `<user>@<domain-name>`

Le principal <user>@<domain-name> peut sélectionner toutes les tables dans D, à l’exception de D.T.

Un utilisateur dispose de SELECT privilèges sur une vue de la table T, mais lorsque cet utilisateur tente de SELECT partir de cette vue, il obtient l’erreur User does not have privilege SELECT on table .

Cette erreur courante peut se produire pour l’une des raisons suivantes :

  • la table T n’a aucun propriétaire inscrit, car elle a été créée à l’aide d’un cluster ou d’un point de terminaison SQL pour lequel le contrôle d’accès à la table est désactivé.
  • Le fournisseur du SELECT privilège sur une vue de la table t n’est pas le propriétaire de la table t ou l’utilisateur n’a pas également le SELECT privilège SELECT sur la table t.

Supposons qu’il existe une table T appartenant à un. Un propriétaire de la vue v1 sur T et B possède la vue v2 sur T.

  • Un utilisateur peut sélectionner sur v1 lorsqu’un a accordé SELECT des privilèges sur la vue v1.
  • Un utilisateur peut sélectionner sur v2 quand un a accordé des SELECT privilèges sur la table T et B a accordé SELECT des privilèges sur v2.

Comme décrit dans la section propriété de l' objet , ces conditions garantissent que seul le propriétaire d’un objet peut accorder à d’autres utilisateurs l’accès à cet objet.

J’ai essayé de s’exécuter sc.parallelize sur un cluster avec le contrôle d’accès à la table activé et cela échoue.

sur les clusters avec le contrôle d’accès de table activé, vous pouvez utiliser uniquement les api Spark SQL et Python tableau. La L’API RDD n’est pas autorisée pour des raisons de sécurité, car Azure Databricks n’a pas la possibilité d’inspecter et autorisent le code dans un RDD.