Gibt es einen Weg, wie Anwendern mit SAP_ALL Berechtigung die Sicht auf HR-Daten wie z.B. Gehälter und Arbeitszeiten gesperrt werden kann? Welche Auswirkungen hat das u.U. für Mandantenkopien?

Könnte man ein eigenen Berechtigungsobjekt verwenden, welches die Sicht auf die HR-Daten erlaubt. Diese Berechtigungsobjekt dürfte dann nur eine dezidierte Person vergeben und auch mit SAP_ALL kann man es sich nicht sich selbst oder anderen zuteilen.

Kennt jemand einen brauchbaren Lösungsweg für so eine Anforderung?

gberndt ::)

Hi,

grundsätzlich ist es nicht möglich, das einem Benutzer mit SAP_ALL die Einsicht auf bestimmte Daten verwehrt wird (deshalb heißt es ja auch SAP_ALL  ;)).

Eine mögliche Lösung wäre, dass Profil SAP_ALL über eine entsprechende Rolle einzuschränken und dann diese anstatt SAP_ALL zu vergeben, so dass sensitive Daten, wie eben Gehälter, nicht vom System-Admin, sondern nur von den entsprechend authorisierten Personen gesehen werden dürfen.

Falls weitere Fragen bestehen sollten, Kontakt erwünscht.

Gruß
Matthias

---

Hallo,

aber hast du dann nicht das Problem, das die USer mit SAP_ALL ja ihre eigene Rolle verändern können. So ist es doch nach wie vor nicht sicher ob die Daten uneinsehbar sind.

ich denke das Berechtigungskonzept sieht solche Situationenen ja direkt vor und biete Lösungen an. DAs SAP_ALL Profil ändern in dem man die Berechtigung (ich kenn mich bei den Berechtigungsobjekten in HR nicht so aus) auf "alles" zuläßt und nur wenn ein Feld einen bestimmten Wert annimmt dann schlägt die Berechtigungsprüfung fehl. Ich will es mal an einem anderen Beispiel erklären. Die Flugdatenbank zusammen mit ABAP Programm ist ja auch so ein Spielplatz für so was. Hier kann man programmieren das man die Daten der Lufthansa einsehen kann, die der United Airlines aber nicht - das soll heißen, wenn eine bestimmte Personalnummer ausgewählt wird, dann muß darauf die Berechtigungsprüfung laufen - also alle Nummern außer diese...
Jetzt kommt es natürlich darauf a, wieviele Nummern hier eine Rolle spielen, aber selbst 50 oder 100 müßte man eintragen können.
Im Prinzip dürfen nur die Nummern rein die erlaubt sind und weiter nix. du mußt nur noch das Berechtigungsobjekt finden, in dem das geprüft wird --> Berechtigungstrace laufen lassen (ST01)

dello

Das klingt auf den ersten Blick schlüssig, ist es aber leider nicht.

Nehmen wir folgende Situation:

Ein SAP User hat SAP_ALL (um die von euch vorgeschlagenen Berechtigungsobjekte beschränkt). nun schreibt er ein kleines ABAP Programm, welches direkt die HR-Tabellen ausliest. Dieses kann er dann in jedem SAP-System starten, in dass er transportieren kann und in dem er z.B. über die SE38 Programme starten kann (oder er erfindet eine Transaktion, deren Zweck der Start des Proggis ist).

So wird die Berechtigungsprüfung ausgehebelt. Ich habe auch eine SAP-Meldung zu diesem Thema aufgemacht und folgende Antwort bekommen:

Frage an SAP:
Gibt es eine Möglichkeit dem SAP_ALL Profil die Sicht auf HR-Daten so zu
entziehen, dass ein Benutzer mit SAP_ALL Berechtigung sich diese auch
nicht mehr selbst zuteilen kann? s geht z.B. um die Informationen zu
Gehältern, Arbeitszeiten von Angestellten/Mitarbeitern. Liegen diese
Daten alle im HR-Cluster?

Antwort:
nein eine solche Möglichkeit gibt es nicht, einzelnen Profilen bestimmte
Berechtigungen wegzunehmen.

Wenn ein User die Berechtigung hat in einer produktiven Umgebung den
Daten-Browser zu verwenden, so kann er sich die Daten über die PA-
Tabellen selektieren.
Hier müssen Sie schon organisatorisch sicherstellen dass eben
der Zugang zur SE16 entsprechend eingeschränkt wird; insbesondere
wenn es sich um eine produktive Umgebung handelt.
Endanwender sollten sowieso keine SE11/SE16 Berechtigung erhalten.
Unterstützt werden Sie hierbei auch vom Berechtigungsobjekt
S_TABU_DIS. Dieses Objekt wird nicht nur in der SM30/SM31 geprüft,
sondern auch im Data-Browser.
Wenn also SE16 Berechtigung vergeben wird, muß über das Basis Berechtig-
ungsobjekt S_TABU_DIS der Zugriff über Berechtigungsgruppen entsprechend
gesteuert werden. Über die HR Berechtigungsobjekte (z.B. PLOG, P_ORGIN)
klappt das leider nicht.
Nur über das Berechtigungsobjekt S_TABU_DIS können Sie
entsprechende Einschränkungen für den Zugriff auf HR-Tabellen
vornehmen.
Standardmäßig werden die HR-Tabellen mit der Tabellenklasse "PA"
ausgeliefert. Diese Klassifizierung erfolgt über die geschützte
Tabelle TDDAT. Entwickler, die keine Berechtigung auf diese
Tabellenklasse haben, können selbst mit SE16 nicht auf HR-
Tabellen zugreifen.
Der Zugriff auf einzelne HR-Tabellen kann also über die Pflege der
Tabelle TDDAT weiter verfeinert werden kann.
Hier können also auch spezielle HR-Tabellen für einen bestimmten
Mitarbeiterkreis lesend oder schreibend zugänglich, für andere
Mitarbeiter dagegen aber gesperrt werden.


Meine 2. Frage:
Ich beziehe mich auf die bereits quittierte Anfrage:
XXXXXXXXXXX. Wenn es gelingt, mit dem Berechtigungsobjekt
S_TABU_DIS den Zugriff auf HR-Daten mittels der TK SE16 zu unterbinden.
Verhindert dass auch, dass ein Entwickler mit Hilfe eines einfach ABAP
Programms die HR-Tabellen direkt ausliest und deren Inhalte erhält,
obwohl er über die SE16 nichts sehen kann?

Antwort SAP:
das wird natürlich nicht verhindert. Allerdings sollte es dem
Entwickler im Produktivsystem ja gar nicht möglich sein, solche
ABAPs zu erstellen, bzw. solche ABAPs ins Entwicklungssystem zu
transportieren.

Ergänzend lege ich noch folgenden Hinweis bei:
#13202 Aspekte der Sicherheit bei ABAP-Programmierung


Man muss demnach systemweit ein differenziertes Berechtigungskonzept ausarbeiten, welches diese Nebenbedingungen berücksichtigt.

Gruesse

Guido

Hi Guido,

üblicherweise ist es ja so, dass Entwickler gar keine Berechtigung aus dem Produktivsystem haben oder haben sollten.

Ich würde mir auch eine Rolle basteln - es bleibt wohl nichts anderes übrig - in der ich die wichtigen Berechtigungsobjekte einschränke oder gar nicht erst vergebe.

Guck Dir doch mal die Klasse BC_A an, die ist für die Basisadministratoren.
Hier noch Berechtigungsobjekte für die Workbench, dazu ruhig mal die Hilfe lesen: S_DEVELOP, u. S_PROGRAM.

Viel Spaß damit + Gruß
daniel A.

Hallo,

das soll jetzt also heißen, dass man wenn man keine Berechtigung hat eine Tabelle zu lesen sich ein ABAP Programm basteln kann, welches die Tabelle ausliest und schon hat man die Daten zur Einsicht.
Das ist ja wirklich lustig... oder auch nicht!

Aber ich denke es gibt schon einen Grund dafür, das ein Produktivsystem eben von einem Entwicklungssystem getrennt sein sollte - vielleicht gerade auch deswegen dass man die Produktivdaten nicht einsehen oder sogar verändern kann...

Ich wußte es gibt eine  Grund dafür, das man als "Berechtigungskonzeptersteller" keine leichten Job macht.

dello

So üblich ist das, vor allem in kleinen Unternehmen bzw. bei kleinen Installationen nicht, dass Entwickler Produktivdaten einsehen können.

Oft reicht schon der Zugriff auf das Integrationssystem, wenn dort regelmäßig aktuelle Daten (damit an diesen getestet werden kann) eingespielt werden.

Zu einem "sauberen" Berechtigungskonzept gehört auch nach meinem Verständnis, Entwicklern, wenn überhaupt nur sehr eingeschränkt Zugriff auf Produktionssysteme zu geben (z.B. ohne die Berechtigung Programme zu starten, die nicht in einer genehmigungspflichtigen Programmliste bzw. Transaktion aufgelistet sind)

Gruesse

Guido

Mal die "ketzerische Frage"...:

-> Wieso braucht man denn überhaupt SAP_ALL innerhalb eines Profils?

Hier geht es soch eh nur um die pure Bequemlichkeit, weil man keine eignene Profile und Gruppen basteln will...oder?

Im übrigen kann jeder DB-Admin sowieso alle Daten auslesen...egal, welche Berechtigungen im SAP eingestellt sind...

-> grundstäzlich sollte jeder Zugriff der Entwickler im Prod-System unterbunden werden...und wenn, dann nur mit eingeschränkten Rechten
-> dies gilt ebenso für das QAS...dort soll getestet werden und nicht entwickelt!
-> auch im DEV-System braucht kein Entwickler SAP_ALL...auch nich der Admin...

😎 Ciao, OldSAPGuru

---

SAP_ALL benötigt man nicht einmal im Entwicklungssystem! Selbst hier kann man die Entwickler berechtigungsseitig einschränken. Die Berechtigung User/Rollen usw anlegen zu dürfen sollte man auf jeden Fall entziehen. Und auch im Basisbereich sollte man sich überlegen was ein Entwickler tatsächlich benötigt. Die Berechtigung z.B. für einen Mandantenkopie ganz sicher nicht, oder? Mit anderen Worten, bevor man anfängt Rollen zu basteln (die Zeiten der Profile sollten längst vorbei sein!), sollte man sich erst einmal überlegen welche Transaktionen und Objekte man für kritisch errachtet und das dann entsprechend berücksichtigen.
Und wie bereits einige erkannt haben, nicht nur das Produktivsystem benötigt ein sauberes Berechtigungskonzept. Nicht jeder der sich im Entwicklungssystem tummelt soll dort(unternehmensabhängig) alles ändern dürfen. Und im Dev ist ein an das Produktivsystem angelehntes Berechtigungskonzept auf jeden Fall notwendig wenn man dort mit kopierten produktiven Daten arbeitet.

Ein Entwickler benötigt allenfalls Anzeigeberechtigungen im Produktivsystem und keine SE/SA38!

Was mich interessieren würde: Arbeitet ihr im Produktivsystem auch noch mit SAP_ALL? Falls ja, sollte das asap geändert werden, denn das hält keiner Revision und keinem Wirtschaftsprüfer stand. Allenfalls ein Notfalluser kann SAP_ALL erhalten. Allerdings muss dann für diesen User ein bestimmtes Nutzungsprozedere festgelegt werden.

Petra

Was mich interessieren würde: Arbeitet ihr im Produktivsystem auch noch mit SAP_ALL? Falls ja, sollte das asap geändert werden, denn das hält keiner Revision und keinem Wirtschaftsprüfer stand. Allenfalls ein Notfalluser kann SAP_ALL erhalten. Allerdings muss dann für diesen User ein bestimmtes Nutzungsprozedere festgelegt werden.

Petra

Mit dem Standhalten magst du zwar theoretisch recht haben, in der Realität kratzt das aber keinen so richtig...auch die Prüfer wollen ja nächstes Jahr wieder kommen...also wird das Testat auch so kommen ;-)

Hab ich bei jedem Kunden bis dato so erlebt...  ::)

😎 Ciao, OldSAPGuru

---

Mit dem Standhalten magst du zwar theoretisch recht haben, in der Realität kratzt das aber keinen so richtig...auch die Prüfer wollen ja nächstes Jahr wieder kommen...also wird das Testat auch so kommen ;-)

Hab ich bei jedem Kunden bis dato so erlebt...  ::)

😎 Ciao, OldSAPGuru

Na, ich bisher in dieser Form noch nicht  :o.... oder sagen wir's mal so, ne gewisse Modifikation  ;) wurde schon erwartet.... was letztendlich ja auch kein Problem mit dem Pfrofilgenerator darstellt.

Petra