Access Control (Zugriffskontrolle)

Access Control (Zugriffskontrolle) bezeichnet die Gesamtheit organisatorischer und technischer Mechanismen, die regeln, welcher Prinzipal (Nutzer, Gruppe, Service) auf welche Ressource welche Operation ausführen darf. Die Umsetzung folgt der Kette Authentifizierung, Autorisierung und Audit und stützt sich auf Modelle wie RBAC, ABAC, ACL oder PBAC.

Was ist Access Control?

Access Control ist der Sammelbegriff für alle Kontrollen, mit denen ein System entscheidet, ob ein Prinzipal eine bestimmte Operation auf einer Ressource ausführen darf. Der Begriff umfasst drei aufeinanderfolgende Schritte: Authentifizierung stellt die Identität des Prinzipals fest (Passwort, Multifaktor, Zertifikat, Token). Autorisierung bewertet, ob diese Identität die angefragte Operation ausführen darf. Audit hält fest, welche Anfragen mit welchem Ergebnis passiert sind, damit Entscheidungen prüfbar bleiben.

Die Autorisierung wird über Modelle beschrieben, die sich in ihrer Entscheidungsbasis unterscheiden. RBAC (Role-Based Access Control) bindet Rechte an Rollen und ist im Standard ANSI/INCITS 359 formalisiert. ABAC (Attribute-Based Access Control) berechnet Zugriffe über Attribute des Subjekts, des Objekts, der Aktion und des Kontexts und ist in NIST SP 800-162 beschrieben. ACL (Access Control List) ordnet Rechte direkt Nutzern pro Ressource zu. PBAC (Policy-Based Access Control) ist der Oberbegriff für policy-getriebene Modelle; ABAC ist eine Ausprägung davon. Auf derselben Plattform koexistieren die Modelle häufig; eine ABAC-Policy greift meist erst, wenn ein RBAC-Basisrecht vorliegt.

Access Control folgt drei modell-unabhängigen Prinzipien: Least Privilege (nur die Rechte, die eine Aufgabe verlangt), Separation of Duties (kritische Prozesse werden nicht von einer einzelnen Identität allein ausgeführt) und Need-to-Know (Zugriff nur bei fachlichem Bedarf). Neuere Rahmenwerke wie [Zero Trust](https://csrc.nist.gov/pubs/sp/800/207/final) (NIST SP 800-207) verlangen zusätzlich eine kontinuierliche, kontextabhängige Zugriffs-Entscheidung anstelle eines einmalig geprüften Netzwerk-Perimeters. In Datenplattformen läuft Access Control typischerweise über eine feste Kette: Ein Identity Provider (Entra ID, Okta, Google Workspace) hält den führenden Nutzerbestand; über [SCIM](/insights/glossar/scim/) werden Nutzer und Gruppen provisioniert; ein Katalog vergibt Grants an diese Gruppen (Unity Catalog per GRANT/REVOKE auf Katalog-, Schema-, Tabellen-, View-, Volume- oder Function-Ebene); Row-Level Security, Column Masking und ABAC-Policies wirken feingranular darüber; ein Audit-Log wie system.access.audit protokolliert jede Zugriffs-Entscheidung.

Abgrenzung zu Authentifizierung, RBAC, Data Governance und Encryption

Access Control wird häufig mit benachbarten Konzepten vermischt, die entweder eine Vorstufe, eine spezifische Ausprägung oder eine komplementäre Schicht darstellen.

Access Control gegenüber Authentifizierung: Authentifizierung beantwortet die Frage „Wer ist das?" über Passwort, MFA, Zertifikat oder Token. Access Control setzt darauf auf und beantwortet die Frage „Was darf diese Identität?".

Access Control gegenüber RBAC: RBAC ist ein konkretes Modell zur Umsetzung der Autorisierungs-Schicht innerhalb von Access Control. Der Oberbegriff umfasst zusätzlich ABAC, ACL und PBAC sowie die vor- und nachgelagerten Schritte Authentifizierung und Audit.

Access Control gegenüber [Data Governance](/insights/glossar/data-governance/): Data Governance ist der übergeordnete Rahmen mit Ownership, Klassifizierung, Qualitätsregeln und Prozessen. Access Control ist einer der operativen Bausteine dieses Rahmens: die technische Durchsetzung der Zugriffsregeln.

Access Control gegenüber Encryption: Verschlüsselung schützt Daten in Ruhe und beim Transport gegen unautorisierten Zugriff auf Speichermedium oder Leitung. Sie regelt aber keine Zugriffs-Entscheidung über die entschlüsselten Daten selbst. Access Control und Encryption sind komplementäre Schichten.

Beispiel: Access-Control-Kette in Databricks Unity Catalog

Ein Datenteam betreibt einen Databricks-Lakehouse mit Unity Catalog. Die Nutzer- und Gruppen-Objekte liegen in Entra ID; über [SCIM](/insights/glossar/scim/) werden die Gruppen grp-data-analyst, grp-data-engineer und grp-data-compliance in den Databricks Account synchronisiert (Provisioning).

Beim Login authentifiziert Entra ID den Nutzer per SAML oder OIDC gegenüber Databricks (Authentifizierung). Auf Katalog-Ebene sind die Grants an die Gruppen vergeben: GRANT SELECT ON SCHEMA analytics.sales TO grp-data-analyst` (Autorisierung per [RBAC](/insights/glossar/rbac/)). Eine [ABAC](/insights/glossar/abac/)-Policy sorgt zusätzlich dafür, dass Spalten mit dem Governed Tag pii=true nur für Mitglieder von grp-data-compliance` im Klartext lesbar sind; für alle anderen greift eine Masking-Funktion. Eine [Row-Level-Security-Policy](/insights/glossar/row-level-security/) filtert im Vertriebs-Datensatz die Zeilen so, dass jede Region ausschließlich die eigenen Umsätze sieht.

Jede Zugriffs-Entscheidung wird im Audit-Log protokolliert (system.access.audit). Für ein Access Review beantwortet eine Abfrage auf dieses Log und die Grants-Views, welche Gruppen Rechte auf welche Objekte haben, wer Mitglied dieser Gruppen ist und welche Abfragen tatsächlich ausgeführt wurden. Die vollständige Access-Control-Kette umfasst in diesem Beispiel Provisioning (SCIM), Authentifizierung (SAML/OIDC), Autorisierung (RBAC + ABAC + Row-Level Security + Column Masking) und Audit.