Encryption e audit: KMS multi-region e CloudTrail

In scenari enterprise multi-account la protezione dei dati at rest ruota attorno ad AWS KMS. La scelta a livello professional è tra una CMK regionale e una multi-region key: quest’ultima replica lo stesso key material (stesso key ID) in più region, così un oggetto cifrato in una region può essere decifrato nel sito di failover senza ri-cifratura. È il pattern corretto quando repliche cross-region di Amazon S3, DynamoDB global tables o snapshot EBS devono restare leggibili nella region secondaria. Attenzione: le multi-region key non sono globali; ogni replica ha una key policy indipendente e va gestita per region.

Per la governance preferisci customer managed key alle AWS managed key quando servono key policy granulari, rotation controllata e condivisione cross-account via grant. Con AWS Organizations, le SCP possono imporre che i bucket rifiutino upload non cifrati o che si usino solo determinate CMK. Ogni operazione KMS è tracciata da AWS CloudTrail: abilita un organization trail centralizzato verso un bucket S3 in un log-archive account, con log file validation per l’integrità. È l’audit trail che l’esame si aspetta per compliance e forensics.

Rilevamento e protezione: GuardDuty, WAF, Shield

Amazon GuardDuty è il servizio di threat detection: analizza VPC Flow Logs, DNS logs e CloudTrail management events senza agenti, segnalando credenziali compromesse, comunicazioni con C2 o crypto mining. A livello enterprise si abilita sull’organization con un delegated administrator account, così ogni nuovo account eredita la copertura. I finding confluiscono in AWS Security Hub per la vista aggregata e in Amazon EventBridge per remediation automatica (es. isolare una EC2).

Sul perimetro applicativo distingui i livelli: AWS WAF filtra traffico L7 (SQL injection, XSS, rate-based rule) su CloudFront, ALB e API Gateway; AWS Shield Standard protegge da DDoS L3/L4 gratuitamente, mentre Shield Advanced aggiunge protezione sui costi, DDoS Response Team e copertura estesa. Per l’ispezione egress/ingress centralizzata usa AWS Network Firewall dietro un Transit Gateway. Non confondere i ruoli: WAF non ferma un volumetrico L4, Shield non ispeziona i payload HTTP.

Disaster recovery multi-region: le quattro strategie

La resilienza cross-region si sceglie bilanciando RTO (tempo di ripristino) e RPO (perdita dati tollerata) contro il costo:

  • Backup & restore: snapshot replicati nella region secondaria; RTO/RPO nell’ordine di ore, costo minimo. Ricostruisci l’infrastruttura on demand via IaC.
  • Pilot light: i dati sono replicati in continuo (es. Aurora cross-region replica) e i componenti core esistono spenti o minimi; il compute si accende al disastro. RTO in decine di minuti.
  • Warm standby: una copia funzionante ma sottodimensionata gira sempre nella region secondaria e serve poco traffico; al failover si scala. RTO in minuti, costo medio. È la scelta quando “compute ridotto sempre attivo” compare nello scenario.
  • Active-active (multi-site): entrambe le region servono traffico produttivo, RTO/RPO prossimi a zero, costo massimo e maggiore complessità (conflict resolution dei dati).

Il traffico si dirotta con Amazon Route 53 (failover, latency o weighted routing) con health check, oppure con AWS Global Accelerator per un failover più rapido a livello di rete. Per i dati, DynamoDB global tables e Aurora Global Database abilitano warm standby e active-active con replica gestita. AWS Elastic Disaster Recovery (DRS) replica workload on-prem o EC2 con RPO di secondi senza riarchitettare.

Trappole tipiche d’esame

  • Oggetto S3 cifrato illeggibile dopo il failover cross-region → multi-region KMS key: una CMK regionale non decifra nella region secondaria; serve la replica della multi-region key, non una chiave nuova.
  • “Compute ridotto sempre attivo” con RTO di minuti → warm standby: pilot light tiene il compute spento (RTO più alto), active-active costa troppo per quel requisito.
  • DDoS volumetrico L3/L4 → Shield, non WAF: WAF opera a L7; per SYN flood e reflection serve Shield Advanced.
  • Threat detection su tutti gli account → GuardDuty con delegated admin in Organizations: abilitarlo account per account è overhead e lascia scoperti i nuovi account.
  • RPO di secondi per workload on-prem → AWS Elastic Disaster Recovery: i backup periodici danno RPO in ore; DRS fa replica continua a livello di blocco.
  • Audit centralizzato e immutabile delle operazioni sulle chiavi → organization CloudTrail + log file validation: un trail per-account è frammentato e alterabile dall’account stesso.