KMS, ACM e pattern di crittografia
Gestire le chiavi di crittografia con AWS KMS, fornire e ruotare i certificati TLS con ACM e scegliere tra crittografia lato client, lato server e in transito
KMS, ACM e pattern di crittografia è una lezione AWS Solutions Architect gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento AWS Solutions Architect, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso AWS Solutions Architect include 4 lezioni in totale.
Crittografia su AWS: panoramica
La crittografia è un controllo di sicurezza fondamentale che protegge la riservatezza dei dati anche nel caso in cui i supporti di archiviazione vengano compromessi o si ottenga l'accesso attraverso altri mezzi. AWS offre la crittografia dei dati a riposo (archiviati in database, S3 ed EBS) e in transito (in movimento sulle reti). Servizi principali: AWS Key Management Service (KMS) gestisce le chiavi di crittografia per la crittografia dei dati a riposo. AWS Certificate Manager (ACM) fornisce e gestisce certificati TLS per la crittografia dei dati in transito. Comprendere quando e come applicare ciascun servizio è essenziale per il dominio Security Architecture di SAA-C03.
# Encryption coverage on AWS:
# At rest (KMS):
# S3, EBS, RDS, DynamoDB, EFS, SQS,
# Lambda env vars, Secrets Manager, SSM Parameter Store
# In transit (ACM/TLS):
# ALB listeners (HTTPS), API Gateway, CloudFront,
# Direct Connect, VPN, inter-service communication
# Both:
# S3 Server-Side Encryption + HTTPS only policyAWS KMS: Key Management Service
AWS KMS è un servizio completamente gestito per creare e controllare le chiavi di crittografia. KMS utilizza Hardware Security Modules (HSM) per proteggere le chiavi: il materiale della chiave non lascia mai l'HSM senza essere crittografato. KMS si integra con la maggior parte dei servizi AWS per la crittografia lato server. Tipi di chiavi: AWS Managed Keys (gratuite, ruotate automaticamente ogni anno, non è possibile controllarle direttamente), Customer Managed Keys (CMK) (1 $ al mese ciascuna, con controllo su rotazione, policy della chiave ed eliminazione). Custom Key Store utilizza il proprio cluster CloudHSM per i requisiti di conformità che impongono HSM dedicati.
# Create a Customer Managed Key (CMK)
aws kms create-key \
--description 'Production database encryption key' \
--key-usage ENCRYPT_DECRYPT \
--origin AWS_KMS \
--tags TagKey=Purpose,TagValue=RDS-Encryption
# Create an alias for the key
aws kms create-alias \
--alias-name alias/prod-db-key \
--target-key-id arn:aws:kms:us-east-1:123:key/abc-def
# CMK costs: $1/month + $0.03 per 10,000 API callsPolicy e grant delle chiavi KMS
Ogni chiave KMS dispone di una key policy, ovvero una policy basata sulle risorse che controlla chi può utilizzare e gestire la chiave. A differenza delle policy IAM, basate sull'identità, le key policy sono obbligatorie: la key policy deve concedere esplicitamente l'accesso affinché le policy IAM abbiano effetto. Best practice: separare l'amministrazione della chiave (chi può gestirla) dall'utilizzo della chiave (quali servizi e ruoli possono crittografare/decrittografare). Utilizzi i key grant per delegare temporaneamente l'accesso; ad esempio, può concedere a un cluster EMR l'uso temporaneo di una chiave KMS per un job senza modificare la key policy.
# KMS key policy: grant RDS and admin access
{
'Statement': [
{
'Sid': 'Enable root account full access',
'Principal': {'AWS': 'arn:aws:iam::123:root'},
'Action': 'kms:*',
'Effect': 'Allow'
},
{
'Sid': 'Allow RDS to use this key',
'Principal': {'Service': 'rds.amazonaws.com'},
'Action': ['kms:Encrypt','kms:Decrypt','kms:GenerateDataKey'],
'Effect': 'Allow'
}
]
}Crittografia envelope con KMS
KMS utilizza la crittografia envelope per proteggere in modo efficiente grandi quantità di dati. Non è possibile crittografare direttamente con una chiave KMS più di 4 KB. Al suo posto: KMS genera una Data Encryption Key (DEK), una chiave casuale utilizzata per crittografare localmente i dati effettivi. La DEK viene quindi crittografata dalla chiave KMS (la Key Encryption Key). La DEK crittografata viene archiviata insieme ai dati crittografati. Per decrittografare, si chiama prima KMS per decrittografare la DEK, quindi si utilizza localmente la DEK in testo normale per decrittografare i dati. Questo è il funzionamento alla base della crittografia di S3, EBS e RDS.
# Generate a Data Key (for envelope encryption)
aws kms generate-data-key \
--key-id alias/my-key \
--key-spec AES_256
# Response contains:
# Plaintext: base64-encoded DEK (use to encrypt data locally)
# CiphertextBlob: KMS-encrypted DEK (store alongside data)
# To decrypt:
# 1. Call kms:Decrypt(CiphertextBlob) -> plaintext DEK
# 2. Use plaintext DEK to decrypt data locally
# 3. Zeroize plaintext DEK from memory
aws kms decrypt --ciphertext-blob fileb://encrypted-dek.binRotazione delle chiavi KMS
La rotazione delle chiavi è una best practice di sicurezza che sostituisce periodicamente il materiale crittografico delle chiavi, limitando la finestra di esposizione nel caso in cui una chiave venga compromessa. Per le Customer Managed Keys, è possibile abilitare la rotazione automatica annuale: KMS genera nuovo materiale della chiave e lo utilizza per le nuove operazioni di crittografia, conservando il materiale precedente per decrittografare i dati esistenti. Le AWS Managed Keys vengono ruotate automaticamente ogni anno. Il materiale delle chiavi importato NON supporta la rotazione automatica (è necessario ruotarlo manualmente). Dopo la rotazione, le nuove operazioni KMS utilizzano automaticamente il nuovo materiale della chiave senza modifiche all'applicazione.
# Enable automatic annual key rotation
aws kms enable-key-rotation \
--key-id alias/prod-db-key
# Verify rotation is enabled
aws kms get-key-rotation-status \
--key-id alias/prod-db-key
# Manual rotation (for imported key material):
# 1. Create a new CMK
# 2. Update all services to use new key
# 3. Re-encrypt existing data with new key
# 4. Schedule old key for deletion (minimum 7-day waiting period)Opzioni di crittografia lato server di S3
S3 supporta tre opzioni di crittografia lato server: SSE-S3: S3 gestisce le chiavi utilizzando AES-256; è gratuita e offre il controllo minimo. SSE-KMS: utilizza una chiave KMS (gestita da AWS o una CMK), fornisce una traccia di audit della chiave in CloudTrail, supporta le key policy e prevede un costo per ogni chiamata API KMS. SSE-C: il cliente fornisce e gestisce il materiale della chiave con ogni richiesta; S3 non archivia mai la chiave. Utilizzi SSE-KMS quando è necessario controllare tramite audit chi ha utilizzato la chiave e quando. Utilizzi SSE-S3 per dati a bassa sensibilità, quando semplicità e costi sono prioritari. Imponga la crittografia con una policy del bucket che neghi PutObject senza crittografia.
# Enforce SSE-KMS on all new S3 objects
aws s3api put-bucket-policy \
--bucket my-secure-bucket \
--policy '{
"Statement": [{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-secure-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}]
}'
# Set default encryption for bucket
aws s3api put-bucket-encryption \
--bucket my-secure-bucket \
--server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/my-key"}}]}'AWS Certificate Manager (ACM)
AWS Certificate Manager (ACM) fornisce, gestisce e rinnova automaticamente i certificati SSL/TLS per i servizi AWS senza costi. I certificati ACM possono essere utilizzati con ALB, NLB, CloudFront, API Gateway e AppSync. ACM gestisce automaticamente il ciclo di vita dei certificati: li rinnova 60 giorni prima della scadenza e distribuisce il rinnovo in modo trasparente. È possibile richiedere certificati per i domini di cui si è proprietari (convalidati tramite DNS o e-mail) oppure importare certificati di terze parti. I certificati ACM NON sono scaricabili: sono associati al servizio AWS a cui vengono collegati.
# Request a public ACM certificate
aws acm request-certificate \
--domain-name app.example.com \
--subject-alternative-names '*.example.com' \
--validation-method DNS
# ACM returns a CNAME record to add to Route 53
# Add the CNAME -> ACM validates domain ownership
# Certificate is issued and auto-renews annually
# Attach to ALB listener (HTTPS:443)
aws elbv2 create-listener \
--load-balancer-arn <ALB-ARN> \
--protocol HTTPS --port 443 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123:certificate/abc \
--default-actions Type=forward,TargetGroupArn=<TG-ARN>ACM Private Certificate Authority
ACM Private CA (Certificate Authority) consente di creare una gerarchia di CA private completamente gestita per emettere certificati per risorse interne — istanze EC2, container, API interne e dispositivi IoT. A differenza dei certificati ACM pubblici (utilizzati con servizi esposti su Internet), i certificati delle CA private possono essere emessi per qualsiasi hostname o indirizzo IP interno. Utilizzi Private CA per: TLS reciproco (mTLS) tra microservizi, autenticazione basata su certificati per VPN e requisiti di conformità per la PKI interna. Private CA costa 400 $ al mese per la CA, oltre a 0,75 $ per ogni certificato emesso.
# Create ACM Private Certificate Authority
aws acm-pca create-certificate-authority \
--certificate-authority-type ROOT \
--certificate-authority-configuration '{
"KeyAlgorithm": "RSA_2048",
"SigningAlgorithm": "SHA256WITHRSA",
"Subject": {
"Country": "US",
"Organization": "Example Corp",
"CommonName": "Example Corp Internal CA"
}
}'
# Issue certificate from private CA
aws acm request-certificate \
--domain-name internal-service.example.internal \
--certificate-authority-arn arn:aws:acm-pca:us-east-1:123:certificate-authority/xxxCrittografia di EBS e RDS
Per la crittografia dei volumi EBS, la attivi al momento della creazione del volume (oppure copi un volume esistente con la crittografia attivata). Tutti i dati presenti nel volume, inclusi gli snapshot, vengono crittografati utilizzando la chiave KMS specificata. La crittografia EBS è trasparente per il sistema operativo: non sono necessarie modifiche all'applicazione. Per la crittografia RDS, la attivi durante la creazione dell'istanza DB; non è possibile crittografare direttamente un'istanza RDS esistente non crittografata. Soluzione alternativa: crei uno snapshot crittografato da un'istanza non crittografata, quindi lo ripristini in una nuova istanza crittografata. Gli snapshot crittografati di EBS e RDS rimangono crittografati anche quando vengono copiati.
# Enable account-level EBS default encryption
aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id \
--kms-key-id alias/prod-ebs-key
# Encrypt an existing unencrypted RDS instance:
# 1. Create unencrypted snapshot
aws rds create-db-snapshot \
--db-instance-identifier mydb \
--db-snapshot-identifier mydb-plain-snapshot
# 2. Copy snapshot with encryption
aws rds copy-db-snapshot \
--source-db-snapshot-identifier mydb-plain-snapshot \
--target-db-snapshot-identifier mydb-encrypted-snapshot \
--kms-key-id alias/prod-db-keyCrittografia lato client e lato server
Comprendere la distinzione tra crittografia lato server e lato client è importante per l'esame SAA-C03. Crittografia lato server: AWS crittografa i dati dopo averli ricevuti e li decrittografa prima di consegnarli; i dati sono in chiaro tra l'applicazione e AWS. Crittografia lato client: Lei crittografa i dati prima di inviarli ad AWS; AWS archivia solo il testo cifrato e non vede mai i dati in chiaro. Utilizzi la crittografia lato client per i dati con il più alto livello di sensibilità, quando non può affidare al provider cloud la gestione dei dati in chiaro, ad esempio per cartelle cliniche o dati finanziari soggetti a normative rigorose.
# Client-side encryption with AWS Encryption SDK
# (conceptual Python example)
# 1. Application encrypts data locally using KMS DEK
# from aws_encryption_sdk import KmsKeyProvider, encrypt
# key_provider = KmsKeyProvider(key_ids=['alias/my-key'])
# ciphertext, _ = encrypt(
# source=b'Sensitive patient data',
# key_provider=key_provider
# )
# 2. Send ciphertext to S3
# s3.put_object(Bucket='hipaa-data', Key='record.enc', Body=ciphertext)
# AWS only stores ciphertext - cannot decrypt without your key policyAccesso tra account a KMS
Le chiavi KMS possono essere condivise tra account AWS per scenari di crittografia tra account. Ad esempio, se l'applicazione dell'Account A scrive dati crittografati in un bucket S3 di proprietà dell'Account B, la chiave KMS dell'Account A deve consentire al principale dell'Account B di utilizzarla. Configuri la policy della chiave KMS nell'Account A per concedere l'accesso tra account, quindi crei una policy IAM nell'Account B per consentire al ruolo di utilizzare la chiave dell'Account A. Questo modello è comune nelle architetture di condivisione dei dati e multi-account, in cui un account centrale gestisce le chiavi di crittografia.
# KMS key policy: allow cross-account access
# (in Account A's key policy)
{
'Sid': 'Allow Account B to use this key',
'Effect': 'Allow',
'Principal': {
'AWS': 'arn:aws:iam::999999999999:root'
},
'Action': [
'kms:Encrypt',
'kms:Decrypt',
'kms:ReEncrypt*',
'kms:GenerateDataKey*',
'kms:DescribeKey'
],
'Resource': '*'
}
# Account B IAM policy also needed to allow the role to use itVerifica rapida
Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.
Riepilogo della lezione
In questa lezione ha imparato che: KMS gestisce le chiavi di crittografia con protezione HSM e supporta le CMK per un controllo degli accessi granulare e audit trail, ACM fornisce e rinnova automaticamente i certificati TLS per i servizi AWS senza costi e la crittografia può essere applicata lato server (KMS) o lato client, con la crittografia lato server come modello più comune per i workload nativi AWS. Imponga la crittografia tramite bucket policy che neghino le operazioni non crittografate. Prossimamente esamineremo GuardDuty, Inspector e Macie.
Domande Frequenti
La lezione «KMS, ACM e pattern di crittografia» è gratuita?
Sì — il testo completo di «KMS, ACM e pattern di crittografia» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso AWS Solutions Architect, passa a CoddyKit PRO. Il corso AWS Solutions Architect include 4 lezioni in totale.
Cosa imparerò in «KMS, ACM e pattern di crittografia»?
Gestire le chiavi di crittografia con AWS KMS, fornire e ruotare i certificati TLS con ACM e scegliere tra crittografia lato client, lato server e in transito Eserciti AWS Solutions Architect con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare AWS Solutions Architect?
Non è richiesta alcuna esperienza precedente. AWS Solutions Architect su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.
Quanto tempo richiede la lezione «KMS, ACM e pattern di crittografia»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione AWS Solutions Architect?
Sì. Ogni lezione AWS Solutions Architect include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- KMS, ACM e pattern di crittografia
- GuardDuty, Inspector e Macie
- Secrets Manager e Parameter Store
- WAF, Shield e Network Firewall