Un amministratore di database deve intervenire su un server di produzione. Nel modello tradizionale può disporre di un account che conserva i relativi privilegi 24 ore al giorno, anche se li utilizza poche volte al mese. Con il Privileged Identity Management (PIM) il principio cambia: l’amministratore è riconosciuto come idoneo a ottenere quei privilegi, ma deve attivarli quando ne ha bisogno. L’autorizzazione può richiedere MFA, approvazione, una motivazione e altri controlli; dopo trenta minuti, un’ora o il tempo stabilito dalla policy, decade automaticamente.
Con questo approccio vengono ridotti i cosiddetti standing privileges, autorizzazioni potenti che rimangono disponibili anche quando nessuno le sta utilizzando.
La questione ha assunto una dimensione diversa con la moltiplicazione delle identità digitali. Oltre agli amministratori IT nel campo giocano diversi attori: sviluppatori, fornitori esterni, workload cloud, service account, API, container, pipeline DevOps e, sempre più spesso, agenti AI capaci di operare sui sistemi.
Il 2026 Global Incident Response Report di Palo Alto Networks, rileva che debolezze legate alle identità hanno avuto un ruolo nell’89% delle indagini. Nell’analisi di oltre 680.000 identità cloud, il 99% di utenti, ruoli e servizi disponeva inoltre di autorizzazioni eccessive, alcune inutilizzate da almeno 60 giorni.
Le credenziali continuano intanto a essere un bene facilmente monetizzabile. Nel DBIR 2025 Verizon ha rilevato l’uso di credenziali compromesse come vettore iniziale nel 22% delle violazioni analizzate. Nei log dei provider SSO studiati per la stessa ricerca, il credential stuffing rappresentava, nel caso mediano, il 19% dei tentativi giornalieri di autenticazione.
Se una password rubata è pericolosa, una password rubata associata a privilegi amministrativi permanenti lo è molto di più.
Come funziona il Privileged Identity Management
Un sistema PIM parte da un censimento. Deve sapere quali identità dispongono, o possono disporre, di privilegi: amministratori di dominio, amministratori cloud, DBA, sviluppatori, service account, API key, chiavi SSH, account di emergenza. Deve inoltre stabilire su quali risorse tali privilegi producono effetti.
L’operazione è meno banale di quanto sembri. Gruppi annidati, vecchi account, permessi ereditati, ambienti multi-cloud e applicazioni legacy possono produrre un livello di privilegio effettivo molto superiore a quello visibile osservando una singola directory.
Il secondo passaggio consiste nel separare l’idoneità al privilegio dal possesso permanente del privilegio. Un sistemista può essere autorizzato a diventare amministratore di un determinato ambiente senza esserlo continuamente.
Quando deve eseguire un intervento, richiede l’elevazione. Il PIM verifica le condizioni stabilite dalla policy: identità dell’utente, MFA, stato del dispositivo, rete di provenienza, rischio della sessione, ticket di change management, eventuale approvazione del responsabile. Solo dopo questi controlli il ruolo viene attivato.
È il principio del just-in-time access (JIT). A questo si accompagna il just-enough access: il privilegio dovrebbe riguardare soltanto le risorse e le operazioni necessarie.
Al termine della finestra autorizzata, il privilegio viene revocato automaticamente.
In un’implementazione più ampia entrano poi in gioco vault per password e chiavi, rotazione automatica delle credenziali, broker delle sessioni, registrazione delle attività amministrative e integrazione con SIEM e SOAR. La sequenza richiesta-attivazione-utilizzo-revoca diventa così ricostruibile a posteriori.
Questo modello risponde anche a una trasformazione del rischio. Palo Alto Networks rileva che il 65% degli accessi iniziali osservati nel 2025 è riconducibile a tecniche basate sull’identità, tra social engineering e abuso di credenziali. Nell’87% degli incidenti analizzati gli attaccanti hanno operato su almeno due superfici di attacco. Una volta ottenuta un’identità valida, quindi, l’obiettivo è spesso trovare autorizzazioni che permettano di avanzare verso altri sistemi.
Dove il PIM si inserisce nell’identity management
PIM, PAM e IAM vengono talvolta usati come termini quasi intercambiabili. Ma ci sono delle sottili differenze che è utile sottolineare.
L’Identity and Access Management (IAM) costituisce il perimetro più ampio: gestisce identità, autenticazione e autorizzazioni. Vi rientrano directory, single sign-on, federation, MFA, lifecycle degli utenti, access management e altri servizi.
L’Identity Governance and Administration (IGA) aggiunge la dimensione della governance: chi dovrebbe avere accesso a che cosa, chi approva quell’accesso, come viene certificato e come cambia quando una persona viene assunta, cambia ruolo o lascia l’azienda. Gartner, per esempio, continua infatti a trattare IGA come un mercato specifico dell’IAM.
Il Privileged Identity Management si concentra invece sull’idoneità a ricevere privilegi elevati e sulla loro elevazione temporanea. Stabilisce, per esempio, che una determinata persona possa diventare amministratore Azure per un’ora, previa MFA e approvazione.
Il Privileged Access Management (PAM) copre un dominio in larga parte contiguo, ma tradizionalmente si concentra maggiormente sull’utilizzo dell’accesso privilegiato: vault delle credenziali, rotazione delle password, gestione e registrazione delle sessioni, accesso remoto privilegiato ed endpoint privilege management.
Nella pratica la separazione si sta assottigliando. Le piattaforme PAM incorporano JIT e governance delle identità; quelle nate nell’identity governance estendono il controllo alle sessioni privilegiate e alle identità non umane. Gartner osservava già nel 2025 che funzioni mature quali vaulting e session management si stavano progressivamente standardizzando, mentre restavano più differenzianti le capacità rivolte all’accesso privilegiato delle macchine.
Forrester ha persino scelto Privileged Identity Management Solutions come denominazione per la propria Wave del terzo trimestre 2025, valutando dieci provider. Secondo la società di analisi, il mercato si sta spostando dal controllo degli amministratori IT verso piattaforme capaci di governare identità umane, machine identity e agenti AI.
Per il CIO e i CISO, dunque, è più utile guardare alle capacità che all’etichetta commerciale: discovery delle identità privilegiate, governance, JIT, gestione delle credenziali, controllo delle sessioni, accesso dei fornitori, privilegi degli endpoint, workload identity e integrazione con l’ecosistema IAM e SOC.
Anche la regolamentazione europea spinge in questa direzione. Nel settore finanziario, le norme tecniche di DORA richiedono che gli accessi privilegiati, di emergenza e amministrativi siano assegnati sulla base della necessità di utilizzo o ad hoc e registrati nei log; indicano inoltre, ove possibile e opportuno, l’impiego di soluzioni automatizzate per la gestione degli accessi privilegiati.
Un’impostazione analoga compare nelle regole di attuazione della NIS2 applicabili alle categorie contemplate dal regolamento europeo 2024/2690: sono previsti account dedicati alle operazioni di amministrazione, autenticazione forte, restrizione dei privilegi e revisione periodica dei diritti degli account privilegiati. Il PIM non equivale quindi alla conformità normativa, ma può fornire alcuni dei controlli e delle evidenze necessari a dimostrarla.
I…
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Gianluca Ferrari
Source link
