Déploiement de SCEP pour la sécurisation du BYOD et de l'authentification WiFi dans l'enseignement supérieur

Bienvenue dans cette fiche technique de Purple. Je suis votre hôte et aujourd'hui nous allons aborder un sujet récurrent pour les équipes informatiques de l'enseignement supérieur : le déploiement du protocole SCEP pour sécuriser le BYOD et l'authentification WiFi. Si vous utilisez PEAP-MSCHAPv2 sur le réseau de votre campus, cette session vous concerne directement. Et si vous prévoyez déjà de migrer vers une authentification basée sur les certificats, nous allons vous présenter l'architecture, les pièges à éviter et les étapes de mise en œuvre pour y parvenir. Commençons par le problème. Les universités sont, par nature, des environnements ouverts. Les étudiants arrivent en septembre avec deux, trois, voire cinq appareils personnels. Ils s'attendent à se connecter immédiatement, en toute sécurité et sans avoir à appeler le support technique. Pour la plupart des établissements, la réalité se traduit par une file d'attente au support qui atteint deux mille tickets dans les quarante-huit heures suivant la rentrée. Ce n'est pas un problème de personnel. C'est un problème d'architecture. La cause première est presque toujours la même : l'authentification WiFi par mot de passe. Lorsque vous utilisez WPA2-Enterprise avec PEAP et MSCHAPv2, vous demandez aux étudiants de configurer manuellement les paramètres 802.1X sur chaque appareil. Un seul mauvais paramètre, et ils deviennent vulnérables à une attaque de type "homme du milieu". Pire encore, lorsque l'université impose un changement de mot de passe tous les quatre-vingt-dix jours, tous les appareils du campus perdent simultanément leur accès au WiFi. C'est une catastrophe prévisible et évitable. La solution est l'authentification par certificat via EAP-TLS, et le mécanisme qui la rend évolutive est le SCEP : le Simple Certificate Enrolment Protocol. Le SCEP a été officialisé par l'IETF dans la RFC 8894 en 2020, bien qu'il soit utilisé depuis le début des années 2000. Il automatise le processus de demande et d'installation de certificats numériques X.509 sur les appareils, sans nécessiter d'intervention informatique manuelle par appareil. Voici son fonctionnement global. Votre plateforme de MDM, qu'il s'agisse de Microsoft Intune ou de Jamf, pousse une charge utile SCEP vers chaque appareil enregistré. Cette charge utile contient deux éléments : l'URL de la passerelle SCEP et un mot de passe de défi partagé. L'appareil génère une demande de signature de certificat, l'envoie à la passerelle SCEP, qui valide le mot de passe de défi et transmet la demande à votre autorité de certification. L'autorité de certification signe le certificat et le renvoie à l'appareil. À partir de ce moment, l'appareil s'authentifie sur votre réseau WiFi à l'aide de EAP-TLS : le certificat prouve l'identité de l'appareil auprès du serveur RADIUS, et le certificat du serveur RADIUS prouve l'identité du réseau auprès de l'appareil. C'est une authentification mutuelle. Aucun mot de passe n'est échangé sur le réseau. Cette authentification mutuelle est essentielle. Avec PEAP, un étudiant se connectant à un point d'accès pirate diffusant votre SSID transmettra volontiers ses identifiants. Avec EAP-TLS, l'appareil vérifie le certificat du serveur RADIUS avant de poursuivre. S'il ne correspond pas à l'autorité de certification de confiance, la connexion échoue silencieusement. Vous venez d'éliminer toute cette catégorie d'attaques de type "evil twin".Parlons maintenant d'architecture. Un déploiement SCEP en production pour une université comporte six composants clés. Premièrement, votre fournisseur d'identité : Microsoft Entra ID, Okta, ou Google Workspace. Deuxièmement, votre plateforme MDM : Intune pour Windows et Android, Jamf pour macOS et iOS. Troisièmement, votre autorité de certification (CA) : soit Microsoft Active Directory Certificate Services sur site, soit une PKI cloud. Quatrièmement, votre passerelle SCEP : le point de terminaison HTTP qui reçoit les demandes de certificats. Cinquièmement, votre serveur RADIUS pour l'authentification. Sixièmement, votre couche d'accès : les points d'accès Cisco Meraki, HPE Aruba, Ruckus, ou Juniper Mist configurés pour le 802.1X. La chaîne de confiance fonctionne de la manière suivante. La CA émet un certificat racine. Ce certificat racine est distribué à chaque appareil via le MDM, établissant ainsi la confiance. La CA émet ensuite des certificats clients pour les appareils via SCEP. Lorsqu'un appareil se connecte, il présente son certificat client au serveur RADIUS, et le serveur RADIUS présente son certificat serveur à l'appareil. Les deux parties effectuent la vérification par rapport au certificat racine de confiance. L'accès est accordé ou refusé en fonction de la validité du certificat, et non d'un mot de passe. Laissez-moi vous guider à travers la séquence d'implémentation. C'est l'ordre qui fonctionne. Étape un : nettoyez votre référentiel d'identités. Assurez-vous que votre Active Directory ou Entra ID dispose de groupes bien définis pour les étudiants, le personnel et les invités. Les politiques de certificats et les attributions de VLAN seront liées à ces groupes. Étape deux : déployez votre autorité de certification. Si vous utilisez Microsoft ADCS, configurez une hiérarchie à deux niveaux : une CA racine hors ligne et une CA d'émission en ligne. La CA racine doit être isolée du réseau après la configuration initiale. Étape trois : configurez votre passerelle SCEP. Il s'agit du point de terminaison HTTP vers lequel votre MDM orientera les appareils. Assurez-vous qu'il soit accessible depuis le segment réseau où les appareils effectuent l'enregistrement initial, généralement votre SSID d'intégration. Étape quatre : configurez votre serveur RADIUS. Importez le certificat de la CA d'émission en tant que CA de confiance. Configurez le protocole EAP-TLS comme méthode d'authentification. Configurez les attributs de retour VLAN pour que le serveur RADIUS puisse attribuer dynamiquement les étudiants au segment réseau correct. Étape cinq : configurez vos profils MDM. Dans Intune, créez d'abord un profil de certificat de confiance, puis un profil de certificat SCEP, et enfin un profil WiFi qui fait référence au certificat SCEP. Déployez-les exactement dans cet ordre. Chacun dépend de l'existence du précédent. Étape six : configurez vos points d'accès. Sur Cisco Meraki, HPE Aruba, Ruckus, ou Juniper Mist, configurez votre SSID sécurisé pour le WPA2-Enterprise ou le WPA3-Enterprise. Définissez le délai d'attente RADIUS à au moins cinq secondes pour absorber la latence de validation des certificats pendant les pics de connexion. Passons maintenant aux pièges à éviter. J'ai vu ces erreurs faire échouer des déploiements à maintes reprises. Le premier piège est le déploiement des profils MDM dans le mauvais ordre. Si le profil WiFi arrive sur l'appareil avant le profil de certificat SCEP, l'appareil n'a pas de certificat pour s'authentifier. La connexion échoue, et l'utilisateur contacte le support technique. Le deuxième piège est d'oublier les appareils BYOD. Intune et Jamf gèrent votre parc d'appareils appartenant à l'institution. Mais les appareils personnels des étudiants ne sont pas enregistrés dans votre MDM. Pour ceux-ci, vous avez besoin d'un portail d'intégration en libre-service. L'étudiant s'authentifie via l'authentification unique (SSO) en utilisant ses identifiants universitaires, et le portail utilise SCEP pour provisionner le certificat. La plateforme de Purple intègre ce flux d'intégration directement dans l'expérience du Captive Portal, permettant aux étudiants de finaliser leur enregistrement en moins de deux minutes sans aucune intervention du service informatique. Le troisième piège est lié aux échecs de dépassement de délai RADIUS lors des pics d'intégration. Testez la charge de votre infrastructure RADIUS avant le mois de septembre, et non pendant celui-ci. Implémentez un équilibrage de charge sur au moins deux nœuds RADIUS. Le quatrième piège concerne la révocation des certificats. Lorsqu'un étudiant s'en va, ou qu'un appareil est perdu ou volé, vous devez révoquer le certificat immédiatement. Assurez-vous que votre autorité de certification (CA) publie une liste de révocation de certificats, et que votre serveur RADIUS la vérifie à chaque authentification. Passons maintenant à une session rapide de questions-réponses sur les sujets que nous entendons le plus souvent. Le SCEP peut-il fonctionner sans MDM ? Techniquement oui, mais en pratique non. Sans MDM pour pousser la charge utile SCEP et le profil WiFi, vous revenez à une configuration manuelle de l'appareil. Quelle doit être la durée de validité d'un certificat ? Pour les appareils des étudiants, une durée de un à deux ans est la norme. Assez longue pour couvrir l'année universitaire sans frottement lié au renouvellement, assez courte pour limiter l'exposition si un certificat est compromis. Qu'en est-il des appareils IoT qui ne prennent pas en charge la norme 802.1X ? Utilisez le contournement d'authentification MAC (MAB) avec un portail d'enregistrement d'appareils en libre-service. Les étudiants enregistrent l'adresse MAC de leur console de jeux ou de leur smart TV, et votre système NAC la place dans le bon VLAN. Cela fonctionne-t-il avec eduroam ? Oui. EAP-TLS est entièrement pris en charge par la fédération eduroam. Les certificats émis par la CA de votre campus peuvent authentifier les étudiants sur eduroam dans n'importe quelle institution participante à travers le monde. Pour conclure, voici les trois décisions qui définissent le succès d'un déploiement SCEP. Premièrement : choisissez l'architecture de votre CA avant toute autre chose. Un ADCS sur site vous offre un contrôle total. Un PKI cloud vous offre une simplicité opérationnelle. Un mauvais choix ici vous coûtera des mois de travail supplémentaire. Deuxièmement : automatisez l'intégration du BYOD dès le premier jour. Ne supposez pas que les étudiants configureront leurs appareils personnels manuellement. Ils ne le feront pas. Créez le portail en libre-service avant la rentrée. Troisièmement : testez la capacité de votre serveur RADIUS sous charge avant le mois de septembre. Une panne RADIUS le premier jour de la rentrée est tout à fait évitable. La plateforme de Purple prend en charge ces trois aspects : l'intégration PKI cloud overlay, l'intégration BYOD en libre-service via notre Captive Portal, et une infrastructure RADIUS testée sur quatre-vingt mille sites actifs avec une disponibilité de quatre-vingt-dix-neuf virgule quatre-vingt-dix-neuf pour cent. Merci d'avoir participé à ce briefing technique Purple. Pour plus d'informations, visitez purple.ai.