SAP-Berechtigungen – Eine gemeinsame Perspektive von Entwicklern und Beratern

Zwischen SAP Berechtigungsberatern und ABAP Entwicklern besteht seit langer Zeit Uneinigkeit darüber, wie Berechtigungsobjektausprägungen im Coding umzusetzen sind. Dabei gibt es zwei Positionen:

Zum einen wird von Consultants geraten, niemals auf das Signalwort DUMMY, die Konstante space oder das Literal ‘ ‘ zu testen. Diese Tests prüfen nur oberflächlich auf die Existenz eines Berechtigungsobjektes und reagieren nicht auf Einstellungen in der Feldausprägung im Profil der Rollen. Außerdem wird dann das Literal ‚ ‘ berechtigt, da es in der Transaktion STAUTHTRACE angezeigt wird. 

Zum anderen gibt es Situationen, in denen die Entwicklung diese oberflächlichen Tests nutzt, um dem User Zeit und der Maschine Ressourcen zu ersparen. Stellt das Programm frühzeitig fest, dass der User nicht die nötigten Objekte im Benutzerpuffer hat, kann es vor dem ersten SELECT abbrechen und eine entsprechende Fehlermeldung ausgeben. 

Beide Positionen enthalten einen wahren Kern. Schauen wir uns die Auswirkungen verschiedener Programmierungen an einem vereinfachten Beispiel an. Die Rolle(n) besitzen dabei ausschließlich das Berechtigungsobjekt S_DEVELOP mit der Feldausprägung DEVCLASS „Z*“.

ABAP Coding Ausgabe in STAUTHTRACE Technische Prüfung
AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ FIELD “.

S_DEVELOP DEVCLASS ‘ ‘

Eine beliebige Ausprägung des Objektes berechtigt
AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ FIELD space.

S_DEVELOP DEVCLASS ‘ ‘

Eine beliebige Ausprägung des Objektes berechtigt
AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ FIELD ‚ ‚.

S_DEVELOP DEVCLASS ‘ ‘

Eine beliebige Ausprägung des Objektes berechtigt
AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ DUMMY.

S_DEVELOP DEVCLASS

Eine beliebige Ausprägung des Objektes berechtigt
DATA field TYPE char255.

AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ FIELD field.

S_DEVELOP DEVCLASS ‘ ‘

Eine beliebige Ausprägung des Objektes berechtigt
AUTHORITY-CHECK OBJECT ‚S_DEVELOP‘

 ID ‚DEVCLASS‘ FIELD ‚DUMMY‘.

S_DEVELOP DEVCLASS DUMMY

ABAP Coding ist falsch. Hier muss das nicht existierende Literal ‚DUMMY‘ berechtigt werden

 

Diese Art der Programmierung ergibt Sinn, wenn große Datenmengen gelesen werden müssen. Bevor nun begonnen wird die Daten von der Datenbank zu lesen, kann mit einer DUMMY – Prüfung schnell ersichtlich werden, ob der User überhaupt eine Berechtigung besitzt, um auf einen Teil der Daten zuzugreifenWie aber aus der obigen Tabelle ersichtlich wird, darf ein Coding nicht nur durch eine allgemeine Prüfung abgesichert sein, sondern muss durch spätere, detaillierte Prüfungen ergänzt werden. Allerdings muss auch in diesem Kontext space (oder ‘ ‘) nicht explizit berechtigt werden. Für die allgemeine Prüfung aus dem Beispiel genügt die Ausprägung:

Abb. 1: Ausschnitt aus der Transaktion PFCG

Steht im Berechtigungstrace der Wert „DUMMY“ in einer der fünf oberen Zeilen, so ist das ABAP Coding dringend anzupassen.

Aus dem obigen Beispiel wird deutlich, dass beide Seiten aufeinander zugehen müssen. Zum einen dürfen Berechtigungsberater nicht alles berechtigen, was in der STAUTHTRACE angezeigt wird. Zum anderen müssen die Entwickler nach einem anfänglichen, oberflächlichen Berechtigungscheck noch die einzelnen Berechtigungen explizit prüfen.