Wie man Vertica auditieren kann

Das Auditieren von Vertica ist mehr als nur einen Logging-Schalter umzulegen. Um zu verstehen, wer auf die Datenbank zugegriffen hat, welche SQL-Anweisungen ausgeführt wurden und wie sich diese Aktionen auf die Daten ausgewirkt haben, benötigen Sie sowohl die nativen Überwachungsansichten von Vertica als auch einen zentralen Ort, um diese Ereignisse zu speichern und zu analysieren. Diese Anleitung zeigt einen praktischen Arbeitsablauf: Zuerst wird v_monitor verwendet, um native Beweise zu sammeln, dann wird DataSunrise Data Audit genutzt, um eine vollständige Vertica-Audit-Trail aufzubauen.

Wir werden verwandte Themen wie Audit-Logs, Datenbank-Aktivitätsüberwachung und Compliance Manager ansprechen. Für die Konfiguration auf Engine-Ebene und Details zum Katalog bleibt die offizielle Vertica-Dokumentation die maßgebliche Quelle.

Schritt 1 – Native Vertica-Audit-Quellen prüfen

Vertica speichert die Aktivitätshistorie in seinem v_monitor-Schema und in Engine-Protokolldateien. Diese Ansichten sind nicht speziell als „Audit“ gekennzeichnet, enthalten aber die meisten Informationen, die benötigt werden, um nachvollziehen zu können, was passiert ist:

• v_monitor.query_requests – eine Zeile pro Anfrage, inklusive Benutzername, Anfragetyp, SQL-Text, Zeitstempel und Erfolgsflag.
• v_monitor.sessions – Sitzungs-Metadaten wie Sitzungs-ID, Client-Host und Anmeldezeit.
• Engine-Protokolldateien – Authentifizierungsversuche, Fehler und Engine-Warnungen, die im Verzeichnis der Vertica-Logs geschrieben werden.

Sie können diese Daten direkt in DBeaver prüfen, indem Sie eine einfache Abfrage ausführen:

SELECT *
FROM v_monitor.query_requests
ORDER BY start_timestamp DESC
LIMIT 100;

Native Vertica-Historie aus v_monitor.query_requests in DBeaver. Jede Zeile identifiziert den Knoten, Benutzer, die Sitzung, den Anfragetyp und den SQL-Text und bietet so eine grundlegende Audit-Übersicht.

Dieser Ansatz beantwortet bereits viele Audit-Fragen: Welche Benutzer haben welche Anweisungen ausgeführt und wann. Wenn Sie jedoch mehrere Cluster betreiben oder Auditdaten über Monate oder Jahre aufbewahren müssen, ist das manuelle Abfragen von v_monitor und das Kopieren der Ergebnisse aus DBeaver schwer aufrechtzuerhalten. Die nächsten Schritte zeigen, wie Sie von rohen Logs zu einem strukturierten Vertica-Audit-Arbeitsablauf wechseln.

Schritt 2 – Lücken beim nativen Vertica-Audit identifizieren

Bevor zusätzliche Werkzeuge hinzugefügt werden, ist es hilfreich, klar zu definieren, wo die native Auditierung Schwächen hat:

• Cluster-lokale Ansicht. Abfragen gegen v_monitor zeigen nur, was in einem einzelnen Cluster passiert ist. Sie müssen sich separat mit jeder Umgebung verbinden.
• Begrenzte Aufbewahrung. Die Historie ist durch Speicherplatz und Konfiguration begrenzt. Alte Einträge verschwinden, wenn Tabellen bereinigt werden und Logdateien rotiert werden.
• Keine Politikabstraktion. Vertica zeichnet zwar genau auf, was passiert ist, bietet aber keine regelbasierten Audit-Policies wie „logge alle DDL im Schema Finance“ an.
• Manueller Export und Korrelation. Um SIEM- oder Berichtssysteme zu versorgen, müssen Sie eigene Exporte schreiben, Logs von mehreren Knoten zusammenführen und Formate normalisieren.

Um von der Ad-hoc-Inspektion zu wiederholbaren Audits zu wechseln, fügen die meisten Teams eine dedizierte Schicht hinzu, die SQL in Echtzeit erfassen, Audit-Regeln anwenden und Ereignisse in einem zentralen Repository speichern kann.

Schritt 3 – DataSunrise als Vertica-Audit-Schicht einführen

DataSunrise Activity Monitoring ergänzt Vertica, indem es SQL-Verkehr auf dem Weg zur Datenbank erfasst. Im Proxy-Modus verbinden sich Anwendungen über DataSunrise; im Sniffer-Modus lauscht DataSunrise am gespiegelten Netzwerkverkehr. In beiden Fällen kann es die Statements sehen, die Vertica erhält, und diese anhand von Audit-Regeln bewerten.

1. Anwendungen senden SQL-Verkehr an Vertica.
2. DataSunrise beobachtet jede Anfrage, die den überwachten Pfad durchläuft oder überschreitet.
3. Übereinstimmende Ereignisse werden in einem internen Audit-Repository gespeichert und optional an Syslog- oder SIEM-Systeme weitergeleitet.
4. Das Ergebnis ist ein zentralisierter Vertica-Audit-Trail, der in der DataSunrise Web-Benutzeroberfläche und APIs zugänglich ist.

Die verbleibenden Schritte beschreiben, wie dieser Auditpfad konfiguriert wird.

Schritt 4 – Vertica in DataSunrise registrieren

Registrieren Sie zunächst Vertica als überwachte Datenbank in der DataSunrise-Konsole, damit die Plattform versteht, wie erfasste SQL-Anfragen interpretiert werden:

1. Öffnen Sie Konfiguration → Datenbanken.
2. Klicken Sie auf Hinzufügen und wählen Sie Vertica als Datenbanktyp aus.
3. Geben Sie den Hostnamen, Port, Datenbank und ein Dienstkonto mit ausreichenden Berechtigungen zur Einsicht in die benötigten Objekte an.
4. Wählen Sie aus, ob diese Instanz im Proxy-Modus oder Sniffer-Modus auditiert wird.
5. Klicken Sie auf Testen, um zu bestätigen, dass DataSunrise auf die Vertica-Instanz zugreifen kann.

Registrierung einer Vertica-Instanz in DataSunrise. Nach erfolgreicher Verbindung kann der Datenverkehr, der über den überwachten Pfad fließt, auditiert werden.

Nach diesem Schritt kann DataSunrise erfasste SQL-Anfragen einer spezifischen Vertica-Datenbank zuordnen und korrekt in der Audit-Oberfläche anzeigen.

Schritt 5 – Audit-Regel für Vertica erstellen

Definieren Sie im nächsten Schritt, welche Vertica-Operationen als Audit-Ereignisse behandelt werden sollen. DataSunrise verwendet Audit-Regeln, um zu steuern, was protokolliert wird und wohin die Logs gelangen:

1. Öffnen Sie Audit → Regeln.
2. Erstellen Sie eine neue Regel, z. B. VERTICA_audit.
3. Wählen Sie die Vertica-Instanz aus der Datenbankliste.
4. Wählen Sie auf der Registerkarte für Abfragetypen die zu protokollierenden Operationen aus (z. B. SELECT, INSERT, UPDATE, DELETE und DDL).
5. Optional können Sie die Regel auf bestimmte Schemata oder Tabellen einschränken, z. B. jene mit regulierten Daten.
6. Konfigurieren Sie die Protokolleinstellungen: Speicherung im internen Audit-Speicher, Syslog oder beides.
7. Aktivieren Sie die Regel und speichern Sie die Konfiguration.

Ab diesem Zeitpunkt wird jede Vertica-Anfrage, die den Bedingungen der Regel entspricht, im DataSunrise Audit-Repository geschrieben.

Schritt 6 – Vertica Audit-Trail in Transactional Trails validieren

Um zu überprüfen, ob die Auditierung wie erwartet funktioniert, erzeugen Sie einige Testaktivitäten über den überwachten Pfad (zum Beispiel eine Sitzung öffnen und schließen, eine Einstellung ändern und eine DDL-Anweisung ausführen) und überprüfen dann die Ergebnisse:

1. Gehen Sie zu Audit → Transactional Trails.
2. Filtern Sie nach Datenbanktyp = Vertica und nach Ihrer Auditregel (z. B. VERTICA_audit).
3. Untersuchen Sie die erfassten Abfragen, Zeitstempel und Zeilenanzahlen.

Vertica-Auditergebnisse in DataSunrise Transactional Trails. Die VERTICA_audit-Regel protokolliert DDL- und sitzungsbezogene Anweisungen, die vom JDBC-Treiber ausgeführt werden, mit Zeitstempeln und Zeilenanzahlen.

Sie sollten nun Audit-Einträge sehen, die mit der von Ihnen ausgeführten Testaktivität übereinstimmen. Wenn die Ereignisse korrekt erscheinen, funktioniert das Vertica-Auditieren über DataSunrise.

Schritt 7 – Audit-Aufgaben natives Vertica vs. DataSunrise zuordnen

Die folgende Tabelle zeigt, wie sich übliche Audit-Aufgaben unterscheiden, wenn man sich nur auf native Vertica-Ansichten verlässt gegenüber der Verwendung eines DataSunrise-unterstützten Vertica-Audit-Trails.

Schritt 8 – Best Practices für das Auditieren von Vertica

Nachdem die Grundlagen eingerichtet sind, helfen einige Praktiken dabei, Ihr Vertica-Audit sowohl effektiv als auch handhabbar zu halten:

• Definieren Sie Audit-Regeln für Schemata, die regulierte, finanzielle oder anderweitig sensible Daten speichern.
• Kombinieren Sie Transactional Trails mit Session Trails, um vollständige Benutzerverläufe rekonstruieren zu können.
• Wählen Sie Aufbewahrungszeiträume, die den regulatorischen Anforderungen und der Speicherkapazität entsprechen.
• Überprüfen Sie Auditberichte regelmäßig gemeinsam mit Sicherheits- und Compliance-Verantwortlichen.
• Verwenden Sie User Behavior Analysis, um ungewöhnliche Muster hervorzuheben, anstatt jede Anweisung manuell zu prüfen.

Fazit

Das Auditieren von Vertica beginnt mit dem Verständnis dessen, was die Datenbank bereits in v_monitor und Engine-Logs aufzeichnet. Diese nativen Quellen liefern die Rohdaten: Wer hat welche Anweisungen wann ausgeführt. Um eine nachhaltige Audit-Praxis aufzubauen, fügen Sie DataSunrise als dedizierte Audit-Schicht hinzu, die SQL-Verkehr erfassen, konsistente Regeln anwenden, die Historie zentralisieren und Auditdaten in einer Form präsentieren kann, auf die Sicherheits-, Risiko- und Compliance-Teams sich verlassen können.

Durch die Registrierung von Vertica in DataSunrise, das Erstellen fokussierter Audit-Regeln und die Validierung der Ergebnisse in Transactional Trails bewegen Sie sich von gelegentlichem Log-Scraping hin zu einem strukturierten, wiederholbaren Audit-Arbeitsablauf. Das Ergebnis ist eine Vertica-Audit-Trail, die Datenschutz- und Compliance-Vorschriften erfüllt, Incident Response unterstützt und dauerhafte Transparenz darüber bietet, wie auf Ihre analytischen Daten zugegriffen und diese geändert werden.