EAP-TLS vs EAP-TTLS : Quel protocole WiFi basé sur les certificats choisir ?

Ce guide propose une comparaison directe et définitive entre EAP-TLS et EAP-TTLS pour l'authentification WiFi d'entreprise sous la norme IEEE 802.1X. Il explique la différence architecturale entre l'authentification mutuelle par certificat et le tunneling de certificat côté serveur uniquement, et offre aux responsables informatiques, architectes réseau et RSSI un cadre de décision clair basé sur les capacités de gestion des appareils et les exigences de conformité. Purple prend en charge les parcours d'authentification EAP-TLS et EAP-TTLS pour le WiFi du personnel, et ce guide aide les organisations à comprendre les compromis d'infrastructure avant de s'engager dans l'une ou l'autre approche.

📖 9 min de lecture📝 2,090 mots🔧 2 exemples concrets❓ 4 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du podcast

INTRODUCTION ET CONTEXTE (0:00 - 2:00)

Bonjour et bienvenue dans ce briefing technique de Purple. Je suis votre hôte et aujourd'hui, nous décortiquons les différences cruciales entre EAP-TLS et EAP-TTLS pour l'authentification WiFi d'entreprise. Si vous êtes un architecte réseau, un directeur informatique ou si vous gérez l'infrastructure de grands espaces tels que des chaînes de magasins, des hôpitaux ou des stades, ce briefing a été conçu spécifiquement pour vous. Nous allons aller droit au but et aborder l'architecture de sécurité, les compromis d'implémentation et la façon de choisir le protocole adapté à votre environnement. Entrons directement dans le vif du sujet.

Avant de plonger dans les protocoles eux-mêmes, posons le décor. La majorité des déploiements WiFi d'entreprise actuels reposent encore sur un mot de passe unique partagé : une clé prépartagée, ou PSK. Chaque appareil sur le réseau utilise le même identifiant. Lorsqu'un employé s'en va ou qu'un appareil est perdu, vous avez deux options : changer le mot de passe pour tout le monde, ou accepter le risque qu'un ancien employé ou un voleur dispose toujours d'identifiants valides. Aucune de ces solutions n'est acceptable pour une entreprise sérieuse.

La solution est le 802.1X, la norme IEEE pour le contrôle d'accès réseau basé sur les ports. Le 802.1X attribue à chaque appareil son propre identifiant d'authentification individuel. Lorsqu'un appareil se connecte, le point d'accès n'accorde pas l'accès directement. Il transmet la demande d'authentification à un serveur RADIUS centralisé, qui vérifie l'identifiant et indique au point d'accès s'il doit ouvrir le port. Le résultat est un contrôle d'accès par appareil, auditable et révocable. C'est le fondement sur lequel EAP-TLS et EAP-TTLS sont tous deux basés.

Les deux protocoles sont des méthodes de protocole d'authentification extensible, ou méthodes EAP, qui fonctionnent au sein de ce framework 802.1X. La question n'est pas de savoir s'il faut utiliser le 802.1X. La question est de savoir quelle méthode EAP utiliser en son sein. Et c'est à cette question que nous allons répondre aujourd'hui.

ANALYSE TECHNIQUE APPROFONDIE D'EAP-TLS (2:00 - 5:30)

Commençons par EAP-TLS, qui signifie Transport Layer Security. EAP-TLS est défini dans la spécification RFC 5216 et est largement considéré comme la référence absolue en matière d'authentification sans fil. Le principe fondamental est l'authentification mutuelle. L'appareil client et le serveur RADIUS doivent tous deux présenter des certificats numériques X.509 valides pour prouver leur identité avant que l'accès au réseau ne soit accordé. Aucun mot de passe n'intervient à aucun moment du processus. Zéro.

Cela revêt une importance capitale du point de vue de la sécurité. Les mots de passe peuvent être hameçonnés. Ils peuvent être devinés par force brute. Ils peuvent être volés lors d'une violation de données chez un service tiers où votre employé a réutilisé le même mot de passe. Les certificats ne peuvent pas être hameçonnés, ne peuvent pas être devinés et sont liés à un appareil spécifique. Si un acteur malveillant souhaite accéder à votre réseau, il a besoin de l'appareil physique et de sa clé privée cryptographique intégrée. Il s'agit d'un modèle de menace fondamentalement différent.

Laissez-moi vous guider à travers la poignée de main (handshake) EAP-TLS en détail, car sa compréhension permet de clarifier pourquoi ce protocole est si sécurisé. Lorsqu'un appareil tente de se connecter au réseau WiFi, le point d'accès envoie une requête EAP-Request pour obtenir l'identité de l'appareil. L'appareil répond. Le point d'accès transmet cette réponse au serveur RADIUS. Le serveur RADIUS initialise la poignée de main TLS en envoyant un message Server Hello, accompagné de son certificat X.509. Le client valide ce certificat de serveur par rapport à son magasin d'Autorités de Certification (CA) racines de confiance. Si la validation échoue, la poignée de main s'interrompt immédiatement. L'appareil refuse de se connecter. C'est ce qui protège contre les attaques de type Evil Twin, où un pirate configure un point d'accès malveillant pour usurper l'identité de votre réseau.

Si le certificat du serveur est valide, le client présente alors son propre certificat X.509 au serveur RADIUS. Le serveur RADIUS valide le certificat du client : il vérifie la chaîne de signatures remontant jusqu'à la CA racine de confiance, s'assure que le certificat n'a pas expiré et consulte la liste de révocation de certificats (CRL) pour garantir que le certificat n'a pas été révoqué. Ce n'est que lorsque les deux parties sont satisfaites que le tunnel TLS est établi et que le message EAP-Success est envoyé, accordant ainsi l'accès au réseau. L'ensemble de l'échange utilise TLS 1.2 ou 1.3, offrant une confidentialité persistante parfaite (perfect forward secrecy).

À présent, ce niveau de sécurité s'accompagne d'une exigence opérationnelle : vous avez besoin d'une infrastructure à clés publiques, ou PKI. Au minimum, il vous faut une Autorité de Certification racine hors ligne et une Autorité de Certification émettrice en ligne. La CA racine doit être isolée physiquement (air-gapped), car sa clé privée constitue l'ancre de confiance maîtresse de toute votre hiérarchie de certificats. La CA émettrice gère l'émission quotidienne des certificats et publie la liste de révocation de certificats. De plus, de manière critique, vous avez besoin d'un mécanisme pour déployer des certificats clients sur chaque appareil du réseau. Pour un parc de milliers d'appareils, cela implique d'intégrer votre PKI à une plateforme de gestion d'appareils mobiles (MDM) à l'aide de SCEP (Simple Certificate Enrollment Protocol). Lorsqu'un appareil d'entreprise est enregistré dans votre MDM, il demande et reçoit automatiquement son certificat sans aucune interaction de l'utilisateur.

SCÉNARIOS DE MISE EN ŒUVRE (5:30 - 8:00)

Alors, quel protocole devriez-vous déployer ? La décision dépend presque entièrement de vos capacités de gestion des appareils et de vos exigences de conformité. Laissez-moi vous proposer un cadre de décision pratique.

Posez-vous trois questions. Premièrement : tous les appareils se connectant à ce réseau sont-ils gérés par l'entreprise via une plateforme MDM comme Microsoft Intune ou Jamf ? Si oui, vous disposez de l'infrastructure nécessaire pour déployer des certificats clients, et EAP-TLS est le bon choix. Deuxièmement : ce réseau doit-il répondre aux exigences PCI DSS 4.0, HIPAA ou WPA3 Enterprise 192 bits ? Si oui, EAP-TLS est le choix requis. Troisièmement : avez-vous une proportion importante d'appareils non gérés ou personnels (BYOD) ? Si oui, EAP-TTLS est le choix pragmatique pour ce segment de votre réseau.

Permettez-moi de vous présenter deux scénarios concrets du monde réel. Premier scénario : une chaîne nationale de vente au détail comptant quatre cents magasins. Chaque terminal de point de vente et chaque scanner portatif du personnel est enregistré dans Microsoft Intune. Le réseau entre dans le champ d'application de la norme PCI DSS 4.0. Dans cet environnement, vous déployez EAP-TLS. Vous établissez une PKI privée, utilisez Intune pour déployer des certificats clients uniques sur chaque appareil via SCEP, et configurez votre serveur RADIUS pour vérifier la liste de révocation des certificats. Si un appareil est volé, vous révoquez son certificat et il est exclu du réseau en quelques minutes. Aucun mot de passe à réinitialiser. Aucun secret partagé à renouveler sur quatre cents sites.

Deuxième scénario : un grand campus universitaire comptant vingt mille étudiants utilisant des ordinateurs portables, des smartphones et des tablettes personnels. L'équipe informatique ne peut pas installer de certificats sur les appareils personnels. Dans cet environnement, EAP-TTLS est le choix pragmatique. Vous installez un certificat de confiance sur vos serveurs RADIUS, vous l'intégrez au service d'annuaire de votre université, et les étudiants s'authentifient à l'aide de leurs identifiants existants à l'intérieur du tunnel sécurisé. Il prend en charge Windows, macOS, Linux, Android et iOS sans aucun logiciel supplémentaire côté client.

Dans de nombreuses grandes entreprises, la réponse consiste en fait à combiner les deux. Vous déployez EAP-TLS pour vos appareils d'entreprise gérés, et EAP-TTLS ou un réseau sécurisé distinct pour les sous-traitants, les visiteurs et le BYOD. Il s'agit d'un modèle courant dans les groupes hôteliers, où les appareils du personnel sont gérés et dotés de certificats, tandis que l'infrastructure destinée aux clients utilise un parcours d'authentification totalement différent.

Q&R RAPIDES (8h00 - 9h00)

Permettez-moi de vous apporter quelques réponses rapides aux questions que nous posent fréquemment les CTO et les architectes réseau.

Question 1 : EAP-TLS est-il obligatoire pour WPA3 Enterprise ? Si vous implémentez la suite de sécurité WPA3 Enterprise 192 bits, oui, EAP-TLS est la seule méthode autorisée. C'est la seule méthode EAP qui répond aux exigences de la Wi-Fi Alliance pour le WPA3-Enterprise 192 bits.

Question 2 : Pouvons-nous utiliser EAP-TTLS pour les appareils IoT ? En général, non. Les appareils IoT sans écran (headless), comme les pompes à perfusion ou les capteurs environnementaux, manquent généralement d'interface pour gérer des méthodes d'authentification internes complexes. EAP-TLS est en fait mieux adapté à l'IoT, car vous pouvez provisionner le certificat lors de la phase de préparation de l'appareil. L'appareil s'authentifie automatiquement, sans aucune interaction de l'utilisateur.

Question 3 : Qu'en est-il du BYOD sur un réseau EAP-TLS ? Pour les appareils personnels non gérés, EAP-TLS est difficile à gérer sur le plan opérationnel. Vous pouvez utiliser des portails d'embarquement pour provisionner un certificat temporaire, mais cela ajoute des frictions. Pour le BYOD, EAP-TTLS ou un réseau invité dédié avec une segmentation appropriée est généralement la bonne réponse.

Question 4 : Quel est le rapport avec les fournisseurs de matériel informatique ? EAP-TLS et EAP-TTLS sont tous deux pris en charge par toutes les principales plateformes de matériel WiFi d'entreprise : Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et Ubiquiti UniFi. Les détails de configuration varient selon la plateforme, mais les normes sous-jacentes sont indépendantes des fournisseurs.

RÉSUMÉ ET PROCHAINES ÉTAPES (9:00 - 10:00)

Pour conclure, voici vos principaux points à retenir. L'EAP-TLS offre le plus haut niveau de sécurité grâce à l'authentification mutuelle par certificat. Il élimine totalement le risque lié aux mots de passe et constitue le choix idéal pour les flottes d'appareils gérés et les environnements réglementés. L'EAP-TTLS offre une sécurité robuste grâce à des certificats côté serveur et un tunnel d'identification chiffré. C'est le choix idéal pour les environnements mixtes ou BYOD. Les deux protocoles exigent que vous imposiez la validation du certificat du serveur sur chaque client. Sans cela, aucun des deux protocoles ne vous protège contre les points d'accès malveillants. De plus, la gestion du cycle de vie des certificats est le principal défi opérationnel de l'EAP-TLS : automatisez-la via MDM et SCEP dès le premier jour.

Vos prochaines étapes ? Auditez votre déploiement 802.1X actuel. Si vous dépendez toujours de mots de passe partagés, planifiez votre migration. Vérifiez si les demandeurs (supplicants) de vos clients valident le certificat du serveur. Et si vous effectuez un déploiement sur plusieurs sites ou sur un parc distribué, envisagez un service RADIUS hébergé dans le cloud pour réduire la charge opérationnelle. Merci d'avoir écouté ce briefing technique de Purple. Purple prend en charge les parcours d'authentification EAP-TLS et EAP-TTLS pour le Staff WiFi à travers nos plus de 80 000 sites actifs. Pour des guides de déploiement plus détaillés et pour comprendre comment nos plateformes d'analyse et d'identité s'intègrent à vos réseaux sécurisés, visitez purple dot ai.

Points clés à retenir

✓EAP-TLS nécessite une authentification mutuelle par certificat : l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509. Aucun mot de passe n'est échangé à aucun moment, éliminant totalement le risque de vol d'identifiants.
✓EAP-TTLS ne nécessite qu'un certificat côté serveur pour établir un tunnel TLS chiffré. Le client s'authentifie à l'intérieur du tunnel à l'aide de ses identifiants d'annuaire existants (nom d'utilisateur et mot de passe).
✓Le principal facteur de décision est la gestion des appareils : si vous contrôlez les appareils via un MDM, déployez EAP-TLS. Si vous devez prendre en charge le BYOD ou des appareils non managés, déployez EAP-TTLS.
✓EAP-TLS est la seule méthode EAP qui répond aux exigences de chiffrement 192 bits de WPA3-Enterprise et elle est fortement recommandée pour les environnements de données de titulaires de cartes PCI DSS 4.0.
✓Les deux protocoles exigent que la validation du certificat serveur soit appliquée sur chaque appareil client. Sans cela, aucun des deux protocoles ne protège contre les attaques de points d'accès malveillants (rogue AP) – c'est la configuration la plus importante à auditer.
✓L'automatisation du cycle de vie des certificats via MDM et SCEP est indispensable pour déployer EAP-TLS à grande échelle. L'expiration non gérée des certificats est la cause la plus fréquente d'échecs d'authentification de masse.
✓De nombreuses grandes entreprises déploient les deux : EAP-TLS pour les appareils d'entreprise managés sur un SSID Staff WiFi dédié, et EAP-TTLS pour les sous-traitants et le BYOD sur un SSID distinct et segmenté.

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

Définitions clés

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

Une méthode d'authentification 802.1X définie dans la RFC 5216 qui exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. Aucun mot de passe n'est échangé. L'authentification est mutuelle et liée par cryptographie.

La référence absolue en matière de sécurité sans fil d'entreprise. Requis pour le WPA3-Enterprise 192 bits et fortement recommandé pour les environnements de données de titulaires de cartes PCI DSS 4.0.

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

Une méthode d'authentification 802.1X définie dans la RFC 5281 qui ne requiert qu'un certificat côté serveur pour établir un tunnel TLS chiffré. Le client s'authentifie à l'intérieur du tunnel à l'aide d'une méthode d'authentification interne secondaire, généralement un identifiant et un mot de passe.

Le choix privilégié pour les environnements BYOD et les réseaux aux systèmes d'exploitation mixtes où le déploiement de certificats clients n'est pas viable sur le plan opérationnel.

802.1X

Une norme IEEE pour le contrôle d'accès réseau basé sur les ports, qui fournit un mécanisme d'authentification pour les appareils se connectant à un LAN ou un WLAN. Elle définit les rôles de supplicant, d'authentificateur et de serveur d'authentification.

Le cadre fondamental qui permet aux réseaux d'entreprise d'authentifier des appareils individuels plutôt que de s'appuyer sur un seul mot de passe partagé. EAP-TLS et EAP-TTLS fonctionnent tous deux au sein de ce cadre.

RADIUS (Remote Authentication Dial-In User Service)

Un protocole réseau qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité pour les utilisateurs se connectant à un service réseau. Dans les déploiements 802.1X, le serveur RADIUS est le serveur d'authentification qui vérifie les certificats ou les identifiants.

Le composant serveur qui vérifie les certificats ou les mots de passe et indique au point d'accès s'il doit accorder ou refuser l'accès au réseau. Les plateformes prises en charge incluent FreeRADIUS, Microsoft NPS et Cisco ISE.

PKI (Public Key Infrastructure)

Un ensemble de rôles, de politiques, de matériel, de logiciels et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques. Une PKI d'entreprise type se compose d'une CA racine hors ligne et d'une CA d'émission en ligne.

L'infrastructure d'arrière-plan requise pour émettre les certificats clients et serveurs utilisés dans l'authentification EAP-TLS. Sans PKI, l'EAP-TLS ne peut pas être déployé.

MDM (Mobile Device Management)

Logiciel utilisé par les services informatiques pour surveiller, gérer et sécuriser les appareils mobiles et les ordinateurs portables des employés. Les plateformes MDM comme Microsoft Intune et Jamf peuvent automatiser le déploiement de certificats et de profils WiFi sur les appareils enregistrés.

Indispensable pour automatiser le déploiement à grande échelle des certificats clients pour l'EAP-TLS. Sans intégration MDM, l'installation manuelle de certificats sur des milliers d'appareils est impossible sur le plan opérationnel.

SCEP (Simple Certificate Enrollment Protocol)

Un protocole utilisé pour automatiser la délivrance de certificats numériques aux appareils réseau. Les plateformes MDM utilisent SCEP pour demander et installer silencieusement des certificats sur les appareils d'entreprise enregistrés, sans intervention de l'utilisateur.

Le mécanisme standard pour le provisionnement transparent de certificats (zero-touch) dans les déploiements EAP-TLS. Pris en charge par Microsoft Intune, Jamf et la plupart des plateformes MDM d'entreprise.

CRL (Certificate Revocation List)

Une liste de certificats numériques qui ont été révoqués par l'Autorité de Certification émettrice avant leur date d'expiration prévue. Les serveurs RADIUS vérifient la CRL pour s'assurer que le certificat d'un appareil connecté est toujours valide.

Le mécanisme qui vous permet de bloquer immédiatement du réseau un appareil volé ou compromis en révoquant son certificat. Les serveurs RADIUS doivent être configurés pour vérifier fréquemment la CRL, ou utiliser OCSP pour une validation en temps réel.

X.509

Une norme de l'UIT-T définissant le format des certificats à clé publique. EAP-TLS et EAP-TTLS utilisent tous deux des certificats X.509 pour l'authentification du serveur. EAP-TLS requiert également des certificats X.509 sur l'appareil client.

Le format de certificat utilisé dans tous les déploiements de PKI d'entreprise. Lorsque les équipes informatiques font référence aux « certificats numériques » dans le contexte du 802.1X, elles désignent les certificats X.509.

Méthode d'authentification interne

Le protocole d'authentification secondaire utilisé à l'intérieur du tunnel TLS chiffré établi par EAP-TTLS. Les méthodes internes courantes incluent PAP (Password Authentication Protocol), CHAP et MS-CHAPv2.

Le choix de la méthode d'authentification interne affecte les propriétés de sécurité d'un déploiement EAP-TTLS. PAP envoie le mot de passe en texte clair à l'intérieur du tunnel ; MS-CHAPv2 utilise un mécanisme de défi-réponse. Le tunnel chiffre tout le trafic d'authentification interne.

Exemples concrets

Une chaîne nationale de vente au détail comptant 400 magasins doit sécuriser ses terminaux de point de vente (POS) et les scanners portables de son personnel. L'environnement entre dans le champ d'application de la norme PCI DSS 4.0. Tous les appareils sont enregistrés dans Microsoft Intune. Quel protocole doivent-ils déployer et quelles sont les principales étapes de configuration ?

Déployer EAP-TLS. Étape 1 : Établir une PKI à deux niveaux avec une CA racine hors ligne (air-gapped) et une CA émettrice en ligne. Étape 2 : Configurer Microsoft Intune avec un profil de certificat SCEP ciblant tous les terminaux POS et scanners. Étape 3 : Déployer un serveur RADIUS (Microsoft NPS ou RADIUS cloud) et le configurer pour valider les certificats clients par rapport à la CA interne. Étape 4 : Activer la vérification CRL ou OCSP sur le serveur RADIUS. Étape 5 : Déployer un profil WiFi via Intune en spécifiant le SSID, EAP-TLS comme méthode d'authentification, la CA racine de confiance et le nom du serveur RADIUS attendu. Étape 6 : Tester avec un groupe pilote de 10 appareils avant de déployer sur les 400 sites. Étape 7 : Établir un processus de surveillance de l'expiration des certificats avec des alertes à 60, 30 et 7 jours avant l'échéance.

Commentaire de l'examinateur : EAP-TLS est le bon choix car la norme PCI DSS 4.0 recommande vivement l'authentification mutuelle par certificat pour les réseaux sans fil dans l'environnement des données de titulaires de carte. S'en remettre à des mots de passe (EAP-TTLS) pour les terminaux POS introduit un risque inacceptable de vol d'identifiants. L'intégration MDM via SCEP est essentielle : l'installation manuelle de certificats sur 400 sites est impossible d'un point de vue opérationnel. Le point de défaillance le plus courant dans ce scénario est l'oubli de forcer la validation du certificat du serveur dans le profil WiFi d'Intune, ce qui laisserait les appareils vulnérables aux attaques de type Evil Twin malgré le déploiement d'EAP-TLS.

Un grand campus universitaire doit fournir un accès WiFi sécurisé à 20 000 étudiants utilisant un mélange d'ordinateurs portables personnels, de smartphones et de tablettes (BYOD). L'équipe informatique ne peut pas installer de certificats sur les appareils personnels. L'université utilise Microsoft Entra ID pour la gestion des identités. Quel protocole doivent-ils déployer ?

Déployer EAP-TTLS avec MS-CHAPv2 comme méthode d'authentification interne, intégré à Microsoft Entra ID via RADIUS. Étape 1 : Obtenir un certificat de serveur auprès d'une CA publique approuvée par tous les principaux systèmes d'exploitation, ou déployer une CA interne et distribuer le certificat racine via les outils de gestion d'appareils de l'université pour les terminaux gérés. Étape 2 : Configurer le serveur RADIUS pour qu'il s'authentifie auprès de Microsoft Entra ID à l'aide de LDAP ou d'un proxy RADIUS. Étape 3 : Créer un guide de connexion WiFi pour les étudiants spécifiant le SSID, EAP-TTLS, MS-CHAPv2 et la CA de confiance. Étape 4 : Appliquer des politiques de mots de passe forts au niveau d'Entra ID et envisager d'activer l'authentification multifacteur pour l'inscription initiale. Étape 5 : Configurer le profil WiFi pour imposer la validation du certificat du serveur et spécifier la CA de confiance ainsi que le nom du serveur RADIUS.

Commentaire de l'examinateur : L'EAP-TTLS est ici le choix pragmatique. Gérer une PKI pour 20 000 appareils personnels non managés est impossible sur le plan opérationnel. L'EAP-TTLS fournit un tunnel sécurisé pour les identifiants, les protégeant contre l'interception sur les ondes tout en prenant en charge divers systèmes d'exploitation, notamment Windows, macOS, Linux, Android et iOS. Le risque critique dans ce scénario est que les étudiants configurent mal leurs appareils et ignorent la validation du certificat du serveur. La publication d'un guide d'intégration clair avec les étapes de configuration exactes, et l'utilisation d'un certificat de serveur publiquement approuvé, réduit considérablement ce risque.

Questions d'entraînement

Q1. Vous déployez EAP-TLS pour une flotte de 5 000 ordinateurs portables d'entreprise répartis sur 50 bureaux. Après avoir déployé le profil WiFi via Microsoft Intune, les appareils ne parviennent pas à se connecter. Les journaux du serveur RADIUS indiquent « Unknown CA » pour chaque tentative d'authentification ayant échoué. Quelle est la cause la plus probable et comment la résoudre ?

Conseil : Considérez la chaîne de validation des certificats du côté client, et ce que le profil MDM doit inclure au-delà de la simple configuration de la méthode EAP.

Voir la réponse type

Les appareils clients ne sont pas configurés pour faire confiance à l'Autorité de Certification interne qui a émis le certificat du serveur RADIUS. Le profil WiFi du MDM doit inclure le certificat de l'AC racine (et tous les certificats d'AC intermédiaires) et configurer le suppliant pour leur faire confiance pour la validation du serveur. Sans cela, le client rejette le certificat du serveur RADIUS et interrompt le handshake. Résolution : mettez à jour le profil WiFi Intune pour inclure le certificat de l'AC racine de confiance sous le paramètre « Certificat racine pour la validation du serveur », et redéployez le profil sur tous les appareils.

Q2. Votre organisation a déployé EAP-TTLS pour un environnement BYOD mixte. Lors d'un audit de sécurité, votre équipe de tests d'intrusion démontre qu'elle peut capturer les identifiants des utilisateurs en configurant un point d'accès malveillant avec un certificat auto-signé. Comment corriger cette vulnérabilité sans migrer vers EAP-TLS ?

Conseil : Pensez à ce qui se passe avant l'authentification interne et à la configuration côté client qui empêche le tunnel TLS de s'établir avec un serveur non approuvé.

Voir la réponse type

La vulnérabilité existe car les appareils clients ne sont pas configurés pour valider le certificat du serveur RADIUS. Résolution : mettez à jour tous les profils WiFi (via MDM pour les appareils gérés, et via un nouveau guide d'intégration pour le BYOD) afin d'imposer la validation du certificat du serveur. Spécifiez l'AC de confiance et le nom attendu du serveur RADIUS dans le profil. Les clients ainsi configurés refuseront d'établir le tunnel TLS avec tout serveur incapable de présenter un certificat signé par l'AC de confiance spécifiée, éliminant ainsi le vecteur d'attaque par point d'accès malveillant.

Q3. Un directeur informatique d'hôpital souhaite déployer le 802.1X pour ses appareils IoT médicaux (pompes à perfusion, moniteurs patients, capteurs environnementaux). Il envisage d'utiliser EAP-TTLS car il estime que la gestion des certificats est trop complexe. Pourquoi ce raisonnement est-il erroné, et quelle est la bonne approche ?

Conseil : Considérez comment les appareils IoT sans écran gèrent les invites d'authentification et ce qui se passe lorsqu'un appareil ne peut pas saisir d'identifiants.

Voir la réponse type

Le raisonnement est erroné pour deux raisons. Premièrement, la plupart des appareils IoT médicaux headless ne disposent pas d'une interface utilisateur pour saisir des identifiants, ce qui rend l'authentification interne EAP-TTLS avec nom d'utilisateur/mot de passe opérationnellement impossible. Deuxièmement, EAP-TLS est en réalité plus simple pour l'IoT en pratique : les certificats peuvent être provisionnés lors de la phase de préparation de l'appareil (staging) avant son déploiement, et l'appareil s'authentifie automatiquement sans aucune interaction de l'utilisateur. La bonne approche est EAP-TLS avec des certificats provisionnés via le système de gestion des appareils utilisé lors de la phase de préparation. Cela répond également aux exigences de la réglementation HIPAA en matière d'authentification sans fil forte dans les environnements de santé.

Q4. Vous êtes l'architecte réseau d'un groupe hôtelier comptant 200 établissements. Vous devez sécuriser le WiFi du personnel pour 3 000 appareils d'entreprise managés (inscrits dans Intune) et fournir également un WiFi sécurisé pour les sous-traitants et les prestataires externes qui apportent leurs propres ordinateurs portables. Concevez l'architecture d'authentification.

Conseil : Demandez-vous si un seul SSID avec une seule méthode EAP peut répondre aux besoins de ces deux populations, et quelles sont les implications en matière de segmentation de réseau qui découlent de ces deux types d'utilisateurs.

Voir la réponse type

Déployez deux SSIDs distincts avec des méthodes d'authentification et des affectations de VLAN différentes. SSID 1 (Staff WiFi) : EAP-TLS, certificats déployés via Intune SCEP, VLAN affecté au segment de réseau du personnel avec un accès complet aux systèmes de gestion de l'hôtel. SSID 2 (Contractor WiFi) : EAP-TTLS avec MS-CHAPv2, identifiants validés par rapport à un annuaire distinct ou un compte de sous-traitant à durée limitée dans Microsoft Entra ID, VLAN affecté à un segment isolé d'accès internet uniquement sans aucun accès aux systèmes internes. Les deux SSIDs doivent imposer la validation du certificat du serveur. Cette architecture offre au personnel le niveau de sécurité le plus élevé tout en fournissant aux sous-traitants une méthode d'authentification pratique, et la segmentation du réseau garantit qu'un identifiant de sous-traitant compromis ne peut pas accéder aux systèmes internes de gestion de l'hôtel.

Continuer la lecture de cette série

Serveur RADIUS : un guide complet pour les entreprises

Ce guide fournit aux responsables informatiques, architectes réseau et directeurs techniques une référence technique définitive sur l'authentification serveur RADIUS pour le WiFi d'entreprise. Il couvre le framework AAA, l'architecture 802.1X, la sélection de la méthode EAP, les arbitrages de déploiement entre cloud et sur site, ainsi que l'attribution dynamique de VLAN. Les exploitants de sites dans l'hôtellerie, le commerce, l'événementiel et le secteur public y trouveront des conseils de mise en œuvre pratiques, des études de cas réelles et les cadres décisionnels nécessaires pour migrer de clés prépartagées non sécurisées vers une architecture de contrôle d'accès réseau sécurisée et basée sur l'identité.

Aruba ClearPass vs. Purple WiFi : comparaison des fonctionnalités et co-déploiement

Un guide technique complet détaillant l'architecture de co-déploiement d'Aruba ClearPass et de Purple WiFi. Il traite de la configuration du proxy RADIUS, de l'attribution dynamique de VLAN et des meilleures pratiques pour fournir des réseaux d'invités sécurisés et axés sur l'analyse de données aux côtés du contrôle d'accès réseau (NAC) d'entreprise.

Cisco ISE vs. Purple WiFi : comparaison et complémentarité

Ce guide explique comment Cisco ISE et Purple WiFi remplissent des rôles distincts mais complémentaires au sein des réseaux d'entreprise. Il détaille comment utiliser Cisco ISE pour un accès d'entreprise sécurisé 802.1X tout en tirant parti de Purple pour un WiFi invité conforme au GDPR, des analyses marketing et l'intégration CRM.