Zsarolóvírusnak ellenálló biztonsági mentés ── a 3-2-1 szabály, felülírhatatlan tárhely és a visszaállíthatóság ellenőrzése

Zsarolóvírus-támadások után sok olyan eset van, amikor a szervezetnek volt biztonsági mentése, mégsem tudott visszaállni. A leggyakoribb ok, hogy a mentéseket is titkosították minden mással együtt. Ez a cikk azt mutatja be, hogyan készíthető a támadásoknak ellenálló biztonsági mentés kis- és középvállalkozások Windows-számítógépei és fájlkiszolgálói számára.

Három fő pont van: legyen egy olyan példány, amelyet a fertőzött gép nem tud felülírni; ne használja az „Előző verziók” funkciót a biztonsági mentés helyett; és győződjön meg arról, hogy ténylegesen vissza tud állni. A 3-2-1 szabály meghatározza, hány példányt tartson és hol, de önmagában hiányos a zsarolóvírusok elleni védelemhez.

A cikkben szereplő parancsok csak Windowson használhatók; a kimenetüket Windows Server 2022 rendszergazdai parancssorában ellenőriztem. A termékek beállítási képernyői és árai változhatnak, ezért bevezetéskor nézze meg az egyes gyártók legfrissebb dokumentációját.

Sok szervezetnek volt mentése, mégsem tudott visszaállni

A japán Nemzeti Rendőrügynökség megkérdezi a zsarolóvírus-támadást elszenvedett szervezeteket a biztonsági mentéseik állapotáról. A 2025 első félévéről szóló jelentés szerint a választ adó 53 szervezet közül 51 készített biztonsági mentést. Azonban abból a 48-ból, amelyet arról kérdeztek, vissza tudott-e állni a mentésből a támadás előtti szintre, csak 7-nek sikerült, 41-nek nem¹.

A visszaállítás sikertelenségének okát megadó 35 szervezet közül 23 azt válaszolta, hogy „a mentéseket is titkosították”, 8 „üzemeltetési hiányosságot”, 4 pedig „egyéb” okot jelölt meg¹. Ugyanez a jelentés leírja, hogy a zsarolóvírus-csoportok a nyomaik eltüntetése és a helyreállítás megakadályozása érdekében törlik az áldozatok naplóit és biztonsági mentéseit. Ezután arra kéri a szervezeteket, hogy a mentéseket offline környezetben tárolják².

flowchart TB
        accTitle: Hogyan lehet mentés, mégsem sikerül a visszaállítás
        accDescr: Az ábra azt mutatja, hogy a biztonsági mentés akkor is titkosítva lesz minden mással együtt, ha a fertőzött gép eléri, és ha a visszaállítási eljárást nem ellenőrizték, üzemeltetési hiányosság miatt nem sikerül a visszaállítás.
        A["Van biztonsági mentés"] --> B{"Eléri a fertőzött gép?"}
        B -->|"Eléri"| C["Szintén titkosítják vagy törlik"]
        B -->|"Nem éri el"| D{"Ellenőrizték a visszaállítási eljárást?"}
        D -->|"Nem ellenőrizték"| E["Üzemeltetési hiányosság miatt nem állítható vissza"]
        D -->|"Ellenőrizték"| F["Visszaállítható"]

1. ábra: A biztonsági mentés akkor használható, ha a fertőzött gép nem éri el, és a visszaállítási eljárást ellenőrizték.

Vannak olyan esetek is, amikor a visszaállítás sikerült. Az IPA „Információbiztonsági irányelvek kkv-k számára” című kiadványának 4. kiadása bemutat egy építőipari céget, amelynek fájlkiszolgálóit és más rendszereit egy VPN-eszközön keresztüli behatolás után titkosították. Részben azért, mert a cég évente kétszer tartott visszaállítási gyakorlatot, a támadás felfedezése után öt nappal a biztonsági mentésekből újraindította az alaprendszereit. Ennek ellenére az egyes belső rendszerek újraindítása 41 napig, a távoli elérés helyreállítása négy hónapig tartott, és a cég elvesztette belső fájljainak több mint 20 százalékát³. Attól, hogy a mentésekből vissza lehet állni, a kár nem tűnik el.

Az ábrán a folytonos vonal mindig fennálló kapcsolatot, a szaggatott vonal feltételes kapcsolatot jelöl (a feltételeket a részletoldal kapcsolatonként ismerteti). A kapcsolatok teljes listája (összesen 13, bizonyítékokkal és megbízhatósági szinttel) és a fő fogalmak meghatározása a tudástérkép részletoldalán található (japánul). Adatok: JSON-LD / Turtle

A támadók törlik az általuk elérhető mentéseket

A CISA és más amerikai ügynökségek által kiadott #StopRansomware útmutató szerint sok zsarolóvírus megpróbálja megkeresni és törölni vagy titkosítani az elérhető biztonsági mentéseket, hogy az áldozat a váltságdíj kifizetése nélkül ne tudjon helyreállni. Ezért fontosnak tartja, hogy a mentéseket offline tárolják⁴.

A Microsoft is azt írja, hogy a támadók arra összpontosítanak, hogy használhatatlanná tegyék a biztonsági mentési szoftvereket és az operációs rendszer olyan funkcióit, mint a kötetárnyékmásolatok⁵. A fertőzött gép által elérhető mentések közé tartoznak a következők.

• A számítógéphez állandóan csatlakoztatott külső meghajtók
• Meghajtóbetűjelhez rendelt NAS- vagy fájlkiszolgáló-megosztások
• Felhőalapú szinkronizált mappák, amelyekbe a mindennapi fiók írhat
• Ugyanazon a köteten lévő árnyékmásolatok (Előző verziók)

Még az operációs rendszer beépített parancsaival is törölhetők az árnyékmásolatok és a biztonsági mentési katalógusok. A MITRE ATT&CK ezt a technikát „Inhibit System Recovery” (T1490) néven tartja nyilván. Példaként említi az összes árnyékmásolat törlését a vssadmin.exe delete shadows /all /quiet paranccsal, és a Windows biztonsági mentési katalógusának törlését a wbadmin.exe delete catalog -quiet paranccsal⁶. A CISA útmutatója azt is kéri, hogy a szervezetek figyeljék a vssadmin.exe, a wbadmin.exe, a wmic.exe (shadowcopy) és hasonló eszközök gyanús használatát⁴.

flowchart TB
        accTitle: Mentések, amelyeket a fertőzött gép elér és amelyeket nem
        accDescr: Az ábra azt mutatja, hogy a fertőzött gép írhat az állandóan csatlakoztatott külső meghajtókra, a hozzárendelt megosztásokra, a szinkronizált mappákba és az árnyékmásolatokba, de nem írhat a leválasztott adathordozókra és a felülírhatatlan tárhelyre.
        P["Fertőzött gép"] --> R["Helyek, ahová írhat"]
        P -.-x N["Leválasztott adathordozó, felülírhatatlan tárhely"]
        R --> A["Állandóan csatlakoztatott külső meghajtó"]
        R --> B["Hozzárendelt megosztott mappa"]
        R --> C["Felhőalapú szinkronizált mappa"]
        R --> D["Árnyékmásolatok"]

2. ábra: Azok a mentések, amelyek olyan helyen vannak, ahová a fertőzött gép írhat, a támadás célpontjává válnak.

Az időigényes támadásokra is figyelni kell. A Microsoft szerint a zsarolóvírusok néha fokozatosan titkosítanak, miközben a kulcsot a rendszeren hagyják. A felhasználók ezalatt a szokásos módon használhatják az adatokat, így senki sem veszi észre, hogy egyre gyűlnek a titkosított adatokról készült mentések. Amikor minden titkosítva van, és a kulcsot törlik, már a legutóbbi mentések sem olvashatók⁵. Ha csak a legutóbbi generációt őrzi meg, ebben az esetben nincs mihez visszatérni.

Az „Előző verziók” nem helyettesítik a biztonsági mentést

A Windows „Előző verziók” funkciója és a megosztott mappák árnyékmásolatai a kötet árnyékmásolata szolgáltatást (VSS) használják. A Windowshoz mellékelt VSS-rendszerszolgáltató másolás íráskor (copy-on-write) módszerrel dolgozik: egy blokk felülírása előtt a blokk tartalmát egy különbségterületre menti, és így állítja elő a kötet egy adott időpontbeli állapotát⁷.

A Microsoft a VSS dokumentációjában a következőképpen magyarázza az árnyékmásolat és a biztonsági mentés közötti különbséget. Amikor az árnyékmásolatból cserélhető adathordozóra, például szalagra másolják az adatokat, az adathordozó tartalma lesz a biztonsági mentés. A másolás után maga az árnyékmásolat törölhető⁷. A dokumentáció azt is leírja, hogy ha a különbségterület elfogy, először a régebbi árnyékmásolatok törlődnek⁷.

flowchart TB
        accTitle: Az árnyékmásolat és a biztonsági mentés közötti különbség
        accDescr: Az ábra azt mutatja, hogy az árnyékmásolat az eredeti kötethez képesti különbségek összessége, amely helyhiány esetén vagy egy támadó által törlődik, míg a külön adathordozóra másolt biztonsági mentés az eredeti kötet elvesztése után is megmarad.
        V["Eredeti kötet"] --> S["Árnyékmásolat (különbségek)"]
        S --> L["Helyhiány esetén a legrégebbi törlődik először"]
        S --> K["A támadó törli a vssadminnal"]
        S -->|"Másolás külön adathordozóra"| B["Biztonsági mentés"]
        B --> R["Az eredeti kötet elvesztése után is megmarad"]

3. ábra: Az árnyékmásolatok az eredeti kötet adataitól függenek; a biztonsági mentés az, amit külön adathordozóra másol.

Az árnyékmásolatok hasznosak ahhoz, hogy a felhasználók maguk állítsák vissza a véletlenül felülírt fájlokat. Ahogy azonban az előző szakaszban láttuk, a támadók néha törlik őket. A működésüket és az üzemeltetésüket részletesen a „Volume Shadow Copy (VSS): The Mechanism and the Practice” című cikk ismerteti.

Hogy mely árnyékmásolatok maradtak meg, a rendszergazdai parancssorban a vssadmin list shadows paranccsal listázhatja ki. Ez az alparancs ügyfél- és kiszolgálógépen is elérhető⁸.

vssadmin list shadows

A OneDrive és a SharePoint verzióelőzményei és lomtára szintén lehetővé teszik, hogy a felhasználók visszakapják a fájljaikat. A Microsoft azt javasolja, hogy tanítsa meg a felhasználóknak, hogyan állíthatják vissza a teljes OneDrive-ot egy korábbi időpontra. Azt is írja, hogy a felhasználók csak akkor állítsanak vissza, ha már biztos benne, hogy a támadót kiszorították, és készüljön fel arra az esetre, ha a felhasználók a kártevőt is visszaállítják⁵.

A 3-2-1 szabály meghatározza, hány példány legyen és hol

A 3-2-1 szabály ökölszabály arra, hogyan tartsa a biztonsági mentés példányait. A US-CERT számára 2012-ben készült „Data Backup Options” című dokumentum a következőképpen magyarázza⁹.

• 3: A fontos fájlokból tartson három példányt, az eredetit és két biztonsági mentést.
• 2: Tárolja őket kétféle adathordozón, hogy különböző típusú katasztrófák ellen is védve legyenek.
• 1: Egy példányt tartson az otthonán vagy a vállalkozásán kívül.

A dokumentum forrásként a „The DAM Book” című, digitális fényképek kezeléséről szóló könyvet nevezi meg, amelyet Peter Krogh fotográfus írt⁹. A Microsoft is hivatkozik erre a szabályra a zsarolóvírusok elleni biztonsági mentésről szóló dokumentációjában, és az „1”-et „telephelyen kívüli vagy hideg példányként” írja le⁵.

A 3-2-1 szabály azt kéri, hogy egy példány a telephelyen kívül legyen. Azt nem követeli meg, hogy ez a példány offline vagy felülírhatatlan legyen. Ha tehát a telephelyen kívüli példány olyan felhőben van, amelyre a fertőzött gép bármikor írhat, a helyi példányokkal együtt titkosíthatják. A CISA útmutatója és a Microsoft dokumentációja a zsarolóvírusok elleni védekezésként az offline tárolást nevezi meg. A Microsoft a felülírhatatlan tárhelyet is említi⁴⁵.

flowchart TB
        accTitle: A 3-2-1 szabály és a zsarolóvírus elleni védelem
        accDescr: Az ábra azt mutatja, hogy a három példányt, kétféle adathordozót és egy telephelyen kívüli példányt előíró 3-2-1 szabályt egy offline vagy felülírhatatlan példánnyal kell kiegészíteni, majd meg kell győződni a visszaállíthatóságról.
        A["Három példány"] --> B["Kétféle adathordozó"]
        B --> C["Egy a telephelyen kívül"]
        C --> D["Egy offline vagy felülírhatatlan"]
        D --> E["A visszaállíthatóság ellenőrzése"]

4. ábra: A 3-2-1 szabályt egészítse ki egy olyan példánnyal, amelyet a fertőzött gép nem tud felülírni, és a visszaállíthatóság ellenőrzésével.

A Veeam biztonsági mentési gyártó ezt „3-2-1-1-0 szabály” néven népszerűsíti. A Veeam dokumentációja szerint a további „1” egy offline, légréssel elválasztott vagy felülírhatatlan példány megtartását jelenti, a „0” pedig azt, hogy a rendszeres visszaállítás-ellenőrzés nulla hibát mutat¹⁰. Ez egy gyártói dokumentációban szereplő elnevezés, nem hivatalos szabvány. A két további elem ugyanakkor egybevág azzal, amit a CISA és az IPA kér.

Legyen egy példány, amelyet a fertőzött gép nem tud felülírni

A felülírhatatlan példány elkészítésének két fő módja van: az adathordozót leválasztja a számítógépről és elteszi, vagy olyan felhőtárhelyet használ, amelyben az adatok egy meghatározott ideig nem írhatók felül és nem törölhetők. Bármelyiket választja, a biztonsági mentés kezeléséhez szükséges jogosultságokat válassza el a mindennapi munkától.

Válassza le az adathordozót a gépről, és tárolja külön

Az IPA irányelvei az önértékelés egyik példaintézkedéseként azt írják, hogy a biztonsági mentéshez használt eszközöket és adathordozókat csak a mentés idejére csatlakoztassa a számítógéphez. Felsorolja azt is, hogy határozza meg a mentés módját, tárolja biztonságos helyen, és rendszeresen ellenőrizze, hogy vissza lehet-e állni belőle¹¹.

A továbblépni kívánó szervezetek számára az irányelvek a „fizikai elkülönítést” említik. Ez azt jelenti, hogy a mentéseket az eredeti rendszertől fizikailag távol eső helyen tartják, a külső tárolókat vagy a mentési szalagokat a lehető legmesszebb tárolják. A tárolási helyre példaként a banki széfet, illetve egy megbízható üzleti partnert vagy kapcsolt vállalkozást hoz¹².

Az így, az éles rendszerektől leválasztva tárolt mentést offline mentésnek nevezzük. A leválasztott adathordozóra a fertőzött gép nem tud írni. Viszont az adathordozót embereknek kell újra csatlakoztatniuk és szállítaniuk, így előfordul, hogy egy mentés elmarad, vagy az adathordozót nem viszik el a telephelyről. Határozza meg, ki és mikor csatlakoztatja és választja le az adathordozót, és ki viszi el a tárolási helyre.

Használjon felülírhatatlan felhőtárhelyet

A felhőtárhelyeknek vannak olyan funkcióik, amelyek egy meghatározott ideig megakadályozzák az adatok felülírását vagy törlését. Ezek az adatokat WORM (Write Once, Read Many) állapotban tárolják.

Az Azure Blob Storage nem módosítható tárolójában, ha időalapú megőrzési szabályzatot állít be, az adatok ebben az időszakban létrehozhatók és olvashatók, de nem módosíthatók és nem törölhetők¹³. A szabályzat először zárolatlan állapotban jön létre, és tesztelés után zárolja. A zárolt szabályzat nem törölhető, a megőrzési időszaka meghosszabbítható, de nem rövidíthető¹³. A Microsoft szerint még a fiók rendszergazdai jogosultságával rendelkező felhasználók sem módosíthatják vagy törölhetik az adatokat¹³.

Az Amazon S3 Object Lock két móddal rendelkezik. Megfelelőségi (compliance) módban a megőrzési időszak alatt senki, az AWS-fiók gyökérfelhasználóját is beleértve, nem írhatja felül és nem törölheti az objektumverziót. Irányítási (governance) módban csak a különleges jogosultsággal rendelkező felhasználók módosíthatják vagy távolíthatják el a megőrzési beállításokat¹⁴. Az Object Lock csak olyan bucketekben használható, amelyekben engedélyezve van az S3 verziókezelés¹⁴.

flowchart TB
        accTitle: Két példa felülírhatatlan tárhelyre
        accDescr: Az ábra azt mutatja, hogy az Azure Blob Storage nem módosítható tárolójában a zárolt szabályzat nem törölhető és a megőrzési időszaka nem rövidíthető, az S3 Object Lockkal pedig megfelelőségi módban még a gyökérfelhasználó sem törölhet, irányítási módban viszont különleges jogosultsággal módosítani lehet.
        W["Felülírhatatlan tárhely"] --> AZ["Az Azure Blob Storage nem módosítható tárolója"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["Zárolás után a megőrzés nem rövidíthető"]
        S3 --> C["Megfelelőségi mód"]
        S3 --> G["Irányítási mód"]
        C --> C1["Még a gyökérfelhasználó sem törölhet"]
        G --> G1["Különleges jogosultsággal módosítható"]

5. ábra: Mindkét tárhely egy meghatározott ideig megtagadja a felülírást és a törlést; hogy mennyire szigorúan, az a beállításoktól függ.

Az Azure-ban, ha a szabályzat zárolása után veszi észre a beállítási hibát, a megőrzési időszak akkor sem rövidíthető¹³. A CISA útmutatója megjegyzi, hogy egyes felhőszolgáltatók kínálnak felülírhatatlan tárhelyet, és figyelmeztet, hogy a hibás beállítás jelentős költségekkel járhat. Azt is említi, hogy az ilyen tárhely nem minden esetben felel meg bizonyos szabályozások követelményeinek⁴. Ha hosszú megőrzési időszakot állít be, és zárolja, ebben az időszakban nem törölheti az adatokat, és a tárolási díj folyamatosan felmerül. Kezdje zárolatlan állapottal vagy rövid időszakkal, győződjön meg arról, hogy vissza tud állni, és csak utána alkalmazza az éles beállításokat.

Válassza szét a biztonsági mentés kezelésének jogosultságait

Még ha felülírhatatlan tárhelyet használ is, ha a mentési beállításokat és szabályzatokat a mindennapi rendszergazdai fiókkal módosítani lehet, egy támadó is módosíthatja őket. A Microsoft azt javasolja, hogy az online mentések módosítása vagy törlése előtt követeljen meg egy további lépést, például többtényezős hitelesítést vagy biztonsági PIN-kódot. Azt is felsorolja, hogy a mentési és visszaállítási műveleteket korlátozza a kijelölt szerepkörű felhasználókra, és csökkentse azoknak a fájlmegosztásoknak a számát, amelyekbe sok felhasználó írhat és amelyekből törölhet⁵.

Még ha ugyanaz a személy kezeli is a számítógépeket és a mentéseket, a mentési cél kezelésére szolgáló fiókot ne használja a mindennapi bejelentkezéshez, és védje többtényezős hitelesítéssel.

Őrizzen meg több generációt

Az IPA irányelvei a „generációkezelést” említik, vagyis több időpontból származó mentések megőrzését. Ez lehetővé teszi, hogy az adatok sérülése vagy elvesztése esetén egy adott időpontra térjen vissza¹². Ahogy egy korábbi szakaszban láttuk, ha időbe telik a titkosítás észrevétele, a legutóbbi mentések már titkosított adatokat tartalmaznak. Azt, hogy hány generációt őriz meg, aszerint döntse el, mennyi időbe telhet a titkosítás észrevétele, és mennyibe kerül a tárolás.

flowchart TB
        accTitle: Három intézkedés egy felülírhatatlan példány megtartásához
        accDescr: Az ábra azt mutatja, hogy a leválasztott adathordozót el kell tenni vagy felülírhatatlan tárhelyet kell használni, a mentések kezelésének jogosultságait el kell választani a mindennapi fiókoktól, és több generációt kell megőrizni.
        A["Felülírhatatlan példány"] --> B["Leválasztott adathordozó tárolása"]
        A --> C["Felülírhatatlan tárhely"]
        B --> D["Kezelési jogosultságok szétválasztása"]
        C --> D
        D --> E["Több generáció megőrzése"]

6. ábra: Miután eldöntötte, hol tartja, válassza szét a kezelési jogosultságokat, és őrizzen meg generációkat, hogy késői észrevétel esetén is vissza tudjon térni.

Győződjön meg arról, hogy vissza tud állni

A Nemzeti Rendőrügynökség jelentésében a visszaállítás sikertelenségének második leggyakoribb oka az „üzemeltetési hiányosság” volt¹. Hogy egy mentés ténylegesen visszaállítható-e, csak akkor derül ki, ha kipróbálja. Ezt a munkát, amikor a mentésből ténylegesen visszaállít, hogy ellenőrizze ezt, visszaállítási tesztnek nevezzük.

Az IPA irányelvei a biztonsági mentés üzemeltetését három részre bontják: a mentés készítésére, tárolására és a visszaállításra. A visszaállításnál azt kérik, hogy készítsen helyreállítási tervet, és győződjön meg arról, hogy helyesen vissza tud állni³. Az üzleti szempontból kritikus rendszereknél azt kérik, hogy a mentések készítését és az eljárásokat a helyreállítási időcélhoz (RTO) és a helyreállítási pontcélhoz (RPO) igazítsa, és gyakorlatokkal ellenőrizze a hatékonyságukat. Az RTO az az idő, amely alatt a célzott szintre vissza kell állni, az RPO pedig az az időpont, amelyre visszaáll, vagyis a legutóbbi mentés időpontja¹⁵. A CISA útmutatója is azt kéri, hogy a katasztrófa utáni helyreállítást szem előtt tartva rendszeresen ellenőrizze, hogy a mentések használhatók és sértetlenek-e⁴.

flowchart TB
        accTitle: Hogyan végezzen visszaállítási tesztet
        accDescr: Az ábra azt a folyamatot mutatja, amelyben eldönti a visszaállítás sorrendjét, egy külön környezetbe állít vissza, összeveti a felhasznált időt és a visszaállított időpontot az RTO-val és az RPO-val, majd javítja az eljárásleírást.
        A["A visszaállítás sorrendjének eldöntése"] --> B["Visszaállítás külön környezetbe"]
        B --> C["A felhasznált idő összevetése az RTO-val"]
        B --> D["A visszaállított időpont összevetése az RPO-val"]
        C --> E["Az eljárásleírás javítása"]
        D --> E
        E -.->|"Következő ellenőrzés"| A

7. ábra: Próbálja ki a visszaállítást, ellenőrizze, hogy az idő és az időpont megfelel-e a céloknak, és az eredményeket vezesse vissza az eljárásleírásba.

Mit kell ellenőrizni?

Az IPA és a Microsoft dokumentációja alapján az ellenőrizendő elemek a következőképpen rendezhetők.

A Microsoft azt javasolja, hogy először azonosítsa az üzlet szempontjából kritikus rendszereket, és rendszeresen mentse őket. Az így létrejövő, prioritás szerint rendezett mentési lista egyben a visszaállítás sorrendje is lesz. Magas prioritásként elsőként az olyan hitelesítési rendszereket említi, mint az Active Directory, amelyek minden más rendszerbe való belépéshez szükségesek⁵. Azt is javasolja, hogy rendszeresen gyakorolja az üzleti működés újraindítását abból az állapotból, amikor minden rendszer leállt. Ezekben a gyakorlatokban abból induljon ki, hogy az e-mail és a csevegés sem érhető el⁵.

A Microsoft azt írja, hogy a támadók szándékosan célba veszik a visszaállítási eljárásleírásokat és a hálózati ábrákat. Azt javasolja, hogy védje őket, vagy tartson kéznél nyomtatott példányokat⁵. Ha az eljárásleírás csak a fájlkiszolgálón van meg, nem tudja elolvasni, amikor éppen az a fájlkiszolgáló lesz titkosítva.

Mire figyeljen a támadás utáni visszaállításkor?

Egy valódi támadás után a visszaállítás előtt távolítsa el magát a zsarolóvírust a környezetből⁵. A Microsoft azt említi, hogy olyan időpontból származó mentést válasszon, amelyről tudni lehet, hogy fertőzésmentes, és a visszaállítás előtt vizsgálja át a mentést kártevők után kutatva⁵. A Nemzeti Rendőrügynökség jelentése szerint a zsarolóvírus-csoportok néha távolról irányítható szoftvert telepítenek hátsó ajtóként, hogy a behatolási pont lezárása után is vissza tudjanak jutni². A visszaállítás előtt ki kell vizsgálni a behatolás útvonalát és mindazt, amit a támadók hátrahagytak.

flowchart TB
        accTitle: A mentésből történő visszaállítás sorrendje támadás után
        accDescr: Az ábra azt mutatja, hogy el kell távolítani magát a zsarolóvírust és a behatolás útvonalát, ki kell választani egy fertőzésmentes időpontból származó mentést, át kell vizsgálni kártevők után kutatva, majd a legmagasabb prioritású rendszereket kell először visszaállítani.
        A["Magának a zsarolóvírusnak az eltávolítása"] --> B["A behatolás útvonalának és a hátrahagyott elemeknek a vizsgálata"]
        B --> C["Fertőzésmentes időpont kiválasztása"]
        C --> D["A mentés átvizsgálása"]
        D --> E["A legmagasabb prioritásúak visszaállítása először"]

8. ábra: Támadás után távolítsa el, amit a támadók hátrahagytak, és győződjön meg egy fertőzésmentes időpontról, mielőtt visszaállít.

Milyen gyakran kell ellenőrizni?

Az IPA irányelvei és a CISA útmutatója is azt kéri, hogy „rendszeresen” győződjön meg a visszaállíthatóságról, de számot egyik sem ad meg¹¹⁴. A korábban bemutatott IPA-esetben szereplő cég évente kétszer tartott visszaállítási gyakorlatot³. Döntse el, mennyi ideig állhat a működés, és milyen régi lehet a visszaállított állapot, majd olyan gyakorisággal ellenőrizzen, amellyel meg tud győződni arról, hogy ezeket teljesíti.

Mit kell először eldönteni

Az eddigiek összefoglalhatók abban, amit egy kkv-nak először el kell döntenie.

flowchart TB
        accTitle: A zsarolóvírusnak ellenálló biztonsági mentésről hozott döntések sorrendje
        accDescr: Az ábra azt a sorrendet mutatja, amelyben eldönti a hatókört, a példányok helyét és a felülírhatatlan példányt, a jogosultságokat és a generációkat, az RTO-t és az RPO-t, majd meggyőződik a visszaállíthatóságról.
        A["A hatókör eldöntése"] --> B["A példányok helyének eldöntése"]
        B --> C["A felülírhatatlan példány eldöntése"]
        C --> D["A jogosultságok és a generációk eldöntése"]
        D --> E["Az RTO és az RPO eldöntése"]
        E --> F["A visszaállíthatóság ellenőrzése"]

9. ábra: Egyetlen folyamatban döntsön mindenről, a hatókörtől egészen a visszaállíthatóság végső ellenőrzéséig.

Az IPA irányelveinek 4. kiadásában a „Készítsen biztonsági mentést!” pont bekerült a szervezetek kiindulópontjául szolgáló „5 információbiztonsági szabály” közé, így ezek 6 szabállyá bővültek¹⁶. Az irányelvek egészének feldolgozását a „Where Should SMEs Start on Security?” című cikk foglalja össze. Ha kiszolgálócserét tervez, olvassa el a „Preparing for Windows Server 2016 End of Support” című cikket is.

Kapcsolódó cikkek

• 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

Források

Kapcsolódó cikkek

Azonos címkéket használó, legfrissebb cikkek. Mélyítse el ismereteit szorosan kapcsolódó témákban.

Kapcsolódó témák

Ehhez a témához közel álló témaoldalak. A cikkből kiindulva eljuthat a kapcsolódó szolgáltatásokhoz és további cikkekhez.

Mely szolgáltatásokhoz kapcsolódik ez a téma

Ez a cikk a következő szolgáltatási oldalakhoz kapcsolódik. Kezdje azzal, amelyik a leginkább illik az Ön helyzetéhez.

Gyakori kérdések

A cikk témájával kapcsolatban a konzultációk során gyakran felmerülő kérdések.

Ha készítek biztonsági mentést, zsarolóvírus-fertőzés után mindent vissza tudok állítani?

Gyakran a mentés puszta megléte nem elég a visszaállításhoz. A japán Nemzeti Rendőrügynökség 2025 első félévi összesítésében a biztonsági mentést készítő és választ adó 48 szervezet közül 41 nem tudta visszaállítani az adatait a támadás előtti szintre. A leggyakoribb ok az volt, hogy a mentéseket is titkosították. Kell egy olyan példány, amelyet a fertőzött gép nem tud felülírni, és meg kell győződni arról, hogy abból vissza lehet állni.

Ha a Windowsban ott vannak az Előző verziók, akkor is kell biztonsági mentés?

Igen. Az Előző verziók kötetárnyékmásolatok, vagyis az eredeti köteten tárolt különbségek. A Microsoft azt tekinti biztonsági mentésnek, amit az árnyékmásolatból például szalagra másolnak. A zsarolóvírusok a vssadmin és hasonló eszközök segítségével néha törlik az árnyékmásolatokat, ezért kombinálja őket külön adathordozóra készített mentéssel.

Elég-e a 3-2-1 szabály betartása a zsarolóvírus elleni védelemhez?

Nem mindig. A 3-2-1 szabály három példányt, kétféle adathordozót és egy telephelyen kívüli példányt ír elő, de azt nem követeli meg, hogy a telephelyen kívüli példány offline vagy felülírhatatlan legyen. Egy olyan felhőbeli példányt, amelyre a fertőzött gép bármikor írhat, ugyanúgy titkosíthatnak. Adjon hozzá egy offline adathordozón vagy felülírhatatlan tárhelyen lévő példányt.

Milyen gyakran ellenőrizzem, hogy vissza tudok-e állni a mentésből?

Az IPA irányelvei és a CISA útmutatója is csak annyit mond, hogy „rendszeresen”, számot nem ad meg. Az IPA irányelveiben szerepel egy cég, amely évente kétszer tartott visszaállítási gyakorlatot, és a támadás felfedezése után öt nappal újraindította az alaprendszereit. Döntse el, mennyi ideig állhat a működés, és milyen régi lehet a visszaállított állapot, majd olyan gyakorisággal ellenőrizzen, amellyel meg tud győződni arról, hogy ezeket teljesíteni tudja.

A szerző bemutatása

A cikk szerzőjének bemutatkozó oldala.

Go Komura

A KomuraSoft LLC képviselője

Fő területei a Windows-szoftverfejlesztés, a műszaki konzultáció és a hibakeresés; különösen a meglévő megoldásokat érintő projektekben, valamint a nehezen felderíthető okú hibák kivizsgálásában erős.