Comment révoquer l'accès WiFi lors du départ d'un employé

Bienvenue dans ce point technique de Purple. Je suis votre hôte et aujourd'hui, nous abordons l'une des failles les plus courantes de l'offboarding en entreprise : que devient concrètement l'accès WiFi lorsqu'un employé s'en va ? Cela semble simple. On rend son badge, les RH ferment le compte et c'est réglé. Mais si votre réseau utilise toujours un mot de passe partagé WPA2, cette personne est partie en connaissant toujours ce mot de passe. Et à moins de le changer pour tout le monde, elle peut s'y reconnecter depuis le parking. C'est le problème que nous résolvons aujourd'hui. Nous allons passer en revue les trois modèles fiables de révocation du WiFi par utilisateur, détailler une checklist de révocation pour le jour même et expliquer exactement ce qu'un auditeur ISO 27001 ou SOC 2 s'attend à trouver dans vos logs. C'est parti. Première partie : pourquoi les mots de passe partagés ne sont pas adaptés. Le WPA2-Personal, la configuration standard des routeurs domestiques, utilise une clé unique prépartagée. Tout le monde sur le réseau connaît le même mot de passe. Quand une personne s'en va, ce mot de passe reste valide sur son téléphone, son ordinateur portable et tout appareil qu'elle a un jour connecté. Le seul moyen de révoquer son accès est de changer le mot de passe de l'ensemble du réseau et de le redistribuer à tous les utilisateurs et appareils restants. Dans un hôtel de 200 employés, cela implique de mettre à jour chaque terminal de point de vente, chaque PC administratif et le téléphone de chaque manager. Dans une chaîne de vente au détail de 50 magasins, cela impose un déploiement coordonné sur chaque site. Le coût opérationnel est élevé, la perturbation est réelle, et le délai entre le dernier jour du partant et la modification finale constitue une véritable faille de sécurité. La norme PCI DSS, le standard de l'industrie des cartes de paiement, exige que vous modifiiez les identifiants partagés dès que le personnel qui les connaît s'en va. Ainsi, si vos caisses sont sur le même réseau que le WiFi de votre personnel, un départ déclenche une obligation de conformité, et pas seulement une recommandation de bonne pratique. La cause profonde est simple : un mot de passe partagé n'est associé à aucune identité. Le réseau ne peut pas faire la différence entre un employé actuel et un ancien. Pour résoudre ce problème, vous devez utiliser des identifiants par utilisateur. Deuxième partie : les trois modèles qui fonctionnent vraiment. Le premier modèle est le 802.1X avec authentification par certificat EAP-TLS. C'est la référence absolue en matière de sécurité WiFi d'entreprise. Dans ce modèle, chaque utilisateur ou appareil détient un certificat numérique unique émis par votre autorité de certification (CA). Lorsqu'il se connecte au WiFi, le serveur RADIUS valide ce certificat de manière cryptographique. Le certificat est lié à une identité, pas à un mot de passe. Pour révoquer l'accès, il suffit de révoquer le certificat au niveau de la CA. Le serveur RADIUS vérifie l'état de révocation en temps réel à l'aide d'OCSP (Online Certificate Status Protocol). Lorsque vous marquez un certificat comme révoqué, lors de la tentative d'authentification suivante de l'appareil, le serveur RADIUS interroge le répondeur OCSP, reçoit une réponse de révocation et envoie un refus d'accès (Access-Reject) au point d'accès. L'appareil est déconnecté du réseau dans les secondes qui suivent la tentative d'authentification suivante. Pour les sessions actives, vous utilisez le protocole RADIUS Change of Authorisation, ou CoA, pour mettre fin immédiatement à la session existante. Combinés, l'OCSP et le CoA vous permettent de révoquer l'accès WiFi d'un collaborateur sortant en moins d'une minute, avec une piste d'audit complète dans vos journaux RADIUS. Le défi avec EAP-TLS réside dans la surcharge liée à la PKI. Vous avez besoin d'une autorité de certification, d'un mécanisme pour délivrer les certificats aux appareils, généralement via un MDM comme Microsoft Intune, et d'un processus pour les révoquer. Pour les organisations disposant d'un MDM et d'une infrastructure d'identité matures, c'est la bonne réponse. Pour les équipes plus petites ou les environnements avec des appareils IoT qui ne peuvent pas prendre en charge l'authentification par certificat, vous devez adopter une approche différente. Le deuxième modèle est l'iPSK (Identity Pre-Shared Key). Cisco l'appelle iPSK, Ruckus l'appelle DPSK, Aruba l'appelle MPSK, mais le concept reste le même : chaque utilisateur ou appareil obtient un mot de passe unique, même s'ils se connectent tous au même SSID. Le serveur RADIUS associe chaque clé unique à une identité spécifique et, en option, à un VLAN spécifique. Lorsque vous supprimez cette clé de la base de données RADIUS, l'appareil ne peut plus s'authentifier. L'impact de la suppression d'un collaborateur sortant est limité à une seule personne. Les clés de tous les autres utilisateurs restent valides. L'iPSK est particulièrement adapté aux environnements dotés de types d'appareils mixtes. Les appareils IoT, les terminaux de point de vente et le matériel hérité qui ne peuvent pas prendre en charge les certificats 802.1X peuvent tous utiliser l'iPSK. Il est également plus simple à exploiter qu'un déploiement PKI complet, ce qui en fait le choix idéal pour les organisations de taille moyenne qui ont besoin d'une révocation par utilisateur sans la surcharge d'infrastructure. Le délai de révocation pour l'iPSK est généralement de quelques minutes, et non de quelques secondes. La suppression de la clé se propage au serveur RADIUS, mais les sessions actives peuvent persister jusqu'à ce que l'appareil se réauthentifie ou que vous envoyiez un paquet CoA pour forcer la déconnexion. Le troisième modèle est le déprovisionnement piloté par SCIM. SCIM signifie System for Cross-domain Identity Management. Il s'agit d'un standard ouvert, défini dans les RFC 7643 et RFC 7644, qui permet à votre fournisseur d'identité de transmettre les événements liés au cycle de vie des utilisateurs aux systèmes en aval en temps réel. Voici comment cela fonctionne en pratique. Votre fournisseur d'identité, qu'il s'agisse de Microsoft Entra ID, d'Okta ou de Google Workspace, est la source unique de vérité pour les comptes d'utilisateurs. Lorsque les RH désactivent le compte d'un collaborateur sortant dans le fournisseur d'identité, SCIM envoie une requête à chaque système connecté, y compris à votre plateforme de gestion du WiFi. Purple se connecte à votre fournisseur d'identité via SCIM. Dès que vous désactivez un utilisateur dans Entra ID, Okta ou Google Workspace, Purple reçoit l'événement SCIM et révoque ses identifiants WiFi lors de la prochaine authentification. L'événement est enregistré avec un horodatage, l'identité de l'utilisateur et l'action entreprise. Cette entrée de journal est exactement ce qu'un auditeur ISO 27001 a besoin de voir. Le SCIM ne remplace pas le 802.1X ou l'iPSK. Il se positionne au-dessus d'eux. Le SCIM gère le cycle de vie des identités ; le protocole d'authentification gère l'application des règles réseau. L'association du SCIM et du 802.1X vous offre une révocation automatique et en temps réel, avec un historique d'audit complet et sans aucune étape manuelle. Section trois : la check-list pour une révocation le jour même. Lorsque arrive le dernier jour d'un collaborateur quittant l'entreprise, voici la séquence que votre équipe informatique doit suivre. Étape un : désactivez le compte dans votre fournisseur d'identité. C'est le déclencheur de tout le reste. Dans Microsoft Entra ID, configurez le compte sur désactivé. Dans Okta, désactivez l'utilisateur. Dans Google Workspace, suspendez le compte. Étape deux : si vous utilisez le SCIM, vérifiez que l'événement de déprovisionnement a bien été déclenché. Consultez vos journaux SCIM ou votre plateforme de gestion du WiFi pour trouver l'événement correspondant. Si le SCIM n'est pas configuré, révoquez manuellement le certificat dans votre AC ou supprimez la clé iPSK de votre base de données RADIUS. Étape trois : envoyez un CoA RADIUS pour mettre fin à toute session WiFi active. La plupart des serveurs RADIUS d'entreprise, ainsi que les plateformes comme Purple, peuvent le faire automatiquement lors d'un événement de déprovisionnement. Si vous le faites manuellement, utilisez l'interface CoA de votre serveur RADIUS pour déconnecter l'appareil de l'utilisateur par adresse MAC ou par ID de session. Étape quatre : confirmez qu'il ne reste aucune session active. Vérifiez le tableau de bord de votre contrôleur WiFi. Sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet, vous devriez pouvoir effectuer une recherche par nom d'utilisateur ou par appareil et confirmer qu'il n'y a plus aucune association active. Étape cinq : archivez l'entrée du journal d'audit. Exportez ou marquez le journal d'authentification RADIUS, le journal des événements SCIM et le journal CoA pour l'utilisateur et la date concernés. Stockez-les dans votre plateforme ITSM ou SIEM (gestion des informations et des événements de sécurité). La mesure de contrôle A.9.2.6 de l'Annexe A de la norme ISO 27001 exige que vous supprimiez ou adaptiez les droits d'accès de tous les employés et prestataires à la fin de leur contrat. Votre journal en est la preuve. Étape six : si vous utilisez un PSK partagé WPA2 et qu'aucune des étapes précédentes ne s'applique, renouvelez le mot de passe. Coordonnez le déploiement sur l'ensemble des sites et des appareils avant le dernier jour du collaborateur si possible, ou immédiatement après. Section quatre : ce qu'attend l'auditeur. Les normes ISO 27001 et SOC 2 exigent toutes deux que vous prouviez que les accès sont supprimés rapidement à la fin d'un contrat de travail. Pour le WiFi spécifiquement, les auditeurs recherchent quatre éléments. Premièrement, une procédure d'offboarding documentée qui inclut explicitement l'accès au réseau. Deuxièmement, la preuve que cette procédure a été suivie pour un échantillon de collaborateurs partis, généralement de dix à vingt-cinq personnes sélectionnées sur les douze derniers mois. Troisièmement, un journal indiquant l'horodatage de la désactivation du compte et l'horodatage de la révocation de l'accès WiFi, l'écart entre les deux devant être clairement visible. Quatrièmement, la confirmation qu'aucun compte d'ancien employé n'affiche de session WiFi active. Si vous utilisez WPA2 avec clé partagée (PSK), vous ne pouvez pas fournir de preuves pour les points trois et quatre. Il n'existe pas de journal par utilisateur. Le mieux que vous puissiez faire est d'indiquer la date de rotation du mot de passe et de soutenir qu'elle a été effectuée avant ou le dernier jour de présence du collaborateur partant. Les auditeurs rejettent de plus en plus cet argument. Si vous utilisez 802.1X avec SCIM, le journal est automatique. Purple enregistre chaque événement de déprovisionnement SCIM avec un horodatage UTC, la source du fournisseur d'identité, l'identifiant unique de l'utilisateur et l'action qui en découle. C'est un registre d'audit propre et infalsifiable. Section cinq : pièges d'implémentation et comment les éviter. L'erreur la plus courante consiste à supposer que la désactivation d'un compte chez le fournisseur d'identité est suffisante. Ce n'est pas le cas, à moins que votre plateforme WiFi ne soit connectée à ce fournisseur d'identité via SCIM ou une intégration similaire en temps réel. Sans cette connexion, le système WiFi n'a aucun moyen de savoir que le compte a été désactivé. Le deuxième piège est la mise en cache des certificats. Même avec l'OCSP, les serveurs RADIUS mettent en cache les réponses valides pendant une période configurable, généralement de 15 à 60 minutes. Si vous révoquez un certificat et que le serveur RADIUS dispose d'une réponse valide en cache, l'appareil peut continuer à s'authentifier jusqu'à l'expiration du cache. Définissez le TTL du cache OCSP sur 15 minutes ou moins pour les environnements hautement sécurisés. Le troisième piège est l'oubli des sessions actives. La révocation des identifiants empêche de nouvelles authentifications mais ne met pas fin à une session WiFi existante. Envoyez toujours un RADIUS CoA après avoir révoqué des identifiants pour déconnecter immédiatement l'appareil. Le quatrième piège concerne l'IoT et les appareils partagés. Un appareil enregistré au nom d'un collaborateur partant peut être un poste de travail partagé ou un équipement opérationnel. Avant de procéder à la révocation, confirmez que l'appareil est personnel et non partagé. S'il est partagé, réenregistrez-le sous un compte de service avant de révoquer les identifiants du partant. Section six : questions-réponses rapides. Question : à quelle vitesse l'accès WiFi basé sur des certificats peut-il être révoqué ? Avec l'OCSP et le RADIUS CoA, en moins de 60 secondes à partir du moment où vous révoquez le certificat auprès de l'autorité de certification. La vérification OCSP a lieu lors de la prochaine tentative d'authentification. Le CoA met immédiatement fin à la session active. Question : le SCIM fonctionne-t-il avec tous les équipements WiFi ? SCIM fonctionne au niveau de la couche de gestion des identités, pas de la couche matérielle. Purple est indépendant du matériel et fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. L'intégration SCIM se fait avec Purple, pas directement avec les points d'accès. Question : que se passe-t-il si nous n'avons pas de MDM et ne pouvons pas déployer de certificats ? L'iPSK est votre solution. Il vous permet une révocation par utilisateur sans nécessiter d'infrastructure de certificats. Purple peut gérer les clés iPSK et se connecter à votre fournisseur d'identité pour automatiser le cycle de vie. Résumé et prochaines étapes. Le message clé est le suivant : si vous ne pouvez pas révoquer l'accès WiFi d'une seule personne sans affecter tous les autres, vous faites face à un problème de partage de clés d'identification. La solution réside dans l'utilisation de clés d'identification par utilisateur, soit via des certificats avec 802.1X EAP-TLS, soit via des clés uniques avec iPSK, associées à un déprovisionnement basé sur SCIM afin d'automatiser la révocation dès l'intervention des RH. Purple se connecte à Microsoft Entra ID, Okta et Google Workspace via SCIM, est déployé dans plus de 80 000 sites physiques actifs et enregistre chaque événement de déprovisionnement à des fins d'audit. Si vous vous préparez pour l'ISO 27001 ou SOC 2, ou si vous souhaitez simplement combler la faille de sécurité liée aux départs d'employés avant qu'elle ne devienne un incident, c'est par là qu'il faut commencer. Pour une analyse technique complète de la révocation de certificats et du protocole OCSP, consultez notre guide sur l'OCSP et la révocation de certificats pour l'authentification WiFi. Pour une vision plus globale de l'automatisation des processus d'arrivée, d'évolution et de départ des collaborateurs, consultez notre guide de sécurité WiFi pour les entreprises. Merci d'avoir écouté ce point technique de Purple.