Amazon DOP-C02: Sicurezza, Conformità e Governance — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La sicurezza, la conformità e la governance su AWS si basano su controlli deterministici che scalano tra account e Regioni senza rallentare la delivery. Un design robusto stratifica i controlli di identità (IAM, permission boundary e service control policy), la governance multi-account (AWS Organizations e Control Tower), la valutazione e la risoluzione continua (AWS Config), il rilevamento delle minacce (Security Hub, GuardDuty, Inspector), l’igiene dei segreti, la crittografia con AWS KMS e l’isolamento di rete (VPC security group, NACL, endpoint e PrivateLink). L’obiettivo è minimizzare il blast radius (raggio d’impatto), dimostrare la conformità in modo continuo e automatizzare la prevenzione e la risoluzione, preservando al contempo il principio del privilegio minimo (least privilege) e l’autonomia degli sviluppatori.

Identità, Policy e Governance Multi-Account

I ruoli IAM, le policy, i permission boundary e gli SCP operano congiuntamente per formare il set di permessi effettivo. Le policy basate sull’identità di un ruolo IAM definiscono le azioni consentite; la trust policy del ruolo definisce chi può assumerlo. I permission boundary limitano ciò che un principal può fare, indipendentemente da quanto specificato nelle policy di identità. Gli SCP in AWS Organizations stabiliscono il massimo assoluto per qualsiasi principal in un account membro (incluso l’utente root). Le policy basate sulle risorse (per S3, KMS, Secrets Manager, ecc.) possono consentire l’accesso cross-account, ma anch’esse non possono superare i limiti imposti dagli SCP o dai permission boundary. Il permesso effettivo è l’intersezione di: policy di identità ∩ permission boundary ∩ policy di sessione (se presenti) ∩ policy di risorsa (se applicabile) ∩ SCP, con qualsiasi Deny esplicito che ha la precedenza.

Utilizzare i permission boundary per abilitare un self-service sicuro in un singolo account. Ad esempio, una pipeline per il vending di risorse può creare ruoli solo se associa un boundary che nega iam:PassRole tranne che per pattern specifici, nega kms:Decrypt su chiavi sensibili e limita i tipi di istanza EC2. I boundary possono essere associati solo da principal che possiedono già iam:PutRolePermissionsBoundary; proteggere questo diritto in modo rigoroso.

Gli SCP sono guardrail a livello di organizzazione. I guardrail comuni includono il divieto di disabilitare AWS Config o CloudTrail, la prevenzione di inviti a organizzazioni esterne, il divieto di modifiche all’amministratore delegato di IAM Identity Center e la restrizione delle Regioni. Preferire modelli di autorizzazione esplicita per eccezione (allow-by-exception) con condizioni (ad esempio, consentendo modifiche da parte di un ruolo di amministrazione centrale) per minimizzare l’attrito. Consentire sempre la creazione e l’uso dei ruoli collegati ai servizi (service-linked roles) necessari (ad es. per GuardDuty, Inspector, Config), altrimenti gli SCP bloccheranno involontariamente la configurazione dei servizi.

AWS Organizations fornisce OU gerarchiche per separare gli ambienti (es. Sandbox, Dev, Prod), i tipi di workload e le corsie di eccezione. Ereditare gli SCP dalle OU padre per evitare la deriva delle policy. Utilizzare il vending di account per standardizzare la configurazione degli account: Account Factory di AWS Control Tower (console) o Account Factory for Terraform (AFT) per l’integrazione in CI/CD. AFT aggiunge flussi di lavoro in stile GitOps, rilevamento della deriva e feature flag (ad es. per il provisioning del supporto Enterprise) e scala fino a centinaia di account con guardrail di base coerenti.

AWS Control Tower automatizza una landing zone con guardrail prescrittivi. I guardrail preventivi sono SCP gestiti da Control Tower; i guardrail di rilevamento (detective) sono regole di AWS Config che vengono distribuite. Control Tower integra IAM Identity Center per l’SSO e i set di permessi. Utilizzare set di permessi basati su ABAC con attributi per il controllo degli accessi per definire l’ambito delle azioni tramite aws:PrincipalTag o attributi di identità. Estendere la baseline con Customizations for AWS Control Tower (CfCT) per distribuire automaticamente CloudFormation, SCP e pacchetti Config per OU/account. Mantenere OU di eccezione per ospitare workload che necessitano di policy personalizzate senza indebolire i guardrail globali.

Conformità Continua e Risoluzione Automatizzata

Abilitare AWS Config a livello di organizzazione da un account amministratore delegato. Attivare la registrazione per tutte le risorse in tutte le Regioni e aggregare la configurazione attraverso l’Organizzazione con un aggregatore di organizzazione. Utilizzare regole gestite per controlli comuni (es. ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) e creare regole personalizzate basate su Lambda per logiche su misura (es. verificare la cadenza di rotazione delle chiavi KMS rispetto a una policy di 90 giorni o imporre tag e valori predefiniti). I conformance pack raggruppano regole, parametri e azioni di risoluzione in pacchetti (bundle) versionati e distribuibili per OU; mantenerli nel controllo di versione e distribuirli tramite StackSets o CfCT per coerenza e verificabilità.

La risoluzione automatizzata chiude il cerchio. Associare la valutazione di non conformità di ogni regola a un runbook di SSM Automation che impone la baseline: associare un profilo di istanza predefinito, applicare un tag con un valore predefinito, attivare S3 Block Public Access o riavviare un’istanza EC2 per manutenzione. Utilizzare documenti parametrizzati e input dinamici (ad es. dal risultato di Config) per mantenere i runbook generici. Per le risorse ad alto rischio, configurare la risoluzione per l’esecuzione automatica; per le azioni sensibili, richiedere un’approvazione di modifica o un’invocazione manuale tramite EventBridge e ChatOps. Proteggere Config stesso con SCP che negano l’arresto del registratore o l’eliminazione dei canali di consegna, tranne che da parte di un amministratore centrale.

Firewall Manager completa questo livello per la gestione delle policy come servizio (policy-as-a-service) tra più account, utilizzando Organizations. Delegare un amministratore centrale e creare policy per le associazioni di web ACL WAF su ALB/API Gateway esposti a Internet, l’audit e la pulizia dei security group dei VPC o la propagazione delle regole di DNS Firewall. Questo sposta l’applicazione futura delle policy dal rilevamento/risoluzione alla prevenzione.

Rilevamento delle Minacce, Igiene dei Segreti e Gestione delle Vulnerabilità

Security Hub funge da pannello di controllo centralizzato (central pane of glass) per i risultati (findings) tra più account e Regioni. Abilitalo con un amministratore delegato, aggrega i risultati e attiva gli standard pertinenti (AWS Foundational Security Best Practices, CIS, PCI DSS dove applicabile). I risultati confluiscono nell’AWS Security Finding Format (ASFF), normalizzando gli input provenienti da GuardDuty, Inspector, IAM Access Analyzer, Config, Macie e strumenti di partner. Configura i pattern di EventBridge per instradare i risultati critici verso automazioni di remediation (SSM Automation, Lambda) e notifiche (SNS, chat).

GuardDuty fornisce un rilevamento gestito delle minacce senza richiedere la gestione di pipeline di log a livello di data plane. Analizza gli eventi di gestione e dati di CloudTrail, i VPC Flow Logs, i log delle query DNS di Route 53 Resolver e i log di audit di EKS per rilevare comportamenti anomali, esfiltrazione di credenziali, crypto-mining, esfiltrazione DNS e altro ancora. Abilita la Malware Protection per la scansione di S3 e EC2/EBS in caso di attività sospette. Utilizza l’abilitazione automatica a livello di organizzazione e archivia sistematicamente i risultati a basso segnale con regole di soppressione per concentrarsi sugli elementi che richiedono un’azione.

Amazon Inspector valuta continuamente le istanze EC2 (tramite l’agente SSM) per le CVE dei pacchetti, le immagini dei container ECR per le vulnerabilità prima del deploy e le funzioni Lambda per le CVE dei pacchetti di codice. Inspector richiede che le istanze EC2 abbiano l’SSM Agent installato, che il profilo dell’istanza consenta le autorizzazioni SSM e che sia presente connettività in uscita (egress) verso gli endpoint di SSM/KMS (tramite VPC endpoint se l’accesso a Internet è limitato). Configura Inspector per inviare i risultati a Security Hub e attivare flussi di lavoro di patching con Systems Manager Patch Manager o remediation basata su runbook. Utilizza i tag per definire l’ambito (scope) delle risorse da sottoporre a scansione e per separare i carichi di lavoro di sandbox da quelli regolamentati.

Secrets Manager centralizza l’archiviazione, la rotazione e l’accesso cross-account dei segreti con una solida auditabilità. Preferisci Secrets Manager a Parameter Store per le credenziali che richiedono la rotazione, sfruttando la rotazione integrata per RDS/Aurora o la rotazione basata su Lambda per sistemi esterni. Le etichette di staging (AWSCURRENT, AWSPREVIOUS) consentono una rotazione senza tempi di inattività (zero-downtime). Esegui le Lambda di rotazione in VPC con gli endpoint necessari (Secrets Manager, RDS, KMS) e limita il traffico in uscita (egress). Per l’utilizzo cross-account, allega una policy basata su risorsa che conceda ai principal di altri account l’autorizzazione GetSecretValue; assicurati che la policy della chiave KMS (CMK) del segreto consenta ai principal del consumer di decifrare e, se necessario, di creare grant. Per il disaster recovery o per controlli di località, replica i segreti tra Regioni e allinea le finestre di rotazione.

Protezione dei Dati e Sicurezza della Rete

Progetta la crittografia utilizzando KMS con policy della chiave esplicite. Le policy della chiave, non solo le policy IAM, autorizzano in ultima istanza le entità principali (principal) a eseguire operazioni crittografiche su una CMK. Adotta un modello di policy della chiave basato sui ruoli e sul principio del privilegio minimo: delega l’amministrazione a un ruolo di amministratore KMS centrale; concedi i diritti di utilizzo in modo ristretto ai ruoli dei carichi di lavoro; non consentire l’uso del carattere jolly kms:* per evitare escalation accidentali. Usa le chiavi di condizione (kms:EncryptionContext:*) per vincolare la decrittografia ai contesti previsti. Le chiavi Multi-Regione consentono una crittografia attivo-attivo in cui i dati vengono replicati tra Regioni.

I grant sono lo strumento giusto per delegare l’uso temporaneo o strettamente limitato di una chiave senza modificare la policy della chiave, e sono necessari per alcuni flussi di servizio (ad es. EC2 Auto Scaling che utilizza launch template crittografati, uso di AMI cross-account). Per consentire a un altro account di creare grant, la policy della chiave deve permettere kms:CreateGrant alle entità principali di quell’account; il beneficiario del grant (grantee) deve fornire un token di grant per l’uso immediato nello stesso percorso di chiamata. Per le AMI crittografate cross-account, copia e crittografa l’AMI con una CMK, condividi l’AMI, permetti all’account di destinazione di creare grant sulla CMK e fai in modo che il ruolo collegato al servizio (service-linked role) di destinazione riceva un grant.

La crittografia a involucro (envelope encryption) è il pattern predefinito: genera una chiave dati con KMS, crittografa i dati localmente con la chiave dati in chiaro, quindi archivia solo il testo cifrato e la chiave dati crittografata. In lettura, chiama KMS Decrypt per recuperare la chiave dati in chiaro in memoria. Questo minimizza le chiamate a KMS per payload di grandi dimensioni e limita l’esposizione della chiave in chiaro. Dove supportato, utilizza la SSE-KMS gestita dal servizio (S3, EBS, RDS) per semplicità operativa, ma allinea comunque le policy della chiave per i producer/consumer cross-account.

La sicurezza della VPC inizia con gruppi di sicurezza basati sul principio del privilegio minimo. I gruppi di sicurezza sono stateful; il traffico di ritorno è implicito. Preferisci i riferimenti ai gruppi di sicurezza rispetto alle regole basate su CIDR per evitare liste di IP consentiti fragili e per mantenere l’intento con l’infrastructure as code. Le regole di default che consentono tutto il traffico in uscita sono rischiose; limita esplicitamente l’egress alle destinazioni richieste e usa gli endpoint VPC per l’accesso ai servizi AWS. Le NACL sono stateless e vengono valutate per prime; mantienile come controlli grossolani a livello di subnet con ritorni espliciti per le porte effimere solo quando devi implementare un confine aggiuntivo o soddisfare requisiti normativi; altrimenti, favorisci i gruppi di sicurezza per la loro gestibilità.

Elimina le dipendenze da internet utilizzando gli endpoint VPC. Gli endpoint di gateway (S3, DynamoDB) instradano il traffico privatamente sulla rete AWS; associa una policy dell’endpoint per limitare i bucket o le tabelle accessibili. Gli endpoint di interfaccia (AWS PrivateLink) espongono i servizi AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) tramite IP privati; distribuiscili in subnet con i giusti gruppi di sicurezza e abilita il DNS privato in modo che i nomi di servizio standard si risolvano in indirizzi privati. Per microservizi producer-consumer tra account/VPC, pubblica un servizio endpoint supportato da un NLB e fai in modo che i consumer creino endpoint di interfaccia verso di esso tramite PrivateLink, evitando peering o transit gateway e mantenendo il traffico fuori dalla rete internet pubblica. Combina questi controlli con subnet senza NAT e senza IGW, e con un’ispezione centralizzata dell’egress dove l’accesso a internet è necessario.

Scenario Pratico del Problema

Expedia Group si sta espandendo su centinaia di account AWS in più Regioni e deve applicare una baseline di sicurezza rigorosa: nessun egress verso internet per i carichi di lavoro, remediation automatizzata delle configurazioni errate, rilevamento centralizzato delle minacce, rotazione dei segreti e condivisione cross-account controllata di AMI crittografate per immagini golden standardizzate.

Stabilire una governance multi-account con AWS Organizations e AWS Control Tower

Azione: Creare OU per Sandbox, Dev, Prod e Security. Distribuire Control Tower per stabilire la landing zone, abilitare i guardrail obbligatori e integrare IAM Identity Center. Usare Account Factory for Terraform (AFT) per il provisioning degli account tramite GitOps.
Perché: Control Tower fornisce guardrail “chiavi in mano” e applicati continuamente (SCP e regole Config). AFT standardizza il provisioning degli account su larga scala e codifica le baseline nel controllo di versione.

Creare SCP per applicare guardrail globali con eccezioni

Azione: Associare SCP che negano la disattivazione di CloudTrail e AWS Config, limitano le Regioni e impediscono ACL pubbliche su S3. Includere eccezioni basate su condizioni per un ruolo di amministratore della sicurezza nell’OU Security. Consentire la creazione/uso dei ruoli collegati al servizio (service-linked roles) necessari.
Perché: Gli SCP limitano i privilegi di tutte le entità principali, inclusa la root, prevenendo deviazioni e consentendo al contempo eccezioni controllate per le operazioni centrali.

Distribuire pacchetti di conformità (conformance pack) di Config con remediation automatizzata

Azione: Dall’account amministratore delegato di Security, abilitare AWS Config a livello di organizzazione e creare un aggregatore. Distribuire un pacchetto di conformità che imponga la crittografia EBS di default, SSH limitato, tag obbligatori con valori predefiniti e WAF richiesto sui punti di ingresso pubblici. Mappare ogni regola a documenti SSM Automation per correzioni automatiche (es. associare un profilo di istanza di default, impostare tag mancanti su “weekly”).
Perché: I pacchetti di conformità offrono una policy-as-code coerente e verificabile con auto-remediation che mantiene gli ambienti in uno stato conforme senza un sovraccarico di ticket.

Centralizzare il rilevamento con Security Hub, GuardDuty e Inspector

Azione: Abilitare GuardDuty e Inspector a livello di organizzazione con un amministratore delegato. Abilitare gli standard di Security Hub (AWS FSBP e CIS) e aggregare i risultati (finding). Creare regole EventBridge per instradare i risultati ad alta gravità a runbook SSM Automation e a un topic SNS per il personale reperibile (on-call).
Perché: Il rilevamento gestito e la valutazione delle vulnerabilità forniscono una copertura continua con un sovraccarico operativo minimo, e Security Hub consolida i segnali per un triage e una risposta più rapidi.

Applicare il principio del privilegio minimo in IAM con permission boundary e ABAC

Azione: Negli account provisionati con AFT, richiedere che i ruoli creati dagli sviluppatori associno un permission boundary che neghi iam:PassRole eccetto a ruoli selezionati e limiti le API ad alto impatto. Usare i set di autorizzazioni (permission set) di IAM Identity Center con ABAC per definire l’ambito delle azioni in base ai tag del team.
Perché: I permission boundary consentono un self-service sicuro prevenendo al contempo l’escalation dei privilegi; l’ABAC riduce la proliferazione delle policy e rimane allineato con gli attributi dell’identità.

Rafforzare i percorsi di rete con endpoint VPC e PrivateLink

Azione: Rimuovere IGW/NAT dalle subnet delle applicazioni. Creare endpoint di interfaccia per KMS, Secrets Manager, SSM, ECR, CloudWatch e endpoint di gateway per S3/DynamoDB con policy dell’endpoint restrittive. Pubblicare i servizi di piattaforma interni tramite NLB supportati da PrivateLink per il consumo cross-account.
Perché: La connettività privata elimina l’esposizione a internet e garantisce che i servizi rimangano raggiungibili in ambienti bloccati.

Implementare una strategia di chiavi KMS con grant per le AMI cross-account

Azione: Creare CMK per ogni ambiente con policy della chiave limitate ai ruoli. Nell’account di creazione delle immagini, crittografare le AMI golden e condividerle. Aggiornare la policy della CMK per consentire agli account di destinazione di creare grant, quindi creare grant per i ruoli collegati al servizio (service-linked roles) in quegli account di destinazione.
Perché: I grant forniscono una delega limitata e verificabile senza dover modificare le policy della chiave per ogni consumer, consentendo ad Auto Scaling di avviare istanze da AMI crittografate tra account.

Standardizzare la rotazione dei segreti e l’accesso cross-account

Azione: Archiviare le credenziali di database e API in Secrets Manager. Implementare la rotazione tramite Lambda per i target non-RDS e abilitare la rotazione integrata per RDS. Per i segreti di piattaforma condivisi, associare policy basate sulle risorse che concedono GetSecretValue ai ruoli dei consumer in altri account e assicurarsi che le policy delle CMK consentano la decrittografia. Collocare le Lambda di rotazione in VPC con gli endpoint necessari.
Perché: La rotazione automatizzata riduce il rischio legato alle credenziali; le policy delle risorse allineate con KMS consentono un consumo cross-account sicuro preservando il principio del privilegio minimo e le tracce di audit.

Questa architettura fornisce a Expedia Group guardrail applicabili, conformità dimostrabile, correzioni automatizzate e percorsi di accesso ai dati strettamente controllati, il tutto preservando la velocità degli sviluppatori attraverso un self-service sicuro e una connettività privata.

← Monitoraggio · Tutti i domini · Container e Operazioni Serverless →

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