Kun yrityksenne avainjärjestelmä kaatuu, vaikeinta on tietää, mitä palauttaa ensin, kenellä on käyttöoikeus sen tekemiseen, mihin varmuuskopioon voi luottaa ja kuinka kauan yrityksenne voi jatkaa toimintaansa ilman kyseistä järjestelmää.
Tällöin monet pienet ja keskisuuret yritykset (pk-yritykset) huomaavat kuilun varmuuskopioiden olemassaolon ja todellisen palautustilauksen välillä. Varmuuskopio saattaa sisältää tarvitsemanne tiedot, mutta se ei määritä palautusjärjestystä, jaa vastuita, vahvista palautuksen toimivuutta tai ratkaise puuttuvien ylläpitäjän kirjautumistietojen ongelmaa käyttökatkon aikana.
IT-katastrofipalautustilaus antaa tälle prosessille rakenteen ennen häiriön ilmenemistä. Se määrittelee, mitkä järjestelmät ovat tärkeimpiä, kuinka nopeasti ne on palautettava, kuinka paljon tietojen menetystä yritys voi sietää, mitä tietojen häviämisen estämisen strategioita otetaan käyttöön, kuka vastaa kustakin palautusvaiheesta ja miten kriittiset kirjautumistiedot suojataan. Tämä selkeys voi estää IT-vaaratilanteen muuttumisen pitkittyneeksi seisokkiajaksi, menetetyiksi tuloiksi tai laajemmaksi toiminnalliseksi kriisiksi.
Mikä on IT-katastrofipalautustilaus?
Toiminnan jatkuvuus vs. IT-katastrofipalautus
Mitä IT-katastrofipalautustilauksenne on kattava
Mitä IT-katastrofipalautustilauksenne on määriteltävä
Kirjautumistietojen palautus: huomiotta jätetty katastrofipalautusskenaario
Katastrofipalautustilauksen mallipohja
Miten IT-katastrofipalautustilaus testataan
Rakentakaa palautus järjestelmien, tietojen ja käyttöoikeuksien ympärille
Mikä on IT-katastrofipalautustilaus?
IT-katastrofipalautustilaus on dokumentoitu prosessi teknologiajärjestelmien palauttamiseksi häiriön jälkeen. Se keskittyy yrityksen IT-tasoon: tietoihin, sovelluksiin, laitteisiin, infrastruktuuriin, pilvipalveluihin, ylläpitäjän käyttöoikeuksiin, varmuuskopioihin ja palautuksesta vastaaviin henkilöihin.
Käytännöllisen IT-palautustilauksen tulisi vastata seuraaviin kysymyksiin:
- Mitkä järjestelmät on palautettava ensin?
- Kuinka paljon seisokkiaikaa yritys voi sietää?
- Kuinka suuri tietojen menetys on hyväksyttävää?
- Missä varmuuskopiot on tallennettu?
- Kuka voi palauttaa järjestelmiä?
- Mitä ylläpitäjän kirjautumistietoja tarvitaan?
- Miten tiimi vahvistaa, että palautetut järjestelmät ovat turvallisia ja käyttökelpoisia?
- Miten yritys viestii henkilöstölle ja asiakkaille, jos ensisijaiset kanavat ovat poissa käytöstä?
Katastrofipalautustilauksen tulisi kattaa muutakin kuin kyberhyökkäykset: sen on katettava arkipäiväiset ongelmat, kuten laitteistoviat, kadonneet kirjautumistiedot ja tahattomat poistot. Sen on myös katettava ulkoisten palveluiden keskeytykset, kuten pilvialustojen tai SaaS-työkalujen häiriöt, virheelliset määritykset sekä avainhenkilöiden lähteminen siirtämättä kriittisiä käyttöoikeuksia.
Palautusta ei tule suunnitella katkoksen aikana. Se on suunniteltava, sille on määritettävä vastuuhenkilöt, siitä on viestittävä ja se on testattava ennen kuin yrityksenne on tukeuduttava siihen.
Toiminnan jatkuvuus vs. IT-katastrofipalautus
Toiminnan jatkuvuutta ja IT-katastrofipalautusta pidetään usein samana asiana, mutta ne ratkaisevat eri ongelmia.
Toiminnan jatkuvuudessa on kyse yrityksen toiminnan ylläpitämisestä häiriön aikana. Se kattaa asiakasviestinnän, väliaikaiset työnkulut, henkilöstön vastuut, toimittajien koordinoinnin ja päätökset siitä, mitä palveluita on jatkettava, vaikka tavalliset järjestelmät eivät olisikaan käytettävissä.
IT-katastrofipalautus keskittyy tämän työn taustalla olevaan teknologiaan. Se määrittelee, miten järjestelmät, tiedot, sovellukset, varmuuskopiot ja ylläpitäjien käyttöoikeudet palautetaan, jotta yritys voi palata normaaliin toimintaan turvallisesti.
Esimerkkinä voidaan pitää CRM-järjestelmän käyttökatkoa. Toiminnan jatkuvuustilaus voi selittää, miten myynti- tai tukitiimit jatkavat asiakkaiden palvelemista CRM-järjestelmän ollessa alhaalla. IT-palautustilaus puolestaan selittää, kuka ottaa yhteyttä toimittajaan, mitä tietoja on palautettava, mikä varmuuskopio tai vienti on käytettävissä, mitä kirjautumistietoja tarvitaan ja miten tiimi vahvistaa, että järjestelmää on jälleen turvallista käyttää.
Monille pk-yrityksille kuilu paljastuu vasta vaaratilanteen aikana. Tiedetään, kuka ottaisi yhteyttä asiakkaisiin, mutta ei sitä, kuka voi palauttaa laskutusjärjestelmän. Tiedetään, että varmuuskopioita on olemassa, mutta ei sitä, onko palautusta koskaan testattu. Tiedetään, että yksi työntekijä yleensä hoitaa IT-asioita, mutta ei sitä, mitä tapahtuu, jos kyseinen henkilö ei ole käytettävissä, tai missä ylläpitäjän salasanat on tallennettu, jos häneen ei saada yhteyttä.
Mitä IT-katastrofipalautustilauksenne on kattava
Vahvan IT-katastrofipalautustilauksen ei tarvitse olla liian pitkä, mutta sen on oltava riittävän yksityiskohtainen, jotta sitä voidaan noudattaa stressaavassa tilanteessa.
Palautusaikatavoite
Palautusaikatavoite eli RTO määrittelee, kuinka nopeasti järjestelmä on palautettava. Maksujärjestelmän on ehkä oltava jälleen käytössä muutamassa tunnissa, kun taas sisäisen raportoinnin hallintapaneeli saattaa sietää pidemmän katkoksen.
Asettakaa RTO-tavoitteet liiketoimintavaikutusten, älä teknisten asetusten perusteella, sillä seisokkien kustannukset ovat sekä liiketoiminnallinen että tekninen ongelma. Kysykää, mitkä järjestelmät vaikuttavat liikevaihtoon, asiakassitoumuksiin, lakisääteisiin velvoitteisiin, tietoturvaan ja työntekijöiden tuottavuuteen.
Palautuspistetavoite
Palautuspistetavoite eli RPO määrittelee, kuinka suuri tietojen menetys on hyväksyttävää, mikä auttaa valitsemaan oikeat tietojen häviämisen estämisen (DLP) strategiat. Jos järjestelmän RPO on yksi tunti, varmuuskopioiden tai replikoinnin on tuettava palautusta suurin piirtein tähän ajankohtaan.
Jos RPO on yksi päivä, yritys hyväksyy suuremman aukon. RPO auttaa myös määrittämään varmuuskopiointitiheyden, sillä mitä lyhyempi RPO on, sitä useammin varmuuskopioita on tehtävä. Kriittiset järjestelmät tarvitsevat siksi tiheämpiä varmuuskopioita kuin matalan prioriteetin järjestelmät.
Järjestelmien prioriteettitasot
Kaikkia järjestelmiä ei tule palauttaa samanaikaisesti. Pienyrityksen katastrofipalautustilauksen tulisi jakaa järjestelmät prioriteettitasoihin.
- Taso 1: Järjestelmät, joita tarvitaan ydintoimintoihin, tietoturvaan, viestintään tai liikevaihdon kerryttämiseen.
- Taso 2: Tärkeät järjestelmät, jotka sietävät lyhyitä käyttökatkoja.
- Taso 3: Matalamman prioriteetin järjestelmät, jotka voidaan palauttaa sen jälkeen, kun yrityksen toiminta on vakaata.
Tyypillisiä tason 1 järjestelmiä voivat olla sähköposti, henkilöllisyydentarjoaja, salasananhallinta, talousjärjestelmät, asiakastietokanta, pilvitallennustila ja viestintäalustat.
Varmuuskopiointistrategia
Varmuuskopiointistrategianne tulisi määritellä:
- Mitä varmuuskopioidaan ja kuinka usein
- Missä varmuuskopiot on tallennettu
- Kuka voi käyttää niitä
- Miten palautusta testataan
NCSC on myös julkaissut(uusi ikkuna) lunnasohjelman kestäviä varmuuskopiointiperiaatteita pilvi- ja paikallisille varmuuskopioratkaisuille, huomauttaen, että varmuuskopioidut tiedot eivät ole oletusarvoisesti lunnasohjelman kestäviä ja ne tulisi arvioida lunnasohjelman uhkaa vastaan.
Vahva varmuuskopiointistrategia sisältää yleensä offline- tai muuttumattomat varmuuskopiot kriittisille tiedoille, säännöllisen testaamisen, dokumentoidut palautusvaiheet ja erilliset kirjautumistiedot varmuuskopioinnin hallintaan.
Tehtävät ja vastuut
Katastrofipalautustilauksessa tulisi nimetä vastuuhenkilöt, ei vain tehtäviä. Jos kaikki palautustieto on yhden henkilön varassa, yrityksellä on henkilöstöriski IT-riskin lisäksi. Määritelkää, kuka:
- Johtaa palautusta
- Palauttaa järjestelmät
- Ottaa yhteyttä toimittajiin
- Hyväksyy hätäkäyttöoikeudet
- Viestii sisäisesti
- Dokumentoi päätökset
Mitä IT-katastrofipalautustilauksenne on määriteltävä
| Komponentti | Mihin se vastaa |
| RTO | Kuinka nopeasti kukin järjestelmä on palautettava? |
| RPO | Kuinka paljon tietoja yrityksellä on varaa menettää? |
| Prioriteettitasot | Mitkä järjestelmät palautetaan ensin, ja mitkä voivat odottaa? |
| Varmuuskopiointistrategia | Mitä varmuuskopioidaan, mihin ne tallennetaan ja onko palautusta testattu? |
| Tehtävät ja vastuut | Kuka johtaa palautusta, palauttaa järjestelmät, ottaa yhteyttä toimittajiin ja hyväksyy hätämuutokset? |
Kirjautumistietojen palautus: huomiotta jätetty katastrofipalautusskenaario
Katastrofipalautus keskittyy usein tietoihin, palvelimiin ja varmuuskopioihin. Käytännössä palautus voi kuitenkin epäonnistua, koska tiimi ei pääse käyttämään järjestelmiä, joita tarvitaan toiminnan palauttamiseen.
Kirjautumistietojen palautuksessa kysytään:
- Kenellä on pääsy ylläpitäjätileille?
- Missä varmuuskopioiden kirjautumistiedot on tallennettu?
- Mitkä tilit voivat palauttaa kriittisiä järjestelmiä?
- Mitä tapahtuu, jos salasana katoaa, altistuu tietoturvaloukkaukselle tai on sellaisen henkilön hallussa, joka ei ole tavoitettavissa?
- Ovatko hätätilanteen kirjautumistiedot suojattuja ja tarkistettuja?
- Voidaanko käyttöoikeudet mitätöidä ja määrittää uudelleen nopeasti?
Jos varmuuskopioiden kirjautumistiedot on tallennettu yhden työntekijän selaimeen, palautuskoodit säilytetään yksityisessä muistiinpanossa tai jaetut ylläpitäjän salasanat kiertävät chatissa, yritys ei välttämättä pysty toipumaan häiriöttömästi vaaratilanteen aikana.
Yrityskäyttöön tarkoitettu salasananhallinta auttaa vähentämään tätä riskiä keskittämällä kriittiset kirjautumistiedot salattuihin holveihin, määrittämällä käyttöoikeudet tehtävän mukaan ja helpottamalla käyttöoikeuksien mitätöimistä tai uudelleenmäärittämistä, kun joku lähtee tai vastuut muuttuvat. Proton Pass for Business auttaa tiimejä luomaan vahvoja salasanoja, tallentamaan kirjautumistiedot turvallisesti, käyttämään turvallista jakamista ja pitämään arkaluonteiset käyttöoikeudet poissa chateista ja laskentataulukoista.
IT-tiimeille suunnattuna salasananhallintana Proton Pass tukee keskitettyä kirjautumistietojen hallintaa, salasanakäytäntöjä, turvallista jakamista, raportointia ja lokeja, SCIM-provisiointia sekä SSO-integraatioita. Se tekee kirjautumistietojen palauttamisesta hallittavampaa, koska pääsy kriittisiin järjestelmiin ei ole riippuvainen yhdestä henkilöstä, yhdestä selainprofiilista tai yhdestä dokumentoimattomasta salasanasta.
Katastrofipalautustilauksen mallipohja
Katastrofipalautustilaus toimii parhaiten, when se on riittävän yksityiskohtainen ohjaamaan toimintaa käyttökatkon aikana, mutta riittävän yksinkertainen tiimin käytettäväksi paineen alla. Pk-yrityksissä mallipohjan tulisi keskittyä olennaiseen: mitä on palautettava, kuinka nopeasti, mistä varmuuskopiosta, kenen toimesta ja millä kirjautumistiedoilla.
1. Laajuus
Määritelkää, mitkä järjestelmät, palvelut, sijainnit, laitteet ja tiedot tilaus kattaa.
Mallipohjan teksti: Tämä IT-katastrofipalautustilaus kattaa järjestelmät, tiedot, palvelut, kirjautumistiedot ja toimittajat, joita tarvitaan [Yrityksen nimi] -yrityksen kriittisten toimintojen palauttamiseen teknologiahäiriön jälkeen.
2. Kriittisten järjestelmien luettelo
Luetteloikaa järjestelmät, joihin yrityksenne tukeutuu, ja määrittäkää niille prioriteettitasot.
Mallipohjan teksti: Kriittiset järjestelmät ryhmitellään tasoille 1, 2 ja 3 liiketoimintavaikutuksen, palautusaikatavoitteen, palautuspistetavoitteen ja muihin järjestelmiin liittyvien riippuvuuksien perusteella.
3. Palautustavoitteet
Määritelkää RTO ja RPO kullekin prioriteettijärjestelmälle.
Mallipohjan teksti: Kullakin järjestelmällä on oltava dokumentoitu palautusaikatavoite ja palautuspistetavoite. Nämä tavoitteet tulisi tarkistaa vähintään vuosittain ja suurten järjestelmämuutosten jälkeen.
4. Varmuuskopiointi- ja palautusprosessi
Dokumentoikaa, missä varmuuskopiot on tallennettu, kuinka usein ne ajetaan, kuka voi käyttää niitä ja miten palautuksen testaaminen toimii.
Mallipohjan teksti: Varmuuskopiot on suojattava luvattomalta käytöltä, tallennettava tarvittaessa erillään ensisijaisista järjestelmistä ja testattava säännöllisesti. Palautusmenetelmät on dokumentoitava tason 1 järjestelmille.
5. Kirjautumistietojen ja käyttöoikeuksien palautus
Määritelkää, missä kriittiset kirjautumistiedot on tallennettu ja kuka voi käyttää niitä palautuksen aikana.
Mallipohjan teksti: Ylläpitäjän kirjautumistiedot, varmuuskopioiden kirjautumistiedot, palautuskoodit ja katastrofipalautukseen tarvittavat toimittajien käyttöoikeudet on tallennettava hyväksytyssä salatussa holvissa. Käyttöoikeudet on rajattava valtuutettuihin tehtäviin, ja ne on tarkistettava tehtävämuutosten, työntekijöiden poistumisen ja palautusharjoitusten jälkeen.
6. Tehtävät ja eskalointi
Määritelkää palautuksesta vastaavat henkilöt, varahenkilöt ja eskalointireitit.
Mallipohjan teksti: Kullakin palautustehtävällä on oltava ensisijainen vastuuhenkilö ja varavastuuhenkilö. Tilauksen on tunnistettava, kuka johtaa palautusta, kuka palauttaa järjestelmät, kuka ottaa yhteyttä toimittajiin, kuka viestii päivityksistä ja kuka hyväksyy hätämuutokset.
7. Viestintätilaus
Määritelkää, miten yritys viestii sisäisesti ja ulkoisesti IT-käyttökatkon aikana.
Mallipohjan teksti: Palautustapahtuman aikana sisäiset päivitykset jaetaan [hyväksytyn kanavan] kautta. Ulkoisen viestinnän asiakkaille, toimittajille, vakuutusyhtiöille tai sääntelyviranomaisille on oltava [tehtävän/tiimin] hyväksymää.
8. Testaus- ja tarkistustiheys
Määritelkää, kuinka usein tilaus testataan ja päivitetään.
Mallipohjan teksti: Tämä katastrofipalautustilaus testataan vähintään [vuosittain / kaksi kertaa vuodessa] ja tarkistetaan suurten vaaratilanteiden, järjestelmämuutosten, toimittajamuutosten tai epäonnistuneiden palautusharjoitusten jälkeen.
Miten IT-katastrofipalautustilauksenne testataan
Katastrofipalautustilaus muuttuu hyödylliseksi vasta, kun sitä on testattu todellista häiriötä muistuttavissa olosuhteissa. Varmuuskopio, joka on olemassa mutta jota ei ole koskaan palautettu, on silti vain oletus. Palautustehtävä, jonka vain yksi henkilö ymmärtää, on edelleen riippuvuustekijä. Ylläpitäjän kirjautumistieto, jota kukaan ei löydä katkoksen aikana, on edelleen este.
Testauksen ei tarvitse aluksi olla monimutkaista. Useimmille pk-yrityksille tavoitteena on osoittaa, että yritys pystyy palauttamaan oikeat järjestelmät, oikeiden ihmisten toimesta ja oikeilla kirjautumistiedoilla realistisessa ajassa.
1. Pöytäharjoitus
Valitkaa todennäköinen skenaario, kuten jaettuihin tiedostoihin vaikuttava lunnasohjelma, pilvitallennustilan katkos, asiakastietojen tahaton poistaminen tai ylläpitäjätilin käyttöoikeuden äkillinen menetys. Käykää läpi, mitä tiimi tekisi ensimmäisen tunnin aikana, kuka johtaisi toimintaa, mihin toimittajiin otettaisiin yhteyttä, mitkä järjestelmät asetettaisiin etusijalle ja mitä tietoja puuttuisi.
2. Testatkaa palautusta
Valitkaa kriittinen tiedosto, tietokanta, postilaatikko tai järjestelmän vienti ja vahvistakaa, että se voidaan palauttaa käyttökelpoiseen tilaan. Tarkistakaa, ovatko palautetut tiedot riittävän tuoreita, toimivatko käyttöoikeudet edelleen ja tietääkö tiimi, missä varmuuskopio sijaitsee.
3. Testatkaa säännöllisesti
Käytännön lähtökohtana pk-yritysten tulisi testata tilaus vähintään kerran vuodessa NIST:n ohjeiden mukaisesti, jotka on julkaistu julkaisussa Special Publication 800-34 Revision 1(uusi ikkuna), ja useammin suurten järjestelmä- tai toimittajamuutosten jälkeen.
4. Testatkaa kirjautumistietojen palautusta
Vahvistakaa, että valtuutetut henkilöt pääsevät käsiksi varmuuskopioiden ylläpitäjätileihin, pilven ylläpitäjätileihin, toimittajaportaaleihin, palautuskoodeihin ja hätätilanteen kirjautumistietoihin ilman riippuvuutta yhden työntekijän selaimesta, yksityisistä muistiinpanoista tai muistista. Tavoitteena ei ole altistaa arkaluonteisia salasanoja tarpeettomasti. Tarkoituksena on vahvistaa, että käyttöoikeusmalli toimii edelleen, kun yritys on paineen alla.
Dokumentoikaa jokaisen testin jälkeen, mikä epäonnistui, mikä kesti liian kauan, ja määrittäkää vastuuhenkilö ja määräaika jokaiselle korjaukselle. Hyvä testi ei ole sellainen, jossa kaikki sujuu täydellisesti. Se on testi, joka paljastaa puutteet silloin, kun yrityksellä on vielä aikaa korjata ne.
Rakentakaa palautus järjestelmien, tietojen ja käyttöoikeuksien ympärille
Hyödyllinen IT-katastrofipalautustilaus antaa yritykselle palautusjärjestyksen, vastuuhenkilöt, realistisen näkemyksen hyväksyttävästä seisokkiajasta sekä tavan ylläpitää toiminnan jatkuvuutta ja palauttaa pääsy järjestelmiin, jotka pitävät työn käynnissä.
Pk-yrityksille tämä voi merkitä eroa lyhyen häiriön ja pitkittyneen käyttökatkon välillä. Jos sähköposti, talousohjelmisto, pilvitallennustila, asiakasjärjestelmät tai ylläpitäjätilit eivät ole käytettävissä, tiimin on tiedettävä, mikä on etusijalla, kuka voi toimia ja mitä kirjautumistietoja tarvitaan käyttöoikeuksien palauttamiseksi turvallisesti.
Tästä syystä palautuksen suunnittelun tulisi kattaa järjestelmät, tiedot ja käyttöoikeudet yhdessä. Varmuuskopiot voivat palauttaa tiedostot, mutta kirjautumistiedot ovat niitä, joiden avulla tiimi saa takaisin hallintaansa palauttamiseen tarvittavat järjestelmät. Ylläpitäjän kirjautumiset, toimittajaportaalit, varmuuskopiotilit, palautuskoodit ja jaetut toiminnalliset kirjautumistiedot on kaikki suojattava, järjestettävä ja pidettävä oikeiden ihmisten saatavilla, kun jotain menee vikaan.
Yrityskäyttöön tarkoitettu salasananhallinta auttaa vahvistamaan tätä osaa tilauksesta. Kun kriittiset kirjautumistiedot on tallennettu salattuihin salasanaholveihin ja jaetaan vain valtuutettujen henkilöiden kanssa, yritys on vähemmän riippuvainen yhden työntekijän selaimesta, yksityisistä muistiinpanoista tai muistista palautustapahtuman aikana.
