Amazon SCS-C02: Protezione dei dati e S3 — 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.

Policy dei bucket S3, ARN delle risorse e Deny espliciti

Una policy di bucket S3 è un documento JSON basato sulla risorsa che viene valutato insieme alle policy basate sull’identità. Due regole dominano il suo comportamento. Primo, un Deny esplicito prevale sempre: non importa quante dichiarazioni Allow esistano, un Deny corrispondente blocca la richiesta. Secondo, l’elemento Resource deve corrispondere esattamente al pattern dell’ARN dell’azione. Le azioni a livello di bucket come s3:ListBucket operano su arn:aws:s3:::my-bucket, mentre le azioni a livello di oggetto come s3:GetObject e s3:PutObject operano su arn:aws:s3:::my-bucket/*. Un errore di configurazione comune è concedere s3:GetObject su arn:aws:s3:::my-bucket senza il suffisso /* — la chiamata API si rivolge a un ARN di oggetto, nessuna dichiarazione corrisponde e la richiesta viene negata per impostazione predefinita.

La policy seguente nega qualsiasi accesso non-TLS e concede l’accesso in lettura a un ruolo specifico, utilizzando correttamente entrambe le forme di ARN.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Una trappola frequente è tentare di “ritagliare” un’eccezione aggiungendo un Allow successivo dopo un Deny generico. Le dichiarazioni di policy non sono sensibili all’ordine e la logica di valutazione di IAM restituisce Deny non appena trova una corrispondenza con una negazione. La soluzione corretta è restringere il Deny — ad esempio, tramite un NotPrincipal o una Condition — invece di aggiungere una dichiarazione permissiva in seguito.

Regole di lifecycle, scadenza degli oggetti e Vault Lock

Le regole di lifecycle di S3 automatizzano le transizioni tra classi di storage e la scadenza degli oggetti. Per soddisfare i requisiti di conservazione — come la rimozione di PII 30 giorni dopo l’ingestione — si associa una regola che fa scadere le versioni correnti degli oggetti dopo 30 giorni e che elimina permanentemente le versioni non correnti poco dopo. Per i metadati correlati scritti su DynamoDB, abilitare l’attributo TTL di DynamoDB in modo che gli elementi si auto-eliminino secondo la stessa pianificazione; la combinazione di questi due meccanismi è operativamente efficiente perché non richiede Lambda, scheduler o codice di pulizia personalizzato.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Per i dati archiviati con obblighi di conservazione normativa, S3 Glacier Vault Lock fornisce un controllo WORM separato a livello di vault. Una volta confermata la policy di Vault Lock (un processo in due fasi, avvio/completamento, da eseguire entro 24 ore), non può essere modificata, nemmeno dall’utente root dell’account. Questo è diverso da Object Lock, che opera a livello di oggetto S3.

Block Public Access e OAC di CloudFront

S3 Block Public Access (BPA) è un set di quattro interruttori a livello di account e di bucket che sovrascrivono qualsiasi ACL o policy che altrimenti concederebbe l’accesso pubblico. Abilitare tutti e quattro a livello di account e imporli con una SCP, ad esempio negando s3:PutBucketPublicAccessBlock quando tenterebbe di allentare le impostazioni. Questa difesa approfondita (defense-in-depth) impedisce a un ingegnere di riesporre accidentalmente un bucket tramite una ACL permissiva.

Per i contenuti pubblici serviti tramite CloudFront, il pattern corretto è l’Origin Access Control (OAC). L’OAC firma le richieste da CloudFront a S3 usando SigV4; la policy del bucket permette quindi solo al service principal della distribuzione CloudFront. Affidarsi solo a CloudFront senza OAC (o il legacy OAI) lascia l’URL S3 direttamente accessibile, vanificando i controlli di accesso e il WAF della CDN. Il bucket deve rimanere privato, con BPA abilitato, e la policy deve avere come scope l’ARN della distribuzione:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock e Replicazione tra regioni (Cross-Region Replication)

Object Lock impone la semantica WORM sui singoli oggetti e richiede che il versioning sia abilitato e che Object Lock sia attivato alla creazione del bucket (non può essere aggiunto in seguito a un bucket esistente senza contattare AWS). Esistono due modalità di conservazione:

• Modalità Governance: i principal con privilegi s3:BypassGovernanceRetention possono abbreviare o rimuovere la conservazione.

• Modalità Compliance: nessun utente — incluso l’utente root dell’account AWS — può eliminare o sovrascrivere l’oggetto o ridurne il periodo di conservazione fino alla sua scadenza. Un blocco a fini legali (legal hold) può essere inoltre applicato e rimosso indipendentemente da utenti con il permesso s3:PutObjectLegalHold.

La modalità Compliance è la scelta corretta quando il requisito è l’immutabilità assoluta contro tutte le identità. Per estendere tale garanzia tra più regioni, abbinare Object Lock con S3 Replication. Gli oggetti replicati conservano la loro configurazione di blocco nel bucket di destinazione (che deve anch’esso avere Object Lock abilitato), in modo che un evento a livello di regione o un tentativo di eliminazione malevolo non possa compromettere la copia conservata.

Macie e Athena per il rilevamento e l’indagine

Amazon Macie utilizza identificatori di dati gestiti e personalizzati per scansionare gli oggetti S3 alla ricerca di PII, PHI, credenziali e altri pattern di dati sensibili. Segnala i risultati a Security Hub ed EventBridge, abilitando la remediation automatizzata, come la messa in quarantena di oggetti tramite una policy di bucket restrittiva basata su tag. Abilitare Macie in ogni regione che archivia dati dei clienti e delegare l’amministrazione tramite AWS Organizations per centralizzare i risultati.

Amazon Athena fornisce SQL serverless sui dati in S3 ed è lo strumento standard per interrogare gli eventi di dati a livello di oggetto di CloudTrail. Per indagare su chi ha avuto accesso a un oggetto S3 specifico, abilitare gli eventi di dati di CloudTrail per il bucket, inviare i log a un bucket S3 centralizzato e interrogare con Athena:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Errori Comuni e Loro Cause Principali

• Mancanza di /* sugli ARN degli oggetti: Le chiamate API a livello di oggetto vengono valutate rispetto a bucket/key, non all’ARN del bucket. Senza /*, nessuna dichiarazione corrisponde e IAM restituisce un rifiuto implicito, che si manifesta con errori 403 inaspettati su GetObject anche quando il “bucket” sembra consentito.

• Aggiungere un Allow dopo un Deny esplicito: La valutazione di IAM non dipende dall’ordine; qualsiasi Deny corrispondente interrompe la valutazione e restituisce un rifiuto. La soluzione è restringere l’ambito del Deny (tramite Condition, NotPrincipal o NotResource), non aggiungere dichiarazioni permissive.

• CloudFront senza OAC o una policy del bucket restrittiva: L’URL di origine S3 rimane raggiungibile direttamente, aggirando URL firmati, regole WAF e restrizioni geografiche. Abilitare sempre il BPA sul bucket di origine e limitare s3:GetObject al service principal di CloudFront tramite AWS:SourceArn.

• Presumere che Object Lock possa essere abilitato su un bucket esistente: Object Lock deve essere configurato alla creazione del bucket. L’adeguamento retroattivo richiede la creazione di un nuovo bucket con Object Lock abilitato e la migrazione dei dati.

• Confondere la modalità governance con la modalità compliance: La modalità governance non impedisce a un utente con privilegi elevati di rimuovere la retention; solo la modalità compliance blocca persino l’account root.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial archivia estratti conto dei clienti, log delle transazioni e archivi di conformità a lungo termine in più bucket S3 distribuiti su due regioni AWS. Il loro ambiente utilizza CloudFront per i portali dei clienti, il logging cross-account e le transizioni automatiche del ciclo di vita verso classi di storage di archiviazione per la conservazione normativa.

Sfida: Una recente revisione interna ha rilevato diversi bucket con policy incoerenti che espongono PII (informazioni di identificazione personale), nessuna conservazione immutabile per i record archiviati e nessun modo centralizzato per scoprire dove risiedono gli oggetti sensibili tra account e regioni.

Approccio Consigliato:

1. Abilitare S3 Block Public Access a livello di account e di bucket e distribuire CloudFront Origin Access Control (OAC); restringere la policy del bucket per consentire GetObject solo dal principal OAC di CloudFront utilizzando ARN di risorsa precisi e aggiungere rifiuti espliciti per qualsiasi richiesta non proveniente tramite l’OAC.
2. Imporre la crittografia lato server con AWS KMS richiedendo kms:Encrypt/kms:GenerateDataKey in una policy del bucket e aggiungere rifiuti espliciti per le richieste PutObject che non includono x-amz-server-side-encryption e il kms:context richiesto per impedire caricamenti non crittografati.
3. Configurare S3 Object Lock in modalità compliance per i bucket che devono essere immutabili e abilitare la Cross-Region Replication (CRR) con regole di replica che preservino i metadati di Object Lock, in modo che gli oggetti replicati rimangano immutabili nella regione di DR (Disaster Recovery).
4. Creare regole del ciclo di vita di S3 (Lifecycle Rules) per eseguire la transizione di oggetti datati verso le classi di storage S3 Glacier e impostare la scadenza degli oggetti per le finestre di conservazione consentite; per gli archivi che devono essere legalmente immutabili, inserirli in vault di Amazon S3 Glacier e applicare policy di Glacier Vault Lock per imporre una conservazione di tipo write-once (scrittura unica).
5. Distribuire Amazon Macie su più account per scoprire e classificare le PII, abilitare S3 Inventory e interrogare i risultati con Amazon Athena per query investigative, e attivare una remediation automatizzata (Lambda/Step Functions) per etichettare, mettere in quarantena o spostare oggetti sensibili in bucket bloccati e crittografati.

Motivazione: Questo approccio a più livelli impone il principio del privilegio minimo e la crittografia, fornisce conservazione immutabile e durabilità cross-region per la conformità, e utilizza Macie/Athena per la scoperta centralizzata e la remediation automatizzata, allineandosi con le best practice di AWS per la protezione dei dati e la gestione del ciclo di vita.

Amazon Macie: Scoperta Automatizzata, Job di Classificazione e Liste di Esclusione (Allow List)

Amazon Macie è un servizio gestito di sicurezza dei dati che utilizza machine learning e pattern matching per scoprire dati sensibili — informazioni di identificazione personale (PII), numeri di carte di pagamento (PAN), credenziali e tipi di dati personalizzati definiti tramite regex — archiviati in Amazon S3. Macie opera in due modalità complementari che vengono spesso confuse.

La scoperta automatizzata di dati sensibili è un processo a basso costo e in esecuzione continua che campiona gli oggetti in ogni bucket dell’account (o in un’intera organizzazione quando Macie è delegato a un account di sicurezza). Costruisce un punteggio di sensibilità e un inventario per ogni bucket. Questo è il punto di partenza corretto quando si hanno migliaia di bucket e non si sa ancora dove si trovino i dati sensibili, perché minimizza i costi e l’overhead amministrativo campionando anziché scansionare ogni singolo oggetto.

I job di classificazione (sensitive data discovery jobs) sono scansioni approfondite una tantum o pianificate, mirate a bucket specifici. Una volta che la scoperta automatizzata segnala un bucket come contenente dati sensibili, si crea un job di classificazione con ambito limitato a quel bucket per un’analisi esaustiva. Il pattern canonico è quindi: abilitare la scoperta automatizzata a livello di organizzazione, quindi procedere con i job di classificazione solo sui bucket segnalati.

Le liste di esclusione (Allow list) sono il meccanismo per sopprimere le corrispondenze note come benigne. Se un data lake contiene PAN di test sintetici (ad esempio, l’intervallo di carte di prova ben noto 4111 1111 1111 1111), Macie segnalerà ogni occorrenza. Riscrivere o spostare i dati è costoso e dirompente; l’approccio corretto è definire una allow list di Macie — un elenco di valori esatti in testo semplice o una regex — e associarla ai tuoi job di classificazione e alla configurazione della scoperta automatizzata. Le corrispondenze con la allow list vengono escluse dai risultati (findings), mentre i PAN autentici continuano a generare avvisi.

Problema Pratico: Scenario d’Uso

Scenario: Meridian Financial gestisce un ambiente AWS multi-account con centinaia di bucket S3 che archiviano log delle transazioni, documenti dei clienti e archivi a lungo termine spostati su S3 Glacier. Il loro team di sicurezza ha implementato crittografia e logging di base, ma non dispone di un sistema centralizzato per la scoperta di dati sensibili né di controlli di conservazione coerenti tra gli account.

Sfida: Un bucket accessibile pubblicamente, scoperto di recente, conteneva record di clienti archiviati con PII (informazioni di identificazione personale) a causa di una policy del bucket errata e di una transizione del ciclo di vita verso S3 Glacier. Meridian deve ora trovare tutti i dati sensibili, rimediare alle esposizioni e applicare una conservazione conforme per gli archivi in futuro.

Approccio Raccomandato:

1. Abilitare Amazon Macie in tutta l’AWS Organization e attivare la scoperta automatizzata di S3 in modo che Macie valuti continuamente bucket e oggetti alla ricerca di dati sensibili e configurazioni rischiose.
2. Creare processi di classificazione (classification job) di Macie che mirino a tutti i bucket S3; configurare identificatori di dati sensibili personalizzati per SSN e numeri di conto e impostare delle allow list (liste di esclusione) per escludere dati di test noti, file di fornitori e account di servizio.
3. Utilizzare S3 Inventory per elencare gli oggetti in S3 Glacier, quindi eseguire S3 Batch Operations per ripristinare temporaneamente solo gli oggetti segnalati dall’inventario per la scansione di Macie, in modo che i processi di classificazione possano ispezionare il contenuto archiviato in Glacier.
4. Automatizzare la remediation inviando i risultati (finding) di Macie ad Amazon EventBridge e Security Hub; attivare funzioni Lambda per applicare policy sicure ai bucket S3, abilitare S3 Block Public Access, rimuovere ACL pubbliche e taggare i bucket per la revisione.
5. Implementare una conservazione duratura e misure preventive: abilitare S3 Versioning e S3 Object Lock (modalità governance/compliance) sui bucket critici, imporre SSE-KMS con CMK tramite policy del bucket e distribuire SCP di AWS Organizations per bloccare le ACL pubbliche e richiedere la crittografia e l’Object Lock dove applicabile.
6. Abilitare gli eventi dati (data events) di CloudTrail per S3 e inviare i risultati a un SIEM per l’alerting e la pianificazione periodica dei processi di classificazione di Macie per garantire una copertura continua.

Motivazione: Questo approccio utilizza Macie per la scoperta automatizzata e la classificazione mirata (con allow list), ripristina gli oggetti di Glacier solo quando necessario per l’ispezione, automatizza la remediation tramite EventBridge/Lambda e impone una conservazione immutabile e la crittografia con Object Lock e KMS, allineandosi con le best practice di AWS per il rilevamento, la remediation e i controlli preventivi.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Trattare i risultati grezzi di Macie come verità assolute senza configurare liste di esclusione (allow list) o di soppressione produce un eccesso di avvisi (alert fatigue) e può mascherare incidenti reali nel rumore generato da dati sintetici — ecco perché semplicemente “fidarsi dei risultati” è la risposta sbagliata in ambienti con un alto numero di falsi positivi.

Integrazione dei Risultati di Macie con EventBridge

Macie pubblica ogni risultato (finding) su Amazon EventBridge sulla sorgente aws.macie. Ciò consente di instradare i risultati senza dover interrogare (polling) l’API di Macie. Una regola tipica inoltra i finding di tipo Policy a SNS per avvisare il personale di turno (on-call paging) e invia i finding di tipo SensitiveData ad AWS Security Hub per l’aggregazione.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

I target della regola sono topic SNS, Security Hub o una funzione Lambda per una remediation personalizzata (ad esempio, applicando automaticamente una policy restrittiva al bucket incriminato).

Condizioni delle Policy dei Bucket per i Confini dell’Organization

S3 Block Public Access (BPA) blocca solo l’accesso proveniente da Internet pubblico o da principal anonimi. Non impedisce a un principal autenticato in un altro account AWS o in un’altra AWS Organization di accedere al bucket se una policy del bucket o una ACL concede tale accesso. Affidarsi solo a BPA è quindi errato quando il requisito è impedire l’accesso cross-organization — è necessario combinare le policy dei bucket con le Service Control Policies (SCP) a livello di Organizations.

Due chiavi di condizione IAM rendono precisa l’applicazione dei confini dell’organization:

• aws:ResourceOrgID: l’ID dell’Organization proprietaria della risorsa a cui si sta accedendo. Utilizzata nelle policy di identità/SCP per negare ai principal l’accesso a risorse al di fuori della propria Org.

• aws:PrincipalOrgID: l’ID dell’Org del principal che effettua la chiamata. Utilizzata nelle policy dei bucket per negare l’accesso da parte di principal esterni alla propria Org.

• aws:SourceOrgPaths: il percorso della OU del principal di origine, consentendo di limitare l’ambito a una specifica OU (ad esempio, solo la OU “Production” può scrivere in un bucket di compliance).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Abbinando questo a una SCP che nega s3:DeleteObject* su risorse dove aws:ResourceOrgID non corrisponde alla propria Org, l’esfiltrazione o la cancellazione cross-Org diventa impossibile, anche se una policy del bucket viene accidentalmente allentata.

S3 Object Lock: Modalità Compliance e Versioning

Object Lock applica una semantica write-once-read-many (WORM) alle singole versioni degli oggetti. Richiede che S3 Versioning sia abilitato sul bucket (Object Lock senza versioning non è possibile — il blocco protegge un ID di versione specifico, non la chiave).

• Modalità Governance: gli utenti con il permesso s3:BypassGovernanceRetention possono abbreviare o rimuovere la conservazione. Adatto per l’applicazione di policy interne.

• Modalità Compliance: nessun principal, incluso l’account root di AWS, può abbreviare, rimuovere o eliminare la versione dell’oggetto fino alla scadenza del periodo di conservazione. Questa è la scelta corretta per i requisiti di immutabilità normativa (SEC 17a-4, FINRA, archiviazione HIPAA).

La conservazione (retention) può essere impostata per singolo oggetto (data Retain-Until) o tramite una configurazione di conservazione predefinita a livello di bucket. I Legal Hold sono blocchi separati e a tempo indeterminato che persistono finché non vengono rimossi esplicitamente da un principal che detiene il permesso s3:PutObjectLegalHold.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Correggere gli Errori della Policy Prima del Completamento del Blocco

Vault Lock su S3 Glacier impone policy di accesso al vault immutabili. Il processo prevede due chiamate: initiate-vault-lock pone la policy in uno stato in-progress con una finestra di 24 ore, e complete-vault-lock la rende permanente. Se si scopre un errore di battitura durante la finestra di 24 ore — ad esempio, un Principal eccessivamente permissivo — la soluzione corretta e più economica è:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock annulla il blocco in corso senza alcun costo, consentendo di avviare nuovamente il processo con la policy corretta. Le “soluzioni” alternative — eliminare e ricreare il vault (che richiede l’eliminazione di tutti i 10 TB di archivi e il loro nuovo caricamento, comportando costi di recupero e trasferimento), o attendere il completamento del blocco per poi cercare di aggirarlo — sono dispendiose o impossibili. Una volta eseguito complete-vault-lock, la policy è immutabile per sempre; l’annullamento è valido solo durante la finestra in-progress.

Trappola Correlata: Catena di Fiducia DNSSEC

Una trappola comune tra domini diversi riguarda il DNSSEC di Route 53. L’abilitazione della firma DNSSEC su una hosted zone per un sottodominio genera una Key Signing Key (KSK) e un record DS corrispondente. Tale record DS deve essere pubblicato nella zona padre (parent zone); senza di esso, i resolver non possono convalidare la catena di fiducia e o trattano le risposte come non valide (bogus) o ripiegano sulla risoluzione non sicura, interrompendo il funzionamento del DNS per i client che effettuano la convalida. Abilitare la firma senza esportare il record DS e inserirlo presso il registrar o nella zona padre costituisce uno stato di configurazione incompleta, non un’implementazione DNSSEC funzionante.

← Crittografia · Tutti i domini · Networking e sicurezza VPC →

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

Sfoglia Amazon →