SAP SU24 Varianten in S/4HANA: Effizientere Berechtigungsrollen

Die Verwaltung von Berechtigungen in SAP-Systemen, insbesondere in SAP S/4HANA und mit der Einführung von SAP Fiori, ist eine zentrale Säule der IT-Sicherheit und Nutzerfreundlichkeit. Eine effektive Berechtigungsverwaltung entscheidet maßgeblich über die User Experience (UX) Ihrer Anwender. Fehlerhafte oder ineffizient gepflegte Berechtigungen können die Akzeptanz neuer Technologien, wie des Fiori Launchpads, erheblich mindern und den potenziellen Nutzen für Ihre Organisation reduzieren. Ein häufiges Problem ist beispielsweise, dass manuell hinzugefügte Transaktionscodes in einer Rolle für Benutzer im Fiori Launchpad nicht verfügbar sind.

Seit jeher gilt beim Aufbau von Anwendungsberechtigungsrollen über die Transaktion PFCG (Rollenpflege) ein klares Mantra: Vermeiden Sie CHANGED. MANUAL nur in Ausnahmefällen. MAINTAINED ist akzeptabel. Streben Sie STANDARD an. Dieses Prinzip ist eng mit der Transaktion SU24 (Berechtigungsvorschläge) verknüpft, die automatisch Vorschläge in die Berechtigungsdaten einer Rolle importiert oder entfernt, basierend auf den Einträgen im Rollenmenü. Neue Funktionen, insbesondere die Einführung von Varianten in der Sap Su24, bieten nun die Möglichkeit, die Effizienz und Qualität des Berechtigungsrollenbaus in SAP S/4HANA signifikant zu verbessern.

Experten diskutieren SAP S/4HANA Berechtigungsrollen und SU24-Varianten

Die Integration von PFCG und SU24 im Überblick

Die Transaktion SU24 ist in erster Linie ein Beschleuniger für den Rollenbau und gilt als Best Practice, da sie entscheidende Vorteile bietet:

• Reduziert “Access Creep”: Wenn Transaktionen aus dem Rollenmenü entfernt werden, werden die zugehörigen Berechtigungsvorschläge ebenfalls entfernt (sofern sie nicht von einem anderen Menüpunkt benötigt werden). Dieser Vorteil funktioniert jedoch nur für Elemente mit dem Berechtigungsstatus “STANDARD” und “MAINTAINED”.
• Reduziert Berechtigungsfehler: Die Rolle erhält automatisch die erforderlichen Berechtigungen für jede Anwendung, sofern die Zuordnungen in der Transaktion SU24 vollständig gepflegt und die Anwendung zum Rollenmenü hinzugefügt wurde.
• Reduziert Erstellungsaufwand und -zeit: Sicherheitsadministratoren können bestehende Zuordnungen für den Rollenbau nutzen, was weniger Zeit für die Zuordnung der Werte für jede Rolle erfordert.
• Vereinfacht und verbessert die Impaktanalyse: Es erleichtert Berechtigungsexperten, schnell zu identifizieren, warum eine Berechtigung Teil einer Sicherheitsrolle ist. Dies unterstützt bei der Bewertung der Auswirkung auf die Funktionstrennung (Segregation of Duties), bei der Rollenbereinigung und bei der Priorisierung von Regressionstests.

Kehren wir zum bereits erwähnten Mantra zurück:

Vermeiden Sie CHANGED. MANUAL nur in Ausnahmefällen. MAINTAINED ist akzeptabel. Streben Sie STANDARD an.

Warum “CHANGED” vermeiden?

Den Status “CHANGED” sollten wir nach Möglichkeit vermeiden, da er einen bewussten Bruch der Standardzuordnungen darstellt und von der Konsistenz abweicht. Ein Objekt mit dem Status “CHANGED” wird wie ein “MANUAL”-Objekt behandelt. Die Transaktion PFCG kann eine “CHANGED”-Berechtigung nicht automatisch aus der Rolle entfernen, wenn die Transaktion aus dem Menü entfernt wird, da keine direkte Beziehung zwischen den Daten besteht. Folglich können “CHANGED”-Objekte den “Access Creep” erhöhen und es erschweren, den Zugriff korrekt zu bewerten oder zu entfernen.

“MANUAL” nur in Ausnahmefällen?

“MANUAL” akzeptieren wir nur in Ausnahmefällen. Einige Berechtigungen sind erforderlich, aber nicht Anwendungen zugeordnet, die einem Rollenmenü hinzugefügt werden können (z. B. S_RFCACL für Trusted RFC-Verbindungen). Einige können klare Designentscheidungen sein, um eine bestehende Rolle mit zusätzlichen Berechtigungen zu ergänzen (z. B. Genehmigungscodes für den Einkauf). Diese Ausnahmen sind klar dokumentiert und ändern sich seltener.

Warum “STANDARD” anstreben?

Wir streben den Status “STANDARD” an, weil er eine 100%ige Übereinstimmung mit den Berechtigungsvorschlägen bedeutet. Angenommen, die SU24-Daten sind korrekt, ist es unwahrscheinlich, dass das Team der Sicherheitsadministratoren Werte in PFCG pflegen muss. Dies gewährleistet höchste Konsistenz und Wartungsfreundlichkeit.

Ist “MAINTAINED” akzeptabel?

Wir akzeptieren “MAINTAINED” als einen Kompromiss zwischen der Pflege dessen, was in SU24 möglich ist, und der Vermeidung des “CHANGED”-Status. Es ist ein praktikabler Mittelweg, wenn “STANDARD” aufgrund spezifischer Anforderungen nicht vollständig erreichbar ist.

Wäre es nicht großartig, wenn wir uns nicht mit “MAINTAINED” zufriedengeben müssten? Varianten machen dies möglich.

Häufige Szenarien für den Status “MAINTAINED”

Der Status “MAINTAINED” tritt auf, wenn Berechtigungsvorschläge in SU24 nur teilweise gepflegt wurden. Dies ist notwendig, wenn ein Transaktionscode zu mehreren Rollen mit unterschiedlich zugrunde liegenden Berechtigungswerten gehört. Wenn wir beispielsweise eine Transaktion für die Tabellenpflege hätten, würden wir das Berechtigungsobjekt S_TABU_NAM bereitstellen. Dieses Objekt enthält die Felder “Aktivität” (Activity) und “Tabellenname” (Table Name). Wir können den Aktivitätsvorschlag nicht in SU24 pflegen, wenn wir Benutzern entweder Anzeige- oder Pflegemodus gewähren müssen. Beide Rollen würden jedoch denselben Tabellennamen benötigen. Infolgedessen würden wir den Vorschlag nur teilweise pflegen: Das Feld “Aktivität” bliebe leer, und “Tabellenname” enthielte den Eintrag.

Die Transaktion OB52 beispielsweise ermöglicht den Zugriff auf Buchungsperioden. Viele Benutzer benötigen lediglich Lesezugriff, während nur wenige Änderungen vornehmen dürfen. Innerhalb der Transaktion SU24 stellt SAP das Feld ACTVT (Activity) als leeren Vorschlag bereit, der dann auf Rollenebene gepflegt wird.

SU24-Konfiguration für das Berechtigungsobjekt S_TABU_NAM mit teilweisen Vorschlagswerten

Innerhalb der Transaktion PFCG würden wir zunächst einen STANDARD-Vorschlag erhalten, der dann auf “MAINTAINED” gesetzt wird, sobald wir die Aktivitätsvorschläge vollständig ausgefüllt haben (eine Rolle erhält nur Anzeige, während die andere Rolle Änderungs- und Anzeigezugriff erhält).

Weitere Szenarien für “MAINTAINED” – und wo es kompliziert werden kann

Der Status “MAINTAINED” kann auch aus folgenden Gründen resultieren:

• SAP-Vorschläge und Upgrades bleiben unverändert: Der Kunde entscheidet sich, die Standardvorschläge so zu belassen und alle notwendigen Anpassungen auf Rollenebene vorzunehmen.
• “Cockpit”-Transaktionen: Die Anwendung hat mehrere Anwendungsfälle, die durch Kombinationen von Berechtigungen gesteuert werden. Die SU24-Standardvorschläge bleiben überwiegend leer, um Flexibilität bei der Pflege der Werte auf Rollenebene zu bieten.
• HR-Berechtigungen und -Transaktionen: Die meisten HR-Transaktionszugriffe werden über zwei (2) Hauptobjekte gesteuert – P_ORGIN und PLOG. Diese Objekte enthalten Felder für die Aktivitätsebene, Infotypen und Einschränkungen für Unternehmensdaten. Um den Status “CHANGED” und “MANUAL” zu vermeiden, werden diese Objekte mit leeren Vorschlägen hinzugefügt und alle Änderungen auf Rollenebene verwaltet.

SAP-Vorschläge und Upgrades

SAP liefert Standardvorschläge für SAP-Standardtransaktionen. Diese Werte werden über die Tabellen der Transaktion SU22 ausgeliefert und über die Transaktion SU25 (für Greenfield-Systeme wird Schritt 1 ausgeführt) in die SU24-Tabellen kopiert. Der Kunde darf Änderungen an den SAP-Vorschlägen vornehmen. Innerhalb der Transaktion SU24 können Sie die Werte in Ihrem System mit den SAP-Vorschlägen vergleichen, um zu prüfen, ob Sie vom Original abgewichen sind.

Vergleich von SAP-Standardvorschlägen und kundeneigenen Änderungen in der SU24-Transaktion

Im Rahmen von Upgrades liefert SAP neue Werte (Änderungen an bestehenden Zuordnungen und Zuordnungen für neue Transaktionen). Der Kunde verwendet die Transaktion SU25, Schritte 2a/2b, um Kundentabellen und SAP-Tabellen zu vergleichen und Änderungen zu importieren.

Initialbild der Transaktion SU25 zur Übernahme von SAP-Vorschlagswerten bei Upgrades

Für viele Kunden wird es jedoch zu einer Herausforderung, zu entscheiden, ob sie SAP-Updates für bereits gepflegte Transaktionen übernehmen sollen. Abhängig vom Reifegrad des Rollenbaus kann es schwierig sein zu beurteilen, welche Vorschläge besser geeignet sind: die neuesten SAP-Vorschläge oder die vom Kunden im Rahmen der Rollenverfeinerung vorgenommenen Updates.

Einige Teams für die Sicherheitsadministration vermeiden Änderungen an SAP-Standardvorschlägen. In dieser Situation führt dies zu einem erhöhten Anteil an “CHANGED” und “MANUAL”-Berechtigungen – genau das, was wir vermeiden wollen. Es erleichtert jedoch die Bearbeitung von Upgrades für das Sicherheitsteam.

“Cockpit”-Transaktionen

Eine “Cockpit”-Transaktion ist ein einziger Einstiegspunkt für mehrere funktionale Szenarien und wird mehreren Rollen zugewiesen. In dieser Situation haben SU24-Vorschläge eine höhere Rate an Unvollständigkeit und erfordern eine individuelle Pflege in jeder Rolle. Jede Rolle benötigt eine andere Kombination von Feldwerten. Dieser Grad der Lokalisierung verlagert den Erstellungsaufwand auf den Sicherheitsadministrator als Teil des Rollenbaus.

HR-Berechtigungen und -Transaktionen

HR-Berechtigungsobjekte steuern den Zugriff auf Personalstammdaten und Organisationsstrukturen für Infotypen. Wenn Sie versuchen, SU24-Vorschläge zu verwenden, sind Sie in den meisten Fällen gezwungen, einen leeren Vorschlag in SU24 einzugeben, da jede Rolle unterschiedliche Werte benötigt. Beispielsweise erfordert der Transaktionscode PA30 (Personalstammdaten pflegen) P_ORGIN-Berechtigungen, um die Aktivitätsebene, den Datenzugriff und die Infotypen zu steuern. Mehrere Benutzer benötigen möglicherweise Zugriff auf die Transaktion, aber unterschiedlichen funktionalen Zugriff. Daher müsste P_ORGIN in SU24 leer bleiben und vollständig in PFCG gepflegt werden. Dies kann es in HR-zentrierten Rollen schwierig machen, zu bestimmen, warum die Rolle bestimmte Feldwerte enthält, da der Kontext nicht anhand der Rollenmenüpunkte bestimmt werden kann. Oft greifen Sicherheitsadministratoren stattdessen auf das manuelle Hinzufügen von Objekten zurück, anstatt eine SU24-Pflege zu versuchen.

Ein Anwendungsfall für SU24-Varianten: Fiori App F3163

Nehmen wir das Szenario einer “Cockpit”-Anwendung: Sie möchten Benutzern Zugriff auf die Fiori App F3163 “Geschäftspartnerstammdaten verwalten” ermöglichen. Diese Anwendung erlaubt den Zugriff auf Lieferanten-, Kunden- und Mitarbeiterinformationen und ist in mehreren Geschäftsrollen-Templates enthalten. Viele Benutzer benötigen Zugriff auf die Anwendung, müssen jedoch auf spezifische Daten beschränkt werden.

Fiori Apps Reference Library Ansicht der App F3163 'Geschäftspartnerstammdaten verwalten'

Die Berechtigung für die Fiori App F3163 basiert auf dem SAP Gateway Service MD_BUSINESSPARTNER_SRV 0001. Innerhalb der SU24 werden Standardvorschläge bereitgestellt, diese sind jedoch für den Pflegezugriff ohne spezifische Einschränkung auf die Geschäftspartnerrolle. Das bedeutet, ohne Änderungen des Vorschlags in der Transaktion SU24 müssten alle Einschränkungen auf Rollenebene erfolgen. Änderungen auf Rollenebene würden zu den Status “MAINTAINED”, “CHANGED” oder “MANUAL” führen. Alternativ könnte die SU24 so aktualisiert werden, dass die Feldvorschläge entfernt und leere Werte für die vollständige Pflege auf Rollenebene hinterlassen werden (was letztendlich nur zu “MAINTAINED” führen würde), aber dies berücksichtigt keine unterschiedlichen Pflegestufen (z. B. kann der Löschzugriff eingeschränkt sein).

Standard-SU24-Vorschläge für den SAP Gateway Service MD_BUSINESSPARTNER_SRV

Jedes Mal, wenn die Anwendung zu einer Rolle hinzugefügt wird, muss der Administrator dann Änderungen vornehmen. Der SU24-Vorschlag, wie er im Bild oben dargestellt ist, würde immer importiert werden, sodass eine Rolle mit einem sehr breiten Berechtigungsumfang resultiert. Das Team der Sicherheitsadministratoren muss dann jede vorgeschlagene Berechtigung durcharbeiten, um entweder nicht benötigte Berechtigungen zu deaktivieren, Feldvorschläge zu vervollständigen oder zur Transaktion SU24 zurückzukehren, um Vorschläge in den Stammdaten zu ändern, und dann zur Rolle zurückzukehren, um den Rollenbau fortzusetzen. Da diese Anwendung jedoch von mehreren Prozessbereichen (Beschaffung, Vertrieb, HR usw.) genutzt wird, ist es unwahrscheinlich, dass SU24-Vorschläge geändert werden, da dies alle Rollen beeinflussen würde. Stattdessen landen die Vorschläge im Status “MAINTAINED” oder “CHANGED”, um die erforderliche Berechtigung für die Rolle beizubehalten. Letztendlich gehen die Vorteile der SU24-Vorschläge verloren, oder Sie müssen alle Vorschläge in SU24 entfernen und alles in PFCG pflegen.

SU24-Variantenpflege für MD_BUSINESSPARTNER_SRV zur Abbildung spezifischer Zugriffsberechtigungen

Varianten können dieses Problem jedoch lösen und es Ihnen ermöglichen, weiterhin STANDARD-Vorschläge zu verwenden. Innerhalb der Transaktion SU24 wird eine Variante mit der erforderlichen Zuordnung erstellt. Bevor wir jedoch die Varianten erstellen, betrachten wir, wie der Anwendungs-Tab in PFCG aussieht, wenn keine Varianten verfügbar sind.

PFCG-Anwendungs-Tab ohne verfügbare SU24-Varianten

Dieser Tab in PFCG wird erst gefüllt, nachdem das Rollenmenü aktualisiert und die SU24-Definitionen eingelesen wurden. Im obigen Beispiel sind die Optionen ausgegraut, da keine Varianten zur Auswahl stehen. Dies zeigt, dass ohne Varianten die Flexibilität, spezifische Zugriffskontexte zu steuern, eingeschränkt ist, und es erfordert manuelle Anpassungen, die oft zu “MAINTAINED”- oder “CHANGED”-Status führen.

Berechtigungsdaten in PFCG vor der Anwendung einer SU24-Variante

Wenn die Varianten ausgewählt sind, werden die SU24-Vorschläge über den Berechtigungs-Tab importiert. Wie in diesem Beispiel sind keine Varianten vorhanden, sodass die SAP-Standardwerte übernommen werden.

Varianten in SU24 nutzen: So geht’s

Diese Funktionalität wurde ursprünglich unter einem “neuen” Transaktionscode SU24N bereitgestellt, ist aber inzwischen wieder in die Transaktion SU24 integriert worden. Für weitere Details siehe SAP Hinweis: 2798443 – SU24N: New dialog environment for authorization default value maintenance. Die Transaktion SU24 ermöglicht es Ihnen nun, Varianten der Pflegevorschläge zu erstellen. Das bedeutet, Sie können mehrere Vorschlagsversionen anlegen und steuern, welche Sie in den Rollen übernehmen.

Innerhalb der Transaktion SU24 können Sie nun VARIANTE ANLEGEN wählen, anstatt die SAP-Standardvorschläge für eine Anwendung zu ändern. Bei der Erstellung der Variante müssen Sie diese im Kundennamensraum eingeben. Sie können eine Namenskonvention implementieren (z. B. das Hinzufügen der Fiori-Applikations-ID, was später für den Kontext hilfreich sein kann).

Erste Schritte zur Varianten-Erstellung in der Transaktion SU24

Da es sich um ein Workbench-Objekt handelt, müssen Sie es einem Transportauftrag zuweisen. Sobald Sie die Variante erstellt haben, können Sie mit den Änderungen an den Vorschlagsdaten beginnen, ohne die Standardwerte zu aktualisieren.

Anpassung der Berechtigungsvorschläge innerhalb einer neuen SU24-Variante

Im Fall dieser Anwendung und im Kontext der Verwaltung von Lieferanten können Sie nun Berechtigungsvorschläge deaktivieren, die nicht relevant sind, sowie bestehende Vorschläge für Werte ändern, die für Lieferantenstammdaten relevanter sind.

Nachdem Sie die Updates abgeschlossen haben, speichern Sie diese (genau wie Sie es getan hätten, wenn Sie die Standardvorschläge aktualisiert hätten).

Speichern der geänderten Vorschläge in der SU24-Variante

Kehren Sie zur Transaktion PFCG zurück und gehen Sie zum Anwendungs-Tab. Sie werden nun die SU24-Varianten automatisch identifiziert sehen, basierend auf den Anwendungen im Rollenmenü.

PFCG-Anwendungs-Tab mit Auswahlmöglichkeiten für SU24-Varianten

Da nun eine Variante existiert, können Sie auswählen, welche für die Berechtigungsvorschläge der Rolle verwendet werden soll. Wenn mehrere Varianten vorhanden sind, können Sie beliebig viele für die Rolle auswählen.

Auswahl einer spezifischen SU24-Variante für die PFCG-Rolle

Nachdem Sie die zutreffende Variante ausgewählt haben, speichern Sie die Rolle, bevor Sie die Berechtigungsdaten erneut pflegen. Im Berechtigungs-Tab müssen Sie den Expertenmodus für die Profilgenerierung > Alte lesen/mit neuen zusammenführen auswählen, um die SU24-Werte neu einzulesen und die VARIANT-Vorschläge zu übernehmen.

Sie werden weiterhin aufgefordert, die Organisationswerte einzugeben (oder zu aktualisieren, falls erforderlich).

Aktualisierung der Organisationswerte in PFCG nach Anwendung einer SU24-Variante

Die Berechtigungsdaten zeigen nun mehr STANDARD (grüne) Vorschläge aufgrund der von Ihnen gepflegten Variante.

Berechtigungsdaten in PFCG mit erhöhtem STANDARD-Status durch SU24-Varianten

Bei der Überprüfung der Berechtigungsvorschläge sehen Sie nun, welche spezifische Variante sie eingebracht hat.

Übersicht der Berechtigungsvorschläge in PFCG mit Angabe der SU24-Variantenquelle

Wie bereits erwähnt, ist der Variantenname bei der Erstellung einer VARIANT in SU24 sehr nützlich, um den Kontext zu verstehen. Wie oben gezeigt, ist der Anwendungs-Variantenname “ZF3163_SUP_M” eine grundlegende Namenskonvention für die Fiori App F3163 mit der Variante “Supplier Maintenance” (Lieferantenpflege). Solche Konventionen können es erleichtern, den Zugriffskontext zu verstehen, im Vergleich zum OData-Service-Namen der Anwendung.

Vorteile des Einsatzes von SU24-Varianten

Der Hauptvorteil der Verwendung von Varianten besteht darin, dass Sie die Berechtigungs-Standardvorschläge aus SU24 nutzen und den gesamten Pflegeaufwand einzelner Berechtigungen innerhalb der Rolle minimieren können. Im Folgenden sind weitere Vorteile aufgeführt, die sich aus der Verwendung von Varianten in SU24 ergeben:

• Einfache Handhabung unterschiedlicher Zugriffskontexte für dieselbe Anwendung.
• Trennung der Standardzuordnungen für Entwicklung/Wartung von den Zuständigkeiten des Berechtigungsrollen-Teams.
• Reduzierung des “Access Creep” und der Verwirrung beim Rollenbau durch weniger direkte manuelle Pflege von Werten.
• Besserer Zugriffskontext durch Variantenbezeichnungen, um den Grund für Berechtigungsvorschläge innerhalb einer Rolle besser zu verstehen.
• Einfache Ergänzung einer neuen Variante zu einer Anwendung für eine andere Rolle, ohne die bestehenden Rollen pflegen zu müssen. Dies kann auftreten, wenn Sie eine Anwendung im Design hinzufügen, aber die SU24 ändern müssen. Wenn Sie die SU24-Daten aktualisieren, müssten Sie auch die bestehenden Rollen pflegen und Regressionstests durchführen. Dies erhöht Ihre Änderungsanforderungen und Ihren Aufwand. Stattdessen können Sie eine neue Variante nur für diese Werte definieren.
• Reduzierung des SU25 Schritt 2a/2b Upgrade-Aufwands, da Sie das Pflegen von SAP-Standardvorschlägen vermeiden. Sie müssen jedoch Ihre Varianten manuell bewerten, um zu entscheiden, ob Sie neue Wertvorschläge hinzufügen müssen, die dem SAP-Original hinzugefügt wurden.
• Flexibilität, Zugriffsvorschläge für Nicht-Produktions- und Produktionszugriff zu differenzieren. Dies kann Sicherheitsteams ermöglichen, SU24 für den Projektrollenbau sensibler Transaktionen zu nutzen, die im Allgemeinen nur im Anzeigemodus gewährt würden.
• Kleiner Vorteil: Sie können auf die Varianten-Tab-Zeilenelemente der Transaktion PFCG doppelklicken, um zur zugehörigen SU24-Konfiguration zu navigieren und zu bestätigen, dass Sie die erforderliche Variante ausgewählt haben.

Geben Sie Varianten eine Chance und teilen Sie Ihre Erfahrungen in den Kommentaren unten mit. Ich würde mich freuen zu erfahren, ob dies etwas ist, das Sie als Teil Ihres Rollenbau-Beschleunigers und Ansatzes für den konsistenten Aufbau von Sicherheitsrollen in Betracht ziehen würden.

Zusammenfassung der Berechtigungsstatus

Für diejenigen, die neu im Aufbau von ABAP-Berechtigungsrollen über die Transaktion PFCG sind, fasst die folgende Tabelle die Berechtigungsstatus zusammen:

Referenzen:

• SAP Hinweis: 2798443 – SU24N: New dialog environment for authorization default value maintenance