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 su anfitrión, y hoy profundizaremos en los detalles de SCEP (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 usted es un gerente de TI, un arquitecto de redes o un 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 veremos teoría; nos enfocaremos en arquitectura y toma de decisiones. Comencemos. [SECCIÓN: Introducción y contexto - aproximadamente 1 minuto] Este es el problema al que probablemente se enfrenta. Tiene dispositivos del personal, laptops de contratistas y teléfonos personales que necesitan acceso a la red. Es probable que tenga una combinación de dispositivos administrados y no administrados. 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 una vulnerabilidad. La respuesta es 802.1X, el estándar IEEE para el control de acceso a la red basado en puertos. Este 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 encuentra 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 analizaremos hoy. [SECCIÓN: Análisis técnico detallado - aproximadamente 5 minutos] Comencemos con lo que realmente hace 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 requerir que una persona genere e instale manualmente cada uno. Este es el flujo de cuatro pasos. Paso uno: el dispositivo se conecta a un endpoint SCEP, una URL alojada de manera 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 su Autoridad de Certificación. Paso dos: el dispositivo presenta un desafío SCEP, un secreto compartido que demuestra que está autorizado para solicitar un certificado. En un entorno administrado por MDM como Microsoft Intune, este desafío se entrega de forma dinámica y exclusiva por dispositivo, lo cual es mucho más seguro que una contraseña estática compartida en todos los dispositivos. Paso tres: el dispositivo genera su propio par de claves pública y privada de manera local. 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. Es por esto que SCEP es la opción correcta para la autenticación de red, 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 el CSR, lo firma con la clave privada de la CA y devuelve el certificado X.509 firmado al dispositivo. El dispositivo ahora tiene 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 aprovisionado por SCEP. El servidor RADIUS valida tres cosas: la cadena de certificados de vuelta a la CA raíz de confianza, la fecha de vencimiento del certificado y si el certificado ha sido revocado - verificado contra una Lista de Revocación de Certificados, o CRL, o mediante OCSP, el Protocolo de Estado de Certificados en Línea. Si se aprueban 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á con la CA de confianza. Esa es su protección contra los ataques de gemelos malvados. Ahora hablemos de la secuencia de implementación en Microsoft Intune, porque es la plataforma MDM más común que vemos en entornos empresariales. Se implementan tres perfiles de configuración de Intune, en orden estricto. Primero, el perfil de Certificado Raíz de Confianza - esto 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 - esto le indica a los dispositivos la URL de SCEP, el formato del nombre del sujeto, el uso de la clave y el uso de clave extendido 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 - esto especifica el SSID, establece el tipo de seguridad en WPA2-Enterprise o WPA3-Enterprise, establece 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 depende del perfil Raíz de Confianza. Si los implementa fuera de secuencia, obtendrá errores. Una decisión de arquitectura que debe tomar es dónde alojar el servidor NDES. Debe estar accesible desde Internet para que los dispositivos puedan registrarse antes de llegar al sitio. 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 firewall entrantes 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 o las 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 falla más comunes que observamos. Modo de falla uno: discrepancia en la asignación de grupos. Esta es la causa más frecuente de fallas en el despliegue de perfiles de WiFi en Intune. Si su perfil de Root de confianza está asignado a un grupo de usuarios, su perfil SCEP a un grupo de dispositivos y su perfil de WiFi a un grupo de usuarios diferente, Intune no puede resolver la cadena de dependencias. Los tres perfiles deben dirigirse exactamente al mismo grupo de Azure AD, ya sea a todos los usuarios o a todos los dispositivos. Elija uno y sea consistente. Modo de falla dos: disponibilidad de la CRL. Su servidor RADIUS verifica la CRL para comprobar 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 después de 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 el uso de OCSP como una alternativa más resistente a la verificación de CRL. Modo de falla 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 de WiFi desplegado por MDM no especifica la CA de confianza y el nombre del 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 del servidor en su perfil de WiFi. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Pasemos a unas preguntas rápidas. Pregunta: ¿Necesitamos WPA3? Sí. Migre a WPA3-Enterprise. Este exige marcos de gestión protegidos, lo que bloquea los ataques de desautenticación. Todo el hardware de Cisco Meraki, HPE Aruba, Ruckus y Juniper Mist lo admite. Pregunta: ¿Qué pasa con los dispositivos que no admiten 802.1X, como los sensores de IoT o las impresoras heredadas? Utilice la omisión de autenticación MAC como último recurso, pero coloque esos dispositivos en una VLAN fuertemente restringida sin acceso a los recursos corporativos. Pregunta: ¿Cómo encaja Purple en 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 de 802.1X y SCEP gestiona el acceso del personal y de los dispositivos administrados. Funcionan en SSIDs independientes y 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 escala. La clave privada permanece en el dispositivo; esa es la ventaja de seguridad sobre PKCS. Realice el despliegue a través de MDM en una secuencia estricta: Root de confianza, luego el perfil SCEP y después el perfil de WiFi, todos dirigidos al mismo grupo. Publique NDES a través de Application Proxy o migre a PKI en la nube. Aplique la verificación de CRL o de OCSP en su servidor RADIUS. Y configure siempre la validación del certificado del servidor en los suplicantes del cliente. Si todavía utiliza una clave precompartida común para el WiFi del personal, ese es el cambio que debe realizar este trimestre. La infraestructura de certificados requiere más trabajo al principio, pero elimina toda una categoría de ataques basados en credenciales y, por lo general, reduce los tickets de soporte 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.