Business Continuity (BC) plán vs. Disaster Recovery (DR) plán

Co to je Business Continuity (BC) plán a Disaster Recovery (DR) plán? Jaký je mezi nimi rozdíl a co by měli obsahovat?

Business Continuity (BC) plán i Disaster Recovery (DR) plán je důležitý pro zvládání mimořádných událostí (např. přírodní katastrofa, kybernetický útok, výpadek elektřiny). Liší se svými cílem, zaměřením, rozsahem a přístupem.

Není možno mít BC ani DR plán připraven pro konkrétní případ, proto je pří jejich vytváření důležité se zaměřit na obecné postupy a zásady místo konkrétních scénářů. Plány musí být:

dostatečně široké, aby pokryly různé situace, a
dostatečně strukturované, aby poskytly jasné vodítko, jak jednat.

Místo řešení konkrétních situací, je třeba definovat, co je pro společnost klíčové, které činnosti/systémy, a zaměřit se na zajištění jejich nepřetržitého fungování. Klíčem k vytvoření dobrého BC a DR plánu je strukturovaný a flexibilní přístup, který umožní jejich adaptaci na různé scénáře. Pro jejich vytvoření je důležité si vydefinovat:

klíčové oblasti, tj. identifikovat základní/klíčové funkce společnosti (IT systémy, fyzická infrastruktura, personál, komunikace)
obecné typy možných výpadků a rozdělit je do skupin, např. výpadky IT, nedostupnost budovy, narušení dodavatelského řetězce, nedostatek pracovníků.

Pro každou klíčovou oblast a možný typ výpadku je pak důležité připravit obecný plán. K tvorbě plánu je nutno přistupovat hierarchicky od prioritních funkcí/činností k těm méně důležitým. U každé funkce nebo činnosti musí být definována rychlost potřeby jejího obnovení (RTO) a kolik dat/informací je akceptovatelné ztratit (RPO).

Pro řešení konkrétního situace je tedy nutné mít vytvořené:

obecné postupy pro situace, kdy nelze přesně předvídat nedostupnost – např. postup, jak analyzovat situaci v reálném čase a rozhodnout o dalším kroku.
obecné moduly - např. modul pro obnovení IT infrastruktury, modul pro krizovou komunikaci, modul pro záložní pracoviště atd., které je možno pro ten konkrétní situaci kombinovat, a
obecné šablony, kontrolní seznamy a modelové scénáře pro různé typy událostí -např. základní plán komunikace při výpadku, plán pro obnovu serveru s proměnlivými faktory, které se zaměří na odlišné typy výpadků - např. krátkodobé a dlouhodobé.

Zaměstnanci musí být místo specifických scénářů seznámeni s obecnými kroky, které se použijí při jakékoli krizi (identifikace problému, hodnocení dopadu, aktivace plánu), a zásadami i přístupy, jak reagovat na krizi.

Vhodné je testování BC a DR plánů s obecným scénářem, který zahrnuje různé varianty - např. výpadek internetu, nepřístupnost budovy.

BC plán

je širší a komplexnější, zajišťuje celkové přežití společnosti a pokračování jejích obchodních činností. Jeho cílem je zajistit, aby společnost mohla pokračovat ve své činnosti s co nejmenším narušením i v případě rozsáhlé katastrofy. Zahrnuje všechny její oblasti, nejen IT. Řeší také kritické obchodní procesy, personální otázky, komunikaci se zákazníky a partnery, dostupnost budov a zařízení. Pokrývá jak okamžitou reakci, tak dlouhodobé udržení činnosti. Je více zaměřen na celkový provoz a schopnost společnosti přežít krizi.
zahrnuje veškeré procesy nutné k tomu, aby organizace mohla pokračovat ve své činnosti. Obsahuje:
- Úvod a účel plánu: Popis cílů BC plánu a jeho význam pro organizaci.
- Analýzu dopadu na podnikání (BIA): Identifikace a analýza důsledků přerušení činností, definování klíčových procesů a akceptovatelného výpadku (RTO, RPO).
- Strategie pro kontinuitu podnikání: Plánování alternativních řešení pro udržení klíčových procesů (např. přesun pracovníků na jinou pobočku, práce z domova).
- Kritickou infrastrukturu a zdroje: Zajištění dostupnosti budov, zařízení a zásob pro podporu provozu.
- Plán komunikace: Strategie pro interní a externí komunikaci se zaměstnanci, zákazníky, dodavateli a dalšími zainteresovanými stranami během krize.
- Role a odpovědnosti: Přehled týmů a jednotlivců s jasně definovanými úkoly pro zvládání krizí.
- Postupy pro reakci na krizové situace: Podrobný návod pro první reakce, krizové scénáře a úkoly k zajištění bezpečnosti a udržení provozu.
- Kontingenční plánování: Alternativní způsoby a postupy pro pokračování činností (např. dohody s alternativními dodavateli).
- Testování a školení: Program pro pravidelné školení zaměstnanců a testování plánu, aby se ověřila jeho efektivnost.
- Dokumentaci a revize: Aktualizace a přezkoumání plánu po testech, změnách v organizaci nebo po mimořádné události.

DR plán

je součástí BC plánu a zaměřuje se na obnovu IT systémů a minimalizaci technologických ztrát. Jeho primárním cílem je tedy obnovit a zachovat funkčnost IT systémů a dat po mimořádné události**.** Zaměřuje se hlavně na technologickou infrastrukturu a IT procesy. Obsahuje konkrétní kroky pro obnovení hardwaru, softwaru, dat a komunikačních systémů. Obvykle pokrývá krátkodobé reakce, aby se co nejrychleji obnovil provoz klíčových systémů a minimalizovala ztráta dat.
DR plán je zaměřen na obnovu IT systémů a infrastruktury po mimořádné události. Obsahuje tyto hlavní částí:
- Úvod a účel plánu: Vymezení účelu plánu, jeho rozsahu a cílů.
- Zmapování kritických IT systémů: Identifikace systémů, aplikací a dat, které jsou nezbytné pro podnikání.
- Analýza rizik: Seznam hrozeb (přírodní katastrofy, kyberútoky, výpadky proudu) a jejich možný dopad.
- Plán zálohování a obnova dat: Přesný popis způsobu zálohování dat, frekvence záloh a postupy pro obnovu dat.
- Plán pro obnovení infrastruktury: Kroky pro obnovení serverů, sítě, databází a dalších kritických součástí.
- Dohody o úrovni služeb (SLA): Zajištění spolupráce s poskytovateli cloudových služeb nebo datových center.
- Zodpovědné osoby a kontakty: Jasně stanovené role a odpovědnosti jednotlivých členů týmu, kontaktní údaje na klíčové pracovníky a partnery.
- Postupy testování plánu: Harmonogram a popis testovacích scénářů pro ověření účinnosti DR plánu.
- Postupy pro návrat k normálnímu stavu: Procesy pro přechod z obnovy na běžný provoz.

Testování BCP/DR

Možnosti:

Table-top cvičení (scénářový přístup, krizové řízení)
Funkční test přesměrování lidí, komunikace
Technické testy obnovy IT systémů ze záloh

Proč testovat

Bez testování nás nečekaná maličkost může hodně zdržet nebo třeba i znemožnit obnovu i při sebelepšímu plánu. Bez pravidelných testů nemáte zaručeno, že váš plán obstojí tváří v tvář skutečné krizi.
Je to stejné jako s autem, pokud ho nikdy nezkontrolujete, může vás nečekaná závada nechat na holičkách uprostřed silnice. Stejně tak i s vašimi plán
Každý test přináší cenné informace o tom, co funguje a co ne.
Pravidelně aktualizované plány reflektují změny v infrastruktuře.
Pravidelné testování vám pomůže identifikovat slabá místa a nedostatky ve vašem plánu.
Table top cvičení (simulace scénáře), kde se v týmu diskutuje o jednotlivých krocích potřebných k obnovení systémů bez skutečného provedení obnovy, e to ideální způsob, jak zapojit všechny zainteresované strany bez velkých nákladů.
Pro případ výpadku se hodí mít předem rozdělené úkoly a přidělit odpovědnost za konkrétní oblasti konkrétnímu zaměstnanci a je vhodné mít to připravené a vyzkoušené. Každý zaměstnanec by měl vědět co má dělat. Koordinace a dobrá komunikace se zákazníkem je plně v režii firmy. Informace mus íproudit napříč společností kontinuálně a především konzistentně.
Zákazník musí vědět, že máte vše pod kontrolou. Informujte ho srozumitelně o tom, co se děje a pokud ještě neznáte podrobnosti, hlaste se pravidelně s updaty o situaci.
Co když budeme potřebovat něco, co je v záloze a bez toho to nejde obnovit.

Ajťáci si myslí, že testování je zbytečný opruz, vždyť máme DR plány, tak jsme v pohodě. Ale bez ověření funkčnosti je to jen iluze!

Nečastější omyly ajťáků

DR plány na papíře vypadají perfektně, ale dokud se neotestují není jisté, že budou fungovat.

Dokumentace není zárukou, že to v reálu bude fungovat. Ne každý jí čte a zná, při otestování se s ní může více seznámit.

Testování odhalí slabiny. Bez testování jsou DR plány jen teorie, teprve praxe ukáže jak jsou dobré a je lepší na to přijít při testu než v praxi. Můžou tam být mezery, které odhalí jen test nebo skutečný BI.

Rychlá a efektivní reakce na BI je klíčová. Minimalizuje dopady a zkracuje dobu nefunkčnosti = snížení finančních ztrát.

Pravidelný test zlepší připravenost lidí a pomůže jim reagovat klidně a efektivně pod tlakem, který na ně bude až to bude reálný.

Když se nepovede při testu, tak je to možnost zlepšit a nic se neděje, ale když se totéž stane při reálném prů…, tak budeme za ……

Při testu se může přijít na reálné chyby v konfiguraci, zapomenuté hrozby a zranitelnosti (penetrační testování) a na mezery v komunikaci a rozhodovacích procesech (testování Dr plánů a vymyšlených BI).

Nemáme na to čas/peníze. Pokud není čas na otestování, ta ještě méně ho bude při reálném BI, ten může způsobit větší a delší výpadky než kdyby se to otestovalo. Otestování je vždy levnější než reálný BI. Nemůžeme něco automatizovat?

Testování nemusí narušit provoz, existují způsoby testování, které se omezení provozu nedotknou (simulace, tableto test,…).

Test není nikdy realistický, v praxi to bude jiné. Ale stále je lepší než žádné, lze dát dohromady různé typy/scénáře BI) fyzické poškození, chyba konfigurace, zavlečení malware, průnik hackera,….) a ty otestovat. Bez testu nejsme připravený na nic.

I když si myslíme, že máme vše dobře zabezpečený, že se nemůže BI stát, tak to nemůže být 100%. Útoky se dějí náhodně i cíleně a i velké firmy nebo státní organizace byly napadeny, tak proč bychom měli být výjimkou?