A 3-2-1 mentési szabály SaaS-környezetben
A 3-2-1 mentési szabályt saját adathordozóra írták. Mit jelent a három számjegy, ha az adat a Microsoft 365-ben, a Google Workspace-ben vagy a Slackben van.
A 3-2-1 mentési szabály így szól: tartson 3 másolatot az adatairól, 2 különböző adathordozó-típuson, és 1 másolatot tároljon telephelyen kívül. Ez a világ legtöbbet idézett mentési tanácsa — és a Microsoft 365, a Google Workspace, a Slack és az Atlassian Cloud esetében pontosan meghatározható módon félrevezető. A szabályt olyan állományokra írták, amelyek az Ön tulajdonában lévő adathordozón vannak, és mindhárom számjegy ezt feltételezi. A SaaS-ban viszont Ön nem birtokol adathordozót, az adatai eleve telephelyen kívül vannak, és nem egy meghibásodó lemez fenyegeti őket, hanem egy jogosult fiók, amely jogosult műveleteket végez. A szabályt érdemes követni. Csak előbb le kell fordítani adathordozóról sorsközösségre.
Honnan ered a szabály, és mit mond szó szerint
A 3-2-1 szabálynak komolyabb háttere van, mint sokan gondolnák. Szó szerint szerepel a Data Backup Options című anyagban, amelyet Paul Ruggiero és Matthew A. Heckathorn jegyez, 2012-es Carnegie Mellon University szerzői joggal, az amerikai US-CERT számára készítve:
Whatever backup options you choose, remember to follow the 3-2-1 rule of backups: 3 — Keep 3 copies of any important file: 1 primary and 2 backups. 2 — Keep the files on 2 different media types to protect against different types of hazards. 1 — Store 1 copy offsite (e.g., outside your home or business facility).
Két részlet fontosabb benne, mint maguk a számok.
Az első a „2" indoklása: különböző típusú veszélyek ellen. A szabály lényege az együtt járó meghibásodás kizárása. Két lemez ugyanabból a gyártási tételből együtt megy tönkre; egy lemez és egy szalag nem. Ez a gondolat a SaaS-ban is tökéletesen megállja a helyét.
A második az „1" zárójeles magyarázata: a lakóhelyén vagy a telephelyén kívül. A „telephelyen kívül" 2012-ben azt jelentette, hogy másik épületben, hogy egyetlen tűz vagy beázás ne vihesse el mindkét példányt. Földrajzi utasítás, mert akkoriban a másolatok fizikai tárgyak voltak.
Az eredet ráadásul nem a vállalati IT, hanem a hivatásos fotózás felől érkezik: maga az US-CERT-anyag az American Society of Media Photographers Backup Overview című összeállítására hivatkozik a további olvasmányok között. A szabályt általában Peter Krogh fotográfus 2005-ös The DAM Book című kötetéhez szokás kötni. Ebből érthető a felépítése is: egy fotós negatívja pótolhatatlan, nincs mögötte szolgáltató második példánnyal, az ellenfél pedig egy szekrényben tönkremenő merevlemez.
Miért törik meg a 3-2-1 mentési szabály a SaaS-adatokon
Vegye sorra a számjegyeket egy Microsoft 365-bérlőn, és látni fogja, hol bomlik fel.
„3 másolat" — Önnek már most jóval több van, és egyik sem számít bele. A Microsoft dokumentációja szerint a OneDrive, a SharePoint és az Exchange Online „proprietary architecture design for resiliency with replicated copies of customer data" megoldással működik, vagyis replikált másolatokkal, amelyek beavatkozás nélkül veszik át egymás szerepét. Ez sok, szakszerűen kezelt példány. A replikáció azonban hardverhibára készült, és úgy működik, hogy hűen továbbadja azt, amit az élő példány tartalmaz. Amikor egy zsarolóvírus titkosít egy állományt, a replikáció dolga éppen az, hogy minden példányba eljusson a titkosított változat. A tönkretett adat hibátlan másolata is tönkretett adat. A 3-2-1 logikája szerint ezek egyetlen másolatnak számítanak, mert közös a sorsuk.
„2 különböző adathordozó-típus" — Ön egyetlen adathordozót sem birtokol. Nincs miből másodikat választani. A legtisztességesebb fordítás a két különböző szolgáltató, de még ezt is könnyű látszólag teljesíteni. A Microsoft saját mentési terméke a dokumentáció szerint „built on top of standard OneDrive and SharePoint infrastructure", azaz ugyanarra az infrastruktúrára épül. Valódi visszaállítási pontokat adó, hasznos termék — de nem második adathordozó abban az értelemben, ahogy a szabály érti.
„1 másolat telephelyen kívül" — formálisan teljesül, gyakorlati haszon nélkül. Az adatai eleve valaki más épületében vannak. A 2012-es definíciót a szerződéskötés napján teljesítette. A szándék azonban a függetlenség volt, nem a távolság — és a Microsoft itt dicséretesen egyértelmű: „Data never leaves the Microsoft 365 data trust boundary and honors the geographic locations of your current data residency."
Érdemes kétszer elolvasni. Az uniós adatrezidencia szempontjából ez pontosan az, amit Ön szeretne, és jogos érv a termék mellett. A 3-2-1 „1"-es számjegye szempontjából viszont az ellenkezője a követelménynek: a másolat ugyanazon a határon belül van, ugyanazok az adminisztrátorok érik el, ugyanaz a bérlő szabályozza. A Microsoft ugyanilyen nyíltan fogalmaz arról is, hogy a mentések „immutable unless expressly deleted by the Backup tool admin", vagyis a rendszergazda kifejezett törlése esetén megszűnnek — 90 napos türelmi idővel, ami valódi és jól megtervezett biztonsági háló, egyúttal annak elismerése, hogy a törlési útvonal létezik.
A fordítás: adathordozó helyett sorsközösség
Tartsa meg a számokat, és változtassa meg, mit számolnak. A szabály így nem a tárolóeszközökről, hanem egymástól független hibatartományokról szól:
- 3 másolat → 3 visszaállítási útvonal, amelyek egymástól függetlenül hibásodhatnak meg. Az élő adat, egy natív visszaállítási mechanizmus, és egy olyan példány, amely fölött a platform nem rendelkezik. Ne a lemezre írt bájtokat számolja, hanem az adat visszaszerzésének egymástól eltérő módjait.
- 2 adathordozó → 2 bizalmi határ. A SaaS-ban nem lemez és szalag a lényeges különbség, hanem az, hogy ki engedélyezheti a megsemmisítést. Két másolat, amely ugyanannak a címtárnak felel, valójában egy másolat két néven.
- 1 telephelyen kívül → 1 példány a feltört rendszergazdai fiók hatókörén kívül. Nem másik ország. Másik vezérlősík. Ez az a számjegy, amely ténylegesen dolgozik a zsarolóvírus ellen, és ez az, amelyet a natív eszköztár a legkevésbé teljesít.
A harmadik pont valójában az elszigetelés kérdése — erről részletesen írtunk abban a cikkben, amely bemutatja, mit választ le valójában egy air gap mentés —, illetve annak kérdése, hogy egy példány egyáltalán módosítható-e, amit a módosíthatatlan mentésről szóló írásunk jár körbe.
Mit ad a négy platform natívan
Az átfordított szabályhoz mérve a natív eszközök jobban teljesítenek, mint ahogy a kritikusaik állítják, és rosszabbul, mint ahogy a marketing sugallja:
- A Microsoft 365 az egyetlen a négy közül, amely valódi, időpontra visszaálló helyreállítási pontokat kínál, és részletesen közli a visszaállítási elvárásait — ezeket az RTO és RPO SaaS-környezetben című cikkünkben vezettük végig. A „3 visszaállítási útvonalat" teljesíti, az „1 hatókörön kívüli példányt" nem.
- A Google Workspace rövid, mindent vagy semmit alapú rendszergazdai visszaállítási ablakot ad időpontra visszaállás helyett; a Google Workspace mentésének minden útvonaláról szóló írásunk veszi sorra, melyik mit nem rögzít.
- A Slack exportot kínál, vagyis olyan formátumú másolatot, amelyből visszaállítani nem lehet — lásd: mit tartalmaz valójában egy Slack-export.
- Az Atlassian Cloud törlési ablakokkal és kézi exporttal dolgozik, nem visszaállítási útvonallal; a részletek az Atlassian Cloud mentés natív korlátairól szóló cikkben.
Mindegyik esetben ugyanaz a hiány: a második és harmadik példány — ahol egyáltalán létezik — azon a határon belül él, amely ellen biztosítania kellene.
A számjegy, amely kimaradt az eredeti szabályból
Egy elterjedt változat két további számmal egészíti ki a képletet: egy offline vagy más módon módosíthatatlan példánnyal, és nulla hibával az ellenőrzéskor. Az első az iménti elszigetelési pont megismétlése. A második viszont a valóban hiányzó utasítás, mert a soha vissza nem állított mentés nem kontroll, hanem hiedelem.
Ez nem elméleti aggály. Az ENISA Threat Landscape 2026 jelentése a legaktívabb uniós zsarolóvírus-csoportok technikáit a MITRE ATT&CK keretrendszerhez rendeli, és a T1490, „Inhibit System Recovery" — a rendszer-helyreállítás megakadályozása — ötből négy csoportnál szerepel: az Akira, a Hunters International, a Qilin és a Safepay esetében. A helyreállítási mechanizmus megtámadása az adat megtámadása előtt bevett gyakorlat, nem egzotikus finomítás. Az a mentés, amelyből még soha nem állítottak vissza semmit, pontosan az a fajta kontroll, amely ilyen nyomás alatt csendben megbukik.
Egy 3-2-1 ellenőrzés, amelyet még ezen a héten elvégezhet
Tegyen fel öt kérdést egyetlen valódi munkaterhelésre:
- Hányféleképpen tudom visszaszerezni ezt az adatot, és túlélne-e bármelyik kettő ugyanazt a rossz napot?
- Melyik azonosító törölheti vagy szabhatja át az összes példányt? Ha egyetlen azonosító, akkor egy példányom van.
- Ha egy példány módosíthatatlan, ki rövidítheti le a megőrzési időt, és kell-e hozzá bárki más jóváhagyása?
- Mikor végzett bárki utoljára valódi visszaállítást — nem feladat-ellenőrzést, hanem egy használható állomány előállítását?
- Ha maga a bérlő nem lenne elérhető, melyik példányt tudnám mégis elolvasni?
Ha az őszinte válaszok: „kettő", „igen, a globális rendszergazda", „a globális rendszergazda", „soha" és „egyiket sem", akkor a 3-2-1 szabály semmilyen hasznot hajtó formában nem teljesül — függetlenül attól, hány replika létezik.
Hogy ezek közül a hiányok közül melyik számít ténylegesen az Ön bérlőiben, pontosan ezt méri fel díjmentes SaaS-mentési felmérésünk: hozzon egy munkaterhelést, mi pedig feltérképezzük a meglévő visszaállítási útvonalakat, megmutatjuk, melyek osztoznak közös sorsban, és segítünk kiválasztani és bevezetni azt a megoldást, amely a megmaradó rést betölti.
Kapcsolódó
Air gap mentés: mit választ le valójában
A SaaS-adatok air gap mentése mindig logikai leválasztás. Mit jelent a fogalom pontosan, és melyik négy kapcsolatot érdemes elvágni.
Módosíthatatlan mentés: mit jelent valójában az immutable backup
A módosíthatatlan mentést a tárolási réteg nem engedi törölni a dátuma előtt. Mit jelent ez a gyakorlatban, és mit ad helyette a négy SaaS-platform.
SaaS adatvédelem: a megfelelés még nem helyreállíthatóság
A magyar „adatvédelem” a GDPR-t idézi fel, a visszaállíthatóság viszont kimarad belőle. A két feladat szétválasztása Microsoft 365, Google Workspace, Slack és Atlassian környezetben.