Når et nøkkelsystem i virksomheten din går ned, er de vanskeligste delene å vite hva du skal gjenopprette først, hvem som har tilgang til å gjøre det, hvilken sikkerhetskopi som er klarert, og hvor lenge virksomheten din kan fortsette å fungere uten det systemet.
Det er her mange små og mellomstore bedrifter (SMB-er) oppdager gapet mellom det å ha sikkerhetskopier og det å ha et faktisk gjenopprettingsabonnement. En sikkerhetskopi kan inneholde dataene du trenger, men den bestemmer ikke gjenopprettingsrekkefølgen, fordeler ikke ansvar, validerer ikke om gjenopprettingen fungerer, eller løser ikke problemet med manglende administrator-påloggingsinformasjon under et avbrudd.
Et IT-katastrofegjenopprettingsabonnement gir denne prosessen struktur før et avbrudd inntreffer. Det definerer hvilke systemer som betyr mest, hvor raskt de må bli gjenopprettet, hvor mye datatap virksomheten kan tolerere, hvilke strategier for forebygging av datatap som skal implementeres, hvem som eier hvert gjenopprettingstrinn, og hvordan kritisk påloggingsinformasjon beskyttes. Denne klarheten kan forhindre at en IT-hendelse blir til langvarig nedetid, tapte inntekter eller en bredere operasjonell krise.
Hva er et IT-katastrofegjenopprettingsabonnement?
Virksomhetskontinuitet kontra IT-katastrofegjenoppretting
Hva IT-gjenopprettingsabonnementet ditt ved katastrofe må dekke
Hva IT-gjenopprettingsabonnementet ditt ved katastrofe må definere
Gjenoppretting av påloggingsinformasjon: det oversedde scenarioet for katastrofegjenoppretting
Mal for gjenopprettingsabonnement ved katastrofe
Slik tester du IT-gjenopprettingsabonnementet ditt ved katastrofe
Bygg gjenoppretting rundt systemer, data og tilgang
Hva er et IT-katastrofegjenopprettingsabonnement?
Et IT-gjenopprettingsabonnement ved katastrofe er en dokumentert prosess for å gjenopprette teknologisystemer etter et avbrudd. Det fokuserer på IT-laget i virksomheten: data, applikasjoner, enheter, infrastruktur, skytjenester, administratortilgang, sikkerhetskopier og personene som er ansvarlige for gjenoppretting.
Et praktisk IT-gjenopprettingsabonnement bør svare på spørsmål som:
- Hvilke systemer må komme tilbake først?
- Hvor mye nedetid kan virksomheten tolerere?
- Hvor mye datatap er akseptabelt?
- Hvor er sikkerhetskopiene lagret?
- Hvem kan gjenopprette systemer?
- Hvilken administrator-påloggingsinformasjon trengs?
- Hvordan vil teamet bekrefte at gjenopprettede systemer er sikre og brukbare?
- Hvordan vil virksomheten kommunisere med ansatte og kunder hvis primære kanaler er nede?
Et gjenopprettingsabonnement ved katastrofe bør gå lenger enn å bare håndtere cyberangrep: det må dekke hverdagslige problemer som maskinvarefeil, tapt påloggingsinformasjon og utilsiktet sletting. Det må også dekke eksterne tjenesteavbrudd som avbrudd i skyplattformer eller SaaS-verktøy, feilkonfigurasjoner og at nøkkelmedarbeidere slutter uten å overføre kritisk tilgang.
Gjenoppretting er ikke noe som skal utformes under et avbrudd. Det må planlegges, eies, kommuniseres og testes før virksomheten din blir avhengig av det.
Virksomhetskontinuitet kontra IT-katastrofegjenoppretting
Virksomhetskontinuitet og IT-katastrofegjenoppretting blir ofte behandlet som det samme, men de løser ulike problemer.
Virksomhetskontinuitet handler om å holde virksomheten i drift under et avbrudd. Det dekker klientkommunikasjon, midlertidige arbeidsflyter, ansattes ansvar, leverandørkoordinering og beslutninger om hvilke tjenester som må fortsette selv om normale systemer er utilgjengelige.
IT-katastrofegjenoppretting fokuserer på teknologien bak dette arbeidet. Det definerer hvordan systemer, data, applikasjoner, sikkerhetskopier og administratortilgang skal gjenopprettes slik at virksomheten kan gå tilbake til normal drift på en sikker måte.
Som et eksempel, tenk på et CRM-avbrudd. Et abonnement for virksomhetskontinuitet kan forklare hvordan salgs- eller støtteteam fortsetter å betjene kunder mens CRM-systemet er nede. IT-gjenopprettingsabonnementet forklarer hvem som kontakter leverandøren, hvilke data som må gjenopprettes, hvilken sikkerhetskopi eller eksport som er tilgjengelig, hvilken påloggingsinformasjon som kreves, og hvordan teamet bekrefter at systemet er trygt å bruke igjen.
For mange SMB-er dukker gapet opp først under en hendelse. Folk vet hvem som vil kontakte klienter, men ikke hvem som kan gjenopprette faktureringssystemet. De vet at sikkerhetskopier eksisterer, men ikke om en gjenoppretting noen gang har blitt testet. De vet at én ansatt vanligvis håndterer IT, men ikke hva som skjer hvis denne personen er utilgjengelig eller hvor administratorpassordene er lagret hvis personen ikke er tilgjengelig.
Hva IT-gjenopprettingsabonnementet ditt ved katastrofe må dekke
Et sterkt IT-katastrofegjenopprettingsabonnement behøver ikke å være overdrevent langt, men det må være spesifikt nok til å kunne kjøres i en stressende situasjon.
Mål for gjenopprettingstid
Recovery time objective, eller RTO, definerer hvor raskt et system må gjenopprettes. Et betalingssystem må kanskje være tilbake innen få timer, mens et internt rapporteringskontrollpanel kan tolerere et lengre avbrudd.
Sett RTO-er etter virksomhetens konsekvenser, ikke etter tekniske preferanser, fordi kostnaden for nedetid er både et forretningsmessig og et teknisk problem. Spør hvilke systemer som påvirker inntekter, kundeforpliktelser, juridiske forpliktelser, sikkerhet og ansattes produktivitet.
Mål for gjenopprettingspunkt
Recovery point objective, eller RPO, definerer hvor mye datatap som er akseptabelt, noe som deretter bidrar til å sette de rette strategiene for forebygging av datatap (DLP). Hvis et system har en RPO på én time, må sikkerhetskopier eller replikering støtte gjenoppretting til omtrent det tidspunktet.
Hvis RPO-en er én dag, aksepterer virksomheten et større gap. RPO bidrar også til å bestemme frekvensen på sikkerhetskopier, for jo kortere RPO-en er, desto hyppigere må sikkerhetskopiene dine være. Kritiske systemer trenger derfor hyppigere sikkerhetskopier enn lavprioriterte systemer.
Prioritetsnivåer for systemer
Ikke alle systemer bør gjenopprettes samtidig. Et gjenopprettingsabonnement ved katastrofe for små bedrifter bør dele inn systemene i prioritetsnivåer.
- Nivå 1: Systemer som kreves for kjernevirksomhet, sikkerhet, kommunikasjon eller inntekter.
- Nivå 2: Viktige systemer som kan tolerere kort nedetid.
- Nivå 3: Lavprioriterte systemer som kan gjenopprettes etter at virksomheten er stabil.
Typiske nivå 1-systemer kan inkludere e-post, identitetstilbyder, passordapp, finanssystemer, kundedatabase, skylagring og kommunikasjonsplattformer.
Sikkerhetskopistrategi
Sikkerhetskopistrategien din bør definere:
- Hva som sikkerhetskopieres og hvor ofte
- Hvor sikkerhetskopiene er lagret
- Hvem som har tilgang til dem
- Hvordan gjenoppretting testes
NCSC har også publisert(nytt vindu) prinsipper for løsepengevirus-resistente sikkerhetskopier for sky- og lokale sikkerhetskopiløsninger, og bemerker at sikkerhetskopierte data ikke er resistente mot løsepengevirus som standard og bør vurderes mot trusselen om løsepengevirus.
En sterk sikkerhetskopistrategi inkluderer vanligvis frakoblede eller uforanderlige sikkerhetskopier for kritiske data, regelmessig testing, dokumenterte gjenopprettingstrinn og separat påloggingsinformasjon for administrering av sikkerhetskopier.
Roller og ansvar
Et gjenopprettingsabonnement ved katastrofe bør navngi eiere, ikke bare oppgaver. Hvis én person sitter på all kunnskap om gjenoppretting, har virksomheten en personrisiko i tillegg til en IT-risiko. Definer hvem som:
- Leder gjenopprettingen
- Gjenoppretter systemer
- Kontakter leverandører
- Godkjenner nødtilgang
- Kommuniserer internt
- Dokumenterer beslutninger
Hva IT-gjenopprettingsabonnementet ditt ved katastrofe må definere
| Komponent | Hva det svarer på |
| RTO | Hvor raskt må hvert system gjenopprettes? |
| RPO | Hvor mye data har virksomheten råd til å tape? |
| Prioritetsnivåer | Hvilke systemer kommer tilbake først, og hvilke kan vente? |
| Sikkerhetskopistrategi | Hva som sikkerhetskopieres, hvor det er lagret, og om gjenoppretting har blitt testet? |
| Roller og ansvar | Hvem som leder gjenopprettingen, gjenoppretter systemer, kontakter leverandører og godkjenner nødendringer? |
Gjenoppretting av påloggingsinformasjon: det oversedde scenarioet for katastrofegjenoppretting
Katastrofegjenoppretting fokuserer oppmerksomheten ofte på data, tjenere og sikkerhetskopier. Men i praksis kan gjenopprettingen mislykkes fordi teamet ikke har tilgang til systemene som trengs for å gjenopprette driften.
Gjenoppretting av påloggingsinformasjon spør:
- Hvem som har tilgang til administratorkontoer?
- Hvor sikkerhetskopiert påloggingsinformasjon er lagret?
- Hvilke kontoer som kan gjenopprette kritiske systemer?
- Hva som skjer hvis et passord går tapt, blir kompromittert eller innehas av noen som er utilgjengelig?
- Om nød-påloggingsinformasjon er beskyttet og gjennomgås?
- Kan tilgang tilbakekalles og tildeles på nytt raskt?
Hvis sikkerhetskopiert påloggingsinformasjon er lagret i én ansatts nettleser, gjenopprettingskoder oppbevares i et privat notat, eller delte administratorpassord sirkulerer via chat, kan det hende at virksomheten ikke klarer å gjenopprette problemfritt under en hendelse.
En passordapp for bedrifter bidrar til å redusere denne risikoen ved å sentralisere kritisk påloggingsinformasjon i krypterte hvelv, tildele tilgang etter rolle, og gjøre det enklere å tilbakekalle eller tildele tilgang på nytt når noen slutter eller ansvarsområder endres. Proton Pass for Business hjelper team med å generere sterke passord, lagre påloggingsinformasjon sikkert, bruke sikker deling og holde sensitiv tilgang unna chat-er og regneark.
Som en passordapp for IT-team, støtter Proton Pass sentralisert administrasjon av påloggingsinformasjon, retningslinjer for passord, sikker deling, rapportering og logger, SCIM-klargjøring og SSO-integrasjoner. Det gjør gjenoppretting av påloggingsinformasjon mer håndterbart fordi tilgang til kritiske systemer ikke er avhengig av én person, én nettleserprofil eller ett udokumentert passord.
Mal for gjenopprettingsabonnement ved katastrofe
Et gjenopprettingsabonnement ved katastrofe fungerer best når det er spesifikt nok til å veilede handlinger under et avbrudd, men enkelt nok til at teamet kan bruke det under press. For SMB-er bør malen fokusere på det mest essensielle: hva som må gjenopprettes, hvor raskt, fra hvilken sikkerhetskopi, av hvem, og med hvilken påloggingsinformasjon.
1. Omfang
Definer hvilke systemer, tjenester, plasseringer, enheter og data abonnementet dekker.
Kopi av mal: Dette IT-gjenopprettingsabonnementet ved katastrofe dekker systemene, dataene, tjenestene, påloggingsinformasjonen og leverandørene som kreves for å gjenopprette [Bedriftsnavn] sine kritiske operasjoner etter et teknologiavbrudd.
2. Oversikt over kritiske systemer
List opp systemene virksomheten din er avhengig av, og tildel prioritetsnivåer.
Kopi av mal: Kritiske systemer vil bli gruppert i nivå 1, nivå 2 og nivå 3 basert på virksomhetens konsekvenser, mål for gjenopprettingstid, mål for gjenopprettingspunkt og avhengighet av andre systemer.
3. Gjenopprettingsmål
Definer RTO og RPO for hvert prioriterte system.
Kopi av mal: Hvert system må ha et dokumentert mål for gjenopprettingstid og mål for gjenopprettingspunkt. Disse målene bør gjennomgås minst årlig og etter store systemendringer.
4. Sikkerhetskopiering- og gjenopprettingsprosess
Dokumenter hvor sikkerhetskopier er lagret, hvor ofte de kjører, hvem som har tilgang til dem, og hvordan testing av gjenoppretting fungerer.
Kopi av mal: Sikkerhetskopier må beskyttes mot uautorisert tilgang, lagres separat fra primære systemer der det er hensiktsmessig, og testes regelmessig. Gjenopprettingsprosedyrer må dokumenteres for nivå 1-systemer.
5. Gjenoppretting av påloggingsinformasjon og tilgang
Definer hvor kritisk påloggingsinformasjon er lagret, og hvem som har tilgang til den under gjenoppretting.
Kopi av mal: Administrator-påloggingsinformasjon, sikkerhetskopiert påloggingsinformasjon, gjenopprettingskoder og leverandørtilgang som kreves for katastrofegjenoppretting, må lagres i et godkjent kryptert hvelv. Tilgang må begrenses til autoriserte roller og gjennomgås etter rolleendringer, avvikling og gjenopprettingsøvelser.
6. Roller og eskalering
Definer eiere av gjenoppretting, varamedlemmer og eskaleringsbaner.
Kopi av mal: Hver gjenopprettingsrolle må ha en primær eier og en sikkerhetskopieier. Abonnementet må identifisere hvem som leder gjenopprettingen, hvem som gjenoppretter systemer, hvem som kontakter leverandører, hvem som kommuniserer oppdateringer og hvem som godkjenner nødendringer.
7. Kommunikasjonsabonnement
Definer hvordan virksomheten kommuniserer internt og eksternt under et IT-avbrudd.
Kopi av mal: Under en gjenopprettingshendelse vil interne oppdateringer bli delt via [godkjent kanal]. Ekstern kommunikasjon til kunder, leverandører, assurandører eller tilsynsmyndigheter må godkjennes av [rolle/team].
8. Test- og vurderingsfrekvens
Definer hvor ofte abonnementet testes og oppdateres.
Kopi av mal: Dette gjenopprettingsabonnementet ved katastrofe vil testes minst [årlig/to ganger i året] og vurderes etter store hendelser, systemendringer, leverandørendringer eller mislykkede gjenopprettingsøvelser.
Slik tester du IT-gjenopprettingsabonnementet ditt ved katastrofe
Et gjenopprettingsabonnement ved katastrofe blir bare nyttig når det har blitt testet under forhold som ligner et reelt avbrudd. En sikkerhetskopi som eksisterer, men som aldri har blitt gjenopprettet, er fortsatt en antakelse. En gjenopprettingsrolle som bare én person forstår, er fortsatt en avhengighet. En administrator-påloggingsinformasjon som ingen finner under et avbrudd, er fortsatt en hindring.
Testing behøver ikke å være komplisert i starten. For de fleste SMB-er er målet å bevise at virksomheten kan gjenopprette de riktige systemene, med de riktige menneskene, ved å bruke den riktige påloggingsinformasjonen, innenfor en realistisk tidsramme.
1. Skrivebordsøvelse
Velg et sannsynlig scenario, for eksempel løsepengevirus som påvirker delte filer, et avbrudd i skylagring, utilsiktet sletting av kundedata eller plutselig tap av tilgang til en administratorkonto. Gå gjennom hva teamet ville gjort den første timen, hvem som ville ledet, hvilke leverandører som ville bli kontaktet, hvilke systemer som ville bli prioritert, og hvilken informasjon som ville mangle.
2. Test gjenoppretting
Velg en kritisk fil, database, innboks eller systemeksport, og bekreft at den kan gjenopprettes til en brukbar tilstand. Sjekk om de gjenopprettede dataene er ferske nok, om tillatelser fortsatt fungerer, og om teamet vet hvor sikkerhetskopien ligger.
3. Test regelmessig
Som et praktisk utgangspunkt bør SMB-er teste abonnementet minst én gang i året, i tråd med NIST-veiledningen i Special Publication 800-34 Revision 1(nytt vindu), og oftere etter store system- eller leverandørendringer.
4. Test gjenoppretting av påloggingsinformasjon
Bekreft at autoriserte personer har tilgang til sikkerhetskopierte administratorkontoer, sky-administratorkontoer, leverandørportaler, gjenopprettingskoder og nød-påloggingsinformasjon uten å være avhengig av én ansatts nettleser, private notater eller minne. Målet er ikke å eksponere sensitive passord unødvendig. Det er å bekrefte at tilgangsmodellen fortsatt fungerer når virksomheten er under press.
Etter hver test må du dokumentere hva som mislyktes, hva som tok for lang tid, og tildele en bestemt person og frist for hver utbedring. En god test er ikke en der alt går perfekt. Det er en som avslører gapene mens virksomheten fortsatt har tid til å utbedre dem.
Bygg gjenoppretting rundt systemer, data og tilgang
Et nyttig IT-gjenopprettingsabonnement ved katastrofe gir virksomheten en gjenopprettingsrekkefølge, et sett med eiere, et realistisk syn på akseptabel nedetid, og en måte å opprettholde virksomhetskontinuitet og gjenvinne tilgang til systemene som holder arbeidet i gang.
For SMB-er kan dette utgjøre forskjellen mellom et kort avbrudd og en langvarig driftsstans. Hvis e-post, finansprogramvare, skylagring, kundesystemer eller administratorkontoer er utilgjengelige, må teamet vite hva som kommer først, hvem som kan handle, og hvilken påloggingsinformasjon som kreves for å gjenopprette tilgangen på en sikker måte.
Det er derfor gjenopprettingsplanlegging bør dekke systemer, data og tilgang sammen. Sikkerhetskopier kan gjenopprette filer, men påloggingsinformasjon er det som lar teamet gjenvinne kontrollen over systemene som trengs for å gjenopprette. Administratorpålogginger, leverandørportaler, sikkerhetskopierte kontoer, gjenopprettingskoder og delt operasjonell påloggingsinformasjon må alle beskyttes, organiseres og være tilgjengelige for de rette personene når noe går galt.
En passordapp for bedrifter bidrar til å styrke den delen av abonnementet. Med kritisk påloggingsinformasjon lagret i krypterte passordhvelv og bare delt med autoriserte personer, er virksomheten mindre avhengig av én ansatts nettleser, private notater eller minne under en gjenopprettingshendelse.
