IAM spiegato con il badge aziendale (la vera base di AWS)

Access Denied.

Se hai mai aperto la console AWS più di tre volte, lo hai visto. Magari stavi cercando di leggere un oggetto su un bucket S3. Magari stavi avviando una Lambda che doveva scrivere su DynamoDB. O semplicemente stavi tentando di creare la tua prima istanza EC2.

Hai ricontrollato il bucket. Hai riguardato la Lambda. Hai googlato. Hai bestemmiato in dialetto. E alla fine, dopo mezz’ora, hai scoperto che la risposta era IAM.

Spoiler: la risposta è quasi sempre IAM.

E qui sta la trappola in cui cade quasi chiunque studi AWS da zero. IAM viene visto come “la noiosa gestione dei permessi”. Un capitolo che si salta volentieri per arrivare ai servizi divertenti, EC2, S3, Lambda. Errore. IAM è la lingua con cui ogni servizio AWS parla con ogni altro servizio. Non capirla significa non capire AWS.

In questo articolo ti spiego IAM con un’analogia che, se la mandi a memoria una volta, ti sblocca metà delle domande di sicurezza al Cloud Practitioner e al Solutions Architect. L’analogia del badge aziendale.

User, group, role: tre cose, non una

Prima cosa da chiarire. IAM non è un solo concetto, è un intero edificio. E al primo piano ci sono tre porte che vanno aperte con la testa giusta.

IAM User. È una persona o un servizio con un’identità permanente. Ha un nome, può avere una password per accedere alla console, può avere chiavi API per accedere da codice. Se dovessi dare un badge a un dipendente nuovo, gli daresti un IAM User: nome stampato sopra, foto, valido finché lavora in azienda.

IAM Group. È un contenitore di user. Non un’identità in sé, non puoi loggarti come gruppo, non puoi assegnargli credenziali. Un group serve solo per organizzare gli user e dargli permessi in blocco. Se assumi 10 sviluppatori e tutti devono leggere lo stesso bucket, non scrivi 10 policy: crei un group “Developers”, ci attacchi una policy, e ci metti dentro i 10 user. Quando ne aggiungi un undicesimo, lo butti nel group e ha già tutto.

IAM Role. Qui è dove la maggior parte si perde. Un role è un’identità temporanea che chiunque autorizzato può “indossare” per un certo tempo. Non ha credenziali permanenti. Non ha una password. Non viene “creato per qualcuno”: viene creato come ruolo a sé stante, e poi assegnato a chi lo richiede al momento giusto.

Pensa al pass visitatore alla reception. Non ha il tuo nome stampato. È nel cassetto. Quando arriva qualcuno autorizzato, un consulente esterno, una Lambda che ha bisogno di accedere a S3, un altro account AWS, la reception (IAM) glielo consegna. Lui lo usa per qualche ora, e quando esce lo restituisce.

L’esempio più frequente d’esame è la Lambda che deve leggere da DynamoDB. La Lambda non ha credenziali sue. Le viene assegnato un role al momento del deploy, e quando deve agire AWS le presta temporaneamente le chiavi di quel role. Stessa logica per ogni servizio AWS che parla con un altro servizio AWS.

User = badge personale permanente. Group = sacco di badge personali con la stessa policy. Role = pass visitatore impersonale, riutilizzabile, temporaneo.

Le policy sono le regole del badge

Avere un badge non significa entrare ovunque. Il badge in sé è solo un pezzo di plastica. Quello che decide cosa puoi fare è la policy attaccata a quel badge.

Una policy IAM è un documento JSON che dice quattro cose: cosa è permesso (o vietato), su quali azioni, su quali risorse, in quali condizioni. Ridotta all’osso, una policy ha questa forma:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::mie-fatture/*",
  "Condition": {
    "IpAddress": { "aws:SourceIp": "192.0.2.0/24" }
  }
}

Tradotta in italiano: “Consenti di leggere oggetti dal bucket mie-fatture, ma solo se la richiesta arriva da quella sottorete.” Una regola del badge, scritta in JSON.

Le policy si attaccano in due modi:

Identity-based: attaccate a un user, un group o un role. Dicono “questa identità può fare X”.
Resource-based: attaccate direttamente a una risorsa (un bucket S3, una key KMS). Dicono “questa risorsa accetta accessi da Y”.

Una bucket policy su S3, ad esempio, è una resource-based policy. La policy che permette al tuo IAM user di leggere quel bucket potrebbe stare su entrambi i lati: o sul tuo user, o sul bucket. Spesso vivono insieme, e per un junior questa cosa è disorientante.

E la logica di valutazione? Tre regole, in quest’ordine:

Per default, AWS nega tutto.
Un Allow esplicito sblocca un’azione.
Un Deny esplicito vince sempre, anche se c’è un Allow da un’altra parte.

Il deny esplicito è il martello: bloca tutto, anche le permissioni dell’amministratore. È il motivo per cui le policy di “guardrail” aziendali (chi può fare cosa) si scrivono con i Deny, non con gli Allow.

Domanda d’esame tipica: “L’utente ha una policy che permette s3: ma una resource-based policy nega s3:DeleteObject. Cosa succede?”*. Tradotto nel linguaggio del badge: il portone ti riconosce, ma una porta interna ha un divieto preciso. Il divieto preciso vince. Sempre.

Il principio del minimo privilegio (e perché cambia tutto)

C’è una regola, in IAM, che da sola spiega l’80% delle scelte di sicurezza in AWS. Si chiama principle of least privilege.

Tradotto: dai a ogni identità solo i permessi che le servono per fare il suo mestiere, nulla di più. Né di meno (sennò non funziona), né di più (sennò sei vulnerabile).

L’errore classico del principiante è dare AdministratorAccess “tanto per testare”. Funziona, certo. Ma se quella chiave finisce su GitHub per sbaglio, capita più spesso di quanto immagini, esiste persino una documentazione AWS dedicata al recovery da credenziali esposte, chi le trova ha le chiavi del regno. Non solo del bucket che stavi testando.

Se ci pensi, è la stessa logica del badge fisico. Non daresti il badge “passe-partout” del CEO a uno stagista del marketing. Gli daresti un badge che apre solo le porte che gli servono, in orario d’ufficio, e che si disattiva quando il contratto scade.

In pratica, su AWS questo significa:

Niente lavoro quotidiano sull’utente root. Il root è il proprietario assoluto dell’account. Lo usi una volta per la setup iniziale, attivi la MFA, e poi lo metti nel cassetto. Letteralmente.
MFA su qualunque user con privilegi non banali. Una password rubata smette di essere un problema se chi la ruba non ha anche il tuo telefono.
Role al posto di chiavi statiche, dove possibile. Se una EC2 deve leggere un bucket, non ci attacchi una chiave hardcoded: le assegni un role. Nessuna credenziale che possa leakare, perché non ne esiste una di permanente.
Permessi specifici, non wildcard. s3:GetObject su un bucket preciso è meglio di s3:* su tutto. La pigrizia in IAM si paga.

Il principio del minimo privilegio non è un consiglio “carino”. È quello che, all’esame, distingue un’opzione corretta da una sbagliata in metà delle domande di sicurezza.

Gli errori IAM che fanno bocciare al primo tentativo

Li vedo settimanalmente nei forum, nei messaggi degli studenti, nelle simulazioni d’esame sbagliate. I più frequenti sono cinque.

Confondere user e role. Lo so, l’ho già detto sopra, ma è davvero il primo errore. Se in una domanda d’esame leggi “una Lambda deve accedere a DynamoDB” e l’opzione corretta parla di “creare un IAM user con chiavi”, sbagliata. La risposta è quasi sempre “creare un role e assegnarlo alla Lambda”.
Pensare che il group abbia permessi propri. Il group è un contenitore. Le policy si applicano attraverso il group agli user che ci stanno dentro. Non puoi assegnare un permesso a un group e poi usarlo “come group”, ci sarà sempre un user a fare la richiesta.
Non sapere che IAM è globale. Ogni servizio AWS ha una regione. IAM no. Gli user, i role, le policy che crei sono validi in tutto l’account, ovunque. Domanda d’esame tipica: “In quale regione si crea l’utente IAM?”. Trabocchetto. Risposta: in nessuna, è globale.
Non capire che il role si “assume”. Quando un servizio o un utente vuole usare un role, esegue un’operazione chiamata sts:AssumeRole. AWS gli risponde con credenziali temporanee. È quello il meccanismo dietro le quinte di ogni “Lambda accede a S3” e di ogni accesso cross-account. Senza capire AssumeRole, intere domande del SAA diventano oscure.
Sottovalutare il Deny esplicito. Quando vedi un’opzione di policy con "Effect": "Deny", sappi che vince contro qualunque Allow. Non è “una restrizione tra le tante”, è il martello finale.

Bonus, sempre dalla mia esperienza con gli studenti: leggere le policy in JSON spaventa, ma è una skill che si costruisce in poche ore. Apri la console, vai in IAM, clicca su una policy AWS-managed (tipo AmazonS3ReadOnlyAccess) e leggila riga per riga chiedendoti “cosa permette questa singola riga?”. È il modo più veloce per costruire l’intuizione.

Domande frequenti su AWS IAM

IAM è gratis? Sì. IAM in sé non costa nulla, non paghi per gli user, i role, le policy, gli accessi. Paghi solo i servizi che gli user e i role consumano (S3, EC2 e così via). È uno dei pochi servizi AWS a costo zero.

IAM è regionale o globale? Globale. User, role, group, policy sono validi su tutto l’account, in qualunque regione. Anche se la console mostra una regione in alto a destra mentre sei in IAM, è un’illusione visiva.

Posso usare lo stesso utente IAM su più account? No. Gli user sono legati a un singolo account. Per accedere a più account dallo stesso login esistono due strade: i cross-account role (assumi un role nell’altro account) o IAM Identity Center (ex AWS SSO), che è la soluzione consigliata per organizzazioni multi-account.

Cosa devo fare se sospetto che le credenziali siano state compromesse? Tre azioni, nell’ordine: disattiva la chiave compromessa, ruota tutte le credenziali del user, controlla CloudTrail per capire cosa è stato fatto con quella chiave. AWS pubblica una guida ufficiale al recovery, vale la pena tenerla nei segnalibri.

Esiste un audit log delle azioni IAM? Sì. Ogni chiamata API verso AWS, incluso ogni accesso e ogni modifica IAM, è tracciata da CloudTrail, che è attivo di default sui nuovi account. È il primo posto dove guardi se vuoi capire chi ha fatto cosa, quando, e da dove.

Come si attiva la MFA? Dalla console IAM, sezione Security credentials dell’utente. Puoi usare un’app di authenticator (Google Authenticator, Authy, 1Password) o una chiave fisica tipo YubiKey. AWS supporta più dispositivi MFA per lo stesso user, comodo se perdi il telefono.

Posso integrare IAM con Active Directory o Google Workspace? Sì, tramite IAM Identity Center con federazione SAML o OIDC. Gli utenti continuano a loggarsi con le credenziali aziendali e ottengono accessi su AWS senza creare un IAM user dedicato. È l’approccio standard nelle aziende serie.

Se sei arrivato in fondo, hai già davanti la differenza tra chi studia AWS davvero e chi salta i capitoli “noiosi”. IAM non è un dettaglio amministrativo. È la lingua con cui ogni cosa, su AWS, parla con ogni altra cosa.

E IAM è anche il dominio più pesato del Cloud Practitioner, Security e Compliance vale il 30% dell’esame, e gran parte di quelle domande gira proprio attorno a questi concetti.

Se vuoi un punto di partenza gratuito per cominciare a prepararti, con una sezione dedicata a IAM tra le prime, scarica il Cloud Practitioner Starter Kit. È pensato per chi parte da zero e vuole una mappa ordinata.

Se invece sei più avanti e vuoi un percorso completo verso l’esame, il corso AWS Cloud Practitioner CLF-C02 in italiano tratta IAM con la stessa logica di questo articolo: l’analogia, le quattro componenti, le policy lette in JSON, e le 15-20 trappole più frequenti dell’esame, simulazioni incluse.

E quando affronti una simulazione, tieni a mente una cosa sola. La prossima volta che leggi la parola “permesso”, “accesso”, “non riesce a chiamare”, “credenziali”, chiediti: “come funziona il badge?”. Sette volte su dieci, lì c’è la risposta.

AWS lo fa fare a IAM. Come sempre.

Ti è stata utile questa guida? Condividila con un collega.