Comment configurer l'authentification WiFi 802.1X : un guide étape par étape

Comment configurer l'authentification WiFi 802.1X : un guide étape par étape Un podcast Purple Enterprise WiFi Intelligence [INTRODUCTION - environ 1 minute] Bienvenue. Je m'exprime aujourd'hui en tant qu'architecte de solutions senior, et si vous m'écoutez, vous êtes probablement face à un projet de sécurité réseau qui implique l'authentification 802.1X - soit parce que votre équipe de conformité l'a signalé, soit parce que votre assureur l'a demandé, ou encore parce que vous venez d'hériter d'un réseau fonctionnant avec une clé partagée PSK et que vous savez que ce n'est plus suffisant. Alors, entrons directement dans le vif du sujet. Le 802.1X est la norme IEEE pour le contrôle d'accès réseau basé sur les ports. C'est la colonne vertébrale de la sécurité WiFi d'entreprise - le mécanisme qui garantit que chaque appareil se connectant à votre réseau a été positivement identifié et autorisé avant de pouvoir transmettre le moindre octet de trafic. Ce n'est pas optionnel pour les organisations qui gèrent des données de cartes de paiement sous PCI-DSS, ce n'est pas optionnel pour les environnements de santé sous GDPR, et franchement, pour toute organisation exploitant plus de quelques points d'accès, c'est l'architecture qui s'impose. Au cours des dix prochaines minutes, je vais vous guider à travers l'architecture technique, la configuration RADIUS, le déploiement des certificats et les scénarios réels où les choses se compliquent. C'est parti. [ZOOM TECHNIQUE - environ 5 minutes] Très bien, le framework 802.1X comporte donc trois composants. Vous avez le Supplicant - c'est l'appareil client, l'ordinateur portable, le téléphone, le capteur IoT. Vous avez l'Authenticator - c'est votre point d'accès ou votre commutateur réseau, parfois appelé le NAS, le Network Access Server. Et vous avez le serveur d'authentification - presque universellement un serveur RADIUS dans les déploiements d'entreprise. Voici comment fonctionne la liaison. Lorsqu'un appareil tente de se connecter à un SSID protégé par 802.1X, le point d'accès ne le laisse pas simplement entrer. À la place, il ouvre ce que l'on appelle un port contrôlé - un canal limité qui ne laisse passer que le trafic EAP, le protocole d'authentification extensible. Le point d'accès envoie une requête EAP-Request Identity à l'appareil. L'appareil répond avec son identité. Le point d'accès transmet ensuite cette information au serveur RADIUS, encapsulée dans un paquet RADIUS Access-Request. Le serveur RADIUS procède à l'authentification - en vérifiant les identifiants par rapport à Active Directory, un magasin de certificats ou toute autre base d'identité que vous avez configurée - et renvoie soit un Access-Accept, soit un Access-Reject. C'est seulement en cas d'Accept que le point d'accès ouvre le port de données complet et attribue l'appareil au VLAN approprié. À présent, la méthode EAP que vous choisissez ici a une importance considérable. Il y en a cinq que vous rencontrerez dans les déploiements d'entreprise. EAP-TLS est la référence absolue. Le client et le serveur présentent tous deux des certificats X.509. Aucun mot de passe n'est requis. C'est l'option la plus sécurisée et celle exigée pour les niveaux de conformité PCI-DSS les plus élevés. La seule contrainte est qu'une infrastructure PKI complète - Public Key Infrastructure - est indispensable pour émettre et gérer les certificats clients. Cela implique une autorité de certification, une gestion du cycle de vie des certificats et un mécanisme de déploiement des certificats sur chaque appareil. Pour les organisations disposant de Microsoft Active Directory et d'Active Directory Certificate Services, cette configuration est très accessible. Pour celles qui ne possèdent pas cette infrastructure, cela représente un investissement significatif. PEAP-MSCHAPv2 est la méthode la plus largement déployée en pratique. Elle crée un tunnel TLS en utilisant uniquement un certificat côté serveur, puis transmet les identifiants de connexion (nom d'utilisateur et mot de passe) au sein de ce tunnel. Elle est compatible par défaut avec la quasi-totalité des appareils, s'intègre directement à Active Directory via NPS sur Windows Server, et ne requiert aucun certificat client. En contrepartie, elle est vulnérable aux attaques de collecte d'identifiants si les utilisateurs sont incités à se connecter à un point d'accès malveillant - car le client ne valide pas le certificat du serveur par défaut. Vous devez impérativement imposer la validation du certificat serveur dans vos profils de suppliant. EAP-TTLS est similaire à PEAP mais offre plus de flexibilité pour la méthode d'authentification interne. Elle est couramment utilisée dans les environnements Linux et lorsqu'il est nécessaire de prendre en charge des serveurs d'authentification existants. EAP-FAST a été développé par Cisco pour pallier les faiblesses de LEAP. Cette méthode utilise des identifiants d'accès protégés (Protected Access Credentials) plutôt que des certificats. Elle est principalement pertinente si vous évoluez dans un environnement majoritairement équipé en équipements Cisco ou si vous gérez des appareils plus anciens qui ne supportent pas les autres méthodes. EAP-SIM et EAP-AKA sont utilisés dans les déploiements de classe opérateur - comme OpenRoaming ou Passpoint - où l'authentification est liée à une carte SIM ou USIM. Ces solutions sont de plus en plus pertinentes pour le WiFi public dans les grands espaces accueillant du public, afin d'offrir une connexion sécurisée et transparente sans Captive Portal. Abordons maintenant la configuration RADIUS. Que vous déployiez Microsoft NPS, FreeRADIUS, Cisco ISE ou Aruba ClearPass, les étapes de configuration fondamentales restent identiques. Premièrement, vous définissez vos clients RADIUS - il s'agit de vos points d'accès ou de vos contrôleurs LAN sans fil. Chaque client est enregistré avec son adresse IP et un secret partagé. Ce secret partagé sert à authentifier les messages RADIUS échangés entre le point d'accès et le serveur. Utilisez une longueur minimale de 22 caractères, générés de manière aléatoire et uniques pour chaque équipement NAS. Deuxièmement, vous configurez votre politique réseau. C'est ici que vous définissez les droits d'accès. Avec NPS, vous créez une politique réseau correspondant à des conditions - appartenance à un groupe dans Active Directory, type d'appareil, heure de connexion - et attribuez des attributs - identifiant VLAN, délai d'expiration de session, limites de bande passante. L'attribut RADIUS le plus utilisé est l'attribution de VLAN, spécifiquement le Tunnel-Type configuré sur VLAN, le Tunnel-Medium-Type sur 802, et le Tunnel-Private-Group-ID configuré avec votre numéro de VLAN. Troisièmement, vous configurez votre stratégie de demande de connexion. Cela indique à NPS comment gérer les requêtes RADIUS entrantes - s'il faut les authentifier localement ou les transférer vers un autre serveur RADIUS. Dans un déploiement distribué, vous pourriez avoir un serveur RADIUS central avec des proxys NPS sur chaque site. Du côté des certificats, pour PEAP et EAP-TLS, votre serveur RADIUS a besoin d'un certificat serveur approuvé par vos clients. La voie la plus simple consiste à utiliser un certificat provenant d'une autorité de certification publique - DigiCert, Sectigo, Let's Encrypt - car ces certificats racines sont déjà approuvés par tous les principaux systèmes d'exploitation. Si vous utilisez une autorité de certification interne, vous devez déployer le certificat racine sur tous les appareils clients via une stratégie de groupe ou votre plateforme MDM. Pour EAP-TLS spécifiquement, vous avez également besoin de certificats clients. Dans un environnement Active Directory, vous utiliseriez ADCS avec une inscription automatique via une stratégie de groupe pour déployer les certificats sur les appareils joints au domaine. Pour les appareils BYOD, vous utiliseriez votre MDM - Intune, Jamf, VMware Workspace ONE - pour déployer à la fois le certificat et le profil WiFi. Du côté du point d'accès, la configuration est simple. Vous créez un nouveau SSID, configurez la sécurité sur WPA2-Enterprise ou WPA3-Enterprise, pointez le serveur d'authentification RADIUS vers l'adresse IP de votre NPS sur le port UDP 1812, configurez le serveur de comptabilité RADIUS sur le port UDP 1813, saisissez le secret partagé et activez l'attribution dynamique de VLAN si vous l'utilisez. La plupart des plateformes de points d'accès d'entreprise - Cisco Meraki, Aruba, Ruckus, Extreme Networks - disposent d'une interface graphique pour cela, ce qui prend environ dix minutes une fois que votre serveur RADIUS est prêt. [RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER - environ 2 minutes] Très bien, parlons des points de friction dans les déploiements, car c'est là que je justifie mes honoraires de consultant. Le point de défaillance le plus courant est la validation du certificat. J'ai vu des organisations déployer correctement PEAP-MSCHAPv2 côté serveur, puis laisser les profils des demandeurs clients configurés pour accepter n'importe quel certificat. Cela compromet totalement le modèle de sécurité. Chaque profil de demandeur - qu'il soit déployé via une stratégie de groupe ou un MDM - doit spécifier l'autorité de certification racine de confiance et le nom de serveur attendu. Sans cela, vous êtes vulnérable aux attaques de type jumeau maléfique. Le deuxième problème courant est la gestion des secrets partagés RADIUS. J'ai vu des réseaux de production fonctionner avec un secret partagé configuré sur "radius" ou sur la valeur par défaut du fournisseur. Ces secrets sont les clés de votre infrastructure d'authentification. Générez-les de manière aléatoire, stockez-les dans un gestionnaire de secrets et renouvelez-les régulièrement. Troisièmement : la mauvaise configuration des VLAN. L'attribution dynamique de VLAN est puissante - elle vous permet de placer les appareils du personnel sur le VLAN de l'entreprise, les sous-traitants sur un VLAN restreint et les appareils IoT sur un VLAN isolé, le tout à partir du même SSID. Mais si les attributs RADIUS ne sont pas configurés correctement, ou si les ports trunk des commutateurs ne transportent pas les bons VLAN, les appareils ne parviendront pas à se connecter ou se retrouveront sur le mauvais segment. Testez cela rigoureusement dans un environnement de test avant de passer en production. Quatrièmement : la redondance. Votre serveur RADIUS est désormais un élément critique de votre infrastructure. S'il tombe en panne, plus personne ne se connecte. Vous devez configurer au minimum un serveur RADIUS principal et un serveur RADIUS secondaire sur chaque point d'accès. Pour les grands déploiements, envisagez des clusters de proxys RADIUS avec surveillance de l'état de santé. Cinquièmement, et cela s'applique spécifiquement aux environnements de l'hôtellerie et du commerce : la séparation entre invités et entreprise. Votre SSID d'entreprise 802.1X et votre SSID de guest WiFi doivent être complètement séparés - différents VLANs, différentes règles de pare-feu, différents DNS. Une plateforme comme Purple gère la partie invités avec son propre Captive Portal et sa couche analytique, tandis que votre infrastructure 802.1X gère la partie entreprise. Ce sont des systèmes complémentaires et non concurrents. [QUESTIONS-RÉPONSES RAPIDES - environ 1 minute] Passons en revue les questions que l'on me pose le plus souvent. Puis-je utiliser le 802.1X sur une plateforme de points d'accès gérée dans le cloud ? Oui - Meraki, Aruba Central et Ruckus Cloud le prennent tous en charge. Vous configurez les détails du serveur RADIUS dans le tableau de bord cloud, et les points d'accès se chargent du proxy EAP. Ai-je besoin d'Active Directory ? Non. FreeRADIUS peut s'authentifier auprès d'un annuaire LDAP, de bases de données SQL, de fichiers plats ou même d'APIs REST. Mais l'intégration AD via NPS est de loin la méthode d'entreprise la plus courante. Qu'en est-il des appareils IoT qui ne prennent pas en charge le 802.1X ? Utilisez le contournement d'authentification MAC - MAB - comme solution de secours. L'adresse MAC de l'appareil est envoyée au serveur RADIUS en guise d'identifiant et de mot de passe. Ce n'est pas aussi sécurisé que l'EAP, mais cela vous permet d'intégrer des appareils IoT tout en les maintenant dans un VLAN restreint. Le 802.1X fonctionne-t-il avec le WPA3 ? Oui. Le WPA3-Enterprise est essentiellement du WPA3 avec une authentification 802.1X. Il ajoute un chiffrement plus fort - 192 bits en mode haute sécurité - et constitue la norme recommandée pour les nouveaux déploiements. [RÉSUMÉ ET PROCHAINES ÉTAPES - environ 1 minute] En résumé : le 802.1X n'est pas une simple option. Pour toute organisation qui gère des données sensibles, traite des paiements ou opère dans un environnement réglementé, c'est la base de la sécurité du WiFi d'entreprise. L'architecture est bien établie, les outils sont matures et la méthode de déploiement est claire. Commencez par choisir votre méthode EAP - PEAP-MSCHAPv2 si vous avez besoin de résultats rapides et d'une large compatibilité, ou EAP-TLS si vous disposez de l'infrastructure PKI et avez besoin du niveau de sécurité le plus élevé. Configurez votre serveur RADIUS et sa redondance avant de toucher au moindre point d'accès. Déployez vos profils de demandeurs via une stratégie de groupe ou un MDM avant la mise en service. Et séparez complètement votre guest WiFi - utilisez une plateforme dédiée pour cette couche. Si vous gérez un environnement multisite - hôtels, chaînes de magasins, stades - la complexité augmente avec le nombre de sites, mais l'architecture reste la même. La clé réside dans un serveur RADIUS centralisé avec une redondance locale par site, et un profil de demandeur cohérent déployé par MDM sur l'ensemble de votre parc d'appareils. Merci de nous avoir écoutés. Le guide écrit complet, les schémas d'architecture et les listes de contrôle de configuration sont disponibles sur purple.ai. Si vous planifiez un déploiement 802.1X et souhaitez discuter des spécificités de votre environnement, contactez directement l'équipe Purple.