Ein Kollege von mir hat mich auf ein interessantes Verhalten bei einer SAP Parametertransaktion für die SE16 (Tabellenanzeige / Data Browser) hingewiesen. Parametertransaktionen erlauben bestimmte Transaktionen mit Parametern vorzubelegen – dies ermöglicht die Nutzung von an sich kritischen Transaktionen wie der SE16, weil der Anwender direkt auf die gewünschte Tabelle oder View geleitet wird. Es gibt aber Situationen, wo dieser Mechanismus fehlerhaft oder nicht wie erwartet reagiert.
Szenario 1
Die Parametertransaktion enthält einen fehlerhaften Parameter – z.B. eine Tabelle, die nicht mehr existiert. Im Screenshot sieht man die Parametertransaktion ZSE16_MISSING, die auf die nicht existente Tabelle “MISSING” verweist.
Wenn der Anwender die Transaktion ZSE16_MISSING aufruft landet er in der SE16 – und hat damit die Möglichkeit andere Tabelle aufzurufen – sofern seine Berechtigungen dies erlauben. De fakto hat ein Anwender damit aber eine vollwertige SE16, ohne dass dies jemand erfährt oder dies durch Reports sichtbar wird.
Szenario 2
Es wurde die richtige Tabelle bei der SAP Parametertransaktion angegeben – aber es wurde die Tabellen-Berechtigungsgruppe nicht richtig konfiguriert. In dem Beispiel hat der Anwender die Berechtigung auf die ZSE16_AGR_DEFINE – aber in seinen Systemrollen nicht die notwendige Tabellenberechtigungsgruppe “SC” (S_TABU_DIS->DICBERCLS, Zuordnungsübersicht in Tabelle TDDAT). Auch in diesem Fall wird der Anwender auf die SE16 zurückgeworfen und kann diese nun im Rahmen seiner sonstigen Berechtigungen nutzen.
In dem Strategieworkshop SAP Berechtigungen entwickeln wir für Sie eine Strategie zur Optimierung der SAP Sicherheit und Reduzierung der Betriebsaufwände.
Fazit
Beide Szenarien sind real und bei einem meiner Kunden aufgetreten. Das Risiko von Szenario 1 ist meines Erachtens relativ gering, da eher selten ganze Tabellen gelöscht werden. Szenario 2 dagegen birgt aus meiner Sicht hohes Risiko. Denn bei jeder Berechtigung der SAP Parametertransaktion muss sichergestellt werden, dass der Rolle auch sofort die richtige Tabellenberechtigung hinzugefügt wird. Sollte das vom Berechtigungsadministrator übersehen werden, dann wird einem Endbenutzer eine vollwertige SE16 gewährt. Zuverlässige Abhilfe dafür wäre die sorgfältige Pflege der SU24, damit beim Hinzufügen der Transaktion in einer Rolle gleich die richtigen Vorschlagswerte in das Berechtigungsprofil eingesteuert werden.
5 Kommentare zu "Gefahren einer SAP Parametertransaktion"
Kennt jemand das Problem, dass beim Erstellen einer Parametertransaktion aus SE16 in der PFCG die Vorschlagswerte aus SE16, also S_TABU_DIS angezeigt werden, obwohl das Berechtigungsobjekt S_TABU_DIS in der Tabelle USOBT_C nicht gepflegt ist. Ich möchte erreichen, dass mein Eintrag der Z-Transaktion in die PFCG nur das Berechtigungsobjekt S_TABU_NAM vorgeschlagen wird. Hat jemand eine Idee?
Hallo Frau Ernst.
Der Vorschlag von S_TABU_DIS ist für die SE16 direkt verdrahtet. Sie können Ihre Z-Transaktion in der SU24 pflegen. Dort können Sie sogar gleich den richtigen Wert für S_TABU_NAM pflegen. Zukünftige Verwendungen der Transaktion in der PFCG benötigen so keine zusätzliche Pflege im Berechtigungseditor mehr.
MfG Tobias Harmes
Das Risiko von Szenario 2 sollte wegfallen wenn man statt S_TABU_DIS S_TABU_NAM verwendet. Dann sollte der Fehler auch ‘nur’ beim Fehlen der Tabelle auftreten.
Vielen Dank für den Hinweis auf S_TABU_NAM. Szenario 2 spricht explizit von einer (versehentlichen) Fehlkonfiguration der Berechtigung. Auch bei S_TABU_NAM könnte ich einen falschen Tabellennamen angeben – besonders bei kryptischen Tabellennamen, die sich nur in einem Buchstaben unterscheiden. Oder auch beliebt: 0 (Null) vs. O (O wie Otto).
Es gibt noch einen Fallstrick in dieser Art. Ruft man eine Tabelle mit mehr als 40 Feldern
in der SE16 zum ersten Mal(!) auf, dann meldet das System, dass die Selektionsfelder
begrenzt werden müssen und bietet einen Auswahldialog über die Felder an. Diesen
kann man aber abbrechen und landet dann ebenfalls im Einstiegsbild der SE16. Das
gilt natürlich auch für den Umweg über eine Parametertransaktion.
Wurde aber einmal eine Menge von Feldern für die Selektion festgelegt, dann gilt
diese ja für alle User (da ist dann diese unschöne Arbeitsweise der SE16 mal von
Vorteil). Da man hoffentlich als Entwickler/Admin zumindest einmal seine Sachen
selbst ausprobiert, bevor man die weitergibt, ist das Ganze aber wohl noch
akademischer als Ihr erstgenanntes Szenario. Erwähnen kann man es aber.