Cuando varios clientes utilizan la misma instancia de un software, un proveedor SaaS tiene que responder a una pregunta fundamental: ¿cómo se separan los datos de cada cliente (tenant)? La respuesta más extendida en el sector es una base de datos compartida en la que cada tabla lleva una columna adicional como «tenant_id», por la que se filtra cada consulta. Funciona, pero depende por completo de que este filtro esté implementado correctamente en cada punto del código. 1Tool sigue un camino estructuralmente distinto.
Una base de datos propia por cliente en lugar de una tabla compartida
En 1Tool, cada cliente recibe su propia base de datos, físicamente separada. Se conecta de forma dinámica en tiempo de ejecución: cuando un usuario inicia sesión, el sistema sabe con qué base de datos de cliente tiene que comunicarse y establece la conexión en consecuencia. Por tanto, la separación no se produce a nivel de aplicación mediante una condición de filtro, sino ya a nivel de infraestructura. Un error de programación que, con una base de datos compartida, podría en teoría hacer que se olvide la condición de filtro y que se vean datos de otro cliente queda descartado de entrada con una arquitectura estricta de una base de datos por cliente: sencillamente no existe ninguna tabla compartida de la que pudieran leerse por error más datos de la cuenta.
Servidores propios para los grandes clientes, caché separada para todos
Si es necesario, esta separación puede llevarse aún más lejos. Para clientes especialmente grandes, 1Tool puede incluso asignar un servidor de base de datos completamente propio –con su propio host y sus propias credenciales– en lugar de ejecutar la base de datos en la misma infraestructura de servidores compartida que otros clientes. Así, el aislamiento se amplía del nivel lógico al nivel físico de la infraestructura cuando tiene sentido para un cliente por motivos de seguridad o de rendimiento. Además, 1Tool gestiona también la caché por cliente: los datos almacenados en caché se mantienen igualmente separados por cliente, de modo que tampoco a este nivel puede producirse ninguna mezcla entre clientes.
Permisos detallados dentro del cliente
La separación entre clientes es solo un nivel del control de acceso. Dentro de un mismo cliente, un sistema de permisos con decenas de reglas de filtrado especializadas –los llamados scopes– determina además qué registros concretos puede ver un usuario determinado. Así se puede hacer, por ejemplo, que un comercial vea solo sus propios contactos, mientras que un directivo tiene una visión completa, todo ello dentro de la misma base de datos ya aislada por cliente. Para las empresas con altas exigencias de protección y seguridad de datos, esta combinación es un argumento relevante a la hora de elegir proveedor. Una base de datos compartida con columnas tenant_id es más barata de escalar en la operación, pero exige que cada consulta de todo el sistema se filtre correctamente, durante años y a lo largo de muchas generaciones de desarrolladores. Una verdadera arquitectura de una base de datos por cliente traslada esta garantía de la lógica de la aplicación a la propia infraestructura.
Preguntas frecuentes
¿Una base de datos propia por cliente significa que los datos se almacenan físicamente separados?
Sí, cada cliente recibe su propia base de datos separada en lugar de tablas compartidas con un identificador de cliente como columna de filtro.
¿Se puede ejecutar un cliente concreto en un servidor completamente propio?
Para clientes especialmente grandes es posible, con su propio host y sus propias credenciales, separado de la infraestructura de servidores compartida.
¿Cómo se regula dentro de un cliente quién ve qué registros?
De ello se encarga un sistema de permisos con numerosas reglas de filtrado especializadas, que actúan además de la separación de bases de datos y restringen el acceso a registros concretos para cada usuario.
¿Qué importancia tiene un verdadero aislamiento de bases de datos para los requisitos de protección de datos de su empresa?
Seguir leyendo
- Notificar a otros sistemas: peticiones HTTP directamente desde el flujo de automatización
- Webhooks entrantes: datos externos al CRM de forma estructurada