Palautussuunnitelma on dokumentoitu menettelytapa teknisten palveluiden palauttamiseksi vian jälkeen. Se kattaa mitkä järjestelmät palautuvat missä järjestyksessä, kuinka kauan kukin palautumisaika on, kuinka paljon tietojen menetys on hyväksyttävää ja kuka suorittaa työn. Se on jatkuvuussuunnittelun tekninen kerros. Jatkuvuussuunnitelma pitää liiketoiminnan käynnissä keinolla millä hyvänsä, kun taas palautussuunnitelmassa on erityisesti kyse järjestelmien palauttamisesta.
- Prioriteettijärjestelmäluettelo, joka on peritty liiketoiminnan analyysi sen sijaan, että se olisi IT:n keksimä.
- Palautustavoite ja hyväksyttävä tietojen menetysluku kullekin järjestelmälle.
- Riittävän yksityiskohtaisia runbookeja, jotta joku muukin kuin tavallinen henkilö voi seurata niitä.
- Riippuvuusjärjestys, koska väärässä järjestyksessä palautetut järjestelmät eivät tule esiin.
- Testiraportti, koska testaamaton toipumismenettely on hypoteesi.
Mikä on katastrofipalautussuunnitelma?
Palautussuunnitelmassa esitetään, miten teknologiapalvelut palautetaan niitä kaatavan tapahtuman jälkeen: laitteistovian, datakeskuksen menetyksen, epäonnistuneen muutoksen, pilvialueen käyttökatkoksen tai kiristyshaittaohjelman. Se vastaa kolmeen kysymykseen jokaisesta suunnitelmaan kuuluvasta järjestelmästä: Kuinka nopeasti tiedot on palautettava, kuinka paljon viimeaikaisia tietoja meillä on varaa menettää ja mitä tarkalleen ottaen tehdään palauttaakseen tiedot.
Sana katastrofi on harhaanjohtava. Useimmat käynnistyskutsut eivät ole dramaattisia. Vioittunut tietokanta, epäonnistunut migraatio tai kriittisen palvelun vanhentunut varmenne lähettävät sinut samaan suunnitelmaan kuin tulva. Suunnitelman kirjoittaminen vain katastrofaalisia skenaarioita varten jättää sinut improvisoimaan paljon yleisempien skenaarioiden läpi.
Palautumissuunnittelu on osa liiketoiminnan jatkuvuuden alla kuvattua laajempaa osaamista , josta prioriteetit ja palautumisaikataulut tulevat. Jos teknologianäkemys on rakennettu ilman näitä, suunnitelma suojaa järjestelmiä järjestyksessä, jota kukaan ei ole validoinut liiketoimintaa vasten.
Miten valitset toipumismenetelmän?
Palautustavoite sanelee arkkitehtuurin, ja arkkitehtuuri sanelee kustannukset. Tämä on kompromissi, joka määrittää kaiken muun suunnitelmassa, ja se kannattaa tehdä eksplisiittisesti sen sijaan, että perittäisimme infrastruktuurin tukeman toiminnan. Vaihtoehtoja on kolme, ja niitä ympäröivä sanasto on turhan teknistä melko yksinkertaisille ideoille.
| Varmuuskopion palautus | Lämmin valmiustila | Aktiivinen-aktiivinen | |
|---|---|---|---|
| Mikä se on | Palvelun uudelleenrakentaminen viimeisimmästä varmuuskopiosta epäonnistumisen jälkeen | Toinen kopio pysyi käynnissä, mutta oli käyttämättömänä, vaihdettiin tarvittaessa. | Kaksi live-kopiota jakavat teoksen, joten ei ole mitään päälle kytkettävää |
| Tietojen menetysikkuna | Viimeisimmän varmuuskopion jälkeen | Minuuttitietoja | Lähellä nollaa |
| Aika palauttaa | Tunnista päivään | Minuuttia tunteihin | Lähellä nollaa |
| Suojaa | Viallinen tai salattu data | Infrastruktuurin menetys | Sivuston tai alueen menetys |
| Pysyvät kustannukset | Vain tallennustila | Osa toista omaisuutta | Kaksi elävää kartanoa |
| Soveltuvat | Palvelut, jotka kestävät käyttökatkoksen | Kriittisimmät palvelut | Palvelut, joita ei voi pysäyttää |
Harvat organisaatiot tarvitsevat samaa lähestymistapaa kaikkialla. Hyödyllinen malli on porrastaminen: pieni määrä palveluita, jotka eivät todellakaan voi pysäyttää, saa kalliin suojauksen, suurin osa saa oikeasuhteisen suojauksen ja pitkä häntä palautetaan varmuuskopiosta. Yhden lähestymistavan soveltaminen tasaisesti joko ylittää kulut toiminnoille, jotka kestäisivät päivän, tai jättää kriittisille muutamille toiminnoille palautumisajan, jonka yritys on jo hylännyt.
Kaksi vikaantumistapaa toistuu. Ensimmäinen on palautuskohde, joka valitaan hinnoittelematta sitä tarjoavaa arkkitehtuuria, joten suunnitelma sitoutuu johonkin, mitä infrastruktuuri ei voi tehdä. Toinen on replikoinnin ostaminen ja sen olettaminen palautukseksi, kun vioittunut tai salattu tietojoukko replikoituu yhtä uskollisesti kuin hyväkin. Replikointi suojaa infrastruktuurin menetyksiltä. Varmuuskopiot suojaavat virheelliseltä tiedolta, eivätkä nämä kaksi ole toisensa korvaavia.
Mitä katastrofivalmiussuunnitelman tulisi sisältää?
Järjestelmäkohtainen, ei organisaatiokohtainen. Yksittäinen yleisluontoinen kuvaus lähestymistavasta ei ole käytettävissä kello kolme aamuyöllä kenellekään päivystävälle henkilölle.
- Palautumistavoitteet: kyseisen järjestelmän aikatavoite ja hyväksyttävä tiedonhävikki, jäljitettynä ne asettavaan liiketoiminta-analyysiin.
- Riippuvuusjärjestys: minkä on oltava käynnissä ensin. Todennus, verkottuminen, DNS ja tietokannat yleensä edeltävät niitä tarvitsevia sovelluksia.
- Juoksukirjavarsinaiset vaiheet, jotka on kirjoitettu niin, että pätevä insinööri, joka ei omista järjestelmää, voi suorittaa ne.
- Käyttöoikeus ja tunnistetiedot: miten etuoikeutettu pääsy saadaan tapahtuman aikana, ja joka säilytetään paikassa, joka säilyy toimintahäiriön jälkeen.
- Tietojen palautus: missä varmuuskopiot sijaitsevat, miten eheys tarkistetaan ja kuinka kauan palautus todella kestää todellisilla tietomäärillä.
- Vahvistus: miten varmistat, että palvelu todella toimii eikä ainoastaan toiminnassa.
- Roolit ja eskaloituminenkuka päättää käynnistää, kuka suorittaa, kuka kommunikoi ja kuka valtuuttaa varajärjestelmän.
Näistä riippuvuusjärjestys saa eniten huomiota, koska väärin tehtynä se aiheuttaa virheitä, jotka näyttävät pikemminkin rikkinäiseltä järjestelmältä kuin järjestyksen virheeltä. Sovellus, joka on palautettu ennen tietokannan lukemista tai identiteettipalvelun käyttöä, jota vasten se todennetaan, ei käynnisty, ja tiimi menettää aikaa väärän ongelman diagnosointiin. Yleinen kaava pätee useimpiin kiinteistöihin.
Useimmiten puuttuva yksityiskohta on palautuksen todellinen kesto. Yön yli valmistuvan varmuuskopion palauttaminen tuotantomäärillä voi kestää huomattavasti kauemmin, ja jos kukaan ei ole mitannut sitä, palautustavoite on arvaus.
Yksi raja kannattaa vetää. Palautussuunnitelma palauttaa järjestelmät toimintakuntoon. Yrityksen käyttämä kiertotie tällöin yhden tietyn nimetyn riskin osalta kuuluu sen sijaan varautumissuunnitelmaan . Organisaatiot, jotka säilyttävät vain teknologiasuunnitelman, huomaavat usein, ettei kukaan ole sopinut, miten työ jatkuisi sillä välin.
Tämän takana on suurempi kuva.
Tämä sivu käsittelee yhtä osaa liiketoiminnan sietokyvystä. Kokonaiskuva loksahtaa kohdalleen Real Resiliencessa – IO:n viitekehyksessä, joka yhdistää tietoturvan, yksityisyyden ja tekoälyn hallinnan.
Miten testaat katastrofipalautussuunnitelmaa?
Testaus on se, missä elvytyssuunnitelmat saavat uskottavuutensa, ja siinä on edistystä. Jokainen taso maksaa enemmän ja todistaa enemmän, eikä ohjelma, joka ei koskaan pääse ensimmäiseltä tasolta, ole vakiintunut kovin hyvin.
| Testityyppi | Mitä se todistaa | Mitä se maksaa |
|---|---|---|
| Walkthrough | Että dokumentaatio on täydellinen ja ymmärrettävissä jollekin, joka ei ole sitä kirjoittanut. | Muutama tunti. Mihinkään järjestelmään ei koskettu. |
| Pöytäliikunta | Että ihmiset tietävät roolinsa ja että päätöksenteko ja eskalointi toimivat paineen alla. | Puoli päivää oikeiden ihmisten aikaa. |
| Komponenttien palautus | Että varmuuskopiot ovat todella palautettavissa ja että todellinen palautuksen kesto on tiedossa. | Kohtalainen. Tarvitsee eristetyn ympäristön. |
| Osittainen vikasietoisuus | Että yksittäinen palvelu voi toimia palautusasemastaan, riippuvuudet mukaan lukien. | Merkittävää suunnittelua. Jonkin verran palveluriskiä. |
| Täysi vikasietoisuus | Että koko ympäristö voi toimia palautumisesta kuormitettuna yrityksen työskennellessä sen parissa. | Korkea. Yleensä tarvitaan suunniteltu ikkuna. |
Kirjaa ylös, mikä epäonnistui. Löydetyt ja korjatut ongelmat sisältävä testiloki on vahvempi todiste toimintakyvystä kuin sarja puhtaita testejä, jotka viittaavat lähinnä siihen, etteivät testit olleet tarpeeksi vaativia. Löydökset omistajineen ja päivämäärineen muuttavat testauksen parannukseksi varmuuden sijaan.
Mitkä standardit kattavat katastrofien jälkeisen palautuksen?
Yhtäkään standardia ei ole tarkoitettu pelkästään katastrofien jälkeiseen palautumiseen, joten vaatimukset jakautuvat useille eri osa-alueille. Tämä on yksi syy siihen, miksi palautumissuunnittelu usein irtautuu kaikesta muusta.
- ISO 22301: sertifioitava liiketoiminnan jatkuvuuden hallintajärjestelmä. Se asettaa analyysin ja palautumisprioriteetit, jotka teknologiasuunnitelman tulisi sisältää.
- ISO / IEC 27031: ohjeita erityisesti ICT-valmiudesta liiketoiminnan jatkuvuuden varmistamiseksi, joka on lähimpänä katastrofien jälkeistä palautumista tieteenalana.
- ISO 27001Liite A sisältää toimenpiteitä tietoturvallisuuden varmistamiseksi häiriötilanteissa, tieto- ja viestintätekniikan jatkuvuusvalmiudessa sekä tietojen varmuuskopioinnissa, joten palautumiskykyä tarkastellaan auditoinnin aikana.
- Sektorisäännötsäännellyille organisaatioille on asetettu lisäodotuksia, esimerkiksi jatkuvuus- ja toipumisvaatimukset NIS 2:n käyttöönotto-ohjeet.
ISO 22301- ja ISO 27001 -standardien mukainen työskentely tuottaa suurimman osan näiden järjestelmien vaatimasta todistusaineistosta muodossa, joka on jo auditoitu riippumattomasti.
Aloita ilmainen kokeilu
Haluatko tutkia?
Rekisteröidy ilmaiseen kokeilujaksoon tänään ja pääset käyttämään kaikkia ISMS.onlinen tarjoamia yhteensopivuusominaisuuksia
Miten katastrofien jälkeinen palautuminen liittyy resilienssiin?
Katastrofien jälkeinen palautus palauttaa järjestelmät. Resilienssi on laajempi kyky selviytyä kaikenlaisista häiriöistä, mukaan lukien tapahtumista, joita mikään runbook ei ennakoi. Niiden välinen yhteys on se, että palautuminen riippuu kokonaan palautussuunnitelman ulkopuolisista kontrolleista: ovatko varmuuskopiot muuttumattomia, toimivatko etuoikeutetut käyttöoikeudet edelleen, kun identiteetintarjoaja on poissa käytöstä, onko palautusympäristöä ylläpitävää toimittajaa arvioitu ja toimiiko häiriötilanteisiin reagointiprosessi.
Resilience Loop toteuttaa tietoturvaa ISO 27001 -standardin mukaisesti, tietosuojaa ISO 27701 -standardin mukaisesti ja tekoälynhallintaa ISO 42001 -standardin mukaisesti yhtenä yhdistettynä järjestelmänä, jossa palautuminen toimii lisälinssinä samoihin kontrolleihin. Kiristysohjelmat tekevät tämän selväksi. Se on samanaikaisesti tietoturvahäiriö, mahdollisesti henkilötietojen rikkominen ja palautumistapahtuma, ja organisaatio, joka käyttää näitä kolmea erillisinä ohjelmina, reagoi siihen kolme kertaa. Rakenne, joka välttää tämän, on esitetty liiketoiminnan resilienssikehyksessä.
Miten todistat katastrofitilanteiden jälkeisen palautuksen toimivuuden?
Kukaan ei uskottavasti hyväksy suunnitelman olemassaoloa todisteena. Todisteena on itse suunnitelma nykyisine elvytystavoitteineen, testiraportteineen, joista käyvät ilmi päivämäärät ja osallistujat, testien paljastamat epäonnistumiset, sitä seuranneet korjaavat toimenpiteet ja vahvistus siitä, että suunnitelma vastaa edelleen kuvaamaansa kiinteistöä.
Työn aikana luotu todistusaineisto on aina saatavilla. Ennen tarkastusta tai asiakkaan due diligence -tarkastusta koottu todistusaineisto paljastaa yleensä, kuinka paljon dokumentoitu kiinteistö on poikennut todellisesta. Lähestymistapa on esitetty siinä, miten resilienssi osoitetaan , ja resilienssipisteytys antaa lähtökohdan, josta työskennellä.
Miksi valita ISMS.online katastrofien jälkeiseen suunnitteluun?
Elvytyssuunnitelmat epäonnistuvat paljon useammin valuutan kuin sisällön osalta. ISMS.online on rakennettu pitämään ne linjassa kuolinpesän kanssa.
- Suunnitelmat, jotka ovat sidottuja niiden kattamiin järjestelmiin: jokainen merkintä liittyy resurssiin, sen omistajaan ja siihen liittyviin ohjaimiin, joten ajautuminen on näkyvissä.
- Perityt, ei keksityt toipumistavoitteetliiketoiminta-analyysin asettamat tavoitteet siirtyvät teknologiasuunnitelmaan.
- Testiaikataulut ja löydökset yhdessäsuunnittele harjoitukset, kirjaa ylös epäonnistuneet asiat ja seuraa korjaavia toimenpiteitä samassa paikassa kuin suunnitelmaa.
- Yksi ohjausjoukko, jokainen kehysVarmuuskopiointi-, käyttöoikeus- ja toimittajien hallintamekanismit on kartoitettu kerran ja niitä käytetään uudelleen standardien ISO 22301, ISO 27031, ISO 27001, ISO 27701 ja ISO 42001 välillä.
- Toimittajariippuvuuksien arviointiKolmannet osapuolet, joista toipumisesi on hiljaisesti riippuvainen, hallitaan samassa järjestelmässä.
- Syvän asiantuntemuksen pohjalta: ohjattua toteutusta asiantuntijoilta, jotka ovat toteuttaneet toipumisohjelmia säännellyissä ympäristöissä.
- Rakennettu Iso-Britannian ja säännellyille markkinoilleSuunniteltu organisaatioille, joiden on osoitettava toipumiskykynsä tilintarkastajille ja asiakkaille.
Katso, miten se sopii yhteen liiketoiminnan resilienssialustalla , tai varaa demo.
UKK
Mitä eroa on katastrofien jälkeisellä palautumissuunnitelmalla ja liiketoiminnan jatkuvuussuunnitelmalla?
Palautussuunnitelma palauttaa teknologiapalvelut. Liiketoiminnan jatkuvuussuunnitelma pitää liiketoiminnan toiminnassa häiriöiden aikana millä tahansa käytettävissä olevilla keinoilla, mukaan lukien manuaalinen työskentely järjestelmien ollessa poissa käytöstä. Palauttaminen on osa jatkuvuutta eikä sen vaihtoehto, ja teknologiasuunnitelman palautustavoitteiden tulisi perustua liiketoiminta-analyysiin, johon jatkuvuussuunnitelma perustuu.
Mikä RTO:n ja RPO:n tulisi olla?
Molemmat perustuvat liiketoimintavaikutusten analyysiin eivätkä siihen, mitä infrastruktuuri pystyy tällä hetkellä tarjoamaan. Palautumisaikatavoite johdetaan pisteestä, jossa toiminnan häiriöistä tulee hyväksymättömiä, ja se asetetaan marginaalilla tämän rajan sisällä. Palautumispistetavoite seuraa siitä, kuinka paljon viimeaikaista dataa yrityksellä on varaa rekonstruoida tai menettää. Kummankin asettaminen nykyisen teknisen suorituskyvyn perusteella tuottaa tavoitteita, jotka aina saavutetaan eivätkä todista mitään.
Mitä eroa on lämpimän valmiustilan ja aktiivi-aktiivisen tilan välillä?
Lämmin valmiustila pitää palvelun toisen kopion käynnissä, mutta käyttämättömänä. Se ei palvele ketään, ennen kuin siirrät sen vikasietotilaan, joten palautus edellyttää tarkoituksellista vaihtoa, ja tämä vaihto vie aikaa ja voi mennä pieleen. Aktiivinen-aktiivinen tarkoittaa, että kaksi reaaliaikaista kopiota käsittelee molemmat todellista työtä samanaikaisesti, joten toisen menettäminen jättää toisen jo palvelemaan eikä mitään tarvitse kytkeä päälle. Aktiivinen-aktiivinen poistaa vikasietovaiheen ja on vastaavasti kalliimpi, koska käytät ja lisensoit kahta tuotantoympäristöä yhden ja varaympäristön sijaan.
Kuinka usein katastrofitilanteiden jälkeistä palautussuunnitelmaa tulisi testata?
Vähintään kerran vuodessa mielekkään testin suorittamiseksi, kevyemmillä läpikäynneillä useammin ja tarkastelulla aina, kun kiinteistössä tapahtuu olennaisia muutoksia. Tiheydellä on vähemmän merkitystä kuin edistymisellä: organisaatio, joka käyttää samaa pöytäjärjestelmää joka vuosi, tietää, että sen ihmiset ymmärtävät roolinsa, mutta sillä ei vieläkään ole näyttöä siitä, että palautus toimii tuotantomäärällä. Vaihtele testityyppiä, jotta eri oletuksia voidaan tarkastella.
Poistaako pilvipalvelu tarpeen katastrofien jälkeiselle palautussuunnitelmalle?
Ei. Pilvialustat tarjoavat rakennuspalikat vikasietoiselle arkkitehtuurille, mutta saatavuusvyöhykkeet ja hallitut palvelut ovat konfigurointivalintoja pikemminkin kuin oletusarvoja, ja alueellisia käyttökatkoksia esiintyy. Pilvipalvelut eivät myöskään tee mitään poistetulle tai salatulle tiedolle, virheelliselle konfiguroinnille tai vaarantuneelle tilille. Suunnitelma muuttaa muotoaan pilvessä, ja siitä tulee enemmän konfigurointia, muuttumattomia varmuuskopioita ja tilin palautusta kuin laitteistoa, mutta se ei katoa.
Onko kiristyshaittaohjelma katastrofipalautusjärjestelmä?
Se on sitä ja paljon muuta. Kiristysohjelmat ovat tietoturvapoikkeama, usein henkilötietojen rikkominen ja palautustapahtuma samanaikaisesti, ja ne mitätöivät tavanomaisen palautussuunnittelun oletukset. Varmuuskopiot voidaan salata tai poistaa, joten muuttumattomuus ja offline-kopiot ovat tärkeitä, ja ympäristö on ehkä rakennettava uudelleen sen sijaan, että se palautettaisiin paikalleen, koska palauttaminen vaarantuneeseen tilaan yksinkertaisesti tartuttaa sen uudelleen.
