Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Diplomant:

Bc. Pavlína Lukášová

Vedoucí diplomové práce:

Ing. Dušan Chlapek, Ph.D.

Oponent diplomové práce:

RNDr. Jaroslav Dotlačil

Cloud Computing jako nástroj BCM

Akademický rok 2010/2011


Pavlína Lukášová

Prohlášení

Prohlašuji, ţe jsem diplomovou práci zpracovala samostatně a ţe jsem uvedla všechny pouţité prameny a literaturu, ze kterých jsem čerpala.

……………………………….

V Praze dne 10. prosince 2010

podpis

-ii/x-



Poděkování

Za odborné vedení a podnětné rady poskytnuté při psaní této práce bych ráda poděkovala vedoucímu své diplomové práce Ing. Dušanu Chlapkovi, Ph.D. Dále bych chtěla poděkovat také zástupcům Výpočetního centra Vysoké školy ekonomické v Praze, kteří si ochotně našli čas a poskytli mi cenné informace při zpracovávání této práce. Zvláštní poděkování bych ráda věnovala svým blízkým, kteří mě podporovali během mého dosavadního studia.

-iii/x-



ABSTRAKT Tato diplomová práce se zabývá moţnostmi propojení dvou konceptů: Business Continuity Management a Cloud Computing. Problematika Business Continuity Management je zvláště zaměřena na kontinuitu IT sluţeb a s ní souvisejících technických aspektů, mezi které patří Service Level Management a stanovení Service Level Agreement. V oblasti Cloud Computingu je důraz kladen především na otázky bezpečnosti, neboť tato část představuje největší překáţku implementace tohoto konceptu. Následně jsou v této diplomové práci identifikovány oblasti, ve kterých se oba výše zmíněné koncepty doplňují, oblasti, ve kterých Cloud Computing přináší pro BCM nové moţnosti a také oblasti, které by mohly činit potenciální problémy při konkrétní implementaci. Z tohoto důvodu je vymezeno několik poţadavků, které klade koncept BCM na Cloud Computing řešení. Dalším zaměřením této práce je charakteristika sektoru terciárního vzdělávání a postihnutí jeho základních odlišností od sektoru komerčního. Na základě těchto odlišností práce argumentuje vyuţitím vhodného Cloud Computing řešení za současného zlepšení Business Continuity. Analýza potenciálu konceptů Business Continuity Management a Cloud Computing v sektoru terciárního vzdělávání je následně verifikována oproti vydefinovaným poţadavkům a předpokladům. Výsledkem této části práce jsou podklady pro analýzu specifických podmínek na Vysoké škole ekonomické v Praze. V další části této práce je provedeno multikriteriální srovnání pěti řešení Infrastructure-as-a-Service, a to se zaměřením nejen na technické aspekty, ale také na aspekty finanční a aspekty Business Continuity. Zaměřením poslední části této práce je návrh praktického řešení pro konkrétní podmínky VŠE, a to jak v oblasti Business Continuity Management, tak i v oblasti Cloud Computing s důrazem na současné zlepšení Business Continuity. Navrhované řešení je znázorněno také pomocí strategické mapy a opomenuto není ani zhodnocení řešení z finančního hlediska.

KLÍČOVÁ SLOVA Business Continuity Management, BCM, Cloud Computing, virtualizace, infrastruktura jako sluţba, IaaS, hybridní cloud

-iv/x-



ABSTRACT This thesis deals with possible interconnections between two concepts: Business Continuity Management and Cloud Computing. Business Continuity Management domain is especially aimed at IT services continuity and related technical aspects such as Service Level Management or Service Level Agreement. Within Cloud Computing domain, the security topic is especially emphasized since this part of user concerns represents the biggest hurdle in the implementation process of this whole concept. Subsequently, there are certain areas identified where both concepts mentioned above are complement, where Cloud Computing brings new opportunities for BCM and where could possible problems arise during particular implementation. For those reasons there are several requirements defined. These requirements are set by BCM concept on any Cloud Computing solution. The characteristics of higher education and finding of basic differences from commercial sphere is another orientation of this thesis. Based on these findings the thesis argues for usage of suitable Cloud Computing solution together with improvement of Business Continuity in the same time. Potential analysis of Business Continuity Management and Cloud Computing concepts in higher education is subsequently verified against defined requirements and presumptions. Results of this part of thesis serve as an input for analysis of specific conditions on University of Econimics in Prague. Multi-criterion comparison of five Infrastructure-as-a-Service solution is performed in subsequent part of this thesis. The comparison is not only aimed at technical aspects but also at financial and Business Continuity aspects. The last part of this thesis deals with practical proposal for specific conditions on University of Economics in Prague within both Business Continuity Management and Cloud Computing domain. The improvement of contemporary Business Continuity is emphasized. The proposal is also demonstrated using strategic map and evaluated from the financial perspective.

KEYWORDS Business Continuity Management, BCM, Cloud Computing, virtualization, Infrastructure-as-aService, IaaS, hybrid cloud

-v/x-



OBSAH ÚVOD

1

VYMEZENÍ TÉMATU PRÁCE CÍLE PRÁCE PŘÍNOSY PRÁCE PŘEDPOKLADY A OMEZENÍ PRÁCE

1 2 2 2

1 CHARAKTERISTIKA BUSINESS CONTINUITY MANAGEMENT

3

1.1 VÝZNAM BUSINESS CONTINUITY MANAGEMENT PRO CHOD ORGANIZACE 1.2 ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY 1.3 ROZHODNUTÍ O SESTAVENÍ PLÁNU BUSINESS CONTINUITY 1.4 KRIZOVÉ ŘÍZENÍ 1.5 SERVICE LEVEL MANAGEMENT 1.5.1 DOBA OBNOVY A BOD OBNOVY 1.6 ALTERNATIVNÍ PROSTŘEDÍ 1.7 ÚPRAVA BCM VE STANDARDECH 1.7.1 MEZINÁRODNÍ ORGANIZACE PRO STANDARDIZACI ISO

3 5 6 7 8 8 10 10 11

2 CHARAKTERISTIKA CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE

12

2.1 POTENCIÁL CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE 2.2 BENEFITY PLYNOUCÍ Z ADOPCE CLOUD COMPUTINGU 2.3 HROZBY CLOUD COMPUTINGU Z HLEDISKA BEZPEČNOSTI 2.3.1 ZNEUŽITÍ A NEZÁKONNÉ POUŽITÍ CLOUD COMPUTINGU 2.3.2 OTÁZKY ZABEZPEČENÍ ROZHRANÍ 2.3.3 SDÍLENÍ INFRASTRUKTURY 2.3.4 ZTRÁTA NEBO ÚNIK DAT 2.3.5 OCHRANA UŽIVATELSKÝCH ÚČTŮ 2.4 ZRANITELNOSTI CLOUD COMPUTINGU 2.5 IDENTITY & ACCESS MANAGEMENT VE VAZBĚ NA CLOUD COMPUTING 2.6 NÁVRH BEZPEČNOSTNÍCH OPATŘENÍ PRO ADOPCI CLOUD COMPUTINGU

15 15 16 17 18 18 19 19 20 21 22

3 VAZBA CLOUD COMPUTINGU NA BUSINESS CONTINUITY MANAGEMENT

24

3.1 CO CLOUD COMPUTING SPOLEČNOSTEM PŘINÁŠÍ PRO JEJICH BUSINESS CONTINUITY 3.1.1 CLOUD COMPUTING JAKO VÝCHODISKO Z KRIZE 3.1.2 JAK MŮŽE CLOUD COMPUTING POMOCI ZAJISTIT BUSINESS CONTINUITY 3.1.3 PRAVIDLA ADOPCE CLOUD COMPUTINGU JAKO NÁSTROJE BUSINESS CONTINUITY 3.2 PŘEPOKLAD PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM 3.2.1 ŘÍZENÍ RIZIK 3.3 POŽADAVKY BCM NA CLOUD COMPUTING 3.4 KATEGORIE A - BEZPEČNOST 3.4.1 P01 BEZPEČNOST A MONITORING 3.4.2 DŮVĚRNOST INFORMACÍ 3.5 KATEGORIE B - DISASTER RECOVERY 3.5.1 P02 ZÁLOHOVÁNÍ A ARCHIVACE 3.6 KATEGORIE C - SERVICE LEVEL AGREEMENT 3.6.1 P03 DOSTUPNOST SLUŽEB

24 24 25 26 27 27 27 28 28 29 29 30 31 32

-vi/x-



3.7 NEGATIVNÍ DOPAD CLOUD COMPUTINGU NA BUSINESS CONTINUITY

33

4 VYUŽITÍ BCM A CLOUD COMPUTINGU V OBLASTI TERCIÁRNÍHO VZDĚLÁVÁNÍ

35

4.1 CHARAKTERISTIKA SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ A JEHO ODLIŠNOSTI OD SEKTORU 35 36 36 37 38 39 40 42 43 44 44 44 45 47 47

SOUKROMÉHO

4.2 VYUŽITÍ BCM V SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ 4.2.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI 4.2.2 FÁZE 2 – URČENÍ STRATEGIE BCM 4.2.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU 4.2.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU 4.3 POTENCIÁL CLOUD COMPUTINGU PRO SEKTOR TERCIÁRNÍHO VZDĚLÁVÁNÍ 4.3.1 KTERÉ SLUŽBY PŘESUNOUT DO CLOUDU A KDY 4.3.2 FENOMÉN „CONSUMERIZACE“ A SDÍLENÍ OBSAHU 4.3.3 VYUŽITÍ CLOUD COMPUTINGU PRO KOMUNIKACI 4.4 NAPLNĚNÍ PODMÍNEK BCM NA CLOUD COMPUTING ŘEŠENÍ 4.4.1 PŘEDPOKLAD – ŘÍZENÍ RIZIK 4.4.2 POŽADAVEK P01 BEZPEČNOST A MONITORING 4.4.3 POŽADAVEK P02 ZÁLOHOVÁNÍ A ARCHIVACE 4.4.4 POŽADAVEK P03 DOSTUPNOST SLUŽEB 4.5 DALŠÍ CHARAKTERISTIKY SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM 47 4.5.1 SP01 SEZÓNNOST 47 4.5.2 SP02 ZÁVISLOST NA IT 48 4.5.3 SP03 KONKURENČNÍ TLAK 48 4.5.4 SP04 INOVACE 48 5 POTENCIÁL BCM A CLOUD COMPUTINGU V PODMÍNKÁCH VŠE PRAHA

49

5.1 POPIS SOUČASNÉHO STAVU 5.1.1 SWOT ANALÝZA 5.1.2 PROCESNÍ MAPA VŠE 5.1.3 VÝPOČETNÍ CENTRUM 5.1.4 TECHNOLOGICKÁ INFRASTRUKTURA 5.1.5 STUDIJNÍ INFORMAČNÍ SYSTÉM 5.2 VÝBĚR VHODNÉ VARIANTY CLOUDOVÉHO ŘEŠENÍ 5.3 INFRASTRUKTURA JAKO SLUŽBA 5.4 VIRTUALIZACE 5.5 SOUKROMÝ CLOUD 5.6 HYBRIDNÍ CLOUD 5.7 VYUŽITÍ CLOUD COMPUTINGU PRO VÝUKU 5.8 CLOUD COMPUTING A OPEN SOURCE 5.9 POHLED ODDĚLENÍ VÝPOČETNÍHO CENTRA VŠE 5.9.1 P01 BEZPEČNOST A MONITORING 5.9.2 P02 ZÁLOHOVÁNÍ A ARCHIVACE 5.9.3 P03 DOSTUPNOST SLUŽEB 5.9.4 VIRTUALIZACE NA VŠE

49 49 50 51 52 52 53 53 56 56 58 59 60 61 61 61 62 62

6 ANALÝZA POSKYTOVATELŮ CLOUDOVÝCH ŘEŠENÍ NA TRHU

64

-vii/x-



6.1 VÝBĚR POSKYTOVATELŮ IAAS 6.2 VÝBĚR KRITÉRIÍ PRO ANALÝZU 6.3 POPIS VYBRANÝCH KRITÉRIÍ 6.3.1 TECHNICKÉ ASPEKTY 6.3.2 ASPEKTY BCM 6.3.3 FINANČNÍ ASPEKTY 6.4 GOGRID CLOUD HOSTING 6.4.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 6.4.2 HODNOCENÍ ASPEKTŮ BCM 6.4.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 6.4.4 CELKOVÉ HODNOCENÍ GOGRID CLOUD HOSTING 6.5 AMAZON EC2 6.5.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 6.5.2 HODNOCENÍ ASPEKTŮ BCM 6.5.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 6.5.4 CELKOVÉ HODNOCENÍ AMAZON EC2 6.6 RACKSPACE CLOUD SERVERS 6.6.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 6.6.2 HODNOCENÍ ASPEKTŮ BCM 6.6.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 6.6.4 CELKOVÉ HODNOCENÍ RACKSPACE CLOUD SERVERS 6.7 RELIACLOUD 6.7.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 6.7.2 HODNOCENÍ ASPEKTŮ BCM 6.7.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 6.7.4 CELKOVÉ HODNOCENÍ RELIACLOUD 6.8 ELASTICHOSTS 6.8.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 6.8.2 HODNOCENÍ ASPEKTŮ BCM 6.8.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 6.8.4 CELKOVÉ HODNOCENÍ ELASTICHOSTS 6.9 VZÁJEMNÉ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ 6.9.1 ZHODNOCENÍ OBLASTI TECHNICKÝCH ASPEKTŮ 6.9.2 ZHODNOCENÍ OBLASTI BUSINESS CONTINUITY 6.9.3 ZHODNOCENÍ OBLASTI FINANČNÍCH ASPEKTŮ 6.9.4 MULTIKRITERIÁLNÍ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ 6.10 ZÁVĚREČNÉ ZHODNOCENÍ

64 65 66 66 67 68 69 69 69 70 70 71 71 71 71 71 72 72 72 73 73 74 74 74 74 74 75 75 75 75 76 77 77 78 78 79 79

7 NÁVRH VHODNÉHO ŘEŠENÍ PRO VŠE PRAHA

80

7.1 OBLAST BUSINESS CONTINUITY MANAGEMENT 7.1.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI 7.1.2 FÁZE 2 – URČENÍ STRATEGIE BCM 7.1.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU 7.1.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU 7.2 OBLAST CLOUD COMPUTINGU 7.2.1 NAPLNĚNÍ PŘEDPOKLADU ŘÍZENÍ RIZIK 7.2.2 NAPLNĚNÍ POŽADAVKŮ BCM NA ŘEŠENÍ CLOUD COMPUTINGU

80 80 82 83 84 84 85 87

-viii/x-



7.2.3 BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ 7.2.4 FINANČNÍ ZHODNOCENÍ 7.3 SHRNUTÍ

88 89 90

ZÁVĚR

92

POUŽITÁ LITERATURA

94

INTERNETOVÉ ZDROJE

97

TERMINOLOGICKÝ SLOVNÍK

102

PŘÍLOHA A – SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ

108

PŘÍLOHA B – SEZNAM SERVERŮ PROVOZOVANÝCH NA VŠE

109

PŘÍLOHA C – STRUKTURA ROZHOVORU SE ZÁSTUPCI VÝPOČETNÍHO CENTRA VŠE

110

PŘÍLOHA D – PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ

111

PŘÍLOHA E – UKÁZKA WEBOVÉHO ROZHRANÍ DOSTUPNÉHO IAAS ŘEŠENÍ

112

PŘÍLOHA F – ŠABLONA PLÁNU BUSINESS CONTINUITY

117

SEZNAM OBRÁZKŮ OBR. 1 - PŘEHLED KONCEPTU BUSINESS CONTINUITY MANAGEMENT (ZDROJ: AUTOR) OBR. 2 - ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY MANAGEMENT (ZDROJ: [BCI2010A]) OBR. 3 - GRAFICKÉ ZNÁZORNĚNÍ RPO A RTO (ZDROJ: AUTOR) OBR. 4 - TYPY CLOUD COMPUTINGU (ZDROJ: AUTOR) OBR. 5 - PŘEHLED KONCEPTU CLOUD COMPUTING (ZDROJ: AUTOR) OBR. 6 - POŘADÍ OBAV Z ADOPCE CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [VELTE2010]) OBR. 7 - SROVNÁNÍ VÝPADKŮ EMAILOVÝCH SLUŽEB V MIN./MĚSÍC (ZDROJ: [GLOTZBACH2008]) OBR. 8 - PROCESNÍ MODEL VŠE (ZDROJ: AUTOR, VYTVOŘENO NA ZÁKLADĚ [TRCKA2009]) OBR. 9 - ARCHITEKTURA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [LENK2009]) OBR. 10 - ZOBRAZENÍ HYBRIDNÍHO CLOUDU (ZDROJ: AUTOR) OBR. 11 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR) OBR. 12 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR) OBR. 13 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR) OBR. 14 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR) OBR. 15 - GRAFICKÉ ZNÁZORNĚNÍ ŘEŠENÍ ELASTICHOSTS (ZDROJ: AUTOR) OBR. 16 - GRAFICKÉ ZNÁZORNĚNÍ POROVNÁNÍ IAAS ŘEŠENÍ VE 3 ROZMĚRECH (ZDROJ: AUTOR) OBR. 17 - GRAFICKÉ ZNÁZORNĚNÍ VZTAHU MEZI NÁKLADY NA OBNOVU A ZTRÁTOU ORGANIZACE (ZDROJ: AUTOR) OBR. 18 - BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ (ZDROJ: AUTOR) OBR. 19 - WEBOVÉ ROZHRANÍ (ZDROJ: AUTOR) OBR. 20 - VYTVOŘENÍ INSTANCE (ZDROJ: AUTOR) OBR. 21 - NASTAVENÍ PARAMETRŮ INSTANCE (ZDROJ: AUTOR) OBR. 22 - SPUŠTĚNÍ INSTANCE (ZDROJ: AUTOR) OBR. 23 - TIGHTVNC PŘIHLÁŠENÍ (ZDROJ: AUTOR) OBR. 24 - ROZHRANÍ INSTANCE (ZDROJ: AUTOR) OBR. 25 - ÚČTOVÁNÍ SLUŽEB (ZDROJ: AUTOR) -ix/x-

4 6 10 13 14 18 33 51 55 59 70 72 73 75 76 79 81 89 112 113 114 114 115 115 116



SEZNAM TABULEK TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB. TAB.

1 - KATEGORIZACE POŽADAVKŮ BCM NA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: AUTOR) 2 - PŘEHLED SROVNÁVANÝCH KRITÉRIÍ (ZDROJ: AUTOR) 3 - HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR) 4 - HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR) 5 - HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR) 6 - HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR) 7 - HODNOCENÍ ELASTICHOSTS (ZDROJ: AUTOR) 8 - POŘADÍ IAAS ŘEŠENÍ DLE HODNOCENÝCH KRITÉRIÍ (ZDROJ: AUTOR) 9 - POŘADÍ IAAS ŘEŠENÍ DLE TECHNICKÝCH PARAMETRŮ (ZDROJ: AUTOR) 10 - POŘADÍ IAAS ŘEŠENÍ DLE PARAMETRŮ BCM (ZDROJ: AUTOR) 11 - POŘADÍ IAAS ŘEŠENÍ DLE FINANČNÍCH KRITÉRIÍ (ZDROJ: AUTOR) 12 - SOUHRNNÁ TABULKA ANALÝZY DOPADU (ZDROJ: AUTOR) 13 - PŘÍKLAD PLÁNU BCM PRO RIZIKO ZTRÁTY DAT (ZDROJ: AUTOR) 14 - FINANČNÍ ZHODNOCENÍ NAVRŽENÉHO ŘEŠENÍ (ZDROJ: AUTOR) 15 - SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ (ZDROJ: [VSE2010]) 16 - SEZNAM SERVERŮ NA VŠE (ZDROJ: [TRCKA2009]) 17 - PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ (ZDROJ: AUTOR) 18 - ŠABLONA PLÁNU BUSINESS CONTINUITY (ZDROJ: AUTOR)

-x/x-

28 65 70 71 73 74 76 77 77 78 78 81 83 89 108 109 111 117



ÚVOD S koncepty Business Continuity Management a Cloud Computing se v dnešní době setkáváme často, a to zejména v kontextu řízení organizace a oblasti IT sluţeb. V době, kdy je kladen důraz na sniţování nákladů a efektivní vyuţívání dostupných zdrojů a v době, kdy pomalu doznívá finanční krize, a tak jakékoli prosazení nového konceptu vyţaduje velkou dávku odvahy, trpělivosti a především pádných argumentů. Na první pohled se zdá, ţe zajištění Business Continuity, tedy plynulého chodu organizace, by mělo být prioritou kaţdé fungující organizace. Ve skutečnosti však plán Business Continuity nemá ani zdaleka většina společností. Proč tomu tak je? Plán Business Continuity je často chápán jako ochrana před něčím, co se stane jednou za několik desítek let, nastane-li taková situace vůbec někdy. To ovšem neodpovídá realitě, protoţe nejčastější příčinou ohroţení kontinuity podniku nejsou přírodní katastrofy, ale technické závady nebo chyby zaviněné lidským faktorem. Tyto otázky je moţné řešit vyuţitím Cloud Computingu, jinými slovy vyuţívat poskytovaný software, platformu nebo infrastrukturu jako sluţbu v rámci sítě internet a odebírat tuto sluţbu pouze v případě potřeby. Díky tomuto konceptu se společnosti nejen sniţují náklady, ale část IT zdrojů se tak automaticky přesouvá na jiné místo, čímţ je automaticky zajištěna dostupnost sluţeb v případě, kdy by se v budově společnosti vyskytl jakýkoli problém. Tato diplomová práce se zaměřuje na propojení obou konceptů: Business Continuity Management a Cloud Computing. Hledá oblasti, ve kterých se oba koncepty doplňují a oblasti, které by mohly činit potenciální problémy při konkrétní implementaci.

VYMEZENÍ TÉMATU PRÁCE Nejprve jsou v této práci popsány základní charakteristiky Business Continuity Management. Jedná se o velmi širokou a komplexní oblast, proto je hlavním zaměřením kontinuita IT sluţeb a s ní související technické aspekty, mezi které patří Service Level Management a stanovení Service Level Agreement. V další části je podrobněji přiblíţen koncept Cloud Computingu. Obdobně jako u Business Continuity, i zde se jedná o velmi širokou problematiku, proto byla vybrána pouze část bezpečnosti, které je věnována větší pozornost. Otázky bezpečnosti jsou v této práci řešeny z toho důvodu, ţe bezpečnost je nejčastější příčinou obav společnosti implementovat koncept Cloud Computingu. Po popsání základních charakteristik obou konceptů je pozornost zaměřena na oblast terciárního vzdělávání a jeho odlišnosti od komerčního sektoru. Zde je popsáno, jakým způsobem je moţné vyuţívat cloudová řešení a jaká je jejich vhodnost pro tuto oblast. Na tuto kapitolu navazuje analýza potenciálu vyuţití Business Continuity Management a Cloud Computing na Vysoké škole ekonomické v Praze (dále VŠE), která vychází z popsání současného stavu výpočetní techniky na VŠE. V následující části je provedena analýza poskytovatelů cloudových řešení, pro kterou byli vybráni poskytovatelé řešení Infrastructure-as-a-Service. Tito poskytovatelé byli vybráni z důvodu své vhodnosti pro vyuţití v sektoru terciárního vzdělávání. Jejich vhodnost je výsledkem předchozí analýzy tohoto sektoru. Celkem bylo hodnoceno pět poskytovatelů, jejichţ nabídku bylo moţné srovnávat. Závěrem této práce byla analýza vhodnosti Cloud Computing řešení pro naplnění Business Continuity poţadavků v konkrétních podmínkách VŠE a návrh vhodného řešení pro další rozvoj této instituce. -1/117-



CÍLE PRÁCE Tato diplomová práce má několik cílů, které lze vymezit takto: 







Identifikovat vazbu konceptu Cloud Computing na koncept Business Continuity Management a pokusit se nalézt oblasti, ve kterých Cloud Computing přináší pro Business Continuity nové moţnosti. Charakterizovat sektor terciárního vzdělávání, postihnout základní odlišnosti od sektoru komerčního a pro tyto odlišnosti argumentovat vhodným řešením Cloud Computingu za současného zlepšení Business Continuity. Provést multikriteriální srovnání Infrastructure-as-a-Service řešení nabízených na trhu cloudových sluţeb a argumentovat, proč jsou tato řešení pro sektor terciárního vzdělávání vhodná. Na základě analýzy současného stavu navrhnout moţné řešení Cloud Computing sluţeb v prostředí Vysoké školy ekonomické v Praze.

PŘÍNOSY PRÁCE Přínosy této práce lze shrnout do následujících bodů: 





Zmapování vazeb mezi oběma koncepty a vymezení oblastí, ve kterých je účinné a účelné vyuţít konceptu Cloud Computing pro zlepšení Business Continuity, a dosáhnout tak efektivnosti IT zdrojů společnosti či sníţení nákladů. Provedení multikriteriálního srovnání nejvýznamnějších poskytovatelů IaaS řešení, které můţe čtenáři slouţit v procesu rozhodování o implementaci cloudových sluţeb, a to s důrazem na kritéria technologická, kritéria Business Continuity a v neposlední řadě také kritéria finanční. Praktický návrh řešení Cloud Comutingu ve specifickém prostředí Vysoké školy ekonomické v Praze.

PŘEDPOKLADY A OMEZENÍ PRÁCE Omezením této práce v oblasti Business Continuity Managementu je její soustředění zejména na IT sluţby. Z důvodu širokého rozsahu tohoto konceptu bylo nutné do této diplomové práce vybrat pouze určitou část. IT sluţby byly vybrány především pro jejich úzkou vazbu na Cloud Computing řešení. Předpokladem této práce v oblasti Cloud Computing je skutečnost, ţe bezpečnostní aspekty jsou nejčastější příčinou, proč se společnosti zdráhají vyuţívat cloudových sluţeb naplno. Proto se tato práce v oblasti Cloud Computingu zaměřuje především na otázky bezpečnosti. Posledním omezením této práce je návrh praktického řešení pro specifické podmínky Vysoké školy ekonomické v Praze. Záměrně byly pro návrh řešení opomíjeny ostatní typy a velikosti společností.

-2/117-



1 CHARAKTERISTIKA BUSINESS CONTINUITY MANAGEMENT Business Continuity Management z velké části zahrnuje aktivitu plánování kontinuity pro případy vzniku interní či externí krize. Tento proces v sobě kombinuje jak měkké, tak tvrdé přístupy tak, aby vytvořil účinnou prevenci a obnovu organizace, a to za současného zachování konkurenční výhody a bez ztráty na pověsti společnosti. Business Continuity Management (dále jen BCM) začal být v posledních letech často skloňovaným pojmem. Bývá spojován především s krizovým řízením, ale ve skutečnosti BCM navazuje na řízení podnikových procesů, koncept bezpečnosti, logistiku a na řadu dalších principů efektivního fungování společnosti. Rozšířil se jak v soukromé sféře, tak ve sféře veřejné, výjimkou není ani sektor školství. V této kapitole se zaměříme na základní charakteristiky tohoto konceptu. Definice BCM tak, jak je pouţívána evropským orgánem Business Continuity Institute, hovoří o BCM jako o konceptu důleţitém pro všechny organizace nezávisle na sektoru ekonomiky, neboť udrţuje nejen efektivní chod společnosti, ale zajišťuje také prevenci případných ztrát a ochranu značky či dobrého jména podniku: "Business Continuity Management je holistický přístup k řízení společnosti, jenţ identifikuje potenciální dopady na organizaci, které by mohly ohrozit efektivní fungování společnosti, a poskytuje rámec pro vybudování pruţného systému schopného reagovat na krizové situace, a hájit tak zájmy zainteresovaných stran." [BCI2010b] Základním předpokladem úspěšné aplikace BCM je identifikace procesů organizace, a to především procesů klíčových, tj. takových procesů, jejichţ narušení nebo úplná absence by způsobila neschopnost organizace naplňovat své cíle. Poté, co jsou procesy identifikovány a v ideálním případě také popsány, můţe organizace pokračovat v identifikaci a ohodnocení rizik, se kterými je moţné se setkat. Podle [Billsberry2004] patří mezi nejčastěji zmiňované případy rizik kategorie přírodních katastrof, jako jsou poţáry či povodně, v poslední době se také často setkáme s riziky teroristického útoku či útoku po síti internet. Přitom v praxi mnohem častějšími riziky jsou rizika selhání technologie, poškození rozvodů vody či přerušení dodávky elektrické energie. Dojde-li k identifikaci klíčových procesů, jejich výstupů a ohodnocení rizik ohroţujících pravidelný chod organizace, je moţné začít sestavovat plán, který by stanovoval, jaká opatření mají být aplikována v případě, ţe nastanou podmínky způsobené ohodnocenými riziky. Součástí BC plánu není však pouze ohodnocení dopadu rizik na podnikové procesy, ale je jí také porozumění tomu, které části pouţívané IT technologie jsou zranitelné různými typy rizik. [Snedaker2007] Je-li plán jednou stanoven, neznamená to, ţe je stanoven na několik let dopředu a nebude potřeba ho obnovovat. Plán BC je potřeba neustále aktualizovat, jedná se o stále opakující se proces revize plánu, který by měl vycházet ze samotné podstaty podnikové kultury.

1.1 VÝZNAM BUSINESS CONTINUITY MANAGEMENT PRO CHOD ORGANIZACE Proč je BCM pro chod organizace důleţité? Není to dáno jenom z toho důvodu, ţe organizace v takovém případě vlastní návod na to, co dělat v případě, kdy nastane krizová situace, ale zároveň pomáhá minimalizovat počet špatných rozhodnutí v případě, ţe krize nastane. Sniţuje také závislost na zaměstnancích, kteří jsou ve společnosti přítomni v době krize a jejichţ specifické rozhodnutí by mohlo zapříčinit ztrátu dat, příjmů nebo zákazníků [Denault2004]. V neposlední řadě by mohlo poškodit také pověst, značku a dobré jméno společnosti. Z výše uvedených důvodů vyplývá, ţe definice BC plánu je důleţitá ve všech odvětvích, neboť je podstatné, aby byla společnost schopna na vzniklou situaci reagovat efektivně a rychle, a mohla tak -3/117-



včasně obnovit chod podnikových procesů a v neposlední řadě také zajistit bezpečnost zaměstnanců i veřejnosti. Podle [Snedaker2007] je klíčovou hnací silou pro BCM zhodnocení toho, jak velké narušení chodu společnosti je pro podnik přijatelné a co je společnost schopna a ochotna udělat pro to, aby narušení předešla. V dobách ekonomické recese se pro BCM argumentuje obtíţněji neţ v dobách "dobrých". Těţko lze předpokládat, ţe je moţné management společnosti přesvědčit tvrzením, ţe BCM pomůţe společnosti vyrovnat se s něčím, co potenciálně hrozí jednou za několik let. [Pribyl2010] Důleţitou skutečností však je to, ţe BCM napomáhá zajistit a udrţet stabilitu v otázkách důvěry ze stran zákazníků a jejich loajalitu. Samotný tento fakt má za důsledek, ţe BCM pomáhá udrţovat tok peněz neboli cash flow. Nutnost identifikace rizik potenciálně hrozících společnosti a definice plánu Business Continuity (dále jen BC plánu) není spojena jen s rozvojem informačních technologií či érou internetu. Potřeba BC plánu byla nutná uţ od samotného počátku vzniku podnikání. Popření potřeby sestavení BC plánu v 21. století, kdy technologie sahá prakticky do všech koutů jakékoli organizace, by však nemělo být nadále akceptováno. Jak jiţ bylo uvedeno výše, BCM by měl být zakořeněn v samotné podnikové kultuře a měli by to být právě manaţeři odpovědní za zajištění dostupnosti systémů či sluţeb, kteří by měli mít eminentní zájem na sestavení BC plánu. Absence BC plánu ve společnosti by totiţ mohla být chápána jako nedbalost plnění jejich pracovních povinností a výše uvedené důsledky krize by společnost mohly dovést ke zbytečně vysokým pokutám. Na Obr. 1 je znázorněn přehled konceptu BCM. Jednotlivým částem popsaným na obrázku bude věnován následující text této kapitoly. Zvláštní důraz je kladen na popsání ţivotního cyklu, krizové řízení a určení doby a bodu obnovy jednotlivých podnikových procesů.

Obr. 1 - Přehled konceptu Business Continuity Management (Zdroj: Autor)

-4/117-



1.2 ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY Ţivotní cyklus Business Continuity popisuje nejen postup tvorby plánu, ale také aktivity tvorbě plánu předcházející, mezi které patří například identifikace rizik, a aktivity následné. Samotný ţivotní cyklus Business Continuity sestává z několika fází (viz Obr. 2 – Ţivotní cyklus Business Continuity Management). Ve vnitřním kruhu nalezneme řízení programu a politiky BCM. Politikou BCM se rozumí klíčový dokument, který určuje rozsah BCM a představuje důvod, proč by mělo být BCM implementováno. Politika BCM musí být v souladu se strategií organizace. Dokument je základním vstupem pro proces BCM plánování. Ve vnějším kruhu je znázorněno začlenění BCM do kultury organizace, pod kterým se rozumí vybudování takového systému, kde by byl BCM součástí kaţdodenního provozu organizace a byl v souladu s prioritami společnosti. Zpravidla je nutné, aby se kultura organizace na základě BCM politiky změnila. V prostředním kruhu je zobrazen proces BCM sestávající ze čtyř hlavních fází [BCI2010a]: 







Porozumění organizaci – porozumění organizaci je činnost, která reviduje činnost organizace ve smyslu jejích cílů, jednotlivých funkcí a omezení prostředí, ve kterém se pohybuje. Pro porozumění organizaci jsou zpravidla vyuţívány následující nástroje: o Analýza dopadu (Business Impact Analysis – BIA) – analýza slouţící k ohodnocení dopadu, jaký by měla narušující událost na provoz organizace, o Continuity Requirements Analysis (CRA) – vyuţívá se k odhadu zdrojů a sluţeb, které vyţaduje kaţdá činnost, aby mohla být obnovena do běţného provozu organizace, o Ohodnocení rizik (Risk Assessment – RA) – je pouţíváno k odhadu pravděpodobnosti dopadu neznámé hrozby na určitou funkci organizace. Před provedením analýzy odhodnocení rizik by měla být provedena analýza dopadu (BIA), pomocí které jsou určeny klíčové činnosti podniku. Určení strategie BCM – jedná se o aktivitu, která určuje strategii nejlépe naplňující poţadavky organizace a sestavuje postupy na taktické úrovni (pro oblasti lidských zdrojů, budov a zařízení, technických zdrojů apod.). V rámci tohoto kroku jsou stanovovány hodnoty parametrů maximální tolerovatelná doba odstávky, čas obnovy a doba obnovy, které jsou podrobněji popsány v kapitole 1.5.1. Tvorba a implementace BC plánu – na této úrovni dochází k sestavení sady plánů Business Continuity. Tyto plány zahrnují jasně definovaný proces eskalace a řízení incidentu, způsob komunikace mezi zainteresovanými stranami a plány obnovy narušených činností na taktické, operativní i strategické úrovni. Školení, údrţba a revize – tato fáze ţivotního cyklu vychází z dokumentu politiky BCM a zajišťuje ověřování, zda by byla organizace stále schopna obnovit svou činnost a zhodnocuje dopad změn v organizační struktuře, podnikových procesech, trhu, rizicích, prostředí a podnikové strategie na schopnost zajistit kontinuitu podniku.

-5/117-



ě len

BCM ní

do kultury organ iz

a ce

č Za

Porozumění organizaci

Školení, údržba a revize

Řízení programu a politiky BCM

Určení strategie BCM

Tvorba a implementace BCM plánu

Obr. 2 - Ţivotní cyklus Business Continuity Management (Zdroj: [BCI2010a])

1.3 ROZHODNUTÍ O SESTAVENÍ PLÁNU BUSINESS CONTINUITY Horní ekonomickou hranicí společnosti bývají výnosy, o jejichţ maximalizaci podnik usiluje. K tomu, aby společnost dosáhla zvýšení výnosů, můţe dospět kupříkladu získáním většího podílu na trhu. Měnit se však nebude jen velikost podílu na trhu a výše trţeb, ale také výše nákladů a s nimi spojená rentabilita investice do zvýšení podílu na trhu. A právě rentabilita je jakousi spodní ekonomickou hranicí společnosti, která se stává důleţitějším měřítkem v dlouhodobém horizontu. Proto většina společností hledá rovnováhu mezi růstem spodní a horní hranice. [Snedaker2007] Spojitost mezi těmito hranicemi a sestavením BC plánu je právě v uvědomění si, jakou cenu je podnik ochoten zaplatit za činnost sestavení plánu a jakou cenu je ochoten zaplatit v případě, ţe nastane krizová situace a selhání podniku bude mít finanční dopady. Je-li společnost zaměřena na zvyšování výnosů, její prioritou sestavení plánu BC nebude. Vlastnictví BC plánu však můţe být chápáno jako konkurenční výhoda, neboť zákazníci by existenci takového plánu mohli vnímat pozitivně. Na druhé straně, je-li společnost zaměřena na zvyšování rentability, je snazší přesvědčit management, ţe potenciální hrozba by měla zásadní dopad na provozní výkonnost. Není pochyb o tom, ţe ať uţ se společnost zaměřuje na zvyšování výnosů nebo na zvyšování rentability, v obou případech je dopad selhání podniku značný, a proto by si společnost měla uvědomit, jakou cenu je ochotna obětovat ve prospěch, resp. v neprospěch sestavení BC plánu. Ze studie provedené v roce 2005 [Snedaker2007] vyplývá, ţe ze všech společností, které byly postihnuty ztrátou podstatné části dat a zároveň postrádaly BC plán nebo plán obnovy dat, 43% nebylo

-6/117-



nikdy obnoveno, 51% ukončilo svou činnost do 2 let a pouze 6% z nich přeţilo v dlouhodobém horizontu. Ve stejném roce byla provedena jiná studie [Snedaker2007], která odhalila, ţe 92% společností se shoduje na tom, ţe je pro ně důleţité plánovat opatření pro mimořádné události, 88% uvedlo, ţe jsou vlastníky jakéhokoli plánu pro mimořádné situace a pouze 39% z dotázaných odpovědělo, ţe BC plán mají. Co je však zajímavé, je skutečnost, ţe ačkoli celých 92% uvedlo, ţe je důleţité plánovat pro mimořádné události, 12% dotázaných si nemyslí, ţe vlastnit plán pro mimořádné situace má pro jejich společnost význam.

1.4 KRIZOVÉ ŘÍZENÍ Krizové řízení je proces přípravy na vznik nepředvídané negativní události, která by mohla zapříčinit omezení činnosti podniku, nebo dokonce její zastavení. Tato negativní událost ohroţuje organizaci, zainteresované strany nebo veřejnost. [ICM2005] Krizové řízení s BCM velmi úzce souvisí. BCM je zaměřeno primárně na dlouhodobější aspekty zotavení z krize jako je např. přemístění provozu do jiné lokace. Z plánů BCM však krizové řízení vychází, neboť se v podstatě jedná o rozhodování, zda další vývoj událostí povede k zániku provozu organizace, nebo spíše k obnovení stavu na úroveň existující před vznikem krize. Krize je podle [ICM2005] definována jako významné narušení podnikové činnosti. Událost, která posléze ústí v krizi má tři základní elementy:   

hrozba pro organizaci, moment překvapení, omezená doba pro rozhodování.

Krize můţe vznikat několika způsoby. Podle [Martanova2010] můţe být krize na jedné straně způsobena ze strany businessu (např. nízký odbyt, management neschopný tvořit strategická rozhodnutí, nízká poptávka, špatná komunikace ve firmě, ztráta klíčových zaměstnanců, silná legislativní regulace apod.) a na straně druhé podniku hrozí krize způsobené katastrofami (poţár v budově podniku, havárie na výrobní lince, epidemie infekční choroby, kolaps datového centra, záplavy atd.). Vedle těchto řekněme nejběţnějších událostí týkajících se krizového řízení rozeznáváme také hrozby kriminálního charakteru plynoucí z kriminálních činností, sociálněpolitické hrozby a také hrozby typické pro určitý sektor ekonomiky, např. u bank lze hovořit o finančních hrozbách. Aby společnost předcházela katastrofálním důsledkům krize, je pro ni důleţité rozdělit své procesy do několika následujících oblastí:   

procesy, které vydělávají peníze a jsou jádrem podniku, procesy, které peníze nevydělávají, ale tvoří jádro podniku, podpůrné procesy.

Je úlohou kaţdého krizového manaţera nastavit taková opatření, která budou nejvhodnější pro danou kategorii procesů. V rámci komplexního ochranného systému řízení kontinuity jsou pro vytipované klíčové procesy vytvářeny procesy alternativní, které jsou spuštěny v případě, kdy původní proces nemůţe fungovat svým běţným způsobem. Mezi základy krizového řízení patří také sestavení skupin lidí na několika různých úrovních, které mají na starosti řešení problému v případě, kdy nastane. Tyto skupiny jsou hierarchicky uspořádány. Nejníţe postavené týmy odpovídají za řešení problému na úrovni divizí nebo podnikových jednotek, zatímco na nejvyšší úrovni je tým koordinující činnosti týmů jemu podřízených, který se zároveň zodpovídá vedení společnosti a pravidelně jej informuje o aktuálním vývoji situace. -7/117-



1.5 SERVICE LEVEL MANAGEMENT Service Level Management (dále SLM) je proces, na jehoţ základě organizace identifikuje a určuje úroveň IT sluţby, která je potřeba k podpoře businessu a definuje mechanismus, kterým je moţné úroveň sluţeb monitorovat tak, aby bylo moţné zajistit jejich dodrţování. V rámci procesu SLM jsou typicky určeny Service Level Agreement (dále SLA), coţ jsou ujednání mezi poskytovatelem a odběratelem sluţby, ve kterých je definováno, co přesně která sluţba znamená, co poskytuje a na jaké úrovni je potřeba sluţbu udrţovat tak, aby ji mohl odběratel vyuţívat k účelům, ke kterým je určena. [Sun2007] Vedle stanovení úrovně SLA jsou určeny také úrovně Operational Level Agreement (OLA), které definují vzájemné vztahy mezi interními jednotkami organizace, které se společně podílejí na zajištění a poskytování jedné sluţby v rámci jedné SLA. Součástí SLM je IT Service Continuity Management (dále ITSCM), který je procesem definovaným konceptem ITIL a který podporuje souhrnný BCM, neboť jeho hlavním účelem je zajistit obnovení nezbytné IT infrastruktury. [Galup2007] IT v dnešní době hraje nezbytnou roli v podpoře a naplňování podnikových poţadavků. ITSCM je disciplína řízení IT sluţeb, která je procesně orientovaná a je často spojována se standardy ITIL, ve kterých je podsekce věnovaná této problematice zaměřena zejména na podporu sluţeb a na jejich dodání. Podle studie provedené společností Gartner [Potter2009] spadá 80% nákladů na infrastrukturu právě do těchto dvou oblastí. Koncept BCM je s procesem SLM velmi úzce spjat. Zatímco SLM specifikuje konkrétní a měřitelnou úroveň IT sluţby a definuje smlouvu SLA mezi poskytovatelem a odběratelem, BCM přebírá SLA jako klíčový dokument, do kterého poskytuje vstupy. Pojato obráceně, SLM se musí stát nutnou součástí BC plánů, ve kterých je na základě SLM specifikována obnova klíčových IT sluţeb a aplikací v dohodnutých úrovních, které vyhovují zákazníkovi/odběrateli, a to do doby, neţ bude obnoven běţný provoz společnosti. Přitom je důleţité si uvědomit, ţe není nezbytně nutné, aby všechny sluţby byly okamţitě obnoveny na 100%, coţ by právě mělo být ukotveno v BC plánech.

1.5.1 DOBA OBNOVY A BOD OBNOVY Mezi nejdůleţitější parametry SLA z hlediska BC plánů patří doba obnovy (RTO - Recovery Time Objective) a bod obnovy (RPO - Recovery Point Objective) – viz Obr. 3. V následujícím textu jsou popsány vedle RTO a RPO i další parametry týkající se času obnovy [Snedaker2007]: 

Maximální tolerovatelná doba odstávky (MTD - Maximum Tolerable Downtime) - stanovuje maximální dobu, po kterou je business ochoten tolerovat neexistenci nebo nedostupnost určité funkce podniku. Pro kaţdou podnikovou funkci je definována samostatná maximální tolerovatelná doba odstávky. Logicky klíčové funkce budou mít nejkratší tolerovatelnou dobu odstávky. MTD je sloţeno ze dvou elementů, a to času obnovy a pracovního času obnovy. 𝑀𝑇𝐷 = 𝑅𝑇𝑂 + 𝑊𝑅𝑇





Čas obnovy (RTO - Recovery Time Objective) - čas, za který je moţné obnovit narušené systémy a zdroje, jinými slovy je to systémový čas obnovy. Je součástí MTD. Pokud je například MTD pro klíčový podnikový proces 3 dny, systémový čas obnovy můţe být 1 den. Znamená to, ţe společnost musí obnovit funkcionalitu všech systémů potřebných pro běh klíčového podnikového procesu během jednoho dne. Pracovní čas obnovy (WRT - Work Recovery Time) - je druhým elementem tvořícím MTD. Jestliţe MTD je 3 dny, RTO 1, tak WRT je 2 dny. Znamená to, ţe společnost má 2 dny na to, aby zcela obnovila chod procesu za předpokladu, ţe jiţ běţí podpůrné systémy. V rámci WRT -8/117-



jsou obnovovány a zajišťovány všechny vstupy pro proces, lidské zdroje, dokumenty a legislativní zajištění apod. Pracovní čas obnovy bývá bohuţel často přehlíţen, a to především ze strany IT oddělení. Z pohledu IT je dostačující, aby byly znovu obnoveny aplikace, které proces podporují. Avšak z pohledu businessu zde jsou dodatečné kroky, které musí být provedeny, aby bylo moţné podnikový proces opět spustit. 

Bod obnovy (RPO - Recovery Point Objective) - objem nebo rozsah ztracených dat, který je společnost ochotna tolerovat z hlediska nezbytných podnikových systémů. Některé společnosti zálohují data v reálném čase, některé v řádech hodin, dnů či týdnů. Od periody zálohy dat se odvíjí také tolerovatelná ztráta dat. Jestliţe je záloha dat prováděna jednou týdně, znamená to, ţe podnik je ochoten tolerovat aţ týdenní ztrátu dat.

Poţadavky zákazníka na RTO/RPO se v mnoha případech liší od moţností dodavatele. Moţných řešení, jak dosáhnout konsensu při stanovování RTO/RPO nalezneme v běţné praxi hned několik [Martanova2010]: 

Provedení odborné analýzy dopadů (Business Impact Analysis) - analýza dopadu je proces identifikace klíčových podnikových funkcí a ohodnocení dopadu a ztráty v případech, kdy je dotčená podniková funkce nedostupná. V rámci této analýzy je třeba nejen ohodnotit dopad, který by měla událost na chod podniku, ale také určit dobu výpadku podnikové funkce, která jiţ ohroţuje samotnou existenci organizace. Výsledkem analýzy dopadů je dle [Rittinghouse2005] hodnocení a seřazení všech klíčových i podpůrných podnikových funkcí v pořadí odpovídající jejich nutnosti obnovy, a to na základě předchozího kolektivního ohodnocení těchto funkcí v rámci společnosti. Podle Business Continuity Institute [BCI2007] nebo [Snedaker2007] rozlišujeme 4 základní účely analýzy dopadu: obdrţet informace o nezbytných cílech organizace, jejich priority a dobu, za kterou by bylo moţné obnovit běţný chod společnosti tak, aby stále mohla naplňovat cíle, které jsou pro ni existenčně důleţité, o získat rozhodnutí vedení společnosti o maximální tolerovatelné době odstávky pro kaţdou podnikovou funkci, o poskytnout relevantní informace, na základě kterých by bylo moţné sestavit/doporučit strategii obnovy, o načrtnout jak externí, tak interní závislosti mezi podnikovými funkcemi, které vedou k naplnění podstatných podnikových cílů. Stanovení RTO/RPO, které můţe být nabídnuto dodavatelem - jedná se o interní moţnosti dodavatele, které je schopen zajistit. Zainteresování obou stran do procesu vyjednávání - výstupem tohoto procesu by měla být také dojednaná strategie obnovy podnikových funkcí. o

 

Výsledky analýzy dopadu a ostatních metod dosaţení konsensu v procesu stanovení RTO/RPO podnikových funkcí by se měly stát podkladem nejen pro BC plánování. [Rittinghouse2005] Výsledkem je kompromis, který má jisté finanční aspekty a dopad jak na poskytovatele, tak na zákazníka, neboť z finančního hlediska se vţdy jedná o rozloţení nákladů mezi obě strany. Část investice plyne ze strany zákazníka a část je také nucen investovat poskytovatel do svého interního BCM.

-9/117-



Časový úsek od poslední zálohy

Recovery Point Objective

Časový úsek do obnovení systému

Narušující událost

Recovery Time Objective

Obr. 3 - Grafické znázornění RPO a RTO (Zdroj: Autor)

1.6 ALTERNATIVNÍ PROSTŘEDÍ V případě, ţe dojde k přerušení moţnosti přístupu k primárnímu prostředí, ať uţ z jakéhokoli důvodu, potřebuje mít společnost k dispozici řešení, jak zajistit podnikovou činnost. Jedním z těchto řešení je také moţnost vlastnit alternativní prostředí. V praxi rozeznáváme několik druhů alternativních prostředí [Rittinghouse2005]: 



 



Cold site – jedná se o prostředí, které odpovídá prostředí provoznímu, ale v tomto prostředí není umístěno ţádné vybavení. Je připraveno na to, aby bylo veškeré vybavení do prostředí teprve přesunuto po vzniku krizové situace. Na místě mohou být připraveny telefonní přípojky, přípojky do elektrické sítě, připojení k internetu atd. Hot site – jedná se o prostředí, které poskytuje prostor pro zaměstnance a je plně vybaveno včetně zdrojů a infrastruktury tak, aby mohly být okamţitě obnoveny kritické podnikové funkce. Warm site – částečně zařízené prostředí typu hot site, kde však není umístěno tolik vybavení jako v případě hot site. Podmínkou je, ţe data zde umístěná nesmí být příliš stará. Mobile site – jedná se o prostředí, které je dočasné a je pouze částečně vybavené. Zpravidla bývá umístěno nedaleko primárního prostředí, aby tak byl ušetřen čas zaměstnanců na přesun do odlehlejšího prostředí. Mirrored site – jedná se o zcela identické prostředí s prostředím primárním jak do vybavení, tak do umístěných dat, tak do bezpečnostních opatření. Je ekvivalentem redundantního prostředí, a je tak nejdraţší moţností z výše uvedených typů.

1.7 ÚPRAVA BCM VE STANDARDECH Business Continuity Management podléhá současné právní úpravě, regulacím a je také ustanoven v řadě standardů, a to jak na národní, tak na mezinárodní úrovni. Z hlediska legislativní úpravy spadá Česká republika pod ustanovení Evropské unie, a to zejména pod Evropský program ochrany kritické infrastruktury, který byl představen ve směrnicích EU a je zaloţen na seznamu evropské kritické infrastruktury podle vstupů vloţených jednotlivými členskými státy. Regulace BCM je v rámci Evropy implementována pouze ve finančním sektoru, zejména se jedná o bankovní instituce a pojišťovny. V některých zemích se úprava týká také zdravotní péče a sektoru jaderné energie. [Gilbert2010] V oblasti standardů se setkáme s řadou úprav především ze strany Mezinárodní organizace pro standardizaci a Britského institutu standardizace. Protoţe je pro území České republiky relevantní -10/117-



zejména úprava ze strany organizace ISO, zaměříme se především na její standardy, které jsou uvedené v následující podkapitole. BCM se dotýkají také další standardy, mezi které patří ITIL (Continuity Management jako součást knihy „Service Design“) a COBIT (P03, P09).

1.7.1 MEZINÁRODNÍ ORGANIZACE PRO STANDARDIZACI ISO Mezinárodní organizace pro standardizaci ISO vydala jiţ několik standardů, které se nějakým způsobem dotýkají Business Continuity organizace. Jeden ze standardů týkající se ICT je teprve vyvíjen, zbývající tři standardy jsou seřazeny podle data vydání v textu níţe [ISO2010]: 

ISO/IEC FCD 27031 – Information Technology – Security techniques – Guidelines for ICT readiness for business continuity Tento standard dosud nebyl vydán, nyní se nachází ve stavu konceptu. V budoucnu bude tento standard definovat Business Continuity pro ICT, konkrétně bude navrhovat rámcovou strukturu (metody a procesy) pro jakoukoli organizaci (soukromou, veřejnou…), identifikovat relevantní aspekty pro zlepšení připravenosti ICT, a umoţnit tak organizacím změřit svou připravenost na vznik narušujících událostí.



ISO/IEC 24762:2008 – Information technology – Security techniques – Guidelines for information and communications technology disaster recovery services Tento standard poskytuje návod na obnovu z krize v oblasti IT v kontextu BCM. Týká se oblastí informační bezpečnosti a aspektů dostupnosti IT v době krize. Implementací standardu organizace dosáhne větší pruţnosti své ICT infrastruktury podporující klíčové podnikové činnosti.



ISO/PAS 22399:2007 - Societal Security – Guideline for incident preparedness and operational continuity management První mezinárodně uznávaný standard týkající se připravenosti organizace a řízení kontinuity organizací jak ve veřejném, tak v soukromém sektoru. Tento dokument je zaloţen na best practices pěti národních standardů z Austrálie, Izraele, Japonska, Velké Británie a Spojených Států.



ISO/IEC 27002:2005 – Information Technology – Security techniques – Code of practice for information security management Tento standard slouţí jako doporučení informační bezpečnosti v několika oblastech. Kapitola 14 tohoto standardu se věnuje BCM a popisuje vztah mezi plánováním obnovy IT z krize, BCM a Business Continuity plánováním, a to v rozsahu od analýzy a dokumentace aţ po testování a školení plánů.

-11/117-



2 CHARAKTERISTIKA CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE Cloud Computing se začal v prostředí internetu objevovat aţ v druhé polovině poslední dekády, přesto si však našel širokou oblibu IT veřejnosti. Velmi rychle se stal často skloňovaným pojmem a setkáme se s ním i v prostředí sociálních sítí, kde např. v síti Twitter se na Cloud computing prostřednicvím článků odkazuje mnoho členů z řad odborné i „laické“ veřejnosti. Cílem této kapitoly je vymezit definici Cloud Computingu a uvědomit si jeho základní charakteristiky. Zvláštní pozornost je potom věnována také otázkám bezpečnosti a zabezpečení cloudových řešení. Definici Cloud Computingu by bylo moţné vybírat z celé řady zdrojů. Protoţe však tento termín je do jisté míry doposud sporný, znamená různé věci pro různé lidi a není zcela vymezeno, do jaké míry se jedná o „reklamní trik“ a do jaké míry lze tento pojem povaţovat za „něco nového“, neexistuje ţádný veřejně uznávaný orgán, který by poskytoval jedinou ověřenou definici. Zatímco někteří definují Cloud Computing úzce jako poskytování virtuálních serverů prostřednictvím internetu, jiní vidí Cloud Computing jako jakoukoli sluţbu poskytovanou mimo firewall společnosti. Pro účely vymezení pojmu v této diplomové práci byla pouţita následující definice: „Cloud Computing je: 1. Umístění a přístup k aplikacím a datům pomocí internetového prohlíţeče častěji, neţ pomocí softwaru instalovaného na koncové stanici nebo na serveru. 2. Na internetu zaloţené sdílení informací, IT zdrojů a softwarových aplikací, které je poskytováno koncovým stanicím a mobilním zařízením „na poţádání“. 3. Vyuţívání internetu pro přístup k webovým aplikacím, webovým sluţbám a IT infrastruktuře jako ke sluţbě.“ [CC2010] Na trhu Cloud Computingu se setkáme se jmény velkých hráčů jako je Amazon, Google či Microsoft, stejně tak jako na něm najdeme mnoho menších společností. Všichni tito poskytovatelé svorně nabízejí potenciálním zákazníkům sníţení nákladů a inovativní řešení. [Velte2010] Velkou otázkou však zůstává, které aplikace je vhodné do cloudu převádět a jak velká jsou s tím spojena bezpečnostní rizika. Pojem cloud je také moţné chápat v různých rovinách. Podle některých definic (např. [Com2010]) je cloud chápán jako síť, resp. internet, podle jiných autorů (např. [Info2010], [Wardley2010]) se pod pojmem cloud rozumí elastické prostředí zdrojů poskytující sluţby několika odběratelům na určité úrovni smluvené kvality. Rozeznáváme tři základní typy cloudů (viz Obr. 4) [Wood2009]:   

interní – soukromé cloudy provozované organizací samotnou, externí – sluţby jsou poskytovány třetí stranou prostřednictvím sítě internet. V případě externího cloudu zákazník musí často platit i za infrastrukturu, kterou nepouţívá, hybridní – kombinace interního a externího přístupu ke cloudu.

V některých společnostech jsou vyuţívány hybridní cloudy, ve kterých jsou sluţby poskytovány převáţně interně a externě poskytovaných sluţeb včetně infrastruktury je vyuţíváno pouze v případě, kdy kapacita interní infrastruktury není dostačující nebo v případě, kdy se jedná o běh méně rizikových sluţeb. Ostatní modely cloudu se teprve vyvíjejí a pomalu začínají být vyuţívány, včetně modelu vyuţívajícího infrastrukturu poskytovanou a udrţovanou externě, ale pouţívanou privátně jednou nebo několika malými společnostmi. Takový model je některými instituty (např. National Institute of -12/117-



Standards and Technology NIST v USA) či autory [Wood2009] [Prodelal2010] nazýván komunitním cloudem.

Hybridní cloud Interní cloud

Externí služba

Externí Cloud

Obr. 4 - Typy Cloud Computingu (Zdroj: Autor)

Vedle této klasifikace se lze setkat také se třemi hlavními modely, ve kterých jsou cloudové sluţby poskytovány. Tyto modely poskytování sluţeb jsou následující [Catteddu2009] [Rittinghouse2010]: 





Software as a Service (SaaS) – jedná se o software licencovaný třetí stranou, který je zákazníkovi dostupný v případě potřeby. Většinou jsou tyto sluţby poskytovány prostřednictvím sítě internet, neboť jsou snadno vzdáleně konfigurovatelné. Mezi příklady takto poskytovaných sluţeb patří software pro zpracování textu, tabulkový procesor (orig. spreadsheet), CRM a sluţby řízení webového obsahu (Salesforce CRM, Google Docs atd.). Podle společnosti Gartner [Potter2009] bude v roce 2010 poskytováno 30% nového software právě jako SaaS. Platform as a Service (PaaS) – umoţňuje zákazníkům vyvíjet nové aplikace za vyuţití API, které je umístěno a konfigurováno vzdáleně. Platforma nabízí vyuţití zabudovaných nástrojů pro vývoj aplikací (včetně návrhu a testování) či konfigurační management. Příklady poskytovatelů PaaS jsou: Microsoft Azure, Force a Google App. V některých případech je forma PaaS označována jako tzv. „cloudware“. Infrastructure as a Service (IaaS) – poskytuje virtuální prostor a ostatní hardware a operační systémy, které mohou být řízeny prostřednictvím API sluţeb. Mezi poskytovatele patří Amazon EC2 a S3 (Storage-as-a-Service), Terremark Enterprise Cloud, Windows Live Skydrive nebo Rackspace Cloud. Sluţba je ve většině případů účtována na základě mnoţství vyuţití zdrojů, a odráţí tak úroveň aktivity zákazníka.

S rostoucí úspěšností adopce konceptu SaaS zákazníky se objevila myšlenka nabízet tzv. IT-as-aService [Rittinghouse2010], coţ je koncept, který přenáší model sluţeb na vyšší úroveň, a to přímo do IT infrastruktury zákazníka. Moderní IT organizace by tak existovala jako samostatný celek a stala by se strategičtější v operativních rozhodnutích. Mnoho organizací v dnešní době převádí svá IT oddělení do samostatných center, která vystupují ve vztahu ke společnosti jako externí subjekt. To, jestli se koncept IT-as-a-Service stane budoucností také velkých organizací, ukáţe pouze čas. Nabízí však benefity, mezi které patří jak výhody finanční, tak výhody rozšiřitelnosti, flexibility či spolehlivosti a které jsou blíţe popsány v následující kapitole.

-13/117-



V dnešní době se také setkáme s pojmem konceptu Anything-as-a-Service (XaaS) ([Rittinghouse2010], [Karnam2010]), který je také jistou podmnoţinou Cloud Computingu a který zahrnuje vyuţívání znovupouţitelných softwarových komponent pomocí internetové sítě. Vzrůst zájmu o všechny koncepty typu "as-a-service" je dán především jejich vysokou dostupností, neboť registrační proces je limitován pouze vlastnictvím kreditní karty. I z tohoto důvodu byl koncept adoptován nejprve malými a středními podniky, u velkých společností se teprve pomalu hlásí o slovo. Přehled konceptu Cloud Computing tak, jak s ním bude pracováno v rámci této diplomové práce je znázorněn na Obr. 5 níţe. Jednotlivé kategorie konceptu Cloud Computing jsou popsány v následujícím textu.

Obr. 5 - Přehled konceptu Cloud Computing (Zdroj: Autor)

-14/117-



2.1 POTENCIÁL CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE I kdyţ Cloud Computing nabízí řadu výhod, o kterých se podrobněji zmíníme později, je důleţité si uvědomit, ţe ne všechny aplikace je vhodné do cloudu přesouvat. S rostoucím zájmem o Cloud Computing ze strany poskytovatelů roste i poptávka ze strany zákazníků, a tak často dochází k situacím, kdy se společnost rozhodne přesunout určitou aplikaci do cloudu, aniţ by předem zváţila soulad s celkovou strategií podniku a investiční návratnost projektu (ROI). Z průzkumu prováděného ve Spojených státech v březnu 2010 [Fogarty2010] vyplývá, ţe nejčastějším důvodem, proč se společnosti rozhodují pro adopci Cloud Computingu, je pruţnost běhu podnikových procesů (49% dotázaných), teprve na druhém místě bylo uváděno zvýšení účinnosti nákladů (46%) a na místě třetím uvolnění IT zdrojů za účelem zaměření se na inovaci (22%). Přitom běţným poţadavkem při přesunu aplikace do cloudu je její integrace s ostatními aplikacemi ve společnosti pouţívaných. Tato integrace můţe být natolik náročná, ţe předpokládaná úspora nákladů z přesunu do cloudu můţe být převýšena dodatečnými náklady na integraci aplikace. [Velte2010] uvádí, ţe k podobné situaci dochází také v případě, kdy je aplikace navázána na databázi, která je udrţována lokálně. V takovém případě je rovněţ lepší vést aplikaci interně do té doby, neţ je moţné přemístit do cloudu celou infrastrukturu včetně databáze. Základním rozhodovacím kritériem pro to, kterou aplikaci ponechat interně a kterou přesunout do cloudu, bývá povaha dat, která jsou v rámci aplikace udrţována. Podle některých odhadů (např. [Fogarty2010], [Velte2010]) obsahuje pouze ¼ podnikových aplikací kritická data nebo funkce, které by bylo vhodnější ponechat v rámci podniku, neboť některé aplikace nejsou schopny zabezpečené komunikace v rámci sítě Internet. Z hlediska přínosů Cloud Computingu pro tradiční způsoby udrţení Business Continuity či plánu obnovy můţeme jmenovat například sníţení pravděpodobnosti výpadku e-mailové sluţby v případě, kdy dojde k neočekávané události v rámci organizace. Posílání zpráv by bylo v tomto případě nadále umoţněno a doručení e-mailů adresátovi zaručeno. Mezi další výhody dle [Rittinghouse2010] patří také to, ţe potenciální výpadky systému mohou být pro společnost prakticky nepostřehnutelné nebo ţe společnost můţe nadále vyuţívat telekomunikačních sluţeb i během jejich výpadku či vyuţívat sluţeb bezdrátového připojení, a moci tak nadále odesílat a přijímat e-mailovou poštu i v případech, ţe lokální e-mailový systém, datové centrum, síť či zaměstnanci jsou nedostupní.

2.2 BENEFITY PLYNOUCÍ Z ADOPCE CLOUD COMPUTINGU Poskytovatelé Cloud Computingu, ať uţ se jedná o velké firmy typu Amazon, Google či Microsoft, nebo firmy malé, se shodují na následujících benefitech, které Cloud Computing společnostem přináší ([Marks2010], [Rittinghouse2010], [Velte2010]): 





Sníţení či optimalizace nákladů – Cloud Computing nabízí způsob, jak sníţit náklady na IT infrastrukturu, a to díky tomu, ţe umoţňuje společnosti vyhnout se některým kapitálovým nákladům, vyuţít lépe kapacitu a sníţit provozní náklady díky redukci interních IT zdrojů. Moţnost přístupu k podnikovým datům z několika lokalit - to je dáno základním principem Cloud Computingu, kdy jsou sluţby poskytovány zákazníkovi prostřednictvím internetu, a zaměstnanci se tak nemusí nacházet se v určité lokalitě, aby mohli přistupovat k podnikovým datům. Lepší vyuţití IT infrastruktury – díky moţnosti virtualizace IT zdrojů je moţné zlepšit vyuţití serverů, které v některých případech dosahuje pouze 10%, zatímco za vyuţití přístupů Cloud Computingu by toto vyuţití dosahovalo 50 – 65% nebo i více [Marks2010]. -15/117-

















Rozšiřitelnost IT infrastruktury – v případech, kdy v podniku vznikne náhlá potřeba rozšířit stávající IT infrastrukturu, můţe Cloud Computing pomoci urychlit proces „dodání“ IT zdroje, neboť namísto nákupu, instalace a konfigurace nového zařízení stačí pouze dokoupit dodatečnou operační paměť nebo úloţiště u poskytovatele. Lepší vyuţití aktiv – aktivy, která mohou být díky Cloud Computingu lépe vyuţívána, se rozumí lidé a znalosti. Primárním principem tohoto konceptu je outsourcing IT zdrojů, mezi které patří infrastruktura, middleware i aplikace, díky čemuţ společnost dosáhne uvolnění lidských zdrojů pro svůj vlastní business, ve kterém se specializuje. Uvolnění interních zdrojů – přesunem dat, která nejsou kritická pro naplňování podnikových cílů, do úloţiště třetí strany dosáhne podnik toho, ţe jeho IT oddělení bude mít více prostoru na řešení důleţitých a kritických úkolů, které přímo ovlivňují chod podniku. Mimoto podle [Velte2010] podnik také přesune část odpovědnosti za případný výpadek sítě na poskytovatele, coţ také sniţuje zatíţení interních zdrojů. Model platby pay-as-you-go – s výše uvedeným benefitem Cloud Computingu úzce souvisí i způsob platby za vyuţívané IT zdroje, neboť smyslem tohoto konceptu je pouţívat IT zdroje pouze v případě potřeby, tedy „on demand“, a na základě toho také za tyto zdroje platit. I kdyţ je tento model preferovaný dle [Rittinghouse2010] především ze strany uţivatele, některé nabídky Cloud Computingu vyuţívají model zaloţený na principu předplatného. Fixní náklady se stávají variabilními – vyuţitím pay-as-you-go modelu se z původně fixních nákladů na IT zdroje stávají náklady variabilní, neboť platby probíhají pouze na základě vyuţití zdrojů. Tento fakt významně ovlivňuje financování podniku, a je tak zajímavý nejen pro IT manaţery, ale také pro ostatní vedoucí pracovníky. Zkrácení doby uvedení na trh – díky potenciálu Cloud Computingu by společnosti mohly dosahovat výrazného zkrácení doby uvedení produktu na trh, coţ by mělo zásadní vliv na obchodní výsledky podniku. Podporu podniků začínajících a inovativních – díky konceptu vyuţívání IT infrastruktury pouze v případě potřeby je umoţněno také těmto typům podniků rychle nastartovat svůj model podnikání, a to na základě úspory na vstupních pořizovacích nákladech za IT zdroje.

2.3 HROZBY CLOUD COMPUTINGU Z HLEDISKA BEZPEČNOSTI Úvodem této kapitoly bychom měli uvést, ţe je důleţité si uvědomit, ţe Cloud Computing není jen uskupením výhod a benefitů, o kterých se lze dočíst v kaţdé broţurce cloudového poskytovatele, ale společně s výhodami skýtá v sobě vyuţití Cloud Computingu také jistá rizika. Ani na ta však není moţné pohlíţet jednostranně, je důleţité zváţit, zda rizika Cloud Computingu jsou pro firmu přijatelná ve srovnání s řešeními tradičními, zejména aplikacemi provozovanými na straně zákazníka, která také nejsou zcela bezriziková. Riziko bezpečnosti je s Cloud Computingem často spojováno, a to především s cloudy ve formě externí. Hlavním důvodem je obava, ţe pokud společnost umístí svá citlivá proprietární data do cloudu, není jiţ za jejich ochranu zodpovědná pouze vlastnická firma, ale také třetí strana, která poskytuje vyuţívané IT sluţby. Tato hrozba představuje na jedné straně zvýšené riziko hackerských útoků, na straně druhé dochází také k chybám způsobeným lidským faktorem. Jako příklad lze uvést incident z roku 2007, kdy britská vláda chybně umístila 25 milionů záznamů daňových poplatníků, které se tak staly přístupné třetí straně. [Velte2010] Bezpečnost cloudových sluţeb se v posledních letech stává samostatnou součástí počítačové bezpečnosti, síťového zabezpečení a v širším kontextu také informační bezpečnosti. Mezi cílové oblasti cloudové bezpečnosti patří odpovědnosti na straně poskytovatele (zabezpečení infrastruktury, -16/117-



dat a aplikací) a odpovědnosti na straně zákazníka (zákazník se musí ujistit, zda poskytovatel provedl opatření zabezpečující jeho data). Částečným řešením potenciálního rizika uchovávání citlivých dat v prostředcích třetí strany je vývoj vlastní aplikace, a to buď vlastními silami, nebo vývojem aplikace na míru. K podobné situaci dochází také v případě, kdy společnost hledá specifickou aplikaci, která není na trhu dostupná. Tyto aplikace a sluţby takto poskytované jsou zpravidla zaloţeny na tzv. LAMP konceptu, coţ je soubor relativně jednoduchých a výkonných technologií, které jsou však poskytovány ve formě open-source. Zkratka samotná vychází z jednotlivých částí konceptu uvedených níţe [Dougherty2001]:    

Linux – open-source operační systém Apache – open-source webový server MySQL – open-source relační databázový systém pro webové servery PHP – programovací jazyk

Z výše uvedeného je zřejmé, ţe aplikace zaloţené na LAMP jsou dostupnější alternativou k mnohým komerčním balíčkům. Problémem takovýchto řešení je však jejich rozšiřitelnost. Omezení vycházejí z počtu moţných vláken spojení k Apache serveru, maximální velikosti relačních tabulek v databázi MySQL apod. [Velte2010] Takováto omezení v Cloud Computingu neexistují, zjednodušeně se dá říci, ţe rozšíření znamená pouze dodání dalších a dalších serverů, čímţ dojde k rozšíření současné kapacity. Domény cloudové bezpečnosti můţeme rozdělit do několika kategorií. Zatímco Gartner [Brodkin2008] definuje 7 oblastí zájmu, Forrester [Wang2009] 3 oblasti a Cloud Security Alliance [CSA2009] 15 oblastí, můţeme tyto oblasti rozdělit na část bezpečnosti (do které spadají především otázky ochrany dat a bezpečnosti aplikací) a část souladu s podnikem, kam mimo jiné řadíme i Business Continuity. Následující text je podrobněji zaměřen na vybrané konkrétní hrozby cloudových sluţeb z oblasti soukromí a bezpečnosti.

2.3.1 ZNEUŽITÍ A NEZÁKONNÉ POUŽITÍ CLOUD COMPUTINGU Z průzkumu provedeného agenturou IDC [Velte2010], kdy bylo dotazováno 244 výkonných pracovníků IT, vyplývá, ţe 74,5% dotázaných je v otázce Cloud Computingu znepokojeno aspekty bezpečnosti. Teprve po otázkách bezpečnosti se na ţebříčku ukazuje výkonnost, dostupnost, moţnost integrace s ostatními aplikacemi, moţnost customizace, cena, regulace či nedostatek poskytovatelů Cloud Computingu na trhu. Grafické znázornění tohoto průzkumu je zobrazeno na Obr. 6. S rostoucím vývojem technologií roste i vynalézavost kriminálních ţivlů, kteří vyuţívají technologický pokrok ku svému prospěchu, a stávají se tak těţko odhalitelnými. Poskytovatelé Cloud Computingu se stávají častou obětí kybernetických útoků, a to částečně z důvodu povahy procesu registrace, která je anonymní, a ztěţuje tak schopnost poskytovatele vypátrat podvody. Proces registrace ve většině případů vyţaduje pouze vlastnictví platné platební karty, které postačuje k tomu, aby se registrující subjekt mohl stát uţivatelem sluţeb cloudu. Těmito útoky byli nejvíce postiţeni poskytovatelé platformy (PaaS), ale v poslední době se terčem útoků stávají také poskytovatelé infrastruktury (IaaS). V současné době jsou nejčastějšími útoky spamy či škodlivý kód, v budoucnosti se očekává prolamování hesel a klíčů, stejně tak jako další typy útoků. [CSA2010b]

-17/117-



Bezpečnost Výkonnost Dostupnost Integrace s in-house řešením Možnost customizace

Cena Náklady na přesun zpět do in-house

Regulace Nedostatek poskytovatelů 0

10

20

30

40

50

60

70

80

Obr. 6 - Pořadí obav z adopce Cloud Computing řešení (Zdroj: [Velte2010])

Na druhou stranu je však logické brát v úvahu také to, ţe řešení jako sluţba je mnohdy lépe zabezpečeno neţ řešení provozované na straně klienta. [Houser2010] Dodavatel takovýchto řešení totiţ ve vlastním zájmu udrţuje svá řešení v datovém centru, které je zabezpečeno jak fyzicky, tak virtuálně, a to na lepší úrovni, neţ si můţe dovolit běţná společnost.

2.3.2 OTÁZKY ZABEZPEČENÍ ROZHRANÍ I kdyţ se lze setkat s obecným tvrzením, ţe největší hrozbu pro data organizace představují její vlastní zaměstnanci, a proto předání dat neutrální třetí straně můţe toto riziko sniţovat, stále v této oblasti vyvstávají otázky, zda je rozhraní a poskytovaná API dostatečně zabezpečeno. Skutečností však je, ţe samotná rozhraní jsou na straně poskytovatele zabezpečena kvalitně, důleţité je ale také to, jak se k vyuţívání cloudových sluţeb postaví sám zákazník. [CSA2010b] Tyto bezpečnostní aspekty se týkají především zajištění, vyuţívání, řízení, orchestrace či monitorování odebíraných sluţeb. Zabezpečení rozhraní na straně poskytovatele můţe zahrnovat celou škálu bezpečnostních opatření, jako jsou autentizační procesy, řízení přístupu, šifrování nebo monitorování prováděných činností. Jak jiţ bylo uvedeno výše, je třeba mít na paměti, ţe rizika nejsou spojena pouze se škodlivými útoky subjektů zvenčí, ale také s neúmyslnými činy porušujícími politiku organizace. Do této kategorie bezpečnostních otázek také spadají podle [CSA2010b] nové aplikace, které jsou na existujícím rozhraní vybudovány, a to jak zákazníkem, tak třetí stranou. Zpravidla se jedná o nadstavby existujících aplikací, které dodávají potřebnou funkcionalitu vyţadovanou koncovými uţivateli či managementem společnosti.

2.3.3 SDÍLENÍ INFRASTRUKTURY S konceptem sdílení technologie, jako jsou například diskové prostory, operační paměť a další elementy, vyvstává otázka zvýšeného rizika útoků a přístupu k důvěrným datům jiným subjektem, neboť tyto elementy infrastruktury nejsou primárně pro dělení na části určeny. Samotní poskytovatelé Cloud Computing řešení nabízejí sluţby rozšiřitelným způsobem, coţ představuje sdílení infrastruktury s ostatními odběrateli. V mnoha případech nejsou komponenty tvořící sdílenou infrastrukturu (operační paměť, grafický procesor atd.) navrţeny tak, aby umoţňovaly oddělení v rámci sdílené architektury. Toho si jsou útočníci dobře vědomi a důsledkem toho je jejich zvýšený zájem o získání neoprávněného přístupu k datům. -18/117-



Pro překonání tohoto nedostatku zprostředkovává VMM přístup hostujícímu operačnímu systému k fyzické infrastruktuře. Tím se sniţuje pravděpodobnost útoku, neboť je obecně těţší získat přístup tímto způsobem neţ pomocí běţného operačního systému. [Catteddu2009] Mimoto na úrovni virtualizační vrstvy probíhá monitoring bezpečnostních událostí. I v tomto případě je však moţné, aby operační systém získal nepřiměřenou úroveň přístupu, a mohl tak ovlivňovat platformu, na níţ je postaven. [CSA2010b] Bezpečnostní opatření a monitoring by však měly tato rizika eliminovat.

2.3.4 ZTRÁTA NEBO ÚNIK DAT Ztráta dat je pochopitelně velkou hrozbou pro kaţdou společnost. Dá se říci, ţe v otázce, zda Cloud Computing řešení implementovat či nikoli, stojí za všemi ostatními aspekty rizik bezpečnostní povahy obava z úniku dat. Riziko ztráty kontroly nad daty je prohloubeno v případech, kdy se jedná o násobný přenos dat, např. mezi několika spojenými cloudy. Na druhou stranu však někteří poskytovatelé cloudových řešení poskytují také informace o tom, jakým způsobem s daty zákazníka nakládají. Někteří z nich podle [Catteddu2009] také nabízejí certifikaci zpracovávání dat a bezpečnostních činností, jakou je např. certifikace SAS70. Přitom tato hrozba nespočívá pouze v riziku, ţe by se k citlivým datům mohla dostat neoprávněná osoba. Způsobů, jak kompromitovat uţivatelská data, existuje pochopitelně několik. Nejběţnějším způsobem je vymazání dat nebo nahrazení dat původních bez předchozí zálohy. Dalšími příklady mohou být dle [CSA2010b] např. vymazání záznamu z širšího kontextu či ztráta šifrovacího klíče, které mohou ústit v neobnovitelnou ztrátu. Na druhou stranu Cloud Computing řešení můţe pomoci minimalizovat riziko pouţití nespolehlivého média, na kterém by data mohla být uchována. Díky diskovým kapacitám a zálohám prováděným poskytovatelem jsou data zákazníka z tohoto ohledu mnohdy ve větším bezpečí, neţ by byla v případě uloţení na straně zákazníka. Rizika ztráty nebo úniku dat často vyplývají z nedostatečného uvědomění zákazníka o bezpečnostním monitoringu, a to zejména monitorování autentizace, autorizace a účtování (AAA), kdy jsou na jednotlivých síťových prvcích monitorovány a zaznamenávány události potenciálně vedoucí k narušení bezpečnosti. Toto monitorování umoţňuje seskupovat jednotlivé události do incidentů a tyto incidenty následně na základě předem stanovených pravidel vyhodnocovat.

2.3.5 OCHRANA UŽIVATELSKÝCH ÚČTŮ Útoky prostřednictvím uţivatelských účtů zůstávají stále nejdůleţitější hrozbou, která se pohybuje na předních pozicích ţebříčku priorit kaţdé společnosti. Je totiţ zřejmé, ţe s odcizenými přihlašovacími údaji se můţe útočník v systému pohybovat takřka bez povšimnutí, čehoţ můţe vyuţívat k získání citlivých informací pod odcizenou identitou, sledování prováděných činností a transakcí či směrování na nelegitimní stránky. [CSA2010b] Společnosti by si měly techniky tohoto typu dobře uvědomovat a implementovat strategie obrany proti takovým útokům. Problémem zůstává skutečnost, ţe cloudové sluţby jsou hojně vyuţívány spíše menšími společnostmi, a to především z důvodu vysoké dostupnosti jak sluţeb, tak samotného registračního procesu, zatímco organizace většího typu cloudové sluţby doposud často nevyuţívají. Podle [Rittinghouse2010] většinou tyto malé společnosti postrádají dostatečnou bezpečnostní politiku, a proto se i z tohoto důvodu cloudové sluţby stávají častým terčem útoku. Co do odpovědi na útoky ze strany nejrůznějších škodlivých software bývá však cloudové řešení spíše výhodou, neboť společnosti poskytující sluţby jsou díky včasné detekci nového vývoje v oblasti škodlivého softwaru schopny implementovat efektivnější a účinnější prvky, jak se proti těmto útokům zabezpečit. [Catteddu2009] uvádí, ţe výhodou můţe být také to, ţe velcí poskytovatelé cloudových -19/117-



sluţeb si mohou dovolit mít v řadách pracovníků odborníky v nejrůznějších oblastech bezpečnosti, coţ u mnohých malých společností bohuţel není moţné.

2.4 ZRANITELNOSTI CLOUD COMPUTINGU Vedle rizik souvisejících s adopcí konceptu Cloud Computingu se setkáme také s nejrůznějšími případy zranitelnosti, které buď s Cloud Computingem přímo souvisejí nebo se jedná o obecné zranitelnosti z hlediska informační bezpečnosti. V následujícím textu jsou v obrysech načrtnuty některé z nich [Catteddu2009]: 











Zranitelnost AAA – tím je myšlen nedostatečný způsob autentizace, autorizace a účtování na prostředcích v síti (servery, switche, routery apod.), který by mohl potenciálně umoţnit neautorizovaný přístup pomocí: o nezabezpečeného úloţiště přihlašovacích údajů pro sluţby cloudu, o nedostatečného počtu uţivatelských rolí, o přihlašovacích údajů uloţených na přechodném zařízení. Zranitelnost procesu získávání zákazníků – jak jiţ bylo řečeno výše, proces registrace pro vyuţívání cloudových sluţeb je velmi přístupný takřka bez ţádných omezení, avšak do jisté míry nebezpečný. A to především z následujících důvodů: o zákazník nemá kontrolu nad procesem získávání dalších zákazníků, o identita zákazníka není při registraci náleţitě ověřována, o jsou vytvářeny nesynchronizované kopie identifikačních dat uţivatele. Pozbytí izolace zdrojů – díky sdílení zdrojů mezi několika zákazníky je moţné, ţe pouţití zdroje jedním zákazníkem můţe ovlivnit zdroj druhého zákazníka: o IaaS cloudové infrastruktury většinou závisí na návrhu architektury, kde jsou fyzické zdroje sdíleny několika virtuálními stroji, a tedy i několika zákazníky, o zranitelnost na úrovni bezpečnosti virtuálního stroje můţe vést k neautorizovanému přístupu ke sdíleným zdrojům. Nemoţnost zpracovávat data v šifrované podobě – zašifrovat data v úloţišti nepatří k obtíţným záleţitostem, avšak navzdory nedávnému vývoji v homomorfním šifrování se nepředpokládá, ţe by bylo moţné data v šifrované podobě také zpracovávat. Podle [Cooney2009] bylo však odhadnuto, ţe v případě pouţití šifrovaných klíčových slov při vyhledávání ve vyhledávači Google by byl potřebný čas zpracování násoben trilionkrát. Autor [Schneier2009] k tomuto faktu uvádí, ţe podle Mooreova zákona bude trvat dalších 40 let, neţ se vyhledávání pomocí šifrovaných klíčových slov stane stejně efektivní jako současné vyhledávání. Nepřesné modelování pouţitých zdrojů – ačkoli většina poskytovatelů zákazníkům umoţňuje rezervovat pro sebe potřebné zdroje, algoritmus přidělování zdrojů můţe snadno selhat z následujících důvodů: o nepřesné modelování vyuţití zdrojů, které můţe vést k přečerpání či nedostatku zdrojů. Mezi nejznámější algoritmy přiřazování zdrojů patří Token Bucket, Fair Queuing a Class-Based Queuing. [Catteddu2009] o selhání algoritmu z důvodu neočekávaných událostí nebo z důvodu nepřesné klasifikace přiřazovaných zdrojů. Mezi zranitelnosti, které nejsou typické pouze pro Cloud Computing patří mimo jiné také nedostatek povědomí o bezpečnostních aspektech nebo nejasně definované role a odpovědnosti. Ačkoli tyto zranitelnosti nejsou spojeny pouze s vyuţíváním cloudových sluţeb, měly by být pečlivě zváţeny před rozhodnutím vyuţívat řešení Cloud Computingu. -20/117-



2.5 IDENTITY & ACCESS MANAGEMENT VE VAZBĚ NA CLOUD COMPUTING Identity & Access Management (dále IAM) patří dnes mezi největší výzvy, kterým musí IT čelit. Ačkoli je moţné, aby společnost začala vyuţívat cloudových sluţeb bez implementace systému pro řízení přístupů, z dlouhodobého hlediska je nutné tuto strategii do cloudových sluţeb zahrnout. Příchod cloudových sluţeb zcela změnil podstatu řízení identit. Doposud byla řešení pro řízení identity navrţena pro řízené a statické prostředí uvnitř společnosti. Dle [Rittinghouse2010] v rámci cloudu nyní jiţ nepostačí řízení identit orientované na uţivatele, ale poskytovatelé cloudových sluţeb jsou nuceni zhodnotit nové modely a řídící procesy IAM tak, aby poskytovali důvěru zákazníkům napříč cloudem a také v organizaci samotné. Následujícím text je zaměřen především na základní funkce IAM:    

nabytí/pozbytí identity, autentizace, autorizace a správa uţivatelských účtů, podpora souladu.

Rychlý vývoj konceptu SaaS předstihl vývoj standardů. Např. standard SPML (Service Provisioning Markup Language), coţ je rámec zaloţený na XML pro výměnu informací o uţivatelích, zdrojích či sluţbách mezi organizacemi, nebyl jiţ 3 – 4 roky aktualizován. [CSA2010a] Mezitím však s rychlým vývojem konceptů SaaS vzniklo několik odlišných způsobů, jak získávat a spravovat uţivatelské účty. V mnoha případech proto poskytovatelé cloudových řešení zvolili raději variantu neinvestovat do vývoje dále, dokud se neobjeví přesně definované standardy tuto problematiku upravující. Uţivatelé cloudových sluţeb by podle [CSA2010a] měli pro naplnění poţadavků na získávání uţivatelských účtů upravit nebo rozšířit svá autoritativní úloţiště dat tak, aby zahrnuli své aplikace a procesy do cloudu. Autentizace uţivatel je další výzvou pro organizace, které se rozhodnou vyuţívat cloudových sluţeb. Autentizace probíhá prostřednictvím přihlašovacích údajů, digitálních podpisových certifikátů apod. Zejména společnosti, které vyuţívají k autentizaci především přihlašovací jméno a heslo by měly zváţit následující aspekty:  

 

hesla by měla být chráněna a komunikace by měla být zabezpečena, je-li pro více sluţeb v rámci jednoho cloudu pouţíváno jedno heslo, je velmi pravděpodobné, ţe v případě útoku a prolomení hesla získá útočník přístup do několika cloudových sluţeb zároveň, hesla by měla dodrţovat základní pravidla pro sestavení hesel, aby nebyla snadno prolomitelná slovníkovou metodou, vyuţívané sluţby jsou vystaveny hrozbě phishingu.

Z těchto a dalších uvedených důvodů je dobré zváţit, zda určitá aplikace nevyţaduje silnější autentizační mechanismy, kterými jsou například jednorázová hesla (One-time password - OTP) zaslaná např. na e-mailovou adresu nebo mobilní telefon nebo digitální podpisové a šifrovací certifikáty. Silnější způsoby autentizace jsou dnes jiţ častěji vyuţívány především většími společnostmi (např. u bankovních institucí je silná autentizace uţivatel nezbytností), problémem však zůstává skutečnost, ţe daná metoda autentizace nemusí být kompatibilní s řešením poskytovatele cloudových sluţeb. Řízení přístupu a správa uţivatelských účtů/profilů je náročnější v rámci cloudu, neboť informační zdroje mohou být umístěny na jiném místě neţ je umístěna samotná sluţba, která je vyuţívá. Pro tyto účely je důleţité identifikovat důvěryhodný zdroj a zabezpečenou komunikaci, pomocí které mohou -21/117-



být informace do cloudu přenášeny. Pro zákazníka je důleţité, aby cloud byl schopen zajistit následující funkcionalitu [CSA2010a]:   



 

řízení přístupu na základě politiky stanovené zákazníkem, řízení přístupu k datům jednotlivých uţivatelů a zajištění jejich oddělení od ostatních zákazníků v prostředí sdíleném více uţivateli, udrţovat uţivatelské informace a dodrţovat politiku řízení přístupu; v některých případech je také vyţadováno, aby řešení uţivatelům umoţňovalo specifikovat externí entity, se kterými by měla být sdílena uţivatelská data, poskytnout dodatečné notifikace o vytvořených/smazaných účtech a přidělených právech tak, aby bylo zabráněno vzniku podvodných účtů nebo účtů s vyšší úrovní oprávnění, neţ jaká je skutečně potřeba, poskytnout auditní logy činnosti v rámci prostředí jednotlivého zákazníka, a to včetně řízení identit, poskytnout prostředky pro určení odpovědnosti v případě problémů, které mohou nastat.

V současné době neexistuje ţádný standard, který by definoval podobu auditních logů, a tak musí poskytovatel sluţeb a zákazník společně pracovat na definování podoby konkrétního záznamu pro dané účely, na zabezpečení důvěrnosti, integrity a dostupnosti této informace. V případě cloudových sluţeb je samozřejmě opět nezbytné zajistit, aby přístup jednoho zákazníka k logům neposkytoval informace také o jiném zákazníkovi.

2.6 NÁVRH BEZPEČNOSTNÍCH OPATŘENÍ PRO ADOPCI CLOUD COMPUTINGU SaaS v dnešní době neposkytuje dostatečně velkou podporu řízení identit. Dá se však očekávat, ţe s rostoucím zájmem o SaaS, IaaS a PaaS se zvýší adopce standardů umoţňujících snazší řízení uţivatelských profilů, o kterých se zmíníme v této podkapitole. Existuje několik modelů pro řízení přístupu. V zásadě však platí, ţe model řízení přístupu, který vyhovuje podmínkám společnosti v prostředí mimo cloud, bude také vhodný pro vyuţití v rámci cloudu. Pro sluţby zpracování transakcí je často vyuţíván model RBAC (Role Based Access Control), coţ je koncept omezení přístupu do systému pouze autorizovaným uţivatelům. Podle [CSA2010a] bývá tento model často doplňován o další principy, mezi které patří například striktní oddělení kořenového uţivatele od ostatních uţivatelů, a zabránění tak existenci uţivatelských účtů s většími pravomocemi, neţ které jsou ve skutečnosti potřebné, nebo také bývá doplněn o politiky oddělení dat, jako jsou SQL pohledy implementované na úrovni databáze. Autentizace, která probíhá prostřednictvím tzv. single sign-on (SSO), můţe být dvojího druhu. Prvním typem je SSO zaměřené na uţivatele. Takovým modelem je například OpenID, které umoţňuje uţivatelům vybrat si způsob autentizace. Tento model je vhodný v případech, kdy je v rámci řízení přístupů akceptovatelné, aby uţivatel vystupoval pod svým pseudonymem. V jiných případech však tato autentizace nestačí a politikou řízení přístupů je vyţadováno, aby bylo vţdy ověřeno, kým uţivatel skutečně je. V takových situacích je moţné vyuţít modely SSO, jako je například SAML, který umoţňuje poskytovateli cloudového řešení nebo zákazníkovi zvolit povolené způsoby autentizace, čímţ je zajištěna vyšší kvalita bezpečnosti v řízení přístupů. SAML je zaloţen na několika existujících standardech, jako je SOAP, HTTP nebo XML a jak ve verzi 1.1, tak ve verzi 2.0 vyuţívá digitálního podpisu pro autentizaci a udrţení integrity zpráv. V pozdější verzi standardu SAML je umoţněno také XML šifrování. [Rittinghouse2010] Jsou-li cloudové sluţby vyuţívány společnostmi, je pravděpodobné, ţe politika řízení přístupu bude specifikována a uloţena na jednom místě (u zákazníka), zatímco bude přenášena na místo druhé (k -22/117-



poskytovateli). Jestliţe by si kaţdý poskytovatel cloudového řešení a kaţdý zákazník specifikoval jiný formát představující informace o politice řízení přístupů, vznikla by neudrţitelná situace vedoucí k potenciálnímu selhání. Proto existuje i v tomto případě standard eXtensible Access Control Markup Language (XACML), který reprezentuje formát politiky řízení přístupů. [CSA2010a] V konečném důsledku pak společnost můţe vyuţívat SAML single sign-on pro autentizaci uţivatel, zatímco cloudová sluţba bude schopna přijmout informace o politice ve formátu SAML dle XACML a pro přenos dat bude pouţit standard SPML. Dle [CSA2010a] není v současné době ještě standard SPML natolik rozšířen, avšak s rostoucím zájmem o vyuţívání cloudových sluţeb ze strany velkých organizací poroste v budoucnu také vyuţití tohoto standardu.

-23/117-



3 VAZBA CLOUD COMPUTINGU NA BUSINESS CONTINUITY MANAGEMENT V této kapitole jsou nastíněny základní oblasti, ve kterých se koncepty Business Continuity Management a Cloud Computing prolínají a ve kterých se doplňují. Protoţe zaměřením této práce jsou z pohledu podnikové kontinuity především IT sluţby, je i tato kapitola pojata z pohledu moţností, které přináší Cloud Computing pro kontinuitu zejména těchto sluţeb. Nejprve jsou v této kapitole popsány oblasti, ve kterých Cloud Computing přináší nové moţnosti pro plánování Business Continuity. Na základě tohoto textu je poté určen předpoklad pro vyuţití Cloud Computing řešení pro zlepšení Business Continuity. Kapitolu uzavírá výčet poţadavků, které klade BCM na Cloud Computing řešení a které je potřeba z hlediska podnikové kontinuity naplnit.

3.1 CO CLOUD COMPUTING SPOLEČNOSTEM PŘINÁŠÍ PRO JEJICH BUSINESS CONTINUITY Plán Business Continuity byl dle [Clarke2009] ve světě businessu dlouho chápán jako něco, co je finančně nákladné a co si mohou dovolit pouze velké korporace. A právě z tohoto hlediska můţe dnešním podnikům pomoci Cloud Computing. Díky vyuţívání tohoto konceptu můţe mít prakticky kaţdá firma alespoň základní koncepci plánu kontinuity v případě, ţe by podnik postihla jakákoli narušující událost. Základní myšlenkou sestavení plánu podnikové kontinuity je vytipování klíčových procesů, které jsou pro společnost zásadní a kterými se s největší pravděpodobností odlišují od svých konkurentů. Obdobný předpoklad platí pro IT systémy, které proces podporují. Je logické, ţe IT systémy, které podporují klíčový podnikový proces, budou pravděpodobně klasifikovány rovněţ jako klíčové. Problém spočívá v tom, ţe se obecně příliš nedoporučuje do cloudu přesouvat ty sluţby/procesy/systémy, které podnik zásadním způsobem odlišují od konkurence. Na druhou stranu by však bylo pošetilé očekávat, ţe všechny systémy, které klíčový proces podporují, budou klíčové natolik, aby do cloudu nemohly být přesunuty. Záleţí proto na konkrétní situaci a je na společnosti, aby zváţila, které aplikace, informační systémy nebo celé servery přesunula do cloudu. Na základě výše uvedených informací by se dalo usoudit, ţe Cloud Computing nepředstavuje pro Business Continuity ţádný potenciál jednoduše proto, ţe přesunutí klíčových systémů do cloudu nese příliš velké riziko. V následujícím textu je uveden krátký příklad argumentující pro opak. V situaci, kdy by budovu společnosti zachvátil poţár, by se ocitla bez dodávky elektrické energie, neboť ta by byla přerušena. Chod společnosti by byl váţně ohroţen a v budově by vypukl chaos. Vedení společnosti by nemohlo svým zaměstnancům dát rychle vědět, co se děje a co by měli dělat. I přes veškerá evakuační cvičení by lidé panikařili a nemohli by se dostat ke svým emailovým účtům, kde by mohli nalézt uţitečné informace. A to i přes to, ţe by vlastnili mobilní zařízení, které by se k emailovému serveru připojit dokázalo. Kdyby se však společnost předtím rozhodla přesunout své emailové sluţby do cloudu, zaměstnanci by mohli např. díky wifi spotům dosáhnout svou emailovou schránku, coţ by mohlo napomoci zvládnutí situace a sníţení chaosu.

3.1.1 CLOUD COMPUTING JAKO VÝCHODISKO Z KRIZE Cloud Computing řešení je moţné chápat a vyuţívat jako řešení vypořádání se s narušujícími událostmi nebo dokonce jako východisko z krize. Existuje několik modelů, kterými lze vyuţívat Cloud Computing sluţby ve smyslu naplnění poţadavků kontinuity podniku: 

Cloudové sluţby vyuţívané jako primární zdroj. Tím se rozumí situace, kdy společnost přesunula do cloudu své procesy a aplikace, které jsou tak provozovány pouze na straně poskytovatele, např.: -24/117-



vyuţívání sluţeb emailového serveru umístěného u poskytovatele, čímţ je zajištěna kontinuita podniku v případě, kdy hlavní budovu zasáhne neočekávaná událost, o vyuţívání infrastruktury umístěné u poskytovatele, jako jsou servery či datová centra. Tím je zajištěn přístup k datům nezávisle na situaci, která nastane. Cloud Computingu je vyuţíváno pouze v případě, kdy nastane narušující událost. V takovém případě zákazník svá data a aplikace primárně provozuje v in-house řešení. Data však automaticky replikuje do úloţiště u poskytovatele, a to na základě předem stanovených intervalů. V případě, kdy nastane narušující událost, společnost pouze přejde z in-house řešení na řešení cloudové a své uţivatele jednoduše přesměruje na novou adresu. o



Doba přesměrování je závislá na čase, který je potřeba vynaloţit na zajištění/spuštění virtuálního serveru a případném transferu dat nebo jejich dešifrování. V případě pouţití replikace je čas kratší, a doba potřebná k přesměrování je tak výrazně niţší. Výhody tohoto řešení jsou přímočaré [Pyle2010]: -

replikace dat probíhá automaticky, organizace nemusí vynakládat dodatečné náklady na zajištění plánu pro obnovení z krize, společnost není nucena dokupovat dodatečný hardware ani software, společnost je ušetřena dodatečných nákladů na mirroring (přesný obraz) svého datového centra.

Po pominutí hrozby jsou v tomto případě aktualizovaná data v cloudovém řešení replikována zpět do in-house řešení, a business se tak můţe navrátit ke své běţné činnosti. 



Přednastavené instance pouţívané v případě krize. V rámci tohoto modelu společnost vyuţívá přednastavených serverových instancí, které jsou provozovány na straně poskytovatele. V případě krize na primární lokaci společnosti jsou systémy předány do cloudu a instance se stává primárním zdrojem dat. To můţe být podle [Opsview2010] provedeno jak manuálně, tak také automaticky pomocí specializovaných nástrojů. Aktivní - aktivní. Tento model zjednodušeně znamená, ţe systémy jsou provozovány jak na straně poskytovatele, tak na straně zákazníka. Jedná se o představitele hybridního cloudu (viz kapitola 2.1). Od předchozího modelu se tolik neliší, ale je zde obvykle více komplexnosti z důvodu synchronizace dat, výpadek během sezení apod.

Z předchozího textu je patrné, ţe společnost si můţe vybrat, kterou cestou se preferuje vydat, aby naplnila poţadavky nejen na Business Continuity, ale také poţadavky managementu v otázkách řešení přesunu klíčových dat a aplikací do cloudu.

3.1.2 JAK MŮŽE CLOUD COMPUTING POMOCI ZAJISTIT BUSINESS CONTINUITY Správným pouţitím cloudových sluţeb můţe společnost tohoto konceptu vyuţít při sestavování svého plánu podnikové kontinuity, a to zejména v následujících oblastech [Opsview2010]: 

Lidé a budovy - v dnešní době se rozšiřuje trend práce z domova, kdy zaměstnanci preferují zůstat doma během pracovní doby a svou práci odvádět vzdáleně. To je umoţněno především díky vysokému pokrytí širokopásmového připojení k internetu. Díky distribuované pracovní síle a cloudovým sluţbám je pak snazší udrţet kontinuitu společnosti v případě vzniku narušující události. Pro tuto oblast platí také skutečnost, ţe v případě selhání stávajícího připojení k internetu mohou zaměstnanci vyuţít jiných forem připojení, ať uţ pomocí wifi spotů nebo pomocí svého mobilního zařízení. -25/117-





Technologie - koncept Infrastructure-as-a-Service je velmi přesvědčivým konceptem pro zajištění strategie podnikové kontinuity pro data centra, a to za vyuţití některého z modelů představených výše. Mimoto lze do této oblasti zařadit také technologii VoIP (Voice over IP), která se v posledních několika letech rozšiřuje a která by díky svému potenciálu mohla poskytnout dostatečnou kapacitu pro telekomunikační účely v rámci malého nebo středního podniku.



Informace - vyuţití cloudových sluţeb v této oblasti je zřejmé. Společnost vyuţívá cloudových sluţeb k uloţení aktuálních dat, a to za předpokladu zachování jejich důvěrnosti a udrţení jejich vysoké dostupnosti v případě potřeby. Je však důleţité zváţit, zda poskytovatel cloudových řešení můţe citlivá data uchovávat, a to z důvodu geografického umístění či právní regulace. Opomenuta by neměla být ani integrita dat, a to především v komplexních prostředích. Integrita dat se týká především přístupu, kdy jsou cloudové sluţby vyuţívány pouze jako záloha.

Při zvaţování vhodného modelu vyuţití cloudových sluţeb je proto nutné zohlednit mimo jiné také dopad Cloud Computingu na všechny tyto tři výše zmíněné oblasti aktiv.

3.1.3 PRAVIDLA ADOPCE CLOUD COMPUTINGU JAKO NÁSTROJE BUSINESS CONTINUITY I kdyţ Cloud Computing přináší společnostem bez pochyby řadu zajímavých benefitů, nelze opomíjet ani rizika, která musí být vzata v úvahu a musí být řízena. Mezi tato rizika patří bezpečnost, soulad s podnikovou architekturou, soukromí a další provozní rizika související s hladkým chodem podniku. Následující body podrobněji popisují oblasti, na které je nutné se zaměřit za účelem úspěšné implementace Cloud Computing řešení jako nástroje pro Business Continuity [Vellante2010]: 









S rostoucím zájmem o virtualizaci a Cloud Computing roste také poptávka po odbornících na Business Continuity. To je dáno především tím, ţe tradiční Business Continuity a řízení rizik má přehled o technologickém portfoliu celé společnosti, a můţe tak zajistit komplexní pohled na podnik, který je nedocenitelným poţadavkem cloudových iniciativ. Společnosti, které se vydaly cestou virtualizace a Cloud Computingu, musí zajistit soulad cloudových iniciativ s tradičními metrikami a disciplínami Business Continuity, mezi které patří řízení rizik či governance. Před adopcí virtualizace a Cloud Computingu je důleţité sestavit celkovou strategii a z pohledu procesů obnovení z krize a podnikové kontinuity stanovit cíl zajištění pruţnosti. Tato pruţnost by měla být základní součástí podnikových operací. Klíčovou odpovědností v rámci sestavování strategie je vytvoření povědomí jak o příleţitostech, tak o rizicích. Společnosti, které chtějí konceptu virtualizace a Cloud Computingu vyuţít v hlubším slova smyslu a zapojit je do běţného chodu organizace, by měly začít s dozorem nad procesem ohodnocení rizik a identifikace metrik, které jsou pro organizaci důleţité. Dodavatelé, kteří chtějí svým zákazníkům poskytovat sluţby krizového řízení a Business Continuity, by měli porozumět skutečnosti, ţe nabízet jedno řešení všem zákazníkům není moţné. Odlišnosti jako velikost společnosti, odvětví podnikání nebo klíčové priority jsou natolik odlišujícím faktorem, který vyţaduje podrobnější analýzu a ohodnocení řešení vhodného pro konkrétní situaci.

-26/117-



3.2 PŘEPOKLAD PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM Pro to, aby mohl být Cloud Computing ve společnosti úspěšně pouţit pro řízení její kontinuity, je zapotřebí, aby tento koncept splňoval předpoklad řízení rizik. Bliţší upřesnění tohoto předpokladu je popsáno v následující podkapitole.

3.2.1 ŘÍZENÍ RIZIK Výstupem účinného řízení rizik by měla být identifikace technologických aktiv, identifikace dat a jejich vazby na podnikové procesy, aplikace, úloţiště dat apod. Vedle identifikace by podle [Rittinghouse2010] mělo být výstupem také určení odpovědnosti za správu těchto aktiv. Formální proces ohodnocení rizik by měl alokovat bezpečnostní zdroje navázané na podnikovou kontinuitu. Ohodnocení rizik je klíčové pro rozhodování v otázkách prioritizace mezi uţitkem společnosti a ochranou aktiv. Nedostatek pozornosti věnované ohodnocení rizik vede k nárůstu auditních nálezů týkajících se informační bezpečnosti, ohrození certifikačních cílů a můţe vést aţ k neúčinnému výběru bezpečnostních opatření, která nejsou schopna sníţit rizika informační bezpečnosti na přijatelnou úroveň. Detailnější ohodnocení rizik, a to především na technické úrovni za vyuţití metody modelování hrozeb, by mělo být pouţito jak v případě aplikací, tak infrastruktury. V návaznosti na toto ohodnocení je umoţněno týmům vyvíjející produkty úzce spolupracovat s interním týmem bezpečnosti, a účinně tak testovat aplikace na definované hrozby [Rittinghouse2010]. Modelování hrozeb vyţaduje znalost jak IT procesů, tak procesů podnikových, a to ve spojení s technologickými znalostmi o fungování aplikací a systémů podporujícími běţící procesy. Společně s tím, jak byl model Software-as-a-Service postupně přesunut do cloudu, vznikl také předpoklad, ţe rizika spojená s informační bezpečností budou řešena na straně poskytovatele sluţeb. Tento předpoklad vznikl na základě jednoduché skutečnosti, totiţ ţe poskytovatel sluţeb si nemůţe dovolit vzbudit negativní zájem způsobený narušením bezpečnosti sluţeb na jeho straně. Taková situace by ho stála ztrátu pověsti a dobrého jména, coţ by pro něj znamenalo postupnou ztrátu důvěry zákazníků, hrozbu právních dopadů a potenciálně konec jeho podnikání. Druhým pramenem tohoto předpokladu je také skutečnost, ţe dodavatel se specializuje na poskytování sluţeb, a proto je jedním z jeho hlavních zaměření také soustředit se na bezpečnost. K zajištění zabezpečení má zpravidla více technologických prostředků a lidských zdrojů neţ většina firem sluţby odebírajících.

3.3 POŽADAVKY BCM NA CLOUD COMPUTING Z charakteristiky obou konceptů (viz kapitoly 1 a 2) vychází následující text této kapitoly, který je zaměřen na tři nejdůleţitější poţadavky z pohledu Business Continuity. Pro přehlednost jsou tyto poţadavky označeny P01 – P03. Poţadavky konceptu Business Continuity Management, které jsou kladeny na řešení Cloud Computingu, lze zařadit do tří jim nadřazených kategorií: A. Bezpečnost B. Disaster recovery C. Service Level Agreement Tyto kategorie byly zvoleny pro lepší přehlednost a následnou klasifikaci jednotlivých poţadavků. Zatímco první kategorie se týká technického zajištění bezpečnosti uloţených dat a provozovaných aplikací, druhá kategorie specifikuje strategii pro obnovení po havárii a třetí kategorie zahrnuje otázky smluvního zajištění poskytování/odebírání sluţeb. -27/117-



V Tab. 1 je uvedena přehledná klasifikace identifikovaných poţadavků, které by mělo naplnit kaţdé řešení Cloud Computingu pro to, aby společnost dosahovala větší pruţnosti v oblasti Business Continuity: Kategorie

Název poţadavku

A. Bezpečnost

P01 Bezpečnost a monitoring

B. Disaster recovery

P02 Zálohování a archivace

C. Service Level Agreement

P03 Dostupnost sluţeb

Tab. 1 - Kategorizace poţadavků BCM na Cloud Computing řešení (Zdroj: Autor)

V následujícím textu jsou tyto poţadavky detailněji popsány.

3.4 KATEGORIE A - BEZPEČNOST Jednotlivá cloudová řešení se co do naplnění kritérií bezpečnosti a monitoringu výrazně liší, a to ve všech modelech poskytování sluţeb, ať uţ se jedná o software, platformu nebo infrastrukturu. Téměř všichni poskytovatelé nabízejí zabezpečení nabízených sluţeb. Jiţ menší počet poskytovatelů se zmiňuje o standardech bezpečnosti, které jsou dodrţovány a ještě niţší počet poskytuje informace zvlášť o zabezpečení a zvlášť o bezpečnostním monitoringu. V některých případech jsou sluţby zabezpečení a monitoringu nabízeny partnerskou společností poskytovatele sluţby. V takovém případě je třeba zváţit, zda je pro společnost vhodné, ţe do vztahu přibude další strana, i kdyţ sama společnost s ní nebude v ţádném přímém vztahu, nebo zda je naopak ţádoucí, aby se o zabezpečení a bezpečnostní monitoring starala specializovaná firma.

3.4.1 P01 BEZPEČNOST A MONITORING V rámci návrhu bezpečnostních opatření by měly být zahrnuty jak metody technologie a návrhu, tak bezpečnostní procesy potřebné k zajištění následujících sluţeb napříč všemi technologickými vrstvami [Rittinghouse2010]:       

autentizace, autorizace, dostupnost, důvěrnost, integrita, odpovědnost, soukromí.

Vedle těchto sluţeb nabízí cloudové řešení také moţnost monitoringu událostí, které se nějakým způsobem vztahují k bezpečnosti. Ne kaţdá společnost si můţe dovolit provozovat vlastní bezpečnostní monitoring, a to jak z důvodu nedostatku technických prostředků, tak z nedostatku zkušeného personálu. Podstata bezpečnostního monitoringu spočívá v tom, ţe jsou monitorovány komponenty infrastruktury, na kterých jsou umístěna citlivá data. Například v případě finanční instituce to mohou být servery, kde jsou umístěna data o finančních trzích. Na těchto komponentách jsou monitorovány události, které nějakým způsobem souvisí s bezpečností systému. Takovou událostí můţe být například opakované neúspěšné přihlášení uţivatele, neúspěšná autorizace uţivatele, změna nastavení monitorovaného systému apod. -28/117-



Tyto události jsou následně ze všech monitorovaných systémů různými metodami přenášeny na jedno místo, kde jsou dále vyhodnocovány. Jednotlivým událostem je přiřazována jejich závaţnost. Díky prostředkům monitorování je potom moţné na základě jedné nebo několika bezpečnostních událostí vytvořit incident, který je potřeba řešit, a je proto přiřazen řešiteli. V prostředí Cloud Computingu je potom moţné, aby se o bezpečnostní monitoring staral poskytovatel sluţby. Výčet bezpečnostních událostí, které je potřeba monitorovat, je společným výstupem jednání poskytovatele a odběratele. Při výskytu některé bezpečnostní události nebo sady bezpečnostních událostí je pak moţné definovat určité akce, například zaslání emailu o výskytu incidentu. Díky takové emailové notifikaci je potom zákazník vţdy informován o aktuální bezpečnostní situaci odehrávající se nad jeho systémy. Bezpečnost aplikací je stále odpovědností společnosti i přesto, ţe je přesune do cloudu. Bezpečnost dat a infrastruktury, na kterých tyto aplikace běţí, je však odpovědností poskytovatele. Lze předpokládat, ţe poskytovatel cloudových sluţeb disponuje aktuálnějšími prostředky ochrany systémů a infrastruktury před kybernetickými útoky neţ je v moţnostech odběratele. To je dáno jak specializací poskytovatele na zajištění bezpečnostních aspektů, tak i tím, ţe poskytovatel si zpravidla můţe dovolit zaměstnat odborníky v oboru bezpečnosti. Postupem času navíc poskytovatelé cloudových řešení získávají také uznávané certifikace jako například SAS70, coţ je široce uznávaný standard pro provádění kontroly účtů (auditing) vydaný americkým institutem AICPA (American Institute of Certified Public Accountants). Také [Hapl2010] uvádí, ţe potenciálně slabším článkem bohuţel zůstávají aplikace na cloudu provozované, kde záleţí na tom, zda se jedná o cloud veřejný, privátní či hybridní.

3.4.2 DŮVĚRNOST INFORMACÍ Zajištění důvěrnosti informací je aspektem, který by měl být upraven v rámci Service Level Agreement. Přesunutí kritických aplikací a citlivých dat do veřejného cloudu vzbuzuje u společností nemalý zájem. Je povinností poskytovatele cloudových sluţeb zajistit, aby data po přesunu do cloudu měla stejné zabezpečení a stejnou úroveň důvěrnosti jako měla před přesunutím. Zajištění bezpečnosti a důvěrnosti dat je důleţité hned z několika důvodů [Rittinghouse2010]:   

společnost odebírající sluţby potřebuje svým zákazníkům poskytnout spolehlivé sluţby tak, aby neztratila jejich důvěru, společnost potřebuje pomocí těchto sluţeb naplnit své Service Level Agreements, které má uzavřené se svými zákazníky či odběrateli, společnost musí být schopna obstát před pravidelnými audity.

3.5 KATEGORIE B - DISASTER RECOVERY Účelem plánování podnikové kontinuity a plánu obnovení z krize je minimalizace dopadu negativních událostí na podnikové procesy. K tomu, aby společnost zajistila nepřerušenou komunikaci napříč všemi vrstvami podniku a mohla se snadno zotavit z krize, potřebuje pruţné sluţby. Ty sluţby, které jsou poskytovány modelem SaaS a které zajišťují nepřetrţitou komunikaci i v případě krize (např. sluţby emailového poskytovatele), pomáhají společnosti nejen obnovit chod po výpadku, ale mohou také sníţit celkovou komplexnost, náklady a kaţdodenní rizika klíčových aplikací. Na příkladech poskytování emailových sluţeb a sluţeb telekomunikačních lze snadno demonstrovat, jaké výhody Cloud Computing pro plánování Business Continuity a obnovení z krize přináší. V případě narušující události v lokalitě podniku jsou komunikační sluţby stále dostupné, a společnost tak můţe zůstat v kontaktu se svými zaměstnanci, zákazníky i partnery. -29/117-



S postupnou virtualizací prostředí SaaS narůstá i vyuţití těchto technologií pro Business Continuity, neboť virtualizační software účinně napomáhá uvolnění vazby mezi aplikacemi a hardwarem, na kterém tyto aplikace běţí. Virtuální server je moţné kopírovat, zálohovat a přemisťovat stejně jednoduchým způsobem, jako je moţné přemisťovat soubor. Narůstající počet poskytovatelů virtualizačního software nabízí ve svém řešení také zabudovanou schopnost podporovat migraci dat za běhu systému. To společně se skutečností, ţe došlo k uvolnění vazby aplikací na hardware, umoţňuje podle [Rittinghouse2010] vzniknout nízkonákladovým prostředkům rychlé realokace výpočetních zdrojů bez jakéhokoli výpadku sluţby během migrace. Další nespornou výhodou virtualizace pro podnikovou kontinuitu je schopnost poskytovatele dodávat sluţby v souladu se stanovenými Service Level Agreements a také sluţby vysoké kvality. Eliminace dopadu výpadku sluţeb na straně zákazníka patří bezesporu k předním výhodám Cloud Computingu. Co se ovšem stane v případě, kdy k výpadku sluţby dojde u poskytovatele? Poskytovatel musí být schopen přesně specifikovat, co se v takovém případě stane. Riziko výpadku se týká všech modelů poskytování cloudových sluţeb, ať uţ se jedná o software, infrastrukturu nebo platformu. Většina poskytovatelů je schopna obnovit sluţby v řádu několika sekund aţ minut, ale je důleţité také zohlednit to, co se stane s daty, která nebyla v době výpadku uloţena. Existuje několik způsobů, kterými jsou poskytovatelé schopni zajistit, ţe nedojde k ţádné ztrátě, včetně cacheování a průběţného ukládání dat do operační paměti nebo soustavného ukládání dat do paralelní instance. Tento způsob zajištění obnovy dat by měl být vzat v úvahu při volbě vhodného poskytovatele cloudových sluţeb, stejně tak by tato technická specifika měla být podchycena v ujednání Service Level Agreement. V dnešní době na trhu nalezneme poskytovatele, kteří zaručují nulovou ztrátu dat v případě výpadku, někteří jiní poskytovatelé hovoří pouze o minimalizaci ztráty. Je vhodné takováto různá řešení před samotným rozhodnutím pečlivě zváţit, neboť v některých případech bude mít vyšší prioritu jiné bezpečnostní kritérium neţ ztráta transakčních dat v poslední minutě před výpadkem sluţby.

3.5.1 P02 ZÁLOHOVÁNÍ A ARCHIVACE Zálohování je pro společnost důleţité nejen v případě potřeby obnovení z krize, ale i za běţných okolností je někdy třeba vrátit stav aplikace/systému do předchozího stavu například z důvodu nekonzistence dat. Poskytovatel je zpravidla schopen zajistit zálohování automaticky na několika různých úrovních. V některých případech (například v případě vyuţívání infrastruktury jako sluţby) je schopen zákazník pomocí webového rozhraní pro správu nakoupených sluţeb ovlivňovat frekvenci těchto záloh nebo provádět zálohy ad hoc. Díky rozšíření virtualizace je dnes moţné zálohovat celé image nakoupených serverových instancí se stejnou jednoduchostí a elegancí, jako je moţné zálohovat běţné soubory. Existuje několik modelů zálohy dat [Pohorelsky2002]:   

nestrukturovaná záloha – nestrukturovanou zálohou se rozumí například manuální záloha na přenosná média (CD/DVD) s minimální informací o tom, co bylo zálohováno a kdy, inkrementální – v tomto případě jsou pravidelně prováděny inkrementální zálohy, tedy zálohy pouze přírůstku dat, rozdílová – tato metoda zálohování kopíruje soubory, které byly od poslední zálohy modifikovány nebo vytvořeny, -30/117-


 


reverzně přírůstková – tato metoda uchovává informace o rozdílech mezi současným stavem a stavem poslední zálohy, úplná záloha – tento model zálohy zálohuje data celého systému.

Vedle modelů zálohy dat lze rozlišovat mezi metodami zálohování [Zoner2010]:     

ruční zálohování dat – toto zálohování probíhá ručně a není automatizováno, automatizovaná synchronizace dat – tato metoda můţe být realizována například pomocí dávkového souboru, zálohování dat s komprimací – zálohovaná data jsou v tomto případě komprimována, a dochází tak k úspoře místa, automatizované zálohování dat s komprimací – programy umoţňující automatizovaně zálohovat data s komprimací, umoţňují také například šifrování záloh, imaging – tento způsob zálohování vytváří přesný obraz disku, a to tak, ţe jsou při záloze ukládány namísto jednotlivých souborů informace z obsazených sektorů na daném diskovém oddílu.

Vedle zálohování je pro společnost nezbytné nastavit také proces archivace. Díky archivaci je potom společnost schopna dohledávat data k určitému časovému okamţiku v minulosti. Důvodů k vyhledání archivovaných dat lze jmenovat několik. Mezi ty nejčastější patří policejní vyšetřování nebo auditing několika účetních období dozadu.

3.6 KATEGORIE C - SERVICE LEVEL AGREEMENT Součástí sestavení plánu kontinuity podnikových sluţeb je tzv. Service Level Management (podrobnosti viz kapitola 1.5). V rámci tohoto procesu jsou identifikovány základní poţadavky na obnovení podnikových sluţeb, jako je doba obnovy a bod obnovy. Stanovení doby obnovy a bodu obnovy by mělo vycházet také z identifikace, jak dlouho je společnost, resp. určitá podniková jednotka schopna bez fungující sluţby/procesu existovat a také ze specifikace toho, jak dlouhý časový úsek bez zálohy dat je pro danou sluţbu ještě tolerovatelný. Na základě toho jsou následně sestavovány plány záloh. Pokud má tedy cloudová sluţba naplňovat jak poţadavky Business Continuity, tak poţadavky krizového řízení a plánů obnovení z krize, je podstatné, aby v dokumentu SLA byly podrobně popsány všechny úrovně smluvené dostupnosti sluţby, včetně plánovaných odstávek z důvodu aktualizace a údrţby sluţeb. Základním měřítkem pro Business Continuity je procentuálně vyjádřená dostupnost cloudové sluţby, která se pohybuje u poskytovatelů nejčastěji v rozmezí 99,9% - 100%. Důleţitá je také frekvence měření a vyhodnocování tohoto intervalu, která se potom liší, zda se jedná o frekvenci měsíční, čtvrtletní či roční. Špatně definované Service Level Agreement patří k nejčastějším obavám z Cloud Computingu. [Velte2010] Důsledkem toho je potom nedůvěra společností v bezpečnost poskytovaných sluţeb, v jejich dostupnost a dobu provozuschopnosti, obnovení z krize apod.

-31/117-



3.6.1 P03 DOSTUPNOST SLUŽEB Důvodem, proč se některé společnosti rozhodují pro přesun svých sluţeb do cloudu, můţe být také to, ţe potřebují zajistit jejich dostupnost v reţimu 24/7/365, tedy nepřetrţitě a sami nejsou schopni takovou vysokou dostupnost zajistit vlastními prostředky. Poskytovatelé sluţeb jsou naopak takovou dostupnost schopni zajistit, neboť na rozdíl od většiny zákazníků disponují redundantní infrastrukturou, na kterou jsou schopni sluţby v řádu sekund přemístit v případě, kdy by došlo k výpadku na primární infrastruktuře. Jsou také schopni zabezpečit pravidelné kopie serverů, zálohování a archivaci, a to jak pro naplnění poţadavků Business Continuity v případě výpadku sluţby, tak pro schopnost zpětného dohledávání určité skutečnosti v minulosti (např. na základě policejního vyšetřování) nebo pro poţadavky auditingu. Podrobné informace o dostupnosti sluţeb musí být definovány v SLA, kde je nutné mimo jiné uvést:     

dobu, po kterou musí být sluţba dostupná, dobu plánovaných odstávek nutných pro aktualizaci a údrţbu sluţby, dobu, po kterou bude ke sluţbě poskytována technická podpora, reakční dobu, za kterou je poskytovatel schopen reagovat na vzniklou situaci a zahájit její řešení, dobu, za kterou dojde k obnovení sluţby v případě výpadku, a to odlišenou dle vzniku výpadku: - v čase podpory, - mimo čas podpory.

Dalším důvodem, proč se společnost rozhoduje nad vyuţíváním cloudových sluţeb, můţe být také to, ţe potřebuje překlenout různé výkyvy ve vyuţívání sluţeb. Typickým příkladem je firma, která ke svému podnikání vyuţívá e-shop, jehoţ internetové stránky jsou navštěvovány řekněme sezónně. Do této kategorie lze zařadit například knihkupectví s výkyvy v návštěvnosti v období Vánoc, květinářství s výkyvy na různé sváteční dny nebo rekreační zařízení se sezónní vytíţeností v létě/v zimě. Pro takovou společnost není ţádoucí, aby nakupovala zbytečně rozsáhlou infrastrukturu, která by byla plně vyuţita dvakrát do roka a ve zbývajícím čase by efektivně vyuţívána nebyla. Stejně tak ovšem není ţádoucí, aby společnost přicházela o cenné zakázky a zákazníky jenom proto, ţe není schopna ustát zvýšený nápor zákazníků. Řešením těchto problémů jsou právě cloudové sluţby, které poskytují pruţnou kapacitu vyuţívání sluţeb. Protoţe společnost dopředu ví, ve kterých dnech očekává zvýšený zájem zákazníků, můţe dle toho sestavit plán nákupu cloudových sluţeb a zaplatit skutečně za to, co spotřebuje. Poté, co nápor zákazníků pomine, navrátí se firma bez obtíţí na niţší interní kapacitu. Téměř standardem v dnešní době je architektura sluţeb, které jsou navrhovány tak, aby byly vysoce dostupné. Tyto sluţby běţí na serverech s různou úrovní virtualizované technologie, která je dodávána skrze rozsáhlá datová centra běţící podle SLA na úrovni 99,99% [Rittinghouse2010] dostupnosti nebo ještě vyšší. Například v říjnu 2008 zveřejnila společnost Google článek [Glotzbach2008], ve kterém představila dostupnost cloudových emailových sluţeb Gmail ve srovnání s běţnými konkurenčními řešeními (viz Obr. 7). Tento článek byl zaměřen především na měření spolehlivosti cloudových sluţeb, konkrétně měření dostupnosti emailové sluţby Gmail. Výsledkem bylo zjištění, ţe sluţba byla v průběhu celého roku -32/117-



dostupná více neţ 99,9% času, a to jak pro soukromé zákazníky, tak pro firmy. V průměru to tak znamená výpadek sluţeb na 10 – 15 minut měsíčně. Ve srovnání s ostatními tradičními způsoby emailového řešení si cloudová sluţba vede velmi dobře. Podle průzkumu provedeného ve stejném roce bylo zjištěno, ţe v průměru společnosti s tradičními řešeními čelí neplánovanému výpadku sluţeb 30 – 60 minut za měsíc a plánovaným odstávkám v rozmezí 36 – 90 minut za měsíc (viz Obr. 7).

Doba výpadku služby (v minutách)

Srovnání výpadků emailových služeb (v min./měsíc) 150

100 Plánovaná odstávka Neplánovaná odstávka

50

0 Gmail

GroupWise

Lotus

Exchange

Obr. 7 - Srovnání výpadků emailových sluţeb v min./měsíc (Zdroj: [Glotzbach2008])

Na základě těchto zjištění společnost Google jiţ v roce 2008 oznámila, ţe 99,9% dostupnost zaručenou SLA je schopna zajistit také u dalších sluţeb jako je kalendář, dokumenty, webové stránky nebo komunikátor. Tím ve své podstatě vznikl standard poskytování sluţeb s 99,9% nebo vyšší dostupností. V dnešní době nalezneme mnoho poskytovatelů, kteří zaručují 100% dostupnost nabízených sluţeb.

3.7 NEGATIVNÍ DOPAD CLOUD COMPUTINGU NA BUSINESS CONTINUITY Cloud Computing beze sporu přináší z hlediska podnikové kontinuity řadu výhod. Setkáme se však také s několika překáţkami, které by mohly potenciálně narušit strategii Business Continuity podniku. V minulosti se jiţ odehrálo několik případů, kdy musely být pozastaveny sluţby poskytované jednomu zákazníkovi a díky principu sdílení technologické infrastruktury došlo k narušení běhu sluţeb i u odběratelů, kteří neměli s incidentem nic společného. Příklady lze nalézt prakticky po celém světě. V následujícím textu je uvedeno několik incidentů, které se v minulosti odehrály: 

Ve Spojených státech došlo k případu, kdy bylo několik firem vyšetřováno federální policií a z toho důvodu bylo zabaveno a prošetřováno i jejich datové úloţiště. Bohuţel však toto úloţiště bylo umístěno v cloudu a vedle vyšetřovaných firem poskytovatel provozoval sluţby i ostatních zákazníků. Bez ohledu na to byly všechny internetové stránky provozované poskytovatelem dočasně vypnuty. Společnostem tak byla dle [Fox2009] způsobena několikamilionová ztráta. Zvláště těm společnostem, jejichţ business byl zaloţen na fungující internetové stránce, bylo zcela zamezeno naplňovat své podnikové cíle. -33/117-





V Evropě lze nalézt podobný příklad ve Švédsku. Zde se v nedávné době zdvihla iniciativa podporovaná vládou, která vyústila dočasným ukončením sluţeb jednoho poskytovatele internetových sluţeb. Důvodem pro zamezení moţnosti poskytovat sluţby bylo, ţe jedním ze zákazníků vyuţívajících jeho sluţeb byla skupina Pirate Bay (skupina vyšetřovaná z důvodu porušení autorských práv u digitálních médií). [Fox2009]

V evropských podmínkách a v podmínkách České republiky konkrétně sice neexistuje instituce s tak silnými pravomocemi, jako tomu je v případě FBI ve Spojených státech, ale je moţné, ţe společnost bude vyuţívat sluţby datového centra umístěného v jiné zemi. V takovém případě je vhodné ověřit si stávající místní legislativu. Jistou moţností, jak obejít toto riziko, je umístit svá data do více datových center. Je však třeba ověřit, zda jsou tato datová centra vlastněna odlišnými poskytovateli. Jedná se však vţdy o komplikované řešení, které naproti základnímu benefitu konceptu Cloud Computing znamená spíše zvýšení nákladů odebírající společnosti. K ohroţení kontinuity sluţeb zákazníka můţe dojít také v případě, kdy jeden z odběratelů sluţeb čelí útokům tzv. odmítnutí sluţby (angl. Denial of service - jedná se o snahu učinit např. internetovou sluţbu nebo webovou stránku nedostupnou). V takovém případě však poskytovatel můţe učinit první krok a ukončit poskytování sluţeb zákazníkovi ohroţujícímu provoz celé infrastruktury, jako se to stalo například na začátku prosince 2010 [Kirk2010], kdy Amazon rozhodl o ukončení poskytování sluţeb organizaci WikiLeaks, a zabránil tak moţnému výpadku sluţeb ostatních odběratelů.

-34/117-



4 VYUŽITÍ BCM A CLOUD COMPUTINGU V OBLASTI TERCIÁRNÍHO VZDĚLÁVÁNÍ Sektor terciárního vzdělávání má svá jistá specifika, která vyplývají ze způsobu jeho financování a z mnoha dalších faktorů, kterými je například struktura "zákazníků", kterým své sluţby poskytuje. V mnohých rysech se však sektor vzdělávání podobá komerčním společnostem, neboť v dnešní době roste konkurence v oblasti terciárního vzdělávání, a instituce proto bojují o nové studenty. Díky tomu dochází k dramatickému nárůstu nákladů v sektoru školství, rychlejšímu neţ je růst inflace. Univerzity se snaţí zvýšit atraktivitu lepší nabídkou sluţeb, výjimku netvoří ani nabídka informačních technologií. Tato kapitola je blíţe zaměřena na to, jaká specifika má v sektoru terciárního vzdělávání Business Continuity Management, co mu můţe nabídnout Cloud Computing a jak tento koncept vyuţit k naplnění cílů BCM.

4.1 CHARAKTERISTIKA SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ A JEHO ODLIŠNOSTI OD SEKTORU SOUKROMÉHO Informační technologie se staly nedělitelnou součástí systému vzdělávání. Důkazem toho je vznik řešení, mezi která patří studijní informační systémy (SIS) nebo řídící výukové systémy (LMS), které se staly kaţdodenní součástí ţivota institucí pro vzdělávání. Stejně tak jako je tomu i v jiných ekonomických odvětvích, i v sektoru školství vykonávají informační technologie řadu klíčových rolí. Celkové náklady na IT v sektoru terciárního vzdělávání mají rostoucí tendenci. Částečně je to způsobeno nároky na širokopásmové připojení nebo na vybavení počítačových učeben. Dalším důvodem vysokých nákladů na IT je podle [Educause2010] dlouhá tradice institucí budovat si své vlastní informační systémy a spravovat téměř veškerou IT infrastrukturu interně. Sektor terciárního vzdělávání je odlišný od komerčního sektoru strukturou uţivatelů, kteří informační systémy vyuţívají a kteří kladou prakticky neustále poţadavky na nové prvky technologické infrastruktury, na nové aplikace, na připojení, na vybavení učeben, počet přístupových bodů bezdrátové sítě a spoustu dalších. Zatímco mezi uţivatele informačních systémů patří fakulty, katedry, zaměstnanci včetně administrativních pracovníků, kteří jsou běţnými uţivateli informačních systémů také v komerčních sférách (jako paralela k podnikovým jednotkám, oddělením apod.), v sektoru terciárního vzdělávání se setkáme ještě s jednou skupinou uţivatelů. Jsou jí studenti. Tato skupina je velmi početná, má relativně vysoké poţadavky na funkcionalitu informačního systému a mimo jiné vyţaduje precizní přidělení přístupových práv. Představuje také vysoké zatíţení informačních systémů v určitých obdobích, mezi která patří například přihlašování na zkoušky a také poţaduje v podstatě 24/7 dostupnost systémů. Díky této členitosti struktury uţivatelů však IT odborníci v sektoru vzdělávání obvykle nečelí otázkám uţivatelů, se kterými se lze setkat v soukromém sektoru komerčních organizací [Gulachek2005]. Mezi takové otázky patří dotazy na to, jaký existuje plán Business Continuity nebo co se stane v případě, kdy nastane neočekávaná událost apod. Problémem oblasti terciárního vzdělávání a sektoru školství v České republice obecně je to, ţe instituce nemají dostatek financí. To je dáno především tím, ţe na rozdíl od našich západních sousedů studenti neplatí školné, a instituce je proto závislá na tom, kolik financí dostane od ministerstva školství MŠMT, resp. od státu. Tato situace má nejen dopad na moţnosti institucí na nákup technického vybavení, ale také komplikuje to, jak chápat v otázkách informačních technologií ve školství roli studenta – zda se jedná pouze o uţivatele, nebo o zákazníka. -35/117-



Výjimku v tomto ohledu tvoří v České republice soukromé vysoké školy. Na soukromých školách studenti platí školné stejně tak, jako je tomu v zahraničí. Na těchto školách proto můţeme hovořit o studentovi jako o zákazníkovi. Státní školy teprve přistupují k modelu placení školného, který v budoucnu ovlivní to, jaké sluţby bude škola muset poskytovat tak, aby uspokojila potřeby studenta, tedy zákazníka. V současném modelu státních vysokých škol se proto dostáváme k dilematu, jak studenta chápat. V rámci této diplomové práce bude o studentovi v tomto kontextu dále uvaţováno jako o zákazníkovi. Důvodem je to, ţe pravděpodobně jiţ brzy budou všichni studenti za sluţby vysokých škol platit a také to, ţe jiţ dnes jsou to právě studenti, kteří kladou poţadavky na to, jaké informační technologie potřebují ke svému studiu. Protoţe je tato práce zaměřena na vyuţití Cloud Computing řešení pro naplnění Business Continuity, dostaneme se k otázce, kdo má větší zájem o udrţení Business Continuity instituce – zda je to student nebo MŠMT, které školy prakticky financuje. Lze předpokládat, ţe je to student, kdo by měl klást vysoké poţadavky na Business Continuity, neboť se jedná o jeho budoucnost a jeho data, která by mohla být potenciálně ztracena. Na základě těchto důvodů budeme v rámci této práce o studentovi uvaţovat jako o zákazníkovi odebírajícím sluţby instituce terciárního vzdělávání a zároveň uţivateli informačních technologií touto institucí poskytovaných.

4.2 VYUŽITÍ BCM V SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ Postupný nárůst informačních technologií do kaţdodenní přítomnosti má za důsledek i paradoxní skutečnost, ţe řada institucí si plně neuvědomuje svou závislost na funkčních informačních systémech. Proto je relativně jednoduché zanedbat či opomenout skutečný dopad rušivé události na chod instituce. Existují dva způsoby, kterými můţe být instituce ovlivněna v případě, kdy se rušivá událost dotkne nějakým způsobem IT systémů [Datamonitor2007]:  

selhání IT - rušivá událost přímo narušila IT systémy, které je potřeba zcela obnovit před tím, neţ bude instituce opět schopna běţné činnosti, nepřímý dopad na IT - IT systémy se budou muset přizpůsobit rušivé události, která nastala v jiné části organizace, coţ je dáno právě zvyšující se závislostí podnikové činnosti na informačních systémech a na vzrůstající vzájemné provázanosti.

V kapitole 1.2 Ţivotní cyklus Business Continuity jsou uvedeny 4 fáze ţivotního cyklu plánování Business Continuity. V následujících podkapitolách je nastíněno, jak lze BCM v sektoru vzdělávání v jednotlivých fázích tohoto cyklu prakticky vyuţít.

4.2.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI Univerzity jsou stejně jako ostatní společnosti náchylné k mnoţství přírodních a lidskou vinou způsobených mimořádných událostí a rizik. Společně s rozpoznáním, ţe ne všechny události mohou být odvráceny a ţe některá rizika mohou být přijatelná lze dojít ke zjištění, ţe řádné plánování je pro udrţení a obnovení sluţeb naprosto nezbytné. Jak je uvedeno v první kapitole, která podrobněji popisuje principy plánování Business Continuity, toto plánování není spojeno výhradně s katastrofami typu záplavy nebo zemětřesení, ale také s rušivými událostmi jako je výpadek dodávky elektrického proudu či serveru, se kterými se v prostředí dnešních společností setkáme poměrně často. Jedním z důvodů je podle [Vogel2010a] nárůst IT v posledním desetiletí, který přinesl nejen nové moţnosti, ale také nové zranitelnosti. Zajímavé je však to, ţe i kdyţ je plánování Business Continuity v sektoru terciárního vzdělávání chápáno jako důleţité, oddělení informačních technologií obvykle nepřikládá těmto plánům velkou -36/117-



prioritu, ale podporu Business Continuity vykonává spíše jako proces v pozadí. Důvodem je zejména to, ţe instituce terciárního vzdělávání nejsou provozní společností, pro kterou by výpadek sluţeb znamenal obrovské finanční ztráty nebo pro kterou by výpadek nutně znamenal úplné zastavení činnosti. Tento fakt také svědčí o skutečnosti, ţe nutnost Business Continuity je sice chápána jako nezbytná součást řízení instituce terciárního vzdělávání, není však včleněna hluboko do podnikové kultury. Poněkud kontrastně na druhou stranu působí informace, ţe podle několika studií (např. [Pirani2007]) si většina pracovníků napříč sektory nedokáţe Business Continuity bez funkčních IT systémů představit. Lze proto říci, ţe zatímco kontinuita podniku je spojována se spolehlivě fungujícími IT systémy, podpora ze strany IT toto nevidí jako prioritu. Existuje několik faktorů, kvůli kterým by mohl vzrůst zájem o problematiku Business Continuity. V následujícím textu jsou tyto faktory představeny, s důrazem na specifika sektoru terciárního vzdělávání [Datamonitor2007]: 





řada moţných rušivých událostí - i kdyţ přírodní katastrofy nejsou v České republice díky geografické lokaci tak častým jevem, události jako prosakování vodovodního potrubí a výpadky dodávky elektrického proudu jsou mnohem frekventovanější hrozbou pro udrţení kontinuity podnikání, vzrůstající závislost na IT - v případě, ţe by došlo k selhání centrální funkce IT, pro instituce terciárního vzdělávání by bylo čím dál tím těţší pokračovat ve své činnosti, a to i pouze částečně, konkurenční tlak a povědomí o značce - ačkoli se můţe zdát, ţe u institucí terciárního vzdělávání je poněkud nezvyklé hovořit o značce a procesu řízení značky, i tyto organizace si musí zachovat svou pověst stability v případě krize, pokud chtějí přeţít.

4.2.2 FÁZE 2 – URČENÍ STRATEGIE BCM Cílem plánu podnikové kontinuity je striktní dodrţování bezpečnostní politiky a politiky soukromí, které platí v rámci celé instituce. Je důleţité si uvědomit, ţe tyto politiky a regulace musí být dodrţovány i v situacích, kdy instituce provozuje svou činnost za mimořádných podmínek v dobách krize. Informační systémy jsou zranitelné vůči řadě narušujících událostí ve škále od mírných (např. krátkodobý výpadek elektrického proudu, selhání harddisku) aţ po závaţné (např. zničení vybavení, poţár). Některé zranitelnosti je podle [Vogel2010a] moţné odstranit pomocí technických či operativních řešení, ale není moţné odstranit veškerá rizika. Sníţení rizik pomocí plánování řešení nepředvídaných událostí spočívá spíše v zaměření se na efektivní a účinná řešení pro obnovu systému. Mezi účinná opatření patří například určení klíčových zaměstnanců, kteří by působili jako kontaktní osoby v případě, kdy nastane krize. Tito zaměstnanci jsou následně odpovědní za řešení situace a za navrácení podniku do běţného chodu. Odpovědní zaměstnanci jsou typicky určeni na několika úrovních, kdy na kaţdé úrovni vzniká krizový tým, který je hierarchicky podřízen týmu umístěnému o úroveň výše. Součástí seznamu kontaktních osob by měli být také zástupci pověřených osob, které by bylo moţné kontaktovat v případě, ţe by pověřená osoba nebyla zastiţena. Samozřejmostí je vedle jmen dodání také telefonních čísel či jiných kontaktních údajů. Nejvýše umístěný tým je pak odpovědný nejvyššímu managementu společnosti/instituce a zajišťuje reporting směrem nahoru k managementu, stejně tak jako předávání zpráv a delegování úkolů směrem dolů na krizové týmy. Tento způsob uspořádání pro krizové situace je běţný v komerčním sektoru, v sektoru terciárního vzdělávání se s ním však málokdy setkáme. -37/117-



V plánu podnikové kontinuity by měly být popsány také jiţ existující metody zálohování a obnovy. Do této problematiky také spadá testování existujícího záloţního prostředí, a to v následujících bodech [Rittinghouse2005]:   

zda záloţní prostředí obsahuje potřebnou infrastrukturu, vybavení, hardware, software a komunikační prostředky, zda je záloţní prostředí schopno zajistit plný provoz, zda je v záloţním prostředí implementována stejná úroveň bezpečnostních opatření, jako je tomu u provozního prostředí.

Plán podnikové kontinuity musí být sestaven na základě zváţení, zda je moţné určitou podnikovou sluţbu obnovit v primárním provozním prostředí nebo zda je potřeba k obnově sluţby vyuţít prostředí alternativní/záloţní. Vytvoření takového alternativního prostředí je finančně relativně velmi nákladné. V případě institucí terciárního vzdělávání by však takové prostředí mohlo být vytvořeno například na jiné domácí univerzitě. Díky tomu, ţe univerzity a ostatní především výzkumné instituty jsou v České republice propojeny vysokorychlostní akademickou sítí, bylo by moţné vytvářet záloţní prostředí bez dodatečné investice na vybudování infrastruktury.

4.2.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU Plány Business Continuity jsou zaloţeny na ohodnocení rizik a na analýze dopadu a zahrnují proces pravidelné údrţby včetně proškolování. [Vogel2010a] Pro sestavení BC plánu v podmínkách konkrétní instituce by mělo být zodpovězeno, co se stane v případě, kdy nastanou určité podmínky, které znesnadní běţný průchod procesem podle několika předem definovaných scénářů. Mezi takové scénáře uveďme například [Gulachek2005]: 1. Není moţné dostat se do kanceláře, ale je moţné dostat se k datům. 2. Je moţné dostat se do kanceláře, ale není moţné dostat se k datům. 3. Ztráta klíčového zaměstnance (nemoc, smrt nebo jakákoli jiná příčina). Z takto definovaných scénářů je následně moţné odvodit nápravná opatření, mezi která patří zálohování záznamů a souborů a jejich ukládání mimo prostory kanceláře/budovy, vytvoření telefonního seznamu kontaktů a jeho distribuce mezi zaměstnance a jmenování pověřeného zástupce v případě, kdy by první kontakt ze seznamu nebyl z jakýchkoli důvodů k zastiţení. Kaţdý plán podnikové kontinuity by se měl zaměřovat na naplnění základních elementů:  

  

identifikace sluţeb, podnikových procesů, aplikací a podpůrných nástrojů (obchodní záznamy, počítače, telefony atd.), které musí být udrţovány během výskytu narušující události, identifikace sluţeb, procesů a aplikací, které nejsou kritické, a za určitých okolností můţe dojít k přerušení jejich provozu. V rámci tohoto kroku je nutné definovat, jak dlouho je určité oddělení schopno bez těchto sluţeb fungovat, a to včetně faktorů, které mají na tuto dobu trvání vliv [Vogel2010a], určení minimálního stavu zaměstnanců, dat, zařízení atd., který je nevyhnutelně potřebný k zajištění klíčových funkcí a k zajištění obnovy, udrţování aktuálního seznamu kontaktů se jmény a telefonními čísly klíčových zaměstnanců společně s jejich odpovědností za obnovu běţné činnosti, identifikace vzájemného vztahu plánu BC s operativními plány kontinuity ostatních oddělení. Do tohoto kroku spadá zejména identifikace toho, která oddělení jsou na sobě vzájemně závislá. -38/117-





zajištění, ţe všichni zaměstnanci, kteří mají odpovědnost za udrţení podnikové kontinuity, jsou pravidelně proškolování a připraveni reagovat na krizové situace.

K tomu, aby BCM mohl v instituci fungovat, je potřeba, aby jednotliví zaměstnanci, resp. jednotlivá oddělení, pro které byl sestaven plán podnikové kontinuity, měli moţnost obrátit se na zastřešující orgán, jehoţ odpovědností by bylo za mimořádných událostí zajistit obnovení běţného provozu instituce. Sestavením plánu Business Continuity je moţné dosáhnout několika pozitivních výstupů. Tyto výstupy nejsou výlučně typické pouze pro sektor terciárního vzdělávání, mohou však pomoci instituci lépe porozumět významu sestavení plánu BC. Tyto pozitivní výstupy jsou uvedeny v následujícím seznamu [Gulachek2005]: 



   

Návrh architektury a způsob zavedení nových sluţeb – nové sluţby a technologie jsou na základě plánu navrţeny redundantně s implementací plánu obnovy a sníţení rizik jako součást plánování Business Continuity. Změna přístupu ke změnovému řízení – z poţadavků plánů Business Continuity vyplývá potřeba zvýšeného počtu a úrovně dokumentace, která není v současné době u institucí terciárního vzdělávání dostatečná. Spokojenost a důvěra zákazníků – na základě definovaného plánu je moţné sledovat zvýšenou spokojenost s klíčovými sluţbami ze strany studentů. Spolehlivost sluţeb – na základě SLA mezi oddělením poskytujícím informační sluţby a ostatními odděleními je zajištěna vyšší spolehlivost dostupnosti sluţeb. Podpora technologických zdrojů pro naplnění plánů Business Continuity. Upevnění komunikačního kanálu napříč celou organizací – samotná existence plánu Business Continuity vyţaduje ustanovení plánu komunikace. Jak technické, tak administrativní komponenty tohoto plánu vytváří nové kanály komunikace mezi odlišnými okruhy zaměstnanců na několika úrovních. V případě institucí terciárního vzdělávání hovoříme například o komunikaci mezi zaměstnanci nejen na úrovni jednotlivých kateder, ale také mezi jednotlivými fakultami v rámci celé školy.

4.2.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU Význam údrţby a pravidelné revize plánu je zřejmý: zajistit aktuálnost plánu, a to včetně aktuálnosti seznamu kontaktních osob a pověřených zástupců pro případ krize. V pravidelných intervalech by mělo být realizováno také školení zaměstnanců instituce. Je-li plánování podnikové kontinuity zakořeněno v samotné kultuře instituce, jsou pak nově příchozí zaměstnanci v této oblasti automaticky proškolováni. Lze uvést následující sadu obecných důsledků plánování Business Continuity s důrazem na sektor terciárního vzdělávání [Gulachek2005]: 

vrchní dozor – instituce terciárního vzdělávání musí zodpovědně spravovat svá data, a to zejména v případech, kdy se podílí na veřejně financovaných projektech. Mezi techniky Business Continuity patří zajištění informační bezpečnosti a pro ochranu, uchování a udrţení vyuţitelnosti dat a systémů v případě krize existují specializované nástroje. V případě, kdy se instituce podílí na výzkumu, nese tato instituce dodatečnou odpovědnost za data výzkumu jako součást poţadavků stanovených v rámci grantu.



řízení – metodologie a přístupy k řízení technologie jsou v dnešní době klíčovým poţadavkem v prostředí institucí. Do této oblasti patří například otázky změnového řízení, výměny nebo upgrade klíčových serverů či síťových komponent, existence rollback plánu atd. -39/117-




 


inovace – vývoj a správa technologií musí být natolik flexibilní, aby se mohly přizpůsobit inovacím. Tato flexibilita je dána dvěma zásadami úspěšného BC plánování: spolehlivostí a redundancí. Inovace pak musí splnit poţadavky Business Continuity, aby se mohla stát součástí produkčního prostředí. náklady – díky existenci plánů kontinuity je moţné rozumným plánováním sníţit náklady na hardware a software. spolupráce – příleţitosti pro sdílení zdrojů mezi institucemi plynou z existence současných aktiv, lidského kapitálu a vazeb mezi institucemi. Strategické příleţitosti spolupráce umoţňují institucím zlepšit své základní kompetence. Díky tomu můţe vzniknout partnerství umoţňující vzniknout záloţním lokalitám Business Continuity pro obě strany navzájem. Tento inovativní přístup vzniká na základě uvědomění si důleţitosti Business Continuity a strategické důleţitosti účinného vyuţití aktiv.

4.3 POTENCIÁL CLOUD COMPUTINGU PRO SEKTOR TERCIÁRNÍHO VZDĚLÁVÁNÍ Specialisté v oboru informačních technologií jsou skeptičtí k adopci Cloud Computingu v rámci své společnosti. Výjimkou není ani oblast terciárního vzdělávání. Důvodem je jak typicky česká nedůvěřivá povaha, tak nekonzistentní literatura, která slibuje výhody Cloud Computingu na jedné straně a hovoří o bezpečnostních rizicích na straně druhé. Dalším důvodem je nekonzistence v terminologii. Setkáme se s mnoha definicemi Cloud Computingu od dodavatelů, konzultačních společností i od jednotlivců odborné informatické veřejnosti. Nesporným důvodem ke skepsi odborníků je také to, ţe v minulosti se jiţ setkali s mnoha novými koncepty, které slibovaly přínos něčeho nového a slibovaly také řadu benefitů (např. grid computing). Cloud Computing se od ostatních nových konceptů v kontextu oblasti terciárního vzdělávání odlišuje několika základními body [Katz2009]: 

První odlišností je odlišnost tohoto konceptu po technické stránce. U Cloud Computingu se setkáme s řadou vyspělých standardů umoţňujících standardizovanou komunikaci mezi oběma stranami. Mezi další technické charakteristiky patří rozšíření vysokokapacitní sítě, rozšíření konceptu virtualizace, dostupnost aplikací apod. To, ţe se Cloud Computing mohl jako koncept objevit a rozvinout právě v poslední dekádě, vychází z několika technických předpokladů [Svoboda2009]. Mezi tyto předpoklady patří právě vysokorychlostní síť, která je v dnešní době jiţ samozřejmostí prakticky všech firem. U institucí terciárního vzdělávání je taková vysokorychlostní síť zajištěna akademickou sítí, která například u nás patří k nejrychlejším sítím v České republice vůbec.



Dalším předpokladem vedoucím k rostoucí popularitě Cloud Computingu je také výpočetní výkon procesorů, kapacita diskových polí či datových center. Současně se rozšiřuje také koncept virtualizace, díky kterému je moţné dosahovat značných finančních úspor, a to jak u virtualizace serverové, tak virtualizace desktopů. Zejména desktopová virtualizace v oblasti vzdělávání přináší nesporně řadu výhod. [Zahorova2010], [CIO2010] Protoţe jsou to právě školy, které potřebují vybavovat učebny mnoţstvím počítačů, na jejichţ pořízení a údrţbu mnohdy nezbývají finanční prostředky a navíc na těchto počítačích je zapotřebí stejná konfigurace a instalace aplikací. Není proto nic snazšího, neţ na jednotlivé koncové stanice aplikovat jednu image operačního systému. Zjednoduší se tím správa koncových stanic a dojde také ke sníţení nákladů na nové vybavení učeben.

-40/117-





Generace, která vyrůstala na širokopásmovém připojení k internetu, v prostředí sociálních sítí a která zvyšuje počty prodejů netbooků, hledá právě taková řešení, která by jim poskytovala moţnost ulehčit svým nízkonákladovým zařízením a umoţnila jim přesunout výpočetní kapacitu na servery poskytovatelů. Tito uţivatelé toto řešení vyhledávají jiţ dnes ve svém soukromém ţivotě a pro většinu aplikací vyuţívají internetový prohlíţeč jako uţivatelské rozhraní. Mezi takové uţivatele patří především studenti a ti jsou zákazníky vysokých škol a univerzit, a jsou proto uţivateli sluţeb poskytovaných institucemi terciárního vzdělávání.

Vedle výhod jmenovaných výše nabízí Cloud Computing také další prospěch, kterým je moţnost regulace poskytovaných sluţeb dle sezónnosti. Uveďme příklad květinářství, které poskytuje své sluţby mimo jiné online a největší zatíţení internetového obchodu zaţívá na svátky jako je Den matek, případně Den ţen či svátek Svatého Valentýna, zatímco v ostatních dnech není zatíţení internetové aplikace tak vysoké. V takovém případě je výhodné vyuţívat Cloud Computingu k nastavení optimální infrastruktury, neboť zatíţení je dopředu předvídatelné. Stejně dopředu předvídatelné zatíţení můţeme sledovat i u institucí terciárního vzdělávání v době státních zkoušek, zápisů předmětů na začátku semestru, přihlašování na zkoušky apod. Tento způsob zajištění potřebné infrastruktury v případě potřeby je velmi efektivním způsobem sníţení nákladů na infrastrukturu. Veřejné cloudy poskytované firmami jako je IBM, Google nebo Amazon jsou vhodné pro takové sluţby, které neodlišují danou instituci od institucí konkurenčních nebo které nejsou těsně spojeny s prvky, které instituci diferencují a poskytují jí konkurenční výhodu. V případě, kdy daná činnost přidává instituci unikátní hodnotu, je vhodné vyuţívat privátních cloudů. Tyto cloudy umoţňují alespoň částečně sníţit náklady na IT, a to díky konsolidaci aktiv prostřednictvím virtualizace. Jak jiţ bylo zmíněno výše, virtualizaci je moţné realizovat na několika úrovních, ať uţ se jedná o koncové stanice uţivatelů nebo o servery. Nedostatek důvěry v cloudové sluţby má zcela jistě mnoho příčin. Mezi ty nejčastější příčiny společné jak pro komerční sektor, tak pro sektor terciárního vzdělávání, patří [Katz2009]:     

nedostatečně definované nebo zcela chybějící SLA, nedostatečné řízení rizik, nejasně definované ROI, nevyspělost trhu, problémy plynoucí z managementu společnosti.

V sektoru terciárního vzdělávání se setkáme s obdobnými příčinami, které jsou dále zatíţeny dodatečnými obavami ze ztráty důvěry veřejnosti, a to podle [Educause2010] především u institucí, které se věnují výzkumu např. lidského organismu či jadernému výzkumu. Instituce terciárního vzdělávání se rovněţ obávají ztráty své konkurenceschopnosti, a to jak na domácím trhu, tak i v kontextu mezinárodním. V sektoru terciárního vzdělávání jsou z pohledu cloudových sluţeb patrné rysy, které lze shrnout do následujících bodů [Katz2009]: 

Instituce terciárního vzdělávání jsou zatíţeny několika aspekty, které by mohly potenciálně zpomalit adopci Cloud Computingu. Mezi sporné otázky patří audity instituce, které podléhají ministerstvu školství nebo ochrana dat výzkumu, neboť výzkum je důleţitou business oblastí terciárního vzdělávání. -41/117-











Odlišné činnosti budou přesouvány do cloudu s odlišnou rychlostí – sluţby, které by bylo moţné umístit do cloudu v rámci institucí terciárního vzdělávání, můţeme rozdělit do tří kategorií: - sluţby, které překrývají komerčně poskytované sluţby (např. emailové schránky, VoIP, telefony) – tato oblast bude pravděpodobně růst pro vyuţití cloudových sluţeb, - aplikace, které instituce potřebují pro řízení své organizace (ERP) – tato oblast je řízena poměrně silnou regulací a její růst a případný přesun do cloudu bude pomalý, - aplikace vyuţívané pro výzkumnou činnost – tato oblast je jiţ nyní virtualizována (vzdálená správa, superpočítače…). Některé instituce se mohou stát poskytovateli cloudových sluţeb – v dnešní době se setkáme s řadou organizací, které se snaţí odpovědět si na otázku, zda by se oni sami nemohli stát poskytovateli cloudových sluţeb. Tato moţnost není vyloučena ani u institucí terciárního vzdělávání, neboť tyto instituce zpravidla disponují dostatečně výkonnou infrastrukturou, která není plně vyuţívána, a zároveň by se měly naučit chovat více trţně. Silné jméno instituce by také mohlo zajistit zisk širokého portfolia zákazníků. Obecně platí, ţe přesun sluţeb do cloudu, které jsou nové, nebo o které vzrostl nově zájem, je rychlejší neţ přesun jiţ existujících sluţeb. V oblasti terciárního vzdělávání je poptávka po sluţbách velmi proměnlivá, neboť je vyvolávána jak ze strany studentů, kteří se kaţdý rok obměňují (u komerčních institucí tak rychlá cirkulace uţivatel sluţeb není běţná), tak i ze strany vyučujících obnovujících osnovy vyučovaných předmětů. Jestliţe instituce terciárního vzdělávání nevytvoří ţádnou cloudovou strategii, můţe se stát, ţe uţivatelé, kteří začnou sami vyuţívat cloudové sluţby, tímto způsobem instituci přivedou do cloudu i bez vedení organizace jako takové. Jak jiţ bylo několikrát uvedeno výše, studenti patří mezi skupinu uţivatelů, u kterých je pravděpodobné očekávat zvýšený zájem o cloudové sluţby (viz kapitola 4.3.2).

4.3.1 KTERÉ SLUŽBY PŘESUNOUT DO CLOUDU A KDY Základní otázkou, kterou si instituce terciárního vzdělávání musí poloţit, je rozhodnutí, které sluţby je vhodné přesunout do cloudu a kdy. Je důleţité zdůvodnit, proč by daná sluţba měla být přesunuta do cloudu a zhodnotit takové rozhodnutí z hlediska ušetřených nákladů a sníţení pracovních míst. Podle [Educause2010] by měla instituce terciárního vzdělávání podstoupit následující čtyři kroky: 







Provést analýzu dopadu – instituce by měly zhodnotit svá data podle úrovně důleţitosti a citlivosti, aby tak určily, které sluţby přináší instituci odlišnost a které sluţby by naopak mohly být snadno přesunuty do cloudu. Ustanovit kontrolu sluţeb, budovat důvěru a implementovat bezpečnostní modely – porozumět rizikům jednotlivých procesů za účelem tvorby rozhodnutí o úrovni garance sluţby. Vycházet ze stávajících modelů zajištění sluţeb a přidat dodatečná kritéria pro Cloud Computing – revizí sluţeb instituce a modelů, jakými jsou sluţby zajišťovány, zjistí instituce, jakým způsobem by tyto sluţby mohly být poskytovány v rámci cloudu. Před podepsáním smlouvy o poskytování sluţby s dodavatelem ověřit, zda bude v budoucnu případně moţné poskytovatele změnit. Stejně tak je vhodné si předem zjistit, zda by bylo moţné sluţbu případně opět poskytovat interně.

-42/117-



I kdyţ se společnost rozhodne změnit strukturu podnikových procesů, samotná reorganizace by neměla být hlavním důvodem k implementaci konceptu Cloud Computingu. Setkáme se s mnoha cíli cloudových sluţeb, které by bylo vhodné zváţit dříve, neţ dojde k přesunu sluţby do cloudu. Lze uvést několik předpokladů pro přesun sluţby [Educause2010]: 









Sluţba není pevně svázána s businessem - lze obecně říci, ţe čím je sluţba spjatější s podstatou podniku, tím obtíţnější (a pravděpodobně také méně lákavé) je její přesunutí do cloudu. Samotná otázka, zda sluţbu přesunout do cloudu, však není jednoduchá. Zpravidla nejjednodušší rozhodnutí bývají učiněna v případě, kdy se jedná o nové potřeby, které dosud nebyly naplněny stávajícími sluţbami, nebo se naopak jedná o nové sluţby, které doposud nebyly začleněny do podnikových procesů. Vysoké riziko ROI - jedním z často zmiňovaných témat se stává úloţiště dat v rámci cloudu a nebo na cloudu zaloţený supercomputing. Zatímco předmětem zájmu se často stává bezpečnost a zachování soukromí dat, skrývá Cloud Computing pro tyto potřeby skutečné výhody v podobě sníţení nákladů z důvodu kompenzace vysokých nákladů na uţívání a eliminace značných výdajů na výstavbu a údrţbu datových center. Sluţby nesoucí nízké riziko - obdobně jako s kaţdým novým a relativně neodzkoušeným projektem, i v případě cloudu je vhodné přesouvat jako první ty sluţby, které nenesou velké riziko v případě, kdy se ocitnou mimo instituci. Z takového porovnání sluţeb vyplývá, ţe např. plně integrovaný ERP systém není vhodným kandidátem pro první zkušenosti s cloudovými sluţbami. I kdyţ tento fakt se zdá být jasným, mnoho společností začíná svou zkušenost s cloudovými sluţbami právě přesunem svého ERP systému. Prioritizace cloudu - prioritizace se netýká výhradně toho, kterou technologii je vhodné jako první přemístit do cloudu, ale toho, jak velkým výzvám čelí celé odvětví (v tomto případě terciární vzdělávání) a do jaké míry je moţné trend budoucího směřování institucí terciárního vzdělávání tímto ovlivnit. Důvěra - předpokladem úspěšného fungování cloudového partnerství je vzájemná důvěra obou participujících. Vedle důvěry je důleţitým předpokladem také spojitost sluţby a rychlá reakční doba ze strany poskytovatele.

4.3.2 FENOMÉN „CONSUMERIZACE“ A SDÍLENÍ OBSAHU V literatuře se v dnešní době často setkáme s pojmem "consumerizace" (orig. consumerization, viz např. [Bittman2008]). Tento termín se vztahuje k trendu, kdy uţivatel začne s pouţíváním určité informatické sluţby ve svém soukromém ţivotě, oblíbí si ji a přinese ji do svého profesního ţivota. Právě tento trend je dobře patrný v sektoru terciárního vzdělávání, především z důvodu podstatného vlivu studentů, kteří rádi vyuţívají cloudových sluţeb, a to jednak z důvodu pouţívání netbooků či mobilních zařízení, která nejsou natolik výkonná, aby mohla hostovat vlastní aplikaci a jednak z důvodu okamţitého přístupu k datům z několika přístupových zařízení. Princip consumerizace lze dobře pozorovat také na fenoménu sociálních sítí. Ty byly zpočátku vyuţívány především pro soukromé účely, s postupem času se dostaly do profesionální sféry a dnes jiţ nikoho nepřekvapí, kolik informací o instituci je snadno k nalezení na stránkách sociální sítě a jak je mnohdy obtíţné najít obdobné informace na klasických internetových stránkách. V dnešní době roste objem obsahu, který je ukládán na nejrůznějších místech internetu, výjimku netvoří ani sociální sítě. Se vznikem konceptu Web 2.0 je obsah na internetu stále více interaktivní a zároveň takto uţivatelem vytvořený obsah má jednu klíčovou vlastnost - ţivotnost. Podle [Bittman2008] je ţivotnost takového díla ve své podstatě neomezená. Zároveň získal takto vytvořený -43/117-



obsah velký vliv v široké komunitě uţivatelů internetu. Vznikly nové aspekty ochrany díla a částečně byly díky sdílení tvorby mezi uţivateli smyty některé otázky plagiátorství.

4.3.3 VYUŽITÍ CLOUD COMPUTINGU PRO KOMUNIKACI Nejrozšířenějším konceptem poskytovaných cloudových sluţeb jsou nástroje pro kolaboraci uvnitř týmů, především nástroje pro komunikaci a sdílení souborů. Prostředky pro komunikaci jsou přirozeně vhodné pro cloudový přístup, neboť jsou téměř všechny závislé na jedné infrastruktuře, kterou je internet. Mezi tyto komunikační prostředky patří emailová komunikace a zasílání zpráv pomocí tzv. instant messagingu. Vyuţívání komunikace poskytované prostřednictvím cloudu nese pro instituci řadu výhod. Výhody spočívají nejen v zajištění fungujících emailových sluţeb i v případě, ţe instituce je narušena neočekávanou událostí, ale také v tom, ţe společnost velmi výrazně ulehčí své vlastní technologické infrastruktuře. Správa emailových sluţeb ve vlastní organizaci spotřebovává nemalé mnoţství zdrojů, ve většině případů patří dle [Gatewood2009] mezi ty největší konzumenty technologie. V prostředí terciárního vzdělávání se setkáme také s otázkou, zda mají být sluţby agregovány či nikoli. Tato otázka je výchozím bodem pro rozhodování, jakým způsobem by měly být sluţby v rámci univerzity zajišťovány. V některých případech jsou zajišťovány jedním oddělením a poskytovány podle potřeby, v jiných případech jsou zajišťovány prostřednictvím agregace. Jako příklad lze uvést emailové sluţby, které bývají často agregovány. Tím je umoţněno univerzitám sníţit náklady na provoz společné platformy pro ty uţivatele, kteří se pohybují mezi jednotlivými pracovišti a katedrami. Naopak sluţby, které jsou specifické pro určitou znalostní oblast nebo pro určitou skupinu zaměstnanců podle [Mitrano2010] agregovány zpravidla nejsou, a jsou proto poskytovány na místní úrovni. Sdílení souborů poskytované prostřednictvím cloudu je dalším typem aplikace, která byla dle [Gatewood2009] nabízena ve formě cloudu mezi prvními. Řešení pro sdílení souborů se liší v závislosti na typu úkolu, který má taková aplikace řešit. Můţe se jednat o ad hoc vytvářená úloţiště, ale můţe to být také velmi specifické řešení určené pro definovanou podnikovou jednotku či oddělení.

4.4 NAPLNĚNÍ PODMÍNEK BCM NA CLOUD COMPUTING ŘEŠENÍ V kapitole 3 Vazba Cloud Computingu na Business Continuity Management jsou uvedeny tři poţadavky a jeden předpoklad, které klade BCM na řešení Cloud Computingu. V následujícím textu je nejprve vysvětlen předpoklad řízení rizik v kontextu problematiky institucí terciárního vzdělávání, poté následuje popis jednotlivých poţadavků P01 - P03.

4.4.1 PŘEDPOKLAD – ŘÍZENÍ RIZIK K tomu, aby instituce rozhodla, zda je vhodné určitou sluţbu přesouvat do cloudu, je nutné, aby byl kladen důraz na řízení rizik. V rámci tohoto procesu je nejprve nutné provést základní test. Tento test spočívá v následujícím postupu [Mitrano2010]: Po provedení cost-benefit analýzy (porovnání nákladů a přínosů) a analýzy vhodnosti (posouzení dopadu na uţivatele, zaměstnance, zajištění IT atd.) je třeba zváţit, zda sluţba, která má být přesunuta do cloudu, nenaruší schopnost podniku řídit sluţby, které podporují jeho klíčové procesy. Toto riziko by mělo být řešeno jak z hlediska sluţby samotné, tak z hlediska vlivu na ostatní sluţby, které buď byly přesunuty do cloudu, nebo které zůstávají v prostředí instituce.

-44/117-



Proces řízení rizik je stejně důleţitý jako samotné odpovědi, které by měly být jeho výstupem. Tento proces mnohé vypovídá o koordinaci myšlení vyššího managementu instituce. Je nezbytné, aby proces řízení rizik byl v instituci vybudován a řízen. Nutnost tohoto procesu můţe být ustanovena také v politice upravující správu cloudových sluţeb, neboť je nutné, aby rizika byla řízena nejen z pohledu jedné cloudové sluţby, ale také z pohledu celku.

4.4.2 POŽADAVEK P01 BEZPEČNOST A MONITORING V následujícím textu je uvedeno osm nejdůleţitějších sporných otázek týkajících se bezpečnosti, které by měly být předmětem jednání před adopcí jakékoli cloudové sluţby v sektoru terciárního vzdělávání. [Vogel2010b] [Mitrano2010]: 

Důvěrnost dat a zajištění soukromí – instituce terciárního vzdělávání mají povinnost chránit data týkající se např. studentů a výzkumu. I kdyţ za data umístěná u poskytovatele odpovídá sám poskytovatel, je odpovědností instituce samotné zajistit takové smluvní podmínky, které by zaručovaly dostatečnou ochranu. Do dnešního dne stále platí, ţe přesunutí citlivých dat do cloudu znamená vznik potenciálně nového rizika. Těmito daty se v případě pohledu ze strany studenta rozumí: - data, která mají přímý vztah ke studentovi - data, která jsou udrţována vzdělávací institucí. a) předpisy – na základě smlouvy je po instituci vyţadováno dodrţovat všechny právní, technické a další poţadavky, b) krádeţ identity – instituce by měly mít nastaven proces, jak se vypořádat se situací v případě narušení, a to především ohledně otázek, kdo je povinen koho informovat o vzniklé situaci. Dalšími body procesu by mělo být testování narušení, určení technických kritérií pro ohodnocení a identifikace entity odpovědné za notifikaci a následný postup za účelem řešení vzniklé situace. c) soukromí uţivatelů – v prostředí Cloud Computingu, kdy jsou některé důvěrné informace poskytovány třetí straně, je povinností kaţdé instituce zajistit, aby veškeré poskytované informace byly důvěrné, a nedocházelo tak k narušení soukromí uţivatelů. Jako příklad lze uvést model SaaS, konkrétně vyuţívání emailových sluţeb od poskytovatele Google. Je známo, ţe společnost Google vyuţívá nad přijímanými a odesílanými zprávami data mining, na základě kterého je pak schopna nabízet uţivateli kontextovou reklamu. I kdyţ se společnost odvolává na to, ţe data mining probíhá zcela automatizovaně a anonymně, je třeba zváţit jisté bezpečnostní aspekty, mezi které patří např.: 



informace o tom, jaké techniky anonymizace, která odděluje uţivatele od získaných dat, jsou pouţívány,  zda společnost provádí data mining na základě klíčových slov či celých dotazů,  zda společnost spojuje/nespojuje tyto dotazy s jednotlivými uţivateli,  jakým způsobem společnost s takto získanými daty nakládá a jak zajišťuje jejich bezpečnost,  zda společnost neprodává získané informace,  jak dlouho udrţuje takto získaná data,  k jakým účelům jsou tato data pouţívána,  zda se společnost zavazuje tato data po určitém časovém okamţiku smazat. Prolomení důvěrnosti dat a jejich bezpečnost - pokud třetí osoba pronikne jakýmkoli způsobem k důvěrným datům, nese instituce terciárního vzdělávání primární odpovědnost za oznámení, ţe k takové situaci došlo, -45/117-



do této kategorie také spadají rizika spojená s duševním vlastnictvím - autorizace a duševní vlastnictví v drţení třetí stranou. E-discovery – instituce by měla nejprve provést tzv. cost-benefit analýzu, tedy porovnat náklady a přínosy řešení ještě předtím, neţ začne samotné vyjednávání podmínek s poskytovatelem. Je důleţité do analýzy zahrnout celé portfolio sluţeb odebíraných od poskytovatelů a porovnat takové portfolio s jakýmikoli technickými či procesními přístupy, které jsou v instituci uplatňovány. Výsledkem této analýzy jsou doporučení, do kterých oblastí by instituce měla více investovat (např. zvýšit výdaje na zálohování systémů a dat, na školení dotčených stran apod.). Service Level Agreement – instituce musí trvat na tom, aby byly jasně definovány úrovně poskytování sluţeb. Je potřeba určit, kolik času obě strany vyţadují k tomu, aby byla smlouva SLA implementována, a jaké existují pokuty v případě, kdy nebude stanovená úroveň sluţby dodrţena. Pozastavení/přerušení smlouvy – instituce by si měla předem zjistit, jak jsou stanoveny podmínky pro případ, kdy by se rozhodla pozastavit nebo přerušit dohodu o poskytování sluţeb. Je také nutné zváţit, kolik času by instituce v takovém případě potřebovala, aby mohla sluţby opět sama poskytovat nebo aby mohla změnit externího poskytovatele. Další otázkou, kterou je nutné zohlednit, je skutečnost, co se stane s daty instituce poté, co dojde k pozastavení nebo přerušení smlouvy s poskytovatelem. Na základě těchto úvah by potom měla být sestavena smlouva o odebírání sluţeb. Ohodnocení rizik – v této oblasti by měly být zvaţovány především následující skutečnosti: - odškodnění – odškodnění by mělo být zohledněno jak z pohledu odebírající instituce, tak z pohledu poskytovatele, - záruky – záruky vyplývají především ze stanovených Service Level Agreeements, - odpovědnost za koncové uţivatele – v uzavírané smlouvě musí dojít k přesnému definování toho, kdy a v kterých situacích kdo nese odpovědnost za koncové uţivatele, - porušení patentu – před uzavřením smlouvy by se instituce měla přesvědčit, zda procesy, postupy či zdroje jsou skutečně vlastněny poskytovatelem a zda nedochází k ţádnému střetu zájmů, který by v budoucnosti mohl ohrozit data instituce, - přenos rizik – v rámci sestavení SLA by mělo být definováno mimo jiné také to, zda jsou určitá rizika přenášena z odběratele na dodavatele a naopak. V případě, kdy by nastala neočekávaná situace, musí být jasně definováno, kdo je za tuto situaci odpovědný, - politiky a metody – pro určité oblasti by měly být definovány určité politiky, např. pro produkty, které uchovávají citlivá uţivatelská data, by mělo být provedeno ohodnocení rizik. Toto ohodnocení by mělo být podchyceno v politice. Business Continuity – do oblasti Business Continuity patří otázky týkající se sestavení Service Level Agreement, kde by mělo být podchyceno, jakým způsobem má instituce k datům přístup, co se stane v případě výpadku sluţby a kdy dojde k obnovení sluţby apod. Dále do oblasti Business Continuity patří také záleţitosti týkající se pozastavení/přerušení smlouvy s dodavatelem (viz výše). Právní otázky a závazky třetích stran – poskytovatelé cloudových sluţeb si ze smlouvy volí svou vlastní jurisdikci. Je však vhodné tento přístup eliminovat a smlouvu uzavřít spíše podle existujících právních ustanovení. -













Do této oblasti lze zahrnout také právní úpravu týkající se grantů se zvláštními právními podmínkami.

-46/117-



4.4.3 POŽADAVEK P02 ZÁLOHOVÁNÍ A ARCHIVACE Zálohování a archivace patří k důleţitým poţadavkům Business Continuity. Protoţe instituce terciárního vzdělávání jsou velkými institucemi, lze předpokládat, ţe objem dat nutných k obnovení v případě krize bude značně velký. Díky rozšíření konceptu virtualizace je však moţné dnes zálohovat celé image nakoupených serverových instancí stejně jednoduše, jako je moţné zálohovat běţné soubory. Vedle zálohování poskytuje Cloud Computing také snazší řešení pro zajištění záloţního prostředí. Díky Cloud Computingu instituce získá znatelně levnější alternativu k běţně pouţívaným prostředím v komerčním sektoru typu hot site, cold site, mirrored site apod., které nejsou v oblasti terciárního vzdělávání běţně vyuţívány. V takovém případě stačí pouze replikovat data do záloţního prostředí a začít platit za vyuţívání tohoto prostředí aţ skutečně v okamţiku, kdy nelze pouţívat prostředí primární. Samotná replikace dat můţe probíhat na několika úrovních. Běţnou replikací je replikace na úrovni diskových polí.

4.4.4 POŽADAVEK P03 DOSTUPNOST SLUŽEB Studenti jsou specifickou skupinou zákazníků/uţivatelů informačního systému a konzumentů sluţeb, které jim instituce terciárního vzdělávání poskytuje. Postupem času se bude jednat o generaci, která vyrostla na širokopásmovém připojení k internetu a která snadno a rychle adoptuje nové koncepty. Mezi tyto koncepty patří například sdílení souborů, komunikace mezi členy týmu nebo fenomén sociální sítě. Vyuţitím Cloud Computingu získá instituce nespornou výhodu. Tím, ţe vyuţije cloudovou platformu, získá tak prostředí, ve kterém lze snadno integrovat běţně pouţívané aplikace, neboť tyto aplikace budou s postupem času stále častěji vyvíjeny pro potřeby Cloud Computingu, a to i zástupci z řad studentů. Tato skupina uţivatelů také klade vysoké nároky na dostupnost IT systémů instituce. Pro instituci je proto nejlepší, kdyţ jsou její systémy vysoce dostupné. Není však nutností, aby se o nepřetrţitý provoz systémů a aplikací starala sama instituce, ale je moţné vyuţívat sluţeb cloudových poskytovatelů, kteří by vysokou dostupnost automaticky zajišťovali.

4.5 DALŠÍ CHARAKTERISTIKY SEKTORU COMPUTINGU JAKO NÁSTROJE BCM

TERCIÁRNÍHO VZDĚLÁVÁNÍ PRO VYUŽITÍ

CLOUD

V případě institucí terciárního vzdělávání se vedle výše uvedených poţadavků setkáme také s řadou specifik, pro která je moţné vyuţít konceptu Cloud Computingu za současného přispění ke zlepšení Business Continuity. Tyto charakteristické rysy jsou představeny v následujícím textu.

4.5.1 SP01 SEZÓNNOST Provoz IT systémů institucí terciárního vzdělávání se vyznačuje charakteristickou sezónností, kdy dochází k nerovnoměrnému zatíţení informačních systémů v průběhu akademického roku. První skutečnost platí pro celý sektor školství. Je jí období letních prázdnin. IT systémy jsou tak v průběhu července a srpna vytíţeny daleko méně neţ ve zbytku akademického roku. Opakem, kdy jsou IT systémy naopak vytíţeny hodně a v některých případech i přetíţeny, jsou období přihlašování studentů na zkoušky, období promocí, období registrací předmětů apod. Tyto výkyvy je moţno účinně řešit prostřednictvím Cloud Computingu a dopředu zajistit vyšší kapacitu infrastruktury právě pro tato období. Instituce by tak nemusela vydávat vyšší výdaje na -47/117-



dodatečné technologické zdroje a současně by uspokojila poptávku ze strany studentů a zaměstnanců školy.

4.5.2 SP02 ZÁVISLOST NA IT U institucí terciárního vzdělávání je velmi patrný nárůst postupné závislosti na IT technologiích. Oproti společnostem komerčního sektoru je na instituce terciárního vzdělávání kladen větší tlak na nákup kvalitního IT vybavení jak pro výuku, tak i do počítačových studoven pro studenty. Výjimkou není ani pořizování nejnovější techniky do laboratoří nebo pracovišť s multimédii. Z tohoto důvodu by kaţdá instituce měla zvaţovat, zda není moţné šetřit na místech, kde to lze. Jednou z takových moţností je Cloud Computing, kdy například díky modelu Infrastructure-as-aService je instituci umoţněno ušetřit na technologické infrastruktuře a vyuţívat modelu virtualizovaných serverů, na kterých běţí samotné aplikace instituce.

4.5.3 SP03 KONKURENČNÍ TLAK Ani instituce terciárního vzdělávání nejsou výjimkou, i v tomto oboru panuje vysoká konkurence. Především v posledních několika letech s nárůstem soukromých vysokých škol a se vzrůstajícím zájmem studentů středních škol pokračovat ve svém vzdělávání na vysoké škole, je cílem kaţdé univerzity získat pro sebe „ty nejlepší“ studenty, a vychovávat tak elitu. Díky tomuto konkurenčnímu tlaku rostou výdaje na potřebné vybavení a na výstavbu nových budov/učeben/zařízení tak, aby instituce mohly konkurovat v boji o nové studenty. Skrze Cloud Computing je instituce schopna ušetřit v nákladech na IT infrastrukturu (viz výše).

4.5.4 SP04 INOVACE Instituce terciárního vzdělávání by měly jít příkladem v inovacích ostatním odvětvím ekonomiky. Není tomu tak bohuţel u českého školství, ale ve světě lze nalézt mnoho případů, kdy univerzity, které disponují řadou nadprůměrně chytrých studentů, jsou také předními inovátory ve společnosti. Stejně tak by univerzity měly vytvářet prostředí pro to, aby se inovativní myšlenky mohly dále rozvíjet. Pro tyto účely je koncept Cloud Computingu otevřený.

-48/117-



5 POTENCIÁL BCM A CLOUD COMPUTINGU V PODMÍNKÁCH VŠE PRAHA Tato kapitola navazuje na závěry předchozích kapitol, bere v úvahu specifika prostředí Vysoké školy ekonomické v Praze a hledá nejvhodnější Cloud Computing řešení, která by zároveň přispívala ke zlepšení Business Continuity. Z tohoto důvodu jsou v této kapitole postupně podrobněji představeny koncepty Infrastruktura jako sluţba, virtualizace a tvorba privátních cloudů. Kombinace těchto přístupů můţe instituci přinést řadu výhod, neboť tento koncept slibuje revoluci v poskytování distribuovaných softwarových sluţeb. [Konstantinou2009] Díky souboru rozhraní, která jsou poskytována IaaS cloudy, jsou řízeny virtuální stroje, a dochází tak k podstatnému sníţení komplexnosti zajišťování sluţeb.

5.1 POPIS SOUČASNÉHO STAVU Prvním krokem k rozpoznání současného stavu na Vysoké škole ekonomické (dále jen VŠE) je identifikace uţivatelů IS/ICT. Mezi uţivatele patří následující skupiny [VSE2010]:         

studenti, potenciální studenti, účastníci celoţivotního vzdělávání, management VŠE, managementy fakult, učitelé, vědečtí pracovníci, administrativní pracovníci, externí uţivatelé knihovny, absolventi VŠE.

Správa IS/ICT je na VŠE soustředěna do několika útvarů. Hlavním útvarem je Výpočetní centrum (viz kapitola 5.1.3) a Centrum informačních a knihovnických sluţeb CIKS. CIKS zajišťuje informační podporu výuky, vědy a výzkumu na VŠE. Tento útvar řeší především otázky týkající se analýzy informačních potřeb všech cílových skupin VŠE. CIKS je hlavním útvarem, který podporuje vědeckou činnost na VŠE. CIKS dále spolupracuje s Výpočetním centrem VŠE v napojení informačních systémů CIKS na informační systém školy. Zároveň se CIKS podílí na tvorbě a realizaci informační strategie VŠE.

5.1.1 SWOT ANALÝZA Pro informatické útvary byla vypracována SWOT analýza. Tato analýza je uvedena v Příloha A – SWOT analýza informatických útvarů. Ze SWOT analýzy jsou dobře patrné slabé stránky VŠE a příleţitosti. V následujícím textu bude mimo jiné brán zřetel na minimalizaci slabých stránek pomocí maximalizace vyuţití příleţitostí. V rámci SWOT analýzy byly definovány tyto charakteristiky [VSE2010]: 

silné stránky - výsledky dosaţené v minulých letech – do této oblasti spadá implementace studijního informačního systému ISIS, nová organizace a nové sluţby v rámci webhostingu, stoprocentní pokrytí areálu VŠE bezdrátovou sítí, podpora pouţívání mobilních telefonů a datových sluţeb přes mobilní operátory, - stabilní prostředí s velkou společenskou prestiţí, - dobré jméno a prestiţ CIKS ve vědecké komunitě, - velmi dobré hodnocení WWW stránek školy na mezinárodní úrovni.

-49/117-









slabé stránky - platové podmínky v resortu školství, - neexistence procesů pro řízení informatiky ve všech oblastech, - roztříštěnost technického a programového vybavení, - absence jednotného systému pro řízení identit (IAM), - neexistence nástrojů pro zvýšení spolupráce pedagogů a vědeckých pracovníků. příleţitosti - získávat zdroje financování pro velké koncepční investice z fondů rozvojových projektů a grantů vypisovaných MŠMT, CESNET apod., - rozvíjet zkušenosti a odborné znalosti v rámci spolupráce se zahraničními univerzitami, - vyuţívat sluţeb CESNET, PASNET a EUNIS, - vyuţívat slev pro školy, - zapojení do konsorciálních projektů na informační zdroje. hrozby - zaostávání za českým i celosvětovým vývojem způsobené poklesem investic do IS/ICT, - problémy se získáváním kvalifikovaných pracovních sil z důvodu limitujícího systému odměňování, - zastarávání informačních technologií, které můţe vést ke sníţení kvality poskytovaných sluţeb, - neuváţený, neefektivní outsourcing, - pořizování licencí a sluţeb za úplatu se závazkem dalších pravidelných plateb za údrţbu, - konec systému financování elektronických informačních zdrojů prostřednictvím programů MŠMT v roce 2011, - rozsáhlost a specifičnost studijního informačního systému.

5.1.2 PROCESNÍ MAPA VŠE Na VŠE jsou v současné době podle [Trcka2009] aktivity zajišťovány pomocí pěti klíčových procesů, z nichţ jeden zastřešuje čtyři zbývající. Vedle těchto hlavních procesů instituce řídí dalších šest procesů podpůrných. Procesy zajištění výuky na VŠE jsou znázorněny na Obr. 8. Náplň jednotlivých procesů lze popsat takto [Trcka2009]: Klíčové procesy: 

Strategický rozvoj VŠE – tento proces zastřešuje ostatní klíčové procesy, jeho cílem je analýza stavu a dalšího moţného rozvoje ostatních procesů. o Zajištění studia – tento proces zajišťuje studijní proces, který sestává z následujících kroků:  Příprava podmínek zajištění studia  Přijímací řízení  Zápis ke studiu  Podpora studia  Graduace  Práce s absolventy Tento proces je zajišťován studijním informačním systémem (ISIS). -50/117-



Rozvoj vědy a výzkumu – tento proces podporuje vědu a výzkum, např. udělování grantů, finanční řízení, publikační činnost apod. o Podpora a rozvoj hospodářské činnosti – tento proces zajišťuje doplňkové činnosti VŠE, mezi které patří např. ubytování a stravování, nájmy, sluţby apod. o Zajištění mezinárodních aktivit a vztahů – cílem tohoto procesu je podpora agendy mezinárodních vztahů, např. výměnné pobyty nebo výuka externistů ze zahraničí. o

Hlavní procesy Strategický rozvoj VŠE

Zajištění studia

Rozvoj vědy a výzkumu

Podpora a rozvoj hospodářské činnosti

Zajištění mezinárodních aktivit a vztahů

Podpůrné procesy Koordinace a řízení rozvojových programů

Řízení ekonomiky

Zajištění administrativy

Řízení lidských zdrojů

Řízení a provoz informačního systému

Zajištění účetnictví a provozu školy

Obr. 8 - Procesní model VŠE (Zdroj: Autor, vytvořeno na základě [Trcka2009])

Podpůrné procesy: o o o o o o o

Koordinace a řízení rozvojových programů Řízení ekonomiky Zajištění administrativy Řízení lidských zdrojů Řízení a provoz informačního systému Zajištění administrativy Zajištění účetnictví a provozu školy

5.1.3 VÝPOČETNÍ CENTRUM O chod výpočetní techniky se na VŠE stará výpočetní centrum. Toto centrum je jedním z útvarů VŠE, které například v otázkách připojení univerzity do sítě internet spolupracuje se správou sítě PASNET (Prague Academic and Scientific NETwork). Kromě připojení univerzity k síti internet výpočetní centrum zabezpečuje následující činnosti [VSE2010]:      

koordinace zavádění jednotlivých komponent informačního systému VŠE, navrhování a realizace koncepce rozvoje IS/ICT na VŠE, vývoj informačních systémů univerzity, rozvoj a správu lokální počítačové sítě a síťové infrastruktury, provoz hlavních serverů, archivaci dat a instalaci programového vybavení, provoz počítačových učeben a studoven, -51/117-


 


konzultační sluţby uţivatelům výpočetní techniky, opravy, údrţba, inovace a další rozvoj výpočetní techniky.

5.1.4 TECHNOLOGICKÁ INFRASTRUKTURA VŠE provozuje rozsáhlou lokální počítačovou síť, která je napojena prostřednictvím praţské metropolitní sítě PASNET a sítě CESNET2 do internetu. V areálech školy je také provozována bezdrátová síť Eduroam, která jako součást mezinárodní bezdrátové sítě poskytuje připojení uţivatelům napříč celou Evropou. Otázky bezpečnosti jsou na VŠE řešeny pomocí dvou firewallů (Cisco provozovaný oddělením síťové infrastruktury a aplikační firewall CheckPoint provozovaný správou lokální sítě, viz [VSE2010]). Na VŠE jsou provozovány servery na různých hardwarových architekturách (nejčastěji sparc a opteron). V současné době Výpočetní centrum spravuje téměř 100 serverů a CIKS několik dalších. [VSE2010] Přehled serverů provozovaných na VŠE včetně operačních systémů je uveden v Příloha B – Seznam serverů provozovaných na VŠE. Servery s operačním systémem Novell Netware 6.5 a sluţbou eDirectory poskytují síťové sluţby uţivatelům (např. jmenná sluţba, autorizace, diskový prostor). Vedle těchto serverů jsou na VŠE provozovány aplikační servery, nejčastěji běţící na operačním systému typu Unix (Linux, Solaris), Novell Netware a Windows 2000/2003 Server. Pro zajištění podnikové kontinuity jsou servery napojeny na dieselový agregát, který je schopen obnovit chod serverů do tří minut od výpadku dodávky elektrické energie. Pro snazší správu a pro lepší zajištění Business Continuity v případě problému jsou klíčové servery (studijní agendy a ekonomické systémy) podle [Trcka2009] vybaveny kartami pro vzdálenou správu, díky nimţ je moţné ovládat server na dálku i na nejniţší systémové úrovni. Tento přístup umoţňuje ovládat server, i pokud nereaguje na standardní volání na úrovni operačního systému (restart, vypnutí systému). Vybrané servery jsou centrálně zálohovány. Kompletní zálohy jsou prováděny jednou za týden. Inkrementální zálohy se provádějí na denní bázi, v případě studijního informačního systému kaţdé 4 hodiny. Zálohy vybraných serverů jsou ukládány na dedikované pracoviště, které je umístěno mimo hlavní areály univerzity. Zálohy jsou uskutečňovány nejprve na disková pole, následně na pásky. V současném objemu (pozn. informace z roku 2009) pásky obsahují data posledních 2 týdnů. [Trcka2009] Lze předpokládat, ţe tato doba se bude v budoucnu s rostoucím objemem dat zkracovat. Z hlediska dostupnosti jsou jednotlivé komponenty systému (servery, síťové prvky) monitorovány open-sourceovým softwarem. Tento systém informuje správce o výpadcích spravovaných zařízení nebo nenadálých situacích. Dle [Xymon2010] tento software poskytuje uţivatelům reporty o dostupnosti a grafy výkonnosti jednotlivých komponent. Další součástí technologické infrastruktury jsou počítačové učebny a studovny slouţící pro podporu vědy a výuky. Od roku 2001 rostl počet koncových stanic na počítačových učebnách a studovnách. Rok 2007 lze podle [VSE2010] z tohoto pohledu povaţovat za zlomový, neboť v tomto roce vzrostl podíl vyuţívání vlastních notebooků studentů připojených do počítačové sítě. K tomuto faktu přispěla také skutečnost, ţe došlo k zavedení bezdrátové sítě v prostorách VŠE, počítačové studovny začaly být méně vytěţovány, a proto bylo rozhodnuto o jejich jiném vyuţívání, např. testování studentů.

5.1.5 STUDIJNÍ INFORMAČNÍ SYSTÉM Studijní informační systém ISIS je na VŠE pouţíván od srpna roku 2008. Před uvedením do ostrého provozu musel být tento systém upraven podle specifik VŠE, jako jsou registrace a zápisy, vedlejší specializace, státní zkoušky apod. Implementace ISISu byla ukončena v roce 2009 a díky tomu, ţe se -52/117-



jedná o rozsáhlý systém, stal se dle [VSE2010] základním kamenem pro systémovou integraci dalších souvisejících oblastí. Mezi tyto oblasti patří rozhraní ISISu s ekonomickými a informačními systémy Odysea a iFIS a s knihovním systémem Aleph500. Tento systém nyní podporuje celý studijní proces tak, jak je uveden v kapitole 5.1.2. Nahradil tak jedenáct do té doby existujících samostatných aplikací. Vedle studijního procesu studijní informační systém zajišťuje také průběh podpůrných procesů [Trcka2009]:         

Manaţerské výstupy a hlášení externím subjektům, Podpora pro ubytování na koleji, Zpracování stipendií, Ţivotní cyklus vyučujícího, Anketa, Zajištění ediční činnosti, Zpracování poplatků za studium, Administrace ISIS, a další procesy pro podporu vědy a výzkumu (procesy plánování konferencí, evidence publikací, práce s granty), pasportizace (procesy pro evidenci areálů, lokalit, budov a místností).

5.2 VÝBĚR VHODNÉ VARIANTY CLOUDOVÉHO ŘEŠENÍ Jak jiţ bylo uvedeno v kapitole 2 Charakteristika Cloud Computingu v řízení organizace, rozeznáváme cloudy veřejné, soukromé a hybridní. Vyuţití těchto typů cloudů lze rozdělit podle velikosti organizace. Zatímco malé organizace (do 50-ti zaměstnanců) jsou relativně omezené svým rozpočtem a lidskými zdroji, a oceňují proto především fakt, ţe se nemusí o systémy starat samy a ţe počáteční investice jsou minimální, střední podniky (do 250-ti zaměstnanců) se budou zajímat o moţnosti efektivního vyuţití vlastních ICT prostředků a elasticitu vyuţívaných sluţeb a velké společnosti budou dle [Prodelal2010] klást důraz na efektivní údrţbu celé infrastruktury ICT a její optimalizaci. Naváţeme-li tuto úvahu na typologii cloudů, můţeme říci, ţe malé společnosti budou vyuţívat spíše veřejných SaaS cloudů, střední společnosti pak podle [Prodelal2010] soukromých nebo hybridních IaaS nebo PaaS cloudů a velké společnosti především soukromých IaaS cloudů. Z informační strategie VŠE [VSE2010] vyplývá, ţe zaručení poţadované dostupnosti aplikací a sluţeb, zajištění optimálního výkonu a zvládnutí výkonových špiček patří mezi priority budoucího rozvoje VŠE. Současně je kladen důraz na minimalizaci nákladů. Na tyto aspekty je následující text podrobněji zaměřen. Z úvahy o vztahu mezi velikostí společnosti a typem Cloud Computing řešení vychází i následná analýza situace a návrh vhodného řešení v podmínkách Vysoké školy ekonomické v Praze. Neboť VŠE patří svou velikostí mezi organizace velké, budou zohledňována především řešení IaaS, soukromého a hybridního cloudu a virtualizace.

5.3 INFRASTRUKTURA JAKO SLUŽBA Instituce terciárního vzdělávání můţe čerpat výhody ze všech modelů poskytování cloudových sluţeb. V případě, kdy se rozhodne vyuţívat infrastrukturu jako sluţbu, vyuţívá stroje, který je vlastněn dodavatelem a je umístěn v místě jeho působení. Instituce v takovém případě vyuţívá virtualizovaného serveru, na kterém jsou spuštěny její aplikace, a úloţiště v cloudu. -53/117-



Cloudová řešení tohoto typu nabízejí díky sdruţenému vyuţívání infrastruktury aţ 80% vyuţití IT zdrojů. [Feuerlicht2010] Podle některých odhadů (viz např. [Feuerlicht2010], [Litoiu2010]) kombinace moţnosti násobného vyuţívání zdrojů a umístění datových center do geografických oblastí s niţšími náklady na elektrickou energii, práci, pořízení majetku a daně sniţuje náklady na pořízení sluţeb 5 – 7 krát. V poslední době vzrostl o řešení IaaS zájem, a to díky výraznému sníţení nákladů na infrastrukturu díky modelu platby pay-as-you-go. Současné modely IaaS obvykle poskytují virtuální stroje (Virtual Machine), které jsou následně zákazníkem upravovány a spravovány. Protoţe umístění virtuálních strojů má podle [Lee2010] podstatný vliv na výkon aplikace, zůstává otázkou, zda jsou zdroje efektivně vyuţívány. Zatímco poskytovatel nemá informace o náročnosti hostované aplikace, uţivatelé IaaS řešení nemohou zasahovat do infrastruktury, která pod aplikacemi leţí. A tak dochází k tomu, ţe jsou zdroje alokovány bez ohledu na běţící aplikace a optimalizace probíhá na straně zákazníka pouze na aplikační úrovni. Tento nedostatek informací můţe být řešen jak na straně odběratele (různými metodami optimalizace výkonu aplikací), tak na straně poskytovatele, a to například formou vyţádání specifikace potřeb zákazníka, jeho poţadavků na zdroje a nejlepší moţné odhady budoucí spotřeby zdrojů. Další moţností jsou také řešení alokace zdrojů zaloţené na různých modelech, jako např. metoda zaloţená na topologii aplikací přestavená ve studii, která je výsledkem spolupráce Californské univerzity a laboratoří HP [Lee2010]. Jiní autoři (např. [Appavoo2010]) se přiklánějí k tomu, ţe k získání potřebné elasticity a dosaţení maximálního výkonu je potřeba přímý přístup k hardware, např. vyuţívání superpočítačů pro poskytování cloudové infrastruktury. V návaznosti na tuto neinformovanost odběratele je důleţité porozumět konceptu Cloud Computingu tak, aby byla instituce schopna modelovat ekosystém cloudových sluţeb vyuţívaných od různých poskytovatelů. Pro tyto účely bylo navrţeno několik modelů architektury ekosystému Cloud Computingu. Příklad takového modelu je uveden na Obr. 9. Tento model sestává z několika vrstev Cloud Computingu (IaaS, PaaS, SaaS), kdy ke kaţdé vrstvě jsou uvedeny příklady na trhu nabízených řešení. Na tomto obrázku je například ve vrstvě IaaS ve skupině „Zdroje“ uveden jako příklad řešení Amazon EC2. Zde se proto analogicky nacházejí řešení cloudových serverů porovnávaných v předchozí kapitole. Cloudová úloţiště poskytovaná k těmto serverovým řešením pak spadají do vrstvy „Základní infrastrukturní sluţby“, neboť poskytují pouze základní funkcionalitu úloţiště. [Lenk2009] Jak jiţ bylo uvedeno výše, tyto vrstvy budou hlavním předmětem zájmu této diplomové práce v otázkách návrhu budoucího řešení vyuţití Cloud Computing sluţeb v prostředí VŠE. Pro řízení infrastruktury odebírané jako sluţbu je moţné vyuţívat řešení, která jsou pro tyto účely určena. Pro ilustraci je tato řešení moţné nalézt na Obr. 9 v postranní dimenzi „Podpora businessu“. Příkladem takové platformy určené pro správu a řízení infrastruktury je enStratus. Toto řešení se zaměřuje na otázky governance, které společnost enStratus vymezuje takto [EnStratus2010]:      

Řízení bezpečnosti – správa uţivatelů, šifrování, správa klíčů Řízení financí – sledování nákladů, rozpočtování, kurzové rozdíly Audity a reporting Monitoring a upozorňování Automatizace – automatické změny velikosti úloţiště, správa zálohování, řízení změn Jednotná správa napříč řešeními různých poskytovatelů Cloud Computingu

-54/117-



Google Docs Aplikační služby Opensocial

Složené aplikační služby

Podpora businessu

Aplikace

Správa

SaaS

Základní aplikační služby

OpenID

PaaS Prostředí pro programování

Google App Engine

Prostředí pro realizaci

Google Bigtable

IaaS Nadstavbové infrastrukturní služby

GoogleFS

Základní infrastrukturní služby

Zdroje Amazon EC2

Virtuální zdroje Fyzické zdroje

Emulab

Účtování, autentizace, správa uživatel

Infrastrukturní služby

Vývoj, konfigurace, monitoring, řízení životního cyklu

Django

Hardware Obr. 9 - Architektura Cloud Computing řešení (Zdroj: [Lenk2009])

Právě taková řešení jako je enStratus společnostem pomáhají v následujících oblastech [EnStratus2010]:   

překlenutí obavy z bezpečnostních aspektů implementace Cloud Computing řešení, zaručení spolehlivosti a dostupnosti odebíraných sluţeb, poskytnutí řešení pro obnovu z havárie a Business Continuity.

Právě tyto oblasti byly v této práci jiţ v kapitole 3.3 vymezeny jako 3 nejdůleţitější kategorie poţadavků BCM na Cloud Computing řešení.

-55/117-



5.4 VIRTUALIZACE Fenomén virtualizace a Cloud Computing spolu úzce souvisejí. Virtualizace se jako koncept začala pouţívat ke sníţení nákladů na infrastrukturu, a to především díky moţnosti konsolidovat servery [Stratus2010]. Virtualizace tedy umoţňuje poskytování infrastruktury jako sluţby jako jednu z forem Cloud Computingu. Na druhou stranu však Cloud Computing koncept virtualizace rozšiřuje o něco dále. Z uţivatelského hlediska přináší výhodu v tom, ţe umoţňuje uţivateli vyhnout se vynakládání počátečních nákladů na pořízení infrastruktury. Tyto dva koncepty jsou proto z těchto důvodů velmi úzce spjaty. V době, kdy je prakticky vše v oblasti IT poskytováno jako sluţba (viz kapitola 2; koncept Anythingas-a-Service - XaaS), probíhá virtualizace na několika úrovních. Virtualizovány jsou jak fyzické zdroje, tak platformy i samotné podnikové aplikace [Lenk2009], [Litoiu2010]:   

vrstva infrastruktury nabízí úloţiště, CPU a paměť – tyto tři prvky jsou obvykle poskytovány jako virtuální stroj, vrstva platformy poskytuje aplikační a databázové servery a prostředí pro vývoj, testování a uvolnění aplikací. Tato vrstva typicky vyuţívá sluţeb poskytovaných vrstvou infrastruktury, vrstva software nabízí jednoduché nebo sloţené sluţby (aplikace), které jsou vyuţívány koncovými uţivateli.

Virtualizace je podle [Wolf2005] ve své podstatě abstrakce fyzických hranic technologie. Například pracovní stanice uţivatelů nebo servery nepotřebují ke své existenci fungovat jako samostatné jednotky, a nepotřebují tedy samostatný fyzický hardware, jako je CPU nebo základní deska. Namísto toho mohou běţet uvnitř virtuálního stroje, kde je hardware emulován a ve vztahu k operačnímu systému se chová jako běţný hardware. Vyuţívání virtuálních strojů v distribuovaném prostředí přináší řadu výhod. Mezi tyto výhody lze řadit následující [Assuncao2009] [Golden2008]:      

konsolidace serverů – původní počet ne zcela vyuţívaných serverů se můţe díky virtualizaci sníţit – dojde k efektivnímu rozloţení zátěţe mezi menší počet serverů, sníţení nákladů na provoz serverů – kaţdý server potřebuje být ke svému provozu napájen ze sítě elektrické energie. Konsolidací serverů dochází ke sníţení nákladů na elektrickou energii. moţnost vytvoření virtuálního stroje pro běh zastaralé aplikace, aniţ by tato aplikace narušovala API ostatních aplikací, zlepšení bezpečnosti díky moţnosti vytvoření samostatné instance pro běh aplikací s diskutabilní spolehlivostí, dynamické zajištění zdrojů, zvýšení výkonnosti aplikací například navýšením operační paměti serverů.

Virtualizace také minimalizuje některá rizika, která jsou neodmyslitelně spojená se sdílením IT zdrojů mezi více uţivateli, neboť zde dochází k přidání virtualizační vrstvy, na které lze monitorovat, zda nedochází k nějaké události, která by znamenala narušení bezpečnosti.

5.5 SOUKROMÝ CLOUD Soukromé, privátní neboli také interní cloudy jsou alternativou k veřejným cloudům pro velké společnosti s vysokým počtem zaměstnanců nebo specifickými poţadavky na poskytované sluţby či na zabezpečení dat, které nemohou být naplněny nabídkou veřejných cloudů. Především bezpečnostní otázky vedou dle [Hurwitz2010] společnosti ke zvýšenému zájmu o privátní, popřípadě hybridní cloudová prostředí. Dalším významným faktorem zájmu o interní cloudy je také -56/117-



situace, kdy společnosti jiţ investovaly významné prostředky v oblasti hardware, software a diskových prostorů, a proto by tyto investice chtěly zuţitkovat. Privátní cloud je infrastruktura, která umoţňuje uţivateli dosáhnout, konfigurovat a poskytovat zdroje datového centra za vyuţití automatizovaných samoobsluţných nástrojů a softwarových sluţeb, a to v rámci datového centra instituce. Privátní cloud umoţňuje dle [Eucalyptus2010a] vyřizovat několik simultánních ţádostí uţivatelů, a to automatizovaně bez nutnosti zásahu zaměstnanců. K naplnění těchto předpokladů jsou typicky vyuţívány virtuální stroje, které jsou buď předkonfigurovány pro specifické potřeby uţivatele, nebo mohou být customizovány samotným koncovým uţivatelem. Privátní cloud můţe být virtualizované datové centrum umístěné v prostředí organizace, chráněné jejím firewallem. Můţe se však také jednat o privátní prostor vymezený v datovém centru poskytovatele, který je schopen vypořádat se se zatíţením organizace. Charakteristiky privátního cloudu jsou následující [Hurwitz2010]:      

umoţňuje IT zajišťovat sluţby a výpočetní výkon pro interní uţivatele, a to samoobsluţným způsobem, automatizuje řízení úloh a umoţňuje účtovat jednotlivá oddělení pouze za sluţby, které opravdu vyuţívají, poskytuje řízené prostředí, optimalizuje vyuţití výpočetních zdrojů, např. serverů, podporuje specifické pracovní zatíţení, poskytuje samoobsluţné zajištění hardwarových a softwarových zdrojů.

Lze říci, ţe tyto charakteristiky jsou obdobné, jako tomu je u cloudů veřejných. Podstatný rozdíl mezi těmito dvěma typy cloudů však spočívá v kontrole nad prostředím, která je v případě interních cloudů v rukou samotné organizace nebo důvěryhodného partnera. To však není jediným důvodem, proč se společnosti rozhodují pro zřízení privátního cloudu. Lze si představit situaci, kdy společnost investovala do své vlastní technologické infrastruktury, a vlastní tedy datové centrum, jehoţ kapacita však není plně vyuţita. V takovém případě je pro organizaci finančně výhodnější, pokud se rozhodne vyuţívat toto datové centrum jako poskytovatele privátního cloudu. I za předpokladu, ţe bude muset pro tyto účely pořídit nový software, je tato varianta dle [Hurwitz2010] výhodnější oproti alternativě vyuţívání veřejného cloudu. Dosaţení plné účinnosti z vybudovaných privátních cloudů vyţaduje změnu činností a odpovědností jak koncových uţivatelů, tak zaměstnanců IT oddělení. Ze strany koncových uţivatelů je vyţadována schopnost a znalost ovládání prostředí pro samostatné obstarání zdrojů. V případě privátních cloudů, kdy proces přidělování zdrojů probíhá automaticky, je uţivateli namísto souboru fyzických serverů přiřazen soubor virtuálních strojů. V některých případech privátní cloud nedosahuje dostatečné elasticity. Důvodem k tomu je fakt, ţe na rozdíl od cloudů veřejných, v rámci jedné společnosti existuje pouze jedna špička ve smyslu vytíţení informačních systémů. Velmi pravděpodobně v rámci privátního cloudu budou uţivatelé přistupovat také k jedné jediné aplikaci [Hapl2010]. To je v rámci veřejných cloudů řešeno jak tím, ţe datová centra poskytovatele jsou umístěna v odlišných geografických oblastech, tak také tím, ţe uţivatelé z různých geografických oblastí budou zatěţovat vyuţívané zdroje v jiné denní době. Tento nedostatek je moţné řešit také tak, ţe dočasný nedostatek kapacity interního cloudu bude vyrovnán sluţbou cloudu veřejného. Toto spojení řešení privátního a veřejného cloudu bývá nazýváno hybridním cloudem (viz kapitola 5.6). [Eucalyptus2010a] Řešení hybridního cloudu můţe být provedeno několika způsoby. Jedním ze způsobů je vyuţívání veřejného cloudu pouze dočasně, kdy -57/117-



jsou data v době maximálního vytíţení (např. v případě institucí terciárního vzdělávání ve zkouškovém období) přesunuta do veřejného cloudu. V tomto okamţiku začíná instituce vyuţívat sluţeb externího poskytovatele a začíná také za tyto sluţby platit. Poté, co pomine potřeba zvýšených zdrojů technologické infrastruktury, jsou data instituce přenesena zpět do privátního cloudu. K tomu, aby společnost dosáhla vybudování interního cloudu, potřebuje projít následujícími pěti kroky [Eucalyptus2010a]:   





implementace technologie virtualizace – v tomto kroku společnost musí vybrat virtualizační technologii, pomocí které budou poskytovány sluţby interním uţivatelům, vytyčení výpočetních a výkonnostních poţadavků, nároků na paměť a diskový prostor kaţdé aplikace, návrh vývoje virtuálních strojů – administrátoři privátních cloudů často nabízejí předdefinované virtuální stroje, ze kterých si uţivatelé mohou vybrat. Tyto předdefinované virtuální stroje musí být vyvinuty a zaneseny do aplikačního portfolia. Postupem času budou někteří uţivatelé chtít konfigurovat své vlastní virtuální stroje, ať uţ zcela nové, nebo dokonfigurováním předpřipravených image, ustanovit politiku účtování za vyuţívání sluţeb – na rozdíl od veřejných cloudů, u cloudů privátních se můţe IT oddělení setkat s tím, ţe uţivatel neuvolní zdroje, které jiţ nepotřebuje, nebo začne hromadit ty zdroje, které mu byly přiděleny. Protoţe v privátním cloudu nejsou uţivatelům sluţby účtovány přímo na základě vyuţívání sluţeb, je potřeba ustanovit takovou politiku, která by zajišťovala, ţe technologické zdroje budou účinně vyuţívány a nebude docházet k podobným neefektivním alokacím, navrhnout architekturu a rozmístění infrastruktury privátního cloudu – ideálně jsou privátní cloudy vysoce konfigurovatelné, takţe mohou vyuţívat výhod jiţ existující infrastruktury nebo infrastruktury speciálně určené pro vytvoření cloudu co nejúčinnějším způsobem.

5.6 HYBRIDNÍ CLOUD Hybridní cloudy hrají klíčovou roli při adopci Cloud Computingu, a to především ve velkých organizacích. S rostoucí oblibou hybridních cloudů u organizací roste také potřeba zjednodušení návrhu takových struktur. Z tohoto důvodu vznikají nástroje, které jsou schopny sjednotit komerční řešení s řešením in-house. Takovým řešením je rozhraní, které je schopno sjednotit odlišné fyzické zdroje a jednotně poskytovat sluţby koncovému uţivateli. Rozhraní se skládá z výpočetních jednotek, přepínačů a jednotek s úloţným prostorem. Jednotky jsou spojeny základní deskou a vysokorychlostním spojením. [Furht2010] Nad touto společnou virtualizační vrstvou jsou typicky vystavěny aplikace pro správu, kam patří zajištění sluţeb, účtování, zabezpečení, dynamická alokace zdrojů apod. Systém pro správu virtuálních strojů odpovídá za řízení virtuální infrastruktury jako celku, a to tím, ţe poskytuje základní funkcionalitu pro vývoj, správu a monitorování virtuálních strojů v distribuovaném prostředí. Vyuţitím této vrstvy pro správu virtuálních strojů instituce dle [Montero2010] docílí toho, ţe výpočetní zdroje budou odděleny od své fyzické infrastruktury, a tím rozšíří původní benefity virtuálních strojů aţ na úroveň výpočetních clusterů (tj. jejich konsolidace, osamostatnění, rozdělení a dosaţení pruţné výpočetní kapacity). Pro účely VŠE by bylo vhodné ve vrstvě pro správu virtuálních strojů jak vlastních, tak i externích dodavatelů vyuţívat open sourceových prostředků, neboť cílem VŠE je také sniţování nákladů na infrastrukturu. Jak bylo zjištěno z rozhovoru s útvarem Výpočetního centra, VŠE má jiţ v současné době zkušenosti s vyuţitím open sourceových řešení, a nebyla by to tedy první zkušenost s tímto typem licencování softwaru. -58/117-



Zjednodušená struktura takového hybridního cloudu je schematicky znázorněna na následujícím obrázku. Uživatelé

Virtuální infrastruktura

Vrstva služeb IaaS software pro hybridní cloud

Fyzická infrastruktura

Univerzita

Poskytovatel cloudových služeb

Vrstva infrastruktury Obr. 10 - Zobrazení hybridního cloudu (Zdroj: Autor)

Lze uvaţovat, ţe princip hybridního cloudu bude ideálním Cloud Computing modelem pro většinu organizací, neboť představuje spojení výhod privátního a veřejného cloudu. [Mather2009] Díky tomuto spojení je moţné kritická data uchovávat v rámci privátního interního cloudu, kde má organizace celkovou kontrolu nad bezpečností dat, výkonností, řízením apod. Díky veřejnému cloudu potom můţe organizace vyuţívat sluţeb umístěných mimo organizaci pro data a sluţby, které nejsou kritické a integrovat tato řešení do své infrastruktury. V rámci hybridních cloudů můţe společnost také přemisťovat data z prostředků umístěných ve veřejném cloudu do prostředků v rámci společnosti a naopak. Zajištění bezpečnosti přenosu dat můţe být dle [Stenzel2010] realizováno několika různými metodami, jako je například šifrování dat nebo virtuální privátní sítě VPN. Příkladem, kdy se společnost rozhodne vyuţívat hybridního cloudu, můţe být situace, kdy vyuţívá systému CRM umístěného ve veřejném cloudu a zároveň ERP systému umístěném v cloudu interním. [Hugos2010] V budoucnu je relativně jednoduché takové řešení rozšířit například o nástroje spolupráce a komunikace mezi zaměstnanci.

5.7 VYUŽITÍ CLOUD COMPUTINGU PRO VÝUKU Cloud Computing jako vyvíjející se koncept má vysoký potenciál pro výuku studentů oboru informační technologie. Tito studenti jsou stejně jako všichni technicky zaměření studenti motivováni k objevování a uţívání nových technologií. Uţ jen z tohoto důvodu je moţné předpokládat, ţe koncept práce v „cloudu“ bude mezi studenty vítán. Podstatnou výhodou Cloud Computingu je však také to, ţe díky tomuto přístupu je pro instituci moţné zajistit studentům pohodlný přístup k technologickým zdrojům odkudkoli. Je tak moţné například díky virtualizaci zpřístupnit některé aplikace či databázové systémy, které byly doposud dostupné -59/117-



pouze z určité lokality. Je také moţné počítat s tím, ţe koncept Cloud Computingu se v následujících letech rozšíří, a společnosti budou proto poptávat zaměstnance, kteří budou mít s tímto konceptem zkušenosti. [Holden2009]

5.8 CLOUD COMPUTING A OPEN SOURCE Koncept Cloud Computingu zaznamenal od svého vzniku řadu evolučních změn. Nejprve existoval Cloud Computing v podobě veřejných cloudů, kdy byly uţivatelům nabízeny veřejně dostupné sluţby. Stejně tak, jak je však v informačním světě společností zapotřebí interních sítí (například intranetu oproti internetu), vznikla i potřeba interní/privátní obdoby veřejného cloudu. K tomu, aby však mohla být dosaţena určitá úroveň řízení IT infrastruktury, je potřeba, aby platforma, na které jsou principy Cloud Computingu implementovány, byla transparentní. [Eucalyptus2010b] To znamená, ţe platforma privátního cloudu nemůţe zastínit ţádnou jiţ existující vrstvu hardwarové nebo softwarové infrastruktury, aniţ by ve stejném okamţiku neposkytovala zabezpečené a řízené prostředí pro koncové uţivatele. [Nair2009] Například není dostačující, aby pouze skutečnost, ţe uţivatel má přístup do intranetu společnosti, mu automaticky umoţňovala přístup do privátního cloudu. Je potřeba, aby byla na úrovni privátního cloudu řešena autentizace uţivatel. Zajištění takové transparentnosti je moţné dosáhnout vyuţíváním open sourceových řešení. Díky tomu, ţe open-sourceová řešení jsou vyvíjena komunitou a jejich zdrojový kód je veřejně dostupný, není chování těchto řešení záhadou pro IT personál instituce, která je vyuţívá. Mimoto k opensourceovým řešením je běţnou záleţitostí také existence veřejně dostupných diskuzí, kde lze nalézt vhodná řešení, a to i například od dodavatele třetí strany. S open source systémy jsou spojena také zajímavá zjištění oblasti bezpečnosti. Zatímco zpočátku se věřilo, ţe open-source platformy jsou náchylné k útokům z důvodu otevřeného přístupu, s postupem času, jak se vyvíjel tento koncept a jeho uţivatelé, se ukázalo, ţe opak je pravdou. Otevřený přístup ke zdrojovému kódu naopak umoţňuje IT specialistům vyvinout účinná opatření proti moţným útokům zvenčí. Naopak proprietární platformy jsou pak podle [Eucalyptus2010b] proti útokům zvenčí mnohem více zranitelné. Často se setkáme s ne zcela přesným tvrzením, ţe implementace open source software nutně vede společnosti ke sníţení nákladů. Sníţení nákladů totiţ není jediným a nejdůleţitějším důvodem, proč by se instituce měla rozhodnout pro vyuţívání open sourceových řešení. Open source software přináší firmám řadu konkurenčních výhod, které lze shrnout v následujících bodech [Noska2010]: 



  

bezpečnost – díky otevřenosti konceptu má ke zdrojovému kódu přístup více vývojářů, kteří tak mohou rychleji odhalit bezpečnostní rizika a zároveň implementovat opatření k jejich minimalizaci, kvalita – na open sourceových řešeních pracují tisíce vývojářů a výsledná funkcionalita můţe pravděpodobně lépe naplnit poţadavky jednotlivých odběratelů. A to jednak proto, ţe je pravděpodobné, ţe stejný nebo podobný problém, který má jedna společnost, jiţ řešila jiná společnost v minulosti, a proto existuje pro tento problém řešení. Dalším důvodem oblíbenosti open source software je technická nadřazenost odebírající firmy, customizace – díky moţnosti volného upravování zdrojového kódu získává společnost důleţitý prostředek vysoké customizace software, a to navíc vlastními silami, svoboda – společnost logicky ztrácí závislost na určitém dodavateli software a do jisté míry můţe ovlivňovat, co od software poţaduje, flexibilita – společnost není nucena provádět upgrade hardware a software podle dodavatele, ale pouze v případě, kdy to vyţaduje sama, -60/117-






 




interoperabilita – open source software vyuţívá často otevřených standardů pro komunikaci. Takový software tedy např. nepouţívá individuální formát dat, a je proto snazší vzájemná interoperabilita s jinými společnostmi vyuţívajícími jiný software zaloţený také na otevřených standardech, moţnosti prověření – tato výhoda úzce souvisí s výše zmíněnou bezpečností a podporou standardů. Na rozdíl od proprietárního řešení, u open source software se uţivatel můţe sám přesvědčit o tom, jakým způsobem jsou tyto otázky řešeny, moţnosti podpory – obvykle platí, ţe open source jako řešení je dodáváno zdarma a odběratel platí za podporu nebo vyuţívá aktuální a podrobné online dokumentace, různá fóra apod., celková cena – obecně platí, ţe celková cena za pořízený open source software je niţší neţ v případě proprietárního software. Je však potřeba zváţit, zda např. odborné zaškolení vlastních zaměstnanců pro open source software nebude v konečném důsledku draţší neţ nákup proprietárního řešení, moţnost vyzkoušení všeho před pořízením – ve většině případů si společnost můţe vyzkoušet plnou verzi řešení před tím, neţ se rozhodne ho skutečně vyuţívat, a to bez jakýchkoli závazků. S tím se v případě proprietárních řešení běţně nesetkáme.

5.9 POHLED ODDĚLENÍ VÝPOČETNÍHO CENTRA VŠE V rámci získání aktuálního pohledu na problematiku Business Continuity Management a Cloud Computing na VŠE bylo osloveno Výpočetní centrum. Pro schůzku se zástupci Výpočetního centra byla sestavena struktura rozhovoru uvedená v příloze Příloha C – Struktura rozhovoru se zástupci Výpočetního centra VŠE. Výsledky tohoto rozhovoru jsou uvedeny v následujícím textu této kapitoly. Samostatné podkapitoly obsahují informace týkající se specifických poţadavků BCM na Cloud Computing řešení, které byly stanoveny v kapitole 3. Výpočetní centrum VŠE vypracovalo v tomto roce informační strategii pro VŠE. Tato strategie je nyní v připomínkovém řízení, po zapracování připomínek se očekává její vydání. V této strategii jsou mimo jiné uvedeny také strategické cíle VŠE v oblasti IT pro období 2011 - 2015. V době psaní této diplomové práce bylo pracováno s verzí 1.2 informační strategie před jejím oficiálním vydáním.

5.9.1 P01 BEZPEČNOST A MONITORING Monitoring komponent v systému je v současné době realizován monitorovacím systémem zaznamenávajícím především výpadky sluţby. V případě výpadku sluţby je potom administrátor o aktuálním stavu informován komunikačními kanály, jako je email nebo textová zpráva. Tento monitorovací systém poskytuje také webové rozhraní, pomocí kterého je moţné zjistit aktuální stav všech monitorovaných komponent v systému. Součástí tohoto systému je také logování komponent, ze kterého je moţné identifikovat, co se se systémem ve skutečnosti děje. Bezpečnostní monitoring probíhá na úrovni informačního systému. Například u studijního informačního systému ISIS jsou monitorovány jakékoli útoky zvenčí. Informace o útocích jsou potom pomocí GMS brány předávány operátorům.

5.9.2 P02 ZÁLOHOVÁNÍ A ARCHIVACE Záloţní lokalita pro VŠE jako taková neexistuje. V minulosti VŠE provozovala duplicitní serverový sál v areálu školy na Jiţním Městě. Od tohoto modelu se ale jiţ upustilo. Namísto toho má serverový sál v areálu VŠE Ţiţkov implementována silná protipoţární opatření, která by měla zabránit fyzickému zničení serverů v případě vypuknutí poţáru v budově školy.

-61/117-



Před 2 - 3 roky VŠE oslovilo několik komerčních firem s nabídkou externího datového úloţiště. Tyto nabídky by byly pro školu zajímavé a ráda by je vyuţívala, nakonec však byly zamítnuty, a to z toho důvodu, ţe všichni poskytovatelé nabízeli kromě datového úloţiště také další dodatečné sluţby, o které VŠE neměla zájem. Kaţdodenní zálohování dat vybraných serverů však probíhá. Servery, na které záloha probíhá, jsou umístěny v lokalitě Jarov. Ve stejné lokalitě probíhá také archivace dat, a to na pásky. Důleţité servery VŠE jsou tedy zálohovány jednotným centrálním způsobem s vyuţitím modelu Disk2Disk2Tape. [VC2010] Na otázku, zda by VŠE uvítala moţnost záloţního prostředí u jiné české univerzity, bylo odpovězeno, ţe tato moţnost by byla díky vysokorychlostnímu spojení pomocí sítě CESNET/PASNET mezi univerzitami proveditelná. V současné době se však nic podobného nerealizuje ani v rámci VŠE, ani u jiných českých univerzit.

5.9.3 P03 DOSTUPNOST SLUŽEB V současné době VŠE nevlastní plán Business Continuity. Kontinuita není v současné době řešena, neboť se neuvaţuje, ţe by sluţby bylo nutné poskytovat v reţimu 24/7. Tím se nerozumí, ţe by na VŠE sluţby nebyly poskytovány v reţimu 24/7, ale ţe ţádná sluţba není natolik kritická, aby musela být poskytována nepřetrţitě. Při výpadku konektivity sluţeb je systém nastaven tak, aby síťová cesta k serverům byla automaticky nastavena jiným směrem, a systémy tak mohly nadále fungovat. Pokud dochází k vysokému zatíţení určité sluţby, VŠE tuto situaci řeší raději nakoupením vlastní technologické infrastruktury, tedy z vlastních zdrojů. VŠE má díky nabídkám poskytovatelů IT natolik výhodné smlouvy na nové servery, ţe doposud neuvaţovala o nákupu sluţeb v cloudu. Jinému způsobu zajištění potřebné kapacity VŠE brání také smlouvy uzavřené s dodavateli serverů. Pokud by se ale VŠE rozhodovala, jakým způsobem platit za vyuţívané externí sluţby, volila by zřejmě model pravidelných plateb neţ model pay-as-you-go, neboť sluţby, které by takto vyuţívala, by musely být poskytovány v reţimu 24/7.

5.9.4 VIRTUALIZACE NA VŠE Zvláštní pozornost je na VŠE jiţ v současné době věnována virtualizaci. Virtualizace jako projekt na VŠE byl v době psaní této diplomové práce čerstvě spuštěn. Tento projekt byl podán na ministerstvo školství MŠMT a je v současné době projednáván. V rámci projektu se počítá s interní realizací, externí spolupráce na virtualizaci není uvaţována. Do dnešní doby se jedná zejména o virtualizaci serverů pro síťové tisky, do budoucna se počítá také s virtualizací části počítačů na posluchárnách. Problémem virtualizace počítačů na posluchárnách je však v tom, ţe asi na 50-ti % koncových zařízení není ze strany hardware umoţněno, aby na nich virtualizace mohla být provedena. Dalším krokem po virtualizaci počítačů na posluchárnách je očekávaná virtualizace koncových stanic umístěných na počítačových učebnách. Virtualizace serverů jednotlivých pracovišť (kateder, fakult) v současné době neprobíhá, avšak některé fakulty jeví o virtualizaci zájem jiţ dnes (např. Fakulta podnikohospodářská). Tyto katedrální a fakultní servery jsou nyní umístěny v předsálí serverového sálu a jejich virtualizací by došlo k podstatnému sníţení potřebné technologické infrastruktury.

-62/117-



Závěrem lze uvést, ţe VŠE by uvaţovala o zbudování interního cloudového řešení, o hybridním však doposud neuvaţovala. Poskytování cloudových sluţeb externím subjektům mimo VŠE by škola měla zájem, ale realizace takového modelu bude moţná aţ v budoucnu poté, co se model cloudového řešení podaří implementovat v interním prostředí.

-63/117-



6 ANALÝZA POSKYTOVATELŮ CLOUDOVÝCH ŘEŠENÍ NA TRHU V této kapitole je provedena analýza vybraných poskytovatelů řešení Infrastructure-as-a-Service, kteří by v následující kapitole mohli být vhodnými kandidáty pro návrh praktického Cloud Computing řešení. Sektor terciárního vzdělávání je oblastí, kde jednotlivé instituce typicky mají mnoho fyzických serverů, které však nejsou vyuţívány na 100%. Zároveň pro tento sektor platí určitá sezónnost, a to jednak ve smyslu většího zatíţení od září do června, ale také ve smyslu vysokých nároků na dostupnost ve zkouškovém období či v období státních zkoušek. Z těchto důvodů byli v této kapitole porovnáváni poskytovatelé IaaS, kteří jsou na trhu největšími hráči. Jak jiţ bylo uvedeno v kapitole 2 Charakteristika Cloud Computingu v řízení organizace, rozeznáváme tři základní modely poskytování sluţeb:   

Software as a Service Platform as a Service Infrastructure as a Service

Po zhodnocení nabídky na trhu a zváţení vyuţití tohoto srovnání pro budoucí analýzu zúţenou na podmínky Vysoké školy ekonomické (viz kapitola 5) byla srovnávána pouze řešení poskytovatelů nabízejících infrastrukturu jako sluţbu. Tato řešení spočívají v dodání infrastruktury (typicky ve virtualizovaném prostředí) pro výpočetní výkony, a umoţňují tak zlepšit její vyuţití. Zákazníci nakupují sluţbu zejména v podobě virtualizovaných serverů namísto toho, aby kupovali fyzické servery, datová centra či síťové vybavení. Sluţby jsou zákazníkům účtovány na základě pouţívání, zpravidla za kaţdou hodinu běhu nakoupené sluţby, někteří poskytovatelé nabízí svým zákazníkům také pohodlnou alternativu předplacení sluţby na měsíc dopředu.

6.1 VÝBĚR POSKYTOVATELŮ IAAS Při výběru vhodných kandidátů, které by bylo moţné vzájemně porovnat, byl kladen velký důraz na jejich nabídku. Podmínkou bylo, aby poskytovatel byl primárně zaměřen na nabízení infrastruktury, teprve dodatečně případně nabízel PaaS nebo SaaS. V další části této diplomové práce budou výsledky analýzy pouţity pro návrh optimalizace vyuţití pouţívaných serverů na Vysoké škole ekonomické, proto jsou primárním zaměřením právě sluţby poskytující infrastrukturu. Důvodem pro zúţení výběru byla v neposlední řadě také komplexnost konceptu Cloud Computing a praktická nemoţnost srovnávat řešení poskytovatelů napříč jednotlivými modely poskytování. Nesporným důvodem pro upřednostnění konceptu IaaS před ostatními modely poskytování sluţeb byla také skutečnost, ţe v této práci je kladen důraz na navázání konceptu Cloud Computing na Business Continuity Management. Vyuţití SaaS v podmínkách terciárního vzdělávání je sice moţné, avšak z hlediska udrţení kontinuity společnosti je mnohem zajímavější formou právě vyuţívání infrastruktury. Pro podrobnější analýzu poskytovatelů byly vybrány následující společnosti a jejich řešení:     

Amazon (Amazon Elastic Compute Cloud) ElasticHosts GoGrid (GoGrid Cloud Hosting) Rackspace Cloud (Rackspace Cloud Servers) ReliaCloud -64/117-



6.2 VÝBĚR KRITÉRIÍ PRO ANALÝZU Všichni tito dodavatelé nabízejí řešení, kterým si na trhu přímo konkurují. Orientují se na stejnou strukturu zákazníků a jejich řešení jsou si do jisté míry podobná. Pro hodnocení jejich produktů proto bylo moţné navrhnout strukturu kritérií uvedenou v tabulce Tab. 2. Kritéria byla rozdělena do tří hlavních kategorií, kterými jsou technické aspekty, aspekty BCM a aspekty finanční. Kritéria jsou v rámci jednotlivých kategorií dále podrobněji členěna do niţších celků. Jednotlivým kritériím byla přiřazena také váha. Z celkového počtu 13-ti kritérií bylo vybráno 5 kritérií, kterým byla přidělena vyšší váha neţ ostatním. První tři kritéria byla ohodnocena vyššími vahami z důvodu důleţitosti těchto kritérií nejen pro volbu cloudového poskytovatele, ale také z hlediska BCM. Tato kritéria vycházejí z identifikovaných poţadavků BCM na Cloud Computing řešení uvedených v kapitole 3.3. Tato kritéria byla proto definována následujícím způsobem:   

BCM001 Bezpečnost a monitoring BCM002 Zálohování BCM003 Garance SLA

Další dvě kritéria, kterým byla přiřazena vyšší váha, byla vybrána proto, neboť jsou důleţitá při rozhodování, zda je poskytovatel IaaS pro instituci vhodný či nikoliv. Tato kritéria jsou následující:  

TECH005 Podporovaný operační systém FIN001 Model financování

Kategorie kritérií

Název a označení

Váha kritéria

TECH001 Cloudové servery

0,07

TECH002 Cloudové úloţiště

0,07

TECH003 Webový ovládací panel

0,07

1.2 Vývoj a otevřenost

TECH004 API

0,07

1.3 Technické parametry

TECH005 Podporovaný operační systém

0,09

TECH006 Minimální velikost

0,07

TECH007 Maximální velikost

0,07

BCM001 Bezpečnost a monitoring

0,09

BCM002 Zálohování

0,09

BCM003 Garance SLA

0,09

FIN001 Model financování

0,08

FIN002 Způsob stanovení ceny

0,07

FIN003 Technická podpora

0,07

1. Technické aspekty 1.1 Typy poskytovaných řešení

2. Aspekty BCM 2.1 Bezpečnost 2.2 Smluvní ujednání 3. Finanční aspekty 3.1 Financování 3.2 Sluţby

Tab. 2 - Přehled srovnávaných kritérií (Zdroj: Autor)

V následujícím textu jsou podrobněji popsána jednotlivá kritéria a způsob jejich vyhodnocování.

-65/117-



6.3 POPIS VYBRANÝCH KRITÉRIÍ 6.3.1 TECHNICKÉ ASPEKTY V rámci technických aspektů byla hodnocena kritéria tří podřazených kategorií. Mezi tyto podkategorie patří:   

Typy poskytovaných řešení, kterými se rozumí typy poskytovatelem nabízených sluţeb a jejich moţnost správy a administrace, Vývoj a otevřenost hodnotí, zda poskytovatel umoţňuje svým zákazníkům vyuţívat otevřeného API či nikoliv, a Technické parametry, které klasifikují srovnávaná řešení na základě podporovaných operačních systémů, nabízené velikosti cloudových serverů apod.

6.3.1.1 TECH001 CLOUDOVÉ SERVERY V rámci tohoto kritéria je hodnoceno, zda poskytovatel nabízí své řešení ve formě cloudových serverů či nikoliv. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:  

0 – poskytovatel nenabízí cloudové servery 1 – poskytovatel nabízí cloudové servery

6.3.1.2 TECH002 CLOUDOVÉ ÚLOŽIŠTĚ Toto kritérium hodnotí, zda je v rámci poskytovaného cloudového serveru poskytováno také úloţiště a toto úloţiště není placeno zvlášť. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:  

0 – cloudové úloţiště není v rámci sluţby poskytováno 1 – cloudové úloţiště je poskytováno v rámci sluţby

6.3.1.3 TECH003 WEBOVÝ OVLÁDACÍ PANEL Tímto kritériem je hodnoceno, zda nabízené řešení poskytuje moţnost řídit vyuţívané instance cloudových serverů pomocí webového prohlíţeče, ve webovém ovládacím panelu. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:  

0 – řešení nezahrnuje webový ovládací panel 1 – řešení zahrnuje webový ovládací panel

6.3.1.4 TECH004 API V rámci tohoto kritéria je rozlišováno, zda dodavatel poskytuje k řešení API a zda je toto API otevřené. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:  

0 – API není poskytováno 0,5 – API je poskytováno, ale není otevřené -66/117-





1 – API je otevřené

6.3.1.5 TECH005 PODPOROVANÝ OPERAČNÍ SYSTÉM V rámci tohoto kritéria je hodnoceno, jak širokou škálu podporovaných operačních systémů dodavatel nabízí. Toto kritérium je důleţité při rozhodování, zda vyuţívat nabízeného řešení či nikoliv, proto mu byla přiřazena vyšší váha. Váha tohoto kritéria je 0,09. Kritérium je hodnoceno následujícím způsobem:    

0 – řešení podporuje pouze platformu Windows (Windows Server 2003, Windows Server 2008) 0,34 – řešení podporuje také některou z opensourcových distribucí Linux (např. Ubuntu, Debian, CentOS, Gentoo…) 0,67 – řešení podporuje také RHEL (Red Hat Enterprise Linux) 1 – řešení podporuje také platformu SLES (SUSE Linux Enterprise Server)

6.3.1.6 TECH006 MINIMÁLNÍ VELIKOST Kritériem minimální velikosti se rozumí minimální poskytovaná velikost RAM, od které je moţné vyuţívat nabízených řešení. Sluţby byly podle tohoto kritéria hodnoceny na základě úvahy, ţe čím menší je nejniţší moţná poskytovaná velikost RAM, tím lepší je vyuţití kapacity a škálovatelnost. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:   

0,34 – minimální velikost je 1GB a více 0,67 – minimální velikost je v rozmezí 500MB – 1GB (včetně) 1 – minimální velikost je v rozmezí 256MB – 500MB (včetně)

6.3.1.7 TECH007 MAXIMÁLNÍ VELIKOST Obdobně jako u předchozího kritéria TECH006 Minimální velikost, rozumí se i u tohoto kritéria poskytovaná velikost RAM, jakou je moţné v rámci řešení vyuţívat. Hodnocené sluţby byly na základě tohoto kritéria hodnoceny dle předpokladu, ţe čím větší je maximální poskytovaná velikost, tím větší moţnosti se společnosti nabízejí. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:   

0,34 – maximální velikost je v rozmezí 8GB – 15,9 GB 0,67 – maximální velikost je v rozmezí 16GB – 32GB 1 – maximální velikost je 32GB a více

6.3.2 ASPEKTY BCM V rámci aspektů Business Continuity Management byla hodnocena kritéria dvou podřazených kategorií. Tyto kategorie jsou následující:  

Bezpečnost, kam jsou zařazeny nejen otázky bezpečnosti, ale také monitoringu a v neposlední řadě i schopnost poskytovatele zaručit nulovou ztrátu dat v případě výpadku sluţby, Smluvní ujednání, kde je důraz kladen na garanci Service Level Agreement.

-67/117-



6.3.2.1 BCM001 BEZPEČNOST A MONITORING V rámci tohoto kritéria je hodnoceno, zda je moţné v rámci řešení implementovat také bezpečnostní pravidla pro ochranu soukromí a dat společnosti a případně, zda je také moţné vyuţívat bezpečnostního monitoringu. Z důvodu zvýšeného zájmu společností o otázky bezpečnosti cloudových sluţeb byla tomuto kritériu přidělena vyšší váha. Váha tohoto kritéria je 0,09. Kritérium je hodnoceno následujícím způsobem:   

0 – bezpečnost a monitoring není implementován 0,5 – implementována je pouze bezpečnost sluţby 1 – implementována je bezpečnost i monitoring

6.3.2.2 BCM002 ZÁLOHOVÁNÍ Toto kritérium hodnotí, zda dodavatel ručí za zálohu dat v případě, kdy dojde k výpadku sluţby ze strany poskytovatele. Toto kritérium má přímou vazbu na Business Continuity společnosti, proto mu byla přidělena vyšší váha. Váha tohoto kritéria je 0,09. Kritérium je hodnoceno následujícím způsobem:  

0 – poskytovatel neručí za zálohu dat 1 – poskytovatel ručí za zálohu dat

6.3.2.3 BCM003 GARANCE SLA Garancí SLA se rozumí procentuální vyjádření, do jaké míry odpovídá poskytovatel za dohodnuté úrovně poskytování IaaS. Toto kritérium přímo souvisí s Business Continuity instituce, proto mu byla přiřazena vyšší váha. Váha tohoto kritéria je 0,09. Kritérium je hodnoceno následujícím způsobem: 

na stupnici 0 – 1, kde 1 = 100% garance SLA.

6.3.3 FINANČNÍ ASPEKTY V rámci finančních aspektů byla hodnocena kritéria dvou podřazených kategorií. Tyto kategorie jsou následující: 



Financování - důleţitým kritériem pro rozhodování je skutečnost, zda je řešení nabízeno formou platby pay-as-you-go. Protoţe tento model je typický pro řešení Cloud Computingu obecně, je kladen důraz také na to, zda je vedle modelu pay-as-you-go k dispozici také jiný model financování, Sluţby, kde jsou nabízená řešení kategorizována na základě existence podpory zákazníků a hodnocení, zda je tato sluţba nabízena zdarma.

6.3.3.1 FIN001 MODEL FINANCOVÁNÍ V rámci tohoto kritéria je hodnoceno, zda je poskytované řešení moţné financovat modelem pay-asyou-go, nebo zda je nabízen také pohodlnější model měsíčního předplatného, který je však odvozen z hodinové sazby. Protoţe je toto kritérium důleţité pro rozhodování o implementaci řešení, byla mu přiřazena vyšší váha. Váha tohoto kritéria je 0,08. -68/117-



Kritérium je hodnoceno následujícím způsobem:  

0,5 – model financování je pouze pay-as-you-go 1 – nabízeny jsou také další modely financování

6.3.3.2 FIN002 ZPŮSOB STANOVENÍ CENY Tímto kritériem je hodnoceno, jakým způsobem dochází ke stanovení ceny za poskytované sluţby. Toto kritérium přímo souvisí s předchozím kritériem FIN001 Model financování. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:  

0,5 – cena je stanovena na základě hodiny pouţívání 1 – cena můţe být stanovena také dalšími způsoby

6.3.3.3 FIN003 TECHNICKÁ PODPORA V rámci tohoto kritéria je hodnoceno, zda poskytovatel nabízí ke svým sluţbám technickou podporu (poskytovanou 24/7/365) a zda je tato sluţba poskytována zdarma či za poplatek. Váha tohoto kritéria je 0,07. Kritérium je hodnoceno následujícím způsobem:   

0 – technická podpora není zajištěna 0,5 – technická podpora je poskytována za příplatek 1 – technická podpora je poskytována zdarma

6.4 GOGRID CLOUD HOSTING GoGrid je společnost, která se specializuje na poskytování cloudových serverů. Pohybuje se v oblasti poskytování IaaS, coţ je její core business. Ve spolupráci s partnerskými společnostmi poskytuje dodatečné nadstavbové sluţby, mezi které patří vrstva softwaru a aplikací, vývoj aplikací, obnovení z krize a zálohování či bezpečnost a monitoring serverů. Společnost získala řadu ocenění v oblasti poskytování IT sluţeb. [GoGrid2010] Více informací viz: http://www.gogrid.com/cloud-hosting/

6.4.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ GoGrid Cloud Hosting je sluţba, která nabízí zároveň cloudové servery i cloudová úloţiště. K zakoupeným instancím je moţné přistupovat prostřednictvím webového ovládacího panelu na úrovni plných administrátorských práv. Mezi platformy podporované společností GoGrid patří Windows Server, dále zde pak nalezneme podporu některých opensourcových distribucí Linuxu. Podrobnosti o podporovaných platformách jsou znázorněny v Příloha D – Podporované operační systémy IaaS řešení. Nabízená řešení se pohybují ve velikosti od 500MB do 16GB.

6.4.2 HODNOCENÍ ASPEKTŮ BCM Bezpečnost a monitoring nad servery není poskytován přímo společností GoGrid, ale je poskytován ve spolupráci s partnerskými dodavateli sluţeb. Společnost GoGrid garantuje 100% zajištění SLA a poskytuje technickou podporu zdarma v ceně nakoupené sluţby. -69/117-



6.4.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ Mezi nabízené modely financování patří jednak model pay-as-you-go, ale společnost GoGrid nabízí také předplacené měsíční plány. Tyto měsíční plány jsou rozlišeny podle zvolené kategorie cloudu (professional, business, corporate, enterprise).

6.4.4 CELKOVÉ HODNOCENÍ GOGRID CLOUD HOSTING Celkové hodnocení GoGrid řešení je na základě přiřazených vah uvedeno v následující tabulce: Identifikace kritéria

Váha 0,07 0,07 0,07 0,07 0,09 0,07 0,07 0,09 0,09 0,09 0,08 0,07 0,07

TECH001 TECH002 TECH003 TECH004 TECH005 TECH006 TECH007 BCM001 BCM002 BCM003 FIN001 FIN002 FIN003 Celková váţená hodnota

Hodnota 1 1 1 1 0,67 1 0,67 1 1 1 1 1 1

Váţená hodnota 0,07 0,07 0,07 0,07 0,0603 0,07 0,0469 0,09 0,09 0,09 0,08 0,07 0,07 0,9472

Tab. 3 - Hodnocení GoGrid Cloud Hosting (Zdroj: Autor)

Celková váţená hodnota hodnoceného řešení GoGrid je 0,9472 -> 94,72% vhodnost řešení pro implementaci dle zvolených kritérií. Znázorněním neváţených hodnocených kritérií pomocí radarového grafu získáme následující diagram:

GoGrid FIN003 FIN002 FIN001

TECH001 1 0,8 0,6 0,4 0,2 0

TECH002 TECH003 TECH004

BCM003

TECH005

BCM002

TECH006

BCM001

TECH007

Obr. 11 - Grafické znázornění hodnocení GoGrid Cloud Hosting (Zdroj: Autor)

-70/117-



6.5 AMAZON EC2 Amazon Elastic Compute Cloud (Amazon EC2) je webová sluţba, která poskytuje škálovatelnou výpočetní kapacitu prostřednictvím cloudového řešení. Amazon EC2 je sluţba, která poskytuje primárně cloudové servery a cloudové úloţiště. Amazon EC2 je součástí platformy pro Cloud Computing, Amazon Web Services. [Amazon2010] Více informací viz: http://aws.amazon.com/ec2/

6.5.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ Amazon EC2 je řešení, které nad poskytovanými cloudovými servery a cloudovým úloţištěm nabízí také řídící panel přes webové rozhraní. Je proto moţné provádět správu nakoupených serverových instancí odkudkoli prostřednictvím sítě internet. Řešení Amazon EC2 podporuje řadu různých operačních systémů, od Windows Server, přes open sourceové distribuce Linuxu aţ po ty komerční. Podrobný přehled podporovaných platforem je uveden v Příloha D – Podporované operační systémy IaaS řešení. Nabízená řešení se pohybují v rozmezí od 613MB do 68,4GB.

6.5.2 HODNOCENÍ ASPEKTŮ BCM Společnost Amazon.com nabízí nad cloudovými servery také bezpečnostní dohled a monitoring. Společnost však nezaručuje nulovou ztrátu dat, neboť v případě výpadku sluţby je schopna vrátit serverovou instanci do nějakého okamţiku v minulosti. Garance SLA je v případě společnosti Amazon.com ve výši 99,95%. Poskytovaná technická podpora není zdarma, je však moţné si ji připlatit paušální sazbou.

6.5.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ Amazon EC2 je moţné platit v rámci modelu pay-as-you-go nebo předplaceným plánem na dobu jednoho roku nebo tří let, a to za zvýhodněnou hodinovou sazbu. Cena je rozlišena podle velikosti zakoupené instance.

6.5.4 CELKOVÉ HODNOCENÍ AMAZON EC2 Identifikace kritéria TECH001 TECH002 TECH003 TECH004 TECH005 TECH006 TECH007 BCM001 BCM002 BCM003 FIN001 FIN002 FIN003 Celková váţená hodnota

Váha 0,07 0,07 0,07 0,07 0,09 0,07 0,07 0,09 0,09 0,09 0,08 0,07 0,07

Hodnota 1 1 1 0,5 1 0,67 1 1 0 0,9995 1 1 0,5

Tab. 4 - Hodnocení Amazon EC2 (Zdroj: Autor)

-71/117-

Váţená hodnota 0,07 0,07 0,07 0,035 0,09 0,0469 0,07 0,09 0 0,089955 0,08 0,07 0,035 0,816855



Celkové hodnocení Amazon EC2 je na základě přiřazených vah znázorněno ve výše uvedené tabulce. Celková váţená hodnota hodnoceného řešení Amazon EC2 je 0,8169 -> 81,69% vhodnost řešení pro implementaci podle hodnocených kritérií. Znázorněním neváţených hodnotových kritérií pomocí radarového grafu získáme následující diagram:

Amazon EC2 TECH001 1 FIN003 0,8 0,6 FIN002 0,4 0,2 FIN001 0


BCM003

TECH005

BCM002

TECH006

BCM001

TECH007

Obr. 12 - Grafické znázornění hodnocení Amazon EC2 (Zdroj: Autor)

6.6 RACKSPACE CLOUD SERVERS Rackspace Cloud je dceřinou společností Rackspace, která se zaměřuje na poskytování infrastruktury jako sluţby a na poskytování cloudového úloţiště. Společnost Rackspace Cloud si zakládá na nepřetrţité technické podpoře, kterou nabízí zdarma prostřednictvím několika komunikačních kanálů, mezi nimiţ nechybí např. ani live chat. Společnost získala řadu ocenění v oblasti webového hostingu. [Rackspace2010] Více informací viz: http://www.rackspacecloud.com/cloud_hosting_products/servers

6.6.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ Rackspace Cloud nabízí aţ 50 cloudových serverů společně s cloudovým úloţištěm. K nakoupeným běţícím serverům je moţné přistupovat pomocí řídícího panelu na úrovni administrátorského oprávnění. Mezi podporované platformy patří Microsoft Server, nejčastější distribuce open source Linuxu (Ubuntu, Debian…), ale také např. i komerční Red Hat Enterprise Linux. Podrobnosti o podporovaných platformách jsou uvedeny v Příloha D – Podporované operační systémy IaaS řešení. Nabízená řešení se pohybují v rozmezí od 256MB do 16GB.

6.6.2 HODNOCENÍ ASPEKTŮ BCM Toto řešení poskytuje moţnost zabezpečení, o otázkách monitoringu se však dodavatel ve své prezentaci nezmiňuje. Společnost Rackspace Cloud garantuje 100% plnění SLA a poskytuje technickou podporu zdarma v rámci poskytovaných sluţeb.

-72/117-



6.6.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ Řešení Rackspace Cloud Servers je financováno výhradně modelem pay-as-you-go. Od tohoto modelu se také odvíjí stanovená sazba za hodinu vyuţívání. Ceny jsou rovněţ rozděleny do několika kategorií v závislosti na velikosti nakoupené cloudové instance. Společnost si zakládá na poskytované technické podpoře.

6.6.4 CELKOVÉ HODNOCENÍ RACKSPACE CLOUD SERVERS Celkové hodnocení Rackspace Cloud Servers řešení je na základě přiřazených vah uvedeno v následující tabulce: Identifikace kritéria TECH001 TECH002 TECH003 TECH004 TECH005 TECH006 TECH007 BCM001 BCM002 BCM003 FIN001 FIN002 FIN003 Celková váţená hodnota

Váha

Hodnota

Váţená hodnota

0,07 0,07 0,07 0,07 0,09 0,07 0,07 0,09 0,09 0,09 0,08 0,07 0,07

1 1 1 1 0,67 1 0,67 0,5 1 1 0,5 0,5 1

0,07 0,07 0,07 0,07 0,0603 0,07 0,0469 0,045 0,09 0,09 0,04 0,035 0,07 0,8272

Tab. 5 - Hodnocení Rackspace Cloud Servers (Zdroj: Autor)

Celková váţená hodnota hodnoceného řešení Rackspace Cloud Servers je 0,8272 -> 82,72% vhodnost řešení pro implementaci podle hodnocených kritérií. Znázorněním neváţených hodnocených kritérií pomocí radarového grafu získáme následující diagram:

Rackspace Cloud TECH001 1 FIN003 0,8 0,6 FIN002 0,4 0,2 FIN001 0


BCM003

TECH005

BCM002

TECH006

BCM001

TECH007

Obr. 13 - Grafické znázornění hodnocení Rackspace Cloud Servers (Zdroj: Autor)

-73/117-



6.7 RELIACLOUD ReliaCloud je sluţba poskytující infrastrukturu jako cloudové řešení. ReliaCloud je soukromou společností, která je nabídkou svých hostingových sluţeb přímým konkurentem takových společností, jako je např. Rackspace. ReliaCloud je součástí hostingové organizace. Obdobně jako Rackspace, zakládá si i ReliaCloud na poskytování nepřetrţité technické podpory svým zákazníkům. [ReliaCloud2010] Více informací viz: http://www.reliacloud.com/howitworks/

6.7.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ ReliaCloud je sluţba, která poskytuje vysoce dostupné cloudové servery i cloudové úloţiště. Tyto sluţby jsou zabezpečené firewallem a je moţné k nim přistupovat pomocí webového ovládacího panelu na úrovni administrátorských práv. Platformy podporované řešením ReliaCloud zahrnují Microsoft Server i některé opensource distribuce Linuxu. Podrobnosti o podporovaných platformách jsou uvedeny v Příloha D – Podporované operační systémy IaaS řešení. Nabízená řešení se pohybují v rozmezí od 500MB do 8GB.

6.7.2 HODNOCENÍ ASPEKTŮ BCM ReliaCloud garantuje 100% dodrţení stanovených SLA.

6.7.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ ReliaCloud nabízí financování pouze na základě modelu pay-as-you-go. Sazby jsou odlišeny v několika kategoriích podle velikosti instance. Technická podpora je poskytována zdarma v rámci zakoupených sluţeb.

6.7.4 CELKOVÉ HODNOCENÍ RELIACLOUD Celkové hodnocení ReliaCloud řešení je na základě přiřazených vah uvedeno v následující tabulce: Identifikace kritéria TECH001 TECH002 TECH003 TECH004 TECH005 TECH006 TECH007 BCM001 BCM002 BCM003 FIN001 FIN002 FIN003 Celková váţená hodnota

Váha

Hodnota

Váţená hodnota

0,07 0,07 0,07 0,07 0,09 0,07 0,07 0,09 0,09 0,09 0,08 0,07 0,07

1 1 1 0,5 0,34 1 0,34 0,5 1 1 0,5 0,5 1

0,07 0,07 0,07 0,035 0,0306 0,07 0,0238 0,045 0,09 0,09 0,04 0,035 0,07 0,7394

Tab. 6 - Hodnocení ReliaCloud (Zdroj: Autor)

-74/117-



Celková váţená hodnota hodnoceného řešení ReliaCloud je 0,7394 -> 73,94% vhodnost řešení pro implementaci dle stanovených kritérií. Znázorněním neváţených hodnotových kritérií pomocí radarového grafu získáme následující diagram:

ReliaCloud TECH001 1 FIN003 0,8 0,6 FIN002 0,4 0,2 FIN001 0


BCM003

TECH005

BCM002

TECH006

BCM001

TECH007

Obr. 14 - Grafické znázornění hodnocení ReliaCloud (Zdroj: Autor)

6.8 ELASTICHOSTS ElasticHosts je mezinárodní sluţba poskytující infrastrukturu pomocí cloudu. Sluţba ElasticHosts je poskytována ze dvou datových center. Soustředí se na poskytování virtualizace tak, aby byla flexibilní, a zaměřuje se na širokou škálu zákazníků od těch nejmenších, aţ po velké korporace. Společnost si zakládá na tom, ţe je ekologickou a sniţuje uhlíkovou stopu. [ElasticHosts2010] Více informací viz: http://www.elastichosts.com/

6.8.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ ElasticHosts je řešení poskytující cloudové servery a cloudová úloţiště, ke kterým je moţné přistupovat pomocí webového řídícího panelu. Díky tomu je moţné řídit a nastavovat servery obdobně, jako tomu je na úrovni hardware. Mezi podporované platformy patří Windows Server (pozn. uváděn je pouze Windows Server 2008) a některé z open source distribucí Linuxu. Podrobnosti jsou znázorněny v tabulce v Příloha D – Podporované operační systémy IaaS řešení. Velikosti nabízených řešení se pohybují v rozmezí od 1,7 GB do 8GB.

6.8.2 HODNOCENÍ ASPEKTŮ BCM Infrastruktura je zabezpečena a ElasticHosts ručí za kompletní obnovení uţivatelských dat v případě výpadku sluţby. Garance SLA je 100%.

6.8.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ ElasticHosts je moţné financovat na základě modelu pay-as-you-go nebo na základě měsíčního tarifu placeného dopředu. Sazby jsou odlišeny podle velikosti zakoupené serverové instance. Při předplacení sluţeb na 12 měsíců nabízí ElasticHosts zvýhodnění. -75/117-



Technická podpora není poskytována zdarma, je moţné ji dokoupit za paušální sazbu navíc. Poskytovatel se hájí tím, ţe není moţné zaručit funkcionalitu aplikací běţících na poskytované infrastruktuře, z tohoto důvodu neexistuje technická podpora zdarma.

6.8.4 CELKOVÉ HODNOCENÍ ELASTICHOSTS Celkové hodnocení ElasticHosts řešení je na základě přiřazených vah uvedeno v následující tabulce: Identifikace kritéria TECH001 TECH002 TECH003 TECH004 TECH005 TECH006 TECH007 BCM001 BCM002 BCM003 FIN001 FIN002 FIN003 Celková váţená hodnota

Váha

Hodnota

Váţená hodnota

0,07 0,07 0,07 0,07 0,09 0,07 0,07 0,09 0,09 0,09 0,08 0,07 0,07

1 1 1 0,5 0,34 0,34 0,34 0,5 1 1 1 1 0,5

0,07 0,07 0,07 0,035 0,0306 0,0238 0,0238 0,045 0,09 0,09 0,08 0,07 0,035 0,7332

Tab. 7 - Hodnocení ElasticHosts (Zdroj: Autor)

Celková váţená hodnota hodnoceného řešení ElasticHosts je 0,7332 -> 73,32% vhodnost řešení pro implementaci dle stanovených kritérií. Znázorněním neváţených hodnocených kritérií pomocí radarového grafu získáme následující diagram:

ElasticHosts TECH001 1 FIN003 0,8 0,6 FIN002 0,4 0,2 FIN001 0


BCM003

TECH005

BCM002

TECH006

BCM001

TECH007

Obr. 15 - Grafické znázornění řešení ElasticHosts (Zdroj: Autor)

-76/117-



6.9 VZÁJEMNÉ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ Na základě provedené analýzy pěti dostupných IaaS řešení bylo dosaţeno několika závěrů. Analýza vycházela z celkového počtu 13-ti kritérií, z nichţ kaţdé mohlo nabývat maximální hodnoty 1. Čím vyšší dosaţená hodnota v daném kritériu byla, tím vhodnější řešení. Jednotlivým kritériím byly dále přiřazeny váhy (viz kapitola 6.1). Po ohodnocení všech kritérií bylo zjištěno následující pořadí „vhodnosti“ IaaS řešení: Řešení IaaS

Naplnění kritérií (%)

1. GoGrid Cloud Hosting

94,72%

2. Rackspace Cloud Servers

82,72%

3. Amazon EC2

81,69%

4. ReliaCloud

73,94%

5. ElasticHosts

73,32% Tab. 8 - Pořadí IaaS řešení dle hodnocených kritérií (Zdroj: Autor)

Abychom získali podrobnější přehled o analyzovaných produktech a zároveň zhodnotili jejich vhodnost jak z hlediska technických předpokladů, tak z hlediska Business Continuity Management, analyzovali jsme získaná data dále.

6.9.1 ZHODNOCENÍ OBLASTI TECHNICKÝCH ASPEKTŮ Mezi technické aspekty, na základě kterých byla řešení dále hodnocena, patří následujících sedm kritérií:       

TECH001 Cloudové servery TECH002 Cloudové úloţiště TECH003 Webový ovládací panel TECH004 API TECH005 Podporovaný operační systém TECH006 Minimální velikost TECH007 Maximální velikost

Na základě ohodnocení technických kritérií lze získat následující pořadí: Řešení IaaS


1. – 2. GoGrid Cloud Hosting

65,31%

1. – 2. Rackspace Cloud Servers

65,31%

3. Amazon EC2

64,56%

4. ReliaCloud

52,77%

5. ElasticHosts

46,17% Tab. 9 - Pořadí IaaS řešení dle technických parametrů (Zdroj: Autor)

Podle tohoto srovnání jsou řešení GoGrid Cloud Hosting a Rackspace Cloud Servers srovnatelné a velice se jim přibliţuje také Amazon EC2. Výrazně se zvětšil rozdíl mezi zbývajícími řešeními ReliaCloud a ElasticHosts.

-77/117-



6.9.2 ZHODNOCENÍ OBLASTI BUSINESS CONTINUITY V dalším kroku jsme porovnávali produkty z hlediska Business Continuity. Pro tento účel byla vybrána následující kritéria:   

BCM001 Bezpečnost a monitoring BCM002 Zálohování BCM003 Garance SLA

Nutno podotknout, ţe všechna tato tři kritéria mají sobě přiřazenu vyšší váhu neţ kritéria zbývající. Proto je zajímavý výsledek srovnání konkurenčních řešení: Řešení IaaS



90%


75%

2. – 4. ReliaCloud

75%

2. – 4. ElasticHosts

75%

5. Amazon EC2

59,99% Tab. 10 - Pořadí IaaS řešení dle parametrů BCM (Zdroj: Autor)

Na této tabulce je zajímavé jak srovnání tří řešení Rackspace Cloud Servers, ReliaCloud a ElasticHosts, tak i značný propad řešení Amazon EC2. Tento propad je dán především následujícími důvody: 



Amazon EC2 neposkytuje záruku nulové ztráty dat v případě výpadku sluţby. Dokáţe pouze zajistit navrácení instance do nejbliţšího časového okamţiku před výpadkem. V některých případech proto můţe dojít ke ztrátě dat. Garance SLA ze strany Amazon.com je „pouze“ na úrovni 99,95%, zatímco ostatní poskytovatelé hodnocených řešení jsou schopni zajistit garanci stoprocentní.

Na druhou stranu řešení Amazon EC2 nabízí na rozdíl od některých řešení umístěných na 2. – 4. místě bezpečnostní monitoring. Ani to mu však nestačilo, aby se dostal nad jejich úroveň. Při výběru vhodného řešení je proto dobré všechny tyto aspekty zváţit.

6.9.3 ZHODNOCENÍ OBLASTI FINANČNÍCH ASPEKTŮ V této oblasti byla hodnocena následující kritéria:   

FIN001 Model financování FIN002 Způsob stanovení ceny FIN003 Technická podpora

Porovnáním těchto kritérií dosáhneme následujícího pořadí srovnávaných řešení: Řešení IaaS



73,34%

2. – 3. Amazon EC2

61,67%

2. – 3. ElasticHosts

61,67%


48,34%

4. – 5. ReliaCloud

48,34% Tab. 11 - Pořadí IaaS řešení dle finančních kritérií (Zdroj: Autor)

-78/117-



Z pořadí získaného porovnáním finančních kritérií je zřejmé, ţe se poněkud výrazně změnilo umístění jednotlivých řešení. To je dáno především strukturou kritérií, které zvýhodňují ta řešení, která nabízí variabilitu v otázkách financování. Toto pořadí ve srovnání s pořadími předchozími je zřejmým důkazem toho, ţe není vhodné výběr řešení omezovat pouze na finanční kritéria.

6.9.4 MULTIKRITERIÁLNÍ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ Na následujícím obrázku je graficky znázorněn komplexní vztah mezi hodnocenými řešeními. Na ose X je vyjádřeno naplnění technických kritérií, osa Y znázorňuje naplnění poţadavků Business Continuity Management. Velikost jednotlivých „koulí“ je dána naplněním finančních kritérií. Umístění jednotlivých řešení nám tak poskytuje obrázek o tom, jak vhodné je řešení z hlediska technického, finančního a z hlediska plánování podnikové kontinuity.

Aspekty BCM

Porovnání řešení IaaS 100% 95% 90% 85% 80% 75% 70% 65% 60% 55% 50% 40%

GoGrid

ElasticHosts

ReliaCloud Rackspace

Amazon EC2

45%

50%

55%

60%

65%

70%

Technické aspekty Obr. 16 - Grafické znázornění porovnání IaaS řešení ve 3 rozměrech (Zdroj: Autor)

6.10

ZÁVĚREČNÉ ZHODNOCENÍ

V této kapitole bylo provedeno srovnání pěti řešení Infrastructure-as-a-Service. Na první pohled jsou tato řešení srovnatelná a jsou si sobě přímými konkurenty. Předmětem této kapitoly však bylo mimo jiné poukázat také na to, jak se vhodnost vybíraného řešení mění v závislosti na sadě aplikovaných kritérií. Například řešení, které se na první pohled můţe jevit jako nedostatečné z hlediska technických aspektů, neboť nepodporuje širokou škálu operačních systémů, můţe překvapit svou pruţností při naplnění aspektů Business Continuity.

-79/117-



7 NÁVRH VHODNÉHO ŘEŠENÍ PRO VŠE PRAHA Tato kapitola je praktickou aplikací návrhu vhodného Cloud Computing řešení podporujícího poţadavky Business Continuity Management v konkrétních podmínkách VŠE Praha. Řešení vychází z výsledků předchozích kapitol a aplikuje veškeré poznatky ve specifickém prostředí instituce terciárního vzdělávání. V první části této kapitoly je popsán ţivotní cyklus Business Continuity Management na VŠE Praha, v části druhé jsou navrhnutá Cloud Computing řešení verifikována s ohledem na poţadavky, které na ně klade Business Continuity Management.

7.1 OBLAST BUSINESS CONTINUITY MANAGEMENT V oblasti Business Continuity Management by instituce měla postupovat podle jednotlivých fází ţivotního cyklu procesu BCM, popsaných v kapitole 1.2. V této kapitole si takový postup ukáţeme prakticky na konkrétních podmínkách VŠE Praha.

7.1.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI K tomu, aby instituce mohla úspěšně implementovat prvky Business Continuity Management, je potřeba, aby byla provedena analýza dopadů (BIA). V rámci analýzy dopadů instituce určuje, které činnosti jsou pro ni klíčové a co by pro instituci znamenalo, došlo-li by k jejich narušení. Protoţe VŠE je institucí v oboru terciárního vzdělávání a všechny její fakulty, resp. katedry podporují stejné procesy, nebude v tomto ohledu instituce členěna na menší celky, ale bude z procesního hlediska chápána jako jeden celek. V prvním kroku analýzy dopadů je důleţité určit procesy, které jsou z hlediska BCM pro VŠE klíčové. Z hlavních procesů zobrazených v Procesní mapě v kapitole 5.1.2 jsou z hlediska Business Continuity klíčové následující tři procesy:   

PR01 - Zajištění studia PR02 - Rozvoj vědy a výzkumu PR03 - Podpora a rozvoj hospodářské činnosti

Mezi procesy klíčové z hlediska Business Continuity byly vybrány klíčové procesy Procesní mapy s výjimkou procesu Zajištění mezinárodních aktivit a vztahů. Tento proces je z hlediska VŠE důleţitý, neboť si v rámci něho VŠE zajišťuje mezinárodní pověst a dobré vztahy se zahraničními univerzitami. V případě, ţe by však byl proces narušen a došlo k jeho výpadku, chod instituce jako takové nebude významně ohroţen. U procesů PR01 – PR03 by mělo dojít k ohodnocení dopadu rizik na daný proces, doba poţadovaná na obnovení procesu a odhad dopadu na instituci. Ten můţe být odhadnut v podobě finanční ztráty, dopadu na dodávky sluţeb, poškození pověsti, nesplnění zákonných povinností apod. V následující tabulce je uveden příklad zobrazení výsledků Analýzy dopadu na jednotlivé klíčové procesy.

-80/117-



Název procesu

MTD (Maximum Downtime)

Tolerable RPO Ohodnocení (Recovery dopadu Point RTO (Recovery WRT (Work Objective Time Recovery Time) Objective)

PR01 Zajištění studia

< 2 dny

4 Přerušení dodávky sluţeb

< 2 dny

< hodiny

PR02 Rozvoj vědy a < 1,5 dne výzkumu

< 2 dny

< 1 den

Poškození pověsti

PR03 Podpora a rozvoj < 1 den hospodářské činnosti

< 2 dny

< 1 den

Finanční ztráty

Tab. 12 - Souhrnná tabulka Analýzy dopadu (Zdroj: Autor)

Sloupec RTO udává maximální počet hodin/dní, za který je nutné obnovit chod podpůrných systémů. Jestliţe v případě procesů PR01 Zajištění studia a PR02 Rozvoj vědy a výzkumu by byla potřeba chod podpůrných systémů obnovit do dvou dnů, v případě procesu PR03 Podpora a rozvoj hospodářské činnosti by tento čas měl být kratší, neboť narušení tohoto procesu vede k finančním ztrátám. Ve sloupci WRT je stanoven maximální moţný čas potřebný k obnovení chodu celého procesu za předpokladu, ţe podpůrné systémy jsou jiţ obnoveny. V případě procesu P01 Zajištění studia by mohl být tento čas delší neţ v případě zbylých dvou procesů, neboť narušení procesu P02 Rozvoj vědy a výzkumu a PR03 Podpora a rozvoj hospodářské činnosti má pro instituci větší dopady. Obnova dat v případě jejich ztráty by probíhala nahráním z pásky. Tato obnova má jisté časové poţadavky, celkové obnovení procesu by se proto pohybovalo spíše v řádech dnů, neţli hodin. Důleţité je brát také v úvahu to, která data by měla prioritu pro obnovu. V případě obnovy dat studijního informačního systému ISIS by prioritu měla studijní data, např. obnovení dat poštovních schránek by bylo provedeno s niţší prioritou, a tedy později. Na základě takto definovaných hodnot pro jednotlivé klíčové procesy lze stanovit prioritu, se kterou by mělo dojít k obnovení chodu procesu. Zpravidla největší prioritu mají logicky procesy s nejkratší poţadovanou dobou obnovy a/nebo s největšími finančními ztrátami.

Náklady

Stanovení RTO jednotlivých klíčových procesů je výsledkem rozhodnutí instituce. Optimální hodnota RTO se často udává jako bod, kdy se finanční ztráta rovná nákladům na obnovení chodu procesu. Tato vzájemná závislost je uvedena schematicky na následujícím grafu.

Náklady na obnovu Ztráty organizace

Čas Obr. 17 - Grafické znázornění vztahu mezi náklady na obnovu a ztrátou organizace (Zdroj: Autor)

-81/117-



Po stanovení optimálních hodnot je v rámci Analýzy dopadů potřeba také odhadnout zdroje a sluţby nutné k tomu, aby byla činnost, resp. proces zcela obnoven. Součástí první fáze ţivotního cyklu Business Continuity Managementu je také popsání specifických rysů, které jsou společné pro oblast terciárního vzdělávání, na konkrétních podmínkách VŠE. Tato specifika mají vliv na stanovení strategie Business Continuity a byla vymezena a popsána v kapitole 4.5. V následujícím textu jsou tato specifika popsána pro konkrétní případ VŠE: 

SP01 Sezónnost – sezónnost se v podmínkách VŠE nejvíce projevuje ve variabilitě poskytování sluţby, kterou je vzdělávání, a proto nejvíce rysů sezónnosti vykazuje proces PR01 Zajištění studia. Ostatní procesy PR02 Rozvoj vědy a výzkumu a PR03 Podpora a rozvoj hospodářské činnosti nevykazují takové výkyvy sezónnosti, ačkoli i u těchto procesů je patrný propad ve frekvenci jejich vyuţívání v letních měsících. Proces PR01 Zajištění studia má výkyvy nejen během letních měsíců, kdy probíhají prázdniny, ale také se liší počty a potřeby studentů na začátku semestru, v jeho průběhu, na konci, během zkouškového období či v období státních zkoušek.







SP02 Závislost na IT – závislost na IT se na VŠE stejně jako na ostatních institucích terciárního vzdělávání zvyšuje. Důkazem je také to, ţe všechny klíčové procesy jsou podporovány jedním nebo více informačními systémy. Zvyšuje se také vyuţívání IT při jednotlivých činnostech, kdy je například moţné prostřednictvím studijního informačního systému přihlašovat se na termíny zkoušek, přihlašovat se do vedlejších specializací nebo sestavovat si rozvrh. V blízké budoucnosti je plánováno také začít s testováním studentů pomocí informačního systému. SP03 Konkurenční tlak – konkurenčnímu tlaku VŠE nečelí pouze ze strany ostatních státních institucí, ale také ze strany soukromých vysokých škol, jejichţ počet v posledních letech v České republice rapidně vzrostl. Tyto soukromé školy si postupně budují svou pověst, získávají prestiţ a v mnohých případech také vyhrávají v „boji“ o studenty. SP04 Inovace – VŠE by stejně jako kaţdá jiná instituce terciárního vzdělávání měla být nositelem inovativních myšlenek. Protoţe VŠE však není školou technickou, ale primárně ekonomickou, nepatří mezi přední představitele inovace v oblasti informačních technologií.

7.1.2 FÁZE 2 – URČENÍ STRATEGIE BCM Náplní druhého kroku ţivotního cyklu BCM je určení samotné strategie BCM. Tato strategie by měla vycházet z dokumentu Bezpečnostní politika VŠE. Na základě tohoto dokumentu je potom moţné identifikovat moţné příčiny narušení klíčových procesů. Určení strategie BCM se týká všech aktiv instituce, nejen technických zdrojů, ale také budov a zařízení, lidských zdrojů apod. V podstatě existuje několik typů strategií BCM. Tyto strategie bychom mohli kategorizovat následujícím způsobem [ICM2004]:     

Přijetí rizik, neprovedení ţádné změny Přijetí rizik, vytvoření vzájemné dohody o pomoci s jinou institucí Sníţení rizik Sníţení rizik a zajištění externí pomoci Sníţení rizik a vytvoření prostředí pro interní pomoc

Jak jiţ bylo uvedeno v kapitole 1, nejčastější příčinou narušení běţné činnosti jsou incidenty jako výpadek elektrického proudu nebo porucha vodovodního rozvodu. VŠE by na základě identifikovaných moţných příčin a pravděpodobnosti jejich výskytu měla zhodnotit, zda by nebylo vhodné vyuţívat datového úloţiště u externího poskytovatele. Tato datová úloţiště jsou umístěna -82/117-



v jiné lokalitě, neţ se nachází instituce a především jsou většinou technicky natolik vybavena, ţe dokáţou udrţet svůj chod ze záloţních zdrojů třeba i tři dny. VŠE postupem času ustoupila od strategie záloţního prostředí, kdy byla data redundantně ukládána v serverovém sále v areálu na Jiţním Městě. V současné době VŠE nemá ţádné záloţní prostředí. Díky tomu, ţe je však připojena k akademické síti PASNET a posléze také k síti pro výzkum CESNET2, bylo by moţné vytvořit záloţní prostředí v areálu jiné tuzemské instituce pro terciární vzdělávání. Takové záloţní prostředí by mohlo být poskytováno institucemi navzájem, coţ by mimo jiné vedlo ke zvýšení důvěryhodnosti obou stran. Dalším důleţitým prvkem strategie BCM je určení krizového uspořádání instituce. To znamená, ţe by mělo být stanoveno takové uspořádání, které by v případě krize neslo odpovědnost za její řešení a navrácení chodu procesů do původního stavu. Součástí identifikace krizového uspořádání je i definice klíčových osob, které by včetně svých zástupců a telefonních kontaktů měly být uvedeny na seznamu, který by měl mít k dispozici kaţdý zaměstnanec. Tato fáze ţivotního cyklu BCM navazuje na Analýzu dopadů provedenou v prvním kroku a upřesňuje RTO (Recovery Time Objective) jednotlivých sluţeb. Díky tomu je moţné určit, s jakou frekvencí je potřeba zálohovat a archivovat data instituce. V současné době na VŠE probíhá denní záloha dat, v případě systému ISIS je to dokonce v intervalu 4 hodin. Data jsou zálohována v lokalitě Jarov a posléze archivována.

7.1.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU BCM plán – Ztráta dat – postup pro prvních 24 – 48 hodin Popis stavu  

Poskytování sluţby vzdělávání je narušeno Běţný průběh procesu je narušen z důvodu nedostupných/chybějících dat

Pravděpodobnost



nízká

Dopad



vysoký

Pravděpodobná příčina



problém sítě

Dotčené procesy



PR01 Zajištění studia

Odpovědnost



odpovědná osoba XXX

Činnosti

Okamţitě 



Během 24 - 48 hodin

kontaktování Výpočetního centra, oznámení problému, doţadování se zálohy, je-li dostupná informování ostatních kompetentních osob o problému

  

navázání kontaktu se záloţní lokalitou obnovení dat z poslední zálohy neexistuje-li datová záloha, obnovit data z papírových dokumentů

Sníţení dopadu

 

častější zálohování kopie dokumentů na lokální úloţiště, přenosná média (je-li to umoţněno Bezpečnostní politikou)

Omezení



časový úsek doby obnovení dat

Zdroje



záloha dat

Tab. 13 - Příklad plánu BCM pro riziko ztráty dat (Zdroj: Autor)

-83/117-



Po té, co byla identifikována rizika, provedena Analýza dopadů a vydefinována strategie BCM, je moţné vytvořit BC plán. Tento plán přenáší strategii BCM instituce do činností na taktické a operativní úrovni, a udává tak, jak se mají zachovat jednotliví zaměstnanci. Součástí plánu BC je také plán obnovy. Plán by měl být stručný, ale neměl by být zjednodušený. Při sestavování plánu BC je třeba mít na mysli, ţe v případě potřeby budou zaměstnanci potřebovat jednat rychle a účinně, je třeba proto zvolit vhodný formát plánu. Ve výše uvedené tabulce je uveden příklad plánu BC pro případ, kdy by došlo k narušení procesu PR01 Zajištění studia z důvodu rizika ztráty dat. Z výše uvedené tabulky příkladu Business Continuity plánu pro výskyt určitého rizika je zřejmé, ţe takový plán má zásadní vliv na doposud existující postup eskalace a řízení procesu, a to i v případě, ţe ţádný plán eskalace a řízení doposud neexistoval.

7.1.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU Náplní poslední fáze ţivotního cyklu Business Continuity Management je pravidelné testování jednotlivých scénářů, které byly definovány v rámci předchozí fáze. Testování je vyhodnoceno formou záznamu a na základě jeho výsledku je rozhodnuto o aktuálnosti scénáře a jeho případné nutnosti aktualizace. Tímto způsobem je moţné udrţovat plán Business Continuity aktuální.

7.2 OBLAST CLOUD COMPUTINGU V rámci VŠE by bylo moţné vyuţívat celé řady Cloud Computing řešení. Instituce by mohla vyuţívat nabízených aplikací pro komunikaci v rámci týmové spolupráce nebo ke sdílení souborů. V případě tak velké společnosti, kterou je VŠE, je však vhodnější začít s implementací Cloud Computing řešení v oblasti infrastruktury. Důvody, proč by VŠE měla začít s vyuţíváním Cloud Computingu v oblasti infrastruktury lze shrnout do následujících bodů: 

  

instituce jiţ investovala určité finanční částky do své vlastní infrastruktury, a není proto v jejím zájmu začít vyuţívat cizí prostředky, aniţ by současně neredukovala infrastrukturu umístěnou v rámci společnosti, instituce hledá účinný prostředek k tomu, jak efektivně vyuţívat své dosavadní zdroje a jak sníţit náklady na tyto zdroje potřebné, instituce operuje s mnoţstvím citlivých dat, které není alespoň z počátku vhodné přesouvat do datových center externího poskytovatele, instituce nehledá způsoby, jak začít vyuţívat Cloud Computing (nabídky dodavatelů na SaaS řešení jsou nejčastějšími), ale jak sníţit své dosavadní náklady.

Z výše uvedených důvodů vyplývá, ţe efektivní vyuţívání vlastní infrastruktury je pro VŠE stěţejní záleţitostí. Na základě kapitoly 5.2, kde bylo identifikováno, které Cloud Computing řešení by nejlépe vyhovovalo VŠE a kapitoly 7.1, ve které byl demonstrován ţivotní cyklus BCM, by navrhovaná strategie Cloud Computing řešení mohla být dosaţena v následujících krocích: 1. Virtualizace existujících serverů 2. Vytvoření privátního cloudu 3. Přechod do hybridního cloudu 3.1. Vyuţití nabídky externího poskytovatele IaaS 3.2. Vyuţití open sourceového nástroje pro integraci 3.3. Vyuţití nástroje pro governance řešení -84/117-



V rámci informační strategie VŠE [VSE2010] bylo stanoveno několik cílů dalšího směřování VŠE. Mezi těmito cíli je mimo jiné zmíněna virtualizace serverů a datových úloţišť, zavedení systému pro řízení identit, udrţení funkčního a spolehlivého systému zálohování, archivace a udrţení a posilování bezpečnosti IS/ICT. Tyto cíle jsou v souladu s řešením navrhovaným v této diplomové práci.

7.2.1 NAPLNĚNÍ PŘEDPOKLADU ŘÍZENÍ RIZIK Před samotnou implementací Cloud Computing řešení by instituce terciárního vzdělávání měla provést analýzu řízení rizik. Prvním krokem této analýzy je identifikace technologických aktiv (např. serverů), které podporují klíčové procesy VŠE a identifikace dat na těchto aktivech umístěných. Pokud hovoříme o vyuţívání Cloud Computing řešení na úrovni infrastruktury, je vhodné, aby instituce provedla modelování hrozeb (Threat modeling). Pro to, aby byla VŠE schopna modelovat hrozby na úrovni infrastruktury, je potřeba, aby znala jak IT procesy, tak procesy podnikové. Výstupem činnosti modelování hrozeb je identifikace a ohodnocení hrozeb a zranitelností, které jsou aktuální pro jednotlivé komponenty infrastruktury. Proces modelování hrozeb v případě VŠE by sestával z několika kroků a měl přibliţně následující podobu: 1. Identifikace bezpečnostních cílů Bezpečnostními cíli se rozumí cíle a omezení, která jsou spojena s důvěrností, integritou a dostupností dat a aplikací. Při definování bezpečnostních cílů je vhodné analyzovat situaci instituce z pohledu omezení. Postupem „co bychom nechtěli, aby se stalo“ je moţné identifikovat, která bezpečnostní opatření jsou nejdůleţitější. V tomto kroku by se instituce měla zaměřit na to, která data jsou pro ni nejdůleţitější. Výsledkem by mohly být následující cíle:   

ochránit studijní data před útoky zajistit dosaţení SLA jednotlivých sluţeb (např. dostupnost studijního informačního systému ISIS) udrţet dobré jméno VŠE

2. Vytvoření přehledu infrastruktury V tomto kroku je potřeba vytvořit přehled o tom, jaká infrastruktura se na VŠE nachází. Pro vyuţití v tomto praktickém příkladě je potřeba definovat, na kterých serverech se nacházejí studijní, ekonomická a další data, která jsou výstupem klíčových procesů VŠE. Součástí tohoto přehledu by měly být také informace o technologickém vybavení, např. operačních systémech na serverech nainstalovaných, o bezpečnostním monitoringu nebo o protokolech a portech probíhající komunikace. 3. Vytvoření detailního pohledu na infrastrukturu Tento krok logicky navazuje na krok předchozí, ale jde do většího detailu podrobnosti. V tomto kroku je například vhodné identifikovat, jakým způsobem probíhá autentizace a autorizace uţivatel, jakým způsobem probíhá datový tok, jak silná je ochrana dat pomocí firewallu apod. Na takto vytvořený přehled infrastruktury je nutné navázat změny, které by v instituci proběhly v případě, kdyby se rozhodla pro Cloud Computing řešení. Toto rozhodnutí by mělo vliv na způsob autentizace a autorizace uţivatelů a na bezpečnost přenosu dat mezi interním prostředím za hranicemi firewallu a externím datovým centrem.

-85/117-



4. Identifikace hrozeb V tomto kroku jiţ instituce můţe identifikovat hrozby, které jsou spojeny s adopcí Cloud Computingu. V případě VŠE jsou to hrozby, které souvisejí s vyuţíváním sluţeb IaaS. Tyto hrozby jsou výsledkem předchozích kroků, navazují na definované bezpečnostní cíle v kroku 1 a berou v úvahu současnou situaci infrastruktury VŠE. Seznam hrozeb pro adopci IaaS řešení na VŠE by mohl mít následující podobu: 

zneuţití a nezákonné pouţití Cloud Computing řešení – nejčastějším případem zneuţití a nezákonného pouţití jsou spamy, škodlivý kód nebo prolomení hesel. VŠE se jiţ v současné době podařilo úspěšně se bránit proti spamovým útokům pomocí nové metody vyhodnocování spamových zpráv „greylisting“. [VC2010] V případě, ţe by se VŠE rozhodla vyuţívat kapacitu externího poskytovatele pro navýšení své vlastní kapacity např. v době zkouškového období, musela by uvaţovat o tom, jak by se tato hrozba změnila, neboť by musela být některá data přesunuta do cloudu.









nedostatečné zabezpečení rozhraní – nedostatečné zabezpečení bylo zpočátku hrozbou týkající se především PaaS řešení, v dnešní době se ale týká i IaaS. Předcházení a minimalizaci hrozeb je moţné dosáhnout pomocí autentizace přístupů, bezpečnostního monitoringu a řízení přístupů (IAM). hrozba plynoucí ze sdílené infrastruktury – infrastruktura sdílená s ostatními zákazníky externího poskytovatele je spíše psychologickou obavou, i kdyţ určité riziko ve sdílené infrastruktuře opravdu je. Na druhou stranou je to však rozšířenost vyuţívání virtualizace v rámci Cloud Computing řešení, která umoţňuje účinně oddělit aplikace od infrastruktury a tím také sníţit riziko útoku. ztráta nebo únik dat – díky vyuţívání Cloud Computing řešení by VŠE získala spolehlivé úloţiště dat v odlišné lokalitě. Bylo by proto moţné omezit ukládání dat na lokální úloţiště a zamezit ukládání citlivých dat na přenosná média, která by se mohla snadno dostat do cizích rukou. útok prostřednictvím uţivatelských účtů – tento útok je nejčastější hrozbou informačních systémů. S vyuţíváním Cloud Computing řešení důvěryhodného externího poskytovatele by se nemělo toto riziko zvýšit, naopak většina poskytovatelů nabízí účinné nástroje například pro řízení identit, čímţ by VŠE dosáhla lepší bezpečnosti uţivatelských účtů.

5. Identifikace zranitelností Identifikace zranitelností Cloud Computing řešení je prováděna obdobně jako identifikace hrozeb v předchozím kroku. VŠE by měla hledat zranitelnosti v následujících oblastech: 

Autentizace – v této oblasti by si instituce měla klást otázky: o Jsou uţivatelská jména a hesla přenášena mezi interním a externím prostředím v šifrované podobě? o Kde jsou uţivatelská jména a hesla uloţena a jak jsou zabezpečena? o Jsou uţivatelé nuceni pouţívat silná hesla? Jaké další moţnosti ochrany hesel jsou implementovány? o Jakým způsobem probíhá ověření správného přihlašovacího jména a hesla? o Jak je autentizovaný uţivatel identifikován po prvotním přihlášení? Odpovědi na tyto otázky přinášejí přehled zranitelností v oblasti autentizace. Zvlášť důleţité je to, aby přenos mezi VŠE a poskytovatelem Cloud Computing řešení probíhal šifrovaně. -86/117-





Autorizace – v této oblasti by si instituce měla klást otázky: o Je vyuţíván řízený přístup pomocí rolí? Jsou tyto role dostatečně granulární tak, aby bylo moţné řídit přístup a auditing? o Je omezen přístup k databázi? Jak probíhá autorizace v přístupu k databázi? Zranitelností v této oblasti je nedostatečně řízený přístup pomocí rolí. V mnoha případech mají jednotlivé role zbytečně velká oprávnění a oprávnění kořenového administrátora nejsou dostatečně oddělena. Cílem řízení přístupů ke kaţdému informačnímu systému je ten, aby existoval pouze jeden uţivatel s nejvyššími právy a všem ostatním rolím byla přidělována co nejniţší moţná práva.



Auditing – v této oblasti by si instituce měla klást otázky: o Byly vydefinovány klíčové činnosti, které by měly být na pravidelné bázi auditovány? o Jak jsou chráněny logovací soubory? Zranitelností VŠE v této oblasti by mohla být neschopnost auditovat neúspěšná přihlášení uţivatelů do informačního systému, neboť VŠE nemá implementován systém pro bezpečnostní monitoring.



Absence IAM – řízení identit není na VŠE v současné době řešeno, i kdyţ je plánována jeho implementace. Vyuţívání řešení externích poskytovatelů by bylo moţné řízení identit získat zároveň s cloudovým úloţištěm.

7.2.2 NAPLNĚNÍ POŽADAVKŮ BCM NA ŘEŠENÍ CLOUD COMPUTINGU V této kapitole bude zhodnoceno, jak vybrané řešení virtualizace serverů, vybudování privátního cloudu a přechod do cloudu hybridního splňuje poţadavky BCM, které byly stanoveny v kapitole 3.3. Na základě strategického postupu uvedeného v kapitole 7.2, na základě výsledků analýzy poskytovatelů IaaS řešení provedeného v kapitole 6 a na základě zjištěných poţadavků kladených BCM na Cloud Computing řešení bylo zvoleno následující řešení: 







problematika samotné virtualizace serverů, resp. výběr řešení vhodného pro virtualizaci nebyl předmětem této diplomové práce. Pro navrhované Cloud Computing řešení nehraje nástroj virtualizace roli. Důvodem, proč nebyla tato problematika řešena, je také skutečnost, ţe virtualizace serverů jiţ na VŠE v současné době probíhá. pro vytvoření privátního cloudu bylo navrţeno řešení Eucalyptus, které je open sourceovým projektem a které poskytuje podporu také pro vytvoření hybridního cloudu. Software Eucalyptus byl původně vyvíjen jako součást akademického výzkumného projektu a v dnešní době se dostává na přední pozice vedoucích technologií vyuţívaných v Cloud Computingu. Řešení Eucalyptus je vhodné pro organizace velkých rozměrů, v podmínkách VŠE by poţadavkům na vytvoření privátního, resp. hybridního cloudu vyhovoval. na základě výsledků analýzy poskytovatelů IaaS řešení nejvíce vyhovuje podmínkám VŠE a poţadavkům BCM řešení společnosti GoGrid. Jak je uvedeno v kapitole 6.9 Vzájemné porovnání hodnocených řešení, GoGrid nejvíce naplňuje technická kritéria, kritéria BCM i kritéria finanční. GoGrid řešení je také vhodné pro hostování hybridních cloudů. k tomu, aby byly naplněny všechny poţadavky BCM na Cloud Computing řešení, je moţné v další fázi vyuţít řešení pro governance enStratus. Toto řešení umoţňuje řídit a monitorovat bezpečnost, řídit finance, audity, reporting a poskytuje jednotnou správu různých poskytovatelů Cloud Computingu, např. pro pozdější rozšíření. Řešení enStratus naplňuje všechny tři poţadavky BCM na Cloud Computing řešení P01 – P03.

-87/117-



7.2.2.1 P01 BEZPEČNOST A MONITORING Bezpečnost a monitoring je moţné řešit několika způsoby. Vţdy by byl řešen interně v rámci VŠE, ale při vyuţití nabídek externích poskytovatelů v rámci hybridního cloudu by byla bezpečnost řešena prostředky dodanými poskytovatelem. Poskytovatel GoGrid je vlastníkem certifikace SAS70, coţ je mezinárodně uznávaný standard vydaný americkým institutem certifikovaných auditorů AICPA. Při vybudování privátního cloudu a vyuţití nástroje Eucalyptus je také moţné získat prostředky pro řízení bezpečnosti, bezpečnostního monitoringu je však moţné dosáhnout pouze implementací dodatečné vrstvy, kterou je například governance vrstva enStratus. 7.2.2.2 P02 ZÁLOHOVÁNÍ A ARCHIVACE Kritéria pro zálohování a archivaci splňují všechna řešení. Díky virtualizaci serverů je moţné zálohovat celé serverové instance stejně jednoduše, jako je moţné zálohovat jednotlivé soubory. V případě vybudování hybridního cloudu a vyuţívání datového úloţiště externího poskytovatele by VŠE navíc získala záloţní prostředí, které by mohla vyuţívat. Záloţní prostředí by mohla VŠE získat také v rámci spolupráce s jinou institucí terciárního vzdělávání, kdy by si tak obě instituce poskytovaly prostřednictvím sítě záloţní prostředí vzájemně. 7.2.2.3 P03 DOSTUPNOST SLUŽEB Modelem hybridního cloudu se zvýší dostupnost poskytovaných sluţeb, a to především v obdobích, kdy je informační systém VŠE nejvíce zatěţován. Tím by toto řešení podporovalo specifikum VŠE SP01 Sezónnost. Po několik týdnů v roce, kdy jsou sluţby nejvíce vyuţívány, by tak nedocházelo k přetíţení systému. Díky získání dodatečné kapacity u externího poskytovatele by se VŠE mohla stát poskytovatelem cloudových sluţeb externím zákazníkům, chovala by se tak trţně a získala by dodatečné příjmy.

7.2.3 BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ Na Obr. 18 je schematicky znázorněna strategie postupu VŠE při implementaci Cloud Computing řešení podporujícího Business Continuity Management. Pro schematické znázornění byl vybrán model Balanced Scorecard. Jediná úprava, která byla provedena, je změna dimenze „Zákazníci“ na dimenzi „Studenti“. Celkem je tak moţné zde nalézt čtyři dimenze: Zaměstnanci, Procesy, Studenti a Hodnotové ukazatele. V kaţdé z dimenzí jsou znázorněny cíle a metriky. Způsob dosaţení těchto cílů je uveden v posledním sloupci. Strategická mapa je znázorněna tak, ţe první cíl je uveden v dimenzi Zaměstnanci, odkud navazují jednotlivé hybné síly na ostatní dimenze. Strategickým cílem v oblasti Zaměstnanci je „Zvýšení flexibility poskytovaných zdrojů“, čímţ se myslí poskytování zdrojů jednotlivým katedrám. Tohoto cíle je moţné dosáhnout virtualizací stávající infrastruktury. Na tento cíl navazuje strategický cíl dimenze Procesy „Optimalizace vyuţívání zdrojů“. K dosaţení tohoto cíle je jiţ zapotřebí vybudovat cloud, pro potřeby optimalizace je dostatečné vyuţívat privátní cloud. V dimenzi Studenti je umístěn cíl „Zvýšení dostupnosti sluţeb“. Tohoto cíle je moţné dosáhnout vytvořením hybridního cloudu, kdy by VŠE získala dodatečnou výpočetní kapacitu od externího poskytovatele.

-88/117-



Cíle

Metriky

Získání konkurenční výhody

Získání konkurenční výhody

% získaných nových studentů ve srovnání s jinými vysokými školami

Udržení dobrého jména VŠE

Otevření prostoru pro poskytování služeb externě

Snížení nákladů

Hodnota snížení nákladů

Zvýšení dostupnosti služeb

Zvýšení spokojenosti studentů

Vytvoření hybridního cloudu

Procesy

Optimalizace využívání zdrojů

Optimalizace využívání zdrojů

Snížení počtu serverů/zvýšení využívání kapacity

Vytvoření privátního cloudu

Zvýšení flexibility poskytovaných zdrojů katedrám

Zvýšení flexibility poskytovaných zdrojů

Zvýšení spokojenosti zaměstnanců

Virtualizace existujících serverů

Hodnotové ukazatele

Mapa strategie

Zaměstnanci

Měření přínosů navrhovaného řešení

Udržení dobrého jména VŠE

Studenti

Snížení nákladů

Zvýšení dostupnosti služeb

Realizace

Obr. 18 - Balanced Scorecard navrhovaného řešení (Zdroj: Autor)

Nejvýše umístěnými strategickými cíli jsou cíle v dimenzi Hodnotové ukazatele. Zde se nacházejí cíle „Sníţení nákladů“, „Udrţení dobrého jména VŠE“ a „Získání konkurenční výhody“. Všechny tyto cíle jsou pro VŠE ţádoucí. Díky sníţení nákladů si instituce můţe dovolit vynakládat finanční prostředky na nákup jiného vybavení, díky udrţení dobrého jména VŠE by se jí naskytla moţnost poskytovat cloudové sluţby externím odběratelům a získáním konkurenční výhody by VŠE vyhrávala v konkurenčním boji o dobré studenty.

7.2.4 FINANČNÍ ZHODNOCENÍ V této kapitole jsou stručně naznačeny cenové relace za odebírané sluţby. Rychlý přehled je uveden v následující tabulce: Název poskytovatele

Počet serverů

RAM

Cena [CZK / Cena [CZK / měsíc] rok]

Eucalyptus

-

-

-

1

GoGrid

<6

16 GB

71 862

862 344

enStratus

< 17

-

8 985

107 820

Celkem

-

-

80 847

970 164

Tab. 14 - Finanční zhodnocení navrţeného řešení (Zdroj: Autor)

Způsob platby za podporu k software Eucalyptus není bohuţel veřejně dostupný. Eucalyptus software nabízí řešení ve dvou variantách. Tou první je open source řešení, které je zcela zdarma. Druhou 1

Ceny byly přepočítávány kurzem 1USD = 17,97 CZK -89/117-



variantou je Eucalyptus Enterprise Edition, kde zákazník platí za podporu. V Enterprise edici je mu navíc poskytována podpora více platforem. U řešení GoGrid byla vybrána varianta poskytující 67 000 tzv. server RAM hodin za měsíc. GoGrid rozumí jednou RAM hodinou běţnou hodinu krát velikost RAM na cloudových serverech: 1 𝑅𝐴𝑀 ℎ𝑜𝑑𝑖𝑛𝑎 = ℎ𝑜𝑑𝑖𝑛𝑎 𝑥 𝑅𝐴𝑀 V praxi to znamená, ţe počet cloudových serverů je variabilní. Je moţné za stejnou částku odebírat 6 serverů s velikostí RAM 16 GB, nebo 12 serverů s RAM o velikosti 8 GB apod. Pro vstvu governance řešení enStratus byl zvolen plán Standard, kdy je za měsíční sazbu poskytováno řešení pro neomezený počet serverových instancí, 60 záloh za měsíc (zálohy infrastruktury zahrnují objem dat, image sluţeb nebo datových zdrojů), neomezený počet uţivatelských účtů, dodatečné sluţby (LDAP, SAML 2.0, enStratus API) a monitorování serverů zdarma. Celková cena je proto uvedena pouze orientačně, a to z výše uvedených důvodů. Cena by se změnila také podle toho, kdy by se VŠE rozhodla vyuţívat kapacity externího poskytovatele pouze v období nejvyššího zatíţení, coţ by znamenalo pouze minimální náklady na vyuţívané sluţby, ale zároveň by to mohlo přinést komplikace v rámci přenosu dat z interního prostředí do prostředí externího a zpět.

7.3 SHRNUTÍ Předmětem této kapitoly byl návrh vhodného řešení z několika pohledů. Nejprve byla provedena analýza VŠE z hlediska Business Continuity Management. Postup byl proveden podle jednotlivých fází ţivotního cyklu, ve kterých byly nejprve identifikovány klíčové procesy, následně byla provedena analýza dopadů a načrtnut plán Business Continuity. K tomu, aby byl na VŠE plán Business Continuity v současné době řešen, přispěla i skutečnost zavedení helpdesku v minulém roce (2009). [VC2010] Bohuţel však dosud ţádný plán Business Continuity na VŠE neexistuje, zaměstnanci (zejména vyučující) nemají ţádný scénář pro to, co dělat v případě, kdy by například nebyla data ISISu dostupná. Výsledkem zmapování této oblasti byla také identifikace specifik charakteristických pro VŠE. Pro konkrétní podmínky VŠE byla navrţena strategie postupu při implementaci Cloud Computing řešení. Tato strategie byla verifikována provedením modelování hrozeb pro naplnění předpokladu řízení rizik. Pro jednotlivé fáze navrhované strategie byla vybrána konkrétní řešení od existujících poskytovatelů a tato řešení byla verifikována oproti poţadavkům BCM na Cloud Computing řešení, které byly definovány v kapitole 3.3. Na závěr byla navrhovaná strategie znázorněna také pomocí Balanced Scorecard, kde je postavena proti cílům a metrikám rozmístěným ve čtyřech dimenzích. Kapitolu uzavírá finanční hodnocení navhrnovaného řešení. Za současných podmínek na VŠE panujících lze definovat moţnosti Cloud Computingu podporovat klíčové procesy následujícím způsobem: 

PR01 Zajištění studia – v současné době není moţné tento proces zcela podporovat pomocí Cloud Computing řešení. Studijní informační systém ISIS je v současné době postaven na několika aplikačních serverech (v počtu cca 7 serverů), které by v případě potřeby zvýšení kapacity mohly být doplněny virtuálními instancemi serverů v modelu Cloud Computing. Problém však je to, ţe studijní informační systém ISIS vyuţívá pouze jeden databázový server. Z tohoto důvodu by nedošlo ke zvýšení výkonnosti ISISu jako celku i v případě, ţe by

-90/117-



došlo k navýšení kapacity aplikačních serverů. K získání potřebné flexibility a výkonnosti by bylo třeba implementovat virtualizaci na úrovni datového úloţiště. Je však moţné uvaţovat o vyuţívání Cloud Computingu na počítačových učebnách. V současné době se uvaţuje o virtualizaci koncových stanic. Na některých předmětech se jiţ nyní vyuţívá virtualizace instancí, například pro správu databáze. Virtualizace by se mohla v budoucnu stát prvním vývojovým krokem ke konceptu Cloud Computingu. 



PR02 Rozvoj vědy a výzkumu – v současné době jsou katedrální servery a některé další servery virtualizovány. Tyto virtualizované instance jsou poskytovány jednotlivým pracovištím. Tato oblast by se proto mohla stát první oblastí, ve které by se dal implementovat princip Cloud Computingu. Mimo jiné by bylo moţné dosáhnout lepšího přehledu o poskytovaných instancích, o jejich bezpečnosti apod. PR03 Podpora a rozvoj hospodářské činnosti – v případě ekonomického informačního systému iFIS se setkáváme se stejným problémem, jako je tomu u ISISu. Tento systém v současné době vyuţívá také pouze jeden databázový server, proto je bez virtualizace datového úloţiště zvýšení výkonnosti celého systému z tohoto důvodu omezeno.

Díky moţnosti změny ekonomického prostředí v podmínkách terciárního vzdělávání lze předpokládat, ţe v budoucnu pravděpodobně dojde také ke změně modelu poskytování sluţeb studentům. Jiţ v blízké době je moţné, ţe studenti začnou platit školné, a stanou se tak plnohodnotnými zákazníky institucí terciárního vzdělávání odebírajícími sluţbu, stejně tak jako je tomu v komerčním sektoru. Proto je potřeba do budoucna přemýšlet o změně investic do technologie a o tom, zda je důleţité mít všechny technologické zdroje umístěny v areálu VŠE. Dalším předpokladem a pravděpodobným trendem je také to, ţe v budoucnu budou vznikat aplikace psané přímo pro cloudovou platformu, jako je tomu jiţ v případě některých zahraničních univerzit (Skandinávie, Německo, viz např. [Peritor2009]). Na tento fakt navazuje také skutečnost, ţe odborníci v oblasti Cloud Computingu budou poptávanou pracovní silou, a proto by tato příleţitost během studií mohla pomoci studentům v uplatnění na pracovním trhu. V současných podmínkách by navrhovaná strategie stála za zváţení, ale situace na akademické půdě VŠE a v rámci terciárního vzdělávání v České republice obecně není na takový trend připravena. I kdyţ investice do vybudování hybridního cloudu nejsou zanedbatelné, vybudování takového řešení by přineslo potenciál zlepšení současné situace a mohlo by instituci přinést pozitivní dopady pro budoucí rozvoj.

-91/117-



ZÁVĚR Tato diplomová práce se věnovala problematice vzájemného vyuţití konceptů Business Continuity Management a Cloud Computing. V rámci této práce bylo stanoveno několik cílů. Tím prvním byla identifikace vazby konceptu Cloud Computing na Business Continuity Management. Tento cíl byl splněn nalezením tří základních oblastí, ve kterých se oba tyto koncepty prolínají. Mezi tyto oblasti patří bezpečnost a monitoring, zálohování a archivace a dostupnost sluţeb. Druhým cílem této práce byla charakteristika sektoru terciárního vzdělávání a snaha o vystihnutí specifik tohoto sektoru v návaznosti na definované oblasti moţného propojení obou výše jmenovaných konceptů. Tento cíl byl splněn v kapitole 4, kde byla vedle poţadavků definována také další specifika sektoru terciárního vzdělávání, na které byl později kladen zřetel při výběru vhodného řešení v konkrétních podmínkách. Třetím cílem této práce bylo multikriteriální srovnání řešení Infrastructure-as-a-Service, a to s ohledem na srovnání řešení jak podle technických a finančních kritérií, tak také podle kritérií, které vycházejí z poţadavků kladených konceptem Business Continuity Management na Cloud Computing řešení. Naplnění tohoto cíle je obsahem kapitoly 6 a její výsledek byl pouţit jako podklad pro návrh praktického řešení. Čtvrtým cílem této práce byla identifikace potenciálu Business Continuity Management a Cloud Computing v podmínkách Vysoké školy ekonomické v Praze. Tento cíl byl naplněn v kapitole 5 identifikací moţných řešení vhodných pro zvýšení Business Continuity na VŠE. Po splnění výše uvedených cílů bylo moţné navrhnout praktické Cloud Computing řešení pro konkrétní podmínky VŠE. Toto řešení vychází nejen z výsledků předchozích kapitol, ale je také zaloţeno na konkrétních podmínkách VŠE, které byly zjištěny na základě Informační strategie VŠE, Výroční zprávy za minulý rok (2009) a několika schůzek se zaměstnanci Výpočetního centra. Praktický návrh řešení byl zaměřen především na vyuţití konceptu IaaS v rámci Cloud Computingu, které úzce souvisí s virtualizací a implementací hybridního cloudu. Bylo identifikováno, ţe podpora dvou ze tří klíčových procesů VŠE pomocí Cloud Computing řešení by za současných podmínek nebyla moţná, neboť oba dva hlavní systémy podporující tyto procesy vyuţívají pouze jednoho databázového serveru. Nebylo by proto moţné navýšit výkonnost aplikací jako celku alespoň do té doby, neţ by bylo rozhodnuto o virtualizaci datového úloţiště. Třetí z procesů Rozvoj vědy a výzkumu by v dnešní době bylo moţné konceptem Cloud Computing podporovat. V současné době jiţ probíhá virtualizace některých serverů pracovišť nebo alespoň probíhají jednání o moţnostech virtualizace. Bylo by proto moţné začít princip Cloud Computingu v této oblasti implementovat. I kdyţ se zdá, ţe by nebylo moţné plně podporovat všechny tři klíčové procesy VŠE konceptem Cloud Computing, navrhované řešení je v souladu s cíli stanovenými v Informační strategii VŠE. Mezi těmito cíli je uvedena virtualizace serverů a datových úloţišť, zavedení systému pro řízení identit, udrţení funkčního a spolehlivého systému zálohování, archivace a udrţení a posilování bezpečnosti IS/ICT. Všech těchto cílů by bylo moţné dosáhnout implementováním navrhovaného Cloud Computing řešení za současné podpory Business Continuity Management instituce. Stálo by proto za zváţení, zda by nebylo moţné implementovat alespoň část navrhovaného řešení, která by tyto cíle mohla zajistit. Vedle technické stránky zhodnocení řešení je však také důleţité brát v úvahu stránku ekonomickou a procesní. Díky tomu, ţe se v blízké budoucnosti změní ekonomické prostředí v sektoru terciárního -92/117-



vzdělávání a studenti se stanou skutečnými zákazníky institucí, je moţné předpokládat, ţe také dojde ke změně modelu poskytování sluţeb. Nepochybně dojde také ke změně poptávky na trhu práce a studenti technických oborů budou vyţadovat moţnost vzdělávat se v oblasti Cloud Computingu. I z tohoto důvodu by bylo vhodné zváţit moţnost vyuţívání cloudových sluţeb, a to nejen na úrovni infrastruktury, ale také na úrovni platformy a software. Právě zaměření této práce na vyuţití Cloud Computing řešení v oblasti infrastruktury je hlavním omezením této diplomové práce. Pro další rozšíření této problematiky lze navrhnout analýzu vhodnosti vyuţití konceptu také na úrovni platformy a software. Dalšími omezeními této práce jsou do jisté míry specifika VŠE. Lze předpokládat, ţe Cloud Computing by pro naplnění poţadavků Business Continuity Management v prostředí jiné instituce terciárního vzdělávání měl zcela jiný potenciál.

-93/117-



POUŽITÁ LITERATURA [Appavoo2010] APPAVOO, Jonathan. – WATERLAND, Amos. – SILVA, Dilma Da. – UHLIG, Volkmar. a další. Providing a Cloud Network Infrastructure on a Supercomputer in HPDC’10, červen 20–25, 2010. Chicago, USA. c2010. ISSN: 978-1-60558-9428/10/06. [Assuncao2009] ASSUNCAO, Marcos Dias de. – COSTANZO, Alexandre di. Evaluating the CostBenefit of Using Cloud Computing to Extend the Capacity of Clusters in HPDC’09, červen 11-13, 2009. Mnichov, Německo. c2009. ISSN: 978-1-60558-587-1/09/06. [BCI2007] Good Practice Guidelines 2008: A Management Guide to Implementing Global Good Practice in Business Continuity Management. Business Continuity Institute Guidelines. c2007. [BCI2010a] Good Practice Highlights 2010: Edited Highlights of the Good Practice Guidelines: Global Edition. Business Continuity Institute Guidelines. c2010. [Billsberry2004] BILLSBERY, B. Business Continuity Management. What? Why? How? VEGA Group PLC, UK. Whitepaper. c2004. Dostupný z WWW: . [Carr2009] CARR, Nicholas. The Big Switch: Rewiring the World, from Edison to Google. W. W. Norton & Company, 2009. New York, USA. ISBN: 978-0-393-33394-7. [Catteddu2009] CATTEDDU, Daniele. – HOGBEN, Giles. Cloud Computing: Benefits, risks and recommendations for information security. ENISA (European Network and Information Security Agency) report. c2009. Dostupný z WWW: . [Cerna2010] ČERNÁ, Andrea. Využití open source software ve veřejné správě ČR. Diplomová práce na Vysoké škole ekonomické v Praze na Katedře informačních technologií. c2010. [CSA2010a] Cloud Security Alliance. Domain 12: Guidance for Identity & Access Management V2.1. The Cloud Security Alliance. c2010. Dostupný z WWW: . [CSA2010b] Cloud Security Alliance. Top Threats to Cloud Computing V1.0. The Cloud Security Alliance. c2010. Dostupný z WWW: . [Curda2009] ČURDA, Vít. Cloud computing – porovnání dostupných řešení. Bakalářská práce na Vysoké škole ekonomické v Praze na Katedře informačních technologií. c2009. [Datamonitor2007] Ensuring business continuity in higher education IT: Preparing for the unexpected. Datamonitor whitepaper. c2007. [Denault2004] DENAULT, Victoria M. Business Continuity for „Dummies“. NEDRIX Conference. c2004. Dostupný z WWW: . -94/117-



[Educause2010] Shaping the Higher Education Cloud. EDUCAUSE a NACUBO Whitepaper. c2010. Dostupný z WWW: . [Eucalyptus2010a] Eucalyptus Systems. Five Steps to Enterprise Cloud Computing. Eucalyptus Systems Whitepaper. c2010. [Eucalyptus2010b] Eucalytpus Systems. Cloud Computing and Open Source: IT Climatology is Born. Eucalyptus Systems Whitepaper. c2010. [Feuerlicht2008] FEUERLICHT, Jiří. Enterprise Computing: Concepts, Standards and Architectures. Vysoká škola ekonomická v Praze, Nakladatelství Oeconomica, 2008. Praha, Česká republika. ISBN: 978-80-245-1367-6. [Feuerlicht2010] FEUERLICHT, George. – GOVARDHAN, Shyam. Impact of Cloud Computing: Beyond a Technology Trend in Systémová integrace 2010. c2010. [Furht2010] FURHT, Borko. – ESCALANTE, Armando. Handbook of Cloud Computing. Springer Science+Business Media, 2010. New York, USA. ISBN: 978-1-4419-6523-3. [Galup2007] GALUP, Stuart. - DATTERO, Ronald. - JIM, Quan J. - CONGER, Sue. Information Technology Service Management: An Emerging Area for Academic Research and Pedagogical Development. in Sigmis-CPR'07, Missouri, USA. c2007. [Gatewood2009] GATEWOOD, Brent. Clouds on the information horizon: How to avoid the storm. Lenexa, 07-08/2009. Vol. 43, Iss. 4. ISSN: 15352897. [Gilbert2010] Gilbert, Jan. Business Continuity Management Legislations, Regulations and Standards. Business Continuity Institute. c2010. Dostupný z WWW: . [Golden2008] GOLDEN, Bernard. Virtualization for Dummies. Wiley Publishing, Indiana, USA. c2008. ISBN: 978-0-470-14831-0. [Gulachek2005] GULACHEK, Bernard. Business Continuity Planning: Process, Impact, and Implications. University of Minnesota. c2005. [Hapl2010] HAPL, Martin. Implementace SaaS BI Platformy v Cloudu in Systémová integrace 2010. GoodData. c2010. [Holden2009] HOLDEN, Edward P. – KANG, Jai W. – DIANNE, Bills P. – ILYASSOV, Mukhtar. Databases in the Cloud: a Work in Progress in Sigite’09, říjen 22-24, 2009. c2009. Fairfax, USA. ISSN: 978-1-60558-765-3/09/10. [Hugos2010] HUGOS, Michael. – HULITZKY, Derek. Business in the Cloud: What Every Business Needs to Know About Cloud Computing. John Wiley & Sons, Inc. New Jersey, USA. c2011. ISBN: 978-0-470-61623-9. [Hurwitz2010]HURWITZ, Judith. – BLOOR, Robin. – KAUFMAN, Marcia. – HALPER, Fern. Cloud Computing for Dummies. Wiley Publishing, Indiana, USA. c2010. ISBN: 978-0-47048470-8. [Katz2009] KATZ, Richard N. – GOLDSTEIN, Philip J. – YANOSKY, Ronald. Demystifying Cloud Computing for Higher Education. EDUCAUSE Center for Applied Research. Research Bulletin. c2009. [cit. 2010-10-10]. Dostupný z WWW: .

-95/117-



[Konstantinou2009] KONSTANTINOU, Alexander V. – EILAM, Tamar. – KALANTAR, Michael. – TOTOK, Alexander A. a další. An Architecture for Virtual Solution Composition and Deployment in Infrastructure Clouds in VTDC’09, červen 15, 2009. Barcelona, Španělsko. c2009. ISSN: 978-1-60558-580-2/09/06. [Lee2010] LEE, Gunho. – PARTHASARATHY, Ranganathan. – TOLIA, Niraj. – KATZ, Randy H. Topology-Aware Resource Allocation for Data-Intensive Workloads. APSys 2010, Indie. c2010. ISSN: 978-1-4503-0195-4/10/08. [Lenk2009] LENK, Alexander. – KLEMS, Markus. – NIMIS, Jens. – TAI, Stefan. – SANDHOLM, Thomas. What’s Inside the Cloud? An Architectural Map of the Cloud Landscape. CLOUD’09. c2009. Vancouver, Kanada. ISSN: 978-1-4244-3713-9/09. [Litoiu2010] LITOIU, Marin. – WOODSIDE, Murray. – WONG, Johny. – NG, Joanna. – ISZLAI, Gabriel. A Business Driven Cloud Optimization Architecture in SAC’10, březen 22-26, 2010. Sierre, Švýcarsko. c2010. ISSN: 978-1-60558-638-0/10/03. [Marks2010] MARKS, Eric A. – LOZANO, B. Executive’s Guide to Cloud Computing. John Wiley & Sons, Inc., New Jersey. c2010. ISBN: 978-0-470-52172-4. [Martanova2010] MARTANOVÁ, Kateřina. Vztah BCM a ITSCM. RWE Transgas, prezentace. c2010. [cit. 2010-10-03]. [Mather2009] MATHER, Tim. – KUMARASWAMY, Subra. – LATIF, Shaled. Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance. O’Reilly Media, California, USA. c2009. ISBN: 978-0-596-80276-9. [Osecky2009] OSECKÝ, Michal. Kategorizace služeb poskytovaných v rámci Cloud Computing. Bakalářská práce na Vysoké škole ekonomické v Praze na Katedře informačních technologií. c2009. [Pirani2007] PIRANI, Judith A. - YANOSKY, Ronald. Shelter from the Storm: IT and Business Continuity in Higher Education. Educause Center for Applied Research. c2007. [Pohorelsky2002] POHOŘELSKÝ, Pavel. Zálohování a archivace dat. Mendlova zemědělská a lesnická univerzita v Brně. c2002. Dostupný z WWW: . [Prodelal2010] PRODĚLAL, Jaroslav. Cloud computing – efektivní využívání a řízení prostředků ICT in Systemová integrace 2010. OldanyGroup. c2010. [Rittinghouse2005] RITTINGHOUSE, John W. - RANSOME, James F. Business Continuity and Disaster Recovery for InfoSec Managers. Elsevier Digital Press, MA, USA. c2005. ISBN: 978-1-55558-339-2. [Rittinghouse2010] RITTINGHOUSE, John W. – RANSOME, James F. Cloud Computing: Implementation, Management, and Security. Taylor and Francis Group, LLC, USA. c2010. ISBN: 978-1-4398-0680-7. [Snedaker2007] SNEDAKER, Susan. Business Continuity & Disaster Recovery for IT Professionals. Syngress Publishing, Inc, USA. c2007. ISBN: 978-1-59749-172-3. [Stenzel2010] STENZEL, Joe et al. CIO Best Practices: Enabling Strategic Value with Information Technology. John Wiley & Sons, Inc. New Jersey, USA. c2011. ISBN: 978-0-47063540-7. -96/117-



[Stratus2010] Stratus Technologies. Server Virtualization and Cloud Computing: Four Hidden Impacts on Uptime and Availability. Stratus Technologies WhitePaper. c2010. Dostupný z WWW: . [Sun2007] Service Level Management. Sun Microsystems Whitepaper. Sun Microsystems, Inc. c2007. [cit. 2010-10-03]. Dostupný z WWW: . [Svoboda2009] SVOBODA, Jiří. Cloud Computing in Systémová integrace 2/2009. T-Mobile Czech Republic. c2009. Dostupný z WWW: . [Trcka2009] TRČKA, Adam. Strategie dalšího rozvoje informačního systému VŠE Praha. Diplomová práce na Vysoké škole ekonomické v Praze na Katedře informačních technologií. c2009. [VC2010] Výroční zpráva za rok 2009. Výpočetní centrum, VŠE. Květen, 2010. c2010. [Velte2010] VELTE, Anthony T. – VELTE, Toby, J. – ELSENPETER, Robert. Cloud Computing: A Practical Approach. McGraw-Hill Companies, USA. c2010. ISBN: 978-0-07-1626958. [VSE2010] Informační strategie Vysoké školy ekonomické na období 2011 – 2015. Výpočetní centrum, VŠE. Verze 1.2. Dokument před oficiálním vydáním. c2010. [Wolf2005] WOLF, Chris. – HALTER, Erick M. Virtualization From Desktop to the Enterprise. Apress, California, USA. c2005. ISBN: 1-59059-495-9. [Wood2009] WOOD, Gary a kol. Security Implications of Cloud Computing. Information Security Forum. c2009.

INTERNETOVÉ ZDROJE [Amazon2010] Amazon.com. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW: . [BCI2010b] The Business Continuity Institute. Webová prezentace. c2010. [cit. 2010-07-10]. Dostupný z WWW: . [Brodkin2008] BRODKIN, Jon. Gartner: Seven cloud-computing security risks in InfoWorld: Security Central. c2008. [cit. 2010-10-09]. Dostupný z WWW: . [Bittman2008] BITTMAN, Tom. Cloud Computing and K-12 Education. c2008. [cit. 2010-10-11]. Gartner blogs. Dostupný z WWW: . [BusDict2010] Business Dictionary. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [CC2010] Cloud Computing Defined. Webová prezentace. c2010. [cit. 2010-08-17]. Dostupný z WWW: . -97/117-



[CESNET2010] CESNET. O nás. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [CIO2010] CIO Business World. Virtualizace v oblasti školení a vzdělávání in CIO Business World. Listopad, 2010. Případová studie. c2010. [cit. 2010-11-14]. Dostupný z WWW: . [Clarke2009] CLARKE, Mark. Cloud computing as a business continuity plan in Tectonic. c2009. [cit. 2010-10-19]. Dostupný z WWW: . [Com2010] Cloud – Computer Dictionary Definition. Computer Desktop Encyclopedia. c2010. [cit. 2010-11-24]. Dostupný z WWW: . [CSA2009] Sampling of issues we are addressing. Cloud Security Alliance. c2009. [cit. 2010-10-09]. Dostupný z WWW: . [Cooney2009] COONEY, Michael. IBM touts encryption innovation in Computerworld. c2009. [cit. 2010-10-01]. Dostupný z WWW: . [Dougherty2001] DOUGHERTY, Dale. LAMP: The Open Source Web Platform. Leden, 2001. c2001. [cit. 2010-10-09]. Dostupný z WWW: . [ElasticHosts2010] ElasticHosts. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW: . [EnStratus2010] enStratus. Webová prezentace. c2010. [cit. 2010-10-30]. Dostupný z WWW: . [Fogarty2010] FOGARTY, Kevin. Which Apps Should You Move to the Cloud? 5 Guidelines in CIO Online. c2010. [cit. 2010-09-05]. Dostupný z WWW: . [Fox2009] FOX, Armando. Cloud computing, law enforcement and business continuity. Above the Clouds, A Berkeley View of Cloud Computing. Blog. c2009. [cit. 2010-10-23]. Dostupný z WWW: . [Glotzbach2008] GLOTZBACH, Matthew. What we learned from 1 million businesses in the cloud. Google blog. c2008. [cit. 2010-10-24]. Dostupný z WWW: . [GoGrid2010] GoGrid. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW: . [Houser2010] HOUSER, Pavel. Cloud, bezpečnost a ERP systémy: podle čeho volit? in SecurityWorld. c2010. [cit. 2010-09-17]. Dostupný z WWW: .

-98/117-



[ICM2004] ICM Computer Group. Business Continuity for Beginners in Continuity Central. Prosinec, 2004. c2004. [cit. 2010-11-18]. Dostupný z WWW: . [ICM2005] Crisis Management. American Institute for Crisis Management (ICM). c2005. [cit. 201011-24]. Dostupný z WWW: . [Info2010] European Union defines cloud computing. Information Age. Únor, 2010. c2010. [cit. 201011-24]. Dostupný z WWW: . [InvestorWords2010] InvestorWords. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [ISO2010] International Organization for Standardization. Webová prezentace. c2010. [cit. 2010-1001]. Dostupný z WWW: . [ITSM2010] ITSM Encyclopedia. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [Karnam2010] KARNAM, Sridhar. Anything-as-a-Service (XaaS): Future of cloud computing. Červen, 2010. c2010. [cit. 2010-09-29]. Dostupný z WWW: . [Key2003] KEY, Russell. QuickStudy: Extensible Access Control Markup Language (XACML) in Computerworld. Květen, 2003. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [Kirk2010] KIRK, Jeremy. Update: WikiLeaks‘ Assange arrested in London, denied bail in ComputerWorld. Prosinec, 2010. c2010. [cit. 2010-12-10]. Dostupný z WWW: . [Llorente2009] LLORENTE, Ignacio M. Building Your Open Source Private Cloud in Opensource Magazine. Únor, 2009. c2009. [cit. 2010-11-06]. Dostupný z WWW: . [Meier2005] MEIER, J.D. – MACKMAN, Alex. – WASTELL, Blaine. How To: Create a Threat Model for a Web Application at Design Time. MSDN Library, 2005. c2005. [cit. 201011-20]. Dostupný z WWW: . [Mitrano2010] MITRANO, Tracy. Outsourcing and Cloud Computing for Higher Education. c2010. [cit. 2010-10-22]. Dostupný z WWW: . [Montero2010] MONTERO, Ruben S. Elastic Management of Computing Clusters. c2010. [cit. 201011-09]. Dostupný z WWW: . [Nair2009] NAIR, Kiran C. Hands On: Building a Private Cloud using Open Source Solutions Part 1: Setting up Cloud Infrastructure using Eucalyptus Open Cloud Platform. c2009. [cit. 2010-11-04]. Dostupný z WWW: . -99/117-



[Noska2010] NOSKA, Martin. 10 důvodů, proč je open source dobrou volbou in Computerworld. Listopad, 2010. c2010. [cit. 2010-11-16]. Dostupný z WWW: . [Opsview2010] Opsview Development Team. Business Continuity in the Cloud Era in TechWorld. c2010. [cit. 2010-10-20]. Dostupný z WWW: . [Pasnet2010]

PASNET. Online. c2010. .

[cit.

2010-12-04].

Dostupný

z WWW:

[Peritor2009] AWS Case Study: Peritor. Případová studie. Červen, 2009. c2009. [cit. 2010-11-22]. Dostupný z WWW: . [Potter2009] POTTER, Kurt. Gartner Integrated IT Spending Perspectives: Building Your Budget for 2010. Prosinec, 2009. c2009. [cit. 2010-10-03]. Dostupný z WWW: . [Pribyl2010] PŘIBYL, Tomáš. Jak zajistit continuitu podnikání in SecurityWorld. c2010. [cit. 201010-03]. Dostupný z WWW: . [Pyle2010] PYLE, Chris. How to Ensure Business Continuity with Cloud Computing in eWeek. c2010. [cit 2010-10-20]. Dostupný z WWW: . [Rackspace2010] Rackspace Cloud. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW: . [ReliaCloud2010] ReliaCloud. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW: . [Schneier2009] SCHNEIER, Bruce. Homomorphic Encryption Breaktrough. c2009. [cit. 2010-10-01]. Dostupný z WWW: . [TechTarget2010] TechTarget. Search Security. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW: . [Vellante2010] VELLANTE, David. Business Continuity 2010: How Virtualization and Cloud Computing Change the Game. c2010. [cit. 2010-10-21]. Dostupný z WWW: . [Vogel2010a] VOGEL, Valerie. Business Continuity Management (ISO 15). Information Security Guide. c2010. [cit. 2010-10-09]. Dostupný z WWW: . [Vogel2010b] VOGEL, Valerie. Cloud Computing Security. Information Security Guide. c2010. [cit. 2010-10-21]. Dostupný z WWW: . -100/117-



[Wang2009] WANG, Chenxi. Cloud Security Front And Center. Forrester Blogs. c2009. [cit. 201010-09]. Dostupný z WWW: . [Wardley2010] WARDLEY, Simon. What is Cloud? Březen, 2010. c2010. [cit. 2010-11-24]. Dostupný z WWW: . [Webopedia2010] Webopedia. Online. c2010. .

[cit.

2010-12-04].

Dostupný

z WWW:

[Xymon2010] Xymon. Systém pro monitorování systémů a sítě. Webová prezentace. c2010. [cit. 2010-10-31]. Dostupný z WWW: . [Zahorova2010] ZÁHOROVÁ, Zuzana. IT ve školství s technologiemi Citrix in CIO Business World. Listopad, 2010. c2010. [cit. 2010-11-14]. Dostupný z WWW: . [Zoner2010] Obvyklé metody zálohování dat. Zoner Software. c2010. [cit. 2010-11-26]. Dostupný z WWW: .

-101/117-



TERMINOLOGICKÝ SLOVNÍK Termín

Zkratka

Význam

Analýza dopadů

-

Analýza zaměřená na identifikaci rizik, kterým je společnost vystavena a která by mohla znamenat náhlou ztrátu klíčových funkcí podniku. [BusDict2010]

Application Programming Interface

API

Soubor postupů, protokolů a nástrojů pro vývoj softwareových aplikací. [Webopedia2010]

Authentication, Authorization, and Accounting

AAA

Tři základní součásti protokolu zabezpečení online transakcí (především při přenosu finančních dat): (1) autentizace, (2) autorizace a (3) účtování. [BusDict2010]

Balanced Scorecard

BSC

Praktika, která kombinuje výsledky minulého vývoje společnosti (finanční kritéria) s budoucím vývojem (např. spokojenost zákazníků, učení se organizace, procesní oblast). [BusDict2010]

Best practices

-

Metody a techniky, kterými je moţné dosáhnout lepších výsledků neţ za pouţití jiných. [BusDict2010]

Bod obnovy

-

Objem nebo rozsah ztracených dat, který je společnost ochotna tolerovat z hlediska nezbytných podnikových systémů. [Snedaker2007]

Business Continuity Management

BCM

Holistický přístup k řízení společnosti, jenţ identifikuje potenciální dopady na organizaci, které by mohly ohrozit efektivní fungování společnosti, a poskytuje rámec pro vybudování pruţného systému schopného reagovat na krizové situace, a hájit tak zájmy zainteresovaných stran. [BCI2010b]

Business Impact Analysis

BIA

viz Analýza dopadů

Cache/cacheování

-

Vysokorychlostní mechanismus ukládání dat. Můţe se jednat buď o vyhrazenou částí hlavní paměti, nebo o samostatné zařízení poskytující úloţný prostor. [Webopedia2010]

Cash flow

CF

Příjmové a výdajové finanční toky, které reprezentují provozní činnosti firmy. V účetnictví je cash flow rozdíl mezi objemem finančních prostředků dostupných na začátku období a objemem prostředků na konci tohoto období. [BusDict2010]

CESNET

-

Síť pro výzkum. CESNET je sdruţení zaloţené vysokými školami a Akademií věd České republiky v r. 1996. Provozuje a rozvíjí páteřní akademickou počítačovou síť ČR. Současná generace sítě se nazývá CESNET2. [CESNET2010]

-102/117-



Cloud

-

Síťový cloud. Tento pojem je pouţíván v oblasti telekomunikace jako veřejný prostor na přenosových linkách. V kontextu Cloud Computingu se pojmem cloud rozumí veřejná nebo soukromá elastická infrastruktura poskytující sluţby několika odběratelům a umoţňující přenos dat mezi subjekty. [Webopedia2010]

Cloud Computing

CC

1. Umístění a přístup k aplikacím a datům pomocí internetového prohlíţeče častěji, neţ pomocí softwaru instalovaného na koncové stanici nebo na serveru. 2. Na internetu zaloţené sdílení informací, IT zdrojů a softwarových aplikací, které je poskytováno koncovým stanicím a mobilním zařízením „na poţádání“. 3. Vyuţívání internetu pro přístup k webovým aplikacím, webovým sluţbám a IT infrastruktuře jako ke sluţbě. [CC2010]

Cloudware

-

Software, který je provozován na serverech umístěných v cloudu (viz cloud). [Webopedia2010]

Consumerization

-

Trend, kdy uţivatel začne pouţívat určitou informatickou sluţbu ve svém soukromém ţivotě, oblíbí si ji a postupně ji přenese do svého profesního ţivota. [Bittman2008]

Continuity Analysis

Requirements CRA

Analýza, která se vyuţívá k odhadu zdrojů a sluţeb, které vyţaduje kaţdá činnost, aby mohla být obnovena do běţného provozu organizace. [BCI2010a]

Cost-benefit analýza

CBA

Proces vyčíslení nákladů a výnosů, které by přineslo určité rozhodnutí, program nebo projekt v porovnání s jinou alternativou. [BusDict2010]

Čas obnovy

-

Čas, za který je moţné obnovit narušené systémy a zdroje, tj. systémový čas obnovy. [Snedaker2007]

Data mining

DM

Skupina databázových aplikací, které hledají skrité vzorce ve skupině dat, která mohou být pouţita pro předpověď budoucího vývoje. [Webopedia2010]

eXtensible Access Markup Language

Control XACML

Jazyk poskytující stejnou definici jako SAML (viz SAML), ale definuje navíc prostředek udrţení bezpečnostní politiky organizace. [Key2003]

eXtensible Markup Language

XML

Specifikace vytvořená konzorciem W3C. Umoţňuje návrhářům vytvořit vlastní tagy, definice, přenos, validaci a interpretaci dat mezi aplikacemi a organizacemi. [Webopedia2010]

Governance

-

Ustanovení politik a průběţné monitorování jejich správné implementace v rámci organizace. [BusDict2010] -103/117-



Grid computing

-

Způsob propojení sítě. Grid Computing spojuje nevyuţívané cykly všech počítačů do sítě za účelem vyřešení problému příliš velkého pro samostatný stroj. [Webopedia2010]

Homomorfní šifrování

-

Způsob šifrování, kdy je na prostém textu provedená specifická algebraická operace a jiná algebraická operace je provedena na šifrovaném textu. [Schneier2009]

Hosting

-

Spojení systémů, kdy uţivatel můţe přistupovat k hostu (hostitelskému systému/počítači) vzdáleně. Typicky nabízí infrastrukturu pro poskytování sluţby. [Webopedia2010]

Identity & Access Management

IAM

Rámec podporující řízení elektronických identit a přístupů. [TechTarget2010]

Informační technologie

a

komunikační ICT

Obor nebo vývoj a vyuţívání technologie ke zpracování informací. [Webopedia2010]

Information Technology ITIL Infrastructure Library

Široce uznávaný přístup k řízení IT sluţeb. Poskytuje sadu best practices, je podporován a akreditován mnoha organizacemi, stejně tak jako implementačními nástroji a nástroji pro ohodnocení. [Webopedia2010]

Infrastructure as a Service

IaaS

Poskytování virtuálního prostoru a ostatního hardware a operačních systémů, které mohou být řízeny prostřednictvím API sluţeb. [Rittinghouse2010]

Instant messaging

IM

Typ komunikace prostřednictvím internetu umoţňující navázat soukromou konverzaci s jiným uţivatelem. [Webopedia2010]

In-house

-

Umístěný v rámci společnosti. [InvestorWords2010]

IT Service Management

Continuity ITSCM

Cílem procesu z rámce ITIL je podporovat celkový proces Business Continuity Management zajištěním všech IT procesů (systémy, síť, aplikace, telekomunikace atd.). [ITSM2010]

Learning Management System

LMS

viz Řídící výukový systém

Linux

-

Volně distribuovatelný open source operační systém, který lze spustit na mnoha hardwareových platformách. [Webopedia2010]

Maximální tolerovatelná doba odstávky

Maximální doba, po kterou je business ochoten tolerovat neexistenci nebo nedostupnost určité funkce podniku. [Snedaker2007]

Maximum Tolerable Downtime

MTD

viz Maximální tolerovatelná doba odstávky

Middleware

-

Software, který spojuje dvě oddělené aplikace. [Webopedia2010]

-104/117-



Mirroring

-

Proces kopírování dat z jedné lokace do úloţného prostoru, a to v reálném čase. [Webopedia2010]

Modelování hrozeb

-

Proces optimalizace bezpečnosti sítě pomocí identifikace cílů a zranitelností a moţností minimalizace hrozeb. [TechTarget2010]

Ohodnocení rizik

-

Analýza, která je pouţívána k odhadu pravděpodobnosti dopadu neznámé hrozby na určitou funkci organizace. [BCI2010a]

One time password

OTP

Heslo, které je platné pouze pro jednu operaci přihlášení. [TechTarget2010]

Open-source

OS

Program nebo software, kde je zdrojový kód dostupný veřejnosti za účelem vyuţití a modifikace, a to zdarma, bez poplatku. [Webopedia2010]

Operational Level Agreement

OLA

Smlouva, která definuje, jak IT skupiny v rámci jedné organizace zajistí dodání/poskytování sluţby nebo sady sluţeb. [TechTarget2010]

Outsourcing

-

Vyhledávání zdrojů mimo vlastní organizaci, obvykle za účelem sníţení nákladů nebo vyuţití schopností jiné entity. [Webopedia2010]

PASNET

-

Praţská akademická počítačová síť. Vysokorychlostní metropolitní síť určená pro přenos obecných digitálních dat. Zajišťuje propojení počítačových LAN sítí praţských pracovišť vysokých škol a Akademie věd ČR. [Pasnet2010]

Pay-as-you-go

-

Metoda účtování za sluţby, kdy je odběratel účtován za skutečný objem odebrané sluţby. [BusDict2010]

Phishing

-

Podvodné získání osobních nebo citlivých dat z osobních počítačů. [BusDict2010]

Platform as a Service

PaaS

Umoţňuje zákazníkům vyvíjet nové aplikace za vyuţití API, které je umístěno a konfigurováno u poskytovatele sluţby. [Rittinghouse2010]

Pracovní čas obnovy

-

Čas, za který je nutné obnovyt všechny vstupy pro proces, lidské zdroje, dokumenty, legislativní zajištění apod. [Snedaker2007]

Random Access Memory

RAM

Typ paměti počítače, ke které je moţné přistupovat náhodně, tj. bez závislosti na předcházejících bytech. [Webopedia2010]

Recovery Point Objective

RPO

viz Bod obnovy

Recovery Time Objective

RTO

viz Čas obnovy

Red Hat Enterprise Linux

RHEL

Komerční distribuce Linuxu. [Webopedia2010]

Replikace

-

Proces vytvoření a řízení duplicitní verze datového zdroje. [Webopedia2010]

-105/117-



Return on Investment

ROI

Výnosnost aktiv měřené jako poměr čistých příjmů a průměrného zaměstnaného kapitálu. [BusDict2010]

Risk Assessment

RA

viz Ohodnocení rizik

Role Based Access Control

RBAC

Systém řízení přístupu ke zdrojům/aplikacím zaloţený na uţivatelských rolích. [Webopedia2010]

Rollback

-

Navrácení uskutečněné činnosti za účelem provedení nové nebo alternativní. [BusDict2010]

Řídící výukový systém

-

Systém pro správu, dokumentaci, reporting a řízení programů školení, výuky, e-learningu apod. [BusDict2010]

Security Assertion Language

Markup SAML

Definuje, jak jsou identity a informace o přístupu přenášeny a zprostředkovány mezi organizacemi, aniţ by byla narušena jejich interní bezpečnost. [Key2003]

Service Level Agreement

SLA

Smlouva mezi poskytovatelem sluţby a zákazníkem, která určuje povahu, kvalitu a rozsah poskytované/odebírané sluţby. [BusDict2010]

Service Level Management

SLM

Monitorování a řízení kvality sluţeb za účelem dosaţení KPI. [TechTarget2010]

Service Provisioning Markup SPML Language

Jazyk zaloţený na XML umoţňující výměnu informací mezi aplikacemi a organizacemi. [TechTarget2010]

Simple Object Access Protocol

SOAP

Protokol definující přeposílání zpráv zaloţený na XML. Je vyuţíván k šifrování informace posílané prostřednictvím webové sluţby. [Webopedia2010]

Single sign-on

SSO

Autentizační proces, kde uţivatel/klient zadává jedno uţivatelské jméno a heslo, a získá tak přístup k mnoha aplikacím/zdrojům v rámci společnosti. [Webopedia2010]

Software as a Service

SaaS

Software licencovaný třetí stranou, který je zákazníkovi dostupný v případě potřeby. Většinou se jedná o software poskytovaný prostřednictvím sítě internet. [Rittinghouse2010]

Superpočítač

-

Rychlejší typ počítače. Jsou obvykle velmi nákladné a běţí na nich specializované aplikace vyţadující velký objem matematických výpočtů. [Webopedia2010]

SUSE Linux Enterprise Server

SLES

Komerční verze distribuce Linuxu. [Webopedia2010]

Threat Modeling

-

viz Modelování hrozeb

Virtual Machine

VM

Operační prostředí umístěné na jednom počítači, které se chová, jako by bylo umístěné na samostatném počítači. [Webopedia2010]

-106/117-



Virtual Machine Monitor

VMM

Hostující program, násobného počtu [Webopedia2010]

Voice over IP

VoIP

Kategorie hardware a software, která umoţňuje uţivatelům vyuţívat internetu jako prostředku pro přenos telefonních hovorů posíláním dat prostřednictvím IP. [Webopedia2010]

Web 2.0

-

Termín popisující druhou generaci WWW. Je zaměřen na vzájemnou spolupráci lidí a sdílení informací online. Uţivatelé se stávají tvůrci obsahu. [Webopedia2010]

Work Recovery Time

WRT

viz Pracovní čas obnovy

-107/117-

který umoţňuje provoz identických prostředí.



PŘÍLOHA A – SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ Strengths   

Weaknesses

Opportunities    

  

Výsledky dosaţené v minulých letech Stabilní prostředí s velkou společenskou prestiţí a existenční budoucností Moţnost spolupráce se studenty

Platové podmínky v resortu školství Technologická nekázeň Stagnující tendence vynakládání prostředků na informační technologie

Threats

Získávat zdroje financování z fondů rozvojových projektů a grantů Spolupráce se zahraničními univerzitami Vyuţívat sluţeb CESNETu, PASNETu, EUNISu Vyuţívat slev pro školy

   

Zastarávání informačních technologií Limitující systém odměňování Neuváţený outsourcing Očekávaný nárůst potřeby finančních prostředků na provoz IS/ICT

Tab. 15 - SWOT analýza informatických útvarů (Zdroj: [VSE2010])

-108/117-



PŘÍLOHA B – SEZNAM SERVERŮ PROVOZOVANÝCH NA VŠE Označení Operační systém serveru

Popis serveru

A

Windows 2003

B

Windows 2000

Certifikační autorita

C

NetWare 6.5 SP5

Úloţiště SW balíčků distribuované skrze Novell Zenworks

D

Windows 2003

Cluster Lotus Notes, IMAP přístup

E

Windows 2003

Lotus Notes – veřejný přístup přes webové rozhraní

F

Windows 2003

Ekonomická agenda

G

Windows 2003

Úloţiště pro image stanice

H

NetWare 6.5 SP5

Novell e-directory

I

Solaris 9

Databázový server pro agendy PES, Výsledky

J

NetWare 6.5 SP5

Kopie serveru HAS pro Jiţní město

K

Solaris 9

Testovací DB server pro agendu PES, migrační DB pro ISIS

L

Windows 2003

Lotus Notes, poštovní server pro část zaměstnanců (1800 účtů)

M

NetWare 6.5 SP5

Home adresáře pro zaměstnance (Novell e-directory)

N

Windows 2003

Systém centrální správy karet

O

Windows 2003

Ekonomická agenda

P

NetWare 6.5 SP5

Novell e-directory

Q

NetWare 6.5 SP5

Webové stránky a frontend pro přístup přes netstorage.vse.cz (Novell e-directory)

R

NetWare 6.5 SP5

Home adresáře pro studenty (Novell e-directory)

S

NetWare 6.5 SP5

Podpora tisku (Novell e-directory)

T

Windows 2000

Aplikační a databázový server pro agendu vstupů

U

Windows 2003

Server s lokální replikou Windows update a McAffee update

V

Windows 2003

Ekonomická agenda

W

Aplikační servery pro studijní agendu (ISIS)

X

Databázové servery pro studijní agendu (ISIS) Tab. 16 - Seznam serverů na VŠE (Zdroj: [Trcka2009])

-109/117-



PŘÍLOHA C – STRUKTURA ROZHOVORU SE ZÁSTUPCI VÝPOČETNÍHO CENTRA VŠE Pro rozhovor se zástupci Výpočetního centra VŠE byla sestavena struktura rozhovoru, kterou lze uvést následujícím způsobem: I.

Oblast Business Continuity Management 1. Existuje na VŠE dokument informační strategie? 2. Existuje plán Business Continuity definovaný pro VŠE? 3. Existuje plán zotavení z krize (Disaster Recovery)? 4. Bylo by moţné vyuţívat záloţního prostředí pro ukládání dat ve spolupráci s jinou českou univerzitou? 5. Jakým způsobem probíhá v současné době archivace dat? II. Oblast bezpečnosti 6. Je na VŠE prováděn bezpečnostní monitoring komponent (servery, síťové prvky)? III. Oblast Cloud Computingu 7. Existují na VŠE takové servery, jejichţ kapacita není plně vyuţita? 8. Běţí na těchto serverech takové sluţby, které by bylo moţné přesunout do cloudu (tj. sluţby, které nejsou zcela charakteristické pro VŠE)? 9. Bylo by moţné tyto servery virtualizovat a poskytovat cloudové sluţby jiným oddělením v rámci VŠE? 10. Existují pro vytvoření privátního cloudu kapacity lidských zdrojů? 11. Byla by VŠE ochotna vyuţívat pro vybudování privátního cloudu open sourceových řešení? 12. Bylo by moţné pomocí konceptu Cloud Computing nabízet sluţby také externím subjektům? 13. Měla by VŠE zájem o to platit za sluţby modelem platby pay-as-you-go? IV. Obecné otázky 14. Jaké jsou stanoveny strategické cíle pro VŠE v oblasti IT na rok 2011?

-110/117-



PŘÍLOHA D – PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ Název OS

GoGrid

Amazon EC2

Rackspace Cloud

Řešení

ReliaCloud ElasticHosts

Windows Server 2003

ano

ano

ano

ano

ne

Windows Server 2008

ano

ano

ano

ano

ano

Ubuntu

ne

ano

ano

ano

ano

Debian

ne

ano

ano

ano

ano

Gentoo

ne

ano

ano

ne

ne

CentOS

ano

ne

ano

ano

ne

Fedora

ne

ano

ano

ne

ano

RHEL

ano

ano

ano

ne

ne

SLES

ne

ano

ne

ne

ne

Tab. 17 - Podporované operační systémy IaaS řešení (Zdroj: Autor)

-111/117-



PŘÍLOHA E – UKÁZKA WEBOVÉHO ROZHRANÍ DOSTUPNÉHO IAAS ŘEŠENÍ V rámci této diplomové práce byla testována funkcionalita nabízeného IaaS řešení od společnosti ElasticHosts. Tato společnost nabízí řešení v rámci pětidenního trialu, ve kterém byla funkcionalita testována. V rámci těchto testů byly prováděny pouze základní uţivatelské testy, zátěţové testy nebyly součástí tohoto testování. 1. Přihlášení do webového rozhraní Po zaregistrování se na stránkách společnosti ElasticHosts je moţné se přihlásit do webového rozhraní ElasticHosts. Webové rozhraní je zobrazeno na následujícím obrázku.

Obr. 19 - Webové rozhraní (Zdroj: Autor)

-112/117-



2. Vytvoření vlastní instance serveru Řešení nabízí několik moţností, jakým způsobem vytvořit instanci serveru. Je moţné vybrat z nabídky předinstalovaných systémů, live CD Linux verzí nebo instalací systému z disku. Co do nabídky operačních systémů je moţné vybrat z několika distribucí Linuxu nebo Windows Server. Podrobnosti o podporovaných platformách ElasticHosts jsou uvedeny v příloze Příloha D – Podporované operační systémy IaaS řešení. Po zvolení názvu vytvářené instance, způsobu instalace operačního systému, typu operačního systému a velikosti disku je moţné vytvořit vlastní instanci. Na následujícím obrázku je zobrazena vytvořená instance včetně disku, který jí byl přiřazen.

Obr. 20 - Vytvoření instance (Zdroj: Autor)

-113/117-



3. Nastavení parametrů instance serveru U zvolené instance lze dynamicky nastavit parametry CPU, přiřazené paměti, disků apod.

Obr. 21 - Nastavení parametrů instance (Zdroj: Autor)

4. Spuštění instance

Obr. 22 - Spuštění instance (Zdroj: Autor)

-114/117-



Instanci spustíme v Control Panel stisknutím tlačítka "Start". Společně s instancí je startován také disk, který jí byl přiřazen v procesu vytváření nebo při změně konfigurace serveru. Po startu je instanci přidělena IP adresa, na které je spuštěna. K této IP adrese je moţné přistupovat pomocí specializovaných nástrojů, kterým je například TightVNC.

Obr. 23 - TightVNC přihlášení (Zdroj: Autor)

Pomocí tohoto nástroje je moţné získat přímý přístup ke spuštěné instanci na úrovni administrátora. Po úspěšné instalaci a spuštění instance dosáhneme například zobrazení uvedeného na následujícím obrázku. Na obrázku je rovněţ naznačeno, ţe uţivatel má přístupová oprávnění na úrovni administrátora systému.

Obr. 24 - Rozhraní instance (Zdroj: Autor)

-115/117-



5. Zjištění a správa účtování Součástí webového rozhraní jsou také informace o způsobu účtování odebíraných sluţeb. Tyto sluţby je moţné dynamicky aktualizovat v návaznosti na skutečně odebírané mnoţství.

Obr. 25 - Účtování sluţeb (Zdroj: Autor)

-116/117-



PŘÍLOHA F – ŠABLONA PLÁNU BUSINESS CONTINUITY BCM plán – – postup pro <prvních 24 – 48 hodin> Popis stavu 

<popis, jakým způsobem se výskyt rizika projevuje>

Pravděpodobnost



Dopad



Pravděpodobná příčina



Dotčené procesy



Odpovědnost



Činnosti

Okamţitě

Během <24 – 48 hodin>



<definujte činnosti, které by měly být provedeny okamţitě po vzniku rizika, tj. během první hodiny>



Sníţení dopadu



Omezení



<jmenujte omezení znesnadňující rychlou nápravu>

Zdroje



<definujte návazné činnosti vedoucí k plnému obnovení chodu dotčených procesů>

Tab. 18 - Šablona plánu Business Continuity (Zdroj: Autor)

-117/117-

Vysoká škola ekonomická v Praze

Recommend Documents