En 2023, una vulnerabilidad en una plataforma de transferencia de archivos en la nube de uso generalizado permitió a los atacantes desplazarse lateralmente por los entornos de los clientes, no irrumpiendo en cada inquilino por separado, sino explotando debilidades de la arquitectura de la plataforma que los conectaba. Miles de organizaciones se vieron afectadas. No tenían nada en común, salvo que todas confiaban en el mismo proveedor. Ninguna había evaluado si la arquitectura multiinquilino de ese proveedor ofrecía un aislamiento adecuado entre clientes. Ninguna había preguntado si un compromiso que afectara a otro cliente de la misma plataforma podía llegar a sus datos. La pregunta nunca había surgido, porque la mayoría de las organizaciones no piensa en los demás inquilinos que comparten la infraestructura de su proveedor. Hasta que no les queda otra opción.
¿Qué son realmente los riesgos de acceso entre inquilinos?
El riesgo de acceso entre inquilinos es la posibilidad de que los datos, las cargas de trabajo o el entorno de un cliente dentro de una plataforma en la nube multiinquilino puedan ser accedidos, afectados o comprometidos como consecuencia de la presencia de otro cliente en la misma plataforma, o como consecuencia de debilidades en los componentes compartidos de la plataforma que atienden a todos los inquilinos simultáneamente. Es una categoría de riesgo estructuralmente invisible en la mayoría de las evaluaciones de proveedores porque no surge de la relación del proveedor con usted en particular. Surge de la arquitectura del proveedor y del hecho de que usted comparte esa arquitectura con todos los demás clientes a los que atiende.
La arquitectura multiinquilino es el modelo económico fundamental del software en la nube. Un proveedor de SaaS no construye una instancia independiente de su plataforma para cada cliente: construye una plataforma y la divide de modo que cada cliente vea solo sus propios datos y su propia configuración. Esa división puede implementarse en muchos niveles: separación lógica dentro de una base de datos compartida, esquemas de base de datos independientes por inquilino, bases de datos independientes en infraestructura compartida o infraestructura totalmente aislada por inquilino. Las implicaciones de seguridad de cada enfoque son radicalmente distintas, y la mayoría de los clientes no tiene idea de qué modelo utilizan sus proveedores.
El riesgo no es teórico. La separación lógica, el modelo más común y económico, depende por completo de los controles de acceso de la capa de aplicación para impedir que un inquilino vea los datos de otro. Si esos controles contienen un error, una configuración incorrecta o una falla de diseño, la separación falla. Un investigador que consulta el ID de cliente equivocado en un punto de conexión de API mal validado, una herramienta de soporte que agrega datos de varios inquilinos sin un alcance adecuado o un proceso en segundo plano que trata registros sin aplicar los límites entre inquilinos: cualquiera de ellos puede provocar una exposición de datos entre inquilinos sin que intervenga ningún atacante. Cuando interviene un atacante real que busca deliberadamente estas debilidades, es mucho más probable que la exposición se descubra y se explote.
El riesgo entre inquilinos se manifiesta en varios patrones distintos de ataque y de falla:
- Referencias directas a objetos inseguras: API que aceptan identificadores de inquilinos o de recursos sin validar que el usuario solicitante pertenece a ese inquilino, lo que permite a un cliente consultar los datos de otro
- Vulnerabilidades de la infraestructura compartida: fallas en componentes compartidos por todos los inquilinos (servicios de autenticación, canales de registro, procesos en segundo plano) que afectan simultáneamente a todos los clientes cuando se explotan
- Escalamiento de privilegios entre inquilinos: comprometer una cuenta con pocos privilegios en la plataforma y usar ese punto de apoyo para escalar el acceso a otros inquilinos a través de interfaces administrativas compartidas o herramientas de soporte
- Efectos del vecino ruidoso: la actividad de un inquilino consume recursos compartidos de formas que degradan la disponibilidad o crean canales laterales basados en tiempos para otros inquilinos
- Acceso de soporte y administrativo: personal del proveedor con capacidad para acceder al entorno de cualquier inquilino con fines de soporte, lo que crea una capa de acceso compartida que elude los controles de seguridad de cada inquilino
Por qué es importante
El riesgo entre inquilinos es una de las dimensiones menos evaluadas del riesgo de terceros en la nube precisamente porque es invisible en el modelo de evaluación estándar. Un cuestionario para proveedores pregunta por las prácticas de seguridad del proveedor: su cifrado, sus controles de acceso, sus capacidades de respuesta a incidentes. No pregunta por los demás clientes que comparten la infraestructura del proveedor, ni por cómo el compromiso de uno de esos clientes podría abrir una vía hacia sus datos. Sin embargo, en una arquitectura multiinquilino, cada uno de los demás clientes de la plataforma forma parte, de forma indirecta, de su modelo de amenazas.
El cálculo del radio de impacto de un incidente entre inquilinos es fundamentalmente distinto del de una brecha dirigida contra un proveedor. Cuando se vulnera a un proveedor a través de una vulnerabilidad de su plataforma compartida, todos los clientes de esa plataforma pueden verse afectados simultáneamente, con independencia de su postura de seguridad individual, de su diligencia debida en la incorporación o de los controles que hayan implementado por su parte. No hay nada que un cliente pueda hacer dentro de su propio inquilino para impedir que se explote una vulnerabilidad entre inquilinos. La protección reside por completo en la arquitectura y la implementación del proveedor, sobre las que el cliente no tiene control directo.
Esto crea una obligación de diligencia debida específica que va más allá de la evaluación estándar de proveedores: evaluar la arquitectura multiinquilino del proveedor y sus mecanismos de aislamiento como un factor de riesgo en sí mismo. Un proveedor que trata datos de organizaciones muy atacadas (instituciones financieras, prestadores de servicios de salud, contratistas del gobierno) junto con clientes menos conscientes de la seguridad representa una propuesta de riesgo distinta a la de un proveedor con una base de clientes más homogénea. La sofisticación de los atacantes que se dirigen a un cliente de la plataforma puede afectar a todos los demás clientes si el aislamiento es insuficiente.
Dónde se equivocan la mayoría de los equipos
La falla más común es equiparar la separación a nivel de cuenta con el aislamiento de seguridad. La mayoría de los clientes entienden que tienen su propia cuenta, su propio inicio de sesión y su propio espacio de datos dentro de la plataforma de un proveedor. Interpretan que esto significa que sus datos están aislados de los de otros clientes. Lo que realmente han confirmado es que la interfaz de usuario de la aplicación solo les muestra sus propios datos en el funcionamiento normal, no que la arquitectura subyacente impida el acceso entre inquilinos en condiciones adversas. Son afirmaciones significativamente distintas, y la mayoría de las organizaciones nunca ha pedido a un proveedor que demuestre la segunda.
La segunda falla es no tener en cuenta el acceso del soporte del proveedor como factor de riesgo entre inquilinos. Prácticamente todos los proveedores de SaaS mantienen la posibilidad de que su personal de soporte acceda a los inquilinos de los clientes para investigar problemas, responder a solicitudes de soporte o realizar operaciones administrativas. Esa capa de acceso de soporte es una capacidad compartida que existe en todos los inquilinos simultáneamente. Si los controles de acceso internos del proveedor para esas herramientas de soporte son inadecuados, o si se compromete una cuenta del personal de soporte, la exposición no se limita a un inquilino. Puede abarcar toda la base de clientes.
- Aceptar 'los datos de nuestros clientes están separados lógicamente' como evidencia de un aislamiento adecuado sin comprender lo que eso significa a nivel arquitectónico
- Sin evaluación del modelo de aislamiento de inquilinos del proveedor (lógico, a nivel de esquema, a nivel de base de datos o a nivel de infraestructura) ni de las implicaciones de seguridad de cada uno
- No preguntar por el acceso del soporte del proveedor a su inquilino específico: quién puede acceder, en qué condiciones y con qué registro
- No considerar la composición de clientes de la plataforma del proveedor como un factor de riesgo: una plataforma que atiende a clientes muy atacados conlleva un riesgo entre inquilinos distinto al de una que atiende a pymes de bajo riesgo
- Tratar el riesgo entre inquilinos como una preocupación del proveedor de servicios en la nube en lugar de una preocupación sobre la arquitectura del proveedor
Cómo se ve una buena práctica
Las organizaciones con una evaluación madura del riesgo entre inquilinos tratan el aislamiento de inquilinos como una pregunta de primer orden en la diligencia debida sobre proveedores, no como algo secundario. Entienden que la arquitectura del proveedor es tan pertinente para su postura de seguridad como sus políticas, y hacen preguntas diseñadas para sacar a la luz cómo se implementa realmente el aislamiento, no solo si existe.
- Modelo de aislamiento de inquilinos documentado en los registros de evaluación del proveedor (separación lógica, a nivel de esquema, a nivel de base de datos o infraestructura dedicada), con una comprensión de lo que implica cada uno
- Controles de acceso del soporte del proveedor evaluados: quién en el proveedor puede acceder a su inquilino, mediante qué proceso de autorización y qué se registra cuando lo hace
- Historial de incidentes entre inquilinos revisado: si el proveedor ha sufrido alguna vez una exposición de datos entre inquilinos y, en tal caso, cuál fue su respuesta y qué cambios arquitectónicos se realizaron después
- Alcance de las pruebas de penetración confirmado: si las pruebas de seguridad del proveedor incluyen escenarios de ataque entre inquilinos y si los resultados están disponibles para los clientes
- Residencia y aislamiento de los datos definidos por contrato: el contrato especifica cómo se implementa el aislamiento de inquilinos y qué recursos existen si falla
Herramientas
La evaluación del riesgo entre inquilinos es principalmente una evaluación arquitectónica y de gobierno, más que un problema de herramientas. Sin embargo, varias herramientas facilitan las obligaciones de diligencia debida y monitoreo que genera para el cliente.
Gestión de la postura de seguridad de SaaS: AppOmni, Obsidian Security, Valence Security
Las herramientas de SSPM ofrecen visibilidad sobre cómo se configuran y utilizan las plataformas SaaS dentro del inquilino de un cliente. Sacan a la luz integraciones con privilegios excesivos, concesiones excesivas de acceso a datos y patrones de uso anómalos que pueden indicar una exposición entre inquilinos. Para los profesionales de TPRM, también aportan evidencia del monitoreo activo de la capa que pertenece al cliente dentro de las plataformas SaaS, lo que demuestra que la organización no confía pasivamente en las afirmaciones de aislamiento del proveedor.
Agentes de seguridad de acceso a la nube: Netskope, Microsoft Defender for Cloud Apps, Zscaler
Los CASB ofrecen visibilidad y control sobre los datos que entran y salen de las plataformas SaaS, incluida la detección de anomalías en los patrones de acceso a datos. En un incidente entre inquilinos, un CASB puede detectar volúmenes o patrones inusuales de acceso a datos antes de que el proveedor identifique el problema, lo que aporta una alerta temprana y evidencia para la respuesta a incidentes.
Plataformas de evaluación de la seguridad de proveedores: OneTrust, ProcessUnity, Vanta
Estas plataformas permiten realizar evaluaciones estructuradas de riesgos de proveedores que pueden configurarse para incluir preguntas específicas sobre el riesgo entre inquilinos. La clave es asegurarse de que la plantilla de evaluación vaya más allá del contenido estándar de un cuestionario de seguridad e incluya preguntas específicas de arquitectura sobre el aislamiento de inquilinos, los controles de acceso del soporte y el historial de incidentes entre inquilinos.
Programas de recompensas por errores y de divulgación de vulnerabilidades: HackerOne, Bugcrowd
Un proveedor con un programa activo de recompensas por errores que incluye escenarios de ataque entre inquilinos en su alcance ha asumido un compromiso público significativo de identificar estas vulnerabilidades. La existencia de un programa así, y el historial del proveedor en la respuesta a hallazgos entre inquilinos y su remediación, es una señal tangible de madurez en seguridad arquitectónica que va más allá de una declaración de políticas.
Desafíos de gobernanza
El desafío de gobierno del riesgo entre inquilinos es que queda fuera del modelo estándar de evaluación de riesgos de proveedores. La mayoría de los programas de TPRM evalúan los controles de seguridad del proveedor en cuanto se aplican a los datos y a la relación del cliente. El riesgo entre inquilinos requiere evaluar la arquitectura del proveedor en cuanto se aplica a toda la población de clientes, una evaluación más amplia y menos conocida que la mayoría de los marcos de evaluación no están diseñados para realizar.
La respuesta práctica es integrar la evaluación entre inquilinos en la clasificación por niveles y la diligencia debida de los proveedores como una dimensión de riesgo específica, ponderada según la sensibilidad de los datos tratados y la composición probable de la base de clientes del proveedor. Un proveedor que trata datos regulados altamente sensibles junto con muchos otros clientes justifica una diligencia debida arquitectónica más profunda que uno que maneja datos operativos de baja sensibilidad en una implementación dedicada.
- Añadir el aislamiento de inquilinos a su cuestionario estándar para proveedores como sección obligatoria para cualquier proveedor en la nube que trate datos sensibles
- Solicitar los informes de pruebas de penetración del proveedor, prestando especial atención a si se incluyeron escenarios de ataque entre inquilinos en el alcance
- Revisar las divulgaciones históricas de incidentes del proveedor en busca de cualquier evento de exposición de datos entre inquilinos: suelen minimizarse en las respuestas a los cuestionarios
- Exigir por contrato la notificación dentro de un plazo definido si el proveedor tiene conocimiento de cualquier vulnerabilidad o incidente entre inquilinos que pueda haber afectado a sus datos
- Considerar un arrendamiento dedicado para las relaciones con proveedores de mayor riesgo: algunos proveedores ofrecen, con un costo adicional, un aislamiento a nivel de infraestructura que elimina por completo el riesgo de los componentes compartidos
Si usted forma parte de un equipo pequeño
Comience por identificar cuáles de sus proveedores de SaaS tratan sus datos sensibles de mayor criticidad en un entorno multiinquilino compartido. Para esos proveedores, añada tres preguntas a su próxima conversación de evaluación: cómo se implementa el aislamiento de inquilinos a nivel de arquitectura, quién en el proveedor puede acceder a su inquilino específico y en qué condiciones, y si el proveedor ha sufrido alguna vez una exposición de datos entre inquilinos. Las respuestas le dirán si el riesgo se está gestionando o simplemente se está dando por resuelto.
- Revise el lenguaje sobre aislamiento de datos de sus contratos con proveedores: las referencias vagas a una 'separación lógica' sin detalles arquitectónicos son una brecha que conviene abordar
- Pregunte a sus proveedores de SaaS de mayor sensibilidad si ofrecen arrendamiento dedicado y a qué costo: vale la pena evaluarlo para sus relaciones más críticas
- Habilite todos los registros de auditoría que sus plataformas SaaS ofrezcan para su propio inquilino: no impedirán los incidentes entre inquilinos, pero le ayudarán a detectarlos y responder a ellos
- Compruebe si sus proveedores SaaS críticos tienen programas activos de recompensas por errores y si las vulnerabilidades entre inquilinos están dentro de su alcance
Qué exigir
Pregunte directamente:
"¿Cómo se implementa el aislamiento de inquilinos en la arquitectura de su plataforma? ¿Se trata de una separación lógica dentro de una base de datos compartida, una separación a nivel de esquema, bases de datos independientes o infraestructura dedicada por cliente?"
"¿En qué condiciones puede su personal de soporte o de ingeniería acceder a nuestro inquilino específico, qué autorización se requiere y qué se registra cuando lo hace?"
"¿Su plataforma ha sufrido alguna vez una exposición de datos o una vulnerabilidad entre inquilinos? En tal caso, ¿cuál fue el impacto, cuál fue su respuesta y qué cambios arquitectónicos realizaron?"
Evidencia que debe esperar
- Una descripción arquitectónica clara del aislamiento de inquilinos: no una declaración de marketing, sino una explicación técnica
- Documentación de los controles de acceso del soporte, incluidos los requisitos de autorización y el registro de auditoría
- Informes de pruebas de penetración o resúmenes ejecutivos que confirmen que se probaron escenarios entre inquilinos
- Compromisos contractuales de aislamiento de datos con recursos definidos si el aislamiento falla
Un proveedor que responde a la pregunta sobre el aislamiento con 'sus datos están completamente seguros en su cuenta' ha descrito la experiencia del usuario, no la arquitectura. Insista en obtener la respuesta técnica.
Cómo demostrarlo
El riesgo entre inquilinos se reconoce cada vez más en los marcos regulatorios como una dimensión de la diligencia debida sobre los proveedores de servicios en la nube. Demostrar que su organización ha evaluado este riesgo, y no solo aceptado las garantías del proveedor, requiere evidencia documentada de una evaluación arquitectónica, no solo de haber completado un cuestionario.
- Registros de evaluación de proveedores que documentan el modelo de aislamiento de inquilinos de cada plataforma SaaS que trata datos sensibles
- Evidencia de la revisión del historial de incidentes entre inquilinos como parte de la diligencia debida sobre el proveedor
- Cláusulas contractuales que especifican los compromisos de aislamiento de inquilinos y las obligaciones de notificación de violaciones de datos
- Registros de la revisión del alcance de las pruebas de penetración que confirman que se incluyeron escenarios entre inquilinos
- Documentación de las decisiones en todos los casos en que se evaluó un arrendamiento dedicado y se adoptó o se descartó con una justificación documentada
Conclusión clave
Cada proveedor que usted utiliza en un entorno de nube multiinquilino lo conecta, de forma indirecta pero significativa, con todos los demás clientes de esa plataforma. Su postura de seguridad dentro de su propio inquilino es irrelevante si la arquitectura que lo separa de los demás inquilinos es inadecuada. No puede salir de una vulnerabilidad entre inquilinos aplicando parches, no puede sortearla mediante configuración y no puede llegar a la seguridad mediante evaluaciones sin preguntar específicamente cómo funciona el aislamiento y si alguna vez ha fallado. El riesgo entre inquilinos no es exótico: es una característica estructural de toda plataforma multiinquilino de la que usted depende. La única pregunta es si lo ha evaluado.