ABAC-Richtlinien DENY (Beta)

Von Bedeutung

ABAC-Richtlinien DENY befinden sich in Der Betaversion. DENY Richtlinien sind auf Metastore-, Katalog- oder Schema-Ebene angehängt und verweigern die Berechtigung MANAGE ACCESS CONTROL für die unterstützten sicherbaren Objekttypen. Siehe Unterstützte sicherungsfähige Typen und Berechtigungen. Um eine DENY Richtlinie an jeden Katalog im Metastore anzuhängen, siehe Metastore-Level ABAC policies (Beta).

ABAC-Richtlinien DENY verweigern Prinzipalen explizit Unity Catalog-Berechtigungen für absicherbare Objekte, deren Governance-Tags mit einer Bedingung übereinstimmen, und haben stets Vorrang vor jeder Gewährung. Diese Seite behandelt, wie man ABAC-Richtlinien DENY erstellt, bearbeitet, listet und löscht, was es bedeutet, abzulehnen MANAGE ACCESS CONTROL, sowie den aktuellen Umfang und die Einschränkungen.

Sie können ABAC-Richtlinien DENY mit Catalog Explorer, SQL, der REST-API,Terraform oder den Databricks-SDKs erstellen und verwalten.

Eine Übersicht über ABAC und Kernkonzepte, einschließlich geregelter Tags und integrierter Funktionen wie has_tag und has_tag_value, finden Sie unter Kernkonzepte für die attributbasierte Zugriffssteuerung (ABAC).

Computeanforderungen

Die Verwendung von SQL zum Erstellen, Ändern oder Entfernen DENY von Richtlinien erfordert eine klassische Compute-Ressource , die Databricks Runtime 18 LTS oder höher ausführt.

Note

Databricks Runtime 18 ist neuer als Databricks Runtime 18.0, 18.1 und 18.2. Features, die zuvor als spätere nummerierte Version ausgeliefert wurden, werden stattdessen als veraltete Updates für Databricks Runtime 18 ausgeliefert. Ausführliche Informationen finden Sie unter "Informationen zu einheitlichen Versionshinweisen".

Was ist eine DENY Richtlinie?

Eine DENY-Richtlinie ist eine Richtlinie zur attributbasierten Zugriffssteuerung, die bestimmten Principals explizit ein Unity-Catalog-Privileg für schützbare Objekte verweigert, deren verwaltete Tags der Bedingung der Richtlinie entsprechen. Unity Catalog bewertet die WHEN Bedingung der Richtlinie anhand der beaufsichtigten Tags auf jedem sekurablen Objekt im Umfang der Richtlinie bei jeder Überprüfung des Zugriffs und verweigert das Privileg für jedes übereinstimmende sekurable Objekt.

Eine DENY Richtlinie hat Vorrang vor jeder Gewährung derselben Berechtigung und kann nicht durch eine individuelle Gewährung außer Kraft gesetzt werden.

Eine DENY Richtlinie wird durch die folgenden Regeln geregelt:

DENY hat immer Vorrang. Eine DENYRichtlinie setzt jede Gewährung desselben Privilegs außer Kraft, einschließlich Gewährungen, die durch Vererbung, Gruppenmitgliedschaft oder implizit durch Objektbesitz erteilt werden. Kein einzelner Zuschuss kann einen aktiven DENY außer Kraft setzen.
Metastore-Administratoren sind immer implizit ausgenommen. Ein Metastore-Administrator ist niemals von einer DENY Richtlinie für MANAGE ACCESS CONTROLbetroffen, einschließlich einer Metastore-Level-Richtlinie DENY , die sicherstellt, dass es immer einen Weg zur Änderung oder Entfernung DENY einer Richtlinie gibt.
DENY wird nach unten vererbt. Die Verweigerung selbst wird entlang der Objekthierarchie nach unten vererbt, genauso wie Berechtigungen der Privilegienvererbung folgen. Eine DENY Richtlinie für einen Katalog verweigert die Berechtigung für alle aktuellen und zukünftigen Objekte innerhalb dieses Katalogs, und eine DENY Richtlinie für ein Schema verweigert sie für alle aktuellen und zukünftigen Objekte innerhalb dieses Schemas.
Überlappende DENY Richtlinien werden kombiniert, und das restriktivste Ergebnis gilt. Wenn mehrere DENY Policen auf denselben Grundsatz angewendet werden, sind ihre Auswirkungen vereint. Eine Politik DENY kann keinen Prinzipal ausnehmen, den eine andere DENY Politik anvisiert. Wenn eine der anwendbaren Richtlinien ein Privileg verweigert, wird das Privileg verweigert.
DENY Politiken sind unabhängig von Zuschüssen. Im Gegensatz zu einem REVOKE, der nur ein ausdrücklich gewährtes Privileg entfernt, hängt eine DENY-Richtlinie nicht von einer bestehenden Gewährung ab. Sie können ein Privileg verweigern, das nie gewährt wurde, und das Entfernen einer Berechtigung entfernt keine DENY-Richtlinie. Eine DENY Richtlinie bleibt in Kraft, bis sie ausdrücklich aufgehoben wird.

DENYRichtlinien können entweder auf von Ihnen erstellte Tags oder systemdefinierte Tags verweisen, die von Azure Databricks unter ihren Bedingungen definiert wurden.

DENY Richtlinien unterscheiden sich in zweierlei Hinsicht von Zeilenfilter- und Spaltenmaskierungsrichtlinien:

Zeilenfilter- und Spaltenformatrichtlinien beschränken den Inhalt von Daten, auf die ein Benutzer bereits zugreifen kann. DENY Richtlinien bestimmen, ob ein Prinzipal überhaupt eine Handlung ausführen kann, wie etwa die Verwaltung der Zugriffskontrolle.
Zeilenfilter- und Spaltenformatrichtlinien erfordern eine benutzerdefinierte Funktion (UDF), um den Filter oder die Maske zu implementieren. DENY Richtlinien verwenden keine UDFs. Die Bedingung wird direkt in der Richtliniendefinition definiert.

Was bedeutet die Verweigerung von MANAGE ACCESS CONTROL?

MANAGE ACCESS CONTROL ist ein dem MANAGE Privileg untergeordnetes Privileg, das die Zugriffsverwaltung regelt, z. B. das Erteilen und Entziehen von Privilegien, die Übertragung der Eigentümerschaft und die Verwaltung von ABAC-Richtlinien. Es kann abgelehnt, aber nicht gewährt werden. Details finden Sie unter ZUGRIFFSKONTROLLE VERWALTEN.

DENY Richtlinien können verwendet werden, um die Berechtigung MANAGE ACCESS CONTROL zu entziehen und so zu verhindern, dass bestimmte Prinzipalen, einschließlich der Objektbesitzer, Operationen zur Zugriffsverwaltung an den Objekten im Geltungsbereich einer Richtlinie durchführen. Es entfernt die Berechtigungen zur Zugriffsverwaltung, die von diesem Privileg gesteuert werden, unabhängig davon, wie ein Prinzipal darüber verfügt, sei es durch das MANAGE-Privileg oder implizit durch den Besitz des Objekts.

Bei den betroffenen Objekten verliert ein Prinzipal, dem der Zugriff verweigert wurde, die Möglichkeit:

Gewähren und widerrufen Sie Privilegien.
Ändere den Besitzer des Objekts.
Erstellen und verwalten Sie ABAC-Richtlinien.
Konfigurieren Sie Ziele für Zugriffsanfragen.
Verwalten Sie Workspace-Katalog-Bindungen, falls das Privileg auf Katalogebene verweigert wird.

Eine Ablehnung von MANAGE ACCESS CONTROL entzieht einem Prinzipal nicht die Möglichkeit, Objektmetadaten einzusehen. Ein Prinzipal mit MANAGE oder ein Objekteigentümer kann weiterhin sehen, dass das Objekt existiert, und kann weiterhin alle anderen Berechtigungen wahrnehmen, die durch MANAGE, seine sonstigen Privilegien oder die Inhaberschaft gewährt werden. Sie verlieren nur die oben genannten Zugangsmanagement-Fähigkeiten.

Das Ablehnen von MANAGE ACCESS CONTROL schließt nicht jeden Pfad, über den ein Prinzipal Daten freigeben kann. Siehe Überlegungen zum Datenaustausch.

DENY Politikbeispiele

Die folgende Richtlinie verweigert allen Kontobenutzern mit Ausnahme der Gruppe data_adminsMANAGE ACCESS CONTROL für jede in catalog_a mit sensitive gekennzeichnete Tabelle. Betroffene Hauptpersonen, einschließlich Tabelleninhaber, verlieren die Möglichkeit, Rechte zu gewähren oder zu widerrufen, das Eigentum zu ändern oder Zeilenfilter und Spaltenmasken in diesen Tabellen zu verwalten:

CREATE POLICY deny_manage_access_control_sensitive_tables
ON CATALOG catalog_a
COMMENT 'Prevent non-admins from managing permissions on sensitive tables'
TO `account users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR TABLES
WHEN has_tag('sensitive');

Die folgende Richtlinie verweigert MANAGE ACCESS CONTROL auf allen Schemas in catalog_a einer bestimmten Gruppe, mit Ausnahme von data_admins. Da DENY sie nach unten erben, verlieren betroffene Hauptverantwortliche auch die Möglichkeit, den Zugriff auf die Objekte innerhalb dieser Schemata zu verwalten:

CREATE POLICY deny_designated_users_catalog_access
ON CATALOG catalog_a
COMMENT 'Prevent designated users from managing access on catalog objects'
TO `designated_users`
EXCEPT `data_admins`
DENY MANAGE ACCESS CONTROL
FOR SCHEMAS;

Unterstützte absicherbare Typen und Privilegien

DENY-Richtlinien unterstützen die Berechtigung MANAGE_ACCESS_CONTROL für die folgenden absicherbaren Typen. Eine Richtlinie bezieht sich auf einen Typ von sicherbarem Objekt. Unity Catalog validiert das Privileg gegen den securable Typ, wenn Sie die Policy erstellen.

Absicherbarer Typ	`MANAGE_ACCESS_CONTROL`
Katalog	✓
Schema	✓
Tabelle	✓
Volumen	✓
Funktion	✓
Modell	✓
Geheimnis	✓

Dies ist die Liste der Sicherheitstypen, die in der Klausel FOR unterstützt werden. Wenn eine Richtlinie an einen Katalog oder ein Schema angehängt wird, wird die DENY auf alle Objekte innerhalb dieses Katalogs oder Schemas vererbt, auch auf Objekte, deren Typ von der Klausel FOR nicht unterstützt wird.

In SQL verwenden Sie nach FOR die Pluralform des Sicherheitselementtyps, wie DENY MANAGE ACCESS CONTROL FOR TABLES oder FOR SCHEMAS. Singularformen werden nicht akzeptiert. Legen Sie in der REST-API for_securable_type auf die Singularform fest, zum Beispiel TABLE.

Erstellen einer DENY Richtlinie

Sie können eine DENY Richtlinie über die Catalog Explorer UI, mit der CREATE POLICY SQL-Anweisung oder mit der REST-API erstellen.

Um eine DENY-Richtlinie zu erstellen, müssen Sie über MANAGE für den Katalog oder das Schema verfügen, an das die Richtlinie zugeordnet ist, oder Eigentümer dieses Securable-Objekts sein.

Katalog-Explorer

DENY Richtlinien müssen aus einem Katalog oder Schema erstellt werden. Der Typ Zugriffsrichtlinie verweigern ist nicht verfügbar, wenn man von einem einzelnen Objekt wie einer Tabelle beginnt.

Klicken Sie im Azure Databricks-Arbeitsbereich auf das Katalog.
Wählen Sie den Katalog oder das Schema aus, in dem Sie die Richtlinie anfügen möchten. DENY Richtlinien können nur auf Katalog- oder Schema-Ebene angehängt werden.
Klicken Sie auf die Registerkarte Richtlinien.
Klicken Sie auf Neue Richtlinie.
Geben Sie unter "Richtlinienidentifikation" einen Richtliniennamen und eine optionale Beschreibung ein.
Unter Prinzipale und Bereich:
- Wählen Sie unter "Angewendet auf" die Prinzipale (Benutzer, Gruppen oder Dienstprinzipale) aus, für die die Richtlinie gilt.
- Wählen Sie unter Except for optional Prinzipale aus, die von der Richtlinie ausgeschlossen werden sollen.
- Bestätigen Sie in Scope den Katalog oder das Schema, dem die Richtlinie zugeordnet ist.
Wählen Sie unter Richtlinientyp die Option Zugriff verweigern aus.
Unter Securable Objects wählen Sie den Securable-Typ, auf den die Policy angewendet wird. Siehe unterstützte Typen und Privilegien.
Unter der Bedingung wählen Sie, wie die Policy auf Securables des gewählten Typs im Katalog oder Schema begrenzt wird:
- Keine Bedingung bewirkt, dass die Richtlinie auf alle Sicherungsobjekte dieses Typs im ausgewählten Katalog oder Schema angewendet wird.
- Sicherbare Objekte, die einem dieser Tags entsprechen wendet die Richtlinie nur auf Sicherungsmodelle an, die mindestens eines der ausgewählten, regulierten Tags tragen.
- Sicherungsobjekte, die einem benutzerdefinierten Ausdruck entsprechen ermöglicht es Ihnen, einen auf Tags basierenden Ausdruck zu erstellen, um zu bestimmen, auf welche Sicherungsobjekte die Richtlinie angewendet wird. Siehe Bedingungen und integrierte Funktionen für die verfügbaren Bedingungsfunktionen.
Unter Privilegien wählen Sie ZUGRIFFSKONTROLLE verwalten. Dies ist die einzige Berechtigung, die DENY-Richtlinien unterstützen.
Klicken Sie auf " Code anzeigen ", um die entsprechende SQL-Anweisung vor dem Speichern zu überprüfen, und klicken Sie dann auf "Richtlinie erstellen".

SQL

Die SQL-Syntax für eine DENY-Richtlinie verwendet einen DENY ... FOR ... WHEN ...-Anweisungstext anstelle von ROW FILTER oder COLUMN MASK.

CREATE [OR REPLACE] POLICY policy_name
ON { METASTORE | CATALOG catalog_name | SCHEMA schema_name }
[COMMENT description]
TO principal [, ...]
[EXCEPT principal [, ...]]
DENY MANAGE ACCESS CONTROL
FOR securable_type
[WHEN condition]

Parameters:

policy_name: Ein Name für die Richtlinie. Muss für alle Richtlinien eindeutig sein, die für dasselbe sicherungsfähige Objekt definiert sind.
ON { METASTORE | CATALOG | SCHEMA }: Der Bereich, in dem die Richtlinie anwendet wird. DENY Policies können auf Metastore-, Katalog- oder Schema-Ebene angehängt werden, nicht auf einzelne securable Objekte. Verwenden Sie ON METASTORE, um die Richtlinie auf alle Kataloge im Metastore anzuwenden. ON METASTORE Nimmt keinen Namen an und zielt auf den Metastore ab, in dem du gerade operierst. Siehe ABAC-Richtlinien auf Metastore-Niveau (Beta).
TO principal [, ...]: Die Benutzer, Gruppen oder Dienstprinzipale, für die die Richtlinie gilt.
EXCEPT principal [, ...]: Verantwortliche, die von der Richtlinie ausgenommen sind. Metastore-Administratoren sind immer implizit ausgenommen und müssen nicht aufgeführt werden.
DENY MANAGE ACCESS CONTROL: Das Privileg zu leugnen. MANAGE ACCESS CONTROL ist das einzige unterstützte Privileg.
FOR securable_type: Der zu sichernde Typ innerhalb des Geltungsbereichs, für den die Richtlinie gilt. Eine Richtlinie gilt für einen Typ. Siehe unterstützte Typen und Privilegien.
WHEN condition: Ein tagbasierter boolescher Ausdruck, der bestimmt, für welche Securables die Richtlinie innerhalb des Geltungsbereichs gilt. Verwendet integrierte Funktionen has_tag('tag_name') und has_tag_value('tag_name', 'tag_value'). Wenn es weggelassen wird, wird standardmäßig TRUE verwendet (gilt für alle sicherbaren Objekte des Typs im Geltungsbereich). Siehe Bedingungen und integrierte Funktionen für die verfügbaren Bedingungsfunktionen.

Beispiele finden Sie in DENY Politikbeispielen.

REST API

Dieses Beispiel verweigert MANAGE ACCESS CONTROL für jede mit sensitive gekennzeichnete Tabelle in catalog_a allen Kontobenutzern, außer data_admins:

curl -X POST "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- << 'EOF'
{
  "name": "deny_manage_access_control_sensitive_tables",
  "comment": "Prevent non-admins from managing permissions on sensitive tables",
  "on_securable_type": "CATALOG",
  "on_securable_fullname": "catalog_a",
  "for_securable_type": "TABLE",
  "policy_type": "POLICY_TYPE_DENY",
  "to_principals": ["account users"],
  "except_principals": ["data_admins"],
  "deny": {
    "privileges": ["MANAGE_ACCESS_CONTROL"]
  },
  "when_condition": "has_tag('sensitive')"
}
EOF

name, on_securable_type, on_securable_fullname, for_securable_type, , policy_type, , to_principalsund deny.privileges sind erforderlich. comment, except_principals und when_condition sind optional.

Für Details zur Anfrage und Antwort siehe Create-Policy in der REST-API-Referenz.

Bearbeiten einer DENY Richtlinie

Katalog-Explorer

Verwalten Sie DENY Richtlinien auf der Registerkarte Richtlinien des übergeordneten Katalogs oder Schemas, dem sie zugeordnet sind.

Klicken Sie im Azure Databricks-Arbeitsbereich auf das Katalog.
Wählen Sie den Katalog oder das Schema aus, dem die Richtlinie angefügt ist.
Klicken Sie auf die Registerkarte Richtlinien.
Wählen Sie die Richtlinie aus, die Sie bearbeiten möchten.
Aktualisieren Sie alle Felder, die Sie ändern möchten.
Wähle Richtlinie aktualisieren aus.

SQL

Um eine DENY-Richtlinie mit SQL zu bearbeiten, führen Sie CREATE OR REPLACE POLICY mit demselben Namen und Ziel aus. Siehe Erstellen einer DENY Richtlinie.

REST API

Anders als CREATE OR REPLACE POLICY in SQL unterstützt PATCH es partielle Updates. Verwenden Sie den Abfrageparameter update_mask , um anzugeben, welche Felder geändert werden sollen. Nur diese Felder werden aktualisiert, und fehlende Felder im Anforderungskörper bleiben unverändert.

Dieses Beispiel ergänzt audit_admins die von der Police ausgeschlossenen Prinzipien:

curl -X PATCH "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies/CATALOG/catalog_a/deny_manage_access_control_sensitive_tables?update_mask=except_principals" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  --data-binary @- << 'EOF'
{
  "except_principals": ["data_admins", "audit_admins"]
}
EOF

Der Wert, den Sie senden, ersetzt die bestehende Liste statt sie hinzuzufügen, daher müssen Sie alle Prinzipien einbeziehen, die Sie ausschließen möchten, nicht nur die neuen.

Löschen einer DENY Richtlinie

Katalog-Explorer

Verwalten Sie DENY Richtlinien auf der Registerkarte Richtlinien des übergeordneten Katalogs oder Schemas, dem sie zugeordnet sind.

Klicken Sie im Azure Databricks-Arbeitsbereich auf das Katalog.
Wählen Sie den Katalog oder das Schema aus, dem die Richtlinie angefügt ist.
Klicken Sie auf die Registerkarte Richtlinien.
Wählen Sie die Richtlinie aus.
Klicken Sie auf "Richtlinie löschen".

SQL

Um eine DENY Richtlinie mit SQL zu löschen, führen Sie DROP POLICY aus:

DROP POLICY deny_manage_access_control_sensitive_tables ON CATALOG catalog_a;

REST API

curl -X DELETE "https://${DATABRICKS_HOST}/api/2.1/unity-catalog/policies/CATALOG/catalog_a/deny_manage_access_control_sensitive_tables" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}"

Richtlinien anzeigen

Verwenden Sie SHOW POLICIES, um die Richtlinien aufzulisten, die für ein Sicherungsobjekt definiert sind. Verwenden Sie SHOW EFFECTIVE POLICIES, um auch Richtlinien einzubeziehen, die aus übergeordneten Bereichen geerbt werden, z. B. Richtlinien auf Katalogebene, die ein Schema betreffen.

SHOW [EFFECTIVE] POLICIES ON { METASTORE | CATALOG | SCHEMA } securable_name

Das Ergebnis umfasst den Richtliniennamen, den Policytyp, den Katalog und das Schema der Securable, auf der jede Policy definiert ist, sowie den Typ und vollständigen Namen dieser Securable. DENY Richtlinien werden mit dem Richtlinientyp DENY zusammen mit allen Zeilenfiltern, Spaltenmasken und GRANT Richtlinien zurückgegeben, die an denselben Geltungsbereich angehängt sind. Die Spalte Table wird nur dann gefüllt, wenn eine Policy in einer Tabelle definiert ist. Dies gilt für Zeilenfilter- und Spaltenmasken-Richtlinien. Für GRANT- und DENY-Richtlinien ist die Table-Spalte NULL.

Beispiel:

SHOW EFFECTIVE POLICIES ON CATALOG catalog_a;

Policy Name                                  Policy Type  Catalog    Schema  Table  Comment                                                           on_securable_type  on_securable_fullname
-------------------------------------------  -----------  ---------  ------  -----  ----------------------------------------------------------------  -----------------  ---------------------
deny_manage_access_control_sensitive_tables  DENY         catalog_a  NULL    NULL   Prevent non-admins from managing permissions on sensitive tables  CATALOG            catalog_a

SHOW GRANTS spiegelt DENYRichtlinien nicht wider. Informationen finden Sie unter Einschränkungen.

Beschreiben einer Richtlinie

Verwenden Sie DESCRIBE POLICY, um die Details zu einer bestimmten DENY-Richtlinie anzuzeigen. Erfordert READ METADATA oder MANAGE für das sicherbare Zielobjekt oder den Besitz des Objekts.

{ DESC | DESCRIBE } POLICY policy_name ON { METASTORE | CATALOG | SCHEMA } securable_name

Das Ergebnis zeigt die Eigenschaften der Richtlinie als Schlüssel-Wert-Paare an, darunter Name, Typ des sicherbaren Objekts, Name des sicherbaren Objekts, Prinzipale, verweigerte Berechtigungen und die Bedingung WHEN.

Abfrage von Richtliniendefinitionen mit Information Schema

Sie können die Richtliniendefinitionen DENY im aktuellen Katalog mit INFORMATION_SCHEMA.ABAC_POLICY_DEFINITIONS abfragen:

SELECT *
FROM information_schema.abac_policy_definitions
WHERE policy_type = 'DENY';

Für die verfügbaren Spalten und weitere Beispiele siehe ABAC_POLICY_DEFINITIONS.

Kontingente für Richtlinien

Resource	Limit
Richtlinien pro Metastore (alle Objekte)	10.000
Richtlinien pro Metastore, direkt angehängt (Beta)	100
Richtlinien pro Katalog	100
Richtlinien pro Schema	100

GRANT und DENY Richtlinien teilen sich für jedes Objekt ein gemeinsames Kontingent. Diese Kontingente sind von den Kontingenten für Zeilenfilter- und Spaltenformatrichtlinien getrennt.

Auditprotokollierung

DENYOperationen zum Erstellen, Ändern und Löschen von Richtlinien werden unter denselben createPolicy-, deletePolicy-, getPolicy- und listPolicies-Aktionen protokolliert wie Richtlinien für Zeilenfilter und Spaltenmasken. Siehe Überwachungsprotokollierung , z. B. Überwachungsprotokollabfragen.

Bewährte Methoden

Verwenden Sie in TO und EXCEPT Gruppen, nicht einzelne Benutzer. Das Hinzufügen oder Entfernen von Benutzern aus einer Gruppe namens in einer Richtlinie ändert, für wen die Richtlinie gilt, ohne die Richtlinie zu bearbeiten.
Nehmen Sie immer eine vertrauenswürdige Gruppe von der Richtlinie aus, damit Sie nicht versehentlich alle aussperren. Dies ist besonders wichtig, wenn eine Richtlinie auf die Gruppe account users angewendet wird. Verwenden Sie die Klausel EXCEPT , um eine Gruppe zu benennen, die das Privileg behält, sodass mindestens ein Satz von Hauptverantwortlichen weiterhin Zugriff auf die betroffenen Objekte verwalten kann.
Wenden Sie Richtlinien im kleinsten Bereich an, der die Zielobjekte abdeckt. Ein breiterer Anwendungsbereich bringt nicht verwandte Wertpapiere in die Tag-Matching der Richtlinie ein und kann den Zugang verweigern, wo Sie es nicht beabsichtigt haben.

Das Verweigern von MANAGE ACCESS CONTROL blockiert nur die Fähigkeiten, die von der Eigentümerschaft und dem Privileg MANAGE gesteuert werden. Es schließt nicht jeden Pfad, über den ein Auftraggeber Daten weitergeben kann. Eine DENY Richtlinie verhindert Folgendes nicht:

Daten mit CTAS kopieren. Ein Prinzipal mit SELECT für eine Tabelle und CREATE TABLE für ein Schema (zusammen mit USE CATALOG und USE SCHEMA) kann die Daten mithilfe von CREATE TABLE ... AS SELECT in eine neue Tabelle kopieren. Um dies einzuschränken, vermeiden Sie es, CREATE TABLE zu gewähren.
Daten über eine Ansicht verfügbar machen. Ein Benutzer mit SELECT für eine Tabelle und CREATE TABLE für ein Schema (sowie USE CATALOG und USE SCHEMA) kann eine Ansicht für die Tabelle erstellen. Da eine View mit den Rechten ihres Besitzers ausgeführt wird, können die auf der View gewährten SELECT Hauptverantwortlichen die zugrunde liegenden Daten ohne direkten Zugriff auf die Quelltabelle lesen. Um dies einzuschränken, vermeiden Sie es, CREATE TABLE zu gewähren, da dies auch zur Erstellung von Ansichten berechtigt.
Anwenden oder Entfernen von verwalteten Tags. Ein Principal mit APPLY TAG auf einem Objekt und dem ASSIGN Privileg auf einem verwalteten Tag kann diesen Tag auf dem Objekt weiterhin ändern, was tagbasierte Richtlinien beeinflussen kann. Um dies einzuschränken, begrenzen Sie, wer über ASSIGN für das gesteuerte Tag und APPLY TAG für das Objekt verfügt. Siehe "Verwalten von Berechtigungen für geregelte Tags".
OpenSharing. Ein Share-Eigentümer mit dem erforderlichen Privileg auf einem Objekt kann es zu einem Share hinzufügen. Um dies einzuschränken, vermeiden Sie, CREATE SHARE für den Metastore zu gewähren.
Verkauf von Anmeldeinformation. Ein Hauptverantwortlicher kann den Zugriff auf Objekte über den Verkauf von Zugangsdaten teilen. Um dies einzuschränken, vermeiden Sie es, externen Datenzugriff im Metastore zu aktivieren und gewähren Sie nicht EXTERNAL USE SCHEMA.
Gruppenmanagement. Ein Principal mit der Verwalten-Berechtigung in einer Databricks-Gruppe (einschließlich Konto- und Arbeitsbereichsadministratoren, die sie automatisch haben) kann die Gruppenmitgliedschaft ändern, was wiederum bestimmen kann, wer den Zugriff über diese Gruppe erbt. Um dies einzuschränken, beschränke dich, wer die Berechtigung "Verwalten" für Gruppen hat.

Begrenzungen

Nur das MANAGE ACCESS CONTROL Privileg kann entzogen werden. Andere Privilegien, wie SELECT und MODIFY, werden von DENY Richtlinien nicht unterstützt.
Das Privileg MANAGE ACCESS CONTROL kann verweigert, aber nicht gewährt werden.
Eine Policy kann an einen Metastore (Beta), einen Katalog oder ein Schema angehängt werden, nicht an ein einzelnes securable Objekt.
Eine Richtlinie gilt für einen Objekttyp, der gesichert werden kann. Um die Berechtigung für mehr als einen Typ sicherbarer Objekte im selben Geltungsbereich zu verweigern, erstellen Sie für jeden Typ eine separate Richtlinie, oder erstellen Sie eine Richtlinie FOR SCHEMAS, sodass MANAGE ACCESS CONTROL für alle Objekttypen innerhalb des Schemas verweigert wird.
SHOW GRANTS, GetPermissions, und GetEffectivePermissions spiegeln keine Richtlinien wider.DENY Um die DENY geltenden Richtlinien zu sehen, verwenden Sie SHOW EFFECTIVE POLICIES sie im Katalog oder Schema des Objekts.

Weitere Informationen

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-09-17

ABAC-Richtlinien DENY (Beta)

Computeanforderungen

Was ist eine DENY Richtlinie?

Was bedeutet die Verweigerung von MANAGE ACCESS CONTROL?

DENY Politikbeispiele

Unterstützte absicherbare Typen und Privilegien

Erstellen einer DENY Richtlinie

Katalog-Explorer

SQL

REST API

Bearbeiten einer DENY Richtlinie

Katalog-Explorer

SQL

REST API

Löschen einer DENY Richtlinie

Katalog-Explorer

SQL

REST API

Richtlinien anzeigen

Beschreiben einer Richtlinie

Abfrage von Richtliniendefinitionen mit Information Schema

Kontingente für Richtlinien

Auditprotokollierung

Bewährte Methoden

Überlegungen zum Datenaustausch

Begrenzungen

Weitere Informationen

Feedback

Zusätzliche Ressourcen