Módosíthatatlan mentés: mit jelent valójában az immutable backup

A módosíthatatlan mentés (angolul: immutable backup) olyan másolat, amelyet maga a tárolási réteg nem enged módosítani, felülírni vagy törölni egy előre rögzített időpont eléréséig — nem azért, mert a jogosultságok tiltják, hanem mert a tároló senkitől nem fogadja el a műveletet. A Microsoft dokumentációja világosan megadja a formális meghatározást: a módosíthatatlanság olyan tárolást jelent, amely meghatározott ideig nem módosítható, nem törölhető és nem írható felül. Zsarolóvírus szempontjából ez egyetlen, nagyon konkrét dolog miatt számít. A támadó érvényes hitelesítő adatokkal érkezik, a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud natív védőhálói pedig szinte kivétel nélkül jogosultsághoz kötöttek. A módosíthatatlanság az az egyetlen tulajdonság, amelyet nem érdekel, milyen magas jogosultsága van a támadónak.

Három feltételnek egyszerre kell teljesülnie

Egy másolat csak akkor módosíthatatlan, ha mindhárom állítás igaz rá:

1. A korlátozás a tárolóban van, nem az alkalmazásban. Egy letiltott törlés gomb a felületen alkalmazásszintű ellenőrzés, és az alkalmazásszintű ellenőrzést meg lehet kerülni azzal, ha közvetlenül az alatta lévő API-val beszél valaki. A módosíthatatlanság azt jelenti, hogy maga a tároló utasítja vissza az írást, bármelyik kliens kezdeményezi is.
2. Van meghatározott időtartam, és annak vége van. A módosíthatatlanság mindig időhöz kötött: tartozik hozzá egy dátum, ameddig a védelem tart. Az "örökre módosíthatatlan" vagy üzleti ígéret műszaki köntösben, vagy pongyola fogalmazás — és ütközik azokkal a törlési kötelezettségekkel is, amelyeket a GDPR ró Önre.
3. Túléli a rendszer legmagasabb jogosultságát is. Ez az a próba, amely elválasztja a valódi megvalósítást a látszólagostól, és ezt szokták a leghalkabban elbukni.

A WORM (write once, read many) ugyanennek a gondolatnak a régebbi neve, és a megfelelőségi dokumentumokban ma is találkozni fog vele. A viselkedést írja le, nem a megvalósítás módját.

A beállítás, amely eldönti, hogy valódi-e

Az S3 Object Lock a modell legrészletesebben dokumentált megvalósítása, és sok mentési platform erre épít, ezért jól használható arra, hogy megmutassa, mit takar a szó. Itt ugyanis a lényegi különbség konfigurációs döntés, nem marketingjelző — két megőrzési mód közül lehet választani:

• Governance (irányított) mód. A felhasználók nem írhatják felül és nem törölhetik a védett verziót, és nem módosíthatják a zárolás beállításait — hacsak nem rendelkeznek külön erre feljogosító engedéllyel. Ez megállítja a hétköznapi fiókokat és a hétköznapi hibákat. Nem állítja meg azt, aki rendelkezik ezzel az engedéllyel, vagy ellopott egy ilyen identitást.
• Compliance (megfelelőségi) mód. A védett verziót egyetlen felhasználó sem írhatja felül és nem törölheti — beleértve a fiók legfőbb, root jogosultságú felhasználóját is. A megőrzési mód nem módosítható, a megőrzési idő nem rövidíthető. Az objektumot kizárólag az idő múlása szabadítja fel.

Ettől elkülönül a jogi zárolás (legal hold), amelyhez egyáltalán nem tartozik megőrzési idő: megakadályozza a felülírást és a törlést, és addig marad érvényben, amíg valaki kifejezetten fel nem oldja. Ez más eszköz más feladatra — bizonyítékmegőrzésre való, nem zsarolóvírus elleni ellenállóképességre.

A gyakorlati következtetés rövid. Ha egy szolgáltató azt mondja, hogy a mentések módosíthatatlanok, de nem mondja meg, melyik modell van érvényben, akkor éppen a lényeget nem mondta meg. A visszakérdezés egyetlen mondat: le tudja-e bárki rövidíteni ebben a rendszerben a megőrzési időt, vagy meg tud-e semmisíteni egy másolatot a dátuma előtt — és ha igen, ki?

Miért pont zsarolóvírus ellen számít

A SaaS-t érő zsarolóvírus-támadás ritkán néz ki behatolásnak. A titkosítás hitelesítve érkezik: egy érvényes tokent birtokló szinkronizáló kliensen, egy munkatárs által jóváhagyott OAuth-hozzájáruláson vagy egy feketepiacon vásárolt rendszergazdai fiókon keresztül. A kártevő minden művelete olyan művelet, amelyre az adott hitelesítő adat fel volt jogosítva.

Pontosan ezért teljesítenek alul a natív védőhálók akkor, amikor szükség lenne rájuk. A OneDrive és a SharePoint lomtára 93 napot ad az eredeti törléstől számítva, csakhogy ez egy lomtár, és egy kellően magas jogosultságú fiók ki tudja üríteni. A megőrzési beállításokat az módosíthatja, aki a megőrzést adminisztrálja. A verziótörténetet ki lehet meríteni, ha a támadó egyszerűen elég sok új verziót ír. Egyik mechanizmust sem olyan ellenféllel szemben tervezték, aki birtokolja a hitelesítő adatokat — hanem a véletlen hibák ellen.

A módosíthatatlanság átfogalmazza a kérdést: nem az a tét, hogy volt-e a támadónak jogosultsága, hanem az, hogy lejárt-e már a megőrzési idő. Ez sokkal unalmasabb kérdés, és éppen ez benne a jó.

Egy dolgot érdemes nyíltan kimondani, mert a téma körüli kommunikáció ezzel nem szokott pontos lenni: a módosíthatatlanság nem állítja meg a támadást. Nem észleli, nem akadályozza meg az éles adatok titkosítását, és nem rövidíti le az incidenst. Pontosan egyetlen dolgot dönt el: hogy létezik-e még tiszta másolat, amikor keresni kezdi.

Mit ad ehelyett a négy platform

Sem a Microsoft 365, sem a Google Workspace, sem a Slack, sem az Atlassian Cloud nem kínál tárolószintű módosíthatatlanságot a szokásos natív helyreállítás részeként. Amit kap, az időkorlátos és jogosultsághoz kötött visszavonási lehetőség.

A Microsoft 365 a legérdekesebb eset, mert a Microsoft becsületesen dokumentálja az árnyalatot, az összefoglalók viszont általában nem. A Microsoft 365 Backup kiegészítő a visszaállítási pontokat úgynevezett append-only (csak hozzáfűzhető) tárolón tartja, így a meglévő mentési adatokat a szolgáltatás nem tudja módosítani vagy felülírni. A Microsoft saját oldala azonban kimondja a határt: a termék a módosíthatatlanság definícióját a törlés tiltása kivételével követi. A törlés szándékosan elérhető marad, hogy az ügyfél ki tudjon lépni a szolgáltatásból — utána rögzített 90 napos türelmi idő alatt még visszanyerhetők a mentések, és több rendszergazdát értesítő riasztás is jár hozzá. A Microsoft ezt úgy írja le, mint ami megközelíti a teljes módosíthatatlanságot, nem pedig megvalósítja azt. A kiegészítő többi korlátját a Microsoft 365 mentés valós lefedettségéről szóló írásunkban jártuk körül.

A Microsoft ugyanakkor szállít egy valóban zárszerű vezérlőt, amely megérdemelné, hogy ismertebb legyen: ez a Purview megőrzési szabályokra alkalmazható Preservation Lock. Miután ezt egyszer bekapcsolták, senki — beleértve a globális rendszergazdát is — nem tudja a szabályt kikapcsolni, törölni vagy kevésbé szigorúra állítani; kizárólag kiterjeszteni lehet. A Microsoft szabályozói elvárásokra és a "megbízhatatlan rendszergazda" kockázata elleni védekezésre pozicionálja, és szándékosan nem teszi elérhetővé az adminisztrációs felületen: PowerShellből kell alkalmazni, és utólag nem vonható vissza. Ez nem mentés — megőrzési vezérlő, amely a szabály hatókörét védi, nem egy független másolatot, és nem segít, ha maga a tenant válik elérhetetlenné. De ez áll a legközelebb a compliance módú kikényszerítéshez a Microsoft 365-ön belül.

A Google Workspace 25 napot ad a rendszergazdának egy törölt felhasználó adatainak visszaállítására, a szokásos kuka-határidőkön felül, a Vault pedig kifejezetten kimondja magáról, hogy nem adatarchívum: exportál, nem állít vissza. Egyik mechanizmus sem módosíthatatlan semmilyen értelemben — mindkettő rendszergazdai funkció, rendszergazdák számára elérhetően. A Google Workspace mentés készítéséről szóló írásunk végigveszi, mit fed le és mit nem a négy szóba jöhető útvonal.

A Slack és az Atlassian Cloud még távolabb áll a gondolattól. A Slack-export egy adott időpillanatot rögzítő fájl, amelynek a tárolásáért ezután Ön felel — így annyira módosíthatatlan, amennyire a célhelyet azzá teszi. Az Atlassian natív exportjai ugyanígy viselkednek.

A minta mind a négy platformon ugyanaz: a szolgáltató az adatok rendelkezésre állását garantálja, és ad egy rövid visszavonási lehetőséget. Hogy hol él a független másolat, meddig van rögzítve, és ki tudja idő előtt megsemmisíteni — ezeket a kérdéseket a platform visszaadja Önnek. Ugyanaz a megosztott felelősség, amely a SaaS-helyreállíthatóság minden más kérdését is eldönti.

Hat kérdés, mielőtt elfogadja a szót

1. Melyik kikényszerítési modell van érvényben? Governance jellegű, ahol létezik privilegizált felülbírálás, vagy compliance jellegű, ahol senkinek nincs? Kérje írásban, ne diaképen.
2. Ki tudja lerövidíteni a megőrzési időt? Ha a válasz az, hogy "egy rendszergazda", akkor a módosíthatatlanság szabály, nem tulajdonság.
3. Mi történik a szolgáltatásból való kilépéskor vagy fizetés elmaradásakor? Sok megvalósítás felszabadítja vagy törli a másolatokat, amikor az üzleti kapcsolat véget ér. Pontosan ezt a pillanatot fogja megcélozni az a támadó, aki a számlázási identitását birtokolja.
4. Külön bizalmi határon belül van a másolat? Az a módosíthatatlan másolat, amely a védett tenanten belül él, osztozik annak sorsában: lejáró előfizetés, rendszergazdai kompromittálódás, tenant szintű üzemzavar.
5. Mely munkaterheléseket fedi le ténylegesen? Az a módosíthatatlanság, amely a fájlokra kiterjed, de a csevegésre, a levelezésre, a feladatelőzményekre vagy a jogosultsági struktúrára nem, a könnyebbik felét fedte le.
6. Mikor állított vissza utoljára módosíthatatlan másolatból? A módosíthatatlanság azt garantálja, hogy az adat ott van. Arról nem mond semmit, hogy vissza tudja-e állítani működő állapotba, és mennyi idő alatt.

Az utolsó kérdést teszi fel a legkevesebb szervezet, és ezt az incidens válaszolja meg Ön helyett. Az a másolat, amelyből még soha nem állított vissza, nem kontroll, hanem feltételezés — a különbség pedig mindig a legrosszabb napon derül ki.

Ha a megőrzési időt szabályozói elvárás határozza meg, érdemes a NIS2 mentési követelményeiről szóló írásunkat is átnézni: a kikényszerítési modell megválasztása ott már nem csak műszaki döntés.

Hol jövünk mi a képbe

Nem mi vagyunk a platform, és nem mi üzemeltetjük a bérlői környezetét. Azt segítünk tisztázni, mi a tényleges helyreállítási igénye — mely munkaterhelések hordoznak valódi kockázatot, meddig kell visszamenőleg helyreállítani, mennyire kell függetlennek lennie a másolatnak, és melyik kikényszerítési modellt kívánja meg a megfelelőségi helyzete —, majd segítünk kiválasztani a környezetéhez illő megoldást, és üzembe helyezni. Onnantól Öné a rendszer, és Ön üzemelteti.

Ha a módosíthatatlanság kérdésére inkább a saját környezetére vonatkozó választ kapna, mint elméletit, a helyreállítási felmérésünk végigveszi a munkaterheléseit, a megőrzési kötelezettségeit és a jelenlegi natív határidőit, és megmutatja, hol van valójában a rés.