Cos'è l'EAP-TLS? Spiegazione dell'autenticazione WiFi basata su certificato
Questa guida fornisce un riferimento tecnico completo sull'EAP-TLS (Extensible Authentication Protocol con Transport Layer Security), il metodo di autenticazione 802.1X più sicuro disponibile per il WiFi aziendale. Copre l'infrastruttura di certificati X.509 richiesta, l'handshake di autenticazione reciproca e i modelli di implementazione pratica per i settori dell'ospitalità, del retail, della sanità e del settore pubblico. I manager IT, gli architetti di rete e i CTO troveranno indicazioni pratiche sulla progettazione PKI, sul provisioning dei certificati integrato con MDM, sulla configurazione RADIUS e sull'allineamento della conformità con PCI DSS e GDPR.
Ascolta questa guida
Visualizza trascrizione del podcast
Executive Summary
EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) è il metodo di autenticazione IEEE 802.1X che elimina completamente le credenziali condivise dalla catena di autenticazione wireless. Mentre PEAP ed EAP-TTLS si affidano a nomi utente e password trasmessi attraverso un tunnel crittografato, l'EAP-TLS richiede che sia il dispositivo client sia il server RADIUS presentino certificati X.509 validi emessi da un'Autorità di Certificazione (CA) fidata. Questo modello di autenticazione reciproca rende irrilevante una password rubata: senza un certificato valido e non revocato, un dispositivo non può accedere alla rete.
Per i gestori di sedi che offrono Guest WiFi in hotel, complessi commerciali o centri congressi, e per i team IT responsabili delle reti del personale e dei dispositivi IoT, l'EAP-TLS rappresenta l'attuale livello massimo di sicurezza per l'autenticazione wireless. È obbligatorio o fortemente raccomandato dallo standard PCI DSS 4.0 per gli ambienti con dati dei titolari di carta, dall'HIPAA per le reti wireless sanitarie, ed è il metodo richiesto per le distribuzioni WPA3 Enterprise a 192 bit (Suite B).
L'onere di implementazione è concreto — la gestione del ciclo di vita dei certificati, l'infrastruttura PKI e l'integrazione MDM sono complessi — ma il ROI in termini di sicurezza è sostanziale. Questa guida analizza l'architettura, l'handshake, i modelli di implementazione e le pratiche operative che determinano il successo o il blocco di un rollout EAP-TLS.
Approfondimento Tecnico
Come Funziona Effettivamente l'EAP-TLS
L'EAP-TLS opera all'interno del framework di controllo dell'accesso basato su porta 802.1X. I tre attori in ogni scambio di autenticazione sono il supplicant (il dispositivo client), l'authenticator (l'access point wireless o lo switch gestito) e l'authentication server (in genere un server RADIUS come FreeRADIUS, Microsoft NPS o Cisco ISE). L'access point non prende decisioni di autenticazione in autonomia: agisce come un relè trasparente, incapsulando i messaggi EAP in pacchetti RADIUS e inoltrandoli al server di autenticazione.
Per una comprensione più approfondita di come RADIUS supporti questa architettura, consulta Cos'è RADIUS? Come i Server RADIUS Proteggono le Reti WiFi .
L'handshake EAP-TLS si svolge come segue:
- L'access point invia un messaggio di EAP-Request/Identity al dispositivo che tenta la connessione.
- Il dispositivo risponde con la propria identità (comunemente un'identità esterna anonima per proteggere il nome utente da intercettazioni).
- Il server RADIUS avvia l'handshake TLS con un messaggio EAP-TLS/Start.
- Il client invia un messaggio di ClientHello, indicando le suite di cifratura TLS supportate.
- Il server RADIUS risponde con ServerHello, il suo certificato server X.509 e una richiesta di certificato.
- Il client convalida il certificato del server confrontandolo con il proprio archivio delle CA radice attendibili. Se la convalida non va a buon fine, l'handshake si interrompe, proteggendo la rete dai rogue access point.
- Il client presenta il proprio certificato client X.509.
- Il server RADIUS convalida il certificato del client: controlla la catena delle firme fino alla CA radice attendibile, verifica che il certificato non sia scaduto e consulta la Certificate Revocation List (CRL) o interroga il risponditore OCSP per confermare che il certificato non sia stato revocato.
- Entrambe le parti derivano le chiavi di sessione dal segreto master TLS. Il server RADIUS invia un messaggio di EAP-Success e l'access point apre la porta controllata.
L'intero scambio avviene prima che al dispositivo venga concesso qualsiasi tipo di accesso alla rete. In nessun momento viene trasmessa una password. Le chiavi di sessione derivate sono univoche per ciascuna sessione, garantendo la perfect forward secrecy quando si utilizzano le suite di cifratura ECDHE: questo significa che il traffico storico non può essere decifrato anche nel caso in cui un certificato venga compromesso in un secondo momento.
Certificati X.509 e architettura PKI
La sicurezza di EAP-TLS dipende interamente dall'integrità della PKI sottostante. Una tipica PKI aziendale per EAP-TLS si articola su tre livelli:
| Livello | Componente | Ruolo |
|---|---|---|
| Root CA | Autorità di certificazione radice offline | Firma i certificati delle CA intermedie; mantenuta isolata (air-gapped) |
| Intermediate CA | CA di emissione online | Rilascia i certificati del server e dei client; gestisce la pubblicazione delle CRL |
| End Entities | Certificato del server RADIUS + certificati dei client | Utilizzati nell'handshake di autenticazione live |
La CA radice deve essere mantenuta offline e isolata fisicamente. Se la sua chiave privata venisse compromessa, l'intera gerarchia dei certificati perderebbe di validità. La CA intermedia gestisce l'emissione quotidiana e pubblica la CRL. I certificati client vengono rilasciati ai singoli dispositivi (non agli utenti), solitamente con un Subject Alternative Name (SAN) che contiene l'indirizzo MAC del dispositivo o un identificatore del dispositivo proveniente dal vostro MDM.
EAP-TLS a confronto con altri metodi 802.1X
La tabella sopra illustra perché l'EAP-TLS è la scelta consigliata per gli ambienti regolamentati. Il PEAP-MSCHAPv2, che è tuttora il metodo 802.1X più diffuso, presenta vulnerabilità note: il certificato del server spesso non viene convalidato dai client (un errore di configurazione che espone ad attacchi tramite rogue AP) e lo stesso MSCHAPv2 è stato violato dal punto di vista crittografico fin dal 2012. L'EAP-TLS elimina entrambe le superfici di attacco.
WPA2 Enterprise e WPA3 Enterprise
EAP-TLS funziona allo stesso modo sia su WPA2 Enterprise (IEEE 802.11i) sia su WPA3 Enterprise (IEEE 802.11ax). La differenza risiede nella suite di cifratura negoziata per lo strato di crittografia dei dati wireless. WPA3 Enterprise impone i Protected Management Frames (PMF) e offre una modalità di sicurezza opzionale a 192 bit (Suite B) che richiede EAP-TLS con specifiche suite di cifratura a curve ellittiche (ECDHE + ECDSA o RSA-3072). Per la maggior parte delle implementazioni aziendali, lo stato finale ideale è rappresentato da WPA3 Enterprise con EAP-TLS e suite di cifratura AES-256 standard.
Guida all'implementazione
Fase 1: Progettazione e implementazione della PKI
Prima di configurare anche un solo access point, la PKI deve essere attiva. Per le organizzazioni prive di una CA interna esistente, Active Directory Certificate Services (AD CS) di Microsoft è la scelta più comune in ambienti Windows. Per implementazioni multipiattaforma o cloud-native, HashiCorp Vault PKI, EJBCA o un servizio PKI gestito come AWS Private CA rappresentano valide alternative.
Decisioni chiave in questa fase:
- Periodo di validità del certificato: I certificati client con validità di 1-2 anni bilanciano sicurezza e costi operativi. Periodi più brevi aumentano gli eventi di revoca; periodi più lunghi estendono la finestra di esposizione per un certificato compromesso.
- Algoritmo della chiave: RSA-2048 rimane ampiamente supportato. ECDSA P-256 offre una sicurezza equivalente con certificati di dimensioni ridotte e handshake più veloci — consigliato per le nuove installazioni.
- CRL vs. OCSP: La distribuzione CRL è più semplice da implementare ma introduce latenza e problemi di caching. OCSP fornisce lo stato di revoca in tempo reale. Per ambienti ad alta sicurezza, l'approccio preferito è l'OCSP stapling sul server RADIUS.
Fase 2: Configurazione del server RADIUS
Il server RADIUS deve essere configurato per:
- Presentare il proprio certificato server (emesso dalla CA interna) ai client che si connettono.
- Considerare attendibili solo le CA radice e intermedie interne per la convalida dei certificati client — non considerare attendibili le CA pubbliche per l'autenticazione dei client.
- Eseguire controlli CRL o OCSP su ogni certificato client presentato.
- Associare gli attributi del certificato (Common Name, SAN o estensioni OID) alle regole dei criteri di rete — ad esempio, assegnando i dispositivi a VLAN specifiche in base agli attributi del certificato.
Per una panoramica dettagliata dell'architettura e della configurazione del server RADIUS, fare riferimento a What Is RADIUS? How RADIUS Servers Secure WiFi Networks .
Fase 3: Distribuzione dei certificati tramite MDM/SCEP
L'installazione manuale dei certificati non è scalabile. Per qualsiasi implementazione che superi una manciata di dispositivi, il provisioning dei certificati deve essere automatizzato. L'approccio standard prevede:
- Dispositivi aziendali gestiti: Integrare la PKI con la piattaforma MDM (Microsoft Intune, Jamf, VMware Workspace ONE). Configurare un profilo SCEP o EST che richieda e installi automaticamente un certificato client al momento della registrazione del dispositivo. Il certificato viene associato al TPM o al Secure Enclave del dispositivo, laddove supportato, impedendone l'esportazione.
- BYOD e dispositivi dei fornitori: Distribuisci un portale di onboarding (come il portale Guest di Cisco ISE o una soluzione BYOD dedicata) che guidi l'utente attraverso un processo di installazione del certificato una tantum. Rilascia certificati con periodi di validità più brevi e limita l'accesso alla rete tramite policy VLAN.
- IoT e dispositivi headless: Utilizza SCEP con password di verifica pre-condivise o EST con credenziali di bootstrap. Il rinnovo del certificato deve essere automatizzato tramite lo stesso protocollo prima della scadenza.
Fase 4: Configurazione dell'Access Point e del SSID
Configura l'SSID aziendale con:
- Sicurezza: WPA2 Enterprise o WPA3 Enterprise (802.1X)
- Tipo di EAP: EAP-TLS
- Server RADIUS: Punta al tuo server di autenticazione con chiave segreta condivisa (shared secret)
- Assegnazione VLAN: Abilita l'assegnazione dinamica della VLAN tramite attributi RADIUS (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID)
- PMF: Obbligatorio per WPA3; fortemente raccomandato per WPA2
Fase 5: Configurazione del Supplicant del Client
Per i dispositivi Windows gestiti tramite Criteri di gruppo o Intune, distribuisci una policy di rete cablata/wireless che specifichi l'EAP-TLS, la CA root attendibile e i criteri di selezione del certificato. Su macOS e iOS, distribuisci un profilo di configurazione. Su Android, utilizza il profilo WiFi gestito tramite MDM. Elemento critico: imponi la validazione del certificato del server — specifica la CA esatta e il nome del server. Lasciare questa opzione deselezionata è l'errore di configurazione più comune nelle distribuzioni 802.1X.
Best Practice
Imponi la validazione del certificato del server su tutti i supplicant. L'errore di configurazione più vulnerabile nelle distribuzioni 802.1X riguarda i client che accettano qualsiasi certificato del server, consentendo attacchi tramite access point canaglia (rogue AP). Ogni profilo WiFi distribuito tramite MDM deve specificare la CA attendibile e il nome del server previsto (CN o SAN).
Automatizza il rinnovo del certificato prima della scadenza. Configura il monitoraggio per ricevere avvisi quando i certificati si trovano a meno di 30 giorni dalla scadenza. Configura il rinnovo automatico SCEP o EST in modo che i dispositivi rinnovino i certificati senza l'intervento dell'utente. Un evento di scadenza di massa dei certificati è uno degli incidenti più destabilizzanti che un team di rete aziendale possa affrontare.
Implementa OCSP anziché CRL dove possibile. I file CRL possono diventare di grandi dimensioni e vengono memorizzati nella cache dai client, il che significa che un certificato revocato di recente potrebbe essere ancora accettato fino alla scadenza della cache. OCSP fornisce lo stato in tempo reale ed è il meccanismo di revoca preferito per gli ambienti ad alta sicurezza.
Segmenta la tua PKI. Utilizza CA intermedie separate per diverse classi di certificati: una per i certificati del server RADIUS, una per i certificati dei dispositivi client, una per i certificati utente. Questo limita la portata di un eventuale compromesso della CA e semplifica le policy di revoca.
Registra e monitora gli eventi di autenticazione. Il tuo server RADIUS genera un log di autenticazione per ogni tentativo di connessione. Invia questi log al tuo SIEM. Pattern come fallimenti di autenticazione ripetuti, errori di validazione del certificato o connessioni da indirizzi MAC imprevisti sono indicatori precoci di una configurazione errata o di un attacco. Allineamento con lo standard PCI DSS 4.0. Il requisito 8.6 impone un'autenticazione forte per i componenti di sistema. Per le reti wireless incluse nell'ambito del PCI DSS, EAP-TLS con autenticazione basata su certificati soddisfa il requisito di autenticazione a più fattori a livello di rete, poiché il certificato (qualcosa che si ha) combinato con la chiave privata legata al TPM del dispositivo (qualcosa che si è) costituisce due fattori.
Risoluzione dei Problemi e Mitigazione del Rischio
Modalità di Guasto Comuni
| Modalità di Guasto | Sintomo | Causa Radice | Soluzione |
|---|---|---|---|
| Errore di convalida della catena di certificati | EAP-Failure dopo lo scambio del certificato del server | Il client non si fida della CA del server RADIUS | Distribuire il certificato della CA radice nel trust store del dispositivo tramite MDM |
| Certificato client non presentato | L'autenticazione si interrompe dopo il certificato del server | Nessun certificato client installato o certificato errato selezionato | Verificare il completamento dell'iscrizione SCEP; controllare il profilo MDM |
| OCSP/CRL non raggiungibile | Errori di autenticazione intermittenti | Il server RADIUS non può raggiungere l'endpoint di revoca | Assicurarsi che gli URL OCSP/CRL siano accessibili dal server RADIUS; implementare il caching locale delle CRL |
| Certificato scaduto | Tutti i dispositivi non superano l'autenticazione contemporaneamente | Automazione del rinnovo non configurata | Implementare avvisi di scadenza a 30 giorni; configurare il rinnovo automatico SCEP |
| Attacco Rogue AP | Gli utenti si connettono a un AP dannoso | Convalida del certificato del server disabilitata sul supplicant | Forzare la convalida del certificato del server in tutti i profili WiFi dell'MDM |
| Errore di assegnazione della VLAN | Il dispositivo si connette ma ottiene il segmento di rete errato | Attributi RADIUS configurati in modo errato | Verificare Tunnel-Type (13=VLAN), Tunnel-Medium-Type (6=802), Tunnel-Private-Group-ID (VLAN ID) |
Mitigazione del Rischio per Distribuzioni su Larga Scala
Per gli ambienti del settore hospitality con centinaia di punti di accesso distribuiti su più proprietà, e per le catene retail con sedi distribuite, il rischio operativo principale è un evento di scadenza sincronizzata dei certificati. Scaglionare le date di emissione dei certificati tra i vari gruppi di dispositivi in modo che i rinnovi siano distribuiti nel tempo anziché avvenire simultaneamente. Mantenere un inventario dei certificati nel proprio MDM ed eseguire report settimanali sui certificati in scadenza entro 60 giorni.
Per gli ambienti del settore healthcare , il rischio aggiuntivo è la latenza di autenticazione che influisce sui flussi di lavoro clinici. Ottimizzare il posizionamento del server RADIUS per ridurre al minimo il tempo di andata e ritorno. Prendere in considerazione la distribuzione di server proxy RADIUS in ciascuna sede per ridurre la dipendenza dalla rete WAN per l'autenticazione.
ROI e Impatto Aziendale
Quantificare l'Investimento in Sicurezza
Il caso aziendale per EAP-TLS rispetto all'802.1X basato su password è evidente se confrontato con i costi delle violazioni dei dati. Il costo medio di una violazione dei dati nel Regno Unito nel 2024 è stato di 3,58 milioni di sterline (Rapporto IBM Cost of a Data Breach). Una percentuale significativa di violazioni aziendali ha origine da credenziali compromesse. EAP-TLS elimina completamente il vettore di furto delle credenziali per l'accesso alla rete.
Per le organizzazioni soggette a PCI DSS, una violazione della rete wireless che comporti l'esposizione dei dati dei titolari di carta comporta sanzioni, costi per indagini forensi e potenziali penalità da parte dei circuiti delle carte che superano di gran lunga il costo dell'implementazione di una PKI. L'allineamento della conformità da solo giustifica l'investimento per qualsiasi organizzazione che elabori pagamenti con carta su infrastruttura wireless.
Guadagni in Termini di Efficienza Operativa
Contrariamente a quanto si potrebbe pensare, un'implementazione EAP-TLS ben eseguita con provisioning dei certificati integrato con l'MDM può ridurre il carico dell'helpdesk rispetto all'802.1X basato su password. I ripristini delle password, la gestione delle credenziali condivise e i ticket relativi a "perché non riesco a connettermi al WiFi" vengono eliminati. L'impegno di implementazione iniziale è concentrato nella fase iniziale, ma le operazioni a regime richiedono un intervento minimo.
Per i gestori di sedi che implementano WiFi Analytics insieme a reti sicure per il personale, la segmentazione abilitata da EAP-TLS e dall'assegnazione dinamica delle VLAN consente di separare nettamente il traffico degli ospiti, il traffico del personale e il traffico dei dispositivi IoT sulla stessa infrastruttura fisica, riducendo i costi dell'hardware e migliorando al contempo il livello di sicurezza.
Il Ruolo di Purple nella Sicurezza del WiFi Aziendale
La piattaforma di Purple opera all'intersezione tra il Guest WiFi e l'intelligence delle reti aziendali. Per le reti del personale e dei dispositivi aziendali, EAP-TLS fornisce il livello di autenticazione. La piattaforma WiFi Analytics di Purple si colloca al di sopra di questo, fornendo visibilità sui pattern di utilizzo della rete, sui tempi di permanenza dei dispositivi e sull'affluenza della sede — dati che hanno significato solo quando la rete sottostante è adeguatamente segmentata e autenticata.
Per le organizzazioni che esplorano la connettività fluida basata su OpenRoaming e Passpoint all'interno delle sedi, Purple agisce come un identity provider gratuito con la licenza Connect, sfruttando lo stesso framework di identità basato su 802.1X e certificati che supporta EAP-TLS. Ciò posiziona EAP-TLS non solo come un controllo di sicurezza, ma come la base per servizi di connettività avanzati in hub di trasporto , complessi commerciali e strutture ricettive.
Per gli architetti di rete che valutano l'intersezione tra SD-WAN e la sicurezza del WiFi aziendale, The Core SD-WAN Benefits for Modern Businesses fornisce un contesto complementare su come l'autenticazione sicura si integra con le moderne architetture WAN.
Definizioni chiave
EAP-TLS (Extensible Authentication Protocol – Transport Layer Security)
Un metodo di autenticazione 802.1X definito nella RFC 5216 che utilizza l'autenticazione reciproca dei certificati X.509 tra il dispositivo client e il server RADIUS. Nessuna delle due parti ottiene l'accesso alla rete senza presentare un certificato valido, non revocato e firmato da un'Autorità di Certificazione (CA) fidata.
I team IT incontrano EAP-TLS quando valutano i metodi di autenticazione 802.1X per le distribuzioni WPA2 Enterprise o WPA3 Enterprise. È il metodo consigliato per gli ambienti regolamentati (PCI DSS, HIPAA, ISO 27001) e il metodo richiesto per WPA3 Enterprise a 192 bit (Suite B).
Certificato X.509
Uno standard di certificato digitale (definito in ITU-T X.509 e RFC 5280) che associa una chiave pubblica a un'identità (dispositivo, server o utente). Contiene l'identità del soggetto, la chiave pubblica, la firma digitale della CA emittente e le date di validità. In EAP-TLS, sia il server RADIUS che il dispositivo client presentano certificati X.509 durante l'handshake di autenticazione.
I team IT utilizzano i certificati X.509 durante la configurazione dei server RADIUS (certificato server), la registrazione dei dispositivi tramite MDM (certificato client) e la gestione dell'infrastruttura PKI. La scadenza e la revoca dei certificati rappresentano le principali preoccupazioni operative.
PKI (Public Key Infrastructure)
La combinazione di hardware, software, policy e procedure necessarie per creare, gestire, distribuire, memorizzare e revocare certificati digitali. In una distribuzione EAP-TLS, la PKI è composta almeno da una CA radice e da una CA emittente, oltre all'infrastruttura CRL/OCSP per la revoca.
La PKI è la dipendenza fondamentale per qualsiasi distribuzione EAP-TLS. I team IT devono progettare e gestire una PKI prima di poter distribuire EAP-TLS. Le piattaforme PKI più comuni includono Microsoft AD CS, EJBCA, HashiCorp Vault PKI e servizi gestiti come AWS Private CA.
RADIUS (Remote Authentication Dial-In User Service)
Un protocollo di rete (RFC 2865) che fornisce autenticazione, autorizzazione e tracciamento (AAA) centralizzati per l'accesso alla rete. Nelle distribuzioni 802.1X/EAP-TLS, il server RADIUS convalida i certificati client, applica le policy di rete e restituisce gli attributi di assegnazione VLAN all'access point.
RADIUS è il componente del server di autenticazione in ogni distribuzione 802.1X. Le implementazioni comuni includono Microsoft NPS, FreeRADIUS, Cisco ISE e Aruba ClearPass. Il server RADIUS deve essere configurato per considerare fidata la CA interna ed eseguire controlli di revoca dei certificati.
Autenticazione Reciproca
Un processo di autenticazione in cui entrambe le parti comunicanti verificano l'identità dell'altra prima di stabilire una connessione. In EAP-TLS, il client convalida il certificato del server RADIUS (proteggendo dagli AP non autorizzati) e il server RADIUS convalida il certificato del client (proteggendo dall'accesso di dispositivi non autorizzati).
L'autenticazione reciproca è il fattore differenziante chiave di EAP-TLS rispetto a PEAP ed EAP-TTLS. I team IT dovrebbero sottolineare l'autenticazione reciproca quando giustificano l'uso di EAP-TLS di fronte ad auditor di sicurezza e team di conformità, poiché contrasta direttamente i vettori di minaccia legati ad AP non autorizzati e furto di credenziali.
SCEP (Simple Certificate Enrollment Protocol)
Un protocollo (originariamente definito da Cisco, standardizzato in RFC 8894) che consente richieste e rilascio automatizzati di certificati tra un dispositivo client e un'Autorità di Certificazione. Nelle distribuzioni EAP-TLS, SCEP viene utilizzato dalle piattaforme MDM per fornire automaticamente i certificati client ai dispositivi gestiti senza l'intervento dell'utente.
SCEP è il meccanismo standard per il provisioning di certificati zero-touch negli ambienti MDM aziendali. I team IT configurano i profili SCEP in Intune, Jamf o Workspace ONE per automatizzare la distribuzione e il rinnovo dei certificati client.
CRL (Certificate Revocation List)
Un elenco pubblicato periodicamente di numeri di serie di certificati che sono stati revocati dalla CA emittente prima della loro data di scadenza. I server RADIUS controllano la CRL per garantire che un certificato client presentato durante l'autenticazione EAP-TLS non sia stato revocato (ad esempio, a causa del furto del dispositivo o dell'uscita di un dipendente).
La gestione della CRL è una considerazione operativa critica nelle distribuzioni EAP-TLS. I team IT devono garantire che il punto di distribuzione della CRL sia accessibile dai server RADIUS, che le CRL siano pubblicate con frequenza sufficiente a riflettere le revoche recenti e che i server RADIUS siano configurati per rifiutare l'autenticazione se non è possibile recuperare la CRL.
OCSP (Online Certificate Status Protocol)
Un protocollo di verifica della revoca dei certificati in tempo reale (RFC 6960) che consente a un server RADIUS di interrogare il responder OCSP della CA per verificare lo stato corrente di uno specifico certificato, invece di scaricare e analizzare una CRL completa. OCSP fornisce una latenza inferiore e informazioni sulla revoca più aggiornate rispetto al controllo basato su CRL.
I team IT dovrebbero preferire OCSP rispetto alla CRL per gli ambienti ad alta sicurezza in cui la revoca in tempo reale è importante (ad esempio, la revoca immediata di un certificato quando un dispositivo viene segnalato come rubato). Lo stapling OCSP, in cui il server RADIUS memorizza nella cache e presenta la risposta OCSP, riduce la latenza ed elimina la dipendenza dalla raggiungibilità del responder OCSP durante ogni autenticazione.
802.1X (Port-Based Network Access Control)
Uno standard IEEE che fornisce un framework di autenticazione per i dispositivi che tentano di connettersi a una LAN o WLAN. Definisce tre ruoli: supplicant (il dispositivo che si connette), authenticator (l'access point o lo switch) e server di autenticazione (RADIUS). EAP-TLS è uno dei diversi metodi EAP che possono essere utilizzati all'interno del framework 802.1X.
L'802.1X è il framework generale all'interno del quale opera EAP-TLS. I team IT incontrano l'802.1X durante la configurazione di SSID WPA2 Enterprise o WPA3 Enterprise e durante la configurazione dell'autenticazione delle porte cablate sugli switch gestiti. La comprensione di 802.1X è un prerequisito per la distribuzione di EAP-TLS.
Perfect Forward Secrecy (PFS)
Una proprietà crittografica dei protocolli di scambio delle chiavi che garantisce che le chiavi di sessione non possano essere derivate dalla chiave privata a lungo termine. In EAP-TLS con suite di cifratura ECDHE, ogni sessione genera una coppia di chiavi effimere unica, il che significa che la compromissione della chiave privata del certificato non espone il traffico delle sessioni passate.
I team IT dovrebbero specificare suite di cifratura basate su ECDHE durante la configurazione di EAP-TLS per garantire la PFS. Ciò è particolarmente importante negli ambienti in cui il traffico di rete viene registrato e potrebbe essere soggetto a futuri tentativi di decrittografia (uno scenario di attacco "registra ora, decifra più tardi").
Esempi pratici
Un gruppo alberghiero di 12 strutture con 450 camere ha la necessità di migrare il WiFi del personale da PEAP-MSCHAPv2 a EAP-TLS. Il gruppo dispone di laptop Windows 10/11 gestiti tramite Microsoft Intune, oltre a circa 200 tablet Android utilizzati dal personale delle pulizie. Il team IT non dispone di una PKI interna esistente. Qual è l'approccio di implementazione consigliato?
Fase 1 — Implementazione della PKI (Settimane 1–3): Distribuire Microsoft AD CS con una gerarchia a due livelli. Configurare una root CA offline su un server dedicato che verrà spento dopo la configurazione iniziale. Distribuire una CA emittente online (CA intermedia) su una VM Windows Server. Configurare la CA emittente per pubblicare le CRL su un server web interno accessibile da tutti i server RADIUS in tutte le 12 strutture. Abilitare il ruolo di risponditore OCSP sul server della CA emittente.
Fase 2 — Infrastruttura RADIUS (Settimane 2–4): Distribuire Microsoft NPS (Network Policy Server) in ciascuna struttura, oppure centralizzare con server proxy NPS in ogni sito che puntano a un cluster NPS centrale. Rilasciare un certificato del server RADIUS dalla CA interna a ciascuna istanza NPS. Configurare i criteri di rete NPS: metodo di autenticazione = EAP-TLS, root CA attendibile = root CA interna, convalida del certificato = abilitata, assegnazione VLAN tramite attributi RADIUS.
Fase 3 — Profili dei certificati Intune (Settimane 3–5): In Microsoft Intune, creare un profilo Certificato attendibile per distribuire il certificato della root CA a tutti i dispositivi gestiti. Creare un profilo di certificato SCEP destinato alla CA emittente, con formato del nome del soggetto CN={{DeviceId}}, utilizzo chiave = Firma digitale, utilizzo chiave avanzato = Autenticazione client. Creare un profilo WiFi specificando EAP-TLS, il profilo del certificato SCEP come certificato client e la root CA come autorità di certificazione server attendibile.
Fase 4 — Registrazione dei tablet Android (Settimane 4–6): Registrare i tablet Android in Intune tramite Android Enterprise (modalità Dispositivo dedicato). Distribuire i profili di configurazione equivalenti di Certificato attendibile, Certificato SCEP e WiFi. Verificare l'installazione dei certificati su un gruppo pilota di 10 tablet prima della distribuzione completa.
Fase 5 — Progetto pilota e transizione (Settimane 6–8): Eseguire EAP-TLS in parallelo con PEAP su un SSID separato in una struttura pilota. Convalidare i tassi di successo dell'autenticazione, l'assegnazione delle VLAN e il comportamento di rinnovo dei certificati. Procedere con la distribuzione struttura per struttura. Dismettere l'SSID PEAP dopo un periodo di esecuzione in parallelo di 30 giorni in ciascun sito.
Una catena di vendita al dettaglio nazionale con 280 negozi deve proteggere la propria rete WiFi dei punti vendita (POS) per soddisfare i requisiti PCI DSS 4.0. Ogni negozio dispone di 8-15 terminali POS basati su Windows, un mix di dispositivi gestiti e non gestiti, e un unico amministratore IT che gestisce tutti i negozi da remoto. La catena utilizza attualmente una password WPA2-PSK condivisa in tutti i negozi. Qual è il percorso di migrazione a EAP-TLS?
Valutazione e definizione dell'ambito: Innanzitutto, definire l'ambito dell'ambiente dei dati dei titolari di carta (CDE) secondo lo standard PCI DSS. I terminali POS che elaborano i dati delle carte rientrano nell'ambito; i dispositivi delle sale relax del personale no. Segmentare la rete in modo che solo i terminali POS si trovino sull'SSID protetto da EAP-TLS. Ciò limita l'ambito di distribuzione dei certificati a una popolazione di dispositivi noti e gestiti.
PKI e RADIUS centralizzati: Distribuire un servizio RADIUS ospitato nel cloud (ad esempio, Cisco ISE nel cloud o JumpCloud RADIUS) per eliminare la necessità di hardware RADIUS on-premise in ciascun negozio. Questo passaggio è fondamentale per una rete di vendita al dettaglio distribuita in cui la gestione dei server locali non è praticabile. Il servizio RADIUS cloud si connette alla PKI interna tramite un tunnel sicuro.
Distribuzione dei certificati basata su MDM: Tutti i terminali POS devono essere registrati in un MDM (Microsoft Intune o equivalente). Distribuire l'ancora di attendibilità della root CA e il profilo del certificato SCEP tramite la policy MDM. Il soggetto del certificato deve includere il numero del negozio e l'ID del terminale (ad es. CN=POS-STORE042-TERM003) per consentire policy RADIUS granulari e la registrazione dei log di controllo.
Configurazione dell'SSID: Configurare un SSID POS dedicato su ciascun access point del negozio con WPA2 Enterprise / EAP-TLS. Utilizzare l'assegnazione dinamica della VLAN per collocare i terminali POS autenticati sulla VLAN CDE. Implementare un SSID guest separato su una VLAN completamente isolata per il WiFi dei clienti.
Monitoraggio e prove di conformità: Configurare i registri di autenticazione RADIUS affinché vengano inoltrati a un SIEM centrale. Generare report mensili che mostrino i tassi di successo dell'autenticazione, lo stato di validità dei certificati e gli eventuali eventi di revoca. Questi dati di log costituiscono prove di controllo per il Requisito 10 di PCI DSS (registrazione e monitoraggio) e per il Requisito 8.6 (gestione dell'autenticazione).
Domande di esercitazione
Q1. La tua organizzazione gestisce un ospedale da 600 posti letto con 1.200 laptop Windows aziendali e 400 tablet Android condivisi utilizzati dal personale infermieristico. Il Wi-Fi attuale utilizza PEAP-MSCHAPv2 con credenziali Active Directory. Un recente penetration test ha rilevato che nessuno dei dispositivi client convalida il certificato del server RADIUS e il tester ha eseguito con successo un attacco rogue AP catturando le credenziali AD. Ti è stato chiesto di rimediare a questa situazione entro 90 giorni. Qual è il tuo piano di remediation prioritario?
Suggerimento: Considera cosa può essere risolto immediatamente (modifica della configurazione) rispetto a ciò che richiede un intervento sull'infrastruttura (implementazione PKI). Non tutti i passaggi di remediation richiedono EAP-TLS — alcuni possono essere applicati all'attuale distribuzione PEAP mentre si pianifica la migrazione a lungo termine.
Visualizza risposta modello
Immediato (Settimane 1–2): Correggere la convalida del certificato del server sulla distribuzione PEAP esistente. Distribuisci un aggiornamento del profilo Wi-Fi tramite GPO/Intune a tutti i dispositivi Windows gestiti, specificando la CA radice attendibile e il CN/SAN previsto del server RADIUS. Questo chiude immediatamente la vulnerabilità rogue AP senza richiedere modifiche alla PKI. Per i tablet Android, distribuisci un profilo Wi-Fi MDM aggiornato. Questo risolve il problema critico in pochi giorni.
A breve termine (Settimane 2–8): Implementare una PKI interna. Configura una PKI AD CS a due livelli (CA radice offline + CA emittente online). Rilascia un nuovo certificato del server RADIUS dalla CA interna. Aggiorna la configurazione NPS. Distribuisci la nuova CA radice attendibile a tutti i dispositivi tramite MDM.
A medio termine (Settimane 6–12): Migrare a EAP-TLS per i dispositivi gestiti. Configura i profili SCEP in Intune per i laptop Windows. Distribuisci i profili dei certificati client. Crea un nuovo SSID EAP-TLS in parallelo all'SSID PEAP esistente. Avvia un progetto pilota con 50 laptop, convalida e poi procedi con il roll-out a ondate. I tablet Android condivisi presentano una complessità maggiore: valuta se la registrazione come Android Enterprise Dedicated Device sia fattibile o se un portale di onboarding basato su certificati sia più appropriato per i dispositivi a uso condiviso.
Considerazione chiave: Il GDPR e le normative sanitarie richiedono tutele adeguate per le reti wireless che trasmettono dati sensibili. La vulnerabilità rogue AP rappresenta un rischio da segnalare. Documenta la tempistica di remediation e i controlli provvisori per il tuo responsabile della conformità.
Q2. Un centro congressi sta implementando una nuova infrastruttura Wi-Fi per supportare sia una rete sicura per il personale (EAP-TLS) sia una rete Wi-Fi per gli ospiti. La struttura ospita eventi fino a 5.000 partecipanti. L'IT manager desidera utilizzare la stessa infrastruttura fisica di access point per entrambe le reti. Come dovrebbe essere progettata la rete per raggiungere questo obiettivo e quali sono le decisioni di configurazione chiave?
Suggerimento: Considera la segmentazione degli SSID, la progettazione delle VLAN e i diversi requisiti di autenticazione per il personale (basata su certificati) rispetto agli ospiti (Captive Portal o social login). Pensa a come la piattaforma guest Wi-Fi di Purple si integra con questa architettura.
Visualizza risposta modello
Progettazione SSID e VLAN: Distribuisci due SSID sulla stessa infrastruttura fisica di access point. SSID 1 (Staff): WPA3 Enterprise / EAP-TLS, con trasmissione sulle bande a 5GHz e 6GHz, mappato sulla VLAN Staff (es. VLAN 10). SSID 2 (Guest): WPA3 Personal o Open con OWE (Opportunistic Wireless Encryption), mappato sulla VLAN Guest (es. VLAN 20). La VLAN Guest non deve avere alcun accesso alla VLAN Staff o all'infrastruttura interna, ma solo l'accesso a Internet.
Rete Staff: Configura il server RADIUS con policy EAP-TLS. Rilascia certificati client a tutti i dispositivi del personale tramite MDM. Utilizza l'assegnazione dinamica della VLAN per inserire i dispositivi del personale autenticati sulla VLAN 10. Prendi in considerazione l'implementazione di un SSID separato per le apparecchiature AV/gestione eventi sulla VLAN 30 con EAP-TLS e una policy di certificati dedicata.
Rete Guest: Integra la piattaforma Guest WiFi di Purple per l'autenticazione tramite Captive Portal, social login o acquisizione email. La rete ospiti opera in modo completamente indipendente dall'infrastruttura EAP-TLS. La piattaforma WiFi Analytics di Purple fornisce dati sul tempo di permanenza, sull'affluenza e sull'engagement provenienti dalla rete ospiti.
Pianificazione della capacità: Per 5.000 ospiti simultanei, assicurati che lo scope DHCP della VLAN guest, l'uplink Internet e la densità degli access point siano dimensionati in modo appropriato. L'autenticazione EAP-TLS aggiunge un sovraccarico trascurabile per connessione, ma la capacità del server RADIUS dovrebbe essere validata per i picchi di carico durante gli eventi.
Q3. Il CTO di un'azienda retail sta valutando se implementare EAP-TLS per 350 negozi o continuare con WPA2-PSK con una chiave condivisa a rotazione. Il team IT è piccolo (3 persone) e non ha esperienza con le PKI. La preoccupazione principale del CTO è la conformità PCI DSS per la rete POS. Qual è la tua raccomandazione e come imposteresti il business case?
Suggerimento: Considera i requisiti PCI DSS, la capacità operativa di un team IT ridotto e la presenza di opzioni di servizio gestito che riducano l'onere della PKI. La risposta non è necessariamente 'distribuire immediatamente EAP-TLS' — un approccio graduale o gestito potrebbe essere più appropriato.
Visualizza risposta modello
Raccomandazione: EAP-TLS tramite un servizio RADIUS e PKI gestito, con implementazione graduale nell'arco di 6 mesi.
WPA2-PSK non è accettabile per un ambiente di dati dei titolari di carta conforme a PCI DSS. Il requisito 8 del PCI DSS impone l'autenticazione individuale per i componenti di sistema e una PSK condivisa non soddisfa questo criterio. Una compromissione della PSK espone simultaneamente tutti i 350 negozi. Il rischio non è teorico: le violazioni della rete POS tramite credenziali Wi-Fi compromesse sono un vettore di attacco documentato nel settore retail.
Approccio con servizio gestito: Invece di sviluppare competenze PKI interne, affidati a un provider RADIUS e PKI gestito (es. Foxpass, JumpCloud o SecureW2). Questi servizi forniscono un server RADIUS in hosting, una CA gestita e l'integrazione MDM nativa. Il team IT configura i profili dei certificati MDM e le impostazioni RADIUS degli access point — non è richiesta alcuna competenza PKI. Il costo è in genere di $3–8 per dispositivo al mese, una cifra irrisoria rispetto al costo di una violazione PCI DSS.
Business Case: Inquadra l'investimento rispetto a tre categorie di costo: (1) sanzioni per non conformità PCI DSS e costi di investigazione forense a seguito di una violazione — in genere da £50k a £500k per un retailer di medie dimensioni; (2) penali dei circuiti di carte di pagamento per una violazione dei dati dei titolari di carta — potenzialmente milioni; (3) danno reputazionale e perdita di clienti. Il costo del servizio gestito per 350 negozi con 15 terminali POS ciascuno (5.250 dispositivi) a $5/dispositivo/mese è di circa $26.250/mese — meno del costo giornaliero di un'indagine su una violazione dei dati.
Continua a leggere questa serie
PSK per dispositivo per fornitore: confronto tra iPSK, DPSK, MPSK e PPSK (e supporto WPA3)
Un confronto completo delle implementazioni PSK per dispositivo tra Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Scopri come WPA3-SAE influisce sulle strategie delle chiavi per dispositivo e quando distribuire le modalità di transizione rispetto al passaggio a 802.1X.
Metodi di autenticazione del Captive Portal a confronto
Questa guida di riferimento tecnico autorevole valuta i compromessi architetturali, operativi e di conformità di cinque metodi di autenticazione principali per captive portal. Fornisce ad architetti di rete, direttori IT e marketing manager i dati quantitativi e i framework decisionali necessari per bilanciare l'attrito nell'onboarding degli ospiti con i requisiti di raccolta dati all'interno delle sedi aziendali.
Cos'è l'autenticazione tramite indirizzo MAC? Quando usarla e quando evitarla
Questa guida tecnica di riferimento autorevole copre l'autenticazione tramite indirizzo MAC negli ambienti WiFi aziendali: come funziona l'autenticazione MAC basata su RADIUS a livello Layer 2, le sue vulnerabilità di sicurezza intrinseche (incluso il MAC spoofing e l'impatto della randomizzazione MAC a livello di sistema operativo) e i precisi contesti operativi in cui rimane uno strumento valido per la gestione di dispositivi IoT e headless. Fornisce linee guida di implementazione pratiche per responsabili IT e architetti di rete nei settori dell'ospitalità, del retail, della sanità e dei luoghi pubblici, con esempi pratici reali, framework decisionali e contesti di integrazione per la piattaforma di guest WiFi e analytics di Purple.