O copie de siguranță contează doar dacă ați testat și că puteți recupera cu ajutorul acesteia — nu doar dacă fișierul este acolo, ci dacă codul sursă, linia de dezvoltare și secretele asociate revvin în stare de funcționare după un incident. În dezvoltarea software, nu este vorba doar despre un depozit pe care îl puteți restaura, ci despre un lanț întreg: controlul versiunilor, servere de compilare, conductele de livrare, medii de testare și cheile și jetonurile care aparțin acestora. Fără o procedură de recuperare testată, voi aflaţi abia în timpul unui incident dacă funcționează, iar acesta este cel mai prost moment pentru a o descoperi.
Obligația de îngrijire NIS2 menționează în mod explicit continuitatea și recuperarea ca parte a celor zece măsuri din articolul 21. Directiva nu prescrie o frecvență de testare fixă și nici o formă concretă — aceasta se completează în funcție de organizație, iar transpunerea specifică fiecărei țări poate aduce accentele sale proprii. Ceea ce revine constant, în chestionarele clienților și în ceea ce autoritățile de supraveghere consideră rezonabil, este distincția între a avea o copie de siguranță și a avea o copie de siguranță pe care ați restaurat-o și de care știți că rezultatul funcționează.
Ce înseamnă exact „testat
O testare nu este același lucru cu o bifă verde în software-ul de backup. Testat înseamnă că cineva a restaurat efectiv backup-ul într-un mediu separat, a verificat dacă codul se compilează, dacă build-ul reușește și dacă aplicația funcționează conform așteptărilor. Numai atunci știți dacă punctul de recuperare este utilizabil și cât timp necesită. Un backup care este creat dar niciodată restaurat este în practică o presupunere despre recuperare, nu o recuperare dovedită.
Ce restaurați concret în fluxul de dezvoltare
În dezvoltarea de software, codul sursă este rar singurul lucru pe care îl puteți pierde. Gândiți-vă la configurația pipeline-ului CI/CD, scripturile de compilare, dependențele de pachete externe, cheile de acces pentru registre și medii cloud, și istoricul din sistemul de control de versiuni în sine. Un plan de recuperare care acoperă doar codul, dar nu pipeline-ul sau secretele, lasă o organizație blocată și după un incident. De aceea, este util să determinați pentru fiecare dintre aceste componente în parte: unde se află copia de siguranță, cine o poate restaura, și dacă aceasta a fost vreodată testată.
Cât de des este rezonabil să testați
Nu există un termen fix în directivă pentru cât de des trebuie să efectuați un test de recuperare. Ceea ce se consideră rezonabil în practică depinde de cât de des se schimbă mediul: o autostradă de dezvoltare care schimbă configurația pipeline-ului săptămânal necesită teste mai frecvente decât un mediu stabil care rămâne neschimbat timp de luni. Multe organizații aleg un moment calendaristic fix — de exemplu, în fiecare trimestru — combinat cu un test după fiecare schimbare majoră a infrastructurii. Mai important decât frecvență este faptul că a existat o dată vreun moment, și că puteți indica când.
Ce consemnați ca dovadă
Un cumparator care trimite un chestionar de securitate rar întreabă despre tehnica din spatele copiei dumneavoastră de siguranță. Întrebarea este de obicei mai simplă: când a fost testat aceasta ultima dată, de cine, și care a fost rezultatul. Pentru acel răspuns, este suficient să consemnați trei lucruri: data ultimului test de recuperare, cine a efectuat testul, și ce componentă a fost restaurată — cod, pipeline, secrete, sau toate trei. Fără acea consemnare, răspunsul la chestionarul rămâne o amintire în loc de dovadă, și aceasta este exact diferența pe care un evaluator de cealaltă parte a mesei vrea să o vadă.
Relația cu restul dosarului
Copia de siguranță și recuperarea rar stau singure. Cine are permisiunea să efectueze procedura de recuperare depinde de controlul accesului la linia de dezvoltare; ceea ce a mers prost în timpul unei defecțiuni aparține în același registru de incidente care se ține și pentru alte măsuri. Configurarea unui astfel de dosar nu trebuie să fie un proiect separat: cele zece măsuri defalcate pe situație arată exact unde se încadrează copia de siguranță și recuperarea în ansamblu, și care alte măsuri au o legătură directă cu acestea.
Dacă copia de siguranță și recuperarea se constituie ca măsură de diligență pentru organizația dumneavoastră depinde de faptul că sunteți dumneavoastră sub NIS2 sau că primești această întrebare printr-un ordonator care se află sub NIS2. în câteva întrebări vedeți unde vă aflați oferă o primă indicație în acest sens, cu explicații cu privire la motivul pentru care. Cum ajungem la acea indicație și care sunt sursele care o fundamentează este explicat pe pagina cu privire la metodologia noastră.
O copie de siguranță care nu a fost niciodată restabilită nu este o garanție — este o întrebare care așteaptă un răspuns. Doriți să știți dacă și cum este relevantă această măsură pentru organizația dumneavoastră, și ce altceva este inclus în acest context? Efectuați scanarea rapidă gratuită sau răsfoiți întrebările cel mai des puse despre NIS2 pentru întrebările pe care alți antreprenori le-au pus deja.