Varmuuskopiointi epäonnistui – ja se huomattiin vasta liian myöhään
Moni yritys ajattelee, että varmuuskopiointi on kunnossa niin kauan kuin varmistusjärjestelmä näyttää vihreää valoa eikä kukaan saa hälytyksiä. Käytännössä ongelmat alkavat usein paljon aikaisemmin.
Yksi yleisimmistä yllätyksistä IT-palveluissa on se, että varmuuskopiot näyttävät onnistuneilta, mutta palautus ei toimikaan silloin kun sitä tarvitaan. Tiedosto puuttuu, tietokanta on vioittunut tai osa palvelimesta jäi kokonaan varmistamatta. Silloin huomataan, että varmuuskopioinnin onnistuminen ja palautuksen onnistuminen ovat kaksi eri asiaa.
Hallituissa IT-palveluissa varmistukset ovat yksi niistä alueista, joiden pitäisi toimia huomaamatta päivästä toiseen. Juuri siksi niihin liittyvät ongelmat jäävät helposti piiloon.
Ongelma ei yleensä ala varmuuskopiosta
Kun yritys menettää tietoja, ensimmäinen kysymys kuuluu usein:
“Miksi varmuuskopio ei toiminut?”
Todellinen ongelma on kuitenkin monessa tapauksessa syntynyt viikkoja tai kuukausia aikaisemmin.
Olennaista on ymmärtää, että varmistusprosessi koostuu useista eri vaiheista:
tiedon keräämisestä
tiedon siirtämisestä
tallentamisesta
säilyttämisestä
palautuksen testaamisesta
Jos yksikin vaihe alkaa toimia väärin, lopputulos voi näyttää pitkään normaalilta.
Esimerkiksi levytila voi täyttyä hitaasti. Varmistuspalvelin voi jatkaa toimintaansa, mutta vanhoja palautuspisteitä poistetaan automaattisesti. Kun palautusta tarvitaan, huomataan että käytettävissä on vain muutaman päivän historia, vaikka tavoitteena oli säilyttää tietoja kuukausien ajalta.
Hiljaiset epäonnistumiset ovat vaarallisimpia
➠ IT-ympäristöissä kaikkein hankalimpia eivät yleensä ole näkyvät virheet.
➠ Jos varmistus epäonnistuu kokonaan ja järjestelmä lähettää hälytyksen, ongelmaan voidaan reagoida nopeasti.
➠ Vaikeammat tilanteet liittyvät niin sanottuihin hiljaisiin virheisiin.
➠ Varmistus saattaa valmistua ilman virheilmoitusta, mutta kaikkia tietoja ei ole mukana. Tämä voi tapahtua esimerkiksi silloin, kun uusi sovellus otetaan käyttöön eikä sitä lisätä varmistuksen piiriin. Palvelin näkyy raportissa onnistuneena, mutta osa liiketoiminnan kannalta tärkeästä datasta jää kokonaan suojaamatta.
➠ Tällaisia tapauksia nähdään erityisesti ympäristöissä, joissa palveluita kehitetään jatkuvasti ja infrastruktuuri muuttuu nopeasti.
Pilvipalvelut eivät poista varmistustarvetta
Yksi yleinen väärinkäsitys liittyy pilvipalveluihin.
Moni olettaa, että esimerkiksi Microsoft 365:n, AWS:n tai muiden pilvipalveluiden käyttö tarkoittaa automaattisesti täydellistä tietosuojaa.
Todellisuudessa palveluntarjoajan vastuu ja asiakkaan vastuu ovat eri asioita.
Jos käyttäjä poistaa tiedostoja, tietokantaa muutetaan virheellisesti tai kiristyshaittaohjelma salaa tietoja, palautusmahdollisuudet riippuvat siitä, millainen varmistusratkaisu ympäristöön on rakennettu.
Pilvi ei poista varmuuskopioinnin tarvetta. Se vain muuttaa sitä, miten varmistukset toteutetaan.
Miksi palautus epäonnistuu juuri kriittisellä hetkellä?
Tämä on kysymys, jonka moni IT-tiimi joutuu kohtaamaan ainakin kerran.
Syy löytyy usein siitä, että palautuksia ei testata riittävän säännöllisesti.
Varmuuskopioiden olemassaolo ei vielä kerro mitään niiden käyttökelpoisuudesta.
Jos palautusta ei koskaan harjoitella, kukaan ei tiedä:
kuinka kauan palautus kestää
palautuuko koko järjestelmä vai vain osa siitä
ovatko käyttöoikeudet kunnossa
käynnistyvätkö sovellukset normaalisti palautuksen jälkeen
Monessa yrityksessä palautustesti tehdään vasta todellisen häiriön aikana. Se on huonoin mahdollinen hetki huomata, että dokumentaatio on vanhentunut tai palautusprosessi on muuttunut.
Kiristyshaittaohjelmat muuttivat pelisäännöt
➠ Muutama vuosi sitten varmuuskopioinnissa keskityttiin lähinnä laitteistovikoihin ja käyttäjävirheisiin.
➠ Nykyään keskustelu pyörii usein kiristyshaittaohjelmien ympärillä.
➠ Tämä on muuttanut myös varmistusstrategioita.
➠ Jos hyökkääjä pääsee samaan ympäristöön kuin varmistusjärjestelmä, hän voi yrittää poistaa tai salata myös varmuuskopiot. Tämän vuoksi monet organisaatiot ovat siirtyneet käyttämään eristettyjä tallennusratkaisuja sekä niin sanottuja muuttumattomia varmistuksia, joita ei voida muokata tietyn säilytysajan aikana.
➠ Tavoitteena ei ole vain tallentaa tietoa, vaan varmistaa, että tieto on käytettävissä myös hyökkäyksen jälkeen.
Dokumentaatio unohtuu liian usein
Tekniset ratkaisut saavat paljon huomiota, mutta käytännössä moni palautus viivästyy aivan muista syistä.
Kun avainhenkilö on lomalla tai vaihtanut työpaikkaa, kukaan ei välttämättä tiedä:
missä varmistukset sijaitsevat
miten palautus käynnistetään
mitä järjestystä palveluiden palautuksessa pitää noudattaa
mitkä tunnukset ovat käytössä
Silloin ongelma ei ole tekninen vaan operatiivinen.
Hyvä dokumentaatio ei ole pelkkä auditointivaatimus. Se voi ratkaista sen, saadaanko liiketoiminta takaisin toimintaan tunneissa vai päivissä.
Miten ongelmia voidaan vähentää?
Täydellistä ympäristöä ei ole olemassa, mutta tietyt käytännöt vähentävät riskejä merkittävästi.
Ensimmäinen askel on seurata varmistusten onnistumista aktiivisesti eikä vain luottaa oletuksiin.
Toinen askel on testata palautuksia säännöllisesti. Testi paljastaa yleensä enemmän kuin yksikään raportti.
Kolmanneksi kannattaa tarkistaa säännöllisesti, että kaikki uudet palvelut, tietokannat ja sovellukset kuuluvat varmistuksen piiriin. IT-ympäristöt muuttuvat jatkuvasti, eikä alkuperäinen suunnitelma välttämättä vastaa nykytilannetta.
Lisäksi on hyvä arvioida, kuinka nopeasti järjestelmät pitäisi saada takaisin käyttöön häiriötilanteessa. Ilman tätä tietoa on vaikea rakentaa oikeanlaista varmistusratkaisua.
Lopuksi
➠ Varmuuskopiointi näyttää usein yksinkertaiselta asialta, kunnes ensimmäinen todellinen palautustarve tulee vastaan.
➠ Silloin huomio siirtyy pois raporteista ja teknisistä lupauksista. Ratkaisevaa on, saadaanko tiedot takaisin käyttöön vai ei.
➠ Hallituissa IT-palveluissa varmistusten tärkein tehtävä ei ole tuottaa onnistuneita raportteja. Niiden tehtävä on palauttaa liiketoiminnan kannalta tärkeät tiedot silloin, kun jokin menee pieleen. Sen vuoksi varmuuskopiointia kannattaa tarkastella säännöllisesti käytännön palautuskyvyn, ei pelkästään teknisen toteutuksen näkökulmasta.