Die kritische Transaktion SE16N !

SE16N, die kritische Transaktion

Heute möchte ich Sie mit einer neuerdings (ECC6.0) sehr kritisch gewordenen Transaktion bekannt machen:

Für die Transaktion SE16N gibt es auch 2 Funktionsbausteine SE16N_INTERFACE und UA_SE16N_INTERFACE.
Alle Funtionen können für das Lesen einer Tabelle problemlos angewendet werden.

Nun kann man aber sowohl die SE16N als auch die beiden Funktionsbausteine auch zur Pflege einer Tabelle benutzen. Es gibt bei den Funktionsbausteinen ein sog. Update-Flag, das man einschalten kann, um die Pflege zu erlauben.

In der ECC6.0 haben sich die Entwickler aber dazu entschlossen, im Pflegefall das System die volle Berechtigung für das Debuggen streng abfragen zu lassen, und nur beim Vorliegen aller 3 Aktivitäten 01,02,03 auf  OBJECTTYP=DEBUG die Pflege der Tabelle zuzulassen.

Dies bedeutet,  dass man jedem Benutzer der SE16N im Falle der Pflege das Objekt

S_DEVELOP ACTVT=01,02,03 OBJECTTYP=DEBUG

zuordnen müsste.

Jeglicher Schutz wäre somit aufgehoben. Auch eine Revision würde eine derartige Rolle nicht durchlassen.

Was bewirkt S_DEVELOP im System?
Einerseits ist es performancerelevant, da ein Benutzer, der in den DEBUG-Modus geht, nicht mehr den Arbeitsbereich des Systems wechseln kann. Bei gehäuftem Auftreten von DEBUG-Modi, kann das System sogar zum Stillstand kommen.

Andererseits bewirkt die Vergabe von vollen DEBUG-Rechten die völlige Öffnung des System, was zu Daten-Schiefständen und zum Verlust der Integrität der Daten führen kann. Zwar werden Veränderungen unter Debug-Modus protokolliert, doch was hilft dies, wenn z.B. Summierungsfelder betroffen sind?

Der einzige Ausweg der bleibt, ist entweder, falls die Transaktion bzw. das Programm mit dem Baustein, nur an Administratoren vergeben werden soll, dieses Recht nur für kurze Zeit zu vergeben, oder die Programme müssen umgeschrieben werden.

Beim Umprogrammieren, kann man sich mit einen Aufruf der Transaktion SM30 behelfen, da die Funktion CALL TRANSACTION nicht wie der Transaktionsstart im OK-Code das Berechtigungsobjekt S_TCODE abfrägt.

D.h.  man muss dem Benutzer nicht das Recht auf die SM30 vergeben, was ggf. aus anderen Gründen schadhaft sein könnte.  Da innerhalb der Transaktion SM30 die Berechtigung auf die Pflege der Tabelle (S_TABU_DIS) abgeprüft wird, kann man so einen Schutz nur für diese Tabelle aufbauen. Außerdem ist es möglich, eine Selection der Daten über Varianten in der Transaktion zu steueren.

Mir ist leider kein anderer Weg bekannt,  die veränderte Abprüfung der SE16N-Pflege revisions- und prüfungssicher zu umgehen.
Ich stellle diese Aussage aber gerne zur Diskussion. Wer also eine andere Idee der Lösung hat, könnte sie ja der Gemeinschaft posten!

Mit herzlichen Grüßen

Bernd Klüppelberg

Schreiben Sie bitte einen Kommentar





SAP Berechtigungen, -Konzepte, -Technik | System Beratung Bernd Klüppelberg