SAP Risikominimierung
Autor: Andre Tenbuss | 10. Mai 2013
Mit diesem HowTo möchte ich Ihnen aufzeigen, wie kritisch die Vergabe der Berechtigungen zum Aufruf der Transaktionen SA38 und SE38 in einem produktiven SAP-System unter Umständen sein kann. Anwender sollten in produktiven SAP-Systemen nicht die Berechtigung haben Programme über die SA38 bzw. die SE38 auszuführen, da hier nur schwer einzuschränken ist, welche unter Umständen auch sicherheitskritischen Programme aufgerufen werden können. In der Praxis kommt es jedoch häufig vor, dass für bestimmte Anwendungsfälle die Berechtigung zum Start der SA38 bzw. der SE38 an Benutzer vergeben wird.
Download des Artikels mit zusätzlichem Inhalt
Laden Sie diesen kompletten Beitrag “HowTo: SAP Risikominimierung durch fehlende Berechtigungsgruppen von Programmen und Tabellen” als PDF herunter, inklusive zusätzlichen Beispielen und Tipps zur Analyse.
Die erforderlichen Berechtigungsobjekte zum Aufruf der Transaktion SA38 sind in der unten dargestellten Grafik abgebildet. Die beiden Berechtigungsobjekte S_TCODE und S_PROGRAM werden bei Aufruf der Transaktion geprüft. Bei dem Berechtigungsobjekt S_PROGRAM wird allerdings nur das Feld P_ACTION auf den Feldwert SUBMIT (Ausführen ABAP Programm) geprüft. Das Feld P_GROUP wird an dieser Stelle noch nicht geprüft. Dieses Feld dient zur Einschränkung der Programmausführungsberechtigung auf die in der Tabelle TPGP angelegten Berechtigungsgruppen.
Abbildung 1: Erforderliche Berechtigungen zum Aufruf der Transaktion SA38
Risiko 1: Fehlende Berechtigungsgruppen bei Programmen
Ruft der Benutzer nun die Transaktion SA38 auf, kann er grundsätzlich, wie in Abbildung 2 dargestellt, den Namen jedes beliebigen Programms in das Feld “Programm” eintragen. Ruft der Benutzer nun ein Programm auf, prüft das SAP-System, ob eine Berechtigungsgruppe in den Eigenschaften des Programms festgelegt wurde. Ist dies der Fall, dann wird über das Feld P_GROUP des Berechtigungsobjekts S_PROGRAM geprüft, ob der Benutzer die entsprechende Berechtigungsgruppe aufrufen darf. Sicherheitskritisch ist jedoch die Tatsache, dass der Benutzer unabhängig von den in seinen Berechtigungen definierten erlaubten Berechtigungsgruppen sämtliche Programme ausführen kann, die keine definierte Berechtigungsgruppe haben. Wenn wir die in Abbildung 1 dargestellte Beispielrolle an einen Benutzer vergeben, dann könnte dieser den Report RK_SE16N aufrufen, welcher sich hinter der Transaktion SE16N verbirgt.
Abbildung 2: SA38 Programmausführung von RK_SE16N
In der Regel sind Benutzer in produktiven SAP-Systemen nicht über das Berechtigungsobjekt S_TCODE berechtigt, die Transaktion SE16N auszuführen. Benutzer, welche unter anderem über die Ausführungsberechtigung der SA38 verfügen, können aber das Programm RK_SE16N jedoch wie in den Abbildungen 2 und 3 dargestellt trotzdem aufrufen, da üblicherweise keine Berechtigungsgruppe vergeben ist.
Abbildung 3: Report RK_SE16N bzw. Transaktion SE16N
Risiko 2: Fehlende Berechtigungsgruppen bei Tabellen
Bei Aufruf einer Tabelle wird zusätzlich das Berechtigungsobjekt S_TABU_DIS und dessen Feld ACTVT (Aktivität) geprüft. Auch bei diesem Berechtigungsobjekt verhält es sich analog zur S_PROGRAM-Berechtigung so, dass nur bei Tabellen mit gepflegter Berechtigungsgruppe auch das Feld DICBERCLS (Berechtigungsgruppe) geprüft wird. Alle Tabellen ohne Tabellenberechtigungsgruppe können entsprechend der erlaubten Aktivität angezeigt (03) oder geändert (02) werden.
Abbildung 4: Berechtigungsobjekt S_TABU_DIS (Tabellenpflege)
Empfehlung
Option 1. Wenn Sie die Vergabe der Transaktion SA38 bzw. SE38 weitestgehend vermeiden möchten, dann können Sie über die Transaktion SE93 für erforderliche Programme eine Transaktion anlegen. Diese Transaktion können Sie dann in den Berechtigungsrollen der Benutzer über das Berechtigungsobjekt S_TCODE berechtigen.
Option 2. Da ein Bedarf, Benutzer für den Aufruf der Transaktion SA38 bzw. SE38 zu berechtigen unter Umständen gegeben sein kann, bleibt noch die Option, für Programme und Tabellen ohne Berechtigungsgruppe eine Berechtigungsgruppe zu definieren. Das mag auf den ersten Blick, in Anbetracht der Menge von Programmen und Tabellen ohne eine entsprechende Einstellung sehr aufwendig wirken, kann jedoch die Wirksamkeit der Berechtigungen und damit die Sicherheit der Systeme enorm steigern. Für Programme und Tabellen ohne Berechtigungsgruppe kann beispielsweise eine beliebige Berechtigungsgruppe angelegt und vergeben werden. Die relevanten Tabellen, in denen Sie die Zuordnungen der Berechtigungsgruppen finden können, finden Sie nachfolgend aufgelistet.
Tabellenübersicht
Programme. Hier finden Sie die Tabellen, welche im Zusammenhang mit Berechtigungsgruppen für Programme relevant sind.
TPGP: Hier können Sie vorhandene Berechtigungsgruppen einsehen und einfügen. Alternativ lassen sich Berechtigungsgruppen auch über das Programm RSCSAUTH pflegen.
TRDIR: In dieser Tabelle sind alle Programme (Feld: NAME) mit den entsprechenden Berechtigungsgruppen (Feld: SECU) verzeichnet.
Tabellen. Hier finden Sie die Tabellen, welche im Zusammenhang mit Berechtigungsgruppen für Tabellen relevant sind.
TBRG: In der Tabelle TBRG können Berechtigungsgruppen für Tabellen (Objekt: S_TABU_DIS) angelegt werden.
TDDAT: Eine Zuordnung von Tabellen zu Berechtigungsgruppen können Sie in dieser Tabelle einsehen und ändern.
Was sind Ihre Erfahrungen zu SAP Risikominimierung?
2 Kommentare zu "SAP Risikominimierung"
Zu Option 2:
Verstehe ich das richtig, um das über Berechtigungsgruppen zu managen, muss ich erstmal alle SAP Standard und Z- Reports mit einer Berechtigungsgruppe versehen. Im Anschluss definiere ich dann über s_program welche Berechtigungsgruppen erlaubt sind? Wenn dem so ist, dann noch 2 Fragen:
In der Tabelle TRDIR stehen wirklich alle Reports die gepflegt werden müssen? Oder wie bekomme ich das raus? Mein Versuch mit der se38 über * die Anzahl der Reports zu ermitteln endeten mit einem Kurzdump.
Ist es ratsam dann wirklich alle Reports mit einer Berechtigungsgruppe zu versehen und diese erstmal zu verbieten (Freigabe nach dem Minimalprinzip)! Oder besteht dann die Gefahr, dass im Hintergrund plötzlich Prozesse nicht mehr funktionieren, weil die Reports ja quasi erstmal für alle gesperrt sind ( wenn ein Sachbeabeiter z.B. ein Prozess anstößt welcher im Hintergrund ein Report anstartet)
Danke für eine Antwort 🙂
Hallo Herr P.,
vielen Dank für Ihre Frage. Ja, Sie haben die Option 2 korrekt verstanden. Wenn die Anlage von Transaktionen zu einem Report keine Option ist, dann bleibt lediglich die Definition von Berechtigungsgruppen für die Reports. Es handelt sich hierbei um verschiedene Herangehensweisen. In der Tabelle TRDIR stehen alle Reports, die gepflegt werden müssen. Wenn die Abfrage der Tabelle zu einem Kurzdump führt, dann müsste man zunächst ermitteln, ob dies auf Grund einer Zeitüberschreitung, eines Pufferüberlaufs oder z.B. eines Syntaxfehlers geschieht. Im Falle eines Pufferüberlaufs oder einer Zeitüberschreitung bleibt noch der Weg sich mit “A*”, “B*” u.s.w. durchzuhangeln. Alternativ könnten Sie natürlich die entsprechenden Parameter erhöhen.
Sie fragen, ob es ratsam ist, wirklich alle Reports mit einer Berechtigungsgruppe zu versehen. Wenn ich die Wahl habe zwischen Option 1 (Transaktion für Report anlegen) und Option 2 (Vergabe von SA38/SE38 und Vergabe von Berechtigungsgruppen), dann empfehle ich Option 1. Grund dafür ist die Tatsache, dass bei Option 2 auch regelmäßig geprüft werden muss, ob ggf. neue Reports ohne Berechtigungsgruppe in das System transportiert worden sind.
Bei Option 2 kann es durchaus vorkommen, dass auf Grund von fehlenden Berechtigungen nach Änderung der Berechtigungsgruppe eines Reports Probleme auftreten können. Ein Ansatz könnte hier sein: Analyse aller vergebenen Berechtigungsrollen (Aktivitätsgruppen) mit dem Objekt S_PROGRAM, Aktivität SUBMIT und leerem Feld P_GROUP. In alle diese Rollen können Sie vorab bereits den Namen der neuen Berechtigungsgruppe eintragen und anschließend die Berechtigungsgruppen der Reports ändern.
Ich hoffe, dass ich Ihnen weiterhelfen konnte. Für weitere Fragen stehe ich natürlich gerne zur Verfügung.
Viel Erfolg und beste Grüße, Andre Tenbuß