-
security level auf 40 setzen
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
-
... 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
-
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
-
... 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
-
Vielen Dank
ich habe unsere Audit reciever mal analysieren lassen und finden diese 'kritischen", weil CODE 'J', Einträge.
Code:
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
-
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
-
Zitat von dibe
Vielen Dank
ich habe unsere Audit reciever mal analysieren lassen und finden diese 'kritischen", weil CODE 'J', Einträge.
Code:
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
-
Zitat von 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
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 ;-)
-
Tja,
bei meiner Umstellung von V5R4 auf V6R1 ging alles Gut........
Bis zum ersten Mal der monatliche Reorgjob lief........
GG
-
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.
-
Zitat von KingofKning
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
Zitat von holgerscherer
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.
-
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.
Similar Threads
-
By DEVJO in forum NEWSboard Programmierung
Antworten: 12
Letzter Beitrag: 29-09-15, 14:07
-
By coolie in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 10-10-14, 09:06
-
By thluetjen in forum IBM i Hauptforum
Antworten: 13
Letzter Beitrag: 31-01-08, 10:21
-
By Kirsten Steer in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 16-09-02, 11:15
-
By W.Steiner in forum Archiv NEWSblibs
Antworten: 0
Letzter Beitrag: 05-07-01, 09:55
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks