Willkommen im SAP Forum

Hi. Was ist mit Änderungsberechtigungen, die sich nicht in Feldern vom Typ ACTVT verstecken?

Hi Jonas. Tja, die bleiben leider wie sie sind. Also ein S_BTCH_JOB und ein S_BTCH_ADM mit BTCADMIN hätte auch eine Änderungsberechtigung über das Einplanen von Jobs. Für ein perfektes READ ONLY SAP_ALL wird hier wohl auch nicht drum herumkommen, Feinschliff zu machen. In jedem Fall muss auch die Nutzung dieser Rolle über das Security Audit Log überwacht werden. Ich werde im Artikel oben noch mal eine entsprechenden Hinweis ergänzen. Viele Grüße Tobias

Update // Hinweis auf Umgang mit Basis-Berechtigungen, speziell Berechtigungsobjekt S_ADMI_FCD ergänzt. Danke an unserer Leserin Jaqueline Dahm für den Hinweis per Mail!

In der Transaktion pfcg bekomme ich via springen - Einstellungen nur 2 Auswahlpunkte angezeigt. Der Punkt Gesamtsicht fehlt. Warum?

Hi Thomas, meinst du Hilfsmittel->Einstellungen? Könnte an Berechtigungen oder dem Support-Package-Stand liegen. In jedem Fall sollte eine Option "ALV-Tree verwenden (Berechtigungspflege neu aufrufen)" oder ähnlich vorhanden sein.

Hallo, ich habe die Rolle kurz getestet. Ich kann in der SCOT noch Konten anlegen oder löschen... Gruß Rouven

Hallo Herr Stockschläder, in dem Fall am besten einmal mit einem Berechtigungstrace das Ganze aufzeichnen und testen, was hier an Berechtigungen geprüft wird, damit das noch aus der Rolle ausgebaut werden kann. Viele Grüße

Wenn Änderungsberechtigungen in einer SAP_ALL_READ_ONLY-Rolle bleiben, dann ist es keine Leserolle mehr, d.h. bei der Vergabe der Rolle würde eine Täuschung stattfinden. Spätestens wenn ein Prüfer käme, wäre dies ein Punkt, der im Revisionsbericht stehen würde und eine erneute Rollen. Daher müssten entweder wirklich alle Änderungsberechtigungen wie z.B. auch im FELD AUTHC entfernt werden oder der Rollenname müsste angepasst werden. Wie sehen Sie dies?

Ja, es sollte hier eine "Packungsbeilage" geben, sprich eine aussagekräftige Beschreibung der Rolle und ihrer Limitationen. Mir ist keine Prüfungsfeststellung bei dieser Vorgehensweise bisher zugetragen worden. Im Gegenteil, oft wird manuell ein schlechteres Ergebnis erreicht. Auch weil dann oft doch wieder eine SAP_ALL-Rolle vergeben wird, weil die andere Version gar nicht funktioniert. Und der Begriff Täuschung kommt normalerweise auch mit der Frage des Vorsatzes, und der dürfte beim "normalen" Admin kaum vorliegen. Der hat ja ganz andere Möglichkeiten. Wer unbedingt (vielleicht aufgrund eines sehr hohen Schutzbedarfs) den Anfangsverdacht einer Täuschung vermeiden will, da kann die Rolle sicherlich besser SAP_ALL_BEIHNAHE_READ_ONLY nennen.

tatsächlich ist diese Rolle mit dem o.g. HowTo auch keine "Beinahe Anzeige".

Hallo Herr Harmes, ich bin neulich erst auf diesen Artikel gestoßen und konnte damit endlich einmal eine vernünftige read-only Variante des SAP_ALL Profils als sauber dokumentierte Rolle in unserem SAP System anlegen. Viele Dank für diese Anregung und auch für die Ergänzungen der Kollegen, die ich gleich mit übernehmen konnte. Ich wollte aber hier noch auf 2 Punkte aufmerksam machen: 1.) Die Kollegen haben hier ja schon (zurecht) auf die Update Berechtigungen in der neuen Rolle hingewiesen, die man leicht übersehen kann und somit zusätzliche Nacharbeiten benötigen. Im Gegensatz dazu wollte ich aber auch noch darauf hinweisen, daß es auch noch andere Read Only Aktivitäten gibt, die man einfach vernachlässigt wenn man der Empfehlung am Ende des Artikels folgt. Einfach alle Objekte, die die Aktivitäten 03 und/oder 08 nicht berechtigen, zu ignorieren greift hier m.E. viel zu kurz. Ich habe mich nämlich durch die verbliebenen ca. 120 offenen Objekte manuell durchgearbeitet und bin dabei auf mehr als 10 Berechtigungsobjekte gestossen, die zum Beispiel auch die folgenden Aktivitäten berechtigen: 27 - Summensätze anzeigen 28 - Einzelposten anzeigen 29 - Gespeicherte Daten anzeigen 33 - Lesen 48 - Simulieren 53 - Appliaktionsstart anzeigen 56 - Archiv anzeigen 58 - Übernahme anzeigen A5 - Berichte anzeigen A6 - Lesen mit Filter B5 - Historie anzeigen C2 - Anzeige von Zahlungskarten D3 - Detailanzeige T0 - Terminangebot anzeigen V3 - Versionen anzeigen All diese Aktivitäten einfach unter den Tisch fallen zu lassen halte ich für falsch, da es sich eindeutig um read-only Aktivitäten abseits der klassischen 03 und 08 Aktivitäten handelt. Wenn wir schon den Anspruch haben, die zumindest annähernd "perfekte" READ_ALL Rolle zu bauen, dann gehören diese Aktivitäten m.E. einfach mit dazu damit sich ein Admin oder ähnlich privilegierte User auch wirklich ALLES im SAP System anzeigen lassen dürfen. Außerdem macht es m.E. einen besseren Eindruck bei einem Auditor wenn die Rolle wirklich bis zum letzten Objekt durchgearbeitet und gepflegt wurde. Übrigens waren die Aktivitäten 03 und 08 bei den o.g. Objekten trotz der vorherigen Massenpflege immer noch NICHT berechtigt. Schon deshalb muss man diese Objekte noch einmal händisch pflegen - unabhängig davon ob man die anderen Anzeige Aktivitäten für relevant hält oder nicht. 2.) Mein zweiter Punkt betrifft die Berechtigungen für die Benutzung der Kundenprogramme im Z Namensraum. Im beschriebenen Ansatz berechtigen wir ja pauschal erst einmal ALLE Transaktionen durch die Ausprägung "*" im Objekt S_TCODE. Allerdings berechtigen wir dann automatisch auch jedes potentiell fehlerhafte Z Programm welches möglicherweise ändernd auf Daten zugreift und keine oder eine nur unzureichende Berechtigungsprüfung durchführt. Mich würde interessieren was Sie und die Kollegen hier empfehlen würden. Viele Grüße Marko Pfeiffer

Hallo Herr Pfeiffer, vielen Dank für Ihren Kommentar. Ich habe bei unseren Experten nachgefragt und folgende Antwort bekommen: "Mit Ihren Antworten haben Sie Recht. Das Ergebnis mit der Anleitung ist nur eine 70%-Lösung und SAP_ALL bleibt auch mit dieser Einschränkung eine kritische Sache. Wenn eine gute Security und Compliance gefordert ist, raten wir weiterhin dazu, ein ordentliches Berechtigungskonzept nach Minimalprinzip aufzubauen. Alle Fälle, in denen man als SAP-Kunde das Anzeige-SAP_ALL nutzen möchte, würde ich empfehlen zu hinterfragen, ob die verbleibenden Restrisiken angemessen erscheinen oder welche Alternativen es gibt. Dazu beraten wir gerne. Ergänzend zu Punkt 1 möchte ich auf jeden Fall noch darauf hinweisen, dass auch zahlreiche andere Felder neben ACTVT noch Änderungsberechtigungen freigeben. Das beinhaltet Felder wie z. B. CO_ACTION, PS_ACTVT und andere. Daneben gibt es auch noch Berechtigungsobjekte, die wenn man sie hat, automatisch eine schreibende Berechtigung zulassen, die also deaktiviert werden müssten, um wirklich hundertprozentig Read-Only zu werden." Wenn Sie sich zu dem Thema genauer austauschen möchten, schreiben Sie uns gerne auch eine Mail an info@rz10.de. Viele Grüße aus der RZ10-Redaktion