IAM e least privilege

AWS Identity and Access Management (IAM) è la base della sicurezza operativa. Il principio di least privilege richiede di concedere solo i permessi effettivamente necessari e di partire da policy restrittive, ampliandole quando servono. Per i workload su EC2 non si distribuiscono mai access key statiche: si assegna un IAM role tramite l’instance profile, così le credenziali temporanee vengono ruotate automaticamente e non finiscono nel codice o nelle AMI. Le policy identity-based si attaccano a utenti, gruppi e ruoli; quelle resource-based (S3 bucket policy, KMS key policy) al servizio. Per irrigidire il perimetro esistono le permission boundary, mentre IAM Access Analyzer individua risorse accessibili dall’esterno dell’account. In operations la regola pratica è: ruoli e credenziali temporanee, non utenti IAM long-lived.

Encryption con KMS e gestione dei segreti

AWS Key Management Service (KMS) gestisce le chiavi con envelope encryption: una data key cifra i dati, la KMS key cifra la data key. Esistono customer managed key (controllo pieno su rotazione e policy), AWS managed key e AWS owned key. Un punto operativo cruciale: l’accesso a una KMS key dipende sia dalla policy IAM del principal sia dalla key policy della chiave. Se un utente riceve AccessDenied leggendo un oggetto S3 o un volume EBS cifrato pur avendo i permessi IAM, quasi sempre manca l’autorizzazione nella key policy o nel grant. La rotazione automatica delle customer managed key è annuale.

Per i segreti applicativi (password DB, API key) si usa AWS Secrets Manager, che offre rotazione automatica gestita da una Lambda, con integrazione nativa per RDS. In alternativa Systems Manager Parameter Store conserva parametri (anche cifrati con KMS via SecureString) senza costi per parametro standard, ma senza rotazione automatica nativa. Criterio d’esame: se lo scenario richiede rotazione automatica di credenziali RDS, la risposta è Secrets Manager.

Detection, audit e compliance

Amazon GuardDuty è il servizio di threat detection: analizza in modo agentless le sorgenti già presenti (CloudTrail, VPC Flow Logs, DNS logs) e segnala comportamenti anomali come istanze compromesse o esfiltrazione. Non richiede l’installazione di agent sulle istanze.

AWS Config registra nel tempo la configurazione delle risorse e valuta la compliance tramite Config rules (managed o custom); i conformance pack raggruppano regole per framework, e la remediation può essere automatizzata con SSM Automation. Config risponde alla domanda “questa risorsa è conforme adesso e com’era ieri?”.

AWS CloudTrail è invece l’audit trail delle chiamate API. Registra di default i management event, mentre i data event (es. GetObject su S3, invocazioni Lambda) vanno abilitati esplicitamente. Per un audit affidabile si usa un trail multi-region con log file validation, che rileva manomissioni dei log. Distinzione chiave: Config traccia lo stato di configurazione, CloudTrail traccia chi ha fatto cosa.

Guardrail con AWS Organizations

AWS Organizations centralizza la governance multi-account. Le Service Control Policy (SCP) sono guardrail che definiscono il tetto massimo di permessi per gli account di una OU: limitano ma non concedono mai. Un’azione è consentita solo se è permessa sia dalle SCP sia dalle policy IAM; la SCP da sola non abilita nulla. Con Organizations si abilitano centralmente GuardDuty, Config e un organization trail di CloudTrail, e si designano delegated administrator per gestire i servizi di sicurezza fuori dal management account. Il passing score dell’esame SOA-C03 è 700/1000.

Trappole tipiche d’esame

  • AccessDenied su risorsa cifrata con KMS pur avendo i permessi IAM → controlla la key policy: l’accesso a una KMS key richiede autorizzazione sia in IAM sia nella key policy o in un grant.
  • Scenario che chiede di “dare più permessi” con una SCP → risposta sbagliata: le SCP limitano il massimo consentito, non concedono privilegi; servono comunque policy IAM.
  • Credenziali hardcoded su EC2 → usa un IAM role via instance profile: mai access key statiche, si sfruttano credenziali temporanee auto-ruotate.
  • Rotazione automatica di password RDS → Secrets Manager, non Parameter Store: Parameter Store non ha rotazione nativa integrata.
  • “Installa l’agent GuardDuty” → è agentless: GuardDuty analizza log esistenti, non richiede agent sulle istanze.
  • Audit di accessi a oggetti S3 assente in CloudTrail → abilita i data event: di default CloudTrail registra solo i management event.