Come eseguire l’audit di Vertica

L’audit di Vertica è più di un semplice attivare un interruttore di logging. Per capire chi ha avuto accesso al database, quali istruzioni SQL sono state eseguite e come quelle azioni hanno influenzato i dati, è necessario avere sia le viste di monitoraggio native di Vertica sia un luogo centralizzato per memorizzare e analizzare quegli eventi. Questa guida mostra un flusso di lavoro pratico: prima utilizzando v_monitor per raccogliere le evidenze native, poi usando DataSunrise Data Audit per costruire un audit trail completo di Vertica.

Faremo riferimento a temi correlati come Audit Logs, Database Activity Monitoring e Compliance Manager. Per la configurazione a livello di motore e i dettagli di catalogo, la documentazione ufficiale Vertica resta la fonte autorevole.

Passo 1 – Ispezionare le fonti di audit native di Vertica

Vertica memorizza la cronologia delle attività nel suo schema v_monitor e nei file di log del motore. Queste viste non sono etichettate “audit”, ma contengono la maggior parte delle informazioni necessarie per ricostruire cosa è successo:

• v_monitor.query_requests – una riga per ogni richiesta, inclusi nome utente, tipo di richiesta, testo SQL, timestamp e flag di successo.
• v_monitor.sessions – metadati di sessione come ID sessione, host client e ora di login.
• File di log del motore – tentativi di autenticazione, errori e avvisi del motore scritti nella directory dei log di Vertica.

Puoi ispezionare questi dati direttamente in DBeaver eseguendo una query base:

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

Cronologia nativa di Vertica da v_monitor.query_requests in DBeaver. Ogni riga identifica il nodo, l’utente, la sessione, il tipo di richiesta e il testo SQL, fornendo una vista di audit di base.

Questo approccio risponde già a molte domande di audit: quali utenti hanno eseguito quali istruzioni e quando. Tuttavia, se gestisci più cluster o se devi conservare i dati di audit per mesi o anni, interrogare manualmente v_monitor e copiare i risultati da DBeaver è difficile da sostenere. I passi successivi mostrano come passare dai log grezzi a un flusso di lavoro strutturato di audit Vertica.

Passo 2 – Identificare le lacune nell’audit nativo di Vertica

Prima di aggiungere altri strumenti, è utile chiarire dove l’audit nativo presenta delle limitazioni:

• Vista locale per cluster. Le query su v_monitor mostrano solo cosa è successo su un singolo cluster. Devi connetterti a ogni ambiente separatamente.
• Conservazione limitata. La storia è vincolata da spazio disco e configurazione. I record vecchi scompaiono man mano che le tabelle vengono pulite e i file di log ruotano.
• Nessuna astrazione politica. Vertica registra fedelmente cosa è accaduto, ma non fornisce politiche di audit basate su regole come “loggare tutte le DDL nello schema finance”.
• Esportazione e correlazione manuali. Per alimentare sistemi SIEM o di reporting, devi scrivere i tuoi export, unire i log da più nodi e normalizzare i formati.

Per passare da un’ispezione ad hoc a un audit ripetibile, la maggior parte dei team aggiunge un livello dedicato in grado di catturare SQL in tempo reale, applicare regole di audit e memorizzare gli eventi in un repository centrale.

Passo 3 – Introdurre DataSunrise come livello di audit per Vertica

DataSunrise Activity Monitoring completa Vertica catturando il traffico SQL in transito verso il database. Distribuito in modalità proxy, le applicazioni si connettono attraverso DataSunrise; in modalità sniffer, DataSunrise ascolta il traffico speculare. In entrambi i casi, può vedere le query ricevute da Vertica e valutarle rispetto alle regole di audit.

1. Le applicazioni inviano il traffico SQL verso Vertica.
2. DataSunrise osserva ogni richiesta che passa attraverso o oltre l’interfaccia monitorata.
3. Gli eventi corrispondenti vengono scritti in un repository di audit interno e, opzionalmente, inoltrati a sistemi Syslog o SIEM.
4. Il risultato è un audit trail centralizzato di Vertica, visibile tramite l’interfaccia web e le API di DataSunrise.

I passaggi rimanenti descrivono come configurare questo percorso di auditing.

Passo 4 – Registrare Vertica in DataSunrise

Per prima cosa, registra Vertica come database monitorato nella console di DataSunrise in modo che la piattaforma possa interpretare correttamente l’SQL catturato:

1. Apri Configurazione → Database.
2. Clicca su Aggiungi e scegli Vertica come tipo di database.
3. Fornisci Hostname, Porta, Database e un account di servizio con privilegi sufficienti per vedere gli oggetti necessari.
4. Seleziona se questa istanza sarà auditata in modalità proxy o sniffer.
5. Clicca su Test per confermare che DataSunrise riesce a raggiungere l’istanza Vertica.

Registrazione di un’istanza Vertica in DataSunrise. Una volta convalidata la connessione, il traffico Vertica che passa lungo il percorso monitorato può essere auditato.

Dopo questo passaggio, DataSunrise può associare l’SQL catturato a un database Vertica specifico e visualizzarlo correttamente nell’interfaccia di audit.

Passo 5 – Creare una regola di audit per Vertica

Successivamente, definisci quali operazioni di Vertica devono essere trattate come eventi di audit. DataSunrise utilizza regole di audit per controllare cosa viene loggato e dove:

1. Apri Audit → Regole.
2. Crea una nuova regola, ad esempio VERTICA_audit.
3. Seleziona l’istanza Vertica dalla lista dei database.
4. Nella scheda tipi di query, seleziona le operazioni da loggare (ad esempio SELECT, INSERT, UPDATE, DELETE e DDL).
5. Facoltativamente, limita la regola a schemi o tabelle specifiche, come quelle che contengono dati regolamentati.
6. Configura le impostazioni di log: salva nell’archivio audit interno, su Syslog oppure entrambi.
7. Abilita la regola e salva la configurazione.

Da questo momento in poi, ogni richiesta Vertica che soddisfa le condizioni della regola viene scritta nel repository di audit di DataSunrise.

Passo 6 – Validare l’audit trail di Vertica in Transactional Trails

Per verificare che l’audit funzioni come previsto, genera qualche attività di prova attraverso il percorso monitorato (ad esempio, apri e chiudi una sessione, cambia una impostazione, esegui una istruzione DDL), quindi controlla i risultati:

1. Vai su Audit → Transactional Trails.
2. Filtra per Tipo di Database = Vertica e per la tua regola di audit (es. VERTICA_audit).
3. Ispeziona le query catturate, i timestamp e il conteggio delle righe.

Risultati di audit Vertica in DataSunrise Transactional Trails. La regola VERTICA_audit logga DDL e istruzioni legate a sessioni eseguite dal driver JDBC, con timestamp e conteggio righe.

Dovresti ora vedere le voci di audit corrispondenti all’attività di test che hai eseguito. Se gli eventi appaiono correttamente, l’audit di Vertica tramite DataSunrise sta funzionando.

Passo 7 – Mappare i compiti di audit tra Vertica nativo e DataSunrise

La tabella sottostante mostra come i compiti comuni di auditing differiscono utilizzando solo le viste native di Vertica rispetto a un audit trail Vertica supportato da DataSunrise.

Passo 8 – Best practice per l’audit di Vertica

Una volta poste le basi, alcune pratiche aiutano a mantenere l’audit di Vertica efficace e gestibile:

• Definire regole di audit per schemi che contengono dati regolamentati, finanziari o altrimenti sensibili.
• Combinare Transactional Trails con Session Trails per ricostruire interi percorsi utente.
• Scegliere periodi di conservazione allineati ai requisiti normativi e alla capacità di storage.
• Rivedere regolarmente i report di audit con i responsabili di sicurezza e conformità.
• Utilizzare l’analisi del comportamento utente per evidenziare pattern insoliti invece di scansionare manualmente ogni istruzione.

Conclusioni

L’audit di Vertica parte dalla comprensione di cosa il database registra già in v_monitor e nei log del motore. Queste fonti native forniscono i fatti grezzi: chi ha eseguito quali istruzioni e quando. Per costruire una pratica di audit sostenibile, si aggiunge DataSunrise come livello dedicato di audit che può catturare il traffico SQL, applicare regole coerenti, centralizzare la cronologia e presentare i dati di audit in una forma su cui i team di sicurezza, rischio e conformità possono fare affidamento.

Registrando Vertica in DataSunrise, creando regole di audit focalizzate e validando i risultati in Transactional Trails, si passa da un’attività occasionale di scraping dei log a un flusso di lavoro strutturato e ripetibile di auditing. Il risultato è un audit trail di Vertica che si allinea alle normative sulla conformità dei dati, supporta la risposta agli incidenti e offre una visibilità duratura su come i tuoi dati analitici sono accessibili e modificati.