En flytning til cloud ændrer, hvor grænsen for jeres systemer går, og hvem der har ansvaret for de enkelte dele. Hvad der skal testes, afhænger derfor af to forhold: hvilke dele af opsætningen virksomheden selv råder over efter flytningen, og hvilke nye adgangsveje flytningen skaber.
Testen efter flytningen skal rette sig mod det, virksomheden selv konfigurerer: identiteter og roller, det, der er åbent mod internettet, adskillelsen mellem miljøer og forbindelsen tilbage til kontornettet. En test før flytningen er mest nyttig, når den bruges til at stille krav til den nye opsætning, før den tages i brug.
Systemet er det samme, vejene ind er nye
På egne servere lå en stor del af beskyttelsen i det fysiske netværk: hvad der stod bag firewallen, og hvem der kunne komme ind i bygningen. I cloud ligger mere af beskyttelsen i indstillinger, roller og rettigheder, som kan ændres af enhver med de rette adgange.
I et tænkt eksempel flytter ERP-systemet og en filserver fra et serverrum til en cloudplatform, mens kontornettet bliver, hvor det er. Før lå ERP-systemet kun på det interne net. Efter flytningen kan det være tilgængeligt via en ny forbindelse, et administrationspanel på internettet og en integration til webshoppen. Systemet er uændret, men der er kommet nye veje ind.
Det er de veje, en test omkring flytningen skal handle om. Ikke selve cloudplatformen, men de grænser, virksomheden har tegnet på den.
Flytningen ændrer også, hvem der er nabo. Hvor serverrummet kun rummede virksomhedens egne systemer, deler en cloudplatform den underliggende infrastruktur med andre kunder. Det er udbyderens opgave at holde kunderne adskilt. Virksomhedens opgave er at sørge for, at egne ressourcer ikke åbnes mere end nødvendigt.
Delt ansvar sætter rammen
Cloududbydere beskriver ansvaret som delt. Udbyderen står for den underliggende platform, mens kunden står for egne data, identiteter og den opsætning, der vælges. Hvor grænsen præcist går, afhænger af tjenestetypen. → Delt ansvar i cloud
For bestillingen betyder det, at testen skal rettes mod den del, virksomheden selv har ansvaret for. At udbyderen har sikret sine datacentre, siger intet om, hvorvidt et lagringsområde ved en fejl er gjort tilgængeligt for alle. → Cloududbyderen har styr på sikkerheden
Udbyderne har også regler for, hvad kunder må teste på deres platforme. Microsoft og AWS beskriver hver især, hvad der kan testes uden forudgående godkendelse, og hvilke aktiviteter der ikke er tilladt. Reglerne kan ændre sig og skal læses, før testen planlægges. Læs også de aftaler, virksomheden selv har indgået. Står en partner for opsætningen, kan partnerens kontrakt indeholde egne krav om varsel eller godkendelse. → Er en penetrationstest lovlig?
Før flytningen: kend det, der flytter med
En test før flytningen kan have to formål. Det ene er at kende svagheder i de systemer, der flytter, så de ikke tages med. Et ERP-system med for brede roller er lige så sårbart i cloud som i serverrummet.
Testen før kan også afdække afhængigheder, som ingen har tænkt på: et system, der forventer at stå på samme net som filserveren, eller en integration, der kun virker, fordi alt i dag ligger bag samme firewall. Den slags afhængigheder kan føre til hurtige løsninger under flytningen, hvor der åbnes mere end nødvendigt.
Det andet formål er at afprøve den nye opsætning, før den tages i brug. En flytning kan bygges op i et nyt miljø ved siden af det gamle. Ligner miljøet den kommende drift, kan det testes, før data og brugere flyttes, og fund kan rettes uden at påvirke hverdagen. Forskellen mellem det testede miljø og den senere drift skal dog stå klart i rapporten. → Penetrationstest i produktion eller testmiljø
Efter flytningen: det hører med i scope
Når flytningen er afsluttet, kan scope bygges op omkring de nye grænser.
- Identiteter og roller · hvem der kan administrere hvad, og om konti har flere rettigheder end nødvendigt.
- Det, der er synligt udefra · tjenester, administrationsflader og lagring, der kan nås fra internettet.
- Adskillelse mellem miljøer · om test, udvikling og drift er holdt adskilt.
- Forbindelsen til kontornettet · den forbindelse, der binder cloud og egne lokaler sammen, og hvad den giver adgang til i begge retninger.
- Integrationer · forbindelser mellem cloudsystemerne og andre løsninger. → Integrationer mellem systemer
Omfatter flytningen også Microsoft 365, er det et område med sine egne spørgsmål om afgrænsning. → Microsoft 365 og testen
Hvornår efter flytningen?
Testen efter bør ligge, når opsætningen er stabil, og de midlertidige adgange fra flytteperioden er lukket. Under en flytning kan projektgruppen have fået brede rettigheder for at få arbejdet til at glide. Spørgsmålet er, om de rettigheder stadig findes, når projektet er slut.
Spørg også, hvem der skal kunne ændre opsætningen fremover. Er det driftsleverandøren, en intern medarbejder eller en udvikler hos systemleverandøren? Svaret har betydning for, hvilke roller og administrative adgange testen skal se på.
Testen må heller ikke vente så længe, at opsætningen har nået at ændre sig flere gange uden kontrol. Læg den i projektplanen som en del af afslutningen og ikke som en opgave til senere. Står en ny partner for driften i cloud, er flytningen samtidig et leverandørskifte. → Skift af hosting- eller driftsleverandør
Det skal I lade være med
- At bestille en test af hele cloud · navngiv konti, abonnementer, tjenester og roller.
- At teste udbyderens platform · det er sjældent tilladt og svarer ikke på virksomhedens spørgsmål.
- At glemme vejen tilbage · forbindelsen til kontornettet kan også give adgang den anden vej.
- At lade projektets rettigheder blive stående · midlertidige adgange bør være fjernet før testen eller indgå i den.
- At regne den gamle rapport for gyldig · en rapport fra serverrummet beskriver ikke den nye opsætning.
Hvad kan og ikke kan konkluderes
En test efter flytningen kan vise, hvordan de undersøgte dele af virksomhedens opsætning holdt på testtidspunktet. Den kan ikke dokumentere udbyderens sikkerhed, og den dækker kun de konti og tjenester, der var med i scope.
Konklusioner om cloud forældes også hurtigt, fordi indstillinger kan ændres med få klik. Resultatet bør derfor læses sammen med, hvordan virksomheden styrer ændringer i opsætningen bagefter. En test af et testmiljø før flytningen kan på samme måde ikke stå alene som dokumentation for driften, hvis opsætningen er ændret undervejs. Valget af testtype ved flytningen følger samme principper som ellers. → Typer af penetrationstest
Tjekliste til cloudflytningen
- ☐ Er det skrevet ned, hvilke dele virksomheden selv har ansvaret for?
- ☐ Er udbyderens regler for kunders test læst?
- ☐ Er konti, abonnementer og tjenester navngivet i scope?
- ☐ Er forbindelsen til kontornettet med i testen?
- ☐ Er projektets midlertidige adgange fjernet eller med i scope?
- ☐ Er testen placeret, efter at opsætningen er stabil?
- ☐ Er det aftalt, hvordan ændringer i opsætningen styres bagefter?
Kilder
- Microsoft Learn: Penetration testing: Microsofts regler for kunders test af egne ressourcer i Azure.
- AWS: Penetration testing: AWS’ politik for kunders sikkerhedstest af egne ressourcer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Hvor ofte skal I teste? · Spørgsmål og svar
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
