Secure Guest Access: Implementación de NAC para dispositivos no gestionados

SecurePass: 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 cada vez más complejo: ¿cómo ofrecer a los huéspedes, visitantes y contratistas un acceso rápido y cómodo a la WiFi sin abrir una puerta de entrada a su infraestructura corporativa? Eso es exactamente lo que vamos a analizar hoy. No se trata de una perspectiva teórica. Vamos a cubrir la arquitectura, las decisiones de despliegue, los requisitos de cumplimiento y los escenarios del mundo real en los que esto funciona correctamente y donde surgen los problemas. El principal reto es este: los dispositivos no gestionados. Sus clientes se conectan con smartphones, portátiles y tablets personales, y cada vez más con dispositivos IoT, ninguno de los cuales está bajo su control, 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 de trabajo que resuelve esto. Comencemos. Inmersión técnica profunda. En primer lugar, definamos con precisión qué es realmente un 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 utiliza y si ese dispositivo cumple con los requisitos de seguridad de su entorno 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, lo habitual sería utilizar 802.1X con EAP-TLS, donde los certificados se envían mediante SCEP a través de su MDM. Sin embargo, para los dispositivos de invitados no gestionados, el protocolo 802.1X no es práctico: los invitados no tienen certificados y usted no puede enviárselos. Por lo tanto, la capa de autenticación para los invitados se basa en un Captive Portal: una página de autenticación web que intercepta la solicitud inicial HTTP o HTTPS y redirige al usuario a un flujo de inicio de sesión o registro. Aquí es donde operan plataformas como la solución de Guest WiFi de Purple, capturando la identidad mediante inicio de sesión social, correo electrónico, verificación por SMS o registro basado en formularios, y enviando 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, esto 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, se le podría asignar a 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 asistente a una conferencia obtiene acceso durante la duración del evento, un cliente de un hotel obtiene acceso durante la duración de su estancia. La tercera capa es la de aplicación de políticas. Esto se gestiona en el extremo de la red: sus puntos de acceso inalámbricos, switches y cortafuegos. 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 renovando 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 fricción adicional. Esto supone una mejora significativa con respecto al SSID de invitados abierto tradicional, que transmite 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, 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 cortafuegos 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 períodos de retención y pistas de auditoría configurables. 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 análisis 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 más sólida del estado de seguridad de los dispositivos no gestionados, existen enfoques basados y no basados en agentes. La evaluación del estado de seguridad sin agentes utiliza técnicas como la identificación del sistema operativo (OS fingerprinting), el escaneo de puertos abiertos y el análisis del agente de usuario HTTP para clasificar los dispositivos y evaluar el cumplimiento normativo básico. Esto es adecuado para redes de invitados donde se desea identificar el tipo de dispositivo para fines analíticos o aplicar políticas diferenciadas — por ejemplo, bloquear el acceso de dispositivos IoT conocidos a ciertos servicios. La evaluación del estado de seguridad 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 autenticación previa con acceso únicamente al Captive Portal y al 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 de mercado medio, un servicio RADIUS alojado en la nube e integrado con su plataforma de Captive Portal es la decisión correcta. Elimina la sobrecarga operativa de gestionar servidores RADIUS locales y proporciona la redundancia que necesita para una red de invitados de producción. Asegúrese de que sus secretos compartidos de RADIUS sean robustos y se roten periódicamente. Tercero, configure su Captive Portal. El portal debe ser accesible desde la VLAN de autenticación previa — 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 autenticación previa para que apunte a un servidor DNS que resuelva el dominio del portal. Pruebe esto con cuidado — la configuración incorrecta del DNS es la causa más común de fallos en el Captive Portal. Cuarto, pruebe su 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 de RADIUS se están transmitiendo correctamente. Compruebe que la VLAN de invitados no tiene ruta hacia sus subredes corporativas — ejecute un traceroute desde la VLAN de invitados a una IP corporativa y confirme que falla. Ahora, los problemas comunes. El modo de fallo más frecuente es la configuración incorrecta del split-tunneling - donde la VLAN de invitados tiene una ruta no deseada a los recursos internos debido a una regla de firewall mal configurada o a una ACL inexistente. Audite sus reglas de firewall antes de la puesta en marcha. El segundo fallo común es la gestión de tiempos de espera 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 no funciona, lo cual es 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 problema 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. El protocolo 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 utilizar 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 operativamente, los SSIDs 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 un flujo de Captive Portal? Utilice el bypass de autenticación basado 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 de la hostelería, ajústelo a la duración de la estancia del huésped. Para el sector de retail, lo habitual son de dos a cuatro horas. Para eventos, ajústelo al horario del evento. Establezca siempre un tiempo de espera por inactividad - 30 minutos de inactividad es un valor por defecto razonable. ¿Debo registrar el tráfico de los invitados? Sí, por motivos legales y de cumplimiento normativo. 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 siguientes 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 (adónde pueden ir) y la aplicación (cómo se garantiza que se cumpla la política). El control de acceso a la red (NAC) une estos elementos, con RADIUS como protocolo de comunicación entre su plataforma de autenticación y su infraestructura de red. Para sus siguientes 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 y la configuración de retención de datos de su Captive Portal. 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 la 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 escucharnos. Esto ha sido un informe de inteligencia de Purple WiFi sobre acceso seguro para invitados: implementación de NAC para dispositivos no gestionados.