Monitoraggio dell'attività del database: cosa osservare e come farlo

I database contengono i dati di clienti, pagamenti e salute che interessano maggiormente a regolatori, attaccanti e revisori. Le funzionalità di audit native in SQL Server, Oracle, MySQL e PostgreSQL registrano modifiche a oggetti e permessi, ma offrono poca visibilità su chi ha letto righe sensibili.

Il Rapporto sulla Sicurezza dei Dati e dell'Identity Netwrix 2026 ha rilevato che il 75% delle esposizioni di dati sensibili inizia con identità compromesse o permessi configurati in modo errato. L'audit nativo offre la minima visibilità dove queste identità hanno più potere: account privilegiati che possono modificare direttamente il registro di audit.

Il monitoraggio dell’attività del database produce un registro indipendente di accessi, modifiche e azioni amministrative, così i team di sicurezza possono indagare sugli incidenti, dimostrare la conformità e rilevare abusi prima che un account compromesso o una modifica silenziosa alla configurazione diventino una violazione segnalabile.

Che cos'è il monitoraggio dell'attività del database?

Il monitoraggio dell’attività del database (DAM) è una disciplina di sicurezza che cattura, memorizza e analizza l’attività di utenti e amministratori all’interno di un database, indipendentemente dal motore del database stesso. Su richiesta, risponde a chi si è connesso, cosa ha letto o modificato e se qualcuno ha cambiato la configurazione di audit.

DAM si affianca al monitoraggio delle prestazioni ma ha uno scopo diverso. Gli strumenti di performance tracciano CPU, I/O e latenza delle query per mantenere il motore efficiente. DAM invece cattura la dichiarazione SQL, l’identità dell’utente, l’indirizzo IP del client e il timestamp, così puoi collegare l’attività a una persona o servizio nominato.

Uno strumento DAM raccoglie queste informazioni tramite un network tap, un agente host, o la funzione di audit del database stesso, quindi le inoltra a un repository esterno al database affinché il record sopravviva a un account amministratore compromesso.

Perché il monitoraggio dell’attività del database è importante

Per un amministratore di database (DBA) o un analista della sicurezza, la parte difficile di qualsiasi incidente o audit è dimostrare chi ha toccato cosa. Senza una traccia indipendente nel database, i team ricostruiscono manualmente quella prova da log parziali, di solito entro una scadenza.

I dati sensibili si concentrano nel livello del database

I record dei clienti, i dati dei titolari di carta e le protected health information (PHI) risiedono nelle tabelle del database. Qualsiasi dato regolamentato passa attraverso un database a un certo punto. Quando l'accesso al database non è monitorato, gli asset più sensibili dell'ambiente perdono il loro livello più vicino di responsabilità, e ogni controllo a valle dipende da una traccia che non è mai stata catturata.

I log nativi del database non possono supportare un'indagine

La traccia predefinita di SQL Server cattura modifiche a oggetti e permessi ma non l'attività SELECT, e conserva solo 100 MB di cronologia. Peggio ancora, Microsoft avverte che gli sysadminExpand possono manomettere la traccia di controllo stessa, motivo per cui NIST SP 800-53 AU-9(2) richiede di conservare i record di audit su un sistema separato da quello controllato.

I framework di conformità richiedono una traccia di audit del database

Ogni framework principale considera l'attività del database come prova. PCI DSS v4.0.1 Il Requisito 10 impone 12 mesi di accesso registrato ai dati del titolare della carta e l'integrità del registro di controllo. Il 45 CFR 164.312(b) di HIPAA richiede meccanismi che registrino ed esaminino l'attività nei sistemi ePHI.

Nel suo rapporto di ispezione 2023 su Ernst & Young Incorporated (Pubblicazione PCAOB n. 104-2024-113), il PCAOB ha citato la società per non aver valutato come i proprietari del controllo del cliente abbiano esaminato le modifiche dirette al database dietro il suo sistema contabile, in un audit sul controllo interno della rendicontazione finanziaria ai sensi di SOX.

Il GDPR Articolo 5(2) richiede ai titolari di dimostrare la conformità ai principi del regolamento, incluso mostrare chi ha avuto accesso ai dati personali.

Gli account compromessi e gli abusi interni emergono prima nel database

Un accesso valido sembra legittimo a ogni sistema tranne a quello che registra cosa è stato fatto, motivo per cui il furto di credenziali e l'uso improprio interno raramente attivano i controlli perimetrali. Il 2026 Data Breach Investigations Report di Verizon ha rilevato che l'abuso di credenziali è presente nel 39% delle violazioni in qualche punto della catena di attacco, e il monitoraggio continuo del database è spesso il primo luogo per individuare il movimento laterale che segue.

Attività del database da monitorare

Le categorie seguenti hanno un peso sufficiente in termini di sicurezza o conformità per giustificare regole di rilevamento dedicate. Insieme coprono chi è entrato, cosa ha letto o modificato e se qualcuno ha manomesso il record: le domande con cui inizia ogni indagine.

Eventi di autenticazione e connessione

I record di accesso sono il primo luogo in cui una credenziale rubata diventa visibile. I tentativi di accesso falliti rivelano tentativi di indovinare la password o credential stuffing, mentre gli accessi riusciti da fonti insolite rivelano che le credenziali vengono usate dove non dovrebbero.

Gli accessi privilegiati e degli account di servizio meritano particolare attenzione, poiché un account di servizio che si connette improvvisamente da una nuova workstation invece che dal suo solito livello applicativo vale quasi sempre la pena di essere investigato. Oracle abilita una predefined failed-logon policy per impostazione predefinita nei nuovi database, anche se quelli aggiornati spesso devono attivarla manualmente.

Letture di dati sensibili ed esportazioni di massa

La visibilità diretta su chi ha interrogato tabelle regolamentate distingue il sapere che si è verificata un’esposizione dal dimostrare cosa è stato prelevato. L’accesso per la prima volta a una tabella mai toccata da un utente e l’estrazione massiva tramite strumenti come bcpExpand o expdpExpand, sono i modelli di lettura più importanti da monitorare, lo stesso comportamento che i controlli di data loss prevention osservano all’endpoint.

Modifiche allo schema e alla configurazione

Le modifiche allo schema e alla configurazione possono distruggere i dati o rendere cieco il monitoraggio progettato per catturare tutto il resto. CREATE, ALTER, Expande DROPExpand istruzioni contro tabelle e stored procedure necessitano di allarmi dedicati, e le modifiche alla configurazione di audit meritano la risposta più rapida. Microsoft fornisce xp_cmdshellExpand disabilitato di default in SQL Server perché abilitarlo concede a un attaccante una shell di comandi.

Privilegi nuovi o aumentati

Una singola concessione di privilegi può trasformare un account limitato in uno che legge tutto o disabilita completamente il registro di controllo. Le modifiche all'appartenenza ai ruoli, i nuovi accessi e qualsiasi aggiunta al ruolo sysadmin in SQL Server, o un ruolo DBA equivalente in Oracle, sono avvisi inderogabili, lo stesso privilege escalation modello monitorato a livello di identità. Il principio del minor privilegio è il controllo di base. La policy ORA_ACCOUNT_MGMT di Oracle lo copre, ma è disabilitata di default.

Modifiche ai dati nelle tabelle sensibili

Quando uno stipendio o il saldo di un conto cambia senza autorizzazione, la prima domanda è quale fosse il valore prima della modifica. I record di audit nativi registrano solo il testo della dichiarazione, non i valori delle righe, quindi è necessario un meccanismo separato che conservi il contenuto prima e dopo, come il Change Data Capture di SQL Server, il logging binario dell'immagine della riga di MySQL o i PostgreSQL triggers. Gli avvisi su modifiche massive o fuori orario a tabelle regolamentate corrispondono a MITRE T1565, Data Manipulation.

Attività che rompe il normale schema

Le regole di base rilevano attività che sembrano ordinarie isolate, ma insolite per l’account che le esegue, come un utente che interroga improvvisamente 10 tabelle in cinque minuti o un account applicativo noto che si connette da un nuovo indirizzo IP.

Questa è l'unica categoria che si basa sull'analisi SIEM piuttosto che sulla configurazione nativa di audit, lo stesso approccio basato sulla linea di base comportamentale che identity threat detection utilizza a livello di account.

Come implementare il monitoraggio delle attività del database

Procedi attraverso i cinque passaggi in ordine, poiché ciascuno dipende dal precedente. Ciò che definisci nel passaggio 1 determina quale metodo di raccolta si adatta al passaggio 2, e così via.

Si presume anche un piccolo team che non può esaminare manualmente ogni evento, quindi diversi passaggi seguenti si basano su rollout graduali e baseline automatizzate invece che su una valutazione manuale.

1. Definire l'ambito di ciò che sarà monitorato

Inizia inventariando quali database contengono dati regolamentati o sensibili per l'azienda, come stipendi, titolari di carte, dati sanitari o proprietà intellettuale, e classificandoli in base al driver normativo. Questo inventario conta solo quando sai quali tabelle contengono campi sensibili, quindi esegui prima data classification; saltalo e una specifica di audit delle buste paga non avrà nulla a cui fare riferimento.

La posta in gioco è reale: il sondaggio alla base del Netwrix 2026 Data and Identity Security Report ha rilevato che il 57% delle organizzazioni non mantiene continuamente un inventario dei dati sensibili, quindi la maggior parte dei team inizia questo passaggio alla cieca.

Una volta mappati i database sensibili, estendi lo stesso inventario agli account privileged, condivisi e di servizio che li utilizzano, e impegnati a monitorare ogni sessione privileged completamente, anche quando il logging degli utenti regolari rimane selettivo.

CIS Safeguard 8.5 stabilisce il minimo per questo impegno. Al minimo, acquisire nome utente, timestamp e indirizzi di origine e destinazione per ogni asset che contiene dati sensibili.

2. Scegli un metodo di raccolta che corrisponda al tuo ambiente

La cattura passiva della rete tramite una porta SPAN è il punto di partenza se si necessita di zero carico sul server. Tuttavia, questo compromesso di carico zero comporta la perdita di visibilità su Transport Layer Security (TLS) forward-secret, connessioni locali e database gestiti nel cloud.

Quando bloccare un’istruzione è più importante che vederla, un proxy inline è più adatto, poiché termina TLS da solo, anche se questo controllo aggiunge latenza e rende il proxy una dipendenza di disponibilità.

Se le connessioni locali necessitano ancora di copertura dopo ciò, e il team può tollerare il costo della CPU più il lavoro di rivalidazione che ogni aggiornamento del kernel o del database comporta, un agente host colma questa lacuna. I team che eseguono database come servizio (DBaaS) o che necessitano di visibilità nelle procedure memorizzate e nella crittografia, vi arrivano invece abbinando l’audit nativo alla raccolta senza agenti.

Oracle segnala un sovraccarico CPU a una cifra media singola per l'auditing nativo fino a 360.000 record di audit all'ora. La raccolta senza agenti aggiunge ulteriore carico, quindi testare la combinazione prima di implementarla.

In pratica, la maggior parte dei team combina comunque i metodi, poiché la documentazione AVDF di Oracle consiglia di abbinare il monitoraggio della rete con la revisione del database in modo che ciascuno copra i punti ciechi dell’altro.

3. Definisci politiche e soglie di allerta su cui un piccolo team può intervenire

Attiva le regole a fasi, non tutte insieme, perché abilitare tutto dal primo giorno sommergerebbe un piccolo team di falsi positivi. Inizia questo rollout graduale con la manomissione delle audit e le concessioni sysadmin, mappate dalle sei categorie di attività sopra, poiché queste due hanno la minore tolleranza per un allarme mancato.

NIST SP 800-94 avverte che un sistema appena distribuito genera tipicamente troppi falsi positivi prima che le sue regole siano completamente adattate all'ambiente, ed è proprio per questo che l'approccio a fasi è importante.

Le regole di volume e modello di accesso richiedono un trattamento diverso. Eseguile come anomalie, tarate su almeno una settimana di dati di base, dello stesso ordine di grandezza che Microsoft Sentinel usa per la sua regola di anomalie sulle righe interessate, che si allena per 14 giorni.

Aspettate che queste soglie rimangano locali al vostro ambiente piuttosto che seguire un numero universale, poiché l'anomalia per un team è di 100 righe, per un altro 500.000, e solo la vostra baseline rivela quale sia quale.

4. Centralizza gli eventi del database e correlali con il contesto dell’identità

Centralizza prima la raccolta dei log, come richiesto da CIS Safeguard 8.9, e utilizza uno strumento che filtri grandi set di eventi in un insieme che un umano può esaminare, come raccomandato da NIST SP 800-61 Rev. 3. Una volta che questa pipeline esiste, correlare ogni evento con l'account dietro di esso, poiché un log centralizzato senza contesto di identità ti lascia ancora a leggere istruzioni SQL grezze invece di nomi.

In Microsoft Sentinel, quella correlazione avviene tramite tabelle specifiche. Inoltra gli eventi di audit di Azure SQL alla tabella SQLSecurityAuditEventsExpand (o AzureDiagnosticsExpand nelle configurazioni precedenti), gli eventi Windows di SQL Server a SecurityEventExpand, e gli avvisi di Defender a SecurityAlert;Expand quindi usa la tabella IdentityInfoExpand per associare la persona dietro ogni account.

Gli utenti di Splunk e IBM QRadar possono seguire lo stesso schema con le proprie ricerche di identità; il vantaggio è trasformare "qualcuno ha eseguito una grande SELECT" in "un account contractor aggiunto a sysadmin due ore fa ha eseguito una grande SELECT."

5. Testare, ottimizzare e mantenere la pipeline di monitoraggio

Testa l'intera pipeline con attività rappresentative prima di fidarti in produzione. Aggiungi un login di test a un ruolo server, modifica una specifica di audit ed esegui un'esportazione di 600 righe, quindi conferma che ogni avviso arrivi con l'identità corretta allegata. Una pipeline che registra l'evento ma perde il contesto dell'identità è solo a metà costruita.

Ricostruisci le baseline ogni volta che le applicazioni cambiano e ricontrolla periodicamente le policy di audit, poiché Oracle's AVDF documentation avverte che un DBA può modificarle o eliminarle. Recupera e rivedi le impostazioni secondo un programma; CIS Safeguard 8.1 richiede questa revisione almeno annualmente.

La conservazione richiede la stessa disciplina. Impostala sul mandato più severo applicabile, con il minimo di 12 mesi di PCI DSS come base, e mantieni anche l'impostazione diagnostica che alimenta una pipeline Azure SQL nella tua lista monitorata, poiché eliminarla può interrompere silenziosamente la raccolta.

Come Netwrix ti aiuta a monitorare l'attività del database

La maggior parte del lavoro sopra, dalla definizione dell’ambito alla correlazione del contesto di identità, si applica indipendentemente dagli strumenti che usi. Netwrix Auditor copre la raccolta, gli avvisi e i dettagli prima e dopo per SQL Server e Oracle, e Netwrix Access Analyzer aggiunge il livello di permessi e dati sensibili.

Monitoraggio degli accessi e degli accessi privilegiati

Netwrix Auditor SQL Server monitoring registra accessi riusciti e falliti e traccia l'attività del DBA, incluse azioni privilegiate e modifiche ai ruoli del server. Il suo Oracle Database monitoring software monitora accessi riusciti e falliti e controlla le istruzioni SQL e i privilegi. Per entrambe le fonti, è possibile configurare avvisi per inviare email a un analista o eseguire uno script definito come azione di risposta.

I report di Auditor servono anche come prova di conformità. First National Bank and Trust of Beloit utilizza Netwrix Auditor come soluzione principale per la conformità OCC e ora impiega un’ora, invece di una settimana, per prepararsi alle verifiche. Bank of the South lo usa per proteggere i dati critici per l’azienda e rispettare PCI DSS e GLBA, risparmiando almeno 40 ore all’anno nella preparazione delle verifiche.

Cattura dei valori prima e dopo le modifiche ai dati

Netwrix Auditor for SQL Server funziona di default in modalità senza trigger, leggendo il registro di traccia ogni cinque minuti senza carico aggiuntivo e segnalando chi ha modificato cosa e quando. La modalità basata su trigger aggiunge i valori prima e dopo per INSERT, UPDATE e DELETE, che l’audit nativo non può fornire, a costo di un carico aggiuntivo sui server con molte transazioni.

Collegare l'attività ai dati sensibili

Netwrix Auditor applica il contesto dei dati sensibili a livello di tabella in modalità senza trigger, utilizzando le tabelle e le policy che hai configurato, così i report possono segnalare attività contro tabelle regolamentate. Per una scoperta e analisi dei permessi più approfondita su SQL Server e Oracle, Netwrix Access Analyzer mappa i permessi effettivi e mette in evidenza dati sovraesposti, oltre a quanto coperto da Auditor da solo.

Distribuzione con impatto minimo sulla produzione

Netwrix Auditor raccoglie da remoto, quindi solo la modalità basata su trigger tocca direttamente le tabelle monitorate. La raccolta Oracle avviene tramite Oracle Instant Client sul server Auditor ogni dieci minuti, e la lettura delle tracce di SQL Server ogni cinque minuti. I componenti aggiuntivi inoltrano i record di attività a Splunk, IBM QRadar e ArcSight per i team che già centralizzano su un SIEM.

Metti in pratica il monitoraggio dell'attività del database

Inizi con l'istanza che contiene i dati più regolamentati, stabilisca una baseline e si espanda solo dopo che il primo set di avvisi produce risultati concreti.

Per i carichi di lavoro gestiti nel cloud, la copertura dipende dalla fonte dei dati e dal modello di distribuzione. Netwrix Access Analyzer rileva dati sensibili e analizza i permessi su SQL Server, Azure SQL, Amazon RDS per SQL Server e Oracle.

Richiedi una demo per vedere come Netwrix può aiutarti a monitorare l'attività del database, centralizzare il registro di controllo e rilevare gli abusi prima che diventino una violazione.