Kernkonzepte für die attributbasierte Zugriffssteuerung (ABAC)

Attributbasierte Zugriffssteuerung (Access Control, ABAC) ist ein Access-Control-Modell, das gesteuerte Tags und Richtlinien verwendet, um Berechtigungen basierend auf Objektattributen anstelle von Zuweisungen pro Objekt zu erteilen. Diese Seite definiert die Bausteine: geregelte Tags, die drei ABAC-Richtlinientypen (Zeilenfilter, Spaltenmaske und GRANT Richtlinien), die zum Konfigurieren erforderlichen Berechtigungen und die Trennung von Aufgaben, die ABAC für alle Teams ermöglicht.

Eine Übersicht über alle ABAC-Themen, einschließlich Lernprogramme, Richtlinienverwaltung, bewährte Methoden und Einschränkungen, finden Sie unter Attributbasierte Zugriffssteuerung im Unity-Katalog .

Was ist ABAC?

Attributbasierte Zugriffssteuerung (Access Control, ABAC) ist ein dynamisches Zugriffssteuerungsmodell, bei dem Zugriffsentscheidungen auf Richtlinien basieren, die anhand von Attributen ausgewertet werden, die sicherungsfähigen Objekten zugeordnet sind. Im Unity-Katalog werden diese Attribute durch geregelte Tags dargestellt. Diese geregelten Tags werden in Richtlinienbedingungen verwendet, um Datenobjekte innerhalb eines bestimmten Bereichs zuzuordnen, z. B. einen Katalog oder ein Schema. Dadurch kann eine einzelne Richtlinie automatisch auf mehrere Datenobjekte angewendet werden, die ihren Bedingungen entsprechen.

Eine ABAC-Richtlinie könnte beispielsweise alle mit PII gekennzeichneten Spalten für Tabellen innerhalb von mit HR gekennzeichneten Schemas maskieren. Wenn neue Datenobjekte erstellt und markiert werden, wird die Richtlinie automatisch angewendet, ohne dass für jedes Objekt separate Richtliniendefinitionen erforderlich sind.

ABAC unterstützt die Sicherheit auf Zeilen- und Spaltenebene durch Zeilenfilterrichtlinien und Spaltenformatrichtlinien für Tabellen, materialisierte Ansichten und Streamingtabellen. Zeilenfilterrichtlinien beschränken, welche Zeilen ein Benutzer sehen kann. Spaltenmaskierungsrichtlinien steuern, wie Spaltenwerte Benutzern angezeigt werden. Einen Vergleich mit Zeilenfiltern und Spaltenmasken auf Tabellenebene siehe Wann soll ABAC im Vergleich zu Zeilenfiltern auf Tabellenebene und Spaltenmasken verwendet werden.

ABAC unterstützt außerdem die dynamische Gewährung von Berechtigungen durch GRANTRichtlinien (Beta) bei unterstützten absicherbaren Objekttypen. Siehe ABAC-Richtlinien GRANT (Beta).

Gesteuerte Tags

Im Unity-Katalog werden Attribute als geregelte Tags implementiert. Gesteuerte Tags sind Schlüsselwertpaare, die auf Kontoebene definiert sind und auf Unity Catalog sicherungsfähige Objekte wie Kataloge, Schemas, Tabellen, Spalten, Modelle und Volumes sowie Arbeitsbereichsobjekte angewendet werden. Sie stellen Merkmale wie Vertraulichkeit, Klassifizierung oder Geschäftsdomäne dar.

Standardmäßig übernehmen sicherungsfähige Elemente die Tags aus ihrem übergeordneten Katalog oder Schema. Sie können geerbte Tags auf jeder Ebene außer der Spaltenebene überschreiben: Spaltentags erben nicht von der übergeordneten Tabelle und müssen direkt angewendet werden.

Auf gesteuerte Tags kann in Richtlinienbedingungen mithilfe integrierter Funktionen wie has_tag() und has_tag_value() verwiesen werden, die überprüfen, ob ein bestimmtes Tag im Zieldatenobjekt entweder direkt oder über die Tagvererbung vorhanden ist.

Geregelte Tags werden auf Kontoebene definiert. Dies bedeutet, dass Sie die gleiche Tagtaxonomie in Ihrem gesamten Datenbestand in einem Konto verwenden können, einschließlich mehrerer Metastores.

Weitere Informationen finden Sie unter „Geregelte Tags“ und „Tags auf im Unity-Katalog sicherbare Objekte anwenden“.

Richtlinien

Richtlinien werden an sicherungsfähige Objekte im Unity-Katalog angefügt, um Zugriffssteuerungsregeln basierend auf Tagbedingungen zu definieren. Unten ist ein Beispiel aufgeführt:

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Jede Richtlinie gibt Folgendes an:

• Bereich: Das sicherungsfähige Objekt, an das die Richtlinie angefügt ist, angegeben durch die ON Klausel. Das Anwenden einer Richtlinie auf ein sicherbares Objekt bedeutet, dass die Richtlinienbedingungen für alle Objekte des in der FOR-Klausel angegebenen Typs ausgewertet werden, und zwar für das Objekt selbst und alle seine untergeordneten Objekte.
  • Für Zeilenfilter- und Spaltenmaskierungsrichtlinien sind die unterstützten Richtlinienbereiche CATALOG, SCHEMA oder TABLE. Für GRANT-Richtlinien (Beta) sind CATALOG und SCHEMA unterstützte Richtlinienbereiche.
  • Tabellen, einschließlich Streaming-Tabellen und materialisierter Ansichten, sind der einzige unterstützte sichere Typ für Zeilenfilter- und Spaltenmaskenrichtlinien, die mit der Klausel spezifiziert sind FOR TABLES . GRANT Richtlinien (Beta) gelten für Modelle, Modelldienste, Modellanbieterdienste, MCP-Dienste und Agentendienste und verwenden die Klausel GRANT <privilege> FOR <securable_type> . Für die vollständige Liste der unterstützten sicheren Typen und Privilegien siehe Unterstützte sichere Typen und Privilegien.
  • Eine an einem Katalog angefügte Richtlinie wird für alle Tabellen in diesem Katalog ausgewertet. Eine an ein Schema angehängte Richtlinie wird auf alle Tabellen in diesem Schema angewendet. Eine einer Tabelle zugeordnete Richtlinie wird ausschließlich anhand dieser Tabelle ausgewertet.

• Prinzipale: Wer die Richtlinie betrifft und wer ausgenommen ist. Die TO Klausel gibt die Benutzer, Gruppen oder Dienstprinzipale an, die der Richtlinie unterliegen. Die optionale EXCEPT Klausel schließt bestimmte Prinzipale aus dieser Richtlinie aus.
• Aktionen: Gibt an, ob die Richtlinie einen Zeilenfilter, eine Spaltenmaskierung oder eine Berechtigungsvergabe anwendet. Zeilenfilter- und Spaltenformatrichtlinien verwenden eine benutzerdefinierte Funktion (UDF), um die Filter- oder Maskierungslogik zu implementieren. GRANT Richtlinien (Beta) verwenden keine UDFs. Siehe Richtlinientypen.
• Bedingungen: Tagbasierte Ausdrücke, die bestimmen, auf welche Tabellen oder Spalten die Richtlinienziele ausgerichtet sind. Siehe Bedingungen und integrierte Funktionen.

Richtlinien werden über die Benutzeroberfläche oder programmgesteuert mit SQL-Anweisungen erstellt und verwaltet, wie z. B. CREATE POLICY, DROP POLICY, SHOW POLICIES oder DESCRIBE POLICYREST-APIs, Databricks-SDKs oder Terraform. Weitere Informationen finden Sie unter Erstellen und Verwalten von ABAC-Richtlinien für die vollständige Syntax und Beispiele.

Richtlinientypen

ABAC unterstützt drei Richtlinientypen: Zeilenfilterrichtlinien, Spaltenformatrichtlinien und GRANT Richtlinien (Beta). Zeilenfilter- und Spaltenmaskierungsrichtlinien erfordern UDFs, um die Filter- oder Maskierungslogik zu implementieren. GRANT Richtlinien verwenden keine UDFs und gewähren stattdessen Berechtigungen, wenn ihre tagbasierte Bedingung mit den Attributen des Zielobjekts übereinstimmt.

Zeilenfilterrichtlinien

Zeilenfilterrichtlinien beschränken, welche Zeilen ein Benutzer in einer Tabelle basierend auf Werten in Spalten anzeigen kann, die durch Tags identifiziert werden, die den Bedingungen und integrierten Funktionen entsprechen. Die Richtlinie verweist auf eine UDF, die jede Zeile auswertet. Zeilen, bei denen die Funktion FALSE zurückgibt, werden von den Abfrageergebnissen ausgeschlossen. Argumente werden über die Klausel USING COLUMNS an die UDF übergeben.

Beispielanwendungsfall: Stellen Sie für einen Verkaufskatalog sicher, dass das EMEA-Team nur EMEA-Verkaufsdatensätze in allen Tabellen mit einer Spalte mit Kategorisierung regionsieht.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Spaltenmaskenrichtlinien

Spaltenformatrichtlinien steuern, welche Werte ein Benutzer für bestimmte Spalten sieht, die durch Tags identifiziert werden, die den Bedingungen und integrierten Funktionen entsprechen. Die Richtlinie verweist auf eine UDF, die den Spaltenwert als Eingabe verwendet und den ursprünglichen Wert oder eine maskierte Version zurückgibt. Der maskierte Spaltenwert wird automatisch als erstes Argument aus dem ON COLUMN-Klausel gebunden, und zusätzliche Argumente können über USING COLUMNS übergeben werden. Der Rückgabetyp muss mit dem Datentyp der Spalte übereinstimmen oder in diesen konvertierbar sein.

Beispielanwendungsfall: Maskieren Sie SSN-Spalten pii : ssn , sodass Benutzer ***-**-XXXX (nur letzte vier Ziffern) sehen, es sei denn, sie befinden sich in einer Compliancegruppe, die von der Richtlinie ausgenommen ist.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

Die USING COLUMNS Klausel übergibt Argumente an die UDF. Sie akzeptiert Aliase für Spalten, die einem tagbasierten Ausdruck entsprechen, oder Konstantenwerte (an zitierte Zeichenfolgen, numerische Literale, boolesche Werte (TRUE/FALSE) oder NULL), die in der Reihenfolge angegeben werden, in der die Funktion sie erwartet. Es akzeptiert auch Tagintrospection-Funktionen, die den Wert eines Tags zur Abfragezeit extrahieren und an die UDF übergeben. Bei Richtlinien für Spaltenmasken handelt es sich hierbei um zusätzliche Argumente, die über die maskierte Spalte hinausgehen (die automatisch über ON COLUMN gebunden wird). Dadurch kann eine einzelne UDF für Richtlinien mit verschiedenen Parametern wiederverwendet werden.

SQL UDFs werden empfohlen, um eine bessere Leistung zu erzielen. Python-UDFs, die im Unity-Katalog registriert sind, werden ebenfalls unterstützt, obwohl der Abfrageoptimierer sie nicht in-line setzen oder optimieren kann, wie es bei SQL-UDFs der Fall ist. Anleitungen zur Auswahl von UDF-Sprachen finden Sie unter Leistungsüberlegungen .

GRANT Richtlinien (Beta)

GRANT Richtlinien gewähren dynamisch ein Unity-Katalogrecht, wenn ihre tagbasierte Bedingung mit den Tags eines sicherungsfähigen Objekts übereinstimmt. Jedes Mal, wenn ein Benutzer versucht, auf ein sicherungsfähiges Objekt zuzugreifen, identifiziert Unity Catalog alle GRANT Richtlinien, deren Bereich das Objekt abdeckt, überprüft, ob sich der Benutzer in der TO Liste und nicht in der EXCEPT Liste befindet, und wertet die Bedingung der Richtlinie WHEN anhand der Tags auf dem sicherungsfähigen Objekt aus, einschließlich geerbter Tags. Wenn die Richtlinie gilt, gewährt Unity Catalog die Berechtigung. GRANT Richtlinien verwenden dasselbe Bewertungsmodell wie Zeilenfilter- und Spaltenmaskierungsrichtlinien, mit der Ausnahme, dass sie keine UDFs verwenden. Die Bedingung wird direkt in der Richtliniendefinition definiert.

Die effektiven Berechtigungen für ein Objekt sind die Summe der direkt gewährten Berechtigungen sowie aller anwendbaren GRANT-Richtlinien. Ein Prinzipal hat die Berechtigung, wenn eine GRANT-Richtlinie im Geltungsbereich für diesen Prinzipal gilt oder eine direkte GRANT derselben Berechtigung gilt. GRANT Richtlinien gewähren nur zusätzlichen Zugriff. Sie können den Zugriff nicht widerrufen, der direkt gewährt wurde.

Bedingungen und integrierte Funktionen

Bedingungen sind tagbasierte Ausdrücke, die bestimmen, auf welche Tabellen und Spalten eine Richtlinie im Geltungsbereich abzielt.

• Tabellenbedingungen (WHEN Klausel): Boolesche Ausdrücke, die Tabellen basierend auf ihren Tags entsprechen. Wenn dieser Wert nicht angegeben wird, beträgt er standardmäßig TRUE, d. h. die Richtlinie gilt für alle Tabellen im Bereich.
• Spaltenbedingungen (MATCH COLUMNS Klausel): Ein oder mehrere durch Kommas getrennte boolesche Ausdrücke, die identifizieren, auf welche Spalten die Richtlinienziele ausgerichtet sind. Jeder Ausdruck kann eine einzelne integrierte Funktion wie has_tag('pii') oder eine Kombination mit logischen Operatoren wie has_tag_value('pii', 'ssn') AND has_tag('sensitive') sein. Jedem Ausdruck kann ein Alias (nach AS angegeben) zugewiesen werden, auf den in den ON COLUMN- und USING COLUMNS-Klauseln verwiesen werden kann. Eine Richtlinie kann bis zu 3 Spaltenausdrücke enthalten, und alle müssen übereinstimmen, damit die Richtlinie angewendet wird.

Beide Klauseltypen verwenden die folgenden integrierten Funktionen, die vom Unity-Katalog anhand sicherungsfähiger Metadaten ausgewertet werden:

Um anhand der Attribute des Benutzers, der die Abfrage ausführt, statt anhand von Ressourcentags abzugleichen, siehe Identitätsattributfunktionen.

Um im Kontext einer Anfrage, wie z. B. der aufrufenden Anwendung, abzustimmen, siehe Context-Attributfunktionen.

Tags werden nicht von Tabellen auf Spalten übertragen. Die Verwendung von has_tag() in einer MATCH COLUMNS-Klausel führt nur zu einer Übereinstimmung mit Tags auf Spaltenebene, nicht jedoch mit Tags der übergeordneten Tabelle oder ihrer Vorfahren.

Beispiel: Verwenden von zwei Bedingungen für Spalten. Ein customers Schema enthält Tabellen mit einer markierten pii : email E-Mail-Spalte und einer Zustimmungsspalte, die markiert consent_to_contactist. Die Richtlinien maskieren E-Mail-Adressen, es sei denn, der Kunde hat zugestimmt, kontaktiert zu werden. Es verwendet zwei Spaltenbedingungen:

1. has_tag_value('pii', 'email') identifiziert die Spalte, die E-Mail-Adressen enthält (die spalte, die maskieren soll).
2. has_tag('consent_to_contact') identifiziert die Spalte, die Zustimmungsinformationen enthält (wird von der UDF verwendet, um zu entscheiden, ob maskiert werden soll).

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Diese Richtlinie gilt nur für Tabellen mit markierter pii : email Spalte und markierter consent_to_contactSpalte. Wenn eine Tabelle keine Spalten enthält, die beide Bedingungen erfüllen, gilt die Richtlinie nicht, und die Daten werden nicht maskiert zurückgegeben.

Identitätsattributfunktionen (Beta)

Funktionen der Identitätsattribute bewerten Eigenschaften des Benutzers, der die Abfrage ausführt, wie z. B. Abteilung, Land oder Stellenrolle. Diese Attribute können von Ihrem Identitätsanbieter bereitgestellt und direkt in Richtlinienbedingungen verwendet werden. Dadurch können Sie flexiblere Bedingungen ausdrücken, ohne für jede Kombination von Identitätseigenschaften separate Gruppen zu erstellen. Wenn sich die Identitätsinformationen in Ihrem Identitätsanbieter ändern, verwenden Richtlinien die aktualisierten Attributwerte, genauso wie sie aktualisierte Gruppenmitgliedschaft verwenden.

Diese Funktionen werden in der WHEN Klausel der Spaltenmaskenrichtlinien unterstützt.

Beachte beim Erstellen von Richtlinien, die diese verwenden, das folgende Verhalten:

• Ein fehlendes Attribut wird zu false. Wenn der Benutzer keinen Wert für das Attribut hat, gar keine Attribute hat oder das Attribut nicht existiert, gibt die Funktion zurück, false anstatt einen Fehler auszulösen. Phrasenbedingungen, sodass dieses false Ergebnis den Zugriff einschränkt. Siehe Identitätsattributbedingungen.
• Attributschlüssel und -werte sind groß- und kleinschreibungsabhängig und werden exakt verglichen: Finance und finance stimmen nicht überein.
• Attributänderungen werden nicht sofort wirksam. Änderungen in Ihrem Identitätsanbieter werden nicht sofort mit Azure Databricks synchronisiert. Weitere Informationen finden Sie unter Identitätsattribute .

Für die von Azure Databricks unterstützten Attribute und deren Bereitstellung siehe Identitätsattribute. Beispiele für die Verwendung von Identitätsattributen in Richtlinien finden Sie unter Maskieren einer Spalte anhand der Attribute des abfragenden Benutzers.

Kontextattributfunktionen (Beta)

Kontextattribute werden verwendet, um den Datenzugriff für Anfragen im Namen eines Benutzers über eine OAuth-Anwendung einzuschränken. Dieses Setup kann genutzt werden, um Agenten daran zu hindern, auf Daten zuzugreifen, wenn sie im Namen eines Benutzers handeln, während diese Daten zugänglich bleiben, falls der Benutzer sie direkt im Arbeitsbereich abfragt.

Sie umfasst jede OAuth-Anwendung, sei es eine integrierte App wie die Azure Databricks CLI oder eine individuelle OAuth-App. Es gibt zwei verschiedene Kontextmerkmale:

• request.is_on_behalf_of: die Zeichenkette 'true' oder 'false'. Zeigt an, ob die Anfrage im Namen eines Benutzers über eine OAuth-App ausgeführt wird. Jede Anfrage von einer OAuth-App hat diesen Wert auf 'true'gesetzt.
• request.client_id: die OAuth-Client-ID. Dies kann verwendet werden, um einen bestimmten OAuth-Client anzusprechen, entweder eine integrierte OAuth-App (zum Beispiel ) databricks-clioder eine eigene OAuth-App. Das client_id kann auf der Seite App-Verbindungen in der Kontokonsole angezeigt werden. Für Databricks-Apps kann sie auch auf der Autorisierungsseite der App unter OAuth2 App Client ID beobachtet werden. Oder es kann aus dem identity_metadata.acting_resource Feld in den Audit-Protokollen abgefragt werden.

Diese Attribute sind nicht benutzermodifizierbar und werden explizit vom System bereitgestellt; Ein Anrufer beeinflusst sie nur dadurch, wie sie sich authentifizieren. Diese Attribute können verwendet werden, um externe Agenten zu identifizieren, nicht Genie-Agenten.

Kontextattribute können durch folgende Funktionen verwendet werden:

Bei Attributschlüsseln wird die Groß-/Kleinschreibung nicht berücksichtigt, bei Werten hingegen schon.

Um zu erfahren, wie man diese Kontextattribute nutzt, um den Zugriff von externen Agenten zu steuern, siehe Zugriff einschränken für externe Agenten, die im Namen eines Benutzers handeln.

Benutzerdefinierte Funktionen (UDFs)

Zeilenfilter- und Spaltenmaskierungsrichtlinien verwenden benutzerdefinierte Funktionen (UDFs), um ihre Filter- oder Maskierungslogik zu implementieren. Informationen zum Erstellen und Verwalten von UDFs finden Sie unter SQL- und Python-benutzerdefinierte Funktionen (UDFs) in Unity Catalog; Beispiele finden Sie unter Gängige Muster für Zeilenfilterung und Spaltenmaskierung.

Funktionen zur Tag-Introspektion

Tagintrospection-Funktionen extrahieren den Wert eines geregelten Tags und übergeben ihn über die USING COLUMNS Klausel an eine UDF. Da die UDF den Tagwert als Argument empfängt, kann eine einzelne Richtlinie und UDF mehrere Tagwerte verarbeiten, anstatt eine separate Richtlinie für jeden Tagwert zu benötigen. Diese Funktionen sind nur für Zeilenfilter- und Spaltenmaskierungsrichtlinien verfügbar, da GRANT-Richtlinien keine UDFs verwenden.

Das Erstellen einer Richtlinie, die diese Funktionen verwendet, erfordert Databricks Runtime 18 LTS oder höher. Diese Anforderung gilt nur für die Richtlinienerstellung, nicht für die Abfrage der geregelten Tabellen.

Zum Abfragezeitpunkt wertet Unity Catalog diese Funktionen anhand der Tags auf der Tabelle oder den Spalten aus, auf die die Richtlinie zutrifft: get_tag_value() liest aus der Tabelle, die die Bedingung WHEN erfüllt, und get_column_tag_value() liest aus den Spalten, die durch MATCH COLUMNS identifiziert werden. Sie können nur in der USING COLUMNS Klausel angezeigt werden, nicht in WHEN oder MATCH COLUMNS unter Bedingungen.

Beide Funktionen nehmen den Tag-Schlüssel als Zeichenfolgenliteral entgegen. Das Tag muss ein verwaltetes Tag sein, und get_column_tag_value() muss auf einen Alias verweisen, der in der MATCH COLUMNS-Klausel der Richtlinie vorhanden ist. Ist das Tag nicht verwaltet oder ist der Alias ungültig, schlägt die Erstellung der Richtlinie fehl. Ist ein referenziertes Tag zum Zeitpunkt der Ausführung einer Abfrage nicht mehr verwaltet, schlagen Abfragen gegen die Zieltabellen der Richtlinie zur Laufzeit fehl.

Beispiel: Eine Richtlinie für alle PII-Typen

Ohne Tag-Introspektion erfordert die Maskierung jeder Art von personenbezogenen Informationen (E-Mail, Sozialversicherungsnummer, Telefonnummer) eine separate Richtlinie und eine eigene UDF für jeden Tag-Wert. Mit get_column_tag_value() übergibt eine einzige Richtlinie den pii-Tag-Wert der übereinstimmenden Spalte an eine UDF. Die UDF verzweigt sich anhand dieses Werts:

CREATE FUNCTION mask_pii(col STRING, pii_type STRING)
RETURNS STRING
RETURN CASE
  WHEN pii_type = 'email' THEN regexp_replace(col, '(^[^@]+)', '***')
  WHEN pii_type = 'ssn' THEN '***-**-' || right(col, 4)
  WHEN pii_type = 'phone' THEN '***-***-' || right(col, 4)
  ELSE col
END;

CREATE POLICY mask_all_pii
ON CATALOG main
COLUMN MASK mask_pii
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS col
ON COLUMN col
USING COLUMNS (get_column_tag_value(col, 'pii'));

Für jede maskierte Spalte entspricht get_column_tag_value(col, 'pii') dem Tag-Wert pii dieser Spalte (email, ssn, phone usw.), und mask_pii wendet die passende Transformation an. Ein neuer Tag-Wert erfordert lediglich einen neuen Zweig in der UDF, keine neue Richtlinie.

Trennung von Aufgaben und Berechtigungen

Das Einrichten von ABAC umfasst mehrere Schritte mit jeweils eigenen Berechtigungsanforderungen. Organisationen können diese Aufgaben je nachdem, wie sie sich für die Trennung von Aufgaben entscheiden, über spezielle Gruppen verteilen. Beispielsweise kann eine Organisation zentral eine Tag-Taxonomie definieren, und anschließend können Datenverantwortliche Daten klassifizieren, Governance-Administratoren Richtlinien verfassen, Datenersteller Objekte innerhalb verwalteter Bereiche erstellen und Datennutzer auf die verwalteten Objekte zugreifen.

1. Erstellen Sie die Etikettentaxonomie. Definieren Sie die geregelten Tagschlüssel und deren zulässige Werte, bevor eine person sie anwendet oder Richtlinien schreibt. Erstellen Sie beispielsweise ein sensitivity Tag mit kontrollierten Werten (public, internal, , confidentialrestricted) oder einem pii Tag mit Werten wie ssn, emailund phone_number. Informationen zu Benennungskonventionen und Taxonomiedesign finden Sie unter "Standardisieren von Attributen und Benennungen ".

   • Erforderliche Berechtigungen: Kontoadministrator oder ein Benutzer mit CREATE-Berechtigung für Tags auf Kontoebene.

2. Datenressourcen taggen. Ein Datenverwalter, ein Datenersteller oder ein KI-Klassifizierungssystem weist den sicherheitsrelevanten Objekten im Unity Catalog – wie Katalogen, Schemata, Tabellen, Spalten, Modellen und Volumes – vordefinierte Tags zu. Markieren Sie z. B. Spalten, die personenbezogene Informationen enthalten, mit pii : ssnoder markieren Sie ein Modell mit lifecycle : production. Das richtige Tagging ist der wesentliche erste Schritt für ABAC-Richtlinien, die angewendet werden sollen.

   • Erforderliche Berechtigungen: ASSIGN für das Tag und APPLY TAG für das Objekt.

3. Erstellen Sie eine Richtlinie. Ein Governanceadministrator erstellt eine Richtlinie in einem Bereich, z. B. einem Katalog oder Schema. Die Richtlinie gibt an, für wen sie gilt, welche Bedingungen sie auswertet und welche Aktion angewendet werden soll, z. B. einen Zeilenfilter, eine Spaltenmaske oder eine Berechtigungsvergabe.

   • Erforderliche Berechtigungen: MANAGE-Berechtigungs- oder -Objektbesitz für das sicherungsfähige Objekt, an das die Richtlinie angefügt ist. Für Zeilenfilter- und Spaltenmaskierungsrichtlinien ist auch die EXECUTE-Berechtigung für die UDF erforderlich.

4. Erstellen sie Datenobjekte. Datenersteller erstellen absicherbare Objekte wie Tabellen, Modelle oder Volumes in den Bereichen, für die sie Zugriffsrechte erhalten haben. Neue Objekte erben Tags aus übergeordneten Katalogen und Schemas. Datenersteller haben APPLY TAG automatisch auf den Objekten, die sie erstellen, wodurch sie zusätzliche Tags anwenden können. Alternativ können sie sich auf die automatische Datenklassifizierung verlassen, um Tagging zu verarbeiten. Wenn eine Organisation auf Datenersteller angewiesen ist, ihre eigenen Objekte zu kategorisieren, sollte sie klare Taggingpraktiken einrichten. Datenersteller müssen keine Zugriffssteuerungen konfigurieren, wenn Richtlinien auf höheren Ebenen festgelegt werden, was Azure Databricks empfiehlt.

   • Für das übergeordnete Objekt sind folgende Berechtigungen erforderlich: CREATE TABLE oder andere relevante Erstellungsberechtigungen.

5. Von Access gesteuerte Objekte. Wenn ein Benutzer versucht, auf ein sicherungsfähiges Objekt innerhalb des Gültigkeitsbereichs einer Richtlinie zuzugreifen, wertet Unity Catalog die anwendbaren Richtlinien automatisch aus. Für Zeilenfilter- und Spaltenformatrichtlinien sieht der Benutzer gefilterte oder maskierte Daten, wenn die Tabelle oder Spalten den Bedingungen der Richtlinie entsprechen und der Benutzer nicht ausgenommen ist. Für Richtlinien vom Typ GRANT (Beta) erhält der Benutzer das gewährte Privileg, wenn die Bedingungen erfüllt sind und der Benutzer sich in TO und nicht in EXCEPT befindet.

   • Erforderliche Berechtigungen: Für Zeilenfilter- und Spaltenmaskierungsrichtlinien müssen Benutzern direkte Berechtigungen für das Objekt Tabelle gewährt werden, z. B. SELECT. Diese Richtlinien filtern Datensätze oder Maskenspalten für Tabellen, auf die der Benutzer bereits zugreifen kann. Sie erteilen keine Berechtigungen selbstständig. GRANT-Richtlinien (Beta) gewähren die Berechtigung selbst und werden mit allen direkten Berechtigungen für dasselbe Sicherungsobjekt zusammengeführt.

Vorteile von ABAC

• Wiederverwendbare Richtlinien basierend auf Attributen: Eine einzelne Richtlinie kann auf mehrere Datenobjekte angewendet werden, die mit denselben attributbasierten Bedingungen übereinstimmen, anstatt an ein bestimmtes Objekt gebunden zu werden.

• Automatische Anwendung auf neue Objekte: Wenn neue Datenobjekte innerhalb des Gültigkeitsbereichs erstellt und mit den relevanten Attributen gekennzeichnet sind, gelten vorhandene ABAC-Richtlinien ohne zusätzliche Konfiguration. Richtlinien wirken wie zukünftige Zuschüsse, was bedeutet, dass Zugriffssteuerungen automatisch angewendet werden, wenn neue Daten erstellt und entsprechend kategorisiert werden.

• Einheitliche Durchsetzung innerhalb eines Bereichs: Richtlinien, die auf Katalog- oder Schemaebene angefügt sind, werden dynamisch für übereinstimmende Datenobjekte in diesem Bereich ausgewertet, wodurch Unterschiede beim Filtern oder Maskieren ähnlicher Daten entfernt werden.

• Geringere laufende Wartung: Änderungen können vorgenommen werden, indem Richtlinienlogik oder gesteuerte Tags aktualisiert werden, anstatt jedes einzelne Objekt wie erforderlich mit Zeilenfiltern auf Tabellenebene und Spaltenmasken zu überarbeiten.

• Zentrale Governance: Da Richtlinien einmal definiert und auf viele übereinstimmende Datenobjekte angewendet werden können, können Governanceteams Steuerelemente in größeren Teilen der Datenmenge mit weniger Richtliniendefinitionen verwalten.

Weitere Ressourcen

• Geregelte Tags
• POLICY ERSTELLEN
• Verwalten von Berechtigungen im Unity-Katalog
• Zeilenfilter und Spaltenmasken
• Referenz zur Systemtabelle des Überwachungsprotokolls
• Anforderungen, Kontingente und Einschränkungen für Zeilenfilter- und Spaltenmaskierungsrichtlinien