Cloud Computing jako nástroj BCM

Transkript

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
Akademický rok 2010/2011
Pavlína Lukášová
Prohlášení
Prohlašuji, ţe jsem diplomovou práci zpracovala samostatně a ţe jsem uvedla všechny pouţité
prameny a literaturu, ze kterých jsem čerpala.
……………………………….
V Praze dne 10. prosince 2010
podpis
-ii/x-
Poděkování
Za odborné vedení a podnětné rady poskytnuté při psaní této práce bych ráda poděkovala vedoucímu
své diplomové práce Ing. Dušanu Chlapkovi, Ph.D. Dále bych chtěla poděkovat také zástupcům
Výpočetního centra Vysoké školy ekonomické v Praze, kteří si ochotně našli čas a poskytli mi cenné
informace při zpracovávání této práce. Zvláštní poděkování bych ráda věnovala svým blízkým, kteří
mě podporovali během mého dosavadního studia.
-iii/x-
ABSTRAKT
Tato diplomová práce se zabývá moţnostmi propojení dvou konceptů: Business Continuity
Management a Cloud Computing. Problematika Business Continuity Management je zvláště zaměřena
na kontinuitu IT sluţeb a s ní souvisejících technických aspektů, mezi které patří Service Level
Management a stanovení Service Level Agreement. V oblasti Cloud Computingu je důraz kladen
především na otázky bezpečnosti, neboť tato část představuje největší překáţku implementace tohoto
konceptu.
Následně jsou v této diplomové práci identifikovány oblasti, ve kterých se oba výše zmíněné koncepty
doplňují, oblasti, ve kterých Cloud Computing přináší pro BCM nové moţnosti a také oblasti, které by
mohly činit potenciální problémy při konkrétní implementaci. Z tohoto důvodu je vymezeno několik
poţadavků, které klade koncept BCM na Cloud Computing řešení.
Dalším zaměřením této práce je charakteristika sektoru terciárního vzdělávání a postihnutí jeho
základních odlišností od sektoru komerčního. Na základě těchto odlišností práce argumentuje vyuţitím
vhodného Cloud Computing řešení za současného zlepšení Business Continuity.
Analýza potenciálu konceptů Business Continuity Management a Cloud Computing v sektoru
terciárního vzdělávání je následně verifikována oproti vydefinovaným poţadavkům a předpokladům.
Výsledkem této části práce jsou podklady pro analýzu specifických podmínek na Vysoké škole
ekonomické v Praze.
V další části této práce je provedeno multikriteriální srovnání pěti řešení Infrastructure-as-a-Service,
a to se zaměřením nejen na technické aspekty, ale také na aspekty finanční a aspekty Business
Continuity.
Zaměřením poslední části této práce je návrh praktického řešení pro konkrétní podmínky VŠE, a to jak
v oblasti Business Continuity Management, tak i v oblasti Cloud Computing s důrazem na současné
zlepšení Business Continuity. Navrhované řešení je znázorněno také pomocí strategické mapy
a opomenuto není ani zhodnocení řešení z finančního hlediska.
KLÍČOVÁ SLOVA
Business Continuity Management, BCM, Cloud Computing, virtualizace, infrastruktura jako sluţba,
IaaS, hybridní cloud
-iv/x-
ABSTRACT
This thesis deals with possible interconnections between two concepts: Business Continuity
Management and Cloud Computing. Business Continuity Management domain is especially aimed at
IT services continuity and related technical aspects such as Service Level Management or Service
Level Agreement. Within Cloud Computing domain, the security topic is especially emphasized since
this part of user concerns represents the biggest hurdle in the implementation process of this whole
concept.
Subsequently, there are certain areas identified where both concepts mentioned above are complement,
where Cloud Computing brings new opportunities for BCM and where could possible problems arise
during particular implementation. For those reasons there are several requirements defined. These
requirements are set by BCM concept on any Cloud Computing solution.
The characteristics of higher education and finding of basic differences from commercial sphere is
another orientation of this thesis. Based on these findings the thesis argues for usage of suitable Cloud
Computing solution together with improvement of Business Continuity in the same time.
Potential analysis of Business Continuity Management and Cloud Computing concepts in higher
education is subsequently verified against defined requirements and presumptions. Results of this part
of thesis serve as an input for analysis of specific conditions on University of Econimics in Prague.
Multi-criterion comparison of five Infrastructure-as-a-Service solution is performed in subsequent part
of this thesis. The comparison is not only aimed at technical aspects but also at financial and Business
Continuity aspects.
The last part of this thesis deals with practical proposal for specific conditions on University of
Economics in Prague within both Business Continuity Management and Cloud Computing domain.
The improvement of contemporary Business Continuity is emphasized. The proposal is also
demonstrated using strategic map and evaluated from the financial perspective.
KEYWORDS
Business Continuity Management, BCM, Cloud Computing, virtualization, Infrastructure-as-aService, IaaS, hybrid cloud
-v/x-
OBSAH
ÚVOD
1
VYMEZENÍ TÉMATU PRÁCE
CÍLE PRÁCE
PŘÍNOSY PRÁCE
PŘEDPOKLADY A OMEZENÍ PRÁCE
1
2
2
2
1 CHARAKTERISTIKA BUSINESS CONTINUITY MANAGEMENT
3
1.1 VÝZNAM BUSINESS CONTINUITY MANAGEMENT PRO CHOD ORGANIZACE
1.2 ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY
1.3 ROZHODNUTÍ O SESTAVENÍ PLÁNU BUSINESS CONTINUITY
1.4 KRIZOVÉ ŘÍZENÍ
1.5 SERVICE LEVEL MANAGEMENT
1.5.1 DOBA OBNOVY A BOD OBNOVY
1.6 ALTERNATIVNÍ PROSTŘEDÍ
1.7 ÚPRAVA BCM VE STANDARDECH
1.7.1 MEZINÁRODNÍ ORGANIZACE PRO STANDARDIZACI ISO
3
5
6
7
8
8
10
10
11
2 CHARAKTERISTIKA CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE
12
2.1 POTENCIÁL CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE
2.2 BENEFITY PLYNOUCÍ Z ADOPCE CLOUD COMPUTINGU
2.3 HROZBY CLOUD COMPUTINGU Z HLEDISKA BEZPEČNOSTI
2.3.1 ZNEUŽITÍ A NEZÁKONNÉ POUŽITÍ CLOUD COMPUTINGU
2.3.2 OTÁZKY ZABEZPEČENÍ ROZHRANÍ
2.3.3 SDÍLENÍ INFRASTRUKTURY
2.3.4 ZTRÁTA NEBO ÚNIK DAT
2.3.5 OCHRANA UŽIVATELSKÝCH ÚČTŮ
2.4 ZRANITELNOSTI CLOUD COMPUTINGU
2.5 IDENTITY & ACCESS MANAGEMENT VE VAZBĚ NA CLOUD COMPUTING
2.6 NÁVRH BEZPEČNOSTNÍCH OPATŘENÍ PRO ADOPCI CLOUD COMPUTINGU
15
15
16
17
18
18
19
19
20
21
22
3 VAZBA CLOUD COMPUTINGU NA BUSINESS CONTINUITY MANAGEMENT
24
3.1 CO CLOUD COMPUTING SPOLEČNOSTEM PŘINÁŠÍ PRO JEJICH BUSINESS CONTINUITY
3.1.1 CLOUD COMPUTING JAKO VÝCHODISKO Z KRIZE
3.1.2 JAK MŮŽE CLOUD COMPUTING POMOCI ZAJISTIT BUSINESS CONTINUITY
3.1.3 PRAVIDLA ADOPCE CLOUD COMPUTINGU JAKO NÁSTROJE BUSINESS CONTINUITY
3.2 PŘEPOKLAD PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM
3.2.1 ŘÍZENÍ RIZIK
3.3 POŽADAVKY BCM NA CLOUD COMPUTING
3.4 KATEGORIE A - BEZPEČNOST
3.4.1 P01 BEZPEČNOST A MONITORING
3.4.2 DŮVĚRNOST INFORMACÍ
3.5 KATEGORIE B - DISASTER RECOVERY
3.5.1 P02 ZÁLOHOVÁNÍ A ARCHIVACE
3.6 KATEGORIE C - SERVICE LEVEL AGREEMENT
3.6.1 P03 DOSTUPNOST SLUŽEB
24
24
25
26
27
27
27
28
28
29
29
30
31
32
-vi/x-
3.7 NEGATIVNÍ DOPAD CLOUD COMPUTINGU NA BUSINESS CONTINUITY
33
4 VYUŽITÍ BCM A CLOUD COMPUTINGU V OBLASTI TERCIÁRNÍHO VZDĚLÁVÁNÍ
35
4.1 CHARAKTERISTIKA SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ A JEHO ODLIŠNOSTI OD SEKTORU
35
36
36
37
38
39
40
42
43
44
44
44
45
47
47
SOUKROMÉHO
4.2 VYUŽITÍ BCM V SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ
4.2.1 FÁZE 1 – POROZUMĚNÍ ORGANIZACI
4.2.2 FÁZE 2 – URČENÍ STRATEGIE BCM
4.2.3 FÁZE 3 – TVORBA A IMPLEMENTACE BCM PLÁNU
4.2.4 FÁZE 4 – ŠKOLENÍ, ÚDRŽBA A REVIZE PLÁNU
4.3 POTENCIÁL CLOUD COMPUTINGU PRO SEKTOR TERCIÁRNÍHO VZDĚLÁVÁNÍ
4.3.1 KTERÉ SLUŽBY PŘESUNOUT DO CLOUDU A KDY
4.3.2 FENOMÉN „CONSUMERIZACE“ A SDÍLENÍ OBSAHU
4.3.3 VYUŽITÍ CLOUD COMPUTINGU PRO KOMUNIKACI
4.4 NAPLNĚNÍ PODMÍNEK BCM NA CLOUD COMPUTING ŘEŠENÍ
4.4.1 PŘEDPOKLAD – ŘÍZENÍ RIZIK
4.4.2 POŽADAVEK P01 BEZPEČNOST A MONITORING
4.4.3 POŽADAVEK P02 ZÁLOHOVÁNÍ A ARCHIVACE
4.4.4 POŽADAVEK P03 DOSTUPNOST SLUŽEB
4.5 DALŠÍ CHARAKTERISTIKY SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ PRO VYUŽITÍ CLOUD COMPUTINGU
JAKO NÁSTROJE BCM
47
4.5.1 SP01 SEZÓNNOST
47
4.5.2 SP02 ZÁVISLOST NA IT
48
4.5.3 SP03 KONKURENČNÍ TLAK
48
4.5.4 SP04 INOVACE
48
5 POTENCIÁL BCM A CLOUD COMPUTINGU V PODMÍNKÁCH VŠE PRAHA
49
5.1 POPIS SOUČASNÉHO STAVU
5.1.1 SWOT ANALÝZA
5.1.2 PROCESNÍ MAPA VŠE
5.1.3 VÝPOČETNÍ CENTRUM
5.1.4 TECHNOLOGICKÁ INFRASTRUKTURA
5.1.5 STUDIJNÍ INFORMAČNÍ SYSTÉM
5.2 VÝBĚR VHODNÉ VARIANTY CLOUDOVÉHO ŘEŠENÍ
5.3 INFRASTRUKTURA JAKO SLUŽBA
5.4 VIRTUALIZACE
5.5 SOUKROMÝ CLOUD
5.6 HYBRIDNÍ CLOUD
5.7 VYUŽITÍ CLOUD COMPUTINGU PRO VÝUKU
5.8 CLOUD COMPUTING A OPEN SOURCE
5.9 POHLED ODDĚLENÍ VÝPOČETNÍHO CENTRA VŠE
5.9.4 VIRTUALIZACE NA VŠE
49
49
50
51
52
52
53
53
56
56
58
59
60
61
61
61
62
62
6 ANALÝZA POSKYTOVATELŮ CLOUDOVÝCH ŘEŠENÍ NA TRHU
64
-vii/x-
6.1 VÝBĚR POSKYTOVATELŮ IAAS
6.2 VÝBĚR KRITÉRIÍ PRO ANALÝZU
6.3 POPIS VYBRANÝCH KRITÉRIÍ
6.3.1 TECHNICKÉ ASPEKTY
6.3.2 ASPEKTY BCM
6.3.3 FINANČNÍ ASPEKTY
6.4 GOGRID CLOUD HOSTING
6.4.1 HODNOCENÍ TECHNICKÝCH ASPEKTŮ
6.4.2 HODNOCENÍ ASPEKTŮ BCM
6.4.3 HODNOCENÍ FINANČNÍCH ASPEKTŮ
6.4.4 CELKOVÉ HODNOCENÍ GOGRID CLOUD HOSTING
6.5 AMAZON EC2
6.5.4 CELKOVÉ HODNOCENÍ AMAZON EC2
6.6 RACKSPACE CLOUD SERVERS
6.6.4 CELKOVÉ HODNOCENÍ RACKSPACE CLOUD SERVERS
6.7 RELIACLOUD
6.7.4 CELKOVÉ HODNOCENÍ RELIACLOUD
6.8 ELASTICHOSTS
6.8.4 CELKOVÉ HODNOCENÍ ELASTICHOSTS
6.9 VZÁJEMNÉ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ
6.9.1 ZHODNOCENÍ OBLASTI TECHNICKÝCH ASPEKTŮ
6.9.2 ZHODNOCENÍ OBLASTI BUSINESS CONTINUITY
6.9.3 ZHODNOCENÍ OBLASTI FINANČNÍCH ASPEKTŮ
6.9.4 MULTIKRITERIÁLNÍ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ
6.10 ZÁVĚREČNÉ ZHODNOCENÍ
64
65
66
66
67
68
69
69
69
70
70
71
71
71
71
71
72
72
72
73
73
74
74
74
74
74
75
75
75
75
76
77
77
78
78
79
79
7 NÁVRH VHODNÉHO ŘEŠENÍ PRO VŠE PRAHA
80
7.1 OBLAST BUSINESS CONTINUITY MANAGEMENT
7.2 OBLAST CLOUD COMPUTINGU
7.2.1 NAPLNĚNÍ PŘEDPOKLADU ŘÍZENÍ RIZIK
7.2.2 NAPLNĚNÍ POŽADAVKŮ BCM NA ŘEŠENÍ CLOUD COMPUTINGU
80
80
82
83
84
84
85
87
-viii/x-
7.2.3 BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ
7.2.4 FINANČNÍ ZHODNOCENÍ
7.3 SHRNUTÍ
88
89
90
ZÁVĚR
92
POUŽITÁ LITERATURA
94
INTERNETOVÉ ZDROJE
97
TERMINOLOGICKÝ SLOVNÍK
102
PŘÍLOHA A – SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ
108
PŘÍLOHA B – SEZNAM SERVERŮ PROVOZOVANÝCH NA VŠE
109
PŘÍLOHA C – STRUKTURA ROZHOVORU SE ZÁSTUPCI VÝPOČETNÍHO CENTRA VŠE
110
PŘÍLOHA D – PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ
111
PŘÍLOHA E – UKÁZKA WEBOVÉHO ROZHRANÍ DOSTUPNÉHO IAAS ŘEŠENÍ
112
PŘÍLOHA F – ŠABLONA PLÁNU BUSINESS CONTINUITY
117
SEZNAM OBRÁZKŮ
OBR. 1 - PŘEHLED KONCEPTU BUSINESS CONTINUITY MANAGEMENT (ZDROJ: AUTOR)
OBR. 2 - ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY MANAGEMENT (ZDROJ: [BCI2010A])
OBR. 3 - GRAFICKÉ ZNÁZORNĚNÍ RPO A RTO (ZDROJ: AUTOR)
OBR. 4 - TYPY CLOUD COMPUTINGU (ZDROJ: AUTOR)
OBR. 5 - PŘEHLED KONCEPTU CLOUD COMPUTING (ZDROJ: AUTOR)
OBR. 6 - POŘADÍ OBAV Z ADOPCE CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [VELTE2010])
OBR. 7 - SROVNÁNÍ VÝPADKŮ EMAILOVÝCH SLUŽEB V MIN./MĚSÍC (ZDROJ: [GLOTZBACH2008])
OBR. 8 - PROCESNÍ MODEL VŠE (ZDROJ: AUTOR, VYTVOŘENO NA ZÁKLADĚ [TRCKA2009])
OBR. 9 - ARCHITEKTURA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: [LENK2009])
OBR. 10 - ZOBRAZENÍ HYBRIDNÍHO CLOUDU (ZDROJ: AUTOR)
OBR. 11 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR)
OBR. 12 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR)
OBR. 13 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR)
OBR. 14 - GRAFICKÉ ZNÁZORNĚNÍ HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR)
OBR. 15 - GRAFICKÉ ZNÁZORNĚNÍ ŘEŠENÍ ELASTICHOSTS (ZDROJ: AUTOR)
OBR. 16 - GRAFICKÉ ZNÁZORNĚNÍ POROVNÁNÍ IAAS ŘEŠENÍ VE 3 ROZMĚRECH (ZDROJ: AUTOR)
OBR. 17 - GRAFICKÉ ZNÁZORNĚNÍ VZTAHU MEZI NÁKLADY NA OBNOVU A ZTRÁTOU ORGANIZACE (ZDROJ:
AUTOR)
OBR. 18 - BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ (ZDROJ: AUTOR)
OBR. 19 - WEBOVÉ ROZHRANÍ (ZDROJ: AUTOR)
OBR. 20 - VYTVOŘENÍ INSTANCE (ZDROJ: AUTOR)
OBR. 21 - NASTAVENÍ PARAMETRŮ INSTANCE (ZDROJ: AUTOR)
OBR. 22 - SPUŠTĚNÍ INSTANCE (ZDROJ: AUTOR)
OBR. 23 - TIGHTVNC PŘIHLÁŠENÍ (ZDROJ: AUTOR)
OBR. 24 - ROZHRANÍ INSTANCE (ZDROJ: AUTOR)
OBR. 25 - ÚČTOVÁNÍ SLUŽEB (ZDROJ: AUTOR)
-ix/x-
4
6
10
13
14
18
33
51
55
59
70
72
73
75
76
79
81
89
112
113
114
114
115
115
116
SEZNAM TABULEK
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
TAB.
1 - KATEGORIZACE POŽADAVKŮ BCM NA CLOUD COMPUTING ŘEŠENÍ (ZDROJ: AUTOR)
2 - PŘEHLED SROVNÁVANÝCH KRITÉRIÍ (ZDROJ: AUTOR)
3 - HODNOCENÍ GOGRID CLOUD HOSTING (ZDROJ: AUTOR)
4 - HODNOCENÍ AMAZON EC2 (ZDROJ: AUTOR)
5 - HODNOCENÍ RACKSPACE CLOUD SERVERS (ZDROJ: AUTOR)
6 - HODNOCENÍ RELIACLOUD (ZDROJ: AUTOR)
7 - HODNOCENÍ ELASTICHOSTS (ZDROJ: AUTOR)
8 - POŘADÍ IAAS ŘEŠENÍ DLE HODNOCENÝCH KRITÉRIÍ (ZDROJ: AUTOR)
9 - POŘADÍ IAAS ŘEŠENÍ DLE TECHNICKÝCH PARAMETRŮ (ZDROJ: AUTOR)
10 - POŘADÍ IAAS ŘEŠENÍ DLE PARAMETRŮ BCM (ZDROJ: AUTOR)
11 - POŘADÍ IAAS ŘEŠENÍ DLE FINANČNÍCH KRITÉRIÍ (ZDROJ: AUTOR)
12 - SOUHRNNÁ TABULKA ANALÝZY DOPADU (ZDROJ: AUTOR)
13 - PŘÍKLAD PLÁNU BCM PRO RIZIKO ZTRÁTY DAT (ZDROJ: AUTOR)
14 - FINANČNÍ ZHODNOCENÍ NAVRŽENÉHO ŘEŠENÍ (ZDROJ: AUTOR)
15 - SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ (ZDROJ: [VSE2010])
16 - SEZNAM SERVERŮ NA VŠE (ZDROJ: [TRCKA2009])
17 - PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ (ZDROJ: AUTOR)
18 - ŠABLONA PLÁNU BUSINESS CONTINUITY (ZDROJ: AUTOR)
-x/x-
28
65
70
71
73
74
76
77
77
78
78
81
83
89
108
109
111
117
ÚVOD
S koncepty Business Continuity Management a Cloud Computing se v dnešní době setkáváme často,
a to zejména v kontextu řízení organizace a oblasti IT sluţeb. V době, kdy je kladen důraz na
sniţování nákladů a efektivní vyuţívání dostupných zdrojů a v době, kdy pomalu doznívá finanční
krize, a tak jakékoli prosazení nového konceptu vyţaduje velkou dávku odvahy, trpělivosti
a především pádných argumentů.
Na první pohled se zdá, ţe zajištění Business Continuity, tedy plynulého chodu organizace, by mělo
být prioritou kaţdé fungující organizace. Ve skutečnosti však plán Business Continuity nemá ani
zdaleka většina společností. Proč tomu tak je? Plán Business Continuity je často chápán jako ochrana
před něčím, co se stane jednou za několik desítek let, nastane-li taková situace vůbec někdy. To ovšem
neodpovídá realitě, protoţe nejčastější příčinou ohroţení kontinuity podniku nejsou přírodní
katastrofy, ale technické závady nebo chyby zaviněné lidským faktorem.
Tyto otázky je moţné řešit vyuţitím Cloud Computingu, jinými slovy vyuţívat poskytovaný software,
platformu nebo infrastrukturu jako sluţbu v rámci sítě internet a odebírat tuto sluţbu pouze v případě
potřeby. Díky tomuto konceptu se společnosti nejen sniţují náklady, ale část IT zdrojů se tak
automaticky přesouvá na jiné místo, čímţ je automaticky zajištěna dostupnost sluţeb v případě, kdy by
se v budově společnosti vyskytl jakýkoli problém.
Tato diplomová práce se zaměřuje na propojení obou konceptů: Business Continuity Management
a Cloud Computing. Hledá oblasti, ve kterých se oba koncepty doplňují a oblasti, které by mohly činit
potenciální problémy při konkrétní implementaci.
VYMEZENÍ TÉMATU PRÁCE
Nejprve jsou v této práci popsány základní charakteristiky Business Continuity Management. Jedná se
o velmi širokou a komplexní oblast, proto je hlavním zaměřením kontinuita IT sluţeb a s ní související
technické aspekty, mezi které patří Service Level Management a stanovení Service Level Agreement.
V další části je podrobněji přiblíţen koncept Cloud Computingu. Obdobně jako u Business Continuity,
i zde se jedná o velmi širokou problematiku, proto byla vybrána pouze část bezpečnosti, které je
věnována větší pozornost. Otázky bezpečnosti jsou v této práci řešeny z toho důvodu, ţe bezpečnost je
nejčastější příčinou obav společnosti implementovat koncept Cloud Computingu.
Po popsání základních charakteristik obou konceptů je pozornost zaměřena na oblast terciárního
vzdělávání a jeho odlišnosti od komerčního sektoru. Zde je popsáno, jakým způsobem je moţné
vyuţívat cloudová řešení a jaká je jejich vhodnost pro tuto oblast.
Na tuto kapitolu navazuje analýza potenciálu vyuţití Business Continuity Management a Cloud
Computing na Vysoké škole ekonomické v Praze (dále VŠE), která vychází z popsání současného
stavu výpočetní techniky na VŠE.
V následující části je provedena analýza poskytovatelů cloudových řešení, pro kterou byli vybráni
poskytovatelé řešení Infrastructure-as-a-Service. Tito poskytovatelé byli vybráni z důvodu své
vhodnosti pro vyuţití v sektoru terciárního vzdělávání. Jejich vhodnost je výsledkem předchozí
analýzy tohoto sektoru. Celkem bylo hodnoceno pět poskytovatelů, jejichţ nabídku bylo moţné
srovnávat.
Závěrem této práce byla analýza vhodnosti Cloud Computing řešení pro naplnění Business Continuity
poţadavků v konkrétních podmínkách VŠE a návrh vhodného řešení pro další rozvoj této instituce.
-1/117-
CÍLE PRÁCE
Tato diplomová práce má několik cílů, které lze vymezit takto:




Identifikovat vazbu konceptu Cloud Computing na koncept Business Continuity Management
a pokusit se nalézt oblasti, ve kterých Cloud Computing přináší pro Business Continuity nové
moţnosti.
Charakterizovat sektor terciárního vzdělávání, postihnout základní odlišnosti od sektoru
komerčního a pro tyto odlišnosti argumentovat vhodným řešením Cloud Computingu za
současného zlepšení Business Continuity.
Provést multikriteriální srovnání Infrastructure-as-a-Service řešení nabízených na trhu
cloudových sluţeb a argumentovat, proč jsou tato řešení pro sektor terciárního vzdělávání
vhodná.
Na základě analýzy současného stavu navrhnout moţné řešení Cloud Computing sluţeb
v prostředí Vysoké školy ekonomické v Praze.
PŘÍNOSY PRÁCE
Přínosy této práce lze shrnout do následujících bodů:



Zmapování vazeb mezi oběma koncepty a vymezení oblastí, ve kterých je účinné a účelné
vyuţít konceptu Cloud Computing pro zlepšení Business Continuity, a dosáhnout tak
efektivnosti IT zdrojů společnosti či sníţení nákladů.
Provedení multikriteriálního srovnání nejvýznamnějších poskytovatelů IaaS řešení, které
můţe čtenáři slouţit v procesu rozhodování o implementaci cloudových sluţeb, a to s důrazem
na kritéria technologická, kritéria Business Continuity a v neposlední řadě také kritéria
finanční.
Praktický návrh řešení Cloud Comutingu ve specifickém prostředí Vysoké školy ekonomické
v Praze.
PŘEDPOKLADY A OMEZENÍ PRÁCE
Omezením této práce v oblasti Business Continuity Managementu je její soustředění zejména na IT
sluţby. Z důvodu širokého rozsahu tohoto konceptu bylo nutné do této diplomové práce vybrat pouze
určitou část. IT sluţby byly vybrány především pro jejich úzkou vazbu na Cloud Computing řešení.
Předpokladem této práce v oblasti Cloud Computing je skutečnost, ţe bezpečnostní aspekty jsou
nejčastější příčinou, proč se společnosti zdráhají vyuţívat cloudových sluţeb naplno. Proto se tato
práce v oblasti Cloud Computingu zaměřuje především na otázky bezpečnosti.
Posledním omezením této práce je návrh praktického řešení pro specifické podmínky Vysoké školy
ekonomické v Praze. Záměrně byly pro návrh řešení opomíjeny ostatní typy a velikosti společností.
-2/117-
1 CHARAKTERISTIKA BUSINESS CONTINUITY MANAGEMENT
Business Continuity Management z velké části zahrnuje aktivitu plánování kontinuity pro případy
vzniku interní či externí krize. Tento proces v sobě kombinuje jak měkké, tak tvrdé přístupy tak, aby
vytvořil účinnou prevenci a obnovu organizace, a to za současného zachování konkurenční výhody
a bez ztráty na pověsti společnosti. Business Continuity Management (dále jen BCM) začal být v
posledních letech často skloňovaným pojmem. Bývá spojován především s krizovým řízením, ale ve
skutečnosti BCM navazuje na řízení podnikových procesů, koncept bezpečnosti, logistiku a na řadu
dalších principů efektivního fungování společnosti. Rozšířil se jak v soukromé sféře, tak ve sféře
veřejné, výjimkou není ani sektor školství. V této kapitole se zaměříme na základní charakteristiky
tohoto konceptu.
Definice BCM tak, jak je pouţívána evropským orgánem Business Continuity Institute, hovoří o BCM
jako o konceptu důleţitém pro všechny organizace nezávisle na sektoru ekonomiky, neboť udrţuje
nejen efektivní chod společnosti, ale zajišťuje také prevenci případných ztrát a ochranu značky či
dobrého jména podniku:
"Business Continuity Management je holistický přístup k řízení společnosti, jenţ identifikuje
potenciální dopady na organizaci, které by mohly ohrozit efektivní fungování společnosti, a poskytuje
rámec pro vybudování pruţného systému schopného reagovat na krizové situace, a hájit tak zájmy
zainteresovaných stran." [BCI2010b]
Základním předpokladem úspěšné aplikace BCM je identifikace procesů organizace, a to především
procesů klíčových, tj. takových procesů, jejichţ narušení nebo úplná absence by způsobila
neschopnost organizace naplňovat své cíle. Poté, co jsou procesy identifikovány a v ideálním případě
také popsány, můţe organizace pokračovat v identifikaci a ohodnocení rizik, se kterými je moţné se
setkat. Podle [Billsberry2004] patří mezi nejčastěji zmiňované případy rizik kategorie přírodních
katastrof, jako jsou poţáry či povodně, v poslední době se také často setkáme s riziky teroristického
útoku či útoku po síti internet. Přitom v praxi mnohem častějšími riziky jsou rizika selhání
technologie, poškození rozvodů vody či přerušení dodávky elektrické energie.
Dojde-li k identifikaci klíčových procesů, jejich výstupů a ohodnocení rizik ohroţujících pravidelný
chod organizace, je moţné začít sestavovat plán, který by stanovoval, jaká opatření mají být
aplikována v případě, ţe nastanou podmínky způsobené ohodnocenými riziky. Součástí BC plánu není
však pouze ohodnocení dopadu rizik na podnikové procesy, ale je jí také porozumění tomu, které části
pouţívané IT technologie jsou zranitelné různými typy rizik. [Snedaker2007]
Je-li plán jednou stanoven, neznamená to, ţe je stanoven na několik let dopředu a nebude potřeba ho
obnovovat. Plán BC je potřeba neustále aktualizovat, jedná se o stále opakující se proces revize plánu,
který by měl vycházet ze samotné podstaty podnikové kultury.
1.1 VÝZNAM BUSINESS CONTINUITY MANAGEMENT PRO CHOD ORGANIZACE
Proč je BCM pro chod organizace důleţité? Není to dáno jenom z toho důvodu, ţe organizace
v takovém případě vlastní návod na to, co dělat v případě, kdy nastane krizová situace, ale zároveň
pomáhá minimalizovat počet špatných rozhodnutí v případě, ţe krize nastane. Sniţuje také závislost
na zaměstnancích, kteří jsou ve společnosti přítomni v době krize a jejichţ specifické rozhodnutí by
mohlo zapříčinit ztrátu dat, příjmů nebo zákazníků [Denault2004]. V neposlední řadě by mohlo
poškodit také pověst, značku a dobré jméno společnosti.
Z výše uvedených důvodů vyplývá, ţe definice BC plánu je důleţitá ve všech odvětvích, neboť je
podstatné, aby byla společnost schopna na vzniklou situaci reagovat efektivně a rychle, a mohla tak
-3/117-
včasně obnovit chod podnikových procesů a v neposlední řadě také zajistit bezpečnost zaměstnanců
i veřejnosti. Podle [Snedaker2007] je klíčovou hnací silou pro BCM zhodnocení toho, jak velké
narušení chodu společnosti je pro podnik přijatelné a co je společnost schopna a ochotna udělat pro to,
aby narušení předešla.
V dobách ekonomické recese se pro BCM argumentuje obtíţněji neţ v dobách "dobrých". Těţko lze
předpokládat, ţe je moţné management společnosti přesvědčit tvrzením, ţe BCM pomůţe společnosti
vyrovnat se s něčím, co potenciálně hrozí jednou za několik let. [Pribyl2010] Důleţitou skutečností
však je to, ţe BCM napomáhá zajistit a udrţet stabilitu v otázkách důvěry ze stran zákazníků a jejich
loajalitu. Samotný tento fakt má za důsledek, ţe BCM pomáhá udrţovat tok peněz neboli cash flow.
Nutnost identifikace rizik potenciálně hrozících společnosti a definice plánu Business Continuity (dále
jen BC plánu) není spojena jen s rozvojem informačních technologií či érou internetu. Potřeba BC
plánu byla nutná uţ od samotného počátku vzniku podnikání. Popření potřeby sestavení BC plánu
v 21. století, kdy technologie sahá prakticky do všech koutů jakékoli organizace, by však nemělo být
nadále akceptováno. Jak jiţ bylo uvedeno výše, BCM by měl být zakořeněn v samotné podnikové
kultuře a měli by to být právě manaţeři odpovědní za zajištění dostupnosti systémů či sluţeb, kteří by
měli mít eminentní zájem na sestavení BC plánu. Absence BC plánu ve společnosti by totiţ mohla být
chápána jako nedbalost plnění jejich pracovních povinností a výše uvedené důsledky krize by
společnost mohly dovést ke zbytečně vysokým pokutám.
Na Obr. 1 je znázorněn přehled konceptu BCM. Jednotlivým částem popsaným na obrázku bude
věnován následující text této kapitoly. Zvláštní důraz je kladen na popsání ţivotního cyklu, krizové
řízení a určení doby a bodu obnovy jednotlivých podnikových procesů.
Obr. 1 - Přehled konceptu Business Continuity Management (Zdroj: Autor)
-4/117-
1.2 ŽIVOTNÍ CYKLUS BUSINESS CONTINUITY
Ţivotní cyklus Business Continuity popisuje nejen postup tvorby plánu, ale také aktivity tvorbě plánu
předcházející, mezi které patří například identifikace rizik, a aktivity následné. Samotný ţivotní cyklus
Business Continuity sestává z několika fází (viz Obr. 2 – Ţivotní cyklus Business Continuity
Management).
Ve vnitřním kruhu nalezneme řízení programu a politiky BCM. Politikou BCM se rozumí klíčový
dokument, který určuje rozsah BCM a představuje důvod, proč by mělo být BCM implementováno.
Politika BCM musí být v souladu se strategií organizace. Dokument je základním vstupem pro proces
BCM plánování.
Ve vnějším kruhu je znázorněno začlenění BCM do kultury organizace, pod kterým se rozumí
vybudování takového systému, kde by byl BCM součástí kaţdodenního provozu organizace a byl
v souladu s prioritami společnosti. Zpravidla je nutné, aby se kultura organizace na základě BCM
politiky změnila.
V prostředním kruhu je zobrazen proces BCM sestávající ze čtyř hlavních fází [BCI2010a]:




Porozumění organizaci – porozumění organizaci je činnost, která reviduje činnost organizace
ve smyslu jejích cílů, jednotlivých funkcí a omezení prostředí, ve kterém se pohybuje. Pro
porozumění organizaci jsou zpravidla vyuţívány následující nástroje:
o Analýza dopadu (Business Impact Analysis – BIA) – analýza slouţící k ohodnocení
dopadu, jaký by měla narušující událost na provoz organizace,
o Continuity Requirements Analysis (CRA) – vyuţívá se k odhadu zdrojů a sluţeb,
které vyţaduje kaţdá činnost, aby mohla být obnovena do běţného provozu
organizace,
o Ohodnocení rizik (Risk Assessment – RA) – je pouţíváno k odhadu pravděpodobnosti
dopadu neznámé hrozby na určitou funkci organizace. Před provedením analýzy
odhodnocení rizik by měla být provedena analýza dopadu (BIA), pomocí které jsou
určeny klíčové činnosti podniku.
Určení strategie BCM – jedná se o aktivitu, která určuje strategii nejlépe naplňující poţadavky
organizace a sestavuje postupy na taktické úrovni (pro oblasti lidských zdrojů, budov
a zařízení, technických zdrojů apod.). V rámci tohoto kroku jsou stanovovány hodnoty
parametrů maximální tolerovatelná doba odstávky, čas obnovy a doba obnovy, které jsou
podrobněji popsány v kapitole 1.5.1.
Tvorba a implementace BC plánu – na této úrovni dochází k sestavení sady plánů Business
Continuity. Tyto plány zahrnují jasně definovaný proces eskalace a řízení incidentu, způsob
komunikace mezi zainteresovanými stranami a plány obnovy narušených činností na taktické,
operativní i strategické úrovni.
Školení, údrţba a revize – tato fáze ţivotního cyklu vychází z dokumentu politiky BCM a
zajišťuje ověřování, zda by byla organizace stále schopna obnovit svou činnost a zhodnocuje
dopad změn v organizační struktuře, podnikových procesech, trhu, rizicích, prostředí a
podnikové strategie na schopnost zajistit kontinuitu podniku.
-5/117-
ě
len
BCM
ní
do kultury organ
iz
a ce
č
Za
Porozumění
organizaci
Školení,
údržba
a revize
Řízení programu a
politiky BCM
Určení
strategie
BCM
Tvorba
a implementace
BCM plánu
Obr. 2 - Ţivotní cyklus Business Continuity Management (Zdroj: [BCI2010a])
1.3 ROZHODNUTÍ O SESTAVENÍ PLÁNU BUSINESS CONTINUITY
Horní ekonomickou hranicí společnosti bývají výnosy, o jejichţ maximalizaci podnik usiluje. K tomu,
aby společnost dosáhla zvýšení výnosů, můţe dospět kupříkladu získáním většího podílu na trhu.
Měnit se však nebude jen velikost podílu na trhu a výše trţeb, ale také výše nákladů a s nimi spojená
rentabilita investice do zvýšení podílu na trhu. A právě rentabilita je jakousi spodní ekonomickou
hranicí společnosti, která se stává důleţitějším měřítkem v dlouhodobém horizontu. Proto většina
společností hledá rovnováhu mezi růstem spodní a horní hranice. [Snedaker2007]
Spojitost mezi těmito hranicemi a sestavením BC plánu je právě v uvědomění si, jakou cenu je podnik
ochoten zaplatit za činnost sestavení plánu a jakou cenu je ochoten zaplatit v případě, ţe nastane
krizová situace a selhání podniku bude mít finanční dopady. Je-li společnost zaměřena na zvyšování
výnosů, její prioritou sestavení plánu BC nebude. Vlastnictví BC plánu však můţe být chápáno jako
konkurenční výhoda, neboť zákazníci by existenci takového plánu mohli vnímat pozitivně. Na druhé
straně, je-li společnost zaměřena na zvyšování rentability, je snazší přesvědčit management, ţe
potenciální hrozba by měla zásadní dopad na provozní výkonnost. Není pochyb o tom, ţe ať uţ se
společnost zaměřuje na zvyšování výnosů nebo na zvyšování rentability, v obou případech je dopad
selhání podniku značný, a proto by si společnost měla uvědomit, jakou cenu je ochotna obětovat ve
prospěch, resp. v neprospěch sestavení BC plánu.
Ze studie provedené v roce 2005 [Snedaker2007] vyplývá, ţe ze všech společností, které byly
postihnuty ztrátou podstatné části dat a zároveň postrádaly BC plán nebo plán obnovy dat, 43% nebylo
-6/117-
nikdy obnoveno, 51% ukončilo svou činnost do 2 let a pouze 6% z nich přeţilo v dlouhodobém
horizontu.
Ve stejném roce byla provedena jiná studie [Snedaker2007], která odhalila, ţe 92% společností se
shoduje na tom, ţe je pro ně důleţité plánovat opatření pro mimořádné události, 88% uvedlo, ţe jsou
vlastníky jakéhokoli plánu pro mimořádné situace a pouze 39% z dotázaných odpovědělo, ţe BC plán
mají. Co je však zajímavé, je skutečnost, ţe ačkoli celých 92% uvedlo, ţe je důleţité plánovat pro
mimořádné události, 12% dotázaných si nemyslí, ţe vlastnit plán pro mimořádné situace má pro jejich
společnost význam.
1.4 KRIZOVÉ ŘÍZENÍ
Krizové řízení je proces přípravy na vznik nepředvídané negativní události, která by mohla zapříčinit
omezení činnosti podniku, nebo dokonce její zastavení. Tato negativní událost ohroţuje organizaci,
zainteresované strany nebo veřejnost. [ICM2005]
Krizové řízení s BCM velmi úzce souvisí. BCM je zaměřeno primárně na dlouhodobější aspekty
zotavení z krize jako je např. přemístění provozu do jiné lokace. Z plánů BCM však krizové řízení
vychází, neboť se v podstatě jedná o rozhodování, zda další vývoj událostí povede k zániku provozu
organizace, nebo spíše k obnovení stavu na úroveň existující před vznikem krize.
Krize je podle [ICM2005] definována jako významné narušení podnikové činnosti. Událost, která
posléze ústí v krizi má tři základní elementy:



hrozba pro organizaci,
moment překvapení,
omezená doba pro rozhodování.
Krize můţe vznikat několika způsoby. Podle [Martanova2010] můţe být krize na jedné straně
způsobena ze strany businessu (např. nízký odbyt, management neschopný tvořit strategická
rozhodnutí, nízká poptávka, špatná komunikace ve firmě, ztráta klíčových zaměstnanců, silná
legislativní regulace apod.) a na straně druhé podniku hrozí krize způsobené katastrofami (poţár v
budově podniku, havárie na výrobní lince, epidemie infekční choroby, kolaps datového centra, záplavy
atd.). Vedle těchto řekněme nejběţnějších událostí týkajících se krizového řízení rozeznáváme také
hrozby kriminálního charakteru plynoucí z kriminálních činností, sociálněpolitické hrozby a také
hrozby typické pro určitý sektor ekonomiky, např. u bank lze hovořit o finančních hrozbách.
Aby společnost předcházela katastrofálním důsledkům krize, je pro ni důleţité rozdělit své procesy do
několika následujících oblastí:



procesy, které vydělávají peníze a jsou jádrem podniku,
procesy, které peníze nevydělávají, ale tvoří jádro podniku,
podpůrné procesy.
Je úlohou kaţdého krizového manaţera nastavit taková opatření, která budou nejvhodnější pro danou
kategorii procesů. V rámci komplexního ochranného systému řízení kontinuity jsou pro vytipované
klíčové procesy vytvářeny procesy alternativní, které jsou spuštěny v případě, kdy původní proces
nemůţe fungovat svým běţným způsobem.
Mezi základy krizového řízení patří také sestavení skupin lidí na několika různých úrovních, které
mají na starosti řešení problému v případě, kdy nastane. Tyto skupiny jsou hierarchicky uspořádány.
Nejníţe postavené týmy odpovídají za řešení problému na úrovni divizí nebo podnikových jednotek,
zatímco na nejvyšší úrovni je tým koordinující činnosti týmů jemu podřízených, který se zároveň
zodpovídá vedení společnosti a pravidelně jej informuje o aktuálním vývoji situace.
-7/117-
1.5 SERVICE LEVEL MANAGEMENT
Service Level Management (dále SLM) je proces, na jehoţ základě organizace identifikuje a určuje
úroveň IT sluţby, která je potřeba k podpoře businessu a definuje mechanismus, kterým je moţné
úroveň sluţeb monitorovat tak, aby bylo moţné zajistit jejich dodrţování. V rámci procesu SLM jsou
typicky určeny Service Level Agreement (dále SLA), coţ jsou ujednání mezi poskytovatelem a
odběratelem sluţby, ve kterých je definováno, co přesně která sluţba znamená, co poskytuje a na jaké
úrovni je potřeba sluţbu udrţovat tak, aby ji mohl odběratel vyuţívat k účelům, ke kterým je určena.
[Sun2007]
Vedle stanovení úrovně SLA jsou určeny také úrovně Operational Level Agreement (OLA), které
definují vzájemné vztahy mezi interními jednotkami organizace, které se společně podílejí na zajištění
a poskytování jedné sluţby v rámci jedné SLA.
Součástí SLM je IT Service Continuity Management (dále ITSCM), který je procesem definovaným
konceptem ITIL a který podporuje souhrnný BCM, neboť jeho hlavním účelem je zajistit obnovení
nezbytné IT infrastruktury. [Galup2007] IT v dnešní době hraje nezbytnou roli v podpoře a naplňování
podnikových poţadavků. ITSCM je disciplína řízení IT sluţeb, která je procesně orientovaná a je často
spojována se standardy ITIL, ve kterých je podsekce věnovaná této problematice zaměřena zejména na
podporu sluţeb a na jejich dodání. Podle studie provedené společností Gartner [Potter2009] spadá
80% nákladů na infrastrukturu právě do těchto dvou oblastí.
Koncept BCM je s procesem SLM velmi úzce spjat. Zatímco SLM specifikuje konkrétní a měřitelnou
úroveň IT sluţby a definuje smlouvu SLA mezi poskytovatelem a odběratelem, BCM přebírá SLA
jako klíčový dokument, do kterého poskytuje vstupy. Pojato obráceně, SLM se musí stát nutnou
součástí BC plánů, ve kterých je na základě SLM specifikována obnova klíčových IT sluţeb a aplikací
v dohodnutých úrovních, které vyhovují zákazníkovi/odběrateli, a to do doby, neţ bude obnoven
běţný provoz společnosti. Přitom je důleţité si uvědomit, ţe není nezbytně nutné, aby všechny sluţby
byly okamţitě obnoveny na 100%, coţ by právě mělo být ukotveno v BC plánech.
1.5.1 DOBA OBNOVY A BOD OBNOVY
Mezi nejdůleţitější parametry SLA z hlediska BC plánů patří doba obnovy (RTO - Recovery Time
Objective) a bod obnovy (RPO - Recovery Point Objective) – viz Obr. 3. V následujícím textu jsou
popsány vedle RTO a RPO i další parametry týkající se času obnovy [Snedaker2007]:

Maximální tolerovatelná doba odstávky (MTD - Maximum Tolerable Downtime) - stanovuje
maximální dobu, po kterou je business ochoten tolerovat neexistenci nebo nedostupnost určité
funkce podniku. Pro kaţdou podnikovou funkci je definována samostatná maximální
tolerovatelná doba odstávky. Logicky klíčové funkce budou mít nejkratší tolerovatelnou dobu
odstávky. MTD je sloţeno ze dvou elementů, a to času obnovy a pracovního času obnovy.
𝑀𝑇𝐷 = 𝑅𝑇𝑂 + 𝑊𝑅𝑇


Čas obnovy (RTO - Recovery Time Objective) - čas, za který je moţné obnovit narušené
systémy a zdroje, jinými slovy je to systémový čas obnovy. Je součástí MTD. Pokud je
například MTD pro klíčový podnikový proces 3 dny, systémový čas obnovy můţe být 1 den.
Znamená to, ţe společnost musí obnovit funkcionalitu všech systémů potřebných pro běh
klíčového podnikového procesu během jednoho dne.
Pracovní čas obnovy (WRT - Work Recovery Time) - je druhým elementem tvořícím MTD.
Jestliţe MTD je 3 dny, RTO 1, tak WRT je 2 dny. Znamená to, ţe společnost má 2 dny na to,
aby zcela obnovila chod procesu za předpokladu, ţe jiţ běţí podpůrné systémy. V rámci WRT
-8/117-
jsou obnovovány a zajišťovány všechny vstupy pro proces, lidské zdroje, dokumenty
a legislativní zajištění apod.
Pracovní čas obnovy bývá bohuţel často přehlíţen, a to především ze strany IT oddělení.
Z pohledu IT je dostačující, aby byly znovu obnoveny aplikace, které proces podporují. Avšak
z pohledu businessu zde jsou dodatečné kroky, které musí být provedeny, aby bylo moţné
podnikový proces opět spustit.

Bod obnovy (RPO - Recovery Point Objective) - objem nebo rozsah ztracených dat, který je
společnost ochotna tolerovat z hlediska nezbytných podnikových systémů. Některé
společnosti zálohují data v reálném čase, některé v řádech hodin, dnů či týdnů. Od periody
zálohy dat se odvíjí také tolerovatelná ztráta dat. Jestliţe je záloha dat prováděna jednou
týdně, znamená to, ţe podnik je ochoten tolerovat aţ týdenní ztrátu dat.
Poţadavky zákazníka na RTO/RPO se v mnoha případech liší od moţností dodavatele. Moţných
řešení, jak dosáhnout konsensu při stanovování RTO/RPO nalezneme v běţné praxi hned několik
[Martanova2010]:

Provedení odborné analýzy dopadů (Business Impact Analysis) - analýza dopadu je proces
identifikace klíčových podnikových funkcí a ohodnocení dopadu a ztráty v případech, kdy je
dotčená podniková funkce nedostupná. V rámci této analýzy je třeba nejen ohodnotit dopad,
který by měla událost na chod podniku, ale také určit dobu výpadku podnikové funkce, která
jiţ ohroţuje samotnou existenci organizace.
Výsledkem analýzy dopadů je dle [Rittinghouse2005] hodnocení a seřazení všech klíčových i
podpůrných podnikových funkcí v pořadí odpovídající jejich nutnosti obnovy, a to na základě
předchozího kolektivního ohodnocení těchto funkcí v rámci společnosti.
Podle Business Continuity Institute [BCI2007] nebo [Snedaker2007] rozlišujeme 4 základní
účely analýzy dopadu:
obdrţet informace o nezbytných cílech organizace, jejich priority a dobu, za kterou by
bylo moţné obnovit běţný chod společnosti tak, aby stále mohla naplňovat cíle, které
jsou pro ni existenčně důleţité,
o získat rozhodnutí vedení společnosti o maximální tolerovatelné době odstávky pro
kaţdou podnikovou funkci,
o poskytnout relevantní informace, na základě kterých by bylo moţné sestavit/doporučit
strategii obnovy,
o načrtnout jak externí, tak interní závislosti mezi podnikovými funkcemi, které vedou k
naplnění podstatných podnikových cílů.
Stanovení RTO/RPO, které můţe být nabídnuto dodavatelem - jedná se o interní moţnosti
dodavatele, které je schopen zajistit.
Zainteresování obou stran do procesu vyjednávání - výstupem tohoto procesu by měla být také
dojednaná strategie obnovy podnikových funkcí.
o


Výsledky analýzy dopadu a ostatních metod dosaţení konsensu v procesu stanovení RTO/RPO
podnikových funkcí by se měly stát podkladem nejen pro BC plánování. [Rittinghouse2005]
Výsledkem je kompromis, který má jisté finanční aspekty a dopad jak na poskytovatele, tak na
zákazníka, neboť z finančního hlediska se vţdy jedná o rozloţení nákladů mezi obě strany. Část
investice plyne ze strany zákazníka a část je také nucen investovat poskytovatel do svého interního
BCM.
-9/117-
Časový úsek od
poslední zálohy
Recovery Point
Objective
Časový úsek do
obnovení systému
Narušující událost
Recovery Time
Objective
Obr. 3 - Grafické znázornění RPO a RTO (Zdroj: Autor)
1.6 ALTERNATIVNÍ PROSTŘEDÍ
V případě, ţe dojde k přerušení moţnosti přístupu k primárnímu prostředí, ať uţ z jakéhokoli důvodu,
potřebuje mít společnost k dispozici řešení, jak zajistit podnikovou činnost. Jedním z těchto řešení je
také moţnost vlastnit alternativní prostředí. V praxi rozeznáváme několik druhů alternativních
prostředí [Rittinghouse2005]:





Cold site – jedná se o prostředí, které odpovídá prostředí provoznímu, ale v tomto prostředí
není umístěno ţádné vybavení. Je připraveno na to, aby bylo veškeré vybavení do prostředí
teprve přesunuto po vzniku krizové situace. Na místě mohou být připraveny telefonní
přípojky, přípojky do elektrické sítě, připojení k internetu atd.
Hot site – jedná se o prostředí, které poskytuje prostor pro zaměstnance a je plně vybaveno
včetně zdrojů a infrastruktury tak, aby mohly být okamţitě obnoveny kritické podnikové
funkce.
Warm site – částečně zařízené prostředí typu hot site, kde však není umístěno tolik vybavení
jako v případě hot site. Podmínkou je, ţe data zde umístěná nesmí být příliš stará.
Mobile site – jedná se o prostředí, které je dočasné a je pouze částečně vybavené. Zpravidla
bývá umístěno nedaleko primárního prostředí, aby tak byl ušetřen čas zaměstnanců na přesun
do odlehlejšího prostředí.
Mirrored site – jedná se o zcela identické prostředí s prostředím primárním jak do vybavení,
tak do umístěných dat, tak do bezpečnostních opatření. Je ekvivalentem redundantního
prostředí, a je tak nejdraţší moţností z výše uvedených typů.
1.7 ÚPRAVA BCM VE STANDARDECH
Business Continuity Management podléhá současné právní úpravě, regulacím a je také ustanoven
v řadě standardů, a to jak na národní, tak na mezinárodní úrovni.
Z hlediska legislativní úpravy spadá Česká republika pod ustanovení Evropské unie, a to zejména pod
Evropský program ochrany kritické infrastruktury, který byl představen ve směrnicích EU a je zaloţen
na seznamu evropské kritické infrastruktury podle vstupů vloţených jednotlivými členskými státy.
Regulace BCM je v rámci Evropy implementována pouze ve finančním sektoru, zejména se jedná o
bankovní instituce a pojišťovny. V některých zemích se úprava týká také zdravotní péče a sektoru
jaderné energie. [Gilbert2010]
V oblasti standardů se setkáme s řadou úprav především ze strany Mezinárodní organizace pro
standardizaci a Britského institutu standardizace. Protoţe je pro území České republiky relevantní
-10/117-
zejména úprava ze strany organizace ISO, zaměříme se především na její standardy, které jsou
uvedené v následující podkapitole.
BCM se dotýkají také další standardy, mezi které patří ITIL (Continuity Management jako součást
knihy „Service Design“) a COBIT (P03, P09).
1.7.1 MEZINÁRODNÍ ORGANIZACE PRO STANDARDIZACI ISO
Mezinárodní organizace pro standardizaci ISO vydala jiţ několik standardů, které se nějakým
způsobem dotýkají Business Continuity organizace. Jeden ze standardů týkající se ICT je teprve
vyvíjen, zbývající tři standardy jsou seřazeny podle data vydání v textu níţe [ISO2010]:

ISO/IEC FCD 27031 – Information Technology – Security techniques – Guidelines for
ICT readiness for business continuity
Tento standard dosud nebyl vydán, nyní se nachází ve stavu konceptu. V budoucnu bude tento
standard definovat Business Continuity pro ICT, konkrétně bude navrhovat rámcovou
strukturu (metody a procesy) pro jakoukoli organizaci (soukromou, veřejnou…), identifikovat
relevantní aspekty pro zlepšení připravenosti ICT, a umoţnit tak organizacím změřit svou
připravenost na vznik narušujících událostí.

ISO/IEC 24762:2008 – Information technology – Security techniques – Guidelines for
information and communications technology disaster recovery services
Tento standard poskytuje návod na obnovu z krize v oblasti IT v kontextu BCM. Týká se
oblastí informační bezpečnosti a aspektů dostupnosti IT v době krize. Implementací standardu
organizace dosáhne větší pruţnosti své ICT infrastruktury podporující klíčové podnikové
činnosti.

ISO/PAS 22399:2007 - Societal Security – Guideline for incident preparedness and
operational continuity management
První mezinárodně uznávaný standard týkající se připravenosti organizace a řízení kontinuity
organizací jak ve veřejném, tak v soukromém sektoru. Tento dokument je zaloţen na best
practices pěti národních standardů z Austrálie, Izraele, Japonska, Velké Británie a Spojených
Států.

ISO/IEC 27002:2005 – Information Technology – Security techniques – Code of practice
for information security management
Tento standard slouţí jako doporučení informační bezpečnosti v několika oblastech. Kapitola
14 tohoto standardu se věnuje BCM a popisuje vztah mezi plánováním obnovy IT z krize,
BCM a Business Continuity plánováním, a to v rozsahu od analýzy a dokumentace aţ po
testování a školení plánů.
-11/117-
2 CHARAKTERISTIKA CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE
Cloud Computing se začal v prostředí internetu objevovat aţ v druhé polovině poslední dekády, přesto
si však našel širokou oblibu IT veřejnosti. Velmi rychle se stal často skloňovaným pojmem a setkáme
se s ním i v prostředí sociálních sítí, kde např. v síti Twitter se na Cloud computing prostřednicvím
článků odkazuje mnoho členů z řad odborné i „laické“ veřejnosti. Cílem této kapitoly je vymezit
definici Cloud Computingu a uvědomit si jeho základní charakteristiky. Zvláštní pozornost je potom
věnována také otázkám bezpečnosti a zabezpečení cloudových řešení.
Definici Cloud Computingu by bylo moţné vybírat z celé řady zdrojů. Protoţe však tento termín je do
jisté míry doposud sporný, znamená různé věci pro různé lidi a není zcela vymezeno, do jaké míry se
jedná o „reklamní trik“ a do jaké míry lze tento pojem povaţovat za „něco nového“, neexistuje ţádný
veřejně uznávaný orgán, který by poskytoval jedinou ověřenou definici. Zatímco někteří definují
Cloud Computing úzce jako poskytování virtuálních serverů prostřednictvím internetu, jiní vidí Cloud
Computing jako jakoukoli sluţbu poskytovanou mimo firewall společnosti. Pro účely vymezení pojmu
v této diplomové práci byla pouţita následující definice:
„Cloud Computing je:
1. Umístění a přístup k aplikacím a datům pomocí internetového prohlíţeče častěji, neţ pomocí
softwaru instalovaného na koncové stanici nebo na serveru.
2. Na internetu zaloţené sdílení informací, IT zdrojů a softwarových aplikací, které je poskytováno
koncovým stanicím a mobilním zařízením „na poţádání“.
3. Vyuţívání internetu pro přístup k webovým aplikacím, webovým sluţbám a IT infrastruktuře jako
ke sluţbě.“ [CC2010]
Na trhu Cloud Computingu se setkáme se jmény velkých hráčů jako je Amazon, Google či Microsoft,
stejně tak jako na něm najdeme mnoho menších společností. Všichni tito poskytovatelé svorně
nabízejí potenciálním zákazníkům sníţení nákladů a inovativní řešení. [Velte2010] Velkou otázkou
však zůstává, které aplikace je vhodné do cloudu převádět a jak velká jsou s tím spojena bezpečnostní
rizika.
Pojem cloud je také moţné chápat v různých rovinách. Podle některých definic (např. [Com2010]) je
cloud chápán jako síť, resp. internet, podle jiných autorů (např. [Info2010], [Wardley2010]) se pod
pojmem cloud rozumí elastické prostředí zdrojů poskytující sluţby několika odběratelům na určité
úrovni smluvené kvality.
Rozeznáváme tři základní typy cloudů (viz Obr. 4) [Wood2009]:



interní – soukromé cloudy provozované organizací samotnou,
externí – sluţby jsou poskytovány třetí stranou prostřednictvím sítě internet. V případě
externího cloudu zákazník musí často platit i za infrastrukturu, kterou nepouţívá,
hybridní – kombinace interního a externího přístupu ke cloudu.
V některých společnostech jsou vyuţívány hybridní cloudy, ve kterých jsou sluţby poskytovány
převáţně interně a externě poskytovaných sluţeb včetně infrastruktury je vyuţíváno pouze v případě,
kdy kapacita interní infrastruktury není dostačující nebo v případě, kdy se jedná o běh méně
rizikových sluţeb.
Ostatní modely cloudu se teprve vyvíjejí a pomalu začínají být vyuţívány, včetně modelu
vyuţívajícího infrastrukturu poskytovanou a udrţovanou externě, ale pouţívanou privátně jednou nebo
několika malými společnostmi. Takový model je některými instituty (např. National Institute of
-12/117-
Standards and Technology NIST v USA) či autory [Wood2009] [Prodelal2010] nazýván komunitním
cloudem.
Hybridní
cloud
Interní
cloud
Externí
služba
Externí
Cloud
Obr. 4 - Typy Cloud Computingu (Zdroj: Autor)
Vedle této klasifikace se lze setkat také se třemi hlavními modely, ve kterých jsou cloudové sluţby
poskytovány. Tyto modely poskytování sluţeb jsou následující [Catteddu2009] [Rittinghouse2010]:



Software as a Service (SaaS) – jedná se o software licencovaný třetí stranou, který je
zákazníkovi dostupný v případě potřeby. Většinou jsou tyto sluţby poskytovány
prostřednictvím sítě internet, neboť jsou snadno vzdáleně konfigurovatelné. Mezi příklady
takto poskytovaných sluţeb patří software pro zpracování textu, tabulkový procesor (orig.
spreadsheet), CRM a sluţby řízení webového obsahu (Salesforce CRM, Google Docs atd.).
Podle společnosti Gartner [Potter2009] bude v roce 2010 poskytováno 30% nového software
právě jako SaaS.
Platform as a Service (PaaS) – umoţňuje zákazníkům vyvíjet nové aplikace za vyuţití API,
které je umístěno a konfigurováno vzdáleně. Platforma nabízí vyuţití zabudovaných nástrojů
pro vývoj aplikací (včetně návrhu a testování) či konfigurační management. Příklady
poskytovatelů PaaS jsou: Microsoft Azure, Force a Google App. V některých případech je
forma PaaS označována jako tzv. „cloudware“.
Infrastructure as a Service (IaaS) – poskytuje virtuální prostor a ostatní hardware a operační
systémy, které mohou být řízeny prostřednictvím API sluţeb. Mezi poskytovatele patří
Amazon EC2 a S3 (Storage-as-a-Service), Terremark Enterprise Cloud, Windows Live
Skydrive nebo Rackspace Cloud. Sluţba je ve většině případů účtována na základě mnoţství
vyuţití zdrojů, a odráţí tak úroveň aktivity zákazníka.
S rostoucí úspěšností adopce konceptu SaaS zákazníky se objevila myšlenka nabízet tzv. IT-as-aService [Rittinghouse2010], coţ je koncept, který přenáší model sluţeb na vyšší úroveň, a to přímo do
IT infrastruktury zákazníka. Moderní IT organizace by tak existovala jako samostatný celek a stala by
se strategičtější v operativních rozhodnutích. Mnoho organizací v dnešní době převádí svá IT oddělení
do samostatných center, která vystupují ve vztahu ke společnosti jako externí subjekt.
To, jestli se koncept IT-as-a-Service stane budoucností také velkých organizací, ukáţe pouze čas.
Nabízí však benefity, mezi které patří jak výhody finanční, tak výhody rozšiřitelnosti, flexibility či
spolehlivosti a které jsou blíţe popsány v následující kapitole.
-13/117-
V dnešní době se také setkáme s pojmem konceptu Anything-as-a-Service (XaaS)
([Rittinghouse2010], [Karnam2010]), který je také jistou podmnoţinou Cloud Computingu a který
zahrnuje vyuţívání znovupouţitelných softwarových komponent pomocí internetové sítě. Vzrůst
zájmu o všechny koncepty typu "as-a-service" je dán především jejich vysokou dostupností, neboť
registrační proces je limitován pouze vlastnictvím kreditní karty. I z tohoto důvodu byl koncept
adoptován nejprve malými a středními podniky, u velkých společností se teprve pomalu hlásí o slovo.
Přehled konceptu Cloud Computing tak, jak s ním bude pracováno v rámci této diplomové práce je
znázorněn na Obr. 5 níţe. Jednotlivé kategorie konceptu Cloud Computing jsou popsány
v následujícím textu.
Obr. 5 - Přehled konceptu Cloud Computing (Zdroj: Autor)
-14/117-
2.1 POTENCIÁL CLOUD COMPUTINGU V ŘÍZENÍ ORGANIZACE
I kdyţ Cloud Computing nabízí řadu výhod, o kterých se podrobněji zmíníme později, je důleţité si
uvědomit, ţe ne všechny aplikace je vhodné do cloudu přesouvat. S rostoucím zájmem o Cloud
Computing ze strany poskytovatelů roste i poptávka ze strany zákazníků, a tak často dochází
k situacím, kdy se společnost rozhodne přesunout určitou aplikaci do cloudu, aniţ by předem zváţila
soulad s celkovou strategií podniku a investiční návratnost projektu (ROI).
Z průzkumu prováděného ve Spojených státech v březnu 2010 [Fogarty2010] vyplývá, ţe nejčastějším
důvodem, proč se společnosti rozhodují pro adopci Cloud Computingu, je pruţnost běhu podnikových
procesů (49% dotázaných), teprve na druhém místě bylo uváděno zvýšení účinnosti nákladů (46%) a
na místě třetím uvolnění IT zdrojů za účelem zaměření se na inovaci (22%).
Přitom běţným poţadavkem při přesunu aplikace do cloudu je její integrace s ostatními aplikacemi ve
společnosti pouţívaných. Tato integrace můţe být natolik náročná, ţe předpokládaná úspora nákladů
z přesunu do cloudu můţe být převýšena dodatečnými náklady na integraci aplikace. [Velte2010]
uvádí, ţe k podobné situaci dochází také v případě, kdy je aplikace navázána na databázi, která je
udrţována lokálně. V takovém případě je rovněţ lepší vést aplikaci interně do té doby, neţ je moţné
přemístit do cloudu celou infrastrukturu včetně databáze.
Základním rozhodovacím kritériem pro to, kterou aplikaci ponechat interně a kterou přesunout do
cloudu, bývá povaha dat, která jsou v rámci aplikace udrţována. Podle některých odhadů (např.
[Fogarty2010], [Velte2010]) obsahuje pouze ¼ podnikových aplikací kritická data nebo funkce, které
by bylo vhodnější ponechat v rámci podniku, neboť některé aplikace nejsou schopny zabezpečené
komunikace v rámci sítě Internet.
Z hlediska přínosů Cloud Computingu pro tradiční způsoby udrţení Business Continuity či plánu
obnovy můţeme jmenovat například sníţení pravděpodobnosti výpadku e-mailové sluţby v případě,
kdy dojde k neočekávané události v rámci organizace. Posílání zpráv by bylo v tomto případě nadále
umoţněno a doručení e-mailů adresátovi zaručeno. Mezi další výhody dle [Rittinghouse2010] patří
také to, ţe potenciální výpadky systému mohou být pro společnost prakticky nepostřehnutelné nebo ţe
společnost můţe nadále vyuţívat telekomunikačních sluţeb i během jejich výpadku či vyuţívat sluţeb
bezdrátového připojení, a moci tak nadále odesílat a přijímat e-mailovou poštu i v případech, ţe
lokální e-mailový systém, datové centrum, síť či zaměstnanci jsou nedostupní.
2.2 BENEFITY PLYNOUCÍ Z ADOPCE CLOUD COMPUTINGU
Poskytovatelé Cloud Computingu, ať uţ se jedná o velké firmy typu Amazon, Google či Microsoft,
nebo firmy malé, se shodují na následujících benefitech, které Cloud Computing společnostem přináší
([Marks2010], [Rittinghouse2010], [Velte2010]):



Sníţení či optimalizace nákladů – Cloud Computing nabízí způsob, jak sníţit náklady na IT
infrastrukturu, a to díky tomu, ţe umoţňuje společnosti vyhnout se některým kapitálovým
nákladům, vyuţít lépe kapacitu a sníţit provozní náklady díky redukci interních IT zdrojů.
Moţnost přístupu k podnikovým datům z několika lokalit - to je dáno základním principem
Cloud Computingu, kdy jsou sluţby poskytovány zákazníkovi prostřednictvím internetu, a
zaměstnanci se tak nemusí nacházet se v určité lokalitě, aby mohli přistupovat k podnikovým
datům.
Lepší vyuţití IT infrastruktury – díky moţnosti virtualizace IT zdrojů je moţné zlepšit vyuţití
serverů, které v některých případech dosahuje pouze 10%, zatímco za vyuţití přístupů Cloud
Computingu by toto vyuţití dosahovalo 50 – 65% nebo i více [Marks2010].
-15/117-







Rozšiřitelnost IT infrastruktury – v případech, kdy v podniku vznikne náhlá potřeba rozšířit
stávající IT infrastrukturu, můţe Cloud Computing pomoci urychlit proces „dodání“ IT zdroje,
neboť namísto nákupu, instalace a konfigurace nového zařízení stačí pouze dokoupit
dodatečnou operační paměť nebo úloţiště u poskytovatele.
Lepší vyuţití aktiv – aktivy, která mohou být díky Cloud Computingu lépe vyuţívána, se
rozumí lidé a znalosti. Primárním principem tohoto konceptu je outsourcing IT zdrojů, mezi
které patří infrastruktura, middleware i aplikace, díky čemuţ společnost dosáhne uvolnění
lidských zdrojů pro svůj vlastní business, ve kterém se specializuje.
Uvolnění interních zdrojů – přesunem dat, která nejsou kritická pro naplňování podnikových
cílů, do úloţiště třetí strany dosáhne podnik toho, ţe jeho IT oddělení bude mít více prostoru
na řešení důleţitých a kritických úkolů, které přímo ovlivňují chod podniku. Mimoto podle
[Velte2010] podnik také přesune část odpovědnosti za případný výpadek sítě na
poskytovatele, coţ také sniţuje zatíţení interních zdrojů.
Model platby pay-as-you-go – s výše uvedeným benefitem Cloud Computingu úzce souvisí
i způsob platby za vyuţívané IT zdroje, neboť smyslem tohoto konceptu je pouţívat IT zdroje
pouze v případě potřeby, tedy „on demand“, a na základě toho také za tyto zdroje platit. I kdyţ
je tento model preferovaný dle [Rittinghouse2010] především ze strany uţivatele, některé
nabídky Cloud Computingu vyuţívají model zaloţený na principu předplatného.
Fixní náklady se stávají variabilními – vyuţitím pay-as-you-go modelu se z původně fixních
nákladů na IT zdroje stávají náklady variabilní, neboť platby probíhají pouze na základě
vyuţití zdrojů. Tento fakt významně ovlivňuje financování podniku, a je tak zajímavý nejen
pro IT manaţery, ale také pro ostatní vedoucí pracovníky.
Zkrácení doby uvedení na trh – díky potenciálu Cloud Computingu by společnosti mohly
dosahovat výrazného zkrácení doby uvedení produktu na trh, coţ by mělo zásadní vliv na
obchodní výsledky podniku.
Podporu podniků začínajících a inovativních – díky konceptu vyuţívání IT infrastruktury
pouze v případě potřeby je umoţněno také těmto typům podniků rychle nastartovat svůj model
podnikání, a to na základě úspory na vstupních pořizovacích nákladech za IT zdroje.
2.3 HROZBY CLOUD COMPUTINGU Z HLEDISKA BEZPEČNOSTI
Úvodem této kapitoly bychom měli uvést, ţe je důleţité si uvědomit, ţe Cloud Computing není jen
uskupením výhod a benefitů, o kterých se lze dočíst v kaţdé broţurce cloudového poskytovatele, ale
společně s výhodami skýtá v sobě vyuţití Cloud Computingu také jistá rizika. Ani na ta však není
moţné pohlíţet jednostranně, je důleţité zváţit, zda rizika Cloud Computingu jsou pro firmu přijatelná
ve srovnání s řešeními tradičními, zejména aplikacemi provozovanými na straně zákazníka, která také
nejsou zcela bezriziková.
Riziko bezpečnosti je s Cloud Computingem často spojováno, a to především s cloudy ve formě
externí. Hlavním důvodem je obava, ţe pokud společnost umístí svá citlivá proprietární data do
cloudu, není jiţ za jejich ochranu zodpovědná pouze vlastnická firma, ale také třetí strana, která
poskytuje vyuţívané IT sluţby. Tato hrozba představuje na jedné straně zvýšené riziko hackerských
útoků, na straně druhé dochází také k chybám způsobeným lidským faktorem. Jako příklad lze uvést
incident z roku 2007, kdy britská vláda chybně umístila 25 milionů záznamů daňových poplatníků,
které se tak staly přístupné třetí straně. [Velte2010]
Bezpečnost cloudových sluţeb se v posledních letech stává samostatnou součástí počítačové
bezpečnosti, síťového zabezpečení a v širším kontextu také informační bezpečnosti. Mezi cílové
oblasti cloudové bezpečnosti patří odpovědnosti na straně poskytovatele (zabezpečení infrastruktury,
-16/117-
dat a aplikací) a odpovědnosti na straně zákazníka (zákazník se musí ujistit, zda poskytovatel provedl
opatření zabezpečující jeho data).
Částečným řešením potenciálního rizika uchovávání citlivých dat v prostředcích třetí strany je vývoj
vlastní aplikace, a to buď vlastními silami, nebo vývojem aplikace na míru. K podobné situaci dochází
také v případě, kdy společnost hledá specifickou aplikaci, která není na trhu dostupná. Tyto aplikace
a sluţby takto poskytované jsou zpravidla zaloţeny na tzv. LAMP konceptu, coţ je soubor relativně
jednoduchých a výkonných technologií, které jsou však poskytovány ve formě open-source. Zkratka
samotná vychází z jednotlivých částí konceptu uvedených níţe [Dougherty2001]:




Linux – open-source operační systém
Apache – open-source webový server
MySQL – open-source relační databázový systém pro webové servery
PHP – programovací jazyk
Z výše uvedeného je zřejmé, ţe aplikace zaloţené na LAMP jsou dostupnější alternativou k mnohým
komerčním balíčkům. Problémem takovýchto řešení je však jejich rozšiřitelnost. Omezení vycházejí
z počtu moţných vláken spojení k Apache serveru, maximální velikosti relačních tabulek v databázi
MySQL apod. [Velte2010] Takováto omezení v Cloud Computingu neexistují, zjednodušeně se dá
říci, ţe rozšíření znamená pouze dodání dalších a dalších serverů, čímţ dojde k rozšíření současné
kapacity.
Domény cloudové bezpečnosti můţeme rozdělit do několika kategorií. Zatímco Gartner
[Brodkin2008] definuje 7 oblastí zájmu, Forrester [Wang2009] 3 oblasti a Cloud Security Alliance
[CSA2009] 15 oblastí, můţeme tyto oblasti rozdělit na část bezpečnosti (do které spadají především
otázky ochrany dat a bezpečnosti aplikací) a část souladu s podnikem, kam mimo jiné řadíme i
Business Continuity.
Následující text je podrobněji zaměřen na vybrané konkrétní hrozby cloudových sluţeb z oblasti
soukromí a bezpečnosti.
2.3.1 ZNEUŽITÍ A NEZÁKONNÉ POUŽITÍ CLOUD COMPUTINGU
Z průzkumu provedeného agenturou IDC [Velte2010], kdy bylo dotazováno 244 výkonných
pracovníků IT, vyplývá, ţe 74,5% dotázaných je v otázce Cloud Computingu znepokojeno aspekty
bezpečnosti. Teprve po otázkách bezpečnosti se na ţebříčku ukazuje výkonnost, dostupnost, moţnost
integrace s ostatními aplikacemi, moţnost customizace, cena, regulace či nedostatek poskytovatelů
Cloud Computingu na trhu. Grafické znázornění tohoto průzkumu je zobrazeno na Obr. 6.
S rostoucím vývojem technologií roste i vynalézavost kriminálních ţivlů, kteří vyuţívají
technologický pokrok ku svému prospěchu, a stávají se tak těţko odhalitelnými. Poskytovatelé Cloud
Computingu se stávají častou obětí kybernetických útoků, a to částečně z důvodu povahy procesu
registrace, která je anonymní, a ztěţuje tak schopnost poskytovatele vypátrat podvody. Proces
registrace ve většině případů vyţaduje pouze vlastnictví platné platební karty, které postačuje k tomu,
aby se registrující subjekt mohl stát uţivatelem sluţeb cloudu.
Těmito útoky byli nejvíce postiţeni poskytovatelé platformy (PaaS), ale v poslední době se terčem
útoků stávají také poskytovatelé infrastruktury (IaaS). V současné době jsou nejčastějšími útoky
spamy či škodlivý kód, v budoucnosti se očekává prolamování hesel a klíčů, stejně tak jako další typy
útoků. [CSA2010b]
-17/117-
Bezpečnost
Výkonnost
Dostupnost
Integrace s in-house řešením
Možnost customizace
Cena
Náklady na přesun zpět do in-house
Regulace
Nedostatek poskytovatelů
0
10
20
30
40
50
60
70
80
Obr. 6 - Pořadí obav z adopce Cloud Computing řešení (Zdroj: [Velte2010])
Na druhou stranu je však logické brát v úvahu také to, ţe řešení jako sluţba je mnohdy lépe
zabezpečeno neţ řešení provozované na straně klienta. [Houser2010] Dodavatel takovýchto řešení
totiţ ve vlastním zájmu udrţuje svá řešení v datovém centru, které je zabezpečeno jak fyzicky, tak
virtuálně, a to na lepší úrovni, neţ si můţe dovolit běţná společnost.
2.3.2 OTÁZKY ZABEZPEČENÍ ROZHRANÍ
I kdyţ se lze setkat s obecným tvrzením, ţe největší hrozbu pro data organizace představují její vlastní
zaměstnanci, a proto předání dat neutrální třetí straně můţe toto riziko sniţovat, stále v této oblasti
vyvstávají otázky, zda je rozhraní a poskytovaná API dostatečně zabezpečeno. Skutečností však je, ţe
samotná rozhraní jsou na straně poskytovatele zabezpečena kvalitně, důleţité je ale také to, jak se
k vyuţívání cloudových sluţeb postaví sám zákazník. [CSA2010b] Tyto bezpečnostní aspekty se
týkají především zajištění, vyuţívání, řízení, orchestrace či monitorování odebíraných sluţeb.
Zabezpečení rozhraní na straně poskytovatele můţe zahrnovat celou škálu bezpečnostních opatření,
jako jsou autentizační procesy, řízení přístupu, šifrování nebo monitorování prováděných činností. Jak
jiţ bylo uvedeno výše, je třeba mít na paměti, ţe rizika nejsou spojena pouze se škodlivými útoky
subjektů zvenčí, ale také s neúmyslnými činy porušujícími politiku organizace.
Do této kategorie bezpečnostních otázek také spadají podle [CSA2010b] nové aplikace, které jsou na
existujícím rozhraní vybudovány, a to jak zákazníkem, tak třetí stranou. Zpravidla se jedná o
nadstavby existujících aplikací, které dodávají potřebnou funkcionalitu vyţadovanou koncovými
uţivateli či managementem společnosti.
2.3.3 SDÍLENÍ INFRASTRUKTURY
S konceptem sdílení technologie, jako jsou například diskové prostory, operační paměť a další
elementy, vyvstává otázka zvýšeného rizika útoků a přístupu k důvěrným datům jiným subjektem,
neboť tyto elementy infrastruktury nejsou primárně pro dělení na části určeny. Samotní poskytovatelé
Cloud Computing řešení nabízejí sluţby rozšiřitelným způsobem, coţ představuje sdílení
infrastruktury s ostatními odběrateli. V mnoha případech nejsou komponenty tvořící sdílenou
infrastrukturu (operační paměť, grafický procesor atd.) navrţeny tak, aby umoţňovaly oddělení
v rámci sdílené architektury. Toho si jsou útočníci dobře vědomi a důsledkem toho je jejich zvýšený
zájem o získání neoprávněného přístupu k datům.
-18/117-
Pro překonání tohoto nedostatku zprostředkovává VMM přístup hostujícímu operačnímu systému
k fyzické infrastruktuře. Tím se sniţuje pravděpodobnost útoku, neboť je obecně těţší získat přístup
tímto způsobem neţ pomocí běţného operačního systému. [Catteddu2009] Mimoto na úrovni
virtualizační vrstvy probíhá monitoring bezpečnostních událostí. I v tomto případě je však moţné, aby
operační systém získal nepřiměřenou úroveň přístupu, a mohl tak ovlivňovat platformu, na níţ je
postaven. [CSA2010b] Bezpečnostní opatření a monitoring by však měly tato rizika eliminovat.
2.3.4 ZTRÁTA NEBO ÚNIK DAT
Ztráta dat je pochopitelně velkou hrozbou pro kaţdou společnost. Dá se říci, ţe v otázce, zda Cloud
Computing řešení implementovat či nikoli, stojí za všemi ostatními aspekty rizik bezpečnostní povahy
obava z úniku dat. Riziko ztráty kontroly nad daty je prohloubeno v případech, kdy se jedná o násobný
přenos dat, např. mezi několika spojenými cloudy. Na druhou stranu však někteří poskytovatelé
cloudových řešení poskytují také informace o tom, jakým způsobem s daty zákazníka nakládají.
Někteří z nich podle [Catteddu2009] také nabízejí certifikaci zpracovávání dat a bezpečnostních
činností, jakou je např. certifikace SAS70.
Přitom tato hrozba nespočívá pouze v riziku, ţe by se k citlivým datům mohla dostat neoprávněná
osoba. Způsobů, jak kompromitovat uţivatelská data, existuje pochopitelně několik. Nejběţnějším
způsobem je vymazání dat nebo nahrazení dat původních bez předchozí zálohy. Dalšími příklady
mohou být dle [CSA2010b] např. vymazání záznamu z širšího kontextu či ztráta šifrovacího klíče,
které mohou ústit v neobnovitelnou ztrátu.
Na druhou stranu Cloud Computing řešení můţe pomoci minimalizovat riziko pouţití nespolehlivého
média, na kterém by data mohla být uchována. Díky diskovým kapacitám a zálohám prováděným
poskytovatelem jsou data zákazníka z tohoto ohledu mnohdy ve větším bezpečí, neţ by byla v případě
uloţení na straně zákazníka.
Rizika ztráty nebo úniku dat často vyplývají z nedostatečného uvědomění zákazníka o bezpečnostním
monitoringu, a to zejména monitorování autentizace, autorizace a účtování (AAA), kdy jsou na
jednotlivých síťových prvcích monitorovány a zaznamenávány události potenciálně vedoucí
k narušení bezpečnosti. Toto monitorování umoţňuje seskupovat jednotlivé události do incidentů
a tyto incidenty následně na základě předem stanovených pravidel vyhodnocovat.
2.3.5 OCHRANA UŽIVATELSKÝCH ÚČTŮ
Útoky prostřednictvím uţivatelských účtů zůstávají stále nejdůleţitější hrozbou, která se pohybuje na
předních pozicích ţebříčku priorit kaţdé společnosti. Je totiţ zřejmé, ţe s odcizenými přihlašovacími
údaji se můţe útočník v systému pohybovat takřka bez povšimnutí, čehoţ můţe vyuţívat k získání
citlivých informací pod odcizenou identitou, sledování prováděných činností a transakcí či směrování
na nelegitimní stránky. [CSA2010b] Společnosti by si měly techniky tohoto typu dobře uvědomovat a
implementovat strategie obrany proti takovým útokům.
Problémem zůstává skutečnost, ţe cloudové sluţby jsou hojně vyuţívány spíše menšími společnostmi,
a to především z důvodu vysoké dostupnosti jak sluţeb, tak samotného registračního procesu, zatímco
organizace většího typu cloudové sluţby doposud často nevyuţívají. Podle [Rittinghouse2010]
většinou tyto malé společnosti postrádají dostatečnou bezpečnostní politiku, a proto se i z tohoto
důvodu cloudové sluţby stávají častým terčem útoku.
Co do odpovědi na útoky ze strany nejrůznějších škodlivých software bývá však cloudové řešení spíše
výhodou, neboť společnosti poskytující sluţby jsou díky včasné detekci nového vývoje v oblasti
škodlivého softwaru schopny implementovat efektivnější a účinnější prvky, jak se proti těmto útokům
zabezpečit. [Catteddu2009] uvádí, ţe výhodou můţe být také to, ţe velcí poskytovatelé cloudových
-19/117-
sluţeb si mohou dovolit mít v řadách pracovníků odborníky v nejrůznějších oblastech bezpečnosti, coţ
u mnohých malých společností bohuţel není moţné.
2.4 ZRANITELNOSTI CLOUD COMPUTINGU
Vedle rizik souvisejících s adopcí konceptu Cloud Computingu se setkáme také s nejrůznějšími
případy zranitelnosti, které buď s Cloud Computingem přímo souvisejí nebo se jedná o obecné
zranitelnosti z hlediska informační bezpečnosti. V následujícím textu jsou v obrysech načrtnuty
některé z nich [Catteddu2009]:






Zranitelnost AAA – tím je myšlen nedostatečný způsob autentizace, autorizace a účtování na
prostředcích v síti (servery, switche, routery apod.), který by mohl potenciálně umoţnit
neautorizovaný přístup pomocí:
o nezabezpečeného úloţiště přihlašovacích údajů pro sluţby cloudu,
o nedostatečného počtu uţivatelských rolí,
o přihlašovacích údajů uloţených na přechodném zařízení.
Zranitelnost procesu získávání zákazníků – jak jiţ bylo řečeno výše, proces registrace pro
vyuţívání cloudových sluţeb je velmi přístupný takřka bez ţádných omezení, avšak do jisté
míry nebezpečný. A to především z následujících důvodů:
o zákazník nemá kontrolu nad procesem získávání dalších zákazníků,
o identita zákazníka není při registraci náleţitě ověřována,
o jsou vytvářeny nesynchronizované kopie identifikačních dat uţivatele.
Pozbytí izolace zdrojů – díky sdílení zdrojů mezi několika zákazníky je moţné, ţe pouţití
zdroje jedním zákazníkem můţe ovlivnit zdroj druhého zákazníka:
o IaaS cloudové infrastruktury většinou závisí na návrhu architektury, kde jsou fyzické
zdroje sdíleny několika virtuálními stroji, a tedy i několika zákazníky,
o zranitelnost na úrovni bezpečnosti virtuálního stroje můţe vést k neautorizovanému
přístupu ke sdíleným zdrojům.
Nemoţnost zpracovávat data v šifrované podobě – zašifrovat data v úloţišti nepatří
k obtíţným záleţitostem, avšak navzdory nedávnému vývoji v homomorfním šifrování se
nepředpokládá, ţe by bylo moţné data v šifrované podobě také zpracovávat. Podle
[Cooney2009] bylo však odhadnuto, ţe v případě pouţití šifrovaných klíčových slov při
vyhledávání ve vyhledávači Google by byl potřebný čas zpracování násoben trilionkrát. Autor
[Schneier2009] k tomuto faktu uvádí, ţe podle Mooreova zákona bude trvat dalších 40 let, neţ
se vyhledávání pomocí šifrovaných klíčových slov stane stejně efektivní jako současné
vyhledávání.
Nepřesné modelování pouţitých zdrojů – ačkoli většina poskytovatelů zákazníkům umoţňuje
rezervovat pro sebe potřebné zdroje, algoritmus přidělování zdrojů můţe snadno selhat
z následujících důvodů:
o nepřesné modelování vyuţití zdrojů, které můţe vést k přečerpání či nedostatku
zdrojů. Mezi nejznámější algoritmy přiřazování zdrojů patří Token Bucket, Fair
Queuing a Class-Based Queuing. [Catteddu2009]
o selhání algoritmu z důvodu neočekávaných událostí nebo z důvodu nepřesné
klasifikace přiřazovaných zdrojů.
Mezi zranitelnosti, které nejsou typické pouze pro Cloud Computing patří mimo jiné také
nedostatek povědomí o bezpečnostních aspektech nebo nejasně definované role
a odpovědnosti. Ačkoli tyto zranitelnosti nejsou spojeny pouze s vyuţíváním cloudových
sluţeb, měly by být pečlivě zváţeny před rozhodnutím vyuţívat řešení Cloud Computingu.
-20/117-
2.5 IDENTITY & ACCESS MANAGEMENT VE VAZBĚ NA CLOUD COMPUTING
Identity & Access Management (dále IAM) patří dnes mezi největší výzvy, kterým musí IT čelit.
Ačkoli je moţné, aby společnost začala vyuţívat cloudových sluţeb bez implementace systému pro
řízení přístupů, z dlouhodobého hlediska je nutné tuto strategii do cloudových sluţeb zahrnout.
Příchod cloudových sluţeb zcela změnil podstatu řízení identit. Doposud byla řešení pro řízení identity
navrţena pro řízené a statické prostředí uvnitř společnosti. Dle [Rittinghouse2010] v rámci cloudu
nyní jiţ nepostačí řízení identit orientované na uţivatele, ale poskytovatelé cloudových sluţeb jsou
nuceni zhodnotit nové modely a řídící procesy IAM tak, aby poskytovali důvěru zákazníkům napříč
cloudem a také v organizaci samotné.
Následujícím text je zaměřen především na základní funkce IAM:




nabytí/pozbytí identity,
autentizace,
autorizace a správa uţivatelských účtů,
podpora souladu.
Rychlý vývoj konceptu SaaS předstihl vývoj standardů. Např. standard SPML (Service Provisioning
Markup Language), coţ je rámec zaloţený na XML pro výměnu informací o uţivatelích, zdrojích či
sluţbách mezi organizacemi, nebyl jiţ 3 – 4 roky aktualizován. [CSA2010a] Mezitím však s rychlým
vývojem konceptů SaaS vzniklo několik odlišných způsobů, jak získávat a spravovat uţivatelské účty.
V mnoha případech proto poskytovatelé cloudových řešení zvolili raději variantu neinvestovat do
vývoje dále, dokud se neobjeví přesně definované standardy tuto problematiku upravující.
Uţivatelé cloudových sluţeb by podle [CSA2010a] měli pro naplnění poţadavků na získávání
uţivatelských účtů upravit nebo rozšířit svá autoritativní úloţiště dat tak, aby zahrnuli své aplikace
a procesy do cloudu.
Autentizace uţivatel je další výzvou pro organizace, které se rozhodnou vyuţívat cloudových sluţeb.
Autentizace probíhá prostřednictvím přihlašovacích údajů, digitálních podpisových certifikátů apod.
Zejména společnosti, které vyuţívají k autentizaci především přihlašovací jméno a heslo by měly
zváţit následující aspekty:




hesla by měla být chráněna a komunikace by měla být zabezpečena,
je-li pro více sluţeb v rámci jednoho cloudu pouţíváno jedno heslo, je velmi pravděpodobné,
ţe v případě útoku a prolomení hesla získá útočník přístup do několika cloudových sluţeb
zároveň,
hesla by měla dodrţovat základní pravidla pro sestavení hesel, aby nebyla snadno
prolomitelná slovníkovou metodou,
vyuţívané sluţby jsou vystaveny hrozbě phishingu.
Z těchto a dalších uvedených důvodů je dobré zváţit, zda určitá aplikace nevyţaduje silnější
autentizační mechanismy, kterými jsou například jednorázová hesla (One-time password - OTP)
zaslaná např. na e-mailovou adresu nebo mobilní telefon nebo digitální podpisové a šifrovací
certifikáty. Silnější způsoby autentizace jsou dnes jiţ častěji vyuţívány především většími
společnostmi (např. u bankovních institucí je silná autentizace uţivatel nezbytností), problémem však
zůstává skutečnost, ţe daná metoda autentizace nemusí být kompatibilní s řešením poskytovatele
cloudových sluţeb.
Řízení přístupu a správa uţivatelských účtů/profilů je náročnější v rámci cloudu, neboť informační
zdroje mohou být umístěny na jiném místě neţ je umístěna samotná sluţba, která je vyuţívá. Pro tyto
účely je důleţité identifikovat důvěryhodný zdroj a zabezpečenou komunikaci, pomocí které mohou
-21/117-
být informace do cloudu přenášeny. Pro zákazníka je důleţité, aby cloud byl schopen zajistit
následující funkcionalitu [CSA2010a]:






řízení přístupu na základě politiky stanovené zákazníkem,
řízení přístupu k datům jednotlivých uţivatelů a zajištění jejich oddělení od ostatních
zákazníků v prostředí sdíleném více uţivateli,
udrţovat uţivatelské informace a dodrţovat politiku řízení přístupu; v některých případech je
také vyţadováno, aby řešení uţivatelům umoţňovalo specifikovat externí entity, se kterými by
měla být sdílena uţivatelská data,
poskytnout dodatečné notifikace o vytvořených/smazaných účtech a přidělených právech tak,
aby bylo zabráněno vzniku podvodných účtů nebo účtů s vyšší úrovní oprávnění, neţ jaká je
skutečně potřeba,
poskytnout auditní logy činnosti v rámci prostředí jednotlivého zákazníka, a to včetně řízení
identit,
poskytnout prostředky pro určení odpovědnosti v případě problémů, které mohou nastat.
V současné době neexistuje ţádný standard, který by definoval podobu auditních logů, a tak musí
poskytovatel sluţeb a zákazník společně pracovat na definování podoby konkrétního záznamu pro
dané účely, na zabezpečení důvěrnosti, integrity a dostupnosti této informace. V případě cloudových
sluţeb je samozřejmě opět nezbytné zajistit, aby přístup jednoho zákazníka k logům neposkytoval
informace také o jiném zákazníkovi.
2.6 NÁVRH BEZPEČNOSTNÍCH OPATŘENÍ PRO ADOPCI CLOUD COMPUTINGU
SaaS v dnešní době neposkytuje dostatečně velkou podporu řízení identit. Dá se však očekávat, ţe
s rostoucím zájmem o SaaS, IaaS a PaaS se zvýší adopce standardů umoţňujících snazší řízení
uţivatelských profilů, o kterých se zmíníme v této podkapitole.
Existuje několik modelů pro řízení přístupu. V zásadě však platí, ţe model řízení přístupu, který
vyhovuje podmínkám společnosti v prostředí mimo cloud, bude také vhodný pro vyuţití v rámci
cloudu. Pro sluţby zpracování transakcí je často vyuţíván model RBAC (Role Based Access Control),
coţ je koncept omezení přístupu do systému pouze autorizovaným uţivatelům. Podle [CSA2010a]
bývá tento model často doplňován o další principy, mezi které patří například striktní oddělení
kořenového uţivatele od ostatních uţivatelů, a zabránění tak existenci uţivatelských účtů s většími
pravomocemi, neţ které jsou ve skutečnosti potřebné, nebo také bývá doplněn o politiky oddělení dat,
jako jsou SQL pohledy implementované na úrovni databáze.
Autentizace, která probíhá prostřednictvím tzv. single sign-on (SSO), můţe být dvojího druhu. Prvním
typem je SSO zaměřené na uţivatele. Takovým modelem je například OpenID, které umoţňuje
uţivatelům vybrat si způsob autentizace. Tento model je vhodný v případech, kdy je v rámci řízení
přístupů akceptovatelné, aby uţivatel vystupoval pod svým pseudonymem. V jiných případech však
tato autentizace nestačí a politikou řízení přístupů je vyţadováno, aby bylo vţdy ověřeno, kým
uţivatel skutečně je. V takových situacích je moţné vyuţít modely SSO, jako je například SAML,
který umoţňuje poskytovateli cloudového řešení nebo zákazníkovi zvolit povolené způsoby
autentizace, čímţ je zajištěna vyšší kvalita bezpečnosti v řízení přístupů.
SAML je zaloţen na několika existujících standardech, jako je SOAP, HTTP nebo XML a jak ve verzi
1.1, tak ve verzi 2.0 vyuţívá digitálního podpisu pro autentizaci a udrţení integrity zpráv. V pozdější
verzi standardu SAML je umoţněno také XML šifrování. [Rittinghouse2010]
Jsou-li cloudové sluţby vyuţívány společnostmi, je pravděpodobné, ţe politika řízení přístupu bude
specifikována a uloţena na jednom místě (u zákazníka), zatímco bude přenášena na místo druhé (k
-22/117-
poskytovateli). Jestliţe by si kaţdý poskytovatel cloudového řešení a kaţdý zákazník specifikoval jiný
formát představující informace o politice řízení přístupů, vznikla by neudrţitelná situace vedoucí
k potenciálnímu selhání. Proto existuje i v tomto případě standard eXtensible Access Control Markup
Language (XACML), který reprezentuje formát politiky řízení přístupů. [CSA2010a]
V konečném důsledku pak společnost můţe vyuţívat SAML single sign-on pro autentizaci uţivatel,
zatímco cloudová sluţba bude schopna přijmout informace o politice ve formátu SAML dle XACML
a pro přenos dat bude pouţit standard SPML. Dle [CSA2010a] není v současné době ještě standard
SPML natolik rozšířen, avšak s rostoucím zájmem o vyuţívání cloudových sluţeb ze strany velkých
organizací poroste v budoucnu také vyuţití tohoto standardu.
-23/117-
3 VAZBA CLOUD COMPUTINGU NA BUSINESS CONTINUITY MANAGEMENT
V této kapitole jsou nastíněny základní oblasti, ve kterých se koncepty Business Continuity
Management a Cloud Computing prolínají a ve kterých se doplňují. Protoţe zaměřením této práce jsou
z pohledu podnikové kontinuity především IT sluţby, je i tato kapitola pojata z pohledu moţností,
které přináší Cloud Computing pro kontinuitu zejména těchto sluţeb. Nejprve jsou v této kapitole
popsány oblasti, ve kterých Cloud Computing přináší nové moţnosti pro plánování Business
Continuity. Na základě tohoto textu je poté určen předpoklad pro vyuţití Cloud Computing řešení pro
zlepšení Business Continuity. Kapitolu uzavírá výčet poţadavků, které klade BCM na Cloud
Computing řešení a které je potřeba z hlediska podnikové kontinuity naplnit.
3.1 CO CLOUD COMPUTING SPOLEČNOSTEM PŘINÁŠÍ PRO JEJICH BUSINESS CONTINUITY
Plán Business Continuity byl dle [Clarke2009] ve světě businessu dlouho chápán jako něco, co je
finančně nákladné a co si mohou dovolit pouze velké korporace. A právě z tohoto hlediska můţe
dnešním podnikům pomoci Cloud Computing. Díky vyuţívání tohoto konceptu můţe mít prakticky
kaţdá firma alespoň základní koncepci plánu kontinuity v případě, ţe by podnik postihla jakákoli
narušující událost.
Základní myšlenkou sestavení plánu podnikové kontinuity je vytipování klíčových procesů, které jsou
pro společnost zásadní a kterými se s největší pravděpodobností odlišují od svých konkurentů.
Obdobný předpoklad platí pro IT systémy, které proces podporují. Je logické, ţe IT systémy, které
podporují klíčový podnikový proces, budou pravděpodobně klasifikovány rovněţ jako klíčové.
Problém spočívá v tom, ţe se obecně příliš nedoporučuje do cloudu přesouvat ty
sluţby/procesy/systémy, které podnik zásadním způsobem odlišují od konkurence. Na druhou stranu
by však bylo pošetilé očekávat, ţe všechny systémy, které klíčový proces podporují, budou klíčové
natolik, aby do cloudu nemohly být přesunuty.
Záleţí proto na konkrétní situaci a je na společnosti, aby zváţila, které aplikace, informační systémy
nebo celé servery přesunula do cloudu. Na základě výše uvedených informací by se dalo usoudit, ţe
Cloud Computing nepředstavuje pro Business Continuity ţádný potenciál jednoduše proto, ţe
přesunutí klíčových systémů do cloudu nese příliš velké riziko. V následujícím textu je uveden krátký
příklad argumentující pro opak.
V situaci, kdy by budovu společnosti zachvátil poţár, by se ocitla bez dodávky elektrické energie,
neboť ta by byla přerušena. Chod společnosti by byl váţně ohroţen a v budově by vypukl chaos.
Vedení společnosti by nemohlo svým zaměstnancům dát rychle vědět, co se děje a co by měli dělat.
I přes veškerá evakuační cvičení by lidé panikařili a nemohli by se dostat ke svým emailovým účtům,
kde by mohli nalézt uţitečné informace. A to i přes to, ţe by vlastnili mobilní zařízení, které by se
k emailovému serveru připojit dokázalo. Kdyby se však společnost předtím rozhodla přesunout své
emailové sluţby do cloudu, zaměstnanci by mohli např. díky wifi spotům dosáhnout svou emailovou
schránku, coţ by mohlo napomoci zvládnutí situace a sníţení chaosu.
3.1.1 CLOUD COMPUTING JAKO VÝCHODISKO Z KRIZE
Cloud Computing řešení je moţné chápat a vyuţívat jako řešení vypořádání se s narušujícími
událostmi nebo dokonce jako východisko z krize. Existuje několik modelů, kterými lze vyuţívat
Cloud Computing sluţby ve smyslu naplnění poţadavků kontinuity podniku:

Cloudové sluţby vyuţívané jako primární zdroj. Tím se rozumí situace, kdy společnost
přesunula do cloudu své procesy a aplikace, které jsou tak provozovány pouze na straně
poskytovatele, např.:
-24/117-
vyuţívání sluţeb emailového serveru umístěného u poskytovatele, čímţ je zajištěna
kontinuita podniku v případě, kdy hlavní budovu zasáhne neočekávaná událost,
o vyuţívání infrastruktury umístěné u poskytovatele, jako jsou servery či datová centra.
Tím je zajištěn přístup k datům nezávisle na situaci, která nastane.
Cloud Computingu je vyuţíváno pouze v případě, kdy nastane narušující událost. V takovém
případě zákazník svá data a aplikace primárně provozuje v in-house řešení. Data však
automaticky replikuje do úloţiště u poskytovatele, a to na základě předem stanovených
intervalů. V případě, kdy nastane narušující událost, společnost pouze přejde z in-house řešení
na řešení cloudové a své uţivatele jednoduše přesměruje na novou adresu.
o

Doba přesměrování je závislá na čase, který je potřeba vynaloţit na zajištění/spuštění
virtuálního serveru a případném transferu dat nebo jejich dešifrování. V případě pouţití
replikace je čas kratší, a doba potřebná k přesměrování je tak výrazně niţší.
Výhody tohoto řešení jsou přímočaré [Pyle2010]:
-
replikace dat probíhá automaticky, organizace nemusí vynakládat dodatečné náklady
na zajištění plánu pro obnovení z krize,
společnost není nucena dokupovat dodatečný hardware ani software,
společnost je ušetřena dodatečných nákladů na mirroring (přesný obraz) svého
datového centra.
Po pominutí hrozby jsou v tomto případě aktualizovaná data v cloudovém řešení replikována
zpět do in-house řešení, a business se tak můţe navrátit ke své běţné činnosti.


Přednastavené instance pouţívané v případě krize. V rámci tohoto modelu společnost vyuţívá
přednastavených serverových instancí, které jsou provozovány na straně poskytovatele.
V případě krize na primární lokaci společnosti jsou systémy předány do cloudu a instance se
stává primárním zdrojem dat. To můţe být podle [Opsview2010] provedeno jak manuálně, tak
také automaticky pomocí specializovaných nástrojů.
Aktivní - aktivní. Tento model zjednodušeně znamená, ţe systémy jsou provozovány jak na
straně poskytovatele, tak na straně zákazníka. Jedná se o představitele hybridního cloudu (viz
kapitola 2.1). Od předchozího modelu se tolik neliší, ale je zde obvykle více komplexnosti
z důvodu synchronizace dat, výpadek během sezení apod.
Z předchozího textu je patrné, ţe společnost si můţe vybrat, kterou cestou se preferuje vydat, aby
naplnila poţadavky nejen na Business Continuity, ale také poţadavky managementu v otázkách řešení
přesunu klíčových dat a aplikací do cloudu.
3.1.2 JAK MŮŽE CLOUD COMPUTING POMOCI ZAJISTIT BUSINESS CONTINUITY
Správným pouţitím cloudových sluţeb můţe společnost tohoto konceptu vyuţít při sestavování svého
plánu podnikové kontinuity, a to zejména v následujících oblastech [Opsview2010]:

Lidé a budovy - v dnešní době se rozšiřuje trend práce z domova, kdy zaměstnanci preferují
zůstat doma během pracovní doby a svou práci odvádět vzdáleně. To je umoţněno především
díky vysokému pokrytí širokopásmového připojení k internetu. Díky distribuované pracovní
síle a cloudovým sluţbám je pak snazší udrţet kontinuitu společnosti v případě vzniku
narušující události.
Pro tuto oblast platí také skutečnost, ţe v případě selhání stávajícího připojení k internetu
mohou zaměstnanci vyuţít jiných forem připojení, ať uţ pomocí wifi spotů nebo pomocí
svého mobilního zařízení.
-25/117-

Technologie - koncept Infrastructure-as-a-Service je velmi přesvědčivým konceptem pro
zajištění strategie podnikové kontinuity pro data centra, a to za vyuţití některého z modelů
představených výše.
Mimoto lze do této oblasti zařadit také technologii VoIP (Voice over IP), která se v posledních
několika letech rozšiřuje a která by díky svému potenciálu mohla poskytnout dostatečnou
kapacitu pro telekomunikační účely v rámci malého nebo středního podniku.

Informace - vyuţití cloudových sluţeb v této oblasti je zřejmé. Společnost vyuţívá
cloudových sluţeb k uloţení aktuálních dat, a to za předpokladu zachování jejich důvěrnosti
a udrţení jejich vysoké dostupnosti v případě potřeby.
Je však důleţité zváţit, zda poskytovatel cloudových řešení můţe citlivá data uchovávat, a to
z důvodu geografického umístění či právní regulace. Opomenuta by neměla být ani integrita
dat, a to především v komplexních prostředích. Integrita dat se týká především přístupu, kdy
jsou cloudové sluţby vyuţívány pouze jako záloha.
Při zvaţování vhodného modelu vyuţití cloudových sluţeb je proto nutné zohlednit mimo jiné také
dopad Cloud Computingu na všechny tyto tři výše zmíněné oblasti aktiv.
3.1.3 PRAVIDLA ADOPCE CLOUD COMPUTINGU JAKO NÁSTROJE BUSINESS CONTINUITY
I kdyţ Cloud Computing přináší společnostem bez pochyby řadu zajímavých benefitů, nelze opomíjet
ani rizika, která musí být vzata v úvahu a musí být řízena. Mezi tato rizika patří bezpečnost, soulad
s podnikovou architekturou, soukromí a další provozní rizika související s hladkým chodem podniku.
Následující body podrobněji popisují oblasti, na které je nutné se zaměřit za účelem úspěšné
implementace Cloud Computing řešení jako nástroje pro Business Continuity [Vellante2010]:





S rostoucím zájmem o virtualizaci a Cloud Computing roste také poptávka po odbornících na
Business Continuity. To je dáno především tím, ţe tradiční Business Continuity a řízení rizik
má přehled o technologickém portfoliu celé společnosti, a můţe tak zajistit komplexní pohled
na podnik, který je nedocenitelným poţadavkem cloudových iniciativ.
Společnosti, které se vydaly cestou virtualizace a Cloud Computingu, musí zajistit soulad
cloudových iniciativ s tradičními metrikami a disciplínami Business Continuity, mezi které
patří řízení rizik či governance.
Před adopcí virtualizace a Cloud Computingu je důleţité sestavit celkovou strategii
a z pohledu procesů obnovení z krize a podnikové kontinuity stanovit cíl zajištění pruţnosti.
Tato pruţnost by měla být základní součástí podnikových operací. Klíčovou odpovědností
v rámci sestavování strategie je vytvoření povědomí jak o příleţitostech, tak o rizicích.
Společnosti, které chtějí konceptu virtualizace a Cloud Computingu vyuţít v hlubším slova
smyslu a zapojit je do běţného chodu organizace, by měly začít s dozorem nad procesem
ohodnocení rizik a identifikace metrik, které jsou pro organizaci důleţité.
Dodavatelé, kteří chtějí svým zákazníkům poskytovat sluţby krizového řízení a Business
Continuity, by měli porozumět skutečnosti, ţe nabízet jedno řešení všem zákazníkům není
moţné. Odlišnosti jako velikost společnosti, odvětví podnikání nebo klíčové priority jsou
natolik odlišujícím faktorem, který vyţaduje podrobnější analýzu a ohodnocení řešení
vhodného pro konkrétní situaci.
-26/117-
3.2 PŘEPOKLAD PRO VYUŽITÍ CLOUD COMPUTINGU JAKO NÁSTROJE BCM
Pro to, aby mohl být Cloud Computing ve společnosti úspěšně pouţit pro řízení její kontinuity, je
zapotřebí, aby tento koncept splňoval předpoklad řízení rizik. Bliţší upřesnění tohoto předpokladu je
popsáno v následující podkapitole.
3.2.1 ŘÍZENÍ RIZIK
Výstupem účinného řízení rizik by měla být identifikace technologických aktiv, identifikace dat
a jejich vazby na podnikové procesy, aplikace, úloţiště dat apod. Vedle identifikace by podle
[Rittinghouse2010] mělo být výstupem také určení odpovědnosti za správu těchto aktiv. Formální
proces ohodnocení rizik by měl alokovat bezpečnostní zdroje navázané na podnikovou kontinuitu.
Ohodnocení rizik je klíčové pro rozhodování v otázkách prioritizace mezi uţitkem společnosti
a ochranou aktiv. Nedostatek pozornosti věnované ohodnocení rizik vede k nárůstu auditních nálezů
týkajících se informační bezpečnosti, ohrození certifikačních cílů a můţe vést aţ k neúčinnému výběru
bezpečnostních opatření, která nejsou schopna sníţit rizika informační bezpečnosti na přijatelnou
úroveň.
Detailnější ohodnocení rizik, a to především na technické úrovni za vyuţití metody modelování
hrozeb, by mělo být pouţito jak v případě aplikací, tak infrastruktury. V návaznosti na toto
ohodnocení je umoţněno týmům vyvíjející produkty úzce spolupracovat s interním týmem
bezpečnosti, a účinně tak testovat aplikace na definované hrozby [Rittinghouse2010]. Modelování
hrozeb vyţaduje znalost jak IT procesů, tak procesů podnikových, a to ve spojení s technologickými
znalostmi o fungování aplikací a systémů podporujícími běţící procesy.
Společně s tím, jak byl model Software-as-a-Service postupně přesunut do cloudu, vznikl také
předpoklad, ţe rizika spojená s informační bezpečností budou řešena na straně poskytovatele sluţeb.
Tento předpoklad vznikl na základě jednoduché skutečnosti, totiţ ţe poskytovatel sluţeb si nemůţe
dovolit vzbudit negativní zájem způsobený narušením bezpečnosti sluţeb na jeho straně. Taková
situace by ho stála ztrátu pověsti a dobrého jména, coţ by pro něj znamenalo postupnou ztrátu důvěry
zákazníků, hrozbu právních dopadů a potenciálně konec jeho podnikání.
Druhým pramenem tohoto předpokladu je také skutečnost, ţe dodavatel se specializuje na poskytování
sluţeb, a proto je jedním z jeho hlavních zaměření také soustředit se na bezpečnost. K zajištění
zabezpečení má zpravidla více technologických prostředků a lidských zdrojů neţ většina firem sluţby
odebírajících.
3.3 POŽADAVKY BCM NA CLOUD COMPUTING
Z charakteristiky obou konceptů (viz kapitoly 1 a 2) vychází následující text této kapitoly, který je
zaměřen na tři nejdůleţitější poţadavky z pohledu Business Continuity. Pro přehlednost jsou tyto
poţadavky označeny P01 – P03.
Poţadavky konceptu Business Continuity Management, které jsou kladeny na řešení Cloud
Computingu, lze zařadit do tří jim nadřazených kategorií:
A. Bezpečnost
B. Disaster recovery
C. Service Level Agreement
Tyto kategorie byly zvoleny pro lepší přehlednost a následnou klasifikaci jednotlivých poţadavků.
Zatímco první kategorie se týká technického zajištění bezpečnosti uloţených dat a provozovaných
aplikací, druhá kategorie specifikuje strategii pro obnovení po havárii a třetí kategorie zahrnuje otázky
smluvního zajištění poskytování/odebírání sluţeb.
-27/117-
V Tab. 1 je uvedena přehledná klasifikace identifikovaných poţadavků, které by mělo naplnit kaţdé
řešení Cloud Computingu pro to, aby společnost dosahovala větší pruţnosti v oblasti Business
Continuity:
Kategorie
Název poţadavku
A. Bezpečnost
P01 Bezpečnost a monitoring
B. Disaster recovery
P02 Zálohování a archivace
C. Service Level Agreement
P03 Dostupnost sluţeb
Tab. 1 - Kategorizace poţadavků BCM na Cloud Computing řešení (Zdroj: Autor)
V následujícím textu jsou tyto poţadavky detailněji popsány.
3.4 KATEGORIE A - BEZPEČNOST
Jednotlivá cloudová řešení se co do naplnění kritérií bezpečnosti a monitoringu výrazně liší, a to ve
všech modelech poskytování sluţeb, ať uţ se jedná o software, platformu nebo infrastrukturu.
Téměř všichni poskytovatelé nabízejí zabezpečení nabízených sluţeb. Jiţ menší počet poskytovatelů
se zmiňuje o standardech bezpečnosti, které jsou dodrţovány a ještě niţší počet poskytuje informace
zvlášť o zabezpečení a zvlášť o bezpečnostním monitoringu.
V některých případech jsou sluţby zabezpečení a monitoringu nabízeny partnerskou společností
poskytovatele sluţby. V takovém případě je třeba zváţit, zda je pro společnost vhodné, ţe do vztahu
přibude další strana, i kdyţ sama společnost s ní nebude v ţádném přímém vztahu, nebo zda je naopak
ţádoucí, aby se o zabezpečení a bezpečnostní monitoring starala specializovaná firma.
V rámci návrhu bezpečnostních opatření by měly být zahrnuty jak metody technologie a návrhu, tak
bezpečnostní procesy potřebné k zajištění následujících sluţeb napříč všemi technologickými vrstvami
[Rittinghouse2010]:







autentizace,
autorizace,
dostupnost,
důvěrnost,
integrita,
odpovědnost,
soukromí.
Vedle těchto sluţeb nabízí cloudové řešení také moţnost monitoringu událostí, které se nějakým
způsobem vztahují k bezpečnosti. Ne kaţdá společnost si můţe dovolit provozovat vlastní
bezpečnostní monitoring, a to jak z důvodu nedostatku technických prostředků, tak z nedostatku
zkušeného personálu.
Podstata bezpečnostního monitoringu spočívá v tom, ţe jsou monitorovány komponenty
infrastruktury, na kterých jsou umístěna citlivá data. Například v případě finanční instituce to mohou
být servery, kde jsou umístěna data o finančních trzích.
Na těchto komponentách jsou monitorovány události, které nějakým způsobem souvisí s bezpečností
systému. Takovou událostí můţe být například opakované neúspěšné přihlášení uţivatele, neúspěšná
autorizace uţivatele, změna nastavení monitorovaného systému apod.
-28/117-
Tyto události jsou následně ze všech monitorovaných systémů různými metodami přenášeny na jedno
místo, kde jsou dále vyhodnocovány. Jednotlivým událostem je přiřazována jejich závaţnost. Díky
prostředkům monitorování je potom moţné na základě jedné nebo několika bezpečnostních událostí
vytvořit incident, který je potřeba řešit, a je proto přiřazen řešiteli.
V prostředí Cloud Computingu je potom moţné, aby se o bezpečnostní monitoring staral poskytovatel
sluţby. Výčet bezpečnostních událostí, které je potřeba monitorovat, je společným výstupem jednání
poskytovatele a odběratele. Při výskytu některé bezpečnostní události nebo sady bezpečnostních
událostí je pak moţné definovat určité akce, například zaslání emailu o výskytu incidentu. Díky takové
emailové notifikaci je potom zákazník vţdy informován o aktuální bezpečnostní situaci odehrávající
se nad jeho systémy.
Bezpečnost aplikací je stále odpovědností společnosti i přesto, ţe je přesune do cloudu. Bezpečnost dat
a infrastruktury, na kterých tyto aplikace běţí, je však odpovědností poskytovatele. Lze předpokládat,
ţe poskytovatel cloudových sluţeb disponuje aktuálnějšími prostředky ochrany systémů
a infrastruktury před kybernetickými útoky neţ je v moţnostech odběratele. To je dáno jak
specializací poskytovatele na zajištění bezpečnostních aspektů, tak i tím, ţe poskytovatel si zpravidla
můţe dovolit zaměstnat odborníky v oboru bezpečnosti.
Postupem času navíc poskytovatelé cloudových řešení získávají také uznávané certifikace jako
například SAS70, coţ je široce uznávaný standard pro provádění kontroly účtů (auditing) vydaný
americkým institutem AICPA (American Institute of Certified Public Accountants). Také [Hapl2010]
uvádí, ţe potenciálně slabším článkem bohuţel zůstávají aplikace na cloudu provozované, kde záleţí
na tom, zda se jedná o cloud veřejný, privátní či hybridní.
3.4.2 DŮVĚRNOST INFORMACÍ
Zajištění důvěrnosti informací je aspektem, který by měl být upraven v rámci Service Level
Agreement. Přesunutí kritických aplikací a citlivých dat do veřejného cloudu vzbuzuje u společností
nemalý zájem. Je povinností poskytovatele cloudových sluţeb zajistit, aby data po přesunu do cloudu
měla stejné zabezpečení a stejnou úroveň důvěrnosti jako měla před přesunutím.
Zajištění bezpečnosti a důvěrnosti dat je důleţité hned z několika důvodů [Rittinghouse2010]:



společnost odebírající sluţby potřebuje svým zákazníkům poskytnout spolehlivé sluţby tak,
aby neztratila jejich důvěru,
společnost potřebuje pomocí těchto sluţeb naplnit své Service Level Agreements, které má
uzavřené se svými zákazníky či odběrateli,
společnost musí být schopna obstát před pravidelnými audity.
3.5 KATEGORIE B - DISASTER RECOVERY
Účelem plánování podnikové kontinuity a plánu obnovení z krize je minimalizace dopadu negativních
událostí na podnikové procesy. K tomu, aby společnost zajistila nepřerušenou komunikaci napříč
všemi vrstvami podniku a mohla se snadno zotavit z krize, potřebuje pruţné sluţby. Ty sluţby, které
jsou poskytovány modelem SaaS a které zajišťují nepřetrţitou komunikaci i v případě krize (např.
sluţby emailového poskytovatele), pomáhají společnosti nejen obnovit chod po výpadku, ale mohou
také sníţit celkovou komplexnost, náklady a kaţdodenní rizika klíčových aplikací.
Na příkladech poskytování emailových sluţeb a sluţeb telekomunikačních lze snadno demonstrovat,
jaké výhody Cloud Computing pro plánování Business Continuity a obnovení z krize přináší.
V případě narušující události v lokalitě podniku jsou komunikační sluţby stále dostupné, a společnost
tak můţe zůstat v kontaktu se svými zaměstnanci, zákazníky i partnery.
-29/117-
S postupnou virtualizací prostředí SaaS narůstá i vyuţití těchto technologií pro Business Continuity,
neboť virtualizační software účinně napomáhá uvolnění vazby mezi aplikacemi a hardwarem, na
kterém tyto aplikace běţí. Virtuální server je moţné kopírovat, zálohovat a přemisťovat stejně
jednoduchým způsobem, jako je moţné přemisťovat soubor. Narůstající počet poskytovatelů
virtualizačního software nabízí ve svém řešení také zabudovanou schopnost podporovat migraci dat za
běhu systému.
To společně se skutečností, ţe došlo k uvolnění vazby aplikací na hardware, umoţňuje podle
[Rittinghouse2010] vzniknout nízkonákladovým prostředkům rychlé realokace výpočetních zdrojů bez
jakéhokoli výpadku sluţby během migrace. Další nespornou výhodou virtualizace pro podnikovou
kontinuitu je schopnost poskytovatele dodávat sluţby v souladu se stanovenými Service Level
Agreements a také sluţby vysoké kvality.
Eliminace dopadu výpadku sluţeb na straně zákazníka patří bezesporu k předním výhodám Cloud
Computingu. Co se ovšem stane v případě, kdy k výpadku sluţby dojde u poskytovatele? Poskytovatel
musí být schopen přesně specifikovat, co se v takovém případě stane. Riziko výpadku se týká všech
modelů poskytování cloudových sluţeb, ať uţ se jedná o software, infrastrukturu nebo platformu.
Většina poskytovatelů je schopna obnovit sluţby v řádu několika sekund aţ minut, ale je důleţité také
zohlednit to, co se stane s daty, která nebyla v době výpadku uloţena.
Existuje několik způsobů, kterými jsou poskytovatelé schopni zajistit, ţe nedojde k ţádné ztrátě,
včetně cacheování a průběţného ukládání dat do operační paměti nebo soustavného ukládání dat do
paralelní instance. Tento způsob zajištění obnovy dat by měl být vzat v úvahu při volbě vhodného
poskytovatele cloudových sluţeb, stejně tak by tato technická specifika měla být podchycena
v ujednání Service Level Agreement.
V dnešní době na trhu nalezneme poskytovatele, kteří zaručují nulovou ztrátu dat v případě výpadku,
někteří jiní poskytovatelé hovoří pouze o minimalizaci ztráty. Je vhodné takováto různá řešení před
samotným rozhodnutím pečlivě zváţit, neboť v některých případech bude mít vyšší prioritu jiné
bezpečnostní kritérium neţ ztráta transakčních dat v poslední minutě před výpadkem sluţby.
Zálohování je pro společnost důleţité nejen v případě potřeby obnovení z krize, ale i za běţných
okolností je někdy třeba vrátit stav aplikace/systému do předchozího stavu například z důvodu
nekonzistence dat.
Poskytovatel je zpravidla schopen zajistit zálohování automaticky na několika různých úrovních.
V některých případech (například v případě vyuţívání infrastruktury jako sluţby) je schopen zákazník
pomocí webového rozhraní pro správu nakoupených sluţeb ovlivňovat frekvenci těchto záloh nebo
provádět zálohy ad hoc.
Díky rozšíření virtualizace je dnes moţné zálohovat celé image nakoupených serverových instancí se
stejnou jednoduchostí a elegancí, jako je moţné zálohovat běţné soubory.
Existuje několik modelů zálohy dat [Pohorelsky2002]:



nestrukturovaná záloha – nestrukturovanou zálohou se rozumí například manuální záloha na
přenosná média (CD/DVD) s minimální informací o tom, co bylo zálohováno a kdy,
inkrementální – v tomto případě jsou pravidelně prováděny inkrementální zálohy, tedy zálohy
pouze přírůstku dat,
rozdílová – tato metoda zálohování kopíruje soubory, které byly od poslední zálohy
modifikovány nebo vytvořeny,
-30/117-


reverzně přírůstková – tato metoda uchovává informace o rozdílech mezi současným stavem
a stavem poslední zálohy,
úplná záloha – tento model zálohy zálohuje data celého systému.
Vedle modelů zálohy dat lze rozlišovat mezi metodami zálohování [Zoner2010]:





ruční zálohování dat – toto zálohování probíhá ručně a není automatizováno,
automatizovaná synchronizace dat – tato metoda můţe být realizována například pomocí
dávkového souboru,
zálohování dat s komprimací – zálohovaná data jsou v tomto případě komprimována,
a dochází tak k úspoře místa,
automatizované zálohování dat s komprimací – programy umoţňující automatizovaně
zálohovat data s komprimací, umoţňují také například šifrování záloh,
imaging – tento způsob zálohování vytváří přesný obraz disku, a to tak, ţe jsou při záloze
ukládány namísto jednotlivých souborů informace z obsazených sektorů na daném diskovém
oddílu.
Vedle zálohování je pro společnost nezbytné nastavit také proces archivace. Díky archivaci je potom
společnost schopna dohledávat data k určitému časovému okamţiku v minulosti. Důvodů k vyhledání
archivovaných dat lze jmenovat několik. Mezi ty nejčastější patří policejní vyšetřování nebo auditing
několika účetních období dozadu.
3.6 KATEGORIE C - SERVICE LEVEL AGREEMENT
Součástí sestavení plánu kontinuity podnikových sluţeb je tzv. Service Level Management
(podrobnosti viz kapitola 1.5). V rámci tohoto procesu jsou identifikovány základní poţadavky na
obnovení podnikových sluţeb, jako je doba obnovy a bod obnovy.
Stanovení doby obnovy a bodu obnovy by mělo vycházet také z identifikace, jak dlouho je společnost,
resp. určitá podniková jednotka schopna bez fungující sluţby/procesu existovat a také ze specifikace
toho, jak dlouhý časový úsek bez zálohy dat je pro danou sluţbu ještě tolerovatelný. Na základě toho
jsou následně sestavovány plány záloh.
Pokud má tedy cloudová sluţba naplňovat jak poţadavky Business Continuity, tak poţadavky
krizového řízení a plánů obnovení z krize, je podstatné, aby v dokumentu SLA byly podrobně popsány
všechny úrovně smluvené dostupnosti sluţby, včetně plánovaných odstávek z důvodu aktualizace
a údrţby sluţeb.
Základním měřítkem pro Business Continuity je procentuálně vyjádřená dostupnost cloudové sluţby,
která se pohybuje u poskytovatelů nejčastěji v rozmezí 99,9% - 100%. Důleţitá je také frekvence
měření a vyhodnocování tohoto intervalu, která se potom liší, zda se jedná o frekvenci měsíční,
čtvrtletní či roční.
Špatně definované Service Level Agreement patří k nejčastějším obavám z Cloud Computingu.
[Velte2010] Důsledkem toho je potom nedůvěra společností v bezpečnost poskytovaných sluţeb,
v jejich dostupnost a dobu provozuschopnosti, obnovení z krize apod.
-31/117-
Důvodem, proč se některé společnosti rozhodují pro přesun svých sluţeb do cloudu, můţe být také to,
ţe potřebují zajistit jejich dostupnost v reţimu 24/7/365, tedy nepřetrţitě a sami nejsou schopni
takovou vysokou dostupnost zajistit vlastními prostředky.
Poskytovatelé sluţeb jsou naopak takovou dostupnost schopni zajistit, neboť na rozdíl od většiny
zákazníků disponují redundantní infrastrukturou, na kterou jsou schopni sluţby v řádu sekund
přemístit v případě, kdy by došlo k výpadku na primární infrastruktuře.
Jsou také schopni zabezpečit pravidelné kopie serverů, zálohování a archivaci, a to jak pro naplnění
poţadavků Business Continuity v případě výpadku sluţby, tak pro schopnost zpětného dohledávání
určité skutečnosti v minulosti (např. na základě policejního vyšetřování) nebo pro poţadavky
auditingu.
Podrobné informace o dostupnosti sluţeb musí být definovány v SLA, kde je nutné mimo jiné uvést:





dobu, po kterou musí být sluţba dostupná,
dobu plánovaných odstávek nutných pro aktualizaci a údrţbu sluţby,
dobu, po kterou bude ke sluţbě poskytována technická podpora,
reakční dobu, za kterou je poskytovatel schopen reagovat na vzniklou situaci a zahájit její
řešení,
dobu, za kterou dojde k obnovení sluţby v případě výpadku, a to odlišenou dle vzniku
výpadku:
- v čase podpory,
- mimo čas podpory.
Dalším důvodem, proč se společnost rozhoduje nad vyuţíváním cloudových sluţeb, můţe být také to,
ţe potřebuje překlenout různé výkyvy ve vyuţívání sluţeb. Typickým příkladem je firma, která ke
svému podnikání vyuţívá e-shop, jehoţ internetové stránky jsou navštěvovány řekněme sezónně. Do
této kategorie lze zařadit například knihkupectví s výkyvy v návštěvnosti v období Vánoc, květinářství
s výkyvy na různé sváteční dny nebo rekreační zařízení se sezónní vytíţeností v létě/v zimě.
Pro takovou společnost není ţádoucí, aby nakupovala zbytečně rozsáhlou infrastrukturu, která by byla
plně vyuţita dvakrát do roka a ve zbývajícím čase by efektivně vyuţívána nebyla. Stejně tak ovšem
není ţádoucí, aby společnost přicházela o cenné zakázky a zákazníky jenom proto, ţe není schopna
ustát zvýšený nápor zákazníků.
Řešením těchto problémů jsou právě cloudové sluţby, které poskytují pruţnou kapacitu vyuţívání
sluţeb. Protoţe společnost dopředu ví, ve kterých dnech očekává zvýšený zájem zákazníků, můţe dle
toho sestavit plán nákupu cloudových sluţeb a zaplatit skutečně za to, co spotřebuje. Poté, co nápor
zákazníků pomine, navrátí se firma bez obtíţí na niţší interní kapacitu.
Téměř standardem v dnešní době je architektura sluţeb, které jsou navrhovány tak, aby byly vysoce
dostupné. Tyto sluţby běţí na serverech s různou úrovní virtualizované technologie, která je dodávána
skrze rozsáhlá datová centra běţící podle SLA na úrovni 99,99% [Rittinghouse2010] dostupnosti nebo
ještě vyšší.
Například v říjnu 2008 zveřejnila společnost Google článek [Glotzbach2008], ve kterém představila
dostupnost cloudových emailových sluţeb Gmail ve srovnání s běţnými konkurenčními řešeními (viz
Obr. 7).
Tento článek byl zaměřen především na měření spolehlivosti cloudových sluţeb, konkrétně měření
dostupnosti emailové sluţby Gmail. Výsledkem bylo zjištění, ţe sluţba byla v průběhu celého roku
-32/117-
dostupná více neţ 99,9% času, a to jak pro soukromé zákazníky, tak pro firmy. V průměru to tak
znamená výpadek sluţeb na 10 – 15 minut měsíčně.
Ve srovnání s ostatními tradičními způsoby emailového řešení si cloudová sluţba vede velmi dobře.
Podle průzkumu provedeného ve stejném roce bylo zjištěno, ţe v průměru společnosti s tradičními
řešeními čelí neplánovanému výpadku sluţeb 30 – 60 minut za měsíc a plánovaným odstávkám
v rozmezí 36 – 90 minut za měsíc (viz Obr. 7).
Doba výpadku služby (v minutách)
Srovnání výpadků emailových
služeb (v min./měsíc)
150
100
Plánovaná odstávka
Neplánovaná odstávka
50
0
Gmail
GroupWise
Lotus
Exchange
Obr. 7 - Srovnání výpadků emailových sluţeb v min./měsíc (Zdroj: [Glotzbach2008])
Na základě těchto zjištění společnost Google jiţ v roce 2008 oznámila, ţe 99,9% dostupnost
zaručenou SLA je schopna zajistit také u dalších sluţeb jako je kalendář, dokumenty, webové stránky
nebo komunikátor.
Tím ve své podstatě vznikl standard poskytování sluţeb s 99,9% nebo vyšší dostupností. V dnešní
době nalezneme mnoho poskytovatelů, kteří zaručují 100% dostupnost nabízených sluţeb.
3.7 NEGATIVNÍ DOPAD CLOUD COMPUTINGU NA BUSINESS CONTINUITY
Cloud Computing beze sporu přináší z hlediska podnikové kontinuity řadu výhod. Setkáme se však
také s několika překáţkami, které by mohly potenciálně narušit strategii Business Continuity podniku.
V minulosti se jiţ odehrálo několik případů, kdy musely být pozastaveny sluţby poskytované jednomu
zákazníkovi a díky principu sdílení technologické infrastruktury došlo k narušení běhu sluţeb
i u odběratelů, kteří neměli s incidentem nic společného. Příklady lze nalézt prakticky po celém světě.
V následujícím textu je uvedeno několik incidentů, které se v minulosti odehrály:

Ve Spojených státech došlo k případu, kdy bylo několik firem vyšetřováno federální policií
a z toho důvodu bylo zabaveno a prošetřováno i jejich datové úloţiště. Bohuţel však toto
úloţiště bylo umístěno v cloudu a vedle vyšetřovaných firem poskytovatel provozoval sluţby
i ostatních zákazníků. Bez ohledu na to byly všechny internetové stránky provozované
poskytovatelem dočasně vypnuty.
Společnostem tak byla dle [Fox2009] způsobena několikamilionová ztráta. Zvláště těm
společnostem, jejichţ business byl zaloţen na fungující internetové stránce, bylo zcela
zamezeno naplňovat své podnikové cíle.
-33/117-

V Evropě lze nalézt podobný příklad ve Švédsku. Zde se v nedávné době zdvihla iniciativa
podporovaná vládou, která vyústila dočasným ukončením sluţeb jednoho poskytovatele
internetových sluţeb. Důvodem pro zamezení moţnosti poskytovat sluţby bylo, ţe jedním ze
zákazníků vyuţívajících jeho sluţeb byla skupina Pirate Bay (skupina vyšetřovaná z důvodu
porušení autorských práv u digitálních médií). [Fox2009]
V evropských podmínkách a v podmínkách České republiky konkrétně sice neexistuje instituce s tak
silnými pravomocemi, jako tomu je v případě FBI ve Spojených státech, ale je moţné, ţe společnost
bude vyuţívat sluţby datového centra umístěného v jiné zemi. V takovém případě je vhodné ověřit si
stávající místní legislativu.
Jistou moţností, jak obejít toto riziko, je umístit svá data do více datových center. Je však třeba ověřit,
zda jsou tato datová centra vlastněna odlišnými poskytovateli. Jedná se však vţdy o komplikované
řešení, které naproti základnímu benefitu konceptu Cloud Computing znamená spíše zvýšení nákladů
odebírající společnosti.
K ohroţení kontinuity sluţeb zákazníka můţe dojít také v případě, kdy jeden z odběratelů sluţeb čelí
útokům tzv. odmítnutí sluţby (angl. Denial of service - jedná se o snahu učinit např. internetovou
sluţbu nebo webovou stránku nedostupnou). V takovém případě však poskytovatel můţe učinit první
krok a ukončit poskytování sluţeb zákazníkovi ohroţujícímu provoz celé infrastruktury, jako se to
stalo například na začátku prosince 2010 [Kirk2010], kdy Amazon rozhodl o ukončení poskytování
sluţeb organizaci WikiLeaks, a zabránil tak moţnému výpadku sluţeb ostatních odběratelů.
-34/117-
4 VYUŽITÍ BCM A CLOUD COMPUTINGU V OBLASTI TERCIÁRNÍHO VZDĚLÁVÁNÍ
Sektor terciárního vzdělávání má svá jistá specifika, která vyplývají ze způsobu jeho financování
a z mnoha dalších faktorů, kterými je například struktura "zákazníků", kterým své sluţby poskytuje.
V mnohých rysech se však sektor vzdělávání podobá komerčním společnostem, neboť v dnešní době
roste konkurence v oblasti terciárního vzdělávání, a instituce proto bojují o nové studenty. Díky tomu
dochází k dramatickému nárůstu nákladů v sektoru školství, rychlejšímu neţ je růst inflace. Univerzity
se snaţí zvýšit atraktivitu lepší nabídkou sluţeb, výjimku netvoří ani nabídka informačních
technologií. Tato kapitola je blíţe zaměřena na to, jaká specifika má v sektoru terciárního vzdělávání
Business Continuity Management, co mu můţe nabídnout Cloud Computing a jak tento koncept vyuţit
k naplnění cílů BCM.
4.1 CHARAKTERISTIKA SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ A JEHO ODLIŠNOSTI OD SEKTORU
SOUKROMÉHO
Informační technologie se staly nedělitelnou součástí systému vzdělávání. Důkazem toho je vznik
řešení, mezi která patří studijní informační systémy (SIS) nebo řídící výukové systémy (LMS), které
se staly kaţdodenní součástí ţivota institucí pro vzdělávání. Stejně tak jako je tomu i v jiných
ekonomických odvětvích, i v sektoru školství vykonávají informační technologie řadu klíčových rolí.
Celkové náklady na IT v sektoru terciárního vzdělávání mají rostoucí tendenci. Částečně je to
způsobeno nároky na širokopásmové připojení nebo na vybavení počítačových učeben. Dalším
důvodem vysokých nákladů na IT je podle [Educause2010] dlouhá tradice institucí budovat si své
vlastní informační systémy a spravovat téměř veškerou IT infrastrukturu interně.
Sektor terciárního vzdělávání je odlišný od komerčního sektoru strukturou uţivatelů, kteří informační
systémy vyuţívají a kteří kladou prakticky neustále poţadavky na nové prvky technologické
infrastruktury, na nové aplikace, na připojení, na vybavení učeben, počet přístupových bodů
bezdrátové sítě a spoustu dalších.
Zatímco mezi uţivatele informačních systémů patří fakulty, katedry, zaměstnanci včetně
administrativních pracovníků, kteří jsou běţnými uţivateli informačních systémů také v komerčních
sférách (jako paralela k podnikovým jednotkám, oddělením apod.), v sektoru terciárního vzdělávání se
setkáme ještě s jednou skupinou uţivatelů. Jsou jí studenti. Tato skupina je velmi početná, má
relativně vysoké poţadavky na funkcionalitu informačního systému a mimo jiné vyţaduje precizní
přidělení přístupových práv. Představuje také vysoké zatíţení informačních systémů v určitých
obdobích, mezi která patří například přihlašování na zkoušky a také poţaduje v podstatě 24/7
dostupnost systémů.
Díky této členitosti struktury uţivatelů však IT odborníci v sektoru vzdělávání obvykle nečelí otázkám
uţivatelů, se kterými se lze setkat v soukromém sektoru komerčních organizací [Gulachek2005]. Mezi
takové otázky patří dotazy na to, jaký existuje plán Business Continuity nebo co se stane v případě,
kdy nastane neočekávaná událost apod.
Problémem oblasti terciárního vzdělávání a sektoru školství v České republice obecně je to, ţe
instituce nemají dostatek financí. To je dáno především tím, ţe na rozdíl od našich západních sousedů
studenti neplatí školné, a instituce je proto závislá na tom, kolik financí dostane od ministerstva
školství MŠMT, resp. od státu. Tato situace má nejen dopad na moţnosti institucí na nákup
technického vybavení, ale také komplikuje to, jak chápat v otázkách informačních technologií ve
školství roli studenta – zda se jedná pouze o uţivatele, nebo o zákazníka.
-35/117-
Výjimku v tomto ohledu tvoří v České republice soukromé vysoké školy. Na soukromých školách
studenti platí školné stejně tak, jako je tomu v zahraničí. Na těchto školách proto můţeme hovořit
o studentovi jako o zákazníkovi. Státní školy teprve přistupují k modelu placení školného, který
v budoucnu ovlivní to, jaké sluţby bude škola muset poskytovat tak, aby uspokojila potřeby studenta,
tedy zákazníka. V současném modelu státních vysokých škol se proto dostáváme k dilematu, jak
studenta chápat.
V rámci této diplomové práce bude o studentovi v tomto kontextu dále uvaţováno jako o zákazníkovi.
Důvodem je to, ţe pravděpodobně jiţ brzy budou všichni studenti za sluţby vysokých škol platit
a také to, ţe jiţ dnes jsou to právě studenti, kteří kladou poţadavky na to, jaké informační technologie
potřebují ke svému studiu. Protoţe je tato práce zaměřena na vyuţití Cloud Computing řešení pro
naplnění Business Continuity, dostaneme se k otázce, kdo má větší zájem o udrţení Business
Continuity instituce – zda je to student nebo MŠMT, které školy prakticky financuje. Lze
předpokládat, ţe je to student, kdo by měl klást vysoké poţadavky na Business Continuity, neboť se
jedná o jeho budoucnost a jeho data, která by mohla být potenciálně ztracena.
Na základě těchto důvodů budeme v rámci této práce o studentovi uvaţovat jako o zákazníkovi
odebírajícím sluţby instituce terciárního vzdělávání a zároveň uţivateli informačních technologií touto
institucí poskytovaných.
4.2 VYUŽITÍ BCM V SEKTORU TERCIÁRNÍHO VZDĚLÁVÁNÍ
Postupný nárůst informačních technologií do kaţdodenní přítomnosti má za důsledek i paradoxní
skutečnost, ţe řada institucí si plně neuvědomuje svou závislost na funkčních informačních systémech.
Proto je relativně jednoduché zanedbat či opomenout skutečný dopad rušivé události na chod instituce.
Existují dva způsoby, kterými můţe být instituce ovlivněna v případě, kdy se rušivá událost dotkne
nějakým způsobem IT systémů [Datamonitor2007]:


selhání IT - rušivá událost přímo narušila IT systémy, které je potřeba zcela obnovit před tím,
neţ bude instituce opět schopna běţné činnosti,
nepřímý dopad na IT - IT systémy se budou muset přizpůsobit rušivé události, která nastala
v jiné části organizace, coţ je dáno právě zvyšující se závislostí podnikové činnosti na
informačních systémech a na vzrůstající vzájemné provázanosti.
V kapitole 1.2 Ţivotní cyklus Business Continuity jsou uvedeny 4 fáze ţivotního cyklu plánování
Business Continuity. V následujících podkapitolách je nastíněno, jak lze BCM v sektoru vzdělávání
v jednotlivých fázích tohoto cyklu prakticky vyuţít.
Univerzity jsou stejně jako ostatní společnosti náchylné k mnoţství přírodních a lidskou vinou
způsobených mimořádných událostí a rizik. Společně s rozpoznáním, ţe ne všechny události mohou
být odvráceny a ţe některá rizika mohou být přijatelná lze dojít ke zjištění, ţe řádné plánování je pro
udrţení a obnovení sluţeb naprosto nezbytné.
Jak je uvedeno v první kapitole, která podrobněji popisuje principy plánování Business Continuity,
toto plánování není spojeno výhradně s katastrofami typu záplavy nebo zemětřesení, ale také
s rušivými událostmi jako je výpadek dodávky elektrického proudu či serveru, se kterými se
v prostředí dnešních společností setkáme poměrně často. Jedním z důvodů je podle [Vogel2010a]
nárůst IT v posledním desetiletí, který přinesl nejen nové moţnosti, ale také nové zranitelnosti.
Zajímavé je však to, ţe i kdyţ je plánování Business Continuity v sektoru terciárního vzdělávání
chápáno jako důleţité, oddělení informačních technologií obvykle nepřikládá těmto plánům velkou
-36/117-
prioritu, ale podporu Business Continuity vykonává spíše jako proces v pozadí. Důvodem je zejména
to, ţe instituce terciárního vzdělávání nejsou provozní společností, pro kterou by výpadek sluţeb
znamenal obrovské finanční ztráty nebo pro kterou by výpadek nutně znamenal úplné zastavení
činnosti. Tento fakt také svědčí o skutečnosti, ţe nutnost Business Continuity je sice chápána jako
nezbytná součást řízení instituce terciárního vzdělávání, není však včleněna hluboko do podnikové
kultury. Poněkud kontrastně na druhou stranu působí informace, ţe podle několika studií (např.
[Pirani2007]) si většina pracovníků napříč sektory nedokáţe Business Continuity bez funkčních IT
systémů představit. Lze proto říci, ţe zatímco kontinuita podniku je spojována se spolehlivě
fungujícími IT systémy, podpora ze strany IT toto nevidí jako prioritu.
Existuje několik faktorů, kvůli kterým by mohl vzrůst zájem o problematiku Business Continuity.
V následujícím textu jsou tyto faktory představeny, s důrazem na specifika sektoru terciárního
vzdělávání [Datamonitor2007]:



řada moţných rušivých událostí - i kdyţ přírodní katastrofy nejsou v České republice díky
geografické lokaci tak častým jevem, události jako prosakování vodovodního potrubí
a výpadky dodávky elektrického proudu jsou mnohem frekventovanější hrozbou pro udrţení
kontinuity podnikání,
vzrůstající závislost na IT - v případě, ţe by došlo k selhání centrální funkce IT, pro instituce
terciárního vzdělávání by bylo čím dál tím těţší pokračovat ve své činnosti, a to i pouze
částečně,
konkurenční tlak a povědomí o značce - ačkoli se můţe zdát, ţe u institucí terciárního
vzdělávání je poněkud nezvyklé hovořit o značce a procesu řízení značky, i tyto organizace si
musí zachovat svou pověst stability v případě krize, pokud chtějí přeţít.
Cílem plánu podnikové kontinuity je striktní dodrţování bezpečnostní politiky a politiky soukromí,
které platí v rámci celé instituce. Je důleţité si uvědomit, ţe tyto politiky a regulace musí být
dodrţovány i v situacích, kdy instituce provozuje svou činnost za mimořádných podmínek v dobách
krize.
Informační systémy jsou zranitelné vůči řadě narušujících událostí ve škále od mírných (např.
krátkodobý výpadek elektrického proudu, selhání harddisku) aţ po závaţné (např. zničení vybavení,
poţár). Některé zranitelnosti je podle [Vogel2010a] moţné odstranit pomocí technických či
operativních řešení, ale není moţné odstranit veškerá rizika.
Sníţení rizik pomocí plánování řešení nepředvídaných událostí spočívá spíše v zaměření se na
efektivní a účinná řešení pro obnovu systému. Mezi účinná opatření patří například určení klíčových
zaměstnanců, kteří by působili jako kontaktní osoby v případě, kdy nastane krize. Tito zaměstnanci
jsou následně odpovědní za řešení situace a za navrácení podniku do běţného chodu. Odpovědní
zaměstnanci jsou typicky určeni na několika úrovních, kdy na kaţdé úrovni vzniká krizový tým, který
je hierarchicky podřízen týmu umístěnému o úroveň výše.
Součástí seznamu kontaktních osob by měli být také zástupci pověřených osob, které by bylo moţné
kontaktovat v případě, ţe by pověřená osoba nebyla zastiţena. Samozřejmostí je vedle jmen dodání
také telefonních čísel či jiných kontaktních údajů.
Nejvýše umístěný tým je pak odpovědný nejvyššímu managementu společnosti/instituce a zajišťuje
reporting směrem nahoru k managementu, stejně tak jako předávání zpráv a delegování úkolů směrem
dolů na krizové týmy. Tento způsob uspořádání pro krizové situace je běţný v komerčním sektoru,
v sektoru terciárního vzdělávání se s ním však málokdy setkáme.
-37/117-
V plánu podnikové kontinuity by měly být popsány také jiţ existující metody zálohování a obnovy.
Do této problematiky také spadá testování existujícího záloţního prostředí, a to v následujících bodech
[Rittinghouse2005]:



zda záloţní prostředí obsahuje potřebnou infrastrukturu, vybavení, hardware, software
a komunikační prostředky,
zda je záloţní prostředí schopno zajistit plný provoz,
zda je v záloţním prostředí implementována stejná úroveň bezpečnostních opatření, jako je
tomu u provozního prostředí.
Plán podnikové kontinuity musí být sestaven na základě zváţení, zda je moţné určitou podnikovou
sluţbu obnovit v primárním provozním prostředí nebo zda je potřeba k obnově sluţby vyuţít prostředí
alternativní/záloţní.
Vytvoření takového alternativního prostředí je finančně relativně velmi nákladné. V případě institucí
terciárního vzdělávání by však takové prostředí mohlo být vytvořeno například na jiné domácí
univerzitě. Díky tomu, ţe univerzity a ostatní především výzkumné instituty jsou v České republice
propojeny vysokorychlostní akademickou sítí, bylo by moţné vytvářet záloţní prostředí bez dodatečné
investice na vybudování infrastruktury.
Plány Business Continuity jsou zaloţeny na ohodnocení rizik a na analýze dopadu a zahrnují proces
pravidelné údrţby včetně proškolování. [Vogel2010a] Pro sestavení BC plánu v podmínkách
konkrétní instituce by mělo být zodpovězeno, co se stane v případě, kdy nastanou určité podmínky,
které znesnadní běţný průchod procesem podle několika předem definovaných scénářů. Mezi takové
scénáře uveďme například [Gulachek2005]:
1. Není moţné dostat se do kanceláře, ale je moţné dostat se k datům.
2. Je moţné dostat se do kanceláře, ale není moţné dostat se k datům.
3. Ztráta klíčového zaměstnance (nemoc, smrt nebo jakákoli jiná příčina).
Z takto definovaných scénářů je následně moţné odvodit nápravná opatření, mezi která patří
zálohování záznamů a souborů a jejich ukládání mimo prostory kanceláře/budovy, vytvoření
telefonního seznamu kontaktů a jeho distribuce mezi zaměstnance a jmenování pověřeného zástupce
v případě, kdy by první kontakt ze seznamu nebyl z jakýchkoli důvodů k zastiţení.
Kaţdý plán podnikové kontinuity by se měl zaměřovat na naplnění základních elementů:





identifikace sluţeb, podnikových procesů, aplikací a podpůrných nástrojů (obchodní záznamy,
počítače, telefony atd.), které musí být udrţovány během výskytu narušující události,
identifikace sluţeb, procesů a aplikací, které nejsou kritické, a za určitých okolností můţe
dojít k přerušení jejich provozu. V rámci tohoto kroku je nutné definovat, jak dlouho je určité
oddělení schopno bez těchto sluţeb fungovat, a to včetně faktorů, které mají na tuto dobu
trvání vliv [Vogel2010a],
určení minimálního stavu zaměstnanců, dat, zařízení atd., který je nevyhnutelně potřebný
k zajištění klíčových funkcí a k zajištění obnovy,
udrţování aktuálního seznamu kontaktů se jmény a telefonními čísly klíčových zaměstnanců
společně s jejich odpovědností za obnovu běţné činnosti,
identifikace vzájemného vztahu plánu BC s operativními plány kontinuity ostatních oddělení.
Do tohoto kroku spadá zejména identifikace toho, která oddělení jsou na sobě vzájemně
závislá.
-38/117-

zajištění, ţe všichni zaměstnanci, kteří mají odpovědnost za udrţení podnikové kontinuity,
jsou pravidelně proškolování a připraveni reagovat na krizové situace.
K tomu, aby BCM mohl v instituci fungovat, je potřeba, aby jednotliví zaměstnanci, resp. jednotlivá
oddělení, pro které byl sestaven plán podnikové kontinuity, měli moţnost obrátit se na zastřešující
orgán, jehoţ odpovědností by bylo za mimořádných událostí zajistit obnovení běţného provozu
instituce.
Sestavením plánu Business Continuity je moţné dosáhnout několika pozitivních výstupů. Tyto
výstupy nejsou výlučně typické pouze pro sektor terciárního vzdělávání, mohou však pomoci instituci
lépe porozumět významu sestavení plánu BC. Tyto pozitivní výstupy jsou uvedeny v následujícím
seznamu [Gulachek2005]:






Návrh architektury a způsob zavedení nových sluţeb – nové sluţby a technologie jsou na
základě plánu navrţeny redundantně s implementací plánu obnovy a sníţení rizik jako součást
plánování Business Continuity.
Změna přístupu ke změnovému řízení – z poţadavků plánů Business Continuity vyplývá
potřeba zvýšeného počtu a úrovně dokumentace, která není v současné době u institucí
terciárního vzdělávání dostatečná.
Spokojenost a důvěra zákazníků – na základě definovaného plánu je moţné sledovat zvýšenou
spokojenost s klíčovými sluţbami ze strany studentů.
Spolehlivost sluţeb – na základě SLA mezi oddělením poskytujícím informační sluţby
a ostatními odděleními je zajištěna vyšší spolehlivost dostupnosti sluţeb.
Podpora technologických zdrojů pro naplnění plánů Business Continuity.
Upevnění komunikačního kanálu napříč celou organizací – samotná existence plánu Business
Continuity vyţaduje ustanovení plánu komunikace. Jak technické, tak administrativní
komponenty tohoto plánu vytváří nové kanály komunikace mezi odlišnými okruhy
zaměstnanců na několika úrovních. V případě institucí terciárního vzdělávání hovoříme
například o komunikaci mezi zaměstnanci nejen na úrovni jednotlivých kateder, ale také mezi
jednotlivými fakultami v rámci celé školy.
Význam údrţby a pravidelné revize plánu je zřejmý: zajistit aktuálnost plánu, a to včetně aktuálnosti
seznamu kontaktních osob a pověřených zástupců pro případ krize. V pravidelných intervalech by
mělo být realizováno také školení zaměstnanců instituce. Je-li plánování podnikové kontinuity
zakořeněno v samotné kultuře instituce, jsou pak nově příchozí zaměstnanci v této oblasti automaticky
proškolováni.
Lze uvést následující sadu obecných důsledků plánování Business Continuity s důrazem na sektor
terciárního vzdělávání [Gulachek2005]:

vrchní dozor – instituce terciárního vzdělávání musí zodpovědně spravovat svá data, a to
zejména v případech, kdy se podílí na veřejně financovaných projektech. Mezi techniky
Business Continuity patří zajištění informační bezpečnosti a pro ochranu, uchování a udrţení
vyuţitelnosti dat a systémů v případě krize existují specializované nástroje.
V případě, kdy se instituce podílí na výzkumu, nese tato instituce dodatečnou odpovědnost za
data výzkumu jako součást poţadavků stanovených v rámci grantu.

řízení – metodologie a přístupy k řízení technologie jsou v dnešní době klíčovým poţadavkem
v prostředí institucí. Do této oblasti patří například otázky změnového řízení, výměny nebo
upgrade klíčových serverů či síťových komponent, existence rollback plánu atd.
-39/117-



inovace – vývoj a správa technologií musí být natolik flexibilní, aby se mohly přizpůsobit
inovacím. Tato flexibilita je dána dvěma zásadami úspěšného BC plánování: spolehlivostí a
redundancí. Inovace pak musí splnit poţadavky Business Continuity, aby se mohla stát
součástí produkčního prostředí.
náklady – díky existenci plánů kontinuity je moţné rozumným plánováním sníţit náklady na
hardware a software.
spolupráce – příleţitosti pro sdílení zdrojů mezi institucemi plynou z existence současných
aktiv, lidského kapitálu a vazeb mezi institucemi. Strategické příleţitosti spolupráce umoţňují
institucím zlepšit své základní kompetence. Díky tomu můţe vzniknout partnerství umoţňující
vzniknout záloţním lokalitám Business Continuity pro obě strany navzájem. Tento inovativní
přístup vzniká na základě uvědomění si důleţitosti Business Continuity a strategické
důleţitosti účinného vyuţití aktiv.
4.3 POTENCIÁL CLOUD COMPUTINGU PRO SEKTOR TERCIÁRNÍHO VZDĚLÁVÁNÍ
Specialisté v oboru informačních technologií jsou skeptičtí k adopci Cloud Computingu v rámci své
společnosti. Výjimkou není ani oblast terciárního vzdělávání. Důvodem je jak typicky česká
nedůvěřivá povaha, tak nekonzistentní literatura, která slibuje výhody Cloud Computingu na jedné
straně a hovoří o bezpečnostních rizicích na straně druhé. Dalším důvodem je nekonzistence
v terminologii. Setkáme se s mnoha definicemi Cloud Computingu od dodavatelů, konzultačních
společností i od jednotlivců odborné informatické veřejnosti.
Nesporným důvodem ke skepsi odborníků je také to, ţe v minulosti se jiţ setkali s mnoha novými
koncepty, které slibovaly přínos něčeho nového a slibovaly také řadu benefitů (např. grid computing).
Cloud Computing se od ostatních nových konceptů v kontextu oblasti terciárního vzdělávání odlišuje
několika základními body [Katz2009]:

První odlišností je odlišnost tohoto konceptu po technické stránce. U Cloud Computingu se
setkáme s řadou vyspělých standardů umoţňujících standardizovanou komunikaci mezi
oběma stranami. Mezi další technické charakteristiky patří rozšíření vysokokapacitní sítě,
rozšíření konceptu virtualizace, dostupnost aplikací apod.
To, ţe se Cloud Computing mohl jako koncept objevit a rozvinout právě v poslední dekádě,
vychází z několika technických předpokladů [Svoboda2009]. Mezi tyto předpoklady patří
právě vysokorychlostní síť, která je v dnešní době jiţ samozřejmostí prakticky všech firem.
U institucí terciárního vzdělávání je taková vysokorychlostní síť zajištěna akademickou sítí,
která například u nás patří k nejrychlejším sítím v České republice vůbec.

Dalším předpokladem vedoucím k rostoucí popularitě Cloud Computingu je také výpočetní
výkon procesorů, kapacita diskových polí či datových center. Současně se rozšiřuje také
koncept virtualizace, díky kterému je moţné dosahovat značných finančních úspor, a to jak
u virtualizace serverové, tak virtualizace desktopů.
Zejména desktopová virtualizace v oblasti vzdělávání přináší nesporně řadu výhod.
[Zahorova2010], [CIO2010] Protoţe jsou to právě školy, které potřebují vybavovat učebny
mnoţstvím počítačů, na jejichţ pořízení a údrţbu mnohdy nezbývají finanční prostředky
a navíc na těchto počítačích je zapotřebí stejná konfigurace a instalace aplikací. Není proto nic
snazšího, neţ na jednotlivé koncové stanice aplikovat jednu image operačního systému.
Zjednoduší se tím správa koncových stanic a dojde také ke sníţení nákladů na nové vybavení
učeben.
-40/117-

Generace, která vyrůstala na širokopásmovém připojení k internetu, v prostředí sociálních sítí
a která zvyšuje počty prodejů netbooků, hledá právě taková řešení, která by jim poskytovala
moţnost ulehčit svým nízkonákladovým zařízením a umoţnila jim přesunout výpočetní
kapacitu na servery poskytovatelů.
Tito uţivatelé toto řešení vyhledávají jiţ dnes ve svém soukromém ţivotě a pro většinu
aplikací vyuţívají internetový prohlíţeč jako uţivatelské rozhraní. Mezi takové uţivatele patří
především studenti a ti jsou zákazníky vysokých škol a univerzit, a jsou proto uţivateli sluţeb
poskytovaných institucemi terciárního vzdělávání.
Vedle výhod jmenovaných výše nabízí Cloud Computing také další prospěch, kterým je moţnost
regulace poskytovaných sluţeb dle sezónnosti. Uveďme příklad květinářství, které poskytuje své
sluţby mimo jiné online a největší zatíţení internetového obchodu zaţívá na svátky jako je Den matek,
případně Den ţen či svátek Svatého Valentýna, zatímco v ostatních dnech není zatíţení internetové
aplikace tak vysoké. V takovém případě je výhodné vyuţívat Cloud Computingu k nastavení optimální
infrastruktury, neboť zatíţení je dopředu předvídatelné.
Stejně dopředu předvídatelné zatíţení můţeme sledovat i u institucí terciárního vzdělávání v době
státních zkoušek, zápisů předmětů na začátku semestru, přihlašování na zkoušky apod. Tento způsob
zajištění potřebné infrastruktury v případě potřeby je velmi efektivním způsobem sníţení nákladů na
infrastrukturu.
Veřejné cloudy poskytované firmami jako je IBM, Google nebo Amazon jsou vhodné pro takové
sluţby, které neodlišují danou instituci od institucí konkurenčních nebo které nejsou těsně spojeny
s prvky, které instituci diferencují a poskytují jí konkurenční výhodu.
V případě, kdy daná činnost přidává instituci unikátní hodnotu, je vhodné vyuţívat privátních cloudů.
Tyto cloudy umoţňují alespoň částečně sníţit náklady na IT, a to díky konsolidaci aktiv
prostřednictvím virtualizace. Jak jiţ bylo zmíněno výše, virtualizaci je moţné realizovat na několika
úrovních, ať uţ se jedná o koncové stanice uţivatelů nebo o servery.
Nedostatek důvěry v cloudové sluţby má zcela jistě mnoho příčin. Mezi ty nejčastější příčiny společné
jak pro komerční sektor, tak pro sektor terciárního vzdělávání, patří [Katz2009]:





nedostatečně definované nebo zcela chybějící SLA,
nedostatečné řízení rizik,
nejasně definované ROI,
nevyspělost trhu,
problémy plynoucí z managementu společnosti.
V sektoru terciárního vzdělávání se setkáme s obdobnými příčinami, které jsou dále zatíţeny
dodatečnými obavami ze ztráty důvěry veřejnosti, a to podle [Educause2010] především u institucí,
které se věnují výzkumu např. lidského organismu či jadernému výzkumu. Instituce terciárního
vzdělávání se rovněţ obávají ztráty své konkurenceschopnosti, a to jak na domácím trhu, tak
i v kontextu mezinárodním.
V sektoru terciárního vzdělávání jsou z pohledu cloudových sluţeb patrné rysy, které lze shrnout do
následujících bodů [Katz2009]:

Instituce terciárního vzdělávání jsou zatíţeny několika aspekty, které by mohly potenciálně
zpomalit adopci Cloud Computingu. Mezi sporné otázky patří audity instituce, které podléhají
ministerstvu školství nebo ochrana dat výzkumu, neboť výzkum je důleţitou business oblastí
terciárního vzdělávání.
-41/117-




Odlišné činnosti budou přesouvány do cloudu s odlišnou rychlostí – sluţby, které by bylo
moţné umístit do cloudu v rámci institucí terciárního vzdělávání, můţeme rozdělit do tří
kategorií:
- sluţby, které překrývají komerčně poskytované sluţby (např. emailové schránky,
VoIP, telefony) – tato oblast bude pravděpodobně růst pro vyuţití cloudových sluţeb,
- aplikace, které instituce potřebují pro řízení své organizace (ERP) – tato oblast je
řízena poměrně silnou regulací a její růst a případný přesun do cloudu bude pomalý,
- aplikace vyuţívané pro výzkumnou činnost – tato oblast je jiţ nyní virtualizována
(vzdálená správa, superpočítače…).
Některé instituce se mohou stát poskytovateli cloudových sluţeb – v dnešní době se setkáme
s řadou organizací, které se snaţí odpovědět si na otázku, zda by se oni sami nemohli stát
poskytovateli cloudových sluţeb. Tato moţnost není vyloučena ani u institucí terciárního
vzdělávání, neboť tyto instituce zpravidla disponují dostatečně výkonnou infrastrukturou,
která není plně vyuţívána, a zároveň by se měly naučit chovat více trţně. Silné jméno instituce
by také mohlo zajistit zisk širokého portfolia zákazníků.
Obecně platí, ţe přesun sluţeb do cloudu, které jsou nové, nebo o které vzrostl nově zájem, je
rychlejší neţ přesun jiţ existujících sluţeb. V oblasti terciárního vzdělávání je poptávka po
sluţbách velmi proměnlivá, neboť je vyvolávána jak ze strany studentů, kteří se kaţdý rok
obměňují (u komerčních institucí tak rychlá cirkulace uţivatel sluţeb není běţná), tak i ze
strany vyučujících obnovujících osnovy vyučovaných předmětů.
Jestliţe instituce terciárního vzdělávání nevytvoří ţádnou cloudovou strategii, můţe se stát, ţe
uţivatelé, kteří začnou sami vyuţívat cloudové sluţby, tímto způsobem instituci přivedou do
cloudu i bez vedení organizace jako takové. Jak jiţ bylo několikrát uvedeno výše, studenti
patří mezi skupinu uţivatelů, u kterých je pravděpodobné očekávat zvýšený zájem o cloudové
sluţby (viz kapitola 4.3.2).
4.3.1 KTERÉ SLUŽBY PŘESUNOUT DO CLOUDU A KDY
Základní otázkou, kterou si instituce terciárního vzdělávání musí poloţit, je rozhodnutí, které sluţby je
vhodné přesunout do cloudu a kdy. Je důleţité zdůvodnit, proč by daná sluţba měla být přesunuta do
cloudu a zhodnotit takové rozhodnutí z hlediska ušetřených nákladů a sníţení pracovních míst. Podle
[Educause2010] by měla instituce terciárního vzdělávání podstoupit následující čtyři kroky:




Provést analýzu dopadu – instituce by měly zhodnotit svá data podle úrovně důleţitosti
a citlivosti, aby tak určily, které sluţby přináší instituci odlišnost a které sluţby by naopak
mohly být snadno přesunuty do cloudu.
Ustanovit kontrolu sluţeb, budovat důvěru a implementovat bezpečnostní modely –
porozumět rizikům jednotlivých procesů za účelem tvorby rozhodnutí o úrovni garance
sluţby.
Vycházet ze stávajících modelů zajištění sluţeb a přidat dodatečná kritéria pro Cloud
Computing – revizí sluţeb instituce a modelů, jakými jsou sluţby zajišťovány, zjistí instituce,
jakým způsobem by tyto sluţby mohly být poskytovány v rámci cloudu.
Před podepsáním smlouvy o poskytování sluţby s dodavatelem ověřit, zda bude v budoucnu
případně moţné poskytovatele změnit. Stejně tak je vhodné si předem zjistit, zda by bylo
moţné sluţbu případně opět poskytovat interně.
-42/117-
I kdyţ se společnost rozhodne změnit strukturu podnikových procesů, samotná reorganizace by
neměla být hlavním důvodem k implementaci konceptu Cloud Computingu. Setkáme se s mnoha cíli
cloudových sluţeb, které by bylo vhodné zváţit dříve, neţ dojde k přesunu sluţby do cloudu. Lze
uvést několik předpokladů pro přesun sluţby [Educause2010]:





Sluţba není pevně svázána s businessem - lze obecně říci, ţe čím je sluţba spjatější
s podstatou podniku, tím obtíţnější (a pravděpodobně také méně lákavé) je její přesunutí do
cloudu. Samotná otázka, zda sluţbu přesunout do cloudu, však není jednoduchá. Zpravidla
nejjednodušší rozhodnutí bývají učiněna v případě, kdy se jedná o nové potřeby, které dosud
nebyly naplněny stávajícími sluţbami, nebo se naopak jedná o nové sluţby, které doposud
nebyly začleněny do podnikových procesů.
Vysoké riziko ROI - jedním z často zmiňovaných témat se stává úloţiště dat v rámci cloudu
a nebo na cloudu zaloţený supercomputing. Zatímco předmětem zájmu se často stává
bezpečnost a zachování soukromí dat, skrývá Cloud Computing pro tyto potřeby skutečné
výhody v podobě sníţení nákladů z důvodu kompenzace vysokých nákladů na uţívání
a eliminace značných výdajů na výstavbu a údrţbu datových center.
Sluţby nesoucí nízké riziko - obdobně jako s kaţdým novým a relativně neodzkoušeným
projektem, i v případě cloudu je vhodné přesouvat jako první ty sluţby, které nenesou velké
riziko v případě, kdy se ocitnou mimo instituci. Z takového porovnání sluţeb vyplývá, ţe
např. plně integrovaný ERP systém není vhodným kandidátem pro první zkušenosti
s cloudovými sluţbami. I kdyţ tento fakt se zdá být jasným, mnoho společností začíná svou
zkušenost s cloudovými sluţbami právě přesunem svého ERP systému.
Prioritizace cloudu - prioritizace se netýká výhradně toho, kterou technologii je vhodné jako
první přemístit do cloudu, ale toho, jak velkým výzvám čelí celé odvětví (v tomto případě
terciární vzdělávání) a do jaké míry je moţné trend budoucího směřování institucí terciárního
vzdělávání tímto ovlivnit.
Důvěra - předpokladem úspěšného fungování cloudového partnerství je vzájemná důvěra obou
participujících. Vedle důvěry je důleţitým předpokladem také spojitost sluţby a rychlá reakční
doba ze strany poskytovatele.
4.3.2 FENOMÉN „CONSUMERIZACE“ A SDÍLENÍ OBSAHU
V literatuře se v dnešní době často setkáme s pojmem "consumerizace" (orig. consumerization, viz
např. [Bittman2008]). Tento termín se vztahuje k trendu, kdy uţivatel začne s pouţíváním určité
informatické sluţby ve svém soukromém ţivotě, oblíbí si ji a přinese ji do svého profesního ţivota.
Právě tento trend je dobře patrný v sektoru terciárního vzdělávání, především z důvodu podstatného
vlivu studentů, kteří rádi vyuţívají cloudových sluţeb, a to jednak z důvodu pouţívání netbooků či
mobilních zařízení, která nejsou natolik výkonná, aby mohla hostovat vlastní aplikaci a jednak
z důvodu okamţitého přístupu k datům z několika přístupových zařízení.
Princip consumerizace lze dobře pozorovat také na fenoménu sociálních sítí. Ty byly zpočátku
vyuţívány především pro soukromé účely, s postupem času se dostaly do profesionální sféry a dnes jiţ
nikoho nepřekvapí, kolik informací o instituci je snadno k nalezení na stránkách sociální sítě a jak je
mnohdy obtíţné najít obdobné informace na klasických internetových stránkách.
V dnešní době roste objem obsahu, který je ukládán na nejrůznějších místech internetu, výjimku
netvoří ani sociální sítě. Se vznikem konceptu Web 2.0 je obsah na internetu stále více interaktivní
a zároveň takto uţivatelem vytvořený obsah má jednu klíčovou vlastnost - ţivotnost. Podle
[Bittman2008] je ţivotnost takového díla ve své podstatě neomezená. Zároveň získal takto vytvořený
-43/117-
obsah velký vliv v široké komunitě uţivatelů internetu. Vznikly nové aspekty ochrany díla a částečně
byly díky sdílení tvorby mezi uţivateli smyty některé otázky plagiátorství.
4.3.3 VYUŽITÍ CLOUD COMPUTINGU PRO KOMUNIKACI
Nejrozšířenějším konceptem poskytovaných cloudových sluţeb jsou nástroje pro kolaboraci uvnitř
týmů, především nástroje pro komunikaci a sdílení souborů.
Prostředky pro komunikaci jsou přirozeně vhodné pro cloudový přístup, neboť jsou téměř všechny
závislé na jedné infrastruktuře, kterou je internet. Mezi tyto komunikační prostředky patří emailová
komunikace a zasílání zpráv pomocí tzv. instant messagingu.
Vyuţívání komunikace poskytované prostřednictvím cloudu nese pro instituci řadu výhod. Výhody
spočívají nejen v zajištění fungujících emailových sluţeb i v případě, ţe instituce je narušena
neočekávanou událostí, ale také v tom, ţe společnost velmi výrazně ulehčí své vlastní technologické
infrastruktuře. Správa emailových sluţeb ve vlastní organizaci spotřebovává nemalé mnoţství zdrojů,
ve většině případů patří dle [Gatewood2009] mezi ty největší konzumenty technologie.
V prostředí terciárního vzdělávání se setkáme také s otázkou, zda mají být sluţby agregovány či
nikoli. Tato otázka je výchozím bodem pro rozhodování, jakým způsobem by měly být sluţby v rámci
univerzity zajišťovány. V některých případech jsou zajišťovány jedním oddělením a poskytovány
podle potřeby, v jiných případech jsou zajišťovány prostřednictvím agregace. Jako příklad lze uvést
emailové sluţby, které bývají často agregovány. Tím je umoţněno univerzitám sníţit náklady na
provoz společné platformy pro ty uţivatele, kteří se pohybují mezi jednotlivými pracovišti
a katedrami.
Naopak sluţby, které jsou specifické pro určitou znalostní oblast nebo pro určitou skupinu
zaměstnanců podle [Mitrano2010] agregovány zpravidla nejsou, a jsou proto poskytovány na místní
úrovni.
Sdílení souborů poskytované prostřednictvím cloudu je dalším typem aplikace, která byla dle
[Gatewood2009] nabízena ve formě cloudu mezi prvními. Řešení pro sdílení souborů se liší
v závislosti na typu úkolu, který má taková aplikace řešit. Můţe se jednat o ad hoc vytvářená úloţiště,
ale můţe to být také velmi specifické řešení určené pro definovanou podnikovou jednotku či oddělení.
4.4 NAPLNĚNÍ PODMÍNEK BCM NA CLOUD COMPUTING ŘEŠENÍ
V kapitole 3 Vazba Cloud Computingu na Business Continuity Management jsou uvedeny tři
poţadavky a jeden předpoklad, které klade BCM na řešení Cloud Computingu. V následujícím textu je
nejprve vysvětlen předpoklad řízení rizik v kontextu problematiky institucí terciárního vzdělávání,
poté následuje popis jednotlivých poţadavků P01 - P03.
4.4.1 PŘEDPOKLAD – ŘÍZENÍ RIZIK
K tomu, aby instituce rozhodla, zda je vhodné určitou sluţbu přesouvat do cloudu, je nutné, aby byl
kladen důraz na řízení rizik. V rámci tohoto procesu je nejprve nutné provést základní test. Tento test
spočívá v následujícím postupu [Mitrano2010]:
Po provedení cost-benefit analýzy (porovnání nákladů a přínosů) a analýzy vhodnosti (posouzení
dopadu na uţivatele, zaměstnance, zajištění IT atd.) je třeba zváţit, zda sluţba, která má být přesunuta
do cloudu, nenaruší schopnost podniku řídit sluţby, které podporují jeho klíčové procesy. Toto riziko
by mělo být řešeno jak z hlediska sluţby samotné, tak z hlediska vlivu na ostatní sluţby, které buď
byly přesunuty do cloudu, nebo které zůstávají v prostředí instituce.
-44/117-
Proces řízení rizik je stejně důleţitý jako samotné odpovědi, které by měly být jeho výstupem. Tento
proces mnohé vypovídá o koordinaci myšlení vyššího managementu instituce. Je nezbytné, aby proces
řízení rizik byl v instituci vybudován a řízen. Nutnost tohoto procesu můţe být ustanovena také
v politice upravující správu cloudových sluţeb, neboť je nutné, aby rizika byla řízena nejen z pohledu
jedné cloudové sluţby, ale také z pohledu celku.
4.4.2 POŽADAVEK P01 BEZPEČNOST A MONITORING
V následujícím textu je uvedeno osm nejdůleţitějších sporných otázek týkajících se bezpečnosti, které
by měly být předmětem jednání před adopcí jakékoli cloudové sluţby v sektoru terciárního
vzdělávání. [Vogel2010b] [Mitrano2010]:

Důvěrnost dat a zajištění soukromí – instituce terciárního vzdělávání mají povinnost chránit data
týkající se např. studentů a výzkumu. I kdyţ za data umístěná u poskytovatele odpovídá sám
poskytovatel, je odpovědností instituce samotné zajistit takové smluvní podmínky, které by
zaručovaly dostatečnou ochranu. Do dnešního dne stále platí, ţe přesunutí citlivých dat do cloudu
znamená vznik potenciálně nového rizika. Těmito daty se v případě pohledu ze strany studenta
rozumí:
- data, která mají přímý vztah ke studentovi
- data, která jsou udrţována vzdělávací institucí.
a) předpisy – na základě smlouvy je po instituci vyţadováno dodrţovat všechny právní,
technické a další poţadavky,
b) krádeţ identity – instituce by měly mít nastaven proces, jak se vypořádat se situací v případě
narušení, a to především ohledně otázek, kdo je povinen koho informovat o vzniklé situaci.
Dalšími body procesu by mělo být testování narušení, určení technických kritérií pro
ohodnocení a identifikace entity odpovědné za notifikaci a následný postup za účelem řešení
vzniklé situace.
c) soukromí uţivatelů – v prostředí Cloud Computingu, kdy jsou některé důvěrné informace
poskytovány třetí straně, je povinností kaţdé instituce zajistit, aby veškeré poskytované
informace byly důvěrné, a nedocházelo tak k narušení soukromí uţivatelů.
Jako příklad lze uvést model SaaS, konkrétně vyuţívání emailových sluţeb od poskytovatele
Google. Je známo, ţe společnost Google vyuţívá nad přijímanými a odesílanými zprávami
data mining, na základě kterého je pak schopna nabízet uţivateli kontextovou reklamu. I kdyţ
se společnost odvolává na to, ţe data mining probíhá zcela automatizovaně a anonymně, je
třeba zváţit jisté bezpečnostní aspekty, mezi které patří např.:


informace o tom, jaké techniky anonymizace, která odděluje uţivatele od získaných
dat, jsou pouţívány,
 zda společnost provádí data mining na základě klíčových slov či celých dotazů,
 zda společnost spojuje/nespojuje tyto dotazy s jednotlivými uţivateli,
 jakým způsobem společnost s takto získanými daty nakládá a jak zajišťuje jejich
bezpečnost,
 zda společnost neprodává získané informace,
 jak dlouho udrţuje takto získaná data,
 k jakým účelům jsou tato data pouţívána,
 zda se společnost zavazuje tato data po určitém časovém okamţiku smazat.
Prolomení důvěrnosti dat a jejich bezpečnost
- pokud třetí osoba pronikne jakýmkoli způsobem k důvěrným datům, nese instituce
terciárního vzdělávání primární odpovědnost za oznámení, ţe k takové situaci došlo,
-45/117-
do této kategorie také spadají rizika spojená s duševním vlastnictvím - autorizace a
duševní vlastnictví v drţení třetí stranou.
E-discovery – instituce by měla nejprve provést tzv. cost-benefit analýzu, tedy porovnat náklady
a přínosy řešení ještě předtím, neţ začne samotné vyjednávání podmínek s poskytovatelem. Je
důleţité do analýzy zahrnout celé portfolio sluţeb odebíraných od poskytovatelů a porovnat
takové portfolio s jakýmikoli technickými či procesními přístupy, které jsou v instituci
uplatňovány. Výsledkem této analýzy jsou doporučení, do kterých oblastí by instituce měla více
investovat (např. zvýšit výdaje na zálohování systémů a dat, na školení dotčených stran apod.).
Service Level Agreement – instituce musí trvat na tom, aby byly jasně definovány úrovně
poskytování sluţeb. Je potřeba určit, kolik času obě strany vyţadují k tomu, aby byla smlouva
SLA implementována, a jaké existují pokuty v případě, kdy nebude stanovená úroveň sluţby
dodrţena.
Pozastavení/přerušení smlouvy – instituce by si měla předem zjistit, jak jsou stanoveny podmínky
pro případ, kdy by se rozhodla pozastavit nebo přerušit dohodu o poskytování sluţeb. Je také
nutné zváţit, kolik času by instituce v takovém případě potřebovala, aby mohla sluţby opět sama
poskytovat nebo aby mohla změnit externího poskytovatele. Další otázkou, kterou je nutné
zohlednit, je skutečnost, co se stane s daty instituce poté, co dojde k pozastavení nebo přerušení
smlouvy s poskytovatelem. Na základě těchto úvah by potom měla být sestavena smlouva
o odebírání sluţeb.
Ohodnocení rizik – v této oblasti by měly být zvaţovány především následující skutečnosti:
- odškodnění – odškodnění by mělo být zohledněno jak z pohledu odebírající instituce, tak
z pohledu poskytovatele,
- záruky – záruky vyplývají především ze stanovených Service Level Agreeements,
- odpovědnost za koncové uţivatele – v uzavírané smlouvě musí dojít k přesnému
definování toho, kdy a v kterých situacích kdo nese odpovědnost za koncové uţivatele,
- porušení patentu – před uzavřením smlouvy by se instituce měla přesvědčit, zda procesy,
postupy či zdroje jsou skutečně vlastněny poskytovatelem a zda nedochází k ţádnému
střetu zájmů, který by v budoucnosti mohl ohrozit data instituce,
- přenos rizik – v rámci sestavení SLA by mělo být definováno mimo jiné také to, zda jsou
určitá rizika přenášena z odběratele na dodavatele a naopak. V případě, kdy by nastala
neočekávaná situace, musí být jasně definováno, kdo je za tuto situaci odpovědný,
- politiky a metody – pro určité oblasti by měly být definovány určité politiky, např. pro
produkty, které uchovávají citlivá uţivatelská data, by mělo být provedeno ohodnocení
rizik. Toto ohodnocení by mělo být podchyceno v politice.
Business Continuity – do oblasti Business Continuity patří otázky týkající se sestavení Service
Level Agreement, kde by mělo být podchyceno, jakým způsobem má instituce k datům přístup, co
se stane v případě výpadku sluţby a kdy dojde k obnovení sluţby apod. Dále do oblasti Business
Continuity patří také záleţitosti týkající se pozastavení/přerušení smlouvy s dodavatelem (viz
výše).
Právní otázky a závazky třetích stran – poskytovatelé cloudových sluţeb si ze smlouvy volí svou
vlastní jurisdikci. Je však vhodné tento přístup eliminovat a smlouvu uzavřít spíše podle
existujících právních ustanovení.
-






Do této oblasti lze zahrnout také právní úpravu týkající se grantů se zvláštními právními
podmínkami.
-46/117-
4.4.3 POŽADAVEK P02 ZÁLOHOVÁNÍ A ARCHIVACE
Zálohování a archivace patří k důleţitým poţadavkům Business Continuity. Protoţe instituce
terciárního vzdělávání jsou velkými institucemi, lze předpokládat, ţe objem dat nutných k obnovení
v případě krize bude značně velký. Díky rozšíření konceptu virtualizace je však moţné dnes zálohovat
celé image nakoupených serverových instancí stejně jednoduše, jako je moţné zálohovat běţné
soubory.
Vedle zálohování poskytuje Cloud Computing také snazší řešení pro zajištění záloţního prostředí.
Díky Cloud Computingu instituce získá znatelně levnější alternativu k běţně pouţívaným prostředím
v komerčním sektoru typu hot site, cold site, mirrored site apod., které nejsou v oblasti terciárního
vzdělávání běţně vyuţívány.
V takovém případě stačí pouze replikovat data do záloţního prostředí a začít platit za vyuţívání tohoto
prostředí aţ skutečně v okamţiku, kdy nelze pouţívat prostředí primární. Samotná replikace dat můţe
probíhat na několika úrovních. Běţnou replikací je replikace na úrovni diskových polí.
4.4.4 POŽADAVEK P03 DOSTUPNOST SLUŽEB
Studenti jsou specifickou skupinou zákazníků/uţivatelů informačního systému a konzumentů sluţeb,
které jim instituce terciárního vzdělávání poskytuje. Postupem času se bude jednat o generaci, která
vyrostla na širokopásmovém připojení k internetu a která snadno a rychle adoptuje nové koncepty.
Mezi tyto koncepty patří například sdílení souborů, komunikace mezi členy týmu nebo fenomén
sociální sítě.
Vyuţitím Cloud Computingu získá instituce nespornou výhodu. Tím, ţe vyuţije cloudovou platformu,
získá tak prostředí, ve kterém lze snadno integrovat běţně pouţívané aplikace, neboť tyto aplikace
budou s postupem času stále častěji vyvíjeny pro potřeby Cloud Computingu, a to i zástupci z řad
studentů.
Tato skupina uţivatelů také klade vysoké nároky na dostupnost IT systémů instituce. Pro instituci je
proto nejlepší, kdyţ jsou její systémy vysoce dostupné. Není však nutností, aby se o nepřetrţitý provoz
systémů a aplikací starala sama instituce, ale je moţné vyuţívat sluţeb cloudových poskytovatelů,
kteří by vysokou dostupnost automaticky zajišťovali.
4.5 DALŠÍ CHARAKTERISTIKY SEKTORU
COMPUTINGU JAKO NÁSTROJE BCM
TERCIÁRNÍHO VZDĚLÁVÁNÍ PRO VYUŽITÍ
CLOUD
V případě institucí terciárního vzdělávání se vedle výše uvedených poţadavků setkáme také s řadou
specifik, pro která je moţné vyuţít konceptu Cloud Computingu za současného přispění ke zlepšení
Business Continuity. Tyto charakteristické rysy jsou představeny v následujícím textu.
4.5.1 SP01 SEZÓNNOST
Provoz IT systémů institucí terciárního vzdělávání se vyznačuje charakteristickou sezónností, kdy
dochází k nerovnoměrnému zatíţení informačních systémů v průběhu akademického roku. První
skutečnost platí pro celý sektor školství. Je jí období letních prázdnin. IT systémy jsou tak v průběhu
července a srpna vytíţeny daleko méně neţ ve zbytku akademického roku.
Opakem, kdy jsou IT systémy naopak vytíţeny hodně a v některých případech i přetíţeny, jsou období
přihlašování studentů na zkoušky, období promocí, období registrací předmětů apod.
Tyto výkyvy je moţno účinně řešit prostřednictvím Cloud Computingu a dopředu zajistit vyšší
kapacitu infrastruktury právě pro tato období. Instituce by tak nemusela vydávat vyšší výdaje na
-47/117-
dodatečné technologické zdroje a současně by uspokojila poptávku ze strany studentů a zaměstnanců
školy.
4.5.2 SP02 ZÁVISLOST NA IT
U institucí terciárního vzdělávání je velmi patrný nárůst postupné závislosti na IT technologiích.
Oproti společnostem komerčního sektoru je na instituce terciárního vzdělávání kladen větší tlak na
nákup kvalitního IT vybavení jak pro výuku, tak i do počítačových studoven pro studenty. Výjimkou
není ani pořizování nejnovější techniky do laboratoří nebo pracovišť s multimédii.
Z tohoto důvodu by kaţdá instituce měla zvaţovat, zda není moţné šetřit na místech, kde to lze.
Jednou z takových moţností je Cloud Computing, kdy například díky modelu Infrastructure-as-aService je instituci umoţněno ušetřit na technologické infrastruktuře a vyuţívat modelu
virtualizovaných serverů, na kterých běţí samotné aplikace instituce.
4.5.3 SP03 KONKURENČNÍ TLAK
Ani instituce terciárního vzdělávání nejsou výjimkou, i v tomto oboru panuje vysoká konkurence.
Především v posledních několika letech s nárůstem soukromých vysokých škol a se vzrůstajícím
zájmem studentů středních škol pokračovat ve svém vzdělávání na vysoké škole, je cílem kaţdé
univerzity získat pro sebe „ty nejlepší“ studenty, a vychovávat tak elitu.
Díky tomuto konkurenčnímu tlaku rostou výdaje na potřebné vybavení a na výstavbu nových
budov/učeben/zařízení tak, aby instituce mohly konkurovat v boji o nové studenty. Skrze Cloud
Computing je instituce schopna ušetřit v nákladech na IT infrastrukturu (viz výše).
4.5.4 SP04 INOVACE
Instituce terciárního vzdělávání by měly jít příkladem v inovacích ostatním odvětvím ekonomiky.
Není tomu tak bohuţel u českého školství, ale ve světě lze nalézt mnoho případů, kdy univerzity, které
disponují řadou nadprůměrně chytrých studentů, jsou také předními inovátory ve společnosti.
Stejně tak by univerzity měly vytvářet prostředí pro to, aby se inovativní myšlenky mohly dále
rozvíjet. Pro tyto účely je koncept Cloud Computingu otevřený.
-48/117-
5 POTENCIÁL BCM A CLOUD COMPUTINGU V PODMÍNKÁCH VŠE PRAHA
Tato kapitola navazuje na závěry předchozích kapitol, bere v úvahu specifika prostředí Vysoké školy
ekonomické v Praze a hledá nejvhodnější Cloud Computing řešení, která by zároveň přispívala ke
zlepšení Business Continuity. Z tohoto důvodu jsou v této kapitole postupně podrobněji představeny
koncepty Infrastruktura jako sluţba, virtualizace a tvorba privátních cloudů. Kombinace těchto
přístupů můţe instituci přinést řadu výhod, neboť tento koncept slibuje revoluci v poskytování
distribuovaných softwarových sluţeb. [Konstantinou2009] Díky souboru rozhraní, která jsou
poskytována IaaS cloudy, jsou řízeny virtuální stroje, a dochází tak k podstatnému sníţení
komplexnosti zajišťování sluţeb.
5.1 POPIS SOUČASNÉHO STAVU
Prvním krokem k rozpoznání současného stavu na Vysoké škole ekonomické (dále jen VŠE) je
identifikace uţivatelů IS/ICT. Mezi uţivatele patří následující skupiny [VSE2010]:









studenti,
potenciální studenti,
účastníci celoţivotního vzdělávání,
management VŠE, managementy fakult,
učitelé,
vědečtí pracovníci,
administrativní pracovníci,
externí uţivatelé knihovny,
absolventi VŠE.
Správa IS/ICT je na VŠE soustředěna do několika útvarů. Hlavním útvarem je Výpočetní centrum (viz
kapitola 5.1.3) a Centrum informačních a knihovnických sluţeb CIKS. CIKS zajišťuje informační
podporu výuky, vědy a výzkumu na VŠE. Tento útvar řeší především otázky týkající se analýzy
informačních potřeb všech cílových skupin VŠE. CIKS je hlavním útvarem, který podporuje vědeckou
činnost na VŠE. CIKS dále spolupracuje s Výpočetním centrem VŠE v napojení informačních
systémů CIKS na informační systém školy. Zároveň se CIKS podílí na tvorbě a realizaci informační
strategie VŠE.
5.1.1 SWOT ANALÝZA
Pro informatické útvary byla vypracována SWOT analýza. Tato analýza je uvedena v Příloha A –
SWOT analýza informatických útvarů. Ze SWOT analýzy jsou dobře patrné slabé stránky VŠE
a příleţitosti. V následujícím textu bude mimo jiné brán zřetel na minimalizaci slabých stránek pomocí
maximalizace vyuţití příleţitostí. V rámci SWOT analýzy byly definovány tyto charakteristiky
[VSE2010]:

silné stránky
- výsledky dosaţené v minulých letech – do této oblasti spadá implementace studijního
informačního systému ISIS, nová organizace a nové sluţby v rámci webhostingu,
stoprocentní pokrytí areálu VŠE bezdrátovou sítí, podpora pouţívání mobilních
telefonů a datových sluţeb přes mobilní operátory,
- stabilní prostředí s velkou společenskou prestiţí,
- dobré jméno a prestiţ CIKS ve vědecké komunitě,
- velmi dobré hodnocení WWW stránek školy na mezinárodní úrovni.
-49/117-



slabé stránky
- platové podmínky v resortu školství,
- neexistence procesů pro řízení informatiky ve všech oblastech,
- roztříštěnost technického a programového vybavení,
- absence jednotného systému pro řízení identit (IAM),
- neexistence nástrojů pro zvýšení spolupráce pedagogů a vědeckých pracovníků.
příleţitosti
- získávat zdroje financování pro velké koncepční investice z fondů rozvojových
projektů a grantů vypisovaných MŠMT, CESNET apod.,
- rozvíjet zkušenosti a odborné znalosti v rámci spolupráce se zahraničními
univerzitami,
- vyuţívat sluţeb CESNET, PASNET a EUNIS,
- vyuţívat slev pro školy,
- zapojení do konsorciálních projektů na informační zdroje.
hrozby
- zaostávání za českým i celosvětovým vývojem způsobené poklesem investic do
IS/ICT,
- problémy se získáváním kvalifikovaných pracovních sil z důvodu limitujícího
systému odměňování,
- zastarávání informačních technologií, které můţe vést ke sníţení kvality
poskytovaných sluţeb,
- neuváţený, neefektivní outsourcing,
- pořizování licencí a sluţeb za úplatu se závazkem dalších pravidelných plateb za
údrţbu,
- konec systému financování elektronických informačních zdrojů prostřednictvím
programů MŠMT v roce 2011,
- rozsáhlost a specifičnost studijního informačního systému.
5.1.2 PROCESNÍ MAPA VŠE
Na VŠE jsou v současné době podle [Trcka2009] aktivity zajišťovány pomocí pěti klíčových procesů,
z nichţ jeden zastřešuje čtyři zbývající. Vedle těchto hlavních procesů instituce řídí dalších šest
procesů podpůrných. Procesy zajištění výuky na VŠE jsou znázorněny na Obr. 8.
Náplň jednotlivých procesů lze popsat takto [Trcka2009]:
Klíčové procesy:

Strategický rozvoj VŠE – tento proces zastřešuje ostatní klíčové procesy, jeho cílem je analýza
stavu a dalšího moţného rozvoje ostatních procesů.
o Zajištění studia – tento proces zajišťuje studijní proces, který sestává z následujících
kroků:
 Příprava podmínek zajištění studia
 Přijímací řízení
 Zápis ke studiu
 Podpora studia
 Graduace
 Práce s absolventy
Tento proces je zajišťován studijním informačním systémem (ISIS).
-50/117-
Rozvoj vědy a výzkumu – tento proces podporuje vědu a výzkum, např. udělování grantů,
finanční řízení, publikační činnost apod.
o Podpora a rozvoj hospodářské činnosti – tento proces zajišťuje doplňkové činnosti VŠE,
mezi které patří např. ubytování a stravování, nájmy, sluţby apod.
o Zajištění mezinárodních aktivit a vztahů – cílem tohoto procesu je podpora agendy
mezinárodních vztahů, např. výměnné pobyty nebo výuka externistů ze zahraničí.
o
Hlavní procesy
Strategický rozvoj VŠE
Zajištění studia
Rozvoj vědy a
výzkumu
Podpora
a rozvoj
hospodářské
činnosti
Zajištění
mezinárodních
aktivit a vztahů
Podpůrné procesy
Koordinace a řízení
rozvojových programů
Řízení ekonomiky
Zajištění
administrativy
Řízení
lidských zdrojů
Řízení a provoz
informačního systému
Zajištění účetnictví a
provozu školy
Obr. 8 - Procesní model VŠE (Zdroj: Autor, vytvořeno na základě [Trcka2009])
Podpůrné procesy:
o
o
o
o
o
o
o
Koordinace a řízení rozvojových programů
Řízení ekonomiky
Zajištění administrativy
Řízení lidských zdrojů
Řízení a provoz informačního systému
Zajištění administrativy
Zajištění účetnictví a provozu školy
5.1.3 VÝPOČETNÍ CENTRUM
O chod výpočetní techniky se na VŠE stará výpočetní centrum. Toto centrum je jedním z útvarů VŠE,
které například v otázkách připojení univerzity do sítě internet spolupracuje se správou sítě PASNET
(Prague Academic and Scientific NETwork). Kromě připojení univerzity k síti internet výpočetní
centrum zabezpečuje následující činnosti [VSE2010]:






koordinace zavádění jednotlivých komponent informačního systému VŠE,
navrhování a realizace koncepce rozvoje IS/ICT na VŠE,
vývoj informačních systémů univerzity,
rozvoj a správu lokální počítačové sítě a síťové infrastruktury,
provoz hlavních serverů, archivaci dat a instalaci programového vybavení,
provoz počítačových učeben a studoven,
-51/117-


konzultační sluţby uţivatelům výpočetní techniky,
opravy, údrţba, inovace a další rozvoj výpočetní techniky.
5.1.4 TECHNOLOGICKÁ INFRASTRUKTURA
VŠE provozuje rozsáhlou lokální počítačovou síť, která je napojena prostřednictvím praţské
metropolitní sítě PASNET a sítě CESNET2 do internetu. V areálech školy je také provozována
bezdrátová síť Eduroam, která jako součást mezinárodní bezdrátové sítě poskytuje připojení
uţivatelům napříč celou Evropou.
Otázky bezpečnosti jsou na VŠE řešeny pomocí dvou firewallů (Cisco provozovaný oddělením síťové
infrastruktury a aplikační firewall CheckPoint provozovaný správou lokální sítě, viz [VSE2010]).
Na VŠE jsou provozovány servery na různých hardwarových architekturách (nejčastěji sparc
a opteron). V současné době Výpočetní centrum spravuje téměř 100 serverů a CIKS několik dalších.
[VSE2010] Přehled serverů provozovaných na VŠE včetně operačních systémů je uveden v Příloha B
– Seznam serverů provozovaných na VŠE. Servery s operačním systémem Novell Netware 6.5
a sluţbou eDirectory poskytují síťové sluţby uţivatelům (např. jmenná sluţba, autorizace, diskový
prostor). Vedle těchto serverů jsou na VŠE provozovány aplikační servery, nejčastěji běţící na
operačním systému typu Unix (Linux, Solaris), Novell Netware a Windows 2000/2003 Server.
Pro zajištění podnikové kontinuity jsou servery napojeny na dieselový agregát, který je schopen
obnovit chod serverů do tří minut od výpadku dodávky elektrické energie.
Pro snazší správu a pro lepší zajištění Business Continuity v případě problému jsou klíčové servery
(studijní agendy a ekonomické systémy) podle [Trcka2009] vybaveny kartami pro vzdálenou správu,
díky nimţ je moţné ovládat server na dálku i na nejniţší systémové úrovni. Tento přístup umoţňuje
ovládat server, i pokud nereaguje na standardní volání na úrovni operačního systému (restart, vypnutí
systému).
Vybrané servery jsou centrálně zálohovány. Kompletní zálohy jsou prováděny jednou za týden.
Inkrementální zálohy se provádějí na denní bázi, v případě studijního informačního systému kaţdé 4
hodiny. Zálohy vybraných serverů jsou ukládány na dedikované pracoviště, které je umístěno mimo
hlavní areály univerzity. Zálohy jsou uskutečňovány nejprve na disková pole, následně na pásky.
V současném objemu (pozn. informace z roku 2009) pásky obsahují data posledních 2 týdnů.
[Trcka2009] Lze předpokládat, ţe tato doba se bude v budoucnu s rostoucím objemem dat zkracovat.
Z hlediska dostupnosti jsou jednotlivé komponenty systému (servery, síťové prvky) monitorovány
open-sourceovým softwarem. Tento systém informuje správce o výpadcích spravovaných zařízení
nebo nenadálých situacích. Dle [Xymon2010] tento software poskytuje uţivatelům reporty
o dostupnosti a grafy výkonnosti jednotlivých komponent.
Další součástí technologické infrastruktury jsou počítačové učebny a studovny slouţící pro podporu
vědy a výuky. Od roku 2001 rostl počet koncových stanic na počítačových učebnách a studovnách.
Rok 2007 lze podle [VSE2010] z tohoto pohledu povaţovat za zlomový, neboť v tomto roce vzrostl
podíl vyuţívání vlastních notebooků studentů připojených do počítačové sítě. K tomuto faktu přispěla
také skutečnost, ţe došlo k zavedení bezdrátové sítě v prostorách VŠE, počítačové studovny začaly být
méně vytěţovány, a proto bylo rozhodnuto o jejich jiném vyuţívání, např. testování studentů.
5.1.5 STUDIJNÍ INFORMAČNÍ SYSTÉM
Studijní informační systém ISIS je na VŠE pouţíván od srpna roku 2008. Před uvedením do ostrého
provozu musel být tento systém upraven podle specifik VŠE, jako jsou registrace a zápisy, vedlejší
specializace, státní zkoušky apod. Implementace ISISu byla ukončena v roce 2009 a díky tomu, ţe se
-52/117-
jedná o rozsáhlý systém, stal se dle [VSE2010] základním kamenem pro systémovou integraci dalších
souvisejících oblastí. Mezi tyto oblasti patří rozhraní ISISu s ekonomickými a informačními systémy
Odysea a iFIS a s knihovním systémem Aleph500.
Tento systém nyní podporuje celý studijní proces tak, jak je uveden v kapitole 5.1.2. Nahradil tak
jedenáct do té doby existujících samostatných aplikací.
Vedle studijního procesu studijní informační systém zajišťuje také průběh podpůrných procesů
[Trcka2009]:









Manaţerské výstupy a hlášení externím subjektům,
Podpora pro ubytování na koleji,
Zpracování stipendií,
Ţivotní cyklus vyučujícího,
Anketa,
Zajištění ediční činnosti,
Zpracování poplatků za studium,
Administrace ISIS,
a další procesy pro podporu vědy a výzkumu (procesy plánování konferencí, evidence
publikací, práce s granty), pasportizace (procesy pro evidenci areálů, lokalit, budov
a místností).
5.2 VÝBĚR VHODNÉ VARIANTY CLOUDOVÉHO ŘEŠENÍ
Jak jiţ bylo uvedeno v kapitole 2 Charakteristika Cloud Computingu v řízení organizace, rozeznáváme
cloudy veřejné, soukromé a hybridní. Vyuţití těchto typů cloudů lze rozdělit podle velikosti
organizace. Zatímco malé organizace (do 50-ti zaměstnanců) jsou relativně omezené svým rozpočtem
a lidskými zdroji, a oceňují proto především fakt, ţe se nemusí o systémy starat samy a ţe počáteční
investice jsou minimální, střední podniky (do 250-ti zaměstnanců) se budou zajímat o moţnosti
efektivního vyuţití vlastních ICT prostředků a elasticitu vyuţívaných sluţeb a velké společnosti budou
dle [Prodelal2010] klást důraz na efektivní údrţbu celé infrastruktury ICT a její optimalizaci.
Naváţeme-li tuto úvahu na typologii cloudů, můţeme říci, ţe malé společnosti budou vyuţívat spíše
veřejných SaaS cloudů, střední společnosti pak podle [Prodelal2010] soukromých nebo hybridních
IaaS nebo PaaS cloudů a velké společnosti především soukromých IaaS cloudů.
Z informační strategie VŠE [VSE2010] vyplývá, ţe zaručení poţadované dostupnosti aplikací a
sluţeb, zajištění optimálního výkonu a zvládnutí výkonových špiček patří mezi priority budoucího
rozvoje VŠE. Současně je kladen důraz na minimalizaci nákladů. Na tyto aspekty je následující text
podrobněji zaměřen.
Z úvahy o vztahu mezi velikostí společnosti a typem Cloud Computing řešení vychází i následná
analýza situace a návrh vhodného řešení v podmínkách Vysoké školy ekonomické v Praze. Neboť
VŠE patří svou velikostí mezi organizace velké, budou zohledňována především řešení IaaS,
soukromého a hybridního cloudu a virtualizace.
5.3 INFRASTRUKTURA JAKO SLUŽBA
Instituce terciárního vzdělávání můţe čerpat výhody ze všech modelů poskytování cloudových sluţeb.
V případě, kdy se rozhodne vyuţívat infrastrukturu jako sluţbu, vyuţívá stroje, který je vlastněn
dodavatelem a je umístěn v místě jeho působení. Instituce v takovém případě vyuţívá virtualizovaného
serveru, na kterém jsou spuštěny její aplikace, a úloţiště v cloudu.
-53/117-
Cloudová řešení tohoto typu nabízejí díky sdruţenému vyuţívání infrastruktury aţ 80% vyuţití IT
zdrojů. [Feuerlicht2010] Podle některých odhadů (viz např. [Feuerlicht2010], [Litoiu2010])
kombinace moţnosti násobného vyuţívání zdrojů a umístění datových center do geografických oblastí
s niţšími náklady na elektrickou energii, práci, pořízení majetku a daně sniţuje náklady na pořízení
sluţeb 5 – 7 krát.
V poslední době vzrostl o řešení IaaS zájem, a to díky výraznému sníţení nákladů na infrastrukturu
díky modelu platby pay-as-you-go. Současné modely IaaS obvykle poskytují virtuální stroje (Virtual
Machine), které jsou následně zákazníkem upravovány a spravovány. Protoţe umístění virtuálních
strojů má podle [Lee2010] podstatný vliv na výkon aplikace, zůstává otázkou, zda jsou zdroje
efektivně vyuţívány. Zatímco poskytovatel nemá informace o náročnosti hostované aplikace, uţivatelé
IaaS řešení nemohou zasahovat do infrastruktury, která pod aplikacemi leţí. A tak dochází k tomu, ţe
jsou zdroje alokovány bez ohledu na běţící aplikace a optimalizace probíhá na straně zákazníka pouze
na aplikační úrovni.
Tento nedostatek informací můţe být řešen jak na straně odběratele (různými metodami optimalizace
výkonu aplikací), tak na straně poskytovatele, a to například formou vyţádání specifikace potřeb
zákazníka, jeho poţadavků na zdroje a nejlepší moţné odhady budoucí spotřeby zdrojů. Další
moţností jsou také řešení alokace zdrojů zaloţené na různých modelech, jako např. metoda zaloţená
na topologii aplikací přestavená ve studii, která je výsledkem spolupráce Californské univerzity
a laboratoří HP [Lee2010]. Jiní autoři (např. [Appavoo2010]) se přiklánějí k tomu, ţe k získání
potřebné elasticity a dosaţení maximálního výkonu je potřeba přímý přístup k hardware, např.
vyuţívání superpočítačů pro poskytování cloudové infrastruktury.
V návaznosti na tuto neinformovanost odběratele je důleţité porozumět konceptu Cloud Computingu
tak, aby byla instituce schopna modelovat ekosystém cloudových sluţeb vyuţívaných od různých
poskytovatelů. Pro tyto účely bylo navrţeno několik modelů architektury ekosystému Cloud
Computingu. Příklad takového modelu je uveden na Obr. 9.
Tento model sestává z několika vrstev Cloud Computingu (IaaS, PaaS, SaaS), kdy ke kaţdé vrstvě
jsou uvedeny příklady na trhu nabízených řešení. Na tomto obrázku je například ve vrstvě IaaS ve
skupině „Zdroje“ uveden jako příklad řešení Amazon EC2. Zde se proto analogicky nacházejí řešení
cloudových serverů porovnávaných v předchozí kapitole. Cloudová úloţiště poskytovaná k těmto
serverovým řešením pak spadají do vrstvy „Základní infrastrukturní sluţby“, neboť poskytují pouze
základní funkcionalitu úloţiště. [Lenk2009] Jak jiţ bylo uvedeno výše, tyto vrstvy budou hlavním
předmětem zájmu této diplomové práce v otázkách návrhu budoucího řešení vyuţití Cloud Computing
sluţeb v prostředí VŠE.
Pro řízení infrastruktury odebírané jako sluţbu je moţné vyuţívat řešení, která jsou pro tyto účely
určena. Pro ilustraci je tato řešení moţné nalézt na Obr. 9 v postranní dimenzi „Podpora businessu“.
Příkladem takové platformy určené pro správu a řízení infrastruktury je enStratus. Toto řešení se
zaměřuje na otázky governance, které společnost enStratus vymezuje takto [EnStratus2010]:






Řízení bezpečnosti – správa uţivatelů, šifrování, správa klíčů
Řízení financí – sledování nákladů, rozpočtování, kurzové rozdíly
Audity a reporting
Monitoring a upozorňování
Automatizace – automatické změny velikosti úloţiště, správa zálohování, řízení změn
Jednotná správa napříč řešeními různých poskytovatelů Cloud Computingu
-54/117-
Google Docs
Aplikační služby
Opensocial
Složené aplikační služby
Podpora businessu
Aplikace
Správa
SaaS
Základní aplikační služby
OpenID
PaaS
Prostředí pro programování
Google App
Engine
Prostředí pro realizaci
Google Bigtable
IaaS
Nadstavbové infrastrukturní služby
GoogleFS
Základní infrastrukturní služby
Zdroje
Amazon EC2
Virtuální zdroje
Fyzické zdroje
Emulab
Účtování, autentizace, správa uživatel
Infrastrukturní služby
Vývoj, konfigurace, monitoring, řízení životního cyklu
Django
Hardware
Obr. 9 - Architektura Cloud Computing řešení (Zdroj: [Lenk2009])
Právě taková řešení jako je enStratus společnostem pomáhají v následujících oblastech
[EnStratus2010]:



překlenutí obavy z bezpečnostních aspektů implementace Cloud Computing řešení,
zaručení spolehlivosti a dostupnosti odebíraných sluţeb,
poskytnutí řešení pro obnovu z havárie a Business Continuity.
Právě tyto oblasti byly v této práci jiţ v kapitole 3.3 vymezeny jako 3 nejdůleţitější kategorie
poţadavků BCM na Cloud Computing řešení.
-55/117-
5.4 VIRTUALIZACE
Fenomén virtualizace a Cloud Computing spolu úzce souvisejí. Virtualizace se jako koncept začala
pouţívat ke sníţení nákladů na infrastrukturu, a to především díky moţnosti konsolidovat servery
[Stratus2010]. Virtualizace tedy umoţňuje poskytování infrastruktury jako sluţby jako jednu z forem
Cloud Computingu. Na druhou stranu však Cloud Computing koncept virtualizace rozšiřuje o něco
dále. Z uţivatelského hlediska přináší výhodu v tom, ţe umoţňuje uţivateli vyhnout se vynakládání
počátečních nákladů na pořízení infrastruktury. Tyto dva koncepty jsou proto z těchto důvodů velmi
úzce spjaty.
V době, kdy je prakticky vše v oblasti IT poskytováno jako sluţba (viz kapitola 2; koncept Anythingas-a-Service - XaaS), probíhá virtualizace na několika úrovních. Virtualizovány jsou jak fyzické
zdroje, tak platformy i samotné podnikové aplikace [Lenk2009], [Litoiu2010]:



vrstva infrastruktury nabízí úloţiště, CPU a paměť – tyto tři prvky jsou obvykle poskytovány
jako virtuální stroj,
vrstva platformy poskytuje aplikační a databázové servery a prostředí pro vývoj, testování
a uvolnění aplikací. Tato vrstva typicky vyuţívá sluţeb poskytovaných vrstvou infrastruktury,
vrstva software nabízí jednoduché nebo sloţené sluţby (aplikace), které jsou vyuţívány
koncovými uţivateli.
Virtualizace je podle [Wolf2005] ve své podstatě abstrakce fyzických hranic technologie. Například
pracovní stanice uţivatelů nebo servery nepotřebují ke své existenci fungovat jako samostatné
jednotky, a nepotřebují tedy samostatný fyzický hardware, jako je CPU nebo základní deska. Namísto
toho mohou běţet uvnitř virtuálního stroje, kde je hardware emulován a ve vztahu k operačnímu
systému se chová jako běţný hardware.
Vyuţívání virtuálních strojů v distribuovaném prostředí přináší řadu výhod. Mezi tyto výhody lze řadit
následující [Assuncao2009] [Golden2008]:






konsolidace serverů – původní počet ne zcela vyuţívaných serverů se můţe díky virtualizaci
sníţit – dojde k efektivnímu rozloţení zátěţe mezi menší počet serverů,
sníţení nákladů na provoz serverů – kaţdý server potřebuje být ke svému provozu napájen ze
sítě elektrické energie. Konsolidací serverů dochází ke sníţení nákladů na elektrickou energii.
moţnost vytvoření virtuálního stroje pro běh zastaralé aplikace, aniţ by tato aplikace
narušovala API ostatních aplikací,
zlepšení bezpečnosti díky moţnosti vytvoření samostatné instance pro běh aplikací
s diskutabilní spolehlivostí,
dynamické zajištění zdrojů,
zvýšení výkonnosti aplikací například navýšením operační paměti serverů.
Virtualizace také minimalizuje některá rizika, která jsou neodmyslitelně spojená se sdílením IT zdrojů
mezi více uţivateli, neboť zde dochází k přidání virtualizační vrstvy, na které lze monitorovat, zda
nedochází k nějaké události, která by znamenala narušení bezpečnosti.
5.5 SOUKROMÝ CLOUD
Soukromé, privátní neboli také interní cloudy jsou alternativou k veřejným cloudům pro velké
společnosti s vysokým počtem zaměstnanců nebo specifickými poţadavky na poskytované sluţby či
na zabezpečení dat, které nemohou být naplněny nabídkou veřejných cloudů.
Především bezpečnostní otázky vedou dle [Hurwitz2010] společnosti ke zvýšenému zájmu o privátní,
popřípadě hybridní cloudová prostředí. Dalším významným faktorem zájmu o interní cloudy je také
-56/117-
situace, kdy společnosti jiţ investovaly významné prostředky v oblasti hardware, software a diskových
prostorů, a proto by tyto investice chtěly zuţitkovat.
Privátní cloud je infrastruktura, která umoţňuje uţivateli dosáhnout, konfigurovat a poskytovat zdroje
datového centra za vyuţití automatizovaných samoobsluţných nástrojů a softwarových sluţeb, a to
v rámci datového centra instituce. Privátní cloud umoţňuje dle [Eucalyptus2010a] vyřizovat několik
simultánních ţádostí uţivatelů, a to automatizovaně bez nutnosti zásahu zaměstnanců. K naplnění
těchto předpokladů jsou typicky vyuţívány virtuální stroje, které jsou buď předkonfigurovány pro
specifické potřeby uţivatele, nebo mohou být customizovány samotným koncovým uţivatelem.
Privátní cloud můţe být virtualizované datové centrum umístěné v prostředí organizace, chráněné
jejím firewallem. Můţe se však také jednat o privátní prostor vymezený v datovém centru
poskytovatele, který je schopen vypořádat se se zatíţením organizace.
Charakteristiky privátního cloudu jsou následující [Hurwitz2010]:






umoţňuje IT zajišťovat sluţby a výpočetní výkon pro interní uţivatele, a to samoobsluţným
způsobem,
automatizuje řízení úloh a umoţňuje účtovat jednotlivá oddělení pouze za sluţby, které
opravdu vyuţívají,
poskytuje řízené prostředí,
optimalizuje vyuţití výpočetních zdrojů, např. serverů,
podporuje specifické pracovní zatíţení,
poskytuje samoobsluţné zajištění hardwarových a softwarových zdrojů.
Lze říci, ţe tyto charakteristiky jsou obdobné, jako tomu je u cloudů veřejných. Podstatný rozdíl mezi
těmito dvěma typy cloudů však spočívá v kontrole nad prostředím, která je v případě interních cloudů
v rukou samotné organizace nebo důvěryhodného partnera. To však není jediným důvodem, proč se
společnosti rozhodují pro zřízení privátního cloudu.
Lze si představit situaci, kdy společnost investovala do své vlastní technologické infrastruktury,
a vlastní tedy datové centrum, jehoţ kapacita však není plně vyuţita. V takovém případě je pro
organizaci finančně výhodnější, pokud se rozhodne vyuţívat toto datové centrum jako poskytovatele
privátního cloudu. I za předpokladu, ţe bude muset pro tyto účely pořídit nový software, je tato
varianta dle [Hurwitz2010] výhodnější oproti alternativě vyuţívání veřejného cloudu.
Dosaţení plné účinnosti z vybudovaných privátních cloudů vyţaduje změnu činností a odpovědností
jak koncových uţivatelů, tak zaměstnanců IT oddělení. Ze strany koncových uţivatelů je vyţadována
schopnost a znalost ovládání prostředí pro samostatné obstarání zdrojů. V případě privátních cloudů,
kdy proces přidělování zdrojů probíhá automaticky, je uţivateli namísto souboru fyzických serverů
přiřazen soubor virtuálních strojů.
V některých případech privátní cloud nedosahuje dostatečné elasticity. Důvodem k tomu je fakt, ţe na
rozdíl od cloudů veřejných, v rámci jedné společnosti existuje pouze jedna špička ve smyslu vytíţení
informačních systémů. Velmi pravděpodobně v rámci privátního cloudu budou uţivatelé přistupovat
také k jedné jediné aplikaci [Hapl2010]. To je v rámci veřejných cloudů řešeno jak tím, ţe datová
centra poskytovatele jsou umístěna v odlišných geografických oblastech, tak také tím, ţe uţivatelé
z různých geografických oblastí budou zatěţovat vyuţívané zdroje v jiné denní době.
Tento nedostatek je moţné řešit také tak, ţe dočasný nedostatek kapacity interního cloudu bude
vyrovnán sluţbou cloudu veřejného. Toto spojení řešení privátního a veřejného cloudu bývá nazýváno
hybridním cloudem (viz kapitola 5.6). [Eucalyptus2010a] Řešení hybridního cloudu můţe být
provedeno několika způsoby. Jedním ze způsobů je vyuţívání veřejného cloudu pouze dočasně, kdy
-57/117-
jsou data v době maximálního vytíţení (např. v případě institucí terciárního vzdělávání ve
zkouškovém období) přesunuta do veřejného cloudu. V tomto okamţiku začíná instituce vyuţívat
sluţeb externího poskytovatele a začíná také za tyto sluţby platit. Poté, co pomine potřeba zvýšených
zdrojů technologické infrastruktury, jsou data instituce přenesena zpět do privátního cloudu.
K tomu, aby společnost dosáhla vybudování interního cloudu, potřebuje projít následujícími pěti kroky
[Eucalyptus2010a]:





implementace technologie virtualizace – v tomto kroku společnost musí vybrat virtualizační
technologii, pomocí které budou poskytovány sluţby interním uţivatelům,
vytyčení výpočetních a výkonnostních poţadavků, nároků na paměť a diskový prostor kaţdé
aplikace,
návrh vývoje virtuálních strojů – administrátoři privátních cloudů často nabízejí
předdefinované virtuální stroje, ze kterých si uţivatelé mohou vybrat. Tyto předdefinované
virtuální stroje musí být vyvinuty a zaneseny do aplikačního portfolia. Postupem času budou
někteří uţivatelé chtít konfigurovat své vlastní virtuální stroje, ať uţ zcela nové, nebo
dokonfigurováním předpřipravených image,
ustanovit politiku účtování za vyuţívání sluţeb – na rozdíl od veřejných cloudů, u cloudů
privátních se můţe IT oddělení setkat s tím, ţe uţivatel neuvolní zdroje, které jiţ nepotřebuje,
nebo začne hromadit ty zdroje, které mu byly přiděleny. Protoţe v privátním cloudu nejsou
uţivatelům sluţby účtovány přímo na základě vyuţívání sluţeb, je potřeba ustanovit takovou
politiku, která by zajišťovala, ţe technologické zdroje budou účinně vyuţívány a nebude
docházet k podobným neefektivním alokacím,
navrhnout architekturu a rozmístění infrastruktury privátního cloudu – ideálně jsou privátní
cloudy vysoce konfigurovatelné, takţe mohou vyuţívat výhod jiţ existující infrastruktury
nebo infrastruktury speciálně určené pro vytvoření cloudu co nejúčinnějším způsobem.
5.6 HYBRIDNÍ CLOUD
Hybridní cloudy hrají klíčovou roli při adopci Cloud Computingu, a to především ve velkých
organizacích. S rostoucí oblibou hybridních cloudů u organizací roste také potřeba zjednodušení
návrhu takových struktur. Z tohoto důvodu vznikají nástroje, které jsou schopny sjednotit komerční
řešení s řešením in-house.
Takovým řešením je rozhraní, které je schopno sjednotit odlišné fyzické zdroje a jednotně poskytovat
sluţby koncovému uţivateli. Rozhraní se skládá z výpočetních jednotek, přepínačů a jednotek
s úloţným prostorem. Jednotky jsou spojeny základní deskou a vysokorychlostním spojením.
[Furht2010] Nad touto společnou virtualizační vrstvou jsou typicky vystavěny aplikace pro správu,
kam patří zajištění sluţeb, účtování, zabezpečení, dynamická alokace zdrojů apod.
Systém pro správu virtuálních strojů odpovídá za řízení virtuální infrastruktury jako celku, a to tím, ţe
poskytuje základní funkcionalitu pro vývoj, správu a monitorování virtuálních strojů v distribuovaném
prostředí. Vyuţitím této vrstvy pro správu virtuálních strojů instituce dle [Montero2010] docílí toho,
ţe výpočetní zdroje budou odděleny od své fyzické infrastruktury, a tím rozšíří původní benefity
virtuálních strojů aţ na úroveň výpočetních clusterů (tj. jejich konsolidace, osamostatnění, rozdělení
a dosaţení pruţné výpočetní kapacity).
Pro účely VŠE by bylo vhodné ve vrstvě pro správu virtuálních strojů jak vlastních, tak i externích
dodavatelů vyuţívat open sourceových prostředků, neboť cílem VŠE je také sniţování nákladů na
infrastrukturu. Jak bylo zjištěno z rozhovoru s útvarem Výpočetního centra, VŠE má jiţ v současné
době zkušenosti s vyuţitím open sourceových řešení, a nebyla by to tedy první zkušenost s tímto
typem licencování softwaru.
-58/117-
Zjednodušená struktura takového hybridního cloudu je schematicky znázorněna na následujícím
obrázku.
Uživatelé
Virtuální infrastruktura
Vrstva služeb
IaaS software pro hybridní cloud
Fyzická infrastruktura
Univerzita
Poskytovatel
cloudových
služeb
Vrstva infrastruktury
Obr. 10 - Zobrazení hybridního cloudu (Zdroj: Autor)
Lze uvaţovat, ţe princip hybridního cloudu bude ideálním Cloud Computing modelem pro většinu
organizací, neboť představuje spojení výhod privátního a veřejného cloudu. [Mather2009] Díky
tomuto spojení je moţné kritická data uchovávat v rámci privátního interního cloudu, kde má
organizace celkovou kontrolu nad bezpečností dat, výkonností, řízením apod. Díky veřejnému cloudu
potom můţe organizace vyuţívat sluţeb umístěných mimo organizaci pro data a sluţby, které nejsou
kritické a integrovat tato řešení do své infrastruktury.
V rámci hybridních cloudů můţe společnost také přemisťovat data z prostředků umístěných ve
veřejném cloudu do prostředků v rámci společnosti a naopak. Zajištění bezpečnosti přenosu dat můţe
být dle [Stenzel2010] realizováno několika různými metodami, jako je například šifrování dat nebo
virtuální privátní sítě VPN.
Příkladem, kdy se společnost rozhodne vyuţívat hybridního cloudu, můţe být situace, kdy vyuţívá
systému CRM umístěného ve veřejném cloudu a zároveň ERP systému umístěném v cloudu interním.
[Hugos2010] V budoucnu je relativně jednoduché takové řešení rozšířit například o nástroje
spolupráce a komunikace mezi zaměstnanci.
5.7 VYUŽITÍ CLOUD COMPUTINGU PRO VÝUKU
Cloud Computing jako vyvíjející se koncept má vysoký potenciál pro výuku studentů oboru
informační technologie. Tito studenti jsou stejně jako všichni technicky zaměření studenti motivováni
k objevování a uţívání nových technologií. Uţ jen z tohoto důvodu je moţné předpokládat, ţe koncept
práce v „cloudu“ bude mezi studenty vítán.
Podstatnou výhodou Cloud Computingu je však také to, ţe díky tomuto přístupu je pro instituci moţné
zajistit studentům pohodlný přístup k technologickým zdrojům odkudkoli. Je tak moţné například
díky virtualizaci zpřístupnit některé aplikace či databázové systémy, které byly doposud dostupné
-59/117-
pouze z určité lokality. Je také moţné počítat s tím, ţe koncept Cloud Computingu se v následujících
letech rozšíří, a společnosti budou proto poptávat zaměstnance, kteří budou mít s tímto konceptem
zkušenosti. [Holden2009]
5.8 CLOUD COMPUTING A OPEN SOURCE
Koncept Cloud Computingu zaznamenal od svého vzniku řadu evolučních změn. Nejprve existoval
Cloud Computing v podobě veřejných cloudů, kdy byly uţivatelům nabízeny veřejně dostupné sluţby.
Stejně tak, jak je však v informačním světě společností zapotřebí interních sítí (například intranetu
oproti internetu), vznikla i potřeba interní/privátní obdoby veřejného cloudu.
K tomu, aby však mohla být dosaţena určitá úroveň řízení IT infrastruktury, je potřeba, aby platforma,
na které jsou principy Cloud Computingu implementovány, byla transparentní. [Eucalyptus2010b] To
znamená, ţe platforma privátního cloudu nemůţe zastínit ţádnou jiţ existující vrstvu hardwarové nebo
softwarové infrastruktury, aniţ by ve stejném okamţiku neposkytovala zabezpečené a řízené prostředí
pro koncové uţivatele. [Nair2009] Například není dostačující, aby pouze skutečnost, ţe uţivatel má
přístup do intranetu společnosti, mu automaticky umoţňovala přístup do privátního cloudu. Je potřeba,
aby byla na úrovni privátního cloudu řešena autentizace uţivatel.
Zajištění takové transparentnosti je moţné dosáhnout vyuţíváním open sourceových řešení. Díky
tomu, ţe open-sourceová řešení jsou vyvíjena komunitou a jejich zdrojový kód je veřejně dostupný,
není chování těchto řešení záhadou pro IT personál instituce, která je vyuţívá. Mimoto k opensourceovým řešením je běţnou záleţitostí také existence veřejně dostupných diskuzí, kde lze nalézt
vhodná řešení, a to i například od dodavatele třetí strany.
S open source systémy jsou spojena také zajímavá zjištění oblasti bezpečnosti. Zatímco zpočátku se
věřilo, ţe open-source platformy jsou náchylné k útokům z důvodu otevřeného přístupu, s postupem
času, jak se vyvíjel tento koncept a jeho uţivatelé, se ukázalo, ţe opak je pravdou. Otevřený přístup ke
zdrojovému kódu naopak umoţňuje IT specialistům vyvinout účinná opatření proti moţným útokům
zvenčí. Naopak proprietární platformy jsou pak podle [Eucalyptus2010b] proti útokům zvenčí
mnohem více zranitelné.
Často se setkáme s ne zcela přesným tvrzením, ţe implementace open source software nutně vede
společnosti ke sníţení nákladů. Sníţení nákladů totiţ není jediným a nejdůleţitějším důvodem, proč by
se instituce měla rozhodnout pro vyuţívání open sourceových řešení. Open source software přináší
firmám řadu konkurenčních výhod, které lze shrnout v následujících bodech [Noska2010]:





bezpečnost – díky otevřenosti konceptu má ke zdrojovému kódu přístup více vývojářů, kteří
tak mohou rychleji odhalit bezpečnostní rizika a zároveň implementovat opatření k jejich
minimalizaci,
kvalita – na open sourceových řešeních pracují tisíce vývojářů a výsledná funkcionalita můţe
pravděpodobně lépe naplnit poţadavky jednotlivých odběratelů. A to jednak proto, ţe je
pravděpodobné, ţe stejný nebo podobný problém, který má jedna společnost, jiţ řešila jiná
společnost v minulosti, a proto existuje pro tento problém řešení. Dalším důvodem oblíbenosti
open source software je technická nadřazenost odebírající firmy,
customizace – díky moţnosti volného upravování zdrojového kódu získává společnost
důleţitý prostředek vysoké customizace software, a to navíc vlastními silami,
svoboda – společnost logicky ztrácí závislost na určitém dodavateli software a do jisté míry
můţe ovlivňovat, co od software poţaduje,
flexibilita – společnost není nucena provádět upgrade hardware a software podle dodavatele,
ale pouze v případě, kdy to vyţaduje sama,
-60/117-





interoperabilita – open source software vyuţívá často otevřených standardů pro komunikaci.
Takový software tedy např. nepouţívá individuální formát dat, a je proto snazší vzájemná
interoperabilita s jinými společnostmi vyuţívajícími jiný software zaloţený také na
otevřených standardech,
moţnosti prověření – tato výhoda úzce souvisí s výše zmíněnou bezpečností a podporou
standardů. Na rozdíl od proprietárního řešení, u open source software se uţivatel můţe sám
přesvědčit o tom, jakým způsobem jsou tyto otázky řešeny,
moţnosti podpory – obvykle platí, ţe open source jako řešení je dodáváno zdarma a odběratel
platí za podporu nebo vyuţívá aktuální a podrobné online dokumentace, různá fóra apod.,
celková cena – obecně platí, ţe celková cena za pořízený open source software je niţší neţ
v případě proprietárního software. Je však potřeba zváţit, zda např. odborné zaškolení
vlastních zaměstnanců pro open source software nebude v konečném důsledku draţší neţ
nákup proprietárního řešení,
moţnost vyzkoušení všeho před pořízením – ve většině případů si společnost můţe vyzkoušet
plnou verzi řešení před tím, neţ se rozhodne ho skutečně vyuţívat, a to bez jakýchkoli
závazků. S tím se v případě proprietárních řešení běţně nesetkáme.
5.9 POHLED ODDĚLENÍ VÝPOČETNÍHO CENTRA VŠE
V rámci získání aktuálního pohledu na problematiku Business Continuity Management a Cloud
Computing na VŠE bylo osloveno Výpočetní centrum. Pro schůzku se zástupci Výpočetního centra
byla sestavena struktura rozhovoru uvedená v příloze Příloha C – Struktura rozhovoru se zástupci
Výpočetního centra VŠE. Výsledky tohoto rozhovoru jsou uvedeny v následujícím textu této kapitoly.
Samostatné podkapitoly obsahují informace týkající se specifických poţadavků BCM na Cloud
Computing řešení, které byly stanoveny v kapitole 3.
Výpočetní centrum VŠE vypracovalo v tomto roce informační strategii pro VŠE. Tato strategie je nyní
v připomínkovém řízení, po zapracování připomínek se očekává její vydání. V této strategii jsou mimo
jiné uvedeny také strategické cíle VŠE v oblasti IT pro období 2011 - 2015. V době psaní této
diplomové práce bylo pracováno s verzí 1.2 informační strategie před jejím oficiálním vydáním.
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.
Záloţní lokalita pro VŠE jako taková neexistuje. V minulosti VŠE provozovala duplicitní serverový
sál v areálu školy na Jiţním Městě. Od tohoto modelu se ale jiţ upustilo. Namísto toho má serverový
sál v areálu VŠE Ţiţkov implementována silná protipoţární opatření, která by měla zabránit
fyzickému zničení serverů v případě vypuknutí poţáru v budově školy.
-61/117-
Před 2 - 3 roky VŠE oslovilo několik komerčních firem s nabídkou externího datového úloţiště. Tyto
nabídky by byly pro školu zajímavé a ráda by je vyuţívala, nakonec však byly zamítnuty, a to z toho
důvodu, ţe všichni poskytovatelé nabízeli kromě datového úloţiště také další dodatečné sluţby,
o které VŠE neměla zájem.
Kaţdodenní zálohování dat vybraných serverů však probíhá. Servery, na které záloha probíhá, jsou
umístěny v lokalitě Jarov. Ve stejné lokalitě probíhá také archivace dat, a to na pásky. Důleţité servery
VŠE jsou tedy zálohovány jednotným centrálním způsobem s vyuţitím modelu Disk2Disk2Tape.
[VC2010]
Na otázku, zda by VŠE uvítala moţnost záloţního prostředí u jiné české univerzity, bylo odpovězeno,
ţe tato moţnost by byla díky vysokorychlostnímu spojení pomocí sítě CESNET/PASNET mezi
univerzitami proveditelná. V současné době se však nic podobného nerealizuje ani v rámci VŠE, ani
u jiných českých univerzit.
V současné době VŠE nevlastní plán Business Continuity. Kontinuita není v současné době řešena,
neboť se neuvaţuje, ţe by sluţby bylo nutné poskytovat v reţimu 24/7. Tím se nerozumí, ţe by na
VŠE sluţby nebyly poskytovány v reţimu 24/7, ale ţe ţádná sluţba není natolik kritická, aby musela
být poskytována nepřetrţitě.
Při výpadku konektivity sluţeb je systém nastaven tak, aby síťová cesta k serverům byla automaticky
nastavena jiným směrem, a systémy tak mohly nadále fungovat.
Pokud dochází k vysokému zatíţení určité sluţby, VŠE tuto situaci řeší raději nakoupením vlastní
technologické infrastruktury, tedy z vlastních zdrojů. VŠE má díky nabídkám poskytovatelů IT natolik
výhodné smlouvy na nové servery, ţe doposud neuvaţovala o nákupu sluţeb v cloudu.
Jinému způsobu zajištění potřebné kapacity VŠE brání také smlouvy uzavřené s dodavateli serverů.
Pokud by se ale VŠE rozhodovala, jakým způsobem platit za vyuţívané externí sluţby, volila by
zřejmě model pravidelných plateb neţ model pay-as-you-go, neboť sluţby, které by takto vyuţívala,
by musely být poskytovány v reţimu 24/7.
5.9.4 VIRTUALIZACE NA VŠE
Zvláštní pozornost je na VŠE jiţ v současné době věnována virtualizaci. Virtualizace jako projekt na
VŠE byl v době psaní této diplomové práce čerstvě spuštěn. Tento projekt byl podán na ministerstvo
školství MŠMT a je v současné době projednáván. V rámci projektu se počítá s interní realizací,
externí spolupráce na virtualizaci není uvaţována.
Do dnešní doby se jedná zejména o virtualizaci serverů pro síťové tisky, do budoucna se počítá také
s virtualizací části počítačů na posluchárnách. Problémem virtualizace počítačů na posluchárnách je
však v tom, ţe asi na 50-ti % koncových zařízení není ze strany hardware umoţněno, aby na nich
virtualizace mohla být provedena.
Dalším krokem po virtualizaci počítačů na posluchárnách je očekávaná virtualizace koncových stanic
umístěných na počítačových učebnách.
Virtualizace serverů jednotlivých pracovišť (kateder, fakult) v současné době neprobíhá, avšak některé
fakulty jeví o virtualizaci zájem jiţ dnes (např. Fakulta podnikohospodářská). Tyto katedrální
a fakultní servery jsou nyní umístěny v předsálí serverového sálu a jejich virtualizací by došlo
k podstatnému sníţení potřebné technologické infrastruktury.
-62/117-
Závěrem lze uvést, ţe VŠE by uvaţovala o zbudování interního cloudového řešení, o hybridním však
doposud neuvaţovala. Poskytování cloudových sluţeb externím subjektům mimo VŠE by škola měla
zájem, ale realizace takového modelu bude moţná aţ v budoucnu poté, co se model cloudového řešení
podaří implementovat v interním prostředí.
-63/117-
6 ANALÝZA POSKYTOVATELŮ CLOUDOVÝCH ŘEŠENÍ NA TRHU
V této kapitole je provedena analýza vybraných poskytovatelů řešení Infrastructure-as-a-Service, kteří
by v následující kapitole mohli být vhodnými kandidáty pro návrh praktického Cloud Computing
řešení. Sektor terciárního vzdělávání je oblastí, kde jednotlivé instituce typicky mají mnoho fyzických
serverů, které však nejsou vyuţívány na 100%. Zároveň pro tento sektor platí určitá sezónnost, a to
jednak ve smyslu většího zatíţení od září do června, ale také ve smyslu vysokých nároků na
dostupnost ve zkouškovém období či v období státních zkoušek. Z těchto důvodů byli v této kapitole
porovnáváni poskytovatelé IaaS, kteří jsou na trhu největšími hráči.
Jak jiţ bylo uvedeno v kapitole 2 Charakteristika Cloud Computingu v řízení organizace, rozeznáváme
tři základní modely poskytování sluţeb:



Software as a Service
Platform as a Service
Infrastructure as a Service
Po zhodnocení nabídky na trhu a zváţení vyuţití tohoto srovnání pro budoucí analýzu zúţenou na
podmínky Vysoké školy ekonomické (viz kapitola 5) byla srovnávána pouze řešení poskytovatelů
nabízejících infrastrukturu jako sluţbu.
Tato řešení spočívají v dodání infrastruktury (typicky ve virtualizovaném prostředí) pro výpočetní
výkony, a umoţňují tak zlepšit její vyuţití. Zákazníci nakupují sluţbu zejména v podobě
virtualizovaných serverů namísto toho, aby kupovali fyzické servery, datová centra či síťové vybavení.
Sluţby jsou zákazníkům účtovány na základě pouţívání, zpravidla za kaţdou hodinu běhu nakoupené
sluţby, někteří poskytovatelé nabízí svým zákazníkům také pohodlnou alternativu předplacení sluţby
na měsíc dopředu.
6.1 VÝBĚR POSKYTOVATELŮ IAAS
Při výběru vhodných kandidátů, které by bylo moţné vzájemně porovnat, byl kladen velký důraz na
jejich nabídku. Podmínkou bylo, aby poskytovatel byl primárně zaměřen na nabízení infrastruktury,
teprve dodatečně případně nabízel PaaS nebo SaaS. V další části této diplomové práce budou výsledky
analýzy pouţity pro návrh optimalizace vyuţití pouţívaných serverů na Vysoké škole ekonomické,
proto jsou primárním zaměřením právě sluţby poskytující infrastrukturu.
Důvodem pro zúţení výběru byla v neposlední řadě také komplexnost konceptu Cloud Computing
a praktická nemoţnost srovnávat řešení poskytovatelů napříč jednotlivými modely poskytování.
Nesporným důvodem pro upřednostnění konceptu IaaS před ostatními modely poskytování sluţeb
byla také skutečnost, ţe v této práci je kladen důraz na navázání konceptu Cloud Computing na
Business Continuity Management. Vyuţití SaaS v podmínkách terciárního vzdělávání je sice moţné,
avšak z hlediska udrţení kontinuity společnosti je mnohem zajímavější formou právě vyuţívání
infrastruktury.
Pro podrobnější analýzu poskytovatelů byly vybrány následující společnosti a jejich řešení:





Amazon (Amazon Elastic Compute Cloud)
ElasticHosts
GoGrid (GoGrid Cloud Hosting)
Rackspace Cloud (Rackspace Cloud Servers)
ReliaCloud
-64/117-
6.2 VÝBĚR KRITÉRIÍ PRO ANALÝZU
Všichni tito dodavatelé nabízejí řešení, kterým si na trhu přímo konkurují. Orientují se na stejnou
strukturu zákazníků a jejich řešení jsou si do jisté míry podobná. Pro hodnocení jejich produktů proto
bylo moţné navrhnout strukturu kritérií uvedenou v tabulce Tab. 2. Kritéria byla rozdělena do tří
hlavních kategorií, kterými jsou technické aspekty, aspekty BCM a aspekty finanční. Kritéria jsou
v rámci jednotlivých kategorií dále podrobněji členěna do niţších celků.
Jednotlivým kritériím byla přiřazena také váha. Z celkového počtu 13-ti kritérií bylo vybráno 5
kritérií, kterým byla přidělena vyšší váha neţ ostatním.
První tři kritéria byla ohodnocena vyššími vahami z důvodu důleţitosti těchto kritérií nejen pro volbu
cloudového poskytovatele, ale také z hlediska BCM. Tato kritéria vycházejí z identifikovaných
poţadavků BCM na Cloud Computing řešení uvedených v kapitole 3.3. Tato kritéria byla proto
definována následujícím způsobem:



BCM001 Bezpečnost a monitoring
BCM002 Zálohování
BCM003 Garance SLA
Další dvě kritéria, kterým byla přiřazena vyšší váha, byla vybrána proto, neboť jsou důleţitá při
rozhodování, zda je poskytovatel IaaS pro instituci vhodný či nikoliv. Tato kritéria jsou následující:


TECH005 Podporovaný operační systém
FIN001 Model financování
Kategorie kritérií
Název a označení
Váha kritéria
TECH001 Cloudové servery
0,07
TECH002 Cloudové úloţiště
0,07
TECH003 Webový ovládací panel
0,07
1.2 Vývoj a otevřenost
TECH004 API
0,07
1.3 Technické parametry
0,09
TECH006 Minimální velikost
0,07
TECH007 Maximální velikost
0,07
0,09
0,09
BCM003 Garance SLA
0,09
0,08
FIN002 Způsob stanovení ceny
0,07
FIN003 Technická podpora
0,07
1. Technické aspekty
1.1 Typy poskytovaných řešení
2. Aspekty BCM
2.1 Bezpečnost
2.2 Smluvní ujednání
3. Finanční aspekty
3.1 Financování
3.2 Sluţby
Tab. 2 - Přehled srovnávaných kritérií (Zdroj: Autor)
V následujícím textu jsou podrobněji popsána jednotlivá kritéria a způsob jejich vyhodnocování.
-65/117-
6.3 POPIS VYBRANÝCH KRITÉRIÍ
6.3.1 TECHNICKÉ ASPEKTY
V rámci technických aspektů byla hodnocena kritéria tří podřazených kategorií. Mezi tyto
podkategorie patří:



Typy poskytovaných řešení, kterými se rozumí typy poskytovatelem nabízených sluţeb
a jejich moţnost správy a administrace,
Vývoj a otevřenost hodnotí, zda poskytovatel umoţňuje svým zákazníkům vyuţívat
otevřeného API či nikoliv, a
Technické parametry, které klasifikují srovnávaná řešení na základě podporovaných
operačních systémů, nabízené velikosti cloudových serverů apod.
6.3.1.1
TECH001 CLOUDOVÉ SERVERY
V rámci tohoto kritéria je hodnoceno, zda poskytovatel nabízí své řešení ve formě cloudových serverů
či nikoliv.
Váha tohoto kritéria je 0,07.
Kritérium je hodnoceno následujícím způsobem:


0 – poskytovatel nenabízí cloudové servery
1 – poskytovatel nabízí cloudové servery
6.3.1.2
TECH002 CLOUDOVÉ ÚLOŽIŠTĚ
Toto kritérium hodnotí, zda je v rámci poskytovaného cloudového serveru poskytováno také úloţiště
a toto úloţiště není placeno zvlášť.


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é
-66/117-

1 – API je otevřené
6.3.1.5
TECH005 PODPOROVANÝ OPERAČNÍ SYSTÉM
V rámci tohoto kritéria je hodnoceno, jak širokou škálu podporovaných operačních systémů dodavatel
nabízí. Toto kritérium je důleţité při rozhodování, zda vyuţívat nabízeného řešení či nikoliv, proto mu
byla přiřazena vyšší váha.




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.
-67/117-
6.3.2.1
BCM001 BEZPEČNOST A MONITORING
V rámci tohoto kritéria je hodnoceno, zda je moţné v rámci řešení implementovat také bezpečnostní
pravidla pro ochranu soukromí a dat společnosti a případně, zda je také moţné vyuţívat
bezpečnostního monitoringu. Z důvodu zvýšeného zájmu společností o otázky bezpečnosti
cloudových sluţeb byla tomuto kritériu přidělena vyšší váha.



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-asyou-go, nebo zda je nabízen také pohodlnější model měsíčního předplatného, který je však odvozen
z hodinové sazby. Protoţe je toto kritérium důleţité pro rozhodování o implementaci řešení, byla mu
přiřazena vyšší váha.
-68/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/
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.
Bezpečnost a monitoring nad servery není poskytován přímo společností GoGrid, ale je poskytován ve
spolupráci s partnerskými dodavateli sluţeb.
Společnost GoGrid garantuje 100% zajištění SLA a poskytuje technickou podporu zdarma v ceně
nakoupené sluţby.
-69/117-
Mezi nabízené modely financování patří jednak model pay-as-you-go, ale společnost GoGrid nabízí
také předplacené měsíční plány. Tyto měsíční plány jsou rozlišeny podle zvolené kategorie cloudu
(professional, business, corporate, enterprise).
6.4.4 CELKOVÉ HODNOCENÍ GOGRID CLOUD HOSTING
Celkové hodnocení GoGrid řešení je na základě přiřazených vah uvedeno v následující tabulce:
Identifikace kritéria
Váha
0,07
0,07
0,07
0,07
0,09
0,07
0,07
0,09
0,09
0,09
0,08
0,07
0,07
TECH001
TECH002
TECH003
TECH004
TECH005
TECH006
TECH007
BCM001
BCM002
BCM003
FIN001
FIN002
FIN003
Celková váţená hodnota
Hodnota
1
1
1
1
0,67
1
0,67
1
1
1
1
1
1
Váţená hodnota
0,07
0,07
0,07
0,07
0,0603
0,07
0,0469
0,09
0,09
0,09
0,08
0,07
0,07
0,9472
Tab. 3 - Hodnocení GoGrid Cloud Hosting (Zdroj: Autor)
Celková váţená hodnota hodnoceného řešení GoGrid je 0,9472 -> 94,72% vhodnost řešení pro
implementaci dle zvolených kritérií.
Znázorněním neváţených hodnocených kritérií pomocí radarového grafu získáme následující diagram:
GoGrid
FIN003
FIN002
FIN001
TECH001
1
0,8
0,6
0,4
0,2
0
TECH002
TECH003
TECH004
BCM003
TECH005
BCM002
TECH006
BCM001
TECH007
Obr. 11 - Grafické znázornění hodnocení GoGrid Cloud Hosting (Zdroj: Autor)
-70/117-
6.5 AMAZON EC2
Amazon Elastic Compute Cloud (Amazon EC2) je webová sluţba, která poskytuje škálovatelnou
výpočetní kapacitu prostřednictvím cloudového řešení. Amazon EC2 je sluţba, která poskytuje
primárně cloudové servery a cloudové úloţiště. Amazon EC2 je součástí platformy pro Cloud
Computing, Amazon Web Services. [Amazon2010]
Více informací viz: http://aws.amazon.com/ec2/
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
TECH002
TECH003
TECH004
TECH005
TECH006
TECH007
BCM001
BCM002
BCM003
FIN001
FIN002
FIN003
Váha
0,07
0,07
0,07
0,07
0,09
0,07
0,07
0,09
0,09
0,09
0,08
0,07
0,07
Hodnota
1
1
1
0,5
1
0,67
1
1
0
0,9995
1
1
0,5
Tab. 4 - Hodnocení Amazon EC2 (Zdroj: Autor)
-71/117-
Váţená hodnota
0,07
0,07
0,07
0,035
0,09
0,0469
0,07
0,09
0
0,089955
0,08
0,07
0,035
0,816855
Celkové hodnocení Amazon EC2 je na základě přiřazených vah znázorněno ve výše uvedené tabulce.
Celková váţená hodnota hodnoceného řešení Amazon EC2 je 0,8169 -> 81,69% vhodnost řešení pro
implementaci podle hodnocených kritérií.
Znázorněním neváţených hodnotových kritérií pomocí radarového grafu získáme následující diagram:
Amazon EC2
TECH001
1
FIN003
0,8
0,6
FIN002
0,4
0,2
FIN001
0
TECH002
TECH003
TECH004
BCM003
TECH005
BCM002
TECH006
BCM001
TECH007
Obr. 12 - Grafické znázornění hodnocení Amazon EC2 (Zdroj: Autor)
6.6 RACKSPACE CLOUD SERVERS
Rackspace Cloud je dceřinou společností Rackspace, která se zaměřuje na poskytování infrastruktury
jako sluţby a na poskytování cloudového úloţiště. Společnost Rackspace Cloud si zakládá na
nepřetrţité technické podpoře, kterou nabízí zdarma prostřednictvím několika komunikačních kanálů,
mezi nimiţ nechybí např. ani live chat.
Společnost získala řadu ocenění v oblasti webového hostingu. [Rackspace2010]
Více informací viz: http://www.rackspacecloud.com/cloud_hosting_products/servers
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.
-72/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
TECH002
TECH003
TECH004
TECH005
TECH006
TECH007
BCM001
BCM002
BCM003
FIN001
FIN002
FIN003
Váha
Hodnota
Váţená hodnota
0,07
0,07
0,07
0,07
0,09
0,07
0,07
0,09
0,09
0,09
0,08
0,07
0,07
1
1
1
1
0,67
1
0,67
0,5
1
1
0,5
0,5
1
0,07
0,07
0,07
0,07
0,0603
0,07
0,0469
0,045
0,09
0,09
0,04
0,035
0,07
0,8272
Tab. 5 - Hodnocení Rackspace Cloud Servers (Zdroj: Autor)
Celková váţená hodnota hodnoceného řešení Rackspace Cloud Servers je 0,8272 -> 82,72% vhodnost
řešení pro implementaci podle hodnocených kritérií.
Rackspace Cloud
TECH001
1
FIN003
0,8
0,6
FIN002
0,4
0,2
FIN001
0
TECH002
TECH003
TECH004
BCM003
TECH005
BCM002
TECH006
BCM001
TECH007
Obr. 13 - Grafické znázornění hodnocení Rackspace Cloud Servers (Zdroj: Autor)
-73/117-
6.7 RELIACLOUD
ReliaCloud je sluţba poskytující infrastrukturu jako cloudové řešení. ReliaCloud je soukromou
společností, která je nabídkou svých hostingových sluţeb přímým konkurentem takových společností,
jako je např. Rackspace.
ReliaCloud je součástí hostingové organizace. Obdobně jako Rackspace, zakládá si i ReliaCloud na
poskytování nepřetrţité technické podpory svým zákazníkům. [ReliaCloud2010]
Více informací viz: http://www.reliacloud.com/howitworks/
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
TECH002
TECH003
TECH004
TECH005
TECH006
TECH007
BCM001
BCM002
BCM003
FIN001
FIN002
FIN003
Váha
Hodnota
Váţená hodnota
0,07
0,07
0,07
0,07
0,09
0,07
0,07
0,09
0,09
0,09
0,08
0,07
0,07
1
1
1
0,5
0,34
1
0,34
0,5
1
1
0,5
0,5
1
0,07
0,07
0,07
0,035
0,0306
0,07
0,0238
0,045
0,09
0,09
0,04
0,035
0,07
0,7394
Tab. 6 - Hodnocení ReliaCloud (Zdroj: Autor)
-74/117-
Celková váţená hodnota hodnoceného řešení ReliaCloud je 0,7394 -> 73,94% vhodnost řešení pro
implementaci dle stanovených kritérií.
Znázorněním neváţených hodnotových kritérií pomocí radarového grafu získáme následující diagram:
ReliaCloud
TECH001
1
FIN003
0,8
0,6
FIN002
0,4
0,2
FIN001
0
TECH002
TECH003
TECH004
BCM003
TECH005
BCM002
TECH006
BCM001
TECH007
Obr. 14 - Grafické znázornění hodnocení ReliaCloud (Zdroj: Autor)
6.8 ELASTICHOSTS
ElasticHosts je mezinárodní sluţba poskytující infrastrukturu pomocí cloudu. Sluţba ElasticHosts je
poskytována ze dvou datových center. Soustředí se na poskytování virtualizace tak, aby byla flexibilní,
a zaměřuje se na širokou škálu zákazníků od těch nejmenších, aţ po velké korporace.
Společnost si zakládá na tom, ţe je ekologickou a sniţuje uhlíkovou stopu. [ElasticHosts2010]
Více informací viz: http://www.elastichosts.com/
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í.
-75/117-
Technická podpora není poskytována zdarma, je moţné ji dokoupit za paušální sazbu navíc.
Poskytovatel se hájí tím, ţe není moţné zaručit funkcionalitu aplikací běţících na poskytované
infrastruktuře, z tohoto důvodu neexistuje technická podpora zdarma.
6.8.4 CELKOVÉ HODNOCENÍ ELASTICHOSTS
Celkové hodnocení ElasticHosts řešení je na základě přiřazených vah uvedeno v následující tabulce:
TECH001
TECH002
TECH003
TECH004
TECH005
TECH006
TECH007
BCM001
BCM002
BCM003
FIN001
FIN002
FIN003
Váha
Hodnota
Váţená hodnota
0,07
0,07
0,07
0,07
0,09
0,07
0,07
0,09
0,09
0,09
0,08
0,07
0,07
1
1
1
0,5
0,34
0,34
0,34
0,5
1
1
1
1
0,5
0,07
0,07
0,07
0,035
0,0306
0,0238
0,0238
0,045
0,09
0,09
0,08
0,07
0,035
0,7332
Tab. 7 - Hodnocení ElasticHosts (Zdroj: Autor)
Celková váţená hodnota hodnoceného řešení ElasticHosts je 0,7332 -> 73,32% vhodnost řešení pro
implementaci dle stanovených kritérií.
ElasticHosts
TECH001
1
FIN003
0,8
0,6
FIN002
0,4
0,2
FIN001
0
TECH002
TECH003
TECH004
BCM003
TECH005
BCM002
TECH006
BCM001
TECH007
Obr. 15 - Grafické znázornění řešení ElasticHosts (Zdroj: Autor)
-76/117-
6.9 VZÁJEMNÉ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ
Na základě provedené analýzy pěti dostupných IaaS řešení bylo dosaţeno několika závěrů. Analýza
vycházela z celkového počtu 13-ti kritérií, z nichţ kaţdé mohlo nabývat maximální hodnoty 1. Čím
vyšší dosaţená hodnota v daném kritériu byla, tím vhodnější řešení.
Jednotlivým kritériím byly dále přiřazeny váhy (viz kapitola 6.1). Po ohodnocení všech kritérií bylo
zjištěno následující pořadí „vhodnosti“ IaaS řešení:
Řešení IaaS
Naplnění kritérií (%)
1. GoGrid Cloud Hosting
94,72%
2. Rackspace Cloud Servers
82,72%
3. Amazon EC2
81,69%
4. ReliaCloud
73,94%
5. ElasticHosts
73,32%
Tab. 8 - Pořadí IaaS řešení dle hodnocených kritérií (Zdroj: Autor)
Abychom získali podrobnější přehled o analyzovaných produktech a zároveň zhodnotili jejich
vhodnost jak z hlediska technických předpokladů, tak z hlediska Business Continuity Management,
analyzovali jsme získaná data dále.
6.9.1 ZHODNOCENÍ OBLASTI TECHNICKÝCH ASPEKTŮ
Mezi technické aspekty, na základě kterých byla řešení dále hodnocena, patří následujících sedm
kritérií:







TECH001 Cloudové servery
TECH002 Cloudové úloţiště
TECH003 Webový ovládací panel
TECH004 API
TECH006 Minimální velikost
TECH007 Maximální velikost
Na základě ohodnocení technických kritérií lze získat následující pořadí:
Řešení IaaS
1. – 2. GoGrid Cloud Hosting
65,31%
1. – 2. Rackspace Cloud Servers
65,31%
3. Amazon EC2
64,56%
4. ReliaCloud
52,77%
5. ElasticHosts
46,17%
Tab. 9 - Pořadí IaaS řešení dle technických parametrů (Zdroj: Autor)
Podle tohoto srovnání jsou řešení GoGrid Cloud Hosting a Rackspace Cloud Servers srovnatelné
a velice se jim přibliţuje také Amazon EC2. Výrazně se zvětšil rozdíl mezi zbývajícími řešeními
ReliaCloud a ElasticHosts.
-77/117-
6.9.2 ZHODNOCENÍ OBLASTI BUSINESS CONTINUITY
V dalším kroku jsme porovnávali produkty z hlediska Business Continuity. Pro tento účel byla
vybrána následující kritéria:



BCM003 Garance SLA
Nutno podotknout, ţe všechna tato tři kritéria mají sobě přiřazenu vyšší váhu neţ kritéria zbývající.
Proto je zajímavý výsledek srovnání konkurenčních řešení:
Řešení IaaS
90%
75%
2. – 4. ReliaCloud
75%
2. – 4. ElasticHosts
75%
5. Amazon EC2
59,99%
Tab. 10 - Pořadí IaaS řešení dle parametrů BCM (Zdroj: Autor)
Na této tabulce je zajímavé jak srovnání tří řešení Rackspace Cloud Servers, ReliaCloud
a ElasticHosts, tak i značný propad řešení Amazon EC2. Tento propad je dán především následujícími
důvody:


Amazon EC2 neposkytuje záruku nulové ztráty dat v případě výpadku sluţby. Dokáţe pouze
zajistit navrácení instance do nejbliţšího časového okamţiku před výpadkem. V některých
případech proto můţe dojít ke ztrátě dat.
Garance SLA ze strany Amazon.com je „pouze“ na úrovni 99,95%, zatímco ostatní
poskytovatelé hodnocených řešení jsou schopni zajistit garanci stoprocentní.
Na druhou stranu řešení Amazon EC2 nabízí na rozdíl od některých řešení umístěných na 2. – 4. místě
bezpečnostní monitoring. Ani to mu však nestačilo, aby se dostal nad jejich úroveň. Při výběru
vhodného řešení je proto dobré všechny tyto aspekty zváţit.
6.9.3 ZHODNOCENÍ OBLASTI FINANČNÍCH ASPEKTŮ
V této oblasti byla hodnocena následující kritéria:



FIN002 Způsob stanovení ceny
FIN003 Technická podpora
Porovnáním těchto kritérií dosáhneme následujícího pořadí srovnávaných řešení:
Řešení IaaS
73,34%
2. – 3. Amazon EC2
61,67%
2. – 3. ElasticHosts
61,67%
48,34%
4. – 5. ReliaCloud
48,34%
Tab. 11 - Pořadí IaaS řešení dle finančních kritérií (Zdroj: Autor)
-78/117-
Z pořadí získaného porovnáním finančních kritérií je zřejmé, ţe se poněkud výrazně změnilo umístění
jednotlivých řešení. To je dáno především strukturou kritérií, které zvýhodňují ta řešení, která nabízí
variabilitu v otázkách financování.
Toto pořadí ve srovnání s pořadími předchozími je zřejmým důkazem toho, ţe není vhodné výběr
řešení omezovat pouze na finanční kritéria.
6.9.4 MULTIKRITERIÁLNÍ POROVNÁNÍ HODNOCENÝCH ŘEŠENÍ
Na následujícím obrázku je graficky znázorněn komplexní vztah mezi hodnocenými řešeními. Na ose
X je vyjádřeno naplnění technických kritérií, osa Y znázorňuje naplnění poţadavků Business
Continuity Management. Velikost jednotlivých „koulí“ je dána naplněním finančních kritérií.
Umístění jednotlivých řešení nám tak poskytuje obrázek o tom, jak vhodné je řešení z hlediska
technického, finančního a z hlediska plánování podnikové kontinuity.
Aspekty BCM
Porovnání řešení IaaS
100%
95%
90%
85%
80%
75%
70%
65%
60%
55%
50%
40%
GoGrid
ElasticHosts
ReliaCloud
Rackspace
Amazon EC2
45%
50%
55%
60%
65%
70%
Technické aspekty
Obr. 16 - Grafické znázornění porovnání IaaS řešení ve 3 rozměrech (Zdroj: Autor)
6.10
ZÁVĚREČNÉ ZHODNOCENÍ
V této kapitole bylo provedeno srovnání pěti řešení Infrastructure-as-a-Service. Na první pohled jsou
tato řešení srovnatelná a jsou si sobě přímými konkurenty. Předmětem této kapitoly však bylo mimo
jiné poukázat také na to, jak se vhodnost vybíraného řešení mění v závislosti na sadě aplikovaných
kritérií. Například řešení, které se na první pohled můţe jevit jako nedostatečné z hlediska technických
aspektů, neboť nepodporuje širokou škálu operačních systémů, můţe překvapit svou pruţností při
naplnění aspektů Business Continuity.
-79/117-
7 NÁVRH VHODNÉHO ŘEŠENÍ PRO VŠE PRAHA
Tato kapitola je praktickou aplikací návrhu vhodného Cloud Computing řešení podporujícího
poţadavky Business Continuity Management v konkrétních podmínkách VŠE Praha. Řešení vychází
z výsledků předchozích kapitol a aplikuje veškeré poznatky ve specifickém prostředí instituce
terciárního vzdělávání. V první části této kapitoly je popsán ţivotní cyklus Business Continuity
Management na VŠE Praha, v části druhé jsou navrhnutá Cloud Computing řešení verifikována
s ohledem na poţadavky, které na ně klade Business Continuity Management.
7.1 OBLAST BUSINESS CONTINUITY MANAGEMENT
V oblasti Business Continuity Management by instituce měla postupovat podle jednotlivých fází
ţivotního cyklu procesu BCM, popsaných v kapitole 1.2. V této kapitole si takový postup ukáţeme
prakticky na konkrétních podmínkách VŠE Praha.
K tomu, aby instituce mohla úspěšně implementovat prvky Business Continuity Management, je
potřeba, aby byla provedena analýza dopadů (BIA). V rámci analýzy dopadů instituce určuje, které
činnosti jsou pro ni klíčové a co by pro instituci znamenalo, došlo-li by k jejich narušení.
Protoţe VŠE je institucí v oboru terciárního vzdělávání a všechny její fakulty, resp. katedry podporují
stejné procesy, nebude v tomto ohledu instituce členěna na menší celky, ale bude z procesního
hlediska chápána jako jeden celek.
V prvním kroku analýzy dopadů je důleţité určit procesy, které jsou z hlediska BCM pro VŠE klíčové.
Z hlavních procesů zobrazených v Procesní mapě v kapitole 5.1.2 jsou z hlediska Business Continuity
klíčové následující tři procesy:



PR01 - Zajištění studia
PR02 - Rozvoj vědy a výzkumu
PR03 - Podpora a rozvoj hospodářské činnosti
Mezi procesy klíčové z hlediska Business Continuity byly vybrány klíčové procesy Procesní mapy
s výjimkou procesu Zajištění mezinárodních aktivit a vztahů. Tento proces je z hlediska VŠE důleţitý,
neboť si v rámci něho VŠE zajišťuje mezinárodní pověst a dobré vztahy se zahraničními univerzitami.
V případě, ţe by však byl proces narušen a došlo k jeho výpadku, chod instituce jako takové nebude
významně ohroţen.
U procesů PR01 – PR03 by mělo dojít k ohodnocení dopadu rizik na daný proces, doba poţadovaná na
obnovení procesu a odhad dopadu na instituci. Ten můţe být odhadnut v podobě finanční ztráty,
dopadu na dodávky sluţeb, poškození pověsti, nesplnění zákonných povinností apod.
V následující tabulce je uveden příklad zobrazení výsledků Analýzy dopadu na jednotlivé klíčové
procesy.
-80/117-
Název procesu
MTD
(Maximum
Downtime)
Tolerable RPO
Ohodnocení
(Recovery dopadu
Point
RTO (Recovery WRT
(Work
Objective
Time
Recovery Time)
Objective)
PR01 Zajištění studia
< 2 dny
4 Přerušení dodávky
sluţeb
< 2 dny
<
hodiny
PR02 Rozvoj vědy a < 1,5 dne
výzkumu
< 2 dny
< 1 den
Poškození pověsti
PR03 Podpora a rozvoj < 1 den
hospodářské činnosti
< 2 dny
< 1 den
Finanční ztráty
Tab. 12 - Souhrnná tabulka Analýzy dopadu (Zdroj: Autor)
Sloupec RTO udává maximální počet hodin/dní, za který je nutné obnovit chod podpůrných systémů.
Jestliţe v případě procesů PR01 Zajištění studia a PR02 Rozvoj vědy a výzkumu by byla potřeba chod
podpůrných systémů obnovit do dvou dnů, v případě procesu PR03 Podpora a rozvoj hospodářské
činnosti by tento čas měl být kratší, neboť narušení tohoto procesu vede k finančním ztrátám.
Ve sloupci WRT je stanoven maximální moţný čas potřebný k obnovení chodu celého procesu za
předpokladu, ţe podpůrné systémy jsou jiţ obnoveny. V případě procesu P01 Zajištění studia by mohl
být tento čas delší neţ v případě zbylých dvou procesů, neboť narušení procesu P02 Rozvoj vědy
a výzkumu a PR03 Podpora a rozvoj hospodářské činnosti má pro instituci větší dopady.
Obnova dat v případě jejich ztráty by probíhala nahráním z pásky. Tato obnova má jisté časové
poţadavky, celkové obnovení procesu by se proto pohybovalo spíše v řádech dnů, neţli hodin.
Důleţité je brát také v úvahu to, která data by měla prioritu pro obnovu. V případě obnovy dat
studijního informačního systému ISIS by prioritu měla studijní data, např. obnovení dat poštovních
schránek by bylo provedeno s niţší prioritou, a tedy později.
Na základě takto definovaných hodnot pro jednotlivé klíčové procesy lze stanovit prioritu, se kterou
by mělo dojít k obnovení chodu procesu. Zpravidla největší prioritu mají logicky procesy s nejkratší
poţadovanou dobou obnovy a/nebo s největšími finančními ztrátami.
Náklady
Stanovení RTO jednotlivých klíčových procesů je výsledkem rozhodnutí instituce. Optimální hodnota
RTO se často udává jako bod, kdy se finanční ztráta rovná nákladům na obnovení chodu procesu. Tato
vzájemná závislost je uvedena schematicky na následujícím grafu.
Náklady na
obnovu
Ztráty
organizace
Čas
Obr. 17 - Grafické znázornění vztahu mezi náklady na obnovu a ztrátou organizace (Zdroj: Autor)
-81/117-
Po stanovení optimálních hodnot je v rámci Analýzy dopadů potřeba také odhadnout zdroje a sluţby
nutné k tomu, aby byla činnost, resp. proces zcela obnoven.
Součástí první fáze ţivotního cyklu Business Continuity Managementu je také popsání specifických
rysů, které jsou společné pro oblast terciárního vzdělávání, na konkrétních podmínkách VŠE. Tato
specifika mají vliv na stanovení strategie Business Continuity a byla vymezena a popsána v kapitole
4.5. V následujícím textu jsou tato specifika popsána pro konkrétní případ VŠE:

SP01 Sezónnost – sezónnost se v podmínkách VŠE nejvíce projevuje ve
variabilitě poskytování sluţby, kterou je vzdělávání, a proto nejvíce rysů sezónnosti vykazuje
proces PR01 Zajištění studia. Ostatní procesy PR02 Rozvoj vědy a výzkumu a PR03 Podpora
a rozvoj hospodářské činnosti nevykazují takové výkyvy sezónnosti, ačkoli i u těchto procesů
je patrný propad ve frekvenci jejich vyuţívání v letních měsících.
Proces PR01 Zajištění studia má výkyvy nejen během letních měsíců, kdy probíhají prázdniny,
ale také se liší počty a potřeby studentů na začátku semestru, v jeho průběhu, na konci, během
zkouškového období či v období státních zkoušek.



SP02 Závislost na IT – závislost na IT se na VŠE stejně jako na ostatních institucích
terciárního vzdělávání zvyšuje. Důkazem je také to, ţe všechny klíčové procesy jsou
podporovány jedním nebo více informačními systémy. Zvyšuje se také vyuţívání IT při
jednotlivých činnostech, kdy je například moţné prostřednictvím studijního informačního
systému přihlašovat se na termíny zkoušek, přihlašovat se do vedlejších specializací nebo
sestavovat si rozvrh. V blízké budoucnosti je plánováno také začít s testováním studentů
pomocí informačního systému.
SP03 Konkurenční tlak – konkurenčnímu tlaku VŠE nečelí pouze ze strany ostatních státních
institucí, ale také ze strany soukromých vysokých škol, jejichţ počet v posledních letech
v České republice rapidně vzrostl. Tyto soukromé školy si postupně budují svou pověst,
získávají prestiţ a v mnohých případech také vyhrávají v „boji“ o studenty.
SP04 Inovace – VŠE by stejně jako kaţdá jiná instituce terciárního vzdělávání měla být
nositelem inovativních myšlenek. Protoţe VŠE však není školou technickou, ale primárně
ekonomickou, nepatří mezi přední představitele inovace v oblasti informačních technologií.
Náplní druhého kroku ţivotního cyklu BCM je určení samotné strategie BCM. Tato strategie by měla
vycházet z dokumentu Bezpečnostní politika VŠE. Na základě tohoto dokumentu je potom moţné
identifikovat moţné příčiny narušení klíčových procesů. Určení strategie BCM se týká všech aktiv
instituce, nejen technických zdrojů, ale také budov a zařízení, lidských zdrojů apod.
V podstatě existuje několik typů strategií BCM. Tyto strategie bychom mohli kategorizovat
následujícím způsobem [ICM2004]:





Přijetí rizik, neprovedení ţádné změny
Přijetí rizik, vytvoření vzájemné dohody o pomoci s jinou institucí
Sníţení rizik
Sníţení rizik a zajištění externí pomoci
Sníţení rizik a vytvoření prostředí pro interní pomoc
Jak jiţ bylo uvedeno v kapitole 1, nejčastější příčinou narušení běţné činnosti jsou incidenty jako
výpadek elektrického proudu nebo porucha vodovodního rozvodu. VŠE by na základě
identifikovaných moţných příčin a pravděpodobnosti jejich výskytu měla zhodnotit, zda by nebylo
vhodné vyuţívat datového úloţiště u externího poskytovatele. Tato datová úloţiště jsou umístěna
-82/117-
v jiné lokalitě, neţ se nachází instituce a především jsou většinou technicky natolik vybavena, ţe
dokáţou udrţet svůj chod ze záloţních zdrojů třeba i tři dny.
VŠE postupem času ustoupila od strategie záloţního prostředí, kdy byla data redundantně ukládána
v serverovém sále v areálu na Jiţním Městě. V současné době VŠE nemá ţádné záloţní prostředí.
Díky tomu, ţe je však připojena k akademické síti PASNET a posléze také k síti pro výzkum
CESNET2, bylo by moţné vytvořit záloţní prostředí v areálu jiné tuzemské instituce pro terciární
vzdělávání. Takové záloţní prostředí by mohlo být poskytováno institucemi navzájem, coţ by mimo
jiné vedlo ke zvýšení důvěryhodnosti obou stran.
Dalším důleţitým prvkem strategie BCM je určení krizového uspořádání instituce. To znamená, ţe by
mělo být stanoveno takové uspořádání, které by v případě krize neslo odpovědnost za její řešení
a navrácení chodu procesů do původního stavu. Součástí identifikace krizového uspořádání je
i definice klíčových osob, které by včetně svých zástupců a telefonních kontaktů měly být uvedeny na
seznamu, který by měl mít k dispozici kaţdý zaměstnanec.
Tato fáze ţivotního cyklu BCM navazuje na Analýzu dopadů provedenou v prvním kroku a upřesňuje
RTO (Recovery Time Objective) jednotlivých sluţeb. Díky tomu je moţné určit, s jakou frekvencí je
potřeba zálohovat a archivovat data instituce. V současné době na VŠE probíhá denní záloha dat,
v případě systému ISIS je to dokonce v intervalu 4 hodin. Data jsou zálohována v lokalitě Jarov
a posléze archivována.
BCM plán – Ztráta dat – postup pro prvních 24 – 48 hodin
Popis stavu


Poskytování sluţby vzdělávání je narušeno
Běţný průběh procesu je narušen z důvodu nedostupných/chybějících dat
Pravděpodobnost

nízká
Dopad

vysoký
Pravděpodobná
příčina

problém sítě
Dotčené procesy

PR01 Zajištění studia
Odpovědnost

odpovědná osoba XXX
Činnosti
Okamţitě


Během 24 - 48 hodin
kontaktování
Výpočetního
centra, oznámení problému,
doţadování se zálohy, je-li
dostupná
informování
ostatních
kompetentních
osob
o problému



navázání kontaktu se záloţní
lokalitou
obnovení
dat
z poslední
zálohy
neexistuje-li datová záloha,
obnovit data z papírových
dokumentů
Sníţení dopadu


častější zálohování
kopie dokumentů na lokální úloţiště, přenosná média (je-li to
umoţněno Bezpečnostní politikou)
Omezení

časový úsek doby obnovení dat
Zdroje

záloha dat
Tab. 13 - Příklad plánu BCM pro riziko ztráty dat (Zdroj: Autor)
-83/117-
Po té, co byla identifikována rizika, provedena Analýza dopadů a vydefinována strategie BCM, je
moţné vytvořit BC plán. Tento plán přenáší strategii BCM instituce do činností na taktické
a operativní úrovni, a udává tak, jak se mají zachovat jednotliví zaměstnanci.
Součástí plánu BC je také plán obnovy. Plán by měl být stručný, ale neměl by být zjednodušený. Při
sestavování plánu BC je třeba mít na mysli, ţe v případě potřeby budou zaměstnanci potřebovat jednat
rychle a účinně, je třeba proto zvolit vhodný formát plánu.
Ve výše uvedené tabulce je uveden příklad plánu BC pro případ, kdy by došlo k narušení procesu
PR01 Zajištění studia z důvodu rizika ztráty dat.
Z výše uvedené tabulky příkladu Business Continuity plánu pro výskyt určitého rizika je zřejmé, ţe
takový plán má zásadní vliv na doposud existující postup eskalace a řízení procesu, a to i v případě, ţe
ţádný plán eskalace a řízení doposud neexistoval.
Náplní poslední fáze ţivotního cyklu Business Continuity Management je pravidelné testování
jednotlivých scénářů, které byly definovány v rámci předchozí fáze. Testování je vyhodnoceno formou
záznamu a na základě jeho výsledku je rozhodnuto o aktuálnosti scénáře a jeho případné nutnosti
aktualizace. Tímto způsobem je moţné udrţovat plán Business Continuity aktuální.
7.2 OBLAST CLOUD COMPUTINGU
V rámci VŠE by bylo moţné vyuţívat celé řady Cloud Computing řešení. Instituce by mohla vyuţívat
nabízených aplikací pro komunikaci v rámci týmové spolupráce nebo ke sdílení souborů. V případě
tak velké společnosti, kterou je VŠE, je však vhodnější začít s implementací Cloud Computing řešení
v oblasti infrastruktury.
Důvody, proč by VŠE měla začít s vyuţíváním Cloud Computingu v oblasti infrastruktury lze shrnout
do následujících bodů:




instituce jiţ investovala určité finanční částky do své vlastní infrastruktury, a není proto
v jejím zájmu začít vyuţívat cizí prostředky, aniţ by současně neredukovala infrastrukturu
umístěnou v rámci společnosti,
instituce hledá účinný prostředek k tomu, jak efektivně vyuţívat své dosavadní zdroje a jak
sníţit náklady na tyto zdroje potřebné,
instituce operuje s mnoţstvím citlivých dat, které není alespoň z počátku vhodné přesouvat do
datových center externího poskytovatele,
instituce nehledá způsoby, jak začít vyuţívat Cloud Computing (nabídky dodavatelů na SaaS
řešení jsou nejčastějšími), ale jak sníţit své dosavadní náklady.
Z výše uvedených důvodů vyplývá, ţe efektivní vyuţívání vlastní infrastruktury je pro VŠE stěţejní
záleţitostí. Na základě kapitoly 5.2, kde bylo identifikováno, které Cloud Computing řešení by nejlépe
vyhovovalo VŠE a kapitoly 7.1, ve které byl demonstrován ţivotní cyklus BCM, by navrhovaná
strategie Cloud Computing řešení mohla být dosaţena v následujících krocích:
1. Virtualizace existujících serverů
2. Vytvoření privátního cloudu
3. Přechod do hybridního cloudu
3.1. Vyuţití nabídky externího poskytovatele IaaS
3.2. Vyuţití open sourceového nástroje pro integraci
3.3. Vyuţití nástroje pro governance řešení
-84/117-
V rámci informační strategie VŠE [VSE2010] bylo stanoveno několik cílů dalšího směřování VŠE.
Mezi těmito cíli je mimo jiné zmíněna virtualizace serverů a datových úloţišť, zavedení systému pro
řízení identit, udrţení funkčního a spolehlivého systému zálohování, archivace a udrţení a posilování
bezpečnosti IS/ICT. Tyto cíle jsou v souladu s řešením navrhovaným v této diplomové práci.
7.2.1 NAPLNĚNÍ PŘEDPOKLADU ŘÍZENÍ RIZIK
Před samotnou implementací Cloud Computing řešení by instituce terciárního vzdělávání měla provést
analýzu řízení rizik. Prvním krokem této analýzy je identifikace technologických aktiv (např. serverů),
které podporují klíčové procesy VŠE a identifikace dat na těchto aktivech umístěných.
Pokud hovoříme o vyuţívání Cloud Computing řešení na úrovni infrastruktury, je vhodné, aby
instituce provedla modelování hrozeb (Threat modeling). Pro to, aby byla VŠE schopna modelovat
hrozby na úrovni infrastruktury, je potřeba, aby znala jak IT procesy, tak procesy podnikové.
Výstupem činnosti modelování hrozeb je identifikace a ohodnocení hrozeb a zranitelností, které jsou
aktuální pro jednotlivé komponenty infrastruktury.
Proces modelování hrozeb v případě VŠE by sestával z několika kroků a měl přibliţně následující
podobu:
1. Identifikace bezpečnostních cílů
Bezpečnostními cíli se rozumí cíle a omezení, která jsou spojena s důvěrností, integritou a dostupností
dat a aplikací. Při definování bezpečnostních cílů je vhodné analyzovat situaci instituce z pohledu
omezení. Postupem „co bychom nechtěli, aby se stalo“ je moţné identifikovat, která bezpečnostní
opatření jsou nejdůleţitější.
V tomto kroku by se instituce měla zaměřit na to, která data jsou pro ni nejdůleţitější. Výsledkem by
mohly být následující cíle:



ochránit studijní data před útoky
zajistit dosaţení SLA jednotlivých sluţeb (např. dostupnost studijního informačního systému
ISIS)
udrţet dobré jméno VŠE
2. Vytvoření přehledu infrastruktury
V tomto kroku je potřeba vytvořit přehled o tom, jaká infrastruktura se na VŠE nachází. Pro vyuţití
v tomto praktickém příkladě je potřeba definovat, na kterých serverech se nacházejí studijní,
ekonomická a další data, která jsou výstupem klíčových procesů VŠE. Součástí tohoto přehledu by
měly být také informace o technologickém vybavení, např. operačních systémech na serverech
nainstalovaných, o bezpečnostním monitoringu nebo o protokolech a portech probíhající komunikace.
3. Vytvoření detailního pohledu na infrastrukturu
Tento krok logicky navazuje na krok předchozí, ale jde do většího detailu podrobnosti. V tomto kroku
je například vhodné identifikovat, jakým způsobem probíhá autentizace a autorizace uţivatel, jakým
způsobem probíhá datový tok, jak silná je ochrana dat pomocí firewallu apod.
Na takto vytvořený přehled infrastruktury je nutné navázat změny, které by v instituci proběhly
v případě, kdyby se rozhodla pro Cloud Computing řešení. Toto rozhodnutí by mělo vliv na způsob
autentizace a autorizace uţivatelů a na bezpečnost přenosu dat mezi interním prostředím za hranicemi
firewallu a externím datovým centrem.
-85/117-
4. Identifikace hrozeb
V tomto kroku jiţ instituce můţe identifikovat hrozby, které jsou spojeny s adopcí Cloud Computingu.
V případě VŠE jsou to hrozby, které souvisejí s vyuţíváním sluţeb IaaS. Tyto hrozby jsou výsledkem
předchozích kroků, navazují na definované bezpečnostní cíle v kroku 1 a berou v úvahu současnou
situaci infrastruktury VŠE.
Seznam hrozeb pro adopci IaaS řešení na VŠE by mohl mít následující podobu:

zneuţití a nezákonné pouţití Cloud Computing řešení – nejčastějším případem zneuţití
a nezákonného pouţití jsou spamy, škodlivý kód nebo prolomení hesel. VŠE se jiţ v současné
době podařilo úspěšně se bránit proti spamovým útokům pomocí nové metody vyhodnocování
spamových zpráv „greylisting“. [VC2010]
V případě, ţe by se VŠE rozhodla vyuţívat kapacitu externího poskytovatele pro navýšení své
vlastní kapacity např. v době zkouškového období, musela by uvaţovat o tom, jak by se tato
hrozba změnila, neboť by musela být některá data přesunuta do cloudu.




nedostatečné zabezpečení rozhraní – nedostatečné zabezpečení bylo zpočátku hrozbou týkající
se především PaaS řešení, v dnešní době se ale týká i IaaS. Předcházení a minimalizaci hrozeb
je moţné dosáhnout pomocí autentizace přístupů, bezpečnostního monitoringu a řízení
přístupů (IAM).
hrozba plynoucí ze sdílené infrastruktury – infrastruktura sdílená s ostatními zákazníky
externího poskytovatele je spíše psychologickou obavou, i kdyţ určité riziko ve sdílené
infrastruktuře opravdu je. Na druhou stranou je to však rozšířenost vyuţívání virtualizace
v rámci Cloud Computing řešení, která umoţňuje účinně oddělit aplikace od infrastruktury
a tím také sníţit riziko útoku.
ztráta nebo únik dat – díky vyuţívání Cloud Computing řešení by VŠE získala spolehlivé
úloţiště dat v odlišné lokalitě. Bylo by proto moţné omezit ukládání dat na lokální úloţiště
a zamezit ukládání citlivých dat na přenosná média, která by se mohla snadno dostat do cizích
rukou.
útok prostřednictvím uţivatelských účtů – tento útok je nejčastější hrozbou informačních
systémů. S vyuţíváním Cloud Computing řešení důvěryhodného externího poskytovatele by
se nemělo toto riziko zvýšit, naopak většina poskytovatelů nabízí účinné nástroje například
pro řízení identit, čímţ by VŠE dosáhla lepší bezpečnosti uţivatelských účtů.
5. Identifikace zranitelností
Identifikace zranitelností Cloud Computing řešení je prováděna obdobně jako identifikace hrozeb
v předchozím kroku. VŠE by měla hledat zranitelnosti v následujících oblastech:

Autentizace – v této oblasti by si instituce měla klást otázky:
o Jsou uţivatelská jména a hesla přenášena mezi interním a externím prostředím
v šifrované podobě?
o Kde jsou uţivatelská jména a hesla uloţena a jak jsou zabezpečena?
o Jsou uţivatelé nuceni pouţívat silná hesla? Jaké další moţnosti ochrany hesel jsou
implementovány?
o Jakým způsobem probíhá ověření správného přihlašovacího jména a hesla?
o Jak je autentizovaný uţivatel identifikován po prvotním přihlášení?
Odpovědi na tyto otázky přinášejí přehled zranitelností v oblasti autentizace. Zvlášť důleţité je
to, aby přenos mezi VŠE a poskytovatelem Cloud Computing řešení probíhal šifrovaně.
-86/117-

Autorizace – v této oblasti by si instituce měla klást otázky:
o Je vyuţíván řízený přístup pomocí rolí? Jsou tyto role dostatečně granulární tak, aby
bylo moţné řídit přístup a auditing?
o Je omezen přístup k databázi? Jak probíhá autorizace v přístupu k databázi?
Zranitelností v této oblasti je nedostatečně řízený přístup pomocí rolí. V mnoha případech
mají jednotlivé role zbytečně velká oprávnění a oprávnění kořenového administrátora nejsou
dostatečně oddělena. Cílem řízení přístupů ke kaţdému informačnímu systému je ten, aby
existoval pouze jeden uţivatel s nejvyššími právy a všem ostatním rolím byla přidělována co
nejniţší moţná práva.

Auditing – v této oblasti by si instituce měla klást otázky:
o Byly vydefinovány klíčové činnosti, které by měly být na pravidelné bázi auditovány?
o Jak jsou chráněny logovací soubory?
Zranitelností VŠE v této oblasti by mohla být neschopnost auditovat neúspěšná přihlášení
uţivatelů do informačního systému, neboť VŠE nemá implementován systém pro
bezpečnostní monitoring.

Absence IAM – řízení identit není na VŠE v současné době řešeno, i kdyţ je plánována jeho
implementace. Vyuţívání řešení externích poskytovatelů by bylo moţné řízení identit získat
zároveň s cloudovým úloţištěm.
7.2.2 NAPLNĚNÍ POŽADAVKŮ BCM NA ŘEŠENÍ CLOUD COMPUTINGU
V této kapitole bude zhodnoceno, jak vybrané řešení virtualizace serverů, vybudování privátního
cloudu a přechod do cloudu hybridního splňuje poţadavky BCM, které byly stanoveny v kapitole 3.3.
Na základě strategického postupu uvedeného v kapitole 7.2, na základě výsledků analýzy
poskytovatelů IaaS řešení provedeného v kapitole 6 a na základě zjištěných poţadavků kladených
BCM na Cloud Computing řešení bylo zvoleno následující řešení:




problematika samotné virtualizace serverů, resp. výběr řešení vhodného pro virtualizaci nebyl
předmětem této diplomové práce. Pro navrhované Cloud Computing řešení nehraje nástroj
virtualizace roli. Důvodem, proč nebyla tato problematika řešena, je také skutečnost, ţe
virtualizace serverů jiţ na VŠE v současné době probíhá.
pro vytvoření privátního cloudu bylo navrţeno řešení Eucalyptus, které je open sourceovým
projektem a které poskytuje podporu také pro vytvoření hybridního cloudu. Software
Eucalyptus byl původně vyvíjen jako součást akademického výzkumného projektu a v dnešní
době se dostává na přední pozice vedoucích technologií vyuţívaných v Cloud Computingu.
Řešení Eucalyptus je vhodné pro organizace velkých rozměrů, v podmínkách VŠE by
poţadavkům na vytvoření privátního, resp. hybridního cloudu vyhovoval.
na základě výsledků analýzy poskytovatelů IaaS řešení nejvíce vyhovuje podmínkám VŠE
a poţadavkům BCM řešení společnosti GoGrid. Jak je uvedeno v kapitole 6.9 Vzájemné
porovnání hodnocených řešení, GoGrid nejvíce naplňuje technická kritéria, kritéria BCM
i kritéria finanční. GoGrid řešení je také vhodné pro hostování hybridních cloudů.
k tomu, aby byly naplněny všechny poţadavky BCM na Cloud Computing řešení, je moţné
v další fázi vyuţít řešení pro governance enStratus. Toto řešení umoţňuje řídit a monitorovat
bezpečnost, řídit finance, audity, reporting a poskytuje jednotnou správu různých
poskytovatelů Cloud Computingu, např. pro pozdější rozšíření. Řešení enStratus naplňuje
všechny tři poţadavky BCM na Cloud Computing řešení P01 – P03.
-87/117-
7.2.2.1
P01 BEZPEČNOST A MONITORING
Bezpečnost a monitoring je moţné řešit několika způsoby. Vţdy by byl řešen interně v rámci VŠE, ale
při vyuţití nabídek externích poskytovatelů v rámci hybridního cloudu by byla bezpečnost řešena
prostředky dodanými poskytovatelem. Poskytovatel GoGrid je vlastníkem certifikace SAS70, coţ je
mezinárodně uznávaný standard vydaný americkým institutem certifikovaných auditorů AICPA.
Při vybudování privátního cloudu a vyuţití nástroje Eucalyptus je také moţné získat prostředky pro
řízení bezpečnosti, bezpečnostního monitoringu je však moţné dosáhnout pouze implementací
dodatečné vrstvy, kterou je například governance vrstva enStratus.
7.2.2.2
P02 ZÁLOHOVÁNÍ A ARCHIVACE
Kritéria pro zálohování a archivaci splňují všechna řešení. Díky virtualizaci serverů je moţné
zálohovat celé serverové instance stejně jednoduše, jako je moţné zálohovat jednotlivé soubory.
V případě vybudování hybridního cloudu a vyuţívání datového úloţiště externího poskytovatele by
VŠE navíc získala záloţní prostředí, které by mohla vyuţívat.
Záloţní prostředí by mohla VŠE získat také v rámci spolupráce s jinou institucí terciárního vzdělávání,
kdy by si tak obě instituce poskytovaly prostřednictvím sítě záloţní prostředí vzájemně.
7.2.2.3
P03 DOSTUPNOST SLUŽEB
Modelem hybridního cloudu se zvýší dostupnost poskytovaných sluţeb, a to především v obdobích,
kdy je informační systém VŠE nejvíce zatěţován. Tím by toto řešení podporovalo specifikum VŠE
SP01 Sezónnost. Po několik týdnů v roce, kdy jsou sluţby nejvíce vyuţívány, by tak nedocházelo
k přetíţení systému.
Díky získání dodatečné kapacity u externího poskytovatele by se VŠE mohla stát poskytovatelem
cloudových sluţeb externím zákazníkům, chovala by se tak trţně a získala by dodatečné příjmy.
7.2.3 BALANCED SCORECARD NAVRHOVANÉHO ŘEŠENÍ
Na Obr. 18 je schematicky znázorněna strategie postupu VŠE při implementaci Cloud Computing
řešení podporujícího Business Continuity Management. Pro schematické znázornění byl vybrán model
Balanced Scorecard. Jediná úprava, která byla provedena, je změna dimenze „Zákazníci“ na dimenzi
„Studenti“. Celkem je tak moţné zde nalézt čtyři dimenze: Zaměstnanci, Procesy, Studenti
a Hodnotové ukazatele.
V kaţdé z dimenzí jsou znázorněny cíle a metriky. Způsob dosaţení těchto cílů je uveden v posledním
sloupci. Strategická mapa je znázorněna tak, ţe první cíl je uveden v dimenzi Zaměstnanci, odkud
navazují jednotlivé hybné síly na ostatní dimenze.
Strategickým cílem v oblasti Zaměstnanci je „Zvýšení flexibility poskytovaných zdrojů“, čímţ se
myslí poskytování zdrojů jednotlivým katedrám. Tohoto cíle je moţné dosáhnout virtualizací stávající
infrastruktury.
Na tento cíl navazuje strategický cíl dimenze Procesy „Optimalizace vyuţívání zdrojů“. K dosaţení
tohoto cíle je jiţ zapotřebí vybudovat cloud, pro potřeby optimalizace je dostatečné vyuţívat privátní
cloud.
V dimenzi Studenti je umístěn cíl „Zvýšení dostupnosti sluţeb“. Tohoto cíle je moţné dosáhnout
vytvořením hybridního cloudu, kdy by VŠE získala dodatečnou výpočetní kapacitu od externího
poskytovatele.
-88/117-
Cíle
Metriky
Získání konkurenční
výhody
Získání
konkurenční
výhody
% získaných nových
studentů ve srovnání
s jinými vysokými
školami
Udržení
dobrého
jména VŠE
Otevření prostoru
pro poskytování
služeb externě
Snížení
nákladů
Hodnota
snížení nákladů
Zvýšení
dostupnosti
služeb
Zvýšení
spokojenosti
studentů
Vytvoření
hybridního
cloudu
Procesy
Optimalizace
využívání zdrojů
Optimalizace
využívání
zdrojů
Snížení počtu
serverů/zvýšení
využívání kapacity
Vytvoření
privátního
cloudu
Zvýšení flexibility
poskytovaných zdrojů
katedrám
Zvýšení
flexibility
poskytovaných
zdrojů
Zvýšení
spokojenosti
zaměstnanců
Virtualizace
existujících
serverů
Hodnotové ukazatele
Mapa strategie
Zaměstnanci
Měření přínosů navrhovaného řešení
Udržení dobrého
jména VŠE
Studenti
Snížení nákladů
Zvýšení
dostupnosti služeb
Realizace
Obr. 18 - Balanced Scorecard navrhovaného řešení (Zdroj: Autor)
Nejvýše umístěnými strategickými cíli jsou cíle v dimenzi Hodnotové ukazatele. Zde se nacházejí cíle
„Sníţení nákladů“, „Udrţení dobrého jména VŠE“ a „Získání konkurenční výhody“. Všechny tyto cíle
jsou pro VŠE ţádoucí. Díky sníţení nákladů si instituce můţe dovolit vynakládat finanční prostředky
na nákup jiného vybavení, díky udrţení dobrého jména VŠE by se jí naskytla moţnost poskytovat
cloudové sluţby externím odběratelům a získáním konkurenční výhody by VŠE vyhrávala
v konkurenčním boji o dobré studenty.
7.2.4 FINANČNÍ ZHODNOCENÍ
V této kapitole jsou stručně naznačeny cenové relace za odebírané sluţby. Rychlý přehled je uveden
v následující tabulce:
Název poskytovatele
Počet serverů
RAM
Cena [CZK / Cena [CZK /
měsíc]
rok]
Eucalyptus
-
-
-
1
GoGrid
<6
16 GB
71 862
862 344
enStratus
< 17
-
8 985
107 820
Celkem
-
-
80 847
970 164
Tab. 14 - Finanční zhodnocení navrţeného řešení (Zdroj: Autor)
Způsob platby za podporu k software Eucalyptus není bohuţel veřejně dostupný. Eucalyptus software
nabízí řešení ve dvou variantách. Tou první je open source řešení, které je zcela zdarma. Druhou
1
Ceny byly přepočítávány kurzem 1USD = 17,97 CZK
-89/117-
variantou je Eucalyptus Enterprise Edition, kde zákazník platí za podporu. V Enterprise edici je mu
navíc poskytována podpora více platforem.
U řešení GoGrid byla vybrána varianta poskytující 67 000 tzv. server RAM hodin za měsíc. GoGrid
rozumí jednou RAM hodinou běţnou hodinu krát velikost RAM na cloudových serverech:
1 𝑅𝐴𝑀 ℎ𝑜𝑑𝑖𝑛𝑎 = ℎ𝑜𝑑𝑖𝑛𝑎 𝑥 𝑅𝐴𝑀
V praxi to znamená, ţe počet cloudových serverů je variabilní. Je moţné za stejnou částku odebírat 6
serverů s velikostí RAM 16 GB, nebo 12 serverů s RAM o velikosti 8 GB apod.
Pro vstvu governance řešení enStratus byl zvolen plán Standard, kdy je za měsíční sazbu poskytováno
řešení pro neomezený počet serverových instancí, 60 záloh za měsíc (zálohy infrastruktury zahrnují
objem dat, image sluţeb nebo datových zdrojů), neomezený počet uţivatelských účtů, dodatečné
sluţby (LDAP, SAML 2.0, enStratus API) a monitorování serverů zdarma.
Celková cena je proto uvedena pouze orientačně, a to z výše uvedených důvodů. Cena by se změnila
také podle toho, kdy by se VŠE rozhodla vyuţívat kapacity externího poskytovatele pouze v období
nejvyššího zatíţení, coţ by znamenalo pouze minimální náklady na vyuţívané sluţby, ale zároveň by
to mohlo přinést komplikace v rámci přenosu dat z interního prostředí do prostředí externího a zpět.
7.3 SHRNUTÍ
Předmětem této kapitoly byl návrh vhodného řešení z několika pohledů. Nejprve byla provedena
analýza VŠE z hlediska Business Continuity Management. Postup byl proveden podle jednotlivých
fází ţivotního cyklu, ve kterých byly nejprve identifikovány klíčové procesy, následně byla provedena
analýza dopadů a načrtnut plán Business Continuity. K tomu, aby byl na VŠE plán Business
Continuity v současné době řešen, přispěla i skutečnost zavedení helpdesku v minulém roce (2009).
[VC2010] Bohuţel však dosud ţádný plán Business Continuity na VŠE neexistuje, zaměstnanci
(zejména vyučující) nemají ţádný scénář pro to, co dělat v případě, kdy by například nebyla data
ISISu dostupná.
Výsledkem zmapování této oblasti byla také identifikace specifik charakteristických pro VŠE. Pro
konkrétní podmínky VŠE byla navrţena strategie postupu při implementaci Cloud Computing řešení.
Tato strategie byla verifikována provedením modelování hrozeb pro naplnění předpokladu řízení rizik.
Pro jednotlivé fáze navrhované strategie byla vybrána konkrétní řešení od existujících poskytovatelů
a tato řešení byla verifikována oproti poţadavkům BCM na Cloud Computing řešení, které byly
definovány v kapitole 3.3.
Na závěr byla navrhovaná strategie znázorněna také pomocí Balanced Scorecard, kde je postavena
proti cílům a metrikám rozmístěným ve čtyřech dimenzích. Kapitolu uzavírá finanční hodnocení
navhrnovaného řešení.
Za současných podmínek na VŠE panujících lze definovat moţnosti Cloud Computingu podporovat
klíčové procesy následujícím způsobem:

PR01 Zajištění studia – v současné době není moţné tento proces zcela podporovat pomocí
Cloud Computing řešení. Studijní informační systém ISIS je v současné době postaven na
několika aplikačních serverech (v počtu cca 7 serverů), které by v případě potřeby zvýšení
kapacity mohly být doplněny virtuálními instancemi serverů v modelu Cloud Computing.
Problém však je to, ţe studijní informační systém ISIS vyuţívá pouze jeden databázový
server. Z tohoto důvodu by nedošlo ke zvýšení výkonnosti ISISu jako celku i v případě, ţe by
-90/117-
došlo k navýšení kapacity aplikačních serverů. K získání potřebné flexibility a výkonnosti by
bylo třeba implementovat virtualizaci na úrovni datového úloţiště.
Je však moţné uvaţovat o vyuţívání Cloud Computingu na počítačových učebnách.
V současné době se uvaţuje o virtualizaci koncových stanic. Na některých předmětech se jiţ
nyní vyuţívá virtualizace instancí, například pro správu databáze. Virtualizace by se mohla
v budoucnu stát prvním vývojovým krokem ke konceptu Cloud Computingu.


PR02 Rozvoj vědy a výzkumu – v současné době jsou katedrální servery a některé další
servery virtualizovány. Tyto virtualizované instance jsou poskytovány jednotlivým
pracovištím. Tato oblast by se proto mohla stát první oblastí, ve které by se dal implementovat
princip Cloud Computingu. Mimo jiné by bylo moţné dosáhnout lepšího přehledu
o poskytovaných instancích, o jejich bezpečnosti apod.
PR03 Podpora a rozvoj hospodářské činnosti – v případě ekonomického informačního
systému iFIS se setkáváme se stejným problémem, jako je tomu u ISISu. Tento systém
v současné době vyuţívá také pouze jeden databázový server, proto je bez virtualizace
datového úloţiště zvýšení výkonnosti celého systému z tohoto důvodu omezeno.
Díky moţnosti změny ekonomického prostředí v podmínkách terciárního vzdělávání lze předpokládat,
ţe v budoucnu pravděpodobně dojde také ke změně modelu poskytování sluţeb studentům. Jiţ
v blízké době je moţné, ţe studenti začnou platit školné, a stanou se tak plnohodnotnými zákazníky
institucí terciárního vzdělávání odebírajícími sluţbu, stejně tak jako je tomu v komerčním sektoru.
Proto je potřeba do budoucna přemýšlet o změně investic do technologie a o tom, zda je důleţité mít
všechny technologické zdroje umístěny v areálu VŠE.
Dalším předpokladem a pravděpodobným trendem je také to, ţe v budoucnu budou vznikat aplikace
psané přímo pro cloudovou platformu, jako je tomu jiţ v případě některých zahraničních univerzit
(Skandinávie, Německo, viz např. [Peritor2009]). Na tento fakt navazuje také skutečnost, ţe odborníci
v oblasti Cloud Computingu budou poptávanou pracovní silou, a proto by tato příleţitost během studií
mohla pomoci studentům v uplatnění na pracovním trhu.
V současných podmínkách by navrhovaná strategie stála za zváţení, ale situace na akademické půdě
VŠE a v rámci terciárního vzdělávání v České republice obecně není na takový trend připravena.
I kdyţ investice do vybudování hybridního cloudu nejsou zanedbatelné, vybudování takového řešení
by přineslo potenciál zlepšení současné situace a mohlo by instituci přinést pozitivní dopady pro
budoucí rozvoj.
-91/117-
ZÁVĚR
Tato diplomová práce se věnovala problematice vzájemného vyuţití konceptů Business Continuity
Management a Cloud Computing. V rámci této práce bylo stanoveno několik cílů. Tím prvním byla
identifikace vazby konceptu Cloud Computing na Business Continuity Management. Tento cíl byl
splněn nalezením tří základních oblastí, ve kterých se oba tyto koncepty prolínají. Mezi tyto oblasti
patří bezpečnost a monitoring, zálohování a archivace a dostupnost sluţeb.
Druhým cílem této práce byla charakteristika sektoru terciárního vzdělávání a snaha o vystihnutí
specifik tohoto sektoru v návaznosti na definované oblasti moţného propojení obou výše jmenovaných
konceptů. Tento cíl byl splněn v kapitole 4, kde byla vedle poţadavků definována také další specifika
sektoru terciárního vzdělávání, na které byl později kladen zřetel při výběru vhodného řešení
v konkrétních podmínkách.
Třetím cílem této práce bylo multikriteriální srovnání řešení Infrastructure-as-a-Service, a to
s ohledem na srovnání řešení jak podle technických a finančních kritérií, tak také podle kritérií, které
vycházejí z poţadavků kladených konceptem Business Continuity Management na Cloud Computing
řešení. Naplnění tohoto cíle je obsahem kapitoly 6 a její výsledek byl pouţit jako podklad pro návrh
praktického řešení.
Čtvrtým cílem této práce byla identifikace potenciálu Business Continuity Management a Cloud
Computing v podmínkách Vysoké školy ekonomické v Praze. Tento cíl byl naplněn v kapitole 5
identifikací moţných řešení vhodných pro zvýšení Business Continuity na VŠE.
Po splnění výše uvedených cílů bylo moţné navrhnout praktické Cloud Computing řešení pro
konkrétní podmínky VŠE. Toto řešení vychází nejen z výsledků předchozích kapitol, ale je také
zaloţeno na konkrétních podmínkách VŠE, které byly zjištěny na základě Informační strategie VŠE,
Výroční zprávy za minulý rok (2009) a několika schůzek se zaměstnanci Výpočetního centra.
Praktický návrh řešení byl zaměřen především na vyuţití konceptu IaaS v rámci Cloud Computingu,
které úzce souvisí s virtualizací a implementací hybridního cloudu. Bylo identifikováno, ţe podpora
dvou ze tří klíčových procesů VŠE pomocí Cloud Computing řešení by za současných podmínek
nebyla moţná, neboť oba dva hlavní systémy podporující tyto procesy vyuţívají pouze jednoho
databázového serveru. Nebylo by proto moţné navýšit výkonnost aplikací jako celku alespoň do té
doby, neţ by bylo rozhodnuto o virtualizaci datového úloţiště.
Třetí z procesů Rozvoj vědy a výzkumu by v dnešní době bylo moţné konceptem Cloud Computing
podporovat. V současné době jiţ probíhá virtualizace některých serverů pracovišť nebo alespoň
probíhají jednání o moţnostech virtualizace. Bylo by proto moţné začít princip Cloud Computingu
v této oblasti implementovat.
I kdyţ se zdá, ţe by nebylo moţné plně podporovat všechny tři klíčové procesy VŠE konceptem
Cloud Computing, navrhované řešení je v souladu s cíli stanovenými v Informační strategii VŠE. Mezi
těmito cíli je uvedena virtualizace serverů a datových úloţišť, zavedení systému pro řízení identit,
udrţení funkčního a spolehlivého systému zálohování, archivace a udrţení a posilování bezpečnosti
IS/ICT. Všech těchto cílů by bylo moţné dosáhnout implementováním navrhovaného Cloud
Computing řešení za současné podpory Business Continuity Management instituce. Stálo by proto za
zváţení, zda by nebylo moţné implementovat alespoň část navrhovaného řešení, která by tyto cíle
mohla zajistit.
Vedle technické stránky zhodnocení řešení je však také důleţité brát v úvahu stránku ekonomickou
a procesní. Díky tomu, ţe se v blízké budoucnosti změní ekonomické prostředí v sektoru terciárního
-92/117-
vzdělávání a studenti se stanou skutečnými zákazníky institucí, je moţné předpokládat, ţe také dojde
ke změně modelu poskytování sluţeb.
Nepochybně dojde také ke změně poptávky na trhu práce a studenti technických oborů budou
vyţadovat moţnost vzdělávat se v oblasti Cloud Computingu. I z tohoto důvodu by bylo vhodné zváţit
moţnost vyuţívání cloudových sluţeb, a to nejen na úrovni infrastruktury, ale také na úrovni
platformy a software.
Právě zaměření této práce na vyuţití Cloud Computing řešení v oblasti infrastruktury je hlavním
omezením této diplomové práce. Pro další rozšíření této problematiky lze navrhnout analýzu
vhodnosti vyuţití konceptu také na úrovni platformy a software. Dalšími omezeními této práce jsou do
jisté míry specifika VŠE. Lze předpokládat, ţe Cloud Computing by pro naplnění poţadavků Business
Continuity Management v prostředí jiné instituce terciárního vzdělávání měl zcela jiný potenciál.
-93/117-
POUŽITÁ LITERATURA
[Appavoo2010] APPAVOO, Jonathan. – WATERLAND, Amos. – SILVA, Dilma Da. – UHLIG,
Volkmar. a další. Providing a Cloud Network Infrastructure on a Supercomputer in
HPDC’10, červen 20–25, 2010. Chicago, USA. c2010. ISSN: 978-1-60558-9428/10/06.
[Assuncao2009] ASSUNCAO, Marcos Dias de. – COSTANZO, Alexandre di. Evaluating the CostBenefit of Using Cloud Computing to Extend the Capacity of Clusters in HPDC’09,
červen 11-13, 2009. Mnichov, Německo. c2009. ISSN: 978-1-60558-587-1/09/06.
[BCI2007] Good Practice Guidelines 2008: A Management Guide to Implementing Global Good
Practice in Business Continuity Management. Business Continuity Institute
Guidelines. c2007.
[BCI2010a] Good Practice Highlights 2010: Edited Highlights of the Good Practice Guidelines:
Global Edition. Business Continuity Institute Guidelines. c2010.
[Billsberry2004] BILLSBERY, B. Business Continuity Management. What? Why? How? VEGA
Group PLC, UK. Whitepaper. c2004. Dostupný z WWW: <http://www.vegagroup.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-activityinterface2010/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>.
-94/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-47048470-8.
[Katz2009] KATZ, Richard N. – GOLDSTEIN, Philip J. – YANOSKY, Ronald. Demystifying Cloud
Computing for Higher Education. EDUCAUSE Center for Applied Research.
Research
Bulletin.
c2009.
[cit.
2010-10-10].
Dostupný
z WWW:
<http://www.educause.edu/ir/library/pdf/ecar_so/erb/ERB0919.pdf>.
-95/117-
[Konstantinou2009] KONSTANTINOU, Alexander V. – EILAM, Tamar. – KALANTAR, Michael. –
TOTOK, Alexander A. a další. An Architecture for Virtual Solution Composition and
Deployment in Infrastructure Clouds in VTDC’09, červen 15, 2009. Barcelona,
Španělsko. c2009. ISSN: 978-1-60558-580-2/09/06.
[Lee2010] LEE, Gunho. – PARTHASARATHY, Ranganathan. – TOLIA, Niraj. – KATZ, Randy H.
Topology-Aware Resource Allocation for Data-Intensive Workloads. APSys 2010,
Indie. c2010. ISSN: 978-1-4503-0195-4/10/08.
[Lenk2009] LENK, Alexander. – KLEMS, Markus. – NIMIS, Jens. – TAI, Stefan. – SANDHOLM,
Thomas. What’s Inside the Cloud? An Architectural Map of the Cloud Landscape.
CLOUD’09. c2009. Vancouver, Kanada. ISSN: 978-1-4244-3713-9/09.
[Litoiu2010] LITOIU, Marin. – WOODSIDE, Murray. – WONG, Johny. – NG, Joanna. – ISZLAI,
Gabriel. A Business Driven Cloud Optimization Architecture in SAC’10, březen 22-26,
2010. Sierre, Švýcarsko. c2010. ISSN: 978-1-60558-638-0/10/03.
[Marks2010] MARKS, Eric A. – LOZANO, B. Executive’s Guide to Cloud Computing. John Wiley &
Sons, Inc., New Jersey. c2010. ISBN: 978-0-470-52172-4.
[Martanova2010] MARTANOVÁ, Kateřina. Vztah BCM a ITSCM. RWE Transgas, prezentace.
c2010. [cit. 2010-10-03].
[Mather2009] MATHER, Tim. – KUMARASWAMY, Subra. – LATIF, Shaled. Cloud Security and
Privacy: An Enterprise Perspective on Risks and Compliance. O’Reilly Media,
California, USA. c2009. ISBN: 978-0-596-80276-9.
[Osecky2009] OSECKÝ, Michal. Kategorizace služeb poskytovaných v rámci Cloud Computing.
Bakalářská práce na Vysoké škole ekonomické v Praze na Katedře informačních
technologií. c2009.
[Pirani2007] PIRANI, Judith A. - YANOSKY, Ronald. Shelter from the Storm: IT and Business
Continuity in Higher Education. Educause Center for Applied Research. c2007.
[Pohorelsky2002] POHOŘELSKÝ, Pavel. Zálohování a archivace dat. Mendlova zemědělská a
lesnická
univerzita
v Brně.
c2002.
Dostupný
z WWW:
<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-47063540-7.
-96/117-
[Stratus2010] Stratus Technologies. Server Virtualization and Cloud Computing: Four Hidden
Impacts on Uptime and Availability. Stratus Technologies WhitePaper. c2010.
Dostupný
z WWW:
<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-1626958.
[VSE2010] Informační strategie Vysoké školy ekonomické na období 2011 – 2015. Výpočetní
centrum, VŠE. Verze 1.2. Dokument před oficiálním vydáním. c2010.
[Wolf2005] WOLF, Chris. – HALTER, Erick M. Virtualization From Desktop to the Enterprise.
Apress, California, USA. c2005. ISBN: 1-59059-495-9.
[Wood2009] WOOD, Gary a kol. Security Implications of Cloud Computing. Information Security
Forum. c2009.
INTERNETOVÉ ZDROJE
[Amazon2010] Amazon.com. Webová prezentace. c2010. [cit. 2010-10-17]. Dostupný z WWW:
<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-computingsecurity-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-12education/>.
[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/>.
-97/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-vzdelavani6927>.
[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/cloudcomputing-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.
[cit.
2010-10-09].
Dostupný
z WWW:
<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-computinglaw-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-cehovolit-3129>.
-98/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. 201011-24]. Dostupný z WWW: <http://www.siliconfareast.com/crisis-management.htm>.
[Info2010] European Union defines cloud computing. Information Age. Únor, 2010. c2010. [cit. 201011-24]. Dostupný z WWW: <http://www.information-age.com/channels/data-centreand-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-1001]. 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-xaasfuture-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. 201011-20].
Dostupný
z WWW:
<http://msdn.microsoft.com/enus/library/ms978527.aspx>.
[Mitrano2010] MITRANO, Tracy. Outsourcing and Cloud Computing for Higher Education. c2010.
[cit.
2010-10-22].
Dostupný
z WWW:
<http://www.cit.cornell.edu/policies/publications/cloud/index.cfm>.
[Montero2010] MONTERO, Ruben S. Elastic Management of Computing Clusters. c2010. [cit. 201011-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.
2010-11-04].
Dostupný
z
WWW:
<http://www.infosysblogs.com/cloudcomputing/2009/05/hands_on_building_a_privat
e_cl_1.html>.
-99/117-
[Noska2010] NOSKA, Martin. 10 důvodů, proč je open source dobrou volbou in Computerworld.
Listopad,
2010.
c2010.
[cit.
2010-11-16].
Dostupný
z WWW:
<http://computerworld.cz/analyzy-a-studie/10-duvodu-proc-je-open-source-dobrouvolbou-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-continuityin-the-cloud-era/>.
[Pasnet2010]
PASNET.
Online.
c2010.
<http://www.pasnet.cz/pasnet/>.
[cit.
2010-12-04].
Dostupný
z WWW:
[Peritor2009] AWS Case Study: Peritor. Případová studie. Červen, 2009. c2009. [cit. 2010-11-22].
Dostupný z WWW: <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. 201010-03]. Dostupný z WWW: <http://securityworld.cz/securityworld/jak-zajistitkontinuitu-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/CloudComputing/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.
2010-10-21].
Dostupný
z
WWW:
<https://wiki.internet2.edu/confluence/display/itsg2/Cloud+Computing+Security>.
-100/117-
[Wang2009] WANG, Chenxi. Cloud Security Front And Center. Forrester Blogs. c2009. [cit. 201010-09].
Dostupný
z WWW:
<http://blogs.forrester.com/security_and_risk/2009/11/cloud-security-front-andcenter.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.
<http://www.webopedia.com>.
[cit.
2010-12-04].
Dostupný
z WWW:
[Xymon2010] Xymon. Systém pro monitorování systémů a sítě. Webová prezentace. c2010. [cit.
2010-10-31]. Dostupný z WWW: <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/>.
-101/117-
TERMINOLOGICKÝ SLOVNÍK
Termín
Zkratka
Význam
Analýza dopadů
-
Analýza zaměřená na identifikaci rizik, kterým je
společnost vystavena a která by mohla znamenat
náhlou
ztrátu
klíčových
funkcí
podniku.
[BusDict2010]
Application Programming
Interface
API
Soubor postupů, protokolů a nástrojů pro vývoj
softwareových aplikací. [Webopedia2010]
Authentication, Authorization,
and Accounting
AAA
Tři základní součásti protokolu zabezpečení online
transakcí (především při přenosu finančních dat): (1)
autentizace, (2) autorizace a (3) účtování.
[BusDict2010]
Balanced Scorecard
BSC
Praktika, která kombinuje výsledky minulého vývoje
společnosti (finanční kritéria) s budoucím vývojem
(např. spokojenost zákazníků, učení se organizace,
procesní oblast). [BusDict2010]
Best practices
-
Metody a techniky, kterými je moţné dosáhnout
lepších výsledků neţ za pouţití jiných.
[BusDict2010]
Bod obnovy
-
Objem nebo rozsah ztracených dat, který je
společnost ochotna tolerovat z hlediska nezbytných
podnikových systémů. [Snedaker2007]
Business Continuity
Management
BCM
Holistický přístup k řízení společnosti, jenţ
identifikuje potenciální dopady na organizaci, které
by mohly ohrozit efektivní fungování společnosti, a
poskytuje rámec pro vybudování pruţného systému
schopného reagovat na krizové situace, a hájit tak
zájmy zainteresovaných stran. [BCI2010b]
Business Impact Analysis
BIA
viz Analýza dopadů
Cache/cacheování
-
Vysokorychlostní mechanismus ukládání dat. Můţe
se jednat buď o vyhrazenou částí hlavní paměti, nebo
o samostatné zařízení poskytující úloţný prostor.
[Webopedia2010]
Cash flow
CF
Příjmové a výdajové finanční toky, které reprezentují
provozní činnosti firmy. V účetnictví je cash flow
rozdíl mezi objemem finančních prostředků
dostupných na začátku období a objemem prostředků
na konci tohoto období. [BusDict2010]
CESNET
-
Síť pro výzkum. CESNET je sdruţení zaloţené
vysokými školami a Akademií věd České republiky
v r. 1996. Provozuje a rozvíjí páteřní akademickou
počítačovou síť ČR. Současná generace sítě se
nazývá CESNET2. [CESNET2010]
-102/117-
Cloud
-
Síťový cloud. Tento pojem je pouţíván v oblasti
telekomunikace jako veřejný prostor na přenosových
linkách. V kontextu Cloud Computingu se pojmem
cloud rozumí veřejná nebo soukromá elastická
infrastruktura
poskytující
sluţby
několika
odběratelům a umoţňující přenos dat mezi subjekty.
[Webopedia2010]
Cloud Computing
CC
1. Umístění a přístup k aplikacím a datům pomocí
internetového prohlíţeče častěji, neţ pomocí
softwaru instalovaného na koncové stanici nebo na
serveru.
2. Na internetu zaloţené sdílení informací, IT zdrojů
a softwarových aplikací, které je poskytováno
koncovým stanicím a mobilním zařízením „na
poţádání“.
3. Vyuţívání internetu pro přístup k webovým
aplikacím, webovým sluţbám a IT infrastruktuře jako
ke sluţbě. [CC2010]
Cloudware
-
Software, který je provozován na serverech
umístěných v cloudu (viz cloud). [Webopedia2010]
Consumerization
-
Trend, kdy uţivatel začne pouţívat určitou
informatickou sluţbu ve svém soukromém ţivotě,
oblíbí si ji a postupně ji přenese do svého profesního
ţivota. [Bittman2008]
Continuity
Analysis
Requirements CRA
Analýza, která se vyuţívá k odhadu zdrojů a sluţeb,
které vyţaduje kaţdá činnost, aby mohla být
obnovena do běţného provozu organizace.
[BCI2010a]
Cost-benefit analýza
CBA
Proces vyčíslení nákladů a výnosů, které by přineslo
určité rozhodnutí, program nebo projekt v porovnání
s jinou alternativou. [BusDict2010]
Čas obnovy
-
Čas, za který je moţné obnovit narušené systémy a
zdroje, tj. systémový čas obnovy. [Snedaker2007]
Data mining
DM
Skupina databázových aplikací, které hledají skrité
vzorce ve skupině dat, která mohou být pouţita pro
předpověď budoucího vývoje. [Webopedia2010]
eXtensible Access
Markup Language
Control XACML
Jazyk poskytující stejnou definici jako SAML (viz
SAML), ale definuje navíc prostředek udrţení
bezpečnostní politiky organizace. [Key2003]
eXtensible Markup Language
XML
Specifikace vytvořená konzorciem W3C. Umoţňuje
návrhářům vytvořit vlastní tagy, definice, přenos,
validaci a interpretaci dat mezi aplikacemi a
organizacemi. [Webopedia2010]
Governance
-
Ustanovení politik a průběţné monitorování jejich
správné
implementace
v rámci
organizace.
[BusDict2010]
-103/117-
Grid computing
-
Způsob propojení sítě. Grid Computing spojuje
nevyuţívané cykly všech počítačů do sítě za účelem
vyřešení problému příliš velkého pro samostatný
stroj. [Webopedia2010]
Homomorfní šifrování
-
Způsob šifrování, kdy je na prostém textu provedená
specifická algebraická operace a jiná algebraická
operace je provedena na šifrovaném textu.
[Schneier2009]
Hosting
-
Spojení systémů, kdy uţivatel můţe přistupovat
k hostu (hostitelskému systému/počítači) vzdáleně.
Typicky nabízí infrastrukturu pro poskytování
sluţby. [Webopedia2010]
Identity & Access Management
IAM
Rámec podporující řízení elektronických identit a
přístupů. [TechTarget2010]
Informační
technologie
a
komunikační ICT
Obor nebo vývoj a vyuţívání technologie ke
zpracování informací. [Webopedia2010]
Information
Technology ITIL
Infrastructure Library
Široce uznávaný přístup k řízení IT sluţeb. Poskytuje
sadu best practices, je podporován a akreditován
mnoha
organizacemi,
stejně
tak
jako
implementačními nástroji a nástroji pro ohodnocení.
[Webopedia2010]
Infrastructure as a Service
IaaS
Poskytování virtuálního prostoru a ostatního
hardware a operačních systémů, které mohou být
řízeny
prostřednictvím
API
sluţeb.
[Rittinghouse2010]
Instant messaging
IM
Typ
komunikace
prostřednictvím
internetu
umoţňující navázat soukromou konverzaci s jiným
uţivatelem. [Webopedia2010]
In-house
-
Umístěný v rámci společnosti. [InvestorWords2010]
IT
Service
Management
Continuity ITSCM
Cílem procesu z rámce ITIL je podporovat celkový
proces Business Continuity Management zajištěním
všech IT procesů (systémy, síť, aplikace,
telekomunikace atd.). [ITSM2010]
Learning Management System
LMS
viz Řídící výukový systém
Linux
-
Volně distribuovatelný open source operační systém,
který lze spustit na mnoha hardwareových
platformách. [Webopedia2010]
Maximální tolerovatelná doba odstávky
Maximální doba, po kterou je business ochoten
tolerovat neexistenci nebo nedostupnost určité funkce
podniku. [Snedaker2007]
Maximum Tolerable Downtime
MTD
viz Maximální tolerovatelná doba odstávky
Middleware
-
Software, který spojuje dvě oddělené aplikace.
[Webopedia2010]
-104/117-
Mirroring
-
Proces kopírování dat z jedné lokace do úloţného
prostoru, a to v reálném čase. [Webopedia2010]
Modelování hrozeb
-
Proces optimalizace bezpečnosti sítě pomocí
identifikace cílů a zranitelností a moţností
minimalizace hrozeb. [TechTarget2010]
Ohodnocení rizik
-
Analýza,
která
je
pouţívána
k odhadu
pravděpodobnosti dopadu neznámé hrozby na určitou
funkci organizace. [BCI2010a]
One time password
OTP
Heslo, které je platné pouze pro jednu operaci
přihlášení. [TechTarget2010]
Open-source
OS
Program nebo software, kde je zdrojový kód
dostupný veřejnosti za účelem vyuţití a modifikace, a
to zdarma, bez poplatku. [Webopedia2010]
Operational Level Agreement
OLA
Smlouva, která definuje, jak IT skupiny v rámci
jedné organizace zajistí dodání/poskytování sluţby
nebo sady sluţeb. [TechTarget2010]
Outsourcing
-
Vyhledávání zdrojů mimo vlastní organizaci, obvykle
za účelem sníţení nákladů nebo vyuţití schopností
jiné entity. [Webopedia2010]
PASNET
-
Praţská
akademická
počítačová
síť.
Vysokorychlostní metropolitní síť určená pro přenos
obecných digitálních dat. Zajišťuje propojení
počítačových LAN sítí praţských pracovišť vysokých
škol a Akademie věd ČR. [Pasnet2010]
Pay-as-you-go
-
Metoda účtování za sluţby, kdy je odběratel účtován
za skutečný objem odebrané sluţby. [BusDict2010]
Phishing
-
Podvodné získání osobních nebo citlivých dat
z osobních počítačů. [BusDict2010]
Platform as a Service
PaaS
Umoţňuje zákazníkům vyvíjet nové aplikace za
vyuţití API, které je umístěno a konfigurováno u
poskytovatele sluţby. [Rittinghouse2010]
Pracovní čas obnovy
-
Čas, za který je nutné obnovyt všechny vstupy pro
proces, lidské zdroje, dokumenty, legislativní
zajištění apod. [Snedaker2007]
Random Access Memory
RAM
Typ paměti počítače, ke které je moţné přistupovat
náhodně, tj. bez závislosti na předcházejících bytech.
[Webopedia2010]
Recovery Point Objective
RPO
viz Bod obnovy
Recovery Time Objective
RTO
viz Čas obnovy
Red Hat Enterprise Linux
RHEL
Komerční distribuce Linuxu. [Webopedia2010]
Replikace
-
Proces vytvoření a řízení duplicitní verze datového
zdroje. [Webopedia2010]
-105/117-
Return on Investment
ROI
Výnosnost aktiv měřené jako poměr čistých příjmů
a průměrného zaměstnaného kapitálu. [BusDict2010]
Risk Assessment
RA
viz Ohodnocení rizik
Role Based Access Control
RBAC
Systém řízení přístupu ke zdrojům/aplikacím
zaloţený na uţivatelských rolích. [Webopedia2010]
Rollback
-
Navrácení uskutečněné činnosti za účelem provedení
nové nebo alternativní. [BusDict2010]
Řídící výukový systém
-
Systém pro správu, dokumentaci, reporting a řízení
programů školení, výuky, e-learningu apod.
[BusDict2010]
Security Assertion
Language
Markup SAML
Definuje, jak jsou identity a informace o přístupu
přenášeny a zprostředkovány mezi organizacemi,
aniţ by byla narušena jejich interní bezpečnost.
[Key2003]
Service Level Agreement
SLA
Smlouva mezi poskytovatelem sluţby a zákazníkem,
která
určuje
povahu,
kvalitu
a
rozsah
poskytované/odebírané sluţby. [BusDict2010]
Service Level Management
SLM
Monitorování a řízení kvality sluţeb za účelem
dosaţení KPI. [TechTarget2010]
Service Provisioning Markup SPML
Language
Jazyk zaloţený na XML umoţňující výměnu
informací mezi aplikacemi a organizacemi.
[TechTarget2010]
Simple Object Access Protocol
SOAP
Protokol definující přeposílání zpráv zaloţený na
XML. Je vyuţíván k šifrování informace posílané
prostřednictvím webové sluţby. [Webopedia2010]
Single sign-on
SSO
Autentizační proces, kde uţivatel/klient zadává jedno
uţivatelské jméno a heslo, a získá tak přístup
k mnoha aplikacím/zdrojům v rámci společnosti.
[Webopedia2010]
Software as a Service
SaaS
Software licencovaný třetí stranou, který je
zákazníkovi dostupný v případě potřeby. Většinou se
jedná o software poskytovaný prostřednictvím sítě
internet. [Rittinghouse2010]
Superpočítač
-
Rychlejší typ počítače. Jsou obvykle velmi nákladné
a běţí na nich specializované aplikace vyţadující
velký
objem
matematických
výpočtů.
[Webopedia2010]
SUSE Linux Enterprise Server
SLES
Komerční verze distribuce Linuxu. [Webopedia2010]
Threat Modeling
-
viz Modelování hrozeb
Virtual Machine
VM
Operační prostředí umístěné na jednom počítači,
které se chová, jako by bylo umístěné na
samostatném počítači. [Webopedia2010]
-106/117-
Virtual Machine Monitor
VMM
Hostující program,
násobného
počtu
[Webopedia2010]
Voice over IP
VoIP
Kategorie hardware a software, která umoţňuje
uţivatelům vyuţívat internetu jako prostředku pro
přenos
telefonních
hovorů
posíláním
dat
prostřednictvím IP. [Webopedia2010]
Web 2.0
-
Termín popisující druhou generaci WWW. Je
zaměřen na vzájemnou spolupráci lidí a sdílení
informací online. Uţivatelé se stávají tvůrci obsahu.
[Webopedia2010]
Work Recovery Time
WRT
viz Pracovní čas obnovy
-107/117-
který umoţňuje provoz
identických
prostředí.
PŘÍLOHA A – SWOT ANALÝZA INFORMATICKÝCH ÚTVARŮ
Strengths



Weaknesses
Opportunities







Výsledky dosaţené v minulých letech
Stabilní prostředí s velkou společenskou
prestiţí a existenční budoucností
Moţnost spolupráce se studenty
Platové podmínky v resortu školství
Technologická nekázeň
Stagnující
tendence
vynakládání
prostředků na informační technologie
Threats
Získávat zdroje financování z fondů
rozvojových projektů a grantů
Spolupráce se zahraničními univerzitami
Vyuţívat sluţeb CESNETu, PASNETu,
EUNISu
Vyuţívat slev pro školy




Zastarávání informačních technologií
Limitující systém odměňování
Neuváţený outsourcing
Očekávaný nárůst potřeby finančních
prostředků na provoz IS/ICT
Tab. 15 - SWOT analýza informatických útvarů (Zdroj: [VSE2010])
-108/117-
PŘÍLOHA B – SEZNAM SERVERŮ PROVOZOVANÝCH NA VŠE
Označení Operační systém
serveru
Popis serveru
A
Windows 2003
B
Windows 2000
Certifikační autorita
C
NetWare 6.5 SP5
Úloţiště SW balíčků distribuované skrze Novell Zenworks
D
Windows 2003
Cluster Lotus Notes, IMAP přístup
E
Windows 2003
Lotus Notes – veřejný přístup přes webové rozhraní
F
Windows 2003
Ekonomická agenda
G
Windows 2003
Úloţiště pro image stanice
H
NetWare 6.5 SP5
Novell e-directory
I
Solaris 9
Databázový server pro agendy PES, Výsledky
J
NetWare 6.5 SP5
Kopie serveru HAS pro Jiţní město
K
Solaris 9
Testovací DB server pro agendu PES, migrační DB pro ISIS
L
Windows 2003
Lotus Notes, poštovní server pro část zaměstnanců (1800 účtů)
M
NetWare 6.5 SP5
Home adresáře pro zaměstnance (Novell e-directory)
N
Windows 2003
Systém centrální správy karet
O
Windows 2003
Ekonomická agenda
P
NetWare 6.5 SP5
Novell e-directory
Q
NetWare 6.5 SP5
Webové stránky a frontend pro přístup přes netstorage.vse.cz
(Novell e-directory)
R
NetWare 6.5 SP5
Home adresáře pro studenty (Novell e-directory)
S
NetWare 6.5 SP5
Podpora tisku (Novell e-directory)
T
Windows 2000
Aplikační a databázový server pro agendu vstupů
U
Windows 2003
Server s lokální replikou Windows update a McAffee update
V
Windows 2003
Ekonomická agenda
W
Aplikační servery pro studijní agendu (ISIS)
X
Databázové servery pro studijní agendu (ISIS)
Tab. 16 - Seznam serverů na VŠE (Zdroj: [Trcka2009])
-109/117-
PŘÍLOHA C – STRUKTURA ROZHOVORU SE ZÁSTUPCI VÝPOČETNÍHO CENTRA VŠE
Pro rozhovor se zástupci Výpočetního centra VŠE byla sestavena struktura rozhovoru, kterou lze uvést
následujícím způsobem:
I.
Oblast Business Continuity Management
1. Existuje na VŠE dokument informační strategie?
2. Existuje plán Business Continuity definovaný pro VŠE?
3. Existuje plán zotavení z krize (Disaster Recovery)?
4. Bylo by moţné vyuţívat záloţního prostředí pro ukládání dat ve spolupráci s jinou českou
univerzitou?
5. Jakým způsobem probíhá v současné době archivace dat?
II. Oblast bezpečnosti
6. Je na VŠE prováděn bezpečnostní monitoring komponent (servery, síťové prvky)?
III. Oblast Cloud Computingu
7. Existují na VŠE takové servery, jejichţ kapacita není plně vyuţita?
8. Běţí na těchto serverech takové sluţby, které by bylo moţné přesunout do cloudu (tj. sluţby,
které nejsou zcela charakteristické pro VŠE)?
9. Bylo by moţné tyto servery virtualizovat a poskytovat cloudové sluţby jiným oddělením v
rámci VŠE?
10. Existují pro vytvoření privátního cloudu kapacity lidských zdrojů?
11. Byla by VŠE ochotna vyuţívat pro vybudování privátního cloudu open sourceových řešení?
12. Bylo by moţné pomocí konceptu Cloud Computing nabízet sluţby také externím subjektům?
13. Měla by VŠE zájem o to platit za sluţby modelem platby pay-as-you-go?
IV. Obecné otázky
14. Jaké jsou stanoveny strategické cíle pro VŠE v oblasti IT na rok 2011?
-110/117-
PŘÍLOHA D – PODPOROVANÉ OPERAČNÍ SYSTÉMY IAAS ŘEŠENÍ
Název OS
GoGrid
Amazon EC2
Rackspace
Cloud
Řešení
ReliaCloud ElasticHosts
Windows Server 2003
ano
ano
ano
ano
ne
Windows Server 2008
ano
ano
ano
ano
ano
Ubuntu
ne
ano
ano
ano
ano
Debian
ne
ano
ano
ano
ano
Gentoo
ne
ano
ano
ne
ne
CentOS
ano
ne
ano
ano
ne
Fedora
ne
ano
ano
ne
ano
RHEL
ano
ano
ano
ne
ne
SLES
ne
ano
ne
ne
ne
Tab. 17 - Podporované operační systémy IaaS řešení (Zdroj: Autor)
-111/117-
PŘÍLOHA E – UKÁZKA WEBOVÉHO ROZHRANÍ DOSTUPNÉHO IAAS ŘEŠENÍ
V rámci této diplomové práce byla testována funkcionalita nabízeného IaaS řešení od společnosti
ElasticHosts. Tato společnost nabízí řešení v rámci pětidenního trialu, ve kterém byla funkcionalita
testována. V rámci těchto testů byly prováděny pouze základní uţivatelské testy, zátěţové testy nebyly
součástí tohoto testování.
1. Přihlášení do webového rozhraní
Po zaregistrování se na stránkách společnosti ElasticHosts je moţné se přihlásit do webového rozhraní
ElasticHosts. Webové rozhraní je zobrazeno na následujícím obrázku.
Obr. 19 - Webové rozhraní (Zdroj: Autor)
-112/117-
2. Vytvoření vlastní instance serveru
Řešení nabízí několik moţností, jakým způsobem vytvořit instanci serveru. Je moţné vybrat z nabídky
předinstalovaných systémů, live CD Linux verzí nebo instalací systému z disku.
Co do nabídky operačních systémů je moţné vybrat z několika distribucí Linuxu nebo Windows
Server. Podrobnosti o podporovaných platformách ElasticHosts jsou uvedeny v příloze Příloha D –
Podporované operační systémy IaaS řešení.
Po zvolení názvu vytvářené instance, způsobu instalace operačního systému, typu operačního systému
a velikosti disku je moţné vytvořit vlastní instanci.
Na následujícím obrázku je zobrazena vytvořená instance včetně disku, který jí byl přiřazen.
Obr. 20 - Vytvoření instance (Zdroj: Autor)
-113/117-
3. Nastavení parametrů instance serveru
U zvolené instance lze dynamicky nastavit parametry CPU, přiřazené paměti, disků apod.
Obr. 21 - Nastavení parametrů instance (Zdroj: Autor)
4. Spuštění instance
Obr. 22 - Spuštění instance (Zdroj: Autor)
-114/117-
Instanci spustíme v Control Panel stisknutím tlačítka "Start". Společně s instancí je startován také disk,
který jí byl přiřazen v procesu vytváření nebo při změně konfigurace serveru. Po startu je instanci
přidělena IP adresa, na které je spuštěna.
K této IP adrese je moţné přistupovat pomocí specializovaných nástrojů, kterým je například
TightVNC.
Obr. 23 - TightVNC přihlášení (Zdroj: Autor)
Pomocí tohoto nástroje je moţné získat přímý přístup ke spuštěné instanci na úrovni administrátora.
Po úspěšné instalaci a spuštění instance dosáhneme například zobrazení uvedeného na následujícím
obrázku. Na obrázku je rovněţ naznačeno, ţe uţivatel má přístupová oprávnění na úrovni
administrátora systému.
Obr. 24 - Rozhraní instance (Zdroj: Autor)
-115/117-
5. Zjištění a správa účtování
Součástí webového rozhraní jsou také informace o způsobu účtování odebíraných sluţeb. Tyto sluţby
je moţné dynamicky aktualizovat v návaznosti na skutečně odebírané mnoţství.
Obr. 25 - Účtování sluţeb (Zdroj: Autor)
-116/117-
PŘÍLOHA F – ŠABLONA PLÁNU BUSINESS CONTINUITY
BCM plán – <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ě
Během <24 – 48 hodin>

<definujte činnosti, které
by měly být provedeny
okamţitě po vzniku rizika,
tj. během první hodiny>

Sníţení dopadu

<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>
<definujte
návazné
činnosti vedoucí k plnému
obnovení chodu dotčených
procesů>
Tab. 18 - Šablona plánu Business Continuity (Zdroj: Autor)
-117/117-

Cloud Computing jako nástroj BCM

Transkript

Podobné dokumenty

Více o vDR

Vše o Google Apps

KALENDÁŘ AKCÍ | EVENT CALENDAR HILTON PRAGUE

Bezpečnost cloud computingu - T