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

Parlez en anglais britannique avec un ton confiant, autoritaire et conversationnel - comme un consultant principal en sécurité réseau informant un client. Rythme mesuré, diction claire, professionnel mais sans raideur. Pauses naturelles occasionnelles pour insister : Bienvenue dans la série d'informations techniques Purple. Aujourd'hui, nous abordons un sujet qui est au cœur même de la sécurité du WiFi d'entreprise - le suppliant 802.1X. Si vous vous êtes déjà demandé pourquoi certains appareils se connectent à votre réseau d'entreprise sans invite de mot de passe, tandis que d'autres affichent des erreurs de certificat et génèrent des tickets d'assistance, cet épisode est pour vous. [pause moyenne] Commençons par les bases. Le suppliant 802.1X est le composant logiciel sur un appareil client - un ordinateur portable, un smartphone, une tablette - qui gère la négociation 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 carte d'identité de l'appareil. Le réseau ne laisse pas entrer n'importe qui. Il demande des identifiants. Le suppliant est ce 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 au 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 signifie Extensible Authentication Protocol over LAN. Tout le reste est bloqué. Une fois que le suppliant a prouvé son identité au serveur RADIUS via l'authentificateur, le port s'ouvre et le trafic normal s'écoule. [pause moyenne] Maintenant, il y a trois acteurs dans ce jeu. Premièrement, le suppliant - 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 suppliant lance le processus en envoyant un message EAPOL-Start. L'authentificateur répond par une demande d'identité EAP-Request. Le suppliant répond avec son identité. Cette identité est transmise au serveur RADIUS, qui défie ensuite le suppliant avec la méthode EAP convenue. Si tout est correct, le serveur RADIUS envoie un 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 la plupart des décisions de déploiement sont prises. EAP-TLS - c'est-à-dire 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 se déroule en douze étapes et utilise la cryptographie à clé publique-privée tout au long du processus. 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. PEAP enveloppe une méthode interne basée sur un mot de passe, généralement MSCHAPv2, à l'intérieur d'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 serveur du côté client est donc non négociable lors de l'exécution de PEAP. [medium pause] Passons maintenant au supplicant lui-même - plus précisément au 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 de configuration automatique sans fil et de 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 de configuration WiFi. Ces supplicants natifs couvrent EAP-TLS et PEAP-MSCHAPv2 sur toutes les plateformes actuelles. L'avantage des supplicants natifs est évident : aucun logiciel supplémentaire à déployer, pas de coût de licence, mises à jour de sécurité automatiques de l'OS et intégration étroite avec le magasin de certificats du système d'exploitation. Pour les parcs d'appareils gérés - machines Windows enregistrées dans Microsoft Intune, Mac gérés via Jamf - vous pouvez déployer des profils de configuration 802.1X de manière invisible 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 que vous souhaitez verrouiller les paramètres du supplicant pour que les utilisateurs ne puissent pas les configurer accidentellement de manière incorrecte, un client tiers vous offre ce contrôle. Des outils comme la suite JoinNow de SecureW2 agissent également comme des agents d'intégration - ils configurent le supplicant natif plutôt que de le remplacer, guidant les utilisateurs à travers l'enregistrement des certificats et l'installation des profils. [medium pause] Laissez-moi vous présenter deux scénarios réels pour rendre cela concret. Tout 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 afin d'éliminer l'authentification par mot de passe et de 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 machines Windows 7 héritées dans les bureaux administratifs. L'approche ici est progressive. Commencez par la flotte de 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'enregistrement de certificat basé sur SCEP à partir de la PKI interne. Ces appareils s'authentifient automatiquement dès le premier jour. Pour les appareils Android personnels (BYOD), déployez un portail d'intégration en libre-service - les utilisateurs visitent une URL, téléchargent un profil de configuration, et le supplicant est configuré pour eux. Les machines Windows 7 héritées restent sur PEAP avec une validation stricte du certificat de serveur appliquée, isolées sur un VLAN distinct avec un accès limité, jusqu'à ce qu'elles soient déclassées. [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 pour les invités. La norme PCI-DSS exige que les environnements de données des titulaires de cartes soient isolés des autres segments du réseau. Le détaillant utilise le 802.1X sur les réseaux du personnel et des points de vente, avec une attribution de VLAN basée sur les attributs de certificat. Un terminal de point de vente présente un certificat d'appareil avec une unité organisationnelle "POS" - la politique RADIUS l'affecte au VLAN PCI. Une tablette du personnel présente un certificat contenant "Staff" - elle atterrit sur le VLAN du personnel. Les appareils des invités se connectent à un SSID entièrement distinct, géré par une solution de Captive Portal. La configuration du supplicant sur les terminaux de point de vente 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, de sorte qu'il n'y a aucune intervention manuelle lors de l'expiration des certificats. [medium pause] Maintenant, les pièges de mise en œuvre. Laissez-moi vous présenter les quatre plus courants. Numéro un : l'absence de validation du certificat serveur sur les déploiements PEAP. Si vous ne configurez pas le requérant 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 pirate. Spécifiez toujours l'autorité de certification (CA) racine de confiance et le nom du serveur dans le profil du requérant. Numéro deux : l'expiration des certificats provoquant des échecs d'authentification massifs. Les certificats clients ont une période de validité. Si vous ne mettez pas en place un renouvellement automatisé via SCEP ou NDES, vous serez confronté à un événement critique 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 requérant incohérent. Android en particulier présente une prise en charge fragmentée de la norme 802.1X selon les fabricants. Certaines versions exigent que l'utilisateur installe manuellement le certificat de l'autorité de certification 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 demandes d'assistance. Numéro quatre : les mises à jour des fonctionnalités de Windows 11 qui perturbent la configuration du requérant. Microsoft a modifié le comportement de la norme 802.1X dans plusieurs mises à jour de Windows 11. Plus précisément, la mise à jour 24H2 a introduit des changements dans la façon dont le requérant natif gère le repli EAP-TLS. Testez vos profils de requérant par rapport aux nouvelles versions du système d'exploitation avant de les déployer en production. [pause moyenne] Questions rapides maintenant. Les appareils IoT peuvent-ils prendre en charge la norme 802.1X ? La plupart ne le peuvent pas. Les appareils IoT manquent généralement de requérant. La solution de secours est le contournement de l'authentification MAC - MAB - où le serveur RADIUS authentifie l'appareil sur la base 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 infrastructure PKI pour exécuter la norme 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 les coûts d'infrastructure. Comment la norme 802.1X interagit-elle 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 d'autres. Sur les réseaux WiFi du personnel, l'extension SecurePass de Purple s'intègre à votre fournisseur d'identité - Microsoft Entra ID, Okta ou Google Workspace - pour appliquer l'authentification 802.1X et des politiques de VLAN par utilisateur sans nécessiter d'infrastructure RADIUS sur site. [pause moyenne] Pour résumer : le requérant 802.1X est l'agent côté appareil qui permet au contrôle d'accès réseau basé sur les ports de fonctionner. Votre choix de méthode EAP - EAP-TLS pour une sécurité maximale, PEAP comme option de transition - détermine vos exigences de PKI et votre approche de configuration du requérant. Les requérants natifs du système d'exploitation couvrent la majorité des scénarios d'appareils gérés lorsqu'ils sont déployés via une solution MDM. Les clients tiers apportent de la valeur dans des cas spécifiques : méthodes EAP propriétaires, parcs de systèmes d'exploitation 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 suppliant, automatisez le renouvellement des certificats avant de déployer l'EAP-TLS à grande échelle, et isolez les appareils qui ne peuvent pas prendre en charge le 802.1X - IoT, matériel hérité - sur des VLANs dédiés avec le contournement d'authentification MAC comme solution de repli. Pour en savoir plus sur la façon dont Purple s'intègre à votre architecture d'accès réseau, visitez purple dot ai. Merci pour votre écoute.