Muut dokumentit

10.3.2020

Vakuutukset ja varmistaminen

Perinteisesti varmistamista on verrattu vakuuttamiseen. Niiden on oltava kunnossa, mutta toivottavasti niitä ei jouduta hyödyntämään. Yritykset kuitenkin varautuvat riskeihin myös vakuuttamalla toimintojaan. Monissa vakuutuksissa on mainittu varmuuskopioinnin vaatimukset osana korvauskäytäntöä. Perinteisesti kun suunnitellaan yrityksen varmistuskäytäntöjä, niitä ohjaavat toiminnan sanelemat palautusaikavaatimukset (RTO) ja palautushetkivaatimukset (RPO). Mutta kuinka moni on ottanut huomioon yrityksen vakuutusten vaatimukset?

Otan esimerkiksi erään vakuutusyhtiön tarjoaman vastuuvakuutuksen;

”Vakuutusturva on voimassa mikäli tiedot, tiedostot ja ohjelmat ovat varmistettu ja suojeluohjeiden kohdan Varmuuskopiointi vaatimukset täyttyvät.”

 “Yleisten sopimusehtojen mukaan korvausta voidaan alentaa tai se voidaan evätä, jos vakuutuksenottaja tai muu korvaukseen oikeutettu on tahallisesti tai huolimattomuudesta, jota ei voida pitää vähäisenä, laiminlyönyt suojeluohjeiden noudattamisen.”

Mitkä ne varmuuskopioinnin vaatimukset ovat?

Varmuuskopiointi

 Tietojärjestelmien muuttuneista tiedoista on otettava varmuuskopiot päivittäin. Varmuuskopiot on säilytettävä lukitussa dataturvakaapissa, joka antaa datamateriaalille vähintään 60 minuutin suojan palovahinkoja vastaan.

Täysvarmistus (käyttöjärjestelmän ja -ympäristön, ohjelmistojen ja tietojen varmuuskopiointi) on tehtävä vähintään kerran viikossa. Ohjelmistot on varmuuskopioitava myös muutosten yhteydessä. Täysvarmistukset ja ohjelmistojen varmuuskopiot on säilytettävä lukitussa dataturvakaapissa tai vastaavassa lukitussa kaapissa, joka on eri palo-osastossa kuin tietojärjestelmän laitteet. Dataturvakaapin tai vastaavan kaapin on annettava vähintään 60 minuutin suoja palovahinkoja vastaan.

Jokaiselle viikonpäivälle ja kuukauden jokaiselle viikolle on varattava oma tiedon säilytykseen tarkoitettu nauha tai vastaava tietoväline varmuuskopiointia varten.

Varmuuskopioinnin onnistuminen ja tietojen palauttaminen varmuuskopioilta on testattava säännöllisesti.

Jos tietojärjestelmien käyttöpalvelu on ulkoistettu, on varmistettava, että palvelun tuottaja noudattaa vähintään edellä mainittuja vaatimuksia. Tietojen varmistamisesta on sovittava osana palvelusopimusta.”

Lisäksi suojeluohjeissa on määritelty

”Uudet tai muutetut ohjelmat, sovellukset ja järjestelmät pitää testata alalla yleisesti hyväksytyllä tavalla ennen kuin niitä käytetään varsinaisessa ICT-tuotannossa. Testauksissa on käytettävä tuotantotiedoista erillisiä taustatietoja.”

 

Vaatimukset vs yleiset käytännöt

Tarkastellaanpa näitä vaatimuksia yksi kerrallaan.

”Tietojärjestelmien muuttuneista tiedoista on otettava varmuuskopiot päivittäin”

Tämä yleensä toteutuu, toisinaan on kuitenkin ympäristöjä, joiden varmistus kestää jopa kauemmin kuin 24h. Todellisuudessa tuollaisessa tilanteessa pitäisi löytää parempi ratkaisu, koska yleensä myöskään RPO/RTO tarpeet eivät tällöin toteudu.

 

”Varmuuskopiot on säilytettävä lukitussa dataturvakaapissa, joka antaa datamateriaalille vähintään 60 minuutin suojan palovahinkoja vastaan.”

Tässä käytäntö ei kohtaa vaatimusta yleisesti käytössä olevissa ratkaisuissa. Varmistusmedia on ehkä levyjärjestelmä, de-duplikoiva laitteisto tai pilvi. Ainoa tapa saavuttaa tämä vaatimus on tallentaa tai kopioida varmistus siirrettävälle medialle, esimerkiksi LTO-nauhalle ja tallettaa se paloturvakaappiin. Usein tällainen varmistusjärjestelmä on mitoitettu sen mukaan, että de-duplikointi pienentää tarvittavan siirrettävän tiedon määrää. Kuinka moni de-duplikoiva järjestelmä osaa tehdä de-duplikoidun siirrettävän median? Entä kuinka käyttökelpoinen se on, jos se sisältää vain muuttuneet tiedot? Onko de-duplikoiva järjestelmä riittävän suorituskykyinen, jos kaikki tieto on avattava ja kirjoitettava siirrettävälle medialle päivittäin? Kuinka moni oikeasti tekee näin? Suurin osa nauhoja käyttävistä ratkaisuista perustuu nauhakirjaston sijoittamiseen eri palotilaan kuin tuotantoympäristöt.

 

”Täysvarmistus (käyttöjärjestelmän ja -ympäristön, ohjelmistojen ja tietojen varmuuskopiointi) on tehtävä vähintään kerran viikossa.”

Täysvarmistusten otto perinteisessä mielessä tehdään nykyään yleensä harvemmin kuin viikoittain. Osa varmistusjärjestelmistä tekee loogisen täysvarmistuksen hyödyntäen synteettistä täysvarmistusta tai muuta tapaa. Entä varmistusjärjestelmät, jotka toimivat progressive incremental -tyylisesti? Myös useassa tapauksessa varmistukset on kohdistettu vain tietojen varmuuskopiointiin ja luotettu, että käyttöjärjestelmä ja ohjelmistot asennetaan palautuksen hetkellä muilla keinoin.

 

”Täysvarmistukset ja ohjelmistojen varmuuskopiot on säilytettävä lukitussa dataturvakaapissa tai vastaavassa lukitussa kaapissa, joka on eri palo-osastossa kuin tietojärjestelmän laitteet. Dataturvakaapin tai vastaavan kaapin on annettava vähintään 60 minuutin suoja palovahinkoja vastaan.”

Täysvarmistuksilla siis on päivittäisiin varmistuksiin nähden kovennettu vaatimus — paloturvakaapin on sijaittava eri palo-osastossa. Kaapin on lisäksi oltava lukittu. Toisaalta jos käytössä on paloturvakaappi, niin en ole koskaan törmännyt sellaiseen samassa palotilassa kuin tietojärjestelmät.

 

”Jokaiselle viikonpäivälle ja kuukauden jokaiselle viikolle on varattava oma tiedon säilytykseen tarkoitettu nauha tai vastaava tietoväline varmuuskopiointia varten.”

Vaatimus, joka käytännössä rajaa pois käytöstä jaetut levypohjaiset de-duplikoivat järjestelmät ja pilvipalvelut. Toisaalta tämä ehkä myös kertoo varmistusten vähimmäistalletusajan, yksi kuukausi täysvarmistuksia ja viikko päivittäisiä? Jos media siirretään erilliseen paloturvakaappiin niin erillinen media jokaiselle päivälle syntyy loogisesti. Mutta kuten aiemmin mainittiin, yleensä varmistusjärjestelmät on rakennettu hyödyntäen esim. nauhakirjastoa joka on sijoitettu eri palotilaan. Kun nauhojen kapasiteetti (nyt käytännössä jopa 30 TB / media) jatkossa kasvaa, vaaditaan varmistussovellukselta ominaisuus, jossa aktiivinen nauha vaihdetaan päivittäin. Varmistusratkaisusta riippuu, voidaanko ko. median käyttämätöntä tyhjää tilaa hyödyntää jatkossa, jos halutaan tallentaa päivittäisiä varmistuksia vaikka kaksi tai neljä viikkoa.

 

”Varmuuskopioinnin onnistuminen ja tietojen palauttaminen varmuuskopioilta on testattava säännöllisesti.”

Erittäin hyvä vaatimus, mutta taas hieman avoin vaatimustasoltaan? Kuinka usein on säännöllisesti? Entä riittääkö, jos kokeillaan vain yksittäisen tiedoston / varmistuksen palauttaminen (pistokoe) vai pitääkö kokeilla kaikki? Mihin tasoon asti kokeilu pitää viedä? Riittääkö että raakadata on palautettavissa tiedostoiksi, vai onko tarpeen kokeilla, että sovellus on loogisesti palautettavissa haluttuun ajankohtaan. Nykyään kun suurin osa sovelluksista koostuu useasta eri palvelimesta ja tietokannasta.

 

”Jos tietojärjestelmien käyttöpalvelu on ulkoistettu, on varmistettava, että palvelun tuottaja noudattaa vähintään edellä mainittuja vaatimuksia. Tietojen varmistamisesta on sovittava osana palvelusopimusta.”

Alalla on yritetty siirtyä palvelutasojen kuvaamiseen (SLA), ottamatta kantaa teknisiin ratkaisuihin, joilla se on toteutettu. Nähtävästi vakuutuksen vaatimusten puolelta palveluntarjoajan on avattava käyttämäänsä ratkaisua paljon nykyistä enemmän.

 

”Uudet tai muutetut ohjelmat, sovellukset ja järjestelmät pitää testata alalla yleisesti hyväksytyllä tavalla ennen kuin niitä käytetään varsinaisessa ICT-tuotannossa. Testauksissa on käytettävä tuotantotiedoista erillisiä taustatietoja.”

Yleinen käytäntö liiketoimintakriittisissä sovelluksissa, mutta entä varmistusjärjestelmä? Kuinka monella on käytettävissään erillinen testausympäristö varmistusjärjestelmästä?

 

Loppupäätelmä

Kun jatkossa teet ratkaisua varmistusjärjestelmästä, muista keskustella myös yrityksen vakuutuksista vastaavien kanssa. Todennäköisesti tämän keskustelun jälkeen on avattava myös keskustelut vakuutusyhtiön kanssa ja ymmärrettävä molemmin puolin käytetyt käytännöt ja vaaditut toteutustavat.

MultiCom Software auttaa suunnittelemaan vaatimusten mukaisen varmistusjärjestelmän, toteuttaa sen avaimet käteen ja tarvittaessa operoi sitä palveluna.