Comment configurer le WiFi d'entreprise sur les appareils Android avec EAP-TLS

Comment configurer le WiFi d'entreprise sur les appareils Android avec EAP-TLS Un point technique de Purple - Environ 10 minutes - INTRODUCTION ET CONTEXTE - environ 1 minute Bienvenue dans la série des points techniques de Purple. Je suis votre hôte, et aujourd'hui, nous allons aborder les spécificités du déploiement de l'authentification 802.1X EAP-TLS sur les appareils Android - que vous gériez un parc hôtelier, une chaîne de vente au détail, un stade ou un campus du secteur public. Si vous êtes responsable d'un réseau qui doit authentifier des appareils Android professionnels ou BYOD sans dépendre de mots de passe partagés, cet épisode est pour vous. EAP-TLS est la référence absolue en matière de sécurité WiFi d'entreprise - il utilise une authentification mutuelle basée sur des certificats, ce qui signifie qu'il n'y a pas d'identifiants à hameçonner, pas de mots de passe à renouveler, et une posture de conformité qui satisfait aux exigences PCI-DSS, ISO 27001 et à la plupart des cadres de sécurité du secteur public. À la fin de ce point technique, vous comprendrez exactement comment fonctionne EAP-TLS sur Android, quelles sont vos options de déploiement et les trois erreurs les plus courantes qui provoquent l'échec des déploiements. C'est parti. - ANALYSE TECHNIQUE APPROFONDIE - environ 5 minutes Commençons par l'architecture. Le 802.1X est la norme IEEE qui régit le contrôle d'accès au réseau basé sur les ports. Lorsqu'un appareil Android se connecte à un réseau WiFi d'entreprise - configuré en WPA2-Enterprise ou WPA3-Enterprise - le point d'accès agit en tant qu'authentificateur. Il ne prend pas la décision d'authentification lui-même ; il transmet la conversation entre l'appareil et un serveur RADIUS, qui est le véritable serveur d'authentification. EAP-TLS - pour Extensible Authentication Protocol avec Transport Layer Security - est la méthode d'authentification qui s'exécute au sein de ce cadre 802.1X. Ce qui la différencie d'EAP-PEAP ou d'EAP-TTLS, qui utilisent un nom d'utilisateur et un mot de passe dans un tunnel TLS, c'est que EAP-TLS utilise des certificats X.509 des deux côtés. Le serveur RADIUS présente un certificat de serveur à l'appareil, et l'appareil présente en retour un certificat de client au serveur RADIUS. Les deux parties se valident mutuellement. C'est l'authentification mutuelle, et c'est ce qui fait d'EAP-TLS l'option la plus sécurisée disponible. Maintenant, sur Android spécifiquement, il y a quelques éléments à comprendre. Android 11 et les versions ultérieures ont introduit des exigences de validation de certificat plus strictes. Si vous effectuez un déploiement sur Android 11 ou version supérieure - ce qui représente aujourd'hui la grande majorité de votre parc - l'appareil refusera de se connecter à moins que le certificat du serveur RADIUS ne soit explicitement approuvé. Vous ne pouvez pas vous fier uniquement au magasin de confiance du système ; vous devez soit envoyer le certificat de l'autorité de certification (CA) racine à l'appareil, soit configurer le profil WiFi pour y faire explicitement référence. Parlons de la chaîne de certificats. Vous devez mettre en place trois composants avant qu'un seul appareil Android ne puisse s'authentifier via EAP-TLS. Tout d'abord, une autorité de certification - qu'il s'agisse de votre PKI interne, de Microsoft Active Directory Certificate Services ou d'une PKI cloud comme SCEP via Intune. Deuxièmement, un certificat de serveur délivré à votre serveur RADIUS, signé par cette autorité de certification. Troisièmement, un certificat client unique délivré à chaque appareil ou utilisateur, également signé par la même autorité de certification. L'appareil présente son certificat client lors de la négociation TLS, et le serveur RADIUS le valide par rapport à la liste de révocation de certificats de l'autorité de certification, ou CRL, ou via OCSP - Online Certificate Status Protocol. Pour Android, le certificat client et la clé privée sont généralement regroupés sous forme de fichier PKCS12 - c'est-à-dire un fichier .P12 ou .PFX - qui contient à la fois le certificat et la clé privée chiffrée. Sur un appareil configuré manuellement, l'utilisateur importe ce fichier via les Paramètres, puis Sécurité, puis Installer un certificat. Sur un appareil géré par MDM, le certificat est poussé silencieusement vers le magasin de clés géré de l'appareil - aucune interaction de l'utilisateur n'est requise. Parlons maintenant du profil WiFi lui-même. Lors de la configuration d'une connexion WiFi d'entreprise sur Android, vous devez spécifier : l'SSID, le type de sécurité - WPA2-Enterprise ou WPA3-Enterprise - la méthode EAP - qui est TLS - le certificat de l'autorité de certification pour la validation du serveur, le certificat client pour l'authentification de l'appareil et la chaîne d'identité, qui est généralement le Common Name de l'appareil ou l'UPN de l'utilisateur. Sur Android 11 et versions ultérieures, vous devez également spécifier la correspondance du suffixe de domaine ou le sujet du certificat du serveur pour empêcher les attaques de l'homme du milieu. Pour les déploiements MDM - et c'est là que réside la véritable puissance de l'évolutivité - vous poussez tout cela sous forme de profil de configuration structuré. Dans Microsoft Intune, vous créez un profil de certificat SCEP qui demande et installe automatiquement un certificat client unique sur chaque appareil Android enregistré. Vous créez ensuite un profil de configuration WiFi qui fait référence à ce profil de certificat. Lorsque l'appareil se connecte, il reçoit à la fois le certificat et le profil WiFi, et il se connecte automatiquement à votre réseau 802.1X. Aucune interaction de l'utilisateur, aucun appel au support. Si vous utilisez Intune à cette fin, notre guide d'accompagnement sur la façon d'utiliser Microsoft Intune pour pousser des certificats WiFi sur les appareils détaille les étapes de configuration exactes - je vous recommande de le lire en parallèle avec cette présentation. Pour VMware Workspace ONE et Jamf Connect, le processus est identique sur le plan de l'architecture - un profil de certificat SCEP ou PKCS, suivi d'un profil WiFi qui y fait référence. L'interface utilisateur spécifique diffère, mais la chaîne de certificats et les exigences de configuration RADIUS restent les mêmes. Une chose importante à signaler concernant RADIUS : si vous utilisez FreeRADIUS, Microsoft NPS ou Cisco ISE, assurez-vous que le certificat de votre serveur inclut les attributs corrects d'utilisation étendue de la clé (EKU) - en particulier, l'authentification du serveur, OID 1.3.6.1.5.5.7.3.1. Android est très strict à ce sujet. Un certificat qui fonctionne parfaitement avec les clients Windows peut échouer sur Android si l'EKU est absent ou mal configuré. --- RECOMMANDATIONS DE MISE EN OEUVRE ET PIÈGES À ÉVITER - environ 2 minutes Abordons maintenant les problèmes réels rencontrés sur le terrain, car c'est là que la plupart des déploiements rencontrent des difficultés. Le premier échec, et le plus courant, concerne la confiance des certificats. Android 11 et les versions supérieures ne se connecteront pas si la chaîne de certification du serveur RADIUS ne peut pas être validée. La solution est simple : déployez le certificat de votre autorité de certification (CA) racine dans le magasin de certificats utilisateur de l'appareil via votre MDM, et référencez-le explicitement dans le champ du certificat CA du profil WiFi. Ne laissez pas ce paramètre sur "Ne pas valider" - c'est une faille de sécurité et cela échouera de toute façon sur certaines versions d'Android. Le deuxième piège est l'expiration des certificats. Les certificats clients ont généralement une durée de validité de un à deux ans. Si vous ne mettez pas en place un renouvellement automatisé via SCEP ou NDES, vous risquez de vous réveiller un matin et de constater que la moitié de votre parc d'appareils a perdu l'accès au WiFi simultanément. Intégrez l'automatisation du renouvellement des certificats dans votre flux de travail MDM dès le premier jour, et non après coup. Le troisième problème concerne la capacité du serveur RADIUS. Les négociations EAP-TLS sont plus gourmandes en ressources de calcul que les négociations PEAP en raison de l'échange mutuel complet de certificats. Dans un stade ou un centre de conférence avec des milliers d'authentifications simultanées, un serveur RADIUS sous-dimensionné deviendra un goulot d'étranglement. Dimensionnez votre infrastructure RADIUS pour les pics d'authentifications simultanées, et non pour la charge moyenne. Enfin, du côté d'Android, sachez que différents fabricants - Samsung, Google, Xiaomi - ont des implémentations légèrement différentes de l'API de configuration WiFi. Testez les profils déployés par votre MDM sur des appareils représentatifs de chaque fabricant de votre parc avant de procéder à un déploiement à grande échelle. Les appareils Samsung, en particulier, ont historiquement exigé que le champ d'identité soit explicitement défini, même lorsqu'il peut être déduit du certificat. --- QUESTIONS-RÉPONSES RAPIDES - environ 1 minute Voici quelques questions rapides que l'on me pose régulièrement. Puis-je utiliser EAP-TLS pour les appareils BYOD ? Oui, mais cela nécessite que l'utilisateur installe un certificat client sur son appareil personnel. Pour un BYOD à grande échelle, déterminez si EAP-TTLS avec PAP ou PEAP-MSCHAPv2 constitue un compromis plus pratique, en réservant EAP-TLS aux appareils appartenant à l'entreprise. EAP-TLS fonctionne-t-il avec WPA3-Enterprise ? Oui, et WPA3-Enterprise avec le mode 192 bits impose d'ailleurs EAP-TLS. Si vous déployez WPA3-Enterprise dans des environnements hautement sécurisés, EAP-TLS est votre seule option conforme. Quelle est la version minimale d'Android que je devrais cibler ? Android 8 et versions supérieures prennent en charge EAP-TLS nativement. Pour Android 11 et versions supérieures, imposez la validation explicite du certificat de l'autorité de certification (CA). Pour Android 13 et versions supérieures, vous pouvez exploiter les API de gestion des certificats améliorées pour un contrôle plus granulaire. La plateforme de Purple peut-elle s'intégrer aux réseaux EAP-TLS ? La plateforme d'analyse et de WiFi invité de Purple fonctionne sur un SSID distinct de votre réseau d'entreprise 802.1X. Vos appareils d'entreprise s'authentifient via EAP-TLS sur le SSID sécurisé, tandis que les appareils invités utilisent le captive portal de Purple sur le SSID invité. Les deux coexistent sur la même infrastructure de point d'accès, la séparation par VLAN assurant la frontière de sécurité. - RÉSUMÉ ET PROCHAINES ÉTAPES - environ 1 minute Pour conclure : EAP-TLS sur Android est la méthode d'authentification WiFi d'entreprise la plus sécurisée disponible, et avec les outils de MDM modernes, elle est tout à fait pratique à déployer à grande échelle. Les trois aspects à maîtriser sont : une infrastructure PKI correctement configurée avec renouvellement automatique des certificats, une confiance explicite envers le certificat CA sur Android 11 et versions supérieures, et une infrastructure RADIUS dimensionnée pour la charge de pointe. Si vous déployez sur un site avec un trafic mixte d'entreprise et d'invités, la plateforme de Purple vous offre la couche d'analyse et d'engagement sur le réseau invité tandis que votre infrastructure EAP-TLS sécurise le côté entreprise. Les deux se complètent parfaitement. Pour vos prochaines étapes : consultez notre schéma d'architecture dans le guide complet, suivez le guide de déploiement Intune et réalisez un pilote sur un sous-ensemble d'appareils avant de le déployer sur l'ensemble de votre parc. Commencez par un groupe contrôlé de cinquante appareils, validez la distribution des certificats ainsi que la connectivité WiFi, puis déployez à grande échelle en toute confiance. Merci d'avoir écouté le briefing technique de Purple. Vous trouverez le guide écrit complet, les schémas et les références de configuration sur purple.ai. À la prochaine.