Cómo implementar la autenticación 802.1X con Cloud RADIUS

Cómo implementar la autenticación 802.1X con Cloud RADIUS Un informe de inteligencia de Purple WiFi --- INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto) --- Le damos la bienvenida al informe de inteligencia de Purple WiFi. Soy su anfitrión, y hoy vamos a analizar en detalle la autenticación 802.1X con Cloud RADIUS: qué es, por qué es tan importante en este momento y cómo implementarla de forma efectiva en un entorno multisitio. Si gestiona la infraestructura de WiFi para un grupo hotelero, una cadena de tiendas, un estadio o una organización del sector público, este es uno de esos temas que no deja de surgir, y con razón. El panorama de las amenazas ha cambiado. Las redes con PSK compartida se consideran cada vez más un riesgo de cumplimiento normativo, y no solo un inconveniente de seguridad. Los reguladores, los auditores y las aseguradoras de ciberriesgos plantean preguntas cada vez más complejas sobre el control de acceso a la red. Y la buena noticia es que RADIUS en la nube ha hecho que 802.1X sea realmente viable de implementar a escala, sin la sobrecarga de infraestructura local que antes lo hacía inviable para entornos distribuidos. Así que entremos en materia. --- ANÁLISIS TÉCNICO DETALLADO (aprox. 5 minutos) --- En primer lugar, asegurémonos de que todos partimos de la misma definición. IEEE 802.1X es un estándar de control de acceso a la red basado en puertos. Define un marco de autenticación que se sitúa en la capa 2 del modelo OSI, por lo que opera antes de que se conceda a un dispositivo cualquier tipo de conectividad IP. Esa es la diferencia clave con respecto a la autenticación en la capa de aplicación. Con 802.1X, un dispositivo no puede acceder a la red hasta que se haya autenticado positivamente. El protocolo consta de tres componentes. El suplicante (el dispositivo final, ya sea un ordenador portátil, un smartphone o un terminal de punto de venta). El autenticador (normalmente el punto de acceso WiFi o el switch gestionado). Y el servidor de autenticación (que en las implementaciones modernas es su servicio Cloud RADIUS). El flujo funciona de la siguiente manera. Un dispositivo intenta asociarse con un punto de acceso. El punto de acceso no concede acceso total a la red de inmediato. En su lugar, abre un puerto controlado e inicia un intercambio EAP (el protocolo de autenticación extensible) con el dispositivo. El dispositivo presenta sus credenciales, que podrían ser un nombre de usuario y contraseña, un certificado digital o una identidad basada en SIM. El punto de acceso retransmite ese intercambio al servidor RADIUS utilizando el protocolo RADIUS sobre UDP, normalmente en el puerto 1812 para la autenticación y 1813 para la contabilidad. El servidor RADIUS valida las credenciales contra un almacén de identidades (Active Directory, Azure AD o un directorio LDAP) y devuelve un mensaje Access-Accept o Access-Reject. Si se acepta, el punto de acceso abre el puerto y el dispositivo obtiene acceso a la red. Si se rechaza, permanece bloqueado. Sencillo en teoría, pero los detalles de la implementación importan enormemente. Ahora bien, la selección del método EAP es donde fallan muchas implementaciones. Se utilizan habitualmente varios métodos EAP, y presentan perfiles de seguridad y requisitos operativos muy diferentes. EAP-TLS es el estándar de oro. Requiere autenticación mutua por certificado: tanto el servidor como el cliente presentan un certificado. Esto elimina por completo el riesgo de robo de credenciales, ya que no hay contraseñas que robar. Sin embargo, requiere una infraestructura PKI y un mecanismo para distribuir los certificados de cliente a los dispositivos, lo que normalmente implica una solución MDM. Para entornos corporativos BYOD y despliegues de alta seguridad, esta es la respuesta correcta. PEAP con MSCHAPv2 es el método más implantado en entornos empresariales. Solo requiere un certificado en el lado del servidor y canaliza el intercambio de credenciales dentro de TLS. Es compatible de forma nativa con Active Directory, lo que simplifica enormemente su gestión operativa. El riesgo es que resulta vulnerable a la recopilación de credenciales si los usuarios se conectan a un punto de acceso no autorizado con un certificado autofirmado, por lo que la validación del certificado en el lado del cliente es innegociable. EAP-TTLS es similar a PEAP pero más flexible en el método de autenticación interno. Es especialmente útil en entornos con dispositivos mixtos donde convive una combinación de equipos Windows, macOS, iOS y Android con diferentes capacidades de suplicante. Para el soporte de dispositivos heredados (como terminales de punto de venta antiguos o sensores IoT), EAP-FAST puede ser una opción pragmática, ya que no requiere certificados y utiliza en su lugar una credencial de acceso protegido (PAC). Ahora, hablemos de la pieza de RADIUS en la nube. Tradicionalmente, RADIUS era un servicio local: FreeRADIUS en un servidor Linux o Microsoft NPS en Windows Server. Ese modelo funciona, pero conlleva costes operativos reales: mantenimiento de hardware, configuración de alta disponibilidad, parches y la necesidad de infraestructura local en cada ubicación que requiera autenticación de baja latencia. El RADIUS en la nube cambia esa ecuación significativamente. Un servicio RADIUS en la nube está alojado y gestionado por el proveedor. Sus puntos de acceso envían solicitudes RADIUS a través de internet al servicio en la nube, que se encarga de la autenticación contra su proveedor de identidad. La preocupación por la latencia es real pero manejable: los servicios RADIUS en la nube modernos están distribuidos globalmente y los viajes de ida y vuelta de autenticación suelen completarse en menos de 100 milisegundos, lo que resulta imperceptible para los usuarios finales. La integración con los proveedores de identidad es la dependencia crítica. La mayoría de las plataformas RADIUS en la nube admiten LDAP, LDAPS, SAML 2.0 e integración directa con Azure AD o Okta. Para las organizaciones que ya utilizan Microsoft 365, la integración con Azure AD es el camino natural: se obtiene inicio de sesión único, políticas de acceso condicional y aplicación de MFA, todo ello integrado en su capa de control de acceso a la red. Para los establecimientos que despliegan WiFi para invitados junto con redes para el personal, la arquitectura suele separar estas en SSIDs distintos con diferentes políticas de autenticación. Las redes del personal utilizan 802.1X con credenciales corporativas. Las redes de invitados utilizan un Captive Portal o un flujo de inicio de sesión social. La plataforma de Purple admite ambos modelos, y la capa de analítica de WiFi se sitúa en ambos, lo que le ofrece visibilidad sobre el comportamiento de los dispositivos, el tiempo de permanencia y la utilización de la red sin comprometer la segmentación de seguridad. --- RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aprox. 2 minutos) --- Permítame detallar la secuencia práctica de despliegue y señalar los modos de fallo que veo con más frecuencia. Comience con la integración de su proveedor de identidad. Antes de tocar un solo punto de acceso, confirme que su servicio RADIUS en la nube puede autenticarse contra su directorio. Realice pruebas con una cuenta de servicio, valide la vinculación LDAP y confirme que los atributos de pertenencia a grupos se devuelven correctamente, ya que los necesitará para las políticas de asignación de VLAN. En segundo lugar, planifique su estrategia de certificados. Si opta por EAP-TLS, necesita una CA, debe decidir si utilizará una CA pública o una interna, y necesita un plan de despliegue de MDM para los certificados de cliente. Si opta por PEAP, necesita un certificado de servidor de una CA de confianza (no autofirmado) y debe distribuir el certificado de la CA a todos los dispositivos cliente para que la validación del certificado funcione correctamente. Este es el paso que suele omitirse y que provoca incidentes de seguridad. En tercer lugar, configure sus clientes RADIUS (es decir, sus puntos de acceso y controladores) con el secreto compartido y la IP o el nombre de host del servidor correctos. Utilice un secreto compartido fuerte y generado aleatoriamente, no una palabra de diccionario. Y si su proveedor de RADIUS en la nube admite RADIUS sobre TLS (RadSec), utilícelo. Cifra el tráfico RADIUS en tránsito, lo cual es especialmente importante cuando dicho tráfico atraviesa la internet pública. En cuarto lugar, realice pruebas con un grupo piloto antes del despliegue completo. Los fallos de autenticación a gran escala son perjudiciales y difíciles de diagnosticar bajo presión. Realice un piloto con diez a veinte dispositivos, valide los registros de autenticación, confirme que la asignación de VLAN funciona y compruebe que los registros de contabilidad se escriben correctamente. Los modos de fallo que veo con más frecuencia son: validación de certificados desactivada en los clientes, lo que genera vulnerabilidad de tipo "man-in-the-middle"; secretos compartidos demasiado cortos o reutilizados en varios sitios; lista de IPs permitidas del servidor RADIUS no configurada, por lo que las solicitudes de autenticación de nuevos sitios se descartan silenciosamente; y perfiles de MDM que no se actualizan cuando caducan los certificados, lo que provoca fallos masivos de autenticación el día de la renovación. --- PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto) --- Algunas preguntas que me hacen con regularidad. ¿Puedo ejecutar 802.1X en una red que también tiene dispositivos IoT que no admiten EAP? Sí, utilice MAC Authentication Bypass como alternativa para los dispositivos que no pueden ejecutar un suplicante, pero coloque esos dispositivos en una VLAN restringida con reglas de firewall estrictas. ¿Reemplaza 802.1X al cifrado WPA2 o WPA3? No, 802.1X se encarga de la autenticación. WPA2-Enterprise o WPA3-Enterprise se encargan del cifrado. Necesita ambos. WPA3-Enterprise con 802.1X es la mejor práctica actual para nuevos despliegues. ¿Cuál es el impacto de la latencia en la autenticación? Con un servicio RADIUS en la nube bien configurado, prevea entre 50 y 150 milisegundos por autenticación. Para escenarios de itinerancia (roaming), la transición rápida de BSS 802.11r puede reducir significativamente la sobrecarga de la reautenticación. ¿Cumple esto con PCI DSS? 802.1X con EAP-TLS o PEAP en una red correctamente segmentada cumple con el Requisito 1 y el Requisito 8 de PCI DSS para el control de acceso a la red. Involucre a su QSA desde el principio. --- RESUMEN Y PRÓXIMOS PASOS (aprox. 1 minuto) --- En resumen: 802.1X con RADIUS en la nube es la respuesta adecuada para cualquier organización que necesite demostrar el control de acceso a la red ante los auditores, reducir el radio de impacto de una filtración de credenciales o gestionar la autenticación de forma centralizada en un entorno distribuido. El despliegue no es trivial, pero es totalmente manejable con la preparación adecuada. En primer lugar, asegúrese de que la integración con su proveedor de identidad sea correcta. Elija su método EAP en función de su parque de dispositivos y de su capacidad operativa para gestionar certificados. Utilice RadSec si su infraestructura lo admite. Y realice pruebas antes de implementarlo a gran escala. Si gestiona una red mixta de invitados y personal (como ocurre en la mayoría de los operadores de hostelería y comercio minorista), plataformas como Purple le ofrecen la capacidad de gestionar ambos modelos de autenticación desde un único panel de control, con la capa analítica aplicada a todo el entorno. Para sus próximos pasos: audite su estado actual de control de acceso a la red, identifique qué ubicaciones siguen utilizando PSK compartida y elabore un plan de migración por fases. Comience con los centros de mayor riesgo (aquellos que entran en el ámbito de PCI DSS o que manejan datos confidenciales) y avance hacia el resto. Gracias por su atención. En purple.ai dispone de más sesiones informativas técnicas.