Authentification WiFi basée sur des certificats : guide EAP-TLS
Published
Un collaborateur quitte l'entreprise et votre équipe doit décider s'il faut à nouveau modifier le mot de passe du WiFi du personnel WiFi. Le modifier implique de reconnecter les ordinateurs portables, les téléphones, les tablettes de la réception et les équipements que personne ne se souvient avoir configurés. Ne pas le modifier signifie accepter qu'une personne externe à l'organisation sache toujours comment se connecter.
L'authentification basée sur certificat WiFi vous offre un meilleur moyen d'identifier les appareils de confiance. Cependant, elle modifie également la charge de travail de votre équipe : au lieu de distribuer des mots de passe, vous gérerez les chaînes de confiance, le renouvellement des certificats, la révocation et les appareils réinsérés en stock pendant des mois. L'amélioration de la sécurité est réelle. Un fonctionnement fiable nécessite bien plus que la simple sélection de EAP-TLS dans un profil sans fil.
Table des matières
- Ce que signifie l'authentification WiFi basée sur les certificats
- Fonctionnement du handshake EAP-TLS étape par étape
- Comparaison des certificats avec les mots de passe partagés et PEAP
- Création de l'AC et approvisionnement des certificats via MDM
- Gestion du cycle de vie des certificats, de l'émission au renouvellement
- Révocation de l'accès en cas de perte d'appareil ou de départ d'utilisateur
- Éligibilité des appareils et gestion des exceptions
- Confirmer votre plan de certificats avant le déploiement
Ce que signifie l'authentification WiFi basée sur des certificats
L'authentification WiFi basée sur certificat remplace un mot de passe WiFi partagé par un certificat numérique individuel, que le réseau vérifie avant d'accorder l'accès. Pensez au code d'accès partagé d'une porte de bureau par rapport à un badge d'employé. Avec le code, tout le monde prouve qu'il connaît le même secret. Avec un badge, le service de sécurité peut identifier un identifiant particulier et l'annuler de manière indépendante.
Prenons l'exemple d'un ordinateur portable géré devant accéder au réseau du personnel. Son certificat identifie l'équipement ou son utilisateur assigné, et sa clé privée protégée lui permet de prouver qu'il détient cet identifiant. Le certificat lui-même n'est pas un mot de passe secret, et la simple copie du certificat public ne fournit pas la clé privée correspondante.
Le schéma montre comment les identifiants individuels remplacent le mot de passe commun.
Où s'intègrent les composants
Le cadre sous-jacent est IEEE 802.1X, initialement développé pour l'Ethernet filaire et adapté aux réseaux LAN sans fil. Présentation de Microsoft sur IEEE 802.1X authentification) décrit le cadre et le rôle de l'authentification centralisée via RADIUS.
Le point d'accès contrôle les admissions, tandis que le service RADIUS évalue la demande d'authentification. EAP-TLS est la méthode d'authentification basée sur les certificats acheminée via cette configuration. L'appareil et le serveur d'authentification se valident mutuellement avant d'établir le matériel de clé pour la connexion.
Maintenir ces composants distincts :
- Certificat d'appareil : Identifie l'équipement terminal ou l'utilisateur et fonctionne avec une clé privée conservée par l'appareil.
- Certificat du serveur d'authentification : Permet à l'appareil de vérifier qu'il communique avec un service d'authentification approuvé.
- Autorité de certification : Émet des certificats que chaque partie peut valider via une chaîne de confiance explicitement approuvée.
L'appareil et le serveur n'ont pas nécessairement besoin de certificats provenant de la même autorité d'émission. L'important est que chaque partie fasse confiance à l'émetteur approprié et applique la bonne politique de validation.
Règle pratique : Considérez les certificats comme un système d'identité réseau, et non comme des mots de passe complexes.
Cette distinction modifie la façon dont vous gérez la perte d'un ordinateur portable. Vous pouvez révoquer son identifiant sans remplacer ceux présents sur les équipements de tous les autres collaborateurs. Cependant, la possession d'un certificat valide établit une identité, pas une autorisation illimitée. Votre politique d'accès doit toujours déterminer ce que cette identité peut atteindre.
Fonctionnement étape par étape de l'échange de clés EAP-TLS
Une connexion implique le demandeur d'accès (supplicant) de l'appareil, le point d'accès agissant comme authentificateur, et le serveur d'authentification. Le demandeur d'accès est le composant du système d'exploitation qui gère l'authentification réseau de l'entreprise.
Ce flux simplifié présente les principaux transferts plutôt que l'ensemble des messages du protocole.
Suivez l'échange et ses points de défaillance
L'authentification mutuelle et la dérivation de clés sous-jacentes à cet échange sont définies dans la spécification EAP-TLS, RFC 5216.
L'appareil s'associe au point d'accès. Il initie l'échange d'authentification d'entreprise et fournit une identité. L'association seule n'accorde pas d'accès réseau normal. Un paramètre de sécurité sans fil incorrect peut empêcher l'appareil d'atteindre l'étape d'authentification par certificat.
Le point d'accès retransmet les messages EAP à RADIUS. Il transmet l'échange entre le terminal et le service d'authentification au lieu de délivrer lui-même le certificat d'appareil. Un problème de connectivité RADIUS ou un point d'accès mal enregistré peut interrompre l'échange à ce stade.
Le serveur présente son certificat. L'appareil vérifie la chaîne de certificats, la validité et l'identité attendue du serveur. Un émetteur non approuvé, une chaîne incomplète ou un nom de serveur inattendu doit amener l'appareil à refuser la connexion.
L'appareil présente son certificat client. Le serveur valide l'identifiant, vérifie les informations de révocation applicables et évalue l'identité. Un certificat manquant ou une clé privée inaccessible peut ressembler à un échec de connexion générique pour l'utilisateur, même si les journaux du serveur indiquent une cause spécifique.
L'échange TLS établit des éléments de chiffrement partagés. Le terminal doit prouver la possession de sa clé privée, et non simplement présenter un fichier de certificat. Des paramètres cryptographiques incompatibles peuvent empêcher la finalisation, même si les deux certificats sont valides par ailleurs.
RADIUS renvoie le résultat d'authentification et les attributs de politique. Une acceptation peut inclure une attribution de VLAN ou d'autres attributs d'autorisation pris en charge. Une authentification réussie suivie d'une connexion inutilisable peut indiquer un problème de VLAN ou de politique en aval plutôt qu'un problème de certificat.
Configurez le client pour vérifier le serveur
Dans le profil du demandeur d'accès (supplicant), sélectionnez explicitement EAP-TLS, configurez l'AC de confiance et spécifiez les noms de serveurs RADIUS attendus. Conservez la validation du certificat du serveur activée. Ne laissez pas les utilisateurs ignorer un avertissement simplement pour se connecter.
Utilisez cette vidéo parallèlement au flux de protocole lors des discussions sur l'échange avec votre équipe.
Chaque connexion dépend de la présence, de l'accessibilité et de la validité des identifiants au moment de l'authentification. Le dépannage nécessite donc des preuves provenant à la fois du demandeur d'accès (supplicant) et de RADIUS, et pas seulement d'un tableau de bord de point d'accès indiquant qu'un client n'a pas pu se connecter.
Comparaison des certificats avec les mots de passe partagés et PEAP
WiFi méthodes d'authentification selon les mêmes critères
| Méthode | Identifiant sur l'appareil | Portée de la révocation | Responsabilité | Effort de configuration |
|---|---|---|---|---|
| Phrases secrètes partagées WPA2 ou WPA3-Personal | Une seule phrase secrète connue de tous les utilisateurs | Modifie la clé pour tout le monde | Aucune à partir de l'identifiant partagé lui-même | Faible |
| WPA2-Enterprise avec PEAP-MSCHAPv2 | Nom d'utilisateur et mot de passe par utilisateur | Désactive un compte | Par utilisateur | Moyen |
| EAP-TLS sur WPA2 ou WPA3-Enterprise | Certificat client unique et clé privée par appareil | Révoque un certificat | Par appareil et utilisateur lors du mappage | Élevé, nécessite une PKI et un provisionnement géré |
| WPA3-Enterprise 192 bits avec EAP-TLS | Certificat répondant aux exigences cryptographiques du profil | Révoque un certificat | Par appareil et utilisateur lors du mappage | Élevé, plus vérifications de compatibilité des chiffrements |
EAP-TLS n'est pas synonyme de WPA3. Le registre de certification de la Wi-Fi Alliance identifie EAP-TLS parmi les méthodes d'authentification d'entreprise prises en charge. L'authentification par certificat est un choix d'authentification d'entreprise, tandis que le profil WPA détermine également les exigences de sécurité sans fil.
Comparez le type d'identifiant, pas seulement la désignation
Une phrase de passe partagée prouve la connaissance d'un secret commun. Elle ne permet pas d'identifier l'employé qui l'a fournie, même si l'équipement réseau peut toujours enregistrer les détails de la connexion. Les départs de personnel deviennent délicats, car remplacer l'identifiant implique de mettre à jour chaque appareil qui l'utilise.
PEAP-MSCHAPv2 passe à des noms d'utilisateur et des mots de passe individuels. Il utilise un tunnel TLS authentifié par le serveur pour protéger l'échange d'authentification interne, l'évaluation correcte du serveur reste donc importante. Cela peut fournir des enregistrements utiles par utilisateur, mais les changements de mot de passe et les problèmes de compte font toujours partie du support réseau sans fil.
Avec EAP-TLS, le point de terminaison utilise son certificat et sa clé privée au lieu d'un mot de passe de compte lors de l'authentification. Cela donne aux administrateurs un identifiant spécifique à l'appareil à gérer, à condition que l'inventaire associe correctement les certificats aux points de terminaison et à leurs propriétaires.
Choisissez la méthode dont votre équipe peut réellement gérer le cycle de vie des identifiants, et non simplement l'option la plus sécurisée sur le papier dans le menu du contrôleur.
Adapter la méthode à la population
Les phrases de passe partagées constituent une mauvaise option par défaut pour l'accès du personnel géré, pour lequel le retrait individuel et la responsabilité sont essentiels. Même pour les invités et les équipements à faible risque, un mot de passe commun nécessite une politique stricte de distribution et de remplacement.
Les certificats conviennent aux ordinateurs portables et téléphones gérés, car vous pouvez les déployer via un système de gestion existant. Le profil d'entreprise à niveau d'assurance plus élevé ajoute des travaux de compatibilité ; il ne supprime aucune responsabilité liée au cycle de vie. PEAP peut rester une option de migration lorsque des comptes individuels existent mais que le déploiement de certificats n'est pas prêt, plutôt qu'un motif de report indéfini d'une architecture d'accès basée sur l'identité.
Création de l'AC et fourniture des certificats via MDM
Un déploiement manageable commence par une infrastructure à clés publiques (PKI) dont la responsabilité est clairement définie. Une hiérarchie courante maintient une autorité de certification racine hors ligne et utilise une CA d'émission pour la délivrance quotidienne des certificats. Un service PKI géré peut remplir ces rôles sans que votre équipe n'ait à exploiter chaque composant localement.
L'AC émettrice signe les certificats d'appareil et de serveur. RADIUS doit faire confiance à la chaîne de certificats client, tandis que les points de terminaison doivent faire confiance à la chaîne de serveurs appropriée. Ne partez pas du principe que l'installation d'un certificat racine configure automatiquement le reste de la politique sans fil.
Choisissez les profils avant de délivrer les certificats
Un modèle d'équipement nécessite une utilisation d'authentification client, une identité d'équipement ou d'utilisateur que votre politique peut résoudre, ainsi qu'une période de validité régie par votre conception de renouvellement et de reprise.
Profils de certificats par niveau de sécurité
| Profil | Clé et algorithme | Validité type | Cas d'usage |
|---|---|---|---|
| Ordinateur portable ou téléphone géré standard | Algorithme approuvé par l'organisation, pris en charge sur l'ensemble du parc | Définie par la politique de renouvellement et de récupération | Parcs mixtes sur WPA2-Enterprise |
| Appareil géré avec restrictions renforcées | Modèle plus robuste approuvé après tests des points d'accès | Définie par la politique et la capacité de renouvellement | Parcs modernes avec un firmware à jour |
| WPA3-Enterprise 192 bits | ECDSA P-384 ou RSA 3072 ou supérieur | Définie par la politique et la capacité de renouvellement | Sites nécessitant une assurance plus élevée après tests de compatibilité |
| Appareil sans écran ou hérité | Souvent non pris en charge | Cycle de vie pris en charge par le fournisseur ou expiration de l'exception | Procédure d'exception |
Le guide de déploiement de la WiFi Alliance précise que le mode 192 bits WPA3-Enterprise restreint l'authentification à EAP-TLS et utilise des suites AES-256-GCM avec des paramètres de courbe elliptique P-384 ou des tailles de module RSA/DH d'au moins 3072 bits. Le profil d'assurance supérieur du tableau doit donc être vérifié par rapport à l'ensemble de la suite sélectionnée, et pas seulement par rapport à l'étiquette de clé du certificat.
Les modèles de certificats, les logiciels RADIUS, les demandeurs et les fournisseurs cryptographiques doivent concorder. Un point de terminaison prenant en charge le EAP-TLS ordinaire peut tout de même échouer sous ce profil plus strict.
Déployer simultanément la confiance, les identifiants et la configuration
Avec SCEP, le profil de gestion ordonne à l'appareil de générer une paire de clés et de demander un certificat. L'AC signe la demande ; l'appareil conserve sa clé privée dans un espace de stockage protégé. Ne distribuez pas les mêmes certificat client et clé privée à plusieurs machines.
Déployez les dépendances dans un ordre contrôlé :
- Confiance en premier : Installez les certificats CA de confiance requis.
- Identifiants ensuite : Fournissez la configuration SCEP et confirmez la bonne émission.
- Profil sans fil en dernier : Référencez l'identifiant client visé et les paramètres de validation du serveur.
Conservez un ciblage de groupe cohérent sur l'ensemble des profils dépendants. Utilisez la comparaison de profils de certificat MDM WiFi pour examiner les différences de plateforme avant de standardiser le déploiement. Fournissez également une connexion d'enrôlement qui ne dépend pas du certificat que l'appareil tente encore d'obtenir.
Gestion du cycle de vie des certificats, de l'émission au renouvellement
Un ordinateur portable qui se connecte avec succès aujourd'hui peut échouer après être resté dans un placard pendant sa période de renouvellement. Le point d'accès peut être en parfait état, le mot de passe n'a pas changé et l'utilisateur n'a commis aucune erreur. Le point de terminaison ne dispose simplement plus d'un identifiant valide.
Le guide des exigences EAP du NIST décrit la nécessité de approvisionner les certificats avant l'authentification, qu'ils soient disponibles pendant l'échange et vérifiables, y compris leur statut de révocation. Ces exigences intègrent les dépendances du cycle de vie à la disponibilité du réseau.
Ce chronogramme est utile pour attribuer la responsabilité au-delà du déploiement initial.
Attribuer un contrôle opérationnel à chaque étape
| Étape | Contrôle | Défaillance évitée |
|---|---|---|
| Inscription | Surveiller l'enregistrement MDM et le ciblage des profils | L'équipement ne reçoit jamais d'instruction d'inscription |
| Émission | Valider les autorisations des modèles et les résultats des demandes | L'AC rejette les demandes ou émet des certificats inutilisables |
| Déploiement | Vérifier l'installation et l'accès protégé à la clé privée | Le certificat existe mais le demandeur ne peut pas l'utiliser |
| Renouvellement | Commencer tôt, surveiller l'achèvement et autoriser un chevauchement testé | Les équipements atteignent l'expiration sans certificat de remplacement |
| Expiration | Alerter les propriétaires et fournir une voie de récupération restreinte | Les équipements expirés n'ont aucun moyen de récupération |
| Mise hors service | Rétrograder les identifiants et supprimer les entrées d'inventaire obsolètes | Le matériel mis hors service conserve une identité acceptée |
Le renouvellement nécessite une preuve d'achèvement, et pas seulement un paramètre d'automatisation activé. Suivez si un certificat de remplacement a été émis, installé et utilisé avec succès. Pendant la période de chevauchement, confirmez que le demandeur sélectionne un identifiant approprié au lieu de choisir à plusieurs reprises un identifiant obsolète.
Planifiez la gestion des appareils qui ne sont pas en ligne
Définissez la fenêtre de renouvellement en fonction du comportement réel des appareils. Un équipement utilisé de manière saisonnière ou conservé comme pièce de rechange peut nécessiter un processus de récupération différent de celui d'un ordinateur portable qui se connecte quotidiennement. Ne partez pas du principe qu'un point de terminaison hors ligne peut se renouveler simplement parce que son ancien certificat figure toujours dans le MDM.
Maintenez un inventaire liant le numéro de série du certificat, l'identifiant du point de terminaison, le propriétaire, l'émetteur, l'expiration et l'état de renouvellement. Incluez les certificats de l'AC émettrice et du serveur d'authentification, car leur remplacement peut affecter une population beaucoup plus large.
Une tâche de renouvellement qui s'est exécutée avec succès ne garantit pas qu'un appareil puisse s'authentifier avec son certificat de remplacement.
Testez les erreurs d'horloge système, la réinstallation complète des systèmes d'exploitation et les modifications de la chaîne d'AC. Une réinstallation peut supprimer la clé privée ; une erreur d'horloge peut donner l'impression qu'un certificat valide ne l'est pas encore ; une modification de la chaîne peut priver les points de terminaison de la confiance requise.
Attribuez des responsables désignés pour les échecs impliquant le MDM, la PKI et les services réseau. Sinon, chaque équipe peut signaler que son propre système fonctionne correctement alors que le terminal reste déconnecté. EAP-TLS transforme le risque d'interruption en un problème d'inventaire, d'automatisation et de gestion des dépendances. Cela ne supprime pas ce risque.
Révocation des accès en cas de perte d'appareils ou de départ d'utilisateurs
Le compte d'annuaire d'un collaborateur quittant l'entreprise est désactivé, mais son ordinateur portable contient toujours un certificat qui n'a pas expiré. La possibilité de se reconnecter dépend de votre intégration d'autorisation et de vos contrôles de révocation. Désactiver un compte et révoquer un certificat sont des actions distinctes, à moins que votre flux de travail configuré ne les relie explicitement.
Définissez le résultat du départ (offboarding) en termes opérationnels : les nouvelles authentifications doivent échouer, l'inscription ne doit pas délivrer d'identifiants de remplacement et les sessions existantes doivent se terminer via un mécanisme pris en charge. Un ticket RH clôturé ne prouve aucun de ces résultats.
Comprendre les vérifications de statut
Une liste de révocation de certificats, ou CRL, publie les certificats qu'un émetteur a retirés. L'Online Certificate Status Protocol, ou OCSP, permet à un système de validation de demander le statut d'un certificat auprès d'un répondeur.
Le composant qui valide le certificat applique la politique de vérification de statut correspondante. Pour les certificats clients, il s'agit généralement du service d'authentification et non du point d'accès. Si les informations de statut ne sont pas disponibles, une politique « fail-closed » peut bloquer des appareils autrement valides, tandis qu'une politique « fail-open » peut accepter un identifiant dont la révocation ne peut pas être confirmée.
Rendez ce choix explicite. Intégrez les informations de statut en cache, les délais de publication et la disponibilité des répondeurs dans vos tests plutôt que de supposer que cliquer sur « révoquer » modifie immédiatement chaque décision d'authentification.
Utiliser une procédure complète en cas de perte d'appareil
Pour un ordinateur portable manquant, coordonnez les actions plutôt que de traiter chacune d'elles comme l'étape finale d'une équipe distincte :
- Identifier et retirer l'identifiant. Associer le point d'accès à son numéro de série de certificat réel et révoquer l'identifiant correspondant.
- Empêcher toute réémission. Désactiver l'éligibilité à l'enrôlement de l'appareil et appliquer le processus d'expulsion ou de retrait MDM approprié.
- Interrompre l'accès actif. Utiliser les commandes de déconnexion de session prises en charge, y compris le Changement d'autorisation RADIUS lorsque l'infrastructure le permet.
- Vérifier le résultat. Confirmer que la session a pris fin et qu'une nouvelle tentative d'authentification est rejetée.
La révocation seule ne met pas nécessairement fin à une session sans fil établie. Sur les équipements ne disposant pas d'un mécanisme de déconnexion pris en charge, la session peut se poursuivre jusqu'à la reconnexion, la réauthentification ou une autre limite de session appliquée. Consignez cette limitation dans la procédure d'incident.
Votre registre d'audit doit inclure :
- Identité de l'identifiant : Identifiant de l'appareil, numéro de série du certificat et propriétaire associé.
- Preuve de décision : Motif de la révocation, opérateur et heure de l'action.
- Preuve d'application : Heure de fin de la session et résultat du rejet ultérieur.
- Exposition restante : Toute session qui n'a pas pu être interrompue de manière forcée et la mesure de confinement prise.
Planifiez des exercices de révocation. Exécutez-les après des modifications de la politique d'authentification ainsi que lors de tests opérationnels de routine, afin qu'un incident réel de perte d'appareil ne soit pas votre premier essai de validation de l'ensemble de la chaîne.
Planification de l'éligibilité des appareils et des exceptions
Classes d'appareils et leur compatibilité avec EAP-TLS
| Classe d'équipement | Adéquation EAP-TLS | Alternative typique | Question clé à poser |
|---|---|---|---|
| Ordinateurs portables et téléphones gérés | Élevée | Aucune nécessaire, inscription MDM | L'inscription MDM est-elle fiable ? |
| Tablettes d'entreprise et bornes interactives | Bonne lorsqu'elles sont gérées par MDM | Clé spécifique à la borne autonome SSID | La clé privée peut-elle résider dans un stockage sécurisé ? |
| Capteurs IoT autonomes | Faible sans micrologiciel adapté | Clé par équipement sur un VLAN isolé | Le micrologiciel prend-il en charge 802.1X ? |
| Systèmes de salle, AV et visioconférence | Support spécifique au fournisseur | SSID dédié avec clé par équipement | Le fournisseur peut-il installer et renouveler les certificats ? |
| Équipements médicaux | Souvent limitée | Réseau segmenté avec méthode approuvée par le fournisseur | L'équipement est-il certifié pour cette méthode ? |
| Terminaux sur systèmes d'exploitation hérités | Non pris en charge lorsque les fonctionnalités requises sont absentes | VLAN de quarantaine avec exception limitée dans le temps | Quand l'exception est-elle réexaminée ? |
La contrainte fondamentale est que chaque EAP-TLS client a besoin de son propre certificat, et pas seulement d'une confiance envers le serveur. Le guide du NIST sur les réseaux sans fil distingue cette exigence de certificat client de l'authentification par certificat basée uniquement sur le serveur.
Un appareil a donc besoin d'un demandeur d'accès (supplicant) fonctionnel, d'une protection appropriée de la clé privée et d'un moyen pris en charge pour recevoir et remplacer son identifiant. Une fiche technique indiquant « WiFi entreprise WiFi pris en charge » ne suffit pas à établir ces capacités.
Tester l'ensemble du cycle de vie de l'équipement
Pour un système de salle de réunion, demandez au fournisseur de faire la démonstration de l'installation, du renouvellement et de la récupération d'un certificat après une réinitialisation des paramètres d'usine. Une interface web acceptant le chargement d'un certificat peut résoudre l'intégration initiale sans pour autant résoudre la maintenance.
Pour les équipements médicaux et opérationnels, préservez les exigences d'assistance du fournisseur. Ne modifiez pas la méthode d'authentification d'un appareil de production uniquement parce qu'un autre produit du même fabricant la prend en charge.
Les appareils personnels nécessitent une décision d'éligibilité distincte. Votre conception d'intégration BYOD doit établir quelle gestion ou installation de profil est acceptable avant d'exiger des utilisateurs qu'ils s'inscrivent.
Définir des exceptions strictes et responsabilisées
Un appareil incapable d'utiliser des certificats ne doit pas hériter des autorisations d'accès d'un ordinateur portable d'employé géré. Attribuez un propriétaire défini à son identifiant alternatif et limitez le réseau aux destinations qui lui sont strictement nécessaires.
Consigner les informations suivantes pour chaque exception :
- Raison technique : La fonctionnalité manquante ou la restriction du fournisseur, appuyée par une vérification de la configuration.
- Mesures compensatoires : La segmentation, les services autorisés et l'alternative révocable individuellement.
- Date de révision : Une décision planifiée de renouveler, modifier ou supprimer l'exception.
- Plan de remplacement : La mise à jour du firmware, la méthode d'intégration prise en charge ou le remplacement du matériel qui y mettrait fin.
Évitez de transformer un réseau de quarantaine temporaire en un emplacement permanent pour des équipements non identifiés. Une exception sans propriétaire ni condition de sortie devient une politique d'accès non documentée. L'approche défendable ne consiste pas à imposer des certificats à tout prix ; elle repose sur une authentification forte des équipements gérés, associée à des alternatives délibérément restreintes.
Confirmez votre plan de certificats avant le déploiement
Une démonstration réussie prouve qu'un ordinateur portable en bon état peut se connecter. Un pilote utile montre ce qui se produit lorsque l'enrôlement échoue, qu'un identifiant expire, qu'un appareil est retiré ou qu'une dépendance devient indisponible. Validez le modèle opérationnel, pas seulement la première poignée de main réussie.
Choisissez un site pilote et identifiez les classes d'équipements concernées avant de modifier l'accès en production. Répertoriez les capacités des points d'accès, le comportement des demandeurs d'accès (supplicants) et les versions de micrologiciel. Lorsqu'un profil de garantie supérieure est requis, validez le modèle de certificat sélectionné, les vérifications de la chaîne de certificats et l'utilisation étendue de la clé par rapport à des terminaux représentatifs.
Concrétisez l'examen de préparation de cette semaine
Utilisez cette liste de contrôle pour identifier les responsables manquants et les hypothèses non vérifiées.
- Confirmer la prise en charge des équipements : vérifiez que chaque équipement concerné peut stocker et utiliser une clé privée protégée, et pas seulement importer un certificat.
- Confirmer la confiance et le renouvellement : attribuez des responsables pour la chaîne d'AC, le service d'inscription, la surveillance des renouvellements et la voie de récupération.
- Tester l'application : démontrez l'acceptation, le rejet, la révocation et la fin de session active prise en charge.
- Approuver les exceptions : attribuez à chaque classe non prise en charge une alternative restreinte, un responsable désigné et une date de révision.
- Définir des alertes exploitables : acheminez les événements d'expiration imminente et d'échec de renouvellement vers une personne en mesure de les résoudre.
Utilisez une RADIUS procédure de test d'authentification répétable afin que les ingénieurs recueillent des preuves comparables. Enregistrez l'état du client, le résultat attendu, le résultat réel et le code d'erreur correspondant.
Évaluer le pilote selon sa prise en charge
Exécutez le chemin de certificat à côté du réseau existant avec une procédure de retour en arrière (rollback) définie. Incluez l'inscription à distance, un point de terminaison reconstruit, une pièce de rechange hors ligne et les systèmes d'exploitation pris en charge par votre assistance technique. Ne choisissez pas uniquement des ordinateurs portables récemment configurés.
Examinez les tickets d'assistance en parallèle des journaux d'authentification. Séparez les échecs de certificat des problèmes de couverture sans fil, d'attribution d'adresses et de VLAN, afin que l'équipe ne repense pas la PKI pour résoudre une panne sans rapport.
L'acceptation du pilote doit signifier que les appareils gérés se connectent normalement sans intervention de l'utilisateur, que les échecs ont des causes identifiées et que le retrait d'accès peut être démontré. Conservez les preuves des tentatives réussies et rejetées, avec suffisamment de contexte d'identité pour expliquer la décision.
Définissez la date de révision du pilote avant son démarrage. Confirmez le site, les classes d'équipements, les propriétaires et les critères d'acceptation cette semaine, puis n'étendez le périmètre qu'après la résolution des défaillances et la preuve de la reprise par l'équipe. Un déploiement plus restreint avec un renouvellement et une révocation fiables constitue une meilleure base qu'un déploiement large que personne ne peut réparer en toute confiance.
Purple Access propose un accès WiFi du personnel WiFi basé sur des certificats via EAP-TLS distribués par MDM, ainsi qu'un accès invités et par appareil sur les points d'accès que vous possédez déjà. Visitez Purple Access pour planifier un pilote sur un site, valider le certificat et les parcours d'exception, et évaluer le résultat sur les tickets d'assistance et les preuves d'audit avant d'étendre le déploiement.
