AWS IAM spiegato: utenti, ruoli e principio del minimo privilegio

Quando si parla di sicurezza nel cloud, la prima domanda che ogni azienda dovrebbe porsi non riguarda firewall o crittografia: riguarda gli accessi. Chi può accedere a cosa? In AWS, la risposta passa da un unico servizio che governa tutto: IAM, Identity and Access Management.

IAM è il servizio che permette di decidere con precisione chi (utenti, gruppi, ruoli) può fare cosa (azioni sui servizi AWS) su quali risorse (bucket S3, istanze EC2, database, reti), e a quali condizioni. Non è un optional: è il punto di partenza di qualsiasi strategia di sicurezza su AWS, ed è uno degli argomenti centrali delle certificazioni AWS, dalla Foundational alla Security Specialty.

In questa guida vediamo come funziona IAM nella pratica: identità, policy e il principio del minimo privilegio, la regola che sta alla base di ogni configurazione degli accessi ben fatta.

Che cos'è AWS IAM

IAM gestisce le identità e i permessi all'interno di un account AWS. Ogni chiamata alle API di AWS viene verificata da IAM prima di essere eseguita: se chi la invia non ha il permesso di compiere quell'azione su quella risorsa, la richiesta viene negata. Questo vale per ogni servizio, da EC2 a S3, da Lambda a CloudFront.

Ci sono due famiglie di componenti da conoscere:

• le identità, ovvero chi chiede di compiere un'azione (utenti, gruppi, ruoli, identità federate);
• le policy, ovvero i documenti che stabiliscono quali permessi vengono concessi e a quali condizioni.

Vediamole in ordine.

Le identità: utenti, gruppi e ruoli

Utenti IAM

Un utente IAM rappresenta tipicamente una persona, ma può rappresentare anche un'applicazione o un servizio che deve autenticarsi in modo permanente. A ogni utente possono essere associate due tipi di credenziali:

• una password per l'accesso alla console AWS;
• una o più chiavi di accesso (access key ID e secret access key) per chiamare le API o usare la CLI.

Le chiavi di accesso sono credenziali di lunga durata: per questo la raccomandazione ufficiale AWS è di usarle solo dove strettamente necessario, di ruotarle periodicamente e di non incorporarle mai nel codice o nei repository. Per il codice in esecuzione esistono alternative migliori, come vediamo tra poco.

Regola pratica: un utente per ogni persona, mai condividere un account.

Gruppi

I gruppi sono contenitori di utenti che condividono gli stessi permessi. Invece di associare una policy a ogni singolo utente, la si associa al gruppo: chi entra nel gruppo eredita i permessi, chi esce li perde. Questo semplifica la gestione quando i ruoli aziendali cambiano: un nuovo collega entra nel gruppo "sviluppatori" e ha subito i permessi giusti, senza che qualcuno debba configurarli a mano.

Ruoli e credenziali temporanee

Un ruolo IAM non è associato a una persona specifica: è un'identità che può essere assunta, per un tempo limitato, da entità fidate. Le entità possono essere utenti dell'account, servizi AWS, oppure identità provenienti da altre organizzazioni o da provider di identità esterni (federazione).

Quando si assume un ruolo, AWS rilascia credenziali temporanee attraverso il servizio AWS STS (Security Token Service). Queste credenziali hanno una durata limitata e vengono generate al momento: rappresentano un rischio molto minore rispetto alle chiavi di lunga durata.

L'esempio classico è un'istanza EC2 che deve leggere oggetti da un bucket S3. Invece di copiare una chiave di accesso dentro l'istanza (e dentro ogni sua immagine o snapshot), si crea un ruolo con i permessi necessari e lo si associa all'istanza tramite un instance profile. È AWS stesso a fornire e rinnovare automaticamente le credenziali temporanee: nessun segreto da gestire, nessun rischio che finisca in un repository.

Questo modello funziona anche per le applicazioni containerizzate su ECS o EKS (tramite IRSA, IAM Roles for Service Accounts), per le funzioni Lambda e per le pipeline CI/CD. Il principio è sempre lo stesso: delegare l'autenticazione al servizio, mai gestire chiavi a mano.

Le policy: il linguaggio dei permessi

Le policy sono documenti JSON che definiscono i permessi. Una policy è composta da uno o più statement, ciascuno con quattro elementi fondamentali:

• Effect: Allow o Deny. Un Deny esplicito ha sempre la precedenza su qualsiasi Allow;
• Action: le operazioni consentite o negate (per esempio s3:GetObject o ec2:RunInstances);
• Resource: le risorse su cui l'azione vale (per esempio un ARN specifico o un'intera struttura);
• Condition (opzionale): le condizioni che devono essere vere perché il permesso valga, come l'IP di origine, la regione o la presenza di una sessione con MFA.

Esistono due grandi categorie di policy:

• le identity-based policy, allegate a un'identità (utente, gruppo o ruolo): stabiliscono cosa quell'identità può fare;
• le resource-based policy, allegate alla risorsa stessa (come le bucket policy di S3): stabiliscono chi può accedere a quella risorsa.

A questi livelli si aggiungono, in un contesto multi-account, gli SCP (Service Control Policies) di AWS Organizations, che pongono un limite ai permessi massimi consentiti in tutti gli account dell'organizzazione, e i permissions boundary, che definiscono il limite massimo di permessi che un'identità può ricevere. Nessun permesso può superare questi confini, qualunque policy venga allegata.

Un aspetto da capire bene: i permessi funzionano per unione, non per somma. Se una policy consente l'accesso a una risorsa e un'altra lo nega, vince il Deny. Per questo le policy andrebbero scritte in modo semplice e leggibile: meno statement, meno sorprese.

Il principio del minimo privilegio

Il principio del minimo privilegio è la regola d'oro della gestione degli accessi: concedere a ogni identità soltanto i permessi necessari per svolgere il proprio lavoro, e niente di più.

Perché è così importante? Ogni permesso in più è una superficie d'attacco in più. Se un utente ha accesso a tutto l'account e le sue credenziali vengono compromesse, l'attaccante ha le chiavi di tutto. Se invece l'utente può solo leggere un bucket specifico, il danno resta contenuto a quel bucket. In un panorama in cui le minacce passano spesso da credenziali rubate o da utenti che accumulano privilegi nel tempo, ridurre i permessi è la difesa più efficace ed economica.

Applicarlo in AWS significa, in pratica:

1. Partire da zero: non allegare policy come AdministratorAccess o il supporto completo a un servizio senza un motivo concreto. Iniziare dal minimo e aggiungere solo quando serve.
2. Misurare l'uso reale: la console IAM mostra per ogni utente e ruolo le informazioni sulle ultime attività di accesso (last accessed). Chi non usa certi permessi non dovrebbe averli.
3. Generare policy dall'uso: IAM Access Analyzer può analizzare l'attività di un'identità e generare automaticamente una policy con solo i permessi effettivamente utilizzati. È uno strumento prezioso per ripulire configurazioni storiche.
4. Validare le policy: sempre Access Analyzer verifica che le policy siano valide e segnala quelle eccessivamente permissive (per esempio "*" in Action o Resource), aiutando a correggerle prima che diventino un problema.
5. Controllare l'accesso esterno: Access Analyzer individua le policy che consentono l'accesso a principi esterni all'account, un controllo fondamentale per S3, KMS e gli altri servizi con resource-based policy.
6. Usare le condizioni: per restringere i permessi anche nel tempo e nello spazio — richiedendo MFA, limitando la regione o vincolando le azioni a una specifica sottorete.

Il minimo privilegio non è un'attività una tantum: è un processo continuo. I permessi tendono ad accumularsi con il passare dei progetti; revisioni periodiche delle policy sono parte del lavoro di chi governa l'accesso.

Buone pratiche operative su IAM

Chiudiamo con le raccomandazioni che AWS indica come base di partenza per qualunque account, anche il più piccolo:

• Proteggi l'utente root: l'account root è quello creato per primo, con accesso totale e irrevocabile. Va usato solo per le poche operazioni di gestione dell'account che richiedono proprio il root, e va protetto con MFA, password complessa e credenziali mai condivise.
• Abilita sempre l'MFA: l'autenticazione a più fattori è la protezione singola più efficace contro il furto delle credenziali. Conviene richiederla con una condizione di policy (aws:MultiFactorAuthPresent) per le operazioni sensibili.
• Usa i ruoli per le applicazioni: mai chiavi di accesso incorporate nel codice o nelle configurazioni; per i carichi di lavoro su EC2, ECS, EKS e Lambda usare sempre ruoli.
• Ruota le credenziali: le chiavi di accesso di lunga durata vanno ruotate con regolarità; gli strumenti di IAM Access Analyzer aiutano a individuare quelle inutilizzate.
• Monitora l'attività: AWS CloudTrail registra tutte le chiamate API, incluse quelle che usano le credenziali; abilitarlo è il prerequisito per qualunque indagine di sicurezza.
• Centralizza l'accesso multi-account: con AWS Organizations si possono imporre confini di permesso comuni tramite SCP, e usare AWS IAM Identity Center (il successore di AWS SSO) per un accesso centralizzato con Single Sign-On e identità federate.

Seguire queste pratiche non garantisce la sicurezza da solo, ma è il prerequisito senza il quale nessun altro controllo — firewall, VPC, cifratura — ha senso: se un utente compromesso può fare qualsiasi cosa, tutti gli altri controlli diventano un'illusione.

Perché approfondire IAM in un percorso di formazione

IAM è il fondamento di ogni ruolo AWS. Lo si incontra già nei corsi introduttivi di architettura, e diventa centrale nei percorsi di security: è uno degli ambiti più pesanti della certificazione AWS Certified Security – Specialty, dove si lavora proprio su policy, federazione, analisi degli accessi e minimo privilegio.

Comprenderlo significa imparare a ragionare in modo strutturato su accessi e dati, un'abilità che le aziende cercano sempre di più — anche in vista di adempimenti come la direttiva NIS2, che spinge le organizzazioni a rafforzare proprio il controllo degli accessi.

Se vuoi costruire queste competenze con un percorso pratico e guidato, i corsi AWS di Digital Lab ti accompagnano dalla base alla specializzazione, con laboratori reali su console e servizi. Scopri il calendario nella pagina dei corsi AWS: /corsi-aws.