IAM on My personal blog

L'identità dei workload

Tue, 14 Jul 2026 09:00:00 +0200

Perché conta

Un’applicazione nel cloud deve spesso leggere un database, scrivere su uno storage, chiamare un’altra API. Per farlo le serve un’identità. La via sbagliata — e purtroppo comunissima — è creare un utente IAM, generare una chiave statica (access key / service account key) e incollarla in un file di configurazione o in una variabile d’ambiente. Quella chiave non scade mai, finisce nei log, nei repository Git, nei backup, nelle immagini dei container: è la causa numero uno di credenziali cloud rubate. Le identità di workload esistono per non doverla mai creare.

Il meccanismo: la macchina È l’identità

  flowchart LR
    APP[Applicazione<br/>su una VM / container] -->|"chiede credenziali"| MD[Metadata service<br/>locale della piattaforma]
    MD -->|"credenziali temporanee<br/>a scadenza"| APP
    APP -->|"usa le credenziali"| API[API del cloud]
    ROLE[Ruolo assegnato<br/>alla macchina] -.definisce i permessi.-> MD
    style ROLE fill:#fde2e4,stroke:#e63946

Invece di dare una chiave all’applicazione, si assegna un ruolo alla macchina che la ospita (una istanza, un container, una funzione). La piattaforma espone un metadata service locale da cui l’applicazione ottiene, a richiesta, credenziali temporanee che scadono dopo minuti o ore e vengono rinnovate in automatico. Nessun segreto a lunga vita esiste mai: se la macchina viene spenta, le credenziali muoiono con lei.

I nomi nei tre provider

1
2
3

AWS   → IAM Role su EC2/ECS/Lambda (via Instance Metadata Service, usa IMDSv2!)
GCP   → service account allegato alla risorsa + metadata server
Azure → Managed Identity (system- o user-assigned)

Il concetto è identico: un’identità legata alla risorsa, credenziali effimere servite localmente. Su AWS è importante forzare IMDSv2 (la versione del metadata service che richiede un token), perché la v1 è stata sfruttata in attacchi SSRF per rubare credenziali dalle istanze.

Oltre il cloud: la federazione

E se il workload gira fuori dal cloud — in una pipeline CI/CD su GitHub, in un cluster on-premise? Qui entra la federazione (workload identity federation): il sistema esterno presenta un token firmato OIDC che attesta la sua identità (“sono la pipeline X del repo Y”), e il cloud lo scambia con credenziali temporanee, senza che nessuna chiave statica cambi mai di mano. È il modo moderno di far parlare CI, Kubernetes esterni e altri cloud con il tuo ambiente, in sicurezza.

Domanda: una chiave statica in un file è semplicissima e funziona ovunque. Ruoli, metadata service, federazione OIDC: non sto aggiungendo pezzi fragili per risolvere un problema che una buona gestione dei segreti già coprirebbe?

No, e la distinzione è importante: la gestione dei segreti (che vedremo nel prossimo capitolo) riduce il rischio di una chiave, ma l'identità di workload lo elimina alla radice — sono complementari, non alternative. Una chiave statica, per quanto ben custodita in un vault, ha tre proprietà che nessuna gestione può togliere: esiste, quindi può essere letta; non scade, quindi se trapela resta valida finché qualcuno non se ne accorge e la revoca manualmente; e deve viaggiare dal vault all'applicazione, moltiplicando i punti in cui può trapelare (log, dump di memoria, variabili d'ambiente ispezionabili, immagini di container). L'identità di workload rende la chiave statica inesistente: l'applicazione non possiede mai un segreto a lunga vita, ottiene credenziali che scadono in minuti e si rinnovano da sole. Se un attaccante le ruba, ha una finestra brevissima, non un accesso permanente; e la revoca è automatica allo spegnimento della macchina. Sui "pezzi fragili": il metadata service e la federazione OIDC non li costruisci tu, li fornisce la piattaforma, già irrobustiti — l'unica tua accortezza è usare la variante sicura (IMDSv2) e configurare bene le condizioni della federazione. In cambio elimini l'intera categoria di incidenti "chiave statica trovata nel repo Git", che è tra le più frequenti in assoluto. La chiave in un file è semplice come lasciare la porta aperta è semplice: la complessità che eviti oggi la paghi come breach domani.

Conclusione

Le identità di workload eliminano le chiavi statiche: la macchina riceve un ruolo, ottiene credenziali temporanee da un metadata service locale, e all’esterno la federazione OIDC scambia token firmati con credenziali effimere. Nessun segreto a lunga vita da custodire. Ma qualche segreto — password di database, chiavi di terze parti, certificati — resterà sempre inevitabile: come conservarlo è il tema della gestione dei segreti e KMS, prossimo capitolo.

Il principio del privilegio minimo

Tue, 07 Jul 2026 09:00:00 +0200

Perché conta

L’IAM ti dà il potere di concedere permessi con precisione chirurgica. Il privilegio minimo è la disciplina di usarlo bene: dare a ogni identità solo i permessi che le servono per il suo compito, e nulla di più. Non è un vezzo da puristi: è ciò che trasforma una credenziale rubata da catastrofe a incidente contenuto. Se un’applicazione compromessa può leggere un solo bucket, il danno finisce lì; se poteva fare * su tutto, hai perso l’intero account.

Il raggio d’esplosione

  flowchart TD
    C[Credenziale compromessa] --> Q{Quali permessi<br/>aveva?}
    Q -->|"Admin / wildcard *"| B[Raggio enorme:<br/>tutto l'account a rischio]
    Q -->|"Solo lo stretto necessario"| S[Raggio minimo:<br/>danno contenuto a una risorsa]
    style B fill:#fde2e4,stroke:#e63946
    style S fill:#d8f3dc,stroke:#2d6a4f

La domanda che conta dopo ogni compromissione è “cosa poteva fare questa identità?”. Il privilegio minimo è ciò che rende la risposta accettabile. Si chiama raggio d’esplosione (blast radius): ogni permesso in più lo allarga.

I tre antipattern da evitare

1
2
3

"Action": "*"             → può fare QUALSIASI cosa su quel servizio
"Resource": "*"           → su QUALSIASI risorsa, non solo le sue
ruolo admin "per comodità" → assegnato a un'app che ne usa il 2%

I wildcard sono comodi mentre sviluppi e letali in produzione. Il pattern giusto è l’opposto: partire da zero permessi e aggiungere solo ciò che fallisce — far girare l’applicazione, guardare quali chiamate API vengono negate, concedere esattamente quelle. Gli strumenti di analisi degli accessi dei provider (access analyzer, policy advisor) aiutano a scoprire i permessi concessi ma mai usati, da rimuovere.

Temporaneo batte permanente

Il privilegio minimo ha anche una dimensione temporale. Permessi elevati che servono di rado (un deploy, un’operazione d’emergenza) non vanno lasciati sempre attivi: meglio concederli just-in-time, a scadenza, con un ruolo assumibile solo quando serve e con tracciamento. Un permesso che esiste solo per i dieci minuti in cui serve non può essere abusato il resto del tempo.

Domanda: partire da zero e aggiungere ogni permesso che fallisce è lentissimo e frustrante. In un team che deve consegnare, non è più pragmatico dare permessi larghi e stringere "dopo"?

È la trappola più comune e più costosa del cloud, perché quel "dopo" non arriva quasi mai — e lo sanno bene anche gli attaccanti. Dare permessi larghi "per ora" crea tre problemi che si saldano. Primo, il dopo non viene: una volta che l'app funziona con permessi larghi, nessuno torna a stringerli, perché restringere rischia di rompere qualcosa in produzione e non dà alcun beneficio visibile — è lavoro invisibile che si fa solo dopo un incidente. Secondo, i permessi larghi diventano invisibili: con decine di ruoli e wildcard sparsi, nessuno sa più chi può fare cosa, e quando audit o incidente arrivano, scopri che mezza organizzazione aveva accesso admin "temporaneo" da due anni. Terzo, l'abitudine si propaga: il ruolo largo copiato una volta viene riusato, e la larghezza diventa lo standard di fatto. Il punto pragmatico vero è che partire stretti costa meno nel tempo, non di più: oggi gli strumenti generano la policy minima dai log di utilizzo quasi automaticamente, parti da una policy di sviluppo permissiva in ambiente di test, registri cosa usa davvero, e promuovi in produzione la versione stretta già pronta. Così la velocità in sviluppo resta, ma ciò che va in produzione è già minimo. La scorciatoia "largo ora, stretto dopo" non è pragmatismo: è debito di sicurezza che si paga tutto insieme, con gli interessi, il giorno del breach.

Conclusione

Il privilegio minimo contiene il raggio d’esplosione di ogni credenziale compromessa: niente wildcard, si parte da zero e si allarga solo sul necessario, si preferisce il temporaneo al permanente. Ma c’è un’intera classe di identità che spesso riceve permessi troppo larghi e credenziali troppo durature: le applicazioni e i server. Come darglieli in modo sicuro è il tema dell’identità dei workload, prossimo capitolo.

IAM: identità e accessi

Tue, 30 Jun 2026 09:00:00 +0200

Perché conta

Nella rete tradizionale, se eri “dentro” il perimetro eri in gran parte fidato. Nel cloud quel perimetro non esiste: ogni risorsa è un endpoint API raggiungibile da Internet, e l’unica cosa che separa un attaccante dai tuoi dati è chi può chiamare quell’API. Per questo si dice che nel cloud l’identità è il nuovo perimetro. L’IAM (Identity and Access Management) è il sistema che decide, a ogni singola richiesta, se concederla o negarla.

I quattro concetti base

  flowchart LR
    PR["PRINCIPAL<br/>chi fa la richiesta<br/>(utente, ruolo, servizio)"] -->|chiede| AC["AZIONE<br/>cosa vuole fare<br/>(es. leggi oggetto)"]
    AC -->|su| RS["RISORSA<br/>su cosa<br/>(es. questo bucket)"]
    POL["POLICY<br/>le regole"] -.valuta.-> DEC{Consenti<br/>o nega?}
    PR --> DEC
    AC --> DEC
    RS --> DEC
    style POL fill:#fde2e4,stroke:#e63946

Ogni richiesta è la tripla principal → azione → risorsa, e le policy sono le regole che la valutano. Una policy è, in sostanza, un elenco di “questo principal può (o non può) fare queste azioni su queste risorse, a queste condizioni”.

Utenti, gruppi, ruoli

Utente: un’identità a lungo termine per una persona (o, storicamente, per un’app — da evitare).
Gruppo: un insieme di utenti a cui si assegnano permessi in blocco, per non ripeterli uno a uno.
Ruolo: un’identità assumibile temporaneamente, senza credenziali permanenti. È lo strumento chiave del cloud: una VM, una funzione o un utente “assume” un ruolo e ottiene credenziali a scadenza. I ruoli evitano le chiavi statiche, il punto debole numero uno.

Il modello di valutazione: nega per default

La regola d’oro di quasi tutti gli IAM cloud:

1. Si parte da: TUTTO NEGATO (deny implicito)
2. Un Allow esplicito concede il permesso
3. ...ma un Deny esplicito VINCE sempre su qualunque Allow
4. Risultato: accesso solo se c'è un Allow e NESSUN Deny applicabile

Il deny implicito significa che se nessuna policy concede un’azione, è negata. E un deny esplicito batte qualsiasi allow: utile per mettere guardrail che nessun permesso successivo può aggirare. Su AWS si aggiungono i confini (permission boundaries) e le SCP a livello di organizzazione; su GCP l’ereditarietà lungo la gerarchia; su Azure i ruoli RBAC con scope. I nomi cambiano, la logica “nega-salvo-consenso-esplicito” no.

Domanda: l'IAM con policy, ruoli, condizioni sembra enormemente più complicato di "utente e password con dei permessi". Tutta questa complessità non è ingegneria eccessiva?

Sembra eccessiva solo finché non vedi cosa deve governare: non "un utente che accede a un'app", ma qualunque principal — persona, server, funzione, pipeline, servizio di un altro account — che chiama una qualunque delle migliaia di API del provider su una qualunque delle tue risorse, da ovunque nel mondo. "Utente e password con dei permessi" basta per un'applicazione singola; non basta per un sistema dove il chiamante è spesso una macchina, le risorse sono centinaia, e concedere un permesso di troppo a un'identità sbagliata espone dati a Internet. La complessità dell'IAM non è gratuita: ogni pezzo risolve un problema reale. I ruoli esistono per eliminare le chiavi statiche, che sono la causa principale di credenziali rubate. Le condizioni (da quale IP, con quale MFA, verso quale rete) esistono per restringere un permesso al contesto legittimo. Il deny esplicito e i guardrail d'organizzazione esistono per porre limiti invalicabili che nemmeno un amministratore distratto può allargare. Il privilegio minimo, che vedremo nel prossimo capitolo, ha bisogno di questa granularità per essere esprimibile. La vera scelta non è "IAM semplice o complesso", ma "controllo granulare di chi-può-cosa, oppure permessi grossolani che per comodità finiscono sempre troppo larghi". Nel cloud, dove un permesso troppo largo significa dati esposti, la granularità è il prezzo della sicurezza — e, con buone pratiche (gruppi, ruoli, policy riusabili), si gestisce senza impazzire.

Conclusione

L’IAM è il perimetro del cloud: valuta ogni richiesta come principal-azione-risorsa contro le policy, partendo da tutto negato, con il deny esplicito che vince sempre. Utenti, gruppi e soprattutto ruoli assumibili ne sono i mattoni. Avere questo modello chiaro è la premessa per la regola che rende l’IAM davvero sicuro — concedere il meno possibile: il principio del privilegio minimo, prossimo capitolo.