Zabezpečení ICT v rámci projektu rozdělení společnosti

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Zabezpečení ICT v rámci projektu rozdělení společnosti Diplomová práce

Autor:

Martin Tlučhoř Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš

červen 2013

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne

26. 6. 2013

Bc. Martin Tlučhoř

Poděkování

Touto cestou bych rád poděkoval vedoucímu práce Ing. Vladimíru Benešovi za velkou trpělivost a odborné vedení mé diplomové práce.

Anotace Tato práce se zabývá moţnostmi jak řešit zabezpečení ICT v organizaci. Pojednává o významu informací a hrozbách, kterým organizace musí čelit. V první části jsou popsány jednotlivé kroky, kterými se zavádění bezpečnosti v praxi provádí od analýzy rizik aţ k vytvoření projektu a jeho implementaci. Další část je věnována teorii tvorby havarijních plánů pro případ, kdy všechna bezpečnostní opatření selţou. V praktické části je proveden rozbor stavu zabezpečení konkrétní firmy a návrh opatření k jejímu zlepšení. Závěrečná část prezentuje modelový příklad havarijního plánu. Klíčová slova: bezpečnost, informace, riziko, opatření, incident, projekt, havárie, plán

Annotation The study addresses various possibilities how to deal with ICT security in the organization. It discusses the importance of information and threats that organizations must face. The first section describes the steps by which the security implementation in practice goes through the risk analysis to the project creation and implementation. Next section is devoted to the theory of making contingency plans for cases when all precautions fail. In the practical there is security status analyze of a particular company and opportunities for its improvement. The final section presents a model example of the emergency plan. Key words: Security, information, risk, remedy, incident, project, accident, plan

Obsah ÚVOD ................................................................................................................................................ 8 ZVOLENÉ METODY ZPRACOVÁNÍ ........................................................................................ 10 VYMEZENÍ PROBLEMATIKY A ZÁKLADNÍ POJMY .......................................................... 10 1.

TEORIE ZABEZPEČENÍ ICT ............................................................................................ 12

1.1.

Informační bezpečnost.............................................................................................................. 12

1.2.

Zranitelnost IS a hrozby ............................................................................................................ 14

1.3.

Bezpečnostní incidenty – útoky ................................................................................................. 18

1.4.

Ochrana před škodlivým kódem ................................................................................................ 22

1.5.

Analýza rizik ............................................................................................................................. 22

1.6.

Bezpečnostní politika, bezpečnostní projekt .............................................................................. 25

1.7.

Monitorování a audit ................................................................................................................ 28

1.8.

Řízení bezpečnosti informací ..................................................................................................... 30

1.9.

IT strategie a bezpečnost informačních systémů ........................................................................ 32

1.10.

HW a SW ochranná opatření ..................................................................................................... 34

2.

KRIZOVÉ PLÁNY ............................................................................................................... 37

2.1.

Business Continuity Plan ........................................................................................................... 38

2.1.1.

Kontinuita činností v IT ................................................................................................................. 39

2.1.2.

Životní cyklus BCP ......................................................................................................................... 41

2.1.3.

Analýza dopadů a analýza rizik ..................................................................................................... 43

2.1.4.

Návrh strategie ............................................................................................................................. 44

5

2.1.5.

Reakce na havárii.......................................................................................................................... 45

2.1.6.

Vytvoření plánů a implementace ................................................................................................. 46

2.1.7.

Testování a údržba ....................................................................................................................... 47

2.1.8.

Produkty podporující BCP............................................................................................................. 48

2.2.

Disaster Recovery Plan.............................................................................................................. 48

2.2.1.

Strategie a plán obnovy ................................................................................................................ 50

2.2.2.

Sedm vrstev DR ............................................................................................................................ 54

2.2.3.

Postup při výběru IT technologií pro DRP..................................................................................... 56

2.2.4.

Současné trendy v DR ................................................................................................................... 57

2.2.5.

Legislativa a standardy ................................................................................................................. 59

2.3.

3.

Shrnutí ..................................................................................................................................... 61

PŘÍPRAVA PROJEKTU ROZDĚLENÍ SPOLEČNOSTI ................................................ 63

3.1.

Představení společnosti ............................................................................................................ 63

3.2.

Rozdělení společnosti ............................................................................................................... 64

3.3.

Analýza infrastruktury a jejího zabezpečení před rozdělením společnosti ................................. 67

3.3.1.

Informační systém ........................................................................................................................ 67

3.3.2.

Sídlo firmy..................................................................................................................................... 69

3.3.3.

Místnost se servery ...................................................................................................................... 70

3.3.4.

Servery.......................................................................................................................................... 70

3.3.5.

Zálohování .................................................................................................................................... 71

3.3.6.

Pracovní stanice ........................................................................................................................... 71

3.3.7.

Síťová infrastruktura..................................................................................................................... 72

3.4.

Zjištěná rizika............................................................................................................................ 74

6

4.

REALIZACE A ZHODNOCENÍ PROJEKTU ................................................................... 76

4.1.

Nové sídlo................................................................................................................................. 76

4.2.

Infrastruktura a zabezpečení v novém sídle ............................................................................... 77

4.2.1.

Místnost serverů v novém sídle ................................................................................................... 77

4.2.2.

Servery v novém sídle................................................................................................................... 78

4.2.3.

Informační systém používaný novou společností......................................................................... 79

4.2.4.

Síťová infrastruktura v novém sídle.............................................................................................. 80

4.2.5.

Zálohování v novém sídle ............................................................................................................. 82

4.3.

Úpravy infrastruktury a zabezpečení v původním sídle .............................................................. 83

4.3.1.

Místnost serverů v původním sídle .............................................................................................. 84

4.3.2.

Informační systémy používané v původní společnosti ................................................................. 84

4.3.3.

Servery v původním sídle ............................................................................................................. 85

4.3.4.

Síťová infrastruktura v původním sídle ........................................................................................ 85

4.3.5.

Zálohování v původním sídle ........................................................................................................ 86

4.4.

Realizovaná opatření v rámci restrukturalizace ......................................................................... 87

4.5.

Modelový příklad havarijních plánů .......................................................................................... 88

4.6.

Další opatření ........................................................................................................................... 90

4.7.

Budoucí opatření ...................................................................................................................... 91

ZÁVĚR ........................................................................................................................................... 93 SEZNAM POUŽITÉ LITERATURY .......................................................................................... 94 SEZNAM OBRÁZKŮ ................................................................................................................... 99 SEZNAM TABULEK ..................................................................................................................100 7

Úvod V současné době jsme svědky stále rychlejšího vývoje a rozvoje moderních technologií, které se uplatňují ve všech sférách našeho ţivota. Stávají se stále podstatnější součástí chodu kaţdé firmy, podniku či instituce. Zvykli jsme si vyuţívat všech výhod, které nám přinášejí, ale současně se tím stáváme závislejšími a zranitelnějšími. Pouţíváme internet, e-mail, chytré mobilní telefony, sociální sítě - jsme zkrátka on-line, v kontaktu s celým světem. Naše nároky nejen na výkon, dostupnost, kapacitu, spolehlivost úloţišť, ale hlavně na bezpečnost jsou rok od roku vyšší. Ochrana dat, zabezpečení celého informačního systému (IS) a informačních technologií (IT) je prioritou pro kaţdou organizaci, protoţe jakékoliv ohroţení nebo výpadek mohou znamenat velké ekonomické ztráty, nebo i krach. Vyuţívání informačních technologií je totiţ spojeno s řadou rizik. Od pouhého selhání lidského faktoru, přes nezákonnou či kriminální činnost zvnějšku aţ po různé nepředvídatelné situace jako jsou ţivelní pohromy nebo havárie. Tyto hrozby nutí firmy se na takovéto situace dopředu připravit a snaţit se jim zabránit dříve, neţ se naplní. Investují proto nemalé prostředky na bezpečnostní opatření, která tato rizika minimalizují, sestavují plány pro zachování kontinuity činností i plány pro obnovu po mimořádných událostech. Téma své diplomové práce „Zabezpečení ICT v rámci projektu rozdělení společnosti“ jsem si zvolil s ohledem na to, ţe se touto problematikou zabývám i v rámci své práce ve firmě a je to pro mne tudíţ příleţitostí, jak se s problematikou podrobněji seznámit, ale také proto, ţe bezpečnostní standardy a normy jsou jen obecným návodem k zajištění bezpečnosti a chybí konkrétní praktické příklady z praxe. Cílem mé práce je obecně popsat a rozebrat principy zabezpečování informačních a komunikačních technologií a na příkladu jedné konkrétní existující firmy popsat jednotlivé kroky při zdokonalování bezpečnostních systémů v rámci její restrukturalizace. V první části své práce se budu zabývat vysvětlením základních pojmů, které jsou nezbytné pro správné pochopení problematiky, jako např. co je to bezpečnost informací, jak se dá řídit, jak s ní souvisí business kontinuity management (BCM) apod. V další části proberu postupy při zabezpečování

informačních systémů, objasním důleţitost

bezpečnostní politiky firmy a vysvětlím principy tvorby havarijních plánů. V další části 8

pak představím firmu, na které budu demonstrovat postupné kroky vedoucí ke zlepšení zabezpečení jejích ICT. Provedu nejprve analýzu výchozího stavu technické infrastruktury, a poté na základě zjištěných kritických oblastí navrhnu příslušná opatření včetně návrhu havarijního plánu.

9

Zvolené metody zpracování Pro získání celkového přehledu a orientace v problematice jsem si vyhledal několik publikací, ze kterých jsem čerpal nejdůleţitější informace pro svou práci. Abych neopomenul ani nejnovější trendy, podrobně jsem studoval na internetu i materiály firem, které se zabývají zabezpečováním informačních systémů, vývojem technologických zařízení a současně nabízejí vypracování projektů tzv. „na klíč“. V souladu se získanými informacemi jsem prováděl analýzu technologické infrastruktury konkrétní firmy z hlediska podpory nejdůleţitějších činností pro zachování jejího běţného provozu. Na základě zjištěných skutečností a vytipovaných moţných rizik jsem stanovil opatření, která tato rizika eliminují nebo alespoň minimalizují a navrhl postup pro případ havárie.

Vymezení problematiky a základní pojmy Díky obrovskému nárůstu dat a informací, které jsou pro kaţdou firmu stěţejní, je nezbytně nutné mít vytvořenou dobře fungující a dobře zabezpečenou IT infrastrukturu. Jak jsme se mohli v nedávné době sami přesvědčit na příkladu našich povodní, japonské Fukušimi či teroristických útoků v Americe, existuje široká škála moţností i úplného zničení celé organizace. Přesto se stále vyskytuje spousta, především malých firem, které nemají své informační systémy optimálně zabezpečené, nemají spolehlivě dořešené procesy zálohování a nevěnují pozornost tvorbě havarijních plánů. Právě tato opatření však mohou jednou rozhodnout o přeţití jejich firmy. Definic a vyjádření toho, co je to vlastně informační systém je celá řada, zjednodušeně by se dalo říci, ţe informační systém je moţné chápat jako systém vzájemně propojených informací a procesů, které s těmito informacemi pracují, jedná se např. o sběr, ukládání, přenos, zpracování a distribuci informací. Informacemi jsou pak myšlena data, a ta jsou pro organizaci významná, protoţe ovlivňují naše rozhodování a řízení. Informační technologie jsou veškeré nástroje, postupy a technologie, které lidem umoţňují nakládání s informacemi.

10

V okamţiku, kdy tato zařízení začala komunikovat mezi sebou, případně v uzavřených sítích, byl původní koncept informačních technologií IT rozšířen o prvek komunikace a vznikla zkratka ICT – informační a komunikační technologie. Tyto technologie dnes zahrnují veškeré HW i SW prostředky. Všechny tyto prostředky společně s daty tvoří aktiva organizace, která mají určitou hodnotu a společně s lidmi tvoří celý informační systém. Kvalitní informační systém pak ovlivňuje efektivnost řízení a konkurenceschopnost firmy.

11

1. Teorie zabezpečení ICT 1.1. Informační bezpečnost Informační bezpečnost, jak vyplývá ze standardu International standard ISO IEC 27000, znamená zajištění ochrany integrity, důvěrnosti a dostupnosti informací, kde - integrita

– znamená zajištění neporušenosti, správnosti a úplnosti informací,

- důvěrnost

– znamená, ţe informace je dostupná jen pro autorizované osoby (jde o identifikaci a určení toho, kdo smí provádět konkrétní operace),

- autenticita

– znamená moţnost dohledání původce informace,

- dostupnost – znamená přístupnost informace kdykoliv je potřeba. Jedna z mnoha definic uvádí např.: „Informační bezpečnost je multidisciplinární obor, usilující o komplexní pohled na problematiku ochrany informací během jejich vzniku, zpracování, ukládání, přenosu a likvidace. Je tak moţné chápat odvětví, zabývající se sniţováním rizik vztahujících se k fenoménu informací a navrhující opatření vztahující se k příslušným organizačním, řídícím, metodickým, technickým, právním a dalším otázkám, které s touto problematikou souvisejí.“[16] Z jiného hlediska lze bezpečnost IT chápat jako ochranu před prováděním nevyţádané činnosti. Zajištění bezpečnosti informací je důleţité i z hlediska legislativních poţadavků jako např. ochrana osobních údajů, nakládání s určitým druhem informací apod. V neposledním případě si zajištěním bezpečnosti informací firma také chrání svou pověst i své know-how.

12

Obrázek 1 - Vztah úrovní bezpečnosti v organizaci. Zdroj: [9]

Ještě jednou se vrátíme k pojmu „informace“, která je podle ISO/IEC 2382-36 (369001) definována asi takto: „Informace je význam, který člověk přisuzuje údajům. Údaj je obraz vlastností objektu, vhodně formalizovaný pro přesnost, interpretaci nebo zpracování prostřednictvím lidí nebo automatů“. Informace ovlivňují naše rozhodování, které pak můţe způsobit různé důsledky. S pojmem informace pak souvisí ještě pojem data. „Data jsou formalizovaný záznam lidského poznání pomocí symbolů (znaků). Smysluplná informace pak vzniká v procesu interpretace člověkem“ [17]. Data nebo informace jsou pro firmu cenným aktivem, protoţe přinášejí určitý uţitek. Jak správně s daty nakládat je pak úkolem bezpečnostní politiky, která je souhrnem pravidel a norem jak data spravovat, ochraňovat a distribuovat.

13

1.2. Zranitelnost IS a hrozby Přes veškerá zabezpečení je kaţdý informační systém zranitelný. Vţdy existuje nějaké zranitelné místo, kterého můţe někdo vyuţít k útoku nebo kde můţe dojít např. k havárii. Všechna tato zranitelná místa představují pro organizaci určitou hrozbu. Hrozby, které mohou způsobit organizaci problémy a narušit tak její kontinuální chod, lze rozdělit podle různých hledisek:

bouře, hurikány, vichřice (je třeba brát v úvahu frekvenci a intenzitu bouří, blízkost stromů a jiných objektů v okolí) Přírodní

záplavy (blízkost moře, řek, potoků, hladiny spodních vod nebo polohu ve svahu, v rokli atd.) zemětřesení, tsunami, sesuvy půdy, vulkanická činnost, apod. lesní poţáry elektrické obvody a plynová zařízení

Poţáry

Hrozby vnější

stroje a zařízení (např. tiskárny, kopírky, počítače, servery, nápojové automaty, čistící stroje, plnící linky, myčky, chladničky a mrazáky, laminovací stroje, ventilátory, apod.) laboratoře a dílny (tlakové láhve s plyny, chemikálie, barvy, laky, odpad, apod.)

Technické a technologické Vyplavení

Výpadky sluţeb

vodovodní potrubí kanalizace vytápění kondenzát z klimatizace elektrická energie vytápění telekomunikační sluţby (internet, telefony) voda

Poruchy Tabulka 1 – Hrozby vnější. Zdroj: vlastní

14

kouření pracovníků Lidský faktor neúmyslné

neopatrná manipulace poblíţ potrubí či elektrického vedení stavební práce a údrţba neškolený uţivatel ţhářství

Hrozby vnitřní

vandalismus sabotáţ špionáţ terorismus krádeţ malware hackeři

Lidský faktor úmyslné

Tabulka 2 – Hrozby vnitřní. Zdroj: vlastní

Potenciály těchto hrozeb jsou samozřejmě pro kaţdou organizaci individuální, a od toho se odvíjí i samotné řešení pro organizaci. Existence hrozby představuje určité riziko, a proto musí kaţdá firma tato rizika analyzovat a rozhodnout, která z nich jsou pro ni významná. Bez ohledu na lokalitu a další faktory ovlivňující míru hrozeb je obecně stále více neţ polovina všech přerušení provozu a delších výpadků normálních činností organizací způsobena přímo aktivitami člověka. Vyplývá to ze studie společnosti Accenture, jejíţ výsledky znázorňuje diagram níţe (viz obr. č. 2). Na diagramu je vidět jakou měrou se ve skutečnosti podílejí některé hrozby na delších výpadcích provozu organizací. To, ţe výpadků způsobených lidským faktorem je největší podíl, ovšem neznamená, ţe by takovéto pohromy měly nejvíce dramatické následky. Proto tak na sebe, vyjma terorismu, mnohem více pozornosti upoutávají stále častější přírodní katastrofy, které se na tomto diagramu spolu s haváriemi telekomunikací pomyslně dělí aţ o třetí místo.

15

Obrázek 2 - Hrozby. Zdroj: http://www.accenture.com/SiteCollectionImages/Technology/ Outlook_Journal/Research_And_Insights/ITDisaster1.gif

Přestoţe jsou většinou přírodní katastrofy velmi medializované a škody kaţdé z nich vyčíslovány do astronomických výší, je v součtu hodnota škod způsobených člověkem stále mnohem větší. Výpadky proudu a jiné havárie spojené s napájením jsou také velmi významnou hrozbou pro kontinuitu provozu, a na tomto diagramu jsou na druhém místě s přibliţně jednou osminou z celkového podílu. Naprostá většina organizací na ochranu před krátkodobými výpadky napětí dnes pouţívá UPS, a mnoho z nich je pak dále doplňuje například dieselagregátem pro pokrytí i delších výpadků. Problémem můţe být, ţe většina z nich takto chrání pouze nejdůleţitější hardware firemní infrastruktury, aby nedošlo k jeho poškození, a neřeší jiţ další problémy plynoucí z dlouhodobých výpadků energie, jako např.: o i přes funkční servery a sítě napájené ze záloţních zdrojů je nemoţné pracovat na stolních počítačích,

16

o nefunkční osvětlení, o nefunkční vzduchotechnika a klimatizace či vytápění, o neaktivní protipoţární ochrana včetně prostředků pro vyhlášení případné evakuace, o nárůst teplot v chlazených skladech a znehodnocení výrobků či surovin, o nefunkční výrobní a balicí přístroje, o nefunkční výtahy, apod. Následující dva grafy vycházejí z průzkumu společnosti Ernst&Young „Průzkum stavu informační bezpečnosti v ČR“ a je na nich zobrazena četnost jednotlivých bezpečnostních incidentů v českých společnostech k roku 2009 a také závaţnost dopadů jednotlivých bezpečnostních incidentů.

Obrázek 3 – Bezpečnostní incidenty s nejzávaţnějším dopadem 2008-2009. Zdroj: [22]

17

Obrázek 4 – Výskyt bezpečnostních incidentů 2008 – 2009. Zdroj: [22]

Z těchto grafů je moţné si udělat představu o tom, na jaké hrozby by se měla organizace zaměřit, neboli kam se jí vyplatí vynaloţit své prostředky na ochranu aktiv. Posoudit cenu aktiva je však mnohdy velmi obtíţné i proto, ţe by se k němu měly připočítat i vedlejší náklady spojené s jeho nedostupností v době po incidentu. Při posuzování závaţnosti hrozeb je také nutné vzít v úvahu, jak velkou škodu by hrozba mohla způsobit, ale i pravděpodobnost s jakou je hrozba schopna dané aktivum ohrozit. Škoda, coby následek hrozby vyčíslený v penězích, by měla zahrnovat veškeré náklady, tzn. náklady na odstranění, ušlý zisk, poškození reputace, ztrátu know-how apod.

1.3. Bezpečnostní incidenty – útoky Útok je úmyslná a plánovaná akce směřující k napadení informačního systému nebo sítě. Tyto útoky je moţné třídit z mnoho různých hledisek. Jedním z nich můţe být např. motivace útočníka:

18

1) bezdůvodně se snaţí něco poškodit, mohou být motivováni třeba nenávistí či závistí a neuvědomují si většinou dopady, jsou to útočníci malé síly, 2) prohledávají jen tak ze zvědavosti IS a data avšak nemají s nimi ţádné úmysly-útočníci malé síly, 3) snaţí se prolomit zabezpečení, aby se zviditelnili, jsou to útočníci střední síly, např. hackeři, 4) vstupují do systému s předem jasným cílem např. získání peněz, prosazení svého politického vlivu, zločin, vytváření teroru apod., jedná se o útočníky velké síly, kteří se snaţí za sebou nezanechat stopy, 5) usilují o návrat internetu bez jakýchkoli omezení, většinou to jsou útočníci malé síly. K základním bezpečnostním útokům patří: přerušení nebo zničení – jedná se o aktivní útok na dostupnost HW, SW nebo dat např. vymazáním, poškozením, poruchou apod. kdy dojde k ukončení dostupnosti určitého aktiva, odposlech – jde o útok na důvěrnost, např. kopírování dat či programů. Detekce odposlechu je velmi obtíţná a nemusí být ani odhalena, změna či modifikace – jde o útok na integritu neboli celistvost dat, útočník změní data nebo program, přidá do programu nějakou funkci – vyuţití např. v elektronickém bankovnictví. Další třídění útoků je podle velikosti předpokládané škody. Z tohoto hlediska je můţeme třídit na útoky: významné – jde o útoky s velkou škodou, v některých případech je moţné se proti nim pojistit, v ostatních případech je vhodné se proti nim zabezpečit, nevýznamné – útoky s malou škodou, u nichţ nemá smysl vypracovávat nákladná opatření.

19

Podle účelu provádění lze útoky dělit na útoky: Průzkumné – prostřednictvím různých technik chce útočník získat informace o svém cíli, např. sleduje stopy, které zanechávají uţivatelé svými aktivitami v systému, sleduje volně dostupné databáze, provádí odposlech, skenování systému či spyware apod. Narušení přístupu – útočník se snaţí získat přístup do systému, např. útoky na hesla, phishing, krádeţ identity - vydáváním se za někoho jiného se snaţí získat přístup do systému, zneuţití bezpečnostních slabin v HW nebo SW, apod. Odepření sluţeb – cílem je poškodit systém pomocí velkého mnoţství dat, kdy dojde ke sníţení výkonnosti či úplnému vyřazení z provozu (útoky DoS a DDoS-viz dále). Ke známým útokům patřících do skupiny tzv. škodlivých kódů, coţ jsou programy nebo aplikace, které mohou mít neblahý vliv na naše data, patří: Viry – jsou nejstarší formou počítačových útoků, virus se připojí k jinému souboru a majitelem je při práci nevědomky spuštěn. Napadá další soubory, aţ dojde k nějakému poškození, obvykle smazání dat či sníţení výkonu počítače. Trojské koně – je druh software, který vypadá jako neškodný uţitečný program, ale ve skutečnosti má za úkol sledovat naši činnost na počítači, např. zjišťuje, jaké internetové stránky navštěvujeme, jaké pouţíváme programy apod. Sami se nešíří a k aktivaci dochází tím, ţe uţivatel otevře infikovaný program vesměs jako přílohu e-mailových zpráv. Červi – vyuţívají skulin v zabezpečení systému a sami se šíří jako samostatný program na další, sítí dostupné počítače, kde provádějí nebezpečné aktivity. Po síti se rychle šíří a zaplňují disk či neúměrně zatěţují síť. Většinou bývají také přílohou e-mailových zpráv. Spyware - program, který sbírá informace o aktivitách uţivatele bez jeho vědomí.

20

Advare – software, který zobrazuje neţádanou reklamu na základě informací, které posbíral. Phishing - e-mail, jakoby z důvěryhodného zdroje který uţivatele vyzývá k návštěvě webových stránek s cílem odeslat útočníkovi své přihlašovací údaje. Hoaxy – je nevyţádaná zpráva, která uţivatele např. varuje před nějakým nebezpečím či poskytuje jakousi radu a zpravidla vyzývá k dalšímu rozeslání zprávy. Nebezpečí spočívá v přeposílání velkého mnoţství adres čímţ se zvětšuje prostor pro šíření spamu a dochází také k zatíţení sítě. Spam – jsou e-mailem šířené zprávy, nejčastěji obchodní nabídky, které zaplavují internet. E-mailové adresy se získávají pomocí programů, které prohledávají internet a sbírají tyto adresy. Malware – souhrnné označení pro viry, červi, spyware a trojské koně. V poslední době také aplikace, která tvrdí, ţe odstraní spyware, ale místo toho ho do počítače zanese. Rootkit – škodlivý program hluboko v operačním systému, kde ukrývá běţící procesy. Dialer – dokáţe změnit telefonní číslo pro připojení na internet na jiné s vysokým tarifem. Útok DoS (Denial of Service) – útok spočívá v zahlcení serveru falešnými poţadavky, např. na nějakou sluţbu, kterou firma poskytuje. DDoS (Distributed Denial of Service) – jedná se o stejný typ útoku, avšak vedený z velkého mnoţství počítačů. Hranice mezi jednotlivými druhy těchto hrozeb se postupem času stírají a dochází k jejich vzájemnému prolínání. Přesto se zdá, ţe do budoucna bude stále větší hrozbou především spyware a červi. Bezpečnostním problémem jsou v poslední době i mobilní telefony, MP3 přehrávače nebo iPody připojené k síti, jejichţ prostřednictvím můţe dojít k rychlému šíření škodlivého kódu celou sítí.

21

1.4. Ochrana před škodlivým kódem Základním prostředkem ochrany jsou antivirové programy, které je však nutno pravidelně aktualizovat, aby fungovaly i proti nejnovějšímu malware. Většina z nich dnes nabízí jak funkci prohledávání počítače na vyţádání, tak i funkci rezidentního štítu, který běţí na pozadí a svou funkci tak plní neustále. Pro řízení a zabezpečení síťového provozu uvnitř lokální sítě, tak i ven se pouţívá firewall. Odfiltrovává nebezpečné sluţby, blokuje mapování vnitřní sítě, chrání nejen před útoky zvenčí, ale brání i nevědomému odesílání dat z počítače. Firmám je určen především hardwarový firewall, který pak můţe plnit i další funkce a stává se tak významným prostředkem komplexní bezpečnostní politiky firmy. Obecně bychom mohli shrnout některé zásady obrany proti škodlivým programům do několika bodů: o pouţívat aktualizovaný antivirový program i firewall, o „záplatovat“ pravidelně operační systém (čímţ se myslí instalace balíčků, které opravují nově zjištěné bezpečnostní nedostatky nejen operačního systému, ale i webového prohlíţeče, kancelářských nástrojů a jiných aplikací), o pouţívat programy na odstraňování spywaru, o neotvírat přílohy e-mailů od neznámých odesílatelů, nenavštěvovat pochybné stránky, nezveřejňovat osobní a citlivé údaje, nestahovat soubory z neověřených zdrojů apod.

1.5. Analýza rizik Rizikem se rozumí míra ohroţení aktiva konkrétní hrozbou a bývá vyjádřeno pravděpodobností jeho vzniku a závaţností dopadu na organizaci. Tato rizika je zapotřebí vyhodnotit a snaţit se je zmírnit za pouţití ochranných opatření, případně je zcela odstranit, pokud je to moţné, anebo je akceptovat, pokud jsou pro společnost přijatelná.

22

Při vynaloţení příliš velkého mnoţství prostředků na zabezpečení by mohly náklady překročit případné škody vyplývající z rizika. Jak vyplývá z následujícího grafu, optimální míra zabezpečení se nachází někde uprostřed mezi vynaloţenými náklady a případnými škodami, v místě tzv. zvratu, které se nachází v průsečíku obou křivek.

Obrázek 5 – Vztah mezi rizikem a vynaloţenými náklady na jeho odstranění. Zdroj: [10]

Cílem analýzy rizik je tedy identifikovat hrozby, kterým je informační systém vystaven, určit výši potenciálních škod a stanovit opatření. Zkoumá se při ní např.: -

co můţe způsobit výpadek proudu,

-

jaká jsou protipoţární opatření,

-

jaké důsledky můţe mít ztráta dat,

23

-

jak je prováděno zálohování,

-

jak se likvidují záznamy,

-

jaká je antivirová ochrana,

-

kde se archivuje dokumentace,

-

kdo přiděluje přístupová práva a jak se pracuje s hesly,

-

co můţe způsobit zaměstnanec,

-

jakým způsobem se dá vstoupit do firmy apod.

Výsledky této analýzy mají pro společnost zásadní význam, a protoţe odkrývají tzv. slabá místa, měly by s nimi pracovat pouze pověřené osoby. Existují i programy, které s touto analýzou a stanovením potenciálních hrozeb mohou pomoci, např. metodika CRAMM (CCTA Risk Analysis and Management Method) – metodika pro analýzu a řízení rizik a nástroj pro vytváření bezpečnostní dokumentace nutné pro certifikaci., která zkoumá celkem 36 skupin hrozeb a zranitelností. Analýza rizik tedy zahrnuje: -

identifikaci aktiv a hrozeb,

-

ohodnocení aktiv,

-

určení pravděpodobnosti uplatnění hrozby,

-

určení zranitelnosti kaţdého aktiva danou hrozbou,

-

kvantifikaci rizika pro jednotlivé dvojice aktivum a hrozba.

Po identifikaci pro společnost významných aktiv se určí jejich hodnota buď v penězích (např. jako škoda) nebo jako kvalitativní posouzení slovní (např. zanedbatelné, významné, kritické apod.). Pravděpodobnost uplatnění hrozby se ohodnotí buď kvantitativně (např. se číselně stanoví pravděpodobnost výskytu během roku) nebo kvalitativně (např. vysoká, střední, nízká). Ohodnocení zranitelnosti coby pravděpodobnosti vyuţití hrozby se

24

ohodnotí buď kvantitativně (procenty) nebo kvalitativně stejně jako u hrozeb pomocí slovního vyjádření. V závěrečné fázi dojde k vyhodnocení rizik buď výpočtem (v případě kvantitativní metodiky) nebo odhadem. Na základě těchto informací pak organizace vypracuje dokumenty a předpisy, kde je definováno, co je třeba zabezpečit a kdo za to zodpovídá, a ty se pak stávají součástí její bezpečnostní politiky.

1.6. Bezpečnostní politika, bezpečnostní projekt Postup řešení bezpečnosti informačních systémů je pro kaţdou organizaci zcela individuální, nelze ho odnikud převzít a je zapotřebí ho chápat jako proces, který není nikdy dokončen. Musí reagovat na změny v organizaci, změny technologií apod. Na počátku se vypracovává studie bezpečnosti, která mapuje situaci ve firmě. Poté následuje analýza rizik a teprve na ní navazuje stanovení bezpečnostní politiky, která je dokumentem zásadního významu, který určuje směr řešení. Bezpečnostní projekt pak dále konkretizuje jednotlivá bezpečnostní opatření. Bezpečnostní politika je písemný dokument, který určuje odpovědnosti, pravomoci a práva. Jedná se o závazný dokument, který se po schválení vedením organizace stává vnitřní normou. Definuje organizační infrastrukturu a jmenuje bezpečnostní management, který je zodpovědný za její prosazování a realizaci. V malých firmách však můţe být za bezpečnost odpovědný třeba jen jeden člověk, zpravidla zaměstnanec IT oddělení. Jednotlivé oblasti bezpečnosti informací popisuje norma ISI 27002, která vychází z normy ISO/IEC 17799 a obsahuje přehled doporučení a bezpečnostních opatření. O zavedení konkrétních opatření však rozhoduje sama organizace na základě hodnocení rizik. Na obr. 6 je znázorněno členění informační bezpečnosti do 11 kategorií, které jsou důleţité pro fungování organizace a jejich vazba na bezpečnostní politiku.

25

Obrázek 6 – Oddíly bezpečnosti informací. Zdroj: [7]

K jednotlivým kategoriím ještě uvedu stručnou charakteristiku: Bezpečnostní politika – jak uţ bylo výše uvedeno, je dokument specifikující cíle a význam zabezpečení informací, popisuje zásady a stanovuje odpovědnosti a pravomoci. Organizace

bezpečnosti

–

vytváří

organizační

strukturu bezpečnosti

v organizaci a stanovuje zásady fungování nejen uvnitř firmy, ale i ve vztahu k okolí. Řízení přístupů – řídí přístup k aktivům (identifikace uţivatele, autentizace, přidělení oprávnění, přiřazení odpovědnosti). Klasifikace a řízení aktiv – definuje aktiva a jejich důleţitost ve vztahu k ochraně. Bezpečnost lidských zdrojů – sleduje zajištění bezpečnosti informací z hlediska lidských zdrojů – školení zaměstnanců. 26

Fyzická bezpečnost a bezpečnost prostředí – opatření pro zamezení přístupu cizích osob jako obrana proti poškození nebo zcizení aktiv. Řízení komunikace a řízení provozu – zajištění bezpečného provozu ICT, zajištění zálohování dat a monitoring sítě. Nákup, vývoj a údrţba IS – dodrţování bezpečnosti informací i při pořizování nových ICT. Řízení kontinuity činností organizace – stanoví postupy pro zajištění nepřetrţitého provozu organizace (brání přerušení kritických procesů) a opatření pro minimalizaci škod. Zvládání bezpečnostních incidentů – stanovení pravidel pro hlášení bezpečnostních incidentů a postupů pro jejich nápravu. Soulad s poţadavky – zajištění souladu s legislativními i smluvními závazky. Bezpečnostní politika jako dokument by měla obsahovat následující body: popis organizace, cíle bezpečnostní politiky, vypracování bezpečnostní infrastruktury – určit role, funkce, odpovědnosti, povinnosti, definici aktiv, identifikaci hrozeb, analýzu rizik, popis současného stavu, návrh bezpečnostních opatření, havarijní plány, časový plán implementace a školení. 27

Tento dokument vytváří tým odborníků, kteří musí respektovat legislativu, rozumět bezpečnostní architektuře, vyznat se v personální bezpečnosti a mnoha dalších disciplínách. Při formulování bezpečnostní politiky je potřebné dobře vybalancovat, aby nebyla příliš liberální, ale ani příliš striktní, protoţe čím bude striktnější, tím obtíţněji se bude prosazovat v praxi a bude často obcházena. Na druhé straně příliš liberální přístup bude představovat potenciální bezpečnostní riziko. K tomu, aby se bezpečnostní politika stala součástí kaţdodenního fungování organizace, je důleţité, aby zaměstnanci byli proškoleni, prováděla se průběţná kontrola dodrţování pravidel, aby dodrţování zásad neblokovalo chod firmy a aby i management tyto zásady dodrţoval. Na základě přijaté bezpečnostní politiky je pak vypracován bezpečnostní projekt, který je jiţ souhrnem konkrétních bezpečnostních opatření, která se pak musí implementovat do praxe. Tento projekt bývá rozdělen na projekt bezpečnosti technického vybavení IT, projekt zabezpečení sítí a komunikací, fyzické ochrany apod. V této fázi pak vznikají bezpečnostní provozní směrnice jako např. směrnice pro pouţití síťových sluţeb (definuje pravidla uţívání, stanovuje postupy pro přístup), směrnice pro zálohování a nakládání s médii, směrnice pro klasifikaci informací a dat (stanovuje odpovědnosti pro zajišťování ochrany), směrnice pro zvládání bezpečnostních incidentů, směrnice pro správu (definuje pravidla pro přístup uţivatelů k informacím a dalším sluţbám) apod.

1.7. Monitorování a audit Po vybudování bezpečnostních mechanismů a jejich implementaci je třeba neustále ověřovat, zda jsou dobře nastaveny, jestli se příliš nezměnily podmínky a jestli odpovídají dané situaci. Dnešní informační systémy generují mnoţství monitorovacích dat. Je důleţité mít takové mechanizmy, které jednak detekují případné bezpečnostní incidenty, ale mohou v sobě mít i nápravné kontrolní mechanizmy. Detekce pokusů o incident je pro organizaci cenným materiálem, který by se měl uchovávat a vyhodnocovat. Logy, které vytváří kaţdý informační systém, slouţí buď k průběţnému monitoringu a sledování podezřelých aktivit v systému nebo k dohledávání průběhu událostí. Spojením logů z více systémů je pak moţné získat reálný obrázek o tom, co se na síti děje. Pro vyhodnocování monitoringu je potřebná určitá zkušenost. Obsluha by měla umět vyhodnotit závaţnost situace a podle toho jednat.

28

Audit je nezávislé posouzení např. informačního systému nebo jeho části. Základním typem auditu je interní audit, který je součástí systému řízení organizace. Dalším typem je externí audit, který slouţí k ověření, do jaké míry se lze spolehnout na správnost, úplnost a přesnost transakcí. Audity se dále odlišují tím, za jakým účelem se provádějí např. kontrola shody, zajištění úrovně bezpečnosti, audity pro certifikaci ISO apod.

Obrázek 7 – Postup tvorby bezpečnosti. Zdroj: [5]

29

Hodnocení bezpečnosti je moţné provádět i vlastními silami, ale protoţe systém je kvalifikovaně schopný otestovat většinou jen správce IT, který se zpravidla zároveň účastnil systému zavádění bezpečnosti, není tento způsob příliš vhodný. Hodnocení kvality zabezpečení proto bude vhodnější svěřit odborné firmě. I zde jsou ovšem určitá úskalí, protoţe není moţné zjistit, jak kvalitní práci externí firma odvedla a také se nelze zcela spolehnout na poctivost jejích zaměstnanců. Ti se samozřejmě během své práce dostávají k citlivým údajům, odhalují slabiny ve firmě a mohli by případně těchto informací zneuţít.

1.8. Řízení bezpečnosti informací Z hlediska potřeby zavádět ve firmě bezpečnostní opatření je moţné zařadit firmy do několika kategorií, v závislosti na tom, v jakém stádiu zavádění bezpečnostních opatření se nacházejí. V prvním stádiu firma nemá prakticky ţádnou představu o bezpečnosti, nikdo se jí nezabývá. Mohou zde existovat určitá bezpečnostní opatření, ale nejsou nijak strukturována ani integrována. Ve druhém stádiu se nacházejí firmy, kde je bezpečnost chápána jako technický problém a má ji na starost útvar IT. Tyto firmy jiţ vyuţívají pokročilejších technologií, jako např. antivirové programy, firewall, ale není zde vytvořen ţádný systém. Třetí stádium jiţ znamená, ţe existuje určitý systematičtější pohled na bezpečnost a technické

prostředky

jsou

sofistikovanější.

Díky

školením

postupně

vzrůstá

i informovanost zaměstnanců. Ve čtvrtém stádiu se nacházejí firmy, kde se jiţ bezpečnost stala součástí firemní kultury a řeší se jiţ plánovaně a systematicky. U organizací, které se jiţ nacházejí ve vyšším stádiu, vzniká potřeba bezpečnost informací řídit. Protoţe však prakticky kaţdá organizace pracuje s nějakými citlivými daty, např. s osobními údaji, které je ze zákona povinna chránit, dá se říci, ţe potřeba řídit bezpečnost informací vzniká i tam. Záleţí však na tom, jakým způsobem svá citlivá data chrání, zda je uchovává někde v trezoru či zda má vypracovaný nějaký systém, jak mít svá data „pod kontrolou“. Veškeré činnosti, které v organizaci probíhají, musí být vykonávány tak, aby

30

zůstaly zachovány hlavní principy bezpečnosti informací tj. důvěrnost, integrita a dostupnost informací. Pro dosaţení tohoto stavu existuje souhrn pravidel, který se nazývá Systém řízení bezpečnosti informací - ISMS (Information Security Management System), který vychází z normy ISO/IEC 27001. Aby se dalo hovořit o řízení bezpečnosti informací, musí být v organizaci vytvořen, zaveden a průběţně dokumentován systém, který bude definovat všechny principy a metody, které budou tuto činnost zahrnovat. Definice, která z této normy vychází, říká, ţe „Systém managementu bezpečnosti informací je část celkového systému managementu organizace zaloţená na přístupu (organizace) k rizikům činností, která je zaměřena na ustavení, zavádění, provoz, monitorování, přezkoumání, udrţování a zlepšování bezpečnosti informací“. Znamená to tedy, ţe řízení bezpečnosti informací je částí celkového managementu firmy, vedle kterého můţe být např. i systém řízení jakosti dle normy ISO/IEC 9001 či systém řízení vztahů k okolí podle normy ISO/IEC 14001. V některých organizacích je moţné se setkat s tím, ţe všechny tyto systémy jsou sloučeny do tzv. integrovaného systému řízení, coţ umoţňuje jejich snazší správu, provoz i kontrolu. Definice také hovoří o tom, ţe je tento systém zaloţen na přístupu organizace k rizikům činností, a to znamená, ţe si firma na základě vyhodnocení rizik sama určí, jak náročný systém bezpečnosti chce vybudovat. Všechny tyto systémy, které se v organizaci nacházejí, mají společné to, ţe procházejí cyklickým vývojem, zaloţeném na principu zpětné vazby, známým jako Plan-Do-Check-Act. V tomto případě znamená: Plan (plánuj) – ustavení ISMS – definovat cíle a rozsah řízení bezpečnosti a stanovit opatření. DO (dělej) – zavádění a provoz ISMS – implementovat řízení do fungování organizace. Check (kontroluj) – monitorování a přezkoumání ISMS – sledovat a hodnotit fungování ISMS. Act (jednej) – údrţba a zlepšování ISMS – realizovat změny a odstraňovat nedostatky. Řešení problematiky bezpečnosti organizace vyţaduje komplexní přístup a další normou, která tuto oblast upravuje je ISO/IEC 27002, která poskytuje podrobný přehled 31

bezpečnostních opatření. Obě normy tak tvoří potřebný základ, na kterém bude celý systém vybudován. Případná certifikace pak probíhá podle normy ISO/IEC 27001. K dalším nástrojům pro řízení informační bezpečnosti, o kterých bych se ještě rád zmínil, je metodika COBIT a soubor nejlepších praktik ITIL. Metodika COBIT (Control Objectives for Information and related Technology - Kontrolní cíle pro informace a s nimi spojenou technologii) vznikla původně jako nástroj pro řízení auditu IS a je jakýmsi rámcem pro kontrolu a řízení IT. Pomáhá podnikům řídit soulad podnikových cílů a informačních technologií. Poskytuje odpověď na otázku „co by se mělo udělat“. Metodika ITIL (InformationTechnology Infrastructure Library - Knihovna infrastruktury informačních technologií) je mezinárodně uznávaný standard pro řízení IT sluţeb. Je to soubor nejlepších praktik vytvořených lidmi z praxe, který vznikl v Anglii jako nástroj pro řízení IT vládních a státních orgánů. Obsahuje definice procesů a rolí v organizaci a způsoby implementace, tzn., ţe poskytuje návod „jak to udělat“.

1.9. IT strategie a bezpečnost informačních systémů Ve většině oborů je dnes bezpečná a fungující IT strategie základem plynulého provozu a efektivní práce, coţ napomáhá ke zvyšování zisku a minimalizaci nákladů. IT strategie je jedním z výstupů strategického řízení a je současně jednou z dílčích strategií, které navazují na celkovou firemní strategii. Představuje dlouhodobou orientaci organizace, tzn. vizi jejího budoucího stavu, v oblasti zdrojů, sluţeb a technologií. Podporuje dosaţení cílů organizace prostřednictvím informačních technologií. Proces přípravy a tvorby IT strategie předpokládá spolupráci nejen na úrovni managementu a specialistů IT, ale i ostatních zaměstnanců tak, aby bylo dosaţeno celkové efektivity. Na základě analýzy provozovaných aplikací, poskytovaných sluţeb, sluţeb poskytovaných externími dodavateli a na základě zpětné vazby od zaměstnanců, zákazníků a specialistů z IT oddělení je navrţena optimální organizační struktura a správný způsob komunikace.

32

Pro zpracování strategie se vyuţívá nejen metod procesní analýzy, ale je moţné pouţít např. i metodiku ITIL . Základem návrhu řešení je pak definování SLA aplikací (dohoda o úrovni sluţby - rozsah technické podpory), HW, zmapování síťové infrastruktury a v neposlední řadě i analýza připravenosti infrastruktury z hlediska obnovy při výpadku. Plány postupu pro obnovu provozu a dat v kritických situacích jsou samozřejmou součástí návrhu IT strategie. V dalším kroku se zjišťuje, zda současné aplikační vybavení firmy je dostačující z hlediska plánovaného rozvoje. V případě potřeby je navrţeno rozšíření stávajících aplikací, optimalizace počtu aplikací a zjednodušení procesů práce s těmito aplikacemi. Součástí procesu tvorby IT strategie je i analýza způsobů uloţení dat a jejich zálohování, a to především vzhledem k dostupnosti v případě výpadku či jiné krizové situace. Výsledkem je návrh řešení diskového úloţiště s vazbou na zálohovací a obnovovací mechanismy včetně případného aplikačního vybavení pro optimální správu uloţených dat. Navrţená IT strategie je samozřejmě součástí celého informačního systému, který podléhá přísným kritériím na zabezpečení. Proces řešení zabezpečení informačních systémů IS je kontinuální, nikdy nekončící proces, jelikoţ se v průběhu času mění nejen vnější, ale i vnitřní podmínky a společnost musí na tyto změny reagovat - průběţně vyhodnocovat rizika a navrhovat opatření na jejich minimalizaci.

Informační strategie Východiska

Analýzy

Podnik.strateg. Cíle IS/IT

Architektury

Dopady IS

Projekty

Celková arch.

Organizační

Obsah

Funkční

Personální

Harmonogram

Analýza stavu IS

Analýza stavu IT

Způsob řešení Formulace krit.fakt IS/IT

A.vývoj.trendů IT

Datová

Ekonomické Zodpovědnost

Technolog.

Technologické

Ekonomika

Externí part.

Prac.náročnost

Obrázek 8 – Struktura informační strategie. Zdroj: www.cacio.cz/priloha/32

33

Bezpečný informační systém lze vybudovat jen díky aplikaci komplexních ochranných mechanismů. Těmito ochrannými mechanismy se rozumí soubor administrativních, technických, fyzických a logických opatření pro prevenci, detekci a opravu nesprávného pouţití informačních systémů. Příkladem technického (hardwarové) zabezpečení mohou být např. šifrovače, záloţní média, identifikační karty apod. Mezi logické (softwarové) bezpečnostní funkce patří např. antivirová ochrana, digitální podpis, apod. K opatřením administrativního charakteru patří např. zákony, předpisy, školení zaměstnanců apod. Bezpečnostní opatření fyzická pak mohou být např. mříţe, ostraha, zámky, trezor apod.

1.10. HW a SW ochranná opatření Šifrovací zařízení – je nejmocnějším prostředkem k ochraně dat před přečtením nepovolanou osobou. Data jsou převedena do nesrozumitelného tvaru, čímţ se dosahuje důvěrnosti dat, a protoţe data, která nelze běţně přečíst nelze ani upravovat, můţe šifrování plnit i funkci zajištění integrity. Rozlišujeme šifrování symetrickým klíčem, kdy je stejný klíč pouţíván pro šifrování i dešifrování. Výhodou tohoto způsobu je vyšší rychlost, nevýhodou pak je způsob distribuce klíče, tzn. jak zajistit aby se klíč dostal pouze k rukám příjemce, pokud je šifrování pouţito k přenosu zpráv. Šifrování asymetrickým klíčem znamená, ţe se pouţívají dva klíče, jeden veřejný a druhý privátní. Veřejný klíč je pouţíván veřejně, privátní je naopak v drţení jen jednoho člověka. Pokud je zpráva zašifrovaná jedním z klíčů, lze ji dešifrovat druhým klíčem, tzn., pokud zprávu zašifruji veřejným klíčem toho, komu je určena, můţe si ji přečíst jen ten, kdo zná soukromý klíč. Pokud však zprávu zašifruji svým privátním klíčem, mohou si ji přečíst všichni, kdo znají můj veřejný klíč. Tento způsob je pomalejší neţ šifrování symetrickým klíčem. Digitální podpis – je zaloţen na principu tzv. hašování. Ze zprávy je určitým definovaným způsobem vytvořen vzorek – hash, který je připojen ke zprávě a pak zašifrován privátním klíčem. Příjemce si stejným algoritmem zjistí hash hodnotu, veřejným klíčem odesílatele dešifruje elektronický podpis - coţ je hash hodnota při odesílání a porovná ji se svou zjištěnou hash hodnotou. Pokud jsou hodnoty stejné, znamená to, ţe při přenosu nedošlo k pozměnění zprávy. Šifrování dat v počítači je dalším moţným způsobem pouţití šifrování a vyuţívá se především u přenosných počítačů či šifrování záloţních dat nebo hesel. 34

Identifikační čipové karty – karta obsahuje digitální certifikát uţivatele a privátní klíč. Karta je chráněna heslem a můţe provést digitální podpis privátním klíčem. Certifikát slouţí pro přístup do aplikací. Zálohování – je proces vytváření kopií dat na záloţní nosiče, většinou to jsou magnetické pásky, externí pevné disky nebo disková pole. Tyto kopie se pořizují v určitých časových intervalech a umoţňují v případě bezpečnostního incidentu uvést informační systém do stavu před incidentem. Zálohují se nejen data, ale i operační systém, jeho nastavení apod. Systémy detekce a prevence narušení – sledují veškerý síťový provoz a detekují ohroţení. Systémy IDS detekují nebezpečí, aţ kdyţ projde sítí, systémy IPS stojí přímo v cestě a mohou tak aktivně zasáhnout např. zastavením provozu. V roce 2009 zachytil IPS cca 30 % útoků a antimalware 70 % útoků, v roce 2011 uţ zachytil IPS 70 % útoků a antimalware jen 30 % útoků. Firewall – tvoří ochranu mezi sítí nebo počítačem a internetem. Filtruje příchozí komunikaci a nepropustí zakázané pakety. Webová proxy a filtr – jde o zařízení přes které je přeposílána veškerá webová komunikace. Na základě nastavených pravidel je uţivatelům na dané stránky přístup buď povolen, nebo zablokován. V některých případech je součástí i antivirová, či antispywarová ochrana. E-mailová brána a spamfilter – brána sleduje veškerý e-mailový provoz a provádí jeho filtraci. Antivirový (antimalware) program – zajišťuje ochranu před škodlivým softwarem na základě identifikace signatur jednotlivých ohroţení. Antispyware – funguje na podobném principu jako antivirový program. Kontrola přístupu k síti – ověřuje identitu uţivatelů. V současné době je rostoucím zdrojem nebezpečí pouţívání USB flash disků. Šíří se přes ně nejen útočné kódy, ale mohou jejich prostřednictvím unikat i citlivá data. Blokování zápisu na ně můţe být dalším prvkem ochrany před ztrátou dat. 35

Pro uţivatelské přihlašování do systémů by měl být pouţíván alespoň systém „single signon“, ale v případě přístupu k VPN a klíčovým webovým aplikacím by bylo vhodnější vyuţívat hardwarové tokeny pro generování jednorázového hesla OTP (one-time password). Sofistikovanějším řešením jsou pak softwarové tokeny běţící na mobilních telefonech nebo hardwarové čipy generující OTP přímo na displej notebooku. Systémy pro řízení bezpečnostních incidentů (SIEM) umoţňují na základě automatické analýzy všech uloţených logů vytřídit z obrovského mnoţství událostí opravdové bezpečnostní incidenty. SIEM také umoţňuje vzniklý incident sledovat, řídit, případně jej pomoci vyřešit.

36

2. Krizové plány Krizové (havarijní) plány mohou být nedílnou součástí bezpečnostní politiky organizace, jak vyplývá z normy ISO/IEC 17799, kde řízení kontinuity je jednou z bezpečnostních zón viz obr. 6 (oddíl 10). I za situace, ţe má firma velmi dobře zpracované a v praxi fungující bezpečnostní předpisy, můţe se přihodit nějaká mimořádná nečekaná událost, kdy preventivní opatření selţou. Těmito mimořádnými událostmi se rozumí jakýkoliv bezpečnostní incident nebo havárie, které mají za následek narušení obvyklého chodu firmy (selhání IS) aţ do té míry, kdy je potřeba náhradních sluţeb k zajištění chodu a předejití ztrát. Havárií můţe být cokoliv od krátkodobého výpadku proudu přes výpadek klimatizace v serverovně, selhání datové sítě, napadení hackerem, výpadek internetu, působení počítačových virů, selhání hardwaru aţ po ţivelní pohromu, vyplavení nebo poţár. Aby byla firma na tyto nenadálé situace připravena, vytváří tzv. havarijní plány, coţ je jen jiné označení pro BCP (Business Continuity Plan) a DRP (Disaster Recovery Plan). Při tvorbě těchto plánů je vhodné postupovat podle doporučených metodik a v souladu s příslušnými standardy. Podle výzkumů společnosti Ernst&Young z roku 2009 nemá v České republice zpracovaný ţádný krizový plán přibliţně polovina firem, přičemţ zdokumentovaný a řádně otestovaný havarijní plán, má přibliţně čtvrtina organizací. Tato čtvrtina tak připadá na organizace, pro které by i malé přerušení mohlo znamenat ohroţení lidských ţivotů či obrovské finanční ztráty, tedy například letecká přeprava a zejména pak řízení letového provozu, nemocnice, dodavatelé energií a sluţeb telekomunikací, banky či velké internetové obchody. Management ostatních českých organizací zatím rizika výskytu havárií velmi podceňuje. Tento názor sdílí i senior manaţer společnosti Ernst&Young, David Kesl, dle jehoţ slov: „Většina společností v Česku ţije v mylné představě, ţe na ochranu před nenadálými událostmi ohroţujícími jejich podnikání jim stačí uzavřít pojištění s dostatečně vysokým krytím pojistného rizika. Neuvědomují si však, ţe i jen několikadenní přerušení jejich činnosti můţe způsobit nevratné škody. Nejde jen o finanční ztráty, často mnohem horší je ztráta zákazníků a dobré pověsti“. Právě určitá obchodní prestiţ, kterou si firma vytváří

37

mnoho let, a o kterou můţe přijít během pár dní, patří mezi jen velmi obtíţně a zdlouhavě obnovitelná aktiva firmy.

2.1. Business Continuity Plan BCP (Business Continuity Plan) je „Plán pro zachování provozu“, který se zaměřuje na obnovení procesů kritických pro chod společnosti (obnovu provozu IS) v co nejkratším čase, aby bylo zajištěno její přeţití a minimalizovány ztráty. BCP není zkratkou pouţívanou jen pro samotný plán, ale i pro celý proces plánování, tedy Business Continuity Planning, plán je pak výstupem tohoto procesu. Často se lze v této souvislosti setkat rovněţ s pojmem BCM (Business Continuity Management). Jde o manaţerskou disciplínu, která de facto zastřešuje BCP a propojuje celou řadu dalších oblastí. Britský standard BS 25999-1 definuje BCM jako: „Řídicí proces podporovaný vedením společnosti, který identifikuje potenciální dopady ztrát a jehoţ cílem je vytvořit takové postupy a prostředí, které umoţní zajistit kontinuitu a obnovu klíčových procesů a činností organizace v poţadovaných časech a na předem stanovené minimální úrovni, v případě jejich narušení nebo ztráty“. Dá se tedy shrnout, ţe řízení kontinuity činností - BCM, má za úkol předcházet incidentům, a pokud k nim dojde, tak zajistit, aby dopady na firmu byly co nejmenší. Dalším jejím úkolem je také zajistit, aby v určitém čase od incidentu byl obnoven provoz na určité úrovni a nakonec zajistit i přechod k běţnému provozu. Oba tyto pojmy BCP a BCM se vzájemně překrývají, protoţe tvorba BCP podléhá určitým pravidlům, jeţ jsou součástí BCM. BCMS pak znamená certifikovaný systém řízení kontinuity činností, který prosazuje procesní přístup k implementaci, provozování, monitorování, přezkoumávání a zlepšování všech činností ţivotního cyklu BCM.

38

Obrázek 9 - BCM rámec. Zdroj: http://www.checkpointontario.com/_bin/policies/continuity.cfm

2.1.1. Kontinuita činností v IT Myšlenka plánovat a řídit kontinuitu činností organizace vzešla z praxe, kdy se ukázalo, ţe v případě havárie je důleţité nejen obnovit funkčnost IS, ale ţe je potřeba dořešit také spoustu souvisejících problémů, jako např. přemístit zaměstnance do náhradní lokality a vytvořit jim podmínky pro práci, zabezpečit výrobní prostory, sklady, vyřešit komunikaci apod. Všechny tyto aspekty řeší BCP. Vymezení pojmů BCP a DRP se v odborných publikacích někdy různí. Je ale zřejmé, ţe DRP, který řeší plán obnovy ICT, je součástí

39

BCP. Plány kontinuity a obnovy vznikají pro jednotlivé kritické činnosti a detailně popisují postupy k zajištění kontinuity (v přechodném období) a k návratu do běţného provozu. Při plánování kontinuity v oblasti IT musíme vyřešit mnoho specifických problémů. Nenadálá událost či havárie v oblasti IT nemusí být nutně zaviněna nějakou přírodní katastrofou, častější naopak bývá virový útok, výpadek proudu, chyba administrátora, selhání hardwaru nebo technologií poskytujících infrastrukturní sluţby a přesto můţe být způsobená škoda velká. V praxi vidíme, ţe i nejlepší technologie nasazené na eliminaci konkrétních hrozeb nemusejí být vţdy dostatečné. Čistě technický přístup totiţ nezaručuje, ţe systémy budou fungovat, ţe budou dostupné ve správný čas, a na správném místě, a ţe jsme na všechny moţné situace připraveni. Pro mnoho firem i krátký výpadek sluţeb informačního systému můţe znamenat pokles zisku či produktivity, ztrátu příleţitostí nebo úbytek zákazníků. Je nezbytné, aby pro sluţby poskytované IT byl vypracován konkrétní systém řízení a plánování kontinuity činností s ohledem na celkovou infrastrukturu IS, která by měla být těmto potřebám přizpůsobena. Správně zvládnutý plán kontinuity činností znamená, ţe v okamţiku havárie budou všichni zodpovědní pracovníci vědět, co mají dělat, koho kontaktovat, jaké sluţby a v jakém pořadí sanovat. Právě tato opatření mají v danou chvíli nedocenitelnou hodnotu. Plán kontinuity zpracovaný na základě důkladných analýz umoţní soustředit se v okamţiku havárie na obnovu nejkritičtějších procesů či zachování aktiv. K ochraně zdrojů a systémů je zapotřebí zcela jasně definovat, které z nich jsou nejkritičtější z hlediska hlavní činnosti organizace. Klíčem k úspěchu je v kaţdém případě také pomoc a podpora managementu, který musí stanovit cíle, vyčlenit odpovídající zdroje a přidělit odpovědnosti a povinnosti. Důleţitým prvkem je také posilování povědomí o významu a důleţitosti řízení kontinuity činností. Jednou z moţností je zavedení programu školení.

40

Obrázek 10 - Postup vytváření plánu kontinuity. Zdroj: www.tsoft.cz/node/268

2.1.2. Ţivotní cyklus BCP Kvalitní zpracování plánů kontinuity činností by mělo být strategickým cílem jakékoliv organizace - od velkých nadnárodních společností aţ po malou či střední firmu. I kdyţ se masivnost nasazení konkrétních technologií bude v organizacích různého typu lišit, je nutné při navrhování plánů kontinuity zachovat stěţejní principy ţivotního cyklu řízení kontinuity. Tento cyklus vychází z normy BS 25999-1 a je znázorněn na následujícím obrázku.

41

Obrázek 11 - Ţivotní cyklus BCP/DRP. Zdroj: http://www.cesnet.cz/akce/2009/zazemi-pro-crt…/disaster recovery.pdf

Ţivotní cyklus BCM i BCP je prakticky shodný, ale u některých schémat znázorňujících BCM se můţeme setkat s tím, ţe první tři kroky zde znázorněné jsou skryté pod označením „Porozumění organizaci“ a kroky 5 a 6 pod označením „Vývoj a implementace BCM“. Na začátku tvorby BCP je nezbytná důkladná analýza prostředí organizace (ustanovení BCM) – jedná se o shromáţdění informací o cílech, aktivitách, zdrojích a aktivech firmy i o zúčastněných stranách. V další fázi je zapotřebí identifikovat kritické činnosti a aktiva, jejich zranitelnost a hrozby. Vyhledat kritické činnosti znamená umět procesy, které v organizaci probíhají, roztřídit. Nejjednodušší způsob je rozdělení na procesy: kritické – to jsou procesy, které vytvářejí výstupy pro externí zákazníky a které naplňují poslání organizace, podpůrné – jsou procesy uvnitř organizace, které podporují procesy kritické, vedlejší – jsou také procesy pro vnitřní fungování organizace, které je moţné zajistit smluvně zvenčí (outsourcing). K identifikaci těchto klíčových činností nám můţe pomoci analýza dopadů.

42

2.1.3. Analýza dopadů a analýza rizik Dalším krokem je provedení analýzy dopadů neočekávaných událostí na chod společnosti BIA (Business Impact Analysis), jejímţ úkolem je především analýza moţných rizik, odhad a kvantifikace následků havárie na organizaci. Pro kaţdou aktivitu se zkoumá nejdelší moţná doba jejího výpadku a minimální stupeň, na který musí být obnovena. Činnosti se kategorizují podle priority, kterou mají při obnově chodu. V rámci analýzy rizik je vyhotoven seznam rizik, která společnost ohroţují. Rizika jsou ohodnocena podle pravděpodobnosti vzniku a podle výše ztrát, které mohou způsobit. Dále se v této fázi často provádí analýza stávajících moţností obnovy (Recoverability Assesment), ve které je zjišťována stávající připravenost IT prostředí na řešení mimořádné situace. Zvláště u větších organizací je pro vypracování těchto analýz vhodné vyuţít sluţeb nějaké renomované externí firmy, která má nejen know-how potřebné pro jejich provedení, ale zároveň vnese díky své nezainteresovanosti kritický pohled na jednotlivé vazby a procesy uvnitř organizace. K hodnocení se vyuţívají standardní techniky, jako např. CRAMM, o které jiţ bylo hovořeno dříve. Výsledky analýzy dopadů a rizik mohou být také podkladem pro vytvoření tabulky (viz níţe), kde osa x představuje dopad na organizaci - škodu a osa y představuje pravděpodobnost výskytu – riziko. Na tyto osy se zaznamenávají jednotlivá rizika dle ohodnocení pravděpodobnosti vzniku a významnosti dopadu a podle výsledného umístění je moţné k nim zaujmout různé postoje, jak ukazuje následující graf na obr. č. 12. Akceptovatelné riziko je u zanedbatelných škod a malé pravděpodobnosti vzniku, v případě vysoké pravděpodobnosti vzniku ale malého dopadu je vhodné pouţít heuristická (nápravná) opatření sniţující míru rizika, pokud je míra pravděpodobnosti vysoká a dopady závaţné, měla by firma zváţit, zda je nezbytné toto činnost provozovat, případně podniknout preventivní opatření (odstranění zranitelných míst, školení) a při malé pravděpodobnosti vzniku ale velkých dopadech je prostor pro detekční opatření a havarijní plány, v úvahu připadá i moţnost pojištění.

43

Obrázek 12 - Analýza rizik-výběr opatření. Zdroj: http://tfirt.webst.fd.cvut.cz/10sem/bezpecnost_is/vypisky.pdf

2.1.4. Návrh strategie Jakmile jsou identifikovány klíčové procesy, známa rizika, hrozby a kvantifikovány zdroje (poţadavky na sítě, technologie apod.), musí společnost přijmout rozhodnutí o tom, jakou strategii zvolit pro zajištění kontinuity – tzn. vytvořit a dokumentovat proces reakce na incidenty pro kaţdý kritický proces. Aby nedošlo k neřízené reakci na incident, je nutné mít u kritických procesů i plány pro jednotlivé činnosti a také postup, kdy jednotlivé plány aktivovat. Je třeba definovat i postupy pro řízení vztahů se zúčastněnými stranami. Kaţdý uţivatel (člen vedení) by jistě chtěl mít zajištěnu 100% dostupnost sluţeb, většinou ale jen do té doby, neţ se dozví cenu za takové řešení. Ztráty z nedostupnosti sluţeb exponenciálně rostou s ubíhajícím časem, zatímco náklady na obnovu provozu se rapidně zvyšují se zkracujícím se časovým limitem pro obnovu. Výsledky BIA analýzy v korelaci s cenou slouţí jako dobré podklady pro určení optimálního času obnovy a volbu vhodné investiční strategie do této oblasti. V této fázi vzniká vlastní plán a jeho závazná 44

dokumentace pro provedení záchranného procesu. Jsou zde stanoveny jednotlivé kroky, kompetence apod. Při návrhu strategie obnovy je nutno se vyhnout dvěma extrémům. Jedním extrémem je „pouze technologické“ řešení, kdy robustní nasazení konkrétní technologie, bez zváţení širšího organizačního, technického a strategického kontextu, můţe znamenat zbytečně promrhané investice. Druhý extrém spočívá v „pouze papírovém plánování“, kdy plány obnovy sice obsahují samé dobré nápady, ale nikomu není jasné, jaké konkrétní důsledky z toho pro něj vyplývají.

2.1.5. Reakce na havárii Po zjištění havárie je zapotřebí nejdříve vyhodnotit její rozsah a následně rozhodnout, zda pro její zvládnutí je třeba aktivovat havarijní plány. Pokud ano, spustí se DRP a současně začínají probíhat další procesy BCP. Řízení situace převezme krizový tým, který byl sestaven. Tento tým rozhodne o tom, které krizové scénáře jsou pro danou situaci adekvátní a stanoví harmonogram obnovy a priority jednotlivých úkolů. Tým dále iniciuje a koordinuje řízení obnovy provozu tak, aby ztráty byly minimální, a zajišťuje alespoň provizorní provoz kritických sluţeb. V této situaci je vhodné převést část rozhodovacích pravomocí na týmy, které skutečně řeší danou situaci a managementu ponechat především koordinační a komunikační úlohu. Důleţitou součástí řešení vzniklé situace je zajištění krizové komunikace, a to jak mezi členy řešitelského týmu navzájem, tak i vůči všem zainteresovaným subjektům, tzn. zaměstnancům, partnerům, vlastníkům i akcionářům organizace. Po stabilizaci provizorního provozu a obnově kritických sluţeb je zahájena fáze rekonstrukce ICT, která by měla zajistit návrat k normálnímu provozu, tzn. ke stavu před havárií s tím, ţe prioritou se stává obnova dalších méně kritických sluţeb. Tato fáze můţe znamenat dlouhodobější proces, který pak probíhá buď v původní, nebo v nové lokalitě.

45

Obrázek 13 - Časový přehled reakce na incident. Zdroj: http://cs.wikipedia.org/wiki/Business-ContinuityManagement

2.1.6. Vytvoření plánů a implementace Poté, co je navrţena strategie, nastává fáze vytvoření plánů a jejich implementace. Z vytvořených plánů musí být zřejmé: -

co se má dělat,

-

kdy se to má dělat,

-

kdo to má dělat,

-

kde jsou potřebné zdroje,

-

jak bude dosaţeno kontinuity činností.

46

Nemělo by se zapomenout také na to, jakým způsobem bude zajištěn návrat od procesu obnovy k normálnímu provozu. Aby se předešlo rozptýlení celého dobrého záměru do spousty dílčích problémů, ke kterému můţe při zavádění řízení kontinuity ve větší organizaci snadno dojít, je dobré přidrţet se metody postupné implementace. Při takovém postupu je nejdříve perfektně vyřešena jedna omezená oblast - většinou ta, která obsahuje nejkritičtější a nejohroţenější procesy a tento funkční celek je postupně rozšiřován, aţ zahrne všechny důleţité procesy a aktiva organizace. Výsledkem této implementační fáze jsou vlastní plány kontinuity činností (Business Continuity Plan) a plány obnovy IS po havárii (Disaster Recovery Plan). Tyto plány obsahují návrhy vhodných technologických řešení např. technologie pro automatizované zálohování dat, technologie pro vytvoření záloţních pracovišť, pro monitorování narušení bezpečnosti apod. V budoucnosti je pak kaţdá nová technologie do těchto plánů zapracována.

2.1.7. Testování a údrţba Vytvořené plány se testují z hlediska moţných scénářů vzniku krizové situace. Testování je velmi důleţitou součástí celého procesu plánování a řízení kontinuity. Ačkoliv můţe být takové testování organizačně či finančně náročné, neexistuje ţádný jiný způsob jak zajistit, ţe se prostředky vloţené do tohoto procesu skutečně navrátí v podobě bezproblémového zvládnutí krizových situací. Pravidelné testování můţe probíhat například prostřednictvím dotazování zaměstnanců formou testu, zda vědí, co mají dělat. Ověřovat by se také měla funkčnost záloţních zdrojů a také to, zda by konkrétní činnost byla skutečně obnovena včas. Poslední důleţitou součástí ţivotního cyklu BCP je pravidelná aktualizace dokumentů včetně kontaktních údajů a audit. To poskytuje celému procesu potřebnou zpětnou vazbu a činí z něj neustále se zlepšující systém řízení. Aby plány odráţely aktuální potřeby organizace, měly by být v určitých časových intervalech přezkoumávány.

47

Celý proces plánování kontinuity je z hlediska ţivotního cyklu vlastně nekonečným procesem, při kterém se celý cyklus „analýza-návrh strategie-implementace-testování a údrţba“ opakuje stále znovu od začátku.

2.1.8. Produkty podporující BCP K modernímu plánování a řízení kontinuity je zapotřebí odpovídající softwarová podpora. Můţe jít např. o vytvoření portálu, který zajistí uloţení a dostupnost krizových plánů a důleţitých kontaktů v zabezpečené lokalitě, umoţní jejich testování, případně automatickou notifikaci klíčových osob v případě havárie. Existuje velké mnoţství technologií podporujících zajištění redundance, off-site storage, failoveru i vzdáleného zrcadlení dat. Před úmyslnými útoky můţe ochránit vytvoření vícevrstvého systému zabezpečení v kaţdém vhodném bodě infrastruktury. Mezi produkty podporující vytvoření BCP patří např. eBRP Toolkit1 nebo Business Continuity Plan Generator2. Existují i celá integrovaná řešení od renomovaných firem např. IBM, HP nebo Sun Microsystems, které nabízejí architektonická řešení zaměřená na zajištění kontinuity provozu a obnovu po havárii, coţ můţe být zajímavou alternativou k vlastním řešením.

2.2. Disaster Recovery Plan Jak jiţ bylo zmíněno, havarijní plány stanovují postupy pro řešení nestandardní situace po bezpečnostním incidentu a měly by pokrýt celé období od vzniku mimořádné události přes rychlé zpřístupnění kritických funkcí aţ po úplnou obnovu. Jedná se o souhrn konkrétních, přesně definovaných a zdokumentovaných opatření pro pouţití v mimořádných situacích. DRP (Disaster Recovery plan) detailně popisuje sled činností pro zajištění úplné obnovy ICT sluţeb v definovaném časovém rozpětí, a je z tohoto pohledu určitou podmnoţinou plánů BCP, které se týkají všech činností ve firmě.

1

Dostupný na http://www.ebrp.net/toolkit.htm

2

Dostupný na http://www.business-continuity-and-disaster-recovery-world.co.uk/

48

Existence těchto plánů souvisí se zaměřením a velikostí firmy. Pro všechny je společným cílem minimalizovat dopady nepředvídaných událostí na obchodní výsledky společnosti a současně optimalizovat zdroje na zajištění opětovného fungování. Vypracování těchto plánů je náročná disciplína a existují dva způsoby, jak se k nim dopracovat – buď vlastními silami, nebo prostřednictvím specializované externí firmy, která disponuje propracovanou a ověřenou metodikou. Těchto sluţeb vyuţívají z finančních důvodů převáţně velké firmy. Na následujícím obrázku jsou znázorněny vzájemné vztahy mezi BCM, BCP a DRP.

Obrázek 14 – Hlavní části BCM a jejich vzájemné vztahy. Zdroj: [20]

49

2.2.1. Strategie a plán obnovy Ihned po narušení bezpečnosti ICT musí být k dispozici předem určený krizový tým lidí, jehoţ úkolem je zajištění nouzového stavu. Tým informuje další pracovníky odpovědné za řešení incidentu a postupuje podle předem vypracovaných plánů. Plán obnovy by měl řešit: kontaktní údaje (členů týmu, klientů, dodavatelů, servisních firem, apod.), definice incidentů a postupy jak jednat v konkrétní situaci, pořadí obnovy, jaké jsou nejdelší přípustné doby výpadku pro jednotlivé činnosti, seznam členů krizového týmu, úkoly jednotlivých členů týmu, podmínky, za jakých dojde k aktivaci plánu, dostupnost zálohovaných dat, zajištění komunikace, postupy jak jednat v konkrétní situaci, popis plánovaného průběhu obnovy a popis obnovy jednotlivých systémů, zavedení systému varování, testování a údrţba plánu.

Vytvořený plán by měl být jednoduchý, stručný, jasný, přehledný a dostupný. Tvorba a údrţba DRP podléhá stejnému ţivotnímu cyklu jako tvorba BCP (viz výše). Jednotlivé fáze můţeme shrnout do několika bodů:

50

odhalení hrozeb (zohlednit specifika dané lokality), analýza prostředí (infrastruktury, jednotlivých činností), analýza rizik a dopadů (BIA), návrh strategie (dokumentace, lidské zdroje) a její implementace, aktualizace, školení a testování (ověření funkčnosti strategie).

Obrázek 15 – Postup tvorby havarijních plánů. Zdroj: http://tfirt.webst.fd.cvut.cz/10sem/bezpecnost_is/vypisky.pdf

Jak vyplývá z předchozího textu a jak ukazuje obrázek č. 15, principy pro tvorbu plánů DRP i BCP jsou stejné. Vycházejí z celkového zhodnocení současného stavu, dále se analyzují rizika a hodnotí se dopady na aktivity organizace. Pak jsou navrţena konkrétní opatření a následuje jejich implementace. Na závěr probíhá ještě jejich testování,

51

pravidelná aktualizace a proškolování zaměstnanců, protoţe cílem celého cyklu je zabezpečit stálou aktuálnost a realizovatelnost plánu. Při tvorbě DRP se vychází z analýzy dopadů BIA (Business Impact Analysis), která konkretizuje důsledky přerušení kritických procesů (kaţdý proces zvlášť) pro organizaci a stanoví dobu, do které musí být procesy obnoveny. Zde je jedním z nejdůleţitějších faktorů správné stanovení hodnot Recovery Point Objective (RPO) a Recovery Time Objective (RTO). RPO znamená akceptovatelnou ztrátu údajů jako časový úsek před havárií, který si můţeme dovolit ztratit. RTO vyjadřuje časový úsek od havárie, do kterého je nutné obnovit provoz IS (klíčových procesů), neboli představuje maximálně akceptovatelný čas výpadku. Obnovení funkčnosti kritických procesů v sobě zahrnuje obnovování funkčnosti jednotlivých systémů, které se mnohdy nedají obnovovat paralelně. Je proto dobré si předem připravit časové harmonogramy obnovy jednotlivých systémů podle toho, zda na sebe navazují nebo zda se mohou provádět současně. Celková délka obnovy totiţ nesmí přesáhnout hodnotu RTO. Na základě stanovení těchto hodnot je třeba zvolit vhodnou strategii obnovy. Strategie určuje a vybírá vhodné metody slouţící k zachování kritických procesů v době havárie a současně určuje principy a základní východiska pro návrh plánů obnovy. V praxi se na základě individuálních potřeb vyuţívají tyto strategie zálohování kritických zdrojů nebo jejich kombinace: DR Hot site (horká záloha) je pracoviště v alternativní lokalitě s plným HW, SW a komunikačním vybavením, kompatibilním s původním působištěm-restart v řádu hodin. Obvykle se zde provozuje jen nejnutnější část IS, která je potřebná pro udrţení funkčnosti organizace. Současně musí být k dispozici funkční zálohy dat. DR Warm site je lokální pracoviště, kde je moţná rekonfigurace tak, aby byl umoţněn přístup do vzdáleného centra obnovy.

52

DR Cold site znamená vyhrazené klimatizované prostory se základními sítěmi bez HW a SW, kde je moţné zahájit proces obnovy. DR Mirror site je identické, kompletně vybavené pracoviště v geograficky dostatečně vzdálené lokalitě. Pro oblast obnovy dat se pouţívají strategie: zálohování na externí paměťová média a jejich uchovávání mimo místa zpracování, zálohování na disky v místě zpracování a jejich automatické kopírování na disky ve vzdálené lokalitě, replikace údajů na infrastrukturu umístěnou ve vzdálené lokalitě. Při výběru vhodné strategie platí zásada, ţe náklady na obnovu by neměly být vyšší neţ moţná ztráta způsobená havárií. V oblasti technické jde o investice do infrastruktury, záloţních zdrojů, náhradní lokality apod. U organizačních opatření se jedná o aktualizaci dokumentů, změny smluvních vztahů s dodavateli apod. Z následujícího grafu (obr. 16) je zřejmé, ţe náklady na obnovu jsou nejprve vyšší neţ ztráta z nedostupnosti procesů, po určité době se křivky protnou a následně začínají růst ztráty z nedostupnosti, zatímco náklady na obnovu klesají. Průsečík těchto křivek nám naznačuje, jaká je optimální výše nákladů na implementaci opatření pro zachování kontinuity a jaké jsou optimální časy obnovy. Struktura DRP je dále závislá na velikosti a poţadavcích organizace a musí zohledňovat její technickou a technologickou infrastrukturu. Dále musí být v souladu s cíli organizace a s plánem kontinuity činností BCP. Samozřejmě musí splňovat i zákonné předpisy, technické normy, interní pravidla apod.

53

Obrázek 16 – Porovnání nákladů na obnovu a ztrát z nedostupnosti procesu. Zdroj: www.cimib.cz/fileadmin/user upload/prezentace/02 cimib Chlup.pdf

2.2.2. Sedm vrstev DR Ze znalosti prostředí firmy můţeme dovozovat, jaké problémy ji ohroţují a zaměřit se tak na jednotlivé činnosti z pohledu jejich významu pro společnost a rychlosti s jakou bude potřeba tyto činnosti obnovovat. Americká uţivatelská společnost SHARE ve spolupráci s IBM definovala sedm vrstev pro plánování procesů Disaster Recovery: VRSTVA 0 – No off-site data Jedná se o stav, kdy společnost nemá ţádné zabezpečení, ţádná zálohovaná data, záloţní HW, ani plán obnovy. Čas obnovy se v tomto případě nedá definovat. Takováto společnost se vystavuje riziku, ţe v případě nenadálé skutečnosti se z ní nemusí vzpamatovat. VRSTVA 1 – Data backup with no Hot Site V tomto případě má společnost implementované zálohovací řešení, v němţ jsou duplikovaná data ukládána ve stejné lokalitě jako původní. V závislosti na délce uchovávání záloh je moţné definovat, v jakém čase lze informace obnovit. Nevýhodou 54

tohoto řešení je, ţe k vyřešení problému dojde aţ v době, kdy se dokončí obnova ze záloh. Pokud je problém rozsáhlý, můţe se dotknout i záloh, které poté nebude moţné obnovit. VRSTVA 2 – Data backup with a Hot Site Jedná se o stejný stav jako v předešlém případě s tím rozdílem, ţe zálohovací řešení ukládá data mimo původní lokalitu. Tím jsou firemní data při nastalé kritické situaci zabezpečenější. K vyřešení problému dochází opět aţ po obnově dat ze zálohy. VRSTVA 3 – Electronic vaulting Třetí vrstva je vylepšením druhé vrstvy, přičemţ se v zálohovacím řešení upraví podmínky zálohování vybraných kritických firemních dat, jeţ jsou primárně ukládána na rychle dostupné úloţiště a několikrát duplikována. Data jsou ukládána elektronicky (bez fyzické manipulace) mimo původní lokalitu. Také je vytvořen plán, který zajistí prioritní obnovení těchto dat. VRSTVA 4 – Point-in-time copies V této vrstvě je moţné aplikovat spojení zálohovacího řešení s funkcionalitou hardwarových diskových polí (například FlashCopy). Celkové zálohování má mít co nejniţší vliv (zátěţ) na stávající infrastrukturu. Jako nejvhodnější se v tomto smyslu ukazují diskové prostory na centrálních úloţištích (síť Storage Area Network). VRSTVA 5 – Transaction integrity V této vrstvě se jiţ implementuje hardwarové i softwarové nastavení pro vybrané komponenty, kde produkční i záloţní lokalita (stejné umístění) ve společnosti obsahuje stejná data. Implementované zálohovací řešení pracuje jako dodatečný nástroj pro obnovu zálohovaných a archivovaných dat. VRSTVA 6 – Zero or little data loss Duplikace produkčních a záloţních komponentů (rozlišené lokality) ve společnosti se vztahuje na širokou sféru firemních dat. Při výpadku jedné části v lokalitě přebírá funkcionalitu druhá část. Zálohovací řešení se implementuje v kaţdé z lokalit, a to s moţností plného zastoupení.

55

VRSTVA 7 – Highly automated, business-integrated solution Jedná se o automatizované řešení, které zajistí úplnou duplikaci a integraci dat mezi lokalitami společnosti. Proces obnovy po ztrátě dat je plně automatizovaný. Společnost má vytvořen podrobný plán definující postup obnovy, velký důraz je kladen na nepřerušení funkcionality komponent ve společnosti. Z uvedeného je zřejmé, ţe čím kratší je čas potřebný k celkové obnově RTO, tím se zvyšují finanční nároky na realizaci řešení, a je tedy třeba najít kompromis mezi těmito aspekty.

2.2.3. Postup při výběru IT technologií pro DRP V momentu, kdy se při řešení plánů Disaster Recovery dostáváme k samotnému návrhu řešení, musíme vzít v úvahu všechny předchozí parametry, které jsme jiţ zmiňovali. Vrátíme-li se zpět k modelu 7 vrstev, nalezli bychom pro kaţdou vrstvu několik moţných řešení pro výběr konkrétních technologií od nejrůznějších výrobců, jsme ale samozřejmě limitovaní stávajícím prostředím. V dalším kroku bychom se měli snaţit zařadit jednotlivé procesy a s nimi spojené IT aplikace do výše zmíněného modelu. Při tomto zařazování by měly být procesy a aplikace rozdělené do několika skupin podle času poţadovaného pro obnovu (RTO). V kaţdé skupině se tedy budou nacházet procesy a aplikace buď s nízkou, střední nebo vysokou hodnotou RTO. Prolnutím těchto dvou pohledů se nám zúţí moţnosti výběru a my budeme zvaţovat další otázky, jako jsou např.: jaké mnoţství dat se má obnovovat, jaké aplikace se budou obnovovat, na jaké HW a SW platformě aplikace jsou, jaká forma konektivity mezi primárním a sekundárním zařízením je k dispozici, atd.

56

Tím se nám prostor pro výběr bude dále zmenšovat, aţ nakonec budeme schopní vybrat řešení, které bude odpovídat našim poţadavkům.

2.2.4. Současné trendy v DR Zajištění vysoké dostupnosti klíčových aplikací a ochrany dat je v dnešní společnosti čím dál významnějším poţadavkem, protoţe cena ztráty dat či výpadku některých IT systémů můţe být nevyčíslitelná. Dostupnost (High Availability) HA je definována jako zajištění moţnosti uţivatelů přistupovat ke svým systémům a získávat informace v okamţiku potřeby. Vysoká dostupnost je systémový návrh postupu, který zajistí poţadovaný stupeň provozní stability během určitého období. Pro návrh takového postupu je klíčovým parametrem doba obnovy RTO. V souvislosti s vysokou dostupností a minimalizací doby obnovy se dnes často mluví o virtualizaci. Můţeme si ji představit jako určitou mezivrstvu mezi virtualizovaným systémem a zařízením či mezi dvěma systémy tak, aby se staly na sobě nezávislými.

Obrázek 17 - Znázornění virtualizace. Zdroj: www.kancelarskestroje.cz/uploads/assets/stories

Pochopení principu virtualizace nám dovoluje efektivně vyuţívat její vlastnosti v IT a pracovat s daty a aplikacemi kontinuálně bez výpadků či jiných omezení v případě havárie. Nejpouţívanější způsob vyuţití virtualizace pro DR je serverová virtualizace. Je to mezivrstva mezi operačním systémem a HW (viz obr. 17). Operační systém se tak stává nezávislým na HW, na kterém běţí, coţ přináší řadu výhod právě pro DR. Důvodem postupného rozšiřování serverové virtualizace je především skutečnost, ţe pro IT je zajištění bezpečného chodu serverů prioritou, protoţe jejich havárie má na provoz společnosti nejvyšší dopad. Výhody serverové virtualizace:

57

v případě havárie HW můţeme náš server spustit téměř na libovolném zařízení se srovnatelným výkonem, dobu zprovoznění systému po výpadku dokáţeme zkrátit z několika hodin aţ dnů na výpadek v řádu minut aţ sekund, jednoduše a efektivně dokáţeme provádět ověřování a testování nastaveného DRP, nízká finanční náročnost na udrţení DRP ve funkčním stavu. Mezi nejznámější firmy nabízející virtualizační nástroje patří VMware, Cyrix a Microsoft. Z hlediska tvorby DRP jsou v praxi nejpouţívanější tyto způsoby ochrany: 1. off-line záloha systémů: a) pokud pouţíváme fyzický server, pouţijeme vhodnou HW náhradu tohoto serveru, aby v případě výpadku bylo zajištěno, ţe dokáţeme tento server či systém ze zálohy obnovit. Je nutné mít dostupnou zálohu a HW, na němţ systém obnovíme, b) virtuální systémy; zde existují dvě moţnosti: pouţíváme fyzický server a virtuální server máme jen pro případ havárie. Tento virtuální server pravidelně zálohujeme a pravidelně obnovujeme s fyzickým, máme plnou virtualizaci, kdy je virtuální systém uloţený na diskovém poli. V případě havárie serveru jsme schopni zprovoznit systém na jiném serveru bez zásahu administrátora. U obou těchto variant můţe uţivatel přijít v případě výpadku o některá dosud neuloţená data. 2. on-line záloha s vysokou dostupností Máme dva systémy, které běţí paralelně, tzn., ţe musíme mít k dispozici 2 HW, na kterých běţí jeden systém. Data jsou ukládána souběţně na oba

58

systémy, a proto má uţivatel v případě výpadku k dispozici vţdy jeden funkční systém. Uţivatel ani nepozná výpadek a neztratí ţádná data. Zkušenosti z praxe ukazují, ţe on-line záloha se vyuţívá nejčastěji u kritických systémů, v ostatních případech je nejčastěji vyuţívána varianta s virtuálními systémy, tzn. 1b).

2.2.5. Legislativa a standardy Vybrané předpisy a normy, které se vztahují k bezpečnosti informací, řízení kontinuity činností a tvorbě plánů jsou např.: Zákon č. 240/2000 Sb., o krizovém řízení a o změně některých zákonů, ukládá státním organizacím povinnost mít připravené krizové plány a spolupracovat na jejich přípravě s ministerstvy. Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonůtýká se dat, která se dají povaţovat za osobní, tzn. taková, na základě kterých lze přímo či nepřímo identifikovat o jakou osobu či subjekt se jedná. Zákon č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti – připadá v úvahu u firem, které spadají pod pravomoc příslušné právní normy (mohou to být např. i dodavatelé zboţí a sluţeb pro ozbrojené síly). Zákon č. 241/2000 Sb., o hospodářských opatřeních pro krizové stavy a o změně některých souvisejících zákonů. Z osvědčených standardů je moţné jmenovat např.: ISO/IEC 27001:2005 (BS 7799-2) specifikuje poţadavky na vytváření, provádění, provozování, udrţování a zlepšování systému řízení informační bezpečnosti, ISO/IEC 24762:2008 stanoví obecné zásady pro informační a komunikační technologie sluţby Disaster Recovery, ISO/IEC 22399:2007 poskytuje základ pro pochopení, rozvoj a implementaci kontinuity činností a sluţeb v organizaci,

59

ISO/IEC 27002:2005 určen pro rozvoj bezpečnostních norem a postupy řízení bezpečnosti, ISO/IEC 27031:2011 popisuje principy připravenosti ICT technologií k zajištění kontinuity provozu, CobiT je soubor praktik, které by měly umoţnit dosaţení strategických cílů organizace díky efektivnímu vyuţití dostupných zdrojů a minimalizaci IT rizik, ITIL je soubor publikací zaměřených na nejlepší zkušenosti s řízením sluţeb IT, SAS70 standard, který je moţné doporučit pro audit při posuzování vnitřní kontroly (proces zachování kontinuity činností je nezbytný pro zachování účetní průkaznosti, tj. zaručení integrity nejen účetních záznamů, ale i všech kritických procesů), BS 25999-1:2006 britský standard – stanovuje základní principy a poskytuje doporučení pro implementaci BCP v organizaci (základem tohoto standardu byla veřejně dostupná specifikace PAS 56 z roku 2003), BS 25999-2:2007 obsahuje poţadavky pro certifikaci systémů řízení kontinuity činností, BS 25777-2008 pomáhá porozumět hrozbám při dodávce ICT sluţeb, identifikovat potenciální dopady při přerušení ICT sluţeb. Ekonomika USA, která se problémem zachování kontinuity činností v krizových situacích zabývá uţ dlouhou dobu, vychází především u organizací ve státním sektoru z normy NIST SP 800-34 Contingency Planning Guide for Federal Informatic Systems. Tato norma řeší otázky systému řízení kontinuity činností podniků a státních organizací. Zabývá se strategií a tvorbou plánů včetně doporučených postupů testování těchto plánů. Tato norma třídí krizové plánování do následujících oblastí: Plán zachování kontinuity organizace (Business Continuity Plan - BCP) – definuje postupy jak zajistit procesy organizace po mimořádné události;

60

Plán kontinuity činností (Continuity of Operations Plan - COOP) – připravuje koncept zajištění náhradního způsobu řešení pokračování činností na jiném místě; Plán krizové komunikace (Crisis Communication Plan) – stanovuje pravidla pro interní i externí komunikaci; Plán ochrany kritické infrastruktury (Critical Infrastructure Protection Plan - CIP), obsahuje souhrn procedur, které slouţí k ochraně a obnově technických prostředků; Plán reakce na kybernetické incidenty (Cyber Incident Response Plan) – řeší způsoby jak předcházet, odhalovat a reagovat na kybernetické útoky; Plán obnovy po havárii (Disaster Recovery Plan - DRP) – soustřeďuje se na obnovení činností organizace se zaměřením na IT; Plán zvládání mimořádných událostí informačního systému (Information System Contingency Plan - ISCP) obsahuje postupy pro ohodnocení rozsahu škod a postupy obnovy; Plán evakuace osob (Occupant Emergency Plan - OEP) - řeší evakuaci osob v případě ohroţení ţivota a zdraví osob.

2.3. Shrnutí V předchozích kapitolách jsem se zabýval teorií zabezpečování informačních systémů, a to z mnoha úhlů pohledu. Všechna tato pravidla jsou samozřejmě platná v kterémkoliv podniku, je však důleţité je přizpůsobit na míru tak, aby vyhovovala nejen z hlediska zaměření firmy, ale také s ohledem na to, o jak velkou organizaci se jedná. V závislosti na tom, jak je firma velká a jak sloţitou organizační strukturu má, se bude odvíjet samotný postup tvorby zabezpečení. U malých firem většinou dochází k zavádění bezpečnostních opatření „zdola“. Nejprve bývá vypracován určitý záměr chránit nejdůleţitější aktiva firmy a po úspěšné implementaci postupně dochází společně s rozvojem organizace k dalšímu rozšiřování zabezpečení. Tento způsob můţe vyhovovat aţ do okamţiku překročení určitého stupně rozvoje, kdy uţ je pro organizaci tento stav nevyhovující a přejde na způsob tvorby 61

„shora“, coţ je způsob, který se pevně opírá o všechny výše popsané principy a normy, kdy je vytvořena celá fungující struktura (formalizovaný způsob tvorby). Pro obě varianty však platí, ţe proces tvorby musí projít několika kroky od záměru, přes analýzu, stanovení principů a odpovědností aţ k projektu a jeho implementaci. Některé kroky mohou být prováděny současně, případně můţe být jejich pořadí přehozeno.

62

3. Příprava projektu rozdělení společnosti V této kapitole nejprve představím společnost, ve které působím a předestřu okolnosti, které vedly k jejímu rozdělení na dva samostatné subjekty, díky čemuţ bylo moţné realizovat mnoho změn majících vliv na zabezpečení ICT. V další části, v rámci přípravy projektu, provedu analýzu infrastruktury celé společnosti před jejím rozdělením, a to především z hlediska zabezpečení a připravenosti na havárie.

3.1. Představení společnosti Jedná se o americkou společnost s celosvětovou působností (dále téţ koncern), zabývající se vývojem, výrobou, prodejem a servisem biochemických, imunochemických a hematologických analyzátorů k automatizaci, zjednodušení a zefektivnění provozu klinických laboratoří, dále přístrojů pro biomedicínský výzkum jako jsou centrifugy, ultracentrifugy, průtokové cytometry, pipetovací roboty, spektrofotometry nebo třeba přístroje na charakterizaci velikosti a tvaru částic. Kromě přístrojů a širokého spektra spotřebního materiálu, jako jsou např. provozní chemie, kalibrační soupravy, rotory, kapiláry apod., patří mezi důleţité produkty společnosti ještě reagenční chemie a manuální imunodiagnostické soupravy ve formátu RIA, ELISA a LIA. Právě tyto soupravy se vyrábějí pouze ve třech pobočkách společnosti, v USA, ve Francii a především tady u nás v České republice. Jedná se o soupravy, u nichţ některé sloţky obsahují radioaktivní indikátor. A právě s těmi má původní společnost v ČR více neţ dvacetileté zkušenosti. Tato původní česká společnost se neubránila globalizačnímu procesu, kdy došlo nejdříve k fúzi s francouzskou společností, a pak dvěma následnými kroky se stala součástí této americké korporace. Oproti původnímu zaměření čistě na výzkum a výrobu manuálních diagnostických souprav se tak zdejší společnost rozrostla a převzala roli výhradního poskytovatele celého portfolia výrobků a sluţeb této americké společnosti pro Českou republiku. Pozitivní efekt celého procesu byl také v konsolidaci výrobních programů ostatních entit (pro potřeby této práce jsou entitami označovány lokalizované součásti koncernu bez ohledu na právní subjektivitu) s podobným výrobním programem, jaký byl v původní české společnosti.

63

Díky tomu došlo k významnému nárůstu objemu výroby a výrobky se nově daří, i díky rozvinuté obchodní síti mateřské společnosti, realizovat na mnoha do té doby nepřístupných trzích. Spolu s rozšířením a novým americkým vedením přišlo pochopitelně mnoho změn. Objekt, ve kterém se tato česká pobočka nacházela, byl kapacitně nedostačující, ale laboratoře s kontrolovaným pásmem pro práci s radioaktivními látkami a výrobní linky bylo téměř nemoţné přesunout do nové lokality, a proto byla přistavena nová budova. Spolu s organizační strukturou se postupně adoptovaly standardy a procedury koncernu a začaly se realizovat první větší investice do IT infrastruktury. Nově vzniklé IT oddělení postupně přetvářelo do té doby minimální a zcela nestandardní infrastrukturu. Harmonizace s mateřskou společností však probíhala velmi pozvolna. Jedním z důvodů byla nepřipravenost amerického informačního systému (dále téţ IS) pro nasazení v ČR. Dalším důvodem, moţná překvapivě, byla i skutečnost, ţe firma vytvořila a řadu let vylepšovala „systém kvality“, který je podkladem pro certifikaci kvality ISO 9001, a bez kterého by své produkty nemohla prodávat. Změna výrobních podmínek (přemístění výroby, řízení výroby pomocí jiného IS) by způsobila zásadní dopad do systému kvality a firma na takovou změnu z důvodu nedostatečných zdrojů prozatím nepřistoupila. Firma si tak s sebou nesla kromě neustále rostoucího ERP systému, vyvinutého in-house na platformě DataFlexu, také mnoho neustále rostoucích a vyvíjejících se dokumentových databází na platformě Lotus Notes.

3.2. Rozdělení společnosti Snahou amerického vedení bylo upravit v nových entitách podmínky tak, aby vyhovovaly i americkým zákonům, zvláště zákonu SOx (Sarbanes–Oxley Act), protoţe koncern je společností kótovanou na amerických akciových trzích. Také naše závislost na IS se ukazovala jako čím dál větší překáţka – pro naše komerční operace byl přístup do koncernového IS nezbytností, ale koncernový IS nebyl schopen v poţadovaném rozsahu poskytovat podporu výrobní části firmy. Z obou uvedených důvodů vznikala velká mnoţství úkolů a řešitele demotivovala skutečnost, ţe jde o řešení prozatímní. A přesto, ţe bylo nakonec nalezeno nejlepší moţné řešení, jen výjimečně ho bylo moţné označit jako uspokojivé.

64

Situace volala po provedení rozsáhlé analýzy, která by mohla být podkladem pro projekt komplexního řešení přestavby IT struktury, řízení a monitorování přístupů do budov, resp. jejich jednotlivých částí, ale i k IT aplikacím a datům. Naší snahou bylo do tohoto projektu včlenit i havarijní plány. Přístup vedení společnosti však nebyl k tomuto problému vstřícný, protoţe nadřízené sloţky nic takového zatím nepoţadovaly, a proto to mělo nízkou prioritu, mj. i z důvodu omezených zdrojů. Práce na projektu byla zahájena v roce 2008 vlastními silami (pracovníky IT). Jednotlivé části byly průběţně diskutovány s nadřízenou IT sloţkou v evropské centrále. Jiţ v průběhu roku bylo pořizování některých potřebných investičních celků voleno tak, aby zapadaly do budoucího řešení. Ke konci roku byl ale projekt pozastaven. Důvodem byla informace o připravované velké akvizici, která s sebou přinese řadu změn. A jak se následně ukázalo, šlo o změny natolik zásadní, ţe bylo třeba celý projekt přehodnotit. K restrukturalizaci sloučených firem dochází prakticky vţdy. Je to přirozeným důsledkem globalizačního procesu, kdyţ se řízení koncernu, vzniklého nesourodými akvizicemi, stane neefektivním. Impulzem pro rozsáhlou restrukturalizaci koncernu se stala akvizice části jiného koncernu. Došlo k nárůstu počtu zaměstnanců zhruba o pětinu a v ostatních ekonomických parametrech byl příspěvek vyvolaný akvizicí podobný. Prakticky celosvětově došlo v koncernu na lokálních úrovních ke splynutí dvou týmů a dvou problematik, a to zhruba v podobných proporcích (5:1). Motivem záměru restrukturalizovat koncern bylo zvýšení efektivity řízení a rentability koncernu. Tím, jak koncern rostl, bylo čím dál obtíţnější řídit stejným mechanizmem značně odlišné podniky. Vedoucí pracovník se svým týmem orientovaný například na výrobní činnost, nebyl většinou schopen efektivně řídit činnost komerční, a naopak. Proto bylo přijato rozhodnutí sjednotit jednotlivé činnosti (výzkum, vývoj a výrobu, marketing a obchod, servis) do divizí, a vytvořit jim samostatnou řídící strukturu aţ na úroveň nejvyššího vedení koncernu. Tyto divize se v jednotlivých lokalitách samozřejmě neobejdou bez podpůrných útvarů, z nichţ nejdůleţitější jsou - útvar IT, útvar lidských zdrojů (HR) a útvar zabezpečování jakosti (QA).

65

Jednotlivé entity byly vyzvány, aby vypracovaly projekt, který povede k realizaci záměru a bude přihlíţet k potřebám a moţnostem dané entity, především jejímu zaměření a její velikosti. Procesu restrukturalizace se nevyhnula ani česká součást koncernu. Na tvorbě projektu restrukturalizace české entity se účastnily všechny útvary společnosti. Avšak ani v tomto okamţiku management společnosti z důvodu jiných priorit nepodporoval začlenění principů BC a DR do vznikajícího projektu, ačkoliv to útvar IT poţadoval. Proto se útvar IT rozhodl vyuţít této příleţitosti a formou souběţného projektu na lokální úrovni navrhnout a realizovat opatření ke zvýšení bezpečnosti ICT Hlavními úkoly obou projektů bylo: rozdělení společnosti na dvě samostatné společnosti (právnické subjekty), v původní společnosti - nazývejme ji P (Původní) ponechat vývoj a výrobu, do nově zaloţené společnosti - nazývejme ji N (Nová) přenést veškeré komerční aktivity a sluţby, společnost P bude prodávat své výrobky výhradně prostřednictvím společnosti N, společnost N se přemístí do objektu v lokalitě vzdálené 3 aţ 10 km od společnosti P (dolní mez uvedeného intervalu byla poţadavkem IT, aby se minimalizovalo riziko případného současného zničení sídel obou společností a horní mez byla poţadavkem vedení společnosti, aby při předpokládaném hojném styku zaměstnanců obou společností nedocházelo k velkým časovým ztrátám), společnost P si ponechá útvar zabezpečování jakosti a společnost N si tyto sluţby bude od P nakupovat, do společnosti N přejdou útvary IT, HR a ekonomický útvar a společnost P si tyto sluţby bude od N nakupovat.

66

3.3. Analýza infrastruktury a jejího zabezpečení před rozdělením společnosti V této kapitole resp. jejích podkapitolách jsou uvedeny jednotlivé celky analýzy infrastruktury.

3.3.1. Informační systém Jak jiţ bylo řečeno, dominantou informačního systému zdejší pobočky je ERP (Enterprise Ressource Planning) systém vyvinutý svépomocí na platformě Dataflexu s tím, ţe jeho úpravy, optimalizace a přizpůsobení novým potřebám společnosti probíhají do současnosti. Jeho nespornou výhodou je tedy naprostá kompatibilita a podpora výrobních procesů firmy a také to, ţe jej zdejší kmenoví zaměstnanci velmi dobře ovládají. Nevýhodou tohoto ERP systému je zejména jeho zastaralost, a to jak z hlediska technického, tedy čím dál horší kompatibilita

s novými

operačními systémy a nízký výkon

systému,

z hlediska

tak

grafického

rozhraní, s nímţ se jakoby vracíte zpět v čase, do éry DOSu.

Zprovoznit

tento

systém na nějakém novém počítači

byla

nejdříve

celkem výzva, naštěstí se později

podařilo

systém

a spouštěcí soubory upravit Obrázek 18 - ERP systém. Zdroj: vlastní

tak, ţe dnes je zprovoznění

systému na novém počítači pro stávající uţivatele otázkou několika sekund a pro nového uţivatele do 15 minut. Proces případné obnovy tohoto systému při nějaké havárii byl ovšem v onu dobu zcela nepopsaný, plný neznámých proměnných.

67

Přístup do ERP systému je zabezpečen na dvou úrovních. Uţivatel musí mít aktivní doménový účet a musí být členem příslušné skupiny, umoţňující přístup k souborům systému. Dále musí mít vytvořený profil v samotném systému, který určuje jeho oprávnění uvnitř systému a strukturu menu. Pro vstup do systému pak jiţ stačí být přihlášen doménovým účtem do počítače a spustit aplikaci. Jako poštovní klient fungoval napříč celou společností systém Lotus Notes. Tato skutečnost a fakt, ţe jeden z členů IT týmu byl LN administrátor a programátor, zásadním způsobem přispěla ke vzniku mnoha databází podporujících nové procesy a hlavně ke vzniku jedné velké databáze pro podporu rostoucí obchodní, marketingové a servisní divize, která začala plnit funkci chybějícího CRM (Customer Relationship Management) systému. Díky neustálému internímu vývoji a modifikacím databáze velmi rychle rostla a přizpůsobovala se potřebám jednotlivých oddělení. Stejně jako u všech velkých společností, i zde postupně docházelo k centralizaci některých řídících a kontrolních procesů, v tomto případě na ústředí evropské centrály. Postupně tak přebírali správu serverů profesionálové ze speciálního systémového oddělení v IT evropské centrále stejně tak, jako tomu bylo u entit ostatních zemí Evropy a Asie. Administrátorská práva lokálních IT pracovníků tak byla částečně omezena, coţ se nejvíce negativně projevilo právě při správě Lotus Notes. Mnoho věcí se tak zpomalilo a zkomplikovalo, protoţe se kvůli většině změn či přidání nových uţivatelů musela posílat ţádost do evropské centrály. To, co dříve trvalo pár sekund, mohlo nyní trvat i dny. Velkou nevýhodou bylo, ţe u nás vyvinutým databázím v centrále nerozuměli, nevěděli, jak fungují, jak jsou vzájemně provázané, a co všechno ke svému chodu vyţadují. To systému bohuţel několikrát způsobilo krátkodobé výpadky, kdyţ na centrále vypnuli nějakou sluţbu, o které nevěděli, co dělá. Proces obnovy databází ze zálohy probíhá v celku bezproblémově. Pokud by RPO bylo nedostatečné, protoţe zálohy lokálních serverů probíhají jednou denně, je moţně v případě potřeby pouţít aktuálnější zálohy v podobě lokálních replik databází na discích počítačů uţivatelů, kteří s databázemi pracují. Replikace je nastavena automaticky všem uţivatelům kvůli zvýšení rychlosti odezvy databází, zejména pak pro uţivatele přistupující zvenčí přes VPN. Uţivatelé pracují na lokální replice databáze a jsou-li připojeni na síti, probíhá replikace s databázemi na serveru na pozadí, která uţivatele nijak nebrzdí.

68

V případě, ţe by ovšem došlo ke ztrátě celého serveru, nebyl připraven ţádný přesný postup jak jej nahradit. Pro přístup do Lotus Notes je zapotřebí ID soubor chráněný heslem. Přístupy k jednotlivým databázím a role se pak nastavují pro jednotlivé uţivatele nebo skupiny.

3.3.2. Sídlo firmy Sídlo firmy se nachází v areálu na okraji Prahy. Areál byl postaven na konci 70. let minulého století, a tomu také odpovídá technické vybavení budov. Budovy jsou vybaveny EPS (elektronickým protipožárním systémem), ale technické protipoţární vybavení tvoří pouze hasicí přístroje a vodní hasební technika (hydranty a „suchovody“). V ţádné budově nejsou instalovány sprinklery. Areál má vlastní trafostanici a výkonný záloţní zdroj (65 kW). Areál je oplocený a nepřetrţitě střeţený. Jediný vstup do areálu je přes vrátnici s nepřetrţitou ostrahou. Kromě naší firmy zde sídlí ještě několik menších společností. Naše firma vyuţívala tři budovy: budova A - původní stará budova, ve které probíhá výroba, budova B - nová budova, která byla vystavěna dle poţadavků firmy, budova C - část další staré budovy, jejíţ druhé patro bylo přizpůsobeno k vestavbě několika kanceláří a také k dalšímu propojení obou budov. Hlavní vstup do areálu je zajištěn vrátnicí přes dveře na vstupní kartu a potom samotným vstupem do budovy A opět dveřmi na vstupní kartu nebo prostřednictvím personálu přilehlé recepce. Druhý vstup do firmy je zajištěn průjezdem kolem vrátnice se závorou ovládanou vstupní kartou či personálem vrátnice. Ze dvora je poté vstup do budovy B zajištěn jedněmi dveřmi na klíč a hned dalšími dveřmi na vstupní kartu. Mimo pracovní dobu jsou budovy zajištěny alarmem a pravidelně kontrolovány ostrahou.

69

3.3.3. Místnost se servery Místnost se servery se nachází ve druhém, tedy předposledním patře budovy B, stejně jako kancelář IT oddělení. Vstup do místnosti je ze skladové haly. Místnost byla vybavena klimatizační jednotkou dostatečného výkonu, ale bez zálohy a hrozilo tedy přehřívání serverů v případě poruchy klimatizační jednotky. V místnosti byly dva racky s pohodlným přístupem ze všech stran a připojením veškeré kabeláţe svodem z vrchu. Jeden rack je vyhrazen pro servery, zálohovací jednotku a přepínač s terminálem pro obsluhu serverů. Druhý rack je vyhrazen pro telefonní ústřednu a koncová zařízení poskytovatelů připojení. V kaţdém racku je jedna jednotka UPS, obě jsou napájené nouzovým dieselagregátem pro případ výpadku proudu. Dieselagregát by měl naskočit automaticky do minuty od výpadku proudu. Tato sluţba však vlastníkem objektu není garantována.

3.3.4. Servery V této části nemá smysl zacházet příliš do technických podrobností – Servery jsou HP Proliant DL380 osazené procesory Intel Xeon. Na serverech běţí operační systém Windows Server 2003. Server1 – Infrastructure server – zajišťuje lokální repositury pro aktualizace Windows, aktualizace ovladačů a softwaru pro počítače Lenovo a instalační balíčky standardního softwaru uţívaného ve společnosti. Při výpadku tohoto serveru budou příslušné sluţby přesměrovány na jiný server tohoto typu v evropské centrále, server2 – Domain controller – zajišťuje zejména sluţby DHCP, DNS a Active Directory. Při výpadku tohoto serveru budou příslušné sluţby přesměrovány na jiný server tohoto typu v evropské centrále, server3 – FileServer – jeho hlavním úkolem je poskytovat přístup k souborům a zároveň zajišťovat provoz lokálního ERP systému. Při výpadku tohoto serveru budou příslušné sluţby nedostupné aţ do zajištění náhrady – postup ovšem nebyl popsán, 70

server4 – Lotus Notes server – zajišťuje zejména sluţby elektronické pošty a chod databází + lokálního CRM systému. Při výpadku tohoto serveru je moţné provizorně obnovit databáze ze zálohy na Lotus Notes serveru v evropské centrále do zajištění náhrady – postup ovšem nebyl popsán.

3.3.5. Zálohování Zálohování probíhalo na páskové mechanice HP StorageWorks Ultrium 448 na pásky LTO2 (200GB/400GB) zálohovacím softwarem Backup Exec od společnosti Symantec. Zálohování probíhalo kaţdý pracovní den a dvakrát týdně probíhala výměna sad pásek mezi firmou a off-site lokalitou – pásky byly ukládány do bezpečnostní schránky v bance. Rotace pásek fungovala systémem dvou sad pásek - jedna pro sudý a druhá pro lichý týden. Pásky byly označeny názvy dní a sady rozlišeny červenou a bílou barvou. V půlce a na konci týdne se tak vţdy vyměnila polovina sady pásek. Výjimky byly vţdy na konci měsíce a poslední den v roce, kdy byla provedena záloha na pásku označenou příslušným datem a uloţena v bance. Měsíční zálohy se v bance ponechávaly dva roky, neţ byly znovu pouţity a roční pásky 6 let. Zálohován byl vţdy kompletní obsah serveru3 a serveru4 a jednou týdně byla vţdy prováděna kontrolní obnova náhodných dat z kaţdé zálohované sekce. Výsledek obnovy stejně jako kaţdé zálohy byl zadokumentován a potvrzen podpisem. Proces zálohování byl dobře popsán, dokumentován a fungoval bez problémů.

3.3.6. Pracovní stanice Všechny počítače společnosti mají operační systém Windows XP Professional (32bit) Service Pack 3. K aktualizaci systému prostřednictvím Windows Update byly vyuţívány lokální repository na infrastructure serveru. Nebyly instalovány přímo od Microsoftu, ale byly nejprve testovány, aby nedocházelo k neţádoucím konfliktům, a aţ poté nahrány na servery. Instalace aktualizací musela být iniciována uţivatelem, který byl o nových aktualizacích informován zprávou na hlavním panelu.

71

Lokální data na pracovních stanicích nejsou nijak automaticky zálohována a je zodpovědností kaţdého uţivatele si je zálohovat. Samozřejmě jen málo z nich tak opravdu činí, natoţ pravidelně. Čas od času se tedy stane, ţe dojde k selhání harddisku a nějaká data se uţ obnovit nepodaří. Většina uţivatelů má naštěstí důleţitá data na síťových discích, kde jsou v bezpečí. Kromě selhání harddisku je zde ještě další významné riziko ztráty dat, a to u uţivatelů laptopů, kterým jsou bohuţel někdy odcizeny. Nejčastěji tak, ţe byly ponechány někde v zaparkovaném vozidle. Zde je navíc i riziko, ţe se mohou data s citlivým obsahem dostat do nepovolaných rukou. Antivirovou ochranu zajišťuje na všech stanicích sytém McAfee, který je pravidelně aktualizován z infrastructure serveru. Systém McAfee také brání spouštění i instalaci neţádoucích programů.

3.3.7. Síťová infrastruktura Aktivní prvky sítě jsou značky Nortel, které nahradily dřívější prvky značky 3Com. Ty totiţ nedisponovaly sluţbou PoE (Power over Ethernet), která byla zapotřebí pro chystanou implementaci IP telefonie. Síť tvoří tedy tyto aktivní prvky: 9x - Nortel ERS 5520 48T, 2x - Nortel Passport 1624G, 1x – Nortel Contivity 600 VPN Switch 128-bit.

72

Obrázek 20 - Síťové prvky Nortel (zleva: Passport 1624G, ERS5520 48T, Contivity 600 VPN) Zdroj: firemní intranet

Obrázek 19 - Diagram síťové architektury. Zdroj: vlastní

73

Jak jsou jednotlivé prvky vzájemně propojené, bude nejlépe patrné z diagramu (viz obr. 19). Vedení kabeláţe je poměrně chaotické, coţ je způsobeno tím, ţe nebylo realizováno najednou, ale naopak postupně, dle potřeby. Prostory objektu, zejména pak budovy A, nejsou vůbec připravené na takové mnoţství kabelů. Polovina kabeláţe tak vede nad podhledy a druhá polovina, kde podhledy nejsou, vede lištami. Z bezpečnostního hlediska lze alespoň říci, ţe ţádný kabel nevede cizími prostory mimo objekt firmy. Veškerá síťová komunikace s vnějším světem vede přes evropskou centrálu, kde je kontrolována a filtrována. Vyuţívají kombinaci hardwarového i softwarového firewallu a různých webových filtrů. Konkrétní technické řešení nám není známo, ale fungují spolehlivě a nedochází k ţádným problémům. Daní za tuto ochranu je ovšem trochu niţší rychlost načítání webových stránek. Pro přístup do firemní sítě přes VPN, bylo vyuţíváno řešení od RSA. Kaţdý uţivatel, jemuţ byl schválen přístup z venku, byl vybaven hardwarovým tokenem. Na počítači pak byl instalován a nakonfigurován klient od společnosti Nortel, kde bylo nutno zadat uţivatelské jméno, heslo a opsat aktuální kód z displeje na RSA tokenu. Kaţdý kód měl minutovou expiraci. Nevýhoda tohoto řešení byla poměrně vysoká cena na uţivatele za licenci a token, a také poměrně častá chybovost, kdy musel uţivatel kontaktovat IT podporu.

3.4. Zjištěná rizika V této kapitole jsou seřazena rizika, vytipovaná analýzou počátečního stavu, sestupně od nejzávaţnějšího po nejméně závaţné. a) Z hlediska záměru zvýšit bezpečnost ICT a sestavit havarijní plány je nejzávaţnějším problémem nízká podpora managementu. b) Neexistence záloţní lokality. Tím není moţné obnovit funkci systémů v případě úplného poškození v potřebném čase. c) Neexistence havarijních plánů. d) Chybí záloţní klimatizační jednotka v místnosti serverů.

74

e) Nedostatečná ostraha objektu. V objektu chybí monitorovací kamerový systém. S tím souvisí riziko neoprávněného nakládání s firemními daty, v případě neoprávněného vniknutí do objektu. f) Aktivní síťové prvky nedisponují redundantním zdrojem napájení. g) Nespolehlivost záloţního zdroje elektrické energie. h) Nekompatibilita ERP systému s moderními operačními systémy. i) Protipoţární systém neobsahuje sprinklery. j) Uţivatelé se neodhlašují ani nezamykají počítač, kdyţ opouští své pracoviště k) Lokální data na pracovních stanicích nejsou v případě selhání hardwaru či ztrátě zařízení dostatečně zabezpečena. l) Připojení do firemní sítě přes VPN je dostatečně bezpečné ale nespolehlivé m) Antivirová ochrana systémem McAfee je dostatečná, ale některé pracovní stanice mají problém s aktualizací virových definic, coţ je činí zranitelnými vůči nejaktuálnějším hrozbám.

75

4. Realizace a zhodnocení projektu 4.1. Nové sídlo Při realizaci projektu bylo prvním úkolem nalezení vhodného objektu pro nově zaloţenou společnost N (nová). Kromě vzdálenosti od původního sídla, musel objekt splňovat řadu dalších poţadavků, zejména: reprezentativní vzhled vnější i vnitřní, moţnost izolovat pronajaté prostory od případných ostatních nájemců, moţnost rozšíření v případě růstu společnosti, zabezpečení objektu proti vniknutí a poţáru, ostraha, dostupnost záloţního zdroje elektřiny. Zvolen byl objekt blíţe středu města, vzdušnou čarou vzdálený 3,4 km od původního sídla P. Jde o objekt relativně nový, kolaudovaný na počátku tohoto století. Vstup do objektu je přes recepci s nepřetrţitou ostrahou nebo ze zadní části objektu ze dvora, kam je však moţné se dostat pouze přes jinou recepci sousedního objektu také s nepřetrţitou ostrahou, resp. bránou pro vjezd vozidel osazenou čtečkou čipových karet – oba vstupy do objektu jsou navíc osazeny fyzickou překáţkou (turniketem u recepce, resp. dveřmi ze dvora), umoţňující vstup pouze drţitelům čipových karet s oprávněním vstupu. Celý areál je monitorován kamerovým systémem. Areál má vlastní trafostanici a záloţní zdroj. Zabezpečovací systém a protipoţární systém pokrývá všechny prostory. Signalizace je vyvedena na obě recepce areálu a dále je zajištěna pomocí SMS. Všechny prostory jsou odděleně klimatizované. Nevýhodou objektu je, ţe protipoţární systém neobsahuje sprinklery.

76

Po celkové rekonstrukci pronajatých prostor byly všechny vstupy do oddělených částí osazeny čtečkou čipových karet a vstup do oddělení IT byl ještě zvlášť osazen čtečkou přesto, ţe je tam moţné vstoupit pouze z jiţ zabezpečeného prostoru.

4.2. Infrastruktura a zabezpečení v novém sídle 4.2.1. Místnost serverů v novém sídle Při přípravě pronajatých prostor byla zásadní pozornost věnována místnosti serverů, která se nachází ve třetím (předposledním) patře budovy. Vstup do místnosti serverů je pouze z kanceláře oddělení IT. Je osazen čtečkou čipových karet a oprávnění vstupu mají pouze pracovníci IT. Místnost je vybavena robustní klimatizací, konkrétně dvěma vnitřními jednotkami na sobě nezávislými, tedy kaţdá má na střeše objektu svou vlastní externí výměníkovou jednotku a výkon kaţdé z nich spolehlivě převyšuje předpokládané tepelné zdroje. Umístění vnitřních jednotek bylo voleno bezpečně tak, aby v případě poruchy čerpadla kondenzátu nemohlo dojít k zatopení ţádných elektrických zařízení. V místnosti je několik poţárních čidel a čidel na měření teploty vzduchu s automatickou signalizací překročení předvolené hranice teploty či poţáru prostřednictvím SMS. Místnost je napájena z běţného zdroje elektřiny, ale přes nouzový rozvaděč. Záloţní zdroj v případě výpadku běţného zdroje elektřiny naběhne do 10 sekund. Instalovány jsou kabelové lávky s dvojnásobnou kapacitou předpokládaného průřezu kabelů. Podlaha je zvýšená, aby se eliminovalo riziko vytopení a současně aby došlo k lepšímu rozloţení zátěţe. Povrch podlahy je antistatický. V místnosti jsou tři racky s pohodlným přístupem ze všech stran a s připojením veškeré kabeláţe svodem z vrchu od kabelové lávky. První rack je vyhrazen pro aktivní síťové prvky, patch panely a panely pro organizaci kabeláţe. Druhý rack je vyhrazen pro servery, zálohovací jednotku a terminál pro obsluhu serverů a konzolí některých důleţitých periferií. Třetí rack je vyhrazen pro telefonní ústřednu a koncová zařízení poskytovatelů připojení. Ve druhém a třetím racku jsou jednotky UPS, kaţdá vţdy napájí jeden z páru redundantních zdrojů kaţdého serveru či switche.

77

4.2.2. Servery v novém sídle Opět nebudeme hovořit příliš o technických podrobnostech – Servery jsou také HP Proliant DL380 ale o generaci vyšší, rovněţ osazené procesory Intel Xeon. Na serverech běţí operační systém Windows Server 2003, a na jednom Windows Server 2008. Server1 – Infrastructure server (přesunutý ze sídla P, viz 3.3.4.) server2 – Domain controller (zde jediný s Windows Server 2008) – zajišťuje zejména sluţby DHCP, DNS a Active Directory. Při výpadku tohoto serveru budou příslušné sluţby přesměrovány na jiný server tohoto typu v evropské centrále, server3 – FileServer – jeho hlavním úkolem je poskytovat přístup k souborům a zároveň zajišťovat provoz aplikace pro komunikaci s bankou a realizaci hromadných plateb. Při výpadku tohoto serveru budou příslušné sluţby nedostupné aţ do zajištění náhrady. Náhradu lze realizovat prostřednictvím Fileserveru v sídle P – postup ovšem nebyl popsán. Čtvrt roku se testovalo vzájemné zrcadlení obou fileserverů. Nebylo však pouţito příliš sofistikované řešení a docházelo tak k mnoha nepříjemnostem, aktualizačním anomáliím a zejména nadměrnému zatíţení komunikační linky mezi sídly. Protoţe nebylo schváleno uvolnění prostředků pro kvalitnější řešení synchronizace ani pro navýšení kapacity komunikační linky, bylo zrcadlení serverů ukončeno. Uţivatelé obou sídel nyní vyuţívají oba Fileservery, ale s významnou preferencí vlastního fileserveru vzhledem k rozloţení dat dle zaměření společnosti. Všechny servery jsou pokryty servisním kontraktem uzavřeným s firmou HP na opravu či výměnu vadného kusu hardware v případě jeho selhání, a to během následujícího pracovního dne od nahlášení závady (tento kontrakt platí i pro všechny tiskárny HP).

78

4.2.3. Informační systém pouţívaný novou společností V průběhu příprav a přestavby sídla N probíhalo rozsáhlé školení týkající se zavedení nového globálního informačního systému koncernu na platformě Oracle E-bussiness Suite, pro který se mezi zaměstnanci uţ v době jeho vývoje vryl název „Oracle“, a ten se pouţívá napříč celým koncernem. Systém je ucelenou sadou integrovaných globálních podnikových aplikací. Plní tak funkci ERP a částečně i CRM systému. Pokrývá téměř 100% procesů komerčních entit koncernu (příprava modulů systému pro výrobní entity se neustále protahuje, coţ je dáno relativně malým počtem výrobních entit a jejich různorodostí). Po úspěšném přestěhování poloviny společnosti do sídla N, uţivatelé rovněţ úspěšně adoptovali tento nový informační systém. Trvalo tedy přibliţně 18 měsíců, neţ se s ním uţivatelé sţili, coţ bylo způsobeno zejména nekvalitní přípravou amerického implementačního týmu, který se soustředil na školení obsluhy systému, ale nijak se nezabýval nezbytnou změnou a mapováním zdejších procesů. Po vyřešení veškerých počátečních nedostatků lze nyní říci, ţe systém má jedinou zásadní nevýhodu a tou je rychlost odezvy systému. Je to logická daň za to, ţe systém je centralizován v USA a uţivatelé všech komerčních entit přistupují k tomuto jednomu zdroji. Mluvíme tedy celkem o přibliţně 7 tisících uţivatelích, z toho jej ale opravdu aktivně vyuţívá asi 30 % a ti jsou ještě rozprostřeni přes všechna časová pásma, tudíţ nepřistupují všichni najednou. Obrovskou výhodou je, ţe veškerá starost o tento systém je v rukách IT pracovníků v USA. Tím také odpadá z našeho pohledu i starost o jeho zabezpečení a případnou obnovu. V USA to mají pod kontrolou - systém ještě před dvěma lety, neţ padlo rozhodnutí o outsourcingu, běţel na vlastním vybavení společnosti v hlavním sídle v Miami. Projekt převodu systému do správy společnosti „I/O Data Centers, LLC“ tak z Miami udělal záloţní lokalitu a systém nyní funguje v jednom z bezesporu světově nejvyspělejších datacenter ve Phoenixu v Arizoně. Odpovědnost lokálního IT oddělení ve vztahu k tomuto systému se tak omezuje pouze na zajištění provozu sítě a počítačů. Elektronická pošta byla z platformy Lotus Notes v celém koncernu převedena na MS Exchange a Outlook 2010. Uţivatelé se tak nyní dostanou ke svým mailům prostřednictvím doménového účtu prostým spuštěním Outlooku. Servery zajišťující sluţby elektronické pošty a Blackberry jsou nyní mimo naši lokální kontrolu a fyzicky i mimo Českou republiku – jeden ve Švýcarsku a jeden v USA, oba vzájemně zastupitelné.

79

Odpovědnost lokálního IT oddělení za provoz elektronické pošty se tedy taktéţ omezuje pouze na zajištění provozu sítě a počítačů. Lotus Notes se pouţívá i nadále pro některé databáze, které se dosud nepodařilo nahradit jiným způsobem. Plán je ovšem do konce roku 2014 všechny databáze a celý Lotus Notes opustit.

4.2.4. Síťová infrastruktura v novém sídle Aktivní prvky sítě jsou dle nového korporátního standardu značky Juniper Networks, které nahradily dřívější standard Nortel, který jiţ nedobrovolně zmizel z trhu. Sluţba PoE (Power over Ethernet), která je zapotřebí pro napájení IP telefonů je ale samozřejmě přítomna i u nich. Velkou výhodou Switchů Juniper je moţnost osazení dvěma redundantními jednoduše vyměnitelnými napájecími jednotkami, coţ výrazně zvyšuje rezistenci zařízení proti výpadkům způsobeným poruchou napájení. V případě selhání napájecí jednotky jsou pracovníci síťového týmu na evropské centrále ihned automaticky informováni. Síť tvoří tedy tyto aktivní prvky: 5x – Juniper EX4200 48T, 1x – Juniper SRX210.

Obrázek 21 – Síťové prvky Juniper (SRX210 a EX4200 48T). Zdroj: firemní intranet

80

Jak jsou jednotlivé prvky vzájemně propojené, bude nejlépe patrné z diagramu níţe (viz obr. 22). Vedení kabeláţe je přehledné a uspořádané díky tomu, ţe veškeré rozvody byly realizovány v průběhu rekonstrukce objektu. Abychom předešli případným poţadavkům na rozšíření rozvodů v budoucnu, nechali jsme je rozvést v 2,5krát naddimenzovaném rozsahu, neţ byl původní plán vycházející z plánovaného počtu pracovních stanic a firemních standardů. Ještěţe jsme tak učinili, neboť o necelý rok později došlo k menším organizačním změnám, a v jedné místnosti bylo rázem zapotřebí dvakrát tolik síťových zásuvek.

Obrázek 22- Diagram síťové architektury. Zdroj: vlastní

81

Co se týče propojení s ostatními entitami, jsou v současnosti v provozu 3 nezávislé linie. V prvním případě je prostřednictvím ISP (Internet Service Provider) poskytováno připojení do veřejné sítě internet. Přes něj je primární spojení VPN tunelem do evropské centrály a dalším VPN tunelem do sídla P. Toto spojení však z důvodu nadstandardní datové komunikace mezi sídly P a N nebylo dostačující, a proto byla zřízena druhá linie Metro-line, přímé propojení obou lokalit. Třetí linie je od společnosti Global Crossing Ltd., jeţ je nyní vlastníkem a operátorem nejpokročilejší sítě ze skleněných vláken na světě a přední globální poskytovatel řešení IP komunikace. Hlavní úlohou tohoto připojení je přímější spojení do USA za účelem poskytovat komfortnější přístup do koncernového informačního systému.

4.2.5. Zálohování v novém sídle Pro zálohování v této lokalitě byl instalován HP 1/8 G2 LTO-4 Ultrium 1760 SCSI Autoloader. Zálohování probíhá na LTO4 (800GB) zálohovacím softwarem CA ArcServe. Zálohování probíhá kaţdý pracovní den. Pásky se do zálohovací jednotky vkládají kaţdý týden vţdy na následujících 5 aţ 6 dní. Predikce pásek, které mají být pouţity na následující týden, je automaticky generována denně a je zasílána mailem pracovníkům IT oddělení. Zálohování se provádí bez fyzické verifikace záznamu, pro kontrolu se 1x týdně provádí obnova náhodně vybraných dat ze zálohy. Z měsíční a roční zálohy se vţdy provádí obnova náhodně vybraných dat pro ověření. Pásky s měsíční a roční zálohou jsou ukládány off-site v prostorách společnosti P, v bezpečnostní schránce v kanceláře IT. Pásky pro denní zálohování, pokud nejsou právě pouţívány, jsou uloţeny v pracovně IT, v budově sídla N. Pásky s měsíčními zálohami datového serveru jsou uchovávány 1 rok a pásky s ročními zálohami datového serveru jsou uchovávány po neomezeně dlouhou dobu. Zálohován je vţdy kompletní obsah datového serveru. Rotace pásek probíhá dle následujícího diagramu (viz Obrázek 23) Proces zálohování je dobře popsán, dokumentován a funguje bez váţnějších problémů.

82

Obrázek 23 - Zálohování - rotace pásek. Zdroj: vlastní

4.3. Úpravy infrastruktury a zabezpečení v původním sídle Po přestěhování společnosti N, která vznikla oddělením od společnosti P (původní), se v sídle společnosti P uvolnilo hodně prostor - týkalo se to zejména budov B a C (viz popis sídla v části 2.2.2). Budova C byla vyklizena a vrácena majiteli areálu. Budova B byla kromě místnosti serverů dočasně zcela vyklizena, aby v ní mohla proběhnout rekonstrukce, jejímţ hlavním cílem bylo přebudovat stávající prostory na sklady. Z hlediska předmětu této práce jsou podstatné dvě skutečnosti: v celé budově B byly instalovány sprinklery kromě místnosti serverů, místnost serverů byla zvětšena na dvojnásobek a zrekonstruována (viz dále).

83

4.3.1. Místnost serverů v původním sídle Během rekonstrukce došlo k dvojnásobnému zvětšení místnosti serverů a jejímu novému vybavení bezpečnostními protipoţárními systémy včetně monitorování teploty vzduchu s automatickou signalizací předvolené hranice teploty pomocí SMS. Vstup do této místnosti je blokován pouţitím čipové karty a monitorován. Místnost serverů je napájena z běţného zdroje elektřiny přes nouzový rozvaděč. Nově repasovaný záloţní zdroj v případě výpadku běţného zdroje elektřiny naběhne do 9 sekund, a díky jeho nedávné údrţbě jsme i prakticky vyzkoušeli, ţe UPS udrţela systémy v chodu 16 minut a po této době všechny servery bezpečně vypnula. Místnost je nově vybavena robustní klimatizací. Původní jednotka byla nahrazena novými dvěma vnitřními jednotkami na sobě nezávislými, tedy kaţdá má na střeše objektu svou vlastní externí výměníkovou jednotku a výkon kaţdé z nich spolehlivě převyšuje předpokládané tepelné zdroje. Stejně tak jako v sídle N bylo umístění vnitřních jednotek voleno bezpečně tak, aby v případě poruchy čerpadla kondenzátu nemohlo dojít k zatopení ţádných elektrických zařízení. V místnosti jsou nyní tři racky s pohodlným přístupem ze všech stran a připojením veškeré kabeláţe svodem z vrchu od nové kabelové lávky. Z jiné místnosti byly přesunuty aktivní síťové prvky a našly své místo v prvním racku spolu s patch panely a panely pro organizaci kabeláţe. Druhý rack je vyhrazen pro servery, zálohovací jednotku a terminál pro obsluhu serverů a konzolí některých důleţitých periferií. Třetí rack je vyhrazen pro telefonní ústřednu a koncová zařízení poskytovatelů připojení. Ve druhém a třetím racku jsou jednotky UPS, kaţdá vţdy napájí jeden z páru redundantních zdrojů kaţdého serveru.

4.3.2. Informační systémy pouţívané v původní společnosti Informační systémy zůstaly ve srovnání s analyzovaným výchozím stavem prakticky beze změny. Došlo ovšem ke změně bezpečnostní politiky – všechny pracovní stanice se nyní samy uzamknou po deseti minutách nečinnosti, zkrátila se lhůta pro obměnu hesla na 60 dní a zpřísnily se poţadavky na komplexnost hesel.

84

4.3.3. Servery v původním sídle Ohledně serverů nedošlo k významným změnám oproti předešlému stavu (viz 3.3.2), jen jeden server byl přesunut do sídla N a u jednoho byl upgradován operační systém. Server1 – Domain controller - nyní s Windows Server 2008, jinak beze změny, server2 – FileServer - značná část dat byla přesunuta na fileserver sídla N, server stále zajišťuje chod lokálního ERP systému, jinak beze změny Server3 – Lotus Notes server - Od převodu elektronické pošty na Exchange jiţ zajišťuje pouze chod databází, jinak beze změny.

4.3.4. Síťová infrastruktura v původním sídle Síťová infrastruktura zůstala co do technického vybavení ve srovnání s analyzovaným výchozím stavem prakticky beze změny. Stále jsou tedy instalovány síťové prvky značky Nortel, které jsou zde jiţ ovšem zastaralé a představují tedy významné riziko. Vyměněn kvůli kompatibilitě se sídlem B byl prvek Nortel Contivity 600 VPN za Juniper SRX210. Architektura sítě se zjednodušila úbytkem kanceláří z opuštěné budovy C. Jakým způsobem jsou nyní jednotlivé prvky vzájemně propojené , bude nejlépe patrné z diagramu níţe (viz Obrázek 24). Co se týče propojení s ostatními entitami, je zde situace nyní stejná jako v sídle N - jsou v provozu 3 nezávislé linie (viz 4.2.4).

85

Obrázek 24 - Diagram síťové architektury. Zdroj: vlastní

4.3.5. Zálohování v původním sídle I zde byl pro zálohování serverů v této lokalitě instalován autoloader, ovšem jiného typu, HP 1/8 G2 LTO-3 Ultrium 1760 SCSI Autoloader. Zálohování probíhá na LTO3 (400GB/800GB) zálohovacím softwarem CA ArcServe. Zálohování probíhá stejně jako v sídle N a podle stejného schématu (viz diagram v části 4.2.5) s tím, ţe ukládání pásek off-site probíhá pochopitelně obráceně.

86

4.4. Realizovaná opatření v rámci restrukturalizace V části 3.4 byla vyhodnocena rizika, která vyplynula z analýzy počátečního stavu. Zde se nyní podíváme, jakým způsobem byla některá tato rizika vypořádána. ad 3.4.a)

Lokální

management

si

postupně

začíná

uvědomovat

důleţitost

zabezpečení ICT a potřeby havarijních plánů, ale je stále zatíţen řadou jiných činností s vyššími prioritami a současně tlačen nadřízenými sloţkami k neustálému sniţování nákladů, coţ nedovoluje realizovat tento záměr externí formou. Řešení je proto stále jen v rukou pracovníků útvaru IT. ad 3.4.b, c)

Díky záměru rozdělit společnost na dvě části, a takto nově vzniklou společnost přesídlit a nově vybavit potřebnými technologiemi (viz část 4.2 a 4.3), byl tento problém absence záloţní lokality vyřešen. Vyuţití náhradní lokality je tak součástí havarijního plánu (viz část 4.5).

ad 3.4.d)

Původní klimatizační jednotka v místnosti serverů v lokalitě P byla nahrazena dvojicí dostatečně výkonných klimatizačních jednotek (viz část 4.3.1). Bylo vyuţito rekonstrukce a kompletních úprav klimatizačních zařízení, kterých bylo zapotřebí pro vznik nového chlazeného skladu.

ad 3.4.e)

Monitorovací kamerový systém v lokalitě P dosud nebyl instalován. Prozatím nedošlo k dohodě s pronajímatelem areálu, který by měl systém realizovat a provozovat.

ad 3.4.f)

Výměna síťových prvků s redundantním napájecím zdrojem nebyla zatím realizována. Navíc tato zařízení jiţ značně zestárla a mnohem více se zahřívají. Riziko selhání je jiţ velmi vysoké. S výměnou se počítá, ale uţ mnoho měsíců se čeká na schválení a nákup nových prvků se stále odkládá. Pro řešení krizových situací jsou k dispozici dva náhradní switche, které mohou být namontovány a nakonfigurovány místo porouchaných.

87

ad 3.4.g)

Majitel areálu provedl repasi záloţního zdroje a smluvně zajistil periodické revize. Zdroj nyní naběhne po výpadku napájecí sítě do 9 sekund. Výkon ovšem není dostačující, aby zajistil energii i pro mraţené a chlazené sklady v případě delších výpadků, a proto byl uzavřen kontrakt se společností Carrot Euro, která v případě potřeby do hodiny přistaví náhradní zdroje energie potřebného výkonu, které se zapojí do připravených zásuvek na západní straně objektu a udrţuje je v chodu, dokud je třeba.

ad 3.4.h)

ERP, uţívaný ve společnosti P, prozatím není nahrazen novým systémem. Očekává se nasazení globálního informačního systému koncernu, který v sobě jiţ bude zahrnovat i „výrobní modul“. (Prozatímním řešením k provozu na novějších operačních systémech, je-li třeba, je spuštění virtuální stanice s Windows XP, kde systém funguje).

ad 3.4.i)

V lokalitě P byly v rámci rekonstrukce budovy B instalovány sprinklery, kromě místnosti serverů (viz část 4.3.1). V budově A instalace sprinklerů nepřichází v úvahu vzhledem k charakteru práce (práce s radioaktivními látkami – viz část 3.1).

4.5. Modelový příklad havarijních plánů V předchozích kapitolách jsem se věnoval detailnímu popisu a analýze minulého a současného stavu zabezpečení ICT ve vybrané firmě i s výhledem do budoucna. Na všechna bezpečnostní opatření, která jsem zde uvedl, budou postupně navazovat i havarijní plány pro mimořádné události. Jako modelový příklad zde uvedu havarijní plán pro celkovou obnovu podniku z důvodu havárie (poţár v místnosti serverů). Pro sestavení plánu je třeba zdůraznit, ţe technologie v obou lokalitách jsou podobné, dostatečně výkonné a s dostatečnou kapacitou, aby zastoupení umoţňovaly.

88

Poţár je závaţná situace, při které jsou současně aktivovány kromě DRP a BCP i další krizové plány jako např. evakuační. Vzhledem k tématu a zaměření této práce se omezím jen na sestavení modelového DRP a z hlediska BCP vyberu pro ilustraci jednu kritickou činnost, jejíţ kontinuitu by musely krizové týmy řešit. DRP pro havárii způsobenou poţárem v místnosti serverů sídla P Čas od zjištění havárie

Obnovovaná služba

Odpovědná osoba

Popis činnosti

1

do 1 h

-

pracovník IT

analýza rozsahu havárie

2

do 1,5 h

-

vedoucí IT

informace vedení společnosti

3

do 2 h

-

management

rozhodnutí vedení o rozsahu a rychlosti obnovy na základě návrhu vedoucího IT realizace konkrétních částí plánu

4

do 2,5 h

zahájení dočasné obnovy síťových disků

pracovník IT

úprava logovacích skriptů a obnova dat ze zálohy na pásce (doba 4h)

5

do 3 h

provoz uživatelů

management

Instrukce zaměstnancům aktivace replik databází v evropské centrále

6

do 9 h

dočasná obnova databází

pracovník IT v evropské centrále

7

do 12 h

dočasná obnova ERP systému

pracovník IT

konfigurace systému po obnově dat

8

do 12 h

objednávka HW

pracovník IT

objednávka nakontraktovaného HW

9

do 3 d

příprava dodaného HW

pracovník IT

instalace a konfigurace (doba 1 d)

10

až to půjde

instalace HW v nových nebo rekonstruovaných prostorách

pracovník IT

převoz a instalace HW, oživení, obnovení dat (doba 3 d)

pracovník IT

vyplnění dokumentace o příčině a řešení incidentu, uložení na sdílený disk do určené složky, vypracování zprávy pro nadřízenou složku v evropské centrále

průběžně a po 11 ukončení činností

-

Tabulka 3 - Modelový příklad DRP. Zdroj: vlastní

89

Pro zabezpečení kontinuity provozu v přechodné době bude nutné v případě takovéto havárie řešit velké mnoţství činností, které jsou nezbytné, aby firma fungovala alespoň v omezeném provozu. Z nich jsem vybral zajištění objednávek. Modelový plán BCP pro zajištění přijímání objednávek od zákazníků:

Čas od zjištění havárie

do 3 h

Popis činnosti

informace zaměstnancům zákaznického oddělení

Odpovědná osoba

vedoucí oddělení

příprava provizorních do 4 h

telefonů a několika rezervních počítačů

IT oddělení

v náhradní lokalitě

do 5 h.

do 6 h.

přesun zaměstnanců do

zaměstnanci zákaznického

náhradní lokality

oddělení

přijímání objednávek

zaměstnanci zákaznického

v náhradních prostorách

oddělení

Tabulka 4 – Modelový příklad zajištění kontinuity přijímání objednávek. Zdroj: vlastní

4.6. Další opatření Mimo hlavní projekt rozdělení společností, jímţ bylo dosaţeno záloţní lokality a redundance hardwaru, bylo postupně provedeno ještě několik opatření, která přispěla ke zvýšení zabezpečení ICT v celokoncernovém i lokálním měřítku, čímţ byla vypořádána některá další rizika, která vyplynula z analýzy počátečního stavu (viz část 3.4). ad 3.4.j)

Aby se sníţilo riziko zneuţití uţivatelského účtu někým jiným, jsou nyní všechny pracovní stanice nastaveny tak, aby se po deseti minutách

90

nečinnosti samy uzamkly. Spolu s tím se zpřísnily poţadavky na komplexnost hesel a zkrátila se lhůta pro jejich obměnu na 60 dní. ad 3.4.k)

Pracovní stanice jsou v současnosti hromadně přeinstalovávány na Windows 7 s aktivním šifrováním BitLocker, Jiţ tedy nebude hrozit zneuţití dat z disku ukradeného laptopu. Zálohování lokálních dat z pracovních stanic však stále není nijak automatizované. Uţivatelé mají sice více variant, jak a kam si svá data zálohovat, ale iniciativa je stále na nich.

ad 3.4.l)

Drahé a nespolehlivé řešení vzdáleného připojení do firemní sítě přes VPN společnosti Nortel s vyuţitím tokenu od RSA bylo nahrazeno řešením společnosti Juniper Networks s vyuţitím smartkaret. Řešení je to výrazně levnější a téměř bezporuchové. Z hlediska bezpečnosti je pro připojení nutné mít čtečku a Smartkartu, která je chráněna PINem a poté se ještě přihlásit doménovým účtem, který patří k certifikátu na smartkartě.

ad 3.4.m)

Pracovní stanice i servery jsou stále pod ochranou antivirového a antispywareového systému McAfee. Aktualizace virových definic jiţ probíhají bezproblémově i pro uţivatele, kteří se připojují pouze vzdáleně. Aktualizace operačního systému jsou nyní distribuovány nástrojem SCCM (System Center Configuration Manager), jeţ je vyuţíván rovněţ pro distribuci instalačních balíčků softwaru. Oba aktualizační systémy vytvářejí přehledy o průběhu distribuce aktualizací, o počítačích kde ještě nedošlo k poţadovanému restartu počítače, a v případě, ţe uţivatel s restartem otálí, můţe být u kritických aktualizací i vynucen.

4.7. Budoucí opatření V sídle P bude nejdříve nutné vyřešit výměnu aktivních síťových prvků značky Nortel. Nemají redundantní zdroje napájení, jsou zastaralé a představují tedy významné riziko. Společnost Nortel Networks jiţ navíc nefunguje, a proto by bylo i náročné případnou závadu na zařízení řešit běţným způsobem. Opuštěním budovy C vznikly naštěstí rezervy v podobě dvou funkčních switchů, kterými lze v případě nouze poškozené zařízení

91

nahradit. Dalším problémem je umístění switchů v racku umístěném v chodbě budovy A. Tento rack sice disponuje zařízením UPS pro nouzové napájení pro pokrytí doby, neţ naskočí záloţní zdroj, ale má pouze základní odvětrávání – není nijak chlazen. To v kombinaci s větráčky v zastaralých switchích způsobuje postupný nárůst teploty a hrozí přehřátí. V návrhu opatření je proto zapotřebí zrealizovat plánovanou výměnu síťových prvků Nortel za prvky společnosti Juniper Networks a spojit ji s výměnou racku za nový, vybavený vlastním chlazením nebo kvalitním odvětráním. Dalším důleţitým opatřením bude vytvoření havarijního plánu, jak v případě incidentu nahradit funkci serveru Lotus Notes pro databáze tak, ţe se vyuţijí repliky databází na serveru v evropské centrále. Postup je znám a byl i otestován, ale není popsán a proto je závislý na stávajícím personálu IT oddělení zde i v evropské centrále. Podobné je to i s dalšími procedurami obnovy sluţeb, které jsou ideově známy, ale doposud nebyly dokumentovány a řádně otestovány. Dříve neţ Windows XP zcela ztratí podporu a na všech počítačích budou přeinstalovány na Windows 7, by bylo třeba nahradit ERP, uţívaný ve společnosti P, novým systémem. Optimální řešení by bylo, kdyby byl globální informační systém koncernu rozšířen o dlouho slibovaný „výrobní modul“. Současné náhradní řešení vyuţitím virtuální pracovní stanice rozhodně není ideální.

92

Závěr Informační bezpečnost je dnes pro kaţdou firmu jednou z nejdůleţitějších oblastí činností, protoţe ji chrání před případnými ztrátami ať uţ finančního či morálního charakteru. Ţádné univerzální řešení, které by bylo moţné aplikovat na organizace všech typů a velikostí, ale bohuţel není k dispozici. Zajištění bezpečnosti je pro mnohé firmy natolik zásadní a přitom náročnou záleţitostí, ţe při rozhodnutí o jejím zavádění se raději obrátí na specializované firmy, které se touto problematikou zabývají. Musím konstatovat, ţe i v případě naší firmy, by se celkové skutečně koncepční řešení, které by zahrnovalo všechny subjekty celého koncernu, bez odborníků nepochybně neobešlo. Jsem přesvědčen, ţe dříve nebo později k tomuto kroku stejně dojde. V současnosti je však zabezpečení tuzemské pobočky stále z velké části v našich rukách, a je proto i mojí snahou vytvořit koncept, který bude skutečně funkční. První část mé práce se věnuje teorii zabezpečování informačních a komunikačních technologií, a to nejen z hlediska preventivních opatření, ale i v případě, kdy tato preventivní opatření nestačí a je nutné pouţít havarijní plán. Tato teoretická část je jakýmsi náhledem do celé problematiky, protoţe ve skutečnosti se jedná o širokou oblast, zahrnující mnoţství dílčích disciplín. Druhá část mé práce se zabývá detailním popisem a analýzou minulého a současného stavu infrastruktury firmy, kde působím, s cílem navrhnout opatření ke zvýšení jejího zabezpečení. Toto téma jsem si zvolil právě z důvodu, ţe jsem se této problematice chtěl věnovat a získat o ní co nejvíce informací, které bych pak mohl uplatnit v praxi. Od doby, kdy jsem do této firmy nastoupil a začal se tomuto tématu věnovat, prošla společnost mnoha změnami a uběhlo několik let. Některá řešení, která jsou zde navrţena, se tak mezitím jiţ stihla zrealizovat. Popsaná analýza je analýzou stavu ještě před přijetím všech opatření a mnohá řešení jsou jiţ aktuálním stavem. Myslím, ţe to však není na závadu věci, ale spíše potvrzením, ţe navrţené dílčí kroky se postupně zavádějí do praxe. Domnívám se, ţe cíl mé práce demonstrovat moţnosti zvýšení zabezpečení ICT na příkladu konkrétního projektu rozdělení společnosti byl splněn. Určitým bonusem pak můţe být reálný popis problémů a vztahů ve firmě, která je součástí velké nadnárodní korporace.

93

Seznam pouţité literatury Články v odborných publikacích:

[1]

TLUČHOŘ, Martin. Plán obnovy po katastrofách. Praha, 2012. Diplomová práce. Bankovní institut vysoká škola.

[2]

BROOKS, Charlotte. Disaster recovery strategies with Tivoli Storage management. 1. vyd. San Jose, Calif.: IBM, 2002, 404 s. ISBN 07-384-2650-4.

[3]

BROOKS, Charlotte. IBM System Storage business continuity : part 1 planning guide. United States: IBM, 2007. ISBN 0738489700.

[4]

BROOKS, Charlotte. IBM System Storage business continuity : Part 2: Solutions Guide. United States: IBM, 2007. ISBN 0738489727.

[5]

ČSN ISO/IEC TR 13335-1. Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 1: Pojetí a modely bezpečnosti IT. Praha: Česká technická norma, 1999.

[6]

ČSN ISO/IEC 27001. Informační technologie – Bezpečnostní techniky - Systémy managementu bezpečnosti informací - Požadavky. Praha: Česka technická norma, 2006.

[7]

ČSN ISO/IEC 27002. Informační technologie – Bezpečnostní techniky – Soubor postupů pro řízení bezpečnosti informací. Praha: Česka technická norma, 2008.

[8]

DOSEDĚL, Tomáš. Počítačová bezpečnost a ochrana dat. Vyd. 1. Brno: Computer Press, 2004, 190 s. ISBN 80-251-0106-1.

94

[9]

DOUCEK, Petr. Řízení bezpečnosti informací: 2. rozšířené vydání o BCM. 2., přeprac. vyd. Praha: Professional Publishing, 2011, ISBN 978-80-7431-050-8.

[10] DOUCEK, Petr, Luděk NOVÁK a Vlasta SVATÁ. Řízení bezpečnosti informací. 1. vyd. Praha: Professional Publishing, 2008, 239 s. ISBN 978-8086946-88-7.

[11] HANÁČEK, Petr a Jan STAUDEK. Bezpečnost informačních systémů: metodická příručka zabezpečování produktů a systémů budovaných na bázi informačních technologií. Praha: Úřad pro státní informační systém, 2000, 127 s. ISBN 80-238-5400-3.

[12] HÜBNER, Miroslav. Pohled nejen CIO na informační bezpečnost. Praha: Tate International, 2012, 160 s. Příručka manaţera, 16. ISBN 978-808-6813-257.

[13] INSTITUTION, British Standards. Business continuity management: Part 2 : Specification. London: British Standards Institution, 2007. ISBN 978-058-0599132.

[14] INSTITUTION, British Standards. Business Continuity Management:Part 1 : Code of Practice. London: British Standards Institution, 2006.

[15] LEBER, Jody. Windows NT. Zálohování a obnova dat. 1. vyd. Brno: Computer Press, 1998, 282 s. ISBN 80-722-6123-1.

[16] POŢÁR, Josef. Informační bezpečnost. Plzeň: Aleš Čeněk, 2005, 309 s. Vysokoškolská učebnice (Vydavatelství a nakladatelství Aleš Čeněk). ISBN 80868-9838-5.

95

[17] ROSICKÝ, Antonín. Informace a systémy: základy teorie pro úspěšnou praxi. Vyd. 1. Praha: Oeconomica, 2009, 200 s. ISBN 978-80-245-1629-5.

[18] SHARP, John. Jak postupovat při řízení kontinuity činností: Naplnění požadavků BS 25999. Risk Analysis Consultants, 2009. ISBN 978-80-254-39920.

[19] SNEDAKER, Susan. Business Continuity and Disaster Recovery Planning for IT Professionals Book. Burlington, MA: Syngress, 2007, 456 s. ISBN 1597491721.

[20] SVÁTÁ, Vlasta. Standardy/praktiky pro řízení sluţeb informační bezpečnosti. In: Inovativní přístupy služeb: Service Oriented Management : 16. září 2009 v Liberci. Vyd. 1. V Liberci: Technická univerzita, 2009, s. 65-72. ISBN 978-807372-510-5.

Elektronické zdroje:

[21] BRECHLEROVÁ, Dagmar. Řešení informační bezpečnosti (1. část). [online]. 2005 [cit. 2013-03-23]. Dostupné z: http://www.systemonline.cz/clanky/reseniinformacni-bezpecnosti-1-cast.htm

[22] ERNST & YOUNG, NBÚ, DSM – data security management. Průzkum stavu informační bezpečnosti v ČR 2009. Praha: Tate International, 2009. ISBN 97880-86813-19-6. Dostupné z: http://www.dsm.tate.cz/files/download/PSIB_CR_2009.pdf

[23] FLUTKA. Ochrana dat a jejich obnova v případě výpadku či havárie. [online]. [cit. 2012-04-10]. Dostupné z: www.kancelarskestroje.cz/uploads/assets/stories/pdf/clanek_ha_dr.pdf

96

[24] HALUZÍK, Roman. Business Continuity Management a aplikovaná metodika. [online]. 2009 [cit. 2012-02-14]. Dostupné z: http://businessworld.cz/aktuality/business-continuity-management-a-aplikovanametodika-2729

[25] KODL, Jindřich. Projektové řízení procesů kontinuity při provozování bezpečných IS. [online]. 2004 [cit. 2012-02-24]. Dostupné z: http://si.vse.cz/archive/proceedings/2004/projektove-rizeni-procesu-kontinuitypri-provozovani-bezpecnych-is.pdf

[26] KONTKIEWICZ, Andrzej. Desatero pro disaster recovery. [online]. 2011 [cit. 2012-03-22]. Dostupné z: http://www.businessworld.cz/it-strategie/desatero-prodisaster-recovery-7016

[27] KUNDEROVÁ, Ludmila. Obnova kontinuity informačního systému [online]. 2005 [cit. 2013-04-20]. Dostupné z: https://akela.mendelu.cz/~xakwari/gkunde.rtf

[28] NAGYOVÁ, Eva a Jana MIKULÁŠIOVÁ. Disaster recovery planning určite áno, ale... (prvý krok k BCM). [online]. 2009 [cit. 2012-04-25]. Dostupné z: http://www.tempest.sk/clanky-disaster-recovery-planning-urcite-ano--ale--prvykrok-k-bcm-/99s460c?stxt=&sekcia=&oblast=&sfrom=&sto=&page=3

[29] OPLETAL, Petr. K čemu je IT strategie. [online]. 2010 [cit. 2012-04-20]. Dostupné z: http://www.systemonline.cz/sprava-it/k-cemu-je-it-strategie.htm

[30] PADRTA, Aleš. Obnova po havárii (Disaster recovery). [online]. 2009 [cit. 2012-04-02]. Dostupné z: http://www.cesnet.cz/akce/2009/zazemi-pro-certcsirt/p/disaster-recovery.pdf

97

[31] PŘIBYL, Tomáš. Plánování kontinuity činnosti (1). [online]. 2009 [cit. 2012-0418].

Dostupné

z:

http://www.securityworld.cz/securityworld/Planovani-

kontinuity-cinnosti-1-1832

[32] PŘIBYL, Tomáš. Plánování kontinuity činnosti (2). [online]. 2009 [cit. 2012-0313].

Dostupné

z:

http://www.securityworld.cz/securityworld/Planovani-

kontinuity-cinnosti-2-1833

[33] RADECKÝ, Alexandr. Sedm vrstev disaster recovery. [online]. 2009 [cit. 201202-10]. Dostupné z: http://businessworld.cz/it-infrastruktura-virtualizace/sedmvrstev-disaster-recovery-1366

[34] RADECKÝ, Alexandr. Co zvážit při plánování disaster recovery. [online]. 2009 [cit. 2012-04-20]. Dostupné z: http://businessworld.cz/it-strategie/co-zvazit-priplanovani-disaster-recovery-7138

[35] ŠIROKÝ, Libor. Od golfu k certifikaci BCMS [online]. 2010 [cit. 2013-05-04]. Dostupné z: http://www.rac.cz/RAC/homepage.nsf/CZ/Clanky/$FILE/DSM-032010_Od golfu k certifikaci BCMS_Siroky.pdf

[36] TOBOLKA, Martin. Jak na havarijní plány a plány obnovy ICT infrastruktury?. [online].

2011

[cit.

2013-05-15].

Dostupné

http://www.systemonline.cz/sprava-it/jak-na-havarijni-plany-a-plany-obnovyict-infrastruktury.htm

98

z:

Seznam obrázků Obrázek 1 - Vztah úrovní bezpečnosti v organizaci. Zdroj: [9]

13

Obrázek 2 - Hrozby. Zdroj: http://www.accenture.com/SiteCollectionImages/Technology/ Outlook_Journal/Research_And_Insights/ITDisaster1.gif 16 Obrázek 3 – Bezpečnostní incidenty s nejzávažnějším dopadem 2008-2009. Zdroj: [22] 17 Obrázek 4 – Výskyt bezpečnostních incidentů 2008 – 2009. Zdroj: [22]

18

Obrázek 5 – Vztah mezi rizikem a vynaloženými náklady na jeho odstranění. Zdroj: [10] 23 Obrázek 6 – Oddíly bezpečnosti informací. Zdroj: [7]

26

Obrázek 7 – Postup tvorby bezpečnosti. Zdroj: [5]

29

Obrázek 8 – Struktura informační strategie. Zdroj: www.cacio.cz/priloha/32

33

Obrázek 9 - BCM rámec. Zdroj: http://www.checkpointontario.com/_bin/policies/continuity.cfm

39

Obrázek 10 - Postup vytváření plánu kontinuity. Zdroj: www.tsoft.cz/node/268

41

Obrázek 11 - Životní cyklus BCP/DRP. Zdroj: http://www.cesnet.cz/akce/2009/zazemipro-crt…/disaster recovery.pdf 42 Obrázek 12 - Analýza rizik-výběr opatření. Zdroj: http://tfirt.webst.fd.cvut.cz/10sem/bezpecnost_is/vypisky.pdf

44

Obrázek 13 - Časový přehled reakce na incident. Zdroj: http://cs.wikipedia.org/wiki/Business-Continuity-Management

46

Obrázek 14 – Hlavní části BCM a jejich vzájemné vztahy. Zdroj: [20]

49

Obrázek 15 – Postup tvorby havarijních plánů. Zdroj: http://tfirt.webst.fd.cvut.cz/10sem/bezpecnost_is/vypisky.pdf

51

99

Obrázek 16 – Porovnání nákladů na obnovu a ztrát z nedostupnosti procesu. Zdroj: www.cimib.cz/fileadmin/user upload/prezentace/02 cimib Chlup.pdf 54 Obrázek 17 - Znázornění virtualizace. Zdroj: www.kancelarskestroje.cz/uploads/assets/stories

57

Obrázek 18 - ERP systém. Zdroj: vlastní

67

Obrázek 19 - Diagram síťové architektury. Zdroj: vlastní

73

Obrázek 20 - Síťové prvky Nortel (zleva: Passport 1624G, ERS5520 48T, Contivity 600 VPN) Zdroj: firemní intranet 73 Obrázek 21 – Síťové prvky Juniper (SRX210 a EX4200 48T). Zdroj: firemní intranet

80

Obrázek 22- Diagram síťové architektury. Zdroj: vlastní

81

Obrázek 23 - Zálohování - rotace pásek. Zdroj: vlastní

83

Obrázek 24 - Diagram síťové architektury. Zdroj: vlastní

86

Seznam tabulek Tabulka 1 – Hrozby vnější. Zdroj: vlastní

14

Tabulka 2 – Hrozby vnitřní. Zdroj: vlastní

15

Tabulka 3 - Modelový příklad DRP. Zdroj: vlastní

89

Tabulka 4 – Modelový příklad zajištění kontinuity přijímání objednávek. Zdroj: vlastní 90

100