Zálohování – jak nepřijít o data při útoku hackera (teorie)

Možná si říkáte, jak souvisí zálohování s počítačovou bezpečností? Zálohování (pokud jej tedy neuděláte špatně) nemá vliv na odolnost vaší sítě proti hackerům a virům. Pokud však vaši síť již jednou napadnou, budou to zálohy, které vás musí podržet. Chtěl bych se s vámi podělit o to, jak jsme uvažovali nad návrhem vhodného zálohování pro naše zákazníky a co jsme nakonec zavedli.

Jaké otázky jsme si kladli

Stejně jako antivirus, tak ani zálohování u nás nemělo úplný řád. Zákazníci používali různý software, jiné destinace pro zálohy, jiné časy zálohování a zálohy byly různě odolné proti ztrátě dat. To bylo ještě v půlce roku 2015. V rámci standardizace (důvody a přínosy viz: „Standardizace – děláme IT jako Baťa cvičky“) jsme vše nakonec sjednotili a vytvořili si best practices pro zálohování.

Při návrhu našeho finálního řešení jsme si kladli dále uvedené otázky. U otázek samozřejmě záleží, jaké máte prostředí: počet serverů, množství dat, kde jsou data uchována a jaké jsou rychlosti sítě. Jinak budete navrhovat zálohování pro firmu, která má velké archivy poměrně neměnných dat na jednom místě a jinak pro firmu, která má převážně aplikační servery s databázemi rozmístěnými v různých lokalitách. Typ zákazníka, na kterého jsme řešení navrhovali, je firma o maximálně desítkách serverů a objemu dat do pár desítek terabajtů. Na svých serverech mají jak běžné sdílené složky, tak i různé informační systémy.

Jak rychle obnovíme svá data? (Recovery time objective) (vlastnost zajímající zákazníka)

Naším cílem je (v případě ztráty/poškození dat) data obnovit co nejrychleji. Během obnovy dat totiž zákazník může pracovat pouze částečně nebo vůbec a stojí jej to nemalé peníze (v závislosti na jeho velikosti a systémech, co mu nefungují). Při zamýšlení se nad rychlostí obnovy, si představuji hlavně následující dvě události.

Částečná ztráta dat, kdy si uživatel například smaže omylem jeden soubor/adresář. Běžně je tato obnova rychlá – ztracená část dat se obnoví ze zálohy a je v celku jedno, jakou máte zálohovací technologii. V každém případě je nutné si obnovu v prostředí i zkusit, aby se vychytaly případné okolnosti, které člověka nenapadnou (například úzké hrdlo na síti, nebo pomalé zálohovací úložiště, protože jsou zálohy uložené v 30 inkrementech).

Úplná ztráta dat na serveru nebo síti způsobená například selháním HW serveru, napadením cryptovirem nebo hackerem). Obnovení zabere více času, protože se jedná o větší množství dat než v případě částečné obnovy. Hlavně záleží na zálohovací technologii. Pokud se budou zálohovat pouze selektivně data bez systému (např. přes Cobain Backup), bude obnova znamenat: nainstalovat podkladový OS, aktualizace, ovladače, samotný informační systém a pak až do něj obnovit data. Celé to může zabrat i několik dní, zvláště když potřebujete spolupráci dodavatele IS (který v extrémních případech již ani neexistuje nebo nechce spolupracovat). Proto je třeba volit zálohovací SW, který zálohuje celé disky/oddíly (včetně systému) a umí případně udělat obnovu do odlišného HW (jiné velikosti disků, řadič disku atd.). Opět ideální je si na nečisto otestovat.

Jak staré jsou naše zálohy? (Recovery point objective) (vlastnost zajímající zákazníka)

Některým našim malým zákazníkům tolik nevadí, když přijdou o tři dny práce, data si prostě zadají znovu. Pro jiné zákazníky by byl problém přijít i o hodinu práce, protože už nikdo nedá dohromady, jaké změny se v systému za hodinu provedly (bylo by to moc drahé, nebo by se změny nedaly dohledat). Potřebovali jsme tedy řešení, které by nám umožnilo zálohovat jak jednou denně (minimum pod které nechceme jít), tak i několikrát za den.

Při plánování četnosti záloh je nutné myslet na to, že při jakémkoliv zálohování (kromě snapshotů) dochází k zatížení zálohovaného serveru (po celou dobu jsou zatížené disky a na začátku může dojít i ke krátkým zpožděním kvůli tvorbě VSS kopie).

Jsou zálohy odolné vůči selhání jedné technologie? (Pravidlo 3-2-1) (vlastnost zajímající nás)

Co se stane, když bude chyba v nějakém zálohovacím SW a data budou v zálohách špatně uložená? Co když se rozbije celý server, dostaneme se k zálohám? A co když serverovnu vytopí prasklé potrubí/nebo zničí požár?

Ideální je dodržovat pravidlo zálohování 3-2-1. Tzn. mít minimálně 3 kopie dat (včetně produkční „kopie“) na 2 různých zařízeních/technologiích a 1 kopii mít offsite (v jiné lokalitě než zbylé dvě). Pravidlo bych rozšířil i o to, aby se použil více jak jeden zálohovací SW (člověk nikdy neví, kdy se v nějakém zálohovacím SW objeví chyba).

Jsou zálohy odolné vůči virům a hackerům? (vlastnost zajímající nás)

Co když někdo prolomí naši síť (virus nebo hacker)? Nedostane se i k zálohám, které by smazal? Cryptovirus se moc neptá a šifruje vše, co mu přijde pod ruku, včetně záloh (externí USB disk není řešení – viz. Ransomware 2: Zaplatit výkupné nebo data nemít?). Je důležité, aby zálohy byly od produkčního prostředí co nejvíce oddělené. Ideálně aby nešlo zálohy smazat/změnit.

Zálohy jsou tak důležité, že je nutné být i paranoidní (viz Nejčernější hrozba, které se v IT bezpečnosti bojím) a počítat s nepravděpodobnými událostmi. Ztráta produkčních dat spolu se zálohami může znamenat konec pro spoustu firem a škody mohou být stamiliónové! Věřím, že s tímhle vědomím nechce nikdo usínat. Proto je nutné začlenit do zálohování i nějaké offline, nebo cloudové zálohy.

Ideální je si občas udělat i archivní zálohu (např. 1x za půl roku) a tu zálohu si někam založit. Mohlo by se totiž stát, že by nějaký trpělivý útočník záměrně znehodnocoval vaše zálohy. Např. data by byla v produkčním prostředí transparentně šifrovaná (čehož byste si nevšimli), vy byste zálohovali zašifrovaná data a až by se vám protočily všechny zálohy (tzn. měli byste už jen zálohy s šifrovanými daty), tak by útočník smazal „šifrovací klíč“.

Další věci, které brát v potaz

Zálohy se ještě odlišují podle konzistence (inconsistent, crash-consistent a application-consistent).  Zjednodušeně řečeno jde o to, jestli jsou ta zálohovaná data nepoškozená a úplná (např. jestli nejsou v paměti nějaké nezapsané změny). Krásně popsané je to třeba v článku „VSS Crash-Consistent vs Application-Consistent VSS Backups“. Nám jde o to, abychom měli vždy „application-consistent“ zálohy (stejný stav, jako kdybychom server před zálohováním korektně vypnuli a pak data zálohovali). Žít se dá i s „crash-consistent“ zálohami (jako kdybychom server natvrdo vypnuli a pak data zálohovali). „Inconsistent“ zálohy jsou spíše loterií.

Dalším důležitým bodem je pravidelně testovat obnovu dat/systémů ze záloh a mít plán obnovy. V okamžiku ztráty dat, musíte mít jistotu, že se můžete na zálohy spolehnout a že víte, jaký má být postup obnovy. Je pozdě a stresující teprve v tu chvíli začít vymýšlet, v jakém pořadí servery obnovíte, kde jsou recovery média a ovladače.

Věcí, kterou v tomto článku neřeším je „důvěrnost“ záloh. Zatím pro to nemáme bohužel žádné standardizované řešení (řešíme případ od případu). Když se budete chtít někdo podělit o to, jak to řešíte vy, rád se přiučím.

Závěr

Co si o tom myslíte? Našli jste nějakou chybu/nepřesnost? Řešíte podobné otázky ohledně zálohování, nebo vás u zálohování trápí něco jiného? Jak často provádíte zkušební obnovu dat? Napište mi do komentářů pod článek, nebo mi pošlete e-mail.

Zálohování v praxi

Připravil jsem pro vás i pokračování – článek o tom, jak řešíme zálohy v PATRON-IT. Jakým konkrétním technologiím věříme, jak je nastavujeme, kde vidíme výhody i úskalí. Článek publikuji zase některé pondělí. Pokud jste zvědaví a nechcete si ho nechat ujít, rád vám ho pak pošlu na e-mail.