Automatisation de la sécurité WiFi d'entreprise : le guide de déploiement des certificats SCEP

Bienvenue dans ce briefing technique. Je suis ravi de vous présenter notre dernier guide : Automatiser la sécurité WiFi d'entreprise, en se concentrant spécifiquement sur le déploiement de certificats SCEP. Si vous gérez des réseaux pour des hôtels, des chaînes de vente au détail ou des espaces publics, vous savez déjà que s'appuyer sur des clés pré-partagées ou de simples Captive Portals pour l'accès du personnel constitue une vulnérabilité de sécurité majeure. Aujourd'hui, nous parlons de la référence absolue : l'authentification 802.1X utilisant l'EAP-TLS. Plongeons dans l'architecture. Le défi principal avec l'EAP-TLS ne réside pas dans le protocole lui-même, mais dans la logistique de distribution de certificats clients uniques sur des milliers d'appareils, qu'il s'agisse d'ordinateurs portables Windows, d'iPads ou de tablettes de point de vente. C'est là que les plateformes de gestion des terminaux mobiles (MDM), telles que Microsoft Intune ou Jamf, entrent en jeu. Mais comment distribuer ces certificats de manière sécurisée ? Vous avez généralement deux choix : PKCS ou SCEP. Laissez-moi être absolument clair sur ce point : pour l'authentification WiFi, vous voulez SCEP. C'est le Simple Certificate Enrollment Protocol. Voici pourquoi c'est important. Avec SCEP, le MDM demande à l'appareil de générer sa propre clé privée localement. Cette clé reste verrouillée dans le matériel sécurisé de l'appareil. Elle ne transite jamais sur le réseau. L'appareil envoie simplement une demande de signature de certificat (CSR) à votre autorité de certification via une passerelle, généralement un serveur NDES. Comparez cela avec le PKCS, où l'autorité de certification génère la clé privée de manière centralisée et la pousse sur le réseau vers l'appareil. Bien que le PKCS ait sa place — par exemple, pour le chiffrement des e-mails où vous avez besoin d'un séquestre de clés —, transmettre des clés privées sur le réseau est un risque que vous n'avez tout simplement pas besoin de prendre pour l'authentification réseau. Gardez les clés sur l'appareil. Utilisez SCEP. Parlons maintenant de l'implémentation. S'il y a une chose à retenir de ce briefing, c'est cette règle d'or : la confiance avant l'authentification. Vous ne pouvez pas simplement pousser un profil WiFi et espérer que cela fonctionne. Il existe une séquence de déploiement stricte en trois étapes que vous devez suivre. Étape une : Déployer le certificat racine de confiance. Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice. Poussez ce profil en premier. Étape deux : Configurer et pousser le profil de certificat SCEP. Cela indique à l'appareil comment communiquer avec la passerelle SCEP, quel format utiliser pour son nom de sujet, et à quoi sert réellement le certificat — dans ce cas, l'authentification client. Vous devez lier ce profil à la racine de confiance déployée à l'étape une. Étape trois : Déployer le profil WiFi 802.1X. C'est là que vous rassemblez le tout. Vous spécifiez l'SSID, sélectionnez WPA3-Enterprise, définissez le type d'EAP sur EAP-TLS et le pointez vers le certificat SCEP pour l'authentification client. Voici un piège majeur que nous voyons constamment. Un client nous appelle et dit : "Les certificats sont sur l'appareil, mais le profil WiFi affiche une erreur dans Intune." Presque à chaque fois, il s'agit d'une mauvaise correspondance dans le ciblage des groupes. Si vous attribuez le profil SCEP à un groupe « Utilisateurs », mais que vous attribuez le profil WiFi à un groupe « Appareils », le MDM ne peut pas résoudre la dépendance. Faites correspondre exactement vos cibles sur l'ensemble des trois profils. Prenons un scénario réel. Imaginez un hôtel de 200 chambres. Ils disposent de 150 appareils iOS gérés pour le service d'étage. Actuellement, ils utilisent un réseau standard avec mot de passe, et le personnel ne cesse de partager ce mot de passe avec les clients. C'est un cauchemar. En migrant vers le WPA2-Entreprise avec EAP-TLS via SCEP, le directeur informatique élimine complètement le mot de passe. Les appareils iOS s'authentifient silencieusement en arrière-plan à l'aide de leurs certificats. Mais que se passe-t-il si un membre du personnel perd un appareil ou quitte l'entreprise ? Désactiver leur compte Active Directory ne suffit pas, car le certificat sur cet appareil reste cryptographiquement valide. Cela nous amène à un contrôle de sécurité essentiel : la vérification stricte de la CRL. Vous devez configurer votre serveur RADIUS pour qu'il vérifie la liste de révocation des certificats (CRL). Si un appareil est perdu, vous révoquez le certificat auprès de l'AC. Le serveur RADIUS détecte la révocation sur la CRL et bloque immédiatement l'accès au réseau. Sans une vérification stricte de la CRL, votre posture de sécurité est incomplète. Pour conclure, la transition vers un déploiement automatisé de certificats SCEP offre un retour sur investissement massif. Vous constaterez une réduction de 70 à 80 % des tickets d'assistance liés au WiFi, car les utilisateurs ne se retrouvent plus bloqués et ne saisissent plus de mots de passe erronés. Plus important encore, vous éliminez le risque de collecte d'identifiants, vous assurant ainsi de respecter les cadres de conformité tels que PCI DSS et le GDPR. Automatiser la sécurité du WiFi d'entreprise ne consiste pas seulement à tout verrouiller ; il s'agit de faire du chemin sécurisé la voie la plus simple pour vos utilisateurs. Merci pour votre écoute, et n'hésitez pas à consulter le guide écrit complet pour obtenir tous les détails de configuration étape par étape.