Konzeptkarte

Data Access Controls (DAC)

Stand 2026-07-24T14:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist Data Access Controls (DAC)?

Eine DAC-Regel auf Catalog-Ebene steuert alle Konsumenten gleichzeitig – SAC, Joule, Delta Sharing, OData, JDBC – und ersetzt die drei oder vier separaten Row-Security-Richtlinien, die ein generischer Warehouse-Stack benötigen würde.

Data Access Controls, DAC, sind SAP Datasphere's Sicherheitsmechanismus auf Catalog-Ebene, um einzuschränken, welche Zeilen und welche Spalten ein bestimmter Nutzer sehen darf. Das entscheidende Merkmal ist nicht die Prädikatlogik selbst — Row-Level-Security gibt es in jeder ausgereiften Datenbank —, sondern wo die Regel lebt: Eine DAC-Regel wird einmal am Catalog-Objekt angebracht, und jeder Konsument, der durch dieses Objekt liest, erbt automatisch dieselbe Einschränkung. SAC-Stories, Joule-Agenten, Delta-Sharing-Partner, OData-Clients, JDBC-Verbindungen — eine Regel, überall identisch durchgesetzt, ohne separate Policy, die pro Werkzeug gepflegt werden muss.

Warum das mehr bedeutet, als es klingt

In einem generischen Stack aus Warehouse, BI-Tool und API-Gateway bedeutet dieselbe Row-Level-Garantie zu erreichen typischerweise, die Filterlogik drei- oder viermal zu schreiben: einmal im nativen Row-Security-Feature des Warehouses, einmal in der Transformationsschicht, einmal im eigenen Sicherheitsmodell des BI-Tools, und noch einmal in welchem Dienst auch immer die Daten nach außen exponiert. Jede Duplikation ist eine Stelle, an der die Logik auseinanderdriften kann — jemand aktualisiert die BI-Tool-Regel nach einer Reorganisation und vergisst die warehouse-seitige Regel, und über einen gewissen Zeitraum sieht ein Nutzer Daten, die er nicht sehen sollte. DAC reduziert diese Angriffsfläche auf eine Stelle. Das ist das Argument, mit dem Analytics-Verantwortliche einem skeptischen Governance- oder Security-Team gegenübertreten: weniger Stellen, an denen sich eine Sicherheitslücke verstecken kann, und ein einziger Ort, um Compliance während eines Audits nachzuweisen.

Warum es zählt

Ein einziges Prädikat, angewendet auf der niedrigsten exponierten View-Schicht, erreicht jeden nachgelagerten Konsumenten und eliminiert Policy-Drift über BI-Tool, Warehouse und API-Gateway hinweg.
Das Region-/Geografie-Filtermuster dient zugleich als DSGVO-Compliance-Mechanismus — eine Regel bedient sowohl das Vertriebsreporting als auch die regulatorische Pflicht.
DAC-Regeln sind benannte, versionierte, code-review-fähige Catalog-Objekte — Sicherheits-Policy wird zu einem auditierbaren Artefakt statt verstreuter, stillschweigend gepflegter Konfiguration über mehrere Werkzeuge hinweg.

Kernpunkte

Row- und Spaltensicherheit auf Catalog-Ebene; eine Regel erreicht SAC + Joule + Delta Share + OData + JDBC.
Prädikat referenziert Session-Attribute ($$session_user) und Spalten des Zielobjekts.
An der niedrigsten exponierten View binden — niemals nur am Analytic Model.
Fünf kanonische Muster: Region · Kostenstelle · Segment · Zeitfenster · PII-Spaltenmaskierung.
Autorisierungs-Mapping-Tabelle im Besitz von HR/IAM, stündlich aktualisiert, an IdP-Claims angebunden.
Push-down bleibt erhalten: Query-Rewrite fügt eine WHERE-Klausel hinzu, HANA führt sie als Standardplan aus.
DAC vs. SAC-Rollen: DAC = Zeilen-Scope (werkzeugübergreifend); SAC-Rollen = nur Objektzugriff.
Overhead 3–5 ms pro Regel pro Abfrage; ab ~10 gestapelten Regeln über eine zusammengesetzte Mapping-Tabelle konsolidieren.
Data Access Controls (DAC) ist erst dann beherrscht, wenn es eine konkret benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Werkzeug demonstrieren.

Begriffe auf dieser Seite

DAC (Data Access Control): Sicherheitsregel für Zeilen/Spalten auf Catalog-Ebene, angewendet zur Query-Rewrite-Zeit.
DAC predicate: Boolescher SQL-Ausdruck, der entscheidet, ob eine Zeile den Sicherheitsfilter für den aufrufenden Nutzer passiert.
Session attribute: Nutzerspezifischer Wert, aufgelöst aus IdP-Claims, Gruppenmitgliedschaften oder Lookup-Tabellen. Referenziert als $$session_user.X.
Authorization mapping table: Vom Kunden verwaltete Tabelle, die USER_ID auf erlaubte Scopes (Region, Kostenstelle, Segment) abbildet. Wird von DAC-Prädikaten verbunden.
Column masking: DAC-Variante, die eine feste Zeichenkette (z. B. „***MASKED***") statt des echten Spaltenwerts zurückgibt, wenn die Regel greift.
Cross-tool reach: Das entscheidende Merkmal von DAC — eine Regel an einem Catalog-Objekt gilt für jeden Konsumenten, der das Objekt liest, nicht nur für ein einzelnes BI-Tool.
Query-rewrite: Optimizer-Phase in Datasphere, in der das SQL des Nutzers in zusätzliche WHERE-/SELECT-Klauseln eingebettet wird, um DAC durchzusetzen. Push-down bleibt erhalten.
ABAC: Attribute-Based Access Control — Preview-Feature, tag-gesteuerte Policy-Vererbung aus der Catalog-Hierarchie. GA-Ziel H2 2026.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →