Lokální záloha je lepší než žádná záloha, ale nepředstavuje kompletní plán obnovy. Pokud se záloha nachází na stejném serveru, diskovém poli, síti nebo ve stejných prostorách jako produkční systém, stejný incident může zasáhnout živá data i jejich obnovovací kopii.
To je důležité ve chvíli, kdy ransomware zašifruje dostupné soubory, disk selže bez varování nebo požár, povodeň, krádež, výpadek napájení či chyba obsluhy vyřadí celý provoz z provozu. Firma může mít technicky stále k dispozici zálohu, ale ne takovou, kterou lze použít.
Pro agenturu nebo malou firmu nejde jen o nepříjemnost v oblasti IT. Neúspěšná obnova může zastavit e-mail, účetnictví, zákaznické portály, dodávky projektů, interní soubory i podnikové aplikace. Klienti mohou zaznamenat zmeškané termíny nebo nedostupné služby dříve, než firma vůbec zjistí příčinu.
Proč může lokální záloha selhat spolu s primárním serverem
Lokální záloha obvykle znamená kopii uloženou v blízkosti systému, který chrání. Může jít o druhý disk ve stejném serveru, zálohovací disk připojený k síti, NAS v kanceláři nebo jiný počítač ve stejné serverovně. Tato řešení mohou usnadnit rychlou, běžnou obnovu. Automaticky však nezajišťují oddělení od závažného incidentu.
Ransomware může zasáhnout více než produkční data
Provozovatelé ransomwaru nekončí vždy u zašifrování hlavního serveru. Jakmile získají administrátorské údaje nebo se přesunou po síti, mohou hledat zálohovací sdílené složky, připojená úložiště, konzole pro správu a starší body obnovy. Pokud je lokální záloha trvale dostupná se stejnými přihlašovacími údaji, může být zašifrována, smazána nebo záměrně poškozena.
Některé útoky cílí také na zálohovací software a jeho konfiguraci. Cíl je jasný: odstranit schopnost organizace obnovit data a následně zvýšit tlak na zaplacení výkupného. Druhá kopie, která je online, zapisovatelná a viditelná z napadeného prostředí, nemusí poskytovat smysluplnou ochranu před ransomwarem.
Smazání je stejně závažné jako zašifrování. Útočník může odstranit body obnovy, vyprázdnit koše, vypnout naplánované úlohy nebo změnit nastavení uchovávání. Zaměstnanec, který se snaží omezit dopad incidentu, může také smazat nesprávné soubory nebo odpojit úložiště v nevhodnou chvíli. Záloha potřebuje ochranu před škodlivými i náhodnými změnami.
Poruchy hardwaru a disků se neřídí harmonogramem zálohování
Pevné disky, SSD, RAID řadiče, napájecí zdroje i základní desky serverů mohou selhat. RAID může po selhání jednoho disku udržet server v provozu, ale RAID není záloha: replikuje nebo rozděluje data v rámci stejného systému, místo aby vytvářel nezávislou obnovovací kopii.
Selhat může i lokální zálohovací disk, zejména pokud nepřetržitě běží ve stejném prostředí nebo není monitorován a testován. Pokud server a jeho zálohovací úložiště sdílejí řadič, napájecí zdroj, místnost nebo chladicí systém, může jedna porucha zasáhnout obě zařízení. Úloha zálohování, která hlásí úspěch, může stále obsahovat nečitelná data nebo neúplný stav aplikace, pokud nejsou obnovy kontrolovány.
Události v prostorách odstraní všechny blízké kopie
Riziko se neomezuje pouze na kybernetické útoky. Krádež může současně odnést servery i zálohovací disky. Požár může zničit kancelář nebo místnost datového centra. Záplavy mohou poškodit zařízení v několika patrech nebo v celé budově. Incident související s napájením může vyřadit produkci i lokální úložiště, zatímco elektrický přepěťový ráz může poškodit obojí.
I když lokální zálohovací zařízení přežije, firma k němu nemusí mít přístup. Budova může být uzavřena, síť nedostupná nebo lidé, kteří systém umějí obsluhovat, mohou sami řešit incident. Fyzická blízkost je užitečná při některých rychlých obnovách, ale stává se slabinou, pokud obnovovací kopie nemá geografické ani logické oddělení.
Chyba obsluhy představuje riziko pro obnovu
Lidské chyby jsou častou příčinou ztráty dat: dojde ke smazání adresáře, přepsání virtuálního počítače, změně zásad uchovávání nebo vypnutí zálohovací úlohy během údržby, která už není znovu aktivována. Lokální systémy často usnadňují administrátorovi s rozsáhlými oprávněními změnit produkční data i jejich zálohu.
Obnovitelný návrh počítá s tím, že lidé budou občas chybovat. Využívá oddělené řízení přístupu, chráněné uchovávání, jasné postupy a testy obnovy, místo aby spoléhal na to, že si jeden administrátor v časovém presu vzpomene na každý krok.
Lokální záloha, off-site záloha a obnova podle pravidla 3-2-1
Tyto pojmy spolu souvisejí, ale nejsou zaměnitelné. Firma může mít více kopií a přesto křehký plán obnovy, pokud všechny kopie závisí na stejném serveru, účtu, umístění nebo napájecím zdroji.
Lokální záloha
Lokální záloha je uložena na stejném místě nebo ve stejné infrastruktuře jako chráněný server. Její hlavní výhodou je rychlost. Pokud je smazán jeden soubor a server zůstává v pořádku, může být obnova z blízkého úložiště rychlejší než načítání dat přes síťové připojení do jiného umístění.
Její omezení jsou stejně praktická:
- Může být dostupná ransomwaru, který využívá kompromitované přihlašovací údaje.
- Může být zničena nebo odcizena spolu s primárním serverem.
- Může záviset na stejné elektřině, síti, administrátorovi nebo hardwaru.
- Může vytvářet falešný pocit bezpečí, pokud nebyla nikdy otestována obnova.
Lokální záloha může být užitečnou vrstvou, zejména pro rychlou provozní obnovu. Neměla by však být jedinou vrstvou. Širší srovnání omezení lokální zálohy a rizik off-site obnovy jasně ukazuje hlavní pointu: blízká kopie není automaticky nezávislou kopií.
Off-site záloha
Off-site záloha je uložena mimo produkční prostředí. Oddělení může být fyzické, logické nebo obojí. Pokud je kancelářský server napaden, obnovovací data by neměla být vystavena prostřednictvím stejné běžné cesty. Pokud jsou prostory poškozeny, firma by stále měla mít přístup ke svému zálohovacímu úložišti z jiného místa.
Off-site ochrana je nejsilnější, pokud zahrnuje šifrování, řízený přístup, uchovávání, které nelze snadno přepsat, a proces obnovy, který byl prakticky vyzkoušen. Samotné umístění nestačí. Kopie uložená v jiné budově, ale připojená pomocí neomezených přihlašovacích údajů, může být stále zranitelná vůči síťovému útoku.
Obnovitelný přístup 3-2-1
Princip 3-2-1 představuje užitečný základ:
- 3 kopie: uchovávejte produkční data a nejméně dvě další kopie.
- 2 typy úložišť nebo prostředí: neumisťujte všechny kopie na stejný typ systému nebo přístupové cesty.
- 1 kopie mimo lokalitu: zajistěte, aby incident v daném místě neodstranil všechny možnosti obnovy.
Pro odolnost vůči ransomwaru potřebuje tento model více podrobností. Nejméně jedna obnovovací kopie by měla být izolována od běžného přístupu pro zápis a chráněna před úpravami po dobu uchovávání. Právě zde je důležitá neměnnost. Neměnnou zálohu nelze během definovaného období uchovávání upravovat ani mazat běžnými operacemi, což snižuje pravděpodobnost, že útočník nebo uspěchaný administrátor vymaže historii obnovy.
Neměnnost nenahrazuje řízení přístupu, šifrování, monitorování ani testování. Jde o jednu z kontrol v návrhu obnovy. Organizace musí také vědět, jak se ověřit, požádat o obnovu, získat potřebné klíče a znovu sestavit služby závislé na datech.
Šifrování a správa klíčů ovlivňují možnost obnovy
Zálohovaná data mohou obsahovat záznamy o zákaznících, faktury, smlouvy, přihlašovací údaje, zdrojové soubory, exporty e-mailů a osobní informace. Uložení těchto dat mimo lokalitu bez šifrování představuje riziko pro jejich důvěrnost. Šifrování data chrání v případě odhalení úložných médií nebo přístupových kanálů.
Šifrování však přináší praktickou odpovědnost: někdo musí mít klíč pod kontrolou. Pokud jediný použitelný klíč drží poskytovatel, zákazník může mít menší nezávislou kontrolu nad přístupem k vlastním obnovovacím datům. Pokud se klíč ztratí, mohou být zálohovaná data trvale nečitelná, přestože je úložiště neporušené.
U společnosti Safenix jsou zálohy šifrovány pomocí klíče, který Safenix nikdy nedrží. Tento návrh ponechává správu klíče zákazníkovi, místo aby se poskytovatel stal jedinou autoritou schopnou data dešifrovat. Klíč proto musí být chráněn, zdokumentován a zpřístupněn oprávněným osobám, když je potřeba obnova. Firma by měla určit, kdo má přístup, kde jsou uloženy nouzové informace ke klíči a jak se přístup předá, pokud obvyklý administrátor není k dispozici.
Plán obnovy by měl na tyto otázky odpovědět ještě před incidentem:
- Kdo je oprávněn požádat o obnovu?
- Kdo má přístup k šifrovacímu klíči?
- Jak se ověřují žádosti během krizové situace?
- Co se stane, pokud je hlavní administrátor nemocný, nedostupný nebo zasažen stejným incidentem?
- Lze obnovená data použít v aplikaci, nebo vyžadují další konfiguraci a přihlašovací údaje?
Dobrá správa klíčů vyvažuje bezpečnost a dostupnost. Uložení klíče na stejném serveru jako šifrovaná záloha maří smysl oddělení. Uložení klíče pouze v paměti jediné osoby vytváří jiný kritický bod selhání.
Uchovávání, RPO a RTO mění zálohu v plán obnovy
Uchovávání určuje, jak daleko do minulosti se můžete vrátit
Uchovávání je období, po které jsou ponechány body obnovy. Krátké období může stačit při náhodném smazání, ale je k ničemu, pokud ransomware zůstane několik týdnů neodhalen. Delší období dává organizaci více příležitostí najít čistý bod obnovy, zejména pokud útočník před spuštěním šifrování potichu pozměňoval soubory.
Doba uchovávání by měla odpovídat potřebám firmy. Agentura může potřebovat starší projektové soubory, fakturační záznamy a výstupy pro klienty. Malý maloobchod nebo firma poskytující odborné služby může potřebovat finanční a regulatorní záznamy mnohem déle než každodenní provozní snímky. Důležité je rozhodnout se záměrně, místo abyste přijali výchozí nastavení, které nikdo nikdy nekontroloval.
RPO určuje přijatelnou ztrátu dat
Cíl bodu obnovy neboli RPO je maximální období nedávných dat, o které je firma ochotna přijít. Pokud zálohy běží jednou denně, selhání serveru může znamenat ztrátu téměř celého pracovního dne. Pokud firma snese ztrátu pouze jedné hodiny, musí harmonogram zálohování a kapacita sítě podporovat častější ochranu.
RPO není pouze technické nastavení. Má svou cenu. Častější zálohy spotřebují více úložiště, přenosové kapacity a času na zpracování. Správný cíl závisí na hodnotě a četnosti změn dat i na důsledcích jejich ručního znovuvytvoření.
RTO určuje přijatelnou dobu výpadku
Cíl doby obnovy neboli RTO vyjadřuje, jak rychle musí být služba po incidentu znovu dostupná. Obnova několika souborů a znovuvybudování celého serveru jsou odlišné úkoly. RTO by mělo zohledňovat přenos dat, dešifrování, nastavení operačního systému, instalaci aplikací, aktivaci licencí, změny DNS, přístup uživatelů a ověření funkčnosti.
Firma, která slibuje rychlé obnovení služeb, musí rozumět svým závislostem. Server může záviset na databázi, adresářové službě, poštovním relé, pravidle firewallu, softwarové licenci, externím API nebo specializované konfiguraci, která není součástí zálohovaných dat. Záloha může dokonale obnovit soubory, a přesto ponechat aplikaci nedostupnou.
Testování obnovy odlišuje kopii od skutečné schopnosti obnovy
Úspěšně dokončená zálohovací úloha pouze dokazuje, že proces proběhl podle zálohovacího softwaru. Nedokazuje, že jsou přítomny požadované soubory, že je záloha konzistentní nebo že firma může po obnově fungovat.
Testy obnovy by měly být plánovány na různých úrovních:
- Obnova souborů: obnovte jednotlivé dokumenty, poštovní schránky nebo projektové adresáře.
- Obnova systému: obnovte celý server nebo virtuální počítač na vhodnou infrastrukturu.
- Obnova aplikace: ověřte, že databáze, služby, oprávnění a konfigurace fungují společně.
- Ověření fungování firmy: požádejte uživatele, aby provedli realistické úkoly a ověřili úplnost dat.
Testování by mělo zaznamenat, jak dlouho trvá každá fáze, které přihlašovací údaje jsou potřeba a které kroky závisí na konkrétní osobě. Postup je nutné aktualizovat po změnách serveru, aktualizacích softwaru, úpravách sítě a změnách odpovědností zaměstnanců.
Chráněné off-site zálohy se šifrováním, obnovou po ransomwaru, uchováváním a testováním obnovy lze posoudit jako součást širší služby zálohování a obnovy Safenix. Relevantní otázkou není pouze to, kolik úložiště je zahrnuto. Jde o to, zda návrh snižuje počet rozhodnutí, která musí malý tým učinit během narušující události, a zároveň zachovává zákazníkovi kontrolu nad chráněnými daty.
Jak může agentura nebo malá firma pokračovat v provozu
Když je primární server nedostupný, obnova by měla začít stanovením priorit, nikoli panikou. Určete služby, které udržují firmu v provozu, a služby, které mohou počkat. Praktické pořadí může být následující:
- Potvrďte incident a izolujte zasažené systémy, aniž byste zničili důkazy nebo možnosti obnovy.
- Vyberte čistý bod obnovy podle RPO a pravděpodobného času napadení.
- Obnovte nejdůležitější server nebo aplikaci v kontrolovaném prostředí.
- Před opětovným širokým připojením služby ověřte data, přístup uživatelů a kritické pracovní postupy.
- Poskytněte zaměstnancům a klientům jasný dočasný provozní postup.
Dočasný provoz může využívat přístup k nezbytným záznamům pouze pro čtení, alternativní komunikační kanály, ruční evidenci objednávek nebo požadavků či omezenou nabídku služeb. Plán by měl určit, kdo komunikuje s klienty, kdo schvaluje náhradní postupy a jak se po návratu systémů sladí nové transakce.
Pro agenturu to může znamenat upřednostnění projektových souborů, komunikace s klienty, evidence času a fakturace. Pro malou firmu může jít o obnovu objednávek, skladových dat, schůzek, finančních systémů nebo zákaznické podpory. Cílem není vždy obnovit všechny servery najednou. Nejprve je třeba obnovit služby, které omezí dopad na klienty a ochrání cash flow.
Závislosti obnovy by měly být zdokumentovány odděleně od samotné zálohy. Uchovávejte přehled rolí serverů, podrobností o síti, vlastníků aplikací, informací o licencích, DNS záznamů, důležitých kontaktů a způsobu správy klíčů. Nepředpokládejte, že osoba, která server vytvořila, bude k dispozici během požáru, ransomwarového útoku nebo náhlého onemocnění.
Náklady spoléhání pouze na lokální zálohu
Strategie založená pouze na lokálních zálohách se zdá levná, protože může využívat stávající disky a hardware. Skryté náklady se projeví při selhání. Zaměstnanci mohou strávit několik dní zjišťováním, co přežilo, hledáním čisté kopie, obnovou systémů a opětovným vytvářením chybějících informací. Nouzové vybavení, odborná podpora, přesčasy a ztracené prodeje mohou rychle převýšit náklady na řádnou off-site ochranu.
Výpadek také ovlivňuje důvěru. Klienti mohou zmeškat termíny, ztratit přístup k dodaným materiálům nebo začít pochybovat, zda byly důvěrné informace chráněny. Firma možná bude muset incident vysvětlit, prošetřit možné odhalení dat, informovat dotčené strany a vyjednávat prodloužení termínů. I když se data nakonec podaří obnovit, provozní a reputační dopad může přetrvávat.
Off-site záloha serverů není zárukou, že každý incident proběhne bezbolestně. Je to způsob, jak snížit počet událostí, které vyústí v trvalou ztrátu dat, a dát firmě definovanou cestu zpět k provozu. Její hodnota vychází z kombinace oddělení, šifrování, správy klíčů pod kontrolou zákazníka, neměnného uchovávání, vhodně nastavených cílů RPO a RTO a pravidelného testování obnovy.
Budujte odolnost kolem serverů, které máte pod kontrolou
Safenix je vhodný pro firmy, které chrání servery pod vlastní kontrolou, ať už tyto servery podporují agenturu, malou kancelář nebo aplikaci pro klienty. Na rozsahu záleží: nejde o zálohování webu hostovaného na sdíleném hostingu, kde zákazník nekontroluje základní server ani proces zálohování. Web na sdíleném hostingu by měl být posuzován podle vlastního nastavení zálohování a obnovy poskytovatele hostingu.
U serveru pod vlastní kontrolou začněte zmapováním dat a služeb, které na něm závisí. Poté určete, co může pokrýt lokální záloha, co musí být uloženo off-site, jak dlouho mají body obnovy zůstat neměnné, kdo kontroluje šifrovací klíč a jak bude obnova testována. První hodiny výpadku zdokumentujte stejně pečlivě jako samotný harmonogram zálohování.
Lokální kopie vám může pomoci rychle se zotavit z drobné chyby. Izolovaná, šifrovaná a neměnná off-site kopie vám dává větší šanci na obnovu ve chvíli, kdy je problémem server, síť, prostory nebo útočník. Toto rozlišení je základem praktické ochrany před ransomwarem a obnovy po havárii.