Comment configurer SCEP pour un WiFi d'entreprise sécurisé et le provisionnement BYOD

Bienvenue dans ce briefing technique de Purple. Je suis votre hôte, et aujourd'hui nous plongeons au cœur de la configuration de SCEP pour la sécurisation du WiFi d'entreprise et l'approvisionnement des terminaux BYOD. Pour les responsables informatiques, les architectes réseau et les CTO opérant dans l'hôtellerie, le commerce de détail et le secteur public, la gestion des accès réseau est un compromis permanent entre sécurité et efficacité opérationnelle. Vous devez gérer des centaines, parfois des milliers de terminaux se connectant à votre réseau chaque jour. Smartphones des collaborateurs, ordinateurs portables des prestataires, tablettes de point de vente. Et les anciennes méthodes pour gérer cela ne sont tout simplement plus adaptées. S'appuyer sur des clés pré-partagées, ou PSK, pour le WiFi des collaborateurs et du BYOD est une vulnérabilité de sécurité qui ne demande qu'à être exploitée. Un mot de passe partagé, une fois compromis, donne à n'importe qui un accès à votre réseau. Et le contournement de l'authentification MAC, ou MAB, n'est pas meilleur. Les smartphones modernes utilisent par défaut des adresses MAC aléatoires, ce qui rend le MAB totalement inopérant, et les adresses MAC peuvent être usurpées en quelques secondes. L'architecture réseau moderne exige une authentification 802.1X utilisant EAP-TLS. Cela garantit que chaque terminal est vérifié de manière cryptographique avant de toucher au réseau. Mais voici le défi : comment distribuer des certificats clients uniques à des milliers de terminaux non gérés sans submerger votre centre d'assistance ? La réponse est le Simple Certificate Enrolment Protocol, ou SCEP. Commençons par l'architecture. SCEP est la norme de l'industrie pour l'enrôlement des terminaux d'entreprise, définie dans la RFC 8894. Créée à l'origine par VeriSign en 1999, elle a résisté à l'épreuve du temps car elle résout de manière élégante un problème véritablement complexe. Dans un flux de travail SCEP, le terminal génère sa propre paire de clés privée et publique localement. Il crée une demande de signature de certificat, ou CSR, et l'envoie via un service d'enrôlement de terminaux réseau, appelé NDES, à votre autorité de certification, ou CA. La CA valide la demande et renvoie le certificat public signé au terminal. L'avantage de sécurité critique ici est que la clé privée ne quitte jamais le terminal. Elle est générée localement et stockée dans l'enclave sécurisée matérielle du terminal. Sur un ordinateur portable Windows, il s'agit du Trusted Platform Module, ou TPM. Sur un iPhone, c'est la Secure Enclave. La clé privée n'est jamais transmise sur le réseau. C'est ce qui rend SCEP largement supérieur aux alternatives comme PKCS pour l'authentification réseau, où la CA génère la paire de clés de manière centralisée et la transmet au terminal. Maintenant, parlons du BYOD. C'est là que cela devient vraiment intéressant d'un point de vue opérationnel. Vous souhaitez que vos collaborateurs puissent utiliser leurs terminaux personnels pour accéder aux outils internes, mais vous ne voulez pas les contraindre à s'enrôler dans le MDM de votre entreprise. C'est un problème de confidentialité, et cela suscite une forte résistance de la part du personnel. La solution est un portail d'intégration en libre-service. Voici comment cela fonctionne. L'utilisateur connecte son appareil personnel à un SSID de provisionnement dédié. Ce réseau est un jardin fermé (walled garden), limitant l'accès à tout sauf au portail d'intégration et à votre fournisseur d'identité. L'utilisateur s'authentifie à l'aide de ses identifiants d'entreprise, généralement via une intégration SAML avec Microsoft Entra ID, Okta ou Google Workspace. Une fois l'authentification réussie, le système génère un certificat client unique et spécifique à l'appareil via SCEP. Un profil de configuration est poussé sur l'appareil, contenant le certificat, le certificat de l'autorité de certification racine (Root CA) et les paramètres réseau. L'appareil se connecte ensuite automatiquement au SSID sécurisé de l'entreprise à l'aide d'EAP-TLS. C'est transparent pour l'utilisateur et sécurisé pour l'entreprise. Ils n'ont besoin de rien savoir sur les certificats ou le 802.1X. Ils se connectent simplement une seule fois et ils sont connectés. Maintenant, passons en revue l'implémentation en détail. La séquence de déploiement est essentielle, et se tromper est la cause d'échec la plus fréquente. Étape un : déployez le certificat racine de confiance (Trusted Root). Avant qu'un appareil puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice. Exportez votre certificat Root CA sous forme de fichier .cer et déployez-le sur vos groupes d'appareils cibles. Cette étape n'est pas négociable. Sans elle, toute la chaîne échoue. Étape deux : configurez le profil de certificat SCEP. Cela indique aux appareils comment obtenir leur certificat client. Vous devez configurer le format du nom de l'objet (subject name). Pour une authentification gérée par l'utilisateur, la norme est CN égal à UserPrincipalName. Pour l'authentification de l'appareil, utilisez CN égal à l'ID d'appareil Azure AD. Définissez l'utilisation de la clé sur signature numérique et chiffrement de clé (digital signature et key encipherment). Sous l'utilisation étendue de la clé (extended key usage), spécifiez l'authentification client (Client Authentication) avec l'OID 1.3.6.1.5.5.7.3.2. Liez ce profil au profil de certificat de confiance Root CA de l'étape un, et fournissez l'URL externe de votre serveur NDES. Étape trois : déployez le profil WiFi 802.1X. Cela lie les certificats au SSID du réseau. Saisissez le nom du réseau exactement tel qu'il est diffusé par vos points d'accès. Définissez le type de sécurité sur WPA2-Enterprise ou WPA3-Enterprise. Définissez le type EAP sur EAP-TLS. Sélectionnez le profil de certificat SCEP comme certificat d'authentification client, et spécifiez le certificat de confiance Root CA pour la validation du serveur. Cette séquence est l'élément le plus important à retenir de toute cette présentation. La confiance, puis le certificat, puis le WiFi. Dans cet ordre, à chaque fois. Laissez-moi maintenant vous présenter quelques bonnes pratiques qui vous éviteront des difficultés majeures en production. Tout d'abord, publiez votre serveur NDES via le proxy d'application Azure AD. Le serveur NDES doit être accessible depuis Internet pour permettre aux appareils distants de provisionner des certificats avant d'arriver sur site. Cependant, exposer directement un serveur interne à Internet représente un risque de sécurité important. Le proxy d'application vous offre un accès à distance sécurisé sans ouvrir de ports de pare-feu entrants. Deuxièmement, implémentez des certificats à courte durée de vie pour les appareils BYOD. Au lieu d'un certificat valide pendant trois ans, émettez des certificats valides pour 90 jours. Lorsque le certificat expire, l'utilisateur doit se réauthentifier via le portail d'intégration. Cela permet d'éliminer naturellement les appareils obsolètes du réseau. Un appareil qui n'a pas été utilisé depuis 90 jours est simplement retiré. Aucun nettoyage manuel n'est requis. Troisièmement, et c'est absolument crucial, configurez votre serveur RADIUS pour appliquer une vérification stricte de la liste de révocation de certificats (CRL). Lorsqu'un employé quitte l'organisation, la désactivation de son compte Active Directory peut ne pas révoquer immédiatement son accès WiFi si son certificat client reste valide. Votre serveur RADIUS doit vérifier la CRL avant d'accorder l'accès. Assurez-vous que vos points de distribution CRL sont hautement disponibles. Si le serveur RADIUS ne peut pas atteindre la CRL, l'authentification échoue pour tout le monde. C'est une panne généralisée. Examinons maintenant certains modes de défaillance courants et comment les éviter. Le problème le plus fréquent est l'échec de l'application du profil WiFi. L'appareil reçoit la racine de confiance et les certificats SCEP, mais le profil WiFi s'affiche comme Erreur dans la console MDM. Neuf fois sur dix, il s'agit d'une incompatibilité de ciblage de groupe. Si le profil SCEP est attribué à un groupe d'utilisateurs, mais que le profil WiFi est attribué à un groupe d'appareils, le MDM ne peut pas résoudre la dépendance. Auditez vos attributions. Assurez-vous que les trois profils ciblent exactement le même groupe. Le deuxième problème courant est lié aux erreurs NDES 403 Forbidden. Les appareils ne parviennent pas à récupérer le certificat SCEP et les journaux NDES IIS affichent des erreurs HTTP 403. Cela est généralement dû au fait que le compte de service du connecteur ne dispose pas des autorisations nécessaires sur le modèle de certificat, ou qu'un pare-feu bloque les paramètres de chaîne de requête spécifiques utilisés par SCEP. Vérifiez que le compte du connecteur dispose des autorisations de lecture et d'inscription sur le modèle de l'autorité de certification. Vérifiez les journaux de votre pare-feu pour vous assurer que les URL contenant le paramètre operation equals GetCACaps ne sont pas bloquées. Permettez-moi de vous présenter deux scénarios réels pour illustrer comment cela se passe dans la pratique. Premier scénario : un hôtel de 200 chambres avec 50 membres du personnel de ménage utilisant des smartphones personnels pour accéder à l'application de planification. Le responsable informatique souhaite éviter un enregistrement MDM complet afin de respecter la vie privée du personnel. La solution est un portail en libre-service intégré à Microsoft Entra ID. Le personnel se connecte au SSID de provisionnement, se connecte avec ses identifiants Microsoft Entra ID et télécharge un profil SCEP. Le serveur SCEP émet un certificat client de 30 jours directement sur l'appareil. L'appareil se connecte au SSID WiFi du personnel à l'aide d'EAP-TLS. Le serveur RADIUS attribue ces appareils à un VLAN restreint qui permet uniquement l'accès à l'application de planification. Lorsqu'un membre du personnel démissionne, son compte Microsoft Entra ID est désactivé et le serveur RADIUS refuse instantanément l'accès au réseau. Deuxième scénario : une chaîne nationale de vente au détail de 500 magasins déployant un WiFi sécurisé pour les tablettes de point de vente appartenant à l'entreprise. L'architecte réseau doit s'assurer que même si une tablette est volée, les identifiants ne peuvent pas être extraits. La solution est Microsoft Intune qui déploie des certificats via SCEP. Intune pousse le certificat racine de confiance, suivi d'un profil SCEP qui ordonne à la tablette de générer sa propre clé privée dans son enclave matérielle sécurisée. La tablette soumet une demande CSR au serveur NDES, reçoit le certificat client et se connecte au SSID Retail POS en utilisant EAP-TLS. Comme la clé privée est générée localement et n'est jamais transmise, les identifiants d'une tablette volée ne peuvent pas être utilisés ailleurs. Cela répond aux exigences de conformité PCI DSS. Parlons maintenant de l'analyse de rentabilisation. La transition vers le déploiement de certificats SCEP 802.1X offre des rendements mesurables en matière de sécurité et d'opérations. Le WiFi basé sur un mot de passe génère un volume important de tickets d'assistance. Expirations de mots de passe, verrouillages, fautes de frappe. L'authentification par certificat est invisible pour l'utilisateur. Les appareils se connectent automatiquement. Cela réduit généralement le volume de tickets d'assistance liés au WiFi de 70 %. Il s'agit d'une réduction matérielle des coûts opérationnels. EAP-TLS élimine le risque de collecte d'identifiants et d'attaques de type Man-in-the-Middle. C'est essentiel pour la conformité avec PCI DSS dans les environnements de vente au détail et le GDPR dans tous les secteurs. Le coût d'une violation de données dépasse de loin le coût du déploiement d'une infrastructure PKI appropriée. Et pour les organisations qui exploitent déjà le WiFi invité et la plateforme d'analyse de Purple, l'extension de l'intégration sécurisée aux appareils BYOD du personnel offre une stratégie de gestion de réseau unifiée. L'overlay cloud de Purple, indépendant du matériel, s'intègre avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks et Fortinet, vous évitant ainsi d'être lié à un seul fournisseur de matériel. Purple opère sur 80 000 sites actifs et a traité 440 millions de connexions en 2024, détenant les certifications ISO 27001, GDPR, CCPA et Cyber Essentials. Permettez-moi de conclure par un résumé rapide des décisions clés que vous devez prendre. Devez-vous utiliser SCEP ou PKCS ? Utilisez SCEP pour l'authentification WiFi. La clé privée reste sur l'appareil. N'utilisez PKCS que pour le chiffrement des e-mails lorsque le séquestre de clés est requis. Quelle doit être la durée de validité des certificats ? 90 jours pour le BYOD. Un à deux ans pour les appareils gérés par l'entreprise. Devez-vous cibler les utilisateurs ou les appareils dans votre MDM ? Ciblez les appareils pour les terminaux d'entreprise qui doivent se connecter avant la session de l'utilisateur. Ciblez les utilisateurs pour le BYOD où le certificat doit être lié à l'individu. Comment gérer la fragmentation d'Android ? Utilisez Passpoint, également connu sous le nom de Hotspot 2.0, dans la mesure du possible. Il offre une expérience de connexion cohérente pour tous les fabricants d'appareils Android. Et enfin, quel est l'élément le plus important à réussir ? La vérification CRL sur votre serveur RADIUS. Sans cela, un certificat révoqué peut toujours accorder un accès au réseau. C'est la fin du point d'information d'aujourd'hui. Si vous souhaitez approfondir l'un de ces sujets, les guides techniques de Purple sur la sécurité WiFi d'entreprise et l'authentification par certificat EAP-TLS sont disponibles sur le site Web de Purple à l'adresse purple.ai. Merci pour votre écoute.