Ved en flytning til skyen giver det mening at gennemgå konti, grupper og rettigheder før flytningen og lejerens indstillinger efter. Det, der flyttes med, bør være ryddet op. Det, der først findes i det nye miljø, kan først kontrolleres, når det er sat op.
Ingen regel foreskriver rækkefølgen. Den er almindelig praksis og bygger på en enkel tanke: Fejl i det, der flyttes, bliver flyttet med, og fejl i det nye miljø bliver først synlige, når det kører.
Flytningen er en væsentlig ændring
For de fleste virksomheder er bilaget til forordning 2024/2690 en frivillig målestok, fordi forordningen kun binder visse digitale tjenesteudbydere. Efter punkt 6.3.3 skal konfigurationer ses igen med planlagte mellemrum og ved væsentlige ændringer. En flytning af katalog, post, filer eller servere til en cloud-platform er en sådan ændring.
I Cyber Essentials, den britiske ordning, må cloudtjenester i version 3.3 ikke skæres fra, når omfanget lægges fast. Ordningen er kun en sammenligning her, men pointen er nyttig. Det, der flyttes til skyen, forlader ikke jeres ansvar for opsætningen.
Før flytningen: det, der følger med
Alt, der flyttes, tager sine fejl med. Det gælder især identiteten.
- Konti · Det, der gennemgås: Inaktive konti, fratrådte, vikarer og testbrugere · Hvorfor før: De bliver ellers oprettet i skyen
- Grupper · Det, der gennemgås: Medlemmer af administrative og brede grupper · Hvorfor før: Rettigheder følger gruppen med op
- Servicekonti · Det, der gennemgås: Ejer, formål og rettigheder · Hvorfor før: De kan få nye rettigheder i skyen
- Filrettigheder · Det, der gennemgås: Mapper med adgang for alle · Hvorfor før: Rettighederne kan følge filerne
- Synkronisering · Det, der gennemgås: Hvilke konti og attributter der skal op · Hvorfor før: Det, der synkroniseres, bliver svært at rydde op i bagefter
Oprydningen er lettest i det gamle miljø, fordi værktøjerne og vanerne er kendte. Efter flytningen findes de samme fejl to steder. Træk udtrækkene af konti og grupper både før og efter oprydningen, og gem dem. Så kan forskellen vises, og den, der senere gennemgår lejeren, kan se, hvad der bevidst blev lagt ud af flytningen.
Under flytningen: midlertidige adgange
En migrering kræver ofte brede rettigheder til de værktøjer og konti, der flytter data. Det er almindelig praksis at registrere hver af dem med formål og slutdato, så de kan lukkes, når flytningen er færdig.
Bilaget til forordningen kan bruges som målestok også her. Punkt 11.2.2, litra d, taler om at begrænse tredjeparters adgang i omfang og varighed, og punkt 6.7.2, litra h, om forbindelser fra tjenesteudbydere i en bestemt periode. En migreringspartner er netop en sådan tredjepart.
Efter flytningen: det, der først findes nu
Når lejeren kører, kan dens egne indstillinger kontrolleres. Det er almindelig praksis at se på:
- flerfaktor for alle brugere og særligt for administratorer
- politikker for betinget adgang
- hvem der har de administrative roller, og om de er faste eller aktiveres efter behov
- nødkonti, der virker, og hvis brug bliver opdaget
- ekstern deling og gæsteadgang
- auditlog slået til, og hvor længe den gemmes
- de midlertidige migreringsadgange, som skal være lukket
- backup af data i skyen, der ikke dækkes af platformens egne funktioner
For kontorplatformen har den amerikanske myndighed CISA lavet sikkerhedsbaselines til Microsoft 365 og Google Workspace i projektet SCuBA. De er skrevet til føderale myndigheder, men CISA stiller baselines og måleværktøjer til rådighed også for private virksomheder. De kan bruges som målestok for lejeren efter flytningen.
Servere, der flyttes som de er
Flyttes servere uændret til en cloud-platform, følger deres opsætning med. Lokale administratorer, åbne tjenester og gamle protokoller er de samme. Det nye er netværket omkring dem. I skyen styres åbningerne af platformens egne regler, og en server, der før stod bag firewallen, kan få en offentlig adresse med et enkelt valg.
Gennemgangen efter flytningen bør derfor sammenligne de åbninger, serveren havde før, med dem, den har nu. Hver åbning mod internettet, der ikke fandtes før, skal kunne begrundes.
Ansvaret flytter ikke med
Platformens udbyder driver det underliggende. Opsætningen af lejeren, kontiene og åbningerne er stadig jeres. Hvordan grænsen trækkes, og hvad udbyderens egne erklæringer dækker, står i delt ansvar.
Efter flytningen: det, der stadig står tilbage
En migrering efterlader ofte rester i det gamle miljø. Servere, der skulle lukkes, kører videre. Firewallregler til det gamle system står åbne. Konti, der blev brugt til synkronisering, har stadig rettigheder. En gennemgang efter flytningen bør derfor også se bagud på det miljø, der blev forladt.
Ventetid efter flytningen
Det er en god idé at vente lidt med gennemgangen efter flytningen, til opsætningen har sat sig, og de første rettelser er lavet. En vurdering kan efter NIST lægges efter en større opgradering. Ventes der for længe, bliver de midlertidige adgange til faste, og ingen husker, hvorfor de blev givet.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at gennemgangen står i migreringsplanen med to punkter: oprydning før og kontrol efter. Det kræver også en liste over midlertidige adgange med slutdatoer.
Springes oprydningen over, flytter fratrådte medarbejderes konti, brede grupper og forældede rettigheder med til et miljø, der kan nås fra hele internettet. Springes kontrollen efter over, kører lejeren med de indstillinger, den blev oprettet med, og dem, migreringen tilføjede undervejs.
Det skal I lade være med
- At flytte konti uden at rydde op først · fejlene følger med.
- At lade migreringsadgange stå åbne efter flytningen · de har ofte de bredeste rettigheder.
- At glemme det gamle miljø · servere og regler, der skulle lukkes, kører ofte videre.
Det skal gennemgangen kunne vise
- ☐ Udtræk af konti og grupper før flytningen og efter oprydningen.
- ☐ En liste over midlertidige migreringsadgange med dato for lukning.
- ☐ Lejerens indstillinger holdt op mod en navngiven målestok.
- ☐ Status for de systemer og regler i det gamle miljø, der skulle lukkes.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690, artikel 1 og bilaget punkt 6.3.3, 6.7.2 og 11.2.2, læst 13. november 2026.
- NCSC, Cyber Essentials: Requirements for IT Infrastructure v3.3, april 2026, læst 13. november 2026.
- CISA, Secure Cloud Business Applications (SCuBA) Project, læst 13. november 2026.
- NIST, SP 800-115 Technical Guide to Information Security Testing and Assessment, september 2008, afsnit 6.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv oprydningen før og kontrollen efter ind i migreringsplanen som to faste punkter.
Læs også: Gennemgang af Microsoft 365 · Inaktive og forældreløse konti
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
