Sicherheitssoftware auf der AS400

[hs]

Du sprichst große Worte gelassen aus!

Ich möchte mir aber nicht meine Finger verbrennen, indem ich an den Berechtigungen in unserem ERP-System drehe.

Die Folgen sind für mich nicht absehbar!

Werde diesbezüglich aber nochmals Kontakt mit unserem ERP-Lieferanten herstellen.

Gruß
HS

[BenderD]

Hallo,

ich bewundere immer wieder die Risikofreude diverser Software Lieferanten. Nach europäischem Recht setzt Produkthaftung des Herstellers bereits ein, wenn das Produkt nicht dem Stand der Technik entspricht und der Hersteller wird damit für Schäden haftbar, die auf derartige Produktmängel zurück gehen.
Da fragt man sich doch manchmal: was ist das Stand der Technik, bei Software ohne hinreichendes Berechtigungskonzept, ohne Transaktions Sicherheit...

mfg

Dieter Bender

Du sprichst große Worte gelassen aus!

Ich möchte mir aber nicht meine Finger verbrennen, indem ich an den Berechtigungen in unserem ERP-System drehe.

Die Folgen sind für mich nicht absehbar!

Werde diesbezüglich aber nochmals Kontakt mit unserem ERP-Lieferanten herstellen.

Gruß
HS

[hs]

Über die Software allein kann man ja auch nicht auf die Daten zugreifen. Programmaufruf ist nur über Menüs möglich, Programmberechtigung kann natürlich individuell vergeben werden.
Der Zugriff auf die Daten wird erst möglich mit Betriebssystem FTP, QRY etc.

Damit ist der Hersteller wohl raus aus der Haftung.

PS: Die Software ist natürlich auch schon ein paar Jahre alt.

[BenderD]

Hallo,

das könnte man auch anders sehen, FTP QRY und Konsorten sind seit Jahren auf jeder AS400 drauf und Menüschutz lässt sich von jedem Anwender, der es drauf anlegt untergraben. Dazu kommt das Risiko, dass schon bei leichter Fahrlässigkeit, ohne jede Absicht Daten verschüttet gehen können.
Das mit dem Alter ist nur dann ein Argument, wenn die Software bereits vor Jahren gekauft wurde und wird bereits dann zur Ausrede, wenn sogenannte "Wartungsgebühren" (Begriff aus dem Ingenieurswesen:= Vorbeugung gegen Verschleiß?!) verlangt und bezahlt werden.
Ich halte den Ansatz an den Hersteller zu gehen, schon für den ersten Schritt.

mfg

Dieter Bender

Über die Software allein kann man ja auch nicht auf die Daten zugreifen. Programmaufruf ist nur über Menüs möglich, Programmberechtigung kann natürlich individuell vergeben werden.
Der Zugriff auf die Daten wird erst möglich mit Betriebssystem FTP, QRY etc.

Damit ist der Hersteller wohl raus aus der Haftung.

PS: Die Software ist natürlich auch schon ein paar Jahre alt.

[Fuerchau]

Wenn der ERP-Lieferant nicht mitspielt, hast du trotzdem die Möglichkeit, dein Berechtigungskonzept zu realisieren.
Die Vorgehensweise von Dieter (und wie SAP es macht) ist die einzig Richtige und kann von keinem ERP-Anbieter "verboten" werden.

Am einfachsten ist es wirklich mit:

GRTOBJAUT OBJ(MYDTALIB) OBJTYPE(*LIB) USER(*PUBLIC) AUT(*EXCLUDE)
CHGOWNALL LIB(MYPGMLIB) NEWOWN(ERPMASTER) CUROWNAUT(*REVOKE)
CHGPGM PGM(MYPGMLIB/*ALL) USRPRF(*OWNER)

Für alle PF's, die einen "Fremd"-Zugriff benötigen, erstelle ich halt eine Lib mit speziellen LF's.
Das ganze am besten per CLP, so dass beim nächsten ERP-Release ein DLTLIB und anschließendes CALL vollkommen ausreicht, den Zustand wiederherzustellen.

Beispiel für CHGOWNALL:

  
CMD		PROMPT('Ändern OBJOWN LIB/*all')			   
PARM	   KWD(LIB) TYPE(*NAME) LEN(10) MIN(1) MAX(1) +   
			 EXPR(*YES) PROMPT('Bibliothek')			  
PARM	   KWD(NEWOWN) TYPE(*NAME) LEN(10) MIN(1) +	   
			 EXPR(*YES) PROMPT('Neuer Eigner')			
PARM	   KWD(CUROWNAUT) TYPE(*CHAR) LEN(10) +		   
			 RSTD(*YES) DFT(*REVOKE) SPCVAL((*REVOKE) +   
			 (*SAME)) EXPR(*YES) PROMPT('Aktuelle +	   
			 Eignerberechtigung')

CLP dazu:

  
			 PGM		PARM(&LIB &NEWOWN &CUROWNAUT)		 
															  
/* PARAMETER AUS KOMMANDO */								  
			 DCL		VAR(&LIB) TYPE(*CHAR) LEN(10)		 
			 DCL		VAR(&NEWOWN) TYPE(*CHAR) LEN(10)	  
			 DCL		VAR(&CUROWNAUT) TYPE(*CHAR) LEN(10)   
															  
/* VARIABLEN FÜR FEHLERAUSGANG */							 
			 DCL		VAR(&MSGID) TYPE(*CHAR) LEN(7)		
			 DCL		VAR(&MSGF) TYPE(*CHAR) LEN(10)		
			 DCL		VAR(&MSGL) TYPE(*CHAR) LEN(10)		
			 DCL		VAR(&MSGDTA) TYPE(*CHAR) LEN(512)	 
			 DCL		VAR(&MSGK) TYPE(*CHAR) LEN(4)		 
															  
/* TEMPORÄRE DATEI ERSTELLT */								
			 DCL		VAR(&CRTF) TYPE(*CHAR) LEN(1)		 
																	  
			 DCLF	   FILE(QADSPOBJ)								
																	  
			 MONMSG	 MSGID(CPF0000 CPF1907) EXEC(GOTO +			
						  CMDLBL(FEHLER))							 
																	  
/* ÜBERWACHUUNG SYSTEMANFRAGE 2 */									
			 SNDPGMMSG  MSG('/* */') TOPGMQ(*SAME) MSGTYPE(*RQS)	  
			 RCVMSG	 PGMQ(*SAME) MSGTYPE(*RQS) RMV(*NO) +		  
						  KEYVAR(&MSGK)							   
																	  
			 DSPOBJD	OBJ(&LIB/*ALL) OBJTYPE(*ALL) DETAIL(*BASIC) + 
						  OUTPUT(*OUTFILE) OUTFILE(QTEMP/CHGOBJALL) + 
						  OUTMBR(*FIRST *REPLACE)					 
			 CHGVAR	 VAR(&CRTF) VALUE('X')						 
																	  
																 
			 OVRDBF	 FILE(QADSPOBJ) TOFILE(QTEMP/CHGOBJALL)   
																 
SCHLEIFE:														
			 RCVF												
			 MONMSG	 MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDE))   
																 
			 IF		 COND(&ODOBOW *NE &NEWOWN) THEN(DO)	   
			 CHGOBJOWN  OBJ(&ODLBNM/&ODOBNM) OBJTYPE(&ODOBTP) +  
						  NEWOWN(&NEWOWN) CUROWNAUT(&CUROWNAUT)  
			 ENDDO											   
																 
			 GOTO	   CMDLBL(SCHLEIFE)						 
																 
ENDE:															
			 IF		 COND(&CRTF *NE ' ') THEN(DO)			 
			 DLTF	   FILE(QTEMP/CHGOBJALL)					
			 MONMSG	 MSGID(CPF0000)							   
			 ENDDO												   
																	 
			 RMVMSG	 PGMQ(*SAME) MSGKEY(&MSGK) CLEAR(*BYKEY)	  
			 MONMSG	 MSGID(CPF0000)							   
																	 
			 RETURN												  
																	 
FEHLER:															  
			 RCVMSG	 PGMQ(*SAME) MSGTYPE(*EXCP) MSGDTA(&MSGDTA) + 
						  MSGID(&MSGID) MSGF(&MSGF) MSGFLIB(&MSGL)   
																	 
			 RMVMSG	 PGMQ(*SAME) MSGKEY(&MSGK) CLEAR(*BYKEY)	  
			 MONMSG	 MSGID(CPF0000)							   
																	 
			 SNDPGMMSG  MSGID(&MSGID) MSGF(&MSGL/&MSGF) +			
						 MSGDTA(&MSGDTA) TOPGMQ(*PRV) MSGTYPE(*ESCAPE) 
																	   
			ENDPGM

[hs]

Natürlich kann mir das der ERP - Hersteller nicht "verbieten"

Aber es ist halt mein Risko, einen solchen weitreichenden Eingriff in die Software vorzunehmen!

Ohne Unterstützung des ERP - Herstellers werde ich sowas jedenfalls nicht durchführen.

Gruß
HS

[Fuerchau]

Meine Meinung:
Das ist weder ein weitreichender Eingriff in die Software noch ein Risiko, da die Objektschutz-Mechanismen der AS/400 sehr gut sind.
Wenn alle Lib's eines Paketes entsprechend "behandelt" werden, ist das eine Sache von wenigen Minuten.

Und: Es funzt !!!

[Sven Schneider]

So einfach wie es Fuerchau und BenderD schreiben ist es in der Praxis nicht. (Wer lebt schon auf einer Insel)
Oftmals existieren Schnittstellendateien zu anderen Systemen, wie Fibu und Kore.
Weiterhin gibt z.B. PC-Module (wie Bankensoftware), welche Daten (Per ODBC) in Schnittstellendateien einspielen oder Auslesen.
Das ganze ließe sich beliebig fotsetzen.

All das muss ich geeignet umstellen (Schnittstellen z.B. in andere Libs auslagern), bzw. mit dedizierten Berechtigungen versehen.

Und hier sind i.d.R. immer die Softwareanbieter mit im Boot.

Sven

[BenderD]

Hallo,

besonders kompliziert ist das nicht, das Problem liegt mehr darin, dass schwer abzuschätzen ist, was Berechtigungsfehler für Auswirkungen haben könnten und deswegen ist der Weg über den Hersteller vorzuziehen.
Was die externen Schnittstellen und PC Module angeht, so sollten die eigentlich nur lesen dürfen oder Batch Eingangsschnittstellen sein, die in dem Sinne eher harmlos sind, dass sie alles machen oder nix und wiederholbar sind.
In jedem Fall empfiehlt es sich (nicht nur hierfür) nach Berechtigungs Änderungen das Audit Journal zu aktivieren, damit man Fehlerhafte Abläufe sofort erkennt.
An der Stelle sei noch angemerkt, dass der skizzierte Weg auch kein Hochsicherheitssystem erzeugt, aber entscheidende Verbesserungen bringt und die Grundlage für alle denkbaren Maßnahmen darstellt, wenn man keine Placebo-Lösung sucht.

mfg

Dieter Bender

So einfach wie es Fuerchau und BenderD schreiben ist es in der Praxis nicht. (Wer lebt schon auf einer Insel)
Oftmals existieren Schnittstellendateien zu anderen Systemen, wie Fibu und Kore.
Weiterhin gibt z.B. PC-Module (wie Bankensoftware), welche Daten (Per ODBC) in Schnittstellendateien einspielen oder Auslesen.
Das ganze ließe sich beliebig fotsetzen.

All das muss ich geeignet umstellen (Schnittstellen z.B. in andere Libs auslagern), bzw. mit dedizierten Berechtigungen versehen.

Und hier sind i.d.R. immer die Softwareanbieter mit im Boot.

Sven

[Fuerchau]

Wartung ?
Ach ja:

Erscheint ein Techniker beim Kunden: "Sie haben eine Störung gemeldet ?"
Kunde: "Nein, wie kommen Sie darauf !"
Techniker: "Na gut, dann warte ich so lange."

[holgerscherer]

Wartung ?
Ach ja:

Erscheint ein Techniker beim Kunden: "Sie haben eine Störung gemeldet ?"
Kunde: "Nein, wie kommen Sie darauf !"
Techniker: "Na gut, dann warte ich so lange."

Grins, soo schlimm ists doch auch nicht, höchstens bei den ersten Serien der 8G Platten musste man einen Techniker auf Vorrat neben die Kiste stellen.

Was ich bei der ganzen Diskussion um Sicherheit und Sicherheitssoftware bisher vermisse, ist ein Statement zur Einstellung der ITler und der Anwender.

Oft interessiert sich der ITler solange nicht für Sicherheit, bis ein (externer) Auditor das Thema anspricht. Dann wird in hektischer Betriebsamkeit jedes Mittel ausgelootet, Software angeschafft oder entsprechende Berechtigungen gesetzt (der Ansatz mit USER(*OWNER) ist schon korrekt), und irgendwann ists dann vorbei.
Übrigens: USER(*OWNER) ist fast immer schmerzlos, wenn nicht, hat das Softwarehaus geschlampt, dann (wie Dieter schreibt) greift wieder die Haftungsfrage. Im Zweifelsfalle sollte man seine Umgebung auf einem Testsystem unter die Lupe nehmen, das gilt auch für geplante Wechsel auf SecLvl40 oder besser 50.

Ich habe bei meiner ERP-Software das alte Konzept der AUTLs wieder ausgegraben, das funktioniert auch recht gut; allerdings gilt hier (wie immer im Bereich "Sicherheit"): absolute Disziplin. Und auch wenn es 5000 Programme sind, mit ein paar CLs ist das Leben angenehmer.

Da Sicherheit kein statisches Thema ist, sollte man immer wieder darüber nachdenken, aber bei der Gelegenheit nicht den Anwender aus den Augen verlieren. Man kann eine AS/400 recht sicher machen (100% gibt es nie), aber dann ist das Ganze auch recht unkomfortabel. Heutzutage will ja jeder Bürohengst am liebsten mit Excel oder Access direkt auf die Daten zugreifen. Unterbindet man diesen direkten Zugriff auf die schwarze Kiste (empfehlenswert), macht man vielleicht einen Umweg über ein DataWarehouse, sprich, man kopiert alles auf einen externen Server.
Und da sieht es dann oft grauenhaft aus! Die AS/400 ist dann sicher wie die Burg, aber die Schatzkammer ist draussen beim Bauer im Heuschober.

Kennwortverschlüsselung ist mit SSL schon seit einiger Zeit möglich, aber was hilfts, wenn die Kundendatenbank als banale Excel-Tabelle auf dem lokalen PC oder auf dem Server rumliegt, wo jeder darauf zugreifen kann?

Und bei der Bewertung der Gefahrenquellen ist der gefrustete Vertriebsmitarbeiter in den Top 3, der innerlich gekündigt hat und alle Kontakte mitnehmen will.

Weiterhin kann man auf der AS/400 fast alles protokollieren, was auf dem System abgeht (wenn man den Plattenplatz frei hat), aber verhindern tut so ein Audit-Journal nichts. Aber man kann daraus lernen, im Notfall kapieren, was IBM manchmal treibt.

Und wer noch nicht gefrustet genug ist, darf sich gelegentlich mal die Symptomzeichenfolgen der PTFs genauer anschauen.

In diesem Sinne:
Sicherheit ist wichtig, aber nicht alles. Aber es wird wichtiger, wenn man in einer rauhen Branche arbeitet.

-h

[AS400.lehrling]

Grins, soo schlimm ists doch auch nicht, höchstens bei den ersten Serien der 8G Platten musste man einen Techniker auf Vorrat neben die Kiste stellen.

Was ich bei der ganzen Diskussion um Sicherheit und Sicherheitssoftware bisher vermisse, ist ein Statement zur Einstellung der ITler und der Anwender.

Da Sicherheit kein statisches Thema ist, sollte man immer wieder darüber nachdenken, aber bei der Gelegenheit nicht den Anwender aus den Augen verlieren. Man kann eine AS/400 recht sicher machen (100% gibt es nie), aber dann ist das Ganze auch recht unkomfortabel. Heutzutage will ja jeder Bürohengst am liebsten mit Excel oder Access direkt auf die Daten zugreifen. Unterbindet man diesen direkten Zugriff auf die schwarze Kiste (empfehlenswert), macht man vielleicht einen Umweg über ein DataWarehouse, sprich, man kopiert alles auf einen externen Server.
Und da sieht es dann oft grauenhaft aus! Die AS/400 ist dann sicher wie die Burg, aber die Schatzkammer ist draussen beim Bauer im Heuschober.

Kennwortverschlüsselung ist mit SSL schon seit einiger Zeit möglich, aber was hilfts, wenn die Kundendatenbank als banale Excel-Tabelle auf dem lokalen PC oder auf dem Server rumliegt, wo jeder darauf zugreifen kann?

Und bei der Bewertung der Gefahrenquellen ist der gefrustete Vertriebsmitarbeiter in den Top 3, der innerlich gekündigt hat und alle Kontakte mitnehmen will.

Weiterhin kann man auf der AS/400 fast alles protokollieren, was auf dem System abgeht (wenn man den Plattenplatz frei hat), aber verhindern tut so ein Audit-Journal nichts. Aber man kann daraus lernen, im Notfall kapieren, was IBM manchmal treibt.

Und wer noch nicht gefrustet genug ist, darf sich gelegentlich mal die Symptomzeichenfolgen der PTFs genauer anschauen.

In diesem Sinne:
Sicherheit ist wichtig, aber nicht alles. Aber es wird wichtiger, wenn man in einer rauhen Branche arbeitet.

-h

Darf man davon ausgehen das du das "Angebot" an genohmmen hast ?