Autor: Tomáš Přibyl, externí redaktor ICT SECURITY

Jedním z největších prohřešků v oblasti informační bezpečnosti je fakt, že zapomínáme na skutečnost, že její součástí je i dostupnost. Přitom jde o extrémně nebezpečný prohřešek.

Odepření přístupu

Ostatně, čítankovým příkladem nebezpečnosti nedostupnosti jsou stále oblíbené útoky Denial of Service – odepření služby. Zákeřnost útoků DoS spočívá v tom, že není napadený skutečný cíl, ale přístupové zdroje k němu. Cíl tak zůstává netknutý, ale přesto jen není možné regulérně využívat. Z reálného světa se DoS útok dá přirovnat k ucpané silnici: vše je z technického hlediska v pořádku, přesto se k cíli nemůžeme dostat.

V praxi je DoS útok typicky provedený obsazením přístupových zdrojů (např. záplava nekorektních paketů) nebo zahlcením kritického místa (např. „shození“ programu).

Právě DoS (respektive jejich silnější verze DDoS, Distributed DoD) útoky ukazují na nutnost zajištění dostupnosti a na snadnost provedení podobného úkonu. Nemusí přitom jít o útok záměrný: stačí běžný provozní výpadek spojení nebo jiná mimořádná událost.

Zálohování vs. archivace

Oblastí, kde se dostupnost ukazuje jako kritická, je zálohování. Často se totiž stává, že sice pečlivě a pravidelně zálohujeme – ale zálohy jsou v případě potřeby nedostupná. Přesněji: jsou nedostupné tak rychle, jak bychom potřebovali.

Je to dáno třeba tím, že dochází k zaměňování principů zálohování a archivace. Zálohování je proces vytvoření kopie dat, která může být fyzicky umístěná kdekoliv mimo původní místo, kterou můžeme dále používat a ke které se v případě potřeby můžeme kdykoliv vracet. Cílem zálohování je mít data bez zbytečného prodlení k dispozici v případě problémů s primárním médiem. Naproti tomu archivace představuje trvalé uchování dat, přičemž tato nemusí být bez zbytečné prodlevy dostupná. Cílem archivace je zajistit dostupnost dat z dlouhodobého hlediska.

Pozor na mraky!

Už patnáct procent IT manažerů dnes nasazuje projekty z oblasti cloud computingu. Většímu rozšíření této čím dál populárnější technologie přitom brání pochybnosti o její spolehlivosti, otázkách zálohování či toleranci k chybám. Ostatně, tyto oblasti hodnotí jako kritické a často neřešené i ti, kdo se pro cloud computing již rozhodli.

Za velmi kritickou je přitom často považována právě otázka dostupnosti. Při veškeré vysoké spolehlivosti komunikačních linek jsme na ně v případě cloudů odkázáni. A jedná se o faktor, který i při extrémně vysoké spolehlivosti výpadek mít může – a nad kterým nemáme tak úplně kontrolu. Nebo dokonce: proti kterému je možné podniknout útok.

Co ovšem s tím?

Pokud si vůbec uvědomíme, že dostupnost potřebujeme řešit, máme napůl vyhráno. Druhou polovinou je přijetí skutečnosti, že kromě technického přístupu k věci (dedikované linky, nezávislé zdroje, důraz na fyzickou bezpečnost, implementace kvalitních kontrolních prvků...) musíme aplikovat i přísně organizační prvky.

Důvod je prostý: čistě technický přístup nezaručuje, že postupy budou fungovat, že budou dostupné ve správný čas a na správném místě, že jsme připraveni na všechny možné situace apod. Tady musí nastoupit právě organizační stránka věci.

Ostatně, technická či jiná již existující opatření nepodložená jasnými fakty jsou často výsledkem emočních nebo zvykových rozhodnutí. Např. „když toto funguje jinde, proč by to nefungovalo i u nás“, nebo „takto je to zde již dlouho a dosud jsme s tím neměli problém“. Díky tomuto pohybu ve vyjetých kolejích dochází k duplikování, k nedostatku, k nejasnostem, chybám – a následným výpadkům, kterýchžto se chceme vyvarovat.

Musíme např. jasně definovat hodnotu „maximální přípustné doby výpadku“ (MTD, Maximum Tolerable Downtime). Upozorňujeme, že MTD je zapotřebí stanovit pro každý kritický proces zvlášť.

Někdy je též označována jako „cílový čas obnovy [plného provozu]“ (RTO, Recovery Time Objective), což ale není úplně přesné. Tato hodnota (ne)dostupnosti je často dána i normami nebo legislativou. Pro úplnost: existuje ještě hodnota „cílový bod obnovy [plného provozu]“ (RPO, Recovery Point Objective), která stanovuje minimální požadavky na provoz a podobu systému, jakých musí být dosaženo po výpadku.

Proč je hodnota MTD tak důležitá?

• Umožňuje identifikovat a prioritizovat jednotlivé kritické procesy.

• Stanovuje závazné hodnoty (hodnota „co nejdříve“ je hodně vágní), kterých musí být dosaženo u procesů a podpůrných zdrojů.

• Poutá důležitou pozornost směrem k otázkám dostupnosti.

• Poskytuje empirická data, na kterých lze stavět funkční a platné strategie.

Zkrátka a dobře: i dostupnost se dá bez větších potíží (vy)řešit.

Stačí jen chtít...