Cómo Remote Browser Isolation a la arquitectura «Zero Trust»

Remote browser isolation RBI) es una de las expresiones técnicas más directas del principio fundamental del modelo «zero trust»: nunca conceder confianza implícita a ningún contenido, sesión o dispositivo. Para los arquitectos de seguridad que adaptan los controles a los principios de la norma NIST SP 800-207 y al Modelo de Madurez «Zero Trust» de la CISA, el RBI subsana una laguna que el filtrado de URL mediante SWG y la detección en los terminales, por sí solos, no pueden cubrir: las amenazas procedentes del navegador que se ejecutan antes de que se alcance una decisión. Este artículo explica exactamente cómo se corresponde el RBI con los principios del modelo «Zero Trust» de «verificar explícitamente», «privilegio mínimo» y «asumir la violación», y cuál es su lugar junto a ZTNA, SWG, CASB y DLP dentro de una pila moderna de SSE.

¿Qué es Remote Browser Isolation?

Remote browser isolation una tecnología de seguridad que ejecuta las sesiones de navegación web en un contenedor alojado en la nube, separando físicamente todo el código web del dispositivo del usuario. El dispositivo local nunca procesa directamente el código web activo; en su lugar, solo recibe un flujo de píxeles o un DOM depurado y reconstruido.

Imagínese a una analista de compras de una empresa fabricante de tamaño medio que recibe un enlace de un nuevo proveedor. El dominio se registró la semana pasada, carece de historial de reputación de URL y se encuentra en la zona gris «sin clasificar», donde un SWG tradicional lo bloquearía (lo que frustraría a la analista) o lo permitiría (confiando en lo desconocido). Con RBI, la página se carga dentro de un contenedor en la nube desechable. El analista ve una página totalmente interactiva —rellena un formulario, descarga un PDF—, pero ni JavaScript, ni ActiveX, ni ningún exploit incrustado llega a afectar a su ordenador portátil. Si la página albergara un exploit de día cero, este se activaría de forma inofensiva dentro de un contenedor que se borra en el momento en que ella cierra la pestaña.

Este modelo es más importante que nunca. El Grupo de Inteligencia sobre Amenazas de Google (GTIG) registró 75 vulnerabilidades de «día cero» explotadas en entornos reales en 2024, y el 44 % de esas explotaciones tenían como objetivo tecnologías empresariales (GTIG, abril de 2025). Las cadenas de ataque basadas en navegadores siguen siendo un vector persistente, y RBI proporciona una defensa en profundidad independientemente de si la amenaza es conocida o no.

¿Por qué es importante el RBI para el modelo «Zero Trust»?

El modelo «zero trust» no es un producto que se adquiera, sino un conjunto de principios de diseño. La norma NIST SP 800-207 (2020) establece que el modelo «zero trust» parte de la base de que no se concede confianza implícita a los activos ni a las cuentas de usuario basándose únicamente en su ubicación física o en la red, ni en la titularidad de los activos. Sin embargo, el navegador ha funcionado tradicionalmente basándose en la confianza implícita: si una URL cumple los criterios de la lista de permitidos del SWG o un dominio cuenta con un certificado válido, el terminal carga y ejecuta todo el código que envía el servidor. Se trata de un modelo de confianza perimetral aplicado a una interacción a nivel de sesión.

La brecha de madurez sigue siendo evidente. En la encuesta de Gartner de 2024 sobre la adopción del modelo «zero-trust», el 63 % de las organizaciones afirmaron haber implementado total o parcialmente una estrategia «zero-trust», pero Gartner señaló que, para la mayoría de ellas, este modelo sigue cubriendo la mitad o menos del entorno y mitiga una cuarta parte o menos del riesgo empresarial global. Una de las brechas más importantes que aún persisten es la sesión del navegador: según Gartner, los navegadores son el principal método de acceso a la mayoría de las aplicaciones corporativas modernas; sin embargo, menos del 10 % de las organizaciones ha adoptado a día de hoy un navegador empresarial seguro, aunque Gartner prevé que la adopción aumente hasta el 25 % para 2028. El navegador es el lugar donde los empleados interactúan a diario con aplicaciones SaaS, herramientas de IA y sitios web externos, pero muchas organizaciones siguen tratándolo con un simple modelo de «permitir/bloquear», en lugar de aplicar controles granulares de visibilidad, políticas y protección de datos.

Imaginemos a un responsable de cumplimiento normativo del sector de los servicios financieros que accede a un portal regulatorio alojado por un proveedor externo. El SWG clasifica el dominio como «gubernamental» y permite el acceso. Sin embargo, el portal del proveedor ejecuta un complemento vulnerable y un atacante ha inyectado un iframe malicioso. Sin RBI, el terminal de la responsable se convierte ahora en la superficie de ataque. Con RBI, el iframe se carga dentro de un contenedor aislado, la carga maliciosa nunca llega al terminal y la responsable finaliza su tarea sin darse cuenta de que existía la amenaza.

Cómo se ajusta el RBI a los tres principios del modelo «Zero Trust»

Verifíquelo de forma explícita

La norma NIST SP 800 207 exige que ningún activo se considere de confianza de forma inherente: la empresa debe evaluar el estado de seguridad del activo al analizar cada solicitud de recursos. RBI aplica este principio en la capa de sesiones web. En lugar de tomar una decisión binaria sobre la confianza basada en la reputación de la URL, RBI ejecuta cada sesión que cumple los requisitos de forma aislada y evalúa el contenido en función de su comportamiento dentro del contenedor. De este modo, la verificación pasa de ser un control puntual (comprobación de la URL) a un modelo de contención continua en el que ni siquiera a los dominios «de confianza» se les conceden privilegios de ejecución de código sin procesar en los terminales.

Cuando un gestor de reclamaciones sanitarias abre un portal para socios y accede a una página que activa una descarga silenciosa, los controles de verificación tradicionales —autenticación multifactorial (MFA), cumplimiento de los requisitos del dispositivo y reputación de la URL— ya se han superado. El usuario está autenticado, el dispositivo está gestionado y la URL se ha clasificado como segura. RBI añade una capa de verificación adicional: incluso después de que se hayan superado todas las comprobaciones previas, no se considera de confianza que el propio contenido web se ejecute en el terminal.

Privilegio mínimo

La norma NIST SP 800 207 especifica que se aplican los principios del privilegio mínimo para restringir tanto la visibilidad como la accesibilidad. RBI aplica el principio del privilegio mínimo a la entrega de contenidos web. Los usuarios solo reciben lo que necesitan para realizar su trabajo: una representación visual procesada de la página. No reciben código JavaScript sin procesar, CSS ni objetos ejecutables. Los controles de DLP integrados en RBI pueden restringir aún más las operaciones del portapapeles, la impresión, la carga de archivos y las descargas en función del nivel de confidencialidad de la sesión.

Un ejemplo concreto: un proveedor de servicios gestionados concede a los contratistas acceso al sistema de gestión de incidencias de la empresa a través de ZTNA. Los contratistas se autentican, superan las comprobaciones de conformidad de los dispositivos y acceden a la aplicación. Sin embargo, el arquitecto de seguridad también aplica una política de RBI: las sesiones de los contratistas se ejecutan de forma aislada, con la función de copiar y pegar desactivada y las descargas restringidas a archivos PDF sin formato. Los contratistas pueden leer y actualizar los tickets, pero no pueden extraer datos sin procesar. Se trata de la aplicación del principio del «privilegio mínimo», no solo al acceso a la red, sino también a las acciones que los usuarios pueden realizar dentro de la sesión.

Suponer que se ha producido una filtración

La norma NIST SP 800 207 parte de la base de que la red es siempre hostil y de que existen amenazas externas e internas en todo momento. RBI incorpora este principio desde su diseño: parte de la base de que cualquier página web podría verse comprometida y establece un «air gap» entre el contenido web y el terminal. Tal y como señala la Cloud Security Alliance, RBI ejecuta sesiones web de alto riesgo en contenedores en la nube aislados y efímeros, en los que el terminal local del usuario nunca interactúa directamente con el código web activo (CSA, enero de 2026).

Si un comercial visita la página de marketing de un proveedor de SaaS comprometido que distribuye una carga útil de malware sin archivos a través de una biblioteca JavaScript maliciosa, dicha carga útil se ejecuta dentro del contenedor y se destruye al finalizar la sesión. No existe ningún mecanismo de persistencia, ni oportunidad de movimiento lateral, ni rastro alguno en el terminal. Se mantiene la postura de «suponer una brecha de seguridad» aunque la amenaza haya eludido todos los demás controles de la pila.

Cómo encaja el RBI en el modelo de madurez «Zero Trust» de la CISA

El Modelo de Madurez de «Zero Trust» de la CISA, versión 2.0 (2023), estructura el enfoque «Zero Trust» en torno a cinco pilares —Identidad, Dispositivos, Redes, Aplicaciones y cargas de trabajo, y Datos— con tres capacidades transversales: Visibilidad y análisis, Automatización y orquestación, y Gobernanza. El RBI contribuye a varios pilares simultáneamente:

Pilar ZTMM de la CISA: Contribución del RBI y progresión de la madurez

La norma NIST SP 800-207 define la tríada arquitectónica compuesta por el motor de políticas (PE), el administrador de políticas (PA) y el punto de aplicación de políticas (PEP). Dentro de este modelo, RBI actúa como PEP en la capa de sesión del navegador. El PE evalúa el contexto de la solicitud —identidad del usuario, estado del dispositivo, riesgo de la URL, sensibilidad de los datos— y el PA ordena al servicio RBI que aísle la sesión y aplique los controles de datos adecuados. Esto se ajusta a los requisitos de la CISA en materia de verificación por solicitud, tal y como los describe la Cloud Security Alliance (CSA, enero de 2026).

RBI dentro de la pila de SSE: integración con ZTNA, SWG, CASB y DLP

El RBI, por sí solo, resulta útil, pero tiene sus limitaciones. Su pleno valor en el marco del modelo «zero trust» se pone de manifiesto cuando funciona como un componente integrado dentro de una plataforma Security Service Edge SSE) que incluye SWG, CASB, ZTNA y DLP.

Considere el flujo de trabajo cuando un empleado que utiliza un dispositivo gestionado accede a una herramienta de IA generativa a través de un navegador. El SWG inspecciona la solicitud, clasifica el destino y determina el riesgo de la URL. El CASB identifica la aplicación de IA y comprueba si está autorizada. El motor DLP analiza el texto de la solicitud en busca de datos confidenciales. Y la sesión RBI —activada por la política del SWG, ya que la herramienta de IA está clasificada como «de supervisión»— garantiza que el empleado pueda utilizar la herramienta, pero no pueda pegar información de identificación personal (PII) de los clientes, descargar respuestas que contengan contenido confidencial ni cargar archivos con datos regulados. Todo ello tiene lugar dentro de un único motor de políticas, y no a través de cuatro productos independientes con consolas separadas.

Este modelo de integración es el motivo por el que Gartner estima que el mercado de SASE crecerá a una tasa compuesta anual (CAGR) del 26 %, hasta alcanzar los 28 500 millones de dólares en 2028 (Gartner, febrero de 2025). Las empresas están unificando el acceso, la protección frente a amenazas y la seguridad de los datos en plataformas integradas, ya que la alternativa —la combinación de productos independientes de RBI, SWG, CASB y DLP— genera lagunas en las políticas, una aplicación inconsistente y una sobrecarga operativa que socava el modelo «zero trust».

Skyhigh Private Access ZTNA con el análisis DLP y la ejecución de RBI sin interrupciones, de modo que las sesiones de aplicaciones privadas quedan aisladas cuando así lo exige la política, sin necesidad de desviar el tráfico a través de un producto independiente.

Cuando el navegador se convierte en el espacio de trabajo

El navegador es el espacio de trabajo principal para el acceso a servicios SaaS, el uso de herramientas de IA, la descarga de archivos, la introducción de credenciales y la colaboración con terceros. Un arquitecto de seguridad que implemente ZTNA para proteger aplicaciones privadas, pero que ignore la sesión del navegador en la que los empleados interactúan con dichas aplicaciones, presenta una brecha en la aplicación de las medidas de seguridad. RBI subsana esa brecha, no sustituyendo el navegador que los usuarios ya conocen (Chrome, Edge, Firefox, Safari), sino envolviendo la sesión en una capa de aislamiento basada en la nube controlada por la política de SSE.

Un colaborador externo no gestionado abre la aplicación CRM de una empresa a través de un CASB de proxy inverso. El CASB autentica al colaborador, aplica controles de sesión y activa una política RBI, ya que el dispositivo no está gestionado. El colaborador ve y utiliza el CRM con normalidad, pero, en segundo plano, la sesión se ejecuta de forma aislada, con restricciones en el portapapeles y el bloqueo de descargas. La empresa protege los datos sin obligar al colaborador a instalar un agente, registrar un dispositivo ni utilizar un navegador específico.

Criterios de evaluación: qué hay que tener en cuenta en un RBI de «cero confianza»

No todas las implementaciones de RBI aportan el mismo valor en materia de «zero trust». Los arquitectos de seguridad que evalúen el aislamiento del navegador deben tener en cuenta los siguientes criterios:

1. Integración nativa con SSE. El RBI debe formar parte del mismo motor de políticas que el SWG, el CASB, el ZTNA y el DLP. Si el RBI requiere una consola independiente, políticas independientes o una gestión del tráfico independiente, se generan lagunas operativas e incoherencias en las políticas.

2. Controles granulares de los datos dentro de las sesiones de aislamiento. El modelo «zero trust» exige la aplicación del principio de «privilegio mínimo» a nivel de sesión. El RBI debe permitir desactivar el portapapeles, la impresión, la carga, la descarga y la captura de pantalla de forma independiente por política, por grupo de usuarios y por categoría de aplicación.

3. Compatibilidad con dispositivos no gestionados. Una solución que requiera un agente en el terminal para habilitar el aislamiento entra en contradicción con uno de los principales casos de uso de RBI: proteger el acceso desde dispositivos que la empresa no controla.

4. Rendimiento y experiencia del usuario. Si el RBI introduce una latencia perceptible, los usuarios buscarán formas de eludirlo —abriendo enlaces en sus dispositivos personales, utilizando puntos de acceso móvil o, simplemente, quejándose hasta que el departamento de TI establezca excepciones—. La capa de aislamiento debe cargar las páginas a una velocidad casi nativa.

5. Fidelidad de representación. Las aplicaciones SaaS modernas son aplicaciones de página única complejas que hacen un uso intensivo de JavaScript. RBI debe gestionarlas sin alterar su funcionalidad, sin omitir elementos interactivos ni mermar la experiencia del usuario.

6. Activación escalable basada en políticas. El modelo «zero trust» no requiere aislar todas las sesiones. Las mejores implementaciones permiten a los equipos de seguridad definir criterios de activación basados en el riesgo: aislar las URL no clasificadas, aislar todas las sesiones de los usuarios de alto riesgo, aislar categorías específicas de SaaS o aislar todo el tráfico procedente de dispositivos no gestionados.

7. Visibilidad y análisis. El RBI debería incorporar la telemetría de las sesiones a la capa de análisis más amplia del SSE, contribuyendo así a la capacidad transversal de «Visibilidad y análisis» del ZTMM de la CISA. Esto implica saber quién ha accedido a qué, cuándo, desde dónde y utilizando qué dispositivo, así como si dicho comportamiento se desvía de la línea de base.

El coste del «punto ciego» de la navegación

Dejar las sesiones del navegador fuera de los controles de «zero trust» tiene un coste cuantificable. Según el informe de IBM «Cost of a Data Breach Report 2024» (julio de 2024), el coste medio mundial de una filtración de datos alcanzó los 4,88 millones de dólares estadounidenses en 2024. Las credenciales comprometidas fueron el vector de ataque más habitual, representando el 16 % de todas las filtraciones.

El phishing a través del navegador es uno de los principales mecanismos utilizados para el robo de credenciales. Un administrador de nóminas recibe un enlace a lo que parece ser la página de inicio de sesión de un portal de prestaciones. El dominio se ha registrado recientemente, supera las comprobaciones DMARC y parece legítimo. Sin RBI, el administrador introduce sus credenciales en la página del atacante y el robo de credenciales se lleva a cabo. Con RBI aplicando una política de aislamiento a los dominios no categorizados, la página de phishing se carga en un contenedor, el sistema DLP detecta el patrón de envío de credenciales y la sesión se interrumpe antes de que las credenciales salgan del entorno aislado.

La justificación financiera de la implementación de RBI no es meramente teórica. Las organizaciones que subsanan las deficiencias en la aplicación de medidas de seguridad a nivel del navegador reducen su exposición a los vectores de ataque más costosos: el robo de credenciales, la distribución de malware a través de la web y la exfiltración de datos mediante acciones del navegador no supervisadas.

Errores habituales al implementar el RBI en un modelo «Zero Trust»

Implementación de RBI como producto independiente. Sin la integración con SSE, RBI se convierte en otra solución puntual con su propio silo de políticas. Un sistema sanitario que implemente RBI por separado de su SWG acabará teniendo dos motores de categorización de URL distintos, dos consolas de políticas y una desviación inevitable. Las políticas entran en conflicto, las excepciones proliferan y el modelo «zero trust» se ve mermado.

Aislarlo todo, siempre. El aislamiento generalizado supone un desperdicio de recursos informáticos y reduce el rendimiento en las sesiones de bajo riesgo. Un enfoque basado en el riesgo —que consiste en aislar los dominios no clasificados, los grupos de usuarios de alto riesgo y las categorías de aplicaciones sensibles— ofrece mejores resultados en materia de seguridad con menos obstáculos.

Ignorar los dispositivos no gestionados. Algunas implementaciones exigen que los agentes desvíen el tráfico hacia el servicio de aislamiento, lo que excluye precisamente el caso de uso (contratistas, BYOD, transiciones por fusiones y adquisiciones) en el que RBI aporta el mayor valor. Una empresa minorista que incorpora a responsables de almacén temporales que utilizan tabletas personales necesita un aislamiento sin agentes, no un redireccionamiento que dependa de ellos.

Descuidar la protección DLP en las sesiones aisladas. La protección RBI sin controles de datos detiene el malware, pero no la filtración de datos. Un empleado que no pueda pegar registros de clientes en un correo electrónico personal a través de un navegador normal sí podrá hacerlo a través de una sesión aislada, a menos que se apliquen controles sobre el portapapeles.

Considerar RBI como un sustituto de la VDI. RBI aísla las sesiones del navegador, no los escritorios completos. Complementa a la VDI en casos de uso específicos (acceso a la web para terceros), pero no la sustituye para los usuarios que necesitan aplicaciones de escritorio nativas.