vysoká škola ekonomická v praze - · pdf filecloud computing jako...

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

Cloud Computing jako nástroj BCM Pavlína Lukášová

-ii/x-

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


-iii/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.


-iv/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


-v/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-a-

Service, IaaS, hybrid cloud


-vi/x-

OBSAH

ÚVOD 1

VYMEZENÍ TÉMATU PRÁCE 1

CÍLE PRÁCE 2

PŘÍNOSY PRÁCE 2

PŘEDPOKLADY A OMEZENÍ PRÁCE 2

1 CHARAKTERISTIKA BUSINESS CONTINUITY MANAGEMENT 3

1.1 VÝZNAM BUSINESS CONTINUITY MANAGEMENT PRO CHOD ORGANIZACE 3

1.2 ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY 5

1.3 ROZHODNUTÍ O SESTAVENÍ PLÁNU BUSINESS CONTINUITY 6

1.4 KRIZOVÉ ŘÍZENÍ 7

1.5 SERVICE LEVEL MANAGEMENT 8

1.5.1 DOBA OBNOVY A BOD OBNOVY 8

1.6 ALTERNATIVNÍ PROSTŘEDÍ 10

1.7 ÚPRAVA BCM VE STANDARDECH 10

1.7.1 MEZINÁRODNÍ ORGANIZACE PRO STANDARDIZACI ISO 11

2 CHARAKTERISTIKA CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE 12

2.1 POTENCIÁL CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE 15

2.2 BENEFITY PLYNOUCÍ Z ADOPCE CLOUD COMPUTINGU 15

2.3 HROZBY CLOUD COMPUTINGU Z HLEDISKA BEZPEČNOSTI 16

2.3.1 ZNEUŽITÍ A NEZÁKONNÉ POUŽITÍ CLOUD COMPUTINGU 17

2.3.2 OTÁZKY ZABEZPEČENÍ ROZHRANÍ 18

2.3.3 SDÍLENÍ INFRASTRUKTURY 18

2.3.4 ZTRÁTA NEBO ÚNIK DAT 19

2.3.5 OCHRANA UŽIVATELSKÝCH ÚČTŮ 19

2.4 ZRANITELNOSTI CLOUD COMPUTINGU 20

2.5 IDENTITY & ACCESS MANAGEMENT VE VAZBĚ NA CLOUD COMPUTING 21

2.6 NÁVRH BEZPEČNOSTNÍCH OPATŘENÍ PRO ADOPCI CLOUD COMPUTINGU 22

3 VAZBA CLOUD COMPUTINGU NA BUSINESS CONTINUITY MANAGEMENT 24

3.1 CO CLOUD COMPUTING SPOLEČNOSTEM PŘINÁŠÍ PRO JEJICH BUSINESS CONTINUITY 24

3.1.1 CLOUD COMPUTING JAKO VÝCHODISKO Z KRIZE 24

3.1.2 JAK MŮŽE CLOUD COMPUTING POMOCI ZAJISTIT BUSINESS CONTINUITY 25

3.1.3 PRAVIDLA ADOPCE CLOUD COMPUTINGU JAKO NÁSTROJE BUSINESS CONTINUITY 26

3.2 PŘEPOKLAD PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM 27

3.2.1 ŘÍZENÍ RIZIK 27

3.3 POŽADAVKY BCM NA CLOUD COMPUTING 27

3.4 KATEGORIE A - BEZPEČNOST 28

3.4.1 P01 BEZPEČNOST A MONITORING 28

3.4.2 DŮVĚRNOST INFORMACÍ 29

3.5 KATEGORIE B - DISASTER RECOVERY 29

3.5.1 P02 ZÁLOHOVÁNÍ A ARCHIVACE 30

3.6 KATEGORIE C - SERVICE LEVEL AGREEMENT 31

3.6.1 P03 DOSTUPNOST SLUŽEB 32


-vii/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

SOUKROMÉHO 35

4.2 VYUŽITÍ BCM V SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ 36

4.2.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI 36

4.2.2 FÁZE 2 – URČENÍ STRATEGIE BCM 37

4.2.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU 38

4.2.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU 39

4.3 POTENCIÁL CLOUD COMPUTINGU PRO SEKTOR TERCIÁRNÍHO VZDĚLÁVÁNÍ 40

4.3.1 KTERÉ SLUŽBY PŘESUNOUT DO CLOUDU A KDY 42

4.3.2 FENOMÉN „CONSUMERIZACE“ A SDÍLENÍ OBSAHU 43

4.3.3 VYUŽITÍ CLOUD COMPUTINGU PRO KOMUNIKACI 44

4.4 NAPLNĚNÍ PODMÍNEK BCM NA CLOUD COMPUTING ŘEŠENÍ 44

4.4.1 PŘEDPOKLAD – ŘÍZENÍ RIZIK 44

4.4.2 POŽADAVEK P01 BEZPEČNOST A MONITORING 45

4.4.3 POŽADAVEK P02 ZÁLOHOVÁNÍ A ARCHIVACE 47

4.4.4 POŽADAVEK P03 DOSTUPNOST SLUŽEB 47

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 49

5.1.1 SWOT ANALÝZA 49

5.1.2 PROCESNÍ MAPA VŠE 50

5.1.3 VÝPOČETNÍ CENTRUM 51

5.1.4 TECHNOLOGICKÁ INFRASTRUKTURA 52

5.1.5 STUDIJNÍ INFORMAČNÍ SYSTÉM 52

5.2 VÝBĚR VHODNÉ VARIANTY CLOUDOVÉHO ŘEŠENÍ 53

5.3 INFRASTRUKTURA JAKO SLUŽBA 53

5.4 VIRTUALIZACE 56

5.5 SOUKROMÝ CLOUD 56

5.6 HYBRIDNÍ CLOUD 58

5.7 VYUŽITÍ CLOUD COMPUTINGU PRO VÝUKU 59

5.8 CLOUD COMPUTING A OPEN SOURCE 60

5.9 POHLED ODDĚLENÍ VÝPOČETNÍHO CENTRA VŠE 61

5.9.1 P01 BEZPEČNOST A MONITORING 61

5.9.2 P02 ZÁLOHOVÁNÍ A ARCHIVACE 61

5.9.3 P03 DOSTUPNOST SLUŽEB 62

5.9.4 VIRTUALIZACE NA VŠE 62

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


-viii/x-

6.1 VÝBĚR POSKYTOVATELŮ IAAS 64

6.2 VÝBĚR KRITÉRIÍ PRO ANALÝZU 65

6.3 POPIS VYBRANÝCH KRITÉRIÍ 66

6.3.1 TECHNICKÉ ASPEKTY 66

6.3.2 ASPEKTY BCM 67

6.3.3 FINANČNÍ ASPEKTY 68

6.4 GOGRID CLOUD HOSTING 69

6.4.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ 69

6.4.2 HODNOCENÍ ASPEKTŮ BCM 69

6.4.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ 70

6.4.4 CELKOVÉ HODNOCENÍ GOGRID CLOUD HOSTING 70

6.5 AMAZON EC2 71




6.5.4 CELKOVÉ HODNOCENÍ AMAZON EC2 71

6.6 RACKSPACE CLOUD SERVERS 72




6.6.4 CELKOVÉ HODNOCENÍ RACKSPACE CLOUD SERVERS 73

6.7 RELIACLOUD 74




6.7.4 CELKOVÉ HODNOCENÍ RELIACLOUD 74

6.8 ELASTICHOSTS 75




6.8.4 CELKOVÉ HODNOCENÍ ELASTICHOSTS 76

6.9 VZÁJEMNÉ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ 77

6.9.1 ZHODNOCENÍ OBLASTI TECHNICKÝCH ASPEKTŮ 77

6.9.2 ZHODNOCENÍ OBLASTI BUSINESS CONTINUITY 78

6.9.3 ZHODNOCENÍ OBLASTI FINANČNÍCH ASPEKTŮ 78

6.9.4 MULTIKRITERIÁLNÍ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ 79

6.10 ZÁVĚREČNÉ ZHODNOCENÍ 79

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

7.1 OBLAST BUSINESS CONTINUITY MANAGEMENT 80

7.1.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI 80

7.1.2 FÁZE 2 – URČENÍ STRATEGIE BCM 82

7.1.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU 83

7.1.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU 84

7.2 OBLAST CLOUD COMPUTINGU 84

7.2.1 NAPLNĚNÍ PŘEDPOKLADU ŘÍZENÍ RIZIK 85

7.2.2 NAPLNĚNÍ POŽADAVKŮ BCM NA ŘEŠENÍ CLOUD COMPUTINGU 87


-ix/x-

7.2.3 BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ 88

7.2.4 FINANČNÍ ZHODNOCENÍ 89

7.3 SHRNUTÍ 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) 4

OBR. 2 - ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY MANAGEMENT (ZDROJ: [BCI2010A]) 6

OBR. 3 - GRAFICKÉ ZNÁZORNĚNÍ RPO A RTO (ZDROJ: AUTOR) 10

OBR. 4 - TYPY CLOUD COMPUTINGU (ZDROJ: AUTOR) 13

OBR. 5 - PŘEHLED KONCEPTU CLOUD COMPUTING (ZDROJ: AUTOR) 14

OBR. 6 - POŘADÍ OBAV Z ADOPCE CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [VELTE2010]) 18

OBR. 7 - SROVNÁNÍ VÝPADKŮ EMAILOVÝCH SLUŽEB V MIN./MĚSÍC (ZDROJ: [GLOTZBACH2008]) 33

OBR. 8 - PROCESNÍ MODEL VŠE (ZDROJ: AUTOR, VYTVOŘENO NA ZÁKLADĚ [TRCKA2009]) 51

OBR. 9 - ARCHITEKTURA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [LENK2009]) 55

OBR. 10 - ZOBRAZENÍ HYBRIDNÍHO CLOUDU (ZDROJ: AUTOR) 59

OBR. 11 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR) 70

OBR. 12 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR) 72

OBR. 13 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR) 73

OBR. 14 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR) 75

OBR. 15 - GRAFICKÉ ZNÁZORNĚNÍ ŘEŠENÍ ELASTICHOSTS (ZDROJ: AUTOR) 76

OBR. 16 - GRAFICKÉ ZNÁZORNĚNÍ POROVNÁNÍ IAAS ŘEŠENÍ VE 3 ROZMĚRECH (ZDROJ: AUTOR) 79

OBR. 17 - GRAFICKÉ ZNÁZORNĚNÍ VZTAHU MEZI NÁKLADY NA OBNOVU A ZTRÁTOU ORGANIZACE (ZDROJ:

AUTOR) 81

OBR. 18 - BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ (ZDROJ: AUTOR) 89

OBR. 19 - WEBOVÉ ROZHRANÍ (ZDROJ: AUTOR) 112

OBR. 20 - VYTVOŘENÍ INSTANCE (ZDROJ: AUTOR) 113

OBR. 21 - NASTAVENÍ PARAMETRŮ INSTANCE (ZDROJ: AUTOR) 114

OBR. 22 - SPUŠTĚNÍ INSTANCE (ZDROJ: AUTOR) 114

OBR. 23 - TIGHTVNC PŘIHLÁŠENÍ (ZDROJ: AUTOR) 115

OBR. 24 - ROZHRANÍ INSTANCE (ZDROJ: AUTOR) 115

OBR. 25 - ÚČTOVÁNÍ SLUŽEB (ZDROJ: AUTOR) 116


-x/x-

SEZNAM TABULEK TAB. 1 - KATEGORIZACE POŽADAVKŮ BCM NA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: AUTOR) 28

TAB. 2 - PŘEHLED SROVNÁVANÝCH KRITÉRIÍ (ZDROJ: AUTOR) 65

TAB. 3 - HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR) 70

TAB. 4 - HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR) 71

TAB. 5 - HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR) 73

TAB. 6 - HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR) 74

TAB. 7 - HODNOCENÍ ELASTICHOSTS (ZDROJ: AUTOR) 76

TAB. 8 - POŘADÍ IAAS ŘEŠENÍ DLE HODNOCENÝCH KRITÉRIÍ (ZDROJ: AUTOR) 77

TAB. 9 - POŘADÍ IAAS ŘEŠENÍ DLE TECHNICKÝCH PARAMETRŮ (ZDROJ: AUTOR) 77

TAB. 10 - POŘADÍ IAAS ŘEŠENÍ DLE PARAMETRŮ BCM (ZDROJ: AUTOR) 78

TAB. 11 - POŘADÍ IAAS ŘEŠENÍ DLE FINANČNÍCH KRITÉRIÍ (ZDROJ: AUTOR) 78

TAB. 12 - SOUHRNNÁ TABULKA ANALÝZY DOPADU (ZDROJ: AUTOR) 81

TAB. 13 - PŘÍKLAD PLÁNU BCM PRO RIZIKO ZTRÁTY DAT (ZDROJ: AUTOR) 83

TAB. 14 - FINANČNÍ ZHODNOCENÍ NAVRŽENÉHO ŘEŠENÍ (ZDROJ: AUTOR) 89

TAB. 15 - SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ (ZDROJ: [VSE2010]) 108

TAB. 16 - SEZNAM SERVERŮ NA VŠE (ZDROJ: [TRCKA2009]) 109

TAB. 17 - PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ (ZDROJ: AUTOR) 111

TAB. 18 - ŠABLONA PLÁNU BUSINESS CONTINUITY (ZDROJ: AUTOR) 117


-1/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.


-2/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í.


-3/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


-4/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)


-5/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.


-6/117-

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

Řízení programu a

politiky BCM

Porozumění

organizaci

Určení

strategie

BCM

Tvorba

a implementace

BCM plánu

Školení,

údržba

a revize

Začlenění BCM do kultury organizace


-7/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.


-8/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


-9/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:

o 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í.

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.


-10/117-

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í

Narušující událost

Recovery Point

Objective

Recovery Time

Objective

Časový úsek od

poslední zálohy

Časový úsek do

obnovení systému


-11/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ů.


-12/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


-13/117-

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

cloudem.

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-a-

Service [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.

Interní

cloudExterní

služba

Hybridní

cloud

Externí

Cloud


-14/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)


-15/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].


-16/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,


-17/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]


-18/117-

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.

0 10 20 30 40 50 60 70 80

Nedostatek poskytovatelů

Regulace

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

Cena

Možnost customizace

Integrace s in-house řešením

Dostupnost

Výkonnost

Bezpečnost


-19/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


-20/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.


-21/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


-22/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


-23/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.


-24/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ř.:


-25/117-

o 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.

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í.


-26/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.


-27/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.


-28/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.


-29/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.


-30/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,


-31/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.


-32/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


-33/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).

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.

0

50

100

150

Gmail GroupWise Lotus Exchange

Do

ba

vý

pa

dk

u s

lužb

y (

v m

inu

tách

)

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

Plánovaná odstávka

Neplánovaná odstávka


-34/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ů.


-35/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.


-36/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


-37/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.


-38/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á.


-39/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.


-40/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.


-41/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í.


-42/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ě.


-43/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ý


-44/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.


-45/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,


-46/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.


-47/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 TERCIÁRNÍHO VZDĚLÁVÁNÍ PRO VYUŽITÍ CLOUD

COMPUTINGU JAKO NÁSTROJE BCM 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


-48/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-a-

Service 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ý.


-49/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.


-50/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).


-51/117-

o 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čí.

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

Podpůrné procesy:

o Koordinace a řízení rozvojových programů

o Řízení ekonomiky

o Zajištění administrativy

o Řízení lidských zdrojů

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

o Zajištění administrativy

o 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,

Hlavní procesy

Podpůrné procesy

Strategický rozvoj VŠE

Zajištění studia

Zajištění

mezinárodních

aktivit a vztahů

Rozvoj vědy a

výzkumu

Řízení

lidských zdrojů

Koordinace a řízení

rozvojových programů

Podpora

a rozvoj

hospodářské

činnosti

Řízení a provoz

informačního systému

Zajištění účetnictví a

provozu školy

Zajištění

administrativyŘízení ekonomiky


-52/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


-53/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.


-54/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


-55/117-

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í.

Hardware

Infrastrukturní služby

Zdroje

Fyzické zdroje

Virtuální zdroje

Základní infrastrukturní služby

Nadstavbové infrastrukturní služby

IaaS

Prostředí pro programování

Prostředí pro realizaci

PaaS

Aplikace

Aplikační služby

Základní aplikační služby

Složené aplikační služby

SaaS

Sp

ráva

Po

dp

ora

bu

sin

essu

Vývo

j, ko

nfig

ura

ce

, mo

nito

ring

, říze

ní ž

ivo

tníh

o c

yklu

Účto

vá

ní, a

ute

ntiz

ace

, sp

ráva

uživ

ate

l

Emulab

Amazon EC2

GoogleFS

Google Bigtable

Google App

Engine

Django

Google Docs

Opensocial

OpenID


-56/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 Anything-

as-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é


-57/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


-58/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.


-59/117-

Zjednodušená struktura takového hybridního cloudu je schematicky znázorněna na následujícím

obrázku.

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é

Vrstva služeb

Vrstva infrastruktury

Fyzická infrastruktura

Virtuální infrastruktura

IaaS software pro hybridní cloud

Uživatelé

Univerzita

Poskytovatel

cloudových

služeb


-60/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 open-

sourceový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,


-61/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.


-62/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.


-63/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í.


-64/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


-65/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

1. Technické aspekty

1.1 Typy poskytovaných řešení 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

2. Aspekty BCM

2.1 Bezpečnost BCM001 Bezpečnost a monitoring 0,09

BCM002 Zálohování 0,09

2.2 Smluvní ujednání BCM003 Garance SLA 0,09

3. Finanční aspekty

3.1 Financování FIN001 Model financování 0,08

FIN002 Způsob stanovení ceny 0,07

3.2 Sluţby FIN003 Technická podpora 0,07

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í.


-66/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ášť.



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.



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é.



0 – API není poskytováno

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


-67/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.



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.



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í.



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.


-68/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.



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.



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.



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-as-

you-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.



-69/117-


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í.



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.



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.

http://www.gogrid.com/cloud-hosting/


-70/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 Hodnota Váţená hodnota

TECH001 0,07 1 0,07

TECH002 0,07 1 0,07

TECH003 0,07 1 0,07

TECH004 0,07 1 0,07

TECH005 0,09 0,67 0,0603

TECH006 0,07 1 0,07

TECH007 0,07 0,67 0,0469

BCM001 0,09 1 0,09

BCM002 0,09 1 0,09

BCM003 0,09 1 0,09

FIN001 0,08 1 0,08

FIN002 0,07 1 0,07

FIN003 0,07 1 0,07

Celková váţená hodnota 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:

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

0

0,2

0,4

0,6

0,8

1TECH001

TECH002

TECH003

TECH004

TECH005

TECH006

TECH007BCM001

BCM002

BCM003

FIN001

FIN002

FIN003

GoGrid


-71/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/


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.


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.


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


TECH001 0,07 1 0,07

TECH002 0,07 1 0,07

TECH003 0,07 1 0,07

TECH004 0,07 0,5 0,035

TECH005 0,09 1 0,09

TECH006 0,07 0,67 0,0469

TECH007 0,07 1 0,07

BCM001 0,09 1 0,09

BCM002 0,09 0 0

BCM003 0,09 0,9995 0,089955

FIN001 0,08 1 0,08

FIN002 0,07 1 0,07

FIN003 0,07 0,5 0,035


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

http://aws.amazon.com/ec2/


-72/117-

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:

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


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.


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.

0

0,2

0,4

0,6

0,8

1TECH001

TECH002

TECH003

TECH004

TECH005

TECH006

TECH007BCM001

BCM002

BCM003

FIN001

FIN002

FIN003

Amazon EC2

http://www.rackspacecloud.com/cloud_hosting_products/servers


-73/117-


Ř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:


TECH001 0,07 1 0,07

TECH002 0,07 1 0,07

TECH003 0,07 1 0,07

TECH004 0,07 1 0,07

TECH005 0,09 0,67 0,0603

TECH006 0,07 1 0,07

TECH007 0,07 0,67 0,0469

BCM001 0,09 0,5 0,045

BCM002 0,09 1 0,09

BCM003 0,09 1 0,09

FIN001 0,08 0,5 0,04

FIN002 0,07 0,5 0,035

FIN003 0,07 1 0,07


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í.


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

0

0,2

0,4

0,6

0,8

1TECH001

TECH002

TECH003

TECH004

TECH005

TECH006

TECH007BCM001

BCM002

BCM003

FIN001

FIN002

FIN003

Rackspace Cloud


-74/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/


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.


ReliaCloud garantuje 100% dodrţení stanovených SLA.


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:


TECH001 0,07 1 0,07

TECH002 0,07 1 0,07

TECH003 0,07 1 0,07

TECH004 0,07 0,5 0,035

TECH005 0,09 0,34 0,0306

TECH006 0,07 1 0,07

TECH007 0,07 0,34 0,0238

BCM001 0,09 0,5 0,045

BCM002 0,09 1 0,09

BCM003 0,09 1 0,09

FIN001 0,08 0,5 0,04

FIN002 0,07 0,5 0,035

FIN003 0,07 1 0,07


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

http://www.reliacloud.com/howitworks/


-75/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:

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/


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.


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%.


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í.

0

0,2

0,4

0,6

0,8

1TECH001

TECH002

TECH003

TECH004

TECH005

TECH006

TECH007BCM001

BCM002

BCM003

FIN001

FIN002

FIN003

ReliaCloud

http://www.elastichosts.com/


-76/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:


TECH001 0,07 1 0,07

TECH002 0,07 1 0,07

TECH003 0,07 1 0,07

TECH004 0,07 0,5 0,035

TECH005 0,09 0,34 0,0306

TECH006 0,07 0,34 0,0238

TECH007 0,07 0,34 0,0238

BCM001 0,09 0,5 0,045

BCM002 0,09 1 0,09

BCM003 0,09 1 0,09

FIN001 0,08 1 0,08

FIN002 0,07 1 0,07

FIN003 0,07 0,5 0,035


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í.


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

0

0,2

0,4

0,6

0,8

1TECH001

TECH002

TECH003

TECH004

TECH005

TECH006

TECH007BCM001

BCM002

BCM003

FIN001

FIN002

FIN003

ElasticHosts


-77/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í:


1. – 2. GoGrid Cloud Hosting 65,31%

1. – 2. Rackspace Cloud Servers 65,31%


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.


-78/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í:


1. GoGrid Cloud Hosting 90%

2. – 4. Rackspace Cloud Servers 75%

2. – 4. ReliaCloud 75%

2. – 4. ElasticHosts 75%


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í:


1. GoGrid Cloud Hosting 73,34%

2. – 3. Amazon EC2 61,67%

2. – 3. ElasticHosts 61,67%

4. – 5. Rackspace Cloud Servers 48,34%

4. – 5. ReliaCloud 48,34%

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


-79/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.

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.

50%

55%

60%

65%

70%

75%

80%

85%

90%

95%

100%

40% 45% 50% 55% 60% 65% 70%

Asp

ek

ty B

CM

Technické aspekty

Porovnání řešení IaaS

GoGrid

Amazon EC2

Rackspace

ElasticHosts ReliaCloud


-80/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.


-81/117-

Název procesu MTD (Maximum Tolerable

Downtime)

RPO

(Recovery

Point

Objective

Ohodnocení

dopadu

RTO (Recovery

Time

Objective)

WRT (Work

Recovery Time)

PR01 Zajištění studia < 2 dny < 2 dny < 4

hodiny

Přerušení dodávky

sluţeb

PR02 Rozvoj vědy a

výzkumu

< 1,5 dne < 2 dny < 1 den Poškození pověsti

PR03 Podpora a rozvoj

hospodářské činnosti

< 1 den < 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.

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.

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

Ná

kla

dy

Čas

Náklady na obnovu

Ztráty organizace


-82/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


-83/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ě

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

Během 24 - 48 hodin

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)


-84/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í


-85/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.


-86/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ě.


-87/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.


-88/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.


-89/117-

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 /

měsíc]

Cena [CZK /

rok]

Eucalyptus - - - -

GoGrid < 6 16 GB 71 8621 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

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

Za

mě

stn

an

ci

Pro

ce

sy

Stu

de

nti

Ho

dn

oto

vé

uka

za

tele

Mapa strategie Cíle Metriky Realizace

Snížení nákladů

Získání konkurenční

výhody

Zvýšení

dostupnosti služeb

Zvýšení flexibility

poskytovaných zdrojů

katedrám

Udržení dobrého

jména VŠE

Optimalizace

využívání zdrojů

Virtualizace

existujících

serverů

Vytvoření

hybridního

cloudu

Vytvoření

privátního

cloudu

Zvýšení

flexibility

poskytovaných

zdrojů

Optimalizace

využívání

zdrojů

Zvýšení

dostupnosti

služeb

Snížení

nákladů

Udržení

dobrého

jména VŠE

Získání

konkurenční

výhody

% získaných nových

studentů ve srovnání

s jinými vysokými

školami

Hodnota

snížení nákladů

Zvýšení

spokojenosti

zaměstnanců

Zvýšení

spokojenosti

studentů

Snížení počtu

serverů/zvýšení

využívání kapacity

Otevření prostoru

pro poskytování

služeb externě


-90/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


-91/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.


-92/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


-93/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.


-94/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-942-

8/10/06.

[Assuncao2009] ASSUNCAO, Marcos Dias de. – COSTANZO, Alexandre di. Evaluating the Cost-

Benefit 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: <http://www.vega-

group.com/assets/documents/100005ADWhitePaper_BusinessContinuityManagement.

pdf>.

[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:

<http://www.coe.int/t/dghl/cooperation/economiccrime/cybercrime/cy-activity-

interface-

2010/presentations/Outlook/Udo%20Helmbrecht_ENISA_Cloud%20Computing_Outl

ook.pdf>.

[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:

<http://www.cloudsecurityalliance.org/guidance/csaguide-dom12-v2.10.pdf>.

[CSA2010b] Cloud Security Alliance. Top Threats to Cloud Computing V1.0. The Cloud Security

Alliance. c2010. Dostupný z WWW:

<http://www.cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf>.

[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:

<http://www.nedrix.com/PDF/Business%20Continuity%20For%20Dummies.pdf>.


-95/117-

[Educause2010] Shaping the Higher Education Cloud. EDUCAUSE a NACUBO Whitepaper. c2010.

Dostupný z WWW: <http://www.educause.edu/ir/library/pdf/PUB9009.pdf>.

[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:

<http://www.thebci.org/LRSGVersion4.pdf>.

[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-470-

48470-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:

<http://www.educause.edu/ir/library/pdf/ecar_so/erb/ERB0919.pdf>.


-96/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:

<https://akela.mendelu.cz/~lidak/bif/bis.pdf>.

[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-470-

63540-7.


-97/117-

[Stratus2010] Stratus Technologies. Server Virtualization and Cloud Computing: Four Hidden

Impacts on Uptime and Availability. Stratus Technologies WhitePaper. c2010.

Dostupný z WWW:

<http://www.stratus.com/~/media/Stratus/Files/Resources/WhitePapers/ServerVirtuali

zationandCloudComputing.pdf>.

[Sun2007] Service Level Management. Sun Microsystems Whitepaper. Sun Microsystems, Inc. c2007.

[cit. 2010-10-03]. Dostupný z WWW:

<http://www.sun.com/emrkt/sunspectrum/servicelevelwhitepaper.pdf>.

[Svoboda2009] SVOBODA, Jiří. Cloud Computing in Systémová integrace 2/2009. T-Mobile Czech

Republic. c2009. Dostupný z WWW:

<http://www.cssi.cz/cssi/system/files/all/0svoboda.pdf>.

[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-162695-

8.

[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:

<http://aws.amazon.com/ec2>.

[BCI2010b] The Business Continuity Institute. Webová prezentace. c2010. [cit. 2010-07-10].

Dostupný z WWW: <http://www.thebci.org/>.

[Brodkin2008] BRODKIN, Jon. Gartner: Seven cloud-computing security risks in InfoWorld: Security

Central. c2008. [cit. 2010-10-09]. Dostupný z WWW:

<http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-

security-risks-853>.

[Bittman2008] BITTMAN, Tom. Cloud Computing and K-12 Education. c2008. [cit. 2010-10-11].

Gartner blogs. Dostupný z WWW:

<http://blogs.gartner.com/thomas_bittman/2008/11/26/cloud-computing-and-k-12-

education/>.

[BusDict2010] Business Dictionary. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.businessdictionary.com>.

[CC2010] Cloud Computing Defined. Webová prezentace. c2010. [cit. 2010-08-17]. Dostupný

z WWW: <http://www.cloudcomputingdefined.com/>.


-98/117-

[CESNET2010] CESNET. O nás. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.cesnet.cz/sdruzeni/>.

[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:

<http://businessworld.cz/case-studies/virtualizace-v-oblasti-skoleni-a-vzdelavani-

6927>.

[Clarke2009] CLARKE, Mark. Cloud computing as a business continuity plan in Tectonic. c2009. [cit.

2010-10-19]. Dostupný z WWW: <http://www.tectonic.co.za/2009/05/cloud-

computing-as-a-business-continuity-plan/>.

[Com2010] Cloud – Computer Dictionary Definition. Computer Desktop Encyclopedia. c2010. [cit.

2010-11-24]. Dostupný z WWW: <http://computer.yourdictionary.com/cloud>.

[CSA2009] Sampling of issues we are addressing. Cloud Security Alliance. c2009. [cit. 2010-10-09].

Dostupný z WWW: <http://www.cloudsecurityalliance.org/issues.html#ediscovery>.

[Cooney2009] COONEY, Michael. IBM touts encryption innovation in Computerworld. c2009. [cit.

2010-10-01]. Dostupný z WWW:

<http://www.computerworld.com/s/article/9134823/IBM_touts_encryption_innovatio

n?taxonomyId=152&intsrc=kc_top&taxonomyName=compliance>.

[Dougherty2001] DOUGHERTY, Dale. LAMP: The Open Source Web Platform. Leden, 2001. c2001.


<http://onlamp.com/pub/a/onlamp/2001/01/25/lamp.html>.

[ElasticHosts2010] ElasticHosts. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW:

<http://www.elastichosts.com>.

[EnStratus2010] enStratus. Webová prezentace. c2010. [cit. 2010-10-30]. Dostupný z WWW:

<http://www.enstratus.com>.

[Fogarty2010] FOGARTY, Kevin. Which Apps Should You Move to the Cloud? 5 Guidelines in CIO

Online. c2010. [cit. 2010-09-05]. Dostupný z WWW:

<http://www.cio.com/article/603702/Which_Apps_Should_You_Move_to_the_Cloud

_5_Guidelines>.

[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: <http://berkeleyclouds.blogspot.com/2009/04/cloud-computing-

law-enforcement-and.html>.

[Glotzbach2008] GLOTZBACH, Matthew. What we learned from 1 million businesses in the cloud.

Google blog. c2008. [cit. 2010-10-24]. Dostupný z WWW:

<http://googleblog.blogspot.com/2008/10/what-we-learned-from-1-million.html>.

[GoGrid2010] GoGrid. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW:

<http://www.gogrid.com>.

[Houser2010] HOUSER, Pavel. Cloud, bezpečnost a ERP systémy: podle čeho volit? in

SecurityWorld. c2010. [cit. 2010-09-17]. Dostupný z WWW:

<http://securityworld.cz/securityworld/cloud-bezpecnost-a-erp-systemy-podle-ceho-

volit-3129>.


-99/117-

[ICM2004] ICM Computer Group. Business Continuity for Beginners in Continuity Central. Prosinec,

2004. c2004. [cit. 2010-11-18]. Dostupný z WWW:

<http://www.continuitycentral.com/feature0158.htm>.

[ICM2005] Crisis Management. American Institute for Crisis Management (ICM). c2005. [cit. 2010-

11-24]. Dostupný z WWW: <http://www.siliconfareast.com/crisis-management.htm>.

[Info2010] European Union defines cloud computing. Information Age. Únor, 2010. c2010. [cit. 2010-

11-24]. Dostupný z WWW: <http://www.information-age.com/channels/data-centre-

and-it-infrastructure/news/1147048/european-union-defines-cloud-computing.thtml>.

[InvestorWords2010] InvestorWords. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.investorwords.com>.

[ISO2010] International Organization for Standardization. Webová prezentace. c2010. [cit. 2010-10-

01]. Dostupný z WWW: <http://www.iso.org>.

[ITSM2010] ITSM Encyclopedia. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://itsm.certification.info>.

[Karnam2010] KARNAM, Sridhar. Anything-as-a-Service (XaaS): Future of cloud computing.

Červen, 2010. c2010. [cit. 2010-09-29]. Dostupný z WWW:

<http://scienceofbusiness.wordpress.com/2010/06/17/anything-as-a-service-xaas-

future-of-cloud-computing/>.

[Key2003] KEY, Russell. QuickStudy: Extensible Access Control Markup Language (XACML) in

Computerworld. Květen, 2003. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.computerworld.com/s/article/81295/XACML>.

[Kirk2010] KIRK, Jeremy. Update: WikiLeaks‘ Assange arrested in London, denied bail in

ComputerWorld. Prosinec, 2010. c2010. [cit. 2010-12-10]. Dostupný z WWW:

<http://www.computerworld.com/s/article/9200118/Update_WikiLeaks_Assange_arre

sted_in_London_denied_bail>.

[Llorente2009] LLORENTE, Ignacio M. Building Your Open Source Private Cloud in Opensource

Magazine. Únor, 2009. c2009. [cit. 2010-11-06]. Dostupný z WWW:

<http://opensource.sys-con.com/node/833883>.

[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. 2010-

11-20]. Dostupný z WWW: <http://msdn.microsoft.com/en-

us/library/ms978527.aspx>.

[Mitrano2010] MITRANO, Tracy. Outsourcing and Cloud Computing for Higher Education. c2010.


<http://www.cit.cornell.edu/policies/publications/cloud/index.cfm>.

[Montero2010] MONTERO, Ruben S. Elastic Management of Computing Clusters. c2010. [cit. 2010-

11-09]. Dostupný z WWW: <http://blog.dsa-research.org/?p=98>.

[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.


<http://www.infosysblogs.com/cloudcomputing/2009/05/hands_on_building_a_privat

e_cl_1.html>.


-100/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:

<http://computerworld.cz/analyzy-a-studie/10-duvodu-proc-je-open-source-dobrou-

volbou-8029>.

[Opsview2010] Opsview Development Team. Business Continuity in the Cloud Era in TechWorld.

c2010. [cit. 2010-10-20]. Dostupný z WWW:

<http://blogs.techworld.com/monitoring-the-pulse-of-it/2010/05/business-continuity-

in-the-cloud-era/>.

[Pasnet2010] PASNET. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.pasnet.cz/pasnet/>.

[Peritor2009] AWS Case Study: Peritor. Případová studie. Červen, 2009. c2009. [cit. 2010-11-22].

Dostupný z WWW: <http://aws.amazon.com/solutions/case-studies/peritor/>.

[Potter2009] POTTER, Kurt. Gartner Integrated IT Spending Perspectives: Building Your Budget for

2010. Prosinec, 2009. c2009. [cit. 2010-10-03]. Dostupný z WWW:

<http://www.gartner.com/it/content/1210500/1210537/dec9_2010budgetplanningv9_k

potter.pdf>.

[Pribyl2010] PŘIBYL, Tomáš. Jak zajistit continuitu podnikání in SecurityWorld. c2010. [cit. 2010-

10-03]. Dostupný z WWW: <http://securityworld.cz/securityworld/jak-zajistit-

kontinuitu-podnikani-3100>.

[Pyle2010] PYLE, Chris. How to Ensure Business Continuity with Cloud Computing in eWeek. c2010.

[cit 2010-10-20]. Dostupný z WWW: <http://www.eweek.com/c/a/Cloud-

Computing/How-to-Ensure-Business-Continuity-with-Cloud-Computing/>.

[Rackspace2010] Rackspace Cloud. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný

z WWW: <http://www.rackspacecloud.com/cloud_hosting_products/servers>.

[ReliaCloud2010] ReliaCloud. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW:

<http://www.reliacloud.com/>.

[Schneier2009] SCHNEIER, Bruce. Homomorphic Encryption Breaktrough. c2009. [cit. 2010-10-01].

Dostupný z WWW:

<http://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html>.

[TechTarget2010] TechTarget. Search Security. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://searchsecurity.techtarget.com>.

[Vellante2010] VELLANTE, David. Business Continuity 2010: How Virtualization and Cloud

Computing Change the Game. c2010. [cit. 2010-10-21]. Dostupný z WWW:

<http://wikibon.org/wiki/v/Business_Continuity_2010:_How_Virtualization_and_Clo

ud_Computing_Change_the_Game>.

[Vogel2010a] VOGEL, Valerie. Business Continuity Management (ISO 15). Information Security

Guide. c2010. [cit. 2010-10-09]. Dostupný z WWW:

<https://wiki.internet2.edu/confluence/display/itsg2/Business+Continuity+Manageme

nt+%28ISO+14%29>.

[Vogel2010b] VOGEL, Valerie. Cloud Computing Security. Information Security Guide. c2010. [cit.


<https://wiki.internet2.edu/confluence/display/itsg2/Cloud+Computing+Security>.


-101/117-

[Wang2009] WANG, Chenxi. Cloud Security Front And Center. Forrester Blogs. c2009. [cit. 2010-

10-09]. Dostupný z WWW:

<http://blogs.forrester.com/security_and_risk/2009/11/cloud-security-front-and-

center.html>.

[Wardley2010] WARDLEY, Simon. What is Cloud? Březen, 2010. c2010. [cit. 2010-11-24].

Dostupný z WWW: <http://blog.gardeviance.org/2010/03/what-is-cloud.html>.

[Webopedia2010] Webopedia. Online. c2010. [cit. 2010-12-04]. Dostupný z WWW:

<http://www.webopedia.com>.

[Xymon2010] Xymon. Systém pro monitorování systémů a sítě. Webová prezentace. c2010. [cit.

2010-10-31]. Dostupný z WWW: <http://sourceforge.net/projects/xymon/>.

[Zahorova2010] ZÁHOROVÁ, Zuzana. IT ve školství s technologiemi Citrix in CIO Business World.

Listopad, 2010. c2010. [cit. 2010-11-14]. Dostupný z WWW:

<http://businessworld.cz/it-strategie/it-ve-skolstvi-s-technologiemi-citrix-6928>.

[Zoner2010] Obvyklé metody zálohování dat. Zoner Software. c2010. [cit. 2010-11-26]. Dostupný

z WWW: <http://www.zalohovani.net/inpage/obvykle-metody-zalohovani-dat/>.


-102/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]


-103/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 Requirements

Analysis

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 Control

Markup Language

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]


-104/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í a komunikační

technologie

ICT Obor nebo vývoj a vyuţívání technologie ke

zpracování informací. [Webopedia2010]

Information Technology

Infrastructure Library

ITIL Š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 Continuity

Management

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]


-105/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]


-106/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 Markup

Language

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

Language

SPML 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]


-107/117-

Virtual Machine Monitor VMM Hostující program, který umoţňuje provoz

násobného počtu identických prostředí.

[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


-108/117-

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

Strengths Weaknesses

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

Opportunities 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])


-109/117-

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

Označení

serveru

Operační systém 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])


-110/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?


-111/117-

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

Název OS

Řešení

GoGrid Amazon EC2 Rackspace

Cloud

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)


-112/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)


-113/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)


-114/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)


-115/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)


-116/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)


-117/117-

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

BCM plán – <Název plánu> – postup pro <prvních 24 – 48 hodin>

Popis stavu

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

Pravděpodobnost <nízká – střední – vysoká>

Dopad <nízký – střední – vysoký>

Pravděpodobná příčina <identifikujte nejčastější příčiny výskytu rizika>

Dotčené procesy <vyjmenujte dotčené procesy>

Odpovědnost <určete osobu, která je odpovědná za obnovení chodu dotčených

procesů>

Činnosti Okamţitě

<definujte činnosti, které

by měly být provedeny

okamţitě po vzniku rizika,

tj. během první hodiny>

Během <24 – 48 hodin>

<definujte návazné

činnosti vedoucí k plnému

obnovení chodu dotčených

procesů>

Sníţení dopadu <uveďte faktory, které by vedly ke sníţení dopadu rizika>

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

Zdroje <určete seznam zdrojů, na základě kterých lze provést nápravu>

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

vysoká škola ekonomická v praze - · pdf filecloud computing jako...

Documents