Klientisolering för MSP:er: ett tenant-ID eller en inloggning är inte auktorisering

Ett klienttillhandahållet tenant-ID, en X-Tenant-ID-header, en fungerande inloggning, en policy för villkorlig åtkomst eller en SSO-anslutning talar var och en om något användbart — men ingen av dem bevisar på egen hand att den som anropar får se en viss kunds data. Den här guiden är för MSP:er och IT-team som driver eller köper multi-tenant-plattformar: den visar, mekanism för mekanism, var en server-side auktoriseringskontroll faktiskt måste sitta, från den första begäran till dagen ett konto avslutas.

Ett tenant-ID väljer bara ut en kund, det auktoriserar ingen

Ett tenant-ID som skickas av klienten — i begärans body, i en query-parameter, eller härlett från en subdomän — är en selektor. Det talar om för applikationen vilken kundkontext som ska öppnas. OWASP Multi-Tenant Security Cheat Sheet slår fast den underliggande regeln: bind varje begäran till en autentiserad principal, härled den principalens tenant-medlemskap från server-side-tillstånd, tillämpa kontroller på objektnivå inuti tenanten, och håll admin- eller nödvägar separata från vanlig tenant-åtkomst. Den kontrollen måste köras överallt en tenant-gräns spelar roll, inte bara vid API:ets ytterdörr: vid läsningar och skrivningar, vid administrativa åtgärder, och vid bakgrundsjobb som tar över arbete efter att den ursprungliga begäran avslutats. Ett kötriggat jobb som ärver ett tenant-ID från ett meddelande, utan att omverifiera det, öppnar exakt den lucka den ursprungliga kontrollen skulle stänga.

En X-Tenant-ID-header eller ett body-fält döljer samma fälla

Samma misstag dyker upp under en headers namn. Multi-tenant-API:er accepterar ofta en X-Tenant-ID-header eller ett tenant-fält i begärans body för att välja vilken kunds data ett anrop ska röra, och det är frestande att behandla det värdet som tillräckligt så snart det tolkas korrekt. OWASP:s vägledning pekar ut två relaterade fallgropar: att anta att en tenant-identifierare är säker för att den är lång eller svår att gissa, i stället för att köra en riktig auktoriseringskontroll; och att låta en annars tenant-bunden kodväg tyst falla tillbaka på en obegränsad fråga när det förväntade värdet saknas eller är felformat. Båda felen låter en autentiserad anropare, som inte tillhör den begärda tenanten, nå data som tillhör någon annan.

Inloggning bevisar vem någon är — inte vilken tenant de får röra

Autentisering svarar på en annan fråga än isolering. NIST Special Publication 800-210, om åtkomstkontroll för molnsystem, behandlar tenant-isolering som en egenskap som själva plattformen måste upprätthålla på varje API- och dataväg när en enda mjukvaruinstans betjänar många tenanter, eftersom kunden som använder tjänsten inte kontrollerar den underliggande infrastrukturen. AWS Well-Architected SaaS Lens beskriver två sätt leverantörer bygger detta på: i en “silo”-modell får varje tenant dedikerade resurser och en avgränsad exekveringsroll, enklare att resonera kring men svårare att driva i stor skala; i en “pool”-modell delar tenanter infrastruktur och isolering måste upprätthållas inuti applikationslogiken vid varje begäran. Ingen av modellerna är i sig säkrare. Det som avgör är om en leverantör konkret kan visa hur en begäran binds till anroparens egen tenant innan någon data rörs — inte att anroparen har en fungerande inloggning.

Villkorlig åtkomst säkrar inloggningen, inte datavägen

Microsoft beskriver villkorlig åtkomst som en Zero Trust-policymotor byggd på om-så-logik: om en användare, eller alltmer en AI-agent, försöker nå en resurs, måste ett villkor som enhetsefterlevnad, inloggningsrisk eller plats uppfyllas först. Det är en genuint användbar grind — den kan hindra en komprometterad autentiseringsuppgift från att ens starta en session, eller stänga av en session som börjar bete sig misstänkt. Men den har ingen insyn i hur en applikations egen backend, när en session väl finns, bestämmer vilka poster hos vilken kund ett givet API-anrop får läsa eller skriva. Om en plattform litar på ett klienttillhandahållet tenant-värde för att fatta det beslutet har villkorlig åtkomst redan avslutat sitt jobb, framgångsrikt och utan relevans för felet, vid den tidpunkt beslutet fattas. En välkonfigurerad inloggningsgrind framför ett dåligt isolerat API ger samma dataläcka som den skulle ge utan grinden. Microsofts Agent 365-licensiering utvidgar villkorlig åtkomst till AI-agenter, men samma skillnad mellan inloggning och dataåtkomst gäller även där.

SSO släpper in människor; bara SCIM släpper ut dem som slutar

Federation svarar på “vem får logga in just nu?”. System for Cross-domain Identity Management, standardiserat som RFC 7644, svarar på en annan fråga: vilka konton som fortfarande borde finnas kvar. Microsofts SCIM-provisioneringsdokumentation beskriver det vanliga flödet: en mjuk radering hos identitetsleverantören sätter en användarresurs active-attribut till false, och den mottagande applikationen förväntas inaktivera eller arkivera den platsen som svar. Utan en SCIM-integration slutar en avslutad medarbetares single sign-on att fungera, men platsen — och eventuell kvarvarande API-åtkomst kopplad till den — kan bestå orörd. Provisioneringssidan behöver också sin egen avgränsning: en SCIM-bearer-token bör utfärdas per kundtenant och accepteras enbart vid den tenantens egen SCIM-slutpunkt. Att dela en enda multi-tenant SCIM-hemlighet mellan flera kunder gör en enda läckt token till en risk för deprovisionering och kontooövertagande mellan olika kunder.

Att inaktivera kontot avslutar varken sessionen eller token

När någon slutar och en administratör inaktiverar personens konto hos identitetsleverantören är det lätt att anta att jobbet är klart. Microsofts egen vägledning om att återkalla åtkomst säger något annat: att inaktivera ett konto blockerar nya inloggningar men ogiltigförklarar inte automatiskt redan utfärdade uppdateringstoken, aktiva sessioner eller webbläsarkakor. Att verkligen skära av åtkomsten kräver att sessioner och token återkallas separat och att cachade autentiseringsuppgifter rensas — och där det finns tillgängligt tillämpar Continuous Access Evaluation avskärningen snabbare än att vänta på att en token löper ut naturligt. NIST:s utkast till vägledning om sessionshantering gör en relaterad poäng: att inneha en giltig åtkomsttoken är inte ett bevis på att en session fortfarande är legitimt öppen, och identitetsleverantörens sessioner och applikationens sessioner är oberoende av varandra, så att avsluta den ena avslutar inte automatiskt den andra. Det är därför OWASP Session Management Cheat Sheet kräver server-side-ogiltigförklaring av sessioner med både inaktivitets- och absoluta timeouts, i stället för att lita på att klienten kastar bort autentiseringsuppgifterna.

Vissa MSP:er föredrar att lämna över det här kontrollplansarbetet till en dedikerad leverantör i stället för att bygga och granska det själva; Auris är en europeisk IAM-as-a-Service-plattform för adaptiv MFA, federerad SSO och oföränderliga granskningsloggar.

Vad du bör göra

• Härled tenant-medlemskap från server-side-identitetsdata vid varje begäran; lita aldrig enbart på ett klienttillhandahållet ID, en header eller ett body-fält.
• Tillämpa den kontrollen på varje väg där en tenant-gräns är inblandad: läsningar, skrivningar, administrativa åtgärder och bakgrunds- eller kötriggade jobb.
• Avvisa varje tenant-selektor som inte bekräftats mot den autentiserade anroparens faktiska medlemskap, i stället för att anta att en lång identifierare är säker.
• Behandla villkorlig åtkomst, SSO och tenant-bindning som separata kontroller med separata felmoder, och testa var och en för sig.
• Sätt upp SCIM vid sidan av SSO, avgränsa varje SCIM-token till en enda tenant, och bekräfta att en avslutad medarbetares konto inaktiveras även i källsystemet, inte bara hos identitetsleverantören.
• Vid offboarding, återkalla uttryckligen sessioner och uppdateringstoken i varje applikation personen använt, i stället för att stanna vid “kontot inaktiverat”.

Källor: OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — översikt över villkorlig åtkomst, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.