Comment configurer SCEP pour la sécurité du BYOD et l'authentification réseau 802.1X

Bonjour et bienvenue dans ce point technique de Purple. Je suis votre hôte et, aujourd'hui, nous allons entrer dans les détails du protocole SCEP (Simple Certificate Enrollment Protocol) et voir comment le configurer correctement pour sécuriser le BYOD et l'authentification réseau 802.1X. Si vous êtes responsable informatique, architecte réseau ou CTO en charge de l'infrastructure WiFi d'un groupe hôtelier, d'un réseau de points de vente, d'un stade ou d'une organisation du secteur public, cela vous concerne directement. Aujourd'hui, nous ne faisons pas de théorie. Nous parlons d'architecture et de décisions. C'est parti. [SECTION: Introduction et contexte - environ 1 minute] Voici le problème auquel vous êtes probablement confronté. Vous avez des appareils de collaborateurs, des ordinateurs portables de sous-traitants et des téléphones personnels qui ont tous besoin d'accéder au réseau. Vous avez probablement un mélange d'appareils gérés et non gérés. Et quelque part dans votre infrastructure, il reste encore une clé WPA2 pré-partagée connue par douze personnes, dont trois ont quitté l'entreprise l'année dernière. Ce n'est pas une posture de sécurité. C'est un risque. La solution est le 802.1X, la norme IEEE pour le contrôle d'accès réseau basé sur les ports. Elle garantit qu'aucun appareil ne transmet de trafic tant qu'il n'a pas été explicitement authentifié. Mais le 802.1X n'est que le cadre. La vraie question est de savoir quelle méthode d'authentification s'y intègre. Et pour le BYOD à grande échelle, la réponse est l'EAP-TLS avec des certificats provisionnés via SCEP. C'est ce que nous allons décortiquer aujourd'hui. [SECTION: Analyse technique approfondie - environ 5 minutes] Commençons par ce que fait réellement le SCEP. Le SCEP - Simple Certificate Enrollment Protocol - a été initialement publié sous forme de projet Internet par l'IETF en 1999, créé par VeriSign. Il a été formalisé sous la référence RFC 8894. Son rôle est simple : automatiser le processus de délivrance de certificats numériques X.509 aux appareils à grande échelle, sans qu'un humain n'ait à générer et installer manuellement chacun d'eux. Voici le processus en quatre étapes. Étape 1 : l'appareil se connecte à un point de terminaison SCEP, une URL hébergée soit sur site via un rôle Windows Server appelé NDES (Network Device Enrollment Service), soit via un fournisseur PKI cloud. Cette URL est la passerelle vers votre autorité de certification. Étape 2 : l'appareil présente un challenge SCEP, un secret partagé qui prouve qu'il est autorisé à demander un certificat. Dans un environnement géré par MDM comme Microsoft Intune, ce challenge est fourni de manière dynamique et unique pour chaque appareil, ce qui est bien plus sécurisé qu'un mot de passe statique partagé par tous les appareils. Étape 3 : l'appareil génère sa propre paire de clés privée et publique localement. Il crée une demande de signature de certificat - un CSR - à l'aide de la clé publique et l'envoie au serveur SCEP. Voici le point de sécurité critique : la clé privée ne quitte jamais l'appareil. Elle est générée localement, stockée dans l'enclave sécurisée de l'appareil (le TPM sur Windows ou la Secure Enclave sur iOS), et n'est jamais transmise. C'est pourquoi le SCEP est le bon choix pour l'authentification réseau, contrairement au PKCS, où l'autorité de certification génère la clé de manière centralisée et doit la pousser vers l'appareil. Étape quatre : l'Autorité de Certification valide le CSR, le signe avec la clé privée de la CA et renvoie le certificat X.509 signé à l'appareil. L'appareil dispose désormais d'une identité cryptographique unique. Maintenant, comment ce certificat est-il utilisé pour l'authentification 802.1X ? Quand l'appareil se connecte à votre SSID WiFi, le point d'accès - qu'il s'agisse de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist ou Ubiquiti UniFi - agit comme authentificateur. Il ne prend pas la décision d'authentification lui-même. Il transmet l'échange EAP à votre serveur RADIUS. Il peut s'agir de Microsoft NPS, Cisco ISE ou Aruba ClearPass. Le serveur RADIUS initialise un handshake EAP-TLS. L'appareil présente son certificat client provisionné par SCEP. Le serveur RADIUS valide trois éléments : la chaîne de certification remontant jusqu'à la CA racine de confiance, la date d'expiration du certificat, et si le certificat a été révoqué - vérifié par rapport à une liste de révocation de certificats (CRL) ou via l'OCSP (Online Certificate Status Protocol). Si ces trois vérifications réussissent, le serveur RADIUS envoie un message EAP-Success, et le point d'accès ouvre le port. L'appareil est connecté au réseau. Il s'agit d'une authentification mutuelle. L'appareil valide également le certificat du serveur RADIUS. Si quelqu'un configure un point d'accès pirate, l'appareil le rejettera car le certificat du serveur ne sera pas validé par la CA de confiance. C'est votre protection contre les attaques de type « evil twin ». Parlons maintenant de la séquence de déploiement dans Microsoft Intune, car c'est la plateforme MDM la plus courante que nous rencontrons dans les environnements d'entreprise. Vous déployez trois profils de configuration Intune, dans un ordre strict. Premièrement, le profil Trusted Root Certificate - qui pousse votre certificat de CA racine sur chaque appareil pour qu'ils fassent confiance à votre PKI. Deuxièmement, le profil SCEP Certificate - qui indique aux appareils l'URL SCEP, le format du nom de l'objet, l'utilisation de la clé et l'utilisation étendue de la clé pour l'authentification client. L'OID pour l'authentification client est 1.3.6.1.5.5.7.3.2. Troisièmement, le profil WiFi - qui spécifie le SSID, définit le type de sécurité sur WPA2-Enterprise ou WPA3-Enterprise, définit le type EAP sur EAP-TLS, et se lie au profil de certificat SCEP. L'ordre est crucial. Le profil WiFi dépend du profil SCEP, qui lui-même dépend du profil Trusted Root. Déployez-les dans le désordre et vous obtiendrez des erreurs. Une décision d'architecture que vous devez prendre est l'emplacement d'hébergement du serveur NDES. Il doit être accessible depuis Internet pour que les appareils puissent s'enrôler avant leur arrivée sur site. La méthode sécurisée consiste à publier l'URL NDES via Microsoft Entra ID Application Proxy. Cela évite d'ouvrir des ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enrôlement. Pour les organisations qui souhaitent éliminer totalement l'infrastructure sur site, les fournisseurs de PKI cloud - la solution Cloud PKI de Microsoft dans Intune, ou des options tierces - suppriment complètement la dépendance au NDES. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Laissez-moi vous présenter les trois modes de défaillance les plus courants que nous constatons. Mode de défaillance un : non-correspondance du ciblage des groupes. C'est la cause la plus fréquente d'échec du déploiement des profils WiFi dans Intune. Si votre profil de racine de confiance (Trusted Root) est attribué à un groupe d'utilisateurs, votre profil SCEP à un groupe d'appareils, et votre profil WiFi à un autre groupe d'utilisateurs, Intune ne peut pas résoudre la chaîne de dépendance. Les trois profils doivent cibler exactement le même groupe Azure AD - soit uniquement des utilisateurs, soit uniquement des appareils. Choisissez-en un et restez cohérent. Mode de défaillance deux : disponibilité de la CRL. Votre serveur RADIUS vérifie la CRL pour s'assurer que les certificats n'ont pas été révoqués. Si le point de distribution de la CRL (l'URL CDP intégrée dans le certificat) est inaccessible, l'authentification échoue pour tous les appareils. C'est une cause fréquente de pannes massives après des modifications réseau. Assurez-vous que vos CDP sont hautement disponibles, idéalement publiés sur une URL interne et une URL externe pour les appareils distants. Envisagez l'OCSP comme une alternative plus résiliente à la vérification CRL. Mode de défaillance trois : non-application de la validation du certificat serveur sur les clients. C'est la configuration erronée la plus impactante dans les déploiements 802.1X. Si votre profil WiFi déployé par MDM ne spécifie pas l'autorité de certification (CA) de confiance et le nom attendu du serveur RADIUS, les appareils se connecteront à n'importe quel serveur présentant n'importe quel certificat. Cela annule tout l'intérêt d'EAP-TLS. Configurez toujours la validation du serveur dans votre profil WiFi. [SECTION: Questions-Réponses rapides - environ 1 minute] Passons à quelques questions rapides. Question : Avons-nous besoin du WPA3 ? Oui. Migrez vers le WPA3-Enterprise. Il impose les trames de gestion protégées (PMF), ce qui bloque les attaques par déauthentification. Tous les équipements de Cisco Meraki, HPE Aruba, Ruckus et Juniper Mist le prennent en charge. Question : Qu'en est-il des appareils qui ne supportent pas le 802.1X - comme les capteurs IoT ou les anciennes imprimantes ? Utilisez le contournement d'authentification MAC (MAC Authentication Bypass) comme solution de repli, mais placez ces appareils sur un VLAN fortement restreint sans aucun accès aux ressources de l'entreprise. Question : Comment Purple s'intègre-t-il là-dedans ? La plateforme de Guest WiFi de Purple gère la couche d'accès des visiteurs et des invités - le Captive Portal, la capture de données, les analyses. Votre infrastructure 802.1X et SCEP gère l'accès du personnel et des appareils gérés. Ils fonctionnent sur des SSID distincts et des VLAN distincts. Purple s'intègre avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet - votre investissement matériel est donc protégé. [SECTION: Résumé et prochaines étapes - environ 1 minute] Pour conclure. SCEP automatise la délivrance des certificats à grande échelle. La clé privée reste sur l'appareil - c'est l'avantage de sécurité par rapport au PKCS. Déployez via MDM dans un ordre strict : racine de confiance, puis profil SCEP, puis profil WiFi, en ciblant tous le même groupe. Publiez NDES via un proxy d'application ou passez à une infrastructure PKI cloud. Imposez la vérification CRL ou OCSP sur votre serveur RADIUS. Et configurez toujours la validation du certificat serveur sur les demandeurs clients. Si vous utilisez encore une clé pré-partagée unique pour le WiFi de votre personnel, c'est le changement à opérer ce trimestre. L'infrastructure de certificats demande plus de travail au départ, mais elle élimine toute une catégorie d'attaques basées sur les identifiants et réduit généralement les tickets d'assistance liés au WiFi de 70 à 80 % une fois déployée. Pour obtenir le guide technique complet, les schémas d'architecture et des exemples concrets, rendez-vous sur purple dot ai. Merci pour votre écoute.