Varmuuskopiointi on yksi yrityksen tietoturvan perusasioista. Tärkeät tiedostot ja järjestelmät varmistetaan, jotta ne voidaan saada takaisin, jos jotain tapahtuu.
Mutta varmuuskopion olemassaolo ei vielä vastaa kaikkein olennaisimpaan kysymykseen:
Kuinka nopeasti yritys pystyy jatkamaan toimintaansa?
Jos tärkeät tiedostot katoavat, Microsoft 365 -ympäristössä tapahtuu vakava häiriö tai liiketoimintakriittinen palvelu lakkaa toimimasta, tieto siitä, että data on jossain tallessa, lohduttaa vain rajallisesti.
Data pitää saada takaisin. Oikeat järjestelmät pitää palauttaa oikeassa järjestyksessä. Käyttäjien pitää päästä takaisin töihin. Jonkun pitää myös tietää, mitä tehdään ja kuka tekee päätökset.
Siksi palautuminen ei ole vain IT tekninen kysymys. Se on liiketoiminnan jatkuvuuteen ja johtamiseen liittyvä kysymys.
Varmuuskopiointi ja palautuminen eivät ole sama asia
Varmuuskopioinnissa huolehditaan siitä, että tiedosta on olemassa palautettavissa oleva kopio.
Palautumiskyky kertoo, mitä tapahtuu sen jälkeen.
Kuinka nopeasti tieto saadaan takaisin käyttöön? Kuinka kauan järjestelmät voivat olla poissa käytöstä? Onko palauttamiseen tarvittava osaaminen saatavilla? Entä tiedetäänkö, missä järjestyksessä järjestelmät pitää palauttaa?
Näiden kysymysten merkitys huomataan helposti vasta siinä vaiheessa, kun jotain on jo tapahtunut.
Tästä tunnettu esimerkki on GitLabin vuoden 2017 tietokantahäiriö. Tuotantotietokannasta poistettiin vahingossa dataa, minkä jälkeen GitLab.com oli poissa käytöstä noin 18 tuntia. Palautustilanteessa havaittiin, etteivät kaikki varmistusmekanismit toimineet odotetusti: muun muassa tietokannan normaalit varmuuskopiot olivat epäonnistuneet eikä niitä voitu käyttää palautukseen. Lopulta järjestelmä jouduttiin palauttamaan hitaammasta vaihtoehtoisesta kopiosta, ja osa tuotantodatasta menetettiin pysyvästi.
GitLab nosti jälkiselvityksessään esille myös hyvin olennaisen syyn ongelmaan: varmuuskopioiden palauttamisen säännöllisellä testaamisella ei ollut selkeää omistajaa. Kukaan ei siis ollut vastuussa siitä, että palautusprosessi todella toimisi käytännössä.
Teknisesti varmuuskopioita oli ajateltu olevan olemassa. Todellinen palautumiskyky selvisi vasta silloin, kun sitä tarvittiin.
Jos kaikkea ei saada heti takaisin, mitä palautetaan ensin?
Harvassa vakavassa häiriötilanteessa kaikki palautuu yhdellä napinpainalluksella.
Silloin yrityksen pitää pystyä vastaamaan vaikeampaan kysymykseen: minkä pitää toimia ensimmäisenä?
Onko kriittisintä saada sähköposti ja Teams käyttöön? Asiakastyön tiedostot? Käyttäjien tunnistautuminen? Taloushallinto? Verkkokauppa? Tuotannon järjestelmät? Vai esimerkiksi Azuren varassa toimiva palvelu, jota yrityksen asiakkaat käyttävät?
Oikea vastaus riippuu täysin liiketoiminnasta.
Jossakin yrityksessä muutaman tunnin sähköpostikatko on lähinnä hankala. Toisessa yrityksessä asiakkaiden käyttämän palvelun pysähtyminen voi alkaa aiheuttaa merkittävää vahinkoa lähes välittömästi.
Siksi palautumisjärjestystä ei pitäisi päättää varmuuskopiointijärjestelmän asetuksissa. Se pitäisi päättää sen perusteella, mikä on liiketoiminnalle tärkeintä.
Hydro osoitti, että palautuminen on myös priorisointia
Norjalainen teollisuuskonserni Hydro joutui maaliskuussa 2019 laajan kyberhyökkäyksen kohteeksi. Hyökkäys vaikutti yhtiön toimintaan maailmanlaajuisesti ja pakotti sen eristämään järjestelmiä sekä siirtymään monissa yksiköissä manuaalisiin toimintatapoihin. Saastuneita tietokoneita ja palvelimia tarkastettiin, puhdistettiin ja rakennettiin uudelleen varmuuskopioiden pohjalta.
Oleellista on, ettei koko yritys palautunut normaaliksi samalla hetkellä.
Viikko hyökkäyksen jälkeen suurin osa Hydron toiminnasta pyöri jo normaalilla kapasiteetilla, mutta pahiten kärsineen Extruded Solutions -liiketoiminta-alueen tuotanto oli noin 70–80 prosentissa normaalista ja yksi sen yksiköistä oli edelleen lähes pysähdyksissä. Monissa toimipisteissä työtä jatkettiin manuaalisesti samalla, kun IT-järjestelmiä palautettiin hallitusti.
Myöhemmissä päivityksissään Hydro kuvasi siirtyneensä teknisestä palautumisesta liiketoiminnan ja operaatioiden palautumiseen. Tukevia IT-toimintoja otettiin käyttöön vaiheittain ja tarvittaessa rakennettiin väliaikaisia toimintatapoja.
Juuri tästä palautumissuunnitelmassa on kyse.
Kaiken ei tarvitse välttämättä toimia heti. Mutta yrityksen pitää tietää, mitkä asiat eivät voi odottaa.
Palautumissuunnitelma alkaa liiketoiminnasta
Hyvä palautumissuunnitelma ei siis ala kysymyksestä siitä, mitä teknologiaa käytetään varmuuskopiointiin.
Ensin pitää ymmärtää yrityksen toimintaa.
Mitä ilman työnteko käytännössä pysähtyy? Mitkä järjestelmät näkyvät suoraan asiakkaalle? Minkä palvelun katkos estää laskutuksen, tuotannon tai asiakaspalvelun? Missä vaiheessa käyttökatko alkaa aiheuttaa merkittävää taloudellista vahinkoa tai muita ongelmia?
Kun nämä riippuvuudet tunnetaan, voidaan määritellä myös palautumisjärjestys.
Esimerkiksi käyttäjien tunnistautuminen voi olla edellytys lähes kaikelle muulle. Sen jälkeen voidaan tarvita asiakastyössä käytettävät järjestelmät ja tiedostot. Vähemmän kriittiset sisäiset palvelut voivat odottaa.
Tekninen palautusprosessi pitäisi rakentaa tämän järjestyksen ympärille – ei toisinpäin.
Entä jos ongelma ei olekaan kyberhyökkäys?
Palautumista ajatellaan helposti vain kiristyshaittaohjelmien tai muiden kyberhyökkäysten kautta. Todellisuudessa vakava häiriö voi syntyä myös paljon konkreettisemmasta syystä.
Maaliskuussa 2021 OVHcloudin Strasbourgin datakeskuksessa syttyi tulipalo. Yksi datakeskus tuhoutui ja koko alueen toiminta jouduttiin sähkön katkaisemisen vuoksi pysäyttämään. Katkos vaikutti tuhansiin asiakkaisiin ja osa asiakkaista menetti dataa. OVHcloudin raportin mukaan suurin osa dataa menettäneistä asiakkaista ei ollut ottanut käyttöön yhtiön tarjoamaa varmuuskopiointiratkaisua.
Tapaus muistuttaa yhdestä jatkuvuussuunnittelun perusasiasta: ei riitä, että tiedetään missä varsinainen järjestelmä sijaitsee. Pitää myös miettiä, missä varmuuskopio on, mistä se voidaan palauttaa ja mitä tapahtuu, jos alkuperäinen ympäristö ei olekaan käytettävissä.
Jos tuotanto ja varmuuskopio ovat käytännössä saman häiriön vaikutuspiirissä, varmuuskopio ei välttämättä tarjoa sitä turvaa, jota siltä odotetaan.
Johdon pitää tietää, kuinka kauan liiketoiminta voi odottaa
IT voi kertoa, millaisia järjestelmiä voidaan varmuuskopioida, kuinka usein varmistuksia tehdään ja millä tavalla palautus teknisesti toteutetaan.
Mutta IT ei yksin voi päättää, kuinka pitkän katkoksen liiketoiminta kestää.
Jos keskeinen järjestelmä olisi poissa käytöstä kaksi tuntia, mitä tapahtuisi?
Entä kahdeksan tuntia?
Tai kaksi työpäivää?
Näihin kysymyksiin vastaaminen kuuluu liiketoiminnalle ja johdolle. Vasta niiden perusteella voidaan arvioida, vastaavatko nykyiset tekniset ratkaisut yrityksen todellisia tarpeita.
Samalla pitää sopia vastuut. Häiriötilanteessa ei pitäisi alkaa selvittää, kuka saa päättää palautumisjärjestyksestä, kuka kommunikoi henkilöstölle tai asiakkaille ja kuka johtaa teknistä palauttamista.
Päätöksenteko on huomattavasti helpompaa silloin, kun pelisäännöt on mietitty ennen kriisiä.
Palautumista pitää myös harjoitella
Palautumissuunnitelma voi näyttää paperilla erinomaiselta ja silti epäonnistua käytännössä.
Varmuuskopio voi olla vioittunut. Palauttaminen voi kestää oletettua kauemmin. Käyttäjien oikeudet eivät ehkä palaudu odotetusti. Yksi kriittinen palvelu saattaa olla riippuvainen toisesta järjestelmästä, jota kukaan ei huomannut sisällyttää ensimmäiseen palautusvaiheeseen.
GitLabin tapaus on tästä erityisen hyvä muistutus: ongelma ei ollut ainoastaan tekninen virhe, vaan myös se, ettei palautusmenettelyä ollut testattu säännöllisesti eikä sen toimivuudella ollut selkeää omistajaa.
Palautumisen testaamisen ei tarvitse tarkoittaa koko yrityksen pysäyttämistä.
Oleellisinta on pystyä osoittamaan käytännössä, että kriittinen tieto todella voidaan palauttaa, palautumiseen kuluva aika tunnetaan, tarvittavat riippuvuudet on huomioitu ja vastuuhenkilöt tietävät oman roolinsa.
On huomattavasti parempi löytää suunnitelman heikko kohta hallitussa testissä kuin keskellä oikeaa häiriötilannetta.
Varmuuskopio on vasta lähtökohta
Varmuuskopioinnin tavoitteena ei lopulta ole mahdollisimman suuri määrä varmuuskopioita.
Tavoitteena on, että yritys pystyy jatkamaan toimintaansa myös silloin, kun jotain menee pahasti pieleen.
Siksi yrityksen johdon pitäisi pystyä vastaamaan ainakin näihin kysymyksiin:
Mikä palautetaan ensimmäisenä?
Kuinka nopeasti kriittisten palveluiden pitää olla jälleen käytössä?
Kuka tekee päätökset häiriötilanteessa?
Ja milloin palautumista on viimeksi kokeiltu käytännössä?
Jos vastaukset eivät ole selvillä etukäteen, toimiva varmuuskopiointi voi antaa turvallisuuden tunnetta ilman todellista varmuutta liiketoiminnan palautumisesta.
Varmuuskopio on tärkeä.
Mutta lopulta olennaisempaa on se, palaako liiketoiminta.
