security level auf 40 setzen

[dibe]

Hallo zusammen,
wir wollen von Security 30 auf 40 wechseln.

Lt SC415302.PDF sind 'nur' das die Unterschiede

- Programs that use unsupported interfaces fail at run time.
- Enhanced hardware storage protection is enforced for all storage.
- Pointers used in parameters are validated for user domain programs running in system state.
- A program’s associated space cannot be directly modified.
- Internal control blocks are protected.

Wenn ich ehrlich bin weis ich nicht, was da gemeint ist!

Was sind nicht unterstütze Schnittstellen?
Welche Auswirkungen hat der erweiterte Speicher schutz
was sind "user domain programs running in system state".
Hat es für das Tagesgeschäft folgen, wenn zugeordneter Speicher nicht geändert werden kann?
Was für interne Control Blöcke?

Ihr merkt schon ... ich hab nicht so viel Ahnung.

Habt Ihr von 30 auf 40 umgestellt uns was für Probleme gab es dabei?

Danke
Dietlinde Beck

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

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

... wenn ich das auf die Schnelle richtig sehe, sind Einträge mit Code T, Art AF und davon die, die mit
B, C, D, J, R oder S anfangen kritisch.
Von dem blank ausprobieren über die Feiertage, halte ich persönlich nix. Erstens brennt mir da die Weihnachtsgans an und dann spielt ja noch eine Rolle warum ich das mache. Oft sind sowas Revisionsanforderungen und da halte ich von Schüssen aus der Hüfte wenig.

D*B

[holgerscherer]

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

Mal eben umstellen und testen am Wochenende geht in der Regel schief. Da reicht die Zeit nicht, alles auszuprobieren.

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

Je nach Branche und Validierungsvorschriften dauert das einige Wochen. Im Pharma-Bereich haben wir Kunden, die "mal eben" 6 Monate testen, auch vor jedem Release-Wechsel.

Wenn keine Testumgebung vorhanden ist - dafür gibts Dienstleister ;-)

[KingofKning]

Tja,
bei meiner Umstellung von V5R4 auf V6R1 ging alles Gut........

Bis zum ersten Mal der monatliche Reorgjob lief........

GG

[Fuerchau]

Bei vernünftiger Berechtigungsstruktur (kennt man ja aus anderen Beiträgen) sollte die Security mit 30 jeder Revision standhalten.
Es gibt keinen Grund zwingend auf 40 gehen zu müssen.

Mit MI-Programmen/Funktionen gehen wohl die wenigsten um. Compiler halten sich an die Regeln.
Programme, die von Anwendern entwickelt werden sind eher selten im "System"-Mode zumal die IBM das Verfahren wie dies zu erreichen ist nicht offen gelegt hat.
Solange alles per API gemacht wird gibt es keine Probleme mit der 40.

[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

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.