security level auf 40 setzen

[BenderD]

Kannst Du ja mal fröhlich am 24ten umstellen dann hast du 4 Tage Zeit zum testen und wenn es nicht klappt stellst Du am 27ten wieder zurück.
GG


Am besten auf einer eigenen Testmaschine / -Partition die Umgebung auf SecLvl40 oder 50 stellen und in Ruhe ein paar Wochen alles genau testen.


... zwischen diesen Positionen liegen offensichtlich Welten! Ich würde mich allerdings keiner der beiden anschließen wollen.
- das Audit Journal deckt alles auf, was bei einem Test knallen würde, nur ohne dass da was knallt.
- alle Probleme stehen im Zusammenhang mit MI Programmen oder dem Aufruf nicht dokumentierter Schnittstellen.
- weder mit CL, noch mit RPG jedweder Schattierung, noch mit SQL, REXX oder den anderen Compilern lassen sich Programme erstellen, die unter irgendeinem seclevel Probleme verursachen, solange diese Programme kein MI Programm oder undokumentierte Schnittstellenprogramme aufrufen.

Da in einzelnen Fällen die Probleme nicht auf kurzem Weg heilbar sind, empfehle ich hier in jedem Fall sorgfältiges Vorgehen:
- Aktivierung Audit Journal
- Verifizierung, dass das auch korrekt erfolgt ist
- Fachkundige Auswertung der Journaleinträge
- ausreichender Auswertungs-Zeitraum, der auch alle Abschlüsse und Reorgs umfasst

Problemkanidaten sind fast immer gekaufte Software, insbesondere Systemnahe Tools (können auch freie sein), deshalb würde ich mir das immer von den Software Lieferanten zertifizieren lassen, (was zumeist kein Problem darstellen sollte).

D*B

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.

[Pikachu]

IBM i for Business - Job descriptions (https://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarljobd.htm)


When a batch job is submitted, the job might run using a different profile other than the user who submitted the job. The profile can be specified on the SBMJOB command, or it can come from the USER parameter of the job description. If your system is at security level (QSECURITY system value) 30 or lower, the user submitting a job needs authority to the job description but not to the user profile specified on the job description. This represents a security exposure. At security level 40 and higher, the submitter needs authority to both the job description and the user profile.

[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