Mentési stratégia: a 3-2-1 szabály ma

A mentés az a terület, ahol a legtöbb szervezet azt hiszi, rendben van, egészen az első valódi visszaállításig. A klasszikus 3-2-1 szabály jó kiindulópont, de a zsarolóvírus üzleti modellje óta önmagában kevés. Ez a cikk arról szól, mi hiányzik belőle, és hogyan lehet ellenőrizni, hogy a mentés tényleg mentés-e.

A klasszikus szabály

3-2-1: legyen legalább 3 másolat az adatból, 2 különböző adathordozón, és 1 másolat legyen telephelyen kívül.

Ez a szabály hardverhibára, tűzre és lopásra tervezték, és ezekre ma is jó válasz. Amire nem készült fel, az a célzott támadó, aki hetekig bent van a hálózatban, és aki a titkosítás előtt szándékosan tönkreteszi a mentéseket.

A valós incidensekben ez a lépés szinte mindig megtörténik. A támadó tartományi adminisztrátori jogot szerez, majd megkeresi a mentőszervert, törli a snapshotokat, és csak utána indítja a titkosítást. Ha a mentés ugyanabban a tartományban van, ugyanazokkal a hitelesítő adatokkal elérhető, akkor a 3-2-1 mindhárom másolata egyszerre vész el.

Amivel ki kell egészíteni: 3-2-1-1-0

Az iparági gyakorlat ezért két számmal bővítette a szabályt.

A két új elem az, ami ma a különbséget jelenti.

A megváltoztathatatlan másolat

Az immutable mentést a megőrzési idő lejárta előtt senki nem törölheti és nem módosíthatja, még adminisztrátori joggal sem. Több megvalósítása van:

• Objektumzárolás (object lock) tárolón vagy felhőben, WORM módban.
• Szalag, ami a kiírás után fizikailag kikerül a meghajtóból. Régimódi, de a támadó nem éri el a hálózaton keresztül.
• Külön hitelesítési tartomány: a mentőrendszer nem tagja a vállalati tartománynak, saját, nem újrahasznált hitelesítő adatokkal és MFA-val.

A harmadik pont önmagában is óriási különbség. Ha a mentőszerverre a tartományi admin nem tud belépni, a támadási lánc ott megszakad.

A nulla hiba

A mentés léte nem bizonyíték. Csak a sikeres visszaállítás az.

A tapasztalat szerint a mentési feladat "sikeres" státusza és a valóban visszaállítható adat között meglepően gyakran van különbség: hiányzó adatbázis-konzisztencia, kihagyott mappák, nem mentett konfigurációk, lejárt titkosítási kulcs, dokumentálatlan visszaállítási sorrend.

Hogyan tesztelje a visszaállítást

Negyedévente egy próba elég, de valódinak kell lennie.

1. Válasszon ki egy valós rendszert, ne a legkisebbet. Ideálisan olyat, ami üzletileg fontos.

2. Állítsa vissza izolált környezetbe. Külön hálózati szegmens, hogy ne zavarja az élest.

3. Mérje az időt. Mennyi idő alatt állt vissza? Ez a valós RTO, nem az, ami a papíron van.

4. Ellenőrizze az adatot. Nemcsak azt, hogy elindul-e, hanem hogy az adat konzisztens és teljes-e. Adatbázisnál ez integritás-ellenőrzést jelent.

5. Dokumentálja az akadályokat. Mi hiányzott, mit nem talált a csapat, hol kellett improvizálni. Ezek a következő incidensben órákat vagy napokat jelentenek.

Egy évente egyszeri, teljes körű helyreállítási gyakorlat (több rendszer, valós forgatókönyv szerint) ezen felül javasolt.

RTO és RPO: a két szám, amit tudni kell

Ezt a két mutatót az üzlettel közösen kell meghatározni, nem az IT-nak egyedül.

• RPO (Recovery Point Objective): mennyi adatvesztés fogadható el? Ha a mentés naponta egyszer fut, az RPO 24 óra. Egy pénzügyi tranzakciós rendszernél ez elfogadhatatlan.
• RTO (Recovery Time Objective): mennyi idő alatt kell visszaállnia a szolgáltatásnak?

A gyakori hiba, hogy ezeket sosem beszélik meg. Az IT azt hiszi, a napi mentés elég, az üzlet pedig azt hiszi, két óra alatt minden visszaáll. Az incidens közepe rossz alkalom kideríteni, hogy egyik sem igaz.

Rendszerenként érdemes besorolást csinálni: kritikus (RTO 4 óra), fontos (RTO 24 óra), normál (RTO 72 óra). A besorolás dönti el, hova költ.

Amit szinte mindenki kihagy

A konfiguráció mentése. Nemcsak az adat kell, hanem a tűzfalszabályok, a hálózati konfiguráció, a tartományi beállítások, a tanúsítványok. Egy teljes helyreállításnál ezek nélkül nincs mihez visszaállítani az adatot.

A felhős adat. Sokan azt hiszik, a felhőszolgáltató ment. A legtöbb szolgáltatónál a felelősség megosztott: az infrastruktúra az övé, az adat a tiéd. A postafiókok, a fájlmegosztás és a felhős alkalmazások adata gyakran teljesen mentetlen.

Az OT-környezet. A PLC-programok, a HMI-projektek és a mérnöki munkaállomások konfigurációja. Sok üzemben a "mentés" egy évekkel ezelőtti fájl egy mérnök laptopján. Ezeknek offline másolatban a helyük.

A visszaállítási dokumentáció. Ha a leírás csak azon a rendszeren van, amit vissza kell állítani, akkor nincs.

Összefoglalva

A mai mentési stratégia három dolgon áll vagy bukik:

1. Van-e olyan másolat, amit a támadó nem tud elérni a kompromittált hálózatból.
2. Tesztelte-e valaki, hogy tényleg vissza lehet állítani.
3. Egyezik-e az üzleti elvárás azzal, amit a rendszer valóban tud (RTO/RPO).

Ez a három kérdés egy délelőtt alatt megválaszolható, és a válasz szinte mindig meglepetést okoz. A zsarolóvírus-védelemről és az incidens első 24 órájáról külön cikkben írtunk.