Kundernes eget ansvar: det, I ikke kan teste for dem

Jeres penetrationstest kan vise, hvordan produktet holder, men den kan ikke vise, om kunden har givet de rigtige personer adgang, slået totrinslogin til eller fjernet konti efter en fratrædelse. Det er kundens del, og den ligger uden for det, I kan teste og dokumentere. Svaret på, hvor grænsen går, hviler på en enkel fordeling: I står for det, I har bygget og driver; kunden står for sine egne brugere, sin egen opsætning og de data, kunden selv lægger ind. Det svære er at sige det, så kunden forstår det før en hændelse og ikke efter.

Hvor jeres test stopper

Testeren arbejder med testkonti og testkunder, som I har oprettet. Rapporten kan derfor sige noget om, hvad produktet tillader, og om adskillelsen mellem kunder holder. Den kan ikke sige noget om, hvordan en bestemt kunde har sat sit eget miljø op.

Et eksempel gør forskellen tydelig. Testen kan vise, at en bruger med rollen læser ikke kan ændre data. Den kan ikke vise, at kunden har givet rollen administrator til de rigtige personer. Det første er produktets kontrol. Det andet er kundens beslutning. Rapporten kan heller ikke sige noget om kundens medarbejdere: om de genbruger adgangskoder, deler konti eller bruger produktet fra en privat computer uden opdateringer. Den slags kan have stor betydning for kundens risiko, men det ligger uden for jeres produkt og uden for jeres test. → Roller og rettigheder i produktet

Det, der ligger hos kunden

Gør det konkret for kunden, hvad der er deres del. Listen afhænger af produktet, men kan rumme:

Brugere og konti · hvem der oprettes, og hvornår de fjernes igen.
Roller og rettigheder · hvem der får administratoradgang, og hvem der kun skal læse.
Login · om totrinslogin er slået til, og hvordan kundens eget login er sat op, hvis I understøtter single sign-on.
Indstillinger · de valg, kunden selv træffer i produktets opsætning, fx deling og eksport.
Integrationer · de nøgler, kunden har fået til API’et, og de systemer, kunden selv forbinder.
Egne enheder · de computere og telefoner, kundens medarbejdere bruger produktet fra.
Data · hvad kunden vælger at lægge ind, og hvem hos kunden der må se det.

Single sign-on og integrationer er beskrevet for sig, fordi grænsen dér går gennem en fælles forbindelse. → Kundernes SSO · → Integrationer og ansvar

Sådan kan cloududbydernes modeller bruges

Ansvarsdelingen er ikke en ny tanke. Microsoft beskriver i sin model for delt ansvar, at kunden ved alle typer cloudtjenester, også SaaS, beholder ansvaret for data, enheder, konti og adgangsstyring. Modellen gælder Microsofts egne tjenester og er ikke en regel for jeres produkt, men den giver kundens sikkerhedsfolk en ramme, de kender.

Den britiske NCSC skriver i sine principper for cloudsikkerhed, at konfigurationen af de cloudtjenester, kunden bruger, forbliver kundens ansvar, også når leverandøren har gjort sikre indstillinger til standard. Samme princip lægger vægt på, at leverandøren gør sikkerhedsfunktioner til standard og ikke til noget, kunden skal slå til. Begge dele kan bruges, når I forklarer jeres egen fordeling. Henvis gerne til dem i et spørgeskema, men skriv jeres egen fordeling med jeres egne funktioner, så kunden ikke skal oversætte en generel model til jeres produkt. → Produktet hostes hos en cloududbyder

Gør kundens del lettere

At noget er kundens ansvar, betyder ikke, at I kan læne jer tilbage. Det, I bygger, afgør, hvor let det er for kunden at gøre det rigtige. Et produkt, der kræver mange manuelle valg for at blive sikkert, flytter i praksis en del af risikoen over på kunden. Det er jeres del:

Sikre standarder · nye kunder starter med indstillinger, der beskytter, og skal aktivt vælge dem fra.
Synlighed · kundens administrator kan se, hvem der har adgang, og hvad de har gjort.
Advarsler · produktet gør opmærksom på valg, der svækker sikkerheden.
Vejledning · en kort beskrivelse af de indstillinger, kunden bør tage stilling til.

Funktionerne kan selv være en del af testen. Kan en bruger omgå et krav om totrinslogin, er det et fund i produktet, ikke et valg hos kunden. → Scope for et SaaS-produkt

Skriv grænsen ned

Fordelingen skal stå tre steder. I omfangsafsnittet eller resuméet, så kunden kan se, at testen dækkede produktets kontroller og ikke kundens opsætning. I kontrakten eller sikkerhedsbilaget, så parterne kan pege på den senere. Og i vejledningen til kundens administrator, så den, der skal handle, også får det at vide. → Sikkerhedsbilaget

Hold formuleringen kort og saglig. Et par sætninger om, hvad I tester og vedligeholder, og en liste over det, kunden selv skal tage stilling til, er nok. En lang juridisk tekst bliver ikke læst af den administrator, der skal bruge den.

Et tænkt eksempel: Et softwarehus med et system til kvalitetsstyring i byggeriet skriver i kundeversionen af rapporten, at testen dækkede produktets roller, login og adskillelse mellem kunder med testkonti oprettet af softwarehuset. Under det står tre linjer om, at kundens tildeling af roller, brug af totrinslogin og fjernelse af tidligere medarbejdere er kundens egen opgave, med en henvisning til administratorvejledningen. Når en kunde senere spørger, om en tidligere projektleder stadig kunne logge ind, er svaret allerede skrevet.

Når kunden vil have jer til at teste deres del

En kunde kan bede om en test af netop sin opsætning. Det er en anden opgave end jeres produkttest, og den bør aftales som sådan: hvem bestiller, hvem betaler, og hvem får rapporten. Det kan være kunden selv, der bør bestille, fordi resultatet handler om kundens beslutninger. Testen skal i så fald følge jeres regler for kunders test, så den ikke rammer andre kunder i det samme miljø. → Kunden vil have testet sin opsætning

Det skal I lade være med

Lade rapporten antyde, at kundens opsætning er testet · skriv, hvad testkontiene var.
Skyde alt over på kunden · usikre standarder og manglende kontroller er jeres.
Gemme fordelingen i kontrakten alene · administratoren skal også kende den.
Love at overvåge kundens brugere · medmindre det er en del af aftalen.
Vente med at forklare grænsen til en hændelse · så bliver det en diskussion om skyld.

Hvad kan og ikke kan konkluderes

En klar fordeling viser kunden, hvad jeres test dækker, og hvad kunden selv skal sørge for. Den flytter ikke ansvaret for produktets egne fejl, og den gør ikke kundens opsætning sikker. Hvad der juridisk gælder mellem parterne, afgøres af aftalen. Teksten er ikke juridisk rådgivning.

Tjekliste til ansvarsfordelingen

☐ Er kundens del beskrevet i en kort liste?
☐ Står det i rapportens resumé, at kundens opsætning ikke var omfattet?
☐ Er fordelingen med i kontrakten eller sikkerhedsbilaget?
☐ Har kundens administrator fået en vejledning?
☐ Starter nye kunder med sikre standarder?
☐ Er sikkerhedsfunktionerne selv med i testen?

Kilder

Microsoft Learn: Shared responsibility in the cloud: kunden beholder ansvaret for data, enheder, konti og adgangsstyring ved alle typer cloudtjenester.
NCSC: Cloud security principle 14, secure use of the service: konfigurationen er kundens ansvar; leverandøren bør gøre sikkerhedsfunktioner til standard.

Senest gennemgået: oktober 2026.