2FA e NIS2 con Zitadel su un sistema di posta legacy

La richiesta era di quelle che sembrano semplici: attivare l'autenticazione a due fattori sull'accesso a un pannello di gestione della posta, perché un adeguamento normativo lo richiede. L'identity provider lo supporta, l'interruttore c'è, il lavoro sembra di mezz'ora.

Poi qualcuno fa la domanda giusta: se scegliamo il codice temporaneo via email, a quale indirizzo lo mandiamo? E lì la mezz'ora diventa un progetto. Perché l'accesso a quel pannello è storicamente un accesso per dominio: l'utente digita il nome del dominio e una password, e quello che accade tecnicamente è una verifica contro una casella tecnica di quel dominio. Il codice andrebbe lì. E quella casella, per una convenzione stabilita in un documento del 1997, è quasi sempre recapitata all'operatore che gestisce il servizio, non al cliente. Il codice di accesso del cliente arriverebbe nella casella dell'assistenza.

Non è un caso limite ed è la ragione per cui vale la pena raccontarlo: è il modo in cui un sistema costruito bene vent'anni fa incontra un requisito che vent'anni fa non esisteva. Negli articoli precedenti di questa serie ho descritto il modello di identità dell'identity provider, come si sposta l'autorizzazione nell'applicazione che conosce il dominio e come si mantiene il prodotto installabile anche senza federazione. Qui affronto il vincolo normativo che ha dato l'urgenza a tutto il resto.

Perché il secondo fattore non si accende con un interruttore?

Perché il secondo fattore presuppone una cosa che quel sistema non aveva: un'identità che corrisponda a una persona. Un codice temporaneo, una notifica su un'applicazione, una chiave hardware sono tutti meccanismi che verificano che ci sia quel individuo dall'altra parte. Se l'identità con cui si accede è una casella condivisa, non c'è nessun individuo da verificare: c'è un ruolo, e i ruoli non hanno telefoni.

È un difetto che nei sistemi datati si presenta sempre nella stessa forma. L'accesso è per risorsa, non per persona: si entra "come dominio", "come cliente", "come postazione". Ha funzionato per anni perché la password condivisa era accettabile, e smette di funzionare nel momento in cui una norma chiede di dimostrare chi ha fatto una certa operazione. Un registro che dice che l'accesso è stato fatto dalla casella tecnica di un dominio non risponde a quella domanda.

La riformulazione che uso quando devo spiegare perché il lavoro è più grande di quanto sembri: l'autenticazione a due fattori non si aggiunge a un'identità condivisa, la sostituisce. La spesa non è nel secondo fattore, è nel passaggio da un accesso per risorsa a uno per persona.

Il vincolo che rende il caso interessante

La casella in questione non è una scelta di prodotto, è un obbligo. Le convenzioni sulle caselle di ruolo, codificate nella RFC 2142, stabiliscono che alcuni indirizzi debbano esistere per ogni dominio che offre determinati servizi, e fra questi ci sono quello dedicato ai problemi del servizio di posta e quello per le segnalazioni di abuso. Non si possono togliere: sono il canale attraverso cui il resto della rete segnala i problemi, e un dominio che li rifiuta si crea difficoltà molto concrete.

Nella pratica quella casella accumula tre funzioni diverse che nessuno ha mai deciso di sommare. È l'indirizzo di ruolo previsto dallo standard, quindi riceve segnalazioni tecniche e va letto da chi sa cosa farne, che è l'operatore. È l'identità di accesso al pannello, per come il sistema è stato costruito. E se si accende il codice via email, diventa anche il destinatario del secondo fattore.

Sono tre funzioni con tre destinatari naturali diversi, e la seconda e la terza sono state aggiunte per comodità in momenti in cui la prima era l'unica considerata. La contromisura che viene proposta per prima in questi casi è un instradamento condizionale, del tipo "se il messaggio arriva dall'identity provider, inoltralo al contatto del cliente, altrimenti tienilo". Funziona, e va detto chiaramente che è una toppa: si basa sul mittente, che è un dato falsificabile, aggiunge una regola da mantenere per ogni dominio, e soprattutto lascia intatto il difetto di fondo, cioè che l'identità continua a essere una casella. Il giorno in cui serve sapere quale persona ha fatto una modifica, quella regola non aiuta.

Cosa dice davvero la norma, con le date

Qui serve precisione, perché su questo tema circolano molte affermazioni approssimative e le date sbagliate producono decisioni sbagliate.

Il riferimento tecnico per i soggetti nel perimetro italiano è la determinazione ACN n. 379907/2025, efficace dal 15 gennaio 2026, che ha sostituito il precedente atto del 2025. Citare quello vecchio è un errore ricorrente che si trova ancora in parecchi materiali in circolazione.

Le scadenze che contano, per chi è già nell'elenco nazionale dal 2025: le misure di base vanno completate entro il 31 ottobre 2026, un termine che corrisponde a diciotto mesi dalla comunicazione di inserimento. Le misure sono organizzate in allegati tecnici e la loro numerosità dipende dalla classificazione del soggetto: 37 misure articolate in 87 requisiti per i soggetti importanti, e 43 misure per gli essenziali, che aggiungono fra le altre cose il monitoraggio continuo, le attività di verifica delle vulnerabilità e di test di intrusione, e la sicurezza delle risorse umane. Per chi invece è stato inserito per la prima volta nel 2026 il termine per le misure di base è il 31 luglio 2027, con la notifica degli incidenti operativa dal 1 gennaio 2027.

Il dato che cambia la percezione dell'urgenza, e che consiglio di mettere in ogni discussione su questo tema: da ottobre 2026 l'Agenzia passa dall'accompagnamento alla verifica, con l'avvio delle attività ispettive. Fino a quel momento il rapporto è stato di supporto; dopo, è di controllo. Le sanzioni previste arrivano fino a 10 milioni di euro o al 2 per cento del fatturato mondiale per i soggetti essenziali, e a 7 milioni o all'1,4 per cento per gli importanti.

Sul piano degli incidenti, il meccanismo di notifica è operativo da gennaio 2026 con una scansione precisa: pre-notifica entro 24 ore, notifica entro 72 ore, relazione finale entro un mese. Vale la pena conoscerla anche se non ti riguarda direttamente, perché è la scadenza che trasforma un incidente tecnico in un problema di conformità nel giro di un giorno.

Se non sai se la tua azienda rientri nel perimetro, e capita più spesso di quanto si creda che rientri per via di un servizio accessorio, il mio strumento di autovalutazione NIS2 risponde in sette domande e classifica il soggetto. È il punto di partenza corretto: discutere delle misure prima di sapere se sei nel perimetro è tempo speso male in entrambe le direzioni.

Nel merito del controllo degli accessi, la richiesta normativa non nomina una tecnologia. Chiede che l'accesso ai sistemi sia controllato, che sia autenticato con un livello adeguato al rischio, e che sia tracciabile. È quest'ultimo requisito, più del secondo fattore in sé, quello che rende insostenibile l'identità condivisa: un registro di accessi in cui figura una casella di ruolo non dice chi c'era davvero, e questo è un problema anche prima di qualunque adempimento.

Chi sono le persone, quando il cliente è un'azienda

Prima di poter dare un'identità a ciascuno serve rispondere a una domanda che nei sistemi con accesso per risorsa non si era mai posta: chi sono queste persone, esattamente? È il passaggio che ho visto sottovalutare più spesso, e che determina la dimensione reale del progetto.

Nel caso concreto sono emerse tre popolazioni con esigenze diverse. C'è il titolare del rapporto, la persona di riferimento del cliente, che di norma è già censita nelle anagrafiche perché è quella con cui si è firmato il contratto: per lei l'identità esiste già o si crea a partire da un dato che si possiede. C'è chi si occupa dei sistemi per conto del cliente, che spesso è un fornitore esterno e che nelle anagrafiche non compare da nessuna parte: per lei serve un meccanismo di delega esplicito, con un invito e una revoca, perché è una relazione che nasce e finisce indipendentemente dal contratto. E ci sono gli operatori interni, che hanno già un'identità aziendale e che vanno solo collegati alle risorse su cui possono intervenire.

Le tre popolazioni hanno tre percorsi di attivazione diversi e tre modelli di revoca diversi, e trattarle come un unico insieme è l'errore che allunga i progetti. La seconda in particolare è quella che genera il lavoro non previsto, perché richiede di costruire una funzione che prima non esisteva: un modo per il cliente di dire chi altri può accedere alle sue risorse, e di toglierlo. Senza quella funzione, l'unica alternativa realistica è che il cliente condivida le proprie credenziali con il fornitore, che è esattamente il comportamento che si stava cercando di eliminare.

C'è un principio che ne ricavo e che vale in generale: una misura di sicurezza che rende impossibile una cosa che le persone devono fare non viene rispettata, viene aggirata. Se togli la credenziale condivisa senza offrire un modo legittimo di delegare, hai spostato il problema, non risolto. Il modo legittimo va costruito nello stesso rilascio, non nel successivo.

Il percorso di rimedio, in tre passi

La soluzione non è instradare meglio i messaggi: è smettere di usare una casella come identità. Il percorso che ho impostato ha tre passi, e l'ordine conta perché ciascuno rende possibile il successivo.

Primo, l'identità diventa la persona. Chi accede non è più il dominio ma un individuo, con la propria identità presso l'identity provider, che i sistemi già conoscono. Il legame fra quella persona e le risorse che può amministrare non sta più in una password condivisa: viene calcolato dal sistema che conosce le anagrafiche, come descritto nell'articolo sull'autorità di autorizzazione. È il passo che porta via più tempo, ed è quello senza cui gli altri due non hanno senso.

Secondo, il secondo fattore si applica alla persona, dove ha un significato. A quel punto l'identity provider può chiedere un codice temporaneo generato da un'applicazione, una chiave hardware, o un altro fattore, e tutti verificano che sia quella persona. La domanda su dove mandare il codice via email semplicemente non si pone più, perché non serve più mandarlo a nessuna casella.

Terzo, la casella di ruolo torna a essere solo quello. Riceve le segnalazioni previste dallo standard, viene letta da chi le sa gestire, e non ha più nessuna funzione nell'accesso. È la parte che dà più soddisfazione, perché non richiede di costruire niente: si toglie una responsabilità che non avrebbe mai dovuto avere.

Sulla scelta del fattore vale la pena essere pratici, perché è la decisione su cui si perde più tempo in riunione. Il codice generato da un'applicazione è il compromesso ragionevole per la gran parte delle situazioni: non costa nulla, funziona senza connessione, e l'unico attrito reale è la registrazione iniziale e il caso della persona che cambia telefono. La chiave hardware è più solida e più costosa, e ha senso per chi amministra sistemi critici. Il codice via email, che è da dove è partita questa storia, è il più debole dei tre: sposta la sicurezza sulla casella di posta, quindi vale esattamente quanto vale la protezione di quella casella. Nel caso di un pannello che gestisce la posta stessa, c'è anche una circolarità evidente da cui è meglio stare alla larga.

Se stai affrontando un adeguamento in cui il vincolo tecnico non è la misura da implementare ma il modello di identità che ci sta sotto, nel mio profilo professionale trovi il percorso su compliance NIS2, sicurezza applicativa e modernizzazione di sistemi in esercizio.

Come si convive con i due sistemi durante la transizione?

Tenendoli entrambi accesi e spostando le persone a gruppi, mai con un passaggio unico a data fissa. È la parte del progetto che decide se l'adeguamento andrà bene o male, e curiosamente è quella che nei piani riceve meno spazio.

Il meccanismo che lo rende possibile è la configurazione a più stati descritta nell'articolo precedente: l'accesso classico resta disponibile mentre quello federato viene attivato. Non è un compromesso al ribasso, è la condizione perché la migrazione sia reversibile. Se qualcosa non funziona per un gruppo di utenti, si torna indietro per quel gruppo senza fermare tutto.

L'ordine con cui muovere le persone conta e non è casuale. Prima chi lavora in casa, cioè gli operatori interni, perché sono raggiungibili, sanno spiegare cosa non va, e un problema su di loro non diventa un ticket di un cliente. Poi i clienti più strutturati, quelli che hanno un referente tecnico con cui si può parlare. Per ultimi i clienti piccoli, che sono i più numerosi e i meno attrezzati, e che vanno spostati quando la procedura è già stata affinata due volte.

Sulla comunicazione l'errore da evitare è annunciare la novità come un miglioramento tecnico. Alla persona che deve registrare un secondo fattore non interessa il modello di identità: le interessa sapere cosa deve fare, entro quando, e cosa succede se non lo fa. Tre frasi, in quest'ordine, e un canale di assistenza indicato in modo esplicito. Il resto è rumore che riduce la probabilità che il messaggio venga letto.

C'è poi la decisione più delicata dell'intero percorso, ed è quando spegnere l'accesso classico. Tenerlo acceso indefinitamente vanifica il lavoro, perché finché esiste una via che non richiede il secondo fattore, il sistema vale quanto la via più debole. Spegnerlo troppo presto blocca fuori le persone che non hanno ancora completato la registrazione. Il criterio che uso è una soglia dichiarata in anticipo, del tipo "quando il novanta per cento degli accessi degli ultimi trenta giorni passa dal percorso nuovo", più una comunicazione dedicata a chi resta indietro. La data di spegnimento va decisa all'inizio del progetto e comunicata subito, altrimenti si sposta all'infinito e la coda non si esaurisce mai.

Le misure che il controllo degli accessi tocca davvero

Un adeguamento di questo tipo non chiude una singola casella in un elenco, e vale la pena vederlo perché cambia il calcolo costi-benefici.

L'identità per persona con secondo fattore incide direttamente su l'autenticazione, che è il requisito da cui è partita questa storia. Ma incide anche su la gestione del ciclo di vita degli accessi, perché un'identità individuale si può creare, sospendere e revocare, mentre una credenziale condivisa no. Incide su la tracciabilità delle operazioni, perché i registri passano da contenere nomi di caselle a contenere nomi di persone. Incide su la gestione dei privilegi, perché diventa possibile distinguere chi può fare cosa invece di avere un unico livello di accesso per risorsa. E incide su la gestione degli incidenti, perché la finestra di 24 ore per la pre-notifica presuppone di sapere in fretta cosa è successo e per mano di chi.

È il motivo per cui, quando aiuto qualcuno a impostare il piano, consiglio di non trattare il controllo degli accessi come una voce fra le altre. Nella maggior parte delle organizzazioni è la voce che, risolta bene, ne sistema altre quattro; e lasciata indietro, blocca le stesse quattro qualunque cosa si faccia sul resto. La numerosità delle misure, decine di voci articolate in decine di requisiti, spaventa e induce ad affrontarle in ordine di elenco: è il modo peggiore, perché fra quelle voci ce ne sono alcune che sono prerequisiti di altre, e questa è una di quelle.

Vale anche la pena di dire cosa non risolve, per onestà. Il secondo fattore protegge l'accesso, non protegge da chi ha accesso legittimo e sbaglia o agisce in malafede. Per quello servono la classificazione delle operazioni sensibili e la tracciabilità di chi agisce per conto di chi, che sono temi trattati in altri articoli di questa serie. E non protegge da un'applicazione che, una volta autenticata la persona, non verifica cosa quella persona possa toccare: quello è il recinto applicativo, ed è un lavoro separato che va fatto comunque.

Cosa costa davvero, e a chi

La parte per chi la decisione la deve prendere, perché il costo di questo lavoro non è dove sembra.

Il costo tecnico è medio e finito. Portare l'identità sull'identity provider, mappare le persone alle risorse, adeguare il pannello: è un progetto con un inizio e una fine, e la maggior parte del lavoro l'ho descritta negli articoli precedenti di questa serie.

Il costo di transizione è il vero costo, ed è di comunicazione. Ogni persona che oggi accede con una credenziale condivisa deve ricevere un'identità propria, attivarla, registrare un secondo fattore. Su una base di qualche centinaio di utenti non tecnici questo non è un rilascio, è una campagna: comunicazione preventiva, istruzioni scritte in modo comprensibile, un periodo di convivenza fra i due sistemi, e assistenza pronta a rispondere per le prime settimane. Chi pianifica solo la parte tecnica scopre questa voce nel momento peggiore.

Il costo del non farlo è asimmetrico. Non è la sanzione, che è un'eventualità. È che senza identità per persona non si può rispondere a una domanda che prima o poi arriva: chi ha fatto questa operazione. Arriva da un cliente che contesta una modifica, da un'indagine interna, da un'ispezione. E la risposta "non possiamo saperlo, l'accesso è condiviso" è più costosa di qualunque sanzione, perché mina la fiducia in tutto il resto.

C'è infine un beneficio che di solito non viene messo a bilancio e che nella pratica ripaga da solo il lavoro: la revoca diventa possibile. Con una credenziale condivisa, quando una persona lascia l'azienda del cliente, l'unico modo di toglierle l'accesso è cambiare la password a tutti. Nella realtà non lo fa nessuno, e la conseguenza è che ex collaboratori mantengono accesso per anni. Con un'identità per persona, si disattiva quella e basta. Se dovessi convincere qualcuno con un solo argomento, userei questo e non la norma.

Vale la pena chiudere con il ribaltamento di prospettiva che ho trovato più utile in queste discussioni. Un adeguamento normativo viene quasi sempre percepito come un costo imposto dall'esterno, e in questo caso specifico si è rivelato l'occasione per correggere un difetto architetturale che esisteva da anni e che nessuno aveva mai avuto una ragione abbastanza forte per affrontare. La norma non ha creato il problema: ha creato il budget per risolverlo. Se stai guardando una scadenza di adeguamento come a un adempimento da spuntare al minimo costo, vale la pena chiedersi quale difetto vecchio potresti chiudere approfittandone, perché quella finestra si apre di rado. E se vuoi capire se il tuo modello di identità regge quel tipo di domanda, scrivimi pure: la verifica è rapida e si riduce a chiedersi se il registro degli accessi contenga nomi di persone o nomi di caselle.