EAP-TLS vs PEAP : sécurité, certificats et adéquation
Published
Le conseil le plus courant concernant eap tls vs peap est simpliste et erroné. Choisir EAP-TLS parce qu'il est "plus sécurisé," et laisser PEAP aux équipes qui n'ont pas rattrapé leur retard. Cela élude la question qui détermine si un WLAN multi-site fonctionne toujours un lundi matin. Pouvez-vous émettre, renouveler et révoquer un certificat pour chaque appareil censé l'utiliser ?
Je ne déploirais pas une seule méthode sur l'ensemble du parc. L'EAP-TLS sa place sur les appareils que vous pouvez enrôler et renouveler. Le PEAP, presque toujours avec un EAP-MSCHAPv2 interne, s'impose lorsqu'un mot de passe d'annuaire existe déjà et que l'enrôlement de certificats n'est pas pratique. La méthode la plus complexe n'est pas toujours celle que vous pouvez exploiter. Un certificat expiré dans le back-office d'un hôtel bloque le personnel alors que ses comptes restent valides. Un profil PEAP qui ignore la vérification du serveur peut transmettre un mot de passe d'annuaire à un point d'accès malveillant. Ces deux échecs sont d'ordre opérationnel. Attribuez la méthode à la population ciblée au lieu de chercher une solution unique pour tout le réseau.
Table des matières
- EAP-TLS et PEAP côte à côte
- Comment chaque méthode s'authentifie et où les mots de passe fuient
- Prérequis relatifs aux certificats avant le déploiement
- Cycle de vie des certificats et effort de déploiement
- Révocation, vitesse de roaming et prise en charge des clients
- Attribuer chaque population et valider la séparation
EAP-TLS et PEAP côte à côte
La différence pratique entre EAP-TLS et PEAP réside dans le type d'identifiant que chaque équipement peut prendre en charge et les efforts requis pour le maintenir fonctionnel. Utilisez EAP-TLS pour les appareils que vous pouvez inscrire et renouveler. Utilisez PEAP lorsque les utilisateurs disposent déjà de mots de passe d'annuaire et que l'inscription de certificats n'est pas réalisable. Aucune des deux méthodes n'est la solution universelle pour tous les profils d'utilisateurs.
| Critère | EAP-TLS | PEAP |
|---|---|---|
| ID de type EAP | 13 | 26 |
| Identifiant client | Certificat client X.509 | Nom d'utilisateur et mot de passe, généralement EAP-MSCHAPv2 ou EAP-GTC |
| Identifiant serveur | Certificat de serveur RADIUS | Certificat de serveur RADIUS sur le tunnel TLS externe |
| Authentification mutuelle | Certificats client et serveur | Certificat serveur plus authentification interne de l'utilisateur ou de l'équipement |
| Mot de passe sur le réseau | Aucun | Oui, à l'intérieur du tunnel TLS |
| Ce qu'un AP malveillant peut voler si le client ignore la vérification du serveur | Rien de similaire à un mot de passe ; l'authentification échoue par sécurité | Mot de passe d'annuaire |
| Révocation d'un équipement | Révoker ou faire expirer ce certificat | Désactiver le compte ou réinitialiser un mot de passe susceptible d'être réutilisé |
| Gestion de l'infra PKI | Certificats serveur et client, renouvellement et récupération | Certificat serveur uniquement |
| Meilleurs cas d'usage initial | Personnel géré par MDM et équipements privilégiés | Équipements non gérés ne pouvant pas intégrer de certificats |
Un article technique Authentik de 2025 identifie EAP-TLS sous l'ID de type EAP 13 et PEAP sous l'ID de type 26. Ces ID identifient les méthodes auprès de RADIUS et du supplicant. Ils ne déterminent pas quelles personnes ou quels appareils doivent les utiliser.
Ce que ces lignes changent concrètement
L'identifiant du client définit la limite opérationnelle. EAP-TLS présente un certificat client X.509. PEAP utilise un nom d'utilisateur et un mot de passe, généralement via EAP-MSCHAPv2 ou EAP-GTC. Cela fait de l'enrôlement et du renouvellement des certificats la charge de travail déterminante, plutôt qu'un classement théorique des méthodes.
Les vérifications de confiance diffèrent également. EAP-TLS authentifie à la fois les certificats client et serveur. PEAP valide le certificat du serveur RADIUS sur le tunnel TLS externe, puis authentifie l'utilisateur ou l'équipement avec une méthode interne.
L'exposition du mot de passe dépend de la configuration du supplicant. EAP-TLS ne fait circuler aucun mot de passe sur le réseau. PEAP transporte un mot de passe dans son tunnel, donc un client qui ignore les vérifications du serveur peut divulguer un mot de passe d'annuaire à un point d'accès piraté. Avec EAP-TLS, un certificat client manquant ou non approuvé entraîne l'échec de l'authentification.
La désinscription dépend également de ce qui est géré. Un certificat d'appareil peut être révoqué ou laissé à expiration sans réinitialiser le mot de passe d'annuaire d'une personne. La désactivation d'un compte ou la modification d'un mot de passe réutilisé peut affecter d'autres connexions liées à cet identifiant.
Le compromis opérationnel est clair : EAP-TLS nécessite des certificats clients, un renouvellement et une procédure de récupération, tandis que PEAP exige le certificat serveur et une configuration rigoureuse du supplicant. Attribuez EAP-TLS au personnel enrôlé et aux appareils privilégiés ; conservez PEAP pour les terminaux non gérés qui ne peuvent pas intégrer la gestion des certificats. Les équipes qui exploitent une infrastructure serverless pour les plateformes de membres peuvent avoir des populations distinctes de membres, de personnel et d'appareils, mais le modèle d'hébergement ne choisit pas la méthode d'authentification. L'identifiant doit correspondre à ce que vous êtes en mesure de gérer.
Comment chaque méthode s'authentifie et où les mots de passe fuient
EAP-TLS n'est pas automatiquement la bonne réponse pour chaque utilisateur. La décision clé consiste à savoir si votre équipe peut émettre, renouveler et révoquer des certificats de manière fiable pour chaque population. PEAP simplifie l'intégration des utilisateurs non gérés, mais son mot de passe dépend d'une configuration correcte du supplicant.
Les deux méthodes utilisent le 802.1X. Le supplicant est l'appareil qui demande l'accès, l'authentificateur est le point d'accès ou le commutateur qui relaie cette demande, et le serveur RADIUS l'accepte ou la rejette. Ils partagent le framework EAP, pas un identifiant.
L'index des spécifications IETF EAP décrit le protocole EAP-TLS, défini dans l'IETF RFC 5216, comme une authentification client et serveur basée sur des certificats, incluant une authentification mutuelle, une négociation de suite cryptographique protégée en intégrité, ainsi qu'une dérivation de clés. La spécification a été publiée en mars 2008. En pratique, EAP-TLS nécessite un certificat client délivré via une infrastructure PKI, parallèlement au certificat du serveur RADIUS.
Deux séquences, un cadre
EAP-TLS authentifie les deux extrémités au cours d'un seul échange TLS :
- Le supplant commence EAP avec l'authentificateur, qui relaie la demande vers RADIUS.
- Les certificats du serveur et du client sont vérifiés pendant l'échange TLS.
- L'échange protège la négociation de la suite de chiffrement et dérive les clés, sans envoyer de mot de passe pouvant être hameçonné, rejoué ou attaqué par force brute.
- Un certificat client manquant ou non approuvé entraîne le rejet de l'appareil. Il ne peut pas se rabattre sur la saisie d'un mot de passe.
PEAP crée un tunnel TLS externe qui authentifie le serveur, puis exécute une méthode interne, généralement EAP-MSCHAPv2 ou EAP-GTC. Comme la méthode interne peut utiliser un nom d'utilisateur et un mot de passe, les terminaux n'ont généralement pas besoin de certificats clients. L'index des spécifications IETF EAP décrit également le cadre normalisé utilisé par ces méthodes.
Les utilisateurs ne voient pas le tunnel externe de PEAP. L'identité interne, généralement un nom d'utilisateur et un mot de passe ou un jeton, est envoyée uniquement après l'établissement du TLS. Cela rend PEAP familier pour les supplicants basés sur des annuaires, tout en laissant un mot de passe exposé si le client ne vérifie pas correctement le tunnel.
Le PEAP avec EAP-TLS interne est un cas particulier plus complexe, combinant une méthode de certificat avec un tunnel TLS externe. Un déploiement étiqueté « PEAP » désigne généralement le PEAP-MSCHAPv2.
Où le suppliant détermine le résultat
Un compte-rendu des méthodes EAP pour le sans-fil d'entreprise en explique la différence : EAP-TLS utilise une authentification X.509 mutuelle. RADIUS valide le certificat client, et le client valide le certificat serveur. Aucun mot de passe ne peut être hameçonné, rejoué ou attaqué par force brute. Le compte-rendu précise également que le NIST exige que la station sans-fil et le serveur d'authentification détiennent tous deux des certificats valides.
Avec PEAP, le client doit valider la chaîne de certificats RADIUS et le nom de serveur attendu. Si l'un de ces contrôles est manquant, un point d'accès malveillant peut solliciter un mot de passe d'annuaire. Un profil de supplicant défini sur « ne pas valider » ne protège pas le mot de passe.
Règle pratique : Épinglez le nom du serveur RADIUS et l'AC émettrice dans le profil WiFi. Sans ces vérifications, PEAP peut fournir un mot de passe à un serveur frauduleux.
Les réponses MS-CHAPv2 interceptées peuvent être piratées hors ligne après qu'un attaquant les a obtenues via un tunnel malveillant. La validation du tunnel constitue le contrôle essentiel ; la méthode interne ne permet pas de sécuriser un profil qui accepte un serveur non approuvé. Ce risque lié au mot de passe s'étend au-delà du WiFi. Des rapports concernant les identifiants compromis au sein des PME australiennes soulignent pourquoi un mot de passe d'annuaire réutilisé conserve une grande valeur pour un attaquant.
Attribuez EAP-TLS aux appareils gérés et aux utilisateurs dont vous pouvez gérer le cycle de vie des certificats. Utilisez PEAP là où les utilisateurs ou les appareils ne peuvent pas recevoir et renouveler des certificats de manière fiable, mais imposez la validation du nom de serveur et de l'autorité de certification (CA) via le profil du supplicant. Le compromis opérationnel est direct : les certificats demandent un travail d'enrôlement et de récupération, tandis que les mots de passe vous obligent à gérer la réutilisation et les modifications de comptes. La meilleure méthode dépend de ce que vous pouvez gérer, et non de la désignation d'un gagnant unique pour chaque SSID.
Exigences en matière de certificats avant le déploiement
Confirmez ces six éléments dans un laboratoire avant la première connexion en production. Une chaîne manquante ou un nom erroné ressemblera à « le WiFi est en panne », et non à une erreur de certificat.
- Certificat de serveur RADIUS. Émettez-le depuis votre AC privée. Placez le nom épinglé par le profil du supplicant dans le sujet ou le SAN. Définissez l'usage d'authentification du serveur et fournissez la chaîne intermédiaire complète avec le certificat. Une AC publique qui signerait n'importe quel nom correspondant est un modèle de confiance inadapté pour un nom RADIUS interne.
- Certificat client. Un par appareil ou utilisateur, avec un usage d'authentification client. Placez une identité unique dans le SAN, telle qu'un nom principal d'utilisateur ou un numéro de série d'appareil. Stockez la clé privée dans le TPM ou la Secure Enclave lorsque la plateforme le prend en charge.
- Ancre de confiance. Installez l'AC racine interne ou l'AC émettrice via le profil MDM. Ne dirigez pas les appareils vers une racine publique en espérant que la vérification du nom suffise.
- Validité et renouvellement. Définissez une durée de vie pour le certificat de serveur et pour les certificats clients. Créez une fenêtre de chevauchement afin que le certificat de remplacement soit installé avant l'expiration de l'ancien.
- Révocation. Fournissez au serveur RADIUS un point de terminaison CRL ou OCSP accessible. Décrivez, par écrit, si l'authentification échoue ou se poursuit lorsque ce point de terminaison est hors ligne. Testez le cas hors ligne. Ne le découvrez pas lors d'une micro-coupure WAN.
- Canal d'enrôlement. Distribuez les certificats via SCEP ou un fichier PKCS#12 à travers le MDM. Validez le processus sur un appareil, renouvellement compris, avant de cibler un groupe.
Prenons l'exemple d'une clinique utilisant Okta pour l'identité du personnel et Intune pour les ordinateurs portables. Le nom RADIUS dans le profil doit correspondre au certificat, et le groupe Okta qui doit aboutir sur le VLAN clinique doit être le même groupe que celui utilisé par le MDM pour l'enrôlement. Nos notes sur l'authentification Okta WiFi authentication détaillent ce transfert d'identité sans transformer le laboratoire en un SSID à mot de passe.
Connectez un ordinateur portable de test, révoquez son certificat et confirmez que la tentative d'association suivante échoue avant de toucher à un environnement de production.
Cycle de vie des certificats et effort de déploiement
La sécurité EAP-TLS se transforme en panne lorsqu'un certificat expire, ou lorsqu'un client ne peut pas accéder aux informations de révocation, alors même que le compte utilisateur est parfaitement valide. C'est la question qui mérite d'être posée. DÉCLARER QUE "les certificats sont plus difficiles" n'est pas une architecture cible.
La publication spéciale NIST 800-120 souligne le même enjeu. EAP-TLS requiert une gestion rigoureuse de l'émission, de la distribution, du renouvellement, de la chaîne de confiance et de la vérification de la révocation. Un appareil disposant d'un certificat expiré ou incapable d'atteindre le service de révocation peut perdre son accès réseau, même si l'identité de l'utilisateur reste valide. PEAP authentifie généralement le serveur lors de la phase TLS externe, puis valide un nom d'utilisateur et un mot de passe via une méthode interne telle que MS-CHAPv2, évitant ainsi la gestion du cycle de vie des certificats clients. La simplicité du premier jour déplace ainsi la charge de travail vers les réinitialisations de mot de passe et la gestion des profils incorrects.
Éviter que les certificats ne deviennent la cause des pannes
La réponse à apporter réside dans l'automatisation, et non dans des procédures manuelles rallongées.
- Inscrire via MDM. Déployez simultanément le profil, l'ancrage de confiance et le certificat. La configuration WiFi manuelle est la cause principale du décochage des vérifications du nom de serveur.
- Chevaucher les renouvellements. Installez le nouveau certificat avant que l'ancien n'expire. Un week-end où tous les ordinateurs portables tombent en panne en même temps indique un chevauchement trop court.
- Tester la révocation hors ligne. Sachez si le serveur RADIUS bloque l'accès (fail closed) ou l'autorise (fail open) lorsque les listes CRL ou les répondeurs OCSP ne peuvent pas être interrogés.
- Conserver une procédure de secours. Un équipement défaillant doit disposer d'un moyen de connexion alternatif qui ne soit pas "emprunter le mot de passe PEAP d'un collègue." Un port filaire dédié au support ou un SSID de secours strictement restreint est préférable à un secret partagé écrit sur un tableau blanc.
Purple Access récupère les certificats EAP-TLS de Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru, et Addigy, distribués via SCEP, avec une configuration qui prend cinq à dix minutes une seule fois pour l'organisation plutôt que par appareil. Le réseau sécurisé est sans mot de passe et basé sur des certificats, et un appareil qui ne respecte pas la posture de sécurité est refusé lors de l'authentification grâce à l'accès conditionnel. Il s'agit d'une adhésion soumise à des règles de conformité, et non d'une seconde invite de mot de passe.
PEAP reste le choix le plus simple lorsque la PKI n'est pas suffisamment développée, que les prestataires ne peuvent pas être intégrés au MDM, ou que des environnements BYOD mixtes n'acceptent pas de certificat. Le secteur de la santé, de l'éducation, de l'hôtellerie et d'autres flottes multi-sites sont souvent confrontés à ces trois défis simultanément. Utilisez EAP-TLS pour les appareils gérés de l'entreprise, du personnel et à haut risque. Conservez une alternative strictement contrôlée pour les points terminaux non gérés ou temporaires. L'identité à l'échelle du site est la décision clé, pas un slogan affirmant que TLS a détrôné les mots de passe.
Si RADIUS est lui-même l'élément fragile, un serveur centralisé hébergé élimine la panne du "serveur unique dans le placard du siège". Notre article sur le RADIUS-as-a-Service est l'endroit idéal pour vérifier l'accessibilité et la redondance avant d'incriminer la méthode EAP.
La courte présentation ci-dessous montre l'enrôlement de certificat à côté d'une méthode interne par mot de passe, ce qui illustre le contraste auquel le support informatique est confronté lorsque le renouvellement est en retard.
Révocation, vitesse d'itinérance et prise en charge des clients
La prise en charge et la vitesse sont des questions de recherche. Les supplicants actuels sur Windows, macOS, iOS, Android, et ChromeOS prennent en charge les deux méthodes. C'est le mode de défaillance qui diffère.
EAP-TLS échoue lorsque le profil, l'autorité de certification émettrice ou les dates de validité sont incorrects. PEAP échoue lorsque la méthode interne, le format d'identité ou la vérification du nom de serveur ne correspondent pas à la politique RADIUS. Aucun de ces échecs ne signifie que le point d'accès « ne prend pas en charge l'entreprise ».
La révocation présente la même séparation. Désactiver le certificat d'un appareil isole cet ordinateur portable sans toucher aux autres identifiants de la personne. Réinitialiser un mot de passe d'annuaire impacte chaque client non géré qui l'utilise encore. Une interruption immédiate et spécifique à l'appareil est l'avantage d'EAP-TLS. Les échecs stricts dus à des certificats expirés en sont le coût.
Des handshakes, pas des noms de marques
Un document de l'ACM sur la latence d'authentification sans fil indique que la performance dépend davantage du nombre de handshakes, de l'itinérance, de la validation des certificats et de la latence du backend que du nom de la méthode. L'EAP-TLS standard effectue l'authentification par certificat client et serveur lors de son échange TLS. PEAP établit un tunnel TLS puis exécute l'authentification interne, ajoutant ainsi une phase distincte. La documentation technique Cisco citée dans cette étude précise que PEAP avec EAP-TLS interne implique deux handshakes TLS et peut s'avérer lent lorsqu'une réauthentification complète se produit pendant l'itinérance.
Mesurez ces éléments séparément. Ne désignez pas un gagnant à partir d'un seul temps de connexion moyen.
- Temps d'association à l'IP au 95e percentile
- Authentification complète par rapport à la latence de reprise d'itinérance
- Temps d'aller-retour RADIUS
- Taux d'échec d'authentification
- Échecs de renouvellement de certificat
La reprise de session, le mise en cache PMK ou 802.11r, la joignabilité RADIUS locale et une chaîne de certificats courte influent plus sur ces chiffres que le remplacement d'une suite de chiffrement. PEAP peut sembler simple au premier jour tout en générant des retards dus à des échanges de mots de passe répétés et à la résolution des problèmes utilisateurs. EAP-TLS peut sembler instantané après l'enrôlement, puis échouer brutalement en raison d'un certificat expiré.
| Symptôme | Méthode la plus probable | Cause habituelle | Correctif pratique |
|---|---|---|---|
| Demande de mot de passe répétée près d'un point d'accès inconnu | PEAP | Le supplicant ne valide pas le nom du serveur ou la chaîne de certification | Déployer un profil qui verrouille le nom RADIUS et l'AC |
| Perte d'accès sur un ordinateur portable après un changement de rôle | EAP-TLS | Certificat révoqué ou appareil supprimé de la solution MDM | Confirmer la révocation et réinscrire uniquement cet appareil |
| Équipe entière bloquée un lundi matin | EAP-TLS | Certificats expirés simultanément ou chevauchement de renouvellement trop court | Planifier le renouvellement avant l'expiration et conserver une procédure de secours |
| L'itinérance semble lente uniquement lors de la réauthentification complète | PEAP avec EAP-TLS interne | Deux poignées de main (handshakes) TLS | Privilégier la reprise de session, le dictionnaire PMK ou 802.11r - éviter EAP-TLS interne sauf en cas de nécessité |
| Rejets aléatoires sur un seul site | L'une ou l'autre | Temps d'aller-retour RADIUS ou récupération de la chaîne, pas le nom EAP | Mesurer le RTT et le 95e centile entre l'association et l'IP avant de changer de méthode |
Une itinérance lente sur un site est généralement due à la distance du serveur RADIUS ou à la récupération de la chaîne de certification, et non à la preuve d'un mauvais choix de type EAP.
Attribuer chaque population et prouver la séparation
Un même bâtiment peut accueillir des ordinateurs portables du personnel, un invité en conférence, le Mac d'un prestataire et une caisse enregistreuse. Ils ne doivent pas partager le même type d'identifiant. Cartographiez chaque population, pilotez un site à côté du réseau que vous exploitez déjà, et évaluez les tickets ainsi que le journal d'authentification avant de dupliquer la configuration.
| Population | Utiliser | Ne pas utiliser | Pourquoi |
|---|---|---|---|
| Personnel géré par MDM et utilisateurs privilégiés | EAP-TLS sur un SSID WPA-Enterprise | PSK partagé ou PEAP | Identité par certificat, VLAN par groupe, l'accès prend fin lorsque le compte est désactivé |
| Invités et visiteurs de passage | Captive Portal ou Passpoint sur un VLAN invité | Enrôlement PEAP ou EAP-TLS à l'accueil | Aucun cycle de vie de certificat et aucun mot de passe d'annuaire à hameçonner |
| Ordinateurs portables non gérés et prestataires | PEAP-MSCHAPv2 uniquement avec validation forcée du serveur | EAP-TLS si vous ne pouvez pas les enrôler ou les renouveler | Les mots de passe existent déjà, mais le profil doit vérifier le certificat RADIUS |
| Imprimantes, téléviseurs, caisses, vidéosurveillance et capteurs | PSK par équipement avec son propre VLAN | EAP-TLS ou mot de passe PEAP partagé | Ces équipements ne peuvent généralement pas stocker de certificats, et une clé partagée est difficile à renouveler |
| Site mixte dans un même bâtiment | Séparation par identité sur des VLAN distincts | Un seul SSID et une seule méthode pour tout le monde | Le personnel, les invités et les objets présentent des failles différentes et ne doivent pas partager le même type d'identifiant |
Qui conserve les mots de passe et qui doit impérativement y renoncer
Le personnel géré et les utilisateurs privilégiés bénéficient d'EAP-TLS sur un SSID WPA-Enterprise. Le personnel d'entretien, de réception et d'exploitation peut s'authentifier avec des certificats issus d'un MDM via SCEP, atterrir sur un VLAN par groupe d'annuaire et perdre son accès lorsque le compte est désactivé. Un PSK partagé ou un mot de passe PEAP recrée exactement ce que vous essayiez de retirer.
Les invités et visiteurs restent sur un Captive Portal ou Passpoint, sur un VLAN invité. N'enrôlez pas de certificats à la réception et ne les mettez pas sur PEAP. Il n'y a aucun cycle de vie que vous allez gérer, et il y a un mot de passe d'annuaire que vous ne voulez pas voir hameçonné. Un profil Passpoint peut se reconnecter lors de la prochaine visite sans générer de nouveau ticket.
Les ordinateurs portables non gérés et les prestataires peuvent rester sur PEAP-MSCHAPv2, et uniquement si le profil impose la validation du serveur. Si vous ne pouvez pas les enrôler ou les renouveler, EAP-TLS les bloquera. Si vous ne pouvez pas imposer la vérification du serveur, le risque lié au mot de passe l'emporte sur la commodité, et ils ne devraient pas du tout se trouver sur le SSID du personnel.
Les imprimantes, téléviseurs, caisses, TPE, caméras CCTV, capteurs et contrôleurs d'accès reçoivent une clé iPSK individuelle par appareil et leur propre VLAN. Ils ne peuvent généralement pas stocker de certificats. Un mot de passe PEAP partagé réintroduit le problème de la clé partagée. La norme PCI DSS v4.0.1 Req 2.3.2 exige que les clés sans-fil soient modifiées lorsque toute personne les connaissant quitte l'entreprise, ce qu'une clé partagée rend irréaliste. La technologie iPSK est adaptée à ces équipements. Les téléviseurs des chambres, les thermostats et les caisses ont leur place sur des VLAN liés à une clé et totalement invisibles pour les visiteurs.
Faites-en la preuve sur un site
Appliquez la nouvelle conception sur les points d'accès déjà présents sur le site, en parallèle du réseau actuel. Jugez-en sur la réduction des tickets et les preuves d'audit, pas sur une démonstration de connexion.
Exigez un journal d'authentification qui enregistre chaque acceptation et rejet avec l'identité, l'appareil, le statut d'enrôlement MDM, la méthode, le point d'accès, l'SSID, le site, le VLAN, le rôle, le motif et l'heure. Ce même journal constitue le jeu de preuves pour les contrôles d'accès et de journalisation ISO 27001 ainsi que pour les exigences 8 et 10 de PCI-DSS. Sans MDM, verrouillez d'abord les profils PEAP et ne planifiez les certificats que pour la population gérée.
Nous pouvons organiser cette séparation en trois réseaux par établissement. Les clients utilisent le Captive Portal, incluant une vérification de la chambre via le PMS lorsque l'établissement en dispose. Le personnel utilise EAP-TLS ou Passpoint. Les objets connectés utilisent des clés par appareil. Le service RADIUS basé sur le cloud oriente chaque appareil vers le bon réseau et VLAN selon son identité, et rejette un départ dont le compte est désactivé. La trajectoire de migration pour abandonner un mot de passe partagé par le personnel est identique à celle décrite dans notre guide pour migrer le WiFi du personnel multi-site vers le 802.1X.
Je commencerais le pilote avec l'SSID du personnel géré et les clés par appareil pour les caisses enregistreuses, et je laisserais les prestataires sur un profil PEAP validé jusqu'à ce que l'enrôlement soit effectif. Une méthode unique pour tout le monde paraît plus propre sur un schéma, mais échoue de trois manières différentes sur le terrain.
Purple Access exécute le WiFi du personnel basé sur des certificats et des clés par appareil pour les objets connectés sur les points d'accès que vous possédez déjà, transformant l'arbitrage EAP-TLS vs PEAP en un choix de population plutôt qu'en un pari à l'échelle de toute l'infrastructure. Vous pouvez valider les accès ouverts, sécurisés et iPSK sur un seul site, puis évaluer les tickets et le journal d'authentification avant un déploiement plus large. Visitez Purple Access pour cartographier vos réseaux personnel, invités et objets connectés.
