A legtöbb szervezetnél van egy üzletmenet-folytonossági terv: egy fiókban, egy megosztott meghajtón, néha csak egy tanúsítás kedvéért összeállítva. A baj az, hogy a terv értéke nem a meglétében, hanem a működésében rejlik. Egy zsarolóvírus-támadás, egy adatközpont-kiesés vagy egy elhúzódó szolgáltatói leállás nem a dokumentumot teszteli, hanem az Önök képességét arra, hogy a kritikus folyamatokat időben helyreállítsák. Ebben a cikkben végigvesszük, mi a különbség a BCP és a DRP között, mit jelent a BIA, az RTO és az RPO, hogyan épül fel egy működő terv, és miért éppen a rendszeres tesztelés az, ami a papírból valódi képességet csinál.
Mi a különbség a BCP és a DRP között?
A BCP az egész szervezet túléléséről szól, a DRP pedig az IT-rendszerek helyreállításáról. A DRP tehát a BCP egyik részhalmaza, nem a szinonimája. A BCP (Business Continuity Plan, üzletmenet-folytonossági terv) arra ad választ, hogyan tartja fenn a szervezet a kritikus üzleti folyamatait egy zavaró esemény alatt: ki dönt, hol dolgoznak az emberek, hogyan kommunikálnak az ügyfelekkel, milyen kézi vagy alternatív munkamenetekkel hidalják át a kiesést. A DRP (Disaster Recovery Plan, katasztrófa-helyreállítási terv) ennél szűkebb és technikaibb: arról szól, hogyan állítják vissza a konkrét IT-rendszereket, adatokat és infrastruktúrát egy meghibásodás vagy támadás után.
| Szempont | BCP (üzletmenet-folytonosság) | DRP (katasztrófa-helyreállítás) |
|---|---|---|
| Fókusz | teljes szervezet, üzleti folyamatok | IT-rendszerek, adatok, infrastruktúra |
| Cél | a működés fenntartása a zavar alatt | a rendszerek visszaállítása a zavar után |
| Hatókör | emberek, folyamatok, helyszínek, kommunikáció | szerverek, hálózat, mentések, alkalmazások |
| Felelős | üzleti vezetés, folytonossági menedzser | IT- és infrastruktúra-csapat |
| Tipikus tartalom | szerepek, alternatív munkamenetek, eszkaláció | helyreállítási sorrend, mentési rend, futtatókönyvek |
A kettő nem helyettesíti egymást: hiába áll vissza a szerver, ha közben senki nem tudja, ki értesíti az ügyfeleket; és hiába van vészforgatókönyv az emberekre, ha az adat visszaállíthatatlanul elveszett. A működő gyakorlat a kettőt egységes rendszerben kezeli.
Mi az a BIA, és miért ez a tervezés alapja?
A BIA az üzleti hatáselemzés, amely megmutatja, melyik folyamat mennyire kritikus, és mennyi kiesést bír el. Minden további döntés ebből indul ki. A BIA (Business Impact Analysis) során a folyamatokat aszerint rangsorolják, hogy egy leállásuk milyen pénzügyi, jogi, működési és reputációs hatással jár, és ez a hatás hogyan súlyosbodik az idő előrehaladtával. A cél nem az, hogy mindent egyformán „kritikusnak” nyilvánítsanak, épp ellenkezőleg: a BIA segít elkülöníteni azt a néhány folyamatot, amelynek kiesése valóban egzisztenciális, attól a sok funkciótól, amely néhány napig nélkülözhető.
A BIA tipikus kimenetei:
- a kritikus folyamatok rangsorolt listája és a hozzájuk tartozó tolerálható kiesési idő,
- az egyes folyamatok közötti függőségek (rendszerek, beszállítók, kulcsemberek),
- a maximális elviselhető kiesés (MTPD) folyamatonként,
- a helyreállítási prioritások, amelyek a DRP sorrendjét meghatározzák.
A BIA nélküli folytonossági terv vakrepülés: vagy feleslegesen drágán túlbiztosít, vagy épp a legfontosabb folyamatot hagyja védtelenül.
Mit jelent az RTO és az RPO?
Az RTO azt mondja meg, meddig állhat le egy rendszer, az RPO pedig azt, mennyi adatot veszíthetünk el: két különböző kérdés, két különböző célérték. Ez a két mutató a folytonossági tervezés mérnöki nyelve. A BIA-ból levezetett üzleti igényt fordítják le konkrét, mérhető célokká, amelyekre a mentési és helyreállítási megoldásokat tervezni lehet.
| Mutató | Mit mér? | A kérdés, amire válaszol |
|---|---|---|
| RTO (Recovery Time Objective) | helyreállítási időcél | „Meddig állhat le a szolgáltatás, mielőtt a kár elviselhetetlen lesz?” |
| RPO (Recovery Point Objective) | adatvesztési időcél | „Mennyi adatot, hány órányi munkát engedhetünk meg, hogy elvesszen?” |
Egy egyszerű példa: ha egy rendszer RTO-ja 4 óra, akkor a kiesés kezdetétől számítva négy órán belül újra működnie kell. Ha az RPO-ja 1 óra, akkor legfeljebb egy óra adatvesztés elfogadható, ami a gyakorlatban óránkénti (vagy gyakoribb) mentést igényel. Minél szigorúbb a célérték, annál drágább a megoldás, ezért az RTO/RPO meghatározása mindig üzleti és költségdöntés, nem pusztán technikai paraméter.
Hogyan épül fel egy működő folytonossági terv?
Egy működő terv strukturált folyamat eredménye, nem egyetlen dokumentum megírása. A gyakorlatban a következő lépések vezetnek oda, hogy a folytonosság ne véletlenen múljon:
- Hatókör és vezetői elköteleződés. Mely szervezeti egységekre, folyamatokra terjed ki a program, és ki a felelős szponzor.
- BIA elvégzése. A kritikus folyamatok, függőségek és tolerálható kiesések azonosítása.
- Kockázatértékelés. Milyen fenyegetések (kibertámadás, kiesés, emberi hiba, beszállítói leállás) veszélyeztetik a folyamatokat.
- Folytonossági stratégia kiválasztása. Az RTO/RPO célokhoz illesztett megoldások (lásd lentebb).
- A BCP és a DRP kidolgozása. Szerepek, eszkaláció, kommunikáció, technikai helyreállítási futtatókönyvek.
- Tesztelés és felülvizsgálat. A terv kipróbálása és folyamatos karbantartása.
Milyen folytonossági stratégiák léteznek?
A stratégia mindig a BIA-ból levezetett célokhoz igazodik, nem fordítva. A leggyakoribb megközelítések a következők.
- Redundancia és magas rendelkezésre állás: párhuzamos rendszerek, automatikus átállás (failover) a legszigorúbb RTO-jú folyamatokhoz.
- Mentés és visszaállítás: rendszeres, tesztelt mentések, ahol az RPO-t a mentési gyakoriság határozza meg.
- Alternatív helyszín vagy felhőalapú átállás arra az esetre, ha az elsődleges telephely vagy adatközpont kiesik.
- Kézi áthidaló folyamatok: ideiglenes, papíralapú vagy manuális munkamenetek, amíg a rendszerek visszaállnak.
- Beszállítói és ellátási lánc tartalékok: alternatív szállítók, szerződéses SLA-k a kritikus szolgáltatásokra.
Miért kell tesztelni a tervet?
Mert egy nem tesztelt terv csak feltételezés: az igazi képesség az, amit valós nyomás alatt is végre tudnak hajtani. A leírt lépések tele lehetnek rejtett hibákkal: elavult kontaktlista, hiányzó hozzáférési jog, soha vissza nem állított mentés, olyan függőség, amelyről senki nem tudott. Ezek kizárólag tesztelés közben derülnek ki, nem éles incidens alatt, amikor a tét a legnagyobb. A tesztelésnek több, egymást kiegészítő szintje van.
- Asztali gyakorlat (tabletop): a kulcsszereplők átbeszélnek egy forgatókönyvet, vagyis ki mit tenne, milyen sorrendben, kit értesítenének. Olcsó, gyors, és kiválóan feltárja a szerep- és kommunikációs réseket.
- Technikai teszt (helyreállítási teszt): a mentések tényleges visszaállítása, a failover kipróbálása, az RTO/RPO mérése valós körülmények között.
- Teljes szimuláció: egy nagyobb forgatókönyv végigjátszása, lehetőleg a termelési környezettől elszigetelten, a teljes folyamat élesben közeli ellenőrzésére.
Minden teszt után rögzíteni kell a tapasztalatokat, és a tervet ennek megfelelően frissíteni. A tesztelés nem egyszeri esemény, hanem visszatérő ciklus: évente legalább egyszer, vagy minden jelentős változás után érdemes elvégezni.
Hogyan kapcsolódik mindez az ISO 22301-hez és a NIS2-höz?
Az ISO 22301 a folytonosság menedzsmentrendszerét adja keretbe, a NIS2 pedig jogi kötelezettséggé teszi. A kettő ugyanazt a tesztelt képességet várja el, csak más oldalról. Az ISO 22301 a BCMS (Business Continuity Management System, üzletmenet- folytonossági irányítási rendszer) nemzetközi szabványa: a BIA-tól a stratégián és a terveken át a rendszeres tesztelésig és a folyamatos fejlesztésig egy zárt PDCA-ciklusba szervezi a folytonosságot. Aki ezt a szabványt követi, lényegében a fent leírt elemeket építi tanúsítható rendszerré. A BCMS jól illeszkedik az információbiztonsági irányítási rendszerhez is, sokszor az ISO/IEC 27001 mellé épül ki.
A NIS2 ezt a képességet a kritikus és kiemelten fontos ágazatokban jogi kötelezettséggé emeli: az üzletmenet-folytonosság, a mentési rend, a krízismenedzsment és a helyreállítási képesség kifejezetten nevesített elvárás, amelyet bizonyíthatóan kell teljesíteni. Ráadásul a NIS2 szigorú incidensbejelentési határidőket szab. Ezek a 24 óra korai figyelmeztetés, a 72 óra részletes bejelentés és az 1 hónap záró jelentés, amelyek mögött csak egy begyakorolt, tesztelt folytonossági folyamat ad valós fedezetet. A mulasztás tétje sem elhanyagolható: a bírság felső határa elérheti a 10 millió eurót vagy az éves árbevétel 2%-át (a kettő közül a magasabbat). A részletekről a NIS2 felkészítés oldalon olvashat bővebben.
Hogyan segít a zemITis?
A Zemitis Advisory Kft. budapesti információbiztonsági tanácsadóként a BIA elvégzésétől az RTO/RPO célok meghatározásán át a BCP/DRP kidolgozásáig és a tesztgyakorlatok levezetéséig végigviszi a folytonossági programot, mégpedig CISA, CISM és ISO 27001 Lead Auditor minősítésű szakértőkkel, négy-szem-elv alapú minőségbiztosítással. Akár önálló ISO 22301-felkészülésről, akár a NIS2 felkészítés részeként megvalósuló folytonossági képességről van szó, díjmentes konzultáción átbeszéljük a következő lépéseket. Ha pedig folyamatos szakmai támogatásra van szükség, az IBF szolgáltatás keretében a tervek karbantartását és rendszeres tesztelését is átvállaljuk.