Hive-Metastore-Berechtigungen und sicherungsfähige Objekte (Legacy)

In diesem Artikel wird das Berechtigungsmodell für den Legacy-Hive-Metastore beschrieben, der in jedem Azure Databricks-Arbeitsbereich integriert ist. Außerdem wird beschrieben, wie Berechtigungen für Objekte im integrierten Hive-Metastore gewährt, verweigert und widerrufen werden. Unity Catalog verwendet ein anderes Modell zum Erteilen von Berechtigungen. Weitere Informationen finden Sie unter Unity Catalog-Berechtigungen und sicherungsfähige Objekte.

Hinweis

Die Tabellenzugriffssteuerung für Daten, die vom Hive-Metastore verwaltet werden, ist ein Legacy-Datengovernancemodell. Databricks empfiehlt, ein Upgrade der vom Hive-Metastore verwalteten Tabellen auf den Unity Catalog-Metastore durchzuführen. Unity Catalog vereinfacht die Sicherheit und Governance Ihrer Daten durch die Bereitstellung eines zentralen Ortes zum Verwalten und Überwachen des Datenzugriffs über mehrere Arbeitsbereiche in Ihrem Konto. Weitere Informationen dazu, wie sich das Legacy-Berechtigungsmodell vom Unity Catalog-Berechtigungsmodell unterscheidet, finden Sie unter Arbeiten mit Unity Catalog und dem Legacy-Hive-Metastore.

Anforderungen

Hinweis

  • Die Datenzugriffssteuerung ist in Databricks SQL auch dann immer aktiviert, wenn die Tabellenzugriffssteuerung für den Arbeitsbereich nicht aktiviert ist.
  • Wenn die Tabellenzugriffssteuerung für den Arbeitsbereich aktiviert ist und Sie im Arbeitsbereich bereits ACLS (gewährte und verweigerte Berechtigungen) angegeben haben, werden diese ACLs in Databricks SQL berücksichtigt.

Verwalten von Berechtigungen für Objekte im Hive-Metastore

Berechtigungen für Datenobjekte, die vom Hive-Metastore verwaltet werden, können entweder von einem Arbeitsbereichsadministrator oder dem Besitzer eines Objekts gewährt werden. Sie können Berechtigungen für Hive-Metastore-Objekte mithilfe von SQL-Befehlen verwalten.

Zum Verwalten von Berechtigungen in SQL verwenden Sie GRANT, REVOKE-, DENY-, MSCK- und SHOW GRANTS-Anweisungen in einem Notebook oder im SQL-Abfrage-Editor von Databricks mithilfe dieser Syntax:

GRANT privilege_type ON securable_object TO principal

Hinweis:

Um allen Benutzer*innen in Ihrem Arbeitsbereich eine Berechtigung zu gewähren, gewähren Sie diese Berechtigung auf Ebene der Gruppe users. Beispiel:

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

Weitere Informationen zum Verwalten von Berechtigungen für Objekte im Hive-Metastore mithilfe von SQL-Befehlen finden Sie unter Berechtigungen und sicherungsfähige Objekte im Hive-Metastore.

Sie können die Tabellenzugriffssteuerung auch in einem vollständig automatisierten Setup mit dem Databricks Terraform-Anbieter und databricks_sql_permissions verwalten.

Objektbesitz

Wenn die Tabellenzugriffssteuerung für einen Cluster oder ein SQL-Warehouse aktiviert ist, wird ein Benutzer, der ein Schema, eine Tabelle, eine Ansicht oder eine Funktion erstellt, zu dessen/deren Besitzer. Dem Besitzer werden alle Berechtigungen gewährt, und er kann anderen Benutzern Berechtigungen erteilen.

Gruppen können Objekte besitzen. In diesem Fall werden alle Mitglieder dieser Gruppe als Besitzer betrachtet.

Entweder die Besitzer*innen eines Objekts oder Arbeitsbereichsadministrator*innen können den Besitz an einem Objekt mithilfe des folgenden Befehls übertragen:

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

Hinweis

Wenn die Tabellenzugriffssteuerung in einem Cluster oder SQL-Warehouse deaktiviert ist, werden Besitzer beim Erstellen eines Schemas, einer Tabelle oder einer Sicht nicht registriert. Arbeitsbereichsadministrator*innen müssen dem Objekt mithilfe des Befehls ALTER <object> OWNER TO einen Besitzer oder eine Besitzerin zuweisen.

Sicherungsfähige Objekte im Hive-Metastore

Sicherungsfähige Objekte sind:

  • CATALOG: Steuert den Zugriff auf den gesamten Datenkatalog.

    • SCHEMA: Steuert den Zugriff auf ein Schema.
      • TABLE: Steuert den Zugriff auf eine verwaltete oder externe Tabelle.
      • VIEW: Steuert den Zugriff auf SQL-Sichten.
      • FUNCTION: Steuert den Zugriff auf eine benannte Funktion.
  • ANONYMOUS FUNCTION: Steuert den Zugriff auf anonyme oder temporäre Funktionen.

    Hinweis

    ANONYMOUS FUNCTION-Objekte werden in Databricks SQL nicht unterstützt.

  • ANY FILE: Steuert den Zugriff auf das zugrunde liegende Dateisystem.

    Warnung

    Benutzer, die Zugriff auf ANY FILE gewährt haben, können die Einschränkungen für Katalog, Schemas, Tabellen und Sichten umgehen, indem sie direkt aus dem Dateisystem lesen.

Hinweis

Berechtigungen für globale und lokale temporäre Sichten werden nicht unterstützt. Lokale temporäre Sichten sind nur innerhalb derselben Sitzung sichtbar, und im Schema global_temp erstellte Ansichten sind für alle Benutzer sichtbar, die einen Cluster oder ein SQL-Warehouse gemeinsam nutzen. Berechtigungen für die zugrunde liegenden Tabellen und Sichten, auf die von temporären Sichten verwiesen wird, werden jedoch erzwungen.

Berechtigungen, die Sie für Hive-Metastore-Objekte gewähren können

  • SELECT: Gewährt Lesezugriff auf ein Objekt.
  • CREATE: Gewährt die Fähigkeit, ein Objekt zu erstellen (z. B. eine Tabelle in einem Schema).
  • MODIFY: Ermöglicht das Hinzufügen, Löschen und Ändern von Daten zu oder aus einem Objekt.
  • USAGE: Bietet keine Funktionen, ist aber eine zusätzliche Anforderung zum Ausführen einer Aktion für ein Schemaobjekt.
  • READ_METADATA: Gewährt die Fähigkeit, ein Objekt und seine Metadaten anzuzeigen.
  • CREATE_NAMED_FUNCTION: Gewährt die Fähigkeit, eine benannte UDF in einem bestehenden Katalog oder Schema zu erstellen.
  • MODIFY_CLASSPATH: Ermöglicht das Hinzufügen von Dateien zum Spark-Klassenpfad.
  • ALL PRIVILEGES: Gewährt alle Berechtigungen (wird in alle oben genannten Berechtigungen übersetzt).

Hinweis

Die MODIFY_CLASSPATH-Berechtigung wird in Databricks SQL nicht unterstützt.

USAGE-Berechtigung

Um eine Aktion für ein Schemaobjekt im Hive-Metastore durchzuführen, muss ein Benutzer zusätzlich zu der Berechtigung zum Ausführen dieser Aktion über die Berechtigung „USAGE“ für dieses Schema verfügen. Jede der folgenden Bedingungen erfüllt die USAGE-Anforderung:

  • Ein Arbeitsbereichsadministrator sein
  • Der Benutzer verfügt über die Berechtigung USAGE für das Schema oder ist Mitglied einer Gruppe mit der USAGE-Berechtigung für das Schema.
  • Der Benutzer verfügt über die Berechtigung USAGE für den CATALOG oder ist Mitglied einer Gruppe, die über die Berechtigung USAGE verfügt.
  • Der Benutzer ist Besitzer des Schemas oder Mitglied einer Gruppe, die Besitzer des Schemas ist.

Selbst der Besitzer eines Objekts innerhalb eines Schemas muss zur Verwendung über die Berechtigung USAGE verfügen.

Berechtigungshierarchie

Wenn die Tabellenzugriffssteuerung im Arbeitsbereich und in allen Clustern aktiviert ist, sind SQL Objekte in Azure Databricks hierarchisch, und Berechtigungen werden nach unten vererbt. Dies bedeutet, dass durch das Erteilen oder Verweigern einer Berechtigung für CATALOG diese für alle Schemas im Katalog automatisch gewährt oder verweigert werden. Ebenso werden die einem Schemaobjekt gewährten Berechtigungen von allen Objekten in diesem Schema geerbt. Dieses Muster gilt für alle sicherungsfähigen Objekte.

Werden einem Benutzer die Berechtigungen für eine Tabelle verweigert, kann er die Tabelle nicht anzeigen, indem er versucht, alle Tabellen im Schema aufzulisten. Werden einem Benutzer Berechtigungen für ein Schema verweigert, kann er nicht sehen, dass das Schema vorhanden ist, indem er versucht, alle Schemas im Katalog aufzulisten.

Funktionen für dynamische Sichten

Azure Databricks enthält zwei Benutzerfunktionen, mit denen Sie Berechtigungen auf Spalten- und Zeilenebene dynamisch im Text der Definition einer Sicht ausdrücken können, die vom Hive-Metastore verwaltet wird.

  • current_user(): Gibt den aktuellen Benutzernamen zurück.
  • is_member(): Bestimmt auf Arbeitsbereich-Ebene, ob der aktuelle Benutzer Mitglied einer bestimmten Azure Databricks-Gruppe ist.

Das folgende Beispiel kombiniert beide Funktionen, um zu bestimmen, ob ein Benutzer über die entsprechende Gruppenmitgliedschaft verfügt:

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

Berechtigungen auf Spaltenebene

Sie können dynamische Ansichten verwenden, um die Spalten einzuschränken, die einer bestimmten Gruppe oder einem bestimmten Benutzers angezeigt werden. Betrachten Sie das folgende Beispiel, in dem nur Benutzer, die der Gruppe auditors angehören, E-Mail-Adressen aus der Tabelle sales_raw sehen können. Zur Analysezeit ersetzt Spark die CASE-Anweisung entweder durch das Literal 'REDACTED' oder die Spalte email. Dieses Verhalten ermöglicht alle üblichen Leistungsoptimierungen, die von Spark bereitgestellt werden.

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

Zeilenspezifische Berechtigungen

Mit dynamischen Sichten können Sie Berechtigungen bis auf Zeilen- oder Feldebene festlegen. Betrachten Sie das folgende Beispiel, in dem nur Benutzer, die der Gruppe managers angehören, Transaktionsbeträge (Spalte total) sehen können, die größer als 1.000.000,00 USD sind:

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;

Datenmaskierung

Wie in den vorherigen Beispielen gezeigt, können Sie die Maskierung auf Spaltenebene implementieren, um zu verhindern, dass Benutzer bestimmte Spaltendaten sehen, es sei denn, sie gehören der richtigen Gruppe an. Da es sich bei diesen Sichten um standardmäßiges Spark-SQL handelt, können Sie komplexere Arten der Maskierung mit komplexeren SQL-Ausdrücken erreichen. Im folgenden Beispiel können alle Benutzer Analysen für E-Mail-Domänen durchführen, aber Mitgliedern der Gruppe auditors werden die vollständigen E-Mail-Adressen der Benutzer angezeigt.

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