SAP und das Prinzip der geringstmöglichen Berechtigungen

SAP und das Prinzip der geringstmöglichen Berechtigungen

Michael Schneider
von Michael Schneider
Lesezeit: 6 Minuten

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.

SAP

Umgehen von Berechtigungsprüfungen mithilfe des Debuggers

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:

  1. Entwicklungssystem
  2. Testsystem
  3. Produktivsystem.

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.

Datenmanipulation auf Tabellenebene

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.

Das Prinzip der geringstmöglichen Berechtigungen

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.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

×
Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv