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

Acceso seguro para invitados: Implementación de NAC para dispositivos no administrados. Un informe de inteligencia de Purple WiFi. Introducción y contexto. Bienvenido. Si eres responsable de la seguridad de la red en un hotel, cadena de retail, estadio o recinto del sector público, te estás enfrentando 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 WiFi, sin abrir una puerta de entrada a tu infraestructura corporativa? Eso es exactamente lo que vamos a abordar hoy. Esto no es un análisis teórico. Vamos a cubrir la arquitectura, las decisiones de implementación, los requisitos de cumplimiento y los escenarios del mundo real donde esto funciona bien, y donde sale mal. El desafío principal es este: los dispositivos no administrados. Tus invitados se conectan con smartphones personales, laptops, tablets y, cada vez más, con dispositivos IoT; ninguno de los cuales controlas, ninguno tiene instalado tu agente de MDM y todos representan un riesgo potencial de seguridad si no se segmentan y autentican correctamente. Network Access Control, o NAC, es el marco de trabajo que resuelve esto. Entremos en materia. Análisis técnico detallado. Primero, seamos precisos sobre qué es realmente NAC. Network Access Control es un marco de seguridad que aplica un acceso basado en políticas a los recursos de la red. Evalúa quién se está conectando, qué dispositivo está utilizando y si ese dispositivo cumple con tus requisitos de postura de seguridad, antes de conceder el acceso. Para los dispositivos de invitados no administrados, la verificación de la postura es necesariamente ligera, pero los componentes de identidad y segmentación son críticos. La arquitectura se divide en tres capas funcionales. La primera es la capa de autenticación. Para los dispositivos corporativos administrados, normalmente usarías IEEE 802.1X con EAP-TLS, donde los certificados se envían a través de SCEP mediante tu MDM. Pero para los dispositivos de invitados no administrados, 802.1X no es práctico: los invitados no tienen certificados y tú no puedes enviárselos. Por lo tanto, la capa de autenticación para invitados depende de un Captive Portal: una página de autenticación basada en 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 las 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 basado en formularios, 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 tus políticas de acceso y asigna el dispositivo al segmento de red adecuado. Para un invitado, eso normalmente significa una VLAN de invitados dedicada con acceso exclusivo a Internet y sin ruta hacia tus subredes corporativas. Para un contratista con un dispositivo conocido, podrías asignarlo 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 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ámbrico, 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 al 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á implementando o actualizando su infraestructura inalámbrica, WPA3 debería estar en su hoja de ruta. WPA3-SAE, que significa Simultaneous Authentication of Equals, reemplaza a WPA2-PSK y elimina la vulnerabilidad a los ataques de diccionario fuera de línea. Específicamente para redes de invitados, WPA3-OWE (Opportunistic Wireless Encryption) es particularmente relevante. OWE proporciona cifrado sin requerir una contraseña, lo que significa que los invitados obtienen una conexión cifrada sin ninguna fricción adicional. Esto representa una mejora significativa con respecto al SSID de invitado abierto tradicional, que transmite datos en texto claro. El cumplimiento no es negociable en la mayoría de los sectores verticales de los que estamos hablando. Si administra un hotel con un sistema de punto de venta, PCI DSS exige una segmentación de red estricta 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 los invitados a través de su Captive Portal, necesita un consentimiento explícito, una base legal para el procesamiento y una política de retención de datos. La plataforma de Purple maneja la captura de consentimiento que cumple con el GDPR de forma nativa, con periodos de retención configurables y registros 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 un 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 maneja 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 postura de dispositivos más sólida para dispositivos no administrados, existen enfoques con y sin agente. La evaluación de 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 de HTTP para clasificar los dispositivos y evaluar el cumplimiento básico. Esto es adecuado para redes de invitados donde 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 ciertos servicios. La evaluación de 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 implementación 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 DNS, una VLAN de invitados con acceso a internet y sin rutas internas, y opcionalmente una VLAN de contratistas con acceso interno restringido. Configure sus ACL de firewall. Esta es la base; todo lo demás se construye sobre ella. En segundo lugar, implemente su infraestructura RADIUS. Para la mayoría de las implementaciones del 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 administrar 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 sólidos y se roten con regularidad. En tercer lugar, configure su Captive Portal. El portal debe ser accesible desde la VLAN de autenticación previa, lo que significa que la resolución de DNS para el dominio del portal debe funcionar antes de la autenticación. Configure su alcance 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 de DNS es la causa más común de fallas en el Captive Portal. En cuarto lugar, 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 llegue a 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. Verifique 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 falle. Ahora, los errores comunes. El modo de falla más habitual es la configuración incorrecta de 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 faltante. Audite sus reglas de firewall antes de la puesta en marcha. El segundo error común es el manejo de tiempo de espera (timeout) de RADIUS: si su servidor RADIUS no está disponible, ¿qué sucede? 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 abierto significa que los invitados obtienen acceso a la red incluso si RADIUS está caído, lo cual es un riesgo de seguridad. El modo cerrado significa que no hay acceso si RADIUS no está disponible, lo cual es la postura correcta para un despliegue seguro. El tercer error común es el vencimiento 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 redes de invitados? No. 802.1X es adecuado para dispositivos corporativos administrados. Para invitados no administrados, un Captive Portal con asignación de VLAN basada en RADIUS es la arquitectura correcta. ¿Puedo usar un solo 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 SSID separados son más sencillos de administrar y más fáciles de auditar. Manténgalos separados. ¿Cómo manejo 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 de hospitalidad, alinéelo con la duración de la estadía del huésped. Para el sector de retail, lo habitual es de dos a cuatro horas. Para eventos, alinéelo con el programa 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 historial de auditoría de forma nativa. Resumen y siguientes pasos. En resumen: el acceso seguro de invitados para dispositivos no administrados 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). NAC une estos elementos, con RADIUS como el 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 existan 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 está utilizando WPA2 con un SSID de invitados abierto, incluya WPA3-OWE en su plan 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 la analítica 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 guiarlo a través de una arquitectura de referencia para su caso de uso. Gracias por escucharnos. Esto ha sido un Purple WiFi Intelligence Briefing sobre Acceso Seguro para Invitados: Implementación de NAC para Dispositivos No Administrados.