Multi-tenant para deputacións: como coordinar varios concellos sen mesturar os seus datos

Unha deputación provincial coordina decenas de concellos pequenos que non teñen recursos para dispor dos seus propios sistemas. A solución natural é despregar un software único que dea servizo a todos. O reto técnico crítico é: como se asegura que ningún concello poida ver os datos dos demais?

Esta é a pregunta central do deseño multi-tenant no sector público, e este artigo describe como a abordamos en Labrax.

Tres patróns de multi-tenancy

Existen basicamente tres estratexias para servir múltiples clientes (tenants) desde unha mesma aplicación:

1. Database-per-tenant (illamento físico)

Cada cliente ten a súa propia base de datos, completamente separada. Illamento máximo, pero custo operativo alto: xestionar 30 bases de datos para unha deputación con 30 municipios é complexo de manter.

2. Schema-per-tenant (illamento lóxico)

Unha soa base de datos, pero cada cliente ten o seu propio esquema. Equilibrio entre illamento e custo. Boa opción cando os clientes son poucos pero requiren unha separación clara.

3. Shared-database con tenant_id (illamento por columna)

Todos os clientes comparten as mesmas táboas, pero cada rexistro ten un campo tenant_id que identifica o propietario. A aplicación filtra sempre por ese campo. É o patrón máis eficiente operativamente, pero require disciplina absoluta para evitar fugas de datos.

O nivel xerárquico: tenant pai e tenants fillos

Unha deputación non é só un conxunto de tenants iguais. É unha estrutura xerárquica:

• A Deputación é un tenant con visibilidade agregada (pode ver indicadores e estatísticas de todos os municipios da provincia).
• Cada Concello é un tenant fillo con visibilidade só sobre os seus propios datos.
• Algunhas mancomunidades poden ser tenants intermedios, con visibilidade parcial sobre os concellos que as compoñen.

Esta xerarquía non é trivial de implementar. Cada operación de lectura debe avaliar o nivel de acceso do usuario e devolver os datos co grao de detalle que lle corresponde:

• Un usuario do Concello de X ve os datos individuais do seu municipio.
• Un usuario da Deputación ve indicadores agregados de toda a provincia, pero non datos individuais de cidadáns concretos (isto é moi importante polo RGPD).
• Un superusuario da Deputación con autorización explícita e asinada pode ver datos individuais dun municipio concreto, pero queda rexistrado no log de auditoría.

Cifrado: unha clave por tenant

O cifrado de datos en repouso é obrigatorio no ENS Alto. A pregunta é: unha soa clave para toda a base de datos ou unha clave por tenant?

Usamos unha clave por tenant. Isto significa que, aínda que alguén tivese acceso físico ao servidor, non podería ler os datos dos concellos sen ter tamén as claves correspondentes, que están almacenadas por separado nun módulo HSM (Hardware Security Module). Se un tenant solicita a baixa do servizo, podemos garantir a destrución criptográfica dos seus datos simplemente eliminando a súa clave.

O control de accesos: RBAC + ABAC

O control de quen pode ver que se basea en dous modelos combinados:

RBAC (Role-Based Access Control)

Os usuarios teñen roles (administrador municipal, axente operativo, técnico, xestor) e cada rol ten un conxunto de permisos definidos. Un axente pode consultar pero non aprobar. Un xestor pode aprobar dentro do seu tenant pero non fóra. Etc.

ABAC (Attribute-Based Access Control)

Sobre o RBAC engádense regras baseadas en atributos do recurso. Por exemplo: "un usuario só pode ver rexistros onde tenant_id = su_tenant". Estas regras avalíanse en cada petición e son as que garanten o illamento real.

A combinación é o que dá o sistema completo: o RBAC define que pode facer o rol en abstracto e o ABAC define sobre que recursos concretos pode actuar.

Auditoría: o log é o contrato

No sector público, a auditoría non é opcional. Cada operación crítica xera unha entrada no log de auditoría con:

• Quen fixo a operación (usuario e tenant).
• Que fixo (tipo de operación).
• Sobre que recurso.
• Cando (timestamp con precisión de milisegundos).
• Desde onde (IP de orixe, axente do navegador).
• Resultado (éxito, fallo, código de erro).

Este log consérvase durante 24 meses como mínimo e é inmutable: unha vez escrita unha entrada, non se pode modificar nin borrar. Se unha administración necesita demostrar que unha operación se realizou (ou non se realizou), o log é a proba.

Cando un concello marcha

Unha decisión arquitectónica importante: que pasa cando un tenant deixa o servizo?

A nosa política é a seguinte:

1. O tenant solicita a saída con preaviso (tipicamente 6 meses segundo o convenio).
2. Xérase unha exportación completa dos seus datos en formato estándar (JSON estruturado + ficheiros adxuntos).
3. O tenant verifica que a exportación está completa e asina a conformidade.
4. Procédese á eliminación criptográfica: destrúese a clave de cifrado do tenant.
5. Os datos seguen fisicamente no almacenamento durante 30 días máis (retención de seguridade), pero son inaccesibles sen a clave.
6. Despois de 30 días execútase a eliminación física definitiva.

Este proceso garante que o tenant que marcha recibe os seus datos completos e que ninguén (nin sequera nós) pode recuperalos despois.

O plano operativo: como se opera o sistema

Unha vez en produción, o día a día implica:

• Despregamentos: aplicamos as actualizacións da aplicación a todos os tenants simultaneamente, pero cada un conserva a súa configuración propia (catálogos, parámetros, integracións).
• Migracións de datos: cando hai un cambio de esquema, mígranse tenant por tenant, con rollback automático se falla.
• Monitorización: cada tenant ten o seu propio panel de saúde (latencia, erros, uso). Se un tenant ten problemas, íllase sen afectar os demais.
• Copias de seguridade: copias diarias por tenant, cunha retención de 30 días para a recuperación rápida e de 12 meses para o cumprimento legal.

Que cambia se a túa deputación quere despregar isto

Se xestionas unha deputación e estás a avaliar un software supramunicipal:

• Pregúntalle ao provedor polo seu modelo de illamento de datos. Database-per-tenant, schema-per-tenant ou shared-with-tenant_id. Calquera resposta vale, pero debe estar clara e documentada.
• Pide ver os logs de auditoría reais dun tenant en produción. Se non cos poden ensinar, hai un problema.
• Pregunta como se xestiona a saída dun tenant. Se a resposta é vaga, o día que a túa deputación queira cambiar de provedor haberá problemas.
• Pregunta polo RGPD entre tenants: que pasa se o responsable do tratamento dun concello solicita información que se cruza con datos doutro?

Estas preguntas separan os provedores que pensaron realmente a arquitectura multi-tenant dos que engadiron un campo tenant_id ás táboas e lle chaman "multi-tenant".