Introducción a Cisco SUDI: Identidad de dispositivos basada en hardware en el control de acceso a la red

Introducción a Cisco SUDI: Identidad de dispositivos basada en hardware en el control de acceso a la red Un informe técnico de Purple - Guion completo del podcast (aprox. 10 minutos) --- SEGMENTO 1: INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto) Hola y bienvenidos a este informe técnico de Purple. Durante los próximos diez minutos, les guiaré a través de Cisco SUDI (Secure Unique Device Identifier): qué es exactamente, cómo encaja en su arquitectura de control de acceso a la red y qué debe hacer al respecto si gestiona infraestructura de Cisco a gran escala. Este contenido está dirigido a arquitectos de red, responsables de TI y directores de tecnología (CTO) de grandes recintos (hoteles, cadenas de tiendas, estadios, centros de conferencias), es decir, cualquier lugar donde se ofrezca WiFi empresarial y se necesite la total certeza de que el hardware de la red es exactamente lo que dice ser. Comencemos con el problema que resuelve SUDI. En la red de cualquier gran recinto, hay decenas o cientos de puntos de acceso, switches y controladores. La pregunta de la que depende su seguridad es: ¿cómo sabe que cada uno de esos dispositivos es un producto Cisco original y sin modificar, y no una falsificación, una unidad comprometida o un dispositivo manipulado en tránsito? Ese es el vacío que cubre SUDI. --- SEGMENTO 2: ANÁLISIS TÉCNICO DETALLADO (aprox. 5 minutos) SUDI significa Secure Unique Device Identifier (Identificador Único de Dispositivo Seguro). Es un certificado X.509 versión 3, el mismo formato de certificado utilizado en HTTPS y TLS, pero en lugar de emitirse a una persona o servidor, se asigna a un componente de hardware específico durante su fabricación. Contiene el identificador de producto y el número de serie del dispositivo, y está vinculado a la propia infraestructura de clave pública (PKI) de Cisco. Esto es lo que diferencia a SUDI de un certificado de software que instalaría usted mismo. El certificado SUDI, junto con su par de claves asociado, reside dentro de un chip resistente a manipulaciones llamado Trust Anchor module, o TAm. La clave privada se genera dentro de ese chip y nunca sale de él. No se puede exportar. No se puede clonar. Si alguien manipula físicamente el chip, la clave se destruye. Esa es la raíz de confianza basada en hardware. SUDI es la implementación de Cisco del estándar IEEE 802.1AR, el estándar del sector para identificadores de dispositivos seguros o DevIDs. Según la norma 802.1AR, la credencial instalada por el fabricante se denomina Initial Device Identifier o IDevID. El SUDI de Cisco es exactamente eso: un IDevID que Cisco instala en fábrica. Puede complementarlo con un Locally Significant Device Identifier o LDevID, que emite su propia PKI para las políticas de autorización locales. Ahora bien, ¿cómo se conecta esto con el control de acceso a la red? El punto de integración más común es IEEE 802.1X, el estándar de control de acceso a la red basado en puertos. Cuando un punto de acceso o switch de Cisco se conecta, puede presentar su certificado SUDI a un servidor RADIUS (normalmente Cisco ISE, Identity Services Engine) utilizando EAP-TLS, que es el protocolo de autenticación extensible con seguridad de la capa de transporte. El servidor RADIUS valida el certificado frente a la autoridad de certificación pública de Cisco, confirma que el dispositivo es original y, a continuación, aplica la política de red correspondiente. Esto es significativamente más sólido que el MAC address bypass, que es el método de respaldo que la mayoría de las redes utilizan para los dispositivos de infraestructura. Las direcciones MAC se pueden suplantar en menos de un minuto. Un certificado vinculado al hardware en un chip resistente a manipulaciones no se puede suplantar sin destruir físicamente el dispositivo. En el contexto de un gran recinto, esto es crucial por tres razones. En primer lugar, elimina el riesgo de que puntos de acceso no autorizados se unan a su red. Un dispositivo falsificado o no autorizado sencillamente no puede presentar un SUDI válido. En segundo lugar, permite un Zero Touch Provisioning automatizado: se envía un nuevo dispositivo a su recinto, se enciende, presenta su SUDI y su sistema de gestión lo verifica con su inventario antes de enviarle la configuración. Sin intervención manual. En tercer lugar, le proporciona un registro de auditoría verificable criptográficamente. Cada dispositivo que se ha autenticado en su red lo ha hecho con un certificado que demuestra que es un producto Cisco específico y registrado. Permítanme hablar del Trust Anchor module con un poco más de detalle, porque es la base sobre la que se asienta todo lo demás. El TAm es un chip patentado de Cisco que proporciona tres elementos: almacenamiento seguro no volátil para el SUDI y las claves, servicios criptográficos que incluyen la generación de números aleatorios y la creación de huellas digitales de hardware. Vale la pena destacar este último punto: Cisco registra una huella digital de los componentes de hardware críticos de un dispositivo durante su fabricación y la almacena en el TAm. Cuando el dispositivo arranca, comprueba la huella digital del hardware detectado con la almacenada. Si no coinciden, el dispositivo no arranca. Esto detecta la manipulación del hardware en tránsito, una preocupación real en despliegues en grandes recintos donde el hardware puede pasar por varias manos antes de su instalación. Un aspecto operativo que deben tener en cuenta: los certificados SUDI emitidos antes de mayo de 2019 caducan a los diez años de su fecha de fabricación o el 14 de mayo de 2029, lo que ocurra primero. Cisco ha solucionado esto con una nueva generación de certificados denominada SUDI-2099, válidos hasta diciembre de 2099. Si dispone de hardware de la serie Catalyst 9000 fabricado antes de 2019, debe comprobar las fechas de caducidad de sus SUDI ahora mismo. El comando es show crypto pki certificate en IOS-XE. Busque el punto de confianza CISCO_IDEVID_SUDI y compruebe la fecha de finalización. Si utiliza Catalyst 9200, actualice a IOS-XE 17.12.2 o posterior para asegurarse de utilizar el certificado 2099 correcto. --- SEGMENTO 3: RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aprox. 2 minutos) Permítanme ofrecerles una perspectiva práctica de la implementación. Si va a desplegar la autenticación basada en SUDI en un gran recinto, este es el proceso recomendado. Comience con su infraestructura RADIUS. Cisco ISE es la opción natural si ya se encuentra en el ecosistema de Cisco, pero cualquier servidor RADIUS que admita EAP-TLS y pueda realizar la validación frente a una CA externa funcionará. Debe importar la CA raíz de Cisco y los certificados de la CA ACT2 SUDI en el almacén de confianza de su RADIUS. Están disponibles públicamente en el portal PKI de Cisco. A continuación, configure su política 802.1X para exigir autenticación basada en certificados para los dispositivos de infraestructura. Separe esto de su política de autenticación de usuarios finales; los flujos de autenticación de empleados y de invitados son diferentes y deben gestionarse en conjuntos de políticas distintos en ISE. Para nuevos despliegues, habilite Zero Touch Provisioning. Su sistema de gestión de red (como Cisco DNA Center o Catalyst Center) puede utilizar SUDI para verificar la identidad del dispositivo antes de enviar la configuración. Esto elimina el proceso de preparación manual y reduce el tiempo de aprovisionamiento de horas a minutos por dispositivo. Ahora, hablemos de los errores comunes. El más habitual que observo es mezclar la autenticación SUDI con MAC address bypass en el mismo puerto. Si recurre a MAB cuando falla SUDI, habrá debilitado el modelo de seguridad. Defina una política clara: los dispositivos compatibles con SUDI deben autenticarse obligatoriamente a través de SUDI. Los dispositivos que no admitan SUDI se derivan a una VLAN de cuarentena a la espera de una revisión manual. El segundo error es la caducidad de los certificados. Configure ya la supervisión de las fechas de caducidad de SUDI en toda su infraestructura. No espere a que se produzca una interrupción del servicio para descubrir que sus puntos de acceso ya no pueden autenticarse. La plataforma de Purple se integra con Cisco Meraki y otros proveedores de hardware para mostrar los indicadores de estado de los dispositivos (incluido el estado de autenticación) en un único panel, lo que hace que este tipo de supervisión proactiva sea viable a gran escala. El tercer error es la pérdida de enfoque del proyecto. SUDI autentica el dispositivo de hardware, no al usuario que se conecta a través de ese dispositivo. Sigue necesitando una capa de identidad independiente para invitados, empleados y residentes. Ahí es donde entra una plataforma como Purple: nosotros gestionamos la capa de identidad humana, la captura de consentimiento, la asignación de VLAN para el tráfico de invitados y las analíticas, mientras que SUDI se encarga de la capa de infraestructura subyecente. --- SEGMENTO 4: PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto) Repasemos tres preguntas que me formulan con frecuencia. ¿SUDI sustituye a mi PKI actual? No. SUDI es un IDevID instalado por el fabricante. Demuestra que el dispositivo es hardware original de Cisco. Su PKI empresarial emite LDevIDs y certificados de usuario para todo lo demás. Funcionan en paralelo. ¿Puedo utilizar SUDI en hardware que no sea de Cisco? No. SUDI es específico de Cisco. HPE Aruba tiene un equivalente llamado certificados de aprovisionamiento IAP. Ruckus y Juniper Mist disponen de sus propios mecanismos de identidad de dispositivos. El estándar subyacente (IEEE 802.1AR) es neutro respecto al proveedor, pero cada fabricante lo implementa de forma diferente. ¿Qué ocurre cuando caduca un certificado SUDI? Los servicios que dependen de SUDI para la autenticación (como HTTPS, SSH con autenticación por certificado o Zero Touch Provisioning) fallarán. El dispositivo en sí seguirá funcionando, pero ya no podrá demostrar su identidad criptográficamente. Por eso es tan importante la migración a SUDI-2099. --- SEGMENTO 5: RESUMEN Y PRÓXIMOS PASOS (aprox. 1 minuto) Para resumir: Cisco SUDI le proporciona una identidad de dispositivo vinculada al hardware que no se puede suplantar, clonar ni exportar. Es la base de una capa de infraestructura de confianza. Combinado con IEEE 802.1X y una política RADIUS bien configurada, elimina el riesgo de dispositivos no autorizados y permite un aprovisionamiento automatizado a gran escala. Sus tres acciones inmediatas: uno, audite su infraestructura de Cisco para comprobar las fechas de caducidad de SUDI mediante show crypto pki certificate. Dos, importe la CA raíz de Cisco en su almacén de confianza RADIUS y configure políticas EAP-TLS para los dispositivos de infraestructura. Tres, separe su política de autenticación de infraestructura de la de usuarios finales; responden a propósitos distintos y deben gestionarse de forma independiente. Si desea profundizar en cómo se integra Purple con Cisco Meraki y otros proveedores de hardware para ofrecer una segmentación de red basada en la identidad para invitados, empleados y residentes, visite purple.ai o lea las guías relacionadas que encontrará enlazadas bajo este episodio. Gracias por su atención. Nos vemos en el próximo informe técnico. --- FIN DEL GUION