Sicherheitssoftware auf der AS400

[hs]

Hallo,

wir haben eine relativ neue AS400 mit Betriebssystem 5.2 im Einsatz.

Ich bekomme immer wieder Anrufe von Anbietern, die mir Software verkaufen wollen, mit der man die Sicherheit der AS400 verbessern kann.

Nun hängt unsere AS400 nicht im Internet und unser internes Netzwerk ist gegen aussen natürlich durch eine Firewall geschützt.

Den einzigen Zusatznutzen, den ich sehe, ist der Schutz gegen Datendiebstahl von intern (Stichwort: ODBC).

Aber so was kann man doch sicher auch mit Bordmitteln abstellen?
Gibt es im Netz eine vernünftige Abhandlung, welche Scheunentore auf der AS400 offen sind und was man dagagen tun kann?

Was habt ihr für Erfahrungen beim Einsatz solcher Sichheitssoftware? Lohnt sich eine Testinstallation?

Danke für eure Antworten
HS

[Fuerchau]

Such mal den Beitrag "Kennwort knacken".

[Sven Schneider]

Prinzipiell lässt sich fast alles mit Bordmiteln lösen ,aber ....

Vorgehensweise :
Erst Objektschutz dann Schutz der Zugriffsmethoden.

Höchstwahrscheinlich wirst schon bei der Betrachtung folgender Punkte Probleme haben :

1. Berechtigungen prüfen (Objektschutz)
-hat irgend ein AS/400-Anwender direkten Zugriff auf deine Anwendungsdaten, sind alle zugehörigen Bibliotheken und Objekte bzw. IFS-Files geschützt
- generell sollte nur Anwendungslogik veränderlichen Zugriff auf deine Daten haben, aber auch rein lesender Zugriff könnte ein Problem sein.(Wer lesen kann kann auch mitnehmen). Dies wir erreicht mit einem speziellem Anwendungsprofil, welche allein Rechte an den Daten hat. Alle Anwendungen müssen dann unter diesem Profil laufen. (Konzept: adopted authority)
- bei IFS-Daten wird es noch etwas komplizierter, hier wird kein adopted authority unterstützt (ggf. Konzept: swap userprofil)
- Hast du eine Anwendungssoftware (z.B. ERP-System) eines Drittanbieters im Einsatz, ist es oft nicht einfach ein solches Berechtigungkonzept umzusetzen. Hier hilft es nur auf den Anbieter hinzuwirken, dies umzusetzen.

2. Zugriffsmethoden prüfen
Um auf die Daten zuzugreifen bzw. sie zu verändern, gibt es mehrere Methoden :
RMTCMD (LMTCPB im USRPRF wird hier ignoriert), SQL(ODBC/JDBC), FTP, DDM/DRDA, SMB(NETSERVER)
Diese Dienste kannst du Zu- oder Abschalten oder gar nicht erst starten.

Wenn du Punkt 1. nicht konsequent umsetzt, hasst du mit Bordmitteln keine Möglichkeit die Zugriffe unter Punkt 2. zu verhindern.
Es sei denn du schaltest mit ENDTCPSVR bzw. ENDHOSTSVR diese Zugriffmöglichkeiten systemweit ab.

Zusätzliche Sicherheitssoftware (wie PCSACC/400, Pentasafe etc.) kann i.d.R. nur den Zugriffschutz auf der Zugriffsmethode (FTP, SQL etc.) erweitern, und damit den nicht vorhandenen Objektschutz ergänzen. Ausserdem lassen sich damit ggf. Sicherheitslücken aufdecken, die ich dann manuell oder automatisch schliessen kann, entweder innerhalb dieser Software oder auf OS/400 Objektebene.


Sven

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

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