ABAC (Attribute-Based Access Control, deutsch: attributbasierte Zugriffskontrolle) ist ein Modell, das Zugriffe auf Daten nicht mehr über feste Rollen erlaubt, sondern über Regeln, die Merkmale (Attribute) vergleichen: Merkmale der Person, die zugreift, Merkmale der Daten, auf die zugegriffen wird, sowie der Aktion und der Umgebung. Solche Merkmale sind etwa Tabellen-Markierungen wie pii=true (enthält personenbezogene Daten) oder region=DACH (gilt für den DACH-Raum) sowie Gruppen- oder Standort-Angaben zur Person. Das US-Standardisierungsinstitut NIST hat das Modell 2014 in der Norm SP 800-162 formal beschrieben.
Was ist ABAC?
ABAC ist ein Modell zur Rechtevergabe. Statt einer Person eine feste Rolle (etwa „Analyst") mit einem Paket an Rechten zuzuordnen, prüft eine zentrale Regel-Engine bei jeder Datenabfrage in Echtzeit, ob die Kombination aus Merkmalen zusammenpasst: die Merkmale der anfragenden Person, der angefragten Daten, der geplanten Aktion (lesen, schreiben, löschen) und des Kontexts (Uhrzeit, Netzwerk). Passt die Kombination auf eine hinterlegte Regel (Policy), wird der Zugriff erlaubt; ansonsten abgelehnt. Der Vorteil: Eine einzige Regel kann gleichzeitig für viele Tabellen gelten, sobald diese passend markiert sind.
Der Begriff wurde durch die NIST Special Publication 800-162 („Guide to Attribute Based Access Control (ABAC) Definition and Considerations", VC Hu et al., 2014) etabliert. Ältere Standardisierungen wie OASIS XACML 3.0 hatten das Grundkonzept bereits als Policy Decision Point und Policy Enforcement Point beschrieben. Motivation war die Beobachtung, dass reine Rollenmodelle bei feingranularen Regeln in eine Rollen-Explosion laufen: Für jede neue Kombination aus Sensitivität, Region, Mandant oder Klassifizierung entsteht eine eigene Rolle. ABAC verlagert diese Logik in Policies, die Attribute lesen; die Zahl der Rollen bleibt konstant.
Ein ABAC-System besteht typischerweise aus vier Kategorien von Attributen. Subjekt-Attribute beschreiben den Nutzer oder den technischen Prinzipal (Gruppen-Mitgliedschaft, Abteilung, Freigabestufe). Objekt-Attribute beschreiben die Ressource (Klassifizierung, Owner, Tag). Aktions-Attribute benennen die Operation (Lesen, Schreiben, Löschen). Kontext-Attribute beschreiben die Umgebung (Uhrzeit, Netzwerk, Anwendung). Eine Policy verknüpft diese Werte zu einer Regel, die zur Abfragezeit ausgewertet wird.
In modernen Datenplattformen läuft die Umsetzung meist über Tags oder Labels am Datenobjekt und eine zentrale Policy-Ebene. In Databricks Unity Catalog übernehmen Governed Tags an Catalog, Schema, Tabelle oder Spalte die Rolle der Objekt-Attribute; Policies auf Account- oder Catalog-Ebene formulieren die Regel und werden bei jeder Abfrage zusammen mit den RBAC-Grants ausgewertet.
Abgrenzung gegen RBAC, Row-Level Security und Dynamic Views
ABAC ersetzt RBAC nicht. Beide Modelle koexistieren: Ohne bestehendes RBAC-Recht wirkt keine ABAC-Policy, ohne passende Policy gilt das RBAC-Recht weiterhin. Beide Schichten werden bei jeder Abfrage kombiniert. Damit unterscheidet sich ABAC von Mechanismen, die tabellenspezifisch oder tabellen-lokal greifen.
| Mechanismus | Entscheidungsbasis | Reichweite |
|---|---|---|
| RBAC | Rollen- und Gruppenmitgliedschaft | Objekte, auf die die Rolle Rechte hat |
| ABAC | Attribute + Policy (Subjekt, Objekt, Aktion, Kontext) | alle Objekte mit passenden Attributen |
| Row-Level Security | SQL-Filterfunktion pro Tabelle | einzelne Tabelle |
| Column Masking | Maskierungsfunktion pro Spalte | einzelne Spalte |
| Dynamic Views | View-Definition mit current_user() | einzelne View |
RBAC ordnet Rechte über Rollen zu und ist gut prüfbar, solange die Zahl der Sonderfälle begrenzt bleibt. Kehren dieselben Bedingungen über viele Objekte wieder (PII, Region, Mandant), skaliert ABAC besser, weil eine einzige Policy viele Rollen einspart. Row-Level Security und Column Masking bleiben die richtige Wahl für tabellen- oder spaltenspezifische Logik, die sich nicht sinnvoll aus Attributen ableiten lässt. Dynamic Views sind ein älteres Muster mit derselben Grenze: Die Logik lebt am einzelnen View und nicht auf einer globalen Regel-Ebene.
Beispiel: PII-Schutz per Tag-Policy in Unity Catalog
Ein Datenteam möchte sicherstellen, dass alle Spalten, die personenbezogene Daten enthalten, nur von berechtigten Rollen im Klartext gelesen werden. Statt jede einzelne Tabelle mit einer eigenen Column Mask zu versehen, wird eine Governed-Tag-Konvention eingeführt: Jede PII-haltige Spalte trägt den Tag pii=true.
Auf Account-Ebene existiert eine ABAC-Policy, die eine Bedingung formuliert: Spalten mit pii=true sind im Klartext nur für Mitglieder der Gruppe data-compliance lesbar; für alle anderen Gruppen wird der Wert per Maskierungsfunktion auf einen Hash reduziert. Wird eine neue Tabelle angelegt und werden die relevanten Spalten korrekt getaggt, greift die Policy automatisch. Es wird kein zusätzlicher Grant, keine tabellenlokale Column Mask und keine neue View benötigt.
Der Wirkungsbereich der Policy hängt an der Tag-Qualität. Fehlt der Tag an einer neuen Spalte, greift die Policy nicht, und der Klartext ist über die bestehenden RBAC-Rechte lesbar. Deshalb setzt ABAC in der Praxis ein diszipliniertes Tag-Management voraus; Automatismen für Klassifizierung und Auditierung der Tag-Belegung sind Teil der Betriebslogik.
ABAC (Attribute-Based Access Control) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.