Het toevoegen van een tenant-ID aan elke tabel is een nuttige eerste stap. Op zichzelf zorgt dit echter nog niet voor het isoleren van een SaaS-toepassing. Gegevens worden namelijk ook verwerkt via cache-items, werkberichten, zoekindexen, objectopslag en beheerinterfaces.
Ik beschouw isolatie als een eigenschap van het gehele verzoek en de daaropvolgende verwerking ervan. Bij elke grens moet het systeem weten wiens gegevens het verwerkt en waarom de huidige bewerking toestemming heeft om deze te verwerken.
De context van de tenant op de server instellen
Een door de browser verstrekte tenant-ID is een aangevraagde reikwijdte, geen bewijs van lidmaatschap. De applicatie moet de geauthenticeerde gebruiker identificeren, de toegang tot die tenant verifiëren en een autorisatiecontext tot stand brengen voordat bedrijfsgegevens worden geladen.
Die context moet expliciet worden weergegeven in de grenzen van de service. Een verborgen globale status maakt het moeilijker om inzicht te krijgen in geplande taken en gelijktijdige verzoeken. Een worker moet voldoende informatie ontvangen om zijn eigen geautoriseerde bereik te bepalen, in plaats van aannames over te nemen uit het oorspronkelijke HTTP-verzoek.
Database-opzoekingen moeten die reikwijdte weerspiegelen. Bij het laden van een gesprek wil ik dat de query zowel de identiteit als de tenant ervan beperkt. Als een record globaal wordt opgehaald en de eigenaar pas later wordt gecontroleerd, neemt de kans toe dat een ander codepad het per ongeluk eerder gebruikt.
Gebruik de database als een extra grens
PostgreSQL ondersteunt beveiligingsbeleidsregels op rijniveau, waaronder standaardweigering wanneer rijbeveiliging is ingeschakeld en er geen toepasselijk beleid is dat toegang toestaat. In de documentatie wordt ook een belangrijk onderscheid gemaakt: supergebruikers en rollen met omzeilingsrechten zijn niet aan deze regels gebonden, en tabeleigenaren omzeilen de beleidsregels doorgaans.
Dat betekent dat een overtuigende beleidsdefinitie slechts een onderdeel van het ontwerp is. De daadwerkelijke rol van de applicatie in de database, de migratiefunctie, het gebruik van een verbindingspool en het transactiegedrag zijn allemaal van belang. Ik zou het beleid controleren met dezelfde rechten als de actieve applicatie.
Als de context van de tenant via de verbindingsinstellingen wordt doorgegeven, is bij verbindingen uit de pool bijzondere aandacht vereist. De context moet via een betrouwbaar pad worden ingesteld, op de juiste manier worden afgebakend en mag niet doorsijpelen naar het volgende verzoek. Beveiliging op rijniveau biedt extra bescherming, maar is geen vervanging voor inzicht in de levenscyclus van de verbinding.
Neem ook de plaatsen buiten SQL mee
Een cache-sleutel zoals conversation:123 gaat ervan uit dat de identificatiecode wereldwijd uniek is en dat elke aanroeper dezelfde toegangsregels hanteert. Een expliciete tenantcomponent maakt de eigendomsgrens zichtbaar en vermindert onbedoelde conflicten.
Zoeken en ophalen vereisen dezelfde discipline. Filters op huurder en toegang horen thuis in de selectie van kandidaten. Door pas na een algemene top-k-zoekopdracht te filteren, kunnen geldige kandidaten verloren gaan, en het toelaten van ongeautoriseerde tekst in de herrangschikking of de modelcontext is op zich al een openbaarmaking.
Ook opslagpaden voor objecten, exporttaken, gebruikstellers en meldingswachtrijen moeten de context van de tenant bevatten. Een applicatie kan haar interactieve schermen beveiligen, maar toch gegevens lekken via een CSV-export op de achtergrond.
Test met huurders die bewust op elkaar lijken
Ik geef de voorkeur aan isolatietests waarbij gebruik wordt gemaakt van twee tenants met overlappende namen, vergelijkbare documenten en overeenkomende externe identificatiecodes. Hierdoor komen onbedoelde globale zoekopdrachten gemakkelijker aan het licht dan bij een dataset waarin elke waarde duidelijk uniek is.
- Vraag het dossier van een andere huurder rechtstreeks op aan de hand van het ID-nummer.
- Zoek naar tekst die alleen in de kennisbank van de andere tenant voorkomt.
- Een in de cache opgeslagen antwoord hergebruiken na het wisselen van geautoriseerde werkruimten.
- Een worker-bericht met niet-overeenkomende metadata over de eigenaar opnieuw afspelen.
- Probeer eens te exporteren via een rol met beperkte toegang.
Ik test ook ondersteunende tools. Omwille van het administratieve gemak worden in het product vaak de meest uitgebreide machtigingen ingesteld; daarom moet toegang tussen verschillende tenants weloverwogen, beperkt en controleerbaar zijn.
Een tenantgrens is betrouwbaar wanneer deze zowel in de normale verwerkingspaden als in de herstelpaden intact blijft. Het gaat er niet alleen om of de hoofd-API correct is afgebakend, maar ook of bij elke latere kopie en elk later gebruik van de gegevens die afbakening behouden blijft.
Bijgewerkt op 25 september 2026.