EAP-TLS vs EAP-TTLS: Qual Protocolo de WiFi Baseado em Certificados Deve Escolher?

Este guia fornece uma comparação direta e definitiva entre o EAP-TLS e o EAP-TTLS para a autenticação de WiFi empresarial ao abrigo da norma IEEE 802.1X. Explica a diferença arquitetónica entre a autenticação mútua por certificado e o tunelamento de certificado apenas do servidor, oferecendo aos gestores de TI, arquitetos de rede e CISOs uma estrutura de decisão clara com base nas capacidades de gestão de dispositivos e requisitos de conformidade. A Purple suporta ambos os caminhos de autenticação EAP-TLS e EAP-TTLS para WiFi de Funcionários, e este guia ajuda as organizações a compreender os compromissos de infraestrutura antes de se comprometerem com qualquer uma das abordagens.

📖 9 min de leitura📝 2,090 palavras🔧 2 exemplos práticos❓ 4 perguntas de prática📚 10 definições principais

Ouça este guia

Ver transcrição do podcast

INTRODUÇÃO E CONTEXTO (0:00 - 2:00)

Olá e bem-vindo a este briefing técnico da Purple. Sou o vosso anfitrião e hoje vamos analisar as diferenças cruciais entre o EAP-TLS e o EAP-TTLS para a autenticação WiFi empresarial. Se é arquiteto de rede, diretor de TI ou gere infraestruturas para grandes espaços como cadeias de retalho, hospitais ou estádios, este briefing foi desenhado especificamente para si. Vamos diretos ao assunto e discutir a arquitetura de segurança, as contrapartidas de implementação e como escolher o protocolo certo para o seu ambiente. Vamos começar.

Antes de mergulharmos nos protocolos em si, vamos enquadrar o cenário. A maioria das implementações de WiFi empresarial hoje em dia ainda depende de uma única palavra-passe partilhada - uma Pre-Shared Key, ou PSK. Cada dispositivo na rede utiliza a mesma credencial. Quando um colaborador sai ou um dispositivo é perdido, tem duas opções: alterar a palavra-passe para todos ou aceitar o risco de um ex-colaborador ou de um ladrão ainda ter credenciais válidas. Nenhuma das opções é aceitável para uma empresa séria.

A resposta é o 802.1X, a norma IEEE para controlo de acesso à rede baseado em portas. O 802.1X atribui a cada dispositivo a sua própria credencial de autenticação individual. Quando um dispositivo se liga, o ponto de acesso não concede acesso diretamente. Encaminha o pedido de autenticação para um servidor RADIUS centralizado, que verifica a credencial e indica ao ponto de acesso se deve abrir a porta. O resultado é um controlo de acesso auditável, revogável e por dispositivo. Esta é a base sobre a qual o EAP-TLS e o EAP-TTLS são construídos.

Ambos os protocolos são métodos Extensible Authentication Protocol, ou métodos EAP, que operam dentro desta estrutura 802.1X. A questão não é se deve utilizar o 802.1X. A questão é qual o método EAP a utilizar dentro dele. E é a isso que estamos aqui para responder hoje.

ANÁLISE TÉCNICA DETALHADA DO EAP-TLS (2:00 - 5:30)

Comecemos pelo EAP-TLS, que significa Transport Layer Security. O EAP-TLS está definido no RFC 5216 e é amplamente considerado o padrão de excelência para autenticação sem fios. O princípio fundamental é a autenticação mútua. Tanto o dispositivo cliente como o servidor RADIUS têm de apresentar certificados digitais X.509 válidos para provar a sua identidade antes de o acesso à rede ser concedido. Não existem palavras-passe envolvidas em qualquer ponto do processo. Zero.

Isto é extremamente importante do ponto de vista da segurança. As palavras-passe podem ser alvo de phishing. Podem ser adivinhadas por força bruta. Podem ser roubadas através de uma fuga de dados num serviço de terceiros onde o seu colaborador tenha reutilizado a mesma palavra-passe. Os certificados não podem ser alvo de phishing, não podem ser adivinhados e estão vinculados a um dispositivo específico. Se um agente malicioso quiser aceder à sua rede, precisa do dispositivo físico e da sua chave privada criptográfica integrada. Trata-se de um modelo de ameaça fundamentalmente diferente.

Deixe-me orientá-lo detalhadamente pelo handshake EAP-TLS, porque compreendê-lo esclarece a razão pela qual o protocolo é tão seguro. Quando um dispositivo tenta ligar-se à rede WiFi, o ponto de acesso envia um EAP-Request a solicitar a identidade do dispositivo. O dispositivo responde. O ponto de acesso encaminha isto para o servidor RADIUS. O servidor RADIUS inicia o handshake TLS enviando uma mensagem Server Hello, juntamente com o seu certificado X.509. O cliente valida este certificado de servidor em relação ao seu repositório de Autoridade de Certificação (CA) raiz fidedigna. Se a validação falhar, o handshake termina imediatamente. O dispositivo recusa-se a ligar. É isto que protege contra ataques Evil Twin, em que um hacker configura um ponto de acesso nocivo para se fazer passar pela sua rede.

Se o certificado do servidor for válido, o cliente apresenta então o seu próprio certificado X.509 ao servidor RADIUS. O servidor RADIUS valida o certificado do cliente: verifica a cadeia de assinaturas até à CA raiz fidedigna, verifica se o certificado não expirou e consulta a Lista de Revogação de Certificados (CRL) para garantir que o certificado não foi revogado. Apenas quando ambas as partes estão satisfeitas é que o túnel TLS é estabelecido e a mensagem EAP-Success é enviada, concedendo o acesso à rede. Toda a troca utiliza TLS 1.2 ou 1.3, proporcionando confidencialidade direta perfeita (perfect forward secrecy).

Agora, este nível de segurança traz consigo um requisito operacional: precisa de uma Infraestrutura de Chaves Públicas, ou PKI. No mínimo, precisa de uma Autoridade de Certificação raiz offline e de uma Autoridade de Certificação emissora online. A CA raiz deve estar isolada (air-gapped), porque a sua chave privada é a âncora de confiança mestre para toda a sua hierarquia de certificados. A CA emissora lida com a emissão diária de certificados e publica a Lista de Revogação de Certificados. E, fundamentalmente, necessita de um mecanismo para implementar certificados de cliente em todos os dispositivos na rede. Para uma frota de milhares de dispositivos, isto significa integrar a sua PKI com uma plataforma de Mobile Device Management (MDM) usando SCEP - o Simple Certificate Enrollment Protocol. Quando um dispositivo corporativo é registado no seu MDM, solicita e recebe automaticamente o seu certificado sem qualquer interação do utilizador.

CENÁRIOS DE IMPLEMENTAÇÃO (5:30 - 8:00)

Então, qual o protocolo que deve implementar? A decisão resume-se quase inteiramente às suas capacidades de gestão de dispositivos e aos seus requisitos de conformidade. Deixe-me apresentar-lhe uma estrutura prática de tomada de decisão.

Faça a si próprio três perguntas. Primeira: todos os dispositivos que se ligam a esta rede são geridos pela empresa através de uma plataforma MDM como o Microsoft Intune ou o Jamf? Se sim, tem a infraestrutura para implementar certificados de cliente, e o EAP-TLS é a escolha certa. Segunda: esta rede precisa de cumprir os requisitos PCI DSS 4.0, HIPAA ou WPA3 Enterprise de 192 bits? Se sim, o EAP-TLS é a escolha obrigatória. Terceira: tem uma proporção significativa de dispositivos não geridos ou BYOD? Se sim, o EAP-TTLS é a escolha pragmática para esse segmento da sua rede.

Deixe-me dar-lhe dois cenários concretos do mundo real. Cenário um: uma cadeia de retalho nacional com quatrocentas lojas. Cada terminal de ponto de venda e scanner portátil da equipa está registado no Microsoft Intune. A rede está no âmbito da norma PCI DSS 4.0. Neste ambiente, implementa-se o EAP-TLS. Estabelece uma PKI privada, utiliza o Intune para enviar certificados de cliente exclusivos para cada dispositivo via SCEP e configura o seu servidor RADIUS para verificar a Lista de Revogação de Certificados. Se um dispositivo for roubado, revoga o seu certificado e este fica fora da rede em poucos minutos. Sem palavra-passe para repor. Sem segredo partilhado para rodar em quatrocentos locais.

Cenário dois: um grande campus universitário com vinte mil estudantes a utilizar computadores portáteis, smartphones e tablets pessoais. A equipa de TI não pode instalar certificados em dispositivos pessoais. Neste ambiente, o EAP-TTLS é a escolha pragmática. Instala um certificado fidedigno nos seus servidores RADIUS, integra-se com o serviço de diretório da sua universidade e os estudantes autenticam-se utilizando as suas credenciais existentes dentro do túnel seguro. Suporta Windows, macOS, Linux, Android e iOS sem qualquer software adicional no lado do cliente.

Em muitas grandes empresas, a resposta é, na verdade, ambas. Implementa o EAP-TLS para os seus dispositivos corporativos geridos e o EAP-TTLS ou uma rede segura separada para prestadores de serviços, visitantes e BYOD. Este é um padrão comum em grupos de hotelaria, onde os dispositivos da equipa são geridos e emitidos com certificados, enquanto a infraestrutura voltada para os hóspedes utiliza um caminho de autenticação totalmente diferente.

PERGUNTAS E RESPOSTAS RÁPIDAS (8:00 - 9:00)

Deixe-me dar-lhe algumas respostas rápidas a perguntas que ouvimos frequentemente de CTOs e arquitetos de rede.

Pergunta um: O EAP-TLS é obrigatório para o WPA3 Enterprise? Se estiver a implementar o conjunto de segurança de 192 bits do WPA3 Enterprise, sim, o EAP-TLS é o único método permitido. É o único método EAP que satisfaz os requisitos de 192 bits do WPA3-Enterprise da Wi-Fi Alliance.

Pergunta dois: Podemos utilizar o EAP-TTLS para dispositivos IoT? Geralmente, não. Os dispositivos IoT sem interface de utilizador, como bombas de infusão ou sensores ambientais, costumam carecer de interface para lidar com métodos complexos de autenticação interna. O EAP-TLS é, na verdade, mais adequado para IoT, porque pode provisionar o certificado durante a preparação do dispositivo. O dispositivo autentica-se automaticamente, sem necessidade de interação do utilizador.

Pergunta três: E quanto ao BYOD numa rede EAP-TLS? Para dispositivos pessoais não geridos, o EAP-TLS é operacionalmente difícil. Pode utilizar portais de integração para fornecer um certificado temporário, mas isso adiciona fricção. Para BYOD, o EAP-TTLS ou uma rede de convidados dedicada com segmentação apropriada é normalmente a resposta certa.

Pergunta quatro: Como é que isto se relaciona com os fornecedores de hardware? Tanto o EAP-TLS como o EAP-TTLS são suportados em todas as principais plataformas de hardware de WiFi empresarial - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. Os detalhes de configuração variam de acordo com a plataforma, mas os padrões subjacentes são neutros em relação ao fornecedor.

RESUMO E PRÓXIMOS PASSOS (9:00 - 10:00)

Para resumir, aqui estão as principais conclusões. O EAP-TLS oferece a segurança mais elevada através de autenticação mútua de certificados. Elimina totalmente o risco de palavra-passe e é a escolha certa para frotas de dispositivos geridos e ambientes regulados. O EAP-TTLS oferece uma segurança forte através de certificados do lado do servidor e túneis de credenciais encriptados. É a escolha certa para ambientes mistos ou BYOD. Ambos os protocolos exigem que imponha a validação do certificado do servidor em cada cliente. Sem isso, nenhum dos protocolos o protege contra pontos de acesso fraudulentos. E a gestão do ciclo de vida dos certificados é o principal desafio operacional do EAP-TLS - automatize-a via MDM e SCEP desde o primeiro dia.

Os seus próximos passos? Audite a sua implementação 802.1X atual. Se ainda depende de palavras-passe partilhadas, planeie a sua migração. Verifique se os seus suplicantes de cliente estão a validar o certificado do servidor. E se estiver a implementar em múltiplos locais ou numa propriedade distribuída, considere um serviço RADIUS alojado na nuvem para reduzir a carga operacional. Obrigado por ouvir este briefing técnico da Purple. A Purple suporta caminhos de autenticação EAP-TLS e EAP-TTLS para Staff WiFi em mais de 80.000 locais ativos. Para guias de implementação mais detalhados e para compreender como as nossas plataformas de análise e identidade se integram com as suas redes seguras, visite purple.ai.

Principais Conclusões

✓O EAP-TLS requer autenticação mútua de certificados - tanto o dispositivo cliente como o servidor RADIUS apresentam certificados X.509. Não são partilhadas palavras-passe em momento algum, eliminando totalmente o risco de roubo de credenciais.
✓O EAP-TTLS requer apenas um certificado do lado do servidor para estabelecer um túnel TLS encriptado. O cliente autentica-se dentro do túnel utilizando credenciais de diretório existentes (nome de utilizador e palavra-passe).
✓O principal fator de decisão é a gestão de dispositivos: se controla os dispositivos via MDM, implemente EAP-TLS. Se suporta BYOD ou dispositivos não geridos, implemente EAP-TTLS.
✓O EAP-TLS é o único método EAP que cumpre os requisitos de 192 bits do WPA3-Enterprise e é fortemente recomendado para ambientes de dados de titulares de cartões PCI DSS 4.0.
✓Ambos os protocolos exigem que a validação do certificado do servidor seja imposta em cada dispositivo cliente. Sem ela, nenhum dos protocolos protege contra ataques de pontos de acesso falsos - esta é a configuração mais impactante a auditar.
✓A automatização do ciclo de vida dos certificados via MDM e SCEP não é negociável para o EAP-TLS em escala. A expiração não gerida de certificados é a causa mais comum de falhas de autenticação em massa.
✓Muitas grandes empresas implementam ambos: EAP-TLS para dispositivos corporativos geridos num SSID dedicado para Staff WiFi, e EAP-TTLS para empreiteiros e BYOD num SSID separado e segmentado.

कार्यकारी सारांश (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) और नेटवर्क उपयोग की दृश्यता प्रदान करता है। क्षेत्र-विशिष्ट परिनियोजन मार्गदर्शन के लिए, हॉस्पिटैलिटी , रिटेल , हेल्थकेयर , और ट्रांसपोर्ट के लिए हमारे संसाधनों को एक्सप्लोर करें।

Definições Principais

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

Um método de autenticação 802.1X definido no RFC 5216 que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Não são partilhadas palavras-passe. A autenticação é mútua e criptograficamente vinculada.

O padrão de excelência para a segurança wireless empresarial. Necessário para WPA3-Enterprise de 192 bits e fortemente recomendado para ambientes de dados de titulares de cartões PCI DSS 4.0.

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

Um método de autenticação 802.1X definido no RFC 5281 que exige apenas um certificado do lado do servidor para estabelecer um túnel TLS encriptado. O cliente autentica-se dentro do túnel utilizando um método de autenticação interno secundário, tipicamente um nome de utilizador e palavra-passe.

A escolha preferencial para ambientes BYOD e redes com sistemas operativos mistos onde a implementação de certificados de cliente é operacionalmente impraticável.

802.1X

Uma norma IEEE para controlo de acesso à rede baseado em portas que fornece um mecanismo de autenticação para dispositivos que se ligam a uma LAN ou WLAN. Define as funções de supplicant, authenticator e servidor de autenticação.

A estrutura fundamental que permite às redes empresariais autenticar dispositivos individuais em vez de dependerem de uma única palavra-passe partilhada. Tanto o EAP-TLS como o EAP-TTLS operam dentro desta estrutura.

RADIUS (Remote Authentication Dial-In User Service)

Um protocolo de rede que fornece gestão centralizada de autenticação, autorização e faturação (accounting) para utilizadores que se ligam a um serviço de rede. Em implementações 802.1X, o servidor RADIUS é o servidor de autenticação que verifica certificados ou credenciais.

O componente de servidor que verifica os certificados ou palavras-passe e instrui o ponto de acesso sobre se deve conceder ou negar o acesso à rede. As plataformas suportadas incluem FreeRADIUS, Microsoft NPS e Cisco ISE.

PKI (Public Key Infrastructure)

Um conjunto de funções, políticas, hardware, software e procedimentos necessários para criar, gerir, distribuir, utilizar, armazenar e revogar certificados digitais. Uma PKI empresarial típica consiste numa CA raiz offline e numa CA emissora online.

A infraestrutura de suporte necessária para emitir os certificados de cliente e de servidor utilizados na autenticação EAP-TLS. Sem uma PKI, o EAP-TLS não pode ser implementado.

MDM (Mobile Device Management)

Software utilizado pelos departamentos de TI para monitorizar, gerir e proteger os dispositivos móveis e portáteis dos colaboradores. As plataformas de MDM, como o Microsoft Intune e o Jamf, podem automatizar a implementação de certificados e perfis de WiFi nos dispositivos registados.

Essencial para automatizar a implementação em escala de certificados de cliente para EAP-TLS. Sem a integração de MDM, a instalação manual de certificados em milhares de dispositivos é operacionalmente impossível.

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo utilizado para automatizar a emissão de certificados digitais para dispositivos de rede. As plataformas de MDM utilizam o SCEP para solicitar e instalar silenciosamente certificados em dispositivos corporativos registados, sem interação do utilizador.

O mecanismo padrão para provisionamento de certificados sem intervenção (zero-touch) em implementações EAP-TLS. Suportado pelo Microsoft Intune, Jamf e pela maioria das plataformas de MDM empresariais.

CRL (Certificate Revocation List)

Uma lista de certificados digitais que foram revogados pela Autoridade de Certificação emissora antes da sua data de expiração programada. Os servidores RADIUS verificam a CRL para validar se o certificado de um dispositivo de ligação ainda é válido.

O mecanismo que lhe permite bloquear imediatamente da rede um dispositivo roubado ou comprometido, revogando o seu certificado. Os servidores RADIUS devem ser configurados para verificar a CRL frequentemente, ou utilizar OCSP para validação em tempo real.

X.509

Uma norma ITU-T que define o formato dos certificados de chave pública. O EAP-TLS e o EAP-TTLS utilizam ambos certificados X.509 para autenticação do servidor. O EAP-TLS também exige certificados X.509 no dispositivo cliente.

O formato de certificado utilizado em todas as implementações de PKI empresariais. Quando as equipas de TI se referem a "certificados digitais" no contexto do 802.1X, referem-se a certificados X.509.

Método de autenticação interna

O protocolo de autenticação secundário utilizado dentro do túnel TLS encriptado estabelecido pelo EAP-TTLS. Os métodos internos comuns incluem o PAP (Password Authentication Protocol), CHAP e MS-CHAPv2.

A escolha do método de autenticação interna afeta as propriedades de segurança de uma implementação EAP-TTLS. O PAP envia a palavra-passe em texto limpo dentro do túnel; o MS-CHAPv2 utiliza um mecanismo de desafio-resposta. O túnel encripta todo o tráfego de autenticação interna.

Exemplos Práticos

Uma cadeia de retalho nacional com 400 lojas necessita de proteger os seus terminais de ponto de venda (POS) e os scanners portáteis da equipa. O ambiente está no âmbito do PCI DSS 4.0. Todos os dispositivos estão inscritos no Microsoft Intune. Qual o protocolo que devem implementar e quais são as principais etapas de configuração?

Implementar EAP-TLS. Passo 1: Estabelecer uma PKI de dois níveis com uma CA raiz offline isolada (air-gapped) e uma CA emissora online. Passo 2: Configurar o Microsoft Intune com um perfil de certificado SCEP direcionado a todos os dispositivos POS e scanners. Passo 3: Implementar um servidor RADIUS (Microsoft NPS ou RADIUS na nuvem) e configurá-lo para validar certificados de cliente face à CA interna. Passo 4: Ativar a verificação CRL ou OCSP no servidor RADIUS. Passo 5: Distribuir um perfil de WiFi através do Intune especificando o SSID, o EAP-TLS como método de autenticação, a CA raiz fidedigna e o nome do servidor RADIUS esperado. Passo 6: Testar com um grupo piloto de 10 dispositivos antes de expandir para todos os 400 locais. Passo 7: Estabelecer um processo de monitorização de expiração de certificados com alertas aos 60, 30 e sete dias antes do vencimento.

Comentário do Examinador: O EAP-TLS é a escolha correta porque o PCI DSS 4.0 recomenda fortemente a autenticação mútua por certificado para redes sem fios no ambiente de dados de titulares de cartões. Confiar em palavras-passe (EAP-TTLS) para dispositivos POS introduz um risco inaceitável de roubo de credenciais. A integração de MDM através de SCEP é essencial - a instalação manual de certificados em 400 locais é operacionalmente inviável. O ponto de falha mais comum neste cenário é esquecer de impor a validação do certificado do servidor no perfil de WiFi do Intune, o que deixaria os dispositivos vulneráveis a ataques de Evil Twin, apesar da implementação do EAP-TLS.

Um grande campus universitário necessita de fornecer WiFi seguro para 20.000 estudantes que utilizam uma combinação de portáteis pessoais, smartphones e tablets (BYOD). A equipa de TI não pode instalar certificados em dispositivos pessoais. A universidade utiliza o Microsoft Entra ID para a gestão de identidades. Qual o protocolo que devem implementar?

Implementar EAP-TTLS com MS-CHAPv2 como método de autenticação interna, integrado com o Microsoft Entra ID através de RADIUS. Passo 1: Obter um certificado de servidor de uma CA pública fidedigna por todos os principais sistemas operativos, ou implementar uma CA interna e distribuir o certificado raiz através das ferramentas de gestão de dispositivos da universidade para os dispositivos geridos. Passo 2: Configurar o servidor RADIUS para autenticar face ao Microsoft Entra ID utilizando LDAP ou proxy RADIUS. Passo 3: Criar um guia de adesão ao WiFi para estudantes especificando o SSID, EAP-TTLS, MS-CHAPv2 e a CA fidedigna. Passo 4: Impor políticas de palavras-passe fortes ao nível do Entra ID e ponderar a ativação de autenticação multifator para a inscrição inicial. Passo 5: Configurar o perfil de WiFi para impor a validação do certificado do servidor e especificar a CA fidedigna e o nome do servidor RADIUS.

Comentário do Examinador: O EAP-TTLS é a escolha pragmática neste caso. Gerir uma PKI para 20.000 dispositivos pessoais não geridos é operacionalmente impossível. O EAP-TTLS fornece um túnel seguro para as credenciais, protegendo-as contra a interceção por rádio (over-the-air) enquanto suporta diversos sistemas operativos, incluindo Windows, macOS, Linux, Android e iOS. O risco crítico neste cenário é os estudantes configurarem incorretamente os seus dispositivos para ignorar a validação do certificado do servidor. Publicar um guia de adesão claro com passos de configuração exatos, e usar um certificado de servidor publicamente fidedigno, reduz significativamente este risco.

Perguntas de Prática

Q1. Está a implementar o EAP-TLS para uma frota de 5000 portáteis corporativos em 50 localizações de escritórios. Após enviar o perfil de WiFi através do Microsoft Intune, os dispositivos não se conseguem ligar. Os registos do servidor RADIUS mostram "CA Desconhecida" para cada tentativa de autenticação falhada. Qual é a causa mais provável e como a resolve?

Dica: Considere a cadeia de validação de certificados no lado do cliente e o que o perfil MDM deve incluir além da mera definição do método EAP.

Ver resposta modelo

Os dispositivos cliente não estão configurados para confiar na Autoridade de Certificação interna que emitiu o certificado do servidor RADIUS. O perfil de WiFi do MDM deve incluir o certificado da CA raiz (e quaisquer certificados de CA intermédia) e configurar o suplicante para confiar neles para validação do servidor. Sem isso, o cliente rejeita o certificado do servidor RADIUS e termina o handshake. Resolução: atualize o perfil de WiFi do Intune para incluir o certificado da CA raiz confiável na definição "Certificado raiz para validação do servidor" e reenvie o perfil para todos os dispositivos.

Q2. A sua organização implementou o EAP-TTLS para um ambiente BYOD misto. Durante uma auditoria de segurança, a sua equipa de testes de intrusão demonstrou que consegue capturar credenciais de utilizador ao configurar um ponto de acesso falso com um certificado autoassinado. Como corrige esta vulnerabilidade sem migrar para EAP-TLS?

Dica: Pense no que acontece antes da autenticação interna e que configuração no lado do cliente impede o estabelecimento do túnel TLS com um servidor não confiável.

Ver resposta modelo

A vulnerabilidade existe porque os dispositivos cliente não estão configurados para validar o certificado do servidor RADIUS. Correção: atualize todos os perfis de WiFi (via MDM para dispositivos geridos e através de um novo guia de integração para BYOD) para impor a validação do certificado do servidor. Especifique a CA confiável e o nome do servidor RADIUS esperado no perfil. Os clientes configurados desta forma recusar-se-ão a estabelecer o túnel TLS com qualquer servidor que não apresente um certificado assinado pela CA confiável especificada, eliminando o vetor de ataque do ponto de acesso falso.

Q3. Um diretor de TI de um hospital quer implementar o 802.1X para os seus dispositivos IoT médicos (bombas de infusão, monitores de doentes, sensores ambientais). Estão a considerar o EAP-TTLS porque acreditam que a gestão de certificados é demasiado complexa. Porque é que este raciocínio é falho e qual é a abordagem correta?

Dica: Considere como os dispositivos IoT sem interface de utilizador lidam com pedidos de autenticação e o que acontece quando um dispositivo não consegue introduzir credenciais.

Ver resposta modelo

O raciocínio é falho por duas razões. Primeiro, a maioria dos dispositivos IoT médicos headless não tem uma interface de utilizador para introduzir credenciais, tornando a operação de autenticação interna EAP-TTLS com utilizador/palavra-passe impossível do ponto de vista operacional. Segundo, o EAP-TLS é, na verdade, mais simples para IoT na prática: os certificados podem ser aprovisionados durante a preparação do dispositivo antes da implementação, e o dispositivo autentica-se automaticamente sem interação do utilizador. A abordagem correta é o EAP-TLS com certificados aprovisionados através do sistema de gestão de dispositivos utilizado durante a preparação. Isto também cumpre os requisitos da HIPAA para uma autenticação wireless forte em ambientes de cuidados de saúde.

Q4. É o arquiteto de rede de um grupo hoteleiro com 200 propriedades. Precisa de proteger o WiFi do pessoal para 3000 dispositivos geridos (inscritos no Intune) e também fornecer WiFi seguro para empreiteiros e fornecedores terceiros que trazem os seus próprios computadores portáteis. Desenhe a arquitetura de autenticação.

Dica: Considere se um único SSID com um único método EAP pode servir ambas as populações e que implicações de segmentação de rede surgem dos dois tipos de utilizadores.

Ver resposta modelo

Implemente dois SSIDs separados com diferentes métodos de autenticação e atribuições de VLAN. SSID 1 (Staff WiFi): EAP-TLS, certificados enviados através de Intune SCEP, VLAN atribuída ao segmento de rede do pessoal com acesso total aos sistemas de gestão do hotel. SSID 2 (Contractor WiFi): EAP-TTLS com MS-CHAPv2, credenciais validadas contra um diretório separado ou uma conta de empreiteiro temporária no Microsoft Entra ID, VLAN atribuída a um segmento isolado apenas com acesso à Internet e sem acesso a sistemas internos. Ambos os SSIDs devem impor a validação do certificado do servidor. Esta arquitetura oferece ao pessoal a máxima segurança enquanto fornece aos empreiteiros um método de autenticação prático, e a segmentação de rede garante que uma credencial de empreiteiro comprometida não consiga aceder aos sistemas internos de gestão do hotel.

Continue a ler esta série

Server RADIUS: um guia abrangente para empresas

Este guia fornece aos gestores de TI, arquitetos de rede e CTOs uma referência técnica definitiva sobre a autenticação de server RADIUS para WiFi empresarial. Abrange a estrutura AAA, a arquitetura 802.1X, a seleção do método EAP, as vantagens e desvantagens da implementação na cloud versus local, e a atribuição dinâmica de VLAN. Os operadores de espaços nos setores da hotelaria, retalho, eventos e setor público encontrarão orientações de implementação práticas, estudos de caso do mundo real e as estruturas de decisão necessárias para migrar de chaves pré-partilhadas inseguras para uma arquitetura de controlo de acesso à rede segura e orientada pela identidade.

Aruba ClearPass vs. Purple WiFi: Comparando Funcionalidades e Co-implementação

Um guia técnico abrangente que detalha a arquitetura de co-implementação do Aruba ClearPass e do Purple WiFi. Abrange a configuração de proxy RADIUS, atribuição dinâmica de VLAN e as melhores práticas para fornecer redes de convidados seguras e orientadas por análise de dados, em conjunto com o NAC empresarial.

Cisco ISE vs. Purple WiFi: Como se Comparam e Trabalham em Conjunto

Este guia explica como o Cisco ISE e o Purple WiFi desempenham funções distintas mas complementares em redes empresariais. Detalha como utilizar o Cisco ISE para acesso corporativo seguro 802.1X enquanto aproveita o Purple para WiFi de convidados em conformidade com o GDPR, análises de marketing e integração com CRM.