Qu'est-ce qu'un supplicant 802.1X ? Types de clients et configuration des appareils

S'exprimer en anglais britannique avec un ton confiant, autoritaire et conversationnel - comme un consultant senior en sécurité réseau briefant un client. Rythme mesuré, diction claire, professionnel mais pas rigide. Pauses naturelles occasionnelles pour accentuer le propos : Bienvenue dans la série de briefings techniques de Purple. Aujourd'hui, nous abordons un sujet qui est au cœur même de la sécurité WiFi d'entreprise : le supplicant 802.1X. Si vous vous êtes déjà demandé pourquoi certains appareils se connectent à votre réseau d'entreprise sans demander de mot de passe, alors que d'autres affichent des erreurs de certificat et génèrent des tickets d'assistance, cet épisode est fait pour vous. [pause moyenne] Commençons par les bases. Le supplicant 802.1X est le composant logiciel d'un appareil client - un ordinateur portable, un smartphone, une tablette - qui gère le handshake d'authentification lorsque cet appareil tente de rejoindre un réseau protégé par la norme IEEE 802.1X. Considérez-le comme le présentateur de la carte d'identité de l'appareil. Le réseau ne laisse pas entrer n'importe qui. Il demande des identifiants. Le supplicant est celui qui s'avance et dit : "voici qui je suis, voici mon certificat, laissez-moi entrer". La norme elle-même - IEEE 802.1X - définit le contrôle d'accès réseau basé sur les ports. Avant que l'authentification ne réussisse, le point d'accès ou le commutateur ne laisse passer qu'un type de trafic très restreint : les trames EAPOL, qui signifient Extensible Authentication Protocol over LAN. Tout le reste est bloqué. Une fois que le supplicant prouve son identité au serveur RADIUS via l'authentificateur, le port s'ouvre et le trafic normal circule. [pause moyenne] Il y a maintenant trois acteurs dans ce scénario. Premièrement, le supplicant - l'appareil client. Deuxièmement, l'authentificateur - votre point d'accès ou commutateur, du matériel comme Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist. Troisièmement, le serveur d'authentification - presque toujours un serveur RADIUS, qui valide les identifiants par rapport à un annuaire comme Microsoft Entra ID ou Okta. Le supplicant lance le processus en envoyant un message EAPOL-Start. L'authentificateur répond par une demande d'identité EAP-Request. Le supplicant répond avec son identité. Cette identité est transmise au serveur RADIUS, qui défie ensuite le supplicant avec la méthode EAP convenue. Si tout est correct, le serveur RADIUS envoie un message Access-Accept, le port s'ouvre et l'appareil est placé sur le bon VLAN. [pause moyenne] Parlons des méthodes EAP, car c'est là que se prennent la plupart des décisions de déploiement. EAP-TLS - à savoir Extensible Authentication Protocol avec Transport Layer Security - est la référence absolue. Il exige que le client et le serveur présentent tous deux des certificats. Authentification mutuelle. Pas de mots de passe. Le certificat client prouve l'identité de l'appareil ; le certificat serveur prouve que le réseau est légitime, ce qui protège contre les attaques de type « evil twin » (jumeau malveillant) où un point d'accès pirate tente de récupérer des identifiants. EAP-TLS s'exécute en douze étapes et utilise la cryptographie à clé publique-privée d'un bout à l'autre. C'est la méthode requise pour le WPA3-Enterprise dans son mode de sécurité le plus élevé, et elle s'aligne sur les exigences de la norme NIST SP 800-171 pour la vérification de l'identité des appareils. PEAP - Protected EAP - est le point de départ le plus courant pour les organisations qui ne disposent pas encore d'une PKI complète. Le PEAP encapsule une méthode interne basée sur un mot de passe, généralement MSCHAPv2, dans un tunnel TLS. Le serveur présente un certificat ; le client n'en présente pas. Cela signifie que le déploiement est plus simple - vous n'avez pas besoin de fournir de certificats clients - mais qu'il est moins sécurisé. MSCHAPv2 utilise le hachage MD4, considéré comme compromis depuis 1995. Si un utilisateur se connecte à un point d'accès pirate qui présente un certificat d'apparence fiable, ses identifiants peuvent être interceptés. La validation du certificat du serveur côté client est donc non négociable lors de l'utilisation de PEAP. [medium pause] Penchons-nous maintenant sur le supplicant lui-même - et plus particulièrement sur le choix entre les supplicants natifs du système d'exploitation et les logiciels clients tiers. Chaque système d'exploitation majeur est livré avec un supplicant 802.1X intégré. Windows le prend en charge nativement depuis XP, via les services Configuration automatique sans fil et Configuration automatique câblée. macOS et iOS gèrent le 802.1X via leurs profils de configuration réseau. Android le prend en charge via le panneau des paramètres WiFi. Ces supplicants natifs couvrent l'EAP-TLS et le PEAP-MSCHAPv2 sur toutes les plateformes actuelles. L'avantage des supplicants natifs est évident : aucun logiciel supplémentaire à déployer, aucun coût de licence, des mises à jour de sécurité automatiques de l'OS et une intégration étroite avec le magasin de certificats du système d'exploitation. Pour les flottes d'appareils gérés - machines Windows enregistrées dans Microsoft Intune, Mac gérés via Jamf - vous pouvez pousser des profils de configuration 802.1X de manière silencieuse via MDM, et les utilisateurs ne voient jamais d'invite. L'appareil s'authentifie automatiquement chaque fois qu'il se trouve à portée. Les supplicants tiers entrent en jeu dans des scénarios spécifiques. Si vous utilisez une infrastructure Cisco et souhaitez utiliser EAP-FAST - la méthode EAP propriétaire de Cisco - vous avez besoin du logiciel client de Cisco, historiquement le Secure Services Client ou AnyConnect Network Access Manager. Si vous avez besoin d'une gestion de configuration cohérente sur un parc d'OS mixtes et souhaitez verrouiller les paramètres du supplicant afin que les utilisateurs ne puissent pas les configurer de manière incorrecte par accident, un client tiers vous offre ce contrôle. Des outils comme la suite JoinNow de SecureW2 agissent également comme des agents d'onboarding : ils configurent le supplicant natif au lieu de le remplacer, guidant les utilisateurs à travers l'enrôlement des certificats et l'installation des profils. [medium pause] Laissez-moi vous présenter deux scénarios réels pour rendre cela concret. D'abord, un hôtel de 400 chambres. L'établissement exploite aujourd'hui un réseau pour le personnel sur WPA2-Enterprise avec PEAP-MSCHAPv2. L'équipe informatique souhaite migrer vers EAP-TLS pour éliminer l'authentification par mot de passe et réduire le risque de vol d'identifiants. Le défi : les appareils du personnel sont un mélange d'ordinateurs portables Windows gérés via Intune, de téléphones Android personnels utilisés pour le logiciel de gestion de l'établissement, et de quelques anciennes machines Windows 7 dans les bureaux administratifs. L'approche ici est progressive. Commencez par la flotte Windows gérée. Déployez un profil de configuration Intune qui installe le certificat de l'autorité de certification (CA) racine du serveur RADIUS, configure le profil WiFi pour EAP-TLS, et déclenche l'enrôlement de certificat basé sur SCEP depuis la PKI interne. Ces appareils s'authentifient automatiquement dès le premier jour. Pour les appareils Android personnels (BYOD), déployez un portail d'onboarding en libre-service : les utilisateurs visitent une URL, téléchargent un profil de configuration, et le supplicant est configuré pour eux. Les anciennes machines Windows 7 restent sur PEAP avec une validation stricte du certificat de serveur appliquée, isolées dans un VLAN distinct avec un accès limité, jusqu'à leur mise hors service. [medium pause] Deuxième scénario : une grande chaîne de vente au détail de 200 magasins. Chaque magasin dispose d'un mélange de terminaux de point de vente, de tablettes pour le personnel et d'un réseau WiFi invité. La norme PCI DSS exige que les environnements de données des titulaires de cartes soient isolés des autres segments de réseau. Le détaillant utilise le 802.1X sur les réseaux du personnel et des terminaux de point de vente (POS), avec une attribution de VLAN basée sur les attributs des certificats. Un terminal POS présente un certificat d'appareil avec une unité organisationnelle "POS" - la politique RADIUS l'attribue au VLAN PCI. Une tablette du personnel présente un certificat avec "Staff" - elle atterrit sur le VLAN du personnel. Les appareils invités se connectent entièrement à un SSID distinct, géré par une solution de Captive Portal. La configuration du supplicant sur les terminaux POS est verrouillée via MDM. Aucune interaction de l'utilisateur n'est requise. Les terminaux s'authentifient silencieusement au démarrage. Le renouvellement des certificats est automatisé via SCEP, il n'y a donc aucune intervention manuelle à l'expiration des certificats. [medium pause] Maintenant, passons aux pièges de mise en œuvre. Laissez-moi vous présenter les quatre plus courants. Numéro un : l'absence de validation du certificat du serveur sur les déploiements PEAP. Si vous ne configurez pas le supplicant pour valider le certificat du serveur RADIUS et vérifier le nom du serveur, les utilisateurs risquent de se connecter à un point d'accès malveillant. Spécifiez toujours l'AC racine de confiance et le nom du serveur dans le profil du supplicant. Numéro deux : l'expiration des certificats provoquant des échecs d'authentification massifs. Les certificats clients ont une période de validité. Si vous n'avez pas mis en place de renouvellement automatisé via SCEP ou NDES, vous ferez face à un effet de falaise où des centaines d'appareils cesseront de s'authentifier simultanément. Intégrez l'automatisation du renouvellement avant la mise en production. Numéro trois : les appareils BYOD avec un comportement de supplicant incohérent. Android en particulier présente un support 802.1X fragmenté selon les fabricants. Certaines versions nécessitent que l'utilisateur installe manuellement le certificat de l'AC avant que le profil WiFi ne l'accepte. Un portail d'intégration qui gère cette étape réduit considérablement le volume de tickets d'assistance. Numéro quatre : les mises à jour de fonctionnalités de Windows 11 qui perturbent la configuration du supplicant. Microsoft a modifié le comportement du 802.1X dans plusieurs mises à jour de Windows 11. Plus précisément, la mise à jour 24H2 a introduit des changements dans la manière dont le supplicant natif gère le repli EAP-TLS. Testez vos profils de supplicant avec les nouvelles versions du système d'exploitation avant de les déployer en production. [medium pause] Questions-réponses rapides à présent. Les appareils IoT peuvent-ils prendre en charge le 802.1X ? La plupart ne le peuvent pas. Les appareils IoT manquent généralement totalement de supplicant. La solution de repli est le MAC Authentication Bypass - MAB - où le serveur RADIUS authentifie l'appareil en fonction de son adresse MAC. Les adresses MAC pouvant être usurpées, les appareils MAB doivent toujours être placés sur un VLAN IoT isolé avec des règles de pare-feu strictes. Ai-je besoin d'une PKI pour exécuter le 802.1X ? Pour PEAP, non - vous avez seulement besoin d'un certificat serveur sur le serveur RADIUS. Pour EAP-TLS, oui - vous avez besoin d'une PKI pour émettre des certificats clients. Les services PKI basés sur le cloud réduisent considérablement la charge d'infrastructure. Comment le 802.1X interagit-il avec la plateforme d'accès réseau de Purple ? Purple fonctionne comme une surcouche cloud au-dessus de votre matériel existant - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist et autres. Sur les réseaux WiFi du personnel, le module complémentaire SecurePass de Purple s'intègre à votre fournisseur d'identité - Microsoft Entra ID, Okta ou Google Workspace - pour appliquer l'authentification 802.1X et les politiques VLAN par utilisateur sans nécessiter d'infrastructure RADIUS sur site. [medium pause] Pour résumer : le supplicant 802.1X est l'agent côté appareil qui permet le fonctionnement du contrôle d'accès réseau basé sur les ports. Votre choix de méthode EAP - EAP-TLS pour une sécurité maximale, PEAP comme option de transition - détermine vos besoins en PKI et votre approche de configuration du supplicant. Les supplicants natifs du système d'exploitation couvrent la majorité des scénarios d'appareils gérés lorsqu'ils sont déployés via MDM. Les clients tiers apportent de la valeur dans des cas spécifiques : méthodes EAP propriétaires, parcs d'OS mixtes nécessitant une configuration cohérente ou intégration BYOD en libre-service. Les trois points à retenir : validez le certificat de votre serveur RADIUS sur chaque profil de supplicant, automatisez le renouvellement des certificats avant de déployer EAP-TLS à grande échelle, et isolez les appareils qui ne prennent pas en charge 802.1X - IoT, matériel hérité - sur des VLAN dédiés avec le MAC Authentication Bypass comme solution de secours. Pour en savoir plus sur la façon dont Purple s'intègre à votre architecture d'accès réseau, visitez purple point ai. Merci pour votre écoute.