Multi-tenant en security
Meerdere organisaties werken op hetzelfde platform, elk met de vertrouwelijke gegevens van hun klanten. Isolatie is daarmee geen feature maar een bestaansvoorwaarde.
Isolatie in de database, niet in de applicatie
Het uitgangspunt: de database weigert data die je niet mag zien, ongeacht wat de applicatie vraagt. Elke tabel heeft row-level security aan. Een fout in de frontend of een handmatig aangeroepen API kan de scheiding daarom niet omzeilen.
De policies steunen op twee serverside functies die op basis van de ingelogde gebruiker bepalen bij welke tenant die hoort en welke rol hij heeft. Die waarden komen nooit uit de aanvraag van de client — ze worden opgezocht. Een client die beweert bij een andere tenant te horen, verandert daarmee niets.
Omdat vrijwel alle tenant-gebonden policies via diezelfde functie lopen, werkt een aanpassing daar in één keer door op het hele platform. Een geschorste tenant bijvoorbeeld: zodra de status niet meer actief is, leveren alle policies nul rijen — zonder dat er negentig policies herschreven hoeven te worden.
Rollen
| Rol | Reikwijdte |
|---|---|
| platform_admin | Platformbeheer over tenants heen; werkt vanuit een eigen beheertenant |
| tenant_admin | Beheer binnen de eigen tenant: gebruikers, huisstijl, labels, prompts |
| tenant_user | Werkt in de canvassen van de eigen tenant |
| end_client_user | Beperkte deelnemer vanuit de geanalyseerde organisatie |
Verdediging in lagen
Rechtenverhoging wordt op drie niveaus tegengehouden:
- Policy — row-level security bepaalt welke rijen zichtbaar en wijzigbaar zijn.
- Kolomrechten en trigger — een gebruiker kan de eigen rol of tenant niet aanpassen, ook niet met een rechtstreekse databaseopdracht.
- Serverside controle — beheeracties lopen via functies die opnieuw valideren dat een beheerder niet buiten de eigen tenant muteert en geen platformrechten kan uitdelen.
Eén laag zou volstaan als hij foutloos is. Drie lagen betekent dat een fout in één laag niet meteen een datalek is.
Wat iemand zonder account kan zien
Vrijwel niets. Een bezoeker die niet is ingelogd kan precies één ding lezen: de openbare teksten en instellingen die het inlogscherm nodig heeft. Alles daarbuiten — elke tabel met inhoud van een organisatie, elke serverfunctie — is voor die bezoeker afgesloten, en een controle die na elke databasewijziging en elke nacht draait meldt het zodra dat verandert. Dat was niet altijd zo: in de zomer van 2026 bleek dat de standaardinstellingen van de databaseleverancier een niet-ingelogde bezoeker meer rechten gaven dan de bedoeling was, op tientallen tabellen. Dat is dichtgezet, de uitzonderingen zijn met naam en reden vastgelegd, en de controle die het terugkomen ervan signaleert is er gekomen uit precies dat incident.
Bewijs, geen belofte
Isolatie wordt getest en niet aangenomen:
- Een eigen reeks isolatietests draait tegen staging en controleert per rol wat wel en niet zichtbaar is.
- De suite heeft een eigen zelftest: hij weigert te draaien tegen een andere omgeving dan staging, en er wordt bewezen dat een kunstmatig ingebrachte fout de test daadwerkelijk rood maakt. Een testsuite die stilletjes niets meer test is gevaarlijker dan geen testsuite.
- De suite draait dagelijks en bij elke wijziging die de datalaag raakt.
Afscherming van het dossier
Zoeken naar bewijs in klantdocumenten is hard begrensd op het canvas waarin je werkt. Materiaal van een andere opdracht — laat staan een andere tenant — kan niet meekomen als bron.
Toegang tot productie
Rechtstreekse schrijftoegang tot de productiedatabase staat standaard dicht en wordt per taak expliciet geopend. Elke aanraking wordt vastgelegd in een niet-wijzigbaar logboek. Er is een back-upprocedure met een aantoonbaar geteste herstelprocedure — hersteld naar een aparte omgeving en vergeleken op schema en rijaantallen.