Una diputació provincial coordina desenes d'ajuntaments petits que no tenen recursos per tenir els seus propis sistemes. La solució natural és desplegar un programari únic que doni servei a tots. El repte tècnic crític és: com s'assegura que cap ajuntament no pugui veure les dades dels altres?
Aquesta és la pregunta central del disseny multi-tenant en el sector públic, i aquest article descriu com l'abordem a Labrax.
Tres patrons de multi-tenancy
Hi ha bàsicament tres estratègies per servir múltiples clients (tenants) des d'una mateixa aplicació:
1. Database-per-tenant (aïllament físic)
Cada client té la seva pròpia base de dades, completament separada. Aïllament màxim, però cost operacional alt: gestionar 30 bases de dades per a una diputació amb 30 municipis és complex de mantenir.
2. Schema-per-tenant (aïllament lògic)
Una sola base de dades, però cada client té el seu propi esquema. Equilibri entre aïllament i cost. Bona opció quan els clients són pocs però requereixen una separació clara.
3. Shared-database amb tenant_id (aïllament per columna)
Tots els clients comparteixen les mateixes taules, però cada registre té un camp tenant_id que n'identifica el propietari. L'aplicació filtra sempre per aquest camp. És el patró més eficient operativament, però requereix una disciplina absoluta per evitar fuites de dades.
El nivell jeràrquic: tenant pare i tenants fill
Una diputació no és només un conjunt de tenants iguals. És una estructura jeràrquica:
- La Diputació és un tenant amb visibilitat agregada (pot veure indicadors i estadístiques de tots els municipis de la província).
- Cada Ajuntament és un tenant fill amb visibilitat només sobre les seves pròpies dades.
- Algunes Mancomunitats poden ser tenants intermedis, amb visibilitat parcial sobre els ajuntaments que les componen.
Aquesta jerarquia no és trivial d'implementar. Cada operació de lectura ha d'avaluar el nivell d'accés de l'usuari i retornar les dades amb el grau de detall que li correspon:
- Un usuari de l'Ajuntament de X veu les dades individuals del seu municipi.
- Un usuari de la Diputació veu indicadors agregats de tota la província, però no dades individuals de ciutadans concrets (això és molt important pel RGPD).
- Un superusuari de la Diputació amb autorització explícita i signada pot veure dades individuals d'un municipi concret, però queda registrat al log d'auditoria.
Xifratge: una clau per tenant
El xifratge de dades en repòs és obligatori a l'ENS Alt. La pregunta és: una sola clau per a tota la base de dades, o una clau per tenant?
Fem servir una clau per tenant. Això significa que, encara que algú tingués accés físic al servidor, no podria llegir les dades dels ajuntaments sense tenir també les claus corresponents, que estan emmagatzemades per separat en un mòdul HSM (Hardware Security Module). Si un tenant sol·licita la baixa del servei, podem garantir la destrucció criptogràfica de les seves dades simplement eliminant-ne la clau.
El control d'accessos: RBAC + ABAC
El control de qui pot veure què es basa en dos models combinats:
RBAC (Role-Based Access Control)
Els usuaris tenen rols (administrador municipal, agent operatiu, tècnic, gestor) i cada rol té un conjunt de permisos definits. Un agent pot consultar però no aprovar. Un gestor pot aprovar dins del seu tenant però no fora. Etc.
ABAC (Attribute-Based Access Control)
Sobre l'RBAC s'hi afegeixen regles basades en atributs del recurs. Per exemple: "un usuari només pot veure registres on tenant_id = su_tenant". Aquestes regles s'avaluen a cada petició i són les que garanteixen l'aïllament real.
La combinació és el que dona el sistema complet: RBAC defineix què pot fer el rol en abstracte, ABAC defineix sobre quins recursos concrets pot actuar.
Auditoria: el log és el contracte
En el sector públic, l'auditoria no és opcional. Cada operació crítica genera una entrada al log d'auditoria amb:
- Qui ha fet l'operació (usuari i tenant).
- Què ha fet (tipus d'operació).
- Sobre quin recurs.
- Quan (timestamp amb precisió de mil·lisegons).
- Des d'on (IP d'origen, agent del navegador).
- Resultat (èxit, error, codi d'error).
Aquest log es conserva durant 24 mesos com a mínim i és immutable: un cop escrita una entrada, no es pot modificar ni esborrar. Si una administració necessita demostrar que una operació es va fer (o no es va fer), el log n'és la prova.
Quan un ajuntament se'n va
Una decisió arquitectònica important: què passa quan un tenant deixa el servei?
La nostra política és la següent:
- El tenant sol·licita la sortida amb preavís (típicament 6 mesos segons el conveni).
- Es genera una exportació completa de les seves dades en format estàndard (JSON estructurat + fitxers adjunts).
- El tenant verifica que l'exportació és completa i en signa la conformitat.
- Es procedeix a l'eliminació criptogràfica: es destrueix la clau de xifratge del tenant.
- Les dades continuen físicament a l'emmagatzematge durant 30 dies més (retenció de seguretat), però són inaccessibles sense la clau.
- Després de 30 dies s'executa l'eliminació física definitiva.
Aquest procés garanteix que el tenant que se'n va rep les seves dades completes i que ningú (ni tan sols nosaltres) no les pot recuperar després.
El pla operatiu: com s'opera el sistema
Un cop en producció, el dia a dia implica:
- Desplegaments: apliquem les actualitzacions de l'aplicació a tots els tenants simultàniament, però cadascun conserva la seva configuració pròpia (catàlegs, paràmetres, integracions).
- Migracions de dades: quan hi ha un canvi d'esquema, es migren tenant per tenant, amb rollback automàtic si falla.
- Monitoratge: cada tenant té el seu propi tauler de salut (latència, errors, ús). Si un tenant té problemes, s'aïlla sense afectar els altres.
- Còpies de seguretat: còpies diàries per tenant, amb retenció de 30 dies per a una recuperació ràpida i de 12 mesos per al compliment legal.
Què canvia si la teva diputació vol desplegar això
Si gestiones una diputació i estàs avaluant un programari supramunicipal:
- Pregunta al proveïdor pel seu model d'aïllament de dades. Database-per-tenant, schema-per-tenant o shared-with-tenant_id. Qualsevol resposta és vàlida, però ha de ser clara i estar documentada.
- Demana veure els logs d'auditoria reals d'un tenant en producció. Si no te'ls poden ensenyar, hi ha un problema.
- Pregunta com es gestiona la sortida d'un tenant. Si la resposta és vaga, el dia que la teva diputació vulgui canviar de proveïdor hi haurà problemes.
- Pregunta pel RGPD entre tenants: què passa si el responsable del tractament d'un ajuntament sol·licita informació que es creua amb dades d'un altre?
Aquestes preguntes separen els proveïdors que han pensat de debò l'arquitectura multi-tenant dels que han afegit un camp tenant_id a les taules i en diuen "multi-tenant".
