Copii de siguranță pentru o firmă mică: regula 3-2-1 și proba restaurării

Întrebarea „avem backup?” primește aproape întotdeauna răspunsul „da”. Întrebarea „când a restaurat cineva ultima dată ceva din el?” primește, aproape la fel de des, liniște. Între cele două stă toată diferența: un backup este o presupunere până în clipa în care cineva scoate din el un fișier și îl deschide. Mai jos: ce merită salvat la o firmă mică, ce înseamnă regula 3-2-1, cele două cifre de decis înainte de a cumpăra orice și cum probezi că restaurarea funcționează.

„Am backup” nu este o stare, e o măsurătoare

ENISA, agenția Uniunii Europene pentru securitate cibernetică, a constatat într-un raport dedicat firmelor mici că peste 90% dintre firmele chestionate făceau deja un fel de copie de siguranță, iar procentul pare să fi crescut mai departe, peste 94%, în perioada pandemiei. Existența copiei nu a fost deci niciodată problema. Problema e dacă din ea se poate reconstrui firma.

Exemplul pe care ENISA îl dă în același raport este lămuritor: în 2017, GitLab a fost nevoit să își oprească serviciul după ce a șters accidental date din producție și a descoperit atunci că restaurarea din copii nu funcționa. O firmă care emite 40 de facturi pe lună are exact aceeași vulnerabilitate: nimeni nu verificase ieșirea, doar intrarea.

Regula 3-2-1, în formularea ENISA

Regula are trei propoziții, iar ENISA le enunță astfel:

Trei copii ale oricărui fișier important.
Două suporturi de stocare diferite, pentru ca aceeași categorie de risc să nu le atingă pe toate.
Cel puțin o copie în afara sediului, în afara mediului ICT principal al firmei — fie într-o locație la distanță, fie în cloud.

Pe lângă numărătoare, ENISA cere patru condiții pentru ca regula să însemne ceva: copia să fie regulată și automatizată pe cât posibil; să fie ținută separat de mediul de producție, adică de rețeaua cu care angajații lucrează direct; să fie criptată, mai ales dacă se mută între locații; și să existe capacitatea testată de a restaura datele — ideal, un test periodic de restaurare completă, de la început până la sfârșit.

Condiția a doua merită citită de două ori: un disc de backup mapat permanent ca literă în Windows pe calculatorul care se infectează nu este ținut separat de producție — e o a doua țintă, la fel de accesibilă ca prima.

Două cifre de decis înainte de a cumpăra orice: RPO și RTO

Ghidul NIST SP 800-34 Rev. 1, standardul american de planificare a continuității pentru sisteme informatice, definește trei mărimi care transformă discuția din „cât costă un NAS” în „cât ne permitem să pierdem”:

MTD (Maximum Tolerable Downtime) — timpul total pe care proprietarul sistemului e dispus să îl accepte pentru întreruperea unui proces, cu toate consecințele incluse.
RTO (Recovery Time Objective) — durata maximă în care o resursă poate rămâne indisponibilă înainte ca efectul asupra proceselor să devină inacceptabil. NIST precizează că RTO trebuie să fie, în mod normal, mai scurt decât MTD.
RPO (Recovery Point Objective) — momentul din timp, anterior întreruperii, până la care datele pot fi recuperate, dat fiind cea mai recentă copie. NIST notează că RPO nu face parte din MTD: e o măsură a cât de multe date suportă procesul să piardă, nu a timpului.

Tradus pentru o firmă mică: RPO îți spune cât de des trebuie să ruleze copia, RTO îți spune ce fel de copie îți trebuie. Un RPO de 24 de ore înseamnă că accepți să reintroduci o zi de documente; dacă facturarea nu suportă asta, o copie care rulează noaptea nu îți este suficientă — oricât de bine ar rula. NIST cere ca politica să specifice ea însăși minimul: cât de des și ce fel de copie (zilnic sau săptămânal, incrementală sau completă), după criticitatea datelor.

Ce anume salvezi — lista care se uită cel mai des

Fișierele din „Documente” sunt partea ușoară. Ce rămâne pe dinafară, de regulă:

Baza de date a programului de contabilitate sau de gestiune, nu doar folderul cu exporturi. O copie făcută cât timp baza e deschisă poate fi inutilizabilă.
Cutiile poștale, inclusiv cele ale foștilor angajați — adesea singurul loc cu istoricul unei comenzi.
Configurațiile: reguli de firewall, certificatele, cheile de licență. Datele revin repede; reconstruirea configurației din memorie durează zile.
Site-ul și baza lui de date, separat de backupul furnizorului de găzduire.

Pentru copiile scoase din sediu, NIST propune cinci criterii de alegere a locului: zona geografică — probabilitatea ca depozitul să fie lovit de același dezastru ca sediul; accesibilitatea; securitatea transportului și a spațiului; condițiile de mediu; și costul.

Dacă în copii intră date cu caracter personal sau informații contractuale, criptarea nu e un lux. Cerința NIST SP 800-171 Rev. 3 numerotată 03.08.09 — scrisă pentru informația controlată neclasificată (CUI) a administrației americane, dar utilă ca model — formulează două obligații distincte: protejarea confidențialității informației din copii și folosirea unor mecanisme criptografice care să împiedice divulgarea neautorizată a acelei informații în locațiile de stocare a copiilor.

Ce NU acoperă Microsoft 365 și Google Workspace

Aici se naște cea mai scumpă presupunere: „datele sunt în cloud, deci sunt salvate”. Furnizorii oferă o fereastră de anulare a unei ștergeri, nu un punct de restaurare la o dată aleasă de tine. Valorile de mai jos sunt din documentația lor oficială:

Ce s-a șters	Cât timp se mai poate recupera	De când se numără
Mesaj șters definitiv din Outlook (Exchange Online)	14 zile implicit, maximum 30 de zile dacă administratorul mărește valoarea	De la ștergerea definitivă
Fișier din Google Drive, după golirea coșului	25 de zile	De la golirea coșului de către utilizator
Mesaj Gmail șters definitiv	25 de zile pentru administrator	Fereastra începe 30 de zile după ștergerea mesajului
Cont de utilizator Google Workspace șters	20 de zile	De la ștergerea contului

Trei observații. Maximul de 30 de zile din Exchange Online nu e activ implicit — implicit sunt 14, iar diferența se setează de administrator. Documentația Google precizează că recuperarea de administrator nu include datele aflate în coșul utilizatorului. Iar un ransomware care criptează fișierele sincronizate nu „șterge” nimic: scrie versiuni noi, și o fereastră de recuperare a ștergerilor nu e unealta potrivită pentru asta.

Retenția furnizorului este deci altceva decât un backup: te apără de propria greșeală de săptămâna asta, nu de o problemă descoperită în martie pentru ceva întâmplat în ianuarie.

Cum probezi că restaurarea funcționează

NIST notează că suporturile de backup — în textul lui, casetele — ar trebui testate periodic pentru a se asigura că datele sunt stocate corect și că fișierele pot fi recuperate fără erori și fără pierderi. „Periodic” se transformă într-o procedură scurtă, pe care o poate ține și o firmă fără departament IT:

Alege ținta înainte, nu fișierul cel mai comod. Un document din urmă cu trei luni, o bază de date și o cutie poștală. Dacă restaurarea merge doar pe un PDF, nu ai testat nimic.
Restaurează în alt loc — alt folder, alt calculator — ca să nu suprascrii originalul și ca să afli dacă îți trebuie o licență sau o parolă pe care nu o ai.
Deschide ce ai restaurat. O bază de date se pornește, nu se cântărește.
Cronometrează. Timpul măsurat este RTO-ul tău real. Dacă e mai mare decât cel asumat, ai o problemă de arhitectură, nu de disciplină.
Notează data, ținta, durata și cine a făcut testul. Fără acest rând scris, la următorul incident discuția începe de la zero.
Verifică alertele în sens invers: oprește intenționat o sarcină de backup și vezi dacă primești notificarea de eșec.

Pentru perioada de păstrare, ENISA nu dă o cifră universală: cere ca retenția să fie stabilită în funcție de circumstanțele concrete ale organizației, astfel încât costul datelor pierdute într-un anumit interval să fie acceptabil. Numărul de copii păstrate în urmă este deci o decizie de afaceri, nu o setare implicită.

Greșeli care se văd abia la restaurare

Copia stă pe aceeași mașină, pe alt disc. Două discuri în aceeași carcasă nu sunt „două suporturi” când riscul e furtul, incendiul sau o supratensiune.
Nimeni nu știe parola de criptare. Copia e intactă și inutilizabilă. Parola trebuie să existe în altă parte decât în sistemul pe care îl restaurezi.
Retenția e mai scurtă decât timpul de descoperire. Dacă păstrezi 7 zile, iar o corupere e observată după 3 săptămâni, toate copiile sunt deja compromise.
Sincronizarea nu este o copie: ea propagă și ștergerea, și criptarea.

Întrebări frecvente

Dacă am OneDrive sau Google Drive, mai am nevoie de backup? Da: furnizorii oferă ferestre de recuperare a ștergerilor (14–30 de zile la Exchange Online, 25 la Drive după golirea coșului), nu puncte de restaurare la o dată aleasă de tine. ENISA cere, în plus, ca o copie să stea în afara mediului ICT principal — iar contul în care lucrezi zilnic nu îndeplinește condiția.

Cât de des ar trebui să testăm restaurarea? ENISA formulează cerința ca test periodic, ideal o restaurare completă de la început până la sfârșit, fără să fixeze un interval; NIST cere testarea periodică a suporturilor. Important e să fie programat și notat, nu „când ne amintim”.

E suficient să mărim retenția din Microsoft 365 la 30 de zile? Ajută, și merită făcut, pentru că implicit sunt 14 zile. Dar rămâne o fereastră de anulare a ștergerii: nu acoperă restaurarea unei cutii poștale la starea de acum două luni.

De unde începem dacă nu avem nimic definit? De la RPO și RTO, pe hârtie, pentru două-trei procese care opresc firma dacă se întrerup (facturare, comenzi, e-mail). Abia apoi se alege tehnologia; ordinea inversă produce copii care nu se restaurează în timp util.

Surse

Vrei să afli în ce stare este de fapt backupul firmei tale — nu dacă rulează, ci dacă se restaurează în timpul pe care ți-l permiți? HQ LEVEL verifică setările, măsoară RPO și RTO reale și face un test de restaurare împreună cu tine, prin serviciul de audit IT. Vezi și externalizare IT, articolul despre ransomware și comparația cloud sau server local. Scrie-ne pentru o discuție fără obligații.

Copii de siguranță pentru o firmă mică: regula 3-2-1, ce salvezi și cum probezi că restaurarea funcționează