Guide de configuration SCEP d'entreprise : Authentification WiFi basée sur les certificats pour l'enseignement supérieur et les grands réseaux

Guide de configuration SCEP pour entreprise : Authentification WiFi basée sur les certificats 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 des briefings techniques Purple. Je vais vous parler aujourd'hui d'un sujet qui atterrit dans de nombreuses boîtes de réception informatiques mais qui trouve rarement une réponse simple : comment déployer concrètement l'authentification WiFi basée sur les certificats à grande échelle, en utilisant SCEP, sur un grand réseau - qu'il s'agisse d'un campus universitaire, d'un groupe hôtelier multi-sites ou d'un grand domaine 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 d'implémentation réels, et les pièges qui vous coûteront un week-end de votre vie si vous ne les anticipez pas. Il s'agit d'un briefing de consultant, pas d'un tutoriel. Je pars du principe 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 d'implémentation. Entrons dans le vif du sujet. --- ANALYSE TECHNIQUE APPROFONDIE - environ 5 minutes Commençons par 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 pendant 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 final que vous ciblez est EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - qui s'inscrit dans le cadre du 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 il exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats valides. Aucun des deux côtés ne fait confiance à l'autre sans preuve cryptographique. Cette authentification mutuelle est ce qui vous protège contre les attaques de type "evil twin" - où un attaquant configure un point d'accès malveillant pour intercepter des identifiants. Voici comment fonctionne l'ensemble de la chaîne. Un appareil géré - un ordinateur portable d'étudiant, un téléphone professionnel, un terminal de point de vente d'hôtel - doit se connecter au réseau sans fil de l'entreprise. Votre plateforme MDM, qui peut être Microsoft Intune ou Jamf, pousse un profil SCEP vers cet appareil. Ce profil 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 ou secret partagé. L'appareil génère sa propre paire de clés publique et privée localement. 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 - un CSR - et l'envoie à la passerelle SCEP. La passerelle valide le défi, transmet le CSR à votre autorité de certification, et l'AC le 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 AC, vérifie la liste de révocation des certificats 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 connecté au réseau. L'ensemble du processus est invisible pour l'utilisateur. Examinons maintenant la position de SCEP par rapport à l'alternative, à savoir 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, l'AC 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ù l'archivage des clés est réellement souhaitable. Pour l'authentification WiFi, SCEP est le choix idéal. La clé privée reste sur l'appareil, un point c'est tout. Abordons maintenant la couche matérielle. SCEP et EAP-TLS sont des normes indépendantes des constructeurs, 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. C'est au niveau de votre configuration RADIUS - qu'il s'agisse de Windows NPS, FreeRADIUS ou d'un service RADIUS cloud - que vous définissez la politique de validation des certificats et, surtout, que 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 de membre du corps 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 géré 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 des certificats SCEP - en particulier le Subject Alternative Name - peuvent porter le nom principal de l'utilisateur provenant de Microsoft Entra ID, Okta ou Google Workspace. Cela associe 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 le scénario de révocation que les clés pré-partagées ne peuvent tout simplement pas offrir. - - - RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER - environ 2 minutes Abordons maintenant la séquence de déploiement, car c'est là que la plupart des équipes commettent des erreurs. La séquence n'est pas négociable : le certificat Root de confiance en premier, le profil de certificat SCEP en deuxième, le profil WiFi en troisième. Intune et Jamf appliquent 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 cryptique qui ressemble à une mauvaise configuration, mais qui n'est en fait qu'un problème de timing. Le deuxième piège est le ciblage des groupes. Les trois profils - Root de confiance, SCEP et WiFi - doivent être déployés exactement sur le même groupe Azure AD ou Jamf. Si le profil SCEP cible un groupe d'utilisateurs et que le profil WiFi cible un groupe d'appareils, Intune ne peut pas résoudre la dépendance et le profil WiFi apparaîtra comme Non applicable. Cela piège constamment les équipes. Troisièmement : l'accessibilité du serveur NDES. Votre serveur NDES doit être accessible depuis Internet pour que les appareils puissent s'enregistrer avant d'arriver sur site. La bonne façon de procéder consiste à utiliser le proxy d'application Azure AD, et non à ouvrir un port dans votre pare-feu. Le proxy d'application 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 des certificats à chaque fois qu'un appareil s'authentifie. Si votre point de distribution CRL n'est pas disponible - 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 de passer en production. Pour les grands réseaux - plus de 500 appareils - envisagez une passerelle SCEP cloud plutôt qu'un NDES sur site. Les passerelles cloud éliminent le point de défaillance unique du NDES, s'adaptent 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 Le 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 avez besoin d'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 d'employés authentifié par certificat. Qu'en est-il d'iOS et Android ? Les deux plateformes prennent en charge SCEP de manière native. 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 WPA3 ? Oui. WPA3-Enterprise impose un mode de sécurité 192 bits pour les environnements sensibles, et EAP-TLS est entièrement compatible. En fait, l'association de WPA3-Enterprise et 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 Pour résumer. L'authentification WiFi par certificat SCEP est l'architecture idéale pour tout réseau comptant plus de 50 appareils gérés. Elle élimine les identifiants partagés, vous offre une identité par appareil, permet une segmentation VLAN dynamique et s'intègre directement à votre fournisseur d'identité pour une révocation automatisée. Séquence de déploiement : Racine de confiance, puis profil SCEP, puis profil WiFi - cet ordre est fixe. Le ciblage des groupes doit être cohérent. La disponibilité de la CRL n'est pas facultative. Pour l'enseignement supérieur en particulier, la combinaison du 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 des accès WiFi détaille l'intégralité du workflow de révocation. Merci pour votre écoute. Je fais partie de l'équipe technique de Purple, et nous vous retrouverons lors du prochain briefing. - FIN DU SCRIPT