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 nous allons aujourd'hui aborder en détail l'authentification 802.1X avec Cloud RADIUS - ce que c'est, pourquoi c'est essentiel 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'un organisme du secteur public, c'est l'un de ces sujets qui revient constamment, et pour de bonnes raisons. Le paysage des menaces a évolué. Les réseaux à clé PSK partagée sont de plus en plus considérés comme un risque de non-conformité, et non plus seulement comme un inconvénient de sécurité. Les régulateurs, les auditeurs et les cyber-assureurs posent tous des questions de plus en plus pointues sur le contrôle d'accès au réseau. La bonne nouvelle est que le RADIUS fourni via le cloud a rendu le 802.1X véritablement déployable à grande échelle, sans les coûts d'infrastructure sur site qui le rendaient auparavant inapplicable pour les parcs distribués. Entrons donc dans le vif du sujet. --- ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) --- Tout d'abord, assurons-nous que nous partageons la même définition. La norme IEEE 802.1X est une norme de contrôle d'accès réseau basée sur les ports. Elle définit un cadre d'authentification qui se situe au niveau de la couche 2 du modèle OSI - elle intervient donc avant même qu'un appareil ne bénéficie de la moindre connectivité IP. C'est la distinction clé par rapport à l'authentification au niveau applicatif. 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 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, correspond à 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 - 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 relaye 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. 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 obtient l'accès au réseau. S'il est rejeté, il reste bloqué. Le principe est simple, mais les détails d'implémentation sont extrêmement importants. C'est précisément sur le choix de la méthode EAP que de nombreux déploiements échouent. Il existe plusieurs méthodes EAP 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. Elle nécessite une authentification mutuelle par certificat - le serveur et le client présentent tous deux un certificat. Cela élimine entièrement le risque de vol d'identifiants, car il n'y a pas de mots de passe à dérober. Cependant, elle 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 solution 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 à gérer sur le plan opérationnel. Le risque est qu'elle est vulnérable à la collecte d'identifiants si les utilisateurs se connectent à un point d'accès malveillant avec 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. Elle est particulièrement utile dans les environnements d'appareils mixtes où vous disposez d'une combinaison d'appareils Windows, macOS, iOS et Android avec des capacités de demandeur 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 elle ne nécessite pas de certificats et utilise à la place un identifiant d'accès protégé (Protected Access Credential). À présent, parlons de la partie RADIUS dans le 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 requérant une authentification à faible latence. Le RADIUS dans le cloud change considérablement la donne. Un service RADIUS dans le 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é. Le problème de la latence est réel mais gérable - les services RADIUS dans le 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 dans le cloud prennent en charge LDAP, LDAPS, SAML 2.0 et l'intégration directe avec Azure AD ou Okta. Pour les organisations qui utilisent déjà Microsoft 365, l'intégration Azure AD est la voie naturelle - vous bénéficiez de l'authentification unique, des politiques d'accès conditionnel et de l'application de la MFA, le tout alimentant votre couche de contrôle d'accès au réseau. Pour les établissements qui déploient un WiFi invité parallèlement aux 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 802.1X avec des identifiants d'entreprise. Les réseaux invités utilisent un Captive Portal ou un flux de connexion via les réseaux sociaux. La plateforme de Purple prend en charge les deux modèles, et la couche d'analyse WiFi s'applique 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 DE MISE EN ŒUVRE 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 constate 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-as-a-Service dans le 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 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 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 - à savoir vos points d'accès et contrôleurs - avec le secret partagé correct et l'adresse 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 dans le cloud prend en charge 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, effectuez des tests avec un groupe pilote avant le déploiement complet. Les échecs d'authentification à grande échelle sont perturbants 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 écrits. Les modes de défaillance que je vois le plus souvent : la validation des certificats désactivée sur les clients, ce qui entraîne 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 adresses IP des serveurs RADIUS non configurée, de sorte que les demandes d'authentification des nouveaux sites sont rejetées silencieusement. Et les profils MDM qui ne sont pas mis à jour à l'expiration des certificats, ce qui provoque 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 802.1X sur un réseau qui contient également des appareils IoT qui ne prennent pas en charge EAP ? Oui - utilisez le contournement de l'authentification MAC (MAB) 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. Est-ce que le 802.1X remplace le chiffrement WPA2 ou WPA3 ? Non - le 802.1X gère l'authentification. Le WPA2-Enterprise ou WPA3-Enterprise gère le chiffrement. Vous avez besoin des deux. Le WPA3-Enterprise avec 802.1X est la meilleure pratique actuelle pour les nouveaux déploiements. Quel est l'impact de la latence sur l'authentification ? Avec un service cloud RADIUS bien configuré, prévoyez de 50 à 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ébut. --- RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) --- Pour résumer : le 802.1X avec cloud RADIUS est la solution idéale pour toute organisation qui doit démontrer un contrôle d'accès au réseau à des auditeurs, réduire la zone d'impact d'une 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 la 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 aux risques - ceux qui entrent dans le champ d'application de la norme PCI-DSS ou qui traitent des données sensibles - et progressez vers l'extérieur. Merci pour votre écoute. D'autres présentations techniques sont disponibles sur purple.ai.