Identity Lifecycle Automation: dal ticket manuale al provisioning zero-touch

Il problema: quando l'identità è un processo manuale

In un'organizzazione con oltre 1.000 dipendenti e turnover continuativo, la gestione manuale delle identità IT è un rischio operativo concreto. Ogni nuovo assunto richiede: creazione account, assegnazione licenze, configurazione gruppi, consegna credenziali. Ogni uscita richiede: blocco accessi, revoca licenze, rimozione gruppi, documentazione.

Quando tutto questo avviene via ticket email, i problemi sono inevitabili:

Tempi lunghi: 2-4 ore per un onboarding completo, con l'IT che diventa collo di bottiglia
Errori umani: account con permessi sbagliati, licenze dimenticate, gruppi non assegnati
Account orfani: ex dipendenti con accessi attivi per giorni o settimane dopo la fine del rapporto — il rischio di sicurezza più grave
Zero audit trail: nessuna traccia strutturata di chi ha fatto cosa, quando, e con quale esito
Configurazioni difformi: ogni operatore crea account in modo leggermente diverso

Questo articolo descrive il sistema che ho progettato e implementato per risolvere questi problemi: un'architettura end-to-end che automatizza l'intero ciclo di vita delle identità, dal trigger HR alla consegna del dispositivo, con audit trail completo e compliance GDPR/NIS2.

Architettura del sistema

Il sistema è composto da tre layer distinti che collaborano:

Due categorie di dipendenti, due percorsi

Il sistema distingue due tipologie di personale con requisiti completamente diversi:

| | GROUND (personale di terra) | CREW (personale navigante) | |---|---|---| | Tipo identità | On-premises | Cloud-only | | Directory | Active Directory + Exchange | Entra ID | | Provisioning | PowerShell via Kerberos | Microsoft Graph API | | Credenziali | Password AD + Remote Mailbox | Password cloud + TAP | | Offboarding | Disable → OU DISMISSED (Day 30) | Disable → Delete cloud (Day 30) |

Questa distinzione è fondamentale: il personale di terra mantiene identità on-prem per compatibilità con sistemi legacy, mentre il personale navigante è gestito interamente nel cloud Microsoft.

Onboarding: dal trigger HR all'account pronto

Il flusso di onboarding è completamente automatizzato e si divide in sei step sequenziali:

Step 1 — Validazione input

Il workflow riceve i dati del dipendente (nome, cognome, reparto, ruolo, responsabile) dalla coda di onboarding, alimentata da una sincronizzazione con il database HR. Il primo step valida il payload: campi obbligatori presenti, formato email corretto, esistenza del reparto nel mapping configurato. Se qualcosa non va, una notifica viene inviata al richiedente — nessun account viene creato con dati incompleti.

Step 2 — Creazione account

GROUND: uno script PowerShell crea l'account in Active Directory nella OU corretta, imposta display name, UPN, numero interno e forza il cambio password al primo accesso. L'operazione avviene via Invoke-Command con autenticazione Kerberos — il container Linux non ha cmdlet AD nativi, quindi ogni operazione passa per una sessione remota sul domain controller.

CREW: il workflow chiama Microsoft Graph API per creare l'utente direttamente su Entra ID. Subito dopo, l'utente viene aggiunto al gruppo del personale navigante.

Step 3 — Sincronizzazione identità cloud

Per il personale GROUND, il workflow attende la propagazione della sync di AD Connect verso Entra ID. Un polling sull'API Graph con retry e backoff esponenziale verifica la disponibilità dell'utente cloud prima di procedere. Solo quando l'identità è confermatamente presente in entrambi i sistemi, il flusso continua.

Step 4 — Assegnazione licenze

Tramite Microsoft Graph API viene assegnata la licenza Microsoft 365 configurata per il reparto. I profili licenza sono mappati in un nodo di configurazione aggiornabile senza modificare il workflow — basta cambiare il mapping, non riscrivere il flusso.

Step 5 — Configurazione gruppi e Teams

L'utente viene aggiunto automaticamente ai gruppi di sicurezza, distribution list e team Microsoft Teams in base al reparto di appartenenza. Il mapping reparto→gruppi è centralizzato e mantenibile.

Step 6 — Consegna credenziali e handoff

Le credenziali temporanee vengono consegnate tramite un servizio di link monouso (TTL 24h per l'utente, 7gg per l'IT) che include password e istruzioni per il primo accesso. In parallelo:

Un report riepilogativo viene inviato al team IT
Una email di notifica parte verso il responsabile del nuovo dipendente
L'email aziendale generata viene scritta nel record HR per chiudere il cerchio

Tempo medio dall'inizio alla fine: meno di 8 minuti, contro le 2-4 ore del processo manuale precedente.

Offboarding: il processo più critico

Un account attivo di un ex dipendente è un rischio di sicurezza immediato. L'offboarding è progettato con una filosofia conservativa: mai forzare, mai cancellare d'ufficio, sempre verificare prima di agire.

Day 0 — Blocco immediato

Quando un evento di leave entra nella coda, il sistema agisce entro secondi:

GROUND: script PowerShell disabilita l'account AD e lo prepara per lo spostamento nella OU di dismiss.

CREW: Graph API resetta la password casuale, revoca tutte le sessioni attive (revokeSignInSessions), disabilita l'account su Entra ID. L'accesso a tutti i servizi cloud viene interrotto immediatamente.

Prima di qualsiasi azione, lo stato dei gruppi viene salvato in un snapshot JSON — questo permette una riattivazione rapida se il dipendente torna (es. contratto a termine rinnovato).

Day 30 — Dismiss definitivo

GROUND: un job giornaliero verifica i candidati allo spostamento (disable completato + 30 giorni passati). Prima di spostare, verifica live su AD che l'account sia ancora disabilitato — se nel frattempo è stato riattivato, lo spostamento viene annullato e l'item segnalato come anomalia. L'account viene spostato in una OU dedicata che lo esclude dalla sync di Entra Connect → Microsoft cancella automaticamente identità cloud e mailbox. L'oggetto AD non viene mai cancellato: resta disabilitato a tempo indeterminato per finalità di audit.

CREW: un job giornaliero verifica i candidati alla cancellazione cloud (30 giorni da leave + 30 giorni da disable). Prima di ogni cancellazione, GET live su Entra ID per confermare che accountEnabled=false. Solo se confermato, il DELETE sposta l'oggetto nel cestino nativo di Entra ID (recuperabile per 30 giorni dal Centro amministrazione M365). Al giorno 60 totale, Microsoft esegue il purge permanente.

Riattivazione

Se un dipendente torna entro 30 giorni, il sistema ripristina automaticamente l'account dallo snapshot dei gruppi salvato al Day 0. Nessuna ricreazione, nessuna riassegnazione manuale — l'identità torna operativa con i permessi originali.

Dashboard operativa

La dashboard è una web application separata, protetta da SSO con Microsoft Entra ID e MFA obbligatorio. L'accesso è limitato a un gruppo di sicurezza nominale; ogni azione è tracciata con l'identità dell'operatore autenticato.

KPI in tempo reale

La dashboard mostra una vista aggregata che unisce dati HR, stato provisioning e asset assegnati:

Totale record in coda
Pending pronti all'esecuzione
Pending schedulati nel futuro
Completati
Errori (con dettaglio eccezione e step fallito)
Assunzioni del giorno
Dispositivi assegnati e PC preparati

Operazioni dalla dashboard

| Operazione | Descrizione | |---|---| | Assegnazione dispositivo | L'operatore inserisce il service tag del laptop; il sistema registra l'associazione con timestamp e operatore | | TAP (Temporary Access Pass) | Genera un pass monouso Entra ID per il primo accesso senza password | | Reset password | Reset sicuro con consegna credenziali via link monouso + email | | Completamento configurazione PC | Reset password + notifica IT + email al dipendente con istruzioni | | Verbale di consegna PDF | Generazione automatica del documento di consegna dispositivo, pronto per la firma |

Calcolo del risparmio

Tempo di provisioning

| Metrica | Prima (manuale) | Dopo (automatizzato) | Risparmio | |---|---|---|---| | Onboarding completo | 2-4 ore | ~8 minuti | ~95% | | Offboarding (blocco accessi) | 30-60 min | <60 secondi | ~98% | | Setup nuovo dispositivo | 3-4 ore | ~25 minuti (Autopilot) | ~85% | | Carico operativo IT | 3-4 ore/settimana | ~30 min/settimana | ~85% |

Sicurezza

| Metrica | Prima | Dopo | Miglioramento | |---|---|---|---| | Account orfani post-leave | Frequenti (giorni/settimane) | Zero dal deployment | Eliminazione totale | | Tempo revoca accessi | Ore-giorni | <60 secondi dal trigger | Riduzione critica | | Audit trail | Assente | Completo (operatore, timestamp, esito) | Tracciabilità totale | | Configurazioni difformi | Comuni | Standardizzate per reparto | Consistenza garantita |

Costo

Il sistema gira su infrastruttura esistente (VM, container Docker, licenze M365 già attive). L'unico costo aggiuntivo è il tempo di sviluppo e manutenzione — nessun costo ricorrente per software di terzi.

Compliance: GDPR e NIS2

Il sistema implementa una strategia di difesa in profondità (defense in depth) su quattro livelli indipendenti:

GDPR (Reg. UE 2016/679)

Art. 5 — Limitazione conservazione: account disabilitati e licenze revocate al termine del rapporto. Zero account orfani è un requisito di compliance prima ancora che un KPI tecnico
Art. 25 — Privacy by design: accesso dashboard limitato a gruppo nominale, utenti DB separati con permessi minimi, ogni azione registrata con identità operatore. Principio del minimo privilegio applicato a ogni livello dello stack
Art. 32 — Sicurezza del trattamento: SSO con MFA obbligatorio, nessun accesso anonimo, trasmissione cifrata TLS end-to-end
Art. 33 — Notifica violazioni: il log strutturato permette di ricostruire con precisione chi aveva accesso a cosa e in quale intervallo di tempo — informazione richiesta nelle notifiche al Garante entro 72 ore

NIS2 (Dir. UE 2022/2555)

Il settore del trasporto aereo è classificato nell'Allegato I come settore essenziale, con obblighi di sicurezza più stringenti.

Art. 21 — Gestione del rischio: il deprovisioning automatico con revoca accessi in meno di 60 secondi riduce drasticamente la finestra di esposizione post-cessazione
Gestione identità e accessi: provisioning standardizzato elimina configurazioni difformi; ogni account è nominale, tracciabile e revocabile centralmente
Registrazione e audit: il log strutturato su PostgreSQL con retention configurabile fornisce l'evidenza operativa richiesta in caso di ispezione o incident response

Resilienza e gestione errori

Il sistema è progettato per fallire in modo sicuro (fail-closed), non in modo silenzioso:

Retry con backoff esponenziale su operazioni Graph API (rate limit, timeout)
Fallback manuale: se uno step fallisce dopo i retry, l'operazione viene sospesa e inviata una notifica IT con istruzioni per intervento — nessun account viene lasciato in stato inconsistente
Idempotenza: ogni step verifica lo stato prima di agire, evitando duplicazioni in caso di riesecuzione
Rollback parziale: se l'assegnazione licenze fallisce, il workflow notifica e mantiene l'account senza licenze anziché eliminarlo
Verifica live prima di azioni distruttive: ogni offboarding verifica lo stato attuale su AD/Entra prima di procedere — se l'account è stato riattivato nel frattempo, l'azione viene annullata
TEST_MODE: un flag centralizzato permette di testare l'intero flusso senza effetti collaterali — email redirette a indirizzo di test, azioni distruttive convertite in mock

Stack tecnologico

| Componente | Tecnologia | |---|---| | Orchestrazione | n8n (immagine custom con PowerShell + Kerberos) | | Dashboard | Python Flask + Gunicorn | | Database | PostgreSQL 15 | | Autenticazione dashboard | oauth2-proxy + Microsoft Entra ID SSO | | Reverse proxy | Caddy (TLS automatico) | | Contenitori | Docker Compose | | Active Directory | PowerShell + WinRM via Kerberos | | Cloud identity | Microsoft Graph API | | Licenze e gruppi | Microsoft Graph API | | Email | Microsoft Graph API (application permissions) | | Consegna credenziali | One-time secret (link monouso TTL 24h/7gg) | | Documenti PDF | ReportLab | | Enrollment dispositivi | Microsoft Intune / Autopilot |

Estensioni del sistema

Il sistema è progettato come piattaforma estendibile. Oltre a onboarding e offboarding, gestisce:

Rollout MFA: 12 batch group (per dipartimento e ruolo), con workflow di notifica, reminder e enforcement graduato. La classificazione S1-S4 basata su metodi di autenticazione registrati e log di sign-in determina il livello di intervento
Monitoraggio certificati e secret: controllo scadenza certificati PFX e client secret delle app registration, con report operativo dettagliato (generazione nuovo secret, aggiornamento configurazione, restart, verifica)
Audit di riconciliazione HR↔AD/Entra: confronto periodico tra stato HR (attivo/disattivato) e stato reale su AD/Entra. Classificazione: MISMATCH_CRITICO (HR dice off, sistema dice on), GAP_PROVISIONING, NON_MATCHABILE, OK. Auto-remediation solo per mismatch ad alta confidenza, attraverso il workflow standard di offboarding
Monitoraggio Azure Arc: stato connessione server registrati, con classificazione per giorni di disconnessione e workflow di conferma umana per la rimozione
Provisioning vendor esterni: architettura pronta (DDL, script, dashboard, workflow) per estendere il ciclo di vita anche a identità esterne

Conclusioni

Un sistema di identity lifecycle management automatizzato non è un lusso tecnico — è un controllo di sicurezza concreto e un requisito di compliance. I benefici si misurano in tre dimensioni:

Tempo: da ore a minuti, liberando il team IT per attività a maggior valore
Sicurezza: zero account orfani, revoca accessi in secondi, audit trail completo
Compliance: evidenza operativa per GDPR, NIS2 e audit ISO 27001

La chiave del successo non è stata la tecnologia singola, ma l'approccio incrementale: partire dal flusso più critico (offboarding), validare in TEST_MODE, flip a produzione solo dopo conferma, poi espandere. Patch chirurgiche, mai riscritture complete. Backup sempre prima di modificare in produzione. E una dashboard che rende lo stato visibile — perché quello che non si vede, non si controlla.