Il principio del privilegio minimo è semplice da enunciare: ogni utente dovrebbe avere solo gli accessi necessari al proprio ruolo, e nulla di più. È difficile, invece, mantenerlo nel tempo, perché nelle organizzazioni reali gli accessi tendono a crescere e quasi mai a diminuire.
Questo fenomeno ha un nome, privilege creep, e una dinamica precisa. A ogni cambio di ruolo, a ogni progetto trasversale, a ogni urgenza risolta concedendo un permesso in più, la somma dei privilegi di una persona aumenta. Nessuno decide mai di accumulare, eppure dopo qualche anno l’organizzazione si ritrova con utenti che possono accedere a molto più di ciò che serve, e con un quadro che nessuno saprebbe più giustificare voce per voce.
Come nasce il privilege creep
La prima causa è il cambio di ruolo gestito a metà, la fase “mover” del ciclo di vita delle identità di cui abbiamo parlato nell’articolo sul modello joiner-mover-leaver. Una persona passa da un reparto all’altro e riceve i permessi della nuova posizione. I precedenti restano, perché toglierli richiede una decisione esplicita che nessuno prende: chi arriva non ha motivo di segnalarlo, chi lascia il reparto non se ne occupa più, l’IT registra una richiesta di aggiunta e non una di rimozione.
La seconda è il permesso concesso per un’eccezione. Una scadenza urgente, una sostituzione durante le ferie, un progetto che richiede l’accesso a un sistema di un altro reparto. L’accesso viene aperto con la migliore delle intenzioni e con l’idea implicita che sia temporaneo, ma nessun meccanismo ne prevede la chiusura. Nella pratica, temporaneo significa permanente.
La terza è l’assegnazione per copia. Quando entra una persona in un ruolo già esistente, il modo più veloce per configurarla è replicare i permessi di un collega. Se quel collega ha accumulato privilegi negli anni, l’accumulo si trasmette: il nuovo arrivato eredita, dal primo giorno, permessi che non ha mai avuto ragione di ricevere.
Perché è un rischio concreto e non solo un problema di ordine
Ogni permesso in eccesso è una porta in più che un attaccante può attraversare se compromette quell’account. Il furto di credenziali resta la modalità di ingresso più sfruttata, e le campagne di phishing sono diventate molto più efficaci da quando l’AI generativa produce messaggi credibili e personalizzati. Un attaccante che entra con credenziali valide non deve forzare nulla: si muove come un utente autorizzato, e l’ampiezza dei suoi privilegi decide quanto lontano può arrivare.
Il privilege creep amplifica anche il danno interno non doloso. Un errore commesso su un sistema a cui una persona non avrebbe dovuto avere accesso è più probabile e più difficile da ricostruire. E rende meno affidabile qualsiasi analisi post incidente: se molti utenti possono fare molte cose, restringere il campo delle ipotesi richiede più tempo.
Il fenomeno non riguarda più solo le persone. Gli AI agent introdotti negli ultimi anni ricevono spesso, al momento della creazione, autorizzazioni più ampie del necessario, perché è più semplice concedere l’accesso a un’intera applicazione che definire con precisione cosa l’agente deve fare. Quelle autorizzazioni non vengono quasi mai ristrette in seguito. Il 91% delle aziende usa già AI agent, ma solo il 10% ha una strategia strutturata per gestirli come identità (Okta, AI at Work 2025): per la maggior parte delle organizzazioni il privilege creep degli agenti non è nemmeno misurato.
Sul piano normativo il tema è esplicito. Il privilegio minimo è richiesto, direttamente o di fatto, dagli impianti NIS2 e DORA, e in sede di verifica non basta enunciarlo in una policy: va dimostrato che i privilegi effettivamente assegnati corrispondono ai ruoli dichiarati. Per i soggetti NIS2 già iscritti in elenco questa evidenza deve essere disponibile entro il 31 ottobre 2026, data da cui l’ACN può avviare le verifiche ispettive. Delle cinque evidenze che un audit chiede abbiamo scritto nell’articolo dedicato all’audit NIS2 e DORA: il privilegio minimo è la seconda, e di solito è quella con lo scarto maggiore tra ciò che la policy dichiara e ciò che i sistemi mostrano.
Perché la revisione manuale non regge
Quasi tutte le organizzazioni sanno di dover rivedere periodicamente gli accessi. La maggior parte lo fa, o dichiara di farlo, con un’esportazione in foglio di calcolo inviata via email ai responsabili una volta l’anno. Il processo si inceppa sempre negli stessi punti.
Il primo è la mancanza di contesto. Un responsabile che riceve un elenco di duecento righe con nomi di applicazioni e codici di permesso non ha gli elementi per decidere: senza sapere quando quell’accesso è stato usato l’ultima volta, la risposta razionale è confermare tutto, perché revocare comporta un rischio operativo e confermare no.
Il secondo è lo scollamento tra decisione ed esecuzione. Anche quando un responsabile chiede di revocare, la revoca è un’attività manuale che qualcun altro deve eseguire su un altro sistema, in un altro momento. Il tasso di completamento è basso e la tracciabilità del collegamento tra la decisione e la sua esecuzione va ricostruita a mano.
Il terzo è la frequenza. Una revisione annuale lascia undici mesi in cui l’accumulo procede indisturbato. Il risultato è che la fotografia scattata durante la campagna è già superata quando la campagna si chiude.
Come funziona una certificazione degli accessi che regge
La certificazione periodica degli accessi è l’antidoto strutturale, a condizione che sia un processo e non un adempimento. Con Okta Identity Governance le campagne di Access Certification possono essere pianificate su base ricorrente oppure attivate in risposta a eventi specifici, come un cambio di reparto o la chiusura di un progetto.
La differenza sostanziale sta nel contesto fornito a chi decide. Ogni voce può essere arricchita con informazioni che rendono la revisione significativa, come la frequenza di utilizzo o l’ultima volta che una risorsa è stata effettivamente usata. Su un permesso non utilizzato da mesi la decisione è immediata; lo stesso permesso, presentato senza contesto, resta lì perché nessuno se la sente di toglierlo.
Il secondo elemento è la remediation automatica. Quando un responsabile revoca, la revoca viene eseguita dalla piattaforma sui sistemi collegati, senza un passaggio manuale intermedio. La decisione e la sua esecuzione diventano lo stesso evento, e l’evidenza che ne deriva è completa per costruzione.
Attorno alla certificazione lavorano altre due leve. L’Entitlement Management lega i permessi ai ruoli invece che alle richieste individuali, così che un cambio di ruolo ricalcoli l’insieme dei privilegi invece di aggiungersi a quello precedente. Le Access Requests con approvazione e scadenza governano i permessi temporanei, che scadono da soli: è il modo più semplice per impedire che l’eccezione di oggi diventi il privilegio permanente di domani.
Il conto lo paga anche chi non si occupa di sicurezza
Il privilege creep viene percepito come un problema del team sicurezza, ma i suoi effetti si distribuiscono altrove. Il primo a pagarne il prezzo è il service desk: più i profili sono disomogenei, meno è possibile standardizzare la configurazione di un nuovo utente, e ogni ingresso diventa una piccola attività su misura. Il tempo di onboarding si allunga e la probabilità di errore aumenta.
Il secondo effetto riguarda i progetti di migrazione. Quando arriva il momento di spostare un’applicazione o di adottare una nuova piattaforma, la mappa dei permessi esistenti è il punto di partenza obbligato. Se quella mappa è il risultato di anni di stratificazioni, l’analisi preliminare costa settimane di lavoro e produce comunque un risultato incerto, che spesso viene replicato tale e quale sul sistema nuovo per non rallentare la migrazione.
Il terzo riguarda le persone. Un dipendente che mantiene accesso a sistemi del reparto precedente si trova, senza averlo chiesto, in una posizione scomoda: in caso di incidente rientra nel perimetro delle verifiche, e la ricostruzione tocca anche lui. Ridurre i privilegi non è solo una misura di sicurezza, è anche una forma di tutela di chi lavora.
Da dove iniziare, in pratica
Un modo concreto per misurare il fenomeno prima di intervenire è prendere un campione di dipendenti con almeno cinque anni di anzianità e confrontare i permessi effettivi con quelli previsti dal ruolo attuale. Lo scarto che emerge è la dimensione del privilege creep in quella organizzazione, ed è quasi sempre più ampio di quanto ci si aspetti.
Il secondo passo è definire i ruoli sui sistemi più critici, anche in modo approssimativo: senza una base di riferimento non esiste un modo oggettivo per dire quali permessi sono in eccesso. Il terzo è una campagna pilota su un perimetro ristretto, con l’obiettivo di misurare due numeri, la percentuale di accessi revocati e il tempo medio di risposta dei responsabili.
Il quarto è la scelta di una cadenza sostenibile. Una revisione semestrale davvero eseguita, con contesto e remediation automatica, vale più di una annuale continuamente rinviata. E, a differenza della prima, mantiene il privilegio minimo invece di limitarsi a fotografarne il degrado.
Domande frequenti
Che cos’è il privilege creep
È l’accumulo progressivo di permessi che un utente raccoglie nel tempo attraverso cambi di ruolo, progetti ed eccezioni, senza che i privilegi non più necessari vengano revocati.
Qual è la differenza tra privilegio minimo e Zero Trust
Il privilegio minimo è il principio secondo cui ogni identità riceve solo i permessi necessari al proprio compito. Zero Trust è un modello architetturale più ampio, che assume l’assenza di fiducia implicita e verifica ogni accesso: il privilegio minimo ne è uno dei pilastri, non un sinonimo.
Ogni quanto va fatta una revisione degli accessi
Dipende dalla criticità dei sistemi e dal ritmo con cui cambiano i ruoli. Per i sistemi critici la semestrale è il minimo ragionevole, e va affiancata da revisioni puntuali a ogni cambio di ruolo e cessazione, che sono i momenti in cui il privilege creep si genera. Una cadenza più fitta ma rispettata vale più di una ambiziosa e disattesa.
Come si misura il privilege creep in azienda
Il modo più diretto è confrontare, su un campione di utenti con anzianità elevata, i permessi effettivamente assegnati con quelli previsti dal ruolo ricoperto oggi. La differenza è una stima concreta dell’accumulo.
La certificazione degli accessi serve solo per la conformità
No. Produce due risultati insieme: riduce la superficie d’attacco riportando l’organizzazione al privilegio minimo, e genera l’evidenza documentale che una verifica richiede. È lo stesso processo a servire entrambi gli obiettivi.
In sintesi
Il privilege creep è il debito tecnico della sicurezza degli accessi: si accumula un permesso alla volta, sempre per una ragione ragionevole, e diventa visibile solo quando qualcuno lo sfrutta. Non si risolve con un intervento una tantum, perché la causa è strutturale e continua a operare. Si governa con un processo ricorrente, dotato di contesto e di esecuzione automatica, che riporta l’organizzazione al privilegio minimo e lascia dietro di sé la traccia documentale che serve in sede di verifica.
Per misurare quanto è ampio l’accumulo nella vostra organizzazione, in Factor-y, primo partner Okta in Italia, mettiamo a disposizione un assessment di 30 minuti, gratuito: una lettura dei privilegi effettivi rispetto ai ruoli, con le priorità di intervento.
