Protección de aplicaciones SaaS mediante controles a nivel del navegador

Su CASB impide que un colaborador externo descargue una lista de clientes de Salesforce a un ordenador portátil no gestionado. Cinco segundos después, ese mismo contratista selecciona toda la tabla, la copia al portapapeles, la pega en una ventana de redacción de Gmail personal y hace clic en Enviar. El CASB nunca lo detecta. El navegador sí lo hizo, y con los controles adecuados, podría haberlo impedido. Esta guía orienta a los administradores de seguridad de SaaS y a los operadores de CASB a través de un enfoque por fases para cerrar esa brecha mediante la aplicación de controles a nivel del navegador: remote browser isolation (RBI), políticas secure web gateway SWG), DLP y acciones de sesión— sobre las implementaciones CASB existentes.

Requisitos previos: lo que debe tener preparado antes de empezar

Antes de habilitar los controles a nivel del navegador, compruebe que su entorno cumple cuatro requisitos básicos. Si se omiten, se producirán conflictos en las políticas, frustración entre los usuarios y una cobertura incompleta.

1. CASB con modos de proxy directo e inverso ya implementados. Necesita la inspección de tráfico en línea para las aplicaciones SaaS autorizadas (proxy inverso) y la visibilidad de la TI en la sombra (proxy directo) como base para la aplicación de políticas. Si su implementación de CASB es solo a través de API, carece de la ruta en línea que proporcionan los controles del navegador.

2. Motor de políticas DLP unificado. Los controles a nivel del navegador deben basarse en las mismas clasificaciones de datos —información de identificación personal (PII), información médica protegida (PHI), registros financieros, código fuente, propiedad intelectual— que utilizan sus políticas DLP de CASB y de correo electrónico. Si sus definiciones DLP se encuentran en silos separados, comience por consolidarlas. Una clasificación incoherente da lugar a que un canal bloquee lo que otro permite. Una plataforma DLP centralizada evita esta fragmentación.

3. Integración con el proveedor de identidad (IdP) y evaluación del estado del dispositivo. Los controles del navegador resultan mucho más útiles cuando se adaptan en función de quién es el usuario y qué dispositivo está utilizando. Un colaborador de marketing que utilice un MacBook personal debería estar sujeto a controles más estrictos que un analista financiero a tiempo completo que utilice un terminal Windows gestionado. Para ello, es necesario establecer una federación SAML/OIDC con su IdP y realizar comprobaciones del estado del dispositivo (gestionado frente a no gestionado, nivel de parches del sistema operativo, estado del cifrado del disco).

4. Inventario de aplicaciones SaaS con clasificación de sensibilidad. No es posible definir el alcance de las políticas de navegador sin saber qué aplicaciones SaaS contienen datos sensibles. Clasifique sus 20 o 50 aplicaciones SaaS principales según el nivel de sensibilidad de los datos (crítico, alto, medio, bajo). Las «Mejores prácticas de gobernanza de SaaS» de la CSA recomiendan evaluar los riesgos durante todas las etapas del ciclo de vida del SaaS: evaluación, adopción, uso y rescisión. Este inventario servirá de base para definir el alcance de sus políticas.

Fase 1: Cerrar la brecha entre el portapapeles y las descargas en escenarios de alto riesgo

Empiece por donde el riesgo es mayor y el número de usuarios es menor: los dispositivos no gestionados que acceden a aplicaciones SaaS confidenciales.

El escenario que justifica la Fase 1: un auditor externo inicia sesión en su instancia de Workday desde un ordenador portátil personal mediante SSO. Su proxy inverso CASB autentica la sesión y bloquea las descargas de archivos según la política. Sin embargo, el auditor abre un informe de remuneración de empleados, selecciona treinta filas de datos salariales, las copia, abre una nueva pestaña en una hoja de cálculo personal de Google Sheets y las pega. El CASB detectó una sesión autenticada de Workday y una sesión de Google Sheets: dos eventos independientes y permitidos por separado. Nunca detectó el movimiento de datos entre ambas, ya que la operación del portapapeles se realizó íntegramente dentro del contexto de renderización del navegador.

Qué implementar: Active remote browser isolation todas las sesiones de dispositivos no gestionados que accedan a aplicaciones SaaS de Nivel 1 (crítico) y Nivel 2 (alto). El aislamiento remoto del navegador (RBI) ejecuta la aplicación SaaS en un contenedor alojado en la nube y transmite únicamente píxeles al navegador del usuario. Esta arquitectura le ofrece un control detallado sobre las acciones de la sesión:

Restricción de copiar/pegar: Bloquee las operaciones de lectura y escritura en el portapapeles desde la sesión aislada, o permita pegar desde el exterior pero bloquee copiar hacia el exterior para evitar que los datos salgan del contexto de la aplicación SaaS.

Supresión de descargas: impida por completo la descarga de archivos desde la sesión renderizada o restrinja las descargas a tipos de archivo específicos.

Bloqueo de impresión: Desactive los comandos de impresión y de impresión a PDF.

Marcas de agua en capturas de pantalla: inserte una marca de agua visible o forense que contenga el correo electrónico del usuario y la marca de tiempo en el flujo de datos procesado, con el fin de disuadir la realización de capturas de pantalla.

La norma NIST SP 800-53, sección 7, exige aislar los componentes del sistema mediante mecanismos de protección de límites para controlar los flujos de información y limitar los posibles daños derivados de ataques hostiles y errores. RBI crea precisamente este límite entre los datos de la aplicación SaaS y el dispositivo local del usuario, aplicando controles de flujo de información que un proxy de red no puede garantizar.

Limitación del alcance: aplique estas medidas de control únicamente a los dispositivos no gestionados y al personal subcontratado en la Fase 1. Los terminales gestionados que cuenten con un agente instalado y un estado de seguridad verificado pueden estar sujetos a medidas de control menos estrictas (como la aplicación de marcas de agua sin bloqueo del portapapeles) para mantener la productividad.

Fase 2: Ampliar la protección DLP del navegador a los dispositivos gestionados y ofrecer una mayor cobertura de SaaS

Una vez que la fase 1 se haya estabilizado —por lo general, tras unas 4 a 6 semanas de recopilación de datos de telemetría y ajuste de políticas—, amplíe la cobertura a los dispositivos gestionados y a un conjunto más amplio de aplicaciones SaaS.

El escenario que justifica la Fase 2: un representante de ventas a tiempo completo, que utiliza un ordenador portátil gestionado, accede a Salesforce a través de Chrome. Abre el registro de una cuenta de cliente, copia el nombre, la empresa y el número de teléfono del contacto, y luego los pega en ChatGPT para generar un correo electrónico de contacto personalizado. No se ha descargado ningún archivo. No se ha infringido ninguna regla de uso compartido de Salesforce. Sin embargo, la información de identificación personal del cliente acaba de salir de su entorno SaaS controlado y ha entrado en una herramienta de IA de terceros a través del portapapeles del navegador.

Según el informe «State of SaaS Security Report (2025)» de CSA, el 63 % de las organizaciones señala que se produce un intercambio excesivo de datos con el exterior, y el 56 % afirma que los empleados suben datos confidenciales a aplicaciones SaaS no autorizadas —a menudo precisamente a través de esas rutas de portapapeles y subida que los controles tradicionales no detectan—. El control de prevención de pérdida de datos (DLP) a nivel del navegador es el mecanismo que intercepta estas acciones antes de que los datos lleguen al destino no autorizado.

Qué implementar:

SWG ha aplicado la inspección DLP en los terminales gestionados. Su secure web gateway intercepta el tráfico del navegador y aplica la clasificación DLP a los datos en tránsito, incluyendo el envío de campos de formulario, los eventos de pegado del portapapeles en aplicaciones web y las cargas de archivos a través del navegador. De este modo, se detecta el caso anterior de Salesforce a ChatGPT.

RBI selectivo para categorías sensibles. En lugar de aislar toda la navegación, se deben redirigir las sesiones hacia las aplicaciones SaaS de Nivel 1 y Nivel 2 a través de RBI cuando el comportamiento del usuario active una señal de riesgo (por ejemplo, al acceder a un objeto de datos de clientes, al abrir una vista de exportación o al navegar hacia una herramienta de IA con credenciales corporativas).

Marcas de agua para disuadir la grabación de sesiones. Aplique marcas de agua visibles a las sesiones en las que se muestren datos confidenciales, de modo que, si un usuario fotografía su pantalla, la marca de agua permita rastrear la imagen hasta un usuario, una sesión y una marca de tiempo concretos.

Principio de diseño de políticas extraído de la norma NIST SP 800-53 AC 4: Se pueden emplear mecanismos de control de acceso a nivel de aplicación y de servicio para proporcionar una mayor seguridad de la información y controlar los flujos de información más allá de lo que logran los controles a nivel de red. Las soluciones DLP y RBI a nivel de navegador operan precisamente en este nivel de aplicación y de servicio, añadiendo un control que los proxies CASB a nivel de red no pueden alcanzar.

Fase 3: Integrar los controles del navegador en su estructura de políticas de SSE

La implementación de controles de navegador como una capa independiente genera una sobrecarga operativa: políticas separadas, consolas separadas, colas de incidencias separadas. La Fase 3 unifica la aplicación de políticas a nivel de navegador con su Security Service Edge (SSE), de modo que un único motor de políticas rija las decisiones de CASB, SWG, DLP, RBI y ZTNA.

El escenario que justifica la Fase 3: su SOC recibe tres alertas: una alerta de CASB indicando que un usuario ha accedido a una aplicación SaaS paralela, una alerta de SWG indicando que la sesión del navegador de ese mismo usuario ha activado una coincidencia con un patrón de DLP, y una alerta de RBI indicando que se ha bloqueado una copia del portapapeles. Tres consolas, tres analistas, tres tickets... todo ello por una sola secuencia de acciones realizada por un único usuario. La política de SSE unificada agrupa todo esto en un único evento correlacionado con un único flujo de trabajo de respuesta.

Qué implementar:

Reglas de política unificadas que tienen en cuenta la identidad del usuario, el estado del dispositivo, el nivel de confidencialidad de la aplicación SaaS, la clasificación de los datos y el tipo de acción del navegador (descarga, portapapeles, impresión, carga) en una única instrucción condicional.

Aislamiento adaptativo que eleva automáticamente una sesión al nivel RBI completo cuando la plataforma SSE detecta una combinación de señales —como, por ejemplo, un dispositivo no gestionado que accede a una aplicación de nivel 1 mientras que el sistema DLP detecta contenido confidencial en la página—.

Envío de datos de telemetría de sesión al SIEM/SOAR para que los eventos a nivel del navegador (bloqueos del portapapeles, inserción de marcas de agua, supresión de descargas) sean visibles junto con los eventos de CASB, SWG y ZTNA, con el fin de facilitar la correlación y la investigación.

El Modelo de Madurez de Zero Trust de la CISA insta a las organizaciones a gestionar y proteger las aplicaciones implementadas mediante controles de acceso granulares y protecciones integradas contra amenazas, con el fin de alcanzar una madurez óptima en los pilares de «Aplicaciones y cargas de trabajo» y «Datos». La integración de controles a nivel del navegador en la política de SSE es la forma de poner en práctica esas directrices para las aplicaciones SaaS a las que se accede a través del navegador.

Puntos de integración: dónde se conectan los controles del navegador con su infraestructura actual

Los controles a nivel del navegador no sustituyen a las herramientas de seguridad existentes, sino que cubren las lagunas de aplicación que existen entre ellas. Defina claramente los puntos de integración para evitar duplicidades y garantizar una cobertura completa.

Consideremos una secuencia de integración en el mundo real: una organización sanitaria utiliza el modo API de CASB para analizar la información médica protegida (PHI) almacenada en Box y aplicar políticas de uso compartido. Sin embargo, cuando una enfermera especializada abre un documento de un paciente a través del navegador en su tableta personal, el análisis de la API ya se ha ejecutado, por lo que no impedirá que se copie el diagnóstico del paciente desde el portapapeles a una aplicación de mensajería. Una sesión de RBI con restricciones del portapapeles y marcas de agua subsana esa laguna sin necesidad de instalar un agente de terminal en la tableta personal. El enfoque Skyhigh Security para proteger las aplicaciones en la nube frente a dispositivos no gestionados aborda precisamente este caso de uso al combinar proxy inverso, RBI y DLP en una política integrada.

Indicadores y criterios de éxito

Los controles a nivel del navegador generan datos de telemetría que las implementaciones anteriores basadas únicamente en CASB no podían proporcionar. Defina las métricas antes de la implementación para poder demostrar el valor añadido y ajustar las políticas.

Indicadores operativos (seguimiento semanal):

Eventos de bloqueo del portapapeles por usuario, aplicación o tipo de dispositivo. Un aumento repentino de los bloqueos del portapapeles en un usuario concreto puede indicar un intento de fuga de datos o bien señalar que la política es demasiado restrictiva para un flujo de trabajo legítimo. Investigue los casos atípicos.

Descargue los eventos de supresión. Realice un seguimiento por aplicación SaaS y función del usuario. Un gran volumen de descargas bloqueadas procedentes de una aplicación concreta puede indicar que los usuarios necesitan una alternativa segura (por ejemplo, un visor de solo lectura o un flujo de trabajo de exportación controlado).

Las marcas de agua han dado lugar a investigaciones. Cuente cuántas veces se ha podido rastrear a un usuario a partir de una captura de pantalla o un documento impreso con marca de agua en el marco de una investigación. Incluso un número reducido demuestra su efecto disuasorio.

Solicitudes de excepciones a las políticas. Realice un seguimiento del número de usuarios que solicitan excepciones a los controles del navegador y de los motivos alegados. Un volumen elevado de excepciones para una aplicación concreta indica que es necesario ajustar la política.

Indicadores de reducción de riesgos (seguimiento trimestral):

Reducción de los incidentes relacionados con datos sensibles que afectan al portapapeles o a las rutas de carga de aplicaciones SaaS. Compare el volumen de incidentes antes y después de la implementación de controles en el navegador para las mismas aplicaciones SaaS y los mismos grupos de usuarios.

Cobertura del control de sesiones de dispositivos no gestionados. Mida el porcentaje de sesiones SaaS de dispositivos no gestionados que pasan por el RBI frente a las que lo eluden. El objetivo es alcanzar una cobertura superior al 95 % para las aplicaciones de nivel 1.

Tiempo medio de detección de intentos de exfiltración a través del navegador. La telemetría del navegador debería reducir el tiempo de detección de días (cuando se depende de alertas de análisis DLP a posteriori) a segundos (bloqueo del portapapeles en tiempo real).

El informe DBIR 2025 de Verizon reveló que el 60 % de las filtraciones de datos implicaban un factor humano: el usuario haciendo clic, copiando, subiendo y pegando. Los controles a nivel del navegador generan datos de telemetría de cumplimiento precisamente sobre estas acciones humanas, lo que proporciona a su SOC visibilidad sobre un vector que los controles de red y API pasan por alto por completo. Por su parte, Forrester informa de que aproximadamente una de cada cinco violaciones de datos se deriva de incidentes internos (2026), y los controles de sesión del navegador proporcionan un cumplimiento directo y en tiempo real frente al portapapeles y las rutas de carga que los usuarios internos explotan con mayor frecuencia.

Errores habituales

Error n.º 1: Implementar el aislamiento RBI completo para todos los usuarios desde el primer día. El aislamiento total de la transmisión de píxeles altera la experiencia de navegación. La latencia aumenta ligeramente, algunas extensiones del navegador dejan de funcionar y las aplicaciones web complejas pueden mostrarse de forma diferente. Si se aplica esto a 5.000 empleados a la vez, el servicio de asistencia técnica se rebelará y la dirección cancelará el proyecto. Empiece por los dispositivos no gestionados y las aplicaciones de alto riesgo. Amplíe la implementación de forma gradual.

Error 2: Aplicar políticas de navegador idénticas a dispositivos gestionados y no gestionados. Un ordenador portátil de un colaborador externo no gestionado requiere el bloqueo total del portapapeles y la restricción de descargas. Un terminal corporativo gestionado con un agente, cifrado de disco verificado y parches actualizados puede que solo necesite marcas de agua y restricciones selectivas al pegar. Diferencie las políticas según el estado de los dispositivos. El perfil de riesgo de una credencial comprometida en un dispositivo gestionado con EDR es fundamentalmente diferente al de una credencial en un dispositivo no gestionado sin visibilidad; sus políticas de navegador deben reflejar esa asimetría.

Error n.º 3: Ignorar los destinos de las herramientas de IA en la política de DLP. Muchas organizaciones han configurado el DLP del navegador para bloquear las subidas a las categorías tradicionales de «TI en la sombra» —almacenamiento personal en la nube, correo web—, pero se han olvidado de incluir los asistentes de IA. Las herramientas de IA se encuentran ahora entre los destinos no autorizados más habituales para los datos pegados y subidos. Actualice las categorías de URL de su SWG y DLP para incluir los servicios de IA generativa, y aplique las mismas restricciones al portapapeles y a las subidas que aplica a otras aplicaciones no autorizadas.

Error n.º 4: Tratar los controles del navegador como un proyecto independiente en lugar de como una extensión de la política de SSE. Si los controles del navegador se alojan en una consola independiente con políticas separadas, se convierten en una herramienta más que el SOC ignora. Integre estos controles en su plataforma de SSE a partir de la fase 3, de modo que los eventos del navegador se correlacionen con los eventos de CASB, SWG y ZTNA en un único flujo de trabajo de incidentes.

Error n.º 5: No clasificar las aplicaciones SaaS según su nivel de sensibilidad antes de redactar las políticas. Sin un inventario de SaaS clasificado por niveles de sensibilidad, se corre el riesgo de bloquear en exceso (aislando aplicaciones de bajo riesgo y frustrando a los usuarios) o de bloquear de forma insuficiente (dejando aplicaciones críticas sin controles). Las grandes empresas utilizan habitualmente entre decenas y cientos de servicios SaaS, y la clasificación no es opcional: es la base de una política específica que evita tanto las brechas de seguridad como el descontento de los usuarios.