Zsarolóvírus helyreállítási terv SaaS-adatokra

A zsarolóvírus helyreállítási terv SaaS-környezetben nem szervermentési kézikönyv, hanem egy rövid, konkrét dokumentum, amely öt kérdésre előre megválaszolja a választ: melyik munkaterhelés meddig állhat, mennyi adat veszhet el elfogadható mértékben, hol van olyan tiszta másolat, amelyet a támadó azonosítója nem ér el, ki jogosult incidenst kihirdetni és visszaállítást indítani, és melyik bejelentési határidő indul el abban a pillanatban, amikor Önök tudomást szereznek az esetről. A Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud esetében nem Önöké az infrastruktúra, így a klasszikus katasztrófa-helyreállítás eszközei nagyrészt kiesnek — a visszaállítási pontot pedig, amiről mindenki azt hiszi, hogy ő határozza meg, valójában az egyes platformok beépített megőrzési ablaka szabja meg Önök helyett.

Az alábbiakban végigvesszük, milyen három számra épül a terv, mit változtat ezeken a SaaS, mely döntéseket kell előre meghozni, mert az incidens közben már visszafordíthatatlanok, és milyen bejelentési órák futnak párhuzamosan a visszaállítással.

A három szám, amire a zsarolóvírus helyreállítási terv épül

A szakterületnek van kialakult szókincse, és érdemes pontosan használni. A NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems) meghatározásai:

• MTD (maximum tolerable downtime) — az a teljes kiesés, amelyet az adott folyamat még elviselhetőnek tart.
• RTO (recovery time objective) — az a leghosszabb idő, ameddig egy rendszererőforrás elérhetetlen maradhat anélkül, hogy az más erőforrásokra, a támogatott üzleti folyamatokra és az MTD-re elfogadhatatlan hatással lenne. Az útmutató kiemeli: az RTO-nak jellemzően rövidebbnek kell lennie az MTD-nél, mert a visszaállított adatok újrafeldolgozása is időt vesz igénybe.
• RPO (recovery point objective) — az a múltbeli időpont, ameddig az üzleti folyamat adatai a legutolsó mentés alapján visszaállíthatók. Vagyis gyakorlatilag azt fejezi ki, mennyi adatvesztést tolerál a folyamat.

A zsarolóvírus az RPO-t másképp feszíti meg, mint egy hétköznapi üzemzavar. Lemezhiba esetén a legfrissebb másolat kell — az RPO annyi, amennyi ideje az készült. Titkosítás esetén viszont éppen a legfrissebb másolat a sérült. Az a visszaállítási pont kell, amely a támadó tevékenysége előtti állapotot tükrözi, és ha a támadó hat hétig csendben ült a rendszerben, akkor ez hat héttel korábbi állapot. A tervezés kérdése tehát nem az, hogy „mennyire friss a legutolsó másolatunk”, hanem hogy meddig tudunk visszanyúlni, és ez több-e, mint amennyi ideje a támadó bent van.

SaaS-ban a platform határozza meg a visszaállítási pontot

Ez az a pont, ahol a SaaS-terv eltér a hagyományos géptermi tervtől. Saját hardveren Önök állítják be a mentési ütemezést, és ebből következik az RPO. SaaS-ban viszont, ha csak azok a másolatok léteznek, amelyeket a szolgáltató tart fenn, akkor a tényleges RPO az ő beépített ablaka lesz: olyan szám, amelyet a szervezetben senki nem választott, amely munkaterhelésenként más, és amelyet a hétköznapi felhasználói viselkedés tovább rövidít.

Munkaterhelés	Mit ad valójában a beépített megőrzés
OneDrive és SharePoint	A két lomtárszint egyetlen 93 napos ablakon osztozik, az eredeti törléstől számítva — nem 93-93 nap (részletek)
Exchange Online	A törölt elemek megőrzése alapból 14 nap, amit az adminisztrátor legfeljebb 30 napra emelhet; a „soft-deleted” postafiók kb. 30 napig él (a három óra)
Gmail és Drive	30 napos lomtár és egy kb. 25 napos adminisztrátori ablak — a Gmailnél a törlés dátumától, a Drive-nál viszont a lomtár kiürítésétől indul (miért kerül ez hetekbe)
Slack	Amit a munkaterület megőrzési beállítása mond. Az üzenettörlés véglegesen történik, az ingyenes csomagokban pedig fix ablak szerint gördül ki az adat (mit őriz meg valójában)
Jira és Confluence Cloud	A törölt projektekre és terekre kemény 60 nap jár; a törölt Confluence-oldalakra nincs közzétett lejárat; egy törölt Bitbucket-tárolót a saját klónjukból kell újraépíteni (a natív korlátok)

Ha ezt a táblázatot RPO-plafonok listájaként olvassuk, két dolog következik belőle. Először: mindegyik hetekben mérhető, vagyis ugyanabban a nagyságrendben van, mint a támadói lappangás — ez kellemetlenül kevés egy olyan számnál, amelyre az üzletmenetet teszik fel. Másodszor: ezek az ablakok nem stabilak. Egy felhasználó kiüríti a Drive lomtárát, egy adminisztrátor tárhely-rendezés közben kiüríti a lomtárat, vagy kilépéskor visszavonják a licencet — mindhárom rövidíti az ablakot anélkül, hogy bárki döntött volna róla.

Az a terv tehát, amely szerint „a beépített megőrzésre támaszkodunk”, nem RPO-t határoz meg. Azt jelenti be, hogy az RPO ismeretlen és mozog. Az alternatíva egy független másolat, amelynek a megőrzési idejét Önök állítják be, és amely a bérlői bizalmi határon kívül van — ugyanez a következtetés a másik irányból megközelítve a felhőmentés és a zsarolóvírus kérdésénél.

Amit előre kell eldönteni, nem az incidens közben

Incidens alatt improvizálnak az emberek, és néhány improvizáció visszafordíthatatlan. Ezeket érdemes most, nyugodt állapotban írásba adni:

• Ki hirdet incidenst. Egy megnevezett szerepkör, amely kimondhatja, hogy „ez zsarolóvírus-incidens”, és elindítja a tervet — plusz egy helyettes. Az itteni bizonytalanság órákba kerül, éppen ott, ahol az órák mindent eldöntenek.
• Állandó felhatalmazás az elszigetelésre. A munkamenetek és alkalmazás-tokenek visszavonása, egy azonosító letiltása és az asztali szinkronizáló kliensek leállítása olyan lépések, amelyek megakadályozzák a kár továbbterjedését a felhőbe. Ha ezekhez külön engedélykérés kell, későn fognak megtörténni.
• Senki nem ürít semmit. A lomtárak kiürítése és a „takarítsuk fel a káoszt” jellegű törlések a vizsgálat közben pontosan azt az anyagot semmisítik meg, amelyre a visszaállításhoz szükség lesz. Ez legyen kimondott tilalom, megnevezett kivételkezelővel.
• A kilépési folyamat áll. A licenc visszavonása vagy a fiók törlése más — jellemzően rövidebb — órát indít el az illető leveleire és fájljaira. Nyitott incidens alatt a rutin kilépéskezelés szüneteljen.
• A megőrzési beállítások zárolva. Egy megőrzési szabály lerövidítése incidens közben nem visszavonható. Ahogy egy Slack-csatorna törlése sem, amely teljesen kikerüli a munkaterületi megőrzést.
• Visszaállítási sorrend. Melyik három munkaterhelés jön vissza először, és ki igazolja, hogy a választott visszaállítási pont tiszta, mielőtt élő adatra írják. A titkosított változat visszaállítása egy jó állapot fölé valódi és gyakori módja annak, hogy egy incidens súlyosabb legyen.

Ehhez nem kell eszköz. Ahhoz kell, hogy ezeket a vitákat előre lefolytatták.

A visszaállítás mellett futó órák

A technikai helyreállítás nem az egyetlen határidős tétel, és a bejelentési órák rövidebbek, mint a legtöbb visszaállítás.

A NIS2 hatálya alá tartozó szervezeteknél a 21. cikk (2) bekezdés c) pontja kifejezetten a kötelező kockázatkezelési intézkedések közé sorolja az üzletmenet-folytonosságot — ideértve a mentések kezelését és a katasztrófa utáni helyreállítást —, valamint a válságkezelést. Vagyis maga a terv a kontroll. A 23. cikk (4) bekezdése ezután megadja a jelentési ütemet: korai figyelmeztetés 24 órán belül attól, hogy a szervezet tudomást szerzett a jelentős incidensről, incidensbejelentés 72 órán belül a súlyosság és a hatás előzetes értékelésével, valamint a rendelkezésre álló kompromittálódási jelzőkkel, kérésre időközi jelentés, majd zárójelentés az incidensbejelentéstől számított egy hónapon belül. A hatályt és a bizonyítási kérdéseket a NIS2 és a SaaS-mentés írásunk tárgyalja.

A GDPR oldalán az a zsarolóvírus-eset is adatvédelmi incidens, amely csak titkosít és nem visz ki adatot — a rendelkezésre állás elvesztése önmagában incidensnek minősül. Ez a NIS2-től függetlenül indítja el a 33. cikk szerinti, szintén 72 órás értékelést, hazai megkeresés esetén a NAIH felé (részletek).

Ennek gyakorlati következménye a tervre: miközben valaki visszaállít, valaki másnak tényszerű időrendet kell vezetnie. Ha ugyanaz a személy végzi mindkettőt, akkor az egyik nem történik meg. Írják le a két sávot külön, névvel.

Hét lépés, SaaS-ra igazítva

A NIST hétlépéses folyamata itt is jól használható; csak a tartalom más.

1. Szabályzat. Rövid nyilatkozat arról, ki felel a helyreállítás-tervezésért, és hogy ez kifejezetten kiterjed a SaaS-munkaterhelésekre is — a legtöbb szabályzat még akkor készült, amikor minden szerveren volt.
2. Üzleti hatáselemzés. Munkaterhelésenként, nem rendszerenként: mi áll meg, ha az Exchange Online egy napra elérhetetlen, ha a Jira-projekt előzménye eltűnik, ha az a Slack-csatorna olvashatatlan, ahol a döntések születtek. Innen jön az MTD.
3. Megelőző kontrollok. Többfaktoros hitelesítés, a tömeges törlési jogosultság szűkítése, alkalmazás-tokenek átvizsgálása és anomáliafigyelés, hogy az első és ne a negyvenedik napon derüljön ki a dolog. Az észlelés nem megelőzés — azt az időt rövidíti, amíg tudomást szereznek róla, és éppen ez tartja a tiszta visszaállítási pontot az ablakon belül.
4. Helyreállítási stratégiák. Munkaterhelésenként: beépített ablak, független másolat, vagy tudatosan vállalt veszteség. Egy valóban lényegtelen dologra a „vállaljuk a veszteséget” legitim válasz, és hitelesebbé teszi a terv többi részét.
5. A terv dokumentuma. Elérhetőségi lánc, kihirdetési jogosultság, elszigetelési lépések, visszaállítási sorrend, bejelentési felelősök. Legyen olyan rövid, hogy hajnali háromkor is elolvassák.
6. Tesztelés, oktatás, gyakorlat. Lásd alább.
7. Karbantartás. Vizsgálják felül, ha új munkaterhelést vezetnek be, csomagot váltanak, vagy változik az adminisztrátori struktúra. Az a terv, amely már nem használt rendszereket sorol fel, olyan terv, amelyet senki nem olvas.

A nem tesztelt terv csak feltételezés

Két teszt van, és más dolgot mérnek.

Az asztali (table-top) végigjátszás a szervezeti hibákat találja meg: nem tudják, ki hirdet incidenst, elavult az elérhetőségi lista, ketten is azt hiszik, hogy a másiknál van az adminisztrátori hozzáférés. Másfél óra, évente egyszer-kétszer.

A valódi visszaállítás a technikai hibákat találja meg, és ez az, amit ki szoktak hagyni. Állítsanak vissza valós adatot egy külön helyre, és mérjék meg a tényleges eltelt időt — ne a szállítói átviteli számot, hanem a sajátjukat, beleértve azt az órát is, amíg megtalálják a megfelelő visszaállítási pontot. Utána vessék össze a leírt RTO-val. Azt, hogy a legnagyobb munkaterhelés teljes visszaállítása mennyi ideig tart, nem azon a napon kellene először megtudni, amikor szükség van rá.

Ha a két szám nem fedi egymást, akkor van egy döntésük, amíg még olcsó: vagy az eszközt változtatják meg, vagy az RTO-t. Mindkettő tisztességes válasz. Az incidens közben felfedezni a rést nem az.

Hol érdemes kezdeni

Ha ma semmi nincs leírva, ennek a tervnek a leggyorsabban is hasznos változata egy egyoldalas táblázat négy oszloppal — munkaterhelés, MTD, RTO, RPO —, a fenti táblázat alapján őszintén kitöltve, és egy ötödik oszloppal arról, melyik másolatból állítanának valójában vissza. Az üres cellák adják a projekttervet.

Segítünk kiválasztani a felállásukhoz illő megoldást, üzembe helyezni és elindítani a védelmet a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud környezetében — a platformot Önök birtokolják és üzemeltetik, mi arról gondoskodunk, hogy a beállítás megfeleljen a leírt helyreállítási céloknak. A leggyakoribb eset platform-specifikus végigjárását a Microsoft 365 zsarolóvírus utáni helyreállításáról szóló írásunk tartalmazza.

Ha inkább a jelenlegi állapotból indulnának, egy felmérés rövid, gyakorlatias áttekintést ad arról, mit tudnának ma visszaállítani, meddig visszamenőleg, és mennyi idő alatt.