View Full Version : Sicherheitssoftware auf der AS400
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
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 !!!
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.
Sven Schneider
31-08-04, 10:20
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
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
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
07-08-05, 23:41
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
08-08-05, 03:14
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 ? :cool:
holgerscherer
08-08-05, 09:00
Darf man davon ausgehen das du das "Angebot" an genohmmen hast ? :cool:
Ähm, Angebot? (Auf_Schlauch_steh)
-h
AS400.lehrling
08-08-05, 09:42
Ähm, Angebot? (Auf_Schlauch_steh)
-h
Na die tätigkeit als Moderator hier im Forum :p