Come gestire onboarding e offboarding dei dipendenti per evitare account “zombie” attivi?

La scena è un classico in quasi ogni azienda: un dipendente lascia l’organizzazione e il responsabile HR, con le migliori intenzioni, chiede al reparto IT di “lasciare la sua casella email attiva ancora per un po’, per controllare se arrivano messaggi importanti”. Sembra un’azione innocua, quasi doverosa per garantire la continuità operativa. In realtà, è il primo passo verso la creazione di un “account zombie”, una porta di accesso dimenticata che rappresenta una vulnerabilità di sicurezza e una non conformità con il GDPR.

Molti credono che per risolvere il problema basti una checklist di offboarding. Sebbene utile, una semplice lista non affronta la radice del problema: l’assenza di un processo di governance dell’identità digitale integrato e automatizzato. Il problema non è la mancanza di strumenti, ma la disconnessione tra le funzioni HR (che gestiscono il ciclo di vita del dipendente) e l’IT (che gestisce gli accessi). Questa disconnessione crea un “debito tecnico-organizzativo” che si accumula nel tempo, lasciando l’azienda esposta a rischi enormi.

Ma se la vera soluzione non fosse aggiungere più controlli manuali, ma ingegnerizzare un processo a prova di errore? Questo articolo non si limiterà a elencare cosa fare, ma spiegherà come strutturare un sistema di governance del ciclo di vita dell’utente che trasformi l’onboarding e l’offboarding da una serie di compiti reattivi a un flusso proattivo e sicuro. Analizzeremo come il Role-Based Access Control (RBAC) può eliminare le autorizzazioni eccessive, come gestire correttamente la disattivazione degli account secondo le direttive del Garante Privacy e quali tecnologie, dal SSO al passwordless, possono blindare l’ecosistema aziendale.

In questa guida, affronteremo passo dopo passo gli elementi chiave per costruire un framework di gestione degli accessi robusto e conforme. Dalla definizione dei ruoli alla revisione periodica, esploreremo le best practice e gli strumenti per garantire che ogni identità digitale sia gestita in modo sicuro durante tutto il suo ciclo di vita in azienda.

Sommario: Gestione del ciclo di vita degli accessi aziendali

Role-Based Access Control: come smettere di dare permessi “Admin” a tutti per comodità

Il peccato originale della gestione accessi è la pigrizia mascherata da efficienza: assegnare permessi di amministratore o privilegi elevati a un nuovo dipendente “perché così può lavorare subito”. Questa pratica viola il principio del minimo privilegio (PoLP), una regola fondamentale della sicurezza informatica secondo cui un utente deve avere accesso solo ed esclusivamente alle risorse necessarie per svolgere le sue mansioni. L’implementazione del Role-Based Access Control (RBAC) è la soluzione strutturale a questo problema. Non si tratta di limitare le persone, ma di ingegnerizzare un sistema in cui i permessi sono legati al ruolo aziendale, non all’individuo.

In una PMI italiana, questo significa mappare i profili definiti dal Contratto Collettivo Nazionale di Lavoro (CCNL) — come quadri, impiegati, agenti — a specifici set di autorizzazioni. Un impiegato dell’ufficio acquisti non ha bisogno di accedere alle cartelle del marketing, così come un tecnico non dovrebbe poter visualizzare i dati della contabilità. Definire questi ruoli a priori trasforma l’onboarding da un processo manuale e soggetto a errori a un’operazione quasi automatica: al nuovo assunto viene assegnato un ruolo, e con esso eredita automaticamente e solo i permessi corretti.

Come mostra la visualizzazione di una matrice di accesso, ogni livello organizzativo corrisponde a un set di “chiavi” diverso. L’obiettivo dell’RBAC è formalizzare questa struttura, rendendola applicabile e verificabile a livello di sistema. Questo non solo migliora drasticamente la sicurezza, riducendo la superficie d’attacco, ma semplifica anche gli audit e garantisce la conformità con normative come il GDPR, che impone un controllo rigoroso su chi accede ai dati personali.

L’errore di lasciare l’email attiva al dipendente licenziato per “controllare se arrivano messaggi”

Lasciare attiva la casella di posta di un ex dipendente è una delle pratiche più rischiose e diffuse. Sebbene l’intento sia quello di non perdere comunicazioni importanti, le implicazioni in termini di sicurezza e privacy sono enormi. Un account attivo è una potenziale backdoor, e la consultazione della posta di un ex collaboratore, anche da parte del datore di lavoro, può configurarsi come un trattamento illecito di dati personali. Il Garante per la protezione dei dati personali è stato molto chiaro su questo punto.

I programmi e servizi informatici per la gestione della posta elettronica possono raccogliere, per impostazione predefinita, in modo preventivo e generalizzato, i metadati relativi all’utilizzo degli account di posta elettronica in uso ai dipendenti.

– Garante per la protezione dei dati personali, Provvedimento del 6 giugno 2024

La procedura corretta è molto diversa e deve essere formalizzata. Al momento della cessazione del rapporto, la casella email deve essere immediatamente disattivata. Si deve impostare un risponditore automatico che informi i mittenti che l’indirizzo non è più attivo e fornisca un contatto alternativo (ad esempio, un indirizzo generico come info@azienda.it). Questa misura è cruciale perché, secondo il provvedimento del Garante Privacy del 6 giugno 2024, i metadati delle email possono essere conservati per un massimo di 21 giorni. Lasciare un account attivo espone l’azienda a non conformità. La soluzione non è “controllare”, ma reindirizzare il flusso di comunicazione su canali aziendali ufficiali e impersonali, disattivando l’accesso individuale.

Review periodica: come scoprire chi ha ancora accesso a cartelle che non usa da 2 anni

Gli accessi non si accumulano solo con gli ex dipendenti. Il “permission creep” o slittamento dei permessi è un fenomeno insidioso che avviene quando i dipendenti cambiano ruolo all’interno dell’azienda, accumulando nuovi accessi senza che i vecchi, ormai inutili, vengano revocati. Il risultato è che dopo pochi anni, molti collaboratori hanno privilegi di accesso a dati e sistemi che non toccano da tempo, aumentando inutilmente la superficie di attacco. Secondo il Ponemon Institute, quasi il 25% dei dipendenti ha ancora accesso ai sistemi aziendali dopo aver lasciato l’azienda, ma il problema degli accessi obsoleti interni è altrettanto grave.

L’unica soluzione a questo problema è un processo di revisione periodica degli accessi (access review). Non è un’attività da fare “quando c’è tempo”, ma un processo di governance obbligatorio, la cui frequenza dipende dalla criticità dei dati trattati, come indicato anche nelle linee guida sulla sicurezza dei dati.

Questa revisione non deve essere un’operazione manuale e titanica. Strumenti moderni di Identity and Access Management (IAM), sia on-premise che cloud, permettono di automatizzare campagne di certificazione in cui i manager di linea devono attivamente confermare o revocare gli accessi per i membri del loro team. I report generati da questi strumenti evidenziano immediatamente gli account “dormienti” o i permessi non utilizzati, permettendo una pulizia mirata e documentata.

Active Directory vs Cloud IdP: quale scegliere per un’azienda con molti lavoratori remoti?

Per decenni, Microsoft Active Directory (AD) on-premise è stato il cuore della gestione delle identità aziendali. Tuttavia, con la diffusione massiccia del lavoro remoto e l’adozione di applicazioni SaaS, questo modello sta mostrando i suoi limiti. Per un’azienda moderna, con molti collaboratori esterni e lavoratori da remoto, la domanda non è più “se” migrare al cloud, ma “come”. Le soluzioni di Identity Provider (IdP) in cloud, come Azure Active Directory (ora Entra ID), Okta o altri, offrono una flessibilità e una sicurezza perimetrale che l’AD tradizionale fatica a garantire.

Il contesto italiano lo conferma: secondo l’ISTAT, nel 2024 il 70,2% delle PMI ha raggiunto un livello base di digitalizzazione, con una spinta notevole verso i servizi cloud per gestire una forza lavoro sempre più distribuita, che include non solo dipendenti ma anche un vasto ecosistema di partite IVA e consulenti. Un IdP cloud permette di gestire tutte queste identità da un’unica console, applicando policy di accesso condizionale (es. “richiedi l’autenticazione a più fattori se ti connetti da una rete non aziendale”) e integrando facilmente centinaia di applicazioni cloud con un unico set di credenziali.

La scelta non è necessariamente un aut-aut. Molte aziende italiane optano per un ambiente ibrido, sincronizzando il loro Active Directory locale con un IdP cloud come Azure AD. Questo approccio consente di mantenere il controllo sulle risorse on-premise, estendendo al contempo la gestione delle identità al mondo cloud. L’infrastruttura ibrida, come rappresentato nell’immagine, unisce il meglio dei due mondi, offrendo un ponte sicuro tra le applicazioni legacy e i moderni servizi SaaS.

Account di servizio: perché non devono mai avere password che non scadono (e come gestirle)

Nascosti nell’infrastruttura IT, gli account di servizio sono utenti non umani utilizzati da applicazioni, script o servizi per interagire con altre parti del sistema (es. un’applicazione che deve leggere un database). La loro più grande vulnerabilità risiede in una pratica terribilmente comune: configurarli con una password che non scade mai “per non interrompere il servizio”. Questo crea un punto debole permanente e altamente privilegiato, un obiettivo primario per gli aggressori.

Questa pratica non è solo una cattiva abitudine, ma una chiara violazione dei principi normativi. Secondo un’interpretazione consolidata del GDPR, un account di servizio con privilegi elevati e una password statica rappresenta una palese negligenza. Va contro i principi di “security by design” (Art. 25) e non rispetta l’obbligo di adottare misure di sicurezza adeguate (Art. 32). Se questo account venisse compromesso, le conseguenze legali e finanziarie per l’azienda potrebbero essere devastanti.

Fortunatamente, esistono alternative moderne per eliminare completamente le password statiche per questi account. La gestione delle credenziali si è evoluta e offre soluzioni robuste per ogni scenario:

• Group Managed Service Accounts (gMSA) in ambiente Windows Server, le cui password sono gestite e ruotate automaticamente da Active Directory.
• Azure Managed Identities per le risorse in cloud, che consentono a un servizio Azure di autenticarsi ad altri servizi senza bisogno di alcuna credenziale nel codice.
• IAM Roles in ambienti come AWS, che forniscono permessi temporanei alle applicazioni senza dover gestire chiavi a lungo termine.
• Vaulting di credenziali con strumenti come HashiCorp Vault, che centralizzano e gestiscono dinamicamente i segreti.

La gestione moderna degli account di servizio si basa sull’automazione e sull’eliminazione delle credenziali statiche, riducendo drasticamente il rischio associato a questi potenti ma vulnerabili componenti dell’infrastruttura.

SPID o CIE: quale integrazione è prioritaria per i servizi al cittadino?

Sebbene SPID (Sistema Pubblico di Identità Digitale) e CIE (Carta d’Identità Elettronica) siano nati per l’accesso ai servizi della Pubblica Amministrazione, il loro potenziale per il settore privato è enorme, specialmente per la gestione dell’identità dei dipendenti. Per un’azienda, poter verificare l’identità di un nuovo assunto con un sistema certificato dallo Stato offre un livello di garanzia ineguagliabile, semplificando l’onboarding e riducendo i rischi di frode. La normativa attuale, inoltre, ha reso questo processo accessibile anche alle imprese private.

Grazie alla figura dell’Aggregatore di servizi, un soggetto autorizzato come InfoCert, un’azienda privata può integrare l’autenticazione tramite SPID o CIE nei propri sistemi (es. portale HR, accesso alla rete) senza dover affrontare il complesso iter di accreditamento presso AgID. Questo è particolarmente utile in settori con alto turnover o dove è richiesta una forte verifica dell’identità. Ma quale dei due sistemi scegliere?

La decisione dipende da un’analisi costi-benefici e dal livello di sicurezza richiesto. Entrambi offrono un’identità forte, ma presentano differenze in termini di diffusione, costi e tempi di integrazione.

Per molte aziende, SPID rappresenta la scelta più pragmatica per un’implementazione rapida e a costi contenuti, offrendo già un livello di sicurezza molto elevato (Livello 2). La CIE, d’altro canto, offre il massimo livello di sicurezza possibile ed è la scelta d’elezione per contesti che trattano dati estremamente sensibili e richiedono una firma elettronica avanzata.

SSO (Single Sign-On): come unificare l’accesso tra app locali e cloud

Un dipendente medio utilizza decine di applicazioni diverse ogni giorno: il CRM, il software di contabilità locale, la suite di produttività in cloud, il portale HR. Gestire una password diversa per ogni servizio non è solo frustrante per l’utente, ma è anche un incubo per la sicurezza. Gli utenti tendono a usare password deboli e a riciclarle, aprendo la porta a violazioni a catena. La soluzione a questa frammentazione è il Single Sign-On (SSO).

Il SSO è una tecnologia che permette a un utente di autenticarsi una sola volta e accedere a più applicazioni e servizi senza dover inserire nuovamente le credenziali. L’implementazione di un sistema SSO centralizzato, come Azure AD o Okta, non solo migliora drasticamente l’esperienza utente, ma rafforza enormemente la sicurezza. Centralizzando l’autenticazione, l’IT può imporre policy di sicurezza robuste, come l’autenticazione a più fattori (MFA), in un unico punto. Questa centralizzazione ha un impatto misurabile: i dati ISTAT del 2024 mostrano una riduzione dal 22,1% al 19,8% degli attacchi informatici gravi nelle imprese tra 50 e 249 addetti che hanno adottato misure di sicurezza avanzate.

La vera sfida per molte PMI italiane è integrare in un sistema SSO non solo le moderne app SaaS, ma anche le applicazioni legacy on-premise, come gestionali storici (es. TeamSystem) o software HR locali (es. Zucchetti). Fortunatamente, esistono soluzioni tecniche per colmare questo divario:

• Utilizzare connettori basati su standard come SAML o OIDC per federare l’identità con le applicazioni che li supportano.
• Implementare soluzioni come Azure AD Application Proxy, che agiscono come un “ponte” per pubblicare in modo sicuro applicazioni web interne e renderle accessibili tramite l’IdP cloud.
• Configurare hub di log centralizzati per raccogliere gli eventi di autenticazione da tutte le applicazioni, garantendo una tracciabilità completa per la conformità GDPR.

Unificare gli accessi tramite SSO è un passo fondamentale per creare un ambiente di lavoro moderno, sicuro e produttivo.

Passwordless in azienda: l’impronta digitale o il volto sono davvero più sicuri della password?

L’idea di abbandonare completamente le password in favore di metodi biometrici come l’impronta digitale o il riconoscimento facciale sta guadagnando sempre più terreno. Ma questa tecnologia è davvero più sicura? La risposta è sì, a patto che sia implementata correttamente secondo standard moderni. La paura principale è che i dati biometrici (l’impronta, l’immagine del volto) vengano inviati e archiviati su un server, dove potrebbero essere rubati. Tuttavia, non è così che funzionano le soluzioni enterprise sicure.

Come spiega la documentazione di Microsoft Security, standard come FIDO2 e Windows Hello for Business non trasmettono mai i dati biometrici attraverso la rete. L’impronta o il volto vengono utilizzati esclusivamente in locale, sul dispositivo dell’utente (PC o smartphone), per sbloccare una chiave crittografica privata archiviata in un chip sicuro (TPM). È questa chiave, unica e protetta, che viene poi utilizzata per autenticare l’utente sul server. In questo modo, il dato biometrico non lascia mai il dispositivo, eliminando il rischio di furto su larga scala.

Tuttavia, l’adozione della biometria in azienda richiede cautela e una rigorosa aderenza alla normativa sulla privacy. L’uso improprio di questi dati può portare a conseguenze legali significative. Non è un caso che il Garante Privacy sanzioni l’uso di impronte digitali per la rilevazione delle presenze quando non sono state adottate garanzie adeguate e non è stata condotta una valutazione d’impatto (DPIA). La chiave è utilizzare sistemi che processano i dati biometrici solo localmente, come descritto sopra, e che sono progettati con i principi di privacy by design.

Per trasformare questi principi in un processo operativo, il primo passo è avviare un audit completo degli accessi attuali per identificare le falle e definire una roadmap chiara. Valutare ora la soluzione di governance più adatta alle vostre esigenze specifiche è l’azione strategica per proteggere la vostra azienda.