Página traducida y verificada automáticamente. Prevalece la versión en inglés. Algunas partes siguen en inglés mientras se verifica su traducción. Ver en inglés · Informar un error de traducción

DeepDive › Seguridad

Detección de ataques entre inquilinos

El cliente A sufrió una brecha. Investigación: no se propagó. El cliente B fue notificado tres semanas después.

Seguridad 5 min de lectura · 2 de agosto de 2026

Un proveedor de software de recursos humanos en la nube operaba una plataforma SaaS multiinquilino que atendía a más de trescientos clientes empresariales. Cuando uno de sus clientes más grandes sufrió una brecha, iniciada mediante una credencial de administrador comprometida, el equipo de respuesta a incidentes del proveedor investigó y contuvo la brecha en cuarenta y ocho horas. Su investigación concluyó que la brecha se había contenido en el inquilino afectado y no se había propagado a los datos de otros clientes. Esta conclusión se basó en el análisis de los registros de acceso a datos del inquilino afectado y en los controles de segmentación de red entre los entornos de los inquilinos. Tres semanas después, un segundo cliente se puso en contacto con el proveedor tras descubrir que una dirección IP desconocida había accedido a sus datos de recursos humanos. La investigación conjunta posterior reveló que el atacante inicial, tras obtener acceso al inquilino del primer cliente, había identificado una vulnerabilidad en la capa de aislamiento de inquilinos del proveedor: una configuración incorrecta en los controles de acceso a la base de datos compartida que permitía al atacante acceder a tablas específicas más allá de los límites entre inquilinos. La investigación inicial del proveedor había confirmado que el atacante no se había desplazado lateralmente por la red, lo cual era exacto, pero no había detectado que el atacante había accedido a datos de otros inquilinos a través de la capa de base de datos mal configurada. El enfoque de la investigación revisó los controles de red. El ataque explotó la capa de datos.

¿Cuál es realmente el problema de la detección de ataques entre inquilinos?

La detección de ataques entre inquilinos es el desafío de identificar cuándo un compromiso de seguridad que afecta al entorno de un cliente en una plataforma multiinquilino ha accedido, o tiene el potencial de acceder, a los entornos de otros clientes a través de componentes de la infraestructura compartida. Las plataformas multiinquilino comparten infraestructura para prestar servicios rentables: bases de datos compartidas, cómputo compartido, redes compartidas y componentes de middleware compartidos. Estos componentes compartidos crean posibles vías de acceso entre inquilinos cuando los controles de aislamiento que deberían impedir que un inquilino acceda a los datos de otro tienen vulnerabilidades o configuraciones incorrectas.

La brecha en la metodología de investigación es la falla de detección específica. Las investigaciones posteriores a una brecha en entornos multiinquilino suelen centrarse en el inquilino comprometido: analizan el acceso del atacante dentro del entorno de ese inquilino, confirman que el aislamiento de inquilinos en la capa de red resistió y determinan el alcance de los datos accedidos dentro del inquilino comprometido. Esta metodología de investigación identifica con exactitud el movimiento lateral en la capa de red. Puede pasar por alto el acceso entre inquilinos en la capa de datos, es decir, los ataques que explotan permisos mal configurados en la base de datos compartida, fallas en el control de acceso de la API u otras vulnerabilidades de la capa de datos para acceder a los datos de otros inquilinos sin realizar el movimiento lateral en la capa de red que la investigación busca.

El problema de la suposición sobre el aislamiento de inquilinos es la causa raíz. Las plataformas multiinquilino implementan el aislamiento de inquilinos en varias capas (red, aplicación y datos), y la metodología de investigación del equipo de seguridad tiende a revisar la capa en la que tiene más confianza. Un proveedor con un sólido aislamiento de red puede revisar esa capa a fondo y ser menos sistemático en las revisiones de la capa de datos. Un atacante que ha estudiado la arquitectura del proveedor sabe qué capa de aislamiento atacar para lograr el acceso entre inquilinos.

  • Investigación que revisa la capa de red mientras el ataque utilizó la capa de datos
  • La suposición sobre el aislamiento de inquilinos no se pone a prueba de forma exhaustiva después de una brecha
  • Aislamiento en varias capas no verificado: se confirmó la red, pero no se revisó la capa de datos
  • Notificación tardía al segundo inquilino: tres semanas de exposición no notificada para el Cliente B
  • El acceso entre inquilinos a través de la infraestructura compartida no figura en la lista de verificación de la investigación de brechas

Por qué es importante

La detección de ataques entre inquilinos es importante para TPRM porque los clientes de plataformas multiinquilino enfrentan un riesgo de brecha que se origina en el entorno de otro cliente, un riesgo que está completamente fuera de su control y que depende de la capacidad del proveedor para detectar el acceso entre inquilinos y notificar a los clientes afectados. El cliente que confía en la conclusión de la investigación del proveedor de que 'la brecha no se propagó' debe comprender qué metodología de investigación produjo esa conclusión y si esa metodología detectaría las técnicas específicas de acceso entre inquilinos pertinentes para la arquitectura del proveedor.

La consecuencia del retraso en la notificación es la dimensión regulatoria. Un retraso de tres semanas en notificar a un segundo cliente cuyos datos fueron accedidos significa un retraso de tres semanas en la respuesta a la brecha y en el cronograma de notificación regulatoria del propio segundo cliente. El plazo de notificación del GDPR del segundo cliente comienza cuando este tiene conocimiento, pero el inicio efectivo de su exposición se produjo cuando el atacante accedió a su inquilino, no cuando recibió la notificación tardía del proveedor.

Dónde se equivocan la mayoría de los equipos

La falla más constante es aceptar la garantía de contención de la brecha del proveedor sin comprender la metodología de investigación que produjo esa garantía. La contención entre inquilinos confirmada mediante el análisis de la capa de red no confirma la contención en la capa de datos.

  • Garantía de contención de la brecha aceptada sin revisar la metodología de investigación
  • Pruebas de aislamiento en varias capas no verificadas: capa de red frente a capa de datos frente a capa de aplicación
  • Sin auditoría por parte del cliente del acceso entre inquilinos a su propio inquilino durante la brecha de otro cliente
  • La revisión de los controles de acceso a la base de datos compartida no se activa ante el incidente de otro cliente
  • Alcance de la investigación del proveedor no revisado en busca de brechas metodológicas

Cómo se ve una buena práctica

Los protocolos maduros de respuesta a incidentes entre inquilinos investigan todas las capas de la infraestructura compartida (red, aplicación y datos) cuando se detecta una brecha en cualquier inquilino, y verifican explícitamente en cada capa que no se produjo acceso entre inquilinos.

  • Investigación entre inquilinos en varias capas: se revisan las capas de red, aplicación y datos
  • Revisión de los registros de acceso a la base de datos compartida de todos los inquilinos cuando se vulnera uno de ellos
  • Prueba de aislamiento entre inquilinos como paso estándar de la investigación de brechas
  • Notificación proactiva a los coinquilinos cuando la infraestructura compartida está involucrada en la investigación
  • Documentación de la arquitectura de aislamiento de inquilinos revisada en la investigación de brechas

Herramientas

Seguridad en la nube: plataformas de CSPM, SIEM nativo de la nube con visibilidad entre inquilinos

Las plataformas de gestión de la postura de seguridad en la nube que monitorean la infraestructura multiinquilino pueden ofrecer visibilidad del acceso entre inquilinos, al identificar cuándo se accede a componentes compartidos más allá de los límites entre inquilinos. Para los profesionales de TPRM, preguntar si el monitoreo de CSPM del proveedor abarca los intentos de acceso a datos entre inquilinos constituye una pregunta concreta sobre el monitoreo del aislamiento.

Desafíos de gobernanza

El desafío de gobierno de la detección entre inquilinos es el requisito de ampliar el alcance de la investigación. Cuando se detecta una brecha en un inquilino, investigar toda la infraestructura compartida en busca de accesos entre inquilinos requiere acceso a los entornos de todos los inquilinos, al que el equipo de investigación puede no tener acceso habitual y que puede plantear problemas de privacidad para otros clientes. La solución de gobierno es incorporar la verificación del aislamiento entre inquilinos a la lista de verificación estándar de investigación de brechas antes de que los incidentes lo exijan.

  • Solicitar la metodología de investigación entre inquilinos: qué se revisa cuando se vulnera cualquier inquilino
  • Preguntar si los registros de acceso a la base de datos compartida se revisan para todos los inquilinos durante una investigación
  • Solicitar la documentación de la arquitectura de aislamiento de inquilinos: qué se comparte y qué está aislado
  • Preguntar por la notificación proactiva a los coinquilinos cuando la infraestructura compartida está involucrada
  • Solicitar evidencia de pruebas de penetración entre inquilinos para los componentes de la infraestructura compartida

Si usted forma parte de un equipo pequeño

Con su proveedor multiinquilino más importante, haga dos preguntas. Primera: cuando se vulnera el inquilino de otro cliente en su plataforma, ¿cuál es su procedimiento de investigación para determinar si el compromiso accedió a los datos de algún otro inquilino? En concreto, ¿ese procedimiento revisa la capa de acceso a la base de datos y la capa de acceso a la aplicación, y no solo el movimiento en la capa de red? Segunda: si esa investigación identificara un riesgo de acceso entre inquilinos, ¿en qué momento nos notificarían, aunque la investigación no hubiera confirmado el acceso a nuestro inquilino específico? Esas dos preguntas revelan la profundidad de la investigación y el desencadenante de la notificación en las brechas de coinquilinos.

  • Preguntar por la metodología de investigación entre inquilinos: qué capas se revisan
  • Preguntar en qué momento se notifica a los coinquilinos durante la investigación de una brecha de un coinquilino
  • Solicitar una descripción general de la arquitectura de aislamiento de inquilinos
  • Preguntar por la visibilidad de los registros de acceso a la base de datos compartida durante las investigaciones

Qué exigir

Pregunte directamente:

"Cuando se vulnera el inquilino de otro cliente en su plataforma, ¿su procedimiento de investigación verifica específicamente si el atacante accedió a componentes de la infraestructura compartida, incluidas las capas de acceso a la base de datos, que podrían permitir el acceso a datos entre inquilinos? ¿En qué momento se nos notificaría?"

Evidencia que debe esperar

  • Lista de verificación de la investigación entre inquilinos: qué capas se verifican
  • Desencadenante y plazo de la notificación a los coinquilinos
  • Documentación de la arquitectura de aislamiento de inquilinos
  • Procedimiento de revisión de los controles de acceso a la base de datos compartida

A un proveedor que confirma el aislamiento de inquilinos se le debe preguntar qué metodología de investigación confirma el aislamiento después de una brecha; en concreto, si se verifica la capa de datos además de la capa de red. La arquitectura de aislamiento describe el diseño. La metodología de investigación describe cómo se verifica el aislamiento cuando un atacante pone a prueba el diseño.

Cómo demostrarlo

  • Registros de la metodología de investigación entre inquilinos
  • Documentación de la arquitectura de aislamiento de inquilinos
  • Procedimiento de notificación a los coinquilinos
  • Evidencia de pruebas de aislamiento en varias capas

Conclusión clave

La investigación confirmó que la brecha no se propagó a través de la red. El atacante utilizó la capa de base de datos. Ambas afirmaciones eran exactas al mismo tiempo. La metodología de investigación revisó una capa y confirmó la contención en esa capa. El atacante explotó una capa distinta. Tres semanas después, se notificó al Cliente B. La brecha había estado activa en su inquilino durante tres semanas después de la confirmación inicial de contención del proveedor. El aislamiento entre inquilinos requiere una investigación en varias capas: red, aplicación y datos. Una metodología de investigación que solo revisa la capa en la que el equipo tiene más confianza deja las demás capas como suposiciones sin verificar. Solicite la metodología de investigación. Confirme que todas las capas estén dentro del alcance.

Biblioteca de regulaciones

Todas las leyes estatales de privacidad de EE. UU., en un mapa

24 estados tienen una ley integral de privacidad en la biblioteca, junto con las leyes de la UE, del Reino Unido, federales de EE. UU. y globales: 102 en total, cada una explicada en palabras sencillas con sus fuentes. Seleccione un estado para ver qué se aplica allí.

  • En vigor
  • Entrada en vigor
  • Leyes sectoriales
AK ME VT NH WA ID MT ND MN IL WI MI NY RI MA OR NV WY SD IA IN OH PA NJ CT CA UT CO NE MO KY WV VA MD DE AZ NM KS AR TN NC SC DC OK LA MS AL GA HI TX FL