Amazon CLF-C02: Sicurezza, identità e compliance — Guida allo studio
Fa parte della AWS Cloud Practitioner CLF-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Identità, controllo degli accessi e principio del privilegio minimo
L’identità e l’accesso in AWS si basano sui costrutti di IAM: utenti, gruppi, ruoli, policy e federazione. La best practice consiste nell’evitare di assegnare permessi all’account root e nel concedere i privilegi tramite ruoli e gruppi, in modo che i permessi siano gestiti centralmente e verificabili. Utilizzare i ruoli IAM per i servizi di calcolo e serverless (ruoli di istanza EC2, ruoli di esecuzione Lambda) invece di incorporare credenziali a lunga durata. Per l’accesso umano, preferire una soluzione di federazione delle identità (IAM Identity Center o un provider SAML/OIDC) per centralizzare l’autenticazione, usare l’MFA e imporre credenziali a breve durata tramite STS per ridurre l’esposizione delle credenziali. La progettazione delle policy deve considerare le policy basate sull’identità rispetto a quelle basate sulla risorsa e l’ordine di valutazione delle policy: un deny esplicito prevale sempre, e i permessi ampi con * sono una trappola comune che viola il principio del privilegio minimo. Le Service Control Policies in AWS Organizations forniscono un guardrail di livello superiore, impedendo agli account di eseguire attività vietate indipendentemente dai permessi IAM a livello di account. I criteri decisionali dipendono dalla scala e dai confini di fiducia (trust boundary): utilizzare ruoli cross-account con il privilegio minimo per l’automazione e l’amministrazione centralizzata; usare i ruoli IAM per i servizi per evitare la fuga di credenziali; usare IAM Access Analyzer per convalidare l’accesso cross-account. Gli operatori spesso dimenticano di ruotare le chiavi, di rimuovere i permessi non utilizzati o di abilitare tempestivamente l’MFA e la federazione: queste lacune creano il rischio operativo più grande.
Protezione dei dati, crittografia e gestione delle chiavi
Crittografare i dati in transito e a riposo come impostazione predefinita. Per i dati in transito, TLS è lo standard di base; per i dati a riposo, AWS offre molteplici opzioni: crittografia lato server di S3 (SSE-S3, SSE-KMS, SSE-C), crittografia di EBS e RDS, e crittografia lato client quando è necessario il controllo del cliente sulle chiavi. AWS KMS è il servizio gestito principale per la gestione delle chiavi e la crittografia a involucro (envelope encryption), che abilita CMK gestite dal cliente, la rotazione automatica e controlli di utilizzo granulari tramite key policy e IAM. KMS si integra con molti servizi AWS per fornire l’auditing dell’uso delle chiavi in CloudTrail, ma si noti che le operazioni di KMS possono comportare costi per richiesta e hanno un ambito regionale: le architetture cross-account o cross-region richiedono una configurazione esplicita delle key policy o l’uso di chiavi multi-Regione. Per esigenze FIPS o di HSM dedicati, AWS CloudHSM offre hardware dedicato al tenant. Utilizzare S3 Object Lock e Glacier Vault Lock per l’immutabilità e la conformità alla conservazione (retention) quando i requisiti normativi richiedono archivi non modificabili. Una trappola comune è presumere che “crittografato” equivalga a “accesso controllato”; la crittografia protegge la confidenzialità del contenuto, ma le policy di accesso e il monitoraggio devono comunque prevenire l’uso non autorizzato. Scegliere SSE-KMS quando si necessita di log di accesso alle chiavi, controllo IAM granulare o decrittografia cross-account; utilizzare la crittografia lato client quando si deve impedire ad AWS di avere accesso al testo in chiaro in qualsiasi momento.
Rilevamento, monitoraggio e risposta automatizzata
La visibilità e il rilevamento sono la linfa vitale della sicurezza nel cloud. CloudTrail fornisce una traccia di audit per le chiamate API (management events) e può anche catturare i data events per S3 e Lambda; tuttavia, molti team trascurano di abilitare i data events, creando dei punti ciechi (blind spot). AWS Config registra le modifiche alla configurazione delle risorse e abilita controlli di conformità continui, mentre Security Hub aggrega i risultati (finding) di GuardDuty (rilevamento delle minacce), Inspector (scansione delle vulnerabilità) e Macie (scoperta di dati sensibili). GuardDuty utilizza molteplici fonti di telemetria (VPC Flow Logs, DNS, CloudTrail) per identificare attività sospette; i finding dovrebbero confluire in un account di sicurezza centrale ed essere resi operativi tramite EventBridge e playbook automatizzati (Lambda o SSM Automation) per il contenimento. Le decisioni su logging e retention influiscono sui costi: bucket S3 centralizzati con regole di lifecycle e crittografia riducono le spese di storage e semplificano l’accesso per gli audit. Integrare con sistemi SIEM o utilizzare integrazioni di partner per analisi avanzate. Una trappola ricorrente per gli operatori è archiviare i log nello stesso account o non proteggere il bucket S3 del trail, il che rischia la manomissione; centralizzare sempre e imporre l’immutabilità e l’accesso limitato. Progettare runbook di incident response che mappino i finding di GuardDuty e CloudTrail a passaggi concreti di contenimento, e testarli regolarmente.
← Networking e distribuzione di contenuti · Tutti i domini · Fatturazione →
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 →