EAP-TLS vs EAP-TTLS: Which Certificate-Based WiFi Protocol Should You Choose?

Questa guida fornisce un confronto definitivo tra EAP-TLS ed EAP-TTLS per l'autenticazione WiFi aziendale secondo lo standard IEEE 802.1X. Spiega la differenza architetturale tra l'autenticazione a certificato mutuo e il tunnelling di certificati solo server, e offre a IT manager, architetti di rete e CISO un quadro decisionale chiaro basato sulle capacità di gestione dei dispositivi e sui requisiti di conformità. Purple supporta entrambi i percorsi di autenticazione EAP-TLS ed EAP-TTLS per il WiFi del personale (Staff WiFi), e questa guida aiuta le organizzazioni a comprendere i compromessi infrastrutturali prima di impegnarsi in uno dei due approcci.

📖 9 minuti di lettura📝 2,090 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

INTRODUZIONE E CONTESTO (0:00 - 2:00)

Benvenuti a questo briefing tecnico di Purple. Sono il vostro ospite e oggi analizzeremo le differenze fondamentali tra EAP-TLS e EAP-TTLS per l'autenticazione WiFi aziendale. Se siete network architect, IT director o gestite l'infrastruttura per grandi spazi come catene retail, ospedali o stadi, questo briefing è pensato appositamente per voi. Andremo dritti al punto per discutere l'architettura di sicurezza, i compromessi di implementazione e come scegliere il protocollo giusto per il vostro ambiente. Entriamo subito nel vivo.

Prima di addentrarci nei protocolli stessi, contestualizziamo lo scenario. La maggior parte delle distribuzioni WiFi aziendali oggi si basa ancora su un'unica password condivisa: una chiave precondivisa, o PSK. Ogni dispositivo sulla rete utilizza la stessa credenziale. Quando un dipendente se ne va o un dispositivo viene smarrito, si hanno due opzioni: cambiare la password per tutti o accettare il rischio che un ex dipendente o un malintenzionato abbia ancora credenziali valide. Nessuna delle due è accettabile per un'azienda seria.

La risposta è 802.1X, lo standard IEEE per il controllo dell'accesso alla rete basato su porta. L'802.1X fornisce a ciascun dispositivo la propria credenziale di autenticazione individuale. Quando un dispositivo si connette, l'access point non concede l'accesso direttamente. Inoltra la richiesta di autenticazione a un server RADIUS centralizzato, che verifica la credenziale e comunica all'access point se aprire la porta. Il risultato è un controllo degli accessi per singolo dispositivo, verificabile e revocabile. Questa è la base su cui sono costruiti sia EAP-TLS e EAP-TTLS.

Entrambi i protocolli sono metodi Extensible Authentication Protocol, o metodi EAP, che operano all'interno di questo framework 802.1X. La domanda non è se utilizzare l'802.1X, ma quale metodo EAP utilizzare al suo interno. Ed è proprio a questo che risponderemo oggi.

APPROFONDIMENTO TECNICO SU EAP-TLS (2:00 - 5:30)

Iniziamo con EAP-TLS, acronimo di Transport Layer Security. EAP-TLS è definito nella RFC 5216 ed è ampiamente considerato lo standard di riferimento per l'autenticazione wireless. Il principio cardine è l'autenticazione reciproca. Sia il dispositivo client che il server RADIUS devono presentare certificati digitali X.509 validi per dimostrare la propria identità prima che venga concesso l'accesso alla rete. Non sono coinvolte password in nessuna fase del processo. Zero.

Questo è estremamente importante dal punto di vista della sicurezza. Le password possono essere soggette a phishing, possono essere indovinate tramite attacchi brute force o rubate a seguito di una violazione dei dati su un servizio di terze parti in cui il dipendente ha riutilizzato la stessa password. I certificati non possono essere oggetto di phishing, non possono essere indovinati e sono vincolati a un dispositivo specifico. Se un malintenzionato vuole accedere alla vostra rete, ha bisogno del dispositivo fisico e della sua chiave privata crittografica integrata. Si tratta di un modello di minaccia fondamentalmente diverso.
Permettimi di illustrarti nel dettaglio l'handshake EAP-TLS, perché comprenderlo chiarirà il motivo per cui questo protocollo è così sicuro. Quando un dispositivo tenta di connettersi alla rete WiFi, l'access point invia una richiesta EAP-Request per l'identità del dispositivo. Il dispositivo risponde. L'access point inoltra la richiesta al server RADIUS. Il server RADIUS avvia l'handshake TLS inviando un messaggio Server Hello, insieme al suo certificato X.509. Il client convalida questo certificato del server confrontandolo con il proprio archivio delle Certification Authority radice attendibili. Se la convalida fallisce, l'handshake si interrompe immediatamente. Il dispositivo rifiuta di connettersi. Questo è ciò che protegge dagli attacchi Evil Twin, in cui un hacker configura un access point fittizio per impersonare la tua rete.

Se il certificato del server è valido, il client presenta il proprio certificato X.509 al server RADIUS. Il server RADIUS convalida il certificato del client: controlla la catena di firma risalendo fino alla CA radice attendibile, verifica che il certificato non sia scaduto e controlla la Certificate Revocation List per garantire che il certificato non sia stato revocato. Solo quando entrambe le parti sono soddisfatte viene stabilito il tunnel TLS e viene inviato il messaggio EAP-Success, che concede l'accesso alla rete. L'intero scambio utilizza TLS 1.2 o 1.3, garantendo una perfect forward secrecy.

Questo livello di sicurezza comporta tuttavia un requisito operativo: è necessaria una Public Key Infrastructure, o PKI. Come minimo, occorrono una Certification Authority radice offline e una Certification Authority di emissione online. La CA radice dovrebbe essere isolata (air-gapped), poiché la sua chiave privata è l'ancora di attendibilità principale per l'intera gerarchia dei certificati. La CA di emissione gestisce il rilascio quotidiano dei certificati e pubblica la Certificate Revocation List. Inoltre, aspetto critico, serve un meccanismo per distribuire i certificati client su ogni dispositivo della rete. Per un parco di migliaia di dispositivi, ciò significa integrare la PKI con una piattaforma di Mobile Device Management utilizzando SCEP (Simple Certificate Enrollment Protocol). Quando un dispositivo aziendale viene registrato nel MDM, richiede e riceve automaticamente il proprio certificato senza alcuna interazione da parte dell'utente.

SCENARI DI IMPLEMENTAZIONE (5:30 - 8:00)

Quindi, quale protocollo dovresti implementare? La decisione dipende quasi interamente dalle tue capacità di gestione dei dispositivi e dai tuoi requisiti di conformità. Ecco un framework decisionale pratico.

Poniti tre domande. Primo: tutti i dispositivi che si connettono a questa rete sono gestiti dall'azienda tramite una piattaforma MDM come Microsoft Intune o Jamf? Se sì, disponi dell'infrastruttura per distribuire i certificati client ed EAP-TLS è la scelta corretta. Secondo: questa rete deve soddisfare i requisiti PCI DSS 4.0, HIPAA o WPA3 Enterprise a 192 bit? Se sì, EAP-TLS è la scelta obbligata. Terzo: hai una percentuale significativa di dispositivi non gestiti o BYOD? Se sì, EAP-TTLS è la scelta più pragmatica per quel segmento della tua rete.

Permettetemi di presentarvi due scenari reali e concreti. Scenario uno: una catena di vendita al dettaglio nazionale con quattrocento negozi. Ogni terminale point-of-sale e scanner portatile del personale è registrato in Microsoft Intune. La rete rientra nell'ambito del PCI DSS 4.0. In questo ambiente, si distribuisce l'EAP-TLS. Si stabilisce una PKI privata, si usa Intune per distribuire certificati client univoci a ogni dispositivo tramite SCEP e si configura il server RADIUS per controllare la Certificate Revocation List. Se un dispositivo viene rubato, si revoca il suo certificato e questo viene escluso dalla rete nel giro di pochi minuti. Nessuna password da reimpostare. Nessun segreto condiviso da ruotare in quattrocento siti.

Scenario due: un grande campus universitario con ventimila studenti che utilizzano laptop personali, smartphone e tablet. Il team IT non può installare certificati sui dispositivi personali. In questo ambiente, l'EAP-TTLS è la scelta pragmatica. Si installa un certificato attendibile sui server RADIUS, si integra con il servizio di directory dell'università e gli studenti si autenticano utilizzando le proprie credenziali esistenti all'interno del tunnel sicuro. Supporta Windows, macOS, Linux, Android e iOS senza software aggiuntivo sul lato client.

In molte grandi aziende, la risposta è in realtà una combinazione di entrambi. Si distribuisce l'EAP-TLS per i dispositivi aziendali gestiti e l'EAP-TTLS o una rete sicura separata per collaboratori esterni, visitatori e BYOD. Questo è un modello comune nei gruppi alberghieri, dove i dispositivi del personale sono gestiti e dotati di certificati, mentre l'infrastruttura rivolta agli ospiti utilizza un percorso di autenticazione completamente diverso.

DOMANDE E RISPOSTE RAPIDE (8:00 - 9:00)

Permettetemi di fornirvi alcune risposte rapide alle domande che sentiamo frequentemente da CTO e architetti di rete.

Domanda uno: L'EAP-TLS è richiesto per WPA3 Enterprise? Se si implementa la suite di sicurezza WPA3 Enterprise a 192 bit, sì, l'EAP-TLS è l'unico metodo consentito. È l'unico metodo EAP che soddisfa i requisiti WPA3-Enterprise a 192 bit della Wi-Fi Alliance.

Domanda due: Possiamo usare l'EAP-TTLS per i dispositivi IoT? In genere no. I dispositivi IoT headless, come le pompe di infusione o i sensori ambientali, di solito non hanno l'interfaccia per gestire metodi di autenticazione interna complessi. L'EAP-TLS è in realtà più adatto per l'IoT, perché è possibile fornire il certificato durante la fase di staging del dispositivo. Il dispositivo si autentica automaticamente, senza richiedere alcuna interazione da parte dell'utente.

Domanda tre: E per il BYOD su una rete EAP-TLS? Per i dispositivi personali non gestiti, l'EAP-TLS è operativamente difficile. È possibile utilizzare portali di onboarding per fornire un certificato temporaneo, ma ciò aggiunge attrito. Per il BYOD, l'EAP-TTLS o una rete ospiti dedicata con un'adeguata segmentazione è solitamente la risposta corretta.

Domanda quattro: Come si relaziona questo con i fornitori di hardware? Sia l'EAP-TLS che l'EAP-TTLS sono supportati su tutte le principali piattaforme hardware WiFi aziendali: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. I dettagli di configurazione variano a seconda della piattaforma, ma gli standard sottostanti sono indipendenti dal fornitore.
RIASSUNTO E PROSSIMI PASSI (9:00 - 10:00)

In sintesi, ecco i punti chiave da ricordare. EAP-TLS offre la massima sicurezza grazie all'autenticazione reciproca tramite certificato. Elimina completamente il rischio legato alle password ed è la scelta corretta per flotte di dispositivi gestiti e ambienti regolamentati. EAP-TTLS offre una solida sicurezza tramite certificati lato server e tunneling crittografato delle credenziali. È la scelta corretta per ambienti misti o BYOD. Entrambi i protocolli richiedono di applicare la convalida del certificato del server su ogni client. Senza di essa, nessuno dei due protocolli protegge dai rogue access point. E la gestione del ciclo di vita dei certificati rappresenta la principale sfida operativa di EAP-TLS: automatizzatela tramite MDM e SCEP fin dal primo giorno.

I vostri prossimi passi? Eseguite un audit della vostra attuale implementazione 802.1X. Se vi affidate ancora a password condivise, pianificate la migrazione. Verificate se i supplicant dei vostri client convalidano il certificato del server. E se state implementando la soluzione su più sedi o su una rete distribuita, prendete in considerazione un servizio RADIUS ospitato nel cloud per ridurre il carico operativo. Grazie per aver seguito questo briefing tecnico di Purple. Purple supporta i percorsi di autenticazione sia EAP-TLS che EAP-TTLS per il Staff WiFi in oltre 80.000 sedi attive. Per guide all'implementazione più dettagliate e per capire come le nostre piattaforme di analytics e identità si integrano con le vostre reti sicure, visitate purple.ai.

Punti chiave

✓L'EAP-TLS richiede un'autenticazione mutua tramite certificati: sia il dispositivo client che il server RADIUS presentano certificati X.509. Non viene scambiata alcuna password in nessun momento, eliminando completamente il rischio di furto delle credenziali.
✓L'EAP-TTLS richiede solo un certificato lato server per stabilire un tunnel TLS crittografato. Il client si autentica all'interno del tunnel utilizzando le credenziali di directory esistenti (nome utente e password).
✓Il fattore decisivo principale è la gestione dei dispositivi: se controlli i dispositivi tramite MDM, distribuisci l'EAP-TLS. Se supporti il BYOD o dispositivi non gestiti, distribuisci l'EAP-TTLS.
✓L'EAP-TLS è l'unico metodo EAP che soddisfa i requisiti WPA3-Enterprise a 192 bit ed è caldamente raccomandato per gli ambienti di dati dei titolari di carta PCI DSS 4.0.
✓Entrambi i protocolli richiedono che la convalida del certificato del server sia applicata su ogni dispositivo client. Senza di essa, nessuno dei due protocolli protegge dagli attacchi di tipo rogue access point: questa è la singola configurazione più importante da verificare.
✓L'automazione del ciclo di vita dei certificati tramite MDM e SCEP è indispensabile per l'EAP-TLS su larga scala. La scadenza non gestita dei certificati è la causa più comune di interruzioni di massa dell'autenticazione.
✓Molte grandi aziende distribuiscono entrambi: EAP-TLS per i dispositivi aziendali gestiti su un SSID Staff WiFi dedicato, ed EAP-TTLS per consulenti e BYOD su un SSID separato e segmentato.

कार्यकारी सारांश (Executive summary)

अपने 802.1X डिप्लॉयमेंट के लिए सही EAP विधि चुनना यह तय करता है कि आपका एंटरप्राइज WiFi वास्तव में सुरक्षित है या केवल कागजों पर ही अनुपालन करता है। EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), जो RFC 5216 में परिभाषित है, को आपसी प्रमाणपत्र प्रमाणीकरण (mutual certificate authentication) की आवश्यकता होती है: नेटवर्क एक्सेस मिलने से पहले क्लाइंट डिवाइस और RADIUS सर्वर दोनों वैध X.509 प्रमाणपत्र प्रस्तुत करते हैं। किसी भी समय पासवर्ड का आदान-प्रदान नहीं किया जाता है। EAP-TTLS (Tunneled Transport Layer Security), जो RFC 5281 में परिभाषित है, को एक एन्क्रिप्टेड TLS टनल स्थापित करने के लिए केवल एक सर्वर-साइड प्रमाणपत्र की आवश्यकता होती है, जिसके अंदर क्लाइंट मौजूदा निर्देशिका क्रेडेंशियल का उपयोग करके प्रमाणित होता है।

रिटेल चेन, हॉस्पिटैलिटी स्थलों और सार्वजनिक क्षेत्र के संगठनों में बुनियादी ढांचे का प्रबंधन करने वाले CTOs और नेटवर्क आर्किटेक्ट्स के लिए, यह निर्णय केवल एक प्रश्न पर निर्भर करता है: क्या आप उपकरणों का प्रबंधन करते हैं? यदि आप MDM के माध्यम से डिवाइस बेड़े को नियंत्रित करते हैं, तो EAP-TLS निश्चित विकल्प है। यदि आप एक विविध BYOD वातावरण का समर्थन करते हैं या एक मजबूत पब्लिक की इन्फ्रास्ट्रक्चर (PKI) की कमी है, तो EAP-TTLS एक व्यावहारिक, अत्यधिक सुरक्षित विकल्प प्रदान करता है। Purple 80,000+ से अधिक लाइव स्थलों पर Staff WiFi के लिए दोनों प्रमाणीकरण पथों का समर्थन करता है।

तकनीकी गहन विश्लेषण (Technical deep-dive)

EAP-TLS की वास्तुकला

EAP-TLS, IEEE 802.1X पोर्ट-आधारित एक्सेस कंट्रोल फ्रेमवर्क के भीतर एक आपसी प्रमाणीकरण (mutual authentication) मॉडल पर काम करता है। प्रत्येक प्रमाणीकरण विनिमय में तीन मुख्य कारक होते हैं: सप्लिकेंट (क्लाइंट डिवाइस), ऑथेंटिकेटर (वायरलेस एक्सेस पॉइंट), और ऑथेंटिकेशन सर्वर (RADIUS सर्वर)। एक्सेस पॉइंट स्वयं प्रमाणीकरण निर्णय नहीं लेता है। यह एक पारदर्शी रिले के रूप में कार्य करता है, जो EAP संदेशों को RADIUS पैकेटों में समाहित करता है और उन्हें ऑथेंटिकेशन सर्वर पर भेजता है।

EAP-TLS हैंडशेक इस प्रकार आगे बढ़ता है। एक्सेस पॉइंट कनेक्ट होने वाले डिवाइस को एक EAP-Request/Identity भेजता है। डिवाइस अपनी पहचान के साथ प्रतिक्रिया देता है। RADIUS सर्वर EAP-TLS/Start संदेश के साथ TLS हैंडशेक शुरू करता है। क्लाइंट एक ClientHello भेजता है, जो इसके समर्थित TLS साइफर सुइट्स का विज्ञापन करता है। RADIUS सर्वर ServerHello, अपने X.509 सर्वर सर्टिफिकेट और एक सर्टिफिकेट अनुरोध के साथ प्रतिक्रिया देता है। क्लाइंट अपने विश्वसनीय रूट CA स्टोर के खिलाफ सर्वर सर्टिफिकेट को सत्यापित करता है। यदि सत्यापन विफल हो जाता है, तो हैंडशेक समाप्त हो जाता है - जो अनधिकृत (rogue) एक्सेस पॉइंट से सुरक्षा प्रदान करता है। इसके बाद क्लाइंट अपना स्वयं का X.509 सर्टिफिकेट प्रस्तुत करता है। RADIUS सर्वर क्लाइंट सर्टिफिकेट को सत्यापित करता है, विश्वसनीय रूट CA तक सिग्नेचर चेन की जांच करता है, सत्यापित करता है कि सर्टिफिकेट समाप्त नहीं हुआ है, और सर्टिफिकेट निरसन सूची (CRL) की जांच करता है या OCSP से पूछताछ करता है। केवल तभी जब दोनों पक्ष संतुष्ट होते हैं, TLS टनल स्थापित होती है और नेटवर्क एक्सेस प्रदान किया जाता है।

चूंकि किसी भी पासवर्ड का आदान-प्रदान नहीं होता है, इसलिए EAP-TLS ऑफलाइन डिक्शनरी हमलों, क्रेडेंशियल स्टफिंग और फ़िशिंग से सुरक्षित है। यह एकमात्र EAP तरीका है जो WPA3-Enterprise 192-bit (Suite B) आवश्यकताओं को पूरा करता है, और इसे कार्डधारक डेटा वातावरण के लिए PCI DSS 4.0 द्वारा और उच्च-सुरक्षा वायरलेस परिनियोजन के लिए NIST SP 800-120 द्वारा अनिवार्य या दृढ़ता से अनुशंसित किया गया है।

EAP-TLS के लिए एक PKI की आवश्यकता होती है। आपको कम से कम एक ऑफलाइन रूट CA और एक ऑनलाइन जारी करने वाले CA की आवश्यकता होती है। रूट CA एयर-गैप्ड होना चाहिए, क्योंकि इसकी प्राइवेट की (private key) आपके संपूर्ण सर्टिफिकेट पदानुक्रम के लिए मास्टर ट्रस्ट एंकर है। जारी करने वाला CA दैनिक सर्टिफिकेट जारी करने का काम संभालता है और CRL प्रकाशित करता है। क्लाइंट सर्टिफिकेट व्यक्तिगत उपकरणों को जारी किए जाते हैं, उपयोगकर्ताओं को नहीं - यह एक डिवाइस-आइडेंटिटी मॉडल है। यह अंतर IoT उपकरणों, साझा टर्मिनलों और हेडलेस सिस्टम के लिए महत्वपूर्ण है।

EAP-TTLS की संरचना

EAP-TTLS को हर क्लाइंट डिवाइस पर सर्टिफिकेट तैनात करने के परिचालन बोझ के बिना मजबूत 802.1X सुरक्षा प्रदान करने के लिए डिज़ाइन किया गया था। यह दो चरणों में काम करता है। पहले चरण में, RADIUS सर्वर अपना सर्टिफिकेट प्रस्तुत करता है और एक सुरक्षित TLS टनल स्थापित करता है। केवल सर्वर को ही सर्टिफिकेट की आवश्यकता होती है। दूसरे चरण में, क्लाइंट एक आंतरिक प्रमाणीकरण पद्धति का उपयोग करके उस एन्क्रिप्टेड टनल के भीतर प्रमाणित होता है। सामान्य आंतरिक तरीकों में PAP (Password Authentication Protocol), CHAP, और MS-CHAPv2 शामिल हैं। क्लाइंट अपना उपयोगकर्ता नाम और पासवर्ड भेजता है, लेकिन क्योंकि यह आदान-प्रदान TLS टनल के भीतर होता है, क्रेडेंशियल ट्रांज़िट में एन्क्रिप्टेड होते हैं और कभी भी हवा में उजागर नहीं होते हैं।

EAP-TTLS macOS, Linux, Android, और iOS पर उत्कृष्ट क्रॉस-प्लेटफ़ॉर्म सहायता प्रदान करता है। चेतावनी Windows को लेकर है: इन-बिल्ट Windows सप्लिकेंट वायरलेस 802.1X के लिए EAP-TTLS को पूरी तरह से लागू नहीं करता है। अधिक Windows वाले वातावरणों को एक तृतीय-पक्ष सप्लिकेंट की आवश्यकता हो सकती है, जो परिचालन जटिलता को बढ़ाता है। Windows-केंद्रित वातावरणों के लिए, MS-CHAPv2 के साथ PEAP अक्सर अधिक व्यावहारिक विकल्प होता है।

EAP-TTLS की सबसे बड़ी सीमा यह है कि यह पासवर्ड के अंतर्निहित जोखिमों को समाप्त नहीं करता है। यदि कोई उपयोगकर्ता कमज़ोर पासवर्ड चुनता है, तो वह बाद में ऑफ़लाइन ब्रूट फ़ोर्स के प्रति संवेदनशील रहता है। यदि आंतरिक प्रमाणीकरण PAP का उपयोग करता है, तो पासवर्ड टनल के भीतर प्लेनटेक्स्ट में भेजा जाता है - जो तब स्वीकार्य है जब आप अपने RADIUS इन्फ्रास्ट्रक्चर पर भरोसा करते हैं, लेकिन इसे एक ट्रस्ट मॉडल के रूप में समझना आवश्यक है।

आमने-सामने तुलना

विशेषता	EAP-TLS	EAP-TTLS
RFC मानक	RFC 5216	RFC 5281
क्लाइंट प्रमाणपत्र आवश्यक	हाँ	नहीं
सर्वर प्रमाणपत्र आवश्यक	हाँ	हाँ
प्रमाणीकरण मॉडल	आपसी (दोनों पक्ष)	केवल-सर्वर
पासवर्ड का जोखिम	कोई नहीं - पासवर्ड रहित	एन्क्रिप्टेड टनल में पासवर्ड
PKI आवश्यकता	पूर्ण PKI (रूट CA + जारीकर्ता CA + MDM)	केवल सर्वर प्रमाणपत्र
WPA3-Enterprise 192-bit	आवश्यक विधि	समर्थित नहीं
PCI DSS 4.0 संरेखण	दृढ़ता से अनुशंसित	मजबूत आंतरिक प्रमाणीकरण के साथ स्वीकार्य
BYOD उपयुक्तता	कम (क्लाइंट प्रमाणपत्र की आवश्यकता होती है)	उच्च (केवल क्रेडेंशियल्स)
IoT डिवाइस उपयुक्तता	उच्च (स्टेजिंग पर प्रमाणपत्र प्रदान किया गया)	कम (क्रेडेंशियल इनपुट के लिए कोई UI नहीं)
Windows मूल समर्थन	हाँ	आंशिक (अक्सर तृतीय-पक्ष सप्लीकेंट की आवश्यकता होती है)
macOS/Linux/Android समर्थन	हाँ	हाँ
परिनियोजन जटिलता	उच्च	मध्यम

कार्यान्वयन गाइड

प्रबंधित फ़्लीट के लिए EAP-TLS तैनात करना

EAP-TLS को तैनात करने के लिए एक कार्यात्मक PKI और एक MDM प्लेटफॉर्म की आवश्यकता होती है। मैन्युअल प्रमाणपत्र स्थापना एंटरप्राइज़ स्तर पर व्यवहार्य नहीं है। आपको SCEP (सिंपल सर्टिफिकेट एनरोलमेंट प्रोटोकॉल) या EST (एनरोलमेंट ओवर सिक्योर ट्रांसपोर्ट) का उपयोग करके अपने PKI को अपने MDM के साथ एकीकृत करना होगा। जब एक कॉर्पोरेट डिवाइस नामांकित होता है, तो यह उपयोगकर्ता के हस्तक्षेप के बिना स्वचालित रूप से अपने प्रमाणपत्र का अनुरोध करता है और प्राप्त करता है।

पहचान प्रबंधन के लिए, Connect लाइसेंस के तहत OpenRoaming जैसी सेवाओं के लिए Purple एक निःशुल्क पहचान प्रदाता के रूप में कार्य करता है, जो अंतर्निहित प्रमाणपत्र और पहचान ढांचे का उपयोग करके विभिन्न स्थानों पर सुरक्षित रोमिंग की सुविधा प्रदान करता है।

RADIUS की ओर, अपने आंतरिक CA के विरुद्ध क्लाइंट प्रमाणपत्रों को मान्य करने और रीयल-टाइम निरसन जाँच के लिए CRL की जाँच करने या OCSP का उपयोग करने के लिए अपने सर्वर को कॉन्फ़िगर करें। समर्थित RADIUS प्लेटफॉर्म में FreeRADIUS, Microsoft NPS और Cisco ISE शामिल हैं। Purple का क्लाउड ओवरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet हार्डवेयर के साथ एकीकृत होता है।

मिश्रित परिवेशों के लिए EAP-TTLS तैनात करना

अप्रबंधित उपकरणों वाले परिवेशों के लिए EAP-TTLS इष्टतम विकल्प है। आपको केवल अपने RADIUS सर्वर पर एक विश्वसनीय प्रमाणपत्र तैनात करने की आवश्यकता है। सुनिश्चित करें कि आपका RADIUS सर्वर आंतरिक प्रमाणीकरण क्रेडेंशियल्स को मान्य करने के लिए सीधे आपकी निर्देशिका सेवा - Microsoft Entra ID, Okta, या Google Workspace - के साथ एकीकृत हो। अपने MDM-तैनात WiFi प्रोफाइल को अपने विशिष्ट विश्वसनीय CA के विरुद्ध सर्वर प्रमाणपत्र सत्यापन लागू करने के लिए कॉन्फ़िगर करें। इस चरण के बिना, TLS टनल दुष्ट एक्सेस पॉइंट्स के खिलाफ कोई सुरक्षा प्रदान नहीं करती है।

सर्वोत्तम प्रथाएं

प्रत्येक क्लाइंट पर सर्वर प्रमाणपत्र सत्यापन लागू करें

EAP-TLS और EAP-TTLS दोनों के लिए सबसे महत्वपूर्ण कॉन्फ़िगरेशन चरण क्लाइंट डिवाइस पर सर्वर प्रमाणपत्र सत्यापन को लागू करना है। यदि कोई डिवाइस किसी विशिष्ट विश्वसनीय CA के विरुद्ध RADIUS सर्वर के प्रमाणपत्र को सत्यापित नहीं करता है, तो यह किसी भी प्रमाणपत्र को प्रस्तुत करने वाले किसी भी सर्वर से जुड़ जाएगा - जिसमें एक दुष्ट एक्सेस पॉइंट भी शामिल है। हमेशा अपने MDM-नियोजित WiFi प्रोफाइल में विश्वसनीय CA और अपेक्षित सर्वर नाम निर्दिष्ट करें। यह एकल कॉन्फ़िगरेशन जांच सबसे प्रभावी सुरक्षा सुधार है जिसे आप आज लागू कर सकते हैं।

प्रमाणपत्र जीवनचक्र प्रबंधन को स्वचालित करें

प्रमाणपत्रों की अवधि समाप्त हो जाती है। यदि आपके पास स्वचालित नवीनीकरण प्रक्रिया नहीं है, तो प्रमाणपत्रों की अवधि एक साथ समाप्त होने पर आपको बड़े पैमाने पर प्रमाणीकरण विफलताओं का सामना करना पड़ेगा। नवीनीकरण को स्वचालित करने के लिए SCEP या EST का उपयोग करें, और समाप्ति तिथियों से काफी पहले निगरानी अलर्ट कॉन्फ़िगर करें। यदि कोई डिवाइस खो जाता है या कोई कर्मचारी चला जाता है, तो प्रमाणपत्र को तुरंत निरस्त कर दें। रीयल-टाइम सत्यापन के लिए CRL की जांच करने या OCSP का उपयोग करने के लिए अपने RADIUS सर्वर को कॉन्फ़िगर करें।

प्रमाणीकरण विधि द्वारा अपने नेटवर्क को विभाजित करें

बड़े या वितरित परिवेशों में, अलग-अलग SSID पर दोनों प्रोटोकॉल चलाने पर विचार करें। कॉर्पोरेट प्रबंधित डिवाइस एक समर्पित स्टाफ WiFi SSID पर EAP-TLS के माध्यम से प्रमाणित होते हैं। ठेकेदार और BYOD डिवाइस उपयुक्त VLAN विभाजन के साथ एक अलग SSID पर EAP-TTLS के माध्यम से प्रमाणित होते हैं। यह पैटर्न प्रीमियर इन और व्हिटब्रेड जैसे आतिथ्य समूहों में आम है, जहां स्टाफ उपकरणों को प्रबंधित और प्रमाणपत्र जारी किए जाते हैं, जबकि मेहमानों के लिए बुनियादी ढांचा एक अलग प्रमाणीकरण पथ का उपयोग करता है। SSID आर्किटेक्चर के बारे में अधिक जानकारी के लिए, हमारा गाइड देखें Three SSIDs to rule them all: the WiFi design for guest, staff and IoT ।

सभी बुनियादी ढांचे में समय को सिंक्रनाइज़ करें

प्रमाणपत्र सत्यापन सटीक सिस्टम समय पर निर्भर करता है। क्लाइंट उपकरणों या RADIUS सर्वरों पर घड़ी का विचलन 'अभी तक मान्य नहीं' या 'समय समाप्त' प्रमाणपत्र त्रुटियां उत्पन्न करता है जिनका निदान करना कठिन होता है। सुनिश्चित करें कि सभी बुनियादी ढांचा घटक विश्वसनीय NTP सर्वरों के साथ सिंक्रनाइज़ हों।

समस्या निवारण और जोखिम शमन

अज्ञात CA त्रुटियां

यदि RADIUS लॉग 'अज्ञात CA' दिखाते हैं, तो क्लाइंट डिवाइस उस CA पर भरोसा नहीं करता है जिसने RADIUS सर्वर का प्रमाणपत्र जारी किया है। सत्यापित करें कि आपके MDM प्रोफ़ाइल में रूट CA प्रमाणपत्र शामिल है और उस पर भरोसा करने के लिए सप्लीकेंट को कॉन्फ़िगर किया गया है। CA रोटेशन या प्रमाणपत्र नवीनीकरण के बाद, अपडेट किए गए CA बंडल को सभी उपकरणों पर फिर से पुश करें।

EAP विधि बेमेल

यदि डिवाइस एक्सेस पॉइंट से कनेक्ट होते हैं लेकिन प्रमाणीकरण विफल हो जाता है, तो जांचें कि क्लाइंट पर कॉन्फ़िगर की गई EAP विधि RADIUS सर्वर द्वारा स्वीकार की जाने वाली विधि से मेल खाती है। EAP-TLS के लिए सेट किया गया डिवाइस प्रोफ़ाइल केवल PEAP के लिए कॉन्फ़िगर किए गए RADIUS सर्वर पर विफल हो जाएगा।

सर्टिफिकेट की समय सीमा समाप्त होने के कारण सामूहिक विफलताएं

यदि बड़ी संख्या में डिवाइस एक साथ प्रमाणित होने में विफल रहते हैं, तो सबसे पहले सर्टिफिकेट की समाप्ति तिथियों की जांच करें। यह EAP-TLS डिप्लॉयमेंट में बड़े पैमाने पर 802.1X विफलताओं का सबसे आम कारण है। ऐसा मॉनिटरिंग सिस्टम लागू करें जो समाप्ति से 60 दिन, 30 दिन और सात दिन पहले अलर्ट भेजे।

RADIUS क्लाइंट का गलत कॉन्फ़िगरेशन

प्रत्येक एक्सेस पॉइंट या वायरलेस कंट्रोलर को सही IP एड्रेस और शेयर्ड सीक्रेट के साथ RADIUS क्लाइंट के रूप में परिभाषित किया जाना चाहिए। बेमेल होने के कारण प्रमाणीकरण टाइमआउट होता है जिसे अक्सर गलत तरीके से EAP विधि के कारण मान लिया जाता है। पहले दिन से ही विस्तृत RADIUS लॉगिंग सक्षम करें। अधिक WiFi समस्या निवारण मार्गदर्शन के लिए, हमारी गाइड Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures देखें।

अनुपालन और नियामक संरेखण

CISOs और नेटवर्क आर्किटेक्ट्स के लिए EAP-TLS बनाम EAP-TTLS का निर्णय लेने के लिए नियामक परिदृश्य को समझना आवश्यक है। EAP विधि का चयन सीधे कई प्रमुख फ्रेमवर्क में आपके अनुपालन की स्थिति को प्रभावित करता है।

PCI DSS 4.0 (पेमेंट कार्ड इंडस्ट्री डेटा सिक्योरिटी स्टैंडर्ड) को कार्डधारक डेटा परिवेश में वायरलेस नेटवर्क के लिए मजबूत क्रिप्टोग्राफिक प्रमाणीकरण की आवश्यकता होती है। आवश्यकता 8.3 CDE तक की सभी पहुंच के लिए मल्टी-फैक्टर प्रमाणीकरण को अनिवार्य बनाती है, और दायरे में आने वाले वायरलेस नेटवर्क को मजबूत प्रमाणीकरण तंत्र का उपयोग करना चाहिए। सर्टिफिकेट-आधारित म्यूचुअल प्रमाणीकरण के साथ EAP-TLS इस आवश्यकता को निश्चित रूप से पूरा करता है। MS-CHAPv2 के साथ EAP-TTLS स्वीकार्य है यदि आंतरिक प्रमाणीकरण ठीक से सुरक्षित है और सर्वर सर्टिफिकेट सत्यापन लागू किया गया है, लेकिन EAP-TLS अधिक मजबूत और ऑडिटर-अनुकूल विकल्प है।

HIPAA (हेल्थ इंश्योरेंस पोर्टेबिलिटी एंड अकाउंटेबिलिटी एक्ट) के तहत कवर की गई संस्थाओं के लिए तकनीकी सुरक्षा उपाय लागू करना आवश्यक है जो इलेक्ट्रॉनिक संचार नेटवर्क पर प्रसारित होने वाली इलेक्ट्रॉनिक संरक्षित स्वास्थ्य जानकारी (ePHI) की रक्षा करते हैं। HIPAA सुरक्षा नियम विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन ePHI ले जाने वाले वायरलेस नेटवर्क के लिए एन्क्रिप्शन और एक्सेस कंट्रोल की उम्मीद प्रबंधित चिकित्सा उपकरण बेड़े के लिए EAP-TLS और स्टाफ उपकरणों के लिए लागू सर्वर सर्टिफिकेट सत्यापन के साथ EAP-TTLS के पक्ष में मजबूती से झुकी हुई है।

WPA3-Enterprise 192-bit (जिसे सुइट B या CNSA मोड के रूप में भी जाना जाता है) Wi-Fi Alliance के WPA3 सर्टिफिकेशन का उच्चतम सुरक्षा स्तर है। यह एकमात्र अनुमत प्रमाणीकरण विधि के रूप में EAP-TLS को अनिवार्य करता है, विशिष्ट सिफर सुइट्स (P-384 के साथ ECDHE, AES-256-GCM) के साथ TLS 1.2 या उच्चतर की आवश्यकता होती है, और ECDSA या RSA-3072 सर्टिफिकेट की आवश्यकता होती है। सरकारी, रक्षा, या महत्वपूर्ण बुनियादी ढांचा अनुप्रयोगों के लिए WPA3-Enterprise 192-bit तैनात करने वाले संगठनों को EAP-TLS का उपयोग करना चाहिए। ISO/IEC 27001 विशिष्ट प्रोटोकॉल को अनिवार्य नहीं करता है, लेकिन संगठनों को नेटवर्क संसाधनों के लिए उपयुक्त एक्सेस नियंत्रण लागू करने की आवश्यकता होती है। EAP-TLS या EAP-TTLS (लागू सर्वर प्रमाणपत्र सत्यापन के साथ) में से किसी एक के साथ 802.1X परिनियोजन (deployment) Annex A.9.1 और A.13.1 की नेटवर्क एक्सेस नियंत्रण आवश्यकताओं को पूरा करता है।

ROI और व्यावसायिक प्रभाव

EAP-TLS पर माइग्रेट करने के लिए PKI और MDM एकीकरण में शुरुआती निवेश की आवश्यकता होती है, लेकिन यह पासवर्ड रीसेट के परिचालन ओवरहेड और क्रेडेंशियल से समझौता होने के कारण होने वाले नेटवर्क ब्रीच के वित्तीय जोखिम को समाप्त करता है। 400 स्टोर वाली एक रिटेल चेन के लिए, साझा PSK नेटवर्क पर एक सिंगल कॉम्प्रोमाइज्ड पासवर्ड पूरे एस्टेट को खतरे में डाल सकता है। EAP-TLS उस अटैक वेक्टर को पूरी तरह से समाप्त कर देता है।

मल्टी-टेनेंट वातावरण और ट्रैवल हब के लिए, सुरक्षित प्रमाणीकरण (authentication) यह सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता ही नेटवर्क बैंडविड्थ का उपयोग करें, जिससे बुनियादी ढांचे (infrastructure) के उपयोग को अनुकूलित किया जा सके। RADIUS प्रमाणपत्र विशेषताओं के माध्यम से डायनामिक VLAN असाइनमेंट क्रिप्टोग्राफिक रूप से लागू नेटवर्क सेगमेंटेशन को सक्षम बनाता है, जिससे SSID चयन या MAC address फ़िल्टरिंग पर निर्भर रहने के बजाय प्रमाणपत्र गुणों के आधार पर उपकरणों को सही नेटवर्क सेगमेंट पर रखा जा सकता है।

Purple का WiFi Analytics प्लेटफ़ॉर्म दोनों प्रमाणीकरण पथों के साथ एकीकृत होता है, जो आपके पूरे एस्टेट में डिवाइस की संख्या, सत्र की अवधि (session durations) और नेटवर्क उपयोग की दृश्यता प्रदान करता है। क्षेत्र-विशिष्ट परिनियोजन मार्गदर्शन के लिए, हॉस्पिटैलिटी , रिटेल , हेल्थकेयर , और ट्रांसपोर्ट के लिए हमारे संसाधनों को एक्सप्लोर करें।

Definizioni chiave

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Un metodo di autenticazione 802.1X definito in RFC 5216 che richiede sia al dispositivo client che al server RADIUS di presentare certificati X.509 validi. Non vengono scambiate password. L'autenticazione è reciproca e crittograficamente vincolata.

Il gold standard per la sicurezza wireless aziendale. Richiesto per WPA3-Enterprise a 192 bit e fortemente raccomandato per gli ambienti di dati dei titolari di carta PCI DSS 4.0.

EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security)

Un metodo di autenticazione 802.1X definito in RFC 5281 che richiede solo un certificato lato server per stabilire un tunnel TLS crittografato. Il client si autentica all'interno del tunnel utilizzando un metodo di autenticazione interno secondario, in genere un nome utente e una password.

La scelta preferita per gli ambienti BYOD e le reti con sistemi operativi misti in cui la distribuzione dei certificati client è operativamente impraticabile.

802.1X

Uno standard IEEE per il controllo dell'accesso alla rete basato su porte che fornisce un meccanismo di autenticazione per i dispositivi che si connettono a una LAN o WLAN. Definisce i ruoli di supplicant, authenticator e authentication server.

Il framework fondamentale che consente alle reti aziendali di autenticare i singoli dispositivi anziché affidarsi a un'unica password condivisa. Sia EAP-TLS che EAP-TTLS operano all'interno di questo framework.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento (accounting) per gli utenti che si connettono a un servizio di rete. Nelle distribuzioni 802.1X, il server RADIUS è il server di autenticazione che verifica i certificati o le credenziali.

Il componente server che verifica i certificati o le password e indica all'access point se concedere o negare l'accesso alla rete. Le piattaforme supportate includono FreeRADIUS, Microsoft NPS e Cisco ISE.

PKI (Public Key Infrastructure)

Un insieme di ruoli, criteri, hardware, software e procedure necessari per creare, gestire, distribuire, utilizzare, memorizzare e revocare certificati digitali. Una tipica PKI aziendale consiste in una CA radice offline e una CA emittente online.

L'infrastruttura di backend richiesta per emettere i certificati client e server utilizzati nell'autenticazione EAP-TLS. Senza una PKI, non è possibile distribuire EAP-TLS.

MDM (Mobile Device Management)

Software utilizzato dai dipartimenti IT per monitorare, gestire e proteggere i dispositivi mobili e i laptop dei dipendenti. Le piattaforme MDM come Microsoft Intune e Jamf possono automatizzare la distribuzione di certificati e profili WiFi sui dispositivi registrati.

Essenziale per automatizzare la distribuzione dei certificati client per EAP-TLS su scala. Senza l'integrazione MDM, l'installazione manuale dei certificati su migliaia di dispositivi è operativamente impossibile.

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo utilizzato per automatizzare l'emissione di certificati digitali ai dispositivi di rete. Le piattaforme MDM utilizzano SCEP per richiedere e installare silenziosamente certificati sui dispositivi aziendali registrati senza l'interazione dell'utente.

Il meccanismo standard per il provisioning dei certificati senza intervento (zero-touch) nelle distribuzioni EAP-TLS. Supportato da Microsoft Intune, Jamf e dalla maggior parte delle piattaforme MDM aziendali.

CRL (Certificate Revocation List)

Un elenco di certificati digitali che sono stati revocati dall'Autorità di Certificazione emittente prima della loro data di scadenza prevista. I server RADIUS controllano la CRL per verificare che il certificato di un dispositivo connesso sia ancora valido.

Il meccanismo che consente di bloccare immediatamente un dispositivo rubato o compromesso dalla rete revocandone il certificato. I server RADIUS devono essere configurati per controllare frequentemente la CRL o utilizzare OCSP per la convalida in tempo reale.

X.509

Uno standard ITU-T che definisce il formato dei certificati a chiave pubblica. EAP-TLS e EAP-TTLS utilizzano entrambi certificati X.509 per l'autenticazione del server. EAP-TLS richiede anche certificati X.509 sul dispositivo client.

Il formato di certificato utilizzato in tutte le distribuzioni PKI aziendali. Quando i team IT si riferiscono ai "certificati digitali" nel contesto di 802.1X, intendono i certificati X.509.

Metodo di autenticazione interna

Il protocollo di autenticazione secondario utilizzato all'interno del tunnel TLS crittografato stabilito da EAP-TTLS. I metodi interni comuni includono PAP (Password Authentication Protocol), CHAP e MS-CHAPv2.

La scelta del metodo di autenticazione interna influisce sulle proprietà di sicurezza di una distribuzione EAP-TTLS. PAP invia la password in testo non crittografato all'interno del tunnel; MS-CHAPv2 utilizza un meccanismo di challenge-response. Il tunnel crittografa tutto il traffico di autenticazione interna.

Esempi pratici

Una catena di vendita al dettaglio nazionale con 400 punti vendita deve proteggere i propri terminali POS (point-of-sale) e gli scanner palmari del personale. L'ambiente rientra nell'ambito del PCI DSS 4.0. Tutti i dispositivi sono registrati in Microsoft Intune. Quale protocollo dovrebbero implementare e quali sono i passaggi chiave di configurazione?

Implementare EAP-TLS. Passaggio 1: Stabilire una PKI a due livelli con una CA radice offline (air-gapped) e una CA di emissione online. Passaggio 2: Configurare Microsoft Intune con un profilo di certificato SCEP destinato a tutti i dispositivi POS e scanner. Passaggio 3: Distribuire un server RADIUS (Microsoft NPS o cloud RADIUS) e configurarlo per convalidare i certificati client rispetto alla CA interna. Passaggio 4: Abilitare il controllo CRL o OCSP sul server RADIUS. Passaggio 5: Inviare un profilo WiFi tramite Intune specificando l'SSID, EAP-TLS come metodo di autenticazione, la CA radice attendibile e il nome del server RADIUS previsto. Passaggio 6: Testare con un gruppo pilota di 10 dispositivi prima di procedere alla distribuzione in tutti i 400 siti. Passaggio 7: Stabilire un processo di monitoraggio della scadenza dei certificati con avvisi a 60, 30 e sette giorni prima della scadenza.

Commento dell'esaminatore: EAP-TLS è la scelta corretta perché il PCI DSS 4.0 raccomanda caldamente l'autenticazione a certificato mutuo per le reti wireless nell'ambiente dei dati dei titolari di carta. Affidarsi alle password (EAP-TTLS) per i dispositivi POS introduce un rischio inaccettabile di furto di credenziali. L'integrazione MDM tramite SCEP è essenziale: l'installazione manuale dei certificati in 400 siti è operativamente impossibile. Il punto di errore più comune in questo scenario è dimenticare di imporre la convalida del certificato server nel profilo WiFi di Intune, il che lascerebbe i dispositivi vulnerabili ad attacchi Evil Twin nonostante l'implementazione di EAP-TLS.

Un grande campus universitario deve fornire un accesso WiFi sicuro a 20.000 studenti che utilizzano un mix di laptop personali, smartphone e tablet (BYOD). Il team IT non può installare certificati sui dispositivi personali. L'università utilizza Microsoft Entra ID per la gestione delle identità. Quale protocollo dovrebbero implementare?

Implementare EAP-TTLS con MS-CHAPv2 come metodo di autenticazione interno, integrato con Microsoft Entra ID tramite RADIUS. Passaggio 1: Ottenere un certificato server da una CA pubblica attendibile da tutti i principali sistemi operativi, oppure distribuire una CA interna e distribuire il certificato radice tramite gli strumenti di gestione dei dispositivi dell'università per i dispositivi gestiti. Passaggio 2: Configurare il server RADIUS per l'autenticazione rispetto a Microsoft Entra ID tramite LDAP o proxy RADIUS. Passaggio 3: Creare una guida all'attivazione WiFi per gli studenti specificando l'SSID, EAP-TTLS, MS-CHAPv2 e la CA attendibile. Passaggio 4: Applicare criteri di password complesse a livello di Entra ID e prendere in considerazione l'abilitazione dell'autenticazione a più fattori per la registrazione iniziale. Passaggio 5: Configurare il profilo WiFi per imporre la convalida del certificato server e specificare la CA attendibile e il nome del server RADIUS.

Commento dell'esaminatore: EAP-TTLS è la scelta pragmatica in questo caso. Gestire una PKI per 20.000 dispositivi personali non gestiti è operativamente impossibile. EAP-TTLS fornisce un tunnel sicuro per le credenziali, proteggendole dall'intercettazione via etere e supportando al contempo diversi sistemi operativi tra cui Windows, macOS, Linux, Android e iOS. Il rischio critico in questo scenario è che gli studenti configurino in modo errato i loro dispositivi saltando la convalida del certificato del server. La pubblicazione di una guida di onboarding chiara con i passaggi esatti di configurazione, e l'uso di un certificato server pubblicamente attendibile, riduce significativamente questo rischio.

Domande di esercitazione

Q1. Stai distribuendo EAP-TLS per una flotta di 5.000 laptop aziendali in 50 sedi d'ufficio. Dopo aver inviato il profilo WiFi tramite Microsoft Intune, i dispositivi non riescono a connettersi. I log del server RADIUS mostrano "Unknown CA" per ogni tentativo di autenticazione fallito. Qual è la causa più probabile e come la risolvi?

Suggerimento: Considera la catena di convalida del certificato sul lato client e cosa deve includere il profilo MDM oltre alla semplice impostazione del metodo EAP.

Visualizza risposta modello

I dispositivi client non sono configurati per considerare attendibile l'Autorità di Certificazione interna che ha emesso il certificato del server RADIUS. Il profilo WiFi MDM deve includere il certificato della CA radice (e qualsiasi certificato della CA intermedia) e configurare il richiedente affinché li consideri attendibili per la convalida del server. Senza questo, il client rifiuta il certificato del server RADIUS e interrompe l'handshake. Risoluzione: aggiorna il profilo WiFi di Intune per includere il certificato della CA radice attendibile nell'impostazione "Certificato radice per la convalida del server" e invia nuovamente il profilo a tutti i dispositivi.

Q2. La tua organizzazione ha distribuito EAP-TTLS per un ambiente BYOD misto. Durante una revisione della sicurezza, il tuo team di penetration testing dimostra di poter catturare le credenziali degli utenti configurando un access point fittizio con un certificato autofirmato. Come risolvi questa vulnerabilità senza migrare a EAP-TLS?

Suggerimento: Pensa a cosa succede prima dell'autenticazione interna e quale configurazione sul lato client impedisce al tunnel TLS di stabilirsi con un server non attendibile.

Visualizza risposta modello

La vulnerabilità esiste perché i dispositivi client non sono configurati per convalidare il certificato del server RADIUS. Soluzione: aggiorna tutti i profili WiFi (tramite MDM per i dispositivi gestiti e tramite una nuova guida di onboarding per il BYOD) per imporre la convalida del certificato del server. Specifica la CA attendibile e il nome del server RADIUS previsto nel profilo. I client configurati in questo modo rifiuteranno di stabilire il tunnel TLS con qualsiasi server che non sia in grado di presentare un certificato firmato dalla CA attendibile specificata, eliminando il vettore di attacco dell'access point fittizio.

Q3. Un direttore IT di un ospedale desidera distribuire l'802.1X per i propri dispositivi IoT medici (pompe d'infusione, monitor dei pazienti, sensori ambientali). Sta valutando EAP-TTLS perché ritiene che la gestione dei certificati sia troppo complessa. Perché questo ragionamento è errato e qual è l'approccio corretto?

Suggerimento: Considera come i dispositivi IoT headless gestiscono le richieste di autenticazione e cosa succede quando un dispositivo non può inserire le credenziali.

Visualizza risposta modello

Il ragionamento è errato per due motivi. Primo, la maggior parte dei dispositivi IoT medicali headless non dispone di un'interfaccia utente per l'inserimento delle credenziali, rendendo operativamente impossibile l'autenticazione interna EAP-TTLS con nome utente/password. Secondo, l'EAP-TLS è in realtà più semplice per l'IoT all'atto pratico: i certificati possono essere configurati durante la preparazione dei dispositivi prima della distribuzione, e il dispositivo si autentica automaticamente senza alcuna interazione da parte dell'utente. L'approccio corretto è l'EAP-TLS con certificati distribuiti tramite il sistema di gestione dei dispositivi utilizzato durante la preparazione. Questo soddisfa anche i requisiti GDPR e altre normative per una solida autenticazione wireless negli ambienti sanitari.

Q4. Sei l'architetto di rete per un gruppo alberghiero con 200 strutture. Devi proteggere il WiFi del personale per 3.000 dispositivi aziendali gestiti (registrati in Intune) e fornire un WiFi sicuro anche a consulenti esterni e fornitori terzi che utilizzano i propri laptop personali. Progetta l'architettura di autenticazione.

Suggerimento: Considera se un singolo SSID con un singolo metodo EAP possa servire entrambi i gruppi di utenti e quali implicazioni di segmentazione della rete derivino dalle due tipologie di utenti.

Visualizza risposta modello

Distribuisci due SSID separati con diversi metodi di autenticazione e assegnazioni VLAN. SSID 1 (Staff WiFi): EAP-TLS, con certificati distribuiti tramite Intune SCEP, VLAN assegnata al segmento di rete del personale con accesso completo ai sistemi di gestione dell'hotel. SSID 2 (WiFi Consulenti): EAP-TTLS con MS-CHAPv2, con credenziali verificate rispetto a una directory separata o a un account temporaneo per consulenti in Microsoft Entra ID, VLAN assegnata a un segmento isolato per il solo accesso a Internet senza accesso ai sistemi interni. Entrambi gli SSID devono imporre la convalida del certificato del server. Questa architettura offre al personale il massimo livello di sicurezza e fornisce al contempo un metodo di autenticazione pratico per i consulenti; la segmentazione della rete garantisce che una credenziale compromessa di un consulente non possa raggiungere i sistemi di gestione interni dell'hotel.

Continua a leggere questa serie

Server RADIUS: una guida completa per le aziende

Questa guida fornisce a IT manager, architetti di rete e CTO un riferimento tecnico definitivo sull'autenticazione tramite server RADIUS per il WiFi aziendale. Copre il framework AAA, l'architettura 802.1X, la selezione del metodo EAP, i compromessi tra implementazioni cloud e on-premises e l'assegnazione dinamica della VLAN. I gestori di location nei settori dell'ospitalità, del retail, degli eventi e del settore pubblico troveranno indicazioni pratiche per l'implementazione, casi di studio reali e i framework decisionali necessari per migrare da chiavi pre-condivise non sicure a un'architettura di controllo degli accessi alla rete sicura e basata sull'identità.

Aruba ClearPass vs. Purple WiFi: Confronto delle Funzionalità e Co-implementazione

Una guida tecnica completa che dettaglia l'architettura di co-implementazione di Aruba ClearPass e Purple WiFi. Copre la configurazione del proxy RADIUS, l'assegnazione dinamica della VLAN e le best practice per fornire reti guest sicure e basate sull'analisi dei dati insieme al NAC aziendale.

Cisco ISE vs. Purple WiFi: Come si Confrontano e Come Lavorano Insieme

Questa guida spiega come Cisco ISE e Purple WiFi ricoprano ruoli distinti ma complementari nelle reti aziendali. Spiega dettagliatamente come utilizzare Cisco ISE per l'accesso aziendale sicuro 802.1X, sfruttando al contempo Purple per il guest WiFi conforme al GDPR, l'analisi di marketing e l'integrazione CRM.