Implementación de la autenticación 802.1X en dispositivos móviles

GUION DE PODCAST: Implementación de la autenticación 802.1X en dispositivos móviles Duración: ~10 minutos | Voz: Inglés británico, masculino, tono de consultor sénior Estructura: Introducción y contexto (1 min) → Inmersión técnica profunda (5 min) → Recomendaciones de implementación y errores comunes (2 min) → Preguntas y respuestas rápidas (1 min) → Resumen y próximos pasos (1 min) --- [INTRODUCCIÓN Y CONTEXTO — ~1 minuto] Bienvenidos de nuevo. Hoy vamos a profundizar en algo que surge constantemente en los proyectos de WiFi empresariales: la autenticación 802.1X en dispositivos móviles. Si gestiona la red de un hotel, un complejo comercial, un estadio o cualquier espacio del sector público donde el personal y los invitados se conectan con iPhones y dispositivos Android, este es el estándar que debe comprender de forma adecuada. El estándar 802.1X no es nuevo. Ha sido la columna vertebral de la seguridad inalámbrica empresarial durante más de dos décadas. Pero los dispositivos móviles han cambiado considerablemente el panorama de la implementación. La gestión de certificados, la selección del método EAP, los flujos de trabajo de aprovisionamiento de MDM... estas son todas áreas donde los proyectos suelen fallar, y donde hacerlo bien ofrece una mejora operativa y de seguridad muy significativa. Así que repasemos la arquitectura, los pasos de implementación tanto para Apple como para Android, y los fallos comunes que cuestan a los equipos semanas de resolución de problemas. --- [INMERSIÓN TÉCNICA PROFUNDA — ~5 minutos] Empecemos con los aspectos fundamentales. IEEE 802.1X es un estándar de control de acceso a redes basado en puertos. Define tres roles: el suplicante (que es su dispositivo móvil), el autenticador (que suele ser su punto de acceso inalámbrico o controlador de LAN inalámbrica) y el servidor de autenticación (casi siempre un servidor RADIUS). Cuando un dispositivo intenta conectarse a un SSID protegido por 802.1X, el punto de acceso no concede acceso completo a la red de inmediato. En su lugar, abre un puerto controlado e inicia un intercambio EAP (el protocolo de autenticación extensible). El dispositivo presenta las credenciales, el punto de acceso las transmite al servidor RADIUS y este acepta o rechaza la conexión. Solo tras la aceptación, el punto de acceso abre el puerto no controlado y permite el tráfico de red completo. Ahora bien, el método EAP que elija es fundamental, y aquí es donde los despliegues móviles difieren de las redes empresariales tradicionales centradas en ordenadores portátiles. EAP-TLS es el estándar de oro. Utiliza una autenticación mutua basada en certificados: tanto el servidor como el cliente presentan certificados. No hay nombre de usuario ni contraseña en el intercambio. Es resistente al phishing de credenciales, a los ataques de intermediario (man-in-the-middle) y a la fuerza bruta. Tanto iOS como Android lo admiten de forma nativa. El desafío es la gestión del ciclo de vida de los certificados: necesita una PKI que funcione y necesita introducir los certificados de cliente en los dispositivos, lo que significa que el uso de un MDM es esencialmente obligatorio. PEAP con MSCHAPv2 es el método más implantado en la práctica. Envuelve MSCHAPv2 dentro de un túnel TLS, por lo que las credenciales quedan protegidas en tránsito. Tanto iOS como Android lo soportan de forma nativa. La desventaja es que depende de un nombre de usuario y una contraseña, lo que introduce una sobrecarga en la gestión de credenciales y un riesgo de exposición si el certificado del servidor no se valida correctamente en el lado del cliente. EAP-TTLS con PAP es común en entornos con directorios LDAP heredados. Android lo soporta de forma nativa; iOS requiere un perfil de configuración. Vale la pena señalar que PAP transmite la contraseña en texto plano dentro del túnel TLS, por lo que la integridad del túnel lo es todo aquí. EAP-FAST es principalmente una solución de Cisco. iOS lo soporta de forma nativa; el soporte de Android es inconsistente entre los diferentes fabricantes y versiones del sistema operativo. Para la mayoría de los despliegues móviles empresariales actuales, la recomendación es EAP-TLS donde se tenga cobertura MDM, y PEAP-MSCHAPv2 donde no se tenga, aplicando siempre una validación estricta del certificado del servidor. Ahora hablemos de la parte de la infraestructura. El servidor RADIUS es el núcleo del despliegue. Microsoft NPS, FreeRADIUS, Cisco ISE y Aruba ClearPass son las principales opciones. Para despliegues nativos en la nube, JumpCloud, Foxpass y Portnox ofrecen RADIUS-as-a-Service, lo que elimina la carga de gestionar la infraestructura local. Su servidor RADIUS debe estar configurado con el método EAP correcto, el secreto compartido para cada punto de acceso o WLC, y el almacén de usuarios, ya sea Active Directory, LDAP o una base de datos local. Para EAP-TLS, también necesita la cadena de certificados de la CA para validar los certificados de los clientes. Por el lado de la autoridad de certificación, dispone de tres opciones. Una PKI interna utilizando Microsoft ADCS o una CA independiente le ofrece un control total y cero costes de certificados, pero requiere madurez operativa para su gestión. Un servicio PKI en la nube (SCEPman, Smallstep o similar) se integra bien con las plataformas MDM modernas y reduce significativamente la carga operativa. Los certificados públicos de una CA comercial rara vez se utilizan para la autenticación de clientes debido al coste y la complejidad. Ahora, la configuración de los dispositivos. En iOS, la vía de despliegue más limpia es Apple Configurator o una plataforma MDM como Jamf, Microsoft Intune o Mosyle. Se envía un perfil de configuración WiFi que especifica el SSID, el método EAP, el certificado del servidor en el que confiar y, para EAP-TLS, el certificado del cliente. El perfil se encarga de todo de forma silenciosa. Los usuarios se conectan sin necesidad de realizar pasos manuales. La configuración manual en iOS es posible pero inestable. Los usuarios deben ir a Ajustes, WiFi, tocar el SSID, introducir las credenciales y, a continuación, se les muestra una solicitud de confianza del certificado. Si el certificado del servidor no procede de una CA de confianza, iOS muestra una advertencia. Los usuarios suelen pulsar "Confiar" sin leerlo, lo que anula por completo el propósito de la validación del certificado. Por este motivo, el aprovisionamiento mediante MDM no es opcional en despliegues profesionales. En Android, la situación está más fragmentada. Android 11 y versiones posteriores requieren que se especifique un certificado CA al conectarse a una red 802.1X; ya no es posible seleccionar "No validar" en las versiones modernas de Android sin que aparezca una advertencia. Este es un cambio de seguridad positivo, pero significa que debe distribuir su certificado CA a los dispositivos Android, ya sea a través de un MDM - Android Enterprise con Intune o VMware Workspace ONE - o instalándolo manualmente desde el almacenamiento del dispositivo. Android también presenta peculiaridades según el fabricante. Los dispositivos Samsung con One UI gestionan los certificados de forma ligeramente diferente a Android de fábrica. Algunos dispositivos Huawei más antiguos presentan problemas de compatibilidad de EAP-TLS con conjuntos de cifrado específicos. Realizar pruebas en todo el abanico de dispositivos de destino antes del despliegue es indispensable. Para la infraestructura inalámbrica, sus puntos de acceso o WLC deben configurarse con el SSID establecido en WPA2-Enterprise o WPA3-Enterprise, la IP del servidor RADIUS y el secreto compartido, y - fundamentalmente - el registro de actividad (accounting) de RADIUS si desea tener visibilidad de la sesión por usuario. WPA3-Enterprise con modo de 192 bits es la mejor práctica actual para entornos de alta seguridad, y combina a la perfección con EAP-TLS. Si aún no está planeando su migración a WPA3, vale la pena leer junto con esta guía el manual sobre la implementación de WPA3-Enterprise para mejorar la seguridad inalámbrica. --- [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - ~2 minutos] Permítame detallar las tres situaciones que con mayor frecuencia desbaratan los despliegues móviles 802.1X. Primero: fallos de confianza en los certificados. Este es el principal generador de incidencias de soporte. En iOS, si el certificado del servidor RADIUS no está incluido en la lista de certificados de confianza del perfil WiFi, los usuarios verán una advertencia de confianza en la primera conexión. En Android, si el certificado CA no está instalado, las versiones modernas rechazarán la conexión o mostrarán una advertencia persistente. La solución consiste en incluir siempre la cadena completa de certificados - CA raíz y cualquier CA intermedia - en sus perfiles MDM. No dependa del almacén de confianza del sistema del dispositivo para su CA interna. Segundo: tiempo de espera y latencia de RADIUS. Los dispositivos móviles no esperan. Si su servidor RADIUS tarda más de dos o tres segundos en responder, tanto iOS como Android volverán a intentarlo y finalmente fallará la conexión. Esto es especialmente crítico en entornos de alta densidad - estadios, centros de conferencias - donde cientos de dispositivos se autentican simultáneamente. Asegúrese de que su infraestructura RADIUS esté dimensionada adecuadamente, considere el despliegue de servidores proxy RADIUS a nivel regional y ajuste los parámetros de reintento y tiempo de espera en el WLC. Tercero: discrepancia en el método EAP. Esto parece obvio, pero es sorprendentemente común. El método EAP configurado en el WLC debe coincidir con el que anuncia el servidor RADIUS, el cual debe coincidir a su vez con el que especifica el perfil del cliente. Una discrepancia da como resultado un fallo de autenticación silencioso con un registro de diagnóstico mínimo. Valide siempre la negociación EAP completa mediante una captura de paquetes en el servidor RADIUS durante las pruebas iniciales. En lo que respecta al MDM, la recomendación práctica es utilizar la autenticación basada en certificados para los dispositivos propiedad de la empresa y PEAP para los escenarios de BYOD en los que no se puedan distribuir certificados de cliente. Esto le proporciona las ventajas de seguridad de EAP-TLS donde más importa, sin la sobrecarga de gestión de certificados que supone el largo historial de dispositivos personales. - [PREGUNTAS Y RESPUESTAS RÁPIDAS - ~1 minuto] ¿Puedo ejecutar 802.1X y un SSID de invitados en la misma infraestructura? Por supuesto. Ejecute SSIDs independientes: uno con WPA2/3-Enterprise para 802.1X y otro para el acceso de invitados con un Captive Portal. La segmentación de VLAN mantiene el tráfico aislado. ¿Necesito un servidor RADIUS local? Ya no. Los servicios de RADIUS en la nube son maduros y fiables. Para los establecimientos con una conectividad a Internet poco fiable, sigue valiendo la pena considerar una instancia de RADIUS local como alternativa de respaldo. ¿Qué pasa con los dispositivos IoT que no son compatibles con 802.1X? Utilice la derivación de autenticación MAC - MAB - para esos dispositivos y colóquelos en una VLAN restringida con reglas de cortafuegos. No permita que accedan al mismo segmento que sus dispositivos autenticados mediante 802.1X. ¿Es suficiente 802.1X para cumplir con PCI-DSS? Es un control sólido, pero PCI-DSS requiere un enfoque por capas. El estándar 802.1X aborda el control de acceso a la red; de todos modos seguirá necesitando cifrado, supervisión y segmentación para cumplir con todos los requisitos. - [RESUMEN Y PRÓXIMOS PASOS - ~1 minuto] En resumen: la autenticación 802.1X en dispositivos móviles es un estándar maduro y consolidado que ofrece una mejora de la seguridad muy significativa en comparación con las redes de claves precompartidas. La complejidad de la implementación es real, pero resulta manejable con las herramientas adecuadas; concretamente, un MDM para la distribución de perfiles y un servidor RADIUS en la nube o local con el dimensionamiento adecuado. Sus próximos pasos inmediatos: audite su infraestructura WiFi actual para comprobar su compatibilidad con WPA2-Enterprise, evalúe la cobertura de su MDM en todo el parque de dispositivos y decida su método EAP en función de si dispone de capacidad PKI. Si empieza desde cero, PEAP-MSCHAPv2 con integración de Active Directory es el camino más rápido para una implementación funcional. Si dispone de MDM y PKI, vaya directamente a EAP-TLS. Para profundizar más en el tema, la guía de implementación de WPA3-Enterprise y los recursos de Purple sobre arquitectura WiFi corporativa son excelentes opciones para continuar. Gracias por escucharnos. Nos vemos en la próxima entrega. - FIN DEL GUION