In mehreren Projekten, an denen wir gearbeitet haben, haben uns Kunden gebeten, mehr Benutzeraktionen in der Datenbank zu protokollieren. Sie möchten alle Aktionen wissen, die die Benutzer in der Anwendung ausführen, aber das Erfassen und Aufzeichnen aller menschlichen Interaktionen kann eine Herausforderung darstellen. Wir mussten alle über das System durchgeführten Datenänderungen protokollieren. Dieser Artikel beschreibt einige der Fallstricke, auf die wir gestoßen sind, und die Ansätze, mit denen wir sie überwunden haben.
Einführung
Ich arbeite als Lösungsarchitekt bei Finanzdienstleistungen. Es ist wichtig, Aufzeichnungen über den letzten Benutzer zu führen, der eine Zeile geändert hat. Im einfachsten Fall reicht es aus, den Zeitstempel der Änderung aufzuzeichnen, um eine Nachvollziehbarkeit zu haben von Änderungen. Hier ist ein einfaches Beispiel einer Tabelle, die Kundenvereinbarungen speichert, die last_changed enthalten Spalten für Benutzer und Zeitstempel.
In einigen Fällen reicht dies jedoch nicht aus. Wir benötigen oft eine vollständige Rückverfolgbarkeit (einschließlich Vorher-Nachher-Bildern). der Daten). In einigen Fällen benötigen wir auch Prüfbarkeit (wer, was, wann).
Leider sind viele unserer Systeme nicht darauf ausgelegt, Rückverfolgbarkeit und Überprüfbarkeit zu gewährleisten. Wir mussten Reverse Engineering durchführen diese Geschäftsbetriebsanforderungen in die Systeme.
Rückverfolgbarkeit
In einigen Fällen haben wir festgestellt, dass die Rückverfolgbarkeit einfach zu erreichen ist. Während wir es in anderen als schwierig oder sogar unmöglich empfunden haben. Abhängig von Ihrem System kann die Lösung einfach sein. Ihr Datenzugriff kann eine einfache Injektion der Protokollierung von Vorher- und Nachher-Bildern der Daten ermöglichen. Diese Protokollierung kann so implementiert werden, dass die Ergebnisse in einer Datenbanktabelle anstatt in einer Protokolldatei gespeichert werden. Bei einigen Produkten haben wir dies ganz einfach durch die Persistenz erreicht Schicht. Dies war beispielsweise mit Hibernate möglich .
Hier sehen Sie einen Eintrag für jedes Audit-Trail-Element, außerdem gibt es Vorher- und Nachher-Werte für jede Spalte, die sich geändert hat. Auch für den Fall, dass eine Zeile gelöscht wird, speichern wir diese Informationen mit dem functioncode Löschen anzeigt. Wir haben uns dafür entschieden, varchar(1) zu verwenden, um den Code der Funktion (C, R, D) zu speichern, der die Art der Änderung angibt, und nicht den Namen oder die Beschreibung der „Operation“ (Create, Update, Delete), die durchgeführt wurde . Der instance_key enthält den Primärschlüssel des hinzugefügten, geänderten oder gelöschten Elements zur Rückverfolgbarkeit.
Es kann jedoch sein, dass Ihre Datenzugriffsschicht nicht die erforderliche Funktionalität für Sie bereitstellt. Bei anderen Produkten war dies bei unserer Datenzugriffsschicht nicht der Fall. In diesen Fällen erforderte die Rückverfolgbarkeit komplexe Änderungen. Beispielsweise benötigen Sie möglicherweise den Abruf und die Protokollierung aller Daten vor der Änderung. Wie ich geschrieben habe, ist dies möglich, kann jedoch komplex sein. Entwickler müssten für jede Zeile einen Abruf erstellen, bevor sie eine Zeile ändern können. Es wäre nicht möglich, ein Update ohne select auszuführen.
Wie können Sie die Rückverfolgbarkeit umgehen? Eine mögliche Lösung besteht darin, sicherzustellen, dass Sie die Ausgangssituation aller Daten kennen, dh die Ausgangssituation, die durch alle statischen Daten entsteht, die in das System geladen werden. Dann müssten Sie alle Änderungen protokollieren. Mit anderen Worten, was sind all die „Nachher“-Bilder der Daten? Auf diese Weise wäre ein „Vorwärtsrollen“ möglich ” aus den geladenen statischen Daten. Alle bis zu diesem Zeitpunkt vorgenommenen Aktualisierungen werden angewendet. Dies ist keine ideale Situation, kann aber akzeptabel sein.
Eine einfache Tabelle kann verwendet werden, wenn die einzige verfügbare Information der neue Wert und nicht der vorherige Wert ist.
Prüfbarkeit
In einigen Situationen müssen wir sicherstellen, dass alle im System durchgeführten Aktionen vollständig überprüfbar sind . Wer hat sich wann eingeloggt? Welche Aktionen hat jeder Benutzer im System durchgeführt, einschließlich der ausschließlichen Anzeige von Daten? Dies ist wichtig, da es von Bedeutung sein kann, ob ein Benutzer eine Zahlung angesehen hat.
Um eine feinkörnige Ablaufverfolgung zu erreichen kann schwierig sein, nur den Datenbankzugriff zu betrachten. Wir müssen oft auf eine höhere Ebene schauen und die durchgeführten Aktionen oder Dienstleistungen untersuchen. In einigen Fällen konnten wir jeden Serviceaufruf nachverfolgen, um zu wissen, was ein Benutzer zu welcher Zeit getan hat. Mit einem Webservice-Input/Output-Controller war das Protokollieren von Serviceanfragen recht einfach.
Hier ist ein Beispiel für ein einfaches Benutzer-Audit-Protokoll, in dem wir die Aktion aufzeichnen, die jeder Benutzer ausführt. Ich diskutiere einige Fragen zu diesem Ansatz im nächsten Abschnitt „Beweis“.
Nachfolgend finden Sie eine kurze Tabellenbeschreibung:
Der user_audit Die Tabelle enthält Datenprüfungseinträge mit Zeitstempel. Der Primärschlüssel besteht aus der audit_entry_time stamp plus die user_id und bank_id plus den Namen der action durchgeführt. Die Felder haben Bedeutungen, die ihren Namen entsprechen. Die Audit-Tabelle speichert das result der Aktion plus die eigentliche class der die Aktion ausgeführt hat, seine Eingabe-parameters und alle errors .
Hier ist ein weiteres Beispiel für einen Audit-Trail, bei dem wir die Vorher- und Nachher-Bilder von Daten aufzeichnen, die in einer bestimmten Tabelle geändert wurden (zusammen mit der durchgeführten Aktion, den Benutzeranmeldeinformationen und dem Zeitstempel).
Der audit_trail Die Tabelle enthält Prüfeinträge von Vorher- und Nachher-Bildern der Daten. Der Primärschlüssel besteht aus dem audit_gen_key das ist ein von der Anwendung generierter Schlüssel. Die Felder haben Bedeutungen, die ihren Namen entsprechen. Der Name der Datenbanktabelle, für die dieser Audit-Trail-Eintrag aufgezeichnet wird, wird in modified_table gespeichert , plus das „vorher“-Bild wird in prev_value gespeichert und das „Nachher“-Bild in new_value . Das module der die Modifikation durchführt und der funct_type Änderungen (Create, Update, Delete) werden ebenfalls gespeichert. Schließlich die Prüfinformationen der user_id (und entsprechende bank_id ) plus Zeitstempel der Änderung (date_last_changed ).
Dann treffen wir auf eine Herausforderung. Wenn sowohl Informationen zur Rückverfolgbarkeit als auch Informationen zur Prüfbarkeit protokolliert werden, erfolgt die Protokollierung zweimal. Aus Revisionssicht ist das ärgerlich. Prüfer müssen sicherstellen, dass die Informationen in diesen beiden Protokollen identisch sind.
Beweis
Eine weitere Herausforderung bestand darin, sicherzustellen, dass alle Benutzeraktionen protokolliert werden . Dies wird häufig von Wirtschaftsprüfern in der Finanzdienstleistungsbranche verlangt.
Jetzt haben wir eine echte Herausforderung. Unsere Lösung bestand darin, eine zentrale Rückverfolgbarkeit und Auditierbarkeit der Protokollierung sicherzustellen. Zentrale „Schnittstellen“ stellen sicher, dass alle Implementierungen dieser Schnittstelle eine Protokollierung enthalten. Es war einfach sicherzustellen, dass alle geeigneten Klassen die Schnittstelle implementierten.
Dies garantiert natürlich keinen 100%igen Nachweis der Protokollierung. Es ist eine strenge Sicherheitsüberprüfung, dass alle entsprechenden Klassen wie erforderlich protokolliert haben.
Schlussfolgerung
Das Reverse Engineering neuer Geschäftsfunktionen in ein bestehendes System ist immer eine Herausforderung. Dies kann umso mehr der Fall sein, wenn die implementierte Funktionalität zum Kern geht.
