Authentification WiFi par certificat : Comment les certificats numériques sécurisent les réseaux sans fil

Authentification WiFi par certificat : comment les certificats numériques sécurisent les réseaux sans fil. Un briefing technique de Purple. Introduction et contexte. Bienvenue dans la série des briefings techniques de Purple. Je suis votre hôte, et aujourd'hui nous abordons l'un des sujets les plus importants - et fréquemment mal compris - de la sécurité des réseaux d'entreprise : l'authentification WiFi par certificat. Si vous gérez un groupe hôtelier, une chaîne de vente au détail, un centre de congrès ou toute organisation où le personnel et les clients se connectent à votre infrastructure sans fil, ce briefing est directement pertinent pour votre posture de sécurité actuelle. Laissez-moi planter le décor. L'approche traditionnelle pour sécuriser le WiFi d'entreprise a été d'utiliser une clé pré-partagée - un mot de passe que tout le monde connaît, qui est écrit sur des tableaux blancs, partagé dans des canaux Slack et, franchement, ne change jamais parce que le modifier signifierait mettre à jour chaque appareil du parc. Ce modèle est dépassé. Il l'a toujours été. L'authentification basée sur les certificats est la méthode utilisée par les réseaux d'entreprise sérieux depuis plus d'une décennie, et si vous n'avez pas encore fait la transition, ce briefing vous donnera la clarté nécessaire pour prendre cette décision. Alors, qu'est-ce que l'authentification WiFi par certificat exactement, pourquoi est-elle importante et comment la déployer concrètement ? Entrons dans le vif du sujet. Analyse technique approfondie. Commençons par les fondamentaux. Un certificat numérique, dans le contexte de l'authentification WiFi, est un identifiant numérique X.509 - essentiellement un document signé cryptographiquement qui prouve l'identité d'un appareil ou d'un utilisateur. Considérez-le comme un passeport pour votre terminal réseau. Contrairement à un mot de passe, qui est un secret partagé pouvant être volé, deviné ou divulgué, un certificat est lié mathématiquement à une clé privée spécifique qui ne quitte jamais l'appareil. On ne peut pas pirater un certificat par phishing. On ne peut pas le forcer par force brute. Et surtout, vous pouvez le révoquer dès qu'un appareil est perdu ou qu'un employé s'en va. L'infrastructure sous-jacente qui permet ce fonctionnement s'appelle la PKI - Public Key Infrastructure (infrastructure à clés publiques). La PKI est une hiérarchie de confiance. Au sommet se trouve une Autorité de Certification Racine (Root CA) - l'ancre de confiance ultime. En dessous, vous avez généralement une ou plusieurs Autorités de Certification Intermédiaires, qui délivrent réellement les certificats d'entité finale aux appareils et aux utilisateurs. Cette hiérarchie est importante car elle signifie que votre Root CA peut être conservée complètement hors ligne et isolée physiquement du réseau, réduisant considérablement votre surface d'attaque. Si une autorité de certification intermédiaire est compromise, vous la révoquez sans toucher à la racine. Maintenant, comment cela fonctionne-t-il concrètement sur un réseau WiFi ? La pile de protocoles utilise la norme 802.1X - le standard de contrôle d'accès réseau basé sur les ports - combinée à EAP-TLS, qui signifie Extensible Authentication Protocol with Transport Layer Security. C'est la référence absolue pour la sécurité du WiFi d'entreprise.Voici le flux d'authentification. Lorsqu'un appareil client tente de se connecter à votre SSID d'entreprise, le point d'accès - agissant en tant que ce que la norme 802.1X appelle l'authentificateur - n'accorde pas immédiatement l'accès au réseau. À la place, il sert de proxy pour une conversation EAP entre le client et votre serveur RADIUS, qui est le serveur d'authentification dans la terminologie 802.1X. Le client présente son certificat. Le serveur RADIUS valide ce certificat par rapport à votre infrastructure PKI - en vérifiant la chaîne de signature, la période de validité et le statut de révocation. Simultanément - et c'est ce qui rend EAP-TLS véritablement supérieur à la plupart des autres méthodes EAP - le client valide également le certificat du serveur. Cette authentification mutuelle empêche les attaques par faux points d'accès, où un attaquant configure un faux réseau WiFi pour intercepter des identifiants. Avec EAP-TLS, les deux parties prouvent leur identité avant qu'un seul octet de données ne soit transmis. Une fois l'authentification mutuelle réussie, le serveur RADIUS envoie un message Access-Accept au point d'accès, et le client est placé dans le segment de réseau approprié - qu'il s'agisse du VLAN d'entreprise, d'un segment invité restreint ou d'un groupe de politiques spécifique basé sur les attributs du certificat. Parlons du cycle de vie des certificats, car c'est là que de nombreux déploiements rencontrent des frictions opérationnelles. Les certificats sont émis, ils ont une période de validité - généralement d'un à trois ans pour les certificats d'appareil - et ils doivent être renouvelés avant leur expiration. Ils peuvent également être révoqués avant l'expiration si un appareil est volé ou mis hors service. La révocation est gérée par deux mécanismes : les CRL, ou listes de révocation de certificats, qui sont des listes publiées périodiquement de numéros de série de certificats révoqués ; et OCSP, le protocole de vérification de statut de certificat en ligne, qui permet un contrôle de révocation en temps réel. Pour les déploiements de grandes entreprises, OCSP est fortement recommandé car les fichiers CRL peuvent devenir très volumineux et introduire de la latence. L'enrôlement des certificats - le fait d'installer initialement les certificats sur les appareils - est géré via des protocoles comme SCEP, le protocole d'enrôlement de certificat simple, ou EST, l'enrôlement via transport sécurisé, qui en est le remplaçant plus moderne. Dans un environnement Microsoft, vous utiliseriez généralement les services de certificats Active Directory avec des stratégies de groupe pour enrôler automatiquement les certificats sur les machines jointes au domaine. Pour les scénarios de gestion d'appareils mobiles, votre plateforme MDM - qu'il s'agisse d'Intune, Jamf ou d'une autre solution - gère la distribution des certificats dans le cadre du profil de configuration de l'appareil. Maintenant, où se situe l'intersection avec le WiFi invité ? Il s'agit d'une distinction importante. L'authentification par certificat est principalement un contrôle du réseau d'entreprise. Vos invités ne disposeront pas de certificats émis par l'infrastructure PKI de votre entreprise. Pour l'accès des invités, vous opérez dans un modèle d'authentification différent - généralement un Captive Portal avec connexion sociale, enregistrement par e-mail, ou de plus en plus, Passpoint et OpenRoaming, qui utilisent des certificats au niveau de l'infrastructure pour permettre un itinérance sécurisée et transparente d'un site à l'autre. La plateforme de Purple se situe carrément dans cet espace de WiFi invité, fournissant la capture d'identité, les analyses et la couche d'engagement au-dessus d'une infrastructure sans fil sécurisée. Le principe d'architecture clé est la segmentation du réseau : votre SSID d'entreprise authentifié par certificat et votre SSID WiFi invité sont logiquement séparés, avec des règles de pare-feu appropriées entre eux. C'est non négociable pour la conformité PCI-DSS si vous traitez des paiements par carte à proximité de votre infrastructure sans fil, et c'est fortement recommandé pour la conformité GDPR au vu des données que vous gérez sur les deux réseaux. Recommandations d'implémentation et pièges à éviter. Laissez-moi vous donner des conseils de déploiement pratiques - et les pièges dans lesquels je vois les organisations tomber à répétition. Premièrement, planifiez votre PKI avant de toucher à un seul point d'accès. L'erreur la plus courante est de déployer l'authentification par certificat avec une structure d'autorité de certification plate à un seul niveau. Implémentez toujours au moins une hiérarchie à deux niveaux avec une autorité de certification racine hors ligne. Le coût opérationnel est minimal ; le gain de sécurité est substantiel. Deuxièmement, consolidez votre infrastructure RADIUS. Un serveur RADIUS unique est un point de défaillance unique. Déployez au minimum deux serveurs RADIUS dans une configuration actif-passif ou actif-actif, et testez votre basculement. J'ai vu des organisations déployer correctement le 802.1X puis découvrir lors d'une panne que leur basculement RADIUS n'était pas configuré sur les points d'accès. Troisièmement, les périodes de validité des certificats doivent s'aligner sur les cycles de renouvellement de votre MDM. Si votre MDM force le renouvellement des certificats sur un cycle de 90 jours mais que vos certificats ont une validité de 12 mois, vous aurez un décalage. Automatisez le renouvellement et configurez des alertes à 60 jours de l'expiration. Quatrièmement - et cela surprend souvent les gens - iOS et Android gèrent la confiance des certificats différemment. iOS exige que le certificat de l'autorité de certification racine soit explicitement approuvé par l'utilisateur lors de la première connexion, sauf s'il est poussé via MDM. Le comportement d'Android varie selon la version et le fabricant. Testez l'expérience client sur chaque classe d'appareil avant la mise en service. Le cinquième piège est la disponibilité de l'OCSP. Si votre répondeur OCSP est interne et qu'un client ne peut pas l'atteindre pendant l'authentification - peut-être parce qu'il se connecte pour la première fois et n'a pas encore d'accès au réseau - l'authentification peut échouer ou basculer sur la CRL. Concevez votre infrastructure OCSP pour qu'elle soit accessible depuis l'état de pré-authentification, ou configurez votre serveur RADIUS pour mettre en cache les réponses OCSP de manière appropriée. Questions et réponses rapides. Permettez-moi de passer en revue les questions que l'on me pose le plus fréquemment. Question : Pouvons-nous utiliser l'authentification par certificat en parallèle avec notre portail WiFi invités existant ? Absolument. Ce sont des SSID distincts avec des mécanismes d'authentification différents. Vos utilisateurs d'entreprise s'authentifient via EAP-TLS ; vos invités passent par le flux du captive portal. Purple gère la partie invités ; votre infrastructure RADIUS gère la partie entreprise. Question : Que se passe-t-il lorsqu'un appareil est perdu ou volé ? Vous révoquez immédiatement le certificat via votre console de gestion CA. La prochaine fois que cet appareil tente de se connecter, le serveur RADIUS vérifie le statut de révocation et rejette la connexion. Avec OCSP, cela peut se faire presque en temps réel. Avec CRL, cela dépend de votre intervalle de publication CRL - généralement quelques heures. C'est pourquoi OCSP est privilégié pour les environnements à haute sécurité. Question : Est-ce que EAP-TLS est compatible avec WPA3 ? Oui. WPA3-Enterprise impose l'utilisation du mode de sécurité 192 bits pour les déploiements les plus sensibles, et EAP-TLS est entièrement compatible. En fait, WPA3-Enterprise avec EAP-TLS est la configuration de sécurité la plus élevée disponible pour le WiFi d'entreprise aujourd'hui. Question : Quel est l'impact sur notre conformité PCI-DSS ? Positif. Les exigences 1 et 8 de PCI-DSS bénéficient toutes deux de l'authentification par certificat. L'élimination des clés pré-partagées partagées supprime un point d'audit majeur, et l'identité par appareil signifie que vous disposez d'une piste d'audit claire de quel appareil a accédé à quel segment de réseau et à quel moment. Résumé et prochaines étapes. Pour synthétiser : l'authentification par certificat WiFi via 802.1X et EAP-TLS est la bonne approche pour toute organisation qui prend la sécurité de son réseau au sérieux. Elle élimine les secrets partagés, fournit une authentification mutuelle, permet un contrôle d'accès granulaire et s'intègre proprement à votre infrastructure d'identité existante. Le parcours de déploiement est bien connu : concevez votre hiérarchie PKI, déployez une infrastructure RADIUS redondante, intégrez-la à votre MDM pour la distribution des certificats, configurez vos points d'accès pour le 802.1X, et testez minutieusement sur l'ensemble de votre parc d'appareils. Pour votre réseau invités, c'est une autre discussion - et c'est là que des plateformes comme Purple apportent une réelle valeur ajoutée, en vous offrant un accueil des invités sécurisé et conforme, avec les fonctionnalités d'analyse et d'engagement qui transforment votre infrastructure WiFi en un actif commercial plutôt qu'en un simple service utilitaire. Si vous évaluez votre niveau de sécurité d'authentification actuel, le bon point de départ est un audit de votre configuration SSID existante et un examen de la préparation de votre infrastructure de certificats. À partir de là, un déploiement progressif - en commençant par un groupe pilote d'appareils managés - est la voie la moins risquée vers un déploiement complet. Merci d'avoir suivi ce briefing technique Purple. Pour aller plus loin, consultez nos guides sur la sécurité du WiFi d'entreprise et les méthodes d'authentification WiFi les plus sécurisées sur le site Web de Purple à l'adresse purple.ai.