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) --- Bienvenido al informe de inteligencia de Purple WiFi. Soy su anfitrión, y hoy entraremos en detalle sobre la autenticación 802.1X con Cloud RADIUS: qué es, por qué es importante en este momento y cómo implementarla realmente en un entorno de múltiples sedes. Si administra la infraestructura WiFi de un grupo hotelero, una cadena minorista, un estadio o una organización del sector público, este es uno de esos temas que surge constantemente, y con justa razón. El panorama de amenazas ha cambiado. Las redes PSK compartidas se consideran cada vez más como una responsabilidad de cumplimiento, no solo como un inconveniente de seguridad. Los reguladores, auditores y aseguradoras de riesgos cibernéticos hacen preguntas cada vez más difíciles sobre el control de acceso a la red. Y la buena noticia es que RADIUS entregado desde la nube ha hecho que 802.1X sea realmente viable de implementar a escala, sin la carga de infraestructura local que solía hacerlo poco práctico para entornos distribuidos. Así que entremos en materia. --- ANÁLISIS TÉCNICO DETALLADO (aprox. 5 minutos) --- Primero, 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 ubica en la Capa 2 del modelo OSI, por lo que opera antes de que se conceda cualquier conectividad IP al dispositivo. Esa es la diferencia clave con la autenticación en la capa de aplicación. Con 802.1X, un dispositivo no puede entrar a la red hasta que haya sido autenticado positivamente. El protocolo consta de tres componentes. El suplicante: ese es el dispositivo final, ya sea una laptop, un smartphone o una terminal de punto de venta. El autenticador: normalmente su punto de acceso WiFi o su switch administrado. Y el servidor de autenticación: que en las implementaciones modernas es su servicio Cloud RADIUS. El flujo funciona así. 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 transmite ese intercambio al servidor RADIUS utilizando el protocolo RADIUS sobre UDP, normalmente en el puerto 1812 para autenticación y 1813 para 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 de 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 principio, pero los detalles de la implementación importan enormemente. Ahora bien, la selección del método EAP es donde fallan muchas implementaciones. Existen varios métodos EAP de uso común, y tienen perfiles de seguridad y requisitos operativos muy diferentes. EAP-TLS es el estándar de oro. Requiere autenticación mutua de certificados: tanto el servidor como el cliente presentan un certificado. Esto elimina por completo el riesgo de robo de credenciales, porque no hay contraseñas que robar. Pero requiere una infraestructura de 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 e implementaciones de alta seguridad, esta es la respuesta correcta. PEAP con MSCHAPv2 es el método más implementado en entornos empresariales. Solo requiere un certificado del lado del servidor y canaliza el intercambio de credenciales dentro de TLS. Es compatible con Active Directory de forma nativa, lo que lo hace operativamente sencillo. El riesgo es que es 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 no es negociable. EAP-TTLS es similar a PEAP pero más flexible en el método de autenticación interno. Es particularmente útil en entornos de dispositivos mixtos donde se tiene una combinación de dispositivos Windows, macOS, iOS y Android con diferentes capacidades de suplicante. Para el soporte de dispositivos heredados (piense en hardware de punto de venta más antiguo o sensores IoT), EAP-FAST puede ser una opción pragmática, ya que no requiere certificados y utiliza una credencial de acceso protegido en su lugar. Ahora, la pieza de Cloud RADIUS. Tradicionalmente, RADIUS era un servicio local: FreeRADIUS en un servidor Linux o Microsoft NPS en Windows Server. Ese modelo funciona, pero tiene costos operativos reales: mantenimiento de hardware, configuración de alta disponibilidad, parches y la necesidad de infraestructura local en cada sitio que requiera autenticación de baja latencia. Cloud RADIUS cambia esa ecuación significativamente. Un servicio Cloud RADIUS es alojado y administrado 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 modernos de Cloud RADIUS están distribuidos globalmente y los viajes de ida y vuelta de autenticación normalmente se completan en menos de 100 milisegundos, lo que es imperceptible para los usuarios finales. La integración con los proveedores de identidad es la dependencia crítica. La mayoría de las plataformas Cloud RADIUS admiten LDAP, LDAPS, SAML 2.0 e integración directa con Azure AD o Okta. Para las organizaciones que ya ejecutan Microsoft 365, la integración con Azure AD es el camino natural: obtiene inicio de sesión único, directivas de acceso condicional y aplicación de MFA, todo alimentando su capa de control de acceso a la red. Para los establecimientos que implementan WiFi para invitados junto con redes para el personal, la arquitectura normalmente los separa en SSID distintos con diferentes directivas 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. El plataforma de Purple admite ambos modelos, y la capa de análisis de WiFi abarca ambos, brindándole 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 darle la secuencia práctica de implementación y señalar los modos de falla 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 Cloud RADIUS pueda autenticarse contra su directorio. Pruebe con una cuenta de servicio, valide la vinculación LDAP y confirme que los atributos de pertenencia a grupos se devuelvan correctamente, porque los necesitará para las directivas 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 implementación 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 se suele omitir y que causa 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 nombre de host del servidor correctos. Utilice un secreto compartido sólido y generado aleatoriamente, no una palabra de diccionario. Y si su proveedor de Cloud RADIUS admite RADIUS sobre TLS (RadSec), utilícelo. Cifra el tráfico RADIUS en tránsito, lo cual es particularmente importante cuando ese tráfico viaja por la internet pública. En cuarto lugar, realice pruebas con un grupo piloto antes de la implementación completa. Las fallas de autenticación a escala son disruptivas 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 funcione y verifique que los registros de contabilidad se escriban correctamente. Los modos de falla que veo con más frecuencia: validación de certificados desactivada en los clientes, lo que genera vulnerabilidad de intermediario. Secretos compartidos demasiado cortos o reutilizados en varios sitios. Lista de IP 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 fallas masivas de autenticación el día de la renovación. --- PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto) --- Algunas preguntas que me hacen con frecuencia. ¿Puedo ejecutar 802.1X en una red que también tiene dispositivos IoT que no admiten EAP? Sí, utilice la omisión de autenticación MAC como respaldo para los dispositivos que no pueden ejecutar un suplicante, pero coloque esos dispositivos en una VLAN restringida con reglas de firewall estrictas. ¿802.1X reemplaza el cifrado WPA2 o WPA3? No, 802.1X se encarga de la autenticación. WPA2-Enterprise o WPA3-Enterprise se encarga del cifrado. Necesita ambos. WPA3-Enterprise con 802.1X es la mejor práctica actual para nuevas implementaciones. ¿Cuál es el impacto de la latencia en la autenticación? Con un servicio Cloud RADIUS bien configurado, espere entre 50 y 150 milisegundos por autenticación. Para escenarios de roaming, la transición rápida de BSS 802.11r puede reducir significativamente la carga de reautenticación. ¿Esto cumple 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) --- Para resumir: 802.1X con Cloud RADIUS es la respuesta correcta para cualquier organización que necesite demostrar el control de acceso a la red ante los auditores, reducir el radio de impacto de una credencial comprometida o administrar la autenticación de forma centralizada en un entorno distribuido. La implementación no es trivial, pero es absolutamente manejable con la preparación adecuada. Primero asegure la integración de su proveedor de identidad. Elija su método EAP en función de su flota de dispositivos y su capacidad operativa para administrar certificados. Utilice RadSec si su infraestructura lo admite. Y realice pruebas antes de implementar a gran escala. Si opera una red mixta de invitados y personal (como la mayoría de los operadores de hotelería y comercio minorista), las plataformas como Purple le brindan la capacidad de administrar ambos modelos de autenticación desde un solo panel de control, con la capa de análisis abarcando todo el entorno. Para sus próximos pasos: audite su postura actual de control de acceso a la red, identifique qué sitios siguen ejecutando PSK compartidas y cree un plan de migración por fases. Comience con sus sitios de mayor riesgo (aquellos dentro del alcance de PCI DSS o que manejan datos confidenciales) y continúe hacia afuera. Gracias por escuchar. Hay más informes técnicos disponibles en purple.ai.