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

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 rigidité. Pauses naturelles occasionnelles pour insister : Bienvenue dans la série d'informations techniques de Purple. Aujourd'hui, nous allons aborder un sujet qui se trouve au cœur même de la sécurité 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 génèrent des erreurs de certificat et des tickets d'assistance, cet épisode est fait 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 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 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 circule. [pause moyenne] Maintenant, il y a trois acteurs dans cette pièce. Tout d'abord, 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 se prennent la plupart des décisions de déploiement. 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. Une 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" où un point d'accès malveillant 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 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 en matière de 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 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 malveillant qui présente un certificat d'apparence fiable, ses identifiants peuvent être capturés. La validation du certificat du serveur du côté client est donc non négociable lors de l'exécution de PEAP. [medium pause] Entrons maintenant dans le vif du sujet avec le supplicant lui-même - en particulier 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 de configuration WiFi. Ces supplicants natifs couvrent EAP-TLS et PEAP-MSCHAPv2 sur toutes les plateformes actuelles. L'avantage des supplicants natifs est évident : pas de logiciel supplémentaire à déployer, pas de 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 - les machines Windows enregistrées dans Microsoft Intune, les Mac gérés via Jamf - vous pouvez pousser des profils de configuration 802.1X de manière transparente via MDM, et les utilisateurs ne voient jamais d'invite. L'appareil s'authentifie automatiquement dès qu'il se trouve à portée. Des 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 de systèmes d'exploitation mixtes et souhaitez verrouiller les paramètres du supplicant afin que les utilisateurs ne puissent pas les configurer de manière erronée par accident, 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'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. Tout d'abord, un hôtel de 400 chambres. L'établissement gère 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 personnels Android utilisés pour le logiciel de gestion de l'établissement, et de quelques anciennes machines Windows 7 dans les bureaux de back-office. L'approche ici est progressive. Commencez par le parc Windows géré. Déployez un profil de configuration Intune qui installe le certificat CA racine du serveur RADIUS, configure le profil WiFi pour EAP-TLS, et déclenche l'enrôlement de certificat basé sur SCEP à partir de la PKI interne. Ces appareils s'authentifient automatiquement dès le premier jour. Pour les appareils BYOD Android, 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 anciennes machines Windows 7 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'à leur mise hors service. [medium pause] Second 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 de 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 des certificats. 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 avec "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 pas d'intervention manuelle à l'expiration des certificats. [medium pause] À présent, 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 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 ne disposez pas d'un renouvellement automatisé via SCEP ou NDES, vous ferez face à un effet de falaise où des centaines d'appareils cesseront de s'authentifier simultanément. Mettez en place 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 exigent 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 au support. Numéro quatre : les mises à jour des fonctionnalités de Windows 11 qui perturbent la configuration du supplicant. Microsoft a modifié le comportement de 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. [pause moyenne] Questions rapides maintenant. Les appareils IoT peuvent-ils prendre en charge 802.1X ? La plupart ne le peuvent pas. Les appareils IoT manquent généralement 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 802.1X ? Pour PEAP, non - vous avez seulement besoin d'un certificat de 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 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, 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 déployer des politiques de VLAN par utilisateur sans nécessiter d'infrastructure RADIUS sur site. [pause moyenne] Pour résumer : le supplicant 802.1X est l'agent côté appareil qui permet le bon 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 des systèmes 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 de systèmes d'exploitation mixtes nécessitant une configuration cohérente, ou intégration BYOD en libre-service. Les trois points essentiels à retenir : validez le certificat de votre serveur RADIUS sur chaque profil de demandeur, automatisez le renouvellement des certificats avant de déployer 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 MAC Authentication Bypass comme solution de repli. Pour en savoir plus sur la manière dont Purple s'intègre à votre architecture d'accès réseau, visitez purple dot ai. Merci pour votre écoute.