Katastrofipalautus (venäläisissä lähteissä käytetään myös ei aivan oikeaa termiä katastrofipalautus ) sisältää joukon käytäntöjä, työkaluja ja menettelyjä, joiden avulla voit palauttaa tai jatkaa elintärkeän teknologisen infrastruktuurin ja järjestelmien toimintaa luonnonkatastrofin tai ihmisen aiheuttaman katastrofin jälkeen. katastrofi [1] . Katastrofipalautus keskittyy tietotekniikkaan (IT) tai kriittisiä liiketoiminnan toimintoja tukeviin teknologiajärjestelmiin, toisin kuin liiketoiminnan jatkuvuuteen, joka edellyttää liiketoiminnan kaikkien olennaisten osien ylläpitämistä suurista häiriöistä huolimatta; siksi sitä voidaan pitää liiketoiminnan jatkuvuustehtävien osana [2][3] . Hätäpalautus olettaa, että pääosaa alun perin toimivasta tietojärjestelmästä ei voida palauttaa vähään aikaan, ja se on tietojen ja palveluiden palauttaminen toissijaisiin säilyneisiin paikkoihin, päinvastoin kuin tietojärjestelmien palauttaminen alkuperäisille paikoilleen.
IT-palvelun jatkuvuuden suunnittelu (ITSC) [4] [5] on liiketoiminnan jatkuvuuden suunnittelun (BCP) [6] osajoukko, joka keskittyy palautuspistetavoitteeseen (RPO) ja Recovery Time Objectiveen (R.T.O.). Tämä prosessi sisältää kahden tyyppisen suunnittelun; IT:n katastrofipalautussuunnittelu ja laajempi IT-kestävyyssuunnittelu. Lisäksi se sisältää myös IT-infrastruktuurin hallintaelementtejä ja viestintään liittyviä palveluita, kuten puhelin- (ääni) ja data.
Suunnitteluun kuuluu valmiuspaikkojen perustaminen, olivat ne sitten kuumia, lämpimiä tai kylmiä, sekä valmiuspaikkojen tukeminen liiketoiminnan jatkuvuuden varmistamiseksi tarvittavilla laitteilla.
Vuonna 2008 British Standards Institution julkaisi BS 25999 liiketoiminnan jatkuvuusstandardiin liittyvän ja sitä tukevan standardin nimeltä BS25777, joka on erityisesti sovitettu IT-järjestelmän jatkuvuudesta liiketoiminnan jatkuvuuteen . Tämä standardi peruutettiin sen jälkeen, kun ISO/IEC 27031 -tietoturvakäytännöt julkaistiin maaliskuussa 2011. Ohjeistus tieto- ja viestintätekniikan valmiuden varmistamiseen liiketoiminnan jatkuvuuden kannalta” [7] .
ITIL määrittelee myös osan näistä termeistä [8] .
Recovery Time Objectives (RTO) Tämä termi käännetään myös "palautumisaikatavoitteeksi" [9] [10] on tavoitekesto ja palvelutaso , jonka sisällä liiketoimintaprosessi on palautettava katastrofin (tai epäonnistumisen) jälkeen, jotta vältetään siihen liittyvät ei-hyväksyttävät seuraukset. liiketoiminnan keskeytyksen kanssa [11] .
Liiketoiminnan jatkuvuuden suunnittelun metodologian mukaisesti prosessin omistaja(t) asettavat RTO:n Business Impact Analysis (BIA) -analyysin aikana, ja se sisältää aikataulun määrittelyn vaihtoehtoisille tai manuaalisille palautuskierroksille.
Aihetta käsittelevässä kirjallisuudessa RTO:ta kutsutaan Recovery Point Objective (RPO) -tavoitetta täydentäväksi. Sen sijaan ne kuvaavat hyväksyttävän tai "hyväksyttävän" ITSC-suorituskyvyn rajoja. RTO ja RPO mittaavat ITSC:n suorituskykyä liiketoimintaprosessien normaalin toiminnan vuoksi menetettynä aikana ja vastaavasti menetettyinä tai varmuuskopioimattomina tiedoilla (RPO) [11] [12] .
Eräässä Forbesin katsauksessa todetaan [9] , että Recovery Time Actual (RTA) on itse asiassa kriittinen mittari toiminnan jatkuvuuden ja katastrofien palautumisen kannalta.
Liiketoiminnan jatkuvuustiimi tekee harjoituksia varsinaisten toimenpiteiden ajoituksella, joiden aikana RTA määritetään ja tarvittaessa mukautetaan [9] .
Palautuspistetavoite ( Recovery Point Objective , RPO ) on enimmäistavoitejakso, jonka aikana tapahtumatietoja katoaa IT-palvelusta suuren tapahtuman vuoksi [11] .
Esimerkiksi jos RPO mitataan minuuteissa (tai jopa useissa tunneissa), niin käytännössä peilattuja varmuuskopioita on ylläpidettävä jatkuvasti, koska päivittäiset nauhavarmuuskopiot eivät riitä [13] .
Suhde palautumisajan tavoitteeseenPalautus, joka ei tapahdu hetkessä, mahdollistaa tapahtumatietojen palauttamisen ajan mittaan ja ilman merkittävää riskiä tai menetystä.
RPO mittaa enimmäisajan, jonka uusimmat tiedot voidaan peruuttamattomasti menettää suuren vaaratilanteen sattuessa, eikä se ole suora mitta tällaisen menetyksen määrästä. Jos BC esimerkiksi aikoo palauttaa tiedot uusimpaan saatavilla olevaan varmuuskopioon, RPO on enimmäisaikaväli tällaisten varmuuskopioiden välillä, jotka on poistettu turvallisesti tallennustilasta.
Usein ymmärretään väärin, että RPO määräytyy olemassa olevan varajärjestelmän mukaan, vaikka todellisuudessa liiketoimintavaikutusanalyysi määrittää kunkin palvelun RPO:n. Kun tarvitaan etätietoja, aika, jonka aikana tietoja voidaan menettää, alkaa usein siitä hetkestä, kun varmuuskopiot on valmistettu, eikä siitä hetkestä, kun ne siirretään pois sivustosta [12] .
Tietojen synkronointipiste (se on myös varmuuskopiopiste ) [14] on ajankohta, jolloin fyysiset tiedot varmuuskopioidaan. Yksinkertaisimmassa toteutuksessa tämä on piste, jossa tietojen päivitysjonon käsittely järjestelmässä pysähtyy, kun levyltä levylle -kopiointi on käynnissä. Nykyaikaisissa järjestelmissä tietojenkäsittely jatkuu tyypillisesti rinnakkain varmuuskopioinnin kanssa, joka tehdään tilannekuvien avulla . Varmuuskopio [15] heijastaa tietojen aiempaa versiota, ei tilaa, joka tapahtui, kun tiedot kopioitiin varmuuskopiotietovälineelle tai siirrettiin varmuuskopiointipaikkaan.
RTO ja RPO on tasapainotettava liiketoimintariskien sekä kaikkien muiden tärkeiden järjestelmän suunnittelukriteerien kanssa.
RPO on sidottu aikaan, jolloin varmuuskopiot ladataan sivuston ulkopuolelle. Tietojen synkroninen kopioiminen ulkoiseen peiliin ratkaisee useimmat pääsivuston saatavuuteen liittyvät odottamattomat ongelmat. Nauhojen (tai muiden kannettavien tietovälineiden) fyysinen siirtäminen muualla tarjoaa osan varmuuskopiointitarpeista suhteellisen alhaisin kustannuksin. Tällaisista kopioista voidaan palauttaa ennalta valitussa paikassa [16] .
Suuria määriä arvokasta tapahtumatietoa varten laitteisto voidaan jakaa kahteen tai useampaan paikkaan erottamalla ne maantieteellisen alueen mukaan, mikä parantaa joustavuutta.
Yksityiskohtaisempaa elvytyssuunnittelua varten indikaattorit, kuten DOO - Degraded Operations Objective - järjestelmän toimintojen suorittamisen hyväksyttävä hidastuminen, joka tapahtuu siirrettäessä tietojenkäsittelyä varmuuskopiosivustolle ja NRO - Network Recovery Objective - verkon vähimmäiskaistanleveys jotka on palautettava, voidaan myös käyttää varmistamaan palautetun järjestelmän hyväksyttävä vähimmäissuorituskyky [17] .
Katastrofitorjunnan ja tietotekniikan (IT) suunnittelu alkoi kehittyä 1970-luvun puolivälissä ja loppupuolella, kun tietokonekeskusten johtajat alkoivat ymmärtää organisaatioidensa riippuvuutta tietokonejärjestelmistä.
Tuohon aikaan useimmat järjestelmät olivat eräsuuntautuneita keskustietokoneita . Toinen etätietokone voi käynnistyä varmuuskopionauhoilta odottaessaan pääsivuston palautumista. seisokit olivat suhteellisen vähäisempiä.
Katastrofipalautusteollisuudesta tuli varmuuskopiointikeskusten tarjoaja. Yksi ensimmäisistä tällaisista keskuksista sijaitsi Sri Lankassa (Sungard Availability Services, 1978) [18] [19] kehitettiin tarjoamaan varatietokonekeskuksia. Yksi varhaisimmista tällaisista keskuksista sijaitsi Sri Lankassa (Sungard Availability Services, 1978). [20] [21] .
1980- ja 90-luvuilla, kun yrityksen sisäinen ajanjako, online-tietojen syöttäminen ja reaaliaikainen käsittely kasvoivat, vaadittiin IT-järjestelmien parempaa saatavuutta.
IT-palvelun jatkuvuus on tärkeä monille organisaatioille, kun ne ottavat käyttöön liiketoiminnan jatkuvuuden hallinnan (BCM) ja tietoturvan hallinnan (ICM) sekä osana tietoturvan ja liiketoiminnan jatkuvuuden hallinnan käyttöönottoa ja hallintaa ISO/IEC 27001 :n ja ISO 22301 :n mukaisesti.
Pilvipalveluiden nousu vuodesta 2010 lähtien jatkaa tätä kehitystä: nyt on entistä vähemmän tärkeätä, missä laskentapalvelut fyysisesti isännöidään, kunhan verkko itsessään on riittävän luotettava (erillinen asia, eikä siitä ole suurta huolta, koska nykyaikaiset verkot ovat erittäin joustavia ). suunnittelultaan). Recovery as a Service (RaaS) on yksi Cloud Security Alliancen [22] tukemista pilvipalveluiden tietoturvaominaisuuksista tai eduista .
Katastrofit voidaan luokitella kolmeen laajaan uhkien ja vaarojen kategoriaan. Ensimmäiseen luokkaan kuuluvat luonnonkatastrofit, kuten tulvat, hurrikaanit, tornadot, maanjäristykset ja epidemiat.
Toinen luokka on teknologiset vaarat, joihin kuuluvat järjestelmien ja rakenteiden onnettomuudet tai viat, kuten putkistojen räjähdykset, kuljetusonnettomuudet, kunnallispalveluhäiriöt, patovauriot ja vaarallisten aineiden vahingossa tapahtuvat päästöt.
Kolmas luokka on ihmisen aiheuttamat uhat, joihin kuuluvat tahalliset teot, kuten aktiiviset haitalliset hyökkäykset, kemialliset tai biologiset hyökkäykset, tietoihin tai infrastruktuuriin kohdistuvat kyberhyökkäykset ja sabotaasi. Kaikkien luonnonkatastrofien luokkien ja tyyppien varautumistoimenpiteet kuuluvat viiteen tehtäväalueeseen: ennaltaehkäisy, suojelu, lieventäminen, reagointi ja toipuminen [23] .
Viimeaikaiset tutkimukset tukevat ajatusta, että kokonaisvaltaisempi lähestymistapa katastrofia edeltävään suunnitteluun on pitkällä aikavälillä kustannustehokkaampaa. Jokainen vaarojen lieventämiseen (kuten katastrofin toipumissuunnitelmaan) käytetty dollari säästää yhteisöltä 4 dollaria vastaus- ja palautuskustannuksissa [24] .
Katastrofipalautustilastot vuodelta 2015 osoittavat, että yksi tunti seisokit voivat maksaa
IT-järjestelmien muuttuessa yhä kriittisemmiksi yrityksen ja mahdollisesti koko talouden moitteettoman toiminnan kannalta, on entistä tärkeämpää pitää nämä järjestelmät käynnissä nopeasti ja palauttaa ne nopeasti. Esimerkiksi 43 % yrityksistä, jotka kokevat suuren liiketoimintadatan menettämisen, eivät koskaan avaudu uudelleen, ja 29 % sulkeutuu kahden vuoden sisällä. Tästä syystä järjestelmien jatkamiseen tai palauttamiseen valmistautuminen on otettava erittäin vakavasti. Tämä vaatii huomattavia ajan- ja rahainvestointeja, jotta varmistetaan mahdollisimman pienet tappiot tuhoisan tapahtuman sattuessa [26] .
Valvontatoimenpiteet ovat toimia tai mekanismeja, joilla voidaan vähentää tai poistaa erilaisia organisaatioille kohdistuvia uhkia. Disaster Recovery Plan (DRP) -suunnitelmaan voidaan sisällyttää erilaisia toimenpiteitä.
Hätäpalautussuunnittelu on osa laajempaa prosessia, joka tunnetaan nimellä liiketoiminnan jatkuvuuden suunnittelu, ja se sisältää suunnittelun sovellusten, tietojen, laitteiden, sähköisen viestinnän (kuten verkkojen) ja muun IT-infrastruktuurin uudelleen käynnistämiseksi. Liiketoiminnan jatkuvuussuunnitelma (BCP) sisältää suunnittelun muista kuin tietotekniikkaan liittyvistä seikoista, kuten avainhenkilöstöstä, tiloista, kriisiviestinnästä ja maineen suojauksesta, ja sen tulee viitata katastrofipalautussuunnitelmaan (DRP) IT-infrastruktuurin palauttamiseksi/jatkuvuuden osalta.
IT-katastrofipalautuksen hallintatoimenpiteet voidaan jakaa kolmeen tyyppiin:
Hyvä DR-suunnitelma edellyttää, että nämä kolme valvontatyyppiä dokumentoidaan ja niitä sovelletaan säännöllisesti niin kutsuttujen "katastrofipalautustestien" avulla.
Ennen katastrofipalautusstrategian valitsemista katastrofipalautussuunnittelija tutustuu ensin organisaationsa liiketoiminnan jatkuvuussuunnitelmaan, jossa on määriteltävä keskeiset mittarit palautuspisteen tavoitteelle ja palautumisajan tavoitteille [28] Liiketoimintaprosessien mittarit kartoitetaan sitten heidän järjestelmiinsä ja infrastruktuuriinsa [29] ] .
Asianmukaisen suunnittelun puute voi lisätä luonnonkatastrofin vaikutuksia [30] . Mittareiden vertailun jälkeen organisaatio tarkistaa IT-budjetin; RTO:iden ja RPO:iden on vastattava käytettävissä olevaa budjettia. Kustannus-hyötyanalyysi määrittää usein, mitä katastrofin toipumistoimenpiteitä tulisi soveltaa.
New York Times kirjoittaa, että pilvivarmuuskopioinnin lisääminen paikallisen ja ulkopuolisen nauha-arkistoinnin etuihin "lisää tietoturvakerroksen" [31] .
Yleisesti käytettyjä tietosuojastrategioita ovat:
Monissa tapauksissa organisaatio voi halutessaan käyttää ulkoistettua katastrofipalautuspalvelun tarjoajaa varmuuskopiointisivuston ja -järjestelmien tarjoamiseen omien etäsivustojensa sijaan yhä useammin pilvipalvelun kautta.
Järjestelmien ennallistamistarpeeseen varautumisen lisäksi organisaatiot toteuttavat myös varotoimia katastrofien ehkäisemiseksi. Näitä voivat olla:
Eräs laajalti käytetty elvytyssuunnitelmaluokitus on SHARE Technical Steering Committeen 1980-luvun lopulla kehittämä seitsemän tasoinen luokittelu, joka kehitettiin yhdessä IBM:n kanssa. He kehittivät valkoisen kirjan, jossa kuvataan katastrofipalautuspalvelujen tasot tasoilla 0–6. Sen jälkeen on syntynyt useita luokituksia kilpailemaan tämän kanssa ja heijastamaan teknologian ja koko alan kehitystä. Eri luokitukset keskittyvät restaurointiprosessin eri näkökohtiin tai teknisiin ominaisuuksiin. Näin ollen Wiboobratrin ja Kosavisuteen luokittelu keskittyy pääasiassa DRaaS- ratkaisuihin . Alla on vertaileva taulukko tällaisista luokitteluista [33] .
| Taso | JAA / IBM [34] [35] [36] | Hitachi [37] | Wiboonratr ja Kosavisutte [38] | Novell [39] | Xiotech [40] |
|---|---|---|---|---|---|
| 0 | Katastrofista palautussuunnitelmaa ei ole. | ||||
| yksi | Varmuuskopioinnit ovat käynnissä, varmuuskopiot siirretään erilliseen rakennukseen, mutta hot standby -sivustoa ei ole . Tätä varausmenetelmää kutsutaan pickup Truck Access Methodiksi (PTAM) [17] . | Varmuuskopiointi ulkopuoliselle nauhalle . | Ajankohtainen palautus on mahdollista. | Nauhavarmuuskopiointi/manuaalinen palautus. | Taso 4
Ajoitettu varmuuskopiointi "kylmään" varmuuskopiointisivustoon |
| 2 | Varmuuskopiointi on käynnissä, on kuuma varmuuskopiosivusto , jonne varmuuskopion tiedot voidaan palauttaa [17] . Menetelmä tunnetaan nimellä PTAM+hotsite. | Varmuuskopio tehdään nauhalle ensisijaisessa tai varmuuskopiointipaikassa. | Nauhalle tehdyt kopiot toimitetaan valmiiksi valmistettuun varmuuskopiointipaikkaan. | Perinteinen levykuvan tallennus/palautus. | |
| 3 | "Elektroninen varastointi" (elektroninen holvi). Verrattuna tasoon 2 lisätään mahdollisuus säännöllisesti kopioida (ja vastaavasti palauttaa) tietoja pääsivustolta. Tyypillinen toipumisaika on 24 tuntia [34] . | "Elektroninen tallennus" - samanlainen kuin SHARE/IBM-luokitus. | Täsmällisen palautuksen mahdollistavat levykopiot tehdään useisiin paikkoihin | Joustava (mukaan lukien tiedostokohtainen ja valittava tiedostoversio palautusta varten) levykuvan tallentaminen / palauttaminen. | Taso 3
Suhteellisen nopea palautuminen asynkronisesti tai aikataulun mukaan suoritetuista varmuuskopioista "lämpimään" varmuuskopiointipaikkaan. |
| neljä | Luodaan kopioita, jotka mahdollistavat ajankohtaisen palautuksen . | Yksi varmuuskopio kirjoitettu levylle. | Järjestelmän toiminnan etäkirjaus suoritetaan. | Varmuuskopiointi/palautus virtualisoinnin perusteella. | |
| 5 | Varmistaa tapahtumatietojen eheyden . | Mahdollisuus palauttaa tiedostojen yhdistäminen eri levykuvista | Luo rinnakkain varjokopio tuotantotietokannasta | Redundanssi perustuu palvelimiin, jotka toimivat klusterissa. | Taso 2
Nopea palautuminen asynkronisesta kopiosta kuumaan valmiustilaan. |
| 6 | Tietojen menetys on nolla tai vain vähän palautuksen jälkeen. | Tietojen saatavuus ensisijaisen ja varajärjestelmän välillä jaetulla levyllä. | Tietoja kopioidaan etänä. | ||
| 7 | Erittäin automatisoitu palautus. | Levyn peilaus ensisijaisen ja toissijaisen järjestelmän välillä. | Tietojen etäkopiointi suoritetaan vikasietoisesti. | Taso 1
Välitön palautus synkronisesta kopiosta kuumaan valmiustilaan. | |
| kahdeksan | Tietojen täydellinen päällekkäisyys. | ||||
Ymmärretään, että jokainen luokituksen seuraava taso täydentää tai korvaa edellisen ominaisuuksillaan.
Disaster Recovery as a Service (DRaaS) on sopimus kolmannen osapuolen, palvelun ja/tai laitteiston tarjoajan kanssa. [41] . Palveluntarjoajat tarjoavat yleensä osana palveluvalikoimaansa. Useat suuret laitetoimittajat tarjoavat osana tätä palvelua modulaarisia datakeskuksia , joiden avulla voit ottaa käyttöön katastrofipalautukseen tarvittavat laitteet mahdollisimman nopeasti.