View Full Version : Komplett Protokollierung
Starocotes
29-08-06, 15:27
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.
Da hilft nur Journalisierung !
Starocotes
29-08-06, 15:31
Gibts da kein anderes Tool? Ansonsten würde das ja heißen ich müsste Journalisierung für JEDE Datei einschalten?
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
29-08-06, 16:03
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
29-08-06, 16:15
....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.
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.
Hier ist noch ein ganz guter Link für weitere Eerklärungen:
http://www.datakontext-press.de/fachbuecher/produkte/03_entgelt/0328/pdf/IKS-Starthilfe%20-%20Auszug.pdf#search=%22sox%20404%22
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
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 ;););)