Mappa Globale#
Cosa fa#
L'account lifecycle gestisce l'intero ciclo di vita di un account utente, dall'onboarding (provisioning) ai cambi di ruolo (modification) fino alla terminazione del rapporto (deprovisioning). Il punto critico non e' la creazione - e' la revoca immediata e completa alla fine del rapporto.
TL;DR#
Un account nasce quando un dipendente inizia, viene modificato a ogni cambio di ruolo, e deve morire il giorno stesso in cui il rapporto finisce. Il problema piu' comune: account che sopravvivono alla fine del rapporto. Questi "account orfani" sono uno dei vettori di attacco piu' sfruttati.
Provisioning#
Il provisioning e' la creazione dell'account con tutti gli accessi necessari per svolgere il proprio ruolo. Il principio guida e' il least privilege: accesso minimo necessario, niente di piu'.
In ambienti enterprise il flusso tipico parte dall'HR system e non da una richiesta IT manuale:
flowchart LR HR[HR System Contratto firmato Start date, ruolo] IDP[Identity Provider Okta, Azure AD Account creato] AD[Active Directory LDAP, OU assegnata Gruppi assegnati] APP[Applicazioni Email, Slack, GitHub VPN, SaaS tools] HR --> IDP --> AD --> APP
Privilege creep e' il rischio principale durante il provisioning di chi cambia ruolo frequentemente: ogni ruolo aggiunge permessi, ma raramente li toglie. Col tempo, un dipendente accumula accessi ben oltre il necessario.
Non delegare mai il provisioning alla persona stessa. Un utente non deve mai configurare i propri permessi. Il provisioning deve passare per un flusso approvato HR → IT.
Dev parallel: Come gestire i permessi di un'API key in un sistema SaaS multi-tenant: crei la chiave con scope minimi (read-only su un endpoint specifico), non con accesso admin globale "perche' fa prima". Il least privilege si applica sia agli account umani sia alle API key di servizio.
Modification#
La modification aggiorna i permessi quando cambia il ruolo del dipendente: promozione, cambio reparto, trasferimento.
| Evento | Azione richiesta | Rischio se non fatto |
|---|---|---|
| Promozione a manager | Aggiungere accessi manageriali, rimuovere accessi operativi precedenti | Accumulo inutile di permessi |
| Trasferimento reparto | Rimuovere accessi vecchio reparto, aggiungere nuovi | Cross-department data access non autorizzato |
| Cambio progetto | Revocare accessi repository/sistemi precedenti | Ex-contributor mantiene accesso al codice |
| Contractor → Dipendente | Aggiornare tipo account, applicare policy dipendenti | Account contractor con policy piu' deboli |
Deprovisioning#
Il deprovisioning e' la fase piu' critica per la sicurezza. Quando un dipendente lascia, ogni ora di ritardo nella revoca e' un'ora in cui un account con credenziali potenzialmente compromesse rimane attivo.
Sequenza corretta:
- Disabilitare l'account (non cancellare - serve per forensics e audit log)
- Revocare tutti i token OAuth e sessioni attive
- Revocare certificati digitali e smart card
- Rimuovere dai gruppi di sicurezza e distribution list
- Trasferire la proprieta' dei file e dati
- Cancellare l'account dopo il periodo di retention richiesto
Il deprovisioning deve avvenire lo stesso giorno della terminazione, idealmente nello stesso momento. Non "quando l'IT ha tempo". Un ex-dipendente malintenzionato puo' esportare dati, installare backdoor o sabotare sistemi nelle ore di ritardo.
Account Orfani#
Gli account orfani (orphaned accounts) sono account attivi di persone che non hanno piu' un rapporto con l'organizzazione. Sono il fallimento del deprovisioning.
| Tipo | Causa tipica | Rischio |
|---|---|---|
| Ex-dipendente | HR non ha notificato IT in tempo | Accesso non autorizzato con credenziali note |
| Ex-contractor | Fine contratto non tracciato nel sistema | Accesso prolungato a sistemi cliente |
| Account condiviso | Persona che lo gestiva ha lasciato | Nessuno sa le credenziali, nessuno puo' disabilitarlo |
| Account di test | Dev environment non pulito | Accesso a produzione via account "temporaneo" |
L'account review / recertification e' il processo periodico (trimestrale o semestrale) in cui ogni manager rivede e approva esplicitamente gli accessi dei propri riporti. Se un manager non approva un accesso entro la scadenza, viene revocato automaticamente.
Service Accounts#
I service account sono account usati da applicazioni, script e servizi automatici, non da persone. Seguono un lifecycle separato e sono spesso i piu' trascurati.
Rischi specifici:
- Non hanno un "owner" chiaramente assegnato - quando il progetto finisce, nessuno li disabilita
- Spesso configurati con password che non scadono mai (
no expiry) per non interrompere il servizio - A volte hanno permessi molto ampi per comodita' di configurazione iniziale
- Non soggetti a MFA per design (sono automatici)
Dev parallel: Come le API key nei repository: quante volte hai trovato un
.env.examplecon una chiave AWS commentata ma mai ruotata? I service account sono la versione enterprise di quella chiave dimenticata inconfig.php. La differenza: la chiave dimenticata spesso ha permessi S3 FullAccess su tutto l'account.
Just-in-Time Provisioning#
Il Just-in-Time (JIT) provisioning crea l'account automaticamente al primo accesso tramite SSO, senza intervento manuale IT. E' la forma piu' avanzata di provisioning automatizzato.
Funziona tramite il protocollo SCIM (System for Cross-domain Identity Management):
sequenceDiagram participant U as Utente (nuovo dipendente) participant SSO as Identity Provider (Okta) participant APP as Applicazione SaaS U->>SSO: Accede con le credenziali aziendali SSO->>APP: SAML/OIDC assertion + attributi utente APP->>APP: Utente esiste? No APP->>APP: Crea account con ruolo da attributi SAML APP-->>U: Accesso concesso Note over APP: Account creato JIT - senza intervento IT
Il vantaggio: ogni nuova applicazione aggiunta all'SSO provvede automaticamente gli utenti al primo accesso, senza ticket IT. Lo svantaggio: se il deprovisioning non e' automatizzato con lo stesso sistema, si crea facilmente un orphaned account.
Account Review e Recertification#
La recertification e' l'audit periodico in cui ogni manager deve certificare che i propri riporti abbiano ancora bisogno degli accessi assegnati.
| Frequenza | Applicata a |
|---|---|
| Trimestrale | Account privilegiati, admin, service account |
| Semestrale | Account standard dipendenti |
| A ogni cambio ruolo | Automatic trigger da HR system |
| Annuale | Contractor e account temporanei |
Il processo: il sistema IAM invia una notifica al manager con lista di accessi dei riporti. Il manager approva o revoca. Se non risponde entro la deadline, gli accessi vengono revocati per default (fail-safe).
Scenario Reale#
Un analista SOC nota accessi non autorizzati a sistemi interni alle 3 di notte. L'account appartiene a un ex-dipendente licenziato tre settimane prima. L'IT aveva chiuso il ticket di deprovisioning, ma aveva disabilitato l'account AD senza revocare il token OAuth della VPN aziendale - il token era valido per 30 giorni. L'ex-dipendente ha usato il token VPN ancora attivo per accedere alla rete. Fix: aggiungere la revoca esplicita di tutti i token OAuth al runbook di deprovisioning, non solo la disabilitazione AD.
Collegato a#
- identity-proofing - il proofing precede il provisioning
- privileged-access-management - PAM gestisce il lifecycle degli account privilegiati
- sso-kerberos-saml - SCIM e JIT si integrano con SSO
- zero-trust - Zero Trust richiede verifica continua, non solo al provisioning
