Automazione Provisioning e Deprovisioning Utenti

In un'organizzazione con oltre 1.000 dipendenti e turnover continuativo tipico del settore aviation, le operazioni manuali di creazione e dismissione account rappresentano un rischio operativo concreto: tempi lunghi, errori umani, account orfani con accessi residui.

In Neos Air — compagnia aerea del gruppo Alpitour World — il processo era gestito manualmente via ticket: l'IT riceveva una richiesta via email, creava l'account in Active Directory, assegnava le licenze Microsoft 365, configurava i gruppi e notificava il responsabile. La dismissione — il caso più critico dal punto di vista della sicurezza — richiedeva interventi su più sistemi senza una procedura standardizzata e senza tracciabilità centralizzata.

Progettazione e implementazione di un sistema end-to-end composto da due layer distinti:

Il primo layer è la pipeline di automazione orchestrata da n8n (immagine custom con PowerShell + Kerberos per WinRM), che gestisce l'intero ciclo di vita dell'utenza: creazione AD, sync Entra ID, assegnazione licenze M365, configurazione gruppi e Teams, notifiche e deprovisioning sicuro.

Il secondo layer è itprov, una dashboard web operativa (Python Flask + PostgreSQL + oauth2-proxy) accessibile su itprov.moonflower.it con SSO aziendale Entra ID. Permette agli operatori IT di monitorare la coda di onboarding, assegnare dispositivi, generare TAP, resettare password AD e produrre la documentazione di consegna — tutto tracciato con l'identità dell'operatore.

Il trigger del workflow è un webhook che riceve i dati dell'utente (nome, cognome, reparto, ruolo, responsabile) dal sistema HR.

Step 1 — Validazione input

n8n valida il payload: campi obbligatori, formato email, esistenza del reparto nel mapping configurato. In caso di errore viene inviata una notifica al richiedente.

Step 2 — Creazione account AD on-prem

L'immagine custom di n8n include PowerShell e il supporto Kerberos per autenticazione WinRM. 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.

Step 3 — Sincronizzazione con Entra ID

Il workflow attende la propagazione dell'AAD Connect sync (polling sull'API Graph con retry) e verifica la disponibilità dell'utente in Entra ID prima di procedere.

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 Set aggiornabile senza modificare il workflow.

Step 5 — Configurazione gruppi e Teams

L'utente viene aggiunto ai gruppi di sicurezza, distribution list e team Microsoft Teams in base al reparto.

Step 6 — Report e handoff

n8n invia automaticamente un report via email al team IT con il riepilogo di tutte le operazioni eseguite durante il provisioning. In parallelo, viene inviata un'email al responsabile del nuovo dipendente con le credenziali provvisorie e la checklist di onboarding. La email aziendale creata viene scritta nel record del dipendente nel DB HR (sync in fase di completamento).

La dismissione è il processo più critico: un account attivo di un ex dipendente è un rischio di sicurezza immediato.

Step 1 — Trigger e schedulazione

Il flusso parte da una richiesta di dismissione con data di efficacia. Se la data è futura, n8n schedula automaticamente l'esecuzione. Il responsabile IT riceve notifica con finestra di annullamento di 2 ore.

Step 2 — Blocco accesso immediato

Via Graph API: reset password casuale, revoca di tutte le sessioni attive (revokeSignInSessions), disabilitazione account Entra ID. L'accesso a tutti i servizi cloud viene interrotto in secondi.

Step 3 — Disabilitazione AD on-prem

Script PowerShell che disabilita l'account, lo sposta nella OU "Dismissed" e aggiunge una nota con data e operatore nel campo Description.

Step 4 — Rimozione licenze e gruppi

Rimozione di tutte le licenze M365 (liberando i seat), rimozione da gruppi di sicurezza, Teams e distribution list. Teams viene rimosso prima dei gruppi per evitare errori di dipendenza.

Step 5 — Report e audit trail

Al completamento del flusso, n8n genera e invia automaticamente un report via email al team IT con il riepilogo di tutte le operazioni eseguite: account disabilitato, sessioni revocate, licenze rimosse, gruppi eliminati. Ogni operazione è inoltre registrata nella tabella provisioning_audit su PostgreSQL con timestamp e operatore, disponibile per audit e ispezioni.

itprov è una web application separata (Flask + PostgreSQL) protetta da oauth2-proxy con SSO Microsoft Entra ID. L'accesso è limitato a uno specifico gruppo di sicurezza aziendale — ogni azione è tracciata con l'identità dell'operatore autenticato.

Architettura

Browser → Caddy (TLS) → oauth2-proxy (Entra ID SSO) → Flask/Gunicorn. Il database PostgreSQL è condiviso con n8n con due utenti separati a permessi granulari: sola lettura per le query della dashboard, lettura/scrittura per le operazioni. La dashboard legge da una vista dedicata che aggrega dati HR, stato provisioning e asset assegnati per ogni dipendente in onboarding.

KPI in tempo reale

La dashboard mostra: totale record, pending pronti all'esecuzione, pending schedulati nel futuro, completati, errori, assunzioni del giorno, dispositivi assegnati, PC preparati, verbali di consegna firmati.

Assegnazione dispositivo

L'operatore inserisce il service tag del laptop dalla dashboard. La richiesta viene scritta nella tabella degli asset con employee ID, data di assunzione, service tag, operatore e timestamp. Se esiste già un'assegnazione attiva per quell'utente viene aggiornata, altrimenti creata come nuovo record.

TAP — Temporary Access Pass

Dalla dashboard è possibile generare un TAP (Temporary Access Pass Entra ID) per permettere all'utente il primo accesso senza password. Il webhook n8n chiama Graph API e restituisce il codice monouso all'operatore.

Completamento configurazione PC

Al termine della configurazione del dispositivo, l'operatore clicca il pulsante dedicato nella dashboard. Il sistema esegue automaticamente:

- Reset della password dell'account creato dal flusso di provisioning, generando una nuova password sicura

- Invio di una notifica al team di gestione sistemi IT con il riepilogo dell'operazione eseguita

- Invio di una email alla casella personale del nuovo dipendente contenente: nuova password aziendale, dettagli del dispositivo assegnato (modello, service tag), istruzioni per la gestione delle credenziali aziendali al primo accesso, e indicazione che dovrà firmare il modulo di consegna dispositivo all'ingresso in azienda

Verbale di consegna

La dashboard genera automaticamente un PDF (ReportLab) con i dati del dipendente, il dispositivo assegnato e gli accessori consegnati. Il documento è predisposto per la firma dell'utente al momento dell'ingresso in azienda e viene archiviato nel sistema.

Sync email → DB HR (in sviluppo)

L'email aziendale creata durante il provisioning dovrebbe essere scritta automaticamente nel record del dipendente nel DB HR. La funzionalità è progettata ma non ancora operativa — la sincronizzazione avviene manualmente in attesa di completamento.

Il workflow implementa error handling su ogni step critico:

- Retry automatico 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

- Idempotenza: ogni step verifica lo stato prima di agire, evitando duplicazioni in caso di riesecuzione

- Rollback parziale: se la creazione licenze fallisce, il workflow notifica e mantiene l'account senza licenze anziché eliminarlo

- La dashboard itprov mostra gli errori in una tab dedicata con il dettaglio dell'eccezione e lo step fallito

Il sistema è stato progettato tenendo conto dei requisiti normativi applicabili al contesto.

GDPR (Reg. UE 2016/679)

- Art. 5 — Limitazione della conservazione: gli account vengono disabilitati e le licenze revocate al termine del rapporto di lavoro, senza lasciare accessi attivi oltre il necessario. Zero account orfani è un requisito di compliance prima ancora che un KPI tecnico.

- Art. 25 — Privacy by design: accesso alla dashboard limitato a un gruppo di sicurezza nominale, utenti DB separati con permessi minimi per funzione (read-only / read-write), ogni azione registrata con l'identità dell'operatore. Il principio del minimo privilegio è applicato a ogni livello dello stack.

- Art. 32 — Sicurezza del trattamento: autenticazione SSO con MFA obbligatorio via Entra ID, nessun accesso anonimo, trasmissione cifrata TLS end-to-end.

- Art. 33 — Notifica violazioni: in caso di incidente, il log strutturato in provisioning_audit 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 della direttiva come settore essenziale, con obblighi di sicurezza più stringenti rispetto ai settori importanti.

- Art. 21 — Misure di gestione del rischio: il deprovisioning automatico con revoca accessi in meno di 60 secondi dalla conferma riduce drasticamente la finestra di esposizione post-cessazione del rapporto di lavoro — uno dei vettori di rischio più frequenti negli incident report del settore.

- Gestione delle identità e degli accessi: il provisioning standardizzato elimina configurazioni difformi tra reparti; ogni account è nominale, tracciabile e revocabile centralmente in un'unica operazione.

- Registrazione e audit: il log strutturato su PostgreSQL con retention configurabile fornisce l'evidenza operativa richiesta in caso di ispezione o incident response — un controllo tecnico concreto per i settori NIS2 essenziali come il trasporto aereo.