Che cos'è l'IAM (gestione delle identità e degli accessi)?

L’IAM è un framework di policy e tecnologie che garantisce agli utenti giusti il giusto accesso alle risorse giuste al momento giusto. L’Identity & Access Management è la disciplina che sta dietro a ogni casella di login e a ogni controllo dei permessi – con una disambiguazione da fare subito: i grandi provider cloud distribuiscono anche prodotti chiamati “IAM” per controllare l’accesso alla propria infrastruttura; quelli sono implementazioni di questa disciplina, non la sua definizione. Questo articolo copre la disciplina – compresa la versione che chi sviluppa app costruisce o eredita, di solito senza chiamarla IAM.

Punti chiave

Il ciclo di vita dell’identità: ingresso, mobilità, uscita

Il lavoro quotidiano dell’IAM è un giro che ogni account compie, e si traduce in operazioni concrete:

INGRESSO creare l'identità → verificare l'e-mail → emettere credenziali/sessione
         (provisioning – automatizzato via SCIM nei sistemi workforce)
MOBILITÀ cambi di ruolo · cambi di team · concessioni e revoche di permessi
         (l'autorizzazione segue i ruoli: una mobilità è un aggiornamento di dati)
USCITA   revocare le sessioni SUBITO → disabilitare l'account → cancellare o anonimizzare
         (deprovisioning – i passaggi saltati diventano "account orfani",
          il rilievo di audit che continua a comparire nei report sulle violazioni)

Lo stesso giro sotto forma di chiamate API:

// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: '[email protected]' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "[email protected]"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "[email protected]"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

Autenticazione vs. autorizzazione

La distinzione su cui poggia tutta la disciplina:

Versione aeroportuale, una volta sola: il controllo passaporti contro la carta d’imbarco. Poi la versione ingegneristica, che conta di più: l’autenticazione produce l’identità che una sessione porta con sé; l’autorizzazione la consuma a ogni richiesta successiva – ed è per questo che le due falliscono in modo diverso e si irrigidiscono separatamente.

I quattro pilastri – e le tre lettere del mercato

L’anatomia funzionale: autenticazione (dimostrare l’identità – password, MFA, SSO, autenticazione senza password), autorizzazione (decidere le azioni – ruoli, permessi, regole sugli oggetti), ciclo di vita (il giro ingresso/mobilità/uscita) e audit (il quarto, cronicamente sottovalutato: log, revisioni degli accessi e la capacità di rispondere a “chi poteva leggere questo, e chi l’ha letto?”). Il mercato dei vendor taglia lo stesso territorio in segmenti che si incontrano in fase di acquisto: AM (access management – accesso, SSO, MFA), IGA (governance – certificazioni, separazione dei compiti, il livello del “dovrebbero averlo?” sopra l’operativo “possono averlo?”) e PAM (accessi privilegiati – vaulting ed elevazione just-in-time per gli account la cui compromissione significa fine della partita). Stessa disciplina, due mappe.

Lo stack degli standard

La zuppa di acronimi, risolta in mansioni – la tabella che le pagine in classifica non forniscono mai:

IAM workforce vs. CIAM

La distinzione si guadagna la tabella perché i contenuti in classifica sono scritti quasi tutti sulla colonna di sinistra, mentre la maggior parte di chi sviluppa e legge un glossario sta costruendo quella di destra: flussi di registrazione, gestione delle sessioni e recupero dell’account per gli utenti di un’app sono CIAM – la disciplina si applica anche quando nessuno nella stanza usa l’acronimo.

Casi d’uso tipici

• Gestione degli utenti di un’app – registrazione, verifica, sessioni, ruoli, cancellazione: CIAM come lavoro quotidiano di backend.
• SSO aziendale – un solo IdP, molte app; MFA e offboarding imposti in un unico punto.
• Identità di API e servizi – credenziali macchina, token con ambito e rotazione per i chiamanti non umani.
• Programmi di conformità – revisioni degli accessi, tracce di audit e prove del privilegio minimo per GDPR, HIPAA, SOC 2.
• Architetture zero trust – controlli di identità a ogni richiesta al posto della posizione di rete come segnale di fiducia.

Costruire o comprare l’IAM? Matrice decisionale

Limiti e trade-off

• L’IAM è un processo travestito da software. Gli strumenti automatizzano la policy, non possono inventarla – progettazione dei ruoli, cadenza delle revisioni e disciplina di offboarding restano lavoro umano.
• La centralizzazione concentra il rischio. Un solo IdP significa un solo posto da proteggere e un solo disservizio che butta fuori tutti; con la comodità arrivano la pianificazione della disponibilità e del ripristino.
• La federazione eredita la fiducia. Ogni app che si fida di un IdP eredita le sue compromissioni; validazione dei token e durate brevi sono il contenimento.
• L’automazione del ciclo di vita ha bisogno della verità. Il provisioning vale quanto la fonte di riferimento che lo alimenta; dati HR obsoleti diventano accessi obsoleti.
• Audit senza revisione è teatro. Log che nessuno legge e certificazioni su cui nessuno agisce soddisfano le checklist, non gli attaccanti.

IAM su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’IAM visto con gli occhi di chi sviluppa è esattamente ciò che la piattaforma consegna: la classe User è l’identity store; registrazione, verifica dell’e-mail, reimpostazione della password e login social coprono l’autenticazione (con un adapter MFA per lo step-up); i session token revocabili portano l’identità; i ruoli e le ACL per singolo oggetto sono il pilastro dell’autorizzazione, applicato a ogni richiesta REST, GraphQL e Live Query; e il ciclo di vita delle schede di codice – ingresso, mobilità, uscita – è ordinario lavoro sui dati, con i trigger di Cloud Code come luogo in cui imporre la policy (bloccare le e-mail usa e getta, registrare eventi di audit, propagare il deprovisioning). È CIAM come livello di piattaforma: i pilastri arrivano assemblati, e il lavoro si sposta dal costruire macchinari per l’identità al decidere la policy.