Digital suverænitet

70 13 63 23

Backup hos samme udbyder er ikke en exit‑mulighed

Backup hos samme udbyder er ikke en exit-mulighed

Mange organisationer har backup af deres cloudtjenester. Kopien ligger dog ofte i samme konto, hos samme udbyder og under samme vilkår som de data, den skal beskytte. Exit-planen hviler på, at mindst én brugbar kopi overlever, hvis adgangen til udbyderen forsvinder.

Artiklen gennemgår, hvordan en kopi hos samme udbyder kan gå tabt sammen med originalen, hvad udbydernes egne vilkår siger om lukning af konti, og hvilke krav exit-planens kopi skal opfylde.

Backup og exit løser to forskellige opgaver

Almindelig backup beskytter mod sletning, fejl og angreb inde i jeres eget miljø. Kopien skal kunne lægges tilbage i den samme tjeneste hurtigt, og derfor ligger den typisk tæt på tjenesten.

Exit-planen stiller et andet spørgsmål. Den spørger, hvad I gør, hvis udbyderen lukker, ændrer eller mister retten til at levere tjenesten. I den situation hjælper en kopi kun, hvis den ligger uden for det, der lukkes. Det skal fremgå af kortlægningen i → trin 1, hvor hver kopi ligger.

Når udbyderens fejl rammer alle kopier

Den australske pensionskasse UniSuper fik i maj 2024 slettet sit private cloudmiljø hos Google Cloud. Ifølge den fælles udtalelse fra UniSuper og Google Cloud fra 8. maj 2024 havde UniSuper miljøet dubleret i to geografiske områder. Sletningen ramte begge.

Samme udtalelse oplyser, at UniSuper havde backup hos en anden tjenesteudbyder, og at den begrænsede datatabet. Google beskrev i sin redegørelse 24. maj 2024, at et tomt felt i et internt værktøj havde givet miljøet en fast løbetid på ét år. Google oplyste også, at kopier i Cloud Storage i samme region ikke blev ramt, og at de sammen med tredjeparts backupsoftware hjalp genopretningen.

Sagen viser, at spredning på flere regioner hos samme udbyder beskytter mod nedbrud på ét sted. Den beskytter mindre godt mod en beslutning eller en fejl, der rammer selve abonnementet. Forløbet er gennemgået i → UniSuper-sagen.

Hvad vilkårene siger om at lukke en konto

Udbydernes egne vilkår beskriver, hvornår de kan suspendere eller opsige en kunde. De er værd at læse med exit-planen ved siden af, fordi en lukket konto typisk også lukker adgangen til de kopier, der ligger i den.

  • AWS · AWS Customer Agreement, opdateret 29. oktober 2026, giver i afsnit 5.2 AWS ret til at opsige straks for at efterkomme lov eller anmodninger fra offentlige myndigheder. Efter afsnit 5.3 gælder kundens frist på 30 dage til at hente sit indhold ikke ved opsigelse efter afsnit 5.2(b).
  • Google · Google Cloud Platform Terms of Service giver i afsnit 4.2 Google ret til straks at suspendere hele eller dele af brugen. Det gælder blandt andet, hvis Google med rimelighed vurderer, at det er nødvendigt for at overholde gældende lov.
  • Microsoft · Microsofts produktvilkår for onlinetjenester oplyser, at kunden har 90 dage til at hente kundedata fra en deaktiveret konto efter udløb. Brud på politikken for acceptabel brug kan føre til suspension af tjenesten.

Vilkårene siger ikke, at udbyderne vil lukke konti. De viser, at grundlaget findes, og at fristen for at hente data kan være kortere end den tid, en flytning kræver.

Sanktioner rammer kontoen og kopierne i den

En udbyder, der er underlagt amerikanske sanktionsregler, kan blive forpligtet til at afbryde en kunde. Mekanismen, og hvordan den rammer tjenester, er beskrevet i → sanktioner og dekreter.

Hvis både produktion og backup ligger hos samme udbyder, rammer en sådan afbrydelse begge på én gang. Det gælder også, hvis backuptjenesten er udbyderens eget produkt. Den dokumenterede sag om en lukket mailkonto hos en international domstol står i → ICC og Microsoft.

Ansvaret for kopien ligger hos kunden

Udbyderne er tydelige om, hvem der har ansvaret for data. Microsofts side om delt ansvar i skyen, opdateret 24. august 2026, angiver kundedata som kundens ansvar i alle driftsformer, også ved software som en tjeneste.

AWS skriver i afsnit 2.3 i sin kundeaftale, at kunden har ansvaret for at sikre, beskytte og tage backup af sine konti og sit indhold. Aftalen nævner også rutinemæssig arkivering af indholdet. Ansvaret for, at en kopi kan bruges ved et skift, ligger altså hos jer, uanset hvor driften foregår.

Uforanderlig lagring og kontoens skæbne

Uforanderlig lagring er et stærkt værn mod angribere, der vil slette eller kryptere backup. AWS beskriver i dokumentationen til S3 Object Lock, at objekter i compliance-tilstand ikke kan overskrives eller slettes af nogen bruger, heller ikke kontoens rodbruger.

Samme side oplyser, at den eneste måde at slette sådan et objekt før tid er at slette den tilknyttede AWS-konto. Låsen følger altså kontoen. Den beskytter mod misbrug af rettigheder i kontoen, mens kontoens fortsatte eksistens afhænger af kundeforholdet til udbyderen.

Egne krypteringsnøgler ændrer heller ikke på det. De holder indholdet utilgængeligt for andre, men de giver ikke adgang til data, der ligger i en lukket konto, jf. → egne nøgler.

Samme jurisdiktion, samme risiko

En kopi hos en anden udbyder flytter risikoen fra den ene udbyders fejl og beslutninger. Den flytter ikke nødvendigvis det juridiske lag. Hvis begge udbydere er underlagt samme stats love, kan samme pålæg ramme dem begge.

Den amerikanske 18 U.S.C. § 2713 pålægger udbydere at udlevere data i deres besiddelse, varetægt eller kontrol, uanset om data ligger i eller uden for USA. Ejerskabet bag backupudbyderen skal derfor slås op på samme måde som ejerskabet bag produktionsmiljøet, jf. → trin 2 og → Cloud Act.

Krav til exit-planens kopi

Exit-planens kopi kan sagtens være en anden end den daglige backup. Den skal opfylde nogle krav, som den daglige backup typisk ikke er bygget til.

  1. Anden udbyder · kopien ligger hos en udbyder eller på udstyr, der ikke afhænger af kontoen hos produktionsudbyderen.
  2. Anden ejer, hvor systemet er kritisk · for de mest kritiske systemer ligger kopien hos en udbyder med en anden ejer og under en anden jurisdiktion end produktionen.
  3. Eget login · adgangen til kopien bruger ikke samme identitetstjeneste som produktionen, så en lukket konto ikke låser jer ude af begge.
  4. Læsbart format · data kan læses uden produktionsudbyderens software, jf. → dokumentformater som binding.
  5. Afprøvet indlæsning · I har mindst én gang lagt kopien ind i et andet system og målt, hvor lang tid det tog.
  6. Kendt omfang · det står skrevet, hvilke data kopien omfatter, og hvilke der mangler, fx indstillinger, rettigheder og historik.

Afprøvningen hører naturligt sammen med testene i → trin 9.

Kravene kan opfyldes i trin. En enkel begyndelse kan være en månedlig eksport af de vigtigste data til lager hos en anden udbyder og udvider, når indlæsningen er afprøvet. Notér for hver kopi, hvem der ejer den, og hvem der kan slette den. Den oplysning bliver vigtig, hvis jeres egne administratorkonti også lukkes.

Lovkravet om backupstyring

Den danske NIS 2-lov, der trådte i kraft 1. juli 2025, kræver i § 6, stk. 1, nr. 3, at omfattede enheder har foranstaltninger for driftskontinuitet, herunder backupstyring og reetablering efter en katastrofe. Nr. 4 omfatter forsyningskædesikkerhed i forholdet til direkte leverandører.

Loven angiver ikke, hvor kopien skal ligge. For enheder, der er omfattet, er det dog naturligt at dokumentere, hvordan backup og leverandørforhold hænger sammen, så det kan forklares ved tilsyn.

Hvad tilgangen kan og ikke kan

En kopi uden for produktionsudbyderen giver jer data at arbejde med, hvis adgangen forsvinder. Den giver også et realistisk tal for, hvor lang tid en flytning tager, når indlæsningen er afprøvet.

Kopien giver ikke en kørende tjeneste. Uden et system at lægge data ind i, og uden brugere der kan arbejde i det, er data kun halvdelen af løsningen. En ekstra kopi koster desuden lagerplads og drift, og det skal indgå i prisen for exit pr. system i → trin 5.

Betydningen for exit-planen

Notér for hvert kritisk system, hvor backup ligger, hvem der ejer udbyderen, og hvilken konto adgangen hænger på. Vælg derefter de systemer, hvor en lukket konto vil koste mest, og etablér en kopi uden for produktionsudbyderen for dem først.

Afprøv indlæsningen af kopien i et andet system mindst én gang om året, og skriv tiden ind i planen. Hvis I er i tvivl om, hvilke systemer der skal prioriteres, kan en uvildig gennemgang hjælpe. Nielco IT laver en jurisdiktions- og afhængighedsvurdering, der omfatter exit-vurdering pr. system.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.

Eller kontakt os på

+45 70 13 63 23

info@nielcoit.dk

Seneste på bloggen

Statens udgifter til Microsoft: hvad tallene viser

Statens udgifter til Microsoft: hvad tallene viser

31. oktober 2026

Fysisk infrastruktur: hvem står bag pc'er, servere og netværksudstyr

Fysisk infrastruktur: hvem står bag pc’er, servere og netværksudstyr

30. oktober 2026

KL og kommunernes digitale handlefrihed

KL og kommunernes digitale handlefrihed

30. oktober 2026