Přihlásit se Vyzkoušet zdarma
← Back to blog

Proč jedna záložní kopie neznamená, že jsou data v bezpečí

Záloha může existovat, a přesto selhat ve chvíli, kdy ji potřebujete. Zjistěte, jak umístění kopií, retence, šifrování, neměnnost a testování obnovy ovlivňují skutečnou obnovu firmy.

📝 Tento článek vznikl s pomocí automatizovaných nástrojů a před zveřejněním jej zkontroloval tým Safenix.

Mnoho firem tvrdí, že má zálohu, protože se každou noc spouští úloha, úložné zařízení obsahuje včerejší soubory nebo server hlásí, že jeho data byla zkopírována. Je to užitečný začátek, ale není to důkaz, že se firma dokáže obnovit.

Záloha má hodnotu pouze tehdy, když je dostupná, neporušená, chráněná před stejným incidentem jako originál a použitelná v době, kterou firma dokáže tolerovat. Selhání hardwaru, ransomware, náhodné smazání, poškození softwaru a napadený server mohou odhalit slabiny, které zůstávají neviditelné, dokud vše vypadá normálně.

Praktický rozdíl spočívá mezi existencí záložní kopie a skutečnou schopností obnovy. První je technický fakt. Druhá je provozní výsledek závislý na tom, zda několik opatření funguje společně.

Záložní kopie není totéž co obnovitelná data

Záložní kopie může existovat, a přesto být nepoužitelná. Může být neúplná, poškozená, příliš stará, zašifrovaná ransomwarem, smazaná spolu se zdrojovými daty nebo nedostupná, protože nikdo nezná potřebné přihlašovací údaje. Zálohovací aplikace může také hlásit úspěch, přestože konkrétní databáze, virtuální počítač nebo důležitá složka byly z úlohy vynechány.

Proto mít záložní kopii není totéž jako umět z ní obnovit data. Obnova vyžaduje důvěru v kopii, známý postup obnovy a dostatek času a přístupu k jeho dokončení.

Pomáhá oddělit tři pojmy:

  • Existence zálohy: úloha vytvořila jeden nebo více souborů, snapshotů či uložených verzí.
  • Integrita zálohy: uložená data jsou úplná, čitelná a dostatečně konzistentní pro obnovu.
  • Provozní obnova: organizace dokáže obnovit potřebné systémy a data do použitelného stavu v rámci dohodnutých cílů obnovy.

Firmy často kontrolují pouze první bod. O tom, zda záloha chrání příjmy, zákaznický servis a každodenní provoz během incidentu, rozhodují další dva.

Rizika uchovávání pouze jedné záložní kopie

Jedna kopie vytváří jediný bod selhání. I když je oddělená od produkčních dat, jedna chyba, vadné zařízení, problém s úložištěm nebo škodlivý zásah mohou odstranit jedinou cestu zpět.

Kopie může fyzicky selhat

Pevné disky, zařízení NAS, vyměnitelné disky a řadiče úložiště mohou selhat. Zálohovací zařízení může také poškodit požár, voda, přehřátí nebo problémy s elektřinou. Pokud jsou produkční server a jediné zálohovací zařízení ve stejné místnosti, může jedna fyzická událost zasáhnout obě zařízení.

Média mají také omezenou životnost. Disk, ze kterého se čte jen zřídka, může selhat právě ve chvíli, kdy je obnova naléhavě potřeba. Záloha, která nikdy nebyla kontrolována, nemusí být spolehlivá; může jít pouze o neotestovaný předpoklad uložený na hardwaru.

Kopie může být omylem smazána

Rizika smazání se netýkají pouze produkčních souborů. Administrátor může odstranit nesprávnou sadu záloh, naformátovat zálohovací disk nebo změnit nastavení retence, aniž by si uvědomil důsledky. Automatická synchronizace může situaci ještě zhoršit: pokud se smazané a poškozené soubory okamžitě zrcadlí, záloha může problém věrně reprodukovat místo toho, aby zachovala starší verzi.

Kopie může být dostupná útočníkovi

Provozovatelé ransomwaru po získání přístupu k serveru nebo účtu administrátora běžně hledají zálohy. Mohou smazat katalogy záloh, zašifrovat úložiště záloh, deaktivovat agenty nebo použít odcizené přihlašovací údaje k přístupu k úložišti. Záloha, která používá stejný doménový účet, heslo nebo síťová oprávnění jako produkční prostředí, může být vystavena stejnému útoku.

To je obzvlášť nebezpečné, protože úspěšná zálohovací úloha může vytvořit falešný pocit bezpečí. Úloha mohla každou noc správně proběhnout, ale pokud útočník dokáže její výstup změnit nebo smazat, firma může slabinu odhalit až poté, co byl primární systém zašifrován.

Kopie může být příliš stará

Kopie stará několik týdnů možná obnoví server, ale nemusí obnovit firmu. Organizace může přijít o faktury, zákaznické záznamy, projektovou práci, objednávky nebo změny konfigurace vytvořené od jejího pořízení. Přijatelný objem ztracených dat se označuje jako cíl bodu obnovy neboli RPO.

RPO je obchodní rozhodnutí vyjádřené časem. RPO 24 hodin znamená, že firma připouští možnost ztráty změn za dobu až jednoho dne. RPO čtyři hodiny je náročnější. Harmonogram zálohování musí tomuto očekávání odpovídat; noční úloha nemůže soustavně poskytovat čtyřhodinový bod obnovy.

Proč záleží na umístění zálohy

Záloha uložená na stejném serveru jako originál není nezávislou kopií pro obnovu. Pokud server selže, je odcizen, zašifrován nebo nesprávně nakonfigurován, mohou originální data i jejich záloha zmizet současně.

Uložení zálohy ve stejné místní síti zvyšuje pohodlí, ale neodstraňuje všechna společná rizika. Napadený účet administrátora, společná oprávnění v adresáři, šíření ransomwaru nebo incident postihující celou síť mohou zasáhnout oba systémy. Lokální kopie mohou být užitečné pro rychlou obnovu, neměly by však být jedinou vrstvou.

Mimolokální úložiště vytváří oddělení od incidentů, které zasáhnou prostory zákazníka nebo primární infrastrukturu. Může také omezit dopad místní krádeže, požáru, povodně a selhání hardwaru. Důležitá otázka nezní pouze, zda poskytovatel říká „cloudová záloha“, ale jak je kopie izolována, kdo ji může smazat, jak dlouho se uchovávají verze a zda lze data v praxi obnovit.

Šifrování chrání důvěrnost, ale záleží na vlastnictví klíčů

Zálohy mohou obsahovat osobní údaje, finanční záznamy, přihlašovací údaje, zdrojový kód a soubory zákazníků. Šifrování pomáhá chránit tyto informace při přenosu i uložení. Šifrování je však pouze tak silné, jak silný je způsob správy klíčů.

Pokud dešifrovací klíč drží poskytovatel zálohy, napadení účtu nebo neoprávněný přístup v rámci služby by mohly data potenciálně odhalit. Pokud klíč kontroluje zákazník a poskytovatel jej nikdy nedrží, nemůže poskytovatel obsah zálohy dešifrovat jménem zákazníka. To zvyšuje důvěrnost, ale vytváří také odpovědnost: zákazník musí klíč chránit a zajistit, aby k němu měli oprávnění pracovníci pro obnovu přístup, kdykoli je potřeba.

Správa klíčů by proto měla být zdokumentována ještě před incidentem. Firma by měla vědět, kde je klíč uložen, kdo jej může používat, jak je přístup omezen a co se stane, pokud primární administrátor nebude k dispozici. Plán obnovy závislý na notebooku nebo paměti jediné osoby není odolný plán.

Retence a verzování určují, jak daleko do minulosti lze obnovit data

Jedna úspěšná záloha nestačí, pokud je problém odhalen pozdě. Poškození, malware a náhodné změny mohou zůstat bez povšimnutí několik dní či týdnů. Pokud zálohovací systém uchovává pouze nejnovější verzi, může poškozený stav nahradit čistý stav dříve, než si toho někdo všimne.

Retence určuje, jak dlouho zůstávají verze záloh dostupné. Verzování zachovává více časových bodů, takže firma může vybrat bod obnovy z doby před incidentem. Obojí musí odpovídat rizikům organizace a době, která může být potřeba k odhalení problému.

Například designová agentura může zjistit, že adresář projektu byl přepsán, až když se klient po několika dnech ozve. Malý prodejce může potřebovat záznamy z doby před ransomwarovou infekcí, která byla týden nečinná. V obou případech může být nejnovější kopie nesprávnou kopií.

Retenci je třeba posuzovat společně s právními, smluvními a provozními požadavky. Neomezené uchovávání dat není automaticky bezpečnější: může zvýšit náklady na úložiště, vystavení riziku v oblasti ochrany soukromí i počet kopií, které je nutné spravovat. Cílem je promyšlené retenční období podporující realistické scénáře obnovy.

Neměnnost snižuje riziko úmyslného smazání

Neměnnost znamená, že uložená zálohovaná data nelze během definované ochranné doby změnit ani smazat. Jde o cennou obranu proti ransomwaru a napadeným účtům administrátorů, protože útočník, který pronikne do produkčního prostředí, by neměl být schopen vymazat všechny body obnovy.

Neměnnost nenahrazuje šifrování, mimolokální úložiště ani testování. Řeší však konkrétní způsob selhání: útočníka nebo administrátora, který se po vytvoření kopie pokusí zálohu změnit. Ochranná doba by měla být dostatečně dlouhá, aby pokryla retenční období, na které se firma spoléhá.

Firmy by měly klást přesné otázky a nepřijímat slovo „neměnná“ bez podrobností:

  • Je neměnnost použita na každou uchovávanou verzi, nebo pouze na vybraná data?
  • Může administrátor zkrátit ochrannou dobu nebo smazat úložiště?
  • Pokračuje ochrana i v případě napadení zdrojového serveru?
  • Jak dlouho jsou body obnovy uchovávány?
  • Jaké typy dat a serverů jsou zahrnuty?

Pro servery kontrolované zákazníkem kombinuje Safenix mimolokální úložiště v Německu se zákazníkem spravovanými šifrovacími klíči, které Safenix nikdy nedrží, a zálohy udržuje neměnné po celou dobu retenčního období. Firmy zvažující spravované mimolokální zálohování s retencí, odolností proti ransomwaru a testováním obnovy pro své servery by přesto měly ověřit, že zvolené nastavení odpovídá jejich cílům obnovy a interním odpovědnostem.

Testování obnovy je důkazem, že záloha funguje

Dokončená zálohovací úloha dokazuje, že proces proběhl. Nedokazuje však, že firma dokáže spustit aplikace, otevřít databáze nebo obnovit soubory, které lidé skutečně potřebují.

Testování obnovy mění předpoklad v důkaz. Základní test může obnovit výběr souborů do odděleného umístění a ověřit, že se správně otevřou. Užitečnější test zahrnuje aplikační data, oprávnění, konzistenci databáze a kroky nutné k opětovnému uvedení služby do provozu.

Testujte různé scénáře obnovy

  • Obnova souborů: obnovte omylem smazaný nebo přepsaný soubor a ověřte jeho obsah.
  • Obnova aplikace: obnovte data a konfiguraci potřebné pro klíčovou podnikovou aplikaci.
  • Obnova serveru: po selhání hardwaru nebo poškození systému znovu sestavte či obnovte celý server.
  • Obnova po bezpečnostním incidentu: ověřte, že lze identifikovat čisté verze z doby před ransomwarovým incidentem.

Výsledek každého testu zaznamenejte. Poznamenejte si, jak dlouho trval, jaké přihlašovací údaje byly potřeba, zda některé soubory chyběly a jaké odborné znalosti byly nutné. Test, který odhalí problém, je užitečný; dává firmě příležitost proces opravit ještě před skutečným výpadkem.

Testování by mělo probíhat po významných změnách infrastruktury a v pravidelných intervalech odpovídajících potřebám firmy. Měla by se ho účastnit i jiná osoba než ta, která zálohu nastavila. Pokud obnovu zná pouze jeden technik, může se nepřítomnost nebo odchod zaměstnance stát rizikem pro obnovu.

Doba obnovy je obchodní požadavek, nejen technická metrika

Cíl doby obnovy, neboli RTO, určuje, jak rychle musí být služba po incidentu dostupná. Malá kancelář může tolerovat den bez dokumentového serveru, zatímco agentura zajišťující živé kampaně pro zákazníky může potřebovat kritická projektová data mnohem dříve. Ne každý systém potřebuje stejné RTO.

Ptejte se, co se během výpadku stane, nejen jak dlouho trvá příkaz k obnově. Celková doba obnovy může zahrnovat:

  • Identifikaci incidentu a výběr čistého bodu obnovy.
  • Získání přístupu k zálohovací službě a šifrovacímu klíči.
  • Obnovu serveru, databáze nebo souborů.
  • Opětovnou instalaci aplikací, aktualizací a závislostí.
  • Kontrolu oprávnění, integrací a konzistence dat.
  • Ověření, že zaměstnanci mohou pracovat a zákazníkům lze poskytovat služby.

Pokud je odpovědí „vyřešíme to, až server selže“, je RTO neznámé. Tato nejistota může být nákladnější než samotná zálohovací služba.

Praktická kontrola záloh pro agentury a malé firmy

Pomocí následujících kontrol zhodnoťte nastavení, které v současnosti chrání vaše servery:

  1. Seznamte důležité systémy. Zahrňte fyzické servery, virtuální počítače, databáze, úložiště souborů, aplikační data a konfigurační soubory. Nepředpokládejte, že obraz serveru zahrnuje všechny externí závislosti.
  2. Pro každý důležitý systém si zapište RPO. Rozhodněte, kolik nedávné práce si firma může dovolit ztratit, a poté ověřte, zda tomu frekvence zálohování odpovídá.
  3. Stanovte RTO podle dopadu na podnikání. Určete, které služby se musí vrátit jako první a jaká dočasná řešení existují.
  4. Ověřte oddělení kopií. Potvrďte, že alespoň jedna kopie pro obnovu je mimo lokalitu a nezávisí na stejném hardwaru, místnosti, síti ani přihlašovacích údajích administrátora jako produkce.
  5. Zkontrolujte přístupová oprávnění. Zjistěte, zda by napadený účet serveru mohl zálohy číst, měnit nebo mazat.
  6. Potvrďte šifrování a vlastnictví klíčů. Zjistěte, kdo může data dešifrovat a jak by k nim oprávnění pracovníci v nouzi získali přístup.
  7. Prověřte retenci a verze. Ujistěte se, že retenční období pokrývá opožděné odhalení poškození, malwaru nebo náhodného smazání.
  8. Ověřte ochranu před smazáním. Hledejte neměnnost nebo jiné opatření, které útočníkovi brání vymazat body obnovy.
  9. Proveďte test obnovy. Obnovte skutečná data, změřte čas a zdokumentujte každý krok i problém.
  10. Určete odpovědnost. Jmenujte osoby odpovědné za sledování úloh, kontrolu upozornění, správu přihlašovacích údajů a vedení obnovy.

Tyto kontroly jsou užitečné i tehdy, když infrastrukturu spravuje externí IT poskytovatel. Majitel firmy je stále odpovědný za to, že ví, co je chráněno, jak rychle to lze obnovit a zda nastavení odpovídá smluvním nebo regulatorním povinnostem.

Kdy je vhodná spravovaná mimolokální zálohovací služba

Interní správa záloh může být rozumná, pokud má organizace potřebné znalosti, čas a nezávislou infrastrukturu pro sledování úloh, ochranu přihlašovacích údajů, správu retence, údržbu šifrovacích klíčů a testování obnovy. Náklady netvoří pouze úložiště. Zahrnují také postupy, dostupnost pracovníků, dokumentaci a pravidelné ověřování.

Spravovaná mimolokální služba je vhodná, pokud je obtížné tyto odpovědnosti soustavně plnit nebo pokud jsou důsledky ztráty serveru větší, než může organizace bez problémů absorbovat. Může nabídnout strukturovaný způsob ochrany serverů kontrolovaných firmou mimo primární prostředí a současně snížit množství zálohovací infrastruktury, kterou musí zákazník provozovat přímo.

Agentury by také měly zvážit, jak oddělují zákazníky a projekty, jak rychle potřebují obnovit sdílené aplikace a kdo je oprávněn obnovu schválit. Malé firmy by měly určit systémy, které jim umožňují obchodovat, a vyhnout se placení za neurčitý příslib ochrany bez kontroly rozsahu, retence a postupů obnovy.

Safenix je navržen pro servery kontrolované zákazníkem. Nejde o zálohovací plán pro web běžící na sdíleném hostingu, kde firma nekontroluje základní server ani konfiguraci záloh. Pokud je web hostován na sdíleném hostingu, jeho vlastník si musí ověřit, co poskytovatel hostingu chrání a zda je nutný nezávislý export nebo migrace do prostředí kontrolovaného zákazníkem.

Nastavte obnovitelnost jako standard

Otázka nezní pouze: „Proběhla záloha?“ Důkladnější kontrola zjišťuje, zda někde odděleně existuje čistá, aktuální a chráněná verze, zda ji útočník může smazat, zda je šifrovací klíč dostupný správným lidem a zda tým obnovu skutečně předvedl.

Jedna záložní kopie může být lepší než žádná, ale nejde o úplnou strategii ochrany. Oddělení mimo lokalitu, rozumná retence, verzování, šifrování pod kontrolou zákazníka, neměnnost a opakovatelné testování obnovy promění zálohovaná data ve skutečnou schopnost obnovy. To je standard, který by si agentury a malé firmy měly stanovit dříve, než incident učiní odpověď naléhavou.

Ready to deliver?

Start your 14-day free trial today.

Vyzkoušet zdarma