Kommen wir heute zum zweiten schwierigeren Fall der Fehleranalyse.
Ein Benutzer hat im Gegensatz zu Fall 1 nun zu viele Rechte! Er darf in der Transaktion xy bestimmte Dinge ausführen, für die er aber nicht berechtigt sein soll. .
Jetzt geht es an die Rollen selbst und an die in den Rollen vergebenen Berechtigungen. Hierbei sind mehrere Fälle denkbar: Der Benutzer hat
- zu viele Rechte bei den Organisationsebenen (Buchungskreis, Werk, etc)
- zu viele Rechte bezüglich der Berechtigungsobjekte, die in der Rolle sind. Z.B. er soll keine Kreditoren anzeigen dürfen.
- zu viele Rechte Transaktionen aufzurufen.
Je nachdem welche Rechte zu viel sind, muß die Analyse zunächst bei den zugeordneten Rollen beginnen. Schaut man sich zunächst mit der SU01 an, welche Rollen der Benutzer besitzt, kann man hier vielleicht schon einen Fehler bei der Rollenzuordnung erkennen.
Vielleicht muß man eine bestehende Masterrolle nur nochmals nach einen anders Org-Level ableiten, um ihm die Rechte zu nehmen. Oder es ist z.B. eine Valuerolle zu viel zugeordnet.
Hat der Benutzer dann immernoch zu viele Rechte, kann es sein, dass man die Rollen anpassen muß. D.h. man muß evtl. die Rolle aufteilen, ihr Objekte oder Transaktionen nehmen und diese einer anderen Rolle zuordnen. Manchmal muß man diese Analyse bis auf die Berechtigungsobjekte in der Rolle herunterbrechen, wenn man das Berechtigungsobjekt, das zu viel ist überhaupt schon identifiziert hat.
Es gibt verschiedenste Hilfsmittel mit denen man bei Kenntnis des Brechtigungsobjekts prüfen kann, in welchen Rollen dies vorkommt und wie es bewertet ist, so z.B. die Transaktion:
S_BCE_68001425 Rollen nach komplexen Suchkriterien (auch zu finden unter Werkzeuge / Administration / Benutzerpflege / Infosystem / Rollen)
Hier können Sie nach dem Vorkommen des Berechtigungsobjektes mit einer Bewertung suchen. Sie erhalten alle Rollen angezeigt, in denen das Berechtigungsobjekt mit der Bewertung vorkommt. Dies und das Wissen um den Aufbau und die Namensgebung der Rolle reichen meist schon aus, die richtige Rolle auszuwählen.
Manchmal ist es so, dass der Benutzer in der Transaktion etwas darf und Sie wissen nicht mit welchem Berechtigungsobjekt das zusammenhängt. Bei über 120.000 Transaktionen kann einem schon einmal eine aus dem Sinn geraten 
Was dann noch beleibt ist der sog. Berechtigungstrace.
Beim Berechtigungstrace ruft man die Transaktion ST01 auf und führt mit dem Benutzer einen Trace durch. D.h. Sie schalten den Trace auf den Benutzer beschränkt ein, dann führt der Benutzer die Transaktion von vorne her (also Transaktionsstart /nxxx) nochmals durch. Der Benutzer muss die Transaktion beenden, dann wird erst der letzte Satz für die Transaktion in den Trace geschrieben.
Nun haben Sie alle aufgerufene Transaktionen und Berechtigungsprüfungen aufgezeichnet. Schalten Sie den Trace in der ST01 aus und analysieren Sie den Trace.
Anhand eines solchen Traces läßt sich nun erkennen, welche Rechte durchlaufen wurden, und welche dem Benutzer zu viel vergeben wurden. Wenn es ganz schlimm kommt, müssen Sie in dem System, wo auch die – oder ähliche – Daten liegen, einen Testbenutzer anlegen, und mit dem Test-User dann die Richtigkeit des zugeordneten Rollensets analysieren.
[Hinweis: Dies ist z.B. ein Fall, wo in einem Integrations- oder Test-System, dem Rollenadministrator das Recht zum Anlegen von Benutzern vergeben werden sollte, um die Fehleranalyse nicht durch Bürokratie künstlich zu verlängern]
Insbesondere eignet sich der ST01-Trace auch für Sie selbst, um festzustellen, was in einer Transaktion wie geprüft wird. Diese Traces führen Sie aber bitte nur ausnahmsweise im Produktionsystem durch.
Letzlich wird die Analyse zeigen, ob Sie eine Rolle in 2 Rollen mit fast gleichen Rechten aufsplitten müssen, oder ob der Fehler mit einer einfachen Zuordnungsänderung gelöst werden kann. Es kann aber auch sein, dass Sie den Fehler mit den vorhandenen Mitteln gar nicht lösen können. Dies bedeutet dann zum Beispiel, dass Sie ein neues eigenes Berechtigungsobjekt brauchen, mit dem Sie die Transaktion steuern können.
Neue Objekte müssen in der Transaktion aber auch abgeprüft werden, sonst habe sie keinen Erfolg. Deshalb müssen Sie in einem solchen Fall mit der Entwicklung zusammen nach sogenannten User-Exists in der Transaktion Ausschau halten, in denen dann ein neues Objekt geprüft werden kann.
Ist kein User-Exit vorhanden, haben Sie nur die Wahl entweder eine Modifikation des Systems durchzuführen (die schlechteste aller Lösungen) oder irgendwie auf organisatorischer Weise den Fehler zu beseitigen. Diese Fälle kommen zum Glück nur sehr selten vor, denn meist gibt es einen Weg, mit dem man Rechte beschränken kann.
In weiteren Beiträgen werde ich später auch typische Berechtigungsbeschränkungen und ihre Bewertungen in Rollen darstellen, weil man immer wieder, genau an der Stelle nicht weiss, wie die Tranaktionen prüfen. Z.B. wie muss die Rolle bewertet werden, wenn man einen Benutzer nur freischalten darf und nur sein Passwort zurücksetzen darf. Was ggf. ja ein Hotliner können soll, er aber ansonsten keine Userrechte besitzt.
Liebe Grüße
Bernd Klüppelberg
Diesen Artikel mit anderen teilen:
Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
Filed under: Berechtigungsobjekt | No Comments »
