Kundens test i et delt miljø: hensynet til de andre kunder

En kunde, der tester sin egen del af et SaaS-produkt, tester i praksis også det, alle de andre kunder deler: servere, databaser, login, køer og de mennesker, der overvåger driften. Derfor kræver en kundes test i et delt miljø aftaler, som en test af et system, kunden ejer alene, ikke gør. Aftalerne hviler på ét princip: testen må gerne afprøve kundens egen adgang og adskillelsen til de andre, men den må ikke gå ud over de andres drift eller data.

Det princip er ikke jeres opfindelse. De store cloudplatforme bruger det samme over for deres egne kunder, og det er let at forklare en kunde, der selv kender det fra sin platform.

Hvad de andre kunder deler med den, der tester

I et produkt med flere kunder i samme løsning er der sjældent noget, der kun tilhører én kunde, ud over dataene og opsætningen. Resten er fælles. Det betyder, at en test, der er rettet mod kundens egen lejer, kan mærkes andre steder:

Ydelse og tilgængelighed · tung automatiseret test kan gøre produktet langsomt for alle.
Fælles funktioner · beskeder, mails og notifikationer kan ramme andre end testkunden.
Overvågning og alarmer · jeres driftsfolk ser noget, der ligner et angreb, og skal kunne skelne.
Support · fejl, testen udløser, kan lande hos jeres support som rigtige fejlmeldinger.
Data · lykkes en test i at bryde adskillelsen, er det en anden kundes data, der kommer frem.

Det sidste punkt er det vigtigste. Netop adskillelsen kan være det, kunden vil teste, og en vellykket test betyder, at testeren har set noget, der ikke var deres. → Multi-tenant

Hvad cloudplatformene selv gør

Microsoft har offentlige regler for kunders test af sine cloudtjenester. Test skal ske i kundens egen lejer eller egne ressourcer. Det er forbudt at tilgå andre kunders data, at teste lejere, man ikke ejer, og at teste tilgængelighed ved at overbelaste tjenesten. Får testeren ved et uheld adgang til data, der ikke er deres, skal de stoppe, give besked, slette dataene og ikke dele dem.

AWS har en tilsvarende politik. Kunder må teste egne ressourcer i en række tjenester uden forudgående godkendelse, mens test, der skal gøre tjenesten utilgængelig, er forbudt, og test af AWS’ egen infrastruktur ikke er tilladt.

For et softwarehus giver det et godt udgangspunkt. Jeres kunder kender den slags regler, og I kan bygge jeres egne betingelser op efter samme mønster. → En testpolitik for kunder

Et særskilt miljø er ofte det bedste svar

Den enkleste måde at beskytte de andre kunder på er at flytte testen væk fra dem. Kan I stille et miljø til rådighed, der kører samme version og opsætning som produktionen, men uden andre kunders data og drift, forsvinder de fleste risici. Kunden kan få to eller flere testlejere, så adskillelsen kan afprøves uden at ramme nogen. → Testlejere

Det kræver, at miljøet faktisk ligner produktionen, ellers siger testen mindre, end kunden tror. Forklar kunden, hvad der er ens, og hvad der er forskelligt. Er der forskelle, der betyder noget for kundens formål, så sig det før testen og ikke efter.

Når testen skal ske i produktionen

Nogle kunder vil teste i den rigtige produktion, fordi de vil se det, deres brugere ser. Det kan være rimeligt, men så skal aftalen dække mere:

Tidsrum · hvornår testen sker, og hvornår den slutter.
Besked på forhånd · så jeres drift og support ved, hvad de ser.
Kontaktpunkt begge veje · hvem der kan stoppe testen, og hvem testeren ringer til.
Ingen tung automatisering · test, der belaster den fælles drift, er ikke tilladt.
Kun egne konti og data · testeren bruger de konti og data, kunden har fået til formålet.
Uheld med andres data · stop, giv besked, slet og del ikke, som hos de store platforme.

Hvem der bærer ansvaret, hvis noget alligevel går galt, hører hjemme i kontrakten. → Ansvar, hvis kundens test skader driften

Når testen viser, at adskillelsen ikke holder

Det værste udfald af en kundes test i et delt miljø er ikke, at produktet bliver langsomt. Det er, at testeren kommer til at se en anden kundes data. Så er der flere spørgsmål på én gang: skal den berørte kunde have besked, hvad er der set, og hvordan rettes fejlen for alle?

Aftal på forhånd, at fundet straks kommer til jer og ikke først står i kundens rapport. Sørg for, at I har en plan for, hvad I gør over for den kunde, hvis data blev set. → Kundens tester finder et fund

Et sådant fund er også en grund til at se på, om jeres egne svar om adskillelse i skemaer og bilag stadig holder. → Spørgsmål om adskillelse af kundernes data

Et tænkt eksempel

Et softwarehus med et HR-system får en anmodning fra en stor kunde, hvis tester vil teste i produktionen en weekend. Softwarehuset tilbyder i stedet et særskilt miljø med samme version, men kunden insisterer, fordi deres revisor vil se den rigtige drift.

Parterne aftaler et tidsrum en lørdag formiddag, at testeren kun bruger kundens egne testkonti, og at automatiseret test kun sker i det særskilte miljø. Driften får besked, og en udvikler er på vagt med et telefonnummer, testeren kender. Kort inde i testen ser testeren et navn fra en anden kunde i en søgning. Testeren stopper, ringer og beskriver fundet uden at gemme eller dele oplysningerne. Fejlen rettes samme dag, og softwarehuset vurderer selv, hvad den anden kunde skal have at vide.

Det skal I lade være med

Lade kunden teste i den fælles produktion uden aftale · de andre kunder har ikke sagt ja.
Give et særskilt miljø, der ikke ligner produktionen · så tester kunden noget andet end det, de bruger.
Glemme at give driften besked · et varslet angreb ligner et rigtigt.
Tillade belastningstest i fælles drift · den rammer alle.
Vente på kundens rapport for at høre om alvorlige fund · I skal vide det med det samme.
Overse, at kundens fund kan berøre andre kunder · en fejl i adskillelsen er alles problem.

Hvad kan og ikke kan konkluderes

En kundes test i et delt miljø kan vise, om kundens egen adgang og adskillelsen til andre holder, set fra den kundes side. Den kan ikke dokumentere hele produktet, og en test i et særskilt miljø siger kun noget om produktionen i det omfang, de to er ens.

Tjekliste før en kundes test i et delt miljø

☐ Kan kunden få et særskilt miljø med egne testlejere?
☐ Er tidsrum, kontaktpunkt og stopprocedure aftalt?
☐ Ved drift og support, at testen finder sted?
☐ Er belastende test udelukket i den fælles drift?
☐ Er det aftalt, hvad testeren gør, hvis andres data bliver synlige?
☐ Kommer alvorlige fund til jer med det samme?

Kilder

Microsoft: Penetration Testing Rules of Engagement: test kun i egen lejer, forbud mod at tilgå andre kunders data og mod test af tilgængelighed, og pligt til at stoppe, give besked og slette data ved utilsigtet adgang.
AWS: Penetration Testing: kunders test af egne ressourcer, forbud mod test af tilgængelighed og mod test af AWS’ infrastruktur.

Senest gennemgået: oktober 2026.