Amazon SOA-C02: Sicurezza, identità e conformità — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fa parte della AWS SysOps Administrator Associate SOA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Questo dominio copre i primitivi di identità, crittografia, segreti e auditing che sono alla base di operazioni AWS sicure e conformi. Si concentra sulla concessione dell’accesso corretto (principio del privilegio minimo), sulla protezione dei dati tramite la gestione delle chiavi e la crittografia e sulla creazione di percorsi di audit immutabili per una conformità continua. Le responsabilità quotidiane di un SysOps includono la progettazione di ruoli IAM e confini di attendibilità (trust boundary), la gestione di chiavi KMS e segreti e l’utilizzo di AWS Config e CloudTrail per rilevare deviazioni (drift) e violazioni delle policy.

IAM, ruoli, policy e federazione

La governance di IAM dovrebbe iniziare con la separazione dei ruoli e il principio del privilegio minimo: utilizzare ruoli separati per l’amministrazione, il logging e i carichi di lavoro applicativi; evitare di associare policy ampie come AdministratorAccess a principal di lunga durata. Creare ruoli con una policy di attendibilità (trust policy) (da console o CLI: aws iam create-role –role-name AppRole –assume-role-policy-document file://trust.json) e associare policy di autorizzazione (permission policy) usando aws iam put-role-policy o policy gestite. Utilizzare i permission boundary e le IAM Condition (aws:SourceIp, aws:RequestedRegion) per limitare dove e come i privilegi possono essere esercitati.

Per la federazione delle identità, preferire SAML/OIDC per emettere credenziali temporanee tramite STS. Per SAML, configurare un identity provider in IAM e usare aws sts assume-role-with-saml –role-arn arn:aws:iam::123456789012:role/SAMLRole –principal-arn arn:aws:iam::123456789012:saml-provider/IdP. Per OIDC (Cognito, Auth0 o altri provider), creare un provider OIDC in IAM e mappare i claim ai ruoli; la federazione di identità web utilizza aws sts assume-role-with-web-identity. Scegliere ruoli federati quando gli utenti sono esterni o quando i servizi di directory centralizzati gestiscono l’autenticazione; utilizzare AWS IAM Identity Center (SSO) per l’accesso aziendale centralizzato e la gestione delle sessioni.

KMS, gestione delle chiavi e crittografia

KMS è il servizio centrale per il ciclo di vita delle chiavi e il controllo degli accessi. Scegliere tra chiavi gestite da AWS (semplicità), chiavi di proprietà di AWS e CMK gestite dal cliente (controllo granulare). Creare CMK con aws kms create-key –description “CMK for prod” e abilitare la rotazione automatica con aws kms enable-key-rotation –key-id alias/ProdKey. Utilizzare le policy delle chiavi (key policy) per definire chi può gestire le chiavi e usare i grant per la delega temporanea degli accessi (aws kms create-grant) piuttosto che policy IAM generiche.

Criteri decisionali: usare le CMK quando sono richiesti l’auditing e il controllo del ciclo di vita della chiave (rotazione, finestre di eliminazione); usare le chiavi gestite da AWS per la comodità automatica in molti servizi gestiti. Proteggere le chiavi applicando policy IAM e policy delle chiavi, limitarne l’uso tramite kms:ViaService o grant di KMS per l’uso cross-account, ed evitare di pianificare l’eliminazione immediata: utilizzare una finestra di attesa minima. Monitorare l’uso di KMS con i log di CloudTrail per le operazioni Encrypt/Decrypt e GenerateDataKey per rilevare utilizzi anomali.

Gestione dei segreti e parameter store

Utilizzare AWS Secrets Manager per la rotazione delle credenziali e l’automazione del ciclo di vita, e Systems Manager Parameter Store (SecureString) per segreti più semplici dove la rotazione è manuale. Creare segreti tramite aws secretsmanager create-secret –name prod/db –secret-string ‘{“username”:“app”,“password”:"…"}’ e abilitare la rotazione specificando una funzione Lambda per la rotazione automatica. Per Parameter Store, usare aws ssm put-parameter –name /prod/db/password –value “…” –type SecureString –key-id alias/ProdKey.

Punti decisionali:

Secrets Manager: rotazione integrata, versioni dei segreti, replica e template di rotazione integrati nella console; costo più elevato ma migliore per credenziali di database e chiavi API.
Parameter Store SecureString: livello gratuito per l’archiviazione di base dei segreti, utilizza CMK di KMS per la crittografia e policy IAM per l’accesso. Limitare sempre l’accesso ai segreti tramite policy IAM basate sul principio del privilegio minimo e preferire l’accesso basato sui ruoli (ruoli di esecuzione di EC2/ECS/Lambda) piuttosto che incorporare credenziali di lunga durata nel codice o nelle variabili d’ambiente.

AWS Config, auditing e monitoraggio della conformità

AWS Config fornisce registrazione continua delle risorse, cronologia delle modifiche e valutazione delle regole. Abilitare un registratore (recorder) e un canale di distribuzione (delivery channel) (da console o con aws configservice start-configuration-recorder) e creare regole gestite o personalizzate con aws configservice put-config-rule. Combinare Config con CloudTrail (aws cloudtrail create-trail –name audit –s3-bucket audit-bucket) e CloudWatch Alarms per il rilevamento e la remediation quasi in tempo reale (utilizzare le azioni di remediation di Config o i documenti di Systems Manager Automation).

Decisioni di progettazione: utilizzare le regole gestite di Config per controlli standard (S3 bucket public-read, MFA per l’account root) e regole personalizzate (Lambda) per controlli specifici del dominio. Assicurare l’aggregazione multi-regione dei dati di Config in un aggregatore e abilitare la registrazione multi-account tramite AWS Organizations. Mantenere un percorso di audit immutabile inviando i log di CloudTrail a un bucket S3 centralizzato e crittografato (SSE-KMS) e abilitare CloudTrail Insights per attività API anomale.

Protezione dei dati, crittografia in transito e a riposo

La crittografia dovrebbe essere applicata a più livelli: a riposo (at rest) utilizzando la crittografia basata su KMS per EBS, RDS, S3 (SSE-S3, SSE-KMS o SSE-C) e in transito (in transit) utilizzando TLS per il traffico applicativo (utilizzare ACM per certificati pubblici/privati e associarli ai listener di ALB/NLB: aws elbv2 create-listener –load-balancer-arn … –protocol HTTPS –port 443 –certificates CertificateArn=arn:aws:acm:…). Utilizzare la crittografia lato client (client-side encryption) dove è richiesto un controllo aggiuntivo e considerare la crittografia a involucro (envelope encryption) con GenerateDataKey quando si crittografano grandi quantità di dati al di fuori delle quote di KMS.

Applicare questi criteri decisionali:

Utilizzare SSE-KMS per gli oggetti S3 quando sono necessari audit e controlli sull’accesso alle chiavi; SSE-S3 è sufficiente per una crittografia di base lato server.
Utilizzare CMK di KMS per EBS e RDS quando sono necessarie la rotazione delle chiavi e il controllo degli accessi cross-account.
Applicare sempre TLS per gli endpoint dei servizi; utilizzare HSTS e cifrari robusti nei load balancer. Utilizzare endpoint VPC e policy IAM per ridurre l’esposizione pubblica delle API del data plane.

Errori Comuni e Criteri Decisionali

Uso eccessivo dell’account root o memorizzazione delle credenziali root: creare invece ruoli di amministratore con MFA e utilizzare AWS SSO o ruoli IAM per le attività quotidiane; bloccare le credenziali root in un vault sicuro e abilitare l’MFA.
Affidarsi a chiavi di accesso a lunga durata: ruotare le chiavi regolarmente o eliminarle a favore di credenziali temporanee tramite STS e il concatenamento di ruoli (role chaining) (ruoli EC2/ECS/Lambda).
Mancata rotazione o protezione inadeguata delle chiavi KMS e dei segreti: abilitare la rotazione automatica per le CMK ove appropriato, utilizzare la rotazione di Secrets Manager per le credenziali dei database e monitorare l’uso delle chiavi tramite CloudTrail.
Affidarsi ai permessi S3 di default o alle ACL: applicare policy di bucket, bloccare l’accesso pubblico e utilizzare SSE-KMS per i dati sensibili; convalidare con le regole di AWS Config.
Uso improprio delle key policy rispetto alle policy IAM: gestire l’amministrazione delle chiavi nella key policy di KMS e concedere l’utilizzo tramite grant o IAM quando appropriato; evitare di concedere l’autorizzazione Decrypt in modo esteso.
Dimenticare la centralizzazione dei log e l’aggregazione multi-regione: impostare trail multi-regione di CloudTrail e aggregatori di Config per la conformità cross-account.

Problema Pratico: Scenario d’Uso

AcmeFin, un’azienda fintech, deve proteggere i database e le API di produzione, fornendo al contempo ai collaboratori esterni (contractor) un accesso temporaneo e mantenendo l’auditabilità per gli audit di conformità.

Creare ruoli IAM separati per l’accesso di amministratori, applicazioni e collaboratori esterni; imporre l’uso dell’MFA e utilizzare IAM Identity Center per la federazione basata su SAML per i collaboratori esterni.
Criptare RDS ed EBS con una CMK gestita dal cliente (aws kms create-key), abilitare la rotazione della chiave e limitare l’uso della chiave tramite una key policy restrittiva che consenta l’accesso solo ai ruoli del database e di audit.
Memorizzare le credenziali del database in AWS Secrets Manager con rotazione automatizzata, utilizzando il template di rotazione Lambda fornito.
Abilitare CloudTrail (multi-regione) e il registratore di AWS Config, inviare i log a un bucket S3 centralizzato e criptato con SSE-KMS, e creare regole di Config per i bucket S3 pubblici e le risorse non criptate.
Utilizzare un ALB con certificati emessi da ACM per l’HTTPS e posizionare le API dietro a WAF e a endpoint VPC ove appropriato.

Questo approccio applica il principio del privilegio minimo (least privilege) tramite la separazione dei ruoli, automatizza la rotazione delle credenziali e delle chiavi per ridurre il raggio d’impatto (blast radius) e centralizza i log e le valutazioni di Config, in modo che gli auditor possano verificare i controlli mentre il team operativo mantiene modelli di accesso sicuri e temporanei.

← Distribuzione · Tutti i domini · Reti e distribuzione di contenuti →

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