• Technika
  • Elektrické zařízení
  • Materiálový průmysl
  • Digitální život
  • Zásady ochrany osobních údajů
  • Ó jméno
Umístění: Domov / Technika / Plánování obnovy po havárii cloudové éry: Nastavení strategie a vývoj plánů

Plánování obnovy po havárii cloudové éry: Nastavení strategie a vývoj plánů

techserving |
801

Jak je uvedeno v prvním článku této série, strategie a postupy obnovy po havárii IT (DR) pomáhají organizacím chránit jejich investice do systémů a infrastruktur IT.

Základním posláním DR je vrátit IT operace na přijatelnou úroveň výkonu co nejrychleji po rušivé události.

Po dokončení posouzení rizik (RA) a analýzy dopadu na podnikání (BIA) musíme prozkoumat kritické IT služby potřebné k podpoře kritických obchodních aktivit organizace.

V tomto článku se podíváme na to, jak nastavit strategii obnovy po havárii a vyvinout podrobné plány DR.

Zabudujte RPO a RTO do strategie DR

Než se podrobně podíváme na strategii a plánování DR, musíme zvážit dvě životně důležité metriky, konkrétně cíl doby obnovy (RTO) a cíl bodu obnovy (RPO).

Podle ISO/IEC 27031:2011, globálního standardu pro obnovu po havárii IT (ve standardu označovaném jako informační a komunikační technologie nebo ICT), je RTO „časové období, během kterého jsou minimální úrovně služeb a /nebo produkty a podpůrné systémy, aplikace nebo funkce musí být obnoveny poté, co došlo k přerušení."

Mezitím je RPO „časový bod, do kterého musí být data obnovena poté, co došlo k přerušení“. Obě tyto metriky jsou potřebné k definování strategií DR.

RPO/RTO a cloud

Všimněte si, že tyto dvě metriky jsou ovlivněny používáním cloudových služeb a úvahami o kybernetické bezpečnosti.

Například RTO pro datové centrum na místě lze snáze vypočítat, protože všechny operace jsou v rámci vlastní lokality organizace.

Naopak, když jsou IT operace přesunuty na cloudové služby, RTO musí poskytovat dodavatel cloudu, který může, ale nemusí být schopen nabídnout přijatelnou hodnotu. Totéž platí, když jsou data umístěna v cloudové službě.

Systémy pro ukládání dat na místě usnadňují podporu hodnot RPO, zatímco externí poskytovatelé cloudového úložiště nemusí být schopni nabídnout spolehlivé RPO. Oba tyto obavy velmi doporučují uzavřít solidní dohodu o úrovni služeb (SLA), protože stanoví dohodnuté úrovně výkonu, které musí třetí strana podporovat.

Strategie a podrobné plány v procesu plánování DR

Obrázek 1 znázorňuje fáze životního cyklu obnovy IT po havárii a je převzat z ISO 27031:2011. Obrázek ukazuje, že kromě rozvoje strategie je třeba zvážit další aktivity, než bude možné vypracovat plány DR.

Například politika obnovy po havárii IT je nezbytnou součástí celkového procesu DR. Jedná se zejména o důležitou položku, kterou je třeba při auditech prověřovat, a proto je její rozvoj nezbytný.

Analýza mezer, kterou lze v případě potřeby provést po posouzení rizik a analýze dopadu na podnikání, pomáhá určit oblasti pro zlepšení, které mohou zlepšit celkový proces plánování obnovy po havárii.

Kritéria technologické výkonnosti lze identifikovat z BIA, RA a analýz mezer a budou zahrnuta do plánů DR. Tyto činnosti mohou také identifikovat zdroje potřebné k dosažení požadované úrovně výkonu. BIA a RA do nich musí také zahrnout lidské zdroje, a to nejen během rušivé události, ale také během běžného provozu.

Definice strategie

Jakmile budou vytvořeny a schváleny kritické systémy a funkce a RTO a RPO, dalším krokem je definovat strategie pro reakci na rušivé incidenty, když k nim dojde. .

ISO 27031 uvádí: „Strategie by měly definovat přístupy k implementaci požadované odolnosti tak, aby byly zavedeny zásady prevence, detekce, reakce, obnovy a obnovy.“

Strategie definují, „co“ je třeba udělat při reakci na incident, zatímco plány popisují, „jak“ bude reakce a obnova provedena.

Jakmile byly identifikovány kritické systémy, data, sítě, prvky kybernetické bezpečnosti a firmy poskytující cloudové služby, použijte příklad v tabulce 1 jako výchozí bod, který vám pomůže formulovat strategie potřebné k jejich ochraně.

Faktory, které je třeba vzít v úvahu při vytváření takové tabulky, mohou zahrnovat rozpočty; názory vedení na rizika; otázky kybernetické bezpečnosti; dostupnost zdrojů, zejména cloudových služeb; náklady versus přínosy; lidská omezení; technologická omezení; a regulační požadavky.

Klíčové faktory při definování strategie DR

Níže jsou důležité otázky při vývoji strategií DR, zejména při zvažování použití cloudových služeb.

Ohledy na lidi

Mezi klíčové problémy patří dostupnost zaměstnanců a/nebo dodavatelů, potřeby školení zaměstnanců a dodavatelů, duplikace kritických dovedností, aby mohla existovat primární a alespoň jedna záloha, dostupná dokumentace, kterou mají zaměstnanci používat, a následná zajistit, aby si zaměstnanci a dodavatel uchovali znalosti.

Využití cloudových služeb přináší další aspekty, jako je bezpečnost dat a systémů, kvalifikace zaměstnanců poskytovatelů cloudu, možnost, že by nepoctiví zaměstnanci cloudu poškodili nebo ukradli zdroje zákazníků, ochota zástupců poskytovatelů cloudu pravdivě odpovídat na otázky a schopnost pracovníků cloud poskytovatele zvládnout požadavky zákazníků.

Fyzické vybavení

Zde musíme zvážit dostupnost alternativních pracovních oblastí na stejném místě, na jiném místě společnosti, na místě poskytnutém třetí stranou, v domovech zaměstnanců a na přenosném pracovním zařízení (např. do pracovního prostoru).

Je také důležité vzít v úvahu zabezpečení webu, postupy pro přístup zaměstnanců, identifikační karty a umístění alternativního prostoru vzhledem k primární kanceláři. Nemusí být možné fyzicky navštívit zařízení poskytovatelů cloudu a zákaznické systémy a data mohou být uložena ve více datových centrech, takže uživatelé musí být připraveni důvěřovat poskytovatelům cloudu, že ochrání jejich aktiva v bezpečných a ekologicky bezpečných datových centrech.

Technologické aspekty

To zahrnuje věci, jako je přístup k prostoru zařízení správně nakonfigurovanému pro systémy (například zdvojené podlahy), vhodné vytápění, ventilace a klimatizace (HVAC), dostatečný primární elektrický výkon, vhodná hlasová a datová infrastruktura, vzdálenost alternativní technologie oblast od primárního pracoviště, zajištění personálu na alternativním technologickém místě, dostupnost technologií pro přepnutí při selhání (do záložního systému) a failback (návrat do normálního provozu) pro usnadnění obnovy, potřeba podporovat starší systémy a schopnosti fyzické a informační bezpečnosti na alternativní web.

Při používání poskytovatele cloudových služeb je třeba pečlivě řešit každý z těchto problémů. Pokud je to možné, je vhodné je zahrnout do smluv o úrovni služeb (SLA).

Úvahy o datech

Zde musíme zahrnout včasné zálohování kritických dat do zabezpečené oblasti úložiště v souladu s požadavky RTO/RPO, metodami ukládání dat (například disk, páska, optické), požadavky na připojení a šířku pásma, abychom zajistili všechna kritická data lze zálohovat v souladu s časovými osami RTO/RPO, možnostmi ochrany dat na alternativním úložišti a dostupností technické podpory od kvalifikovaných poskytovatelů služeb třetích stran.

Tyto úvahy jsou zásadní při používání poskytovatele cloudových služeb, zejména jeho zdrojů pro ukládání a přístup k zákaznickým systémům a datům, jak chrání perimetr svých sítí před kybernetickými útoky, jak plní požadavky zákazníků na RTO/RPO a jak testují své vlastní plány DR.

Aspekty dodavatele

Zde potřebujeme identifikovat a uzavřít smlouvu s primárními a alternativními dodavateli pro všechny kritické systémy a procesy, a dokonce i pro získávání lidí. Mezi klíčové oblasti, kde budou důležití alternativní dodavatelé, patří hardware (servery, racky), napájení (baterie, UPS, ochrana napájení), sítě (služby hlasových a datových sítí), opravy a výměny komponent a více dodavatelských firem (Fedex a UPS). .

Mnoho z těchto problémů lze zmírnit pomocí poskytovatele cloudových služeb, ale stále je rozumné udržovat zálohy důležitých dat a aplikací a mít zásoby důležitých systémových komponent.

Zásady a postupy

Klíčové kroky zde zahrnují definování zásad pro obnovu po havárii IT, jejich schválení vrcholovým vedením, definování postupů krok za krokem (například spuštění zálohování dat do bezpečných alternativních umístění), přemístění operací do alternativního prostoru , obnovení systémů a dat na alternativních místech a obnovení provozu buď na původním místě, nebo na novém místě. Při používání cloudových služeb nezapomeňte zohlednit cloudová hlediska do všech zásad DR a souvisejících procedurálních dokumentů.

Nakonec se ujistěte, že jste získali souhlas vedení pro plánované strategie, zásady a postupy. Buďte připraveni prokázat, že navrhované strategie jsou v souladu s obchodními cíli organizace a strategiemi kontinuity podnikání.

Převedení strategií do plánů DR

Dalším krokem po dokončení strategií DR je převést je do plánů a postupů obnovy po havárii. Abychom ukázali, jak toho lze dosáhnout, byla tabulka 1 revidována na tabulku 2, která následuje.

Zobrazuje kritické systémy a související hrozby, strategii reakce a (nové) kroky reakce, strategii obnovy a (nové) kroky akce obnovy. Provedení tohoto kroku pomáhá definovat akční kroky na vysoké úrovni, které jsou součástí plánu DR.

Pomocí Tabulky 2 rozšiřte podle potřeby kroky akcí na vysoké úrovni na podrobné postupy krok za krokem. Ujistěte se, že jsou propojeny ve správném pořadí.

Vývoj plánů DR

Plány obnovy po havárii poskytují proces krok za krokem pro reakci na rušivou událost.

Postupy by měly zajistit snadno použitelný a opakovatelný proces obnovy poškozených IT aktiv a jejich co nejrychlejšího návratu do normálního provozu. Je-li nutné přemístění personálu do horkého místa třetí strany nebo jiného alternativního prostoru, musí být pro tyto činnosti vypracovány postupy. Kroky pro použití cloudových zálohovacích zdrojů musí být vyvinuty v koordinaci s poskytovatelem cloudu, aby byly postupy prováděny ve správném pořadí.

Při vývoji plánů DR zvažte také revizi globálních norem ISO/IEC 24762 (Směrnice pro služby obnovy informačních a komunikačních technologií po havárii) a ISO/IEC 27035 (Aktivity reakce na incidenty).

Reakce na incidenty

Kromě použití dříve vyvinutých strategií by plány obnovy po havárii IT měly zahrnovat také proces reakce na incidenty (ISO/IEC 27035) k řešení počátečních fází. incidentu a kroky, které je třeba podniknout.

Jako na obrázku 2 by akce reakce na incidenty měly předcházet akcím obnovy po havárii. Při použití cloudových služeb spolupracujte s poskytovatelem na začlenění jeho aktivit reakce na incidenty do plánu DR.

Poznámka: Havarijní management byl zahrnut do obrázku 2, protože představuje činnosti, které mohou být potřebné k řešení situací, kdy jsou zraněni lidé, nebo situací, jako jsou požáry, které musí řešit místní hasičské sbory a další záchranáři.

Struktura plánu DR

Následující část podrobně popisuje rámec a komponenty pro plán DR na základě ISO 27031 a ISO 24762.

Nejlepší plány DR ve své třídě často začínají stránkou nebo dvěma, které shrnují klíčové kroky akce (například kde shromáždit zaměstnance, pokud jsou nuceni evakuovat budovu) a seznamy klíčových kontaktů (například poskytovatelé cloudu, alternativní pracovní oblasti) a jejich kontaktní informace pro usnadnění autorizace a spuštění plánu.

Úvod

Po úvodních stránkách pro nouzové situace mají plány DR úvod, který zahrnuje účel a rozsah plánu. Tato část by měla specifikovat, kdo plán schválil, kdo je oprávněn jej aktivovat, a obsahovat seznam odkazů na jakékoli další relevantní plány a dokumenty (například zásady).

Role a odpovědnosti

Další část by měla definovat role a odpovědnosti členů týmu DR, jejich kontaktní údaje, limity výdajů (například pokud je třeba zakoupit vybavení) a limity jejich pravomocí v případě katastrofy. Při používání cloudových služeb by měly být stejné parametry definovány pro poskytovatele cloudu.

Reakce na incident

Proces reakce na incident identifikuje náhlou přítomnost mimonormální situace (například upozorněnou různými alarmy na úrovni systému), rychle vyhodnotí situaci (a případné škody), aby bylo možné včas určit její závažnost, se pokusí zadržet incident a dostat jej pod kontrolu a upozorní vedení, poskytovatele cloudových služeb a další klíčové zainteresované strany.

Aktivace plánu

Na základě zjištění z činností reakce na incidenty je dalším krokem určení, zda by měly být spuštěny plány obnovy po havárii a které konkrétně by měly být použity. Tyto činnosti by měly být pečlivě koordinovány s poskytovateli cloudových služeb.

Pokud se mají vyvolat plány DR, lze aktivity reakce na incidenty omezit nebo ukončit v závislosti na incidentu, což umožní spuštění plánů DR. Použití poskytovatele cloudu může také pomoci omezit aktivity reakce na incidenty, protože poskytovatel cloudu by měl být aktivován na začátku procesu.

V této části jsou definována kritéria pro spuštění plánu, koordinace s poskytovatelem cloudu, jaká data jsou potřeba a kdo rozhoduje.

Do této části plánu by měly být zahrnuty shromažďovací prostory pro zaměstnance (primární a náhradníci), postupy pro upozornění a aktivaci členů týmu DR a poskytovatelů cloudu a postupy pro zrušení plánu, pokud vedení rozhodne, že odpověď na plán DR není. potřeboval.

Historie dokumentů

Poskytněte sekci se seznamem dat a revizí dokumentů plánu. Měl by obsahovat data revizí, co bylo revidováno a kdo revize schválil. Najděte tuto sekci v přední části plánu.

Postupy

Jakmile byl plán spuštěn a byli informováni i poskytovatelé cloudu, týmy DR a týmy poskytovatelů cloudu pokračují v činnostech odezvy a obnovy, jak je uvedeno v plánech. Čím podrobnější je plán, tím je pravděpodobnější, že dotčené IT aktivum bude obnoveno a vráceno do normálního provozu.

Je nezbytné, aby poskytovatel (poskytovatelé cloudu) znali své role během incidentu. Vylepšete plány DR o relevantní informace a postupy obnovy získané od poskytovatelů cloudu. Úzce koordinujte s poskytovateli cloudu při vývoji plánů DR, abyste zajistili, že mají zdokumentované nouzové postupy.

Přílohy

Umístěné na konci plánu mohou zahrnovat inventáře systémů, inventáře aplikací, inventáře síťových aktiv, smlouvy a dohody o úrovni služeb, kontaktní údaje poskytovatele cloudu (a dalšího dodavatele) a jakoukoli další dokumentaci, která usnadní obnovu.

Další aktivity

Jakmile budou plány DR dokončeny, jsou připraveny k provádění. Uplatňování plánů DR při používání poskytovatele cloudových služeb je obzvláště důležité, protože poskytovatel cloudu bude mít odpovědnost za obnovu kritických systémů a dat. Tento proces určí, zda lze systémy a data efektivně obnovit a vrátit do provozu podle plánu.

Paralelně s těmito aktivitami jsou tři další: vytváření povědomí zaměstnanců, školení zaměstnanců a správa záznamů. Ty jsou zásadní v tom, že zajišťují, aby si zaměstnanci byli plně vědomi plánů DR a jejich odpovědnosti v případě katastrofy, a členové týmu DR a zástupci cloudových služeb byli proškoleni ve svých rolích a povinnostech, jak je definováno v plánech.

A protože plánování DR generuje značné množství dokumentace, měly by být zahájeny také činnosti správy záznamů a řízení změn. To je zvláště důležité při používání poskytovatele cloudových služeb a zajistí to, že si zákazníci budou plně vědomi toho, co by měl poskytovatel dělat.

Získejte co nejvíce dokumentace poskytovatele, abyste byli v souladu s jeho aktivitami. Během plánování DR nezapomeňte koordinovat činnost se správou záznamů společnosti a řízením změn.

Shrnutí

Tento článek demonstroval důležitost rozvoje strategií DR, zejména při používání poskytovatelů cloudových služeb, jak je převést do plánů DR a aktivit reakce na incidenty a jak definovat součásti plánu DR a obsah, který každý obsahuje. Při vývoji plánů obnovy po havárii jsou nezbytné plně definované strategie DR, které jsou založeny na mnoha faktorech, zejména při spolupráci s poskytovateli cloudu.

Přečtěte si další informace o plánování obnovy po havárii