En ciberseguridad, el viejo adagio 'confiar pero verificar' enfatiza que otorgar confianza siempre debe ir acompañado de supervisión. Sin embargo, con el software como servicio (SaaS), las organizaciones a menudo se detienen en la parte de 'confiar' y nunca llegan a la de 'verificar'. Los entornos SaaS en 2025 funcionan con confianza implícita. Una vez que un usuario o aplicación se autentica y recibe acceso, se confía en ellos en gran medida de forma indefinida. Los tokens emitidos a aplicaciones de terceros rara vez caducan, las integraciones suelen obtener más permisos de los necesarios y las automatizaciones se ejecutan con una supervisión humana mínima. Hablamos de los principios de confianza cero, pero en la práctica, muchas plataformas SaaS conceden una aprobación única y luego asumen que todo está bien. El resultado es una creciente brecha de seguridad, donde las credenciales y conexiones son implícitamente confiadas mucho más allá de lo seguro, creando un terreno fértil para filtraciones y abusos.

Confianza implícita en el ecosistema SaaS

Cada integración SaaS o token API representa una relación de confianza implícita entre su organización y algún servicio de terceros. Una vez que un usuario hace clic en 'Permitir' y concede acceso a una aplicación a su cuenta corporativa, esa aplicación es tratada efectivamente como una extensión confiable de su entorno. Esto no sería un problema si esa confianza se examinara continuamente, pero normalmente no es así. Considere los tokens OAuth que nunca se revocan o rotan: muchos pueden permanecer válidos durante meses o incluso años y, en algunos casos, a menos que un administrador los revoque explícitamente, pueden no caducar nunca. Esto significa que una aplicación conectada del año pasado, tal vez una herramienta de marketing o un complemento de productividad, aún podría tener acceso sin restricciones a sus datos hoy, incluso si nadie la usa activamente. Además, estas aplicaciones de terceros a menudo reciben muchos más permisos de los necesarios. Es común que una aplicación solicite ámbitos amplios (a veces el infame acceso 'permitir todo'), y los usuarios ocupados los conceden solo para que la herramienta funcione. Si una aplicación solo necesita acceso de lectura a un calendario, aún podría solicitar permisos de edición y eliminación, y recibirlos. Esta confianza implícita se extiende también a la automatización. Las empresas a veces dependen de bots y scripts de automatización para realizar tareas en aplicaciones en la nube, extrayendo datos, integrando sistemas, generando informes automáticos, etc. Estas automatizaciones se ejecutan usando claves API o tokens (credenciales de máquina) que conllevan muchos privilegios. Pero una vez configurados, tienden a ejecutarse con una supervisión mínima.

La brecha de confianza cero: la verificación solo ocurre una vez

La ironía de todo esto es que muchas organizaciones presumen de la filosofía de confianza cero, 'nunca confíes, siempre verifica', pero sus prácticas SaaS equivalen a 'confía una vez, luego nunca vuelvas a verificar'. Si un empleado instala una aplicación SaaS de terceros, hay una pantalla de autorización OAuth inicial, la única vez que se verifican los permisos y la identidad. Después de hacer clic en 'Permitir', la verificación se detiene. La aplicación recibe un token y ahora tiene acceso persistente en segundo plano. Por lo general, no hay ningún mecanismo integrado para volver a verificar la legitimidad o intención de ese token con cada uso. En efecto, los tokens OAuth y API otorgan confianza persistente entre aplicaciones sin más verificación. Su inicio de sesión único (SSO) y MFA pueden proteger la puerta principal para los inicios de sesión de usuarios, pero estos tokens evaden esos controles por completo. No hay ninguna ventana emergente para reautenticarse cuando una aplicación conectada usa su token para consultar datos; la aplicación simplemente presenta el token y se asume que es válido. En muchos casos, una vez que se aprueba una integración, ni siquiera hay una revisión anual para preguntar: '¿Todavía necesitamos este acceso?' o '¿Esta aplicación se comporta como se espera?'. El paso de 'verificar' de 'nunca confíes, siempre verifica' efectivamente termina el primer día. Después de eso, es un sistema de honor que los ciberdelincuentes están más que dispuestos a explotar.

Tokens y aplicaciones: el nuevo punto ciego en seguridad

Todos estos tokens no monitoreados y aplicaciones con exceso de privilegios han creado un punto ciego evidente en los programas de seguridad. Los equipos de seguridad tradicionalmente se destacan en monitorear inicios de sesión de usuarios, actividad de endpoints y tráfico de red, pero los tokens SaaS y las integraciones a menudo pasan desapercibidos para estas herramientas. Hemos visto esto en múltiples filtraciones a lo largo de los años. A principios de 2023, por ejemplo, Slack reveló que ciberdelincuentes robaron tokens de empleados y los usaron para acceder a repositorios de código internos, evitando la necesidad de cualquier inicio de sesión con contraseña. Por la misma época, CircleCI sufrió un incidente donde malware en la computadora portátil de un ingeniero robó un token de sesión, permitiendo a los intrusos hacerse pasar por ese ingeniero y robar secretos sensibles de clientes. En ambos casos, un token en las manos equivocadas socavó los controles de seguridad habituales. Avanzando hasta 2025, los atacantes se han vuelto aún más audaces. La filtración de Salesloft/Drift es un ejemplo claro: los ciberdelincuentes violaron un proveedor de chatbot SaaS (Drift) y robaron tokens OAuth para su integración con Salesforce. Esos tokens, destinados a permitir que el chatbot accediera a datos de Salesforce en nombre de los clientes, se convirtieron en llaves maestras. Otro grupo, ShinyHunters, tomó una ruta más social: engañaron a empleados mediante phishing/vishing para obtener acceso OAuth a cuentas SaaS de empresas. A mediados de 2025, atacaron a firmas como Google y Workday convenciendo a internos para que autorizaran una aplicación maliciosa o restablecieran una contraseña, otorgando así a los atacantes un punto de apoyo en Salesforce sin hackear el código de la plataforma. Una vez dentro, la aplicación maliciosa se comportaba como cualquier otra aplicación conectada, extrayendo datos hasta que era descubierta. Nuevamente, no había ninguna verificación continua de lo que esa aplicación estaba haciendo más allá del clic inicial de 'sí, confío en esta aplicación'.

Verificación continua: comportamiento sobre credenciales

En un modelo genuino de confianza cero, el acceso sirve como una evaluación continua en lugar de un punto de control único. La verificación continua se ocupa de la distinción entre privilegio otorgado y privilegio observado. El término 'privilegio otorgado' describe el acceso inicial que concedimos a un usuario o token, como 'esta clave API puede leer datos de clientes'. El término 'privilegio observado' describe cómo se usa realmente ese acceso. Por ejemplo, 'esta clave API normalmente lee 10 registros de un rango IP particular cada día entre las 9 a.m. y las 5 p.m.'. Al vigilar el comportamiento, podemos detectar casos en los que un token o aplicación se desvía de su uso o patrón previsto. Si esa clave API de datos de clientes de repente intenta exportar toda la base de datos a las 2 a.m., eso es una gran señal de alerta. Si una cuenta de servicio de integración normalmente tranquila comienza a acceder a registros financieros sensibles que nunca ha tocado antes, eso es motivo de investigación inmediata. En esencia, la verificación continua consiste en preguntarse continuamente: '¿Tiene sentido este comportamiento para esta identidad?'. El modelo CARTA (Evaluación Continua Adaptativa de Riesgo y Confianza) de Gartner encapsula este enfoque: 'nunca confíes, siempre verifica' de forma continua, en tiempo real, adaptándose a lo que el sistema observa. El objetivo es pasar de nuestro modelo de confianza estática actual a uno donde la confianza se gana y se vuelve a ganar constantemente mediante un buen comportamiento.

Conclusión: confía, pero verifica continuamente

El problema con 'confiar pero verificar' hoy no es que el lema sea incorrecto; es que no lo hemos seguido realmente. Confiamos y luego nos olvidamos de verificar. Para cerrar esta brecha de seguridad, deberíamos considerar adoptar la noción de que la confianza no es una decisión única. Cada acceso, ya sea humano o máquina, debe estar sujeto a preguntas: ¿Es normal esta solicitud? ¿Está justificado este uso de privilegio? Esta mentalidad convierte la confianza cero de un eslogan en una realidad operativa, y aquí es exactamente donde Reco cierra el círculo. Reco analiza continuamente los privilegios otorgados frente al comportamiento observado en identidades SaaS, tokens y aplicaciones de terceros. Identifica cuándo el comportamiento se desvía de lo normal, esperado o seguro. En lugar de depender de una confianza persistente ciega, Reco muestra aplicaciones con exceso de privilegios, tokens mal utilizados e integraciones que comienzan a operar fuera de su línea base. Aporta verificación en tiempo real a las partes del ecosistema SaaS donde la verificación ha estado históricamente ausente. Haga clic aquí para comenzar hoy: Solicite una demostración: Comience con Reco. Acerca del autor: Gal es cofundador y CPO de Reco. Gal es ex teniente coronel en la Oficina del Primer Ministro de Israel. Es un entusiasta de la tecnología, con experiencia como investigador de seguridad y hacker. Gal ha liderado equipos en múltiples áreas de ciberseguridad con experiencia en el elemento humano.