Audit Trail di Amazon OpenSearch

L’audit trail di Amazon OpenSearch diventa rilevante quando un cluster smette di essere utilizzato solo per il logging e inizia a servire come fonte di dati aziendali e di sicurezza. In un ambiente di produzione tipico, lo stesso dominio OpenSearch riceve query da servizi applicativi, dashboard BI, team di supporto e processi automatizzati. Queste richieste spesso colpiscono gli stessi indici e API, anche se gli utenti e i sistemi dietro di esse hanno ruoli e intenzioni diversi.

Se i team non mantengono un audit trail, i log di servizio disperdono l’attività e non riescono a fornire un quadro coerente. Durante un incidente, i team devono ricostruire gli eventi indirettamente: chi ha acceduto a un indice, quale endpoint ha usato, se ha modificato dati e cosa è accaduto all’interno della stessa sessione. Quando OpenSearch memorizza identificatori dei clienti, log di accesso o eventi di sicurezza, questo approccio diventa rapidamente inaffidabile.

Perché un audit trail è importante per Amazon OpenSearch

Amazon OpenSearch non è un database relazionale, ma memorizza dati persistenti ed esegue operazioni strutturate su questi dati. I client creano indici, aggiornano documenti, eseguono ricerche e recuperano risultati che possono includere campi sensibili. Da una prospettiva di governance, queste azioni rientrano nelle stesse aspettative di audit applicate ai database.

Diversi fattori rendono l’auditing di OpenSearch differente dall’auditing di sistemi basati su SQL:

1. Accesso ai dati basato su API
   La maggior parte delle operazioni OpenSearch arriva come richieste HTTP con payload JSON. La gestione degli indici, l’aggiornamento dei documenti e le operazioni di ricerca si basano su endpoint REST piuttosto che su istruzioni SQL. Un audit trail che comprende solo SQL perderebbe attività critiche sia del piano di controllo che di quello dati.

2. Molti consumatori nello stesso cluster
   Un singolo cluster OpenSearch spesso supporta sia carichi di lavoro di produzione sia accessi temporanei. Senza un audit trail, i team fanno fatica a separare il traffico normale delle applicazioni da job mal configurati, indagini di supporto o scansioni di indici.

3. Operazioni batch modificano grandi volumi
   Operazioni di bulk indexing e bulk update possono modificare grandi insiemi di documenti in una singola chiamata. Quando si verificano problemi, i team necessitano del contesto di sessione della richiesta, non solo della conferma che una richiesta è avvenuta.

4. Dati regolamentati finiscono negli indici
   Quando gli indici contengono identificatori, indirizzi IP, record clienti o incidenti di sicurezza, la cronologia di accesso e modifica rientra nei requisiti di audit di GDPR, HIPAA, PCI DSS e SOX.

Architettura del log di audit di Amazon OpenSearch

DataSunrise implementa un log di audit per Amazon OpenSearch posizionando uno strato di controllo trasparente tra le applicazioni client e il servizio OpenSearch. Le richieste transitano attraverso lo strato DataSunrise, dove il sistema valuta le operazioni e registra gli eventi di audit secondo le policy definite. Questo design evita modifiche agli indici OpenSearch e al codice applicativo.

Questo approccio basato sul traffico si integra con flussi di lavoro più ampi di monitoraggio dell’attività database e consente ai team di analizzare l’attività attraverso utenti, endpoint, indici e intervalli temporali.

Ogni richiesta diventa un record di audit che i team possono filtrare per utente, indice, tipo di azione, timestamp e contesto della regola. Questo filtraggio rende il log di audit pratico per le indagini sugli incidenti e la verifica della conformità.

Definizione delle regole di audit logging per Amazon OpenSearch

Un log di audit è efficace solo quando i team definiscono regole chiare su cosa il sistema deve registrare. DataSunrise utilizza un auditing basato su regole per tracciare l’attività di OpenSearch e memorizzarla in un formato coerente.

Gli input tipici delle regole includono indice o pattern di indice, metodo HTTP, utente o account di servizio e rete di origine. Le regole possono anche catturare il contesto della sessione e gli esiti dell’esecuzione.

La prioritizzazione delle regole permette un auditing più rigoroso per indici sensibili e riduce il rumore proveniente dal traffico operativo a basso rischio. In ambienti OpenSearch ad alto volume, questa distinzione determina se i dati di audit restano utilizzabili.

Log di audit transazionale e contesto di sessione

Dopo che i team abilitano le regole di audit, DataSunrise registra l’attività in audit trail transazionali. Invece di considerare ogni richiesta come evento isolato, il sistema raggruppa azioni correlate in sessioni e transazioni.

Questo raggruppamento cambia il modo in cui i team indagano sugli incidenti. Possono esaminare sessioni che hanno eseguito ricerche multiple, seguite da aggiornamenti in blocco, prima di chiudersi. Questo approccio offre una sequenza chiara di azioni invece di affidarsi solo ai timestamp.

Ogni voce del log di audit generalmente include:

• Endpoint OpenSearch e nome indice
• Metodo HTTP e tipo di richiesta
• Identificatori di sessione e transazione
• Indirizzo IP di origine e contesto utente
• Timestamp, tempo di esecuzione e stato errori

Questo livello di dettaglio supporta la risposta agli incidenti, le indagini interne e la raccolta di prove di conformità.

Contenuto raccolto tramite il log di audit di Amazon OpenSearch

La copertura del log di audit di Amazon OpenSearch include creazione e cancellazione degli indici, modifiche di configurazione, operazioni di inserimento, aggiornamento e cancellazione dei documenti, query di ricerca e aggregazione, richieste in bulk, apertura e chiusura sessioni, oltre ad operazioni fallite o rifiutate.

I team possono archiviare i dati del log di audit localmente o indirizzarli verso sistemi esterni e integrarli in workflow centralizzati di sicurezza dei dati.

Log di audit e controlli di sicurezza

Il log di audit funge anche da superficie di controllo. Osservando quali endpoint utilizzano le identità, i team possono rilevare pattern come scansioni ripetute, esportazioni non intenzionali o account di servizio che invocano endpoint amministrativi da nuovi segmenti di rete.

DataSunrise può combinare i log di audit con regole di sicurezza e rilevamento comportamentale per segnalare precocemente attività sospette su OpenSearch e inserirle in flussi di indagine consolidati.

Adattamento alla conformità e prove di audit

Se dati regolamentati sono indicizzati, le organizzazioni devono produrre prove che mostrino accesso e modifiche tracciabili. DataSunrise correla i record di audit con i workflow di conformità per GDPR, HIPAA, PCI DSS e SOX. I team possono generare report usando la generazione di report quando necessitano di prove di audit.

I workflow automatici tramite il Compliance Manager riducono lo sforzo manuale quando i team necessitano di prove di audit ripetibili.