Aproape toate companiile fac copii de siguranță. Mult mai puține știu cât durează o restaurare completă, iar o parte descoperă în cel mai prost moment că nu se poate. Fișierele erau salvate, dar baza de date a fost copiată în timp ce scria și este inconsistentă. Sau copiile existau, dar se aflau pe același sistem de stocare care s-a defectat. Sau erau accesibile cu aceleași credențiale pe care le-a folosit atacatorul. Backupul are valoare doar în momentul restaurării, iar acela este singurul moment în care nu mai poate fi corectat.
Pornim de la cerințele reale
Discuția începe cu analiza impactului asupra activității, nu cu alegerea unui produs. Care sisteme opresc efectiv activitatea dacă devin indisponibile și după cât timp. Ce volum de date se poate pierde fără consecințe majore. Cât costă o zi de oprire, exprimat în bani, nu în termeni generali.
Din aceste răspunsuri rezultă RPO și RTO pentru fiecare sistem, stabilite diferențiat. Un ERP poate necesita recuperare în două ore și pierdere maximă de cincisprezece minute, în timp ce arhiva de documente suportă o zi întreagă. Aplicarea celei mai stricte cerințe la toate sistemele multiplică inutil costul, iar aplicarea celei mai permisive expune organizația exact acolo unde nu trebuie.
Cum construim protecția
Folosim regula 3-2-1-1: trei copii ale datelor, pe două tipuri diferite de suport, cu una în altă locație și cel puțin una imutabilă sau offline. Ultima condiție a devenit obligatorie odată cu atacurile care caută în mod deliberat infrastructura de backup înainte de criptare.
Separarea credențialelor este la fel de importantă ca separarea fizică. Sistemul de backup are conturi proprii, nu face parte din domeniul de producție, iar accesul la ștergerea copiilor este restricționat suplimentar. Dacă un administrator compromis poate șterge toate copiile, protecția este iluzorie.
Bazele de date le tratăm separat, cu instrumentele proprii fiecărui motor, pentru că o copiere la nivel de fișier a unei baze active produce frecvent date inconsistente, care par valide până la prima încercare de restaurare.
Testarea, partea care se omite
O copie nerestaurată niciodată este o presupunere, nu o măsură de protecție. Programăm restaurări periodice: verificări automate de integritate, restaurări lunare punctuale de fișiere și mașini virtuale, și un exercițiu anual complet în care recuperăm sistemele critice într-un mediu izolat și măsurăm timpul real până la funcționare.
Aceste exerciții descoperă aproape întotdeauna ceva. Un serviciu care depinde de o configurație aflată pe alt server, o licență legată de identificatorul echipamentului, o procedură care presupune acces la un sistem indisponibil în scenariul respectiv, sau un timp de restaurare de trei ori mai mare decât cel estimat. Este mult mai bine să afli acestea într-un test decât într-o situație reală.
Continuitatea activității
Planul de continuitate depășește partea tehnică. Cuprinde cine decide activarea, cum se comunică intern și către clienți, ce activități se desfășoară manual în perioada de indisponibilitate și cum se revine la starea normală după rezolvare. Include liste de contacte verificate, pentru că o listă cu numerele foștilor angajați nu ajută la ora trei dimineața.
Pentru organizațiile aflate sub incidența NIS2, gestionarea continuității și a crizelor este o cerință explicită, iar dovada testării planului este solicitată la audit. Documentăm fiecare exercițiu cu rezultate și cu acțiunile corective rezultate.
Pentru cine este potrivit
Serviciul se adresează companiilor pentru care oprirea sistemelor înseamnă pierderi directe, organizațiilor cu obligații de conformitate privind continuitatea și celor care au trecut printr-un incident și au constatat că recuperarea a durat mult mai mult decât se aștepta. Rezultatul este că întrebarea despre durata unei recuperări complete primește un răspuns bazat pe măsurători, nu pe estimări optimiste.