Zsarolóvírus és a felhő: megvédi Önt a felhőmentés?

A zsarolóvírus olyan kártevő, amely titkosítja az adatokat, majd váltságdíjat kér a visszafejtésért — és a leggyakoribb tévhit vele kapcsolatban az, hogy a felhő önmagában megvéd tőle. Nem véd meg. Ha „felhőmentés” alatt azt érti, amit a Microsoft 365 vagy a Google Workspace alapból megőriz — lomtár, verziótörténet, visszaállítási pont —, akkor ezek rendelkezésre állási és rövid távú visszavonási funkciók, nem mentések. A zsarolóvírus pedig kifejezetten jól teljesít abban, hogy ezeket az ablakokat kifussa.

Az alábbiakban végigvesszük, hogyan jut el a titkosítás a felhőbe, meddig ér el a natív helyreállítás, és mitől lesz egy másolat valóban helyreállításra alkalmas.

Hogyan jut be a zsarolóvírus a felhőbe

A támadás ritkán a SaaS-szolgáltató infrastruktúráját éri. Egy azonosítót ér, majd azt az azonosítót pontosan úgy használja, ahogyan a rendszer elvárja.

Két út végzi el a munka nagy részét:

A szinkronizáló kliens. A OneDrive és a Google Drive asztali kliense arra való, hogy a helyi változásokat felvigye a felhőbe. Egy fájl titkosítva lesz a munkaállomáson, a tartalma megváltozik, a kliens pedig teszi a dolgát: feltölti a változást. Nincs olyan jelzés, amiből meg tudná különböztetni a titkosítási futást egy szokatlanul termékeny délutántól. A kártevő hozzá sem ér a felhőszolgáltatáshoz — a saját szinkronizáló ügynökével vitetteti át a kárt.

Hitelesített alkalmazás vagy token. Egy feltört fiók, egy rosszindulatú OAuth-hozzájárulás vagy egy ellopott munkamenet a platform saját API-jain keresztül dolgozhat: olvashat, felülírhat és törölhet, API-sebességgel, bárhonnan, munkaállomás nélkül. A platform szemszögéből ez egy jogosult felhasználó, aki gyorsan dolgozik.

Mindkét esetben a titkosítás a bejárati ajtón, hitelesítve érkezik. A replikáció és a földrajzi redundancia — amiben a felhő valóban kiváló — ilyenkor Ön ellen dolgozik: megbízhatóan sokszorosítja a titkosított változatot.

Meddig ér el a natív helyreállítás

A beépített eszközök nem értéktelenek. Érdemes viszont pontosan tudni, hol a határuk.

Microsoft 365. A OneDrive Files Restore funkciójával az elmúlt 30 nap fájl- és mappaműveletei vonhatók vissza, beleértve a törölt, felülírt, sérült vagy kártevő által érintett tartalmat, és munkahelyi vagy iskolai fiókkal is működik. Ez valódi tömeges visszagörgetés, és egy időben észrevett, körülhatárolt incidensnél elég is lehet. A korlátai ugyanilyen világosak: 30 napon túl nincs mit visszahozni, a Microsoft pedig egyértelműen közli, hogy a OneDrive lomtárából véglegesen törölt fájl soha nem állítható helyre. A lomtár-határidőket részletesen a OneDrive és SharePoint lomtárról szóló írásunkban vettük végig.

Google Workspace. A Drive megőrzi a korábbi verziókat, de a Google dokumentálja a plafont: egy verzió 30 nap után, vagy ha már 100 újabb verzió született, véglegesen törlődhet — hacsak valaki kifejezetten meg nem jelölte megőrzésre. Egy olyan kártevő, amely ismételten újraírja a fájlokat, meglehetősen hatékonyan éli fel ezt a 100 verziót.

A natív helyreállítás tehát időben és darabszámban korlátozott visszavonás. Az aznap észrevett incidenssel szemben jól tartja magát. Három gyakori esettel szemben rosszul:

• Hosszú lappangás. Aki hat hétig csendben ül a rendszerben, mielőtt titkosít, addigra kiöregítette a tiszta verziókat a 30 napos ablakból.
• Méret. Néhány fájl visszaállítása verziótörténetből rendben van. Több százezer fájlé, felhasználókon és webhelyeken át, tömeges időpont szerinti visszaállítás nélkül, napokban mérhető leállás.
• Adminisztrátori törlés. A lomtár ürítése, a megőrzési idő lerövidítése, webhelyek és postafiókok eltávolítása mind hétköznapi adminisztrátori művelet. Akinél adminisztrátori jogosultság van, az magát a visszavonási előzményt is el tudja tüntetni — és egy felkészült támadó ezzel kezdi.

A megőrzési szabály nem mentés

Erre a leggyakoribb válasz az, hogy „nálunk be van állítva a megőrzési szabály”. A megőrzés megfelelőségi kontroll: azt szabályozza, meddig kell megtartani a tartalmat, és megakadályozza az idő előtti törlést. Hasznos, de nem mentés, egyetlen szerkezeti okból: ugyanabban a bérlői környezetben, ugyanazon adminisztrátori azonosító alatt, a betörés ugyanazon oldalán él. Akinek jogosultsága van tömegesen titkosítani, annak jellemzően ahhoz is van, hogy módosítsa azt a szabályt, amelynek meg kellett volna őt fékeznie.

Ugyanez a próba minden másolatra alkalmazható. Kérdezze meg: ha a SaaS-bérlőt kezelő azonosító teljesen kompromittálódik, ez a másolat túléli? Ha nem, akkor redundancia, nem helyreállítás. Ez a megosztott felelősségi modell szokásos működése: a szolgáltató a szolgáltatás rendelkezésre állásáért felel, az Ön adatainak visszahozhatósága a saját felhasználói műveletekből viszont az Ön oldalán marad.

Mitől lesz egy másolat zsarolóvírus-álló

Négy tulajdonság végzi az érdemi munkát:

1. Külön bizalmi határ. A SaaS-bérlőn kívüli tárolás, olyan hitelesítő adatokkal, amelyek nem azonosak a Microsoft 365 vagy a Google Workspace adminisztrátori belépésével. Az egyik feltörése nem adhatja oda a másikat.
2. Módosíthatatlan vagy csak bővíthető megőrzés. Olyan mentési adat, amely a megőrzési idején belül nem szerkeszthető és nem törölhető — sem támadó, sem nyomás alatt vagy tévedésből cselekvő adminisztrátor által.
3. Tömeges, időpont szerinti visszaállítás. Az a képesség, hogy kimondható legyen: „ezt a webhelyet, ezt a postafiókot, ezt a Drive-ot a 14-ei 03:00-s állapotra” — és ez tömegesen történjen meg, ne fájlonként.
4. Anomáliafigyelés. A tömeges titkosításnak és törlésnek felismerhető alakja van: szokatlan változási ütem, szokatlan fájltípusok, hajnali aktivitás. A korai észlelés tartja a tiszta visszaállítási pontot az ablakon belül. Az észlelés nem megelőzés: nem állítja meg a támadást, hanem lerövidíti azt az időt, amíg Ön nem tud róla — és általában ez a különbség egy rossz nap és egy rossz negyedév között.

Van egy ötödik, gyakorlati szempont is: a valóban kipróbált visszaállítás. A nem tesztelt mentés csak feltételezés. Nem azon a napon kellene először megtudni, mennyi ideig tart egy teljes helyreállítás, amikor szükség van rá.

Ami magyar szempontból is számít

A NIS2 hatálya alá tartozó hazai szervezeteknél a helyreállíthatóság nem csupán üzemeltetési kérdés, hanem bizonyítási kötelezettség is: az üzletmenet-folytonosságot és az adatok visszaállíthatóságát dokumentálni és tesztelni kell. Ezt a részt részletesen a NIS2 SaaS mentési követelményeiről szóló írásunk járja körül. Egy tömeges titkosítás után nem elég visszaállítani az adatot — azt is meg kell tudni mutatni, mikor mi veszett el, és mi az, ami hiánytalanul visszatért.

Amit érdemes még ma megválaszolni

• Ha ma éjjel egy munkatárs gépén titkosításra kerül minden szinkronizált fájl, meddig tudjuk visszagörgetni, és ki csinálja meg?
• Az első vagy a negyvenedik napon vennénk észre?
• Ha a globális adminisztrátori fiókunk kompromittálódik, melyik másolat marad elérhetetlen a támadó számára?
• Mennyi ideig tart a legnagyobb munkaterhelésünk teljes visszaállítása, és mikor próbáltuk ki utoljára?

Ezekhez a válaszokhoz nem kell szállító, csak fél óra és őszinteség. A platform-specifikus változatot a Microsoft 365 zsarolóvírus utáni helyreállításáról szóló írásunk tárgyalja.

Segítünk kiválasztani a felállásához illő megoldást, üzembe helyezni és elindítani a védelmet — a platformot Ön birtokolja és üzemelteti. Ha egyenes választ szeretne arra, hol szakadna el a jelenlegi beállítása, egy felmérés rövid, gyakorlatias áttekintést ad arról, mit tud ma visszaállítani, és mit nem.