Egy kibertámadás, áramkimaradás, hardverhiba vagy akár egy emberi mulasztás percek alatt képes megbénítani egy vállalat működését. A kérdés nem az, hogy bekövetkezik-e valamilyen incidens – hanem az, hogy mikor. Azok a szervezetek élik túl ezeket az eseményeket minimális veszteséggel, amelyek időben gondolkodtak előre, és felépítettek egy megbízható felhő alapú katasztrófa-elhárítási tervet.

Ez az útmutató lépésről lépésre végigvezet a Business Continuity Plan (BCP) és a Disaster Recovery (DR) stratégia kialakításán felhő környezetben, különös tekintettel az RTO és RPO célok meghatározására.

Mi a különbség a BCP és a DR között?

Sokan összekeverik a két fogalmat, holott eltérő, de egymást kiegészítő területekről van szó.

A Business Continuity Plan (BCP) az üzletmenet-folytonossági terv: azt határozza meg, hogyan tudja a szervezet fenntartani az alapvető működést egy súlyos incidens alatt és után. Ez magában foglalja az embereket, a folyamatokat, a kommunikációt és az üzleti prioritásokat is.

A Disaster Recovery (DR) ezzel szemben az IT-infrastruktúra helyreállítására fókuszál: hogyan állítsuk vissza a rendszereket, adatokat és alkalmazásokat a lehető legrövidebb idő alatt. A DR a BCP egyik technikai pillére.

A kettő egymás nélkül nem teljes. Hiába van kiváló IT-helyreállítási tervünk, ha nem tudjuk, ki dönt válság közben, ki értesíti az ügyfeleket, vagy melyik üzleti folyamatot kell elsőként visszaállítani.

Az RTO és RPO: a két alapfogalom, amelyet mindenki ismer, de kevesen definiálnak pontosan

A felhő alapú DR stratégia gerincét két mérőszám alkotja:

RTO – Recovery Time Objective (helyreállítási idő célérték): Az a maximálisan megengedhető idő, amennyi alatt a rendszernek újra működőképesnek kell lennie egy leállás után. Például: „a webáruházunk legfeljebb 4 óráig lehet elérhetetlenül”.

RPO – Recovery Point Objective (helyreállítási pont célérték): Az a maximálisan elfogadható adatveszteség, amelyet az utolsó sikeres mentéstől mérünk. Például: „legfeljebb 1 órányi tranzakciós adat veszhet el”.

Az RTO és RPO értékei rendszerenként eltérőek. Egy éles e-commerce platform esetén mindkettő igen alacsony (akár percekben mért), míg egy belső riportrendszernél elfogadható lehet egy 24 órás RTO is. A helyes célértékek meghatározása üzleti kockázatelemzésen alapul, nem technikai becsléseken.

A felhő alapú katasztrófa-elhárítási terv kialakításának lépései

1. lépés: üzleti hatáselemzés (BIA – Business Impact Analysis)

Mielőtt bármilyen technikai megoldásba fognánk, fel kell térképeznünk, hogy az egyes rendszerek és folyamatok leállása milyen üzleti következményekkel jár.

Kérdések, amelyeket meg kell válaszolni:

Melyik rendszer leállása jár a legnagyobb bevételkieséssel?
Melyek a jogszabályi vagy szerződéses kötelezettségek (pl. SLA)?
Milyen kölcsönös függőségek vannak az alkalmazások között?
Mi a tényleges óránkénti kiesési költség (direkt és indirekt)?

A BIA eredménye egy prioritási lista lesz, amely megmutatja, melyek a kritikus rendszerek, és ezekhez kell hozzárendelnünk az RTO/RPO célértékeket.

2. lépés: kockázatértékelés és fenyegetéstérkép

A felhő alapú infrastruktúra csökkenti, de nem szünteti meg a kockázatokat. Az értékelés során azonosítani kell:

Természeti katasztrófák (adatközpont régióját érintő esemény)
Kibertámadások (ransomware, DDoS, adatszivárgás)
Emberi hibák (téves konfiguráció, véletlen törlés)
Felhőszolgáltató oldaláról érkező hibák (zónaleállás, API hibák)
Ellátási lánc incidensek (harmadik féltől függő szolgáltatások kiesése)

Minden egyes kockázathoz becsüljük meg a bekövetkezési valószínűséget és az üzleti hatást. Ez lesz a kockázatmátrix alapja.

3. lépés: a DR stratégia architektúrájának meghatározása

A felhőben négy alapvető DR architektúra-modell létezik, amelyek eltérő költség-kockázat arányokkal rendelkeznek:

Backup & Restore (biztonsági mentés és visszaállítás): A legolcsóbb megoldás, de a leghosszabb RTO-val. Az adatokat rendszeresen mentjük felhőbe (pl. AWS S3, Azure Blob Storage), és incidens esetén ezekből állítjuk vissza a rendszert. Megfelelő alacsony prioritású rendszereknél, ahol az RTO akár 24+ óra is elfogadható.

Pilot Light: Az alapinfrastruktúra minimálisan fut a másodlagos régióban (pl. adatbázis-replikáció aktív), de az alkalmazásréteg el van állítva. Incidens esetén az alkalmazásokat gyorsan fel lehet húzni. RTO: általában 1-4 óra.

Warm Standby: Egy kisebb kapacitású, de teljesen működőképes másodlagos környezet fut folyamatosan. Incidens esetén csak skálázni kell. RTO: percekben mérhető.

Hot Standby / Active-Active: Mindkét környezet teljes terhelésen fut párhuzamosan, általában terheléselosztóval. A legdrágább, de szinte nulla RTO-t és RPO-t biztosít. Banki rendszerek, kritikus e-commerce platformok esetén indokolt.

A stratégia megválasztásakor mindig a BIA-ban meghatározott RTO/RPO célértékekből kell kiindulni – nem fordítva.

4. lépés: az adatvédelmi és mentési stratégia kialakítása

A felhő alapú DR tervnek explicit módon meg kell határoznia a mentési politikát:

Mentési frekvencia: folyamatos replikáció, óránkénti snapshot, napi teljes mentés – a rendszer kritikusságától függően
Megőrzési idő: mennyi ideig tároljuk a korábbi mentési pontokat (30 nap, 90 nap, 1 év)?
Titkosítás: az összes mentett adat nyugalmi és átviteli állapotban titkosítva legyen
Georedundancia: a mentések legalább két különböző fizikai helyszínen (régióban) legyenek tárolva
Visszaállíthatóság tesztelése: a mentés csak akkor ér valamit, ha visszaállítható is

A 3-2-1 mentési szabály felhős interpretációja: legalább 3 példány az adatból, legalább 2 különböző tárolási rétegen (pl. elsődleges felhő + offsite backup), legalább 1 példány legyen georedundánsan elkülönítve.

5. lépés: a helyreállítási folyamatok dokumentálása

A DR terv csak akkor használható, ha részletesen, lépésről lépésre dokumentálva van – és ezt nem az incidens kellős közepén kell megírni.

A dokumentációnak tartalmaznia kell:

Incidens észlelési és riasztási folyamat (ki értesít kit, milyen csatornán)
Döntési fa: mikor aktiválják a DR tervet, ki a jogosult döntéshozó
Technikai helyreállítási runbookok rendszerenként (lépésről lépésre)
Kommunikációs terv: belső csapatok, ügyfelek, partnerek, sajtó értesítése
Eszkalációs mátrix: ki veszi át az irányítást, ha az elsődleges felelős nem elérhető
Visszakapcsolási terv: hogyan állunk vissza az elsődleges infrastruktúrára az incidens után

6. lépés: infrastruktúra-automatizálás és IaC

A felhő egyik legnagyobb előnye a DR szempontjából az infrastruktúra kódként való kezelése (Infrastructure as Code – IaC). Terraform, AWS CloudFormation vagy Azure ARM sablonok segítségével az egész infrastruktúra percek alatt újraépíthető egy másik régióban.

Az automatizálás előnyei:

Emberi hiba nélküli, reprodukálható helyreállítás
Drámaian rövidebb RTO
Verziókövethető infrastruktúra-konfiguráció
A DR tesztelése szinte semmibe kerül, mert az infrastruktúra eldobható

Érdemes CI/CD pipeline-ba integrálni a DR szkripteket is, hogy az infrastruktúra-változások automatikusan szinkronban maradjanak a helyreállítási tervvel.

7. lépés: tesztelés és rendszeres felülvizsgálat

A DR terv, amelyet soha nem teszteltek, nem ér semmit. A tesztelés típusai:

Asztali gyakorlat (tabletop exercise): A csapat átbeszéli a forgatókönyvet elméleti szinten. Gyors és olcsó, de nem mutatja meg a valódi technikai problémákat.

Komponensteszt: Egyetlen rendszer vagy backup visszaállítása izoláltan. Rendszeresen elvégzendő.

Teljes DR teszt (failover teszt): Az egész helyreállítási folyamat szimulálása éles vagy teszt környezetben. Évente legalább egyszer ajánlott.

Chaos Engineering: Véletlenszerű, kontrollált hibák injektálása az éles rendszerbe (pl. Netflix Chaos Monkey megközelítés) annak vizsgálatára, hogyan viselkedik a rendszer valódi stressz alatt.

Minden teszt után frissíteni kell a dokumentációt és a runbookokat.

Felhőszolgáltatók natív DR eszközei

A nagyobb felhőszolgáltatók saját DR megoldásokat kínálnak:

AWS: AWS Elastic Disaster Recovery (DRS), Cross-Region Replication, Route 53 health check alapú failover
Microsoft Azure: Azure Site Recovery, Geo-redundant storage (GRS), Traffic Manager
Google Cloud: Cloud Storage multi-region buckets, Spanner globális replikáció, Cloud DNS failover

Ezek az eszközök beépíthetők az automatizált DR folyamatokba, és csökkentik a manuális beavatkozás szükségességét.

Szabályozói és megfelelőségi szempontok

Számos iparágban a DR terv nem csupán ajánlás, hanem jogszabályi kötelezettség. A GDPR például elvárja az adatok helyreállíthatóságát és a megfelelő biztonsági intézkedések dokumentálását. A PCI DSS szabvány pénzügyi adatok kezelőit kötelezi részletes BCP és DR dokumentációra. Az ISO 22301 az üzletmenet-folytonossági menedzsment nemzetközi szabványa, amelynek tanúsítása egyre több nagyvállalati tender elvárása.

Összefoglalás

Egy jól felépített felhő alapú katasztrófa-elhárítási terv nem luxus, hanem alapvető üzleti szükséglet. A BCP és DR stratégia kialakítása hat kulcslépésből áll: üzleti hatáselemzés, kockázatértékelés, architektúra meghatározása, mentési stratégia, részletes dokumentáció és rendszeres tesztelés. Az RTO és RPO célértékek üzleti döntések, nem technikai paraméterek – ezekből kell visszafelé meghatározni a megfelelő technológiai megoldást.

Ha segítségre van szükséged a felhő infrastruktúrád DR stratégiájának kialakításában, csapatunk szívesen segít – ismerkedj meg felhő üzemeltetési szolgáltatásainkkal, vagy nézd meg, milyen felhő migrációs tapasztalatokkal rendelkezünk.