Acceso seguro de invitados: Implementación de NAC para dispositivos no gestionados

Acceso seguro de invitados: Implementación de NAC para dispositivos no gestionados. Un informe de inteligencia de Purple WiFi. Introducción y contexto. Bienvenido. Si es responsable de la seguridad de la red en un hotel, una cadena de tiendas, un estadio o un espacio del sector público, se enfrenta a un problema que cada vez es más difícil: ¿cómo ofrecer a los invitados, visitantes y contratistas un acceso rápido y cómodo a la WiFi, sin abrir una puerta de acceso a su infraestructura corporativa? Eso es exactamente lo que vamos a abordar hoy. Esto no es una descripción teórica. Vamos a cubrir la arquitectura, las decisiones de despliegue, los requisitos de cumplimiento y los escenarios del mundo real donde esto funciona bien, y donde falla. El desafío principal es este: los dispositivos no gestionados. Sus invitados se conectan con smartphones personales, ordenadores portátiles, tabletas y, cada vez más, dispositivos IoT; ninguno de los cuales usted controla, ninguno tiene instalado su agente MDM y todos representan un riesgo potencial de seguridad si no se segmentan y autentican correctamente. El control de acceso a la red, o NAC, es el marco que resuelve esto. Entremos en materia. Análisis técnico detallado. En primer lugar, seamos precisos sobre qué es realmente el NAC. El control de acceso a la red es un marco de seguridad que aplica un acceso basado en políticas a los recursos de la red. Evalúa quién se conecta, qué dispositivo está utilizando y si ese dispositivo cumple con los requisitos de seguridad establecidos, antes de conceder el acceso. Para los dispositivos de invitados no gestionados, la comprobación del estado de seguridad es necesariamente ligera, pero los componentes de identidad y segmentación son fundamentales. La arquitectura se divide en tres capas funcionales. La primera es la capa de autenticación. Para los dispositivos corporativos gestionados, normalmente se utilizaría IEEE 802.1X con EAP-TLS, donde los certificados se envían a través de SCEP mediante su MDM. Pero para los dispositivos de invitados no gestionados, 802.1X no es viable: los invitados no tienen certificados y usted no puede enviárselos. Por lo tanto, la capa de autenticación para invitados se basa en un Captive Portal: una página de autenticación web que intercepta la solicitud HTTP o HTTPS inicial y redirige al usuario a un flujo de inicio de sesión o registro. Aquí es donde operan plataformas como la solución Guest WiFi de Purple, capturando la identidad a través de inicio de sesión social, correo electrónico, verificación por SMS o registro mediante formulario, y pasando esa identidad al motor de políticas de NAC. La segunda capa es el motor de políticas. Aquí es donde se toman las decisiones de acceso. El sistema NAC evalúa la identidad autenticada frente a sus políticas de acceso y asigna el dispositivo al segmento de red adecuado. Para un invitado, eso suele significar una VLAN de invitados dedicada con acceso exclusivo a Internet y sin ruta hacia sus subredes corporativas. Para un contratista con un dispositivo conocido, podría asignarle una VLAN restringida con acceso a recursos internos específicos. El motor de políticas también puede aplicar un acceso basado en el tiempo: un delegado de una conferencia obtiene acceso durante la duración del evento, un huésped de un hotel obtiene acceso durante la duración de su estancia. La tercera capa es la aplicación. Esto se gestiona en el extremo de la red: sus puntos de acceso inalámbricos, switches y firewall. El sistema NAC se comunica con estos dispositivos a través de RADIUS, que es el protocolo Remote Authentication Dial-In User Service. Cuando un invitado se autentica, el servidor RADIUS devuelve un mensaje Access-Accept con atributos de asignación de VLAN, y el punto de acceso coloca el dispositivo en la VLAN correcta. Si la autenticación falla, el servidor RADIUS devuelve Access-Reject y el dispositivo permanece en una VLAN de cuarentena previa a la autenticación con acceso únicamente al Captive Portal. Ahora, hablemos de WPA3. Si está desplegando o actualizando su infraestructura inalámbrica, WPA3 debería estar en su hoja de ruta. WPA3-SAE, que significa Simultaneous Authentication of Equals, sustituye a WPA2-PSK y elimina la vulnerabilidad a los ataques de diccionario sin conexión. Específicamente para redes de invitados, WPA3-OWE (Opportunistic Wireless Encryption) es especialmente relevante. OWE proporciona cifrado sin necesidad de contraseña, lo que significa que los invitados obtienen una conexión cifrada sin ninguna fricción adicional. Esto supone una mejora significativa con respecto al SSID de invitado abierto tradicional, que transmite los datos en texto claro. El cumplimiento normativo no es negociable en la mayoría de los sectores de los que hablamos. Si gestiona un hotel con un sistema de punto de venta, la norma PCI DSS exige una segmentación estricta de la red entre los entornos de datos de los titulares de tarjetas y las redes de invitados. El requisito es explícito: el WiFi de invitados debe estar en un segmento de red independiente sin ruta al alcance de PCI. El NAC aplica esto en la capa de red y su política de firewall lo aplica en el perímetro. El GDPR añade otra dimensión: si recopila datos de identidad de invitados a través de su Captive Portal, necesita un consentimiento explícito, una base jurídica para el tratamiento y una política de retención de datos. La plataforma de Purple gestiona la captura de consentimiento conforme al GDPR de forma nativa, con periodos de retención configurables e historiales de auditoría. Abordemos también la aleatorización de direcciones MAC, ya que es un verdadero dolor de cabeza operativo. Desde iOS 14, Android 10 y Windows 10, los dispositivos aleatorizan su dirección MAC por SSID de forma predeterminada. Esto rompe cualquier política de NAC que dependa de la dirección MAC como identificador persistente. La respuesta correcta es trasladar su modelo de identidad al usuario autenticado, no a la MAC del dispositivo. Cuando un invitado se autentica a través de su Captive Portal, usted vincula su sesión a su identidad autenticada (correo electrónico, número de teléfono o perfil social) en lugar de a su dirección MAC. La plataforma de analítica de Purple gestiona esto correctamente, manteniendo la identidad a nivel de usuario en todas las sesiones, incluso cuando la dirección MAC cambia. Para las organizaciones que necesitan una evaluación de la postura del dispositivo más sólida para dispositivos no gestionados, existen enfoques con y sin agente. La evaluación de la postura sin agente utiliza técnicas como la identificación del sistema operativo (OS fingerprinting), el escaneo de puertos abiertos y el análisis del user-agent HTTP para clasificar los dispositivos y evaluar el cumplimiento básico. Esto es adecuado para redes de invitados en las que se desea identificar el tipo de dispositivo con fines analíticos o aplicar políticas diferenciadas; por ejemplo, bloquear el acceso de dispositivos IoT conocidos a determinados servicios. La evaluación de la postura basada en agentes requiere que el usuario instale un agente temporal, lo cual es adecuado para escenarios de acceso de contratistas o socios, pero genera fricción para los invitados ocasionales. Recomendaciones de implementación y errores comunes. Permítame guiarle a través de la secuencia de despliegue que funciona en la práctica. Comience con la segmentación de la red antes de tocar la configuración del NAC. Defina sus VLAN: una VLAN de preautenticación con acceso únicamente al Captive Portal y DNS, una VLAN de invitados con acceso a internet y sin rutas internas, y opcionalmente una VLAN de contratistas con acceso interno restringido. Configure los ACL de su firewall. Esta es la base; todo lo demás se construye sobre ella. En segundo lugar, despliegue su infraestructura RADIUS. Para la mayoría de los despliegues del mercado medio, un servicio RADIUS alojado en la nube e integrado con su plataforma de Captive Portal es la opción correcta. Elimina la sobrecarga operativa de gestionar servidores RADIUS locales y proporciona la redundancia que necesita para una red de invitados en producción. Asegúrese de que los secretos compartidos de RADIUS sean robustos y se roten con regularidad. En tercer lugar, configure su Captive Portal. El portal debe ser accesible desde la VLAN de preautenticación, lo que significa que la resolución DNS para el dominio del portal debe funcionar antes de la autenticación. Configure su rango DHCP en la VLAN de preautenticación para que apunte a un servidor DNS que resuelva el dominio del portal. Pruebe esto con cuidado: la configuración incorrecta de DNS es la causa más común de fallos en el Captive Portal. En cuarto lugar, pruebe la asignación de VLAN de extremo a extremo. Conecte un dispositivo de prueba, complete el flujo de autenticación y verifique que el dispositivo se ubique en la VLAN correcta con la política de acceso adecuada. Utilice una captura de paquetes para confirmar que los atributos RADIUS se están transmitiendo correctamente. Compruebe que la VLAN de invitados no tenga ruta hacia sus subredes corporativas: ejecute un traceroute desde la VLAN de invitados a una IP corporativa y confirme que falla. Ahora, los errores comunes. El fallo más habitual es una configuración incorrecta del túnel dividido (split-tunnel), donde la VLAN de invitados tiene una ruta no deseada hacia los recursos internos debido a una regla de firewall mal configurada o a una ACL ausente. Audite sus reglas de firewall antes de la puesta en marcha. El segundo fallo común es la gestión de los tiempos de espera (timeout) de RADIUS: si su servidor RADIUS no está accesible, ¿qué ocurre? Asegúrese de que sus puntos de acceso estén configurados para fallar en modo cerrado (fail-closed), no en modo abierto (fail-open). El modo fail-open significa que los invitados obtienen acceso a la red incluso si RADIUS está caído, lo que representa un riesgo de seguridad. El modo fail-closed significa que no hay acceso si RADIUS no está accesible, lo cual es la postura correcta para un despliegue seguro. El tercer error común es la expiración del certificado en su Captive Portal. Si el certificado TLS de su portal expira, los invitados verán una advertencia de seguridad en el navegador y su tasa de autenticación caerá casi a cero. Automatice la renovación de certificados con Let's Encrypt o con su plataforma de gestión de certificados. Preguntas y respuestas rápidas. ¿Necesito 802.1X para las redes de invitados? No. 802.1X es adecuado para dispositivos corporativos gestionados. Para invitados no gestionados, un Captive Portal con asignación de VLAN basada en RADIUS es la arquitectura correcta. ¿Puedo usar un único SSID tanto para invitados como para dispositivos corporativos? Técnicamente sí, utilizando la asignación dinámica de VLAN basada en el resultado de la autenticación. Pero, a nivel operativo, los SSID independientes son más sencillos de gestionar y más fáciles de auditar. Manténgalos separados. ¿Cómo gestiono los dispositivos IoT que no pueden completar el flujo de un Captive Portal? Utilice la omisión de autenticación basada en MAC, o MAB, para dispositivos IoT conocidos con direcciones MAC previamente registradas. Para dispositivos IoT desconocidos, colóquelos en una VLAN de cuarentena y revíselos manualmente. ¿Cuál es el tiempo de espera de sesión adecuado para el acceso de invitados? Para el sector hotelero, alinéelo con la duración de la estancia del huésped. Para el sector retail, lo habitual son de dos a cuatro horas. Para eventos, alinéelo con el horario del evento. Establezca siempre un tiempo de espera por inactividad: 30 minutos de inactividad es un valor predeterminado razonable. ¿Debo registrar el tráfico de los invitados? Sí, por motivos legales y de cumplimiento. Conserve los registros de conexión (IP de origen, marca de tiempo, identidad autenticada) durante un mínimo de 90 días, o más si la legislación de su jurisdicción lo requiere. La plataforma de Purple proporciona este registro de auditoría de forma nativa. Resumen y próximos pasos. En resumen: el acceso seguro de invitados para dispositivos no gestionados es un problema resuelto, pero requiere una arquitectura deliberada. Los tres pilares son la identidad (quién se conecta), la segmentación (a dónde pueden ir) y la aplicación (cómo se garantiza que se cumpla la política). El NAC une todo esto, con RADIUS como protocolo de comunicación entre su plataforma de autenticación y su infraestructura de red. Para sus próximos pasos: si aún no lo ha hecho, audite la segmentación actual de su red de invitados. Confirme que no existen rutas desde su VLAN de invitados hacia sus subredes corporativas. Revise el flujo de consentimiento de GDPR de su Captive Portal y la configuración de retención de datos. Y si utiliza WPA2 con un SSID de invitados abierto, incluya WPA3-OWE en su hoja de ruta de actualización de infraestructura. La plataforma de Purple se integra directamente con esta arquitectura, proporcionando el Captive Portal, la captura de identidad, la capa de cumplimiento de GDPR y las analíticas que se ejecutan sobre su infraestructura NAC. Si desea ver cómo se adapta esto al entorno específico de su establecimiento, el equipo de Purple puede guiarle a través de una arquitectura de referencia para su caso de uso. Gracias por su atención. Esto ha sido un informe de inteligencia de Purple WiFi sobre Acceso Seguro de Invitados: Implementación de NAC para Dispositivos No Gestionados.