Un cambio di ruolo non modifica soltanto l’organigramma: richiede di verificare che gli accessi ai dati restino coerenti con le funzioni effettivamente svolte.
La gestione del cambiamento è da analiuzzare attraverso il privilegio minimo, la revisione delle abilitazioni, la scadenza degli accessi temporanei e i riesami periodici, per evitare che il profilo informatico conservi privilegi non più necessari.
L’obiettivo è trasformare l’autorizzazione da adempimento iniziale a processo verificabile lungo l’intero ciclo di vita dell’utenza, collegando organizzazione, sicurezza e accountability.
Indice degli argomenti
Il cambio di ruolo è un evento privacy
Il cambio di ruolo è un evento rilevante anche per la protezione dei dati e per la sicurezza: un’autorizzazione corretta al momento del rilascio può diventare eccessiva e obsoleta il giorno successivo, senza che nessuno abbia commesso materialmente un abuso.
Nelle organizzazioni, gli account vengono creati rapidamente, ma spesso il rischio che non invecchino bene si annida tra le pieghe della velocità dei cambiamenti.
Un dipendente cambia ufficio, assume nuove responsabilità, viene assegnato a un progetto diverso o cessa di svolgere alcune mansioni; le credenziali, invece, possono continuare a raccontare la sua precedente storia professionale.
Quando sorge il rischio
È in questo scarto temporale che nasce il rischio. L’utente non dispone necessariamente di privilegi illegittimi perché qualcuno glieli ha attribuiti senza titolo: può averli ricevuti correttamente e averli conservati troppo a lungo.
Il problema, quindi, non è soltanto decidere chi può accedere, ma verificare nel tempo se continui ad averne bisogno.
La sicurezza degli accessi, quindi, non si misura al momento in cui viene creato l’account, ma durante l’intero ciclo di vita dell’identità digitale.
Per questo l’autorizzazione non può essere trattata come un atto statico: deve seguire la mansione, non sopravviverle.
Mansioni, autorizzazioni e profili informatici
Nel linguaggio organizzativo, il ruolo e profilo informatico vengono spesso considerati equivalenti, ma non lo sono, punto il ruolo descrive la posizione della persona nell’organizzazione, l’autorizzazione delimita le operazioni che può compiere sui dati; il profilo informatico traduce quel perimetro in funzioni e privilegi concretamente utilizzabili in software ad applicazioni aziendali, assieme alle credenziali di accesso.
I problemi nascono quando questi tre livelli smettono di coincidere. Una variazione registrata dall’ufficio del personale potrebbe non modificare automaticamente le autorizzazioni configurate nei sistemi.
Allo stesso modo una designazione formalmente corretta non rende adeguato un account che consente di consultare e modificare ed estrarre più dati di quelli necessari.
Il mansionario può cambiare con una firma. Le autorizzazioni informatiche richiedono invece un intervento effettivo, perché il relativo rischio viene mitigato solo quando si modificano anche i privilegi.
Il vero oggetto del controllo non è il documento di nomina isolatamente considerato, ma la coerenza tra compiti assegnati, dati accessibili e operazioni consentite.
Il caso Sassari: accessi non coerenti
Un esempio particolarmente chiaro viene dal provvedimento adottato dal Garante nei confronti della Città Metropolitana di Sassari.
Una configurazione non corretta del protocollo informatico aveva reso consultabili documenti riservati anche a persone che, per ruolo e mansioni, non avrebbero dovuto accedervi.
Il punto più significativo non è soltanto che alcune persone potessero vedere un documento riservato, ma che il sistema attribuisse loro una capacità operativa non coerente con la posizione effettivamente ricoperta.
Quando il profilo applicativo non coincide con il ruolo reale, l’errore organizzativo diventa immediatamente una vulnerabilità tecnica.
La causa principale del data breach è stata quindi organizzativa e di progettazione: attribuzione impropria di privilegi; mancato allineamento tra mansioni e autorizzazioni; eccesso di accessi ereditati; assenza di controlli periodici sui profili autorizzativi.
Il caso non riguarda specificamente la mancata revoca di privilegi dopo un cambio di mansione, mostra, però, un problema direttamente pertinente: quando organizzazione e configurazione degli accessi non coincidono, il sistema può rendere disponibili dati a chi non è legittimato a trattarli.
La vicenda, verificatasi durante una transizione istituzionale e informatica dell’ente, offre quindi un punto di partenza per riflettere sulla gestione delle autorizzazioni nei processi di cambiamento.
Privilegi minimi, non fiducia illimitata
La vicenda e il problema più in generale possono essere letti attraverso due criteri complementari: il least privilege, che limita i privilegi alle operazioni necessarie per svolgere i compiti assegnati, e il need-to-know, che circoscrive la conoscibilità delle informazioni a quelle necessarie per quei compiti.
Il punto di partenza è la necessità dell’accesso, richiamata anche dal Garante attraverso le Linee guida EDPB sull’art. 25: occorre limitare sia i soggetti abilitati sia la tipologia di accesso ai dati.
Non significa semplicemente “dare pochi permessi”, ma costruire un rapporto dimostrabile tra ogni privilegio e una specifica esigenza lavorativa: è un discorso di ampiezza e profondità di accesso, che deve essere commisurata alla funzione cui quel profilo è collegato: il minimo potere di accesso per svolgere al meglio le mansioni.
Mansioni e privilegi, quali domande porsi
La domanda corretta non è dunque: “Questo dipendente è affidabile?”. La domanda giusta è: “Per quale attività ha bisogno di questa funzione, di questo archivio e di questo livello di accesso?”.
La fiducia riguarda la persona; il privilegio riguarda la funzione.
Confondere i due piani significa trasformare la fiducia in una misura di sicurezza.
Il ciclo di vita degli accessi
Un sistema IAM efficace deve governare almeno tre momenti: l’ingresso della persona nell’organizzazione, il cambiamento della sua posizione e l’uscita.
Il momento più trascurato è spesso quello intermedio.
L’assunzione produce un evento evidente: occorre creare l’account. La cessazione ne produce un altro altrettanto riconoscibile, sebbene non scontato: l’account deve essere disabilitato.
Il cambiamento di mansione, invece, rischia di aggiungere i nuovi privilegi senza rimuovere quelli precedenti. Gli accessi raramente diventano eccessivi in un solo giorno: si accumulano per stratificazione.
Il passaggio da un ufficio a un altro dovrebbe determinare una revisione completa, non una semplice integrazione del profilo.
In caso contrario, l’identità digitale del lavoratore conserva tracce di tutte le funzioni ricoperte nel tempo e finisce per rappresentare la sua carriera, anziché il suo incarico attuale.
Il cambio di ruolo deve quindi attivare almeno tre verifiche nel momento in cui accade: quali autorizzazioni devono essere attribuite, quali devono essere mantenute e quali devono essere revocate.
Particolare attenzione meritano le autorizzazioni concesse per sostituzioni, progetti, emergenze o attività di assistenza.
Se manca una scadenza predefinita, il privilegio temporaneo tende a diventare permanente per inerzia.
Ogni privilegio eccezionale dovrebbe nascere con una data di scadenza, non con la promessa di ricordarsi di revocarlo.
Dal cambio di mansione alla revisione
Una policy che impone il privilegio minimo resta inefficace se non stabilisce chi comunica il cambio di ruolo, chi valuta gli accessi da revocare, chi modifica il profilo, entro quale termine e con quale evidenza.
La regola diventa una misura di sicurezza soltanto quando produce un’azione verificabile.
Il punto decisivo è trasformare il cambio di mansione in un evento capace di attraversare i confini tra HR, responsabile di funzione, IT, sicurezza e privacy. Se l’informazione resta confinata nel fascicolo del personale, il sistema informatico continuerà a riconoscere il vecchio ruolo.
Riesaminare gli accessi nel tempo
Neppure il processo meglio progettato intercetta sempre ogni cambiamento. Per questo alle revisioni attivate dagli eventi deve affiancarsi una ricertificazione periodica degli accessi.
Il responsabile non dovrebbe ricevere soltanto un elenco di username, ma una rappresentazione comprensibile delle applicazioni accessibili, dei privilegi assegnati e delle ragioni che ne giustificano il mantenimento. La ricertificazione deve produrre una decisione: conferma, riduzione, revoca o approfondimento.
Una mera presa visione dell’elenco non dimostra che l’organizzazione abbia verificato la necessità degli accessi.
Dimostrare la gestione delle autorizzazioni
Governare le autorizzazioni significa anche poter dimostrare come sono state governate: l’organizzazione dovrebbe poter ricostruire chi ha richiesto l’accesso, chi lo ha approvato, quando è stato configurato, quali revisioni ha superato e quando è stato revocato.
L’accountability non richiede soltanto che il privilegio sia corretto, ma anche che la ragione della sua correttezza sia ricostruibile.
Tra le possibili prove da conservare e mostrare in caso sia necessario: matrice ruoli–applicazioni–privilegi, inventario delle utenze e degli account privilegiati, workflow di approvazione, data di scadenza degli accessi temporanei esiti delle ricertificazioni, registrazioni di attivazione e revoca, elenco delle eccezioni e relative motivazioni, log degli accessi privilegiati, report sugli account inattivi, generici o privi di responsabile.
Framework e standard tecnici possono aiutare a colmare dei vuoti.
Gli accessi devono seguire il lavoro
La gestione delle autorizzazioni non termina quando viene creato un account.
Comincia in quel momento e continua attraverso trasferimenti, sostituzioni, promozioni, progetti temporanei e cessazioni.
Un accesso può essere stato attribuito legittimamente e diventare sproporzionato con il trascorrere del tempo.
Per questo la conformità non dipende soltanto dalla correttezza iniziale del profilo, ma dalla capacità dell’organizzazione di mantenerlo coerente con le funzioni effettive.
Le autorizzazioni non diventano obsolete perché scade una password, ma quando cambia il lavoro e il sistema non se ne accorge.
Il punto di incontro tra IAM e protezione dei dati si trova esattamente qui: trasformare ogni cambiamento organizzativo in una revisione tecnica, ogni privilegio in una decisione motivata e ogni accesso in un’operazione attribuibile.
Solo così il principio del minimo privilegio smette di essere una formula di policy e diventa una misura concreta di accountability.
Partecipa alla community