AWS KMS: chiavi, key policy e grant

AWS Key Management Service (KMS) è il servizio centrale per la crittografia gestita. Esistono le customer managed key (CMK), che crei e controlli tu (key policy, alias, rotazione, abilitazione/disabilitazione, tag), e le AWS managed key (nella forma aws/service, es. aws/s3), gestite automaticamente dai servizi: non puoi modificarne la policy né la pianificazione di rotazione. Per scenari di sicurezza con requisiti di controllo e audit granulare la risposta corretta è quasi sempre la customer managed key.

Il concetto cardine dell’esame è la key policy: è l’autorizzazione radice della chiave. Nessun principal — nemmeno l’account root o un amministratore IAM — accede a una KMS key se la key policy non lo consente. Le policy IAM da sole non bastano: servono sia una key policy che deleghi ad IAM ("Principal": {"AWS": "arn:aws:iam::<account>:root"}) sia una policy IAM sull’identità. Questo modello è ciò che abilita l’accesso cross-account: il proprietario della chiave concede nella key policy, l’altro account concede a sua volta ai propri principal via IAM. I grant offrono deleghe temporanee e granulari (con GrantConstraints come EncryptionContext), utili quando un servizio deve usare la chiave per conto di un utente senza modificare la policy. Ricorda che un deny esplicito prevale sempre: una condition key come kms:ViaService o l’assenza di aws:PrincipalOrgID può bloccare l’uso anche se altrove è concesso.

La rotazione automatica delle CMK (annuale, estendibile) ruota il materiale crittografico mantenendo lo stesso key ID e ARN: i dati vecchi restano decifrabili con le versioni precedenti. Con l’imported key material (BYOK) porti tu il materiale: la rotazione automatica non è disponibile e sei responsabile della sua conservazione. Le multi-Region key replicano una chiave con lo stesso key ID in più Region, così un ciphertext prodotto in una Region è decifrabile nella replica dell’altra: sono la soluzione per disaster recovery cross-Region e replica S3 lato client, ma non sono globali per default (vanno replicate esplicitamente).

Envelope encryption e encryption at rest

L’envelope encryption è il pattern usato da KMS e dai servizi integrati: KMS non cifra grandi volumi di dati direttamente (limite ridotto sul payload), ma genera una data key (via GenerateDataKey). La data key in chiaro cifra i dati localmente; la versione cifrata della data key viene conservata accanto al ciphertext. Per decifrare, il servizio invia la data key cifrata a KMS, che la decifra con la CMK, e con essa si decifra il dato. Così la CMK non lascia mai KMS e si scala su qualsiasi dimensione di dato.

Su questa base poggia l’encryption at rest: S3 SSE-KMS (con la key policy che governa chi cifra/decifra e l’opzione S3 Bucket Keys per ridurre le chiamate KMS), EBS (volumi cifrati, snapshot cifrati, encryption by default a livello di Region), RDS (cifratura a riposo abilitabile solo alla creazione dell’istanza; una istanza non cifrata si migra via snapshot cifrato) e DynamoDB (cifratura sempre attiva, con opzione di CMK). L’enforcement dell’encryption su S3 si ottiene con una bucket policy che nega s3:PutObject quando manca l’header corretto (condition su s3:x-amz-server-side-encryption o aws:SecureTransport per forzare TLS), non affidandosi al solo default del bucket.

CloudHSM, ACM e TLS in transito

AWS CloudHSM fornisce HSM single-tenant dedicati, con controllo esclusivo del materiale e conformità FIPS 140-3 Level 3: è la scelta quando i requisiti normativi impongono che le chiavi risiedano in hardware dedicato sotto tuo pieno controllo, o serve un custom key store KMS supportato da CloudHSM. Per l’encryption in transit, AWS Certificate Manager (ACM) emette e rinnova automaticamente certificati TLS pubblici gratuiti da integrare con ELB/ALB, CloudFront e API Gateway; le chiavi private dei certificati ACM non sono esportabili. Per TLS su EC2 o on-premises serve ACM Private CA o certificati importati.

Trappole tipiche d’esame

  • Un utente IAM con AdministratorAccess non riesce a usare una KMS key → key policy: l’accesso amministrativo IAM non basta; la key policy deve delegare ad IAM o nominare il principal. Verifica sempre la key policy.
  • Serve rotazione automatica ma la chiave usa imported key material → non disponibile: con BYOK la rotazione automatica KMS non è supportata; usa una CMK con materiale generato da AWS o ruota manualmente creando una nuova chiave.
  • Ciphertext deve essere decifrabile in un’altra Region per DR → multi-Region key: una chiave regionale standard non decifra fuori Region. Servono multi-Region key replicate, non la semplice copia dello snapshot.
  • Requisito FIPS 140-3 Level 3 con controllo hardware esclusivo → CloudHSM: KMS usa HSM multi-tenant validati; per single-tenant dedicato e controllo totale la risposta è CloudHSM (o custom key store).
  • Impedire upload S3 non cifrati o in chiaro → bucket policy con Deny: l’encryption by default non blocca chi specifica esplicitamente nessuna cifratura; serve un Deny esplicito su s3:PutObject con condition sull’header SSE e su aws:SecureTransport.
  • Rendere una RDS esistente cifrata → snapshot + restore cifrato: non si abilita la cifratura at rest su una istanza RDS già creata; crea uno snapshot, copialo cifrato con la CMK e ripristina da quello.