Comprendre Cisco SUDI : l'identité matérielle des périphériques dans le contrôle d'accès au réseau

Comprendre Cisco SUDI : l'identité matérielle des périphériques dans le contrôle d'accès au réseau Un briefing technique Purple - Script complet du podcast (environ 10 minutes) --- SEGMENT 1 : INTRODUCTION ET CONTEXTE (environ 1 minute) Bonjour et bienvenue dans ce briefing technique Purple. Je vais passer les dix prochaines minutes à vous présenter Cisco SUDI (Secure Unique Device Identifier) : ce que c'est concrètement, comment il s'intègre dans votre architecture de contrôle d'accès au réseau et ce que vous devez faire si vous gérez une infrastructure Cisco à grande échelle. Ce briefing s'adresse aux architectes réseau, aux responsables informatiques et aux directeurs techniques de sites (hôtels, parcs de vente au détail, stades, centres de conférence), c'est-à-dire partout où vous exploitez un réseau WiFi d'entreprise et devez être certain que le matériel connecté à votre réseau est bien celui qu'il prétend être. Commençons par le problème que résout le SUDI. Dans tout grand réseau de site, vous disposez de dizaines ou de centaines de points d'accès, de commutateurs et de contrôleurs. La question dont dépend votre niveau de sécurité est la suivante : comment savoir si chacun de ces périphériques est un produit Cisco authentique et non modifié, et non une contrefaçon, une unité compromise ou un appareil qui a été altéré en transit ? C'est précisément cette faille que le SUDI vient combler. --- SEGMENT 2 : ANALYSE TECHNIQUE APPROFONDIE (environ 5 minutes) SUDI signifie Secure Unique Device Identifier. Il s'agit d'un certificat X.509 version 3 (le même format de certificat que celui utilisé pour le HTTPS et le TLS), mais au lieu d'être attribué à une personne ou à un serveur, il est injecté dans un composant matériel spécifique lors de sa fabrication. Il contient l'identifiant du produit et le numéro de série du périphérique, et il est ancré dans la propre infrastructure à clés publiques (PKI) de Cisco. Voici ce qui différencie le SUDI d'un certificat logiciel que vous installeriez vous-même. Le certificat SUDI, ainsi que sa paire de clés associée, réside dans une puce inviolable appelée module Trust Anchor, ou TAm. La clé privée est générée à l'intérieur de cette puce et ne la quitte jamais. Vous ne pouvez pas l'exporter. Vous ne pouvez pas la cloner. Si quelqu'un altère physiquement la puce, la clé est détruite. C'est la racine de confiance matérielle. Le SUDI est l'implémentation par Cisco de la norme IEEE 802.1AR, la norme de l'industrie pour les identifiants de périphériques sécurisés, ou DevID. Selon la norme 802.1AR, l'identifiant installé par le fabricant est appelé identifiant initial de périphérique, ou IDevID. Le SUDI de Cisco est exactement cela : un IDevID que Cisco installe en usine. Vous pouvez le compléter par un identifiant de périphérique localement significatif, ou LDevID, que votre propre PKI émet pour les politiques d'autorisation locales. Maintenant, comment cela s'intègre-t-il dans le contrôle d'accès au réseau ? Le point d'intégration le plus courant est la norme IEEE 802.1X, la norme de contrôle d'accès au réseau basée sur les ports. Lorsqu'un point d'accès ou un commutateur Cisco se connecte, il peut présenter son certificat SUDI à un serveur RADIUS (généralement Cisco ISE, Identity Services Engine) en utilisant l'EAP-TLS, c'est-à-dire le protocole d'authentification extensible avec sécurité de la couche de transport. Le serveur RADIUS valide le certificat par rapport à l'autorité de certification publique de Cisco, confirme que le périphérique est authentique, puis applique la politique réseau appropriée. Cette méthode est nettement plus robuste que le MAC Address Bypass, qui est la solution de secours que la plupart des réseaux utilisent pour les périphériques d'infrastructure. Les adresses MAC peuvent être usurpées en moins d'une minute. Un certificat lié au matériel dans une puce inviolable ne peut pas être usurpé sans détruire physiquement le périphérique. Dans le contexte d'un site, cela importe pour trois raisons. Premièrement, cela élimine le risque que des points d'accès non autorisés rejoignent votre réseau. Un périphérique contrefait ou non autorisé ne peut tout simplement pas présenter un SUDI valide. Deuxièmement, cela permet un Zero Touch Provisioning automatisé : un nouveau périphérique est expédié sur votre site, s'allume, présente son SUDI, et votre système de gestion le vérifie par rapport à votre inventaire avant de pousser la configuration. Aucune intervention manuelle n'est requise. Troisièmement, cela vous donne une piste d'audit vérifiable par cryptographie. Chaque périphérique qui s'est authentifié sur votre réseau l'a fait avec un certificat qui prouve qu'il s'agit d'un produit Cisco spécifique et identifié. Permettez-moi de parler du module Trust Anchor un peu plus en détail, car c'est le socle sur lequel repose tout le reste. Le TAm est une puce propriétaire de Cisco que offre trois fonctionnalités : un stockage sécurisé non volatile pour le SUDI et les clés, des services cryptographiques incluant la génération de nombres aléatoires, et l'empreinte matérielle. Ce dernier point mérite d'être souligné : Cisco enregistre l'empreinte cryptographique des composants matériels critiques d'un périphérique lors de sa fabrication et stocke cette empreinte dans le TAm. Lorsque le périphérique démarre, il compare l'empreinte matérielle observée à celle stockée. Si elles ne correspondent pas, le périphérique ne démarre pas. Cela permet de détecter les altérations matérielles en transit, une préoccupation bien réelle pour les déploiements sur de grands sites où le matériel peut passer entre plusieurs mains avant son installation. Un point opérationnel dont vous devez être conscient : les certificats SUDI émis avant mai 2019 expirent soit dix ans après leur date de fabrication, soit le 14 mai 2029, selon la date qui survient en premier. Cisco a résolu ce problème avec une nouvelle génération de certificats appelée SUDI-2099, valides jusqu'en décembre 2099. Si vous utilisez du matériel de la gamme Catalyst 9000 fabriqué avant 2019, vous devez vérifier dès maintenant les dates d'expiration de vos SUDI. La commande est show crypto pki certificate sous IOS-XE. Recherchez le point de confiance CISCO_IDEVID_SUDI et vérifiez la date de fin. Si vous êtes sur Catalyst 9200, passez à IOS-XE 17.12.2 ou version ultérieure pour vous assurer d'utiliser le bon certificat 2099. --- SEGMENT 3 : RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES À ÉVITER (environ 2 minutes) Laissez-moi vous présenter la mise en œuvre pratique. Si vous déployez une authentification basée sur le SUDI dans un environnement de site, voici la séquence qui fonctionne. Commencez par votre infrastructure RADIUS. Cisco ISE est le choix naturel si vous êtes déjà dans l'écosystème Cisco, mais n'importe quel serveur RADIUS prenant en charge l'EAP-TLS et capable de valider par rapport à une CA externe fera l'affaire. Vous devez importer la CA racine de Cisco et les certificats de la CA ACT2 SUDI dans le magasin de confiance de votre RADIUS. Ceux-ci sont disponibles publiquement sur le portail PKI de Cisco. Ensuite, configurez votre politique 802.1X pour exiger une authentification basée sur les certificats pour les périphériques d'infrastructure. Séparez cette politique de celle de vos utilisateurs finaux : les flux d'authentification du personnel et des invités sont différents et doivent se trouver sur des ensembles de politiques distincts dans ISE. Pour les nouveaux déploiements, activez le Zero Touch Provisioning. Votre système de gestion de réseau (Cisco DNA Center ou Catalyst Center) peut utiliser le SUDI pour vérifier l'identité du périphérique avant de pousser la configuration. Cela élimine le processus de préparation manuelle et réduit le temps de provisionnement de plusieurs heures à quelques minutes par périphérique. Passons maintenant aux pièges. Le plus courant consiste à mélanger l'authentification SUDI et le MAC Address Bypass sur le même port. Si vous basculez vers le MAB en cas d'échec du SUDI, vous compromettez tout le modèle de sécurité. Définissez une politique claire : les périphériques compatibles SUDI doivent s'authentifier via SUDI, un point c'est tout. Les périphériques non compatibles SUDI vont dans un VLAN de quarantaine en attendant un examen manuel. Le deuxième piège est l'expiration des certificats. Mettez en place dès maintenant une surveillance des dates d'expiration des SUDI sur l'ensemble de votre parc. N'attendez pas une interruption de service pour découvrir que vos points d'accès ne peuvent plus s'authentifier. La plateforme de Purple s'intègre à Cisco Meraki et à d'autres fournisseurs de matériel pour faire remonter les signaux de santé des périphériques (y compris l'état d'authentification) dans un tableau de bord unique, ce qui rend ce type de surveillance proactive très simple à grande échelle. Le troisième piège est la dérive des objectifs. Le SUDI authentifie le périphérique matériel. Il n'authentifie pas l'utilisateur qui s'y connecte. Vous avez toujours besoin d'une couche d'identité distincte pour les invités, le personnel et les résidents. C'est là qu'intervient une plateforme comme Purple : nous gérons la couche d'identité humaine, la capture du consentement, l'attribution des VLAN pour le trafic des invités et les analyses, tandis que le SUDI gère la couche d'infrastructure sous-jacente. --- SEGMENT 4 : QUESTIONS-RÉPONSES RAPIDES (environ 1 minute) Passons en revue trois questions que l'on me pose régulièrement. Le SUDI remplace-t-il ma PKI existante ? Non. Le SUDI est un IDevID installé par le fabricant. Il prouve que le périphérique est un matériel Cisco authentique. Votre PKI d'entreprise émet des LDevID et des certificats d'utilisateur pour tout le reste. Ils fonctionnent en parallèle. Puis-je utiliser le SUDI sur du matériel non-Cisco ? Non. Le SUDI est spécifique à Cisco. HPE Aruba propose un équivalent appelé certificats de provisionnement IAP. Ruckus et Juniper Mist ont leurs propres mécanismes d'identité de périphérique. La norme sous-jacente (IEEE 802.1AR) est neutre vis-à-vis des fournisseurs, mais chaque fabricant l'implémente différemment. Que se passe-t-il lorsqu'un certificat SUDI expire ? Les services qui s'appuient sur le SUDI pour l'authentification (HTTPS, SSH avec authentification par certificat, Zero Touch Provisioning) échoueront. Le périphérique lui-même continue de fonctionner, mais il ne peut plus prouver son identité de manière cryptographique. C'est pourquoi la migration vers le SUDI-2099 est importante. --- SEGMENT 5 : RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) Pour résumer : Cisco SUDI vous offre une identité de périphérique ancrée au niveau matériel qui ne peut être ni usurpée, ni clonée, ni exportée. C'est le fondement d'une couche d'infrastructure digne de confiance. Associé au 802.1X et à une politique RADIUS bien configurée, il élimine le risque de périphériques non autorisés et permet un provisionnement automatisé à grande échelle. Vos trois actions immédiates : premièrement, auditez votre parc Cisco pour vérifier les dates d'expiration des SUDI à l'aide de la commande show crypto pki certificate. Deuxièmement, importez la CA racine de Cisco dans votre magasin de confiance RADIUS et configurez des politiques EAP-TLS pour les périphériques d'infrastructure. Troisièmement, séparez votre politique d'authentification d'infrastructure de votre politique d'authentification d'utilisateur final : elles répondent à des objectifs différents et doivent être gérées indépendamment. Si vous souhaitez en savoir plus sur la façon dont Purple s'intègre à Cisco Meraki et à d'autres fournisseurs de matériel pour offrir une segmentation réseau basée sur l'identité pour les invités, le personnel et les résidents, visitez purple.ai ou lisez les guides associés mis en lien sous cet épisode. Merci pour votre écoute. À bientôt pour un prochain briefing. --- FIN DU SCRIPT