En sikkerhedskopi tæller kun med, hvis I også har testet, at I kan gendanne med den — ikke kun om filen er til stede, men om kildekoden, udviklingspipelineen og de tilhørende hemmeligheder efter en begivenhed fungerer igen. I softwareudvikling handler det ikke blot om et lager, som I kan gendanne, men om hele kæden: versionsstyring, build-servere, pipelines, testmiljøer og de nøgler og tokens, som hører til. Uden en testet gendannelsesprocedure ved I først under en begivenhed, om det virker, og det er det værste tidspunkt at finde ud af det.
NIS2-forsvarspligten nævner kontinuitet og gendannelse udtrykkeligt som en del af de ti foranstaltninger i artikel 21. Direktivet foreskriver ingen fastsat testfrekvens og ingen konkret form — det udfyldes pr. organisation, og den landespecifikke gennemførelse kan give egne accenter til det. Hvad der dog altid vender tilbage, både i spørgeskemaer fra kunder og i det, som tilsynsmyndigheder anser for rimeligt, er sondringen mellem at have en sikkerhedskopi og en sikkerhedskopi, som I har gendannet, og som I ved fungerer.
Hvad 'testet' præcist betyder
En test er ikke det samme som et grønt flueben i sikkerhedskopieringssoftware. Testet betyder, at nogen faktisk har gendannet sikkerhedskopien i et separat miljø, har kontrolleret, at koden kompilerer, at build'et lykkes, og at applikationen fungerer som forventet. Først da ved I, om gendannelsesmomentet er brugbar, og hvor lang tid det tager. En sikkerhedskopi, som udføres, men aldrig gendannes, er i praksis en antagelse om gendannelse, ikke bevist gendannelse.
Hvad I specifikt gendanner i udviklingspipelineen
I softwareudvikling er kildekoden sjældent det eneste, som I kan miste. Tænk på konfigurationen af CI/CD-pipelineen, build-scripts, afhængigheder af eksterne pakker, adgangsformidler til registreringer og cloudmiljøer, og historierne i selve versionsstyringssystemet. En gendannelsesplan, som kun dækker koden, men ikke pipelineen eller hemmeligheder, lader en organisation stadig være stilstande efter en begivenhed. Det er derfor fornuftigt at bestemme for hver af disse dele separat: hvor er sikkerhedskopien, hvem kan gendanne den, og er det nogensinde blevet øvet.
Hvor ofte det er rimeligt at teste
Der er ingen fastsat frist i direktivet for, hvor ofte I skal køre en gendannelsestest. Hvad der i praksis anses for rimeligt, afhænger af, hvor ofte miljøet ændres: en udviklingspipeline, som skifter pipeline-konfiguration hver uge, kræver mere hyppig test end et stabilt miljø, som forbliver uændret i måneder. Mange organisationer vælger et fast kalendermærke — for eksempel hver kvartal — kombineret med en test efter enhver større ændring i infrastrukturen. Vigtigere end frekvensen er, at der overhovedet har været et moment, og at I kan pege på, hvornår.
Hvad I dokumenterer som bevis
En køber, som sender et sikkerhedsspørgeskema, spørger sjældent om teknikken bag jeres sikkerhedskopi. Spørgsmålet er normalt enklere: hvornår blev det testet sidst, af hvem, og hvad var resultatet. For det svar er det tilstrækkeligt at dokumentere tre ting: datoen for den seneste gendannelsestest, hvem der udførte testen, og hvilken del der blev gendannet — kode, pipeline, hemmeligheder eller alt tre. Uden den dokumentation forbliver svaret på spørgeskemaet en erindring i stedet for et bevis, og det er netop den forskel, som en evaluering på den anden side af bordet gerne vil se.
Sammenhængen med resten af dossieret
Back-up og gendannelse står sjældent alene. Hvem der må udføre genoprettelsesproceduren, hænger sammen med adgangskontrol til udviklingspipeline'n; hvad der gik galt under et nedbrud, skal registreres i den samme hændelsesregistrering, som bruges til andre foranstaltninger. At etablere et sådant register behøver ikke at være et særskilt projekt: de ti foranstaltninger opdelt efter situation viser præcis hvor back-up og gendannelse passer ind i helheden, og hvilke andre foranstaltninger der direkte er forbundet hermed.
Om back-up og gendannelse gælder som en pligtoprydelsesforanstaltning for jeres organisation, afhænger af, om I selv falder under NIS2, eller om I modtager dette spørgsmål fra en opdrager, der gør det. i få spørgsmål se hvor I står giver en første indikation heraf med forklaring på hvorfor. Hvordan vi når til denne indikation, og hvilke kilder der ligger til grund herfor, er forklaret på siden om vores arbejdsmåde.
En back-up der aldrig er blevet gendannet, er ingen garanti — det er et spørgsmål, der venter på et svar. Vil I gerne vide, om og hvordan denne foranstaltning er relevant for jeres organisation, og hvad der ellers skal til? Udfør gratis quick-scan'en eller gennemse de hyppigst stillede spørgsmål om NIS2 for spørgsmål, som andre virksomhedsledere allerede har stillet.