Aproape orice companie răspunde afirmativ la întrebarea „aveți backup?”. Răspunsul se referă însă, de cele mai multe ori, la faptul că undeva rulează o sarcină programată care copiază niște date. Întrebarea utilă este alta: dacă mâine dimineață serverul principal nu mai pornește, iar copia de siguranță se dovedește coruptă, cât timp trece până când activitatea revine la normal și cât din munca ultimelor zile se pierde definitiv?
Regula 3-2-1 este cel mai scurt răspuns rezonabil la această întrebare. Nu este o normă tehnică și nu apare într-un standard: a fost formulată de Peter Krogh în contextul arhivării fotografiilor digitale și a rămas în uz pentru că descrie corect modul în care se pierd datele în realitate.
Ce spune regula
Trei copii ale datelor, pe două tipuri diferite de suport, dintre care una în altă locație.
Fiecare cifră apără împotriva unei categorii distincte de defecțiuni, iar utilitatea regulii vine tocmai din faptul că cele trei categorii nu se suprapun.
Trei copii înseamnă datele de producție plus două copii de siguranță. Motivul pentru care nu una, ci două, este că a doua copie protejează împotriva scenariului în care defecțiunea este descoperită abia atunci când prima copie este deja folosită pentru restaurare. O restaurare eșuată dintr-o singură copie nu mai lasă nimic în urmă.
Două tipuri de suport apără împotriva defecțiunilor corelate. Două discuri din același lot, cumpărate în aceeași zi și supuse aceleiași temperaturi, au o probabilitate de defectare mult mai apropiată decât sugerează calculul naiv. Același lucru se aplică la nivel logic: două copii aflate pe același sistem de fișiere, în același pool de stocare sau la același furnizor de cloud împart un mecanism de defectare, indiferent cât de diferite par.
O copie în altă locație apără împotriva evenimentelor care afectează întreaga clădire: incendiu, inundație, furt, o pană electrică prelungită sau o intervenție care distruge o încăpere întreagă. Acesta este singurul element al regulii pe care majoritatea companiilor îl tratează serios, de obicei prin sincronizare într-un serviciu de tip object storage.
Împotriva căror defecțiuni nu apără
Regula a fost formulată într-o perioadă în care principalele riscuri erau defectarea hardware-ului și greșeala umană. Ambele sunt încă actuale, dar nu mai sunt cele care produc pierderile mari.
Un atac de tip ransomware modern nu se limitează la criptarea datelor de producție. Atacatorii petrec de regulă zile sau săptămâni în rețea înainte de a declanșa criptarea, iar în acest interval caută explicit infrastructura de backup: consola soluției, share-urile în care se scriu copiile, credențialele contului de serviciu care are drepturi de ștergere. Criptarea se declanșează după ce copiile au fost șterse sau alterate, exact pentru că altfel victima nu ar avea motiv să plătească.
O arhitectură care respectă formal regula 3-2-1 poate cădea complet în acest scenariu. Trei copii accesibile cu aceleași credențiale de administrare sunt, din perspectiva atacatorului, o singură copie.
Al doilea punct slab este coruperea tăcută. Datele se degradează pe suporturi de stocare fără ca cineva să observe, iar dacă rotația copiilor este suficient de rapidă, versiunea sănătoasă poate fi suprascrisă înainte ca problema să iasă la iveală. O bază de date coruptă logic, dar copiată corect, produce copii de siguranță perfect valide ale unor date inutilizabile.
Al treilea este perimetrul. Datele din Microsoft 365 sau Google Workspace nu sunt incluse implicit într-un backup. Furnizorul garantează disponibilitatea propriei platforme, nu recuperarea conținutului șters de un utilizator sau de un atacator care i-a preluat contul, dincolo de perioadele scurte de retenție din coșul de reciclare.
Extinderea 3-2-1-1-0
Formularea care circulă în industrie astăzi adaugă două cifre.
Unu înseamnă o copie imutabilă sau izolată fizic. Imutabilitatea se obține prin mecanisme de tip object lock sau WORM, în care o copie scrisă nu mai poate fi modificată sau ștearsă până la expirarea perioadei declarate, nici măcar de un cont cu drepturi depline. Aceasta este singura măsură care rezistă în scenariul în care atacatorul deține credențiale de administrator, pentru că restricția este aplicată de platforma de stocare, nu de politica de acces.
Zero înseamnă zero erori la verificare. O copie despre care nu se știe dacă poate fi restaurată nu are valoare cunoscută, are doar cost cunoscut.
Testarea, singura verificare care contează
Verificarea automată a sumelor de control confirmă că fișierul de backup este citibil. Nu confirmă că din el se poate reconstitui un sistem funcțional, că baza de date pornește după restaurare, că aplicația găsește ce are nevoie sau că cineva își amintește ordinea corectă a pașilor.
Un exercițiu de restaurare complet, executat pe un mediu izolat, măsoară trei lucruri pe care nimeni nu le cunoaște înainte: durata reală a restaurării, cantitatea de date pierdute între ultima copie utilizabilă și momentul incidentului, și pașii nedocumentați pe care îi știe o singură persoană. Rareori se încheie fără să descopere ceva.
Frecvența rezonabilă este lunară pentru restaurările punctuale de fișiere și mașini virtuale, iar pentru un exercițiu complet de recuperare a sistemelor critice, cel puțin anuală, semestrială acolo unde cerințele sunt stricte. Rezultatul se documentează de fiecare dată. Documentarea nu este birocrație: este singura formă în care rezultatul poate fi prezentat la un audit și singura care permite compararea între exerciții.
Ce cer reglementările
Pentru companiile aflate sub incidența NIS2, gestionarea continuității activității, inclusiv administrarea copiilor de siguranță și recuperarea în caz de dezastru, este o cerință explicită între măsurile de administrare a riscurilor. Nu se cere o anumită tehnologie, ci existența măsurii și capacitatea de a demonstra că funcționează.
GDPR conține o cerință înrudită, formulată din perspectiva datelor cu caracter personal: capacitatea de a restabili disponibilitatea și accesul la date în timp util, în cazul unui incident fizic sau tehnic. Din nou, formularea este orientată spre rezultat, nu spre metodă, iar dovada rezultatului este exercițiul de restaurare.
Merită observat că ambele texte cer capacitatea de restaurare, nu existența copiilor. Diferența este exact cea dintre o companie care are backup și una care se poate întoarce în funcțiune.
Cum arată în practică
Pentru o companie medie, cu servere proprii și câteva sisteme critice, o schemă funcțională arată de obicei astfel.
Copiile locale se păstrează pe un sistem de stocare separat de cel de producție, cu retenție scurtă și restaurare rapidă, pentru cazurile obișnuite: un fișier șters, o actualizare eșuată, o mașină virtuală care nu mai pornește. Aici contează viteza, nu durata de păstrare.
Copiile din altă locație se scriu într-un serviciu de tip object storage cu blocare la scriere activată și cu o perioadă de retenție aleasă în funcție de cât timp poate trece până când o problemă este descoperită. Contul folosit pentru scriere nu are drepturi de ștergere, iar credențialele lui nu sunt aceleași cu cele folosite pentru administrarea infrastructurii.
Retenția se stabilește pe categorii de date, nu uniform. Un sistem de gestiune a producției și o arhivă de documente au valori foarte diferite, iar tratarea lor identică înseamnă fie cost inutil, fie risc asumat fără să știți.
Monitorizarea acoperă rezultatul sarcinilor de backup, nu doar execuția lor. Diferența contează: o sarcină care se termină cu succes după ce a sărit peste jumătate din volume raportează succes.
Greșelile care se repetă
Cea mai frecventă este confuzia dintre replicare și backup. Replicarea copiază starea curentă, inclusiv coruperea și criptarea, aproape instantaneu. Este un mecanism excelent de disponibilitate și un mecanism inutil de recuperare.
A doua este backupul care rulează cu un cont de administrator de domeniu. Este comod, funcționează la prima configurare și transformă infrastructura de backup într-o țintă cu acces total la restul rețelei.
A treia este retenția aleasă implicit. Valoarea prestabilită a produsului nu are legătură cu intervalul în care organizația dumneavoastră descoperă o problemă, iar acest interval este singurul criteriu relevant.
A patra este absența unui inventar. Nu se poate face backup pentru sisteme despre care nimeni nu știe că există, iar în orice infrastructură care a crescut în timp există astfel de sisteme.
Pasul următor
Dacă vreți să verificați unde se află organizația dumneavoastră, cel mai rapid test este să alegeți un sistem important și să încercați o restaurare completă pe un mediu izolat, cronometrând. Rezultatul spune mai mult decât orice document de politică.
Proiectăm și operăm scheme de backup în cadrul serviciului de backup și disaster recovery, iar partea de izolare a credențialelor și de rezistență la ransomware ține de securitatea cibernetică.