En gjenopprettingsplan beskriver hvordan virksomheten får en tjeneste tilbake i bruk etter et alvorlig avbrudd. Den må koble sikkerhetskopier, tekniske avhengigheter, ansvar og kontroll av dataene som kommer tilbake. Det praktiske resultatet er en prioritert kjøreplan som et tilgjengelig team kan følge også når den vanlige dokumentportalen eller identitetsløsningen er utilgjengelig.
Personvernforordningen artikkel 32 omfatter blant annet evnen til å gjenopprette tilgjengelighet og tilgang til personopplysninger i rett tid etter en fysisk eller teknisk hendelse, samt vurdering av sikkerhetstiltakenes effektivitet. NSMs grunnprinsipper for IKT-sikkerhet gir praktiske råd om sikkerhetskopiering og kontrollert gjenoppretting. Ingen av disse henvisningene fastsetter én felles gjenopprettingstid for alle virksomheter.
Skill tjenestens behov fra teknikkens muligheter
Den overordnede kontinuitetsplanen beskriver hvordan virksomheten opprettholder viktige leveranser under et avbrudd, eventuelt med manuelle arbeidsmåter. Gjenopprettingsplanen beskriver den tekniske tilbakeføringen. Begge trenger samme forståelse av hvilke tjenester som er viktigst og hvilke konsekvenser forsinkelse har.
Tjenesteeieren bør først beskrive hva avbruddet betyr for personer, drift og forpliktelser. En bestillingsportal og et historisk rapportarkiv har ikke nødvendigvis samme tidsbehov. Samtidig kan arkivet inneholde opplysninger som er nødvendige for å behandle en hastesak. Klassifiseringen må derfor bygge på faktiske arbeidsoppgaver, ikke bare systemets navn.
Teknologiteamet vurderer deretter hva dagens løsning kan levere. Hvis tjenesten trenger gjenoppretting på fire timer, mens en realistisk tilbakeføring tar to døgn, er dette et gap som må løses eller håndteres. Det hjelper ikke å skrive fire timer i planen uten å endre kapasitet, avhengigheter eller arbeidsmåte.
Fastsett RTO og RPO med tydelige målepunkter
RTO, Recovery Time Objective, uttrykker målet for hvor lenge tjenesten kan være avbrutt før den skal være tilbake på et avtalt nivå. RPO, Recovery Point Objective, uttrykker hvor langt tilbake i tid virksomheten kan tåle å miste oppdateringer. RTO handler om tid til tilgjengelig tjeneste; RPO handler om tidspunktet data kan gjenopprettes til.
Avtal når klokken starter og hva som regnes som gjenopprettet. «Serveren starter» er et svakt sluttpunkt hvis brukerne fortsatt ikke kan logge inn eller ordrene mangler. Et bedre kriterium kan være at autoriserte brukere kan registrere og hente nødvendige saker, integrasjoner fungerer, og definerte datakontroller er bestått.
Et hypotetisk kundesenter kan beslutte følgende mål:
| Tjeneste | RTO | RPO | Godkjenningskriterium |
|---|---|---|---|
| Saksregistrering | 8 timer | 1 time | Innlogging, opprettelse og uthenting av representative saker fungerer |
| Dokumentarkiv for aktive saker | 12 timer | 4 timer | Nødvendige vedlegg åpnes med riktige tilganger |
| Historisk ledelsesrapportering | 3 arbeidsdager | 1 døgn | Rapportgrunnlaget kan avstemmes mot kildene |
Tallene er egne eksempelvalg, ikke anbefalte bransjestandarder eller lovbestemte frister. Virksomheten må begrunne sine mål og kontrollere om de kan oppnås. Et løfte fra en leverandør om plattformtilgjengelighet er heller ikke nødvendigvis et løfte om å gjenopprette deres slettede data innen samme tidsrom.
Kartlegg avhengighetene som må være på plass først
En applikasjon kan være avhengig av identitetstjeneste, nettverk, navnetjeneste, sertifikater, hemmeligheter, database og lagring. Sikkerhetskopien av databasen er lite nyttig hvis ingen kan hente nøkkelen som dekrypterer den. En administratorkonto kan også være ubrukelig dersom flerfaktorfunksjonen krever en utilgjengelig tjeneste.
Bruk kartleggingen av IT-systemer som grunnlag for rekkefølgen. Tegn de få avhengighetene som faktisk bestemmer oppstarten, og angi hvilken rolle som har ansvar for hver del. Identifiser sirkler: gjenopprettingsdokumentet ligger i systemet som trenger dokumentet for å kunne startes.
Oppbevar en beskyttet og tilgjengelig kopi av nødvendig dokumentasjon og beredskapsinformasjon utenfor den vanlige feilsonen. Dette betyr ikke at alle passord skal ligge ukryptert i en perm. Nødtilgang må utformes med sikkerhet, autorisasjon og sporbar bruk, og kontrolleres før en hendelse gjør den nødvendig.
Vurder sikkerhetskopien som en del av angrepsflaten
Bestem hva som skal kopieres, hvor ofte, hvor lenge kopiene beholdes, og hvem som kan endre eller slette dem. Vurder separasjon fra produksjonsmiljøet, beskyttelse mot uønsket endring og konsekvensene dersom en administratorkonto kompromitteres. En sikkerhetskopi som kan slettes med samme tilgang som produksjonsdata, kan rammes av den samme hendelsen.
Replikering og versjonshistorikk kan bidra til tilgjengelighet, men må vurderes mot scenarioet. Feil eller sletting kan bli replikert raskt. Kontroller hvilke historiske tidspunkter som faktisk kan velges, hvor lenge de finnes, og om gjenoppretting gjelder hele tjenesten eller bare bestemte objekter.
Dokumenter beskyttelsen av krypteringsnøkler og avhengighetene til leverandører. Krypteringsrutinen bør beskrive hvordan autorisert gjenoppretting er mulig uten at nøklene mister sin beskyttelse. En utilgjengelig nøkkel kan gjøre en ellers intakt sikkerhetskopi ubrukelig.
Skriv en kjøreplan med beslutningspunkter
Planen bør starte med hvem som kan aktivere den og hvilken hendelse den gjelder. Ved en ordinær feil kan tilbakeføring til et kjent fungerende tidspunkt være riktig. Ved et innbrudd må teamet også undersøke om miljøet eller sikkerhetskopien er kompromittert. Rask tilbakeføring uten kontroll kan gjeninnføre angriperens tilgang.
En praktisk kjøreplan kan angi: etabler hendelsesledelse og sikkert kommunikasjonsrom, avgrens det berørte miljøet, velg gjenopprettingspunkt, klargjør et kontrollert miljø, gjenopprett grunnleggende avhengigheter, hent data og applikasjon, utfør sikkerhets- og datakontroller, og be tjenesteeier godkjenne begrenset åpning. Hvert trinn trenger ansvarlig rolle og kriteriet for å gå videre.
Hold tekniske kommandoer og versjonsspesifikke detaljer i vedlikeholdte driftsinstrukser. Hovedplanen skal vise rekkefølge og beslutninger. Registrer hvor instruksene finnes, hvilken versjon som er kontrollert, og hva teamet gjør hvis den vanlige leverandørkontakten ikke svarer.
Kontroller data og rettigheter før full åpning
Tilbakeførte data kan mangle nylige rettinger, slettinger eller tilgangsendringer. Teamet må vite hvilke endringer som skjedde etter gjenopprettingspunktet, og hvordan disse skal håndteres. En gammel sikkerhetskopi kan ellers gjeninnføre en konto som skulle være stengt eller opplysninger som var fjernet fra ordinær behandling.
Bruk avstemming mot avgrensede logger eller andre autoritative kilder der det er nødvendig og mulig. Avklar rekkefølgen for å gjenanvende endringer. Gjentatt import kan skape duplikater, mens ukritisk sletting kan fjerne legitime nyere opplysninger. Koble arbeidet til rutinen for riktige personopplysninger.
Kontroller også gruppe- og mappeadgang med representative roller. Tjenesten kan være teknisk tilgjengelig selv om alle brukere feilaktig har fått administratortilgang. Inkluder minst én forventet tillatt og én forventet avvist tilgang i kontrollen, uten å spre reelle personopplysninger til uvedkommende under øvelsen.
Øv på den faktiske flaskehalsen
Velg øvelser ut fra risiko, endringer og usikkerhet. En dokumentgjennomgang kan avdekke uklart ansvar. En avgrenset gjenopprettingsøvelse kan vise at sikkerhetskopien er lesbar. En bredere øvelse kan avdekke samspill mellom identitet, applikasjon og leverandør. Disse gir ulik dokumentasjon og bør ikke omtales som det samme.
Mål tid til hvert viktig trinn, valgt datapunkt og hva som hindret fremdriften. Hvis øvelsen bare omfattet én liten database, skal resultatet ikke brukes som bevis for at hele produksjonsmiljøet kan gjenopprettes innen samme tid. Noter hvilke forutsetninger som var forenklet, og hvilke deler som gjenstår.
Avtal tilbakegangen fra midlertidig drift
Hvis kundesenteret har registrert saker manuelt under avbruddet, må planen angi hvordan disse føres inn etterpå. Utpek en ansvarlig for avstemming, bruk en tydelig markering av hvilke saker som allerede er overført, og bestem når de midlertidige listene skal slettes eller arkiveres etter gjeldende behov. Kontroller at samme henvendelse ikke behandles to ganger med motstridende svar.
Åpning kan skje trinnvis. Tjenesteeieren kan først tillate lesing av aktive saker, deretter ny registrering, og til slutt integrasjoner som sender opplysninger videre. Hvert nivå trenger et klart kriterium og informasjon til brukerne. En slik plan gjør det lettere å oppdage feil før de forplanter seg til andre systemer, uten å skjule at tjenesten fortsatt har begrensninger.
Vedlikehold planen når tjenesten endres
En ny identitetsleverandør, større datamengde eller endret lagringsløsning kan gjøre den gamle tidsberegningen utdatert. Legg gjenoppretting inn i endringsprosessen, og vurder nye avhengigheter før tjenesten tas i bruk. Ansvarlig for planen bør få beskjed ved endringer som påvirker kopiering, tilgang eller tilbakeføring.
Sluttdokumentasjonen bør vise vedtatte mål, kontrollert kapasitet, kjøreplanens versjon, øvelsens omfang og åpne forbedringer med eiere. Bruk tiltaksmatrisen for artikkel 32 til å følge opp gapene. Da kan ledelsen se forskjellen mellom ønsket gjenoppretting og den evnen virksomheten faktisk har dokumentert.