Area41 2024 - Ein Rückblick
Michael Schneider
In den 2000er Jahren habe ich im SAP R/3 Umfeld als Entwickler von einfachen Anwendungen auf der Basis von ABAP und Formularen mit SAPscript gearbeitet. Als SAP-Entwickler wird nebst Programmierkenntnissen auch betriebswirtschaftliches Wissen und Kenntnisse der Prozesse des eigenen Unternehmens benötigt, um nützliche Anwendungen für das Business schreiben zu können. IT-Security war damals nur ein Thema am Rande – obwohl sich in einem SAP-System wertvolle Unternehmensdaten befinden. Die Umsetzung von Sicherheitsmassnahmen beschränkte sich auf die Verwaltung und Zuteilung von Rollen und Berechtigungsobjekten. Eine Rolle umfasst dabei mehrere Berechtigungsobjekte. Eine Möglichkeit ist, diese Rollen in Gruppen wie HR, Finanzen oder Ein-/Verkauf aufzuteilen. Eine Gruppe von Benutzern lässt sich dabei nur schwer in ein solches Schema einteilen: Entwickler. Diese benötigen einerseits Rechte zur Entwicklung von Programmen sowie auch Zugriffe auf die auszuwertenden Daten. Nebst der Herausforderung, den Entwicklern die richtigen Berechtigungsobjekte zuzuteilen, gibt eine weitere Schwierigkeit, die eine grosse Tragweite auf die Sicherheit des Systems hat: zu verhindern, dass der Benutzer die vorhandenen Kontrollen umgehen kann.
Die meisten Programme in SAP R/3 basierten auf der Sprache ABAP und dementsprechend enthält das R/3 System eine umfangreiche Entwicklungsumgebung, mit Codeeditor und Debug-Möglichkeiten. Eine SAP-Systemlandschaft ist meistens dreistufig aufgebaut:
Ein Programm entsteht im Entwicklungssystem und wird durch das Transportsystem (Transaktionscode STMS) in die anderen Systeme transportiert. Ein Entwickler benötigt im Entwicklungssystem umfangreiche Berechtigungen, im Produktivsystem sollte er jedoch so wenig Rechte wie möglich haben.
In SAP besteht die Möglichkeit ein Programm durch die Verwendung von Breakpoints während der Laufzeit zu debuggen. Durch die Eingabe von /h
im Befehlsfenster kann der SAP Debugger während der Laufzeit einer Transaktion gestartet werden. Dies ist eine wertvolle Funktion zur Analyse von Programmen und sollte zu Testzwecken auch genutzt werden. Nebenbei kann der Debugger aber auch zur Umgehung von Sicherheitsmassnahmen missbraucht werden.
Kritische Daten und Funktionen sollten vor unberechtigtem Zugriff geschützt werden. Im Konzept von SAP werden dazu sogenannte Berechtigungsobjekte eingesetzt. Bei der Definition eines solchen Objekts werden Berechtigungsfelder zur genauen Steuerung der Berechtigungen verwendet. Wir erstellen als Beispiel ein solches Objekt namens Z_FIRMA
mit den Feldern ACTVT
und ZFRMID
. Das Feld ACTVT
steuert die Aktivität (Lesen, Schreiben) und ZFRMID
Zugriffe auf verschiedene Firmen (ID der Firmen). Ein Entwickler kann nun die Anweisung AUTHORITY-CHECK
und das Berechtigungsobjekt Z_FIRMA
nutzen, um in seinem Programm die Berechtigungen eines Benutzers zu prüfen. Der dazugehörige Code könnte wie folgt aussehen:
REPORT Z_SCIP_TEST. PARAMETERS p_zfrmid TYPE scarr-carrid DEFAULT 'SC'. AUTHORITY-CHECK OBJECT 'Z_FIRMA' ID 'ZFRMID' FIELD p_zfrmid ID 'ACTVT' FIELD '03'. IF sy-subrc = 0. SELECT ... ENDIF.
Bevor das Programm die Datenabfrage (symbolisiert mit SELECT ...
) ausführt, wird geprüft ob der Benutzer über die erforderlichen Rechte verfügt. Die Anweisung prüft im Benutzerstamm, ob der Benutzer das Berechtigungsobjekt mit der passenden Aktivität und der Firmen-ID zugewiesen hat. Wenn die Berechtigungsprüfung mit AUTHORITY-CHECK
erfolgreich ausfällt, hat die Systemvariable sy-subrc
den Wert 0. Bei fehlenden Rechten wird ein anderer Wert übergeben.
Diese Überprüfung kann mittels Debugger umgangen werden. Für jeden Aufruf von AUTHORITY-CHECK
kann im Debugger ein Breakpoint gesetzt werden. Das heisst, dass das Programm vor jeder Berechtigungsprüfung gestoppt wird, und der Programmfluss durch den Benutzer gesteuert werden kann. Der Benutzer führt die Funktion aus und kann danach den Wert von sy-subrc
auslesen und gezielt manipulieren. Sollte die Berechtigungsprüfung negativ ausfallen, kann der Benutzer den Wert auf 0 setzen, um dem Programm vorzugeben, dass er über die notwendigen Rechte verfügt, um die Daten anzusehen. Demzufolge hat jeder Benutzer mit Debug-Rechten die Möglichkeit implementierte Berechtigungsprüfungen zu umgehen. Vor allem im Produktivsystem sollten die Debug-Rechte dementsprechend sehr sorgfältig vergeben werden.
Nebst der Vertraulichkeit ist die Integrität von Daten ein essentieller Bestandteil der Sicherheit eines Systems. Ein SAP R/3 System verfügt über eine Änderungshistorie für Stammdaten, damit Änderungen aufgezeichnet und nachvollzogen werden können. Wenn nun zum Beispiel der Name eines Materials über die Transaktion MM02 geändert wird, erzeugt das System einen Änderungsbeleg, der unter anderem die Benutzer-ID des Benutzers enthält, welcher die Änderung durchgeführt hat. So kann nachvollzogen werden, wer zu welcher Zeit was geändert hat.
Mit der Transaktion SE16N können die Inhalte von Datenbanktabellen angezeigt werden. Durch die Eingabe &SAP_EDIT
im Befehlsfenster innerhalb der Transaktion kann ein Benutzer die Editierfunktion aktivieren und kann damit Daten auf Tabellenebene direkt verändern. Öffnet nun ein Benutzer die Tabelle MARA und ändert den Namen des Materials via &SAP_EDIT
, wird kein Änderungsbeleg erzeugt. Auch hier gilt das eine solche Berechtigung in einem Produktivsystem nicht vergeben werden sollte.
Diese zwei Beispiele zeigen auf, wie wichtig es ist ein Berechtigungskonzept detailliert zu planen und umzusetzen. Jeder Benutzer, auch privilegierte Benutzergruppen wie Entwickler oder Administratoren, sollten nur die absolut notwendigen Rechte erhalten. Diese Rechte sollten wiederum je nach System (Entwicklung, Produktiv) variieren. So braucht ein Entwickler in einem Produktivsystem keine Rechte um Programme zu entwickeln und zu debuggen. Diese Aufgaben können in den dafür vorgesehenen Systemen umgesetzt werden. Dies gilt für SAP- wie auch für alle anderen IT-Systeme.
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!