Zálohování jako poslední záchrana: pravidlo 3-2-1 v praxi

01Zálohujte to, co je potřebné pro službu

Sepište databáze, nahrané soubory, konfiguraci a návazné služby. U firemní aplikace nestačí zachránit tabulku zákazníků, když chybí přílohy, nastavení oprávnění nebo informace potřebné k jejímu spuštění. U každé části zapište, kde vzniká, kdo ji spravuje a jak ověříte její obnovitelnost.

Rozlišujte data, která znovu získáte ze spolehlivého zdroje, a data, která jsou nenahraditelná. Zdrojové soubory aplikace uložené ve spravovaném repozitáři mohou mít jiný postup obnovy než dokumenty nahrané zákazníky. Přesto potřebujete vědět, jakou verzi aplikace lze spustit nad obnovenou databází.

• Provozní data a soubory, které patří ke stejnému stavu služby.
• Nastavení systému, oprávnění a potřebné návaznosti.
• Postup získání klíčů a přístupů pro oprávněnou obnovu.
• Dokumentace, kontakty a rozhodnutí o pořadí obnovy.

U SaaS služby ověřte rozsah exportu a obnovy. Záloha poskytovatele nemusí být funkcí, kterou může zákazník sám použít pro svůj omylem smazaný obsah. NCSC doporučuje nezávislou kopii důležitých cloudových dat, místo spoléhání pouze na historii souborů nebo dočasný koš.

02Stanovte přípustnou ztrátu dat a čas obnovy

RPO vyjadřuje požadovaný bod v čase, ke kterému musíte data obnovit; prakticky pomáhá určit tolerovanou ztrátu novějších změn. RTO určuje časový cíl obnovení dostupnosti potřebného systému. Rozlišení popisuje NIST SP 800-34 Rev. 1. Tyto požadavky vycházejí z dopadu na práci firmy, nikoli pouze z možností zálohovacího nástroje.

Ptejte se vedoucího procesu, jaké záznamy lze případně doplnit ručně a jak dlouho může práce čekat. Odpověď se může lišit pro přijímání objednávek, historický archiv a pomocný přehled. Udržujte proto cíle po službách. Jediný ambiciózní požadavek pro všechna data může prodražit návrh bez odpovídajícího užitku.

Interval spouštění úlohy sám nezaručuje dosažení RPO. Záloha může selhat, trvat déle nebo se nedostat do bezpečného úložiště. Stejně tak stažení souborů není celá obnova služby. Do plánování zahrňte prostředí, přístupy, kontrolu dat a ověření klíčového uživatelského úkolu.

Při zkoušce porovnejte cíl s dosaženým stavem a časem. Pokud se liší, upravte postup nebo otevřeně změňte požadavek. Časový cíl v dokumentaci bez potřebných prostředků není připraveností na incident.

03Pravidlo 3-2-1 omezuje společné riziko

Běžná formulace znamená alespoň tři kopie dat, dva různé typy médií a jednu kopii mimo hlavní lokalitu. Do tří kopií se obvykle počítá i původní provozní verze, tedy originál a dvě záložní kopie. Takto pravidlo popisuje také AWS v přehledu zálohování. Nejde o záruku proti každému scénáři ztráty.

V cloudu nehodnoťte návrh jen počtem názvů úložišť. Zjistěte, zda kopie sdílejí účet, oprávnění, klíč nebo závislost na stejné službě. Dvě složky na jednom disku nejsou dva typy médií. U cloudového návrhu popište konkrétní oddělení a rizika, která zůstávají společná.

04Odlište vzdálenou, offline a neměnnou kopii

Offsite znamená jiné místo, offline znamená odpojení od běžně dostupného prostředí. Cloudová kopie není automaticky offline. NCSC vysvětluje tento rozdíl a upozorňuje, že samotné 3-2-1 odpojení nevyžaduje. Dostupnost úložiště i platných oprávnění ovlivňuje, zda se k záloze dostane napadený systém.

NÚKIB v doporučení k ransomware uvádí vedle více kopií také neaktivní zálohu, řízení přístupů ke cloudovým kopiím a testovanou obnovitelnost. Pro vlastní prostředí zvolte opatření, které chrání alespoň jednu použitelnou kopii i při kompromitaci běžného provozu.

Neměnné úložiště omezuje přepsání nebo odstranění dat po stanovenou dobu. Ověřte přesný režim konkrétní služby, možnost obejití a oprávnění ke změně pravidel. Ochrana uchování může ovlivnit mazání i náklady. Nejprve ji navrhněte a vyzkoušejte na vhodném rozsahu, aby odpovídala potřebám firmy.

Snapshot může být součástí dobrého řešení. Samotný název ale neprokazuje nezávislou zálohu. Zjistěte, na čem závisí, kdo jej může odstranit a zda zůstane dostupný při ztrátě původního prostředí.

05Chraňte přístupy, klíče a možnost návratu

Účet používaný aplikací pro běžnou práci by neměl zároveň ovládat všechny záložní kopie. Oddělte oprávnění pro vytváření, čtení a destruktivní zásahy podle možností služby. U správců používejte odpovídající ochranu přihlášení a kontrolujte, kdo může změnit pravidla uchování. Technickou ochranu propojte s konkrétní odpovědností.

Pravidla NCSC pro cloudové zálohy zahrnují ochranu před destruktivními zásahy, zachování přístupu, historii verzí, správu šifrovacích klíčů a upozornění na významné změny. Zašifrovaná záloha bez dostupného klíče není použitelná. Ztráta firemní identity také nesmí bez náhrady zablokovat oprávněnou obnovu.

Připravte nouzový způsob přístupu podle konkrétní služby a pravidelně jej ověřujte. Kontakty, postup a potřebné prostředky musí být dostupné i při výpadku hlavního systému. Současně chraňte nouzový přístup před zneužitím a určete, kdo smí rozhodnout o jeho použití.

U dodavatelů ověřte odpovědnosti a dostupnost pomoci během incidentu. Nestačí jméno společnosti v seznamu. Potřebujete vědět, jak požadavek předáte, kdo potvrdí oprávnění a co může technik skutečně obnovit. Další souvislosti rozebírá bezpečnost v cloudu.

06Intervaly a uchování nastavte podle scénářů

Připravte scénáře pro omylem smazaný soubor, chybnou změnu aplikace, poruchu úložiště i napadení. Nejnovější kopie nemusí být nejlepší, pokud už obsahuje chybu nebo kompromitaci. Historie má umožnit výběr potřebného stavu. Současně zvažte, jak dlouho trvá problém odhalit a kolik změn pak musíte rekonstruovat.

U plné zálohy se ukládá celý vybraný obsah. Inkrementální záloha ukládá změny od předchozí zálohy, rozdílová změny od poslední plné. Potřebné podklady pro obnovu závisí na nástroji a formátu. Ověřte celý řetězec a nesmažte jeho potřebnou část jen proto, že vypadá jako starý soubor.

Hlídejte poslední úspěšnou kopii, ne pouze počet spuštěných úloh. Upozornění musí dostat člověk, který může reagovat. Dohodněte postup při opakovaném selhání, nedostatku místa nebo nečekané změně objemu. Nezálohovaná nová databáze může uniknout kontrole, i když všechny původní úlohy svítí zeleně.

07Obnovu vyzkoušejte jako skutečný provozní úkol

Test zahajte z vybrané kopie a obnovujte do odděleného prostředí. Zapište dostupný bod obnovy, potřebné kroky, čas a chybějící prostředky. Kontrola čitelnosti souboru je užitečná, ale u aplikace pokračujte kontrolou vazeb a provedením důležitého uživatelského úkolu. Ověřte například objednávku včetně její přílohy a správných oprávnění.

1. Sepište služby, data a cíle obnovy.
2. Vytvořte a chraňte potřebné kopie.
3. Obnovte vybraný stav a ověřte funkci.
4. Doplňte postup a opakujte kontrolu po změnách.

V testovacím prostředí vypněte odesílání skutečných zpráv, plateb a dalších akcí do produkčních služeb. Použití obnovených dat nesmí omylem spustit původní objednávky znovu. Výsledek testu zapište tak, aby jiný oprávněný pracovník uměl postup zopakovat a rozpoznat správný stav.

Po změně aplikace, úložiště nebo přístupů ověřte dotčenou část obnovy. U přesunu prostředí navazuje plán migrace do cloudu. Stará úspěšná zkouška není dokladem, že nová databáze, šifrování nebo závislost už mají připravený návrat.

Zkoušku občas svěřte jinému oprávněnému pracovníkovi než autorovi postupu. Odhalíte tak chybějící krok, kontakt nebo znalost, která existuje pouze v hlavě správce. Při skutečném výpadku nemusí být tento člověk dostupný. Průběžně ověřujte také přístup k dokumentaci, jejíž otevření může záviset na právě obnovovaném systému.

08Při incidentu obnovujte důvěryhodný stav

U bezpečnostního incidentu nejprve koordinujte omezení napadení a zachování důležitých zjištění. Nevkládejte zachráněná data automaticky zpět do prostředí, kterému ještě nedůvěřujete. Zvolený bod obnovy a připravené prostředí musí odpovídat zjištěnému rozsahu problému. Záloha vrací data, sama neodstraňuje příčinu incidentu.

Po obnově ověřte rozpracované případy a návazné systémy. Některé změny se mohly do zálohy nevejít, zatímco u externí služby už proběhly. Provozní tým potřebuje pravidla, jak dohledat chybějící záznamy a předejít duplicitám. O návratu služby rozhodujte podle ověřeného výsledku a sdělte zaměstnancům zbývající omezení.

Z návratu do provozu udělejte řízené rozhodnutí. Určete člověka, který potvrdí technický stav, a vlastníka procesu, který ověří použitelnost dat pro práci firmy. Zaznamenejte bod obnovy, známé ztracené změny a úkoly pro následnou kontrolu. Zaměstnanci tak vědí, které případy mají dohledat a od kdy mohou znovu používat běžný postup.

09Časté otázky k zálohování 3-2-1