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.
Écouter ce guide
Voir la transcription du podcast
- Synthèse
- Analyse technique approfondie : Comprendre la PKI dans le WiFi d'entreprise
- Les composants clés de la PKI
- Comment la PKI propulse le 802.1X et l'EAP-TLS
- Guide d'implémentation : Déployer un WiFi basé sur les certificats
- Phase 1 : Architecture et sélection de la CA
- Phase 2 : Configuration du serveur RADIUS
- Phase 3 : Approvisionnement automatisé des certificats
- Phase 4 : Application des politiques réseau
- Bonnes pratiques pour l'infrastructure PKI d'entreprise
- Résolution des problèmes et atténuation des risques
- ROI & Impact Commercial

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 |

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).

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.
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é.
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.
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.
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.