De fleste disaster recovery-planer er bare et dokument. Nogen skrev det for to år siden, det ligger i en mappe i SharePoint, og ingen har åbnet det siden den audit eller den kunde, der bad om det. Første gang, det bliver læst under et reelt pres, er det værst tænkelige tidspunkt at opdage, at det er forkert.

Microsoft har selv lukket en del af hullet. Entra ID har nu en indbygget daglig backup af de vigtigste objekter i kataloget: brugere, grupper, apps og Conditional Access-politikker. Det kræver en Entra ID P1- eller P2-licens. Microsoft 365 Backup dækker Exchange, SharePoint og OneDrive med en opbevaringsperiode på op til to år, som I selv kan indstille. Begge dele er nyttige, men ingen af dem er en disaster recovery-plan. Den indbyggede backup i Entra gemmer kun syv dages historik og kun de objekttyper, Microsoft indtil videre har valgt at dække. Microsofts egen vejledning siger det samme: Brug den indbyggede backup som udgangspunkt, og suppler med løsninger fra tredjepart til det, der ligger uden for scope, til længere opbevaring og til fuld genopbygning af en tenant.

Det er i det supplerende lag, den egentlige planlægning ligger, og det er der, de fleste virksomheder stopper. Et backupværktøj uden en testet proces for genoprettelse, en fastlagt rækkefølge for genetablering og en forretning, der har øvet den, er et abonnement. Det er ikke en plan.

Sådan foregår det i praksis

Forløbet følger de anerkendte rammeværk for forretningskontinuitet, ISO 22301, NIST SP 800-34 og god praksis fra BCI og DRI International: først konsekvensen for forretningen, så hullet, så en strategi, så implementering og til sidst øvelse. Detaljerne i hvert trin varierer fra virksomhed til virksomhed, men rækkefølgen er den samme. I er også velkomne til kun at starte med ét af trinene.

1. Konsekvensanalyse og compliancekrav

Kravene starter med en konsekvensanalyse (business impact analysis): hvad det reelt koster i penge, tid og forpligtelser, når hvert system er nede, og hvilke compliancekrav der gælder, fx GDPR, NIS2, DORA, ISO 27001 og de krav, jeres branche ellers stiller. Analysen giver mål for genetableringstid (RTO) og datatab (RPO), der kan forsvares. Kravene til backupværktøjet kommer bagefter og bygger på analysen, ikke omvendt.

2. Hullet mellem mål og virkelighed

Målene for RTO og RPO fra konsekvensanalysen bliver sammenlignet med det, I rent faktisk kan levere i dag. Har I allerede backup og genoprettelse, er det enkelt: Vi måler det. Har I intet endnu, er jeres nuværende kapacitet nul, og hullet er hele målet. Uanset hvad er det hullet, resten af planen skal lukke.

3. Strategi og valg af løsning

ISO 22301 kalder dette trin strategi og valg af løsning. Ud fra hullet i trin 2 beslutter vi, hvordan det skal lukkes. Først ser vi på, hvad markedet allerede har: et færdigt produkt til backup og genoprettelse, et open source-værktøj til konfiguration, der kan bygges videre på, eller en blanding. Derefter beslutter vi, om I skal bygge eller købe, ud fra pris, kontrol og hvad jeres compliancekrav reelt kræver. Svaret er ikke givet på forhånd, og det er ikke altid det samme.

4. Implementering, disaster recovery-plan og runbook

Løsningen fra trin 3 bliver implementeret og konfigureret, og derefter skrives to dokumenter: selve disaster recovery-planen og den tekniske runbook, der beskriver, hvilke systemer der afhænger af hinanden, i hvilken rækkefølge de skal op igen, og hvem der ejer hvert trin. Bygger løsningen på konfiguration frem for et færdigt produkt, gemmes konfigurationen som kode og rulles ud via en versionsstyret pipeline. Så er genoprettelse efter en fejlagtig ændring en tilbagerulning og ikke en manuel genopbygning. Er det i stedet et færdigt produkt, beskriver runbooken produktets egen genoprettelse lige så præcist, og den testes på samme måde.

5. Øvelse og opfølgning

Planen bliver gennemgået som en scenarieøvelse med de folk, der skal udføre den, og de forretningsejere, der er afhængige af den, i stedet for at blive arkiveret efter godkendelsen. Det, øvelsen afslører, fx et trin, der tog længere tid end planlagt, en ejer, der er stoppet, eller en afhængighed, ingen havde kortlagt, bliver skrevet direkte ind i planen og runbooken fra trin 4. Øvelse og opdatering gentages mindst en gang om året, eller når IT-miljøet ændrer sig væsentligt. En plan, der aldrig bliver gennemgået, forælder stille og roligt, indtil den næste hændelse afslører, hvad der har ændret sig.

Det står I tilbage med

Hvis I vælger hele forløbet (anbefalet):

• En konsekvensanalyse bag hvert mål for genetablering. Mål for RTO og RPO, der kan forsvares og ikke er gættet.
• Et dokumenteret hul mellem målene og det, I kan levere i dag. Står I på nul, er det et helt legitimt udgangspunkt.
• En strategi og en beslutning om løsning. Markedet er undersøgt, og valget mellem at bygge og købe er truffet ud fra pris og kontrol, ikke af vane eller fordi et tidligere projekt tilfældigvis brugte det.
• En disaster recovery-plan og en teknisk runbook for den valgte løsning. Navngivne ejere for hvert trin, så rækkefølgen for genetablering er besluttet på forhånd og ikke improviseret.
• En øvet plan, der bliver gennemgået og opdateret fast. Testet sammen med forretningen, så den ikke forælder, indtil den næste hændelse afslører, hvad der har ændret sig.

Bygget på test, ikke papirarbejde

Jeg har gennemført præcis dette forløb på rigtige disaster recovery-opgaver for Entra ID: konsekvensanalyse, hul, strategi og løsning, implementering og øvelse. Det blev valideret med reelle tests af genoprettelse og genudrulning af konfiguration og derefter gennemgået med forretningen som en scenarieøvelse i stedet for at ende som et dokument, ingen åbner. Risikovurderingerne bag arbejdet er lavet op mod CIS Controls, DORA, ISO 27001, NIST CSF og GDPR, som er de rammeværk, en auditor eller en kundes sikkerhedsspørgeskema rent faktisk spørger ind til.

Skal vi tage en snak?

30 minutter, gratis og uforpligtende. Tag den disaster recovery-plan med, I allerede har, også selvom ingen har åbnet den, siden den blev skrevet. Så fortæller jeg, hvilke dele af den der er testet, og hvilke der ikke er.

I kan også sende en besked i stedet.