Spørgsmål om adskillelse af kundernes data

For en kunde, der overvejer et SaaS-produkt, er et af de vigtigste spørgsmål, om andre kunder i samme løsning kan se eller ændre deres data. Derfor kan spørgsmålet om adskillelse stå i et skema til softwareleverandører. Et godt svar hviler på en klar beskrivelse af, hvordan adskillelsen er bygget, hvor den håndhæves, og hvordan den er afprøvet.

Svaret skal altså indeholde to dele: modellen og dokumentationen. Modellen forklarer på begrebsniveau, hvordan kunderne holdes adskilt. Dokumentationen viser, at adskillelsen er efterprøvet, fx i en pentest, hvor netop adskillelsen var med i omfanget.

Hvad kunden vil vide

Bag de forskellige formuleringer ligger nogle få spørgsmål:

Hvor ligger data · har hver kunde sin egen database, eller deler kunderne én?
Hvor håndhæves adskillelsen · i databasen, i applikationen eller begge steder?
Hvem kan krydse grænsen · har jeres egne medarbejdere adgang til flere kunders data, og hvordan styres det?
Hvad med filer, logs og backup · er de også adskilt?
Er det testet · har nogen forsøgt at krydse grænsen, og med hvilket resultat?

Et svar, der kun siger “data er logisk adskilt”, efterlader de fleste af spørgsmålene ubesvaret. → Sikkerhedsspørgeskema fra kunden

Beskriv modellen på begrebsniveau

Der findes flere måder at holde kunder adskilt på i et SaaS-produkt, og ingen af dem er i sig selv rigtig eller forkert. Nogle produkter har en separat database pr. kunde. Andre har én fælles database, hvor hver række er mærket med kunden, og applikationen sørger for, at kun de rette rækker vises. Atter andre blander, fx med fælles database men separat lagring af filer.

Kunden har brug for at vide, hvilken model I bruger, og hvor kontrollen sidder. Hvis adskillelsen alene afhænger af, at applikationen altid husker at filtrere på kunden, er det vigtigt at sige det og at forklare, hvordan det sikres. Det er ikke en svaghed at have en fælles database; det er en svaghed at beskrive den, som om den var noget andet.

Undgå tekniske detaljer, der ikke hjælper kunden. Navne på tabeller, interne nøgler og arkitekturtegninger med servernavne hører ikke hjemme i et skema. → Multi-tenant: test af adskillelsen mellem kunderne

Jeres egne medarbejderes adgang

Nogle kunder spørger særskilt til, hvem hos leverandøren der kan se deres data. Supportmedarbejdere, udviklere og driftsfolk kan have brug for adgang i særlige situationer, og den adgang krydser per definition grænsen mellem kunderne.

Beskriv, hvem der har adgang, hvordan den tildeles, om den er tidsbegrænset, og om den logges. Hvis kunden selv skal godkende supportadgang, så sig det. Det kan være her, kunden har flest spørgsmål, fordi det er her, adskillelsen bevidst brydes. → Supportadgang og administrationsmodul

Hvad testen skal have vist

En påstand om adskillelse er lettest at tro på, når den er efterprøvet. I en pentest af et SaaS-produkt betyder det, at testeren har haft adgang som flere kunder og har forsøgt at nå data, der tilhører en anden kunde. OWASP beskriver i sin liste over de mest udbredte risici for API’er svagheder i adgangskontrollen på objektniveau, hvor et API ikke kontrollerer, om brugeren må tilgå netop det objekt, og hvor følgen kan være adgang til andre brugeres data. Det er den slags svagheder, en test af adskillelsen skal lede efter.

Når I svarer i skemaet, så nævn, om adskillelsen var med i omfanget af seneste test, og om der var fund. Hvis den ikke var med, så sig det, og overvej at tage den med næste gang. Kunden kan bede om omfangsafsnittet for at se, om testen faktisk så på adskillelsen. → Testlejere

Når modellen ændrer sig

Adskillelsen er ikke fast for altid. Et produkt kan starte med én fælles database og senere flytte store kunder til egne databaser, eller en ny funktion kan indføre et fælles lager for filer eller en søgefunktion, der går på tværs af data. Hver af de ændringer kan påvirke, hvordan grænsen mellem kunderne håndhæves.

Når modellen ændrer sig, skal svaret i svarbiblioteket også ændres, og de kunder, der har fået det gamle svar, kan have krav på at blive orienteret, hvis det står i deres kontrakt. Overvej samtidig, om ændringen bør afprøves, før den når produktionen. En ny søgefunktion eller rapportgenerator, der samler data, er netop den type funktion, hvor adskillelsen kan svigte uden at nogen opdager det i den almindelige test. → Penetrationstest af en ny funktion før lancering

Det samme gælder integrationer. Når kunderne kan koble egne systemer på produktet, skal adskillelsen også holde for de data, der kommer ind og går ud den vej.

Et tænkt eksempel

En leverandør af et system til bookning af behandlinger får spørgsmålet: “Beskriv, hvordan kundens data er adskilt fra andre kunders data, og hvordan adskillelsen er verificeret.”

Svaret bliver: “Alle kunder deler én database. Hver post er knyttet til en kunde, og applikationen begrænser alle forespørgsler til den aktive kundes data i et fælles lag, som al dataadgang går igennem. Filer gemmes adskilt pr. kunde. Supportadgang til en kundes data kræver kundens godkendelse, er tidsbegrænset og logges. Adskillelsen var med i omfanget af seneste penetrationstest i april, hvor testeren havde adgang som tre kunder. Der var ingen fund vedrørende adskillelse. Testerens erklæring kan udleveres.”

Svaret er konkret, uden tekniske detaljer, der kan misbruges, og det binder påstanden til en test.

Det skal I lade være med

Skrive logisk adskilt uden forklaring · Kunden kan ikke vurdere et begreb uden indhold.
Beskrive en fælles database som adskilt · Sig, hvilken model I bruger.
Glemme filer, logs og backup · Adskillelsen skal gælde alle steder, data ligger.
Udelade supportadgangen · Det er her, kunden har flest spørgsmål.
Henvise til en test, der ikke dækkede adskillelsen · Kunden læser omfanget.
Dele arkitekturtegninger i skemaet · Vis dem på et møde, hvis det er nødvendigt.

Hvad kan og ikke kan konkluderes

Et præcist svar om adskillelse viser kunden, hvordan produktet er bygget, og om adskillelsen er efterprøvet. En test uden fund på adskillelsen viser, at testeren ikke kunne krydse grænsen i den testede version med de roller, der var med. Den kan ikke garantere, at grænsen holder i fremtidige versioner, og den dækker ikke dele af produktet, der ikke var i omfanget. → Ændringer, der kræver en ny test

Tjekliste til spørgsmålet om adskillelse

☐ Er modellen beskrevet på begrebsniveau?
☐ Er det klart, hvor adskillelsen håndhæves?
☐ Er filer, logs og backup omfattet af svaret?
☐ Er jeres egne medarbejderes adgang beskrevet?
☐ Var adskillelsen med i omfanget af seneste test?
☐ Er tekniske detaljer holdt ude af skemaet?

Kilder

OWASP API Security Top 10 2023: Broken Object Level Authorization: svagheder, hvor et API ikke kontrollerer adgangen til det enkelte objekt, med uautoriseret adgang til andre brugeres objekter som mulig følge.

Senest gennemgået: oktober 2026.