Pochi concetti di cybersecurity sono citati quanto Zero Trust, e pochi sono altrettanto fraintesi. Viene spesso presentato come una tecnologia da acquistare, con una casella da spuntare nel budget. In realtà è un principio di progettazione: non concedere fiducia implicita a nessuno, né alla rete né al dispositivo né alla persona, e verificare ogni richiesta di accesso in base al contesto in cui avviene.
Poiché ogni accesso parte da un’identità, è da lì che Zero Trust comincia. Prima di consentire a qualcuno di entrare in un sistema occorre stabilire con sicurezza chi è, da dove accede e con quale dispositivo. Il perimetro aziendale come lo conoscevamo, la rete interna considerata affidabile per definizione, non esiste più da tempo: quello che resta da proteggere è chi accede e a cosa. L’identità è il nuovo perimetro, e tutto il resto di Zero Trust si costruisce su questa base.
Zero Trust non è un prodotto, e il modo migliore per capirlo è provare a comprarlo
Chi ha provato ad acquistare Zero Trust come un pacchetto si è trovato davanti a un catalogo di tecnologie diverse, ciascuna delle quali copre un pezzo: segmentazione di rete, accesso remoto, protezione degli endpoint, gestione delle identità. Nessuna da sola è Zero Trust, e metterle insieme senza un ordine produce complessità senza produrre sicurezza.
L’ordine conta, e il punto di partenza è obbligato. Ogni richiesta di accesso, qualunque sia la tecnologia che la intercetta, deve essere attribuita a un’identità verificata. Se quella verifica è debole, se la credenziale è intercettabile, se l’account appartiene a una persona che ha lasciato l’azienda, tutto quello che viene dopo si appoggia su una base che non regge. Per questo chi parte dall’identità costruisce Zero Trust su fondamenta solide, e chi parte altrove ci mette un’etichetta.
Verificare l’identità: il primo passo
La verifica dell’identità in un’architettura Zero Trust è contestuale e continua. Non basta una password, e non basta nemmeno una seconda verifica fatta una volta sola al mattino. Ogni richiesta viene valutata rispetto a chi la fa, da quale dispositivo, da quale posizione, a quale ora e verso quale risorsa, e il livello di verifica richiesto si adatta al rischio: un accesso al gestionale dall’ufficio con un dispositivo aziendale non richiede la stessa frizione di un accesso ai sistemi di produzione da una rete sconosciuta.
Il fattore che fa la differenza è la resistenza al phishing. Il furto di credenziali resta la modalità di ingresso più sfruttata, e le campagne di phishing sono diventate molto più efficaci da quando l’AI generativa produce messaggi credibili e costruiti sul contesto reale dell’azienda. Le tecniche di proxy in tempo reale aggirano l’MFA tradizionale basata su codici; i fattori basati su standard FIDO2 no, perché la credenziale è legata al dominio legittimo e non può essere reinserita altrove. È il punto su cui ha più senso investire per primi.
Il privilegio minimo è il cuore operativo
Verificare l’identità è il primo passo; il secondo è decidere a cosa quell’identità può accedere. Qui entra il principio del privilegio minimo: concedere solo gli accessi necessari al ruolo, nulla di più. È la traduzione pratica di Zero Trust nel governo quotidiano degli accessi, e nella pratica è dove la maggior parte delle organizzazioni si ferma.
La difficoltà non è capirlo, ma mantenerlo. In un’organizzazione viva i ruoli cambiano, i progetti nascono e finiscono, le persone entrano ed escono, i fornitori si alternano. Senza un sistema che ricalcoli i permessi a ogni cambiamento, il privilegio minimo si degrada inevitabilmente in privilege creep: la somma dei permessi di una persona cresce nel tempo, sempre per una ragione ragionevole, e nessuno la riporta indietro. Il risultato è che una credenziale compromessa, invece di aprire poche porte, apre un corridoio.
I tre ingredienti che rendono il least privilege sostenibile
Il privilegio minimo regge nel tempo solo se è automatico, perché ciò che è automatico non si degrada. Tre ingredienti, insieme, lo rendono una pratica e non un’intenzione.
- Assegnazione basata sul ruolo. Chi entra riceve gli accessi previsti dalla propria posizione secondo regole definite, non per copia di un collega che ha accumulato permessi negli anni. Un cambio di ruolo ricalcola l’insieme dei privilegi invece di aggiungere i nuovi ai vecchi.
- Revisioni periodiche. Campagne di certificazione in cui i responsabili confermano o revocano gli accessi a intervalli regolari, con il contesto necessario per decidere: l’ultimo utilizzo, il ruolo attuale, la scadenza del rapporto. La revoca viene eseguita dalla piattaforma, non delegata a un ticket.
- Automazione del ciclo di vita. Ogni cambiamento di stato di una persona, ingresso, trasferimento, uscita, aggiorna i suoi accessi senza intervento manuale, collegando le utenze alle fonti autorevoli del personale e dei contratti.
Vale la pena notare che nessuno dei tre ingredienti richiede che l’organizzazione sia già matura: si può partire dai sistemi critici e da pochi ruoli ben definiti, ed estendere il perimetro a ogni ciclo di revisione. Quello che non funziona è l’approccio opposto, tentare di coprire tutto in un colpo solo e fermarsi alla prima eccezione.
Il primo ingrediente impedisce che l’eccesso nasca. Il secondo lo individua dove è già nato. Il terzo chiude la fonte principale dell’accumulo, che è il cambiamento gestito a metà. Nessuno dei tre basta da solo: l’assegnazione per ruolo senza revisioni si sfalda alla prima eccezione, le revisioni senza automazione producono decisioni che nessuno esegue.
Dal principio alla pratica con Okta
Okta unisce questi elementi su una piattaforma unica. L’autenticazione adattiva e contestuale del Workforce Identity Cloud copre la verifica dell’identità, con policy che modulano il livello di controllo in base al rischio e con fattori resistenti al phishing. Okta Identity Governance mantiene il privilegio minimo nel tempo: l’Entitlement Management lega i permessi ai ruoli, le campagne di Access Certification coinvolgono i responsabili nelle revisioni con il contesto necessario, il Lifecycle Management collega le utenze alle fonti autorevoli così che ogni cambiamento di stato aggiorni gli accessi lo stesso giorno. Le Access Requests con approvazione e durata gestiscono le eccezioni, che scadono da sole invece di diventare permanenti.
Il valore aggiunto, per chi deve rendere conto a un auditor o a un’autorità, è che ogni passaggio resta registrato. Zero Trust impostato sull’identità produce, come effetto collaterale, l’evidenza che la conformità richiede: chi ha accesso a cosa, chi lo ha approvato, quando è stato rivisto. Per i soggetti NIS2, ora che le verifiche sono iniziate, non è un dettaglio.
Da dove iniziare, in pratica
Il primo passo è misurare lo scarto tra privilegi effettivi e privilegi previsti dal ruolo su un campione di utenti con anzianità elevata: la differenza è una stima concreta dell’accumulo e dice quanto è grande il problema. Il secondo è imporre fattori resistenti al phishing sugli accessi più esposti, remoti e privilegiati, prima che su tutti gli altri.
Il terzo è definire i ruoli sui sistemi più critici, anche in modo approssimativo, perché senza una base di riferimento non esiste un modo oggettivo per dire quali permessi sono in eccesso. Il quarto è una campagna pilota di certificazione su un perimetro ristretto, con l’obiettivo di misurare i tempi reali e la percentuale di accessi revocati. Questi quattro passi non completano un percorso Zero Trust, ma lo fanno partire dal punto giusto.
Domande frequenti
Zero Trust è un prodotto che si può acquistare
No. È un principio di progettazione secondo cui nessun accesso è affidabile per definizione e ogni richiesta va verificata nel contesto. Si realizza combinando più tecnologie, e il punto di partenza obbligato è la verifica dell’identità.
Qual è la differenza tra privilegio minimo e Zero Trust
Il privilegio minimo è il principio per cui ogni identità riceve solo i permessi necessari al proprio compito. Zero Trust è il modello più ampio che assume l’assenza di fiducia implicita e verifica ogni accesso. Il privilegio minimo è la traduzione operativa di Zero Trust nel governo degli accessi.
Da dove si parte per un percorso Zero Trust
Dall’identità: autenticazione resistente al phishing sugli accessi più esposti, poi privilegio minimo per ruolo, revisioni periodiche e automazione del ciclo di vita. Segmentazione di rete e protezione degli endpoint vengono dopo e si appoggiano su questa base.
Perché il privilegio minimo si degrada nel tempo
Perché ogni cambio di ruolo, progetto ed eccezione aggiunge permessi e quasi nessun evento li toglie. Senza assegnazione per ruolo, revisioni e automazione del ciclo di vita, l’accumulo è inevitabile.
Zero Trust aiuta con la conformità NIS2
Sì. Un’architettura impostata sull’identità produce le evidenze che le verifiche richiedono: inventario degli accessi, privilegio minimo dimostrabile, revisioni tracciate, registro delle decisioni. È lo stesso processo a servire sicurezza e conformità.
In sintesi
Zero Trust non è una scatola, è un modo di lavorare che comincia dall’identità: verificare chi accede, da dove e con cosa, e concedere solo i privilegi necessari. Il principio è semplice da condividere e difficile da mantenere, perché richiede disciplina costante e non un progetto una tantum. Renderlo automatico, con assegnazione per ruolo, revisioni periodiche e ciclo di vita gestito, è ciò che lo trasforma da slogan in pratica, e ciò che produce, nello stesso movimento, l’evidenza che la conformità chiede.
Per impostare un percorso Zero Trust che parta dal punto giusto, in Factor-y, primo partner Okta in Italia, mettiamo a disposizione un assessment di 30 minuti, gratuito: una lettura dei privilegi effettivi rispetto ai ruoli, degli accessi più esposti e delle priorità con cui intervenire.
