5 kritikus hiba, amit a vállalkozások elkövetnek adatmentés során – és hogyan kerüld el őket

Kategória: IT-biztonság / Üzleti folyamatosság
Olvasási idő: ~8 perc
Célközönség: KKV-vezetők, IT-döntéshozók, operatív igazgatók

„Az adatvesztés nem az a kérdés, hogy megtörténik-e – hanem az, hogy mikor és felkészülve vagy-e rá." — általánosan elfogadott elv a kiberbiztonsági szakmában

Miért számít ma jobban, mint valaha?

A Veeam 2024-es globális adatvédelmi felmérése szerint a szervezetek 93%-a szenvedett el valamilyen nem tervezett leállást az elmúlt 12 hónapban, és az átlagos helyreállítási idő (RTO) még mindig meghaladja az IT-csapatok által vállalt célértéket. A zsarolóvírus-támadások száma évről évre 13%-kal nő – és az áldozatok nagy többsége nem Fortune 500-as vállalat, hanem kis- és közepes méretű vállalkozás.

Az adatvesztés üzleti következményei három szinten csapnak le:

• Operatív szint: leállás, elveszett munkaidő, késő projektek
• Pénzügyi szint: helyreállítási költségek, bírságok (GDPR), bevételkiesés
• Reputációs szint: ügyfélbizalom elvesztése, szerződések felmondása

Mégis: a legtöbb vállalkozásnál az adatmentési stratégia évek óta nem változott, az IT-csapat „úgy gondolja, hogy működik" – de soha nem tesztelte.

Ez a cikk az öt leggyakrabban előforduló és egyben legdrágább hibát mutatja be, amelyeket valódi incidensvizsgálatok és iparági adatok alapján azonosítottunk.

1. hiba: Nincs tesztelve a visszaállítás – csak a mentés

Ez a legelterjedtebb és legveszélyesebb tévhit az adatmentés terén: ha a mentési folyamat zöld pipát kap, az adatok biztonságban vannak.

Nem. A mentés csak az első lépés.

Mi a probléma pontosan?

A mentési fájl meglétét és a működőképes visszaállítást összetévesztik. Egy sérült, hiányos vagy nem kompatibilis mentés ugyanolyan értéktelen katasztrófa esetén, mintha nem is létezett volna.

A Gartner adatai szerint az IT-szervezetek közel 60%-a soha nem végez éles visszaállítási tesztet éles környezetben.

Mi a helyes gyakorlat?

• Negyedévente legalább egy teljes visszaállítási tesztet kell végezni izolált tesztkörnyezetben
• A teszt nem ér véget a visszaállítással: ellenőrizni kell az adatok integritását és az alkalmazások működőképességét is
• Dokumentálni kell a tényleges RTO-t (Recovery Time Objective) és RPO-t (Recovery Point Objective), majd összevetni az üzleti célértékekkel

Szakmai javaslat: Vezessen be automatizált helyreállítási tesztelést (pl. immutable snapshot verification), amely emberi beavatkozás nélkül, rendszeres időközönként ellenőrzi a mentések visszaállíthatóságát.

2. hiba: Egyetlen másolat, egyetlen helyen

Az „egy mentés = biztonság" logika hamis. Egyetlen másolat egyetlen veszélyeztetéssel elveszhet: tűz, árvíz, zsarolóvírus, hardverhiba, emberi hiba – mind ugyanazt az eredményt hozza.

Az iparági arany standard: a 3-2-1 szabály

• 3 másolat – az eredeti + 2 biztonsági példány (pl. éles adat + NAS + felhő)
• 2 médiatípus – ne csak egyféle adathordozón (lemez + felhő)
• 1 offsite helyszín – fizikailag eltérő lokáció (másik DC vagy felhőszolgáltató)

Miért kritikus az offsite tárolás?

2023-ban egy budapesti középvállalatnál tűz pusztított az irodaházban. A helyi NAS-eszközök és az azokat tartalmazó szerver is megsemmisült. A vállalat „mentése" ugyanabban a helyiségben volt, mint az éles adatok. A helyreállítás nem volt lehetséges.

A felhőalapú mentés (AWS S3, Azure Blob, Backblaze B2) ma már gazdaságos és skálázható megoldás a 3-2-1 szabály megvalósítására még KKV-k számára is.

3. hiba: A mentési stratégia nem igazodik az üzleti prioritásokhoz

Nem minden adat egyforma értékű – de sok vállalkozás mégis egységesen kezeli őket.

Az RPO–RTO mátrix, amit minden döntéshozónak ismernie kell

• RPO (Recovery Point Objective): Maximálisan elfogadható adatvesztés időben mérve. Mennyit engedhetünk meg, hogy elvesszen?
• RTO (Recovery Time Objective): Maximálisan elfogadható leállási idő. Meddig bírjuk ki rendszer nélkül?

Egy e-kereskedelmi platform esetén az RPO néhány perc lehet (tranzakciós adatok), míg egy belső HR-dokumentumtárnál akár 24 óra is elfogadható. Ha mindkettőt ugyanolyan mentési ciklussal kezelik, az vagy pazarlás, vagy kockázat – esetleg mindkettő.

Hogyan csináld helyesen?

1. Azonosítsd a kritikus üzleti folyamatokat és a hozzájuk tartozó adatokat
2. Határozz meg RPO/RTO célértékeket minden adatosztályra üzleti szempontból
3. Válassz mentési megoldást, amely képes teljesíteni ezeket a célértékeket

Ez nem IT-döntés – ez üzleti döntés, amelyet az IT tud végrehajtani.

4. hiba: A zsarolóvírus-fenyegetés figyelmen kívül hagyása a mentési tervezésnél

A hagyományos mentési stratégiák zsarolóvírus ellen nem nyújtanak védelmet – sőt, sok esetben a mentéseket is titkosítják a támadók.

Hogyan képes a zsarolóvírus a mentéseket is megsemmisíteni?

A modern zsarolóvírusok (pl. Conti, LockBit, BlackCat) célzottan keresik és titkosítják a mentési fájlokat, mielőtt aktiválnák a főtitkosítást. Ha a mentési rendszer folyamatosan hálózati kapcsolatban van az éles rendszerrel, a mentések is fertőzötté válnak.

A megoldás: immutable (megváltoztathatatlan) mentések

Az immutable mentés olyan tárolási módszer, amelynél a mentési fájlokat egy meghatározott ideig sem módosítani, sem törölni nem lehet – még rendszergazdai jogosultsággal sem.

Megvalósítási lehetőségek:

• Object Lock funkció (AWS S3, Azure Blob, Wasabi)
• Air-gapped (fizikailag izolált) mentési rendszerek
• WORM (Write Once, Read Many) szalagos archiválás
• Dedikált backup appliance-ek (pl. Veeam Hardened Repository, Commvault)

A Cybersecurity and Infrastructure Security Agency (CISA) kifejezetten ajánlja az immutable backup megoldásokat minden szervezet számára a zsarolóvírus elleni védekezés részeként.

5. hiba: Hiányzó dokumentáció és felelősségi struktúra

A legjobb mentési rendszer is csődöt mondhat, ha válsághelyzetben senki sem tudja, mit kell csinálni, kinek kell dönteni és hol vannak a hozzáférési adatok.

Mit tapasztalnak az incidenselhárítók?

Az adatvesztési incidensek utáni kivizsgálások visszatérő problémái:

• A mentési rendszer jelszavát csak egy személy ismerte, aki éppen szabadságon volt
• A helyreállítási eljárás nincs dokumentálva, az IT-vezető fejében él
• A biztonsági mentések fizikai helyszíne nem ismert az összes érintett számára
• Nincs kijelölt döntési jogkör arra, mikor kell elindítani a katasztrófa-helyreállítási tervet (DRP)

A Disaster Recovery Plan (DRP) minimális tartalma

Egy működőképes DRP-nek legalább a következőket kell tartalmaznia:

1. Eszközleltár és adatosztályozás – mi van, hol van, mennyire kritikus
2. Mentési architektúra leírása – rendszerek, ütemezés, tárolási helyek
3. Helyreállítási eljárások lépésről lépésre – rendszertípusonként
4. Felelősi mátrix (RACI) – ki dönt, ki végrehajt, kit kell értesíteni
5. Kommunikációs terv – belső és külső érintettek (ügyfelek, hatóságok)
6. Tesztelési naptár – mikor, ki, hogyan teszteli a visszaállítást

A dokumentációt offline és titkosítva is kell tárolni – egy felhőalapú dokumentumban tárolt DRP-hez nem fér hozzá a csapat, ha éppen a felhőszolgáltató az érintett.

Összefoglalás: Az 5 kritikus hiba egy táblázatban

Következő lépések – amit ma megtehetsz

Ha most azt gondolod, „ez a mi rendszerünknél is előfordulhat", az első lépés nem egy drága rendszercsere. Ez egy audit.

Az alábbi három kérdés elvégzésére ma megkérhet bárkit a csapatából:

1. Mikor volt utoljára tesztelve a visszaállítás – és van erről írásos dokumentáció?
2. Hány példányban és hány fizikai helyszínen él a legkritikusabb adatod?
3. Ha holnap zsarolóvírus titkosítja az összes szervered, ki hozza meg a döntést és mi az első öt lépés?

Ha ezekre a kérdésekre nincs azonnali, magabiztos válasz – az adatmentési stratégiád felülvizsgálata nem halasztható tovább.