Guía de configuración de SCEP empresarial: Autenticación Wi-Fi basada en certificados para educación superior y grandes redes

Guía de configuración de SCEP empresarial: Autenticación WiFi basada en certificados para educación superior y grandes redes Un informe técnico de Purple - Guión de podcast (aproximadamente 10 minutos) --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Bienvenidos a la serie de informes técnicos de Purple. Hoy 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 de múltiples sitios o una gran propiedad 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 implementación que la mayoría de los equipos hace mal, 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. Este es un informe de consultoría, no un tutorial. Asumo que sabe qué es un servidor RADIUS y probablemente ya haya decidido que necesita dejar atrás las claves precompartidas. Lo que necesita ahora es el mapa de implementación. Comencemos. --- ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos Entonces, primeros principios. SCEP significa Simple Certificate Enrollment Protocol. Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en empresas durante más de una década antes de eso. Su función es sencilla: automatizar el proceso de obtención de un certificado digital en un dispositivo administrado sin necesidad de que una persona intervenga en cada máquina. En el contexto de la autenticación WiFi, SCEP es el mecanismo de entrega. El protocolo de autenticación real que busca es EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), que se encuentra dentro del marco 802.1X. EAP-TLS es ampliamente considerado como el método de autenticación más seguro para redes inalámbricas empresariales porque 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 lo protege contra los ataques de gemelo malvado (evil twin), donde un atacante levanta un punto de acceso no autorizado para recopilar credenciales. Así es como funciona toda la cadena. Un dispositivo administrado (la laptop de un estudiante, el teléfono de un empleado, una 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 de SCEP a ese dispositivo. El payload contiene dos cosas: la URL de SCEP, que apunta a su servidor NDES o puerta de enlace 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 localmente. Esto es crítico. La clave privada nunca sale del dispositivo. Se genera en el dispositivo, se almacena en el enclave seguro o TPM, y nunca se transmite a través de la red. Luego, el dispositivo crea una Solicitud de Firma de Certificado (CSR) y la envía a la puerta de enlace SCEP. La puerta de enlace valida el desafío, reenvía la CSR a su Autoridad de Certificación, y la CA la firma y devuelve el certificado público al dispositivo. A partir de ese momento, cuando el dispositivo se conecta al SSID de su WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado contra la cadena de confianza de su CA, verifica la Lista de Revocación de Certificados para confirmar que el certificado no haya sido revocado y, si todo está en orden, envía un mensaje de aceptación al punto de acceso. El dispositivo está en la red. Todo el proceso es invisible para el usuario. Ahora, hablemos de dónde se ubica SCEP en relación con 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 a través de la red, lo que introduce una superficie de ataque teórica. PKCS está bien 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 independientes del proveedor, lo que significa que funcionan en puntos de acceso de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. 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, fundamentalmente, donde configura la asignación dinámica de VLAN. Las VLAN dinámicas son la forma en que segmenta la red por identidad. El dispositivo de un estudiante obtiene la VLAN 20 (solo acceso a Internet). El dispositivo de un profesor obtiene la VLAN 10 (acceso a sistemas de investigación internos). El dispositivo de administración de instalaciones obtiene la VLAN 30 (acceso a sistemas de gestión de edificios). Todo esto se basa en los atributos del certificado y la política de RADIUS, sin intervención manual por dispositivo. Para la integración con proveedores de identidad, los atributos del certificado SCEP (específicamente el Nombre Alternativo del Sujeto o Subject Alternative Name) pueden contener el nombre principal del 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 desvincula el 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 implementación, porque aquí es donde la mayoría de los equipos tropieza. La secuencia no es negociable: primero el certificado de Raíz de Confianza, 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 implementado en el dispositivo, el perfil WiFi fallará con un error críptico que parece una mala configuración, pero que en realidad es solo un problema de sincronización. El segundo error común es la asignación de grupos. Los tres perfiles (Raíz de Confianza, SCEP y WiFi) deben implementarse 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 puede resolver la dependencia y el perfil WiFi se mostrará como No aplicable. Esto toma por sorpresa a los equipos constantemente. Tercero: accesibilidad del servidor NDES. Su servidor NDES debe ser accesible desde Internet para que los dispositivos puedan enrolarse antes de llegar al sitio. La forma correcta de hacerlo es a través de Azure AD Application Proxy, no abriendo un puerto en su firewall. App Proxy le brinda acceso remoto seguro sin puertos entrantes y le permite aplicar políticas de Acceso Condicional al flujo de enrolamiento. Cuarto: disponibilidad de la CRL. Su servidor RADIUS verifica la Lista de Revocación de Certificados cada vez que un dispositivo se autentica. Si su punto de distribución de la 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 es una caída del servicio en todo el campus. Haga que sus endpoints de CRL tengan alta disponibilidad y pruebe la revocación antes de salir a producción. Para redes grandes (cualquier red con más de 500 dispositivos), considere una puerta de enlace SCEP en la nube en lugar de un NDES local. Las puertas de enlace en la nube eliminan el punto único de falla de NDES, se 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 ¿Can SCEP handle BYOD devices that are not MDM-enrolled? No directamente. SCEP requiere el enrolamiento en el MDM para enviar el payload del certificado. Para BYOD no administrados, necesita un enfoque diferente: ya sea un portal de onboarding de autoservicio o un SSID independiente que utilice un Captive Portal con verificación de identidad. La plataforma de Purple maneja esa capa de invitados y BYOD de manera limpia, coexistiendo con su red de personal autenticada por certificados. ¿Qué pasa con iOS y Android? Ambas plataformas admiten SCEP de forma nativa. iOS es compatible con 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 administrados. Elimina las credenciales compartidas, le brinda 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 implementación (Raíz de Confianza, luego el perfil SCEP y luego el perfil WiFi) es fija. La asignación de grupos debe ser consistente. 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 y de los profesores, junto con una capa de WiFi de invitados independiente para los estudiantes en dispositivos personales, le brinda seguridad y 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 de la nube. And if you are thinking about what happens when an employee leaves, nuestra guía sobre cómo revocar el acceso WiFi detalla todo el flujo de trabajo de revocación. Gracias por escuchar. Soy del equipo técnico de Purple y nos vemos en el próximo informe. --- FIN DEL GUIÓN