Egy komoly leállás után két kérdés mutatja meg, mekkora volt a kár: mennyi adat veszett el, és meddig nem lehetett dolgozni. Az RPO és az RTO ezekre a kérdésekre ad előre rögzített választ. Belőlük vezethető le a mentési rend, és az is, melyik rendszer kerüljön sorra először a visszaállításnál.
A két számot sok helyen soha nem írták le, vagy leírták, de senki nem mérte meg, tartható-e. A célidő akkor ér valamit, ha egy üzleti döntésből származik, és egy próba igazolja.
Mit jelent az RTO és az RPO
Az RPO (Recovery Point Objective, helyreállítási pont célértéke) azt adja meg, legfeljebb mennyi idő munkája veszhet el. A hiba pillanatától visszafelé mérjük az utolsó használható helyreállítási pontig. Ha a mentés minden éjjel fut, és a rendszer este hétkor áll le, akkor az egész napi adat hiányzik. Napi mentésnél a legrosszabb eset közel 24 óra.
Az RTO (Recovery Time Objective, helyreállítási idő célértéke) azt mondja meg, mennyi idő alatt kell a szolgáltatásnak a kiesés után újra használhatónak lennie. Az óra a leállásnál indul. A hiba észlelése, a döntés a helyreállításról és a felhasználók értesítése is beleszámít, a tényleges adatmásolás csak egy szelete.
A NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems, 2010) egy harmadik mutatót is használ: a legnagyobb elviselhető kiesési időt (maximum tolerable downtime, MTD). Ez az üzleti folyamat tűrése, amelyen túl a kiesés már elfogadhatatlan következménnyel jár. Az RTO-t ennél rövidebbre kell szabni, mert a rendszer visszaállása után a folyamatnak is el kell indulnia.
| Mutató | Kérdés | Mi határozza meg a gyakorlatban |
|---|---|---|
| RPO | Mennyi adat veszhet el? | A mentés vagy a replikáció gyakorisága és a megőrzött helyreállítási pontok |
| RTO | Mennyi ideig állhat a szolgáltatás? | A visszaállítás sebessége, a sorrend, a rendelkezésre álló emberek és a tartalék infrastruktúra |
| MTD | Mikortól elviselhetetlen a kiesés? | Az üzleti folyamat: határidők, szerződések, jogszabályi kötelezettségek |
A két célértéket külön kell meghatározni, bár a gyakorlatban összefüggenek: a rövidebb RPO-t adó napló- vagy replika-visszaállítás az RTO-t is módosíthatja, és mindkettőt az MTD korlátozza. Egy könyvelési rendszerben minden rögzített tétel számít, ezért az RPO rövid, egy-két napos állást viszont a folyamat kibírhat. Egy webáruház termékkatalógusa fordított eset: az adat ritkán változik és könnyen pótolható, a kiesés viszont azonnal érződik.
Üzleti hatáselemzés: melyik rendszer mennyi kiesést bír
A célidőket az üzleti hatáselemzés (business impact analysis, BIA) adja. Az ISO 22301:2019 szabvány az üzletmenet-folytonossági irányítási rendszer kötelező elemeként írja elő, módszertani útmutatót az ISO/TS 22317 ad hozzá. A lényege, hogy folyamatonként felméri, mi történik, ha a folyamat leáll, és hogyan nő a kár az idő múlásával: pénzben, szerződéses kötbérben, jogi következményben, biztonsági kockázatban és az ügyfelek bizalmában.
Az elemzés kiindulópontja a folyamatlista. A folyamatgazda tudja megmondani, mennyi kiesést tűr a számlázás vagy a raktári kiadás, az IT-csapat pedig hozzárendeli azokat a rendszereket, amelyeken a folyamat fut. Egy alkalmazás így több folyamat célidejét is örökölheti, és mindig a legszigorúbb érvényes rá.
Kérdések a folyamatgazdának
- Mennyi idő után érzi meg a kiesést az ügyfél, a partner vagy a termelés?
- Van-e kézi kerülőút, például papíralapú rögzítés, és meddig tartható fenn?
- Milyen határidő, szerződéses vállalás vagy hatósági bejelentési kötelezettség kötődik a folyamathoz?
- Az elveszett adat pótolható-e újrarögzítéssel vagy más forrásból, és mennyi munkával?
- Vannak-e időszakok, például hónapzárás vagy szezon, amikor a tűrés jóval kisebb?
Az elemzés gyakori csapdája, hogy minden folyamatgazda a saját rendszerét mondja kritikusnak. Ha mindenre ugyanaz a rövid célidő vonatkozik, a helyreállítási sorrend elveszti az értelmét, a mentési infrastruktúrát pedig a legszigorúbb igényre kell méretezni. Segít, ha a válaszokat a következményekkel kell alátámasztani, és ha a végső besorolást egy vezető hagyja jóvá, aki a folyamatokat együtt látja. A rendszerek szintekbe sorolásáról a mentési stratégiáról szóló cikk is ír.
Mentési gyakoriság és helyreállítási sorrend
Az RPO felső korlátot szab a két mentés között eltelt időre. Ahol egy nap adatvesztés elfogadható, ott elég az éjszakai mentés. Rövidebb RPO-hoz sűrűbb inkrementális mentés kell, adatbázisoknál pedig a tranzakciós napló rendszeres mentése, amellyel egy adott időpontra lehet visszaállni.
A replikáció nem mentés
A tárolói vagy virtuálisgép-szintű replikáció hardverhiba ellen rövid RPO-t ad: szinkron replikációnál közel nullát, aszinkronnál a replikációs intervallumnyit, ami másodpercektől percekig vagy tovább terjedhet. Közben minden változást átvisz, a véletlen törlést és a titkosított fájlt is. Logikai hibánál és zsarolóvírusnál a replika ugyanolyan használhatatlan, mint az eredeti. Ezért a replikáció mellé is kellenek visszamenőleg megőrzött helyreállítási pontok, köztük olyan, amelyet a támadó nem tud törölni, mint az immutable mentés.
Zsarolóvírus után a ténylegesen használható helyreállítási pont gyakran régebbi, mint a legutolsó mentés. Ha a támadó hetekkel a titkosítás előtt jutott be, a közbenső mentésekben is ott lehet a hátsó kapu. A valós RPO ilyenkor azon múlik, milyen messzire nyúlik vissza a megőrzés, és sikerül-e megtalálni az utolsó tiszta pontot. A támadás menetéről a zsarolóvírus-védelemről szóló cikk szól.
Az RTO és az adatmennyiség
Az RTO-t a visszatöltés sebessége is korlátozza. Tíz terabájt adat egy gigabites kapcsolaton elméletben is közel 22 óra alatt jön át, a gyakorlatban a protokoll, a tároló és a deduplikáció visszafejtése ezt tovább nyújtja. Ha a másolat felhőben vagy távoli telephelyen van, érdemes kiszámolni, mennyi ideig tart a teljes visszatöltés, és hogy a rövid RTO-jú rendszereknek van-e helyben is visszaállítható másolatuk.
A sorrend
Egy teljes leállás után nem lehet mindent egyszerre visszaállítani, ezért a sorrendet előre rögzíteni kell. Az üzleti besorolás megmondja, melyik alkalmazás fontosabb. Az infrastruktúra határozza meg, mi indulhat el egyáltalán. Egy jellemző sorrend:
- Hálózat és tűzfalak, virtualizációs és tárolóréteg.
- A mentőrendszer maga, ha sérült: a katalógus nélkül a visszaállítás sokkal lassabb, mert előbb a mentési adathordozót vagy tárolót kell újra beolvasni.
- Címtár, névfeloldás, időszinkron és tanúsítványszolgáltatás.
- Adatbázis-kiszolgálók, a legrövidebb RTO-jú alkalmazások adatbázisaival kezdve.
- Alkalmazásszerverek és integrációk, a besorolás szerint.
- Felhasználói elérés: távoli hozzáférés, munkaállomások, nyomtatás.
Függőségek: címtár, DNS, hálózat
Gyakori hibaforrás a próbákon, hogy a visszaállított alkalmazás elindul, de senki nem tud belépni, mert a címtár még nem él, vagy az alkalmazás nem találja az adatbázist, mert a névfeloldás régi címre mutat. Ezek a függőségek az üzemben láthatatlanok, a terv viszont ezeken akad el.
Címtár
A legtöbb alkalmazás, a fájlmegosztás, a távoli elérés és sokszor a mentőkonzol is a tartományi fiókokra épül. A tartományvezérlő visszaállításának saját szabályai vannak. Virtuálisgép-pillanatképből csak akkor biztonságos, ha a hipervizor és a címtár is felismeri, hogy a vezérlő egy korábbi állapotból indult. Ha ez a támogatás hiányzik, a visszaállított vezérlő kieshet a szinkronból: a címtár ezt észleli, naplózza, és leállítja rajta a replikációt. Ilyenkor a vezérlőt jellemzően le kell fokozni és újra kell építeni. A teljes címtár, vagyis az egész erdő helyreállításának lépéseit érdemes előre, a saját környezetre szabva a tervbe írni. Ha a leállást támadás okozta, a címtárat a visszaállítás után is ellenőrizni kell, mert a támadó által létrehozott fiókok és jogosultságok a mentéssel együtt visszajönnek. A címtár elleni jellemző támadásokról a címtár védelméről szóló cikk ír.
DNS és időszinkron
Az alkalmazások névvel hivatkoznak egymásra. A címtárba integrált DNS a tartományvezérlővel együtt áll helyre, a külső zónák és a nyilvános rekordok viszont máshol élnek. Ha a tartalék helyszínen mások az IP-címek, a rekordokat át kell írni, és a beállított TTL szabja meg, mikor látják a kliensek az új címet. Rövid RTO-jú szolgáltatásoknál a TTL-t érdemes előre alacsonyra venni. Az időszinkron is függőség: a Kerberos alapértelmezésben legfeljebb öt perc óraeltérést tűr, ezen túl a hitelesítés meghiúsul.
Hálózat és a kevésbé látható szolgáltatások
A hálózat visszaállításához a tűzfalak, kapcsolók és útválasztók konfigurációs mentése kell, a VLAN-ok, a címtervek és a VPN-beállítások dokumentációjával együtt. Ugyanebbe a körbe tartozik a belső tanúsítványkiadó, a licencszerver, a többfaktoros hitelesítés szolgáltatása és minden külső felhőszolgáltatás, amelyen egy belső alkalmazás múlik. Mindegyiknél meg kell nézni, hol van a mentése, és ki tudja visszaállítani.
A katasztrófa-helyreállítási terv tartalma
Az üzletmenet-folytonossági terv azt írja le, hogyan működik tovább a szervezet egy zavar alatt. A katasztrófa-helyreállítási terv ennek az informatikai része: hogyan áll helyre a rendszer a célidőkön belül. A jó terv annak is használható, aki nem írta, és éjjel, fáradtan, a megszokott eszközei nélkül kell követnie.
- Hatály és indítás: milyen esemény indítja el a tervet, és ki jogosult az aktiválásáról dönteni.
- Szerepek: ki vezeti a helyreállítást, ki melyik rendszerért felel, és ki helyettesíti, ha nem elérhető.
- Elérhetőségek: a csapat, a beszállítók és a szolgáltatók telefonszámai, nyomtatott formában is.
- Rendszerlista: minden rendszer RTO-ja, RPO-ja, besorolása és helye a sorrendben.
- Függőségi térkép: mi kell egy rendszer indításához és mi a használatához.
- Lépésenkénti visszaállítási leírások rendszerenként, a szükséges parancsokkal és ellenőrzésekkel.
- Hitelesítő adatok és kulcsok: hol van a vészhelyzeti fiók, a titkosított mentések kulcsa és a mentőrendszer adminisztrátori hozzáférése.
- Tartalék infrastruktúra: hol fut a visszaállított rendszer, ha az eredeti hardver vagy telephely nem használható.
- Kommunikáció: kit, mikor és milyen csatornán kell értesíteni belül és kívül.
- Visszatérés és lezárás: hogyan kerül vissza az üzem az eredeti környezetbe, és ki mondja ki, hogy a helyreállítás véget ért.
A tervnek ott kell lennie, ahol a leállás nem éri el. Ha csak a fájlszerveren vagy a wikin van, akkor éppen abban a helyzetben nem érhető el, amelyre írták. Bevált megoldás a nyomtatott példány és egy, a vállalati környezettől független helyen tárolt másolat.
Kiberincidens után más a menet
Áramszünet vagy hardverhiba után a visszaállítás azonnal kezdődhet. Támadás után előbb ki kell zárni a támadót, meg kell őrizni a bizonyítékokat, és tiszta, a fertőzött hálózattól elválasztott környezetbe kell visszaállítani. A túl korai visszaállítás újrafertőzéshez vezethet. Emiatt a kibertámadásra érvényes forgatókönyvnek a tervben saját, hosszabb időkerete lehet. Az első órák teendőit az incidens első 24 órájáról szóló cikk írja le.
A szabályozás is számol ezzel a területtel. A NIS2-irányelv ((EU) 2022/2555) 21. cikke a kötelező kockázatkezelési intézkedések között nevezi meg az üzletmenet-folytonosságot, a mentések kezelését és a katasztrófa utáni helyreállítást. A pénzügyi szektorra vonatkozó DORA-rendelet ((EU) 2022/2554) 11. és 12. cikke a reagálási és helyreállítási terveket, a mentési szabályzatot és a visszaállítási eljárásokat részletezi.
Visszaállítási teszt: a célidők ellenőrzése
Az RTO és az RPO addig csak cél, amíg valaki meg nem mérte. A NIST SP 800-84 (Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, 2006) a gyakorlatok több fajtáját írja le, a terv közös átbeszélésétől a funkcionális gyakorlatig, amelyben a résztvevők a tényleges lépéseket hajtják végre, éles vagy szimulált környezetben. A kettő mást mutat meg. Az asztali gyakorlat a szerepek és a döntési pontok hiányait hozza elő, például hogy senki nem tudja, ki hirdeti ki a terv indítását. A tényleges visszaállítás a technikai akadályokat és a valós időket mutatja meg.
Mit mérjen a próba
| Mért érték | Mivel kell összevetni |
|---|---|
| Az eltelt idő a leállás bejelentésétől a használható szolgáltatásig, lépésenként rögzítve | RTO |
| A visszaállított adat legutolsó időpontja | RPO |
| Az adat teljessége és belső konzisztenciája, adatbázisnál integritás-ellenőrzéssel | A folyamatgazda elfogadási feltétele |
| Egy valós felhasználói művelet sikere, például egy számla kiállítása | A folyamat tényleges újraindulása |
A lépésenkénti időmérés azért hasznos, mert megmutatja, hol megy el az idő. Az idő jelentős része gyakran az adatmásoláson kívül megy el: a megfelelő mentés megtalálásán, a hiányzó jelszó előkerítésén vagy egy tűzfalszabályon, amelyet a próba közben kell kitalálni. A visszaállítási próba gyakorlati lépéseit a mentési stratégiáról szóló cikk sorolja fel.
Ha a mért idő hosszabb a célnál, két út van: a technikát kell gyorsítani (helyi másolat, előre felépített tartalék környezet, sűrűbb mentés), vagy a folyamatgazdával újra meg kell állapodni a célidőről. A célt csendben, a próba után módosítani nem szabad, mert akkor az üzlet egy olyan számra tervez, amely senkinek nem vállalása. A próbát érdemes nagyobb változás után is megismételni: új rendszer bevezetése, migráció, a mentőszoftver cseréje vagy a telephely átalakítása után a korábbi mérés már nem érvényes.
Kapcsolódó szolgáltatás: Mentés és katasztrófa-helyreállítás →
