Vai al contenuto principale

Garantire la sicurezza del lavoro ibrido: combinare il NAC con lo ZTNA per un accesso senza interruzioni

Questa guida tecnica autorevole illustra la convergenza architetturale di Network Access Control (NAC) e Zero Trust Network Access (ZTNA) per proteggere gli ambienti di lavoro ibridi in contesti aziendali, retail, hospitality e nel settore pubblico. Fornisce un piano di implementazione graduale, casi di studio reali e linee guida di conformità per architetti IT e CTO che hanno l'esigenza di eliminare le lacune di sicurezza create da domini di accesso on-premises e cloud isolati.

📖 6 minuti di lettura📝 1,285 parole🔧 2 esempi pratici3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast
Benvenuti al Purple Enterprise Architecture Briefing. Sono il vostro ospite e oggi approfondiremo una sfida cruciale per i leader IT: la sicurezza della forza lavoro ibrida. In particolare, analizzeremo la convergenza architetturale del Network Access Control — o NAC — e dello Zero Trust Network Access — ZTNA. Se gestite reti complesse in sedi aziendali, spazi retail o ambienti del settore pubblico, questo fa al caso vostro. Inquadriamo il contesto. Il perimetro tradizionale è morto. Lo sappiamo tutti. Proteggere una sede aziendale con un NAC robusto affidandosi al contempo a VPN legacy per l'accesso remoto non è più sufficiente. Crea attrito per l'utente e punti ciechi per l'IT. Le imprese moderne hanno bisogno di una postura di sicurezza unificata che colleghi perfettamente l'infrastruttura on-premises con le applicazioni cloud-native. È qui che entra in gioco la combinazione di NAC e ZTNA. Storicamente, questi erano domini isolati. Il NAC, utilizzando standard come l'802.1X, era eccellente nel controllare l'accesso fisico e wireless all'interno dell'edificio. Verificava lo stato del dispositivo e assegnava le VLAN. Lo ZTNA, d'altra parte, è stato concepito per l'era del cloud: proteggere l'accesso remoto in base all'identità e al contesto, non alla posizione di rete. Il problema sorge quando un lavoratore ibrido si sposta tra questi domini. Si autentica senza problemi a casa tramite ZTNA, ma si scontra con un muro di policy disgiunte quando entra in ufficio. È frustrante, inefficiente e, francamente, crea falle di sicurezza che gli aggressori possono sfruttare. Parliamo quindi dell'architettura tecnica. La soluzione è un livello unificato di brokeraggio dell'identità e del contesto. Dobbiamo sincronizzare la telemetria tra i motori di policy NAC e ZTNA. Pensatela come a una valutazione continua della postura che segue l'utente, ovunque si trovi. Ecco come funziona in pratica. Quando un dispositivo si connette alla rete aziendale, il NAC esegue un controllo completo della postura: versione del sistema operativo, stato dell'antivirus, validazione dei certificati. Condivide immediatamente questo contesto con il broker ZTNA tramite integrazione API. Se la postura del dispositivo peggiora — ad esempio, se viene rilevato un malware — il NAC lo mette in quarantena sulla rete locale e, contemporaneamente, istruisce il broker ZTNA a revocare l'accesso alle applicazioni cloud critiche. Quando l'utente si sposta dall'ufficio a una postazione remota, il client ZTNA mantiene quel contesto di attendibilità stabilito. Non è necessaria alcuna nuova autenticazione. L'esperienza è fluida, ma la sicurezza è continua. Ora, entriamo nei dettagli degli standard alla base di tutto questo. L'IEEE 802.1X è il gold standard per l'autenticazione on-premises. Fornisce la validazione crittografica dell'identità del dispositivo a livello di porta. Il RADIUS funge da protocollo di backend, comunicando tra la soluzione NAC e il vostro identity provider. Sul fronte ZTNA, si fa riferimento a identity provider come Azure Active Directory o Okta, con broker ZTNA dei principali vendor. La chiave è garantire che questi sistemi possano comunicare in modo bidirezionale. Per i gestori di location — hotel, centri congressi, stadi — c'è un ulteriore livello di complessità. Gestisci personale aziendale, appaltatori, ospiti e una flotta in crescita di dispositivi IoT, il tutto sulla stessa infrastruttura fisica. Il NAC gestisce la segmentazione. Il personale aziendale ottiene l'autenticazione 802.1X e l'accesso alle risorse interne. Gli ospiti sono isolati su una rete dedicata, idealmente gestita tramite una piattaforma come il Guest WiFi di Purple, che fornisce un isolamento robusto e al contempo acquisisce preziosi dati analitici. I dispositivi IoT che non possono supportare l'802.1X — come segnaletica digitale, sensori ambientali, terminali POS — vengono gestiti tramite MAC Authentication Bypass, o MAB, con una rigorosa segmentazione VLAN per contenere qualsiasi potenziale compromissione. Lascia che ti illustri uno scenario di implementazione reale. Considera una catena di vendita al dettaglio globale con cinquecento sedi. I manager regionali viaggiano costantemente tra i negozi, la sede centrale e gli uffici domestici. Riscontrano disconnessioni della VPN e un accesso incoerente alle applicazioni di gestione dell'inventario. La soluzione è un'architettura convergente NAC e ZTNA. Quando un manager si trova in negozio, il NAC autentica il dispositivo tramite 802.1X e condivide il contesto interno attendibile con il broker ZTNA. Il broker concede quindi un accesso diretto e ottimizzato all'applicazione di inventario ospitata in cloud, senza che sia necessario un tunnel VPN. Quando il manager lavora da casa, il client ZTNA stabilisce un micro-tunnel sicuro verso l'applicazione, mantenendo le stesse policy di accesso. Il risultato? Accesso coerente, riduzione delle chiamate all'helpdesk e un livello di sicurezza nettamente migliorato. Ora, l'implementazione. Raccomando un approccio in tre fasi. La fase uno è la visibilità. Distribuisci prima il NAC in modalità di monitoraggio. Rileva e profila tutto ciò che si trova sulla tua rete: laptop, dispositivi BYOD, IoT, dispositivi degli ospiti. Non applicare ancora alcuna regola. Contemporaneamente, integra i tuoi provider di identità sia con il NAC che con lo ZTNA per consolidare le identità degli utenti. Utilizza la tua soluzione ZTNA per mappare i pattern di accesso alle applicazioni. Questo ti fornirà i dati necessari per scrivere policy sensate. La fase due è la definizione delle policy. Definisci i requisiti di postura di base per i dispositivi aziendali. Implementa la micro-segmentazione ZTNA in base ai ruoli degli utenti e alla sensibilità delle applicazioni. E, aspetto fondamentale, stabilisci l'integrazione API tra le tue piattaforme NAC e ZTNA per la condivisione bidirezionale del contesto. Testa a fondo questa integrazione prima di passare all'applicazione delle regole. La fase tre è l'applicazione delle regole. Abilita gradualmente l'applicazione del NAC, partendo da un gruppo pilota. Monitora gli errori di autenticazione e adegua le policy. Distribuisci i client ZTNA su tutti gli endpoint aziendali. Ed estendi i principi di zero-trust alle tue reti di ospiti utilizzando una piattaforma gestita. Lasciate che vi fornisca una guida rapida sui trabocchetti più comuni. Primo: i ritardi di sincronizzazione del contesto. Se l'integrazione API tra NAC e ZTNA subisce latenze, un dispositivo compromesso potrebbe mantenere l'accesso alle applicazioni cloud più a lungo del dovuto. La soluzione consiste nell'utilizzare notifiche push basate su webhook anziché affidarsi a meccanismi di polling. Questo garantisce aggiornamenti delle policy quasi in tempo reale. Secondo: policy eccessivamente restrittive che causano picchi di richieste all'helpdesk. Implementare controlli rigorosi sullo stato di sicurezza senza un'adeguata comunicazione agli utenti è la ricetta perfetta per il caos. Utilizzate i Captive Portal per informare gli utenti della non conformità e fornire soluzioni di self-service prima di bloccare completamente l'accesso. Terzo: fallimenti di autenticazione dei dispositivi IoT. I dispositivi IoT headless non possono semplicemente supportare i client 802.1X o ZTNA. La risposta è il MAC Authentication Bypass combinato con una profilazione rigorosa dei dispositivi e una stretta segmentazione delle VLAN. Quarto, e questo è un punto cruciale: non monitorare lo stato di salute dell'integrazione API stessa. Se la sincronizzazione tra NAC e ZTNA si interrompe, si crea una falla di sicurezza. Implementate il monitoraggio e l'allarmistica sullo stato dell'integrazione e definite policy fail-safe che si attivino se la sincronizzazione viene persa per un periodo superiore a una soglia definita. Quindi, qual è il ritorno sull'investimento? Il business case per questa architettura è estremamente convincente. Il consolidamento della gestione delle policy riduce il carico amministrativo per i team IT. L'eliminazione delle VPN legacy migliora significativamente l'esperienza di lavoro ibrido, riducendo i tempi di inattività e la frustrazione. Inoltre, la capacità di dimostrare una valutazione continua dello stato di sicurezza e un controllo degli accessi basato sull'identità semplifica il reporting di conformità per framework come PCI DSS e GDPR — particolarmente rilevanti nei settori retail e sanitario. Per riassumere i punti chiave del briefing di oggi: l'identità è il nuovo perimetro e il contesto è la chiave. Utilizzate il NAC per la rete fisica e lo ZTNA per l'applicazione. Non fidarsi mai, verificare sempre — e farlo continuamente. Implementate per fasi: prima la visibilità, poi la policy, infine l'applicazione. E non dimenticate la rete ospiti e il parco dispositivi IoT — devono far parte della vostra architettura di sicurezza, non essere un elemento secondario. Se desiderate approfondire il futuro della sicurezza di rete guidato dall'intelligenza artificiale, consultate la guida di Purple sul NAC basato su IA e sul rilevamento delle minacce. E per chi gestisce sedi distribuite, la nostra guida SD-WAN vs MPLS merita sicuramente una lettura. Per il briefing di oggi è tutto. Grazie per l'ascolto e alla prossima.

header_image.png

Executive Summary

Per i network architect aziendali e i CTO che gestiscono ambienti distribuiti, il perimetro si è definitivamente dissolto. Il modello tradizionale che prevede la protezione della sede aziendale con un solido Network Access Control (NAC) affidandosi al contempo a VPN legacy per l'accesso remoto non è più sostenibile. Le imprese moderne richiedono una postura di sicurezza unificata che colleghi perfettamente l'infrastruttura on-premises con le applicazioni cloud-native. Questa guida descrive in dettaglio l'integrazione architetturale di NAC e Zero Trust Network Access (ZTNA), fornendo un modello per proteggere gli ambienti di lavoro ibridi senza compromettere l'esperienza utente o il throughput di rete.

Combinando l'applicazione della postura a livello di dispositivo del NAC con la micro-segmentazione incentrata sull'identità di ZTNA, le organizzazioni possono ottenere una verifica continua della fiducia, indipendentemente dalla posizione dell'utente. Questa convergenza è particolarmente critica per i settori ad alta affluenza e con requisiti di conformità complessi, come il Retail , l' Healthcare e l' Hospitality . Inoltre, l'integrazione di piattaforme come l'infrastruttura Guest WiFi di Purple consente di estendere questi principi zero-trust alle reti guest, garantendo un isolamento robusto e una protezione dei dati in linea con gli obblighi GDPR e PCI DSS.

Approfondimento Tecnico: L'Architettura di Convergenza

I Limiti dei Domini di Sicurezza Isolati

Storicamente, NAC e ZTNA operavano come domini di sicurezza isolati. Il NAC, sfruttando lo standard IEEE 802.1X e RADIUS, eccelleva nel controllo dell'accesso fisico e wireless all'interno del perimetro aziendale. Forniva una solida profilazione dei dispositivi, la valutazione della postura e l'assegnazione delle VLAN. Al contrario, lo ZTNA è emerso per proteggere l'accesso remoto alle applicazioni cloud e on-premises, operando sul principio del "never trust, always verify" basato sull'identità e sul contesto dell'utente, piuttosto che sulla posizione di rete.

L'attrito sorge quando i lavoratori ibridi passano da un dominio all'altro. Un utente che si autentica senza problemi tramite ZTNA da casa si trova spesso ad affrontare un'esperienza frammentata quando entra nell'ufficio aziendale, dove le policy NAC potrebbero non essere allineate con il suo contesto ZTNA. Questa frammentazione introduce punti ciechi nella sicurezza e un sovraccarico operativo che influisce direttamente sia sull'efficienza IT che sulla produttività degli utenti finali.

Brokeraggio Unificato di Identità e Contesto

La soluzione architetturale risiede nello stabilire un livello di brokeraggio unificato di identità e contesto che sincronizzi la telemetria tra i motori di policy NAC e ZTNA. Questa integrazione consente una valutazione continua della postura che persiste oltre i confini della rete.

nac_ztna_architecture_overview.png

L'integrazione opera attraverso tre meccanismi chiave. Primo, Valutazione Continua dello Stato di Sicurezza: quando un dispositivo si connette alla rete aziendale, la soluzione NAC esegue un controllo completo dello stato che copre la versione del sistema operativo, lo stato dell'antivirus e la validazione dei certificati. Questo contesto viene immediatamente condiviso con il broker ZTNA tramite integrazione API. Secondo, Applicazione Dinamica delle Policy: se lo stato di sicurezza del dispositivo peggiora — ad esempio, viene rilevato un malware — il sistema NAC mette in quarantena il dispositivo sulla rete locale, istruendo contemporaneamente il broker ZTNA a revocare l'accesso alle applicazioni cloud critiche. Terzo, Transizione Fluida: quando l'utente si sposta dall'ufficio a una posizione remota, il client ZTNA mantiene il contesto di attendibilità stabilito, eliminando la necessità di una nuova autenticazione e garantendo un accesso ininterrotto alle risorse autorizzate.

Per una comprensione più approfondita delle tecnologie wireless sottostanti che supportano queste implementazioni, consulta la nostra guida sulle Wi Fi Frequencies: A Guide to Wi-Fi Frequencies in 2026 .

hybrid_work_security_comparison.png

Guida all'Implementazione: Distribuzione Passo dopo Passo

La distribuzione di un'architettura convergente NAC/ZTNA richiede un approccio graduale per ridurre al minimo le interruzioni e garantire una solida applicazione delle policy.

Fase 1: Identificazione e Rilevamento degli Asset

Prima di implementare le policy di applicazione, è necessario ottenere una visibilità completa del proprio ambiente di rete. Distribuisci la tua soluzione NAC in modalità di solo monitoraggio — configurala per rilevare e profilare tutti i dispositivi connessi, inclusi laptop aziendali, BYOD, IoT e dispositivi guest, senza bloccare l'accesso. Consolida le identità degli utenti integrando sia le soluzioni NAC che ZTNA con un Identity Provider centrale come Azure AD o Okta. Questo garantisce policy di autenticazione coerenti in entrambi i domini. Contemporaneamente, utilizza la tua soluzione ZTNA per monitorare i pattern di accesso alle applicazioni, identificando quali utenti richiedono l'accesso a specifiche applicazioni e ponendo le basi per le tue policy di micro-segmentazione.

Fase 2: Definizione delle Policy e Micro-Segmentazione

Passa dalla visibilità al controllo definendo policy di accesso granulari basate sul principio del privilegio minimo. Stabilisci i requisiti di sicurezza di base per i dispositivi aziendali, inclusi la versione minima del sistema operativo e i requisiti dell'agente EDR attivo, e configura la soluzione NAC per applicare questi requisiti per l'accesso on-premises. Definisci policy ZTNA che limitino l'accesso alle applicazioni in base al ruolo dell'utente e al contesto del dispositivo, garantendo l'allineamento con i requisiti di postura definiti nella soluzione NAC. Aspetto fondamentale, configura l'integrazione API tra le tue piattaforme NAC e ZTNA per abilitare la condivisione bidirezionale del contesto, assicurando che una variazione nella postura del dispositivo rilevata dal NAC attivi immediatamente un aggiornamento delle policy nel broker ZTNA.

Fase 3: Applicazione e Ottimizzazione

Abilita gradualmente la modalità di applicazione delle policy, monitorando le anomalie e perfezionando le regole secondo necessità. Passa la soluzione NAC dalla modalità di monitoraggio a quella di applicazione, iniziando con un gruppo pilota di utenti o sedi, e monitora eventuali errori di autenticazione. Distribuisci il client ZTNA su tutti gli endpoint aziendali, garantendo un accesso fluido alle applicazioni cloud e on-premises. Estendi policy di accesso guest affidabili utilizzando piattaforme come il Guest WiFi di Purple, assicurando che il traffico degli ospiti sia rigorosamente isolato dalle risorse aziendali. Sfrutta i WiFi Analytics per monitorare i modelli di utilizzo e rilevare potenziali anomalie in tutta l'infrastruttura guest.

Best Practice per Ambienti Enterprise

Dai la priorità all'esperienza utente durante l'intera implementazione. La sicurezza non deve ostacolare la produttività e la transizione tra accesso on-premises e remoto deve essere trasparente per l'utente, sfruttando meccanismi di single sign-on e autenticazione continua. Per l'accesso on-premises, imponi l'autenticazione IEEE 802.1X per tutti i dispositivi aziendali, poiché fornisce una solida convalida crittografica dell'identità del dispositivo a livello di porta.

Integra funzionalità di rilevamento delle minacce basate sull'IA nelle tue soluzioni NAC e ZTNA per identificare comportamenti anomali e mettere automaticamente in quarantena i dispositivi compromessi. Per una prospettiva lungimirante su questa funzionalità, consulta The Future of Wi-Fi Security: AI-Driven NAC and Threat Detection e l'equivalente in lingua spagnola El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas . Per le aziende distribuite, l'integrazione di ZTNA con SD-WAN può ottimizzare il routing delle applicazioni e migliorare le prestazioni su più sedi — esamina il nostro confronto in SD WAN vs MPLS: The 2026 Enterprise Network Guide .

Risoluzione dei Problemi e Mitigazione dei Rischi

I ritardi di sincronizzazione del contesto rappresentano la modalità di guasto più critica. Se l'integrazione API tra NAC e ZTNA subisce latenza, un dispositivo compromesso potrebbe mantenere l'accesso alle applicazioni cloud più a lungo di quanto accettabile. La mitigazione consiste nell'implementare notifiche push basate su webhook anziché affidarsi esclusivamente a meccanismi di polling, garantendo aggiornamenti delle policy quasi in tempo reale.

Policy eccessivamente restrittive possono causare picchi significativi di ticket all'helpdesk quando si implementano controlli di postura rigorosi senza un'adeguata comunicazione agli utenti. Utilizza i Captive Portal per informare gli utenti della non conformità e fornire istruzioni di risoluzione self-service prima di bloccare completamente l'accesso.

I fallimenti di autenticazione dei dispositivi IoT sono inevitabili negli ambienti fisici. I dispositivi IoT headless non possono supportare i client 802.1X o ZTNA. La soluzione è il MAC Authentication Bypass (MAB) combinato con una profilazione rigorosa dei dispositivi e una stretta segmentazione delle VLAN per isolare il traffico IoT dalle risorse aziendali.

Il monitoraggio dello stato dell'integrazione API viene spesso trascurato. Se la sincronizzazione tra NAC e ZTNA si interrompe, si crea una lacuna di sicurezza che nessuno dei due sistemi può risolvere autonomamente. Implementa un monitoraggio e un sistema di alert dedicati sullo stato dell'integrazione e definisci policy fail-safe che attivino restrizioni automatiche dell'accesso se la sincronizzazione viene persa per un periodo superiore a una soglia definita.

ROI e impatto aziendale

La convergenza di NAC e ZTNA offre un valore aziendale misurabile che va oltre la mitigazione del rischio. Il consolidamento della gestione delle policy riduce il carico amministrativo per i team IT, consentendo loro di concentrarsi su iniziative strategiche anziché gestire silos di sicurezza disparati. L'eliminazione delle VPN legacy migliora significativamente l'esperienza di lavoro ibrido, riducendo i tempi di inattività e la frustrazione, migliorando al contempo le prestazioni delle applicazioni per gli utenti remoti.

La capacità di dimostrare una valutazione continua della postura e un controllo degli accessi basato sull'identità semplifica il reporting di conformità per framework come PCI DSS e GDPR, particolarmente rilevanti nei settori del Trasporto e del retail, dove gli obblighi di protezione dei dati dei titolari di carta e dei dati personali sono stringenti. Le organizzazioni che hanno implementato architetture convergenti segnalano costantemente una riduzione del tempo medio di contenimento (MTTC) degli incidenti di sicurezza, poiché l'applicazione bidirezionale delle policy consente la quarantena automatizzata senza richiedere interventi manuali.

Definizioni chiave

Network Access Control (NAC)

Una soluzione di sicurezza che applica policy ai dispositivi che richiedono l'accesso a un'infrastruttura di rete, utilizzando tipicamente lo standard IEEE 802.1X per l'autenticazione e la valutazione della postura per determinare l'assegnazione della VLAN e i diritti di accesso.

Fondamentale per la sicurezza degli ambienti on-premise, garantisce che solo i dispositivi conformi e autorizzati possano connettersi agli switch aziendali e agli access point wireless. I team IT si confrontano con questo aspetto quando gestiscono le reti fisiche di uffici e sedi.

Zero Trust Network Access (ZTNA)

Una soluzione di sicurezza IT che fornisce un accesso remoto sicuro ad applicazioni e servizi in base a policy di controllo degli accessi definite, operando sul principio del privilegio minimo e della verifica continua dell'identità anziché sulla posizione di rete.

Sostituisce le VPN legacy fornendo una micro-segmentazione basata sull'identità, concedendo l'accesso solo a specifiche applicazioni anziché all'intera rete. Rilevante per la sicurezza dei lavoratori da remoto e per l'accesso alle applicazioni cloud.

Micro-segmentazione

La pratica di suddividere una rete in segmenti isolati per ridurre la superficie di attacco e prevenire i movimenti laterali da parte di attori malevoli, applicata a livello di applicazione o di carico di lavoro anziché sul perimetro di rete.

ZTNA applica questo concetto a livello applicativo, garantendo che un endpoint compromesso non possa fare pivot per accedere a risorse non autorizzate. I team IT si confrontano con questo aspetto durante la progettazione di architetture zero-trust.

Valutazione della Postura

Il processo di valutazione dello stato di sicurezza di un dispositivo — inclusi versione del sistema operativo, antivirus attivo, certificati installati e livello di patch — prima di concedere l'accesso alla rete o alle applicazioni.

Una funzione fondamentale del NAC, che garantisce che i dispositivi vulnerabili o compromessi vengano messi in quarantena o bonificati prima di poter interagire con la rete aziendale. Rilevante durante l'onboarding dei dispositivi e il monitoraggio continuo.

IEEE 802.1X

Uno standard IEEE per il Network Access Control basato su porta, che fornisce un meccanismo di autenticazione ai dispositivi che desiderano collegarsi a una LAN o WLAN, utilizzando EAP (Extensible Authentication Protocol) sul mezzo di rete.

Il gold standard per l'autenticazione di rete aziendale, che fornisce una robusta convalida crittografica dell'identità del dispositivo. I team IT si confrontano con questo aspetto durante la configurazione di switch, controller wireless e server RADIUS.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di Autenticazione, Autorizzazione e Accounting (AAA) per gli utenti che si connettono e utilizzano un servizio di rete, fungendo da livello di comunicazione tra il NAC e gli identity provider.

Il protocollo backend utilizzato dalle soluzioni NAC per comunicare con gli identity provider e applicare le policy di accesso. Rilevante quando si integra il NAC con Active Directory o IdP cloud.

MAC Authentication Bypass (MAB)

Un metodo di autenticazione di fallback utilizzato dalle soluzioni NAC per i dispositivi che non supportano lo standard 802.1X, che si affida all'indirizzo MAC del dispositivo come identificativo per assegnare le policy di accesso alla rete.

Necessario per accogliere dispositivi headless — stampanti, sensori IoT, digital signage — negli ambienti aziendali. Meno sicuro dell'802.1X, richiede una rigorosa segmentazione VLAN per mitigare i rischi di MAC spoofing.

Identity Provider (IdP)

Un'entità di sistema che crea, mantiene e gestisce le informazioni sull'identità dei soggetti fornendo al contempo servizi di autenticazione alle applicazioni dipendenti all'interno di una federazione o di una rete distribuita.

La fonte centrale di verità per le identità degli utenti, che si integra sia con il NAC sia con lo ZTNA per garantire policy di autenticazione coerenti. I team IT si confrontano con questo aspetto durante la configurazione di SSO e MFA nei sistemi aziendali.

VLAN (Virtual Local Area Network)

Una suddivisione logica di una rete fisica che raggruppa i dispositivi in domini di broadcast isolati, consentendo la segmentazione del traffico senza richiedere un'infrastruttura fisica separata.

Il meccanismo principale per isolare diverse classi di dispositivi — aziendali, guest, IoT — all'interno di una rete fisica condivisa. Fondamentale per la conformità ai requisiti GDPR e PCI DSS per l'isolamento dell'ambiente dei dati dei titolari di carta.

Esempi pratici

Una catena di vendita al dettaglio globale con 500 sedi deve garantire l'accesso sicuro ai manager regionali che viaggiano frequentemente tra i negozi, la sede aziendale e gli uffici domestici remoti. Attualmente riscontrano frequenti disconnessioni della VPN e un accesso incoerente alle applicazioni di gestione dell'inventario ospitate in cloud.

Implementare un'architettura convergente NAC/ZTNA in tutte le sedi. Distribuire l'802.1X tramite NAC per un accesso sicuro e trasparente quando i manager si trovano fisicamente in negozio o in sede, autenticandosi tramite un server RADIUS centralizzato integrato con Azure AD. Distribuire un client ZTNA su tutti i laptop aziendali. Integrare i motori di policy NAC e ZTNA tramite API, configurando notifiche webhook per aggiornamenti immediati dello stato di sicurezza. Quando un manager si connette alla rete del negozio, il NAC autentica il dispositivo e condivide il contesto "trusted internal" con il broker ZTNA. Il broker ZTNA concede quindi un accesso diretto e ottimizzato all'applicazione di inventario ospitata in cloud senza richiedere un tunnel VPN, riducendo la latenza ed eliminando i problemi di disconnessione. Quando il manager lavora da casa, il client ZTNA stabilisce un micro-tunnel sicuro verso l'applicazione, mantenendo le stesse policy di accesso senza dipendere dal perimetro della rete aziendale. I dispositivi guest e IoT in negozio sono isolati su VLAN separate gestite tramite la piattaforma Guest WiFi di Purple.

Commento dell'esaminatore: Questo approccio risolve i problemi di esperienza utente associati alle VPN legacy fornendo un accesso trasparente e sensibile al contesto, indipendentemente dalla posizione. L'integrazione API garantisce che lo stato di sicurezza venga valutato continuamente, mitigando il rischio che un dispositivo compromesso acceda ad applicazioni critiche. La decisione architetturale chiave è il routing "local edge": quando si è sulla rete aziendale, il traffico ZTNA dovrebbe essere instradato verso un broker locale anziché passare attraverso un broker cloud, il che vanificherebbe i vantaggi in termini di latenza.

Un grande centro congressi deve fornire un Wi-Fi sicuro per il personale aziendale, isolando al contempo migliaia di connessioni guest giornaliere e dispositivi IoT di fornitori terzi, inclusi segnaletica digitale, beacon BLE e sensori ambientali.

Distribuire una solida soluzione NAC configurata con una rigorosa segmentazione VLAN su tre livelli distinti. Livello uno: i dispositivi del personale aziendale si autenticano tramite 802.1X e vengono assegnati a una VLAN interna sicura con accesso completo ai sistemi di gestione interni. Livello due: implementare la piattaforma Guest WiFi di Purple per gestire l'accesso pubblico, acquisendo dati analitici preziosi e garantendo al contempo il completo isolamento dalla rete aziendale tramite una VLAN guest dedicata con solo accesso a Internet. Livello tre: per i dispositivi IoT dei fornitori, utilizzare il MAC Authentication Bypass (MAB) combinato con una profilazione approfondita dei dispositivi (analizzando i fingerprint DHCP, gli user agent HTTP e i modelli di traffico) per identificare accuratamente i tipi di dispositivi e assegnarli a VLAN limitate con solo accesso a Internet. Integrare lo ZTNA per consentire al personale aziendale di accedere in modo sicuro alle applicazioni di gestione interna da qualsiasi posizione all'interno della struttura o da remoto. Per l'infrastruttura dei beacon BLE, fare riferimento alla guida su BLE Low Energy Explained for Enterprise per considerazioni sull'integrazione.

Commento dell'esaminatore: Questo scenario evidenzia la necessità di gestire diversi tipi di dispositivi all'interno di un unico ambiente fisico. Il modello di segmentazione a tre livelli è l'approccio corretto: tentare di gestire tutti i tipi di dispositivi all'interno di un unico framework di policy porta invariabilmente a policy eccessivamente permissive o eccessivamente restrittive. L'uso della piattaforma Guest WiFi di Purple per il livello guest è particolarmente rilevante in questo caso, poiché fornisce sia l'isolamento richiesto per la sicurezza sia le funzionalità di analisi necessarie per le operazioni della struttura.

Domande di esercitazione

Q1. La tua organizzazione sta implementando ZTNA per sostituire una VPN legacy. Tuttavia, gli utenti che tornano in ufficio riscontrano latenza durante l'accesso alle applicazioni ospitate localmente nel data center on-premises, poiché il traffico ZTNA viene instradato attraverso un broker ospitato in cloud. Qual è la soluzione architetturale consigliata?

Suggerimento: Considera come il client ZTNA determina il percorso ottimale verso l'applicazione in base al contesto di rete fisica dell'utente.

Visualizza risposta modello

Implementare un Local Edge o un On-Premises ZTNA Broker all'interno del data center aziendale. Configurare il client ZTNA per rilevare quando il dispositivo è autenticato sulla rete aziendale interna tramite NAC e instradare il traffico direttamente all'applicazione locale tramite il broker interno, anziché instradarlo a ritroso (hair-pinning) attraverso il broker ospitato in cloud. Ciò riduce la latenza per le applicazioni on-premises mantenendo gli stessi controlli di accesso basati sull'identità. La condivisione del contesto NAC tramite API dovrebbe segnalare al broker ZTNA che il dispositivo si trova su una rete interna affidabile, abilitando la decisione di instradamento locale.

Q2. Il team IT di un ospedale deve proteggere centinaia di dispositivi medici connessi — pompe di infusione, monitor dei pazienti, apparecchiature di imaging — che non possono eseguire supplicant 802.1X o client ZTNA. Come dovrebbero essere protetti questi dispositivi all'interno di un'architettura convergente NAC/ZTNA?

Suggerimento: Considera i metodi di autenticazione di fallback e il principio di isolamento a livello di rete per i dispositivi che non possono partecipare ai controlli basati sull'identità.

Visualizza risposta modello

Utilizzare il MAC Authentication Bypass (MAB) sulla soluzione NAC, combinato con una profilazione approfondita dei dispositivi tramite fingerprint DHCP, user agent HTTP e analisi del comportamento del traffico per identificare e classificare accuratamente ciascun tipo di dispositivo medico. Una volta identificati, il NAC assegna dinamicamente questi dispositivi a VLAN altamente limitate e isolate che consentono solo la comunicazione con server e sistemi medici specifici e richiesti — bloccando tutto il resto del traffico per impostazione predefinita. Lo ZTNA non è applicabile a questi dispositivi; la sicurezza si basa interamente su una rigorosa segmentazione della rete e sul monitoraggio continuo del traffico per comportamenti anomali. Assicurarsi che le VLAN dei dispositivi medici siano completamente isolate dall'ambiente dei dati dei titolari di carta per mantenere la conformità PCI DSS.

Q3. Durante una distribuzione in produzione, l'integrazione API tra le soluzioni NAC e ZTNA fallisce silenziosamente — non viene attivato alcun avviso. Successivamente, il laptop di un utente sulla rete aziendale viene infettato da malware. Descrivi il risultato di sicurezza previsto e identifica la lacuna architetturale che lo ha consentito.

Suggerimento: Analizza l'impatto di una sincronizzazione del contesto interrotta su ciascun motore di policy in modo indipendente e considera quale monitoraggio avrebbe dovuto essere attivo.

Visualizza risposta modello

La soluzione NAC rileverà lo stato di sicurezza degradato tramite l'integrazione EDR e metterà in quarantena il dispositivo sulla rete locale, impedendo il movimento laterale all'interno dell'ambiente aziendale. Tuttavia, poiché l'integrazione API è fallita silenziosamente, il broker ZTNA non ha ricevuto il contesto di postura aggiornato. Se l'utente tenta di accedere a un'applicazione cloud, il client ZTNA potrebbe comunque stabilire una connessione se il token di autenticazione dell'identità iniziale rimane valido e non è scaduto. La lacuna architetturale è duplice: in primo luogo, l'assenza di monitoraggio dello stato sull'integrazione API stessa; in secondo luogo, la mancanza di una policy fail-safe che attivi restrizioni di accesso automatiche se la sincronizzazione del contesto viene persa oltre una soglia definita. La correzione consiste nell'implementare un monitoraggio dedicato con avvisi sullo stato dell'integrazione, configurare il broker ZTNA per richiedere una rivalutazione periodica della postura (non solo l'autenticazione iniziale) e definire una policy default-deny che si attiva se il feed del contesto NAC non è disponibile per un intervallo superiore a quello specificato.