Konzeptkarte

Rollenbasierte Zugriffskontrolle (RBAC)

Stand 2026-07-23

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 Rollenbasierte Zugriffskontrolle (RBAC)?

RBAC und DAC beantworten zwei unterschiedliche Fragen, die ständig vermischt werden – RBAC entscheidet, ob ein Benutzer ein Objekt öffnen darf, DAC filtert, welche Zeilen dieses Objekts er sehen darf.

Worum es geht

RBAC (Role-Based Access Control) ist das Autorisierungsmodell, bei dem Berechtigungen an Rollen und Rollen an Benutzer geknüpft werden — niemals Berechtigungen direkt an Benutzer. In der SAP-Landschaft zeigt sich das auf zwei unterschiedlichen Ebenen, die ein Senior-Berater niemals vermischen darf: die ABAP/S-4HANA-Ebene (PFCG-Rollen, Berechtigungsobjekte, Sammelrollen) und die Datasphere-/Analytics-Ebene (Space-Berechtigungen, skopierte Rollen und Data Access Controls / DAC — Begleitmodul C008).

Zwei Ebenen, zwei Zwecke. PFCG-Rollen steuern, was ein Benutzer im Quell-ERP TUN darf (Transaktionszugriff, organisatorische Berechtigungen über Felder wie Buchungskreis und Werk). Datasphere-Space-Rollen steuern, was ein Benutzer innerhalb eines Space SEHEN und BAUEN darf (Viewer, Modeler, Space Administrator, plus benutzerdefinierte skopierte Rollen). DAC filtert dann ZEILEN innerhalb eines Objekts, auf das der Benutzer bereits Zugriff hat. RBAC beantwortet „darf dieser Benutzer dieses Objekt öffnen“; DAC beantwortet „welche Zeilen dieses Objekts darf er sehen“. Die beiden zu verwechseln ist der häufigste Governance-Designfehler bei Datasphere-Rollouts.

Warum die Rollenzahl explodiert. Eine Tier-1-SAP-Landschaft landet typischerweise bei 50–200 einzelnen Rollen, sobald organisatorische Berechtigungen (Buchungskreis, Werk, Vertriebsorganisation) mit funktionalen Bereichen (Finanzen, Einkauf, Vertrieb) und Datasphere-Space-Rollen kreuzmultipliziert werden. Design-Disziplin — Namenskonventionen für Rollen, eine Matrix Rolle-zu-Geschäftsfunktion und ein quartalsweises Access Review — verhindert, dass daraus unbeherrschbare technische Schulden werden.

Warum es zählt

PFCG-Rollen (Transaktionszugriff ERP-seitig) und Datasphere-Space-Rollen (Viewer/Modeler/Admin) sind zwei unterschiedliche Ebenen — sie zu vermischen ist der mit Abstand häufigste Governance-Designfehler bei Datasphere-Rollouts.
Die Rollenzahl explodiert von Natur aus auf 50–200, sobald organisatorische Bereiche (Buchungskreis, Werk, Vertriebsorganisation) mit funktionalen Bereichen und Space-Rollen kreuzmultipliziert werden — ohne Disziplin erreicht sie 500+ und wird nicht mehr prüfbar.
Einzelfall-Rollenausnahmen, die pro Benutzeranfrage vergeben statt auf die bestehende Matrix abgebildet werden, sind genau der Weg, auf dem Tier-1-Landschaften bei nicht mehr prüfbaren Rollen landen.

Kernpunkte

RBAC = Berechtigungen werden an Rollen geknüpft, Rollen an Benutzer — nie Berechtigungen direkt an Benutzer.
Zwei unterschiedliche Ebenen: PFCG-/ABAP-Rollen (Objektzugriff) vs. Datasphere-Space-Rollen (Space-Zugriff) — keine der beiden mit DAC (Zeilenzugriff) vermischen.
50–200 Rollen sind bei Tier-1-Größenordnung normal, sobald org. Bereich × funktionaler Bereich × Space-Rolle kreuzmultipliziert werden.
Die Rollenmatrix (Geschäftsfunktion × Systemebene × org. Bereich) muss vor dem Go-live abgezeichnet sein, nicht ad hoc entstehen.
Role-Based Access Control (RBAC) ist erst gemeistert, wenn es eine konkret benannte Buyer-Entscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.
Nutzen Sie aktuelle SAP-, Analysten-, Studien-, KG- und Nachrichtensignale als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Definieren Sie Owner, Kennzahl, Schwellenwert, Support-Pfad und Rollback, bevor Sie skalieren.
Definieren Sie auch bei Nicht-KI-Anwendungsfällen Qualität, Adoption und operative Verantwortung.

Begriffe auf dieser Seite

PFCG-Rolle: SAP-ABAP-Transaktion zur Rollenpflege; bündelt Berechtigungsobjekte in einer Rolle und weist die Rolle dann Benutzern zu.
Berechtigungsobjekt: Berechtigungseinheit auf ABAP-Ebene, die Felder (z. B. Buchungskreis, Werk) mit Aktivitätscodes kombiniert — die atomare Einheit, die PFCG-Rollen bündeln.
Space-Rolle: Datasphere-Rolle auf Space-Ebene (Viewer, Modeler, Space Administrator), die steuert, was ein Benutzer innerhalb eines Space sehen und bauen darf.
Data Access Control (DAC): Zeilenbasierter Filter, der angewendet wird, nachdem RBAC bereits Objektzugriff gewährt hat; beantwortet „welche Zeilen“, nicht „welches Objekt“.
Sammelrolle: PFCG-Rolle, die mehrere Einzelrollen zu einem Tätigkeitsprofil bündelt und die Zuweisung im großen Maßstab erleichtert.
Rollenmatrix: Raster aus Geschäftsfunktion × Systemebene × org. Bereich, mit dem Rollen vor dem Rollout gestaltet werden, nicht danach.
Organisatorische Berechtigung: Berechtigung, die durch ein organisatorisches Feld wie Buchungskreis, Werk oder Vertriebsorganisation eingegrenzt ist.
Access Review: Periodische (typischerweise quartalsweise) Prüfung, die vergebene Rollen mit der Rollenmatrix und der aktuellen Funktion jedes Benutzers abgleicht.

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.

In der App öffnen →