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 den meisten Datenbanken 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. Das NIST beschreibt das Modell in SP 800-162.

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 kann RBAC und ABAC als Sonderfälle ausdrücken und ist das übliche Muster für 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 (USENIX ATC 2019) 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, oft 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, den Aufsicht und Revision nach DORA, NIS2, SOX, HIPAA und der DSGVO verlangen; die HIPAA Security Rule etwa fordert Audit-Kontrollen, die Aktivitäten in Systemen mit elektronischen Gesundheitsdaten aufzeichnen und auswerten (45 CFR 164.312(b)). Protokolle, die sich nachträglich ändern lassen, sind ein schwacher Nachweis, deshalb sind Write-once-Speicher oder eine gleichwertige Garantie, die Manipulationen erkennbar macht die übliche Praxis.

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: die Bordmittel der Plattformen (Row Access Policies in Snowflake, Row Filters und Column Masks in Databricks Unity Catalog, Row-Level Security in BigQuery) und eigenständige Policy-Engines. Kataloge wie Dawiso stehen daneben: Sie halten die Klassifizierung und die Verantwortung fest, auf die Richtlinien verweisen, während die Durchsetzung in der Datenplattform bleibt.

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 technische und organisatorische Maßnahmen für ein dem Risiko angemessenes Schutzniveau, darunter die dauerhafte Vertraulichkeit der Verarbeitungssysteme (Art. 32 Abs. 1 lit. b DSGVO), und Schritte, die sicherstellen, dass Personen mit Zugang zu personenbezogenen Daten diese nur auf Anweisung des Verantwortlichen verarbeiten (Art. 32 Abs. 4 DSGVO). Feinkörnige Zugriffskontrolle ist einer der direktesten Wege, beides zu erfüllen.
• Art. 21 Abs. 2 lit. i NIS2 nennt Konzepte für die Zugriffskontrolle, neben der Sicherheit des Personals und dem Management von Anlagen, unter den zehn Mindestmaßnahmen des Cybersicherheits-Risikomanagements für wesentliche und wichtige Einrichtungen. Die Aufsichtsbehörden können prüfen, wie Zugriff erteilt, entzogen und überprüft wird.
• Art. 9 Abs. 4 lit. c DORA verlangt von Finanzunternehmen Strategien, die den physischen oder logischen Zugang zu Informations- und IKT-Assets auf das beschränken, was für legitime und genehmigte Funktionen nötig ist, samt Kontrollen für die Verwaltung der Zugriffsrechte.
• SOX verlangt in Section 404, dass das Management die interne Kontrolle über die Finanzberichterstattung bewertet, und die Abschlussprüfung testet dabei üblicherweise die Funktionstrennung und den Zugriff auf Finanzsysteme.
• Der EU AI Act (KI-Verordnung) verlangt, dass Hochrisiko-KI-Systeme gegen Versuche unbefugter Dritter widerstandsfähig sind, ihre Verwendung, Ausgaben oder Leistung zu verändern, einschließlich Maßnahmen gegen die Vergiftung von Trainingsdaten (Art. 15 Abs. 5). Zugriffskontrolle über Trainingsdaten und Eingaben ist ein praktischer Weg, das zu erfüllen.

Das gemeinsame Thema: Diese Regeln verlangen Kontrollen, die sich nachweisen lassen. Eine Zugriffskontrolle, die nur in der Anwendung existiert, ist schwer zu belegen; eine Richtlinie, die gegen die Daten formuliert, in der Datenplattform durchgesetzt und von einem Audit-Trail begleitet wird, durch den sich eine prüfende Person bewegen kann, ist weit leichter zu verteidigen. 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.

Quellen

• NIST - SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• Google Research - Zanzibar: Google's Consistent, Global Authorization System
• Snowflake - Understanding row access policies
• Databricks - Row filters and column masks
• Google Cloud - Introduction to BigQuery row-level security
• eCFR - 45 CFR 164.312, Technical safeguards
• DSGVO - Article 32, Security of processing
• EUR-Lex - Directive (EU) 2022/2555 (NIS2)
• EUR-Lex - Regulation (EU) 2022/2554 (DORA)
• EUR-Lex - Regulation (EU) 2024/1689, Artificial Intelligence Act
• Dawiso Help - PII Level and Confidentiality