Automatisation de la révocation des certificats avec OCSP et CRL dans un environnement NAC

Automatiser la révocation des certificats avec OCSP et CRL dans un environnement NAC Un briefing technique Purple — Environ 10 minutes --- INTRODUCTION ET CONTEXTE — environ 1 minute Bienvenue dans la série de briefings techniques Purple. Je suis votre hôte, et nous abordons aujourd'hui les mécanismes de l'automatisation de la révocation des certificats — plus précisément le fonctionnement d'OCSP et des CRL dans un environnement de contrôle d'accès au réseau (NAC), et pourquoi réussir cette mise en œuvre est l'une des décisions de sécurité les plus négligées dans les déploiements WiFi d'entreprise. Si vous gerez une chaîne hôtelière, un réseau de points de vente, un stade ou un réseau du secteur public avec des centaines ou des milliers d'appareils connectés, la gestion du cycle de vie des certificats n'est pas une option. C'est ce qui fait la différence entre un réseau qui applique ses politiques en temps réel et un autre qui héberge discrètement des identifiants révoqués provenant d'appareils qui auraient dû être déconnectés depuis des semaines. Nous aborderons l'architecture technique, passerons en revue deux scénarios réels de déploiement et terminerons par les questions que votre équipe devrait se poser avant de lancer un déploiement en production. C'est parti. --- ANALYSE TECHNIQUE APPROFONDIE — environ 5 minutes Tout d'abord, définissons le problème que nous cherchons à résoudre. Dans tout réseau authentifié IEEE 802.1X — le standard qui sous-tend le WiFi d'entreprise, le NAC filaire et la plupart des architectures modernes d'accès invité —, les appareils s'authentifient à l'aide d'identifiants ou de certificats. Les certificats sont préférables car ils ne reposent pas sur des secrets partagés, ils sont liés à l'appareil et s'intègrent parfaitement aux plateformes MDM via des protocoles comme SCEP. Mais les certificats ont un cycle de vie. Ils expirent, sont compromis, et les appareils sont mis hors service. Lorsque l'un de ces événements se produit, vous avez besoin d'un mécanisme pour indiquer à votre infrastructure réseau : ce certificat n'est plus valide, cessez de lui faire confiance. Ce mécanisme existe sous deux formes : la CRL (Certificate Revocation List ou liste de révocation de certificats) et l'OCSP (Online Certificate Status Protocol). Commençons par la CRL. Une liste de révocation de certificats est exactement ce que son nom indique — une liste signée, publiée par votre autorité de certification (CA), contenant le numéro de série de chaque certificat ayant été révoqué. Votre infrastructure NAC — généralement un serveur RADIUS comme FreeRADIUS, Cisco ISE ou Aruba ClearPass — télécharge périodiquement cette liste depuis un point de distribution CRL (CRL Distribution Point), qui est simplement un point de terminaison HTTP ou LDAP. Le serveur RADIUS met en cache la liste localement et vérifie les numéros de série des certificats entrants par rapport à celle-ci lors de la liaison (handshake) EAP-TLS. L'avantage opérationnel de la CRL est sa simplicité et sa résilience hors ligne. Une fois la liste téléchargée, la vérification de la révocation fonctionne même si votre CA est inaccessible. L'inconvénient est la latence. Si vous révoquez un certificat à 9 heures du matin et que votre intervalle de rafraîchissement de la CRL est de 24 heures, cet appareil pourrait toujours s'authentifier jusqu'au prochain téléchargement planifié. Dans un environnement hautement sécurisé — un hôpital, le back-office de services financiers, un réseau gouvernemental —, cette fenêtre de vulnérabilité est inacceptable. OCSP résout le problème de latence. Au lieu de maintenir une liste locale en cache, votre serveur RADIUS envoie une requête en temps réel à un OCSP Responder — un service placé devant votre CA — pour chaque certificat qu'il doit valider. Le répondeur renvoie l'une des trois réponses suivantes : Good, Revoked ou Unknown. L'ensemble de l'échange se fait en ligne, pendant le handshake EAP-TLS, généralement en moins de 100 millisecondes sur une infrastructure bien dimensionnée. Le compromis avec OCSP réside dans la dépendance à la disponibilité. Si votre OCSP Responder tombe en panne, ou si votre serveur RADIUS ne peut pas l'atteindre en raison d'un cloisonnement du réseau, vous devez prendre une décision politique : optez-vous pour un mode "fail open" — permettant à l'authentification de se poursuivre — ou "fail closed" — refusant l'accès jusqu'à ce que le répondeur soit joignable ? Le mode "fail open" maintient la disponibilité mais crée une faille de sécurité. Le mode "fail closed" maintient la posture de sécurité mais peut bloquer des utilisateurs légitimes lors d'un incident d'infrastructure. Il existe une troisième option intéressante : l'OCSP Stapling. Dans ce modèle, le détenteur du certificat — l'appareil client — récupère périodiquement une réponse OCSP signée auprès du répondeur et l'associe au handshake TLS. Le serveur RADIUS valide la réponse intégrée (stapled) plutôt que d'effectuer sa propre requête OCSP. Cela réduit la charge sur l'OCSP Responder, élimine le problème de confidentialité lié à l'exposition des numéros de série des certificats à un service externe, et améliore la résilience. L'inconvénient est que tous les supplicants EAP ne prennent pas en charge le stapling, vous devez donc vérifier la compatibilité des clients avant de vous y fier. Maintenant, comment cela s'intègre-t-il dans une architecture NAC ? Votre moteur de politique NAC — qu'il s'agisse de Cisco ISE, Aruba ClearPass, Juniper Mist ou d'une pile open-source construite autour de FreeRADIUS et PacketFence — se situe entre le supplicant et le réseau. Lorsqu'un appareil tente de se connecter, le serveur RADIUS reçoit l'Access-Request, effectue la négociation EAP-TLS, valide la chaîne de certificats du client, vérifie le statut de révocation via OCSP ou CRL, puis émet soit un Access-Accept avec une attribution de VLAN, soit un Access-Reject. L'automatisation intervient à deux niveaux. Tout d'abord, au niveau de la couche d'émission des certificats : votre plateforme MDM — Jamf, Intune, Workspace ONE — utilise SCEP pour provisionner automatiquement les certificats sur les appareils gérés. Lorsqu'un appareil est désinscrit ou mis hors service, le MDM déclenche un appel de révocation vers la CA, qui met à jour la CRL et notifie l'OCSP Responder. Ensuite, au niveau de la couche d'application du NAC : votre serveur RADIUS est configuré pour interroger l'OCSP ou actualiser son cache CRL selon un calendrier défini, garantissant ainsi que les décisions de révocation se propagent à la politique d'accès sans intervention manuelle. Le point d'intégration critique ici est le pipeline de communication de la CA vers le NAC. Dans un déploiement bien conçu, la révocation est une chaîne entièrement automatisée : le MDM déclasse l'appareil, déclenche la révocation par la CA, la CA met à jour le répondeur OCSP et publie une nouvelle CRL, le serveur RADIUS détecte le changement — soit immédiatement via OCSP, soit lors de la prochaine fenêtre d'actualisation de la CRL — et l'accès est refusé à l'appareil lors de sa prochaine tentative d'authentification. --- RECOMMANDATIONS D'IMPLÉMENTATION ET PIÈGES À ÉVITER — environ 2 minutes Voici les conseils pratiques qui éviteront à vos déploiements de dérailler. Premièrement : définissez votre tolérance à la latence de révocation avant de choisir votre mécanisme. Si vous gérez un réseau WiFi pour les clients d'un hôtel où le risque principal est un appareil du personnel déclassé, un intervalle d'actualisation de la CRL de 4 heures est probablement suffisant. Si vous gérez un réseau de santé où un appareil compromis pourrait accéder aux données des patients, vous devez opter pour l'OCSP avec une politique de type « fail-closed » et un cluster de répondeurs hautement disponible. Deuxièmement : n'exécutez pas un seul répondeur OCSP en production. Déployez-en au moins deux, derrière un répartiteur de charge, avec une surveillance de l'état (health monitoring). Une panne de répondeur OCSP entraînant un comportement « fail-closed » générera des tickets d'assistance plus rapidement que presque n'importe quelle autre défaillance d'infrastructure. Troisièmement : surveillez la taille de votre CRL. Dans les grands déploiements — on parle ici de dizaines de milliers de certificats —, les fichiers CRL peuvent atteindre plusieurs mégaoctets. Un serveur RADIUS téléchargeant une CRL de 5 Mo toutes les heures via une liaison WAN est un problème de bande passante assuré. Envisagez les CRL delta, qui ne contiennent que les modifications depuis la dernière CRL complète, ou migrez vers l'OCSP pour les environnements à fort volume. Quatrièmement : testez régulièrement votre pipeline de révocation. Il ne suffit pas de configurer l'OCSP et de supposer que cela fonctionne. Automatisez un test mensuel : émettez un certificat, révoquez-le, tentez une authentification, vérifiez le rejet. Si votre surveillance ne détecte pas un répondeur OCSP en panne, votre mécanisme de révocation n'est que de la figuration. Cinquièmement : alignez les périodes de validité de vos certificats sur votre stratégie de révocation. Les certificats à courte durée de vie — de 24 à 72 heures — réduisent la fenêtre d'exposition des identifiants compromis et peuvent réduire totalement votre dépendance vis-à-vis de l'infrastructure de révocation. C'est la direction que prend l'industrie, et cela vaut la peine de l'évaluer pour les nouveaux déploiements. --- QUESTIONS-RÉPONSES RAPIDES — environ 1 minute Question : Puis-je utiliser à la fois l'OCSP et la CRL simultanément ? Oui. La plupart des implémentations RADIUS prennent en charge une chaîne de secours (fallback) : essayer d'abord l'OCSP, puis se rabattre sur la CRL si le répondeur est injoignable. Cela vous offre une vérification en temps réel en conditions normales et une résilience hors ligne en cas de panne. Question : La plateforme WiFi pour clients de Purple s'intègre-t-elle avec un NAC basé sur des certificats ? La plateforme de Purple opère au niveau de la couche d'accès invité, gérant l'authentification par Captive Portal, la capture de données et les analyses. Pour les réseaux du personnel de l'entreprise utilisant le 802.1X avec authentification par certificat, Purple s'intègre à l'infrastructure réseau sous-jacente — les points d'accès, les contrôleurs et les serveurs RADIUS — plutôt que de remplacer la pile de gestion des certificats. Les réseaux invités et du personnel sont généralement segmentés, avec des mécanismes d'authentification différents et adaptés à chacun. Question : Quel est l'aspect conformité ? PCI DSS 4.0 exige que l'accès aux environnements de données de cartes de paiement utilise une authentification forte. Le GDPR exige des mesures techniques appropriées pour protéger les données personnelles. Ces deux cadres sont respectés grâce au 802.1X basé sur des certificats avec révocation automatisée — à condition de pouvoir prouver que la révocation est effectuée en temps opportun et testée. Votre piste d'audit doit indiquer quand les certificats ont été révoqués et quand cette révocation a été propagée pour application au réseau. --- RÉSUMÉ ET PROCHAINES ÉTAPES — environ 1 minute Pour résumer : l'automatisation de la révocation des certificats dans un environnement NAC est un problème à trois niveaux. Vous avez besoin d'une CA qui prend en charge les déclencheurs de révocation automatisés, d'un répondeur OCSP ou d'un point de distribution CRL hautement disponible et correctement dimensionné, et d'un serveur RADIUS configuré pour appliquer le statut de révocation dans le cadre de sa politique d'accès. Le choix entre OCSP et CRL n'est pas binaire — c'est une décision de tolérance au risque qui doit être prise dans le contexte des exigences de sécurité de votre environnement, de la topologie du réseau et de la maturité opérationnelle. Si vous construisez ou examinez un déploiement NAC et souhaitez comprendre comment la plateforme de Purple WiFi invité et d'analyse s'intègre dans l'architecture réseau globale, les liens dans les notes de l'émission vous orienteront vers les guides techniques pertinents. Merci pour votre écoute. Nous vous retrouverons lors du prochain briefing. --- FIN DU SCRIPT