P_ABAP die zweite: Vereinfachungsgrad 1
Im letzten Artikel haben wir über die Gefahren unbeaufsichtigter P_ABAPs mit Vereinfachungsgrad 2 gesprochen. Doch auch die gezähmte Version mit Vereinfachungsgrad 1 hat immer noch genügend Zähne und Hörner, um seine Aufgaben zu erfüllen – und um aus seinem Käfig auszubrechen. Was dieses Objekt kann und warum Sie stets vorsichtig sein sollten, erfahren Sie in folgendem Blogartikel.
Was machen die Berechtigungen ohne P_ABAP?
Einen kurzen Überblick über die Funktionsweise von Vereinfachungsgrad 1 haben wir bereits im letzten Artikel gegeben (wenn Sie ihn verpasst haben, können Sie ihn hier aufrufen). Um die Chancen und Risiken zu verstehen, möchten wir in diesem Blogartikel etwas ausführlicher und mit Beispielen arbeiten. Dabei gilt immer, dass P_ABAP nur bei Reports der logischen Datenbank PNP eine Wirkung hat. Wenn Sie hier in dem Artikel Screenshots der PA20 sehen, soll das nur zur Verdeutlichung der Testdaten dienen. In der PA20 hat das P_ABAP keine Wirkung.
Um die Wirkung von P_ABAP zu erklären, lohnt es sich zunächst, den Normalfall zu betrachten: Wie sind die Berechtigungsobjekte für Infotypen aufgebaut? Die Felder eines jeden Berechtigungsobjekts lassen sich in zwei Gruppen einteilen:
- Datenerlaubnis – Welche Daten erlaubt dieses Objekt?
- Personenerlaubnis – Für welche Personen wird der Zugriff auf diese Daten gewährt?
Damit der Zugriff auf einen Infotypen gewährt wird, müssen beide Feldgruppen in dem Objekt berechtigt sein. Das folgende Objekt gewährt z.B. Leseberechtigung auf den Infotypen 0001 (Org. Zuordnung) und 0007 (Sollarbeitszeit) von Personalnummern mit Mitarbeitergruppe “Aktive” und Mitarbeiterkreis 13.
Diese Berechtigung bringt jedoch auch Einschränkungen mit sich: Für diese Personalnummern darf der Infotyp 0008 (Basisbezüge) nicht gepflegt werden. Ebenso ist es nicht zulässig, den Infotyp 0007 für Personalnummern anderer Mitarbeiterkreise zu hinterlegen. Die Kombination muss exakt übereinstimmen.
Wenn ich dem Benutzer nun eine weitere Berechtigung gebe – z.B. Infotyp 0001 für Mitarbeiterkreis 17 – ändert das nichts am Ergebnis der Prüfung: Die Pflege des Infotypen 0007 ist für alle Mitarbeiterkreise außer 13 verboten.
Was ändert P_ABAP?
Was macht jetzt das P_ABAP mit Vereinfachungsgrad 1? Es bringt SAP dazu, diese Kombination von Datenerlaubnis und Personenerlaubnis aufzuheben. In den entsprechenden Reports darf der Infotyp 0007 weiterhin nur gelesen werden, wenn Berechtigung auf den Infotypen und auf den richtigen Mitarbeiterkreis gegeben ist. Aber diese Berechtigungen müssen nicht mehr in einem einzelnen Objekt zusammenkommen.
Es reicht es, wenn ein Benutzer
- in der Datenerlaubnis Berechtigung auf den Infotypen 0007 in irgendeinem Berechtigungsobjekt hat
- In der Personenerlaubnis (+ Berechtigungslevel) Berechtigung auf die Personalnummer in irgendeinem Berechtigungsobjekt hat.
Wenn wir jetzt die Kombination aus den beiden fast passenden Berechtigungsobjekten nehmen, wird plötzlich Berechtigung erteilt (ein Raunen geht durch die Menge).
Was soll das alles?
Nun stellt sich völlig zu Recht die Frage: Warum lässt die SAP so etwas skandalöses zu? – Die Antwort ist, weil es bestimmte Probleme sehr praktisch löst.
Nehmen wir folgendes Szenario:
Ein Report (nennen wir ihn ZHR_BEISPIELREPORT) gibt verschiedene Personaldaten aus und benötigt dafür leider den Infotypen 0007. Gleichzeitig haben wir einen Sachbearbeiter, der für den Mitarbeiterkreis 13 zuständig ist und dafür Leserechte für den Infotypen 0007 hat. Dieser Sachbearbeiter soll den ZHR_BEISPIELREPORT auch für den Mitarbeiterkreis 17 ausführen – für unser Beispiel den Infotypen 0007 für Mitarbeiterkreis 17 aber auf keinen Fall in der PA20 sehen.
Und hier entsteht das Dilemma:
- Geben wir ihm Rechte auf den Infotypen 0007 für Mitarbeiterkreis 17, verstößt das gegen den Datenschutz.
- Vergeben wir die Rechte nicht, kann der Report für die entsprechenden Personen nicht laufen.
Was nun? Genau hier kommt P_ABAP ins Spiel – in Kombination mit dem zuvor beschriebenen Prinzip. Infotyp 0007 für Mitarbeiterkreis 13 und Infotyp 0001 für Mitarbeiterkreis 17 genügen, damit der Report reibungslos läuft – und das, ohne unerlaubte Daten in der PA20 anzuzeigen.
Die gelben Dreiecke
Es geht sogar noch besser: Da die Kombination von Berechtigungsobjekten ausreicht, ist es nicht einmal erforderlich, dass diese Berechtigungsobjekte für sich vollständig und sinnvoll ausgeprägt werden. Es genügt, wenn entweder die Datensicht oder die Personensicht passt – der Rest kann leer bleiben (das Berechtigungslevel muss immer gefüllt sein). Auch wenn die PFCG gelbe Warndreiecke aufstellt – mit P_ABAP funktioniert die Kombination mit anderen Objekten trotzdem.
Riesige Nebenwirkungen
Also, alles bestens? Nicht ganz.
Wir hatten ja schon erwähnt, dass P_ABAP gerne aus seinem Käfig ausbricht.
Die oben beschriebene Kombinierbarkeit betrifft leider nicht nur die gewünschten Berechtigungsobjekte – sondern alle. Auch jene, die übersehen wurden. Oder die erst fünf Jahre später hinzugekommen sind. Und auch die, die in einer Rolle stecken, die eigentlich jeder Mitarbeiter hat.
Nehmen wir an, die Rolle für alle Mitarbeiter enthält eine uneingeschränkte Berechtigung für den Infotyp 0001. Das ist praktisch – denn so kann jeder in SAP die Grunddaten von Kollegen abrufen.
Doch was bedeutet das für unser P_ABAP? Die Personenerlaubnis aus der Berechtigung für alle Mitarbeiter wird mit der Infotyperlaubnis aus dem Szenario weiter oben kombiniert.
Das Ergebnis? Plötzlich kann der Beispielreport für sämtliche Personen im System ausgeführt werden!
Daraus folgt was?
In diesem Artikel haben wir die Möglichkeiten und Risiken von P_ABAP mit „Vereinfachungsgrad 1“ besprochen. Die wichtigste Schlussfolgerung, die wir Ihnen ans Herz legen wollen, ist, die Auswirkungen dieses Objekts immer im Blick zu behalten.
Wenn ein Benutzer P_ABAP für bestimmte Reports hat, kann jede Rollenänderung die diesen Benutzer betrifft zu einer ungewollten Ausweitung von Berechtigungen führen. Änderungen in einer Rolle sollten daher nicht isoliert sondern immer in Kombination mit den anderen relevanten Rollen betrachtet werden. Um das entsprechende Risiko zu vermindern, sollte P_ABAP generell möglichst sparsam vergeben werden.
Für das Problem „die Berechtigung soll für jede Transaktion anders ausgestaltet sein“ gibt es zusätzlich noch eine ganz andere Herangehensweise: Das Kundeneigene Berechtigungsobjekt (das deutlich näher am Standard liegt, als der Name vermuten lässt). Man kann mit diesem Konzept die Transaktion als Feld in das Berechtigungsobjekt aufnehmen und dann Berechtigungen abhängig von der Transaktion steuern. Aber das ist ein Thema für einen späteren Artikel.
Noch Fragen?
Haben Sie noch Fragen zu Berechtigungen? Oder benötigen Sie Unterstützung bei der Umsetzung?
Sprechen Sie uns auch gerne an! Einen direkten Link zum Kontaktformular finden Sie hier.
