Když klíčový systém ve vaší firmě selže, nejtěžší částí je vědět, co obnovit jako první, kdo k němu má oprávnění přistupovat, která záloha je důvěryhodná a jak dlouho může vaše firma bez tohoto systému fungovat.
Právě v takových chvílích mnoho malých a středních podniků (SMB) zjistí rozdíl mezi tím, když mají zálohy, a skutečným plánem obnovy. Záloha sice může obsahovat potřebná data, ale neurčuje pořadí obnovy, nepřiděluje odpovědnost, neověřuje, zda lze systém obnovit, ani neřeší problém chybějících přihlašovacích údajů správce během výpadku.
Plán obnovy IT po havárii dává tomuto procesu strukturu ještě předtím, než dojde k narušení. Definuje, na kterých systémech nejvíce záleží, jak rychle je potřeba je obnovit, jakou ztrátu dat může firma tolerovat, jaké strategie prevence ztráty dat implementovat, kdo odpovídá za jednotlivé kroky obnovy a jak jsou chráněny kritické přihlašovací údaje. Tato jasnost může zabránit tomu, aby se incident v oblasti IT změnil v dlouhodobý výpadek, ztrátu příjmů nebo širší provozní krizi.
Co je to plán obnovy IT po havárii?
Kontinuita podnikání vs. obnova IT po havárii
Co musí váš plán obnovy IT po havárii obsahovat
Co musí váš plán obnovy IT po havárii definovat
Obnova přihlašovacích údajů: přehlížený scénář obnovy po havárii
Šablona plánu obnovy po havárii
Jak otestovat váš plán obnovy IT po havárii
Sestavte obnovu kolem systémů, dat a možností přistupovat
Co je to plán obnovy IT po havárii?
Plán obnovy IT po havárii je zdokumentovaný proces, jak obnovit technologické systémy po narušení. Zaměřuje se na IT vrstvu podniku: data, aplikace, zařízení, infrastrukturu, cloudové služby, oprávnění správce přistupovat, zálohy a osoby odpovědné za obnovu.
Praktický plán obnovy IT by měl odpovědět na otázky jako:
- Které systémy musí být obnoveny jako první?
- Jak dlouhý výpadek může firma tolerovat?
- Jaká ztráta dat je přijatelná?
- Kde jsou zálohy uložené?
- Kdo může systémy obnovit?
- Které přihlašovací údaje správce jsou potřeba?
- Jak tým potvrdí, že obnovené systémy jsou bezpečné a použitelné?
- Jak bude firma komunikovat se zaměstnanci a zákazníky, pokud budou primární kanály mimo provoz?
Plán obnovy po havárii by měl jít nad rámec řešení kybernetických útoků: musí pokrývat každodenní problémy, jako je selhání hardwaru, ztracené přihlašovací údaje a neúmyslné smazání. Musí také pokrývat přerušení externích služeb, jako jsou výpadky cloudové platformy nebo nástrojů SaaS, chyby v konfiguraci a odchod klíčových zaměstnanců bez předání oprávnění přistupovat ke kritickým systémům.
Obnova není něco, co by se mělo navrhovat během výpadku. Musí být naplánovaná, mít své vlastníky, být komunikovaná a otestovaná ještě předtím, než na ní bude vaše firma záviset.
Kontinuita podnikání vs. obnova IT po havárii
Kontinuita podnikání a obnova IT po havárii jsou často považovány za totéž, ale řeší odlišné problémy.
Kontinuita podnikání je o udržení chodu společnosti během narušení. Zahrnuje komunikaci s klienty, dočasné pracovní postupy, odpovědnosti zaměstnanců, koordinaci s dodavateli a rozhodnutí o tom, které služby musí pokračovat, i když běžné systémy nejsou k dispozici.
Obnova IT po havárii se zaměřuje na technologie stojící za touto prací. Definuje, jak budou obnoveny systémy, data, aplikace, zálohy a oprávnění správce přistupovat k nim, aby se firma mohla bezpečně vrátit k běžnému provozu.
Představte si jako příklad výpadek CRM. Plán kontinuity podnikání může vysvětlovat, jak týmy prodeje nebo podpory nadále obsluhují zákazníky, zatímco je CRM mimo provoz. Plán obnovy IT vysvětluje, kdo kontaktuje prodejce, která data je třeba obnovit, která záloha nebo možnost exportovat je k dispozici, které přihlašovací údaje jsou vyžadovány a jak tým potvrdí, že systém je opět bezpečný k použití.
U mnoha SMB se tato mezera objeví až během incidentu. Lidé vědí, kdo by kontaktoval klienty, ale ne kdo může obnovit fakturační systém. Vědí, že zálohy existují, ale ne, zda bylo někdy testováno jejich obnovení. Vědí, že jeden zaměstnanec má obvykle na starosti IT, ale ne, co se stane, když tento člověk nebude k dispozici, nebo kde jsou uložená hesla správce, pokud s ním nebude možné navázat kontakt.
Co musí váš plán obnovy IT po havárii obsahovat
Dobrý plán obnovy IT po havárii nemusí být příliš dlouhý, ale musí být dostatečně konkrétní, aby se podle něj dalo postupovat ve stresové situaci.
Cíl doby obnovy
Cíl doby obnovy neboli RTO definuje, jak rychle musí být systém obnoven. Platební systém může být potřeba zprovoznit během několika hodin, zatímco interní reportingový ovládací panel může tolerovat delší výpadek.
Stanovte hodnoty RTO podle dopadu na podnikání, nikoli podle technických předvoleb, protože náklady na výpadek představují jak obchodní, tak technický problém. Zeptejte se, které systémy ovlivňují příjmy, závazky vůči zákazníkům, zákonné povinnosti, bezpečnost a produktivitu zaměstnanců.
Cíl bodu obnovy
Cíl bodu obnovy neboli RPO definuje, jaká ztráta dat je přijatelná, což pak pomáhá nastavit správné strategie prevence ztráty dat (DLP). Pokud má systém RPO jednu hodinu, zálohy nebo replikace musí podpořit obnovu přibližně do tohoto bodu.
Pokud je RPO jeden den, firma akceptuje větší mezeru. RPO také pomáhá určit frekvenci zálohování, protože čím kratší je vaše RPO, tím častější musí vaše zálohy být. Kritické systémy proto vyžadují častější zálohy než systémy s nízkou prioritou.
Úrovně priority systémů
Ne každý systém by měl být obnoven ve stejnou dobu. Plán obnovy po havárii pro malé firmy by měl systémy rozdělit do úrovní priority.
- 1. úroveň: Systémy vyžadované pro základní provoz, bezpečnost, komunikaci nebo příjmy.
- 2. úroveň: Důležité systémy, které mohou tolerovat krátký výpadek.
- 3. úroveň: Systémy s nižší prioritou, které lze obnovit poté, co se chod firmy stabilizuje.
Typické systémy 1. úrovně mohou zahrnovat e-mail, poskytovatele identity, správce hesel, finanční systémy, databázi zákazníků, cloudové úložiště a komunikační platformy.
Strategie zálohování
Vaše strategie zálohování by měla definovat:
- Co se zálohuje a jak často
- Kde jsou zálohy uložené
- Kdo k nim může přistupovat
- Jak se testuje obnovení
NCSC také zveřejnilo(nové okno) principy zálohování odolného vůči ransomwaru pro cloudová a on-premise řešení zálohování s tím, že zálohovaná data nejsou vůči ransomwaru odolná ve výchozím nastavení a měla by být posuzována z hlediska hrozby ransomwaru.
Silná strategie zálohování obvykle zahrnuje offline nebo neměnné zálohy pro kritická data, pravidelné testování, zdokumentované kroky pro obnovení a samostatné přihlašovací údaje pro správu záloh.
Role a odpovědnosti
Plán obnovy po havárii by měl jmenovat vlastníky, nikoli pouze úkoly. Pokud všechny znalosti o obnově drží jedna osoba, firma čelí personálnímu riziku stejně jako riziku v oblasti IT. Definujte, kdo:
- Vede obnovu
- Obnovuje systémy
- Kontaktuje prodejce
- Schvaluje nouzový přístup
- Komunikuje interně
- Dokumentuje rozhodnutí
Co musí váš plán obnovy IT po havárii definovat
| Komponenta | Na co odpovídá |
| RTO | Jak rychle musí být každý systém obnoven? |
| RPO | O kolik dat si firma může dovolit přijít? |
| Úrovně priority | Které systémy se obnovují jako první a které mohou počkat? |
| Strategie zálohování | Co se zálohuje, kde je to uložené a zda bylo testováno obnovení? |
| Role a odpovědnosti | Kdo vede obnovu, obnovuje systémy, kontaktuje prodejce a schvaluje nouzové změny? |
Obnova přihlašovacích údajů: přehlížený scénář obnovy po havárii
Obnova po havárii se často zaměřuje na data, servery a zálohy. V praxi však obnova může selhat, protože tým nemá oprávnění přistupovat k systémům potřebným k obnovení provozu.
Obnova přihlašovacích údajů se ptá:
- Kdo má oprávnění přistupovat k účtům správce?
- Kde jsou uložené přihlašovací údaje zálohy?
- Které účty mohou obnovit kritické systémy?
- Co se stane, když je heslo ztraceno, kompromitováno nebo ho má někdo, kdo není k dispozici?
- Jsou nouzové přihlašovací údaje chráněny a revidovány?
- Lze oprávnění přistupovat rychle odvolat a znovu přidělit?
Pokud jsou záložní přihlašovací údaje uložené v prohlížeči jednoho zaměstnance, kódy pro obnovení jsou uchovávány v soukromé poznámce nebo sdílená hesla správce kolují v chatu, firma nemusí být schopna během incidentu bez problémů obnovit provoz.
Firemní správce hesel pomáhá toto riziko snížit tím, že centralizuje kritické přihlašovací údaje v šifrovaných trezorech, přiděluje oprávnění přistupovat podle rolí a usnadňuje odvolat nebo znovu přidělit přístup, když někdo odejde nebo se změní odpovědnosti. Proton Pass for Business pomáhá týmům generovat silná hesla, bezpečně ukládat přihlašovací údaje, používat zabezpečené sdílení a udržovat citlivý přístup mimo chaty a tabulky.
Jako správce hesel pro IT týmy Proton Pass podporuje centralizovanou správu přihlašovacích údajů, zásady hesel, bezpečné sdílení, reporting a logy, SCIM provisioning a integrace SSO. Díky tomu je obnova přihlašovacích údajů lépe zvládnutelná, protože oprávnění přistupovat ke kritickým systémům nezávisí na jedné osobě, jednom profilu prohlížeče nebo jednom nezdokumentovaném hesle.
Šablona plánu obnovy po havárii
Plán obnovy po havárii funguje nejlépe, když je dostatečně konkrétní, aby vedl k akci během výpadku, ale zároveň dostatečně jednoduchý, aby ho tým mohl použít pod tlakem. Pro SMB by se šablona měla zaměřit na to podstatné: co je treba obnovit, jak rychle, ze které zálohy, kým a s jakými přihlašovacími údaji.
1. Rozsah
Definuje, které systémy, služby, umístění, zařízení a data plán pokrývá.
Text šablony: Tento plán obnovy IT po havárii pokrývá systémy, data, služby, přihlašovací údaje a prodejce potřebné k tomu, aby bylo možné obnovit kritické operace společnosti [Company Name] po narušení technologií.
2. Inventář kritických systémů
Uveďte systémy, na které vaše firma spoléhá, a přiřaďte jim úrovně priority.
Kopie šablony: Kritické systémy budou rozděleny do skupin Tier 1, Tier 2 a Tier 3 na základě dopadu na podnikání, cíle doby obnovy, cíle bodu obnovy a závislosti na jiných systémech.
3. Cíle obnovy
Definujte RTO a RPO pro každý prioritní systém.
Text šablony: Každý systém musí mít zdokumentovaný cíl doby obnovy a cíl bodu obnovy. Tyto cíle by měly být přezkoumávány nejméně jednou ročně a po významných změnách systému.
4. Proces zálohování a obnovení
Zdokumentujte, kde jsou zálohy uložené, jak často se spouštějí, kdo k nim může přistupovat a jak funguje testování obnovení.
Text šablony: Zálohy musí být chráněny před neoprávněným přístupem, uložené odděleně od primárních systémů, kde je to vhodné, a pravidelně testovány. Postupy pro obnovení musí být zdokumentovány pro systémy 1. úrovně.
5. Obnova přihlašovacích údajů a oprávnění přistupovat
Definujte, kde jsou uložené kritické přihlašovací údaje a kdo k nim může během obnovy přistupovat.
Text šablony: Přihlašovací údaje správce, přihlašovací údaje zálohy, kódy pro obnovení a přístup prodejců vyžadovaný pro obnovu po havárii musí být uložené ve schváleném šifrovaném trezoru. Přístup musí být omezen na autorizované role a revidován po změnách rolí, odchodu zaměstnanců a cvičeních obnovy.
6. Role a eskalace
Definujte vlastníky obnovy, jejich zástupce a eskalované cesty.
Text šablony: Každá role pro obnovu must mít primárního vlastníka a záložního vlastníka. Plán musí identifikovat, kdo vede obnovu, kdo obnovuje systémy, kdo kontaktuje prodejce, kdo komunikuje aktualizace a kdo schvaluje nouzové změny.
7. Komunikační plán
Definujte, jak firma během výpadku IT komunikuje interně a externě.
Text šablony: Během události obnovy budou interní aktualizace sdíleny prostřednictvím [schválený kanál]. Externí komunikace se zákazníky, prodejci, pojistiteli nebo regulačními orgány musí být schválena [role/tým].
8. Periodicita testování a revizí
Definujte, jak často je plán testován a aktualizován.
Text šablony: Tento plán obnovy po havárii bude testován nejméně [jednou ročně / dvakrát ročně] a revidován po závažných incidentech, změnách systému, změnách prodejců nebo neúspěšných cvičeních obnovy.
Jak otestovat váš plán obnovy IT po havárii
Plán obnovy po havárii se stává užitečným, pouze pokud byl otestován v podmínkách, které se podobají skutečnému narušení. Záloha, která existuje, ale nikdy nebyla obnovena, je stále jen předpokladem. Role pro obnovu, které rozumí pouze jeden člověk, je stále závislostí. Přihlašovací údaj správce, který během výpadku nikdo nemůže najít, je stále překážkou.
Testování nemusí být zpočátku složité. Pro většinu SMB je cílem dokázat, že firma dokáže obnovit správné systémy se správnými lidmi a s použitím správných přihlašovacích údajů v realistickém časovém rámci.
1. Teoretické cvičení
Vyberte pravděpodobný scénář, jako je ransomware postihující sdílené soubory, výpadek cloudového úložiště, neúmyslné smazání zákaznických dat nebo náhlá ztráta oprávnění přistupovat k účtu správce. Projděte si, co by tým dělal v první hodině, kdo by ho vedl, kteří prodejci by byli kontaktováni, které systémy by měly prioritu a jaké informace by chyběly.
2. Otestujte obnovení
Vyberte kritický soubor, databázi, e-mailovou schránku nebo export systému a potvrďte, že jej lze obnovit do použitelného stavu. Zkontrolujte, zda jsou obnovená data dostatečně aktuální, zda oprávnění stále fungují a zda tým ví, kde se záloha nachází.
3. Testujte pravidelně
Jako praktický základ by měly SMB testovat plán alespoň jednou ročně v souladu s pokyny NIST v dokumentu Special Publication 800-34 Revision 1(nové okno), a častěji po významných změnách systémů nebo prodejců.
4. Otestujte obnovení přihlašovacích údajů
Potvrďte, že autorizované osoby mohou přistupovat k záložním účtům správce, cloudovým účtům správce, portálům prodejců, kódům pro obnovení a nouzovým přihlašovacím údajům, aniž by se musely spoléhat na prohlížeč jednoho zaměstnance, soukromé poznámky nebo paměť. Cílem není zbytečně odhalovat citlivá hesla. Jde o to potvrdit, že model přístupu stále funguje, když je firma pod tlakem.
Po každém testu zdokumentujte, co selhalo, co trvalo příliš dlouho, a přiřaďte konkrétní osobu a termín pro každou nápravu. Dobrý test není ten, při kterém jde všechno perfektně. Je to ten, který odhalí nedostatky, dokud má firma ještě čas je napravit.
Sestavte obnovu kolem systémů, dat a oprávnění přistupovat
Užitečný plán obnovy IT po havárii dává firmě pořadí obnovy, sadu vlastníků, realistický pohled na přijatelný výpadek a způsob, jak udržet kontinuitu podnikání a znovu získat přístup k systémům, které udržují práci v chodu.
Pro SMB to může znamenat rozdíl mezi krátkým narušením a dlouhodobým výpadkem. Pokud jsou e-mail, finanční software, cloudové úložiště, zákaznické systémy nebo účty správce nedostupné, tým musí vědět, co je na řadě jako první, kdo může jednat a které přihlašovací údaje jsou vyžadovány k bezpečnému obnovení přístupu.
Proto by plánování obnovy mělo zahrnovat systémy, data a přístup dohromady. Zálohy sice mohou obnovit soubory, ale přihlašovací údaje jsou tím, co týmu umožňuje znovu získat kontrolu nad systémy potřebnými k obnovení provozu. Přihlášení správce, portály prodejců, záložní účty, kódy pro obnovení a sdílené provozní přihlašovací údaje musí být chráněné, organizované a dostupné správným lidem, když se něco pokazí.
Firemní správce hesel pomáhá tuto část plánu posílit. Díky tomu, že jsou kritické přihlašovací údaje uložené v šifrovaných trezorech na hesla a sdílené pouze s autorizovanými osobami, je firma během události obnovy méně závislá na prohlížeči jednoho zaměstnance, soukromých poznámkách nebo paměti.
