Entendiendo Cisco SUDI: Identidad de Dispositivo Basada en Hardware en el Control de Acceso a la Red

Entendiendo Cisco SUDI: Identidad de Dispositivo 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 un informe técnico de Purple. Voy a pasar los próximos diez minutos explicándoles Cisco SUDI (Secure Unique Device Identifier), qué es en realidad, cómo encaja en su arquitectura de control de acceso a la red y qué deben hacer al respecto si operan infraestructura de Cisco a gran escala. Esto está dirigido a arquitectos de red, gerentes de TI y directores de tecnología (CTO) en recintos (hoteles, complejos comerciales, estadios, centros de conferencias), en cualquier lugar donde operen WiFi empresarial y necesiten tener la certeza de que el hardware de su red es exactamente lo que afirma ser. Comencemos con el problema que resuelve SUDI. En cualquier red de un recinto grande, se tienen decenas o cientos de puntos de acceso, switches y controladores. La pregunta de la que depende su postura de seguridad es: ¿cómo sabe que cada uno de esos dispositivos es un producto Cisco genuino y no modificado, y no una imitación, una unidad comprometida o un dispositivo que ha sido alterado en tránsito? Ese es el vacío que cierra 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 a un servidor, se emite a una pieza de hardware específica durante su fabricación. Contiene el identificador de producto y el número de serie del dispositivo, y está arraigado en la propia infraestructura de clave pública de Cisco. Esto es lo que diferencia a SUDI de un certificado de software que usted mismo instalaría. El certificado SUDI, junto con su par de claves asociado, reside dentro de un chip resistente a manipulaciones llamado módulo Trust Anchor, 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 de la industria para Identificadores de Dispositivos Seguros, o DevIDs. Bajo el estándar 802.1AR, la credencial instalada por el fabricante se denomina Identificador Inicial de Dispositivo, o IDevID. El SUDI de Cisco es exactamente eso: un IDevID que Cisco instala en la fábrica. Puede complementarlo con un Identificador de Dispositivo Localmente Significativo, o LDevID, que emite su propia PKI para políticas de autorización locales. Ahora, ¿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 en 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 luego aplica la política de red adecuada. Esto es significativamente más sólido que la omisión de direcciones MAC (MAC address bypass), que es la alternativa 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 recinto, esto es importante por tres razones. Primero, elimina el riesgo de que puntos de acceso no autorizados se unan a su red. Un dispositivo falsificado o no autorizado simplemente no puede presentar un SUDI válido. Segundo, permite el aprovisionamiento automatizado y sin intervención (Zero Touch Provisioning): un nuevo dispositivo se envía a su recinto, se enciende, presenta su SUDI y su sistema de gestión lo verifica contra su inventario antes de enviar la configuración. Sin intervención manual. Tercero, le brinda un registro de auditoría verificable criptográficamente. Cada dispositivo que se autenticó en su red lo hizo con un certificado que demuestra que es un producto Cisco específico y con nombre. Permítame hablar sobre el módulo Trust Anchor 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 cosas: 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 huella digital del hardware. Vale la pena destacar esto último: Cisco registra la huella digital de los componentes de hardware críticos de un dispositivo durante la fabricación y la almacena en el TAm. Cuando el dispositivo arranca, compara la huella digital del hardware detectada con la almacenada. Si no coinciden, el dispositivo no arrancará. Esto detecta la manipulación del hardware en tránsito, una preocupación real para implementaciones en grandes recintos donde el hardware puede pasar por varias manos antes de la instalación. Un problema operativo que debe tener en cuenta: los certificados SUDI emitidos antes de mayo de 2019 vencen a los diez años de la 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 llamada SUDI-2099, válidos hasta diciembre de 2099. Si tiene hardware de la serie Catalyst 9000 fabricado antes de 2019, debe verificar las fechas de vencimiento de su SUDI ahora mismo. El comando es show crypto pki certificate en IOS-XE. Busque el trustpoint CISCO_IDEVID_SUDI y verifique la fecha de finalización. Si utiliza Catalyst 9200, actualice a IOS-XE 17.12.2 o posterior para asegurarse de que está utilizando el certificado 2099 correcto. --- SEGMENTO 3: RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aprox. 2 minutos) Permítame darle un panorama de la implementación práctica. Si está desplegando autenticación basada en SUDI en el entorno de un establecimiento, esta es la secuencia que funciona. 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 validar contra una CA externa funcionará. Necesita importar la CA raíz de Cisco y los certificados de la CA ACT2 SUDI en su almacén de confianza de RADIUS. Estos están disponibles públicamente en el portal PKI de Cisco. Luego, configure su política 802.1X para requerir 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 personal y de invitados son diferentes y deben estar en conjuntos de políticas distintos en ISE. Para nuevos despliegues, habilite Zero Touch Provisioning. Su sistema de gestión de red (Cisco DNA Centre o Catalyst Centre) 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, los errores comunes. El más frecuente que veo es mezclar la autenticación SUDI con la omisión de dirección MAC 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 a través de SUDI, y punto. Los dispositivos que no son compatibles con SUDI van a una VLAN de cuarentena en espera de una revisión manual. El segundo error común es el vencimiento de los certificados. Configure el monitoreo de las fechas de vencimiento de SUDI en toda su infraestructura ahora mismo. No espere a que ocurra 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 las señales de salud de los dispositivos (incluido el estado de autenticación) en un único panel de control, lo que hace que este tipo de monitoreo proactivo sea práctico a gran escala. El tercer error común es la pérdida de enfoque del alcance. SUDI autentica el dispositivo de hardware. No autentica al usuario que se conecta a través de ese dispositivo. Aún necesita una capa de identidad independiente para invitados, personal y residentes. Ahí es donde entra una plataforma como Purple: nosotros nos encargamos de la capa de identidad humana, la captura de consentimiento, la asignación de VLAN para el tráfico de invitados y la analítica, mientras que SUDI se encarga de la capa de infraestructura subyacente. --- SEGMENTO 4: PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto) Permítame responder rápidamente a tres preguntas que me hacen con frecuencia. ¿SUDI reemplaza mi PKI existente? No. SUDI es un IDevID instalado por el fabricante. Demuestra que el dispositivo es hardware genuino de Cisco. Su PKI empresarial emite LDevIDs y certificados de usuario para todo lo demás. Funcionan en paralelo. ¿Puedo usar 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 tienen sus propios mecanismos de identidad de dispositivos. El estándar subyacente (IEEE 802.1AR) es neutral en cuanto al proveedor, pero cada fabricante lo implementa de manera diferente. ¿Qué sucede cuando un certificado SUDI expira? Los servicios que dependen de SUDI para la autenticación (HTTPS, SSH con autenticación de certificado, Zero Touch Provisioning) fallarán. El dispositivo en sí continúa funcionando, pero ya no puede probar su identidad de manera criptográfica. Es por eso que la migración a SUDI-2099 es tan importante. --- SEGMENTO 5: RESUMEN Y PRÓXIMOS PASOS (aprox. 1 minuto) Para resumir: Cisco SUDI le brinda una identidad de dispositivo arraigada en el hardware que no se puede suplantar, clonar ni exportar. Es la base de una capa de infraestructura confiable. Combinado con IEEE 802.1X y una política RADIUS bien configurada, elimina el riesgo de dispositivos no autorizados y permite el aprovisionamiento automatizado a escala. Sus tres acciones inmediatas: uno, audite su inventario de Cisco para identificar las fechas de vencimiento de SUDI utilizando 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 dispositivos de infraestructura. Tres, separe su política de autenticación de infraestructura de su política de autenticación de usuario final; sirven para propósitos diferentes y deben administrarse de forma independiente. Si desea profundizar en cómo Purple se integra con Cisco Meraki y otros proveedores de hardware para ofrecer segmentación de red basada en la identidad para invitados, personal y residentes, visite purple.ai o lea las guías relacionadas que se encuentran enlazadas debajo de este episodio. Gracias por escuchar. Nos vemos en el próximo informe. --- FIN DEL GUION