Plán kontinuity podnikania a obnovy po havárii (BCDR) je súbor techník a procesov, ktoré organizácie používajú na pomoc pri zotavení sa z havárie a obnovení bežných obchodných operácií. Procesy BCDR je ľahšie pochopiť, ak ich rozdelíme do dvoch častí:
Táto časť postupu sa zaoberá obchodnou stránkou veci. Postup sa týka vytvárania politík a postupov, ktoré zabezpečujú funkčnosť základných obchodných funkcií počas katastrofy a po nej. Zahŕňa to:
Obnova po havárii sa primárne zaoberá IT stránkou procesu. Tento proces definuje, ako sa organizácia alebo podnik zotaví z prírodnej alebo digitálnej katastrofy. Zahŕňa to:
Pri diskusii, tvorbe a testovaní vašich plánov BCDR by ste mali poznať niekoľko ďalších dôležitých pojmov. Patria sem:
Cieľový bod obnovy („RPO“) : Aká je požiadavka vo vašom pláne na obnovenie dát? Inými slovami, ak by dnes došlo k zlyhaniu systému, ako ďaleko do minulosti by ste museli ísť na obnovenie platných dát a je takéto množstvo stratených dát pre firmu prijateľné? Niektoré spoločnosti si stanovujú RPO na týždeň. To znamená, že ak by museli obnoviť dáta zo záloh, obnovili by dáta z týždeň starej zálohy so stratou transakčných dát a aktivít až z týždňa.
Cieľový čas obnovy („RTO“) : Váš RTO predstavuje, ako rýchlo by ste mali byť schopní realizovať svoj plán obnovy. Ak ste v tomto momente spustili BCDR a váš RTO je 24 hodín, potom by sa vaša plná prevádzka mala obnoviť na 100 % do 24 hodín od začiatku realizácie plánu BCDR.
Áno. Pokiaľ vaša firma nezvládne dlhší výpadok v trvaní týždňa alebo dlhšie, mali by ste mať plán BCDR vypracovaný vaším technologickým tímom alebo poskytovateľom spravovaných služieb. Okrem toho by ste mali tento plán otestovať.
V jednej nedávnej nočnej mory bol potrebný plán BCDR s RPO (obnoviteľným časom obnovenia) 24 hodín a RTO (čas obnovenia) 24 hodín. Problém bol v tom, že zálohy nebolo možné obnoviť dostatočne rýchlo z ich externého úložiska kvôli veľmi pomalému internetovému pripojeniu a veľkému objemu údajov, ktoré bolo potrebné preniesť na obnovu. Plán BCDR bol nakoniec upravený tak, aby sa lokálne zálohovanie údajov vykonávalo raz mesačne, aby to mohol byť bod obnovy, do ktorého by sa postupne obnovovali prírastkové zmeny z internetového zálohovacieho umiestnenia jeden týždeň, kým sa nedosiahne RPO. To ovplyvnilo RTO, ktoré sa muselo predĺžiť z 24 na 48 hodín, aby sa zohľadnili ďalšie kroky obnovy, ale bol to najekonomickejší prístup, ktorý si spoločnosť mohla dovoliť a akceptovať.
Objavte a zdieľajte najnovšie trendy, tipy a osvedčené postupy v oblasti kybernetickej bezpečnosti – spolu s novými hrozbami, na ktoré si treba dať pozor.
Autor: Katie Boquetti | Editorial: Craig Taylor Editorial od Craiga Taylora: Ešte predtým, ako Claude Code vytvoril...
Čítaj viac
Autor: Katie Boquetti | Editorial: Craig Taylor Editorial od Craiga Taylora: Už nejaký čas to tu vieme...
Čítaj viac
Autor: Katie Boquetti | Editoriál: Craig Taylor Editoriál od Craiga Taylora: CAPTCHA by mala overiť, či...
Čítaj viacZískajte bystrejší pohľad na ľudské riziká s pozitívnym prístupom, ktorý prekonáva tradičné phishingové testovanie.
