Når infrastrukturen flytter til en ny udbyder, skal sikkerheden bygges op igen. Rettigheder, netværksregler, nøgler og overvågning er bygget med den gamle udbyders værktøjer og begreber, og selv om konfigurationen kan eksporteres, virker den ikke af sig selv hos den nye.
Cloud sikkerhed betyder her de kontroller, der beskytter jeres systemer i et miljø, I deler med udbyderen. Hvem der har ansvaret for hvad, afhænger af tjenestetypen. Ved infrastruktur som tjeneste bestemmer kunden over operativsystem, lagring og egne installerede programmer, mens udbyderen har resten under sig. Ved platformstjenester rykker grænsen op, og kunden styrer mindre. Inddelingen er den amerikanske standardorganisation NIST’s fra 2011. Læs ansvarsdeling på en europæisk platform.
Hvad Data Act siger, og hvad den ikke dækker
Ved et skift af cloududbyder giver Data Act (dataforordningen) jer ret til at tage data og digitale aktiver med. Kommissionens spørgsmål og svar til forordningen nævner konfiguration, sikkerhed og adgangsrettigheder som eksempler på digitale aktiver, i det omfang kunden råder over dem uden udbyderens mellemkomst.
Det betyder, at I kan forlange at få beskrivelsen af jeres opsætning med. Vores læsning er, at den ret ikke sikrer, at opsætningen virker hos den nye udbyder. En rolle, en regel eller en politik er skrevet i den gamle udbyders sprog, og den nye har sine egne begreber.
Det, der skal bygges op igen
Rettigheder. Hver udbyder har sin egen model for roller, grupper og politikker. Kan en rolle læse alt i et projekt, eller kun i én ressource? Arves rettigheder nedad? Gennemgå, hvem der har adgang til hvad i dag, og oversæt det til den nye model. Det er også det rigtige tidspunkt at fjerne rettigheder, ingen bruger. Læs hvem kan logge ind.
Netværksregler. Regler for, hvilken trafik der må nå hvilke servere, kan ligge i udbyderens egne sikkerhedsgrupper, i en virtuel firewall eller i operativsystemet. Den nye udbyder kan have en anden model, fx regler på netværket frem for på den enkelte server. Reglerne skal skrives om og testes. En regel, der falder bort i oversættelsen, kan åbne for noget, der var lukket.
Nøgler og hemmeligheder. Krypteringsnøgler, der ligger i udbyderens nøgletjeneste, kan være låst til tjenesten, så de ikke kan tages med. Spørg udbyderen. Kan de ikke tages med, dekrypteres data i det gamle miljø og krypteres igen i det nye med nye nøgler. Adgangskoder og certifikater, som systemerne bruger, skal ind i en ny løsning til hemmeligheder. Læs nøgler i cloud.
Logning og hændelsesovervågning. Hvilke hændelser logger platformen, hvor længe gemmes de, og kan de sendes til jeres egen overvågning? De regler, der i dag udløser en alarm, bygger på den gamle udbyders hændelser. Hos den nye skal de skrives om, og de skal testes ved at fremprovokere hændelserne. Læs overvågning og logs.
Sårbarhedsstyring. Hvem holder operativsystemer og platformskomponenter opdateret? Ved en mindre udbyder kan flere af de opgaver, en stor udbyder løste i en administreret tjeneste, lande hos jer.
Backup og sletning. Backup skal være beskyttet mod sletning og ændring på den nye platform, og adgang til at slette backup skal være begrænset. Læs uforanderlig backup.
Rækkefølgen
Sikkerheden bygges op sammen med fundamentet, før det første system flytter: identitet og rettigheder, netværksregler, logning. Først når de er afprøvet, flytter systemerne. Læs rækkefølgen i infrastrukturen.
Før beslutningen om udbyder hører et sikkerhedsreview af den nye leverandør med. Her er det det tekniske arbejde bagefter, der er emnet.
Hvad det kræver, og hvad det koster at lade være
Opbygningen kræver en, der kender jeres nuværende sikkerhedsopsætning, en, der lærer den nye udbyders model, og tid til at teste hver kontrol. Har I en ekstern sikkerhedsleverandør, skal den med fra begyndelsen. Skøn dagene pr. område som spænd, og læg arbejdet, før systemerne flytter.
Uden opbygning flytter systemerne ind med for brede rettigheder, åbne porte og en overvågning, der ikke ser noget. Det opdages ved en revision, ved et kundespørgeskema eller ved en hændelse, ingen fik alarm om. Prisen er da at bygge sikkerheden op under drift, med systemer, der allerede bruges.
Det skal I lade være med
- At importere den gamle opsætning ukritisk · begreberne er forskellige, og en regel kan betyde noget andet hos den nye udbyder.
- At flytte systemer før logningen virker · en hændelse i overgangen skal også kunne ses.
- At regne med, at udbyderen gør det samme som før · ansvarsfordelingen kan være en anden, og det skal stå skrevet.
Det skal valget kunne vise
- ☐ En oversættelse af roller og rettigheder til den nye model.
- ☐ Netværksregler skrevet om og testet.
- ☐ Nøgler og hemmeligheder i en ny løsning med kendte ansvarlige.
- ☐ Alarmregler, der er testet ved at fremprovokere hændelserne.
- ☐ En skrevet ansvarsfordeling mellem jer og udbyderen.
Kilder
- NIST SP 800-145, The NIST Definition of Cloud Computing, september 2011.
- Europa-Kommissionen, FAQ om Data Act, version 1.4, punkt 53.
Senest gennemgået: november 2026.
Næste skridt
Lav en liste over jeres sikkerhedskontroller i dag, og skriv ud for hver, hvilket værktøj hos den nuværende udbyder den bygger på. Det er listen over det, der skal bygges op igen.
Læs også: Kryptering før upload · Test og de første 90 dage
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
