Sicherheitssoftware auf der AS400

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

[holgerscherer]

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

Ähm, Angebot? (Auf_Schlauch_steh)

-h

[AS400.lehrling]

Ähm, Angebot? (Auf_Schlauch_steh)

-h

Na die tätigkeit als Moderator hier im Forum