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

Guía de configuración de SCEP empresarial: Autenticación de WiFi basada en certificados para educación superior y grandes redes Resumen técnico de Purple: libreto de pódcast (aproximadamente 10 minutos) --- INTRODUCCIÓN Y CONTEXTO - aproximadamente 1 minuto Le damos la bienvenida a la serie de resúmenes técnicos de Purple. Hoy hablaré sobre un tema que llega a muchas bandejas de entrada de TI pero que rara vez recibe una respuesta directa: ¿cómo se implementa realmente la autenticación de WiFi basada en certificados a escala, utilizando SCEP, en una red de gran tamaño? Ya sea un campus universitario, un grupo hotelero con múltiples ubicaciones o un gran sector público. Vamos a cubrir el panorama completo. Lo que realmente hace SCEP, cómo encaja en una arquitectura 802.1X, la secuencia de implementación en la que la mayoría de los equipos se equivocan, dos escenarios de implementación del mundo real y los errores 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 dejar atrás las claves precompartidas. Lo que necesita ahora es el mapa de implementación. Comencemos. --- INMERSIÓN TÉCNICA PROFUNDA - aproximadamente 5 minutos Primero, los principios básicos. SCEP significa Simple Certificate Enrollment Protocol (Protocolo simple de inscripción de certificados). Fue formalizado por el IETF como RFC 8894 en 2020, aunque ya se utilizaba ampliamente en empresas desde hace 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 de WiFi, SCEP es el mecanismo de entrega. El protocolo de autenticación real que se busca implementar es EAP-TLS - Protocolo de autenticación extensible con seguridad de la capa de transporte - el cual se encuentra dentro de la estructura de 802.1X. EAP-TLS se considera el método de autenticación más seguro para redes inalámbricas empresariales porque requiere que tanto el dispositivo del 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 protege contra los ataques de "evil twin" - donde un atacante monta un punto de acceso falso para recolectar credenciales. Así es como funciona la cadena completa. Un dispositivo administrado - una laptop de estudiante, un teléfono del personal, una terminal de punto de venta de un hotel - necesita unirse a la red inalámbrica corporativa. Su plataforma de 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 gateway 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 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 - un CSR - y la envía al gateway SCEP. El gateway valida el desafío, reenvía el CSR a su Autoridad de Certificación, y la CA lo 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 frente a la cadena de confianza de su CA, comprueba 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 de WiFi, SCEP es la opción correcta. La clave privada se queda en el dispositivo, punto final. Ahora, la capa de hardware. SCEP y EAP-TLS son estándares neutrales del 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 se define la política de validación de certificados y, fundamentalmente, donde se configura la asignación dinámica de VLAN. Las VLAN dinámicas son la forma en que se segmenta la red por identidad. Un dispositivo de estudiante obtiene la VLAN 20 - solo acceso a Internet. Un dispositivo del cuerpo docente obtiene la VLAN 10 - acceso a sistemas internos de investigación. Un dispositivo de administración de instalaciones obtiene la VLAN 30 - acceso a sistemas de gestión de edificios. Todo esto se impulsa 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 portar el nombre principal del usuario desde 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 contar. - 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 se equivoca. 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 errónea pero que en realidad es solo un problema de temporización. El segundo error común es la asignación de 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 aparecerá como No Aplicable. Esto confunde 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 al sitio. La forma correcta de hacer esto 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 registro. Cuarto: disponibilidad de 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 CRL no está disponible - ya sea porque un servidor está caído o porque la URL ha cambiado - la autenticación fallará para todos los dispositivos de la red simultáneamente. Eso significa una interrupción en todo el campus. Haga que sus endpoints de CRL sean de alta disponibilidad y pruebe la revocación antes de entrar en producción. Para redes grandes - cualquier cosa por encima de 500 dispositivos - considere un gateway SCEP en la nube en lugar de NDES local. Los gateways en la nube eliminan el punto único de falla de NDES, se 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 manejar dispositivos BYOD que no están registrados en el MDM? No directamente. SCEP requiere el registro en el MDM para enviar la carga de datos del certificado. Para BYOD no gestionados, necesita un enfoque diferente - ya sea un portal de incorporación de autoservicio o un SSID independiente que use un Captive Portal con verificación de identidad. La plataforma de Purple maneja esa capa de invitados y BYOD de manera limpia, coexistiendo junto con la red de su personal autenticada por certificados. ¿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 por 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 - Root de confianza, luego perfil SCEP y finalmente perfil WiFi - es fija. La segmentació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 docente y administrativo, junto con una capa de WiFi para invitados independiente para los estudiantes en sus dispositivos personales, le brinda seguridad y una excelente experiencia de usuario sin compromisos. Si desea profundizar más, la guía de Purple sobre la autenticación WiFi empresarial sin Active Directory o sin un servidor local cubre el camino nativo de la nube. Y si está pensando en qué sucede cuando un empleado se va, nuestra guía sobre cómo revocar el acceso a WiFi describe todo el flujo de trabajo de revocación. Gracias por escuchar. Soy del equipo técnico de Purple, y nos vemos en la próxima sesión informativa. - FIN DEL GUION