Comprendre Cisco SUDI : l'identité d'appareil basée sur le matériel dans le contrôle d'accès réseau

Comprendre Cisco SUDI : L'identité matérielle des équipements dans le contrôle d'accès réseau Une présentation technique Purple - Script complet du podcast (environ 10 minutes) --- SÉQUENCE 1 : INTRODUCTION ET CONTEXTE (environ 1 minute) Bonjour et bienvenue dans cette présentation 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 réseau, et ce que vous devez faire si vous gérez une infrastructure Cisco à grande échelle. Ceci s'adresse aux architectes réseau, aux responsables informatiques et aux directeurs de la technologie de sites accueillant du public - hôtels, zones commerciales, stades, centres de conférence - partout où vous exploitez un WiFi d'entreprise et devez avoir la certitude 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 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 posture de sécurité est la suivante : comment savoir si chacun de ces appareils est un produit Cisco authentique et non modifié - et non une contrefaçon, une unité compromise ou un équipement altéré durant le transport ? C'est ce vide que SUDI vient combler. --- SÉQUENCE 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 utilisé pour HTTPS et TLS - mais au lieu d'être attribué à une personne ou à un serveur, il est attribué à un équipement matériel spécifique lors de sa fabrication. Il contient l'identifiant produit de l'appareil ainsi que son numéro de série, et il est ancré dans la propre infrastructure à clés publiques de Cisco. Voici ce qui différencie 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. SUDI est l'implémentation par Cisco de la norme IEEE 802.1AR - la norme de l'industrie pour les identifiants d'appareils sécurisés, ou DevIDs. Selon la norme 802.1AR, l'identifiant installé par le fabricant est appelé Initial Device Identifier, ou IDevID. Le SUDI de Cisco est exactement cela - un IDevID que Cisco installe en usine. Vous pouvez le compléter par un Locally Significant Device Identifier, ou LDevID, que votre propre PKI génère pour les politiques d'autorisation locales. Maintenant, comment cela s'intègre-t-il au contrôle d'accès réseau ? Le point d'intégration le plus courant est la norme IEEE 802.1X - la norme de contrôle d'accès réseau basée sur les ports. Lorsqu'un point d'accès ou un commutateur Cisco est mis en ligne, il peut présenter son certificat SUDI à un serveur RADIUS - généralement Cisco ISE, Identity Services Engine - via EAP-TLS, qui est 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 l'appareil est authentique, puis applique la politique réseau appropriée. Ceci est nettement plus robuste que le contournement par adresse MAC, qui est la solution de secours utilisée par la plupart des réseaux pour les appareils 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 l'appareil. Dans le contexte d'un site, cela est important pour trois raisons. Premièrement, cela élimine le risque que des points d'accès non autorisés rejoignent votre réseau. Un appareil contrefait ou non autorisé ne peut tout simplement pas présenter un SUDI valide. Deuxièmement, cela permet un provisionnement automatisé de type Zero Touch Provisioning - un nouvel appareil est livré 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 offre une piste d'audit vérifiable par cryptographie. Chaque appareil 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 nommé. Laissez-moi vous parler du module Trust Anchor un peu plus en détail, car c'est le socle sur lequel tout le reste repose. Le TAm est une puce propriétaire Cisco qui fournit trois éléments : 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 des composants matériels critiques d'un appareil lors de sa fabrication et stocke cette empreinte dans le TAm. Lorsque l'appareil démarre, il compare l'empreinte matérielle observée à celle stockée. Si elles ne correspondent pas, l'appareil ne démarre pas. Cela permet de détecter les altérations matérielles pendant le transport - une préoccupation réelle pour les déploiements sur de grands sites où le matériel peut passer entre plusieurs mains avant l'installation. Un problème opérationnel dont vous devez être conscient : les certificats SUDI émis avant mai 2019 expirent soit dix ans après la date de fabrication, soit le 14 mai 2029, selon la première échéance. Cisco a résolu ce problème avec une nouvelle génération de certificats appelée SUDI-2099, valide jusqu'en décembre 2099. Si vous utilisez du matériel de la série Catalyst 9000 fabriqué avant 2019, vous devez vérifier vos dates d'expiration SUDI dès maintenant. La commande est show crypto pki certificate sur IOS-XE. Recherchez le trustpoint CISCO_IDEVID_SUDI et vérifiez la date de fin. Si vous êtes sur Catalyst 9200, effectuez une mise à niveau vers IOS-XE 17.12.2 ou une version ultérieure pour vous assurer d'utiliser le bon certificat 2099. - SEGMENT 3 : RECOMMANDATIONS DE MISE EN ŒUVRE ET PIÈGES (environ 2 minutes) Laissez-moi vous présenter la mise en œuvre pratique. Si vous déployez une authentification basée sur SUDI dans un environnement physique, voici la séquence qui fonctionne. Commencez par votre infrastructure RADIUS. Cisco ISE est le choix naturel si vous évoluez déjà dans l'écosystème Cisco, mais n'importe quel serveur RADIUS prenant en charge EAP-TLS et capable de valider par rapport à une autorité de certification (CA) externe fera l'affaire. Vous devez importer la CA racine de Cisco et les certificats ACT2 SUDI CA dans le magasin de confiance de votre RADIUS. Ces derniers sont disponibles publiquement sur le portail PKI de Cisco. Ensuite, configurez votre politique 802.1X pour exiger une authentification par certificat pour les équipements 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 être traités sur des ensembles de politiques distincts dans ISE. Pour les nouveaux déploiements, activez le provisionnement automatisé (Zero Touch Provisioning). Votre système de gestion de réseau - Cisco DNA Centre ou Catalyst Centre - peut utiliser SUDI pour vérifier l'identité de l'équipement avant de pousser la configuration. Cela élimine le processus de préparation manuelle et réduit le temps de déploiement de plusieurs heures à quelques minutes par appareil. Maintenant, parlons des pièges. Le plus courant consiste à mélanger l'authentification SUDI avec le contournement par adresse MAC (MAB) sur le même port. Si vous basculez vers le MAB en cas d'échec de SUDI, vous compromettez le modèle de sécurité. Définissez une politique claire : les équipements compatibles SUDI doivent s'authentifier via SUDI, un point c'est tout. Les équipements non compatibles SUDI sont orientés vers un VLAN de quarantaine en attendant un examen manuel. Le second piège est l'expiration des certificats. Mettez en place dès maintenant une surveillance des dates d'expiration 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 constructeurs de matériel pour faire remonter les indicateurs de santé des équipements - y compris le statut d'authentification - dans un tableau de bord unique, ce qui rend cette surveillance proactive très pratique à grande échelle. Le troisième piège est la dérive des objectifs. SUDI authentifie l'équipement matériel. Il n'authentifie pas l'utilisateur qui se connecte via cet équipement. 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, le recueil de consentement, l'attribution des VLAN pour le trafic invité et les analyses, tandis que SUDI gère la couche d'infrastructure sous-jacente. - - - SECTION 4 : QUESTIONS-RÉPONSES RAPIDES (env. 1 minute) Passons en revue trois questions que l'on me pose régulièrement. SUDI remplace-t-il ma PKI existante ? Non. SUDI est un IDevID installé par le fabricant. Il prouve que l'équipement est un matériel Cisco authentique. Votre PKI d'entreprise émet des LDevIDs et des certificats utilisateurs pour tout le reste. Ils fonctionnent en parallèle. Puis-je utiliser SUDI sur du matériel non-Cisco ? Non. SUDI est spécifique à Cisco. HPE Aruba dispose d'un équivalent appelé certificats de provisionnement IAP. Ruckus et Juniper Mist ont leurs propres mécanismes d'identité d'équipement. La norme sous-jacente - IEEE 802.1AR - est neutre vis-à-vis des constructeurs, mais chaque fabricant l'implémente différemment. Que se passe-t-il lorsqu'un certificat SUDI expire ? Les services qui dépendent de SUDI pour l'authentification - HTTPS, SSH avec authentification par certificat, Zero Touch Provisioning - échoueront. L'appareil lui-même continue de fonctionner, mais il ne peut plus prouver son identité de manière cryptographique. C'est pourquoi la migration SUDI-2099 est essentielle. - SEGMENT 5 : RÉSUMÉ ET PROCHAINES ÉTAPES (environ 1 minute) Pour résumer : Cisco SUDI vous offre une identité d'appareil ancrée dans le matériel qui ne peut être usurpée, clonée ou exportée. C'est la base d'une couche d'infrastructure digne de confiance. Combiné avec IEEE 802.1X et une politique RADIUS bien configurée, il élimine le risque d'appareils non autorisés et permet un provisionnement automatisé à grande échelle. Vos trois actions immédiates : premièrement, auditez votre parc Cisco pour identifier les dates d'expiration des SUDI à l'aide de show crypto pki certificate. Deuxièmement, importez la CA racine de Cisco dans votre magasin de confiance RADIUS et configurez les politiques EAP-TLS pour les appareils d'infrastructure. Troisièmement, séparez votre politique d'authentification d'infrastructure de votre politique d'authentification d'utilisateur final - elles servent des objectifs différents et doivent être gérées indépendamment. Si vous souhaitez approfondir 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. On se retrouve lors du prochain briefing. - FIN DU SCRIPT