¿Qué es Remote Browser Isolation cómo funciona el RBI?

Remote browser isolation RBI) ejecuta el contenido web en un contenedor en la nube desechable, en lugar de hacerlo en el terminal del usuario, lo que garantiza que el código malicioso procedente de páginas de phishing, vulnerabilidades de día cero y descargas automáticas nunca llegue al dispositivo o a la red de la empresa. Para los arquitectos de seguridad que evalúan la tecnología de aislamiento del navegador como parte de una estrategia de confianza cero, el RBI ofrece un modelo de seguridad fundamentalmente diferente: en lugar de intentar detectar todas las amenazas en el tráfico web, parte de la base de que todo el contenido web es poco fiable y separa físicamente la ejecución del terminal. Este enfoque está cobrando mayor importancia a medida que el navegador se convierte en el principal espacio de trabajo —y en la principal superficie de ataque— en todas las empresas.

¿Qué es Remote Browser Isolation?

Remote browser isolation una tecnología de ciberseguridad que separa físicamente la actividad de navegación web de un usuario de su dispositivo local y de la red corporativa. Cuando un usuario accede a un sitio web, la página se carga y se ejecuta dentro de un contenedor en la nube seguro y efímero, en lugar de hacerlo en el navegador de su ordenador portátil o estación de trabajo. El usuario ve e interactúa con una representación visual segura de la página; todo el código subyacente —HTML, CSS, JavaScript, objetos incrustados— permanece confinado en el entorno remoto. Cuando finaliza la sesión, el contenedor se destruye junto con cualquier carga maliciosa con la que pueda haberse encontrado. Cuando se ofrece como un servicio alojado en la nube, esta tecnología se conoce como remote browser isolation.

Así es como funciona el proceso en la práctica: una directora de marketing recibe un correo electrónico con un enlace a un supuesto informe del sector. Hace clic en él. En lugar de que el enlace se cargue directamente en Chrome en su ordenador portátil, el tráfico se redirige a través de la secure web gateway, que redirige la URL no clasificada a una sesión de RBI. Se activa un contenedor en la nube desechable, que carga la página y la muestra. La directora de marketing ve una versión totalmente interactiva de la página —puede desplazarse, hacer clic y leer—, pero ningún contenido HTML, JavaScript ni ejecutable llega jamás a su equipo. Si el enlace conduce a una página de phishing que contiene un exploit de día cero, el código malicioso se ejecuta dentro del contenedor, el cual se destruye al finalizar la sesión. Su terminal permanece a salvo. No se produce ninguna filtración de datos. Es posible que el SOC nunca tenga que evaluar un incidente, ya que el ataque se contuvo antes de que comenzara.

Este modelo se aleja radicalmente de la seguridad tradicional basada en la detección. A diferencia de los motores antivirus o los filtros de reputación de URL, que se basan en patrones y firmas de amenazas conocidas, el aislamiento del navegador adopta un enfoque de «confianza cero», es decir, trata todo el contenido web como potencialmente hostil, independientemente de su reputación. Esa distinción es importante porque las herramientas tradicionales son, por su propia naturaleza, incapaces de detectar los ataques de «hora cero», es decir, aquellas amenazas que aún no cuentan con una firma.

Por qué Remote Browser Isolation ahora Remote Browser Isolation

El navegador ya no es solo una ventana a Internet. Es el espacio de trabajo de la empresa en el que convergen el correo electrónico, las aplicaciones SaaS, los sistemas CRM, las plataformas financieras y las herramientas de inteligencia artificial. Esa concentración de actividades sensibles convierte al navegador en un objetivo sumamente atractivo.

Casi la mitad de los incidentes de seguridad investigados en 2024 (44 %) estuvieron relacionados con actividades maliciosas iniciadas o facilitadas a través de los navegadores de los empleados, entre las que se incluyen el phishing, el uso indebido de redireccionamientos de URL y las descargas de malware (Informe global de respuesta a incidentes de Unit 42 de 2025). Por su parte, el Informe sobre el estado de la seguridad de los navegadores de 2025, elaborado por Menlo Security, revela un aumento del 140 % en los ataques de phishing dirigidos a los navegadores durante el último año, con un incremento del 130 % en los incidentes de phishing de «hora cero» —ataques demasiado recientes para que figuren en ninguna base de datos de firmas—.

El impacto financiero es grave. El coste medio mundial de una filtración de datos alcanzó los 4,88 millones de dólares en 2024, según el informe «Cost of a Data Breach» de IBM. Los ataques mediante credenciales comprometidas tardaron una media de 292 días en identificarse y contenerse. Muchas de esas cadenas de robo de credenciales comienzan en el navegador: un usuario accede a una página de phishing convincente, introduce sus credenciales y el atacante permanece en el entorno durante casi diez meses antes de que se logre contenerlo.

Consideremos un caso concreto: un analista financiero de un banco de tamaño medio recibe una notificación en el navegador que parece proceder del sistema de gestión de documentos del banco. El enlace redirige a una réplica idéntica de la página de inicio de sesión, alojada en una plataforma en la nube legítima para eludir los filtros de reputación de URL. Sin aislamiento del navegador, el analista introduce sus credenciales y el atacante obtiene acceso a los sistemas internos. Con el RBI activado, la página de phishing se carga dentro de un contenedor en la nube; incluso si el analista intenta introducir sus credenciales, la sesión puede configurarse para bloquear la introducción de credenciales en dominios no categorizados o para eliminar por completo el envío de formularios. La cadena de ataque se interrumpe en el primer enlace.

La norma NIST SP 800-46, Rev. 2, subraya el modelo de amenaza que hace que el RBI sea esencial: el documento parte de la base de que los dispositivos de los usuarios que teletrabajan se verán infectados por malware y recomienda controles por capas, incluidas soluciones de acceso a la red que verifiquen el estado de seguridad del usuario antes de concederle acceso. El RBI pone en práctica esta hipótesis, al no confiar en ningún momento en que el terminal pueda procesar de forma segura el contenido web.

Cómo Remote Browser Isolation : tres enfoques de representación

Todas las soluciones RBI comparten la misma arquitectura básica: el contenido web se recupera y se ejecuta en un entorno remoto y aislado (normalmente, un contenedor efímero en la nube), y solo se envía al navegador local del usuario una representación segura de la página. La diferencia fundamental radica en cómo se genera y se transmite esa representación segura. Existen tres enfoques principales.

Transmisión de píxeles (Pixel Streaming)

Este enfoque procesa el contenido web en un servidor remoto y envía una representación visual de la página web al dispositivo del usuario en forma de imagen interactiva o transmisión de vídeo. Piénselo como si se tratara de una retransmisión en directo de una sesión de navegador que se ejecuta en el ordenador de otra persona: el dispositivo del usuario actúa como un cliente de visualización ligero.

Ventaja de seguridad: aislamiento máximo. El código web original ni los scripts llegan en ningún momento al terminal. Todos los posibles vectores de ataque integrados en el código del sitio web permanecen aislados en el servidor remoto.

Inconveniente: La codificación y transmisión continuas de flujos de vídeo consumen mucho ancho de banda y resultan costosas a gran escala. Incluso cuando están muy optimizadas, la latencia inevitable da lugar a una experiencia de usuario notablemente diferente. En pantallas con alta resolución (DPI), el texto puede aparecer borroso; los usuarios de dispositivos móviles con conexiones variables experimentan una calidad degradada.

Idoneidad: Entornos de alta seguridad en los que la confidencialidad prima sobre la experiencia del usuario: investigación OSINT, acceso administrativo privilegiado a sistemas críticos o navegación en entornos clasificados.

Duplicación del DOM (reconstrucción del DOM)

Mediante la reconstrucción del DOM, las páginas web se cargan en un entorno aislado, se analizan a nivel del Modelo de Objetos de Documento (DOM) y se reescriben para eliminar posibles amenazas. Una vez depurado el contenido, se envía una versión limpia al dispositivo del usuario, donde el navegador del terminal la representa utilizando su propio motor.

Ventaja en materia de seguridad: ligero y rápido. El dispositivo final ofrece una experiencia de navegación casi nativa que conserva la aceleración por GPU y el comportamiento estándar de desplazamiento.

Inconveniente: Las tecnologías subyacentes —HTML, CSS, fuentes web— constituyen en sí mismas vectores de ataque. Intentar eliminar el contenido malicioso mediante la depuración es, por naturaleza, un proceso imperfecto; es posible que se pasen por alto nuevas técnicas de explotación. Las páginas dinámicas complejas pueden dejar de funcionar o mostrarse de forma incorrecta.

Idoneidad: Navegación empresarial de uso general en la que el rendimiento y la experiencia del usuario son lo más importante, y en la que la organización acepta un nivel de aislamiento ligeramente inferior en aras de la productividad.

Renderizado vectorial en red (NVR)

NVR intercepta los comandos de dibujo del motor gráfico utilizado en Chromium y Firefox, los cifra y los transmite al navegador local. Dado que NVR transmite comandos de dibujo vectoriales en lugar del código real de la página web, logra un menor consumo de ancho de banda que el procesamiento de píxeles, al tiempo que mantiene una sólida barrera de aislamiento.

Ventaja en materia de seguridad: el código del sitio web no llega al dispositivo final, de forma similar al «pixel pushing», pero el consumo de ancho de banda es considerablemente menor, ya que los comandos de dibujo vectorial son mucho más compactos que los fotogramas de vídeo pixelados.

Inconveniente: la adopción de NVR es más limitada y puede depender de la compatibilidad específica con el motor del navegador. Se sitúa a medio camino entre el «pixel pushing» y el «DOM mirroring», tanto en lo que respecta a la seguridad como al rendimiento.

Ideal para: Organizaciones que necesitan una seguridad casi al nivel del píxel sin la sobrecarga de ancho de banda que ello supone —plantillas distribuidas con conexiones de red variables—.

Aislamiento total frente a aislamiento selectivo: cómo elegir el modelo de política adecuado

La mayoría de las organizaciones no necesitan —ni desean— aislar cada sesión de navegación. La merma en el rendimiento y los costes informáticos que conlleva el aislamiento total son difíciles de justificar cuando la mayor parte del tráfico se dirige a aplicaciones SaaS bien conocidas y clasificadas. Es aquí donde el aislamiento selectivo se convierte en una estrategia práctica.

El aislamiento total desvía todo el tráfico web a través de RBI. Cada página, cada sesión, cada usuario. Este enfoque resulta adecuado para segmentos que requieren un alto nivel de seguridad: una agencia gubernamental que maneja información clasificada, una sala de operaciones financieras o un laboratorio de investigación sanitaria que accede a fuentes de datos externas. La garantía de seguridad es absoluta, pero también lo son el coste y el impacto en la latencia.

El aislamiento selectivo aplica el RBI únicamente al tráfico que supera un umbral de riesgo definido. Entre los factores desencadenantes habituales se incluyen:

Dominios sin clasificar o recién registrados. Un contratista hace clic en un enlace que conduce a un dominio registrado hace 48 horas. El SWG lo marca como «sin clasificar»; el RBI aísla la sesión automáticamente.

Categorías de URL de riesgo. Los sitios clasificados como de intercambio de archivos, correo electrónico personal o redes publicitarias se aíslan, mientras que el tráfico corporativo de SaaS fluye directamente.

Enlaces incluidos en los correos electrónicos. Todas las URL de los correos electrónicos recibidos —independientemente de su reputación— se abren a través de RBI, lo que neutraliza el principal mecanismo de distribución del phishing.

Segmentos de usuarios sensibles. Los ejecutivos y los usuarios de los departamentos de finanzas y recursos humanos que gestionan datos sujetos a normativa navegan con aislamiento de forma predeterminada; el personal en general lo utiliza únicamente para destinos de riesgo.

El punto clave de integración es la secure web gateway(SWG), que clasifica y redirige el tráfico en tiempo real. La política de la SWG determina qué sesiones acceden a RBI y cuáles pasan por la inspección estándar. Cuando la SWG forma parte de una plataforma SSE más amplia, las decisiones de aislamiento pueden incorporar puntuaciones de riesgo de CASB, clasificación de DLP, identidad del usuario, estado del dispositivo e inteligencia sobre amenazas en tiempo real, creando así una política sensible al contexto que equilibra la seguridad con la productividad.

Cómo encaja el RBI en la arquitectura «Zero Trust» y SSE

El aislamiento del navegador no funciona de forma aislada. Cuando se implementa de forma independiente, combate el malware basado en la web y el phishing, pero deja lagunas en lo que respecta a la exfiltración de datos, la «TI en la sombra» de los servicios SaaS y los ataques basados en la identidad. Su verdadero valor se pone de manifiesto cuando el aislamiento del navegador (RBI) se integra en una arquitectura de confianza cero junto con controles complementarios.

El Modelo de Madurez de «Zero Trust» v2.0 (2023) de la CISA permite abandonar los enfoques tradicionales centrados en el perímetro, lo que permite a las organizaciones aislar los hosts, aplicar el cifrado, segmentar la actividad e implementar controles de seguridad más cercanos a las aplicaciones y los datos. RBI se ajusta directamente a estos principios: aísla el entorno de navegación, aplica el cifrado entre el contenedor y el terminal, y segmenta la actividad web de riesgo de la red corporativa.

El plan técnico de la Cloud Security Alliance para 2026 sobre seguridad de los navegadores va más allá, al replantear el navegador como un punto de aplicación de políticas (PEP) de primer orden dentro de una arquitectura integral de «Zero Trust» que unifica los controles de acceso con privilegios mínimos, la autenticación multifactorial resistente al phishing, la validación del estado de los dispositivos, la gestión adaptativa de sesiones y remote browser isolation. La CSA recomienda específicamente implementar remote browser isolation sesiones privilegiadas o de riesgo elevado, con el fin de neutralizar tanto el compromiso de los terminales como las amenazas maliciosas basadas en la web.

En las arquitecturas SSE reales, el RBI funciona junto con:

SWG para el filtrado de URL, la inteligencia sobre amenazas y la toma de decisiones sobre el enrutamiento del tráfico.

CASB para obtener visibilidad sobre el uso autorizado y no autorizado de servicios SaaS, con la opción de aislar las sesiones de los servicios de «shadow IT» y bloquear al mismo tiempo las acciones de carga y descarga.

El DLP inspeccionará el contenido que circule por sesiones aisladas y evitará que se peguen, se suban o se impriman datos confidenciales durante la navegación de riesgo.

ZTNA / Private Access aislar las sesiones de los dispositivos no gestionados que acceden a aplicaciones internas: un colaborador externo que utiliza su ordenador portátil personal accede a la intranet de la empresa a través de una sesión aislada en la que las funciones de copiar, pegar y descargar están desactivadas.

Según el Magic Quadrant de Gartner de 2024 Magic Quadrant SSE, para 2026, el 85 % de las organizaciones que busquen proteger sus aplicaciones web, SaaS y privadas obtendrán las capacidades de seguridad a través de una solución SSE. El RBI figura entre las capacidades que se esperan de una plataforma SSE madura, lo que refuerza la idea de que el aislamiento ya no es opcional para las organizaciones que se toman en serio la seguridad de los navegadores empresariales.

Evaluación de soluciones de RBI: qué deben priorizar los arquitectos de seguridad

No todas las implementaciones de RBI son iguales. A la hora de evaluar soluciones, céntrese en los criterios que influyen directamente en el nivel de seguridad, la complejidad operativa y la aceptación por parte de los usuarios.

1. Método de representación y techo de aislamiento. Averigüe si la solución utiliza «pixel pushing», «DOM mirroring», NVR o un enfoque híbrido. Pregunte al proveedor qué contenido —si lo hay— se ejecuta en el navegador del terminal. Una solución de «DOM mirroring» que envía código JavaScript depurado al terminal presenta una superficie de amenaza diferente a la de una solución de «pixel pushing» que solo envía fotogramas de imagen.

2. Experiencia de usuario y latencia. Solicite una prueba de concepto en su entorno de red real. Pida a los usuarios que carguen sus diez aplicaciones SaaS más utilizadas a través de la sesión aislada y mida el tiempo de carga de las páginas, la fluidez del desplazamiento, el comportamiento al copiar y pegar, y los flujos de trabajo de carga y descarga de archivos. Si la experiencia se ve mermada de forma notable, la adopción por parte de los usuarios fracasará, y estos encontrarán soluciones alternativas que eludan por completo el aislamiento.

3. Nivel de integración de SSE. El motor de aislamiento debe compartir la política, el contexto de identidad, las reglas de DLP y la inteligencia sobre amenazas con los componentes SWG, CASB y ZTNA. Si tiene que gestionar la política de RBI en una consola independiente con un lenguaje de reglas distinto, está adquiriendo un producto puntual, no una funcionalidad de plataforma. La plataforma SSE Skyhigh Security integra RBI con SWG, CASB, DLP y ZTNA bajo un único motor de políticas, lo que constituye un ejemplo del enfoque unificado que los arquitectos de seguridad deberían exigir.

4. Compatibilidad con dispositivos no gestionados. Uno de los casos de uso más valiosos de RBI es permitir el acceso seguro desde dispositivos que la organización no controla —ordenadores portátiles de contratistas, dispositivos de socios, tabletas personales—. La solución debe admitir una implementación sin cliente (sin agente), en la que los usuarios se conecten a través de un navegador estándar sin necesidad de instalar agentes ni software propietario.

5. Nivel de control de los datos. ¿Permite la solución desactivar las funciones de copiar y pegar, imprimir, realizar capturas de pantalla y descargar archivos en función de cada política? En el caso de una sesión aislada en la que un colaborador externo acceda a Salesforce, se desea un acceso de solo lectura, con la función de copiar y pegar bloqueada y sin almacenamiento de archivos en caché local.

6. Escalabilidad y presencia en la nube. Cada sesión aislada consume recursos informáticos. Infórmese sobre la infraestructura en la nube del proveedor, su presencia geográfica, los límites de concurrencia de sesiones y cómo varían los costes a medida que se añaden usuarios o se incrementa el porcentaje de tráfico aislado.

7. Compatibilidad con los navegadores existentes. La estrategia de adopción más sólida consiste en mantener los navegadores que ya utilizan los usuarios —Chrome, Edge, Firefox, Safari— en lugar de exigirles que los sustituyan por un navegador propio. Tal y como se analiza en la comparación entre los navegadores empresariales y el RBI, las soluciones SSE integradas en el RBI le permiten proteger los navegadores que los empleados ya utilizan sin imponer una migración que suponga una interrupción en su trabajo.

Errores habituales en las implementaciones de RBI

Aislarlo todo desde el primer día. El aislamiento total de todo el tráfico puede parecer una medida segura en una presentación, pero genera quejas sobre el rendimiento que minan la confianza de los usuarios. Un enfoque más adecuado: comience por las categorías de alto riesgo —dominios sin clasificar, URL incrustadas en correos electrónicos y sesiones de dispositivos no gestionados—. Amplíe el alcance del aislamiento a medida que evalúe el impacto en los usuarios y vaya ganándose su confianza.

Implementación de RBI como producto independiente. RBI sin integración con SWG no puede tomar decisiones de enrutamiento inteligentes. RBI sin DLP no puede impedir que un usuario introduzca datos confidenciales en un formulario web durante una sesión aislada. RBI sin CASB no tiene visibilidad para determinar si el destino es un almacenamiento en la nube autorizado o una cuenta personal para compartir archivos. El aislamiento resuelve un problema —impedir que el contenido malicioso llegue al terminal—, pero la seguridad de los datos requiere la pila completa de SSE.

Se pasa por alto el caso de uso de dispositivos no gestionados. Muchas organizaciones adquieren RBI para terminales gestionados, pero descuidan a los contratistas y a los usuarios externos que utilizan dispositivos BYOD. Estos usuarios representan algunas de las sesiones de mayor riesgo. La norma NIST SP 800-46 Rev. 2 advierte explícitamente de que todos los componentes de las tecnologías de teletrabajo, incluidos los dispositivos cliente BYOD, deben protegerse contra las amenazas previstas, tal y como se identifican a través de los modelos de amenazas. RBI es una de las formas más prácticas de hacerlo sin necesidad de que los dispositivos estén inscritos en un sistema de gestión.

No integrar el aislamiento con la identidad. Una política de aislamiento genérica que trate a todos los usuarios por igual supone un desperdicio de recursos y resulta frustrante para los usuarios de bajo riesgo. Vincule las políticas de aislamiento a grupos de identidad, controles de acceso basados en roles y sistemas adaptativos de puntuación de riesgos. Es posible que un ejecutivo que navegue desde un dispositivo gestionado en la red corporativa no necesite aislamiento; sin embargo, ese mismo ejecutivo que navegue desde la red Wi-Fi de un hotel con una tableta personal debería quedar aislado automáticamente. El Informe global de respuesta a incidentes de Unit 42 para 2025 reveló que el 70 % de los incidentes implicaban tres o más vectores de ataque; por lo tanto, las políticas sensibles al contexto que tengan en cuenta la identidad, el dispositivo y el destino son esenciales para romper las cadenas de ataques multivectoriales.