SAP Softwaresicherheit: Optionen und Risiken bei „Call Transaction“
Autor: Yannick Rech | 21. März 2023
Die erste Berechtigungsprüfung, die SAP-Anwender beim Aufruf einer Transaktion immer überstehen müssen, ist die Prüfung auf den Transaktionscode. Es sei denn, sie landen in der Transaktion durch den ABAP-Befehl „CALL TRANSACTION“, denn hier fehlt diese Eingangsprüfung. Welche Möglichkeiten und Empfehlungen gibt es, hier zum Beispiel bei S/4HANA Migrationen kein Schiffbruch zu erleiden?
Welche Sicherheitsproblematik steht hinter Call Transaction?
Mit dem ABAP Kommando CALL TRANSACTION kann aus einem ABAP-Programm eine andere Transaktion aufgerufen werden. Ursprünglich (im Default vor S/4HANA) war es so, dass diese Transaktion aus der anderen Transaktion heraus geöffnet werden konnte, ohne dass das Berechtigungsobjekt S_TCODE abgefragt wurde. Das heißt, dass eine unscheinbare Z-Transaktion in der Lage ist, kritische Transaktionen ohne entsprechende Prüfungen aufzurufen.
Möglichkeit im Code: WITH/WITHOUT AUTHORITY-CHECK
Um das zu kompensieren, wurde von seitens der SAP das Kommando CALL TRANSACTION mit einer Erweiterung versehen. Fortan war die Empfehlung ein WITH oder WITHOUT AUTHORITY-CHECK anzufügen. CALL TRANSACTION sollte nicht mehr ohne den Zusatz verwendet werden. Allerdings ist das weiterhin möglich.
Möglichkeit ohne Code-Änderung: SE97 und die Tabelle TCDCOUPLES
Der im Standard nicht gesetzte RZ10-Parameter auth/check/calltransaction ermöglicht seit einiger Zeit einen anderen Weg zur Lösung dieser Thematik. Damit können SAP Kunden ohne Code-Änderung geduldete Fälle via Tabelle konfigurieren. Die Transaktion SE97 ist eine Möglichkeit, die dafür notwendige Tabelle TCDCOUPLES zu pflegen.
Der Profil-Systemparameter auth/check/calltransaction hat dabei vier mögliche Ausprägungen:
0 – bedeutet, dass bei dem Transaktionsaufruf CALL TRANSACTION niemals (egal was in der SE97 steht) ein S_TCODE abgefragt wird
1 – bedeutet, dass bei dem Transaktionsaufruf CALL TRANSACTION immer (egal was in der SE97 steht) ein S_TCODE abgefragt wird
2 – bedeutet, dass die Eintragungen in der SE97 darüber entscheiden, ob eine Berechtigungsprüfung stattfindet. Steht in der SE97 zu der aufgerufenen Transaktion ein „Ja“ in der Spalte, wird der S_TCODE abgefragt, steht ein „nein“ oder „“ drin, wird der S_TCODE nicht abgefragt. Das bedeutet man muss aktiv das Ganze auf „Ja“ stellen, damit die Berechtigungsprüfung stattfindet
3 – bedeutet, dass die Eintragungen in der SE97 darüber entscheiden, ob eine Berechtigungsprüfung stattfindet. Steht in der SE97 zu der aufgerufenen Transaktion ein „Ja“ oder ein „“ in der Spalte, wird der S_TCODE abgefragt, steht ein „nein“ drin, wird der S_TCODE nicht abgefragt. Das bedeutet, man muss aktiv das Ganze auf „Nein“ stellen, damit die Berechtigungsprüfung nicht stattfindet. Ansonsten findet sie statt.
Nebenwirkungen von auth/check/calltransaction
Eine Änderung auf den strikten Wert 1 hat zur Folge, dass an den Berechtigungen zu SAP Standard-Transaktionen viel gewerkelt werden muss, da sich die SAP selbst auch nicht immer an die Regel hält einen S_TCODE-Prüfung zu fordern. Nicht wenige Kunden stellen dann den Profilparameter auf den Wert 2, als Ausweg aus einer Flut von plötzlichen Berechtigungsfehlern – sogar aus SAP Standardprogrammen.
Das ist De-Facto allerdings in unserer Beobachtung die Rückkehr zum alten unsicheren Standard (praktisch gleichbedeutend mit dem Wert 0). Jede Z-Transaktion kann dann als Wrapper für kritische Zugriffe missbraucht werden, da die Pflege der Tabelle den Z-Entwicklungen hinterherhinkt. Daher empfehlen wir aus Sicherheitsperspektive als Kompromiss den Wert 3: „Immer prüfen bis auf Ausnahmen“. Das kann dabei helfen, Zeit zu gewinnen, um etwaige Code-Changes und Berechtigungs-Ergänzungen umzusetzen.
Auszug aus der SAP-Doku
Beispiel für die Transaktion MIGO
Transaktion MIGO
In der Abbildung sehen wir die Transaktion SE97 für die MIGO in einem ECC 6.0 EHP 8 System. MIGO ist eine SAP Standard Transaktion. Alle hier benannten Transaktionen werden aus der MIGO per CALL TRANSACTION aufgerufen. Wir sehen, dass die Spalte Prüfkennz. Entweder mit „Ja“ oder „“ befüllt ist. Leere Werte („“) sind mit einer roten Ampel versehen. Es gibt kein ausgefülltes „Nein“ in der Spalte Prüfkennz..
Der Profil-Parameter ist hier auf den Wert 2 gesetzt. Das bedeutet, dass „Nein“ und „“ das gleiche sind und damit jede CALL TRANSACTION, für die ich nicht ausdrücklich „Ja“ ankreuze, nicht abgefragt wird.
Wenn ich den Parameter hier auf 3 umstellen würde, würden alle Prüfungen grün werden (und damit abgefragt werden). Außer die, die ausdrücklich mit einem „Nein“ versehen wurden.
Fazit
Die Sicherheitsbedingungen zu CALL TRANSACTION können bei Upgrades schnell Berechtigungsteams ins Schwitzen bringen. Zumal Berechtigungs-Admins oft keine Möglichkeit haben, zeitnah Code-Anpassungen zu fordern und von Berechtigungsnachforderungen überrollt werden. Der Weg über den Profilparameter auth/check/calltransaction mit dem Wert 3 kann helfen, für Fälle in Eigenentwicklungen Zeit zu gewinnen, ohne die unsicheren Altlasten für immer mit in die Zukunft zu nehmen.
Haben Sie weitere Fragen zum Thema oder Beratungsbedarf? Schreiben Sie uns gerne eine Mail an info@rz10.de oder fragen Sie ein unverbdindliches Erstgespräch an: hier anfragen.
