Egy biztonsági másolat csak akkor számít, ha azt is tesztelte, hogy képes-e azzal helyreállítani — nem csak azt, hogy a fájl ott van-e, hanem azt, hogy a forráskód, a fejlesztési folyamat és a kapcsolódó titkok az incidens után újra működőképesen visszatérnek-e. A szoftverfejlesztésben nem csupán egy helyreállítható adattárról van szó, hanem egy teljes láncról: verziókezelés, build-szerverek, pipeline-ok, tesztkörnyezetek és a hozzájuk tartozó kulcsok és tokenek. Tesztelt helyreállítási eljárás nélkül csak az incidens alatt tudja meg, hogy működik-e, és ez a legrosszabb pillanat a megtudásra.
A NIS2 gondossági kötelezettség explicit módon említi a kontinuitást és a helyreállítást az 21. cikk tíz intézkedésének részeként. Az irányelv nem írja elő a rögzített tesztgyakoriságot és konkrét formát sem — ezt minden szervezet saját maga tölti ki, és az ország-specifikus átültetés saját hangsúlyokat adhat ahhoz. Amit azonban mindig visszatér, a felhasználók kérdőíveben és abban, amit a felügyeleti hatóságok helyesnek tartanak, az az a biztonsági másolat és egy helyreálított, működőnek ismert biztonsági másolat közötti különbség.
Mit jelent pontosan a 'tesztelt'
A teszt nem ugyanaz, mint egy zöld pipa a biztonsági másolat szoftverében. Tesztelt azt jelenti, hogy valaki a biztonsági másolatot ténylegesen helyreállította egy külön környezetben, ellenőrizte, hogy a kód lefordul-e, a build sikeres-e, és az alkalmazás az elvárt módon működik-e. Csak akkor tudja, hogy a helyreállítási pont használható-e és mennyi időbe telik. Egy biztonsági másolat, amely készül, de soha nem kerül helyreállításra, a gyakorlatban egy feltevés a helyreállításról, nem pedig egy bizonyított helyreállítás.
Mit állít helyreálló konkréten a fejlesztési folyamatban
A szoftverfejlesztésben az forráskód ritkán az egyetlen dolog, amit elveszíthet. Gondoljon a CI/CD-pipeline konfigurációjára, az összeállítási szkriptekre, a külső csomagok függőségeire, a registries és felhőkörnyezetek hozzáférési kulcsaira, valamint magában a verziókezelő rendszerben lévő előzményre. Egy helyreállítási terv, amely csak a kódot kezeli, de nem a pipelineot vagy a titkokat, egy szervezetet egy incidens után még mindig működésképtelenül hagyja. Ezért célszerű az egyes komponensekre külön-külön meghatározni: hol van a biztonsági mentés, ki tudja azt helyreállítani, és ezt valaha gyakorolták-e már.
Milyen gyakran szükséges tesztelni
Az irányelvben nincs rögzített határidő arra vonatkozóan, hogy milyen gyakran kell helyreállítási tesztet végeznie. Amit a gyakorlatban ésszerűnek tartanak, az attól függ, hogy milyen gyakran változik a környezet: egy fejlesztési folyamat, amely hetente módosítja a pipeline-konfigurációt, gyakoribb tesztelést igényel, mint egy stabil környezet, amely hónapokig változatlan marad. Sok szervezet egy rögzített naptári ritmus mellett dönt — például negyedévenként — és tesztel minden nagyobb infrastruktúra-módosítás után. Fontosabb, mint a gyakoriság, hogy egyáltalán volt egy olyan pillanat, és ki tudja jelölni, hogy mikor.
Mit rögzít bizonyítékként
Az a felek, amelyek biztonsági kérdőívet küld, ritkán érdeklődik a biztonsági mentés mögötti technika iránt. A kérdés általában egyszerűbb: mikor tesztelték ezt utoljára, ki végezte, és mi volt az eredmény. Ehhez a válaszhoz elegendő három dolog rögzítése: az utolsó helyreállítási teszt dátuma, aki elvégezte a tesztet, valamint mely komponens került helyreállításra — kód, pipeline, titkok, vagy mindhárom. Ennek a rögzítésnek a hiányában a kérdőívre adott válasz csak egy emlékezet marad ahelyett, hogy bizonyíték lenne, és ez pontosan az a különbség, amely az értékelőnek az asztal másik oldalán szeretne látni.
Az összekacsolódás a dossié többi részével
A biztonsági mentés és a helyreállítás ritkán működnek önmagukban. Az, hogy ki végezheti el a helyreállítási eljárást, az adatkezelés során a fejlesztési folyamathoz való hozzáféréssel függ össze; amit egy meghibásodás során elrontottak, az ugyanabban az incidensregisztrációban szerepel, amelyet a többi intézkedéshez is használnak. Egy ilyen dossziét összeállítani nem szükséges külön projektként kezelni: a tíz intézkedés szétbontva helyzet szerint megmutatja, hogy a biztonsági mentés és a helyreállítás pontosan hol helyezkednek el az egészben, és mely más intézkedések érintik közvetlenül azokat.
Hogy a biztonsági mentés és a helyreállítás az Ön szervezete számára kötelezően előírt intézkedésnek minősülnek-e, attól függ, hogy Ön közvetlenül a NIS2 hatálya alá tartozik-e, vagy ezt a kérdést egy olyan megrendelőtől kapja, amely igen. néhány kérdésben megtudhatja, hol tart ennek egy első jelzésével szolgál, magyarázattal ellátva. Hogyan jutunk el a jelzéshez, és mely forrásokra alapozunk, az részletezve van a munkafolyamatunkról szóló oldalon.
Egy biztonsági mentés, amelyet még sohasem állítottak vissza, nem garancia — ez egy kérdés, amely választásra vár. Szeretné tudni, hogy ez az intézkedés releváns-e az Ön szervezete számára, és milyen más dolgok tartoznak még ehhez? Végezze el a ingyenes gyorsértékelést, vagy böngésze végig a NIS2-ről leggyakrabban feltett kérdéseket azon kérdésekért, amelyeket más vállalkozók már feltettek.