Amazon SCS-C02: Crittografia, KMS e segreti — Guida allo studio
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.
Tipi di Chiavi AWS KMS, Policy e Controllo degli Accessi
AWS KMS supporta tre ampie categorie di chiavi, e la scelta di quella giusta determina chi controlla il materiale della chiave, dove risiede e come può essere ruotato. Le chiavi di proprietà di AWS (AWS-owned) sono invisibili all’utente, non hanno costi e sono utilizzate da servizi come S3 quando si abilita SSE-S3. Le chiavi gestite da AWS (AWS-managed), con alias aws/<service>, permettono a un servizio di crittografare per conto tuo, ma non è possibile modificarne la policy della chiave, motivo per cui non sono adatte per l’accesso cross-account o per una governance granulare. Le chiavi gestite dal cliente (CMK) sono lo strumento principale: si ha il controllo sulla policy della chiave, sulla rotazione (annuale automatica o on-demand), sui grant, sugli alias e sulla finestra di eliminazione.
Sono importanti due varianti specializzate. Il materiale della chiave importato viene utilizzato quando requisiti normativi o di tipo BYOK (Bring Your Own Key) obbligano a generare il materiale della chiave al di fuori di AWS e a importarlo in una chiave KMS. Il materiale importato è l’ unico modo per configurare una scadenza esplicita del materiale della chiave: le CMK generate da AWS non scadono mai. Non è possibile abilitare la rotazione annuale automatica di AWS sulle chiavi importate; è necessario re-importare il materiale manualmente. Le chiavi multi-regione condividono lo stesso ID e materiale della chiave tra più Regioni tramite chiavi di replica, così un testo cifrato prodotto in us-east-1 può essere decifrato in us-west-1 senza una nuova crittografia. Ogni replica ha la propria policy della chiave e i propri alias indipendenti, ma il materiale crittografico è sincronizzato.
Il controllo più frainteso in assoluto è la policy della chiave KMS. A differenza della maggior parte delle risorse AWS, dove le policy IAM da sole concedono l’accesso, le chiavi KMS utilizzano la loro policy della chiave come fonte primaria di autorizzazione. Una policy IAM che concede kms:Decrypt su una chiave è inefficace a meno che anche la policy della chiave non deleghi l’accesso a IAM (tramite un Principal corrispondente alla root dell’account più una dichiarazione appropriata, o nominando direttamente il principal). Questo è il motivo per cui un ingegnere con AdministratorAccess può comunque ricevere un AccessDenied quando chiama Decrypt su una CMK la cui policy non concede fiducia (trust) all’account. La dichiarazione di delega canonica è simile a questa:
{
"Sid": "EnableIAMPermissions",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "kms:*",
"Resource": "*"
}
I grant e le condizioni ViaService aggiungono restrizioni a più livelli, ad esempio, imponendo che una chiave venga utilizzata solo tramite S3 in una Regione specifica con kms:ViaService: s3.us-east-1.amazonaws.com.
Crittografia Lato Server e Lato Client
Per S3, le due opzioni comuni di crittografia lato server differiscono principalmente per controllo e auditabilità:
- SSE-S3 (AES-256): S3 gestisce interamente le chiavi; non c’è una policy della chiave visibile al cliente, non ci sono eventi di decifratura per chiave in CloudTrail e non c’è governance cross-account. Adeguata per una crittografia a riposo di base, ma insufficiente quando la conformità richiede di dimostrare chi ha decifrato i dati.
- SSE-KMS: Utilizza una CMK controllata dall’utente; ogni chiamata di decifratura viene registrata, la policy della chiave impone l’accesso ed è possibile applicare restrizioni tramite il contesto di crittografia (encryption context). Costa di più per richiesta e consuma le quote TPS di KMS, quindi le chiavi di bucket (
BucketKeyEnabled: true) dovrebbero essere abilitate per ridurre drasticamente le chiamate a KMS.
La crittografia lato client tramite l’AWS Encryption SDK è appropriata quando i dati devono essere crittografati prima di lasciare l’applicazione, o quando il servizio di storage non deve mai vedere il testo in chiaro (plaintext). I carichi di lavoro ad alto throughput dovrebbero avvolgere l’SDK con il CachingCryptoMaterialsManager, che riutilizza le chiavi dati (data key) per più messaggi entro limiti configurabili di byte, messaggi e TTL. Senza caching, ogni chiamata a encrypt innesca una richiesta GenerateDataKey, saturando rapidamente le quote di richiesta di KMS e aumentando i costi.
from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
master_key_provider=mkp, cache=cache,
max_age=600.0, max_messages_encrypted=10000)
Secrets Manager e Parameter Store
Secrets Manager archivia credenziali crittografate con una CMK di KMS e supporta la rotazione automatica tramite una funzione Lambda: AWS fornisce modelli per RDS, Redshift e DocumentDB, e Lambda personalizzate gestiscono qualsiasi altro caso. La rotazione esegue una macchina a stati in quattro passaggi (createSecret, setSecret, testSecret, finishSecret) che mette in staging le nuove credenziali con l’etichetta AWSPENDING prima di promuoverle a AWSCURRENT. Le applicazioni dovrebbero intercettare i fallimenti di autenticazione, aggiornare il segreto e riprovare: questo pattern elimina i tempi di inattività perché la credenziale precedente rimane brevemente valida tramite AWSPREVIOUS.
Quando la Lambda di rotazione viene eseguita all’interno di un VPC (tipico per raggiungere un’istanza RDS privata), necessita di accesso di rete in uscita (outbound) verso l’endpoint del servizio Secrets Manager. In un VPC privato senza NAT, è necessario implementare un endpoint VPC di interfaccia (com.amazonaws.<region>.secretsmanager) e consentire al security group della Lambda di raggiungere l’endpoint sulla porta 443. Dimenticarsene è un errore classico: la rotazione sembra configurata ma ogni invocazione va in timeout.
Per la resilienza cross-region, utilizzare una chiave KMS multi-regione e la funzionalità di replica dei segreti di Secrets Manager. Il segreto primario in us-east-1 è crittografato con la CMK primaria; la replica in us-west-1 decifra utilizzando la CMK di replica. Alias come alias/prod-db possono essere puntati a un nuovo ID di chiave on-demand per una rapida rotazione delle chiavi senza modificare il codice dell’applicazione.
Il tipo SecureString di Parameter Store è un’alternativa leggera quando non è necessaria la rotazione. Entrambi i servizi espongono riferimenti dinamici in CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}) in modo che i template degli stack non contengano mai testo in chiaro.
Crittografia di EBS, RDS, Aurora e degli Snapshot
La crittografia a riposo viene abilitata per volume o per istanza al momento della creazione e non può essere attivata/disattivata su una risorsa esistente. Il pattern di remediation per una risorsa non crittografata e non conforme è una copia dello snapshot con crittografia:
aws ec2 copy-snapshot --source-snapshot-id snap-abc \
--source-region us-east-1 --encrypted \
--kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...
Per RDS e Aurora, ripristinare lo snapshot crittografato in una nuova istanza ed effettuare il cut-over. Il ripristino cross-account richiede la condivisione dello snapshot e la concessione all’account di destinazione delle autorizzazioni kms:CreateGrant e kms:Decrypt sulla CMK tramite la policy della chiave: la sola condivisione dello snapshot fallirà perché la destinazione non può decifrare la chiave dati. La crittografia predefinita di EBS a livello di account dovrebbe essere abilitata in modo che i volumi appena creati siano sempre crittografati, indipendentemente dal comportamento del chiamante.
TLS: Policy di ACM e ALB
ACM emette e rinnova automaticamente i certificati pubblici senza costi aggiuntivi quando sono associati a servizi integrati (ALB, CloudFront, API Gateway). I certificati non possono essere esportati, quindi il TLS terminato su EC2 richiede o ACM Private CA (per certificati privati che si possono esportare) o un certificato importato. Un pattern pragmatico: terminare il TLS pubblico sull’ALB con un certificato ACM e utilizzare un certificato autofirmato o di una CA privata per il tratto da ALB a EC2 se è richiesta la crittografia end-to-end. Forzare i client a usare cifrari moderni con una policy di sicurezza come ELBSecurityPolicy-TLS13-1-2-2021-06, che disabilita TLS 1.0/1.1 e le suite deboli.
Trappole Comuni
IAM senza key policy. Concedere kms:Decrypt in una policy IAM mentre la key policy della CMK omette il principal dell’account produce un errore AccessDenied. KMS considera la key policy come autoritativa; i permessi IAM possono solo restringere ulteriormente ciò che la key policy consente.
Lambda di rotazione senza endpoint VPC. Se la Lambda viene eseguita in subnet private e il VPC non ha un NAT né un endpoint di interfaccia per secretsmanager, la chiamata di rotazione a secretsmanager.<region>.amazonaws.com non può essere risolta o connessa. Anche il security group dell’endpoint deve consentire il traffico sulla porta 443 dal SG della Lambda.
SSE-S3 equiparato a SSE-KMS. SSE-S3 utilizza una chiave di proprietà di AWS senza policy modificabile dal cliente, senza registrazione in CloudTrail delle decrittazioni per singolo oggetto e senza condivisione della chiave tra account. Soddisfa i requisiti di “crittografia a riposo” (encrypt at rest) ma non può imporre quali principal possano decrittare oggetti specifici: solo SSE-KMS con una CMK fornisce tale governance.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce una AWS Organization multi-account con un account Security, account Prod/NonProd separati, microservizi su ECS/EKS dietro ALB, cluster RDS/Aurora, istanze EC2 con volumi EBS e data lake su S3. Sviluppatori e automazioni utilizzano attualmente un mix di chiavi gestite da AWS, parametri SSM in chiaro e condivisione manuale occasionale di snapshot tra account.
Sfida: Un ingegnere ha accidentalmente condiviso uno snapshot RDS non crittografato con un account di terze parti e diverse credenziali API sono state trovate memorizzate come parametri SecureString in chiaro, creando un rischio di esfiltrazione di dati e di accesso non autorizzato al ripristino.
Approccio Raccomandato:
- Creare una CMK simmetrica gestita dal cliente (customer-managed) in AWS KMS con scope a livello di organization nell’account Security, con una key policy che ne conceda l’uso tramite
aws:PrincipalOrgIDagli account membri e abilitare la rotazione automatica; utilizzare i grant per operazioni cross-account di breve durata. - Bonificare gli artefatti esistenti copiando lo snapshot RDS non crittografato ed eventuali snapshot EBS, selezionando la nuova CMK per produrre copie crittografate, quindi eliminare gli snapshot originali non crittografati; impostare i valori predefiniti dell’account in modo che i nuovi RDS ed EBS creino risorse crittografate di default.
- Migrare i segreti in AWS Secrets Manager (o SSM Parameter Store SecureString) crittografandoli con la CMK, abilitare la rotazione automatica delle credenziali del DB in Secrets Manager tramite Lambda e limitare l’accesso utilizzando policy basate sulle risorse e ruoli IAM con il principio del privilegio minimo (least-privilege).
- Imporre la crittografia in transito (encryption in transit) effettuando il provisioning di certificati TLS gestiti da ACM e associandoli agli ALB con una policy TLS moderna (TLS 1.2/1.3), e configurare database e client per richiedere connessioni TLS.
- Prevenire il ripetersi del problema con dei guardrail: applicare Service Control Policies per negare la creazione/condivisione di snapshot non crittografati e i put S3 non crittografati, abilitare le regole di AWS Config per le risorse crittografate e monitorare l’uso di KMS e Secrets Manager tramite CloudTrail e allarmi CloudWatch.
Logica: L’uso di CMK centralizzate con policy a livello di organization, la re-crittografia automatizzata, Secrets Manager per il ciclo di vita dei segreti, l’imposizione del TLS e i guardrail preventivi seguono le best practice di AWS del privilegio minimo (least-privilege) e della difesa in profondità (defense-in-depth) per eliminare i segreti in chiaro e l’accesso non autorizzato agli snapshot.
CMK gestite dal cliente: multi-regione, materiale importato e policy delle chiavi
Una CMK gestita dal cliente è il piano di controllo per ogni operazione crittografica sui dati di tua proprietà in AWS. Le tre proprietà che più spesso determinano se un’architettura ha successo o causa un’interruzione sono la topologia a livello di Regione della chiave, l’origine del suo materiale crittografico e la policy ad essa associata.
Le chiavi multi-regione sono un insieme di chiavi KMS in Regioni diverse che condividono lo stesso ID di chiave e, cosa fondamentale, lo stesso materiale crittografico sottostante. Non vengono replicate automaticamente come le tabelle globali di DynamoDB: si creano esplicitamente delle repliche a partire da una chiave primaria usando ReplicateKey. Poiché il materiale crittografico è identico tra le repliche, il testo cifrato (ciphertext) prodotto in us-east-1 può essere decifrato in us-west-1 senza chiamate KMS tra Regioni diverse. Questa è esattamente la proprietà richiesta quando si replica un segreto di Secrets Manager tra più Regioni: il segreto di replica nella Regione di failover deve essere decifrabile localmente, sia per eliminare la latenza tra Regioni a ogni chiamata GetSecretValue, sia per sopravvivere a un’interruzione (outage) della Regione primaria. Una CMK a singola Regione non può supportare una replica di Secrets Manager in un’altra Regione, quindi il pattern corretto è cifrare il segreto primario con una CMK multi-regione, replicare la chiave nella Regione di destinazione e quindi replicare il segreto puntando alla CMK di replica.
aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
--replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
--secret-id prod/db \
--add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123
Il materiale crittografico importato (origine esterna, Origin=EXTERNAL) si ha quando si genera il materiale grezzo AES-256 al di fuori di AWS e lo si importa in un “guscio” di chiave KMS (key shell). AWS non possiede mai una copia di quel materiale al di fuori della memoria protetta dell’HSM, e non esiste alcun backup. Se si elimina il materiale importato — sia tramite DeleteImportedKeyMaterial sia perché la sua data di scadenza è passata — la chiave passa allo stato PendingImport e tutto il testo cifrato prodotto con quella chiave diventa irrecuperabile a meno che non si reimportino esattamente gli stessi byte. Questo è il percorso di ripristino quando, ad esempio, un volume EBS non riesce a essere collegato (attach) perché la sua chiave dati cifrata non può essere decifrata: reimportare il materiale crittografico identico dalla propria custodia offline (escrow) e il volume torna a essere utilizzabile. Non esiste un ripristino lato AWS, nessun trucco con la rotazione e nessun ticket di supporto in grado di recuperare il materiale importato eliminato. Trattare la copia offline come un’infrastruttura di livello zero (tier-zero).
Le policy delle chiavi sono la radice di attendibilità (root of trust) per ogni chiave KMS. A differenza del solo IAM, KMS richiede un’autorizzazione esplicita (allow) nella policy della chiave stessa; una policy IAM che concede kms:Decrypt è inefficace a meno che la policy della chiave non deleghi a IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} combinato con un’istruzione condizionale). Per l’uso tra account diversi (cross-account), la policy della chiave deve nominare esplicitamente l’account o il principal esterno, e l’account esterno deve quindi concedere i permessi ai propri utenti tramite IAM. Dimenticare il lato della policy della chiave è la causa più comune dei fallimenti di Secrets Manager in scenari cross-account: la policy della risorsa di Secrets Manager permette al principal esterno di chiamare GetSecretValue, ma l’operazione Decrypt sottostante fallisce perché la CMK rifiuta ancora il chiamante.
Pattern per Secrets Manager e Parameter Store SecureString
Sia Secrets Manager che i SecureString di SSM Parameter Store delegano la cifratura a KMS, ma differiscono per costo, semantica della rotazione e comportamento tra Regioni diverse. Secrets Manager supporta la replica multi-regione nativa, il versioning con etichette di staging (AWSCURRENT, AWSPENDING) e la rotazione supportata da Lambda. I SecureString di Parameter Store sono più economici, si integrano con percorsi gerarchici e funzionano bene per segreti di tipo configurazione che ruotano di rado.
Per l’accesso cross-account, è necessario aggiornare sia la policy della risorsa sul segreto (o la policy IAM nell’account consumer di Parameter Store) sia la policy della chiave KMS sulla CMK di cifratura. Presumere che i soli permessi di Secrets Manager siano sufficienti è sbagliato, perché il flusso di recupero esegue sempre un kms:Decrypt implicito sulla CMK; senza un’autorizzazione (allow) nella policy della chiave per l’account esterno, il chiamante riceve un’eccezione AccessDeniedException nella fase di Decrypt anche se la policy del segreto stesso è soddisfatta.
- Secrets Manager: rotazione gestita, struttura JSON, ~$0.40/segreto/mese, replica multi-regione integrata
- Parameter Store SecureString (Advanced): più economico per molti valori, 8 KB per parametro, nessuna replica multi-regione integrata
- Parameter Store SecureString (Standard): piano gratuito (free tier) per parametri cifrati con KMS fino a 4 KB, nessun framework di rotazione
Crittografia Envelope, Bucket Keys e Grant Tokens
La crittografia envelope (o “a busta”) significa che KMS non entra mai in contatto con i dati di massa. Si chiama GenerateDataKey, che restituisce sia una chiave dati in chiaro (usata localmente per crittografare il payload con AES-GCM) sia una copia crittografata di quella chiave dati (archiviata insieme al testo cifrato). Per decrittare, si chiama Decrypt sulla chiave dati “wrapped” (incapsulata) e si deriva nuovamente la chiave in chiaro in locale. Questo pattern è essenziale perché KMS ha quote di richiesta (per Regione, per chiave) e un costo per ogni chiamata API. Se si crittografa ogni record da 4 KB con una chiamata diretta a Encrypt, si incorrerà in throttling e in picchi di costo; se si genera una chiave dati per batch o per file, il throughput scala linearmente con la libreria di crittografia locale.
Le S3 Bucket Keys applicano lo stesso principio all’interno di S3 per SSE-KMS. Senza una bucket key, ogni PUT e GET di un oggetto SSE-KMS genera una chiamata GenerateDataKey o Decrypt. Su un bucket che riceve migliaia di oggetti al secondo, questo produce sia throttling di KMS sia una bolletta KMS sorprendentemente alta. Abilitare una bucket key fa sì che S3 generi una chiave di breve durata a livello di bucket e la riutilizzi per molti oggetti, riducendo il volume di richieste a KMS di ordini di grandezza:
aws s3api put-bucket-encryption --bucket app-data \
--server-side-encryption-configuration '{
"Rules":[{
"ApplyServerSideEncryptionByDefault":{
"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
"BucketKeyEnabled":true}]}'
I Grant sono un’alternativa alle policy delle chiavi per una delega temporanea e granulare. Sono importanti dal punto di vista operativo a causa della consistenza finale (eventual consistency): dopo che CreateGrant restituisce una risposta, il grant non è immediatamente visibile a ogni endpoint di KMS nella Regione. Se un client tenta una chiamata Encrypt pochi millisecondi dopo, potrebbe ricevere un’eccezione AccessDeniedException. Il corpo della risposta di CreateGrant include una stringa GrantToken che, se passata nelle successive chiamate a KMS tramite il parametro --grant-tokens, forza KMS a onorare immediatamente il grant, indipendentemente dallo stato di propagazione.
TOKEN=$(aws kms create-grant --key-id $KEY \
--grantee-principal arn:aws:iam::111122223333:role/worker \
--operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
--grant-tokens "$TOKEN"
Affidarsi a tentativi ripetuti con backoff invece di usare il grant token è una mitigazione valida ma inferiore: spreca latenza e fallisce comunque sotto carico. La soluzione standard è sempre: restituire il grant token dal servizio che crea il grant e richiedere ai chiamanti di presentarlo alla loro prima operazione.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial opera in un ambiente AWS multi-account che ospita PII (Personally Identifiable Information) dei clienti in S3, database transazionali in RDS ed elaborazione serverless tramite Lambda. Utilizzano CMK gestite dal cliente (Customer Managed CMK) con materiale della chiave importato per soddisfare le normative regionali sulla custodia delle chiavi e replicano le chiavi in una seconda regione per il disaster recovery.
Sfida: Un recente audit ha rilevato una policy di una chiave KMS configurata in modo errato che permetteva decrittazioni cross-account e un revisore esterno necessita di accesso temporaneo per decrittare un sottoinsieme di oggetti S3; Meridian ha anche bisogno di una rotazione sicura dei segreti e di una crittografia efficiente per oggetti di grandi dimensioni per controllare i costi delle richieste a KMS.
Approccio Raccomandato:
- Sostituire la policy della CMK configurata in modo errato in AWS KMS con una policy basata sul principio del privilegio minimo (least-privilege) che conceda esplicitamente l’accesso solo ai principal e ai ruoli IAM necessari, e creare una CMK di replica multi-regione per il DR utilizzando le chiavi multi-regione di KMS.
- Re-importare o pianificare la gestione del ciclo di vita per il materiale della chiave importato in base alle finestre temporali di conformità e abilitare le notifiche automatiche di scadenza/rotazione del materiale della chiave usando AWS Config ed EventBridge.
- Per il revisore, creare un grant KMS con un TTL (Time-To-Live) breve e utilizzare immediatamente il grant token nella sessione assume-role del revisore per consentire operazioni di decrittazione temporanee senza modificare la policy della chiave.
- Spostare le credenziali di lunga durata in AWS Secrets Manager con rotazione basata su Lambda legata al servizio sottostante (RDS o chiavi API) e archiviare i parametri infrastrutturali come SecureString in Systems Manager Parameter Store per gli elementi che non richiedono rotazione, imponendo la crittografia con la CMK e policy basate su risorse restrittive.
- Implementare la crittografia envelope per oggetti S3 di grandi dimensioni chiamando
GenerateDataKey(Encrypt/Decrypt) di KMS nel codice dell’applicazione o tramite l’AWS SDK, e abilitare le S3 Bucket Keys per ridurre le richieste a KMS e i costi per la crittografia lato server di oggetti di grandi dimensioni. - Abilitare la registrazione di CloudTrail e il logging dell’utilizzo delle chiavi KMS, e creare allarmi CloudWatch/regole GuardDuty per avvisare in caso di decrittazioni o creazioni di grant inaspettate.
Motivazione: Questo approccio impone l’accesso alle chiavi secondo il principio del privilegio minimo, preserva la conformità per il materiale importato e la continuità multi-regione, utilizza grant temporanei per un accesso sicuro da parte di terzi, centralizza i segreti con rotazione e ottimizza l’utilizzo e i costi di KMS secondo le best practice di AWS.
← Registrazione · Tutti i domini · Protezione dei dati e S3 →
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 →