Executive summary
Ogni organizzazione che gestisce sistemi informativi deve rispondere a una domanda fondamentale: chi può accedere a quali risorse, in quali circostanze e per quanto tempo. Garantire che ogni persona abbia esattamente i permessi necessari, né più, né meno, è diventato uno dei problemi centrali della sicurezza informatica aziendale, con investimenti globali che nel 2023 hanno superato i quindici miliardi di dollari. Questo articolo analizza le tecnologie e i modelli che governano l'intero ciclo di vita delle credenziali di accesso in un'organizzazione, dalla creazione alla revoca, esaminando i punti di forza e le criticità di ciascun approccio. Dall'analisi emerge che le organizzazioni più mature stanno spostando il controllo della sicurezza dalla protezione della rete alla verifica continua dell'identità di chi richiede l'accesso, e che l'automazione di questi processi riduce in modo misurabile gli incidenti causati da accessi non autorizzati.
Background
La disciplina dell'Identity & Access Management (IAM) si occupa dell'insieme di processi, tecnologie e policy che governano la creazione, la gestione e la dismissione delle identità digitali all'interno di un'organizzazione, nonché il controllo degli accessi alle risorse informatiche associate a tali identità. Il problema non è nuovo: i primi sistemi multi-utente degli anni Settanta implementavano già rudimentali meccanismi di autenticazione e autorizzazione. Tuttavia, la complessità contemporanea, ambienti multi-cloud, workforce distribuita, proliferazione di applicazioni SaaS e crescente pressione normativa (GDPR, NIS2, SOX), ha trasformato la gestione delle identità da problema infrastrutturale a priorità strategica di sicurezza [1].
Una systematic review pubblicata su Business & Information Systems Engineering nel 2023 ha identificato quattro categorie di requisiti per i sistemi IAM enterprise: sicurezza e compliance, operabilità, tecnologia e aspetti relativi all'utente finale [2]. Lo studio evidenzia come il 77% delle organizzazioni intenda aumentare il budget destinato alla gestione delle identità per mitigare i rischi di cybersecurity, eppure solo il 38% delle aziende utilizzasse software IAM dedicato al momento della rilevazione, a testimonianza del divario significativo tra consapevolezza del problema e maturità implementativa [2].
Il paradigma contemporaneo dell'IAM si articola attorno a cinque componenti fondamentali che questo articolo analizza in profondità: i servizi di directory e gli identity provider (IdP), i protocolli di federazione e Single Sign-On (SSO), i meccanismi di provisioning automatizzato (SCIM), i modelli formali di controllo degli accessi (RBAC, ABAC), e la gestione degli accessi privilegiati (PAM). La convergenza di questi componenti verso architetture identity-centric, formalizzata dal NIST nel framework Zero Trust Architecture [3], rappresenta il filo conduttore dell'analisi.
Servizi di directory e identity provider
Dall'LDAP ai provider di identità moderni
Il Lightweight Directory Access Protocol (LDAP), standardizzato nella RFC 4511, ha costituito per oltre due decenni il substrato dei servizi di directory enterprise. Un directory LDAP organizza le identità in una struttura gerarchica ad albero (Directory Information Tree), dove ogni entry è identificata da un Distinguished Name (DN) e caratterizzata da un insieme di attributi definiti da uno schema. Microsoft Active Directory (AD), introdotto con Windows 2000, ha esteso LDAP con funzionalità di autenticazione Kerberos, Group Policy e replica multi-master, diventando lo standard de facto per la gestione delle identità in ambienti on-premises [4].
La migrazione verso architetture cloud-native e ibride ha tuttavia evidenziato i limiti strutturali dei directory LDAP tradizionali. La dipendenza da una topologia di rete interna, l'assenza nativa di protocolli di federazione web-based e la complessità della replica cross-datacenter rendono questi sistemi inadeguati come unico punto di gestione delle identità in ambienti distribuiti. Gli identity provider (IdP) moderni, Okta, Microsoft Entra ID (ex Azure AD), Ping Identity, e soluzioni open-source come Keycloak, risolvono questo problema agendo come hub centralizzati di autenticazione, capaci di federare identità provenienti da directory eterogenei e di esporre protocolli standard per l'integrazione con applicazioni SaaS e on-premises [5].
Keycloak e l'ecosistema open-source
Keycloak, progetto open-source accettato nella Cloud Native Computing Foundation (CNCF) al livello Incubating nell'aprile 2023, rappresenta un caso di studio significativo nell'evoluzione degli IdP. L'architettura di Keycloak implementa nativamente OpenID Connect, OAuth 2.0 e SAML 2.0, supporta la federazione con directory LDAP e Active Directory, e offre funzionalità di identity brokering che consentono di delegare l'autenticazione a IdP esterni [5]. Il supporto nativo per il deployment su Kubernetes e la gestione dichiarativa dei realm tramite Custom Resource Definitions (CRD) lo rendono particolarmente adatto a infrastrutture cloud-native, dove la configurazione dell'IdP segue i principi dell'Infrastructure as Code.
Un aspetto architetturale rilevante è la separazione tra il concetto di realm, un dominio isolato di gestione delle identità con proprio spazio di utenti, ruoli e configurazioni, e quello di client, che rappresenta un'applicazione registrata presso l'IdP. Questa separazione consente scenari multi-tenant in cui un singolo deployment di Keycloak serve organizzazioni distinte con politiche di autenticazione indipendenti, senza condivisione di dati identitari tra i tenant.
Protocolli di federazione e Single Sign-On
SAML 2.0: asserzioni XML per la federazione enterprise
Il Security Assertion Markup Language (SAML) 2.0, ratificato come standard OASIS nel marzo 2005, definisce un framework basato su XML per lo scambio di asserzioni di autenticazione e autorizzazione tra domini di sicurezza distinti [6]. Lo standard rappresenta la convergenza di tre specifiche precedenti, SAML 1.1, Liberty Alliance ID-FF 1.2 e Shibboleth 1.3, e resta ampiamente adottato in ambito enterprise, in particolare per l'integrazione con applicazioni legacy e in settori regolamentati.
Il flusso SAML prevede tre entità: il principal (l'utente), il Service Provider (SP, l'applicazione che richiede l'autenticazione) e l'Identity Provider (IdP, il sistema che autentica l'utente ed emette asserzioni). Nel profilo Web Browser SSO, l'SP redirige il browser dell'utente verso l'IdP con una AuthnRequest; l'IdP autentica l'utente e restituisce una Response contenente un'asserzione firmata digitalmente. L'SP valida la firma, estrae gli attributi e stabilisce una sessione locale. La sicurezza del protocollo dipende criticamente dalla corretta validazione delle firme XML: vulnerabilità storiche come XML Signature Wrapping hanno dimostrato che implementazioni carenti possono consentire la forgiatura di asserzioni [7].
OAuth 2.0 e OpenID Connect: autorizzazione e autenticazione per il web moderno
OAuth 2.0, definito nella RFC 6749 [8], è un framework di autorizzazione che consente a un'applicazione di ottenere accesso limitato a risorse protette per conto di un utente, senza che le credenziali dell'utente siano condivise con l'applicazione. Il protocollo introduce il concetto di access token come credenziale a scadenza, emessa da un authorization server dopo il consenso dell'utente, e distingue tra diversi grant type (authorization code, client credentials, device code) adatti a scenari applicativi differenti.
OAuth 2.0 è tuttavia un protocollo di autorizzazione, non di autenticazione: non definisce un meccanismo standard per comunicare l'identità dell'utente al client. OpenID Connect (OIDC) 1.0 colma questa lacuna aggiungendo un identity layer sopra OAuth 2.0 [9]. Il contributo fondamentale di OIDC è l'ID Token, un JSON Web Token (JWT) firmato che contiene claim sull'identità dell'utente autenticato, identificativo univoco (sub), istante di autenticazione (auth_time), livello di assurance (acr), e che il client può validare localmente verificando la firma e i claim temporali.
Analisi comparativa dei protocolli SSO
Una systematic literature review condotta su 88 pubblicazioni nel periodo 2017–2024 ha analizzato il panorama dei protocolli SSO sotto i profili di sicurezza e privacy [7]. I risultati evidenziano che OIDC offre vantaggi significativi in termini di semplicità di implementazione, supporto nativo per applicazioni mobile e SPA (Single Page Application), e interoperabilità con API RESTful. SAML 2.0 mantiene invece una posizione dominante in contesti enterprise dove la compatibilità con sistemi legacy e la maturità degli strumenti di audit sono requisiti prioritari.
Dal punto di vista della sicurezza, entrambi i protocolli presentano superfici di attacco specifiche. Per SAML, le vulnerabilità principali sono legate alla complessità del processing XML (Signature Wrapping, XXE injection). Per OIDC e OAuth 2.0, i rischi si concentrano sulla gestione dei redirect URI (open redirect, authorization code interception), sulla validazione dei token e sugli attacchi di tipo confused deputy in scenari multi-tenant [7]. La mitigazione richiede in entrambi i casi un'implementazione rigorosa delle specifiche: validazione completa delle firme per SAML, uso esclusivo del grant type authorization code con PKCE (Proof Key for Code Exchange) per OIDC nelle applicazioni pubbliche.
sequenceDiagram
participant U as Utente
participant SP as Service Provider
participant IdP as Identity Provider
Note over U,IdP: Flusso OIDC Authorization Code con PKCE
U->>SP: Accesso alla risorsa protetta
SP->>U: Redirect a IdP (code_challenge, scope=openid)
U->>IdP: Autenticazione (credenziali / MFA)
IdP->>U: Redirect a SP (authorization_code)
U->>SP: Callback con authorization_code
SP->>IdP: Token Request (code + code_verifier)
IdP->>SP: ID Token (JWT) + Access Token
SP->>SP: Validazione ID Token (firma, claims)
SP->>U: Sessione autenticata
Provisioning automatizzato e protocollo SCIM
Il problema del provisioning cross-domain
In un'organizzazione enterprise tipica, un singolo dipendente dispone di identità su decine di sistemi: directory aziendale, suite di produttività, piattaforme CRM, strumenti di sviluppo, applicazioni di settore. La creazione, la modifica e la revoca di queste identità in modo manuale genera ritardi operativi, errori di configurazione e, soprattutto, rischi di sicurezza derivanti da account orfani non disattivati dopo la cessazione del rapporto lavorativo. Il provisioning automatizzato affronta questo problema sincronizzando il ciclo di vita delle identità tra l'identity provider centrale e le applicazioni downstream.
SCIM 2.0: architettura e semantica
Il System for Cross-domain Identity Management (SCIM) 2.0, definito nelle RFC 7643 (core schema) e RFC 7644 (protocollo), è uno standard IETF che specifica un'API RESTful per la gestione delle identità tra domini distinti [10]. A differenza di LDAP, che opera come protocollo di query (il consumer interroga il directory per ottenere dati), SCIM implementa un modello di push: l'identity provider invia proattivamente le operazioni di creazione, modifica e cancellazione alle applicazioni target.
Lo schema SCIM definisce due risorse principali, User e Group, con un insieme di attributi core (userName, name, emails, active) ed estensibili tramite il meccanismo di schema extension. Il protocollo espone endpoint RESTful standard:
POST /Users, creazione di un nuovo utentePUT /Users/{id}, sostituzione completa di un utentePATCH /Users/{id}, modifica parziale (ad esempio, disattivazione tramite{"active": false})DELETE /Users/{id}, rimozioneGET /Users?filter=userName eq "mario.rossi", ricerca con filtri
L'adozione di SCIM come protocollo standard di provisioning è particolarmente rilevante nel contesto della gestione del ciclo di vita delle identità (Joiner–Mover–Leaver). Quando un nuovo dipendente viene inserito nel sistema HR (Joiner), un connettore SCIM crea automaticamente le identità sulle applicazioni assegnate al ruolo. Quando il dipendente cambia funzione (Mover), gli attributi vengono aggiornati e i diritti ricalcolati. Alla cessazione (Leaver), una singola operazione di disattivazione sull'IdP si propaga a tutti i sistemi collegati [10, 11].
Limiti e sfide implementative
Nonostante la solidità del design, l'implementazione di SCIM in ambienti reali presenta criticità significative, riconducibili in parte alle sfide di integrazione e interoperabilità che caratterizzano l'intero ecosistema IAM enterprise [2]. La copertura dello schema varia tra i provider: attributi custom, strutture organizzative complesse e relazioni tra identità (ad esempio, gerarchie manageriali o deleghe) richiedono estensioni proprietarie che riducono l'interoperabilità. La gestione degli errori in scenari di provisioning massivo, migliaia di operazioni durante una riorganizzazione aziendale, richiede meccanismi di retry, idempotenza e riconciliazione che il protocollo definisce solo parzialmente. Inoltre, la latenza di propagazione tra l'evento scatenante (modifica nel sistema HR) e l'effettiva applicazione su tutti i sistemi target può raggiungere i minuti, creando finestre temporali in cui i diritti di accesso non riflettono lo stato reale dell'organizzazione.
Modelli di controllo degli accessi
RBAC: il modello a ruoli
Il modello Role-Based Access Control (RBAC), formalizzato da Sandhu et al. nel 1996 [12], introduce il concetto di ruolo come livello di indirezione tra utenti e permessi. Un utente acquisisce un permesso non per assegnazione diretta, ma in virtù dell'appartenenza a un ruolo a cui quel permesso è stato conferito. Il framework RBAC96 definisce quattro modelli di complessità crescente:
- RBAC$_0$ (core): utenti, ruoli, permessi e sessioni, con relazioni many-to-many tra utenti-ruoli e ruoli-permessi.
- RBAC$_1$ (gerarchico): aggiunge gerarchie di ruoli, dove un ruolo senior eredita i permessi dei ruoli subordinati.
- RBAC$_2$ (con vincoli): introduce vincoli statici e dinamici, come la separation of duty (SoD), che impedisce a un singolo utente di detenere combinazioni pericolose di ruoli (ad esempio, chi approva un pagamento non può anche eseguirlo).
- RBAC$_3$: combina gerarchie e vincoli.
Il vantaggio principale di RBAC risiede nella semplificazione amministrativa: in un'organizzazione con migliaia di utenti e centinaia di risorse, il numero di ruoli è tipicamente di ordini di grandezza inferiore al numero di assegnazioni utente-permesso che sarebbero necessarie con un modello a lista di controllo degli accessi (ACL). Lo svantaggio strutturale è la rigidità: RBAC non consente di esprimere politiche che dipendono da attributi contestuali, orario, localizzazione, classificazione del dato, senza una proliferazione di ruoli (role explosion) che vanifica i benefici amministrativi.
ABAC: il modello ad attributi
Il modello Attribute-Based Access Control (ABAC), formalizzato dal NIST nella Special Publication 800-162 [13], generalizza i modelli precedenti definendo le decisioni di accesso come valutazione di policy su attributi associati a quattro categorie: soggetto (chi richiede l'accesso), oggetto (la risorsa), azione (l'operazione richiesta) e ambiente (contesto temporale, localizzazione, livello di rischio). Una policy ABAC esprime regole booleane complesse che possono combinare attributi eterogenei:
$$ \text{permit} \iff (\text{subject.role} = \text{"analyst"}) \land (\text{object.classification} \leq \text{"confidential"}) \land (\text{env.time} \in [09{:}00, 18{:}00]) $$
Il NIST osserva che ACL e RBAC possono essere interpretati come casi speciali di ABAC: le ACL operano sull'attributo "identità", RBAC sull'attributo "ruolo" [13]. ABAC aggiunge la capacità di esprimere policy context-aware senza proliferazione di ruoli, rendendolo particolarmente adatto a scenari in cui le decisioni di accesso dipendono da fattori dinamici. L'architettura di riferimento prevede quattro componenti funzionali: il Policy Enforcement Point (PEP), che intercetta le richieste; il Policy Decision Point (PDP), che valuta le policy; il Policy Information Point (PIP), che fornisce gli attributi necessari alla decisione; e il Policy Administration Point (PAP), dove le policy vengono definite e gestite.
Convergenza RBAC-ABAC negli ambienti enterprise
Nella pratica operativa, la dicotomia tra RBAC e ABAC è meno netta di quanto la letteratura teorica suggerisca. Le implementazioni enterprise mature adottano modelli ibridi in cui RBAC fornisce la struttura organizzativa di base, un insieme stabile di ruoli che riflettono la struttura aziendale, mentre ABAC aggiunge vincoli contestuali che raffinano le decisioni di accesso. Questo approccio, denominato in letteratura RABAC o policy-enhanced RBAC, consente di mantenere la semplicità amministrativa dei ruoli senza sacrificare la flessibilità necessaria per scenari complessi [13]. Le piattaforme IGA (Identity Governance and Administration) di ultima generazione, SailPoint, Saviynt, CyberArk Identity Governance, implementano nativamente questa convergenza, offrendo role mining basato su tecniche di machine learning per derivare ruoli ottimali dai pattern di accesso osservati e policy engine ABAC per i vincoli contestuali.
Privileged Access Management (PAM)
La superficie di rischio degli accessi privilegiati
Gli account privilegiati, amministratori di sistema, account di servizio, credenziali di infrastruttura, rappresentano il vettore di attacco più critico in un'organizzazione. Un singolo account amministrativo compromesso può consentire movimento laterale, esfiltrazione di dati e persistenza nell'infrastruttura per periodi prolungati. Il mercato PAM ha raggiunto un valore di 3,6 miliardi di dollari nel 2024, con un tasso di crescita annuo del 23,3%, a testimonianza della priorità che le organizzazioni attribuiscono a questo segmento [14]. Le istanze di furto di credenziali sono aumentate dell'800% nel 2025, mentre gli attacchi ransomware hanno registrato un incremento del 179%, consolidando la gestione degli accessi privilegiati come componente imprescindibile di qualsiasi strategia di sicurezza [14].
Architettura di una soluzione PAM
Un sistema PAM enterprise implementa tipicamente quattro funzionalità fondamentali: un credential vault cifrato che custodisce e ruota automaticamente le password degli account privilegiati; un session manager che registra e monitora le sessioni amministrative in tempo reale; un meccanismo di just-in-time (JIT) access che concede privilegi elevati solo per la durata necessaria all'esecuzione di un compito specifico; e un analytics engine che rileva comportamenti anomali nelle sessioni privilegiate.
Il principio architetturale centrale è l'eliminazione dell'accesso permanente (standing privilege). Invece di assegnare privilegi amministrativi in modo stabile, il sistema concede accesso elevato on-demand, previa approvazione, per una durata limitata e con registrazione completa della sessione. Questo approccio, denominato Zero Standing Privileges (ZSP), riduce drasticamente la finestra di esposizione in caso di compromissione delle credenziali.
PAM e identità non umane
Un aspetto emergente e critico è la gestione degli accessi privilegiati per le identità non umane: service account, API key, token di automazione, certificati machine-to-machine e, più recentemente, agenti di intelligenza artificiale autonomi. Le identità non umane superano quelle umane con un rapporto stimato di 10:1 in un'organizzazione enterprise tipica, e ciascuna di esse può detenere privilegi elevati su sistemi critici [14]. La convergenza tra PAM e gestione dei secrets (HashiCorp Vault, CyberArk Conjur, AWS Secrets Manager) risponde a questa esigenza, estendendo i principi di rotazione automatica, accesso JIT e audit trail alle credenziali programmatiche.
IAM e Zero Trust Architecture
L'identità come perimetro di sicurezza
Il framework Zero Trust Architecture (ZTA), formalizzato dal NIST nella Special Publication 800-207 [3], rappresenta un cambio di paradigma nella sicurezza informatica: il perimetro di protezione si sposta dalla rete all'identità. Il principio fondante, "never trust, always verify", implica che nessuna entità, interna o esterna alla rete aziendale, riceve fiducia implicita. Ogni richiesta di accesso viene valutata individualmente sulla base dell'identità del soggetto, della postura del dispositivo, del contesto della richiesta e del livello di rischio calcolato dinamicamente.
L'architettura ZTA prevede tre componenti logiche: il Policy Engine (PE), che prende le decisioni di accesso combinando policy, identity data, threat intelligence e telemetria; il Policy Administrator (PA), che traduce le decisioni del PE in azioni concrete (concessione o revoca di sessioni); e il Policy Enforcement Point (PEP), che applica le decisioni al punto di accesso alla risorsa [3]. L'IAM alimenta il PE con i dati fondamentali per la decisione: identità autenticata, ruoli, attributi, livello di assurance dell'autenticazione, storico comportamentale.
Implicazioni per l'architettura IAM
L'adozione di un modello Zero Trust impone requisiti specifici al sistema IAM che vanno oltre la semplice autenticazione e autorizzazione. L'autenticazione deve essere continua, non limitata al momento del login: il livello di fiducia nell'identità può degradarsi durante una sessione in base a segnali comportamentali (accesso da una geolocalizzazione insolita, pattern di navigazione anomali, tentativi di accesso a risorse incongruenti con il ruolo). Questo approccio, denominato adaptive authentication o continuous access evaluation, richiede un'integrazione stretta tra l'IdP, il SIEM (Security Information and Event Management) e il motore di risk scoring.
La revisione 4 della NIST SP 800-63, le cui componenti hanno raggiunto lo stato finale nel 2025, riflette questa evoluzione introducendo il supporto normativo per gli autenticatori sincronizzabili (passkey) e per i wallet digitali come modello di federazione [15]. L'inclusione dei wallet, in cui l'utente controlla direttamente le proprie credenziali verificabili, allinea le linee guida federali statunitensi con l'iniziativa europea dell'EUDI Wallet e con il paradigma emergente della Self-Sovereign Identity (SSI) [16].
Identità decentralizzata e Self-Sovereign Identity
Il paradigma SSI
La Self-Sovereign Identity (SSI) propone un'inversione del modello tradizionale di gestione delle identità: invece di dipendere da un identity provider centralizzato che custodisce e attesta le informazioni identitarie, l'utente detiene il controllo diretto sulle proprie credenziali attraverso un wallet digitale. Le due tecnologie fondanti, standardizzate dal W3C, sono i Decentralized Identifiers (DID), identificativi univoci risolubili senza un registro centrale, e le Verifiable Credentials (VC), attestazioni digitali firmate crittograficamente che possono essere presentate e verificate senza contattare l'emittente [16].
Una survey pubblicata su IEEE nel 2024 ha mappato sistematicamente l'ecosistema DID/VC, documentando la crescente maturità degli standard e delle implementazioni [16]. Il modello a tre parti, issuer (emette la credenziale), holder (la detiene nel wallet), verifier (la verifica), elimina la dipendenza real-time dall'emittente al momento della verifica, migliorando la resilienza e la privacy. La dimostrazione selettiva (selective disclosure) e le zero-knowledge proof consentono all'utente di provare il possesso di un attributo (ad esempio, l'età superiore a 18 anni) senza rivelare il dato completo (la data di nascita).
SSI nel contesto enterprise
L'applicabilità della SSI in ambito enterprise è oggetto di analisi critica. La systematic review di Glöckler et al. [2] ha valutato il potenziale contributo della SSI ai requisiti IAM enterprise, identificando benefici concreti nella gestione delle identità cross-organizzazione (partner, fornitori, clienti) dove i modelli federati tradizionali richiedono relazioni di trust bilaterali complesse. L'iniziativa europea EUDI Wallet, che mira a fornire a ogni cittadino dell'Unione un wallet digitale interoperabile per la gestione di documenti e credenziali verificabili, rappresenta il progetto SSI su scala più ambiziosa attualmente in fase di implementazione [16].
Le sfide rimangono tuttavia significative: la governance dei registri di trust (chi può emettere credenziali riconosciute), la revoca efficiente delle credenziali senza compromettere la privacy, la user experience del wallet per utenti non tecnici e l'integrazione con le infrastrutture IAM esistenti costituiscono problemi aperti che la comunità di ricerca sta affrontando attivamente.
Governance del ciclo di vita e Identity Governance Administration
Il framework Joiner–Mover–Leaver
La governance del ciclo di vita delle identità si articola attorno al modello Joiner–Mover–Leaver (JML), che formalizza i tre eventi fondamentali nel rapporto tra un'identità e un'organizzazione [11]. Nella fase Joiner, l'ingresso di un nuovo dipendente attiva un workflow automatizzato che crea l'identità nel directory aziendale, assegna i ruoli iniziali sulla base della funzione e della business unit, e provisiona gli account sulle applicazioni associate tramite connettori SCIM o proprietari. L'obiettivo è garantire l'operatività dal primo giorno (Day-1 readiness) senza intervento manuale del service desk.
La fase Mover, un cambio di ruolo, di dipartimento o di sede, è paradossalmente la più critica sotto il profilo della sicurezza. L'assegnazione di nuovi diritti è generalmente tempestiva, perché il dipendente ne ha bisogno per svolgere le nuove mansioni. La revoca dei diritti precedenti, invece, viene frequentemente trascurata o ritardata, generando un accumulo progressivo di permessi (privilege creep) che viola il principio del minimo privilegio. La fase Leaver richiede la disattivazione tempestiva e completa di tutte le identità e gli accessi, compresi quelli su sistemi secondari e applicazioni SaaS che potrebbero non essere integrate nel sistema IAM centrale.
IGA e automazione basata su policy
Le piattaforme di Identity Governance and Administration (IGA) orchestrano il ciclo di vita JML integrando dati provenienti dal sistema HR (fonte autoritativa per gli eventi organizzativi), dal directory aziendale e dalle applicazioni target. Il Netwrix 2024 Hybrid Security Trends Report ha documentato una crescita dell'adozione della governance delle identità dal 44% al 55% in ambienti cloud e dal 43% al 58% on-premises in un singolo anno, la crescita più rapida tra tutte le misure di sicurezza monitorate [17]. L'automazione del provisioning, del deprovisioning e degli aggiornamenti di ruolo riduce gli incidenti di sicurezza legati alle identità di oltre il 67% e accelera la produttività per nuovi ingressi e trasferimenti interni [11].
Le piattaforme IGA mature implementano inoltre funzionalità di access certification (revisione periodica dei diritti di accesso da parte dei responsabili), role mining (derivazione automatica di ruoli ottimali dai pattern di accesso osservati) e policy simulation (valutazione dell'impatto di una modifica alle policy prima della sua applicazione). L'integrazione di tecniche di machine learning per l'analisi degli accessi consente di identificare anomalie, utenti con permessi statisticamente incongruenti rispetto al proprio peer group, e di suggerire azioni correttive [17].
Limiti e problemi aperti
Complessità di integrazione
L'ecosistema IAM enterprise è intrinsecamente eterogeneo: protocolli diversi (SAML, OIDC, SCIM, LDAP), modelli di autenticazione incompatibili tra applicazioni legacy e moderne, e la proliferazione di identity silo nei servizi SaaS non integrati generano una complessità di gestione che il 54% delle organizzazioni identifica come il principale ostacolo alla modernizzazione del proprio sistema IAM [1]. La standardizzazione dei protocolli mitiga il problema senza risolverlo: le differenze nelle implementazioni SCIM tra provider, le estensioni proprietarie ai claim OIDC e la varietà di modelli di autorizzazione rendono ogni integrazione un progetto di ingegnerizzazione specifico.
Scalabilità della governance
La governance degli accessi presenta sfide di scalabilità proporzionali alla dimensione dell'organizzazione e al numero di applicazioni integrate [2, 17]. Una campagna di access certification in un'organizzazione con 10.000 dipendenti e 200 applicazioni genera potenzialmente milioni di decisioni di revisione. Senza automazione intelligente e prioritizzazione basata sul rischio, il processo degenera in un esercizio di compliance formale in cui i responsabili approvano in blocco senza esaminare i singoli accessi (rubber-stamping), vanificando l'obiettivo della revisione.
Identità non umane e agentic AI
L'emergere di agenti di intelligenza artificiale autonomi, sistemi che eseguono azioni per conto dell'utente, invocano API, accedono a dati e interagiscono con servizi esterni, introduce un nuovo paradigma di identità che i framework IAM attuali non gestiscono adeguatamente [14]. Un agente AI che opera con i privilegi del proprio utente ma esegue azioni non direttamente supervisionate pone domande inedite: come si applica il principio del minimo privilegio a un sistema il cui comportamento è probabilistico? Come si attribuisce la responsabilità di un'azione eseguita da un agente? Come si revoca l'accesso in tempo reale se l'agente devia dal comportamento atteso? Questi interrogativi costituiscono una frontiera attiva della ricerca e della standardizzazione in ambito IAM.
Riferimenti
[1] Cloud Security Alliance, "Top IAM Priorities for 2025: Addressing Multi-Cloud Identity Management Challenges," CSA Survey Report, 2024. https://cloudsecurityalliance.org/blog/2024/10/30/top-iam-priorities-for-2025-addressing-multi-cloud-identity-management-challenges
[2] J. Glöckler, F. Sedlmeir, M. Frank, and G. Fridgen, "A Systematic Review of Identity and Access Management Requirements in Enterprises and Potential Contributions of Self-Sovereign Identity," in Business & Information Systems Engineering, vol. 66, no. 4, Springer, 2024. https://link.springer.com/article/10.1007/s12599-023-00830-x
[3] S. Rose et al., "Zero Trust Architecture," NIST Special Publication 800-207, 2020. https://csrc.nist.gov/pubs/sp/800/207/final
[4] IETF, "Lightweight Directory Access Protocol (LDAP): The Protocol," RFC 4511, 2006. https://datatracker.ietf.org/doc/html/rfc4511
[5] Cloud Native Computing Foundation, "Keycloak — Open Source Identity and Access Management," CNCF Incubating Project, 2023. https://www.cncf.io/projects/keycloak/
[6] OASIS, "Security Assertion Markup Language (SAML) v2.0 Technical Overview," OASIS Standard, 2005. https://www.oasis-open.org/standard/saml/
[7] CMC, "Single Sign-On Security and Privacy: A Systematic Literature Review," in Computers, Materials & Continua, vol. 84, no. 3, 2024. https://www.techscience.com/cmc/v84n3/63182/html
[8] D. Hardt, "The OAuth 2.0 Authorization Framework," IETF RFC 6749, 2012. https://datatracker.ietf.org/doc/html/rfc6749
[9] OpenID Foundation, "OpenID Connect Core 1.0," Final Specification, 2014. https://openid.net/specs/openid-connect-core-1_0.html
[10] P. Hunt et al., "System for Cross-domain Identity Management: Protocol," IETF RFC 7644, 2015. https://www.rfc-editor.org/rfc/rfc7644.html
[11] OpenIAM, "Joiner–Mover–Leaver (JML) Lifecycle: Automated Provisioning and Deprovisioning," 2024. https://www.openiam.com/workforce-identity-concepts/identity-lifecycle-management/joiner-mover-leaver-lifecycle
[12] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, "Role-Based Access Control Models," in IEEE Computer, vol. 29, no. 2, pp. 38–47, 1996. https://csrc.nist.gov/csrc/media/projects/role-based-access-control/documents/sandhu96.pdf
[13] V. C. Hu et al., "Guide to Attribute Based Access Control (ABAC) Definition and Considerations," NIST Special Publication 800-162, 2014. https://csrc.nist.gov/pubs/sp/800/162/upd2/final
[14] StateTech Magazine, "Privileged Access Management: Key to Zero Trust Architecture," 2024. https://statetechmagazine.com/article/2024/09/privileged-access-management-perfcon
[15] NIST, "Digital Identity Guidelines," NIST Special Publication 800-63-4, 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final
[16] A. Muñoz et al., "A Survey on Decentralized Identifiers and Verifiable Credentials," in IEEE Access, 2024. https://ieeexplore.ieee.org/document/10891701/
[17] Netwrix, "2024 Hybrid Security Trends Report — Identity Governance Adoption," 2024. https://www.idsalliance.org/blog/identity-governance-drivers-in-the-2nd-half-of-2024