Come far funzionare bene il tuo progetto IGA: inizia dalle personas

Perché i progetti IGA falliscono più spesso di quanto dovrebbero

L'Identity Governance and Administration (IGA) esiste da abbastanza tempo perché ci si aspetterebbe un tasso di fallimento basso. I concetti sono ben consolidati, le principali piattaforme sono mature, e non mancano persone che le hanno già implementate in passato. Eppure i progetti continuano a sforare i tempi, a non rispettare l'ambito originario, oppure a consegnare una soluzione che funziona, ma non proprio per quell'organizzazione.

Le cause tendono a raggrupparsi attorno a un insieme di temi ormai familiari.

Il sostegno del management viene citato spesso, e conta davvero. Senza un impegno da parte dei vertici, i progetti sono vulnerabili a essere ridimensionati quando i budget si restringono o le priorità cambiano.

Gli obiettivi di programma sono un altro colpevole ricorrente: o sono stati fissati in modo troppo ambizioso rispetto a ciò che la tecnologia può realisticamente offrire, oppure non sono mai stati abbastanza precisi da poter essere misurati fin dall'inizio.

Le tempistiche di consegna slittano quando la pianificazione viene sacrificata pur di presentare qualcosa agli stakeholder in fretta. Le scelte tecnologiche falliscono quando la valutazione si basa sulle demo dei fornitori invece che su requisiti documentati. È facile lasciarsi attrarre da una piattaforma ricca di funzionalità e scoprire poi che le funzionalità di cui avevi davvero bisogno erano proprio quelle che richiedevano più personalizzazione. I costi sforano quando i requisiti cambiano a metà implementazione, o quando l'impegno necessario per configurare e integrare la soluzione viene sottostimato fin dal principio.

Tutti questi sono problemi reali, e tutti sono stati descritti ampiamente altrove. Ma c'è una modalità di fallimento che tende a restare in secondo piano rispetto a molte delle altre, e riceve molta meno attenzione: il progetto non ha mai stabilito con chiarezza per chi lo si stesse costruendo.

La maggior parte dei progetti IGA in difficoltà può far risalire almeno parte del problema a ipotesi fatte in una fase iniziale sui tipi di utenti, identità e scenari di accesso che la soluzione avrebbe dovuto gestire: ipotesi che si sono poi rivelate sbagliate.

La soluzione non è complicata, ma richiede disciplina. Significa iniziare il progetto costruendo un quadro completo del proprio panorama identitario, non della tecnologia, non delle integrazioni, non dei flussi di lavoro. Solo le persone e le identità che il tuo programma di governance deve coprire. Tutto il resto discende da lì.

Il resto di questo articolo spiega come costruire quel quadro del proprio panorama identitario e perché farlo fa una differenza maggiore di quanto la maggior parte delle organizzazioni si aspetti.

Quindi, stai valutando l'Identity Governance

La tecnologia in sé raramente è il motivo per cui i progetti IGA incontrano difficoltà: la causa principale è quasi sempre partire da un prodotto invece di comprendere le proprie persone.

Che tu abbia il compito di valutare una piattaforma IGA, o che tu sia già a metà progetto e le cose si stiano complicando, probabilmente hai notato che la tecnologia di solito non è la parte difficile.

Le piattaforme IGA (il software che controlla chi ha accesso a cosa, automatizza l'onboarding e l'offboarding, e garantisce che qualcuno riveda periodicamente quei diritti di accesso) sono mature, ben comprese e ampiamente capaci. La maggior parte delle piattaforme principali gestisce i casi d'uso fondamentali senza troppi problemi.

Allora perché così tanti progetti IGA sforano il budget, richiedono più tempo del previsto, o finiscono con una soluzione che non si adatta del tutto?

Nella nostra esperienza, la causa quasi sempre torna a essere la stessa: l'organizzazione ha iniziato scegliendo un prodotto invece di comprendere le proprie persone.

La cosa più preziosa che puoi fare prima di valutare un solo fornitore è capire chi lavora davvero nella tua organizzazione e come si presenta il suo rapporto con l'identità.

Non è semplice come "assumi e licenzia"

In apparenza, l'IGA sembra semplice. Qualcuno entra in azienda e riceve degli account. Qualcuno se ne va e quegli account vengono disabilitati. Nel mezzo, qualcuno verifica periodicamente che le persone abbiano ancora bisogno di ciò che possiedono.

La realtà nella maggior parte delle organizzazioni è decisamente più complicata. Considera alcune delle domande che tendono a emergere una volta che un progetto è in corso:

Cosa succede ai collaboratori esterni e al personale in somministrazione? Compaiono nel tuo sistema HR? Se no, da dove ricava la piattaforma IGA i loro dati?

E i fornitori terzi che hanno bisogno di accesso a sistemi specifici? Come vengono inseriti e chi ne gestisce il ciclo di vita?

Ci sono dipendenti che lavorano su più entità legali o regioni, magari con ruoli diversi in ciascuna?

Esistono account di servizio, account condivisi o identità macchina che devono essere governati insieme agli utenti umani?

E gli utenti in ruoli sensibili, come dirigenti, team finance o amministratori IT, che potrebbero richiedere controlli più severi o processi di approvazione diversi?

Qualcuna delle tue persona detiene un accesso su cui un ente regolatore o un revisore chiederà specificamente conto, e questo cambia il modo in cui i suoi permessi devono essere rivisti o documentati?

I permessi dovrebbero durare per sempre, oppure alcuni permessi, specialmente quelli sensibili, dovrebbero avere una durata limitata?

Nessuno di questi è un caso limite. In qualsiasi organizzazione con più di poche centinaia di persone, sono la norma. E se la piattaforma IGA scelta non è stata valutata rispetto a essi, lo scoprirai nel modo più difficile, di solito durante l'implementazione, quando cambiare rotta costa caro.

Entra in scena la persona

In termini di identity governance, una persona è un tipo distinto di utente il cui ciclo di vita identitario, requisiti di accesso o fonti dati differiscono in modo significativo dagli altri: non singole persone fisiche, ma tipologie di persone.

Esiste una tecnica che fa parte da decenni dell'analisi strutturata dei sistemi, presa in prestito originariamente dall'ingegneria del software, perfettamente adatta a risolvere questo problema. Ha nomi diversi - user personas, attori, archetipi identitari - ma l'idea è semplice.

Prima di definire cosa un sistema debba fare, si definiscono innanzitutto tutti i diversi tipi di persone (e non persone) che il sistema deve servire.

Nella nostra esperienza, un'organizzazione di medie dimensioni identifica tipicamente tra le trenta e le cinquanta personas identitarie distinte. Per organizzazioni nel settore sanitario, educativo o retail, quel numero può facilmente raddoppiare.

Alcuni esempi per rendere l'idea più concreta:

Un dipendente permanente che entra tramite il tuo sistema HR, con un percorso di onboarding standard, l'approvazione del responsabile diretto e un insieme definito di accessi di base predefiniti.

Un collaboratore procurato tramite un'agenzia, il cui profilo vive in un foglio di calcolo o in un portale fornitori anziché nell'HR, e che potrebbe lavorare per più clienti contemporaneamente.

Uno studente o stagista con un impegno a tempo determinato e un accesso che deve scadere in modo pulito al termine del periodo.

Un utente IT privilegiato che detiene account amministrativi che richiedono un controllo elevato, misure di segregazione e, potenzialmente, accesso just-in-time invece di permessi permanenti.

Un'identità non umana, come un account di servizio applicativo o un'integrazione API, che possiede permessi, deve essere governata, e di certo non compilerà mai un modulo di richiesta di accesso self-service.

Ciascuna di queste personas interagirà in modo diverso con la tua piattaforma IGA. Alcune verranno inserite automaticamente da un sistema sorgente. Altre richiederanno processi manuali o fonti dati alternative. Alcune richiederanno catene di approvazione specializzate; altre richiederanno che l'accesso scada secondo un calendario.

Perché questo conta per la scelta della piattaforma

Una volta che hai il tuo elenco di personas, i tuoi requisiti si scrivono quasi da soli.

Smetti di chiedere "questa piattaforma supporta joiner/mover/leaver?" (rispondono tutte di sì) e inizi a porre domande molto più specifiche:

Può acquisire dati identitari da più fonti, come HRIS, fogli di calcolo, LDAP ed endpoint SCIM, e riconciliarli in un unico record identitario?

Può gestire identità che non hanno alcun record HR, tramite un flusso di onboarding separato?

Può applicare policy di governance diverse a tipi di utente diversi, così che i tuoi collaboratori esterni abbiano un ciclo di revisione dell'accesso di 90 giorni mentre i tuoi utenti privilegiati lo abbiano mensile?

Quando qualcuno cambia ruolo, può calcolare il delta e provisionare o deprovisionare le cose giuste senza intervento umano e senza creare diritti orfani?

Può segnalare quando qualcuno accumula una combinazione di diritti di accesso che rappresenta un rischio, anche se ciascun diritto individuale sembrava innocuo al momento della concessione? Può mostrare a un revisore perché l'accesso di ciascuna persona è stato approvato e da chi, con una cadenza di revisione coerente con il rischio che quella persona comporta?

Una piattaforma IGA ben progettata dovrebbe essere in grado di gestire tutto quanto sopra. L'esercizio delle personas ti dice quali di quelle capacità sono davvero critiche per la tua organizzazione, e quali sono semplicemente auspicabili.

Ti dice anche cosa chiedere di dimostrare quando valuti i fornitori. Invece di assistere a una demo generica del prodotto, puoi consegnare al fornitore un set di personas e chiedergli di mostrarti, in modo specifico, come la sua piattaforma gestisce ciascuna di esse.

L'esercizio delle personas trasforma la valutazione di un fornitore da un confronto di funzionalità a un vero e proprio test delle capacità. È molto più difficile nascondere una lacuna quando hai chiesto uno scenario specifico invece di una capacità generica.

Come si presenta una buona implementazione nella pratica

Quando osservi un'implementazione IGA ben configurata, il pensiero basato sulle personas è visibile nell'architettura. Tipi di identità diversi seguono percorsi di onboarding diversi. L'accesso viene assegnato in base al ruolo e al contesto, non tramite elenchi curati manualmente. Quando le circostanze di qualcuno cambiano (una promozione, un trasferimento, un prolungamento di contratto), la piattaforma risponde automaticamente.

Le revisioni degli accessi hanno un ambito definito in modo intelligente: le persone giuste rivedono i diritti giusti, con una cadenza appropriata al livello di rischio. Quando un revisore individua qualcosa che non dovrebbe essere lì, la rimozione è automatica e verificabile. Quando l'accesso serve con urgenza, esiste un flusso di richiesta e approvazione che lascia una traccia chiara.

Le combinazioni sensibili di accesso (ad esempio, la capacità di emettere un ordine d'acquisto e anche di approvarlo) vengono identificate in modo proattivo, non scoperte durante un audit. Le eccezioni vengono gestite con supervisione, invece di accumularsi silenziosamente.

Nulla di tutto ciò richiede una piattaforma particolarmente esotica. Ciò che richiede è che qualcuno, all'inizio del progetto, si sia preso il tempo di capire quali tipi di persone e identità l'organizzazione abbia realmente, e abbia progettato la soluzione attorno a esse.

Il ritorno si manifesta ovunque l'accesso tocchi il business: i diritti si muovono più velocemente perché non richiedono intervento manuale, sono più accurati perché legati al contesto invece che a elenchi statici, e la conformità smette di essere una corsa contro il tempo perché le prove sono state raccolte man mano che il lavoro avveniva, non ricostruite a posteriori.

Il vantaggio pratico

Oltre a rendere più probabile il successo del tuo progetto IGA, l'esercizio delle personas ha un paio di effetti collaterali utili.

Avvantaggia anche altri progetti. L'identità tocca praticamente tutto in un'organizzazione. Il tuo elenco di personas sarà altrettanto utile quando valuti soluzioni di Privileged Account Management (PAM), strumenti di gestione degli endpoint, o qualsiasi altra cosa che debba sapere chi sono i tuoi utenti e cosa fanno.

Rende più semplici le conversazioni con gli stakeholder. Quando puoi fare riferimento a "la persona del collaboratore esterno" o "la persona dell'amministratore privilegiato" invece di descrivere un requisito tecnico astratto, la conversazione diventa più concreta. Gli stakeholder di business comprendono le personas in un modo in cui non sempre comprendono gli schemi dei diritti di accesso.

Produce un input naturale per la governance di progetto. Se utilizzi una matrice RACI (Responsible, Accountable, Consulted, Informed) per gestire le responsabilità di progetto, il tuo elenco di personas ti fornisce la materia prima. Dietro ogni persona c'è un business owner, un custode tecnico e un insieme di stakeholder, tutti da consultare, informare o coinvolgere direttamente.

Dove si inserisce una piattaforma come Netwrix Identity Manager

Nulla di tutto ciò è un motivo per rimandare la scelta di una piattaforma. È un motivo per sceglierne una costruita per lavorare nel modo in cui funziona il tuo elenco di personas, non contro di esso.

Netwrix Identity Manager governa identità interne, esterne, ospiti, tecniche, IoT e di agenti IA nello stesso modello, così che un collaboratore reperito tramite un foglio di calcolo, un account di servizio di cui nessuno in HR ha mai sentito parlare, un agente IA che effettua il provisioning del proprio accesso e un dipendente permanente che arriva tramite il tuo feed HR ricevono tutti la stessa disciplina di ciclo di vita, invece di quattro soluzioni improvvisate diverse. Le identità di terze parti e non umane hanno un proprio percorso di ciclo di vita, incluso l'accesso a tempo determinato che scade secondo programma invece di persistere dopo la fine di un contratto o di un incarico. Anche l'onboarding di nuovi sistemi non richiede un progetto di integrazione su misura: i connettori standard coprono AD, LDAP, SQL, CSV e SCIM out of the box, con connettori avanzati e API generiche disponibili per qualsiasi cosa più specifica del tuo ambiente.

La gestione dei ruoli funziona allo stesso modo. Definisci modelli di ruolo e di policy per persona invece di un'unica policy per tutti, e il role mining usa il machine learning per analizzare i pattern di accesso reali, scoprire le strutture dei ruoli e mantenere il modello aggiornato man mano che l'utilizzo cambia, così che non si limiti a riflettere l'organigramma del giorno in cui è stato costruito.

Il lato del rischio è costruito per la stessa realtà. Un motore di policy rileva e previene i conflitti di segregazione dei compiti, e il monitoraggio continuo segnala account orfani e anomalie prima che emergano in un audit invece che dopo.

Nulla di tutto ciò sostituisce l'esercizio delle personas. È ciò che rende possibile un passaggio rapido dalla progettazione all'implementazione: ogni identità viene definita e governata secondo i propri termini, invece di essere forzata attraverso un unico canale e sistemata con eccezioni per farla rientrare. Il risultato è un rischio più basso, un'implementazione più rapida e un costo inferiore.

In sintesi

Le piattaforme di Identity Governance sono mature e capaci. La tecnologia di solito non è ciò che fa incontrare difficoltà ai progetti. Ciò che fa incontrare difficoltà ai progetti è partire da un prodotto e cercare di far rientrare dopo la realtà dell'organizzazione al suo interno.

L'alternativa (identificare prima le proprie personas identitarie, usarle per definire i requisiti, e poi valutare le piattaforme rispetto a quei requisiti) sembra ovvia quando la si descrive. Ma è sorprendentemente rara nella pratica, e il vuoto che colma è significativo.

Non richiede strumenti specialistici né conoscenze tecniche approfondite. Richiede tempo, buone domande, e la volontà di coinvolgere le persone giuste da tutta l'azienda fin dalle prime fasi del processo.

Definisci bene le personas, e il resto del progetto diventa considerevolmente più semplice. Sbagliale, o saltale del tutto, e potresti ritrovarti a dover adattare a posteriori una soluzione a un problema che non avevi capito fino in fondo quando l'hai acquistata.

Hai problemi con il tuo programma di identità? Possiamo aiutarti a comprendere le tue personas e come Netwrix Identity Manager possa rendere il tuo progetto un successo. Richiedi una demo.