Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Diese Seite enthält eine Anleitung zur Verwendung von Zeilenfiltern und Spaltenmasken, um vertrauliche Daten in Ihren Tabellen zu filtern.
Was sind Zeilenfilter?
Mit Zeilenfiltern können Sie steuern, auf welche Zeilen ein Benutzer basierend auf benutzerdefinierter Logik in einer Tabelle zugreifen kann. Zur Abfragezeit wertet ein Zeilenfilter eine Bedingung aus und gibt nur die Zeilen zurück, die sie erfüllen. Dies wird häufig verwendet, um die Sicherheit auf Zeilenebene zu implementieren, z. B. das Einschränken von Benutzern auf Datensätze aus einer bestimmten Region, Abteilung oder einem bestimmten Konto.
Zeilenfilter werden als benutzerdefinierte SQL-Funktionen (USER-Defined Functions, UDFs) definiert und können auch Python- oder Scala-Logik integrieren, wenn sie in eine SQL-UDF eingeschlossen werden. Sie können Zeilenfilter pro Tabelle oder zentral über ABAC-Richtlinien mithilfe von geregelten Tags anwenden.
Was sind Spaltenmasken?
Spaltenmasken steuern, welche Werte Benutzer in bestimmten Spalten sehen, abhängig davon, wer sie sind. Zum Zeitpunkt der Abfrage ersetzt die Maske jeden Verweis auf eine Spalte durch das Ergebnis der Maskierungsfunktion. Auf diese Weise können vertrauliche Daten, z. B. Sozialversicherungsnummern oder E-Mails, basierend auf der Benutzeridentität oder der Rolle entfernt oder abgeändert werden.
Jede Spalte kann eine Maske aufweisen. Die Maske muss als SQL-UDF definiert werden, die einen Wert vom gleichen Typ zurückgibt wie die zu maskierte Spalte. Die SQL-UDF kann optional Python oder Scala UDFs aufrufen , um komplexe Maskierungslogik zu implementieren. Spaltenmasken können auch andere Spalten als Eingaben verwenden, um z.B. das Verhalten basierend auf mehreren Attributen zu variieren.
Wie Zeilenfilter können Spaltenmasken pro Tabelle angewendet oder zentral über ABAC-Richtlinien verwaltet werden. Sie arbeiten zur Abfragezeit und integrieren sich nahtlos mit Standard-SQL, Notizbüchern und Dashboards.
Wann sollten Sie dynamische Ansichten im Vergleich zu Filtern und Masken verwenden?
Mit dynamischen Ansichten, Zeilenfiltern und Spaltenmasken können Sie zur Abfragezeit Filter- oder Transformationslogik anwenden - sie unterscheiden sich jedoch darin, wie sie verwaltet, bereitgestellt und für Benutzer zugänglich gemacht werden.
| Merkmal | Gilt für: | Verwaltet mithilfe von | Benennungs-Auswirkungen | Am besten geeignet für... |
|---|---|---|---|---|
| Dynamische Ansichten | Ansichten | SQL-Logik | Erstellt einen neuen Objektnamen. | Freigeben gefilterter Daten oder Übergreifen mehrerer Tabellen |
| Zeilenfilter | Tabellen | ABAC- oder Zuordnungstabellen | Tabellenname unverändert | Zugriffssteuerung auf Zeilenebene, die an Benutzer- oder Datentags gebunden ist |
| Spaltenmasken | Tabellen/Spalten | ABAC- oder Zuordnungstabellen | Tabellenname unverändert | Anonymisieren vertraulicher Spaltendaten basierend auf Identität |
- Verwenden Sie dynamische Ansichten, wenn Sie eine schreibgeschützte Ebene für eine oder mehrere Quelltabellen benötigen, insbesondere für das Teilen von Daten oder das Anwenden von Logik auf mehrere Eingaben.
- Verwenden Sie Zeilenfilter und Spaltenformate , wenn Sie Logik direkt auf eine Tabelle anwenden möchten, ohne den Tabellennamen zu ändern oder neue Objekte einzuführen. Diese können entweder mithilfe von ABAC-Richtlinien (empfohlen) oder manuell in Tabellen verwaltet werden.
Einen vollständigen Vergleich finden Sie unter Zugangskontrollmethoden im Vergleich.
Anwenden von Filtern und Masken
Sie können Zeilenfilter und Spaltenmasken auf zwei Hauptarten implementieren.
Verwenden von ABAC-Richtlinien (Public Preview): Anwenden von Filtern und Masken zentral mithilfe geregelter Tags und wiederverwendbarer Richtlinien. Dieser Ansatz skaliert sich über Kataloge und Schemas hinweg und reduziert die Notwendigkeit der Tabellen-nach-Tabellen-Konfiguration. ABAC-Richtlinien sind sicherer als manuelle Richtlinien auf Tabellenebene, da sie von Administratoren auf höherer Ebene definiert werden können und nicht von Tabellenbesitzern außer Kraft gesetzt werden können, was dazu beiträgt, zentralisierte Zugriffssteuerungen zu erzwingen. Sie sind auch in vielen Fällen leistungsfähiger, da Filter- und Maskierungslogik in ABAC-Richtlinien effizienter ausgewertet wird als in tabellenspezifischen UDFs. Databricks empfiehlt die Verwendung von ABAC für die meisten Anwendungsfälle. Informationen zum Anwenden von Filtern und Masken mithilfe von ABAC finden Sie unter "Unity Catalog"-attributbasierte Zugriffssteuerung (ABAC).To apply filters and mask using ABAC see Unity Catalog attribute-based access control (ABAC).
Manuelle Zuordnung pro Tabelle: Anwenden von Filtern und Masken durch direktes Zuweisen von Funktionen zu einzelnen Tabellen und Spalten. Diese Methode kann Zuordnungstabellen oder andere benutzerdefinierte Logik verwenden. Es ermöglicht feinkörnige, tabellenspezifische Kontrolle, ist aber schwieriger zu skalieren und zu warten. Weitere Informationen lesen Sie mehr unter Manuelles Anwenden von Zeilenfiltern und Spaltenmasken.
Empfehlungen zur Leistung
Zeilenfilter und Spaltenmasken steuern die Datensichtbarkeit, indem sichergestellt wird, dass Benutzer den Inhalt der Werte der Basistabellen nicht anzeigen können, bevor Filter- und Maskierungsvorgänge ausgeführt werden. Sie reagieren gut auf Abfragen in gängigen Anwendungsfällen. In weniger gängigen Anwendungen, bei denen das Abfragemodul zwischen der Optimierung der Abfrageleistung und dem Schutz vor Verlust von Informationen aus den gefilterten/maskierten Werten wählen muss, wird immer die sichere Entscheidung auf Kosten der Abfrageleistung getroffen. Um diese Leistungseinbußen zu minimieren, wenden Sie die folgenden Empfehlungen an:
- Verwenden Sie einfache Richtlinienfunktionen: Richtlinienfunktionen mit weniger Ausdrücken führen häufig besser aus als komplexere Ausdrücke. Vermeiden Sie die Verwendung von Zuordnungstabellen und Ausdrucksunterabfragen zugunsten einfacher CASE-Funktionen.
- Beschränken Sie die Anzahl der Spaltenmasken und Maskierungsfunktionen: Mehrere eindeutige Spaltenmasken in großen Tabellen können die Abfrageleistung beeinträchtigen. Jede unterschiedliche Maske erfordert eine Auswertung während Abfragen und erhöht den Verarbeitungsaufwand. Wenden Sie Masken nur auf Spalten an, die wirklich vertrauliche Daten enthalten, und verwenden Sie Maskierungsfunktionen nach Möglichkeit wieder.
- Verringern Sie die Anzahl der Funktionsargumente: Azure Databricks können keine Spaltenverweise auf die Quelltabelle optimieren, die sich aus Richtlinienfunktionsargumenten ergibt, auch wenn diese Spalten nicht in der Abfrage verwendet werden. Verwenden Sie Richtlinienfunktionen mit weniger Argumenten, da die Abfragen aus diesen Tabellen besser funktionieren.
-
Vermeiden Sie das Hinzufügen von Zeilenfiltern mit zu vielen AND-Konjunkten: Da nur ein eindeutiger Zeilenfilter zur Laufzeit für einen bestimmten Benutzer und eine bestimmte Tabelle aufgelöst werden kann, besteht ein allgemeiner Ansatz darin, mehrere gewünschte Richtlinienfunktionen mit
ANDzu kombinieren. Mit jedem zusätzlichen Konjunkt erhöhen sich jedoch die Chancen, dass Konjunkte Komponenten enthalten, die an anderer Stelle in dieser Tabelle erwähnt werden und sich auf die Leistung auswirken könnten (z. B. Zuordnungstabellen). Verwenden Sie weniger Verbindungen, um die Leistung zu verbessern. -
Verwenden Sie deterministische Ausdrücke, die in Tabellenrichtlinien und Abfragen aus diesen Tabellen keine Fehler auslösen können: Einige Ausdrücke können Fehler auslösen, wenn die bereitgestellten Eingaben ungültig sind, z. B. ANSI-Abteilung. In solchen Fällen darf der SQL-Compiler keine Operationen mit diesen Ausdrücken (z. B. Filtern) im Abfrageplan zu weit nach unten verschieben, um die Möglichkeit von Fehlern wie "Division durch Null" zu vermeiden, die Informationen über Werte vor Filter- und/oder Maskierungsvorgängen offenbaren. Verwenden Sie deterministische Ausdrücke, die niemals Fehler auslösen, wie z. B.
try_divide. -
Bevorzugen Sie SQL zu Python UDFs: Python UDFs sind in der Regel weniger leistungsfähig als SQL, und sie bieten weniger Möglichkeiten zur Optimierung. Wenn Sie Python verwenden müssen, markieren Sie UDFs explizit als
DETERMINISTICwenn sie keine nicht deterministische Logik oder Abhängigkeiten umfassen. - Führen Sie Testabfragen über Ihre Tabelle aus, um die Leistung zu messen: Erstellen Sie realistische Abfragen, die die arbeitsauslastung darstellen, die Sie für Ihre Tabelle mit Zeilenfiltern oder Spaltenmasken erwarten, und messen Sie die Leistung. Führen Sie kleine Änderungen an den Richtlinienfunktionen durch und beobachten Sie ihre Effekte, bis Sie einen guten Saldo zwischen Leistung und Ausdruckskraft der Filter- und Maskierungslogik erreichen.
Weitere bewährte Methoden und Beispiel-UDFs finden Sie unter UDFs für bewährte Methoden für ABAC-Richtlinien.
Einschränkungen
- Databricks Runtime-Versionen vor Version 12.2 LTS unterstützen weder Zeilenfilter noch Spaltenmasken. Diese Laufzeiten schlagen sicher fehl, d. h., wenn Sie versuchen, aus diesen Laufzeiten auf Tabellen zuzugreifen, werden keine Daten zurückgegeben.
- Delta-Freigabeanbieter können keine Tabellen mit Sicherheit auf Zeilenebene oder Spaltenmasken freigeben. Delta-Freigabeempfänger können jedoch Zeilenfilter und Spaltenmasken nur auf freigegebene Tabellen und Fremdtabellen anwenden, nicht auf Streamingtabellen oder materialisierte Ansichten.
- Verwaltete Iceberg-Tabellen unterstützen keine Zeilenfilter oder Spaltenmasken.
- Sie können den Iceberg-REST-Katalog oder Unity-REST-APIs nicht verwenden, um auf Tabellen mit Zeilenfiltern oder Spaltenmasken zuzugreifen.
- Sie können keine Sicherheit auf Zeilenebene oder Spaltenmasken auf eine Sicht anwenden.
- Zeitreisen funktionieren für Sicherheit auf Zeilenebene oder Spaltenmasken nicht.
- Der pfadbasierte Zugriff auf Dateien in Tabellen mit Richtlinien wird nicht unterstützt.
- Zeilenfilter- oder Spaltenmaskenrichtlinien mit Zirkelabhängigkeiten zurück zu den ursprünglichen Richtlinien werden nicht unterstützt.
- Zeilenfilter und Spaltenformate können nicht auf Tabellen verweisen, die auch aktive Zeilenfilter oder Spaltenformate aufweisen. In ABAC-Konfigurationen können Sie dies umgehen, indem Sie den Richtlinienfunktionsbesitzer aus der Richtlinie der referenzierten Tabelle ausschließen.
- Tiefe und flache Klone werden bei Tabellen, die über Sicherheit auf Zeilenebene oder Spaltenmasken verfügen, nicht unterstützt.
- Sie können keinen Vektorsuchindex aus einer Tabelle erstellen, auf die Zeilenfilter oder Spaltenmasken angewendet wurden.
-
MERGE-Anweisungen unterstützen keine Tabellen mit Zeilenfilter- oder Spaltenmaskenrichtlinien, die Schachtelungen, Aggregationen, Fenster, Grenzwerte oder nicht-deterministische Funktionen enthalten. - Databricks-Runtime-Versionen unter 17.2 unterstützen
DELETE,UPDATEundMERGEnicht auf partitionierten Tabellen mit Zeilenfilter- oder Spaltenmaskenrichtlinien, die in der Partitionsspalte definiert sind. - Delta Lake-APIs werden nicht unterstützt.
Einschränkung des dedizierten Zugriffsmodus
Sie können nicht auf eine Tabelle mit Zeilenfiltern oder Spaltenmasken aus einer dedizierten Access-Computeressource in Databricks Runtime 15.3 oder darunter zugreifen. Sie können den dedizierten Zugriffsmodus auf Databricks Runtime 15.4 LTS oder höher verwenden, wenn Ihr Arbeitsbereich für die serverlose Berechnung aktiviert ist. Allerdings werden nur Lesevorgänge für Databricks Runtime 15.4 bis 16.2 unterstützt. Schreibvorgänge (einschließlich INSERT, UPDATE, und DELETE) erfordern Databricks Runtime 16.3 oder höher und müssen unterstützte Muster wie MERGE INTO verwenden.
Weitere Informationen finden Sie unter Feingranulare Zugriffssteuerung auf dedizierte Rechenleistung.