Tenant-isolatie voor MSP's: een tenant-ID of login is geen autorisatie

Een door de client aangeleverde tenant-ID, een X-Tenant-ID-header, een werkende login, een Conditional Access-beleid of een SSO-verbinding vertellen elk iets nuttigs — maar geen van alle bewijst op zichzelf dat de aanroeper de gegevens van een bepaalde klant mag zien. Deze gids is voor MSP's en IT-teams die multi-tenant platformen beheren of inkopen: hij laat, mechanisme voor mechanisme, zien waar een server-side autorisatiecontrole daadwerkelijk moet zitten, van het eerste verzoek tot de dag waarop een account wordt uitgeschreven.

Een tenant-ID selecteert alleen een klant, het autoriseert er geen

Een door de client aangeleverde tenant-ID — in een request body, een queryparameter, of afgeleid uit een subdomein — is een selector. Die vertelt de applicatie welke klantcontext geopend moet worden. Het OWASP Multi-Tenant Security Cheat Sheet legt de onderliggende regel vast: bind elk verzoek aan een geauthenticeerde principal, leid het tenant-lidmaatschap van die principal af uit server-side status, handhaaf controles op objectniveau binnen de tenant, en houd admin- of break-glass-paden gescheiden van gewone tenanttoegang. Die controle moet overal draaien waar een tenantgrens ertoe doet, niet alleen aan de voordeur van de API: bij lezen en schrijven, bij administratieve acties, en bij achtergrondtaken die werk oppakken nadat het oorspronkelijke verzoek is afgerond. Een door een wachtrij geactiveerde taak die een tenant-ID overneemt uit een bericht, zonder deze opnieuw te verifiëren, opent precies het gat weer dat de oorspronkelijke controle moest sluiten.

Een X-Tenant-ID-header of body-veld verbergt dezelfde valkuil

Dezelfde fout duikt op onder de naam van een header. Multi-tenant API's accepteren vaak een X-Tenant-ID-header of een tenantveld in de request body om te kiezen van welke klant een aanroep gegevens mag raken, en het is verleidelijk die waarde als voldoende te behandelen zodra hij correct wordt geparst. OWASP's richtlijnen noemen twee verwante valkuilen: aannemen dat een tenant-identifier veilig is omdat hij lang of moeilijk te raden is, in plaats van een echte autorisatiecontrole uit te voeren; en toestaan dat een verder tenant-gebonden codepad stilzwijgend terugvalt op een ongebonden query wanneer de verwachte waarde ontbreekt of onjuist is. Beide fouten laten een geauthenticeerde aanroeper die geen lid is van de opgevraagde tenant, bij gegevens van iemand anders komen.

Inloggen bewijst wie iemand is, niet welke tenant hij mag raken

Authenticatie beantwoordt een andere vraag dan isolatie. NIST Special Publication 800-210, over toegangscontrole voor cloudsystemen, behandelt tenant-isolatie als een eigenschap die het platform zelf moet afdwingen op elk API- en datapad wanneer één software-instantie veel tenants bedient, omdat de klant die de dienst gebruikt de onderliggende infrastructuur niet beheert. AWS's Well-Architected SaaS Lens beschrijft twee manieren waarop leveranciers dit bouwen: in een “silo”-model krijgt elke tenant eigen resources en een afgebakende uitvoeringsrol, eenvoudiger te doorgronden maar lastiger op grote schaal te draaien; in een “pool”-model delen tenants infrastructuur en moet isolatie binnen de applicatielogica bij elk verzoek worden afgedwongen. Geen van beide modellen is inherent veiliger. Wat telt, is of een leverancier concreet kan tonen hoe een verzoek aan de tenant van de aanroeper wordt gebonden voordat gegevens worden geraakt — niet dat de aanroeper een werkende login heeft.

Conditional Access beveiligt het inloggen, niet het datapad

Microsoft omschrijft Conditional Access als een Zero Trust-beleidsengine op basis van als-dan-logica: als een gebruiker, of steeds vaker een AI-agent, een resource probeert te bereiken, moet eerst aan een voorwaarde zoals apparaatcompliance, aanmeldrisico of locatie worden voldaan. Dat is een echt nuttige poort — die kan voorkomen dat een gecompromitteerde inlogcode überhaupt een sessie start, of een sessie afsnijden die verdacht gedrag begint te vertonen. Maar Conditional Access heeft geen zicht op hoe de backend van een applicatie, zodra een sessie bestaat, beslist welke records van welke klant een bepaalde API-aanroep mag lezen of schrijven. Als een platform voor die beslissing vertrouwt op een door de client aangeleverde tenantwaarde, heeft Conditional Access zijn werk dan al gedaan — succesvol, en irrelevant voor de fout. Een goed geconfigureerde inlogpoort voor een slecht geïsoleerde API veroorzaakt hetzelfde datalek als zonder die poort. Microsofts Agent 365-licentie breidt Conditional Access uit naar AI-agents, maar hetzelfde onderscheid tussen inloggen en gegevenstoegang blijft daar ook gelden.

SSO laat mensen binnen; alleen SCIM laat vertrekkers eruit

Federatie beantwoordt de vraag “wie mag nu inloggen?”. Het System for Cross-domain Identity Management, gestandaardiseerd als RFC 7644, beantwoordt een andere vraag: welke accounts zouden nog moeten bestaan. Microsofts SCIM-provisioningdocumentatie beschrijft de gebruikelijke gang van zaken: een soft-delete bij de identiteitsprovider zet het active-attribuut van een gebruikersresource op false, en de ontvangende applicatie wordt geacht die plek daarop uit te schakelen of te archiveren. Zonder een SCIM-integratie stopt de single sign-on van een vertrekker weliswaar met werken, maar diens plek — en eventuele resterende API-toegang die daaraan gekoppeld is — kan onaangeroerd blijven bestaan. Ook de provisioningkant heeft een eigen scope nodig: een SCIM-bearer-token zou per klanttenant moeten worden uitgegeven en alleen geaccepteerd op het eigen SCIM-eindpunt van die tenant. Eén multi-tenant SCIM-geheim delen tussen meerdere klanten maakt van één gelekt token een risico op deprovisioning en accountovername over klanten heen.

Het account uitschakelen beëindigt sessie noch token

Wanneer iemand vertrekt en een beheerder diens account bij de identiteitsprovider uitschakelt, ligt de aanname voor de hand dat het werk klaar is. Microsofts eigen richtlijnen over het intrekken van toegang zeggen iets anders: het uitschakelen van een account blokkeert nieuwe aanmeldingen, maar maakt niet automatisch reeds uitgegeven refresh-tokens, actieve sessies of browsercookies ongeldig. Om toegang echt af te snijden, moet een beheerder sessies en tokens apart intrekken en gecachete gegevens wissen — en waar beschikbaar, dwingt Continuous Access Evaluation die afsnijding sneller af dan wachten tot een token vanzelf verloopt. NIST's conceptrichtlijn voor sessiebeheer maakt een verwant punt: het bezit van een geldig toegangstoken is geen bewijs dat een sessie nog legitiem open is, en sessies bij de identiteitsprovider en bij de applicatie staan los van elkaar — de ene beëindigen, beëindigt de andere niet automatisch. Daarom eist het OWASP Session Management Cheat Sheet server-side sessie-invalidatie met zowel idle- als absolute timeouts, in plaats van te vertrouwen op de client om gegevens weg te gooien.

Sommige MSP's laten dit control-plane-werk liever door een gespecialiseerde leverancier doen dan het zelf te bouwen en te auditeren; Auris is een Europees IAM-as-a-Service-platform voor adaptieve MFA, gefedereerde SSO en onveranderlijke audittrails.

Wat te doen

• Leid tenant-lidmaatschap bij elk verzoek af uit server-side identiteitsgegevens; vertrouw nooit alleen op een door de client aangeleverde ID, header of body-veld.
• Dwing die controle af op elk pad waar een tenantgrens een rol speelt: lezen, schrijven, administratieve acties en achtergrond- of wachtrij-getriggerde taken.
• Wijs elke tenant-selector af die niet is bevestigd tegen de daadwerkelijke lidmaatschappen van de geauthenticeerde aanroeper, in plaats van aan te nemen dat een lange identifier veilig is.
• Behandel Conditional Access, SSO en tenant-binding als aparte controles met aparte faalmodi, en test ze elk afzonderlijk.
• Zet SCIM naast SSO op, beperk elk SCIM-token tot één tenant, en bevestig dat het account van een vertrekker ook in het bronsysteem wordt uitgeschakeld, niet alleen bij de identiteitsprovider.
• Trek bij offboarding sessies en refresh-tokens expliciet in op elke applicatie die de persoon gebruikte, in plaats van te stoppen bij “account uitgeschakeld”.

Bronnen: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — overzicht van Conditional Access, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.