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

Hola y bienvenidos a este informe técnico de Purple. Soy vuestro presentador y hoy vamos a entrar en detalle sobre SCEP - el Protocolo de Inscripción de Certificados Simple - y cómo configurarlo correctamente para una autenticación de red segura de BYOD y 802.1X. Si eres un responsable de TI, un arquitecto de redes o un CTO responsable de la infraestructura WiFi en un grupo hotelero, un entorno de retail, un estadio o una organización del sector público, esto te interesa directamente. Hoy no vamos a hablar de teoría. Vamos a hablar de arquitectura y decisiones. Empecemos. [SECCIÓN: Introducción y contexto - aproximadamente 1 minuto] Este es el problema al que probablemente te enfrentas. Tienes dispositivos de empleados, ordenadores portátiles de contratistas y teléfonos personales que necesitan acceso a la red. Probablemente tengas una mezcla de dispositivos gestionados y no gestionados. Y en algún lugar de tu infraestructura, todavía hay una clave WPA2 precompartida que conocen doce personas, de las cuales tres dejaron la empresa el año pasado. Eso no es una postura de seguridad. Eso es una vulnerabilidad. 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 de forma explícita. 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 con 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 punto de conexión SCEP - una URL alojada de forma local a través de un rol de Windows Server llamado NDES, el Servicio de Inscripción de Dispositivos de Red, o a través de un proveedor de PKI en la nube. Esta URL es la puerta de enlace a tu Autoridad de Certificación. Paso dos: el dispositivo presenta un desafío SCEP - un secreto compartido que demuestra que está autorizado a 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 por todos los dispositivos. Paso tres: el dispositivo genera su propio par de claves pública y privada localmente. Crea una Solicitud de Firma de Certificado - un CSR - utilizando la clave pública y la envía al servidor SCEP. Aquí está el punto de seguridad crítico: la clave privada nunca sale del dispositivo. Se genera localmente, se almacena en el enclave seguro del dispositivo - que es el TPM en Windows o el Secure Enclave en iOS - y nunca se transmite. Por esto 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 cuenta ahora con una identidad criptográfica única. Ahora, ¿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 el autenticador. No toma la decisión de autenticación por sí mismo. 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 provisto por SCEP. El servidor RADIUS valida tres cosas: la cadena de certificados hasta la CA raíz de confianza, la fecha de caducidad del certificado y si el certificado ha sido revocado - verificado mediante una Lista de Revocación de Certificados, o CRL, o a través de 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 está en la red. Esto es 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á frente a la CA de confianza. Esa es su protección contra los ataques de gemelo malvado. Ahora hablemos de la secuencia de despliegue en Microsoft Intune, ya que es la plataforma MDM más común que vemos en entornos empresariales. Se despliegan tres perfiles de configuración de Intune, en un orden estricto. Primero, 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. Segundo, el perfil de Certificado SCEP - este indica a los dispositivos la URL de SCEP, el formato del nombre de sujeto, el uso de la clave y el uso extendido de la clave para la autenticación de clientes. El OID para la autenticación de clientes es 1.3.6.1.5.5.7.3.2. Tercero, 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 se vincula al perfil de certificado SCEP. El orden importa. 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 opciones de terceros - eliminan por completo la dependencia de NDES. [SECTION: Recomendaciones de implementación y errores comunes - aproximadamente 2 minutos] Permítame presentarle 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, ya sean todos usuarios o todos dispositivos. Elija uno y sea coherente. 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 la CRL (la URL de CDP integrada en el certificado) no está accesible, la autenticación fallará para 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 la posibilidad de utilizar OCSP como una alternativa más resistente a la comprobación de la CRL. Modo de fallo tres: no imponer la validación del certificado de servidor en los clientes. Esta es la configuración incorrecta que más repercusiones tiene en los despliegues 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] Respondamos rápidamente a algunas preguntas. Pregunta: ¿Necesitamos WPA3? Sí. Realice la migración a WPA3-Enterprise. Este estándar exige el uso de 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 es compatible con esta tecnología. Pregunta: ¿Qué ocurre con los dispositivos que no admiten 802.1X, como los sensores IoT o las impresoras heredadas? Utilice la derivación de autenticación de MAC (MAB) como alternativa, pero ubique esos dispositivos en una VLAN fuertemente restringida 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 visitantes y clientes: el Captive Portal, la captura de datos y las analíticas. Su infraestructura 802.1X y SCEP se encarga del acceso del personal y de los dispositivos gestionados. Funcionan en SSIDs independientes y en VLANs separadas. 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 gran escala. La clave privada permanece en el dispositivo, lo que supone una ventaja de seguridad con respecto a PKCS. Realice el despliegue a través de MDM en una secuencia estricta: primero el de raíz de confianza, luego el perfil SCEP y, por último, el perfil WiFi, todos dirigidos al mismo grupo. Publique NDES a través de un proxy de aplicaciones o migre a una PKI en la nube. Imponga la comprobación de CRL u 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 compartida para el WiFi del personal, ese es el cambio que debe realizar este trimestre. La infraestructura de certificados requiere más trabajo inicial, pero elimina toda una categoría de ataques basados en credenciales y, por lo general, reduce los tickets de soporte técnico relacionados con el 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 escuchar.