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 un WiFi d'entreprise sécurisé et le provisionnement BYOD. Pour les responsables informatiques, les architectes réseau et les directeurs techniques opérant dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public, la gestion des accès réseau est un équilibre permanent entre sécurité et efficacité opérationnelle. Vous devez gérer des centaines, parfois des milliers d'appareils qui se connectent chaque jour à votre réseau : smartphones du personnel, ordinateurs portables de prestataires, tablettes de point de vente. Et les anciennes méthodes pour gérer cela ne suffisent tout simplement plus. S'appuyer sur des clés pré-partagées (PSK) pour le WiFi du personnel et du BYOD est une faille de sécurité qui ne demande qu'à être exploitée. Un mot de passe partagé, une fois compromis, donne à n'importe qui l'accès à votre réseau. Et le MAC Authentication Bypass (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 via EAP-TLS. Cela garantit que chaque appareil est vérifié par cryptographie avant d'accéder au réseau. Mais voici le défi : comment distribuer des certificats clients uniques à des milliers d'appareils non gérés sans surcharger votre support technique ? La réponse est le protocole SCEP (Simple Certificate Enrollment Protocol). Commençons par l'architecture. SCEP est la norme de l'industrie pour l'enrôlement des appareils d'entreprise, définie dans la RFC 8894. Il existe depuis 1999, créé à l'origine par VeriSign, et il a résisté à l'épreuve du temps car il résout un problème réellement complexe de manière élégante. Dans un flux de travail SCEP, 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 (CSR) et l'envoie via un service d'enrôlement de certificats pour appareils réseau (NDES) à votre autorité de certification (CA). L'autorité de certification valide la demande et renvoie le certificat public signé à l'appareil. L'avantage de sécurité essentiel ici est que la clé privée ne quitte jamais l'appareil. Elle est générée localement et stockée dans l'enclave matérielle sécurisée de l'appareil. Sur un ordinateur portable Windows, il s'agit du Trusted Platform Module (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ù l'autorité de certification génère la paire de clés de manière centralisée et la transmet à l'appareil. Parlons maintenant du BYOD. C'est là que cela devient vraiment intéressant d'un point de vue opérationnel. Vous souhaitez que le personnel puisse utiliser ses appareils personnels pour accéder aux outils internes, mais vous ne voulez pas l'obliger à s'enrôler dans le MDM de votre entreprise. C'est un problème de confidentialité qui suscite une forte résistance de la part des employés. 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 environnement 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 propre à l'appareil via SCEP. Un profil de configuration est poussé sur l'appareil, contenant le certificat, le certificat de l'autorité de certification racine et les paramètres réseau. L'appareil se connecte ensuite automatiquement au SSID sécurisé de l'entreprise via EAP-TLS. C'est transparent pour l'utilisateur et sécurisé pour l'entreprise. Ils n'ont pas besoin de connaître quoi que ce soit sur les certificats ou le 802.1X. Ils se connectent une seule fois et ils sont connectés. Passons maintenant en revue la mise en œuvre en détail. La séquence de déploiement est essentielle, et se tromper est la cause d'échec la plus fréquente. Étape une : déployer le certificat racine de confiance. 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 de CA racine sous forme de fichier .cer et déployez-le sur vos groupes d'appareils cibles. Cette étape est non négociable. Sans elle, toute la chaîne échoue. Étape deux : configurer 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 l'authentification basée sur l'utilisateur, la norme est CN égale UserPrincipalName. Pour l'authentification de l'appareil, utilisez CN égale l'ID d'appareil Azure AD. Définissez l'utilisation de la clé sur signature numérique et chiffrement de clé (key encipherment). Sous l'utilisation étendue de la clé, spécifiez l'authentification client avec l'OID 1.3.6.1.5.5.7.3.2. Associez ce profil au profil de certificat racine de confiance de l'étape une. Et fournissez l'URL externe de votre serveur NDES. Étape trois : déployer 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 d'EAP sur EAP-TLS. Sélectionnez le profil de certificat SCEP comme certificat d'authentification client. Et spécifiez le certificat racine de confiance pour la validation du serveur. Cette séquence est l'élément le plus important à retenir de tout ce briefing. Confiance, puis certificat, puis WiFi. Dans cet ordre, à chaque fois. Laissez-moi maintenant vous présenter quelques bonnes pratiques qui vous éviteront bien des soucis en production. Premièrement, 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 leur arrivée sur site. Mais exposer un serveur interne directement à Internet représente un risque de sécurité majeur. 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, délivrez des certificats valides pendant 90 jours. À l'expiration du certificat, l'utilisateur doit se réauthentifier via le portail d'intégration. Cela permet de supprimer naturellement les appareils obsolètes du réseau. Un appareil qui n'a pas été utilisé depuis 90 jours disparaît tout simplement. Aucun nettoyage manuel n'est requis. Troisièmement, et c'est absolument crucial, configurez votre serveur RADIUS pour imposer 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 de 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. Voyons maintenant quelques 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 les certificats de racine de confiance et 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 concerne les erreurs NDES 403 Forbidden. Les appareils ne parviennent pas à récupérer le certificat SCEP, et les journaux IIS de NDES 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'enrôlement 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 égale GetCACaps ne sont pas bloquées. Laissez-moi vous présenter deux scénarios réels pour illustrer comment cela se passe en pratique. Scénario un : un hôtel de 200 chambres avec 50 employés d'entretien utilisant des smartphones personnels pour accéder à l'application de planification. Le responsable informatique souhaite éviter un enrôlement MDM complet pour 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 Entra ID et télécharge un profil SCEP. Le serveur SCEP délivre un certificat client de 30 jours directement à l'appareil. L'appareil se connecte au SSID Staff WiFi via EAP-TLS. Le serveur RADIUS affecte ces appareils à un VLAN restreint qui n'autorise que l'accès à l'application de planification. Lorsqu'un membre du personnel démissionne, son compte Entra ID est désactivé et le serveur RADIUS refuse instantanément l'accès au réseau. Scénario deux : une chaîne nationale de vente au détail de 500 magasins déployant un WiFi sécurisé pour des 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 demande à la tablette de générer sa propre clé privée dans son enclave matérielle sécurisée. La tablette soumet une CSR au serveur NDES, reçoit le certificat client et se connecte au SSID Retail POS via EAP-TLS. La clé privée étant générée localement et n'étant 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'aspect commercial. La transition vers le déploiement de certificats SCEP 802.1X offre des retours mesurables en matière de sécurité et d'opérations. Le WiFi basé sur mot de passe génère un volume important de tickets d'assistance : expirations de mots de passe, verrouillages, fautes de frappe. L'authentification basée sur certificat est invisible pour l'utilisateur. Les appareils se connectent automatiquement. Cela réduit généralement le volume de support lié au WiFi de 70 %. C'est une réduction matérielle des coûts opérationnels. EAP-TLS élimine le risque de collecte d'identifiants et d'attaques de l'homme du milieu. C'est essentiel pour la conformité avec PCI DSS dans les environnements de vente au détail et avec 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 utilisent déjà la plateforme de Guest WiFi et d'analyse de Purple, étendre l'intégration sécurisée aux appareils BYOD du personnel offre une stratégie de gestion de réseau unifiée. La surcouche cloud agnostique de Purple s'intègre à Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet, de sorte que vous n'êtes pas lié à un seul fournisseur de matériel. Purple opère dans 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. Utilisez PKCS uniquement pour le chiffrement des e-mails où 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 utiliser le ciblage par utilisateur ou par appareil dans votre MDM ? Utilisez le ciblage par appareil pour les appareils d'entreprise qui doivent se connecter avant la session utilisateur. Utilisez le ciblage par utilisateur pour le BYOD où le certificat doit être lié à l'individu. Comment gérez-vous 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'Android. Et enfin, quelle est la chose la plus importante à réussir ? La vérification de la CRL sur votre serveur RADIUS. Sans elle, un certificat révoqué peut toujours accorder l'accès au réseau. C'est la fin du briefing d'aujourd'hui. Si vous souhaitez approfondir l'un de ces sujets, les guides techniques de Purple sur la sécurité du 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.