View Full Version : Komplett Protokollierung
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
29-08-06, 18:57
....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.
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.
Doch, dem ist so. Wobei ich natürlich nur einen Zähler einbaue, wie oft an einem Tag ein Datensatz angesehen wurde, wobei der Zähler wieder neu anfängt, wenn der Datensatz sich geändert hat. Das ganze ist im übrigen nichts neues und zum Beispiel bei den Rechenzentren der Sparkassen (Fiducia und Co) schon lange Standard. Dort gibt es Ereignisse, wenn sich ein Sachbearbeiter am Tag zu oft ein- und denselben Kunden anschaut oder dessen Konten abfragt, dann wird der schon mal zum Geschäftsführer zitiert und nach der Begründung gefragt. Kein Witz sondern traurige Realität. Den Überwachungsstaat gibt es nicht nur auf öffentlichen Plätzen in Form von Videokameras.... Was bedeutet eigentlich Datenschutz ? Kann mir das mal einer erklären ????
Bzgl. WRKREGINF muss ich dich etwas enttäuschen:
- für lokale SQL-Befehle gibt es (z.Zt.) keinen Exit-Punkt
- für Remote-SQL gibt es ausschließlich Exit-Punkte für ODBC (QZDA-Server)
- Zugriffe über das DRDA-Protokoll können NICHT überwacht werden
Es gibt z.B. Anwendungen (Tools) wie Compleo, die einen eigenen TCP-Server für SQL-Zugriffe mitbringen, die mogeln sich an ODBC/DRDA vorbei.
Da hilft ausschließlich die Objekt-Berechtigung gegen unberechtigte Zugriffe.
Starocotes
30-08-06, 09:19
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.
Und wenn es diese Aufzeichnungen nicht gibt weis niemand das was geändert wurde. Theoretisch kann ich doch kurz bevor eine Zahlung an die Bank geht über einen SQL Befehl mal kurz die Kontonnummer austauschen und das nachher wieder rückgängig machen, aufschreiben tue ich das natürlich nicht.
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.
Das dem Theoretisch so ist ist klar, nur wie kann ich das sicher stellen oder im Nachhinein kontrollieren und das ist da wo SOX eigentlich ansetzt.
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.Es muss Kontrollen geben die sicher stellen das kein Unfug getrieben wird oder das Unfug aufgedeckt werden kann. Bei SOX gibt es zwei wichtige Prinzipien, zum Einen Teilung der Zuständigkeiten (segregation of Dutys) und zum anderen das vier Augen Prinzip.
Wir sind da mitten drin viele Dinge umzusetzen und lassen uns von externen Partnern beraten aber letztendlich ist es der Prüfer auf den es ankommt und hier liegt die Crux bei der Sache. Wenn der Prüfer ein Hardliner ist oder Angst hat dann verlangt er Kontrollen auf Alles und das kann keiner Bezahlen. Wenn er aber etwas lockerer ist sieht er das man sich Mühe gibt bestimmte Dinge zu kontrollieren und gibt sich damit zufrieden. Man weis aber vorher nicht wie der Prüfer das sieht. Nicht umsonst sind schon einige Unternehmen in den USA an SOX gescheitert.
Ich jedenfalls kann es mir nicht so einfach machen das abzuwälzen da ich ja dafür verantwortlich bin und auch wenn ein Externer das letztendlich machen soll muss ich das immer noch Koordinieren.
Die Klagen diesbezüglich kann ich durchaus verstehen.
Ich weiß auch nicht, was sich die Amis dabei gedacht haben.
Insbesonders was die Aufzeichnung von Daten angeht, gibt es gerade dort Probleme ohne Ende.
Beschränken kann man sich da ja (eigentlich) auf die Fibu-Systeme, da ja nur diese überwacht werden müssen.
Andere ERP-Systeme spielen da ehe eine untergeordnete Rolle.
Aber auch die lückenlose Verfolgung der Daten stellt sich als schwerig dar.
Was bringt es, wenn ich garantieren kann, dass die Daten mein Unternehmen unverfälscht verlassen wenn ich nicht sicher sein kann, dass diese auch unverfälscht ankommen ?
Das Problem des Admins ist, dass dieser im wesentlichen nicht kontrollierbar ist !
Hier hilft ausschließlich Vertrauen, da im Ernstfall alle Kontrollen versagen da ein Admin gerade diese jederzeit umgehen kann.
Hallo,
vielleicht noch ein paar Anmerkungen:
- Journalisierung aller Dateien sollte (bei dem EDV Budget einer Bank) kein Problem sein - rein technisch ist das keins.
- read Trigger könnten da schon eher Kapazitäten sprengen, da wäre ich vorsichtig
- ein alternativer Ansatz kann noch 4 Augen Prinzip nach Art des Tresorraumes sein, für den man zwei Schlüssel braucht. Technisch geht das kurz skizziert wie folgt:
Auditing für QSECOFR einschalten, damit protokolliert wird, wenn der Mechanismus deaktiviert wird.
Alle nicht interaktiven Schnittstellen über Exit Schnittstellen für QSECOFR zunageln.
Für die interaktive Anmeldung ein Startprogramm festlegen, dass als erstes mit einem Kennwort eines Revisors freigeschltet werden muss (da gibt es APIs für), selbiger muss dann ein entsprechendes Aktivitätsprotokoll mit dem ausführenden gemeinsam abzeichnen.
Voraussetzung ist dann weiterhin, dass die Applikation entsprechende Protokollmechanismen etc. hat, alle Zugriffsschutz Mechanismen korrekt implemetiert sind (keineswegs trivial), die Maschine und das Netz entsprechend physikalisch sicher sind.
mfg
Dieter Bender
Und wenn es diese Aufzeichnungen nicht gibt weis niemand das was geändert wurde. Theoretisch kann ich doch kurz bevor eine Zahlung an die Bank geht über einen SQL Befehl mal kurz die Kontonnummer austauschen und das nachher wieder rückgängig machen, aufschreiben tue ich das natürlich nicht.
Das dem Theoretisch so ist ist klar, nur wie kann ich das sicher stellen oder im Nachhinein kontrollieren und das ist da wo SOX eigentlich ansetzt.
Es muss Kontrollen geben die sicher stellen das kein Unfug getrieben wird oder das Unfug aufgedeckt werden kann. Bei SOX gibt es zwei wichtige Prinzipien, zum Einen Teilung der Zuständigkeiten (segregation of Dutys) und zum anderen das vier Augen Prinzip.
Wir sind da mitten drin viele Dinge umzusetzen und lassen uns von externen Partnern beraten aber letztendlich ist es der Prüfer auf den es ankommt und hier liegt die Crux bei der Sache. Wenn der Prüfer ein Hardliner ist oder Angst hat dann verlangt er Kontrollen auf Alles und das kann keiner Bezahlen. Wenn er aber etwas lockerer ist sieht er das man sich Mühe gibt bestimmte Dinge zu kontrollieren und gibt sich damit zufrieden. Man weis aber vorher nicht wie der Prüfer das sieht. Nicht umsonst sind schon einige Unternehmen in den USA an SOX gescheitert.
Ich jedenfalls kann es mir nicht so einfach machen das abzuwälzen da ich ja dafür verantwortlich bin und auch wenn ein Externer das letztendlich machen soll muss ich das immer noch Koordinieren.
Starocotes
30-08-06, 15:34
Hallo,
vielleicht noch ein paar Anmerkungen:
- Journalisierung aller Dateien sollte (bei dem EDV Budget einer Bank) kein Problem sein - rein technisch ist das keins.
Wir sind leider keine Bank sondern eine kleine Deutsche Zweigstelle eines internationalen Unternehmens das an der NYSE notiert ist.
- ein alternativer Ansatz kann noch 4 Augen Prinzip nach Art des Tresorraumes sein, für den man zwei Schlüssel braucht. Technisch geht das kurz skizziert wie folgt:
Auditing für QSECOFR einschalten, damit protokolliert wird, wenn der Mechanismus deaktiviert wird.
Alle nicht interaktiven Schnittstellen über Exit Schnittstellen für QSECOFR zunageln.
Für die interaktive Anmeldung ein Startprogramm festlegen, dass als erstes mit einem Kennwort eines Revisors freigeschltet werden muss (da gibt es APIs für), selbiger muss dann ein entsprechendes Aktivitätsprotokoll mit dem ausführenden gemeinsam abzeichnen.
Voraussetzung ist dann weiterhin, dass die Applikation entsprechende Protokollmechanismen etc. hat, alle Zugriffsschutz Mechanismen korrekt implemetiert sind (keineswegs trivial), die Maschine und das Netz entsprechend physikalisch sicher sind.
Das hört sich machbar aber zu aufwendig an, was genau das ist was ich suche. Vielen Dank.
Wir können hier nur mit Vorschlägen kommen wie das implementiert werden kann, dann aufzeigen was es kostet und warten was passiert.
Hallo,
schaue Dir einmal diesen Thread durch:
http://www.rlpforen.de/showthread.php?t=6293
Meist ist es preiswerter von der Börse zu verschwinden.
Man kann immer noch Geschäfte mit den Amis machen aber ohne SOX.
;););)
(nicht ganz ernst gemeint).
Sicherheitskosten waren schon immer extrem, die 1. 90% gehen ja noch, für jede nächste 9 kann man Faktor 10 der vorherigen Kosten ansetzen:
90% = X
99% = 10X
99,9& = 100X
usw.
wobei X schon durchaus geschäftsschädigend werden kann.