Ransomware se už nespokojí pouze se zašifrováním produkčních souborů. Schopný útok hledá také systémy, které by mohly škody napravit: zálohovací servery, konzole pro správu, úložiště snapshotů a cloudová úložiště. Pokud útočníci dokážou tyto kopie před požadavkem na výkupné smazat nebo zašifrovat, organizace přichází o nejbezpečnější cestu zpět k běžnému provozu.
Neměnné zálohy řeší právě tuto slabinu. Vytvářejí body obnovy, které během stanovené retenční doby nelze změnit ani smazat, a to ani tehdy, když útočník získá vysoce privilegované přihlašovací údaje. Proto jsou klíčovou součástí ochrany před ransomwarem, samy o sobě však nepředstavují kompletní strategii obnovy. Stále záleží na šifrování, správě klíčů, řízení přístupu, monitorování a ověřených obnovách.
Pro firmy, které provozují vlastní servery, poskytuje Safenix zálohování mimo lokalitu s uložením dat v Německu. Zálohovaná data jsou šifrována klíčem, který Safenix nikdy nevlastní, a kopie jsou neměnné po dobu zvoleného retenčního období. Výsledkem je vrstva obnovy oddělená od produkčního prostředí a chráněná před neoprávněným smazáním. Safenix chrání servery spravované zákazníkem; neposkytuje zálohovací plány pro weby provozované na sdíleném hostingu.
Proč ransomware napadá zálohovací systémy
Mnoho organizací vnímá zálohu jako soubor souborů čekajících na obnovení. Útočníci v ní však vidí něco cennějšího: mapu odolnosti firmy. Jakmile získají přístup k účtu správce serveru, virtualizační platformě, zálohovací konzoli nebo privilegované cloudové identitě, mohou zjistit, kde jsou kopie uložené a jak dlouho se uchovávají.
Průběh útoku často zahrnuje několik fází:
- Odcizení nebo uhádnutí přihlašovacích údajů privilegovaného uživatele.
- Vypnutí ochrany koncových bodů a monitorování.
- Přesun z původního systému na souborové servery, databáze a virtualizační hostitele.
- Vyhledání zálohovacího softwaru, úložišť, snapshotů a servisních účtů.
- Smazání bodů obnovy nebo zkrácení jejich retenčního nastavení.
- Zašifrování produkčních dat a všech zbývajících dostupných záložních kopií.
- Požadavek na platbu s tvrzením, že bez klíče útočníka není obnova možná.
Zálohovací úložiště, které je pouze připojené ke stejnému systému identit nebo síti, proto může být ohrožené, i když se nachází na samostatném hardwaru. Fyzické oddělení pomáhá, ale automaticky neznamená, že je kopie bezpečná. Pokud napadený správce může vydat příkaz ke smazání, může úložiště selhat právě ve chvíli, kdy je potřeba.
Ochrana před ransomwarem musí počítat s možností, že útočník získal přístup na úrovni správce. Otázkou není jen to, zda se k zálohovacímu systému dostanou neoprávnění uživatelé. Jde o to, zda může kdokoli – včetně legitimního, ale napadeného účtu – odstranit poslední čistý bod obnovy.
Čemu neměnné zálohy skutečně brání
Neměnná záloha je bod obnovy chráněný před úpravou nebo smazáním po stanovenou dobu. Během tohoto období nelze data běžnými administrátorskými operacemi přepsat, změnit ani odstranit. Ochrana se vztahuje na uložený objekt nebo záznam zálohy, nespoléhá pouze na zásadu, která správci říká, aby jej nemazal.
Neměnnost je nejlepší chápat jako mechanismus vynucení. Retenční politika říká, že kopie má zůstat dostupná 30, 90 nebo 365 dní. Neměnná retenční politika tento požadavek technicky ztěžuje nebo znemožňuje obejít před koncem dané lhůty. Tento rozdíl je rozhodující při odcizení přihlašovacích údajů.
Představme si, že firma má denní zálohy s devadesátidenní retencí. Pokud útočník získá přístup k zálohovací konzoli a změní nastavení na jeden den, neposkytla politika v praxi žádnou ochranu. Pokud jsou stejné body obnovy uzamčeny proti smazání až do data expirace, změna nastavení v konzoli uzamčené objekty neodstraní.
Neměnnost neznamená, že každá záloha zůstane trvalá. Po uplynutí retenční doby se kopie obvykle stanou způsobilými ke smazání. Nezaručuje také, že data lze použít. Poškozená databáze, neúplná záloha aplikace nebo neověřený postup obnovy mohou stále vést k selhání obnovy. Neměnné úložiště chrání existenci a integritu kopie, automaticky však neověřuje její obsah.
Neměnnost versus běžná retence
Běžná retence je plán. Určuje, kolik bodů obnovy má zálohovací systém uchovávat a kdy lze starší body odstranit. Tento plán je nezbytný pro řízení nákladů na úložiště, může jej však ovládat stejná konzole a stejné účty správce, na které cílí útočník.
Neměnná retence k tomuto plánu přidává technické omezení. Jakmile je kopie potvrzena, nelze ji smazat před vypršením zámku. Dobré řešení odděluje rozhodnutí o retenci od každodenní správy záloh, aby napadený operátor nemohl po zahájení incidentu zkrátit ochranné období.
Obě kontroly spolupracují:
- Retence určuje, jak daleko do minulosti chce organizace obnovovat.
- Neměnnost zabraňuje odstranění nebo změně chráněné kopie před tímto okamžikem.
- Verzování může uchovávat více stavů obnovy namísto jedné průběžně aktualizované kopie.
- Testování obnovy potvrzuje, že uchovávaná data lze skutečně použít k obnově.
Neměnnost není totéž co offline kopie
Offline záloha je odpojená od produkčních systémů, sítí nebo administrativních rozhraní. To může být velmi účinné, protože ransomware nemůže přímo zašifrovat ani smazat kopii, ke které nemá přístup. Tradičním příkladem je páska uložená mimo síť. Vyjímatelný disk, který se pro zálohování pravidelně znovu připojuje, poskytuje menší ochranu, pokud zůstane během útoku připojený.
Offline a neměnné úložiště řeší související, ale odlišné problémy. Offline kopie snižují útočnou plochu odstraněním konektivity. Neměnné kopie zůstávají dostupné pro automatické zálohování a obnovu, zároveň však během období zámku blokují změny. Odolné řešení může využívat obojí, zejména pokud požadavky na obnovu ospravedlňují provozní náročnost.
Existují zde kompromisy. Plně offline média mohou ztížit časté zálohování, monitorování i rychlou obnovu. Někdo musí média střídat, fyzicky chránit, evidovat dostupnou verzi a zajistit, že ji bude možné v případě potřeby přečíst. Neměnné online nebo externí úložiště se může provozovat snadněji, musí však být řádně oddělené od napadených identit a systémů správy.
Důležité je neoznačovat každou odpojenou kopii automaticky za bezpečnou. Offline disk se může ztratit, poškodit, být infikován ještě před odpojením nebo omylem přepsán. Stejně jako každá jiná záloha potřebuje evidenci, omezení přístupu a testy obnovy.
Úložiště s řízeným přístupem není automaticky neměnné
Omezení přístupu k úložišti je nezbytné, samo o sobě však smazání nezabrání. Správce může být jedinou osobou s přístupem k úložišti a přesto mít oprávnění vymazat všechny body obnovy. Pokud je tento účet napaden, stává se kontrola schopností útočníka.
Princip nejmenších oprávnění je proto třeba uplatňovat ve vrstvách. Účet, který zapisuje zálohy, nemusí mít možnost je mazat. Účet spravující zálohovací úlohy nemusí mít možnost měnit zámky retence. Osoba schvalující obnovu by neměla automaticky získat přístup k šifrovacím klíčům nebo konfiguraci úložiště.
Vícefaktorové ověřování, oddělené administrátorské identity, síťová omezení a schvalovací procesy snižují pravděpodobnost, že se z odcizeného hesla stane úplný průnik. Jde o důležité ochranné prvky, nenahrazují však neměnnost. Útočník může jednu kontrolu obejít prostřednictvím zranitelného koncového bodu, odcizeného tokenu relace nebo sociálního inženýrství. Uzamčený bod obnovy poskytuje ochranu poté, co preventivní kontroly selhaly.
Object Lock, WORM a izolovaná úložiště
Neměnné zálohy lze implementovat několika způsoby. Terminologie se mezi produkty liší, principy návrhu jsou však stejné: zapsat data do chráněného umístění, nastavit retenční období a zabránit smazání nebo změně až do jeho konce. Firmy by měly rozumět tomu, co je skutečně uzamčeno, kdo může zásady měnit a zda může správce zámek zkrátit.
Úložiště s Object Lock
Object Lock se běžně používá s objektovými úložišti. Každý objekt zálohy obdrží časové razítko retence a služba úložiště odmítne požadavky na smazání nebo přepsání před tímto okamžikem. Některé implementace nabízejí režim governance, který umožňuje autorizované výjimky, a přísnější režim compliance, jenž je navržen tak, aby těmto výjimkám zabránil, a to i ze strany správců.
Toto rozlišení je důležité. Zámek ve stylu governance může stačit proti běžným provozním chybám, ale nemusí být vhodný, pokud model hrozeb zahrnuje odcizenou identitu správce. Přísnější režim poskytuje silnější ochranu, vyžaduje však pečlivé plánování retence, protože chyby nelze napravit prostým smazáním objektu.
Object Lock může dobře fungovat u velkých úložišť a automatizovaných zálohovacích procesů. Stále je nutné chránit účet úložiště, přístupové údaje k API, konfiguraci bucketu, nastavení replikace a logování. Útočník možná nebude moci smazat uzamčené objekty, může se však pokusit zastavit nové zálohy, změnit plán úloh nebo napadnout vrstvu správy.
Úložiště WORM
WORM znamená write once, read many, tedy zapsat jednou a číst mnohokrát. Systém WORM umožňuje data zapsat a číst, ale během ochranného období brání jejich změně nebo odstranění. WORM může být implementován v objektovém úložišti, specializovaných zařízeních nebo jiných úložných architekturách.
WORM je užitečný popis chování úložiště, nikoli záruka, že každý produkt používající tento pojem nabízí stejnou úroveň zabezpečení. Zeptejte se, zda retenční dobu vynucuje úložná vrstva, zda ji může správce obejít, jak systém řeší změny času a co se stane při selhání kapacity nebo replikace.
Izolovaná zálohovací úložiště
Izolované úložiště odděluje zálohovaná data od produkční sítě, adresáře identit a vrstvy správy. Izolace může být fyzická, logická nebo obojí. Může zahrnovat samostatný účet, oddělené přihlašovací údaje, omezené síťové trasy, jednosměrnou cestu pro zálohy a vyhrazený administrativní proces.
Izolace je obzvlášť cenná, když zákazník provozuje více serverů nebo lokalit. I když je jedno produkční prostředí napadeno, útočník by neměl automaticky získat přístup ke všem úložištím. Úložiště by mělo mít pouze oprávnění potřebná k přijímání a poskytování záloh, zatímco mazání a změny retence by měly chránit oddělené kontroly.
Praktické srovnání těchto přístupů včetně konceptů neměnných záloh a ochrany před ransomwarem najdete v aktuálních doporučeních k přístupům k neměnným zálohám pro ochranu před ransomwarem a v technické dokumentaci zvažované úložné platformy.
Proč záleží na šifrování a správě klíčů
Neměnnost brání útočníkovi zálohu smazat nebo změnit. Šifrování chrání její obsah, pokud někdo získá přístup k úložišti, zkopíruje data nebo pronikne k základní infrastruktuře. Obě kontroly jsou nezbytné, protože záloha, která přežije ransomware, ale odhalí mzdové, zákaznické, právní nebo zdravotní informace, vytváří jiný bezpečnostní incident.
Šifrování by mělo pokrývat data při přenosu i data v klidu. Zálohovací agent by měl data odesílat chráněným připojením a uložená zálohovaná data by měla v úložišti zůstat zašifrovaná. Šifrování snižuje hodnotu odcizeného úložiště, pouze pokud jsou klíče spravovány odděleně od dat a nejsou dostupné každému správci s přístupem k zálohovací platformě.
Správa klíčů si zaslouží zvláštní pozornost. Pokud poskytovatel služby drží jediný použitelný dešifrovací klíč, mohl by průnik do jeho systémů nebo neoprávněné interní jednání data odhalit. Pokud klíč ovládá zákazník, získává větší kontrolu nad důvěrností, zároveň však odpovídá za jeho ochranu a za udržení funkčního procesu obnovy.
Safenix používá šifrovací klíče řízené zákazníkem, které Safenix nikdy nedrží. Tento přístup pomáhá oddělit roli poskytovatele úložiště od schopnosti zákazníka dešifrovat vlastní data. Firmy, které tento model zvažují, si mohou přečíst informace o šifrování Safenix a přístupu s klíčem drženým zákazníkem a následně ověřit, jak bude v jejich prostředí fungovat generování, zálohování, obměna, přístup a nouzová obnova klíčů.
Správa klíčů by měla být zdokumentována ještě před incidentem. Rozhodněte, kdo může ke klíči přistupovat, jak se přístup schvaluje, kde je uložena nouzová kopie a jak bude organizace postupovat, pokud obvyklý správce klíče nebude dostupný. Ztracený klíč může způsobit, že jinak neporušená neměnná záloha nebude obnovitelná.
Návrh retenční doby záloh pro obnovu po ransomwaru
Na otázku, jak dlouho by se měly neměnné zálohy uchovávat, neexistuje univerzální odpověď. Správné období závisí na rychlosti odhalení útoku, době, po kterou může útočník zůstat nepozorován, právních a smluvních povinnostech organizace a čase potřebném k vyšetření a obnově systémů.
Krátké retenční období může stačit malému prostředí s rychlou detekcí a nízkou složitostí dat. Pro organizaci, v níž může napadení zůstat skryté několik týdnů, však může být nebezpečné. Pokud jsou zašifrované nebo pozměněné soubory součástí denních záloh po dobu 30 dní před odhalením, třicetidenní neměnné období nemusí zachovat žádný čistý bod obnovy.
Faktory, které by měly ovlivnit retenční období
- Doba detekce: Odhadněte, jak dlouho může trvat odhalení neobvyklého šifrování, zneužití účtu nebo tichého poškození dat.
- Doba vyšetřování: Uchovávejte čisté body dostatečně dlouho, aby bylo možné útok analyzovat bez zničení důkazů nebo obnovy z kontaminovaného období.
- Doba obnovy: Zahrňte čas potřebný k obnově infrastruktury, ověření aplikací a postupné obnově dat.
- Dopad na podnikání: Kritické systémy mohou ospravedlnit delší retenci a častější body obnovy.
- Shoda s předpisy a smlouvy: Některé záznamy vyžadují delší uchování, zálohovací retence by však neměla být považována za kompletní politiku správy záznamů.
- Náklady na úložiště: Delší retence spotřebuje více úložného prostoru, proto používejte úrovně nebo plány odpovídající hodnotě a rychlosti změn jednotlivých úloh.
Užitečným přístupem je kombinovat provozní zálohy v krátkých intervalech s dlouhodobějšími body obnovy. Organizace může například uchovávat časté aktuální kopie pro rychlou obnovu, denní kopie po několik týdnů a vybrané týdenní nebo měsíční body po delší dobu. Přesný plán by měl vycházet z cílů obnovy, nikoli z výchozího nastavení.
Nenechte retenci vypršet, pokud incident stále probíhá. Po odhalení podezření na napadení zachovejte relevantní neměnné body a prodlužte nebo samostatně exportujte potřebná data pro forenzní práci a obnovu podle možností daného návrhu úložiště. Tým řešící incident by měl vědět, které kopie jsou uzamčené a kdy jejich platnost skončí.
Obnova po odcizení přihlašovacích údajů správce
Odcizené přihlašovací údaje neměnné zálohy automaticky neporazí. Pokud útočník získá přístup k zálohovací konzoli, ale body obnovy jsou v úložišti uzamčené, může být schopen zastavit budoucí úlohy nebo narušit provoz, aniž by chráněné kopie smazal. Toto oddělení je jedním z hlavních důvodů pro používání neměnného úložiště.
Reakce však musí být okamžitá a systematická:
- Izolujte napadené systémy. Pokud je to praktické, odpojte napadené servery nebo síťové segmenty. Nedovolte útočníkovi pokračovat v šifrování dat nebo přístupu k dalším systémům.
- Deaktivujte a obměňte přihlašovací údaje. Zneplatněte odcizené relace, resetujte privilegovaná hesla a obměňte servisní přihlašovací údaje. Zkontrolujte API klíče, tokeny a účty s přístupem k úložištím nebo šifrovacím systémům.
- Chraňte zálohovací prostředí. Omezte přístup ke konzoli, zablokujte podezřelé zdrojové adresy, zkontrolujte administrativní změny a potvrďte, že zámky retence zůstaly aktivní.
- Zastavte destruktivní automatizaci. Pozastavte úlohy nebo integrace, které by mohly přepsat čistá data, a přitom zachovejte již potvrzené neměnné kopie.
- Určete poslední známý čistý bod. Pomocí logů, důkazů z koncových bodů a kontrol aplikací zjistěte, kdy napadení začalo. Nepředpokládejte, že nejnovější záloha je bezpečná.
- Obnovte důvěryhodnou infrastrukturu. Základní prvky identity, sítě a správy obnovte ze známých čistých zdrojů, nikoli opětovným použitím napadených systémů.
- Obnovujte v kontrolovaném prostředí. Nejprve obnovte reprezentativní systém, prověřte jej, ověřte konfiguraci a potvrďte správné fungování aplikací a dat.
- Dokumentujte rozhodnutí a důkazy. Zaznamenejte použitý bod obnovy, osobu, která jej schválila, obnovené položky a nalezené indikátory napadení.
Obnovu nikdy netestujte přímým obnovením přes jedinou zbývající produkční kopii. Pokud je to možné, použijte izolovanou síť nebo samostatné cílové umístění. Zabráníte tak tomu, aby poškozená nebo napadená záloha poškodila čisté prostředí, a poskytnete týmu prostor pro bezpečné ověření obnovy.
Testování obnovy je součástí zabezpečení záloh
Neměnná kopie, kterou nelze obnovit, je nákladný archiv, nikoli spolehlivý plán obnovy. Zálohovací úlohy mohou hlásit úspěch, přesto mohou vynechat databázi aplikace, nezahrnout potřebný konfigurační soubor, selhat při zachycení konzistentního stavu nebo vytvořit obnovu s nevyřešenými závislostmi.
Testování obnovy by mělo probíhat pravidelně a odpovídat systémům, které firma skutečně potřebuje. Test na úrovni souborů je užitečný, nepotvrzuje však, že lze znovu spustit celou aplikaci. Testujte několik typů obnovy:
- Obnovte jednotlivé soubory a ověřte oprávnění, vlastnictví a časová razítka.
- Obnovte databázi a ověřte transakce aplikace a indexy.
- Obnovte kompletní server nebo virtuální počítač do izolovaného prostředí.
- Obnovte kritickou službu, pokud původní infrastruktura není dostupná.
- Ověřte, že šifrovací klíče jsou dostupné a použitelné autorizovanými pracovníky obnovy.
- Změřte délku obnovy a porovnejte ji s cílem obnovy stanoveným pro podnikání.
S testovacími daty zacházejte opatrně. Prostředí obnovy může obsahovat osobní nebo důvěrné informace, proto potřebuje vhodné řízení přístupu a postupy pro likvidaci dat. Uchovávejte písemné záznamy o výsledcích testů, selháních a nápravných opatřeních. Test, který odhalí chybějící závislost, je užitečný pouze tehdy, pokud se návrh zálohování následně změní.
Alespoň jedno cvičení by mělo simulovat ztrátu produkčního prostředí i zálohovací konzole. Ověříte tím, zda organizace dokáže najít chráněné kopie, autentizovat se u služby obnovy, získat přístup ke klíčům řízeným zákazníkem a obnovit data bez závislosti na napadeném serveru správy.
Monitorování a nejmenší oprávnění u neměnných kopií
Neměnnost snižuje dopad pokusů o smazání, monitorování však pomáhá útok odhalit ještě předtím, než bude obnova nutná. Sledujte změny frekvence zálohování, neobvyklé objemy dat, neúspěšné úlohy, nové správce, změny retenčních zásad, přístupy z neznámých míst a náhlé pokusy o procházení úložišť.
Upozornění by měla dostávat i lidé, kteří nejsou závislí pouze na potenciálně napadeném produkčním prostředí. Pokud ransomware vyřadí e-mail nebo monitorovací nástroje, oznámení o selhání zálohy doručené pouze prostřednictvím těchto nástrojů nemusí nikdo vidět. Chraňte logy před změnami a uchovávejte dostatečnou historii, abyste mohli zjistit, kdo ke službě zálohování přistupoval a o co se pokoušel.
Nejmenší oprávnění pravidelně kontrolujte, nikoli pouze jednou nastavte a zapomeňte na ně. Odstraňujte neaktivní účty, oddělujte lidské a servisní identity, omezte zdrojové sítě s přístupem k rozhraním správy a vyžadujte vícefaktorové ověřování privilegovaného přístupu. Pokud je to možné, používejte oddělené přihlašovací údaje pro zápis záloh, obnovu, správu a řízení retence.
Nedávejte aplikačnímu serveru rozsáhlé oprávnění k mazání dat v úložišti. Napadený server by měl mít možnost odeslat data potřebná k jeho zálohování, nikoli spravovat celé zálohovací prostředí. Stejný princip platí pro agentury spravující více zákaznických prostředí.
Ochrana více zákaznických prostředí bez zbytečného komplikování obnovy
Agentury, poskytovatelé řízených služeb a IT týmy často potřebují chránit několik firem současně. Centralizace může zlepšit konzistenci, zároveň však může vytvořit cenný cíl. Pokud jeden sdílený účet správce nebo jedna konzole řídí všechna zákaznická úložiště, může jediný odcizený údaj ohrozit celé portfolio.
Bezpečnější model pro více zákazníků odděluje tenanty, přihlašovací údaje, zásady a oprávnění k obnově. Každé zákaznické prostředí by mělo mít vlastní logickou hranici a jasné vlastnictví šifrovacích klíčů. Technik, který potřebuje obnovit server jednoho klienta, by neměl automaticky moci procházet nebo mazat zálohy jiného klienta.
Provozní jednoduchost je stále důležitá. Nadměrné oddělení může obnovu zpomalit nebo znepřehlednit, zejména během rozsáhlého incidentu. Agentury by měly pro každého klienta udržovat přehledný katalog služeb obsahující:
- Chráněné servery a aplikace.
- Frekvenci zálohování a retenční období.
- Stav neměnného úložiště a data expirace.
- Vlastnictví šifrovacích klíčů a postup nouzového přístupu.
- Schválené kontakty pro obnovu a požadavky na autorizaci.
- Priority obnovy a závislosti mezi systémy.
- Poslední úspěšný test obnovy a nevyřešené problémy.
Pro podobné úlohy používejte standardní zásady, výjimky však uvádějte výslovně. Malý souborový server, databázový cluster a řadič domény mohou potřebovat odlišné plány a pořadí obnovy. Šablony pomáhají předcházet opomenutím, neměly by však nahrazovat testování podle konkrétní úlohy.
Agentury by měly také procvičit scénář izolace klienta. Předpokládejte, že účet správce jednoho zákazníka je napaden, a ověřte, zda tým pro řešení incidentu dokáže pozastavit přístup tohoto tenanta bez přerušení ostatních. Poté proveďte obnovu pomocí správného klíče klienta, schvalovací cesty a cílového umístění. Tím potvrdíte, že bezpečnostní hranice nevytvářejí provozní slepou uličku.
Časté chyby oslabující ochranu neměnných záloh
Uchovávání jediné zálohy na produkčním serveru
Lokální záloha může být rychlá a užitečná, sdílí však rizika produkčního serveru. Proces ransomwaru s oprávněními správce může zašifrovat živé soubory i místní adresář se zálohou. Selhání hardwaru, požár nebo krádež mohou rovněž odstranit obě kopie najednou. Lokální zálohy by měly podporovat rychlou obnovu, nikoli sloužit jako jediná vrstva obnovy.
Předpoklad, že snapshoty jsou neměnné
Snapshoty jsou praktické body v čase, mnoho z nich však může smazat stejný správce, který ovládá produkční platformu. Některé snapshoty jsou navíc ransomwaru vystaveny prostřednictvím připojených svazků nebo zděděných oprávnění. Snapshot považujte za neměnný pouze tehdy, pokud základní úložiště vynucuje zámek, který příslušní správci nemohou obejít.
Používání jediného účtu pro všechno
Jeden účet, který vytváří úlohy, mění retenci, maže data a spravuje šifrování, má příliš velkou moc. Ztěžuje také vyšetřování, protože neexistuje smysluplné oddělení povinností. Používejte vyhrazené identity a dokumentujte, jaké akce může každá z nich provádět.
Ignorování procesu obnovy klíčů
Šifrování řízené zákazníkem je účinné pouze tehdy, když zákazník dokáže klíč v nouzové situaci získat a použít. Pokyny pro obnovu bezpečně uchovávejte, přístup testujte s autorizovanými pracovníky a plánujte pro případ nepřítomnosti zaměstnanců. Neumisťujte nechráněnou kopii klíče vedle zálohovacího úložiště.
Testování pouze při problému
Nouzová situace je nejhorší chvílí pro zjištění, že zálohovací agent vynechal databázi, přihlašovací údaj vypršel nebo cílové umístění obnovy nemá dostatečnou kapacitu. Testy plánujte a neúspěšné testy považujte za bezpečnostní zjištění s určenými vlastníky a termíny.
Praktický kontrolní seznam zabezpečení neměnných záloh
Při kontrole stávajícího návrhu zálohování nebo hodnocení externí služby si položte následující otázky:
- Může ransomware běžící s oprávněními produkčního správce smazat uložené body obnovy?
- Vynucuje zámek retence úložná vrstva, nikoli pouze nastavení v zálohovací konzoli?
- Může správce zkrátit nebo obejít dobu zámku?
- Jsou zálohy uloženy mimo produkční síť a systém identit?
- Jsou data při přenosu i v klidu šifrována?
- Kdo drží šifrovací klíč a může jej organizace obnovit, pokud správce klíče nebude dostupný?
- Jsou oddělena oprávnění k zálohování, obnově, mazání a správě zásad?
- Je pro privilegovaný přístup zapnuto vícefaktorové ověřování?
- Monitorují se změny, neúspěšné úlohy a podezřelé pokusy o přístup?
- Zohledňuje retenční období pravděpodobnou dobu setrvání ransomwaru v organizaci?
- Byly testovány kompletní obnovy aplikací, nejen jednotlivé soubory?
- Může organizace obnovit data, pokud byla produkční zálohovací konzole napadena?
- Jsou u více klientů odděleni tenanti, přihlašovací údaje, klíče a oprávnění k obnově?
Neměnné zálohy jsou základem, nikoli celým plánem obnovy
Odolnost vůči ransomwaru závisí na vrstvách. Ochrana koncových bodů, záplatování, zabezpečení identit, segmentace sítě a informovanost zaměstnanců snižují pravděpodobnost napadení. Neměnné zálohy mimo lokalitu omezují škody, když tyto kontroly selžou. Šifrování a klíče řízené zákazníkem chrání důvěrnost. Monitorování odhaluje podezřelou aktivitu. Testování obnovy mění uložená data ve skutečně použitelnou schopnost obnovy.
Nejdůležitější rozdíl spočívá mezi zálohou, která existuje, a bodem obnovy, který zůstane dostupný během útoku. Běžná retence, úložiště chráněné přístupovými právy nebo snapshot na produkční platformě nemusí přežít napadení správce. Neměnné úložiště je navrženo právě pro tento scénář selhání: zachová body obnovy po dohodnuté retenční období, i když se je někdo s odcizenými přihlašovacími údaji pokusí smazat.
Firmám, které spravují vlastní servery, může návrh zálohování mimo lokalitu s šifrováním, klíči drženými zákazníkem, uložením dat v Německu a neměnností poskytnout silnou nezávislou vrstvu obnovy. Ochranná opatření je třeba pravidelně kontrolovat a testovat, protože neměnné úložiště nenahrazuje ověřené obnovy. Umožňuje důvěryhodnou obnovu; disciplinovaná praxe obnovy prokazuje, že bude fungovat.