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

Automatisation de la révocation de certificats avec OCSP et CRL dans un environnement NAC Une présentation technique Purple - Environ 10 minutes --- INTRODUCTION ET CONTEXTE - environ 1 minute Bienvenue dans la série des présentations techniques Purple. Je suis votre hôte, et aujourd'hui nous allons aborder les mécanismes d'automatisation de la révocation de certificats - plus précisément le fonctionnement de OCSP et CRL 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. Que vous gériez une chaîne hôtelière, un réseau de vente au détail, 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 les politiques de sécurité en temps réel et un réseau 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 de déploiement réels, et terminerons par les questions que votre équipe devrait se poser avant de commencer tout 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é par la norme 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 : la CRL (Certificate Revocation List) et l'OCSP (Online Certificate Status Protocol). Commençons par la CRL. Une Certificate Revocation List est exactement ce que son nom indique : une liste signée, publiée par votre Autorité de Certification, 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, 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 phase d'établissement de liaison (handshake) EAP-TLS. L'avantage opérationnel de la 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 Autorité de Certification est inaccessible. L'inconvénient est le temps de latence. Si vous révoquez un certificat à 9 heures du matin et que l'intervalle de mise à jour de votre CRL est de 24 heures, cet appareil pourra toujours s'authentifier jusqu'au prochain téléchargement planifié. 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, durant le protocole d'accord 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 partitionnement du réseau, vous devez prendre une décision de politique : devez-vous échouer en mode ouvert (fail open) - permettant à l'authentification de se poursuivre - ou en mode fermé (fail closed) - refusant l'accès jusqu'à ce que le répondeur soit accessible ? Le mode fail open maintient le temps de fonctionnement mais crée une faille de sécurité. Le mode 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 qui mérite d'être connue : le 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 protocole d'accord 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 le 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 le stapling, 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. La partie automatisation intervient à deux niveaux. Premièrement, au niveau de la couche de délivrance 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 le OCSP Responder. Deuxièmement, 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 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 l'autorité de certification (CA) vers le contrôle d'accès réseau (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 la modification - 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 DE MISE EN ŒUVRE ET PIÈGES À ÉVITER - environ 2 minutes Voici quelques conseils pratiques pour éviter que vos déploiements ne déraillent. 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 de 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 verrouillage en cas de panne (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 fail-closed générera des tickets d'assistance plus rapidement que presque n'importe quelle autre panne d'infrastructure. Troisièmement : surveillez la taille de votre CRL. Dans les grands déploiements - nous parlons 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 à volume élevé. 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 qu'une façade. Cinquièmement : alignez les périodes de validité de vos certificats avec votre stratégie de révocation. Les certificats à courte durée de vie - 24 à 72 heures - réduisent la fenêtre d'exposition pour les identifiants compromis et peuvent réduire entièrement votre dépendance vis-à-vis de l'infrastructure de révocation. C'est la direction que prend l'industrie, et cela vaut la peine d'être évalué pour les nouveaux déploiements. --- QUESTIONS-RÉPONSES RAPIDES - environ 1 minute Question : Puis-je utiliser 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 se rabattre 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 pour clients 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 de l'entreprise fonctionnant sous 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 des titulaires de carte 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 à la technologie 802.1X basée sur des certificats avec révocation automatisée - à condition que vous puissiez démontrer que la révocation est opportune et testée. Votre piste d'audit doit indiquer quand les certificats ont été révoqués et quand cette révocation s'est propagée à l'application 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 au réseau est un problème à trois niveaux. Vous avez besoin d'une autorité de certification (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 - il s'agit d'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 construisez ou examinez un déploiement de contrôle d'accès au réseau et souhaitez comprendre comment la plateforme WiFi invité et d'analyse de Purple s'intègre dans l'architecture réseau globale, les liens dans les notes de l'émission vous mèneront aux guides techniques pertinents. Merci de votre écoute. Nous vous retrouverons lors du prochain briefing. --- FIN DU SCRIPT