Le guide de l'entreprise pour SCEP : Déployer le protocole SCEP (Simple Certificate Enrollment Protocol) pour la sécurité automatisée du WiFi sur les campus

Bonjour. Si vous gerez une infrastructure WiFi au sein d'un groupe hôtelier, d'un réseau de points de vente, d'un stade ou d'un campus universitaire, ce briefing s'adresse à vous. Nous allons aborder SCEP (Simple Certificate Enrollment Protocol) et, plus particulièrement, la manière dont il résout l'un des problèmes les plus persistants du WiFi d'entreprise : le déploiement automatique de certificats sur des milliers d'appareils, sans que votre support technique ne soit submergé de tickets. [short pause] Permettez-moi de planter le décor. Vous avez décidé – à juste titre – que les clés pré-partagées ne sont plus acceptables pour le WiFi du personnel. Un seul mot de passe compromis expose l'ensemble de votre segment réseau. Vous êtes passé, ou vous êtes en train de passer, à l'authentification 802.1X. Il s'agit de la norme IEEE qui exige que chaque appareil prouve son identité avant d'obtenir un accès au réseau. La version la plus sécurisée de la norme 802.1X est EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), qui utilise des certificats numériques plutôt que des mots de passe. Les certificats sont cryptographiquement uniques par appareil, ils ne peuvent pas être partagés et ils peuvent être révoqués instantanément si un appareil est perdu ou si un employé s'en va. [short pause] Jusqu'ici, tout va bien. Le problème réside dans la distribution. Comment installer un certificat unique sur chaque ordinateur portable, chaque téléphone, chaque tablette de votre parc – sous Windows, iOS, Android, macOS – sans qu'un technicien n'ait à manipuler chaque appareil ? C'est précisément ce que résout SCEP. [medium pause] Le protocole SCEP a été formalisé par l'Internet Engineering Task Force dans la RFC 8894 en 2020, bien qu'il soit utilisé dans les environnements d'entreprise depuis le début des années 2000. C'est un protocole qui permet à un appareil géré de demander son propre certificat directement à votre autorité de certification, en utilisant une URL préconfigurée et un mot de passe de défi (challenge password). Le point de sécurité crucial ici : la clé privée est générée sur l'appareil lui-même, stockée dans l'enclave sécurisée de l'appareil – à savoir la puce TPM sur les appareils Windows, ou la Secure Enclave sur le matériel Apple – et elle ne transite jamais sur le réseau. L'appareil génère une demande de signature de certificat (CSR), l'envoie à la passerelle SCEP, la passerelle valide le défi, transmet la demande à votre autorité de certification, la CA la signe, et le certificat signé est renvoyé à l'appareil. L'ensemble du processus est invisible pour l'utilisateur final. [short pause] Dans un environnement Microsoft, la passerelle SCEP est généralement NDES (Network Device Enrollment Service), un rôle Windows Server qui sert d'intermédiaire entre votre plateforme MDM et votre CA. Microsoft Intune pousse le profil SCEP vers les appareils gérés, ce qui leur indique l'URL NDES et le mot de passe de défi. Les appareils s'occupent du reste automatiquement. [medium pause] Laissez-moi vous présenter un exemple concret de déploiement. Prenons un groupe hôtelier de 150 établissements. Ils disposent d'un parc mixte d'ordinateurs portables Windows pour le personnel de réception, d'appareils iOS pour les gouvernantes et de tablettes Android pour les points de vente des restaurants. Avant SCEP, ils utilisaient le protocole WPA2-Personal avec un mot de passe partagé renouvelé chaque trimestre. Chaque rotation générait une vague d'appels au support technique. Avec SCEP et Intune, ils déploient trois profils successifs. Premièrement, le profil de certificat racine de confiance – qui indique à chaque appareil de faire confiance à l'autorité de certification de l'entreprise. Deuxièmement, le profil de certificat SCEP – qui ordonne aux appareils d'aller récupérer leur certificat client unique. Troisièmement, le profil WiFi – qui configure l'SSID, définit le type de sécurité sur WPA2-Enterprise ou WPA3-Enterprise, et pointe vers le certificat SCEP pour l'authentification. Déployez ces trois profils sur le même groupe d'appareils dans Intune, et chaque appareil géré se connecte automatiquement à l'SSID de l'entreprise, avec un certificat unique, sans aucune interaction de l'utilisateur. [short pause] Le serveur RADIUS – généralement Microsoft NPS ou un service RADIUS cloud – reçoit la demande d'authentification EAP-TLS, valide le certificat auprès de la CA, vérifie la liste de révocation de certificats (CRL) et accorde ou refuse l'accès. Si un employé est licencié, vous révoquez son certificat dans la CA. Son appareil perd l'accès WiFi lors du cycle d'authentification suivant. Aucun renouvellement de mot de passe n'est requis. Plus besoin d'attendre la rotation trimestrielle. [medium pause] On nous interroge souvent sur la différence entre SCEP et PKCS (Public Key Cryptography Standards). Les deux fonctionnent avec Intune. La différence fondamentale réside dans l'endroit où la clé privée est générée. Avec SCEP, elle est générée sur l'appareil. Avec PKCS, la CA génère les deux clés de manière centralisée et pousse la clé privée vers l'appareil. Cela signifie que la clé privée transite sur le réseau, ce qui introduit un risque théorique d'interception. PKCS a sa place – il est mieux adapté au chiffrement des e-mails S/MIME où le séquestre de clés est important. Pour l'authentification WiFi, SCEP est le bon choix. À chaque fois. [short pause] Laissez-moi vous donner un second scénario : un réseau de points de vente. Imaginez une enseigne de prêt-à-porter comptant 200 magasins, chacun équipé de points d'accès Cisco Meraki. Leurs systèmes de point de vente fonctionnent sous Windows et sont gérés via Intune. Ils doivent se conformer à la norme PCI DSS, ce qui implique une segmentation du réseau et une authentification forte pour tout appareil traitant des données de titulaires de cartes. EAP-TLS basé sur SCEP leur offre une authentification au niveau de l'appareil sur l'SSID du personnel, avec une attribution de VLAN pilotée par la politique RADIUS. Les terminaux de point de vente se retrouvent automatiquement sur le VLAN dédié au périmètre PCI. Le WiFi invité – géré séparément via une plateforme comme Purple – fonctionne sur un SSID complètement isolé avec son propre flux d'authentification. Les deux réseaux ne se touchent jamais. Les auditeurs sont satisfaits. L'équipe de sécurité dort sur ses deux oreilles. [medium pause] Très bien, parlons maintenant des pièges, car il y en a quelques-uns qui piègent régulièrement les équipes. [short pause] Le mode de défaillance le plus courant est l'incohérence de ciblage des groupes dans Intune. Votre profil de racine de confiance, votre profil SCEP et votre profil WiFi doivent tous cibler le même groupe Azure AD. Si le profil SCEP cible un groupe d'utilisateurs et que le profil WiFi cible un groupe d'appareils, Intune ne peut pas résoudre la dépendance et le profil WiFi s'affiche en erreur. Vérifiez d'abord vos affectations – c'est presque toujours la cause du problème. [short pause] Deuxième piège : la disponibilité du serveur NDES. Votre serveur NDES doit être accessible depuis Internet pour que les appareils distants puissent s'enregistrer avant d'arriver sur site. La méthode sécurisée pour y parvenir consiste à utiliser Azure AD Application Proxy, qui vous offre un accès à distance sans ouvrir de ports de pare-feu entrants. N'exposez pas NDES directement sur Internet. [short pause] Troisièmement : la disponibilité de la CRL. Votre serveur RADIUS vérifie la liste de révocation de certificats à chaque fois qu'un appareil s'authentifie. Si le point de distribution de la CRL est inaccessible – par exemple si un serveur est en panne ou si une règle de pare-feu a changé –, l'authentification échoue pour tout le monde. Rendez vos points de terminaison CRL hautement disponibles et testez-les régulièrement. [short pause] Quatrièmement : les autorisations des modèles de certificats. Si le compte de service de votre connecteur NDES ne dispose pas des autorisations de lecture et d'inscription (Read and Enroll) sur le modèle de certificat, les appareils reçoivent des erreurs HTTP 403 lorsqu'ils tentent de récupérer leur certificat. C'est une simple correction d'autorisations, mais elle est facile à oublier lors de la configuration initiale. [medium pause] Passons maintenant à une série de questions-réponses rapides. [short pause] SCEP peut-il fonctionner avec des MDM non-Microsoft ? Oui – Jamf pour les parcs d'appareils Apple, VMware Workspace ONE et la plupart des plateformes MDM d'entreprise prennent en charge les profils SCEP. Le protocole est indépendant des fournisseurs. [short pause] SCEP fonctionne-t-il avec une PKI cloud ? Oui. La propre PKI cloud de Microsoft dans Intune Suite élimine complètement le besoin d'un serveur NDES sur site. Des fournisseurs de PKI cloud tiers comme SecureW2 et Keyfactor proposent également des points de terminaison SCEP dans le cloud. [short pause] Qu'en est-il de WPA3-Enterprise ? WPA3-Enterprise utilise la même pile d'authentification 802.1X et EAP-TLS. Les certificats émis par SCEP fonctionnent de manière identique. La mise à niveau se situe au niveau du protocole sans fil, et non au niveau du certificat. [short pause] Quelle est la durée de validité des certificats ? Généralement un an, bien que vous puissiez configurer des périodes de validité plus courtes. Intune gère le renouvellement automatique avant l'expiration, de sorte que les utilisateurs ne subissent jamais d'interruption. [medium pause] En résumé. SCEP automatise la distribution des certificats à grande échelle, éliminant ainsi la charge de travail manuelle liée au déploiement d'une PKI sur de grands parcs d'appareils. La clé privée reste sur l'appareil – c'est le fondement de la sécurité d'EAP-TLS. Déployez dans l'ordre : d'abord la racine de confiance, puis le profil SCEP, puis le profil WiFi, tous ciblant le même groupe. Publiez votre point de terminaison NDES de manière sécurisée via Application Proxy. Maintenez vos points de terminaison CRL hautement disponibles. Et si vous partez de zéro, évaluez une PKI cloud pour supprimer complètement la dépendance à un serveur NDES sur site. [short pause] Pour le WiFi invité – le réseau distinct destiné aux visiteurs –, l'authentification par certificat n'est pas le modèle adapté. Les invités ne disposent pas d'appareils gérés. C'est là qu'une plateforme comme Purple gère le flux d'authentification : Captive Portal, connexion via les réseaux sociaux, collecte d'e-mails ou vérification par SMS, le tout alimentant une base de données de première partie que votre équipe marketing peut réellement exploiter. Les deux approches sont complémentaires : SCEP pour votre parc d'appareils gérés du personnel, Purple pour votre réseau invité. Les deux fonctionnent sur le même matériel, proprement segmentés par VLAN. [short pause] Voilà pour ce briefing sur l'intégration du WiFi d'entreprise avec SCEP. Le guide écrit complet, avec les schémas d'architecture, la configuration étape par étape d'Intune et des exemples concrets, est disponible sur le site Web de Purple. Merci pour votre écoute.