Responsabilita condivisa e IAM

Il modello di responsabilità condivisa

La sicurezza su AWS è un lavoro condiviso tra provider e cliente, riassunto nella distinzione tra “security of the cloud” e “security in the cloud”. AWS è responsabile della sicurezza of the cloud: infrastruttura fisica, data center, hardware, rete di base, virtualizzazione e controlli ambientali. Il cliente è responsabile della sicurezza in the cloud: i dati che carica, la loro classificazione e cifratura, la configurazione dei servizi, la gestione delle identità e degli accessi, e le regole di rete a livello applicativo.

Il concetto chiave è che AWS non guarda mai dentro i tuoi dati e non corregge le tue misconfigurazioni. Se lasci un bucket Amazon S3 pubblico o assegni permessi troppo ampi, la responsabilità è tua. Al contrario, la sicurezza dell’hypervisor o la sostituzione di un disco guasto nel data center non ti riguardano.

Il confine si sposta per servizio

Non esiste una linea fissa: il confine dipende dal modello del servizio. Con Amazon EC2 (IaaS) sei responsabile del sistema operativo guest, delle patch, del firewall a livello di istanza (security group), del runtime e dell’applicazione; AWS gestisce solo l’infrastruttura sottostante. Con un servizio managed come Amazon RDS, AWS si occupa del patching di sistema operativo e database engine, mentre tu resti responsabile di account applicativi, policy di accesso e dati. Con servizi più astratti (ad esempio Amazon S3 o AWS Lambda) AWS gestisce ancora di più, ma configurazione degli accessi e protezione dei dati restano sempre tue.

Regola pratica per l’esame: più il servizio è managed, più responsabilità operativa passa ad AWS, ma la gestione di dati, identità e accessi rimane sempre del cliente.

AWS IAM: identità, policy e least privilege

AWS Identity and Access Management (IAM) controlla chi può fare cosa su quali risorse. È un servizio globale e gratuito. Gli elementi principali:

• IAM user: identità permanente per una persona o un’applicazione.
• IAM group: raccolta di user a cui si assegnano permessi in blocco; semplifica la gestione.
• IAM role: identità assumibile temporaneamente, senza credenziali permanenti. È il meccanismo corretto per dare permessi a un’istanza EC2, a una Lambda o a un’identità federata, evitando di incorporare chiavi statiche nel codice.
• IAM policy: documento (in JSON) che definisce i permessi (allow/deny) e si collega a user, group o role.

Il principio guida è il least privilege: concedi solo i permessi strettamente necessari a svolgere un compito, ampliandoli se serve, invece di partire da accessi ampi. Preferisci i role alle chiavi di accesso a lunga durata, usa i group per non gestire i permessi utente per utente, e ricorda che un deny esplicito prevale sempre su un allow.

Root user e MFA

Il root user è l’identità creata insieme all’account AWS, associata all’email di registrazione, con accesso completo e illimitato, incluse azioni che nessun altro può compiere (chiudere l’account, modificare il piano di supporto, alcune impostazioni di fatturazione). Proprio per questo non va usato per le attività quotidiane. Best practice: crea un IAM user (o usa identità federate) con i permessi necessari all’operatività, non generare access key per il root user, e proteggilo con una password forte.

MFA (Multi-Factor Authentication) aggiunge un secondo fattore oltre alla password: anche se le credenziali vengono rubate, l’accesso resta bloccato senza il secondo fattore. L’esame considera l’abilitazione dell’MFA sul root user come la singola misura di protezione più importante, e la raccomanda anche per tutti gli IAM user con permessi rilevanti.

Trappole tipiche d’esame

• Patchare il sistema operativo di un’istanza EC2 → responsabilità del cliente: in IaaS AWS gestisce solo l’infrastruttura; OS guest, patch e security group sono tuoi.
• “Chi protegge l’hardware dei data center?” → AWS (security of the cloud): l’infrastruttura fisica è sempre responsabilità di AWS, mai del cliente.
• Dare permessi a un’app su EC2 → usa un IAM role, non le access key: incorporare chiavi statiche nel codice è la risposta sbagliata; il role fornisce credenziali temporanee.
• Proteggere l’account al massimo livello → abilita MFA sul root user: è la misura prioritaria; il root non si usa per il lavoro quotidiano.
• Serve un solo permesso in più → concedi solo quello (least privilege): assegnare accesso Administrator o una policy con “*” è la trappola classica.
• Gestire i permessi di molti utenti allo stesso modo → assegnali a un IAM group: modificare i permessi user per user è la scelta sbagliata e non scala.