Identità e ruoli nella gestione documentale: SSO, IAM, gruppi applicativi, deleghe e tracciamento nella PA

In un ente pubblico complesso, la gestione documentale non dipende solo da documenti, fascicoli, workflow e conservazione. Dipende anche da una domanda molto semplice, ma spesso sottovalutata: chi può fare cosa, su quali documenti, in quale momento e con quale tracciabilità?

È qui che entrano in gioco identità digitali, SSO, IAM, gruppi applicativi, ruoli, deleghe e tracciamento.

Il tema sembra tecnico, ma non lo è soltanto. Se un utente vede documenti che non dovrebbe vedere, se una delega resta attiva troppo a lungo, se un gruppo applicativo è troppo ampio, se un profilo consente modifiche non necessarie, se un passaggio viene fatto con un’utenza generica o se i log non permettono di ricostruire chi ha fatto cosa, il problema non riguarda solo l’IT. Riguarda governance, responsabilità, sicurezza, privacy, fascicolo informatico e affidabilità del procedimento.

Per Regioni, ASL, Università, enti multi-sede e organizzazioni pubbliche articolate, identità e ruoli sono una delle fondamenta della gestione documentale. Senza un modello chiaro, anche il miglior workflow diventa fragile.

Questo contenuto prosegue il blocco dedicato a integrazioni e architettura, dopo il pillar su integrazione tra protocollo, fascicolo, ERP, sistemi gestionali e archivi. Lì il tema era come collegare sistemi diversi senza perdere contesto documentale. Qui il focus è più specifico: come evitare che l’integrazione tra sistemi produca accessi incoerenti, responsabilità opache e tracciamenti incompleti.

Perché identità e ruoli sono un tema documentale

In molti enti, la gestione delle identità viene trattata come un tema infrastrutturale: account, credenziali, gruppi, directory, autenticazione, autorizzazioni.

Tutto corretto. Ma nel ciclo documentale l’identità ha un impatto più profondo.

Serve a capire:

• chi ha creato o acquisito un documento;
• chi lo ha classificato;
• chi lo ha fascicolato;
• chi lo ha visto;
• chi lo ha modificato;
• chi lo ha validato;
• chi lo ha trasmesso;
• chi lo ha pubblicato;
• chi ha effettuato un oscuramento;
• chi ha gestito un’anomalia;
• chi ha autorizzato una delega;
• chi ha operato su un fascicolo sensibile.

Se queste informazioni non sono riconducibili a identità, ruoli e responsabilità chiare, il sistema documentale perde una parte della sua affidabilità.

La domanda quindi non è solo: “l’utente riesce ad accedere?”
La domanda corretta è: l’accesso è coerente con il ruolo, il procedimento, il fascicolo e il livello di rischio?

SSO: semplificare l’accesso senza perdere controllo

Il Single Sign-On, o SSO, può semplificare molto l’esperienza degli utenti. Permette di accedere a più sistemi con un’unica identità e riduce la proliferazione di credenziali separate.

In un contesto documentale, però, il valore dello SSO non è solo comodità. È anche governo.

Un modello SSO ben progettato aiuta a:

• ridurre account duplicati;
• velocizzare onboarding e offboarding;
• collegare identità utente a ruoli organizzativi;
• rafforzare autenticazione e controllo accessi;
• semplificare tracciamento e audit;
• ridurre il rischio di credenziali dimenticate o non dismesse.

Ma lo SSO non risolve tutto.

Autenticare un utente significa sapere chi è. Autorizzarlo correttamente significa decidere cosa può fare. Sono due livelli diversi.

Un ente può avere SSO ben configurato ma permessi documentali mal progettati. In quel caso l’utente entra in modo sicuro, ma poi vede o modifica più di quanto dovrebbe.

Per questo SSO e ruoli applicativi devono essere progettati insieme.

IAM: il ciclo di vita dell’identità

IAM significa Identity and Access Management. In pratica, è l’insieme di regole, processi e strumenti che governano il ciclo di vita delle identità e degli accessi.

Nel documentale, un buon modello IAM deve rispondere a domande molto concrete:

• come viene creato un nuovo utente;
• chi approva il suo accesso;
• quali ruoli riceve;
• quali gruppi applicativi vengono assegnati;
• cosa succede quando cambia ufficio;
• cosa succede quando assume un incarico temporaneo;
• cosa succede quando termina il rapporto o cambia funzione;
• chi rivede periodicamente i suoi permessi;
• come vengono gestite le utenze tecniche;
• come vengono gestiti utenti esterni, consulenti o fornitori.

Il problema più frequente non è l’assenza di regole. È la stratificazione.

Una persona entra in un ufficio, riceve permessi. Poi cambia servizio, mantiene parte dei permessi precedenti. Poi riceve una delega temporanea. Poi entra in un gruppo di progetto. Poi quel gruppo non viene più rivisto. Dopo alcuni anni l’utente ha un profilo che non corrisponde più al suo ruolo reale.

Questo è uno dei rischi più comuni negli enti complessi.

Gruppi applicativi: utili, ma pericolosi se troppo ampi

I gruppi applicativi semplificano la gestione degli accessi. Invece di assegnare permessi utente per utente, si creano gruppi collegati a ruoli, uffici, strutture o funzioni.

Il problema nasce quando i gruppi diventano troppo generici.

Esempi tipici:

• “ufficio amministrativo” con permessi troppo estesi;
• “segreteria” che vede fascicoli non pertinenti;
• “responsabili” con funzioni di modifica non necessarie;
• “operatori protocollo” con visibilità eccessiva su documenti sensibili;
• gruppi creati per urgenza e mai rimossi;
• gruppi ereditati da vecchi sistemi e non più verificati.

Un buon modello dovrebbe distinguere almeno:

• gruppi organizzativi;
• gruppi funzionali;
• gruppi di procedimento;
• gruppi temporanei;
• gruppi di sola lettura;
• gruppi con poteri dispositivi;
• gruppi amministrativi;
• gruppi tecnici.

Il principio guida resta quello del least privilege: ogni gruppo deve avere solo i permessi necessari. È lo stesso criterio che regge la security-by-design nella gestione documentale.

Se un gruppo esiste “per comodità”, ma concede visibilità e azioni eccessive, è un rischio.

Ruoli applicativi: non coincidono sempre con l’organigramma

Un altro errore frequente è pensare che i ruoli applicativi coincidano automaticamente con i ruoli organizzativi.

Non è così.

Un dirigente può dover approvare alcuni atti, ma non necessariamente modificare documenti operativi. Un operatore di protocollo può registrare documenti, ma non vedere fascicoli riservati oltre il necessario. Un referente di dipartimento può gestire alcune pratiche, ma non accedere a tutto ciò che riguarda il dipartimento. Un amministratore di sistema può gestire configurazioni, ma non dovrebbe operare sui contenuti senza controlli adeguati.

Nel documentale, i ruoli applicativi dovrebbero essere progettati in base alle azioni reali:

• vedere;
• creare;
• modificare;
• classificare;
• fascicolare;
• assegnare;
• validare;
• approvare;
• firmare;
• trasmettere;
• pubblicare;
• oscurare;
• esportare;
• annullare;
• amministrare;
• consultare log;
• gestire anomalie.

Queste azioni non hanno tutte lo stesso livello di rischio. Un modello maturo le distingue.

Deleghe: il punto in cui molti modelli si indeboliscono

Le deleghe sono indispensabili. Negli enti reali ci sono assenze, sostituzioni, urgenze, incarichi temporanei, gruppi di lavoro, commissioni, progetti, fasi istruttorie.

Il problema non è avere deleghe. Il problema è non governarle.

Una delega documentale dovrebbe indicare:

• chi delega;
• chi riceve la delega;
• per quale funzione;
• su quali documenti o fascicoli;
• per quale periodo;
• con quali limiti;
• chi approva;
• chi viene informato;
• quando viene revocata;
• quali azioni compiute in delega vengono tracciate.

Senza questi elementi, la delega rischia di diventare un accesso permanente mascherato da necessità temporanea.

Il caso più delicato è la delega su azioni dispositive: approvazione, pubblicazione, trasmissione, annullamento, gestione di documenti sensibili. Qui la tracciabilità deve essere molto chiara.

Deve essere sempre distinguibile:

• chi ha operato materialmente;
• se ha operato per sé o in delega;
• per conto di chi;
• in quale momento;
• con quale autorizzazione.

Utenze tecniche e amministrative: il rischio invisibile

Le utenze tecniche, di servizio o amministrative sono spesso necessarie per integrazioni, manutenzione, automazioni o gestione applicativa. Ma sono anche uno dei punti più delicati.

Il rischio nasce quando queste utenze:

• hanno privilegi troppo ampi;
• sono condivise tra più persone;
• non hanno scadenza;
• non sono monitorate;
• non sono collegate a una responsabilità chiara;
• operano sui contenuti senza log leggibili;
• vengono usate per attività ordinarie invece che tecniche.

In un sistema documentale, le utenze tecniche devono essere ridotte, documentate e controllate.

Per ogni utenza tecnica bisognerebbe sapere:

• a cosa serve;
• chi ne è owner;
• quali permessi ha;
• quali sistemi usa;
• quali operazioni può fare;
• quali log produce;
• quando viene rivista;
• se può accedere ai contenuti documentali.

Le utenze tecniche non dovrebbero mai diventare scorciatoie per aggirare il modello dei ruoli.

Tracciamento: sapere chi ha fatto cosa, davvero

Un buon sistema documentale deve permettere di ricostruire le azioni rilevanti.

Il tracciamento dovrebbe coprire almeno:

• login e accessi;
• consultazione di documenti sensibili;
• creazione;
• modifica;
• classificazione;
• fascicolazione;
• cambio stato;
• assegnazione;
• validazione;
• approvazione;
• firma;
• pubblicazione;
• oscuramento;
• esportazione;
• trasmissione;
• annullamento;
• operazioni in delega;
• operazioni amministrative sui profili.

Il punto non è registrare tutto senza criterio. Il punto è registrare ciò che serve per audit, responsabilità, sicurezza, privacy e ricostruibilità del procedimento.

Questo si collega direttamente al tema del fascicolo informatico difendibile: senza log utili, il fascicolo non racconta davvero la storia del procedimento. Ed è anche il materiale su cui si basa un audit di sicurezza documentale.

Accessi ereditati tra sistemi integrati

Quando il sistema documentale dialoga con ERP, sistemi verticali, workflow, repository o archivi, emerge un problema ulteriore: cosa succede agli accessi tra sistemi?

Un utente autorizzato in un sistema potrebbe non dover vedere lo stesso documento in un altro. Un gestionale potrebbe mostrare un allegato proveniente dal documentale senza applicare gli stessi permessi. Un repository potrebbe ricevere copie consultabili da gruppi più ampi. Un’integrazione potrebbe usare un’utenza tecnica con privilegi eccessivi.

Ogni integrazione dovrebbe chiarire:

• quale identità viene usata;
• quali permessi vengono ereditati;
• quali permessi vengono ricalcolati;
• quali log restano nei sistemi coinvolti;
• come vengono gestiti errori o disallineamenti;
• chi è responsabile del controllo;
• come si evitano esposizioni non previste.

L’interoperabilità documentale non può ignorare l’IAM. Altrimenti il rischio si sposta da un sistema all’altro. Le Linee guida AgID danno il quadro di riferimento su identità e accesso ai servizi, ma il modello dei ruoli applicativi resta una scelta progettuale dell’ente.

Una mini-RACI per identità e ruoli

Un modello efficace deve chiarire responsabilità.

Una possibile impostazione:

Attività	Responsible	Accountable	Consulted	Informed
Creazione utente	IT / IAM	Responsabile struttura	Gestione documentale se ruoli documentali	Utente / referente
Assegnazione ruolo documentale	IT / amministratore applicativo	Responsabile funzione documentale o struttura competente	RTD / sicurezza	Utente
Revisione gruppi e permessi	IT + gestione documentale	RTD / direzione competente	DPO se dati sensibili	Responsabili struttura
Attivazione delega	Responsabile struttura	Responsabile procedimento o dirigente competente	Gestione documentale / IT	Delegato
Revoca delega	IT / amministratore applicativo	Responsabile che ha autorizzato	Gestione documentale	Utente interessato
Verifica log accessi sensibili	IT / sicurezza	Responsabile sicurezza / governance	DPO / gestione documentale	Direzione se necessario
Gestione utenze tecniche	IT	Responsabile sistemi informativi	Sicurezza / RTD	Gestione documentale se impatta contenuti

Questa tabella è solo un modello. Ogni ente deve adattarla alla propria organizzazione, con la stessa logica descritta nella matrice RACI nella PA. Ma il principio è fondamentale: gli accessi non possono essere gestiti come attività tecnica senza responsabilità organizzativa.

Errori ricorrenti da evitare

Gli errori più frequenti sono:

• profili troppo ampi;
• gruppi applicativi non rivisti;
• deleghe senza scadenza;
• utenti trasferiti che mantengono vecchi permessi;
• account cessati non disattivati tempestivamente;
• ruoli applicativi copiati da vecchi sistemi;
• utenze tecniche condivise;
• log non consultabili;
• accessi tra sistemi integrati non coerenti;
• assenza di owner per i permessi documentali.

Questi errori non sempre generano incidenti immediati. Ma indeboliscono progressivamente il sistema. Per questo il modello dei ruoli va inquadrato nella governance documentale negli enti complessi, non lasciato alla configurazione applicativa.

Un test pratico da fare subito

Scegli un procedimento sensibile, per esempio personale, gare, atti deliberativi o fascicoli con dati riservati.

Poi verifica:

• quali utenti possono accedere;
• quali gruppi applicativi sono coinvolti;
• chi può leggere;
• chi può modificare;
• chi può approvare;
• chi può esportare;
• chi può pubblicare;
• chi può agire in delega;
• quali utenze tecniche intervengono;
• quali log restano;
• cosa succede se un utente cambia ufficio.

Se le risposte non sono immediate, il modello di identità e ruoli è probabilmente troppo opaco.

Da dove partire nei prossimi 90 giorni

Un percorso realistico può essere questo.

Giorni 1-30 · Mappa ruoli, gruppi e permessi sui casi sensibili

Mappare ruoli applicativi, gruppi e permessi sui procedimenti più sensibili.

Giorni 1-30 · Individua profili troppo ampi e deleghe aperte

Individuare profili troppo ampi, gruppi obsoleti, deleghe aperte e utenze tecniche non documentate.

Giorni 31-60 · Definisci un modello minimo di ruoli

Definire un modello minimo di ruoli: lettura, modifica, approvazione, pubblicazione, amministrazione, export, consultazione log.

Giorni 31-60 · Collega i ruoli al ciclo di vita dell’identità

Collegare i ruoli documentali al ciclo di vita dell’identità: ingresso, cambio ruolo, delega, trasferimento, cessazione.

Giorni 61-90 · Imposta un riesame periodico dei permessi critici

Impostare un riesame periodico dei permessi più critici.

Giorni 61-90 · Verifica come gli accessi si ereditano tra sistemi

Verificare le integrazioni tra sistemi, controllando come vengono ereditati accessi, log e responsabilità.

L’obiettivo non è creare un modello perfetto. È ridurre le zone grigie più pericolose.

Governare accessi, deleghe e tracciabilità

Identità, ruoli, gruppi, deleghe e tracciamento sono la base silenziosa della gestione documentale. Se non sono governati, anche workflow, fascicoli e integrazioni diventano fragili.

Scopri come Docsuite Next può aiutarti a progettare accessi, ruoli documentali, deleghe e tracciabilità in modo più sicuro, coerente e sostenibile.

Domande frequenti

Perché identità e ruoli sono importanti nella gestione documentale?

Perché determinano chi può vedere, modificare, approvare, pubblicare, esportare o amministrare documenti e fascicoli. Se non sono governati, aumentano rischi e responsabilità opache.

Che differenza c’è tra SSO e IAM?

Lo SSO semplifica l’accesso con un’unica identità. L’IAM governa l’intero ciclo di vita degli accessi: creazione, modifica, revoca, gruppi, ruoli, deleghe e controlli.

Perché le deleghe sono un punto critico?

Perché spesso nascono come necessità temporanee ma restano attive troppo a lungo. Devono avere limiti, durata, autorizzazione e tracciamento.

I ruoli applicativi coincidono con l’organigramma?

Non sempre. Devono essere progettati sulle azioni reali: lettura, modifica, approvazione, pubblicazione, export, amministrazione, consultazione log e gestione anomalie.

Come verificare se i permessi sono troppo ampi?

Scegliendo procedimenti sensibili e controllando chi può accedere, modificare, esportare, pubblicare o amministrare documenti e fascicoli. Se molti utenti hanno più poteri del necessario, serve revisione.