Perché il logging è il cuore della security posture

In uno scenario multi-account, la domanda chiave dell’esame è quasi sempre “quale servizio risponde a questa esigenza?”. Distingui tre piani: CloudTrail risponde a chi ha fatto cosa (API activity), AWS Config a com’era configurata la risorsa nel tempo e se è conforme, i VPC Flow Logs a quale traffico di rete è transitato. CloudWatch è il livello di observability che raccoglie metriche e log e permette di reagire con alarm. Confondere questi ruoli è l’errore più frequente: sono complementari, non alternativi.

CloudTrail: chi ha fatto cosa

CloudTrail registra le chiamate API sull’account. Di default cattura i management event (control plane); i data event (accesso a oggetti S3, invocazioni Lambda, operazioni DynamoDB) vanno abilitati esplicitamente e possono generare volumi elevati, quindi si filtrano per risorsa. In un’organizzazione, usa un organization trail creato dal management account: applica il trail a tutti gli account membri, che non possono disabilitarlo, ed è la risposta corretta quando lo scenario chiede copertura centralizzata e a prova di manomissione da parte dei team.

Per l’integrità dei log attiva la log file validation: CloudTrail produce file di digest firmati con hash SHA-256, così puoi provare che nessun file sia stato alterato o cancellato. Abbina bucket S3 con Object Lock, versioning e una bucket policy/SCP che vieti s3:DeleteObject e la disattivazione del trail. CloudTrail Lake è il data lake gestito con retention lunga interrogabile in SQL: utile quando serve analisi investigativa senza costruire pipeline su S3.

CloudWatch Logs, metric filter e alarm

CloudTrail può consegnare gli eventi anche a CloudWatch Logs, abilitando il rilevamento quasi in tempo reale. Il pattern d’esame è: metric filter che cerca un pattern nei log (es. uso delle credenziali root, chiamate Deny/UnauthorizedOperation, modifiche a security group) e incrementa una metrica, poi un CloudWatch alarm che su soglia notifica via SNS o innesca una remediation. Ricorda che il metric filter agisce solo sui log futuri: per query storiche o ad hoc usa CloudWatch Logs Insights.

AWS Config, VPC Flow Logs e analisi centralizzata con Athena

AWS Config registra le configuration item di ogni risorsa e ne mantiene la timeline; le Config rule (managed o custom via Lambda/Guard) valutano la conformità (es. bucket non pubblici, volumi EBS cifrati). Le conformance pack raggruppano rule e le remediation via SSM Automation correggono le deviazioni. Un aggregator consolida dati Config di più account e region per una vista di compliance unica.

I VPC Flow Logs catturano i metadati del traffico IP (source/destination, porte, azione ACCEPT/REJECT) a livello di VPC, subnet o ENI; puoi pubblicarli su CloudWatch Logs o direttamente su S3. Non contengono il payload dei pacchetti: per l’ispezione del contenuto serve Traffic Mirroring.

Per la centralizzazione, il modello di riferimento è un account di logging dedicato (log archive) verso cui tutti gli account consegnano trail, flow logs e altri log in un bucket S3 con accesso cross-account. Su quei dati si esegue analisi con Amazon Athena: SQL serverless direttamente su S3, ideale per indagini a costo controllato. Partiziona i dati (per account/region/data) per ridurre i dati scansionati e quindi la spesa per query.

Trappole tipiche d’esame

  • Traffico di rete bloccato/rifiutato da indagare → VPC Flow Logs (REJECT): CloudTrail registra le API, non i pacchetti; per capire cosa una NACL o un security group ha respinto servono i flow logs con azione REJECT.
  • Prova di integrità dei log CloudTrail → log file validation + digest: non basta cifrare il bucket; sono i digest file firmati SHA-256 a dimostrare che nessun log è stato alterato.
  • Accessi a oggetti S3 non tracciati → abilitare i data event: di default CloudTrail logga solo i management event; l’S3 object-level activity richiede data event espliciti.
  • “La risorsa era conforme ieri e oggi no” → AWS Config, non CloudTrail: la timeline di configurazione e la valutazione delle rule sono di Config; CloudTrail dice chi ha fatto la modifica, non lo stato di conformità.
  • Analisi economica su grandi volumi di log storici → Athena su S3: per query ad hoc su TB di log conviene Athena partizionato, non conservare tutto in CloudWatch Logs.
  • Copertura non disattivabile su tutti gli account → organization trail: un trail per-account può essere spento dal team locale; l’organization trail creato dal management account no.