Copii de rezervă care rezistă la ransomware ── Regula 3-2-1, stocare care nu poate fi suprascrisă și verificarea restaurării

În atacurile ransomware există multe cazuri în care o organizație avea copii de rezervă, dar tot nu a putut restaura. Cea mai frecventă cauză este că și copiile de rezervă au fost criptate odată cu tot restul. Acest articol explică cum se construiesc copii de rezervă care rezistă la atacuri, pentru PC-urile cu Windows și serverele de fișiere ale întreprinderilor mici și mijlocii.

Punctele principale sunt trei: păstrați o copie pe care un PC infectat nu o poate suprascrie, nu folosiți „Versiunile anterioare” în locul copiilor de rezervă și verificați că puteți restaura cu adevărat. Regula 3-2-1 stabilește câte copii păstrați și unde, dar singură lasă unele lipsuri ca apărare împotriva ransomware-ului.

Comenzile din articol sunt doar pentru Windows, iar rezultatul lor l-am verificat într-un prompt de comandă de administrator pe Windows Server 2022. Ecranele de setări și prețurile produselor se pot schimba, așa că verificați cea mai recentă documentație a fiecărui furnizor atunci când le adoptați.

Multe organizații aveau copii de rezervă, dar nu au putut restaura

Agenția Națională de Poliție a Japoniei întreabă organizațiile lovite de ransomware despre starea copiilor lor de rezervă. În raportul pentru prima jumătate a anului 2025, 51 dintre cele 53 de organizații care au răspuns făceau copii de rezervă. Totuși, dintre cele 48 întrebate dacă au putut restaura din copia de rezervă la nivelul de dinaintea atacului, doar 7 au putut, iar 41 nu¹.

Dintre cele 35 care au indicat un motiv pentru care nu au putut restaura, 23 au răspuns „au fost criptate și copiile de rezervă”, 8 „deficiențe operaționale” și 4 „altele”¹. Același raport spune că grupările de ransomware șterg jurnalele și copiile de rezervă ale victimelor pentru a-și șterge urmele și a împiedica recuperarea. Apoi cere păstrarea copiilor de rezervă într-un mediu offline².

flowchart TB
        accTitle: Cum puteți avea copii de rezervă și totuși să nu restaurați
        accDescr: O diagramă care arată că, deși faceți copii de rezervă, acestea sunt criptate odată cu tot restul dacă PC-ul infectat ajunge la ele, iar dacă procedura de restaurare nu a fost verificată, deficiențele operaționale împiedică restaurarea.
        A["Se fac copii de rezervă"] --> B{"Ajunge PC-ul infectat la ele?"}
        B -->|"Ajunge"| C["Sunt și ele criptate sau șterse"]
        B -->|"Nu ajunge"| D{"A fost verificată procedura de restaurare?"}
        D -->|"Nu"| E["Restaurarea eșuează din deficiențe operaționale"]
        D -->|"Da"| F["Se poate restaura"]

Figura 1: Copiile de rezervă pot fi folosite când PC-ul infectat nu ajunge la ele și procedura de restaurare a fost verificată.

Există și cazuri în care restaurarea a reușit. Ediția a 4-a a „Ghidurilor de securitate a informațiilor pentru IMM-uri” ale IPA include cazul unei firme de construcții ale cărei servere de fișiere și alte sisteme au fost criptate după o intruziune printr-un echipament VPN. Și pentru că firma făcea exerciții de restaurare de două ori pe an, și-a repornit din copiile de rezervă sistemele de bază la cinci zile după descoperirea atacului. Chiar și așa, reluarea fiecărui sistem intern a durat 41 de zile, reluarea accesului de la distanță patru luni, iar firma a pierdut peste 20 la sută din fișierele interne³. Faptul că puteți restaura din copiile de rezervă nu face ca paguba să dispară.

În diagramă, linia continuă marchează o relație care este întotdeauna valabilă, iar linia punctată una condiționată (condițiile sunt indicate pentru fiecare relație pe pagina de detalii). Lista completă a relațiilor (13 în total, cu dovezi și grad de certitudine) și definițiile conceptelor principale sunt reunite în pagina de detalii a hărții cunoștințelor (în japoneză). Date: JSON-LD / Turtle

Atacatorii șterg copiile de rezervă la care pot ajunge

Ghidul #StopRansomware publicat de CISA și alte agenții americane spune că multe variante de ransomware încearcă să găsească copiile de rezervă accesibile și să le șteargă sau să le cripteze, astfel încât victima să nu poată recupera datele fără să plătească răscumpărarea. De aceea consideră importantă păstrarea copiilor de rezervă offline⁴.

Și Microsoft scrie că atacatorii se concentrează pe dezactivarea software-ului de backup și a funcțiilor sistemului de operare, cum ar fi copiile umbră ale volumului⁵. Copiile de rezervă la care poate ajunge un PC infectat includ următoarele.

• Unități externe conectate permanent la PC
• Folderele partajate de pe NAS sau de pe un server de fișiere mapate la o literă de unitate
• Folderele de sincronizare în cloud în care poate scrie contul obișnuit
• Copiile umbră (Versiuni anterioare) de pe același volum

Copiile umbră și cataloagele copiilor de rezervă pot fi șterse chiar și cu comenzile integrate în sistemul de operare. MITRE ATT&CK clasifică această tehnică drept „Inhibit System Recovery” (T1490). Ca exemple, dă ștergerea tuturor copiilor umbră cu vssadmin.exe delete shadows /all /quiet și ștergerea catalogului copiilor de rezervă Windows cu wbadmin.exe delete catalog -quiet⁶. Ghidul CISA cere, de asemenea, monitorizarea utilizării suspecte a vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) și a altor instrumente similare⁴.

flowchart TB
        accTitle: Copii de rezervă la care un PC infectat poate și nu poate ajunge
        accDescr: O diagramă care arată că un PC infectat poate scrie pe unitățile externe conectate permanent, în folderele partajate mapate, în folderele de sincronizare și în copiile umbră, dar nu poate scrie pe suporturile deconectate și nici în stocarea care nu poate fi suprascrisă.
        P["PC infectat"] --> R["Locuri în care poate scrie"]
        P -.-x N["Suporturi deconectate, stocare care nu poate fi suprascrisă"]
        R --> A["Unitate externă conectată permanent"]
        R --> B["Folder partajat mapat"]
        R --> C["Folder de sincronizare în cloud"]
        R --> D["Copii umbră"]

Figura 2: Copiile de rezervă păstrate acolo unde un PC infectat poate scrie devin ținte ale atacului.

Trebuie să fiți atenți și la atacurile care durează mult. Microsoft scrie că ransomware-ul criptează uneori treptat, lăsând cheia în sistem. În acest timp utilizatorii pot folosi datele ca de obicei, așa că se acumulează copii de rezervă ale datelor criptate fără ca cineva să observe. După ce totul este criptat și cheia este ștearsă, nici copiile de rezervă recente nu mai pot fi citite⁵. Dacă păstrați doar cea mai recentă generație, în acest caz nu aveți la ce să reveniți.

„Versiunile anterioare” nu înlocuiesc copiile de rezervă

„Versiunile anterioare” din Windows și copiile umbră ale folderelor partajate folosesc Serviciul de copiere umbră a volumelor (VSS). Furnizorul de sistem VSS inclus în Windows folosește metoda copierii la scriere: salvează conținutul unui bloc într-o zonă de diferențe înainte ca blocul să fie suprascris și astfel reconstituie volumul la un anumit moment⁷.

În documentația VSS, Microsoft explică diferența dintre copiile umbră și copiile de rezervă astfel. Când datele sunt copiate dintr-o copie umbră pe un suport amovibil, de exemplu bandă, conținutul acelui suport devine copia de rezervă. După copiere, copia umbră în sine poate fi ștearsă⁷. Documentația spune și că, atunci când zona de diferențe nu mai are spațiu, primele șterse sunt copiile umbră cele mai vechi⁷.

flowchart TB
        accTitle: Diferența dintre copiile umbră și copiile de rezervă
        accDescr: O diagramă care arată că o copie umbră este un set de diferențe față de volumul original și este ștearsă când spațiul nu ajunge sau de către un atacator, în timp ce o copie de rezervă copiată pe un suport separat rămâne chiar dacă volumul original se pierde.
        V["Volumul original"] --> S["Copie umbră (diferențe)"]
        S --> L["Ștearsă începând cu cea mai veche când nu ajunge spațiul"]
        S --> K["Ștearsă de un atacator cu vssadmin"]
        S -->|"Copiere pe un suport separat"| B["Copie de rezervă"]
        B --> R["Rămâne chiar dacă volumul original se pierde"]

Figura 3: Copiile umbră depind de datele volumului original; ceea ce copiați pe un suport separat devine copia de rezervă.

Copiile umbră sunt utile pentru ca utilizatorii să restaureze singuri fișierele pe care le-au suprascris din greșeală. Însă, așa cum arată secțiunea anterioară, atacatorii le șterg uneori. Mecanismul și utilizarea sunt explicate în detaliu în „Volume Shadow Copy (VSS): The Mechanism and the Practice”.

Pentru a vedea ce copii umbră au rămas, rulați vssadmin list shadows într-un prompt de comandă de administrator. Această subcomandă este disponibilă atât pe clienți, cât și pe servere⁸.

vssadmin list shadows

Istoricul versiunilor și coșul de reciclare din OneDrive și SharePoint sunt și ele modalități prin care utilizatorii își pot recupera fișierele. Microsoft recomandă să le arătați utilizatorilor cum își pot restaura întregul OneDrive la un moment anterior. Mai spune ca utilizatorii să restaureze doar după ce sunteți siguri că atacatorul a fost eliminat și să vă pregătiți pentru cazul în care utilizatorii restaurează și programul malware⁵.

Regula 3-2-1 stabilește câte copii și unde

Regula 3-2-1 este o regulă practică despre cum păstrați copiile de rezervă. Documentul „Data Backup Options”, scris în 2012 pentru US-CERT, o explică astfel⁹.

• 3: Păstrați trei copii ale fișierelor importante, originalul și două copii de rezervă.
• 2: Stocați-le pe două tipuri diferite de suport, pentru a vă proteja de diferite tipuri de dezastre.
• 1: Păstrați o copie în afara locuinței sau a firmei.

Ca sursă, documentul citează „The DAM Book”, o carte despre gestionarea fotografiilor digitale scrisă de fotograful Peter Krogh⁹. Și Microsoft citează această regulă în documentația sa despre copiile de rezervă pentru protecția împotriva ransomware-ului și descrie „1” drept „copie în afara locației sau copie rece”⁵.

Ceea ce cere regula 3-2-1 este păstrarea unei copii în afara firmei. Nu cere ca această copie să fie offline sau imuabilă. Așadar, dacă respectiva copie se află într-un cloud în care un PC infectat poate scrie oricând, ea poate fi criptată împreună cu copiile locale. Ghidul CISA și documentația Microsoft indică păstrarea offline ca apărare împotriva ransomware-ului. Microsoft indică și stocarea care nu poate fi suprascrisă⁴⁵.

flowchart TB
        accTitle: Regula 3-2-1 și protecția împotriva ransomware-ului
        accDescr: O diagramă care arată adăugarea unei copii offline sau imuabile la regula 3-2-1 cu trei copii, două tipuri de suport și una în afara firmei, urmată de verificarea că puteți restaura.
        A["Trei copii"] --> B["Două tipuri de suport"]
        B --> C["Una în afara firmei"]
        C --> D["Una offline sau imuabilă"]
        D --> E["Verificați că puteți restaura"]

Figura 4: La regula 3-2-1 adăugați o copie pe care un PC infectat nu o poate suprascrie și verificarea că puteți restaura.

Furnizorul de software de backup Veeam promovează acest lucru drept „regula 3-2-1-1-0”. În documentația Veeam, „1” suplimentar înseamnă păstrarea unei copii offline, izolate fizic (air-gapped) sau imuabile, iar „0” înseamnă zero erori la verificarea periodică a restaurării¹⁰. Este o denumire din documentația unui furnizor, nu un standard oficial. Totuși, cele două elemente adăugate se suprapun cu ce cer CISA și IPA.

Păstrați o copie pe care un PC infectat nu o poate suprascrie

Există două moduri principale de a obține o copie care nu poate fi suprascrisă: deconectați suportul de la PC și îl depozitați sau folosiți o stocare în cloud în care datele nu pot fi suprascrise sau șterse pentru o perioadă stabilită. Indiferent ce alegeți, separați permisiunile de gestionare a copiilor de rezervă de munca de zi cu zi.

Deconectați suportul de la PC și depozitați-l

Ca exemplu de măsură în autoevaluare, ghidurile IPA spun să conectați dispozitivele și suporturile folosite pentru copii de rezervă la PC doar în timpul realizării copiei. Mai menționează stabilirea modului în care se fac copiile, depozitarea lor într-un loc sigur și verificarea periodică a faptului că pot fi restaurate¹¹.

Pentru organizațiile care merg mai departe, ghidurile menționează „izolarea fizică”. Aceasta înseamnă păstrarea copiilor de rezervă într-un loc separat fizic de sistemul original și depozitarea stocării externe sau a benzilor de backup cât mai departe posibil. Ca exemple de locuri de depozitare, menționează o casetă de valori la bancă sau un partener de afaceri ori o firmă afiliată de încredere¹².

O copie de rezervă depozitată astfel, deconectată de sistemele de producție, se numește copie de rezervă offline. Un PC infectat nu poate scrie pe un suport deconectat. Pe de altă parte, oamenii trebuie să reconecteze și să transporte suporturile, așa că se întâmplă ca o copie să nu fie făcută sau suportul să nu fie dus în afara firmei. Stabiliți cine conectează suportul, cine îl deconectează și îl duce la locul de depozitare și când.

Folosiți o stocare în cloud care nu poate fi suprascrisă

Stocările în cloud au funcții care împiedică suprascrierea sau ștergerea datelor pentru o perioadă stabilită. Ele păstrează datele într-o stare numită WORM (Write Once, Read Many).

În stocarea imuabilă Azure Blob Storage, după ce setați o politică de păstrare bazată pe timp, în acea perioadă datele pot fi create și citite, dar nu modificate sau șterse¹³. O politică este creată mai întâi în stare deblocată, iar după testare o blocați. O politică blocată nu poate fi ștearsă, iar perioada ei de păstrare poate fi prelungită, dar nu scurtată¹³. Microsoft explică faptul că nici utilizatorii cu permisiuni de administrator al contului nu pot modifica sau șterge datele¹³.

Amazon S3 Object Lock are două moduri. În modul de conformitate (compliance), nimeni, nici măcar utilizatorul rădăcină al contului AWS, nu poate suprascrie sau șterge o versiune a unui obiect în perioada de păstrare. În modul de guvernanță (governance), doar utilizatorii cu permisiuni speciale pot modifica sau elimina setările de păstrare¹⁴. Object Lock poate fi folosit doar în bucket-uri cu S3 Versioning activat¹⁴.

flowchart TB
        accTitle: Două exemple de stocare care nu poate fi suprascrisă
        accDescr: O diagramă care arată că în stocarea imuabilă Azure Blob Storage o politică blocată nu poate fi ștearsă și perioada ei de păstrare nu poate fi scurtată, iar că în S3 Object Lock, în modul de conformitate, nici utilizatorul rădăcină nu poate șterge, în timp ce în modul de guvernanță permisiunile speciale permit modificări.
        W["Stocare care nu poate fi suprascrisă"] --> AZ["Stocarea imuabilă Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["După blocare perioada nu poate fi scurtată"]
        S3 --> C["Modul de conformitate"]
        S3 --> G["Modul de guvernanță"]
        C --> C1["Nici utilizatorul rădăcină nu poate șterge"]
        G --> G1["Permisiunile speciale permit modificări"]

Figura 5: Ambele tipuri de stocare refuză suprascrierea și ștergerea pentru o perioadă stabilită; cât de strict, depinde de setări.

În Azure, chiar dacă observați o greșeală de configurare după ce ați blocat o politică, nu puteți scurta perioada de păstrare¹³. Ghidul CISA menționează că unii furnizori de cloud oferă stocare care nu poate fi suprascrisă și avertizează că o configurare greșită poate duce la costuri mari. Menționează și că o astfel de stocare poate să nu îndeplinească cerințele anumitor reglementări⁴. Dacă setați o perioadă de păstrare lungă și o blocați, în acea perioadă nu puteți șterge datele, iar costurile de stocare continuă să se acumuleze. Începeți cu starea deblocată sau cu o perioadă scurtă, verificați că puteți restaura și abia apoi aplicați setările de producție.

Separați permisiunile de gestionare a copiilor de rezervă

Chiar dacă folosiți stocare care nu poate fi suprascrisă, dacă setările și politicile copiilor de rezervă pot fi modificate cu contul de administrator obișnuit, un atacator le poate modifica. Microsoft recomandă să cereți un pas suplimentar, cum ar fi autentificarea multifactor sau un PIN de securitate, înainte ca copiile de rezervă online să poată fi modificate sau șterse. Mai menționează limitarea operațiunilor de backup și restaurare la utilizatorii din roluri desemnate și reducerea numărului de foldere partajate în care mulți utilizatori pot scrie și șterge⁵.

Chiar dacă aceeași persoană gestionează atât PC-urile, cât și copiile de rezervă, nu folosiți contul de gestionare a destinației copiilor de rezervă pentru conectarea zilnică la PC și protejați-l cu autentificare multifactor.

Păstrați mai multe generații

Ghidurile IPA menționează „gestionarea generațiilor”, adică păstrarea copiilor de rezervă din mai multe momente. Aceasta vă permite să reveniți la un anumit moment atunci când datele sunt deteriorate sau pierdute¹². Așa cum s-a arătat într-o secțiune anterioară, dacă durează până observați criptarea, cele mai recente copii de rezervă vor conține date deja criptate. Câte generații păstrați stabiliți în funcție de cât poate dura până observați criptarea și de costul stocării.

flowchart TB
        accTitle: Trei măsuri pentru a păstra o copie care nu poate fi suprascrisă
        accDescr: O diagramă care arată depozitarea suporturilor deconectate sau folosirea stocării care nu poate fi suprascrisă, separarea permisiunilor de gestionare a copiilor de rezervă de conturile obișnuite și păstrarea mai multor generații.
        A["O copie care nu poate fi suprascrisă"] --> B["Depozitarea suporturilor deconectate"]
        A --> C["Stocare care nu poate fi suprascrisă"]
        B --> D["Separarea permisiunilor de gestionare"]
        C --> D
        D --> E["Păstrarea mai multor generații"]

Figura 6: După ce stabiliți unde păstrați copia, separați permisiunile de gestionare și păstrați generații, ca să puteți reveni chiar dacă observați târziu.

Verificați că puteți restaura

În raportul Agenției Naționale de Poliție, al doilea cel mai frecvent motiv pentru care restaurarea a eșuat a fost „deficiențele operaționale”¹. Nu puteți ști dacă o copie de rezervă poate fi restaurată cu adevărat până nu încercați. Activitatea prin care confirmați acest lucru restaurând efectiv din copia de rezervă se numește test de restaurare.

Ghidurile IPA împart gestionarea copiilor de rezervă în trei părți: realizarea, păstrarea și restaurarea. Pentru restaurare, cer întocmirea unui plan de recuperare și confirmarea faptului că restaurarea decurge corect³. Pentru sistemele critice pentru afacere, cer adaptarea modului de realizare a copiilor și a procedurilor la obiectivul timpului de recuperare (RTO) și la obiectivul punctului de recuperare (RPO), precum și verificarea eficacității prin exerciții. RTO este timpul necesar pentru restaurarea la nivelul țintă, iar RPO este momentul la care restaurați, adică momentul celei mai recente copii de rezervă¹⁵. Și ghidul CISA cere verificarea periodică a faptului că copiile de rezervă sunt utilizabile și intacte, având în vedere recuperarea în caz de dezastru⁴.

flowchart TB
        accTitle: Cum se face un test de restaurare
        accDescr: O diagramă care arată fluxul de stabilire a ordinii de restaurare, restaurare într-un mediu separat, comparare a timpului necesar și a momentului restaurat cu RTO și RPO și revizuire a manualului de proceduri.
        A["Stabiliți ordinea de restaurare"] --> B["Restaurați într-un mediu separat"]
        B --> C["Comparați timpul necesar cu RTO"]
        B --> D["Comparați momentul restaurat cu RPO"]
        C --> E["Revizuiți manualul de proceduri"]
        D --> E
        E -.->|"Următoarea verificare"| A

Figura 7: Încercați restaurarea, verificați dacă timpul și momentul ating țintele și introduceți rezultatele în manualul de proceduri.

Ce să verificați

Pe baza documentației IPA și Microsoft, ce trebuie verificat poate fi organizat astfel.

Microsoft recomandă să identificați mai întâi sistemele critice pentru afacere și să le faceți copii de rezervă periodic. Lista de copii de rezervă ordonată după prioritate devine astfel direct ordinea de restaurare. Ca prioritate ridicată, menționează pe primul loc sistemele de autentificare, cum ar fi Active Directory, necesare pentru a accesa toate celelalte sisteme⁵. Mai recomandă exerciții periodice de repornire a activității dintr-o stare în care toate sistemele sunt oprite. În aceste exerciții, presupuneți că nici e-mailul și chatul nu sunt disponibile⁵.

Microsoft scrie că atacatorii vizează în mod deliberat manualele de restaurare și diagramele de rețea. Recomandă protejarea lor sau păstrarea unor copii tipărite la îndemână⁵. Dacă manualul există doar pe serverul de fișiere, nu îl puteți citi când acel server este criptat.

Precauții la restaurarea după un atac

După un atac real, eliminați mai întâi ransomware-ul însuși din mediu și abia apoi restaurați⁵. Microsoft menționează alegerea unei copii de rezervă dintr-un moment despre care se știe că nu era infectat și scanarea copiei de rezervă pentru malware înainte de restaurare⁵. Raportul Agenției Naționale de Poliție spune că grupările de ransomware instalează uneori software controlabil de la distanță ca ușă din spate, ca să poată reveni chiar și după ce punctul de intrare este închis². Înainte de restaurare trebuie să cercetați calea de intruziune și tot ce au lăsat în urmă atacatorii.

flowchart TB
        accTitle: Ordinea restaurării din copia de rezervă după un atac
        accDescr: O diagramă care arată eliminarea ransomware-ului însuși și a căii de intruziune, alegerea unei copii de rezervă dintr-un moment neinfectat, scanarea ei pentru malware și apoi restaurarea mai întâi a sistemelor cu cea mai mare prioritate.
        A["Eliminați ransomware-ul însuși"] --> B["Cercetați calea de intruziune și ce a rămas"]
        B --> C["Alegeți un moment neinfectat"]
        C --> D["Scanați copia de rezervă"]
        D --> E["Restaurați mai întâi ce are prioritate maximă"]

Figura 8: După un atac, eliminați ce au lăsat în urmă atacatorii și confirmați un moment neinfectat înainte de restaurare.

Cât de des să verificați

Atât ghidurile IPA, cât și ghidul CISA cer să verificați „periodic” că puteți restaura, dar nu dau un număr¹¹⁴. Firma din cazul IPA prezentat mai devreme făcea exerciții de restaurare de două ori pe an³. Stabiliți cât timp poate sta activitatea oprită și cât de vechi poate fi momentul restaurat, apoi verificați cu o frecvență care vă permite să confirmați că le respectați.

Ce să stabiliți mai întâi

Conținutul de până acum poate fi rezumat ca ceea ce un IMM ar trebui să stabilească mai întâi.

flowchart TB
        accTitle: Ordinea deciziilor pentru copii de rezervă rezistente la ransomware
        accDescr: O diagramă care arată ordinea în care se stabilește domeniul, se stabilește unde se păstrează copiile și copia care nu poate fi suprascrisă, se stabilesc permisiunile și generațiile, se stabilesc RTO și RPO și se verifică faptul că puteți restaura.
        A["Stabiliți domeniul"] --> B["Stabiliți unde păstrați copiile"]
        B --> C["Stabiliți copia care nu poate fi suprascrisă"]
        C --> D["Stabiliți permisiunile și generațiile"]
        D --> E["Stabiliți RTO și RPO"]
        E --> F["Verificați că puteți restaura"]

Figura 9: Stabiliți totul într-o singură succesiune, de la domeniu până la verificarea finală că puteți restaura.

În ediția a 4-a a ghidurilor IPA, la cele „5 reguli de securitate a informațiilor” cu care încep organizațiile s-a adăugat „Faceți copii de rezervă!”, astfel încât acum sunt 6 reguli¹⁶. Cum parcurgeți ghidurile în ansamblu este rezumat în „Where Should SMEs Start on Security?”. Dacă plănuiți să înlocuiți servere, consultați și „Preparing for Windows Server 2016 End of Support”.

Articole conexe

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS): The Mechanism and the Practice — Why Backup Software Can Copy Files That Are Still in Use
• Preparing for Windows Server 2016 End of Support

Referințe

Articole conexe

Cele mai recente articole care au aceleași etichete. Aprofundați cunoștințele prin subiecte apropiate.

Subiecte conexe

Pagini de subiect apropiate de această temă. Pornind de la articol, puteți ajunge la servicii conexe și la alte articole.

Servicii legate de această temă

Acest articol se leagă de paginile de servicii de mai jos. Alegeți punctul de intrare cel mai apropiat de nevoia dumneavoastră.

Întrebări frecvente

Întrebările pe care le primim cel mai des în consultanță pe tema acestui articol.

Dacă fac copii de rezervă, pot restaura totul după o infectare cu ransomware?

Adesea, simpla realizare a copiilor de rezervă nu este suficientă pentru restaurare. În datele despre daune centralizate de Agenția Națională de Poliție a Japoniei pentru prima jumătate a anului 2025, 41 dintre cele 48 de organizații care făceau copii de rezervă și au răspuns nu au putut reveni la nivelul de dinaintea atacului. Cel mai frecvent motiv a fost că fuseseră criptate și copiile de rezervă. Aveți nevoie de o copie pe care un PC infectat nu o poate suprascrie și trebuie să verificați că puteți restaura din ea.

Dacă Windows are Versiuni anterioare, mai am nevoie de copii de rezervă?

Da. Versiunile anterioare sunt copii umbră ale volumului, adică diferențe păstrate pe volumul original. Microsoft consideră copie de rezervă datele copiate dintr-o copie umbră pe un suport, de exemplu bandă. Ransomware-ul șterge uneori copiile umbră cu instrumente precum vssadmin, așa că le combinați cu copii de rezervă pe un suport separat.

Este suficient să respect regula 3-2-1 pentru protecția împotriva ransomware-ului?

Uneori nu este. Regula 3-2-1 cere trei copii, două tipuri de suport și o copie păstrată în afara firmei, dar nu cere ca această copie să fie offline sau imuabilă. O copie în cloud în care un PC infectat poate scrie oricând poate fi criptată la fel. Adăugați o copie pe un suport offline sau într-o stocare care nu poate fi suprascrisă.

Cât de des trebuie să verific dacă pot restaura din copiile de rezervă?

Atât ghidurile IPA, cât și ghidul CISA spun „periodic” și nu dau un număr. Ghidurile IPA includ cazul unei firme care făcea exerciții de restaurare de două ori pe an și și-a repornit sistemele de bază la cinci zile după descoperirea atacului. Stabiliți cât timp poate sta activitatea oprită și cât de vechi poate fi momentul restaurat, apoi verificați cu o frecvență care vă permite să confirmați că le puteți respecta.

Profilul autorului

Pagina de profil a autorului articolului.

Go Komura

Reprezentant al KomuraSoft LLC

Specializat în dezvoltarea de software Windows, consultanță tehnică și investigarea defectelor, cu puncte forte în proiectele care pornesc de la resurse software existente și în investigarea avariilor ale căror cauze sunt greu de identificat.