Comprensión de Cisco SUDI: Identidad con Anclaje por Hardware en el Control de Acceso Seguro a la Red

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor sénior de seguridad de redes que informa a un cliente durante un almuerzo de trabajo. Ritmo pausado, articulación clara, ingenio seco ocasional. No es una conferencia. No es un argumento de venta. Una sesión técnica informativa de tú a tú: Bienvenido a la serie de sesiones técnicas informativas de Purple. Soy su anfitrión, y hoy nos adentraremos en algo que surge a menudo en los despliegues de redes empresariales: Cisco SUDI. Es decir, el Identificador Único de Dispositivo Seguro. Si ha estado buscando una respuesta directa sobre qué hace realmente, cómo encaja en la autenticación 802.1X y si es relevante para su red de sede o campus, [pausa breve] está en el lugar correcto. Comencemos con el problema principal. La mayoría de las redes empresariales todavía dependen de las direcciones MAC para identificar los dispositivos. El Bypass de Autenticación MAC - o MAB - está en todas partes. El problema es que las direcciones MAC se pueden suplantar fácilmente. Un actor malicioso con un ordenador portátil y quince minutos puede clonar la dirección MAC de un punto de acceso de confianza y acceder directamente a su red. Eso no es un riesgo teórico. Es un vector de ataque documentado, y es algo que PCI DSS 4.0 señala específicamente como inadecuado para entornos de datos de titulares de tarjetas. Así que la pregunta es: ¿cómo se demuestra que un dispositivo es lo que dice ser? No solo "que tiene la dirección MAC correcta", sino demostrarlo de forma genuina y criptográfica. Ahí es donde entra en juego SUDI. [pausa breve] El Identificador Único de Dispositivo Seguro de Cisco es un certificado X.509 versión 3, grabado en el módulo Trust Anchor del dispositivo - el chip TAm - durante la fabricación. El certificado contiene el identificador del producto y el número de serie, y está encadenado a la Autoridad de Certificación raíz pública de Cisco. La clave privada se genera dentro del chip TAm y nunca se exporta. Jamás. No se puede clonar. No se puede suplantar. La identidad está físicamente unida al silicio. Esto convierte a SUDI en una implementación de IEEE 802.1AR, el estándar para Identificadores de Dispositivos Seguros. En la terminología de 802.1AR, el SUDI es un IDevID - un Identificador de Dispositivo Inicial. Es la identidad instalada de fábrica que demuestra que el dispositivo es un producto Cisco genuino, fabricado en una instalación conocida, con un número de serie conocido. Ahora bien, ¿por qué es importante en la práctica? Analicemos el flujo de autenticación. Cuando un dispositivo Cisco - por ejemplo, un switch Catalyst o un punto de acceso Meraki - se conecta a su red, puede actuar como un suplicante 802.1X. Presenta su certificado SUDI al autenticador de la red, normalmente un puerto de switch o un controlador inalámbrico. El autenticador reenvía esa credencial a un servidor RADIUS - Cisco ISE es la opción más común aquí, pero funciona cualquier servidor RADIUS que cumpla con la norma RFC 2865. El servidor RADIUS valida la cadena de certificados hasta la CA raíz de Cisco. Si la cadena es válida, el dispositivo es genuino. Se concede el acceso y se asigna la VLAN adecuada. Todo el intercambio utiliza EAP-TLS (protocolo de autenticación extensible con seguridad de la capa de transporte), que es la variante de autenticación mutua. Tanto el dispositivo como la red se autentican mutuamente. Sin contraseñas. Sin secretos compartidos. Sin direcciones MAC. Solo pruebas criptográficas. [short pause] Hablemos del aprovisionamiento Zero Touch (ZTP), porque aquí es donde SUDI resulta realmente útil para grandes despliegues. Imagine que va a desplegar 200 puntos de acceso en una cadena de hoteles o a implementar infraestructura de red en 40 tiendas minoristas. Tradicionalmente, eso implicaría tener a un técnico en cada centro configurando manualmente cada dispositivo. Con el ZTP basado en SUDI, el dispositivo se inicia, presenta su identidad SUDI a un servidor de aprovisionamiento, el servidor valida el certificado, confirma el número de serie comparándolo con su inventario y envía la configuración correcta (encriptada, para que solo ese dispositivo específico pueda desencriptarla). El trabajo del técnico pasa a ser únicamente la instalación física. La red se encarga de lo demás. Para los operadores de hostelería y del sector minorista, esto representa un ahorro operativo muy significativo. Premier Inn, por ejemplo, gestiona cientos de establecimientos. La capacidad de enviar hardware preinstalado en racks a un centro y hacer que se configure automáticamente con una identidad conocida marca la diferencia entre una visita de puesta en servicio de dos días y una de dos horas. [short pause] Ahora entremos en el ciclo de vida del certificado, porque aquí es donde los equipos a veces se ven sorprendidos. Los certificados SUDI originales se emitían con un periodo de validez de diez años a partir de la fecha de fabricación, con un límite fijado el 14 de mayo de 2029. Cisco emitió avisos de campo (FN 72094 y FN 72105) que cubrían los productos afectados. Los dispositivos fabricados después de mayo de 2019 tienen una ventana inferior a diez años. Cuando el SUDI caduca, las funciones que dependen de él para TLS (como las interfaces de gestión HTTPS, la autenticación de certificados SSH o ZTP) pueden dejar de funcionar. El dispositivo en sí sigue funcionando, no quedará inutilizable, pero esos servicios autenticados específicos se interrumpen. La respuesta de Cisco fue introducir certificados SUDI-2099 en el hardware más nuevo, válidos hasta diciembre de 2099. Si adquiere infraestructura de Cisco hoy en día, recibirá SUDI-2099. Si tiene equipos más antiguos en funcionamiento, compruebe las fechas de caducidad con "show crypto pki certificates" en IOS o IOS-XE. Planifique su ciclo de renovación en consecuencia. [short pause] Bien, recomendaciones de implementación. Tres cosas que le diría a cualquier responsable de TI que implemente la autenticación basada en SUDI. Primero: diseñe su política de RADIUS en torno a los atributos del certificado, no solo a la cadena de certificados. Valide el Subject CN contrastándolo con su inventario de dispositivos. Un certificado de Cisco válido demuestra que el dispositivo es hardware original de Cisco, pero no demuestra que sea el dispositivo específico que usted solicitó para esa ubicación. Verifique el número de serie en su política de autorización de RADIUS. Segundo: ejecute SUDI junto con su política de MAB existente, no en lugar de ella, durante la migración. Utilice el perfilado de Cisco ISE para identificar qué dispositivos admiten 802.1AR y muévalos progresivamente a la autenticación basada en certificados. Los dispositivos IoT heredados - cámaras, controladores de climatización, lectores de tarjetas - a menudo no pueden realizar 802.1X en absoluto. MAB sigue siendo la alternativa para ellos. El objetivo es eliminar MAB primero para los dispositivos de infraestructura, donde el riesgo es mayor. Tercero: documente las fechas de caducidad de sus certificados en su CMDB. Esto parece obvio, pero es lo que suele pillar desprevenidos a los equipos. Un switch que deja de aceptar conexiones de gestión HTTPS porque su SUDI ha caducado no es un incidente divertido de diagnosticar a las dos de la mañana. [pausa breve] Preguntas rápidas. Le daré las respuestas cortas. ¿SUDI sustituye a 802.1X? No. SUDI es la credencial. 802.1X es el marco de autenticación. SUDI es lo que se presenta durante un intercambio de 802.1X. ¿Puedo utilizar SUDI con servidores RADIUS que no sean de Cisco? Sí. Cualquier servidor RADIUS que admita EAP-TLS y pueda validar una cadena de certificados X.509 puede funcionar con SUDI. Debe importar el certificado de CA raíz de Cisco en el almacén de confianza de su servidor RADIUS. ¿Admite Cisco Meraki SUDI? Sí, para la autenticación de infraestructura. Los puntos de acceso de Meraki utilizan su propia variante de certificados instalados por el fabricante para la autenticación del controlador en la nube. El panel de Meraki se actualizó para gestionar la caducidad de SUDI antes de la fecha límite de 2026. ¿Qué pasa con Purple WiFi? Purple funciona como una capa superpuesta en la nube sobre su infraestructura existente - Cisco Meraki, HPE Aruba, Ruckus y otros. La capa de Redes Basadas en la Identidad de Purple se sitúa por encima del plano de autenticación de hardware. SUDI protege los propios dispositivos de infraestructura. Purple protege la capa de identidad de los visitantes y del personal que se encuentra encima. Ambos son complementarios, no compiten entre sí. [pausa breve] Para terminar. Cisco SUDI le ofrece una identidad de dispositivo anclada por hardware y verificable mediante criptografía. Elimina la suplantación de identidad MAC como vector de ataque para los dispositivos de infraestructura. Permite el aprovisionamiento Zero Touch a escala. Se alinea con los requisitos de control de IEEE 802.1AR, PCI DSS 4.0 e ISO 27001. Y se integra perfectamente con cualquier infraestructura RADIUS compatible con 802.1X y EAP-TLS. Los siguientes pasos prácticos: audite su inventario de dispositivos Cisco para detectar las fechas de caducidad de los certificados SUDI, identifique qué dispositivos ejecutan MAB que podrían migrarse a la autenticación basada en certificados y revise su política de RADIUS para añadir la validación del número de serie junto con las comprobaciones de la cadena de confianza. Si tiene instalado Purple en sus centros, nuestro equipo puede guiarle sobre cómo se asignan las Redes Basadas en la Identidad a su infraestructura Cisco existente. El enlace está en las notas del programa. Gracias por escucharnos. Hasta la próxima.