Perché l’encryption è un tema centrale del DEA-C01

Da data engineer su AWS non decidi se cifrare, ma come: quale servizio di gestione chiavi usare, dove applicare la cifratura e come dimostrarne la conformità. L’esame verte quasi sempre su scelte di trade-off — costo, controllo, auditabilità — più che sulla configurazione meccanica. I due pilastri sono AWS KMS per la gestione delle chiavi e Amazon Macie per scoprire dove vivono i dati sensibili (PII).

AWS KMS: chiavi, policy ed envelope encryption

KMS gestisce le chiavi crittografiche che quasi tutti i servizi dati usano. Devi distinguere tre tipi di chiave:

  • AWS owned keys: gestite interamente da AWS, invisibili e senza controllo. Zero effort, zero audit granulare.
  • AWS managed keys (alias aws/s3, aws/redshift): create per servizio, con rotazione automatica, ma la key policy non è modificabile.
  • Customer managed keys (CMK): le controlli tu. Puoi definire key policy e grants, abilitare la rotation automatica annuale, usarle cross-account, renderle multi-Region, e disabilitarle o schedularne l’eliminazione (con un waiting period obbligatorio di 7-30 giorni).

KMS usa envelope encryption: la chiave KMS non cifra direttamente i dati ma protegge una data key che a sua volta cifra il payload. Questo evita di trasferire grandi volumi a KMS. Ogni chiamata cripto è registrata in CloudTrail, il che rende le CMK la scelta quando serve un audit trail. Ricorda: l’accesso è controllato dall’intersezione di key policy e IAM policy — una CMK con key policy restrittiva blocca l’accesso anche se l’IAM lo consente.

Encryption at rest: S3 e Redshift

Su Amazon S3 le opzioni di server-side encryption sono:

  • SSE-S3: chiavi gestite da S3 (AES-256), semplice, nessun controllo sulle chiavi.
  • SSE-KMS: usa una chiave KMS, con audit su CloudTrail e permessi fini. È il default richiesto quando lo scenario cita compliance o separazione dei ruoli. Attiva S3 Bucket Keys per ridurre drasticamente le chiamate a KMS ed evitare il throttling su bucket ad alto traffico.
  • DSSE-KMS: doppio strato di cifratura KMS, per requisiti regolatori stringenti.
  • SSE-C: fornisci tu la chiave a ogni richiesta; AWS non la conserva.

Imposta la default encryption a livello di bucket, così ogni oggetto è cifrato anche senza header espliciti. Su Amazon Redshift abiliti l’encryption at rest con KMS (o CloudHSM) alla creazione del cluster; cambiarla richiede un ciclo di ri-cifratura gestito. Anche Glue Data Catalog, i log di CloudWatch, gli stream Kinesis e le code SQS supportano cifratura KMS.

Encryption in transit e Amazon Macie per la PII

La cifratura at rest non basta: proteggi i dati anche in transit con TLS/SSL. Redshift può forzarlo tramite il parametro require_ssl; S3 lo impone con una bucket policy che nega il traffico non-aws:SecureTransport. I VPC endpoints mantengono il traffico verso S3, KMS e Redshift dentro la rete AWS.

Amazon Macie scopre dati sensibili in S3 (solo S3). Usa managed data identifiers per PII, PHI e dati finanziari comuni, e custom data identifiers (regex) per pattern aziendali. Lanci sensitive data discovery jobs, ricevi findings che confluiscono in Security Hub ed EventBridge per l’automazione, e ottieni una vista continua su bucket pubblici o non cifrati. Macie è la risposta corretta ogni volta che lo scenario chiede di identificare PII, non di cifrarla.

Trappole tipiche d’esame

  • Serve audit di ogni operazione crittografica su S3 → SSE-KMS con CMK: SSE-S3 non registra l’uso della chiave su CloudTrail; solo KMS lo fa.
  • Throttling KMS ThrottlingException su un bucket ad alto volume → abilita S3 Bucket Keys: riducono le chiamate a KMS senza cambiare il modello di sicurezza. Aumentare il rate limit è la risposta sbagliata.
  • “Individuare dove si trovano le PII” → Amazon Macie, non KMS né GuardDuty: KMS cifra, GuardDuty rileva minacce; solo Macie fa discovery di dati sensibili, e solo su S3.
  • Accesso negato pur avendo la IAM policy corretta → controlla la key policy della CMK: l’accesso a KMS richiede il permesso in entrambe; la key policy prevale.
  • Rotazione automatica desiderata ma chiave AWS owned/managed → passa a una CMK: solo con customer managed key controlli policy e rotation configurabile.
  • Eliminazione immediata di una chiave compromessa → impossibile: KMS impone un waiting period (7-30 giorni); nel frattempo puoi solo disabilitare la chiave.