Notfalluserkonzept

[Carlos1739]

Hallo,

ich bin ganz frisch hier angemeldet, und habe auch gleich meine erste Frage:

Wir wollen hier bei uns im Unternehmen ein "Notfalluser" – Konzept implementieren, damit im falle eines dringenden Problems sich unsere Entwickler mit SAP_ALL anmelden können. Dazu haben wir den folgenden Ansatz:

Es gibt einen Benutzer, sagen wir mal "emuser" mit SAP_ALL. Dessen Passwort ist im Unternehmen bekannt. In einem Userexit (EXIT_SAPLSUSF_001, SMOD Erweiterung SUSR0001) kommt dann ein Dialog, in dem sich der Anmeldende noch einmal mit seinem "echten" Benutzernamen und Passwort authentifiziert und sagt, was er machen will. Nach einer Prüfung ob der Benutzer das darf, werden die Angegebenen Informationen in einer Tabelle weggeschrieben. Wenn der Benutzer es nicht darf, wird er wieder abgemeldet.

Soweit so gut.

Das Problem das ich aber jetzt sehe ist, dass sobald der Userexit aufgerufen ist hat der Benutzer ja schon SAP_ALL rechte und kann nicht nur den Überprüfungsvorhang abbrechen und normal weitermachen, sondern sich auch über den Debugger für jemand ganz anderes ausgeben.

Hat jemand von euch eine Idee, wie ich einen solchen Notfallbenutzer sonst implementieren kann? Wie wird so etwas bei euch realisiert?

Viele Grüße

[Medina4113]

Hallo
wir haben hier (gut oder nicht) aufgrund von Prüfern (SOX) auf der Produktion kaum noch Berechtigungen. DAmit wir aber trotzdem im Notfall helfen können gibt einen Firefighter an dem man sich anmelden kann und auch die entsprechenden Rechte hat.

Ist bestimmt Kostenpflichtig aber funtioniert ganz gut.

VIRSA nennt sich das glaube ich.

Firma : VIRSA SYSTEMS INC.,

http://en.wikipedia.org/wiki/Virsa_Systems

Ist mehr ode rweniger der 100% Schutz. Leider kann ich Dir nicht sagen was es kostet.

Gruß
Alex

[Tron]

Moin,
geht es überhaupt um das Produktionssystem ?
gruß TRon
(Virsa compliance calibrator ist nur ein Tool zur Analyse von Berechtigungen)

[Carlos1739]

Ja, letztendlich schon.

[Tron]

Moin,
die Entwickler haben bei uns im Unternehmen in Produktion nur "sehende" Berechtigungen auf Anwendungen (keinesfalls SE*). Es gibt einen User der mehr kann und den verwaltet "der BOSS" . Also ein spezieller User, der den "Superuser" sperren und freigeben kann (SOX-Konform).
gruß TRon
Allerdings kann man im Entwicklungssystem einen User mit allen Berechtigungen anlegen und via RFC den User mit Baustein BAPI_USER_CREATE ins Prod system übertragen , aber pssst.

[Fiona462]

Es gibt einen Benutzer, sagen wir mal "emuser" mit SAP_ALL. Dessen Passwort ist im Unternehmen bekannt. In einem Userexit (EXIT_SAPLSUSF_001, SMOD Erweiterung SUSR0001) kommt dann ein Dialog, in dem sich der Anmeldende noch einmal mit seinem "echten" Benutzernamen und Passwort authentifiziert und sagt, was er machen will. Nach einer Prüfung ob der Benutzer das darf, werden die Angegebenen Informationen in einer Tabelle weggeschrieben. Wenn der Benutzer es nicht darf, wird er wieder abgemeldet.

Warum dreht ihr die Anmeldung nicht einfach um.

Erst muss der User sich anmelden und muss sagen was er machen will und erst wenn die Prüfung ok ist, wird er mit dem Notfall-User angemeldet?

Man kann auch einen Notfalluser anlegen und nicht JEDEM das Passwort geben, sondern erst wenn etwas gemacht werden muss und der User als authorisiert erklärt ist.
Danach ändert der Verwalter des Notfalluser das Password.

[Carlos1739]

Also zuersteinmal muss ich mich bedanken! Das geht ja hier Schlag auf Schlag! Das finde ich echt super.

@BauntyHunter: Das halte ich für eine sehr gut Idee. Allerdings habe ich hier das Problem, dass ich das Passwort (mehr oder weniger im Klartext) im System hinterlegen muss. Und da es ja auch auf unseren Integrationssystemen laufen soll, habe ich ein Problem, dieses vor unseren Entwicklern zu verstecken.

[Fiona462]

Also zuersteinmal muss ich mich bedanken! Das geht ja hier Schlag auf Schlag! Das finde ich echt super.

@BauntyHunter: Das halte ich für eine sehr gut Idee. Allerdings habe ich hier das Problem, dass ich das Passwort (mehr oder weniger im Klartext) im System hinterlegen muss. Und da es ja auch auf unseren Integrationssystemen laufen soll, habe ich ein Problem, dieses vor unseren Entwicklern zu verstecken.

Das Password nicht im System hinterlegen sondern bei einem Verantwortlichen in der Schublade.

[Ida5160]

Hallo,

bei uns wurde es wie folgt gelöst: Alle Superuser sind gesperrt. Wenn einer gebraucht wird, generiert die Basis ein Passwort und gibt dieses an zwei dafür autorisierte Mitarbeiter.

Der Einsatz ist zu Dokumentieren (im Ticket). Werden Tabellen geändert, so wird bei uns eine spezielle SM30 verwendet, nämlich eine bei der Tabellenprotokollierung an und ausgeschaltet wird. Dann kann der Fachbereich nachvollziehen, was repariert wurde.

Oder wie bereits vorgeschlagen: versiegeltes Passwort im Briefumschlag im Tresor.

Dann kannst Du Dir den Userexit schenken.

Guten Rutsch

[Alessio37]

Hallo,

wir haben eine Notfallrolle die fast SAP_ALL enthält. Diese wird bei Bedarf für 1-2 Tage einem User auf Anforderung zugeordnet.

Grüße
Alex