EAP-TLS vs. PEAP : quel protocole d'authentification convient à votre réseau ?

EAP-TLS vs PEAP : quel protocole d'authentification convient à votre réseau ? Un briefing technique Purple [INTRODUCTION — environ 1 minute] Bienvenue dans ce briefing technique Purple. Je suis votre hôte, et aujourd'hui nous abordons l'une des décisions les plus importantes que vous aurez à prendre lors de la conception ou de la mise à niveau de votre infrastructure sans fil d'entreprise : le choix entre EAP-TLS et PEAP pour votre framework d'authentification 802.1X. Si vous êtes responsable informatique, architecte réseau ou CTO en charge d'un groupe hôtelier, d'un parc de magasins, d'un stade ou d'une organisation du secteur public, cette décision affecte votre niveau de sécurité, votre conformité et la charge opérationnelle quotidienne de votre équipe. Alors, allons droit au but. EAP-TLS et PEAP sont tous deux des méthodes d'authentification 802.1X. Ils s'appuient tous deux sur un serveur RADIUS pour gérer les demandes d'authentification, et ils offrent tous deux une sécurité nettement plus forte qu'une phrase secrète WPA2 partagée. Mais leur façon de vérifier l'identité est fondamentalement différente — et cette différence a des implications majeures sur la façon dont vous déployez, gérez et faites évoluer votre réseau. [TECHNICAL DEEP-DIVE — environ 5 minutes] Commençons par EAP-TLS — Extensible Authentication Protocol Transport Layer Security. EAP-TLS est la référence absolue en matière d'authentification WiFi d'entreprise. Sa caractéristique déterminante est l'authentification mutuelle par certificat. En pratique, cela signifie que lorsqu'un appareil tente de se connecter à votre réseau, le serveur RADIUS lui présente un certificat numérique. L'appareil vérifie ce certificat par rapport à ses autorités de certification de confiance. Mais voici la différence essentielle avec PEAP : l'appareil présente ensuite son propre certificat au serveur. Le serveur valide ce certificat client, et l'accès au réseau n'est accordé que si les deux certificats sont valides et approuvés. Il n'y a aucun mot de passe en jeu. Aucun. L'authentification repose entièrement sur des certificats. Cela rend EAP-TLS extraordinairement résistant au vol d'identifiants, aux attaques par dictionnaire et aux attaques de l'homme du milieu (Man-in-the-Middle). On ne peut tout simplement pas voler un mot de passe qui n'existe pas dans le flux d'authentification. En contrepartie, la complexité du déploiement est plus élevée. Pour exploiter EAP-TLS à grande échelle, vous avez besoin d'une infrastructure à clés publiques — une PKI — pour émettre, gérer et révoquer des certificats pour chaque appareil de votre réseau. Vous avez également besoin d'une solution de gestion des appareils mobiles (MDM) pour pousser ces certificats de manière silencieuse vers les terminaux. Si vous gérez un parc d'entreprise avec Microsoft Intune ou Jamf, c'est tout à fait gérable. Si ce n'est pas le cas, EAP-TLS devient un projet d'envergure. L'autre aspect opérationnel à prendre en compte est la gestion du cycle de vie des certificats. Les certificats expirent. Si le certificat de votre serveur RADIUS expire, tous les appareils de votre réseau échoueront à s'authentifier en même temps. C'est une panne catastrophique. Les processus de surveillance et de renouvellement des certificats sont non négociables. Penchons-nous maintenant sur PEAP — Protected Extensible Authentication Protocol. PEAP a été conçu pour répondre à la complexité de déploiement d'EAP-TLS tout en offrant une sécurité robuste. L'idée clé derrière PEAP est la suivante : seul le serveur a besoin d'un certificat. Le client n'en a pas besoin. Voici comment cela fonctionne. Le serveur RADIUS présente son certificat à l'appareil client. Le client valide le serveur — tout comme dans EAP-TLS. Cela établit un tunnel TLS chiffré. À l'intérieur de ce tunnel sécurisé, le client effectue ensuite une authentification standard par mot de passe, généralement à l'aide de MSCHAPv2, par rapport à votre annuaire d'identités — Active Directory, LDAP, Google Workspace, peu importe ce que vous utilisez. Le mot de passe ne circule jamais en clair. Il est toujours protégé à l'intérieur du tunnel chiffré. PEAP est donc véritablement sécurisé — à condition d'être configuré correctement. Et c'est là que nous devons parler de la mauvaise configuration la plus courante et la plus dangereuse dans les déploiements PEAP. Si un appareil client n'est pas configuré pour valider strictement le certificat du serveur RADIUS, un attaquant peut configurer un point d'accès malveillant portant le même nom de réseau, présenter un certificat frauduleux, et l'appareil s'y connectera sans problème. L'attaquant capture alors l'échange d'authentification MSCHAPv2, qui peut être piraté hors ligne. Il ne s'agit pas d'une attaque théorique — c'est une technique bien documentée utilisée lors de tests d'intrusion réels. La solution est simple : utilisez des stratégies de groupe (GPO), des profils MDM ou des outils d'intégration pour imposer une validation stricte du certificat du serveur sur chaque appareil client. Mais la réalité opérationnelle est que, dans les environnements BYOD, s'assurer que cette configuration est appliquée de manière cohérente sur des milliers d'appareils personnels non gérés est particulièrement difficile. Laissez-moi vous donner une comparaison concrète. Prenons une chaîne de vente au détail de 500 magasins. Ils disposent de tablettes et de scanners portables appartenant à l'entreprise, tous gérés via Microsoft Intune. EAP-TLS est le bon choix. Intune pousse les certificats automatiquement. Si un scanner est perdu, le service informatique révoque son certificat et il est hors réseau en quelques minutes — pas de réinitialisation de mot de passe, pas de changement de phrase secrète partagée sur 500 magasins. La sécurité est absolue. Considérons maintenant un grand centre de conférences qui gère le WiFi pour 3 000 collaborateurs sur leurs appareils personnels. Pas de MDM. Le personnel utilise Google Workspace. PEAP intégré à Google Secure LDAP est le choix pragmatique. Les collaborateurs s'authentifient avec leurs identifiants habituels. L'équipe informatique fournit une documentation d'intégration pour configurer la validation des certificats. C'est déployable en quelques jours, pas en quelques mois. L'architecture qui sous-tend ces deux protocoles est le même modèle 802.1X à trois composants : le supplicant — c'est-à-dire l'appareil client —, l'authentificateur, qui est votre point d'accès ou votre commutateur, et le serveur RADIUS. L'authentificateur agit comme un gardien, bloquant tout le trafic jusqu'à ce que le serveur RADIUS signale que l'authentification a réussi. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — environ 2 minutes] Quelles sont donc les recommandations pratiques ? Premièrement : si vous disposez d'une solution MDM et d'appareils appartenant à l'entreprise, déployez EAP-TLS. L'investissement initial dans la PKI et la gestion des certificats est payant en termes de réduction des risques et de simplification des audits de conformité. Pour les environnements réglementés — santé, finance, secteur public —, ce n'est pas une option. C'est l'architecture que vos auditeurs s'attendent à voir. Deuxièmement : si vous gérez un environnement BYOD ou si vous ne disposez pas d'infrastructure MDM, déployez PEAP. Mais ne faites pas l'impasse sur la configuration de la validation du certificat du serveur. Utilisez des outils d'intégration, des portails de contrôle d'accès réseau ou des profils MDM dans la mesure du possible pour l'imposer. Traitez cela comme une étape de déploiement obligatoire, et non comme une mesure de sécurisation facultative. Troisièmement : quel que soit le protocole choisi, intégrez la redondance RADIUS dans votre architecture. L'authentification est un élément critique. Une seule défaillance du serveur RADIUS signifie que plus personne ne peut accéder au réseau. Les solutions RADIUS hébergées dans le cloud peuvent offrir cette résilience sans la charge liée à la gestion d'une infrastructure locale redondante. Quatrièmement : segmentez votre réseau après l'authentification. Une authentification 802.1X réussie ne doit pas accorder un accès illimité à l'ensemble du réseau de votre entreprise. Utilisez des politiques d'attribution de VLAN pour placer les utilisateurs dans les segments de réseau appropriés avec les contrôles d'accès adéquats. Les pièges courants à éviter : l'expiration des certificats provoquant des échecs d'authentification massifs dans les déploiements EAP-TLS ; les appareils clients qui ne valident pas les certificats de serveur dans les déploiements PEAP ; et les problèmes de délai d'attente (timeout) RADIUS causés par une latence élevée entre le contrôleur sans fil et le serveur d'authentification — particulièrement fréquents dans les parcs géographiquement distribués. [RAPID-FIRE Q&A — environ 1 minute] Passons en revue quelques questions fréquemment posées. Puis-je exécuter à la fois EAP-TLS et PEAP sur le même réseau ? Oui. De nombreuses organisations utilisent EAP-TLS pour les appareils de l'entreprise sur un SSID et PEAP pour le BYOD ou l'accès invité sur un SSID distinct, avec une segmentation réseau appropriée entre les deux. Est-ce que le WPA3 change la donne ? Le WPA3 Enterprise impose un mode de sécurité 192 bits pour les déploiements hautement sécurisés, ce qui s'aligne sur EAP-TLS. Le WPA3 Personal utilise SAE au lieu de PSK, mais pour les déploiements 802.1X d'entreprise, le choix de la méthode EAP reste pertinent. Le PEAP est-il conforme à la norme PCI DSS ? Oui, lorsqu'il est correctement configuré avec la validation du certificat du serveur activée. Cependant, pour les environnements traitant des données de titulaires de cartes, EAP-TLS est de plus en plus recommandé lors des évaluations de sécurité. Qu'en est-il d'OpenRoaming ? OpenRoaming utilise une authentification basée sur des certificats en arrière-plan, s'alignant sur les principes d'EAP-TLS. Des plateformes comme Purple peuvent agir en tant que fournisseur d'identité pour OpenRoaming, permettant une itinérance fluide et sécurisée entre les sites sans réauthentification. [SUMMARY AND NEXT STEPS — environ 1 minute] Pour résumer : EAP-TLS est l'option offrant la sécurité la plus élevée, éliminant totalement les mots de passe grâce à l'authentification mutuelle par certificat. Il nécessite une infrastructure PKI et MDM mais offre la posture de conformité la plus solide et le contrôle d'accès le plus granulaire au niveau des appareils. PEAP est le choix pragmatique pour le BYOD et les environnements sans infrastructure de gestion des certificats, offrant une authentification chiffrée robuste à l'aide des identifiants existants — mais uniquement lorsque la validation du certificat du serveur est rigoureusement appliquée. Le cadre de décision est simple : si vous gérez vos appareils, utilisez EAP-TLS. Si vos utilisateurs apportent leurs propres appareils, utilisez PEAP — mais configurez-le correctement. Pour vos prochaines étapes : auditez votre configuration d'authentification actuelle, évaluez votre préparation en matière de PKI et de MDM, et examinez votre infrastructure RADIUS pour la redondance et la latence. Si vous déployez ou mettez à niveau un WiFi invité parallèlement à votre réseau d'entreprise, réfléchissez à la manière dont une plateforme comme Purple peut s'intégrer à votre framework d'authentification pour offrir à la fois sécurité et analyses exploitables à partir de votre réseau. Merci d'avoir suivi ce briefing technique Purple. À la prochaine.