Cloudtjenester i leverancen: jeres del og platformens del over for kunden

En NIS2-kunde, der spørger til test af jeres leverance, spørger ikke nødvendigvis til cloudplatformen bag. Alligevel kan det være det første, der skal forklares, for testen kan ikke dække platformen selv. Svaret hviler på cloududbydernes egne beskrivelser af delt ansvar: I ejer jeres data, identiteter, konti og opsætning og skal selv sørge for at få dem testet, mens udbyderen ejer det fysiske og den underliggende infrastruktur og dokumenterer den på anden måde.

Over for kunden er opgaven at gøre den deling synlig, så kunden kan se, at begge dele er dækket. Teksten er ikke juridisk rådgivning, og udbydernes regler kan ændre sig, så de bør læses i den aktuelle udgave.

Delt ansvar forklaret kort

Microsoft beskriver på Microsoft Learn, hvordan ansvaret for sikkerhed fordeles mellem udbyder og kunde, og hvordan fordelingen ændrer sig med tjenestetypen. Ved infrastruktur som tjeneste har kunden ansvaret for styresystem og applikationer. Ved platform som tjeneste overtager udbyderen styresystemet. Ved software som tjeneste overtager udbyderen det meste af stakken. Uanset tjenestetype beholder kunden ifølge samme side ansvaret for data, slutpunkter, konti og adgangsstyring.

Ordet kunde betyder i den sammenhæng jer, fordi det er jer, der køber cloudtjenesten. For jeres NIS2-kunde er I altså den, der står med den del af ansvaret, platformen ikke tager. → Hvem tester hvad i en lagdelt leverance

Hvad der hører til jeres del

Jeres del af testen kan være:

Opsætningen i cloudmiljøet · hvem der kan se og ændre ressourcer, og hvad der er tilgængeligt udefra.
Identiteter og roller · konti, administratorroller og jeres egne medarbejderes adgang. → Adgangskontrol og privilegerede konti
Applikationen · den løsning, kunden bruger, med jeres kode og jeres integrationer.
Data · hvem der kan nå kundens data, og om kundernes data holdes adskilt.
Forbindelser · til kunden, til andre tjenester og til jeres egne systemer.

Det er de punkter, en test af leverancen skal dække, og som kunden kan forvente dokumenteret.

En leverance kan desuden bruge færdige softwaretjenester ved siden af platformen, fx til mail, login eller overvågning. Opsætningen af dem er også jeres, selv om tjenesten er en andens. Skriv dem på listen over systemer, så kunden kan se, om de er med i testen eller dækket på anden måde. En glemt tjeneste med adgang til kundens data er netop den slags hul, kundens leverandørvurdering skal fange.

Platformens regler for test

Cloududbyderne har deres egne regler for, hvad deres kunder må teste. Microsoft oplyser på Microsoft Learn, at forudgående godkendelse ikke kræves for test af egne Azure-ressourcer, men at Microsofts regler for test (rules of engagement) skal følges. En ekstern tester, som I hyrer, skal ifølge siden have jeres udtrykkelige og skriftlige accept som ejer af ressourcerne, og Microsoft giver ikke den accept på jeres vegne. Test af andres miljøer og test, der skal lamme tjenesten, er ikke tilladt.

AWS oplyser på sin side om penetrationstest, at kunder kan teste deres egen infrastruktur uden forudgående godkendelse for en række navngivne tjenester, at andre tjenester kræver kontakt til AWS, og at test af AWS’ egen infrastruktur ikke er tilladt. Begge udbydere forbyder test, der skal overbelaste tjenesten.

Andre udbydere har andre regler. Find den gældende side hos jeres udbyder, og henvis til den i opgavebeskrivelsen, så testeren og kunden kan se, at testen følger platformens rammer. → Cloududbyderens dokumentation

Platformens del: dokumentation frem for test

Det, udbyderen ejer, kan I hverken teste eller give tilladelse til at teste. Kundens spørgsmål om den del besvares med udbyderens egen dokumentation, fx erklæringer, certificeringer og beskrivelser af sikkerhed, som udbyderen stiller til rådighed for sine kunder. Det er jeres opgave at finde de relevante dokumenter og forklare kunden, hvilken del af leverancen de dækker.

En række cloud- og datacenterudbydere er selv omfattet af NIS2 og af gennemførelsesforordning (EU) 2024/2690, der i artikel 1 nævner blandt andet udbydere af cloudcomputingtjenester og datacentertjenester. Om en bestemt udbyder er omfattet i et bestemt land, er udbyderens forhold. Skriv derfor ikke til kunden, at platformen “er NIS2-godkendt”. Henvis til de dokumenter, udbyderen faktisk stiller til rådighed. → Forordning 2024/2690

Sådan forklarer I ansvarsdelingen til kunden

Et kort afsnit i dokumentationen til kunden kan rumme fire punkter:

Tjenestetypen · hvilke cloudtjenester leverancen bygger på, og om de er infrastruktur, platform eller software som tjeneste.
Jeres ansvar · de dele, I selv ejer, og som testen dækker.
Udbyderens ansvar · de dele, udbyderen ejer, og hvilken dokumentation der dækker dem.
Grænsefladen · opsætningen af udbyderens tjenester, som er jeres ansvar, selv om tjenesten er udbyderens.

Det fjerde punkt er det vigtigste. En lagertjeneste kan være sikker fra udbyderens side og alligevel stå åben, fordi den er sat forkert op. Det er en fejl i jeres del, og testen skal kunne finde den.

Et tænkt eksempel

En leverandør af et system til journalføring af laboratorieprøver til en fødevareproducent kører sin løsning på en platformtjeneste i en stor cloud. Fødevareproducenten kræver en penetrationstest og spørger, om “cloudens sikkerhed” er med.

Leverandøren svarer, at testen dækker applikationen, opsætningen af platformtjenesten, administratorroller og adskillelsen mellem kunders data. Platformens fysiske og underliggende sikkerhed er dækket af udbyderens egne erklæringer, som leverandøren henviser til. Testen gennemføres efter udbyderens regler, og opgavebeskrivelsen henviser til dem. Fødevareproducenten får rapporten, leverandørens afsnit om ansvarsdeling og en liste over udbyderens dokumenter, og kan dermed se, hvor hver del af leverancen er dækket.

Det skal I lade være med

At sige, at cloududbyderen tager sig af sikkerheden · opsætning, konti og data er jeres.
At bede testeren teste platformen selv · det er i strid med udbydernes regler.
At teste uden at kende udbyderens regler · testen kan blive stoppet eller bryde aftalen.
At sende udbyderens erklæring som svar på hele testkravet · den dækker ikke jeres del.
At kalde platformen godkendt efter NIS2 · der findes ingen sådan generel godkendelse.

Hvad kan og ikke kan konkluderes

En test af jeres del af en cloudleverance kan dokumentere, hvordan opsætning, roller, applikation og dataadskillelse modstod testen. Den kan ikke dokumentere platformens egen sikkerhed. Den gælder også kun for den opsætning, der var på testtidspunktet, og cloudmiljøer kan ændres hurtigt. Udbyderens dokumentation kan beskrive den del, men det er kunden, der vurderer, om de to tilsammen er tilstrækkelige.

Tjekliste til cloud i leverancen

☐ Ved I, hvilke tjenestetyper leverancen bygger på?
☐ Har I beskrevet, hvilke dele der er jeres, og hvilke der er udbyderens?
☐ Har I læst udbyderens gældende regler for test?
☐ Henviser opgavebeskrivelsen til de regler?
☐ Har I fundet udbyderens dokumentation for platformens del?
☐ Dækker testen opsætningen af udbyderens tjenester?

Kilder

Microsoft Learn, Shared responsibility in the cloud: fordelingen af ansvar efter tjenestetype og de dele, kunden altid beholder.
Microsoft Learn (Azure), Penetration testing: ingen forudgående godkendelse, krav om at følge reglerne for test, skriftlig tilladelse for tredjeparter, forbudt test.
AWS, Penetration Testing: tjenester, der kan testes uden forudgående godkendelse, og forbudte aktiviteter.
Gennemførelsesforordning (EU) 2024/2690: artikel 1 om de omfattede digitale udbydere.

Senest gennemgået: oktober 2026.