Nelle reti di edificio, l’accesso alla porta o alla radio viene ancora trattato troppo spesso come un dettaglio di configurazione. Si parla di VLAN, firewall, segmentazione, logging, ma l’ingresso vero nella rete resta in molti casi affidato a logiche deboli: porte aperte, reti “temporanee” diventate permanenti, whitelist statiche, MAC address usati come identità, SSID condivisi, profili guest estesi oltre il necessario. È qui che 802.1X e NAC diventano rilevanti. Non perché siano una formula magica, ma perché spostano il controllo dal semplice collegamento fisico alla decisione su chi o cosa può davvero entrare, con quali credenziali, in quale segmento e con quale livello di fiducia. Microsoft, nella documentazione ufficiale per l’accesso cablato autenticato, ricorda che una distribuzione 802.1X richiede switch Ethernet compatibili 802.1X e RADIUS; quegli switch, in una infrastruttura RADIUS, operano come client RADIUS. L’architettura di base, quindi, non è “porta attiva o spenta”, ma supplicant, authenticator e server di autenticazione/AAA.
Per trattare l’argomento in modo serio bisogna però evitare due errori opposti. Il primo è presentare 802.1X come soluzione universale e sufficiente in ogni scenario. Il secondo è ridurlo a un fastidio operativo che si può evitare con qualche ACL o con il MAC authentication bypass. Entrambe le posizioni sono povere. 802.1X è un meccanismo di access control molto forte quando i dispositivi supportano bene il supplicant, quando le identità sono governate, quando i certificati o le credenziali sono distribuiti in modo ordinato e quando l’autenticazione è integrata con policy di autorizzazione e segmentazione. Diventa invece fragile o macchinoso quando viene introdotto in reti piene di dispositivi non gestiti, endpoint legacy, apparati IoT eterogenei e procedure di onboarding improvvisate. NIST, nel lavoro sull’onboarding di dispositivi IoT a livello di rete, sottolinea proprio questo punto: prima di fornire a un dispositivo le credenziali necessarie per unirsi alla rete, è cruciale stabilire un rapporto di fiducia tra rete e dispositivo per ridurre il rischio di attacchi.
Architettura di base: cosa fa davvero 802.1X
Il primo chiarimento indispensabile è terminologico. EAP non è un metodo di autenticazione specifico, ma un framework. RFC 3748 definisce EAP come un framework di autenticazione che supporta più metodi e che tipicamente opera direttamente sopra livelli di collegamento dati come PPP o IEEE 802, senza richiedere IP. Questo è importante perché spiega perché 802.1X non sia “una password di rete”, ma un meccanismo di controllo di accesso port-based che incapsula metodi EAP e li trasporta fino al server di autenticazione, tipicamente via RADIUS. RFC 3580 descrive infatti l’uso di RADIUS da parte degli authenticator IEEE 802.1X.
In pratica, il modello corretto è questo. Il dispositivo o utente che chiede accesso è il supplicant. Lo switch cablato o l’access point che controlla la porta o l’associazione è l’authenticator. Il server che decide se autenticare e con quali attributi autorizzativi è il backend AAA, di solito RADIUS. Microsoft, nelle proprie guide per 802.1X cablato e wireless, ribadisce questa logica: l’accesso alla LAN può essere negato se il processo di autenticazione fallisce. Questa è la differenza strutturale rispetto a una porta “sempre aperta”: l’accesso non è presunto, è deciso.
Il vero salto non è l’autenticazione, ma l’autorizzazione dinamica
Molti articoli su 802.1X si fermano all’autenticazione. È incompleto. Il punto davvero rilevante, in una rete di edificio, è che il controllo di accesso non si esaurisce nel sì o no. Una piattaforma NAC o un’infrastruttura AAA ben progettata usa l’identità e il contesto per assegnare VLAN, dACL, SGT, profili di ruolo, posture o restrizioni specifiche. È qui che l’access layer smette di essere un semplice livello di forwarding e diventa un punto di enforcement. La stessa logica emerge nella documentazione di piattaforme come Cisco ISE e nelle guide Microsoft su 802.1X: autenticazione e autorizzazione sono due piani diversi e la decisione finale può includere attributi che modificano il comportamento della porta e del segmento.
Questa distinzione è decisiva per utenti, dispositivi gestiti, BYOD e IoT. Un utente aziendale con certificato può ricevere un accesso diverso da un contractor. Un notebook gestito può finire in un segmento diverso da un desktop non conforme. Un dispositivo di building automation può essere ammesso solo nel microsegmento necessario. Un dispositivo sconosciuto può essere confinato in remediation o onboarding. Senza questo livello dinamico, 802.1X rischia di ridursi a una semplice barriera iniziale. Con questo livello, diventa un motore di policy.
EAP-TLS, password e metodi diversi: non sono equivalenti
Anche qui serve neutralità. Non tutti i metodi EAP offrono lo stesso profilo di sicurezza, gestibilità e complessità operativa. RFC 5216 definisce EAP-TLS come protocollo che usa TLS per autenticazione reciproca basata su certificati e derivazione di chiavi. È una caratteristica importante: l’autenticazione reciproca riduce il rischio di credenziali riutilizzabili e offre una base più robusta rispetto ai modelli centrati su username/password. Per questo, quando si parla di utenti gestiti, dispositivi aziendali e accesso cablato o wireless enterprise, EAP-TLS è spesso considerato il metodo di riferimento.
Detto questo, EAP-TLS non è “migliore” in senso assoluto in qualsiasi contesto. Il suo contro è operativo: richiede PKI, distribuzione ordinata dei certificati, gestione del ciclo di vita, revoca, trust anchors corretti e dispositivi che supportino bene il metodo. Microsoft, nelle guide Intune e Surface Hub, mostra chiaramente che per abilitare 802.1X wired con certificati servono profili specifici e policy dedicate per installare certificati client o root CA. Il vantaggio di sicurezza, quindi, esiste, ma va pagato in progettazione e governo.
I modelli basati su credenziali utente o metodi meno forti possono avere meno attrito iniziale, ma aumentano l’esposizione al riuso delle credenziali, alle difficoltà di lifecycle management e alla minore qualità dell’identità dispositivo. In una rete di edificio seria la domanda corretta non è “qual è il metodo più facile da attivare”, ma “quale metodo è sostenibile nel mio contesto senza abbassare troppo il livello di fiducia”.
Il nodo critico: IoT, stampanti, telecamere, building systems
È qui che molti deployment 802.1X si rompono. Gli endpoint utente moderni possono quasi sempre essere gestiti con supplicant e policy. Gli oggetti tecnici di edificio, invece, no. Stampanti, telecamere, sensori, controllori, apparati medicali, sistemi OT leggeri, device embedded o soluzioni proprietarie spesso non hanno un supplicant 802.1X maturo o non sono gestibili con la stessa disciplina di un laptop. È in questo spazio che compare il MAC Authentication Bypass. Cisco, nella propria guida ufficiale su MAB, lo descrive come strumento per autenticare dispositivi che non sono capaci di IEEE 802.1X o che non hanno un utente, ma sottolinea anche che il design deve tener conto delle sue limitazioni.
Questo è il punto che un articolo serio non deve semplificare. MAB non è “equivalente” a 802.1X. È un compromesso. Offre visibilità e una forma di controllo migliore della porta aperta, ma resta basato su un identificatore debole come il MAC address, facilmente osservabile e imitabile in molti contesti. Quindi ha una sua legittimità operativa per dispositivi incapaci di fare altro, ma non deve essere raccontato come soluzione di sicurezza di pari livello. La scelta corretta non è eliminare MAB a priori; è relegarlo ai dispositivi che ne hanno davvero bisogno, confinarli in policy molto restrittive e considerarlo un fallback, non la base dell’architettura.
Onboarding: il punto in cui molte reti diventano incoerenti
L’onboarding è il passaggio più sottovalutato di tutto il tema NAC. Finché si parla di utenti gestiti in dominio, MDM o endpoint già provisionati, la rete sembra semplice. Ma appena compaiono BYOD, contractor, dispositivi mobili, endpoint temporanei e soprattutto IoT, il problema non è più solo “autenticare”, ma “come fare arrivare in sicurezza il dispositivo al punto in cui potrà autenticarsi nel modo giusto”.
NIST affronta questo esattamente come problema di instaurazione della fiducia prima dell’assegnazione delle credenziali di rete. Le build di riferimento pubblicate dal NCCoE mostrano approcci diversi proprio perché l’onboarding sicuro non è unico: può passare da certificati installati in fabbrica, bootstrap assistito, registrars, DPP, oppure da processi controllati di enrollment e issuance per arrivare poi a 802.1X con certificati X.509. In altri termini, l’errore è pensare che NAC inizi quando la porta fa la challenge EAP. In realtà NAC inizia prima, nel modo in cui decidi chi è legittimato a ricevere le credenziali o il profilo necessario per entrare.
Per il BYOD, le guide Cisco ISE mostrano la stessa complessità: esistono deployment single-SSID, dual-SSID, portali, issuance di certificati, regole diverse per sistema operativo e limitazioni pratiche, ad esempio sulla lunghezza della chain o sul comportamento di iOS durante l’emissione. Questo serve a capire un punto: l’onboarding è sempre il tratto più fragile del percorso, perché deve conciliare sicurezza, usabilità e supporto operativo.
Cosa cambia in una rete di edificio
La differenza reale non è solo più sicurezza “in generale”. Cambiano quattro cose molto concrete.
La prima è che la porta di accesso smette di essere neutra. Ogni porta cablata o SSID può diventare un punto di enforcement basato su identità, ruolo e stato del dispositivo. Questo rende la rete più governabile, ma anche più dipendente dalla qualità del disegno AAA, delle policy e della directory.
La seconda è che la segmentazione diventa più dinamica. Invece di assegnare VLAN statiche per stanza, piano o armadio, si può assegnare accesso in base al soggetto che entra. Questo migliora la sicurezza laterale e l’ordine architetturale, ma richiede coerenza tra access layer, policy engine e segmentazione a valle.
La terza è che i dispositivi non gestiti emergono come problema progettuale. Dove prima “funzionava tutto”, con NAC emergono subito eccezioni, apparati legacy, oggetti embedded e processi di onboarding assenti. Non è un difetto di NAC: è NAC che rende visibile il debito tecnico già esistente.
La quarta è che il supporto operativo cambia. Una rete con 802.1X e NAC ben fatti riduce gli accessi abusivi e migliora il controllo, ma richiede governance su certificati, scadenze, root trust, profili device, regole di fallback, monitoraggio dei fallimenti di autenticazione e troubleshooting più maturo. Microsoft e Cisco mostrano entrambi, in documentazione ufficiale, che l’abilitazione 802.1X su wired network comporta profili, certificati, supplicant settings e policy specifiche. Non è una feature da spuntare e dimenticare.
Dove è più facile cadere in errore
L’errore più frequente è voler applicare 802.1X in modo uniforme a tutto, come se tutti gli endpoint si comportassero allo stesso modo. Non è così. Utenti gestiti, BYOD, stampanti, telecamere, sistemi BMS e IoT vanno trattati con logiche diverse. Un’architettura seria accetta questa differenza e la governa; un’architettura ideologica la nega e poi moltiplica le eccezioni.
Il secondo errore è usare MAB come scorciatoia generalizzata. È comprensibile come fallback, ma diventa pericoloso quando sostituisce 802.1X anche dove quest’ultimo sarebbe praticabile.
Il terzo errore è costruire l’onboarding come eccezione manuale. Se l’enrollment dipende troppo da interventi umani, whitelist temporanee o procedure non ripetibili, il sistema non scala e si degrada rapidamente.
Il quarto errore è fermarsi all’autenticazione senza progettare l’autorizzazione. In quel caso si ottiene una barriera, non un NAC maturo.
Il quinto errore è non considerare il lifecycle. Certificati, dispositivi sostituiti, rotazione delle CA, modifiche delle policy, revoche e nuovi modelli IoT non sono eventi eccezionali: sono esercizio ordinario.
Quale approccio è più corretto
La risposta più seria è mista. Per gli endpoint gestiti, 802.1X con EAP-TLS resta in molti casi la base più robusta, a condizione che l’organizzazione sappia sostenere PKI e distribution dei certificati. Per i dispositivi che non supportano bene 802.1X, serve una strategia separata e più restrittiva, che può includere MAB, ma con segmenti dedicati, policy minimali e controllo rigoroso del perimetro. Per BYOD e onboarding temporaneo serve un flusso di enrollment esplicito, non improvvisato, con profili, portal o meccanismi di bootstrap che abbiano una logica di fiducia chiara. Per l’IoT nuovo, dove possibile, conviene considerare modelli di onboarding più forti e moderni, come quelli che NIST sta trattando nei propri lavori sul trusted onboarding e lifecycle management.
La conclusione corretta non è che 802.1X e NAC risolvano da soli il problema dell’accesso. Risolvono bene una parte del problema, e rendono visibili tutte le altre parti che una rete permissiva tende a nascondere. In una rete di edificio questo è esattamente il loro valore: non semplificano artificialmente la realtà, la rendono governabile. Se il progetto è maturo, il risultato è una rete più controllata, più segmentabile e più difendibile. Se il progetto è debole, 802.1X e NAC non lo mascherano: lo espongono.
