Sicherheitssoftware auf der AS400

[hs]

Vielen Dank für eure ausführlichen Antworten

@fuerchau,
so beschämend das auch ist, dass Kennwörter unverschlüsselt durchs Netz geschickt werden, so traue ich doch niemandem in unserem Unternehmen solche Kenntnisse zu. Zudem lässt sich das ja offensichtlich in V 5.2 leicht abstellen?

@sven
Du hast natürlich recht, dass erst mal der Objektschutz innerhalb der Anwendung sauber geregelt sein muss.
Allerdings wird es wohl bei nahezu allen ERP-Systemen so sein, dass die User auf die Bibliothek und alle Dateien vollen Zugriff haben und Berechtigungen nur innerhalb der Anwendung (Menüs etc.) verwaltet werden. Zumindest kenne ich das nicht anders.
Für jeden mit etwas fortgeschrittenen QRY-Kenntnissen ist es ein leichtes, an alle Daten zu kommen, auch solche, die ihn eigentlich nichts angehen. Natürlich könnte man den Usern die Möglichkeit nehmen, QRYs selbst zu erstellen. Mit dem Resultat, dass dann die ganze Arbeit an mir hängen bleibt :-(

Bin mal gespannt, ob hier durch eine Sicherheitssoftware auch
wirksame Gegenmaßnahmen ergriffen werden können.

Und zu 2:
Das Problem ist halt, dass die Dienste für bestimtme Anwendungen benötigt werden. Und das kann ich meines Wissens nicht userabhängig steuern.

Gruß
HS

[Sven Schneider]

Naja ganz so ist es ja auch nicht.
Das gute Bsp. ist hier z.B. SAP auf der AS/400.
Hier haben nur 2 Profile (SAPxxx) Zugriff auf die Anwendungsdaten. Ansonsten hilft hier nur BAPI, RPC etc.

Aber es gibt immer noch viele zu viele Softwarehäuser, welche sich um ein korrektes Sicherheitskonzept bezüglich ihrer Anwendung drücken

Zum Thema QRY:
Wenn du dem Anwender QRY (QUERY/400, QM) wegnimmst hat er in der Regel damit Problem, weil er weicht dann auf andere Methoden aus (ODBC, JDBC, FTP)

Den Zugriff auf deine Daten zu Auswertungszecken kannst du auch anders lösen, ohne das alles an dir hängen bleibt. Hier einige Bspe:

- eigene Bibliothek mit logischen Files (Views) auf die Originaldaten - readonly Zugriff
- Aufbau eines DataWarehauses oder extract von Datenauszügen in eigenen Bibliotheken
- vordefinierte sql store procedures mit z.B. Rückgabe eines Result sets, diese lassen sich dann sehr gut in Excel verwenden (etwas VBA mit ADO ist hier allerdings vonnöten)

Sven

[BenderD]

Hallo,

@sven
Du hast natürlich recht, dass erst mal der Objektschutz innerhalb der Anwendung sauber geregelt sein muss.
Allerdings wird es wohl bei nahezu allen ERP-Systemen so sein, dass die User auf die Bibliothek und alle Dateien vollen Zugriff haben und Berechtigungen nur innerhalb der Anwendung (Menüs etc.) verwaltet werden. Zumindest kenne ich das nicht anders.

Bin mal gespannt, ob hier durch eine Sicherheitssoftware auch
wirksame Gegenmaßnahmen ergriffen werden können.

Gruß
HS

Das lässt sich doch leicht abstellen:

Public Berechtigung Datenbibliothek *EXCLUDE
Applikations Benutzer ohne Anmeldung
Applikatiions User als Owner der Bibliothek und der Objekte
Programme mit Datenbankzugriff unter Owner Berechtigung laufen lassen.
Wenn die Daten nicht separat gehalten werden, dann muss das Startprogramm (hier wird auch der LIBL gesetzt) bereits unter Owner laufen.

Damit ist alles verboten, was nicht erlaubt ist und so muss es sein. Und hier liegt genau das Problem der Dritt Software zur Kontrolle: bei jedem neuen Release kommen Schnittstellen hinzu, die (noch) nicht dichtgemacht sind und offene Scheunentore erzeugen.

Wenn die Applikation kein differenziertes Berechtigungskonzept hat, dann ist hier Ende der Fahnenstange. Selbst wenn Du über Schnittstellen kontrollierst, verhinderst Du kritische Abläufe nicht. (Wer sagt Dir denn, dass ein externer Zugriff auf die Daten die Verarbeitung nicht korrumpiert???).
Wenn man solche Software kauft, dann muss man vom ersten Tag an wissen, dass man hier einen eigenen Read only Pool für Reports etc. braucht (eigentlich braucht man den sowieso - was helfen die Konditionen von heute bei einem Auftrag, der ein Jahr alt ist?).
Bei der Variante mit den Views wäre ich vorsichtig, zumindest bei Release Wechsel der ERP Software, beim sichern und erst recht beim Restore, da wird es etwas komplizierter und abgeschmierte Release Wechsel sind zuweilen etwas komplex.

mfg

Dieter Bender

[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