Backup og gendannelse: Sådan bygger du en strategi der kan teste og dokumenteres

Hvad skal strategien kunne – ud over at tage backup?

En backup, der aldrig er gendannet, er ikke en strategi, men en forventning. Det afgørende er, at I kan få data og processer tilbage, så I kan arbejde videre – og dokumentere, at det lykkes.

For de fleste organisationer er backup også et databeskyttelsesspørgsmål. Datatilsynet har et selvstændigt emne om behandlingssikkerhed, vejledning om risikovurdering og et katalog over sikkerhedsforanstaltninger. Brug dem som fagligt grundlag, når I begrunder og prioriterer valg.

Offentlige myndigheder og organisationer med borgernære data finder supplerende materiale om databeskyttelse og GDPR på Sikker digital. Private virksomheder kan hente tilsvarende hjælp på Virksomhedsguiden under temaet om at behandle og beskytte personoplysninger, herunder en skabelon til databehandleraftale.

Strategien bør kunne tre ting: beskrive hvad der skal kunne gendannes, og hvor hurtigt; hvordan I tester det; og efterlade dokumentation, som andre kan læse og forstå. Det gælder også, hvis personen, der byggede løsningen, ikke er der længere.

Risikovurdering: Vælg data, processer og scenarier

Begynd med at beslutte, hvad der er værd at gendanne. Hele it-miljøet er sjældent lige kritisk. Gennemgå systemer og processer, og spørg: Hvilke data kan vi ikke drive forretning eller opgaveløsning uden? Hvor længe kan vi undvære dem, og hvad koster det i kroner, tid, tillid og efterlevelse, hvis de er væk i en time, et døgn eller en uge?

Datatilsynets oversigt over regler og vejledning har blandt andet emnerne »Risikovurdering« og »Katalog over sikkerhedsforanstaltninger«. Vurderingen bør være skriftlig og dateret, så den senere kan læses som beslutningsgrundlag.

Vurder for hvert kritisk system, hvor meget data I må miste, og hvor længe systemet må være nede. Tallene er ikke identiske: Et system kan tåle at være nede i timevis, hvis intet data går tabt, mens et andet kan tåle et datatab på få minutter, hvis det blot kommer op igen med det samme. Grænserne bliver senere acceptkriterier i testen.

Vælg derefter konkrete scenarier, I vil teste imod. Typiske scenarier er ransomware eller anden ondsindet kryptering, fejlsletning eller overskrivning af data, hardware- eller diskedefekt, nedbrud eller lukning hos en cloud- eller hostingleverandør samt fysisk hændelse som brand, vandskade eller tyveri.

For hvert scenarie: Hvad er konsekvensen, og hvor langt tilbage skal vi kunne gendanne? Og hvilke afhængigheder – netværk, adgangskontrol, certifikater, integrationspartnere – skal også være på plads, før systemet reelt virker igen?

Prioriter til sidst. I kan ikke teste alt lige grundigt, og en strategi, der forsøger, holder sjældent. Vælg de få systemer og scenarier med størst konsekvens, og test dem grundigt og regelmæssigt. Resten kan dækkes af enklere og sjældnere test – men de skal stadig beskrives og planlægges.

Dokumentation af backup og gendannelse

Dokumentationen skal kunne bruges af nogen, der ikke har bygget løsningen. En praktisk struktur er fire dele: en fortegnelse over, hvad der backes op, og hvor det ligger; procedurer for gendannelse; en ansvarsoversigt; og et arkiv med beslutningsgrundlag og testresultater.

Fortegnelsen er kernen. For hvert system bør den mindst svare på: Hvilke data og hvilken konfiguration indgår, hvor opbevares kopien, hvor længe, hvem har adgang, og hvilken gendannelsestid og datatabsgrænse er aftalt. Datatilsynet har en vejledning om fortegnelse, som kan sikre, at den også dækker relevante behandlinger af personoplysninger. Fortegnelsen skal vedligeholdes, når systemer kommer til eller falder bort – en forældet fortegnelse er værre end ingen, fordi den giver falsk tryghed.

Procedurerne skal være skrevet, så de kan følges under pres. Beskriv trin for trin, hvordan en gendannelse startes, hvem der skal kontaktes, hvordan man verificerer, at data er komplette og konsistente, og hvordan man vender tilbage til normal drift.

Læg dem et sted, hvor de er tilgængelige, selv når de normale systemer ikke er – det er præcis i den situation, de skal bruges. Test gerne proceduren ved at lade en kollega uden kendskab til løsningen gennemgå den og fortælle, hvor den er uklar.

Beslutningsgrundlaget er den del, mange springer over: Hvorfor er en bestemt opbevaringsperiode, leverandør eller gendannelsesniveau valgt? Her bliver risikovurderingen til et dokument, som ledelsen kan godkende og senere henvise til. For virksomheder, der behandler personoplysninger på vegne af andre, eller har leverandører, der gør det, hører databehandleraftaler med til dette lag – Virksomhedsguiden har en skabelon til databehandleraftale, der kan bruges som udgangspunkt.

Testresultaterne er den sidste del – og den, der gør strategien troværdig. Gem dem kronologisk: dato, scenarie, hvem deltog, hvad blev målt, hvad gik galt, og hvilke ændringer det førte til. Undlad at pynte. Et dokumenteret nederlag med en opfølgende rettelse er langt stærkere end en rapport uden afvigelser, som ingen tror på.

Dokumentationskrav for en troværdig backup-strategi

Test og øvelse: Vis at gendannelse virker

En test består af tre ting, der besluttes på forhånd: et scenarie, et acceptkriterium og en rollefordeling. Scenariet hentes fra risikovurderingen. Acceptkriteriet formuleres målbart – for eksempel at en navngiven proces kan køre videre på gendannede data inden for den aftalte tid, og at et på forhånd defineret datasæt er komplet efter gendannelsen.

Start med den enkleste test: gendan en enkelt fil eller database til et isoleret miljø, og verificer indholdet. Det afdækker overraskende ofte fejl i selve backup-jobbet.

Byg derefter op til scenarietest, hvor flere systemer gendannes i den rækkefølge, de afhænger af hinanden. Til sidst en fuld øvelse, hvor medarbejderne arbejder ud fra de skriftlige procedurer uden at kunne spørge den, der normalt fikser det.

Mål undervejs, ikke bagefter. Noter hvornår gendannelsen blev startet, hvornår data var tilgængelige, hvornår systemet var i drift igen, og hvor mange manuelle indgreb der var nødvendige. Manuelle trin er en risiko i sig selv: de tager tid og fejler under stress. Hvis proceduren kræver, at en bestemt person er til stede, bør det stå tydeligt i dokumentationen.

Hyppigheden bør følge kritikaliteten. Kritiske systemer testes oftere end perifere, og testen bør gentages, når noget ændrer sig væsentligt – ny version af systemet, ny leverandør, ny opbevaringsløsning eller ændret datamængde. Sikkerheden bør vurderes løbende, fordi forholdene ændrer sig over tid. En gendannelsestest fra sidste år siger ikke nødvendigvis noget om det miljø, I har i dag.

Afslut hver test med et kort møde, hvor afvigelser bliver til handlinger med ejer og dato. Ellers bliver testen et ritual, og næste gang gentager I den samme fejl.

Kritikalitet vs. testfrekvens – hvordan prioriteres?

Roller og ansvar i test og dokumentation

Før I fordeler opgaver, bør I afklare, hvem der er dataansvarlig, og hvem der er databehandler. Datatilsynet har afsnit om dataansvarlig og databehandler samt om rollefordeling. Det er det rette sted at afklare grænsedragningen, hvis I er i tvivl.

Rollefordelingen får direkte betydning for backup. Ligger jeres data hos en ekstern leverandør, skal det stå klart, hvem der tager backup, hvem der kan gendanne, hvor hurtigt leverandøren skal reagere, og hvordan I får adgang til jeres egne data, hvis samarbejdet ophører. Det hører hjemme i databehandleraftalen og bør kunne dokumenteres – Virksomhedsguiden har en skabelon til databehandleraftale, der kan bruges som afsæt.

Internt er det en fordel at dele ansvaret i fire tydelige funktioner. Den ene ejer strategien og beslutningerne, den anden drifter backup og gennemfører gendannelser, den tredje tester og rapporterer, og den fjerde godkender resultatet og de ændringer, testen giver anledning til.

I små organisationer kan de samme personer dække flere funktioner. Det bør fremgå skriftligt, og godkendelsen bør så vidt muligt ligge hos en anden end den, der testede.

Sørg for, at ansvaret er knyttet til funktioner og ikke kun til navne. Folk skifter job. Dokumentationen skal fungere videre, når medarbejderen gør, og det gør den kun, hvis den beskriver roller, opgaver og procedurer frem for personafhængig viden.

Endelig bør ledelsen have en rolle. Nogen skal kunne godkende prioriteringen, acceptere de resterende risici og afsætte de ressourcer, en test koster i driftstid. Ledelsen bør have et grundlag, hvor tekniske valg og risici er beskrevet, så beslutningstagere kan forholde sig til dem.

Fordel og ulempe ved intern vs. ekstern gendannelse

Fra hændelse til forbedring: Gendannelse ved brud

Backup og gendannelse er en del af jeres beredskab. Når noget går galt – kryptering, fejlsletning eller nedbrud – er det for sent at finde ud af, hvordan gendannelsen foregår. En nedskrevet og testet plan gør en hændelse håndterbar; en plan, der kun findes i hovedet på én person, gør den til en krise.

Hvis hændelsen indebærer et brud på persondatasikkerheden, kommer databeskyttelsesreglerne ind. Datatilsynet har vejledning om både anmeldelse af brud og håndtering af brud på persondatasikkerheden, og deres oversigt over de ti typiske brud kan bruges til at genkende mønstre. For at kunne håndtere et brud bør I på forhånd vide, hvem der vurderer, hvem der anmelder, og hvor oplysningerne om hændelsen samles.

Gendannelse og anmeldelse hænger sammen i praksis: For at vurdere omfanget af et brud skal I vide, hvilke data der var berørt, hvor langt tilbage de kan gendannes, og om der er tegn på, at oplysninger er kommet ud. Derfor bør logning og dokumentation af backup-jobbet være en del af beredskabet, ikke et separat teknisk anliggende.

Efter hændelsen følger læringen. Gennemgå systematisk: Virkede gendannelsen inden for den aftalte tid, og hvilke trin gik anderledes end forventet? Var dokumentationen tilstrækkelig, og kunne den bruges under pres? Hvilke ændringer kræver hændelsen i risikovurderingen, fortegnelsen, procedurerne og testplanen?

Sæt det ind i en fast cyklus. Ændringer i miljøet – nye systemer, nye leverandører, ændrede datamængder – skal føre til en opdateret risikovurdering, som igen skal føre til opdaterede testscenarier og acceptkriterier. Testresultater og hændelser skal føre til opdaterede procedurer og et opdateret dokumentationsgrundlag.