Copia de la mănăstire

Originea

Biblioteca din Alexandria nu a dispărut într-o singură noapte, oricât de frumoasă ar fi legenda incendiului lui Cezar. A dispărut în secole, prin neglijență, tăieri de fonduri, conflicte și, mai ales, printr-o eroare de proiectare — era unică. Sute de mii de suluri, într-un singur loc, în grija unei singure instituții, fără copii sistematice în altă parte. Când instituția a slăbit, textele au murit cu ea. Majoritatea literaturii grecești pe care o avem azi nu s-a păstrat la Alexandria, ci în copiile făcute în altă parte.

Lecția a fost învățată de cineva cu un simț practic remarcabil. Cassiodor, fost ministru al regelui ostrogot Teodoric, s-a retras în jurul anului 540 pe moșia sa din Calabria și a întemeiat mănăstirea Vivarium cu un scop explicit, copierea cărților. În Institutiones, el le explică monahilor că a copia un manuscris este o formă de rugăciune și le dă instrucțiuni despre corectură, legătorie și cum se păstrează pergamentul. Regula Sfântului Benedict, scrisă în aceeași perioadă, prevede ore zilnice de lectură și, implicit, biblioteci. Pe fundamentul ei, timp de o mie de ani, fiecare mănăstire importantă din Europa a avut un scriptorium în care se copiau, din nou și din nou, aceleași texte. Un manuscris de la Monte Cassino era copiat la Bobbio, apoi la Fulda, apoi la Reichenau. Nu exista o politică centrală de arhivare. Exista redundanța.

Rezultatul se vede în statistici. Aproape tot ce avem din Cicero, Virgiliu, Tacit sau Seneca ne-a ajuns prin copii medievale, iar pentru multe texte copia cea mai veche care a supraviețuit vine dintr-o mănăstire aflată la mare distanță de locul unde a fost scris originalul. Când Monte Cassino a fost distrus de bombardamentele aliate în februarie 1944, manuscrisele erau deja evacuate la Roma, nu pentru că cineva avea un plan de continuitate, ci pentru că, după o mie patru sute de ani de incendii, cutremure și jafuri, „ține copia în altă parte” era reflex.

Înaintea tuturor, o lecție involuntară. Biblioteca regelui asirian Assurbanipal, de la Ninive, s-a păstrat pentru că palatul a ars. Focul care a distrus orașul în 612 î.Hr. a copt tăblițele de lut și le-a făcut practic indestructibile. Suportul contează.

Surse: Cassiodor, Institutiones, I, 30; L. D. Reynolds, N. G. Wilson, Scribes and Scholars (ed. a 4-a, 2013), pentru transmiterea textelor clasice; Peter Krogh, The DAM Book (2005), pentru regula 3-2-1.

Principiul

Copia de la mănăstire codifică o regulă pe care fotograful Peter Krogh a formulat-o în 2005 ca „3-2-1” și pe care orice administrator IT o știe pe de rost și o aplică rar — trei copii, pe două tipuri de suport, una în afara locației. Trei copii, pentru că o copie se poate corupe sau pierde fără să observi. Două suporturi, pentru că o defecțiune lovește de obicei un singur tip de dispozitiv sau un singur furnizor. Una în altă parte, pentru că focul, inundația, furtul și atacatorul lovesc un loc odată.

Ransomware-ul a adăugat un al patrulea element, pe care călugării îl aveau implicit. Copia trebuie să fie deconectată. Un manuscris de la Fulda nu putea fi ars de focul de la Monte Cassino pentru că nu exista niciun drum pe care focul să ajungă acolo. O copie de rezervă accesibilă din rețea este, pentru atacator, un fișier ca oricare altul.

Amenințarea de azi

Grupurile de ransomware moderne nu criptează imediat. Petrec zile sau săptămâni în rețea, cu un singur scop înaintea criptării, găsirea și distrugerea copiilor de rezervă. Caută serverele Veeam, consolele de backup, conturile de cloud sincronizate, snapshot-urile de pe sistemele de virtualizare, și le șterg. Abia apoi criptează. Scopul este simplu — o victimă fără copii de rezervă plătește.

Cazul Maersk din 2017 (fișa 3) este exemplul perfect. Infrastructura mondială a companiei a fost reconstruită plecând de la un singur controler de domeniu, din Ghana, care supraviețuise doar pentru că o pană de curent îl ținuse deconectat în timpul atacului. Copia de la mănăstire a fost, în acest caz, un accident. Nu ar trebui să fie.

Al doilea scenariu, mai frecvent la firmele mici, sună așa — „avem backup, e în cloud”. Dosarele sunt sincronizate cu OneDrive sau Google Drive. Când ransomware-ul criptează fișierele de pe laptop, sincronizarea încarcă fidel versiunile criptate în cloud. Sincronizarea nu este copie de rezervă; este oglindă. Oglinda reflectă și dezastrul.

Cum o implementezi luni dimineață

Firma de 20 de oameni

Cumpărați două discuri externe. Unul stă în firmă, celălalt acasă la director sau la un asociat, și se schimbă între ele săptămânal. Discul care nu este în uz stă deconectat. Acesta este singurul lucru care contează cu adevărat. Configurați o copie de rezervă automată, cu orice program de backup, inclusiv cele incluse în sistemul de operare, către discul conectat, zilnic, cu criptarea copiei activată și parola pusă în plicul sigilat (fișa 4).

Păstrați sincronizarea în cloud, dar activați istoricul versiunilor și verificați că puteți restaura un fișier de acum 30 de zile. Pentru datele critice, adăugați un serviciu de backup separat de cel de stocare, cu alt furnizor și alt cont.

O dată pe lună, alegeți un fișier la întâmplare și restaurați-l de pe discul deconectat, pe alt calculator. Dacă durează mai mult de zece minute sau nu reușiți, nu aveți copie de rezervă. Aveți o speranță.

Firma de 500 de oameni

Copiile de rezervă sunt imutabile, adică nu pot fi șterse sau modificate o perioadă fixă, nici de administrator, și stau pe un sistem cu credențiale complet separate de domeniul principal, pentru ca atacatorul care deține domeniul să nu poată atinge consola de backup. Pentru sistemele critice, copii pe bandă sau pe un depozit offline, rotite în afara locației — banda este lentă, ieftină și, deconectată, imună.

De două ori pe an se face un test de restaurare completă a unui sistem critic, de la zero, cu timp măsurat, iar rezultatul, adică orele până la repunerea în funcțiune, intră în planul de continuitate. Orice modificare a politicii de retenție sau ștergere a snapshot-urilor se monitorizează activ, pentru că acesta este semnalul că un atac este în pregătire.

Unde eșuează

Cel mai frecvent eșec este copia netestată. Backup-ul rulează de trei ani, raportează „succes” și restaurează fișiere corupte. Testul lunar este tehnica, nu backup-ul.

Urmează copia conectată. Un disc extern care stă permanent în USB este criptat odată cu restul, iar un NAS în rețea, cu parola de administrator implicită, este prima țintă. Apoi cheia în același loc — o copie criptată a cărei parolă este pe serverul criptat este inutilă; cheia stă în plic, în altă clădire.

Retenția prea scurtă este o capcană mai subtilă. Dacă păstrați copii de șapte zile și atacatorul a stat în rețea două săptămâni, toate copiile conțin deja malware. Păstrați copii lunare timp de un an. Și, în sfârșit, nici călugării nu copiau tot, iar ce nu părea important s-a pierdut. Decideți explicit ce intră în copia de rezervă și verificați că serverul de contabilitate instalat anul trecut chiar este inclus.

Cadrul legal

Art. 32 alin. (1) lit. (c) GDPR cere capacitatea de a restabili disponibilitatea și accesul la datele personale în timp util în caz de incident, adică, literal, obligația de a avea copii de rezervă funcționale, iar lit. (d) cere testarea periodică a măsurilor. Art. 21 alin. (2) lit. (c) din Directiva NIS2 numește explicit gestionarea copiilor de rezervă și recuperarea în caz de dezastru. În ISO/IEC 27001:2022, controlul A.8.13 (copii de rezervă ale informațiilor) cere copii testate periodic, iar A.5.30 (pregătirea TIC pentru continuitatea activității) cere obiective de timp de recuperare definite și verificate.