SAP Debug Berechtigung S_DEVELOP einschränken

Autor: Tobias Harmes | 17. Februar 2012

11 | 16 | #PFCG, #RedesignBerechtigungen, #SUIM

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”.

Unser E-Book zu SAP GRC

E-Book SAP GRC

Roadmap zur Einführung Ihrer individuellen SAP GRC-Lösung - warum GRC mehr als nur lästige Pflicht ist.

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.

Berechtigung einschränken

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)

Sie benötigen Unterstützung bei der Umsetzung? Unser Autor ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Berechtigungen und Security


Artikel war hilfreichArtikel empfehlen


Dieser Beitrag ist auch als Download verfügbar:
Tobias Harmes

Autor

Tobias Harmes

Experte, Speaker, Herausgeber rz10.de

Fragen? Anmerkungen?
Kontaktieren Sie mich

11 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

Kommentar verfassen


Unsere Top-Downloads

Angebot anfordern
Expert Session