SAP® und Transaktionen – was die Berechtigungsprüfung so schwierig macht… Teil 3

Aus analytischer Sicht empfehle ich Ihnen als Einstieg in das Thema zunächst den Teil 2 – Mengengerüst: Module zu lesen. Dort habe ich dargestellt, wie man den Transaktionen Module zuordnet. In der unten verlinkten Excel-Datei habe ich aus Gründen der Performance mittels MS® Excel „Einfügen“ > „Wert“ die Formeln aufgelöst und die Erkenntnisse des vorherigen Artikels in den Spalten B bis F ausgeblendet. Diese können Sie dann weiterverwenden. Und ja – MS® Excel ist nicht das Mittel der Wahl für derartige Analysen, aber im Unternehmen sollte jeder von Ihnen darüber verfügen. 

Für die weiteren Darstellungen habe ich die Tabellen TSTC und TSTCP in die verlinkte MS® Excel-Datei integriert. Diese finden Sie nicht nur in der beigefügten Excel, sondern die Daten habe ich auch in die Tabelle „Vollständige Sicht“ mit Formeln angefügt. Dazu gilt wie bisher: Wer das nachvollziehen will, kann die eigenen Daten (inkl. Y und Z) integrieren. Dies gilt auch für Release-Stände, die nicht unserer Version EHP8 entsprechen.

Dementsprechend finden Sie in Spalte G das direkt aufgerufene Programm bzw. in Spalte H das erste aufzurufende Dynpro – also in der SAP-Sprache ein „Dynamisches Programm“. Es besteht aus einem Bildschirmbild mit seinen Bildschirmelementen und der Ablauflogik. Dies ist also umgangssprachlich der Einstiegsbildschirm. Es ermöglicht Ihnen nicht nur die Transaktionen, sondern auch genau diese Bildschirme bei Bedarf zu vergleichen.

Um das Thema Mengengerüst nochmals aus fachlicher Sicht zu analysieren, habe ich in den Spalten I bis L die entsprechenden Informationen aufbereitet – das Gesamtergebnis finden Sie auch aggregiert und damit filterbar in Spalte M:

Für die Betrachtung der Kritikalität der Transaktionen muss man sich natürlich nicht nur die einzelne Transaktion vor Augen halten, sondern auch die Ausweichmöglichkeiten, die im Unternehmen ggf. genutzt werden, um das Konzept zu umgehen – Stichwort „ich will ja nur arbeiten“.

Kritikalität der Parametertransaktionen an Beispielen verdeutlicht

Betrachten wir aus Blick eines Revisors einmal ein paar Beispiele, um die Schwierigkeiten der Analyse zu fassen:

Fall 1 – Der Klassiker: Beleg buchen

Unzweifelhaft wird man als Revisor auf die User schauen, die entsprechend Belege verarbeiten können. Unabhängig von den angrenzenden Themen, wie Vier-Augen-Prinzipien und Workflow-Steuerung, Kompetenzen und eingestellte Toleranzen, ist alleine diese Transaktion einen Blick auf die User wert. Soweit das Basiswissen.

Fall 2 – Die Ausweichtransaktion: Beleg buchen

Genauso spannend sind aber die umgrenzenden Transaktionen – und ich spreche jetzt noch nicht einmal von Belegänderungen oder Vorerfassungen – sondern von der exakten Abbildung der Transaktion, allerdings mit einer vorgeschalteten Parametertransaktion.

Werfen wir gemeinsam einen Blick in die Tabelle TSTCP, die ich ebenfalls in der Excel abgebildet habe. Die Transaktion ABAD verweist per Parameter auf die FB01 – das typische „/N“ habe ich oben im Modell zur besseren Lesbarkeit einmal abgetrennt. Mit der Eingabe von ABAD erreichen Sie also den gleichen Effekt, als wenn Sie im Dialog die „/N“ in Kombination mit der FB01 eingeben, allerdings mit einer anderen Beschriftung in der Kopfzeile des Programms SAPMF05A:

Fazit daraus: Es ist vollkommen unerheblich, ob Sie eine Buchung mit der Transaktion ABAD oder der FB01 durchführen – es hängt von den weiteren Berechtigungsobjekten ab, ob der User vollständig in der Finanzbuchhaltung buchen darf oder ob dies auf die Anlagenbuchhaltung beschränkt ist.

Für das alltägliche Prüfungsgeschäft heißt das, wenn Sie mit manuellen Prüfungen unterwegs sind: Sie müssen alle Transaktionen und Parameter extrahieren, die genau den gleichen Zugriff auslösen als wenn Sie die Transaktion direkt ausführen würden. Ein schnödes Abprüfen der FB01 mittels des Reports „RSUSR002 – Benutzer nach komplexen Berechtigungswerten“ reicht also nicht (weitere Details siehe Abschnitt Parametertransaktionen und Prüfungen).

Fall 3 – ABAP/4 Reporting

In den R/2-Zeiten als ABAP mit „Allgemeiner Berichts-Aufbereitungs-Prozessor“ beschrieben werden konnte, war eine Transaktion SA38 vielleicht auch nicht schön (ggf. waren die Worte ‚Data-Leakage-Prevention‘ und ‚Gesetz zum Schutz von Geschäftsgeheimnissen‘ noch nicht so geläufig wie heute), aber grundsätzlich einmal unkritisch, weil keine datenverändernden Funktionen implementierbar waren.

Spätestens als sich ABAP mit R/3 zur „Advanced Business Application Programming“-Language weiterentwickelte, hatte das „Reporting“ aus Prüfersicht eine komplett andere Bedeutung. System --> Dienste --> Reporting ließ auf einmal alles das zu, was einen Prüfer aufhorchen ließ: Daten ändern, Massendaten überschreiben, ja sogar Programme ließen sich eine Zeit ausführen, um auf die Betriebssystemebene zu gelangen. Ergo entstand aus der prüfenden Sicht heraus die Notwendigkeit, nicht mehr alle Reports ausführen zu lassen, sondern diese über Berechtigungsgruppen oder Einzeltransaktionen weiter zu beschränken.

Und zum Prüfungsalltag gehört seitdem die zu diskutierende Frage: „Warum hat der User XYZ eigentlich noch volle Rechte zum Ausführen einer SA38?“. Ergo prüfen Sie dies manuell natürlich ab.

Fall 4 – Offene Zahlungsläufe suchen

Die Transaktion SA39 verweist auf den SAP Report SAPMS38M – die Kurzbeschreibung dazu lautet „SA38 für Parametertransaktion“. Auch das sieht zuerst einmal unkritisch aus, wenn da nicht der kleine Haken wäre, dass es bei Administrationsfehlern ein Vollzugriff auf die gesamte Programmlandschaft gäbe. Betrachten wir einmal die beiden Transaktionen EWFM und EWFZ. Auf der aktuellen EHP8-Maschine unterscheiden sich diese in der Transaktionstabelle nicht – es sind beides Parametertransaktionen, allerdings mit einem kleinen, aber feinen Unterschied in der Tabelle TSTCP:

EWFM

/*SA39 RS38M-PROGRAMM=RFEWC150;

EWFZ

/NSA38 RS38M-PROGRAMM=RFEWC110;

Die Ausführung der Transaktion EWFM führt direkt in das Programm RFEWC150 aufgrund der Parametrisierung /*SA39:

Der (sicherheitstechnisch unbefriedigende) Zugriff über die Transaktion EWFZ führt aufgrund der Parametrisierung /NSA38 in die Maske des Reportings, wo Sie das Programm nochmals bestätigen und ausführen müssen:

Und nach der Programmausführung steht Ihnen auch die gewünschte Funktion zur Verfügung:

Und wieder: Was lernen wir für die tägliche Prüfung daraus? Erstens ist der Parameteraufruf für die EWFM noch in älteren Versionen mit /NSA38 in der TSTCP enthalten (prüfen Sie also ggf. einmal genau diesen Eintrag) und zweitens – und das ist das Entscheidende: Der Controller, der im Rahmen der Hauswährungsumstellung eigentlich die „Prüfung, ob alle Zahlungsläufe abgeschlossen sind“ durchführen soll, hat einen Vollzugriff auf die komplette Bibliothek des Reportings mit ggf. datenverändernden Funktionen.

Fall 5 – „Große Umsatzprobe“

Und noch ein weiterer Revisionsklassiker, der Ihnen die Funktionsweise der mit DIREKTPARAMETER gekennzeichneten Transaktionen beispielhaft erläutern soll:

Das in der Transaktion hinterlegte Programm SAPMS38M dient dazu, die Parameter zu übergeben und das dort zu findende Programm SAPF190 zu starten:

Dies könnten Sie also genauso mit einer Transaktion SA38 und der Eingabe von Hand, wie dargestellt, erreichen. Der Unterschied zu Fall 1 und 2 besteht allerdings darin, dass jetzt nicht eine Transaktion, sondern direkt ein konkretes Programm ausgeführt wird.

Und by the way: Der User wird auch nicht durch Pflichteinträge in der TSTCA gehindert, die Transaktion F.03 auszuführen – das haben Sie bestimmt auf dem Schaubild bemerkt.

Parametertransaktionen und Prüfungen…

Und wieder die Frage: Was lerne ich daraus für meinen Prüfalltag, wenn ich keine Software zur Prüfung der Berechtigungen einsetze?

Sie müssen sich ggf. noch tiefer damit befassen, was die Administration alleine an Einstiegsbildschirmen freigegeben hat: Man kann nicht einfach unterstellen, dass eine Transaktion genau einem Einstiegsbildschirm entspricht. Analysieren Sie also alle vorkommenden Transaktionen auf derart ungewollte Ausreißer. Und denken Sie bitte immer daran: Der Mensch sucht sich seine Wege – „ich will ja nur arbeiten, was interessieren mich Berechtigungen und Mechanismen“. Ich denke, dass Sie diese Argumentation aus der Fachabteilung auch kennen.

Frei nach dem nicht ernst gemeinten Motto: „SAP_ALL für alle, dann stehen die Prozesse wenigstens nicht wegen Berechtigungen“.

Was haben wir für uns daraus abgeleitet: Für die Entwicklung von addCube SoDRisk haben wir uns eine extrem aufwändige VBA-Programmierung erstellt, die genau diese Problematik der Parameter-Transaktionen abfängt. Um bei dem Beispiel FB01 zu bleiben: Schauen Sie bitte einmal in die MS® Excel-Datei – dort finden Sie 123 Beispiele, mit denen Sie das Programm SAPMF05A mit unterschiedlichen Einstiegsbildschirmen aufrufen können – also zumindest Teile eines Buchungsbeleges erfassen können.

• Die Excel-Datei zum Beitrag finden Sie hier. (16,9 MiB)

Wie geht es weiter?

Und in den nächsten beiden Beiträgen geht es dann tatsächlich um die Pflichtobjekte der TSTCA, die weiteren Objekte, die Unschärfen der Blaupause USOBT und die Möglichkeit, alles zu „tracen“.

• Teil 4 – Pflichtobjekte und Blaupausen (hier geht es zum Beitrag)

• Teil 5 – „Tracen“ – den SAP-Berechtigungen auf der Spur (hier geht es zum Beitrag)

Vorangegangene Beiträge dieser Reihe

• Teil 1 – Die Prüfungswelt der SAP-Berechtigungen (hier geht es zum Beitrag)

• Teil 2 – Mengengerüst aus Modulsicht (hier geht es zum Beitrag)

Dieser Blogartikel wurde von Mitarbeitern der addKnowledge GmbH erstellt und dient Ihrer allgemeinen Information. Alle Rechte und Pflichten diesbezüglich obliegen der addKnowledge GmbH.

SAP, SAP Logo, R/3, ABAP sind Marken oder eingetragene Marken der SAP® SE und unterliegen daher dem Copyright.