Richtlinienauswertung und Laufzeitverhalten von Zeilenfiltern und Spaltenmasken

Auf dieser Seite wird erläutert, wie ABAC-Richtlinien zur Abfragezeit ausgewertet werden, einschließlich:

• Wenn Richtlinien im Widerspruch stehen
• Funktionsweise der Typkonvertierung von Spaltenmasken
• Welche Schutzmaßnahmen verhindern die Datenexposition, wenn Tags oder Funktionen, von denen eine Richtlinie abhängt, gelöscht werden

Richtlinienauswertung und -erzwingung

Wenn ein Benutzer eine Tabelle abfragt, wird die ABAC-Auswertung in zwei Phasen fortgesetzt: Die Richtlinienauswertung im Unity-Katalog und die Richtlinienerzwingung in der Databricks-Runtime.

Verschiedene Benutzer sehen möglicherweise unterschiedliche Ergebnisse aus derselben Abfrage, da die Richtlinienauswertung von der Identität, Gruppenmitgliedschaft und den Tags der Daten abhängt, auf die sie zugreifen. Änderungen an Gruppenmitgliedschaften oder Tagzuweisungen ändern zum Abfragezeitpunkt die effektiven Richtlinien dynamisch.

Richtlinienauswertung (Unity-Katalog)

Für jede in der Abfrage referenzierte Tabelle führt Unity Catalog folgende Schritte unter Verwendung der Metadaten dieser Tabelle (z. B. geregelter Tag-Zuweisungen) sowie der Identität und der Gruppenmitgliedschaften des anfragenden Benutzers durch:

1. Identifiziert alle Richtlinien, deren Bereich die abgefragte Tabelle abdeckt.
2. Überprüft für jede dieser Richtlinien, ob sich der Abfragebenutzer in der TO Liste und nicht in der EXCEPT Liste befindet.
3. Für jede Policy bewertet sie, ob die abgefragte Tabelle mit den Bedingungen der Richtlinie übereinstimmt. Richtlinienbedingungen können auf Tags verweisen, einschließlich vererbter Tags, Identitätsattribute und Kontextattribute. Spaltenbedingungen müssen mindestens einer Spalte entsprechen.
4. Wenn die Richtlinie gilt, wird der effektive Zeilenfilter oder die Spaltenmaske bestimmt und der Databricks Runtime als Teil der Tabellenmetadaten übermittelt.

In einer Tabelle können mehrere Richtlinien in Konflikt geraten (siehe Widersprüchliche Filter und Masken in einer Tabelle).

Beim Abfragen einer Tabelle über eine Ansicht oder beim Aufruf einer Funktion, die eine Tabelle abfragt, sind zwei Identitäten beteiligt. Der Zugriff auf die zugrundeliegenden Tabellen wird anhand der Identität des View- oder Funktionsbesitzers überprüft, während Richtlinien wie oben beschrieben anhand der Identität des anfragenden Benutzers bewertet werden. Dies ermöglicht es Nutzern, eine Ansicht abzufragen oder eine Funktion ohne direkten Zugriff auf die zugrunde liegenden Tabellen aufzurufen, während jede für den Anfragenden geltende Richtlinie durchgesetzt wird. Wenn Alice zum Beispiel eine Ansicht von Bob abfragt, prüft Unity Catalog zunächst, ob Alice über SELECT für die Ansicht verfügt und ob Bob Zugriff auf die zugrundeliegenden Tabellen hat. Alice benötigt keinen Zugriff auf die zugrunde liegenden Tabellen. Unity Catalog wendet dann die Zeilenfilter- und Spaltenmasken-Richtlinien an, die zu Alices Identität passen, sodass Alice nur die Daten sieht, die ihre eigenen Richtlinien zulassen.

Durchsetzung von Richtlinien (Databricks Runtime)

Der Abfrageplaner von Databricks Runtime übersetzt den effektiven Zeilenfilter oder die Spaltenmaske in eine sichere Ansicht, die über die Tabellenscans gelegt wird und bei der Abfrageausführung die Filterung und Maskierung erzwingt. Dies ist derselbe Erzwingungsmechanismus, der für Zeilenfilter und Spaltenmasken auf Tabellenebene verwendet wird.

Zeitreise mit ABAC-Richtlinien

Zeitreisen ermöglichen es, historische Tabellendaten mit einem bestimmten Zeitstempel oder einer Versionsnummer abzufragen. Time-Travel-Abfragen auf qualifizierenden Tabellen erzwingen ABAC-Richtlinien für Zeilenfilter und Spaltenmasken. Weitere Informationen finden Sie unter Zeitreisen mit ABAC-Richtlinien.

Fail-Closed-Design

ABAC folgt einem nicht geschlossenen Modell, bei dem Azure Databricks standardmäßig den Zugriff verweigert, wenn die Sicherheit nicht überprüft werden kann. Azure Databricks ermöglicht nur den Zugriff auf ABAC-gesicherte Tabellen, wenn sie alle anwendbaren Richtlinien sicher erzwingen kann. Dies gilt für nicht unterstützte Berechnungsversionen, bestimmte Vorgänge mit zugrunde liegenden Tabellendaten und Situationen, in denen die Abhängigkeiten einer Richtlinie (Tags oder Funktionen) entfernt wurden.

Nicht unterstützte Rechenversions

ABAC-Richtlinien erfordern Databricks Runtime 16.4 oder höher oder serverlose Berechnung. Wenn ein Benutzer versucht, von einer nicht unterstützten Version aus auf eine ABAC-gesicherte Tabelle zuzugreifen, schlägt die Abfrage geschlossen (Zugriff wird verweigert) fehl, um die Gefährdung nicht geschützter Daten zu verhindern.

Im dedizierten Zugriffsmodus delegiert Azure Databricks die Durchsetzung an serverlose Compute, um sicherzustellen, dass granulare Zugriffssteuerungen angewendet werden. Damit Benutzer auf älteren Laufzeiten auf diese Tabellen zugreifen können, müssen Sie sie explizit von den Richtlinien ausschließen.

Nicht unterstützte Operationen auf geschützten Daten

Bestimmte Vorgänge sind mit Zeilenfiltern oder Spaltenmasken im Konflikt. Diese Vorgänge schlagen fehl, anstatt die Erzwingung zu umgehen. Um sie auszuführen, muss der Hauptnutzer in der Klausel EXCEPT jeder ABAC-Richtlinie aufgeführt sein, die für die Tabelle gilt. Ausgenommene Akteure unterliegen nicht der Richtlinie, daher muss Azure Databricks die Richtlinie nicht durchsetzen und kann den Vorgang sicher zulassen.

Vorgänge, für die der Ausführungsprinzipal ausgenommen werden muss, umfassen Pipelineaktualisierungen, Sicherungsprozesse und administrative Workflows wie die folgenden:

• Zugriff auf ABAC-gesicherte Tabellen von Systemen mit Databricks-Runtime-Versionen unter 16.4
• Tiefes und flaches Klonen
• OpenSharing, bei dem der Besitzer der Freigabe von der Richtlinie ausgenommen sein muss und über die erforderlichen OpenSharing-Berechtigungen verfügen muss. Beachten Sie, dass die Richtlinie den Zugriff des Empfängers nicht regelt.
• Erstellung und Synchronisierung von AI-Suchindex

Weitere Informationen zu diesen und anderen Einschränkungen finden Sie unter Anforderungen, Kontingente und Einschränkungen für Zeilenfilter- und Spaltenformatrichtlinien.

Entfernte Richtlinienabhängigkeiten

ABAC-Richtlinien hängen von geregelten Tags und UDFs ab. Wenn eine dieser Abhängigkeiten entfernt wird, während eine Richtlinie immer noch darauf verweist, schlagen Abfragen für Tabellen im Bereich der Richtlinie fehl.

Reguliertes Löschen von Tags

Wenn Sie ein geregeltes Tag löschen, auf das eine ABAC-Richtlinie verweist, schlagen alle Abfragen für das Objekt, an das die Richtlinie angefügt ist, sowie die Abfragen für seine untergeordneten Objekte mit einem INVALID_PARAMETER_VALUE.UC_ABAC_UNKNOWN_TAG_POLICY-Fehler fehl. Dies tritt auch dann auf, wenn das Tag nicht für die abgefragten Tabellen übernommen wurde.

Wenn ein reguliertes Tag gelöscht wird, wird es zu einem nicht regulierten Tag. Die Einschränkungen für zulässige Werte werden entfernt, und jeder kann Werte mit APPLY TAG ohne das ASSIGN-Privileg ändern.

Um den Fehler zu beheben, stellen Sie entweder das gelöschte Tag wieder her, oder aktualisieren oder löschen Sie die Richtlinie, die darauf verweist. Siehe Erstellen und Verwalten von geregelten Tags.

Löschen einer markierten Spalte

Azure Databricks verhindert das Löschen einer Spalte, auf die ein vorgeschriebenes Tag angewendet wurde. Um die Spalte zu löschen, muss ein Benutzer mit ASSIGN auf dem Tag und APPLY TAG auf dem Objekt zuerst das Tag entfernen, dann kann die Spalte gelöscht werden.

Dies ist für deklarative Pipelines und andere automatisierte Workflows relevant, die Tabellenschemas ändern. Wenn eine Pipeline versucht, eine markierte Spalte zu entfernen, misslingt der Vorgang. Um die Blockierung der Pipeline aufzuheben, muss ein Benutzer mit den erforderlichen Tagberechtigungen das Tag entfernen, die Pipeline ausführen, damit die Schemaänderung erfolgreich ist, und dann das Tag erneut auf die relevanten Spalten anwenden. Wenn das Tag nicht erneut übernommen wird, schlagen Abfragen der Daten fehl, da die Richtlinie weiterhin im Anwendungsbereich liegt, aber das erwartete Tag nicht mehr am Objekt vorhanden ist.

Entfernung von richtlinienbezogenen Funktionen

Wenn eine UDF, auf die von einer Richtlinie verwiesen wird, gelöscht wird, während sich die Richtlinie noch im Gültigkeitsbereich befindet, schlagen Abfragen gegen Tabellen mit UC_DEPENDENCY_DOES_NOT_EXIST fehl. Stellen Sie die Funktion wieder her, oder aktualisieren Sie die Richtlinie, um auf eine andere UDF zu verweisen.

Bedingungen für Identitätsattribute

Die Funktionen des Identitätsattributs (has_identity_attribute_value und has_identity_attribute_tag_match) lösen sich wie folgt auf:

• Wenn der Benutzer keinen Wert für das Attribut hat, gar keine Attribute hat oder die Richtlinie ein Attribut nennt, das nicht existiert, gibt die Funktion zurück.false Es führt keinen Fehler aus. Da ein fehlender Wert false zurückgibt, sollten Bedingungen so formuliert werden, dass ein fehlender Wert den Zugriff einschränkt, anstatt ihn zu gewähren.
• Wenn eine Richtlinie has_identity_attribute_tag_match einen verwalteten Tag-Schlüssel übergibt, der nicht existiert, schlägt die Erstellung der Richtlinie fehl.

Kontextattributbedingungen

Kontextattributfunktionen (has_context_attribute und has_context_attribute_value) lösen sich wie folgt auf:

• request.client_id ist nur auf einigen Anfragepfaden vorhanden. Es ist für „On-Behalf-Of“-Anfragen vorgesehen, die über eine OAuth-Anwendung gestellt werden, und fehlt andernfalls. request.is_on_behalf_of ist mit dem Wert von 'true' oder 'false'vorhanden oder fehlt auf nicht unterstützten Rechenpfaden.
• Wenn ein erkanntes Attribut in der Anfrage nicht vorhanden ist, gibt die Funktion zurück false (sie erzeugt keinen Fehler). Formuliere Bedingungen so, dass dieses Ergebnis den Zugang einschränkt statt gewährt.
• Ein Schlüssel, der kein erkanntes request.*-Attribut ist, wie etwa ein falsch geschriebener Schlüssel, löst einen Auswertungsfehler aus, anstatt zu false aufgelöst zu werden. Verwenden Sie die genauen Namen request.client_id und request.is_on_behalf_of.

Wenn Sie die Vorschau UC ABAC Context Attributes deaktivieren, obwohl noch Richtlinien für Zeilenfilter oder Spaltenmasken vorhanden sind, die diese Funktionen verwenden, schlagen Abfragen der betroffenen Daten mit UC_ABAC_CONTEXT_ATTRIBUTE_FUNCTIONS_DISABLED fehl, anstatt stillschweigend keine Zeilen zurückzugeben. Die Richtlinienverwaltung ist nicht beeinträchtigt. Sie können weiterhin Policen auflisten, ändern und fallen lassen. Entferne oder überarbeite Richtlinien für Kontextattribute, bevor du die Funktion deaktivierst.

Widersprüchliche Filter und Masken

Nur ein eindeutiger Zeilenfilter kann zur Abfragezeit für eine bestimmte Tabelle und einen bestimmten Benutzer angewendet werden. Auf ähnliche Weise kann zur Laufzeit nur eine einzelne Spaltenmaske für eine bestimmte Spalte und einen bestimmten Benutzer aufgelöst werden. Dies verhindert mehrdeutige Ergebnisse.

Wenn mehrere unterschiedliche Filter oder Masken auf denselben Benutzer und dieselbe Tabelle (oder Spalte) angewendet werden, blockiert Azure Databricks den Zugriff und gibt einen Fehler zurück. Beispiel:

• Ein Filter oder eine Maske auf Tabellenebene steht in Konflikt mit einer ABAC-Richtlinie. Eine Tabelle oder Spalte, die bereits über einen manuell angewendeten Zeilenfilter oder eine Spaltenmaske verfügt, steht in Konflikt mit einem ABAC-definierten Filter oder einer Maske auf demselben Ziel.
• Die Klausel eines Zeilenfilters USING COLUMNS verweist auf einen MATCH COLUMNS Alias, der mehreren Spalten entspricht. Die USING COLUMNS Klausel übergibt Spaltenwerte an die UDF. Wenn ein MATCH COLUMNS Alias in der USING COLUMNS Klausel mehreren Spalten entspricht, kann das Modul nicht ermitteln, welche Spalte an die UDF übergeben werden soll, und die Abfrage schlägt mit einem Fehler fehl.
• Auf eine maskierte Spalte wird in der USING COLUMNS Klausel einer anderen Richtlinie verwiesen. Wenn eine Spalte von einer Richtlinie maskiert wird, kann sie nicht als Eingabeargument in der USING COLUMNS Klausel einer anderen Richtlinie verwendet werden.

Mehrere ABAC-Richtlinien können für dieselbe Tabelle oder Spalte koexistieren, wenn sie zum gleichen effektiven Filter oder Maske führen. Beispielsweise werden zwei Richtlinien, die auf dieselbe UDF mit denselben Argumenten verweisen, in denselben Filter oder dieselbe Maske aufgelöst und sind konfliktfrei.

Problembehandlung bei Richtlinienkonflikten

Wenn Azure Databricks während der Richtlinienauswertung für einen bestimmten Benutzer mehrere unterschiedliche Filter oder Masken erkennt, löst sie einen INVALID_PARAMETER_VALUE.UC_ABAC_MULTIPLE_ROW_FILTERS oder COLUMN_MASKS_FEATURE_NOT_SUPPORTED.MULTIPLE_MASKS Fehler aus und blockiert den Zugriff auf die Tabelle, bis der Konflikt gelöst wird.

So diagnostizieren und beheben Sie das Problem:

1. Verwenden Sie SHOW EFFECTIVE POLICIES, um alle Richtlinien anzuzeigen, die für die Tabelle gelten.
2. Überprüfen Sie INFORMATION_SCHEMA.ROW_FILTERS und INFORMATION_SCHEMA.COLUMN_MASKS, um alle Zeilenfilter auf Tabellenebene oder Spaltenmasken zu identifizieren, die konfliktieren könnten.
3. Überprüfen Sie, welche Richtlinien in ihren TO/EXCEPT Prinzipalen und WHEN/MATCH COLUMNS Bedingungen Überschneidungen aufweisen.
4. Lösen durch:
   • Verfeinern von Richtlinienbedingungen. Aktualisieren WHEN oder MATCH COLUMNS Klauseln, um spezifischer zu sein, sodass unterschiedliche Richtlinien auf unterschiedliche Tabellen oder Spalten abzielen.
   • Anpassen geregelter Tags. Überprüfen Sie Tagzuweisungen für Spalten oder Tabellen, die unbeabsichtigte Richtlinienübereinstimmungen auslösen, und entfernen oder aktualisieren Sie sie.
   • Prinzipien anpassen. Aktualisieren Sie TO/EXCEPT Klauseln, sodass jeder Benutzer von höchstens einer Richtlinie pro Tabelle (für Zeilenfilter) oder pro Spalte (für Spaltenmasken) abgedeckt wird.
   • Umstrukturierungspolitiken. Konsolidieren Sie überlappende Richtlinien in eine einzelne Richtlinie, oder teilen Sie allgemeine Richtlinien in separate, explizit gezielte Richtlinien auf.

Automatische Typumwandlung für Spaltenmasken

Azure Databricks wandelt automatisch sowohl die Eingabe als auch die Ausgabe von Spaltenmaskierungsfunktionen um, die aus ABAC-Richtlinien abgeleitet wurden. Der Wert der Eingabespalte wird in den Parametertyp der Maskenfunktion gecastet, und die Funktionsausgabe wird in den Datentyp der Zielspalte gecastet. Dadurch wird die Typkonsistenz und das zuverlässige Abfrageverhalten beim Maskieren von Spalten sichergestellt. Die automatische Umwandlung funktioniert wie folgt:

1. Ausführung der Maskierungsfunktion: Wenn die Richtlinienauswertung bestimmt, dass die Maskierung gilt, wird die Maskierungsfunktion für die übereinstimmenden Spaltenwerte ausgeführt.
2. Automatische Typumwandlung: Azure Databricks wandelt den Eingabespaltenwert so um, dass er dem Parametertyp der Funktion entspricht, und wandelt die Funktionsausgabe in den Datentyp der Zielspalte um.
3. Ergebnisrückgabe: Das ordnungsgemäß eingegebene Ergebnis wird an die Abfrage zurückgegeben.

Wenn die Eingabe- oder Ausgabetypen nicht kompatibel sind, schlägt die Umwandlung fehl, und die Abfrage gibt einen Laufzeitfehler zurück. Typumwandlung folgt bei CAST-Operationen den ANSI-SQL-Standards (vollständige Details zur Kompatibilität), mit einer Ergänzung, die in allgemeinem SQL nicht unterstützt wird: Richtlinien für ABAC-Spaltenmasken und Zeilenfilter können Spalten mit komplexen Typen in VARIANT umwandeln. STRUCT Spalten werden ab Databricks Runtime 18.1 unterstützt, und ARRAY und MAP<STRING, ...> Spalten ab Databricks Runtime 19. Siehe STRUCT-, ARRAY- und MAP-Spalten maskieren.

Sie müssen sicherstellen, dass Maskenfunktionen Typen zurückgeben, die mit Zielspalten kompatibel sind. Siehe Cast-kompatible Maskierungsfunktionen für Beispiele und den VARIANT Ansatz für flexible Maskierung über Spaltentypen hinweg.