SaaS multitenant: opciones de aislamiento de datos

Las opciones se ordenan de más separación física a más compartición. Ninguna es mejor en abstracto; cada una traslada el riesgo a un lugar distinto.

También existen modelos híbridos: tablas compartidas para la mayoría de clientes y una base dedicada para quien la contrate o la necesite por motivos regulatorios. Funcionan bien si el límite de cada clase de datos está documentado y probado, y si el código no acumula ramas especiales para cada caso.

El modelo de tabla compartida es el más común en productos con muchos clientes, y también el más frágil si el aislamiento depende solo de que cada consulta incluya «WHERE tenant_id = ...». Basta un informe nuevo, un endpoint de exportación o una consulta escrita con prisa para mezclar datos.

Una defensa adicional es delegar el filtro en la propia base de datos. PostgreSQL, por ejemplo, ofrece políticas de seguridad a nivel de fila: se activan por tabla y, a partir de ese momento, solo son visibles o modificables las filas que permita una política. Si la tabla tiene la función activada pero ninguna política, no se ve ninguna fila. La aplicación fija al inicio de cada transacción el tenant activo y la política compara la columna tenant_id con ese valor.

Las políticas no sustituyen a la lógica de la aplicación: siguen siendo necesarias las comprobaciones de permisos dentro del tenant. Pero convierten un error de programación en una consulta que devuelve cero filas en lugar de datos ajenos, que es un fallo mucho más fácil de detectar y mucho menos grave.

El aislamiento no es solo de datos. En una infraestructura compartida, un tenant que lanza una importación masiva o un informe pesado puede ralentizar a todos. Es el problema del vecino ruidoso, y se aborda con límites explícitos:

• Límites de peticiones por tenant en la API, con respuestas claras cuando se superan.
• Colas de trabajos en segundo plano con reparto equitativo, para que un cliente no monopolice los procesos.
• Cuotas de almacenamiento, de usuarios o de registros ligadas al plan contratado.
• Tiempo máximo de ejecución de consultas e informes.
• Métricas por tenant para detectar consumos anómalos antes de que se conviertan en incidencias.

Dentro de cada organización hay roles: administrador del cliente, usuarios con permisos por módulo, quizá restricciones por centro. Ese modelo debe poder configurarlo el propio cliente sin intervención del proveedor. Y por encima existe un nivel distinto, el de la plataforma: el equipo de soporte y operación del SaaS.

El acceso de soporte a los datos de un cliente es una de las vías de exposición más habituales. Una práctica razonable es que no exista por defecto: se solicita para un caso concreto, se limita en el tiempo, queda registrado y, si el producto lo permite, lo autoriza el administrador del cliente. Las herramientas internas de administración deben pasar por los mismos controles que la aplicación, no tener una puerta lateral directa a la base de datos.

El aislamiento se demuestra con pruebas, no con revisiones de código ocasionales. La guía de seguridad multitenant de OWASP propone varias verificaciones; adaptadas a un producto típico, una batería útil incluye:

1. Matriz de acceso cruzado: con dos tenants de prueba, cada operación de cada tabla o endpoint se ejecuta desde el tenant B contra datos del tenant A y debe fallar o devolver vacío.
2. Inventario de tablas: una prueba automática lista las tablas del esquema y falla si alguna con datos de cliente no tiene política de fila activada o no está clasificada.
3. Rol de conexión: en el entorno desplegado se comprueba que la aplicación no usa un rol con privilegios para omitir políticas.
4. Reutilización de conexiones: peticiones alternas de dos tenants sobre el mismo pool demuestran que no se hereda el contexto anterior.
5. Exportaciones, búsquedas e informes: se prueban específicamente, porque suelen usar consultas distintas a las de las pantallas.
6. Restauración: se recupera la copia de un tenant y se verifica que no aparecen datos de otro.

Estas pruebas deben ejecutarse en la integración continua, de modo que una tabla nueva sin política o un endpoint sin filtro bloquee el despliegue.

El modelo elegido se nota sobre todo en la operación diaria. Con una base por tenant, una migración se ejecuta cientos de veces y hay que gestionar las que fallan a medias. Con tabla compartida, restaurar los datos de un solo cliente sin tocar al resto requiere procedimientos específicos. Y en cualquier modelo, el cliente que se va debería poder llevarse sus datos en un formato utilizable, y el proveedor tiene que poder borrarlos de forma verificable, incluidas las copias según su política de retención.

• Muchos clientes pequeños con datos homogéneos: tabla compartida con políticas a nivel de fila y pruebas automáticas.
• Pocos clientes grandes, requisitos de ubicación de datos o contratos que exigen separación física: base de datos por tenant.
• Necesidad de separación clara sin multiplicar instancias y número moderado de clientes: esquema por tenant, con atención a permisos y migraciones.
• Mezcla de perfiles: modelo híbrido, siempre que el código no se llene de excepciones.

Antes de elegir, escribe en una página qué es un tenant en tu producto, quién puede pertenecer a varios y qué pasa cuando uno se va. Esa definición suele decidir el modelo por sí sola. Si estás diseñando un producto de este tipo, desde nuestro servicio de desarrollo SaaS podemos ayudarte a tomar estas decisiones al inicio, junto con la arquitectura que las sostiene.