wir haben im Produktivsystem das Berechtigungsobjekt S_DEVELOP gesperrt.

Allerdings gibt es nun den Antrag, das Berechtigungsobjekt wieder zu vergeben, so dass der Berechtigte im Infoset Coding eingeben kann ohne aber die HR-Tabellen (gleiche Mandant) auslesen zu können.

Hat hierzu jemand eine Idee wie man das steuern kann?

Gruss

n0vize

Im Produktivsystem Berechtigung für Entwicklung zulassen ist an sich schon grenzwertig.

Da ist ja im Prinzip das Scheunentor weit offen.

Ansonsten kann man nur sehr bedingt inschränken.

Entweder er hat Tabellenzugriff oder nicht.

Einige Tabellen im HR sind dann wenigsten noch geclustered - wenn der User aber Coding machen kann und darüber doch wieder über Funktionsbausteine Zugriff bekommt.....

Wir haben uns aus diesen Gründen vor einiger Zeit für eine Lösung von der Fa. topflow entschieden.

SE16XXL - darüber kann man den Zugriff auf einzelne Tabellen berechtigen und zusätzlich noch auf Zeilenebene (z.B. in Abhängigkeit vom Buchungskreis o.ä.).

Viele Grüsse

mas

ich finde so etwas auch grenzwertig bzw. unüblich. Kann man ein Infoset nicht auf der Entwicklung bauen und durchtransportieren?

Gruß

im globalen Bereich

mas

Allerdings bleibt das Problem weiterhin bestehen.

Zur Erstellung von Coding ist tatsächlich der Objekttyp PROG im Berechtigungsobjekt S_DEVELOP und 'AQ*' für OBJNAME erforderlich. Andernfalls ist ein Coding hier nicht möglich.Dieses gilt dann auch für einen Import von Query per Upload in ein anderes System, zumindest bei der Verwendung der Upload/Download Variante.

Beim Ausführen einer solchen Query / Infoset bedarf es dann aebr auch S_DEVELOP mit der Aktivität 03 und ggf. Objekttyp LDB.

Der Report RSAQR3TR ermöglicht jedoch nicht nur Upload / Download sondern auch den Transport von Query und Infoset.

Siehe Doku auf Consulut zu RSAQR3TR  .

ALternativ könnte auch die Berechtigung für S_DEVELOP mit PROG im Produktivsysteme ienr anderen Person zugeordnet sein (SAP Basis) die wiederum dann die Query per Datei Upload importiert.

Danke für Eure Hinweise.

Mir ist klar, dass das eine schwere Sicherheitslücke ist. Da wir die HR Daten teilweise auch im Entwicklungssystem haben hilft mir der Ansatz von Query transportieren nicht weiter.

Gruss

n0vize