Risikoanalyse mit dem Report »Kritische Berechtigungen« durchführen
Dateneigentümerkonzept
In der alltäglichen Rollenpflege kommt es häufig dazu, dass Sie die Berechtigungsdaten einer Einzelrolle erneut ändern müssen, nachdem Sie die Rolle zusammen mit den generierten Berechtigungsprofilen bereits in einem Transportauftrag aufgezeichnet haben. Bisher mussten Sie in diesem Fall einen neuen Transportauftrag anlegen, weil bei jeder Einzelrollenaufzeichnung auch die Tabellenschlüssel der generierten Profile und Berechtigungen aufgezeichnet, aber bei späteren Änderungen der Rollendaten nicht angepasst werden.
Arbeiten Sie auch in einer komplexen Systemlandschaft, in der die Rollen dezentral gepflegt werden? Dann kann es durch den Transport von Profilen aus unterschiedlichen Systemen in ein Zielsystem zu Inkonsistenzen kommen. Wir zeigen Ihnen, wie Sie das verhindern. Bei dezentraler Pflege der Berechtigungsrollen, d. h. einer Pflege der Rollen in unterschiedlichen Systemen bzw. Mandanten, besteht das Risiko, dass sich die Nummernkreise für die Generierung von Berechtigungsprofilen überlappen. Sie können dann zu unterschiedlichen Rollen in unterschiedlichen Mandanten Profile mit gleichem Namen generieren. Sobald Sie diese gleichnamigen Berechtigungsprofile in ein gemeinsames Zielsystem transportieren, wird das bisherige Profil durch das neu importierte Profil überschrieben, und es entstehen Inkonsistenzen. In der Konsequenz kann es passieren, dass Sie beispielsweise einer ERP-Berechtigungsrolle ein SCMBerechtigungsprofil zuweisen. Dies kann dazu führen, dass ein Benutzer, dem die ERP-Rolle zugewiesen ist, nicht die benötigten oder sogar zu viele Berechtigungen erhält. Außerdem haben Sie ein Problem, falls Sie über das Berechtigungsprofil das Quellsystem und den Mandanten ermitteln wollen, in dem dieses Profil generiert wurde. Dies ist nicht möglich, wenn das erste und dritte Zeichen der SAP-System-ID (SID), und der Nummernkreis für die Generierung des Berechtigungsprofils übereinstimmen.
Welche Herausforderungen können nicht allein mithilfe von Berechtigungstools gelöst werden?
Versucht nun ein Benutzer, einen Bericht auszuführen (z. B. mithilfe der Transaktion KE30) werden die Berechtigungen des Benutzers für dieses Berechtigungsobjekt geprüft. Daher müssen Sie Ihre Berechtigungsrollen entsprechend anpassen. Fehlt dem Benutzer die Berechtigung zum Zugriff auf das Objekt, wird seine Anforderung abgelehnt. Hat er eine entsprechende Berechtigung, wird die Anzeige auf den erlaubten Bereich eingeschränkt. Für alle Merkmale oder Wertfelder, die nicht als Felder des Berechtigungsobjekts definiert wurden, ist der Zugriff weiterhin erlaubt.
In der SU53 erhalten Sie den Eintrag des Benutzers, der dort gepeichert ist, und dieser kann ggf. alt sein. Besser ist also den Benutzer selbst über das Menü den Berechtigungsfehler anzeigen zu lassen. Vielleicht erstellen Sie allen Ihren Benutzern eine kleine Doku, wie er sich den Fehler anzeigen läßt, und wo er ihn hinschicken kann, also ein „Kochrezept: How To…“. In dem Fehlerauszug der SU53 werden als erstes die dem Benutzer fehlende Berechtigung angezeigt. Dieses Objekt gilt es also zu analysieren. Im Weiteren der Fehlermeldung werden die dem Benutzer zugeordneten Berechtigungen angezeigt. Diese Informationen kann man dazu benutzen, den Benutzer mit seinem Rollenset einzuordnen, wohin er gehört etc. Letztlich haben wir in unserm Fall 1 nun die fehlende Berechtigung und müssen nun klären, ob der Benutzer diese Berechtigung erhalten soll oder nicht. Dazu muss die Fachabteilung kontaktiert werden, die ja zu entscheiden hat, ob der Benutzer die Berechtigung erhält! Es kann vorkommen, dass es sich bei dem vom Benutzer gemeldeten Problem gar nicht um ein Berechtigungsproblem handelt. Dann wird in dem SU53 – Bereich der letzte Berechtigungsfehler angezeigt, der gar nicht die Fehlerursache ist. Deshalb ist es immer gut, sich auch ein Bildschirmbild der eigentlichen Fehlermeldung schicken zu lassen. Es kommt gar nicht so selten vor, dass Entwickler aus ihren Programmen einen Berechtigungsfehler der Art „Keine Berechtigung für…“ ausgeben, dieser aber gar nicht mit einer standardmäßigen Berechtigungsprüfung geprüft haben, so dass der Fehler kein eigentlicher Berechtigungsfehler ist.
Sichern Sie Ihren Go-Live mit "Shortcut for SAP systems" zusätzlich ab. Notwendige SAP Berechtigungen können Sie schnell und unkompliziert direkt im System zuweisen.
Für das Szenario des Versands von Initialpasswörtern ist die Signierung von E-Mails nicht so relevant.
Über die Zentrale Benutzerverwaltung (ZBV) werden Benutzer angelegt, Rollen zugeordnet und in die jeweiligen Tochtersysteme verteilt.