Gründe für die Verwendung von ABAC im Vergleich zu Zeilenfiltern auf Tabellenebene und Spaltenmasken

Unity Catalog unterstützt zwei Ansätze für die Sicherheit auf Zeilenebene und Spaltenebene: ABAC-Richtlinien und Zeilenfilter auf Tabellenebene und Spaltenmasken. Beide Methoden gewähren keinen eigenen Zugriff auf Daten – beide fügen Einschränkungen über vorhandene Berechtigungen auf Objektebene hinzu. Sie müssen den Basistabellenzugriff separat über Berechtigungen auf Objektebene (GRANT) gewähren.

Der Kernunterschied besteht darin, dass die Einschränkungen definiert sind. Zeilenfilter und Spaltenmasken auf Tabellenebene wenden Vertraulichkeitskontrollen direkt auf einzelne Tabellen mithilfe von an. Tabellenbesitzer verwalten ihren Datenschutz selbst, ohne dass ein verwaltetes Tagsystem erforderlich ist. Dies ist für eine kleine Anzahl von Tabellen einfach, aber jede Tabelle muss einzeln konfiguriert werden, und Tabellenbesitzer können ihre eigenen Filter und Masken ändern oder entfernen.

ABAC-Richtlinien werden auf Katalog-, Schema- oder Tabellenebene angewendet und ordnen Tabellen und Spalten dynamisch basierend auf verwalteten Tags zu. Eine auf Katalogebene definierte Richtlinie gilt für alle Tabellen in diesem Katalog, und einzelne Tabellenbesitzer können sie nicht entfernen, ändern oder umgehen. Die Richtlinie befindet sich im Katalog und wird vom Unity Catalog ausgewertet, bevor die Abfrage die Ausführungszeit erreicht. Auf diese Weise können Administratoren auf höherer Ebene organisationsweite Regeln erzwingen und sicherstellen, dass Administratoren und Besitzer auf niedrigerer Ebene sie nicht umgehen können.

Detaillierte Vergleichszusammenfassung

In dieser Tabelle werden die Unterschiede zwischen ABAC-Richtlinien, Tabellenebene-Zeilenfiltern und Spaltenmasken zusammengefasst.

Überlegung ABAC-Richtlinien Zeilenfilter und Spaltenmasken auf Tabellenebene
SQL-Syntax CREATE POLICY ... ON CATALOG/SCHEMA/TABLE ALTER TABLE ... SET ROW FILTER / ALTER TABLE ... ALTER COLUMN ... SET MASK
Umfang Alle Tabellen innerhalb des Richtlinienbereichs (Katalog, Schema oder Tabelle) und deren Nachfolger. Neue markierte Tabellen werden automatisch behandelt. Eine einzelne Tabelle, in der der Filter oder die Maske konfiguriert ist. Jede Tabelle muss einzeln konfiguriert werden.
Dynamischer Abgleich Tabellen und Spalten werden dynamisch basierend auf verwalteten Tags mithilfe von has_tag() und has_tag_value() zugeordnet. Kein dynamischer Abgleich. Filter und Masken sind an bestimmte Tabellen und Spalten gebunden.
Gezielte Ziele TO / EXCEPT-Klauseln in der Richtliniendefinition, zusätzlich zu Identitätsfunktionen in der UDF. Identitätsfunktionen wie current_user() in der UDF.
Governance von Richtlinien Richtlinien können von Katalog- oder Schemabesitzern festgelegt werden. Nachdem sie auf einer höheren Ebene festgelegt wurden, können Tabellenbesitzer sie nicht außer Kraft setzen, ändern oder entfernen. Verwaltet von Tabellenbesitzern, die Filter und Masken in ihren eigenen Tabellen ändern oder entfernen können.
Nicht unterstützte Funktionen Operationen wie Zeitreise, Klonen und Delta Sharing können von Principals in der EXCEPT-Klausel ausgeführt werden. Siehe "Fail-closed"-Entwurf. Keine EXCEPT Klausel, sodass nicht unterstützte Features für geschützte Tabellen nicht verfügbar sind.
Effektive Richtlinien SHOW EFFECTIVE POLICIES um zu sehen, welche Richtlinien für eine bestimmte Tabelle und einen bestimmten Benutzer gelten. Direkt in der Tabellendefinition sichtbar.
Überprüfbarkeit DESCRIBE POLICY und SHOW POLICIES um Richtliniendefinitionen zu prüfen. INFORMATION_SCHEMA.ROW_FILTERS und INFORMATION_SCHEMA.COLUMN_MASKS.

Verwenden Sie im Allgemeinen ABAC-Richtlinien in folgenden Fällen:

  • Sie benötigen einheitliche Zugriffsregeln für viele Tabellen, Schemas oder Kataloge.
  • Ihre Organisation trennt Aufgaben. Richtlinienautoren definieren beispielsweise Regeln, und Data Stewards klassifizieren Daten mit Tags.
  • Ihr Datenbestand wächst und Sie möchten, dass neue Tabellen automatisch behandelt werden, wenn sie markiert sind.
  • Sie benötigen die EXCEPT Klausel, um Vorgänge wie Zeitreise, Delta Sharing oder vollständige Abfrageoptimierung für bestimmte Principals zuzulassen.

Verwenden Sie im Allgemeinen Zeilenfilter und Spaltenmasken auf Tabellenebene, wenn:

  • Jede Tabelle verfügt über strenge, spezifische Logik, die nicht auf andere Tabellen generalisiert wird.
  • Tabellenbesitzer sollten ihre eigenen Filter und Masken direkt verwalten, ohne ein zentralisiertes Tagsystem.
  • Sie haben einen kleinen, stabilen Satz von Tabellen, die sich selten ändern.

Kombinieren von ABAC- und Zeilenfiltern auf Tabellenebene und Spaltenmasken

ABAC- und Zeilenfilter auf Tabellenebene und Spaltenmasken können in derselben Tabelle koexistieren. Zum Abfragezeitpunkt werden die Richtlinien unabhängig für den anfragenden Benutzer nach den folgenden Regeln ausgewertet.

  • Es kann nur ein eindeutiger Zeilenfilter angewendet werden.
  • Pro Spalte kann nur eine Spaltenmaske aufgelöst werden.

Azure Databricks wertet Konflikte aus, indem die angewendeten Funktionen und nicht die Datenausgabe verglichen werden. Wenn sowohl eine ABAC-Richtlinie als auch ein Filter oder eine Maske auf Tabellenebene dieselbe Zeilenfilter- oder Spaltenformatfunktion für denselben Benutzer anwenden, ermöglicht Azure Databricks die Ausführung. Wenn sie unterschiedliche Funktionen anwenden, blockiert Azure Databricks den Zugriff und gibt einen Fehler zurück, auch wenn diese Funktionen identische Datenausgabe erzeugen.

Ausführliche Informationen zur Konfliktauflösung und Zur Problembehandlung finden Sie unter Regeln für mehrere Filter und Masken.

Sicherheit auf Zeilen- und Spaltenebene mit dynamischen Ansichten

Dynamische Ansichten können auch die Sicherheit auf Zeilenebene und Spaltenebene implementieren, indem Identitätsfunktionen wie current_user() und is_account_group_member() direkt in die Ansichtsdefinition eingebettet werden. Dynamische Ansichten, Zeilenfilter und Spaltenmasken wenden alle Filter- oder Transformationslogik zum Abfragezeitpunkt an, unterscheiden sich jedoch darin, wie sie verwaltet, bereichert und den Benutzern zugänglich gemacht werden.

Gilt für So wird's verwaltet Am besten geeignet für
Dynamische Ansichten Ansichten SQL-Logik in der Ansichtsdefinition Feinkörnige Zugriffssteuerung, die mehrere Quelltabellen umfasst oder Daten für das Teilen umgestaltet
Zeilenfilter und Spaltenmasken Tabellen und Spalten ABAC-Richtlinien oder Zuweisung auf Tabellenebene Zugriffssteuerung auf Zeilenebene und Spaltenebene ohne Einführung neuer Objekte

Verwenden Sie dynamische Ansichten, wenn Sie eine differenzierte Zugriffssteuerung benötigen, die mehrere Quelltabellen umfasst oder Daten für die Freigabe umgestaltet. Verwenden Sie Zeilenfilter und Spaltenmasken, um den Zugriff auf einzelne Tabellen zu steuern, ohne neue Objekte einzuführen.

Beispielsweise kann eine dynamische Ansicht eine E-Mail-Spalte für Nichtprüfer maskieren:

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

Dynamische Ansichten unterstützen die Abfrageoptimierung und das Prädikat-Pushdown vollständig, sodass sie eine bessere Abfrageleistung als Zeilenfilter und Spaltenmasken bieten können. Sie verhindern außerdem, dass Benutzer die zugrunde liegenden Tabellen ändern.

Dynamische Ansichten haben jedoch zwei Nachteile für die Datengovernance:

  • Eingeschränkte Überwachung: Dynamische Ansichten verfügen nicht über semantische Metadaten wie Tags oder Richtliniendefinitionen in Systemtabellen, wodurch sie schwieriger überwacht werden können.
  • Verwundbarkeit bei Probing: Da ihnen eine SecureView Barriere fehlt, bieten sie keinen Schutz vor Probingangriffen, bei denen ein Benutzer ein Prädikat mit Nebenwirkungen konstruiert, um Informationen über gefilterte Zeilen abzuleiten. Siehe Grundlegendes zum Prädikat-Pushdown in geschützten Tabellen.
  • Last updated on