Zugriffbeschränkung auf ein definiertes Paket in der SE80
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo liebe Gemeinde,
ich habe eine Frage zu Berechtigungen und Zugriffsbeschränkungen. Und zwar hätte ich gerne mal gewusst, ob es möglich ist, den Zugriff auf ein definiertes Paket in der SE80 zu beschränken. Ziel ist, dass ein Entwickler nur auf die von ihm selber angelegten Objekte zugreifen kann und die fremden Inhalte nicht sieht.
Für eine Einschätzung der Realisierbarkeit wäre ich Euch sehr dankbar.
Liebe Grüße
ich habe eine Frage zu Berechtigungen und Zugriffsbeschränkungen. Und zwar hätte ich gerne mal gewusst, ob es möglich ist, den Zugriff auf ein definiertes Paket in der SE80 zu beschränken. Ziel ist, dass ein Entwickler nur auf die von ihm selber angelegten Objekte zugreifen kann und die fremden Inhalte nicht sieht.
Für eine Einschätzung der Realisierbarkeit wäre ich Euch sehr dankbar.
Liebe Grüße
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Über welches System redest Du hier? Entwicklungssystem? Produktivsystem?
Was verstehst Du in diesem Zusammenhang unter "Objekte" und unter "fremde Inhalte"?
Und was ist der Grund für so ein Vorgehen?
Was verstehst Du in diesem Zusammenhang unter "Objekte" und unter "fremde Inhalte"?
Und was ist der Grund für so ein Vorgehen?
Hi Unit605,
entschuldige bitte die verspätete Antwort, wallerdings war es mir asu gesundheitlichen Gründen nicht möglich früher zu schreiben.
Ich rede von einem Entwicklungssystem - im Produktivsystem ist der Zugriff auf die Entwicklungstransaktionen ja meist eh komplett eingeschränkt.
Worum es mir hierbei geht - und ich habe schon sehr viel recherchiert - ist, ob es möglich ist, dass man füber Berechtigungen angeben kann, dass ein Benutzer (Entwickler) bspw. in der SE80 nur auf seine eigenen Entwicklungsobjekte ( in Form von Reports, Includes, Programmen --> sprich Quelltext"objekte"/elemente) zugreifen kann.
Ein Zugriff auf ein ihm nicht zugeordnetes Paket soll verhindert werden.
Bsp.: Benutzer01 hat das PAket Z01 zugeordnet, so soll er nicht auf die Paketinhalte von Z02 zugreifen dürfen.
Hört sich schwierig an. meine mich aber zu erinnern, dieses oder etwas ähnliches schonmal gehört zu haben.
Danke und liebe Grüße
entschuldige bitte die verspätete Antwort, wallerdings war es mir asu gesundheitlichen Gründen nicht möglich früher zu schreiben.
Ich rede von einem Entwicklungssystem - im Produktivsystem ist der Zugriff auf die Entwicklungstransaktionen ja meist eh komplett eingeschränkt.
Worum es mir hierbei geht - und ich habe schon sehr viel recherchiert - ist, ob es möglich ist, dass man füber Berechtigungen angeben kann, dass ein Benutzer (Entwickler) bspw. in der SE80 nur auf seine eigenen Entwicklungsobjekte ( in Form von Reports, Includes, Programmen --> sprich Quelltext"objekte"/elemente) zugreifen kann.
Ein Zugriff auf ein ihm nicht zugeordnetes Paket soll verhindert werden.
Bsp.: Benutzer01 hat das PAket Z01 zugeordnet, so soll er nicht auf die Paketinhalte von Z02 zugreifen dürfen.
Hört sich schwierig an. meine mich aber zu erinnern, dieses oder etwas ähnliches schonmal gehört zu haben.
Danke und liebe Grüße
Soll der Benutzer01 (oder Entwickler??) nicht ändernd oder nicht lesend auf andere Objekte zugreifen können?
Und warum dieser Aufwand?
Es ist doch eigentlich so, dass das ein Vorteil ist, wenn man auf andere entwickelte Objekte, zumindestens lesen, zugreifen kann und diese mehrfach zu verwenden.
Wenn z.B. ein Entwickler einen Funktionsbaustein schreibt, warum sollte dann nicht ein anderer Entwickler darauf zugreifen können und diese auch nutzen, anstatt den gleichen Fuba noch einmal in einem anderen Paket zu erstellen?
Wenn es um Änderungen andere Objekte geht, dann legt man das im Team fest und dann hat kein anderer etwas an anderen Objekte zu ändern.
Ich selber bin Entwickler und ich wüßte nicht, wie Du irgendetwas (im Entwicklungssystem) vor mir "verstecken" wolltest.
Also lesen habe ich auf alles mit Leichtigkeit Zugriff.
Das Ändern eines Objektes ist ja durch die Zuordnung zu einem Transport/Aufgabe geregelt.
Der Zweck oder Gedanke für diese Vorgehen, würde Deine Frage evtl. etwas verständlicher machen.
Und warum dieser Aufwand?
Es ist doch eigentlich so, dass das ein Vorteil ist, wenn man auf andere entwickelte Objekte, zumindestens lesen, zugreifen kann und diese mehrfach zu verwenden.
Wenn z.B. ein Entwickler einen Funktionsbaustein schreibt, warum sollte dann nicht ein anderer Entwickler darauf zugreifen können und diese auch nutzen, anstatt den gleichen Fuba noch einmal in einem anderen Paket zu erstellen?
Wenn es um Änderungen andere Objekte geht, dann legt man das im Team fest und dann hat kein anderer etwas an anderen Objekte zu ändern.
Ich selber bin Entwickler und ich wüßte nicht, wie Du irgendetwas (im Entwicklungssystem) vor mir "verstecken" wolltest.
Also lesen habe ich auf alles mit Leichtigkeit Zugriff.
Das Ändern eines Objektes ist ja durch die Zuordnung zu einem Transport/Aufgabe geregelt.
Der Zweck oder Gedanke für diese Vorgehen, würde Deine Frage evtl. etwas verständlicher machen.
hi,
du darfst es nicht auf eine Firma beziehen. Es geht um einen Programmierkurs in einer Schulung. In letzter Zeit kam es häufig vor, dass die Teilnehmer keine eigenen Lösungen entworfen haben, sondern sich von einem der bereits existenten Lösungen eines anderen Teilnehmers bedient haben. Jeder Teilnehmer hat hierbei sein eigenes Paket in dem seine Entwicklungen liegen. Nun wäre es super, wenn der Zugriff halt nur auf sein eigenes Paket möglich ist.
Vielleicht hat ja einer in diesem kontext eine Idee, wie die Quellcode-"Diebstähle" in Zukunft unterbunden werden können.
LG und danke
du darfst es nicht auf eine Firma beziehen. Es geht um einen Programmierkurs in einer Schulung. In letzter Zeit kam es häufig vor, dass die Teilnehmer keine eigenen Lösungen entworfen haben, sondern sich von einem der bereits existenten Lösungen eines anderen Teilnehmers bedient haben. Jeder Teilnehmer hat hierbei sein eigenes Paket in dem seine Entwicklungen liegen. Nun wäre es super, wenn der Zugriff halt nur auf sein eigenes Paket möglich ist.
Vielleicht hat ja einer in diesem kontext eine Idee, wie die Quellcode-"Diebstähle" in Zukunft unterbunden werden können.
LG und danke
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallo OnkelSAP,
ohne es selber getestet zu haben - aber vielleicht kannst du ja in der SMOD die Erweiterung SEUED001 ( dort den Exit001 ) für deine Zwecke verwenden.
ohne es selber getestet zu haben - aber vielleicht kannst du ja in der SMOD die Erweiterung SEUED001 ( dort den Exit001 ) für deine Zwecke verwenden.
Hi,
vielen Dank für die Antwort. Ich hatte eigentlich gehofft, irgendwelche Standardberechtigungen hierfür zu finden und nicht extra eine Erweiterung auszuprogrammieren. Auch wenn es sich nicht nach so viel Aufwand anhört ist es ja immerhin eine Modifikation!
Hat vielleicht noch einer eine Idee, auch wenn es sich hierbei um einen SEHR speziellen Wunsch handelt, der im normalen Entwicklungskontext natürlich nicht gewpnscht ist?
Ander Sache: Gibt es eine Möglichkeit, mit der ich sämtliche Berechtigungsobjekte, die beim starten einer TA geprüft werden, mitloggen kann? Vielleicht finde ich ja so etwas?!
Liebe Grüße
vielen Dank für die Antwort. Ich hatte eigentlich gehofft, irgendwelche Standardberechtigungen hierfür zu finden und nicht extra eine Erweiterung auszuprogrammieren. Auch wenn es sich nicht nach so viel Aufwand anhört ist es ja immerhin eine Modifikation!
Hat vielleicht noch einer eine Idee, auch wenn es sich hierbei um einen SEHR speziellen Wunsch handelt, der im normalen Entwicklungskontext natürlich nicht gewpnscht ist?
Ander Sache: Gibt es eine Möglichkeit, mit der ich sämtliche Berechtigungsobjekte, die beim starten einer TA geprüft werden, mitloggen kann? Vielleicht finde ich ja so etwas?!
Liebe Grüße
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Hallo OnkelSAP,
Schau mal in Transaktion ST01 - da kannst du alles mögliche tracen - auch die Berechtigungsprüfungen.
P.S. Wenn ihr das dann hinbekommt, dass jeder nur noch bei sich schauen darf wäre es aber nur konsequent den Befehl "READ REPORT" aus der ABAPDOKU oder den Schulungsunterlagen zu entfernen.
Schau mal in Transaktion ST01 - da kannst du alles mögliche tracen - auch die Berechtigungsprüfungen.
P.S. Wenn ihr das dann hinbekommt, dass jeder nur noch bei sich schauen darf wäre es aber nur konsequent den Befehl "READ REPORT" aus der ABAPDOKU oder den Schulungsunterlagen zu entfernen.
Beitrag
von Frank Dittrich (Expert / 674 / 0 /
15
)
»
Da ein SAP-Username 12 Zeichen lang ist, ein Paket 30 Zeichen lang ist, und das Berechtigungsobjekt S_DEVELOP ein Feld DEVCLASS (Paket) hat,
kannst Du doch pro User ein Paket anlegen, z.B. mit Prefix Z_USER_.
Also, für User DITTRICH Paket Z_USER_DITTRICH, für USER DEVELOPER001 Paket Z_USER_DEVELOPER001 usw.
Und dann vergibst Du pro User eine Berechtigung, die für S_DEVELOP nur das jeweilige Paket Z_USER_... enthält.
Wenn Die Nutzer nur die Objekte anderer Pakete Z_USER_* nicht sehen dürfen, Pakete $TMP, Y*, Z* (außer eben Z_USER_*) sowie SAP-Standard-Pakete (also z.B. /*, A-Y~ oder so) aber schon, dann bekommt eben jeder Entwickler 2 Berechtigungen, eine mit den allgemein zulässigen Werten für DEVCLASS und ACTVT 03, und eine nur für einen DEVCLASS-Wert Z_USER_* mit ACTVT 01, 02, 03...)
Wenn die Benutzer aber den in ihren Paketen entwickelten Code selbst ausführen dürfen und ein paar grundlegende ABAP-Befehle kennen, bekommen sie aber natürlich, wie schon von anderen erwähnt, den fremden Code doch zu sehen.
Um dieses Schummeln zu unterbinden, muss man dann schon etwas schwerere Geschütze auffahren.
Frank
kannst Du doch pro User ein Paket anlegen, z.B. mit Prefix Z_USER_.
Also, für User DITTRICH Paket Z_USER_DITTRICH, für USER DEVELOPER001 Paket Z_USER_DEVELOPER001 usw.
Und dann vergibst Du pro User eine Berechtigung, die für S_DEVELOP nur das jeweilige Paket Z_USER_... enthält.
Wenn Die Nutzer nur die Objekte anderer Pakete Z_USER_* nicht sehen dürfen, Pakete $TMP, Y*, Z* (außer eben Z_USER_*) sowie SAP-Standard-Pakete (also z.B. /*, A-Y~ oder so) aber schon, dann bekommt eben jeder Entwickler 2 Berechtigungen, eine mit den allgemein zulässigen Werten für DEVCLASS und ACTVT 03, und eine nur für einen DEVCLASS-Wert Z_USER_* mit ACTVT 01, 02, 03...)
Wenn die Benutzer aber den in ihren Paketen entwickelten Code selbst ausführen dürfen und ein paar grundlegende ABAP-Befehle kennen, bekommen sie aber natürlich, wie schon von anderen erwähnt, den fremden Code doch zu sehen.
Um dieses Schummeln zu unterbinden, muss man dann schon etwas schwerere Geschütze auffahren.
Frank
Hallo Frank,
danke für Deine Antwort. Ich habe mich dieTage selber mal sehr intensiv mit der SU21 auseinandergesetzt und bin dort auch das von dir genannte Berechtigungsobjekt S_DEVELOP gestoßen. Quasi 2 Doofe, ein Gedanke...
Werde hiermit mal ein wenig herum experimentieren.
LG
danke für Deine Antwort. Ich habe mich dieTage selber mal sehr intensiv mit der SU21 auseinandergesetzt und bin dort auch das von dir genannte Berechtigungsobjekt S_DEVELOP gestoßen. Quasi 2 Doofe, ein Gedanke...
Werde hiermit mal ein wenig herum experimentieren.
LG
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
2443
Views
Views
Programm ist im Paket, aber fehlt in der SE80
von DeathAndPain » 13.03.2020 15:14 • Verfasst in ABAP® Core
von DeathAndPain » 13.03.2020 15:14 • Verfasst in ABAP® Core
6
Antw.
Antw.
5595
Views
Views
0
Antw.
Antw.
1857
Views
Views
0
Antw.
Antw.
3888
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 460
vor 23 Stunden von a-dead-trousers 5 / 460
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 23 Stunden von a-dead-trousers 5 / 460
vor 23 Stunden von a-dead-trousers 5 / 460