SAP_ALL und SAP_NEW richtig nutzen

Mit den Standardprofilen SAP_ALL und SAP_NEW können Sie einem User volle Berechtigungen für alle Transaktionen und Funktionen im SAP-System zuweisen. Dass die Profile ein enormes Sicherheitsrisiko darstellen, ist bekannt. Für Szenarien wie den Einsatz von Notfall-Benutzern oder für technische User werden sie dennoch oft benötigt. Wie Sie SAP_ALL und SAP_NEW richtig einsetzen, erfahren Sie hier.

Es ist verführerisch, wenn es gefühlt ewig dauert, korrekte Berechtigungen aufzubauen: SAP_ALL zuweisen und der User ist sofort arbeitsfähig. Keine Diskussionen, kein Analyse-Ping-Pong, keine ständigen Fehlermeldungen. Aber so einfach ist es nur bis zum nächsten Audit. Mit den Standard-Profilen SAP_ALL und SAP_NEW vergeben Sie Vollberechtigungen. Und das sollte – vor allem im Produktivsystem – die Ausnahme sein und nicht die Regel.

SAP_ALL und SAP_NEW – was ist der Unterschied?

SAP_ALL enthält Berechtigungen für alle Transaktionen und Objekte im aktuellen SAP-System.

SAP_NEW wird in der Regel zusammen mit SAP_ALL vergeben. Notwendig ist es aber vor allem, wenn Ihr System ein Update oder Upgrade erhält. SAP_NEW garantiert, dass alle User mit SAP_ALL auch dann arbeiten können, wenn durch das Update oder Upgrade neue Objekte und Transaktionen ins System kommen oder alte Standard-Werte geändert werden. Außerdem enthält SAP_NEW das Berechtigungsobjekt S_RFCACL, das Trusted RFC-Verbindungen berechtigt und in SAP_ALL nicht enthalten ist.

Wichtig: SAP_ALL und SAP_NEW sind Profile, keine Rollen. Sie können Rollen auf Grundlage beider Profile aufbauen oder die Profile über die Transaktion SU01 direkt im Benutzerstamm hinterlegen.

Wer darf SAP_ALL bekommen?

Das ist eine sensible Frage. Grundsätzlich sind beide Profile von der SAP nur für den kurzfristigen Einsatz gedacht – vor allem, wenn es um Produktivsysteme geht. Mit SAP_ALL und SAP_NEW kann ein User, wenn er weiß, was er tut, Ihr gesamtes System lahmlegen. Deshalb sollten normale Dialoguser niemals SAP_ALL oder SAP_NEW bekommen.

Dennoch gibt es Szenarien, in denen SAP_ALL und SAP_NEW häufig vergeben werden. Zum Beispiel für Firefighter – also Benutzer, die nur im Notfall genutzt werden dürfen und deren Aktionen protokolliert werden. Auch Technische User sind häufig mit SAP_ALL und SAP_NEW ausgestattet, um zu verhindern, dass beispielsweise wichtige Hintergrundjobs nicht durchlaufen können. Aber gerade bei Technischen Usern lassen sich Berechtigungen sauberer umsetzen!

Berechtigungsfehler trotz SAP_ALL: Woran liegt das?

Grundsätzlich hat ein User mit SAP_ALL und SAP_NEW also quasi Vollberechtigung. Trotzdem kann es vorkommen, dass ein User über diese Profile verfügt und trotzdem Berechtigungsfehler auftauchen, so dass er nicht weiterarbeiten kann.

User will Trusted RFC-Verbindung nutzen

Wenn der User versucht, über eine Trusted RFC-Verbindung auf ein anderes System zuzugreifen, braucht er entsprechende Ausprägungen im Berechtigungsobjekt S_RFCACL und zwar sowohl im Zielsystem als auch im Quellsystem. Weil dieses Objekt falsch genutzt zu großen Sicherheitslücken führen kann, ist es im Profil SAP_ALL nicht enthalten.

Hat der User also nur SAP_ALL und ist S_RFCACL in keiner ihm zugewiesenen Rolle in der passenden Ausprägung enthalten, kann er nicht auf das Zielsystem zugreifen.

Durch die zusätzliche Vergabe von SAP_NEW können Sie das Problem umgehen, denn hier ist S_RFCACL enthalten. Aber wie gesagt: Sie öffnen damit ein potenzielles Sicherheitsrisiko.

Alternativ können Sie in der Tabelle PRGN_CUST den Schalter ADD_S_RFCACL auf „Yes“ setzen. Diese Tabelle enthält Werte für das Berechtigungscustomizing. Der oben genannte Schalter ist per default auf „no“ eingestellt. Setzen Sie ihn auf „Yes“, ist S_RFCACL auch in SAP_ALL enthalten.

SAP_ALL ist nicht (re)generiert

Damit SAP_ALL funktioniert, muss es generiert werden. Normalerweise ist das nicht ihr Problem als Berechtiger, denn wenn Sie einem Benutzer das Profil zuweisen können, ist es auch im System aktiv (also generiert). Allerdings muss SAP_ALL nach jeder Änderung neu generiert werden, damit es den neuen Systemstand umfasst. Wenn also neue Transaktionen oder Berechtigungsobjekte ins System kommen, muss SAP_ALL neu generiert werden, um diese einzuschließen.

Das Generieren geschieht entweder manuell über die Transaktion SU21. In diesem Fall generieren Sie SAP_ALL in jedem Mandanten jedes Systems einzeln. Oder Sie nutzen den Report AGR_REGENERATE_SAP_ALL, mit dem Sie SAP_ALL mandantenübergreifend für mehrere Mandanten gleichzeitig generieren können. Eine weitere Alternative ist der Schalter SAP_ALL_GENERATION in der Tabelle PRGN_CUST. Mit SAP_ALL_GENERATION: ON sagen Sie dem System, dass es SAP_ALL automatisch generieren soll, wann immer neue Objekte importiert werden.

System erhält ein Update/Upgrade

Technische User, die während eines System-Updates oder -upgrades eingesetzt werden, brauchen zusätzlich zu SAP_ALL unbedingt auch SAP_NEW. Vergessen Sie das und es kommen neue Funktionen, Transaktionen, Programme oder Objekte ins System, die während des Updates oder Upgrades relevant sind, läuft der User auf Fehler. Die SAP empfiehlt allerdings, SAP_NEW wieder zu entziehen, sobald die Aktualisierungen abgeschlossen und SAP_ALL neu generiert ist.

User will Z-Objekte oder -transaktionen nutzen

SAP_ALL und SAP_NEW sind Standard-Profile der SAP und umschließen per default deshalb auch erstmal nur Standardfunktionen und -transaktionen. Deshalb kann es passieren, dass User mit SAP_ALL und SAP_NEW keine Berechtigungen für kundeneigene Transaktionen und Objekte haben.

Auch dieser Fehler wird in der Regel durch eine Generierung von SAP_ALL behoben, denn das Profil schließt mit der Generierung immer ALLE Funktionen ein, die gerade im System verfügbar sind – also auch Z-Transaktionen und -Objekte. Alternativ können Sie auch hier mit einem Schalter in der Tabelle PRGN_CUST nachhelfen: Setzen Sie ADD_ALL_CUST_OBJECTS auf „Yes“, werden automatisch alle kundeneigenen Objekte in SAP_ALL aufgenommen. Aber Achtung: Das gilt nur, solange die Objekte und Transaktionen sich an den Namenskonventionen orientieren, wonach kundeneigene Entwicklungen mit Z_ oder Y_ beginnen!

Gut zu wissen: In neueren Releases müssen Sie sich um diesen Berechtigungsfehler nicht mehr sorgen. Hier sind die kundeneigenen Objekte per default in SAP_ALL enthalten.

SAP_ALL einschränken: Geht das?

SAP_ALL und SAP_NEW sind ein Sicherheitsrisiko und werden spätestens bei einem Audit zum Problem (übrigens auch, wenn Sie die Profile kopieren und Ihnen nur einen anderen Namen geben – Auditoren sind klüger!) Aber ohne Vollberechtigungen verursachen Technische und Notfall-Benutzer im Zweifel Fehler, die viel Zeit und Geld kosten können.

Sauber lässt sich dieses Problem nur mit einem umfassenden Berechtigungskonzept lösen, in dem Sie genau erfassen, analysieren und berechtigen, was wirklich benötigt wird. Doch das ist zeitaufwendig und ob etwas fehlt, merken Sie manchmal erst zu spät.

Als (kurzfristige) Kompromisslösung können Sie eine eigene Rolle erstellen, die auf SAP_ALL beruht, aber besonders kritische Funktionen nicht erlaubt. Dazu zählen zum Beispiel das Löschen von Änderungsbelegen, Systemberechtigungen oder die Änderungsberechtigung im Debug-Modus. Bauen Sie dafür in der PFCG eine Rolle auf, deren Berechtigungen Sie aus SAP_ALL ziehen. Anschließend schränken Sie manuell die kritischen Berechtigungsobjekte ein.

Ein Kommentar zu “SAP_ALL und SAP_NEW richtig nutzen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert