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

Automatisation de la révocation des certificats avec OCSP et CRL dans un environnement NAC Une note technique Purple - Environ 10 minutes --- INTRODUCTION ET CONTEXTE - environ 1 minute Bienvenue dans la série de notes techniques Purple. Je suis votre hôte, et nous allons aujourd'hui aborder les mécanismes d'automatisation de la révocation des certificats - plus précisément la manière dont OCSP et CRL fonctionnent au sein d'un environnement Network Access Control, et pourquoi faire le bon choix à ce sujet est l'une des décisions de sécurité les plus négligées lors des déploiements de WiFi d'entreprise. Si vous gérez une chaîne d'hôtels, un parc 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 superflue. C'est la différence entre un réseau qui applique les 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 allons aborder l'architecture technique, passer en revue deux scénarios de déploiement réels et terminer par les questions que votre équipe devrait se poser avant de vous lancer dans un déploiement en production. C'est parti. --- ANALYSE TECHNIQUE APPROFONDIE - environ 5 minutes Tout d'abord, définissons le problème que nous résolvons. Dans tout réseau authentifié via 802.1X - qui est la norme sous-jacente au WiFi d'entreprise, au 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, ils 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 se décline en deux variantes : CRL, qui signifie Certificate Revocation List (liste de révocation de certificats), et OCSP, qui signifie Online Certificate Status Protocol (protocole de vérification de statut de certificat en ligne). Commençons par 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), de chaque numéro de série de certificat qui a é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 à partir d'un point de distribution CRL, qui est simplement un point de terminaison HTTP ou LDAP. Le serveur RADIUS met la liste en cache localement et compare les numéros de série des certificats entrants avec celle-ci lors de la phase d'établissement de liaison (handshake) EAP-TLS. L'avantage opérationnel de CRL réside dans 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 injoignable. L'inconvénient est le temps de latence. Si vous révoquez un certificat à 9 heures du matin et que votre intervalle de rafraîchissement CRL est de 24 heures, cet appareil pourra toujours s'authentifier jusqu'au prochain téléchargement programmé. Dans un environnement hautement sécurisé - un hôpital, un back-office de services financiers, un réseau gouvernemental - ce délai 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 positionné 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 correctement 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 de politique : devez-vous autoriser l'accès par défaut (fail open) - permettant ainsi à l'authentification de se poursuivre - ou bloquer l'accès par défaut (fail closed) - refusant l'accès jusqu'à ce que le répondeur soit joignable ? L'option fail open maintient la disponibilité mais crée une faille de sécurité. L'option fail closed maintient le niveau 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 agrafée plutôt que d'effectuer sa propre requête OCSP. Cela réduit la charge sur l'OCSP Responder, élimine les problèmes de confidentialité liés à 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 demandeurs EAP ne prennent pas en charge l'agrafage, vous devez donc vérifier la compatibilité des clients avant de vous y fier. 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 basée sur FreeRADIUS et PacketFence - se situe entre le demandeur 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. 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 retiré de la gestion 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 rafraîchir son cache CRL selon un calendrier défini, garantissant 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 entre l'autorité de certification (CA) et 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 récupère le changement - soit immédiatement via OCSP, soit lors de la prochaine fenêtre de rafraîchissement de la CRL - et l'accès est refusé à l'appareil lors de sa prochaine tentative d'authentification. --- RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER - environ 2 minutes Laissez-moi vous donner les conseils pratiques qui évitent aux 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 de rafraîchissement 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 verrouillage par défaut (fail-closed) et un cluster de répondeurs hautement disponible. Deuxièmement : n'utilisez pas un seul répondeur OCSP en production. Déployez-en au moins deux, derrière un équilibreur de charge, avec une surveillance de l'état de santé. Une panne de répondeur OCSP qui entraîne un comportement de verrouillage par défaut générera des tickets de support plus rapidement que presque toute autre panne d'infrastructure. Troisièmement : surveillez la taille de votre CRL. Dans les grands déploiements - nous parlons 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 débit 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 à volume élevé. Quatrièmement : testez régulièrement votre pipeline de révocation. Il ne suffit pas de configurer l'OCSP et de supposer qu'il 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 - 24 à 72 heures - réduisent la fenêtre d'exposition des identifiants compromis et peuvent réduire entièrement votre dépendance vis-à-vis de l'infrastructure de révocation. C'est la direction vers laquelle se dirige 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 : essayer d'abord l'OCSP, puis basculer sur la CRL si le répondeur est injoignable. Cela vous offre une vérification en temps réel dans des conditions normales et une résilience hors ligne pendant les pannes. Question : Est-ce que la plateforme WiFi invité de Purple s'intègre avec un NAC basé sur des certificats ?La plateforme de Purple fonctionne 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 d'entreprise exécutant 802.1X avec une 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 des titulaires de cartes 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 par le protocole 802.1X basé sur des certificats avec révocation automatisée - à condition de pouvoir prouver que la révocation est effectuée à temps 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 au niveau du contrôle du réseau. --- RÉSUMÉ ET PROCHAINES ÉTAPES - environ 1 minute Pour résumer : l'automatisation de la révocation des certificats dans un environnement de contrôle d'accès réseau est un problème à trois niveaux. Vous avez besoin d'une autorité de certification 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 la topologie du réseau et de la maturité opérationnelle de votre environnement. Si vous créez ou examinez un déploiement de contrôle d'accès réseau et souhaitez comprendre comment la plateforme WiFi invité et d'analyses de Purple s'intègre dans l'architecture réseau globale, les liens figurant dans les notes de l'émission vous orienteront vers les guides techniques pertinents. Merci pour votre écoute. À bientôt pour le prochain point d'information. --- FIN DU SCRIPT