Céges adatmentés: a 3-2-1 szabály és a visszaállítási teszt

A mentéssel kapcsolatos rossz hírek ritkán szólnak arról, hogy egy cégnek nem volt mentése. Sokkal gyakrabban arról, hogy volt, csak nem lehetett használni. A mentés hónapok óta hibával futott, és senki nem olvasta a figyelmeztető e-maileket. A mentőlemez állandóan a szerverre volt dugva, és a zsarolóvírus azt is titkosította. Vagy minden megvolt, csak senki nem tudta, hogyan kell visszaállítani, és hol van a titkosítási kulcs. Ezek nem egzotikus esetek, hanem visszatérő minták. Ez a cikk arról szól, hogyan kerüld el őket.

A 3-2-1 szabály, ahogy a hatóságok leírják

A 3-2-1 szabály nem egy gyártó marketingje, hanem több mint egy évtizede ismert szakmai alapelv. Az amerikai US-CERT (ma CISA) mentési útmutatója így foglalja össze:

• 3 példány minden fontos adatból: az éles adat és két mentés. Egyetlen mentés nem elég — ha az az egy hibás, nincs tovább.
• 2 különböző adathordozó vagy tárolótípus, hogy egyetlen hibatípus ne vigye el mindkét mentést. Például helyi hálózati tároló (NAS) és felhőtárhely, vagy NAS és cserélhető lemez.
• 1 példány a telephelyen kívül — tűz, beázás, betörés vagy túlfeszültség ellen.

A Nemzeti Kiberbiztonsági Intézet zsarolóvírusokról szóló tájékoztatója ugyanezt a logikát követi, egy fontos hangsúlyeltolással: a három példányból egyet teljesen offline kell tárolni, a legfontosabb védelmi intézkedésnek pedig a rendszeres mentést nevezi egy elkülönített, fizikailag is leválasztható meghajtóra. Ma, amikor a támadók kifejezetten a mentéseket is keresik, ez a hangsúly indokolt.

A modern kiegészítés: 3-2-1-1-0

Egyes mentési gyártók — például a Veeam — a szabályt 3-2-1-1-0 formában bővítették: a plusz 1 egy módosíthatatlan (immutable) vagy hálózatról leválasztott példány, a 0 pedig azt jelenti, hogy a visszaállítás ellenőrzésekor nulla hiba legyen. Ez nem szabvány, hanem gyártói kiterjesztés, de jól emlékeztet a két leggyakoribb gyengeségre: a támadó által elérhető mentésre és a soha nem tesztelt mentésre.

Szinkron nem mentés: a felhőmappák csapdája

A OneDrive, a Dropbox vagy a Google Drive szinkronizált mappája kényelmes és hasznos — de a dolga az, hogy ugyanaz a fájl mindenhol ugyanolyan legyen. Ha a laptopon valaki töröl egy mappát, vagy egy zsarolóvírus titkosítja a fájlokat, a szinkron ezt is hűségesen továbbviszi. A CISA mentési útmutatója a folyamatosan frissülő mentésekről is leírja, hogy észrevétlenül átvihetik az éles fájlok sérülését vagy a kártevőt a mentett példányokra.

Legyünk igazságosak: a Microsoft biztonsági hálót is ad. Munkahelyi vagy iskolai fiókoknál a OneDrive lomtárából a törölt fájlok 93 napig visszaállíthatók, hacsak a rendszergazda nem módosította ezt a beállítást. A OneDrive-visszaállítás funkcióval (Restore your OneDrive) a Microsoft 365-előfizetők az elmúlt 30 nap bármely időpontjára visszaállíthatják a teljes OneDrive-ot — a Microsoft kifejezetten törlés, felülírás, sérülés és kártevőfertőzés esetére ajánlja. Ezek valódi segítségek, de időben korlátozottak, és ugyanabban a rendszerben élnek, mint az éles adat. A Microsoft szerint ha egy fájl a lomtárból is véglegesen törlődött, már nem állítható vissza.

A Microsoft 365 adatai: kié a felelősség?

Gyakori feltételezés, hogy ami a Microsoft felhőjében van, azt a Microsoft menti. A Microsoft saját, megosztott felelősségi modellje ennél pontosabb: minden felhős szolgáltatástípusnál — a Microsoft 365-höz hasonló kész szoftverszolgáltatásoknál is — az ügyfélnél marad az adatok, a fiókok és identitások, valamint a beállítások felelőssége. A Microsoft a fizikai adatközpontért, a hálózatért, a szerverekért és a szolgáltatás platformjáért felel.

A gyakorlatban ez azt jelenti, hogy a Microsoft gondoskodik arról, hogy a szolgáltatás fusson, és egy adatközponti hardverhiba ne vigye el az adataidat — a dokumentációja szerint a OneDrive, a SharePoint és az Exchange több, fizikailag redundáns példányban tárolja az adatokat. Ha viszont egy munkatárs töröl, egy feltört fiókkal valaki titkosít, vagy egy rossz beállítás miatt tűnik el valami, az a te felelősségi köröd. Nem véletlen, hogy a Microsoft is kínál külön, külön díjas mentési terméket (Microsoft 365 Backup) a OneDrive, a SharePoint és az Exchange adataihoz.

Három kérdést érdemes tudatosan eldönteni, nem feltételezni:

• Kell-e független mentés a levelezésről, a OneDrive-okról és a SharePoint-, illetve Teams-fájlokról?
• Milyen régi állapotra kell visszamenni tudni — napokra, hónapokra vagy évekre?
• Ki fér hozzá a mentéshez? Ha ugyanazzal az adminfiókkal törölhető, mint az éles adat, egy feltört fiók mindkettőt viheti.

RPO és RTO: két szám, amiből a mentési rend következik

A mentési rendet nem a technológiával, hanem két üzleti kérdéssel érdemes kezdeni. A NIST definíciója szerint az RPO (recovery point objective) az az időpont, ameddig egy kiesés után vissza kell tudni állítani az adatokat. Közérthetően: mennyi munka veszhet el. Az RTO (recovery time objective) az az idő, ameddig egy rendszer helyreállítás alatt lehet anélkül, hogy az már a cég működését veszélyeztetné. Közérthetően: meddig állhat a munka.

• Napi egy mentésnél a legrosszabb esetben egy teljes munkanap adata veszhet el. Ha a számlázás vagy a rendelésfelvétel ezt nem bírja, sűrűbb mentés vagy folyamatos replikáció kell.
• Az RTO-t nem a mentés, hanem a visszaállítás határozza meg: mennyi adat, milyen sávszélességen, milyen hardverre és ki végzi. Egy felhőből visszatöltött teljes szerver jóval tovább tarthat, mint amire a legtöbben számítanak.
• Nem minden rendszer egyforma. A levelezésnek és a számlázásnak órák alatt kell újra mennie, egy archív projektmappa napokat is várhat. Rangsorold a rendszereket, és a fontossági sorrend szerint tervezd a mentést.

Zsarolóvírus ellen: offline és módosíthatatlan példány

A CISA zsarolóvírus-útmutatója egyértelmű: a kritikus adatokról offline, titkosított mentést kell tartani, és rendszeresen tesztelni, hogy vészhelyzetben elérhető és ép-e. Az indoklás is ott van: sok zsarolóvírus kifejezetten megkeresi és törli vagy titkosítja az elérhető mentéseket. Három eszköz áll rendelkezésre:

• Offline példány — cserélhető lemez vagy szalag, amelyet a mentés után leválasztasz és máshol tárolsz. Olcsó, de fegyelmet igényel: rotációs rend, felelős és napló kell hozzá.
• Módosíthatatlan tárolás — felhős vagy NAS-oldali beállítás, amelynél a mentés a megőrzési időn belül nem írható felül és nem törölhető. A CISA szerint körültekintő beállítást igényel.
• Elkülönített hozzáférés — a mentési rendszer kezelőfelülete ne ugyanazzal a fiókkal legyen elérhető, mint a napi adminisztráció, és legyen rajta többfaktoros hitelesítés.

Mentés csak az, amiből már visszaállítottál

A mentőszoftver zöld pipája azt jelenti, hogy a mentési feladat lefutott — nem azt, hogy az adat teljes, olvasható és belátható időn belül visszaállítható. Ezt csak a visszaállítási teszt bizonyítja. Kiindulásnak ezt a ritmust javasoljuk:

1. Havonta: néhány véletlenszerűen kiválasztott fájl és mappa visszaállítása egy külön helyre, és a megnyitásuk. Öt perc, de kiderül belőle, hogy a mentés olvasható-e.
2. Negyedévente: egy teljes rendszer — például egy szerver vagy egy virtuális gép — visszaállítása tesztkörnyezetbe, időméréssel. Ebből tudod meg a valós RTO-t.
3. Évente vagy nagyobb változás után: forgatókönyv-gyakorlat. „Ma reggel minden titkosítva van” — ki mit csinál, hol a leírás, hol a titkosítási kulcs, kit kell felhívni?
4. Minden alkalommal: dokumentáld a dátumot, a visszaállított adatot, az időtartamot, az eredményt és a felmerült hibát. A dokumentált teszt a vezetésnek és egy esetleges ellenőrzésnek is bizonyíték.

Egyszerű ellenőrzőlista

Ha az alábbi pontok közül bármelyikre a válasz „nem tudom”, ott érdemes kezdeni:

• Tudjuk, mely adatokat és rendszereket mentjük — és azt is, melyeket nem.
• Megvan a 3-2-1: három példány, két tárolótípus, egy a telephelyen kívül.
• Van offline vagy módosíthatatlan példány.
• A Microsoft 365 (levelezés, OneDrive, SharePoint) mentése tudatos döntés, nem feltételezés.
• A mentési hibákról értesítés megy, és valaki el is olvassa.
• A mentési rendszer külön fiókkal és többfaktoros hitelesítéssel védett.
• A titkosítási kulcsok és jelszavak a mentésen kívül is megvannak, biztonságos helyen.
• Van írásos, lépésenkénti visszaállítási leírás.
• A visszaállítást rendszeresen teszteljük, és dokumentáljuk.
• A kritikus rendszerekre van rögzített RPO és RTO.

Ha egyedi ügyviteli rendszert, CRM-et vagy webshopot használsz, annak adatbázisa és feltöltött fájljai is a mentési terv részei — érdemes tisztázni, hogy a fejlesztő vagy az üzemeltető felel értük. Nálunk a szoftverfejlesztés és az IT-üzemeltetés egy csapatnál van, így ez a kérdés nem esik két beszállító közé.

A mentés a védekezés utolsó vonala. Hogy odáig lehetőleg ne jusson el a baj, arról a kiberbiztonsági alapokról szóló cikkünkben írtunk; ha pedig azt mérlegeled, ki felügyelje mindezt, olvasd el a saját rendszergazda vagy külsős IT-üzemeltetés döntési útmutatót.