SAP-Berechtigungen,
präzise erklärt.

Segregation of Duties (SoD) bedeutet, dass kritische Vorgänge nicht in einer Hand liegen – etwa Geschäftspartner anlegen, Bestellung auslösen (ME21N) und den Zahllauf freigeben (F110). Entscheidend ist: Funktionstrennung wird nicht über Transaktionen allein definiert, sondern über Berechtigungsobjekt und Aktivität (ACTVT). Geprüft wird gegen ein risikobasiertes Regelwerk; für Konflikte, die sich organisatorisch nicht auflösen lassen, werden dokumentierte kompensierende Kontrollen (Mitigating Controls) hinterlegt. Fehlende Funktionstrennung zählt zu den häufigsten und schwersten Audit-Findings.

Das Prinzip der minimalen Rechtevergabe: Jeder Benutzer und jeder technische Account erhält genau die Berechtigungen, die die Aufgabe erfordert – nicht mehr. In SAP heißt das konkret: keine pauschalen „*“-Werte auf Organisationsebenen, kein SAP_ALL für Dialognutzer, Aktivitäten (ACTVT) eng gefasst (Anzeigen statt Ändern, wo möglich) und Vorschlagswerte in der SU24 sauber gepflegt. Least Privilege ist der Leitgedanke jedes belastbaren Rollenkonzepts – und die wirksamste Verteidigung gegen Missbrauch, Bedienfehler und Audit-Findings.

Eine kompensierende Kontrolle für SoD- oder kritische Berechtigungsrisiken, die sich organisatorisch nicht sinnvoll auflösen lassen – etwa weil ein kleines Team mehrere Funktionen abdecken muss. Statt das Risiko zu ignorieren, wird es bewusst akzeptiert und durch eine wirksame Gegenmaßnahme abgesichert: eine nachgelagerte Vier-Augen-Kontrolle, regelmäßige Auswertungen oder Protokoll-Reviews mit benanntem Verantwortlichen und festem Turnus. Für den Prüfer entscheidend ist, dass die Kontrolle dokumentiert, zugeordnet und nachweislich gelebt wird – sonst ist sie wertlos.

Ein Notfalluser (oft „Firefighter“) erhält befristet erweiterte Rechte, um in Ausnahmesituationen – Produktionsstörung, Hotfix, Jahresabschluss – handlungsfähig zu sein. Professionell umgesetzt heißt das: Beantragung mit Begründung, zeitliche Befristung, lückenlose Protokollierung der ausgeführten Aktionen und ein nachgelagerter Review durch eine unabhängige Stelle (Vier-Augen-Prinzip). Ohne diesen kontrollierten Prozess wird aus der Ausnahme schnell ein dauerhaft breit berechtigter Account – und damit ein zentrales Sicherheits- und Audit-Risiko.

Die periodische Überprüfung, ob vergebene Berechtigungen noch zur Aufgabe des Benutzers passen (engl. User Access Review). Verantwortliche – meist Vorgesetzte oder Rollen-Owner – bestätigen oder entziehen die zugeordneten Rollen in einem festen Turnus. Sie ist die wirksamste Maßnahme gegen schleichende Überberechtigung durch Abteilungswechsel und das Ansammeln von Rechten und inzwischen – unter anderem durch NIS-2 – faktisch Pflicht. Ohne Rezertifizierung verwässert auch das sauberste Redesign binnen weniger Jahre wieder.

SAP unterscheidet drei Rollentypen. Eine Einzelrolle enthält Transaktionen und Berechtigungswerte. Eine abgeleitete Rolle übernimmt den Funktionsschnitt einer Master- oder Referenzrolle und unterscheidet sich nur in den Organisationsebenen – ideal, um denselben Aufgabenzuschnitt für viele Buchungskreise oder Werke wartbar auszuprägen. Eine Sammelrolle bündelt mehrere Einzelrollen zu einem Paket für die Zuordnung, ohne selbst Berechtigungen zu tragen. Ein konsistentes Master-/Ableitungskonzept ist der Kern einer wartbaren Rollenlandschaft; verstreut gepflegte Org-Werte sind dagegen ein klassischer Pflegealbtraum.

Zwei Grundstrategien für ein Berechtigungsredesign. Greenfield baut das Konzept vom Geschäftsprozess her neu auf – mit klarer Namenskonvention, sauberem Funktionsschnitt und Ableitung über die Org-Ebenen; höchste Qualität, aber mehr Aufwand und ein Alt-zu-Neu-Mapping. Brownfield saniert den Bestand: Redundanzen entfernen, „*“-Werte ersetzen, ungenutzte Transaktionen aus Traces aussortieren, SU24 nachziehen – schneller, lässt aber strukturelle Altlasten. Hybrid übernimmt bewährte Funktionsschnitte, gießt sie aber in ein neues Namens- und Ableitungskonzept. Welcher Weg passt, hängt von Auditdruck, Ausgangsqualität und Change-Kapazität ab.

Organisationsebenen (Org-Level) sind besondere Berechtigungsfelder wie Buchungskreis (BUKRS), Werk (WERKS) oder Einkaufsorganisation (EKORG), die sich in der PFCG zentral pflegen und an abgeleitete Rollen vererben lassen. Sie sind der Schlüssel zu wartbaren Ableitungskonzepten: Der Funktionsschnitt liegt in der Master-Rolle, die Org-Ausprägung steckt allein in der Ableitung. Felder lassen sich über die Transaktion SUPO zu Org-Ebenen hochstufen – das ist mächtig, aber systemweit wirksam und will deshalb gut überlegt sein.

RESPAREA (Responsibility Area) bildet Verantwortungsbereiche im Controlling entlang von Standardhierarchien ab – etwa für Kostenstellen oder Profitcenter. Ein einzelner Knoten deckt automatisch alle untergeordneten Elemente ab. Mächtig und pflegearm, aber riskant: Ein zu breiter Wert öffnet schnell ganze Bereiche und wird im Audit zur Herausforderung.

Der grundlegende Neuzuschnitt einer gewachsenen Rollenlandschaft. Statt Rollen aus Gewohnheit fortzuschreiben, werden sie auf Basis der tatsächlichen Systemnutzung neu gebaut – ausgewertet über Berechtigungstraces (STAUTHTRACE) und gepflegte SU24-Vorschlagswerte, strukturiert in Master- und abgeleitete Rollen entlang der Org-Ebenen. Ergebnis sind weniger, schlankere und redundanzfreie Rollen, geringerer Pflegeaufwand und eine saubere Grundlage für Funktionstrennung und Compliance. Dauerhaft trägt ein Redesign aber nur mit einem Betriebskonzept aus Rollen-Ownern, Änderungsprozess und Rezertifizierung dahinter.

Die PFCG ist die zentrale Transaktion zur Pflege von Rollen und Profilen in SAP. Hier werden Transaktionen, Berechtigungsobjekte, Feldwerte und Organisationsebenen zu Rollen zusammengeführt und in Profile generiert. Ihr Verhalten wird über Customizing-Tabellen wie PRGN_CUST gesteuert.

Ein systemweiter Berechtigungstrace, der für jede Prüfung Objekt, Feldwerte und Ergebnis erfasst. STAUTHTRACE ist das wichtigste Werkzeug, um im Redesign exakt zu sehen, welche Berechtigungen ein Prozess tatsächlich braucht – statt aus Menüs zu raten. Für die punktuelle Detailanalyse gemacht, nicht für Langzeitauswertungen.

In der SU24 sind die Vorschlagswerte hinterlegt, die beim Rollenbau in der PFCG automatisch gezogen werden – also welche Berechtigungsobjekte zu einer Transaktion oder App vorgeschlagen werden. Diese Werte sind oft historisch gewachsen und breiter als nötig. Werden sie ungeprüft übernommen, entstehen Überberechtigungen. Eine saubere, trace-gestützte SU24-Pflege ist deshalb das Fundament schlanker Rollen.

Die SU25 ist das Werkzeug rund um die Vorschlagswerte der SU24 – insbesondere beim Erstbefüllen und nach Release-Wechseln. Über die bekannten Schritte (Abgleich der SAP-Standardvorschläge mit den kundeneigenen Werten) sorgt sie dafür, dass neue oder geänderte Vorschlagswerte nach einem Upgrade kontrolliert in die Kundentabellen übernommen werden – ohne eigene Anpassungen zu überschreiben. Wer die SU25-Schritte nach einem Upgrade auslässt, riskiert veraltete Vorschläge und stille Lücken im Rollenbau.

Die SU53 zeigt die zuletzt fehlgeschlagene Berechtigungsprüfung eines Benutzers – ideal für die schnelle Soforthilfe im Support. Für ein Redesign reicht sie nicht aus, weil sie nur Einzelsituationen abbildet und weder systematische Lücken noch überflüssige Berechtigungen sichtbar macht. Dafür braucht es die umfassenderen Trace-Werkzeuge.

Das Benutzerinformationssystem ist das zentrale Auswertungswerkzeug für Berechtigungen: Welche Benutzer haben eine bestimmte Transaktion, ein Berechtigungsobjekt oder eine kritische Kombination? Welche Rollen enthalten welche Werte, und was hat sich seit wann geändert? SUIM (mit den RSUSR-Reports im Hintergrund) ist damit das Standardwerkzeug für Ist-Analysen, Audit-Vorbereitung und die Suche nach kritischen Berechtigungen. Für die gezielte Laufzeitanalyse einer einzelnen Aktion ergänzt es ein Trace-Werkzeug wie STAUTHTRACE.

Das Berechtigungsobjekt für die ABAP-Entwicklungsumgebung – von der Anzeige von Coding bis zum Anlegen und Ändern von Entwicklungsobjekten. Besonders kritisch ist das Debuggen mit Replace (Aktivität 02 im Debugger): Damit lassen sich zur Laufzeit Variablen und sogar Berechtigungsprüfungen manipulieren – faktisch ein Generalschlüssel. Im Produktivsystem gehört S_DEVELOP daher stark eingeschränkt und Debug-Replace nur kontrolliert und protokolliert vergeben. Es zählt zu den Standard-Prüffeldern jeder Wirtschaftsprüfung.

Das Berechtigungsobjekt S_RFCACL steuert Trusted-RFC-Beziehungen zwischen Systemen. Mit weitreichenden Werten – bis hin zu Wildcards – kann ein Benutzer Aufrufe über Systemgrenzen hinweg starten. Genau deshalb gilt es als besonders sensibel und sollte nicht pauschal über SAP_ALL, sondern nur über gezielte Rollen mit präzisen Feldwerten (SysID, Mandant, User) vergeben werden.

Das klassische Objekt für den Tabellenzugriff über die Standardpflege (SM30/SM31 und Co.). Es steuert den Zugriff nicht je Tabelle, sondern über grobe Berechtigungsgruppen (Feld DICBERCLS) – eine einzige Gruppe kann hunderte Tabellen umfassen. Das macht es pflegeleicht, aber unscharf: Mit einer Gruppe gerät schnell deutlich mehr in Reichweite als beabsichtigt, was im Audit regelmäßig auffällt. Die feingranulare, transparentere Alternative ist S_TABU_NAM.

Die feingranulare Alternative zu S_TABU_DIS: Statt über grobe Berechtigungsgruppen wird der Tabellenzugriff direkt auf einzelne Tabellen vergeben. Das macht den Rollenbau aufwendiger, aber deutlich transparenter und auditfreundlicher – und vermeidet die ungewollte Mitnahme ganzer Tabellengruppen.

Das grundlegendste Berechtigungsobjekt überhaupt: S_TCODE prüft beim Start einer Transaktion, ob der Benutzer den jeweiligen Transaktionscode (Feld TCD) ausführen darf. Es ist die erste Hürde – reicht aber nie allein, weil danach die fachlichen Objekte der Transaktion geprüft werden (etwa Aktivität und Organisationsebene). Ein verbreiteter Fehler ist, Zugriff nur über S_TCODE zu steuern und die nachgelagerten Objekte mit „*“ offenzulassen; sauber ist die Kopplung über gepflegte SU24-Vorschlagswerte.

CODVN bezeichnet die Codeversion, also das Verfahren, mit dem SAP Passwörter in der Tabelle USR02 als Hash speichert. Ältere Verfahren (z. B. das MD5-basierte BCODE) gelten als unsicher und sollten abgelöst werden. Stand der Technik ist CODVN H – ein iterierter, gesalzener SHA-Hash (iSSHA-1, über login/password_hash_algorithm einstellbar) mit zufälligem Salt und vielen Iterationen, ohne unnötige Abwärtskompatibilität.

Read Access Logging (RAL) protokolliert den lesenden Zugriff auf besonders schützenswerte Daten – etwa Bankverbindungen, Gehälter oder personenbezogene Felder –, die normale Änderungsbelege nicht erfassen. Konfiguriert wird kanal- und feldbezogen (Dynpro, Web-Services, RFC), sodass sich belegen lässt, wer wann welche sensiblen Daten eingesehen hat. RAL ist vor allem im Datenschutzkontext (DSGVO) und bei erhöhten Nachweispflichten relevant – sollte aber gezielt eingesetzt werden, da umfassendes Logging Datenvolumen und Performance kostet.

RFC (Remote Function Call) ist die klassische Schnittstellentechnik, über die SAP-Systeme miteinander kommunizieren. Bei einer Trusted-RFC-Beziehung vertraut ein System dem anderen, sodass keine erneute Anmeldung nötig ist. Das ist bequem, aber sicherheitskritisch: Schlecht abgesicherte RFC-Verbindungen sind ein typischer Weg für „Lateral Movement“ über Systemgrenzen hinweg.

Das Sammelprofil SAP_ALL enthält praktisch alle Berechtigungen eines SAP-Systems – der berühmte „Generalschlüssel“. In Produktivsystemen gehört es eng kontrolliert, befristet und protokolliert vergeben, niemals dauerhaft an Dialognutzer. Ob das besonders kritische Objekt S_RFCACL Teil von SAP_ALL ist, steuert übrigens ein einziger Customizing-Schalter (ADD_S_RFCACL).

Das Security Audit Log (SAL) protokolliert sicherheitsrelevante Ereignisse im SAP-System: erfolgreiche und fehlgeschlagene Anmeldungen, RFC-Aufrufe, Transaktionsstarts, Änderungen an Benutzern und kritische Aktionen. Konfiguriert wird es über Filter (klassisch SM19, neuer RSAU_CONFIG), ausgewertet über SM20 bzw. RSAU_READ_LOG. Es ist die zentrale Grundlage, um privilegierte Zugriffe – etwa die Nutzung von Notfallusern – nachvollziehbar zu machen, und damit ein Eckpfeiler der Nachweispflichten aus NIS-2 und Abschlussprüfung.

Die Zentrale Benutzerverwaltung (ZBV, englisch CUA) erlaubt die Pflege von Benutzern für mehrere angeschlossene SAP-Systeme von einem zentralen System aus. Das spart Aufwand, bringt aber Abhängigkeiten mit sich – etwa bei Passwort-Hashverfahren, wo aus Abwärtskompatibilität teils ältere, schwächere Verfahren mitgeführt werden.

Inaktive Benutzerkonten, die seit langem nicht mehr genutzt werden – „Karteileichen“. Sie sind doppelt problematisch: Sie binden unnötige, oft lizenzpflichtige Nutzerlizenzen und sind ein Einfallstor, weil sie niemand mehr kontrolliert. Mit Bordmitteln lassen sie sich systematisch erkennen – etwa über den letzten Logon (Tabelle USR02, Report RSUSR200) – und anschließend automatisiert sperren oder per Gültigkeitsdatum stilllegen. Regelmäßiges Aufräumen inaktiver Konten gehört zu jeder ernstzunehmenden Rezertifizierung.

Governance, Risk & Compliance bezeichnet das Zusammenspiel aus Steuerung, Risikomanagement und Regelkonformität. Im SAP-Berechtigungsumfeld geht es vor allem um die kontinuierliche, regelbasierte Prüfung von Zugriffsrisiken und Funktionstrennung: SoD-Konflikte automatisiert erkennen, Risiken bewerten, kompensierende Kontrollen verwalten und Berechtigungsanträge sowie Notfallzugriffe geregelt abwickeln. So hängt Compliance nicht mehr an Stichproben, sondern wird laufend überwacht und nachweisbar dokumentiert. Wir arbeiten mit dem im Haus eingesetzten GRC-Werkzeug – herstellerunabhängig.

Ein Prüfungsstandard des Instituts der Wirtschaftsprüfer zum Einsatz von IT bei der Abschlussprüfung. Für SAP-Berechtigungen heißt das konkret: Der Prüfer beurteilt, wer auf rechnungslegungsrelevante Funktionen und Daten zugreifen kann und ob das angemessen kontrolliert ist. Typische Prüffelder sind kritische Berechtigungen (SAP_ALL, Tabellenzugriff, Debugging mit Replace), Funktionstrennung, der Umgang mit Notfallusern, Standard- und technische User sowie das Änderungs- und Transportwesen. Beurteilt wird die Wirksamkeit der Kontrollen über den Zeitraum – nicht nur eine Momentaufnahme.

Eine EU-Richtlinie zur Cybersicherheit, die deutlich mehr Unternehmen und auch die Leitungsebene in die Pflicht nimmt. Für SAP-Berechtigungen relevant: nachweisbare, rollenbasierte Zugriffskontrolle nach Least Privilege, regelmäßige Rezertifizierung, ein kontrollierter und protokollierter Notfallzugriff sowie die Protokollierung privilegierter Aktionen – etwa über das Security Audit Log, bei sensiblen Daten ergänzt um Read Access Logging. Aus „Best Practice“ wird damit eine dokumentations- und nachweispflichtige Vorgabe.