Come implementare il modello Zero Trust senza interrompere l'operatività

Nel Regno Unito, il 98% delle organizzazioni dichiara di pianificare o di aver già implementato il modello zero trust, eppure solo il 15% dichiara un'implementazione completa. Il problema non è la consapevolezza. È l'esecuzione. La ricerca sul modello zero trust nel Regno Unito mostra che molti team hanno avviato progetti di pianificazione, segmentazione o identità isolate senza collegare tali controlli in un unico modello operativo.

La questione pratica non è se lo zero trust sia importante. È come implementare lo zero trust senza interrompere i servizi attivi, frustrare gli utenti o creare un'ennesima raccolta di prodotti di sicurezza disconnessi. La risposta consiste nel sequenziare la migrazione attorno all'identità, alla postura del dispositivo, al ciclo di vita della directory, al WiFi sicuro, alla segmentazione e alla verifica continua.

Perché l'implementazione del Zero Trust si blocca nelle grandi aziende

Il 51% delle organizzazioni si trova ancora in una fase iniziale di pianificazione, mentre solo il 15% dichiara un'implementazione completa e l'80% ha dovuto affrontare ostacoli tecnici o operativi. Il rapporto sulle organizzazioni del Regno Unito mostra il divario tra la scelta di una direzione e la gestione dei controlli richiesti. I team spesso iniziano con progetti isolati, per poi scoprire che identità, dispositivi, directory, applicazioni e reti dipendono gli uni dagli altri.

Il modello zero trust rimuove la fiducia intrinseca da sistemi, reti e servizi. Una connessione interna non dovrebbe fornire un accesso ampio. Un vecchio account non dovrebbe conservare i permessi dopo che la persona o il fornitore non ne ha più bisogno. Un servizio non dovrebbe rimanere attendibile a tempo indeterminato solo perché ha superato un singolo controllo di autenticazione.

Il National Cyber Security Centre del Regno Unito inquadra lo zero trust come una migrazione graduale e non come l'acquisto di un prodotto. Le sue linee guida sull'architettura definiscono otto principi di progettazione, inclusi i processi decisionali di accesso basati sull'identità e le comunicazioni protette. La raccolta zero-trust del NCSC è stata pubblicata nel 2021, con linee guida di implementazione ampliate a settembre di quell'anno. I principi di progettazione dell'architettura del NCSC sono utili perché richiedono ai team di definire l'architettura e le decisioni di attendibilità prima di scegliere la tecnologia.

La modalità di fallimento orientata solo al prodotto

Il modello di fallimento inizia solitamente con l'acquisto di una piattaforma. Un team implementa un prodotto di identità, uno strumento di segmentazione o un gateway ZTNA, per poi scoprire che gli account di servizio, i dispositivi non gestiti, le applicazioni legacy, l'autenticazione wireless e l'offboarding della directory non erano mai stati mappati.

Il risultato è un elenco di eccezioni in continua crescita. Gli utenti ricevono soluzioni temporanee, gli amministratori conservano credenziali condivise e i team di sicurezza non possono dire se le policy vengano applicate in modo coerente. Il WiFi espone rapidamente questa debolezza. La segmentazione della rete può separare il traffico, ma non crea un accesso basato sull'identità se gli utenti continuano ad accedere tramite password condivise o se i dispositivi rimangono sconosciuti. Il WiFi senza password con autenticazione basata su certificati, collegato ai record dei dispositivi e allo stato della directory, fornisce alle policy un segnale di identità affidabile. La revoca automatica della directory dovrebbe quindi rimuovere l'accesso quando un account viene disabilitato, anziché attendere una pulizia manuale.

I controlli perimetrali tradizionali hanno ancora un ruolo, ma non possono rispondere a ogni domanda di accesso. L'articolo su perché la sicurezza IT tradizionale fallisce spiega come i servizi cloud, l'accesso remoto e i dispositivi distribuiti indeboliscano l'ipotesi che una rete interna sia automaticamente sicura.

Regola pratica: Non definire policy di applicazione finché non sai quali identità, dispositivi, WiFi e dipendenze dei servizi potrebbero essere interrotti dalla policy stessa.

Una migrazione realizzabile segue questo ordine:

• Scopri l'infrastruttura: identifica utenti, dispositivi, applicazioni, servizi e flussi di dati.
• Definisci i confini: decidi quali risorse richiedono l'isolamento e quali percorsi di accesso sono legittimi.
• Costruisci il control plane: connetti identità, MFA, accesso ai dispositivi basato su certificati, controlli di conformità e ciclo di vita della directory.
• Applica all'edge: applica le policy ad applicazioni, reti e WiFi, non solo alle sessioni VPN.
• Osserva ed espandi: inizia con carichi di lavoro controllati, esamina le decisioni di accesso ed estendi gradualmente il modello.

Questa sequenza rende lo zero trust un modello operativo piuttosto che una raccolta di strumenti. Consente inoltre ai team operativi di proteggere la disponibilità mentre i controlli di identità, il WiFi sicuro e la segmentazione maturano.

Gettare le basi con l'identificazione e i confini di fiducia

Inizia con un inventario che rifletta il reale funzionamento dell'organizzazione, non come lo descrive lo schema di rete. Il NCSC raccomanda di identificare utenti, autorizzazioni necessarie, dispositivi e servizi, per poi progettare la gestione delle identità e degli accessi in base a questi risultati. La guida alla migrazione del NCSC orienta inoltre i team verso la mappatura delle dipendenze legacy e la modellazione delle minacce dell'architettura proposta prima del rollout.

L'output dovrebbe essere un catalogo operativo, non un foglio di calcolo statico. Registra il proprietario, lo scopo aziendale, il metodo di autenticazione, le dipendenze, la sensibilità dei dati, gli utenti previsti e l'impatto del fallimento per ciascuna risorsa importante.

Costruire quattro inventari

Utenti e identità vengono prima di tutto. Includi dipendenti, contrattualizzati, amministratori privilegiati, account di servizio e identità di automazione. Separa lo stato occupazionale di una persona dalla sua esigenza di accesso. Un contrattualizzato potrebbe aver bisogno di accedere a un'applicazione per un periodo definito, mentre un account di servizio potrebbe richiedere l'autenticazione della macchina ma nessun login interattivo.

I dispositivi necessitano di una propria classificazione. Registra i laptop gestiti, i dispositivi mobili, i terminali condivisi, le stampanti, le telecamere, i sistemi dell'edificio e le altre apparecchiature IoT. Prendi nota di quali dispositivi supportano i certificati, la crittografia moderna e la segnalazione dello stato di sicurezza (posture). Le apparecchiature legacy spesso non sono in grado di soddisfare i requisiti di autenticazione del personale, pertanto richiedono una strategia di contenimento esplicita piuttosto che un'eccezione non monitorata.

Le applicazioni e i servizi dovrebbero essere mappati in base ai loro requisiti di identità e trasporto. Documenta se ciascuna applicazione supporta SSO, MFA, protocolli moderni, certificati, accesso tramite proxy o solo un nome utente e una password legacy. Identifica le directory a monte, i database, i servizi DNS, le API e le dipendenze di logging.

I flussi di dati e i percorsi aziendali rivelano i confini della fiducia. Mappa come un membro dello staff raggiunge un sistema clinico, come un collaboratore esterno accede a un portale di manutenzione o come un dispositivo POS comunica con i servizi approvati. Un segmento non ha senso se una dipendenza non documentata costringe a consentire un accesso illimitato attraverso di esso.

Definire i confini prima delle policy

Un confine fiduciario dovrebbe rispondere a tre domande: cosa viene protetto, chi ha bisogno dell'accesso e a quali condizioni. Le condizioni possono includere la garanzia dell'identità, lo stato di salute del dispositivo, il contesto di rete, la sensibilità dell'applicazione e l'approvazione limitata nel tempo.

Le reti WiFi ospiti, l'IoT e i siti multi-tenant meritano un'attenzione speciale. Gli ospiti non dovrebbero mai dipendere dalle credenziali di rete del personale. I dispositivi IoT dovrebbero comunicare solo con i servizi richiesti per il loro funzionamento. I tenant possono condividere l'infrastruttura fisica pur mantenendo l'isolamento logico e una gestione separata delle identità.

Il trasporto sicuro è fondamentale per ogni confine. Se il team ha bisogno di un ripasso semplice su certificati, crittografia e attendibilità dei browser, la guida di Adwave Digital a SSL è un riferimento utile prima di documentare i requisiti di trasporto delle applicazioni e del WiFi.

Concludi la fase di discovery con un modello di minaccia. Testa cosa succede se un account di directory viene compromesso, un dispositivo gestito risulta non conforme, un certificato viene revocato, un controller wireless non è disponibile o un servizio legacy non può autenticarsi con il nuovo identity provider. Questi percorsi di errore dovrebbero definire l'ordine di implementazione.

Costruire l'identità e lo stato del dispositivo come piano di controllo

Le decisioni di zero trust hanno bisogno di una fonte di verità. Nella maggior parte delle infrastrutture, questo significa selezionare la directory che gestisce persone, gruppi ed eventi del ciclo di vita, come Microsoft Entra ID, Google Workspace o Okta. La scelta progettuale importante non è solo il brand. È se ogni sistema di accesso possa consumare lo stesso stato di identità e reagire quando tale stato cambia.

Un utente che lascia l'organizzazione dovrebbe perdere l'accesso ovunque sia importante. Un collaboratore esterno il cui incarico termina non dovrebbe rimanere attivo in un sistema wireless perché un amministratore si è dimenticato di rimuovere un account separato. Il provisioning e la revoca automatici trasformano le modifiche alla directory in controlli operativi anziché in promemoria amministrativi.

Autenticare la persona e il dispositivo

Inizia con SSO e MFA per le applicazioni aziendali. L'MFA aumenta la certezza, mentre l'SSO riduce il numero di credenziali che gli utenti e i service desk devono gestire. Il NCSC raccomanda specificamente di progettare l'IAM attorno all'MFA e di prendere in considerazione l'autenticazione senza password dove opportuno. I metodi senza password possono migliorare sia la sicurezza che l'usabilità, ma richiedono procedure di ripristino, controlli per la registrazione dei dispositivi e supporto per gli utenti che perdono l'accesso al loro autenticatore principale.

Per il WiFi del personale, l'autenticazione basata su certificati è solitamente più solida dal punto di vista operativo rispetto alle password condivise. Con WPA2 o WPA3-Enterprise e 802.1X, la rete può vincolare l'accesso a un'identità registrata o a un certificato di dispositivo. Ciò elimina la necessità di distribuire una chiave comune e rende la revoca precisa.

La postura del dispositivo aggiunge la seconda metà della decisione. Verifica se il dispositivo è gestito, crittografato, aggiornato, conforme e se utilizza un certificato approvato. Un utente valido su un laptop non gestito non dovrebbe ricevere automaticamente lo stesso accesso di quell'utente su un dispositivo aziendale integro.

L'identità prova chi sta richiedendo l'accesso. La postura del dispositivo determina se tale richiesta di accesso è sufficientemente sicura per essere approvata.

Progettare eventi del ciclo di vita, non solo l'accesso

L'onboarding dovrebbe creare l'identità nella directory, assegnare i gruppi corretti, registrare il dispositivo e rilasciare il certificato richiesto attraverso un flusso di lavoro automatizzato. L'offboarding dovrebbe disabilitare l'identità, revocare sessioni e certificati e rimuovere l'accesso alla rete senza attendere l'intervento di un amministratore WiFi dedicato.

I collaboratori esterni hanno bisogno di un percorso diverso. Assegna loro un'appartenenza a gruppi con autorizzazioni limitate, un processo di scadenza o approvazione e l'accesso solo alle applicazioni e ai segmenti di rete richiesti dal loro lavoro. Non risolvere la praticità d'uso per i collaboratori esterni inserendoli in un'ampia rete destinata al personale interno.

I dispositivi legacy richiedono contenimento. Laddove una stampante, un sensore o un terminale specializzato non possa utilizzare l'autenticazione basata su certificati, è necessario utilizzare un segmento dedicato, regole firewall rigorosamente perimetrate e un meccanismo di identità controllato, come una chiave precondivisa individuale. In questo modo l'eccezione rimane visibile e se ne limita il raggio d'azione.

I team che valutano l'accesso alla rete vincolato all'identità possono esaminare l'approccio identity-based networking come modello di implementazione. Il principio architetturale rimane lo stesso, indipendentemente dalla piattaforma: lo stato della directory, la robustezza dell'autenticazione e lo stato del dispositivo devono influenzare insieme la decisione di accesso.

Segmentazione e WiFi sicuro che applica le policy

La segmentazione è necessaria, ma non può imporre da sola l'accesso basato sull'identità. Il 92% delle organizzazioni britanniche intervistate dichiara di segmentare le proprie reti in una certa misura, mentre il 98% afferma di pianificare o aver già implementato il modello zero trust. La ricerca nel Regno Unito indica che la suddivisione in zone della rete è diffusa, ma la garanzia dell'identità, la verifica continua e l'applicazione delle policy richiedono ancora attenzione.

Una VLAN separa il traffico. Non decide se una persona, un dispositivo o una sessione debba mantenere l'accesso. Se un utente passa da un laptop conforme a un dispositivo non gestito, il dispositivo potrebbe rimanere nello stesso segmento a meno che il sistema di accesso non valuti nuovamente l'identità e la postura.

Confrontare i livelli di maturità

Area di Controllo	Implementazione Parziale	Maturità Zero Trust
Progettazione della rete	Le VLAN o ampie zone separano ospiti, personale e dispositivi	Policy granulari limitano l'accesso a risorse e flussi specifici
Autenticazione WiFi	Password condivise, Captive Portal o chiavi statiche	WPA2 o WPA3-Enterprise, 802.1X e accesso basato su certificati o identità
Ciclo di vita dell'utente	Gli amministratori creano e rimuovono gli account manualmente	Le modifiche alla directory effettuano il provisioning e revocano l'accesso in modo automatico
Garanzia del dispositivo	Un dispositivo si connette se possiede le credenziali di rete corrette	Lo stato di salute del dispositivo e lo stato del certificato influenzano ogni decisione di accesso
Risposta alle policy	L'accesso rimane attivo fino a quando una sessione o un account non viene modificato manualmente	Le variazioni di contesto attivano la rivalutazione, la limitazione o la revoca
Visibilità	I log del controller mostrano gli eventi di connessione	Gli eventi di identità, dispositivo, policy e risorse vengono correlati per la revisione

Trattare il WiFi come un confine di identità

Il WiFi è spesso la prima decisione di accesso aziendale che un dispositivo si trova ad affrontare. Lasciarla alla fine del programma crea un divario tra la policy della directory e la connettività fisica.

Per il personale, utilizza WPA2 o WPA3-Enterprise con 802.1X, supportato da certificati o da un altro metodo di identità forte. Il WiFi senza password elimina le credenziali condivise dall'esperienza utente, mentre l'autenticazione basata su certificati associa la connettività a un'identità e a un dispositivo registrati. Passpoint e OpenRoaming possono supportare il roaming sicuro consentendo a un dispositivo registrato di autenticarsi senza dover inserire ripetutamente una password.

L'obiettivo è una connettività crittografata e legata all'identità fin dal primo pacchetto. Un Captive Portal che concede un accesso ampio dopo che l'utente ha accettato i termini non fornisce tale controllo.

Per una revisione pratica della sicurezza WiFi aziendale, valuta la distribuzione dei certificati, l'integrazione dell'identity provider, la gestione delle revoche e la compatibilità dei controller. Il design deve funzionare in tutta l'infrastruttura, inclusi i dispositivi Meraki, Aruba, Ruckus, Mist o UniFi.

Gli ospiti richiedono un'esperienza e una policy separate. Fornisci l'accesso a Internet senza privilegi per il personale. I dispositivi IoT necessitano di policy limitate che consentano solo le destinazioni e i servizi richiesti per il loro funzionamento.

Rivalutare l'accesso continuamente

Il NCSC evidenzia la rivalutazione continua, l'osservabilità e la resilienza come requisiti espliciti del modello zero trust. La sua guida all'implementazione ZTNA supporta la modifica dell'accesso al variare del contesto, anziché lasciare i permessi fissi per l'intera durata di una sessione.

L'integrazione della directory deve supportare la revoca automatica. Un account disabilitato, l'esclusione dall'appartenenza a un gruppo o un certificato revocato dovrebbero attivare aggiornamenti delle policy senza attendere l'intervento di un amministratore WiFi separato. Il risultato può essere un'autenticazione aggiuntiva, lo spostamento su una rete limitata, il blocco dell'applicazione o la revoca immediata dell'accesso.

La segmentazione contiene l'incidente. L'identità, lo stato del dispositivo e la telemetria corrente determinano se l'accesso può continuare. Questa combinazione colma il divario tra la separazione della rete e un vero controllo basato sull'identità.

Implementare il monitoraggio e verificare ogni decisione di accesso

Un rollout sicuro è controllato, osservabile e reversibile. Non iniziare applicando una nuova policy a ogni utente, sito e categoria di dispositivo. Seleziona un gruppo o una sede a basso rischio che contenga comunque una complessità reale sufficiente a far emergere i problemi, quindi verifica il percorso di accesso prima di estenderlo.

Inizia in modalità monitoraggio laddove la tecnologia lo supporti. Acquisisci ciò che la policy consentirebbe e negherebbe, confronta tali decisioni con i requisiti aziendali e indaga sulle dipendenze sconosciute. La modalità monitoraggio non sostituisce l'applicazione delle regole. È un modo per eliminare sorprese evitabili prima che l'applicazione influisca sulla produzione.

Utilizzare una migrazione graduale

Una sequenza pratica si presenta così:

1. Scegli un progetto pilota limitato: seleziona un'applicazione, un sito o un gruppo di utenti a basso rischio con un referente noto e un percorso di supporto chiaro.
2. Registra la baseline: acquisisce le autenticazioni riuscite e non riuscite, lo stato del dispositivo, lo stato del certificato, il posizionamento in rete, il risultato dei criteri e l'esito dell'applicazione.
3. Testa i percorsi di negazione: conferma che MFA falliti, certificati revocati, identità di directory disabilitate e dispositivi non conformi vengano bloccati.
4. Applica in modo mirato: applica la policy al progetto pilota, con una condizione di rollback documentata e un amministratore in grado di annullare la modifica.
5. Espandi per dipendenza: aggiungi gruppi, siti o servizi solo dopo che la fase precedente presenta log stabili e un processo di supporto concordato.

Il progetto pilota dovrebbe includere test di fallimento. Disabilita un'identità di test, rimuovi la sua appartenenza al gruppo, contrassegna un dispositivo come non conforme e revoca il suo certificato. Conferma che l'accesso alla rete, l'accesso alle applicazioni e le sessioni attive rispondano come previsto.

Rendere utile la telemetria

Raccogli gli eventi che spiegano le decisioni, non solo gli eventi che provano l'avvenuta connessione. Come minimo, correla l'identità richiedente, l'identificatore del dispositivo, il risultato dell'autenticazione, lo stato del certificato, il risultato della postura, il segmento di rete, la risorsa di destinazione, la versione della policy e la decisione finale.

Cerca pattern che richiedono una revisione manuale:

• Uso imprevisto dell'identità: un utente accede a una risorsa al di fuori del suo normale ruolo o gruppo approvato.
• Variazioni di postura: un dispositivo precedentemente conforme perde lo stato di gestione, crittografia o certificato.
• Errori ripetuti: si verificano errori di autenticazione o di postura su più account o sedi.
• Eccezioni ai criteri: un dispositivo o servizio legacy dipende ripetutamente da una regola generica.
• Ritardi di revoca: un'identità disabilitata nella directory continua ad avere accesso alla rete o alle applicazioni.

Utilizza la panoramica dei dati e della sicurezza di Purple per valutare come una piattaforma WiFi basata sull'identità gestisce i dati di accesso, i controlli di sicurezza e la visibilità operativa. Indipendentemente dagli strumenti selezionati, le dashboard dovrebbero supportare le decisioni. Un registro che nessuno controlla non migliorerà l'applicazione delle policy.

Condizione di ripristino: Annulla una policy quando blocca un processo aziendale critico, crea una dipendenza non sicura o produce errori di accesso inspiegabili. Conserva le prove, correggi la progettazione e ripeti i test. Non lasciare permanentemente aperta un'eccezione di emergenza.

Proteggere la disponibilità come parte della sicurezza

Il modello zero trust dipende da directory, servizi di certificazione, motori di policy, controller di rete e connettività. Costruisci la resilienza in ogni dipendenza. Definisci cosa accade se l'identity provider non è raggiungibile, se i certificati non possono essere convalidati, se un controller si guasta o se un servizio di policy diventa non disponibile.

Usa la progettazione di servizi fail-safe con attenzione. Alcuni ambienti richiedono che le sessioni esistenti continuino brevemente durante un'interruzione del servizio di identità. Altri dovrebbero limitare l'accesso immediatamente per le risorse sensibili. La scelta corretta dipende dalla risorsa, dal modello di minaccia e dalle conseguenze operative.

Comunica prima dell'applicazione delle regole. Spiega agli utenti cosa cambierà, quali metodi di accesso utilizzeranno, come funziona la registrazione dei dispositivi e dove segnalare i problemi. Monitora i temi del servizio di assistenza e l'analisi degli accessi dopo ogni fase. La riduzione dell'amministrazione manuale degli account, un minor numero di credenziali condivise e una revoca più rapida sono indicatori pratici del miglioramento del modello operativo.

La tua checklist per l'implementazione del Zero Trust e passaggi successivi

Un piano di implementazione praticabile dovrebbe essere inserito all'ordine del giorno della prossima riunione sull'architettura:

• Rilevamento: Inventariare persone, account di servizio, dispositivi, applicazioni e servizi.
• Mappatura delle dipendenze: Documentare i flussi di dati, i metodi di autenticazione, i vincoli legacy e i proprietari operativi.
• Definizione dei confini: Separare l'accesso di personale, ospiti, IoT e tenant in base alle esigenze di risorse.
• Rafforzamento dell'identità: Selezionare una directory come fonte di verità, imporre l'MFA e introdurre l'SSO.
• Adozione di un'autenticazione più forte: Spostare gli utenti e i dispositivi idonei verso un accesso senza password e basato su certificati.
• Automazione del ciclo di vita: Sincronizzare il provisioning dai gruppi di directory e revocare l'accesso quando cambiano le identità o i certificati.
• Valutazione della postura: Verificare la gestione, lo stato di salute e la conformità prima di concedere accessi sensibili.
• WiFi sicuro: Utilizzare l'autenticazione enterprise legata all'identità anziché password condivise del personale.
• Contenimento dei dispositivi legacy: Collocare le eccezioni su segmenti limitati con criteri a perimetro ristretto.
• Monitoraggio preventivo: Eseguire le policy pilota in modalità di osservazione, quindi applicarle definendo criteri di rollback.
• Verifica continua: Testare gli accessi negati, le revoche, le variazioni di postura e i guasti del servizio.
• Espansione deliberata: Aggiungere sedi e carichi di lavoro solo quando i log, la proprietà e i processi di supporto sono pronti.

La decisione di implementazione più importante riguarda la sequenza. Non iniziare con il prodotto più visibile o con il segmento di rete più ampio. Inizia con un percorso che puoi comprendere, misurare e invertire. Per il settore hospitality e retail, ciò potrebbe significare separare il personale, gli ospiti e i dispositivi operativi all'interno di una sede attiva. Per il settore sanitario, potrebbe significare dare priorità ai controlli di identità e dispositivo attorno a un'applicazione sensibile. Per i complessi residenziali multi-tenant, potrebbe significare fornire un accesso semplice ai residenti preservando l'isolamento tra gli inquilini e i sistemi dell'edificio.

Scegli una piattaforma quando questa elimina una reale barriera alla migrazione. Se la tua infrastruttura richiede un WiFi senza password, un accesso del personale integrato con la directory, la revoca automatica e una minore dipendenza da RADIUS on-premises, valuta se una piattaforma come Purple si adatta all'identità e all'architettura di rete esistenti. Mantieni la decisione legata ai tuoi obiettivi di controllo, ai requisiti di integrazione e alla gestione operativa.

Misura i progressi attraverso le prove, non con gli annunci di implementazione. Dovresti essere in grado di mostrare quali identità hanno accesso, quali dispositivi sono attendibili, quali policy hanno negato le richieste, quanto rapidamente ha avuto effetto la revoca e dove rimangono le eccezioni. È così che lo zero trust diventa una capacità operativa anziché l'ennesimo programma di sicurezza bloccato.

---

Purple fornisce WiFi e reti basate sull'identità che collegano il personale e i dispositivi alle directory esistenti, supportano l'accesso senza password e tramite certificati, e possono automatizzare il provisioning e la revoca al variare dello stato della directory. Visita Purple per valutare in che modo l'autenticazione WiFi, lo stato del dispositivo e le integrazioni di rete possono supportare un'implementazione graduale del modello zero trust.