Guía de configuración de SCEP empresarial: autenticación WiFi basada en certificados para educación superior y grandes redes

Guía de configuración de SCEP corporativo: autenticación WiFi basada en certificados para educación superior y grandes redes Sesión técnica de Purple - Guion de podcast (aproximadamente 10 minutos) --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Le damos la bienvenida a la serie de sesiones técnicas de Purple. Hoy voy a hablar de algo que llega a muchas bandejas de entrada de TI pero que rara vez recibe una respuesta clara: ¿cómo se implementa realmente la autenticación WiFi basada en certificados a escala, utilizando SCEP, en una gran red, ya sea un campus universitario, un grupo hotelero con múltiples ubicaciones o una gran infraestructura del sector público? Vamos a cubrir todo el panorama. Qué hace realmente SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de despliegue en la que se equivocan la mayoría de los equipos, dos escenarios de implementación del mundo real y los errores comunes que le costarán un fin de semana de su vida si no los planifica. Esta es una sesión informativa para consultores, no un tutorial. Asumo que sabe qué es un servidor RADIUS y que probablemente ya haya decidido que necesita abandonar las claves precompartidas. Lo que necesita ahora es el mapa de implementación. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos Comencemos por los principios básicos. SCEP significa Protocolo simple de inscripción de certificados (Simple Certificate Enrollment Protocol). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en entornos corporativos desde hacía más de una década. Su función es sencilla: automatizar el proceso de obtención de un certificado digital en un dispositivo gestionado sin necesidad de que una persona tenga que intervenir físicamente en cada máquina. En el contexto de la autenticación WiFi, SCEP es el mecanismo de entrega. El protocolo de autenticación real al que se dirige es EAP-TLS - Protocolo de autenticación extensible con seguridad de la capa de transporte - que se integra dentro del marco 802.1X. EAP-TLS se considera de forma generalizada como el método de autenticación más seguro para redes inalámbricas corporativas, ya que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados válidos. Ninguna de las partes confía en la otra sin una prueba criptográfica. Esa autenticación mutua es lo que le protege contra los ataques de tipo "evil twin" - donde un atacante despliega un punto de acceso no autorizado para recopilar credenciales.Así es como funciona toda la cadena. Un dispositivo gestionado (un portátil de un estudiante, un teléfono de la plantilla o un terminal de punto de venta de un hotel) necesita unirse a la red inalámbrica corporativa. Su plataforma MDM, que podría ser Microsoft Intune o Jamf, envía un payload SCEP a ese dispositivo. El payload contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o pasarela SCEP en la nube, y una contraseña de desafío o secreto compartido. El dispositivo genera su propio par de claves pública y privada de forma local. Esto es fundamental. La clave privada nunca sale del dispositivo. Se genera en el propio dispositivo, se almacena en el enclave seguro o TPM y nunca se transmite a través de la red. A continuación, el dispositivo crea una solicitud de firma de certificado (CSR) y la envía a la pasarela SCEP. La pasarela valida el desafío, reenvía la CSR a su entidad de certificación (CA), y la CA la firma y devuelve el certificado público al dispositivo. A partir de ese momento, cuando el dispositivo se conecta a su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado comparándolo con la cadena de confianza de su CA, comprueba la lista de revocación de certificados para confirmar que el certificado no ha sido revocado y, si todo es correcto, envía un mensaje de aceptación al punto de acceso. El dispositivo ya está en la red. Todo el proceso es invisible para el usuario. Ahora, hablemos de dónde se sitúa SCEP con respecto a la alternativa, que es PKCS. PKCS (Public Key Cryptography Standards) es el otro método de entrega de certificados compatible con plataformas como Intune. Con PKCS, la CA genera tanto la clave pública como la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo. Eso significa que la clave privada viaja por la red, lo que introduce una superficie de ataque teórica. PKCS es adecuado para casos de uso como el cifrado de correo electrónico S/MIME, donde el depósito de claves es realmente deseable. Para la autenticación WiFi, SCEP es la opción correcta. La clave privada se queda en el dispositivo, y punto. Ahora, la capa de hardware. SCEP y EAP-TLS son estándares neutros respecto al proveedor, lo que significa que funcionan en puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. En su configuración de RADIUS (ya sea Windows NPS, FreeRADIUS o un servicio RADIUS en la nube) es donde define la política de validación de certificados y, lo que es fundamental, donde configura la asignación dinámica de VLAN. Las VLAN dinámicas son la forma de segmentar la red por identidad. El dispositivo de un estudiante obtiene la VLAN 20 (solo acceso a internet). El dispositivo de un docente obtiene la VLAN 10 (acceso a los sistemas de investigación internos). Un dispositivo de gestión de instalaciones obtiene la VLAN 30 (acceso a los sistemas de gestión del edificio). Todo esto se gestiona mediante los atributos del certificado y la política de RADIUS, sin intervención manual en cada dispositivo. Para la integración con proveedores de identidad, los atributos de certificado SCEP - específicamente el Subject Alternative Name - pueden portar el nombre principal de usuario de Microsoft Entra ID, Okta o Google Workspace. Eso vincula el certificado a una identidad específica, lo que significa que cuando deshabilita una cuenta en Entra ID y el MDM anula el registro del dispositivo, el certificado se revoca y el acceso WiFi se corta automáticamente. Esa es la historia de revocación que las claves precompartidas simplemente no pueden ofrecer. - - - RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos Bien, hablemos de la secuencia de despliegue, porque aquí es donde la mayoría de los equipos tropiezan. La secuencia no es negociable: primero el certificado Trusted Root, segundo el perfil de certificado SCEP, tercero el perfil WiFi. Tanto Intune como Jamf imponen dependencias de perfil. Si su perfil WiFi hace referencia a un certificado SCEP que aún no se ha desplegado en el dispositivo, el perfil WiFi fallará con un error críptico que parece una configuración incorrecta pero que en realidad es solo un problema de sincronización de tiempo. El segundo error común es la segmentación por grupos. Los tres perfiles - Trusted Root, SCEP y WiFi - deben desplegarse exactamente en el mismo grupo de Azure AD o Jamf. Si el perfil SCEP se dirige a un grupo de usuarios y el perfil WiFi se dirige a un grupo de dispositivos, Intune no podrá resolver la dependencia y el perfil WiFi se mostrará como No aplicable. Esto pilla a los equipos desprevenidos constantemente. Tercero: accesibilidad del servidor NDES. Su servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. La forma correcta de hacerlo es a través de Azure AD Application Proxy, no abriendo un puerto en su firewall. App Proxy le ofrece un acceso remoto seguro sin puertos entrantes y le permite aplicar políticas de acceso condicional al flujo de registro. Cuarto: disponibilidad de la CRL. Su servidor RADIUS comprueba la Lista de Revocación de Certificados cada vez que un dispositivo se autentica. Si su punto de distribución de CRL no está disponible - porque un servidor está caído o la URL ha cambiado - la autenticación falla para todos los dispositivos de la red simultáneamente. Eso se traduce en una interrupción en todo el campus. Haga que sus endpoints de CRL sean altamente disponibles y pruebe la revocación antes de la puesta en marcha. Para redes grandes - cualquier cosa por encima de 500 dispositivos - considere una pasarela SCEP en la nube en lugar de un NDES local. Las pasarelas en la nube eliminan el punto único de fallo de NDES, escalan horizontalmente y, por lo general, se integran directamente con los servicios RADIUS en la nube, eliminando otra dependencia de infraestructura. - - - PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto ¿Puede SCEP gestionar dispositivos BYOD que no están registrados en el MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga útil del certificado. Para BYOD no gestionados, necesita un enfoque diferente - ya sea un portal de autoservicio de incorporación o un SSID independiente que utilice un Captive Portal con verificación de identidad. La plataforma de Purple gestiona esa capa de invitados y BYOD de forma limpia, conviviendo junto a su red de personal autenticada por certificado.¿Qué pasa con iOS y Android? Ambas plataformas admiten SCEP de forma nativa. iOS admite SCEP desde iOS 4. Android Enterprise admite SCEP a través de Intune y otros MDM. La configuración es ligeramente diferente según la plataforma, pero el protocolo subyacente es idéntico. ¿Funciona EAP-TLS con WPA3? Sí. WPA3-Enterprise exige el modo de seguridad de 192 bits para entornos sensibles, y EAP-TLS es totalmente compatible. De hecho, WPA3-Enterprise con EAP-TLS es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales y financieras. - RESUMEN Y PRÓXIMOS PASOS - aproximadamente 1 minuto Para resumir. La autenticación WiFi mediante certificados SCEP es la arquitectura adecuada para cualquier red con más de 50 dispositivos gestionados. Elimina las credenciales compartidas, proporciona una identidad por dispositivo, permite la segmentación dinámica de VLAN y se integra directamente con su proveedor de identidad para la revocación automatizada. La secuencia de despliegue (primero la raíz de confianza, luego el perfil SCEP y después el perfil WiFi) es fija. La segmentación por grupos debe ser coherente. La disponibilidad de la CRL no es opcional. Específicamente para la educación superior, la combinación de SCEP para los dispositivos del personal docente y de administración, junto con una capa de WiFi para invitados independiente para los estudiantes en sus dispositivos personales, ofrece tanto seguridad como una excelente experiencia de usuario sin compromisos. Si desea profundizar más, la guía de Purple sobre autenticación WiFi empresarial sin Active Directory ni un servidor local cubre el camino nativo en la nube. Y si está pensando en qué ocurre cuando un empleado se marcha, nuestra guía sobre cómo revocar el acceso a WiFi detalla todo el flujo de trabajo de revocación. Gracias por escucharnos. Soy del equipo técnico de Purple y nos vemos en la próxima sesión. - FIN DEL GUION