security level auf 40 setzen

[holgerscherer]

PS: @Baldur ... was Anforderungen von Revisoren angeht, habe ich mir abgewöhnt darüber nachzudenken, ob das Sinn macht. Das muss halt schlicht umgesetzt werden.

Du warst doch selbst mal bei Banken unterwegs... kennst das ja. Ich habe diverse Pharma-Projekte hinter mir bzw. am laufen. Da muss auch jeder Kram penibel getestet und dokumentiert werden.
Die Sinnhaftigkeit darf nicht hinterfragt werden - muss gemacht und bezahlt sein.

Andererseits hat es einen Vorteil: man kann diese genaue Vorgehensweise nutzen, um dokumentatorische Lücken zu finden...

[cbe]

Nur weil die Revision es wünscht muss es ja nicht überflüssig sein - im Gegenteil, oft kommen da nützliche Denkanstoße (auch wenn es immer zur Unzeit umgesetzt werden muss... :-) )

Als ich hier im Unternehmen anfing, zeigte ich meinem Chef nach ein paar Wochen, wie ich mir mit ganz wenig Aufwand SECOFR-Rechte selbst geben kann, wenn ich bei SecLvl 30 eine Kommandozeile habe. (siehe Pikachus Beitrag)
Da gab es dann keine Diskussion mehr, was es kostet, von SecLvl 30 auf 40 zu gehen :-)

Letztlich war die Umstellung sogar recht einfach + problemlos, die IBM-Doku führte recht gut.
Wer sich das nicht zutraut, kann man sicher auch einen Dienstleister oder IBM um Unterstützung bitten. Da der Aufwand bei geübten Admins rel. gering ist, sollten auch die Kosten passen.
Ich kann SecLvl 40 nur empfehlen, ein paar Scheunentore werden damit geschlossen.

Gruß, Christian

[Fuerchau]

SecLvl 40 verhindert nicht, dass ein User mit *ALLOBJ sich *SECOFR und sonstige Rechte geben kann.
*ALLOBJ ist das Risiko und nicht SecLvl 30.

[BenderD]

Als ich hier im Unternehmen anfing, zeigte ich meinem Chef nach ein paar Wochen, wie ich mir mit ganz wenig Aufwand SECOFR-Rechte selbst geben kann, wenn ich bei SecLvl 30 eine Kommandozeile habe. (siehe Pikachus Beitrag)

... wobei diese Lücke damit keineswegs zu sein muss, mit *ALLOBJ geht das auch mit seclevel 40

D*B

[cbe]

wenn man *ALLOBJ hat, darf man letztlich alles - stimmt.
Aber bei SecLvl 30 war es (zumindest bei uns) recht einfach, sich *ALLOBJ-Rechte zu holen, die man vorher nicht hatte. Kommandozeile und ein wenig suchen reichte.

[Fuerchau]

Auch das lässt sich mit 40 nicht verhindern.
Wenn man im Endeffekt durch Gruppenprofile oder den Rechten an anderen Profilen an ein *ALLOBJ-Profil kommt hilft Seclvl 40 nicht.
Das Problem hatte ich bei einem Kunden auch. Hier war der zuständige IT-Mensch nicht verfügbar, es musste aber dringend eine Aktivität mit SECOFR durchgeführt werden.
Also habe ich mir auf genau diesem Weg (PUBLIC *USE am *ALLOBJ-Profil) erst selber *ALLOBJ und dann *SECOFR-Rechte genommen.

Die 40 verhindert im Wesentlichen direkte MI-Zugriffe auf unzulässige Domains (hier ist nicht die IP-Domain gemeint), sondern System/User-Domain der Objekte.
Diese Zugriffe sind aber bei korrekter Verwendung von API's immer noch möglich.

[cbe]

Wenn man im Endeffekt durch Gruppenprofile oder den Rechten an anderen Profilen an ein *ALLOBJ-Profil kommt

... dann gehört der Systemadmin geschlagen :-)
Obwohl es für Dich in der beschriebenen Situation sicher praktisch war.

Wie auch immer, es ist mit SecLvl 30 erheblich einfacher, sich *ALLOBJ zu besorgen als mit SecLvl 40.
Komplett wasserdicht wird man die AS400 wahrsch. nie kriegen, aber die 40 hilft ein gutes Stück, mit rel. geringem Aufwand.

[holgerscherer]

Komplett wasserdicht wird man die AS400 wahrsch. nie kriegen, aber die 40 hilft ein gutes Stück, mit rel. geringem Aufwand.

Komplett wasserdicht? erinnert mich an das C2-Tool von Windows NT. "Erster Schritt, deaktivieren Sie alle Netzwerk-Interfaces". Dann noch in Blei eingiessen, und gut ist.

Aber auf IBM i ist es einfacher als anderswo. SecLvl 50 in Angriff nehmen, *ALLOBJ ist böse, *PUBLIC !=*EXCLUDE auch. Aber jedes Konzept steht und fällt mit dem Client.

Man findet ja gelegentlich CA-Sitzungen mit Anmelde-Makros auf ein *SECOFR-Profil. Bei Kunden, die eine 5tägige Sicherheitsschulung wollen...

-h