Zu umfangreiche Berechtigungen beim HR-Reporting verhindern
Eine Benutzergruppe als Pflichtfeld im Benutzerstamm definieren
Vereinfachen Sie Ihr Berechtigungskonzept nicht, bevor Sie alle Anforderungen kennen, sondern fragen Sie sich erst, was es zu erreichen gilt. Analysieren Sie also zunächst die Prozesse (wenn möglich auch technisch), und schaffen Sie erst dann ein Konzept. Viele Berechtigungskonzepte, die wir bei Kunden vorfanden, waren nicht dazu geeignet, den Anforderungen gerecht zu werden. Teilweise handelte es sich um »gewachsene« Berechtigungskonzepte (d. h., dass immer wieder Anforderungen hinzukamen) oder um gekaufte Berechtigungskonzepte. Vielen dieser Konzepte war gemeinsam, dass sie nicht einfach, sondern zu stark vereinfacht worden waren. Ein schönes Beispiel sind Berechtigungskonzepte, die alle Organisationsebenen in Werterollen oder Organisationsrollen zusammenfassen. Es gibt wenige Beispiele, wie z. B. den Rollenmanager der Branchenlösung SAP for Defense and Security, in denen das Ergebnis eines Werterollenkonzepts für den Benutzer noch sinnvoll und angemessen ist. Die Annahme, dass man »mal eben« alle Berechtigungsobjekte separiert, die eine Organisationsebene enthalten, ist zwar einfach, aber eben nicht sinnvoll. Die Vereinfachung, dass nur ein Benutzer ohne Berechtigungen definitiv keine rechtswidrigen Berechtigungen haben kann, haben wir in der Praxis nicht vorgefunden. Allerdings gab es immer wieder den Fall, dass Benutzer viel zu viele Berechtigungen besaßen und das System damit nicht mehr rechtskonform war.
RFC – Verbindungen sind gleichermaßen Schnittstelle für viele lokale und globale Systemprozesse, aber auch eine sicherheitsrelevante Fehlerquelle vieler Unternehmen. Die RFC Schnittstellen und dazugehörige Systembenutzer sind oftmals mit zu starken Berechtigungen ausgeprägt und können schnell von unberechtigten Personen missbraucht werden, um sensible Firmendaten einzusehen. Daher ist es wichtig, diese Systemverbindungen immer im Fokus des globalen Monitorings zu halten und zu prüfen, welche RFC Destinationen, wohin führen und was sie bewirken. Dafür gibt es das Programm RSRFCCHK wodurch Sie gezielte Tests für ihre RFC Systemlandschaft durchführen können. Dabei wird einerseits der Inhalt der Tabelle RFCDES geprüft und anderseits auch die dazugehörigen Benutzereigenschaften der Systembenutzer als Überblick dargestellt. Demzufolge können wichtige Parameter, wie die Zielmaschine, der Mandant, der Hintergrundbenutzer oder auch die Passworteigenschaft überblicksartig geprüft werden.
Berechtigungsobjekte
Um nun Vorschlagswerte für die neue Transaktion zu definieren, verwenden Sie die Transaktion SU24_S_TABU_NAM. In der Selektionsmaske können Sie entweder Ihre neue Z-Transaktion eingeben, oder Sie geben im Suchfeld Gerufene TA (gerufene Transaktion) die Transaktion SE16 ein. Daraufhin wird nach allen Parametertransaktionen gesucht, in denen die Transaktion SE16 verwendet wird. In der Ergebnisliste finden Sie alle Parametertransaktionen, die die Transaktion SE16 als aufrufende Transaktion verwenden. Die letzten beiden Spalten geben an, ob für die Berechtigungsobjekte S_TABU_DIS oder S_TABU_NAM Vorschlagswerte in der Transaktion SU24 gepflegt sind.
Schauen Sie sich den Sicherheitshinweis genau an, damit Sie die betroffenen Programme bzw. Funktionen identifizieren und entsprechende Anwendungstests einplanen können. Nutzen Sie eine Testimplementierung in der Transaktion SNOTE, um weitere SAP-Hinweise zu identifizieren, die Voraussetzung für einen Sicherheitshinweis sind und ebenfalls funktionale Änderungen enthalten können.
Berechtigungen können auch über "Shortcut for SAP systems" zugewiesen werden.
Einmal umgesetzt, lassen sich Rollen mit ihren Berechtigungen schnell auf die neue Region ausrollen.
Eine Rolle, die Sie als Design-Time-Objekt im Design Time Repository erstellt haben, müssen Sie aktivieren, bevor diese einem Benutzer zugeordnet werden kann.