Cómo configurar SCEP para una autenticación de red 802.1X y BYOD segura

Hola y bienvenidos a esta sesión informativa técnica de Purple. Soy su anfitrión, y hoy vamos a entrar en detalle sobre SCEP (Simple Certificate Enrollment Protocol) y cómo configurarlo correctamente para una autenticación de red segura en entornos BYOD y 802.1X. Si es usted director de TI, arquitecto de redes o CTO responsable de la infraestructura de WiFi en un grupo hotelero, una cadena de tiendas, un estadio o una organización del sector público, esto le interesa directamente. Hoy no vamos a hablar de teoría. Vamos a hablar de arquitectura y decisiones. Comencemos. [SECCIÓN: Introducción y contexto - aproximadamente 1 minuto] Este es el problema al que probablemente se enfrente. Tiene dispositivos de empleados, portátiles de contratistas y teléfonos personales que necesitan acceso a la red. Probablemente tenga una mezcla de dispositivos gestionados y no gestionados. Y en algún lugar de su infraestructura, todavía hay una clave compartida WPA2 que conocen doce personas, tres de las cuales dejaron la empresa el año pasado. Eso no es una postura de seguridad. Es un riesgo. La respuesta es 802.1X, el estándar IEEE para el control de acceso a la red basado en puertos. Garantiza que ningún dispositivo transmita tráfico hasta que haya sido autenticado explícitamente. Pero 802.1X es solo el marco de trabajo. La verdadera pregunta es qué método de autenticación se utiliza dentro de él. Y para BYOD a gran escala, la respuesta es EAP-TLS con certificados provistos a través de SCEP. Eso es lo que vamos a analizar hoy. [SECCIÓN: Análisis técnico detallado - aproximadamente 5 minutos] Empecemos por lo que hace realmente SCEP. SCEP (Simple Certificate Enrollment Protocol) fue publicado originalmente como un borrador de Internet por el IETF en 1999, creado por VeriSign. Se formalizó como RFC 8894. Su función es sencilla: automatizar el proceso de emisión de certificados digitales X.509 a dispositivos a gran escala, sin necesidad de que una persona genere e instale manualmente cada uno de ellos. Este es el flujo de cuatro pasos. Paso uno: el dispositivo se conecta a un endpoint SCEP, una URL alojada de forma local a través de un rol de Windows Server llamado NDES (Network Device Enrollment Service) o a través de un proveedor de PKI en la nube. Esta URL es la puerta de enlace a su Entidad de Certificación (CA). Paso dos: el dispositivo presenta un desafío SCEP, un secreto compartido que demuestra que está autorizado para solicitar un certificado. En un entorno gestionado por MDM como Microsoft Intune, este desafío se entrega de forma dinámica y única por dispositivo, lo que es mucho más seguro que una contraseña estática compartida en todos los dispositivos. Paso tres: el dispositivo genera localmente su propio par de claves pública y privada. Crea una Solicitud de Firma de Certificado (CSR) utilizando la clave pública y la envía al servidor SCEP. Aquí está el punto crítico de seguridad: la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo (el TPM en Windows o el Secure Enclave en iOS) y nunca se transmite. Por eso SCEP es la opción correcta para la autenticación de red, y no PKCS, donde la CA genera la clave de forma centralizada y tiene que enviarla al dispositivo. Paso cuatro: la autoridad de certificación valida la CSR, la firma con la clave privada de la CA y devuelve el certificado X.509 firmado al dispositivo. El dispositivo ya dispone de una identidad criptográfica única. Ahora bien, ¿cómo se utiliza ese certificado para la autenticación 802.1X? Cuando el dispositivo se conecta a su SSID de WiFi, el punto de acceso (ya sea Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist o Ubiquiti UniFi) actúa como autenticador. No toma la decisión de autenticación por sí mismo, sino que reenvía el intercambio EAP a su servidor RADIUS. Este podría ser Microsoft NPS, Cisco ISE o Aruba ClearPass. El servidor RADIUS inicia un protocolo de enlace EAP-TLS. El dispositivo presenta su certificado de cliente aprovisionado por SCEP. El servidor RADIUS valida tres aspectos: la cadena de certificados hasta la CA raíz de confianza, la fecha de caducidad del certificado y si el certificado ha sido revocado (comprobándolo con una lista de revocación de certificados, o CRL, o mediante OCSP, el protocolo de estado de certificados en línea). Si se superan las tres comprobaciones, el servidor RADIUS envía un mensaje EAP-Success y el punto de acceso abre el puerto. El dispositivo ya está en la red. Se trata de una autenticación mutua. El dispositivo también valida el certificado del servidor RADIUS. Si alguien configura un punto de acceso no autorizado, el dispositivo lo rechazará porque el certificado del servidor no se validará con la CA de confianza. Esa es su protección contra los ataques de tipo «evil twin» o gemelo malvado. Hablemos ahora de la secuencia de despliegue en Microsoft Intune, ya que es la plataforma MDM más común que vemos en entornos empresariales. Debe desplegar tres perfiles de configuración de Intune en un orden estricto. En primer lugar, el perfil de certificado raíz de confianza: este envía el certificado de su CA raíz a cada dispositivo para que confíen en su PKI. En segundo lugar, el perfil de certificado SCEP: este indica a los dispositivos la URL de SCEP, el formato del nombre del sujeto, el uso de la clave y el uso extendido de la clave para la autenticación del cliente. El OID para la autenticación del cliente es 1.3.6.1.5.5.7.3.2. En tercer lugar, el perfil de WiFi: este especifica el SSID, establece el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise, define el tipo de EAP en EAP-TLS y lo vincula al perfil de certificado SCEP. El orden es importante. El perfil de WiFi depende del perfil SCEP, el cual a su vez depende del perfil de raíz de confianza. Si los despliega fuera de secuencia, obtendrá errores. Una decisión de arquitectura que debe tomar es dónde alojar el servidor NDES. Debe ser accesible desde Internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. La forma segura de hacerlo es publicar la URL de NDES a través de Microsoft Entra ID Application Proxy. Esto evita abrir puertos de entrada en el cortafuegos y le permite aplicar políticas de acceso condicional al flujo de registro. Para las organizaciones que desean eliminar por completo la infraestructura local, los proveedores de PKI en la nube (la propia Cloud PKI de Microsoft en Intune u otras opciones de terceros) eliminan por completo la dependencia de NDES. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Permítame detallar los tres modos de fallo más comunes que observamos. Modo de fallo uno: desajuste en la asignación de grupos. Esta es la causa más frecuente de fallos en el despliegue de perfiles WiFi en Intune. Si su perfil de Raíz de confianza está asignado a un grupo de Usuarios, su perfil SCEP a un grupo de Dispositivos y su perfil WiFi a un grupo de Usuarios diferente, Intune no podrá resolver la cadena de dependencias. Los tres perfiles deben dirigirse exactamente al mismo grupo de Azure AD: o bien todos a Usuarios o bien todos a Dispositivos. Elija uno y sea constante. Modo de fallo dos: disponibilidad de la CRL. Su servidor RADIUS comprueba la CRL para verificar que los certificados no hayan sido revocados. Si el Punto de distribución de CRL (la URL de CDP incrustada en el certificado) no está accesible, la autenticación fallará en todos los dispositivos. Esta es una causa común de interrupciones masivas tras realizar cambios en la red. Asegúrese de que sus CDP tengan una alta disponibilidad, idealmente publicados tanto en una URL interna como en una URL externa para dispositivos remotos. Considere OCSP como una alternativa más resiliente a la comprobación de CRL. Modo de fallo tres: no exigir la validación del certificado del servidor en los clientes. Esta es la configuración incorrecta con mayor impacto en los despliegues de 802.1X. Si su perfil WiFi desplegado por MDM no especifica la CA de confianza y el nombre de servidor RADIUS esperado, los dispositivos se conectarán a cualquier servidor que presente cualquier certificado. Eso anula por completo el propósito de EAP-TLS. Configure siempre la validación de servidor en su perfil WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Hagamos unas preguntas rápidas. Pregunta: ¿Necesitamos WPA3? Sí. Migre a WPA3-Enterprise. Este exige Tramas de gestión protegidas (PMF), lo que bloquea los ataques de desautenticación. Todo el hardware de Cisco Meraki, HPE Aruba, Ruckus y Juniper Mist lo soporta. Pregunta: ¿Qué ocurre con los dispositivos que no soportan 802.1X, como los sensores IoT o las impresoras heredadas? Utilice MAC Authentication Bypass como alternativa de respaldo, pero ubique esos dispositivos en una VLAN muy restringida y sin acceso a los recursos corporativos. Pregunta: ¿Cómo encaja Purple en todo esto? La plataforma de Guest WiFi de Purple gestiona la capa de acceso de visitas y clientes: el Captive Portal, la captura de datos y la analítica. Su infraestructura 802.1X y SCEP gestiona el acceso del personal y de los dispositivos administrados. Funcionan en SSIDs y VLANs independientes. Purple se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, por lo que su inversión en hardware está protegida. [SECTION: Summary and Next Steps - approximately 1 minute] Para resumir. SCEP automatiza la emisión de certificados a escala. La clave privada permanece en el dispositivo; esa es la ventaja de seguridad frente a PKCS. Despliegue a través de MDM en una secuencia estricta: Raíz de confianza, luego el perfil SCEP y después el perfil WiFi, todos dirigidos al mismo grupo. Publique NDES a través de Application Proxy o migre a una PKI en la nube. Exija la comprobación de CRL o OCSP en su servidor RADIUS. Y configure siempre la validación del certificado de servidor en los suplicantes de los clientes. Si todavía utiliza una clave precompartida para la red WiFi del personal, ese es el cambio que debe realizar este trimestre. La infraestructura de certificados requiere más trabajo inicial, pero elimina por completo un tipo de ataque basado en credenciales y, por lo general, reduce los tickets de soporte técnico relacionados con la red WiFi entre un 70 y un 80 por ciento una vez implementada. Para obtener la guía técnica completa, los diagramas de arquitectura y ejemplos prácticos, visite purple dot ai. Gracias por escucharnos.