Multi‑tenant: test af adskillelsen mellem kunderne

Når mange kunder deler det samme produkt, er grænsen mellem dem det, som hver enkelt kunde stoler mest på og kan kontrollere mindst. Svaret på, om grænsen holder, hviler på en penetrationstest, hvor testeren arbejder som flere kunder på én gang og forsøger at nå det, der tilhører de andre. En sådan test er den mest direkte dokumentation, et softwarehus kan give for adskillelsen, men kun hvis den er bestilt med det formål og beskrevet sådan i rapporten.

Kort sagt: testen skal have mindst to kunder at arbejde med, adskillelsen skal stå i omfanget som et selvstændigt mål, og rapporten skal sige tydeligt, hvad der blev forsøgt, og med hvilket resultat.

Hvorfor kunderne spørger til netop adskillelsen

En kunde kan selv styre sine egne brugere, sine adgangskoder og sin egen opsætning. Grænsen til de andre kunder i produktet kan kunden hverken se eller påvirke. Den er helt jeres ansvar, og en fejl i den rammer ikke én kunde, men potentielt alle.

Derfor kan adskillelsen være det første, kundens sikkerhedsfolk kigger efter i rapporten. Den britiske NCSC har gjort adskillelse mellem kunder til et af sine principper for sikker brug af cloudtjenester og peger på, at leverandøren skal kunne forklare, hvordan grænserne virker, og at regelmæssige penetrationstest er en af de former for dokumentation, kunden kan se efter. Det er også der, mange kundespørgsmål starter. → Spørgsmål om adskillelse af kundernes data

Hvad testen afprøver

En test af adskillelsen er ikke en særskilt teknik, men en bestemt måde at se på hele produktet. Testeren logger ind som en bruger hos kunde A og undersøger, om noget af det, der hører til kunde B, kan ses, ændres eller slettes. Det gælder ikke kun skærmbillederne, men alle de veje, data kan nås ad:

Visninger og søgning · kan en liste, et filter eller en søgning vise poster fra en anden kunde?
Direkte henvisninger · kan en bruger hente en bestemt post, et dokument eller et billede, der tilhører en anden kunde?
API’et · gælder samme kontrol, når produktet bruges uden om brugerfladen?
Eksport og rapporter · samler en rapportfunktion data på tværs af kunder?
Notifikationer og mails · kan en besked med en anden kundes oplysninger havne det forkerte sted?

OWASP beskriver svigt i adgangskontrollen på objektniveau som en udbredt risiko for API’er, netop fordi følgen kan være adgang til andre brugeres data. I et produkt med mange kunder er de andre brugere typisk de andre kunder.

Det, I aftaler før testen

Testen af adskillelsen kræver forberedelse fra jer. Testeren skal have adgang som mindst to kunder, og hver kunde skal have data, som det giver mening at forsøge at nå. Tomme kunder giver et tomt resultat. Hvor mange kunder og hvilke roller der skal med, er et valg, I træffer sammen med testeren. → Testlejere: én eller flere kunder i produktet

Aftal desuden:

Målet · at adskillelsen er et eget mål i omfanget, så rapporten kan sige noget om den.
Roller hos hver kunde · både almindelige brugere og kundeadministratorer, fordi grænsen kan holde for den ene og ikke for den anden.
Miljøet · om testen foregår i produktionen eller i et miljø, der er bygget som produktionen.
De rigtige kunder · at testeren aldrig bevæger sig ind i rigtige kunders data, og hvad der sker, hvis det alligevel ser ud til at være muligt.

Det sidste punkt er vigtigt i et delt miljø. Hvis testen viser, at grænsen kan krydses, skal testeren stoppe og melde det, ikke se efter, hvad der ligger på den anden side.

Steder, hvor grænsen let bliver overset

Adskillelsen kan være tænkt grundigt igennem i kernefunktionerne. Den kan blive glemt i det, der kom til senere: en fælles filopbevaring, et baggrundsjob, der sender rapporter, en søgefunktion på tværs af moduler, en integration, der henter data ind for flere kunder ad gangen.

Jeres egne medarbejderes adgang er en særlig sag. Support og drift skal i nogle situationer kunne se en kundes data, og det er en bevidst åbning i grænsen. Den hører med i testen, men som sit eget emne. → Supportadgang og administrationsmodul

Overvej også kunder, der har en særlig opsætning, og funktioner, der kun er slået til for nogle. Hvis testkunderne har standardopsætningen, siger resultatet mindst om de kunder, der skiller sig ud.

Når testen finder et hul i adskillelsen

Et fund, hvor én kunde kan nå en anden kundes data, er alvorligt for jer, uanset hvordan det scores teknisk. Kunderne vil se det som et brud på selve forudsætningen for at bruge produktet.

Rækkefølgen er derfor: ret fundet, få rettelsen bekræftet, og vurder, om hullet har været brugt. Den sidste del kræver, at I ser i jeres egne logs, ikke kun i testerens rapport. Spørgsmålet om, hvorvidt og hvordan kunderne skal informeres, afhænger af jeres kontrakter og af, hvad I finder. → Testen finder noget alvorligt: skal kunderne have besked?

Se også på årsagen. Et hul i adskillelsen kan være mere end en enkelt fejl; det kan være et tegn på, at kontrollen sidder flere steder og ikke ét fælles sted. Den indsigt er mere værd for udviklingsteamet end selve fundet, fordi den peger på, hvor det næste hul kan opstå.

I rapporten, der senere vises til kunder, skal fundet ikke skjules. Et rettet og retestet fund på adskillelsen viser, at testen faktisk så efter, og at I handlede.

Det skal I lade være med

Teste med én kunde · så kan rapporten intet sige om grænsen mellem kunderne.
Lade testkunderne være tomme · testeren skal have noget at forsøge at nå.
Nævne adskillelsen i salget uden at have den i omfanget · kunden læser omfanget og ser forskellen.
Glemme funktionerne på kanten · rapporter, filer, søgning og baggrundsjob hører med.
Lade testeren arbejde mod rigtige kunder uden en klar stopregel · aftal på forhånd, hvad der sker ved et fund.
Love kunderne, at data ikke kan blandes · en test viser, hvad der blev fundet, ikke hvad der aldrig kan ske.

Hvad kan og ikke kan konkluderes

En test uden fund på adskillelsen viser, at testeren ikke kunne krydse grænsen mellem de testkunder, der var sat op, med de roller og i den version, der var med. Den siger ikke noget om dele af produktet uden for omfanget eller om senere ændringer. → Omfangsafsnittet: det første, kundens sikkerhedsfolk læser

Tjekliste til testen af adskillelsen

☐ Står adskillelsen som et eget mål i omfanget?
☐ Har testeren adgang som mindst to kunder med data i begge?
☐ Er både brugere og kundeadministratorer med hos hver kunde?
☐ Er filer, rapporter, søgning og API med?
☐ Er der en aftalt stopregel, hvis grænsen kan krydses?
☐ Er det besluttet, hvordan et fund på adskillelsen håndteres over for kunderne?

Kilder

NCSC (UK): Principle 3, Separation between customers: adskillelse mellem kunder som princip for cloudtjenester, og penetrationstest som en form for dokumentation.
OWASP API Security Top 10 2023: Broken Object Level Authorization: manglende kontrol af adgangen til det enkelte objekt, med adgang til andre brugeres data som mulig følge.

Senest gennemgået: oktober 2026.