Una diputación provincial coordina decenas de ayuntamientos pequeños que no tienen recursos para tener sus propios sistemas. La solución natural es desplegar un software único que dé servicio a todos. El reto técnico crítico es: ¿cómo se aseguran de que ningún ayuntamiento puede ver los datos de los demás?
Esta es la pregunta central del diseño multi-tenant en el sector público, y este artículo describe cómo la abordamos en Labrax.
Tres patrones de multi-tenancy
Existen básicamente tres estrategias para servir a múltiples clientes (tenants) desde una misma aplicación:
1. Database-per-tenant (aislamiento físico)
Cada cliente tiene su propia base de datos, completamente separada. Aislamiento máximo, pero coste operacional alto: gestionar 30 bases de datos para una diputación con 30 municipios es complejo de mantener.
2. Schema-per-tenant (aislamiento lógico)
Una sola base de datos, pero cada cliente tiene su propio esquema. Equilibrio entre aislamiento y coste. Buena opción cuando los clientes son pocos pero requieren separación clara.
3. Shared-database con tenant_id (aislamiento por columna)
Todos los clientes comparten las mismas tablas, pero cada registro tiene un campo tenant_id que identifica al propietario. La aplicación filtra siempre por ese campo. Es el patrón más eficiente operativamente, pero requiere disciplina absoluta para evitar fugas de datos.
El nivel jerárquico: tenant padre y tenants hijo
Una diputación no es solo un conjunto de tenants iguales. Es una estructura jerárquica:
- La Diputación es un tenant con visibilidad agregada (puede ver indicadores y estadísticas de todos los municipios de la provincia).
- Cada Ayuntamiento es un tenant hijo con visibilidad solo sobre sus propios datos.
- Algunas Mancomunidades pueden ser tenants intermedios, con visibilidad parcial sobre los ayuntamientos que las componen.
Esta jerarquía no es trivial de implementar. Cada operación de lectura debe evaluar el nivel de acceso del usuario y devolver los datos en el grado de detalle que le corresponde:
- Un usuario del Ayuntamiento de X ve los datos individuales de su municipio.
- Un usuario de la Diputación ve indicadores agregados de toda la provincia, pero no datos individuales de ciudadanos concretos (esto es muy importante por RGPD).
- Un superusuario de la Diputación con autorización explícita y firmada puede ver datos individuales de un municipio concreto, pero queda registrado en el log de auditoría.
Cifrado: una clave por tenant
El cifrado de datos en reposo es obligatorio en ENS Alto. La pregunta es: ¿una sola clave para toda la base de datos, o una clave por tenant?
Usamos una clave por tenant. Esto significa que aunque alguien tuviera acceso físico al servidor, no podría leer los datos de los ayuntamientos sin tener también las claves correspondientes, que están almacenadas separadamente en un módulo HSM (Hardware Security Module). Si un tenant solicita la baja del servicio, podemos garantizar destrucción criptográfica de sus datos simplemente eliminando su clave.
El control de accesos: RBAC + ABAC
El control de quién puede ver qué se basa en dos modelos combinados:
RBAC (Role-Based Access Control)
Los usuarios tienen roles (administrador municipal, agente operativo, técnico, gestor) y cada rol tiene un conjunto de permisos definidos. Un agente puede consultar pero no aprobar. Un gestor puede aprobar dentro de su tenant pero no fuera. Etc.
ABAC (Attribute-Based Access Control)
Sobre el RBAC se añaden reglas basadas en atributos del recurso. Por ejemplo: "un usuario solo puede ver registros donde tenant_id = su_tenant". Estas reglas se evalúan en cada petición y son las que garantizan el aislamiento real.
La combinación es lo que da el sistema completo: RBAC define qué puede hacer el rol en abstracto, ABAC define sobre qué recursos concretos puede actuar.
Auditoría: el log es el contrato
En sector público, la auditoría no es opcional. Cada operación crítica genera una entrada en el log de auditoría con:
- Quién hizo la operación (usuario y tenant).
- Qué hizo (tipo de operación).
- Sobre qué recurso.
- Cuándo (timestamp con precisión de milisegundos).
- Desde dónde (IP de origen, agente del navegador).
- Resultado (éxito, fallo, código de error).
Este log se conserva durante 24 meses como mínimo y es inmutable: una vez escrita una entrada, no puede modificarse ni borrarse. Si una administración necesita demostrar que una operación se realizó (o no se realizó), el log es la prueba.
Cuando un ayuntamiento se va
Una decisión arquitectónica importante: ¿qué pasa cuando un tenant deja el servicio?
Nuestra política es la siguiente:
- El tenant solicita la salida con preaviso (típicamente 6 meses según convenio).
- Se genera una exportación completa de sus datos en formato estándar (JSON estructurado + ficheros adjuntos).
- El tenant verifica que la exportación es completa y firma conformidad.
- Se procede a la eliminación criptográfica: se destruye la clave de cifrado del tenant.
- Los datos siguen físicamente en el almacenamiento durante 30 días más (retención de seguridad), pero son inaccesibles sin la clave.
- Después de 30 días se ejecuta la eliminación física definitiva.
Este proceso garantiza que el tenant que se va recibe sus datos completos y que nadie (ni siquiera nosotros) puede recuperarlos después.
El plano operativo: cómo se opera el sistema
Una vez en producción, el día a día implica:
- Despliegues: aplicamos updates de la aplicación a todos los tenants simultáneamente, pero cada uno conserva su configuración propia (catálogos, parámetros, integraciones).
- Migraciones de datos: cuando hay cambio de esquema, se migran tenant por tenant, con rollback automático si falla.
- Monitorización: cada tenant tiene su propio dashboard de salud (latencia, errores, uso). Si un tenant tiene problemas, se aísla sin afectar a los demás.
- Backups: backups diarios por tenant, con retención de 30 días para recuperación rápida y 12 meses para cumplimiento legal.
Qué cambia si tu diputación quiere desplegar esto
Si gestionas una diputación y estás evaluando un software supramunicipal:
- Pregunta al proveedor por su modelo de aislamiento de datos. Database-per-tenant, schema-per-tenant o shared-with-tenant_id. Cualquier respuesta vale, pero debe estar clara y documentada.
- Pide ver los logs de auditoría reales de un tenant en producción. Si no pueden enseñártelos, hay un problema.
- Pregunta cómo se gestiona la salida de un tenant. Si la respuesta es vaga, el día que tu diputación quiera cambiar de proveedor habrá problemas.
- Pregunta por el RGPD entre tenants: ¿qué pasa si el responsable del tratamiento de un ayuntamiento solicita información que cruza con datos de otro?
Estas preguntas separan los proveedores que han pensado realmente la arquitectura multi-tenant de los que han añadido un campo tenant_id a las tablas y le llaman "multi-tenant".
