Komplett Protokollierung

[Starocotes]

Hallo

hat jemand ne Lösung um alles was ein bestimmter Benutzer tut zu protokollieren? Mir geht es nicht nur um die generellen Sachen die ich über den Systemwert QAUDLVL einstellen kann sondern auch um Änderungen in Datei (z.B. über SQL oder UPDDTA) und ähnliche Sachen.

[Fuerchau]

Da hilft nur Journalisierung !

[Starocotes]

Gibts da kein anderes Tool? Ansonsten würde das ja heißen ich müsste Journalisierung für JEDE Datei einschalten?

[Fuerchau]

Stimmt auffallend.
So wie QAUDLVL auf Objektebene funktioniert, funktioniert das Journaling auf Dateiebene.

Man bedenke aber, dass das Datenvolumen sehr schnell in nicht überwachbare Größenordnungen ausufert.
Es gibt Anwendungen, die z.B. Satzsperren über Flagfelder realisieren, so dass sich durchaus 1000e Protokollsätze ergeben, ohne dass sich wirklich was geändert hat.

Die andere Möglichkeit sind dann halt noch Trigger-Programme, die bei entsprechender Aktion Protokollsätze schreiben.
Hier gibts aber auch Probleme, da z.B. ein CLRPFM nicht mehr funktioniert, wenn ein Trigger definiert wurde !

Also:
Prüfe genau die Anforderung: WARUM das Ganze und vergiss es ggf. ganz schnell wieder.

[Starocotes]

Prinzipell geht es mir darum eine Verlässliche Aussage zu bekommen das es nicht geht (oder zumindest nicht mit einem vertretbaren Aufwand).

Die Anforderung lautet SOX.
http://de.wikipedia.org/wiki/SOX

Ich als Admin auf der AS/400 kann ja beliebig in Datein rumwursteln und muss das auch können, aber es muss dafür eine Kontrolle geben das ich nicht unbeobachtet Blödsinn mache. Mein Chef vertraut mir, SOX verlangt aber das es eine formelle Kontrolle dafür gibt.

Ich denke ja auch dass das so nicht geht, brauche aber da noch eine gewisse Sicherheit.

[kuempi von stein]

....Die Anforderung lautet SOX......Ich als Admin auf der AS/400 kann ja ....

Wenn Dein Vorstand/Vorgesetzter meint, das Risiko auf Dich abwälzen zu müssen, dann knall dem eben einen externen Anbieter vor dem Latz, der sowas gegen gutes Geld anbietet. (Egal ob das nun wirklich was taugt oder nicht)
Es gibt genug externe, die "angeblich" auch auf der AS/400 nach SOX arbeiten und anbieten.

Dann bist Du eben aus dem Schneider und gut ists....

k.

[Fuerchau]

SOX verlangt nicht, dass alles protokolliert wird sondern dass alle Änderungen dokumentiert sind.
Wenn also per SQL o.ä. irgendwas geändert wird muss es ganz einfach schriftliche Aufzeichnungen darüber geben warum, weshalb und durch wen dies oder das ausserhalb der normalen Anwendung durchgeführt wird.

Sonst müsste ja auch festgehalten werden, warum gerade dieser Auftrag gelöscht wurde (weil der Bediener einen Fehler gemacht hat oder weil der Kunde storniert hat ?).

Gerade als ADMIN darf man eben nicht so einfach in den Dateien rumwursteln, dafür ist man ja ADMIN des SYSTEMS.
Für die Anwendungen sind ja (eigentlich) auch wieder andere Leute zuständig.

SOX wird nicht so heiß gegessen wie es aussieht.
Ich bin ja sowohl Entwickler, Tester, Installer und Admin. Eigentlich müsste ich 4 Personen sein, was aber weder personell noch finanziell vertretbar ist.
Und das geht auch.
Es muss nur über organisatorische Verfahren attestiert sein.

[Fuerchau]

Hier ist noch ein ganz guter Link für weitere Eerklärungen:

http://www.datakontext-press.de/fach...22sox%20404%22

[pwrdwnsys]

SOX wird nicht so heiß gegessen wie es aussieht.
Ich bin ja sowohl Entwickler, Tester, Installer und Admin. Eigentlich müsste ich 4 Personen sein, was aber weder personell noch finanziell vertretbar ist.
Und das geht auch.
Es muss nur über organisatorische Verfahren attestiert sein.

Stimmt, die 4 Personen vereine ich auch in mir. Und weil ein Kunde möchte, das alles protokollliert und überwacht wird, das ganze aber ohne die Platten zum Platzen zu bringen, wie das diverse Tools machen, bin ich eben dabei eine kundenspezifische Lösung zu entwickeln, welche das abdeckt. Dabei werden folgen Funktionen verwendet:
- System-API's zur Abdeckung der SQL-Zugriffe
- READ-Trigger (diese verhindern nämlich kein CLRPFM)
- Journalisierung

[Fuerchau]

System-API's für SQL-Zugriffe ?
Da fallen mir nur die ODBC-Zugriffe (WRKREGINF) ein, gibts da noch was anderes ?

Lokales SQL (STRQMQRY/STRSQL/REXX u.v.m), da gibts nur die besagten Journale (Massenproblem).

Und DRDA-Zugriffe (DB2/Connect, WRKRDBDIRE) können auch nicht protokolliert werden.

Read-Trigger ? => Es geht doch um Veränderungen, die können doch nur Update/Insert/Delete-Trigger feststellen.

Aber seis drum, schließlich gibts ja viele Lösungen für die gleiche Aufgabe

[pwrdwnsys]

System-API's für SQL-Zugriffe ?
Da fallen mir nur die ODBC-Zugriffe (WRKREGINF) ein, gibts da noch was anderes ?

Lokales SQL (STRQMQRY/STRSQL/REXX u.v.m), da gibts nur die besagten Journale (Massenproblem).

Und DRDA-Zugriffe (DB2/Connect, WRKRDBDIRE) können auch nicht protokolliert werden.

Read-Trigger ? => Es geht doch um Veränderungen, die können doch nur Update/Insert/Delete-Trigger feststellen.

Aber seis drum, schließlich gibts ja viele Lösungen für die gleiche Aufgabe

@Fuerchau
a) WRKREGINF, das protokolliert alle SQL-Zugriffe, auch die Remote!. Den Eintrag hab ich jetzt nicht im Kopf, funktioniert aber.

b) Read:TRIGGER: es geht hier auch darum, wer hat welche Daten / Kunden / Geschäfte gesehen, also eine Protokollierung auf Dateninhaltsebene. Und das leistet meines Wissens nach kein Tool, da es hier um Anwendungsspezifische Inhalte geht. Für die Updates / Deletes / Inserts nehme ich immer noch liebend gern die Journale, auch aus Performancegründen.

[kuempi von stein]

....b) Read:TRIGGER: es geht hier auch darum, wer hat welche Daten / Kunden / Geschäfte gesehen, also eine Protokollierung auf Dateninhaltsebene. .....

Nun muss ich doch nochmal mitmischen...

:-)

Hier ist nicht wirklich die Rede davon, jeden Satz der gelesen wird zu protokolieren?
Nee nich?
Wenn ich also auf ne File mit nen paar Millionen records nen DSPPFM oder nen SQL ala SELECT * absetze dann wird nicht wirklich jeder record protokolliert?
Oder?

Arbeitest Du für/in Fort Knox?

k.