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 écoutez ceci, vous êtes probablement confronté à 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 tout simplement parce que vous venez d'hériter d'un réseau fonctionnant sur une clé PSK partagée et que vous savez que cela ne suffit plus. 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é formellement identifié et autorisé avant de pouvoir transmettre le moindre octet de trafic. Ce n'est pas facultatif pour les organisations qui gèrent des données de cartes de paiement sous PCI DSS, ce n'est pas facultatif pour les environnements de santé sous le GDPR et les normes de sécurité des données du NHS, et franchement, pour toute organisation exploitant plus d'une poignée de 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 de certificats et les scénarios réels où les choses se compliquent. C'est parti. [ANALYSE TECHNIQUE APPROFONDIE — environ 5 minutes] Très bien, l'architecture 802.1X repose donc sur trois composants. Vous avez le Supplicant — c'est l'appareil client, l'ordinateur portable, le téléphone, le capteur IoT. Vous avez l'Authentificateur — c'est votre point d'accès ou votre commutateur réseau, parfois appelé NAS (Network Access Server). Et vous avez le Serveur d'Authentification — presque systématiquement un serveur RADIUS dans les déploiements d'entreprise. Voici comment fonctionne la liaison (handshake). 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 (Extensible Authentication Protocol). Le point d'accès envoie une requête d'identité EAP (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 tout autre annuaire d'identité que vous avez configuré — puis renvoie soit un Access-Accept, soit un Access-Reject. Ce n'est que lors d'un Accept que le point d'accès ouvre le port de données complet et attribue l'appareil au VLAN approprié. À ce stade, la méthode EAP que vous choisissez revêt une importance capitale. Vous en rencontrerez principalement cinq 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 contrepartie est que vous devez disposer d'une PKI complète — une infrastructure à clés publiques — pour émettre et gérer les certificats clients. Cela implique une autorité de certification, la gestion du cycle de vie des certificats et un mécanisme pour déployer les certificats sur chaque appareil. Pour les organisations disposant de Microsoft Active Directory et d'Active Directory Certificate Services, cela est tout à fait réalisable. Pour les organisations qui ne disposent pas de cette infrastructure, cela représente un investissement important. 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 (nom d'utilisateur et mot de passe) à l'intérieur de ce tunnel. Elle est compatible par défaut avec la quasi-totalité des appareils, s'intègre directement avec Active Directory via NPS sur Windows Server et ne nécessite pas de certificats clients. Le compromis est qu'elle est vulnérable aux attaques de collecte d'identifiants si les utilisateurs sont incités à se connecter à un point d'accès pirate — car le client ne valide pas le certificat du serveur par défaut. Vous devez imposer la validation du certificat du serveur dans vos profils de demandeur (supplicant). EAP-TTLS est similaire à PEAP mais offre plus de flexibilité dans la méthode d'authentification interne. Elle est courante dans les environnements Linux et lorsque vous devez prendre en charge des backends d'authentification existants. EAP-FAST a été développé par Cisco en réponse aux faiblesses de LEAP. Elle utilise des identifiants d'accès protégés (PAC) plutôt que des certificats. Elle est principalement pertinente si vous évoluez dans un environnement fortement équipé en solutions Cisco ou si vous gérez des appareils existants qui ne peuvent pas prendre en charge les autres méthodes. EAP-SIM et EAP-AKA sont utilisées dans les déploiements de classe opérateur — comme OpenRoaming ou Passpoint — où l'authentification est liée à une carte SIM ou USIM. Ces méthodes sont de plus en plus pertinentes pour le WiFi des lieux publics où vous souhaitez un accueil fluide et sécurisé sans Captive Portal. Parlons maintenant de la configuration RADIUS. Que vous déployiez Microsoft NPS, FreeRADIUS, Cisco ISE ou Aruba ClearPass, les étapes de configuration de base sont les mêmes. Tout d'abord, 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é est utilisé pour authentifier les messages RADIUS entre le point d'accès et le serveur. Utilisez un minimum de 22 caractères, générés de manière aléatoire et uniques pour chaque appareil NAS. Ensuite, vous configurez votre politique réseau. C'est là que vous définissez qui accède à quoi. En termes NPS, vous créez une politique réseau qui correspond à des conditions — appartenance à un groupe dans Active Directory, type d'appareil, heure de la journée — et attribue des attributs — ID de VLAN, délai d'expiration de session, limites de bande passante. L'attribut RADIUS que vous utiliserez le plus est l'attribution de VLAN, plus précisément Tunnel-Type défini sur VLAN, Tunnel-Medium-Type défini sur 802 et Tunnel-Private-Group-ID défini sur 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 authentifier localement ou transférer vers un autre serveur RADIUS. Dans un déploiement distribué, vous pouvez 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 de serveur approuvé par vos clients. La voie la plus simple consiste à utiliser un certificat provenant d'une autorité de certification (CA) 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 CA interne, vous devez déployer le certificat racine sur tous les appareils clients via une stratégie de groupe (GPO) 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 inscription automatique via GPO 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é des points d'accès, la configuration est simple. Vous créez un nouveau SSID, définissez la sécurité sur WPA2-Enterprise ou WPA3-Enterprise, pointez le serveur d'authentification RADIUS vers l'IP de votre NPS sur le port UDP 1812, configurez le serveur de comptabilité (accounting) 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 d'AP d'entreprise — Cisco Meraki, Aruba, Ruckus, Extreme — disposent d'une interface graphique pour cela 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 blocage fréquents lors des déploiements, car c'est là que je justifie mes honoraires de consultant. Le point de défaillance le plus courant est la validation des certificats. J'ai vu des organisations déployer correctement PEAP-MSCHAPv2 côté serveur, puis laisser les profils de demandeurs (supplicants) 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 GPO ou MDM — doit spécifier la CA racine de confiance et le nom de serveur attendu. Sans cela, vous êtes vulnérable aux attaques de type « evil twin ». Le deuxième problème courant est la gestion du secret partagé 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 prestataires 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 laboratoire avant de le déployer 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 secondaire sur chaque point d'accès. Pour les déploiements à grande échelle, envisagez des clusters de proxy RADIUS avec surveillance de l'état de santé. Cinquièmement, et cela concerne spécifiquement les secteurs de l'hôtellerie et du commerce : la séparation entre réseau invité et réseau d'entreprise. Votre SSID d'entreprise 802.1X et votre SSID WiFi invité doivent être complètement séparés — VLAN différents, politiques de pare-feu différentes, DNS différents. Une plateforme comme Purple gère la partie invité avec son propre Captive Portal et son outil d'analyse, 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 exécuter le protocole 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 gèrent le proxying 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'API REST. Cependant, l'intégration d'AD via NPS reste 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 (MAC Authentication Bypass) — comme solution de repli. 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 les 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 authentification 802.1X. Il apporte 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 option facultative. Pour toute organisation qui manipule des données sensibles, traite des paiements ou opère dans un environnement réglementé, c'est la base de la sécurité WiFi d'entreprise. L'architecture est éprouvée, les outils sont matures et la méthode de déploiement est claire. Commencez par choisir votre méthode EAP — PEAP-MSCHAPv2 si vous recherchez un déploiement rapide et une large compatibilité, 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 (supplicants) via une stratégie de groupe ou un MDM avant la mise en service. Et séparez complètement votre WiFi invité — 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 pour votre écoute. Le guide écrit complet, les diagrammes 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.