Identifizieren von Kundenentwicklungen in SAP

Zu allererst möchte ich mit einem Missverständnis aufräumen: nicht alle kundeneigenen Objekte im SAP müssen mit Y* oder Z* beginnen.
Es gibt diverse weitere Möglichkeiten der Benennung, von denen einige nicht offensichtlich sind – und so z.B. dafür verwendet werden können, bösartigen Code zu verstecken.
Oder hätten Sie den Report MSTHRP9INT als eine Kundenentwicklung erkannt und entsprechend geprüft?

Eine der größten Stärken von SAP ist die Möglichkeit, den Softwarestandard durch eigenen Code an den Stellen zu erweitern, an denen Customizing allein nicht reicht.
Die Schattenseite dieser Flexibilität ist wiederum, dass so Kunden-Objekte ins Produktivsystem gelangen, die möglicherweise nicht den strengen Anforderungen entsprechen, die das Unternehmen oder externe Guidelines fordern. Hier ist auch der Auditor gefragt, nur muss dieser auch in der Lage sein, Kundenentwicklungen zielsicher identifizieren zu können.

Doch beginnen wir am Anfang:
Eigene Workbench-Objekte (vereinfacht: Eigenentwicklungen), wie Reports, Tabellen, Funktionsbausteine, usw. dürfen nicht beliebig benannt werden. Vielmehr gibt es eine strenge Vorgabe seitens der SAP, die den verwendbaren Namensbereich für Kundenobjekte regelt.

//Exkurs: Namensraum vs. Namensbereich

• Ein Namensraum ist ein Präfix für Eigenentwicklungen, der offiziell bei der SAP reserviert werden muss, bevor er freigeschaltet und verwendet werden kann. Unterhalb dieses Namensraumes können dann Objekte nach dem Schema /NAMENSTRAUM/MEINOBJEKT angelegt werden. Dies garantiert global eindeutige Namen und erlaubt es, diese Entwicklungen garantiert ohne Konflikte an Kunden weitergeben zu können.
• Ein Namensbereich steht für einen Bereich von Namen, z.B. A bis M* oder Z* für alle Objekte beginnend mit „Z“. Dieser Begriff dient allein der Abgrenzung gegenüber dem bereits belegten „Namensraum“.

Der offizielle SAP Hinweis

Der SAP Hinweis 16466 gibt Aufschluss darüber, welche Namensbereiche je nach Objekttyp verwendet werden dürfen. Die Differenzierung nach Objekttypen ist notwendig, da verschiedene Bereiche für z.B. Transaktionscodes einerseits und Reports andererseits erlaubt sind.

Wir schauen uns im Folgenden einige gängige Objekte an, die für Angreifer interessant sind und mit denen Daten-Manipulationen möglich sind oder Hintertüren gebaut werden können. Dies sind ABAP Reports, Tabellen sowie Transaktionscodes (über die z.B. S_PROGRAM Berechtigungsprüfungen umgangen werden können).

Der genannte SAP Hinweis listet folgende Regeln zu diesen drei Typen:

Auszug aus SAP Hinweis 16466

Weiterhin heißt es:

Die SAP-Namenskonventionen sind unbedingt einzuhalten! Anderenfalls kann es beim Upgrade zu gravierenden Problemen kommen. (Kundenobjekte werden überschrieben.)

… dazu am Ende des Artikels mehr!

Um die Einschränkung der Namensbereiche zu verstehen, wollen wir uns nun anschauen wie diese umgesetzt sind:

Immer, wenn ein neues Objekt – bspw. ein Report – angelegt wird, wird der gewählte Name im Hintergrund von einem zentralen Funktionsbaustein gegen das Regelwerk für Kunden-Namen geprüft.

Dieser SAP-Funktionsbaustein heißt TRINT_GET_NAMESPACE und unterscheidet generell zwischen 3 Arten von Namensbereichen:

• Kunden-Objekte
• Partner- und
• SAP-Objekte

Für Partner- und SAP-Objekte benötigt man einen separaten Objektschlüssel – um diese Typen soll es hier aber nicht gehen.

Bei Kundenobjekten finden wir das Regelwerk im Quellcode des Funktionsbausteines.

Um nicht zu technisch zu werden (und da der Quellcode keinen Schönheitswettbewerb gewinnen würde), fasse ich in den folgenden Tabellen die Regeln für unsere 3 Objekttypen – Reports, Tabellen, Transaktionscodes – zusammen:

Namensbereiche Reports

Reports 1

Reports 2

Namensbereiche Tabellen

Tabellen

Namensbereiche Transaktionscodes

Transaktionscodes

Fazit

Insgesamt hat ein Entwickler also die Wahl aus ganzen 47 Namensbereichen für ABAP-Programme!

Diese Namensbereiche müssen auch alle im Change-Prozess, z.B. bei einer Codeprüfung, abgedeckt werden und sind ebenso relevant für Auditprüfungen. Erschwerend kommt hinzu, dass sich auf dem Entwicklungssystem Attribute, wie z.B. der Anleger oder letzte Änderer eines Reports, relativ einfach manipulieren lassen.

Kommen wir nun zu der Aussage aus dem Hinweis zurück:

Die SAP-Namenskonventionen [aus dem Hinweis] sind unbedingt einzuhalten! […]

E-Book SAP GRC

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

Jetzt anfordern

E-Book SAP GRC

×

Diese Aussage würde bedeuten, dass wir z.B. nur Y* und Z* Reports anlegen dürften und nicht die 45 anderen Bereiche ausschöpfen dürften. Dies widerspricht aber nicht nur der Realität auf produktiven SAP-Systemen, sondern hat noch eine weitere Schwäche: es handelt sich um eine Vorgabe, die im System abweichend umgesetzt ist: der Funktionsbaustein lässt weitere Möglichkeiten zu und die wurden und werden verwendet. Zudem muss bezweifelt werden, dass im Rahmen von Upgrades andere Kundennamensbereiche vorausgesetzt werden, als vom Funktionsbaustein, den wir oben betrachtet haben.

Zu guter Letzt: wenn es stimmen würde und ein Upgrade solche Kunden-Objekte überschreiben würde, dann gäbe es aus Sicht der Nachvollziehbarkeit sogar ein noch größeres Problem – es würde im schlimmsten Falle bösartiger Code im Upgrade überschrieben.

Viel Spaß beim Prüfen!