Bij multi-tenant software gebruiken meerdere klanten dezelfde applicatie, terwijl hun gegevens gescheiden moeten blijven. Lees hoe gedeelde databases, aparte schema’s en afzonderlijke databases zich tot elkaar verhouden, en welke keuzes nodig zijn voor tenantidentificatie, autorisatie en beheer.
Gegevensisolatie begint bij het dreigingsmodel
Gegevensisolatie betekent dat een tenant alleen de gegevens kan benaderen die bij die tenant horen. Dat klinkt als een databasevraag, maar de database-indeling is slechts één laag van de beveiliging. Een fout in een API, achtergrondtaak, export of beheerfunctie kan gegevens alsnog over tenantgrenzen heen beschikbaar maken. Breng daarom eerst in kaart welke gebruikers, processen en beheerders toegang nodig hebben, en via welke onderdelen gegevens worden gelezen of gewijzigd.
Maak onderscheid tussen toevallige fouten en bewuste pogingen om grenzen te doorbreken. Een vergeten filter in een rapportage kan een programmeerfout zijn; het aanpassen van een tenant-ID in een verzoek kan een gerichte aanval zijn. Beide scenario’s vragen om maatregelen op meerdere niveaus. Denk aan autorisatie in de applicatie, beperkingen in de database, gecontroleerde toegang voor beheerders en tests die expliciet controleren op toegang tot andere tenants.
Leg ook vast wat de gevolgen zijn van een incident. Een omgeving met uitsluitend niet-gevoelige configuratiegegevens heeft andere eisen dan een toepassing met personeels-, financiële of medische informatie. Dat beïnvloedt onder meer logging, bewaartermijnen, versleuteling en de keuze tussen gedeelde of gescheiden opslag. Een concreet dreigingsmodel voorkomt dat de databasekeuze wordt behandeld als een geïsoleerde technische voorkeur.
Gedeelde database met tenant-ID’s in tabellen
Bij een gedeelde database gebruiken alle tenants dezelfde tabellen. Een kolom zoals tenant_id geeft aan bij welke klant een record hoort. Deze indeling is compact en sluit goed aan op applicaties waarin veel tenants vergelijkbare gegevensstructuren hebben. Tabellen, databaseverbindingen en migraties hoeven niet per klant te worden aangemaakt. Ook kunnen gezamenlijke rapportages en onderhoudstaken eenvoudiger worden uitgevoerd.
De centrale uitdaging is dat iedere query correct op tenant moet filteren. Eén vergeten voorwaarde kan records van andere klanten tonen of wijzigen. Dat risico neemt toe wanneer query’s verspreid staan over controllers, achtergrondtaken, exports en ad-hoc rapportages. Centraliseer daarom tenantfilters waar dat kan, bijvoorbeeld in repositories of een expliciete datatoegangslaag. Voeg de tenant-ID ook toe aan relevante unieke sleutels en indexen. Een e-mailadres kan bijvoorbeeld uniek zijn binnen één tenant, zonder dat het in de hele installatie uniek hoeft te zijn.
Databasebeperkingen kunnen de bescherming versterken. Row-level security kan regels afdwingen op rijniveau, mits de applicatie de tenantcontext betrouwbaar instelt en verbindingen correct worden opgeschoond. Gebruik daarnaast tests waarin dezelfde identifiers bij verschillende tenants voorkomen. Zo wordt zichtbaar of code onbedoeld op een globale sleutel vertrouwt. Deze aanpak biedt efficiënt gebruik van infrastructuur, maar vraagt om discipline in iedere route waar data wordt opgehaald.
Aparte schema’s per tenant als tussenvorm
Met aparte schema’s staan de tabellen van verschillende tenants in dezelfde database, maar onder afzonderlijke schema-namen. De indeling biedt een zichtbare grens tussen klantgegevens zonder dat voor iedere tenant een aparte databaseverbinding nodig is. Dit kan passen bij toepassingen waarin klanten dezelfde datastructuur gebruiken, maar een duidelijker scheiding nodig hebben dan een tenantkolom in gedeelde tabellen.
Een schema per tenant verplaatst een deel van het probleem naar beheer en queryselectie. De applicatie moet voor iedere bewerking het juiste schema gebruiken. Een onjuist ingestelde zoekvolgorde kan queries naar een ander schema laten verwijzen dan bedoeld. Dynamische schema-namen mogen daarom niet rechtstreeks uit invoer van gebruikers komen; selecteer ze uit vertrouwde tenantmetadata en valideer ze volgens vaste regels. Ook moeten migraties alle schema’s consistent bijwerken, anders kunnen tenants ongemerkt op verschillende versies draaien.
De database blijft een gedeeld operationeel domein. Een storing, capaciteitslimiet of onjuiste configuratie kan meerdere tenants tegelijk raken. Back-ups en herstel op het niveau van één schema zijn bovendien afhankelijk van de mogelijkheden van het gebruikte databasesysteem en de herstelprocedure. Onderzoek of die procedure in de praktijk selectief en herhaalbaar uitvoerbaar is. Aparte schema’s zijn dus geen automatische beveiligingsgarantie: toegangsrechten, applicatielogica en beheerprocessen bepalen mede hoe sterk de scheiding werkelijk is.
Afzonderlijke databases per tenant
Bij een database per tenant krijgt iedere klant een eigen database. Daardoor zijn gegevens fysiek of logisch sterker gescheiden binnen het databasesysteem. Het model kan geschikt zijn wanneer tenants verschillende eisen stellen aan opslag, herstel, regio of databasecapaciteit. Ook kan het onderzoek naar een incident overzichtelijker worden, omdat duidelijker is welke database bij een tenant hoort.
De scheiding brengt extra beheerwerk met zich mee. De applicatie moet de juiste databaseverbinding selecteren en beheren, terwijl migraties, back-ups, monitoring en herstel voor alle databases moeten worden georganiseerd. Handmatige uitvoering wordt kwetsbaar zodra het aantal tenants groeit. Automatiseer daarom provisioning en controleerbare migratieruns, met registratie van de databases waarop een wijziging is toegepast. Houd ook rekening met verschillen tussen tenants die tijdelijk achterlopen; applicatiecode moet dan mogelijk meerdere databaseschema-versies ondersteunen.
Een aparte database maakt fouten in tenantselectie niet onmogelijk. Een verkeerd gekoppelde configuratie kan een verzoek nog steeds naar de database van een andere klant sturen. Behandel de koppeling tussen tenant en database daarom als beveiligingsgevoelige configuratie, met beperkte schrijfrechten en controleerbare wijzigingen. Bepaal daarnaast hoe gezamenlijke functies werken, zoals rapportages over meerdere klanten of centrale gebruikersidentiteiten. Dat soort functionaliteit vereist expliciete toegangspaden en mag niet ontstaan door databases zonder onderscheid samen te voegen.
Tenantidentificatie in verzoeken en achtergrondtaken
Voordat een applicatie gegevens kan isoleren, moet zij weten voor welke tenant een verzoek wordt uitgevoerd. Die identiteit kan worden afgeleid uit een domeinnaam, een organisatiekeuze na inloggen, een API-sleutel of claims in een identiteitstoken. De bron verschilt per product, maar de tenantcontext moet na vaststelling op een gecontroleerde manier door de applicatie worden doorgegeven. Een tenant-ID die een client meestuurt, is op zichzelf geen bewijs dat de gebruiker toegang heeft tot die tenant.
Valideer de geselecteerde tenant altijd tegen de geauthenticeerde identiteit en de actuele lidmaatschappen. Een gebruiker kan toegang hebben tot meerdere organisaties, maar niet noodzakelijk tot alle organisaties die via een URL of verzoekparameter worden genoemd. Leg ook vast wat er gebeurt wanneer een domein, token en sessie verschillende tenants aanwijzen. Een expliciete afwijzing is veiliger dan een stilzwijgende keuze voor een standaardtenant.
Dezelfde regels gelden buiten het directe webverzoek. Een wachtrijbericht moet voldoende betrouwbare context bevatten om de tenant te bepalen, en een achtergrondtaak mag niet leunen op toevallige globale processtatus. Bij hergebruikte workers kan achtergebleven context een taak voor een andere tenant beïnvloeden. Geef tenantcontext daarom expliciet mee, controleer die bij verwerking en wis context na afloop. Voeg tenantinformatie toe aan logs en traces waar dat operationeel nodig is, maar voorkom dat zulke gegevens onnodig in foutmeldingen of externe monitoring terechtkomen.
Autorisatie voorkomt toegang over tenantgrenzen
Authenticatie stelt vast wie een gebruiker is; autorisatie bepaalt wat die gebruiker binnen een tenant mag doen. Een geldige tenantcontext is dus niet voldoende. De applicatie moet ook controleren of de gebruiker lid is van de tenant en of diens rol de gevraagde handeling toestaat. Die controle hoort niet alleen bij het laden van een pagina. Ook API-endpoints, downloads, exports, zoekfuncties en wijzigingen via achtergrondprocessen moeten dezelfde beleidsregels toepassen.
Vermijd autorisatie op basis van moeilijk te raden identifiers. Een UUID of lange sleutel kan het raden van records bemoeilijken, maar vervangt geen toegangscontrole. Controleer bij het ophalen van een object zowel de tenant als de benodigde rechten. Zo voorkom je dat een gebruiker een identifier uit een andere context gebruikt om gegevens op te vragen. Voor relaties tussen records geldt hetzelfde: een factuur mag bijvoorbeeld niet gekoppeld kunnen worden aan een klantrecord uit een andere tenant.
Beheerderstoegang vraagt een afzonderlijk model. Interne medewerkers kunnen soms ondersteuning bieden aan meerdere klanten, maar brede, permanente toegang vergroot de impact van misbruik of een accountcompromis. Werk met beperkte rollen, controleerbare toegang en logging van gevoelige handelingen. Tests moeten niet alleen bevestigen dat een bevoegde gebruiker toegang krijgt, maar ook dat een gebruiker met een andere rol of tenant wordt geweigerd. Negatieve autorisatietests zijn essentieel omdat veel fouten pas zichtbaar worden wanneer een grens actief wordt overschreden.
Migraties, back-ups en herstel per tenant
De database-indeling bepaalt hoe tenantgegevens worden bijgewerkt en hersteld. In een gedeelde database wordt een schemawijziging doorgaans één keer uitgevoerd, maar een fout kan direct alle tenants raken. Bij aparte schema’s of databases moet dezelfde wijziging op meerdere plaatsen plaatsvinden. Dat maakt volgorde, voortgangsregistratie en foutafhandeling belangrijk. Een migratieproces moet kunnen vaststellen welke tenants zijn bijgewerkt, welke zijn overgeslagen en welke een interventie nodig hebben.
Ontwerp wijzigingen waar mogelijk in stappen. Voeg eerst een compatibele structuur toe, laat applicatieversies tijdelijk met oud en nieuw omgaan en verwijder verouderde onderdelen pas wanneer gebruik daarvan is uitgesloten. Dit is vooral relevant wanneer tenantdatabases niet gelijktijdig kunnen worden bijgewerkt. Een migratie die op één database slaagt maar op andere faalt, mag niet leiden tot onduidelijke gedeeltelijke toestand. Leg daarom resultaten en foutmeldingen per tenant vast en maak hervatten veilig.
Back-up is pas bruikbaar wanneer herstel uitvoerbaar is. Onderzoek of één tenant afzonderlijk kan worden teruggezet zonder andere klantgegevens te overschrijven. Bij gedeelde tabellen kan dat een gecontroleerde export en terugplaatsing vereisen; bij losse databases kan herstel eenvoudiger lijken, maar blijven configuratie en versiebeheer onderdeel van de procedure. Test ook herstel van relaties, bestanden en metadata buiten de database. De tenantgrens moet tijdens herstel intact blijven, anders kan een technisch geslaagde terugzetactie alsnog gegevens verkeerd koppelen.
Tenantbeheer en operationele scheiding
Een tenant is meer dan een database-ID. In een beheermodel horen ook status, domeinen, gebruikerslidmaatschappen, instellingen, opslaglocatie en eventuele koppelingen met externe diensten thuis. Beperk welke onderdelen een beheerder kan wijzigen en registreer veranderingen die invloed hebben op toegang of gegevensroutering. Een foutieve wijziging van een domeinkoppeling of databaseadres kan immers verzoeken naar de verkeerde tenant laten leiden.
Maak levenscyclusstappen expliciet: aanmaken, activeren, tijdelijk blokkeren, wijzigen en verwijderen. Provisioning moet niet alleen opslag realiseren, maar ook rollen, basisinstellingen en monitoring configureren. Bij verwijdering moet duidelijk zijn welke gegevens worden verwijderd, welke wettelijke of operationele bewaarplichten gelden en hoe gekoppelde bestanden worden behandeld. Een tenant die is geblokkeerd, mag niet via een oude sessie, API-sleutel of achtergrondtaak alsnog toegang houden.
Operationele systemen moeten tenantcontext bruikbaar maken zonder die als enige bron van beveiliging te behandelen. Dashboards kunnen storingen per tenant tonen, terwijl toegangscontrole bepaalt wie die informatie ziet. Stel grenzen in voor intensief gebruik, zodat één tenant gedeelde capaciteit niet onbeperkt kan belasten. Bij gedeelde infrastructuur zijn quota en detectie van afwijkend gebruik relevant; bij afzonderlijke databases kunnen juist het aantal verbindingen en de gezamenlijke beheerlast oplopen. Door deze signalen per tenant te volgen, worden capaciteitsproblemen en configuratiefouten gerichter zichtbaar.
Veelgestelde vragen
Hoe kies ik de juiste databasearchitectuur voor mijn multi-tenant applicatie?
Kies de databasearchitectuur op basis van risico, herstelbehoeften en beheerlast, niet alleen op basis van het verwachte aantal tenants. Bepaal eerst hoeveel schade een tenantoverschrijdend incident kan veroorzaken en of klanten eisen stellen aan afzonderlijke opslag of datalocatie.
- Vergelijk de modellen op kosten, operationele complexiteit en mogelijkheden voor tenantgericht herstel.
- Test hoe migraties, rapportages en beheerfuncties in elk model werken.
- Begin met een model dat je team veilig kan beheren en plan vooraf hoe tenants later kunnen worden verplaatst.
Een kleine praktijkproef met representatieve gegevens en hersteltests maakt aannames over prestaties en beheer vaak eerder zichtbaar dan een theoretische vergelijking.
Hoe verplaats ik een tenant naar een aparte database zonder gegevensverlies?
Verplaats een tenant met een gecontroleerd migratieproces waarin je gegevens kopieert, controleert en pas daarna het verkeer omschakelt. Leg vooraf vast welke tabellen, bestanden, instellingen en externe koppelingen bij de tenant horen, zodat de verhuizing geen afhankelijke gegevens overslaat.
- Maak een consistente kopie en vergelijk aantallen, sleutels en belangrijke totalen met de bron.
- Beperk of pauzeer schrijfacties tijdens de laatste synchronisatie, of gebruik een gecontroleerd wijzigingslog.
- Schakel de tenant-routering pas om nadat controles slagen en houd een terugvalplan klaar.
Voer de procedure eerst uit in een testomgeving en meet hoe lang kopiëren en controleren werkelijk duren. Zo kun je downtime beperken zonder een ongeteste dubbele schrijfroute te introduceren.
Hoe voorkom ik dat één tenant de prestaties van andere tenants vertraagt?
Voorkom dat één tenant de prestaties van anderen domineert door gebruik te meten en grenzen te stellen aan gedeelde resources. Een gedeelde database kan technisch goed geïsoleerd zijn, maar zware rapportages, grote imports of veel achtergrondtaken kunnen alsnog capaciteit van andere klanten gebruiken.
- Stel limieten in voor verzoekfrequentie, gelijktijdige taken en omvangrijke exports.
- Gebruik wachtrijen met eerlijke verwerking, zodat één tenant niet alle workers bezet.
- Monitor responstijden, databasebelasting en wachtrijlengte per tenant.
Maak overschrijdingen zichtbaar en bepaal vooraf of je taken vertraagt, afwijst of naar een aparte capaciteit verplaatst. Test limieten met piekbelasting, zodat ze ook onder druk voorspelbaar werken.
Hoe beheer ik datalocatie-eisen voor verschillende tenants?
Beheer datalocatie-eisen door per tenant vast te leggen in welke regio gegevens mogen worden opgeslagen en verwerkt, en door die keuze technisch af te dwingen. Alleen een regionale database is niet voldoende als bestanden, back-ups, logs of externe verwerkingsdiensten buiten die regio terechtkomen.
- Registreer de toegestane regio als gecontroleerde tenantconfiguratie.
- Routeer opslag, back-ups en herstelacties op basis van die configuratie.
- Controleer ook de locaties van monitoring, exports en gekoppelde diensten.
Leg vast wat er gebeurt wanneer een regio niet beschikbaar is: uitwijken naar een andere regio kan in strijd zijn met de eis. Test daarom ook herstelprocedures en wijzigingen van regio, inclusief de verplaatsing en verificatie van bestaande gegevens.
Welke gegevens moet ik per tenant monitoren om problemen snel te herkennen?
Monitor per tenant vooral gegevens die helpen om fouten, capaciteitsproblemen en ongebruikelijke toegangspatronen te onderscheiden. Zonder tenantdimensie kunnen gemiddelden over de hele omgeving verbergen dat één klant structureel fouten ervaart of uitzonderlijk veel resources gebruikt.
- Meet foutpercentages, responstijden en aantallen verzoeken per tenant.
- Volg wachtrijvertraging, opslaggroei en mislukte achtergrondtaken.
- Registreer relevante wijzigingen in tenantstatus, domeinkoppelingen en gegevensroutering.
Beperk toegang tot deze informatie en voorkom dat gevoelige inhoud in logs belandt. Gebruik tenant-ID’s om incidenten te onderzoeken, maar stel bewaartermijnen en toegangsrechten zo in dat monitoring zelf geen onnodige gegevensbron wordt.
