Scopo di una Traccia di Audit del Database

Man mano che il numero di fughe di dati continua a crescere, gli enti governativi, le aziende commerciali, le istituzioni mediche e finanziarie, le organizzazioni educative cercano di proteggere i loro dati sensibili da furti da parte dei malintenzionati. La maggior parte delle industrie deve supportare la conformità, la sicurezza e le operazioni. Leggi e regolamenti che controllano l’uso dei registri elettronici come SOX, HIPAA, PCI DSS, GDPR fanno delle tracce di audit un elemento importante di protezione contro le violazioni della sicurezza, supportano la conformità con le normative e il superamento di vari tipi di audit. In altre parole, qualsiasi azienda, agenzia governativa o organizzazione educativa che gestisce dati sensibili trarrà vantaggio dal mantenere log di audit accurati.

Obiettivi della Traccia di Audit del Database

L’idea generale dell’auditing del database è sapere chi e quando ha avuto accesso ai tuoi dati, e quali modifiche sono state apportate.

Tipicamente, l’auditing è utilizzato per:

Le domande chiave affrontate dall’auditing del database includono:

• Chi ha avuto accesso e ha modificato dati sensibili nel tuo sistema?
• Quando sono state apportate modifiche specifiche ai dati?
• Come ha ottenuto l’accesso a questi dati un particolare utente?
• Queste modifiche erano autorizzate?
• Gli utenti privilegiati hanno abusato dei loro ampi diritti di accesso?

Teoricamente, tutte queste richieste possono essere soddisfatte utilizzando sia i meccanismi di audit nativi del database sia un software dedicato. Ma il punto è che non tutti i log di audit sono ugualmente preziosi per i revisori. Soffermiamoci su questo argomento per un po’.

Utilizzare Meccanismi di Audit Integrati nel Database

Le capacità di audit native variano tra diversi database. Per supportare più fonti di dati, gli amministratori di audit devono implementare vari tipi di metodi di ingestion, trasformazione e memorizzazione dei dati. Questo approccio può potenzialmente duplicare i dati di audit esistenti.

Il problema è che quando si utilizzano strumenti di audit nativi, può essere troppo complicato trovare certe informazioni sugli eventi necessari per un audit. Inoltre, i log degli strumenti nativi non sono progettati per scopi di audit. Sono raccolti per gli amministratori di database, così che possano conoscere i bug del database e i problemi di prestazioni.

Sfide dell’Audit Nativo

Quando si utilizzano solo strumenti nativi per l’auditing, si incontreranno alcune difficoltà durante il lavoro:

• Le capacità di audit native che memorizzano i dati di audit nello stesso database possono portare a grandi archivi di log di audit che consumano una parte significativa della memoria del database.
• Gli strumenti nativi spesso raccolgono informazioni in formati non facilmente leggibili dagli auditor e dai team di sicurezza, ostacolando la loro capacità di analizzare i log in modo efficace. Le soluzioni di terze parti forniscono spesso capacità di reporting personalizzabili per affrontare questo problema.
• Sia le soluzioni native che quelle di terze parti possono creare un sovraccarico sul server del database, potenzialmente influenzando le prestazioni. Tuttavia, alcuni strumenti di terze parti, come DataSunrise, offrono sottosistemi di audit configurabili che possono operare in diverse modalità, permettendo agli utenti di minimizzare o addirittura eliminare l’impatto sulle prestazioni.

Se devi soddisfare le esigenze degli auditor e semplificare il lavoro del tuo team di sicurezza, usa semplicemente un software stand-alone dedicato. Dovrebbe essere sufficiente per rispondere alle domande più critiche che sorgono durante un audit dei dati.

Requisiti per un’Applicazione di Traccia di Audit Dedicata

Le soluzioni di audit dedicate tipicamente offrono un approccio centralizzato e uniforme per l’auditing di tutte le fonti di dati supportate.

Lo renderemo semplice, quindi ci sono solo tre principali requisiti per un software di auditing avanzato:

• Dovrebbe monitorare gli utenti privilegiati che hanno accesso ai dati sensibili.
• Il log di audit per questi dati e utenti dovrebbe essere conservato per il periodo richiesto e i rapporti appropriati dovrebbero essere generati periodicamente.
• Tale sistema dovrebbe includere meccanismi di prevenzione degli accessi e di allerta attivati quando viene rilevata un’attività non autorizzata.

Soluzione di Audit di DataSunrise

Basandoci sui requisiti menzionati sopra, esaminiamo più da vicino le capacità di DataSunrise.

Il componente di Audit dei Dati di DataSunrise è in grado di auditare TUTTE le azioni degli utenti e le query inviate al database target. L’auditing semplicemente non dipende dal tipo di utente del database. Quindi è in grado di auditare sia le query degli utenti regolari che le query degli utenti privilegiati.

DataSunrise memorizza i risultati dell’audit in un database integrato SQLite o in un database esterno come PostgreSQL, MS SQL Server, Vertica, Redshift, Aurora MySQL, MySQL. Grazie al componente di reportistica avanzata DataSunrise’s Report Gen, puoi presentare i tuoi dati auditati come un rapporto personalizzabile adatto alle esigenze degli auditor. Puoi anche creare rapporti periodicamente secondo un programma.

Questa suite completa include un componente di Sicurezza dei Dati capace di prevenire l’accesso non autorizzato degli utenti al database target e notificare il personale di sicurezza o gli amministratori via email o messaggistica istantanea. Il sistema può identificare e prevenire in tempo reale SQL injection. Inoltre, presenta sia strumenti di mascheramento dinamico che statico dei dati per aiutare a prevenire fughe di dati accidentali causate da insider.

Quindi, DataSunrise combina tre componenti critici per la sicurezza del database. Audit dei Dati per l’audit, Sicurezza dei Dati per il controllo degli accessi e Mascheramento dei Dati per sia mascheramento dinamico che mascheramento statico dei dati.