CloudTrail e S3: quando il log non vede l’accesso agli oggetti

Un bucket di log popolato non dimostra che ogni accesso ai dati venga registrato. Nel cloud la prima verifica di una detection è l’esistenza dell’evento necessario, nel servizio di raccolta e nella regione corretti.

Due piani di osservazione

La documentazione CloudTrail sugli eventi distingue management events, relativi alle operazioni di gestione, e data events, relativi all’attività sui dati. Per S3 la lettura di un oggetto e una modifica alla configurazione di un bucket non appartengono alla stessa classe di osservazione.

La guida S3 chiarisce che i trail non registrano data events per impostazione predefinita. Configurare risorse e selettori pertinenti, valutando volume e costi. Non assumere che l’event history di management sia sufficiente per ricostruire letture degli oggetti.

Un inventario della copertura

Proposta operativa: per ogni dato critico riportare account, regione, tipo di risorsa, selettore, classi read/write raccolte, destinazione dei log e responsabilità della configurazione. Distinguere trail ed event data store; una verifica su uno non prova la copertura dell’altro.

Controllare che il percorso di consegna funzioni e che l’analista abbia accesso al repository corretto. Un evento presente nel servizio sorgente può essere assente nel SIEM per filtri, errori di parsing o ritardi. Conservare timestamp sorgente e tempo di ingestione per quantificare questa differenza.

Collaudare con un oggetto sintetico

1. Preparare un bucket o prefisso di laboratorio incluso nei selettori; usare un file privo di dati sensibili.
2. Con una sessione autorizzata eseguire una scrittura e una lettura dell’oggetto.
3. Annotare identità di sessione, orari, regione e nome dell’oggetto.
4. Cercare gli eventi nel repository di raccolta e nel SIEM, attendendo la consegna.
5. Verificare che le classi previste siano presenti e distinguere un esito negato da uno riuscito.

Il test è sintetico e non richiede modificare la policy del bucket di produzione. Ripeterlo dopo cambiamenti ai selettori. Un test positivo su un prefisso non certifica gli altri; registrare la risorsa provata e la configurazione effettiva.

Attribuire una sessione prima di segnalarla

CloudTrail espone informazioni sull’identità e sul contesto della chiamata. Nella caccia, correlare le credenziali temporanee con l’operazione che ha creato la sessione, quando disponibile. Un ruolo condiviso può richiedere evidenze ulteriori per attribuire l’attività a una persona o a un workload.

Indirizzo sorgente e user agent sono indizi contestuali. NAT, proxy, automazioni e SDK legittimi possono produrre valori comuni a molti utenti. Non chiudere l’attribuzione su un singolo IP; confrontare identità, risorsa, orario e tipo di operazione con il proprietario del servizio.

Mitigazioni: proteggere l’evidenza e gestire il rumore

Valutare un repository di log separato dal workload, con permessi di lettura e scrittura distinti. La guida AWS propone un bucket in un account separato come possibilità organizzativa: questo non rende automaticamente immutabili i log e non sostituisce il progetto dei permessi.

Una detection iniziale può cercare accessi a oggetti da sessioni insolite dopo una modifica alle autorizzazioni. È un’ipotesi editoriale: prima di attivarla, confrontare deployment, job di manutenzione e processi di business. Misurare la copertura mancante insieme ai falsi positivi. L’esito “nessun evento trovato” deve riportare quali selettori e intervalli sono stati effettivamente verificati.

Fonti essenziali

Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.

• AWS — tipi di eventi CloudTrail
• AWS — logging CloudTrail per S3