Kaikki kohisevat nyt Disaster Recoverysta, mutta mitä kaikkea toimivassa DR-ratkaisussa tulee ottaa huomioon? Tässä artikkelissa Alpit Nordicin Thomas Jaatinen ja Niko Virta kertovat, miten he rakentaisivat unelmiensa DR-ratkaisun, jos budjettirajoituksia ei olisi.
Viime vuosina ransomware-hyökkäyksien määrä on kasvanut valtavasti. Eikä kyberrikollisuus ole ainoa alati monimutkaistuvaan IT-infrastruktuuriin kohdistuva uhka. Yhtä lailla yrityksen liiketoiminnan voi pysäyttää laiterikko konesalissa tai väärässä paikassa tapahtuva inhimillinen virhe.
Ei ihme, että Disaster Recovery -ratkaisut ovat alkaneet kiinnostaa yrityksiä.
DR-ratkaisut täydentävät (mutta eivät korvaa) perinteisiä varmuuskopiointiratkaisuja mahdollistamalla liiketoimintakriittisten palvelujen nopean palauttamisen. DR-ratkaisujen avulla voidaan minimoida datan menetykset ja liiketoiminnan keskeytymisestä syntyvä vahinko, mutta toimiva, testattu ja turvallinen varmuuskopiointi on edelleen kaiken perusta.
Alpit Nordicin asiantuntijat kertovat oman näkemyksensä Disaster Recoverysta
Vaikka Disaster Recovery -ratkaisujen tunnettuus on parantunut viime vuosina, harva IT-päättäjä silti tietää, mitä niissä tulee ottaa huomioon.
Tässä artikkelissa Alpit Nordicin DR-asiantuntijat Thomas Jaatinen ja Niko Virta kertovat, millaisen Disaster Recovery -ratkaisun he rakentaisivat, jos heidän käytössään olisi rajaton budjetti.
Mistä muodostuu toimiva Disaster Recovery -ratkaisu?
DR-ratkaisun tarkoitus on turvata liiketoimintakriittinen osa IT-infrastruktuurista häiriöiden varalta. Ratkaisu toimii siten, että suojatun ympäristön toiminnan häiriintyessä, se voidaan palauttaa nopeasti käyttöön turvalokaatiosta käsin.
Palautumisaikatavoite (RTO eli Recovery Time Object) on yleensä muutamia minuutteja. Palautumispistetavoite (RPO eli Recovery Point Object) voi puolestaan olla vain sekunteja ennen katkosta.
Jaatinen ja Virta kertovat, että ihanteellisen Disaster Recovery -ratkaisun toteutus edellyttää suunnitelmallisuutta. He listaavat kuusi asiaa, joista onnistunut DR-toteutus muodostuu.
- Suojattava toiminnallisuus ja kaikki sen keskeiset riippuvuudet on tutkittu ja määritetty
- Uhkaskenaariot, joita vastaan suojaudutaan, on myös määritetty
- Turvalokaatio ja sen resurssien mitoitus on valittu siten, että sieltä käsin voidaan turvallisesti ajaa suojattuja työkuormia niin kauan kuin on tarve
- DR-toteutusta on testattava säännöllisesti, jotta sen toimivuudesta voidaan olla varmoja
- Uhkaskenaarioita varten tarvitaan pelikirja, joka sisältää selvät toimintaohjeet ja vastuunjaot eri tilanteisiin
- DR-toteutusta on kehitettävä jatkuvasti
Tehtävä: ”Unelmien Disaster Recovery”
Haastoimme Thomaksen ja Nikon suunnittelemaan unelmiensa Disaster Recovery -ratkaisun omassa konesalissa sijaitsevaan tuotantoympäristöön, jossa ajetaan liiketoimintakriittisiä työkuormia. Suunniteltavan ratkaisun tulee varmistaa nopea liiketoiminnan palautuminen kolmessa uhkaskenaariossa:
- Arkipäiväinen häiriötilanne – laiterikko, inhimillinen virhe tai muu korjaustoimenpiteitä vaativa häiriö
- Ransomware-hyökkäys
- Fyysinen katastrofi tai uhka – tulipalo, vesivahinko tai geopoliittinen kriisi
Suojattavan kokonaisuuden laajuus tulee tunnistaa
Useimmat järjestelmät tarvitsevat toimiakseen yhteyksiä muihin palveluihin. Tämä tulee huomioida myös DR-ratkaisussa.
Jos turvattava ympäristö on esimerkiksi työntekijöiden käyttämä tietojärjestelmä tai loppuasiakkaille suunnattu palvelu, on varsinaisen järjestelmän tai palvelun lisäksi kyettävä palauttamaan sen toiminnan edellyttämät muut palvelut. Tällaisia ovat tyypillisesti esimerkiksi web- ja tietokantapalvelimet.
”Riippuvuuksien selvittämisen tärkeyttä ei voi ylikorostaa. On tiedettävä tarkkaan, mitä kaikkea on suojattava, jotta onnistunut palautus olisi mahdollinen. Yleensä se tarkoittaa tarkkaa suunnittelua ja paljon testausta siihen päälle”, Jaatinen kertoo.
Mihin suojattava kokonaisuus sijoitetaan?
DR-ratkaisut perustuvat siihen, että ensisijainen ympäristö kahdennetaan reaaliajassa turvalliseen sijaintiin, josta se voidaan tarvittaessa ottaa käyttöön. Turvalokaation sijainnin valintaan vaikuttavat esimerkiksi saavutettavuus, regulaatio ja turvallisuus.
”Ilman budjettirajoituksia valitsisin palautuksen sijainniksi vain omaan käyttööni varatut resurssit jonkun toisen ylläpitämästä konesalista. Konesalin itsessään tulee täyttää vaaditut turvallisuusvaatimukset, ja vain minulla saisi olla pääsy laitteisiin”, Jaatinen sanoo.
”Turvalokaation maantieteellinen sijainti olisi ihanteellisesti alle 100 kilometrin päässä alkuperäisestä, ellei jokin uhkaskenaario edellytä pidempää välimatkaa – ja jos mahdollista, valitsisin maan alla sijaitsevan konesalin”, Virta jatkaa.
Disaster Recovery -työkalun valinta ja turvalokaatioon sijoitettujen laitteiden mitoitus
DR-ratkaisun toteutus edellyttää lisäksi softaa, jolla kahdentaminen tehdään. Myös turvalokaatioon sijoitettujen resurssien mitoitusta tulee miettiä.
”Työkaluksi valitsen Zerton, josta olemme kirjoittaneet jo aiemmin. Koska budjettirajoitusta ei ole, mitoittaisin turvalokaatioon yhtä paljon kapasiteettia kuin alkuperäiseenkin. Näin varmistamme, että laskentateho ja muisti riittävät, ja että vikasietoisuus on huomioitu myös siellä”, Jaatinen kertoo.
”Riittävä mitoitus on ratkaisevaa, jos aikoo varautua siihen, että työkuormia joudutaan ajamaan pitkään turvalokaatiosta käsin”, Virta muistuttaa.
Verkkoyhteyksien turvaaminen kaikissa uhkaskenaarioissa
Oman ulottuvuutensa muodostaa ensisijaisen ympäristön ja turvalokaation välinen verkkoyhteys. Suorituskykyinen verkkoyhteys nopeuttaa useimmista uhkaskenaarioista palautumista.
”Valitsisin kahdennetun 10 Gb Layer2-yhteyden. Tämä siksi, että haluamme päästä käsiksi palautettaviin työkuormiin mahdollisimman nopeasti. Layer2-yhteys antaa meille siihen hyvät edellytykset”, Jaatinen sanoo.
Virta muistuttaa, että fyysiseen verkkoyhteyteen perustuva ratkaisu ei kuitenkaan ole riittävä kaikissa tilanteissa. Uhkaskenaario 3:ssa koko ensisijainen konesali on uhattuna – myös verkkolaitteet ja -yhteydet.
”Tähän varautuisin siten, että ottaisin fyysisten palomuurien sijasta käyttöön virtuaaliset palomuurit ja reitityspisteet. Replikoimalla verkko tällä tavalla varmennettaisiin palautuminen myös tilanteessa, jossa alkuperäinen konesali on saavuttamattomissa.”
Selkeä pelikirja selkeyttää toimintaa kriisitilanteissa
Tehokas toiminta kriisitilanteessa on mahdollista vain, jos se nojaa selkeään suunnitelmaan ja vastuunjakoon. Erilaisia uhkaskenaarioita vastaavat toimintamallit on hyvä dokumentoida pelikirjaan, jotta palautuminen kriisistä hoituu mahdollisimman nopeasti.
”Pelikirjaan on oltava kirjattuna toimintaohjeet kaikkiin kuviteltavissa oleviin skenaarioihin”, Jaatinen tiivistää.
Pelikirja ottaa kantaa onnistuneen palautumisen kannalta olennaisiin kysymyksiin
Pelikirjassa on muun muassa otettava huomioon, miten varmistetaan käyttäjien pääsy turvalokaatioon siirrettyyn palveluun.
Annetussa tehtävässä ei ole määritelty tarkemmin, onko kyse työntekijöiden käyttöön tarkoitetusta tietojärjestelmästä vai ulkoisille käyttäjille suunnatusta palvelusta. Miten toimintaohjeet eroaisivat näiden osalta?
”Jos yhteydet ovat kokonaan poikki, ja turvattu palvelu on työntekijöiden käytössä oleva tietojärjestelmä, voi toimintaohjeeksi riittää kehotus ottaa VPN-yhteys turvalokaatioon”, Jaatinen kertoo.
Mutta jos turvattavaa palvelua käyttävätkin loppuasiakkaat, on tilanne hieman eri.
”Jos kyse on puolestaan esimerkiksi verkkokaupasta, jolla on asiakkaita ympäri maailman, ei VPN-ratkaisu toimi. Silloin on järjestettävä liikenteen uudelleenohjaus turvalokaatioon verkko-operaattorin kautta.”
Toimiva ratkaisu edellyttää säännöllistä testausta ja jatkuvaa kehitystä
Disaster Recovery on monimutkainen kokonaisuus. Kaikkia liiketoimintakriittisen järjestelmän riippuvuuksia voi olla haastavaa tunnistaa ajamatta useita testejä. Suojattavat ympäristöt myös muuttuvat ja kehittyvät jatkuvasti, minkä on heijastuttava myös turvalokaatioon.
”Johdonmukainen prosessi, johon sisältyy säännöllinen testaus ja jatkuva kehitys, on ihan ehdoton osa toimivaa Disaster Recoverya. Koko homman ideana on turvata liiketoiminnan jatkuvuus, joten tekemistä ei voi jättää puolitiehen ja huomata sitten tilanteen ollessa päällä, ettei tämä toiminutkaan,” Virta toteaa.
Alpit Nordicilta Disaster Recovery palveluna
Disaster Recovery -ratkaisut ovat tulleet jäädäkseen. Lähes kaikkien yritysten kriittiset liiketoimintaprosessit ovat tänä päivänä sidoksissa johonkin digitaaliseen palveluun, ja siksi niiden turvaaminen on välttämätöntä. Palautumissuunnitelma verkkorikoksen varalta on myös yksi NIS2-direktiivin vaatimuksista.
Vaikka yrityksellä olisi rahaa loputtomasti, ihmisresursseja ja aikaa sillä ei silti yleensä ole rajattomasti. Siksi myös Disaster Recovery -toteutuksissa kannattaa harkita palvelukumppanin apua.
”Alpit Nordicin palvelumalli kattaa kaikki vaiheet suunnittelusta säännölliseen testaukseen ja jatkuvaan kehitykseen. Me laadimme myös pelikirjan uhkaskenaarioita varten yhdessä asiakkaan kanssa ja hoidamme asiakkaan puolesta myös varsinaisen katastrofista palautumisen.”
Thomas Jaatinen
”Olen ollut alalla 17 vuotta, ja siitä suurimman osan olen työskennellyt infrastruktuurin parissa. Alpitilla olen erikoistunut datan suojaamiseen ja virtualisointiratkaisuihin. Teen arkkitehtuuritason suunnittelua, mutta en ole suostunut myöskään kokonaan luopumaan ruuvimeisseli kädessä työskentelystä.”
Niko Virta
”Toimin Alpit Nordicin Chief Technology Officerina, mutta teen sen lisäksi myös asiakastöitä. Olen ollut alalla 21 vuotta ja pääasiassa infrapuolen tehtävissä – ensin asiakkaana ja ostajana, kunnes 2008 siirryin toiselle puolelle pöytää. Suhtaudun intohimolla arkkitehtuurikysymyksiin ja Disaster Recoveryyn.”