Delt ansvar i cloud: hvad skal I selv teste?

Penetrationtest: opslagsværk om penetrationstest på dansk

I cloud deles ansvaret for sikkerheden mellem udbyderen og kunden, og grænsen flytter sig med typen af tjeneste. Det, I selv skal lade teste, er den del, der ligger på jeres side af grænsen: jeres data, jeres konti og adgangsstyring og de indstillinger, I har valgt. Udbyderens del kan I ikke teste, men I kan bede om dokumentation for den.

Køberens opgave er at oversætte ansvarsdelingen til et scope. Det sker ved at gå tjeneste for tjeneste og skrive ned, hvem der står for hvad, og hvem der har konfigureret det.

Grænsen flytter sig med tjenesten

Microsoft og andre udbydere beskriver tre grundtyper af cloudtjenester, og ansvaret fordeles forskelligt i hver af dem:

Infrastruktur som tjeneste · virksomheden lejer servere og net og står selv for styresystemer, programmer og netværksregler.
Platform som tjeneste · udbyderen driver styresystemet, og virksomheden står for sine programmer, deres opsætning og adgangen til dem.
Software som tjeneste · udbyderen driver hele programmet, og virksomheden står for sine data, brugere og indstillinger.

Jo længere ned på listen, jo mindre har virksomheden selv at teste. Men intet sted forsvinder ansvaret helt. Microsofts beskrivelse af modellen fremhæver, at kunden ved alle tjenestetyper beholder ansvaret for data, konti, adgangsstyring og de enheder, der bruges til at nå tjenesterne.

Mange virksomheder bruger alle tre typer på én gang uden at tænke over det. Webshoppen kører måske på en platformstjeneste, ERP-systemet på lejede servere og mail og dokumenter i en softwaretjeneste. Hver af dem har sin egen grænse, og hver af dem kræver sin egen linje i scope.

Det, der altid er jeres

Uanset tjenestetype er der fire områder, som hører med i jeres overvejelse om test:

Konti og identiteter · hvem der har adgang, og hvem der kan administrere.
Adgangsstyring · tofaktorlogin, roller og betingelser for adgang.
Data · hvor de ligger, og hvem der kan se dem.
Indstillinger · alt det, I eller jeres partner har valgt i opsætningen.

Det er ofte her, fejlene opstår. Et lagringsområde, der ved en fejl er åbent for alle, eller en administratorkonto uden tofaktorlogin er ikke udbyderens ansvar, selv om det ligger på udbyderens platform. Forestillingen om, at udbyderen tager sig af det hele, er behandlet for sig. → Cloududbyderen har styr på sikkerheden

Fra ansvarsfordeling til scope

Lav en oversigt over de cloudtjenester, virksomheden bruger. For hver tjeneste skrives tjenestetypen, hvad virksomheden selv har konfigureret, og hvem der har gjort det. Oversigten bliver grundlaget for scope og for samtalen med testeren.

Tag kundeportalen som tænkt eksempel. Den kører på en platformstjeneste, bruger en database fra samme udbyder og logger brugere ind via en identitetstjeneste. Udbyderen står for servere og styresystem. Virksomheden står for portalens kode, databasens adgangsregler, de roller, der kan administrere det hele, og forbindelsen til ERP-systemet. Det er de dele, testen skal rettes mod.

Oversigten kan også afsløre tjenester, som ingen havde tænkt på som cloud: et lagringsområde til billeder fra webshoppen, en testudgave af portalen, som en udvikler har oprettet, eller en gammel konto hos en udbyder, som ingen bruger længere. De hører med i oversigten, også selv om de ikke kommer med i testen. Det, der ikke står på listen, kan ingen tage stilling til. → Glemte testmiljøer på internettet

Ved softwaretjenester, fx et personalesystem eller et regnskabsprogram, er der sjældent noget at teste i selve programmet ud over den måde, virksomheden har sat det op på. Her handler spørgsmålene om konti, roller, gæsteadgang og deling. Microsoft 365 er et eksempel på en softwaretjeneste med mange indstillinger, som virksomheden selv vælger. → Microsoft 365 og testen

Udbyderens regler sætter rammen

Selv den del, der er jeres, må kun testes inden for udbyderens regler. Microsoft kræver ikke forhåndsgodkendelse til test af egne ressourcer i Azure, men henviser til fælles regler, der blandt andet forbyder test, som kan lamme tjenesten. AWS tillader test af en række navngivne tjenester uden forudgående godkendelse, mens andre aktiviteter skal anmeldes og vurderes først. Reglerne ændres, og den gældende udgave skal læses, før testen planlægges. Bed testeren angive, hvilke regler opgaven er planlagt efter, og om nogle aktiviteter kræver anmeldelse. Det gør det lettere at svare, hvis udbyderen henvender sig undervejs.

Har en partner sat cloudmiljøet op eller driver det, kan partnerens aftale indeholde egne krav om varsel eller godkendelse. Det er ejeren af ressourcerne, der giver lov, og lovet skal gælde netop denne opgave. → Er en penetrationstest lovlig?

Udbyderens del: dokumentation frem for test

Den del, udbyderen står for, kan virksomheden ikke selv teste. Det er heller ikke nødvendigt for at få et svar. Spørg udbyderen, hvilken dokumentation der findes for deres del, fx certificeringer eller erklæringer fra uafhængige revisorer. Hvad dokumentationen dækker, varierer, og den skal læses med samme opmærksomhed på afgrænsning som en pentestrapport.

Ved mindre softwareleverandører er spørgsmålet ofte mere direkte. Er løsningen selv blevet testet, hvornår, og hvad omfattede testen? Et svar om, at alt er sikkert, er ikke dokumentation. → Leverandøren siger, at alt er sikkert

Skriv svarene ind i oversigten ved siden af jeres egen del. Så kan ledelsen se, hvilke dele der er dækket af jeres test, hvilke af udbyderens dokumentation, og hvor der stadig mangler et svar.

Det skal I lade være med

At gå ud fra, at udbyderen har testet jeres opsætning · udbyderen tester sin platform, ikke jeres valg.
At teste udbyderens del · det er sjældent tilladt og giver ikke svar på jeres spørgsmål.
At glemme konti og roller i softwaretjenester · de er jeres ansvar, også når alt andet er udbyderens.
At bruge én afgrænsning til alle tjenester · hver tjenestetype kræver sin egen beskrivelse.
At springe reglerne over · udbyderens gældende regler for test skal læses før start.

Hvad kan og ikke kan konkluderes

En test kan vise, hvordan jeres del af de undersøgte tjenester holdt på testtidspunktet. Udbyderens sikkerhed ligger uden for, hvad den kan dokumentere, og tjenester uden for oversigten er ikke dækket. Rapporten bør derfor nævne de konti, abonnementer og tjenester, der indgik. Udbyderens dokumentation og jeres testrapport supplerer hinanden, men ingen af dem dækker det hele alene.

Indstillinger i cloud kan ændres hurtigt og af mange. Resultatet bør derfor kobles til, hvordan ændringer styres bagefter. Står virksomheden midt i en flytning, er der særlige spørgsmål om timing. → Flytning til cloud

Tjekliste til ansvarsdelingen

☐ Er alle cloudtjenester listet med tjenestetype?
☐ Er det skrevet ned, hvad I selv har konfigureret i hver?
☐ Er konti, roller, data og indstillinger med i scope?
☐ Er udbyderens gældende regler for test læst?
☐ Har den, der råder over ressourcerne, givet tilladelse?
☐ Er der bedt om dokumentation for udbyderens del?

Kilder

Microsoft Learn: Shared responsibility in the cloud: fordelingen af ansvar for IaaS, PaaS og SaaS og de ansvarsområder, kunden altid beholder.
Microsoft Learn: Penetration testing: ingen forhåndsgodkendelse til test af egne Azure-ressourcer og henvisning til fælles regler.
AWS: Penetration Testing: test af navngivne tjenester uden forudgående godkendelse og krav om anmeldelse af andre aktiviteter.

Senest gennemgået: oktober 2026.