Proč se zálohy staly cílem ransomwaru, a ne záchrannou sítí
Po léta platilo, že záloha byla tou výjimkou, díky které se dal ransomware přežít: zašifrovat produkční prostředí, obnovit ze zálohy, jet dál. Útočníci se ale dotáhli. Ve studii Veeam 2025 Ransomware Trends, která oslovila 1,300 organizací zasažených útokem, mělo 89 % z nich napadená úložiště záloh jako součást útoku — nikoli jako vedlejší efekt, ale jako plnohodnotný cíl v rámci kill chainu. Zničení nebo poškození záchranné sítě ještě před zašifrováním produkčních dat je dnes standardním postupem, protože oběti tím útočník bere páku dřív, než vůbec dorazí výzva k výkupnému.
Projevuje se to na číslech o obnově. Zpráva Sophos State of Ransomware 2025 zjistila, že po útoku použilo zálohy k obnově dat jen 54 % organizací — nejnižší podíl za šest let, co se průzkum provádí. Mezi organizacemi, které nakonec zaplatily víc, než útočník původně požadoval, uvedlo 38 % jako důvod nefunkční nebo selhávající zálohy — jinou možnost prostě neměly. Záloha, která existuje na papíře, není totéž jako záloha, kterou lze pod tlakem čistě obnovit.
Tato propast mezi „máme zálohy" a „máme zálohy odolné vůči ransomwaru" stojí na třech pilířích: neměnnosti (immutability), izolaci a otestované obnově. Nejde o samostatné kontroly, které lze libovolně kombinovat. Když chybí byť jeden z nich, zbylé dva to nevykompenzují — neměnná záloha, na kterou útočník nedosáhne, je k něčemu jen tehdy, když se z ní skutečně dá obnovit, a dobře otestovaný plán obnovy je bezcenný, pokud byla záloha, na které stojí, smazána dřív, než cvičení vůbec začalo.
Všechny tři pilíře podrobně
1. Neměnnost: zálohy, na které útočník nesáhne
Neměnnost znamená, že zálohu nelze v rámci retenčního období změnit ani smazat — ať už špatně nastaveným retenčním skriptem, kompromitovaným administrátorským účtem, nebo útočníkem, který už získal přihlašovací údaje doménového správce. V praxi se prosazuje pomocí object locku na cloudovém nebo objektovém úložišti, hardwaru typu Write Once Read Many (WORM), nebo zabezpečeného linuxového úložiště (repository) s retenčními zámky vynucenými na úrovni úložiště, nezávisle na vlastních přístupových kontrolách zálohovací aplikace.
Na tomto rozlišení záleží, protože moderní provozovatelé ransomwaru aktivně vyhledávají úložiště záloh dostupná pomocí produkčních přihlašovacích údajů a smažou nebo zašifrují je jako první — ještě před primárními daty. Pokud stejný administrátorský účet, který spravuje váš zálohovací software, dokáže smazat i obnovovací body z minulého měsíce, neměnnost ve skutečnosti není zavedená — je to jen nastavení, které dostatečně privilegovaný útočník vypne během pár minut.
Doporučení CISA k ransomwaru je v tomto bodě jednoznačné: udržujte offline, šifrované a neměnné zálohy, pravidelně je ověřujte a berte je jako poslední linii obrany, ne jako první překážku, kterou musí útočník překonat.
2. Izolace: oddělená identitní rovina a kopie, na kterou útočník vůbec nedosáhne
Neměnnost chrání zálohu před změnou. Izolace chrání zálohu před tím, aby se k ní útočník vůbec dostal. Obě opatření se doplňují, nejsou zaměnitelná, a firmy, které zavedou jen jedno z nich, na tuto mezeru obvykle přijdou až během skutečného incidentu, ne při návrhové revizi.
Izolace má dvě složky. První je oddělená identitní rovina — zálohovací infrastruktura by neměla důvěřovat stejné doméně Active Directory, stejným administrátorským přihlašovacím údajům ani stejnému plochému síťovému segmentu jako produkce. Kompromitovaný řadič domény by automaticky neměl znamenat i kompromitované zálohovací prostředí; pokud to tak je, útočníkovi stačilo prolomit jen jednu věc, ne dvě. Druhou složkou je skutečně offline nebo air-gapped kopie — přinejmenším jedna kopie kritických dat, ke které z produkce nevede vůbec žádná trvalá síťová cesta, ať už je toho dosaženo rotací offline pásek, odpojeným replikačním cílem, který je online jen krátce při přijímání dat, nebo cloudovou vrstvou bez trvale uložených přihlašovacích údajů dostupných odkudkoli z produkčního prostředí.
Výzkum Veeam zjistil, že organizace, které dávají přednost tomuto vrstvenému, izolovanému přístupu k odolnosti, se z ransomwarových útoků zotavují až sedmkrát rychleji než ty, které tento přístup nemají, a to s výrazně nižší ztrátou dat po cestě. Právě izolace tento rozdíl umožňuje: je to rozdíl mezi útočníkem, který musí vynaložit skutečné dodatečné úsilí, aby se dostal k vašemu obnovovacímu bodu, a útočníkem, který k němu už má otevřenou relaci, protože sdílí identitní rovinu se systémy, které právě kompromitoval.
3. Otestovaná obnova: ověřte si obnovitelnost dřív, než ji budete potřebovat
Nejméně efektní z těchto tří pilířů je zároveň ten, který organizace nejčastěji přeskakují — a je to vidět na výsledcích. Podle oborového průzkumu z roku 2025 62 % organizací uvedlo, že pravidelně neprovádí testovací cvičení zálohování a obnovy, a 37 % uvedlo, že se jim nepodařilo obnovit data v rámci požadovaného cíle doby obnovy (RTO) právě proto, že zálohy chyběly nebo prostě nikdy nebyly ověřeny. Důvěra a realita se tu výrazně rozcházejí: víc než 60 % organizací věří, že dokáže obnovit provoz po výpadku do několika hodin, ale při skutečném testu se to podaří jen zhruba třetině.
Neotestované obnovy selhávají způsoby, které zůstanou neviditelné až do chvíle, kdy na nich nejvíc záleží: přerušené řetězce záloh, chybějící závislosti pro konzistenci aplikací, přihlašovací údaje servisních účtů, kterým vypršela platnost před měsíci, nebo runbooky napsané pro topologii infrastruktury, která už neexistuje. Přeskočení ověření navíc přináší ostřejší riziko než pouhý výpadek — odhaduje se, že 63 % organizací riskuje opětovné zavlečení infekce během obnovy, protože pod časovým tlakem přeskakují kontrolu integrity a antimalwarovou kontrolu, a fakticky tak obnoví stejný škodlivý kód, který výpadek způsobil.
Opravdový program otestované obnovy znamená plánovaná, plnohodnotná cvičení obnovy do izolovaného obnovovacího prostředí — nejen notifikace typu „úloha zálohování proběhla úspěšně" — ověřená vůči cílům RTO, které firma skutečně potřebuje, ne vůči číslům, která jen dobře vypadají v prezentaci.
Jak to vypadá, když všechny tři pilíře drží
Data Sophos z roku 2025 nabízejí užitečný protipříklad k hlavním statistikám: mezi organizacemi, kterým útočník skutečně zašifroval data, se 97 % z nich přesto podařilo data obnovit. Rozdíl mezi touto skupinou a malou menšinou, které se to nepodařilo, se téměř vždy dá vystopovat k tomu, že jeden ze tří pilířů byl v praxi slabší, než se na papíře zdálo — retenční zámek, který šlo obejít nesprávnou rolí, „oddělená" zálohovací síť, která přesto důvěřovala stejné doméně, nebo obnova, která nikdy nebyla skutečně nacvičena od začátku do konce.
Cena za to, když se to podcení
Tyto tři pilíře nejsou nějaký abstraktní seznam osvědčených postupů — přímo se promítají do toho, kolik ransomwarový incident stojí a jak dlouho trvá. Průměrné náklady na obnovu po ransomwarovém útoku, bez zaplaceného výkupného, se pohybují kolem $1.53 million. Pouze 53 % obětí se plně zotavilo do týdne; zbytek strávil v nějaké formě narušení provozu déle než sedm dní, přičemž výpadky, ztráta produktivity a práce spojená s reakcí na incident se den ode dne kumulovaly.
Stav zabezpečení záloh je jednou z mála proměnných v této rovnici, kterou má organizace plně pod kontrolou. To, zda první útočníkův krok proti vašemu úložišti záloh uspěje, nebo selže, určují výhradně rozhodnutí učiněná o měsíce dřív — ne během samotného incidentu. V okamžiku, kdy útočník získá přihlašovací údaje doménového správce a pátrá po vaší zálohovací platformě, jsou neměnnost, izolace a otestovaná obnova buď už zavedené, nebo nejsou; pod tlakem už není šance je dodatečně dobudovat.
Časté chyby, které potichu podkopávají všechny tři pilíře
V analýzách po incidentu se opakovaně objevuje několik vzorců:
- Zaměňování snapshotů za zálohy. Snapshot ve VMware je časový rozdíl (delta) uložený na stejném datastoru jako virtuální stroj, který chrání — není to nezávislá kopie. Neomezeně roste, zhoršuje výkon a zmizí v okamžiku, kdy zmizí i datastore. Snapshoty jsou pohodlná funkce pro krátkodobý rollback, ne strategie obnovy.
- Chápání „neměnnosti" jako zaškrtávacího políčka, a ne jako ověřené vlastnosti. Object lock a retenční politiky je nutné otestovat přímo proti té administrátorské roli, která spravuje zálohovací platformu — nestačí je jen zdokumentovat v konfiguračním manuálu.
- Označování druhé kopie ve stejné identitní doméně za „izolovanou". Pokud se stejnými přihlašovacími údaji, které byly kompromitovány v produkci, lze autentizovat i k úložišti záloh, geografické nebo platformové oddělení nepředstavuje skutečnou izolaci.
- Měření úspěchu podle dokončení zálohy, ne podle ověření obnovy. Zelená fajfka u včerejší úlohy vám řekne jen to, že se data někam zapsala. Neřekne vám, že jsou data obnovitelná, konzistentní na úrovni aplikace a bez malwaru, který obnovu vůbec vyvolal.
Kde přichází na řadu BackupSec
Ve společnosti BackupSec pomáháme firemním týmům provozovat jejich zálohovací prostředí přesně podle těchto tří pilířů — nenahrazujeme přitom jejich zálohovací platformu, ale děláme zabezpečení záloh pozorovatelné, poradensky podložené a prokazatelné.
Náš přístup kombinuje tři vrstvy:
- ZeroMON poskytuje průběžnou pozorovatelnost nad celým zálohovacím prostředím — monitoring připravený pro Veeam s real-time sledováním úloh, automatizovanými bezpečnostními kontrolami, forenzními auditními stopami pro odhalení configuration driftu a reporty o compliance na jedno kliknutí. Tato vrstva mění tvrzení „neměnnost je nakonfigurovaná" z předpokladu na doložený fakt.
- ZeroTAM poskytuje dedikované odborné poradenství pro architekturu záloh, návrh izolace a plánování obnovy po ransomwaru — lidskou vrstvu, kterou většina firem potřebuje k tomu, aby dokázala interpretovat, co jim jejich zálohovací prostředí ve skutečnosti říká, a navrhnout izolaci, která obstojí ve skutečném incidentu.
- ZeroPEN penetračně testuje vaši zálohovací infrastrukturu tak, jako by to dělal skutečný útočník — cílí na řídicí roviny, přístupové kontroly a nastavení neměnnosti — a následně spouští reálné scénáře obnovy, aby ověřil, že se dokážete obnovit čistě, kompletně a v rámci deklarovaného RTO, ne jen že úloha zálohování nahlásila úspěch.
BackupSec se nasazuje on-premise, k vašim zálohovacím aplikacím se připojuje přes API s přístupem pouze pro čtení a data záloh nikdy nepřesouvá mimo vaše prostředí.
Promluvte si se společností BackupSec o zabezpečení vašich záloh →
Chcete zjistit, jestli by vaše vlastní zálohy obstály? Ohodnoťte své prostředí pomocí bezplatného Backup Security Assessment.