Amazon SCS-C02: Registrazione, audit e analisi forense — Guida allo studio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Rilevamenti e Correzione di Amazon GuardDuty

GuardDuty è un servizio gestito di rilevamento delle minacce che acquisisce continuamente tre flussi di telemetria in background: eventi di gestione di CloudTrail (e opzionalmente eventi dati di S3), VPC Flow Logs e log delle query DNS di Route 53. Non è necessario abilitare, distribuire o pagare separatamente per queste origini di log affinché GuardDuty possa utilizzarle: il servizio legge direttamente un flusso duplicato. Questo è il motivo per cui GuardDuty può essere attivato con una singola chiamata API e iniziare a generare rilevamenti in pochi minuti, senza alcuna progettazione di pipeline per i log.

I rilevamenti hanno un valore di gravità compreso tra 0.1 e 8.9, mappato su Basso (0.1–3.9), Medio (4.0–6.9) e Alto (7.0–8.9). I rilevamenti tipici che richiedono un’azione includono UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B e Recon:IAMUser/MaliciousIPCaller. I pattern di correzione variano a seconda del rilevamento: una compromissione basata su EC2 generalmente giustifica l’isolamento dell’istanza con un security group di quarantena, la creazione di snapshot dei volumi per l’analisi forense e la sua terminazione; un rilevamento basato su IAM richiede la rotazione delle chiavi di accesso e la revisione dell’attività recente del principal in CloudTrail.

Per ambienti multi-account, abilitare GuardDuty tramite AWS Organizations e designare un account amministratore delegato (comunemente l’account degli strumenti di sicurezza, o Security Tooling). L’amministratore delegato può abilitare automaticamente GuardDuty in ogni account membro, esistente e nuovo, in ogni Regione in cui il servizio è attivato. Senza la configurazione dell’amministratore delegato, i rilevamenti di GuardDuty di ogni account rimangono isolati in ciascun membro: abilitare i rilevatori individualmente non li aggrega in modo centralizzato.

AWS Security Hub e Aggregazione Multi-Account

Security Hub è il livello di normalizzazione e aggregazione. Acquisisce i rilevamenti da GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config e decine di prodotti partner, convertendoli nel formato AWS Security Finding Format (ASFF). Esegue anche i propri controlli rispetto a standard come CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS e NIST 800-53.

L’aggregazione multi-account e multi-regione funziona allo stesso modo di GuardDuty: registrare Security Hub con l’amministratore delegato di Organizations, quindi designare una Regione di aggregazione in modo che i rilevamenti provenienti da altre Regioni vengano replicati in quel singolo pannello di controllo. Un errore comune è abilitare Security Hub in ogni account e aspettarsi una vista consolidata: senza l’amministratore delegato e la Regione di aggregazione, ogni account continua a vedere solo i propri rilevamenti.

Security Hub non invia email direttamente. Le notifiche e le automazioni vengono create abbinando gli eventi di rilevamento di Security Hub sul bus di eventi predefinito di EventBridge e inoltrandoli a SNS, Lambda, Step Functions o documenti di Systems Manager Automation.

CloudTrail: Eventi di Gestione vs Eventi Dati

CloudTrail registra due categorie di attività, e confonderle è la lacuna più comune nella copertura del rilevamento.

Eventi di gestione (Management events): operazioni a livello di control plane — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Abilitati di default su qualsiasi nuovo trail.
Eventi dati (Data events): operazioni ad alto volume a livello di risorsa — chiamate a livello di oggetto S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), Invoke di Lambda, chiamate API a livello di item di DynamoDB. Disabilitati di default e fatturati separatamente.

Se un requisito di sicurezza è “rilevare quando qualcuno rende pubblico un oggetto S3 tramite PutObjectAcl,” un trail con i soli eventi di gestione non lo catturerà, perché le modifiche alle ACL su singoli oggetti sono eventi dati. Allo stesso modo, l’egress tramite GetObject da un bucket sensibile è invisibile senza gli eventi dati. PutBucketAcl (a livello di bucket) è un evento di gestione e verrebbe registrato; PutObjectAcl (a livello di oggetto) non lo è.

Utilizzare un trail di organizzazione (organization trail) creato nell’account di gestione o nell’account amministratore delegato, in modo che gli eventi di ogni account membro vengano catturati in un unico bucket S3 e non possano essere disabilitati dai principal degli account membri. Proteggere il trail con:

Crittografia SSE-KMS sul bucket di destinazione, con una policy della chiave KMS che neghi la decrittografia non autorizzata.
Una bucket policy che neghi s3:PutObject senza il service principal di CloudTrail e neghi la cancellazione.
Convalida dell’integrità dei file di log abilitata, che produce file di digest orari firmati con SHA-256 in modo che eventuali manomissioni possano essere provate.

Esempio di creazione:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

Alerting con EventBridge e SNS

EventBridge è l’infrastruttura di routing che connette i rilevamenti a sistemi di risposta umani e automatizzati. Ogni rilevamento di GuardDuty, ogni aggiornamento di un rilevamento di Security Hub e ogni evento derivato da CloudTrail arriva sul bus di eventi predefinito. Le regole utilizzano pattern di eventi JSON per filtrare, per poi distribuire (fan out) a una o più destinazioni (target) (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Un pattern canonico per i rilevamenti ad alta gravità di GuardDuty, inoltrati sia a un topic SNS per le email sia a un delivery stream di Firehose che alimenta OpenSearch per l’analisi:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Per i rilevamenti CRITICAL di Security Hub instradati via email:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

L’endpoint email è una semplice sottoscrizione SNS; il sottoscrittore deve confermare tramite il link ricevuto via email prima che l’invio inizi. Una singola regola può avere fino a cinque destinazioni (target), quindi l’alerting e l’analisi a valle non richiedono regole duplicate.

Quando si creano i pattern, ricordare che gli eventi di gestione di CloudTrail arrivano con "detail-type": "AWS API Call via CloudTrail", mentre gli eventi dati non compaiono sul bus predefinito a meno che non si configuri un trail che pubblichi su CloudWatch Logs e si utilizzi un filtro per le metriche (metric filter) o ci si sottoscriva tramite l’integrazione degli eventi dati di CloudTrail in EventBridge. Scrivere una regola EventBridge che corrisponda a "eventName": "PutObjectAcl" sul bus predefinito senza abilitare gli eventi dati non produrrà alcuna corrispondenza (zero matches).

Log di CloudWatch, Insights, Filtri per le Metriche e Allarmi

L’invio dei log di CloudTrail (e dei VPC Flow Logs, e dei log delle applicazioni) a CloudWatch Logs abilita il rilevamento quasi in tempo reale. I filtri per le metriche (Metric filters) scansionano ogni evento di log in entrata confrontandolo con un pattern e incrementano una metrica personalizzata di CloudWatch; un allarme di CloudWatch (CloudWatch alarm) su quella metrica attiva SNS.

Esempio: allarme su ripetuti fallimenti di accesso alla console.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights fornisce funzionalità di interrogazione ad-hoc utilizzando un linguaggio di query appositamente creato, utile per la risposta agli incidenti dopo l’attivazione di un allarme:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Trappole Comuni

Mancata attività a livello di oggetto S3: PutObjectAcl, GetObject e DeleteObject sono eventi di dati. Un trail di default acquisisce solo eventi di gestione; è necessario aggiungere selettori per gli eventi di dati, altrimenti il finding, l’allarme o la regola di EventBridge che puntano a quei nomi di API non si attiveranno mai, senza alcuna notifica.
Visibilità centralizzata senza amministratore delegato: abilitare GuardDuty o Security Hub in ogni account non aggrega i risultati. I risultati (finding) vengono raccolti centralmente solo dopo aver registrato un amministratore delegato in AWS Organizations e, per Security Hub, aver scelto una Regione di aggregazione. Gli inviti tra account funzionano per ambienti di piccole dimensioni ma non scalano e richiedono un’accettazione per ogni singolo account.
Confusione tra eventi di gestione e di dati nei filtri: PutBucketAcl (bucket) è un evento di gestione e funziona in qualsiasi filtro standard di EventBridge o per le metriche; PutObjectAcl (oggetto) no, indipendentemente da quanto ben formulato sia il pattern, a meno che gli eventi di dati non siano abilitati e consegnati alla stessa pipeline.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce una AWS Organization multi-account con un account di sicurezza dedicato e un account di logging centralizzato. Il loro ambiente include PII (Personally Identifiable Information) dei clienti in S3, API transazionali su EC2/Lambda, e CloudTrail che già scrive eventi di gestione in un bucket S3 centrale; i team desiderano un rilevamento più rapido e una risposta coordinata tra gli account.

Sfida: Gli ingegneri della sicurezza hanno rilevato un picco improvviso di GET su S3 e relativi finding di GuardDuty che suggeriscono una potenziale esfiltrazione di dati, ma gli allarmi sono rumorosi e mancano di un contesto CloudTrail correlato e di un contenimento automatizzato tra gli account.

Approccio Consigliato:

Abilitare Amazon GuardDuty in ogni account membro e designare l’account di sicurezza come amministratore delegato di GuardDuty; abilitare la protezione per gli eventi di dati S3 in modo che i finding includano anomalie di accesso a livello di oggetto.
Configurare CloudTrail per ogni account per consegnare gli eventi di gestione al bucket S3 centrale per la conservazione e per inoltrare eventi di dati selezionati ad alto valore (S3 GetObject/PutObject/DeleteObject e Lambda Invoke) a CloudWatch Logs nell’account di sicurezza per un’ispezione a bassa latenza.
Attivare AWS Security Hub nell’account di sicurezza e abilitare l’aggregazione cross-account con gli account membri in modo che i finding di GuardDuty, i finding derivati da CloudTrail e i risultati di Config/Inspector siano centralizzati e normalizzati.
Creare regole di EventBridge che corrispondano a finding di alta gravità di GuardDuty e Security Hub e li instradino a SNS per notifiche pager e a una Lambda di remediation che utilizzi il contesto di CloudTrail per intraprendere azioni di contenimento (revocare le chiavi API, rimuovere la sessione IAM, isolare l’ENI di EC2).
Aggiungere filtri per le metriche di CloudWatch Logs per tassi anomali di s3:GetObject, filtrati per principal IAM, e un allarme che attivi la stessa pipeline EventBridge/SNS/Lambda; utilizzare le query di CloudWatch Logs Insights nell’account di sicurezza per arricchire gli allarmi con eventi CloudTrail correlati per il triage degli incidenti.

Motivazione: Centralizzare i finding (GuardDuty + Security Hub) e inviare eventi di dati CloudTrail mirati a CloudWatch abilita la correlazione a bassa latenza, l’allarmistica e il contenimento automatizzato tramite EventBridge/SNS/Lambda, allineandosi con le best practice AWS per il rilevamento, l’aggregazione cross-account e la risposta automatizzata.

CloudTrail Centralizzato e Integrità dei Log

CloudTrail è la registrazione autorevole dell’attività delle API AWS, e il fondamento di qualsiasi architettura di audit è un singolo trail multi-regione che consegna i log a un unico bucket S3 centralizzato, idealmente in un account dedicato all’archiviazione dei log all’interno di AWS Organizations. Un trail multi-regione acquisisce automaticamente gli eventi di gestione in ogni Regione corrente e in qualsiasi Regione che AWS lancerà in futuro — un trail a singola regione crea punti ciechi nel momento in cui un workload viene avviato altrove, il che rappresenta il classico fallimento di completezza durante gli audit. Se applicato a livello di organizzazione, il trail acquisisce anche gli eventi di ogni account membro, quindi un nuovo account che si unisce all’organizzazione è coperto senza alcuna configurazione per singolo account.

Abilitare la validazione dei file di log sul trail. CloudTrail consegnerà quindi ogni ora un file di digest firmato allo stesso bucket S3, contenente gli hash SHA-256 dei file di log consegnati. Il comando aws cloudtrail validate-logs percorre la catena dei digest e rileva manomissioni, cancellazioni o lacune. Senza la validazione, un difensore non può dimostrare che i log non sono stati alterati dopo un incidente, il che li invalida come prova forense.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

I fallimenti nella consegna sono quasi sempre problemi di permessi a valle, non bug di CloudTrail. Il bucket S3 deve esistere prima della creazione del trail, la sua bucket policy deve concedere s3:PutObject a cloudtrail.amazonaws.com con una condizione aws:SourceArn che corrisponda al trail, e il proprietario dell’oggetto deve essere il proprietario del bucket (bucket-owner-full-control). Se il trail utilizza SSE-KMS, la policy della CMK deve permettere kms:GenerateDataKey* per il service principal di CloudTrail, e ogni consumatore (Athena, ingegneri della sicurezza, parser Lambda) deve avere il permesso kms:Decrypt su quella chiave. Una modalità di guasto comune: i log vengono consegnati correttamente, ma le query di Athena restituiscono “AccessDenied” perché il ruolo di query non ha il permesso Decrypt sulla CMK di crittografia dei log. Risolvilo sulla policy della chiave, non disabilitando la crittografia.

Log di CloudWatch, Filtri di Metrica e Allarmi in Tempo Reale

CloudTrail consegna i log a S3 in batch a intervalli di 5-15 minuti — un tempo adeguato per audit retrospettivi ma troppo lento per il rilevamento in tempo reale. Per generare allarmi su eventi sensibili, è possibile inviare il trail in streaming a CloudWatch Logs (un’opzione del trail) o instradare eventi specifici tramite EventBridge. L’approccio con CloudWatch Logs utilizza filtri di metrica (metric filters) che effettuano il pattern-matching degli eventi JSON e incrementano una metrica di CloudWatch, la quale a sua volta attiva un allarme CloudWatch e una notifica SNS. L’esempio canonico è l’accesso alla console con l’utente root:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge è spesso la scelta migliore per eventi specifici e ben noti (disattivazione di una chiave KMS, modifiche a policy IAM) perché le sue regole possono attivare direttamente Lambda o Step Functions senza alcun costo associato a Logs. Utilizzare i filtri di metrica quando si necessita di conteggi aggregati o di visualizzazione su dashboard.

La retention su CloudWatch Logs ha come impostazione predefinita Never Expire (Non scade mai), un’opzione costosa e raramente corretta. Impostare una retention esplicita per ogni gruppo di log (aws logs put-retention-policy) in linea con il regime di conformità — comunemente 90 giorni “hot” in CloudWatch con un archivio a lungo termine in S3 tramite un filtro di sottoscrizione o Kinesis Data Firehose.

Per l’igiene dei dati sensibili, applicare le policy di protezione dei dati di CloudWatch Logs (data protection policies) a livello di account. Queste policy utilizzano identificatori di dati gestiti (numeri di carta di credito, chiavi segrete AWS, codici fiscali) per mascherare le stringhe corrispondenti durante l’ingestion. Fondamentalmente, per visualizzare i dati in chiaro è necessaria l’autorizzazione logs:Unmask; concederla solo a un ruolo di tipo break-glass. Gli utenti che possono leggere il gruppo di log ma non possiedono l’autorizzazione Unmask vedono solo asterischi. Una policy a livello di account si applica a tutti i gruppi di log attuali e futuri, il che rappresenta il controllo corretto — le policy per singolo gruppo tendono a divergere man mano che nuovi servizi creano nuovi gruppi.

Query dei Log su Larga Scala: Insights e Athena

Due motori di query si occupano di diversi livelli di dati.

CloudWatch Logs Insights esegue query sui dati già presenti in CloudWatch Logs utilizzando un linguaggio di query appositamente creato. Ideale per dati operativi recenti (log di Lambda, VPC Flow Logs in Logs, log applicativi). È veloce, non richiede la configurazione di uno schema, ma è limitato dalla retention di CloudWatch e dal costo per GB scansionato.
Amazon Athena esegue query SQL Presto/Trino su dati in S3. Ideale per query forensi su larga scala su log di CloudTrail, log di accesso di ALB, VPC Flow Logs archiviati in S3 e log di CloudFront. Il costo è di 5 $ per TB scansionato; utilizzare la partition projection o le partizioni di Glue per data/Regione per ridurre drasticamente i costi di scansione.

Un tipico caso d’uso forense: identificare chi ha disattivato una chiave KMS. Poiché il JSON di CloudTrail è annidato, la tabella Athena creata da CloudTrail espone userIdentity come una struct:

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Per l’analisi di bot su un ALB, abilitare i log di accesso dell’ALB verso S3, definire una tabella Athena sul prefisso dei log, quindi eseguire una join con una tabella di indirizzi IP noti come malevoli e visualizzare l’aggregazione in QuickSight. QuickSight legge i dati da Athena, quindi la pipeline è: ALB → S3 → Athena → QuickSight. L’invio dei log di ALB a CloudWatch Logs Insights non è un percorso supportato nativamente — i log di ALB possono essere inviati solo a S3.

I VPC Flow Logs possono essere inviati a entrambe le destinazioni: scegliere Logs per indagini tattiche del tipo filter dstPort=3389 and action="REJECT", e S3 (in formato Parquet, partizionato) per query di trend su scala mensile.

Raccolta di Prove con Audit Manager

AWS Audit Manager automatizza la raccolta continua di prove (evidence) mappate su framework come PCI DSS, HIPAA, SOC 2 e CIS. Raccoglie le prove da regole di Config, risultati di Security Hub, eventi di CloudTrail e dall’inventario delle risorse, e le raggruppa in valutazioni di controllo (control assessments). Quando abilitato nell’account di gestione di Organizations o in un account amministratore delegato, raccoglie dati da tutti gli account membri, producendo un report di valutazione (assessment report) — un pacchetto compresso (zip) di prove con un manifest — che gli auditor accettano in sostituzione di screenshot manuali. Questa è la risposta corretta ogni volta che uno scenario richiede la raccolta di prove continue, multi-account e allineate a un framework: Config da solo fornisce la conformità delle risorse ma nessuna mappatura a un framework; Security Hub fornisce i risultati (findings) ma nessun pacchetto di valutazione; un report Athena personalizzato non è continuo.

Riepilogo delle trappole

Incolpare CloudTrail per i log mancanti è solitamente sbagliato: il bucket potrebbe non esistere, la policy del bucket potrebbe rifiutare il principal di CloudTrail o la proprietà degli oggetti potrebbe essere configurata in modo errato. Controlla prima S3.
Un trail a singola regione sembra più economico ma produce una cronologia di audit incompleta; multi-regione è la risposta corretta predefinita per una copertura a livello di organizzazione.
I log crittografati con SSE-KMS sono invisibili ad Athena, ai parser Lambda o agli ingegneri a meno che la policy della CMK non conceda kms:Decrypt a tali principal — disabilitare la crittografia non è la soluzione; correggere la policy della chiave lo è.

Problema pratico: scenario d’uso

Scenario: Meridian Financial gestisce una AWS Organization multi-account con account di produzione, staging e un account dedicato al logging. Il loro ambiente ospita API rivolte ai clienti, analytics e segreti amministrati tramite IAM, e necessitano di un logging centralizzato e a prova di manomissione, oltre a strumenti di indagine rapidi per supportare la risposta agli incidenti e le richieste di conformità.

Sfida: Una recente sequenza sospetta di accessi alla console e modifiche alle policy IAM è passata inosservata per ore e c’è preoccupazione che l’integrità dei log e gli allarmi tempestivi non siano adeguati per la ricostruzione forense e la raccolta di prove per Audit Manager.

Approccio consigliato:

Abilitare un trail di AWS Organizations CloudTrail (organization trail) in tutte le regioni, attivare la convalida dell’integrità dei file di log di CloudTrail, consegnare i log e i file di digest a un bucket S3 centralizzato crittografato con una CMK di KMS la cui policy della chiave limiti la decrittografia a un piccolo team di sicurezza, e abilitare il logging degli accessi S3 e il versioning.
Configurare CloudTrail per inviare in streaming gli eventi di gestione e dati selezionati a CloudWatch Logs, quindi creare filtri di metrica di CloudWatch Logs per pattern ad alto rischio (fallimenti di accesso alla console da nuovi IP, CreateUser, PutRolePolicy) e collegare CloudWatch Alarms a topic SNS per il paging e un playbook Lambda automatizzato.
Distribuire dashboard di CloudWatch Logs Insights per l’indagine interattiva degli eventi recenti e impostare regole di conservazione e di ciclo di vita nell’account di logging per conservare le prove secondo la policy.
Catalogare gli oggetti S3 di CloudTrail con AWS Glue ed eseguire query Athena (partizionate per regione/data/servizio) per analisi retrospettive su larga scala e per produrre esportazioni di prove in formato CSV per gli investigatori.
Creare una valutazione (assessment) di AWS Audit Manager che raccolga automaticamente le prove da CloudTrail, AWS Config e IAM in una cartella delle prove (evidence folder) e pianifichi esportazioni periodiche per i revisori della conformità.

Motivazione: Centralizzare e convalidare CloudTrail, inviare in streaming a CloudWatch per filtri di metrica e allarmi in tempo reale, e usare Athena/Logs Insights per query scalabili segue le best practice di AWS per il rilevamento, il logging immutabile e la preparazione forense (forensic readiness), mentre Audit Manager automatizza la raccolta di prove per gli audit.

← Rilevamento delle minacce e avvisi · Tutti i domini · Crittografia →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Supera l'esame →

Sfoglia Amazon →