Cloududbyderens dokumentation og jeres egen test

Når en NIS2-kunde beder om dokumentation for sikkerheden i en leverance, der kører i en offentlig cloud, kan I hente en stak rapporter fra platformen. De er værdifulde, men de besvarer et andet spørgsmål end kundens. Svaret hviler på den grænse, platformene selv beskriver: platformens rapporter handler om platformens egen drift, mens jeres opsætning, konti og applikationer er jeres ansvar og kun kan belyses af jeres egen test.

De to slags dokumentation supplerer hinanden. Ingen af dem kan erstatte den anden. Teksten er ikke juridisk rådgivning.

Hvad platformene stiller til rådighed

De store cloudplatforme samler deres dokumentation ét sted. Microsoft beskriver Service Trust Portal som stedet, hvor kunder kan hente revisionsrapporter udarbejdet af eksterne revisorer, blandt andet om ISO/IEC-certificeringer og SOC-rapporter, og hvor der også findes en kategori med attestationer af penetrationstest og sikkerhedsvurderinger udført af tredjeparter. AWS beskriver AWS Artifact som en selvbetjeningsportal med revisorudstedte rapporter, certificeringer og andre tredjepartsattestationer om AWS.

Rapporterne er udarbejdet til platformens egne kunder og dækker en bestemt periode og et bestemt sæt tjenester. Tjek derfor, at de tjenester, I bruger, står i rapportens omfang, og at rapporten ikke er forældet, før I henviser til den. En rapport om platformens lagringstjenester siger fx ikke nødvendigvis noget om en nyere tjeneste, I er begyndt at bruge.

Begge steder gælder adgangsregler. Microsoft oplyser, at en del af materialet kræver login med en organisationskonto og accept af en fortrolighedsaftale, og at nogle dokumenter kun kan ses med bestemte roller. Det har betydning for, hvad I må give videre til jeres kunde.

Hvad dokumentationen dækker

Platformens rapporter beskriver platformens kontroller: datacentre, fysisk sikkerhed, platformens eget netværk, platformens ansatte og dens interne processer. En attestation af platformens penetrationstest siger, at platformen er testet af en tredjepart. Den siger intet om den virtuelle maskine, det netværk eller den Microsoft 365-lejer, I har sat op.

Det er den delte ansvarsmodel set fra dokumentationens side. Platformen dokumenterer sin del, og I skal dokumentere jeres. Hvor meget der er jeres, afhænger af tjenesten: ved virtuelle maskiner står I for næsten alt over selve hardwaren, mens platformen ved en færdig softwaretjeneste står for mere, og jeres del især handler om brugere, roller og indstillinger. → Cloudtjenester i leverancen

Det, jeres egen test skal dække

Den del af en cloudleverance, der er jeres, er den, I selv har konfigureret, og som platformens rapporter ikke ser. En forkert indstillet rolle eller en lagringskonto, der er åben for flere end tiltænkt, er jeres ansvar, også selv om platformen er sikker. En test af jeres del kan omfatte:

Identiteter og roller · hvem har administratorrettigheder i jeres miljø, og hvordan er de beskyttet?
Netværksopsætning · hvad er eksponeret mod internettet, og hvordan er miljøerne adskilt?
Lagring og data · er data kun tilgængelige for dem, der skal have adgang?
Applikationer og API’er · det, kunden faktisk bruger. → API’et, kunden kalder
Forbindelser til kunden · integrationer og fælles login.

Testen følger platformens regler. Microsoft oplyser, at kunder kan teste de Azure-ressourcer, de ejer, uden forhåndsgodkendelse, men skal følge platformens regler for test, og at tredjeparter kræver skriftlig tilladelse fra ejeren. AWS har sine egne regler for kunders test. Henvis til de gældende regler i opgavebeskrivelsen.

Hvordan kunden kan bruge platformens papirer

Gennemførelsesforordning (EU) 2024/2690 gælder bestemte digitale udbydere. Bilagets punkt 5.1.4, litra e, nævner retten til audit eller retten til at modtage auditrapporter som noget, en relevant enhed angiver i kontrakter med leverandører, hvor det er relevant. Kunder, der ikke er bundet af forordningen, kan bruge samme formulering. → Ret til revision

Når kundens krav siger “auditrapporter”, kan platformens rapporter være en del af svaret for platformens lag. Men I kan ikke nødvendigvis sende dem videre. Er de omfattet af en fortrolighedsaftale med platformen, er den rigtige løsning at fortælle kunden, hvilke rapporter der findes, og hvor kunden selv kan hente dem, hvis kunden har adgang. Er kunden ikke selv kunde hos platformen, så spørg platformen, hvad der må deles, eller giv kunden en beskrivelse af rapporternes omfang uden at vedlægge dem. → Krav til egne underleverandører

Sådan sætter I svaret sammen

Et godt svar til kunden har tre dele, som hver peger på sin kilde:

Platformens lag · hvilken platform og hvilke tjenester I bruger, og hvilke af platformens rapporter der dækker dem.
Jeres lag · hvad I har sat op, og hvordan det er testet, med et resumé af jeres seneste test. → Resumé, erklæring eller rapport
Grænsen · en kort forklaring af, hvor platformens ansvar slutter, og jeres begynder.

Skriv også, hvornår svaret sidst er opdateret. Platformens rapporter fornyes løbende, og jeres egen test har en dato. Et svar uden datoer gør det svært for kunden at vurdere, om det stadig gælder.

Svaret skal kunne læses af en person hos kunden, der ikke kender platformen. Undgå platformens interne navne, hvor almindelige ord kan bruges. → Hvem tester hvad i en lagdelt leverance

Et tænkt eksempel

En leverandør af et planlægningssystem til en transportvirksomhed kører systemet i en offentlig cloud. Kunden, som er omfattet af NIS 2-loven, beder om leverandørens seneste penetrationstest og om dokumentation for platformen. Leverandøren sender et resumé af sin egen test af systemets opsætning, roller og API og oplyser, hvilke af platformens rapporter der dækker de anvendte tjenester. Da rapporterne kræver accept af platformens fortrolighedsvilkår, henviser leverandøren kunden til platformens portal i stedet for at vedhæfte dem.

Det skal I lade være med

At sende platformens rapporter som svar på et spørgsmål om jeres opsætning · de handler om platformen.
At skrive, at platformen er NIS2-godkendt · henvis til de dokumenter, der faktisk findes.
At dele fortrolige rapporter videre uden lov · tjek platformens vilkår.
At teste uden at følge platformens regler · reglerne gælder også for jeres tester.
At gå ud fra, at alle tjenester er omfattet · rapporter og certificeringer har et bestemt omfang.

Hvad kan og ikke kan konkluderes

Platformens dokumentation kan vise, hvordan platformens egne kontroller er vurderet af uafhængige revisorer i den periode, rapporterne dækker. Den kan ikke vise, hvordan jeres opsætning, konti og applikationer er sikret. Jeres egen test kan vise det for de dele, der var med på testtidspunktet. Kunden vurderer ud fra aftalen, om de to tilsammen er tilstrækkelige.

Tjekliste til cloudplatformens dokumentation

☐ Ved I, hvilke af platformens rapporter der dækker de tjenester, I bruger?
☐ Har I tjekket, hvad der må deles med kunden?
☐ Er jeres egen opsætning med i jeres test?
☐ Følger testen platformens regler for test?
☐ Har kunden fået et svar i tre dele?
☐ Er grænsen mellem platformen og jer beskrevet i almindelige ord?

Kilder

Microsoft Learn, Service Trust Portal: revisionsrapporter, attestationer af penetrationstest og adgangsregler.
AWS Artifact: AWS’ portal for revisionsrapporter og tredjepartsattestationer.
Microsoft Learn, penetrationstest i Azure: regler for kunders test af egne ressourcer.
AWS, Penetration Testing: AWS’ regler for kunders test.
Gennemførelsesforordning (EU) 2024/2690: artikel 1 og bilagets punkt 5.1.4, litra e.

Senest gennemgået: oktober 2026.