Når systemerne flytter til en stor cloududbyder, kan det føles som at overlade sikkerheden til nogen, der ved mere om den end jer. Det er delvist rigtigt. Udbyderen har ansvaret for sin egen del, men jeres del forsvinder ikke.
De store udbydere beskriver selv ansvaret som delt. Udbyderen sikrer den platform, tjenesterne kører på. Kunden står for det, kunden selv bestemmer over: hvem der har adgang, hvordan tjenesterne er sat op, og hvilke data der lægges ind. Spørgsmålet er derfor ikke, om cloud er sikkert, men om jeres brug af det er.
Hvorfor myten lyder rigtig
Myten har en sand kerne. De store cloududbydere beskriver omfattende sikkerhedstiltag for deres datacentre, net og platforme, og de dokumenterer dele af det gennem revisioner og certificeringer. Det kan være mere, end en mindre virksomhed selv kan gøre i sit eget serverrum.
Dertil kommer, at tjenesterne virker. Mailen kører, filerne er der, og systemerne er tilgængelige. Det er let at slutte fra driftssikkerhed til informationssikkerhed, men de to er ikke det samme. En tjeneste kan køre stabilt og samtidig være sat op, så uvedkommende kan få adgang til data.
Udbyderens løfte gælder udbyderens del
Når en udbyder skriver om sikkerhed, handler det om det, udbyderen selv kontrollerer: de fysiske datacentre, den underliggende hardware, de net, der forbinder dem, og den software, der driver selve platformen.
Hvor grænsen går, afhænger af tjenesten. Ved en ren servertjeneste står kunden for meget, fra styresystemet og op. Ved en færdig tjeneste som en mail- og kontorpakke står udbyderen for mere, men kunden har stadig ansvaret for brugere, adgange og en lang række indstillinger. Microsoft og AWS beskriver hver især modellen i deres egen dokumentation. → Delt ansvar i cloud: hvad I selv skal teste
Det, der er jeres, uanset tjenesten
Uanset hvilken type tjeneste I bruger, er der forhold, udbyderen ikke kan tage ansvaret for, fordi det er jer, der bestemmer over dem:
- Brugere og adgange · hvem der har konti, hvilke rettigheder de har, og om tidligere ansatte og leverandører er fjernet.
- Login · om der kræves mere end en adgangskode, og hvordan fælles login til flere systemer er sat op. → Fælles login (single sign-on) i testen
- Deling og synlighed · om filer, mapper eller lagringsområder er delt bredere end tænkt.
- Integrationer · hvilke andre systemer og leverandører der har adgang til jeres cloudtjenester.
- Data · hvad der lægges i skyen, og hvem der kan se det.
Det er netop her, fejl kan opstå. En indstilling, der deler en mappe med alle, eller en konto med for mange rettigheder, er ikke en fejl hos udbyderen. Det er en del af jeres opsætning.
Opsætningen ændrer sig også over tid. Nye medarbejdere får adgang, projekter opretter delte mapper, og nye tjenester bliver slået til, fordi nogen havde brug for dem. Hver ændring kan være fornuftig for sig, men tilsammen kan de give et billede, ingen har overblik over. Udbyderen holder ikke øje med, om jeres egne valg stadig passer til jeres behov.
Når en partner har sat det op
Cloudtjenester kan være sat op af en partner eller af driftsleverandøren. Det flytter arbejdet, men ikke nødvendigvis ansvaret. Over for udbyderen er det stadig jer, der er kunden, og over for jeres kunder er det jer, der passer på deres data.
Afklar derfor, hvad partneren har påtaget sig. Står partneren for den løbende vedligeholdelse af brugere og indstillinger, eller blev tjenesten blot sat op og overdraget? Hvem gennemgår opsætningen, når der kommer nye funktioner fra udbyderen? Svarene skal stå i aftalen, så der ikke opstår et hul mellem det, udbyderen sikrer, og det, partneren tror, I selv holder øje med.
Certifikater hos udbyderen dækker ikke jeres opsætning
Udbydernes certificeringer og revisionserklæringer handler om udbyderens kontroller. De kan være vigtige, når I vælger leverandør, og de kan indgå i jeres egen dokumentation over for kunder og revisorer.
Men de siger ikke noget om, hvordan I har sat jeres tjenester op. En virksomhed kan bruge en certificeret platform og alligevel have en opsætning med alvorlige svagheder. Hvis I selv arbejder med ISO/IEC 27001, skal jeres egne kontroller dække jeres del af cloudtjenesterne. → ISO 27001 og penetrationstest
Samme skelnen gælder ved hosting, hvor platformens sikkerhed heller ikke er det samme som løsningens. → Hostingfirmaet tester for os
Hvad det betyder for en test
En penetrationstest af jeres cloudtjenester skal rettes mod jeres del af ansvaret: adgange, opsætning, deling og integrationer. Den skal ikke forsøge at teste udbyderens platform, og udbyderne har regler for, hvad kunder må og ikke må under en test. Reglerne skal læses, inden testen planlægges, fordi de kan ændre sig.
Formulér også, hvad testen skal svare på. Skal den vise, om en medarbejder med en almindelig konto kan nå mere, end rollen tilsiger? Om delte data kan ses udefra? Om en integration giver en leverandør bredere adgang end aftalt? Et klart spørgsmål gør det lettere at afgrænse opgaven og at bruge resultatet. → Er en penetrationstest lovlig?
Hvis I står foran en flytning, eller den lige er sket, er det et naturligt tidspunkt at se på opsætningen. → Flytning til cloud: hvad skal testes før og efter?
Bruger I en kontorpakke i skyen, er mange af de vigtigste spørgsmål knyttet til den. → Microsoft 365 og testen
Det skal I lade være med
- At sidestille udbyderens sikkerhed med jeres · udbyderen sikrer platformen, ikke jeres opsætning.
- At slutte fra stabil drift til sikkerhed · en tjeneste kan køre fint og stadig være sat forkert op.
- At bruge udbyderens certifikater som jeres dokumentation · de dækker udbyderens kontroller, ikke jeres.
- At glemme integrationer og leverandører · adgange til jeres cloudtjenester skal også styres.
- At teste uden at læse udbyderens regler · en test skal holde sig til jeres del af ansvaret.
Hvad kan og ikke kan konkluderes
At en cloududbyder har stærk sikkerhed på sin platform, er en del af billedet. Det kan ikke bruges som konklusion om jeres egne adgange, opsætning eller data. Den del skal vurderes særskilt.
En test af jeres cloudtjenester kan vise, om den opsætning, der indgik, har svagheder, som kan udnyttes. Den kan ikke vise noget om udbyderens platform, og den beskriver kun opsætningen, som den var i testperioden.
Tjekliste til jeres cloudtjenester
- ☐ Ved vi, hvilke cloudtjenester vi bruger, og hvilken type de er?
- ☐ Har vi læst, hvor udbyderen trækker grænsen for ansvaret?
- ☐ Er brugere og rettigheder gennemgået for nylig?
- ☐ Kræver login mere end en adgangskode?
- ☐ Ved vi, hvad der er delt, og med hvem?
- ☐ Har vi overblik over integrationer og leverandøradgange?
- ☐ Er udbyderens regler for test læst før en bestilling?
Kilder
- Microsoft Learn: delt ansvar i cloud: fordelingen af ansvar mellem udbyder og kunde efter tjenestetype.
- AWS: Shared Responsibility Model: udbyderens og kundens del af sikkerheden.
- Microsoft Learn: penetrationstest og AWS: penetrationstest: udbydernes regler for kunders test.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Microsoft 365 og testen · Hostingfirmaet tester for os
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
