El aislamiento de tenants es una disciplina de muros dentro de sistemas compartidos: controles que mantienen a cada tenant sellado frente a todos los demás. El punto que la mayoría de las explicaciones entierra merece el primer párrafo: el aislamiento no es autenticación ni autorización. Un usuario perfectamente logueado y con el rol correcto todavía puede leer los datos de un competidor si nada acota la consulta — el aislamiento es la tercera capa, la que decide en qué universo ocurre cada operación.
Puntos clave
| Pregunta | Respuesta |
|---|---|
| Qué es | Las garantías de que ningún tenant alcanza los datos o recursos de otro |
| No confundir con | Autenticación (quién) y autorización (qué) — el aislamiento es de quién |
| Dónde van los muros | Filas de la base, cachés, colas, storage, tokens — toda capa compartida |
| El modo de falla | Una consulta, job o clave de caché sin acotar = fuga de datos entre tenants |
| El estándar | Aplica en la capa de datos; prueba adversarialmente; nunca confíes en IDs de tenant enviados por el cliente |
El bug, y el muro que le sobrevive
-- El bug al que el aislamiento existe para sobrevivir: una query que olvidó su tenant
SELECT * FROM invoices WHERE id = $1; -- devuelve la factura de cualquiera
-- Con el muro en la capa de datos, el mismo bug devuelve nada:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_wall ON invoices
USING (tenant_id = current_setting('app.tenant')::uuid);En las bases de documentos el muro se construye con roles y control de acceso por objeto — el tenant es un rol, y cada fila queda sellada a él en el momento de la escritura:
// JavaScript / Node.js — Back4app JS SDK
// Provisioning a tenant boundary: a role is the tenant, membership is access
const tenantRole = new Parse.Role('tenant-acme', new Parse.ACL());
tenantRole.getUsers().add(adminUser);
await tenantRole.save();
// Every acme row from now on: readable and writable by the role only
const doc = new Parse.Object('Project', { name: 'Q3 Launch' });
const acl = new Parse.ACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// Flutter / Dart — Back4app Flutter SDK
// Every tenant row: readable and writable by the tenant role only
final acl = ParseACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
final doc = ParseObject('Project')
..set('name', 'Q3 Launch')
..setACL(acl);
await doc.save(); // invisible to every other tenant, enforced server-side// iOS / Swift — Back4app Swift SDK
// Every tenant row: readable and writable by the tenant role only
var acl = ParseACL()
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
var doc = Project()
doc.name = "Q3 Launch"
doc.ACL = acl
doc.save { _ in } // invisible to every other tenant, enforced server-side// Android / Kotlin — Back4app Android SDK
// Every tenant row: readable and writable by the tenant role only
val acl = ParseACL().apply {
setRoleReadAccess("tenant-acme", true)
setRoleWriteAccess("tenant-acme", true)
}
val doc = ParseObject("Project").apply {
put("name", "Q3 Launch")
setACL(acl)
}
doc.saveInBackground() // invisible to every other tenant, enforced server-sideLa pila de enforcement
Cada capa atrapa lo que la de arriba deja caer: el token establece la identidad del tenant en el servidor, el código de la aplicación acota por hábito, la capa de datos aplica por política y la infraestructura pone namespace a todo lo demás que se comparte. El cheat sheet de OWASP es el checklist canónico de la pila completa.
Aislamiento vs. autenticación vs. autorización
| Pregunta que responde | Mecanismo | La falla se ve como |
|---|---|---|
| ¿Quién eres? (autenticación) | Login, sesiones, tokens | Un impostor entra |
| ¿Qué puedes hacer? (autorización) | Roles, permisos | Un usuario excede su rol |
| ¿De quién son estos datos? (aislamiento) | Alcance de tenant + muros en la capa de datos | Un usuario válido lee a otro tenant |
La tercera fila es la que produce titulares, porque pasa todas las pruebas que las dos primeras definen: el atacante inicia sesión legítimamente, usa operaciones permitidas — y atraviesa un muro que falta. Las vulnerabilidades entre tenants canónicas de la era de la nube (la clase ChaosDB de hallazgos de investigación, donde un tenant podía derivar acceso a las bases de otros) fueron todas fallas de tercera fila en sistemas con primera y segunda filas impecables.
De dónde vienen realmente las fugas
- El filtro olvidado — una consulta sin su alcance de tenant; la razón de que los muros pertenezcan a la capa de datos, no a la memoria del desarrollador.
- IDOR — IDs secuenciales o adivinables obtenidos sin verificación de tenant; cambia un ID, lee el registro de un extraño.
- Ejecución fuera de contexto — jobs en segundo plano, webhooks, tareas programadas y exportaciones de datos corriendo con credenciales amplias y sin contexto de tenant.
- Servicios compartidos sin acotar — claves de caché, índices de búsqueda y rutas de archivo sin el prefijo del tenant; el muro de la base sigue en pie mientras la caché fuga.
- Pipelines paralelos — analítica y reportes leyendo la base directamente, por debajo de toda verificación de la aplicación.
- Tenant confiado al cliente — un ID de tenant aceptado del cuerpo de la solicitud en vez de derivado de la sesión; la forma más educada posible de entregar los datos de los demás tenants.
Aislamiento de seguridad vs. noisy neighbors
Misma palabra, dos problemas. El aislamiento de seguridad mantiene al tenant A fuera de los datos del tenant B. El aislamiento de rendimiento — el problema del noisy neighbor (vecino ruidoso) — mantiene la importación masiva del tenant A fuera de la latencia de checkout del tenant B, y se resuelve con cuotas, rate limits y particionamiento, cubierto en el lado de arquitectura de este tema. Un sistema puede ser hermético y aun así dejar que un tenant asfixie al resto; presupuesta para ambos, y no dejes que una discusión de cuotas se haga pasar por revisión de seguridad.
Cómo probar el aislamiento de tenants
La pasada adversarial de dos tenants, automatizada en CI: crea los tenants A y B e intenta todos los cruces — los IDs de objetos de B por la sesión de A en cada endpoint (el barrido de IDOR), el token de A contra los recursos de B, las superficies fuera de la ruta principal (exportaciones, paneles de admin, jobs) con el contexto de cada tenant, y una inspección de claves de caché, URLs de archivos y resultados de búsqueda en busca de alcance de tenant faltante. Agrega el caso del contexto sin definir: ningún tenant en la sesión debería significar ninguna fila, nunca todas. Un aislamiento que no ha sido atacado en CI es una hipótesis con certificado de compliance.
Casos de uso comunes
- SaaS B2B. Cada workspace es un tenant; el aislamiento es la promesa de producto debajo de cada feature.
- Plataformas que hospedan apps de clientes. Dos altitudes a la vez — la plataforma aísla las apps entre sí, cada app aísla a sus propios tenants.
- Tiers enterprise y regulados. Exigencias contractuales de aislamiento mapeadas a muros más fuertes — claves por tenant, recursos dedicados — para las cuentas que las requieren.
- Agencias y productos white-label. Un deploy, muchas organizaciones cliente, cada una sellada.
- Plataformas internas multi-equipo. Departamentos como tenants; modelo de amenaza más amigable, mecánica idéntica.
¿Cuánto aislamiento? Matriz de decisión
| Pool + muros en la capa de datos cuando… | Separación más fuerte cuando… |
|---|---|
| Muchos tenants pequeños, sensibilidad estándar | Los contratos nombran requisitos de aislamiento |
| El costo por tenant debe quedar cerca de cero | Los datos de un tenant exigen claves o región propias |
| Los muros se aplican (RLS/ACLs) y se prueban | Los argumentos de radio de daño vencen a la economía de densidad |
| Un ciclo de update debe cubrir a todos | El restore por tenant es una feature prometida |
| El equipo puede mantener pruebas adversariales | Los auditores quieren fronteras que puedan señalar |
El encuadre honesto: pool con muros aplicados y probados es aislamiento legítimo — la mayor parte de la industria corre así. Sube tenants individuales por la escalera de separación cuando sus requisitos, y no la moda, lo exijan.
Limitaciones y trade-offs
- El aislamiento es transversal para siempre. Cada feature nueva — caché, cola, exportación, búsqueda — vuelve a hacer la pregunta del tenant; la disciplina nunca termina.
- Los muros en la capa de datos tienen letra chica operativa. Contexto de sesión vs. connection pooling, roles con bypass de políticas y modos de dump — la entrada de seguridad a nivel de fila los cataloga.
- El radio de daño compartido sobrevive a la corrección. Un aislamiento lógico perfecto sigue compartiendo dominios de falla — un mal deploy toca a todos los tenants; solo la separación física cambia eso.
- Probar es el costo fuera de presupuesto. La suite de dos tenants es ingeniería de verdad; saltársela convierte “aplicado” de vuelta en “asumido”.
- Los muros más fuertes cuestan densidad. Claves por tenant, silos y recursos dedicados intercambian justo la economía que hizo atractivo compartir — gástalos en los tenants que los necesitan.
Aislamiento de tenants en Back4app
Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El aislamiento nace en la capa de datos por construcción: los roles definen el tenant, la ACL de cada objeto lo sella a ese rol y los permisos a nivel de clase controlan el schema — aplicado server-side en toda ruta, SDKs, REST, GraphQL y dashboard por igual, así que el bug del filtro olvidado no tiene nada que olvidar. La propia plataforma aplica la misma disciplina un nivel más arriba, aislando el backend de cada app del de todas las demás — y el análisis de ingeniería sobre seguridad a nivel de fila muestra el patrón completo en la práctica.
Preguntas frecuentes
¿Qué es el aislamiento de tenants?
El conjunto de controles arquitectónicos que impide que un tenant de un sistema compartido alcance los datos o recursos de otro — los muros entre departamentos de un mismo edificio. Atraviesa cada capa compartida: filas de la base, cachés, colas, almacenamiento de archivos y cómputo, cada una con su propia frontera acotada al tenant actual.
¿En qué se diferencia el aislamiento de tenants de la autenticación y la autorización?
Un usuario puede estar plenamente autenticado y correctamente autorizado para su rol — y aun así alcanzar los datos de otro tenant si nada acota la consulta. La autenticación prueba quién eres; la autorización decide qué acciones puedes ejecutar; el aislamiento garantiza en qué universo de tenant ocurren esas acciones. Es una capa aparte, y tratar login más roles como suficiente es la raíz de la mayoría de los bugs entre tenants.
¿Qué causa la fuga de datos entre tenants?
Una lista corta y estable: consultas sin su filtro de tenant; IDOR — IDs adivinables obtenidos sin acotar por tenant; jobs en segundo plano, webhooks y exportaciones corriendo fuera del contexto del tenant; cachés con claves sin el tenant; pipelines de analítica y reportes que esquivan las verificaciones de la aplicación; y confiar en un identificador de tenant enviado por el cliente en vez de derivarlo de la sesión en el servidor.
¿El problema del noisy neighbor es lo mismo que el aislamiento de tenants?
Son hermanos, no el mismo problema. El aislamiento de seguridad impide que un tenant acceda a los datos de otro; el aislamiento de rendimiento — el problema del noisy neighbor (vecino ruidoso) — impide que la carga de un tenant degrade la de todos los demás, y se resuelve con cuotas, throttling y particionamiento. Las discusiones los confunden con frecuencia; un sistema puede ser perfectamente seguro y aun así dejar que un tenant asfixie al resto.
¿Qué modelo de aislamiento exigen los marcos de compliance?
Ninguno de los grandes marcos manda una arquitectura — se basan en resultados, exigiendo medidas apropiadas y demostrables. La separación física suele venir de clientes enterprise y de contratos, no de reguladores. Lo que las auditorías sí premian: aplicación en la capa de datos, fronteras documentadas y evidencia de que el aislamiento se prueba en vez de asumirse.
¿Cómo aplica la seguridad a nivel de fila el aislamiento de tenants?
Haciendo de la frontera del tenant una propiedad de la tabla: las políticas filtran cada consulta por el contexto de tenant de la sesión, así que una consulta que olvida su filtro devuelve nada en vez de todo. El equivalente en bases de documentos es el control de acceso por objeto — ACLs que nombran el rol del tenant — aplicado por la plataforma en cada solicitud. En ambos casos, el muro sigue en pie aunque el código de la aplicación tropiece.
¿Cómo se prueba el aislamiento de tenants?
Adversarialmente, con dos tenants: intercambia IDs de objetos entre ellos en cada endpoint (la sonda de IDOR), reproduce el token de un tenant contra los recursos del otro, ejercita las rutas que se saltan la app principal — exportaciones, paneles de admin, jobs en segundo plano — e inspecciona claves de caché y URLs de archivos en busca de alcance de tenant faltante. Automatiza las pruebas negativas en CI; un aislamiento que no se prueba es una hipótesis.
¿Qué capas necesitan aislamiento además de la base de datos?
Todo lo compartido: claves de caché con prefijo de tenant, topics de cola y consumer groups acotados por tenant, object storage bajo prefijos por tenant con políticas de acceso a juego, claves de cifrado por tenant donde los contratos lo exigen, y claims de tenant cargados en los tokens y validados en cada solicitud. El muro de la base es necesario, nunca suficiente.