Probintzia-aldundi batek beren sistemak izateko baliabiderik ez duten dozenaka udal txiki koordinatzen ditu. Irtenbide naturala guztiei zerbitzua emango dien software bakar bat hedatzea da. Erronka tekniko kritikoa hau da: nola bermatu udal batek ere ezin dituela besteen datuak ikusi?
Hori da sektore publikoko multi-tenant diseinuaren galdera nagusia, eta artikulu honek Labraxen nola jorratzen dugun azaltzen du.
Multi-tenancy-ko hiru eredu
Funtsean hiru estrategia daude aplikazio beretik hainbat bezerori (tenant) zerbitzua emateko:
1. Database-per-tenant (isolamendu fisikoa)
Bezero bakoitzak bere datu-base propioa du, guztiz bereizia. Isolamendu maximoa, baina kostu operatibo handia: 30 udalerri dituen aldundi baterako 30 datu-base kudeatzea konplexua da mantentzeko.
2. Schema-per-tenant (isolamendu logikoa)
Datu-base bakarra, baina bezero bakoitzak bere eskema du. Isolamenduaren eta kostuaren arteko oreka. Aukera ona bezeroak gutxi direnean baina bereizketa argia behar dutenean.
3. Shared-database tenant_id-rekin (zutabe bidezko isolamendua)
Bezero guztiek taula berak partekatzen dituzte, baina erregistro bakoitzak jabea identifikatzen duen tenant_id eremu bat du. Aplikazioak beti iragazten du eremu horren arabera. Operatiboki eredu eraginkorrena da, baina diziplina erabatekoa eskatzen du datu-ihesak saihesteko.
Maila hierarkikoa: tenant gurasoa eta tenant umeak
Aldundi bat ez da tenant berdinen multzo bat soilik. Egitura hierarkikoa da:
- Aldundia ikuspegi agregatua duen tenant bat da (probintziako udalerri guztien adierazleak eta estatistikak ikus ditzake).
- Udal bakoitza tenant ume bat da, bere datuen gaineko ikuspegia soilik duena.
- Mankomunitate batzuk tarteko tenantak izan daitezke, osatzen dituzten udalen gaineko ikuspegi partzialarekin.
Hierarkia hori ez da inplementatzen erraza. Irakurketa-eragiketa bakoitzak erabiltzailearen sarbide-maila ebaluatu behar du eta datuak dagokion xehetasun-mailan itzuli:
- X Udaleko erabiltzaile batek bere udalerriko datu indibidualak ikusten ditu.
- Aldundiko erabiltzaile batek probintzia osoko adierazle agregatuak ikusten ditu, baina ez herritar jakinen datu indibidualak (hori oso garrantzitsua da RGPDrengatik).
- Baimen esplizitu eta sinatua duen Aldundiko supererabiltzaile batek udalerri jakin bateko datu indibidualak ikus ditzake, baina auditoria-logean erregistratuta geratzen da.
Zifratzea: gako bat tenant bakoitzeko
Atsedeneko datuak zifratzea derrigorrezkoa da ENS Altuan. Galdera hau da: gako bakarra datu-base osorako, ala gako bat tenant bakoitzeko?
Gako bat erabiltzen dugu tenant bakoitzeko. Horrek esan nahi du norbaitek zerbitzarirako sarbide fisikoa izango balu ere, ezingo lituzkeela udalen datuak irakurri dagozkien gakoak ere izan gabe, eta gako horiek bereizita gordetzen dira HSM modulu batean (Hardware Security Module). Tenant batek zerbitzuan baja eskatzen badu, haren datuen suntsipen kriptografikoa berma dezakegu haren gakoa ezabatuz besterik gabe.
Sarbide-kontrola: RBAC + ABAC
Nork zer ikus dezakeen kontrolatzeko bi eredu konbinatu erabiltzen dira:
RBAC (Role-Based Access Control)
Erabiltzaileek rolak dituzte (udal-administratzailea, agente operatiboa, teknikaria, kudeatzailea), eta rol bakoitzak baimen-multzo zehatz bat du. Agente batek kontsultatu dezake, baina ez onartu. Kudeatzaile batek bere tenantaren barruan onartu dezake, baina ez kanpoan. Eta abar.
ABAC (Attribute-Based Access Control)
RBACaren gainean baliabidearen atributuetan oinarritutako arauak gehitzen dira. Adibidez: "erabiltzaile batek tenant_id = su_tenant duten erregistroak soilik ikus ditzake". Arau horiek eskaera bakoitzean ebaluatzen dira, eta horiek bermatzen dute benetako isolamendua.
Konbinazioak ematen du sistema osoa: RBACek zehazten du rolak zer egin dezakeen abstraktuan, eta ABACek zein baliabide zehatzen gainean jardun dezakeen.
Auditoria: logea da kontratua
Sektore publikoan auditoria ez da aukerakoa. Eragiketa kritiko bakoitzak sarrera bat sortzen du auditoria-logean, honako hauekin:
- Nork egin zuen eragiketa (erabiltzailea eta tenanta).
- Zer egin zuen (eragiketa mota).
- Zein baliabideren gainean.
- Noiz (milisegundoko zehaztasuneko timestampa).
- Nondik (jatorriko IPa, nabigatzailearen agentea).
- Emaitza (arrakasta, hutsegitea, errore-kodea).
Log hori gutxienez 24 hilabetez gordetzen da, eta aldaezina da: sarrera bat idatzi ondoren, ezin da aldatu ez ezabatu. Administrazio batek eragiketa bat egin zela (edo ez zela egin) frogatu behar badu, logea da froga.
Udal bat joaten denean
Erabaki arkitektoniko garrantzitsu bat: zer gertatzen da tenant batek zerbitzua uzten duenean?
Gure politika hau da:
- Tenantak irteera eskatzen du aurrez abisatuta (normalean 6 hilabete, hitzarmenaren arabera).
- Haren datuen esportazio osoa sortzen da formatu estandarrean (JSON egituratua + fitxategi erantsiak).
- Tenantak egiaztatzen du esportazioa osoa dela eta adostasuna sinatzen du.
- Ezabatze kriptografikoa egiten da: tenantaren zifratze-gakoa suntsitzen da.
- Datuak fisikoki biltegian jarraitzen dute beste 30 egunez (segurtasun-atxikipena), baina eskuraezinak dira gakorik gabe.
- 30 egunen buruan behin betiko ezabatze fisikoa egiten da.
Prozesu horrek bermatzen du joaten den tenantak bere datu guztiak jasotzen dituela eta inork (ezta guk ere) ezin dituela gero berreskuratu.
Plano operatiboa: nola ustiatzen den sistema
Ekoizpenean jarri ondoren, egunerokoak hau dakar:
- Hedapenak: aplikazioaren eguneratzeak tenant guztiei aldi berean aplikatzen dizkiegu, baina bakoitzak bere konfigurazioa gordetzen du (katalogoak, parametroak, integrazioak).
- Datu-migrazioak: eskema-aldaketa dagoenean, tenantez tenant migratzen dira, huts eginez gero rollback automatikoarekin.
- Monitorizazioa: tenant bakoitzak bere osasun-dashboarda du (latentzia, erroreak, erabilera). Tenant batek arazoak baditu, isolatu egiten da besteei eragin gabe.
- Backupak: tenant bakoitzeko eguneroko backupak, 30 eguneko atxikipenarekin berreskuratze azkarrerako eta 12 hilabetekoarekin legea betetzeko.
Zer aldatzen da zure aldundiak hau hedatu nahi badu
Aldundi bat kudeatzen baduzu eta udalez gaindiko software bat ebaluatzen ari bazara:
- Galdetu hornitzaileari bere datuak isolatzeko ereduari buruz. Database-per-tenant, schema-per-tenant edo shared-with-tenant_id. Edozein erantzun da baliozkoa, baina argia eta dokumentatua izan behar du.
- Eskatu ekoizpeneko tenant baten benetako auditoria-logak ikustea. Erakutsi ezin badizkizute, arazo bat dago.
- Galdetu nola kudeatzen den tenant baten irteera. Erantzuna lausoa bada, zure aldundiak hornitzailez aldatu nahi duen egunean arazoak egongo dira.
- Galdetu tenanten arteko RGPDri buruz: zer gertatzen da udal bateko tratamenduaren arduradunak beste bateko datuekin gurutzatzen den informazioa eskatzen badu?
Galdera horiek bereizten dituzte multi-tenant arkitektura benetan pentsatu duten hornitzaileak taulei tenant_id eremu bat gehitu eta "multi-tenant" deitzen diotenetatik.
