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 importante en este momento y cómo implementarla de forma real en un patrimonio multisitio. Si gestiona la infraestructura WiFi de un grupo hotelero, una cadena de tiendas, un estadio o una organización del sector público, este es uno de esos temas recurrentes, y con razón. El panorama de las amenazas ha cambiado. Las redes PSK compartidas se consideran cada vez más un riesgo de cumplimiento normativo, no solo un inconveniente de seguridad. Reguladores, auditores y aseguradoras cibernéticas plantean preguntas cada vez más difíciles sobre el control de acceso a la red. Y la buena noticia es que el servicio RADIUS suministrado en la nube ha hecho que la tecnología 802.1X sea realmente implementable a gran escala, sin los costes de infraestructura local que antes la hacían inviable para patrimonios distribuidos. Comencemos. --- 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 cualquier tipo de conectividad IP a un dispositivo. Esa es la diferencia clave respecto a la autenticación en la capa de aplicación. Con la tecnología 802.1X, un dispositivo no puede acceder a la red hasta que se haya autenticado positivamente. El protocolo consta de tres componentes. El suplicante, que es el dispositivo final (ya sea un portátil, un smartphone o un terminal de punto de venta). El autenticador, que suele ser su punto de acceso WiFi o su 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 completo 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 pueden ser un nombre de usuario y una 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 a través de UDP, normalmente en el puerto 1812 para la autenticación y en el 1813 para la contabilidad (accounting). El servidor RADIUS valida las credenciales con respecto a 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. Es sencillo en teoría, pero los detalles de la implementación son de enorme importancia. Ahora bien, la selección del método EAP es el punto donde fallan muchas implementaciones. Se utilizan habitualmente varios métodos EAP, los cuales 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 enviar 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 adecuada. PEAP con MSCHAPv2 es el método más extendido 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 las operaciones. El riesgo es que resulta vulnerable a la obtenció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 de certificados 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. Resulta especialmente útil en entornos con dispositivos mixtos en los que se dispone de una combinación de dispositivos Windows, macOS, iOS y Android con distintas capacidades de suplicante. Para ofrecer soporte a dispositivos antiguos - como hardware de punto de venta antiguo o sensores IoT -, EAP-FAST puede ser una opción práctica, ya que no requiere certificados y utiliza en su lugar una credencial de acceso protegido (PAC). Ahora, hablemos de la parte 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 una infraestructura local en cada sitio que requiera autenticación de baja latencia. El servicio RADIUS en la nube cambia significativamente ese cálculo. Un servicio RADIUS en la nube es 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 frente a 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 tiempos de ida y vuelta de la 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 son compatibles con LDAP, LDAPS, SAML 2.0 y la integración directa con Azure AD u 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 conectado a 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 SSID distintos con diferentes políticas de autenticación. Las redes de 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 es compatible con ambos modelos, y la capa de WiFi analytics abarca 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 de despliegue práctica y señalar los fallos 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 de RADIUS en la nube puede autenticarse contra su directorio. Realice una prueba 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 va a 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 enviar 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 correcto y la IP o nombre de host del servidor. Utilice un secreto compartido seguro, generado de forma aleatoria, 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 ese 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 fallos que veo con más frecuencia: validación de certificados desactivada en los clientes, lo que genera vulnerabilidad a ataques de intermediario (man-in-the-middle). Secretos compartidos demasiado cortos o reutilizados en varios sitios. La lista de permitidos de IP del servidor RADIUS no está configurada, por lo que las solicitudes de autenticación de nuevos sitios se descartan silenciosamente. Y los perfiles de MDM no se actualizan cuando los certificados caducan, 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 gestiona la autenticación. WPA2-Enterprise o WPA3-Enterprise gestionan el 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, cabe esperar 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 reautenticación. ¿Cumple esto con PCI-DSS? 802.1X con EAP-TLS o PEAP en una red adecuadamente 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) - Para resumir: 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 un compromiso de credenciales o gestionar la autenticación de forma centralizada en un entorno distribuido. El despliegue no es trivial, pero es absolutamente manejable con la preparación adecuada. Asegúrese de que la integración con su proveedor de identidad sea correcta en primer lugar. Elija su método EAP en función de su parque de dispositivos y su capacidad operativa para gestionar certificados. Utilice RadSec si su infraestructura lo admite. Y realice pruebas antes de un despliegue a gran escala. Si gestiona una red mixta de invitados y personal (como la mayoría de los operadores de hostelería y retail), las plataformas como Purple le ofrecen la capacidad de gestionar ambos modelos de autenticación desde un único panel, con la capa de análisis abarcando todo el entorno. Para sus próximos pasos: audite su situación actual en materia de control de acceso a la red, identifique qué sedes siguen utilizando PSK compartido y elabore un plan de migración por fases. Empiece por las sedes de mayor riesgo (aquellas que entran en el alcance de PCI-DSS o que manejan datos sensibles) y continúe hacia el resto. Gracias por su atención. Encontrará más sesiones técnicas en purple.ai.