En katastrofegjenopprettingsplan er den dokumenterte prosedyren for å gjenopprette teknologitjenester etter en feil, som dekker hvilke systemer som kommer tilbake i hvilken rekkefølge, hvor lang tid hvert system bør ta, hvor mye datatap som er akseptabelt og hvem som utfører arbeidet. Det er det tekniske laget av kontinuitetsplanlegging. Der en kontinuitetsplan holder virksomheten i gang uansett middel, handler en gjenopprettingsplan spesifikt om å få systemene i gang igjen.
- En prioritert systemliste, arvet fra forretningsanalyse snarere enn oppfunnet av IT.
- Et gjenopprettingsmål og et akseptabelt datatapstall for hvert system.
- Løpebøker detaljerte nok til at noen andre enn den vanlige personen kan følge dem.
- Avhengighetsrekkefølgen, fordi systemer som er gjenopprettet i feil rekkefølge ikke dukker opp.
- En testlogg, siden en uprøvd gjenopprettingsprosedyre er en hypotese.
Hva er en katastrofegjenopprettingsplan?
En katastrofegjenopprettingsplan beskriver hvordan teknologitjenester gjenopprettes etter en hendelse som setter dem ned: maskinvarefeil, datasentertap, en mislykket endring, et strømbrudd i skyområdet, løsepengevirus. Den svarer på tre spørsmål for hvert system som er omfattet. Hvor raskt må det være tilbake, hvor mye nye data har vi råd til å miste, og hva gjør man egentlig for å få det tilbake?
Ordet katastrofe er misvisende. De fleste kall er ikke dramatiske. En ødelagt database, en mislykket migrering eller et utløpt sertifikat på en kritisk tjeneste vil sende deg til samme plan som en flom. Å skrive planen kun for katastrofale scenarier lar deg improvisere deg gjennom de langt vanligere.
Gjenopprettingsplanlegging er en del av den bredere kapasiteten som er beskrevet under forretningskontinuitet , og det er der prioriteringene og tidsrammene for gjenoppretting kommer fra. Hvis teknologiperspektivet er bygget uten disse, beskytter planen systemer i en rekkefølge som ingen har validert mot virksomheten.
Hvordan velger du en gjenopprettingsmetode?
Gjenopprettingsmålet dikterer arkitekturen, og arkitekturen dikterer kostnaden. Dette er avveiningen som bestemmer alt annet i planen, og det er verdt å gjøre det eksplisitt i stedet for å arve det infrastrukturen tilfeldigvis støtter. Det finnes tre brede alternativer, og vokabularet rundt dem er lite nyttig teknisk for det som er ganske enkle ideer.
| Gjenoppretting av sikkerhetskopi | Varm standby | Aktiv-aktiv | |
|---|---|---|---|
| Hva det er | Gjenoppbygg tjenesten fra siste sikkerhetskopiering etter en feil | En annen kopi fortsatte å kjøre, men var inaktiv, byttet til ved behov | To levende kopier som deler verket, så det er ingenting å slå på |
| Vindu for datatap | Siden siste sikkerhetskopiering | Minutter med data | Nær null |
| Tid for å gjenopprette | Timer til dager | Minutter til timer | Nær null |
| Beskytter mot | Dårlige eller krypterte data | Tap av infrastruktur | Tap av nettsted eller region |
| Faste kostnader | Bare lagring | Del av et andre bo | To levende eiendommer |
| Egnet til | Tjenester som tåler strømbrudd | De viktigste tjenestene | Tjenester som ikke kan stoppes |
Få organisasjoner trenger den samme tilnærmingen overalt. Det nyttige mønsteret er å lage lag: et lite antall tjenester som virkelig ikke kan stoppe får dyr beskyttelse, flertallet får noe proporsjonalt, og den lange halen gjenopprettes fra sikkerhetskopiering. Å bruke én tilnærming jevnt fører enten til at man bruker for mye penger på aktiviteter som kan tåle en dag, eller at de kritiske få får en gjenopprettingstid som virksomheten allerede har avvist.
To feilmoduser gjentar seg. Den første er et gjenopprettingsmål valgt uten å prise arkitekturen som leverer det, slik at planen forplikter seg til noe infrastrukturen ikke kan gjøre. Den andre er å kjøpe replikering og anta at det er gjenoppretting, når et ødelagt eller kryptert datasett replikeres like trofast som et godt et. Replikering beskytter mot tap av infrastruktur. Sikkerhetskopier beskytter mot dårlige data, og de to er ikke erstatninger.
Hva bør en katastrofeberedskapsplan inneholde?
Per system, ikke per organisasjon. Et enkeltstående narrativt dokument som beskriver tilnærmingen generelt, er ikke brukbart klokken tre om morgenen av den som er på vakt.
- Gjenopprettingsmål: tidsmålet og akseptabelt datatap for det systemet, spores tilbake til forretningsanalysen som satte dem.
- Avhengighetsrekkefølge: hva som må kjøre først. Autentisering, nettverk, DNS og databaser går vanligvis foran applikasjonene som trenger dem.
- Løpeboken: de faktiske trinnene, skrevet slik at en kompetent ingeniør som ikke eier systemet kan utføre dem.
- Tilgang og legitimasjonhvordan privilegert tilgang oppnås under en hendelse, og oppbevares et sted som overlever feilen.
- Datagjenoppretting: hvor sikkerhetskopier er, hvordan man verifiserer integriteten, og hvor lang tid en gjenoppretting faktisk tar med reelle datamengder.
- Verifiseringhvordan du bekrefter at tjenesten faktisk fungerer i stedet for bare å kjøre.
- Roller og eskaleringhvem bestemmer å påkalle, hvem utfører, hvem kommuniserer og hvem autoriserer et reservetiltak.
Av disse får avhengighetsrekkefølgen mest oppmerksomhet, fordi å gjøre feil fører til feil som ser ut som et ødelagt system snarere enn en sekvenseringsfeil. En applikasjon som gjenopprettes før databasen den leser, eller før identitetstjenesten den autentiserer mot, vil ikke starte, og teamet mister tid på å diagnostisere feil problem. Den generelle formen gjelder for de fleste system.
Detaljen som oftest viser seg å mangle er hvor lang tid en gjenoppretting egentlig tar. En sikkerhetskopiering som fullføres over natten kan ta betydelig lengre tid å gjenopprette ved produksjonsvolum, og hvis ingen har målt det, er gjenopprettingsmålet en gjetning.
Én grense er verdt å trekke. En gjenopprettingsplan gjenoppretter systemene. Løsningen bedriften bruker mens det skjer, for én spesifikk navngitt risiko, hører heller hjemme i en beredskapsplan . Organisasjoner som bare beholder teknologiplanen, har en tendens til å oppdage at ingen ble enige om hvordan arbeidet skulle fortsette i mellomtiden.
Det er et større bilde bak dette.
Denne siden dekker én del av forretningsrobusthet. Real Resilience – IOs rammeverk for å koble sammen sikkerhet, personvern og AI-styring – er der hele bildet kommer sammen.
Hvordan tester du en katastrofegjenopprettingsplan?
Det er gjennom testing at gjenopprettingsplaner får sin troverdighet, og det skjer en progresjon. Hvert nivå koster mer og beviser mer, og et program som aldri forlater det første nivået har ikke etablert seg særlig mye.
| Testtype | Hva det beviser | Hva det koster |
|---|---|---|
| walkthrough | At dokumentasjonen er fullstendig og forståelig for noen som ikke har skrevet den. | Noen få timer. Ingen systemer er berørt. |
| Bordøvelse | At folk kjenner rollene sine og at beslutningstaking og eskalering fungerer under press. | En halv dag av de rette menneskenes tid. |
| Gjenoppretting av komponenter | At sikkerhetskopier faktisk kan gjenopprettes, og at den faktiske gjenopprettingsvarigheten er kjent. | Moderat. Trenger et isolert miljø. |
| Delvis failover | At en enkelt tjeneste kan kjøre fra sin gjenopprettingsposisjon, inkludert avhengigheter. | Betydelig planlegging. Noe tjenesterisiko. |
| Full failover | At hele miljøet kan kjøre fra gjenoppretting, ved belastning, med virksomheten som jobber med det. | Høy. Trenger vanligvis et planlagt vindu. |
Registrer hva som mislyktes. En testlogg som viser problemer som er funnet og løst, er sterkere bevis på en fungerende evne enn en serie med feilfrie beståtte testresultater, som hovedsakelig tyder på at testene ikke var krevende nok. Funn med eiere og datoer er det som gjør testing til forbedring snarere enn beroligelse.
Hvilke standarder dekker katastrofegjenoppretting.
Ingen standard er utelukkende dedikert til katastrofegjenoppretting, så kravene er fordelt på flere, noe som er en av grunnene til at gjenopprettingsplanlegging ofte ender opp med å være frakoblet alt annet.
- ISO 22301: det sertifiserbare styringssystemet for forretningskontinuitet. Det setter analyse- og gjenopprettingsprioriteringene som en teknologiplan skal arve.
- ISO / IEC 27031veiledning spesifikt om IKT-beredskap for forretningskontinuitet, som er det fagfeltet som passer best opp mot katastrofegjenoppretting.
- ISO 27001Vedlegg A inneholder kontroller for informasjonssikkerhet under avbrudd, IKT-beredskap for kontinuitet og sikkerhetskopiering av informasjon, slik at gjenopprettingskapasiteten undersøkes under en revisjon.
- Sektorreglerregulerte organisasjoner står overfor ytterligere forventninger, for eksempel kravene til kontinuitet og gjenoppretting i henhold til Veiledning for implementering av NIS 2.
Å jobbe i henhold til ISO 22301 og ISO 27001 sammen produserer mesteparten av bevisene disse regimene ber om, i en form som allerede er blitt uavhengig revidert.
Start din gratis prøveperiode
Vil du utforske?
Registrer deg for din gratis prøveversjon i dag og få hands on med alle samsvarsfunksjonene som ISMS.online har å tilby
Hvordan er katastrofegjenoppretting knyttet til robusthet?
Katastrofegjenoppretting gjenoppretter systemer. Motstandskraft er den bredere evnen til å absorbere forstyrrelser av noe slag, inkludert hendelser ingen runbook forventer. Koblingen mellom dem er at gjenoppretting helt avhenger av kontroller som ligger utenfor gjenopprettingsplanen: om sikkerhetskopier er uforanderlige, om privilegert tilgang fortsatt fungerer når identitetsleverandøren er nede, om leverandøren som er vert for gjenopprettingsmiljøet har blitt vurdert, om hendelsesresponsprosessen fungerer.
Resilience Loop kjører informasjonssikkerhet under ISO 27001, databeskyttelse under ISO 27701 og AI-styring under ISO 42001 som ett sammenkoblet system, med gjenoppretting som et ytterligere perspektiv over de samme kontrollene. Løsepengevirus presiserer dette tydelig. Det er samtidig en sikkerhetshendelse, potensielt et brudd på personopplysninger og en gjenopprettingshendelse, og en organisasjon som kjører disse tre som separate programmer, reagerer på det tre ganger. Strukturen som unngår dette er fastsatt i rammeverket for forretningsrobusthet.
Hvordan beviser du at katastrofegjenoppretting fungerer?
Ingen troverdige aksepterer eksistensen av en plan som bevis. Det som står mål er selve planen med gjeldende gjenopprettingsmål, testrapporter som viser datoer og deltakere, feilene disse testene avdekket, utbedringen som fulgte, og bekreftelse på at planen fortsatt samsvarer med tilstanden den beskriver.
Disse bevisene genereres mens arbeidet pågår, og er alltid tilgjengelige. De samles før en revisjon eller en kundes due diligence, og de pleier å avsløre hvor langt den dokumenterte eiendommen har avviket fra den virkelige. Tilnærmingen er beskrevet i hvordan man dokumenterer robusthet , og robusthetspoengsummen gir deg et grunnlag å jobbe ut fra.
Hvorfor velge ISMS.online for planlegging av katastrofegjenoppretting?
Gjenopprettingsplaner mislykkes mye oftere på valuta enn på innhold. ISMS.online er bygget for å holde dem i tråd med boet.
- Planer knyttet til systemene de dekkerHver oppføring kobler seg til aktivumet, eieren og kontrollene det er avhengig av, slik at avviket er synlig.
- Gjenopprettingsmål arvet, ikke oppfunnetMålene som er satt i forretningsanalysen, videreføres til teknologiplanen.
- Testplaner og funn samletPlanlegg øvelser, registrer hva som mislyktes og spor korrigerende tiltak på samme sted som planen.
- Ett kontrollsett, hvert rammeverksikkerhetskopiering, tilgang og leverandørkontroller kartlagt én gang og gjenbrukt på tvers av ISO 22301, ISO 27031, ISO 27001, ISO 27701 og ISO 42001.
- Leverandøravhengigheter vurdertTredjepartene som gjenopprettingen din i stillhet er avhengig av, administreres i samme system.
- Informert av dyp ekspertiseVeiledet implementering fra spesialister som har drevet gjenopprettingsprogrammer i regulerte miljøer.
- Bygget for britiske og regulerte markederUtviklet for organisasjoner som må bevise gjenopprettingskapasitet overfor revisorer og kunder.
Se hvordan det passer sammen på plattformen for forretningsrobusthet , eller bestill en demonstrasjon.
Spørsmål og svar
Hva er forskjellen mellom en katastrofegjenopprettingsplan og en plan for forretningskontinuitet?
En katastrofegjenopprettingsplan gjenoppretter teknologiske tjenester. En kontinuitetsplan holder virksomheten i gang gjennom forstyrrelser på alle tilgjengelige måter, som kan inkludere manuelt arbeid mens systemer er nede. Gjenoppretting er en del av kontinuitet snarere enn et alternativ til den, og gjenopprettingsmålene i teknologiplanen bør komme fra forretningsanalysen som kontinuitetsplanen er bygget på.
Hva bør RTO og RPO være?
Begge kommer fra analysen av forretningsmessige konsekvenser snarere enn fra hva infrastrukturen kan levere for øyeblikket. Gjenopprettingstiden er avledet fra det punktet hvor forstyrrelser i aktiviteten blir uakseptable, satt med en margin innenfor denne grensen. Gjenopprettingspunktet følger av hvor mye nyere data virksomheten har råd til å rekonstruere eller miste. Å sette en av disse ut fra nåværende teknisk kapasitet produserer mål som alltid blir møtt og ikke beviser noe.
Hva er forskjellen mellom varm standby og aktiv-aktiv?
Varm standby holder en andre kopi av tjenesten kjørende, men inaktiv. Den betjener ingen før du failover til den, så gjenoppretting innebærer en bevisst bytte, og den bytten tar tid og kan gå galt. Aktiv-aktiv betyr at to levende kopier begge håndterer reelt arbeid samtidig, så å miste den ene lar den andre allerede være i drift, og det er ingenting å slå på. Aktiv-aktiv fjerner failover-trinnet og er tilsvarende dyrere, fordi du kjører og lisensierer to produksjonsmiljøer i stedet for ett og et ekstra.
Hvor ofte bør en katastrofeberedskapsplan testes?
Minst én gang i året for en meningsfull test, med lettere gjennomganger oftere og en gjennomgang når testresultatene endres vesentlig. Hyppighet teller mindre enn progresjon: en organisasjon som kjører den samme tabellen hvert år vet at de ansatte forstår rollene sine, men har fortsatt ingen bevis for at en gjenoppretting fungerer ved produksjonsvolum. Alterner testtypen slik at ulike forutsetninger blir undersøkt.
Fjerner skyhosting behovet for en katastrofegjenopprettingsplan?
Nei. Skyplattformer gir byggesteinene for robust arkitektur, men tilgjengelighetssoner og administrerte tjenester er konfigurasjonsvalg snarere enn standardinnstillinger, og regionale avbrudd forekommer. Skyen gjør heller ingenting med slettede eller krypterte data, feilkonfigurasjon eller en kompromittert konto. Planen endrer form i skyen og handler mer om konfigurasjon, uforanderlige sikkerhetskopier og kontogjenoppretting enn om maskinvare, men den forsvinner ikke.
Er ransomware et scenario for katastrofegjenoppretting?
Det er det og mer. Løsepengevirus er en sikkerhetshendelse, ofte et brudd på personopplysninger og en gjenopprettingshendelse samtidig, og det ugyldiggjør antagelser som vanlig gjenopprettingsplanlegging gjør. Sikkerhetskopier kan krypteres eller slettes, så uforanderlighet og frakoblede kopier er viktige, og miljøet må kanskje gjenoppbygges i stedet for å gjenopprettes på plass fordi gjenoppretting til en kompromittert eiendom bare infiserer den på nytt.
