Saltar al contenido principal

Seguridad en el trabajo híbrido: combinación de NAC con ZTNA para un acceso sin interrupciones

Esta guía técnica de referencia aborda la convergencia arquitectónica de Network Access Control (NAC) y Zero Trust Network Access (ZTNA) para proteger los entornos de trabajo híbridos en sedes corporativas, comerciales, de hostelería y del sector público. Proporciona un plan de despliegue por fases, casos de estudio reales y directrices de cumplimiento para arquitectos de TI y CTO que necesiten eliminar las brechas de seguridad creadas por dominios de acceso locales y en la nube aislados.

📖 6 min de lectura📝 1,285 palabras🔧 2 ejemplos prácticos3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast
Le damos la bienvenida a Purple Enterprise Architecture Briefing. Soy su anfitrión y hoy vamos a profundizar en un desafío crítico para los líderes de TI: proteger a la fuerza de trabajo híbrida. En concreto, analizaremos la convergencia arquitectónica de Network Access Control (o NAC) y Zero Trust Network Access (o ZTNA). Si gestiona redes complejas en recintos corporativos, espacios comerciales o entornos del sector público, esto le interesa. Pongámonos en contexto. El perímetro tradicional ha muerto. Todos lo sabemos. Proteger una sede corporativa con un NAC sólido mientras se depende de VPN heredadas para el acceso remoto ya no es suficiente. Genera fricción para el usuario y puntos ciegos para el departamento de TI. Las empresas modernas necesitan un estado de seguridad unificado que conecte a la perfección la infraestructura local con las aplicaciones nativas de la nube. Ahí es donde entra en juego la combinación de NAC y ZTNA. Históricamente, estos eran dominios aislados. NAC, utilizando estándares como 802.1X, era excelente para controlar el acceso físico e inalámbrico dentro del edificio. Comprobaba el estado de seguridad de los dispositivos y asignaba VLAN. ZTNA, por otro lado, se creó para la era de la nube: protegía el acceso remoto en función de la identidad y el contexto, no de la ubicación de la red. El problema surge cuando un trabajador híbrido se desplaza entre estos dominios. Se autentica sin problemas en casa a través de ZTNA, pero se topa con un muro de políticas inconexas cuando entra en la oficina. Es frustrante, ineficiente y, francamente, crea brechas de seguridad que los atacantes pueden aprovechar. Hablemos, pues, de la arquitectura técnica. La solución es una capa unificada de intermediación de identidad y contexto. Necesitamos sincronizar la telemetría entre los motores de políticas de NAC y ZTNA. Piense en ello como una evaluación continua del estado de seguridad que acompaña al usuario, esté donde esté. Así es como funciona en la práctica. Cuando un dispositivo se conecta a la red corporativa, NAC realiza una comprobación exhaustiva de su estado de seguridad: versión del sistema operativo, estado del antivirus, validación de certificados. Comparte este contexto inmediatamente con el agente ZTNA a través de la integración de la API. Si el estado del dispositivo se degrada (por ejemplo, si se detecta malware), NAC lo pone en cuarentena en la red local e indica simultáneamente al agente ZTNA que revoque el acceso a las aplicaciones críticas en la nube. A medida que el usuario se desplaza de la oficina a una ubicación remota, el cliente ZTNA mantiene ese contexto de confianza establecido. Sin necesidad de volver a autenticarse. La experiencia es fluida, pero la seguridad es continua. Ahora, entremos en los estándares que sustentan esto. IEEE 802.1X es el estándar de oro para la autenticación local. Proporciona una validación criptográfica de la identidad del dispositivo a nivel de puerto. RADIUS actúa como protocolo de backend, comunicando la solución NAC con su proveedor de identidad. En el lado de ZTNA, nos encontramos con proveedores de identidad como Azure Active Directory u Okta, con agentes ZTNA de los principales proveedores. La clave es garantizar que estos sistemas puedan comunicarse de forma bidireccional. Para los operadores de recintos (hoteles, centros de conferencias, estadios), existe una capa adicional de complejidad. Gestionan personal corporativo, contratistas, invitados y una flota creciente de dispositivos IoT, todo en la misma infraestructura física. NAC se encarga de la segmentación. El personal corporativo obtiene autenticación 802.1X y acceso a los recursos internos. Los invitados se aíslan en una red dedicada, gestionada idealmente a través de una plataforma como Guest WiFi de Purple, que proporciona un aislamiento sólido al tiempo que captura análisis valiosos. Los dispositivos IoT que no admiten 802.1X (como señalización digital, sensores ambientales, terminales de punto de venta) se gestionan mediante MAC Authentication Bypass, o MAB, con una segmentación estricta de VLAN para contener cualquier posible compromiso. Permítame guiarle a través de un escenario de despliegue real. Piense en una cadena minorista global con quinientas ubicaciones. Los directores regionales viajan constantemente entre las tiendas, la sede central y sus oficinas en casa. Experimentan desconexiones de la VPN y un acceso inestable a las aplicaciones de gestión de inventario. La solución es una arquitectura convergente de NAC y ZTNA. Cuando un director está en la tienda, NAC autentica el dispositivo a través de 802.1X y comparte el contexto interno de confianza con el agente ZTNA. A continuación, el agente concede acceso directo y optimizado a la aplicación de inventario alojada en la nube, sin necesidad de un túnel VPN. Cuando el director trabaja desde casa, el cliente ZTNA establece un microtúnel seguro con la aplicación, manteniendo las mismas políticas de acceso. ¿El resultado? Un acceso constante, menos llamadas al servicio de asistencia y un estado de seguridad notablemente mejorado. Ahora, la implementación. Recomiendo un enfoque de tres fases. La fase uno es la visibilidad. Despliegue primero NAC en modo de monitorización. Descubra y perfile todo lo que hay en su red: portátiles, dispositivos BYOD, IoT, dispositivos de invitados. No aplique ninguna restricción todavía. Al mismo tiempo, integre sus proveedores de identidad tanto con NAC como con ZTNA para consolidar las identidades de los usuarios. Utilice su solución ZTNA para mapear los patrones de acceso a las aplicaciones. Esto le proporcionará los datos necesarios para redactar políticas sensatas. La fase dos es la definición de políticas. Defina los requisitos básicos del estado de seguridad para los dispositivos corporativos. Implemente la microsegmentación de ZTNA en función de los roles de usuario y la sensibilidad de las aplicaciones. And, fundamentalmente, establezca la integración de la API entre sus plataformas NAC y ZTNA para el intercambio bidireccional de contextos. Pruebe a fondo esta integración antes de pasar a la fase de aplicación. La fase tres es la aplicación. Habilite gradualmente la aplicación de NAC, comenzando con un grupo piloto. Supervise los fallos de autenticación y ajuste las políticas. Despliegue clientes ZTNA en todos los extremos corporativos. Y extienda los principios de confianza cero a sus redes de invitados utilizando una plataforma gestionada. Permítame ofrecerle algunos consejos rápidos sobre los errores más comunes. En primer lugar, los retrasos en la sincronización del contexto. Si la integración de la API entre NAC y ZTNA experimenta latencia, un dispositivo comprometido podría mantener el acceso a las aplicaciones en la nube más tiempo de lo aceptable. La solución consiste en utilizar notificaciones push basadas en webhooks en lugar de depender de mecanismos de sondeo (polling). Esto garantiza actualizaciones de políticas casi en tiempo real. En segundo lugar, las políticas demasiado restrictivas que provocan picos de llamadas al servicio de asistencia. Implementar comprobaciones estrictas del estado de seguridad sin una comunicación adecuada con el usuario es una receta para el caos. Utilice Captive Portals para informar a los usuarios sobre el incumplimiento y ofrecer opciones de autorreparación antes de bloquear el acceso por completo. En tercer lugar, los fallos de autenticación de los dispositivos IoT. Los dispositivos IoT sin interfaz de usuario (headless) sencillamente no pueden admitir clientes 802.1X o ZTNA. La respuesta es MAC Authentication Bypass combinado con un perfilado riguroso de dispositivos y una segmentación estricta de VLAN. En cuarto lugar, y esto es muy importante: no supervisar el estado de la propia integración de la API. Si la sincronización entre NAC y ZTNA se interrumpe, tendrá una brecha de seguridad. Implemente la supervisión y las alertas sobre el estado de la integración, y defina políticas de seguridad contra fallos (fail-safe) que se activen si la sincronización se pierde durante más de un umbral definido. ¿Cuál es entonces el retorno de la inversión? El caso de negocio para esta arquitectura es convincente. Consolidar la gestión de políticas reduce la carga administrativa de los equipos de TI. Eliminar las VPN heredadas mejora significativamente la experiencia de trabajo híbrido, reduciendo el tiempo de inactividad y la frustración. Y la capacidad de demostrar una evaluación continua del estado de seguridad y un control de acceso basado en la identidad simplifica los informes de cumplimiento para marcos como PCI DSS y GDPR, especialmente relevantes en entornos comerciales y sanitarios. Para resumir los puntos clave de la sesión de hoy: la identidad es el nuevo perímetro y el contexto es la clave. Utilice NAC para el cable y ZTNA para la aplicación. No confíe nunca, verifique siempre... y hágalo continuamente. Implemente por fases: primero visibilidad, luego políticas y después aplicación. Y no se olvide de la red de invitados y del conjunto de dispositivos IoT: deben formar parte de su arquitectura de seguridad, no ser un aspecto secundario. Si desea profundizar en el futuro de la seguridad de red impulsado por la IA, consulte la guía de Purple sobre NAC impulsado por IA y detección de amenazas. Y para quienes gestionen sitios distribuidos, nuestra guía de SD-WAN frente a MPLS merece mucho la pena. Eso es todo por hoy. Gracias por escucharnos y nos vemos en la próxima.

header_image.png

Resumen ejecutivo

Para los arquitectos de redes empresariales y los CTO que gestionan entornos distribuidos, el perímetro se ha disuelto de forma irrevocable. El modelo tradicional de proteger una sede corporativa con un control de acceso a la red (NAC) sólido mientras se depende de VPN heredadas para el acceso remoto ya no es viable. Las empresas modernas requieren un estado de seguridad unificado que conecte a la perfección la infraestructura local con las aplicaciones nativas de la nube. Esta guía detalla la integración arquitectónica de NAC y Zero Trust Network Access (ZTNA), proporcionando un plan para proteger los entornos de trabajo híbridos sin comprometer la experiencia del usuario ni el rendimiento de la red.

Al combinar la aplicación del estado de seguridad a nivel de dispositivo de NAC con la microsegmentación centrada en la identidad de ZTNA, las organizaciones pueden lograr una verificación de confianza continua independientemente de la ubicación del usuario. Esta convergencia es especialmente crítica para sectores con gran afluencia de público y requisitos de cumplimiento complejos, como el Comercio minorista , la Sanidad y la Hostelería . Además, el aprovechamiento de plataformas como la infraestructura de Guest WiFi de Purple puede extender estos principios de confianza cero a las redes de invitados, garantizando un aislamiento sólido y una protección de datos alineada con las obligaciones de GDPR y PCI DSS.

Análisis técnico profundo: la arquitectura de convergencia

Las limitaciones de los dominios de seguridad aislados

Históricamente, NAC y ZTNA funcionaban como dominios de seguridad aislados. NAC, aprovechando IEEE 802.1X y RADIUS, destacaba en el control del acceso físico e inalámbrico dentro del perímetro corporativo. Proporcionaba un sólido perfilado de dispositivos, evaluación del estado de seguridad y asignación de VLAN. Por el contrario, ZTNA surgió para proteger el acceso remoto a aplicaciones locales y en la nube, operando bajo el principio de "no confiar nunca, verificar siempre" basado en la identidad y el contexto del usuario, en lugar de en la ubicación de la red.

La fricción surge cuando los trabajadores híbridos realizan la transición entre estos dominios. Un usuario que se autentica sin problemas a través de ZTNA en casa a menudo se enfrenta a una experiencia inconexa al entrar en la oficina corporativa, donde las políticas de NAC pueden no alinearse con su contexto de ZTNA. Esta fragmentación introduce puntos ciegos de seguridad y costes operativos que afectan directamente tanto a la eficiencia de TI como a la productividad del usuario final.

Intermediación unificada de identidad y contexto

La solución arquitectónica radica en establecer una capa unificada de intermediación de identidad y contexto que sincronice la telemetría entre los motores de políticas de NAC y ZTNA. Esta integración permite una evaluación continua del estado de seguridad que persiste a través de los límites de la red.

nac_ztna_architecture_overview.png

La integración funciona a través de tres mecanismos clave. En primer lugar, la evaluación continua del estado de seguridad: cuando un dispositivo se conecta a la red corporativa, la solución NAC realiza una comprobación exhaustiva de su estado que abarca la versión del sistema operativo, el estado del antivirus y la validación de certificados. Este contexto se comparte inmediatamente con el agente ZTNA a través de la integración de la API. En segundo lugar, la aplicación dinámica de políticas: si el estado del dispositivo se degrada (por ejemplo, si se detecta malware), el sistema NAC pone el dispositivo en cuarentena en la red local, al tiempo que indica al agente ZTNA que revoque el acceso a las aplicaciones críticas en la nube. En tercer lugar, la transición sin interrupciones: a medida que el usuario se desplaza de la oficina a una ubicación remota, el cliente ZTNA mantiene el contexto de confianza establecido, eliminando la necesidad de volver a autenticarse y garantizando un acceso ininterrumpido a los recursos autorizados.

Para comprender mejor las tecnologías inalámbricas subyacentes que admiten estos despliegues, consulte nuestra guía sobre Frecuencias de Wi-Fi: una guía sobre las frecuencias de Wi-Fi en 2026 .

hybrid_work_security_comparison.png

Guía de implementación: despliegue paso a paso

El despliegue de una arquitectura convergente de NAC/ZTNA requiere un enfoque por fases para minimizar las interrupciones y garantizar una aplicación sólida de las políticas.

Fase 1: Descubrimiento de identidades y activos

Antes de implementar políticas de aplicación, debe lograr una visibilidad completa de su entorno de red. Despliegue su solución NAC en modo de solo monitorización: configúrela para descubrir y perfilar todos los dispositivos conectados, incluidos portátiles corporativos, BYOD, IoT y dispositivos de invitados, sin bloquear el acceso. Consolide las identidades de los usuarios integrando las soluciones NAC y ZTNA con un proveedor de identidad central como Azure AD u Okta. Esto garantiza políticas de autenticación coherentes en ambos dominios. Al mismo tiempo, utilice su solución ZTNA para supervisar los patrones de acceso a las aplicaciones, identificando qué usuarios requieren acceso a aplicaciones específicas y sentando las bases para sus políticas de microsegmentación.

Fase 2: Definición de políticas y microsegmentación

Pase de la visibilidad al control definiendo políticas de acceso granulares basadas en el principio de mínimo privilegio. Establezca requisitos de seguridad básicos para los dispositivos corporativos, incluidos la versión mínima del sistema operativo y los requisitos del agente EDR activo, y configure la solución NAC para aplicar estos requisitos para el acceso local. Defina políticas de ZTNA que restrinjan el acceso a las aplicaciones en función del rol del usuario y del contexto del dispositivo, garantizando la alineación con los requisitos de estado de seguridad definidos en la solución NAC. Fundamentalmente, configure la integración de la API entre sus plataformas NAC y ZTNA para permitir el intercambio bidireccional de contextos, garantizando que un cambio en el estado del dispositivo detectado por NAC imdesencadena inmediatamente una actualización de políticas en el broker ZTNA.

Fase 3: Aplicación y optimización

Habilite gradualmente el modo de aplicación, supervisando las anomalías y perfeccionando las políticas según sea necesario. Transicione la solución NAC del modo de monitorización al modo de aplicación, comenzando con un grupo piloto de usuarios o ubicaciones, y supervise los fallos de autenticación. Implemente el cliente ZTNA en todos los endpoints corporativos, garantizando un acceso fluido a las aplicaciones en la nube y locales. Amplíe las políticas robustas de acceso de invitados utilizando plataformas como Guest WiFi de Purple, garantizando que el tráfico de invitados esté estrictamente aislado de los recursos corporativos. Aproveche WiFi Analytics para supervisar los patrones de uso y detectar posibles anomalías en todo el entorno de invitados.

Buenas prácticas para entornos empresariales

Prioritise la experiencia del usuario durante toda la implementación. La seguridad no debe impedir la productividad, y la transición entre el acceso local y el remoto debe ser transparente para el usuario, aprovechando el inicio de sesión único (single sign-on) y los mecanismos de autenticación continua. Para el acceso local, exija la autenticación IEEE 802.1X para todos los dispositivos corporativos, ya que esto proporciona una validación criptográfica robusta de la identidad del dispositivo a nivel de puerto.

Integre capacidades de detección de amenazas impulsadas por IA en sus soluciones NAC y ZTNA para identificar comportamientos anómalos y poner en cuarentena automáticamente los dispositivos comprometidos. Para obtener una perspectiva de futuro sobre esta capacidad, consulte The Future of Wi-Fi Security: AI-Driven NAC and Threat Detection y su equivalente en español El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas . Para empresas distribuidas, la integración de ZTNA con SD-WAN puede optimizar el enrutamiento de aplicaciones y mejorar el rendimiento en múltiples ubicaciones; revise nuestra comparación en SD WAN vs MPLS: The 2026 Enterprise Network Guide .

Resolución de problemas y mitigación de riesgos

Los retrasos en la sincronización de contexto representan el modo de fallo más crítico. Si la integración de la API entre NAC y ZTNA experimenta latencia, un dispositivo comprometido podría mantener el acceso a las aplicaciones en la nube más tiempo de lo aceptable. La mitigación consiste en implementar notificaciones push basadas en webhooks en lugar de depender únicamente de mecanismos de sondeo (polling), lo que garantiza actualizaciones de políticas casi en tiempo real.

Las políticas excesivamente restrictivas pueden causar picos significativos de tickets de soporte técnico al implementar comprobaciones de estado estrictas sin una comunicación adecuada con el usuario. Utilice Captive Portals para informar a los usuarios sobre el incumplimiento y proporcionar instrucciones de remediación de autoservicio antes de bloquear el acceso por completo.

Los fallos de autenticación de dispositivos IoT son inevitables en entornos de recintos. Los dispositivos IoT sin interfaz de usuario (headless) no pueden admitir clientes 802.1X o ZTNA. La solución es el bypass de autenticación MAC (MAB) combinado con un perfilado riguroso de dispositivos y una segmentación estricta de VLAN para aislar el tráfico de IoT de los recursos corporativos.

La monitorización del estado de la integración de la API se pasa por alto con frecuencia. Si la sincronización entre NAC y ZTNA se interrumpe, existe una brecha de seguridad que ninguno de los sistemas puede resolver de forma independiente. Implemente una monitorización y alertas dedicadas sobre el estado de la integración, y defina políticas de seguridad contra fallos que activen restricciones de acceso automáticas si se pierde la sincronización durante más de un umbral definido.

ROI e impacto empresarial

La convergencia de NAC y ZTNA ofrece un valor empresarial medible más allá de la mitigación de riesgos. La consolidación de la gestión de políticas reduce la carga administrativa de los equipos de TI, lo que les permite centrarse en iniciativas estratégicas en lugar de gestionar silos de seguridad dispares. La eliminación de las VPN heredadas mejora significativamente la experiencia de trabajo híbrido, reduciendo el tiempo de inactividad y la frustración, al tiempo que mejora el rendimiento de las aplicaciones para los usuarios remotos.

La capacidad de demostrar una evaluación continua del estado de seguridad y un control de acceso basado en la identidad simplifica los informes de cumplimiento para marcos como PCI DSS y GDPR, especialmente relevantes en entornos de Transporte y comercio minorista (retail), donde las obligaciones de protección de datos personales y de titulares de tarjetas son estrictas. Las organizaciones que han implementado arquitecturas convergentes informan sistemáticamente de una reducción en el tiempo medio de contención (MTTC) de incidentes de seguridad, ya que la aplicación bidirecional de políticas permite la cuarentena automatizada sin necesidad de intervención manual.

Definiciones clave

Network Access Control (NAC)

Una solución de seguridad que aplica políticas a los dispositivos que solicitan acceso a una infraestructura de red, utilizando normalmente IEEE 802.1X para la autenticación y la evaluación del estado de seguridad para determinar la asignación de VLAN y los derechos de acceso.

Fundamental para proteger los entornos locales, garantizando que solo los dispositivos autorizados y que cumplan las normativas puedan conectarse a los conmutadores corporativos y a los puntos de acceso inalámbricos. Los equipos de TI se encuentran con esto al gestionar las redes físicas de oficinas y recintos.

Zero Trust Network Access (ZTNA)

Una solución de seguridad de TI que proporciona acceso remoto seguro a aplicaciones y servicios basándose en políticas de control de acceso definidas, operando bajo el principio de mínimo privilegio y verificación continua de la identidad en lugar de la ubicación de la red.

Sustituye a las VPN heredadas al proporcionar microsegmentación basada en la identidad, concediendo acceso únicamente a aplicaciones específicas en lugar de a toda la red. Relevante a la hora de proteger a los trabajadores remotos y el acceso a las aplicaciones en la nube.

Micro-segmentation

La práctica de dividir una red en segmentos aislados para reducir la superficie de ataque y evitar el movimiento lateral de los actores de amenazas, aplicada a nivel de aplicación o de carga de trabajo en lugar de en el perímetro de la red.

ZTNA aplica este concepto a nivel de aplicación, garantizando que un extremo comprometido no pueda pivotar para acceder a recursos no autorizados. Los equipos de TI se encuentran con esto al diseñar arquitecturas de confianza cero.

Posture Assessment

El proceso de evaluar el estado de seguridad de un dispositivo (incluida la versión del sistema operativo, el antivirus activo, los certificados instalados y el nivel de parches) antes de conceder acceso a la red o a las aplicaciones.

Una función principal de NAC que garantiza que los dispositivos vulnerables o comprometidos se pongan en cuarentena o se reparen antes de que puedan interactuar con la red corporativa. Relevante durante la incorporación de dispositivos y la supervisión continua.

IEEE 802.1X

Un estándar IEEE para el control de acceso a la red basado en puertos, que proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, utilizando EAP (Extensible Authentication Protocol) a través del medio de red.

El estándar de oro para la autenticación de redes empresariales, que proporciona una validación criptográfica sólida de la identidad del dispositivo. Los equipos de TI se encuentran con esto al configurar conmutadores, controladores inalámbricos y servidores RADIUS.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA) para los usuarios que se conectan y utilizan un servicio de red, actuando como capa de comunicación entre el NAC y los proveedores de identidad.

El protocolo de backend utilizado por las soluciones NAC para comunicarse con los proveedores de identidad y aplicar las políticas de acceso. Relevante al integrar NAC con Active Directory o IdP en la nube.

MAC Authentication Bypass (MAB)

Un método de autenticación de respaldo utilizado por las soluciones NAC para dispositivos que no admiten 802.1X, que se basa en la dirección MAC del dispositivo como identificador para asignar políticas de acceso a la red.

Necesario para dar cabida a dispositivos sin interfaz de usuario (headless) —impresoras, sensores IoT, señalización digital— en entornos empresariales. Es menos seguro que 802.1X y requiere una segmentación estricta de VLAN para mitigar los riesgos de suplantación de identidad (spoofing) de MAC.

Identity Provider (IdP)

Una entidad del sistema que crea, mantiene y gestiona la información de identidad de los principales, al tiempo que proporciona servicios de autenticación a las aplicaciones dependientes dentro de una federación o red distribuida.

La fuente central de información para las identidades de los usuarios, que se integra tanto con NAC como con ZTNA para garantizar políticas de autenticación coherentes. Los equipos de TI se encuentran con esto al configurar SSO y MFA en los sistemas empresariales.

VLAN (Virtual Local Area Network)

Una subdivisión lógica de una red física que agrupa dispositivos en dominios de difusión aislados, lo que permite la segmentación del tráfico sin necesidad de una infraestructura física independiente.

El mecanismo principal para aislar diferentes clases de dispositivos (corporativos, invitados, IoT) dentro de una red física compartida. Fundamental para el cumplimiento de los requisitos de PCI DSS relativos al aislamiento del entorno de datos de los titulares de tarjetas.

Ejemplos prácticos

Una cadena minorista global con 500 ubicaciones necesita garantizar el acceso seguro de los directores regionales que viajan con frecuencia entre las tiendas, la sede corporativa y sus oficinas en casa. Actualmente sufren desconexiones frecuentes de la VPN y un acceso inestable a las aplicaciones de gestión de inventario alojadas en la nube.

Implemente una arquitectura convergente de NAC/ZTNA en todas las ubicaciones. Despliegue 802.1X a través de NAC para un acceso seguro y sin interrupciones cuando los directores se encuentren físicamente en la tienda o en la sede central, autenticándose contra un servidor RADIUS centralizado integrado con Azure AD. Despliegue un cliente ZTNA en todos los portátiles corporativos. Integre los motores de políticas de NAC y ZTNA a través de API, configurando notificaciones de webhook para actualizaciones inmediatas del estado de seguridad. Cuando un director se conecta a la red de la tienda, el NAC autentica el dispositivo y comparte el contexto de 'confianza interna' con el agente ZTNA. A continuación, el agente ZTNA concede acceso directo y optimizado a la aplicación de inventario alojada en la nube sin necesidad de un túnel VPN, lo que reduce la latencia y elimina los problemas de desconexión. Cuando el director trabaja desde casa, el cliente ZTNA establece un microtúnel seguro con la aplicación, manteniendo las mismas políticas de acceso sin depender del perímetro de la red corporativa. Los dispositivos de invitados e IoT de la tienda se aíslan en VLAN independientes gestionadas a través de la plataforma Guest WiFi de Purple.

Comentario del examinador: Este enfoque resuelve los problemas de experiencia de usuario asociados a las VPN heredadas al proporcionar un acceso fluido y adaptado al contexto, independientemente de la ubicación. La integración de la API garantiza que el estado de seguridad se evalúe continuamente, mitigando el riesgo de que un dispositivo comprometido acceda a aplicaciones críticas. La decisión arquitectónica clave es el enrutamiento de 'borde local' (local edge): cuando se está en la red corporativa, el tráfico ZTNA debe enrutarse a un agente local en lugar de pasar por un agente en la nube (hair-pinning), lo que anularía los beneficios de latencia.

Un gran centro de conferencias necesita proporcionar WiFi seguro para el personal corporativo, al tiempo que aísla miles de conexiones diarias de invitados y dispositivos IoT de proveedores externos, como señalización digital, balizas BLE y sensores ambientales.

Despliegue una solución NAC sólida configurada con una segmentación estricta de VLAN en tres niveles distintos. Nivel uno: los dispositivos del personal corporativo se autentican mediante 802.1X y se asignan a una VLAN interna segura con acceso total a los sistemas de gestión internos. Nivel dos: implemente la plataforma Guest WiFi de Purple para gestionar el acceso público, capturando análisis valiosos y garantizando al mismo tiempo el aislamiento total de la red corporativa mediante una VLAN de invitados dedicada con acceso exclusivo a internet. Nivel tres: para los dispositivos IoT de proveedores, utilice MAC Authentication Bypass (MAB) combinado con un perfilado profundo de dispositivos (analizando huellas DHCP, agentes de usuario HTTP y patrones de tráfico) para identificar con precisión los tipos de dispositivos y asignarlos a VLAN restringidas con acceso exclusivo a internet. Integre ZTNA para que el personal corporativo acceda de forma segura a las aplicaciones de gestión interna desde cualquier ubicación del recinto o de forma remota. Para la infraestructura de balizas BLE, consulte la guía sobre Explicación de BLE Low Energy para empresas para conocer las consideraciones de integración.

Comentario del examinador: Este escenario destaca la necesidad de gestionar diversos tipos de dispositivos dentro de un único entorno físico. El modelo de segmentación de tres niveles es el enfoque correcto: intentar gestionar todos los tipos de dispositivos dentro de un único marco de políticas conduce invariablemente a políticas demasiado permisivas o demasiado restrictivas. El uso de la plataforma Guest WiFi de Purple para el nivel de invitados es especialmente relevante aquí, ya que proporciona tanto el aislamiento necesario para la seguridad como la capacidad de análisis requerida para las operaciones del recinto.

Preguntas de práctica

Q1. Su organización está desplegando ZTNA para sustituir una VPN heredada. Sin embargo, los usuarios que regresan a la oficina corporativa experimentan latencia al acceder a las aplicaciones alojadas localmente en el centro de datos local, ya que el tráfico de ZTNA se enruta a través de un agente alojado en la nube. ¿Cuál es la solución arquitectónica recomendada?

Sugerencia: Considere cómo el cliente ZTNA determina la ruta óptima hacia la aplicación en función del contexto de red física del usuario.

Ver respuesta modelo

Implemente un agente ZTNA local (Local Edge u On-Premises) dentro del centro de datos corporativo. Configure el cliente ZTNA para detectar cuándo el dispositivo está autenticado en la red corporativa interna a través de NAC y enrutar el tráfico directamente a la aplicación local a través del agente interno, en lugar de pasar por el agente alojado en la nube. Esto reduce la latencia para las aplicaciones locales al tiempo que mantiene los mismos controles de acceso basados en la identidad. El uso compartido del contexto de NAC a través de la API debe indicar al agente ZTNA que el dispositivo se encuentra en una red interna de confianza, lo que permite tomar la decisión de enrutamiento local.

Q2. El equipo de TI de un hospital necesita proteger cientos de dispositivos médicos conectados (bombas de infusión, monitores de pacientes, equipos de imagen) que no pueden ejecutar suplicantes 802.1X ni clientes ZTNA. ¿Cómo se deben proteger estos dispositivos dentro de una arquitectura convergente de NAC/ZTNA?

Sugerencia: Considere los métodos de autenticación de respaldo y el principio de aislamiento a nivel de red para los dispositivos que no pueden participar en los controles basados en la identidad.

Ver respuesta modelo

Utilise MAC Authentication Bypass (MAB) en la solución NAC, combinado con un perfilado profundo de dispositivos mediante huellas DHCP, agentes de usuario HTTP y análisis del comportamiento del tráfico para identificar y clasificar con precisión cada tipo de dispositivo médico. Una vez identificados, el NAC asigna dinámicamente estos dispositivos a VLAN aisladas y muy restringidas que solo permiten la comunicación con servidores y sistemas médicos específicos y requeridos, bloqueando todo el demás tráfico de forma predeterminada. ZTNA no es aplicable a estos dispositivos; la seguridad depende totalmente de una segmentación estricta de la red y de la supervisión continua del tráfico para detectar comportamientos anómalos. Asegúrese de que las VLAN de los dispositivos médicos estén completamente aisladas del entorno de datos de los titulares de tarjetas para mantener el cumplimiento de PCI DSS.

Q3. Durante un despliegue en producción, la integración de la API entre sus soluciones NAC y ZTNA falla de forma silenciosa: no se activa ninguna alerta. Posteriormente, el portátil de un usuario en la red corporativa se infecta con malware. Describa el resultado de seguridad esperado e identifique la brecha arquitectónica que lo permitió.

Sugerencia: Analice el impacto de una sincronización de contexto interrumpida en cada motor de políticas de forma independiente y considere qué supervisión debería haberse implementado.

Ver respuesta modelo

La solución NAC detectará el estado de seguridad degradado a través de la integración con el EDR y pondrá en cuarentena el dispositivo en la red local, evitando el movimiento lateral dentro del entorno corporativo. Sin embargo, debido a que la integración de la API ha fallado de forma silenciosa, el agente ZTNA no ha recibido el contexto de estado actualizado. Si el usuario intenta acceder a una aplicación en la nube, el cliente ZTNA aún podría establecer una conexión si el token de autenticación de identidad inicial sigue siendo válido y no ha caducado. La brecha arquitectónica es doble: primero, la ausencia de supervisión del estado de la propia integración de la API; segundo, la falta de una política de seguridad contra fallos (fail-safe) que active restricciones de acceso automáticas si se pierde la sincronización del contexto más allá de un umbral definido. La solución consiste en implementar una supervisión dedicada con alertas sobre el estado de la integración, configurar el agente ZTNA para que requiera una revalidación periódica del estado de seguridad (no solo la autenticación inicial) y definir una política de denegación por defecto que se active si el flujo de contexto de NAC no está disponible durante más de un intervalo especificado.

Continúe leyendo esta serie

Gestión del ancho de banda para WiFi de empleados: modelado, QoS y reducción de tráfico

Esta guía detalla métodos prácticos para gestionar el ancho de banda para WiFi de empleados en entornos empresariales. Cubre el modelado de tráfico, la implementación de QoS y cómo el despliegue de Purple Shield reduce la carga de la red sin necesidad de actualizar la infraestructura.

Leer la guía →

How to Reduce the Number of WiFi SSIDs Using Per-Device PSK (iPSK, DPSK, MPSK)

Esta guía de referencia técnica autorizada explica cómo los equipos de TI pueden eliminar la degradación del rendimiento de WiFi causada por la sobrecarga de balizas (beacons) de SSID al unificar múltiples redes dedicadas en un único SSID mediante PSK por dispositivo (xPSK). Abarca el panorama de proveedores que incluye Cisco iPSK, HPE Aruba MPSK, Ruckus DPSK, Juniper Mist PPSK y Ubiquiti UniFi PPSK, con orientación práctica de implementación sobre asignación dinámica de VLAN, incorporación de IoT y cumplimiento de PCI DSS. Los operadores de recintos en los sectores de hostelería, retail, estadios y organizaciones del sector público encontrarán directrices de arquitectura prácticas y ejemplos reales detallados.

Leer la guía →

What is a Probe Request? Understanding How Devices Discover Networks

Esta guía de referencia técnica ofrece un análisis en profundidad de las solicitudes de sondeo IEEE 802.11, el escaneo activo frente al pasivo y el impacto de la aleatorización de MAC en el análisis de ubicaciones. Proporciona estrategias de implementación prácticas para que los arquitectos de red optimicen las implementaciones de alta densidad, mitiguen las 'tormentas de sondeo' y garanticen una recopilación de datos precisa y compatible con GDPR utilizando capas de identidad autenticadas.

Leer la guía →