Was ist das Risiko bei einer so genannten Debug-Replace-Berechtigung? Wie kann man diese Berechtigung in Rollen identifizieren beziehungsweise welche Ausprägungen von dem relevanten Berechtigungsobjekt S_DEVELOP erzeugen ein Risiko?
Über das Berechtigungsobjekt S_DEVELOP kann man Debugging-Berechtigung im SAP erteilen. Diese Berechtigung erlaubt es über die Eingabe von “/h” im OK-Feld der Gui den Debug-Modus zu aktivieren.
Während diese Funktion auf dem Entwicklungssystem ohne Frage zu den notwendigen Entwicklungsfunktionalitäten dazugehört ist es auf einem Produktions- oder Konsolidierungssystem höchst kritisch. Denn es erlaubt dem Anwender den normalen Programmablauf zu beeinflussen und Werte während des Programmlaufs zu ändern.
So kann ein Anwender ein Programm starten und z.B. einen AUTHORITY-CHECK überspringen. Damit erlangt er Zugang zu Daten oder kann Änderungen vornehmen, die im normalen Programmfluss nicht vorgesehen sind.
Ein prominentes Beispiel ist auch über den Debug-Modus das sapedit in der SE16 bzw. SE16N wieder zu aktivieren – dann kann man direkt in der Tabellenansicht Änderungen in der Datenbank durchgeführen. Diese Möglichkeit Felder zu ändern gefährdet den Grundsatz “Keine Änderung ohne Beleg”.
Wie kann man nun S_DEVELOP einschränken?
Zuerst muss man die Rollen identifizieren, die S_DEVELOP mit DEBUG Aktivität 02 enthalten. Dies kann man über die SUIM -> Rollen nach komplexen Selektionskriterien durchgeführt werden. Wenn man den Debug-Modus komplett deaktiveren will, muss man auch nach Aktivität 03 suchen.
Im Rolleneditor in der PFCG kann man nun die entsprechende Rolle einschränken.
Im Hinweis 65968 – ABAP-Debugging-Berechtigungen werden die möglichen Werten für S_DEVELOP dokumentiert:
| OBJTYPE | ACTVT |
| DEBUG | 03 – Anzeigen |
| DEBUG | 02 – Ändern von Feldinhalten und ‘Zu Anweisung springen’ |
| DEBUG | 01 – Kernel-Debugging (für Kunden nicht relevant, nur für SAP-interne Zwecke) |
Auch das Berechtigungsobjekt S_DBG beachten
Ab dem ABAP Release 7.57 steht zusätzlich das Berechtigungsobjekt S_DBG zur Verfügung. Dieses erlaubt eine feinere Steuerung der Änderungsberechtigungen im Debugger. Sind beide Berechtigungsobjekte für einen Benutzer konfiguriert, so erhält der Benutzer die jeweils höherwertige Berechtigung aus beiden Berechtigungsobjekten.
S_DBG kann also schnell eine übersehene Hintertür zu kritischen Berechtigungen werden. Details zu dem Berechtigungsobjekt gibt es ebenfalls in 65968 – ABAP-Debugging-Berechtigungen.
15 Kommentare zu "SAP Debug Berechtigung S_DEVELOP einschränken"
Hallo,
ist es möglich auf eine bzw. gewisse Tabellen einzuschränken?
Hallo.
Allgemein kann man mit dem Berechtigungsobjekt S_TABU_DIS oder S_TABU_NAM die Berechtigungen auf spezielle Tabellen einschränken. Da das Debugging aber an solchen Prüfungen vorbei läuft, gibt es keine mir bekannte Möglichkeit Debug Berechtigung in Abhängigkeit von den gerade verwendeten Tabellen zu steuern.
Mit freundlichen Grüßen
Tobias Harmes
Hallo!
Wie stehen Sie zu dem SAP-Hinweis 1420281 (CO-OM-Tools: SE16N: Abschalten von &SAP_EDIT)?
Ist damit dieses Thema überhaupt noch “aktuell”?
Hallo.
Das Abschalten von der Funktion &SAP_EDIT ist einer der Punkte die durch Debug-Änderungsberechtigungen umgangen bzw. manipuliert werden kann. Darum ist die Einschränkung dieser Berechtigungen vor allem im Produktivsystem absolut notwendig.
Mit freundlichen Grüßen
Tobias Harmes
Vielen Dank, hab ich verstanden 🙂
Hallo,
s_develop hat ja viele Einstellung. Kann man diese so beschränken, das man nur die Möglichkeit sperrt zu entwickeln im System.
MfG
J. Schneider
Hallo Herr Schneider.
Ja, das können Sie. Z.B. können Sie einen Entwickler tracen (ST01 oder STAUTHTRACE) um genaue Ausprägungen für S_DEVELOP zu ermitteln. Die Änderungsberechtigung für DEBUG darf aber in produktionsnahen Systemen nicht vergeben werden.
Mit freundlichen Grüßen,
Tobias Harmes
Hallo,
kann ich nachträglich prüfen ob irgendwelche Felder während des Debuggens geändert wurden?
MfG
C. Clages
Hallo. Sie können das SysLog (Transaktion SM21) prüfen, denn dort wird dieser Vorgang in den Standard-Einstellungen mit User aufgezeichnet. Beispiel-Einträge:
Springe zu Anweisung:
A23 Sprung im ABAP Debugger: Source:(53)->(57) | ByteCode:comp(18
A14 > in Programm MS38MI00 , Zeile 0057, Ereignis EXIT
Feldwertänderung:
A19 Feldinhalt verändert: FCODE -> AAAA
A14 > in Programm MS38MI00 , Zeile 0057, Ereignis EXIT
MfG Tobias Harmes
Wenn der SAL (SM20) auf dem Applikationsserver gelöscht wurde, gibt es dann alternativ eine Möglichkeit ohne den Syslog (SM21) Codesprünge zu identifizieren?
Hallo,
wenn sowohl SAL als auch das Syslog nicht mehr verfügbar sind, ist uns keine allgemeine Möglichkeit bekannt, wie Codesprünge identifiziert werden können. Um hier weiterhelfen zu können, wäre es sinnvoll einmal individuell auf das System zu schauen und insbesondere für zukünftige Vorfälle eine Ablagestrategie für die SAL-Logs aufzusetzen.
Wenn Sprünge im Code möglich sind, ist es ohnehin nicht möglich, selbst mit angeschalteten Logs mit absoluter Sicherheit sagen zu können, wenn jemand im Code springt. Geschickte Angreifer sind ebenfalls in der Lage diese Systematik zu umgehen. An der Stelle ist die Empfehlung, dass alle Berechtigungen hierfür im produktiven Umfeld nicht vergeben werden sollte.
Viele Grüße
Guten Tag, ich habe eine Folgefrage zu diesem Thema und hoffe, die Anfrage erreicht Sie noch. Ich habe in unserem SAP das Objekt S_DEVELOP mit den Ausprägungen
– ACTVT 02, 03, 07, 16
– DEVCLASS = Z_xxxxxxx
– OBJNAME = Z*, xxxxx, yyyyy
– OBJTYPE = [diverse]
Ein Prüfer ist nun der Meinung, dass dennoch eine umfassende Möglichkeit zur manipulativen Änderung besteht. Bewirken denn die Einschränkungen auf die DEVCLASS und OBJNAME nichts?
Vielen Dank für eine Antwort,
Peter
Hallo Peter, hier nochmal die Antwort unseres Experten:
“Zumindest wenn unter den Ausprägungen von OBJTYPE auch der Wert DEBUG ist, halte ich die Ausprägung für sicherheitstechnisch bedenklich. Auch die Ausprägung der ACTVT 16 ist aus Security-Sicht nicht unbedenklich. Das sollten wir uns gerne in einem Gespräch mal im Detail anschauen.”
Sie können uns diesbezüglich auch gerne anrufen (0211 9462 8572-25) oder eine Mail an info@rz10.de schreiben.
Viele Grüße!
Hallo zusammen,
ist es aus compliance Sicht kritisch in einem SAP Produktivsystem das Berechtigungsobjekt S_DEVELOP, Aktivität 02, Objekttyp (alles außer DEBUG) an mehrere User zu vergeben. Falls ja, welche Kontrollmaßnahmen sollten in diesem Zusammenhang zusätzlich implementiert werden?
Hallo, hier die Antwort unserer Experten:
“Wir würden zumindest davon abraten, das so zu vergeben. Es gibt in einem Nicht-Entwicklungssystem keinen Anlass, etwas an Entwicklungen zu ändern (Actvt 02). Solche Änderungen sollten per Transport ins Produktivsystem gebracht werden. Ohne Anlass sollte die Berechtigung dann gemäß Minimalprinzip nicht vergeben werden.
Unter S/4HANA fallen die Entwicklerschlüssel weg: https://rz10.de/sap-berechtigungen/entwicklerschluessel-faellt-weg-in-sap-s-4hana-ein-sicherheitsrisiko/
Damit beruht der Schutz der Entwicklungen stärker auf dem Berechtigungsobjekt.”
Viele Grüße aus der RZ10-Redaktion