Comment révoquer l'accès WiFi lorsqu'un employé s'en va

Bienvenue dans ce point technique sur la révocation de l'accès WiFi lors du départ d'un employé. Le problème semble souvent moins important qu'il ne l'est en réalité. Un employé part le vendredi. Son responsable désactive son adresse e-mail et récupère son ordinateur portable. Pourtant, son téléphone ou son appareil personnel peut toujours se connecter au WiFi du personnel le lundi. Dans un hôtel, cela peut placer un ancien travailleur à proximité de systèmes opérationnels. Dans un réseau de points de vente, cela peut donner accès à un réseau du personnel dans de nombreux magasins. Dans un stade ou un centre de conférences, cela peut rendre la gestion d'une journée d'événement chargée plus difficile. La question immédiate n'est pas de savoir si la personne qui part connaît un mot de passe. Il s'agit de savoir si votre WiFi peut identifier cette personne en tant qu'identité distincte, et refuser cette identité sans perturber tous les autres utilisateurs. Un simple mot de passe WPA2 partagé ne permet pas de faire cela. Chaque personne possède le même identifiant. Une fois que ce mot de passe a été partagé avec un collaborateur sur le départ, le réseau n'a aucun moyen simple de le distinguer de tous les employés autorisés qui le connaissent également. La réponse pratique consiste à renouveler le mot de passe à l'échelle de l'entreprise, puis à effectuer une mise à jour sur chaque appareil approuvé. Cela est coûteux sur le plan opérationnel, génère des tickets d'assistance et est souvent retardé. Ce n'est pas un contrôle de départ crédible le jour même pour un parc de sites distribués. Il existe trois modèles crédibles. Le premier est le 802.1X par personne avec EAP-TLS. Le deuxième est l'iPSK, parfois appelé clé pré-partagée individuelle. Le troisième est le déprovisionnement piloté par le fournisseur d'identité à l'aide de SCIM. Vous pouvez combiner ces modèles. Le choix de conception central reste le même : rendre l'identifiant d'accès attribuable à une personne ou à un appareil géré, puis faire de la suppression un événement contrôlé et enregistré. Commençons par le 802.1X et l'EAP-TLS. L'IEEE 802.1X est le framework de contrôle d'accès au réseau. Il sépare l'appareil qui demande à se connecter, l'authentificateur en périphérie du réseau et le service d'authentification back-end. EAP-TLS est une méthode de protocole d'authentification extensible qui utilise des certificats pour l'authentification mutuelle et la dérivation de clés. En clair, l'appareil prouve la possession d'un certificat et le réseau prouve sa propre identité au cours du même échange d'authentification. Ce modèle convient aux appareils gérés du personnel et aux réseaux à haute assurance. L'action en cas de départ d'un employé ne consiste pas à modifier un mot de passe partagé. Elle consiste à désactiver l'identité et à révoquer, refuser ou supprimer d'une autre manière le droit du certificat à s'authentifier. Votre conception de validation de certificats et RADIUS doit être capable de reconnaître ce changement lorsqu'un appareil s'authentifie. Ne confondez pas l'expiration d'un certificat avec sa révocation. L'expiration est planifiée. La révocation est l'action de départ que vous entreprenez avant la date de fin prévue.Le timing est essentiel. L'accès WiFi basé sur des certificats est vérifié lors de l'authentification. Votre objectif pratique est donc clair : empêcher le certificat de réussir lors de la prochaine tentative d'authentification, puis tester ce résultat. Si l'employé a déjà une session active, déterminez séparément si votre politique exige une déconnexion de session. Il s'agit d'un choix d'exploitation réseau, et non d'un substitut à la révocation de l'identité. Prenez également en compte le comportement de reconnexion rapide et les sessions mises en cache lors de votre processus de conception et de test. Une conception qui semble correcte en laboratoire peut créer un angle mort si votre flux d'authentification en production ne valide pas la modification comme prévu. La checklist opérationnelle pour EAP-TLS est simple. Premièrement, confirmez l'enregistrement d'identité de la personne et sa dernière heure de travail. Deuxièmement, désactivez l'identité source. Troisièmement, révoquez ou refusez le certificat concerné conformément à votre autorité de certification et à votre processus RADIUS. Quatrièmement, supprimez ou fermez une session active si votre politique l'exige. Cinquièmement, tentez une nouvelle connexion avec l'appareil géré de l'ancien employé ou un équivalent contrôlé. Enfin, conservez la demande, la modification, le résultat, l'heure et le responsable. Le deuxième modèle est l'iPSK. Au lieu d'une phrase de passe unique partagée par l'ensemble du personnel, chaque personne ou appareil dispose d'une clé distincte sur le même réseau WiFi destiné au personnel. Cela permet une suppression ciblée. Supprimez la clé associée au collaborateur sur le départ, confirmez qu'une nouvelle tentative de connexion échoue, et laissez toutes les autres clés inchangées. L'iPSK fonctionne très bien lorsque vous possédez des appareils qui ne peuvent pas utiliser de certificats, lorsqu'un programme d'appareils gérés est encore en cours de développement, ou lorsque vous devez effectuer une transition pratique pour abandonner une phrase de passe partagée unique. L'iPSK n'est pas un mot de passe générique pour le personnel sous un nom différent. La clé doit être liée à un enregistrement d'identité ou d'appareil unique. Tenez un inventaire du propriétaire de la clé, de sa date d'émission, de son association avec un appareil ou une personne, de son rôle réseau et de son statut de suppression. Veillez à ce que la clé soit suffisamment distincte pour qu'un événement de suppression puisse être attribué au collaborateur sur le départ. Si la même iPSK est réutilisée par une équipe, un groupe de sous-traitants ou une équipe de rotation, vous recréez le problème du secret partagé dans un espace plus restreint. Le troisième modèle est le déprovisionnement piloté par SCIM. SCIM est un protocole standard basé sur HTTP pour le provisionnement et la gestion des données d'identité entre les systèmes. Dans un processus d'arrivée, de mutation et de départ efficace, le service RH ou informatique désactive le compte dans votre fournisseur d'identité, l'état désactivé est transmis au service d'accès WiFi, et toute authentification WiFi ultérieure est refusée. Purple lie l'accès WiFi au fournisseur d'identité grâce à SCIM. Les fournisseurs d'identité concernés sont Microsoft Entra ID, Okta et Google Workspace. L'avantage opérationnel n'a rien de magique. Il s'agit d'une source unique de vérité : l'événement qui met fin à l'emploi déclenche également la suppression de l'accès WiFi. Traitez le SCIM comme un chemin de contrôle, pas comme un slogan. Vous avez besoin d'un identifiant unique qui associe le compte du fournisseur d'identité au registre d'accès WiFi. Vous avez besoin d'un événement de désactivation convenu. Vous devez savoir quelle erreur le service de réception génère lorsqu'une demande de désactivation échoue. Et vous avez besoin d'une identité de test qui prouve que votre surveillance détecte cet échec. Passez maintenant de la conception à la mise en œuvre. Commencez par un inventaire des accès. Listez chaque réseau WiFi du personnel, son mode de sécurité, la source d'identité, le chemin RADIUS s'il est présent, l'autorité de certification si elle est présente, le registre du propriétaire de l'iPSK s'il est présent, la capacité de déconnexion de session et la destination des journaux. Procédez par groupe de sites, et non sous forme de liste d'entreprise centralisée. Un hôtel, un magasin de centre-ville et un stade peuvent partager la même politique tout en utilisant des équipes opérationnelles et du matériel différents. Ensuite, choisissez le contrôle qui élimine le plus de travail manuel du processus de départ. Pour les appareils d'entreprise gérés, utilisez le 802.1X avec EAP-TLS lorsque votre autorité de certification, votre conception RADIUS et votre gestion des appareils peuvent le prendre en charge. Pour les parcs mixtes et les appareils qui ne peuvent pas utiliser de certificats, utilisez l'iPSK uniquement lorsque chaque clé appartient à un utilisateur unique et peut être supprimée. Pour un parc utilisant déjà Microsoft Entra ID, Okta ou Google Workspace, utilisez le déprovisionnement basé sur SCIM pour que la désactivation du compte devienne le déclencheur de la suppression du WiFi. Purple peut connecter cet événement d'identité à l'état de l'accès WiFi. N'ajoutez pas de second ticket manuel, sauf s'il s'agit d'un chemin d'exception. Construisez un guide de procédure de départ le jour même. Les RH confirment l'heure de fin. Le propriétaire de l'identité désactive le compte. Le responsable du réseau confirme que le certificat, l'iPSK ou le registre d'accès WiFi concerné n'est plus valide. Les opérations décident si une session active doit être déconnectée. Un testeur désigné effectue une nouvelle tentative d'authentification. Le dossier ne se ferme que lorsque le résultat est enregistré. C'est délibérément peu glamour. C'est aussi la partie qu'un auditeur peut reconstituer. Pour les preuves ISO 27001 ou SOC 2, conservez une chaîne courte mais complète : la demande de départ autorisée, la modification du fournisseur d'identité, la modification du WiFi, le résultat de la vérification, les horodatages et le responsable de chaque étape. Évitez de collecter plus de données personnelles que le contrôle n'en requiert. Les registres d'accès peuvent constituer des données personnelles, incluez-les donc dans vos décisions de conservation et de contrôle d'accès. Si le WiFi du personnel peut impacter les systèmes de paiement, discutez de la portée et de la segmentation avec l'équipe responsable de PCI-DSS plutôt que de traiter la révocation du WiFi comme une revendication de conformité autonome. Surveillez quatre modes de défaillance. Premièrement, un mot de passe partagé est toujours utilisé sur un SSID négligé. Deuxièmement, le registre WiFi est associé à une adresse e-mail modifiable plutôt qu'à une identité durable. Troisièmement, un événement de désactivation atteint le fournisseur d'identité mais pas le service d'accès WiFi. Quatrièmement, vous testez uniquement l'état du tableau de bord et non une véritable nouvelle tentative de connexion. Chaque mode de défaillance peut être évité si vous inventoriez, surveillez et testez le contrôle. Questions rapides. Un mot de passe WPA2 partagé peut-il être révoqué pour un seul départ ? Non. Vous devez le renouveler pour tout le monde ou le remplacer par un contrôle par identité. À quelle vitesse l'accès EAP-TLS peut-il être révoqué ? Lors de la prochaine authentification, à condition que votre certificat et votre modèle de validation RADIUS reconnaissent la révocation. Le protocole SCIM met-il fin à une session active ? Pas de lui-même. Traitez le contrôle des sessions comme une décision opérationnelle distincte. L'iPSK convient-il à tous les appareils ? Non. Il s'agit d'un modèle pratique de clé liée à l'identité lorsque l'authentification par certificat n'est pas appropriée. La prochaine étape consiste en une brève analyse de conception. Choisissez un réseau WiFi pour le personnel. Suivez le parcours d'un départ d'employé, de la notification des RH jusqu'au refus d'authentification. Identifiez l'étape manuelle. Puis supprimez-la. Un identifiant WiFi devrait expirer en même temps que le départ de l'employé, et non lors du prochain projet de rotation des mots de passe.