Comment configurer SCEP pour un BYOD sécurisé et l'authentification réseau 802.1X

Bonjour, et bienvenue dans cette présentation technique de Purple. Je suis votre hôte et aujourd'hui, nous allons entrer dans les détails de SCEP - le Simple Certificate Enrollment Protocol - et découvrir 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 d'infrastructures WiFi au sein d'un groupe hôtelier, d'un réseau de points de vente, d'un stade ou d'une organisation du secteur public, ce sujet vous concerne directement. Aujourd'hui, nous ne ferons pas de théorie. Nous allons parler d'architecture et de décisions concrètes. 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 de prestataires 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 existe encore une clé partagée WPA2 que douze personnes connaissent - dont trois ont quitté l'entreprise l'année dernière. Ce n'est pas une posture de sécurité. C'est une vulnérabilité. 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 de travail. La véritable question est de savoir quelle méthode d'authentification l'accompagne. 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 d'Internet Draft par l'IETF en 1999, créé par VeriSign. Il a été formalisé en tant que RFC 8894. Sa fonction est simple : automatiser le processus d'attribution de certificats numériques X.509 aux appareils à grande échelle, sans nécessiter d'intervention humaine pour générer et installer manuellement chacun d'eux. Voici le processus en quatre étapes. Étape un : 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, le Service de d'enregistrement de certificats de l'équipement réseau, soit via un fournisseur PKI cloud. Cette URL est la passerelle vers votre autorité de certification. Étape deux : l'appareil présente un défi SCEP - un secret partagé qui prouve qu'il est autorisé à demander un certificat. Dans un environnement géré par MDM comme Microsoft Intune, ce défi est transmis de manière dynamique et unique pour chaque appareil, ce qui est beaucoup plus sécurisé qu'un mot de passe statique partagé par tous les appareils. Étape trois : l'appareil génère localement sa propre paire de clés privée et publique. 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 - c'est-à-dire le TPM sous Windows ou la Secure Enclave sur iOS - et n'est jamais transmise. C'est pourquoi 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 l'envoyer à l'appareil. Étape quatre : l'Autorité de Certification valide la CSR, la signe avec sa clé privée 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 ? Lorsque 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 lance 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 certificats remontant jusqu'à l'autorité de certification racine de confiance, la date d'expiration du certificat et le fait que le certificat ait été révoqué ou non - vérifié par rapport à une liste de révocation de certificats, ou CRL, ou via OCSP, le protocole de vérification de statut de certificat en ligne. 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 sur le 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 frauduleux, 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 de certificat racine de confiance - celui-ci pousse votre certificat de CA racine vers chaque appareil afin qu'ils fassent confiance à votre PKI. Deuxièmement, le profil de certificat SCEP - celui-ci 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 du client. L'OID pour l'authentification du client est 1.3.6.1.5.5.7.3.2. Troisièmement, le profil WiFi - celui-ci 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 lie au profil de certificat SCEP. L'ordre est important. Le profil WiFi dépend du profil SCEP, qui dépend lui-même du profil de racine de confiance. Déployez-les dans le désordre et vous obtiendrez des erreurs. Une décision d'architecture que vous devez prendre concerne l'emplacement d'hébergement du serveur NDES. Il doit être accessible depuis Internet pour que les appareils puissent s'enregistrer avant d'arriver sur site. La méthode sécurisée pour y parvenir 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'enregistrement. Pour les organisations qui souhaitent éliminer complètement l'infrastructure sur site, les fournisseurs de PKI cloud - la propre solution Cloud PKI de Microsoft dans Intune, ou des options tierces - suppriment totalement la dépendance à NDES. [SECTION : Recommandations de mise en œuvre et pièges à éviter - environ 2 minutes] Laissez-moi vous présenter les trois modes de défaillance les plus courants que nous observons. Premier mode de défaillance : un ciblage de groupe incorrect. C'est la cause la plus fréquente d'échec du déploiement des profils WiFi dans Intune. Si votre profil de certificat racine de confiance 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épendances. 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. Deuxième mode de défaillance : la 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 au certificat - est inaccessible, l'authentification échoue pour tous les appareils. C'est une cause fréquente d'interruptions massives de service après des modifications du 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 de la CRL. Troisième mode de défaillance : l'absence d'obligation de validation du certificat du serveur sur les clients. Il s'agit de la mauvaise configuration la plus impactante dans les déploiements 802.1X. Si votre profil WiFi déployé par MDM ne spécifie pas l'AC de confiance et le nom de serveur RADIUS attendu, les appareils se connecteront à n'importe quel serveur présentant n'importe quel certificat. Cela annule tout l'intérêt du protocole 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 WPA3-Enterprise. Il impose les trames de gestion protégées (PMF), ce qui bloque les attaques par désauthentification. Tous les équipements matériels 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 MAC Authentication Bypass comme solution de secours, 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 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 séparés. 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. Le SCEP automatise la délivrance de 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 : d'abord le certificat racine de confiance, puis le profil SCEP, puis le profil WiFi, en ciblant tous le même groupe. Publiez NDES via Application Proxy ou passez à une PKI cloud. Imposez la vérification CRL ou OCSP sur votre serveur RADIUS. Et configurez toujours la validation du certificat du serveur sur les clients demandeurs. Si vous utilisez encore une clé pré-partagée commune pour le WiFi du personnel, c'est le changement à effectuer ce trimestre. L'infrastructure de certificats représente 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 de support liés au WiFi de 70 à 80 pour cent 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.