În multe discuții despre ransomware, accentul cade pe copii offline, imutabile și pe testele de restaurare. Toate sunt esențiale. Dar există un punct mai puțin vizibil care poate face diferența într-un incident: inventarul backupurilor. Dacă aceeași persoană, aceeași consolă sau același set de drepturi poate modifica și datele de backup, și evidența lor, atunci o organizație poate descoperi prea târziu că “avea copii” doar pe hârtie.
Pe scurt, Backup Catalog Integrity înseamnă să poți demonstra că lista backupurilor, a punctelor de restaurare și a politicilor de retenție nu a fost alterată odată cu depozitul protejat. CISA recomandă păstrarea backupurilor offline sau izolate, testarea regulată a disponibilității și integrității lor și folosirea protecțiilor de tip object lock sau delete protection acolo unde este cazul. În aceeași logică, catalogul backupurilor nu ar trebui lăsat în același loc și sub aceleași permisiuni ca datele pe care le descrie.
Primul pas util este separarea inventarului de depozitul principal. Asta nu înseamnă neapărat schimbarea platformei, ci schimbarea controlului. Exportă periodic lista joburilor, a seturilor protejate, a ultimelor rulări și a punctelor de restaurare într-un registru separat, cu acces mai restrâns decât infrastructura de backup. Ideal, acest registru ajunge într-un spațiu imutabil sau într-un depozit unde modificările rămân auditate și nu pot fi șterse discret.
Al doilea pas este verificarea periodică a diferențelor, nu doar existența unui export. Dacă luni ai 120 de puncte de restaurare și vineri apar 97 fără o explicație documentată, acesta este un semnal de risc. Verificarea ar trebui să urmărească măcar patru lucruri: copii dispărute, politici de retenție reduse, sisteme scoase din protecție și modificări de permisiuni pentru administratorii platformei de backup. Microsoft explică pentru Azure Backup că un vault imutabil, mai ales în starea enabled and locked, blochează operațiunile care pot duce la pierderea punctelor de recuperare și poate folosi stocare WORM pentru a împiedica ștergerea sau dezactivarea protecției.
Un al treilea control important este dovada de integritate. Nu e suficient să ai un CSV exportat automat dacă el poate fi rescris oricând. O variantă mai sigură este să păstrezi fiecare export cu dată clară, să-i aplici o sumă de control sau o semnătură și să trimiți rezultatul într-un loc separat de echipa care administrează backupurile zilnic. Scopul nu este birocrația, ci posibilitatea de a compara rapid “ce exista atunci” cu “ce mai există acum”, fără să depinzi exclusiv de consola care ar fi putut fi deja compromisă.
Mai departe, separarea rolurilor contează mai mult decât pare. CISA insistă și pe principiul least privilege, tocmai pentru că atacatorii folosesc frecvent conturi privilegiate pentru a șterge copii, shadow copies sau alte mecanisme de recuperare. În practică, asta înseamnă ca persoana care poate șterge backupuri să nu fie aceeași care poate modifica jurnalul de audit, iar aprobările pentru schimbări sensibile să lase urme verificabile.
Nu trebuie ignorată nici partea de testare reală. Un control lunar sau trimestrial ar trebui să includă nu doar restaurarea unui fișier, ci și reconcilierea dintre inventar și realitate: ce backupuri apar în catalog, ce backupuri există efectiv în depozit, ce copii sunt imutabile, ce alerte au apărut pentru retenție redusă sau ștergeri și dacă există sisteme critice care au ieșit din rotația normală fără tichet sau aprobare. Dacă aceste verificări există doar informal, riscul rămâne mare.
Pentru firmele mici și medii, regula practică este simplă: păstrează backupurile separate de producție, păstrează evidența backupurilor separată de backupuri, blochează pe cât posibil ștergerea sau scurtarea retenției și compară periodic inventarul istoric cu starea curentă. Ransomware-ul nu vizează doar datele active, ci și capacitatea ta de a dovedi că poți reveni după incident. Iar când inventarul backupurilor devine la rândul lui protejat, șansele de recuperare cresc semnificativ.
