// KIBERBIZTONSÁGI KISOKOS · 10. MODUL

Mentés és üzletmenet-folytonosság — a végső védelem zsarolóvírus ellen

A kb. 7 perc olvasás

A mentés a rendelkezésre állás végső biztosítéka: ha minden más védelem elbukik és a zsarolóvírus titkosítja a rendszered, egy ép, visszaállítható mentésből újraindulhatsz fizetés nélkül. De a mentés csak akkor véd, ha jól van felépítve és tesztelt. Ez a modul végigveszi a 3-2-1 szabályt, az offline/immutable mentést, az RTO/RPO célokat és az üzletmenet-folytonossági tervet — érthetően, kis cégeknek is.

1 · Laikusan

Mi a biztonsági mentés?

A biztonsági mentés (backup) nem más, mint egy tartalék másolat a fontos adataidról és rendszereidről, amit külön őrzöl — hogy ha az eredeti megsérül, eltűnik vagy egy zsarolóvírus titkosítja, vissza tudd állítani belőle a működést. Ez a végső védelem: a többi intézkedés azt próbálja megakadályozni, hogy baj legyen, a mentés viszont az, ami akkor ment meg, ha a baj mégis bekövetkezett.

Képzeld el a lakáskulcsoddal Gondolj a mentésre úgy, mint egy tartalék kulcsra, amit nem a saját zsebedben, hanem egy megbízható szomszédnál vagy a munkahelyeden hagysz. Amíg minden rendben, rá sem gondolsz. De ha egyszer elveszíted a kulcscsomódat vagy bezárod magad, az a kint hagyott másolat az egyetlen, ami visszaenged a lakásba — fizetés és lakatos nélkül. Ám ha a tartalék kulcsot is a saját zsebedben tartod, akkor a kulcscsomóddal együtt az is elveszett. Ezért fontos, hogy a mentés külön legyen tárolva — különben ugyanaz a baj viszi el az eredetit és a másolatot is.

A digitális világban a „tartalék kulcs" a mentésed, a „bezárt lakás" pedig az, amikor egy zsarolóvírus titkosítja a céges fájljaidat, és pénzt követel a feloldásukért. Ha van ép, leválasztott mentésed, nem kell fizetned: visszaállítasz a mentésből, és újraindulsz. Ha nincs — vagy a mentés ugyanazon a hálózaton volt, amit a vírus elért —, akkor vagy fizetsz (kockázatosan, garancia nélkül), vagy elveszíted az adatokat. Ezért mondjuk: a mentés a rendelkezésre állás (az „A" a CIA triászban) utolsó, megkerülhetetlen biztosítéka.

2 · A gyakorlatban

Miért NIS2-szempont?

A NIS2 kiemelten kezeli az üzletmenet-folytonosságot: nem elég megelőzni az incidenst, fel kell készülni arra is, hogy a működés egy súlyos esemény után is helyreálljon. A mentéskezelés, a helyreállítás és a krízis-menedzsment ennek a felkészültségnek a gerince — és pont ezeket kéri számon a szabályozás.

Mi ez?

Rendszeres, ellenőrzött másolatkészítés a kritikus adatokról és rendszerekről, plusz a hozzá tartozó képesség: hogy ezekből egy meghatározott időn belül (RTO) és elfogadható adatvesztéssel (RPO) tényleg vissza is tudj állni. Kiegészítve az üzletmenet-folytonossági (BCP) és katasztrófa-helyreállítási (DRP) tervvel.

Miért NIS2-kötelező elem?

A NIS2-t átültető szabályozás kifejezetten elvárja az üzletmenet-folytonosság, a mentéskezelés és a krízis-menedzsment kezelését a kockázatkezelési intézkedések között. A pontos elvárás a szervezet érintettségétől függ — itt szándékosan nem idézünk konkrét paragrafust; az értelmezés mindig egyedi.

Hogyan segít?

Egy tesztelt mentés a leghatékonyabb válasz a zsarolóvírusra: nem kell fizetned, és gyorsan újraindulsz. Egyúttal bizonyíthatóvá teszi a felkészültséget — egy auditnál vagy egy valódi incidensnél a kérdés nem az, hogy „van-e mentés", hanem hogy „visszaálltál-e már belőle".

2 · A gyakorlatban

Hogyan építs megbízható mentési rendet? — öt lépés

Nem kell hozzá vállalati szintű drága rendszer; a legtöbb cég a meglévő eszközeivel is komoly előrelépést tehet. A lényeg a fegyelem és a tesztelés — nem a technológia ára.

01

Döntsd el, mit kell menteni

Nem mindent kell egyformán menteni. Vedd számba a kritikus adatokat és rendszereket (könyvelés, ügyféladatok, szerződések, webshop, e-mail), és rangsorold: mi nélkül áll meg a működés? Ez köti össze a mentést a kockázatkezeléssel — oda teszed a legjobb védelmet, ahol a kiesés a legjobban fáj.

02

Alkalmazd a 3-2-1 szabályt

Tarts legalább 3 másolatot, 2 különböző hordozón (pl. helyi meghajtó és felhő), és ezek közül 1-et a telephelyen kívül. Így egyetlen meghibásodás, tűz, lopás vagy vírusfertőzés sem viszi el az összes példányt egyszerre.

03

Legyen offline vagy nem felülírható mentés

A zsarolóvírus azt is megpróbálja titkosítani, amit elér a hálózaton — beleértve a csatlakoztatott mentéseket. Ezért tarts legalább egy offline (leválasztott) vagy immutable (nem felülírható, módosíthatatlan) mentést, amelyhez a vírus hozzá sem fér. Ez az a példány, ami valóban megment a fizetéstől.

04

Tűzz ki RTO és RPO célt

Az RTO azt mondja meg, mennyi idő alatt kell visszaállnod (meddig bírja el a cég a kiesést), az RPO azt, mennyi adatot engedhetsz meg elveszíteni (milyen gyakran kell menteni). Ezeket a vezetés tűzi ki üzleti alapon — és ezek döntik el, milyen mentési megoldásba érdemes fektetni.

05

Teszteld a visszaállítást, és írj BCP/DRP-t

A mentés, amit nem teszteltél, nem mentés. Rendszeresen állíts vissza egy mintát egy tesztkörnyezetbe, ellenőrizd, hogy ép és teljes, és naplózd az eredményt — ezt rögzíti a Szabályzat-csomag mentés-teszt naplója (NYV-03). Végül foglald írásba az üzletmenet-folytonossági (BCP) és katasztrófa-helyreállítási (DRP) tervet.

3 · Technikai mélység

Ha mélyebbre ásnál

Az alábbiak a mentésekért felelős kollégának vagy a rendszergazdának szólnak — a laikus olvasó nyugodtan átugorhatja, az elv megértéséhez nem szükséges.

RTO és RPO mélyebben — hogyan vezetik a mentési stratégiát
Az RTO (Recovery Time Objective) és RPO (Recovery Point Objective) nem technikai, hanem üzleti döntés: a vezetés mondja meg, mennyi kiesés és mennyi adatvesztés fér bele. Egy 15 perces RPO napi mentéssel nem érhető el — ott folyamatos replikációra vagy gyakori snapshotokra van szükség. Egy 1 órás RTO-hoz nem elég, hogy „valahol megvan az adat": kell hozzá előre bekészített helyreállítási útvonal, esetleg melegtartalék. Minél szigorúbb a cél, annál drágább a megoldás — ezért érdemes rendszerenként eltérő célokat kitűzni, és csak a tényleg kritikus rendszereknél fizetni a legszigorúbb szintért.
Immutable mentés, 3-2-1-1-0 és a zsarolóvírus-rezisztencia
A klasszikus 3-2-1 szabályt a modern, zsarolóvírus-tudatos gyakorlat 3-2-1-1-0-ra bővíti: a plusz 1 egy offline vagy immutable (WORM — write once, read many) példány, amit a támadó akkor sem tud törölni vagy titkosítani, ha admin-hozzáférést szerez; a 0 pedig azt jelenti, hogy a visszaállítás nulla hiba mellett sikerül (igazolt teszt). Az immutabilitást felhős tárhelyen objektum-zárolással (object lock), helyben pedig külön hitelesítésű, leválasztott tárolóval lehet elérni. Fontos a mentések titkosítása is — különben a másolat maga lesz adatszivárgási kockázat.
BCP vs. DRP, BIA és a krízis-menedzsment
A BCP (Business Continuity Plan — üzletmenet-folytonossági terv) a tágabb keret: hogyan működik tovább a cég egy súlyos zavar alatt (akár manuális kerülőúton, alternatív helyszínen). A DRP (Disaster Recovery Plan — katasztrófa-helyreállítási terv) ennek technológiai része: konkrétan hogyan állítod helyre az IT-rendszereket. Mindkettő bemenete a BIA (Business Impact Analysis): annak felmérése, melyik folyamat kiesése mikor és mennyire fáj — ebből jönnek az RTO/RPO célok. Végül a krízis-menedzsment a döntési és kommunikációs rend baj esetén (ki dönt, kit értesítünk, hogyan). Ezek a tervek élesben akkor érnek valamit, ha rendszeresen, gyakorlat formájában is kipróbálod őket — és a mentés-teszt napló (NYV-03) ennek az egyik bizonyítéka.
2 · A gyakorlatban

Gyors önellenőrzés

Három kérdés, amit ma fel tudsz tenni magadnak — nincs eszköz, nincs regisztráció. Ha bármelyikre „nem" vagy „nem tudom" a válasz, ott van a következő lépésed.

1 · Offline példány

Van-e legalább egy olyan mentésetek, amit egy zsarolóvírus nem érne el (leválasztott vagy nem felülírható)? Ha minden mentés a hálózaton, állandóan csatlakoztatva fut, akkor egyetlen fertőzés az eredetivel együtt a mentést is elviheti.

2 · Tesztelt visszaállítás

Mikor állítottatok vissza utoljára élesben egy mentésből? Ha a válasz az, hogy „még soha" vagy „nem emlékszem", akkor valójában nem tudjátok, hogy a mentés működik-e — csak remélitek.

3 · RTO/RPO és terv

Tudjátok-e, hogy egy súlyos leállás után mennyi idő alatt kell visszaállnotok és mennyi adatot veszíthettek? Ha nincs erre kimondott cél és írott BCP/DRP, akkor a baj pillanatában fogtok improvizálni — a legrosszabbkor.

1 · Laikusan

Gyakori tévhit

Tévhit

„Van mentésünk, tehát biztonságban vagyunk."

Az, hogy fut egy mentési feladat, még nem jelenti, hogy bajban tényleg vissza tudsz állni belőle. A mentések csendben megsérülhetnek, hiányosak lehetnek, vagy épp a zsarolóvírus is eléri őket, mert ugyanazon a hálózaton, állandóan csatlakoztatva voltak. A mentés, amit nem teszteltél, nem mentés — csak egy feltételezés. A valódi biztonság az, ha van offline/immutable példányod, kitűzött RTO/RPO célod, és időnként bizonyítottan visszaállítasz belőle. Nem a mentés léte, hanem a visszaállítás képessége véd meg.

GYIK a mentésről és folytonosságról

A szinkronizálás nem mentés. A szinkron (pl. egy közös felhős meghajtó) azonnal továbbítja a változásokat: ha egy zsarolóvírus titkosítja vagy egy munkatárs törli a fájlt, a hiba pár másodperc alatt a felhőbe is átmegy. A valódi mentés különálló, korábbi állapotokat (verziókat) őriz, amelyekhez a vírus nem fér hozzá — ideális esetben offline vagy nem felülírható (immutable) formában. A kettő kiegészíti egymást, de a szinkron önmagában nem helyettesíti a mentést.
Egy egyszerű hüvelykujjszabály: tarts legalább 3 másolatot az adataidból, 2 különböző hordozón (pl. helyi szerver és külső meghajtó vagy felhő), és ezek közül legalább 1-et a telephelyen kívül. Így egyetlen meghibásodás, tűz, lopás vagy zsarolóvírus sem viszi el az összes másolatot egyszerre. Egy lépéssel tovább a 3-2-1-1-0: a plusz 1 egy offline/immutable példány, a 0 pedig azt, hogy a visszaállítást teszteled, és nulla hiba mellett áll vissza.
Az RTO (Recovery Time Objective) azt mondja meg, mennyi idő alatt kell visszaállnia a működésnek egy leállás után — meddig bírja el a cég a kiesést. Az RPO (Recovery Point Objective) azt mondja meg, mennyi adatot engedhetsz meg elveszíteni, vagyis milyen gyakran kell menteni: ha napi egyszer mentesz, legfeljebb egy nap munkája veszhet el. A két célt a vezetés tűzi ki üzleti alapon, és ezek határozzák meg, milyen mentési és helyreállítási megoldásba érdemes fektetni.
Mert sok cég csak akkor szembesül vele, hogy a mentés sérült, hiányos vagy visszaállíthatatlan, amikor baj van — és akkor már késő. A mentés értéke nem abban van, hogy fut a feladat, hanem hogy abból tényleg vissza tudsz állni. Ezért időnként valóban vissza kell állítani egy mintát egy tesztkörnyezetbe, ellenőrizni, hogy ép és teljes, és naplózni az eredményt (Szabályzat-csomag mentés-teszt napló, NYV-03). A tesztelt visszaállítás az egyetlen bizonyíték arra, hogy a mentésed működik.
TOVÁBB
Folytasd a felkészülést
Következő és kapcsolódó témák

Megvan az elv - mennyire állna helyre a céged?

A mentési rend és a visszaállítás tesztelése szervezeti munka, amit magadnak kell elvégezned — de a kitettséged egy részét (sérülékeny, kívülről elérhető felületek, gyenge konfiguráció, hiányzó fejlécek) egy ingyenes szivárgás-audit pár perc alatt megmutatja, konkrétan a saját domained alapján. Jó kiindulópont, mielőtt a folytonossági tervet összerakod.

Indíts ingyenes auditot →