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 de Purple Enterprise WiFi Intelligence [INTRODUCTION — environ 1 minute] Bienvenue. Je m'adresse à vous aujourd'hui en tant qu'architecte de solutions senior. 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 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 n'est plus suffisant. Entrons donc 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 l'épine dorsale 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 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 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 la bonne architecture. Au cours des dix prochaines minutes, je vais vous présenter 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. [PLONGÉE TECHNIQUE DEEP-DIVE — 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'Authentificateur - 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 le 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. Au lieu de cela, il ouvre ce qu'on appelle un port contrôlé - un canal limité qui ne transmet que le trafic EAP, le protocole d'authentification extensible. L'AP envoie une requête EAP-Request Identity à l'appareil. L'appareil répond avec son identité. L'AP transmet ensuite cette information au serveur RADIUS, encapsulée dans un paquet RADIUS Access-Request. Le serveur RADIUS exécute l'authentification - en vérifiant les identifiants par rapport à Active Directory, un magasin de certificats ou tout autre backend d'identité que vous avez configuré - et renvoie soit un Access-Accept, soit un Access-Reject. Ce n'est que lors d'un Accept que l'AP ouvre le port de données complet et attribue l'appareil au VLAN approprié. Maintenant, la méthode EAP que vous choisissez ici est extrêmement importante. 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 contrepartie est que vous avez besoin 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, c'est très accessible. Pour les organisations ne disposant 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 de connexion (nom d'utilisateur et mot de passe) à l'intérieur de ce tunnel. Elle est compatible avec pratiquement tous les appareils dès leur sortie de l'emballage, s'intègre directement avec Active Directory via NPS sur Windows Server, et ne requiert 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 malveillant - car le client ne valide pas le certificat du serveur par défaut. Vous devez appliquer la validation du certificat du serveur dans vos profils de demandeur. EAP-TTLS est similaire à PEAP mais plus flexible quant à la méthode d'authentification interne. Elle est courante dans les environnements Linux et lorsque vous devez prendre en charge des systèmes d'authentification hérités. 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 plutôt que des certificats. Elle est principalement pertinente si vous êtes dans un environnement fortement équipé en matériel Cisco ou si vous gérez des appareils hérités 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. Celles-ci sont de plus en plus pertinentes pour le WiFi des lieux publics où vous souhaitez une intégration fluide et sécurisée 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. Premièrement, vous définissez vos clients RADIUS - il s'agit de vos points d'accès ou 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. Deuxièmement, vous configurez votre politique réseau. C'est ici que vous définissez qui a accès à quoi. En termes de 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 la session, limites de bande passante. L'attribut RADIUS que vous utiliserez le plus est l'attribution de VLAN, spécifiquement 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 les authentifier localement ou les 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 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 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é 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, définissez 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 - 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 friction lors des déploiements, car c'est là que je gagne 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 du côté serveur, puis laisser les profils de 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 "evil twin". 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é défini 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 d'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 de manière approfondie dans un 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 peut se connecter. Vous devez configurer au minimum un serveur RADIUS principal et un secondaire sur chaque point d'accès. Dans les grands déploiements, envisagez des clusters de proxys RADIUS avec surveillance de l'état. Cinquièmement, et c'est spécifique 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 WiFi invité doivent être complètement séparés - différents VLANs, différentes politiques de pare-feu, différents DNS. Une plateforme comme Purple gère la partie invitée 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. [Q&A RAPIDE - environ 1 minute] Passons en revue les questions que l'on me pose le plus souvent. Puis-je exécuter 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 de serveurs LDAP, de bases de données SQL, de fichiers plats ou même d'APIs. Mais l'intégration d'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 802.1X ? Utilisez le contournement de l'authentification MAC - MAB (MAC Authentication Bypass) - 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 WPA3 ? Oui. WPA3-Enterprise est essentiellement le WPA3 avec 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] Pour résumer : 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 secteur réglementé, c'est le socle de base de la sécurité 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 d'une mise en œuvre rapide et d'une large compatibilité, ou EAP-TLS si vous disposez d'une infrastructure PKI et avez besoin du niveau de sécurité le plus élevé. Configurez et rendez votre serveur RADIUS redondant avant de toucher au moindre point d'accès. Déployez vos profils de demandeurs via une stratégie de groupe ou un outil de 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 déployé de manière uniforme via MDM sur l'ensemble de votre parc d'appareils. Merci pour votre écoute. 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.