Passer au contenu principal

Qu'est-ce que la PKI ? Comment l'infrastructure à clés publiques sécurise le WiFi

Ce guide de référence technique fait autorité et explique l'infrastructure à clés publiques (PKI) ainsi que son rôle essentiel dans la sécurisation des réseaux WiFi d'entreprise dans l'hôtellerie, le commerce de détail et le secteur public. Conçu pour les responsables informatiques, les architectes réseau et les directeurs de la technologie, il fournit des conseils pratiques sur l'authentification par certificat, le déploiement de la norme IEEE 802.1X avec EAP-TLS, et la manière dont la plateforme de Purple tire parti de ces normes pour une connectivité évolutive et conforme. Les lecteurs repartiront avec une feuille de route de déploiement concrète, des études de cas réelles et une compréhension claire de la manière dont la PKI élimine les vulnérabilités du WiFi à clé partagée.

📖 6 min de lecture📝 1,484 mots🔧 2 exemples concrets3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans ce briefing technique Purple. Je suis votre hôte et aujourd'hui, nous nous attaquons à un composant fondamental de la sécurité des réseaux d'entreprise : l'infrastructure à clés publiques, ou PKI, et plus particulièrement à la manière dont elle sécurise le WiFi grâce à l'authentification par certificat. Si vous êtes responsable informatique, architecte réseau ou directeur des opérations d'un site gérant la connectivité dans des hôtels, des chaînes de magasins ou de grands espaces publics, vous savez que la clé pré-partagée traditionnelle (le mot de passe collé au mur ou partagé sur un tableau blanc) est obsolète. C'est une faille de sécurité majeure. Elle n'offre aucune responsabilité individuelle et son renouvellement est un cauchemar opérationnel. Alors, quelle est l'alternative ? La réponse est la norme IEEE 802.1X associée à la PKI. Commençons par les bases. Qu'est-ce qu'une PKI ? L'infrastructure à clés publiques est le cadre complet de matériels, de logiciels, de politiques et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques. En termes simples, c'est le système qui vous permet de délivrer des passeports numériques à chaque appareil et utilisateur de votre réseau. Au lieu qu'un utilisateur saisisse un mot de passe, son appareil présente un certificat numérique : un document cryptographique formaté selon la norme X.509. Ce certificat lie une clé publique à une identité, comme l'adresse MAC d'un appareil ou l'adresse e-mail d'un employé. L'autorité centrale de ce système est l'autorité de certification, ou CA. Considérez la CA comme le gouvernement qui délivre ce passeport. Si votre réseau fait confiance à la CA, il fait confiance aux certificats délivrés par cette CA. Maintenant, comment cela s'applique-t-il au WiFi ? Cela nous amène au 802.1X et à l'EAP-TLS. Le 802.1X est la norme IEEE pour le contrôle d'accès réseau basé sur les ports. Il agit essentiellement comme un videur à la porte de votre réseau : le point d'accès. Il bloque tout le trafic jusqu'à ce que l'appareil prouve son identité. L'EAP-TLS, qui signifie Extensible Authentication Protocol avec Transport Layer Security, est la méthode de référence pour cette preuve. Elle nécessite une authentification mutuelle. C'est un point absolument critique. En EAP-TLS, l'appareil client présente son certificat au serveur RADIUS pour dire : "Je suis un appareil d'entreprise valide". Mais ensuite, le serveur RADIUS présente son propre certificat au client pour dire : "Et je suis le réseau d'entreprise légitime, pas un point d'accès pirate". Cette confiance mutuelle empêche ce que les professionnels de la sécurité appellent les attaques "Evil Twin" (jumeau malveillant), où un acteur malveillant configure un point d'accès pirate avec le même nom de réseau pour voler des identifiants. Comme l'acteur malveillant ne possède pas de certificat valide émanant de votre autorité de certification interne, l'appareil client refusera de se connecter. Un point c'est tout. Parlons des composants plus en détail. La hiérarchie de l'autorité de certification comprend généralement trois niveaux. Au sommet, vous avez la CA racine (Root CA). C'est la source ultime de confiance. Dans un déploiement bien conçu, la CA racine est conservée complètement hors ligne : sécurisée physiquement, isolée du réseau. Elle ne sert qu'à signer les certificats des CA intermédiaires (Intermediate CA). En dessous, vous trouverez une ou plusieurs CA intermédiaires. Celles-ci sont en ligne et gèrent la signature quotidienne des certificats de la CA émettrice. La séparation de la CA racine des CA intermédiaires signifie que même si une CA intermédiaire est compromise, vous pouvez la révoquer sans détruire l'ensemble de votre PKI. Au bas de la hiérarchie, la CA émettrice est celle qui signe réellement les certificats d'entité finale — ceux qui sont installés sur vos ordinateurs portables, tablettes et smartphones. Chaque certificat contient plusieurs champs clés : le Sujet, qui identifie le titulaire du certificat ; l'Émetteur, qui identifie la CA qui l'a signé ; la Clé publique ; la Période de validité, définissant les dates de début et de fin ; et la Signature numérique de la CA émettrice. Examinons maintenant un scénario de déploiement concret. Imaginez une chaîne de vente au détail comptant cinq cents magasins. Ils utilisent actuellement le WPA2-PSK — un mot de passe unique partagé sur l'ensemble des sites. L'équipe informatique sait que cela pose problème. Le renouvellement du personnel implique que le mot de passe est partagé en externe. Il n'y a aucun moyen de vérifier qui est sur le réseau. Et si le mot de passe d'un magasin est compromis, l'attaquant a accès à l'ensemble du parc. La trajectoire de migration vers la PKI se déroule comme suit. Premièrement, sélectionnez un fournisseur de PKI géré dans le cloud et intégrez-le à la solution de gestion des appareils mobiles existante. Deuxièmement, configurez SCEP — le Simple Certificate Enrollment Protocol — pour pousser automatiquement des certificats uniques, liés à l'appareil, vers chaque appareil de l'entreprise. Troisièmement, déployez un service RADIUS cloud et configurez-le pour valider les certificats par rapport à la PKI. Quatrièmement, reconfigurez les contrôleurs sans fil de chaque magasin pour imposer l'authentification 802.1X sur l'SSID de l'entreprise. Enfin, retirez le réseau PSK. Le résultat ? Chaque appareil dispose d'une identité cryptographique unique. Si une tablette est volée, son certificat est révoqué dans la PKI et, en quelques minutes, cet appareil ne peut plus accéder à aucun réseau, dans aucun magasin. Pas de rotation de mot de passe. Pas d'interruption de service. Pas de chaos opérationnel. Parlons maintenant de quelques pièges courants, car c'est là que de nombreux déploiements rencontrent des difficultés. Le premier problème, et le plus fréquent, est une mauvaise gestion de la révocation. Émettre des certificats est la partie facile. Les révoquer de manière fiable est l'aspect où les équipes échouent souvent. Votre serveur RADIUS doit être configuré pour vérifier activement la liste de révocation de certificats, ou CRL, ou utiliser le protocole OCSP (Online Certificate Status Protocol) lors de chaque tentative d'authentification. Pas seulement une fois par jour. À chaque fois. Si un appareil est compromis et que son certificat est révoqué, mais que votre serveur RADIUS ne vérifie la CRL qu'une fois toutes les vingt-quatre heures, vous vous exposez à une faille de sécurité de vingt-quatre heures. Le second piège est la synchronisation de l'heure. Cela piège les équipes plus souvent qu'on ne le pense. Les certificats numériques sont extrêmement sensibles à l'heure. Si l'horloge d'un appareil client est décalée de plus de quelques minutes — en raison d'une panne NTP, par exemple — la validation du certificat échouera. Le certificat semblera soit pas encore valide, soit déjà expiré. Assurez une configuration NTP robuste sur l'ensemble de votre infrastructure réseau. Le troisième piège est la distribution de la chaîne de confiance. Pour que l'authentification mutuelle EAP-TLS fonctionne, l'appareil client doit faire confiance à l'AC racine qui a émis le certificat du serveur RADIUS. Sur les appareils Windows joints à Active Directory, cela est généralement géré automatiquement via la stratégie de groupe. Mais pour les appareils Android, les appareils iOS ou les équipements BYOD, vous devez pousser le certificat de l'AC racine via MDM. Si vous manquez cette étape, ces appareils rejetteront le certificat du serveur RADIUS et ne parviendront pas à se connecter. Passons maintenant aux questions rapides que l'on me pose le plus souvent. Puis-je utiliser EAP-TLS pour le WiFi invité ? Techniquement oui, mais en pratique non. Les appareils invités ne sont pas managés, vous ne pouvez donc pas leur pousser de certificats. Les réseaux invités doivent utiliser un Captive Portal avec connexion via les réseaux sociaux ou authentification par e-mail, tandis que l'SSID de l'entreprise utilise EAP-TLS. Les plateformes comme Purple gèrent cette séparation proprement. Qu'est-ce qu'OpenRoaming et quel est le rapport avec la PKI ? OpenRoaming est une norme de WiFi fédérée qui permet aux utilisateurs de se connecter de manière fluide et sécurisée aux réseaux participants à l'aide d'un profil pré-configuré — essentiellement un identifiant basé sur un certificat. Purple agit en tant que fournisseur d'identité gratuit pour OpenRoaming sous la licence Connect, ce qui signifie que les utilisateurs configurés via Purple peuvent se connecter à n'importe quel site compatible OpenRoaming sans Captive Portal ni mot de passe. À quelle fréquence les certificats doivent-ils être renouvelés ? La bonne pratique consiste à définir la durée de vie des certificats à un an pour les certificats d'entité finale et à automatiser le renouvellement à soixante pour cent de la période de validité. Cela vous donne une marge substantielle si le processus de renouvellement échoue. Pour résumer le point d'aujourd'hui. La PKI remplace les secrets partagés vulnérables par une identité cryptographique. Chaque appareil reçoit un certificat numérique unique et infalsifiable. EAP-TLS fournit une authentification mutuelle, garantissant que l'appareil fait confiance au réseau et que le réseau fait confiance à l'appareil. Le provisionnement automatisé via MDM est non négociable pour les déploiements évolutifs. Une vérification robuste de la révocation fait la différence entre un déploiement sécurisé et un faux sentiment de sécurité. Et pour les sites ouverts au public, l'adoption de normes basées sur la PKI comme OpenRoaming offre une expérience client fluide, sécurisée et à grande échelle. Si vous planifiez une migration vers un WiFi basé sur des certificats, le guide de référence technique complet est disponible sur le site Web de Purple, avec des schémas d'architecture, des listes de contrôle de déploiement et des exemples concrets pour les secteurs de l'hôtellerie, de la vente au détail et de la santé. Merci d'avoir participé à ce briefing. À la prochaine.

header_image.png

Synthèse

Pour les responsables informatiques d'entreprise qui gèrent des déploiements à grande échelle dans l'hôtellerie, le commerce de détail ou les espaces publics, la sécurisation de l'accès sans fil est une exigence fondamentale — et non une option. Les clés pré-partagées traditionnelles (PSK) sont inadaptées aux environnements d'entreprise : elles n'offrent aucune responsabilité individuelle, ne peuvent pas être auditées et génèrent une charge opérationnelle importante lors de leur renouvellement. L'infrastructure à clés publiques (PKI) fournit le fondement cryptographique nécessaire à une sécurité réseau robuste et évolutive. Ce guide détaille ce qu'est une PKI, comment elle sécurise le WiFi d'entreprise grâce à l'authentification par certificat, et les étapes concrètes requises pour déployer la norme IEEE 802.1X avec EAP-TLS. En passant à une architecture basée sur une PKI, les organisations peuvent éliminer le vol de d'identifiants, automatiser l'intégration des appareils et garantir un accès fluide et sécurisé pour les appareils de l'entreprise et les invités — tout en répondant aux exigences des normes PCI DSS, GDPR et ISO 27001.


Analyse technique approfondie : Comprendre la PKI dans le WiFi d'entreprise

Une infrastructure à clés publiques (PKI) est l'ensemble de composants matériels, logiciels, de politiques et de procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques et gérer le chiffrement à clé publique. Dans le contexte du WiFi d'entreprise, la PKI est le moteur qui assure la vérification de l'identité et le chiffrement — remplaçant le mot de passe partagé, intrinsèquement non sécurisé, par une identité cryptographique unique pour chaque appareil ou utilisateur.

Les composants clés de la PKI

La PKI repose essentiellement sur la cryptographie asymétrique, qui utilise deux clés liées mathématiquement : une clé publique (partagée ouvertement) et une clé privée (gardée secrète). Les données chiffrées avec la clé publique ne peuvent être déchiffrées que par la clé privée correspondante, et vice versa. Les principaux composants d'un déploiement PKI sont les suivants.

Composant Rôle Contexte WiFi d'entreprise
Autorité de certification (CA) Émet et signe les certificats numériques La racine de confiance de votre réseau ; tous les appareils doivent faire confiance à la CA
Certificat numérique (X.509) Lie une clé publique à une identité Installé sur chaque appareil de l'entreprise ; présenté lors de l'authentification 802.1X
Serveur RADIUS Valide les certificats et accorde l'accès au réseau Le moteur de décision qui accepte ou rejette les demandes de connexion
Autorité d'enregistrement (RA) Vérifie l'identité avant l'émission du certificat Souvent gérée par le MDM/UEM dans les déploiements automatisés
CRL / OCSP Vérifie si un certificat a été révoqué Crucial pour bloquer en temps réel les appareils compromis ou volés

pki_architecture_overview.png

Comment la PKI propulse le 802.1X et l'EAP-TLS

La sécurité WiFi d'entreprise repose sur la norme IEEE 802.1X pour le contrôle d'accès réseau basé sur les ports. Combiné au protocole EAP (Extensible Authentication Protocol), et plus particulièrement EAP-TLS (Transport Layer Security), l'infrastructure PKI offre le plus haut niveau de sécurité sans fil : l'authentification mutuelle.

Dans un déploiement EAP-TLS, l'appareil client présente son certificat numérique au réseau pour prouver son identité, et le serveur RADIUS présente son certificat au client, prouvant ainsi que le réseau est légitime et qu'il ne s'agit pas d'un point d'accès malveillant de type "evil twin". Cette confiance mutuelle est établie car les deux parties font confiance à l'AC racine (Root CA) qui a émis les certificats. Une fois authentifiée, la session est chiffrée à l'aide de la suite de chiffrement TLS négociée, ce qui empêche l'écoute clandestine et les attaques de l'homme du milieu (man-in-the-middle).

8021x_authentication_flow.png

Le flux EAP-TLS fonctionne à travers quatre entités logiques : l'Appareil Client (supplicant), le Point d'Accès (authentificateur), le Serveur RADIUS (serveur d'authentification) et l'Autorité de Certification (CA). Le point d'accès agit comme un relais transparent — il ne prend pas de décision d'authentification lui-même. Cette décision incombe entièrement au serveur RADIUS, qui valide la chaîne de certificats jusqu'à l'AC racine de confiance.


Guide d'implémentation : Déployer un WiFi basé sur les certificats

La transition vers une architecture WiFi reposant sur une PKI nécessite une planification rigoureuse en quatre phases.

Phase 1 : Architecture et sélection de la CA

Choisissez entre la création d'une PKI interne (par exemple, Active Directory Certificate Services de Microsoft) ou l'utilisation d'un fournisseur de PKI cloud managé. Pour les déploiements modernes à grande échelle, une PKI cloud réduit considérablement la charge administrative et offre une haute disponibilité intégrée. Assurez-vous que la CA choisie s'intègre parfaitement à votre solution de gestion des appareils mobiles (MDM) ou de gestion unifiée des terminaux (UEM). Pour les environnements utilisant le Guest WiFi , assurez-vous que l'infrastructure RADIUS est conçue pour gérer à la fois le trafic d'entreprise 802.1X et l'authentification par Captive Portal des invités sur des SSID distincts.

Phase 2 : Configuration du serveur RADIUS

Déployez un serveur RADIUS robuste — les options incluent FreeRADIUS, Cisco ISE, Aruba ClearPass ou un service RADIUS-as-a-Service cloud natif. Configurez le serveur RADIUS avec son propre certificat de serveur émis par votre CA. C'est une étape critique : sans certificat de serveur valide, le client ne peut pas effectuer d'authentification mutuelle et sera vulnérable aux attaques de type "evil twin". Pour les déploiements dans les grands espaces, envisagez des configurations de proxy RADIUS afin de prendre en charge l'itinérance entre les sites. Les établissements déployant des plateformes de WiFi Analytics doivent s'assurer que les données de comptabilité (accounting) RADIUS alimentent le pipeline d'analyse pour une attribution précise des sessions.

Phase 3 : Approvisionnement automatisé des certificats

L'installation manuelle de certificats n'est pas évolutive et s'avère sujette aux erreurs. Tirez parti de protocoles tels que SCEP (Simple Certificate Enrollment Protocol) ou EST (Enrollment over Secure Transport) via votre MDM pour déployer silencieusement des certificats sur les appareils de l'entreprise. Pour les scénarios de BYOD, mettez en œuvre un portail d'intégration qui fournit de manière sécurisée un certificat à l'appareil de l'utilisateur après une vérification initiale de son identité. Pour les appareils IoT sans écran — tels que les équipements médicaux, les terminaux de point de vente ou l'affichage dynamique — les certificats doivent être configurés lors de la phase de préparation de l'appareil avant son déploiement.

Phase 4 : Application des politiques réseau

Configurez vos contrôleurs sans fil et vos points d'accès pour appliquer le 802.1X sur l'SSID de l'entreprise. Associez les attributs de certificat (tels que le Subject Alternative Name ou le champ OU) à des VLAN spécifiques ou à des politiques de pare-feu à l'aide d'attributs RADIUS, garantissant ainsi un accès réseau selon le principe du moindre privilège. Pour les sites utilisant du matériel de fournisseurs spécifiques, reportez-vous aux guides spécifiques aux fabricants tels que Your Guide to a Wireless Access Point Ruckus pour connaître les étapes de configuration propres à chaque plateforme.


Bonnes pratiques pour l'infrastructure PKI d'entreprise

Protégez l'autorité de certification racine (Root CA). Si vous utilisez une PKI interne, la Root CA doit rester hors ligne et être sécurisée physiquement. Seules les autorités de certification intermédiaires doivent être en ligne et délivrer activement des certificats. Une Root CA compromise invalide l'ensemble de votre PKI.

Mettez en œuvre une vérification robuste de la révocation. Assurez-vous que vos serveurs RADIUS vérifient activement les listes de révocation de certificats (CRL) ou utilisent le protocole OCSP pour vérifier l'état des certificats à chaque tentative d'authentification. L'accès d'un appareil compromis doit être bloqué immédiatement par la révocation de son certificat. Configurer le serveur RADIUS pour mettre en cache les réponses CRL trop longtemps crée une fenêtre de vulnérabilité.

Automatisez les renouvellements avant l'expiration. Les certificats ont une date de fin de validité. Mettez en œuvre des processus de renouvellement automatique déclenchés à 60 ou 70 % de la période de validité du certificat afin d'éviter les pannes de réseau causées par des certificats expirés. L'expiration des certificats est l'une des causes les plus fréquentes d'interruptions de Wi-Fi non planifiées dans les environnements d'entreprise.

Adoptez OpenRoaming pour les lieux publics. Pour les secteurs de l' Hôtellerie , du Commerce de détail , des Transports et de la Santé , la participation à OpenRoaming offre une connectivité invité fluide et sécurisée à grande échelle. Purple agit en tant que fournisseur d'identité gratuit pour OpenRoaming sous la licence Connect, permettant aux utilisateurs disposant de profils existants de se connecter en toute sécurité sans Captive Portal ni mot de passe — le tout reposant sur le même modèle de confiance PKI décrit dans ce guide.


Résolution des problèmes et atténuation des risques

Même avec une planification minutieuse, les déploiements de PKI rencontrent des modes de défaillance prévisibles. Le tableau ci-dessous résume les problèmes les plus courants et leurs solutions.

Mode de défaillance Symptôme Cause racine Résolution
Time sync failure Erreurs de validation de certificat sur tous les appareils Mauvaise configuration NTP sur le client ou le RADIUS Appliquer la politique NTP via le MDM et l'infrastructure réseau
Trust chain failure Types d'appareils spécifiques (ex. Android) impossibles à connecter CA racine absent du magasin de racines de confiance de l'appareil Pousser la CA racine via un profil MDM
CRL unreachable Échecs d'authentification intermittents Pare-feu bloquant les points de terminaison CRL/OCSP Ouvrir les règles de pare-feu pour les points de distribution de la CA
Certificate expiry Déconnexion massive et soudaine Automatisation du renouvellement non configurée Implémenter le renouvellement déclenché par le MDM à 60 % de validité
RADIUS cert mismatch Échec de l'authentification mutuelle pour tous les clients Certificat du serveur RADIUS expiré ou mauvaise CA Renouveler le certificat du serveur RADIUS et redéployer

Pour les environnements de santé en particulier, où les interruptions de réseau ont des implications directes sur la sécurité des patients, reportez-vous à WiFi in Hospitals: A Guide to Secure Clinical Networks pour des recommandations de résilience de niveau clinique.


ROI & Impact Commercial

La mise en œuvre d'une PKI pour la sécurité du WiFi offre une valeur commerciale mesurable sur trois dimensions.

Réduction des risques et conformité. L'élimination des mots de passe partagés supprime le vecteur le plus courant de mouvement latéral sur le réseau. L'authentification par certificat répond directement aux exigences du PCI DSS (Exigence 8.6), du GDPR (mesures techniques de l'Article 32) et de l'ISO 27001 (Annexe A.9). La possibilité de révoquer instantanément un certificat lorsqu'un employé s'en va ou qu'un appareil est volé fournit un contrôle auditable et démontrable que les environnements à clé partagée ne peuvent tout simplement pas égaler.

Efficacité opérationnelle. Le provisionnement automatisé des certificats via le MDM réduit considérablement les tickets du support informatique liés aux problèmes de connectivité WiFi (réinitialisations de mots de passe, rotations de clés et retards d'intégration). Dans les environnements de vente au détail à forte rotation de personnel, cela se traduit directement par une réduction des coûts de support informatique et des délais de déploiement des appareils plus rapides.

Expérience utilisateur et invité améliorée. L'authentification par certificat est invisible pour l'utilisateur final. Les employés de l'entreprise se connectent automatiquement et en toute sécurité sans aucune étape manuelle. Pour les invités, les plateformes comme la solution de Guest WiFi de Purple gèrent la séparation entre l'accès géré de l'entreprise et l'intégration des invités, garantissant que chaque public bénéficie de l'expérience d'authentification appropriée sans compromettre la sécurité sur l'un ou l'autre réseau.

Définitions clés

Public Key Infrastructure (PKI)

Le cadre complet de rôles, de politiques, de matériel et de logiciels utilisé pour gérer les certificats numériques et le chiffrement par clé publique. Il établit les relations de confiance qui permettent aux appareils et aux serveurs de vérifier mutuellement leurs identités de manière cryptographique.

L'architecture fondamentale requise pour abandonner les mots de passe partagés au profit d'une sécurité réseau basée sur l'identité. Tout déploiement de WiFi d'entreprise utilisant la norme 802.1X dépend d'une PKI.

Certificate Authority (CA)

Une entité de confiance qui émet, signe et gère des certificats numériques. Elle fait office de racine de confiance dans une PKI : tout certificat signé par la CA est approuvé par toutes les parties qui font confiance à la CA.

Le pilier central de la sécurité de votre réseau. Si la CA est compromise, tous les certificats qu'elle a émis le sont potentiellement aussi. La protection de la Root CA est le contrôle de sécurité le plus important dans un déploiement de PKI.

X.509

La norme ITU-T définissant le format des certificats à clé publique. Les certificats X.509 contiennent des champs incluant le Sujet, l'Émetteur, la Clé Publique, la Période de Validité et la Signature Numérique de la CA.

Lors de la configuration des politiques de serveur RADIUS, les équipes informatiques associent des champs X.509 spécifiques — tels que le Subject Alternative Name (SAN) ou l'Organisational Unit (OU) — à des attributions de VLAN et des politiques d'accès.

IEEE 802.1X

La norme IEEE pour le contrôle d'accès réseau basé sur les ports (PNAC). Elle fournit un mécanisme d'authentification qui bloque tout trafic réseau au niveau du point d'accès jusqu'à ce que l'identité de l'appareil connecté ait été vérifiée par un serveur d'authentification.

Le protocole qui applique l'authentification par certificat au niveau du point d'accès sans fil. Sans 802.1X, un appareil peut se connecter au SSID sans prouver son identité.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Une méthode EAP qui utilise des certificats clients et serveurs pour établir une session TLS chiffrée et mutuellement authentifiée. C'est la méthode EAP la plus sécurisée disponible pour le WiFi d'entreprise.

La référence absolue pour l'authentification WiFi d'entreprise. Contrairement à PEAP ou EAP-TTLS, qui utilisent des mots de passe à l'intérieur d'un tunnel TLS, EAP-TLS élimine complètement les mots de passe, les remplaçant par des certificats cryptographiques.

RADIUS (Remote Authentication Dial-In User Service)

Un protocole réseau fournissant une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA). Dans les déploiements 802.1X, le serveur RADIUS reçoit le certificat du client de la part du point d'accès, le valide auprès de la CA et renvoie une décision d'accès.

Le moteur de décision de la pile d'authentification WiFi d'entreprise. RADIUS gère également l'attribution dynamique de VLAN, permettant la segmentation du réseau en fonction de l'identité de l'appareil ou du rôle de l'utilisateur.

Certificate Revocation List (CRL)

Une liste publiée périodiquement contenant les certificats révoqués par la CA émettrice avant leur date d'expiration prévue. Les serveurs RADIUS consultent la CRL pour s'assurer qu'ils n'accordent pas d'accès à des appareils compromis ou hors service.

Élément essentiel pour maintenir la sécurité lorsque des appareils sont perdus, volés ou mis hors service. La vérification de la CRL doit être configurée sur le serveur RADIUS — elle ne se fait pas automatiquement.

Mutual Authentication

Un processus de sécurité par lequel les deux parties d'une liaison de communication s'authentifient mutuellement et simultanément. En EAP-TLS, le client s'authentifie auprès du réseau et le réseau s'authentifie auprès du client.

Empêche les attaques de type "Evil Twin" où un pirate configure un point d'accès malveillant avec le même SSID que le réseau de l'entreprise pour intercepter des identifiants. Sans authentification mutuelle, le client n'a aucun moyen de vérifier qu'il se connecte au réseau légitime.

SCEP (Simple Certificate Enrollment Protocol)

Un protocole qui permet la distribution automatisée et évolutive de certificats numériques aux appareils via un MDM ou un système de gestion des appareils réseau.

Le mécanisme qui rend les déploiements de PKI d'entreprise opérationnellement viables à grande échelle. Sans SCEP ou protocole d'enrôlement automatisé similaire, le provisionnement de certificats sur des milliers d'appareils nécessiterait une intervention manuelle.

Exemples concrets

Une grande chaîne de magasins de détail comptant 500 points de vente doit sécuriser son WiFi d'entreprise pour les tablettes de point de vente (POS) des employés et les scanners d'inventaire. Elle utilise actuellement un unique WPA2-PSK dans tous ses magasins, qui est fréquemment partagé avec des personnes externes à l'entreprise et ne peut faire l'objet d'un audit. Comment doit-elle repenser son architecture d'authentification ?

La chaîne de magasins doit migrer vers le WPA3-Enterprise en utilisant le 802.1X et l'EAP-TLS. Étape 1 : Sélectionner un fournisseur de PKI géré dans le cloud et l'intégrer à la solution MDM existante qui gère les tablettes POS et les scanners. Étape 2 : Configurer SCEP pour envoyer automatiquement des certificats numériques uniques et liés aux appareils vers chaque appareil d'entreprise via le MDM. Étape 3 : Déployer un service Cloud RADIUS et le configurer pour valider les certificats par rapport à la PKI, avec la vérification OCSP activée. Étape 4 : Reconfigurer les contrôleurs sans fil de chaque magasin pour imposer l'authentification 802.1X sur l'SSID de l'entreprise. Étape 5 : Retirer le réseau PSK. Étape 6 : Configurer l'attribution de VLAN via les attributs RADIUS pour segmenter les appareils POS des appareils du personnel général au niveau de la couche réseau.

Commentaire de l'examinateur : Cette approche élimine totalement la vulnérabilité liée au secret partagé. Les certificats étant déployés via MDM et liés au matériel de l'appareil, ils ne peuvent pas être extraits et partagés à l'extérieur. Si une tablette est perdue ou volée, son certificat spécifique est révoqué via l'intégration MDM/PKI, bloquant instantanément l'accès au réseau de cet appareil sans affecter les autres magasins ou appareils. La segmentation VLAN via les attributs RADIUS répond également aux exigences de segmentation réseau de la norme PCI DSS pour les environnements de données de titulaires de cartes.

Un grand réseau hospitalier déploie de nouvelles pompes à perfusion médicales sans fil sur trois sites. Ces appareils ne disposent pas d'interface utilisateur pour saisir des identifiants ou accepter les invitations d'un Captive Portal. Comment peuvent-ils être connectés en toute sécurité au réseau WiFi clinique sans créer de vulnérabilité liée à une clé partagée ?

Mettre en œuvre une architecture basée sur une PKI spécifiquement pour les appareils IoT médicaux sans écran (headless). Étape 1 : Générer des certificats X.509 spécifiques à chaque appareil pour chaque pompe à perfusion, en utilisant le numéro de série de l'appareil comme Subject Common Name. Étape 2 : Installer les certificats sur les pompes lors de la phase de préparation et de provisionnement, avant le déploiement clinique. Étape 3 : Configurer l'SSID du WiFi clinique pour le 802.1X EAP-TLS. Étape 4 : Configurer le serveur RADIUS pour mapper le Subject CN du certificat de l'appareil à un VLAN spécifique dédié aux appareils médicaux. Étape 5 : Mettre en œuvre la vérification CRL pour permettre une révocation instantanée si un appareil est mis hors service ou rappelé.

Commentaire de l'examinateur : Il s'agit de l'approche standard pour les déploiements IoT sécurisés dans les environnements cliniques, comme détaillé dans [WiFi in Hospitals: A Guide to Secure Clinical Networks](/blog/wifi-in-hospitals). Elle offre une sécurité robuste basée sur l'identité sans nécessiter d'interaction de la part de l'utilisateur, ce qui est essentiel pour les appareils médicaux sans écran. L'affectation de VLAN via RADIUS garantit que même si le certificat d'une pompe était compromis d'une manière ou d'une autre, l'appareil n'aurait jamais accès qu'au VLAN des appareils cliniques — et non au réseau hospitalier plus large.

Questions d'entraînement

Q1. Votre entreprise migre de PEAP (identifiant/mot de passe) vers EAP-TLS (certificats) pour le SSID de l'entreprise. Lors des tests, les ordinateurs portables Windows se connectent avec succès, mais les appareils Android échouent systématiquement. Les journaux RADIUS indiquent que les appareils Android rejettent le certificat du serveur lors de la liaison TLS (TLS handshake). Quelle est la cause la plus probable et comment la résoudre ?

Conseil : Considérez le concept d'authentification mutuelle et la chaîne de confiance. De quoi l'appareil Android a-t-il besoin pour faire confiance au certificat du serveur RADIUS ?

Voir la réponse type

Les appareils Android n'ont pas le certificat de l'Autorité de Certification (CA) Racine installé dans leur magasin de certificats racines de confiance. Les ordinateurs portables Windows reçoivent automatiquement l'autorité racine via la stratégie de groupe, mais les appareils Android nécessitent que la CA Racine soit déployée via un profil MDM. Sans la CA Racine dans le magasin de confiance, l'appareil Android ne peut pas vérifier la chaîne de certificats du serveur RADIUS, ce qui l'amène à rejeter le certificat du serveur et à interrompre la liaison TLS. Résolution : créez un profil de configuration MDM qui installe le certificat de la CA Racine dans le magasin de confiance de tous les appareils Android gérés, puis testez à nouveau.

Q2. L'ordinateur portable professionnel d'un employé récemment licencié se connecte toujours avec succès au réseau WiFi de l'entreprise deux jours après la désactivation de son compte Active Directory. Le réseau utilise EAP-TLS. Pourquoi cela se produit-il et que faut-il faire pour l'empêcher ?

Conseil : La désactivation d'un compte Active Directory n'invalide pas automatiquement un certificat cryptographique. Réfléchissez à ce que le serveur RADIUS est réellement en train de valider.

Voir la réponse type

Le serveur RADIUS valide le certificat, et non le statut du compte Active Directory. Comme le certificat est toujours mathématiquement valide et n'a pas été révoqué, le serveur RADIUS accorde l'accès. Pour résoudre ce problème immédiatement, le certificat spécifique délivré à cet ordinateur portable doit être révoqué dans l'Autorité de Certification. Pour éviter cela de manière systématique, intégrez le processus de départ RH avec le MDM et la PKI : lorsqu'un employé est licencié, le MDM doit automatiquement révoquer le certificat de l'appareil et désinscrire celui-ci. De plus, assurez-vous que le serveur RADIUS est configuré pour vérifier l'OCSP ou la CRL lors de chaque tentative d'authentification — et pas seulement périodiquement — afin que la révocation prenne effet immédiatement.

Q3. Vous concevez l'architecture réseau d'un grand stade qui souhaite offrir un accès WiFi sécurisé et fluide à 60 000 spectateurs sans exiger que chaque personne passe par un Captive Portal. Le site souhaite également prendre en charge les exposants professionnels qui ont besoin d'un accès sécurisé par 802.1X pour leurs terminaux de paiement (POS). Comment la PKI s'intègre-t-elle dans ces deux exigences ?

Conseil : Considérez qu'il existe deux publics distincts avec des besoins d'authentification différents. OpenRoaming répond à l'un ; un SSID d'entreprise dédié avec 802.1X répond à l'autre.

Voir la réponse type

Deux SSIDs distincts sont nécessaires. Pour les 60 000 spectateurs, configurez OpenRoaming. Le réseau du stade doit être configuré pour faire confiance aux CAs Racines d'OpenRoaming. Lorsqu'un appareil visiteur — configuré par un fournisseur d'identité tel que Purple ou un opérateur mobile — se connecte, il présente un certificat. Le serveur RADIUS le valide par rapport à la chaîne de confiance OpenRoaming et accorde un accès sécurisé et chiffré sans Captive Portal. Pour les exposants professionnels dotés d'équipements POS, déployez un SSID 802.1X distinct utilisant EAP-TLS. Les exposants reçoivent des certificats d'appareil temporaires lors de leur processus d'accréditation, qui sont automatiquement révoqués après l'événement. Les attributs RADIUS affectent les appareils POS à un VLAN dédié, répondant ainsi aux exigences de segmentation réseau de la norme PCI DSS.

Continuer la lecture de cette série

Per-Device PSK par constructeur : iPSK, DPSK, MPSK et PPSK comparés (et support de WPA3)

Une comparaison complète des implémentations de per-device PSK chez Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet et Ubiquiti UniFi. Découvrez comment le WPA3-SAE impacte les stratégies de clés par appareil et quand déployer des modes de transition par rapport à une migration vers le 802.1X.

Lire le guide →

Comparatif des méthodes d'authentification par Captive Portal

Ce guide de référence technique et d'autorité évalue les compromis architecturaux, opérationnels et de conformité des cinq principales méthodes d'authentification par captive portal. Il fournit aux architectes réseau, directeurs informatiques et responsables marketing les données quantitatives et les cadres de décision nécessaires pour équilibrer la friction d'intégration des invités avec les exigences de collecte de données au sein des sites d'entreprise.

Lire le guide →

Qu'est-ce que l'authentification par adresse MAC ? Quand l'utiliser et quand l'éviter

Ce guide de référence technique faisant autorité couvre l'authentification par adresse MAC dans les environnements WiFi d'entreprise — comment fonctionne l'authentification MAC basée sur RADIUS au niveau de la couche 2, ses vulnérabilités de sécurité inhérentes (y compris le spoofing MAC et l'impact de la randomisation MAC au niveau du système d'exploitation), et les contextes opérationnels précis où elle reste un outil valable pour gérer l'IoT et les appareils sans écran (headless). Il fournit des conseils de déploiement exploitables pour les responsables informatiques et les architectes réseau dans les secteurs de l'hôtellerie, du commerce de détail, de la santé et des espaces publics, avec des exemples concrets, des cadres de décision et le contexte d'intégration pour le WiFi invité et la plateforme d'analyse de Purple.

Lire le guide →