Guide de configuration SCEP d'entreprise : Authentification Wi-Fi par certificat pour l'enseignement supérieur et les grands réseaux

Guide de configuration SCEP d'entreprise : Authentification WiFi par certificat pour l'enseignement supérieur et les grands réseaux Un briefing technique Purple - Script de podcast (environ 10 minutes) --- INTRODUCTION ET CONTEXTE - environ 1 minute Bienvenue dans la série de briefings techniques Purple. Je vais vous parler aujourd'hui d'un sujet qui arrive dans de nombreuses boîtes de réception informatiques mais qui obtient rarement une réponse claire : comment déployer concrètement l'authentification WiFi par certificat à grande échelle, à l'aide de SCEP, sur un grand réseau — qu'il s'agisse d'un campus universitaire, d'un groupe hôtelier multisite ou d'un grand parc du secteur public ? Nous allons couvrir l'ensemble du sujet. Ce que fait réellement SCEP, comment il s'intègre dans une architecture 802.1X, la séquence de déploiement que la plupart des équipes ratent, deux scénarios de mise en œuvre réels et les pièges qui vous coûteront un week-end de votre vie si vous ne les planifiez pas. Il s'agit d'un briefing de consultant, pas d'un tutoriel. Je suppose que vous savez ce qu'est un serveur RADIUS et que vous avez probablement déjà décidé de vous affranchir des clés pré-partagées. Ce dont vous avez besoin maintenant, c'est de la feuille de route de mise en œuvre. Entrons dans le vif du sujet. --- ANALYSE TECHNIQUE APPROFONDIE - environ 5 minutes Tout d'abord, les principes de base. SCEP signifie Simple Certificate Enrollment Protocol. Il a été formalisé par l'IETF en tant que RFC 8894 en 2020, bien qu'il ait été largement utilisé en entreprise depuis plus d'une décennie auparavant. Son rôle est simple : automatiser le processus d'obtention d'un certificat numérique sur un appareil géré sans nécessiter d'intervention humaine sur chaque machine. Dans le cadre de l'authentification WiFi, SCEP est le mécanisme de distribution. Le protocole d'authentification réel que vous ciblez est EAP-TLS — Extensible Authentication Protocol with Transport Layer Security — qui s'inscrit dans le cadre 802.1X. EAP-TLS est largement considéré comme la méthode d'authentification la plus sécurisée pour les réseaux sans fil d'entreprise, car elle exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats valides. Aucune des deux parties ne fait confiance à l'autre sans preuve cryptographique. Cette authentification mutuelle est ce qui vous protège contre les attaques de type « evil twin » (jumeau maléfique), où un attaquant déploie un point d'accès pirate pour intercepter des identifiants. Voici comment fonctionne l'ensemble de la chaîne. Un appareil géré — l'ordinateur portable d'un étudiant, le téléphone d'un employé, un terminal de point de vente d'un hôtel — doit se connecter au réseau sans fil de l'entreprise. Votre plateforme MDM, qui peut être Microsoft Intune ou Jamf, pousse une charge utile (payload) SCEP vers cet appareil. Cette charge utile contient deux éléments : l'URL SCEP, qui pointe vers votre serveur NDES ou votre passerelle SCEP cloud, et un mot de passe de défi (challenge) ou secret partagé. L'appareil génère localement sa propre paire de clés publique et privée. C'est un point critique. La clé privée ne quitte jamais l'appareil. Elle est générée sur l'appareil, stockée dans l'enclave sécurisée ou le TPM, et n'est jamais transmise sur le réseau. L'appareil crée ensuite une demande de signature de certificat — une CSR — et l'envoie à la passerelle SCEP. La passerelle valide le défi, transmet la CSR à votre autorité de certification (CA), et la CA la signe puis renvoie le certificat public à l'appareil. À partir de ce moment, lorsque l'appareil se connecte à votre SSID WiFi, il présente ce certificat au serveur RADIUS. Le serveur RADIUS valide le certificat par rapport à la chaîne de confiance de votre CA, vérifie la liste de révocation de certificats (CRL) pour confirmer que le certificat n'a pas été révoqué, et si tout est correct, envoie un message d'acceptation au point d'accès. L'appareil est sur le réseau. Tout le processus est invisible pour l'utilisateur. Parlons maintenant de la place de SCEP par rapport à l'alternative, qui est PKCS. PKCS — Public Key Cryptography Standards — est l'autre méthode de distribution de certificats prise en charge par des plateformes comme Intune. Avec PKCS, la CA génère à la fois la clé publique et la clé privée de manière centralisée, et le connecteur de certificat pousse la paire de clés vers l'appareil. Cela signifie que la clé privée transite sur le réseau, ce qui introduit une surface d'attaque théorique. PKCS convient parfaitement pour des cas d'usage comme le chiffrement d'e-mails S/MIME où le séquestre de clés est souhaitable. Pour l'authentification WiFi, SCEP est le bon choix. La clé privée reste sur l'appareil, un point c'est tout. Passons maintenant à la couche matérielle. SCEP et EAP-TLS sont des normes indépendantes des fournisseurs, ce qui signifie qu'elles fonctionnent sur les points d'accès Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Votre configuration RADIUS — qu'il s'agisse de Windows NPS, FreeRADIUS ou d'un service RADIUS cloud — est l'endroit où vous définissez la politique de validation des certificats et, surtout, où vous configurez l'attribution dynamique de VLAN. Les VLAN dynamiques vous permettent de segmenter le réseau par identité. Un appareil d'étudiant obtient le VLAN 20 — accès Internet uniquement. Un appareil d'enseignant obtient le VLAN 10 — accès aux systèmes de recherche internes. Un appareil de gestion des installations obtient le VLAN 30 — accès aux systèmes de gestion technique du bâtiment. Tout cela est piloté par les attributs du certificat et la politique RADIUS, sans aucune intervention manuelle par appareil. Pour l'intégration des fournisseurs d'identité, les attributs de certificat SCEP — en particulier le Subject Alternative Name — peuvent transporter le nom principal de l'utilisateur (UPN) depuis Microsoft Entra ID, Okta ou Google Workspace. Cela lie le certificat à une identité spécifique, ce qui signifie que lorsque vous désactivez un compte dans Entra ID et que le MDM désinscrit l'appareil, le certificat est révoqué et l'accès WiFi est coupé automatiquement. C'est un scénario de révocation que les clés pré-partagées ne permettent tout simplement pas de réaliser. --- RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES - environ 2 minutes Très bien, parlons de la séquence de déploiement, car c'est là que la plupart des équipes trébuchent. La séquence est non négociable : le certificat Trusted Root d'abord, le profil de certificat SCEP ensuite, et le profil WiFi en troisième. Intune et Jamf imposent tous deux des dépendances de profil. Si votre profil WiFi fait référence à un certificat SCEP qui n'a pas encore été déployé sur l'appareil, le profil WiFi échouera avec une erreur obscure qui ressemble à une mauvaise configuration mais qui n'est en réalité qu'un problème de timing. Le deuxième piège est le ciblage de groupe. Les trois profils — Trusted Root, SCEP et WiFi — doivent être déployés sur le même groupe Azure AD ou Jamf. Si le profil SCEP cible un groupe d'utilisateurs et le profil WiFi cible un groupe d'appareils, Intune ne pourra pas résoudre la dépendance et le profil WiFi s'affichera comme « Non applicable ». Cela piège constamment les équipes. Troisièmement : l'accessibilité du serveur NDES. Votre serveur NDES doit être accessible depuis Internet afin que les appareils puissent s'enregistrer avant d'arriver sur site. La bonne façon de procéder consiste à utiliser Azure AD Application Proxy, et non à ouvrir un port dans votre pare-feu. App Proxy vous offre un accès à distance sécurisé sans ports entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enregistrement. Quatrièmement : la disponibilité de la CRL. Votre serveur RADIUS vérifie la liste de révocation de certificats (CRL) à chaque fois qu'un appareil s'authentifie. Si votre point de distribution CRL est indisponible — parce qu'un serveur est en panne ou que l'URL a changé — l'authentification échoue simultanément pour tous les appareils du réseau. C'est une panne à l'échelle du campus. Rendez vos points de terminaison CRL hautement disponibles et testez la révocation avant la mise en production. Pour les grands réseaux — au-delà de 500 appareils —, envisagez une passerelle SCEP cloud plutôt qu'un serveur NDES sur site. Les passerelles cloud éliminent le point de défaillance unique du NDES, évoluent horizontalement et s'intègrent généralement directement aux services RADIUS cloud, supprimant ainsi une autre dépendance d'infrastructure. --- QUESTIONS-RÉPONSES RAPIDES - environ 1 minute SCEP peut-il gérer les appareils BYOD qui ne sont pas enregistrés dans un MDM ? Pas directement. SCEP nécessite un enregistrement MDM pour pousser la charge utile du certificat. Pour le BYOD non géré, vous devez adopter une approche différente — soit un portail d'intégration en libre-service, soit un SSID distinct utilisant un Captive Portal avec vérification d'identité. La plateforme de Purple gère proprement cette couche d'invités et de BYOD, en parallèle de votre réseau du personnel authentifié par certificat. Qu'en est-il d'iOS et d'Android ? Les deux plateformes prennent en charge SCEP nativement. iOS prend en charge SCEP depuis iOS 4. Android Enterprise prend en charge SCEP via Intune et d'autres MDM. La configuration est légèrement différente selon la plateforme, mais le protocole sous-jacent est identique. EAP-TLS fonctionne-t-il avec le WPA3 ? Oui. Le WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements sensibles, et EAP-TLS est entièrement compatible. En fait, le WPA3-Enterprise avec EAP-TLS est la combinaison recommandée par la Wi-Fi Alliance pour les réseaux gouvernementaux et financiers. --- RÉSUMÉ ET PROCHAINES ÉTAPES - environ 1 minute En résumé. L'authentification WiFi par certificat SCEP est la bonne architecture pour tout réseau comptant plus de 50 appareils gérés. Elle élimine les identifiants partagés, vous donne une identité par appareil, permet une segmentation dynamique des VLAN et s'intègre directement à votre fournisseur d'identité pour une révocation automatisée. La séquence de déploiement — Trusted Root, puis profil SCEP, puis profil WiFi — est fixe. Le ciblage de groupe doit être cohérent. La disponibilité de la CRL n'est pas facultative. Pour l'enseignement supérieur en particulier, la combinaison de SCEP pour les appareils du personnel et des enseignants, associée à une couche WiFi invité distincte pour les étudiants sur leurs appareils personnels, vous offre à la fois la sécurité et une excellente expérience utilisateur, sans compromis. Si vous souhaitez aller plus loin, le guide de Purple sur l'authentification WiFi d'entreprise sans Active Directory ni serveur sur site couvre la voie cloud-native. Et si vous vous demandez ce qui se passe lorsqu'un employé s'en va, notre guide sur la révocation de l'accès WiFi détaille l'ensemble du flux de révocation. Merci pour votre écoute. Je fais partie de l'équipe technique de Purple, et nous nous retrouverons lors du prochain briefing. --- FIN DU SCRIPT