Il vincolo è spesso la visibilità, non la sofisticazione dell’attaccante
Quando un incidente AWS viene investigato in ritardo, la discussione spesso si concentra su quanto avanzata fosse l’intrusione. In molti ambienti il vincolo reale è più semplice: non c’è abbastanza telemetria per ricostruire cosa è successo.
CloudTrail, VPC Flow Logs e data events sono imperfetti. Non rivelano l’intento né catturano payload. Il loro valore è preservare pezzi di evidenza indipendenti che, insieme, rispondono a domande di base: quale identità ha agito, quando, da dove, su quale risorsa e con quale esito.
Come scompare la traccia
Negli ambienti multi-account, il volume di eventi cresce rapidamente. Qualcuno rivede il costo di storage, indexing o SIEM e pone la domanda inevitabile: ci serve così tanto logging?
Le ottimizzazioni arrivano a pezzi:
- gli eventi di lettura vengono scartati come «rumore»
- i Flow Logs sono limitati alla produzione, o solo al traffico rifiutato
- i data events S3 vengono disabilitati per il volume
- la retention è tagliata a 30 o 90 giorni
Ogni decisione può sembrare ragionevole. Insieme possono rimuovere il contesto necessario per capire un compromise.
La ricognizione è ancora attività
Dopo aver ottenuto credenziali valide, un attaccante non inizia necessariamente cancellando dati. Fa domande. Enumera. Mappa.
In termini di API AWS sono operazioni legittime Get*, List* e Describe*. Per un team di prodotto possono sembrare rumore. Per un attaccante sono una mappa.
Se la telemetria di lettura scompare dalla pipeline di sicurezza, un’azione successiva come un cambio di policy può restare visibile. Ciò che si perde è l’inizio della storia: i minuti di enumerazione precedenti.
Esiste anche il pattern inverso: tenere le letture e filtrare le scritture. L’esplorazione resta visibile… e il momento in cui cambiano ruoli, trust policy o security group diventa incompleto.
Lettura e scrittura descrivono fasi diverse. Sceglierne solo una non è «visibilità ottimizzata»; è cecità asimmetrica.
Cosa dovrebbe preservare un’architettura di logging utile
Una postura solida non è «registrare tutto senza giudizio». È definire segnali minimi sostenibili e utili per forensics e detection:
- eventi di management CloudTrail con retention allineata al rischio
- copertura di account e regioni rilevanti, non solo dell’ambiente «principale»
- Flow Logs dove il contesto di rete conta
- data events selettivi su risorse ad alto valore
- un percorso chiaro dallo storage dei log a chi investiga
L’obiettivo non è un museo di eventi. È la capacità di rispondere a domande di sicurezza e di business con evidenza quando conta.
Come si collega al lavoro TechRebel
Negli engagement di sicurezza AWS e osservabilità partiamo da una premessa semplice: la visibilità è una decisione di architettura, non un extra opzionale. Valutiamo cosa viene registrato, cosa viene trattenuto e cosa si può ancora ricostruire prima di parlare di controlli aggiuntivi.
Per revisionare la postura di logging e detection nella vostra organizzazione AWS, prenotate una riunione o vedete AWS & Cloud Security.