Varmuuskopio kelpaa vasta, kun olet myös testannut, että voit palauttaa sen avulla — ei pelkästään sitä, onko tiedosto olemassa, vaan sitä, palautuvatko lähdekoodi, kehitysputki ja niihin liittyvät salaisuudet toimintakuntoon häiriötapahtuman jälkeen. Ohjistokehityksessä ei ole kyse pelkästään repositoriosta, jonka voit palauttaa, vaan koko ketjusta: versioiden hallinnasta, kääntöpalvelimista, putkista, testausympäristöistä ja niihin liittyvistä avaimista ja tokeneista. Ilman testattua palautustoimenpidettä tiedät vasta häiriötapahtuman aikana, toimiiko se, ja se on vähin hetkellä selville saamiselle.
NIS2-huolenpitovelvoite mainitsee jatkuvuuden ja palautuksen nimenomaisesti yhtenä artiklan 21 kymmenen toimenpiteestä. Direktiivi ei määrää kiinteää testaustiheyttä eikä konkreettia muotoa — kukin organisaatio täyttää sen omalla tavallaan, ja maakohtainen täytäntöönpano voi tuoda siihen omia painotuksia. Se, mikä toistuu aina, ostajien kyselyissä ja siinä, mitä valvontaviranomaiset pitävät järkevänä, on ero varmuuskopion omistamisen ja varmuuskopion palauttamisen välillä, kun tiedät, että tulos toimii.
Mitä "testattu" tarkalleen ottaen tarkoittaa
Testaus ei ole sama kuin vihreä rasti varmuuskopiointiohjelmistossa. Testattu tarkoittaa, että joku on todella palauttanut varmuuskopion erilliseen ympäristöön, tarkistanut, kääntyykö koodi, onnistuuko kääntö ja toimiiko sovellus odotetulla tavalla. Vasta sitten tiedät, onko palautushetki käytettävä ja kuinka kauan se kestää. Varmuuskopio, joka luodaan mutta jota ei koskaan palauteta, on käytännössä oletus palautuksesta, ei todistettu palautus.
Mitä tarkasti ottaen palautat kehitysputkessa
Ohjistokehityksessä lähdekoodi on harvoin ainoa asia, jonka voit menettää. Ajattele CI/CD-putken konfiguraatiota, kääntyöskriptejä, ulkoisten pakettien riippuvuuksia, pääsyavaimia rekistereihin ja pilvialueisiin sekä itse versioiden hallintajärjestelmän historiaa. Palautussuunnitelma, joka kattaa vain koodin mutta ei putkea tai salaisuuksia, jättää organisaation häiriötapahtuman jälkeenkin pysäytettäväksi. Siksi on järkevää määritellä jokaiselle näistä osista erikseen: missä varmuuskopio sijaitsee, kuka voi sen palauttaa, ja onko sitä koskaan harjoiteltu.
Kuinka usein testaaminen on kohtuullista
Direktiivissä ei ole määrätty, kuinka usein palautustestaus tulee suorittaa. Se, mitä käytännössä pidetään järkevänä, riippuu siitä, kuinka usein ympäristö muuttuu: kehitysputki, joka vaihtaa putken konfiguraatiota viikoittain, vaatii useampia testejä kuin vakaa ympäristö, joka pysyy muuttumattomana kuukausia. Monet organisaatiot valitsevat kiinteän kalenterihetken — esimerkiksi joka neljännesvuosi — yhdessä testin kanssa jokaisen suuren infrastruktuurin muutoksen jälkeen. Tärkeämpää kuin tiheys on se, että hetki on ollut olemassa, ja voit osoittaa, milloin.
Mitä kirjaat ylös todisteeksi
Ostaja, joka lähettää tietoturvakyselyn, harvoin kysyy varmuuskopiointisi teknologiasta. Kysymys on yleensä yksinkertaisempi: milloin se testattiin viimeksi, kuka sen testasi ja mikä tulos oli. Vastauksen antamiseksi riittää kolme asiaa kirjata: viimeisen palautustestin päivämäärä, kuka testin suoritti ja mikä osa palautettiin — koodi, putki, salaisuudet vai kaikki kolme. Ilman tätä kirjausta kyselylomakkeen vastaus pysyy muistona kirjoitettavaa todisteen sijaan, ja juuri se on ero, jonka toisen puolen arvioija haluaa nähdä.
Yhteys dossier-asiakirjan muuhun osaan
Varmuuskopiointi ja palautus harvoin seisovat erillään. Palautusmenettelyn suorittamisoikeus liittyy pääsyn valvontaan kehityslinjoille; mitä meni pieleen käyttökatkoksen aikana, kuuluu samaan poikkeamarekisteriin, jota käytetään myös muiden riskienhallintamenettelyjen osalta. Tällaisen asiakirjapaketin perustaminen ei tarvitse olla erillinen hanke: kymmenen riskienhallintamenettelyä eriteltyinä tilanteen mukaan osoittaa, mihin varmuuskopiointi ja palautus täsmälleen sopivat kokonaisuuteen ja mitkä muut riskienhallintamenettelyt vaikuttavat niihin suoraan.
Se, ovatko varmuuskopiointi ja palautus huoltovelvollisuuden riskienhallintamenettely organisaatiossanne, riippuu siitä, oletko itse NIS2:n soveltamisalalla vai saatko tämän kysymyksen asettajalta, joka on. muutamassa kysymyksessä näet, missä olet antaa siitä ensimmäisen osoituksen selityksineen. Kuinka päätyimme tähän osoitukseen ja mitkä lähteet siihen perustuvat, on selvitetty sivulla, joka käsittelee toimintatapojamme.
Varmuuskopio, jota ei ole koskaan palautettu, ei ole takuu — se on kysymys, joka odottaa vastausta. Haluaisitko tietää, onko ja miten tämä riskienhallintamenettely merkityksellinen organisaatiollesi, ja mitä muuta siihen liittyy? Tee ilmainen nopea arvio tai selaa useimmin esitettyjä kysymyksiä NIS2:sta niiden kysymysten osalta, jotka muut yrittäjät ovat jo esittäneet.