Vertica Audit-Log

Vertica wird häufig als Kern von Analyseplattformen verwendet, bei denen dutzende Anwendungen, ETL-Jobs und BI-Tools massive Mengen von SQL erzeugen. Wenn etwas Verdächtiges passiert – ein fehlgeschlagener Batch, eine unerwartete Schemaänderung oder ein potenzieller Sicherheitsvorfall – müssen Teams in der Lage sein, eine einfache Frage zu beantworten: wer hat was, wann und wie getan? Ein gut implementiertes Vertica Audit-Log stellt diese Transparenz her, indem es wichtige Datenbankereignisse und das SQL, das diese ausgelöst hat, aufzeichnet.

Dieser Artikel zeigt, wie man mit den nativen Vertica-Auditinformationen direkt aus DBeaver arbeitet und anschließend demonstriert, wie DataSunrise diese niedrigstufigen Einträge in eine zentralisierte, durchsuchbare Audit-Trail verwandelt. Wir führen durch das Abfragen des v_monitor-Schemas, die Konfiguration einer Vertica-Auditregel in DataSunrise und den Vergleich nativer Logs mit der angereicherten Ansicht in den DataSunrise Audit Logs und dem Database Activity Monitoring. Für eine Referenz aller verfügbaren Systemtabellen und Parameter konsultieren Sie bitte die offizielle Vertica-Dokumentation.

Verstehen der Vertica Audit-Logs

Vertica stellt keine einzelne monolithische „audit_log“-Tabelle bereit. Stattdessen werden auditrelevante Informationen in mehreren Systemansichten und Logdateien erfasst. Die zwei Hauptbestandteile sind:

Engine-Audit-Log-Dateien – Betriebssystembasierte Logdateien, die Authentifizierungsversuche, Rechteänderungen und bestimmte Systemereignisse enthalten.
v_monitor-Ansichten – SQL-abfragbare Tabellen, die ausgeführte Anfragen, aktive und historische Sessions sowie verschiedene Überwachungsereignisse anzeigen.

Zusammen können diese Quellen zentrale Fragen beantworten, die für Sicherheits-, Compliance- und Betriebsteams wichtig sind:

Welcher Account hat versucht, sich in den Cluster einzuloggen und von wo?
Welches SQL-Statement hat eine sensible Tabelle gelöscht oder verändert?
Welche Abfragen liefen zum Zeitpunkt eines Vorfalls?
Wie häufig treten Authentifizierungsfehler oder Fehlermeldungen auf?

Die folgenden Abschnitte zeigen, wie man mit DBeaver und DataSunrise diese Informationen zugänglich und nutzbar macht.

Anzeige nativer Vertica Audit-Informationen in DBeaver

Da das v_monitor-Schema wie jede andere Tabelle zugänglich ist, können Sie DBeaver nutzen, um Verticas auditbezogene Ansichten zu erkunden. Eine der nützlichsten ist v_monitor.query_requests, welche jede ausgeführte Anweisung mitsamt Nutzerangaben, Zeitstempeln und Status aufzeichnet.

Vertica Audit-Log – SQL-Abfrageschnittstelle mit Anzeige von Filteroptionen für Audit-Log-Daten und Beispielergebnissen. — Screenshot der Vertica Audit-Log-Oberfläche, die eine SQL-Abfrage zum Filtern von Audit-Logs nach Benutzername, Anfragetyp und Zeitstempeln zeigt, mit darunter angezeigten Beispieldaten. Die Oberfläche enthält ein Textfeld für SQL-Ausdrücke und ein Raster zur Ausgabe der Abfrageergebnisse.

Abfrage von v_monitor.query_requests aus DBeaver. Jede Zeile repräsentiert eine ausgeführte Anfrage, inklusive Benutzername, Anfragetyp, vollständigem SQL-Text, Start- und Endzeitstempeln sowie Erfolgsmeldung.

Eine typische Abfrage zur Erstellung eines nativen Vertica Audit-Logs sieht folgendermaßen aus:


SELECT
    user_name,
    request_type,
    request,
    start_timestamp,
    end_timestamp,
    success,
    error_count
FROM v_monitor.query_requests
ORDER BY start_timestamp DESC
LIMIT 50;

Diese Ausgabe verhält sich bereits wie ein Audit-Log: Sie sehen, welche Nutzer welche Anweisungen wann ausgeführt haben und ob Fehler auftraten. Die Abfrage kann mit weiteren Spalten aus v_monitor.sessions (zur Ermittlung von Client-Adresse und Anwendungsnamen) erweitert oder mit Katalogtabellen verknüpft werden, um Objektmetadaten anzufügen.

Wichtige Felder in einem Vertica Audit-Log

Obwohl die Systemansichten von Vertica viele Spalten enthalten, konzentriert sich ein praktischer Audit-Bericht meist auf eine Kernmenge. Die folgende Tabelle beschreibt die wichtigsten Felder und deren Nutzung bei Untersuchungen.

Feld	Zweck	Beispiel
`user_name`	Identität des Datenbankbenutzers, der die Anweisung ausgeführt hat	`dbadmin`
`request_type`	Oberkategorie wie QUERY, DDL, COPY oder LOAD	`QUERY`
`request`	Vollständiger SQL-Text der Operation (oder ein gekürzter Ausschnitt)	`SELECT col.constraint_name AS pk_name FROM v_catalog...`
`start_timestamp`	Zeitpunkt, zu dem Vertica die Anfrage zu verarbeiten begann	`2025-12-01 15:03:57.385`
`end_timestamp`	Endzeitpunkt; zur Messung der Laufzeit und Überschneidung mit Vorfällen	`2025-12-01 15:03:58.010`
`success`	Boolesches Flag, das anzeigt, ob die Anweisung erfolgreich abgeschlossen wurde	`true`
`error_count`	Anzahl der beim Verarbeiten der Anfrage aufgetretenen Fehler	`0`

Mit diesen Feldern liefert DBeaver Ihnen bereits ein funktionierendes Vertica Audit-Log. Sie können nach Benutzer filtern, nach bestimmten SQL-Mustern suchen oder Ergebnisse als CSV exportieren, um sie weiter zu analysieren. Dennoch hat dieser Ansatz einige Einschränkungen: Die Historie ist auf einen einzelnen Cluster beschränkt, die Aufbewahrung der Logs richtet sich nach den Engine-Einstellungen, und das Korrelation von Ereignissen über Systeme hinweg erfolgt manuell.

Einschränkungen bei der ausschließlichen Verwendung nativer Logs

Native Audit-Logs bieten tiefgehende Details, sind aber in ihrer Reichweite begrenzt. Jeder Vertica-Cluster speichert seine eigene Historie, und Logrotation kann ältere Datensätze unbemerkt entfernen. Außerdem müssen Sie Informationen aus mehreren Ansichten zusammenführen und mit Katalogmetadaten verknüpfen. Wenn Sie mehrere Umgebungen betreiben – Entwicklung, Staging, Produktion – oder Vertica mit anderen Datenbanken kombinieren, wird das schnell unübersichtlich.

Hinzu kommt, dass Engine-Logs und v_monitor-Ansichten Ereignisse nicht automatisch nach Geschäftsregeln kategorisieren. So möchten Sie möglicherweise ein dediziertes Log für „alle DDL-Änderungen im Finance-Schema“ oder „jeden Zugriff auf PII-Spalten“ samt Warnungen bei Verstößen. Dies nur mit nativen Logs zu realisieren, bedeutet eigene Skripte und geplante Abfragen schreiben und pflegen zu müssen.

Zentralisierung der Vertica Audit-Logs mit DataSunrise

DataSunrise begegnet diesen Herausforderungen, indem es als Audit-Schicht vor Vertica agiert. Es erfasst jede SQL-Anweisung, ordnet sie Benutzer, Anwendung und Datenbank zu, wertet sie anhand konfigurierbarer Regeln aus und schreibt das Ergebnis in ein zentrales Audit-Repository. Dieses Repository kann viele Vertica-Cluster und andere Datenplattformen umfassen, sodass Sie eine einheitliche Sicht auf Ihre Datenbankaktivitäten erhalten.

Um das Auditing zu aktivieren, registrieren Sie Vertica als Datenquelle in der DataSunrise-Konsole und erstellen anschließend eine Auditregel – beispielsweise „Vertica Audit Log“ – die festlegt, welche Abfragen und Ereignisse protokolliert werden sollen. Sobald die Regel aktiv ist, erscheint jede passende Aktion im Interface der Transactional Trails.

Vertica Audit-Log – DataSunrise-Benutzeroberfläche zeigt den Audit-Bereich mit Transactional Trails und Serverzeitdetails. — Screenshot der DataSunrise-Oberfläche mit Hervorhebung des „Audit“-Bereichs. Der Tab „Transactional Trails“ ist aktiv, mit filterbarer ID-Liste und Serverzeit auf den 01. Dezember, UTC +3, eingestellt.

DataSunrise Transactional Trails zeigt Vertica Audit-Log-Ereignisse. Jede Zeile stellt eine erfasste Operation dar, inklusive Datenbanktyp, Auditregelname, Benutzerlogin, Client-Anwendung, SQL-Abfrage, Startzeit und Zeilenzahl.

Im Gegensatz zu rohen Engine-Logs ist diese Ansicht für Untersuchung und Berichte optimiert. Sie können nach Regel filtern (z.B. „Vertica Audit Log“), bestimmte Benutzer fokussieren oder nach einer Tabelle oder einem Statement-Muster suchen. Ereignisse lassen sich zudem an SIEM- oder SOAR-Plattformen weiterleiten, dank integrierter Syslog- oder Webhook-Optionen – ohne dass Sie Logs selbst parsen müssen.

Wie DataSunrise Vertica Audit-Logs anreichert

DataSunrise macht mehr als nur die nativen Logs zu spiegeln. Da jede SQL-Anfrage auf der Netzwerkschicht erfasst wird, kann es:

den vollständigen Abfragetext erfassen, auch wenn Vertica interne Logs kürzt.
Auditregeln nach Schema, Tabelle, Benutzer oder Operationstyp anwenden, ohne den Anwendungscode zu ändern.
Ereignisse plattformübergreifend korrelieren, z.B. Vertica, PostgreSQL, Oracle und Cloud-Warehouses in einer Konsole.
höhere Funktionen bedienen wie User Behavior Analysis und Compliance Manager, die auf normalisierten Audit-Daten aufbauen.
flexible Aufbewahrung und Berichterstellung bieten durch geplante Audit-Reports und Exportmöglichkeiten in externe Speicher.

In der Praxis nutzen Organisationen oft die nativen Vertica-Logs für tiefgehende technische Fehlerbehebung und verlassen sich im Tagesbetrieb auf DataSunrise für Sicherheitsüberwachung und Compliance-Nachweise. Diese Kombination liefert sowohl die niedrigstufige Genauigkeit der Engine-Logs als auch die übersichtliche Klarheit einer spezialisierten Audit-Plattform.

Das Ganze zusammenführen

Die Implementierung einer umfassenden Vertica Audit-Log-Strategie erfordert nicht das Verwerfen nativer Werkzeuge. Sie können zunächst v_monitor.query_requests und verwandte Ansichten aus DBeaver abfragen, um zu verstehen, wie Vertica Aktivität aufzeichnet. Diese Ansichten offenbaren, wer welche SQL-Anweisungen wann ausgeführt hat und ob sie erfolgreich waren.

Im nächsten Schritt verbinden Sie Vertica mit DataSunrise, erstellen gezielte Auditregeln und nutzen Transactional Trails, um ein zentrales, langzeitiges Audit-Log über alle Umgebungen hinweg zu pflegen. Durch die Kombination der nativen Vertica-Historie mit DataSunrise’s fortschrittlicher Überwachung, Verhaltensanalyse und Datenschutz-Compliance-Tools erhalten Sicherheits- und Betriebsteams eine einzige verlässliche Quelle zur Untersuchung von Vorfällen, zur Validierung von Kontrollen und zum Nachweis, dass sensible Daten geschützt bleiben.