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

Guía de Configuración SCEP para Grandes Empresas: Autenticación WiFi Basada en Certificados para Educación Superior y Grandes Redes Un Informe Técnico de Purple - Guion de Podcast (aproximadamente 10 minutos) --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Bienvenido a la serie de Informes Técnicos 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 implementar realmente la autenticación WiFi basada en certificados a escala, utilizando SCEP, en una gran red, ya sea un campus universitario, un grupo hotelero multi-sitio o un gran patrimonio 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 la mayoría de los equipos se equivocan, 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 que probablemente ya ha decidido que necesita alejarse de las claves precompartidas. Lo que necesita ahora es el mapa de implementación. Comencemos. --- ANÁLISIS TÉCNICO PROFUNDO - aproximadamente 5 minutos Así que, primeros principios. SCEP son las siglas de Simple Certificate Enrollment Protocol (Protocolo de Registro de Certificados Simple). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en el entorno empresarial 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 manipular 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 (Extensible Authentication Protocol con Transport Layer Security), que se encuadra dentro del marco de trabajo 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 le protege contra los ataques de "evil twin" (gemelo malvado), en los que un atacante crea un punto de acceso fraudulento para recopilar credenciales. Así es como funciona toda la cadena. Un dispositivo gestionado (el ordenador portátil de un estudiante, el teléfono de un empleado, un terminal de punto de venta de un hotel) necesita conectarse a la red inalámbrica corporativa. Su plataforma MDM, que podría ser Microsoft Intune o Jamf, envía una carga útil SCEP a ese dispositivo. La carga útil 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 localmente su propio par de claves pública y privada. 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 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 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 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. 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, fundamentalmente, 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 profesor obtiene la VLAN 10 (acceso a sistemas de investigación internos). El dispositivo de gestión de instalaciones obtiene la VLAN 30 (acceso a sistemas de gestión de edificios). Todo esto se gestiona mediante 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 de certificado SCEP (específicamente el Subject Alternative Name) pueden contener el nombre de usuario principal de Microsoft Entra ID, Okta o Google Workspace. Esto vincula el certificado a una identidad específica, lo que significa que al desactivar una cuenta en Entra ID y desvincular el dispositivo del MDM, el certificado se revoca y el acceso WiFi se corta automáticamente. Esta es la historia de revocación que las claves precompartidas simplemente no pueden ofrecer. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos Muy bien, hablemos de la secuencia de despliegue, porque aquí es donde la mayoría de los equipos fallan. La secuencia no es negociable: primero el certificado Trusted Root, segundo el perfil de certificado SCEP y 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. 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 por sorpresa a los equipos constantemente. Tercero: accesibilidad del servidor NDES. Su servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a la oficina. 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 (CRL) cada vez que un dispositivo se autentica. Si su punto de distribución de CRL no está disponible (ya sea porque un servidor se ha caído o porque la URL ha cambiado), la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso significa una caída del servicio en todo el campus. Asegúrese de que sus endpoints de CRL tengan alta disponibilidad y pruebe la revocación antes de la puesta en marcha. Para redes grandes (cualquier tamaño superior a 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 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: un portal de autogestión para usuarios 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 con su red corporativa autenticada por certificado. ¿Qué ocurre con iOS y Android? Ambas plataformas son compatibles con 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 un 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 En resumen, 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 (Root de confianza, luego perfil SCEP y, por último, perfil WiFi) es fija. La segmentación de 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 administrativo, junto con una capa de WiFi de invitados independiente para los estudiantes en sus dispositivos personales, ofrece tanto seguridad como una excelente experiencia de usuario sin concesiones. Si desea profundizar más, la guía de Purple sobre la autenticación WiFi empresarial sin Active Directory ni un servidor local abarca la vía nativa de la nube. Y si está pensando en lo que ocurre cuando un empleado se marcha, nuestra guía sobre cómo revocar el acceso a la WiFi explica todo el flujo de trabajo de revocación. Gracias por su atención. Soy del equipo técnico de Purple y nos vemos en la próxima sesión informativa. --- FIN DEL GUION