Leer hoe multi-tenant-databases beveiliging en prestaties beïnvloeden, welke risico's er zijn (isolatie, noisy neighbors) en welke praktische maatregelen je kunt nemen om tenants veilig en snel te houden.
Een multi-tenant database is een opzet waarbij veel klanten (tenants) hetzelfde databasesysteem delen—dezelfde database-server, dezelfde onderliggende opslag en vaak hetzelfde schema—terwijl de applicatie ervoor zorgt dat elke tenant alleen bij zijn eigen data kan.
Denk eraan als een appartementencomplex: iedereen deelt de structuur en voorzieningen, maar elke tenant heeft zijn eigen afgesloten unit.
In een single-tenant aanpak krijgt elke klant dedicated database-resources—bijvoorbeeld een eigen database-instantie of eigen server. Isolatie is eenvoudiger te begrijpen, maar doorgaans duurder en operationeel zwaarder naarmate het aantal klanten groeit.
Met multi-tenancy delen tenants infrastructuur, wat efficiënt kan zijn—maar het betekent ook dat je ontwerp grenzen expliciet moet afdwingen.
SaaS-bedrijven kiezen vaak multi-tenancy om praktische redenen:
Multi-tenancy is op zich niet automatisch “veilig” of “snel.” Uitkomsten hangen af van keuzes zoals hoe tenants worden gescheiden (schema, rijen of databases), hoe toegangscontrole wordt afgedwongen, hoe encryptiesleutels worden beheerd en hoe het systeem voorkomt dat de workload van één tenant anderen vertraagt.
De rest van deze handleiding zoomt in op die ontwerpkeuzes—want in multi-tenant systemen zijn beveiliging en prestaties features die je bouwt, geen aannames die je meekrijgt.
Multi-tenancy is geen enkele ontwerpkeuze—het is een spectrum van hoe strak je infrastructuur deelt. Het model dat je kiest bepaalt je isolatiegrens (wat nooit gedeeld mag worden) en dat beïnvloedt direct databasebeveiliging, prestatie-isolatie en dagelijkse operatie.
Elke tenant krijgt zijn eigen database (vaak op dezelfde server of cluster).
Isolatiegrens: de database zelf. Dit is meestal het meest duidelijke verhaal van tenantisolatie omdat cross-tenant toegang meestal een databasegrens moet oversteken.
Operationele afwegingen: zwaarder om op schaal te beheren. Upgrades en schema-migraties moeten mogelijk duizenden keren draaien, en connection pooling kan complex worden. Backups/restores zijn eenvoudig op tenantniveau, maar opslag- en beheeroverhead kan snel groeien.
Beveiliging & tunen: over het algemeen het makkelijkst per klant te beveiligen en te tunen, en een goede keuze wanneer tenants verschillende compliance-eisen hebben.
Tenants delen een database, maar elke tenant heeft een eigen schema.
Isolatiegrens: het schema. Het is een zinvolle scheiding, maar het vertrouwt op correcte permissies en tooling.
Operationele afwegingen: upgrades en migraties blijven repetitief, maar lichter dan database-per-tenant. Backups zijn gecompliceerder: veel tools behandelen de database als unit, dus tenant-niveau operaties kunnen schema-exports vereisen.
Beveiliging & tunen: makkelijker dan gedeelde tabellen, maar je moet gedisciplineerd zijn met privileges en ervoor zorgen dat queries nooit naar het verkeerde schema verwijzen.
Alle tenants delen een database en schema, maar elke tenant heeft aparte tabellen (bijv. orders_tenant123).
Isolatiegrens: de set tabellen. Het kan werken voor een klein aantal tenants, maar schaalt slecht: metadata-bloat, migratiescripts worden onhandelbaar en queryplanning kan verslechteren.
Beveiliging & tunen: permissies kunnen precies zijn, maar operationele complexiteit is hoog en het is makkelijk fouten te maken bij het toevoegen van nieuwe tabellen of features.
Alle tenants delen dezelfde tabellen, onderscheiden door een tenant_id-kolom.
Isolatiegrens: je query- en toegangscontrollayer (vaak row-level security). Dit model is operationeel efficiënt—één schema om te migreren, één indexstrategie om te beheren—maar het is het meest veeleisend voor databasebeveiliging en prestatie-isolatie.
Beveiliging & tunen: het moeilijkst juist te krijgen omdat elke query tenant-aware moet zijn, en het noisy-neighbor-probleem vaker voorkomt tenzij je resource-throttling en zorgvuldige indexering toevoegt.
Een handige vuistregel: hoe meer je deelt, hoe eenvoudiger upgrades worden—maar hoe meer discipline je nodig hebt in tenant-isolatiecontroles en prestatie-isolatie.
Multi-tenancy betekent niet alleen “meerdere klanten in één database.” Het verandert je threatmodel: het grootste risico verschuift van buitenstaanders die binnenkomen naar geautoriseerde gebruikers die per ongeluk (of opzettelijk) data van een andere tenant zien.
Authenticatie beantwoordt “wie ben je?” Autorisatie beantwoordt “wat mag je benaderen?” In een multi-tenant database moet tenant-context (tenant_id, account_id, org_id) tijdens autorisatie worden afgedwongen—niet als optioneel filter.
Een veelgemaakte fout is aannemen dat zodra een gebruiker geauthenticeerd is en je "wint" weet welke tenant, de applicatie queries vanzelf gescheiden houdt. In de praktijk moet scheiding expliciet zijn en afgedwongen op een consistente controlepunt (bijv. databasepolicies of een verplichte querylaag).
De eenvoudigste regel is ook de belangrijkste: elke read en write moet precies voor één tenant gescoord zijn.
Dat geldt voor:
Als tenant-scoping optioneel is, zal het uiteindelijk worden overgeslagen.
Cross-tenant leaks komen vaak door kleine, routinematige fouten:
tenant_id bindenTests draaien typisch met kleine datasets en schone aannames. Productie voegt concurrency, retries, caches, gemengde tenantdata en echte randgevallen toe.
Een feature kan tests halen omdat er maar één tenant in de testdatabase bestaat, of omdat fixtures geen overlappende IDs tussen tenants hebben. De veiligste ontwerpen maken het moeilijk om een ongescopeerde query te schrijven, in plaats van te vertrouwen op reviewers.
Het kernrisico in een multi-tenant database is eenvoudig: een query die vergeet te filteren op tenant kan iemands anders data blootleggen. Sterke isolatiecontroles gaan ervan uit dat fouten zullen gebeuren en maken die fouten onschadelijk.
Elk tenant-bezitgend record moet een tenant-identifier dragen (bijv. tenant_id) en je toegangslaag moet altijd reads en writes daarop scopen.
Een praktisch patroon is “tenant-context eerst”: de applicatie lost de tenant op (van subdomein, org-ID of tokenclaims), slaat die op in de requestcontext, en je data-access code weigert te draaien zonder die context.
Guardrails die helpen:
tenant_id in primaire/unieke sleutels waar passend (om botsingen tussen tenants te voorkomen).tenant_id bevatten zodat cross-tenant relaties niet per ongeluk ontstaan.Waar ondersteund (bijv. PostgreSQL) kan row-level security tenantchecks in de database plaatsen. Policies kunnen elke SELECT/UPDATE/DELETE beperken zodat alleen rijen die bij de huidige tenant horen zichtbaar zijn.
Dit vermindert de afhankelijkheid van "elke developer herinnert zich de WHERE-clause", en kan beschermen tegen bepaalde injection- of ORM-misbruikscenario's. Behandel RLS als een tweede slot, niet als het enige slot.
Als tenants hogere sensitiviteit of strengere compliance-eisen hebben, kan scheiden per schema (of per database) de blast radius verkleinen. De trade-off is verhoogde operationele overhead.
Ontwerp permissies zodat de default “geen toegang” is:
Deze controls werken het beste samen: sterke tenant-scoping, door de database afgedwongen policies waar mogelijk, en conservatieve privileges die de schade beperken wanneer iets misgaat.
Encryptie is een van de weinige controls die nog helpt wanneer andere isolatielagen falen. In een gedeelde datastore is het doel data te beschermen tijdens transport, in rust, en zodat je app kan bewijzen voor welke tenant hij optreedt.
Voor data in transit: vereis TLS voor elke hop: client → API, API → database en interne servicecalls. Dwing dit af op database-niveau waar mogelijk (bijv. niet-TLS-verbindingen weigeren) zodat "tijdelijke uitzonderingen" geen permanente uitzonderingen worden.
Voor data at rest: gebruik database- of opslagniveau-encryptie (managed disk encryption, TDE, versleutelde backups). Dit beschermt tegen verloren media, snapshot-exposure en sommige infrastructuurcompromissen—maar het voorkomt geen foutieve query die rijen van een andere tenant teruggeeft.
Een enkele gedeelde encryptiesleutel is eenvoudiger (minder sleutels om te roteren, minder faalmodi). Het nadeel is de blast radius: als die sleutel lek raakt, zijn alle tenants blootgesteld.
Per-tenant sleutels verkleinen de blast radius en helpen bij klantvereisten (sommige ondernemingen willen tenant-specifieke sleutelcontrole). De trade-off is complexiteit: key lifecycle management, rotatieschema's en supportworkflows (bijv. wat gebeurt er als een tenant hun sleutel uitschakelt).
Een praktisch midden is envelope-encryptie: een masterkey versleutelt per-tenant data keys, waardoor rotatie beheersbaar blijft.
Bewaar database-credentials in een secrets manager, niet als omgevingsvariabelen in langlevende configs. Geef de voorkeur aan kortlevende credentials of automatische rotatie, en scope toegang per service role zodat een compromittering in één component niet automatisch elke database bereikt.
Behandel tenant-identiteit als security-critisch. Accepteer nooit een ruwe tenant-ID van de client als de waarheid. Bind tenant-context aan gesigneerde tokens en server-side autorisatiecontroles, en valideer die bij elke request vóór een database-aanroep.
Een multi-tenant database is een opzet waarbij meerdere klanten dezelfde database-infrastructuur delen (en vaak hetzelfde schema), terwijl de applicatie en/of database afdwingt dat elke tenant alleen zijn eigen data kan benaderen. De kernvereiste is strikte tenant-scoping op elke read en write.
De afweging is dat je opzettelijk isolatie- en prestatieguardrails moet bouwen.
Veelvoorkomende modellen (van meer isolatie naar meer delen):
Je keuze bepaalt de isolatiegrens en de operationele last.
Het grootste risico verschuift naar cross-tenant toegang veroorzaakt door routinefouten, niet alleen externe aanvallers. Tenant-context (zoals tenant_id) moet worden behandeld als een autorisatievereiste, niet als een optioneel filter. Houd ook rekening met productierealiteiten zoals concurrency, caching, retries en achtergrondjobs.
De meest voorkomende oorzaken zijn:
tenant_id bindenOntwerp guardrails zodat ongescopeerde queries moeilijk (of onmogelijk) uit te voeren zijn.
Row-level security (RLS) verplaatst tenantchecks naar de database met policies die SELECT/UPDATE/DELETE beperken tot rijen die bij de huidige tenant horen. Het vermindert de afhankelijkheid van "iedereen die de WHERE-clause onthoudt", maar moet gepaard gaan met app-laag scoping, least privilege en sterke tests. Zie RLS als een extra slot, niet als het enige slot.
Een praktisch basisniveau omvat:
tenant_id op tenant-eigen tabellentenant_id bevattenBehandel tenant-identiteit als security-critisch: vertrouw niet blind op een ruwe tenant-ID van de client; bind deze aan gesigneerde tokens en server-side controles.
Noisy neighbor ontstaat wanneer één tenant gedeelde resources (CPU, geheugen, I/O, verbindingen) opvreet, wat latentie voor anderen verhoogt. Praktische mitigaties:
Streef naar eerlijkheid, niet alleen maximale throughput.
Vergroot isolatie als je consequent ziet:
Hybride opties: carve-out van top-tier tenants in aparte databases/clusters, tiered plans (shared vs dedicated), of analytics/reporting verplaatsen naar aparte stores.
Het doel is fouten veilig te laten falen.