Scenariul se repetă aproape identic. Cineva ajunge dimineața la birou, deschide un fișier și vede că nu se mai deschide. Nici următorul. Pe desktop apare un fișier text care explică politicos unde trebuie trimiși banii. Până la prânz e clar că serverul de fișiere e criptat în întregime, iar întrebarea care contează nu mai e cum au intrat, ci una singură: de unde recuperăm.
Aici se rupe totul. Nu la firewall, nu la antivirus. La backup — pentru că aproape toată lumea are unul, și foarte puțini știu dacă funcționează.
Regula 3-2-1 și motivul pentru care nu mai e suficientă
Regula clasică spune trei copii ale datelor, pe două tipuri diferite de suport, dintre care una în altă locație. E o regulă bună și are treizeci de ani.
Problema e că ransomware-ul modern nu se mai grăbește. Stă în rețea săptămâni întregi, se uită ce există, găsește serverul de backup, îi ia credențialele și abia apoi criptează — începând cu copiile de siguranță. Când ajunge la datele de producție, deja nu mai ai de unde reveni. Un NAS montat ca unitate de rețea, cu utilizator și parolă salvate, e la fel de vulnerabil ca fișierele pe care le protejează.
Cu alte cuvinte, trei copii nu înseamnă nimic dacă toate trei sunt accesibile de pe același domeniu, cu aceleași conturi.
Copia pe care nimeni nu o poate șterge
Diferența dintre a plăti răscumpărarea și a redeporni luni dimineață stă într-un singur cuvânt: imutabilitate.
O copie imutabilă e scrisă o dată și nu mai poate fi modificată sau ștearsă până la expirarea perioadei setate — nici de administrator, nici de cineva care i-a furat parola. Se poate obține pe hardware dedicat, pe stocare obiect cu blocare, sau pe bandă scoasă fizic din bibliotecă. Suportul contează mai puțin decât proprietatea în sine.
Regula 3-2-1 devine astfel 3-2-1-1-0: încă o copie imutabilă sau offline, și zero erori la verificarea restaurării. Detaliile de implementare, cu retenție și separarea conturilor, sunt explicate pe larg în ghidul despre backup și disaster recovery.
Testul pe care nu îl face aproape nimeni
Întreabă pe cineva dintr-o companie când s-a făcut ultima restaurare completă, de probă, cu cronometrul pornit. Răspunsul e, în cele mai multe cazuri, o pauză jenantă.
Un job de backup care se termină cu bifă verde nu dovedește nimic. Poate copia un fișier corupt la fel de bine ca unul valid. Poate sări peste bazele de date deschise. Poate salva de doi ani o partiție care nu mai există. Bifa verde arată că procesul a rulat, nu că datele se pot folosi.
Testul real înseamnă: iei o copie, o restaurezi într-un mediu izolat, pornești aplicația și verifici că datele sunt acolo și sunt corecte. O dată pe trimestru e rezonabil. O dată pe an e mai bine decât niciodată. Zero e cifra la care se află majoritatea.
Două numere pe care ar trebui să le știe și contabilul
Sunt singurele două cifre din tot subiectul care contează pentru cineva din afara IT-ului.
Primul: cât timp poate sta compania oprită fără să conteze cu adevărat. O zi? Patru ore? Douăzeci de minute? Răspunsul diferă enorm între o companie de distribuție și un cabinet care programează pacienți.
Al doilea: câte date își permite să piardă. Dacă backupul rulează o dată pe noapte, la ora 23, iar atacul vine la 16:30, ai pierdut o zi de muncă a tuturor. Uneori e acceptabil. De cele mai multe ori nimeni nu a calculat cât costă.
Din cele două numere rezultă tot restul: cât de des se face copia, unde stă, cât costă. Fără ele, discuția despre backup e o discuție despre produse.
Backupul din cloud nu e automat un backup
E cea mai răspândită confuzie din ultimii ani, și o au inclusiv oameni care lucrează în IT.
Microsoft 365 și Google Workspace garantează că serviciul funcționează și că datele nu se pierd dintr-o defecțiune de-a lor. Nu garantează că îți recuperează un folder de mail șters acum patru luni de cineva care avea drepturi, sau un site SharePoint pe care l-a criptat un cont compromis. Modelul se numește responsabilitate partajată: infrastructura e a lor, datele rămân ale tale.
Coșul de reciclare și retenția implicită acoperă zile sau săptămâni, nu ani. Iar un atacator care intră cu credențialele unui utilizator legitim are exact aceleași drepturi de ștergere ca utilizatorul respectiv. Dacă tot ce ai e retenția nativă, ai o fereastră scurtă și o singură șansă să observi la timp.
Aceeași logică se aplică oricărei aplicații SaaS în care ține compania date de care depinde: facturare, CRM, gestiune. Întrebarea de pus furnizorului nu e „faceți backup?”, ci „în cât timp îmi dați datele înapoi, în ce format, și cine plătește dacă nu puteți?”.
Cine ar trebui să dețină cheile
Un detaliu tehnic cu consecințe mari: dacă backupurile sunt criptate, unde stă cheia?
Într-o instalare făcută în grabă, cheia ajunge salvată pe același server care face copiile. Serverul cade sau e compromis, iar copiile devin un morman de fișiere pe care nu le mai deschide nimeni. Cheia trebuie să existe și în altă parte, într-un loc în care ajung două persoane, nu una — pentru că omul care știe parola pleacă în concediu exact în săptămâna în care ai nevoie de ea.
Ce s-a schimbat pentru companii în ultimii doi ani
Până recent, un incident de securitate era o problemă internă. Companiile din sectoarele acoperite de legislația europeană de securitate cibernetică, transpusă în România prin OUG 155/2024, au acum obligația să notifice autoritatea — prima notificare în 24 de ore de la identificarea incidentului semnificativ.
Asta schimbă calculul. O companie care nu poate spune ce date au fost afectate, de când, și de unde le recuperează, nu are cum să facă acea notificare corect. Iar backupul nu mai e doar plasa de siguranță tehnică, ci și sursa de adevăr pentru raportare.
Ce merită verificat săptămâna asta
Patru lucruri, în ordinea în care dor cel mai tare dacă lipsesc.
Există o copie pe care un cont compromis de administrator nu o poate șterge? Când s-a restaurat ultima oară ceva, cu adevărat, nu doar teoretic? Cât durează restaurarea completă, măsurat, nu estimat? Și mai are cineva din afara companiei acces la sistemul de backup — un furnizor, un fost colaborator, un cont de service uitat deschis?
Ultima întrebare e cea care surprinde cel mai des. Restul se rezolvă cu configurare și disciplină, iar variantele de backup cu copie imutabilă și plan de disaster recovery pornesc de la aceleași două numere de mai sus, nu de la un produs anume.
Companiile care au trecut printr-un atac și și-au revenit în două zile aveau, aproape întotdeauna, același lucru în comun: cineva testase restaurarea înainte să fie nevoie de ea.