Denken Sie an ein Datenbankdesign für die Audit-Protokollierung? Denken Sie daran, was mit Hänsel und Gretel passiert ist:Sie dachten, eine einfache Spur aus Brotkrümeln zu hinterlassen sei eine gute Möglichkeit, ihre Schritte zu verfolgen.
Wenn wir ein Datenmodell entwerfen, werden wir darin geschult, die Philosophie anzuwenden, dass jetzt alles ist, was existiert . Wenn wir beispielsweise ein Schema entwerfen, um Preise für einen Produktkatalog zu speichern, denken wir möglicherweise, dass die Datenbank uns nur den aktuellen Preis jedes Produkts mitteilen muss. Aber wenn wir wissen wollten, ob die Preise geändert wurden und wenn ja, wann und wie diese Änderungen stattfanden, kämen wir in Schwierigkeiten. Natürlich könnten wir die Datenbank speziell so gestalten, dass Änderungen chronologisch aufgezeichnet werden – allgemein bekannt als Audit-Trail oder Audit-Log.
Die Audit-Protokollierung ermöglicht es einer Datenbank, eine „Erinnerung“ an vergangene Ereignisse zu haben. Um mit dem Preislistenbeispiel fortzufahren, ermöglicht ein ordnungsgemäßes Prüfprotokoll der Datenbank, uns genau mitzuteilen, wann ein Preis aktualisiert wurde, wie hoch der Preis war, bevor er aktualisiert wurde, wer ihn aktualisiert hat und von wo aus.
Datenbank-Audit-Logging-Lösungen
Es wäre großartig, wenn die Datenbank für jede Änderung, die in ihren Daten auftritt, eine Momentaufnahme ihres Zustands speichern könnte. Auf diese Weise können Sie zu jedem Zeitpunkt zurückgehen und sehen, wie die Daten zu diesem genauen Zeitpunkt waren, als ob Sie einen Film zurückspulen würden. Aber diese Art der Audit-Protokollierung ist offensichtlich unmöglich; die daraus resultierende Informationsmenge und der Zeitaufwand für die Generierung der Protokolle wäre zu hoch.
Überwachungsprotokollierungsstrategien basieren darauf, Überwachungspfade nur für Daten zu generieren, die gelöscht oder geändert werden können. Jede Änderung darin muss geprüft werden, um Änderungen rückgängig zu machen, die Daten in Verlaufstabellen abzufragen oder verdächtige Aktivitäten zu verfolgen.
Es gibt mehrere gängige Audit-Logging-Techniken, aber keine davon erfüllt jeden Zweck. Die effektivsten sind oft teuer, ressourcenintensiv oder leistungsmindernd. Andere sind in Bezug auf die Ressourcen billiger, aber entweder unvollständig, umständlich zu warten oder erfordern Einbußen bei der Designqualität. Welche Strategie Sie wählen, hängt von den Anwendungsanforderungen und den Leistungsgrenzen, Ressourcen und Designprinzipien ab, die Sie respektieren müssen.
Out-of-the-Box-Protokollierungslösungen
Diese Überwachungsprotokollierungslösungen funktionieren, indem sie alle an die Datenbank gesendeten Befehle abfangen und ein Änderungsprotokoll in einem separaten Repository erstellen. Solche Programme bieten mehrere Konfigurations- und Berichtsoptionen, um Benutzeraktionen zu verfolgen. Sie können alle an eine Datenbank gesendeten Aktionen und Abfragen protokollieren, selbst wenn sie von Benutzern mit den höchsten Privilegien stammen. Diese Tools sind optimiert, um die Auswirkungen auf die Leistung zu minimieren, aber dies ist oft mit finanziellen Kosten verbunden.
Der Preis dedizierter Audit-Trail-Lösungen kann gerechtfertigt sein, wenn Sie mit hochsensiblen Informationen (z. B. Krankenakten) umgehen, bei denen jede Änderung der Daten perfekt überwacht und prüfbar sein muss und der Audit-Trail unveränderbar sein muss. Wenn die Audit-Trail-Anforderungen jedoch nicht so streng sind, können die Kosten für eine dedizierte Protokollierungslösung übermäßig hoch sein.
Die von relationalen Datenbanksystemen (RDBMS) angebotenen nativen Überwachungstools können auch zum Generieren von Audit-Trails verwendet werden. Anpassungsoptionen ermöglichen das Filtern, welche Ereignisse aufgezeichnet werden, um keine unnötigen Informationen zu generieren oder die Datenbank-Engine mit Protokollierungsvorgängen zu überlasten, die später nicht verwendet werden. Die auf diese Weise generierten Protokolle ermöglichen eine detaillierte Nachverfolgung der auf den Tabellen ausgeführten Operationen. Sie sind jedoch nicht zum Abfragen von Verlaufstabellen geeignet, da sie nur Ereignisse aufzeichnen.
Die wirtschaftlichste Option zur Verwaltung eines Audit-Trails besteht darin, Ihre Datenbank speziell für die Audit-Protokollierung zu entwerfen. Diese Technik basiert auf Protokolltabellen, die von Triggern oder Mechanismen gefüllt werden, die für die Anwendung spezifisch sind, die die Datenbank aktualisiert. Es gibt keinen allgemein akzeptierten Ansatz für das Design von Audit-Logging-Datenbanken, aber es gibt mehrere häufig verwendete Strategien, von denen jede ihre Vor- und Nachteile hat.
Entwurfstechniken für die Datenbank-Audit-Protokollierung
Zeilenversionierung für Audit-Protokollierung vorhanden
Eine Möglichkeit, einen Prüfpfad für eine Tabelle zu führen, besteht darin, ein Feld hinzuzufügen, das die Versionsnummer jedes Datensatzes angibt. Einfügungen in die Tabelle werden mit einer anfänglichen Versionsnummer gespeichert. Alle Änderungen oder Löschungen werden tatsächlich zu Einfügungsvorgängen, bei denen neue Datensätze mit den aktualisierten Daten generiert werden und die Versionsnummer um eins erhöht wird. Unten sehen Sie ein Beispiel für dieses Audit-Logging-in-Place-Design:
Hinweis:Tabellendesigns mit eingebetteter Zeilenversionierung können nicht durch Fremdschlüsselbeziehungen verknüpft werden.
Zusätzlich zur Versionsnummer sollten der Tabelle einige zusätzliche Felder hinzugefügt werden, um den Ursprung und die Ursache jeder an einem Datensatz vorgenommenen Änderung zu ermitteln:
- Das Datum/die Uhrzeit, zu der die Änderung aufgezeichnet wurde.
- Der Benutzer und die Anwendung.
- Die durchgeführte Aktion (Einfügen, Aktualisieren, Löschen) usw. Damit der Prüfpfad wirksam ist, darf die Tabelle nur Einfügungen unterstützen (Aktualisierungen und Löschungen sollten nicht zulässig sein). Die Tabelle benötigt auch unbedingt einen Ersatz-Primärschlüssel, da jede andere Kombination von Feldern Wiederholungen unterliegt.
Um über Abfragen auf die aktualisierten Tabellendaten zuzugreifen, müssen Sie eine Ansicht erstellen, die nur die neueste Version jedes Datensatzes zurückgibt. Dann müssen Sie den Namen der Tabelle in allen Abfragen durch den Namen der Ansicht ersetzen, mit Ausnahme der Abfragen, die speziell zum Anzeigen der Chronologie der Datensätze vorgesehen sind.
Der Vorteil dieser Versionierungsoption besteht darin, dass keine zusätzlichen Tabellen zum Generieren des Audit-Trails verwendet werden müssen. Außerdem werden den geprüften Tabellen nur wenige Felder hinzugefügt. Aber es hat einen großen Nachteil:Es zwingt Sie, einige der häufigsten Fehler beim Datenbankdesign zu machen. Dazu gehört, dass die referenzielle Integrität oder natürliche Primärschlüssel nicht verwendet werden, wenn dies erforderlich ist, was es unmöglich macht, die Grundprinzipien des Entwurfs von Entity-Relationship-Diagrammen anzuwenden. Sie können diese nützlichen Ressourcen zu Datenbankentwurfsfehlern besuchen, damit Sie gewarnt werden, welche anderen Praktiken vermieden werden sollten.
Schattentabellen
Eine weitere Audit-Trail-Option besteht darin, eine Schattentabelle für jede zu auditierende Tabelle zu generieren. Die Schattentabellen enthalten die gleichen Felder wie die Tabellen, die sie prüfen, plus die spezifischen Prüffelder (die gleichen, die für die Zeilenversionierungstechnik erwähnt wurden).
Schattentabellen replizieren die gleichen Felder wie die Tabellen, die sie prüfen, plus die Felder, die für Prüfungszwecke spezifisch sind.
Um Audit-Trails in Schattentabellen zu generieren, besteht die sicherste Option darin, Trigger zum Einfügen, Aktualisieren und Löschen zu erstellen, die für jeden betroffenen Datensatz in der Originaltabelle einen Datensatz in der Audit-Tabelle generieren. Die Trigger sollten Zugriff auf alle Prüfinformationen haben, die Sie in der Schattentabelle aufzeichnen müssen. Sie müssen die spezifische Funktionalität der Datenbank-Engine verwenden, um Daten wie das aktuelle Datum und die aktuelle Uhrzeit, den angemeldeten Benutzer, den Anwendungsnamen und den Ort (Netzwerkadresse oder Computername) zu erhalten, von dem der Vorgang ausgeht.
Wenn die Verwendung von Triggern keine Option ist, sollte die Logik zum Generieren der Audit-Trails Teil des Anwendungsstapels sein, idealerweise in einer Schicht, die sich direkt vor der Datenpersistenzschicht befindet, damit sie alle an die Datenbank gerichteten Operationen abfangen kann.
Diese Art von Protokolltabelle sollte nur das Einfügen von Datensätzen ermöglichen; erlauben sie das Ändern oder Löschen, würde der Audit Trail seine Funktion nicht mehr erfüllen. Die Tabellen müssen auch Ersatz-Primärschlüssel verwenden, da die Abhängigkeiten und Beziehungen der Originaltabellen nicht auf sie angewendet werden können.
Wenn die Tabelle, für die Sie ein Audit Trail erstellt haben, Tabellen hat, von denen es abhängt, sollten diese auch entsprechende Schattentabellen haben. Damit der Audit-Trail nicht verwaist, wenn Änderungen an den anderen Tabellen vorgenommen werden.
Schattentabellen sind praktisch wegen ihrer Einfachheit und weil sie die Integrität des Datenmodells nicht beeinträchtigen; die Audit Trails verbleiben in separaten Tabellen und sind einfach abzufragen. Der Nachteil ist, dass das Schema nicht flexibel ist:Jede Änderung in der Struktur der Haupttabelle muss sich in der entsprechenden Schattentabelle widerspiegeln, was die Pflege des Modells erschwert. Wenn außerdem die Audit-Protokollierung auf eine große Anzahl von Tabellen angewendet werden muss, ist die Anzahl der Schattentabellen ebenfalls hoch, was die Schemawartung noch schwieriger macht.
Generische Tabellen für die Audit-Protokollierung
Eine dritte Option besteht darin, generische Tabellen für Überwachungsprotokolle zu erstellen. Solche Tabellen ermöglichen die Protokollierung jeder anderen Tabelle im Schema. Für diese Technik werden nur zwei Tabellen benötigt:
Eine Header-Tabelle, die aufzeichnet:
- Datum und Uhrzeit der Änderung.
- Der Name der Tabelle.
- Der Schlüssel der betroffenen Zeile.
- Die Benutzerdaten.
- Die Art der durchgeführten Operation.
Eine Detailtabelle, die aufzeichnet:
- Die Namen der einzelnen betroffenen Felder.
- Die Feldwerte vor der Änderung.
- Die Feldwerte nach der Änderung. (Sie können dies bei Bedarf weglassen, da Sie es erhalten können, indem Sie den folgenden Datensatz im Audit-Trail oder den entsprechenden Datensatz in der geprüften Tabelle konsultieren.)
Die Verwendung generischer Audit-Log-Tabellen schränkt die Datentypen ein, die auditiert werden können.
Der Vorteil dieser Audit-Logging-Strategie besteht darin, dass keine anderen Tabellen als die beiden oben genannten erforderlich sind. Außerdem werden darin nur Datensätze für die Felder gespeichert, die von einer Operation betroffen sind. Das bedeutet, dass nicht eine ganze Zeile einer Tabelle repliziert werden muss, wenn nur ein Feld geändert wird. Darüber hinaus können Sie mit dieser Technik so viele Tabellen protokollieren, wie Sie möchten – ohne das Schema mit einer großen Anzahl zusätzlicher Tabellen zu überladen.
Der Nachteil ist, dass die Felder, die die Werte speichern, von einem einzigen Typ sein müssen – und breit genug, um selbst die größten Felder der Tabellen zu speichern, für die Sie ein Audit-Log generieren möchten. Am häufigsten werden Felder vom Typ VARCHAR verwendet, die eine große Anzahl von Zeichen akzeptieren.
Wenn Sie beispielsweise ein Prüfprotokoll für eine Tabelle generieren müssen, die ein VARCHAR-Feld mit 8.000 Zeichen enthält, muss das Feld, das die Werte in der Prüftabelle speichert, ebenfalls 8.000 Zeichen enthalten. Dies gilt auch dann, wenn Sie nur eine Ganzzahl in diesem Feld speichern. Wenn Ihre Tabelle andererseits Felder mit komplexen Datentypen wie Bilder, Binärdaten, BLOBs usw. enthält, müssen Sie deren Inhalt serialisieren, damit sie in den VARCHAR-Feldern der Protokolltabellen gespeichert werden können.
Wählen Sie Ihr Datenbank-Audit-Log-Design mit Bedacht aus
Wir haben mehrere Alternativen zum Generieren von Audit-Protokollen gesehen, aber keine davon ist wirklich optimal. Sie müssen eine Protokollierungsstrategie anwenden, die die Leistung Ihrer Datenbank nicht wesentlich beeinträchtigt, sie nicht übermäßig wachsen lässt und Ihre Rückverfolgbarkeitsanforderungen erfüllen kann. Wenn Sie nur Protokolle für einige wenige Tabellen speichern möchten, sind Schattentabellen möglicherweise die bequemste Option. Wenn Sie die Flexibilität haben möchten, jede Tabelle zu protokollieren, sind generische Protokollierungstabellen möglicherweise am besten.
Haben Sie eine andere Möglichkeit entdeckt, ein Überwachungsprotokoll für Ihre Datenbanken zu führen? Teilen Sie es unten in den Kommentaren mit – Ihre Datenbankdesignerkollegen werden Ihnen sehr dankbar sein!
