AWS KMS e le customer managed key

AWS Key Management Service (KMS) è il servizio centrale per creare e governare le encryption key. Le key non escono mai dal servizio: fornisci il testo da cifrare o decifrare tramite le operazioni Encrypt/Decrypt e KMS restituisce il risultato, ma il key material resta protetto lato AWS. Distingui tra AWS managed key (create e gestite automaticamente dai servizi integrati, policy non modificabile) e customer managed key (CMK), che invece controlli tu: definisci la key policy, abiliti la rotation automatica annuale del materiale, assegni un alias e concedi accesso granulare a IAM principal e servizi tramite key policy e grant. Quando ti serve controllo su chi può usare o amministrare la key, audit dettagliato via CloudTrail o rotation su tua schedule, la CMK è la scelta corretta.

Un limite chiave da ricordare: le operazioni dirette Encrypt/Decrypt di KMS accettano payload piccoli (fino a pochi KB). Non usare KMS per cifrare direttamente file o oggetti grandi.

Envelope encryption e GenerateDataKey

Per dati oltre quel limite si usa la envelope encryption. Chiami GenerateDataKey sulla CMK: KMS ritorna una data key in chiaro e la stessa data key cifrata con la CMK. Cifri i dati localmente con la data key in chiaro (crittografia simmetrica veloce), poi elimini dalla memoria la versione in chiaro e memorizzi la data key cifrata accanto al ciphertext. Per leggere i dati chiami Decrypt sulla sola data key cifrata, ottieni la chiave in chiaro e decifri localmente. Questo pattern minimizza le chiamate a KMS, evita il limite di dimensione e permette di ruotare la CMK senza ri-cifrare i dati (cambia solo come si protegge la data key). È esattamente il meccanismo che i servizi AWS usano dietro le quinte con SSE-KMS.

Encryption at rest e in transit

L’encryption at rest protegge i dati archiviati: S3 (SSE-S3, SSE-KMS, SSE-C), EBS, RDS, DynamoDB, EFS e code SQS possono cifrare con KMS. Con SSE-KMS ottieni audit trail e controllo sulla key; ricorda che le richieste al bucket generano chiamate KMS, quindi valuta S3 Bucket Keys per ridurre costi e throttling. L’encryption in transit protegge i dati in movimento tramite TLS/HTTPS: endpoint AWS, API Gateway, ELB e connessioni RDS supportano TLS. Le due protezioni sono complementari: l’esame si aspetta che tu le applichi entrambe, non una in alternativa all’altra.

Secrets Manager vs Parameter Store

Entrambi conservano valori sensibili cifrati con KMS, ma servono scopi diversi. AWS Secrets Manager è pensato per credenziali con ciclo di vita gestito: offre rotation automatica nativa tramite funzioni Lambda (integrazione diretta con RDS, Redshift, DocumentDB), replica cross-region e ha un costo per segreto e per chiamata. SSM Parameter Store conserva configurazione e segreti come parametri; il tipo SecureString li cifra con KMS. Lo standard tier è gratuito ma non ha rotation nativa (la implementi tu, es. via EventBridge + Lambda) e ha limiti su dimensione e numero. L’advanced tier alza i limiti e abilita più policy.

Criterio pratico: se ti serve rotation automatica di credenziali database, scegli Secrets Manager; se ti serve conservare configurazione o segreti semplici a costo zero e la rotation non è un requisito, SecureString in Parameter Store è sufficiente. Parameter Store può anche referenziare segreti di Secrets Manager, combinando i due.

Trappole tipiche d’esame

  • Cifrare un file di grandi dimensioni con KMS → envelope encryption: non passare l’oggetto grande a Encrypt (supera il limite); usa GenerateDataKey e cifra localmente con la data key.
  • Serve rotation automatica di credenziali RDS → Secrets Manager: Parameter Store SecureString non offre rotation nativa; è la funzione distintiva di Secrets Manager.
  • Ridurre i costi con SecureString gratuito → Parameter Store standard tier: se lo scenario enfatizza “nessun costo aggiuntivo” e la rotation non è richiesta, la risposta è Parameter Store, non Secrets Manager.
  • Controllo completo su key policy e rotation → customer managed key: la AWS managed key non consente policy personalizzata né rotation su schedule tua.
  • Proteggere dati “in transito” → TLS/HTTPS, non KMS: KMS e SSE riguardano l’at rest; l’encryption in transit si ottiene con TLS sugli endpoint e sulle connessioni.
  • App che decifra ripetutamente lo stesso oggetto → cache della data key: decifrare la data key una volta e riusarla riduce chiamate a KMS e throttling, invece di chiamare Decrypt per ogni operazione.