security level auf 40 setzen

[BenderD]

... wenn ihr nur mit RPG/COBOL/CL/SQL hantiert, betrifft das eure Programme nicht. Man sollte sich aber von allen Lieferanten der eingesetzten Software Unbedenklichkeit bescheinigen lassen, sonst kann das schief gehen. Hauptsächlich geht es da um Programme, die bestimmte MI Aufrufe und/oder undokumentierte Schnittstellen benutzen.

D*B

[dibe]

Danke Herr Bender!
wir haben tatsächlich nur RPG CL SQL in allen Ausprägungen bei uns laufen.
Das ist zu 90 % eigen entwickelt, aber von Zig verschiedenen externen Mitarbeitern.
Außer einer Adressprüfung und einer Fax Schnittstelle gibt es keine externe Software!
Soll ich zum WE einfach mal umstellen, IPL machen und am WE die SW testen?
Kein 'Fahrplan', keine 'Prüf-Pgmme'?
DiBe

[BenderD]

... testen kann man das schon ohne Umstellung. Wenn man auditing aktiviert, dann werden potentielle Probleme im audit Journal protokolliert. Wie das geht, sieht man hier: http://www-01.ibm.com/support/docvie...d=nas8N1019668 . Es bleibt allerdings das Problem, dass ja in einem Programm ein Problem stecken könnte, dass noch nicht aufgerufen wurde, seitdem man das aktiviert hat. Bevorzugt passiert dann etwas beim Jahreswechsel oder Releasewechsel oder zu ähnlichen Anlässen, wo man das an besten gebrauchen kann.

D*B

[dibe]

Vielen Dank
ich habe unsere Audit reciever mal analysieren lassen und finden diese 'kritischen", weil CODE 'J', Einträge.

CODE  ART  DATUM      ZEIT   JOB-        BENUTZER-    JOB-     PROGRAMM-   OBJEKT-     BIBLIO
                             NAME        NAME         NUMMER   NAME        NAME        NAME  
                                                                                             
 J    NR   161215   73.106   QDBSRV03    QSYS        291.867   QDBSERVE                      
 J    PR   161215   73.107   QDBSRV03    QSYS        291.867   QDBSERVE                      
 J    NR   161215  154.548   QDBSRV03    QSYS        291.867   QDBSERVE                      
 J    PR   161215  154.548   QDBSRV03    QSYS        291.867   QDBSERVE                      
 J    RS   161215  230.839   SAV#DATEN   SAVE        296.393   HCP200      QAUDRCV      QGPL 
 J    RS   161215  230.840   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0001   QGPL 
 J    RS   161215  230.840   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0002   QGPL 
 J    RS   161215  230.840   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0003   QGPL 
 J    RS   161215  230.841   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0004   QGPL 
 J    RS   161215  230.843   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0005   QGPL 
 J    RS   161215  230.843   SAV#DATEN   SAVE        296.393   HCP200      QAUDRC0006   QGPL 
 J    IN   171215   24.030   *TDE        728996            0   *NONE                         
 J    NR   171215   24.115   SCPF        QSYS              0   QWCISCFR                      
 J    PR   171215   24.115   SCPF        QSYS              0   QWCISCFR                      
 J    NR   171215   95.245   QDBSRV03    QSYS        301.672   QDBSERVE                      
 J    PR   171215   95.245   QDBSRV03    QSYS        301.672   QDBSERVE                      

so wie ich das Lese sind das Systemdinge und die Sicherung des Journals/Reciever selber
Bekomme ich bei Level 40 deswegen ein Problem?

Danke
DiBe

[KingofKning]

Also ich habe in all den Jahren und Jahrzehnten noch nie von einem Problem bei der Umstellun von 30 auf 40 gehört.

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

[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.

[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.

[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.

[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