Kdy se vyplatí fyzická ochrana dat či zařízení?

Za jakých podmínek a v jakých částech systému má smysl fyzická ochrana IT zařízení? Podívejme se na hlavní kritéria rozhodování a používané varianty.

S určitou mírou zjednodušení lze říci, že vždy je rozhodující kombinace ceny dat a požadovaná rychlost obnovy činnosti IT systému po případné vážné nehodě. Jakmile jsou data příliš cenná nebo jejich ochranu vyžadují zákony či interní normy, je potřeba řešit jejich zabezpečení jak na úrovni logické, tak i fyzické, a to bez ohledu na jejich objem či velikost organizace. Jistě jste zaslechli okřídlené historky o zálohovacích páskách některých českých bank; snadno si lze domyslet, že většina příběhů se na veřejnost ani nedostane.

Druhou důležitou oblastí je plánování „disaster recovery“, které dnes již kromě majitelů a provozovatelů kritické infrastruktury v nějaké formě řeší i celá řada vlastníků úspěšných středních a menších firem. Pokud má vedení organizace požadavek na konkrétní, vysokou rychlost obnovy činnosti informačního systému po případné závažnější nehodě, musí zajistit fyzické přežití pečlivě vybraných klíčových prvků infrastruktury.

My se zaměříme především na fyzickou ochranu těch nejcennějších IT aktiv, tedy dat, z hlediska ztráty (tedy selhání či zničení zařízení a dat) i z hlediska zcizení (které ničí důvěryhodnost nebo konkurenční výhodu organizace).

Delegace odpovědnosti

V případě menšího objemu dat a ne až tak vysokých nároků na rychlost obnovy systému může jako bezpečná záloha posloužit vzdálené uložení kopie dat u poskytovatele příslušné služby.

Takové zálohování může probíhat plně automaticky, tedy velmi často a spolehlivě. Ve firmě potom bude stačit přiměřeně zabezpečit fyzický přístup k serveru. V tomto případě se nechává odpovědnost za fyzické zabezpečení zálohy na poskytovateli služby, zpravidla provozovateli či nájemci většího hostingového centra.

Důležitým faktorem v takovém případě bude to, jakou úroveň logické a fyzické ochrany zákazníkových dat bude poskytovatel ochoten smluvně garantovat (a za jakou cenu). Při plánování je potřeba rovněž sledovat šíři přenosového pásma z firmy do internetu a možnosti zabezpečení této komunikace, včetně propustnosti spojení při havarijní obnově veškerých zálohovaných dat.

Pokud to bezpečnostní a provozní hlediska umožňují, bude z hlediska zabezpečení kontinuity provozu zajímavý i vzdálený provoz aplikací – buď hostovaných samostatně, nebo provozovaných na vlastních serverech v profesionálním datovém centru.

Pokud chtějí uživatelé mít bezpečnost a důvěrnost dat plně ve svých rukou nebo se jim vzdálené ukládání vzhledem k objemům dat nehodí, je možné využít také zabezpečený datový sejf. Zde bude NAS síťové datové úložiště s živými či zálohovanými daty chráněno před zloději i přírodními živly – ohněm, vodou či elektromagnetickými výboji. Zabezpečené uložení dat či jejich záloh s fyzickým umístěním datového sejfu u zákazníka je dostupné rovněž jako služba, kdy poskytovatel zajišťuje vzdálenou správu a garantuje funkčnost systému.

Fyzická ochrana dat

U většiny malých a středně velkých organizací již lze předpokládat určité fyzické zabezpečení prostor serverovny, s přístupem pouze oprávněných osob, kontrolovaným prostředím, stabilně běžícím systémem zálohování dat a nějakou formou plánování obnovy po havárii. Pokud nebudou nároky na rychlost obnovy příliš vysoké, vystačit je možné s maximálně zabezpečenými a co nejaktuálnějšími datovými zálohami.

Jestliže mají být zálohovaná data ale skutečně v bezpečí, musejí být ve firmě uložena v požáru a zlodějům odolném trezoru, nebo ještě lépe mimo danou budovu. Vzhledem k tomu, že pravidelné odnášení médií například do bankovního trezoru může představovat poměrně značnou zátěž a vlastně i další riziko, je v řadě případů výhodnější použití zmíněného zabezpečeného datového sejfu. Při pokusu o narušení datový sejf varuje správce a v případě větší nehody jej lze „vytáhnout z trosek“, vyjmout datové úložiště, připojit do nové či provizorní sítě a maximálně aktuální data jsou obratem k dispozici.

Určité varování v této oblasti přinesla studie firmy PriceWaterhouseCoopers – podle ní více než polovina britských firem v posledních 12 měsících procesy zotavení po havárii prakticky netestovala. Mnoho velkých podniků využívá zálohování na pásky a má dojem, že je na nejhorší zcela připraveno.

Podle různých údajů se ovšem úspěšnost kompletní obnovy z páskových záloh pohybuje mezi 50 a 70 %. Vzhledem k těmto skutečnostem, v kombinaci s delší dobou potřebnou k obnově z pásků, přechází řada uživatelů na diskové systémy (třeba i s pomocí systému virtuálních páskových knihoven) nebo na schéma disk-disk-páska, kdy je nejaktuálnější záloha vždy na diskovém poli RAID.

Podle společnosti Convenio Consulting se doba žádoucí obnovy pro většinu malých a středních firem v ČR pohybuje v řádu dní. Po překročení této doby společnosti hrozí velké finanční ztráty, nebo dokonce odchod zákazníků. Menší organizace obvykle neinvestují do záložních systémů, a proto jsou důsledky havárií závažnější a skutečná doba obnovy se pohybuje v rozmezí od 3 do 15 dní.

Obnova po vážném poškození serverovny se zpravidla skládá z následujících kroků: obnovení lokality nebo nalezení nové, navezení potřebného hardwaru, obnova operačních systémů, obnova dat, obnovení konektivity a uživatelského prostředí.

S využitím datového sejfu se rychlost obnovy po vážné havárii v serverovně výrazně zkrátí. Výhoda použití zabezpečeného síťového úložiště (datového sejfu) spočívá v tom, že při zničení primárního úložiště je možné jej bez složitého nastavování ihned použít a využít jeho volnou kapacitu pro dočasný běh kritických funkcí IT. Ve fázi obnovy dat a jejich konzistence v aplikacích pomůže přeživší pole RAID nejvýrazněji, protože data lze z diskového systému obnovit podstatně rychleji než z páskových médií, popřípadě některá data mohou být čitelná přímo v souborovém systému. Při správné politice zálohování se zabrání velké ztrátě dat a obnova jejich konzistence je otázkou pouhých hodin a nikoliv dní.

Autor je konzultantem ve společnosti Complete CZ.

***tento článek vyšel v tištěném SecurityWorldu 2/2009