Ransomware-álló mentés 2026-ban: a 3-2-1-1-0 szabály, immutable és air-gap a gyakorlatban

2026. szeptember 15-én az Amazon Web Services kiadott egy státuszfrissítést, amilyet hyperscalertől ritkán látni: nem tudja visszaállítani a hozzáférést azokhoz az erőforrásokhoz és adatokhoz, amelyek kizárólag az Egyesült Arab Emírségekben működő me-central-1 régió mec1-az2 rendelkezésre állási zónájában voltak. Ugyan ez nem egy ransomware esemény volt az Amazonnál, de ez az eset is jól mutatja, mennyire fontos pl a ransomware-álló, az offsite vagy akár a több-régiós, külön hordozó médiára való mentés kialakítása. A márciusi dróntámadások a régió három zónájából kettőt vittek le; Bahreinben a károk több zónára terjedtek, meghaladva azt, amit a redundanciatervezés elbír.

Ezt a hírt sokan úgy olvassák, hogy „az AWS elvesztette az ügyfelek adatait”. Nem ez történt — és a pontos olvasat kellemetlenebb tanulság. A végleges veszteség azokat érte, akiknek az adata egyetlen zónában létezett. Akinél volt másik régióba replikált vagy saját vason tartott másolat, annak ez hosszú kimaradás volt, nem adatvesztés. Ugyanez a törésvonal fut végig a zsarolóvírus-eseteken is: nem az dönti el a kimenetelt, hogy mi éri a rendszert, hanem hogy hány egymástól független példány van az adatból.

Amit az AWS-eset tényleg mond — és amit nem

A felhőszolgáltató a saját infrastruktúrájáért felel, az adat életciklusáért az ügyfél. Három félreértés, amit érdemes rendbe tenni:

„A többzónás kialakítás eleve megvédett.” A több zónára szétosztott üzemeltetés magas rendelkezésre állást ad, nem mentést. A zónák egy régión belül vannak: egyetlen üzemeltető, egyetlen jogosultsági rendszer, egyetlen földrajzi terület. A 3-2-1 „két médiatípus” és „egy példány telephelyen kívül” eleme ettől nem teljesül.

„Majd a szolgáltató visszanyeri valahonnan.” Régiók közötti replikáció van, és ha be van kapcsolva, tényleg abból áll vissza az adat — de ezt az ügyfélnek kell előre beállítania. Utólag nem lehet bekapcsolni valamire, ami már nincs meg. A 2025. októberi AWS-leállásról szóló cikkünkben ugyanez volt a tanulság, akkor még adatvesztés nélkül.

„Ez háborús szélsőség, minket nem érint.” A kiváltó ok egyedi, a mechanizmus nem: tűz, vízkár, áramkimaradás. A dél-koreai kormányzati adatközpont tüzénél 858 TB adat veszett oda, mert nem volt külső másolat — ott egy lítiumion-akkumulátor okozta a tüzet, nem drón. Ugyanide vezet egy szerverszobai tűz vagy egy elhibázott tárolóművelet is, kisebb léptékben és nagyobb valószínűséggel.

Miért nem elég önmagában a 3-2-1?

A klasszikus szabály — három példány, két különböző médián, egy telephelyen kívül — jó válasz a lemezhibára, a véletlen törlésre és a fizikailag megsemmisült adatközpontra. Egyetlen dologra nem készült fel: az aktív, gondolkodó támadóra.

A modern zsarolóvírus-kampány nem a titkosítással kezdődik. A támadó hetekig mozog a hálózaton, feltérképezi a mentési infrastruktúrát, megszerzi a mentőfiók jelszavát, és csak azután indítja a payloadot, hogy a visszaállítás lehetőségét már elvette. A Sophos State of Ransomware felmérése szerint a megtámadott szervezetek 94%-ánál a támadó megpróbálta kompromittálni a mentéseket is, és az esetek 57%-ában sikerrel járt. Ahol a mentés is elesett, 67%-ban fizettek váltságdíjat — ahol kitartott, csak 36%-ban.

Ha a három példány mindegyike ugyanazzal a tartományi adminisztrátori fiókkal elérhető és írható, akkor az nem három példány — az egy példány, három helyen. Pontosan úgy, ahogy a három zóna egy régión belül sem három független másolat.

A magabiztosság közben magas: a Veeam 2026. áprilisi felmérésében a 900-nál több megkérdezett IT-, biztonsági és kockázatkezelési vezető 90%-a bízott a gyors helyreállásban. A zsarolóvírussal érintett szervezeteknek mégis csak 28%-a állította vissza teljesen az adatait, és átlagosan az érintett állomány 72%-a jött vissza.

Mit tesz hozzá a 3-2-1-1-0?

A 3-2-1-1-0 szabály a régi struktúrát tartja, két kötelező elemmel kiegészítve.

Elem	Mit jelent	Technikai megvalósítás
3	három adatpéldány	éles rendszer + két mentés
2	két különböző médiatípus	lemez + szalag, vagy lemez + objektumtár
1	egy példány telephelyen kívül	más régió, más telephely, más szolgáltató
+1	egy módosíthatatlan vagy air-gapelt példány	Object Lock, hardened repository, offline szalag
+0	nulla helyreállítási hiba	dokumentált, rendszeres visszaállítási próba

A +1: olyan másodpéldány, amit a kompromittált admin sem tud törölni

A lényeg nem a másolat léte, hanem hogy a törléshez szükséges jogosultság ne legyen ugyanabban a hitelesítési tartományban, mint amit a támadó megszerzett. Ha a mentés törléséhez elég egy megszerzett domain admin jelszó, akkor nincs +1.

A +0: a mentés addig hipotézis, amíg vissza nem állítottad

A nulla azt jelenti, hogy a helyreállítási próbának hiba nélkül kell végződnie. Nem elég, hogy a mentési job zöld: a job sikere azt igazolja, hogy az adat kiíródott, nem azt, hogy vissza is jön. A 28%-os teljes helyreállítási arány mögött jórészt olyan cégek állnak, ahol a mentés futott, csak soha nem tesztelték.

Immutable vagy air-gap? Nem ugyanaz

A két fogalmat a marketinganyagok gyakran felcserélik, pedig más-más fenyegetés ellen védenek.

A logikai elszigetelés (immutable, WORM) azt jelenti, hogy a tárolóréteg megtagadja a módosítást és a törlést a retenciós időszakon belül. Az Amazon S3 Object Lock két üzemmódja közti különbség lényeges: governance módban a megfelelő jogosultsággal rendelkező fiók feloldhatja a zárolást, compliance módban a retenció csak meghosszabbítható, rövidíteni még a root fiók sem tudja. Ransomware ellen a compliance mód az értelmes választás.

Helyben, saját vason ugyanezt adja a Veeam hardened repository: Linux-szerver XFS fájlrendszerrel, ahol a mentési fájlokra a rendszer a chattr +i immutable attribútumot állítja be, amit root sem tud levenni a retenció lejárta előtt. A telepítés egyszer használatos hitelesítő adatokkal történik, így a jelszó nem kerül be a mentőkiszolgáló adatbázisába.

A fizikai elszigetelés (air-gap) ennél egyszerűbb és erősebb: a médiát kiveszed a meghajtóból. Egy polcon álló szalagkazettát semmilyen távoli jogosultság nem tud felülírni, és semmilyen szolgáltatói incidens nem érinti. Az LTO-10 generáció kazettánként 30 TB natív kapacitást ad — egy közepes vállalat teljes adatvagyona elfér néhány kazettán.

A kettő nem alternatíva egymásnak: a logikai immutabilitás gyors napi visszaállítást ad, a fizikai másolat pedig arra kell, amikor kiderül, hogy a támadó a mentőinfrastruktúrában is bent volt — vagy hogy a szolgáltató nem tudja visszaadni az adatot.

A +0 gyakorlata: hogyan bizonyítod, hogy a mentés visszaáll

A visszaállítási próba akkor ér valamit, ha izolált hálózati szegmensben fut, éles adatra, mért idővel. Amit rögzíteni kell róla:

• mely rendszert állítottad vissza és melyik mentési pontból,
• mennyi idő alatt lett használható (ez a valós RTO, nem a tervezett),
• mekkora adatvesztés keletkezett az utolsó konzisztens pontig (a valós RPO),
• milyen manuális lépés kellett, ami nincs benne a helyreállítási tervben.

Ez a jegyzőkönyv nemcsak belső célra jó. A NIS2 alapján készülő folytonossági dokumentációban a rendszeres, tesztelt mentés kifejezett elvárás, és auditon a „futnak a mentések” önmagában nem bizonyíték — a NIS2 hardveres megfeleléséről szóló összefoglalónkban végigvettük, mit kér számon az auditor a vason.

A hardveroldal: mit igényel ez a vállalattól

A 3-2-1-1-0 nem szoftverlicenc kérdése. Három hardverigényt támaszt.

Dedikált mentőszervert, amely nem a virtualizációs klaszter mellékterméke. Az immutable repository lényege a leválasztott hitelesítés — ha ugyanaz a Windows-tartomány kezeli, mint az éles rendszereket, a védelem papíron van meg. Egy külön Linux-gép saját, lokális fiókkal lényegesen többet ér.

Nyers kapacitást. A retenciós idő alatt a módosíthatatlan mentés nem törölhető, tehát a teljes retenciós ablak helyfoglalására kell méretezni. XFS block cloning mellett a szintetikus teljes mentések nem sokszorozzák a helyet, de tervezni így is bőven kell.

Szalagos meghajtót vagy szalagtárat, ha a fizikai air-gap is cél. Egy önálló LTO-drive a legtöbb kkv-nál elegendő, heti rotációval.

Mindhárom igény kapacitás- és megbízhatóság-orientált, nem csúcsteljesítmény-orientált: a mentőszerver éjjel dolgozik, nagy blokkokat ír szekvenciálisan. Ebben a szerepben hozza a felújított enterprise vas a legjobb ár-érték arányt — egy néhány éves, kétprocesszoros, sok lemezhellyel szerelt gép nettó árban a töredékébe kerül egy új kiszolgálónak, miközben az ECC memória, a redundáns tápegység és a hardveres RAID mind adott. A szerverdokk.hu kínálatában elérhető nagy lemezkapacitású modellek pont erre készültek.

Összefoglalás

Az AWS-eset kivette a vitából az utolsó kifogást. Eddig a 3-2-1-et el lehetett intézni azzal, hogy „a felhőben biztonságban van” — mostantól van rá dokumentált eset, hogy a piac legnagyobb szolgáltatója írásba adta: az adat nincs meg. Nem azért, mert rossz szolgáltató, hanem mert egy példány egy példány marad, akárki üzemelteti.

Hét kérdés a következő mentési felülvizsgálatra:

1. Van legalább egy olyan mentési példány, amit a tartományi adminisztrátori jog sem tud törölni?
2. Van olyan példány, amely fizikailag más helyszínen — más régióban, más telephelyen — van?
3. Az Object Lock compliance módban fut, vagy a governance mód megkerülhető?
4. Van fizikailag leválasztott, offline másolat is, nem csak logikai immutabilitás?
5. Mikor volt az utolsó teljes visszaállítási próba, és mennyi ideig tartott?
6. A mért RTO és RPO egyezik a tervezettel?
7. A mentőinfrastruktúra hitelesítése le van választva az éles környezetről?

Ha valamelyikre nem egyértelmű a válasz, ott van a rés, amit a támadó a hálózatban töltött idő (dwell time) alatt megkeres — vagy amit egy szolgáltatói incidens talál el.

Ha holnap reggel kiderülne, hogy az elsődleges rendszer és a hozzá legközelebbi másolat egyszerre vált elérhetetlenné — melyik példányból indulnál el, és mikor próbáltad ki utoljára, hogy az tényleg visszaáll?

Kapcsolódó olvasmányok:

• Adatbiztonság és amit az adatmentési stratégiáról tudnod kell — a 3-2-1 alapjai lépésről lépésre
• BCP és DR terv készítése: így védd meg céged az IT-katasztrófáktól — a mentés köré épülő folytonossági terv
• Adatvesztés: így védheted meg vállalkozásod adatait — mibe kerül, ha nincs használható másolat

AWS-eset – forrásháttér

• CNBC, 2026-09-15 — AWS nem tudja visszaállítani a szolgáltatást Bahreinben és az EAE egy részén
• The Register, 2026-09-16 — „gone for good”, mec1-az2 megnevezve
• Help Net Security, 2026-09-17 — végleges adatvesztés
• DataCenterDynamics — a márciusi becsapódás és tűz
• CNBC, 2026-03-04 — a támadás ténye