Was ist Datenzugriffsverwaltung?

Datenzugriffsverwaltung (Data Access Management) ist die Disziplin, zu steuern, wer und was in einer Organisation Daten lesen, ändern, weitergeben und mit ihnen handeln darf. Sie ist die Betriebsschicht, die fachliche und regulatorische Vorgaben („Nur die Personalabteilung sieht Vergütungsdaten“, „Zugriff auf PII verlangt einen dokumentierten Zweck“, „Produktionsdaten sind außerhalb des Data Engineering nur lesbar“) in durchgesetzte Kontrollen in den Systemen übersetzt, in denen die Daten tatsächlich liegen.

Die Disziplin ist aus dem Zusammenlaufen dreier älterer Felder entstanden: Identitäts- und Zugriffsverwaltung (wer ist angemeldet), Datenbanksicherheit (was darf jemand nach der Anmeldung tun) und Data Governance (welche fachlichen Regeln gelten für welche Datenkategorien). Heraus kommt eine Schicht zwischen den Identitätsanbietern und der Datenplattform, die Richtlinien anwendet und dabei sowohl die Attribute der anfragenden Seite als auch die Klassifizierung der Daten kennt, und die jene Nachweise erzeugt, die Aufsicht und Revision zunehmend einsehen wollen.

Datenzugriffsverwaltung, definiert

Datenzugriffsverwaltung ist die Gesamtheit der Richtlinien, Mechanismen und Abläufe, die festlegen, welche Subjekte (Nutzer, Dienste, Agenten) welche Handlungen (lesen, schreiben, löschen, teilen) an welchen Daten (Tabellen, Spalten, Zeilen, Dateien, Dokumente) unter welchen Bedingungen (Zweck, Ort, Zeit, Gerätezustand) ausführen dürfen. Die Disziplin liegt im Schnittpunkt dreier Anliegen:

• Identität: verlässlich zu wissen, wer den Zugriff verlangt, und zunehmend auch, welcher KI-Agent im Auftrag welches Nutzers handelt.
• Richtlinie zur Berechtigung: fachliche und regulatorische Regeln in maschinell auswertbare Aussagen darüber zu übersetzen, wer was darf.
• Durchsetzung: die Richtlinie auf der Datenebene anzuwenden, mit Protokollen, die belegen, was erlaubt und was verweigert wurde.

Gut gemacht ist Datenzugriffsverwaltung unsichtbar: Nutzer erreichen die Daten, auf die sie Anspruch haben, ohne Reibung, und die anderen erreichen sie nicht. Schlecht gemacht erzeugt sie zwei Fehlerbilder, die oft nebeneinander bestehen: Berechtigte werden von Daten abgeschnitten, die sie brauchen (die Ticketschlange wächst, Leute verschicken Bildschirmfotos, Schattenauswertungen vermehren sich), und unbefugte Zugriffe gelingen still (der Audit-Trail findet sie erst nach einem Vorfall).

Modelle: RBAC, ABAC, PBAC, ReBAC

Vier Zugriffsmodelle kehren in der modernen Datenzugriffsverwaltung wieder. Echte Systeme kombinieren sie; reine Umsetzungen eines einzigen Modells überleben den Kontakt mit der Komplexität eines Unternehmens selten.

RBAC (rollenbasierte Zugriffskontrolle)

Berechtigungen hängen an Rollen, Nutzer hängen an Rollen. Einfach, gut verstanden, von jeder Datenbank unterstützt. Es funktioniert gut, wenn sich die Nutzerschaft nach Tätigkeit schneiden lässt und die Anforderungen an den Zugriff stabil sind. Es bricht zusammen, wenn eine Organisation Hunderte überlappender Rollen hat, Beschäftigte zwischen Teams wechseln und aus „Das sehen Sie, wenn Sie in der Rolle analytics_us sind“ ein Wartungsalbtraum mit Tausenden Rollenzuweisungen wird.

ABAC (attributbasierte Zugriffskontrolle)

Entscheidungen über den Zugriff stützen sich auf Attribute der Person (Abteilung, Ort, Freigabestufe), der Daten (Klassifizierung, Verantwortung, Schutzbedarf), der Handlung (lesen gegenüber exportieren) und der Umgebung (Zeit, Netz, Gerät). Die Richtlinie steht als Regel da: „Nutzer in der EU dürfen EU-klassifizierte Daten lesen; Nutzer außerhalb der EU nicht, außer mit ausdrücklicher Zweckfreigabe.“ Das skaliert für große, attributreiche Organisationen besser als RBAC.

PBAC (richtlinienbasierte Zugriffskontrolle)

Das allgemeinste Modell: Richtlinien in einer eigenen Sprache (OPA Rego, Cedar, XACML), die beliebige Bedingungen ausdrücken kann. Die Richtlinien liegen in einer zentralen Engine, getrennt von den Anwendungen, die sie nutzen. PBAC umfasst RBAC und ABAC als Sonderfälle und ist das vorherrschende Muster für moderne Umsetzungen von Policy-as-Code.

ReBAC (beziehungsbasierte Zugriffskontrolle)

Zugriff nach Beziehungen in einem Graphen: „Sie sehen die Daten dieses Kunden, wenn Sie im Deal-Team seines Mutterkonzerns sind.“ Googles Zanzibar-Papier hat ReBAC bekannt gemacht; moderne Umsetzungen (SpiceDB, OpenFGA) liefern skalierbare Berechtigung auf Graphbasis. Am nützlichsten dort, wo der Zugriff an der sozialen oder organisatorischen Struktur hängt statt an festen Rollen.

Die Bausteine

Eine reife Umsetzung der Datenzugriffsverwaltung hat sechs wiederkehrende Bausteine.

1. Identität anbinden

Föderierte Identität (SSO) für Menschen, Dienstkonten für Systeme und zunehmend delegierte Token für KI-Agenten, die im Auftrag von Personen handeln. Der Identitätsanbieter, also Okta, Microsoft Entra ID oder Google Workspace, ist die vorgelagerte maßgebliche Quelle. Mehrfaktor-Anmeldung für sensible Systeme. Bereitstellung genau zum Zeitpunkt des Bedarfs für kurzlebige Zugriffe.

2. Richtlinien nach Klassifizierung

Kennzeichen aus der Klassifizierung (PII, finanziell, vertraulich, öffentlich) steuern die Richtlinie. „Alle im Finanzbereich dürfen Hauptbuchdaten lesen“ funktioniert nur, wenn „Hauptbuchdaten“ verlässlich gekennzeichnet sind. Das reife Muster lautet: Die Klassifizierung wird auf der Datenebene gesetzt, Richtlinien verweisen auf Klassifizierungen, und die Richtlinien wandern mit den Daten durch die Plattform.

3. Maskierung und Tokenisierung

Sensible Felder werden umgeformt, bevor sie die konsumierende Seite erreichen. Die dynamische Datenmaskierung schwärzt oder hasht Werte für alle, die sie nicht sehen dürfen, oft auf Spaltenebene. Die Tokenisierung ersetzt sensible Werte durch umkehrbare Token, wo Konsistenz gebraucht wird, der Rohwert aber nicht. Maskierung und Tokenisierung begrenzen den Schaden: Ein übernommenes Analystenkonto kann keine Daten ausleiten, die es nie zu sehen bekam.

4. Abläufe für die Freigabe

Anfragen nach Zugriff laufen durch eine Freigabe, in der Regel durch den Data Owner, bei sensiblen Klassifizierungen mit weiteren Freigebenden. Moderne Werkzeuge für solche Abläufe binden den Katalog ein, sodass die Anfrage, die Daten, der genannte Zweck und die Entscheidung in einem prüfbaren Vorgang landen.

5. Regelmäßige Prüfung der Zugriffe

Einmal erteilter Zugriff verliert an Berechtigung. Prüfungen, üblicherweise quartalsweise oder halbjährlich, bestätigen, dass jede erteilte Berechtigung noch angemessen ist. Sie holen ruhende Zugriffe ans Licht (Beschäftigte, die die Rolle gewechselt und alte Rechte behalten haben) und überhöhte Zugriffe (Berechtigungen, die sich über Jahre angesammelt haben).

6. Unveränderlicher Audit-Trail

Jede Erteilung, jeder Zugriff, jede Ablehnung und jede Änderung an einer Richtlinie wird unveränderlich protokolliert. Der Audit-Trail ist der Nachweis, der Prüfungen nach DORA, NIS2, SOX, HIPAA und der DSGVO standhält. Protokolle ohne Unveränderlichkeit, also ohne Write-once-Speicher oder gleichwertige Zusagen, bestehen die Prüfung nicht.

Datenzugriffsverwaltung gegenüber IAM und IGA

Drei eng verwandte Disziplinen werden oft in einen Topf geworfen. Die Unterschiede zählen, wenn Werkzeuge gekauft und Teams zugeschnitten werden.

• IAM (Identity and Access Management): die breite Disziplin für Anmeldung und Berechtigung über Anwendungen und Infrastruktur hinweg. Werkzeuge: Okta, Microsoft Entra, Ping. Themen: SSO, Mehrfaktor-Anmeldung, Lebenszyklus, Passwortregeln, Zugang zu Anwendungen.
• IGA (Identity Governance and Administration): die Governance-Schicht über IAM. Sie deckt die Verwaltung von Berechtigungen, Zugriffsbescheinigungen, Funktionstrennung und die Abläufe bei Eintritt, Wechsel und Austritt ab. Werkzeuge: SailPoint, Saviynt, Microsoft Entra ID Governance. Thema: wer welchen Zugriff über alle Systeme hinweg hat und ob er noch angemessen ist.
• Datenzugriffsverwaltung: eigens die Datenebene. Wie eine Zugriffsrichtlinie innerhalb der Datenplattform ausgedrückt und durchgesetzt wird, im Warehouse, im Lakehouse, im Lake und in den operativen Speichern. Werkzeuge: Immuta, Privacera, die Bordmittel der Warehouses (Row-Access-Policies in Snowflake, Databricks Unity Catalog, Row-Level Security in BigQuery) und zunehmend Kataloge wie Dawiso, die Richtlinien über Datensysteme hinweg orchestrieren.

Die Datenzugriffsverwaltung sitzt auf IAM auf (sie bezieht den Kontext der Identität von dort) und liegt im Geltungsbereich von IGA (sie ist eine der Zugriffsflächen, die IGA steuert). Dort liegt auch der größte Teil der betrieblichen Komplexität, denn Daten sind feinkörnig (Spalten, Zeilen, Dateien), klassifiziert und von vielen Systemen genutzt, während der Zugang zu einer Anwendung vergleichsweise grob ist: Man hat ihn, oder man hat ihn nicht.

Einführung im großen Maßstab

Die Datenzugriffsverwaltung über Hunderte Datenbestände und Tausende Nutzer einzuführen verlangt eine bewusste Reihenfolge.

1. Zuerst katalogisieren und klassifizieren. Eine Richtlinie, die auf Klassifizierungen verweist, versagt an dem Tag, an dem die Klassifizierungen falsch sind. Bringen Sie Katalog und Klassifizierung so weit, dass Sie eine Richtlinie darauf wetten würden, bevor Sie die Richtlinie entwerfen.
2. Verantwortung zuweisen. Jeder Datenbestand braucht einen Data Owner, der den Zugriff freigibt. Ohne Verantwortliche landen Anfragen bei „dem Datenteam“, und die Richtlinie verkommt zu „im Zweifel verweigern“ oder „im Zweifel erlauben“, was beides vorhersehbar schiefgeht.
3. Das Modell wählen, das zur Organisation passt. Kleine, stabile Organisationen: RBAC reicht. Große oder attributreiche Organisationen: ABAC oder PBAC. Organisationen, deren Zugriffsmuster der Aufbauorganisation folgen: ReBAC bringt Zusatznutzen.
4. Richtlinien an einem Ort ausdrücken. Die Richtlinie liegt an einer Stelle: in einer Policy-Engine, in einem richtlinienbewussten Katalog, in einer einheitlichen Governance-Schicht. Vermeiden Sie das Fehlerbild, dieselbe Richtlinie in jedem Datensystem erneut umzusetzen, wo sie binnen Monaten auseinanderdriftet.
5. Auf der Datenebene durchsetzen. Zugriffskontrolle in der Anwendung lässt sich umgehen. Durchgesetzt werden muss sie in der Speicher- und Abfrageschicht der Datenplattform: Row-Level Security, Maskierung auf Spaltenebene, Zugriff über Sichten, Bordmittel in Unity Catalog oder Snowflake. Das ist die eigentliche Kontrolle.
6. Messen und prüfen. Die Protokolle speisen Dashboards zur Überwachung. Prüfungen der Zugriffe laufen in einem Takt. Anomalieerkennung markiert ungewöhnliche Zugriffsmuster. Die Daten sind da; die Disziplin besteht darin, sie zu nutzen.

Anbindung an die Governance

Datenzugriffsverwaltung ist ebenso sehr eine Disziplin der Governance wie eine der Sicherheit. Und sie ist zunehmend eine regulatorische Pflicht.

• Art. 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen, damit der Zugriff auf personenbezogene Daten auf befugte Zwecke beschränkt bleibt. Damit wird feinkörnige Zugriffskontrolle zur rechtlichen Erwartung an jede Organisation, die personenbezogene Daten in der EU verarbeitet.
• Art. 21 Abs. 2 lit. i NIS2 verlangt Zugriffskontrolle als eine der zehn Mindestmaßnahmen für Cybersicherheit. Die Revision wird prüfen, wie Zugriff erteilt, entzogen und überprüft wird.
• Art. 9 DORA verlangt Vertraulichkeitskontrollen für kritische Funktionen, die auf IKT gestützt sind. Die Zugriffsverwaltung ist die betriebliche Antwort darauf.
• SOX verlangt Funktionstrennung rund um Finanzdaten; die Datenzugriffsverwaltung setzt sie durch.
• Der EU AI Act (KI-Verordnung) verlangt implizit Zugriffskontrollen über Trainingsdaten und Eingaben von KI-Systemen mit hohem Risiko.

Das gemeinsame Thema: Die Aufsicht akzeptiert „Der Zugriff wird in der Anwendung gesteuert“ nicht mehr als Nachweis. Sie will sehen, dass die Richtlinie gegen die Daten formuliert, in der Datenplattform durchgesetzt und von einem Audit-Trail begleitet wird, durch den sich eine prüfende Person bewegen kann. Die Datenzugriffsverwaltung erzeugt genau diesen Nachweis. Sie einmal richtig zu bauen ist das, was die regulatorische Last tragbar macht.

Fazit

Die Datenzugriffsverwaltung ist die Betriebsschicht, auf der Data Governance zu durchgesetztem Verhalten wird. Das reife Muster verbindet ein klares Zugriffsmodell (RBAC plus ABAC plus Policy-as-Code, zunehmend mit Blick auf Beziehungen), ein Fundament aus genauer Klassifizierung und klarer Verantwortung, Maskierung und Tokenisierung für sensible Felder, an den Katalog gebundene Freigabeabläufe, regelmäßige Prüfungen und einen unveränderlichen Audit-Trail. Am meisten zahlen sich die unspektakulären Investitionen aus: die Klassifizierung genau zu halten, die Verantwortung aktuell zu halten, die Richtlinien an einem Ort zu halten. Die aufregenden Teile, Zero Trust, Policy-as-Code, attributreiche Regeln, liefern erst dann Wert, wenn dieses Fundament trägt.