Comment implémenter l'authentification 802.1X avec Cloud RADIUS

Comment implémenter l'authentification 802.1X avec Cloud RADIUS Un briefing d'information Purple WiFi --- INTRODUCTION ET CONTEXTE (environ 1 minute) --- Bienvenue dans ce briefing d'information Purple WiFi. Je suis votre hôte, et aujourd'hui nous allons entrer dans les détails de l'authentification 802.1X avec Cloud RADIUS — ce que c'est, pourquoi c'est crucial aujourd'hui, et comment la déployer concrètement sur un parc multi-sites. Si vous gérez l'infrastructure WiFi d'un groupe hôtelier, d'une chaîne de magasins, d'un stade ou d'une organisation du secteur public, c'est un sujet qui revient constamment — et pour cause. Le paysage des menaces a évolué. Les réseaux à clé partagée (PSK) sont de plus en plus perçus comme un risque de non-conformité, et plus seulement comme un inconvénient de sécurité. Les régulateurs, les auditeurs et les cyber-assureurs posent tous des questions plus strictes sur le contrôle d'accès au réseau. La bonne nouvelle, c'est que le RADIUS basé sur le cloud a rendu le 802.1X véritablement déployable à grande échelle, sans la lourdeur de l'infrastructure sur site qui le rendait auparavant inapplicable pour les parcs distribués. Alors, entrons dans le vif du sujet. --- ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) --- Tout d'abord, assurons-nous que nous partageons tous la même définition. La norme IEEE 802.1X est un standard de contrôle d'accès réseau basé sur les ports. Elle définit un cadre d'authentification qui se situe à la couche 2 du modèle OSI — elle fonctionne donc avant même qu'un appareil ne reçoive la moindre connectivité IP. C'est la distinction clé par rapport à l'authentification au niveau de la couche applicative. Avec le 802.1X, un appareil ne peut pas accéder au réseau tant qu'il n'a pas été formellement authentifié. Le protocole comporte trois composants. Le suppliant (supplicant) — c'est l'appareil final, qu'il s'agisse d'un ordinateur portable, d'un smartphone ou d'un terminal de point de vente. L'authentificateur — généralement votre point d'accès WiFi ou votre commutateur managé. Et le serveur d'authentification — qui, dans les déploiements modernes, est votre service cloud RADIUS. Le flux fonctionne de la manière suivante. Un appareil tente de s'associer à un point d'accès. Le point d'accès n'accorde pas immédiatement un accès complet au réseau. À la place, il ouvre un port contrôlé et lance un échange EAP — le protocole d'authentification extensible (Extensible Authentication Protocol) — avec l'appareil. L'appareil présente ses identifiants, qui peuvent être un nom d'utilisateur et un mot de passe, un certificat numérique ou une identité basée sur une carte SIM. Le point d'accès transmet cet échange au serveur RADIUS en utilisant le protocole RADIUS via UDP, généralement sur le port 1812 pour l'authentification et 1813 pour la comptabilisation (accounting). Le serveur RADIUS valide les identifiants par rapport à un annuaire d'identités — Active Directory, Azure AD ou un annuaire LDAP — et renvoie un message Access-Accept ou Access-Reject. S'il est accepté, le point d'accès ouvre le port et l'appareil accède au réseau. S'il est rejeté, il reste bloqué. Simple en principe, mais les détails de mise en œuvre sont d'une importance capitale. C'est d'ailleurs sur le choix de la méthode EAP que de nombreux déploiements échouent. Plusieurs méthodes EAP sont couramment utilisées, et elles présentent des profils de sécurité et des exigences opérationnelles très différents. EAP-TLS est la référence absolue. Il nécessite une authentification mutuelle par certificat — le serveur et le client présentent tous deux un certificat. Cela élimine totalement le risque de vol d'identifiants, car il n'y a pas de mots de passe à dérober. Cependant, cela requiert une infrastructure PKI et un mécanisme pour déployer les certificats clients sur les appareils, ce qui implique généralement une solution MDM. Pour les environnements BYOD d'entreprise et les déploiements à haute sécurité, c'est la réponse idéale. PEAP avec MSCHAPv2 est la méthode la plus largement déployée dans les environnements d'entreprise. Elle ne nécessite qu'un certificat côté serveur et tunnelise l'échange d'identifiants au sein de TLS. Elle est nativement compatible avec Active Directory, ce qui la rend simple à exploiter. Le risque est qu'elle est vulnérable à la collecte d'identifiants si les utilisateurs se connectent à un point d'accès pirate doté d'un certificat auto-signé — la validation du certificat côté client est donc non négociable. EAP-TTLS est similaire à PEAP mais offre plus de flexibilité dans la méthode d'authentification interne. Il est particulièrement utile dans les environnements d'appareils mixtes où cohabitent des appareils Windows, macOS, iOS et Android avec des capacités de demandeur (supplicant) variables. Pour la prise en charge des appareils existants — comme le matériel de point de vente plus ancien ou les capteurs IoT — EAP-FAST peut être un choix pragmatique, car il ne nécessite pas de certificats et utilise à la place un identifiant d'accès protégé (PAC). Abordons maintenant la partie RADIUS cloud. Traditionnellement, RADIUS était un service sur site — FreeRADIUS sur un serveur Linux, ou Microsoft NPS sur Windows Server. Ce modèle fonctionne, mais il engendre de réels coûts opérationnels : maintenance du matériel, configuration de la haute disponibilité, correctifs et nécessité d'une infrastructure locale sur chaque site nécessitant une authentification à faible latence. Le RADIUS cloud change considérablement la donne. Un service RADIUS cloud est hébergé et géré par le fournisseur. Vos points d'accès envoient des requêtes RADIUS via Internet au service cloud, qui gère l'authentification auprès de votre fournisseur d'identité. La question de la latence est réelle mais gérable — les services RADIUS cloud modernes sont distribués à l'échelle mondiale, et les cycles d'authentification se terminent généralement en moins de 100 millisecondes, ce qui est imperceptible pour les utilisateurs finaux. L'intégration avec les fournisseurs d'identité est la dépendance critique. La plupart des plateformes RADIUS cloud prennent en charge LDAP, LDAPS, SAML 2.0, ainsi que l'intégration directe avec Azure AD ou Okta. Pour les organisations qui utilisent déjà Microsoft 365, l'intégration d'Azure AD est la voie naturelle — vous bénéficiez de l'authentification unique, des politiques d'accès conditionnel et de l'application du MFA, le tout alimentant votre couche de contrôle d'accès au réseau. Pour les établissements déployant un WiFi invité aux côtés des réseaux du personnel, l'architecture sépare généralement ces derniers en SSIDs distincts avec des politiques d'authentification différentes. Les réseaux du personnel utilisent le 802.1X avec des identifiants d'entreprise. Les réseaux invités utilisent un Captive Portal ou un flux de connexion sociale. La plateforme de Purple prend en charge ces deux modèles, et la couche d'analyse WiFi se superpose aux deux, vous offrant une visibilité sur le comportement des appareils, le temps de séjour et l'utilisation du réseau sans compromettre la segmentation de la sécurité. --- RECOMMANDATIONS D'IMPLÉMENTATION ET PIÈGES À ÉVITER (environ 2 minutes) --- Laissez-moi vous présenter la séquence de déploiement pratique et vous signaler les modes de défaillance que je rencontre le plus souvent. Commencez par l'intégration de votre fournisseur d'identité. Avant de toucher à un seul point d'accès, confirmez que votre service RADIUS cloud peut s'authentifier auprès de votre annuaire. Testez avec un compte de service, validez la liaison LDAP et confirmez que les attributs d'appartenance aux groupes sont correctement renvoyés — car vous en aurez besoin pour les politiques d'attribution de VLAN. Deuxièmement, planifiez votre stratégie de certificats. Si vous optez pour l'EAP-TLS, vous avez besoin d'une autorité de certification (CA), vous devez décider si vous utilisez une CA publique ou interne, et vous avez besoin d'un plan de déploiement MDM pour les certificats clients. Si vous optez pour le PEAP, vous avez besoin d'un certificat de serveur provenant d'une CA de confiance — pas auto-signé — et vous devez déployer le certificat de la CA sur tous les appareils clients afin que la validation du certificat fonctionne correctement. C'est l'étape qui est souvent ignorée et qui provoque des incidents de sécurité. Troisièmement, configurez vos clients RADIUS — c'est-à-dire vos points d'accès et contrôleurs — avec le secret partagé correct et l'IP ou le nom d'hôte du serveur. Utilisez un secret partagé fort, généré de manière aléatoire, et non un mot du dictionnaire. Et si votre fournisseur RADIUS cloud prend en charge le RADIUS sur TLS — RadSec —, utilisez-le. Il chiffre le trafic RADIUS en transit, ce qui est particulièrement important lorsque ce trafic traverse l'internet public. Quatrièmement, testez avec un groupe pilote avant le déploiement complet. Les échecs d'authentification à grande échelle sont perturbateurs et difficiles à diagnostiquer sous pression. Menez un projet pilote avec dix à vingt appareils, validez les journaux d'authentification, confirmez que l'attribution des VLAN fonctionne et vérifiez que les enregistrements de comptabilité sont correctement rédigés. Les modes de défaillance que je vois le plus souvent : la validation des certificats désactivée sur les clients, entraînant une vulnérabilité de type "man-in-the-middle" (homme du milieu). Des secrets partagés trop courts ou réutilisés sur plusieurs sites. La liste d'autorisation des IP des serveurs RADIUS non configurée, de sorte que les demandes d'authentification des nouveaux sites sont rejetées silencieusement. Et des profils MDM non mis à jour à l'expiration des certificats, provoquant des échecs d'authentification massifs le jour du renouvellement. --- QUESTIONS-RÉPONSES RAPIDES (environ 1 minute) --- Quelques questions que l'on me pose régulièrement. Puis-je exécuter le 802.1X sur un réseau qui comporte également des appareils IoT ne prenant pas en charge l'EAP ? Oui — utilisez le MAC Authentication Bypass comme solution de repli pour les appareils qui ne peuvent pas exécuter de demandeur (supplicant), mais placez ces appareils sur un VLAN restreint avec des règles de pare-feu strictes. Le protocole 802.1X remplace-t-il le chiffrement WPA2 ou WPA3 ? Non — le 802.1X gère l'authentification. Le WPA2-Enterprise ou le WPA3-Enterprise gère le chiffrement. Vous avez besoin des deux. Le WPA3-Enterprise avec 802.1X est actuellement la meilleure pratique pour les nouveaux déploiements. Quel est l'impact de la latence sur l'authentification ? Avec un service RADIUS cloud bien configuré, comptez entre 50 et 150 millisecondes par authentification. Pour les scénarios d'itinérance, la transition BSS rapide 802.11r peut réduire considérablement la surcharge de réauthentification. Est-ce conforme à la norme PCI DSS ? Le 802.1X avec EAP-TLS ou PEAP sur un réseau correctement segmenté répond aux exigences 1 et 8 de la norme PCI DSS pour le contrôle d'accès au réseau. Impliquez votre QSA dès le départ. --- RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) --- Pour résumer : le 802.1X avec RADIUS cloud est la solution idéale pour toute entreprise qui doit démontrer le contrôle d'accès au réseau aux auditeurs, réduire la surface d'attaque en cas de compromission d'identifiants, ou gérer l'authentification de manière centralisée sur un parc distribué. Le déploiement n'est pas anodin, mais il est tout à fait gérable avec une bonne préparation. Réussissez d'abord l'intégration de votre fournisseur d'identité. Choisissez votre méthode EAP en fonction de votre parc d'appareils et de votre capacité opérationnelle à gérer les certificats. Utilisez RadSec si votre infrastructure le prend en charge. Et testez avant de déployer à grande échelle. Si vous gérez un réseau mixte pour les invités et le personnel — ce qui est le cas de la plupart des opérateurs de l'hôtellerie et du commerce de détail — des plateformes comme Purple vous permettent de gérer les deux modèles d'authentification à partir d'une interface unique, avec une couche d'analyse couvrant l'ensemble du parc. Pour vos prochaines étapes : auditez votre posture actuelle en matière de contrôle d'accès au réseau, identifiez les sites qui utilisent encore des clés PSK partagées, et établissez un plan de migration progressif. Commencez par vos sites les plus exposés — ceux concernés par la norme PCI DSS ou ceux qui traitent des données sensibles — et étendez la démarche. Merci pour votre écoute. D'autres fiches techniques sont disponibles sur purple.ai.