Revoca degli accessi quando un dipendente lascia l'azienda

Quando una persona lascia l'azienda, gli accessi vanno revocati tutti, in un ordine preciso e con una traccia scritta: prima l'identità centrale (account, posta, rete privata virtuale — VPN), poi le applicazioni gestite dall'azienda, infine gli accessi presso fornitori e servizi esterni. La procedura che spesso manca non è la lista — quasi tutti ce l'hanno, almeno a mente — ma la verifica successiva: chi controlla, una settimana dopo, che non sia rimasto nulla di attivo?

Gli account dimenticati: dove si nascondono

La revoca dell'account principale è la parte facile: è visibile, ha un proprietario chiaro e spesso è richiesta da più parti. I problemi nascono altrove. Gli accessi dimenticati si nascondono tipicamente in quattro posti:

• Applicazioni con account locali. Il gestionale del magazzino, il software di progettazione, il pannello del sito web: sistemi che non passano dalla directory centrale e hanno utenze proprie.
• Portali dei fornitori. L'accesso al portale ordini, alla piattaforma di assistenza del fornitore IT, alla console di un servizio cloud: registrati a nome della persona, non dell'azienda.
• Gruppi e deleghe «ereditate». L'appartenenza a gruppi con privilegi cresciuti nel tempo, la delega sulla casella del capo, la firma digitale condivisa.
• Dispositivi e app personali. Il telefono registrato per l'autenticazione a più fattori, l'app delle approvazioni, la mail configurata sul cellulare privato.

Il principio di riferimento è quello descritto dalla pubblicazione NIST SP 800-207, Zero Trust Architecture: nessuna fiducia implicita e una decisione di autorizzazione per ogni accesso a una risorsa. Un account che resta attivo «perché tanto non lo usa più nessuno» è esattamente la fiducia ereditata che quel modello invita a eliminare: finché l'accesso esiste, esiste la possibilità che venga usato, dalla persona o da chiunque ne ottenga il controllo.

La checklist operativa di revoca

La sequenza conta: chiudere prima l'identità centrale impedisce alla persona di ostacolare, anche involontariamente, le revoche successive. Adatta questa lista alla tua realtà e assegna un responsabile a ogni voce.

Il passo 5 è quello che quasi nessuna procedura prevede, ed è quello che trasforma una lista di buone intenzioni in un processo verificabile. Se cerchi uno strumento per il controllo di privilegi e account, la capacità di supportare proprio questa verifica è un criterio da mettere in cima alla griglia.

Le eccezioni temporanee: chi approva e come scadono

Esistono casi legittimi in cui un accesso resta attivo oltre l'uscita: il consulente che deve consegnare documentazione, il dipendente che passa a collaborazione esterna, la casella che deve restare leggibile per un contenzioso. Il problema non è l'eccezione, è l'eccezione senza regole. Tre condizioni minime:

• Approvazione nominativa. Una persona con il ruolo per deciderlo — tipicamente il responsabile IT insieme a chi gestisce il personale — approva l'eccezione per iscritto, con motivazione.
• Perimetro e scadenza. L'eccezione vale per sistemi specifici e fino a una data: non «fino a quando serve». Alla scadenza, l'accesso si chiude o si rinnova con una nuova approvazione. Lo stesso schema vale per le abilitazioni temporanee concesse a persone ancora in forza.
• Registro delle eccezioni attive. L'elenco delle eccezioni è esso stesso un oggetto da revisione periodica: quante sono, da quanto tempo, chi le ha approvate.

Per i dispositivi personali — il telefono con l'app aziendale o il token di autenticazione — serve una procedura di revoca dedicata, che tratti il dispositivo come un accesso da chiudere e sostituire, non come un ricordo da cancellare. Ne parliamo nell'articolo sulla revoca dell'accesso all'app da un telefono.

Esempio illustrativo: l'uscita del venerdì

Esempio illustrativo. Lo scenario seguente è inventato a scopo dimostrativo: non descrive un'azienda o una persona reale.

Venerdì pomeriggio, un'impiegata dell'amministrazione di una piccola azienda termina il rapporto. Il responsabile IT segue la checklist: alle 17 disattiva l'account della directory, la mail e la VPN; poi chiude gestionale e cartelle condivise; infine invia la richiesta di chiusura al fornitore del portale ordini. Sembra tutto fatto.

Alla verifica di chiusura, la settimana successiva, emergono due dimenticanze. La prima: l'account sul portale ordini non è stato chiuso dal fornitore, perché la richiesta era arrivata a un indirizzo generico. La seconda: la persona era ancora nel gruppo «amministratori condominio sede» — un gruppo dimenticato da tutti, eredità di una copertura temporanea di due anni prima — che dava accesso al pannello dei cancelli automatici.

Nessuna delle due dimenticanze è grave di per sé, e nessuna indica malafede. Ma entrambe mostrano il punto debole del processo manuale: senza una verifica incrociata, e senza qualcuno o qualcosa che segnali gli accessi rimasti attivi, la procedura si fida della completezza della memoria. Nell'esempio, la correzione è organizzativa prima che tecnica: il portale ordini entra nell'elenco dei fornitori con procedura nota, il gruppo dei cancelli ottiene un proprietario e una revisione periodica.

Il monitoraggio continuo come rete di sicurezza

Anche la checklist migliore può fallire su un dettaglio. Per questo il controllo continuo funziona da rete di sicurezza: non sostituisce la procedura, ma segnala ciò che la procedura ha mancato. In OverZeus tre agenti coprono questo flusso:

• Athena controlla identità, gruppi e privilegi, e mette in evidenza le variazioni da verificare. Nel contesto di un'uscita, può segnalare gli accessi che risultano ancora attivi per la persona uscita nelle fonti collegate: gruppi dimenticati, appartenenze residue, autorizzazioni che nessuno ha revocato.
• Hermes porta la segnalazione nell'app dei responsabili, spiega le opzioni e raccoglie la decisione. Vale la regola dichiarata del progetto: l'assenza di risposta non è un'autorizzazione — se nessuno decide, l'intervento non parte.
• Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti: chi ha approvato l'eccezione, quando è scaduta, cosa è stato verificato alla chiusura. Se una modifica non ha un riferimento autorizzativo, segnala la lacuna invece di inventare una ricostruzione. È il materiale che serve quando un controllo successivo — interno o di audit sul controllo degli accessi — chiede conto di come è stata gestita quell'uscita.

Le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente: quali sistemi Athena può leggere nel tuo caso va verificato in fase di progetto, non dato per scontato.

Una procedura che si verifica da sola non esiste: serve il passo in più

Riassumendo: revoca in ordine (identità centrale, applicazioni, gruppi e deleghe, fornitori), verifica di chiusura dopo una settimana eseguita da una persona diversa, eccezioni solo con approvazione nominativa, perimetro e scadenza. Il tutto con una traccia scritta, perché la domanda «sei sicuro che non sia rimasto nulla?» prima o poi arriva — da un socio, da un cliente importante, da un auditor — e la risposta migliore è un registro, non un ricordo.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus