Permissions: Definition, Grants und Abgrenzung zu RBAC

Permissions (Berechtigungen) sind konkrete Rechte, die einem Prinzipal (Nutzer, Gruppe oder technischer Dienst) auf einer Ressource gewährt werden, zum Beispiel SELECT (lesen), MODIFY (ändern), USE (verwenden), EXECUTE (ausführen) oder MANAGE (verwalten). In Databricks Unity Catalog werden sie per GRANT/REVOKE-SQL oder über die REST-API auf Objekten wie Katalog, Schema, Tabelle, Volume oder Modell vergeben.

Was sind Permissions?

Eine Permission ist die kleinste Einheit einer Zugriffs-Entscheidung: die Kombination aus einer Aktion (was darf getan werden), einer Ressource (worauf gilt das Recht) und einem Prinzipal (wem gilt das Recht). Ein Beispiel: SELECT auf die Tabelle analytics.sales.orders für die Gruppe grp-data-analyst. Das Recht existiert immer als konkrete Zuordnung dieser drei Bestandteile.

Die Aktion (auch Privilege genannt) benennt die erlaubte Operation. Typische Werte in Datenplattformen sind SELECT für Lesezugriff, MODIFY für schreibende Änderungen, USE CATALOG und USE SCHEMA für die Navigation, EXECUTE für Funktionen, CREATE TABLE für Objekt-Anlage und MANAGE für die Verwaltung inklusive Weitergabe von Rechten. Die Ressource beschreibt das Objekt, auf das die Aktion wirkt: Metastore, Katalog, Schema, Tabelle, View, Volume, Function oder Registered Model. Der Prinzipal ist die Identität, die das Recht ausübt: Nutzer, Gruppe oder Service Principal.

Vergeben werden Permissions in Databricks Unity Catalog per SQL-Kommando GRANT <privilege> ON <object> TO <principal> und entzogen per REVOKE. Dieselbe Wirkung erreicht die Unity-Catalog-REST-API über den Endpoint PATCH /api/2.1/unity-catalog/permissions/<securable_type>/<full_name>. Die aktuellen Grants sind in der System-Sicht system.information_schema.privileges einsehbar.

Permissions folgen der Katalog-Hierarchie und werden entlang dieser Kette vererbt: Ein Grant auf Katalog-Ebene wirkt für alle Schemas darunter, ein Grant auf Schema-Ebene für alle Tabellen im Schema. Feingranulare Ergänzungen wie [Row-Level Security](/insights/glossar/row-level-security/) und [Column Masking](/insights/glossar/column-masking/) schränken die Wirkung auf Datensatz- und Spaltenebene weiter ein. Permissions sind zugleich die Grundlage der gängigen Autorisierungs-Modelle: [RBAC](/insights/glossar/rbac/) bündelt sie in Rollen (typischerweise als Gruppe im Identity Provider), [ABAC](/insights/glossar/abac/) berechnet zur Abfragezeit über Policies, ob eine Permission wirken darf.

Abgrenzung zu Rollen, Access Control, Ownership und Vererbung

Permissions werden häufig mit den Konzepten verwechselt, die auf ihnen aufsetzen oder sie organisieren. Die Modelle unterscheiden sich in ihrer Rolle innerhalb der Autorisierungs-Schicht.

Begriff	Verhältnis zu Permissions
Rollen / RBAC	Bündeln Permissions und weisen sie an Gruppen zu; Rolle = Menge von Permissions plus Zuweisung
Access Control	Oberbegriff für den Gesamtprozess (Authentifizierung, Autorisierung, Audit); Permissions sind ein Baustein
Ownership	Spezielle Meta-Permission, die die Verwaltung eines Objekts erlaubt (Grant vergeben, Objekt löschen)
Berechtigungs-Vererbung	Mechanismus, wie Permissions entlang der Katalog-Hierarchie weiterreichen

Permissions gegenüber Rollen und RBAC: Eine Rolle ist ein Bündel von Permissions plus die Zuweisung dieses Bündels an einen Prinzipal. Permissions sind die atomaren Rechte darunter. Ohne die Rollen-Ebene würden Permissions einzeln an Nutzer vergeben (ACL-Muster), was bei jeder Team-Änderung Nachpflege an vielen Objekten erzwingt.

Permissions gegenüber Access Control: Access Control ist der Oberbegriff für die gesamte Kette aus Authentifizierung, Autorisierung und Audit. Permissions sind der konkrete Baustein innerhalb der Autorisierungs-Schicht; der Bezug ist Teil-Ganzes.

Permissions gegenüber Ownership: Ownership ist eine spezielle Meta-Permission an einem Objekt. Der Owner darf Grants vergeben und entziehen, den Owner wechseln (ALTER … OWNER TO) und das Objekt löschen. Ownership ersetzt keine reguläre MANAGE-Vergabe an eine Gruppe, wenn mehrere Prinzipale das Objekt verwalten sollen.

Permissions gegenüber Berechtigungs-Vererbung: Vererbung ist der Mechanismus, mit dem Permissions entlang der Katalog-Hierarchie weitergereicht werden. Ein Grant auf Schema-Ebene wirkt auf alle Tabellen darunter, sofern kein gezielter Grant auf tieferer Ebene das Verhalten überschreibt. Die Vererbung ist damit kein eigenes Recht, sondern die Regel, wie ein Recht seine Reichweite ausrollt.

Beispiel: Analytics-Katalog mit drei Permissions

Ein Datenteam gibt der Gruppe grp-data-analyst Lesezugriff auf alle Vertriebstabellen im Analytics-Katalog. Statt für jede Tabelle einen eigenen Grant zu setzen, werden drei Permissions auf Schema-Ebene erteilt:

sql

GRANT USE CATALOG ON CATALOG analytics TO `grp-data-analyst`;
GRANT USE SCHEMA ON SCHEMA analytics.sales TO `grp-data-analyst`;
GRANT SELECT ON SCHEMA analytics.sales TO `grp-data-analyst`;

Die Gruppe grp-data-analyst wird per [SCIM](/insights/glossar/scim/) aus Entra ID synchronisiert. Ein Mitglied dieser Gruppe darf ab dem Zeitpunkt jede bestehende und jede künftig angelegte Tabelle in analytics.sales lesen; die Permission wirkt über die Schema-Vererbung. Kommt eine neue Analystin ins Team, reicht ihre Aufnahme in grp-data-analyst im Identity Provider; die Grants im Katalog bleiben unverändert.

Für ein Access Review beantwortet eine Abfrage auf system.information_schema.privileges, welche Prinzipale welche Permissions auf welchen Objekten halten. Die Zahl der Zeilen skaliert mit der Zahl der Gruppen und Objekt-Ebenen, nicht mit der Zahl der einzelnen Tabellen unter einem Schema.