Stud 2014 02 IT IB Ucitelia

Projekt
Dokument
Vypracovanie tandardov zkladnch znalost, metodickch

materilov, analz dokumentov a svisiacich vykonvacch
predpisov a realizcia kolen pre oblas informanej
bezpenosti
tudijn materily k tandardom zkladnch znalost IB
Zmluva .
2012210205
Ministerstvo financi SR
KPMG Slovensko
Oprvnen osoby
Pavel Bojansk
Peter Bork
Zstupcovia oprvnench osb
Jn Hochmann
Rudolf Sedmina
Peter Bork prizvan
Riadiaci vbor
Pavel Bojansk,
Jn Hochmann,
Mojmr Kollr
(DataCentrum)
Koordintor projektu
Jn Hochmann
Manar projektu
Ivan Vazan
Michal Bubk
Peter Bro,
Ivan Vazan
Michal Bubk,
Ladislav Hudec,
Ivan Kopik,
Daniel Olejr
Michal Bubk,
Ladislav Hudec,
Ivan Kopik,
Daniel Olejr
Zmenov komisia
Akceptan tm
Peter Bro,
Petra Hochmannov
(CSIRT.SK),
Ivan Vazan
tudijn materily vypracoval odborn tm v zloen (bez titulov, poda abecedy):

Michal Bubk, Ladislav Hudec, Jaroslav Janek, Ivan Kopik, Daniel Olejr, Erik
Saller, Frantiek Sovi, Martin Stanek a Jozef Stanko.
Ministerstvo financi Slovenskej republiky
Informan bezpenos
tudijn materily pre kurzy informanej bezpenosti pre informatikov
nepecialistov v IB, pecialistov v IB a uiteov
Bratislava, december 2013
Publikcia je uren pre pracovnkov verejnej sprvy, prioritne pre astnkov vzdelvania
v informanej bezpenosti realizovanho Ministerstvom financi Slovenskej republiky, ktor je
gestorom pilotnho projektu v tejto oblasti. Vecn zameranie dokumentu vychdza z materilu
Nvrh systmu vzdelvania v oblasti informanej bezpenosti v SR, ktor bol schvlen
uznesenm vldy SR . 391/2009. Cieom dokumentu je prispie k rozvjaniu povedomia
a kompetentnosti v oblasti informanej bezpenosti a tm pomc vytvraniu bezpenho
prostredia v Slovenskej republike.
ZOSTAVOVATE
mim. prof. doc. RNDr. Daniel Olejr, PhD.
AUTORSK KOLEKTV
Ing. Michal Bubk, CISA, CISM, CRISC,
doc. Ing. Ladislav Hudec, CSc,, CISA,
RNDr. Jaroslav Janek, PhD.,
Mgr. Ivan Kopik, CISA, CRISC, CGEIT,
mim. prof. doc. RNDr. Daniel Olejr, PhD.,
Ing. Ivan Oravec,
Mgr. Erik Saller, CISA, CISM, CRISC, CISSP,
Ing. Frantiek Sovi, CSc.,
doc. RNDr. Martin Stanek, PhD., CISM,
Ing. Jozef Stanko, CISA, CISM, CRISC.
AKCEPTAN KOMISIA MINISTERSTVA FINANCI SR
Ing. Peter Bro,
Ing. Jn Hochmann
Ing. Petra Hochmannov
Mgr. Gabriela Krajoviov
Ing. Ivan Vazan
ODBORN GARANTI
doc. Ing. Ladislav Hudec, CSc,, CISA,
mim. prof. doc. RNDr. Daniel Olejr, PhD.,
JAZYKOV PRAVA: Rukopis nepreiel jazykovou pravou.
Rozmnoovanie a pravy textov v listinnej a elektronickej podobe, preberanie textov do inch
publikci a ich zverejovanie prostrednctvom webovch sdiel je mon len s psomnm
shlasom Ministerstva financi Slovenskej republiky a s uvedenm plnej citcie prslunho
textu.
2
Zklady informanej bezpenosti | MF SR
Obsah
1 Zklady informanej bezpenosti.........................................................................................12
1.1
vod do informanej bezpenosti...................................................................................12
Zkladn pojmy informanej bezpenosti ......................................................................13
1.2
2 Manament informanej bezpenosti ...................................................................................18

2.1
vod ................................................................................................................................18
2.2
Bezpenostn stratgia a bezpenostn politika organizcie ..........................................19
2.3
Implementcia Bezpenostnej stratgie/politiky.............................................................21
2.4
Zdroje na IB ....................................................................................................................22
2.5
Zapojenie zamestnancov do IB procesu..........................................................................23
2.6
Budovanie know-how v informanej bezpenosti ..........................................................25
2.7
Analza rizk ...................................................................................................................26
2.8
Bezpenostn opatrenia...................................................................................................29
2.9
Spravovanie rizk ............................................................................................................33
2.10
Bezpenostn audit .........................................................................................................34
2.11
tandardy ........................................................................................................................36
2.12
Certifikcia ......................................................................................................................38
2.13
Literatra .........................................................................................................................40
2.14
Prloha. Katalg elementrnych hrozieb .........................................................................42
2.15
Prloha. Zoznam zranitenost .........................................................................................43
2.16
Prloha. Obsah bezpenostnej politiky ............................................................................47
2.17
Prloha. Klasifikcia informcie a systmov ...................................................................48
2.18
Znalostn tandardy pre oblas IB ..................................................................................52

2.18.1 Zkladn oblasti znalost informanej bezpenosti ................................................52
2.18.2 Kategrie a roly pouvateov ISVS ......................................................................52
2.18.3 Charakteristika kategri a rol pouvateov ISVS a minimlne znalostn
poiadavky pre jednotliv roly .............................................................................................53
3 Architektra, modely a hodnotenie ......................................................................................69

3.1
vod ................................................................................................................................69
Architektra a komponenty informanho systmu........................................................69
3.2
3.2.1
Hardvr ...................................................................................................................70
3.2.2
Operan systm ....................................................................................................72
3.2.3
Databzov systm .................................................................................................75
3.2.4
Virtualizcia, cloud ................................................................................................76
3.2.5
Model klient-server ................................................................................................76
3.2.6
Bezpenostn funkcie vrstiev .................................................................................77
3.3
Hodnotenie systmov ......................................................................................................79

3.3.1
Funkn bezpenostn poiadavky ........................................................................80
3.3.2
Poiadavky na bezpenostn zruky ......................................................................82
3.3.3
Poiadavky na vyhodnocovanie PP a ST ...............................................................83
3.3.4
rovne hodnotenia (EAL) ......................................................................................83
3.3.5
Vznam a rizik hodnotenia produktov poda CC .................................................84
4 Riadenie prstupu .................................................................................................................86

4.5
QAA, STORK a federcia identity ...............................................................................104
4.9
Zoznam pouitej literatry ............................................................................................125
5 Aplikan bezpenos ........................................................................................................126

5.1
vod ..............................................................................................................................126
Zkladn bezpenostn hrozby pre aplikcie ................................................................126
5.2
5.2.1
Bezpenostn chyby v softvri .............................................................................127
5.2.2
Konfiguran chyby .............................................................................................127
5.2.3
Nedostatky v bezpenosti prevdzky ...................................................................127
Aplikan bezpenostn funkcie ...................................................................................128
5.3
5.3.1
Dleit vahy pri vobe bezpenostnch funkci ...............................................128
5.3.2
Aplikan bezpenostn funkcie ..........................................................................129
Typick zranitenosti aplikci a opatrenia proti nim ...................................................132
5.4
5.4.1
Typick zranitenosti aplikci .............................................................................132
5.4.2
Opatrenia na znenie dopadov aplikanch chb ...............................................138
5.5
Pouvanie otvorench tandardov ...............................................................................143
5.6
Tvorba informanch systmov (poiadavky Vnosu o tandardoch pre ISVS) .........145
5.7
Zoznam pouitch zdrojov............................................................................................149
6 Bezpenos prevdzky .......................................................................................................150

6.1
vod ..............................................................................................................................150
Procesy bezpenosti prevdzky.....................................................................................151
6.2
6.2.1
Pokrytie biznis procesov operciami IS ...............................................................151
6.2.2
innosti manamentu prevdzky .........................................................................152
6.2.3
Kontroln mechanizmy ........................................................................................153
6.2.4
Riadenie zmien .....................................................................................................157
6.2.5
Nstroje automatizcie manamentu prevdzky ..................................................161
6.3
Vyuitie tretch strn pri dodvke sluieb (outsourcing) ..............................................162

6.3.1
6.4
Rizik vyuitia tretch strn..................................................................................162
Ochrana proti kodlivmu kdu ....................................................................................162

6.4.1
Ochrana proti phishingu .......................................................................................164
6.4.2
Ochrana proti vrusom ..........................................................................................164
6.4.3 pecifick hrozby svisiace s pouvanm mobilnch zariaden a vzdialenou prcou

a opatrenia proti nim ..........................................................................................................165
Bezpenostn incidenty, zodpovednos za ich nahlasovanie a rieenie .......................165
6.5
6.5.2
Automatizcia detekcie a rieenia bezpenostnch incidentov ............................168
Redundancia sieovej infratruktry a zlohovanie dt ................................................168
6.6
6.6.1
Klastre s vysokou dostupnosou ..........................................................................169
6.6.2
Zlohovanie a obnova ..........................................................................................169
6.6.3
Diskov polia........................................................................................................170
6.6.4
Ukladanie a ochrana zlonch mdi ..................................................................170
6.7
Prenos a vmena informci ..........................................................................................171

6.7.1
Narbanie s pamovmi mdiami ......................................................................172
6.7.2
Pouvanie mobilnch zariaden a vzdialen prca ..............................................173
6.8
Monitorovanie a plnovanie kapact systmovch zdrojov ..........................................174

6.8.1
Procesy monitorovania hardvru ..........................................................................174
Zaznamenvanie udalost (logovanie) a monitoring bezpenostnch incidentov .........175
6.9
6.9.1
Zaznamenvanie chb a zlyhan...........................................................................178
6.10
Poiadavky zkona . 275/2006 Z. z. a vnosu o tandardoch pre ISVS v oblasti
bezpenosti prevdzky ...............................................................................................................179
6.10.1 Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o tandardoch
pre informan systmy verejnej sprvy ............................................................................179
6.11
Zver .............................................................................................................................181
6.12
7 Fyzick bezpenos ............................................................................................................183

7.1
vod ..............................................................................................................................183
7.2
Ciele fyzickej ochrany IKT ...........................................................................................184
7.3
Zkladn poiadavky na prostredie, v ktorom maj psobi IKT ................................185

7.3.1
Hrozby a ich nositelia a negatvne vplyvy ...........................................................185
Prehad zkladnch prvkov fyzickej bezpenosti .........................................................186
7.4
7.4.1
Mechanick zbrann prostriedky (MZP) ............................................................187
7.4.2
Technick zabezpeovacie prostriedky (TZP) .....................................................190
7.4.3
Podporn infratruktra ........................................................................................193
7.5
Bezpenostn perimeter, chrnen objekt a chrnen priestor .....................................195
7.6
Umiestovanie a prstup k IKT .....................................................................................197

7.6.1
Umiestovanie IKT ..............................................................................................197
7.6.2
Prstup k IKT ........................................................................................................198
7.7
pecifick opatrenia ......................................................................................................199

7.7.1
Rokovacie miestnosti - ochrana citlivch informci pri ich stnej prezentci...201
7.7.2
Elektromagnetick vyarovanie (EMV) ...............................................................203
7.8
Fyzick bezpenos dtovch centier ...........................................................................203
7.9
Zver .............................................................................................................................204
7.10
8 Kryptolgia I ......................................................................................................................206
8.1
vod ..............................................................................................................................206
8.2
Zkladn pojmy, kryptografick kontrukcie a ich ciele ..............................................206

8.2.1
ifrovanie .............................................................................................................206
8.2.2
Haovacie funkcie a autentizan kdy sprv ......................................................209
8.2.3
Digitlne podpisy .................................................................................................211
8.3
Protokoly .......................................................................................................................212
5
Hesl a kryptografick ke ........................................................................................215
8.4
8.4.1
Hesl .....................................................................................................................215
8.4.2
Ke ....................................................................................................................216
8.5
Zranitenosti a kryptografia ..........................................................................................218
8.6
tandardy a legislatvne poiadavky .............................................................................219

8.6.1
8.7
Legislatva SR ......................................................................................................220
Praktick rady na zver .................................................................................................221
9 Kryptolgia II .....................................................................................................................223
9.1
vod ..............................................................................................................................223
9.2
Symetrick kontrukcie .................................................................................................223

9.2.1
Blokov ifry ........................................................................................................223
9.2.2
Prdov ifry ........................................................................................................225
9.2.3
Haovacie funkcie ................................................................................................225
9.2.4
Autentizan kdy sprv ......................................................................................226
9.3
Asymetrick kontrukcie...............................................................................................227
9.3.1
Asymetrick ifrovanie.........................................................................................227
9.3.2
Podpisov schmy ................................................................................................228
9.3.3
Protokoly na dohodnutie ka ............................................................................228
9.4
Infratruktra verejnch kov....................................................................................229
9.5
Kryptoanalza a bezpenos kryptografickch kontrukci ..........................................231

9.5.1
Ekvivalentn dky kov ...................................................................................232
9.5.2
Ukladanie hesiel a kov ....................................................................................233
9.5.3
Implementan a prevdzkov slabiny.................................................................234
Ilustran prklady.........................................................................................................235
9.6
9.6.1
Vkonov porovnanie ..........................................................................................235
9.6.2
S/MIME ................................................................................................................236
9.7
Praktick rady na zver .................................................................................................237
9.8
Prlohy ilustran prklady .........................................................................................238
A RSA schmy .......................................................................................................................238

B PKI objekty a opercie ....................................................................................................240
10 Siete, internet a telekomunikcie .......................................................................................242
10.1
Systm DNS ..................................................................................................................242
10.1.1 Domny, subdomny a zny ................................................................................243
10.1.2 Preklad mena domny ..........................................................................................245
10.1.3 Zdrojov zznamy DNS .......................................................................................247
10.1.4 Sprvy DNS ..........................................................................................................248
10.1.5 toky na DNS Man in the Middle ....................................................................249
10.1.6 toky na DNS cache poisoning ........................................................................250
10.1.7 Pouit zdroje .......................................................................................................253
Bezpen elektronick pota .........................................................................................254
10.2
10.2.1 Elektronick pota MIME ....................................................................................255

6
10.2.2 Funkcie S/MIME ..................................................................................................259

10.2.3 Pouit zdroje .......................................................................................................263
10.3
Protokol HTTP ..............................................................................................................264

10.3.1 Zkladn koncepcia protokolu .............................................................................264
10.3.2 Formt sprvy iadosti .........................................................................................266
10.3.3 Formt sprvy odpovedi .......................................................................................269
10.3.4 Bezpenos a privtnos.......................................................................................272
10.3.5 Pouit zdroje .......................................................................................................274
10.4
Virtulne privtne siete VPN ........................................................................................275

10.4.1 Protokol L2TP ......................................................................................................277
10.4.2 Protokol IPSec ......................................................................................................281
10.4.3 Protokol SSL/TLS ................................................................................................285
10.4.4 Pouit zdroje .......................................................................................................290
10.5
Systmy na detekciu/prevenciu proti prienikom (IDS/IPS) ..........................................291

10.5.1 tandardn detekn mechanizmy .......................................................................292
10.5.2 Technolgie IDPS ................................................................................................293
10.5.3 Sieov IDPS ........................................................................................................294
10.5.4 Bezdrtov IDPS ..................................................................................................297
10.5.5 Pouit zdroje .......................................................................................................301
11 Plnovanie kontinuity innost ...........................................................................................302

11.1
vod ..............................................................................................................................302
11.2
Procesn cyklus BCM ...................................................................................................304

11.2.1 Riadenie BCM ......................................................................................................304
11.2.2 Ohodnotenie .........................................................................................................306
11.2.3 Plnovanie ............................................................................................................309
11.2.4 Implementcia ......................................................................................................311
11.2.5 Monitorovanie ......................................................................................................312
11.3
BCM v legislatvnych aktoch SR a tandardoch ...........................................................314

11.3.1 Vnos MFSR . 312/2010 o tandardoch pre ISVS .............................................315
11.3.2 Zkon . 45/2011 Z.z. o kritickej infratruktre ...................................................316
11.3.3 Zkon . 122/2013 Z. z. o ochrane osobnch dajov a o zmene a doplnen
niektorch zkonov ............................................................................................................316
11.3.4 Prehad tandardov pre oblas BCM....................................................................316
11.4
Zdroje a literatra ..........................................................................................................318
11.5
Prlohy ...........................................................................................................................319
11.5.1 Plny kontinuity innost ......................................................................................319
11.5.2 Plny obnovy ........................................................................................................322
11.5.3 Typy testov aknch plnov .................................................................................324
12 Legislatva a etika ..............................................................................................................326

12.1
vod ..............................................................................................................................326
7
Prehad veobecnej legislatvy vzahujcej sa na IB....................................................327
12.2
12.2.1 Trestn zkon a trestn poriadok .........................................................................327

12.2.2 Autorsk zkon a oblas duevnho vlastnctva ..................................................331
12.2.3 alie prva a povinnosti organizcie poda veobecnej legislatvy ...................334
pecializovan legislatva a oblasti pravy vo vzahu k IB .........................................334
12.3
12.3.1 Zkon . 275/2006 Z. z. o informanch systmoch verejnej sprvy a o zmene

a doplnen niektorch zkonov ..........................................................................................335
12.3.2 Vnos o tandardoch pre ISVS.............................................................................337
niektorch zkonov ............................................................................................................338
12.3.4 Vyhlka . 164/2013 Z. z. o rozsahu a dokumentcii bezpenostnch opatren 342
12.3.5 Zkon . 45/2011 Z. z. o kritickej infratruktre ..................................................342
In pecifick legislatva vo vzahu k IB ......................................................................343
12.4
12.4.1 Zkon . 215/2002 Z. z. o elektronickom podpise ...............................................344

12.4.2 Zkon . 215/2004 Z. z. o ochrane utajovanch skutonost ...............................347
12.4.3 Zkon . 351/2011 Z. z. o elektronickch komunikcich ...................................348
12.4.4 Zkon . 22/2004 Z. z. o elektronickom obchode ................................................350
12.4.5 Zkon . 576/2004 Z. z. o zdravotnej starostlivosti .............................................351
12.5
Prehad relevantnej legislatvy E vzahujcej sa na riadenie IB ...............................352
12.6
Vntorn legislatva organizcie v oblasti riadenia IB .................................................354
12.7
Anonymita a skromie vs. monitorovanie zamestnancov .............................................354
12.8
Etika a morlny kdex ..................................................................................................356

12.8.1 Morlne kdexy....................................................................................................357
12.8.2 Potaov kriminalita a etick hacking ...............................................................357
12.9
Verejn obstarvanie IKT .............................................................................................358
12.10
Forenzn analza...........................................................................................................360
12.10.1 Poiadavky na zaistenie dkazov pouitench v prvnych konoch .................360

12.11
Zver .............................................................................................................................362
12.12
13 Potaov kriminalita a jej vyetrovanie...........................................................................364

13.1
vod ..............................................................................................................................364
13.2
Predpoklady ochrany pred incidentmi ..........................................................................364
13.3
Potaov kriminalita...................................................................................................365
13.3.1 Digitlna stopa......................................................................................................365
13.3.2 Zbieranie digitlnych stp a zaobchdzanie s nimi ..............................................366
13.3.3 Zaisovanie dkazov bezpenostnch incidentov ................................................367
13.3.4 Analza digitlnych stop ......................................................................................368
13.3.5 Prprava na rieenie incidentov ............................................................................368
13.3.6 Identifikcia tonka ...........................................................................................369
13.3.7 Cena (za rieenie) bezpenostnho incidentu .......................................................370
8
13.4
Znaleck innos ...........................................................................................................371
13.5
CSIRT.SK .....................................................................................................................372
13.6
Kriminalistick expertza a policajn postupy ..............................................................373
13.7
Praktick rady o robi ..............................................................................................374
13.8
Zver .............................................................................................................................374
13.9
Literatra: ......................................................................................................................375
14 Prlohy ................................................................................................................................376
14.1
Strun vkladov slovnk informanej bezpenosti....................................................376
14.2
Anglicko-slovensk register .........................................................................................393
14.3
Zoznam skratiek ............................................................................................................402
vod
Tto kniha je venovan zkladom informanej bezpenosti (IB). Po obsahovej strnke pokrva
problematiku IB v rozsahu a na rovni stanovenej pripravovanmi znalostnmi tandardami MF
SR pre pecialistov IB a informatikov, ktor sa nepecializuj v IB organizci, ktor vlastnia
alebo prevdzkuj informan systmy verejnej sprvy. Primrne je uren ako tudijn materil
pre posluchov kurzov informanej bezpenosti, poriadanch MF SR v rmci projektu
Vypracovanie tandardov zkladnch znalost, metodickch materilov, analz dokumentov a
svisiacich vykonvacch predpisov a realizcia kolen pre oblas informanej bezpenosti.
Me tie posli inm zujemcom na prv oboznmenie sa s vznamom informanej
bezpenosti a lohami, ktor informan bezpenos riei.
Kniha pozostva z vodu, 12 kapitol a prloh. Problematika IB je vemi rozsiahla a rznorod.
Narui normlne fungovanie IKT toti mu prrodn vplyvy, technick poruchy, nemyseln
chyby pouvateov, zl organizcia prce, nedostatok zdrojov, kodliv softvr, cielen toky
hackerov. Preto aj ochrana IKT vyuva mnostvo rozlinch rieen od obyajnej kontroly
zamestancov a nvtevnkov na vrtnici, cez organizan opatrenia typu nenechvaj svoj pota
zapnut, ke na chvu opust pracovisko a po drah a sofistikovan systmy na detekciu
pokusov o naruenie IKT. Aby si vedel itate predstavi, o vetko me IKT ohrozova, ako sa
proti tomu brni, ako zladi jednotliv opatrenia do celistvho systmu, v prvej kapitole
uvdzame strun prehad informanej bezpenosti a vysvetujeme zkladn pojmy IB. V
alch kapitolch sa potom zaoberme jednotlivmi oblasami IB podrobnejie.
Druh kapitola je venovan manamentu informanej bezpenosti, t.j. tomu, ako od jednotlivch
ad hoc rieen a neustleho pltania bezpenostnch dier prejs k systematickmu, efektvnemu a
udratenmu rieeniu IB v organizcii.
Kee kniha je uren aj pre itateov, ktor nemusia ma informatick vzdelanie, v tretej
kapitole strune (a dfame e na prijatenej rovni) popisujeme potae, ich programov
vybavenie, najdleitejie typy aplikci a potaov siete, aby itate ziskal ucelenej pohad
na IKT a vedel si predstavi, ako funguj informan a komunikan systmy, resp. ke budeme
hovori o monch tokoch a obrane proti nim, aby si vedel predstavi, na o s zameran toky
a ak monosti ochrany poskytuj/podporuj jednotliv komponenty IKS. itatelia, ktor maj
potrebn znalosti o IKT, mu zaiatok tejto kapitoly preskoi a preta si asti venovan
certifikcii systmov.
Vea tokov na IKT si vyaduje, aby tonk k nim mal prstup (k fyzickmu zariadeniu, alebo
do systmu napr. prostrednctvom potaovej siete). Prv lnia ochrany je jasn, nepusti dnu
nepovolanho loveka, neumoni mu nieo robi so systmom. Na to sli riadenie prstupu,
ktor aj ben pouvate pozn a vyuva pri prihlasovan sa do systmu prostrednctvom mena
a potvrdzovan svojich oprvnen pomocou hesla. tvrt kapitola pojednva strune, nzorne o
riaden prstupu a metdach, pomocou ktorch sa uplatuje.
Len mlo organizci vysta so tandardnm programovm vybavenm svojich potaov. Na
spracovanie dajov zva pouvaj rzne pecializovan softvrov aplikcie. Piata kapitola je
venovan aplikanej bezpenosti, t.j. bezpenostnm problmom v priebehu ivotnho cyklu
aplikcie a ich rieeniam.
Bezpenos prevdzky, ktor je pre zaistenie bezproblmovho chodu IKS organizcie podstatn,
je sce skr zleitosou informatikov ako ostatnch zamestnancov organizcie, ale aj vedci
pracovnci potrebuj ma aspo rmcov prehad o innostiach, ktor maj riadi. Minimum
prevdzkovej bezpenosti je uveden v iestej kapitole.
Aj ke je informcia v elektronickej podobe neviditen, technick zariadenia, pomocou ktorch
sa spracovva a pamov mdi, na ktorch sa uchovva, s fyzick objekty, ktor psobia v
relnom svete a s vystaven jeho psobeniu. Viacer negatvne faktory sa mu uplatni prve
voi materilnym komponentom IKT. Siedma kapitola pojednva o fyzickej bezpenosti a
10
zaober sa hrozbami, voi ktorm sa d brni prostrednctvom opatren fyzickho alebo

organizanho charakteru.
Kryptografia (veda o ifrovan) poskytuje IB viacero cennch a nenahraditench prostriedkov na
ochranu obsahu dajov pred nepovolanmi osobami, vylenie monosti nepozorovanej zmeny
dajov, podvrhnutia falonej sprvy a i. Zkladom kryptografie a spsobom, ako pouva
kryptografick mechanizmy v bench aplikcich je venovan sma kapitola, vybran problmy
kryptolgie s potom podrobnejie rozobrat v kapitole 9.
Internet a potaov siete vytvorili prepojenm jednotlivch systmov globlny virtulny priestor
a otvorili nebval monosti pre vyuvanie IKT (komunikcia, informan zdroje, vzdelvanie,
obchodovanie, zbava). Prleitosti sa vak chopila aj druh strana, hackeri, teroristi, podvodnci,
zlodeji, skrtka zloinci, ktor potencil potaovch siet a Internetu znauvaj na vlastn
nekal ely. Desiata kapitola je uren tm, o v organizcii zodpovedaj za prevdzku a
bezpenos IKT. Obsahuje podrobn vklad piatich vybranch tm, ktor s z hadiska
bezpenosti potaovch siet kov.
Bez IKT u dnes vina organizci nedoke dlhodobo fungova. Napriek najlepej snahe me
djs ke bezpenostnmu incidentu, ktor vyrad IKT organizcie z innosti (napr. poiar,
zplava, teroristick tok, havria). Organizcia mus rta aj s takouto krajnou monosou a ma
pripraven postup na okamit rieenie prebiehajceho bezpenostnho incidentu, ktorm by
mala zmierni jeho dopad a minimalizova kody. Takisto by mala ma definovan postupnos
krokov na odstrnenie nsledkov bezpenostnho incidentu, aby o najskr mohla zaa
fungova v nhradnom reime a o najrchlejie obnovila pln prevdzku (aj) svojich IKT
(zachovala kontinuitu svojej innosti). Jedensta kapitola sa zaober plnovanm kontinuity
innosti.
Do virtulneho priestoru sa presunuli dokumenty a innosti, ktor maj prvnu vhu. Existuje
viacero zkonov, ktor priamo upravuj spsob, ako naklada s informciou v elektronickej
forme a chrni systmy, v ktorch sa spracovva. V klasickom svete papierovch dokumentov a
runho spracovania informcie sa stroia vyvjali pravidl narbania s dokumentami a ochrany
ich obsahu. IKT existuj len pr desiatok rokov a hoci aj v nich existuj bezpenostn
mechanizmy na ochranu informcie, zatia sa nestihli dosta do veobecnho povedomia tak ako
s znme postupy a prostriedky ochrany sveta papierovch dokumentov. Dvansta kapitola je
venovan zkonnm poiadavkm na ochranu virtulneho priestoru (IKT a informcie, ktor sa v
nich spracovva). Vo virtulnom svete podobne ako v relnom svete nie je spoluitie osb mon
v plnom rozsahu upravi zkonmi a mnoh dleit vzahy s postaven na morlke a etike. Morlke a etike virtulneho priestoru je venovan zver 12. kapitoly.
Aj keby sa podarilo zkonmi ustanovi dokonal pravidl upravujce vzahy v digitlnom
priestore, vdy sa njdu udia, ktor ich bud obchdza. Aby bolo mon inne presadzova
prvo aj v digitlnom priestore je potrebn vedie dokza, e bol poruen zkon, kto to spravil
a zaisti dkazy, aby bolo mon pchatea sdne stha. Hoci sa aj v digitlnom priestore
pchaj klasick, ekonomicky motivovan zloiny, pchatelia pouvaj in prostriedky ako v
relnom svete a preto si aj rieenie potaovej kriminality vyaduje pecifick postupy.
Potaovej kriminalite je venovan posledn, 13. kapitola.
11
1 Zklady informanej bezpenosti

Daniel Olejr
1.1 vod do informanej bezpenosti

Pri plnen svojich loh potrebuj organizcie spracovva mnostvo rozlinch informci.
Rozsah potrebnch informci v mnohch z nich dvno presiahol monosti runho spracovania,
a preto sa hadali monosti, ako potrebn informcie spracovva efektvnejieho. Rieenie
priniesol rozvoj a nasadenie informanch a komunikanch technolgi (IKT, ktor predstavuj
spojenie potaov, telekomunikanch siet a masovokomunikanch prostriedkov). Masov
nasadenie IKT vak nevyrieilo len kapacitn problm, ale spsobilo hlbok zmeny v metdach
spracovania informcie a znamenalo koniec mnohch tradinch postupov zaloench na
papierovch dokumentoch. Informcia sa dnes zva kduje 1 digitlne, zaznamenva
v elektronickej forme, prena pomocou siet a spracovva (automaticky alebo poloautomaticky
za asti loveka-opertora) pomocou potaov. Papierov forma bva nanajv na zaiatku a
obas aj na konci celho procesu, ale informcia sa z papierovho sveta presahovala do
virtulneho priestoru. Tm sa na jednej strane podstatne zvila efektvnos spracovania
informcie (mnostvo informcie a rchlos jej spracovania), ale na druhej strane nebvalo
narstla zranitenos organizcie (a v konenom dsledku aj celej spolonosti). Porucha,
vpadok, kompromitcia, i znienie informanch a komunikanch systmov (IKS) me
vne ohrozi organizciu, znemoni, alebo aspo vrazne obmedzi jej innos (predstavme si,
o by znamenal vpadok riadiaceho systmu atmovej elektrrne, leteckho dispeingu,
bankovho systmu, daovho systmu, komunikanho systmu telekomunikanho opertora,
poty a pod.) Vzhadom na objem dajov, ktor je potrebn priebene/pravidelne spracovva,
nie je nvrat k runmu spracovaniu informci mon, a preto normlny chod organizcie, ale aj
celej spolonosti zvis do znanej miery od spoahlivho fungovania IKT. IKT s dnes kritickou
infratruktrou spolonosti; a to tak tie, od ktorch zvis fungovanie informanej
a komunikanej infratruktry spolonosti, ale aj tie, ktor podporuj innos dleitch
neinformanch systmov spolonosti. Nutnou podmienkou na to, aby spolonos, jej
intitcie, ale aj skromn firmy a obania mohli existova a pracova bez problmov, je
zaistenie spoahlivho fungovania informanej a komunikanej infratruktry spolonosti.
Vzhadom na vzjomn prepojenos systmov sa nesta obmedzi na ochranu vybranch
systmov, ale je potrebn v primeranej miere chrni vetky informan a komunikan systmy,
(IKS) ktor sa nachdzaj v digitlnom priestore SR a navye spolupracova so zahraninmi
partnermi na ochrane globlneho digitlneho priestoru, pretoe nedostatone chrnen IKS sa
me nielen sta obeou tonka, ale aj nstrojom, ktor tonk vyuije na tok na in,
vznamnejie IKS.
IKS s zloit, rozsiahle, vzjomne prepojen, pracuj s nimi asto krt laick pouvatelia,
ohrozuj ich prrodn ivly, technick poruchy, udsk chyby a omyly, kodliv softvr,
cieavedom toky konkurencie, nespokojnch zamestnancov, zlodejov, hackerov, i inch
protivnkov. Zabezpei ich spoahliv fungovanie si vyaduje, aby kad pouvate IKT
primerane svojim monostiam, vedomostiam a postaveniu prispieval k ich ochrane. V tejto
knihe budeme hada odpove na otzky o je informan bezpenos, ako sa d zaisti ochrana
IKS v organizcii, ak lohy pri zaisovan informanej bezpenosti v organizcii vyplvaj pre
zamestnancov organizcie z ich pracovnho zaradenia a napokon o, preo a akm spsobom m
pouvate robi na zaistenie ochrany IKS, s ktormi pracuje, resp. za ktor zodpoved.
t.j. zapisuje pomocou sel, ktor sa ete reprezentuj v dvojkovej sstave, to znamen, e v konenom
dsledku sa zapisuje pomocou slic 0 a 1
12
1.2 Zkladn pojmy informanej bezpenosti

V tejto asti zavedieme a vysvetlme zkladn pojmy z informanej bezpenosti 2. Podobne ako
samotn informan bezpenos (ako oblas udskej innosti), tak aj terminolgia informanej
bezpenosti je v sasnosti vo fze rchleho a trocha chaotickho vvoja. Je to spsoben
multidisciplinrnym charakterom informanej bezpenosti a pouvanm pojmov z inch
discipln asto krt v inom vzname ako mali pvodne; ale najm rchlym vvojom informanej
bezpenosti, ktor prina denne nov nepomenovan skutonosti, pre ktor ich objavitelia neraz
zavdzaj pojmy bez oividnej logickej svislosti (ping of death, spam, smurf attack 3). Slovensk
terminolgia informanej bezpenosti zatia neexistuje, ale vyhneme sa pokueniu vytvra
originlne slovensk termny, ktorm nebude nikto rozumie ani ich pouva a budeme radej
vychdza z aktulnej medzinrodnej terminolgie. Pri vysvetovan zkladnch pojmov sa
nevyhneme nutnosti pouva alie odborn (zva informatick) pojmy. Aby sme itatea
nezahltili prlinm mnostvom podrobnost, vetky pouit odborn pojmy (vysdzan
kurzvou) njde vo vkladovom slovnku.
Zkladnm pojmom je informcia. Vyhneme sa veobecnm filozofickm defincim4 a budeme
vychdza z toho, e s informciou budeme potrebova pracova, a teda informcia mus
existova v podobe, alebo sa da transformova (lovekom, technickm zariadenm, potaovm
programom) do podoby, ktor alie spracovanie umouje. Budeme preto predpoklada, e
informcia je zaznamenan v podobe dajov, ktor maj podobu konench postupnost znakov
nad nejakou konenou abecedou. T ist informcia me by zapsan pomocou rznych
dajov; slo 100 sa d vyjadri slovne: sto, , one hundred, ein hundert, zapsa pomocou
rmskej slice C, v hexadecimlnom vyjadren ako 0x64 a podobne. daje budeme teda chpa
ako zpis informcie a informciu ako obsah dajov. Informcie zskavame rozlinm spsobom
aby sme vetky monosti pokryli bez nutnosti zachdzania do detailov, budeme predpoklada,
e existuj zdroje informcie, z ktorch informciu dokeme zska a zaznamena v podobe
dajov. Informcia je zriedkavo priamo pouiten na mieste, kde sme ju zskali, a preto ju
potrebujeme prena na in miesto, kde ju spracovvame. Informciu prename pomocou
prenosovho kanla spjajceho zdroj informcie a prjemcu informcie (miesto spracovania).
Informcia sa prenosovm kanlom prena bu v podobe dajov zaznamenanch na nejakom
materilnom nosii (list papiera, DVD, USB) alebo prostrednctvom signlov
(elektromagnetickch, svetelnch zvukovch a i.) riacich sa prenosovm kanlom (kovov
alebo optick vodi, vzduch, kozmick priestor). Prenosov kanl je okovek (technick
zariadenie, posol, priestor) o je schopn prenies daje (pri prenose nazvan sprvou) z miesta
A (zdroj) na miesto urenia B (prjemca). daje pritom nemusia obsahova informciu v podobe,
ktor by umoovala jej bezprostredn vyuitie a tak je potrebn ich/ju spracova. Spracovanm
informcie v zkom zmysle rozumieme tak opercie s dajmi ako s triedenie, spjanie, vber,
preusporiadanie, vytvranie novch dajov na zklade starch, teda v podstate transformcie
dajov. V irokom zmysle pod spracovanm informcie rozumieme zber, prenos, samotn
spracovanie 5, uchovvanie, archivciu a nienie dajov. Informcia sa nemus poui ihne po
zskan a spracovan, me by zaznamenan vo forme zpisu dajov na nejakom pamovom
mdiu pre neskorie pouitie (uchovvanie dajov). Ak nie je predpoklad, e sa informcia bude
na nieo pravidelne pouva, ale mono oakva, e raz za nejak as bude potrebn ju vyui,
potom sa archivuje. Archivcia dajov sa od uchovvania dajov li najm dostupnosou:
uloen daje s spravidla dostupn v podstatne kratom ase ako archivovan daje a aj
oprvnenia na prstup k uloenm a archivovanm dajom sa spravidla lia. Ak nie je dvod na
archivovanie informcie (napr. uplynula zkonn lehota ich povinnho uchovvania a nechceme
vynaklada prostriedky na udriavanie archivovanej informcie, alebo sa obvame, e padne do
nepovolanch rk), daje sa niia. Nienie dajov je jednosmern proces, ktorho lohou je
samotn pojem informanej bezpenosti zavedieme v zvere tejto asti
ping smrti, spam = druh msovej konzervy, molkovsk tok
4
informcia je definovan o.i. ako obsah odrazu
5
v zkom zmysle
2
3
13
zaisti, aby sa nedala zska informcia obsiahnut v zniench dajoch. Nienie dajov sa rob
fyzicky fyzickou likvidciou pamovch nosiov, na ktorch boli daje zaznamenan
(mechanickm rozdelenm na mal asti, splenm, psobenm silnho elektromagnetickho
poa), alebo logicky bezpenm odstrnenm dajov z pamovch mdi (napr. vymazanm
a niekokonsobnm prepsanm dajov na magnetickch pskach, diskoch).
Spracovanie informcie (v irokom zmysle) je dleit preto, lebo informcia sa vyuva pre
zabezpeenie chodu organizcie a/alebo plnenia poslania organizcie (napr. personlna agenda
vlastnch zamestnancov organizcie, spracovvanie daovch priznan, evidencia nevybavench
objednvok, daje o poskytnutch slubch, odoslan faktry, tovn zznamy a pod.). Aby na
zklade informcie bolo mon prijma sprvne rozhodnutia, informcia mus by
pravdiv, pln a mus by dostupn v ase, ke to je potrebn. Navye, pri spracovan
informcie sa objavuj alie poiadavky, napr. aby sa k informcii nedostali nepovolan osoby,
aby bolo mon stanovi, o jednotliv osoby s informciou mu robi a pod. Tieto poiadavky
sa nazvaj bezpenostn poiadavky 6 (na informciu, resp. IKS) a medzi zkladn patria:
dvernos, integrita, dostupnos, autentickos, skromnos, nepopretie pvodu, nepopretie
prijatia, anonymita, pseudonymita, zodpovednos za innos v systme.
Zaistenie dvernosti dajov znamen, e k informcii obsiahnutej v dajoch maj prstup len tie
osoby, ktorm je uren (oprvnen osoby). Zdrazujeme rozdiel medzi prstupom k dajom
a prstupom k obsahu dajov. Zaistenie prvej poiadavky by znamenalo, e sa daje spracovvaj
spsobom, pri ktorom je vylen prtomnos nepovolanch osb, o je nerealistick
predpoklad 7. V druhom prpade sta, aby bola informcia zapsan prostrednctvom takch
dajov, e pre vetky osoby okrem oprvnench, bude nezrozumiten; t.j. aby nemohli zska
z dajov ich informan obsah.
Zaistenie integrity dajov znamen, e daje nemu by nepozorovane modifikovan bez toho,
aby si to oprvnen osoba vimla. Idelne by bolo, keby bolo mon vyli akkovek
neoprvnen zsah do dajov poas ich spracovania, ale to sa vzhadom na charakter a zloitos
systmov, v ktorch sa daje spracovvaj, ned garantova. Ak oprvnen osoba zist, e daje
boli neoprvnene upravovan, nebude sa spolieha na informciu, ktor obsahuj, ale me si ich
od toho, kto jej ich poskytol, vyiada ete raz 8.
Zaistenie dostupnosti dajov znamen, e daje s k dispozcii oprvnenm osobm kedykovek,
ke o to poiadaj. Tto absoltna poiadavka sa d zoveobecni tak, e sa stanov maximlny
as od poiadavky na sprstupnenie dajov a po okamih, ke iadate m daje k dispozcii;
alebo sa dostupnos definuje asom, kedy s daje k dispozcii 9.
Naplnenie poiadavky na autentickos dajov znamen, e prjemca si me by ist tm, e
daje s zhodn s tmi, ktor poslal odosielate a identitou odosielatea (z akho zdroja
pochdzaj). Autentickos teda v sebe spja integritu dajov a jednoznan/garantovan urenie
identity tvorcu dajov.
Skromnos (privacy) sa vzahuje na osobn daje a znamen, e lovek m monos stanovi,
ktor jeho osobn daje, komu a za akch podmienok bud sprstupnen. (Skromnos sa
uplatuje napr. pri sprstupovan dajov zdravotnej dokumentcie vyhradenmu okruhu osb:
oetrujcim lekrom, explicitne stanovenm prbuznm alebo prvnym zstupcom pacienta.)
Skromnos je slabia poiadavka ako dvernos; na zaistenie skromnosti napr. zdravotnej
dokumentcie sta oddeli osobn daje, ktor umouj uri identitu pacienta od vsledkov
vyetren. Ak sa potom protivnk dostane k anonymnm dajom, nevie, na koho sa vzahuj.
ak je na daj kladen nejak bezpenostn poiadavka, naprklad na jeho integritu, integrita sa nazva aj
bezpenostnm atribtom daju (a spravidla sa predpoklad, e je v prpade danho daju aj nejakm
spsobom zabezpeen)
7
predstavme si naprklad prenos dajov prostrednctvom bezdrtovej siete alebo Internetu.
8
existuj aj metdy rekontrukcie pokodench dajov, tzv. samoopravn kdy
9
absoltna dostupnos by sa dala vyjadri tak, e daje s dostupn nepretrite alebo, e as od
poiadavky na prstup k dajom po poskytnutie dajov je nulov (resp. dan technickmi parametrami
rchlos vyhadania dajov a doba prenosu od zdroja k iadateovi)
6
14
alie dve bezpenostn poiadavky sa vzahuj na komunikciu: nepopretie pvodu (non

repudiation of origin) sprvy znamen potvrdenie toho, e tvorca/odosielate sprvy sprvu
poslal a nepopretie prijatia (non repudiation of receipt) zasa, e prjemca sprvy sprvu
preukzatene dostal.
Na vysvetlenie alch pojmov potrebujeme definova zkladn pojmy tkajce sa identifikcie.
ubovon vec, daje, dokument, lovek, alebo dokonca nieo tak abstraktn ako mylienka, sa
nazva entita. Entita sa vyznauje nejakmi vlastnosami (atribtmi). Mnoina atribtov, ktor
umouj jednoznane odli dan entitu od podobnch entt, sa nazva identita danej entity.
Vetky atribty, ktor prislchaj danej entite, tvoria absoltnu (pln) identitu danej entity.
Absoltna identita me by vemi rozsiahla a na jednoznan urenie entity v nejakej menej
oblasti bude stai aj podmnoina atribtov absoltnej identity. Preto sa pojem identity viae na
oblas pouitia a identitou entity je ubovon mnoina atribtov, ktor sta na jednoznan
urenie entity v danej oblasti pouitia identity. Naprklad, ak s v miestnosti dvaja udia matka
a diea, tak na urenie dieaa sta ktorkovek z atribtov rok narodenia, vka, vha, rodinn
vzah, zamestnanie a i. Na rchle urenie entity mono vytvori aj umel entitu, identifiktor,
pecilny atribt, ktorho jedinou lohou je plni funkciu identity danej entity v presne
definovanej oblasti pouitia. Identifiktorom je naprklad rodn slo osoby, IO, DI, sriov
slo vrobku a pod. Na identitu sa asto viau nejak jedinen oprvnenia, naprklad prstup
k nejakej slube, alebo ku zdrojom. Aby napr. lovek nemohol prebra zsielku uren inmu
loveku, mus doruovateovi (ktor ho osobne nepozn), preukza svoju identitu. Tento kon
sa sklad z dvoch ast: identifikcie a autentifikcie/autentiz-cie. Pri identifikcii entita
deklaruje svoju identitu (alebo v inom prpade lovek deklaruje identitu nejakej entity, naprklad
vo forme tvrdenia toto je moje auto). Identifikcia sama o sebe na stanovenie identity nesta,
pretoe me by falon. (lovek sa me vydva za niekoho inho.) Druh strana si preto
mus overi pravdivos deklarovanej identity (tento kon sa nazva autentizcia). To sa
v prpade osb rob troma rznymi spsobmi alebo ich kombinciou: na zklade toho, m lovek
je (biometrick charakteristiky ako s odtlaky prstov, obraz sietnice, DNA, vzor); toho, o
lovek m (identifikan/autentizan token: preukaz totonosti, preukaz zamestnanca), alebo
toho, o lovek vie (heslo, PIN, prstupov kd, osobn daje 10 ). Pri autentizcii mus ma
overovate identity monos overi, i poskytnut autentizan daje sa viau na dan identitu.
V benom ivote na overovanie identity (totonosti) slia rzne preukazy (u osb obiansky
preukaz, pas), ktor vydala dveryhodn autorita (poskytovate identity), v potaoch sa lovek
identifikuje prihlasovacm menom a na autentizciu pouva heslo, kartu, alebo odtlaok prsta.
Bezpenostn poiadavka zodpovednos za innos v systme (accountability 11 ) znamen, e
k jednotlivm innostiam v systme je mon jednoznane priradi entitu (loveka, proces), ktor
ich vykonala alebo spsobila.
Anonymita a pseudonymita s bezpenostn poiadavky, ktor chrnia skromie loveka a s
v istom zmysle opan k poiadavke na accountability. Anonymita znamen, e zo zskanch
atribtov nie je mon jednoznane uri entitu (osobu), ktorej prislchaj (situcie v ktorch je
anonymita iaduca s napr. surfovanie po Internete, nakupovanie). Pseudonymita je slabou
poiadavkou ako anonymita; entita vystupuje pod identitou, ktor vo veobecnosti nie je mon
priradi konkrtnej osobe (prezvka, pseudonym, nick), ale obmedzen okruh (dveryhodnch)
osb vie jednoznane identifikova osobu na zklade jej pseudonymu (a prpadne alch
atribtov, ktor m k dispozcii).
Pri spracovan informcie me djs k udalostiam, ktor spsobia poruenie niektorej
z bezpenostnch poiadaviek bu priamo psobenm na daje, zsahom do IKT,
prostrednctvom ktorch sa spracovvaj, alebo prostredia, v ktorom IKT spracovvajce dan
daje, psobia. Takto udalosti sa nazvaj bezpenostn incidenty. To, o me spsobi
10
11
napr. rodn meno babiky z matkinej strany

mon preklady by boli napr. dosledovatenos, ztovatenos
15
bezpenostn incident 12 , sa nazva hrozba (threat). Hrozbou je naprklad poiar, zplava,

zemetrasenie, technick porucha, udsk chyba, nedostatok zdrojov, vpadok napjania, nik
citlivej informcie, sabot, tok hackera a pod. Hrozba m svojho nositea (zplava - prasknut
kanalizan potrubie, d, rieka) a na to, aby nastala, mus v systme, alebo jeho okol by
nieo, o umouje hrozbe prejavi sa; a to zranitenos (vulnerability). Zranitenosou me
by nedostatok (pokoden strecha, slab heslo, zl nastavenie potaa) alebo aj spsob
pouvania systmu (prstup do potaa zo siete kvli sprve na diaku). Ak sa hrozba napln,
(djde k bezpenostnmu incidentu) m to pre daje, systm, technick zariadenia alebo
organizciu nejak negatvne dsledky, dopad. Dopad hrozby je mon mera kvantitatvne
(napr. finann vyjadrenie) prostriedkami, ktor je potrebn vynaloi na odstrnenie nsledkov
bezpenostnho incidentu, ale s dopady, ktorch hodnotu je ak kvantifikova (naruenie
dobrho mena, strata obchodnch prleitost, zranenie alebo smr loveka) , a preto sa popri
kvantitatvnom hodnoten dopadov pouva kvalitatvne hodnotenie (dopad me ma zvanos
nzku, stredn alebo vysok). Hrozba me ma (v prpade ke nastane) pre organizciu
katastroflne nsledky (pd lietadla na budovu, zemetrasenie), ale pravdepodobnos, e sa takto
hrozba napln, je mal. Veliina, ktor zohaduje tak dopad naplnenia hrozby, ako aj
pravdepodobnos jej naplnenia sa nazva riziko. Z matematickho hadiska je riziko stredn
hodnota dopadu spsobenho danou hrozbou; t.j. sin pravdepodobnosti a zvanosti dopadu.
(Ak m organizcia 100 osobnch potaov a pravdepodobnos krdee v priebehu jednho roka
je 5%, tak riziko vyplvajce z hrozby krde osobnho potaa je 0.05 x 100 x cena (PC +
nklady na jeho obstaranie a intalciu)). Aj pravdepodobnos naplnenia hrozieb sa spravidla
ako vyjadruje kvantitatvne. Preto sa pri vpote rizika pouva kvalitatvne ohodnotenie
pravdepodobnosti naplnenia hrozby (pravdepodobnos je vysok, stredn, nzka, prpadne
nulov) a namiesto numerickho vpotu sa riziko vypotava na zklade tabuky 13. Primeran
ochrana systmu (organizcie) vychdza zo znalosti rizk a zavdzan rieen, ktor ich bu plne
eliminuj, alebo aspo znia ich hodnotu na akceptovaten rove. Na urenie a ohodnotenie
rizk, ktor s pre organizciu relevantn, sli analza rizk. Pri analze rizk sa najprv
identifikuje vetko, o m pre organizciu hodnotu a o by mohlo by naruen bezpenostnch
incidentom. Ide o zariadenia, daje, znalosti, finann prostriedky, kvalifikovanch ud,
infratruktru, reputciu organizcie, skrtka vetko, o organizcia potrebuje na to, aby mohla
plni svoje poslanie. Tieto entity sa nazvaj aktvami (assets) organizcie. Potom sa identifikuj
hrozby, ktor s relevantn pre dan organizciu (mu negatvne psobi na niektor aktva)
a vyslia rizik. (Podrobnejie sa touto problematikou budeme zaobera v asti analza rizk).
Organizcia si ur hranicu akceptovatenho rizika a prijme opatrenia, ktor znia rizik pod
tto rove. Opatrenia mu ma rozlin charakter: fyzick opatrenia, personlne opatrenia,
logick opatrenia (bezpenostn opatrenia implementovan pomocou potaovch programov)
a i. Niektor hrozby mu ma pre organizciu fatlne nsledky, ale pravdepodobnos ich
naplnenia je mal (poiar, pd lietadla, v naich podmienkach teroristick tok, zemetrasenie
a pod.). Zavdza opatrenia na eliminciu vetkch rizk vyplvajcich z takchto hrozieb by
pravdepodobne prekraovalo monosti organizcie a preto sa vol in rieenie: organizcia prejde
vetky mon katastrofick scenre a priprav postupy tak pre rieenie krzovch situci ako aj
pre rchle obnovenie normlneho stavu po prekonanej katastrofe (havarijn plny a plny
kontinuity innosti).
Podmienky v organizcii sa mu meni a mu sa objavi nov hrozby, resp. meni hodnota
rizk. Aby bola ochrana aktv organizcie inn a primeran, organizcia mus priebene
spravova/riadi rizik (monitorova systmy, kontrolova dodriavanie prijatch opatren, riei
a analyzova bezpenostn incidenty, upravova existujce a prijma nov bezpenostn
opatrenia). Okrem priebench a iastkovch kontrol by organizcia pravidelne, alebo po
vekch bezpenostnch incidentoch mala necha preveri plnos a primeranos prijatch
opatren formou bezpenostnho auditu a na zklade vsledkov auditu spravi prpadn korekcie
bezpenostnch opatren. Bezpenostn audit m za cie zisti, i s v organizcii dosiahnut
definciu bezpenostnho incidentu neskr ete formalizujeme, na zaiatok vak vystame s uvedenou
definciou
13
podrobnosti itate njde v asti 2.9
12
16
ciele stanoven nejakm dokumentom (bezpenostnm tandardom, zkonom, normou alebo

bezpenostnou politikou organizcie). Bezpenostn audit vykonva kvalifikovan osoba, intern
alebo extern audtor (bezpenosti informanch systmov).
Teraz meme definova aj samotn pojem informan bezpenos. Tento pojem sa pouva
v trojakom vzname: 1. oznauje interdisciplinrnu oblas, ktor sa zaober skmanm hrozieb
a vvojom metd ochrany; 2. na oznaenie aktivt zameranch na dosiahnutie dostatonej rovne
ochrany informcie a napokon 3. znamen idelny stav systmu (organizcie), kedy s
eliminovan vetky rizik vyplvajce z hrozieb voi aktvam systmu (organizcie). V tomto
texte budeme pouva pojem informan bezpenos vo vetkch troch, najm vak
v poslednch dvoch vznamoch.
V tejto asti sme sa obmedzili len na vysvetlenie zkladnch pojmov informanej bezpenosti;
dleitch pojmov potrench pre pochopenie bezpenostnch problmov a spsobov ich rieenia
je samozrejme podstatne viac. Najdleitejie z nich njde itate v alom texte a zhrnut v
priloenom strunom vkladovom slovnku pojmov informanej bezpenosti.
17
2 Manament informanej bezpenosti

Daniel Olejr
Si vis pacem, para bellum
2.1 vod
Mnoh organizcie v sasnosti spracovvaj vinu informci,ktor potrebuj pre
vykonvanie svojej innosti pomocou IKT. Tieto sa vaka svojej nenahraditenosti stali asou
kritickej infratruktry 14, bez ktorej organizcie u nedoku plni svoje poslanie. Ak m preto
organizcia plni svoje lohy, mus sa postara o to, aby nedolo k narueniu jej IKT, ani k
narueniu dajov/informci, ktor sa v nich spracovvaj. Vznam IKT pre fungovanie
organizci a v konenom dsledku celej spolonosti, si uvedomuje aj tt a prostrednctvom
zkonov, vnosov a inch prvnych predpisov definuje povinn poiadavky na rozsah, rove
a spsob ochrany (niektorch alebo vetkch) dajov a IKT organizci. Poiadavkm na
zaistenie IB vyplvajcim zo zkonov sa podrobnejie budeme venova v kapitole 12 a na tomto
mieste spomenieme len na ilustrciu povinn bezpenostn tandardy pre informan systmy
verejnej sprvy uveden vo Vnose MF SR [21]. Poiadavky rznych zkonov na ochranu
informcie, IKT resp. IKS sa v podstate daj vyjadri pomocou tandardnch bezpenostnch
poiadaviek a rovn zruk, ktor prijat rieenia musia poskytova. Na ich splnenie sta
poui jednotn postup, popsan napr. v medzinrodnch normch ISO/IEC radu 27000,
z ktorch vychdzaj aj bezpenostn tandardy Vnosu [21]. vodzovky sme v predchdzajcej
vete pouili preto, lebo hoci je v ISO normch dostatone podrobne popsan, o je potrebn
spravi na dosiahnutie potrebnej rovne IB v organizcii, dodra postupy popsan v normch
a naplni poiadavky, ktor stanovuj nie je ahk loha.
Na dosiahnut a udriavan potrebnej rovne IB v organizcii nebude stai kpi a
implementova nejak technologick rieenia, angaova externch pecialistov, resp. poveri IB
niekokch ud v organizcii. Budovanie a udriavanie informanej bezpenosti je trval proces,
do ktorho bude potrebn v primeranej miere zapoji vetkch ud, ktor pracuj s IKT
organizcie a/alebo mu ovplyvni ich innos; t.j. od vedcich pracovnkov a po servisn
personl a externch spolupracovnkov.
Vedci pracovnk organizcie je zodpovedn za organizciu ktor riadi, vrtane splnenia
bezpenostnch poiadaviek vyplvajcich zo zkonov a v konenom dsledku aj za zaistenie
potrebnej rovne informanej bezpenosti vo svojej organizcii. Hoci nemus by odbornkom
na informan bezpenos a me poveri riadenm IB inch zamestnancov organizcie, neme
sa zbavi ani zodpovednosti za IB v organizcii ani sa vyhn prijmaniu kovch rozhodnut
o IB (ako s stratgia IB, personlne zabezpeenie, financovanie IB, zvzn postupy pre
zaistenie IB, klasifikcia informcie, disciplinrne postihy za spsoben bezpenostn incidenty,
zosladenie riadenia organizcie a riadenia IB a i.). Aby tieto povinnosti dokzal kompetentne
plni, mus ma aspo zkladn znalosti o IB, vedie ich aplikova na svoju organizciu, mus
vedie stanovi priority IB v organizcii, definova zodpovednos pracovnkov organizcie za
IB, stanovi hlavn lohy v IB a mus dokza kontrolova ich plnenie.
Vinu kovch innost potrebnch na dosiahnutie a udriavanie IB v organizcii vak bud
musie vykonva pecialisti na IB a informatici. T bud musie zvldnu problematiku IB do
takej miery, aby vedeli napsa rozumn koncepciu IB v organizcii a rozpracovali ju do
postupov realizovatench v kadodennom ivote. Bud sa musie naui posudzova hrozby,
vyhodnocova rizik, ktor z nich vyplvaj, hada zranitenosti a posudzova vhodnos,
technick a ekonomick nronos opatren, ktor prichdzaj do vahy na odstrnenie, alebo
14
nem sa na mysli kritick infratruktra celottneho vznamu, ale infratruktra organizcie, ktor je
nevyhnutne potrebn na zabezpeenie alebo podporu zkladnch innost organizcie
18
Manament informanej bezpenosti | MF SR
aspo oetrenie odhalench zranitenost. Hoci si organizcia me naja externch pecialistov

na rieenie jednorazovch pecifickch loh, informatici a intern pecialisti na IB sa bud
musie naui samostatne riei ben bezpenostn problmy v organizcii, monitorova
innos prijatch opatren a aj vykonva audity zameran na vyhodnotenie celkovej rovne
bezpenosti v organizcii; resp. naui sa efektvne spolupracova s externmi pecialistami pri
rieen problmov, na ktor ich monosti nebud stai.
Vinu pracovnkov organizcie tvoria pouvatelia IKT, ktor maj o princpoch ich fungovania
len laick vedomosti a o IB nanajv zkladn predstavy. Napriek nzkym oprvneniam, ktor
pouvatelia maj v systmoch organizcie, mu na jednej strane spsobova vne
bezpenostn problmy, ale na druhej strane aj pozitvne prispie k rovni IB v organizcii.
Vzhadom na ich informatick vzdelanie, ale najm potreby nem vznam laickch pouvateov
masovo koli v IB. Laick pouvate potrebuje vedie, o m robi, o nesmie robi, ako
rozpozna, e sa v IKS deje nieo podozriv, o m spravi a na koho sa m obrti. Tieto
veobecn poiadavky na laickch pouvateov sa rchlo konkretizuj v bezpenostnom
procese; mnoh z nich vyplyn u z dokumentov rozpracovvajcich bezpenostn politiku
(bezpenostn koncepciu) organizcie a ak sa pri spracovan bezpenostnej politiky,
bezpenostnch smernc a praktk na nieo podstatn zabudlo, bezpenostn incidenty rchlo
odhalia nedostatky. Organizcia sotva bude ma pecializovanch lektorov informanej
bezpenosti; extern kolitelia s pouiten na prpravu pecialistov IB, ale nepoznaj pomery
v organizcii a laick pouvatelia potrebuj konkrtne vedomosti, koli ich bud musie
informatici a pecialisti na IB z vlastnej organizcie.
Zaisti natrvalo potrebn rove IB v organizcii nie je ani jednoduch, ani lacn. Ak m
organizcia vyhovie vetkm bezpenostnm poiadavkm a naplni svoje potreby v IB
efektvnym spsobom, mala by od rieenia iastkovch bezpenostnch problmov prejs
k systematickmu rieeniu, kde mnoh bezpenostn problmy vyriei spolonmi
preventvnymi opatreniami, na podobn problmy bude vyuva rovnak, u raz vyvinut
rieenia, opatrenia sa bud vzjomne dopa a ich innos bude organizcia priebene
monitorova, pravidelne vyhodnocova a v prpade potreby ich bude aktualizova a prpadne
prijma nov. Skr i neskr bude organizcia potrebova zavies systm riadenia
(manamentu) informanej bezpenosti 15 . Hoci nzov znie zloito a odstraujco, zavedenie
ISMS predstavuje postupnos prirodzench krokov, ktor si teraz strune popeme.
2.2 Bezpenostn stratgia a bezpenostn politika organizcie

Organizcia aj jej vedenie si najprv potrebuje vytvori predstavu o lohe, ktor potrebuje riei
(zaistenie dostatonej rovne IB v organizcii) stanovi zkladn ciele a postup na ich
dosiahnutie; t.j. vypracova vlastn bezpenostn stratgiu 16. Bezpenostn stratgia mus ma
presne stanoven oblas psobnosti; t.j. mus by jasne definovan, na o sa vzahuje (i na cel
organizciu, jej IKT, alebo na nejak dleit systm) a v oblasti svojej psobnosti mus
definova: o treba chrni, na akej rovni a o pre to organizcia je ochotn/pripraven spravi.
Bezpenostn stratgia m najastejie podobu psomnho dokumentu, ktor sa nazva
bezpenostn politika (vstinej nzov by bol politika informanej bezpenosti, alebo politika
bezpenosti IT/IKT, ale v odbornej literatre sa pouva termn bezpenostn politika, a preto sa
ho budeme dra aj my.) Ako sme u spomenuli, za cel organizciu, vrtane primeranej rovne
IB zodpoved vedenie organizcie. To mus iniciova aj systematick rieenie IB v organizcii
(zavedenie systmu manamentu IB, ak sa k IB doteraz takto v organizcii nepristupovalo), resp.
pravideln revzie systmu manamentu IB ak ho organizcia m zaveden a vyuva ho, aby sa
pre ISVS tto povinnos vyplva z bezpenostnch tandardov spomnanho Vnosu [21].
viacero pojmov me u itatea vzbudi obavu, e vyjadruj nieo zloitho. Vo vine prpadov ide
o zbyton obavy, ale pouvanie jednoduchie znejcich vlastnch termnov by mu spsobilo problmy
neskr, ke bude potrebova ta odborn texty pouvajce tandardn terminolgiu IB. V prpade, ke
si nebude ist, ak je vznam nejakho pojmu, odporame mu pozrie sa do vkladovho slovnka.
15
16
19
zaistila jeho aktulnos, innos a efektvnos. Zaneme najjednoduchm 17 prpadom, ke

sa IB v organizcii ete len zana riei a bezpenostn proces18 sa spa od zaiatku a tka sa
celej organizcie.
Hoci to na prv pohad vyzer ako zbyton formalita, ak m ma snaha o systematick rieenie
IB (ktor pravdepodobne povedie aj k rozsiahlym zmenm v organizcii) ndej na spech, mus
vedenie organizcie jednoznane deklarova podporu IB a vytvra podmienky pre spen
priebeh celho bezpenostnho procesu. Bez toho, aby boli zamestnanci presveden, e vedenie
organizcie povauje IB za lohu s vysokou prioritou, nebud jej, najm ak im bude
komplikova ivot, venova potrebn pozornos. Vedenie organizcie sotva bude ma as a
potrebn znalosti na tvorbu bezpenostnej stratgie a psanie bezpenostnej politiky. Po vyjadren
podpory IB preto vedenie mus vytvori 19 pracovn skupinu dostatone kvalifikovanch
a kompetentnch ud, ktor na zklade zadania vedenia pripravia stratgiu IB a napu
bezpenostn politiku organizcie. Bezpenostn politiku organizcie vedenie organizcie najprv
schvli 20 a potom vydva vo forme internho zvznho dokumentu. lohou bezpenostnej
politiky je poveda kadmu zamestnancovi organizcie o me, o nesmie, o mus a za o je
zodpovedn pri prci s IKT. Bezpenostn politika by mala by preto napsan tak, aby jej t,
ktorch sa tka, rozumeli a mus by dostupn vetkm, od ktorch sa oakva, e ju bud
musie dodriava, teda minimlne zamestnancom prslunej organizcie a v primeranej miere aj
zamestnancom tretch strn, ktor s IKT organizcie nejakm spsobom prichdzaj do kontaktu.
Vedenie organizcie v Bezpenostnej politike
1. deklaruje dleitos IB pre organizciu, podporu vedenia organizcie pri zaisovan
potrebnej rovne IB v organizcii a pripravenos vytvori pre to podmienky;
2. definuje, na o sa Bezpenostn politika vzahuje (oblas psobnosti, (scope)
Bezpenostnej politiky), hlavn aktva, hlavn bezpenostn ciele organizcie v IB
a rove IB, ktor v organizcii povauje za primeran,
3. stanov zodpovednos zamestnancov organizcie za presadzovanie a dodriavanie
bezpenostnej politiky (a dokumentov na u nadvzujcich),
4. uvedie truktru bezpenostnch dokumentov nadvzujcich na dan bezpenostn
politiku a ich obsah (pecilne bezpenostn politiky, alebo bezpenostn tandardy,
bezpenostn praktiky ak oblasti pokrvaj a akou formou bud vydan)
5. definuje na zklade oho sa bude informcia v organizcii klasifikova 21,
6. definuje spsob analzy rizk (kvantitatvna/kvalitatvna) a hranicu akceptovatenho
rizika v zvislosti od rovne IB, ktor v organizcii povauje za primeran,
7. stanov
a. zsady pre monitoring, kontrolu a audit informanch a komunikanch
systmov organizcie
b. zsady rieenia bezpenostnch incidentov,
c. stratgiu pre zaistenie kontinuity innosti IKS organizcie,
d. sprvu bezpenostnej politiky (ako asto sa bud robi pravideln a z akch
dvodov mimoriadne revzie bezpenostnej politiky).
Obsah bezpenostnej politiky poda ISO normy [4] je uveden v prlohe Obsah bezpenostnej
politiky.
z hadiska vkladu
termn je prevzat z BSI tandardu [8] a oznauje aktivity smerujce k dosiahnutiu a trvalmu udraniu
potrebnej rovne IB. V podstate zodpoved 2. vznamu pojmu IB, ako sme ju definovali v zkladnch
pojmoch. V materiloch NIST sa ako synonymum pojmu bezpenostn proces pouva pojem
bezpenostn program.
19
u v tejto fze me vedenie organizcie menova manara IB organizcie a poveri ho aj
organizanm zabezpeenm prpravy bezpenostnej stratgie. Samotn pracovn skupina by mala okrem
manara IB a informatikov obsahova aj zstupcov organizanch tvarov, ktor s pre IB relevantn:
personlne oddelenie, sprva budov, prvne oddelenie, oddelenie kontroly, prp. alch
20
predtm ju niekoko krt me vrti pracovnej skupine na dopracovanie
21
pozri prlohu Klasifikcia informcie a systmov
17
18
20
Zhrnutie. Vedenie organizcie zodpoved o.i. aj za rove IB v organizcii. Vnos MF SR

o tandardoch pre ISVS stanovuje povinnos zavies v organizcich, ktor maj ISVS, systm
manamentu IB (ISMS). Vedenie organizcie vytvor pracovn skupinu, ktor nape
bezpenostn politiku organizcie. Tto politika obsahuje stratgiu organizcie v IB, stanovuje
zkladn ciele IB a je zkladom pre IB v organizcii aj pre jej ISMS. Bezpenostn politiku
vedenie vyd ako dokument, zvzn pre vetkch zamestnancov organizcie.
2.3 Implementcia Bezpenostnej stratgie/politiky

Bezpenostn politika vytvra len rmec pre IB v organizcii, ale nezaober sa spsobmi ako
dosiahnu ciele, ktor stanovila. Ak bezpenostn politika nem osta len deklarciou, na
splnenie ou definovanch loh je potrebn vytvori primeran podmienky (personlne,
organizan, finann a i.) zapoji do jej realizcie zamestnancov organizcie, podrobne
analyzova bezpenostn potreby organizcie a rozpracova veobecn ustanovenia
bezpenostnej politiky do systmu opatren 22.
Na to, aby mal kto realizova bezpenostn politiku, je v organizcii potrebn definova
bezpenostn roly, stanovi pre jednotliv roly lohy a zaradi do nich vhodnch ud. Kad
organizcia by mala ma manara IB, zodpovednho za riadenie IB v organizcii. Tento
zamestnanec pln poda [8] nasledujce lohy:
manauje bezpenostn proces a pracuje na lohch, ktor s nm svisia,

pomha vedeniu organizcie pri tvorbe (a sprve) bezpenostnej politiky,
koordinuje rozpracovanie bezpenostnej politiky, iastkovch koncepci, politk,
nvodov, pravidiel a metodickch materilov,
iniciuje a monitoruje implementciu bezpenostnch opatren,
vypracovva pre vedenie organizcie prehady stavu IB v organizcii,
koordinuje v organizcii projekty svisiace s informanou bezpenosou,
vyetruje bezpenostn incidenty, ku ktorm dolo v organizcii,
iniciuje a koordinuje vzdelvacie aktivity zameran na zvenie bezpenostnho
povedomia, znalost a zrunost IB v organizcii.
Manar IB by mal by zapojen aj do novch IKT projektov organizcie, aby mohol

presadzova zohadovanie bezpenostnch poiadaviek hne od zaiatku projektu (napr.
vytvrania alebo obstarvania novho IKS). Manarom IB neme by hocikto. Aby dokzal
spene plni stanoven lohy, mal by pozna organizciu, jej informan a komunikan
infratruktru, by schopn pracova v tme a vies tm, komunikova s vedenm organizcie,
zamestnancami, predstavitemi a zamestnancami tretch strn, ma sksenosti s manamentom
projektov a, samozrejme, mal by ma potrebn vedomosti z IB. Funkcia manara IB by sa
nemala spja s inmi funkciami 23, pretoe by a) mohlo dochdza ku konfliktu zujmov (napr.
informatika a manara IB) a b) nemusel ma na plnenie loh v IB dos asu. Manar IB je
predovetkm vkonn funkcia, ale niektor vstupy jeho prce (koncepn materily IB,
prehady stavu IB v organizcii a najm navrhovan opatrenia) sa musia prerokova vo veden
organizcie a po prpadnch pravch a schvlen presadzova z rovne vedenia organizcie a na
to kompetencie manara IB nestaia. Preto by niektor z lenov vedenia organizcie mal
explicitne zodpoveda za IB v organizcii 24.
Rozsah loh v IB pravdepodobne presiahne fyzick kapacity manara IB. Poda vekosti,
potrieb a monost organizcie bude do plnenia loh IB potrebn zapoji aj alch
zamestnancov; jednch na rieenie koncepnch, kontrolnch a koordinanch loh na rovni
postupnos krokov pri implementcii bezpenostnej politiky v organizcii nemus by toton s porad,
v akom s popisovan v tejto prci
23
v malch organizcich sa tomu pravdepodobne ned vyhn, ale manarovi IB je mon prideova
lohy, pri plnen ktorch nenastva konflikt zujmov
24
tomuto vedcemu zamestnancovi by podliehal manar IB
22
21
celej organizcie (tm pre manament IB alebo bezpenostn frum poda ISO normy [3])
a alch na praktick innosti potrebn na zaisovanie IB v organizanch tvaroch, systmoch,
resp. projektoch organizcie. Zrejme len mlo organizci si bude mc dovoli vytvori tm pre
manament IB zo pecializovanch odbornkov, ktor sa rieeniu IB v organizcii bud venova
na pln vzok. Realistickejm rieenm je njdenie vhodnch kandidtov spomedzi
zamestnancov organizcie a rozrenie ich pracovnej nplne o IB, prpadne ich uvonenie od
inch v povinnost na urit dobu v prpade, ke organizcia potrebuje riei aktny problm
(napr. vypracovanie Bezpenostnej stratgie). Zloenie manarskeho tmu 25 by mohlo by
podobn zloeniu pracovnej skupiny, ktor pripravila Bezpenostn politiku organizcie. Okrem
tohto virtulneho manarskeho tmu, bude organizcia pravdepodobne potrebova
pecializovanch manarov IB, ktorch lohou je riadenie IB v organizanch zlokch (vekej)
organizcie, zabezpeovanie primeranho rieenia bezpenostnch poiadaviek vo vznamnch
projektoch a rieenie bezpenostnch problmov dleitch systmov. Tieto funkcie bude
v organizcii tie pravdepodobne mon riei rozrenm pracovnch npln existujcich
zamestnancov.
Zhrnutie. Bezpenostn politiku bude musie niekto v organizcii zavies do ivota. Vedenie
pover niektorho lena vedenia zodpovednosou za IB (prepojenie vedenia a vkonnej zloky
IB) a ustanov manara IB ako vkonnho zamestnanca pre oblas IB. Poda vekosti
a charakteru organizcie ustanov z riadiacich zamestnancov organizcie tm manara IB, ktor
bude riei koncepn otzky IB a loklnych manarov IB na iaston vzky, ktor bud
pomha manarovi IB a pouvateom IKT riei bezpenostn problmy v organizanch
zlokch, resp. vekch systmoch organizcie.
2.4 Zdroje na IB
Pri implementcii bezpenostnej politiky mus organizcia rta nielen s dostatonmi
finannmi, ale aj udskmi a asovmi zdrojmi. Je jednoduchie odhadn na o bud financie
potrebn, ako ich vku. Najm zdvodnenie vky finannch nkladov spsobuje problmy,
pretoe ak v organizcii nie je dostaton rove IB, tak skr i neskr djde k bezpenostnm
incidentom, ktor bud znamena pre organizciu nejak stratu 26; ale ke organizcia vynaklad
dostaton prostriedky na rieenie IB, k incidentom nedochdza. A potom paradoxne vznik
otzka, i bolo na IB potrebn vynaloi a najm v budcnosti vynaklada tak vek
prostriedky. rove IB v organizcii sa d ako nejako kvantitatvne vyjadri a ete aie sa
predpoved, i v budcnosti organizcia bude cieom nejakho toku, alebo i bude postihnut
prrodnou katastrofou, zhorenmi spoloenskmi podmienkami a ak bud ma tieto
nepriazniv okolnosti na u dopad.
Hoci sa IB ned exaktne hodnoti pomocou tandardnch ekonomickch kritri, dlhodob
sledovanie vzahu medzi investciami do IB a rovou IB (meranou frekvenciou vskytu
a dopadom bezpenostnch incidentov) priniesli zaujmav zistenia. Ukazuje sa, e (za
predpokladu, e s prostriedky na IB optimlne pouit) u s relatvne malmi prostriedkami sa
d dosiahnu zkladn rove IB, ktor predstavuje vek pokrok oproti vchodiskovmu stavu
(bez rieenia IB), ale potom sa zlepovanie rovne IB spomauje, a nakoniec dosiahne
maximum, ktor sa ani almi investciami do IB u viac ned zlepi, pozri graf na obr. 3.1.,
prevzat z BSI tandardu [8]. Tento vzah medzi nkladmi a rovou IB treba zohadova pri
plnovan prostriedkov pre IB u pri tvorbe bezpenostnej politiky organizcie, nakoko nem
zmysel stava si na zaiatku prli ambicizne ciele, na dosiahnutie ktorch bud v realizanej
fze chba prostriedky.
v ISO norme [3] sa nazva bezpenostn frum

vka strt spsobench bezpenostnmi incidentmi me sli ako orientan hodnota pre vku
investci do IB
25
26
22
Obr. 3.1. Vzah medzi nkladmi a dosiahnutou rovou IB [8]

Obmedzen zdroje na IB nemusia nutne znamena, e vne bezpenostn problmy ostan
v organizcii nevyrieen. Mnoh bezpenostn problmy maj naastie viacero rznych rieen
a asto je mon dosiahnu v pokrok jednoduchmi organizanmi opatreniami, ako (napr.)
zavedenm nejakho nkladnho technickho rieenia. Tak naprklad prvm predpokladom
dosiahnutia poadovanej rovne IB je normlne fungovanie IKT v organizcii. Ak m
organizcia nevyhovujcu truktru IKT a/alebo nedostatone kvalifikovan alebo preaen
obsluhu IKT, tak km nebud vyrieen zkladn problmy prevdzky IKT, nem zmysel
prijma alie bezpenostn opatrenia na rieenie bezpenostnch problmov vyej rovne27.
Organizcia me niektor lohy v IB riei vlastnmi pracovnkmi, ale pravdepodobne nebude
ma dostaton kapacity na to, aby rieila vetky bezpenostn problmy vlastnmi silami. Pri
plnovan prostriedkov na IB bude potrebn zohadni aj prostriedky na zabezpeenie externch
pecialistov, prpadne na outsourcing niektorch sluieb (napr. PKI, nezvisl bezpenostn
audit a i.). Prostriedky je potrebn plnova aj na innos manara IB a zamestnancov, ktor sa
na plnen loh v IB podieaj a na samotn monitorovanie IB v organizcii. Tieto nklady sa
organizcii mu vrti, pretoe napr. nezvisl kontrola prijatch opatren me odhali prpady,
ke je cena opatren prli vysok v porovnan s hodnotou rizika (a cenou aktva, ktor maj
chrni), resp. aj v opanom prpade, ke u opatrenie nie je dostatone inn a vaka tomu je
riziko prslunej hrozby prli vysok a pre organizciu neprijaten.
Zhrnutie. Na implementciu bezpenostnej politiky bude potrebn rta s finannmi,
materilnymi a personlnymi zdrojmi. rove IB ani nvratnos investci do IB sa sce ned
presne mera, ale empirick sksenosti ukazuj, e u s relatvne malmi nkladmi sa d
dosiahnu vrazn zlepenie (obr. 3.1) . Dostupn zdroje je potrebn zohadni u pri tvorbe
bezpenostnej politiky a je potrebn rta s tm, e nie vetky lohy bude organizcia schopn
riei sama. Na druhej strane, niektor bezpenostn opatrenia mu odhali nedostatky, ktorch
odstrnenm sa zvi tak efektvnos innosti ako aj rove IB organizcie.
2.5 Zapojenie zamestnancov do IB procesu

Ustanovenie manara IB a bezpenostnho manamentu je nutnou, ale nie postaujcou
podmienkou spenej implementcie bezpenostnej politiky. Jednou z najastejch prin
bezpenostnch incidentov s vlastn zamestnanci. Maj prstup k informanm systmom
a informcim organizcie a bu myselne, z nevedomosti, nedbalosti alebo v dsledku chyby
mu narui systmy alebo daje organizcie. Preto je alm krokom k dosiahnutiu potrebnej
rovne IB v organizcii zapojenie vetkch jej zamestnancov do IB procesu.
Bezpenostn politika stanovuje povinnosti zamestnancov v IB len rmcovo. Aby o tchto
povinnostiach vedeli, musia vetci zamestnanci pozna bezpenostn politiku. Veobecn
bezpenostn povedomie vak nepostauje na to, aby zamestnanci plnili svoje konkrtne lohy
27
k vberu opatren sa dostaneme po analze rizk, v asti Bezpenostn opatrenia.
23
v IB. Na to zamestnanci potrebuj vedie, o sa od nich konkrtne oakva, ako maj plni
svoje povinnosti v IB a o sa stane v prpade, ke svoje povinnosti v IB poruia. Aby sa
organizcia nemusela kadmu zamestnancovi jednotlivo vysvetova jeho lohy v IB,
odporame definova v organizcii alie bezpenostn roly28 a kadho zamestnanca zaradi
do aspo jednej 29 roly. V jednej role bud zaraden zamestnanci, ktor maj rovnak alebo
podobn postavenie vo vzahu k IKT organizcie a s na nich kladen rovnak bezpenostn
poiadavky. Zkladn povinnosti zamestnanca v IB potom vychdzaj z bezpenostnej roly, do
ktorej je zaraden; v zvltnych prpadoch mu by ete doplnen alebo upraven poda
potreby. Prkladom bezpenostnch rol s ben (neprivilegovan) pouvatelia, ktor maj
minimlne oprvnenia v IKS organizcie, informatici (sprvcovia a opertori IKS s oprvneniami
na zasahovanie do nich, na sprvu pouvateov), manari IT a IB, vedci pracovnci a i. Ak
chce organizcia dosiahnu, aby zamestnanci brali svoje povinnosti v IB vne, mali by ich
povinnosti v IB by explicitne uveden v ich pracovnch nplniach.
Podrobnejie informcie o povinnostiach a spsobe ako ich plni, zskaj zamestnanci na
koleniach organizovanch manarom IB. Nov zamestnanec by mal by oboznmen so
svojimi povinnosami pred tm, ako zska prstup k IKS organizcie podobne ako mus
absolvova kolenie o bezpenosti prce. Pri zmench v organizcii, ktor maj vplyv na IB
(organizan zmeny, zavdzanie novch IKS, prechod na nov technolgie), vekch
bezpenostnch incidentoch je potrebn prekoli zamestnancov, ktorch sa uveden zmeny
tkaj, aby vedeli, ako sa menia ich povinnosti, postupy (napr. nahlasovania bezpenostnch
incidentov), resp. e sa menia bezpenostn manari a kontaktn osoby. Ak aj nie je dvod na
mimoriadne kolenia, na udranie dostatonho bezpenostnho povedomia by organizcia
(konkrtne manar IB) mala organizova periodick kolenia zamestnancov o aktulnych
problmoch IB.
Zamestnanec pri svojej innosti me narazi na bezpenostn problm, ktor nevie riei. Aby
mal problm nenarstol do vekch rozmerov, v organizcii by mali by definovan kontaktn
osoby (loklni manari IB), na ktor sa zamestnanec me obrti so iados o pomoc, alebo
radu.
Z bezpenostnho hadiska problematick situcie vznikaj v prpadoch, ke sa men postavenie
zamestnanca v organizcii (prechod na in funkciu, odchod z organizcie). Pre takto prpady
mus ma organizcia pripraven postupy (zablokovanie prstupu do systmov, odovzdanie
autentifikanch prostriedkov, vsledkov prce, zverenej techniky a pamovch mdi), pretoe
nespokojn zamestnanec me organizcii z pomsty spsobi vne problmy. Aj pri obyajnej
zmene pozcie me djs ku konfliktu zujmov, ke m zamestnanec neprimeran oprvnenia,
ktor predstavuj bezpenostn hrozbu alebo zranitenos (kombincia nezruench starch a u
platnch novch oprvnen).
Negatvne strnky informanej bezpenosti. Niektor bezpenostn opatrenia mu narazi na
odpor zamestnancov, pretoe im sauj prcu alebo zasahuj do skromia. V prvom prpade
bud ma zamestnanci tendenciu vyhba sa opatreniam, aby si zjednoduili ivot (napr.
viacnsobn prihlasovanie sa do systmov a aplikci), o sa d riei vysvetlenm zmyslu
opatren, kontrolou dodriavania a uplatnenm rieen, ktor zmiernia negatvne dopady a prli
neoslabia innos opatren (napr. single sign on jedno prihlsenie do systmov organizcie 30).
Druh prpad je zloitej. Organizcia vynaklad prostriedky na kpu technickch zariaden
a aplikci na to, aby pomocou nich dokzala lepie plni svoje lohy. IKT sa vak daj poui aj
na ely, ktor od poslania organizcie maj aleko (sahovanie sborov z Internetu, vyuvanie
elektronickej poty na skromn ely, hranie hier a pod.) Takto innosti v pracovnom ase
v organizcii u existuje rola manar IB; nvrh na alie roly priprav manar IB ako sas
personlnych opatren pre implementciu Bezpenostnej politiky, zaradenie zamestnancov do rl by mal
robi manar IB spolu s vedcimi prslunch tvarov
29
idelne by bolo, keby bol kad zamestnanec zaraden do prve jednej roly, ale kee na niektor lohy
nebude ma organizcia dos ud, nevyhne sa tomu, e zamestnanec bude zaraden do viacerch rl/rol.
30
ale ned sa poui vo vetkch systmoch, napr. tch, ktor si vyaduj siln, viacfaktorov
identifikciu a autentizciu.
28
24
zniuj vkon zamestnancov a mu spsobi aj problmy organizcii (neleglna innos

vykonvan pomocou potaov organizcie). Jednm z monch rieen je stanovi
v bezpenostnej politike zsadu: IKT organizcie sa mu vyuva len na pracovn ely. In
pouitie IKT je zakzan. Takto striktn zkaz si vyaduje kontrolu, ktor mu zamestnanci
povaova za neprimeran zsah do skromia (monitorovanie a zaznamenvanie aktivt na
Internete, kontrola elektronickej poty). Aj dokazovanie, e zamestnanec je zodpovedn napr. za
pokodenie dobrho mena organizcie posielanm elektronickej poty alebo diskusiou na
socilnych sieach me by nron. Miernejou formou je explicitn vymedzenie zakzanch
innost a kontrola zznamov o innosti zamestnancov 31 v systme v prpade bezpenostnho
incidentu.
Disciplinrny proces. Napriek vetkm monm opatreniam me nasta situcia, ke zlyh
lovek a spsob bezpenostn incident. U v prpade chyby me s o poruenie pracovnch
povinnost nehovoriac u o nedbalosti alebo myselnom obchdzan bezpenostnch opatren,
ktor mu ma prsnejiu klasifikciu (dokonca aj poda trestnho zkona). Pre takto prpady
by organizcia mala ma definovan disciplinrny proces s postihmi, ktor by odradili
myselnch poruovateov organizciou stanovench pravidiel ale nezastraili zamestnancov,
ktor spsobili bezpenostn incident nemyselne, natoko, aby v budcnosti radej priznali
chybu vas a nenechali problm nars do vekch rozmerov v ndeji, e sa na ich chybu alebo
omyl neprde.
Zhrnutie. Kad zamestnanec, ktor pracuje s IKT mus vedie, o m robi, o nesmie a preo.
Povinnosti v IB musia by sasou jeho pracovnch povinnost a pomocou kolen sa nau, ako
ich plni. Organizcia mus ma a uplatova postupy pre rieenie problematickch situci
(vpove, zmena pracovnho zaradenia) a zaveden korektn disciplinrny postup pre prpad,
ke zamestnanec spsob bezpenostn incident.
2.6 Budovanie know-how v informanej bezpenosti

Rieenie mnohch loh, o ktorch sme hovorili v predchdzajcich astiach, predpoklad, e
organizcia m minimlne jednho odborne kvalifikovanho manara IB, prpadne alch
pecialistov so systematickmi znalosami v niektorej oblasti IB. Kde vak m takchto
odbornkov vzia? Informan bezpenos v SR zatia nie je zaraden do sstavy vednch a teda
ani tudijnch odborov. To znamen, e neexistuje tudijn program vysokokolskho tdia,
ktor by pripravoval odbornkov na informan bezpenos. Viacron sksenosti s vubou
vybranch predmetov IB vrmci pregradulneho tdia informatiky ukazuj, e tudentom
chbaj praktick sksenosti z fungovania organizci, o sa prejavuje v tom, e hoci dosahuj
dobr vsledky v technickch oblastiach IB, nedoku doceni vznam organizanch,
prevdzkovch, personlnych a prvnych opatren (a ani o tieto oblasti IB nemaj zujem). To
znamen, e prprava pecialistov na IB sa bude musie posun do postgradulneho tdia
a v pregradulnom tdiu bude mon pripravova technicky orientovanch odbornkov
(opertorov, sprvcov systmov a pod.) Km sa vak vytvor systm vzdelvania (aj s
kontinulnym vysokokolskm vzdelvanm), manari IB s odkzan na samotdium,
doplnen tematickmi koleniami, asami na odbornch konferencich, seminroch. Formlne
je mon pecializciu v IB potvrdi zloenm skky a zskanm certifiktov CISA, CISM,
CISSP a pod. (Pozri as 2.12).
Narastajci vznam a zloitos IB podnietili vo vyspelom svete snahu o systematizciu poznania
v IB, o definovanie potrebnch pecializci v IB a o stanovenie obsahovch a kvalitatvnych
poiadaviek na jednotliv pecializcie v IB. Vsledky tchto snaen (ako aj poznatky
z nespench rieen) sme zohadnili v Nvrhu systmu vzdelvania v IB. Vzhadom na
obmedzen kapacity SR sme redukovali poty pecializci na najnutnejie minimum, definovali
vak alie bezpenostne relevantn roly a vypracovali pre jednotliv pecializcie/roly
znalostn tandardy. Tieto tandardy zohaduj tak lohy ud zaradench do jednotlivch rol,
31
z psychologickho hadiska takto rieenie prijatenejie, ale m men odradzujci inok.
25
resp. pecializci, ako aj zkonn poiadavky na ochranu IKT a medzinrodn de facto znalostn
tandardy (Common body of knowledge a Essential body of knowledge). Znalostn tandardy pre
jednotliv roly s uveden v prlohe; systm vzdelvania v IB (ktorho sasou je aj
prebiehajce vzdelvanie v IB a tieto tudijn materily) je vo fze vvoja (postgradulne
vzdelvanie v IB) a testovania (zklady IB).
2.7 Analza rizk

Bezpenostn politika stanovila hlavn ciele pre IB organizcie, hranicu akceptovatenho rizika
a spsob analzy rizk. Organizcia si teraz potrebuje spravi prehad o tom, o konkrtne, pred
m a na akej rovni potrebuje chrni. Odpovede na tieto otzky dva analza rizk. Ak na to
organizcia m dostatok vlastnch kvalifikovanch ud, me si ju robi sama, v opanom
prpade na u vyuije (aj) externch odbornkov. Kee organizcia potrebuje rozpracova svoju
bezpenostn stratgiu (Bezpenostn politiku), predpokladme, e rozsah (scope) analzy rizk
bude toton s oblasou psobnosti Bezpenostnej politiky. (V budcnosti me organizcia
spravi alebo necha si spravi analzu rizk pre dleit systm, as organizcie, resp.
tematicky zameran na nejak druh dajov, napr. osobn daje). Odborn skupina, ktor je
poveren spravi analzu rizk, ur
a) vetky relevantn aktva organizcie
b) vetky relevantn hrozby 32 voi aktvam zo zoznamu vytvorenho v kroku a)
c) vetky bezpenostn poiadavky vyplvajce z prvnych predpisov, vntornch
predpisov, zmlv a podobnch dokumentov organizcie,
d) vetky zranitenosti aktv33 urench v kroku a)
e) u existujce bezpenostn opatrenia.
Pri tvorbe zoznamu aktv zrove zist, kto je za dan aktvum zodpovedn (tzv. majite
aktva) a o vetko na dan aktvum m nejak vplyv (bezpenostn prostredie aktva). Hrozby
voi aktvam dopln o hrozby voi bezpenostnmu prostrediu jednotlivch aktv, pretoe tieto
aktva mu by pokoden aj nepriamo, naruenm podmienok, v ktorch funguj.
Najastejie sa riziko vyjadruje ako stredn hodnota dopadu hrozby, t.j.
riziko = pravdepodobnos * dopad hrozby,
alebo na logaritmickej kle 34:
riziko = pravdepodobnos + dopad hrozby.
Pri vpote rizika sa vyuvaj dva zkladn prstupy; kvantitatvny a kvalitatvny. Pri
kvantitatvnom prstupe je riziko aj dopad vyjadren selne (dopad naprklad vkou finannej
straty, pravdepodobnos slom z intervalu <0,1>), pri kvalitatvnom prstupe sa
pravdepodobnos, dopad aj samotn riziko kategorizuj a vyjadruj slovne. Hoci kvantitatvna
metda vyzer na prv pohad exaktnejie a objektvnejie, pouva sa len zriedka, pretoe je
problm presne uri tak hodnotu dopadu ako aj pravdepodobnosti nejakej udalosti.35 V alom
texte preto rozoberieme kvalitatvnu metdu odhadu rizk. Organizcia by mala ma vytvoren
kritri pre hodnotenie dopadu hrozby, postaven na rovni kd a vke materilnych strt,
ktor v dsledku naplnenia hrozieb utrp, zohadujce poda ISO normy [5]
rove klasifikcie postihnutch informanch aktv,

zvanos naruenie informanej bezpenosti (napr. strata dvernosti, integrity a
dostupnosti),
32
zoznam hrozieb je uveden v prlohe Katalg elementrnych hrozieb

zoznam zranitenost je uveden v prlohe Zoznam zranitenost
34
pripomname, e log x.y = log x + log y
35
ako vyjadri pravdepodobnos udalosti, ktor v organizcii ete nikdy predtm nenastala? Je mon
povaova ju za nulov a hrozbou sa nezaobera? Alebo ako sa d exaktne vyjadri hodnota nehmotnch
aktv, ako je know-how, dobr meno, alebo zdravie a spokojnos zamestnancov?
33
26
naruenie operci/innosti (organizcie, alebo tretch strn),

finann straty,
naruenie plnov a nesplnen termny,
pokodenie reputcie,
poruenie prvnych, zmluvnch a regulanch poiadaviek.
Tento zoznam je potrebn doplni o zdravie a ivot ud 36, lebo strata zdravia a udskho ivota
je z etickho hadiska nenahraditen, strata kvalifikovanho zamestnanca me by ako
nahraditen a zranenie alebo smr loveka me ma negatvne dopady na organizciu
(reputcia, prvne dsledky) .
Hrozby mu ma rzne formy dopadu (napr. zplava: utopenie loveka, pokodenie budovy,
pokodenie zariaden, potaov, preruenie napjania, preruenie komunikanch liniek,
znemonenie prstupu zamestnancov do budovy, znemonenie prchodu zamestnanca do prce,
zneistenie okolitho prostredia, pokodenie cestnch komunikci, a i.). Vyhneme sa
rozoberaniu monch foriem a vyuijeme americk federlny tandard FIPS 199 [12], ktor
abstrahuje od zbytonch podrobnost a vyjadruje rzne formy dopadu hrozieb pomocou
naruenia zkladnch bezpenostnch poiadaviek na ochranu informcie (dvernos, integrita a
dostupnos) a definuje tri kvalitatvne rovne dopadu:
nzky, ak strata dvernosti, integrity alebo dostupnosti 37 m obmedzen negatvny vplyv na
innos organizcie, jej aktva alebo osoby 38. Obmedzen negatvny dopad znamen, e strata
dvernosti, integrity alebo dostupnosti me spsobi
znenie schopnosti organizcie v takej miere a na tak dobu, e organizcia je sce

schopn plni svoje primrne funkcie ale menej efektvne,
mlo zvan pokodenie aktv organizcie,
mal finann straty,
mal ujmu osobm.
stredn, ak strata dvernosti, integrity alebo dostupnosti m zvan negatvny vplyv na innos
organizcie, jej aktva alebo osoby. Zvan negatvny vplyv znamen, e strata dvernosti,
integrity alebo dostupnosti me spsobi
znenie schopnosti organizcie v takej miere a na tak dobu, e organizcia je sce

schopn plni svoje primrne funkcie ale efektvnos jej innosti je vrazne redukovan,
znan pokodenie aktv organizcie,
znan finann straty,
vznamn ujmu osobm (ale nie zvan zranenia alebo straty na ivotoch).
vysok (katastrofick) ak strata dvernosti, integrity alebo dostupnosti m vemi zvan a

katastrofick negatvny vplyv na innos organizcie, jej aktva alebo osoby. Vemi zvan
negatvny vplyv znamen, e strata dvernosti, integrity alebo dostupnosti me spsobi
tak kody, e organizcia nie je schopn vykonva niektor zo svojich primrnych

funkci,
rozsiahle pokodenie aktv organizcie,
vek finann straty, ktor organizcia nie je schopn kompenzova z vlastnch
zdrojov,
vek a katastrofick ujmu osobm (vrtane ivot ohrozujcich zranen a smrti osb).
s relevantn najm pre systmy v ktorch sa spracovvaj zdravotn informcie (nesprvna lieba
v dsledku naruenia integrity alebo dostupnosti dajov), riadiacich systmoch (napr. doprava, elektrrne,
vrobn linky).
37
tu aj v alch prpadoch sa rozumie v dsledku naplnenia hrozby
38
napr. naruenie skromia
36
27
Druhm initeom ovplyvujcim vku rizika je pravdepodobnos naplnenia hrozby. Na

hodnotu pravdepodobnosti (naplnenia hrozby voi konkrtnemu aktvu) vplva o.i. existencia
zranitenost, prijat opatrenia, prpadne potrebn ton potencil. Na ohodnotenie
pravdepodobnosti budeme pouva 4 stupov klu a riziko budeme vyjadrova slovne
(nulov, nzke, stredn, vysok), alebo na vyjadrenie jeho hodnoty pouijeme seln klu:
oznaenie
pomenovanie
poznmka
nulov
udalos nenastane 39
nzka
udalos nenastala, alebo sa vyskytne raz za niekoko rokov
stredn
raz za rok
vysok
niekokokrt mesane/tdenne
Tabuka 3.1. Kvalitatvne vyjadrenie rovne pravdepodobnosti udalosti

Metda odhadovania rizika pre 4 rovov klu pravdepodobnost a 3 rovov klu dopadu je
uveden v nasledujcej tabuke
dopad
nzky
stredn
vysok
nulov
nulov
nulov
nulov
nzka
nzke
nzke
stredn
stredn
nzke
stredn
vysok
vysok
stredn
vysok
vysok
pravdepodobnos
Tabuka 3.2. Kvalitatvne vyjadrenie rizika

In tabuky pre odhad rizk s uveden v norme [5].
Po odhade rizk je potrebn rozhodn, o s nimi organizcia bude robi. M tyri monosti [5]:
1. redukcia rizika. V tomto prpade organizcia prijma opatrenia (technick, organizan,
personlne a in) zameran na znenie pravdepodobnosti naplnenia a/alebo dsledkov
hrozby tak, aby sa hodnota vslednho rizika dostala pod rove akceptovatenho
rizika.
2. zachovanie rizika (risk retention): ak je rove rizika niia ako rove
akceptovatenho rizika, organizcia nemus prijma iadne opatrenia.
3. vyhnutie sa riziku. Prichdza do vahy vtedy, ke by opatrenia na redukciu rizika boli
prli nkladn, ale hodnota rizika je vyia ako rove akceptovatenho rizika.
Organizcia zmen podmienky, ktor viedli k neprijatene vysokmu riziku, naprklad
39
takto prpad nastane, ke hrozba vyuva zranitenos, ktor bola prijatmi opatreniami odstrnen
28
pouitm inho rieenia (vykonvanie innosti inm spsobom, prenesenie innost do

menej nebezpenho prostredia a pod.)
4. prenesenie rizika. Organizcia me prenies riziko na in subjekt 40, ktor ho doke
efektvnejie riei. (Prkladmi prenesenia rizika s napr. zmluvy s dodvateom
o skrtenej dobe servisnho zsahu, outsourcing problematickch innost, poistenie).
Aby organizcia mohla rozhodn, ktor z monost rieenia pre jednotliv rizik zvol, rizik je
potrebn posdi z hadiska ich zvanosti a monost a ochoty organizcie nieo s nimi spravi.
alm krokom po analze rizk 41 je preto ohodnotenie rizk. Ak m organizcia vypracovan
bezpenostn politiku poda ISO normy [3] mala by ma v bezpenostnej politike jasne
stanoven priority, poadovan rove ochrany, kritri pre ohodnotenie rizk a hranicu
akceptovatenho rizika. Ohodnotenie rizk sa potom vykonva 42 vzhadom na tieto kritri
a jeho vsledkom je zoradenie rizk poda priority. Zoznam ohodnotench rizk mus ma
minimlne dve asti: rizik, ktormi sa organizcia nebude zaobera a rizik, ktor je organizcia
pripraven riei. Prv kategriu tvoria tzv. akceptovaten rizik, ktorch hodnota neprevyuje
vopred stanoven hranicu. Hoci na ich rieenie organizcia nemus prijma iadne opatrenia, aj
tieto rizik je potrebn zdokumentova, zdvodni, preo boli takto ohodnoten a sledova, i sa
asom nezmenili podmienky a nevzrstla hodnota dopadu alebo pravdepodobnosti hrozieb tak, e
rove niektorho z rizk prvej kategrie nepresiahla hodnotu akceptovatenho rizika.
Pre ostatn rizik je potrebn prija opatrenia, ktor by znili ich hodnotu pod akceptovaten
rove a spravova ich; vyhn sa im alebo ich prenies na in subjekt.
2.8 Bezpenostn opatrenia

It is estimated that ninety-nine per cent of all reported intrusions result through
exploitation of known vulnerabilities or configuration errors, for which
safeguards and countermeasures were available (NIST SP 800-53)
Bezpenostn opatrenia (safeguards, security controls, security measures) s rieenia, ktorch
zavedenm (implementciou) sa eliminuje alebo aspo zni rove rizika. Poda prostriedkov,
ktor pouvaj sa opatrenia delia na [14]
a) technick,
b) organizan a
c) prevdzkov.
Poda toho, na ktor fzu potencilneho bezpenostnho incidentu spsobenho naplnenm
hrozby psobia, delme opatrenia na
a) preventvne
b) detekn
c) korekn
Technick opatrenia s zaloen na bezpenostnch funkcich realizovanch pomocou
hardvrovch komponentov, firmvru a softvru. Organizan opatrenia sa realizuj pomocou
politk, pravidiel, zvznch postupov, stanoven zodpovednosti, kolen zamestnancov, zmlv.
40
pripomname, e prenesenm rizika sa organizcia spravidla nezbavuje zodpovednosti za prpadn dopad

hrozby, pretoe klienti bud povaova problmy spsoben prpadnm bezpenostnm incidentom za
chybu organizcie
41
niekedy sa ohodnotenie rizk povauje za sas analzy rizk
42
ohodnotenie rizk by mal robi manar IB s pomocou vlastnkov dotknutch aktv a vsledky
ohodnotenia rizk pravdepodobne bude musie schvaova manament, pretoe na ich zklade bude
potrebn prija opatrenia.
29
Prevdzkov opatrenia zahaj fyzick ochranu IKT, podpornej infratruktry, ochranu

prstupu, detekcie pohybu, detekcie poiaru a pod. Hoci sa opatrenia kategorizuj, pri nvrhu
opatren na zmiernenie rizika sa kombinuj opatrenia vetkch troch kategri.
lohou preventvnych opatren je zamedzi vzniku bezpenostnho incidentu, alebo aspo
vrazne zni pravdepodobnos naplnenia hrozby. Preventvne opatrenia s zameran bu na
odstrnenie zranitenosti, ktor hrozba vyuva, alebo v prpade, ak je nositeom hrozby lovek,
na znenie jeho tonho potencilu:
motivcie: napr. zvenie pravdepodobnosti jeho odhalenia a potrestania (odstraenie),

prleitos: na prekonanie novch opatren potrebuje podstatne vie zdroje,
znalosti: odstrnenie znmych zranitenost, ktor umoovali toky.
Detekn opatrenia predstavuj druh rove ochrany aktv. Ich cieom je odhali vas
zanajci bezpenostn incident, signalizova ho napr. opertorovi a zaznamena daje potrebn
na analzu vzniku a priebehu bezpenostnho incidentu. Prkladmi deteknch opatren s
zariadenia na detekciu pohybu, dymu, IDS (intrusion detection systems, systmy na detekciu
prieniku), monitorovacie programy, systmy na vytvranie zznamov auditu a pod. Korekn
opatrenia s zameran na zabezpeenie kontinuity innosti: v prpade bezpenostnch
incidentov na ich rieenie a na nvrat aktva do normlneho stavu. Prklady opatren s uveden
niie.
Poslednm krokom pred vberom opatren na oetrenie neakceptovatench rizk je analza
ekonomickej efektvnosti (cost/benefit) navrhovanch opatren, ktor pripravuje pracovn
skupina. Vstupom pre analzu ekonomickej efektvnosti je zoznam identifikovanch rizk. Ku
kadmu riziku s priraden mon opatrenia a analza pozostva z
urenia dopadu zavedenia novho alebo rozrenia existujceho opatrenia,

urenia dopadu toho, e sa nov opatrenie nezavedie alebo existujce opatrenie nerozri,
odhadu nkladov na zavedenie novho alebo rozrenia existujceho opatrenia, napr.
o kpa technickch zariaden a/alebo softvru,
o prpadn znenie efektvnosti innosti systmu v dsledku zavedenia opatrenia,
o nklady spojen so zavedenm dodatonch politk a procedr,
o nklady na personl potrebn na zavedenie novch opatren (pracovn as
existujcich zamestnancov, alebo prostriedky spojen s prijatm novch
zamestnancov)
o nklady na kolenia zamestnancov,
o nklady na drbu
porovnanie nkladov na zavedenie novho alebo rozrenia existujceho opatrenia a jeho
prnosu vzhadom na vznam tch systmov a dajov pre organizciu, ktorch ochrana
sa danm opatrenm zvi (resp. u ktorch sa zni rove rizika).
Zveren rozhodnutie je na vedcom zamestnancovi (alebo veden) organizcie, ktor mus

posdi, i je v danom prpade riziko akceptovaten alebo nie, a i nvrh na zavedenie novho
opatrenia mono zamietnu alebo nie. Pre rozhodovanie o zaveden novho opatrenia mu
pomc nasledujce pravidl:
a) ak opatrenie redukuje riziko viac, ne je potrebn, treba sa pozrie, i neexistuje in,
lacnejie rieenie,
b) ak je cena navrhovanho rieenia vyia ako hodnota, o ktor redukuje riziko, treba
hada in rieenie
c) ak opatrenie neredukuje riziko dostatone, treba sa pozrie na alie doplujce
opatrenia alebo nejak in opatrenie,
d) ak navrhovan opatrenie redukuje riziko dostatone a je spomedzi monch opatren
najlacnejie, treba ho poui.
30
Nasledujci zoznam obsahuje opatrenia, ktor poda [17] organizcia mus zavies na
dosiahnutie zkladnej rovne bezpenosti 43 svojich IKT.
Riadenie prstupu (Access Control (AC)) Organizcia mus zabezpei
aby prstup k systmu mali len oprvnen osoby a in zariadenia alebo systmy
(extern potae),
aby oprvnen osoby mohli pristupova (priamo, alebo prostrednctvom inch
systmov alebo procesov) len k tm zdrojom systmu, na ktor maj oprvnenia
a vykonva len tie innosti, na ktor s oprvnen.
Bezpenostn povedomie a trning. (Awareness and Training (AT)) organizcia mus

zabezpei
aby si manari a pouvatelia IKT systmov v organizcii boli vedom

bezpenostnch rizk spojench s ich innosou a poiadaviek, ktor pre nich
vyplvaj v tejto svislosti z prslunch zkonov, bezpenostnej politiky
a alej vntornej legislatvy organizcie, bezpenostnch tandardov
a prevdzkovho poriadku IKT systmov;
aby bol personl a pouvatelia primerane trnovan na to, aby si dokzali plni
povinnosti poda prvho bodu tkajce sa bezpenosti prevdzky a pouvania
IKT systmov.
Audit a dosledovatenos (Audit and Accountability (AU)): Organizcia mus
vytvra, chrni a udriava zznamy auditu innosti IKT systmu v rozsahu

potrebnom na to, aby bolo mon monitorova, analyzova, vyetrova
a nahlasova protizkonn, neoprvnen alebo neprimeran aktivity v IKT
systme,
zabezpei, aby jednotliv aktivity v IKT systme boli jednoznane spojen
s pouvatemi, ktor ich vykonali a tak tto pouvatelia mohli by bran na
zodpovednos za svoju innos v systme.
Certifikcia, akreditcia a bezpenostn ohodnotenie (Certification, Accreditation, and

Security Assessments (CA)) Organizcia mus
periodicky vyhodnocova bezpenostn opatrenia v IKT systmoch organizcie,

aby urila, i s opatrenia inn,
vypracova a implementova plny innosti zameran na opravu nedostatkov
a redukciu alebo odstrnenie zranitenost v IKT systmoch organizcie
povoli prevdzku IKT systmov organizcie a pripojenie externch systmov
k nim,
neustle monitorova bezpenostn opatrenia na ochranu IKT systmov, aby
zaistila ich stlu innos.
Manament konfigurcie (Configuration Management (CM)) Organizcia mus
zavies a udriava zkladn konfigurcie IKT systmov a katalgy IKT

systmov (hw, sw, firmware a dokumentcia) organizcie poas ich ivotnch
cyklov,
zavies a presadzova nastavenia bezpenostnej konfigurcie IKT produktov
pouvanch v IKT systmoch organizcie
zkladn rove neznamen nzku rove bezpenosti, pozri Prlohu 2.13.4 Klasifikcia informcie a
systmov
43
31
Havarijn plnovanie (Contingency Planning (CP)): Organizcia mus
vypracova, udriava a efektvne implementova plny reakcie v mimoriadnych

situcich, zlohovacie procedry a plny obnovy pre IKT systmy organizcie, aby
zaistila dostupnos kritickch informanch zdrojov a kontinuitu operci
v mimoriadnych situcich.
Identifikcia a autentifikcia Identification and Authentication (IA): Organizcia mus
identifikova pouvateov IKT systmov, zariaden, procesov konajcich v zujme

pouvateov; a overi identity tchto pouvateov, procesov alebo zariaden ete pred
tm ako im povol prstup k IKT systmom organizcie
Reakcia na incidenty (Incident Response (IR)) Organizcia mus
pre IKT systmy organizcie vytvori operan kapacity na rieenie bezpenostnch

incidentov, ktor s schopn vykonva adekvtnu prpravu zamestnancov, detekciu,
analzu, ohranienie bezpenostnho incidentu, obnovu IKT systmu po incidente
a primeran reakcie pouvateov na incident,
vystopova, zdokumentova a nahlasova prslunm riadiacim pracovnkom
organizcie, prpadne radom.
drba (Maintenance (MA)): Organizcia mus
vykonva aktulnu (poda potreby) a periodick drbu IKT systmov organizcie,

zabezpeova efektvny dohad nad nstrojmi, technikami, mechanizmami, ktor sa
pouvaj pri drbe a personlom ktor drbu vykonva.
Ochrana mdi (Media Protection (MP)) Organizcia mus
chrni pamov mdia tak papierov ako aj digitlne (elektronick),

obmedzi prstup k informcim uloenm na pamovch mdich IKT systmu len pre
oprvnen osoby,
znii pamov mdi pred ich vyradenm alebo bezpene odstrni daje
z pamovch mdi pred ich optovnm pouitm.
Fyzick ochrana a ochrana prostredia (Physical and Environmental Protection (PE))

Organizcia mus
obmedzi fyzick prstup k IKT systmom, zariadeniam a do ich operanho prostredia

len na oprvnen osoby
chrni fyzick zariadenia a podporova infratruktru IKT systmov
poskytova pre IKT systmy podporn zariadenia potrebn pre ich prevdzku
chrni IKT systmy proti prrodnm hrozbm a hrozbm z prostredia
zaisti primeran environmentlne opatrenia v zariadeniach v ktorch s umiestnen IKT
systmy
Plnovanie (Planning (PL)): Organizcia mus
vyvin, zdokumentova, periodicky aktualizova a implementova bezpenostn plny

pre IKT systmy organizcie, ktor popisuj pouit alebo plnovan bezpenostn
opatrenia pre IKT systmy a pravidl sprvania jednotlivcov, pristupujcich k IKT
systmom.
Personlna bezpenos (Personnel Security (PS)) Organizcia mus
32
zabezpei, aby jednotlivci ktor zastvaj zodpovedn funkcie v organizcii (vrtane

tretch strn poskytujcich sluby organizcii) boli dveryhodn osoby a spali
bezpenostn kritri stanoven pre dan funkcie, zaisti, aby informcie a IKT systmy
organizcie boli chrnen poas personlnych zmien a po nich, ako s ukonenie
pracovnho pomeru alebo zmena pracovnho zaradenia,
zavies a uplatova formlne sankcie voi zamestnancom, ktor konali v rozpore
s bezpenostnou politikou alebo bezpenostnmi procedrami organizcie.
Ohodnotenie rizk (Risk Assessment (RA)): Organizcia mus
periodicky ohodnocova rizik voi aktivitm organizcie (vrtane poslania organizcie,

funkci, ktor pln, imidu alebo reputcie), aktvam organizcie, a jednotlivcom, ktor
vyplvaj z innosti IKT systmov organizcie a s nimi svisiaceho spracovania,
uchovvania alebo prenosu informcie.
Obstarvanie systmov a sluieb (System and Services Acquisition (SA)): Organizcia mus
vyhradi dostaton zdroje na primeran ochranu IKT systmov organizcie

pouva v priebehu celho ivotnho cyklu systmu tak procesy, ktor zohaduj
bezpenostn aspekty systmu
dodriava obmedzenia na intalciu a pouvanie softvru
zaisti, aby tretie strany pri poskytovan sluieb organizcii pouvali adekvtne
bezpenostn opatrenia na ochranu informcie, aplikci a/alebo sluieb ktor organizcii
poskytuj
Ochrana systmu a komunikcie (System and Communications Protection (SC))

Organizcia mus
monitorova, kontrolova a chrni komunikciu organizcie (t.j. informcie vysielan

alebo prijman IKT systmami organizcie) na vonkajch hraniciach a kovch
vntornch hraniciach informanch systmov
uplatova pri vvoji a prevdzke IKT systmov tak nvrhy architektry, techniky
vvoja softvru a ininierske princpy, ktor podporuj informan bezpenos v IKT
systmoch organizcie.
Integrita systmu a informcie (System and Information Integrity (SI)) Organizcia mus
vas identifikova, nahlasova a korigova chyby v informcii a v IKT systmoch

organizcie,
na vhodnom mieste IKT infratruktry organizcie (centrlne a/alebo distribuovane)
zabezpeova ochranu IKT systmov pred kodlivm softvrom
monitorova bezpenostn vstrahy a odporania systmu a primerane na ne reagova.
2.9 Spravovanie rizk

Organizcia zavedenm novch alebo rozrenm existujcich opatren zmiernila rizik tm, e
a) odstrnila niektor zranitenosti aktv, m sa zredukovala na nulu pravdepodobnos
naplnenia niektorch hrozieb, (preloenie serverov z przemnej miestnosti na 2.
poschodie odstrnilo monos zaplavenia potaov vodou z rozvodnenej rieky)
b) pridanie cielenho opatrenia znilo kapacitu a motivciu tonka (zruenie anonymnho
prstupu k systmu, siln identifikcia a autentizcia pouvateov, vytvranie zznamov
auditu o innosti v systme)
c) znil sa rozsah negatvneho dopadu bezpenostnho incidentu na organizciu (napr.
zlohovanm dajov a monosou prenies v krtkom ase innos z jednho systmu na
zlon systm).
33
Je vemi pravdepodobn, e sa nepodarilo eliminova vetky rizik. Rizik, ktor ostali po prijat
novch a/alebo rozren existujcich opatren sa nazvaj zostatkov (zvykov, alebo
rezidulne) rizik, ktor bude potrebn porovna s hranicou akceptovatenho rizika. Ak je
rove niektorho zostatkovho rizika vyia ako rove akceptovatenho rizika, organizcia
m dve monosti:
a) njs a implementova vhodn opatrenia, ktor by znili rove vysokch
zostatkovch rizk na rove akceptovatenho rizika,
b) prehodnoti rove akceptovatenho rizika alebo podmienen akceptcia
nerieitenho rizika s povinnosou monitorova prslun aktvum, aby sa vas
zachytil zaiatok prpadnho bezpenostnho incidentu.
Dosiahnutie poadovanej rovne IB znenm rizk na akceptovaten rove nemus ma dlh
trvanie. Podmienky, za ktorch organizcia robila analzu rizk, sa neustle menia:
a) Men sa samotn organizcia (organizan truktra, technick infratruktra,
zamestnanci, ich pracovn zaradenie, roly, vyvja sa poslanie organizcie, men sa
citlivos dajov a pod.). Tieto zmeny mu spsobi, e sa menia aj predpoklady,
z ktorch sa vychdzalo pri analze rizk a teda zvery analzy rizk (najm
vyhodnotenie rizk) nemusia by platn.
b) Menia sa technolgie a v dsledku toho sa objavuj nov zranitenosti, hrozby; star
opatrenia strcaj na innosti, resp. s celkom neaktulne, rove rizk sa me meni
(zvyova).
Aby sa v dynamicky sa meniacom prostred udrala poadovan rove IB v organizcii,
organizcia mus priebene monitorova bezpenostn situciu a v prpade vekch zmien
(organizan zmeny, infratruktra, zmeny zkonov s vekm dopadom na organizciu44, vek
bezpenostn incidenty a pod. ) a v pravidelnch asovch intervaloch zopakova analzu rizk
a aktualizova prijat opatrenia. Ak maj zmeny loklny charakter (zavedenie novho systmu),
analza rizk nemus pokrva cel organizciu a me sa zamera len na tie oblasti, ktor boli
zmenami dotknut.
Zhrnutie. Po prijat opatren mus organizcia skontrolova, i sa jej tm podarilo zni vetky
rizik na prijaten mieru. Ak nie, mus hada in rieenia. Ale ani uspokojiv stav nemus trva
dlho a organizcia mus vyhodnocova zmeny, ktor mu spsobi objavenie novch alebo
nrast existujcich rizk nad prijaten rove. Okrem analz rizk vyvolanch vekmi
zmenami odporame pravideln posdenie IB, aby sa zamedzilo tomu, e asom nepozorovane
vyprchala innos prijatch opatren.
2.10 Bezpenostn audit

Systm opatren, ktor organizcia prijala po analze rizk, nemusel splni jej oakvania.
Niektor opatrenia mohli osta len na papieri, in mohli by implementovan len iastone,
alie stratili na innosti; problmy mu by aj v samotnom ISMS, nevyjasnench
kompetencich alebo chbajcich zdrojoch. Na odhaovanie takchto nedostatkov sli audit.
Audit vo veobecnosti je nezvisl jednorazov kontrola, poas ktorej sa zisuje slad predmetu
auditu s nejakm idelnym stavom. V prpade bezpenostnho auditu organizcie bud
predmetom auditu bezpenostn opatrenia a innos ISMS. Audit opatren ISMS je popsan
v norme ISO/IEC TR 27008 [6] z ktorej sme v tejto asti vychdzali.
Bezpenostn audit sa v organizcich vykonva
a) v pravidelnch asovch intervaloch (naprklad kadorone). Cieom pravidelnho
auditu je posdi, i nedolo k zmenm, ktor sa sce zatia neprejavili, ale mohli zni
44
napr. prijatie Zkona o kritickej infratruktre, Novelizcia Zkona o ochrane osobnch dajov,
v budcnosti prijatie zkona o IB, novelizcia Vnosu MF SR o tandardoch pre ISVS a pod.
34
innos existujcich opatren a tm zvi rove rizk. Pravideln audit umon vas
odhali neinn opatrenia a da podnet na npravu. Zvery auditu s dleitm
podkladom pre pravideln (vron) hodnotenie stavu IB v organizcii.
b) nepravidelne. Podnetom pre vykonanie mimoriadneho bezpenostnho auditu bvaj
najastejie bezpenostn incidenty (asto sa opakujce alebo s vnymi dsledkami pre
organizciu) ktor naznauj, e rove IB v organizcii nie je dostaton, alebo vek
zmeny, ktor si vyiadali prehodnoti systm bezpenostnch opatren. V takchto
prpadoch je lohou bezpenostnho auditu posdi, i existujce bezpenostn opatrenia
poskytuj poadovan rove ochrany.
pecilnym prpadom auditu je tzv. cerifikan audit, ktorho lohou je overi, i je predmet
auditu v slade s nejakm tandardom (napr. i je ISMS organizcie v slade s normou (ISO/IEC
27001). Certifikciou sa budeme zaobera v asti 2.12.
Iniciovanie a zdroje na audit. Povinnos organizcie vykonva pravidelne bezpenostn audit
je stanoven v bezpenostnej politike a audit by mal by zaraden do plnu innosti organizcie
a mali by na by plnovan prostriedky. Vykonanie mimoriadneho auditu bude iniciova
pravdepodobne manar IB, ktor bude musie poiada vedenie o poskytnutie potrebnch
neplnovanch zdrojov. V alom texte predpokladme, e prpravu auditu a koordinciu
sinnosti audtorov a zamestnancov organizcie bude riadi/vykonva manar IB.
Prprava auditu. Manar IB zozbiera potrebn informcie o systmoch, ktor sa maj
posudzova (technick a prevdzkov dokumentciu, predchdzajcu analzu rizk, informcie o
bezpenostnch incidentoch, plny auditu podobnch systmov 45 , vsledky predchdzajcich
auditov systmov organizcie, bezpenostn politiku, tandardy a praktiky pre relevantn
systmy). Na zklade predbene zozbieranch informci spresn rozsah a hbku auditu.
Vber audtorov. Na vykonanie auditu je potrebn odborn kvalifikcia, informan zdroje
a sinnos zamestnancov organizcie. Aby vsledky auditu neboli ovplyvnen zujmami
audtorov, bezpenostn audit nesm vykonva udia, ktor sa podieali na vytvran systmu
alebo na innosti, ktor je predmetom posudzovania. Vykonanm auditu mus organizcia poveri
nezvislho audtora (audtorov), v prpade potreby aj externch. Ke bud audit vykonva
extern audtori, odporame zapoji do audtorskho tmu aj vlastnch zamestnancov
organizcie, aby sa nauili robi audit.
Audtori bud poas auditu potrebova komunikova so zamestnancami (riadiacimi pracovnkmi,
informatikmi, pouvatemi). Manar IB vopred informuje o pripravovanom audite
zamestnancov, ktorch sinnos pri audite je potrebn a spolu s audtormi priprav
harmonogram auditu.
Prprava plnu auditu. Podrobn pln auditu u pripravuj audtori (rozsah, harmonogram,
metdy, ktor hodlaj poui) a schvauje 46 ho manar IB.
Vykonanie auditu. Poas samotnho auditu audtori bud skma objekty (systmy, ich
komponenty, opatrenia a pod.) aby zistili, i spaj poiadavky, ktor s na ne kladen.
Vsledkom posudzovania napr. opatrenia je
a) spa, ak opatrenie v plnom rozsahu pln svoj el;
b) spa iastone, ak ete nebolo plne implementovan, jeho funkcionalita nie je pln
alebo nem dostaton rove,
c) in, ak opatrenie nebolo vbec implementovan, nepln poadovan funkcie, alebo
audtor nemal na jeho posdenie potrebn informcie.
45
ak s, pravda, dostupn
audit zasiahne aj innos organizcie a jeho negatvne dopady je potrebn minimalizova. Preto mus
pln auditu schvli na to oprvnen zamestnanec organizcie.
46
35
Vsledky typu b) a c) audtor mus zdvodni (a prpadne uvies, i mu spsobi naruenie

dvernosti, integrity alebo dostupnosti dajov), aby organizcia vedela, o potrebuje spravi na
npravu nedostatkov.
Posdenie zverov auditu. Partnermi audtorov pri posudzovan konkrtnych systmov, resp.
opatren, ktor sa ich tkaj, s riadiaci pracovnci, ktor s za tieto systmy zodpovedn
(majitelia systmov). Tto dostan predben vsledky auditu ete pred tm, ako na ich zklade
napu audtori zveren sprvu a maj monos odstrni zisten nedostatky. Ak sa tak stalo,
audtori v zverenej sprve uved zistenia, ktor sa tkaj stavu po odstrnen nedostatkov.
Zveren sprva. Odovzdanm zverenej sprvy sa pre audtorov audit kon. Zistenia, ktor
zveren sprva obsahuje, spracuj zodpovedn pracovnci (manar IB, majitelia systmov,
informatici) rovnako ako zvery analzy rizk. Posdia rizik vyplvajce zo zistench
nedostatkov a navrhn rieenia. Kee nedostatky v opatreniach znamenaj, a) e sa vynakladaj
prostriedky organizcie na nedostatone inn opatrenia a b) aktva organizcie nie s
dostatone chrnen; zveren sprvu auditu a navrhovan postup na odstrnenie zistench
nedostatkov by malo prerokova vedenie organizcie.
2.11 tandardy
Zaisti primeran rove IB v organizcii nie je u na prv pohad vzhadom na rozsah,
zloitos a rchle zmeny IKT jednoduch loha. Ak by kad organizcia mala riei svoje
bezpenostn problmy samostatne, bola by to pre vinu z nich nerieiten loha. Organizcie
vak naastie pouvaj tandardn technick prostriedky so tandardnm programovm
vybavenm. Aj tch niekoko pecifickch aplikci, ktor si pre svoje potreby organizcie
nechali vytvori, vyuva tandardn vvojov prostriedky a prevdzkuje sa na tandardnch
IKT. Prevan vina IKT a programovho vybavenia v organizcich je teda tandardn a m
rovnak bezpenostn problmy, ktor je mon riei tandardnmi prostriedkami. V priebehu
uplynulch 2-3 desaro ttne, skromn, akademick, odborn a in organizcie vyvinuli
znan silie o tandardizciu IB, vsledkom ktorej je mnostvo noriem, technickch sprv, defacto tandardov, odporan a nvodov. Na Slovensku za normalizciu zodpoved Slovensk
rad technickej normalizcie, STN. STN vak nevyvja vlastn normy; bezpenostn normy,
ktor obsahuje STN, s prebrat prevane z ISO. ISO normy pre oblas manamentu IB s
sstreden v rade ISO/IEC 47 270xx. Rad ISO/IEC 270xx obsahuje 23 noriem, alch 11 je
rozpracovanch 48. Strune popeme najdleitejie z nich.
ISO/IEC 27000 Information security management systems Overview and vocabulary.
Norma obsahuje prehad ISO noriem venovanch manamentu IB a vklad zkladnch pojmov,
ktor sa v normch radu ISO/IEC 270xx pouvaj. (Najdleitejie z nich s zaraden do
vkladovho slovnka uvedenho v prlohe tejto knihy).
ISO/IEC 27001 Information security management systems Requirements. Toto je
strun norma obsahujca poiadavky, ktor musia spa systmy manamentu IB (ak maj
zska certifikciu poda ISO/IEC 27001). Tieto poiadavky s podrobnejie rozpracovan
v norme
ISO/IEC 27002 Code of practice for information security management. Tto norma
obsahuje okolo 150 opatren, ktor je potrebn zavies na naplnenie poiadaviek stanovench
v norme ISO/IEC 27001. Ak by aj organizcia nemala ambcie necha svoj systm manamentu
IB certifikova poda ISO/IEC 27001, mala by dobre pozna ISO/IEC 27002, pretoe tto norma
je zkladom pre zvzn bezpenostn tandardy ISVS [21].
ISO/IEC 27005 Information security risk management. Toto je vemi uiton norma,
ktor popisuje sprvu rizk, vrtane podrobnho postupu pri analze rizk.
Na vvoj noriem pre oblas IKT ISO vytvorilo spolon vbor s IEC (JTC 1), v ktorom za informan
bezpenos zodpoved podvbor SC 27.
48
prehad radu ISO/IEC 270xx mono njs na strnke http://en.wikipedia.org/wiki/ISO/IEC_27000-series
47
36
ISO/IEC TR 27008 Guidance for auditors on ISMS controls (focused on the information
security controls) Norma m formu technickej sprvy (Technical report) a obsahuje podrobn
nvod, ako pripravi audit bezpenostnch opatren ISMS. Predmetom posudzovania me by aj
samotn ISMS organizcie; o tom, ako pripravi a vykona audit ISMS pojednva pomerne
veobecn norma ISO/IEC 27007.
ISO normy s niekedy prli veobecn a detailne rozoberaj problmy, ktor s zaujmav len
pre zky okruh pecialistov. Pre praktick pouitie mu by uiton normy americkho NIST
a nemeckho Spolkovho radu pre informan bezpenos, BSI.
Americk NIST (National Institute of Standards and Technology Nrodn intitt pre
tandardy a technolgie) zodpoved zo zkona 49 za vvoj tandardov, technk a nvodov na
zaistenie informanej bezpenosti IKS (s vnimkou systmov pracujcich s klasifikovanou
informciou) v americkch ttnych intitcich a agentrach. Hoci je prvne prostredie
a organizcia americkch intitci in ako na Slovensku, niekoko americkch tandardov
a mnostvo metodickch materilov NIST je pouitench aj v slovenskch podmienkach.
Obmedzme sa op na dokumenty svisiace s manamentom IB. Zkladom pre manament
informanej bezpenosti je bezpenostn kategorizcia informanch systmov, ktor je
definovan v nasledujcich dvoch federlnych tandardoch:
FIPS 199 Standards for Security Categorization of Federal Information and Information
Systems definuje spsob klasifikcie informcie a systmov, v ktorch sa tto informcia
spracovva, zaloen na ohodnoten dopadov, spsobench naruenm dvernosti, integrity
a dostupnosti informcie. Na tento tandard nadvzuje
FIPS 200 Minimum Security Requirements for Federal Information and Information
Systems, ktor popisuje, ako na zklade klasifikcie systmov stanovi bezpenostn poiadavky
zodpovedajce poadovanej rovni ich ochrany. Prstupy uveden v tchto dvoch americkch
tandardoch s podrobnejie popsan v prlohe Klasifikcia informcie a systmov.
NIST vydva asi 20 rokov metodick materily z IB v srii Special publications 800. Vyie
uveden federlne tandardy (vytvoren NIST) s podrobnejie rozpracovan v metodickej
publikcii
NIST SP 800-60, Guide for Mapping Types of Information and InformationSystems to
Security Categorization Levels obsahuje nvod na zaradenie informcie a systmov do
bezpenostnch kategri.
alie dokumenty popisuj postup, ako konkretizova bezpenostn potreby systmu a vybra
pre ne vhodn rieenia:
NIST SP 800 30 Risk Management Guide for Information Technology Systems pokrva
rovnak problematiku ako ISO/IEC 27005 sprvu rizk. Podrobne popisuje najm analzu rizk
a vber opatren.
Metodick nvod na sprvu bezpenostnch rizk v priebehu ivotnho cyklu systmu
zohadujci aj klasifikciu systmov, je uveden v publikcii NIST SP 800-37 Guide for
Applying the Risk Management Framework to Federal Information Systems (A Security
Life Cycle Approach).
Jednm z kovch dokumentov SP 800, obsahovo podobnm ISO/IEC 27002 je SP 800-53
Recommended Security Controls for Federal Information Systems. Obsahuje nvod ako
stanovi bezpenostn kategriu systmu a podrobne pecifikova bezpenostn poiadavky na
zachovanie dvernosti, integrity a dostupnosti. Obsahuje aj tri minimlne sbory bezpenostnch
opatren pre systmy z bezpenostnch kategri nzka, stredn a vysok.
49
In accordance with FISMA, NIST is responsible for developing standards, guidelines, and associated
methods and techniques for providing adequate information security for all agency operations and assets,
excluding national security systems.
37
Na u nadvzuje publikcia Special Publication 800-53A Guide for Assessing the Security
Controls in Federal Information Systems, ktor sa zaober metdami posudzovania
efektvnosti opatren a tm poskytuje sptn vzbu pre sprvu rizk.
Aktualizovan dokument NIST SP 800-34, Rev. 1, Contingency Planning Guide for Federal
Information Systems, obsahuje nvod na prpravu, zavedenie, testovanie a udriavanie plnov
na zabezpeenie kontinuity innosti organizcie.
Vetky uveden dokumenty s napsan tak, aby ich mohli ta aj udia, ktor sa nezaoberaj IB.
S vak pomerne rozsiahle, dos sa prekrvaj a z hadiska vedceho pracovnka obsahuj prli
vea technickch podrobnost. NIST si toho bol zrejme vedom a vydal pre vedcich
pracovnkov sborn prruku manamentu IB NIST SP 800-100 Information Security
Handbook: A Guide for Managers. Hoci v slovenskch podmienkach urite nebude mon
realizova niektor jej odporania v plnom rozsahu (personlne zabezpeenie IB,
dokumentovanie IB), poskytuje pohad na IB z hadiska vedceho pracovnka, ktor
v pecializovanch dokumentoch chba.
Nemeck BSI vypracoval koncepciu ochrany IKT zaloen na tom, e vinu systmov tvoria
tandardn systmy, ktor psobia v podobnch podmienkach. Tento predpoklad umonil
katalogizova hrozby, zranitenosti, ale aj opatrenia. Na zklade tchto katalgov je mon
dosiahnu pomerne jednoducho zkladn rove bezpenosti (tandardnch) systmov; poda
charakteru (typu, urenia, prostredia v ktorom psob) je mon stanovi pre systm relevantn
hrozby a vybra na oetrenie rizk, ktor z nich vyplvaj, tandardn opatrenia. Ak zkladn
rove ochrany (Grundschutz) nepostauje, pre systm je nutn spravi analzu rizk (zameran
vak len na hrozby, ktor nie s dostatone pokryt tandardnmi opatreniami) a navrhn
dodaton opatrenia. Tto koncepcia je podporen veobecne dostupnm a pravidelne
aktualizovanm katalgom hrozieb, zranitenost a opatren a tyrmi tandardami, ktor sa oplat
preta:
BSI Standard 100-1 Information Security Management System (ISMS) definuje poiadavky
na ISMS. Je plne kompatibiln s ISO/IEC 27001, ale je nzornej a lepie itaten ako
spomenut ISO tandard.
BSI Standard 100-2 IT-Grundschutz Methodology podrobne vysvetuje ako vytvori, uvies
do innosti a prakticky prevdzkova ISMS v organizcii. Popisuje, ako napsa bezpenostn
politiku, ako vybra vhodn opatrenia, na o si dva pozor pri implementcii bezpenostnej
politiky a ako udriava poadovan rove ISMS.
BSI Standard 100-3 Risk analysis on the basis of IT-Grundschutz riei problm, ktor sme u
spomenuli vyie: ako efektvne dopa opatrenia poskytujce zkladn rove ochrany
systmu opatreniami, zaruujcimi vyiu rove ochrany.
Zatia posledn z BSI tandardov venovanch IB je zameran na kontinuitu innosti.
BSI Standard 100-4 Business continuity management.
BSI tandardy predstavuj trochu odlin prstup k zaisteniu IB v organizcii, ako americk
federlne tandardy a dokumenty NIST. S vak kompatibiln s ISO tandardami radu 270xx
a ISMS vytvoren na zklade BSI tandardov je mon certifikova poda ISO/IEC 27001.
2.12 Certifikcia
Certifikcia produktu, systmu alebo kvalifikcie je posdenie, do akej miery spa posudzovan
objekt stanoven certifikan kritri. Ak posudzovan subjekt spa certifikan kritri v
dostatonej miere, tak mu o tom prslun certifikan orgn me vystavi osvedenie. V
informanej bezpe-nosti sa certifikuj technick zariadenia, systmy a pecialisti v IB.
Technick zariadenia, systmy, v menej miere softvrov rieenia sa certifikuj najastejie
poda ISO/IEC 15408 (Common Criteria). (Objekt posudzovania norma Common Criteria
nazva TOE - Target Of Evaluation, my ho kvli zjednodueniu budeme oznaova ako systm
38
alebo produkt.) Zkladom certifikcie systmu je tzv. protection profile, registrovan

bezpenostn model systmu. Pri hodnoten systmu sa posudzuje, i spa vetky bezpenostn
poiadavky (bezpenostn funkcie) a na akej rovni (bezpenostn zruky). Common Criteria
maj definovanch 7 hierarchicky usporiadanch rovn bezpenostnch zruk (EAL
Evaluation Assurance Level) a teoreticky m na vyej rovni je systm certifikovan, tm
vyiu rove bezpenostnch zruk by mal poskytova. Vhodou certifikcie systmov (poda
Common criteria) s bezpenostne kompatibiln systmy a garantovan rove zruk.
Certifikovan systmy sa pouvaj najm na implementciu bezpenostnch funkci, napr.
ifrovacie moduly a bezpen zariadenia na vytvranie elektronickch podpisov. Pri rozhodovan
o kpe nejakho certifikovanho produktu je vak popri rovni zruk (EAL) potrebn preskma
aj protection profile, oproti ktormu bol produkt certifikovan, aby sa nestalo, e produkt m sce
vysok rove zruk, ale jeho funkcionalita bola obmedzen do takej miery, e nemus by
pouiten pre potreby organizcie. Podrobnejie o certifikcii systmov poda Common Criteria
pojednva kapitola 3.
Common Criteria nerieia bezpenostn aspekty prevdzky certifikovanho systmu. Klad poiadavky na bezpenostn prostredie systmu, ale neuvdzaj bezpenostn funkcie (opatrenia),
pomocou ktorch je tieto poiadavky mon naplni. Manamentom IB sa zaoberaj u
spomnan normy radu ISO/IEC 270xx. Ak m organizcia zaveden ISMS v slade s normou
ISO/IEC 27001, me si ho necha oproti tejto norme certifikova. Norma ISO/IEC 27007 sa
zaober auditom ISMS a obsahuje aj zoznam otzok na certifikan audit ISMS poda ISO/IEC
27001.
Organizcia neraz potrebuje vyui sluby externch pecialistov na IB. Informan bezpenos
na Slovensku zatia nie je samostatnm vednm ani tudijnm odborom a na slovenskch
vysokch kolch zatia 50 nie s tudijn programy, ktor by pripravovali pecialistov v
informanej bezpenosti. (v zahrani napr. Nemecko, Vek Britnia, USA a i. u existuj
vysokokolsk tudijn programy a systm postgradulneho tdia IB, ale odbornkov na
informan bezpenos je aj tam mlo). Postgradulny systm v minimalistickej forme (prax v
IB a individulna prprava na zklade poskytnutch materilov a skka v podobe testu) existuje
aj na Slovensku, kde sa takto d zska medzinrodne uznvan kvalifikcia v informanej
bezpenosti zloenm skok na CISA (certifikovan audtor informanch systmov), CISM
(certifikovan manar informanej bezpenosti), CGEIT. Tieto tri certifikty vystavuje ISACA
Medzinrodn asocicia pre audit informanch systmov. In certifikty (ako napr. CISSP) sa
daj zska v zahrani. Hoci titul ete nemus garantova potrebn odborn kvalifikciu, ak
organizcia potrebuje vykona bezpenostn audit, mala by hada certifikovanho auditora
informanch systmov, CISA. Manar IB by mal ma znalosti zodpovedajce CISM, vo
vekch organizcich by sa uplatnil lovek so znalosami CGEIT. Ete raz pripomname, e
zskanm certifiktu sa lovek nestva odbornkom v danej oblasti, certifikt potvrdzuje, e na to
m potrebn prax a vedomosti.
Zhrnutie. Certifikcia je formlne potvrdenie toho, e predmet certifikcie spa certifikan
kritri. Technick systmy sa najastejie certifikuj vzhadom na rozsah bezpenostnch
funkci a ich rove poda kritri odvodench z normy ISO/IEC 15408. Systmy manamentu
IB sa certifikuj oproti norme ISO/IEC 27001. Odborn kvalifikciu v informanej bezpenosti
je mon formlne preukza zskanm niektorho z certifiktov CISA, CISM, CISSP, CGEIT a
inch.
50
k 9.12.2013
39
2.13 Literatra
[1]
ISO/IEC 27000 Information technology Security techniques Information security

management systems Overview and vocabulary
[2]
ISO/IEC 27001:2005, Information technology -- Security techniques -- Information

security management systems -- Requirements
[3]
ISO/IEC 27002 Information technology Security techniques Code of practice for

information security controls
[4]

management system implementation guidance
[5]
ISO/IEC 27005 Information technology Security techniques Information security risk

management
[6]
ISO/IEC 27008 Security techniques -- Guidelines for auditors on information security

management systems controls
[7]
BSI Standard 100-1 Information Security Management Systems (ISMS), v.1.0.

Bundesamt fr Sicherheit in der Informationstechnik, Bonn, 2005
[8]
BSI Standard 100-2 IT-Grundschutz Methodology, v.1.0. Bundesamt fr Sicherheit in

der Informationstechnik, Bonn, 2005
[9]
BSI Standard 100-3 Risk Analysis based on IT-Grundschutz, v.2.0. Bundesamt fr

Sicherheit in der Informationstechnik, Bonn, 2005
[10] Threats catalogue - Elementary

threats, https://www.bsi.bund.de/SharedDocs/Downloads/
EN/BSI/Grundschutz/download/threats_catalogue.pdf?__blob=publicationFile
[11] H.F.Tipton, M.Krause, (eds.) Information Security Management Handbook, 5-th edition,
Auerbach publications, CRS Press Company, New York, 2004
[12] FIPS 199 Standards for Security Categorization of Federal Information and Information
Systems, U.S. Department of commerce & NIST, 2003
[13]
FIPS 200 Minimum Security Requirements for Federal Information and Information
Systems, U.S. Department of commerce & NIST, 2006
[14] NIST Special Publication 800-30, Risk Management Guide for Information Technology
Systems. Recommendations of the National Institute of Standards and Technology
[15] NIST Special Publication 800-34, Revision 1, Contingency Planning Guide For Federal
Information Systems
[16] NIST Special Publication 800-37 Guide for Applying the Risk Management Framework
to Federal Information Systems A Security Life Cycle Approach
[17]
NIST Special Publication 800-53 Recommended Security Controls for Federal

Information Systems
[18] NIST Special Publication 800-53A, Techniques and Procedures for Verifying the
Effectiveness of Security Controls in Information Systems (Initial public draft), 2004;
[19] NIST Special Publication 800-60, Volume I: Guide for Mapping Types of Information
and Information Systems to Security Categories
[20] Common Vulnerabilities and Exposures (CVE) http://cve.mitre.org/
[21]
40
Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o tandardoch pre

informan systmy verejnej sprvy.
[22]
41
Zkon . 211/2000 Z. z. o slobodnom prstupe k informcim a o zmene a doplnen

niektorch zkonov (Zkon o slobode informci)
2.14 Prloha. Katalg elementrnych hrozieb

Zoznam hrozieb bol prevzat zo Spolkovho radu pre informan bezpenos, BSI.
A oznauje Availability (dostupnos), C Confidentiality (dvernos), I Integrity (integritu).
Hrozba
Vplva na
Poiar
I,A
Nepriazniv klimatick podmienky
I,A
Voda
I,A
zneistenie, prach. korzia
I,A
Prrodn katastrofy
Katastrofy ivotnho prostredia
vek udalosti v prostred/okol (demontrcie, nepokoje)
C,I,A
zlyhanie alebo preruenie dodvky energie
I,A
zlyhanie alebo preruenie komunikanch siet
I,A
10
zlyhanie alebo pokodenie zdrojov energie
11
zlyhanie alebo preruenie poskytovania sluieb
C,I,A
12
interferujca radicia
I,A
13
zachytenie kompromitujceho vyarovania
14
zachytenie informcie/pion
15
odpovanie
16
krde zariaden, pamovch mdi alebo dokumentov
C,A
17
strata zariaden, pamovch mdi alebo dokumentov
C,A
18
zl plnovanie alebo nedostatok adaptcie
C,I,A
19
prezradenie citlivej informcie
20
informcie z nespoahlivho zdroja
C,I,A
21
manipulcia s hw a sw
C,I,A
22
manipulcia s informciou
23
neoprvnen prstup k IKT systmom
C,I,A
24
znienie zariaden alebo pamovch mdi
25
zlyhanie zariaden alebo systmov
C,I,A
26
nesprvne fungovanie zariaden alebo systmov
C,I,A
27
nedostatok zdrojov
28
zranitenosti alebo chyby sw
C,I,A
29
poruenie zkonov alebo predpisov
C,I,A
30
neoprvnen pouvanie alebo sprva zariaden a systmov
C,I,A
42
31
nesprvne pouvanie alebo sprva zariaden a systmov
C,I,A
32
zneuitie oprvnen
C,I,A
33
absencia personlu
34
tok
C,I,A
35
printenie, vydieranie, korupcia
C,I,A
36
krde identity
C,I,A
37
popretie innosti
C,I
38
zneuitie osobnch dajov
39
kodliv sw
C,I,A
40
odmietnutie sluby
41
sabot
42
socilne ininierstvo
C,I
43
opakovan posielanie sprv
C,I
44
neoprvnen vstup do priestorov
C,I,A
45
strata dajov
46
strata integrity citlivej informcie
2.15 Prloha. Zoznam zranitenost

V tejto asti je uveden zoznam zranitenost prevzat z normy [5] doplnen o zranitenosti
uveden v dokumentoch [10] a [14]. Podrobn zoznam zranitenost mono njs v [20]. Pre
kad zranitenos s na ilustrciu uveden hrozby (hrozba), ktor mu dan zranitenos
vyui. pln zoznam hrozieb schopnch vyui uveden zranitenosti je vo vine prpadov
podstatne rozsiahlej.
Prostredie a infratruktra
Zranitenos
Hrozba
Z.1.1
nedostaton fyzick ochrana budov, dver, neoprvnen prstup, krde

okien
Z.1.2
zanedbanie alebo nedostaton rove neoprvnen

prstup,
fyzickho riadenia prstupu do budovy alebo zmern pokodenie, krde
miestnost
Z.1.3
nestabiln elektrick sie
Z.1.4
umiestnenie
zplavami
v oblastiach
vpadok zdrojov energie

ohrozench zplava
Hardvr
Z.2.1
neexistuje harmonogram periodickej vmeny
zhorovanie
pamovch mdi
Z.2.2
citlivos na kolsanie naptia
vpadok naptia, preptie,

kolsanie naptia
Z.2.3
citlivos na vkyvy teplt
teplotn extrmy
43
kvality
Z.2.4
citlivos na vlhkos, pranos, zneistenie
nadmern pranos (vietor,

stavebn prce)
Z.2.5
citlivos na elektromagnetick iarenie
elektromagnetick iarenie
Z.2.6
nedostaton drba alebo chybn intalcia chyba drby, nedostatok

pamovch mdi
pamovch
kapact,
nedostupnos zdrojov
Z.2.7
chba efektvne riadenie zmien konfigurcie
chyba obsluhy
Programov vybavenie (softvr)

Z.3.1.
nejasn alebo nepln pecifikcia pre chyba obsluhy

vvojrov
Z.3.2.
iadne alebo nedostaton

programovho vybavenia
Z.3.3.
komplikovan pouvatesk rozhranie
Z.3.4.
chbajce alebo nedostaton mechanizmy predstieranie cudzej identity

pre identifikciu a autentizaciu
Z.3.5.
nedostaton alebo chbajci zznam auditu
Z.3.6.
veobecne
vybavenia
Z.3.7.
nechrnen tabuky hesiel
Z.3.8.
slab manament hesiel (slab hesl, predstieranie cudzej identity

ukladanie neifrovanch hesiel, rovnak
hesl pre rozlin ely, nedostatone as
menenie hesiel)
Z.3.9.
nesprvne pridelenie prstupovch prv
Z.3.10.
nekontrolovan
softvru
Z.3.11.
opustenie pracovnej stanice bez odhlsenia
pouitie
softvru
neoprvnenm spsobom
Z.3.12.
chba efektvne riadenie zmien
zlyhanie softvru
Z.3.13.
nedostaton alebo chbajca dokumentcia
chyba obsluhy
Z.3.14.
chbaj
zlon
kpie
programovho vybavenia)
(dajov, zlomysen softvr, poiar
Z.3.15.
vyradenie alebo optovn

pamovch
mdi
bez
vymazania dajov
pouvanie pouitie
softvru
poriadneho neoprvnenm spsobom,
Z.3.16.
znme
vady
testovanie zlyhanie softvru

chyba obsluhy
pouitie
softvru
neoprvnenm spsobom
programovho pouitie
softvru
neoprvnenm spsobom
sahovanie
predstieranie cudzej identity
pouitie
softvru
neoprvnenm spsobom
a pouvanie zlomysen softvr
povolen nepotrebn sluba
nik
dajov
(naruenie
dvernosti dajov)
pouitie
softvru
neoprvnenm spsobom,
neoprvnen
systmu
44
prstup
do
Z.3.17.
nedokonen alebo nov softvr
nepln alebo neprimeran

testovanie
Z.3.18
iroko distribuovan softvr
strata integrity
distribcie
sw
Z.4.1.
nechrnen komunikan linky
odpovanie,
linky
preruenie
Z.4.2.
zl prepojenie kblov
infiltrcia komunikcie
Z.4.3.
nedostatky
prjemcu
Z.4.4.
prenos hesiel v otvorenej forme
Z.4.5.
nedostaton/chbajce potvrdenie zaslatia popretie

alebo prijatia sprvy
prijatia
Z.4.6.
pouvanie modemov (dial up)
prstup
neoprvnenho
pouvatea do systmu/siete
Z.4.7.
nechrnen prenos citlivch sprv
odpovanie
Z.4.8.
neadekvtna sprva siete (routing)
preaenie siete
Z.4.9.
nechrnen pripojenie k verejnej sieti
pouitie
softvru
neoprvnenm spsobom
Z.4.10.
nedostatone bezpen architektra siete
prienik do siete
Z.5.1.
nechrnen loisko
krde, naruenie dvernosti
Z.5.2.
nedostaton starostlivos pri vyraovan krde, naruenie dvernosti

dokumentov
Z.5.3.
nekontrolovan koprovanie
naruenie dvernosti krde
Z.6.1.
absencia personlu
nedostatok personlu,
Z.6.2.
prca
externch
pracovnkov
alebo krde, neoprvnen prstup
upratovavacieho personlu bez dohadu
do systmu
Z.6.3.
nedostaton bezpenostn trning
chyba obslunho personlu
Z.6.4.
nedostaton bezpenostn povedomie
chyby pouvateov
Z.6.5.
nesprvne pouitie sw alebo hw
chyba obslunho personlu
Z.6.6.
nedostaton alebo chbajce monitorovacie pouitie sw neoprvnenm

mechanizmy
spsobom
Z.6.7.
nedostaton alebo chbajce politiky pouitie

siet
upravujce
korektn
pouvanie neautorizovanm spsobom
telekomunikanch prostriedkov a vmeny
sprv
Z.6.8.
nedostaton
pracovnkov
poas
Komunikcia
v identifikcii
odosielatea
a predstieranie cudzej identity

prstup
k sieti
pre
neoprvneneho pouvatea
pvodu
alebo
Dokumenty
Personl
45
procedry
pri
zskavan myseln
pokodenie
systmu, chyba obsluhy
Procedurlne zranitenosti
Z.7.1
chybajca autorizcia
spracovanie informcie
Z.7.2
nedostaton formlny proces schvaovania vstup pokodench dajov

verejne dostupnej informcie
Z.7.3
chbajci
formlny
prstupovch prv
Z.7.4
chba politika o pouvan mobilnch krde, neoprvnen prstup

potaov a podobnch zariaden
do systmu
Z.7.5
chbaj formlne procedry riadenia ISMS vstup pokodench dajov

dokumentcie
Z.7.6
chbaj
formlne
procedry vstup pokodench dajov
kontroly/sledovania zznamov ISMS
Z.7.7
chbaj formlne procedry registrovania neoprvnen prstup

a odregistrovania pouvateov
Z.7.8
chba kontrola aktv umiestnench mimo krde

budovy
Z.7.9
chba dohoda o rovni sluieb (Service chyba drby

Level Agreement)
Z.7.10
chba politika
obrazovky
Z.7.11
chbajce alebo nedostaton ustanovenia neoprvnen prstup, chyba

v zmluvch so zkaznkmi alebo tretmi drby, chyba sw
stranami
Z.7.12
chbajce alebo nedostaton ustanovenia podvod, krde

o bezpenosti v zmluvch so zamestnancami
Z.7.13
chbaj plny kontinuity innosti
Z.7.14
chba nleit vymedzenie zodpovednosti za odmietnutie zodpovednosti

informan bezpenos
Z.7.15
chba politika pre pouvanie elektronickej nik citlivej informcie,

poty
nesprvne smerovanie sprv
Z.7.16
chbaj
procedry
a ohodnotenia/odhadu rizika
Z.7.17
chbaj
procedry
pre
s klasifikovanou informciou
Z.7.18
chbaj procedry upravujce narbanie krde informcie, prvny

s informciami, na ktor sa vzahuje ochrana postih
duevnho vlastnctva
Z.7.19
chbaj
procedry
bezpenostnch slabn
Z.7.20
chbaj procedry
beiacich systmov
46
prostriedkov
proces
istho
na
na myseln
systmu
pokodenie
revzie neoprvnen prstup
stola
a istej krde
neoprvnen
k systmu,
dvernosti
informcie,
prstup
naruenie
technick zlyhanie
identifikcie neoprvnen
systmu
prstup
narbanie chyba pouvatea,

citlivch informci
k
nik
oznamovanie pouvanie systmu a siet

neoprvnencm spsobom
zavdzania
sw
do chyba obsluhy
Z.7.21
chba procedra riadenia zmien
Z.7.22
chba
procedra
prostriedkov/zariaden
informcie
na
chyba drby
monitorovania neoprvnen prstup

spracovanie
Z.7.23
nerob sa pravideln audit (dohad, kontrola)
Z.7.24
nerobia sa pravideln revzie manamentu zneuitie zdrojov

(systmu)
Z.7.25
nie je zaveden monitorovac mechanizmus myseln

pre naruenia bezpenosti
systmu
Z.7.26
chba
stanovenie
zodpovednosti
za chyby pouvateov
informan bezpenos v pracovnej nplni
Z.7.27
hlsenia o zvadch nie s zaznamenan chyba obsluhy

v logoch administrtora a opertora
Z.7.28
nie je definovan disciplinrny proces pre krde

informce,
prpad bezpenostnho incidentu
neoprvnen
prstup,
pouvanie sw neoprvnenm
spsobom
neoprvnen prstup
pokodenie
Zranitenosti v aplikcich
omyl pouvatea
Z.8.1
nesprvne nastavenie parametrov
Z.8.2
pouitie aplikanch programov na chybn nedostupnos dajov

daje (napr. neaktulne)
Z.8.3
neschopnos vytvori prevdzkov sprvy
neoprvnen prstup
Z.8.4
nesprvne daje
omyl pouvatea
Veobecn zranitenosti
Z.9.1.
single point of failure (zke miesto, alebo zlyhanie systmu, myseln

kritick prvok systmu)
pokodenie
Z.9.2.
nedostaton drba
zlyhanie hw, sw
2.16 Prloha. Obsah bezpenostnej politiky

V bezpenostnej politike organizcie (vydanej vedenm organizcie) mus by stanoven zvzn
zkladn rmec pre informan bezpenos organizcie. Poda ISO normy [3] bezpenostn
politika by mala povinne obsahova (resp. rmcovo upravova):
47
deklarciu vedenia organizcie o vzname ochrany informcie, identifikcii hlavnch

aktv a stanoven cieov informanej bezpenosti v organizcii a podpore vedenia
organizcie pri ich napan,
vymedzenie oblasti pouitenosti danej bezpenostnej politiky (z oho bezpenostn
politika vychdza a na o vetko sa vzahuje),
truktru bezpenostnch dokumentov nadvzujcich na dan bezpenostn politiku
a ich obsah (pecilne bezpenostn politiky, alebo bezpenostn tandardy,
bezpenostn praktiky ak oblasti pokrvaj a akou formou bud vydan)
stanovenie zodpovednosti zamestnancov organizcie za presadzovanie a dodriavanie
bezpenostnej politiky (a dokumentov na u nadvzujcich),
klasifikciu informcie (na zklade oho sa bude informcia v organizcii klasifikova)
spsob analzy rizk a hranica akceptovatenho rizika,

monitoring, kontrola, audit IKS,
rieenie bezpenostnch incidentov,
zaistenie kontinuity innosti IKS organizcie,
sprva bezpenostnej politiky (ako asto sa bud robi pravideln a z akch dvodov
mimoriadne revzie bezpenostnej politiky).
Ak by bezpenostn politika mala by podrobnejia, mala by stanovi aj zsady pre
riadenie prstupu (k dajom a slubm IKS organizcie),

dosledovatenos (accountability) pre ak innosti,
zznamy auditu (o om sa bud vytvra, kto a ako ich bude spracovva),
outsourcing sluieb svisiacich s vvojom a prevdzkou IKS,
vvoj softvru a obstarvanm IKT,
zlohovanie dajov a softvru (o a ako asto),
kontinuitu innosti (Business continuity planning) identifikcia systmov kritickch
pre organizciu a povinnos vypracova a implementova havarijn plny,
vyraovanie pamovch mdi,
likvidcia papierovch dokumentov,
prstup na Internet a pouvanie elektronickej poty,
vlastnctvo informci komu patria jednotliv daje, prva a povinnosti z toho
vyplvajce,
vynanie IKT zariaden mimo priestorov (opravy),
pouvanie prenosnch zariaden a prca na diaku,
ochranu pred kodlivm softvrom,
ifrov ochrana informcie,
bezpenos pracovnch stanc (minimlna poadovan rove),
ochranu skromia
disciplinrne pokraovanie v prpade poruenia pravidiel stanovench bezpenostnou
politikou,
dosiahnutie/udriavanie sladu s legislatvou (najm v prpade medzinrodnch
organizci, psobiacich v prostred s rozdielnou legislatvou)
prpadne in, ktor organizcia povauje za potrebn.
2.17 Prloha. Klasifikcia informcie a systmov

Klasifikcia informcie a systmov umouje zjednodui manament informanej bezpenosti
v organizcii tm, e namiesto toho, aby sa kad prpad (daj, resp. systm) posudzoval a jeho
ochrana rieila zvl, definuj sa klasifikan kritri, na zklade ktorch je mon rozdeli
daje do (bezpenostnch) tried s rovnakmi bezpenostnmi potrebami. Existuj katalgy
tandardnch bezpenostnch opatren (v Nemecku tzv. Grundschutzbuch BSI) a pre jednotliv
triedy s stanoven sbory tandardnch bezpenostnch opatren, garantujcich poadovan
rove ochrany dajov 51. (Klasifikcia systmov je odvoden od klasifikcie dajov, ktor sa
v nich spracovvaj.) Stanovenie bezpenostnch opatren pre daje sa potom rob tak, e sa
informcia poda klasifikanch kritri zarad do niektorej triedy a na jej ochranu sa pouij
opatrenia zodpovedajce danej triede. (Ak by na daje boli kladen pecilne bezpenostn
poiadavky z hadiska obsahu alebo rovne ochrany, na ktor nestaia takto konfekn
bezpenostn rieenia, bude potrebn spravi analzu rizk, vybra a poui vhodn opatrenia na
ochranu dajov s netandardnmi bezpenostnmi potrebami zvl. V nemeckom tandarde [9]
sa uvdza, e katalgov rieenia poda metodiky tandardu [8] pokrvaj 80% prpadov.)
v Nemecku spomnan BSI Grundschutzbuch [8], v USA poiadavky na ochranu ttnych informanch
systmov (obdoba ISVS) [13], [17], a na Slovensku bezpenostn tandardy uveden vo Vnose MF SR
[21]
51
48
Pozrieme sa na klasifikciu dajov/informcie a systmov podrobnejie. Budeme vychdza

z americkch [12,13] ale na zver ukeme, e navrhovan rieenia s zoveobecnenm
klasickch klasifikanch schm.
Poiadavky na ochranu dajov sa v konenom dsledku redukuj na zkladn bezpenostn
poiadavky (dvernos, integrita, dostupnos, autentickos, skromie a i.) alebo nejak ich
kombinciu. Vyberieme tri zkladn bezpenostn poiadavky 52 dvernos, integrita
a dostupnos a pre kad z nich stanovme 4 hierarchicky klasifikan stupne, vychdzajc
z hodnoty dopadu 53 v dsledku naruenia prslunej bezpenostnej poiadavky (vysvetlme to na
prklade dvernosti, pre integritu a dostupnos budeme postupova rovnako):
NA (nepouiten) ak sa poiadavka na dvernos ned na daje aplikova,
nzky ak je dopad naruenia dvernosti dajov nzky,
stredn ak je dopad naruenia dvernosti dajov stredn,
vysok ak je dopad naruenia dvernosti dajov vysok.
1.
2.
3.
4.
rove dopadu sa vyjadruje rovnako, ako pri analze rizk. Pre kad z klasifikanch stupov
vyberieme (existuj tandardne preddefinovan sbory, ktor meme prebra bez zmeny, alebo
upravi poda potreby) sbor bezpenostnch opatren primeran klasifikanmu stupu. Takto
vznikn po tri sbory bezpenostnch opatren pre dvernos, integritu a dostupnos. (Pre stupe
NA nie s predpsan iadne opatrenia). Klasifikciu dajov budeme robi nasledovne:
Kee je pravdepodobn, e daje, ktor sa pouvaj v rovnakom prostred na podobn el,
bud ma aj podobn bezpenostn poiadavky, budeme klasifikova typy dajov, ktor maj
podobn charakter (osobn daje, zdravotn daje, ekonomick daje, programy, konfiguran
parametre, kryptografick ke, hesl, autentizan daje a pod.). Tento prstup nevyluuje
monos dodatonej klasifikcie konkrtnych dajov, ktor sa nepodarilo zaradi do iadneho
typu. Kadmu typu informcie/dajov priraujeme trojicu [12]
SCtyp informcie = ((dvernos, dopad), (integrita, dopad), (dostupnos, dopad))
kde SC oznauje security category, bezpenostn kategriu 54 a hodnota dopadu je prvok mnoiny
{nzka, stredn, vysok, alebo NA (nepouiten)}. Pre lepie pochopenie oznaenia uvedieme
niekoko prkladov. Uvaujme informciu, ktor organizcia vystavuje na svojej webovej
strnke. Takto informciu ozname ako verejn informciu a priradme jej ohodnotenie:
SCverejn informcia = ((dvernos, NA), (integrita, stredn), (dostupnos, stredn)).
Pre zdravotn informciu (zdravotn dokumentcia pacienta)
SCzdravotn informcia = ((dvernos, vysok), (integrita, vysok), (dostupnos, stredn)).
Systm klasifikujeme na zklade klasifikcie vetkch typov informcie, ktor sa v om
spracovvaj. Taktie mu priraujeme trojzlokov vektor:
SCinforman systm = ((dvernos, dopad), (integrita, dopad), (dostupnos, dopad)),
kde sa ako hodnota dopadu pre dvernos systmu berie maximum z hodnt dopadu pre
dvernos jednotlivch typov informci, ktor sa v om spracovvaj. Podobne pre vpoet
rovne hodnt integrity a dostupnosti. Na rozdiel od klasifikcie dajov sa hodnota NA pri
klasifikcii systmov nepouva a namiesto nej sa pouva hodnota nzka. Ak sa v systme
52
dvody uvedieme neskr

bolo by logickejie, keby sme vychdzali z rovne rizika, ale nepoznme pravdepodobnos naplnenia
jednotlivch hrozieb, ani rove akceptovatenho rizika. To s parametre, ktor bude mon zohadni
pri klasifikcii dajov a systmov v konkrtnej organizcii
54
aby sme odlili klasifikciu na zklade jednho a viacerch klasifikanch kritri. Bezpenostn trieda
je pecilnym prpadom veobecnejej bezpenostnej kategrie.
53
49
spracovva zdravotn a verejn informcia s ohodnotenm poda predchdzajceho prkladu, tak

jeho bezpenostn klasifikcia bude 55
SCinforman systm = ((dvernos, vysok), (integrita, vysok), (dostupnos, stredn)).
Poznmky.
1. Hoci existuje viacero bezpenostnch poiadaviek, najastejie sa na klasifikciu informcie
pouva tradine dvernos. Informan bezpenos sa vak definuje ako dosiahnutie
potrebnej rovne dvernosti, integrity a dostupnosti dajov (IKT a sluieb). Pri analze rizk
sa zohaduj aj in bezpenostn poiadavky (nepopretie prijatia, pvodu, skromnos,
dosledovatenos, anonymita, pseudonymita, a i.) a to znamen, e daje je potrebn skma
(klasifikova) aj z hadiska inch bezpenostnch poiadaviek, ako je dvernos. Keby sa
vak daje/informcia klasifikovali poda viacerch bezpenostnch poiadaviek, vznikli by
dva problmy:
a) niektor bezpenostn poiadavky s protireiv (dosledovatenos a anonymita),
medzi inmi s siln vzby (autentickos a integrita), o by bolo potrebn pri nvrhu
klasifikcie jednoznane vyriei.
b) u pri troch bezpenostnch poiadavkch a tyroch rovniach dopadu dostvame
43= 64 monch kombinci hodnt. Pri n bezpenostnch poiadavkch a tyroch
rovniach dopadu mme 4n monch kombinci, ktor by vzhadom na mon
vzahy medzi jednotlivmi poiadavkami bolo treba riei jednotlivo. Takto
klasifikan schma by vak bola obrovsk a prakticky nepouiten.
Obmedzenie mnoiny bezpenostnch poiadaviek pouitch na klasifikciu na tri (trojica CIA:
confidentiality, integrity, availability) m niekoko dvodov:
a) snaha obmedzi poet tried a vekos klasifikanej schmy (hoci aj 64 tried sa me
zda vea),
b) relatvna nezvislos 56 dvernosti, integrity a dostupnosti, ktor umouje pre
jednotliv stupne ochrany napr. dvernosti stanovi poadovan rove zruk
nezvisle od ostatnch bezpenostnch poiadaviek. To znamen, e bude potrebn
vypracova poiadavky na opatrenia, ktor zaruia dostaton ochranu dvernosti
informcie v prpade, ke je dopad naruenia jej dvernosti nzky, stredn a vysok.
Podobne pre integritu a dostupnos. Vaka relatvnej nezvislosti dvernosti,
integrity a dostupnosti sta vypracova 9 sborov poiadaviek na opatrenia,
namiesto 64, o je ete zvldnuten.
2. Ak nesta kategorizcia poda typu dajov (napr. v prpade utajovanch skutonost), je
mon rozdeli kategriu dajov na podkategrie (v prpade utajovanch skutonost na
vyhraden, dvern, tajn a prsne tajn) a stanovi rove bezpenostnch poiadaviek pre
tieto podkategrie.
3. Americk tandard [12] chpe integritu irie, ako sme ju definovali my v vodnej asti. Z
pragmatickch dvodov zaha do integrity aj autentickos a nepopretie pvodu. Tto
defincia je trocha nekonzistentn (d sa poui pre daje, ale nie pre fyzick systmy), ale
pri tdiu americkch noriem treba ma na pamti tento rozdiel.
4. Vektorov ohodnotenie bezpenostnej kategrie typu informcie je v prpade potreby mon
nahradi skalrnym, t.j. jednou hodnotou. Ostatn hodnoty sa nastavia na NA. To umouje
vyjadri existujce klasifikan schmy postaven na jednom kritriu (bezpenostnej
poiadavke) pomocou vektorovej klasifikanej schmy. Na druhej strane, vektor (dvernos,
integrita, dostupnos) je mon rozri o alie zloky. Ak by sme naprklad chceli
55
v tomto prpade m vo vetkch troch zlokch zdravotn informcia rovnak, alebo vyie nroky na
ochranu ako verejn informcia a uruje bezpenostn klasifikciu systmu
56
je zrejm, e zvislos v tride CIA existuje; opatrenia na zaistenie dvernosti, kontroly integrity mu
ma negatvny vplyv na dostupnos
50
rozliova integritu a autentickos, ale zaradi autentickos medzi klasifikan kritri,

dajom a systmom budeme priraova tvoricu hodnt (dvernos, integrita, dostupnos,
autentickos) na kle NA, nzka, stredn, vysok.
51
2.18 Znalostn tandardy pre oblas IB

2.18.1 Zkladn oblasti znalost informanej bezpenosti
Zkladn oblasti znalost informanej bezpenosti s
1
2
3
4
5
6
7
8
9
10
Legislatva a tandardy IB
Riadenie IB
Riadenie rizk 57
Obstarvanie, vvoj a zmeny IKT systmov
Fyzick bezpenos
Riadenie prstupu
Bezpenos komunikcie
Sprva bezpenostnch incidentov
Prevdzka IKT systmov a kontinuita innosti
Audit informanej bezpenosti
2.18.2 Kategrie a roly pouvateov ISVS

Pouvatelia ISVS s rozdelen do kategri poda lohy, ktor voi ISVS plnia a znalostnch
potrieb z IB, ktor na plnenie svojich povinnost potrebuj. Kategrie s v prpade potreby
rozdelen na roly. Zkladn kategrie a roly pouvateov ISVS s
1. laici,
2.
3.
4.
5.
1.1. neprivilegovan pouvate

manari a vedci pracovnci
2.1. vedci pracovnk/zamestnanec
informatici nepecialisti v IB
3.1. Manar IT
3.2. sprvca IKT systmov
pecialisti v IB
4.1. manar IB
4.2. opertor bezpenostnch technolgi
4.3. audtor bezpenosti IKT systmov
4.4. bezpenostn analytik
uitelia IB
5.1. lektor IB
rozumej sa bezpenostn rizik vyplvajce z hrozieb voi aktvam IKT ako s naprklad procesy
organizcie zabezpeovan alebo podporovan IKT, hardvr, softvr, daje, podporn sluby, personl,
at.
57
52
2.18.3 Charakteristika kategri a rol pouvateov ISVS a minimlne znalostn

poiadavky pre jednotliv roly
2.18.3.1 Laici
Laici s udia bez systematickho informatickho vzdelania, ktor pouvaj IKT systmy
a najm aplikcie ako nstroje na plnenie svojich pracovnch loh, ale v IKT systme maj
zvyajne minimlne oprvnenia, postaujce na plnenie ich zkladnch pracovnch povinnost
(maj prvo vyuva vybran aplikcie, daje, ale nemaj oprvnenie napr. intalova softvr,
meni konfigurciu systmu a pod.) V organizcich verejnej sprvy laici s zaraden do roly
neprivilegovanch pouvateov.
Rola: Neprivilegovan pouvate
Charakteristika roly. V organizcich je spravidla pouvateom IKT systmov, pouva ich
na plnenie svojich pracovnch povinnost, priom prstup do IKT systmov a k ich dajom m
obmedzen na konkrtne opercie v slade s definovanmi oprvneniami. Neprivilegovan
pouvate IKT systmov spravidla nem oprvnenie zasahova do ich konfigurcie, intalova
programy a pod.
Znalostn tandard
Zklady IB
Pozn zkladn pojmy IB.
53
Legislatva a tandardy IB
M zkladn prvnu orientciu v informanej bezpenosti (trestn zkon, autorsk
zkon, zkon o ochrane osobnch dajov, zkon o utajovanch skutonostiach a pod.).
Pozn prvne poiadavky na pouvanie IKT systmov organizcie a etick zsady
sprvania sa v digitlnom priestore.
Doke identifikova daje v IKT systmoch s ktormi pracuje a ktor vyaduj
osobitn ochranu vyplvajcu z prvnych poiadaviek.
Riadenie IB
Pozn v primeranej miere pecifick pravidl vlastnej organizcie naprklad
bezpenostn politiku, tandardy, pouit bezpenostn opatrenia, konkrtne postupy
pri nahlasovan a rieen bezpenostnch incidentov, havarijn plny a pod.
Riadenie rizk bez pecifickch poiadaviek v tejto oblasti
je schopn vyjadri stanovisko k pouvateskej prijatenosti (akceptovatenosti)
obstarvanch, vyvjanch alebo zmenench IKT systmov.
Fyzick bezpenos
Pozn zsady fyzickej bezpenosti.
Doke v praxi uplatova konkrtne pravidl fyzickej bezpenosti organizcie.
Riadenie prstupu
Pozn rzne prostriedky autentizcie (hesl, PIN kdy, tokeny, biometria), vie ich
pouva, pozn zsady ochrany autentizanch prostriedkov.
Pozn zkladn techniky socilneho ininierstva, vie ich identifikova a sprvne na ne
reagova (prezrdzanie hesiel, phishing a pod.).
Bezpenos komunikcie
Pozn zkladn poiadavky na ochranu potaov a inch zariaden v sieti.
Rozumie rizikm prce na Internete, ich dsledkom a osvojil si zsady bezpenej

prce na Internete: elektronick pota (spam, prlohy a pod.), renie infiltrci
(potaov vrusy, malware, spyware a pod.), potaov pirtstvo (sahovanie
neleglneho obsahu).
Doke vhodne reagova a kona v slade s postupmi definovanmi pre bezpenostn
incidenty, ako aj primerane reagova na bezpenostn a in upozornenia IKT
systmov (aplikci, operanho systmu, antivrusovho programu a pod.).
Rozumie zkladnm typom a mechanizmom bezpenostnch opatren v IKT
systmoch.
Pozn vznam, spsob zlohovania a obnovy vlastnch sborov.
Audit
Pozn vznam auditu,
Je schopn vyjadri sa k pouvateskej prijatenosti nm pouvanch IKT systmov
a jeho sa tkajcich bezpenostnch opatren
2.18.3.2 Manari a vedci zamestnanci 58 organizcie

Manari a vedci zamestnanci (s vnimkou manarov IT) s z hadiska informatickch
a informano-bezpenostnch znalost pecilnou podkategriou laikov. Na jednej strane
spravidla nemaj systematick vedomosti o IKT, na druhej strane zodpovedaj za ochranu aktv
organizcie, ktor s v ich psobnosti. Zrove rozhoduj o bezpenostnej politike organizcie
(bez ohadu na to, i je explicitne formulovan), prostriedkoch na jej realizciu, riaden IB a pod.
Manari a vedci zamestnanci s asto zodpovedn za naplnenie legislatvnych poiadaviek na
IB v organizcii (napr. poiadavky svisiace s ochranou osobnch dajov, utajovanch
skutonost, ochranou kritickej infratruktry a pod.). V organizcich verejnej sprvy manari
a vedci zamestnanci s zaraden do spolonej roly vedcich zamestnancov
Rola: Vedci zamestnanec

Charakteristika roly. Zamestnanec vo vedcej pozcii, ktor nie je manarom IT alebo
manarom bezpenosti IKT. Spravidla zodpoved za organizciu ako celok (alebo za jej
vznamn as), v konenom dsledku zodpoved aj za plnenie loh v oblasti IB vo vntri
organizcie.
Znalostn tandard
Zklady IB
Ovlda znalosti a zrunosti poadovan znalostnm tandardom pre laikov vo vetkch
oblastiach. Tento tandard uvdza preto len poiadavky, ktor s navye.
1. Legislatva a tandardy IB
1.1. Vie o existencii a nplni tandardov upravujcich jednotliv oblasti IB (rad ISO
2700x, tandardy ISVS a pod.).
1.2. Pozn legislatvu relevantn pre informan systmy a spracvan daje vo vlastnej
organizcii (zkon o ochrane osobnch dajov 59 , zkon o ochrane utajovanch
Tento tandard zarauje vedcich zamestnancov a manarov, ktor nemaj bezprostredn vzah k
prevdzke a ochrane IKT do spolonej roly vedcich zamestnancov a zvl definuje roly a znalostn
poiadavky pre manarov IT a manarov bezpenosti IKT (skrtene manarov IB).
59
Zkon . 122/2013 Z.z. o ochrane osobnch dajov a o zmene a doplnen niektorch zkonov
58
54
2.
3.
4.
5.
6.
7.
8.
9.
10.
skutonost 60 , zkon o ISVS 61 , zkon o elektronickom podpise 62 , zkon o

elektronickch komunikcich 63 a pod.) ako aj povinnosti, ktor pre organizciu
v ktorej psob, z tejto legislatvy vyplvaj.
Riadenie IB
2.1. Vie identifikova hlavn informan aktva organizcie.
2.2. Pozn zkladn pojmy IB, ich vznam a vie ich aplikova na vlastn organizciu.
2.3. Pozn potrebu a zsady systematickho riadenia informanej bezpenosti, pozn
truktru bezpenostnej politiky a doke pre jej vypracovanie a implementciu
vytvori v rmci svojich kompetenci v organizcii primeran podmienky
a zakomponova IB do informanch procesov organizcie.
2.4. Doke stanovi priority IB v organizcii (z hadiska plnovania, prijmanch
opatren, oetrenia rizk a pod.).
2.5. Doke stanovi zodpovednosti pracovnkov organizcie v oblasti IB a vleni ich do
ich pracovnch npln.
2.6. Doke kontrolova plnenie loh v IB v okruhu svojej psobnosti.
Riadenie rizk
3.1. Doke posdi dsledky vpadku, straty, znienia, pokodenia alebo kompromitcie
aktv organizcie.
3.2. Pozn zkladn pojmy riadenia rizk, ich vznam a vie ich aplikova na vlastn
organizciu: hrozba, zranitenos, bezpenostn incident, opatrenie, analza rizk,
oetrenie rizika a pod.
3.3. Pozn zkladn metdy oetrenia rizk a vie uri hranice akceptovatenho rizika.
3.4. Doke presadzova primeran bezpenostn poiadavky vo vzahu k tretm stranm
(pozn bezpenostn politiku vlastnej organizcie, hrozby vyplvajce z prstupu
tretch strn do systmov organizcie a opatrenia nevyhnutn na eliminciu alebo
znenie svisiacich rizk).
4.1. Rozumie bezpenostnm poiadavkm svisiacimi so zmenami, vvojom,
obstarvanm a zavdzanm IKT systmov a doke ich zohadni pri plnovan
alieho rozvoja IKT organizcie.
Fyzick bezpenos bez pecifickch dodatonch poiadaviek v tejto oblasti
Riadenie prstupu
6.1. Doke definova ktor pracovnci prpadne tretie strany maj ma prstup k funkcim
informanch systmov a dajom v nich.
Bezpenos komunikcie bez pecifickch dodatonch poiadaviek v tejto oblasti
8.1. Pozn vznam sprvy bezpenostnch incidentov a doke vhodne reagova
v prpade vskytu zvanch incidentov s dopadom na innos alebo povinnosti
organizcie.
Prevdza IT systmov a kontinuita innosti
9.1. Rozumie bezpenostnm poiadavkm svisiacimi so prevdzkou IT systmov a
doke ich zohadni pri riaden organizcie.
9.2. Rozumie poiadavkm na kontinuitu innosti IT a doke stanovi jej zkladn rmce
Audit
10.1.
Rozumie lohe a vznamu auditu, doke rmcovo stanovi ciele auditu
a doke interpretova hlavn vsledky auditu.
Zkon . 215/2004 Z.z. o ochrane utajovanch skutonost a o zmene a doplnen niektorch zkonov
Zkon . 275/2006 Z.z. o informanch systmoch verejnej sprvy a o zmene a doplnen niektorch
zkonov
62
Zkon . 215/2002 Z.z. o elektronickom podpise a o zmene a doplnen niektorch zkonov v znen
neskorch predpisov
63
Zkon . 351/2011 Z.z. o elektronickch komunikcich v znen neskorch predpisov
60
61
55
2.18.3.3 Informatici, ktor sa nepecializuj v informanej bezpenosti

Informatici, ktor IKT systmy vyvjaj, spravuj po technickej strnke, alebo riadia IT procesy
v slade s potrebami organizcie, implementuj a udriavaj bezpenostn opatrenia, ale priamo
nezodpovedaj za informan bezpenos. Vo verejnej sprve v tejto kategrii psobia
informatici v dvoch rolch
1. IT manari
2. sprvcovia informanch a komunikanch technolgi
Charakteristika roly. Vedci oddelenia, odboru alebo inej organizanej jednotky
zodpovednej za IT (v alom oddelenie IT) v organizcii, ktor me ale nemus ma
pecializovanch pracovnkov zaoberajcich sa informanou bezpenosou. IT manar riadi
prevdzku IKT a v spoluprci s inmi vedcimi pracovnkmi organizcie plnuje a realizuje
rozvoj IKT systmov organizcie.
Znalostn tandard
Zklady IB

IT manar vie o lohch a zodpovednostiach vedceho pracovnka a pecialistov na IB
v organizcii do takej miery, ktor umon efektvnu komunikciu s vedenm organizcie
a spoluprcu pri zabezpeovan potrieb IB v organizcii.
1.1. Pozn zkladn tandardy, odporania a najlepie praktiky IB pre jednotliv oblasti
IB (rad ISO 2700x, tandardy ISVS a pod.) a je schopn interpretova ich poiadavky
v prostred IT systmov v oblasti svojej psobnosti.
1.2. Pozn legislatvu relevantn pre informan systmy, za ktor zodpoved organizcii
(zkon o ochrane osobnch dajov 64 , zkon o ochrane utajovanch skutonost 65 ,
zkon o ISVS 66 , zkon o elektronickom podpise 67 , zkon o elektronickch
komunikcich 68 a pod.) ako aj povinnosti z tejto legislatvy vyplvajce.
2. Riadenie IB
2.1. Pozn zkladn pojmy IB, ich vznam a vie ich aplikova na IKT systmy vo vlastnej
organizcii, naprklad aktvum, integrita, dvernos, autentickos, dostupnos,
skromie, preukzatenos, neodmietnutenos pvodu a prijatia a pod.
2.2. Vie klasifikova informan aktva poda klasifikanej schmy.
2.3. M znalosti umoujce podiea sa na tvorbe bezpenostnej politiky organizcie
(doke identifikova hlavn informan aktva, posdi realizovatenos/dsledky
navrhovanej rovne ich ochrany, uri, ak informcia sa v akch systmoch
spracovva, formulova poiadavky na neinformatick zloky organizcie
vyplvajce zo stanovench bezpenostnch cieov a pod.).
2.4. Vie v oblasti svojej psobnosti spracova pecifikciu, zaisti vypracovanie a
presadi implementciu bezpenostnej dokumentcie niej rovne, ktor
rozpracovva bezpenostn politiku organizcie (bezpenostn tandardy).
2.5. Doke stanovi a priradi konkrtne zodpovednosti za vkon a prevdzku
66
zkonov
67
neskorch predpisov
68
64
65
56
bezpenostnch opatren pracovnkom IT oddelenia organizcie.

3. Riadenie rizk
organizciu: hrozba, zranitenos, opatrenie, analza rizk, oetrenie rizika a pod.
3.2. Doke posdi dsledky vpadku, straty, znienia, pokodenia alebo kompromitcie
aktv organizcie v oblasti svojej psobnosti.
3.3. Vie vypracova (sm alebo v spoluprci s manarom informanej bezpenosti)
zadanie pre analzu rizk a bezpenostn projekt IKT systmov v jeho psobnosti pre
internch alebo externch expertov, komunikova s nimi pri realizcii zadanej lohy
a posdi kvalitu vstupnch dokumentov.
3.4. Doke ohodnoti riziko a pozn metdy oetrenia rizk.
3.5. Vie posdi dopad navrhovanch bezpenostnch opatren (nklady, technick
zabezpeenie, organizan dsledky, legislatva).
3.6. Vie vyhodnoti innos a efektvnos prijatch opatren.
4. Obstarvanie, vvoj a zmeny IKT systmov
4.1. Vie pecifikova, prpadne posdi zkladn bezpenostn poiadavky na
obstarvan alebo vyvjan systm (zohadujc prostredie, v ktorom bude psobi),
vrtane postupov pri jeho vvoji a testovan.
4.2. Na zklade podkladov (od dodvatea, sprvcu IKT systmov, pecialistov
informanej bezpenosti a pod.) doke posdi, i dodan systm spa
bezpenostn poiadavky, ktor boli pre definovan.
5. Fyzick bezpenos
5.1. Pozn pravidl fyzickej bezpenosti v organizcii a v oblasti svojej psobnosti doke
zabezpei ich naplnenie.
5.2. Doke zabezpei implementciu bezpenostnch opatren, tkajcich sa fyzickej
bezpenosti komponentov IKT systmov (zahajcich dtov centr, stoln aj
prenosn potae pouvateov, mobiln prostriedky IKT a pod.).
6. Riadenie prstupu
6.1. Rozumie zkladnm pojmom a vie ich aplikova v konkrtnom prostred: separcia
prvomoc, princp tyroch o, princp najmench privilgi, a pod.
6.2. Doke zabezpei implementciu opatren tkajcich sa riadenia prstupu
v jednotlivch IKT systmoch (prstupy k informanm systmom, prstupy
k sieovm a inm IKT zdrojom, prstupy tretch strn).
7. Bezpenos komunikcie
7.1. Rozumie zkladnm poiadavkm na bezpenos komunikcie a vie akmi metdami
a prostriedkami sa v IKT zabezpeuj. Rozumie tomu, o opatrenia zabezpeuj a za
akch podmienok.
7.2. Doke zabezpei implementciu opatren tkajcich sa bezpenosti komunikcie
v jednotlivch IKT systmoch (komunikcia s externmi subjektmi, prstup k IKT
systmom zvntra a zvonku organizcie, prstup tretch strn).
8. Sprva bezpenostnch incidentov
8.1. Pozn vznam sprvy bezpenostnch incidentov a doke klasifikova zvanos
incidentov.
8.2. Vie v oblasti svojej psobnosti spracova zadanie, zaisti vypracovanie a presadi
implementciu postupov pri rieen bezpenostnch incidentov v IKT systmoch
v slade s pravidlami a postupmi pri sprve incidentov v organizcii.
9. Prevdzka IKT systmov a kontinuita innosti
9.1. Pozn vznam zabezpeenia kontinuity innost, pozn truktru havarijnch plnov
a plnov kontinuity innost a rozumie zkladnm pojmom v tejto oblasti (RPO,
RTO, MTO a pod.).
9.2. Rozumie zkladnm metdam a opatreniam pre zabezpeenie kontinuity innosti
a ich obmedzeniam.
9.3. Vie v oblasti svojej psobnosti spracova zadanie, zaisti vypracovanie a presadi
implementciu havarijnch plnov a plnov kontinuity innosti IKT systmov,
priom zohadn potreby organizcie (vyplvajce z jej loh).
57
9.4. Doke zohadni lohy organizcie ako aj plny inch tvarov organizcie pri
vypracovan havarijnch plnov a plnov kontinuity innosti v IKT oblasti.
9.5. Doke zabezpei praktick testovanie plnov.
10. Audit
10.1.
Pozn ciele a postupy bezpenostnho auditu, doke spolupracova s
audtormi a interpretova vsledky auditu.
Charakteristika roly - Sprvca IKT systmov. Odbornk s informatickm vzdelanm,

zodpovedn za sprvu IKT
Znalostn tandard
Zklady IB
1.1. Pozn legislatvu relevantn pre systm organizcii (zkon o ochrane osobnch
dajov 69, zkon o ochrane utajovanch skutonost 70, zkon o ISVS 71, zkon
o elektronickom podpise 72, zkon o elektronickch komunikcich73
a pod.) povinnosti, ktor z nej vyplvaj.
1.2. Doke splni povinnosti vyplvajce z legislatvy a v prpade, ak to presahuje jeho
kompetencie, vypracova v spoluprci s manarom IT kvalifikovan nvrh pre
vedenie organizcie.
1.3. Pozn bezpenostn tandardy relevantn pre systm.
2. Riadenie IB
2.1. Pozn zkladn pojmy IB, ich vznam a vie ich aplikova na IKT systmy, ktor
spravuje, naprklad aktvum, integrita, dvernos, autentickos, dostupnos, skromie,
preukzatenos, neodmietnutenos pvodu a prijatia a pod.
2.2. Pre systm doke rozpracova bezpenostn politiku organizcie do konkrtnych
postupov (praktk); pri tvorbe bezpenostnej politiky organizcie doke posdi
nvrh z hadiska potrieb systmu, resp. dopad nvrhu na systm.
2.3. Pozn klasifikan schmu a vie poda nej klasifikova systmov daje, za ktor je
zodpovedn (hesl, konfiguran sbory); vie implementova potrebn opatrenia na
ochranu klasifikovanej informcie pouvanej v systme (ochrana prstupu,
oznaovanie, procedry na spracovanie klasifikovanej informcie v systme).
3. Riadenie rizk
3.1. Pozn zkladn pojmy riadenia rizk, ich vznam a vie ich aplikova na systmy,
ktor spravuje: hrozba, zranitenos, opatrenie, analza rizk, oetrenie rizika a pod.
3.2. Doke samostatne, prpadne v spoluprci s manarom informanej bezpenosti
spracova zadanie na bezpenostn projekt, resp. analzu rizk systmu
a spolupracova pri ich realizcii.
3.3. Vie posdi relevantnos hrozieb voi systmu, zohadniac poiadavky na systm
vyplvajce z legislatvy, bezpenostnej politiky organizcie, tandardov a
zranitenosti systmu.
71
zkonov
72
neskorch predpisov
73
69
70
58
4.
5.
6.
7.
8.
9.
3.4. Doke ohodnoti rizik identifikovan poas analzy rizk.

3.5. Doke posdi plnos a adekvtnos analzy rizk/bezpenostnho projektu
systmu, najm vhodnos a pouitenos navrhovanch opatren.
3.6. Doke implementova navrhovan bezpenostn opatrenia v systme, ktor
spravuje.
4.1. Ovlda ivotn cyklus systmu a pozn bezpenostn poiadavky na systm v
jednotlivch fzach jeho ivotnho cyklu.
4.2. Pre nov systmy, ktor m v budcnosti spravova, doke pecifikova kapacitn
poiadavky a zkladn bezpenostn poiadavky.
4.3. Vie posdi do akej miery s bezpenostn poiadavky splnen v navrhovanch
rieeniach.
4.4. Pri vvoji/dodvke/pravch systmu pozn vznam oddelenia vvojovho,
testovacieho a produknho prostredia a vie primerane zabezpei ochranu
jednotlivch prostred vrtane dajov v nich uloench.
4.5. Vie sformulova bezpenostn poiadavky na dodvateov systmu (dodvka, servis,
in sluby).
4.6. Doke posdi dopad zavedenia novho systmu na existujce systmy (za ktor
zodpoved).
Fyzick bezpenos
5.1. Doke posdi potreby fyzickho zabezpeenia systmu, posdi stav fyzickej
ochrany a adekvtnos monch opatren; vie sformulova poiadavky na
bezpenostn okolie (o.i. pracovn stanice pouvateov) systmu.
Riadenie prstupu
6.1. Rozumie pojmom v oblasti riadenia prstupu a pozn vznam riadenia prstupu
a spsoby jeho zabezpeenia.
6.2. Efektvne spravuje pouvateov systmu; pre systm doke definova roly, kritri
na zaradenie pouvateov do rol a vypracova procedry na zaradenie/vyradenie
pouvatea.
6.3. Doke implementova opatrenia tkajce sa riadenia prstupu v systmoch, ktor
spravuje.
Bezpenos komunikcie
7.1. Ovlda bezpenostn aspekty IKT - bezpenos sieovho prostredia, operanch
systmov, bezpenos databzovch systmov, bezpenos web systmov (veobecne
a detailne bezpenostn aspekty systmu, ktor spravuje)
7.2. Pozn a vie pouva technolgie sieovej bezpenosti.
7.3. Ovlda zklady kryptolgie a PKI (pouvanie kryptografickch technk
a prostriedkov, vrtene sprvy kryptografickch kov).
8.1. Pozn vznam sprvy bezpenostnch incidentov a doke klasifikova zvanos
incidentov tkajcich sa systmov, ktor spravuje.
8.2. Doke spracova a zavies do pouvania postupy pre rieenie bezpenostnch
incidentov zasahujcich systmy, ktor spravuje.
9.1. Pri prevdzke systmu pozn a vie zabezpei dodriavanie pravidiel pre narbanie
s mdiami, vmenu informci s tretmi stranami, monitorovanie aktivt v systme,
a pre vytvranie, ochranu a spracovanie zznamov auditu.
9.2. Pozn princpy fungovania rozlinch typov kodlivho kdu a spsob ochrany proti
nim.
9.3. Pozn vznam zabezpeenia kontinuity innost a rozumie zkladnm pojmom v tejto
oblasti.
9.4. Na zklade odbornho usmernenia doke zdokumentova iastkov plny kontinuity
innosti na rovni nm vykonvanch alebo zabezpeovanch postupov, vrtane
havarijnch plnov a plnov obnovy pre systm, ktor spravuje.
9.5. Rozumie potrebe overovania postupov obnovy a zabezpeenia kontinuity a je
59
schopn prakticky overi postupy dotkajce sa systmov, ktor spravuje.

9.6. M odborn poznatky potrebn na prevdzkovanie systmov, ktor spravuje, v slade
s plnmi zabezpeenia kontinuity innosti.
10. Audit
10.1.
Pozn poiadavky na hodnotenie bezpenosti systmov: audit a certifikcia,
self-assessment v IB.
10.2.
Doke spolupracova s audtormi pri audite systmov, ktor spravuje.
2.18.3.4 pecialisti v informanej bezpenosti

Do tejto kategrie patria v prvom rade manari informanej bezpenosti rozlinch rovn,
audtori IKT systmov a produktov, opertori bezpenostnch technolgi, bezpenostn
analytici, vyetrovatelia pecializujci sa na potaov kriminalitu. Vo verejnej sprve psobia v
4 rolch
1. manari informanej bezpenosti
2. opertori bezpenostnch technolgi (pecialisti zameran na bezpenos konkrtnych IKT
oblast alebo na konkrtne bezpenostn technolgie)
3. audtori
4. bezpenostn analytici
Charakteristika roly - Manar informanej bezpenosti: Vedci pracovnk,

pecializovan pre oblas informanej bezpenosti. Najvyia odborn autorita pre IB v
organizcii. Je vlastnkom bezpenostnej politiky a zodpoved za jej sprvu a v spoluprci
s pracovnkmi vlastnho tvaru (ak tak v organizcii existuje) a/alebo s inmi pracovnkmi aj
za jej rozpracovanie a uplatovanie. Samostatn pozcia bezpenostnho manara IT a/alebo
tvar bezpenostnho manara IT existuje spravidla vo vch organizcich.
Znalostn tandard
1.1. Pozn zkladn tandardy, odporania a najlepie praktiky IB pre jednotliv oblasti
IB (rad ISO 2700x, CObIT, tandardy ISVS a pod.) a je schopn interpretova ich
poiadavky v prostred IT systmov v oblasti svojej psobnosti.
1.2. Pozn legislatvu relevantn pre informan systmy, za ktor zodpoved organizcii
komunikcich 78 a pod.) ako aj povinnosti z tejto legislatvy vyplvajce.
2. Riadenie IB
2.1. Pozn a orientuje sa v jednotlivch oblastiach IB.
2.2. Doke sformulova nvrh bezpenostnej politiky organizcie.
2.3. Doke vypracova alebo riadi vypracovanie bezpenostnho projektu a alch
formlnych dokumentov v slade s legislatvnymi poiadavkami a potrebami
organizcie.
76
zkonov
77
neskorch predpisov
78
74
75
60
3.
4.
5.
6.
7.
2.4. Vie definova vhodn bezpenostn roly a svisiace zodpovednosti v procesoch a

systmoch organizcie .
2.5. Vie zhodnoti aktulny stav riadenia IB v organizcii, vrtane identifikcie
najzvanejch nedostatkov a vhodnch npravnch opatren.
2.6. Doke definova bezpenostn politiky a tandardy pre rzne IKT oblasti
v organizcii.
2.7. Doke premietnu bezpenostn poiadavky do inch vntornch predpisov
organizcie (ktor upravuj riadenie projektov, riadenie zmien, riadenie kvality a
pod.).
2.8. Doke sa podiea na vzdelvan a zvyovan bezpenostnho povedomia
pracovnkov organizcie.
2.9. Doke komunikova s externmi bezpenostnmi expertmi v jednotlivch oblastiach
IB.
Riadenie rizk
organizciu: hrozba, zranitenos, opatrenie, analza rizk, oetrenie rizika a pod.
3.2. Doke zavies a riadi systematick spravovanie IT rizk v organizcii, ohodnoti
rizik a pozn metdy oetrenia rizk.
3.3. Vie vypracova analzu rizk IKT systmov a vie posdi kvalitu takchto
dokumentov ak s vypracovan externe.
3.4. Doke ohodnoti riziko a pozn metdy oetrenia rizk.
3.5. Vie posdi dopad navrhovanch bezpenostnch opatren (nklady, technick
zabezpeenie, organizan dsledky, legislatva).
3.6. Vie vyhodnoti innos a efektvnos prijatch opatren.
3.7. Doke spolupracova pri zavdzan bezpenostnch prostriedkov v organizcii,
vrtane ich testovania.
Obstarvanie, vvoj a zmeny IT systmov
4.1. Vie v spoluprci s odbornmi tvarmi organizcie pecifikova bezpenostn
poiadavky na predmet obstarvania.
4.2. Vie posdi naplnenie bezpenostnch poiadaviek na predmet obstarvania.
Fyzick bezpenos
5.1. Pozn hrozby fyzickho naruenia IKT systmov a ich infratruktry a doke
ohodnoti rizik z nich vyplvajce.
5.2. Vie navrhn, zdvodni a zaisti/zorganizova implementciu opatren fyzickej
ochrany IKT systmov.
5.3. Doke vypracova nvrhy politk na zaistenie fyzickej ochrany IKT systmov
v organizcii.
5.4. Doke posdi innos existujcich opatren fyzickej ochrany a dopad technickch,
organizanch, prpadne inch zmien v organizcii na fyzick bezpenos IKT
systmov.
Riadenie prstupu
6.1. Rozumie vznamu identifikcie a autentizcie; pojmom, princpom a metdam
I&A; spsobom riadenia prstupu a vie ich aplikova v konkrtnom prostred.
6.2. Vie posdi ak rove a spsob riadenia prstupu si vyaduj jednotliv IKT
systmy. Doke navrhn vhodn rieenia pre riadenie prstupu ako aj posdi ich
innos a efektvnos.
6.3. Doke zaisti implementciu opatren tkajcich sa riadenia prstupu v jednotlivch
IKT systmoch a spolupracova pri ich implementcii.
Bezpenos komunikcie
7.1. Pozn a rozumie hrozbm voi sieam a prenanm dajom.
7.2. Pozn a rozumie bezpenostnm mechanizmom a opatreniam na ochranu siet
a dajov.
7.3. Vie posdi nvrhy bezpenostnch opatren navrhnutch sprvcom siete
alebo pecialistom na sieov bezpenos, ako aj spolupracova pri ich nvrhu.
7.4. Doke vhodnm spsobom vyhodnoti innos prijatch opatren.
61

8.1. Doke zabezpei rieenie bezpenostnch incidentov v organizcii.
8.2. Doke vyvodi zvery z bezpenostnch incidentov, ktor sa v organizcii vyskytli.
9. Prevdzka IT systmov a kontinuita innosti
9.1. Ovlda zklady procesov a postupov prevdzky IKT systmov, vrtane svisiacich
bezpenostnch poiadaviek a dopadov.
9.2. Doke vypracova v spoluprci s almi pracovnkmi organizcie havarijn plny a
plny kontinuity innosti.
9.3. Vie plnova stratgiu testovania havarijnch plnov a plnov obnovy a podiea sa na
ich testovan.
10. Audit
10.1.
Pozn lohu auditu a doke pecifikova ciele a rozsah auditu (rozsah
a detailnos auditu, pouit metodika a pod.).
10.2.
Doke spolupracova s audtormi pri bezpenostnom audite a interpretova
vsledky auditu.
Charakteristika roly - Opertor bezpenostnch technolgi. Vykonva iastkov procesy
(innosti pri realizcii bezpenostnch opatren) informanej bezpenosti ako naprklad
opertor antivrusovch nstrojov, nstrojov IDS/IPS, bezpenostnch tokenov, alebo
vykonva sprvu kryptografickch kov at.
Znalostn tandard
1.1. M zkladn prvnu orientciu v legislatve relevantnej pre informan systmy a
spracvan daje vo vlastnej organizcii (zkon o ochrane osobnch dajov 79, zkon
o ochrane utajovanch skutonost 80 , zkon o ISVS 81 , zkon o elektronickom
podpise 82, zkon o elektronickch komunikcich83 a pod.).
2. Riadenie IB
2.1. Doke efektvne vykonva iastkov proces informanej bezpenosti.
2.2. Doke sformulova nvrh bezpenostnej smernice alebo postupu v oblasti tkajcej
sa bezpenostnho procesu v oblasti svojej psobnosti.
2.3. Vie zhodnoti aktulny stav bezpenostnho procesu v organizcii, vrtane
identifikcie najzvanejch nedostatkov.
2.4. Doke spolupracova pri zavdzan a zmench bezpenostnho procesu, vrtane
jeho testovania.
2.5. V prpade potreby je schopn vykoli pracovnkov organizcie v postupoch
zabezpeujcich sprvne a efektvne zvldnutie bezpenostnho procesu.
3. Riadenie rizk
3.1. M veobecn znalosti o spsobe riadenia rizk.
3.2. Pozn hrozby relevantn pre oblas IB v ktorej pracuje, vie zdokumentova a
vyhodnoti rizik z nich vyplvajce a navrhn opatrenia.
3.3. Samostatne, prpadne v spoluprci so sprvcami IKT systmov vie implementova
bezpenostn opatrenia v oblasti svojej psobnosti.
4. Obstarvanie, vvoj a zmeny IKT systmov
4.1. Vie posdi dopady zmien na oblas svojej psobnosti.
4.2. Vie sformulova bezpenostn poiadavky na/z oblasti svojej psobnosti a posdi, i
boli v primeranej miere splnen.
81
zkonov
82
neskorch predpisov
83
79
80
62
5. Fyzick bezpenos
5.1. Pozn problematiku fyzickej bezpenosti vo veobecnosti.
5.2. Doke vyhodnoti fyzick hrozby a odhadn rizik z nich vyplvajce v oblasti
svojej psobnosti a navrhn primeran opatrenia fyzickho a organizanho
charakteru.
6. Riadenie prstupu
6.1. Rozumie pojmom, princpom a vznamu identifikcie, autentizcie, metdam
a spsobom riadenia prstupu a vie ich aplikova v konkrtnom prostred svojej
psobnosti.
6.2. Vie posdi ak rove a spsob riadenia prstupu si vyaduj a ak prostriedky
riadenia prstupu umouj jednotliv bezpenostn technolgie, ktorch prevdzku
zabezpeuje. Doke navrhn vhodn rieenia pre riadenie prstupu ako aj posdi
ich innos a efektvnos.
6.3. Doke zaisti implementciu opatren tkajcich sa riadenia prstupu v oblasti svojej
psobnosti systmoch a spolupracova pri ich implementcii.
7.1. Pozn a rozumie hrozbm voi sieam a prenanm dajom.
7.2. Pozn a rozumie bezpenostnm mechanizmom a opatreniam na ochranu siet
a dajov.
7.3. Pozn a vie pouva prostriedky sieovej bezpenosti v svislosti s bezpenostnou
technolgiou, ktorej prevdzku zabezpeuje.
8.1. Ovlda postupy a innosti pri vskyte a rieen bezpenostnho incidentu, ktor je
indikovan nm prevdzkovanou bezpenostnou technolgiou.
8.2. V prpade potreby vie kvalifikovane psobi v tme na rieenie bezpenostnho
incidentu.
9. Prevdza IT systmov a kontinuita innosti
9.1. Ovlda zklady procesov a postupov prevdzky IKT systmov, vrtane svisiacich
bezpenostnch poiadaviek a dopadov
10. Audit
10.1.
Doke spolupracova s audtormi pri bezpenostnom audite bezpenostnho
procesu a interpretova vsledky auditu.
Charakteristika roly - Audtor bezpenosti IKT systmov: Pracovnk posudzujci zhodu

riadenia IB, vykonvanch procesov IB a implementovanch opatren s definovanmi
legislatvnymi a inmi relevantnmi poiadavkami, prpadne s najlepou praxou.
Znalostn tandard
1.1. pozn a orientuje sa v zkladnch tandardoch IB (rad ISO 2700x, CObIT, tandardy
ISVS a pod.)
1.2. pozn a orientuje sa v platnej legislatve upravujcej poiadavky na IB organizcii
komunikcich 88 a pod.)
86
zkonov
87
neskorch predpisov
84
85
63
2. Riadenie IB
2.1. vie analyzova vntorn procesy organizcie a zhodnoti spsob a kvalitu riadenia
a procesov informanej bezpenosti v organizcii, vrtane svisiacej vntornej
legislatvy (politiky, postupy, tandardy a pod.)
3. Riadenie rizk
3.1. vie zdvodni a zdokumentova identifikovan rizik
3.2. doke odporui potencilne vhodn opatrenia na znenie alebo eliminciu
identifikovanch rizk, prpadne spolupracova so zodpovednmi pracovnkmi
organizcie na nvrhu npravnch opatren
3.3. vie zhodnoti vhodnos a spsob implementcie bezpenostnch prostriedkov
a technolgi v IKT
4. Obstarvanie, vvoj a zmeny IT systmov
4.1. vie zhodnoti spsob riadenia ivotnho cyklu informanch systmov v organizcii
5. Fyzick bezpenos
5.1. m prehad o fyzickej bezpenosti (hrozby, rizik, opatrenia), vie posdi zvanos
rizk relevantnch pre organizciu a adekvtnos prijatch opatren
6. Riadenie prstupu
6.1. pozn vznam a metdy I&A, vie posdi innos metd I&A pouvanch
v organizcii a ich slad s politikou riadenia prstupu (klasifikciou informanch
aktv)
7.1. ovlda zklady kryptolgie, sieovej a komunikanej bezpenosti v dostatonej miere
na to, aby vedel posdi relevantn hrozby voi sieti organizcie a i s prijat
opatrenia primeran
8.1. pozn postupy pri rieen bezpenostnch incidentov vo veobecnosti,
8.2. doke vyhodnoti zznamy o incidentoch v organizcii
8.3. doke posdi, i s postupy, ktor sa pouvaj pri rieen bezpenostnch
incidentov v organizcii primeran, i s v slade s legislatvou a bezpenostnou
politikou organizcie a i s inn
9. Prevdza IT systmov a kontinuita innosti
9.1. pozn najlepie praktiky pre prevdzku informanch systmov a bezpenostnch
prostriedkov
9.2. vie zhodnoti adekvtnos havarijnch plnov a plnov kontinuity innost
9.3. vie zhodnoti kvalitu a adekvtnos pouvanch procesov a postupov prevdzky IKT
(konfiguran riadenie, sprva incidentov, kapacitn plnovanie, riadenie zmien a
pod.)
10. Audit
10.1.
ovlda a vie prakticky poui vhodn metodiku pre audit informanho
systmu
10.2.
vie navrhn stratgiu auditu a vykona audit informanho systmu poda
najlepch praktk, tandardov, legislatvnych a inch poiadaviek na bezpenos
Charakteristika roly - Bezpenostn analytik. pecialista zodpovedn za rieenie zloitch

bezpenostnch incidentov, bezpenostnch incidentov vekho rozsahu alebo incidentov s
vnym dopadom na organizciu. M irok vedomosti zo vetkch oblast informanej
bezpenosti a hlbok pecializovan znalosti z jednej alebo viacerch oblast IB.
Znalostn tandard
88
64
2.
3.
4.
5.
6.
7.
8.
1.1. pozn legislatvu SR relevantn pre oblas IB organizcii (zkon o ochrane osobnch
dajov 89, zkon o ochrane utajovanch skutonost 90, zkon o ISVS 91, zkon
o elektronickom podpise 92, zkon o elektronickch komunikcich93 a pod.)
1.2. pozn medzinrodn tandardy IB
Riadenie IB
2.1. pozn systm riadenia IB poda tandardov ISO/IEC 27000-27002
2.2. pozn systm riadenia IB v organizcii, v ktorej psob
Riadenie rizk
3.1. pozn systm riadenia rizk poda tandardu ISO/IEC 27005 a
3.2. pozn systm riadenia rizk v organizcii, kde psob
3.3. doke vykona analzu rizk
3.4. doke posdi innos prijatch/navrhovanch opatren
4.1. pozn ivotn cyklus IKT systmu a doke posdi, i sa priebehu ivotnho cyklu
konkrtneho IKT systmu dostatone uplatovali bezpenostn poiadavky, resp. kde
organizcia mala bezpenostn rizik
4.2. doke navrhn opatrenia na odstrnenie zistench bezpenostnch rizk
Fyzick bezpenos
5.1. pozn hrozby, zranitenosti a opatrenia na zaistenie fyzickej bezpenosti IKT
systmov vo veobecnosti,
5.2. doke posdi, ktor z hrozieb s relevantn pre IKT systmy organizcie a innos
prijatch opatren
5.3. doke identifikova nedostatky vo fyzickej ochrane IKT po bezpenostnom
incidente a navrhn opatrenia na ich odstrnenie
Riadenie prstupu
6.1. pozn vznam I&A, metdy I&A
6.2. vie posdi vhodnos pouitch metd I&A v organizcii a kvalitu ich
implementcie
Bezpenos komunikcie
7.1. m primeran vedomosti o fungovan potaovch siet, pouvanch sieovch
protokoloch, hrozbch a bezpenostnch mechanizmoch,
7.2. m primeran poznatky o kryptolgii a jej aplikcich (ifrovanie, elektronick
podpis a i.)
7.3. doke posdi kvalitu pouitch rieen na zabezpeenie siete organizcie, vie njs
zranitenosti a navrhn vhodn spsob ich odstrnenia alebo ochrany
8.1. vie identifikova a analyzova bezpenostn incident (charakteristika,
pvodca/prina, postup/spsob vzniku, zhodnotenie rozsahu a dopadov a pod.)
8.2. pozn metodiku vyetrovania/riadenia bezpenostnho incidentu a vie ju aplikova na
rieenie bezpenostnch incidentov
8.3. doke riadi situciu v prpade bezpenostnho incidentu
8.3.1. navrhn vhodn spsob reakcie na bezpenostn incident, minimalizujc
dopady na innos organizcie
8.3.2. odporui spsob zotavenia sa z incidentu
8.3.3. po zvldnut incidentu navrhn preventvne npravn opatrenia, prpadne
dodaton opatrenia vasnej detekcie incidentu
8.3.4. poskytuje informcie o incidente a odporuenia zodpovednm riadiacim
91
zkonov
92
neskorch predpisov
93
89
90
65
pracovnkom organizcie
8.3.5. v prpade potreby zabezpei zskanie dkazov, prpadne potrebn komunikciu
s externmi subjektmi
8.3.6. formlne zdokumentova incident
8.4. pozn tandardn bezpenostn technolgie a ovlda technolgie pouit
v systmoch, ktorch sa tka bezpenostn incident
8.5. pozn prvne poiadavky na zskavanie a uchovvanie dkazov pri bezpenostnch
incidentoch v IKT a vie ich aplikova v praxi
8.6. pozn postupy a ovlda nstroje pre bezpen a preukazn 94 evidenciu zskanch
informci
8.7. pozn techniky a ovlda nstroje forenznho zskavania informci z nosiov dt,
operanch systmov a aplikci (vrtane ivch systmov), potaovch siet a ich
komponentov a pod.
8.8. pozn techniky a ovlda nstroje pre rekontrukciu priebehu incidentu, vrtane
asovej lnie (priebehu), spsobu uskutonenia a identifikcie pvodcu incidentu
8.9. pozn techniky a ovlda nstroje pre analzu prebiehajceho bezpenostnho
incidentu
9. Prevdzka IT systmov a kontinuita innosti
9.1. pozn bezpenostn problmy, ktor je potrebn riei poas prevdzky systmu
9.2. doke posdi prevdzkov predpisy, pouvan postupy a v prpade
bezpenostnho incidentu vie posdi, i dolo k porueniu predpsanch postupov,
alebo i tieto postupy nemaj nedostatky
9.3. doke vyhodnoti hrozby, ktor mu spsobi rozsiahle/zvan naruenie IKT
systmov a posdi innos opatren na zabezpeenie kontinuity innosti
10. Audit
10.1.
Pozn metdy auditu a doke vyuva vsledky auditu pri analze stavu IKT
systmov a prin bezpenostnch incidentov.
2.18.3.5 Uitelia informanej bezpenosti

Uite informanej bezpenosti je odbornk v informanej bezpenosti, ktor v tejto oblasti
pravidelne vykonva systematick vzdelvaciu innos. Kvalifikcia uitea informanej
bezpenosti je dan znalosami, ktor m posluchom odovzda a schopnosou poda ich tak,
aby im posluchi porozumeli a osvojili si ich. Vo verejnej sprve psobia odbornci v IB, ktor
(popri inej innosti) prleitostne vzdelvaj zamestnancov verejnej sprvy v IB. Tto odbornci
patria do roly lektorov IB.
Charakteristika roly - Lektor IB. Lektor s informatickm vzdelanm, ktor u zklady IB
dospelch laikov (zamestnancov nejakej organizcie verejnej sprvy, vrtane manarov a
vedcich pracovnkov).
Znalostn tandard
Zklady IB
94
Pozn zkladn pojmy a rozumie procesom a ich vznamu vo vetkch oblastiach IB.
Okrem pecifickch znalost IB navye:
Doke pripravi a vies praktick cvienia zameran na osvojenie potrebnch zrunost v
oblastiach IB.
Doke demontrova preberan oblasti IB na konkrtnych prkladoch (poiadavky
Zvzn poiadavky na narbanie s digitlnymi dkazmi nie s v slovenskej legislatve zatia stanoven
66
tandardov, legislatvy, spsoby riadenia IB, bezpenostn mechanizmy, postupy a pod.),

ilustrova dobr aj zporn strnky jednotlivch rieen a opatren, at.
Doke pripravi a realizova skku na overenie zskanch znalost a zrunost.
1.1. M zkladn prvnu orientciu v informanej bezpenosti (zkon o ochrane osobnch
dajov 95 , zkon o ochrane utajovanch skutonost 96 , zkon o ISVS 97 , zkon
o elektronickom podpise 98 , zkon o elektronickch komunikcich 99 a pod.)
a o povinnostiach vyplvajcich z tejto legislatvy pre organizciu.
1.2. Pozn prvne poiadavky na pouvanie IT systmov organizcie a etick zsady
sprvania sa v digitlnom priestore.
1.3. Vie o existencii a nplni tandardov upravujcich jednotliv oblasti IB (rad ISO
2700x, tandardy ISVS a pod.).
2. Riadenie IB
2.1. Pozn zkladn pojmy IB, ich vznam a vie ich aplikova na konkrtnu organizciu,
naprklad aktvum, integrita, dvernos, autentickos, dostupnos, skromie,
preukzatenos, neodmietnutenos pvodu a prijatia a pod.
2.2. Pozn v primeranej miere pecifick pravidl vlastnej organizcie naprklad
bezpenostn politiku, tandardy, pouit bezpenostn opatrenia, konkrtne postupy
pri nahlasovan a rieen bezpenostnch incidentov, havarijn plny a pod.
2.3. Vie identifikova hlavn informan aktva organizcie.
2.4. Pozn potrebu a zsady systematickho riadenia IB, pozn truktru bezpenostnej
politiky a rozumie zsadm, ako zakomponova IB do informanch procesov
organizcie.
2.5. Rozumie spsobom, akm stanovi priority IB v organizcii (z hadiska plnovania,
prijmanch opatren, oetrenia rizk a pod.).
2.6. Pozn zsady organizanej bezpenosti a stanovenia zodpovednosti pracovnkov
organizcie v oblasti IB.
3. Riadenie rizk
organizciu: hrozba, zranitenos, bezpenostn incident, opatrenie, analza rizk,
oetrenie rizika a pod.
3.2. Rozumie ohodnoteniu rizk, spsobom posdenia dsledkov vpadku, straty,
znienia, pokodenia alebo kompromitcie aktv organizcie.
3.3. Pozn zkladn metdy oetrenia rizk a spsoby urenia hranice akceptovatenho
rizika.
4. Obstarvanie, vvoj a zmeny IT systmov
4.1. Rozumie bezpenostnm poiadavkm svisiacimi so zmenami, vvojom,
obstarvanm a zavdzanm IT systmov.
5. Fyzick bezpenos
5.1. Pozn vznam fyzickej bezpenosti a zodpovedajce zsady a pravidl.
5.2. Doke v praxi uplatova konkrtne pravidl fyzickej bezpenosti organizcie.
6. Riadenie prstupu
6.1. Pozn princpy fungovania rznych prostriedkov autentizcie (hesl, PIN kdy,
tokeny, biometria), vie ich pouva, pozn zsady ochrany autentizanch
prostriedkov.
97
zkonov
98
neskorch predpisov
99
95
96
67
7.
8.
9.
10.
6.2. Pozn zkladn techniky socilneho ininierstva, vie ich identifikova a sprvne na ne
reagova (prezrdzanie hesiel, phishing a pod.).
Bezpenos komunikcie
7.1. Pozn zkladn poiadavky na ochranu potaov a inch zariaden v sieti.
7.2. Pozn princpy fungovania bezpenostnch rieen v tejto oblasti.
7.3. Rozumie rizikm prce na Internete, ich dsledkom a zsadm bezpenej prce na
Internete: elektronick pota (spam, prlohy a pod.), renie infiltrci (potaov
vrusy, malware, spyware a pod.), potaov pirtstvo.
8.1. Pozn vznam sprvy bezpenostnch incidentov a zsady pri reakcii na
bezpenostn incidenty.
Prevdzka IT systmov a kontinuita innosti
9.1. Rozumie princpom fungovania jednotlivch typov a mechanizmov bezpenostnch
opatren v IT systmoch.
9.2. Pozn vznam, spsob zlohovania a obnovy dajov v IT systmoch ako aj dajov
jednotlivch pouvateov.
9.3. Rozumie bezpenostnm poiadavkm svisiacimi s prevdzkou IT systmov
a spsobu, akm ich zohadni v konkrtnej organizcii.
9.4. Rozumie poiadavkm na kontinuitu innosti IT a doke stanovi jej zkladn rmce
v konkrtnej organizcii.
Audit
10.1.
Pozn vznam auditu, lohu audtora, laika a vedceho pracovnka pri audite.
68
3 Architektra, modely a hodnotenie

Jaroslav Janek
3.1 vod
Hrozby voi informanmu a komunikanmu systmu (IKS) mu by zameran na technick
as systmu, jeho programov vybavenie, na spsob jeho pouvania, alebo na prostredie v
ktorom dan systm psob. Njdenie a zavedenie vhodnch konkrtnych bezpenostnch
opatren technickho charakteru si asto vyaduje detailn poznanie truktry a fungovania IKS.
Pre pouvatea s sce technick opatrenia bu transparentn, alebo si od neho vyaduj
spoluprcu, na ktor nepotrebuje iadne alebo len minimlne technick znalosti, ale poznanie
aspo zkladnch princpov fungovania IKT umouje neinformatikom lepie chpa podstatu
hrozieb, monost voby opatren a uahuje im spoluprcu s bezpenostnmi pecialistami. Tto
kapitola je uren v prvom rade neinformatikom, zaujmajcim v organizcii rzne postavenie
od radovch zamestnancov neprivilegovanch pouvateov IKS, po riadiacich pracovnkov
zodpovednch okrem inho aj za informan bezpenos organizcie. Informatikom me prv
as kapitoly posli pri koleniach laikov; inak mu prv as tejto kapitoly preskoi a
pokraova v tan a druhou asou kapitoly, venovanou bezpenostnm modelom a certifikcii
IKS.
3.2 Architektra a komponenty informanho systmu

Informan systmy, i u ide o mal informan systmy prevdzkovan na jednom potai
alebo komplexn distribuovan systmy, sa skladaj z viacerch vznamnch komponentov.
Vek as tchto komponentov nie je pecifickch pre konkrtny informan systm, ale m
veobecn charakter. Ich lohou je poskytn inm komponentom rzne sluby pomocou svojich
rozhran. Prkladom takch veobecnch komponentov je hardvr a operan systm. Takto
prstup m viacero vhod, napr.:
Nie je potrebn pre kad informan systm nanovo vyma rieenie pre tandardn
problmy, kee tandardn problmy typicky riei nejak tandardn komponent a
rieenie poskytuje ako svoju slubu.
Rzne informan systmy mu zdiea veobecn komponenty, o umouje napr.

pouitie toho istho potaa na rzne ely nemusme kvli novmu informanmu
systmu vdy obstara aj nov hardvr.
Ak sa zachov rozhranie, je mon jednotliv komponenty nahradi inmi bez toho, aby
to malo vplyv na in asti systmu. Napr. aplikan programy pristupuj k dajom
uloenm na disku prostrednctvom sluieb operanho systmu, ktor pre ukladanie
dajov poskytuje abstrakciu sbory. Ke zmenme spsob uloenia dajov na disku, je
potrebn zmeni prslun komponent operanho systmu, no z pohadu aplikanch
programov sa ni nezmen.
Jednotliv komponenty navzjom nevyuvaj svoje sluby chaoticky, ale meme v nich
identifikova typicky niekoko vrstiev. Najniou vrstvou je vrstva hardvru. Sasou hardvru
s, jednoducho povedan, vetky fyzick sasti informanho systmu, teda vetko, o je mon
chyti do ruky. V hardvri s skutone uloen vetky daje, s ktormi informan systm
pracuje. V hardvri sa tie skutone realizuj vetky opercie s dajmi.
Nad vrstvou hardvru sa nachdza vrstva operanho systmu. Operan systm pln rad
dleitch loh ako pre funknos, tak aj pre bezpenos informanho systmu. Jednou z jeho
dleitch loh je poskytn vym vrstvm abstrakciu rznych ast hardvru ako svoje sluby,
69
Architektra, modely a hodnotenie | MF SR
ktor mu komponenty na vych vrstvch vyuva bez toho, aby museli pozna detaily o
pouitom hardvri.
Nad vrstvou operanho systmu sa nachdza aplikan vrstva. V nej sa nachdzaj komponenty
pecifick pre konkrtny informan systm, ako aj alie veobecn komponenty rzne
pomocn programy a tzv. kninice. Kninice s komponenty vyuvan rznymi programami na
rieenie rznych iastonch problmov na aplikanej vrstve, ktor sa asto opakuj. Takisto
kninice zvyajne sprostredkovvaj programom jednotn prstup k slubm operanho
systmu spsobom, ktor nie je zvisl na konkrtnom operanom systme, ale me by
spolon pre viacero rznych operanch systmov.
V zloitejch informanch systmoch sa asto medzi aplikan vrstvu a vrstvu operanho
systmu vklad ete databzov vrstva. Jej lohou je poskytn zloitejie funkcie na prstup k
vekmu mnostvu truktrovanch dajov, m komponenty na aplikanej vrstve odbremen od
problmu, ako uklada a manipulova s vekm mnostvom dajov.
Vrstvy, ktor sme spomenuli vyie patria medzi najvznanejie vrstvy, ktorch odlenie je
potrebn aj z pohadu bezpenosti. Sam s vak asto vntorne lenen na alie vrstvy, alebo
sa aspo skladaj z mnohch spolupracujcich komponentov. V nasledujcich astiach sa
podrobnejie pozrieme na vznam, truktru a vybran vlastnosti jednotlivch vrstiev.
3.2.1
Hardvr
Hardvr informanho systmu sa sklad z viacerch ast. Z laickho pohadu zvonku typicky
vidme samotn pota a k nemu pripojen rzne vstupn a vstupn zariadenia (klvesnica,
my, monitor, tlaiare, skener, ...). V prpade notebookov s viacer tieto zariadenia spojen do
jednho fyzickho celku, o umouje ahie prenanie, no z hadiska ich vznamu a funknosti
sa prakticky nelia od ich samostatnch verzi, ktor poznme zo stolnch potaov alebo
serverov.
Vntri potaa sa nachdza viacero dleitch ast:
zkladn doska (motherboard),
procesor (CPU),
operan pam,
pevn disky,
CD/DVD mechaniky,
rozirujce karty (napr. grafick karta, sieov karta, radi diskov, ...).
Zkladn doska je centrlny komponent, ktor sli predovetkm na to, aby prepojil navzjom
alie komponenty. Na tento el obsahuje jeden alebo niekoko typov tzv. zbernice. Zbernica je
elektronick systm umoujci prenos prkazov a dajov medzi k nej pripojenmi zariadeniami.
V sasnosti sa v bench potaoch stretneme najm so zbernicami typu PCI a PCI-Express.
pecilne zbernice sa pouvaj na komunikciu medzi procesorom(mi) a pamou. Kad
zbernica obsahuje pecilne konektory, do ktorch sa pripjaj jednotliv zariadenia.
Sasou zkladnej dosky s aj alie komponenty, ktor vytvraj rozhrania pre pripjanie
inch zariaden k potau i u externch (napr. klvesnice, myi, monitor, ...), alebo internch
(napr. pevn disky). Na pripjanie rznych zariaden sa pouvaj rzne rozhrania. Z tch dnes
najastejie sa vyskytujcich meme spomen napr.:
USB pouva sa dnes na pripjanie viny externch zariaden k potaom,
PS/2 starie rozhranie na pripojenie klvesnice a myi,
VGA, HDMI, DisplayPort slia na pripojenie monitora,
IDE, SATA ben rozhrania pre pripojenie diskov a CD/DVD mechank v
70
kancelrskych potaoch,
SCSI, SAS ben rozhrania pre pripojenie diskov a CD/DVD mechank v serveroch.
Procesor je centrlna as potaa, ktor riadi cel pota a vykonva vinu vpotov a inch
operci s dajmi. Pota obsahuje aspo jeden procesor, no me ich by aj viac. Dnen
procesory sa navye skladaj z viacerch tzv. jadier, ktor v podstate predstavuj samostatn
procesory uzavret v jednom spolonom obale. Procesor sa vntorne sklad z viacerch ast, z
ktorch najdleitejie s:
aritmeticko-logick jednotka,
riadiaca jednotka,
registre.
Aritmeticko-logick jednotka procesora je sstava obvodov, ktor realizuj elementrne

aritmetick a logick opercie, ako napr. stanie, odtanie, nsobenie, delenie alebo
porovnvanie sel. Registre predstavuj vemi rchlu a mal pam na daje, s ktormi me
aritmeticko-logick jednotka pracova. Riadiaca jednotka riadi innos procesora na zklade
programu. Program je postupnos intrukci. Riadiaca jednotka postupne ta jednotliv
intrukcie programu a pomocou alch ast procesora zabezpeuje ich vykonanie. Jednotliv
intrukcie predstavuj pokyny na vykonanie elementrnych operci ako napr. skoprova daje
medzi miestom v pamti a registrom, vykona aritmetick operciu s hodnotami v dvoch
registroch, zaa vykonva in as programu, a pod. Z takchto elementrnych operci sa v
konenom dsledku skladaj vetky programy, ktor uruj innos procesora, a tm aj celho
informanho systmu.
Aby riadiaca jednotka procesora mohla ta a vykonva intrukcie programu, tieto musia by
zapsan v tzv. strojovom kde. V tejto podobe maj intrukcie podobu postupnosti sel, poda
ktorch riadiaca jednotka rozhodne o a s m m spravi. Tto podoba nie je zrozumiten
loveku. Strojovmu kdu najbliia forma, ktor je zrozumiten (prslune kvalifikovanmu)
loveku je program napsan v tzv. jazyku assemblera. V jazyku assemblera jednotlivm
intrukcim zodpovedaj niekoko-psmenov skratky. V jazyku assemblera sa vak bene pu
len relatvne mal asti programov, ktor bu obsahuj pecilne intrukcie, alebo pri ktorch je
extrmne dleit napr. rchlos alebo presn naasovanie jednotlivch operci. Obyajne sa
programy pu vo vych programovacch jazykoch, ako s napr. C, C++, C#, Java a in. V
tchto jazykoch je mon programy psa loveku podstatne blim tlom, o vrazne
napomha ich zrozumitenosti. Programy napsan vo vych programovacch jazykoch sa
nsledne prekladaj do strojovho kdu pre prslun procesor alebo (napr. v prpade jazyka
Java) do univerzlneho strojovho kdu pre tzv. interpreter. Interpreter je program, ktor
vykonva program zapsan v nejakom univerzlnom strojovom kde na konkrtnom procesore.
Operan pam potaa (asto nie celkom sprvne oznaovan ako RAM) sli na doasn
uloenie dajov a programov v potai, aby s nimi mohol procesor pracova. Typick vekos
operanej pamte v bench kancelrskych potaoch a notebookoch sa v sasnosti pohybuje
na rovni niekoko gigabyte-ov (GB), v serveroch od niekokch GB po rdovo 100 GB. daje
mu by uloen v operanej pamti len km je pota zapnut, po vypnut napjania sa
postupne stratia. Z bezpenostnho hadiska je dleit fakt, e strata obsahu operanej pamte
nie je okamit. Pri izbovej teplote je obsah me vydra niekoko seknd a mint, v nzkych
teplotch aj niekoko hodn.
Okrem operanej pamte pota obsahuje aj pamte, ktor si svoj obsah zachovvaj aj bez
napjania a slia na uloenie zkladnch programov, ktorch loha je po zapnut potaa
vykona zkladn testy a inicializciu jednotlivch ast potaa a nsledne spusti operan
systm.
Pevn disky v potai slia na trvalejie ukladanie programov a dajov. V sasnosti je vina
pevnch diskov zaloen na princpe ukladania dajov v podobe zmagnetizovanch oblast na
rotujcej kovovej platni. Takto uloen daje vydria dlhodobo bez potreby napjania. Pevn
71
disky s vak pomerne chlostiv zariadenia, ktor mu by ahko pokoden napr. prudkmi
pohybmi potaa poas prevdzky disku. Kee obsahuj pohybujce sa mechanick asti
(napr. platne otajce sa rchlosou od 5000 do 15000 otok za mintu a tacie a zapisovacie
hlavy), asom sa opotrebuj a pokazia. Preto nemono predpoklada, e daje uloen na
pevnom disku vydria neobmedzene dlho. Z bezpenostnho hadiska je tie dleit poveda, e
dokonal vymazanie dajov z pevnho disku je vemi problematick a nemon. Aj po
niekokonsobnom prepsan oblasti pevnho disku je stle mon pomocou pecilnych
prstrojov zrekontruova pvodn obsah.
Rozirujce karty umouj pridva potau aliu funkcionalitu. Typickmi prkladmi mu
by grafick karty umoujce potau vytvra signl pre monitor alebo sieov karty
umoujce pripojenie k potaovej sieti. Dnes je ben, e priamo zkladn doska obsahuje
komponenty, ktor as takej funkcionality poskytuj, preto v dnench potaoch typicky nie je
potrebn poui toko rozirujcich kariet ako v minulosti. Z hadiska funknosti vak nie je
dleit, i je komponent poskytujci rozirujcu funkcionalitu integrovan priamo na zkladnej
doske alebo je na rozirujcej karte. V oboch prpadoch je to zariadenie pripojen k niektorej
zbernici na zkladnej doske.
Niektor potae, typicky notebooky, maj aj zvonku dostupn konektory, do ktorch je mon
za behu pripoji pecilny typ rozirujcej karty (PCMCIA, CardBus, ExpressCard). To
umouje rozirovanie funknosti notebooku, no zrove vytvra zranitenos. Tak karta sa v
konenom dsledku stva zariadenm pripojenm k zbernici, o jej umouje priamo
komunikova napr. s operanou pamou. Je preto mon vyrobi tak kartu, ktor napr. umon
z potaa zska kpiu operanej pamte (vrtane citlivch dajov, ktor sa v nej mu
nachdza).
Prenos dajov z a do zariaden pripojench k zbernici typicky prebieha jednm z troch spsobov:
pomocou na to pecificky urench intrukci procesor posiela a prijma daje do/zo

zariadenia,
procesor zariadenie pouva spsobom, ako keby to bola pam (tzv. pamovo
mapovan zariadenia),
priamym prstupom do pamte (DMA).
Pri prvch dvoch spsoboch sa vdy jedn o prenos medzi zariadenm a procesorom. To je
nevhodn pre prenos vekho mnostva dajov, kedy by procesor mohol vykonva nejak
uitonejiu innos. Tento problm sa odstrauje pomocou priameho prstupu do pamte
(DMA), kedy procesor iba inicializuje prenos, ur na ak miesto v pamti sa maj daje zapsa
alebo odkia sa maj preta, a nsledne sa prenos deje po zbernici bez asti procesora priamo
medzi operanou pamou a zariadenm.
Procesor asto potrebuje reagova na extern udalosti napr. prijatie dajov sieovou kartou zo
siete alebo dokonenie DMA prenosu zo zariadenia do pamte. Aby nebolo potrebn neustle
kontrolova, i nejak extern udalos nastala alebo nie, procesory vyuvaj systm preruen.
Zariadenia pripojen na zbernicu maj monos signalizova procesoru tzv. preruenie. Riadiaca
jednotka procesora medzi vykonvanm intrukci sleduje, i procesor nedostal iados o
preruenie. Ak no, tak pred vykonanm alej intrukcie najprv vykon program, ktor sli na
obsluhu prslunho preruenia.
3.2.2
Operan systm
Operan systm (napr. rzny Windows, Linux, UNIX, ...) predstavuje dleit vrstvu nad
vrstvou hardvru, ktor umouje vym vrstvm pouva pota spsobom, ktor nie je
zvisl od konkrtnych technickch detailov pouitho hardvru. Medzi zkladn lohy
operanho systmu z pohadu funknosti patria:
72
sprva procesov a procesora,

sprva pamte,
sprva sborov,
sprva vstupno-vstupnch a inch zariaden.
Informan systmy plnia svoje lohy vykonvanm programov. Program je vykonvan v rmci
procesu. Procesu mus operan systm prideli as operanej pamte, do ktorej ulo intrukcie
programu, a kde sa tie bud poas vykonvania programu uklada spracovvan daje. Vetky
dnes ben operan systmy umouj z pohadu pouvatea vykonva viacero procesov
sasne tzv. multitasking. V skutonosti neme by naraz vykonvanch viac procesov, ne
m pota procesorov (resp. jadier procesorov). Zdanliv sasn vykonvanie viacerch
procesov sa dosahuje ich rchlym striedanm, ie prideovanm a odoberanm procesora
procesu. Toto prideovanie a odoberanie procesora procesom je sasou sprvy procesov a
procesora, a teda jednou z loh operanho systmu. Operan systm sa tie star o vytvranie a
ruenie procesov.
Operan systm spravuje aj operan pam potaa. Prideuje jednotlivm procesom bloky
pamte, ktor proces me pouva. Vetky dnes ben operan systmy podporuj aj tzv.
virtulnu pam. Operan systm vtedy predstiera, e m k dispozcii viac pamte, ne v
skutonosti operanej pamte v potai je. Procesom prideuje bloky (nazvan strnky)
virtulnej pamte. Obsah strnky me by bu uloen v nejakom bloku skutonej fyzickej
pamte, alebo me by odloen na pevnom disku. Operan systm spravuje tabuku strnok,
ktor uruje, i a kde vo fyzickej pamti sa nachdza prslun strnka. Ke sa proces poksi
pristpi k strnke, ktor sa nenachdza vo fyzickej pamti, procesor vygeneruje preruenie,
operan systm njde von miesto vo fyzickej pamti, nata do obsah poadovanej strnky,
uprav tabuku strnok a vrti vykonvanie sp pvodnmu procesu. Ke sa vo fyzickej pamti
nenachdza von miesto na umiestnenie poadovanej strnky, operan systm nejak in
strnku z fyzickej pamte odstrni (priom jej obsah najprv ulo na disk).
Na dlhodobejie ukladanie dajov slia najastejie pevn disky. Procesy vak s priestorom na
pevnom disku nemanipuluj priamo, ale prostrednctvom sluieb operanho systmu, ktor na
tento el poskytuje abstrakciu na ukladanie dajov, ktor poznme ako sbory. Na hardvrovej
vrstve s daje napokon uloen v blokoch na disku. Operan systm v rmci sprvy sborov
pre kad sbor eviduje, v ktorch blokoch na disku sa nachdzaj jednotliv asti dajov v
sbore, prideuje bloky sboru, ke je potrebn sbor zvi, uvouje bloky pri zmenen
vekosti alebo vymazan sboru. Sbory s najastejie organizovan v hierarchickch
truktrach tzv. adresroch (nazvanch aj prieinky). Adresr me obsahova sbory ako aj
alie adresre. Informcie o mench sborov a adresrov, ako aj ich alie atribty, operan
systm tie uklad vo vhodnch truktrach na disku.
Operan systm tie zabezpeuje sprvu alch zariaden, napr. vstupn a vstupn zariadenia,
pomocou ktorch mu procesy interagova s pouvateom alebo inmi systmami. Pri
multitaskingu je zvyajne potrebn zabezpei, aby so zariadenm nemohli naraz komunikova
viacer procesy. Inak by sa napr. mohlo sta, e pri tlaen na tlaiare by sa pomieali vstupy
rznych procesov. lohou operanho systmu je preto zabezpei prideovanie a odoberanie
prstupu k zariadeniam jednotlivm procesom. asto je tie rieenm vytvorenie abstrakcie
zariadenia akhosi virtulneho zariadenia, ktor mu procesy vone pouva, priom
operan systm zabezpe prenos dajov medzi virtulnym a skutonm zariadenm vo
vhodnom ase. Ako prklad si meme uvies napr. klvesnicu a obrazovku. Operan systm
poskytuje vyej vrstve abstrakciu obrazovky (napr. okno) a abstrakciu klvesnice a zabezpeuje,
e obsah okna sa zobraz na sprvnom mieste skutonej obrazovky, a e vstup zo skutonej
klvesnice sa objav na vstupe virtulnej klvesnice toho procesu, ktorho okno je prve aktvne.
Operan systm sm nie je jednoliatym komponentom, ale sklad sa z mnohch ast. Niektor
z nich s nezvisl od konkrtneho hardvru potaa, na ktorom operan systm be, no in s
pre konkrtny hardvr pecifick. Tie pecifick komponenty, asto nazvan ovldae
73
zariaden, poskytuj zvyku operanho systmu jednotn rozhranie pre urit typ zariadenia.
Napr. sieov karta je zariadenie, ktor umouje odosiela a prijma bloky dajov do/z
potaovej siete. Ale s rznymi sieovmi kartami sa na hardvrovej vrstve komunikuje rznym
spsobom napr. niektor pouva DMA, in pecilne intrukcie. lohou ovldaa sieovej
karty je zvyku operanho systmu poskytn jednotn rozhranie pre zariadenie typu sieov
karta.
Operan systm okrem vyie uvedench loh zohrva aj vznamn lohu pre bezpenos
informanho systmu. Zabezpeuje vzjomn izolciu procesov, aby sa procesy mohli
navzjom ovplyvova len prostrednctvom kontrolovatench mechanizmov. Taktie
zabezpeuje iaston izolciu procesov od hardvru a umouje s hardvrom manipulova len
pomocou sluieb operanho systmu. Vnimkou je sprstupnenie tch ast hardvru, ktorch
pouvanie nem dopad na globlny stav systmu (napr. aplikan procesy priamo vyuvaj
ben intrukcie procesora).
Dleitou bezpenostnou funkciou operanho systmu je aj riadenie prstupu. Veobecnejm
aspektom riadenia prstupu je venovan samostatn kapitola. Pre ely riadenia prstupu
operan systm pre kad proces udriava informciu o pouvateovi, ktor je za tento proces
zodpovedn, ie v mene ktorho tento proces be vykonva opercie. Ke proces vyuva
slubu operanho systmu, ktor podlieha riadeniu prstupu (napr. prstup k sboru alebo k
perifrnemu zariadeniu), operan systm vyhodnot, i pouvate zodpovedn za tento proces
m oprvnenie prslun operciu vykona alebo nie. Riadenie prstupu si vyaduje identifikciu
a autentifikciu pouvateov, o tie patr medzi bezpenostn sluby operanho systmu (viac
o identifikcii a autentifikcii v kapitole o riaden prstupu). Operan systm tie zabezpeuje
vymazvanie zvykovch (rezidulnych) informci, ktor mu zosta v pamti po jej uvonen
inm procesom alebo na disku po zmenen alebo vymazan sboru.
Pre lepiu predstavu o riaden prstupu v operanch systmoch sa pozrieme na prklad dvoch
typov bene pouvanch operanch systmov Windows a Linux/UNIX. V oboch systmoch
je zkladom riadenia prstupu tzv. voliten riadenie prstupu (discretionary access control,
DAC). Kad sbor a adresr (alej objekt) m svojho vlastnka, ktor me nastavova
prstupov prva k objektu. Systmy typu Linux/UNIX rozliuj 3 prva na prstup k objektom
tanie, zpis a spustenie programu/pouitie adresra. Tieto prva mu by pridelen vlastnkovi
objektu, jednej skupine pouvateov a ostatnm. Rozrenie modelu prstupovch prv v Linuxe
znme ako ACL (Access Control Lists) umouje tieto prva prideova aj alm pouvateom
a viacerm skupinm. Systmy Windows maj jemnejie delenie prstupovch prv (umouj
napr. rozli prvo na vytvranie novch sborov a prvo na vytvranie podadresrov, umouj
nastavi prvo na vymazanie objektu, a pod.). Pouvaj tie mechanizmus dedenia prstupovch
prv z adresra na podadresre a sbory a umouj tie urit prvo explicitne zakza. Prva
mu by prideovan pouvateom a skupinm pouvateov. Ak je pouvate lenom
viacerch skupn, zskava prva pridelen vetkm skupinm. Zakazovacie prva maj prednos
pred povoovacmi prvami, ak s pridelen na rovnakej rovni adresrovej truktry. Avak
prva pridelen na rovni bliie k objektu maj vdy prednos pred prvami pridelenmi na
vyej rovni.
Voliten riadenie prstupu v operanch systmoch neumouje chrni daje, ku ktorm m
pouvate prstup, proti neiadcemu prstupu kodlivho kdu zlomysench programov
(alebo programov, ktor sa zlomysenmi stan v dsledku zneuitia nejakej ich zranitenosti
tonkom). Mnoh funkcie operanho systmu s prstupn len pouvateom s
administrtorskmi oprvneniami. Administrtorsk oprvnenia tie zva umouj
jednoducho obs prstupov prva k sborom. Vekm problm nastva, ke sa s oprvneniami
administrtora vykonva kodliv kd, kee takto zskava pln kontrolu nad systmom. Z
tohto dvodu je nevhodn pouva konto s administrtorskmi oprvneniami na ben innosti.
ia, je to pomerne astou zlou praktikou. V novch verzich systmu Windows bol preto
implementovan mechanizmus UAC (User Account Control), ktor ani pouvateovi, ktor je
lenom skupiny administrtorov, tandardne nepriznva administrtorsk oprvnenia, no
74
umouje procesu zska tieto oprvnenia po interaktvnom potvrden autentifikovanho

administrtora.
V Linuxovch systmoch museli by niektor programy vykonvan s administrtorskmi
oprvneniami asto len kvli pr opercim. Aby nebolo nutn im poskytn pln kontrolu nad
systmom, je dnes mon takmto programom explicitne prideli vybran oprvnenia
prostrednctvom tzv. capabilities. Tm je mon zni mnostvo programov, ktor maj pln
kontrolu nad systmom.
Inm spsobom, ako obmedzi mon dopady kodlivho kdu, je pouitie povinnho riadenia
prstupu (mandatory access control, MAC). Pri povinnom riaden prstupu s povolen opercie
uren bezpenostnou politikou, ktor ben pouvatelia a procesy neme modifikova.
Prkladom povinnho riadenia prstupu v systmoch Windows je tzv. Mandatory Integrity
Control (MIC). Tento subsystm umouje prideli objektom a procesom rove integrity a
zabrauje procesom s niou rovou integrity modifikova objekty s vyou rovou integrity.
Takto je mon napr. zabrni tomu, aby chybn webov prehliada ovplyvnen kodlivm
kdom z Internetu prepsal dleit sbory.
V systme Linux je mon na povinn riadenie prstupu vyui jeden z dvoch rozrench
subsystmov SELinux a AppArmor. SELinux umouje priradi procesom a objektom tzv.
typy a definova, ak opercie me proces uritho typu vykona s objektom uritho typu.
Subsystm AppArmor umouje vytvra tzv. profily pre urit programy a v tchto profiloch
obmedzi, k akm sborov a vybranm funkcim operanho systmu m ma prslun proces
prstup. Oba tieto subsystmy umouj vemi presne obmedzi mon dopady kodilvho kdu
vykonanho v rmci uritho procesu.
3.2.3
Databzov systm
V informanch systmoch pracujcich s vm objemom truktrovanch dajov zvyajne

aplikan procesy neukladaj daje priamo do sborov pomocou sluieb operanho systmu, ale
vyuvaj sluby databzovho systmu. Databzov systm poskytuje aplikanej vrstve sluby
na vkladanie, pravu a vyhadvanie v truktrovanch dajoch v databzach. Aplikan
vrstva nemus riei, ako daje efektvne uloi do sborov, ako v nich vedie rchlo vyhadva
a pod., ale len priprav tzv. dotazy v urenom jazyku (najastejie sa pouva jazyk SQL), ktor
odole databzovmu serveru a nsledne si prevezme vsledky. Spsob uloenia dajov je
vntornou zleitosou databzovho systmu.
Databzov systmy zvyajne podporuj tzv. transakn spracovanie. Ke k databze sasne
pristupuje viacero aplikanch procesov, asto potrebujeme, aby kad z nich videl daje v
konzistentnom stave. Problm si meme demontrova na jednoduchom prklade. Majme v
databze tabuku s potom tovarov na sklade a majme aplikciu, ktor spracovva objednvky
zkaznkov tak, e najprv skontroluje, i je na sklade aspo poadovan mnostvo tovaru a, ak
no, poet kusov na sklade prslune zni a potvrd objednvku. Ke bud bea dva takto
aplikan procesy naraz, me sa sta, e oba zistia poet kusov na sklade skr ako ho jeden z
nich zni, a teda oba spene potvrdia objednvky, no poet kusov na sklade sa dostane do
zpornch hodnt (a, samozrejme, tovar na vybavenie objednvky nebude k dispozcii). Tento
prklad je sce umel, no relne problmy s nekonzistenciou dajov v databzach s asto
vrazne horie. Rieenm je prve transakn spracovanie aplikan proces vykon vetky
svisiace opercie ako sas jednej tzv. transakcie a databzov systm zabezpe, e v prpade,
e transakcia spene skon, stav v databze bude konzistentn, a e ak bude transakcia zruen,
stav v databze ou nebude ovplyvnen. V naom prklade by to mohlo dopadn tak, e by
databzov systm zruil transakciu jednho procesu v momente, ke by sa poksil modifikova
daje, ktor mu po tom, ako ich pretal, u stihol modifikova in proces.
Databzov systmy tie zabezpeuj riadenie prstupu k databze a s tm svisiacu identifikciu
a autentifikciu. Vo vzahu k operanmu systmu be databzov systm v mene na ten el
urenho pouvatea (v tomto prpade pouvate nezodpoved skutonej osobe, ide o akhosi
virtulneho pouvatea na ely riadenia prstupu procesov, z ktorch sa sklad databzov
75
systm). Aplikan procesy sa identifikuj a autentifikuj pri vyuvan sluieb databzovho

systmu, a ten nsledne povouje alebo zamieta jednotliv opercie s dajmi v databze.
Riadenie prstupu v databzovch systmoch umouje definova prva na manipulciu s
databzami, tabukami, v niektorch databzovch systmoch dokonca s jednotlivmi stpcami
tabuliek. Tm umouje pomerne presne definova, ak opercie mu jednotliv pouvatelia
vykona s rznymi dajmi.
3.2.4
Virtualizcia, cloud
Spolu s narastajcim vkonom hardvru sa oraz astejie stva, e potae s vyuit len na
zlomok ich kapacity. To zniuje efektivitu ich vyuitia z priestorovho, energetickho aj
finannho hadiska. V sasnosti vemi populrnym (aj ke nie principilne novm) rieenm
tohto problmu je virtualizcia hardvru. Pri virtualizcii sa medzi hardvrov vrstvu a operan
systm vlo virtualizan vrstva (tzv. hypervzor), ktorej lohou je na jednom fyzickom hardvri
simulova niekoko samostatnch potaov. Tmto spsobom je potom mon na jednom
vkonnom fyzickom potai ma niekoko virtulnych potaov, priom kad m svoj
operan systm. Vhodou virtualizcie je u spomenut zvenie efektivity, kee je zvyajne
efektvnejie prevdzkova jeden vkonnej pota ako vea (aj ke o nieo menej vkonnch)
potaov. Taktie je vhodou, e ke potrebujeme nasadi nov pota, nie je potrebn kpi a
sprevdzkova nov hardvr, ale meme vyui von kapacitu existujceho. Vytvorenie
novho virtulneho potaa je zleitos pr seknd a mint prce administrtora.
S virtualizciou svis aj dnes populrny pojem cloud. Cloudov sluby nm umouj objedna
si virtulny pota (prpadne cel sie virtulnych potaov) ako slubu prevdzkovatea
cloudu. Pri vyuvan cloudovch sluieb je vak potrebn si uvedomi potencilne bezpenostn
rizik spojen s tm, e nae daje bud uloen a spracovvan v prostred, nad ktorm nemme
kontrolu.
3.2.5
Model klient-server
Informan systmy, ktor umouj sasn prcu viacerm pouvateom s zvyajne

postaven na modeli klient-server. Zkladnou mylienkou tohto modelu je centrlne spracovanie
dajov asou informanho systmu nazvanou server, priom komunikciu medzi tmto
serverom a pouvatemi sprostredkovvaj alie asti informanho systmu, ktor sa
nazvaj klienti. Server je prevdzkovan na jednom potai a klienti s prevdzkovan na inch
potaoch, pri ktorch sedia pouvatelia. Klienti a server navzjom komunikuj
prostrednctvom potaovej siete.
Klientov rozdeujeme na dva zkladn typy tzv. tenk klienti a hrub klienti. Hrub klient je pre
informan systm pecifick program beiaci na pouvateovom potai, ktor zabezpeuje
vstup a vstup dajov, ako aj predben alebo nsledn spracovanie pred/po prenesen dajov na
server. Tenk klient je program beiaci na pouvateovom potai, ktor zabezpeuje v zsade
len vstup a vstup dajov bez nejakho podstatnho spracovania. Ako tenk klient sa v
sasnosti najastejie pouva ben webov prehliada. To m vek vhodu v tom, e nie je
potrebn na pouvateov pota intalova iadny pecilny program, vaka omu nie je ani
dleit, ak operan systm je na pouvateovom potai pouit. Taktie je asto mon
vyui to, e webov prehliada je dnes benou sasou aj inch zariaden ako bench
potaov napr. tabletov, inteligentnch mobilnch telefnov, televzorov a pod. Vaka tomu je
mon s takmto informanm systmom pracova z vekho mnostva rznych zariaden.
Z hadiska bezpenosti je dleit skutonos, e bezpenostn funkcie ako napr. riadenie
prstupu, autentifikcia a pod. musia by realizovan na serveri. Ak by boli realizovan len na
klientovi, nebolo by mon vyli, aby tonk jednoducho pouil vlastnho upravenho klienta
a realizoval tak nepovolen opercie.
76
3.2.6
Bezpenostn funkcie vrstiev
Bezpenos informanho systmu je komplexn zleitos. Odhliadnime vak teraz od prvnych

a organizanch aspektov a pozrime sa bliie na technick otzky tkajce sa toho, v ktorch
vrstvch je mon realizova bezpenostn funkcie a mechanizmy, a ak predpoklady na to
musia by splnen.
Ak je nejak bezpenostn funkcia implementovan na uritej vrstve, me inne poskytova
ochranu len proti tokom, ktor s veden na tejto alebo vyej vrstve. Ke napr. na aplikanej
vrstve implementujeme riadenie prstupu k dajom, tak toto me by inn len proti tokom na
aplikanej vrstve. Ak by toti tonk zskal prstup k systmu napr. na vrstve operanho
systmu, tak me vyui rovnak sluby operanho systmu, ak vyuva aj prslun
aplikcia, a zska prstup k sborom s dajmi bez toho, aby pouil akkovek slubu aplikcie.
Analogicky, ak tonk zska prstup k dajom na rovni hardvru (napr. ukradne pevn disk z
potaa), bez akchkovek problmov me obs riadenie prstupu implementovan v
operanom systme. Jedinou iastonou vnimkou je pouitie kryptografickch prostriedkov
napr. daje zaifrovan na aplikanej vrstve mu by pred naruenm dvernosti inne
chrnen aj proti niektorm tokom napr. na vrstve hardvru.
Vo veobecnosti meme poveda, e nevyhnutnmi predpokladmi pre inn implementciu
bezpenostnch funkci s:
bezpenostn funkciu neme by mon obs teda tonk napr. nesmie ma

monos vyui sluby niej vrstvy na zskanie prstupu k dajom,
implementcia bezpenostnej funkcie mus by chrnen proti neoprvnenej zmene, aby
ju tonk nemohol pozmeni tak, aby mu umonila vykona poadovan opercie,
daje, ktor bezpenostn funkcia pouva na rozhodovanie, musia by chrnen proti
neoprvnenej zmene napr. tonk nesmie ma monos zmeni daje obsahujce
informciu o prstupovch prvach alebo heslo,
dvern daje, ktor bezpenostn funkcia pouva, musia by chrnen aj proti
prezradeniu napr. tonk nesmie ma monos zisti hesl, ktor sa pouvaj na
autentifikciu.
Berc do vahy vyie uveden predpoklady, pozrime sa teraz podrobnejie na typick

bezpenostn funkcie jednotlivch vrstiev. Aplikan vrstva typicky zabezpeuje riadenie
prstupu k funkcim a dajom informanho systmu pre pouvateov aplikcie. Kee
aplikan vrstva je pecifick pre konkrtny informan systm, nie je tu problm zohadni
smantiku, ie vznam, jednotlivch dajov a aplikanch funkci. V prpade pouitia modelu
klient-server aplikan vrstva (presnejie server) me inne zabezpei ochranu dajov proti
tonkovi vyuvajcemu sluby aplikanej vrstvy a izolova ho od monosti poui sluby
niej vrstvy. Neme vak efektvne zabezpei vlastn ochranu ani ochranu proti tonkovi,
ktor m monos priamo vyui sluby nich vrstiev (pretoe tu nie je splnen napr.
predpoklad, e bezpenostn funkciu nie je mon obs). Pokia sa jedn jednoduch aplikciu
(bez pouitia modelu klient-server), je asto problematick zabezpei, aby pouvate aplikcie
nemal monos pristupova aj k slubm operanho systmu.
Dleitou lohou operanho systmu je zabezpei ochranu aplikanej vrstvy (a teda aj jej
bezpenostnch funkci) pred neoprvnenou zmenou, ako aj zabezpei ochranu dajov
aplikanej vrstvy proti neoprvnenmu prstupu inou cestou ako prostrednctvom aplikanej
vrstvy. Tm operan systm vytvra predpoklady pre inn implementciu bezpenostnch
funkci na aplikanej vrstve. Ako sme u spomenuli v asti o operanom systme, na naplnenie
tchto loh operanho systmu sa vyuvaj najm izolcia procesov a riadenie prstupu. Op
vak plat, e operan systm doke poskytova ochranu proti tonkovi, ktor vyuva sluby
operanho systmu, no nedoke efektvne poskytova ochranu proti tonkovi, ktor m
monos vyui priamo sluby hardvru. S vhodnou podporou od hardvru vak operan systm
izoluje procesy od priameho prstupu k hardvru, m ponechva tonkovi jedin cestu na
priamu manipulciu s hardvrom, a to fyzick prstup alebo zsah do hardvru. Ke odhliadneme
77
od fyzickho prstupu, tak vaka izolcii procesov od hardvru operan systm me inne
chrni aj vlastn implementciu a vlastn daje, ktor jeho bezpenostn funkcie vyuvaj.
Bez potrebnej podpory zo strany hardvru by bol problm naplni predpoklady na inn
implementciu bezpenostnch funkci v operanom systme. Dnen hardvr vak poskytuje
niekoko bezpenostnch funkci, ktor tieto predpoklady umouj operanmu systmu splni.
Zkladnmi bezpenostnmi funkciami hardvru s:
riadenie prstupu do pamte,

riadenie prstupu k zariadeniam,
obmedzenie prstupu k privilegovanm intrukcim.
Intrukcie procesora, ktor maj vplyv na systm ako celok (napr. zakazovanie preruen,
manipulcia s bezpenostnmi mechanizmami hardvru, a pod.), sa nazvaj privilegovan
intrukcie. Hardvr umouje privilegovan intrukcie vykonva len operanmu systmu (a
prpadne operanm systmom urenm procesom), no nie benm procesom.
Hardvr tie poskytuje operanmu systmu prostriedky na urenie toho, do ktorch ast pamte
mu jednotliv procesy pristupova. Taktie umouje operanmu systmu uri, e len
operan systm alebo prpadne pecilne uren procesy mu manipulova so zariadeniami.
Vaka tomu si operan systm me ponecha kontrolu nad zariadeniami a celkovm stavom
systmu a inne zabrni procesom, aby mohli obs bezpenostn funkcie operanho systmu.
Jednm z typickch mechanizmov, ktor bva v hardvri na realizciu spomenutch funkci
pouit s tzv. bezpenostn okruhy (security rings). Hardvr definuje niekoko (typicky 2 a 4)
okruhov, v rmci ktorch sa mu vykonva programy (ie postupnosti intrukci). Vntorn
okruh m monos vykonva vetky intrukcie (teda aj privilegovan) a smerom k vonkajm
okruhom pribdaj obmedzenia. Vonkaj okruh typicky uren pre ben programy na
aplikanej rovni neumouje vykonvanie iadnych privilegovanch intrukci. Vntorn
okruh je uren pre operan systm (resp. pre tzv. jadro operanho systmu). Okruhy medzi
vntornm a vonkajm (ak s podporovan) mu by vyuit napr. pre ovldae zariaden v
operanom systme.
alm mechanizmom, sliacim na riadenie prstupu do pamte je strnkovanie. Strnkovanie
sme u spomenuli v svislosti s virtulnou pamou, no m aj lohy v bezpenosti. Hardvr
umouje operanmu systmu udriava samostatn tabuky strnok pre jednotliv procesy a
definova, i program vo vonkajom okruhu me k jednotlivm strnkam pristupova a ako
(tanie, zpis, vykonvanie intrukci). Vaka tomu me operan systm oddeli pam
prstupn jednotlivm procesom a zabezpei tak ich vzjomn izolciu. Zrove tak me
ochrni vlastn daje pred prstupom procesov.
Prstup k zariadeniam bva rieen bu tak, e je definovan, ktor okruh m a ktor u nie
prstup k hardvru, alebo procesor umouje operanmu systmu definova presne, ktor proces
me k jednotlivm zariadeniam pristupova. Vaka tomu me operan systm izolova
procesy od priamej manipulcie napr. s pevnm diskom, grafickou kartou a pod.
iadny z uvedench mechanizmov vak nedoke zabrni manipulcii s hardvrom tonkom,
ktor m fyzick prstup k hardvru (teda ktor me napr. vybra pevn disk z potaa). Tu
zohrva dleit lohu fyzick bezpenos, ktorej je venovan samostatn kapitola. Ak je aj mlo
pravdepodobn, e neoprvnen osoba pota rozoberie, stle vak zostva niekoko problmov,
na ktor je potrebn myslie. Ako sme spomenuli v asti venovanej hardvru, mnoh potae
maj monos rozirova funkcionalitu hardvru aj bez rozoberania a dokonca bez vypnutia.
Typick prkladom s spomenut rozirujce karty pre notebooky (CardBus, ExpressCard).
Zasunutm vhodnej karty tonk zska prstup priamo na zbernicu a me napr. pristupova do
operanej pamte bez vedomia operanho systmu. alm znmym problmom je rozhranie
FireWire (znme tie ako IEEE 1394). Hoci sa najastejie pouva na pripjanie externch
zariaden ako napr. digitlne kamery, v skutonosti, na rozdiel od USB, sa jedn o rozhranie typu
zbernica. Jeho prostrednctvom je mon napr. vykonva aj DMA prenosy, a teda tie zska
78
prstup do operanej pamte bez vedomia operanho systmu. Preto je vhodn toto rozhranie
zablokova (ak nie je potrebn) alebo venova zven pozornos fyzickej bezpenosti.
3.3 Hodnotenie systmov

Pre posudzovanie a porovnvanie bezpenostnch vlastnost a zruk informanch systmov a
ich komponentov je vhodn poui tandardizovan prstup. V sasnosti najpouvanejm
tandardom pre popisovanie bezpenostnch poiadaviek na IT produkty je medzinrodn norma
ISO/IEC 15408, znma tie ako Common Criteria.
V roku 1990 zaala medzinrodn tandardizan organizcia ISO prce na vytvoren
medzinrodnej normy, ktor by stanovila kritria na hodnotenie bezpenosti informanch
systmov. V roku 1993 organizcie zastreujce vvoj takchto kritri v Kanade, USA,
Nemecku, Franczsku, Holandsku a Spojenom krovstve spojili svoje aktivity na vytvorenie
spolonch kritri. Cieom projektu, nazvanho Common Criteria (Spolon kritria), bolo
zjednoti jednotliv dovtedy pouvan kritria (najm TCSEC a ITSEC) a poskytn ich ako
prspevok k aktivitm ISO. V roku 1996 vznikla verzia 1.0, ktor bola akceptovan ako nvrh
ISO/IEC tandardu. Po niekokoronom procese pripomienkovania a upravovania vznikla v roku
1998 verzia 2.0, ktor bola s drobnmi pravami v jni 1999 schvlen ako normy ISO/IEC
15408-1:1999, 15408-2:1999 a 15408-3:1999. Aktualizovan verzia 2.3 bola neskr schvlen
ako ISO/IEC 15408-1:2005, 15408-2:2005 a 15408-3:2005. V sasnosti je aktulna verzia 3.1 a
na nej zaloen normy ISO/IEC 15408-1:2009, 15408-2:2008 a 15408-3:2008. alej budeme
tto normu oznaova ako CC.
CC rozdeuje bezpenostn poiadavky na dva typy funkn bezpenostn poiadavky a poiadavky na bezpenostn zruky. Funkn bezpenostn poiadavky slia na definovanie
poadovanch bezpenostnch funkci, ktor m produkt realizova. Poiadavky na
bezpenostn zruky slia na definovanie poiadaviek na postupy pri vvoji, dodvke a
prevdzke produktu, ktorch cieom je zaisti, e produkt spa definovan funkn poiadavky.
CC definuje truktrovan katalg funknch bezpenostnch poiadaviek a poiadaviek na
bezpenostn zruky. Elementy (jednoduch poiadavky) s zoskupen do komponentov, ktor
pokrvaj urit bezpenostn ciele. Komponenty s zkladnm prvkom, ktor sa me poui v
pecifikcich poiadaviek. Komponenty, ktor pokrvaj rovnak bezpenostn ciele tvoria
rodinu (family). V rmci rodiny niektor komponenty mu tvori hierarchiu. Rodiny, ktor
pokrvaj zko svisiace oblasti, tvoria triedu (class). CC definuje 11 tried funknch
bezpenostnch poiadaviek, 6 tried poiadaviek na bezpenostn zruky a dve triedy
poiadaviek na hodnotenie. CC definuje sedem rovn hodnotenia systmov a produktov,
nazvanch EAL (Evaluation Assurance Level), ktor s definovan pomocou jednotlivch
komponentov poiadaviek na bezpenostn zruky. CC teda zakladaj rovne hodnotenia na
poiadavkch na bezpenostn zruky. rove EAL1 je najniia, rove EAL7 je najvyia.
CC definuj dva zkladn typy dokumentov -- profil ochrany (Protection Profile, alej len PP) a
bezpenostn zmer produktu alebo systmu (Security Target, alej len ST). PP aj ST s
truktrovan dokumenty, ktorch truktra je uren CC.
PP predstavuje shrn bezpenostnch poiadaviek vo forme komponentov z CC a prpadne
alch poiadaviek. elom PP je definova poiadavky pre urit typ systmov alebo IT
produktov (napr. operan systm, kryptografick karta), ktor maj splni uren bezpenostn
ciele. Sasou PP je aj zdvodnenie bezpenostnch cieov a bezpenostnch poiadaviek,
ktormi sa maj bezpenostn ciele naplni. PP by mal zaha aj niektor EAL.
ST predstavuje shrn bezpenostnch poiadaviek uvedench odkazom na PP, CC alebo
uvedench explicitne. ST pecifikuje poiadavky na konkrtny systm alebo IT produkt, ktor
napaj uveden bezpenostn ciele. Sasou ST je popis produktu/systmu a zdvodnenie
bezpenostnch cieov a poiadaviek.
79
Na jednotliv komponenty uveden v katalgu CC sa aplikuj opercie, ktormi sa dopaj

rzne parametre, vyberaj monosti, spresuj deklarcie uveden v komponente. Taktie je
asto mon komponent iterova poui viacnsobne s rznymi parametrami. Tieto opercie
mu by plne alebo iastone vykonan v PP a tie opercie, ktor s komponentom
vyadovan, musia by vykonan v ST.
CC definuje tri typy vyhodnocovania:
vyhodnocovanie PP,
vyhodnocovanie ST,
vyhodnocovanie systmu/produktu.
Cieom vyhodnocovania PP je ukza, e sa jedn o pln, konzistentn, technicky zmyslupln

sbor poiadaviek, ktor je pouiten pre vyhodnocovan systm/produkt.
Cieom vyhodnocovania ST je ukza, e sa jedn o pln, konzistentn, technicky zmyslupln
sbor poiadaviek pouiten pre hodnotenie danho systmu alebo produktu. Ak ST deklaruje
zhodu s nejakm PP, je sasou vyhodnocovania aj preukzanie tejto skutonosti.
Cieom vyhodnocovania systmu alebo produktu je ukza, e tento spa bezpenostn
poiadavky uveden v prslunom ST.
3.3.1
Funkn bezpenostn poiadavky
Cieom tejto asti je predstavi jednotliv triedy funknch bezpenostnch poiadaviek

definovanch v CC, konkrtne v ISO/IEC 15408-2:2008.
Bezpenostn audit (FAU Security audit)
Bezpenostn audit zaha rozpoznvanie, zaznamenvanie, ukladanie a analzu informci,
ktor maj vzah k bezpenostne relevantnm innostiam, t.j. k innostiam, ktor s riaden
bezpenostnou politikou. Zznamy auditu umouj uri, ak bezpenostne relevantn innosti
sa udiali a kto (ak subjekt) je za ne zodpovedn.
Komunikcia (FCO Communication)
Tto trieda poiadaviek obsahuje dve rodiny, ktorch cieom je bezpene identifikova
astnkov komunikcie. Jedna rodina definuje poiadavky na identifikciu odosielatea
informcie (dkaz o pvode), druh na identifikciu prijmatea informcie (dkaz o prijat).
Tieto rodiny zabezpeuj. e odosielate neme poprie odoslanie informcie a prijmate
neme poprie jej prijatie.
Kryptografick podpora (FCS Cryptographic support)
Bezpenostn funkcie systmu mu, zvyajne na dosiahnutie nronejch bezpenostnch
cieov, vyuva kryptografick prostriedky. Vyuvaj sa naprklad na zabezpeenie vyej
rovne identifikcie a autentifikcie, na ochranu dvernosti dajov -- ifrovanie, autentickosti -digitlne podpisy, a alie ely.
Ochrana pouvateskch dajov (FDP User data protection)
Tto trieda poiadaviek pecifikuje poiadavky na bezpenostn funkcie a politiky tkajce sa
ochrany pouvateskch dt. Je rozdelen na tyri asti:
Politiky bezpenostnch funkci na ochranu pouvateskch dt
80
Politika riadenia prstupu

Politika riadenia toku informci
V rmci tchto rodn sa definuj a pomenuj rzne politiky bezpenostnch funkci riadiacich
prstup k polokm systmu a toku informci a ich rmec psobnosti. Na tieto politiky sa potom
odvolvaj poiadavky na bezpenostn funkcie, ktor ich dodriavanie zabezpeuj a
kontroluj.
Spsoby ochrany pouvateskch dt
Funkcie na riadenie prstupu

Funkcie na riadenie toku informci
Vntorn prenosy
Ochrana zvykovch informci
Rollback (vrtenie systmu do predchdzajceho konzistentnho stavu)
Integrita uloench dt
Off-line ukladanie dt, import a export
Autentickos dt
Export dt mimo rmec psobnosti bezpenostnch funkci
Import dt z mimo rmca psobnosti bezpenostnch funkci
Tieto rodiny poiadaviek sa zaoberaj dveryhodnosou dt, ktor sa prenaj medzi systmom
a inmi systmami mimo psobnosti bezpenostnch funkci.
Komunikcia medzi dveryhodnmi systmami
Dvernos pouvateskch dt pri prenosoch medzi dveryhodnmi systmami

Integrita pouvateskch dt pri prenosoch medzi dveryhodnmi systmami
Tieto rodiny sa zameriavaj na zabezpeenie komunikcie medzi dvoma dveryhodnmi

systmami.
Identifikcia a autentifikcia (FIA Identification and authentication)
Rodiny poiadaviek v tejto triede sa zameriavaj na funkcie na zistenie a overenie identity
pouvatea. Identifikcia (zistenie identity) a autentifikcia (overenie identity) s zkladom pre
priradenie sprvnych bezpenostnch atribtov pouvateom. S nevyhnutnm predpokladom
na to, aby systm mohol presadzova bezpenostn politiky. Mnoh triedy poiadaviek s zvisl
na sprvnej identifikcii a autentifikcii pouvateov.
Sprva bezpenosti (FMT Security management)
Tto trieda m niekoko cieov:
sprva dt bezpenostnch funkci,

sprva bezpenostnch atribtov (napr. zoznamy prstupovch prv),
sprva bezpenostnch funkci (napr. vber funkci a nastavovanie ich parametrov),
definovanie bezpenostnch rl.
Ochrana skromia (FPR Privacy)

Tto trieda obsahuje rodiny poiadaviek, ktorch cieom je poskytn pouvateom ochranu
proti zisteniu a zneuitiu ich identity inmi pouvatemi.
Ochrana bezpenostnch funkci (FPT Protection of security functions)
Tto trieda poiadaviek obsahuje rodiny poiadaviek, ktorch cieom je chrni bezpenostn
funkcie a ich dta. V istom zmysle s tieto poiadavky podobn poiadavkm na ochranu
pouvateskch dt a asto sa aj realizuj podobnmi alebo aj rovnakmi prostriedkami. Avak
81
zatia o poiadavky na ochranu pouvateskch dt sleduj ochranu pouvateskch dt,

poiadavky tejto triedy maj za lohu zabezpei, e nie je mon obs alebo neautorizovane
upravova bezpenostn politiku, ktor bezpenostn funkcie vynucuj a kontroluj. Bez
adekvtnej ochrany bezpenostnch funkci a ich dt nie je mon bezpen fungovanie systmu
zaisti. Naprklad, ak je mon neautorizovane meni hesl, nem zmysel pouva autentifikciu
zaloen na znalosti hesiel. Ak je mon neautorizovane zmeni implementciu bezpenostnch
funkci, je mon ich zmeni tak, e povolia innosti v rozpore s prslunou politikou. Ochrana
bezpenostnch funkci sa tka troch vznamnch oblast:
implementcia bezpenostnch funkci, ktor pracuje na abstraktnom potai a

implementuje mechanizmy, ktormi sa vynucuje a kontroluje bezpenostn politika,
dta bezpenostnch funkci, ktor riadia sprvanie bezpenostnch funkci,
extern entity, s ktormi komunikuj bezpenostn funkcie.
Vyuvanie zdrojov (FRU Resource utilisation)

Tto trieda poiadaviek sa zameriava na kontrolu vyuvania zdieanch zdrojov systmu.
Obsahuje poiadavky na monos obmedzi maximlne mnostv systmovch zdrojov (napr.
procesorov as, pam, diskov priestor) spotrebovanch subjektom. Taktie obsahuje
poiadavky na pecifikciu priority subjektov, ktor sa vyuva pri rozhodovan o priraden
systmovch zdrojov. Obsahuje aj poiadavky na zachovanie funknosti systmu pri niektorch
zlyhaniach (napr. pri chybe jednho disku).
Prstup k systmu (FTA Access)
Poiadavky tejto triedy sa zaoberaj otzkami obmedzen prstupu pouvateov k systmu.
Obsahuj poiadavky na zobrazovanie informci pred prihlsenm pouvatea, poiadavky na
vedenie histrie prstupov a informovanie pouvatea o poslednom spenom prihlsen, pote a
poslednom nespenom pokuse o prihlsenie. Tie obsahuje poiadavky na monos obmedzi
prihlsenie na zklade uritch bezpenostnch atribtov. Zaober sa tie monosou uzamknutia
interaktvneho prstupu pouvateom (napr. pri doasnom opusten pracovnej stanice) alebo po
uritom ase neaktivity pouvatea.
Dveryhodn cesta a kanl (FTP Trusted path/channel)
Tto trieda poiadaviek obsahuje rodiny zameran na existenciu a vyuvanie dveryhodnch
komunikanch kanlov medzi bezpenostnmi funkciami a inmi dveryhodnmi systmami a
dveryhodnch komunikanch ciest medzi bezpenostnmi funkciami a pouvatemi.
3.3.2
Poiadavky na bezpenostn zruky
V tejto asti si predstavme triedy poiadaviek na bezpenostn zruky.

Vvoj (ADV Development)
Poiadavky tejto triedy poskytuj informcie o produkte, ktor s zkladom pre testovanie a
hadanie zranitenost. Tto trieda obsahuje poiadavky na popis produktu na rznych rovniach
abstrakcie od pecifikcie cez nvrh a po implementciu. Sasou s aj poiadavky na popis
bezpenostnho modelu a jeho korepondencie s bezpenostnmi funkciami.
Dokumentcia (AGV Guidance documents)
Trieda AGV definuje poiadavky na rozsah, zrozumitenos a plnos dokumentcie, ktor
poskytuje tvorca systmu. Dokumentcia sa del na dokumentciu pre prpravu systmu
(intalcia, konfigurcia, ...) a dokumentciu pre prevdzku (pre vetky role pouvatelia,
administrtori, ...) a je dleitm predpokladom bezpenej prevdzky systmu.
Podpora v priebehu ivotnho cyklu (ALC Life cycle support)
Trieda ALC definuje poiadavky na zruky prostrednctvom pouitia dobre definovanho modelu
celoivotnho cyklu systmu pokrvajceho vetky etapy vvoja systmu. Zaha politiky a
82
procedry odstraovania zistench nedostatkov, korektn pouvanie nstrojov a technk a

bezpenostn opatrenia na ochranu vvojovho prostredia. Definuje poiadavky na manament
konfigurcie (IT systmu) s cieom zaisti zachovanie integrity systmu. Vyaduje disciplnu a
riadenie procesov prav a modifikcie systmu a informci svisiacich so systmom (napr.
dokumentcie.) Manament konfigurcie zabrauje neoprvnenm modifikcim (pridvaniu
alebo odoberaniu ast, komponentov, dajov a pod.) systmu a poskytuje zruku, e IT systm je
v stave deklarovanom jeho dokumentciou. Sasou tejto triedy s aj poiadavky na opatrenia,
procedry a tandardy tkajce sa bezpenho doruenia systmu k odberateovi.
Testy (ATE Tests)
Trieda ATE stanovuje poiadavky na testovanie, ktor m demontrova, e bezpenostn
funkcie systmu spaj bezpenostn funkcionlne poiadavky systmu.
Posdenie zranitenost (AVA Vulnerability assessment)
Trieda AVA definuje poiadavky zameran na identifikciu vyuitench slabch miest systmu.
Zaober sa slabmi miestami, ktor vznikaj pri kontrukcii, prevdzke, zneuit alebo
nesprvnej konfigurcii systmu.
Skladanie (ACO Composition)
Trieda ACO definuje poiadavky uren na bezpen skladanie systmov z podsystmov, ktor
boli vyhodnoten poda CC. Cieom je zaisti, aby zloen systm, ktor sa spolieha na
bezpenos subsystmov, pracoval bezpene.
3.3.3
Poiadavky na vyhodnocovanie PP a ST
CC definuje dve triedy poiadaviek na vyhodnocovanie PP a ST:

Hodnotenie Protection Profile (APE Protection Profile evaluation)
Tto trieda definuje poiadavky na vytvranie, obsah a hodnotenie PP. Cieom je zabezpei, e
PP je vntorne konzistentn, zmyslupln a je pouiten ako zklad pre ST alebo al
(komplexnej) PP.
Hodnotenie bezpenostnho zmeru (ASE Security Target evaluation)
Tto trieda definuje poiadavky na vytvranie, obsah a hodnotenie ST. Cieom je zabezpei, e
ST je vntorne konzistentn, zmyslupln a je v slade s deklarovanm PP.
3.3.4
rovne hodnotenia (EAL)
CC definuje spomenutch 7 rovn hodnotenia EAL. Jednotliv rovne sa lia poiadavkami

na bezpenostn zruky. Vyie rovne poskytuj vyiu mieru dvery v to, e systm spa
funkn bezpenostn poiadavky definovan v prslunom ST.
EAL1 -- funkne testovan
Vyhodnotenie na tejto rovni poskytuje dkaz, e systm alebo produkt funguje v slade s
dokumentciou. Tto rove je vhodn, ak je vyadovan urit miera dvery v sprvne
fungovanie systmu alebo produktu, ale hrozby nie s povaovan za vne. Uiton je, ak je
poadovan nezvisl uistenie, e bola venovan dostaton pozornos ochrane osobnch alebo
podobnch dajov. EAL1 poskytuje zkladn rove zruk na zklade nezvislho testovanie
oproti pecifikcii a preskmania dokumentcie.
EAL2 -- trukturlne testovan
Vyhodnotenie na rovni EAL2 vyaduje zkladn spoluprcu s vvojrom systmu/produktu v
podobe predloenia nvrhovej dokumentcie a vsledkov testovania. Nad rmec EAL1 sa
vyaduje predloenie dkazov testovania vvojrmi na zklade funknej pecifikcie, ako aj
hadania zranitenost. Vyaduje sa preukzanie odolnosti voi tonkom so zkladnm
83
tonm potencilom. Vyaduje sa bezpen spsob distribcie systmu/produktu a sprva

konfigurci v procese vvoja.
EAL3 -- metodicky testovan a kontrolovan
EAL3 umouje vvojrom dosiahnu maximlne zruky z vvoja so zohadnenm poiadaviek
na bezpenos na rovni nvrhu bez vnych zsahov do dobrch praktk softvrovho
ininierstva. Nad rmec EAL2 sa vyaduje, aby testovanie systmu/produktu vvojrmi bolo
zaloen nielen na jeho funknej pecifikcii, ale aj na nvrhu. Vyaduje sa kompletnejie
pokrytie testovania a postupy, ktor poskytuj zkladn dveru, e s produktom nebolo
neoprvnene manipulovan poas vvoja.
EAL4 -- metodicky navrhnut, testovan a kontrolovan
EAL4 je asi najvyia rove, ktor je mon dosiahnu kvalitnmi praktikami softvrovho
ininierstva bez pecilnych znalost a sksenost v oblasti bezpenosti. Pri vyhodnocovan na
tejto rovni sa nad rmec EAL3 analyzuje kompletn pecifikcia rozhran, zkladn modulrny
nvrh a vybran asti implementcie systmu/produktu. Analza zranitenost mus ukza, e
systm/produkt je odoln voi napadnutiu tonkom s rozrenm tonm potencilom.
EAL5 -- semiformlne navrhnut a testovan
Pri vyhodnocovan na rovni EAL5 sa analyzuje cel implementcia bezpenostnch funkci,
poaduje sa semiformlna prezentcia nvrhu systmu/produktu a truktrovan architektra.
Vyaduje sa modulrny nvrh systmu/produktu. Nezvisl analza zranitenost mus preukza
odolnos systmu/produktu voi tonkovi so strednm tonm potencilom.
EAL6 -- semiformlne overen nvrh a testovan
Nad rmec EAL5 sa vyaduje truktrovan prezentcia implementcie, semiformlna
prezentcia funknej pecifikcie a nvrhu, a formlny model vybranch bezpenostnch funkci.
Vyaduje sa vrstvov nvrh systmu/produktu. Nezvisl analza zranitenost mus preukza
odolnos voi tonkovi s vysokm tonm potencilom. Vyaduje sa truktrovan proces
vvoja.
EAL7 -- formlne overen nvrh a testovan
Na rovni EAL7 sa poaduje formlna prezentcia funknej pecifikcie a nvrhu. Nvrh
systmu/produktu mus by dostatone jednoduch, aby bolo mon ho dkladne preskma.
Vyaduje sa kompletn nezvisl testovanie, formlne preskmanie zhody rznych rovn
reprezentcie produktu a pod.
3.3.5
Vznam a rizik hodnotenia produktov poda CC
Vyhodnotenie nejakho IT produktu alebo systmu poda CC me by prnosom v zmysle

vyej dvery v rove bezpenosti. Je vak potrebn si uvedomi, o vsledok vyhodnotenia v
skutonosti znamen. Mnoh dodvatelia toti vyuvaj vyhodnotenie svojich produktov ako
marketingov ah. Nedostatone znal odberate potom ahko podahne ilzii, e ke dan
produkt bol vyhodnoten na rovni EAL4, tak to zabezpe vysok rove bezpenosti.
Problmom je, e akkovek rove sa viae k naplneniu poiadaviek pecifikovanch v
nejakom PP alebo ST. Dleitou sasou PP je definovanie predpokladov o prostred a
identifikcia hrozieb, voi ktorm maj bezpenostn funkcie produktu poskytova ochranu. A
kovou otzkou pre praktick vznam vyhodnotenia nejakho IT produktu preto je, i s
predpoklady v danom konkrtnom prostred splnen a i vetky skutone relevantn hrozby boli
zohadnen. Ak toti nasadme vyhodnoten produkt do prostredia, ktor nespa predpoklady, je
vemi pravdepodobn, e bezpenostn funkcie produktu bud nedostaton, a to napriek tomu,
e produkt mohol by spene vyhodnoten na niektorej z vych rovn (napr. EAL4). Tie je
dleit si uvedomi, e produkty s asto vyhodnoten v uritej konfigurcii a pouitie inej
konfigurcie me ma zsadn vplyv na ich bezpenostn vlastnosti. Samotn tvrdenie, e dan
produkt bol vyhodnoten (i dokonca certifikovan) na nejakej rovni EAL, preto nem vek
praktick vznam a me by naozaj aj len marketingovm ahom. A preskmanie prslunho
84
PP a ST a overenie splnenia predpokladov nm me prinies dveru v to, e produkt bude ma

potrebn bezpenostn vlastnosti aj v naom konkrtnom prostred.
85
4 Riadenie prstupu
Ivan Kopik
4.1
vod
Tto kapitola je venovan riadeniu prstupu. Riadenie prstupu je samostatn okruh informanej
bezpenosti, ktor podporuje a ovplyvuje viacer alie okruhy informanej bezpenosti (napr.
bezpenos potaovch siet, aplikan bezpenos, fyzick a objektov bezpenos).
Pod riadenm prstupu do IKT chpeme prideovanie a spravovanie oprvnen pre narbanie
s potaovmi zdrojmi (dtami, aplikciami, sbormi at.). Zvyajne sa jedn o technick
privilgi ako naprklad oprvnenie vytvra, ta, modifikova alebo maza sbory, spa
vybran programy alebo vytvra spojenia v potaovej sieti. Prstup k potaovm
informanm zdrojom me by riaden a kontrolovan na fyzickej aj na logickej rovni.
Riadenie prstupu na fyzickej rovni vymedzuje monosti vstupu osb do (a vstupu z nich)
budov, serverovn, vpotovho strediska, kancelri alebo inch priestorov, v ktorch sa fyzicky
nachdzaj IKT komponenty (servery, PC, tlaiarne a pod.). V praxi sa vyuva viacero
prostriedkov na podporu riadenia fyzickho prstupu ako napr. nvtevncke karty, identifikan
(ID) karty zamestnancov, ke, biometrick systmy.
Riadenie prstupu na logickej rovni predstavuje prideovanie a kontrolovanie prstupu
k logickm komponentom a zdrojom (aplikcie, transakcie, dta, sluby internetu a pod.)
a aplikuje sa vdy, ke sa predmetn zdroj m poui. Na zklade urenia a overenia identity
pouvatea, ktor poiadal o prstup k danmu zdroju (napr. poksil sa otvori sbor),
bezpenostnch parametrov zdroja a nastaven pouvateskho profilu systm rozhodne, i
poadovan prstup bude umonen. Tmto spsobom sa vymedz, ktor sbory pouvate
me otvori, ktor programy me spa, ktor sluby internetu me vyuva at. Nstroje
na riadenie prstupu s zabudovan do operanch systmov, aplikci, databz aj sieovch
komponentov. Pre riadenie prstupu existuj aj samostatn pecializovan aplikcie.
Riadenie prstupu vo vzahu ku konkrtnemu pouvateovi koreponduje s fzami
pracovnoprvneho vzahu. V zsade sa jedn o vytvorenie, zmeny a odobratie prstupovch prv
pouvatea. V prpade potreby zriadenia prstupovch prv (napr. prijatie novho zamestnanca)
je potrebn vykona spravidla nasledovn innosti:
vytvori a nakonfigurova samostatn pouvatesk konto,

poui pouvatea o pravidlch prce s IS (ak ete nebol pouen),
zvoli metdu autentizcie a oboznmi s ou pouvatea (napr. prvotn heslo),
prideli pouvateskmu kontu potrebn oprvnenia.
V situcich vyadujcich zmenu prstupovch oprvnen (napr. zmeny v sluobnch lohch

alebo pracovnch innostiach, preloenie zamestnanca na in pozciu) je potrebn zabezpei,
aby sasne s pridelenm novch oprvnen boli zamestnancovi odobran pvodn a nepotrebn
oprvnenia. Pri prideovan a zmene prstupovch oprvnen mus by zachovan zsada
pridelenia najmench potrebnch oprvnen, ktor pouvate potrebuje pouva na
vykonvanie svojej innosti.
Odobratie prstupovch oprvnen (napr. pri ukonen pracovnho pomeru zamestnanca,
zvanom poruen pracovnej disciplny, po splnen elu zriadenho prstupu) je pecifickou
formou zmeny prstupovch oprvnen. V niektorch prpadoch je po zruen oprvnen zruen
aj samotn pouvatesk konto. V prpade odvodnenej potreby, je mon konto v IS ponecha,
ale v zablokovanom stave (najastejie z dvodu zachovania integrity dajov zaznamenanch
v IS, ktor sa viau na identitu pouvatea). Je potrebn, aby v organizcii boli zaveden procesy
zaisujce odobratie prstupovch oprvnen. V prpade IS, do ktorch maj prstup iba uren
86
Riadenie prstupu | MF SR
zamestnanci organizcie, je obvyklm rieenm priama komunikcia medzi pracovnkmi sprvy

IKT zabezpeujcej sprvu oprvnen v IS a pracovnkmi personlneho tvaru (alebo obdobnm
tvarom, ktor zabezpeuje preradenie zamestnancov v rmci organizanej truktry alebo ich
odchod).
V tejto kapitole sa alej zameriavame na riadenie prstupu na logickej rovni (rove operanch
systmov, aplikci, potaovch siet a sieovch sluieb). Vysvetujeme zkladn mechanizmy
identifikcie a autentizcie, riadenie vzdialenho prstupu, stupne spoahlivosti autentizcie,
riadenie a administrciu prstupu z pohadu prevdzky.
4.2
Modely riadenia prstupu
Mechanizmy riadenia prstupu sa v praxi implementuj a vyuvaj v zvislosti od pecifk

samotnej organizcie. Ich vyuitie zvis aj od toho, ako s definovan jednotliv pozcie
zamestnancov organizcie a ak je rove citlivosti dt, ktor sa v organizcii spracvaj. Napr.
verejn intitcia bude ma in model riadenia prstupu ako vojensk organizcia. Rzne modely
riadenia prstupu poskytuj rzne rovne bezpenosti vyadovan pri ochrane citlivch dajov
organizcie.
Riaden prstup je rozhodujci pre ochranu dvernosti a integrity dt. Poiadavka na dvernos
poaduje, aby iba autorizovan osoba mohla ta dta a poiadavka integrity znamen, e iba
autorizovan osoba m dovolen dta meni. Riaden prstup nekladie explicitn draz na
dostupnos dt, ale pln dleit lohu pri ochrane dostupnosti (chrni pre vymazanm dajov
neoprvnenmi osobami, neautorizovanmi zmenami dajov a pod.). Ak aj neoprvnen
osoba/tonk zska neautorizovan prstup do systmu alebo k dtam prostrednctvom nejakho
tu, na ktor sa vzahuj mechanizmy riadenia prstupu, bude ma pre neleglne innosti
saen podmienky.
Defincia a modelovanie riadenho prstupu boli ucelenm spsobom stanoven u v roku 1983,
ke Ministerstvo obrany Spojench ttov zverejnilo bezpenostn kritri TCSEC vo forme tzv.
Orange book (TCSEC Trusted computer system evaluation criteria). Tieto kritria definovali
dva dleit reimy riadenia prstupu: voliten riadenie prstupu DAC (discretionary access
control) a povinn riadenie prstupu MAC (mandatory access control). V devdesiatych rokoch
bola vyvinut metda RBAC (role-based access control), ktor sa v rznych modifikcich
pouva dodnes.
Pochopenie princpov, modelov a metd riadenia prstupu, ktor sa daj poui v konkrtnom
prostred organizcie, je pre pecialistov IT vemi dleit. V alom texte sa budeme venova
vysvetleniu princpov nasledovnch metd riadenia prstupu:
riadenie prstupu metdou DAC,
riadenie prstupu metdou MAC,
riadenie prstupu zaloen na pravidlch (Rule-based access Control),
riadenie prstupu zaloen na roliach ( RBAC),
riadenie prstupu zaloen na obmedzen rozhrania,
matice pre riadenie prstupu
o Capability lists (Zoznam povolench operci),
o Access control lists ACL (Zoznam povolench prstupov),
o Mechanizmus atribtov
bezpenostn modely
o Bell-LaPadula model,
o Biba model,
o Clark-Wilson model.
pravidl najmench privilgi,
oddeovanie povinnost,
rotcia povinnost,
87

4.2.1
oddeovanie siet.
Riadenie prstupu metdou DAC
Podstata modelu DAC spova v tom, e kad pouvate m pln kontrolu nad vetkmi
svojimi sbormi a procesmi, ktor spustil/inicioval a niektor prva k tmto sborom a procesom
me poskytn aj inm pouvateom. Inmi slovami, ak pre riadenie prstupu pouvame
model DAC, tak sami urujeme, ako chceme ochraova a s km chceme zdiea svoje dta.
Systmy zaloen na DAC umouj pouvateom povoli alebo zakza prstup k objektom,
ktor s v ich vlastnctve. Najastejia sa tto metda implementuje pomocou tzv. zoznamu
povolench prstupov (ACL).
Metda riadenia prstupu DAC je flexibiln a poas osemdesiatych a devdesiatych rokov sa
tandardne pouvala v komernch aj ttnych organizcich. Ukzalo sa vak, e riadenie
prstupu typu DAC je nedostaton, a to najm z dvoch dvodov. Prvm dvodom je, e
obmedzenie prstupu k objektu pre tanie je v podstate doasn. Napr. ke pouvate A udel
pouvateovi B prva na tanie sboru, tak ni nebrni pouvateovi B v tom, aby si skoproval
obsah sboru pouvatea A do objektu, ktor sm spravuje. Toto umouje pouvateovi B
sprstupni tto kpiu akmukovek aliemu pouvateovi bez toho, aby o tom pouvate A
vedel. Druhm dvodom je, e metda prstupu DAC nedoke eli toku typu trojsk k,
pretoe programy dedia identitu od pouvatea, ktor ich vyvolal. Pouvate B me napr.
napsa pre pouvatea A program, ktor bude predstiera, e vykonva uiton funkcie, ale na
pozad bude ta obsah sborov pouvatea A a zrove ich uklada na in miesto.
4.2.2
Riadenie prstupu metdou MAC
V riaden prstupov pouitm modelu povinnho riadenia prstupu MAC nemaj pouvatelia
monos rozhodova, kto me pristupova k ich dtovm sborom. Jednotliv rovne riadenia
prstupov stanovuj samotn mechanizmy MAC. Prstupy k objektom s zaloen na
privilgich/oprvneniach subjektu (pouvatea) a citlivosti (klasifikanch atribtoch) objektu
(napr. sboru). Inmi slovami, o tom akm spsobom bud dta zdiean jednotlivmi
pouvatemi nerozhoduje vlastnk objektu, ale systm. Naprklad organizcia me
pouvateovi udeli oprvnenie typu citliv; v tomto prpade bude ma prstup k vetkm
objektom s touto klasifikciou prpadne niou (ak sa to vyaduje).
Zhrnieme strune dleit informcie o modeli MAC:
organizcia prostrednctvom systmu riadenia prstupov uruje rovne (stupne) citlivosti
objektov systmu, znme aj pod pojmom labels (nvestia),
kadmu objektu je priraden rove citlivosti a je prstupn iba pre uvateov, ktor
maj oprvnenia tejto rovne alebo vyej rovne,
zmeni rove citlivosti objektu me zmeni iba administrtor systmu, nie vlastnk
objektu.
Model MAC je bezpenej ako model DAC, ale na druhej strane, MAC systmy sa pomerne
zloito konfiguruj a prakticky implementuj. V kritrich TCSEC (Orange book) sa riadenie
prstupu DAC poaduje pre systmy rovne 100 C a MAC pre systmy, ktor s o kategriu
vyie; t.j. na rovni B.
Je potrebn pamta si, e model MAC sa pri riaden prstupu spolieha na systm,v ktorom je
implementovan. Napr. ak je sbor klasifikovan ako dvern, MAC zabrni komukovek
zapsa informcie s vyou bezpenostnou klasifikciou do tohto sboru.
100
Orange book del systmy do 4 rozlinch kategri, najniia je D a najvyia A.
88
4.2.3
Model riadenia prstupov zaloen na pravidlch
Riadenie prstupu zaloen na pravidlch (Rule-Based Access Control) je v princpe pecilny

typ MAC, pri ktorom je prstup k dtam je urovan pravidlami alebo pouvanm klasifikanch
nvest a nie na zklade identity subjektov a objektov samotnch. Tento model riadenia prstupu
je obyajne zaloen na pecifickch profiloch pre kadho pouvatea, o umouje
jednoduch zmenu bezpenostnej informcie aj pre jednho pouvatea. pecifick pravidl
vytvoren administrtormi uruj o sa me a neme vykona s konkrtnym objektom.
4.2.4
Model riadenia prstupov zaloen na roliach (Role-Based Access Control)
V modeli riadenia prstupu postavenom na roliach (Role-Based Access Control, RBAC) s

rozhodnutia o prstupe zaloen na roliach, ktor s definovan na zklade organizanej truktry
organizcie. Prstupov prva nie s viazan na jednotlivch zamestnancov, ale na roly
a vyuvanie konkrtnych zdrojov je obmedzen vlune na osoby, zaraden do roly, ktor m
oprvnenie na prstup k danm zdrojom.
Tento model umouje, aby bola bezpenos riaden spsobom, ktor koreponduje
s organizanou truktrou organizcie. Pre riadenie prstupu s pouvatelia s podobnm
pracovnm zaradenm zaraovan do tried (rol), oprvnenia pre jednotliv roly s stanoven na
zklade pracovnch potrieb a poiadaviek organizcie.
RBAC je metda riadenia prstupu typu MAC, asto je taktie nazvan aj Non-discretionary
access control. Bezpenostn administrcia svisiaca s RBAC pozostva z urenia operci,
ktor musia by vykonan osobami v konkrtnom pracovnom zaraden a zo zaradenia
zamestnancov organizcie do prslunch rol.
4.2.5
Model riadenia prstupu zaloen na obmedzen rozhran
Model obmedzenia rozhran obmedzuje prstupov monosti pouvateov takm spsobom, e

im neumon poadova urit funkcie alebo informcie resp. tak, e im neumon prstup ku
pecifickm zdrojom systmu. Vo veobecnosti existuj tri monosti, ako mono obmedzi
rozhranie:
obmedzenie poloiek v menu pouvateom s ponknut iba monosti prkazov, ktor
mu spusti,
databzov zobrazenie pouvatesk prstup k dtam je obmedzen mechanizmami
prezentcie dt na rovni databzovho nstroja,
fyzick oddelenie prstupu k pouvateskmu rozhraniu.
4.2.6
Matice pre riadenie prstupu
Prstupov matica je pouvan k zobrazeniu a evidencii prstupovch oprvnen aj na ich

dokumentciu. Je to vlastne pole obsahujce riadok pre subjekt v systme a stpec pre objekt
v systme.
Subjekt/objekt
Pouvate 1
Pouvate 2
Pouvate 3
Pouvate 4
Sbor 1
Execute
Read
-
Sbor 2
Read, write
Write
-
Sbor 3
Read, write
Read
Proces 1
Suspend
-
Tab. 4.1 prklad prstupovej matice

Zpisy v tejto matici pecifikuj opercie alebo typ prstupu, ktor m kad subjekt k danmu
objektu. Z teoretickho hadiska je prstupov matica zaujmavm rieenm, z praktickho
hadiska vak pre pre systm s vekm potom pouvateov a objektov bude vemi rozsiahla
89
a me by iba riedko zaplnen. Vyuvan s najm nasledovn praktickejie implementcie

prstupovej matice:
Zoznam povolench operci,
Zoznam povolench prstupov,
Mechanizmus atribtov.
V alch astiach tieto pecifick implementcie prstupovej matice popeme

podrobnejie.
4.2.6.1 Zoznam povolench operci
V tomto modeli sa zpis do matice uskutouje po riadkoch. Kad subjekt je priraden

k zoznamu, ktor obsahuje povolen opercie ku vetkm zahrnutm objektom. Zkladnou
vhodou tohto modelu je monos skontrolova vetky prstupy, ktor s pre dan subjekt
povolen. Na druhej strane je ale nron zisova subjekty, ktor mu pristupova
k jednotlivm objektom. To by znamenalo nutnos vyska ich vetky v kadom zozname
povolench operci. Z tohto dvodu je nron zrui prstup subjektu k nejakmu objektu v
systme. Riadenie prstupu pomocou zoznamu povolench operci nie je preto v praxi vemi
rozren.
Subjekt
Pouvate 1
Pouvate 2
Pouvate 3
Pouvate 4
Sbor 2: Read, Write

Sbor 1: Execute
Sbor 1: Read
Sbor 3: Read
Proces 1: Suspend
Sbor 3: Read, Write
Sbor 2: Write
Tab. 4.2 Prklad zoznamu povolench operci

4.2.6.2 Zoznam povolench prstupov
Metda zoznamu povolench prstupov zostavuje maticu riadenia prstupu pomocou stpcov,
ktor tvoria zoznam pouvateov a ich oprvnen vzahujcich sa k chrnenmu objektu (napr.
sbor alebo adresr). Kad objekt m nastaviten bezpenostn atribty, ktor identifikuj
zoznam povolench prstupov pre jednotlivch pouvateov. Systm m zznam pre kadho
pouvatea systmu s prstupovmi oprvneniami. Najastejie pouvan oprvnenia zahruj
monosti na tanie sboru, zpis do sboru alebo spustenie sboru i programu.
Metdu ACL vyuvaj napr. operan systmy Microsoft Windows. Samotn implementcia
ACL zvis samozrejme na pecifikch kadho systmu. Zkladn typy povolenho prstupu s
monosti tania, zpisu, vytvorenia, modifikcie, zmazania alebo spustenia (aplikcie).
Objekt
Sbor 1
Sbor 2
Sbor 3
Proces 1
Pouvate 2: Execute
Pouvate 1: Read, Write
Pouvate 2: Read, Write
Pouvate 1: Suspend
Pouvate 3: Read
Pouvate 3: Write
Pouvate 4: Read
Tab. 4.3 Prklad zoznamu povolench operci

4.2.6.3 Mechanizmus atribtov
Tento mechanizmus je podobn ako v prpade zoznamu povolench prstupov, rozdiel je v tom,
e namiesto spjania pouvateov s operciami s atribty spjan s objektmi. Mechanizmus
atribtov del pouvateov do troch skupn (vlastnk sboru, skupina a ostatn pouvatelia).
90
Prstupov systm reguluje prstup k sborom pomocou atribtov: tanie (r), zpis (w) alebo
spanie opercie (x). Napr. sbor me ma nasledujce atribty (r w x) (r - x) (- - x). Tento
reazec uruje, e vlastnk m prvo na tanie, zpis a spustenie tohto sboru, skupina m prvo
na tanie a spustenie a ostatn pouvatelia maj prvo na spustenie. Unixovsk operan
systmy historicky vyuvaj (aj) tento mechanizmus.
4.2.7
Bezpenostn modely
Bezpenos sa najlepie presadzuje pomocou viacrovovho bezpenostnho systmu. Takto

systmy doku zabrni pouvateom zska prstup k informcim klasifikovanm na rovni,
na ktor nemaj tto pouvatelia oprvnenia. Na pomoc pri tvorbe viacrovovch
bezpenostnch systmov bolo vytvorench niekoko bezpenostnch modelov, ktor je mon
vyui pri analze a tvorbe bezpenostnho systmu. Medzi najdleitejie patria:
Bell-LaPadulov model,
Bibov model,
Clark-Wilsonov model.
4.2.7.1 Bell-LaPadulov model
Bell-LaPadulov model (BLP) je (technicky) postaven na koncepte konenho automatu.
Primrne sa zameriava na zabezpeenie dvernosti, naopak vbec neodra poiadavky na
zabezpeenie integrity.
BPL definuje pre systm mnoinu stavov. Systm prechdza z jednho stavu (sasnho) do
druhho (budceho) na zklade hodnoty vstupu a predchdzajceho stavu. Pravidl prechodu s
definovan pomocou tzv. prechodovch funkci. BPM predpoklad, e poiaton stav je
bezpen a jeho hlavnm cieom je zabezpei, aby prechod vdy skonil v bezpenom stave.
BLP definuje bezpen stav prostrednctvom troch vlastnost:
Simple Security Property znamen, e tanie informci subjektom na niej rovni od
objektu na vyej rovni nie je dovolen,
*property (hviezdikov vlastnos) znamen, e zpis informci subjektom na vyej
rovni do objektu na niej rovni nie je dovolen (no write down),
Discretionary Security property znamen, e na pecifikovanie DAC sa pouva
prstupov matica.
Pouitie tohto modelu zabrauje pouvateom a procesom, aby mohli zska prstup k objektom
presahujcim ich bezpenostn rove. Zrove zabrauje procesom v rmci stanovenej
klasifikcie zapsa dta do prostredia s niou rovou klasifikcie. No write down princp
zabrauje umiestneniu dt, ktor nie s citliv, ale s umiestnen v citlivom dokumente do menej
citlivho sboru. BLP model riei najm rizik niku citlivch informci mimo prostredie
organizcie.
4.2.7.2 Bibov model
Bibov model riei tok dt z jednej bezpenostnej rovne do inej a kladie hlavn draz na
zaistenie integrity dt. Tento model m dve zkladn aximy svisiace s integritou (v porovnan
s BLP m pravidl stanoven opane):
Simple integrity axiom (axima jednoduchej integrity) znamen, e subjekt na jednej
rovni integrity nem dovolen ta objekt na niej rovni integrity (no read down),
*Integrity axiom znamen, e objekt na jednej rovni integrity nem dovolen
modifikova (write to) objekty na vyej rovni integrity (no write up). Napr. ak proces
me zapsa dta nad svoju bezpenostn rove, mu by dveryhodn dta
znehodnoten prve pridanm menej dveryhodnch dt.
Subjekt na jednej rovni integrity sa neme odvolva na subjekt na vyej rovni integrity.
Tento model vo veobecnosti zaist, e informcia me smerova iba smerom dolu. Uveden
91
dve aximy zabezpeuj, e ist subjekty a objekty nebud znehodnoten prve pinavmi
informciami.
4.2.7.3 Clark-Wilsonov model
Clark-Wilsonov model vyuva vhodne vytvoren transakcie, oddelenie povinnost a oznaovanie
subjektov a objektov na zaistenie ich integrity. Tento model identifikuje tri pravidl integrity:
neautorizovan pouvatelia by nemali robi iadne zmeny v objektoch,
systm by mal udriava vntorn a vonkajiu konzistenciu,
autorizovan pouvatelia by nemali vykonva neautorizovan zmeny.
V modeli s na vyntenie integrity pouvan dva mechanizmy:
Vhodne vytvoren transakcie dta alebo dtov proces sa mu meni len pomocou
pecifickch dveryhodnch programov. Pouvatelia maj potom prstup k tmto
programom a nie priamo k dtam.
Oddelenie povinnost v prpade manipulcie s dtami alebo pokusom o prienik do
systmu s pouvatelia nten spolupracova z dvodu rozdelenia prvomoc
a povinnost medzi viacerch pouvateov.
4.2.8
Pravidl najmench privilgi
Pravidlo najmenieho oprvnenia je jednm zo zkladnch princpov praktickej informanej

bezpenosti. Me by definovan ako politika, ktor limituje prstup tak pouvateov ako aj
procesov iba k tm zdrojom, ktor s nevyhnutn na vkon poadovanej funkcie.
Ke administrtor implementuje pravidlo najmench oprvnen, mus identifikova vetky
pouvatesk lohy a minimlny zoznam oprvnen potrebnch na vykonvanie/plnenie tchto
loh. Administrtor nsledne aplikuje obmedzenia na pouvatea tak, aby mohol pristupova iba
k tm zdrojom, ktor s nevyhnutn na vykonanie jeho pracovnch loh (ani viac oprvnen, ani
menej). Prklady implementcie najmench monch oprvnen:
zabezpeenie, aby minimlny okruh pouvateov mal oprvnenia na rovni root alebo
administrator,
zamedzenie sptania nezabezpeench programov na bezpenostnom zariaden (napr.
firewall) alebo inch dveryhodnch zariadeniach.
4.2.9
Oddeovanie povinnost
Cieom metdy oddeovania povinnost je zaisti, aby iadna osoba nemohla samotn ohrozi
bezpenos v systme. Na oddelenie povinnost je potrebne stanovi, ktor povinnosti v sebe
maj prli zneuiten vysok oprvnenia.
Mon aktivity v systme je preto potrebn identifikova a ohodnoti prslunm stupom rizika
(napr. vysok, stredn, nzke) poda vykonanej analzy rizk. V alom kroku je potrebn
aktivity s neakceptovatene vysokm rizikom rozdeli na viacero mench aktivt a tie rozdeli
medzi viacerch jednotlivcov. Tmto spsobom organizcia nevklad prli vek dveru
v konkrtnych jednotlivcov a v prpade plnovania neleglnej aktivity zamestnancami by bola
potrebn ich vzjomn tajn dohoda a spoluprca. Toto preventvne opatrenie znamen, e
v prpade pchania trestnej innosti by muselo by do tejto innosti zapojench viacero osb.
4.2.10 Rotcia povinnost
Rotcia povinnost alebo rotcia pracovnch pozci je vmena ud, ktor plnia bezpenostne
relevantn lohy, alebo s na pozcii spojenej s plnenm takchto loh. Je mon v prpade, ak
v organizcii psob viacero osb na rovnakej alebo podobnej pracovnej pozcii. Rotcia
pracovnch pozci resp. povinnost umouje organizcii ma k dispozcii viac ako len jednu
osobu, ktor rozumie danm lohm a zodpovednostiam danej pecifickej pracovnej pozcie.
Tento prstup minimalizuje riziko, e dan funkcie nebude ma v prpade odchodu alebo absencie
92
jednho zamestnanca kto vykonva, ako aj napomha pri identifikcii slabch miest v systme
a podozrivch aktivt.
4.2.11 Oddeovanie siet
Oddeovanie siet sa v praxi zabezpeuje prostrednctvom fyzickch alebo technologickch
prostriedkov. elom je oddeli uritch pouvateov, servery alebo in zdroje od inch,
naprklad menej citlivch alebo naopak citlivejch zdrojov. V prpade, ak je potrebn
komunikcia medzi takto oddelenmi entitami, mala by existova demilitarizovan zna
zabezpeujca ochranu prebiehajcej komunikcie. Naprklad umiestnenm dleitch databz,
sborov a serverov do jednej serverovne s riadenm prstupom je pouvateom znemonen
fyzick prstup k citlivm systmom. Informan systm umon logick prstup k tmto
zdrojom prostrednctvom potaovej siete, ale iba prostrednctvom firewalu umiestnenho v
segmente, ktor oddeuje pouvateov od serverov.
4.3
Identifikcia a autentizcia
Riadenie prstupu v praxi vyaduje rozliovanie jednotlivch pouvateov, t.j. ich identifikciu
(urenie identity). Pod identifikciou rozumieme proces, ktorm pouvate poskytuje svoju
identitu do systmu (napr. zad prihlasovacie meno). Autentizcia znamen overenie (potvrdenie)
identity, ktor pouvate poskytol (napr. v rmci autentizcie zad heslo). IKT systmy
rozpoznvaj a overuj identitu pouvateov prve na zklade autentizanch dajov, ktor
pouvatelia poskytn systmu. Samotn proces autentizcie m niekoko krokov, ktor si
vyaduj samostatn zabezpeenie. Ide najm o zadvanie a prenos autentizanch dajov,
rozpoznanie pouvatea, ktor sa autentizoval, pouvatea, ktor so systmom pracuje
(pouvate sa me prihlsi, ods od PC a jeho miesto zaujme niekto in, priom systm stle
akceptuje identitu predchdzajceho pouvatea). Toto separtne zabezpeenie prvkov
autentizanho procesu je predmetom alch bezpenostnch mechanizmov a opatren.
Identifikcia a autentizcia (I&A) je kovm prvkom riadenia prstupu zastnench strn
(napr. pouvateov, administrtorov, systmov).
Vo veobecnosti sa vyuvaj tri zkladn mechanizmy autentizcie pouvateov (alebo ich
kombincia) zaloen na:
nieom, o pouvate vie (napr. heslo, PIN),

nieom, o pouvate m (token ipov karta, genertor jednorazovch hesiel,
klientsk certifikt),
nieom, o pouvate je (biometrick charakteristiky ako odtlaok prsta,
rozpoznvanie vlastnost dhovky, dynamika vlastnorunho podpisu).
V praxi s s kadm z tchto mechanizmov spojen poiadavky, ktor si asto vzjomn

odporuj (pohodlnos pouitia, chybovos, finann nkladnos, spoahlivos, nenron
administrcia). Na prv pohad sa me zda, e vyie uveden mechanizmy poskytuj siln
autentizciu, v skutonosti je s nimi spojench mnostvo bezpenostnch problmov. Ak sa
cudzia osoba rozhodne predstiera identitu legitmneho pouvatea, me sksi uhdnu jeho
heslo alebo ho odpozorova, ukradn jeho ipov kartu, sfalova podpis. Navye m kad
metda aj negatvne rty tak pre pouvateov ako aj pre administrtorov (pouvatelia asto
zabdaj hesl, strcaj tokeny, niektor biometrick systmy mu pouvateov obaova
alebo s finanne prli nkladn). Praktick implementcie silnejej autentizcie vyuvaj
kryptografick mechanizmy, ktor spoahlivos autentizcie vznamne zvyuj.
93
4.3.1
I&A zaloen na nieom, o pouvate vie
V praxi sa najastejie stretvame s formou identifikcie a autentizcie zaloenou na

prihlasovacom mene a k nemu priradenmu heslu. Tto technika je zaloen vlune na nieom,
o pouvate vie. Okrem konvennch hesiel existuj aj alie mechanizmy zaloen na znalosti
pecilnej informcie, napr. ifrovacieho ka. Hesl sa vyuvaj ako bezpenostn
mechanizmus IKT systmov u vemi dlho. Ich pouitie je integrovan v operanch systmoch
a aplikcich, pouvatelia s oboznmen so spsobom ich vyuvania, je prepracovan systm
ich vytvrania a sprvy. Ak s hesl vyuvan v slade s vhodne definovanmi politikami
a smernicami organizcie, mu poskytn dostaton bezpenos.
Pod heslom chpeme tajn informciu (typicky reazec znakov), ktor pouvate pouije na
overenie svojej identity. Pouitie hesla s pouvateskm identifiktorom, ako je naprklad
pouvatesk meno (identifiktor), je asi najvyuvanejou formou identifikcie a autentizcie.
Pri tejto forme identifikcie pouvate zadva identifiktor, ktor oznauje identitu pouvatea
pre systm (login, prihlasovacie meno). Overovanie identity v tomto prpade je proces potvrdenia
identifiktora zadanm tajnej informcie (hesla), ktor pozn len drite pridelenho
identifiktora.
Vo veobecnosti, systmy riadenia prstupov zaloen na hesle vyaduj, aby pouvate zadal
svoje pouvatesk meno a heslo. Systm po zadan hesla over jeho sprvnos; t.j. i heslo
prislcha k pouvateskmu menu. Po pozitvnom overen sprvnosti hesla je pouvate
autentizovan (jeho identita je potvrden) a systm mu povol prstup, na ktor m oprvnenie.
Ako u bolo uveden vyie, autentizcia me zaha nieo, o pouvate pozn (napr. heslo),
nieo, o pouvate m (napr. ipov karta) alebo nieo, m pouvate "je" (napr. odtlaok
prsta alebo hlasov vzorka). Tzv. jednofaktorov autentizcia pouva iba jednu z tchto troch
foriem overovania, zatia o dvojfaktorov autentizcia pouva kombinciu dvoch foriem a
trojfaktorov autentizcia pouva vetky tri formy. Pouitie viacerch faktorov sauje
tonkom zskanie neoprvnenho prstupu k systmu. Naprklad, je ahie odhali heslo
pouvatea alebo ukradn pouvateovi autentizan token (napr. ipov kartu), ako ukradn
ipov kartu a zrove odhali aj PIN k nej a heslo pouvatea. Pre splnenie rznych
bezpenostnch a prevdzkovch potrieb sa vber autentizanch metd medzi systmami li.
Hesl vak zostvaj najastejie pouvanou metdou autentizcie, pouvan tak samostatne,
ako aj s ostatnmi autentizanmi faktormi.
Existuj rzne formy hesiel. Jedna z nich je znma ako osobn identifikan slo (personal
identification number, PIN). PIN je relatvne krtke slo (obvykle 46 znakov) a sklad sa iba
z slic, naprklad "7352" alebo "832290". Vyaduje menej asu na zadvanie (a jednoduchie
zariadenie na zadvanie hesla) ako in druhy hesiel a preto sa asto pouva v prostrediach a
situcich, kde by zloitejie hesl mohli spsobi problmy (napr. vysok chybovos pri
zadvan, drahie vstupn zariadenie alebo nemern asov zdranie). V tchto prostrediach s
zaveden aj in (fyzick) bezpenostn opatrenia, ktor kompenzuj relatvne nzku rove
zabezpeenia poskytovanho PIN-om. PIN sa tie pouva pre zabezpeovacie systmy, platobn
karty a in zariadenia, ale len zriedkavo sa pouva aj ako jedin forma autentizcie pre prstup
do
IKT
systmu.
alia forma hesla je znma ako frza. Ide o pomerne dlh heslo pozostvajce z radu slov alebo
plnej vety. Prkladom je heslo "Som_zamestnanec_c1!". Motivciou pre pouvanie frzy je, e
me by dlhia ako jednoslovn heslo, ale je ahie zapamtaten ako sled ubovonch
psmen, slic a pecilnych znakov, naprklad "72 * ^ DSD!" alebo "C8ke2.e3:". Avak,
jednoduch frzy ako "mamraddobrejedlo" s predvdaten, a preto pre tonka ahie
uhdnuten heslo ako "9j% # F.0", take dka hesla sama o sebe neznamen silnejie heslo.
S plonm nasadenm a vyuvanm hesiel svis mnostvo vnych bezpenostnch problmov.
Odhalenie hesla v praxi me spsobi zskanie neoprvnenho prstupu k viacerm systmom
a aplikcim sasne (pri pouvan tzv. single sign-on systmov, vi alej v tejto kapitole). Aj
z tohto dvodu sa z dlhodobho hadiska autentizan schmy zaloen na znalosti hesla bud
postupne nahrdza silnejmi formami autentizcie. Slabm miestom hesiel je, e ich
94
bezpenos je zaloen na uchovvan hesla v tajnosti. V sasnosti existuje mnostvo spsobov,

ako sa utajenie hesla d narui. Riziko odhalenia hesla sa sce vo viacerch prpadoch d
efektvne minimalizova vhodnmi technikami prce s heslami, v prpade poiadavky na vyiu
rove bezpenosti je vak v dnenej dobe iba samotn heslo nepostaujce. Najznmejie
spsoby naruenia bezpenosti autentizcie postavenej na hesle s vysvetlen v alom texte.
Hdanie alebo hadanie hesiel. V prpade, e si pouvate vyberie heslo sm, m tendenciu
zvoli si ahk, zapamtaten heslo. Takto heslo je vak aj ahko uhdnuten. Men,
priezvisk, dtumy narodenia, svadby, PZ, obben portov tmy, men domcich zvierat s
ast prklady nevhodnch hesiel. Na druhej strane, zloit, potaom vygenerovan hesl sa
ako pamtaj a pouvatelia si ich preto zapisuj na papieriky. Mnostvo potaovch
systmov m od vroby prednastaven tandardn hesl, ktor s veobecne znme. Pokia ich
administrtor nezmen, mu by zneuit. Napriek tomu, e tento problm je notorick znmy
u roky, pravidelne sa objavuj kauzy zneuitia trivilnych hesiel. Na Slovensku v minulosti
vrazne zarezonovala kauza nezmenench prednastavench hesiel na NB SR.
alou metdou neoprvnenho zskania hesla je jeho odpozorovanie poas zadvania
oprvnenm pouvateom. Odpozorovanie me by realizovan napr. cez plece alebo
intalovanou kamerou.
Rozdvanie / poskytovanie hesiel. Pouvatelia asto zdieaj svoje hesl. Povedia ich
svojim spolupracovnkom, aby ich mohli zastpi v prpade neprtomnosti alebo aby im umonili
prstup k sborom (pokia ho vetci nemaj). asto sa na zskanie hesiel vyuva aj metda tzv.
socilneho ininierstva. Osoba, ktor chce heslo neoprvnene zska, sa napr. v telefne predstav
ako zamestnanec servisnej firmy a pod zmienkou testovania systmu alebo odstraovania
poruchy poaduje od pouvatea jeho heslo. Existuje mnoho prepracovanch schm socilneho
ininierstva, ktor s orientovan na rzne hesl (prstup do firemnch systmov, osobnch email tov, internet bankingu a pod.)
Elektronick monitorovanie. Heslo sa poas autentizcie prena od klvesnice cez potaov
sie do prslunho potaa, aplikcie resp. systmu. Poas prenosu me by na viacerch
miestach prenosovej trasy zachyten neoprvnenou osobou. Medzi klvesnicu a pota je mon
umiestni mal zariadenie, ktor hesl zachytva a uklad, prpadne sa heslo d zachyti poas
prenosu cez potaov sie.
Prstup k sboru s heslami. Sasn operan systmy si hesl resp. informcie o nich ukladaj
v pecilnom tvare (nedaj sa z neho extrahova). V prpade zskania prstupu k uloenm
heslm vak existuj techniky a nstroje, ktor napr. postupnm porovnvanm (tzv. tok hrubou
silou) doku uri hadan heslo. Pri vkone sasnch bench PC me by jednoduch heslo
(slovo, ktor je v slovnku alebo je krtke) odhalen v dobe rdovo mint.
Za elom zaistenia dvernosti hesiel a ich bezpenho vyuvania sa v praxi vyuva viacero
opatren technickho ale aj organizanho charakteru. Organizcie by mali ma stanoven jasn
pravidl a poiadavky spojen s heslami. Tieto poiadavky zahaj spsoby ukladania a prenosu
hesiel, ich tvorby a obnovy. Pravidl by mali by dostatone prun, aby sa dali aplikova
v rznych operanch systmoch a aplikcich a pouvateov prli neobaovali.
Zvenie bezpenosti hesiel sa v praxi me dosiahnu viacermi spsobmi. Pouvatelia mu
ma nastaven povinn vyuvanie genertora hesiel, ktor v prpade, ke je potrebn nejak
heslo vytvori alebo zmeni, heslo pre pouvatea vytvor. Takto sa zabrni vyuvaniu
trivilnych ahko uhdnutench hesiel. Genertor silnch hesiel vak strca zmysel, ak si
pouvate bude vytvoren hesl zapisova.
Pokusom o uhdnutie hesla pri jeho zadvan sa d zabrni nastavenm maximlneho potu
nespench prihlsen. Napr. po treom nespenom prihlsen sa et zablokuje a je potrebn,
aby ho administrtor odblokoval.
Automatizovan hdanie hesiel tokom hrubou silou sa sa, ak si pouvatelia volia siln
hesl. Sila hesla zvis od jeho dky, zloitosti, znalosti pouvatea ako si heslo zvoli. Systm
95
me by nastaven tak, aby si vynucoval vber hesla, ktor m predpsan minimlnu dku,
obsahuje aj pecilne znaky (sla, interpunkciu), nenachdza sa v slovnku a nesvis
s pouvateskm menom.
Dobrou bezpenostnou praktikou je aj periodick zmena hesiel. Zniuje sa tak doba zneuvania
hesla v prpade jeho neoprvnenho zskania. V systmoch sa asto implementuje doba
exspircie hesla, po uplynut ktorej je heslo nutn zmeni. Poiadavka na prli ast zmenu
hesiel vak me pouvateov popudi a psob skr kontraproduktvne.
Mnoho organizci zaviedlo alebo plnuje zavies centralizovan rieenia pre sprvu identt a
hesiel s cieom zni poet identifiktorov pouvateskch tov a hesiel, ktor si pouvatelia
potrebuj pamta. Podobne, loklne intalovan pecializovan nstroje pre sprvu hesiel mu
by tie pouit ako loisko pre hesl (v iadnom prpade by vak hesl nemali by ukladan
v itatenom tvare). Centralizovan aj loklne rieenia pre sprvu hesiel mu zni za
kladen na pouvateov a odbremeni pracovnkov helpdesku od aktivt spojench so zmenami
hesiel, odblokovanm tov a podobne. Rieenie pre sprvu hesiel zniuje pravdepodobnos, e
hesl bud ohrozen (pretoe nie s zapsan na papieroch), obvykle nie s opakovane zadvan
na klvesnici (nemu by zachyten cudzou osobou alebo kodlivm softvrom) a nie s slab
(nie je potreba pamta si vetky hesl).
Single sign-on 101 (SSO) technolgia umouje pouvateovi overi jeho identitu (autentizova
sa) iba raz a nsledne zska prstup ku vetkm zdrojom, ktor je oprvnen pouva. Samotn
overenie prstupovch prv k jednotlivm zdrojom je pre pouvatea transparentn. SSO
automatizovane vytvor jedinen siln heslo pre kad zdroj a pravidelne hesl men. Pouvate
obvykle pozn iba zkladn heslo SSO. Vzhadom k tomu, e pre kad zdroj sa pouije in
heslo a pouvate si ich nemus pamta, me SSO voli kad heslo tak siln, ako to prslun
zdroj podporuje a meni hesl primerane asto. SSO rieenia mu tie podporova uchovvanie
a vyuvanie viacerch identifiktorov pre jednho pouvatea, naprklad, "jmrkvicka" na
jednom systme a "jozkom" na inom.
V takmer iadnom komplexnom IKT prostred vak nie je mon ma rieenie SSO, ktor
zabezpe autentizciu pre kad systm a kad zdroj. Prinou je najm vzjomn
nekompatibilita rozhran a protokolov pouvanch vrobcami.
Vina SSO rieen me zaisti autentizciu iba pre niektor systmy a zdroje, preto sa
nazvaj redukovan SSO. Napriek tomu mu by technolgie SSO vemi inn pri zniovan
potu pouvateskch mien a hesiel, ktor si pouvatelia potrebuj zapamta a potu
opakovanch autentizci pouvateov.
Existuje viacero architektr pre SSO technolgie. V praxi sa asto vyuva architektra
poskytujca autentizan sluby (napr. Kerberos) pre pouvateov SSO a databzy alebo
adresrov sluby.
Populrnou adresrovou slubou je Lightweight Directory Access Protocol (LDAP), v rmci
ktorej sa ukladaj a eviduj autentizan daje k zdrojom, pre ktor SSO zabezpeuje
autentizciu. Bez ohadu na konkrtnu architektru, rieenie SSO zvyajne zaha jeden alebo
viacero centralizovanch serverov obsahujcich identifikan daje pre viacero pouvateov.
Takto server sa vak stva tzv. single point of failure (jedinm bodom zlyhania) pre prihlsenie
sa do mnostva zdrojov. Dostupnos servera nsledne ovplyvuje dostupnos vetkch zdrojov,
prstup ku ktorm zvis od autentizanch sluieb servera. Takisto kompromitcia SSO servera
me ohrozi bezpenos alch systmov, ie zabezpeenie SSO servera je obzvl dleit.
Autentizcia pouvatea na vyuitie SSO je sama o sebe tie vemi dleit. Ak sa vzjomn
overovanie (pouvatea aj SSO servera) nevykon sprvne, SSO me by ohrozen tzv. man-
101
jedin prihlsenie
96
in-the-middle 102 (MitM) tokmi. alm problmom SSO autentizcie pouvateov je, e heslo
k SSO me by kompromitovan prostrednctvom socilneho ininierstva, phishing tokmi
alebo inmi prostriedkami. V prpade zskania hesla k SSO zskava tonk prostrednctvom
jedinho hesla prstup k vetkm systmom, slubm a zdrojom, ako m oprvnen pouvate.
Pri rieen autentizcie a autorizcie sa vyuvaj u spomenut adresrov sluby.
4.3.1.1 Adresrov sluby
Adresr (directory) je hierarchick dajov truktra, v ktorej s uloen informcie
o pomenovanch objektoch, ktor s organizovan a zdruovan do skupn. Tmto objektom
me by pota, tlaiare, sluba, domna i pouvatesk et. pecifikom adresra je dtov
model, v ktorom s daje uloen vo forme poloiek, priom kad poloka obsahuje niekoko
atribtov, ktor s nositemi dt (napr. poloka pouvatea obsahuje atribty ako jeho meno,
slo kancelrie, email a pod.). Poloky s rozmiestnen v hierarchickej truktre, tzv.
adresrovom strome (Directory Information Tree). Adresr sa li od relanej databzy, je
navrhnut pre ast tanie a vyhadvanie a len obasn zpis. Riadenie prstupu k dajom
v adresri je zvyajne postaven na riadiacich prstupovch zoznamov - ACL (Access Control
List).
Adresrov sluba je pecializovan aplikcia pre prcu s dajmi zaznamenanmi v adresroch;
ich ukladanie, organizciu a prstup k nim. Prkladom s aplikcie na sprvu pouvateov,
sieovch zdrojov i telefnny zoznam. Adresrov sluba pristupuje k adresru a funguje tie
ako centrlna alebo loklna autorita na riadenie prstupu, ktor poskytuje bezpen autentizciu
pre prstup k zdrojom.
Adresrov sluba sprostredkovva informcie z adresra pouvateom, administrtorom,
aplikcim a pod.
Adresrov sluba me by sasou operanho systmu, ale aj ma formu samostatnej
aplikcie. Najrozrenejm prkladom adresrovej sluby je Active Directory od spolonosti
Microsoft. Active Directory, tak ako vina sasnch adresrovch sluieb, vyuva protokol
LDAP.
LDAP
LDAP je skratka pre Lightweight Directory Access Protocol, o je aplikan protokol pre prstup
k adresrovm slubm a pre modifikciu adresrovch sluieb. Je postaven na architektre
klient/server a na komunikciu medzi klientom a serverom vyuva protokol TCP/IP. Primrne
bol navrhnut ako zjednoduenie prstupovho protokolu DAP medzi klientom a adresrovm
serverom poda tandardu X.500. Jeho hlavnmi vlastnosami s jednoduchos, rozritenos,
otvorenos a distribuovan model uloenia dajov a prstupu k nim. pecifikcia protokolu
LDAP je implementane nezvisl a je veden snahou o zjednoduenie implementcie za elom
podpory nasadenia LDAP v aplikcich (tandardn LDAP API Application Program
Interface). V sasnosti sa pod pojmom LDAP u chpe nielen samotn komunikan protokol,
ale aj adresrov server komunikujci s klientom.
LDAP definuje komunikciu medzi klientom a serverom, na prenos dajov sa vyuva
tandardizovan textov formt a kdovanie. Zkladn schma komunikcie je nasledujca:
Klient naviae spojenie s LDAP serverom. Me sa pripoji anonymne alebo mus preukza
svoju identitu vykon sa autentizcia jednou z definovanch metd. Na naviazanie spojenia
mus klient pozna IP adresu a port LDAP servera.
tok typu tonk v strede tonk vystupuje so sfalovanou identitou voi obom aktrom autentizcie (napr. voi pouvateovi vystupuje ako server) a pomocou toho zist autentizan daje alebo me
realizova nos spojenia.
102
97
Klient m k dispozcii spojenie na server a me v rmci neho posiela iadosti o vykonanie

definovanch operci nad adresrovmi dajmi.
Klient uzatvor spojenie s LDAP serverom.
Z hadiska nvrhu adresrovch sluieb je komunikan protokol len jednm z niekokch
aspektov nvrhu a implementcie. Pre lepie chpanie celku je vhodn rozleni LDAP do
tyroch modelov:
1.
2.
3.
4.
informan model popisuje truktru dajov v adresrovch slubch,

menn model popisuje ako s daje organizovan a identifikovan,
funkn model popisuje opercie nad dajmi v adresrovch slubch,
bezpenostn model popisuje ako s daje chrnen, najm z hadiska riadenia
prstupu.
Z hadiska bezpenosti protokol LDAP riei najm autentizciu a autorizciu pouvatea a

zabezpeenie komunikcie.
Autentizcia pouvatea je spojen aj s jeho vzbou na poloku, ktor ho reprezentuje
v adresrovom strome. LDAP ponka 3 zkladn monosti autentizcie:
1. iadna autentizcia anonymn prstup, zvyajne len pre tanie verejnch poloiek,
2. zkladn autentizcia prostrednctvom jednoznanho mena pouvatea a jeho
hesla, ktor je nsledne uloen v prslunom atribte pouvatea v zaifrovanom
alebo hash tvare,
3. SASL (Simple Authentication and Security Layer).
Komunikcia pri autentizcii medzi klientom a serverom by kvli monmu odchytenia
zasielaneho hesla mala by chrnen ifrovanm.
SASL je tandardizovan metda pre dodaton zabezpeenie komunikanch protokolov
zaloench na spojeniach (napr. TCP/IP). SASL oddeuje autentizan mechanizmus od
aplikanch protokolov, take aplikcia podporujca SASL me teoreticky poui ubovon
autentizan mechanizmus.
Zkladn schma pouitia SASL autentizcie je nasledujca:
Klient zale informcie pre autentizciu

o
o
rozliovacie meno entity, ktor sa autentizuje,

autentizan mechanizmus, ktor bude vyuit (server me prostrednctvom
SASL podporova niekoko autentizanch mechanizmov, ako s napr. SSL a
TLS, Kerberos, GSSAPI...),
autentizan daje preukazujce identitu v prslunom autentizanom mechanizme.

Prostrednctvom LDAP API sa doru autentizan poiadavka LDAP serveru, ktor pre
jej vybavenie pouije prslun autentizan modul (poda pouitho mechanizmu).
Prslun autentizan modul na zklade zskanch dajov rozhodne, i je identita
preukzan alebo nie. Sasou tohto kroku me by alia komunikcia vo vntri
autentizanho mechanizmu (napr. Kerberos).
Praktickou vhodou LDAP autentizcie je monos jej vyuitia ako SSO. LDAP server tak me
pozna vetky men a hesl pouvatea ku sieovm zdrojom a autentizova ho, aj ke sa
v skutonosti prihlsil len prostrednctvom LDAP.
Autorizcia v rmci LDAP zabezpeuje riadenie prstupovch prv k jednotlivm objektom
adresra a operci nad nimi (a na rove atribtov). Je realizovan tandardnmi prkazmi
LDAP, zatia nie je sasou iadneho prijatho tandardu. Najastejie je rieen formou ACL.
98
Bezpenos komunikcie prostrednctvom LDAP sa tandardne riei pomocou protokolov SSL,

resp. TLS. Tie zabezpeuj ifrovanie komunikcie medzi klientom a serverom, ale aj ich
autentizciu (jedno alebo obojstrann). V kombincii s vlastnmi metdami autentizcie LDAP
mu v zvislosti od pouitch prostriedkov a mechanizmov tvori dvojfaktorov autentizciu.
Active Directory
Active Directory (alej len AD) je implementcia adresrovch sluieb spolonosou
Microsoft na pouitie v systmoch Microsoft Windows. AD umouje autentizciu a autorizciu
vetkch pouvateov a potaov, ktor zaha, podporuje plon intalciu softvru
a aktualizci a umouje definovanie a vynucovanie bezpenostnch politk a pravidiel. AD
vyuva protokol LDAP a slubu DNS. Svoje informcie a nastavenia uklad v centrlnej
organizovanej adresrovej databze.
AD je rozriten a klovaten adresrov sluba. Jej zkladnou jednotkou je domna
skupina prostriedkov, ktor zdieaj spolon adresrov databzu. Kad domna m vlastn
jednoznan DNS oznaenie a aspo jeden riadiaci server (tzv. Domain Controler). Domna
predstavuje bezpenostn hranicu v truktre AD a m vlastn bezpenostn pravidl. S inmi
domnami si me vytvra vzah dvery. Hierarchick spojenie domn vzahom rodi-potomok
tvor domnov strom. Spojenie viacerch domnovch stromov vyuvajcich spolon
adresrov daje sa nazva les. Naopak, podskupiny domn, ktor asto odraj organizan
truktru organizcie, sa nazvaj organizan jednotky. Umouj efektvnejie spravova mal
poet objektov domny (pouvatelia, sieov prostriedky) prostrednctvom osobitne
definovanch pravidiel.
Adresrov daje v AD obsahuj najm informcie o:
pouvateskch toch,
zdieanch prostriedkoch,
organizanch jednotkch,
stanovench politikch a pravidlch.
Riadenie prstupov v AD je zaloen na princpoch autentizcie a autorizcie. Autentizcia

pomocou AD je v praxi vinou vyuvan ako SSO a umouje tak pouvateom prstup ku
viacerm zdrojom bez optovnej autentizcie. AD podporuje viacero autentizanch
mechanizmov, ako napr. Kerberos, NTLM, PKI certifikty, SSL/TLS (viac v kapitole venovanej
bezpenosti potaovch siet). Pouvatelia teda maj pridelen prstupov oprvnenia
v zvislosti od pridelench rol a lenstva v organizanch jednotkch. Prstup na rovni
jednotlivch objektov je riaden formou ACL.
Konkrtne parametre autentizcie a autorizcie s stanoven v politikch a pravidlch domny
a organizanch jednotiek AD. Navye, sluby AD s zko spt s operanm systmom
Windows Server a s modifikovan spolu s kadou novou verziou. Konkrtnejia pecifikcia
metd riadenia prstupu preto zvis aj od verzie AD (napr. nov mechanizmus dynamickho
riadenia prstupu vo Windows Server 2012).
4.3.2
I&A zaloen na nieom, o pouvate m
Tto metda sa v praxi vyuva zvyajne v spojen s predchdzajcou, existuj vak aj techniky
zaloen vlune na vlastnctve uritho predmetu. Kombincia nieoho o viem s niem o
mm poskytuje podstatne silnejiu rove bezpenosti ako jednotliv metdy vyuit
samostatne.
Predmety, ktor pouvate vlastn pre pouitie v I&A sa nazvaj tokeny. Existuj dve zkladn
kategrie tokenov: pamov tokeny a inteligentn (smart) tokeny.
99
Pamov tokeny slia na ukladanie informcie, nie vak na jej spracvanie. Na zpis a tanie
informci z/do pamovch tokenov mu by potrebn pecializovan zariadenia. Prkladom
pamovho tokenu s platobn karty s magnetickm psikom. Tieto sa vak pouvaj
v kombincii s PIN-om. Niektor autentizan systmy s zaloen vhradne na vlastnctve
tokenu, ich vyuitie v prostred informanch systmov je vak zriedkavejie. Vyuvaj sa skr
ako systmy pre riadenie fyzickho prstupu v budovch.
Vhodou pamovch tokenov (ak sa pouvaj v kombincii s PIN-om) je podstatne vyia
rove bezpenosti ako pri pouit hesiel. Neoprvnen osoba aj po zskan tokenu nezskava
kompletn informciu , neme token poui, a teda sa neme autentizova. Zskanie tokenu aj
PIN-u je ovea aie ako zskanie pouvateskho mena a hesla (samozrejme, pokia si PIN
pouvate nezapsal priamo na token).
alou vhodou pamovch tokenov je, e v ase mu by pouit iba na jednom mieste.
Napr. ten ist token me by pouit aj pre prstup do priestorov aj pre prihlsenie sa do SSO.
Ak vak pouvate chce opusti PC, mus si token zobra aby mohol prejs cez chrnen
priestory. Minimalizuje sa tak riziko, e pouvate ostane prihlsen aj ke nie je pri PC.
Voi pamovm tokenom existuje mnostvo tokov, ktorch podstatou je najm replikcia
tokenu (resp. dajov na om uloench) alebo kompromitcia PIN-u (v prpade zskania prstupu
k tokenu). S praktickm vyuitm pamovch tokenov s spojen aj naprklad nasledovn
problmy.
Nutnos pecilneho zariadenia (taky). Tto potreba zvyuje finann nronos pouvania
pamovch tokenov. taka mus obsahova jednak as, ktor preta informciu z tokenu,
ako aj komponent, prostrednctvom ktorho sa d zada a overi PIN. V prpade, e PIN overuje
komponent, ktor nie je fyzicky spojen s takou, hroz neoprvnen zachytenie PIN-u poas
jeho zadvania.
Strata tokenu. V prpade straty pouvate strca monos autentizcie (a teda aj prstupu do
systmov) dovtedy, km nedostane nov token. Straten token me by niekm zneuit na
neoprvnen prstup do systmu alebo trvalo odcudzen, prpadne replikovan a vrten sp
oprvnenmu pouvateovi. Ak sa token pouva v kombincii s PIN-om, kad technika
pouiten na neoprvnen zskanie hesla (vysvetlen v predchdzajcom texte) me by
pouit aj na zskanie PIN-u.
Nespokojnos pouvateov. Vo veobecnosti, pouvatelia vyaduj transparentn a pohodln
spsob prce s PC. Potreba nosi a pouva token sa me zda ako obaujca a komplikujca
prstup k systmom a aplikcim. Je vak dleit uvedomova si, e token sli k ochrane
samotnho pouvatea a jeho dt (voi zvzku kov, ktor tie treba nosi pri sebe zvyajne
nikto nenamieta).
Inteligentn (smart) tokeny
Smart tokeny roziruj monosti pamovch tokenov vyuitm inteligentnho ipu
(integrovanho obvodu) zabudovanho priamo do tokenu. Vaka ipu me token sm vykona
urit opercie s dajmi, ktor s v om uloen. Smart token zvyajne vyaduje zadanie PIN-u
predtm, ako ho je mon poui na autentizciu. Existuje viacero typov smart tokenov. Vo
veobecnosti sa odliuj nasledovnmi charakteristikami.
Fyzick vzhad. Smart tokeny mu by smart karty (napr. platobn karta s ipom) alebo mu
vyzera ako mal kalkulaky, USB ke. Smart tokenom me by aj mobiln telefn, v ktorom
je naintalovan pecilna aplikcia.
Rozhranie. Smart tokeny maj manulne alebo elektronick rozhranie. Manulne rozhranie
zvyajne obsahuje mal klvesnicu, prostrednctvom ktorej pouvate token pouva a display
na zobrazenie kdu, ktor pouvate v procese autentizcie zadva. Elektronick rozhranie maj
napr. ipov karty.
100
Protokol. Smart tokeny mu ma implementovan niektor z mnostva protokolov, ktor mu

vyui na proces autentizcie. Vo veobecnosti sa vyuvaj najm 3 zkladn kategrie: vmena
statickho hesla, genertory dynamickch hesiel a systm vzva-odozva 103.
Statick token funguje podobne ako pamov tokeny s vnimkou toho, e pouvate sa mus
autentizova, aby mohol token poui a nsledne token autentizuje pouvatea na potai.
Genertory dynamickch hesiel vytvraj jedinen kombincie znakov (napr. osemcifern
sla), ktor sa periodicky obmieaj (napr. kad mintu). Ak m takto token manulne
rozhranie, pouvate zad prslun aktulne slo pri autentizcii na PC. Ak m elektronick
rozhranie, prenos autentizanho daju sa vykon automaticky bez zsahu pouvatea.
V prpade, e sa prostrednctvom tokenu vytvor a systmu poskytne sprvna hodnota, systm
povol pouvateovi prihlsenie do systmu.
Tokeny zaloen na protokole vzva-odpove spolupracuj s potaom nasledovne:
1. Pota vygeneruje reazec slic (vzva)
2. Na zklade tejto vzvy token vygeneruje odpove, ktor je odoslan nasp do potaa
3. Pota odpove vyhodnot a v prpade, e je sprvna, pouvatea spene autentizuje
Vhody smart tokenov
Smart tokeny poskytuj znan flexibilitu a mu by pouit na rieenie mnohch problmov
autentizcie. Vhody smart tokenov sa lia v zvislosti na pouitom type. Veobecne plat, e
poskytuj vie zabezpeenie ako pamov tokeny. Smart tokeny mu vyriei problm
elektronickho monitorovania s cieom neoprvnene zachyti autentizan daje aj v prpade, e
overovanie sa vykonva v rmci otvorenej siete, pomocou jednorazovch hesiel.
Veobecne plat, e pam na ipe smart tokenu nie je itaten, pokia sa nezad PIN. Okrem
toho, smart tokeny s komplikovanejie a nronejie na falovanie. Smart tokeny s
elektronickmi rozhraniami, ako s napr. ipov karty, poskytuj spsob, ako pre pouvatea
zaisti prstup k viacerm potaom, systmom a aplikcim pomocou jedinho procesu
prihlsenia sa. Okrem toho, jedna ipov karta me by pouit na viac elov (fyzick prstup,
prihlasovanie sa do PC, evidencia dochdzky).
Podobne ako v prpade pamovch tokenov, aj pri smart tokenoch sa vina problmov tka
nkladov na sprvu celho systmu a pouvateskch poiadaviek a pohodlia pri prci. Smart
tokeny s veobecne menej zraniten z hadiska zneuitia PIN-u, pretoe overovanie sa
zvyajne vykonva priamo na karte (samozrejme, je mon odpozorova PIN kd pri jeho
zadvan a kartu ukradn). Smart tokeny s v porovnan s pamovmi tokenmi bezpenejie,
maj irie monosti vyuitia, ale s aj drahie.
Smart tokeny vyaduj elektronick zariadenia na ich tanie/zpis resp. interakciu
s pouvateom. Elektronick zariadenie vak predstavuje alie finann nklady. Rozhranie pre
interaktvnu komunikciu s pouvateom sa sklad z klvesnice a displeja. Vyaduje aby
pouvate vykonal niekoko aktivt (napr. zadal vzvu do tokenu, zadal odpove do potaa)
a me takto spsobi nespokojnos pouvatea pri prci.
4.3.3
I&A zaloen na nieom, o pouvate je
Biometrick autentizan technolgie vyuvaj na urenie a overenie identity jedinen

fyziologick vlastnosti/charakteristiky (atribty) osb.
Vyuvaj sa fyziologick atribty (napr. odtlaky prstov, rk, geometria dlane, vzory sietnice)
alebo behaviorlne atribty (napr. hlasov vzorky, vlastnorun podpisy).
Biometrick autentizcia vo veobecnosti funguje nasledujcim spsobom:
103
challenge-response
101
1. Pred prvm pokusom o autentizciu mus pouvate vytvori a uloi referenn profil /
ablnu (na zklade atribtu, ktor sa v autentizci bude pouva, napr. zosnma a ulo
odtlaok palca). Vsledn ablna je spojen s identitou pouvatea a zaznamenan pre
neskorie pouitie.
2. Pri pokuse o autentizciu pouvatea sa zosnma prslun biometrick atribt (napr.
odtlaok palca). Zosnman atribt sa porovn s atribtom uloenm v ablne a na
zklade vsledku porovnania sa pouvate akceptuje alebo odmietne.
Biometrick systmy mu poskytn pre potaov systmy vyiu mieru bezpenosti, ale
bene pouvan technolgie s v porovnan so smart tokenmi menej dokonal. Nedostatky v
biometrickej autentizcii vyplvaj z technickch akost pri meran a profilovan fyziklnych
vlastnost ud, ako aj z ich premennho charakteru (mu sa meni v zvislosti na rznych
podmienkach). Naprklad, osoba me ma vlhk alebo ahko poranen prsty, hlasov prejav sa
me zmeni v stresujcich podmienkach alebo ke trp bolesou v krku at. Vzhadom na ich
relatvne vysok nklady s biometrick systmy obvykle pouvan v kombincii s inmi
metdami overovania najm v prostrediach vyadujcich vysok bezpenos.
Vkonnos a pouitenos biometrickch autentizanch zariaden sa uruje prostrednctvom
kvantitatvnych parametrov (vyjadrench v percentch). Prvm je poet chybnch odmietnut
(False Recognition Rate - FRR) o znamen, kokokrt je oprvnen osoba pri autentizcii
nesprvne odmietnut systmom. Druhm parametrom je poet chybne akceptovanch
autentizci (False Acceptance Rate - FAR), kedy biometrick systm akceptuje aj
neoprvnenho pouvatea. Vo veobecnosti, kad systm me by konfigurovaten tak, e
hodnoty FRR a FAR sa menia. Plat vak, e znenie jednho parametra spsob zvenie
druhho a naopak.
Je dleit si uvedomi,e biometrick autentizan technolgie vyuvaj osobn daje, ktorch
pouitie je upraven pravnmi aktami. Zkon . 122/2013 Z. z. o ochrane osobnch dajov a o
zmene a doplnen niektorch zkonov chpe pod biometrickm dajom osobn daj fyzickej
osoby oznaujci jej biologick alebo fyziologick vlastnos alebo charakteristiku, na zklade
ktorej je jednoznane a nezamenitene uriten; biometrickm dajom je najm odtlaok prsta,
odtlaok dlane, analza deoxyribonukleovej kyseliny. Tento zkon konkrtne upravuje kto, za
akch podmienok a akm spsobom me biometrick daje spracva.
4.4
Vzdialen prstup
Dnen organizcie vyaduj pripojenie vzdialenm prstupom (prstup zvonka) k ich

informanm zdrojom pre rzne typy pouvateov, ako s zamestnanci, dodvatelia, obania,
obchodn partneri alebo zkaznci. Pri poskytovan tejto monosti prstupu je k dispozcii
mnostvo metd a postupov ako tto formu prstupu riadi.
asto vyuvan metda vzdialenho prstupu je zaloen na platforme protokolov TCP/IP. Tto
metda je cenovo efektvna, umouje pre vzdialen prstup vyui verejn siete / internet
a poskytuje viacer monosti zabezpeenia a autentizcie (je monos vyuva ifrovanie
komunikcie, tokeny pre autentizciu a pod.). V praxi sa pri vzdialenom prstupe do siete
zvyajne vytvor VPN spojenie cez internet, ktor zaist bezpenos komunikcie v prostred
verejnej siete. Vhodou tejto metdy vzdialenho prstupu je jej irok dostupnos, ahkos
pouitia, finanne nenron spojenie a monosti riadenia prstupu. Nevhodou je relatvne
niia spoahlivos (v porovnan s vyhradenmi linkami) a potencilne komplikovan rieenie
prpadnch problmov poas prevdzky.
Je potrebn uvedomi si, e umonenie vzdialenho prstupu me zni bezpenos vntornej
infratruktry organizcie. ifrovan komunikcia me v sebe obsahova kodliv kd alebo
zavren softvr. Systmy na detekciu prienikov a antivrusov programy takto komunikciu
bene nemu kontrolova. Z tohto dvodu sa odpora vetky VPN spojenia ukoni vdy
102
v jednom bode (VPN koncentrtor) a zvi nasadenie nstrojov, ktor doku deifrova
prebiehajcu komunikciu, zaisti jej analzu a nsledne ju op zaifrova.
Rizik vzdialenho prstupu zahaj:
4.4.1
odopretie sluby, kedy vzdialen pouvatelia nebud schopn zska prstup k dtam
alebo aplikcim, ktor s dleit pre ich pracovn aktivity,
pokusy o neoprvnen prstup pouvateov a tretch strn, ktor sa mu snai zska
vzdialen prstup zneuitm bezpenostnch nedostatkov sieovch protokolov alebo
socilnym ininierstvom,
nesprvne nastaven komunikan softvr, o me ma za nsledok nesprvne
nastaven prstupov oprvnenia k systmom a dtam organizcie,
nesprvne konfiguran nastavenia zariaden v internej potaovej sieti organizcie,
nedostaton zabezpeenie hostiteskch systmov, ktor tak mu by vyuvan
tonkom zskanm prstupu na diaku.
Vzdialen prstup pomocou mobilnch zariaden
Pouvanie mobilnch zariaden ako PDA (Personal Digital Assistent), tabletu alebo
smartfnu 104 je v sasnosti vemi rozren a asto v praxi dopaj stoln PC a notebooky
najm z dvodu jednoduchosti pouitia a funkcionality. Monosti pripojenia
a komunikan monosti PDA s v porovnan s minulosou vrazne irie a repektuj
existujce tandardy IKT (wi-fi, USB, Bluetooth a pod.). Sasn PDA je najastejie smartfn
alebo tablet, s integrovanm fotoapartom a monosou sieovho prstupu (wi-fi, 3G) Vyuitie
tchto zariaden asto zaha aj prstup k citlivm alebo dvernm informcim a sborom. V
dsledku nasadenia PDA do dennej praxe sa rizik pre organizciu zvili (PDA sa daj ahko
ukradn alebo strati kvli ich malej vekosti, maj nedostatone prepracovan mechanizmy
ochrany uloench dt a pod.). V prpade, e PDA je pripojiten do internej potaovej siete
alebo synchronizovan bez prslunch bezpenostnch opatren, je riziko neoprvnenho
prstupu do infratruktry organizcie neakceptovatene vysok.
rove opatren implementovanch na ochranu PDA mus zodpoveda charakteru informci,
ktor s v PDA uloen a/alebo spracvan. Je dleit, aby organizcia mala nastaven
a zaveden vhodn politiky, procesy a postupy a pouvatelia si boli plne vedom svojich
zodpovednost pri pouvan PDA na pracovn ely (osobitne v prpadoch, kedy sa jedn
o skromn PDA t.j. tie, ktor nie s vo vlastnctve organizcie).
Pri vyuvan PDA v praxi je potrebn riei najm nasledovn:
104
Slad - PDA a ich vyuvanie mus by v slade s bezpenostnmi poiadavkami, tak ako s
definovan v tandardoch a internch predpisoch organizcie. Existujce politiky, ktor
definuj zdroje a IKT komponenty by mali by rozren tak, aby okrem serverov, PC,
notebookov zahali aj PDA.
Schvlenie pouvaniu PDA by mala prechdza prslun autorizcia a konkrtne postupy
a spsoby jeho vyuvania by mali repektova aplikovaten organizan riadiace akty.
Konfigurcia a aplikan spsoby pouitia PDA by mali by jasne stanoven a kontrolovan.
Starostlivos - pouvatelia by mali venova nleit starostlivos o PDA v rmci
pracovnho prostredia a najm poas cestovania a sluobnch ciest. Akkovek strata alebo
odcudzenie dt z PDA ako aj samotnho PDA mus by povaovan za bezpenostn
incident a bezodkladne hlsen v slade s politikami riadenia bezpenosti a postupmi
organizcie pre rieenie bezpenostnch incidentov.
Povedomie vzdelvanie pouvateov a budovanie bezpenostnho povedomia by malo
zaha aj pokrytie politiky bezpenosti a vyuvania PDA. Workshop i kolenie napome
reniu bezpenostnho povedomia o PDA.
v alom texte s tieto zariadenia pre zjednoduenie sumrne nazvane PDA.
103
PDA aplikcie povolen by mali by iba tie aplikcie, ktor spaj stanoven organizan
smernice alebo s tandardom vrobcu dodvanho zariadenia. Vetky intalovan aplikcie
musia by vopred autorizovan na pracovn pouitie a prslune licencovan.
Synchronizcia - PDA by mali by zlohovan a pravidelne softvrovo aktualizovan.
Informcie na PDA by mali by synchronizovan s dtovmi zdrojmi na notebooku a / alebo
PC. Vzdialen prstup k infratruktre organizcie by mal by umonen iba schvlenmi
metdami a nstrojmi a mechanizmami pre synchronizciu. Vo veobecnosti, pre PDA by
malo by povolen priame spojenie s PC (kblom, bluetooth alebo infra) a vzdialen
pripojenie cez sie schvlenm zabezpeenm spsobom. V ase, v ktorom je PDA pripojen
do internej siete, by nemalo by pripojen do iadnych inch siet ani internetovch aplikci.
Naprklad, v ase PDA synchronizcie s PC v LAN by na PDA mala by zakzan monos
pripojenia PDA do internetu. Pred samotnou synchronizciou mus by PDA autentizovan.
ifrovanie PDA asto sli aj na ukladanie citlivch alebo dvernch informci. Tieto by
mali by zaifrovan v slade s internmi predpismi pre riadenie politiky bezpenosti
informci.
Detekcie vrusov a ochrana - hrozby spojen s potaovmi vrusmi platia rovnako pre PDA
ako platia pre notebooky a PC. Z tohto dvodu by mala by pre PDA zachovan rovnak
rove kontroly ako je na potaoch.
Registrcia zariadenia - PDA schvlen pre pracovn pouitie by mali by evidovan
v databze zariaden, aby ich bolo mon odli od skromnch a cudzch PDA. Organizcie
mu tie vyui monos ntenej aktualizcie (kvli odstraovaniu bezpenostnch chb)
autorizovanch zariaden a konfiguran vylenie monosti pripojenia skromnho PDA.
Fotoapart PDA maj fotoaparty, prostrednctvom ktorch me djs k niku citlivch
informci zosnmanch fotografiami. Rovnako me djs aj k ohrozeniu skromia
samotnho majitea PDA v prpade zneuitia bezpenostnho nedostatku PDA pre ely
neoprvnenho vzdialenho prstupu na PDA.
4.5
QAA, STORK a federcia identity
udia hodne cestuj a dostvaj sa do situci, kedy je v zahrani potrebn rchle overi ich
identitu na zklade dokladov, ktor vydala intitcia inho ttu (letisk, hotely, zdravotn
zariadenia a pod.). Rieenie procesov identifikcie a autentizcie je preto nutn riesi aj na
nadnrodnej rovni.
Vznamnou aktivitou v celoeurpskom rozsahu je projekt STORK 105 (Secure idenTity acrOss
boRders linKed 2.0), ktorho cieom je vytvori Eurpsku platformu interoperability eID. Tto
umon vetkm obyvateom lenskch ttov E komunikova s radmi (prpadne s almi
poskytovatemi sluieb) naprie hranicami, na zklade preukzania sa svojim nrodnm eID
(nrodnm elektronickm identifikanm dokladom). lohou centrlnej platformy STORK je
identifikova subjekt (fyzick osobu), ktor komunikuje s poskytovateom sluby a zasiela
poskytovateovi sluby daje o subjekte. Poskytovate sluby me iada o rzne typy dajov,
avak vdy subjekt sm rozhodne, ktor daje bud skutone poskytnut. Ide o tzv. na
pouvatea zameran prstup (user-centric approach) - vdy pred sprstupnenm dajov je
vyadovan explicitn shlas subjektu. Cieom pri nvrhu tohto mechanizmu bolo zni rizik
kompromitcie osobnch dajov (napr. ak sa zistia bezpenostn problmy celej platformy
STORK) a uini zados nronch pravidlm pre ochranu skromia v Eurpe.
V ase prpravy tejto publikcie boli u realizovan pilotn projekty, napr. spolon identifikcia
pri prstupe k portlom sluieb, alebo zjednoduenie zmeny adresy pri presune do inho ttu E
(SR nebola v pilotnch projektoch zastpen). SR v projekte STORK zastupuje Ministerstvo
financi SR. Prve pri komplexnch a prakticky orientovanch projektoch sa ukazuje, e
105
Stork, z angl. bocian
104
autentizcia v praxi me ma rzny stupe spoahlivosti. Dleitm aspektom autentizcie je

preto tzv. QAA Quality of Authentication Assurance 106.
Prklad: Pri kontrole obianskeho preukazu sa autentizcia, t.j. overenie totonosti fyzickej
osoby, ktor sa nm preukzala, vykon vizulnym porovnanm jej vzhadu a fotografie
umiestnenej na OP. Relne sa vak me sta, e in osoba napodobn vzhad z fotografie, najm
ak fotografia je menej kvalitn, alebo staria takto me djs ku sfalovaniu identity.
Z pohadu overujcej osoby (t.j. toho, kto chce zisti i OP naozaj prinle uritej osobe) sa
preto d na overenie porovnanm fotografie spoahn iba do uritej miery tto miera uruje
kvalitu overenia.
Stupe spoahlivosti autentizcie sa formlne vyjadruje ako miera bezpenostnch zruk, ktor
spen autentizcia poskytuje overujcemu subjektu. Je potom prirodzen, e v rznych
situcich je potrebn rzna rove potrebnch zruk. Z praktickch dvodov pritom nie je
vhodn vdy vykonva autentizciu s vysokm stupom zruk (kee na tento proces je
obvykle potrebn vek mnostvo zdrojov, me by zdhav alebo obaujci napr. vysok
stupe zruk pri zisovan totonosti poskytuje porovnanie DNA). Pre kad konkrtnu situciu
sa sname njs minimlny stupe zruk autentizcie, ktor vak u je dostaton.
Miera zruk autentizcie zvis od nasledovnch procesov:
1. Procesy registranej fzy
2. Sprva autentizanch dajov
3. Samotn vkon autentizcie
Je dleit si uvedomi, e jednotliv procesy mu vykonva rzne subjekty. Napr. v prklade
s obianskym preukazom za proces registrcie zodpoved MV SR, sprvu autentizanch dajov
zabezpeuje drite obianskeho preukazu a vkon autentizcie kad overujci subjekt napr.
vrtnik kontrolujci totonos pri vstupe do budovy. Z pohadu overujceho subjektu je dleit
vsledn stupe zruk, ktor vak z vekej asti zvis od procesov mimo jeho kontroly.
4.5.1
Poiadavky na registran fzu
Registranou fzou rozumieme innosti vykonvan pri vytvoren vzahu medzi subjektom (o
ktorho identitu ide) a garantom autentizanej schmy (entity stanovujcej procesy autentizcie,
ktor za ne aj zodpoved). Tieto innosti prebehn spravidla jednorazovo, pri vytvoren identity
subjektu. V nasledovnom texte popeme poiadavky na tieto innosti, ich vlastnosti a zastnen
strany z hadiska metodiky vypracovanej v rmci projektu STORK. Najdleitejie s
nasledovn:
a) Kvalita registranej procedry
Registran procedra je mechanizmus, pomocou ktorho sa preuke skuton identita
subjektu garantovi autentizanej schmy 107 (napr. na zriadenie tu v banke mus by iadate
osobne prtomn a mus sa preukza obianskym preukazom).
Spoahlivos registranej procedry zvis spravidla na nasledovnch faktoroch:
miera prtomnosti subjektu (iadatea o identitu) Fyzick prtomnos subjektu je

povaovan za najvyiu mieru spoahlivosti pri komunikcii so subjektom v tom zmysle,
e komunikcia realizovan medzi dvoma prtomnmi osobami je povaovan za autentick
(nemodifikovan tonkom) a identita subjektu je potvrden s istotou (jeho fyzickou
existenciou a vnmatenosou som ten, ktor som). V niektorch prpadoch me by
dostaton vykonanie identifikanej procedry iba na zklade vzdialenho prstupu, napr. pri
registrcii prostrednctvom webovho formulra. V inch prpadoch me by fyzick
106
miera zruk dosiahnutch autentizciou
107
Napr. pre eID je garantom autentizanej schmy MV SR.
105
prtomnos vyadovan iba poas overovania identity, alebo aj poas odovzdvania

autentizanch dajov od garanta autentizanej schmy.
vierohodnos dajov svediacich o identite subjektu (assertions) Identita subjektu je
vyjadren pomocou sboru atribtov tento subjekt opisujcich (napr. meno, vek, adresa).
Tieto daje s nsledne uchovvan garantom autentizanej schmy a sprstupovan ako
opis prslunho subjektu alej (napr. overujcemu subjektu). V najjednoduchom prpade
pritom nemusia by vyadovan iadne alie daje o subjekte (napr. pri zaloen
pouvateskho tu v elektronickej hre). V niektorch prpadoch posta zadanie jednho
alebo niekokch zkladnch dajov, ktor nemusia by uniktne viazan na subjekt (napr.
vea fyzickch osb m rovnak krstn meno). alou rovou je vyadovanie takej
kombincie dajov, ktor jednoznane identifikuje iba tento jeden subjekt (v prpade fyzickej
osoby teda u ide o sbor napajci znaky osobnch dajov). Za najvy stupe
vierohodnosti je povaovan uvedenie takch dajov, ktor s uniktne pre subjekt a s
overiten v inch systmoch alebo evidencich (napr. ttom garantovan registre R,
OP).
overenie vierohodnosti dajov svediacich o identite subjektu samotn daje o atribtoch
subjektu, diskutovan v predchdzajcom odseku, mu ma rzny stupe overenia
vierohodnosti. V najjednoduchom prpade sa ich sprvnos neoveruje. al stupe je
elektronick (prpadne automatizovan) overenie sprvnosti dajov procesom, ktor je plne
pod kontrolou subjektu (napr. pri validcii e-mailovej adresy zaslanie kontrolnho mailu
a doruenie odpovede). Nasleduje krov porovnanie dajov s databzou inho subjektu
samozrejme dveryhodnos tohto subjektu nesmie by niia, ako je potrebn miera zruk
pre cel proces autentizcie (obvykle ide o subjekty ako napr. banka, pota, intitcia
verejnej sprvy). Vyiu rove overovania predstavuje prezentovanie pravosti dajov
pomocou ttom vydanho certifikovanho dokumentu napr. identifikan preukaz (OP),
ktor obsahuje minimlne fotografiu subjektu (v prpade fyzickch osb), prpadne
vlastnorun podpis. Za najvy stupe potvrdenia vierohodnosti dajov je povaovan ich
podpsanie kvalifikovanm elektronickm podpisom subjektu (QES v podmienkach SR ide
o ZEP), ktor je povaovan za ekvivalent vlastnorunho podpisu.
b) Spoahlivos procesu vydania identity
Pri vydan identity sa subjektu odovzdaj tokeny preukazujce jeho identitu a autentizan daje
alebo predmety. m vy stupe zruk proces vydania identity poskytuje, tm s vyou
pravdepodobnosou je mon predpoklada, e pri doruovan tokenov a autentizanch dajov
nedolo k odcudzeniu identity alebo prezradeniu dajov. Aj ke s astokrt identifikan
predmety a autentizan daje odovzdan subjektu priamo poas registranej procedry (vi.
predchdzajca as), v niektorch prpadoch ich subjekt me dosta s odstupom viacerch dn
tento posun nastva najm vtedy, ak je potrebn dosiahnu vysok mieru zruk bezpenosti,
napr. vykonvanm dodatonch kontrol alebo vrobou personalizovanho autentizanho
predmetu.
V najjednoduchom prpade doruenie autentizanch dajov prebehne isto elektronickou
formou bez pecifickho zaistenia dvernosti. Napr. heslo je zaslan na zadan adresu
elektronickej poty, alebo s daje zobrazen na www strnke poas registranho procesu.
Ako vy stupe bezpenosti je mon realizova doruenie sce tie elektronickou formou, ale
a po overen vlunho prstupu k doruovanm dajom zo strany subjektu, napr. po zadan
prvotnho hesla, ktor mu bolo vydan poas procesu registrcie.
alie zvenie bezpenosti je mon dosiahnu pomocou fyzickho doruenia predmetov
subjektu takm spsobom, pri ktorom sa overuje jeho identita pri ich preberan. V tomto prpade
je kov zaisti prepravu a odovzdanie predmetov dostatone spoahlivou doruovateskou
slubou, ktor doke garantova na dostatonej rovni ochranu integrity a dvernosti zsielky
a dodranie procedry identifikcie subjektu pri preberan zsielky.
106
Najvym stupom bezpenosti je odovzdanie dajov a predmetov fyzicky prtomnej osobe.

Tento prstup je vak pre subjekt nron na as (najm ak kvli vydaniu identity by bolo
potrebn op prs za garantom autentizanej schmy).
c) Spoahlivos garanta autentizanej schmy
Dleit rolu pri autentizcii zohrva aj spoahlivos samotnho garanta autentizanej schmy.
Ten mus nielen zaisti dostaton bezpenos procesov registrcie a vydania identity, ale mus
by pripraven zaisova aj bezpen uchovvanie dajov (o identitch a autentizan daje)
a vykonva procesy sprvy identt poas ich celho ivotnho cyklu. Kee uveden innosti s
nron, pri schmach umoujcich zdieanie (federciu) identity s spravidla garantmi
autentizanej schmy vek spolonosti alebo organizcie verejnej sprvy.
Zkladn faktory, na zklade ktorch je mon hodnoti rove zruk poskytovan garantmi s
nasledovn:
formalizcia procesov vy stupe zruk je mon oakva od garantov, ktor procesy

svisiace s prevdzkou autentizanej schmy realizuj formalizovanm a riadenm
spsobom. Plat to najm pre riadenie bezpenosti a riadenie rizk.
rove sladu s poiadavkami ide o normatvne poiadavky, vyplvajce napr. zo zkona,
inch prvnych predpisov alebo noriem. Spravidla m vy stupe zruk je potrebn
dosiahnu, tm vy stupe formlneho sladu s poiadavkami sa vyaduje, a po
certifikciu organizcie alebo procesov predpsanm spsobom.
uchovvanie zznamov vytvranie a uchovvanie zznamov o vykonanch
konoch/opercich pomha garantovi pri rieen neskorch problmov, najm pri
preukazovan sprvnosti vykonanch operci a obmedzen kd pri bezpenostnch
incidentoch.
Uveden faktory sa v praxi prelnaj napr. sasou normatvnych poiadaviek s aj zsady

formlneho riadenia procesov a poiadavky na uchovvanie zznamov.
4.5.2
Sprva autentizanch dajov
Tto fza bva asto podceovan, kee poas nej sa nevykonvaj iadne opercie svisiace
s autentizciou. Pritom ku kompromitcii autentizanej schmy dochdza najastejie prve
v tejto fze.
Bezpenos sprvy autentizanch dajov spolone zaisuj:
garant autentizanej schmy povinnosou garanta je uchrni dtov zdroje obsahujce

identity a daje potrebn pre autentizciu pred kompromitciou i u z hadiska ochrany
dvernosti alebo integrity (napr. aby nedolo k neoprvnenmu vloeniu novej identity).
autentizovan subjekt jeho hlavnou povinnosou je zaisti bezpen uchovanie
autentizanch dajov a predmetov tak, aby nedolo k ich odcudzeniu alebo zneuitiu.
Subjekt mus repektova stanoven bezpenostn poiadavky v zvislosti od poadovanho
stupa spoahlivosti autentizcie (napr. in stupe ochrany pred odcudzenm je potrebn pre
prstupov kdy k potaovej hre, in pre autentizan daje do systmov verejnej sprvy).
Vzhadom na vznik integrujcich I&A technolgi (napr. SSO, federcia identity, eID) vznik
astokrt predstava, e nakoniec bude subjekt driteom iba jednej sady identifikanch
a autentizanch dajov, pomocou ktorch sa prihlsi vade. Hoci z pohadu pouvateskej
jednoduchosti je tto predstava lkav, je potrebn odmietnu ju z bezpenostnch dvodov. Ak
by dolo k jej naplneniu, objavili by sa dve mimoriadne zvan hrozby:
pri kompromitcii tchto jedinch autentizanch dajov by tonk mohol zneui

autentizciu ku vetkm slubm, kde m subjekt prstup (t.j. nsledky zneuitia by boli
vysok),
107
aj pri prstupe ku slubm s nim stupom zruk, kde je predpokladan vyia frekvencia
prstupu a to aj s prostred, v ktorom nie je mon zaisti vysok stupe bezpenosti, by
subjekt pouitm jedinch autentizanch dajov zvyoval riziko ich kompromitcie (t.j.
pravdepodobnos ich kompromitcie by stpala.).
Obe hrozby psobia sasne a riziko s nimi spojen je neakceptovaten tak pre subjekty ako aj
pre garantov autentizanch schm.
4.5.3
Samotn vkon autentizcie
Miera zruk procesov autentizcie zvis najm od nasledovnho:

Robustnos autentizanej metdy
Voba konkrtnej autentizanej metdy priamo ovplyvuje odolnos voi tokom na
prelomenie autentizanej schmy, monos uhdnutia autentizanch dajov, ale aj riziko ich
odcudzenia. Relevantn monosti a parametre s napr. jednorazov heslo, kombincia meno
a heslo, certifikt.
Bezpenos implementcie autentizanho mechanizmu
Ak softvrov aplikcia pre vkon autentizcie obsahuje bezpenostn slabiny, vsledn rove
zruk procesov autentizcie neme by vysok. Nedostaton zabezpeenie me spsobi
kompromitciu niektorm z nasledovnch spsobov:
tok hrubou silou vykonanm vekho potu pokusov sa tonk sna uhdnu sprvne
autentizan daje,
odpovanie tonk sa monitorovanm komunikcie (i u v sieti alebo loklne v rmci
procesov) sna narui dvernos autentizanch dajov,
nos spojenia po vykonan autentizcie a vytvoren dveryhodnho komunikanho
kanla tonk zska kontrolu nad komunikanm kanlom, m me pracova so systmom
aj bez vykonania vlastnej autentizcie,
tok typu tonk v strede tonk vystupuje so sfalovanou identitou voi obom aktrom
autentizcie (napr. voi pouvateovi vystupuje ako server) a pomocou toho zist
autentizan daje alebo me meni daje posielan v rmci spojenia.
Prostredie vkonu autentizcie

Prostredie, v ktorom subjekt pristupuje ku slube (kde je vykonvan autentizcia), me ma
zsadn vplyv na vsledn mieru zruk autentizcie. Ak m tonk kontrolu nad zariadenm,
s ktorm subjekt pracuje, v zsade plat, e m prstup ku vetkm dajom ktor subjekt zad
(my, klvesnica) a ku vetkm slubm, ku ktorm sa subjekt autentizoval. Preto v zvislosti na
poadovanej miere zruk je potrebn pecifikova aj poiadavky na bezpenos prostredia,
v ktorom m by autentizcia vykonan (napr. ak je potrebn vysok miera zruk, nie je vhodn
autentizciu vykonva z verejne dostupnch potaov.).
Ako pre kad komplexn systm, aj pri autentizcii plat pravidlo, poda ktorho bezpenos
celku neme by vyia ako bezpenos jeho najslabieho lnku. Nem teda zmysel realizova
urit procesy autentizcie na vysokom stupni bezpenosti, ak in svisiace procesy poskytuj
iba niiu mieru zruk. Z tchto dvodov je zmyslupln realizova autentizan schmy tak, aby
vo vetkch svisiacich procesoch (vi. vyie) bola dosahovan konzistentn rove zruk
bezpenosti.
V praxi s preto pre urit poadovan rove zruk tandardizovan konkrtne poiadavky na
procesy opsan v tejto kapitole vyie. Vytvorenm viacerch hierarchicky usporiadanch rovn
(z hadiska rovne zruk) vznik potom klasifikan schma pre mieru zruk dosiahnutch
autentizciou. Napr. na obrzku 4.1 [STORK-eID Consortium: D2.3 - Quality authenticator
scheme, STORK deliverable] je uveden schma pre QAA rovne definovan v rmci projektu
STORK.
108
Obr. 4.1 Quality of Authentication Assurance rovne pre STORK

V rmci nvrhu elektronickch sluieb verejnej sprvy SR sa taktie pouva hierarchick
klasifikcia vyadovanch zruk autentizcie. Pre kad slubu je povinne stanoven hodnota v
rozsahu 1 a 4 reprezentujca rove zabezpeenia autentizcie v nadvznosti na bezpenos
identifiktora, autentizanch nstrojov a bezpenosti doruenia autentizanch prostriedkov.
Me nadobda hodnoty:
rove 1 - s minimlnym zabezpeenm autentizcie,

rove 2 - s nzkym zabezpeenm autentizcie,
rove 3 - s vznamnm zabezpeenm autentizcie,
rove 4 - s najvym zabezpeenm autentizcie.
Pre rove 4 je predpokladan vyuitie autentizcie pomocou eID (a zadanie prslunho PIN).
Naopak pre rove 1 je uvaovan vyuitie tandardnej metdy meno/heslo. Pre podrobn popis
poiadaviek v tejto schme QAA je pripravovan tandard pre ISVS v gescii MF SR.
4.5.4
Federcia identity
Federcia identt oznauje koncept, ktorho cieom je umoni vyuvanie ast systmu sprvy
identt o najiriemu okruhu aplikci, a to aj mimo primrnu domnu tohto systmu. Zkladom
je mechanizmus na zdiean pouvanie identt. Svisiacimi procesmi s autentizcia identity a
sprstupovanie atribtov uritej identity. Zjednoduene je mon poveda, e federcia identt
umon pouva subjektu urit identitu v mnohch aplikcich a kontextoch, priom procesy
jej sprvy zostan zachovan. Z pohadu subjektu pristupujceho k aplikcim cez webov
prehliada predstavuje federcia identity urit formu SSO.
Pouitie federcie identity sa v sasnom obdob roziruje najm z nasledovnch dvodov:
pouvate pristupuje k mnostvu sluieb/aplikci (napr. poda prieskumov v UK priemern
pouvate denne pristupuje k viac ako 20 slubm), avak chce pri prstupe vyuva o
najmenej identt,
prostrednctvom Internetu dochdza k zsadnmu zveniu prepojitenosti aplikci,
pouvan procesy sprvy identt s pre vinu aplikci tandardizovan, o umouje
jednoduchie prepojenie.
Pri rieen federcie identity je potrebn riei najm nasledovn otzky:
109
otvorenos nakoko sprvca identt umon alm subjektom vyuva v ich systmoch
identity a procesy, ktor sm zabezpeuje; federcia identity je pouvan aj v uzavretch
systmoch (na zklade dohody astnkov, ktor me zaha aj odplatu za jednotliv
sluby spojen so sprvou identt), ale najm v otvorench systmoch, kde je mon von
prstup k uritm slubm.
interoperabilita ako je technologicky nron vytvori prepojenia medzi sprvcom identt
a poskytovatemi sluieb vyuvajcimi federciu identity; tto otzka je dleit najm
z pohadu poskytovateov sluieb, ktor chc umoni vo svojich aplikcich vyuvanie
identt od mnohch sprvcov identt.
dvera nakoko sa sprvca sluby me spoahn na spoahlivos identity a svisiacich
procesov; tu je mon do parametrov odovzdvanch o identite zahrn aj tandardizovan
vyjadrenie miery zruk spoahlivosti identity a autentizcie poda dohodnutej schmy QAA.
Obr. 4.2 SAML scenr realizcie SSO pre webov prehliadae
110
Na federciu identt je mon vyui existujce prvky v rmci aplikci, kde m by federcia
identity pouit, napr. cookies vo webovch prehliadaoch alebo pecilne typy sprv
v protokole Kerberos.
Pre otvoren systmy, kde je poiadavka na irok a flexibiln vyuvanie sluieb, je potrebn
zvoli samostatn pecifikciu, ktor bude riei pecifick problmy federcie identt.
V sasnosti s najastejie pouvan protokoly SAML (najm jeho verzia 2.0) a OpenID. Napr.
na obrzku 4.2 je uveden scenr postupu akci pri realizcii konceptu SSO pri prci s webovm
prehliadaom implementovan pomocou SAML
Federcia identt na zklade SAML 2.0 je pouvan aj pri vyuvan sluieb identifikanho
a autentifikanho modulu (IAM) PVS a je navrhovan za tandard pre ISVS.
4.6
Riadenie prstupu z pohadu prevdzky a jeho administrcia
Administrcia riadenia prstupu je dleitou sasou systmu autentizcie a autorizcie

v organizcii. To, i je systm riadenia prstupu implementovan ako centralizovan alebo
decentralizovan je zvisl na tom, o sa organizcia sna dosiahnu vo svojich bezpenostnch
cieoch. V tejto asti s vysvetlen prakticky implementovan modely riadenia prstupu spolu
s najastejie pouvanmi protokolmi a systmami. Pochopenie pecifk administrcie riadenia
prstupu je pre profesionlov informanej bezpenosti a pecialistov IT vemi dleit.
V alom texte vysvetujeme fungovanie nasledovnch implementci riadenia prstupu:
4.6.1
centralizovan riadenie prstupu (Radius,Tacacs+),

decentralizovan riadenie prstupu.
Centralizovan riadenie prstupu
V centralizovanom riaden prstupu je za poskytovanie (nastavovanie) prstupu ku zdrojom

organizcie pre jednotlivch pouvateov zodpovedn prve jedna entita (oddelenie alebo
konkrtna osoba). Tento princp riadenia prstupu poskytuje pre organizciu dve vhody:
dsledn a jednotn metda riadenia prstupov pouvateov a prstupovch oprvnen,
klovaten rieenie.
Prklady technolgi centralizovanho riadenia prstupov:
RADIUS (Remote Authentication Dial-In User Service) klient/server protokol
a softvr, ktor umouje komunikova s centrlnym serverom za elom autentizcie
vzdialene pripojench pouvateov a autorizcie ich prstupu k poadovanm systmom.
TACACS+ (Terminal Access Controller Access Control System Plus) autentizan
protokol, ktor umouje serveru pre autentizciu vzdialenho prstupu poskytn
pouvatesk prihlasovacie poverenia (credentials) autentizanmu serveru.
Protokol RADIUS
Radius je protokol uren na bezpen prenos autentizanch, autorizanch a evidennch
informci medzi serverom so sieovm prstupom, poadujcim autentizciu svojich spojen,
a zdieanm autentizanm serverom. Radius bol prijat ako tandardn protokol organizciou
IETF (RFC 2865 Remote Authentication Dial In User Service (RADIUS)).
Pri pouit RADIUS posiela klient svoje autentizan poiadavky centrlnemu serveru, ktor
obsahuje vetky pouvatesk prstupov informcie svisiace s autentizciou a sieovmi
slubami a ich sieov ACL. Server, na ktor sa pristupuje, je prevdzkovan ako klient
RADIUSu. RADIUS je otvoren protokol a je ren aj priamo v zdrojovom kde. Me by
prispsoben tak, aby spolupracoval s akmkovek bezpenostnm systmom, ktor je
111
k dispozcii. Me by taktie pouit v spoluprci s TACACS+ a Kerberosom a poskytuje PAP

(Password Authentication Protocol) alebo CHAP (Challenge Handshake Authentication Protocol)
autentizciu vzdialenho uzla.
Zkladn vlastnosti protokolu RADIUS:
pouva model klient/server,
transakcie medzi klientom a serverom s autentizovan prostrednctvom zdieanho
hesla,
ifrovan je iba heslo.
TACACS+
TACACS+ je klient/server protokol uren na sprvu autentizcie, autorizcie a tovatenosti.
Tento protokol je aj prakticky implementovan v zariadeniach rznych vrobcov. Autorizovan
mu by jednotliv pouvatelia alebo skupina pouvateov.
Pouvatesk hesl s spravovan v centrlnej databze, ktor poskytuje jednoducho
klovaten rieenie zabezpeenia siete.
Tento jednotn server riadenia prstupov v praxi znamen, e vetky sluby mu by zlen do
svojej vlastnej databzy, aby mohli vyui vhody alch sluieb dostupnch na tomto serveri
alebo sieti, v zvislosti od monost a funkcionality TACACS+ aplikcie.
TACACS+ protokol m nasledujce atribty:
4.6.2
vyuva mechanizmus dvojfaktorovej autentizcie hesla,

pouvatelia maj monos zmeni si heslo,
ifruje celkov obsah komunikcie,
sluby tohto protokolu mu by implementovan ako sas operanho systmu
sieovch zariaden.
Decentralizovan riadenie prstupu
Pri decentralizovanom riaden prstupu s pouvatelia tesnejie zviazan s monosami

riadenia prstupu. Tto architektra vak nezaisuje jednotnos a konzistentnos v rmci
organizcie. Riadenie prstupu k zdrojom si spravuj samotn vlastnci alebo tvorcovia zdrojov
(napr. sborov). Tento prstup poskytuje sce viu flexibilitu pre jednotlivch administrtorov,
ale prina zrove menej dsledn implementciu politiky riadenia prstupov. Prkladom je tzv.
domna sada objektov a subjektov, ktor maj stanoven prstupov prva k definovanm
opercim. Domny a vzahy medzi nimi s zaloen na dvere, avak vzahy zaloen na
dvere mu by asto kompromitovan, pokia nie s prijat adekvtne opatrenia. Kad
bezpenostn domna je rozdielna, pretoe ich riadia rozdielne politiky a manament.
4.6.3
Poiadavky na riadenie prstupu v organizcii
Riadenie prstupu podporuje a ovplyvuje viacer alie okruhy bezpenosti. Kad pouvate
si mus plni svoje povinnosti a nesmie prekraova svoje oprvnenia Nutnm predokladom pre
dosahovanie poadovanej rovne informanej bezpenosti v organizci je zavedenie
identifikcie, autentizcie a autorizcie. V alom texte budeme vychdza z normy ISO/IEC
27002 (tto norma je zklad pre manament informanej bezpenosti poda tandardov ISVS
a dostatone podrobne sa venuje aj riadeniu prstupu).
Poiadavky na riadenie prstupu s poda vyie uvedenej normy rozdelen do nasledujcich
oblast:
112
politika riadenia prstupu,

riadenie prstupu pouvateov,
zodpovednosti pouvateov,
riadenie prstupu ku sieti,
riadenie prstupu k operanm systmom,
riadenie prstupu k aplikcim a informcim,
mobiln vpotov zariadenia a prca na diaku.
4.6.3.1 Politika riadenia prstupu

V organizcii by mala by vytvoren, dokumentovan, pravidelne preskmavan a poda potrieb
revidovan politika riadenia prstupu. Politika riadenia prstupu m poda tejto normy bra do
vahy najm nasledujce aspekty:
bezpenostn poiadavky jednotlivch aplikci a systmov organizcie,

identifikciu vetkch informci vo vzahu k jednotlivm aplikcim a rizikm, ktorm
s informcie vystaven,
pravidl pre renie informci a pravidl schvaovania prstupu,
konzistenciu prstupovch pravidiel a klasifikciu informci pre rzne systmy a siete,
odpovedajcu legislatvu a ostatn zmluvn zvzky vo vzahu k ochrane prstupu
k dtam alebo slubm,
tandardn prstupov profily pouvateov pre ben kategrie innost,
riadenie prstupovch pravidiel v distribuovanom a sieovom prostred rozoznvajc
vetky mon typy pripojen,
oddelenie jednotlivch rol pre riadenie prstupu, napr. vybavovanie poiadaviek na
prstup, schvaovanie prstupu, sprva prstupov,
poiadavky na formlne schvlenie iadosti o prstup,
poiadavky na pravideln preskmavanie prstupovch prv,
odoberanie prstupovch prv.
Pri tvorbe a stanovovan pravidiel riadenia prstupu by mali by zven aj hadisk ako s napr.
rozliovanie medzi pravidlami, ktor musia by v platnosti vdy a tmi, ktor s nepovinn alebo
podmienen, medzi pravidlami, ktor vyaduj schvlenie administrtorom alebo inou poverenou
osobou a tmi, ktor toto nevyaduj, definovanie pravidiel na zklade princpu vetko, o nie
je vslovne povolen, je zakzan, nie na zklade pravidla vetko, o nie je vslovne zakzan,
je povolen.
4.6.3.2 Riadenie prstupu pouvateov
Hlavnm cieom v tejto asti definovanch opatren je zaisti oprvnen prstup pouvateov
a predchdza neoprvnenmu prstupu k informanm systmom organizcie. V oblasti riadenia
prstupov definuje tto norma viacer okruhy opatren, ktor by mal pecialista IT v primeranej
miere implementova do prostredia organizcie.
Registrcia pouvatea
Vo vntornch predpisoch organizcie by mali by definovan formlne postupy pre registrciu
pouvateov vrtane jej zruenia, ktorch lohou je zabezpei autorizovan prstup ku vetkm
viacpouvateskm informanm systmom a slubm.
Postupy pre registrciu pouvatea a jej zruenie poda tejto normy zahruj viacer opatrenia,
ako napr.:
113
pouitie uniktneho pouvateskho identifiktora (ID),

kontrolu toho, e pouvate m oprvnenia pouva informan systm alebo sluby od
vlastnka systmu, shlas s prstupovmi prvami od nadriadench pouvatea,
kontrolu toho, e rove pridelenho prstupu zodpoved zmerom organizcie a je
v slade s bezpenostnou politikou organizcie,
procesy odovzdvania zoznamu vymedzujceho prstupov prva jednotlivm

pouvateom,
udriavanie formlneho zoznamu o registrovanch osobch oprvnench vyuva
slubu alebo systm,
procesy, ktor zabezpeia okamit odobratie prstupovch oprvnen pouvateom,
ktor zmenili pracovn miesto alebo opustili organizciu,
pravideln kontrolovanie a mazanie nepotrebnch ID pouvateov a ich tov.
Riadenie privilegovanho prstupu

Vo viacpouvateskch informanch systmoch, pri ktorch je nevyhnutn ochrana proti
neautorizovanmu prstupu, by malo by prideovanie privilegovanch oprvnen riaden
prostrednctvom formlneho autorizanho procesu. Pri riaden privilegovanho prstupu poda
tejto normy implementujeme opatrenia ako napr.:
udriavanie popisu privilgi spojench s kadm prvkom systmu (napr. s OS,
databzovm systmom, aplikciami) a kategrie zamestnancov, ktorm by mali by
privilgi pridelen,
prideova privilgia iba na zklade oprvnenej potreby pre pouitie,
mal by by dodriavan proces autorizcie a zachovvan zznam o vetkch
pridelench privilgich, privilgia by nemali by pridelen, pokia nie je proces
autorizcie dokonen.
Sprva pouvateskch hesiel
Sprva pouvateskch hesiel by sa mala riadi formlnym procesom definovanm vo
vntornch predpisoch organizcie, kee hesl s benm prostriedkom na overenie identity
pouvatea pred poskytnutm prstupu ku systmu. Okrem hesiel je potrebn zvi aj pouitie
inch technolgi autentizcie a identifikcie pouvatea ako je naprklad biometria (napr.
odtlaok prsta, onej rohovky), elektronick podpis alebo pouitie technickch prostriedkov
(napr. ipovch kariet).
Pre tento proces je definovanch viacero poiadaviek, ktorm by mal vyhovova, ako napr.
podpis prehlsenia o bezpenom pouvan hesiel, zaistenie povinnosti zmeny jednorazovho
hesla, zavedenie postupov jednoznanej identifikcie pouvateov pred poskytnutm novho,
nhradnho alebo doasnho hesla, povinnos nenechva hesl a alie autentizan prostriedky
v nechrnenom tvare, zmena prednastavench hesiel.
Preskmavanie prstupovch oprvnen pouvatea
Opatrenie zavdza povinnos v pravidelnch intervaloch uskutoova formlne preskmavanie
prstupovch oprvnen pouvateov.
Odporan interval pre preskmavanie je poda tejto normy 6 mesiacov a po kadej vznamnej
zmene ako napr. povenie, preloenie alebo ukonenie pracovnho pomeru. Naproti tomu
preskmavanie privilegovanch prstupovch oprvnen sa odpora vykonva v astejch
intervaloch (odporan s 3 mesiace). Vetky zmeny v pridelench privilgich by mali by
taktie dkladne zaznamenvan pre potreby preskmavania a auditu.
4.6.3.3 Zodpovednosti pouvateov
Pouvatelia si musia by vedom zodpovednosti za dodriavanie nasadench opatren kontroly
prstupu ku zdrojom organizcie, hlavne s ohadom na pouvanie hesiel a bezpenosti im
pridelench prostriedkov a zariaden. Efektvnym zavedenm svisiacich procedr do vntornch
predpisov organizcie je mon minimalizova rizik ako je neoprvnen pouvatesk prstup
k citlivm informcim i prezradenie alebo krde informci a prostriedkov na ich spracvanie.
Pouvanie hesiel
Pouvateom maj by dostupn prehadn odporania pre vytvorenie a pouvanie
bezpench prstupovch hesiel.
114
Tto norma odpora definova postupy a procedry svisiace s pouvanm hesiel, tvorbou
hesiel a ich zaznamenvanm, s intervalmi zmeny hesiel (pravideln, pri nznaku kompromitcie
systmu) a pod. Ak pouvatelia potrebuj, aby mali prstup k viacerm slubm alebo
platformm, odpora tto norma pouva jedno siln heslo pre vetky sluby, pri ktorch s si
pouvatelia ist, e poskytuj rozumn rove zabezpeenia.
Neobsluhovan pouvatesk zariadenia
Pouvatelia a dodvatelia maj by oboznmen s bezpenostnmi poiadavkami a postupmi pre
primeran ochranu neobsluhovanch zariaden.
Niektor zariadenia pouvan v organizcich, ktor s zdieane pouvan viacermi
zamestnancami alebo mu by verejne prstupn, nie s z pohadu bezpenosti chrnen na
takej rovni, ako ostatn zariadenia IKT (napr. pracovn stanice zamestnancov). Ide najm
o zariadenia ako zdiean tlaiarne, pracovn stanice uren na koliace ely, verejne prstupn
PC. Tieto zariadenia si vyaduj pecifick reim prce s nimi a zvltnu ochranu pred
neautorizovanm prstupom, najm ak bvaj dlh as ponechan bez dozoru.
Politika istho stola a istej obrazovky
Na kadom pracovisku sa spravidla pohybuje viacero osb, o pre vone uloen aktva a citliv
informcie predstavuje vrazn riziko. Vina bench zamestnancov nevenuje pozornos
informcim uskladnenm na ich pracovnch stoloch a zabezpeenie potaov tak me strca
svoj inok.
Zsady politiky istho stola a istej obrazovky vrazne zniuj riziko niku a zneuitia dajov.
Ma ist pracovn stl (odstrni z neho pamov mdi a dokumenty, kde by sa mohli
nachdza neverejn i citliv informcie) ako aj odhlsi sa z IS v ase neprtomnosti vo vekej
miere zniuje pravdepodobnos nastania bezpenostnho incidentu.
4.6.3.4 Riadenie prstupu k sieti
S cieom predchdza neautorizovanmu prstupu k sieovm slubm by mal by intern ako aj
extern prstup k tmto slubm formlne riaden. V tejto asti riadenia prstupov definuje
norma viacer okruhy opatren, ich rozsah je zvisl najm na vekosti a zloitosti sieovho
prostredia organizcie.
Politika pouvania sieovch sluieb
Pouvatelia by mali ma priamy prstup iba k tm sieovm slubm, pre ktorch pouitie boli
oprvnen. Neoprvnen alebo nezabezpeen pripojenie k sieovm slubm me ma vplyv
na cel organizciu. Opatrenia v tejto oblasti s potrebn najm pri sieovch pripojeniach
k citlivm alebo kritickm aplikcim organizcie i pri pouvateoch pripjajcich sa
z rizikovch lokalt.
Politika formulovan vo vzahu k sieam a sieovm slubm by mala pokrva autorizan
postupy urujce, kto je oprvnen pristupova k akm sieam a sieovm slubm, kontroln
mechanizmy a postupy na ochranu prstupu k sieovm pripojeniam a slubm prpadne udelen
vnimky prstupu. Tto politika by mala by samozrejme v slade s politikou riadenia prstupu
a politikou bezpenosti IS.
Autentizcia pouvatea externho pripojenia
Prstup vzdialench pouvateov mus by autentizovan. Tto autentizcia me by
zabezpeen napr. pouitm kryptografickch technk, autentizanch predmetov (hardvrovch
tokenov) alebo protokolom typu vzva/odpove. Implementciu takchto technk vyuvaj
napr. virtulne privtne siete VPN siete.
115
Odpora sa zvi nasadenie ochrany pred neautorizovanm alebo nechcenm pripojeniam

k prostriedkom na spracovanie informci (opatrenia typu sptnho volania dial-back). Pre
autentizciu uzlov siete mu by pouit kryptografick techniky, napr. zaloen na
certifiktoch fyzickch potaov. Pre bezpen prstup k bezdrtovm sieam je potrebn
taktie implementova dodaton techniky autentizcie a definova pravidl pouvania
bezpenostnch mechanizmov a autentizanch predmetov.
Hrozbu predstavuje aj monos automatickho pripojenia ku vzdialenm potaom, o me
ma za nsledok zskanie neoprvnenho prstupu k aplikcim organizcie. iadatelia o
vzdialen pripojenia k potaovm systmom by mali by preto vdy autentizovan a riadi sa
pravidlami, ktor je potrebn definova vo vntornch predpisoch organizcie.
Identifikcia zariaden v sieach

Pre autentizciu pripojen z vybranch lokalt a prenosnch zariaden odpora tto norma zvi
automatick identifikciu zariaden. Je to spsob, ktor me by pouit v prpadoch, ak je
dleit, aby bola komunikcia inicializovan iba z uritej lokality alebo zariadenia.
Automatick identifikcia zariaden v sieach me by doplnen o alie techniky autentizcie
pouvateov tchto zariaden.
Ochrana portov pre vzdialen diagnostiku a konfigurciu
Fyzick i logick prstup k diagnostickm a konfiguranm portom by mal by bezpene
riaden. Vea komunikanch, potaovch a sieovch systmov me obsahova prostriedky
na vzdialen konfigurciu a vzdialen prstup, ktor vyuva podporn personl na drbu
systmu. V prpade, e tieto porty nie s chrnen, predstavuj zneuiten prostriedok na
neautorizovan prstup do systmu.
Primeranm bezpenostnm mechanizmom me by uzamknutie klvesnice a pouitie alch
mechanizmov zamedzujcich fyzick prstup k portom i povolenie prstupu k tmto portom
vhradne na zklade dohody medzi sprvcom sluby a personlom zabezpeujcim podporu
technickho a programovho vybavenia
Princp oddelenia siet
Skupiny informanch sluieb, pouvateov a informanch systmov by mali by v sieach
oddelen. Oddelenie v sieach by malo by zaloen na klasifikci ukladanch
a spracovvanch informcich, rovne dvernosti a typu innosti, ktormi sa organizcia
zaober tak, aby bol v prpade naruenia sluieb minimalizovan celkov dopad na organizciu.
Norma ISO/IEC 27002 poskytuje viacero odporan k realizcii ako je rozdelenie siet do
separtnych logickch domn, intalcia bezpenostnch brn (firewallov) medzi miesta
prepojen siet, oddelenie s vyuitm funknosti sieovch zariaden (napr. prepnanm protokolu
IP) a pod.
Riadenie sieovch spojen
Pri zdieanch sieach, hlavne pri tch, ktor presahuj hranice organizcie, mus by
obmedzen monosti pripojenia pouvateov. Obmedzenia by mali by v slade s politikou
riadenia prstupu a s poiadavkami jednotlivch aplikci. Medzi prklady, kde by mali by
nasaden obmedzenia mono poda tejto normy zaradi napr. odosielanie sprv (elektronick
pota), prenos sborov, interaktvny prstup i prstup k aplikcim.
Riadenie smerovania siete
Pre zabezpeenie toho, aby potaov spojenia a informan toky nenaruovali politiku riadenia
prstupu aplikci organizcie, by malo by zaveden riadenie smerovania v sieti. Smerovanie
v sieti by malo by zaloen na overen zdrojovej a cieovej adresy. Pokia s vyuvan proxy
116
servery a/alebo preklad sieovch adries, mu by k overeniu zdrojovej cieovej adresy vyuit
bezpenostn brny umiestnen na internch a externch kontrolnch sieovch bodoch.
4.6.3.5 Riadenie prstupu k operanmu systmu
Pre obmedzenie prstupu k prostriedkom potaa by mali by implementovan dostaton
bezpenostn prostriedky na rovni operanch systmov. Tieto prostriedky musia zabezpeova
innosti ako s autentizcia oprvnench pouvateov v slade s politikou riadenia prstupov,
zaznamenvanie spench a nespench pokusov o autentizciu, zaznamenvanie vyuitia
privilegovanch prstupov, systm varovania v prpade poruenia systmovch bezpenostnch
politk a pod.
Norma definuje tto viacer okruhy opatren, ktor by mal pri implementci bezpenosti riadenia
prstupov k OS pecialista IT zvi a v primeranej miere implementova.
Bezpen postupy prihlsenia
Prstup k operanmu systmu mus by riaden postupmi bezpenho prihlsenia, ktor s
definovan vo vntornch predpisoch organizcie. Postup prihlsenia mus by implementovan
tak, aby boli minimalizovan prleitosti neoprvnenho prstupu a mal by prezrdza minimum
informci o systme, aby neposkytoval zbyton podporu neoprvnenmu pouvateovi.
Dobr prihlasovac postup spa viacer podmienky, ako s nezobrazova identifiktor systmu
km nie je proces prihlsenia kompletn, neposkytova monos npovede, obmedzi poet
povolench nespench pokusov (odporaj sa 3), zvi zaznamenvanie nespench
pokusov prpadne zvi obmedzenie minimlnej a maximlnej doby prihlsenia.
Identifikcia a autentizcia pouvateov
Vetci pouvatelia by mali ma pre svoje vhradn pouitie priraden jedinen identifiktor,
mal by by takisto zvolen vhodn spsob autentizcie k overeniu ich identity. Pre potreby
identifikcie a autentizcie sa najastejie vyuvaj hesl. Rovnak vsledok dosiahneme aj
pomocou kryptografickch prostriedkov a autentizanch protokolov, stupe pouitej
identifikcia a autentizcie by mal vak zodpoveda rovni citlivosti chrnench informci.
Systm sprvy hesiel
Systm sprvy hesiel by mal by interaktvny a mal by zabezpeova pouitie dostatone
kvalitnch hesiel. V tejto norme s definovan viacer odporania, ktor by mali IT pecialisti
pri tvorbe systmu sprvy hesiel zohadni, ako je presadzova pouvanie individulnych hesiel
a uvateskch ID, umoni pouvateom zvoli a zmeni si svoje vlastn heslo, presadzova
vber kvalitnch hesiel, v prpade doasnho hesla vyadova od pouvatea jeho zmenu, pri
zadvan hesla ho nezobrazova na obrazovke, vyadova ukladanie hesiel v ifrovanej podobe
a pod.
Pouvanie systmovch nstrojov
Monos pouitia systmovch nstrojov, ktor mu prekona systmov alebo aplikan
kontroln mechanizmy, mus by v kadej organizcii obmedzen a prsne kontrolovan. Mali by
by zven opatrenia ako s oddelenie systmovch nstrojov od aplikanch programov,
obmedzenie pouvania systmovch nstrojov iba pre minimlny poet dveryhodnch
pouvateov, zaznamenvanie kadho pouitia systmovch nstrojov, odstrnenie vetkch
nepotrebnch nstrojov a systmovch programov a pod.
asov obmedzenie relcie
Neaktvne relcie by sa mali po stanovenej dobe neinnosti ukoni. asov mechanizmus by
mal po definovanej dobe zmaza obsah obrazovky a v prpade potreby ukoni prebiehajce
aplikcie prpadne sieov relcie. as obmedzenia relcie by mal odra bezpenostn rizik
117
vyplvajce z priestorov, klasifikciu informci, pouvan aplikcie ako aj pouvateov, ktor

zariadenie vyuvaj.
asov obmedzenie spojenia
Vymedzenie doby, po ktor je povolen pripojenie k potaovm slubm, obmedzuje
prleitos pre neoprvnen prstup, takisto zamedzuje pouvateom ponecha relcie otvoren
a vyhn sa tak optovnej autentizcii. Toto opatrenie by sa malo zvi najm pri citlivch
potaovch aplikcich, ktor s vyuvan vo vysoko rizikovch lokalitch, napr. vo
verejnch alebo externch priestoroch mimo psobnos bezpenostnej sprvy organizcie.
4.6.3.6 Riadenie prstupu k aplikcim a informcim
Hlavnm cieom tejto asti je definova opatrenia, ktorch implementciou sa bude predchdza
neoprvnenmu prstupu k informcim uloenm v potaovch systmoch. Pre obmedzenie
prstupu k tmto systmom by mali by pouit bezpenostn prostriedky, logick prstup mus
by obmedzen iba pre oprvnench pouvateov.
Obmedzenie prstupu k informcim
Pouvatelia aplikanch programov, vrtane pracovnkov podpory, musia ma prstup
k informcim a funkcim aplikanch systmov obmedzen v slade s definovanou politikou
riadenia prstupu. Poda tejto normy by sa malo zvi aj vyuitie opatren ako s napr.
obmedzenie prstupovch oprvnen pouvateov (napr. na tanie, zpis, mazanie, spanie),
obmedzenie prstupovch oprvnen zo strany alch aplikci i zabezpeenie toho, e vstupy
aplikanch systmov narbajcich s citlivmi dajmi obsahuj iba relevantn daje.
Oddelenie citlivch systmov
Citliv aplikan systmy by mali by implementovan v oddelench, prpadne izolovanch
prostrediach. Citlivos sluieb systmu alebo informci v om spracvanch me napr.
urova, i by mal by aplikan systm prevdzkovan iba na vyhradenom potai alebo smie
zdiea zdroje iba s dveryhodnmi aplikanmi systmami. Izolcia citlivch aplikanch
systmov me by zabezpeen aj ich fyzickm alebo logickm oddelenm.
4.6.3.7 Mobiln vpotov zariadenia a prca na diaku 108
V prpade pouvania mobilnch vpotovch prostriedkov (napr. notebook, laptop, mobiln
telefn) v organizcii by mala by venovan zven pozornos tomu, aby neboli citliv
informcie organizcie prezraden prve prostrednctvom tchto zariaden. Mali by by prijat
formlne pravidl, ktor by zohadovali rizik prce s mobilnmi vpotovmi zariadeniami,
hlavne v nezabezpeenom prostred. Tieto pravidl musia zaha napr. poiadavky na fyzick
ochranu, kontrolu prstupu, kryptografick techniky, zlohovanie i antivrusov ochranu. Tieto
pravidl by mali taktie zaha odporania pre pripjanie tchto zariaden do cudzch siet,
riziko predstavuj najm bezdrtov siete a ich znme bezpenostn slabiny.
Organizcia by mala schvli aktivity prce na diaku iba vtedy, ak s splnen zodpovedajce
bezpenostn poiadavky a s zaveden opatrenia, ktor s v slade s bezpenostnou politikou
organizcie. Je dleit, aby prca na diaku bola schvaovan a kontrolovan vedcimi
zamestnancami a aby boli zaveden vhodn podmienky pre tento druh prce. Norma odpora
zvi viacer okolnosti svisiace s touto oblasou, ako napr. poiadavky na komunikan
bezpenos, citlivos informci, ku ktorm sa pristupuje a ktor s prenan komunikanmi
linkami i okolnosti bezpenosti prostredia prce na diaku.
108
Poiadavky normy ISO/IEC 27022 koreponduj s prechdzajcim textom v tejto kapitole (4.4.
Vzdialen prstup pomocou mobilnch zariaden), na tomto mieste ich uvdzame pre plnos.
118
4.7
Normalizovan koncept systmu riadenia prstupu
Riadenie prstupov v organizcii predstavuje sbor procesov a postupov, ktor umon

jednotlivm entitm (napr. osobe, zariadeniu, systmu, slube) efektvne a najm bezpene
vyuva informan zdroje organizcie a zrove tmto entitm priraova zodpovednosti za
vykonan innosti.
Podobne ako pri inch systmoch riadenia (napr. pri systme riadenia informanej bezpenosti),
aj pre systm riadenia prstupov k informanm zdrojom organizcie je potrebn definova
ucelen rmec komplexne pokrvajci bezpen implementciu a prevdzku tohto systmu.
Definovanie rmca pre systm riadenia prstupov je aj snahou medzinrodnch organizci ako s
ISO a IEC. V tejto oblasti vyvjaj medzinrodne akceptovaten normu ISO/IEC 29146
A framework for access management, ktor bude problematiku podrobne pecifikova a urova
najlepie postupy riadenia prstupov. V ase tvorby tohto materilu bola tto norma v pokroilom
tdiu vvoja, prebiehalo intenzvne pripomienkovanie na medzinrodnej rovni. Cieov dtum
konenho schvlenia a vydania tejto normy je naplnovan na rok 2014.
4.7.1
Model riadenia prstupu ku zdrojom
Riadenie prstupu ku zdrojom organizcie zaha poda ISO/IEC 29146 niekoko zkladnch
entt. Na obrzku 4.3 [ISO/IEC CD 29146 Information technology - Security techniques - A
framework for access management] s znzornen jednotliv kroky realizovan pri prstupe ku
zdrojom organizcie:
autentizovan subjekt (napr. osoba alebo systmov komponent IS) potvrdzuje
poiadavku na prstup ku konkrtnemu zdroju,
v bode rozhodnutia o politike (angl. Policy decision point) sa over iados a vyd
povolenie na prstup,
v bode vyntenia politiky (angl. Policy enforcement point) sa overia prstupov
oprvnenia a umon sa autentizovanmu subjektu prstup ku chrnenmu zdroju.
Autentizovan
subjekt
Bod vyntenia politiky
Chrnen
zdroj
Bod rozhodnutia o politike
Obr. 4.3 Model riadenia prstupu poda ISO/IEC 29146

4.7.2
Zloky systmu riadenia prstupov
Norma ISO/IEC 29146 vysvetuje nasledovn funkn oblasti systmu riadenia prstupov:
pravidl pre riadenie privilgi (angl. Policy and Privilege management),
riadenie autorizanch atribtov (angl. Authorization attribute management),
autorizcia subjektu,
priraovanie zdrojov subjektom (angl. Provisioning),
monitorovanie a sledovatenos vykonanch innost (angl. Monitoring, accountability
and traceability).
Pravidl pre riadenie privilgi
119
Riadenie privilgi je proces tvorby, sprvy, prideovania a odoberania privilgi konkrtnym

subjektom. Priradenie privilgi konkrtnej entite umouje tejto entite sta sa subjektom
v procese riadenia prstupov. Sbor privilgi pouvan v systme riadenia prstupov by mal by
truktrovan v slade s modelom, ktor sa tka aktivt organizcie, subjektov vykonvajcich
tieto aktivity, prevdzkovanch sluieb a zdrojov organizcie. Tieto privilgi by mali by
pecifick pre:
jednotliv subjekty a autorizan atribty,
konkrtne zdroje alebo triedu zdrojov,
spsob pouitia zdrojov.
Riadenie privilgi pozostva z nasledovnch aktivt:
definovanie pravidiel a privilgi na prstup ku zdrojom,
definovanie pravidiel a privilgi pre PDP prpadne definovanie atribtov pre manament
identt,
aktualizcia, prehodnotenie, prpadne zruenie konkrtnych pravidiel a privilgi,
uplatovanie pravidiel a privilgi v procese overovania poiadaviek na prstup ku
zdrojom organizcie.
Riadenie privilgi by malo by implementovan na zklade princpu oprvnenej potreby
pozna s pouitm najmench monch privilgi pre dan subjekt. Malo by by garantovan,
e tento subjekt me s danmi privilgiami pristupova ku konkrtnym zdrojom organizcie.
Riadenie autorizanch atribtov
Proces riadenia autorizanch atribtov zaha priraovanie, modifikciu a odoberanie tchto
atribtov jednotlivm subjektom. Konkrtnymi atribtmi pre subjekt mu by napr. vek,
pozcia, lenstvo v skupinch, funkcia, typ kontraktu i certifikt. Pre zdroj mu by tmito
atribtmi rzne typy klasifikcie, adresa i certifikovan znaka (napr. vlastnctvo sieovho
identifiktora). Autorizan atribty mu by usporiadan do rol.
Autorizcia subjektu
Proces autorizcie subjektu me by uskutoovan automatizovane na zklade definovanho
sboru pravidiel, prpadne me vyadova udsk zsah, pri ktorom osoba s nleitmi
oprvneniami autorizuje poadovan pridelenie privilgi. Za uritch podmienok me entita
legitmne delegova svoje konkrtne oprvnenia na in entitu. V tomto prpade sa jedn
o delegovan autorizciu.
Autorizcia subjektu by mala by vykonvan v slade s pravidlami, ktor by mali pecifikova:
entity, ktor uruj autorizan postupy,
entity, ktor uskutouj on-line autorizciu,
procedry, ktor vykonvaj off-line autentizciu,
rove zabezpeenia vyadovanej pri autentizcii subjektu.
Proces priraovania zdrojov subjektom (Provisioning)
Provisioning je proces poskytnutia prostriedkov subjektom za elom prstupu k informcim
alebo systmovm zdrojom organizcie. Proces je zaloen na rolch priradench konkrtnym
subjektom a oprvneniach spojench s tmito rolami. Provisioning mono rozdeli na tri
zkladn kategrie:
proces priraovania privilgi (angl. privilege provisioning),
proces priraovania zdrojov (angl. resource provisioning),
proces priraovanie tov IKT (angl. ICT account provisioning).
Monitorovanie a sledovatenos vykonanch innost
Aktivity a innosti spojen s riadenm prstupu ku zdrojom organizcie musia by monitorovan
za elom dosahovania sladu s prvnymi, funknmi a bezpenostnmi poiadavkami ako aj v
120
prpade vyetrovania bezpenostnch incidentov. Odpora sa monitorova najm nasledujce

innosti:
prstup ku zdrojom personlnymi subjektmi organizcie,
prstupy do systmov externmi subjektmi, audtormi prpadne inmi poverenmi
osobami,
procedry administrcie prstupu vykonvan administrtormi,
prstup vzdialench subjektov ku zdrojom systmu,
prstup zariaden ku zdrojom systmu,
vytvranie a bezpenos auditnch zznamov a zpisov v registroch.
Systm riadenia prstupu by mal vytvra auditn zznamy najm o:
autorizanch innostiach pre poskytovanie privilgi,
priradench privilgich a autorizanch atribtoch,
udelench povoleniach na vyuvanie zdrojov,
skutonom pouit zdrojov.
4.7.3
Referenn architektra riadenia prstupov
Referenn architektra poda normy ISO/IEC 29146 obsahuje nasledovn komponenty systmu
riadenia prstupu:
Subjekt: inicializan bod, ktor poaduje prstup ku zdrojom organizcie.
Zdroj: predstavuje koncov bod, ku ktormu je po spenej autentizcii a autorizcii
umonen poadovan prstup.
Bod vyntenia politiky (angl. PEP Policy enforcement point): tento komponent me
poadova autentizciu a nsledne si vynti autorizan rozhodnutia. PEP popisuje
atribty jednotlivch subjektov pre potreby inch entt v rmci systmu.
Bod rozhodnutia o politike (angl. PDP Policy decision point): tento komponent
uskutouje autorizan rozhodnutia ako odpove na poiadavky PEP.
Sluby pre bezpenostn tokeny (angl. Security token service): tieto sluby prekladaj
autorizan rozhodnutia do bezpenostnch tokenov, tieto tokeny mu by pouit na
delegovanie prstupu.
Bod administrcie politiky (angl. PAP Policy and attribute administration point): sli
ako centrlny administran bod informci o politike a atribtoch.
Informcie o politike (angl. Policy information): komponent obsahuje informcie
o pravidlch a atribtoch jednotlivch zdrojov, ktor s zahrnut v procese autorizcie.
Monitorovanie: tento komponent monitoruje innosti a lohy poas celho procesu
riadenia prstupu, zvl v prpadoch, ke sa udeuje alebo zamieta prstup ku zdrojom
organizcie.
121
Obr. 4.4 Referenn architektra systmu riadenia prstupov poda ISO/IEC CD 29146
Information technology - Security techniques - A framework for access management
4.8
Auditovanie systmu riadenia prstupov
Vkon auditu riadenia prstupov me by formou internho alebo externho auditu. Pri
externch auditoch s vyuvan sluby nezvislej tretej strany, pri internom audite vykonvaj
poveren zamestnanci organizcie na zklade svojich pracovnch zodpovednost, poiadaviek
manamentu prpadne po vznamnch zmench preskmanie systmu riadenia prstupov.
Auditovanie systmu riadenia prstupov bva spravidla sasou komplexnejieho auditu
vykonvanho v prostred organizci, pri jeho realizcii je odporan riadi sa medzinrodnmi
tandardami v oblasti auditu IKT (napr. audtorsk tandardy a smernice ISACA), poiadavkami
prslunch prvnych predpisov (napr. Vnos o tandardoch pre ISVS) ako aj poiadavkami
dobrej praxe (napr. ISO/IEC 27002 Pravidl dobrej praxe manarstva informanej bezpenosti).
Pri preskmavan systmu riadenia prstupov by mal audtor:
zska veobecn prehad o bezpenostnch rizikch existujcich pri spracovan
informci prostrednctvom preskmania prslunej dokumentcie, dotazovanm
konkrtnych subjektov, pozorovanm a pouvanm technk hodnotenia rizk,
dokumentova a vyhodnoti opatrenia svisiace s prstupovmi cestami do systmu
s cieom posdi ich primeranos, innos a efektvnos prostrednctvom kontroly
funkci softvrovch a hardvrovch komponentov a identifikova prpadn nedostatky
a redundancie,
testova pouit opatrenia svisiace s riadenm prstupov prostrednctvom vhodnch
technk auditu a uri, i s v praxi efektvne a bezpene vyuvan,
122
vyhodnoti prostredie riadenia prstupov s cieom uri, i s existujce opatrenia

svisiace s riadenm prstupov implementovan na zklade vykonanej analzy rizk
prpadne inch auditnch zisten,
vyhodnoti systm riadenia bezpenosti prostrednctvom preskmania vntornch
predpisov organizcie, uskutoovanch procedr a innost svisiacich s riadenm
prstupov a ich porovnanm so svisiacimi bezpenostnmi tandardami a poiadavkami
dobrej praxe.
Zoznmenie sa s IT prostredm organizcie

Oboznmenie sa s IT prostredm organizcie by mal by prv krok vykonvanho auditu
a obsahova zskanie jasnej predstavy o organizanom, technickom a bezpenostnom prostred
prevdzkovanho systmu riadenia prstupov. Tento krok zvyajne zaha uskutonenie
rozhovorov s relevantnmi osobami, fyzick preskmanie priestorov i preskmanie existujcej
dokumentcie svisiacej s auditovanm prostredm.
Dokumentovanie a posdenie prstupovch ciest ku zdrojom organizcie
Prstupov cesta je logick postupnos krokov, ktor vyuva koncov pouvate na zskanie
prstupu k informcim uloenm na prostriedkoch vpotovej techniky. Tto cesta zana
zvyajne na konkrtnom PC/terminle a kon sprstupnenm dt alebo sluieb pouvateovi. Jej
sasou s hardvrov a softvrov komponenty, audtor IS by mal vetky tieto komponenty
analyzova a zisti, i s efektvne a bezpene implementovan. Pri audite by sa mala osobitn
pozornos venova najm:
pvodu a autorizcii dt,
platnosti a sprvnosti vstupnch dt,
riadeniu ivotnho cyklu prstupovch oprvnen,
sprve hesiel a alch autentizanch prostriedkov,
hrozbm zo siete internet (napr. sql injection, cross-site scripting, path traversal).
Rozhovory so zainteresovanmi osobami
Na riadenie a udriavanie jednotlivch komponentov prstupovch ciest s spravidla vyadovan
technick pecialisti a experti na dan oblas. Pre audtora IS mu by tto pecialisti dleitm
zdrojom informci pre pochopenie pecifk danej oblasti bezpenosti. Pre zistenie, s ktormi
zainteresovanmi osobami je potrebn uskutoni rozhovory, by mal audtor IS konzultova tto
zleitos s manarom IKT ako aj preskma organizan truktru. Medzi kov pozcie
patr napr. administrtor bezpenosti, sieov administrtor i administrtor aplikci.
Pri rozhovoroch so zainteresovanmi osobami by mali by identifikovan vetky zodpovednosti
a funkcie, ktor vyplvaj z ich pracovnch pozci. Audtor IS by mal by naprklad schopn
uri, i m administrtor bezpenosti dostaton povedomie a prehad o logickch prstupoch
ku zdrojom organizcie, ako aj i m k dispozcii dostaton prostriedky a podmienky ako tieto
prstupy aktvne administrova, sledova, vyhodnocova, prpadne flexibilne reagova na
vzniknut bezpenostn incidenty.
Audtor IS by mal uskutoni aj rozhovory so vzorkou konench pouvateov IS s cieom
zisti, i maj dostaton povedomie o bezpenostnch politikch, prpadne inch vntornch
predpisoch upravujcich povinnosti pri prstupe ku zdrojom organizcie.
Preskmavanie zznamov z aplikcie na riadenie prstupov
Schopnos aplikci na riadenie prstupu poskytova podrobn zostavy o uskutonench
prstupoch ku zdrojom organizcie umouje administrtorom monitorova dodriavanie
pravidiel svisiacich s riadenm prstupu, ktor s vinou uveden v bezpenostnch politikch
a alch vntornch predpisoch organizcie. Na zklade preskmania vzorky tchto zostv by
mal by audtor IS schopn uri, i administrtori vykonvaj dostaton innosti svisiace
s administrciou, preskmavanm i reakciou na zisten incidenty svisiace s riadenm prstupov.
Nespen pokusy o prstup ku zdrojom organizcie by mali by preskman a mali by ma
123
identifikovan ich atribty ako s as nespenho prihlsenia, miesto, z ktorho bol tento
prstup uskutonen, ako aj dta i sluby, ku ktorm bol prstup poadovan.
Preskmavanie prevdzkovej dokumentcie systmov
Prevdzkov dokumentcia systmov by mala obsahova sbor pravidiel, ktor sa vo
veobecnosti vyuvaj v rmci spracovania dt na podporu vvoja, implementcie, prevdzky
a pouvania systmov v prostred organizcie. Tto prevdzkov dokumentcia by mala
obsahova napr. informcie o platforme, na ktorej me by aplikcia prevdzkovan, o
databzovch systmoch /DBMS, ktor vyuva, kompiltoroch a interpreteroch, o sieovch
monitorovacch nstrojoch a alch podpornch funkcich.
124
4.9 Zoznam pouitej literatry

[1]
NIST Special Publication 800-118 -- Guide to Enterprise Password Management (Draft).
[2]
NIST Special Pub 800-12 - An Introduction to Computer Security: The NIST Handbook.
[3]
CERTIFIED INFORMATION SYSTEMS AUDITOR CISA Review Manual

2011,2010 ISACA.
[4]
Certified Information Systems Security Professional Student Guide Version 1.0, 2005
Thomson NETg, a division of Thomson Learning.
[5]
Information Security Forum: Standard of Good Practice. 2007.
[6]
STN ISO/IEC 27002 - Informan technolgie. Zabezpeovacie techniky. Pravidl

dobrej praxe manarstva informanej bezpenosti.
[7]
STN ISO/IEC 27005:2011 Informan technolgie. Bezpenostn metdy. Riadenie rizk

informanej bezpenosti.
[8]
ISO/IEC WD 29146.6 Information technology Security techniques A framework

for access management.
[9]
STORK project. [Online] [Dtum: 27. 9. 2013.] https://www.eid-stork.eu/.
[10] STORK 2.0 - Secure idenTity acrOss boRders linKed 2.0. [Online] [Dtum: 27. 9. 2013.]
https://www.eid-stork2.eu/.
[11] pecifikcie SAML. OASIS Security Services (SAML) TC. [Online] [Dtum: 27. 9.
2013.] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security.
[12] Google Apps Platform. SAML Single Sign-On (SSO) Service for Google Apps. [Online]
[Dtum:
27.
9.
2013.]
https://developers.google.com/googleapps/sso/saml_reference_implementation.
[13] OpenID - The OpenID
http://openid.net/foundation/.
Foundation.
[Online]
[Dtum:
27.
9.
2013.]
[14] pecifikcia OAuth 2.0. [Online] [Dtum: 27. 9. 2013.] http://tools.ietf.org/html/rfc6749.
125
5 Aplikan bezpenos
Erik Saller
5.1 vod
Cieom tejto kapitoly je poskytn prehad aplikanej bezpenosti.
Aplikan bezpenos je oblas informanej bezpenosti, ktor sa zaober ochranou
softvrovch aplikci poas celho ich ivotnho cyklu. Zavdza opatrenia na presadzovanie
bezpenostnej politiky aplikcie a/alebo system, na ktorom aplikcia be, najm opatrenia ktor
maj zabrni bezpenostnm problmom (incidentom) spsobenm chybami v nvrhu, vvoji,
nasaden, aktualizcii, alebo drbe aplikcie. [1]
Primrnym cieom aplikanej bezpenosti je dosiahnu, aby aplikcie neobsahovali rzne
bezpenostn nedostatky, ktor mu by zneuit tonkom na kompromitciu dajov
spracovvanch aplikciou, kompromitciu samotnej aplikcie alebo infratruktry, na ktorej je
aplikcia prevdzkovan.
Kompromitcia informanch aktv je najm poruenie integrity, dvernosti alebo dostupnosti
informanch aktv.
Aplikan bezpenos m rzne aspekty, ktormi je potrebn sa zaobera, ak chceme pochopi
ak hrozby sa pri pouvan zranitench aplikci vyskytuj, ktor s typick zranitenosti
aplikci, ako vznikaj a ako sa im spene vyhba.
V nasledujcich astiach tejto kapitoly sa budeme zaobera nasledujcimi okruhmi problmov,
ktor maj podstatn vplyv na bezpenos alikci:
Typick hrozby pre bezpenos aplikci
Typick zranitenosti aplikci
Rizik spojen s prevdzkovanm zranitench aplikci
Nvrh a vvoj bezpenho softvru
5.2 Zkladn bezpenostn hrozby pre aplikcie

Aplikcia a nsledne daje, ktor spracva, mu by kompromitovan mnostvom rznych
metd a zneuitm rozmanitch bezpenostnch slabn. Ak djde k spenmu toku na
aplikciu, tonk vinou vyuva bezpenostn zranitenos v samotnom softvri aplikcie.
Ale nie je to vdy tak. Kee chybu mu spravi nielen vvojri ale aj administrtori, opertori
alebo in zamestnanci prevdzky, existuj rzne druhy zranitenost (aplikci), ktor mu
vyui hrozby voi aplikcii. Ide predovetkm o hrozby vyuvajce
bezpenostn chyby v softvri,
konfiguran chyby,
nedostatky v bezpenosti prevdzky.
V nasledujcich astiach sa pozrieme na jednotliv kategrie hrozieb podrobnejie.
126
Aplikan bezpenos | MF SR
5.2.1
Bezpenostn chyby v softvri
Aplikcie najastejie ohrozuj109 bezpenostn chyby v kde aplikcie.

Vskyt bezpenostnch chb v kde me by spsoben rznymi faktormi ako nedostaton
vzdelvanie programtorov zo zsad bezpenho programovania, chbajce tandardy pre
bezpen vvoj v konkrtnych technolgich, nedostatok asu, zl nvrh, chbajca analza
rizk a svisiacich hrozieb i nedostaton testovacie metodolgia.
Toto s vak vinou u len konkrtne prejavy nedostatonho drazu na bezpenos vo vvoji
softvrovho produktu a s tm svisiacej absencie iniciatvy aplikanej bezpenosti riadenej
alebo aspo spravovanej (Governance) z najvych pozci organizcie.
Softvrov zranitenosti majce bezpenostn dopad mu ma rzny typ a formu, mu sa
vyskytn na rznych rovniach technologickch celkov. Niektor typy zranitenost s aktulne
pre vetky alebo aspo pomerne vea platforiem (napr. nedostaton validcia vstupov), niektor
s vemi pecifick a platn len pre mal skupinu technolgi (napr. preteenie zsobnka v
prpade programovacch jazykov C a C++).
Medzi ast zranitenosti aplikci patria:
Nedostaton validcia vstupov
Monos vkladania kdu (Code Injection, Injekcia kdu)
Monos vkladania neoprvnench SQL dotazov (SQL Injection)
Cross-site Scripting (XSS)
Preteenie zsobnka
Race conditions
Nedostatky v nastaven prstupovch prv
Tieto zranitenosti v alom texte rozoberieme podrobnejie.

5.2.2
Konfiguran chyby
alou oblasou kde sa zvykn vyskytova zranitenosti ohrozujce aplikcie s konfiguran

nastavenia. Konfiguran nastavenia, i u v samotnej aplikcii, systme na ktorom je
prevdzkovan, databze ktor aplikcia vyuva alebo v inej svisiacej komponente, me
bezpenos aplikcie vne narui aj bez toho aby bol priamo v kde aplikcie akkovek
bezpenostn nedostatok.
Prkladom konfiguranej chyby s ktorou sme sa v praxi veakrt stretli, me by zdiean
adresr obsahujci stromov truktru sborovho systmu aplikcie. Ak tonk me
zapisova do zdieanho adresra, resp. sborov a adresrov v om, bezpenostn funkcie
aplikcie neochrnia aplikciu pred kompromitciou.
5.2.3
Nedostatky v bezpenosti prevdzky
Nedostaton bezpenostn praktiky pri prevdzke aplikci s alm druhom zranitenost,

ktor mu ohrozi aplikciu.
Kd aplikcie, aj jej konfigurcia me by sto percentne bezpen (v praxi nedosiahnuten
mta), ale ak nie je prevdzkovan bezpenm spsobom, potencilny tonk me aplikciu a
jej daje kompromitova zneuitm bezpenostnch nedostatkov v prevdzke.
Prklady bezpenostnch nedostatkov v prevdzke, ohrozujcich bezpenos aplikcie:
109
ahko uhdnuten systmov hesl,

t.j. vytvraj predpoklad pre naplnenie hrozby
127
Administrcia aplikcie z nezabezpeenho systmu,
Nedostatone chrnen aplikan zlohy
Aby sa predilo podobnm bezpenostnm nedostatkom, je nutn, aby prevdzkov personl

dodriaval bezpenostn politiku organizcie, ktor by mala adresova podobn situcie.
5.3 Aplikan bezpenostn funkcie

Aplikan bezpenostn funkcie slia na implementciu poadovanch bezpenostnch
mechanizmov do aplikcie.
V tejto asti sa najprv budeme venova aspektom, ktor treba zohladni pri vbere
bezpenostnch funkci a potom poskytneme prehad najdleitejich kategri bezpenostnch
funkci.
5.3.1
Dleit vahy pri vobe bezpenostnch funkci
Jednu a t ist bezpenostn poiadavku je mon naplni rznymi spsobmi realizova

pomocou rznych bezpenostnch funkci.
Pri vobe konkrtnych bezpenostnch funkci je potrebn zohadni niekoko kovch
aspektov, ktor maj podstatn dopad na vsledn celkov bezpenos aplikcie.
Ide o nasledovn aspekty:
Pouvatesk prstupnos aplikcie
Vhodnos bezpenostnej funkcie
Nronos sprvy aplikcie
Prostredie aplikcie
5.3.1.1 Pouvatesk prstupnos aplikcie

V princpe je mon ubovon aplikciu (a vo veobecnosti systm alebo IKT) extrmne
zabezpei a natoko, e pravdepodobnos jej kompromitcie bude blzka nule.
To by vak s vysokou pravdepodobnosou znamenalo, e
na zabezpeenie aplikcie by bolo potrebn vynaloi neadekvtne vysok prostriedky,

ktorch hodnota by nebola v rozumnom pomere s hodnotou chrnench aktv,
aplikcia by bola v praxi nepouiten, pretoe implementovan bezpenostn opatrenia by

enormne saili, prpadne plne znemonili jej pouvanie.
Niektor bezpenostn funkcie (vrtane ich parametrov) s pre pouvateov transparentn, take
si ich prtomnos nemusia ani uvedomova. In bezpenostn funkcie s zase pre pouvateov
vemi citen u zo svojej podstaty ako naprklad zopakovanie autentifikcie pri vypran relcie,
kratia ivotnos relcie alebo re-autentifikcia pri volan citlivej opercie.
Pouvatesk prstupnos aplikcie je dleitm aspektom ktor treba bra do vahy u pri
nvrhu aplikcie, ale taktie neskr pri rieen implementanch detailov, aby bezpenostn
opatrenia neinterferovali s vykonvanmi biznis aktivitami do tej miery, e nklady na opatrenia
prevauj nad vhodami (uetrenmi prostriedkami) zskanmi tmito bezpenostnmi
opatreniami.
5.3.1.2 Vhodnos bezpenostnej funkcie
Jednu a t ist bezpenostn poiadavku vieme vinou na technickej rovni implementova
rznymi bezpenostnmi funkciami.
128
Voba bezpenostnej funkcie by sa mala opiera minimlne o nasledujce pravidl:
Ak platforma aplikcie poskytuje urit bezpenostn funkciu, vo veobecnosti je dobr

uprednostni tto pred implementciou vlastnej, ak tomu nebrnia urit pecilne
poiadavky pre ktor existujca funkcia nevyhovuje.
Prednos by mala ma bezpenostn funkcia, ktor je menej nron na zdroje (systmov

pam, vkon procesora, lon priestor, at.
Prednos by mala ma bezpenostn funkcia, ktor je rchlejia ne alternatvy.
Prednos by mala ma bezpenostn funkcia, ktor bude transparentnejia pre pouvateov

aplikcie ne alternatvy, t.j. bude vykonva o sa od nej oakva a menej bude intrferova
(ak vbec) s innosou pouvateov
Bezpenostn funkcia by svojou funknosou mala zapada do architektry prostredia

v ktorej bude nasaden.
5.3.1.3 Nronos sprvy aplikcie

O kad aplikciu sa niekto mus stara. Ak bude sprva aplikcie nron, bude zabera vea
asu, a bude si vyadova kvalifikovanho sprvcu. Ak bude sprvca preaen, alebo
nedostatone kvalifikovan, je vyia pravdepodobnos, e pri sprve aplikcie nieo prehliadne.
Preto me vek poet rznych opatren, ktor je potrebn udriava, paradoxne vies k niej
rovni bezpenosti aplikcie.
Ak bud napr. bezpenostn architektra, implementovan opatrenia, modularizcia, prstupov
a dtov model aplikcie natoko komplikovan alebo neprehadn, e celkov administrcia
a bezpen prevdzkovanie aplikcie bude komplikovan a asovo nron, bude ma vek
poet a rozmanitos opatren na bezpenos aplikcie skr opan inok ne bolo pvodne
zamlan.
Preto by aplikcia mala by spravovaten cez jednotn rozhranie, svisiace parametre by mali
by zoskupen (napr. na jednej obrazovke administranho rozhrania), vznam jednotlivch
konfiguranch parametrov by mal by jednoznan a jasne zdokumentovan.
V neposlednom rade, konfigurovatench parametrov by malo by len toko koko je nevyhnutne
potrebnch na naplnenie poiadaviek konfigurovatenosti a jednotliv parametre by sa svojou
funknosou nemali prekrva.
5.3.1.4 Prostredie aplikcie
Rzne bezpenostn funkcie aplikcie a aj jej celkov architektra, sa u vo fze nvrhu opieraj
o mnostvo predpokladov o prostred v ktorom bude aplikcia nasaden.
Neskorou postupnou zmenou prostredia, v ktorom aplikcia be alebo jej migrciou do novho
prostredia mu presta plati pvodn bezpenostn predpoklady o prostred o me ohrozi
efektvnos existujcich opatren.
5.3.2
Aplikan bezpenostn funkcie
Aplikcie pouvaj cel rad funkci, ktor maj na starosti rzne aspekty ich bezpenosti. Tieto
funkcie nazvame bezpenostnmi funkciami.
Na mnoho bezpenostnch funkci existuj hotov rieenia, ktor treba uprednostni pre
vyvjanm vlastnho kdu pre tento el. Sksenos ukazuje, e niektor bezpenostn funkcie je
vemi ak sprvne (bezpene) navrhn a nsledne implementova bez predchdzajcej
hlbokej sksenosti a znalost v danej oblasti.
129
Preto ak skutone nejde o funknos, ktor mus by z nejakho dvodu it na mieru vyvjanej
aplikcii, treba uprednostni vyuvanie bezpenostnch funkci a mechanizmov poskytovanch
platformou, operanm systmom prpadne databzou aplikcie.
V nasledujcich podkapitolch sa pozrieme na nasledovn najdleitejie typy bezpenostnch
funkc:
Autentifikcia
Autorizcia
Sprva relcie
Validcia vstupov
Spracovanie chb
Vytvranie auditnch zznamov
Kryptografick funkcie
5.3.2.1 Autentifikcia
Autentifikan bezpenostn funkcie spjaj identitu relneho pouvatea s jeho systmovou
identitou (tom) pomocou overenia prihlasovacch dajov. Autentifikan mechanizmy musia
by adekvtne rizikovosti aplikcie aby dokzali odolva tonkom vyuvajcim rzne
metdy tokov na autentifikciu.
Podrobn informcie o autentifikcii a spsoboch, ako pouva autentifikan mechanizmy v
bench aplikcich s poskytnut vo tvrtej kapitole.
5.3.2.2 Autorizcia
Autorizan funkcie musia zaisti, e legitmni pouvatelia systmu sm vykona len tie
opercie a pristupova k tm dajom pre ktor s autorizovan, t.j. ktor zodpovedaj ich
oprvneniam. Riadia prstup ku chrnenm zdrojom povolenm alebo zamietanm prstupu na
zklade rol alebo rovne oprvnen.
Podrobn informcie o autorizcii v bench aplikcich s poskytnut vo tvrtej kapitole.
5.3.2.3 Sprva relcie
V potaovch vedch a pecilne pecilne v oblasti potaovch siet sa pod pojmom relcia
(session) rozumie semi-permanentn interaktvna vmena informci, tie znma ako dialg,
konverzcia alebo stretnutie, medzi dvoma alebo viacermi komunikujcimi zariadeniami, alebo
medzi systmom a pouvateom. [13]
Po prihlsen pouvatea do aplikcie je pouvateovi pridelen tzv. identifiktor relcie
(session ID), ktor sli na identifikciu pouvatea pri jeho alej interakcii s aplikciou, a do
jeho odhlsenia alebo vyprania ivotnosti relcie. Na strane aplikcie je s identifiktorom relcie
spojen identita pouvatea a stav jeho relcie.
Kee pouvate je prostrednctvom identifiktora relcie asociovan so svojou relciou, pre
nsledn aktivitu v aplikcii (pod svojm tom) nepotrebuje pri kadej interakcii posiela svoje
prihlasovacie daje, pre spen prienik na jeho et tonkovi postauje zskanie, alebo
uhdnutie identifiktora jeho relcie. Aby sa hodnoty platnch identifiktorov relcie nedali
uhdnu, musia by generovan bezpenm spsobom, naprklad pomocou silnch
kryptografickch algoritmov.
Pri vvoji bezpenostnch funkci pre sprvu relcie je dobrou praxou uprednostni hotov
rieenia (vinou poskytovan pouitou vvojrskou platformou) pred nvrhom vlastnch
algoritmov.
Bezpenostn funkcie pre sprvu relcie maj za lohu zabezpei to, aby boli autentifikovan
pouvatelia aplikcie robustne a kryptograficky bezpene asociovan so svojou relciou.
130
5.3.2.4 Validcia vstupov

Aplikcia spracovva vstupn hodnoty. Niektor z nich mu ma na innos aplikcie neiadci
vplyv.
Bezpenostn funkcie pre validciu vstupov maj zabezpei, e aplikcia je dostatone odoln
voi vetkm hodnotm vstupnch dajov, i u tieto daje pochdzaj od pouvatea,
infratruktry, externch entt alebo databzovch systmov.
Na nedostatkoch vo validcii vstupov je zaloen mnostvo inch zranitenost ako naprklad
monos vkladania kdu, monos vkladania SQL prkazov, Cross-site scripting zranitenosti,
preteenie zsobnka, at.
5.3.2.5 Spracovanie chb
Poas behu aplikcie mu nasta situcie, kedy aplikcia neme alebo nevie pokraova vo
svojej innosti kvli rznym netandardnm okolnostiam. Prkladom netandardnch okolnost
mu by situcie kedy aplikcia obdr vstup, ktorho hodnoty nespadaj do oakvanho
rozsahu hodnt, dleit sbor sa nepodarilo otvori, sieov spojenie sa nepodarilo nastoli
prpadne zaplnen disk neumonil zpis vstupov. Takto a podobn situcie nazvame
aplikanmi chybami.
Kad aplikcia by mala ma oetren vetky znme mon chybov stavy. Preto je dleit aby
boli pri vvoji identifikovan miesta v kde, kde me nasta chybov stav a implementova
relevantn bezpenostn funkcie, ktor dan chybov stav vhodnm a bezpenm spsobom
oetria.
5.3.2.6 Vytvranie auditnch zznamov
Auditn zznamy slia na zznam udalost v aplikcii. Ak udalosti s do auditnho zznamu
zapisovan zvis od toho, ak udalosti aplikcia umouje auditova a tie toho, ktor z tchto
udalost s v nastaveniach aplikcie nakonfigurovan na audit.
Informcie z auditnho zznamu aplikcie typicky slia na odlaovanie aplikcie v prpade
zistenia aplikanej chyby, optimalizciu, vytvranie tatistk alebo na monitoring udalost
relevantnch z bezpenostnho hadiska.
Na vytvranie auditnch zznamov slia auditn bezpenostn funkcie, ktor zaznamenvaj
nastaveniami vybran dleit udalosti v aplikcii ako napr. prihlsenie a odhlsenie pouvatea,
zamietnutie prstupu k uritmu zdroju a chybov stavy v aplikcii. Aplikcia by vak mala
poskytova monos konfigurcie ako typov udalost, ktor sa bud zaznamenva tak aj rovne
detailnosti informcie, ktor sa bude ku kadej udalosti zaznamenva.
Kee podrobn auditovanie udalost me v pomerne krtkom ase vygenerova vek objem
dt (auditnch zznamov), mus by k dispozcii dostatok diskovho priestoru na ich uskladnenie.
Dobrou praxou je zaznamenva auditn daje na samostatn diskov priestor, aby prpadn
zaplnenie vonej kapacity disku nespsobilo aj havriu prpadne zlyhanie aplikcie alebo priamo
operanho systmu.
Pokia auditn zznamy nemaj formu jednoduchch textovch sborov, ale maj napr. binrny
formt - aplikcia by mala tie poskytova nstroj na prezeranie a prcu s jej auditnmi sbormi.
5.3.2.7 Kryptografick bezpenostn funkcie
Kryptografick bezpenostn funkcie slia primrne na ochranu integrity a dvernosti citlivch
dajov (i u poas ich prenosu alebo pri uskladnen) s vak aj sasou rznych
bezpenostnch protokolov (napr. pri autentifikcii).
Medzi typick kryptografick nstroje a ich pouitie v aplikcich patria:
Genertory pseudo-nhodnch sel

131
Generovanie dostatone nhodnch selnch hodnt pre rzne ely, kedy je vyadovan aby
tieto sla neboli tonkom uhdnuten
Haovacie funkcie
Kontrola integrity dajov

Utajenie prstupovch hesiel pri zachovan monosti ich neskorieho overenia oproti zadanmu
heslu
Autentifikan protokoly
Overenie identity pouvatea
ifrovacie algoritmy
Ochrana dvernosti a integrity uskladnench dajov

Ochrana dvernosti a integrity prenanch dajov
Algoritmy pre elektronick podpis
Overenie identity odosielatea dajov

Nvrh dostatone silnch kryptografickch algoritmov, protokolov a inch kryptografickch
nstrojov a dokzanie ich vlastnost vyaduje hlbok znalosti v kryptografii.
Ete aj v takomto prpade je na potvrdenie ich bezpenosti potrebn analza inmi odbornkmi v
kryptografii. Preto sa vo veobecnosti neodpora vvoj vlastnch elementrnych
kryptografickch nstrojov ale pouitie znmych softvrovch kninc, ktor implementuj
bezpen kryptografick mechanizmy.
Zkladom kryptografie a spsobom, ako pouva kryptografick mechanizmy v bench
aplikcich je venovan sma kapitola.
5.4 Typick zranitenosti aplikci a opatrenia proti nim

Tto podkapitola poskytuje informcie o typickch zranitenostiach aplikci, ako tieto
zranitenosti vznikaj, ako sa prejavuj a ako im predchdza.
Uveden s tie rzne opatrenia, pomocou ktorch je mon zni dopad aplikanch
zranitenost. Tieto opatrenia s dleitou oporou aplikanej bezpenosti, pretoe aj pri najlepej
snahe o za-bezpeenie aplikcie mu by v kde stle prtomn neobjaven bezpenostn
chyby.
5.4.1
Typick zranitenosti aplikci
5.4.1.1 Nedostaton validcia vstupov

Cieom validcie vstupov je zabezpeenie toho, aby aplikcia bola schopn prijma validn
vstupn daje a aby bola zrove dostatone odoln voi vetkm hodnotm vstupnch dt, i u
zskanch od pouvatea, infratruktry, externch subjektov alebo databzovch systmov.
Pod validciou vstupov rozumieme tak kontrolu vstupnch dajov, ktor zabezpe, e prijatm
a nslednm spracovanm tchto dajov nedjde k narueniu bezpenosti aplikcie alebo inch
komponentov IKT.
Validcii musia podlieha vetky vstupy do aplikcie bez ohadu na zdroj.
Najastejou bezpenostnou slabinou aplikci je neschopnos sprvne overi vstup od klienta
alebo od prostredia. Tento nedostatok vedie k mnohm podstatnm zranitenostiam v
aplikcich, ako napr.:
132
Monos vkladanie (injekcia) kdu,
Cross-site scripting (XSS) zranitenosti,
Monos vynorenia z adresra aplikcie,
Preteenie vyrovnvacej pamte (zsobnka).
daje od klienta by nikdy nemali by povaovan za dveryhodn, kee klient m vo

veobecnosti neobmedzen monos manipulova s dtami odosielanmi jeho prehliadaom
alebo inm klientskm programom na vstup aplikcie.
V mnohch prpadoch m kdovanie pecilnych znakov potencil zmierni toky, ktor sa
spoliehaj na nedostatky v overovan vstupov. Naprklad, ak bude aplikovan HTML kdovanie
HTML entt na vstupy pouvatea pred odoslanm do prehliadaa, me to zabrni vine
Cross-site scripting tokov.
Avak ochrana pred takmito tokmi, ktor spova iba vo validcii vstupov nesta je dleit
aby sme takto pokusy v naich aplikcich aj zaregistrovali, napr. systmom pre detekciu
prienikov (IDS - Intrusion Detection System).
Inak umoujeme tonkom opakovane toi na nae aplikcie, km neobjavia chybu, ktor z
aplikcie nebola odstrnen.
Odhaovanie pokusov tonka o njdenie tchto chb je dleitm ochrannm mechanizmom.
5.4.1.2 elov vkladanie kdu (Code Injection, Injekcia kdu)
Injekcia kdu je sbornm nzvom pre mnoho druhov tokov, ktor s zaloen na vkladan
kdu (do aplikcie), ktor je spracovan aplikciou. Takto tok me by vykonan pridanm
reazca znakov do sboru cookie alebo do hodnt argumentov v linke URL.
Tento typ toku zneuva nedostaton validciu vstupno/vstupnch dt, naprklad:
triedu dovolench znakov (tandardn triedy regulrnych vrazov, alebo vlastn),
dtov formt,
mnostvo oakvanch dt,
pre seln vstup, povolen hodnoty vstupu.
Injekcia kdu a injekcia prkazov s toky, ktor sleduj rovnak ciele.

Injekcia kdu - je vkladanie kodlivho kdu do aplikcie. Tento kodliv kd je neskr
spusten v rmci aplikcie. Pridan kd je sasou samotnej aplikcie.
Injekcia prkazov je spustenie externho kodlivho kdu v aplikcii, priom span kd
nie je vntornou sasou aplikcie.
Prklad . 1
Ak strnka pouva funkciu include(), ktor operuje na premennch odoslanch metdou GET
a nevykonva sa ich validcia, tonk sa me poksi spusti vlastn kd, in ako ten, ktor
zamal spusti autor pvodnho kdu.
Linka niie zobrazuje informciu, ako kontaktova spolonos Testsite.
http://testsite.com/index.php?page=contact.php
Niie je uveden modifikovan kd z http://evilsite.com/evilcode.php. Skript "evilcode.php"
me obsahova, naprklad, funkciu phpinfo(), ktor je uiton pre zskanie informci
o konfigurcii prostredia v ktorom webov sluba be.
http://testsite.com/?page=http://evilsite.com/evilcode.php
133
Pre spech tohto snaenia mus by splnen jedin podmienka: konfigurcia servera mus
umoova vkladanie mena sborov do notcie typu http://.
5.4.1.3 Vkladanie neoprvnench SQL dotazov (SQL Injection, Vkladanie SQL kdu,
SQL injekcia)
toky SQL injection sa realizuj vkladanm, alebo tie injekciou SQL kdu do vstupnch dt
prenanch medzi klientom a aplikciou. Exploit SQL injekcie, ktor spene naru
bezpenostn funkcie aplikcie umouje tonkovi ta citliv dta z databzy, modifikova
dta v databze (vkladanie, aktualizcia, mazanie), spa administratvne opercie nad
databzou (vypnutie systmu riadenia databzy SRBD, anglicky DBMS), obnovenie obsahu
uritho sboru prtomnho v databze a v pecilnych prpadoch tie spanie prkazov na
operanom systme. toky SQL injekcie s takmi typmi injeknch tokov, v ktorch s
prkazy SQL injektovan do existujcich legitmnych SQL vstupov tak, aby dolo k spusteniu
tonkom preddefinovanch modifikovanch SQL prkazov.
Hrozby
toky SQL injekcie umouj tonkovi vyuva cudziu identitu, modifikova existujce dta,
spsobova problmy pri prevdzan transakci (zruenie transakcie, zmenenie kovch hodnt
pri peanch transakcich ako je napr. vka prevdzanej sumy), plne prezradenie vetkch
citlivch informci v systme, znienie dt, alebo ich premiestnenie do neiadanej lokality
a zamedzenie prstupu k nim pre bench uvateov a zskanie administrtorskch prv
k napadnutmu systmu.
tok typu SQL injection je vemi ben pri PHP a ASP aplikcich kvli tomu, e sa medzi nimi
stle bene pouvaj starie funkn rozhrania. Kvli charakteru prstupnch rozhran, s J2EE
a ASP.NET aplikcie menej zraniten na ben toky typu SQL injection.
Podobne ako pri inch typoch tokov (ako napr. XSS), je zvanos tokov typu SQL injection
vrazne ovplyvnen schopnosami a kreativitou tonka. Rolu tu hraj tie protiopatrenia na
strane servera, ako je naprklad nastavenie nzkych privilgi pre spojenia s databzovm
serverom at. Vo veobecnosti je potrebn povaova toky typu SQL injekcie za vysoko
zvan.
K tokom formou SQL injekcie dochdza ke:
dta vstupuj do aplikcie z nedveryhodnho zdroja,
dta, ktor vstupuj do aplikcie z dveryhodnho zdroja si dynamicky vytvraj SQL

poiadavku.
toky vkladanm SQL kdu sa stali benm problmom pri webovch aplikcich pouvajcich
databzu. Chyba je ahko detekovaten a zneuiten a preto je ktorkovek webov strnka,
alebo softvrov balek s aspo minimlnym vstupom od uvatea ahko kompromitovan
tmto typom toku.
V zsade je tok zaloen na modifikcii existujceho dtovho vstupu vloenm meta znaku, za
ktorm nasleduje nov, tonkom vykontruovan SQL prkaz, ktor v om predtm
neexistoval. Tto chyba zneuva vlastnos aplikcie netestova a nerozliova vzory vo
vstupnch dtach.
Jednou z tradinch metd na prevenciu tokov SQL injekcie je pristupova k nim ako ku
problmu s dtovou validciou a bu akceptova iba znaky z uritho vopred definovanho
zoznamu (z tzv. whitelist-u) bezpench hodnt, alebo identifikova a vyli potencilne
nebezpen hodnoty z vopred definovanho zoznamu (tzv. blacklist-u).
5.4.1.4 Cross-site Scripting (XSS)
Cross-Site Scripting toky s takm typom injeknho toku, v ktorom s potencilne kodliv
skripty injektovan do inak nekodnch a dveryhodnch webovch strnok. Cross-Site
Scripting (XSS) toky nastvaj, ke tonk pouije webov aplikciu na zaslanie kodlivho
134
kdu inmu uvateovi. Vo vine prpadov sa jedn o kodliv kd vo forme skriptu na strane
prehliadaa. Chyby, ktor umouj spenos takhoto toku s vo veobecnosti pomerne
rozren a nastvaj kdekovek, kde webov aplikcia vyuva vstup od pouvatea na
generovanie vlastnho vstupu bez toho, aby ho overovala, alebo zakdovala.
tonk me poui XSS na zaslanie kodlivho skriptu ni netuiacemu pouvateovi.
Prehliada koncovho pouvatea nem monos zisti, e tento skript nie je dveryhodn
a spust ho. Pretoe si mysl, e skript pochdza od dveryhodnho zdroja, skript me
pristupova k ubovonm sborom cookies, identifiktorom aktvnej session, alebo inm
citlivm informcim udriavanm prehliadaom pouvatea a pouitm touto strnkou. Tieto
skripty mu dokonca prepsa obsah HTML strnky.
Cross-Site Scripting (XSS) toky nastvaj, ke:
dta vstupuj do webovej aplikcie cez nedveryhodn zdroj, najastejie formou webovej
poiadavky (ide o ben HTTP volanie, typicky to bva naprklad kliknutie na vybran
objekt web strnky a nsledn zavolanie konkrtneho URL s ktorm s zasielan aj urit
vstupn parametre)
dta s zahrnut v dynamickom obsahu, ktor je pouvateovi webovej strnky zaslan bez
toho, aby bol validovan na prtomnos kodlivho kdu.
kodliv obsah zaslan webovmu prehliadau m zva formu asti JavaScriptovho kdu, ale
me tie obsahova kd HTML, Flashov kd, alebo in typ kdu, ktor je prehliada schopn
spusti. Rznorodos tokov zaloench na XSS je takmer neobmedzen, ale vo vine
prpadov zaha nelegitmne zaslanie skromnch dt, akmi s cookies, alebo in informcie
o aktvnej session, smerom k tonkovi, presmerovanie obete na webov obsah pod kontrolou
tonka, alebo vykonanie inej kodlivej opercie na potai obete prostrednctvom zranitenej
webovej strnky.
Uloen a reflektovan XSS toky
Cross-Site Scripting toky mu by vo veobecnosti zatrieden do dvoch kategri: uchovvan
(stored) a reflektovan (reflected). Existuje tie tretia, menej znma kategria zvan DOM based
XSS.
Uloen XSS toky
Uloen toky s tak, pri ktorch je injektovan kd permanentne uchovvan na cieovch
serve-roch, naprklad v databze, v diskusnom fre, nvtevnej knihe, v polku pre komentr,
at. Obe prjme kodliv skript zo servera pri poiadavke o uloen informciu.
Zrkadlen XSS toky
Reflektovan toky s tak, pri ktorch je injektovan kd zrkadlen z webovho servera.
Naprklad sa me jedna o chybov hlsenie, vsledok vyhadvania, alebo in odpove, ktor
zaha as vstupu, alebo cel vstup zasielan serveru ako as poiadavky. Reflektovan toky
s smerovan na obete toku cez in kanl, naprklad emailovou sprvou, alebo cez odlin
webov server.
Ke je uvate naveden na kliknutie na linku, alebo zaslanie pecilne modifikovanho
formulra, za ktorm sa skrva kodliv kd, injektovan kd putuje do zranitenho webovho
servera, ktor zrkadl tok sp k pouvateskmu prehliadau. Prehliada potom spa
kodliv kd preto, e tento kd pochdza z dveryhodnho zdroja.
DOM Based XSS toky zaloen na modifikcii DOM
tok nazvan DOM Based XSS (in pouvan meno je type-0 XSS) je tak XSS tok,
v ktorom s kodliv dta prenan pri toku spusten ako vsledok modifikcie DOM
prostredia (Document Object Model) v prehliadai pouvatea pouvanom originlnym
skriptom na strane klienta tak, e kd na strane klienta be v neoakvanom reime. To
znamen, e samotn strnka (teda http odozva na poiadavku klienta) sa nezmen, ale kd na
135
strane klienta obsiahnut v strnke sa spa rozdielne kvli kodlivej modifikcii tonka, ktor
sa udiala v DOM prostred.
Tento tok je odlin od ostatnch XSS tokov (uloench, alebo reflektovanch), pretoe
kodliv dta s uloen v strnke, ktor je odpoveou na poiadavku (vaka chybe na strane
servera).
5.4.1.5 Preteenie zsobnka (pamte)
Preteenie zsobnka nastva, ke aplikcia pri zapisovan dajov do rznych dtovch truktr
nekontroluje, prpadne kontroluje nedostatone, i vekos zapisovanch dajov nie je via ne
vekos dtovej truktry do ktorej sa zpis vykonva.
Ak je vekos zapisovanch dajov via, po vyerpan priestoru v alokovanej dtovej truktre
me djs k prepsaniu rznych aplikanch alebo systmovch riadiacich dtovch truktr.
V takomto prpade najastejie dochdza k havrii aplikcie a ukoneniu jej innosti. Ak vak
tonk doke ovplyvova (doda) daje, ktormi bude tento prepis vykonan, me okrem
zhodenia aplikcie dosiahnu aj spustenie vlastnho kdu na cieovom systme. Kd, ktor chce
tonk spusti obvykle posiela aplikcii v rmci dajov, ktormi bude vykonan prepis
spomnanch dtovch truktr.
tonci vo veobecnosti pouvaj preteenia zsobnka pre naruenie priebehu spania kdu
aplikcie. Pomocou vkladania modifikovanch vstupov do aplikcie je tonk schopn spusti
cudz kd, ktor me prebra kontrolu nad systmom, na ktorom aplikcia be. Historicky boli
identifikovan chyby zneuiten na tok vyvolvajci preteenie zsobnka (v alom tok
preteenia zsobnka) vo vekom mnostve produktov a komponentov.
Chyby/zranitenosti, ktor sa daj vyui na vyvolanie preteenia zsobnka mu by prtomn
v produktoch urench na prevdzkovanie webovch sluieb aj v produktoch urench pre
poskytovanie ostatnch aplikanch sluieb, ktor prevdzkuj statick, alebo dynamick as
strnky, ale tie mu by prtomn v samotnej webovej aplikcii. Chyby zneuiten na tok
preteenm zsobnka njden v bene pouvanch produktoch sa s vekou pravdepodobnosou
stvaj iroko znmymi a predstavuj vznamn riziko pre pouvateov tchto produktov.
Pokia napr. webov aplikcia pouva kninice, ako naprklad grafick kninice na generovanie
obrzkov, alebo komunikan kninice na posielanie emailov, vystavuje sa tm potencilnym
tokom preteenm zsobnka. Literatra, ktor popisuje toky preteenm zsobnka voi bene
pouvanm produktom je vone dostupn a nov zranitenosti s publikovan takmer denne.
Zranitenosti umoujce preteenie zsobnka sa daj njs tie v upravenom kde
proprietrnych aplikci a mu by zneuit dokonca s vou pravdepodobnosou, pretoe
nepreli podrobnejm skmanm a testovanm, ktorm bene pouvan aplikcie vinou
prechdzaj. toky preteenm zsobnka na aplikcie asto ved k prekvapivm vsledkom.
V niektorch prpadoch m vloenie vekho mnostva vstupu za nsledok zlyhanie aplikcie,
alebo databzy na pozad aplikcie. V zvislosti na zvanosti a charaktere chyby je dokonca
mon spsobi odopretie sluby (denial of service). Vek mnostvo dt posunut rozhraniu
aplikcie me aplikciu printi k zobrazeniu po-pisnho chybovho hlsenia, ktor me
potencilne vies k spenmu toku na systm.
toky preteenia zsobnka sa vo veobecnosti realizuj dvoma technikami, priom sa asto
pouva ich kombincia:
riaden zpis dt na konkrtne miesto v pamti,
printenie operanho systmu nesprvne spracova dtov typy.
Pri jazykoch a prostrediach s lepou kontrolou nad dtovmi typmi (strongly-typed

programming languages and environments), charakter tchto technk znemouje vskyt tokov
na preteenia zsobnka.
Techniky prevencie
Niekoko veobecnch technk predchdzania preteeniu zsobnka zaha:
136
Auditovanie kdu (automatick, alebo manulne) analza zdrojovho kdu aplikcie

s cieom odhalenia bezpenostnch chb,
kolenie vvojrov sprva miesta alokovanho pre premenn v pamti (bounds checking),
pouvanie potencilne nebezpench funkci, skupinov tandardy,
Nespaten zsobnky (Non-executable stacks) vina systmov vo svojej benej

konfigurcii umouje spa kd (rozumie sa vkon intrukci procesorom) na
ubovonom mieste v pamti potaa, t.j. aj v pamovej oblasti zsobnka. Rieenia pre
implementciu tzv. nespatelnho zsobnka zabezpeia to, e v oblastiach pamti kde sa
maj nachdza iba daje a nie kd (teda aj na zsobnku) systm neumon spa kd.
Vea operanch systmov m podporu tejto funkcionality,
Kompilan nstroje naprklad nstroje StackShield, StackGuard a Libsafe,
Bezpen funkcie pouvanie bezpenejch alternatv funkci programovacch jazykov C

a C++ miesto funkci postrdajcich kontrolu dky vstupov (napr. strncat namiesto strcat,
strncopy namiesto strcopy at.),
Aktualizcie pravideln aktualizcia webovch a aplikanch serverov a prehad

o aktulnych publikovanch chybovch reportoch tkajcich sa aplikci na ktorch je
zvisl kd,
Pravideln skenovanie aplikci skenovanie aplikci niektorm z dostupnch skenerov,

ktor s okrem inch bezpenostnch chb schopn detegova chyby preteenia zsobnka
v serverovch produktoch a proprietrnych webovch aplikcich.
5.4.1.6 Atomickos operci a race conditions

V databzovch systmoch je nedelitenos (alebo aj atomickos) jedna z vlastnost ACID
transakcie110. ACID transakcia je transakcia ktor spa nasledovn poiadavky
Atomickos
Vyaduje, aby kad transakcia bola spracovan spsobom vetko alebo ni. Ak nezbehne as
transakcie, nezbehne ani transakcia ako celok a databza zostane nezmenen.
Konzistentnos
Tto vlastnos zabezpeuje to, e kad transakcia presva databzu z jednho validnho stavu
do inho validnho stavu.
Izolcia
Tto vlastnos zabezpeuje to, e sasne prebiehajce transakcie presun systm do stavu, ktor
by nastal ak by boli tieto transakcie vykonan sriovo, t.j. jedna po druhej.
Trvalos
Trvalos znamen, e ke u raz bola transakcia potvrden a vykonan (comit), zostane

v platnosti aj v prpade vpadku prdu, havrie alebo prpadnch chb.
V atomickej transakcii je rad operci nad databzou vykonan tak, e bu s vykonan vetky,
alebo nedjde k iadnej.
Zruka atomicity brni tomu aby dolo len iastone k aktualizcia databzy, o me spsobi
vie problmy, ne odmietnu cel rad operci plne [17].
Prklad .1
110
ACID = Atomic, Consistent, Isolated and Durable
137
Prkladom atomicity me by objednvka letenky, kde s vyadovan dve akcie: rezervova si

miesto a platba. Potencilny cestujci mus bu:
1)
aj si rezervova miesto aj zaplati, alebo
2)
ani si nerezervova miesto ani nezaplati.
Rezervan systm nepovauje za prijaten pre zkaznka zaplati za letenku bez zaruenia
sedadla, ani rezervciu sedadla bez spenej platby.
Prklad .2
Povedzme, e chce niekto previes urit mnostvo peaz z jednho tu na druh. Iniciuje
prevod, peniaze sa z jednho tu odtaj, ale ak predtm ako sa pripotaj k druhmu tu
nastane chyba a program sa preru, klient by mohol prs o tto sumu. V sprvne oetrenej
aplikcii, ak djde k takmuto zlyhaniu, potom kvli atomicite, bude iastka preveden bu
plne, alebo sa prevod ani nespust. Tmto spsobom nedelitenos chrni pouvatea aby kvli
chybe v transakcii nedolo ku strate peaz.
Race condition
Race condition je druh chyby v aplikcii, ku ktorej me djs v dsledku toho, e aplikcia
predpoklad, e urit opercie prebehn v uritom porad. Ak to vak nie je pravda, a zmen sa
poradie tchto operci, aplikcia me zosta v nekonzistentnom stave, o me ma za
nsledok poruenie integrity dajov alebo aj preruenie behu aplikcie.
Race condition situcia me ma aj bezpenostn implikcie a me posli potencilnemu
tonkovi naprklad na manipulcie aplikcie alebo obdenie rznych bezpenostnch opatren.
5.4.1.7 Zneuitie prstupovch prv
asto maj aplikcie ovea viac prstupovch prv a privilgi ne v skutonosti potrebuj na
svoju innos. Typickm prpadom je, ke aplikcia be s administrtorskmi oprvneniami.
Z tohto dvodu potom dochdza k zneuitiu prstupovch prv a to hlavne v dvoch prpadoch:
Po spenom zneuit chyby v aplikcii m tonk irie monosti alej eskalcie

kompromitcie dajov, samotnej aplikcie alebo systmu na ktorom aplikcia be.
Samotn aplikcia me poskytova monosti tania a manipulcie dajov, ku ktorm by

pouvate (alebo tonk) za bench okolnost nemal prstup. Prklad: Majme informan
portl, ktor m za lohu sprstupova pouvateom urit dokumenty. Zrove tento portl
be so systmovmi oprvneniami. tonk si me cez uveden portl vyiada
sprstupnenie citlivho systmovho sboru, ku ktormu tonk kvli nedostatonm
oprvneniam prstup nem, ale portl vzhadom na svoje oprvnenia no.
5.4.2
Opatrenia na znenie dopadov aplikanch chb
V idelnom prpade by softvr nemal obsahova iadne bezpenostn nedostatky. ijeme vak
v relnom svete, kde je vinou proces nvrhu a vvoja rznym spsobom limitovan.
Preto je rozumn predpoklada, e kad aplikcia v konenom dsledku obsahuje zranitenosti,
ktor zatia neboli identifikovan.
Existuje riziko, e po nasaden naej aplikcie do prevdzky, v nej me neskr niekto
(potencilny tonk) objavi zranitenos, ktor aj nsledne spene zneuije. Na takto prpad
sa vieme pripravi vyuitm rznych technk a nstrojov, ktor zmiernia dopad takhoto toku.
Medzi uveden techniky a nstroje patria:
138
Separcia oprvnen (Privilege separation)
Modularizcia (Kompartmentalizcia)
Obmedzenie prstupu k aplikcim
Obmedzenie prstupovch prv aplikcie
Uvznenie aplikcie (Jailing)
Aplikan firewally
Kad z nich si teraz podrobnejie rozoberieme.

5.4.2.1 Separcia oprvnen (Privilege separation)
Separcia oprvnen je technika pouvan pri programovan aplikci a v potaovej
bezpenosti, pri ktorej je program rozdelen do ast (modulov), ktor maj pridelen len tie
oprvnenia, ktor potrebuj na plnenie uritej lohy. Pouva sa pre zmiernenie potencilnych
kd pri spenom toku na aplikciu.
Benou metdou pre realizciu separcie oprvnen, je rozdelenie (pomocou systmovej funkcie
fork) beiaceho procesu na dve oddelen procesy. Hlavn program (v) sa vzd vysokch
oprvnen a men program si tieto vysok oprvnenia uchov, aby mohol neskr vykona urit
privilegovan opercie. Men program (ten s vysokmi oprvneniami) je vytvoren tak, aby
istm spsobom (t.j. jednoducho a prehadne) vykonval privilegovan opercie a m menej
rozhran a jednoduchie rozhrania, ne druh v program vykonvajci vetky ostatn aktivity.
Takto nvrh zvyuje pravdepodobnos odhalenia prpadnch zranitenost v privilegovanej asti
kdu. To m za nsledok, e spen kompromitcia privilegovanho kdu, je ovea menej
pravdepodobn ne v prpade zvyku kdu. Obe asti pvodnho procesu potom komunikuj
napr. cez dvojicu socketov. A napriek tomu, e bude tto dvojica programov schopn vykonva
aj privilegovan opercie, nsledn spen tok na v program potom poskytne tonkovi
len minimlny prstup.
Separcia oprvnen sa pod UNIX-ovmi operanymi systmami tradine vykonva
rozlovanm medzi skutonmi ID pouvatea / ID skupiny a efektvnymi ID pouvatea / ID
skupiny pomocou setuid (2) / setgid (2) a svisiacich systmovch volan, ktor boli
pecifikovan tandardom POSIX. Ak s vak v kde aplikcie nesprvne umiestnen, mu by
takto vytvoren bezpenostn medzery zneuit na rozsiahlu kompromitciu aplikcie prpadne
systmu.
Mnoho dmonov sieovch sluieb mus vykona urit privilegovan opercie, napr otvori tzv.
RAW sockety (sieov rozhranie pre nzko-rovov komunikciu) alebo sieov socket pre
internetov komunikciu na nich vyhradench portoch. Taktie rzne administratvne nstroje
mu poas svojho behu vyadova pecilne oprvnenia. Takto softvr zvykne separciu
oprvnen riei takm spsobom, e sa po vykonan kritickch operci sm vzd
privilegovanch oprvnen a to tm spsobom, e zmen pouvatea pod ktorm be na nejak
neprivilegovan et. Tto akcia je pod Unix-ovmi operanmi systmami znma ako vzdanie
sa administratvnych prv (dropping root). Neprivilegovan as zvyajne be pod pouvateom
"nobody" alebo obdobnm samostatnm pouvateskm tom.
Separcia oprvnen sa tie me realizova pomocou rozdelenia funkci jednej aplikcie do
viacerch mench programov, a potom pridelenm rozrench oprvnen jednotlivm astiam
pomocou oprvnen sborovho systmu. Pri tejto metde potom jednotliv programy musia
navzjom komunikova prostrednctvom operanho systmu, take rozsah monch
zranitench miest je obmedzen (potom bezpenostn nedostatok v menej privilegovanej asti
aplikcie typicky neme by zneuit na zskanie vysokch oprvnen, ale nanajv na
vyvolanie stavu odmietnutia sluby (denial-of-service).
139
5.4.2.2 Obmedzenie prstupu k aplikcim

Kad aplikcia me obsahova bezpenostn nedostatky, ktor dosia neboli objaven,
prpadne nie s znme prevdzkovateovi aplikcie. Z toho dvodu je dobrou praxou obmedzi
prstup k aplikcii len pre tch legitmnych pouvateov a systmy, ktor dan aplikciu
potrebuj pre svoju prcu.
Prstup k aplikcii meme obmedzi na dvoch rovniach:
Loklne v rmci systmu

Na sieovej rovni
Loklne v rmci systmu

Ak je mon aplikciu spusti loklne na systme jej pouvatemi, je dobrou praxou aby bol
prstup k takejto aplikcii pridelen iba jej legitmnym pouvateom. Ak by prilo ku
kompromitcii neprivilegovanho pouvateskho tu v systme kde je naintalovan uveden
aplikcia, tonk nezska priamy prstup k aplikcii ak dan et nepatr jednmu z pouvateov
aplikcie. V prpade, e v systme nie s vetci systmov pouvatelia zrove legitmnymi
pouvatemi uvedenej aplikcie, pomha takto opatrenie zni poet potencilnych tonkov.
Na sieovej rovni
Podobne ako v prpade loklneho prstupu, je dobrm opatrenm obmedzi poet potencilnych
tonkov aj na sieovej rovni. Ak je to praktick, najlepie je toto opatrenie implementova na
rovni siete, mu by vak vyuit aj prostriedky OS, alebo samotnej aplikcie. Kadopdne,
obmedzenie prstupu k aplikcii pomha zni riziko zneuitia neskr objavenej zranitenosti
aplikcie.
5.4.2.3 Obmedzenie prstupovch prv aplikcie
V informanej bezpenosti existuje tzv. princp najmench oprvnen (tie znmy ako zsada
minimlnych oprvnen alebo zsada najniej autority), ktor poaduje, aby na uritej vrstve
abstrakcie vpotovho prostredia, mal kad modul (napr. proces, pouvate, program alebo
jeho as v zvislosti na kontexte), prstup len k informcim a zdrojom, ktor s nevyhnutn pre
jeho legitmny el.
Znamen to, e napr. pouvatesk et m ma pridelen iba tie oprvnenia, ktor s
nevyhnutn pre prcu konkrtneho pouvatea.
Naprklad pouvate pre zlohovanie nemus intalova softvr, take m ma prva iba na
spustenie zlohovania a spustenie aplikci svisiacich so zlohovanm. Akkovek alie
privilgi, naprklad pre intalciu novho softvru, s blokovan. Tto zsada by mala plati aj
pre osobn pota pouvatea, ktor zvyajne pracuje na svojom normlnom pouvateskom
te a na administrtorsk et chrnen heslom sa prihlasuje (a nsledne pod nm pracuje) iba
vtedy, ke si to situcia nevyhnutne vyaduje.
Pri aplikcii na pouvatea, sa pouvaj termny ako najmen pouvatesk prstup alebo
najmenej privilegovan pouvatesk et (LUA). Pouitie tchto termnov odkazuje na
koncept, e vetky pouvatesk ty by v kadom okamihu mali bea s tak nzkymi
oprvneniami ako je to len mon a tie aplikcie by mali by span s tak nzkymi
oprvneniami ako je to len mon.
Princp najmench oprvnen je iroko akceptovan dleit princp pouvan pri nvrhu, ktor
vrazne prispieva k zveniu ochrany dt, zneniu dopadov zlyhan aplikcie a obrane proti
tokom.
Medzi vhody uplatnenia tohto princpu patria:
Lepia stabilita systmu
140
Pokia je kd aplikcie obmedzen o sa tka zmien, ktor me v rmci systmu vykonva, je

ahie testova mon akcie a interakcie s inmi aplikciami, resp. modulmi tej istej aplikcie. V
praxi naprklad aplikcie s obmedzenmi prvami nebud ma dostaton prstup na
vykonvanie operci, ktor by mohli zhodi systm alebo nepriaznivo ovplyvni in aplikcie
spusten na rovnakom systme.
Lepie zabezpeenie systmu
Pokia je kd aplikcie obmedzen o sa tka aktivt, ktor me v rmci systmu vykonva,

zranitenos v jednej aplikcii tonkovi priamo neposkytne prstup ku zvyku systmu.
Jednoduchie nasadenie
Veobecne plat, e m menej oprvnen aplikcia vyaduje tm je ahie jej nasadenie v rmci
vieho prostredia. To obyajne vyplva z prvch dvoch vhod, aplikcie, ktor intaluj
vlastn ovldae zariaden, alebo vyaduj zven bezpenostn oprvnenia, zvyajne v rmci
svojho nasadzovania vyaduj alie kony. Tak naprklad rieenia na platforme Microsoft
Windows, ktor nevyaduj vlastn ovldae je mon spusti priamo bez intalcie, zatia o
ovldae zariaden musia by by intalovan samostatne pomocou sluby Windows installer,
aby bolo mon poskytn ovldau zven oprvnenia. [9]
5.4.2.4 Modularizcia (Kompartmentalizcia)
Princp najmench oprvnen funguje ovea lepie, ak prstupov truktra aplikcie nie je typu
"vetko alebo ni".
Prklad .1
Povedzme, e idete na dovolenku a potrebujete oetrovatea pre svoje domce zviera. Radi by ste
obmedzili prstup oetrovatea len na vau gar, kde bude ponechan v domci milik, km
ste pre. Ale ak nemte gar so samostatnm zmkom, potom nemte in monos, len
poskytn oetrovateovi ke ktor mu umonia prstup do celho domu.
Zkladnou mylienkou modularizcie je, e ak rozdelme aplikciu na o najviac (v rozumnej
miere) izolovanch jednotiek - modulov, meme zminimalizova mnostvo kd, ktor me
by tokom na aplikciu spsoben. Rovnak princp sa uplatuje pri ponorkch, ktor s vntri
rozdelen na mnoho rznych komr, z ktorch kad je samostatne hermeticky uzavret. Ak
poruenie trupu spsob naplnenie niektorej komory vodou, ostatn komory nie s dotknut.
Zvyok lodi tak me zachova svoju integritu a posdka me prei v astiach ponorky, ktor
nie s zaplaven.
Prklad .2
alm astm prkladom princpu kompartmentalizcie je vzenie, kde je monos vch
skupn odsdench zloincov zhromaova sa, minimalizovan. Vzni nespia vetci spolu
v jednej vekej miestnosti, ale v mench celch po jednom alebo dvoch. Dokonca aj ke je im
umonen zhromadi sa, povedzme v jedlni, alie bezpenostn opatrenia s adekvtne
zven aby pomohli kompenzova znan zvenie rizika.
Vo svete IT je ovea jednoduchie poukza na prklady zlej modularizcie, ako je njs tie
dobr. Klasick prklad toho, ako to nerobi, je tandardn unixov model privilgi, v ktorom sa
z bezpenostnho hadiska kritick opercie vykonvaj na bze "vetko alebo ni". Ak mte
admi-nistrtorsk oprvnenie pouvatea root, mete v podstate robi, o chcete. Ak nemte
root prstup, existuj rzne obmedzenia. Bez root oprvnen naprklad nemete otvra sluby
na portoch nich ne 1024. Rovnako nemete priamo pristupova na mnoho zdrojov
operanho systmu. Zpis na disk nemete vykonva priamo, ale muste s cez ovldae
zariaden.
V sasnej dobe, ak tonk spene zneuije chybu preteenia zsobnka v kde aplikcie ktor
be pod administrtorskm tom, me napr. vykonva priamy zpis na disk a manipulova s
akmikovek dtami v pamti jadra operanho systmu. Vo vine systmov nie s iadne
ochrann mechanizmy, ktor by tomu zabrnili. Z toho dvodu je napr. nemon vytvori na
141
loklnom pevnom disku log sbor, ktor neme by tonkom vymazan. tonk bude ma
v takomto prpade vdy monos obs ubovon intalovan ovldae, bez ohadu na to, ako
dobre tento ovlda spro-stredkovva prstup na zznamov zariadenie. Preto je dleit, aby
aplikcie vo veobecnosti nebeali pod administratvnym tom a ak existuje potreba tchto
oprvnen pre vkon uritej asti funknost, je dleit aby boli tieto prva pridelen (po
vhodnej modularizcii aplikcie) pridelen iba relevantnmu modulu. Takisto ako vea inch
princpov, mus by aj modularizcia pouit v rozumnej miere. Ak oddelme kad meniu
funknos do samostatnho modulu, ahko sa me sta, e vsledn systm bude plne
nepraktick.
5.4.2.5 Uvznenie aplikcie (Jailing)
Uvznenie aplikcie (Jailing) meme zjednoduene charakterizova ako obmedzenie
aplikanch tov na konkrtny adresrov strom a vybran prkazy.
Na vytvorenie Jail prostredia v prostred operanch systmov UNIX sli systmov volanie
chroot 111. Funkcia chroot v operanch systmoch UNIX vykon operciu, ktor zmen zdanliv
koreov adresr pre aktulne beiaci proces a jeho podprocesy. Program, ktor je spusten v
takto upravenom prostred sa nedoke odkazova (a preto zvyajne nem prstup) na sbory
mimo urenej adresrovej truktry. Upraven prostredie sa nazva "chroot jail" alebo
jednoducho Jail.
Chroot prostredie mono poui na vytvorenie a prevdzkovanie samostatnej virtualizovanej
kpie softvrovho systmu. To me by uiton okrem inho pre:
Testovanie a vvoj
Riadenie softvrovch zvislost
Kompatibilita
Zotavenie systmu
Oddelenie privilgi
Oddelenie privilgi
Programy maj umonen prena otvoren popisovae sborov (sbory, pipe truktry
a sieov pripojenia) do chroot prostredia, o me zjednodui nvrh Jail prostredia tm
spsobom, e nie je nutn ponechva pracovn sbory vntri chroot adresra. To tie
zjednoduuje spuanie potencilne zranitench ast privilegovanej aplikcie v sandbox-e
v rmci prevencie naruenia bezpenosti. Treba poznamena, e mechanizmus chroot nie je
dostaton na izolciu procesu s administratvnymi (root) oprvneniami.
Chroot mechanizmus nie je uren k obrane proti myselnej manipulcii privilegovanm (root)
pouvateom. Na vine systmov sa chroot kontexty neskladaj sprvne a chroot programy s
dostatonmi oprvneniami mu vykona druh chroot operciu a tak sa vymani z obmedzen.
Kvli zneniu rizika spojenho s touto bezpenostnou slabinou, by sa chroot programy mali
vzda oprvnenia pouvatea root akonhle je to mon prpadne by sa mal poui in
mechanizmus (ako napr. FreeBSD jail). Treba poznamena, e niektor systmy, ako naprklad
FreeBSD, priamo implementuj preventvne opatrenia, aby sa zabrnilo toku druhou chroot
operciou.
Pri svojom spusten programy oakvaj, e njdu doasn odkladac priestor, konfiguran
sbory, uzly zariaden a zdiean kninice v uritch prednastavench adresroch. Aby sa chroot
aplikcia spene spustila, mus by chroot adresr vopred naplnen minimlnou mnoinou
tchto sborov.
111
change root (directory)
142
Iba administratvny pouvate root me vykona operciu chroot. Toto m zabrni

pouvateom v spusten SETUID programu vntri pecilne vytvorenho Jail prostredia
(naprklad s falonm /etc /passwd a /etc/shadow sboru), ktor by ho zmanipulovalo tak, aby
pouvateovi zvil oprvnenia [15].
5.4.2.6 Aplikan firewally
Aplikan firewall je typ firewall-u, ktor kontroluje vstup, vstup a/alebo prstup z, alebo na
aplikcie alebo sluby. Pracuje tak, e monitoruje a prpadne blokuje vstup, vstup alebo volanie
systmovj sluby, v prpade ak nespa politiku nastaven na firewall-e. Aplikan firewall je
zvyajne schopn riadi sieov prevdzku na ubovonej vrstvy OSI a hore k aplikanej vrstve.
Je schopn kontrolova aplikcie alebo konkrtne sluby, na rozdiel od stavovho sieovho
firewall-u, ktor bez dodatonho softvru nie je schopn kontrolova prevdzku v sieti s
ohadom na konkrtnu aplikciu [16].
Existuj dve zkladn kategrie aplikanch firewallov:
Sieov aplikan firewall-y,
Systmov (host-based) aplikan firewall-y;
5.4.2.6.1 Sieov aplikan firewall-y

Sieov aplikan firewall pracuje na aplikanej vrstve OSI a je tie znmy ako proxy-based
firewall alebo reverse-proxy firewall. Aplikan firewall-y uren pre pecifick druh sieovej
prevdzky zvykn by pomenovan poda nzvu konkrtnej sluby, ako je naprklad webaplikan firewall. Sieov aplikan firewall-y mu by realizovan prostrednctvom softvru
beiaciho na hostiteskom systme alebo ako samostatn sieov hardvr. asto ide o systm
ktor pomocou rznych foriem proxy serverov podva komunikciu medzi klientom a serverom.
Pretoe pracuje na aplikanej vrstve, me kontrolova obsah komunikcie a blokova pecifick
obsah ako s urit webov strnky, vrusy alebo pokusy o zneuitie znmych logickch
nedostatkov v klientskom softvri.
Modern aplikan firewally doku tie odbremeni servery od ifrovania, blokova aplikan
vstup alebo vstup z detegovanch tokov alebo chybn komunikciu, riadi alebo konsolidova
autenti-fikciu prpadne blokova obsah ktor poruuje platn zsady [16].
5.4.2.6.2 Systmov (host-based) aplikan firewall-y
Systmov aplikan firewall doke sledova akkovek aplikan vstup, vstup alebo volania
systmovch sluieb z aplikci. Je to vykonvan tm spsobom, e firewall monitoruje
informcie podvan priamo v rmci systmovch volan namiesto zskavania tchto informci
zo sieovej komunikcie. Systmov aplikan firewall me poskytn ochranu len aplikcim
beiacim na tom istom systme.
Aplikan firewall vykonva svoju funkciu tak, e rozhoduje, i by konkrtny proces mal
akceptova prichdzajce sieov spojenie. Systmov aplikan firewall to riei tm spsobom,
e zachytva alebo aj filtruje volania medzi aplikanou vrstvou a nimi vrstvami OSI modelu.
Prkladmi systmovch aplikanch firewall-ov budcej genercie, ktor kontroluj volania
systmovch sluby s AppArmor a TrustedBSD MAC rmec (sandboxing) implementovan
v operanom systme Mac OS X.
Systmov aplikan firewall-y mu tie poskytova funknos filtrcie sieovej komunikcie
[16].
5.5 Pouvanie otvorench tandardov

Otvoren tandard je tak technick pecifikcia, ktor je
143
(1) prijat a udrovan neziskovou organizciou alebo konzorciom,

(2) jej al vvoj a modifikcie vychdzaj z otvorenho rozhodovacieho procesu, prstupnho
vetkm zujemcom, na zklade zhody alebo rozhodovania vinovm hlasovanm,
(3) je zverejnen a prslun dokumenty s prstupn bu volne, alebo za nominlny poplatok a
(4) prpadn svisiace duevn vlastnctvo patenty s neodvolatene bezplatne
sprstupnen pre vetkch rovnako [18].
Proprietrny tandard je pecifikciou hardvru alebo softvru, ktor je kontrolovan jednou
spolonosou. Ke je proprietrny tandard ako napr. Windows iroko pouvanm, stva sa
z neho de-facto tandard aj ke nie je spravovan tandardizanou organizciou [19].
Vytvran alebo nakupovan aplikcie, i vo veobecnosti softvr ako tak, by mali by
postaven na otvorench tandardoch a nie na uzavretch proprietrnych, ktorch detaily nie s
verejne dostupn.
Hlavn nevhody aplikci postavench na proprietrnych tandardoch:
Nemusia by interoperabiln s existujcimi alebo budcimi produktmi inch vrobcov
Vinou nie je znma rove bezpenosti tchto tandardov
Zkaznk me zosta v zvislosti na slubch a produktoch konkrtneho dodvatea
Aby bol softvr vbec uiton, mus by interoperabiln. Ak chceme vytlai dokument,
program textovho editoru mus by schopn komunikova s tlaiarou. Podobne mus by
webov prehliada schopn komunikova s webovm serverom, at.
Prklad:
Prklad s rozchodom koaj je vhodn metafora, ke chceme pochopi mylienku otvorench
tan-dardov. Rozchod koaj je vzdialenos medzi koajnicami na eleznici. Ak by kad mesto
alebo tt mal vlastn rozchod koaj alebo rozchody ich koaj by boli tajn, bolo by ak pre
vlak prejs od mesta k mestu. Dalo by sa to riei naprklad tak, e by bol podvozok rua
a vetkch vagnov vlaku vymenen za in na hranici kadho mesta alebo ttu, alebo by musel
by skontruovan zloit multi-prepravn systm umoujci prechod z jednej rky do inej.
Alebo naprklad preprava tovaru z miesta na miesto, by vyadovala vykladanie elezninch
vozov na hraniciach a znovu naloenie nkladu do inho vlaku.
Otvoren tandard pre softvr sa vzahuje na verejne dostupn pecifikcie pre zvldnutie uritej
lohy. Jedn sa o sbor dohd o niektorch aspektoch softvrovho systmu, ktor sa tka
kompatibility.
Najdleitejie otvoren tandardy s dtov formty. Napr. Web je zvisl od noriem ISO pre
znakov sady, a bez takho tandardu by obsahu Web-u mohlo by porozumen len v malej
oblasti, ktor sa dohodla na znakovej sade. Servery a prehliadae by mohli by pouiten len v
niektorch lokalitch.
Otvoren tandardy predstavuj vhodu pre vvojrov, ale ete viac s prnosom pre pouvatea
tm, e umouje vber produktu a technolgie.
144
5.6 Tvorba informanch systmov (poiadavky Vnosu o tandardoch

pre ISVS)
V nasledujcich tabukch poskytujeme prehad konkrtnych ast relevantnej legislatvy, ktor
m svis s aplikanou bezpenosou.
Legislatvna poiadavka
Zkon . 275/2006 Z. z. o informanch systmoch verejnej sprvy:
Zabezpeenie plynulej, bezpenej a spoahlivej prevdzky ISVS, ktor s v
sprve povinnch osb, vrtane organizanho, odbornho a technickho
zabezpeenia
Zabezpeenie informanho systmu verejnej sprvy proti zneuitiu
Relevantn as tejto
kapitoly
7 Vvoj bezpench
aplikci; najm 7.4
Nasadzovanie
6 Typick zranitenosti
aplikci a opatrenia proti
nim; najm 6.1 Typick
zranitenosti aplikci, 6.2
Opatrenia na znenie
dopadov aplikanch chb
Tabuka 5.1. Legislatvne svislosti Aplikanej bezpenosti so zkonom . 275/2006 Z. z. o

informanch systmoch verejnej sprvy
145
Relevantn as tejto
kapitoly
Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o

tandardoch pre informan systmy verejnej sprvy - Technick
tandardy minimlneho technickho zabezpeenia:
Ochrana proti kodlivmu kdu (softvrov ochrana, leglnos softvru) 4.1 Bezpenostn chyby v
softvri; 4.2 Konfiguran
chyby
Sieov bezpenos (firewall)
6.2 Opatrenia na znenie
dopadov aplikanch chb;
konkrtne 6.2.7 Aplikan
firewally
7.4.3 Prevdzkov
Fyzick bezpenos abezpenos prostredia (priestory areimov
opatrenia)
bezpenos
Aktualizciu softvru
4.1 Bezpenostn chyby v
softvri
Monitorovanie amanament bezpenostnch incidentov (ohlasovanie 7 Vvoj bezpench
aevidencia bezpenostnch incidentov, technick zabezpeenie)
aplikci; najm 7.3
Verifikcia, 7.4
Nasadzovanie
Periodick hodnotenia zranitenost (analza rizk)
7 Vvoj bezpench
aplikci; najm 7.3
Verifikcia
Zlohovanie (zabezpeenie zlohovania, testovanie zloh)
7 Vvoj bezpench
aplikci; najm 7.3
Verifikcia
Fyzick ukladanie zloh (umiestnenie prevdzkovch aarchivanch
7.2 Kontrukcia; najm
zloh)
7.2.3 Bezpen
architektra
Riadenie prstupu (autentizcia aautorizcia uvateov)
5.2 Aplikan
bezpenostn funkcie
Aktualizcia informano-komunikanch technolgi (plnovanie,
7 Vvoj bezpench
zmenov manament, testovanie a sprva dokumentcie)
aplikci
Uas tretej strany (analza rizk aSLA zpohadu spoluprce stretmi
7 Vvoj bezpench
stranami)
aplikci; najm 7.3
Verifikcia
Tabuka 5.2. Legislatvne svislosti Aplikanej bezpenosti s vnosom . 312/2010 Z.z.

Ministerstva financi Slovenskej republiky o tandardoch pre informan systmy verejnej sprvy
- Technick tandardy minimlneho technickho zabezpeenia
146
Relevantn as tejto
kapitoly
Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o

tandardoch pre informan systmy verejnej sprvy - tandardy pre ISVS:
Technick tandardy, vzahujce sa na technick prostriedky, sieov
7 Vvoj bezpench
infratruktru aprogramov prostriedky
aplikci; najm 7.2
Kontrukcia
tandardy pre prepojenie
5.1 Dleit aspekty
aplikanej bezpenosti;
5.1.4 Prostredie aplikcie
tandardy pre prstup k elektronickm slubm
6.2 Opatrenia na znenie
dopadov aplikanch chb
tandardy pre webov sluby
5 Aplikan bezpenostn
funkcie; najm 5.2
Aplikan bezpenostn
funkcie
tandardy pre integrciu dt
funkcie; najm 5.1
Dleit aspekty aplikanej
bezpenosti
tandardy prstupnosti a funknosti webovch strnok, vzahujce sa na
aplikan programov vybavenie poda zkona
funkcie; najm 5.1
bezpenosti, konkrtne
Pouvatesk prstupnos
aplikcie
8 Pouvanie otvorench
tandardy pouitia sborov, vzahujce sa na formty vmeny dajov
tandardov
tandardy nzvoslovia elektronickch sluieb, vzahujce sa na sieov
infratruktru
tandardov
Bezpenostn tandardy, vzahujce sa na technick prostriedky, sieov
funkcie; najm 5.1
infratruktru, programov prostriedky a daje
bezpenosti
Tabuka 5.3. Legislatvne svislosti Aplikanej bezpenosti s vnosom . 312/2010 Z.z.

- tandardy pre ISVS, as 1
147
tandardy pre architektru riadenia

tandardy minimlneho technickho zabezpeenia
Dtov tandardy, vzahujce sa na daje, registre a selnky

tandardy elektronickch sluieb verejnej sprvy, vzahujce sa na daje, registre,
selnky aaplikan programov vybavenie poda zkona
tandardy projektovho riadenia, vzahujce sa na postupy a podmienky spojen s
vytvranm arozvojom informanch systmov verejnej sprvy
Technick tandardy pre pripojenie, prstup k elektronickm slubm, webov sluby a
integrciu dt
tandardy prstupnosti a funknosti webovch strnok vzahujce sa na aplikan

programov vybavenie
tandardy jednorazovej elektronickej vmeny dt a formty vmeny dajov

tandardy nzvoslovia el. sluieb vzahujce sa na sieov infratruktru
tandardy pre architektru riadenia, minimlneho technickho zabezpeenia

Dtov tandardy pre daje, registre, selnky
7.4 Nasadzovanie
5 Aplikan
bezpenostn funkcie;
najm5.1.4 Prostredie
aplikcie
tandardov
5.2 Aplikan
bezpenostn funkcie
7 Vvoj bezpench
aplikci
5 Aplikan
bezpenostn funkcie;
najm 5.1 Dleit
aspekty aplikanej
bezpenosti
5 Aplikan
bezpenostn funkcie;
najm 5.1 Dleit
aspekty aplikanej
bezpenosti, konkrtne
Pouvatesk
prstupnos aplikcie
7.4 Nasadzovanie
5 Aplikan
bezpenostn funkcie;
najm 5.1 Dleit
aspekty aplikanej
bezpenosti
7.4 Nasadzovanie
tandardov
Tabuka 5.4: Legislatvne svislosti Aplikanej bezpenosti s vnosom . 312/2010 Z.z.

- tandardy pre ISVS, as 2
148
5.7 Zoznam pouitch zdrojov

[1]
Application security. Wikipedia, slobodn encyklopdia. [Online] [Dtum: 23. 8

2013.] http://en.wikipedia.org/wiki/Application_security.
[2]
ISO/IEC 27034-1 Information technology Security techniques Application security

Part 1: Overview and concepts
[3]
Veobecn pojmy. [Online] [Dtum: 24. 5

2013.] http://www.securityrevue.com/tbm/part1.html.
[4]
Data validation. [Online] [Dtum: 23. 7

2013.] https://www.owasp.org/index.php/Data_Validation.
[5]
Buffer overflows. [Online] [Dtum: 14. 7

2013.] https://www.owasp.org/index.php/Buffer_Overflows.
[6]
Application security. [Online] [Dtum: 23. 8

2013.] https://www.owasp.org/index.php/SQL_Injection.
[7]
Code injection. [Online] [Dtum: 6. 7

2013.] https://www.owasp.org/index.php/Code_Injection.
[8]
Cross-site scripting. [Online] [Dtum: 13. 7

2013.] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS).
[9]
Principle of least privilege. Wikipedia, slobodn encyklopdia. [Online] [Dtum: 17. 7

2013.] http://en.wikipedia.org/wiki/Principle_of_least_privilege.
[10] David L. Cannon, Timothy S. Bergmann, Brady Pamplin. CISA: Certified Information
Systems Auditor Study Guide. 2006. 0782144381.
[11] OWASP - The Open Web Application Security Project. [Online] http://www.owasp.org.
[12] Gary McGraw, John Viega, Software security principles, Part 3: Controlling access,
[Online] http://www.ibm.com/developerworks/library/se-priv/index.html.
[13] OpenSAMM - The Software Assurance Maturity Model,
[Online] http://www.opensamm.org.
[14] Session (Computer science). Wikipedia, slobodn encyklopdia. [Online] [Dtum: 20. 8
2013.] http://en.wikipedia.org/wiki/ Session_(computer_science).
[15] Chroot. [Online] [Dtum: 14.11 2013.] http://en.wikipedia.org/wiki/Chroot
[16] Application Firewall. [Online] [Dtum: 15.11
2013.] http://en.wikipedia.org/wiki/Application_firewall
[17] ACID [Online] [Dtum: 20.9 2013.] http://en.wikipedia.org/wiki/ACID
[18] Metodick pokyn na pouitie odbornch vrazov pre oblas informatizcie spolonosti
Verzia 1.0
[19] Proprietary standards [Online] [Dtum: 25.11 2013.] The Free
Dictionary http://encyclopedia2.thefreedictionary.com/proprietary+standards
149
6 Bezpenos prevdzky
Ivan Oravec a Erik Saller
6.1 vod
Cieom tejto kapitoly je poskytn prehad o prevdzkovej bezpenosti IKT organizci
ubovonej vekosti. Prevdzka informanch systmov je kadodenn sprva centrlnych
vpotovch prostriedkov organizcie.
Prevdzka informanch systmov je potrebn na zabezpeenie efektvnej innosti organizcie,
jej riadenie podlieha vedeniu organizcie a nevyhnutne zvis od jeho podpory. Bez ohadu na
vekos, zameranie a truktru organizcie je predpokladom jej spenho riadenia vyuitie
udskch zdrojov s primeranmi schopnosami, motivciou a dveryhodnosou.
Pod organizciou pre ely tejto kapitoly rozumieme spravidla ttne intitcie, rady, orgny
miestnej samosprvy, mze, kninice, domovy dchodcov, nemocnice at., teda organizcie,
ktor nemaj komern charakter.
Zdroje zahaj ud, financie, vybavenie, zariadenia, postupy a metdy. Informan systmy v
prevdzke s shrnom procedr, innost, ud a technolgi, majcich za cie zber relevantnch
dajov, ich uchovanie, ich spracovanie za elom poskytnutia odpoved na pecifick mnoinu
otzok a konen oznmenie informci ich uvateom. lohou informanch a komunikanch
technolgi (IKT) v innosti organizcie je podporova procesy, ktor v prevdzke prebiehaj
a zaznamenva ich vsledky. Bezpenos prevdzky je pecifick zmyslupln innos,
zameran na odvrtenie alebo minimalizciu bezpenostnch rizk, resp. bezpenostnch
ohrozen rznej povahy a priny voi biznis procesom organizcie. Organizcia potrebuje pre
bezpenos svojej prevdzky manament informanej bezpenosti z organizanho hadiska,
znalos princpov fungovania technickch bezpenostnch prvkov a tie znalos zkonov,
noriem a pravidiel pre bezpen nasadzovanie do prevdzky.
Cieom tejto kapitoly je poskytn prehad o prevdzkovej bezpenosti organizci (ubovonej
vekosti) manarom IT, manarom informanej bezpenosti, vedcim pracovnkom
a technikom. Pretoe bezpenos prevdzky je irok oblas a vyaduje si truktrovan prstup,
v kapitole budeme nasledova truktru tandardu ISO/IEC 27002.
Prevdzka by mala umoni spoahliv a efektvne vyuvanie zdrojov na dosahovanie cieov
organizcie. Zkladn funkcie prevdzky a podmienky poskytovania sluieb organizcie voi
objednvateovi s asto definovan v tzv. dohode o rovni sluieb (SLA).
Bezpenos prevdzky zaha prevenciu incidentov, servis a drbu IKT. Prevencia incidentov
sa dosahuje pomocou monitorovania a riadenia bezpenostne relevantnch udalost, asto aj
takch, ktor s len potencilnymi incidentami a v svislosti s inmi udalosami mu vies k
incidentu. Pokia ide o poiadavku dostupnosti (availability) v bezpenosti prevdzky ,
zabezpeujeme ju pomocou nasadenia redundantnch prvkov IKT a vypracovania
bezpenostnch plnov pre kontinuitu prevdzky a spoahliv obnovu v prpade havrie
(anglicky BCP business continuity planning a tie DRP disaster recovery plan). Tieto plny
poskytuj rieenie v prpade krzovho stavu (priom kritri toho, o je krzov stav sa rznia
poda predmetu innosti konkrtnej organizcie) a ustanovuj kroky potrebn pre rchlu obnovu
systmov IKT.
Dodriavanie dobrch praktk (anglicky best practices) v oblasti bezpenosti prevdzky zana
definovanm poiadaviek na bezpenos prevdzky, nasledovan zavedenm adekvtnych
kontrolnch mechanizmov.
Poiadavky na bezpenos prevdzky musia vdy zohadova aktulny stav prostredia,
ekonomick monosti a stratgiu organizcie.
150
Bezpenos prevdzky | MF SR
6.2 Procesy bezpenosti prevdzky

Pouit metdy zabezpeenia dtovho spracovania prostriedkami IKT sa zameriavaj
predovetkm na zachovanie a zvyovanie dostupnosti systmov pre koncovch pouvateov.
Cieom bezpenosti prevdzky je zabezpei poskytnutie IT sluieb na rovni dostatone
podporujcej ciele organizcie vyuitm prostriedkov, ktor s optimlne z hadiska
vynaloench nkladov. Bezpenos prevdzky vak nemono obmedzova len na dostupnos,
ale je nutn ju orientova tie na ostatn aspekty: dvernos a integritu dt spracovvanch
prostriedkami IKT.
Politika bezpenosti prevdzky uruje tie metdy akmi sa dta spracovvaj. Procesy ochrany
aktv, ktor slia na spracovanie dt implementuj mechanizmy pre redukciu rizk, ktor by
mohli vies ku kompromitcii dvernosti, integrity a dostupnosti ukladanch a spracovvanch
dt.
Pouvatesk prstupnos rozhrania informanho systmu, alebo prvku IKT je potrebn zladi s
poiadavkou prsnosti kontrolnch mechanizmov pouvateskch prv. Zrove je nutn
zabezpeenie zosladenia nasadzovanch mechanizmov s legislatvnymi poiadavkami a
priemyselnmi normami.
tandardy bezpenosti prevdzky (napr. poda normy ISO/IEC 27002) mono spravidla
aplikova pre vetky dtov centr, serverov miestnosti a vpotov stredisk, v ktorch sa dta
spracvaj a ukladaj bez ohadu na ich vekos a druh innosti. S spravidla klovaten
a pouiten v komernom prostred i v organizcich, ktor nemaj komern charakter.
6.2.1
Pokrytie biznis procesov operciami IS
Procesy s podporovan aplikciami beiacimi na prvkoch IKT. Tieto prvky IKT sa lia
vekosou, teda sa me jedna o ubovon systm v rozsahu od najvieho slovho potaa,
cez systmy IKT strednho rozsahu a po loklne siete osobnch potaov. Mu fungova
v pecializovanch prostrediach (napr. dtov centrum) alebo v bench pracovnch prostrediach
(kancelrie, fabriky, sklady). Pouvaj rozlin operan systmy v zvislosti na funkcii, ktor
plnia (IBM MVS, Digital VMS, Windows, Unix, Linux apod.).
S ohadom na potencilne incidenty a svisiace preruenia kontinuity prevdzky tchto systmov
sa kvli spoahlivej obnove ich prevdzky udruj auditn zznamy obsahujce tie informciu
o privilegovanom prstupe opertorov, alebo administrtorov [2].
Pokrytie prevdzkovch procesov zaha:
Manament prevdzky mus zabezpei definovanie toho, kto vlastn konkrtne informan
systmy podporujce procesy v organizcii (je ich biznis vlastnkom, anglicky business
owner). Zamestnanci zodpovedn za manament prevdzky definuj tie poiadavky na
spracovanie a monitorovanie produknch dt a kritria urovania prpadnch incidentov.
Manament sluieb IT s procesy a procedry na poskytovanie a podporu rznych funkci

IT, s ohadom na ich efektvnos. Zaober sa optimalizciou IT sluieb tak, aby naplnili
meniace sa poiadavky prevdzky organizcie. Tie m za lohu zhodnocova
a komunikova vylepenia kvality IT sluieb, rovnako ako komunikovanie ich prnosu
s ohadom napr. na niie nklady.
Podpora infratruktry, teda strategick plnovanie zdrojov, tkajce sa hardvrovch a

softvrovch platforiem, na ktorch informan systm pracuje.
Monitoring pouvania zdrojov aplikuje kontroln mechanizmy na zabezpeenie toho, e

prostriedky IKT s pouvan v slade s ciemi organizcie. Predpokladom takch
kontrolnch mechanizmov je vedenie zznamov o tom, kto tieto zdroje pouva, kedy a kde
s, alebo potencilne bud konkrtne zdroje potrebn a audit toho, i s zdroje zadoven za
sumu peaz, ktor shlas s aktulnymi trhovmi podmienkami pre produkt s obdobnmi
pecifikciami.
151
Technick podpora (anglicky helpdesk) je zodpovedn za operatvnos vyvinutch rieen

a ich bezproblmov nepreruovan chod. Tto as prevdzky by mala prebera
zodpovednos za rieenie vzniknutch incidentov, pokia nejde o incidenty spojen
s informanou bezpenosou.
Procesy zmenovho manamentu, ktor zaisuj, e na efektvne a promptn nasadzovanie

zmien v IT infratruktre bud pouit tandardizovan metdy a procedry. Cieom
zmenovho manamentu je tie zni mnostvo a vplyv potencilnych incidentov
svisiacich s nasadzovanou zmenou [3].
Kontrola kvality vyvjanch aplikci a implementovanch zmien, napr. pomocou internho,

alebo externho auditu, pomocou diskusi s kovmi riadiacimi a zodpovednmi
pracovnkmi, ako aj rozhovormi s inmi relevantnmi pracovnkmi (napr. v prevdzke a na
oddelen IT), previerkou dostupnej dokumentcie, pozorovanm a testovanm relevantnch
kontrolnch postupov a bezpenostnch nastaven.
Riadenie bezpenosti informci uloench na mdich zaha procesy pre zlohovanie,

uchovvanie a obnovu dt.
V praxi sa ete vdy asto stretvame s tm, e bezpenos sa povauje len za nechcen
prvlastok, ale mala by by tandardnou integrlnou sasou kadej z uvedench oblast.
6.2.2
innosti manamentu prevdzky
Medzi innosti oddelenia zodpovednho za manament prevdzky patr:
alokcia prostriedkov,
tvorba tandardov a procesov,
monitorovanie efektvnosti biznis procesov vo vzahu k bezpenostnm opatreniam,
vypracovanie analzy dopadov na prevdzku (BIA),
vvoj a implementcia politk, procedr a tandardov,
implementcia formlneho manamentu zranitenost,
zabezpeenie pravidelnch internch a externch auditov.
6.2.2.1 Dokumentcia procesov manamentu prevdzky

Monitorovanie funknosti a efektvnosti vytvorench prevdzkovch procesov nasleduje po
implementcii navrhnutch tandardov.
Vetky svisiace aktivity by mali by riadne zdokumentovan. Dokumentcia by mala by
udriavan a aktualizovan pri kadej relevantnej zmene, dostupn vetkm pouvateom,
ktorch sa zmeny tkaj a ktor informcie v nej uveden potrebuj k vykonvaniu svojej prce.
Dokumentcia procesov by mala by pripraven pre vetky aktivity, ktor svisia so spracovanm
dt. Systmov administrtori a opertori musia by nleite pouen a motivovan k dodrovaniu
dvernosti citlivch informci v slade s poiadavkami urenmi vlastnkom systmu, alebo
vlastnkom dt, prpadne legislatvnymi alebo internmi predpismi. Dokument bezpenostnej
politiky zavdza spsoby, akmi sa k dtam pristupuje s ohadom na ich klasifikciu a
zachovanie ich dvernosti, integrity a dostupnosti.
Poiadavkami na bezpenos prevdzky s:
Poiadavka na bezpen spracovanie dajov a ochranu informanch aktv ochrana

organizcie pred stratou a kompromitciou informanch aktv.
Poiadavka na udrovanie bezpenosti podpornej infratruktry ochrana podpornej

infratruktry pred tokmi a kompromitciou.
152
Poiadavka na riadenie prstupu pouvatelia na sieti maj len tak rove prstupu
k zdrojom organizcie, ako si vyaduje plnenie ich pracovnch povinnost, alebo na ak maj
oprvnenie.
Poiadavka kontroly prstupu k hardvru hardvr je asto zraniten voi loklnym

tokom, t.j. bezprostrednmu pozmeneniu konfigurcie, pokodeniu, znieniu, alebo
nastreniu prostriedkov na odchytvanie stlaench klves, odpovanie, alebo
neautorizovan zaznamenvanie obrazu. V rmci bezpenosti prevdzky by sa malo riei
zamedzenie takejto kodlivej innosti.
Poiadavka na kvalifikovan obsluhu na prcu s prvkami IKT by mal by vyhraden

kvalifikovan personl, priebene kolen na vkon pridelench innost.
Poiadavka na dostaton kapacitu pre sprvnu funkciu systmov v rmci plnovania by

mali by zohadovan nroky na prevdzku a vas alokovan prostriedky na potrebn
technologick zmeny.
Plnenie bezpenostnej politiky dodranie legislatvnych poiadaviek a poiadaviek

stanovench relevantnmi tandardami.
Prevdzkov dokumentcia v organizcii by preto mala pokrva tieto procesy:
Procesy spracovania, prenosu a uchovvania dt prostrednctvom informanch systmov.
Konkrtnu pecifikciu krokov pri realizcii naplnovanch aktivt, ako s importy a exporty
dajov medzi informanmi systmami a logick naasovanie ich zaiatku a konca.
Informcie o nastavenom zlohovan dt. Zlohovanie by malo by nastaven tak, aby boli
dleit dta zlohovan v sprvnej frekvencii, rozsahu a ukladan na sprvne miesto
(loklne, alebo na geograficky oddelen lokalitu, at.).
Procesy na zvldnutie chb, zlyhan a neoakvanch stavov svisiacich s prevdzkou.

Konkrtne intrukcie by mali by zahrnut a prstupn v dokumentcii.
Zoznam kontaktov a systematick eskalan procedry, ktor treba vyui v prpade vskytu
incidentov. Eskalan procedry uruj kroky, ktor treba podnikn v prpade, e rove
poskytovanch sluieb nedosahuje rove uveden v zmluve SLA.
Zaznamenvanie relevantnch udalost (auditnch zznamov a dt pouitench pre audit)

v potrebnom rozsahu a s potrebnou podrobnosou.
Prevdzkov dokumentcia mus tie obsahova postupy zadvania zmenovch poiadaviek

a kroky zmierovania nsledkov prevdzkovch a pouvateskch incidentov. Mu by
formalizovan v plnoch kontinuity innost (Business continuity planning - BCP) a havarijnch
plnoch (Disaster recovery plan - DRP).
Nstroje podpory riadenia sluby (anglicky IT service desk alebo IT service management)
pomhaj automatizova a zjednoduova cel proces riadenia zmien, drby IKT a manamentu
incidentov. V nich sa zaznamenva popis vykonanch innost od momentu inicicie rieenia a
po spen implementciu poiadavky na zmenu, vykonania drbovej opercie, alebo
eliminciu priny incidentu. Pokroilejie systmy implementuj tie funkcie na automatick
sprvu znalost (anglicky knowledge management), ktor pri sprvnom pouvan vrazne
zniuj riziko straty vedomost a dleitch znalost pri fluktucii zamestnancov.
6.2.3
Kontroln mechanizmy
Na zaistenie sprvnej a bezpenej prevdzky systmov IKT je potrebn vytvori Bezpenostn

politiku.
Cieom tejto politiky je nastavenie podmienok pre zabezpeenie primeranej rovne ochrany
vetkch informanch aktv, s ktormi IKT, pracuje proti hrozbm, ktor na ne psobia z
pohadu dvernosti, integrity a dostupnosti. Nie je dleit ich len zosladi so tandardami, ale
153
zohadni tie pecifik zodpovednost a procedr manamentu prevdzky v konkrtnej

organizcii.
Na overenie splnenia predpokladov pre bezpenos prevdzky sa poda dobrej praxe odpora
pravideln intern alebo extern audit. Dkladnos, rozsah a frekvencia takhoto auditu zvis od
vznamu dotknutch informanch systmov pre organizciu a inch kritri (pozri napr.
ISO/IEC 27008).
6.2.3.1 Kontrola nad privilegovanm prstupom
Privilegovan pouvate je pouvate, ktormu je kvli jeho funkcii, dveryhodnosti a/alebo
znalostiam pridelen oprvnenie pristupova k zdrojom IKT na rovni administrtora, teda vo
vznamne irom rozsahu ako m vina ostatnch pouvateov toho istho systmu. Kontrola
nad privilegovanm prstupom sa v praxi realizuje na rznych rovniach, me sa jedna o
obmedzenie pouvateskho prstupu na rovni fyzickho vstupu do budovy, operanho
systmu, informanho systmu a pod.
Ben pouvate m len urit rove prstupu, ktor je nevyhnutn pre realizciu
kadodennch loh v konkrtnom systme. Kad systm m systmov sbory, ktor s pre beh
systmu dleit. Pri neautorizovanej modifikcii tchto sborov me dochdza k problmom,
ktor by mohli narui beh operanho systmu sliaceho na prevdzku dleitej sluby,
prpadne znemoni pouvateom rieenie ich dennch povinnost. Privilegovan prstup
administrtora poskytuje monos vyuva pri plnen povinnost svisiacich s drbou tie asti
informanho systmu, ktor nie s benm pouvateom prstupn. Vyadovanie prihlsenia
administrtora do privilegovanch ast systmu je prnosn, pretoe zabrauje myselnmu
alebo nemyselnmu pokodeniu systmu zkodnm alebo nesksenm administrtorom.
Oprvnenia na privilegovan prstup by mali by pridelen iba na limitovanmu okruhu
pouvateov. Pouvate s privilegovanm prstupom k operanmu systmu (administrtor,
v linuxovch systmoch nazvan root) m prva intalova nov softvr, odintalova
softvr, alebo meni nastavenia systmu. Administrtor operanho systmu m zva takisto
monos modifikova nastavenie kontroly prstupu tak, aby umonil prstup neautorizovanm
pouvateom. Je potrebn si uvedomi, e ak djde ku kompromitcii mechanizmov riadenia
prstupu, tonkovi je vo vea prpadoch umonen prstup ku vetkm zdrojom, ku ktorm m
prstup samotn systm. Administrtor je oprvnen pozmeni auditn zznamy operanho
systmu a (napr. pri sasnej kompromitcii systmu IDS/IPS) ovplyvova nastavenia detekcie
incidentov tak, aby jeho potencilne nebezpen aktivity zostali nezachyten. Takto napadnut
systm me by asto pozmenen a me by negatvne ovplyvnen funkcia detekcie a znienia
kodlivho kdu (malware). Eventulne na om me djs tie k nasadeniu tzv. zadnch
vrtok (backdoorov), ktor umouj tonkovi sptn prihlsenie a prstup ku
kompromitovanmu systmu. Detekcia takto pozmenench pouvateskch stanc a serverov je
problematick a asto neefektvna.
Nasadenie systmu na odhalenie a prevenciu prieniku (Intrusion Detection/Prevention System IDS/IPS) na detekciu odchlky od korektnho fungovania pouvateskch stanc a detekciu
indiktorov naruenia sieovej prevdzky infratruktry organizcie tonkom m priazniv
vplyv na prevenciu svisiacich incidentov.
asto vak ani metdy pouit IDS/IPS systmami akmi s napr. detekcia neobvyklch vzorov
sprvania v sieovej prevdzke, alebo hbkov kontrola prenanch paketov (anglicky deep
packet inspection) nezaruuj pln ochranu voi existujcim hrozbm.
Administrtorsk prva, ktor by za normlnych okolnost mali by pridelen len zkej skupine
administrtorov, mu by nevyhnutn aj pre zamestnancov na pozcich vvojrov, operatvy,
alebo systmovho monitorovania. Dobrou praxou je v takom prpade model riadenia prstupu,
v ktorom s pouvatelia zaraden do skupn (anglicky groups), ktor maj pecifick rovne
prstupu a prva.
Toto definovanie privilegovanch prstupov pre skupiny pouvateov a s nm svisiace
prideovanie a odnmanie prstupovch prv sa deje kontrolovanm spsobom poda druhu
154
innosti vykonvanej pouvatemi. Sprvne odstupovanm riadenm prstupu pouvateov

k zdrojom je systm vystaven niiemu riziku incidentov spojench s neautorizovanm
prstupom a pozmenenm dleitch nastaven.
Implementcia obmedzenia neautorizovanch aktivt administrtorskch pouvateov nie je
jednoduch a preto je vhodn zavies monitoring systmovch zmien pomocou ktorho je mon
aktivity administrtorov posudzova v kontexte ostatnch bezpenostne relevantnch udalost
a to zvonka systmu (teda tak, aby ich tonk nemohol zmeni na napadnutom loklnom
systme). Medzi takto upresujce udalosti patr naprklad informcia:
z ktorho tu benho pouvatea dolo k eskalcii privilgi - pokia nelo o priame

prihlsenie administrtorskho uvatea,
i ku eskalcii privilgi dolo po prvej vzve na zadanie administrtorskho hesla,
i k privilegovanmu prstupu dolo v ase, alebo mimo asu benej prevdzky,
ak prkazy boli spusten a ktor systmov sbory boli zmenen.
Na to, aby sme mali dveryhodn zznam o vetkch tchto podrobnostiach innost
administrtorov, je nutn prve splnenie predpokladu zachovania integrity a autentickosti
auditnch zznamov. Dobrou praxou je okamite (resp. v stanovench intervaloch) prena
zznamy o bezpenostne relevantnch udalostiach na in systm v sieovej infratruktre, ktor
sa star o ich vyhodnocovanie, ukladanie, triedenie a prpadne vykonanie vhodnch protiopatren
(napr. Intrusion Prevention System IPS).
6.2.3.2 Separcia kanlov pre administrciu od kanlov pre ben prevdzku
Pouvanie spolonch tov pre viacero pouvateov nie je v slade so tandardami
bezpenostnch politk a predovetkm pri administrtorskom prstupe predstavuje vek riziko
zneuitia. Idelne je preto zabezpei separciu tov pre administrciu od tov pre ben
prevdzku. Zskanie prstupu do privilegovanho tu z tu benho pouvatea sa v idelnom
prpade deje a pri splnen vopred stanovench podmienok (autentifikcia) a je nevyhnutn
zabezpei riadne zaznamenvanie (auditovanie) takejto innosti, tak aby bolo jasn, kto a kedy
vyiadal administrtorsk prva.
Zaznamenvanie operci vykonanch pouvatemi a administrtormi sa nazva accounting.
Jeho implementciou v prstupe k sieovm zariadeniam je napr. TACACS+. Tento nstroj vak
nepln iba funkciu accountingu, ale okrem nej vykonva ete autentifikciu (anglicky
authentication) a autorizciu (anglicky authorization).
6.2.3.3 Kontrola integrity
V praxi sa hlavne pri snahe vyhovie prsnejm tandardom nasadzuj nstroje na overovanie
integrity systmovch a aplikanch komponentov a ich aktualizci pred intalciou pomocou
haovania sborov a ich porovnvania s etalnovmi hami. Etalnovmi hami mme na
mysli tak, ktor s v databze softvrovho nstroja na kontrolu integrity veden ako vzorov
a boli sprvne overen. Tento spsob overovania integrity sa najastejie v praxi pouva na
detekciu neautorizovanho zsahu do programovho vybavenia alebo dleitch konfiguranch
sborov.
Nstroje pouvan pri kontrole integrity (naprklad Tripwire) deteguj pozmenenie dt
neoprvnenou osobou a v prpade ak je to vhodn a mon vykonaj aj npravn opatrenia (napr.
korekciu vlastnctva a prstupovch prv sborovho systmu). Mu by sasou kontrolnch
mechanizmov sliacich na prieben vyhodnocovanie dodriavania bezpenostnch politk
organizcie. Poskytuj monosti korelcie logov a vyvodenia zverov o svislostiach incidentu.
Ich vstup je mon vyui pri zbieran digitlnych dkazov, napr. poda tandardu stanovenom
v dokumente ISO 27037.
155
6.2.3.4 Zmena poiatonej konfigurcie po intalcii

V praxi asto dochdza k tomu, e i pri implementcii kvalitnho a drahho informanho
systmu s pokroilmi bezpenostnmi funkciami sa pozabudne na zmenu prednastavench
hesiel, prpadne sa v systme ponech menej bezpen nastavenie komunikanej metdy, ktor
umon tonkovi prienik do systmu, alebo posli ako medzikrok k spenmu prieniku.
Typickmi prkladmi s nastavenia slabch hesiel pre administrtorskho pouvatea ako napr.
admin, administrator, root, toor , alebo in trivilne uhdnuten znenia.
Pokia ide o konfiguran nedostatky, me sa sta, e je aj pokroil VPN rieenie pri
nasadzovan a nastaven dodvateom ponechan s nevhodnm protokolom na vmenu kov,
ktor m sli iba ako doasn rieenie. Za vetky problematick nastavenia spomeme
agresvny md VPN siet, anglicky aggresive mode, pri ktorom m tonk monos relatvne
trivilnym tokom odchyti autentifikan hash zaloen na tzv. preshared key - zdieanom
ki, pouitom na nie vemi bezpen komunikciu dvoch koncovch uzlov VPN siete.
V prpade VPN rieen je neporovnatene jednoduchie toi na takto nedostatone nastaven
rovne zabezpeenia, ako sa napr. pa do kryptografickej analzy prenanch dt.
Predovetkm pri proprietrnych systmoch tie existuje hrozba, e systm bude obsahova
predprogramovan pouvatesk men a hesl (hard-coded credentials), ktor mu
potencilnemu tonkovi posli ako zadn vrtka a predstavova vek bezpenostn riziko
neautorizovanho prstupu.
Pri aktualizcii dleitch systmovch a aplikanch softvrovch komponentov (napr.
v exponovanch prevdzkach) sa mus postupova v slade so tandardami, ktorch dobr
praktiky odporaj pravideln rozbaovanie novch verzi informanch systmov,
operanch systmov a softvrovch balkov vo veobecnosti najprv do testovacieho prostredia.
A po ich dkladnom otestovan dochdza k ich nasadeniu do tzv. produknej prevdzky, ktor
pracuje s relnymi dtami v ostrej prevdzke.
Zo sksenost je mono kontatova, e proprietrne systmy s spravidla vmi nchyln na
vskyt chb pri vvoji, hlavne pokia pouvaj netandardn protokoly na vmenu dt, alebo
netandardn metdy na ukladanie dt. Tieto chyby poskytuj priestor pre hrozby, ktorch
zneuitie tonkom predstavuje potencilne riziko naruenia dvernosti spracovvanch dt, ich
vymazanie, alebo neautorizovan modifikciu, nestabilitu softvru a nedostupnos produknho
systmu na ktorom je tento softvr nasaden. Iniciatvy vvoja softvrovch produktov
s otvorenm zdrojovm kdom (open source) a tandardizcia metd vvoja softvru pomha
zniova vskyt incidentov zaprinench softvrovmi chybami. Tm, e s softvrov
produkty s otvorenm zdrojovm kdom masovo vyuvan a ich testovanie je vykonvan
vekou komunitou vskumnch pracovnkov v oblasti bezpenosti aj masou pouvateov na
celom svete, je zven pravdepodobnos objavenia a nslednho odstrnenia vekej viny
softvrovch chb. Prkladom komunitnho softvru, ktor m irok uplatnenie na produknch
platformch je webov server Apache.
Pri ochrane systmovho a aplikanho kdu a dajov proti neoprvnenej manipulcii poas
prevdzky pomha kontrola integrity pomocou haovania dleitch sborov a archivcia
vstupov haovacch algoritmov, kvli neskoriemu porovnaniu. Pre kontrolu integrity sa mus
poui kryptograficky siln haovacia funkcia. Implementciou tohto prstupu je naprklad u
spomnan nstroj Tripwire a v praxi sa vyuva jeho nasadzovanie naprie vetkmi
produknmi serverovmi systmami v produkcii.
V prpade nasadzovania novch komponentov do existujcej infratruktry je nutn, aby nov
hardvr a softvr zapadol do aktulnej mozaiky IKT prostredia a poda monost nespal
lohy, ktor u za neho pokrva in systm (pokia to nie je explicitne vyadovan). Niekedy
dochdza k zbytonm kolzim technolgi kvli nesprvnemu plnovaniu, napr. pri pouit
viacerch VPN rieen naraz. Pripojenie na VPN, ktor sprstupuje sieov zdroje (dtov
loisk, informan systmy, webov lokality, at.), z nej nsledn pripojenie na in VPN,
kvli prstupu k inm zdrojom nemus vdy fungova prve kvli tomu, e dochdza ku kolzim
s ktormi sa nertalo pri pvodnom plnovan. Prkladom me by problm v prstupe
156
k loklnym, alebo naopak vzdialenm sieovm zdrojom (kolzia adresnho priestoru podsiet
v loklnej sieti s rovnakm adresnm priestorom vo vzdialenej sieti, napr. obe siete by nemali
pouva rozsah 192.168.1.x).
6.2.3.5 Aktualizcia softvru
Centralizovan sprva aktualizci informanch systmov v prostrediach so zloitejou
infratruktrou sa typicky riei vyhradenmi repozitrmi aktualizci v rmci konkrtnej
organizcie, ktor s v danom prostred (na konkrtnych platformch, napr. hardvrovch) riadne
odskan a pri ich nslednom nasaden na koncovch staniciach a serveroch nedochdza
k nepredvdatenm chybm.
Aktualizcia pouvanch systmov je dleit, pretoe aktualizcie systmov alebo aplikci s
dodvatemi vytvran s cieom odstrnenia znmej bezpenostnej alebo inej chyby v ich
produkte. Pri nasadzovan aktualizci je potrebn myslie aj na rizik z tohto procesu
vyplvajce. S kadou novu nasadenou aktualizciou sa toti systm vystavuje napr. riziku
nestability. Paradoxne s po aplikovan zplaty niekedy do systmu vnan zranitenosti.
Typickm prkladom takhoto neiadceho dsledku bolo, ke v mji 2008 vvojov tm
linuxovej distribcie Debian vydal nov stabiln verziu balka OpenSSH s vrazne
zmenenm priestorom generovanch SSH kov, m vystavil produkn servery na celom
svete riziku spenho toku hrubou silou.
6.2.3.6 Kontrola nad hardvrom
Dokonca aj pri korektne nastavench pravidlch riadenia prstupu, sprvnom manamente
pouvateskch tov a hesiel na sieovch zariadeniach, dobrej politiky konfiguranho
manamentu a aktualizci softvru me tonk vyui niektor z metd neautorizovanho
pripojenia na hardvr za elom zskania a zneuitia citlivch informci. Pouvan techniky
zahruj pripojenie sledovacieho nstroja na trunk port sieovho zariadenia kvli
monitorovaniu
a eventulnej
modifikcii
sieovej
prevdzky,
priamy
prstup
k administrtorskmu rozhraniu komponentu IKT/informanho systmu, alebo v pecifickch
prpadoch o pouitie sondy, ktor aktvne alebo pasvne nara dvernos a/alebo integritu
prenosu dt po zbernici potaa, alebo sieovej, resp. telekomunikanej linke.
Prstup k systmovm zdrojom je kontrolovan operanm systmom/firmvrom, ale treba ma
na pamti, e zariadenia pripojen k tomuto systmu mu tie poskytn tonkovi informciu,
ktorej vyzradenie pre ns me predstavova hrozbu. Z tchto dvodov je potrebn dodriava
reimov opatrenia a riadi prstup tie na rovni fyzickej bezpenosti, v rmci ktorch povolme
prstup do serverovn a kancelri, kde s umiestnen prvky IKT iba obmedzenmu okruhu osb,
ktor s dostatone dveryhodn a pouen o zsadch bezpenej manipulcie s dtami a
citlivmi dokumentmi. V prpade ak je potrebn, aby cudzia osoba pristupovala k tmto
priestorom, je nutn aby sa tak vdy dialo v sprievode kvalifikovanho a pouenho personlu.
Viac o reimovch opatreniach, fyzickej a objektovej bezpenosti njdete v prslunej asti tejto
publikcie.
6.2.4
Riadenie zmien
Riadenie zmien je jednou z kovch oblast manamentu prevdzky. Zabezpeuje

kontrolovan implementciu autorizovanch zmien v produknch systmoch. Tieto produkn
systmy mu predstavova systmov, alebo aplikan softvr, me sa vak tie jedna
o hardvrov komponenty, alebo in platformy (napr. softvrov produkty typu middleware,
ktor s na rozhran medzi operanm systmom a aplikanm softvrom). Poiadavky na
zmeny mu vo veobecnosti prichdza z celej organizcie. Pokia ide o technologick zmeny,
mu by iniciovan tie oddelenm sprvy IT, alebo zamestnancami v tejto roli. Je dleit
uri, kto je oprvnen poiadavky na zmeny pecifikova a zabezpei ich integrciu s
procesmi, ktor podporuj.
loha zostavenia stratgie je v rukch manamentu a prslun stratgii podliehajce
technologick zmeny by mali by odshlasen architektmi, prpadne inmi osobami v roli
157
zodpovednej za technick ohodnotenie monch rizk navrhovanch zmien (naprklad oddelenie

bezpenosti, alebo osoby v prslunej roli). lohou manamentu spolu s oddelenm IT by malo
by zabezpeenie toho, aby do IT prostredia boli zaveden iba autorizovan a adekvtne
otestovan zmeny. Potom je mon pristpi k ich samotnej implementcii.
Zmeny v produknch systmoch zahaj:
implementciu novch aplikci,
modifikciu existujcich aplikci,
odstraovanie starch aplikci,
aktualizciu, alebo zapltavanie systmovho softvru.
Z bezpenostnho hadiska ns zaujma potencilny dopad tchto zmien, predovetkm ak ich

implementcia nie je riadne zdokumentovan (napr. automatizovanm systmom pre riadenie
zmien, anglicky IT Service management), alebo riadne schvlen manamentom (napr. pomocou
informanho systmu pre formlne schvaovanie navrhovanch zmien, ktor me by
integrovan rovnako tak v IT Service management softvri).
V praxi sa formlna strnka riadenia zmien asto obchdza. Zmeny sa nedokumentuj do
informanho systmu na to urenho, ale sa robia na dobr slovo (komunikciou cez email,
telefn, alebo intern chat). Dvodom pre takto nesprvny prstup je bu neexistencia
samotnho formlneho systmu na riadenie zmien, alebo to, e implementcia zmien bez ich
dokumentovania je menej asovo nron. Tento prstup m vak negatvne nsledky, ktorch
prkladom je:
Implementcia zmien bez riadneho posdenia dopadov navrhovanej zmeny na IKT a jeho
prostredie, o me vysti do nefunknosti alebo nestability IKT a svisiacich
komponentov.
Implementcia zmien bez odshlasenia vetkmi zainteresovanmi stranami (napr.
vlastnkom menenho systmu) o me vznamne narui chod aktivt podporovanch
danm systmom.
Neekonomick nakladanie s prostriedkami spsoben implementciou funknosti, ktor
je u vo fze rieenia v rmci inho projektu.
Preto je potrebn v kadej organizcii zavies politiku riadenia zmien, ktor okrem inho uruje
ich riadne dokumentovanie. Politika riadenia zmien sa me pecificky venova operanm
systmom, sieam, hardvrovm komponentom informanch a komunikanch technolgi
a podpornej infratruktry potrebnej pre prevdzku IT prostredia (chladenie, klimatizcia,
elektrick rozvody). Politika je nevyhnutn kvli zveniu efektivity (mono nie okamitej, ale v
konenom dsledku sa systematick zavdzanie zmien odzrkadl v lepie fungujcej
infratruktre) a prehadnosti vykonanch zmien. Procesy definovan politikou tie stanovuj
nleitosti notifikcie (riadneho komunikovania uskutoovanch zmien) smerom k
pouvateom, ktorch sa uskutoovan zmena dotka. Takto notifikcia pouvateov je
vemi dleit, kee cieom riadenia zmien je implementova zmeny v informanch
systmoch a IKT prostred, ktor vo vine prpadov slia prve im. Kad (ohlsen, alebo
neohlsen) vpadok sluby IKT by mal negatvny dopad na efektivitu nimi vykonvanch
innost.
Organizcie si vinou osvojuj proces riadenia zmien a modifikuj procesy pre svoje
individulne potreby. Procesy riadenia zmien by mali by navrhnut tak, aby zohadovali
nklady vynaloen na implementciu zmeny vo vzahu k vhodm z nej plyncim. Toto
zhodnotenie sa anglicky nazva business case. Business case navrhovanej zmeny mus by
riadne zanalyzovan a malo by by priebene hodnoten jeho plnenie.
Zmeny systmov by sa mali teda dia kontrolovanm spsobom poda tandardov. V tomto
snaen pomhaj tie dobr praktiky zhrnut v norme ISO 27002, ktor poskytla vzor pre
legislatvny rmec metodiky informanej bezpenosti vo vnose MVSR . 312/2010.
158
Nleitosti procesov riadenia zmien:
Identifikcia a zznam signifikantnch zmien
Udrovanie zznamov o tom, kto me autorizova zmeny
Udrovanie auditnch zznamov ku vetkm zmenovm poiadavkm
Uistenie o tom, e zmenov poiadavky mu zadva len autorizovan pouvatelia
Zavedenie a udrovanie formlnej schvaovacej procedry pre navrhovan zmeny
Uistenie o tom, e autorizovan pouvatelia akceptuj zmeny pred ich implementciou
Plnovanie a testovanie zmien
Previerka opatren a integritnch procedr pre uistenie sa o tom, e nebud naruen

konkrtnymi zmenami
Identifikcia a overenie kritickch funkci pre znenie pravdepodobnosti zavedenia znmeho

bezpenostnho nedostatku alebo zranitenosti plnovanou zmenou
Posdenie potencilnych dopadov (vrtane bezpenostnch dopadov) tchto zmien
Identifikcia vetkch systmov, siet, hardvru, firmvru, softvru, inho vybavenia,

databz, dokumentovanch procesov a procedr, priestorov at., ktor bud vyadova
zmenu
Testovanie novch funkci, ako naprklad softvrovch aktualizci, revidovanch procedr v

prostred oddelenom od produknho ako aj vvojovho prostredia
Uistenie sa, e dokumentcia a pouvatesk procedry s poda potreby revidovan a e

star dokumentcia je archivovan alebo vyraden
Udrovanie kontroly verzi pre vetky aktualizcie
Uistenie sa, e je implementcia zmien vykonan vo vhodnom ase a m minimlny dopad na

svisiace biznis procesy
Dkaz toho, e zmeny napaj vetky bezpenostn poiadavky
Oznmenie podrobnost o zmene vetkm relevantnm osobm
Havarijn postupy, vrtane procedr a zodpovednost pre preruenie implementcie zmeny a

obnovy z nespench zmien a nepredvdanch udalost
Na tomto procese by sa malo od prvch fz podiea tie oddelenie bezpenosti, alebo

zamestnanci plniaci jeho rolu v rmci IT oddelenia kvli posdeniu toho, i je zmena v slade
s bezpenostnmi politikami.
Cieom celho procesu je predovetkm to, aby sa zmeny v infratruktre diali kontrolovanm
spsobom, aby vaka nim dolo k elimincii problmov a chb, ktor zniuj stabilitu
informanch systmov a IKT prostredia.
Na to, aby sme zabezpeili tieto ciele, je potrebn:
v prostred, kde je nevyhnutn vysok dostupnos zabezpei dostaton redundanciu,
komunikova zmeny pouvateom napriek tomu, e mal zmeny sa mu zda vznamn

iba pre mal as pouvateov, me sa sta, e zasiahnu ir okruh pouvateov, je preto
dleit zvi notifikciu irokho okruhu pouvateov, aby mali as sa pripravi na
prpadn vpadok,
vypracova analzu zmien a prezentova hlavn vhody a rizik z nej

vyplvajcich. Poskytnutie riadnej dokumentcie tejto zmeny je dobrm (aj ke nie jedinm)
predpokladom pre predchdzanie kritickm incidentom. Analza popisuje mysel pvodcu
159
poadovanej zmeny a je dleit kvli predchdzaniu implementcie zbytonch, alebo

kodlivch zmien,
redukova dopad zmien na dostupnos poskytovanej sluby sluby IKT a informanch

systmov musia by dostupn, ke ich organizcia potrebuje. Nesprvne posdenie zmien,
chybn implementcie zmien a neadekvtna prprava patr k najastejm chybm, ktor nie
s v tomto procese iaduce. Dobre truktrovan procesy riadenia zmien zamedzuj
problmom a umouj nepretrit beh poskytovanej sluby.
Zavedenie veobecne platnch zsad poskytuje dobr podporu politiky riadenia zmien. Tieto
procesy by mali prinajmenom definova kroky, ktor mus podstpi kad, kto implementuje
zmenu vybavenia podpornej infratruktry:
uvedenie a prezentcia zmeny - zmenov poiadavky musia by prezentovan tm, ktor

bud ma na starosti cel kontrolu vykonvania zmeny s podliehajcimi krokmi. Po otvoren
zmenovej poiadavky je potrebn postupne schvli vetky tieto podliehajce kroky ete pred
plnovanm implementanho harmonogramu. Osoba, ktor schvauje nesmie by toton
s osobou, ktor zmenu vyiadala (segregcia prvomoc),
zaznamenanie zmeny do zmenovho logovho zznamu (change log), ktor poskytuje

dokumentciu samotnej zmeny (okrem inho tie popis asovho harmonogramu a testovanie
zmeny). Tento zmenov logov zznam by mal by aktualizovan v priebehu procesov
schvaovania, plnovania a implementcie zmeny,
asov rozvrhnutie zmeny po uskutonen dkladnej prpravy a zhodnotenia dopadov

zmeny z asovho hadiska by mal by naplnovan proces implementcie. as
implementcie by mal by zvolen tak, aby mali osoby zodpovedn za odshlasenie zmeny
dostatok asu na posdenie zmeny. Pri diskusii s osobami zodpovednmi za posudzovanie
zmien by mali by prediskutovan vetky mon dopady implementovanej zmeny. Ak djde
k dohode na tom, e je mon pristpi k implementcii, je vloen do harmonogramu
plnovanch zmien a oznaen za odshlasen. Vetky odshlasen aj neodshlasen zmeny
by mali by komunikovan psomnou formou s riadnym popisom dvodov.
implementovanie zmien poslednm krokom v zmenovom procese je aplikovanie zmien na

hardvrov a softvrov asti IKT. Ak zmena funguje poda plnu, je vhodn to zapsa do
zmenovej poiadavky a formlne ju uzavrie. Ak zmena nefunguje poda oakvan je
potrebn zozbiera prslun informcie o dvodoch nefunknosti, zapsa ich do zmenovej
poiadavky a uskutoni opatrenia na npravu. Tto informcia sa d neskr vyui pri
analze vzniknutej situcie a je mon pomocou nej zabrni vskytu rovnakho problmu.
V prpade, e by ani po pokuse o npravu nedolo k spenej implementcii zmenovej
poiadavky mala by by vyhotoven sprva. Tto sprva spravidla obsahuje informciu
o tom, ako by nespen zmena mohla ovplyvni prostredie, alebo ak alternatvna metda je
pouit na obnovu prevdzky pokia nedjde k nprave vzniknutho stavu,
hlsenie nasadench zmien manamentu dkladn sprva sumarizujca informcie

o zmenovom procese by mal by periodicky poskytovan manamentu. To zabezpeuje, e
manament si je vedom toho, ak problmy s kvalitou sluby mohli eventulne vznikn
a m monos adekvtne reagova, napr. zmenou v plnovan a stratgii.
Tieto kroky by mali by riadne zdokumentovan a oznmen relevantnm stranm zapojenm

v zmenovom procese. Potom, o djde k spusteniu konkrtneho zmenovho procesu, mala by by
k nemu pridelen osoba zodpovedn za jeho dkladn riadenie a svisiacu agendu.
V prpade nesprvneho procesu zmenovho manamentu by mohlo djs k bezpenostnm
incidentom, nikom dt a narueniu funknosti existujcej infratruktry. Hlavn oblasti riadenia
zmien zahaj kontrolu nad zmenovmi procesmi hardvru, telekomunikanch zariaden,
systmovho softvru, vetkej dokumentcie a procedr svisiacich s prevdzkou, podporou
a drbou beiacich systmov.
160
Kad pripravovan zmena by mala podlieha tzv. UAT (User acceptance testing), teda procesu
testovania a zskania sptnej vzby od pouvateov. Odbornk na konkrtny testovan systm
(vlastnk, alebo pouvate sa v tejto svislosti nazva Subject matter expert, skrtene SME)
skontroluje implementovan zmenu z pouvateskho pohadu a pod sprvu o tom, i je
funkn zmena v slade so stanovenmi poiadavkami. Vo vvoji softvru je takto testovanie
jednou z poslednch fz projektu a vinou sa realizuje predtm, ne zkaznk prjme nov
systm. Pokia systm funguje sprvne poas UAT, je vemi pravdepodobn, e bude vyhovova
a stabilne plni svoju funkciu aj v produkcii. Tieto pouvatesk testy sa vinou nezaoberaj
gramatickmi, kozmetickmi chybami v pouvateskom rozhran, dokonca ani vraznmi
chybami, akmi je softvrov nestabilita. Tieto chyby s odstraovan v skorch fzach
testovania. Podmienky tohto druhu testovania s asto zahrnut v zmluve s dodvateom.
Pri testovan mus by zabezpeen oddelenie vvojovho, testovacieho a produknho
prostredia.
Segregcia prvomoc pri takomto oddelen spova v rozdelen kadej z funkci vvoja,
testovania a prevdzky delegovanm osobm, ktor s zaraden do prslunch rol v procese,
prpadne je vhodn oddeli povinnosti a aplikova konkrtne roly medzi existujcich
zamestnancov, ale vdy tak, aby boli v konkrtnej roli nestrann. Cieom je zamedzi skreslenm
vsledkom testovania spsobench neobjektvnym pohadom zainteresovanch strn. Naprklad
programtor, ktor sa dlho venuje jednej oblasti me potrebova pohad nezainteresovanej
strany, ktor m od problmu odstup, aby identifikoval prinu problmu.
Pre vedenie zznamov o systmoch, prevdzke a zmench sa pouvaj automatizovan
informan systmy. Vinou sa v om zaznamenvaj daje relevantn k nprave incidentov,
teda naprklad v prpade evidencie technickch detailov hardvru s to informcie o fyzickom
umiestnen servera v datacentre, daje o spsobe pripojenia ku konzole kvli drbe,
o operanch systmoch a o biznis vlastnkoch sluieb beiacich na tchto operanch systmoch
(napr. aj kvli ich upozorneniu na pripravovan vpadok).
Prprava drbovch prc mus zaha vyhradenie asovho okna urenho na drbu. Jeho
sprvne naasovanie je kritick pre spoahlivos sluby, pretoe drba asto svis s doasnm
jej vpadkom. Pokia vykonvame drbu systmu, ktor pouvaj tisce pouvateov,
nememe si dovoli vpadok poas najsilnejej dennej prevdzky, preto sa s ohadom na
majoritn as pouvateov vinou vpadok naasuje na hodiny nonej prevdzky, oznmi sa
vetkm pouvateom, prpadne sa im oznamuje monos pouitia alternatvnej sluby.
Manament riadenia zmien vydva tie operan intrukcie zohadujce prpady, kedy slubu
nie je mon po zsahu obnovi. V takchto prpadoch sa uplatuje tzv. rollback, teda
urchlen vrtenie systmu do pvodnho stavu a vol sa nhradn rozvrh implementcie zmien.
Konverzia dtovch formtov pri importe a exporte dt medzi systmami sa deje obyajne tie
v ase mimo hlavnej prevdzky a je uiton zohadova tie krzov prpady, kedy sa import
neukon korektne, prpadne ak celkom zlyh.
Centralizovan databza konfigurci pregeneruje individulne nastavenia a nakopruje ich na
jednotliv prvky infratruktry, prpadne ich ulo do centrlneho loiska dt. Konverzia
systmov (napr. pokia prde k nahradeniu zastaranho systmu novm) sa vo veobecnosti riadi
tandardami zmenovho manamentu popsanom vyie.
asto s na implementciu novch rieen nevyhnutn rozsiahlejie asov okn, ale ak si to
prevdzka vyaduje, systmy sa nastavia u v prpravnch fzach a as vpadku sa tm
minimalizuje.
6.2.5
Nstroje automatizcie manamentu prevdzky
Nstroje integrcie a automatizcie manamentu sluieb prevdzky a kontroly kvality s

v dnenej dobe oraz viac pouvan ako tandard pri riaden zmien a incidentov. Tieto rieenia
podporuj pouvatesk self-support , o znamen, e pouvate si vie vyriei niektor
jednoduch problmy sm bez toho, aby vbec musel kontaktova prv lniu podpory.
161
Benou funkciou s reportovacie funkcie dokumentujce efektivitu sluieb. Vstupn reporty je

mon modifikova poda individulnych potrieb organizcie.
6.3 Vyuitie tretch strn pri dodvke sluieb (outsourcing)

Anglick termn outsourcing znamen dodvku vvoja, implementcie, alebo podpory IKT ako
sluby. Rozsah lovekodn (anglicky MD = man days), potrebnch pre realizciu sluby,
resp. npravu vzniknutho incidentu, je alokovan v zmluvch SLA (Service Level Agreement).
Dodvatesk firma nesie zodpovednos za implementovan zmeny tie v rozsahu urenom
v SLA. Preto je potrebn zmluvy revidova a kvalitu innosti dodvateskej firmy pravidelne
prehodnocova aj v svislosti so strategickm smerovanm organizcie a technologickm
pokrokom. Kad SLA zmluva by mala by pravidelne monitorovan a vyhodnocovan na
pravidelnej bze (v zvislosti na type poskytovanch sluieb, napr. raz za rok).
V SLA by mali by definovan poadovan hodnoty parametrov poskytovanch sluieb (napr.
reakn doby na rzne druhy incidentov, dostupnos systmu) ako aj penalizcie za nenaplnenie
SLA. Dobrou praxou je zahrn do SLA aj motivan ustanovenia, ktor by motivovali
poskytovatea sluby proaktvne prichdza s nvrhmi na ich vylepenie.
Pri vyuvan tretch strn je problematick udrovanie kontroly nad vntornmi mechanizmami.
Ako prklad posli pln vlastnctvo kdu konkrtnej aplikcie a sporn monosti jeho revzie
a internho auditu. K takm situcim me djs v prpade zle nastavenej SLA zmluvy. Pre
bezpen outsourcing je nutn vymedzi prvomoci a segregova ich. Je uiton nastavi biznis
vlastnkov z radov internch zamestnancov a stanovi im mieru zodpovednosti za jednotliv asti
IKT.
6.3.1
Rizik vyuitia tretch strn
Pri vyuvan tretch strn me djs k tomu, e organizcia utrp stratu kvli svojej zvislosti
na dodvateoch, zmluvnch partneroch, alebo externch konzultantoch. Strata me ma za
nsledok znenie rozsahu kovch schopnost, nedostatkom znalost potrebnch na prevdzku,
alebo vysokmi nkladmi na prevdzku vyplvajcimi z neefektvneho poskytovania sluieb
tretmi stranami. V prpade dodvky technickho rieenia existuje tie ako kontrolovaten
riziko zahrnutia zadnch vrtok do prevdzkovanho, udrovanho a vyvjanho rieenia
(informanho systmu, operanch systmov, sieovch zariaden).
alej bezpenostn problmy spojen s nedostatonou segregciou prvomoc, sa zvykn v praxi
prejavi vznikom takej situcie, v ktorej m dodvate pln kontrolu nad vvojom, nasadzovanm
a auditovanm dodvanho rieenia a je teoreticky schopn manipulova zznamy v prpade
kritickho incidentu a tm vznamne sai forenzn analzu v prpade incidentu.
Extern dodvatelia by mali by zmluvne zaviazan umoni zamestnancom odberatea
(organizcia) vykona audit relevantnch systmov dodvatea pre jeho uistenie sa o dodriavan
bezpenostnch poiadaviek odberatea. Alternatvou me by povinnos dodvatea umoni
vykonanie takho auditu nezvislou treou stranou s tm, e auditn sprva bude poskytnut
odberateovi.
6.4 Ochrana proti kodlivmu kdu

Malware (skratka z anglickho malicious software) je veobecn oznaenie kodlivho softvru.
Medzi malware patria:
potaov ervy, ktor vyuvaj internetov pripojenie potaa na svoje vlastn renie
a sekundrne mu spsobova obmedzenie funknosti potaa, intalciu zadnch vrtok
162
(anglicky backdoor), alebo modifikciu sborov na potai. Ich rozdiel oproti vrusom je,
e spravidla neinfikuj spustiten sbory,
trjske kone, ktor mu existova latentn na operanom systme, prejavi sa iba za

uritch podmienok a spsobi pouvateovi kodu,
spyware, ktor sa bez vedomia uvatea poka vypehova citliv dta (akmi s napr.
hesl),
phishingov e-maily, ktor svojm obsahom zavdzaj uvatea a mu ho napr.

presmerova na dveryhodne vyzerajcu strnku, na ktorej od neho pod rznymi zmienkami
vyaduj napr. zadanie hesla,
hoax, poplan sprvy, ktorch tvrdenia sa nezakladaj na objektvnej pravde a vyzvaj

pouvatea, aby ich poslal alej,
adware, produkty zneprjemujce prcu s potaom zobrazovanm reklamy,
exploity, kodliv kdy, ktor vyuvaj programtorsk chybu, zranitenos konkrtneho

produktu,
hackersk nstroje na zahladzovanie stp po toku, skenovanie siet,
nebezpenmi pre skromie s tie tzv. tracking cookies, ktor podvaj tonkovi
informciu o innosti uvatea (naprklad informcie o navtvench strnkach).
Rizik vyplvajce z vskytu tchto druhov kodlivho softvru je mon minimalizova,

prpadne plne eliminova pouitm rznych typov bezpenostnch produktov v kategrii antimalware, medzi ktor patria:
Antivrusov softvry,
Veobecnejie anti-malware softvry,
Anti-intrusion rieenia,
End-point security rieenia vo forme softvrov na kontrolu vynanch dt,
Anti-exploit nstroje nstroje pre zvenie bezpenosti systmovho jadra, ktor

implementuj riadenie rol, zabezpeuj systmov hardening, prevenciu spania
nebezpenho kdu, ochranu zsobnka a in. Za vetky spomeme Grsec, Sandboxy, Nonexec stack patche, AppArmor alebo priamo produkty, ktor tieto nstroje kombinuj.
Mon hrozby vyplvajce z innosti malware na systme zahaj:
zskanie citlivch dokumentov (dajov) malware me nepozorovan odosiela tonkom

vybran typy dajov na vzdialen adresu,
zskanie neautorizovanho vzdialenho prstupu pomocou zadnch vrtok,
znienie/modifikcia pouvateskch, alebo systmovch dt.
Mon kanly distribcie kodlivho softvru, pri ktorch treba dodriava prsne bezpenostn
pravidl:
emailov komunikcia neotvranie emailovch prloh vrazne zniuje riziko infikovania,
prehliadanie internetovch strnok nenavtevova potencilne nebezpen strnky, ktor

ponkaj neleglne sahovanie softvru, hudby a filmov.
upload dokumentov (napr. FTP, SSH, HTTP) nesprvne nastavenie prstupovch prv,
alebo zraniten verzia dmona me vystavi systm narueniu,
163
fyzick prstup k PC (napr. USB, CD, HDD) tonk, ktor m priamy prstup k hardvru,
me pri pripojen cudzch mdi do systmu aktivova program obsahujci malware,
pripojenie na sie (napr. WiFi) samotn prstup na neznmu bezdrtov sie poskytuje
tonkovi priestor pre kompromitciu pripojenho PC.
6.4.1
Ochrana proti phishingu
Jednm z typov kodlivho obsahu, ktor je smerovan na organizcie a pouvateov vo

veobecnosti je pecilne skontruovan phishingov e-mail (anglicky phishing email). Takto
e-mail, ktor sa adresou odosielatea a svojm obsahom poka uvies pouvatea do omylu, e
pochdza z dveryhodnho zdroja asto vyzva pouvatea k vykonaniu uritch konov alebo
poskytnutiu informci, ktor nsledne zneuije. Hromadn zasielanie takchto e-mailov
oznaujeme anglickm termnom phishing. Email so kodlivm obsahom je do naej schrnky
doruen zo zdanlivo dveryhodnej adresy a linka v om me okrem inho navdza na strnku
s falonm autentifikanm formulrom. Tento formulr vyzva pouvatea ku zadaniu mena
a hesla na niektor zo znmych webovch, alebo mailovch sluieb. tonk tak pri spenom
pokuse zskava monos tieto autentifikan daje zneui pri alch tokoch socilneho
ininierstva. Strnka me v nemenej astch prpadoch odkazova na strnku so kodlivm
obsahom, ktor naprklad vyuva zatia neopraven chyby prehliadaa (tzv. Zero day)
a spsob viditen, alebo skryt kompromitciu napadnutho potaa. Takto emaily by mali
by vyfiltrovan spamovm filtrom na rovni mailovho servera organizcie, ale aj napriek tomu
obas dochdza k infiltrcii pouvateskch schrnok.
Najlepou ochranou je v tomto prpade zakolenie personlu ohadom pouvanch tonch
technk a dvodov, preo by mali tieto emaily ignorova. Problmom je, e podobn toky
pracuj s udskmi emciami a tie sa vedia tvri ako legitmna vntro firemn komunikcia,
preto sa stle objavuj v tatisticky vznamnej miere a dosahuj vysok percento spenosti.
6.4.2
Ochrana proti vrusom
Vrus je kodliv program, ktor sa doke sm ri bez vedomia pouvatea. Aby sa mohol
rozmnoova, vklad kpie svojho kdu do inch spustitench sborov a dokumentov. Existuje
mnostvo spsobov, ako sa mu potae infikova cez rzne druhy pamovch mdi
a prostrednctvom Internetu a emailovej komunikcie. Vrusy mu spsobi spomalenie
a nestabilitu systmu, alebo pokodenie dt. Pri niektorch vrusoch sa kodliv kd spa a
s oneskorenm a pri uritch podmienkach, napr. v urit de, alebo po nakazen uritho potu
ostatnch systmov. renie vrusov spsobuje zaaenie sieovch liniek a inch zdrojov
(procesor, pam, diskov priestor at.).
Modern komplexn antivrusov rieenia, tzv. antivrusov systmy chrnia pouvateov aj
pred tmito a mnohmi inmi hrozbami poskytnutm rozrench funkci. Medzi tieto funkcie
patr:
odstraovanie spamu,
funkcia firewallu,
prieben skenovanie emailov a sborovho systmu,
kontrola integrity dt,
plnova akci, ktor vo vybranch termnoch vykonva konkrtnu innos,
karantna, ktor zabezpeuje izolciu infikovanch sborov.
Antivrusov systmy s zavdzan nielen na pracovnch staniciach, ale napr. aj na mailovch

serveroch. Priebene kontroluj nielen sbory na klientskych potaoch, ale aj sbory preberan
sluobnm emailom. Databzy signatr antivrusovho softvru s pravidelne aktualizovan proti
centrlnemu firemnmu repozitru.
164
Antivrusov systmy sam o sebe nestaia, nevyhnutn s tie sprvne nastavenia operanho
systmu ohadne kontroly prstupu k administrtorskm zdrojom, ktor by mali by benmu
pouvateovi odopren (za vetky menujme intalciu novho softvru, prava registrov, at.).
6.4.3
pecifick hrozby svisiace s pouvanm mobilnch zariaden a vzdialenou

prcou a opatrenia proti nim
Zariadenia, ktor nie s organizciou pridelenmi pracovnmi stanicami, ale s v skromnom

vlastnctve pouvatea (inteligentn telefny, skromn laptopy, at.) sa v sluobnch
priestoroch vyskytuj oraz viac. Je preto nutn ich pouvanie a predovetkm pripojenie
k sieovo prstupnm zdrojom kontrolova.
Na tento el mu sli zariadenia ako naprklad tzv. Antisniffer, ktor deteguje takto
zariadenia, klasifikuje ich ako neautorizovan a nemus im povoli pripojenie k sieti. Stle viac
zamestnancov vak chce pristupova z tchto zariaden do siete. Ich zkaz s ohadom na
technologick trendy tabletov a inteligentnch telefnov nemus by prve strategickm
a dlhodobo udratenm rieenm.
V takchto prpadoch je vhodn nasadenie ifrovania prenanch dt pomocou virtulnych
privtnych siet (VPN) a vyuitie ifrovania dt ukladanch na skromn hardvr.
6.5 Bezpenostn incidenty, zodpovednos za ich nahlasovanie a

rieenie
Bezpenostnm incidentom rozumieme udalos, ktor m potencilne negatvny dopad na
prevdzku a chrnen aktva. Je zodpovednosou organizcie kategorizova udalosti, ktor by
mali by posudzovan ako incidenty a monitorova ich vskyt a riei ich. Ich vskyt by mal
spa proces eskalcie rieenia incidentu na relevantn osoby a v svislosti s nm by mali
by podniknut systematick kroky pre bezprostredn rieenie incidentu.
Prkladom incidentu je:
nespen pokus o prihlsenie sa do systmu,
preniknutie tonka do systmu,
odopretie sluby (anglicky Denial of service, DoS), prpadne pecilny typ distribuovanho
odopretia sluby, kedy je tok realizovan z mnohch IP adries (Distributed DoS, DDoS),
take je aia jeho prevencia,
prtomnos kodlivho kdu,
zatopenie IKT vodou z prasknutho potrubia,
zahltenie loklnej siete nesprvne nakonfigurovanm sieovm zariadenm,
zlyhanie aplikcie kvli chybe v kde aplikcie,
pokodenie/krde komponentov IKT.
Spsoby pouit pri realizcii tokov zahaj112:
napadnutie samotnej aplikcie a zneuitie jej zranitenost,
pouitie technk socilneho ininierstva, alebo naintalovania kodlivho kdu na konkrtne

pracovn stanice (odchytvanie stlaench klves, odpovanie, snmanie obrazu) kvli
zskaniu cennch informci,
tento zoznam je len ilustratvny, pretoe sa kad de objavuj nov zranitenosti IKT umoujce
nov metdy tokov.
112
165
priame zneuitie privilegovanho prstupu inch pouvateov systmu, opertorov, alebo

administrtorov,
pouitie slovnkovch tokov na slab hesl v informanom systme a nsledn eskalcia

privilgi,
nsiln iny vlmania, vydierania a krdee pre zskanie prstupu k inkriminovanmu

systmu, alebo jeho dtam.
Incident sa me v IKT prostred prejavova:
plnou nefunknosou systmu hardvrov komponent, alebo informan systm

nereaguje, alebo nie je prstupn,
zmenenm obsahom webovej strnky pvodn obsah webovej strnky bol zmenen kvli
chybe v systme, alebo myselne prepsan tonkom,
neobvyklou sieovou aktivitou daj sa pozorova urit anomlie oproti tandardnej

prevdzke, nezodpovedajca frekvencia innost pouvateov, alebo podozriv druhy
innost,
neobvyklou zaou systmu - vek preaenia systmu, ktor ved k odopretiu dostupnosti
sluby,
podozrivmi zznamami v logoch ak auditn zznamy nie s konzistentn so skutonm

sprvanm systmu, ned sa vyli riziko, e systm je skompromitovan a tonk tieto
auditn zznamy pozmenil.
Fzy rieenia bezpenostnch incidentov:
kategorizcia vzniknutch udalost (eventov) - pri rieen bezpenostnch incidentov sa

bez ohadu na pouit metodolgiu zana triedenm vzniknutch incidentov poda ich
zvanosti posdenm ich dopadu na IKT infratruktru. Zatriedenie je v praxi realizovan
automatizovanmi nstrojmi manamentu bezpenostnch udalost a incidentov (Security
incident and event management, SIEM), o ktorch sa zmieujeme v inej asti tejto
publikcie.
detekcia potencilnych incidentov vyuitm informci z predchdzajcej fzy sa v tomto

kroku zisuje, nakoko pravdepodobn je, e konkrtna udalos by mohla ma dopad na
komponenty IKT,
obnova benej prevdzky po uzavret incidentu obvykle dochdza k fze obnovy

prevdzky (ale nie nutne). Nvrhy opatren na obnovu tandardnej prevdzky s
formalizovan v rmci plnovania kontinuity innost (Business Continuity Managment BCM) a plnu obnovy po havrii (Disaster Recovery Planning - DRP). Pln obnovy po
havrii v psomnej forme definuje procedry, ktor m organizcia podnikn pred, poas
a po vzniku havrie na obnovu tandardnho stavu. Tto havria me ma prrodn
charakter (prrodn katastrofa), alebo to me by dsledok udskej innosti (myselnej,
alebo nemyselnej). Plny zahaj podrobnosti postupov obnovy dleitch dt,
informanch aktv a prevdzky ako celku.
zhodnotenie spenosti metodiky rieenia incidentov, spenosti obnovy pvodnej kvality

sluieb a prpadn prava metodolgie rieenia bezpenostnch incidentov s ohadom na
zmenu podmienok a situcie. Cieom zhodnotenia spenosti je uri vhodn prstupy k
rieeniu vzniknutch incidentov. Tto fza me zaha intern, alebo extern audit a s nm
svisiacu optimalizciu procesov v organizcii pomocou tdia dostupnej dokumentcie,
rozhovorov s personlom a ohodnotenm kvality pouitej technolgie.
Intern dokumentcia by mala by aktualizovan za prevdzky a mala by obsahova daje o tom,

ak npravn opatrenia boli podniknut a kto ich vykonal.
166
Na doplnenie dokumentcie je mon vyui nstroje sprvy riadenia zmien, tzv. service desk,
alebo helpdesk nstrojmi (konkrtnym takm rieenm je napr. HP ITSM). Kvli prevencii
problmov s nedostatkom znalost spsobench odchodom zamestnancov s dleitmi
znalosami sa zavdzaj systmy sprvy vedomostnej a znalostnej bzy (knowledge base
systmy).
Dokumentcia existujcej infratruktry by mala zaha:
topolgiu siete,
podrobnosti o konfigurcii serverov a sieovch zariaden vrtane bezpenostnch nastaven,
nastavenia pracovnch stanc,
kontakty na zodpovedn osoby.
udia, ktor spravuj IKT by mali ma technick spsobilos a mali by by v prpade incidentu
schopn citlivo zasiahnu v krtkom asovom intervale. Zodpovednos za rieenie
bezpenostnch incidentov je pridelen bezpenostnmu manarovi (anglicky security
officer), alebo zamestnancovi oddelenia IT v prslunej roli.
Typicky sa opakovanie incidentov d zvrti:
zmenou konfigurcie operanho systmu, resp. aktualizciou operanho systmu.

Zniovanie pravdepodobnosti opakovania incidentu je mon zariadi pomocou
implementcie politk systmovch, aplikanch a firmvrovch aktualizci, konfiguranho
manamentu a manamentu zranitenost poda tandardov a dobrch praktk (best
practices). Intalcia, drba a aktualizcia informanch systmov by sa mala dia vo
vyhradench asovch oknch, ktor mus by korektne komunikovan pouvateom
a vlastnkom dotknutch systmov.
aktualizciou antivrusovej databzy, alebo databzy IDS/IPS charakteristk (anglicky

nazvanch signatures, ktor s detekovatenmi vzormi tokov, na zklade nich je mon
identifikova a zabrni toku). Systematick nahlasovanie zana priebenm
monitorovanm auditnch zznamov, automatizovanm vyhodnotenm incidentu z IDS/IPS,
alarmom z monitoringu, antivrusovho systmu, alebo inho incidentu postpenho zo
systmu manamentu bezpenostnch udalost a incidentov (SIEM). SIEM analyzuje a
koreluje bezpenostne relevantn udalosti, zatrieuje ich a spja asto zdanlivo nesvisiace
udalosti, aby odhalil potencilne incidenty, eliminuje falon negatvne a falon pozitvne
vsledky. Pokia djde k pozorovaniu netandardnho sprvania na pouvateskej rovni, je
potrebn, aby mali zamestnanci k dispozcii kontaktn informcie na relevantn personl,
ktor vzniknut incident vyetr a podnikne kroky na npravu,
aktualizciou, prpadne eliminciou chb aplikanho softvru tieto innosti musia by

vykonvan odborne zdatnmi vvojrmi a administrtormi (i u z internch zdrojov, alebo
zdrojov dodvatea), ktor s schopn chybu nielen zachyti, ale aj urchlene riei.
truktrovan a systematicky aktualizovan postupy pre nahlasovanie incidentov s jasne
vyhradenmi prvami, povinnosami a zodpovednosami za ich rieenie s dobrm
predpokladom pre predchdzanie kritickm incidentom.
V procese aktualizcie mus by pre prpad jej nespechu umonen obnova do predolej
funknej verzie, tzv. rollback. Medzi najdleitejie vlastnosti rieen centrlneho riadenia
drby operanch systmov patr centrlna sprva aktualizci, selektvna distribcia
aktualizci, ktor sa maj naintalova na konkrtny systm, zlohovanie a monitorovanie
zdravia serverov.
6.5.1.1 Forenzn analza a honeypot/honeynet systmy
Pokia djde k zvanmu napadnutiu systmu a je nutn ho podrobi forenznej analze, je
hlavnm pravidlom zabezpei jeho odpojenie od prevdzky kvli root cause analze - analze
prin incidentu. Takto postup je vak mon iba vtedy, ak je k dispozcii identick zlon
167
systm. itok z analzy prin incidentu na odpojenom systme by mal by v ako kody
spsoben jeho odpojenm.
Oddelenie napadnutho systmu od ostatnch systmov v prevdzke pomha preds aliemu
rozirovaniu nsledkov incidentu, ale v prpade, e m tonk na systme implementovan
kodliv mechanizmus, ktor tak izolciu deteguje a pri takchto snahch naprklad pokod
sborov systm, je mon, e odpojenm spsobme ete viu kodu. Z tohto dvodu je
vhodnejie citlivo izolova ostatn systmy v prevdzke a tm ich ochrni pred nsledkami
kritickch incidentov. V praxi sa asto pouvaj nastren tzv. honeypot systmy, ktor mu
by spojen do siet (honeynet). Tieto simuluj relne produkn systmy kvli zskavaniu
informcii o tonkoch. Mu by neaktualizovan a zraniten voi tokom, prpadne
nakonfigurovan ako ahk koris pre tonka. Pri uskutonen toku vak zaznamenvaj
a zachytvaj vetku tonkovu innos a poskytn svojmu vlastnkovi informcie o
pouvanch technikch, pouitom kodlivom kde a nstrojoch.
6.5.2
Automatizcia detekcie a rieenia bezpenostnch incidentov
Nahlasovanie bezpenostnch incidentov je asto automatizovan vaka rieeniam monitoringu

prevdzky a manamentu bezpenostne relevantnch incidentov (SIEM).
Manament bezpenostnch udalost a incidentov funguje na princpe zbierania auditnch
zznamov do centrlneho servera na analzu prevdzky danej sieovej infratruktry. Tieto dta
s neskr interpretovan v reportoch a poskytnut koncovmu pouvateovi systmu (spravidla
sa jedn o bezpenostnho manara), aby mu uahili prcu pri identifikovan rizk.
Proces innosti systmov SIEM by sa dal schematicky znzorni v nasledovnch krokoch:
zbieranie - prijmanie logov cez protokoly na to uren ako je SNMP (aktvne) a Syslog
(pasvne),
normalizcia - normalizcia logovacch zznamov z rozlinch systmov (rznych

vrobcov, rznych produktov, systmov, zariaden, apod.), normalizcia formtu asovch
dajov a pod.,
obohatenie - pridanie verejne znmeho daju o pouitom exploite, svisiacich informcii o

aktulnom stave siete, vlastnch vsledkoch penetranho testu (znme zranitenosti nho
systmu) at.,
korelcia - zoskupovanie podobnch udalost, priradenie prslunej dleitosti, oznaenie

obzvl zaujmavch udalost a pod.
Systm SIEM redukuje mnostvo informcii, ktor by bezpenostn analytik musel rune
spracovva, zvrazuje abnormlne sprvanie v IT infratruktre a tie redukuje falone
pozitvne, alebo falone negatvne vsledky.
Oddeovanie benej aktivity od nebezpenej sa deje tie formou konsolidcie logovacch riadkov
do vlkien (angl. threadov) a uitonou funkciou je tie ich zapzdrenie do udalost (angl.
eventov). Jednou z mnohch vhod zavedenia SIEM je teda spora nkladov pri prevdzke
rutinnej bezpenostnej analzy a tie minimalizcia monosti zlyhania udskho faktoru v tomto
procese [4].
6.6 Redundancia sieovej infratruktry a zlohovanie dt

Medzi technick metdy ako zabezpei kontinuitu prevdzky komponentov sieovej
infratruktry patr zdvojen napjanie, alebo zlon UPS (zdroj nepreruovanho napjania),
ktor zaistia prsun elektrickej energie v ase vpadku. alm monm opatrenm je
implementcia dvojitej konektivity dtovho centra. Vhodnou praxou je tie dvojit konektivita
168
smerom k vysunutmu loisku zloh, pretoe zabezpe ukladanie zloh aj napriek vpadku
hlavnho sieovho pripojenia.
6.6.1
Klastre s vysokou dostupnosou
Redundancia aplikanch a databzovch serverov sa realizuje pomocou tzv. klastrov s vysokou

dostupnosou (High Availability Clusters - HAC), ktor s schopn distribuova, prpadne
prepna svoju prevdzkov za medzi uzlami. Toto rieenie sa oraz viac pouva pre kritick
aplikcie (e-commerce, banking, VPN rieenia) sa vyuvaj na eliminciu tzv. single-point-offailure, ktorch prtomnos me v prpade incidentu ochromi cel systm a spsobi stratu
renom, alebo inch dleitch zdrojov.
Konfigurcia Active/Active, ktor v prpade vpadku uzla distribuuje za medzi ostatn uzly
klastra. Vyaduje architektonick nvrh s redundantnmi prvkami, ale z dlhodobho hadiska je
vo vine scenrov rentabiln.
Na rozdiel od nej konfigurcia Active/Passive zariadi v prpade vpadku uzla prepnutie na
identick kpiu toho uzla, ktor zlyhal. Udruje teda zrkadlov kpiu beiaceho systmu.
Tento spsob sa nazva tie Hot Spare. Vyaduje vie mnostvo hardvru ako predol
spomnan active/active a to je tie spojen s vymi nkladmi.
Redundanciu je mon implementova aj vo virtualizovanom prostred. Virtulne obrazy
systmov uloen v cloude uahuj a zlacuj implementciu redundantnch klastrovch
rieen. Tto metda sa oraz viac uplatuje v praxi vaka pokroku v technolgich a rastcim
portflim spolonost ponkajcich prenjom cloudovch vpotovch prostred. Tieto
ponkaj tie pokroil cloudov manament v podobe inteligentnho prepnania aktvneho uzla
medzi vetkmi uzlami cloudu. Kad sieov uzol m naintalovan zrkadlov virtulne obrazy,
take koncov pouvate nepocti rozdiel v pouvateskej prstupnosti. Prepnanie sa pri
klastroch s vysokou dostupnosou riadi poda aktulnej zae v konkrtnom regine.
6.6.2
Zlohovanie a obnova
Kee dostupnos dt a schopnos pracova s dtami je kritick pre pouvateov, organizcia

mus ma vypracovan stratgiu zlohovania a postupy pre obnovu dajov zo zloh. Hlavnou
innosou je zlohova kritick systmov a dtov sbory, uloi zlohy na bezpen miesto
mimo pvodnho loiska a uskutoni rchly transfer tchto dt do iadanej lokality v prpade
potreby.
Loklne zlohovanie dt chrni proti zlyhaniu disku a vaka nemu v prevdzke nedochdza (pri
pouit sprvnej konfigurcie) k pokodeniu kritickch dt (daje nevyhnutne potrebn pre chod
organizcie) a ani k ich nedostupnosti. Nechrni vak proti poiaru a inm katastrofm a tie
nezabrauje neautorizovanmu vynaniu zlohovacch psok s dleitmi sbormi. Zlohovanie
dt do geograficky oddelenho miesta by sa preto malo dia na dennej bze. Dleitmi dtami
v tomto kontexte rozumieme pouvatesk dta uloen na serveroch a tie pouvatesk dta
uloen v osobnch potaoch zamestnancov [5].
Pri implementcii zlohovania zvaujeme tri zkladn otzky: ako asto, ak obsah a kam
chceme zlohova. Berieme tie ohad na asov aktulnos zlohovanch dt (napr. pri
navrhovan rotovania logovch zznamov zva nem vznam udriava vetky logy na desa
rokov, pretoe vtedy s u dvno neaktulne, ich archivcia zbytone predra cel rieenie).
Zohadujeme dva parametre, ktor svisia so zvolenm typom zlohovania: as potrebn na
zlohovanie (backup window) a as potrebn na obnovu (data horizon).
6.6.2.1 Pln zlohy
Pri plnom zlohovan sa typicky zlohuj cel disky, resp. partcie diskov, ich systmov aj
dtov asti. Takto rieenie vyaduje (oproti dvom alej vysvetlenm metdam
inkrementlneho a diferencilneho zlohovania) vek mnostvo priestoru.
169
Pln zloha poskytuje najviac redundancie a spravidla najrchlejiu obnovu, teda najkrat data
horizon. Svis to s tm, e dta pri obnove netreba reazi z viacerch inkrementlnych ast,
sta obnovi cel posledn obraz. Tento spsob je dobr ako alternatva k zrkadleniu
(mirroring), o je funkcia poskytovan RAID-ovmi poliami.
6.6.2.2 Inkrementlne zlohy
Inkrementlne zlohy selektvne ukladaj vetky tak sbory, ktor sa zmenili od poslednej
inkrementlnej zlohy. Na obnovu z inkrementlnych zloh je potrebn posledn pln zloha a
reaz vetkch inkrementlnych zloh.
Inkrementlna zloha nie je to ist o diferenn zloha, pretoe nezlohuje vetko, o sa zmenilo
od poslednej plnej zlohy, ale zlohuje iba t as dt, ktor sa zmenili od poslednej
inkrementlnej zlohy.
Technika zloh pomocou snmky pamte tzv. snapshot vrazne urchuje obnovu (za vetky
rieenia spomeme napr. Acronis True Image na klientskch Windows staniciach, zlohy
pomocou nstroja rsnapshot na linuxovch systmoch).
6.6.2.3 Diferenn zlohy
Kad diferenn zloha ulo vetky dta, ktor sa zmenili od poslednej plnej zlohy.
Na ich obnovu je potrebn posledn pln zloha avak oproti inkrementlnemu zlohovaniu
posta posledn diferenn zloha.
Voba frekvencie zlohovania zle od prostredia a druhu dt. Vyuva sa naprklad reim
kompletnej zlohy raz za tde a potom inkrementlnej zlohy raz za noc pre kad produkn
systm.
6.6.3
Diskov polia
Pri zlohovan pecifickch systmov, akmi s vemi vyaen aplikan a databzov servery
sa pouvaj RAID-ov polia so zrkadlenm. Duplicitn kpie dt pre zaistenie redundancie
diskovho priestoru sa asto vyuvaj v produknch prostrediach, kde je dleit zabezpei,
aby pri zlyhan jednho z diskov, bola k dispozcii rchlo dostupn tzv. hot spare zloha. [6]
Niektor zlohovacie aplikcie vyhotovuj kontinulne zlohy sborov, ktor s umiestovan
na sborovch systmoch zlohovacch platforiem. Tieto sbory s veden v databze aj
s informciou o ich lokalite. Po vodnom plnom zlohovan systmu tieto zlohovacie rieenia
vyhotovuj inkrementlne zlohy systmovch sborov na regulrnej bze (v regulrnych
intervaloch).
Ak prde k potrebe obnovi dta, toto rieenie kontinulneho zlohovania doke vyhotovi
obnovu plnej zlohy, alebo obnovi zlohu z konkrtneho dtumu a asu tm, e vygeneruje
zoznam potrebnch sborov z databzy a obnov ich zo zlonho mdia. Tieto typy zloh
minimalizuj vyaenie sieovej prevdzky, as potrebn na obnovu a diskov priestor potrebn
na ukladanie zloh.
Problmom tkajcim sa zlohovania me by neschopnos zlohovacej aplikcie obnovi
obraz zo zlohy kvli tomu, e sbor je pokoden, alebo zlohovacie zariadenie nefunguje
sprvne. alm monm problmom je, e zlohovan systm nie je uloen spolu s tzv. MBR
(master boot record) asou, ktor je v takom prpade nutn obnovi.
V prevdzke je uitonou praxou testovanie sborovho systmu zlonho mdia. Pouit
nstroje sa lia v zvislosti od platformy. Niektor disky maj v sebe implementovan kontroly
vlastnho stavu a vedia signalizova prpadn bliaci sa vpadok.
6.6.4
Ukladanie a ochrana zlonch mdi
Lokalita loiska zlonch mdi a kvalita sieovho prepojenia ovplyvuje rchlos obnovy.
170
Loklne zlohy s sce vemi vhodn pokia ide o as ich obnovy, ale je pri nich riziko
problematickho zotavenia po havrii (poiar, zplavy, ...), ktor s najvou pravdepodobnosou
zasahuje cel geografick okolie pvodn aj zlon lokalitu. [2]
Pri zvenom riziku prrodnch katastrof je potrebn zlohovanie do vysunutch lokalt.
Vysunut lokalita mus by dostatone vzdialen, aby v jej bezprostrednom okol nedolo k tej
istej havrii ako v lokalite, z ktorej zlohujeme.
Pre zlohovanie klasifikovanch informci sa zavdzaj pecilne pravidl, ktor uruj metdu
prenosu dt do loiska (ifrovanie, reim prstupu k loisku), frekvenciu zlohovania a spsob
vyhotovovania zloh (inkrementlne/diferencilne/pln zlohovanie).
6.6.4.1 drba dtovch centier
Vo vysunutej lokalite by mal by k dispozcii pouen personl pripraven zasiahnu v prpade
mimoriadneho vpadku hardvru, alebo jeho ast. Medzi ben innosti patr hardvrov retart
zariadenia, pripojenie novho mdia, vmena pokodenho disku a in kony.
Dleit pre sprvnu prcu zariaden pre ukladanie a ochranu zlonch mdi je tie udrova
prijaten podmienky prostredia (teplota, vlhkos).
Ochrana lokality proti poiaru a povodni me by zabezpeen pomocou pecilnej kontrukcie
budovy, intalciou zariadenia na detekciu poiaru, alarmom, poiarnymi sprchami (tzv.
sprinklermi), ale aj napojenm na pult centralizovanej ochrany.[2]
Napojenie na pult centralizovanej ochrany me by vhodou v prpade mimoriadnych udalost
ako je poiar, alebo vlmanie. Pult centralizovanej ochrany je sluba, ktor poskytuj PZ SR aj
skromn bezpenostn firmy. Ide o vyhodnocovanie alarmov z napojench lokalt. Pri vskyte
neiaducej udalosti je mobilizovan hliadka, prpadne priamo kontaktovan polcia a/alebo
hasii.[2]
Medzi vhodn praktiky patr pravideln obnova do testovacieho prostredia a otestovanie integrity
dt. Vinou sa jedn o obnovu zlonho obrazu do virtulneho prostredia. Nasleduje
otestovanie zkladnej funkcionality informanho systmu, ktor dta vyuva a ak s stanoven
podmienky splnen, zloha aj obnova prebehla v poriadku.[2]
6.7 Prenos a vmena informci

Pri narban s citlivmi dtami je dleit dodrova politiky a postupy pre kontrolovan prenos
a vmenu informci. Dleitou informciou, ktorej distribcia by mala by limitovan s
pouvatesk a administrtorsk hesl. Jednm zo zkladnch pravidiel administrtorov, ale aj
pouvateov systmov je nepsa hesl na papier, neuvdza ich v dokumentcii a neri ich
stnym podanm. Idelne je, ak kad pouvate systmu m svoje vlastn meno a heslo
a obmedzen prstup len k uritm zdrojom. V prpade, e si vyiada eskalciu privilgi a spa
vopred stanoven kritria, dostane privilegovan prstup. Takmto spsobom nedjde k strate
informcie o tom, kto spsobil zmeny v konkrtnom systme a nedochdza k problmom pri
vyvoden zodpovednosti za potencilny incident.
Existuj a v praxi sa vyuvaj aj rieenia centrlnej databzy hesiel, ale vyvodenie
zodpovednosti za vzniknut incident je pri nich problematick, zaha pouitie relatvne
zloitch a drahch metd na zistenie jeho pvodcu (porovnvanie logovch zznamov
z rznych systmov, eventulne forenzn analza).
ifrovanie emailov je prnosn pre zabezpeenie dvernosti informci, ale v oddelench
firemnch sieach sa asto z pragmatickch dvodov neimplementuje. Existuj rieenia
implementujce S/MIME tandard, alebo ifrovacie aplikcie implementujce algoritmus PGP.
Podobne je to s elektronickm podpisom v benej emailovej komunikcii. Takto pecilne
rieenia maj svoje technick obmedzenia, naprklad implementcia do existujceho mailovho
171
klienta, pouitie pri webovch emailovch slubch, nekompatibilita klientov. ifrovanie

emailov na celej ceste od adresta po prijmatea (end-to-end) tie poskytuje priestor pre
infiltrciu infratruktry kodlivm kdom.
Vedenie zznamov o aktvach s citlivmi informciami je reimovm opatrenm, ktor pomha
udrova potrebn prehad o tom, kto m ak aktvum k dispozcii. Podobnm reimovm
opatrenm je aj oznaovanie mdi. Najastejie sa mdium oznauje dtumom vytvorenia mdia,
dtumom, kedy by malo by mdium znien, menami prenanch sborov, ich verziou
a stupom klasifikcie prenanch dt. [2]
V prpade prenania a ukladania citlivch dajov je nutn pouitie zodpovedajcej fyzickej
ochrany a tie je nutn zabezpei vykolen personl na ich sprvu. Pri dodrovan organizciou
stanovench politk a postupov pre prenos a vmenu informci je mon implementova
nstroje vyuvajce schmy zdieanho tajomstva. V takchto schmach je pre prstup k
utajovanej skutonosti potrebn k od viacerch dveryhodnch osb (nie nutne vdy tch
istch). Implementciu takejto schmy njdeme napr. v komernom produkte PGP. Na
unixovch a linuxovch systmoch s na to k dispozcii naprklad nstroje ssss a gfshare.
Prkladom pouitia je situcia, v ktorej riadite banky chce, aby dleit obsah bol prstupn aj
v prpade jeho neprtomnosti, ale iba vtedy, ak sa spoj dostaton mnostvo (konkrtne
urench) zamestnancov.
Ochrana informci pri vmene elektronickmi prostriedkami prenosu zaha postupy pri ktorch
sa prenan dta kontroluj pomocou nstrojov kontroly integrity. Vyuvaj haovacie funkcie,
vstup z ktorch sa po prenose porovnva s pvodnou hodnotou vstupu tejto haovacej funkcie
pred prenosom. Ak sa tieto hodnoty zhoduj, nedolo k pokodeniu integrity prenanch dajov
a me sa pokraova so spracovanm. Aby sme znili riziko toho, e tonk napr. poas
prenosu vykon zmenu v prenanch dajoch a vymen haovaciu hodnotu dokumentu za nov
vypotan zo zmenench dajov je nutn, aby haovacia hodnota bola doruen adrestovi
inm komunikanm kanlom. Ak si naprklad adrest uveden dokument stiahol z web strnky,
haovacia hodnota mu me by doruen napr. e-mailom.
Nstroje na kontrolu integrity ponkaj monos vyui viacero rozdielnych haovacch funkci
pre rzne typy dt. Testovanie sprvnosti sekvencie dt sa v softvri pre kontrolu integrity
realizuje zaznamenvanm sekvennho sla kvli overeniu prijmanch a spracovanch ast.
Vedenie zznamov o prijatch dtach zahaj informcie o tom o bolo prenan, dtum a as
kedy to bolo prenan, pvod, typ a formt dt. Kontrola a oprava chb sa deje v relnom ase
vaka samo opravnmu kdovaniu. Realizuje sa tie logovanie chb v prenose a chyby sa
klasifikuj poda chybovho kdu. V prpade, ak nie je mon opravi chybu je mon vyntenie
opakovanho prenosu.
6.7.1
Narbanie s pamovmi mdiami
K zvenej pouvateskej bezpenosti prispieva tie riadenie prstupu k prenosnm dtovm

nosiom, ktorho implementcia je zvisl od prsnosti bezpenostnej politiky v konkrtnej
organizcii. Hrozby vznikajce pri pouit napr. USB kov, pamovch kariet a inch
dtovch nosiov zahaj infikovanie IKT vrusmi, kodlivm softvrom, ale tie dtov niky,
trval straty, alebo pokodenia dt.
Dsledky nekontrolovanho pouitia dtovch nosiov mu by rzne, od nepovolenho
intalovania softvrov typu backdoor (zadn vrtka), ktor tonkovi umonia neautorizovan
prstup k serveru, alebo pracovnej stanici pouvatea, cez nebezpeenstv intalcie
softvrovch nstrojov na zaznamenvanie stlaench klves, ktor mu uklada vetky
informcie vloen do klvesnice, vrtane mien a hesiel a odosiela ich von. Problmovmi s
tie dtov niky (vynanie informci mimo chrnen priestor organizcie a pod.).
Jednou z metd ochrany proti tmto hrozbm je nasadenie softvru na prevenciu straty dt (Data
Loss Prevention), ifrovanie dtovch nosiov, vzdelvanie personlu, zamykanie obrazovky tak,
aby nedolo k zneuitiu odomknutho potaa, bezpen mazanie u nepotrebnch dt a vedenie
protokolu o vrten aktv.
172
6.7.1.1 Bezpen mazanie dt a skartcia pamovch mdi

Bezpen mazanie dt z neifrovanch dtovch nosiov je jednou z uitonch technk pri
odovzdvan neifrovanho pamovho mdia novmu majiteovi (pri deden hardvrovej
vbavy). Spova v prepsan relevantnch partci mdia nhodnmi, prpadne nulovmi
dtami tak, aby nebolo mon tieto dta obnovi. Metdy sanitizcie pamovch mdi popisuje
napr. tandard NIST SP 800-88.
Toto snaenie je asovo nron a nemus by vdy spen: pri pokroilch forenznch
technikch za pouitia drahch prstrojov je mon dta obnovi aj z prekvapujco
nekonzistentnch dt.
Pri klasifikovanch a kritickch dtach nemus by bezpen mazanie povaovan za dostaton
a niekedy je nutn pristpi ku skartcii pamovch mdi. Fyzick nienie dtovch nosiov
patr medzi archivan a registratrne poiadavky pri spracovan citlivch dt vyadovan napr.
zkonom 395/2002 Z.z. Slia na pecilne zariadenia, ktorch efektivita je certifikovan poda
noriem STN EN ISO 9001:2001 / 14001:2005. Skartovacie stroje sa delia poda stupa
klasifikcie utajovanch skutonost a maj nastaviten reim rovne skartovania, od ktorho sa
odvja as potrebn na skartovanie nosia.
Na stanovenie citlivosti dajov a potrebnej rovne skartcie sa pouva norma DIN 32757-1 s
niekokmi stupami. Stupe 1 m najniie utajenie, stupe 6 najvyie. Ben skartovacie
stroje skartuj na stupe utajenia 2, o postauje potrebm bench uvateov. Stupe utajenia 3
m u tak vstupy, e benmi prostriedkami nie je mon skartovan materil zostavi do
itatenej podoby. Pre potreby vysokho zabezpeenia sli stupe utajenia . 4, ktor me by
iastone zostaviten len s pouitm pikovch technolgi. Stupe . 5 je stopercentne
nezostaviten. m je vy stupe utajenia, tm menej papierov, alebo dtovch nosiov je
mon na jedenkrt skartova.
Pri fyzickom transporte pamovch mdi berieme do vahy ich klasifikciu, mnostvo
prenanch dt a ich asov aktulnos. Poda tchto kritri volme konkrtne bezpenostn
opatrenia. Pri aplikovan pravidiel bezpenho transportu sa nezameriavame iba na pamov
mdia USB a digitlne daje uloen na nich, ale aj na papierov dokumenty, CD, DVD a
magnetick mdi ako s naprklad zlohovacie psky.
Hrozby vyplvajce z neautorizovanho pouitia tchto dt zahaj neautorizovan zneuitie
tlav, peanch zdrojov, dtov niky a pokia sa jedn o dokumenty obsahujce osobn daje
tie riziko potencilneho kradnutia identity.
6.7.2
Pouvanie mobilnch zariaden a vzdialen prca
Pouvanie mobilnch zariaden a nstrojov pre vzdialen prcu je u v sasnosti nevyhnutn,

ale zrove vytvra priestor pre pecifick rizik svisiace s ich pouvanm. Na prevenciu rizk
spojench s pouvanm cudzch zariaden v prostred organizcie, ktor m by chrnen sli
odchytvanie (sniffing) podozrivch vzorov v sieovej komunikcii pomocou IDS/IPS
systmov. Zabezpeuje detekciu pre vrusy, spam, sahovanie vekho objemu dt, toky DDOS
a in aktvne toky. Problmom je, e potencilne kodliv prevdzka je vak asto zapuzdren v
ifrovanom prde dt a teda ako rozpoznaten (aj technikami deep packet inspection).
ifrovan komunikcia medzi VPN uzlami toti zabrauje efektvnej detekcii kybernetickch
tokov a vaka VPN tonk zskava prstup ku vetkm zdrojom, o mu poskytuje idelne
podmienky na prenos kodlivho kdu do vntra infratruktry. alm problmom me by
pasvne odpovanie sieovej prevdzky, ktor nie je ahko detekovaten.
6.7.2.1 Virtulne privtne siete VPN
Typicky sa jedn o virtulne privtne siete zaloen na protokole SSL/TLS alebo na protokole
IPSEC. Po dvojfaktorovej autentifikcii sa otvor ifrovan tunel medzi dvoma uzlami (end-toend), v ktorom sa prenaj dta. Pri vyuvan nstrojov vzdialenej prce, ktormi s typicky
173
ifrovan virtulne privtne siete, sa pouvaj vyhraden zariadenia na dvojfaktorov

autentifikciu. Ide vinou o pouitie prihlasovacieho mena, hesla, sla PIN a sla
generovanho tokenom (zariadenm, ktor je zosynchronizovan uniktnym inicianm
seedom a generuje jednorazov prstupov hesl One Time Passcodes).
6.8 Monitorovanie a plnovanie kapact systmovch zdrojov

Monitorovanie kapact systmovch zdrojov je uren na kontinulne vyhodnocovanie
vyuvania zdrojov IKT. Pri plnovan kapact systmovch zdrojov je potrebn rta so
zvenm potu pouvateov a prve vstup kontinulneho monitorovania kapact poskytuje
aktualizovan informciu o situcii.
Situcia s nzkou pravdepodobnosou me v prpade, e k nej djde, spsobi vek kodu
a preto je potrebn procesy pravidelne revidova a aktualizova. Manament bezpenosti
prevdzky, ktor procesne riei zvldanie tchto incidentov, zaha metodick postupy
pouiten v prpade potreby obnovenia pvodnho stavu prevdzky (ak dopad incidentu m
kritick nepriazniv vplyv na kontinuitu prevdzky). Tieto metodick postupy na obnovenie
pvodnho stavu s formalizovan v krzovch plnoch a plnoch na obnovu havarijnho stavu Business continuity plan (BCP) a Disaster recovery plan (DRP).
6.8.1
Procesy monitorovania hardvru
V komplexnch prostrediach sa zavdzaj nstroje na detekciu abnormlneho sprvania prvkov

infratruktry a na detekciu nadmernho erpania zdrojov. Nevyhnutnou je tie dokumentcia
pouitch softvrovch rieen a kontrola ich innosti, rieenie a reportovanie abnormlnych
udalost pri ich prevdzke. [2]
Reporty na monitorovanie efektvnej a bezpenej prevdzky hardvru zahaj:
reporty o dostupnosti tieto reporty dokumentuj asov intervaly, v ktorch je prvok IKT
schopn prevdzky. Hlavnm cieom tohto reportu je identifikova vchylky v podobe
pretrvvajcej nedostupnosti zvanej tie downtime.
Tak nedostupnos me indikova:

o
pouitie nesprvnych komponentov IKT na zvolen el,
presiahnutie vyhradenho asu na drbu systmu,
nevyhnutnos preventvnej drby,
neadekvtnu funkciu podpornej infratruktry (napr. nedostaton prsun

elektrickej energie, nesprvne fungujce chladenie),
nedostatone vykolench opertorov.
reporty o poruchch hardvru identifikuj poruchy procesora, vstupno-vstupnch

zariaden, prsunu elektrickej energie a diskov pripojench k systmu. Tieto reporty by mali
by pravidelne kontrolovan osobami zodpovednmi za manament prevdzky kvli
vasnmu predchdzaniu incidentov svisiacich s tmito poruchami a na prpadn vyvodenie
npravnch krokov obnovenia tandardnej prevdzky. Audtor informanho systmu by si
mal by vedom, e sprvne urenie priny poruchy hardvrovho, alebo softvrovho
komponentu IKT nie je jednoduch a okamit. Reporty by mali by kontrolovan kvli
nepravidelnm, preruovanm poruchm, alebo poruchm, ktor sa asto opakuj a mu
spsobova problmy pri identifikovan skutonch prin porch.
reporty o vyuit zdrojov tieto automatick reporty dokumentuj pouitie prvku IKT
a pripojench perifrnych zariaden. Softvrov monitorovacie nstroje s pouit na
zmeranie vyuitia procesorov, sieovch zdrojov a sekundrnych pamovch jednotiek
174
(napr. diskov a pskovch mdi). V zvislosti od pouitia operanho systmu by sa vyuitie

zdrojov pre viacpouvatesk potae typu mainframe malo pohybova od 85 do 95 percent
s doasnmi vchylkami do 100%, alebo obasnm klesnutm k 70%. Reporty tohto druhu je
mon vyui zamestnancami zodpovednmi za manament prevdzky pri predpovedan a
plnovan toho ak vpotov kapacity je potrebn vyui v konkrtnych situcich.
vedenie zznamov o aktvach inventr zariaden pripojench k sieti (PC, servery,

smerovae a in).
Ak je vyuitie zdrojov trvalo nad hranicou 95%, osoby zodpovedn za manament IKT by mali
zrevidova vzory pouvateskho sprvania a sprvania aplikcie pri uritch podmienkach.
Cieom tejto revzie by malo by uvonenie systmovch kapact (diskovho priestoru),
aktualizcia hardvrovch komponentov prslunho prvku IKT, alebo presunutie vpotovo
nronch loh do menej exponovanch asov (naprklad poas noci). Ak je vyuitie zdrojov
systmu trvale pod hranicou 85%, je vhodn naopak zrevidova, i nie je mon niektor
vpotov kapacity systmu uvoni pre vpotovo nronejie lohy. [2]
6.8.1.1 Manament systmovch kapact
Manament systmovch kapact predstavuje plnovanie a monitorovanie vpotovch zdrojov.
elom tchto innost je uisti sa, e dostupn zdroje s vyuit efektvne s ohadom na
rozirovanie, alebo zmenovanie rozsahu cieov organizcie. Kovm vstupom pre vytvorenie
plnu kapact s poiadavky organizcie. Tento pln by mal by revidovan a aktualizovan
najmenej jedenkrt do roka.[5]
Plnovanie kapact zohaduje nasledovn parametre:
vyuitie procesora,
vyuitie diskov,
vyuitie telekomunikanch veden a sieovch liniek,
vyuitie vstupno-vstupnch zariaden,
poet pouvateov,
nov technologick trendy,
nov druhy aplikci,
zmluvy SLA.
Niektor z tchto faktorov sa mu navzjom ovplyvova. Naprklad vyuitie

inteligentnejch terminlov, ktor spracovvaj dta loklne a a potom ich posielaj do
centrlneho loiska me priaznivo ovplyvni objem dt prenanch po sieti.[5]
6.9 Zaznamenvanie
udalost
bezpenostnch incidentov
(logovanie)
a monitoring
Vo vpotovom systme prebieha mnostvo procesov, ktorch innos generuje auditn

zznamy. Tieto poskytuj kov informcie, ktor mu by pouit na posdenie optimlnosti
nastavenia systmu vzhadom na jeho funkciu a bezpenos, alebo na vyetrovanie vzniknutch
incidentov. Dveryhodn, relevantn a dostatone detailn logy s dleit pri identifikovan
prin incidentov a tie s dobrm dkazom pri forenznej analze v sdnom vyetrovan.
Zznamy auditu predstavuj chronologick zznam systmovch aktivt dostaton pre
rekontrukciu, revziu a skmanie postupnosti stavov prostredia a aktivt, zastujcich sa na
realizcii opercie, procedry, alebo udalosti v transakcii od jej zaiatku po jej konen vsledok.
175
Auditn zznamy typicky slia na odlaovanie systmu alebo aplikcie v prpade zistenia
systmovej alebo aplikanej chyby, optimalizciu, vytvranie tatistk alebo na monitoring
udalost relevantnch z bezpenostnho hadiska. Taktie pri forenznej analze plat, e logy,
ktor s sam o sebe nekodnm zznamom sa mu v kontexte s inmi zznamami
a nedigitlnymi dkazmi ukza ako zsadn pre vyvodenie zverov vyetrovania.
Auditn zznamy s zznamy generovan rozlinmi softvrovmi komponentmi beiacimi v IT
infratruktre. Zsady a princpy vytvrania robustnch logovacch systmov s zo zrejmch
dvodov v mnostve projektov dodriavan od zaiatku vvoja.
Rozlin formy logovacch mechanizmov s implementovan prakticky vo vetkch operanch
systmoch (vrtane zabudovanch systmov, napr. v aktvnych sieovch prvkoch), v
databzovch systmoch a u viny pecifickch softvrovch aplikci (proprietrne antivrov
rieenia, a pod.).
Existuje viacero dvodov, preo vies auditn zznamy:
vyvodenie zodpovednosti - logovacie zznamy nm pomu spoji urit osoby s uritmi

udalosami,
rekontrukcia udalost - auditn zznamy mu by zobrazen v chronologickom porad

a teda, vieme presne uri, o sa stalo pred incidentom a poas neho. Aby sme dosiahli
absoltnu presnos a aby sme zosynchronizovali jednotliv zdroje logovacch zznamov, je
potrebn synchronizova systmov as poda centrlneho servera,
detekcia prieniku - neautorizovan, alebo neobvykl udalos mus by zaznamenan, aby

mohla by sptne zobrazen. Dlhodob archivcia logov je v tomto snaen vemi prnosn.
V zvislosti od komplexnosti a mnostva logov je potrebn zvoli sprvny spsob ich

uchovvania a vyhodnocovania. Mon spsoby analzy logov sa delia do dvoch kategri:
manulne tento spsob je asto neefektvny, pretoe musme hada iastkov informcie
po viacerch systmoch,
automatick (pomocou skriptov a pecilnych softvrov) najviac vyuvan hlavne kvli

vysokej poetnosti logov.
Bezpenostn auditn zznam mus by bezpodmienene chrnen pred neoprvnenou zmenou,

na o mono vyui aj riadenie prstupu. Medzi odporan praktiky patr zapisovanie zznamov
na mdium, na ktor je mon zpis len raz, aby nebolo mon u existujci zznam zmeni.
Monm rieenm riadenia prstupu je pridelenie prv na tanie a aktualizciu (ale nie
modifikciu, alebo mazanie) do vyhradench ast systmu na ukladanie dt. Takto vyhraden
prstup je mon zabezpei pridelenm pecifickch kov. Systm na ukladanie dt potom
vyhodnocuje pridelenie prstupu ku konkrtnej pouvateskej asti na zklade poskytnutho
ka. Ak sa k poskytnut pouvateom zhoduje s tm, ktor mu je pridelen, je uvateovi
umonen prstup. Prstup je pridelen aj pouvateovi s tzv. master kom, ktor umouje
autorizovan prstup do vetkch ast systmu a typicky ho m k dispozcii vlastnk systmu.
alie metdy zachovania dvernosti, integrity a dostupnosti logovch zznamov:
ifrovanie citlivch dt v prpade, ak s dta prenan po sieti a predovetkm v prpade,

e sa jedn o prenos dt po bezdrtovej sieti,
evidencia mdi je dleit ma prehad o tom, kde s dta uloen a kto m k nim prstup,
oznaovanie mdi oznaenie internch aj externch mdi, zapsanie dtumu vytvorenia

mdia, dtumu znienia, men prenanch sborov, verzia a stupe klasifikcie,
pouitie fyzickej ochrany prenanch informci zabezpeenie toho, e lokalita, v

ktorej s dta fyzicky umiestnen je v slade so tandardami fyzickej a objektovej
bezpenosti,
176
vykolen personl organizovanie kolen, ktor zvia povedomie zamestnancov o

sprvnom zaobchdzan s dtami.
Dvody preo maj by auditn zznamy chrnen pred zsahom a tanm nepovolanmi
osobami zahaj zachovanie ich integrity, ale zrove je nezanedbatenou aj skutonos, e
informcie z tchto logov s ahko zneuiten tonkom. Pri uchovvan logov je poda dobrej
praxe potrebn zabezpei nielen ich loklne kpie, ale tie ich prena do bezpenej
geograficky vzdialenej lokality, kvli zachovaniu vetkch troch aspektov bezpenosti:
dvernosti, integrity a dostupnosti. Dvernos je v tomto prpade dleit kvli tomu, aby sme
predili neautorizovanmu prstupu a prpadnmu zneuitiu tchto dt.
Zachovanie integrity zabezpe, e nedochdza k pokodeniu uloench dt, alebo ich
neautorizovanej modifikci. Dostupnos je dleit zabezpei z toho dvodu, e pri
nedostatonom zabezpeen uloench mdi existuje vysok riziko znienia, alebo pokodenia
dt.
Pri prenan logovch zznamov do geograficky vzdialenej lokality plat, e rzne systmy a
aplikcie maj rzne formy vstupu do logovacch sborov, preto je vhodn tieto zznamy
sumarizova a normalizova loklne, aby sme predili prenaniu zbytone vekho kvanta dt
po sieti do centrlneho loiska.
Defincia toho, o sa d povaova za neobvykl udalos sa rzni, ale do uritej miery by sme
mohli generalizova a poveda, e neobvykl udalosti zahaj:
nespen prihlsenia,
prihlsenia mimo benho pracovnho asu,
zamknutie tov po presiahnut povolenho potu pokusov o prihlsenie,
neobvykl sieov aktivitu (skenovanie siete, prenos neobvykle vekho objemu dt apod.),
zmeny konfigurcie mimo benej drby a bez formlneho zznamu,
prstupy uvateov s nslednou eskalciou prstupovch prv,
neautorizovan pouitie zdrojov,
neprivilegovan prstup k sborom,
prstup k samotnm logovacm zznamom,
neobvykl erpanie systmovch prostriedkov (pam, CPU) at.
Systmov a aplikan logy zaznamenvaj a uchovvaj vetky bezpenostne relevantn

incidenty. Nstroje na monitoring a logovanie bezpenostnch incidentov ponkaj monos
nastavenia rovne detailnosti logov, ich konsolidciu pri zbere z mnostva sieovch zariaden
a operanch systmov v celej sieovej infratruktre.
Citlivos zaznamenvania udalost a konkrtne spsoby nastavenia zaznamenvania udalost
v operanch systmoch MS Windows, UNIX/Linux a inch sa lia v zvislosti od prostredia ,
v ktorom s nasadzovan a aplikcie, ktor je na nich nasaden. Pokrytie tak irokej oblasti sa
vymyk rozsahu tohto dokumentu, preto sa tejto tme nebudeme bliie venova.
Podstatn vak je, e vetky druhy systmov, dokonca aj tie plne zkladn vnoren
(embedded) systmy, maj implementovan logovanie, bola to jedna z prvch vlastnost
operanch systmov od ich plnho zaiatku (urit forma zaznamenvania pouvateskej
aktivity, tzv. accounting, bola zapracovan u do pvodnho systmu Unix v 70-tych rokoch).
Dleit dta, akmi auditn zznamy nepochybne s, i u z pohadu operatvy, rieenia
incidentov, hadania prin anomlnych udalost, alebo forenznho vyetrovania pri kriminlnych
inoch, musia by chrnen pred pokodenm, pozmenenm, alebo znienm.
177
Medzi najbenejie techniky na predchdzanie stratm logovacch zznamov je ich okamit

zlohovanie do geograficky oddelenej lokality. Pokia sa dta prenaj po potencilnej
nebezpenej linke, ktor nie je dedikovan pre zlohovanie je uiton vyui ifrovanie prenosu
(v Linuxe je mon poui napr. nstroj rsync cez protokol ssh, alebo nstroj scp na bezpen
koprovanie na vzdialen systm).
Na zaznamenvanie povolench a nepovolench eskalci privilgi administrtorov a opertorov
na sieovch zariadeniach slia accounting nstroje ako napr. TACACS+, asto modifikovan
poda potrieb konkrtneho informanho systmu na sprvu prstupov. TACACS+ je protokol
pvodne vyvjan CISCO Technologies, ktor sli ako sprostredkovate autentifikcie: sieov
zariadenia na ktor sa pouvate sna pristpi kontaktuj TACACS+ server a overia s nm, e
pouvatesk meno a heslo shlas a je autorizovan na prstup k danmu zariadeniu. Funkciami
TACACS+ s teda autentifikcia, autorizcia a accounting (AAA). Zaznamenva prstupy ku
zdrojom vrtane neoprvnench pokusov.
Tento AAA (autentifikcia, autorizcia, accounting) protokol pvodne vyvjan americkm
ministerstvom obrany a neskr spolonosou Cisco Systems je dnes u vone riten a v IT
priemysle sa stal tandardom. V produknch prostrediach je asto nasadzovan a modifikovan
poda individulnych potrieb.
Jeho tri hlavn funkcie s AAA:
Autentifikcia uruje kto, resp. ktor potaov program me pristupova,
Autorizcia uruje k omu me pristupova,
Accounting vedenie zznamov o vyie uvedench opercich.
6.9.1
Zaznamenvanie chb a zlyhan
Sasou riadenia prevdzkovej bezpenosti s tie monitorovacie rieenia na zaznamenvanie

chb a zlyhan. V praxi sa nasadzuj monitorovacie mechanizmy pre hardvrov prvky
infratruktry, ako s napr. diskov polia, kontroluje sa ich bezchybn prevdzka a vkon.
almi dleitmi informciami, ktor je vhodn monitorova s priebehy importu dt, vkonu
databz a pod.
V rozsiahlych sieovch prostrediach sa tieto poiadavky realizuj integrciou mnohch
monitorovacch rieen, priom asto dochdza k nekonzistencim a falone pozitvnym
alarmom, resp. falone negatvnym vsledkom a inm chybm v posden incidentu a vyvoden
dsledkov.
Nutnou sasou efektvneho manamentu bezpenostnch incidentov je aj konsolidcia
asovch dajov medzi systmami, napr. kvli vyetrovaniu ich nadvznosti a vyvodenie
zodpovednosti za incident. Protokol NTP sli na synchronizciu systmovho asu naprie
sieovou infratruktrou, m zabezpeuje korektn a konzistentn asov daj v logovacch
zznamoch.
6.9.1.1 Systmy pre automatizovan vyhodnocovanie bezpenostnch udalost (SIEM)
Sprvny monitoring a skonsolidovanie asovch informci naprie celou IT infratruktrou je
jednm z nstrojov bezpenosti, ale stle neposkytuje ochranu pred mnostvom sofistikovanch
tokov, ktor by mohli ohrozi prevdzku a spsobi vznamn materilne straty a straty
renom. Systmy SIEM (Security Incident and Event Management) s nstrojom, ktor preber
z pliec bezpenostnho analytika lohu konsolidcie a kontroly rznych typov logovch
zznamov zo serverov, IDS/IPS zariaden, klientskch stanc, sieovch zariaden, databz,
zariaden na kontrolu prstupu at. Takchto logovch zznamov s obrovsk kvant, SIEM
zabezpeuje ich triedenie, vyhodnocovanie, ich zdruovanie do vlkien a ich vizualizciu
v relnom ase.
178
6.10 Poiadavky zkona . 275/2006 Z. z. a vnosu o tandardoch pre

ISVS v oblasti bezpenosti prevdzky
Poda zkona . 275/2006 Z. z. o informanch systmoch verejnej sprvy je informan systm
verejnej sprvy (ISVS) tak informan systm v psobnosti povinnej osoby ako sprvcu, ktor
sli na vkon verejnej sprvy a ktorho prevdzkovanie vyplva z osobitnho predpisu, alebo
z prvomoci rozhodova o prvach a povinnostiach fyzickch osb, alebo prvnickch osb
v oblasti verejnej sprvy.
Legislatvny rmec pre tandardy ISVS v oblasti bezpenosti prevdzky uruje prva
a povinnosti povinnch osb v oblasti informanch systmov verejnej sprvy a innost, ktor
zabezpeuj ich prevdzku. Stanovuje tie zkladn podmienky na zabezpeenie
integrovatenosti a bezpenosti ISVS.
Povinnmi osobami na el zkona s ministerstv a ostatn stredn orgny ttnej sprvy,
orgny miestnej ttnej sprvy, obce a samosprvne kraje. Povinn osoby zabezpeuj plynul,
bezpen a spoahliv prevdzku informanch systmov verejnej sprvy vrtane organizanho,
odbornho a technickho zabezpeenia a zodpovedaj za zabezpeenie informanho systmu
proti zneuitiu.
Povinn osoby maj za lohu zabezpei, aby informan systm vyhovoval tandardom, ktor
vydalo ministerstvo vo veobecne zvznom prvnom predpise. Tmto tandardom sa rozumie
Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o tandardoch pre informan
systmy verejnej sprvy vydan 15.7.2010.
Konkrtne v slade s 3 ods. 4 psm. b), c) a i) zkona o ISVS s jednotliv povinn osoby
povinn:
zabezpeova plynul, bezpen a spoahliv prevdzku informanch systmov verejnej

sprvy, ktor s v ich sprve, vrtane organizanho, odbornho a technickho zabezpeenia,
zabezpeova informan systm verejnej sprvy proti zneuitiu,
zabezpeova, aby bol informan systm verejnej sprvy v slade so tandardmi

informanch systmov verejnej sprvy (alej len "tandardy").
Pokia chce povinn osoba splni uveden povinnosti, najm zabrni zneuitiu ISVS a chce
dosiahnu plynul, bezpen a spoahliv prevdzku informanch systmov verejnej sprvy,
mus sa stara o riadenie informanej bezpenosti vo vetkch jej oblastiach poda prslunch
tandardov, ktor rovnako vydalo Ministerstvo financi vo forme vnosu k zkonu o ISVS.
Konkrtne ide o vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o tandardoch
pre informan systmy verejnej sprvy (alej len vnos o tandardoch ISVS).
6.10.1 Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o
tandardoch pre informan systmy verejnej sprvy
Samotn vnos o tandardoch pre ISVS riei problematiku riadenia IB, ale tandardizuje aj
alie oblasti. Konkrtne v slade s 1 vnosu o tandardoch pre ISVS ide o nasledovn oblasti:
Tmto vnosom sa ustanovuj tandardy pre informan systmy verejnej sprvy, ktormi s:
a) technick tandardy, vzahujce sa na technick prostriedky, sieov infratruktru
a programov prostriedky, a to
1. tandardy pre prepojenie,
2. tandardy pre prstup k elektronickm slubm,
3. tandardy pre webov sluby,
4. tandardy pre integrciu dt,
179
b) tandardy prstupnosti a funknosti webovch strnok, vzahujce sa na aplikan

programov vybavenie poda zkona,
c) tandardy pouitia sborov, vzahujce sa na formty vmeny dajov,
d) tandardy nzvoslovia elektronickch sluieb, vzahujce sa na sieov infratruktru,
e) bezpenostn tandardy, vzahujce sa na technick prostriedky, sieov infratruktru,
programov prostriedky a daje, a to
1. tandardy pre architektru riadenia,
2. tandardy minimlneho technickho zabezpeenia,
f) dtov tandardy, vzahujce sa na daje, registre a selnky,
g) tandardy elektronickch sluieb verejnej sprvy, vzahujce sa na daje, registre, selnky
a aplikan programov vybavenie poda zkona,
h) tandardy projektovho riadenia, vzahujce sa na postupy a podmienky spojen s vytvranm
a rozvojom informanch systmov verejnej sprvy
Organizcie teda nemaj povinnos vyma iadne nov prevdzkov tandardy, ale mu si
natudova a osvoji tandard ISO 27001 a dobr praktiky z ISO 27002, z ktorch tento vnos
vychdza. Po ich prevzat je mon prava poda konkrtnych poiadaviek, vytvorenie plnov na
riadenie informanej bezpenosti a prpadne kontinulne zapracovvanie potrebnch aktualizci
svisiacich so zmenami podmienok.
Vnos definuje tandardy pre organizan opatrenia:
informanej bezpenosti - bezpenostn politika,
personlnu bezpenos - pouenia, postupy pri prijman a ukonen pracovnho pomeru,
manament rizk pre oblas informanej bezpenosti vyhotovovanie analzy rizk,
kontroln mechanizmus riadenia informanej bezpenosti pravideln extern/intern audit,
Technick tandardy minimlneho technickho zabezpeenia s definovan pre:
ochranu proti kodlivmu kdu (softvrov ochrana, leglnos softvru),
sieov bezpenos (firewall),
fyzick bezpenos a bezpenos prostredia (priestory a reimov opatrenia),
aktualizciu softvru,
monitorovanie a manament bezpenostnch incidentov

bezpenostnch incidentov, technick zabezpeenie),
periodick hodnotenia zranitenost (analza rizk),
zlohovanie (zabezpeenie zlohovania, testovanie zloh),
fyzick ukladanie zloh (umiestnenie prevdzkovch a archivanch zloh),
riadenie prstupu (autentizcia a autorizcia uvateov),
aktualizcia informano-komunikanch technolgi (plnovanie, zmenov manament,

testovanie a sprva dokumentcie),
as tretej strany (analza rizk a SLA z pohadu spoluprce s tretmi stranami).
(ohlasovanie
Vnos o tandardoch pre ISVS v oblasti bezpenosti prevdzky alej upravuje:

180
a evidencia
technick tandardy pre pripojenie, prstup k elektronickm slubm, webov sluby a

integrciu dt,
tandardy prstupnosti a funknosti webovch strnok vzahujce sa na aplikan

programov vybavenie,
tandardy jednorazovej elektronickej vmeny dt a formty vmeny dajov,
tandardy nzvoslovia el. sluieb vzahujce sa na sieov infratruktru,
tandardy pre architektru riadenia, minimlneho technickho zabezpeenia,
dtov tandardy pre daje, registre, selnky.
Ministerstvo financi vykonva kontroly na dodriavanie vnosu a pri nedodran tandardov

povinnmi osobami uklad sankcie. Za poruenie povinnost tkajcich sa riadenia IB je mon
udeli aj sankcie a do vky 35.000 EUR.
6.11 Zver
Bezpenos prevdzky si v praxi vyaduje komplexn a efektvny prstup, ktorho cieom je
elimincia, alebo aspo minimalizcia rizk vyplvajcich z prevdzky dleitch informanch
systmov a im podliehajcich prvkov IKT. Uviedli sme prehad najdleitejch zsad v oblasti
riadenia bezpenosti prevdzky a tie tandardizovan dobr praktiky pre minimalizciu vskytu
neiaducich incidentov.
innosti zavedenia a koordincie procesov vedcich k elimincii bezpenostnch incidentov
priamo ohrozujcich kontinuitu prevdzky s vo vznamnej miere motivovan uvedomenm si
dleitosti chrnench informanch aktv. Zavedenie kontrolnch mechanizmov mus by
v rovnovhe s dodranm pravidiel pouvateskho komfortu, pouitenosou systmov
a efektivitou procesov. Zrove nklady vynaloen na implementciu technickch a
organizanch opatren musia by prijatenou polokou pre stanoven rozpoet.
181

[1]
Procesn model poda STN EN ISO 9001. [Online] [Dtum: 5. 9 2013.]

http://www.poling.sk/procesny-model.php.
[2]
Hansche, Susan, Berti, John a Hare, Chris. Official Guide to the CISSP exam. s.l. : CRC
Press Company, 2004.
[3]
Wikipedia, the free encyclopedia. Change management (ITSM). [Online] [Dtum: 5. 9

2013.] http://en.wikipedia.org/wiki/Change_management_(ITSM).
[4]
Maloof, M. Are SIEM and Log Management the same thing? [Online] [Dtum: 17. 7
2013.]
http://www.networkworld.com/reviews/2008/063008-test-siem-logintegration.html.
[5]
David L. Cannon, Timothy S. Bergmann, Brady Pamplin. CISA: Certified Information

Systems Auditor Study Guide. 2006. 0782144381.
[6]
RAID. Wikipedia The Free Encyclopedia. [Online] [Dtum:

http://en.wikipedia.org/wiki/RAID.
[7]
Metodick usmernenie seku bankovho dohadu Nrodnej banky Slovenska . 7/2004

k overeniu bezpenosti informanho systmu banky a poboky zahraninej banky.
[Online] [Dtum: 19. 4 2013.] http://www.nbs.sk/sk/dohlad-nad-financnymtrhom/dohlad-nad-bankovnictvom/odporucania-a-metodicke-usmernenia/metodickeusmernenia/mu-useku-bankoveho-dohladu-nbs-c-7-2004.
[8]
Wikipedia, the free encyclopedia. Operations security. [Online] [Dtum: 17. 7 2013.]
http://en.wikipedia.org/wiki/Operations_security.
[9]
Bratislava, MO SR. Bezpenostn stratgia Slovenskej republiky. 2001. Zv. 17.7.2001,

Obrana .14.
[10] CSIRT.SK.
Informan
brora.
[Online]
http://www.csirt.gov.sk/img/infobrochure.pdf.
[Dtum:
19.
22.
8 2013.]
2013.]
[11] Hlavika, Mgr. Luk. Forenzn analza IKT. [Online] [Dtum: 24. 7 2013.]
http://www.dcs.fmph.uniba.sk/~gazi/uib/materialy/forensic.pdf.
182
7 Fyzick bezpenos
Ivan Oravec a Jozef Stanko
7.1 vod
Podobne, ako in oblasti riadenia IB popsan v alch kapitolch, je oblas fyzickej
bezpenosti jednou zo zkladnch oblast riadenia IB, ktor si vyaduje formlny a systematick
prstup. Zanedbanie riadenia v ktorejkovek oblasti me ma fatlne nsledky na bezpenos
samotnch aktv z pohadu naruenia ich zkladnch aspektov, ktormi s ich integrita,
dostupnos a dvernos. Rovnako dleitm faktom, pri riaden IB v rmci celej organizcie, je
vyvenie jednotlivch oblast riadenia navzjom, najm vzhadom na povahu a citlivos
chrnench aktv a typ, truktru a dislokciu organizcie.
Poznanie problematiky v oblasti fyzickej bezpenosti je preto nutnm, avak nie postaujcim
predpokladom spenho riadenia IB v rmci organizcie a elimincie monch hrozieb
a zranitenost.
Vina z ns si pod pojmom fyzick bezpenos predstav najm ochranu objektov alebo
pecifickch priestorov strnou (bezpenostnou) slubou, alebo inou ozbrojenou zlokou.
Tento typ ochrany samozrejme predstavuje jednu zo zkladnch zloiek, avak vzhadom na
zven finann nklady sa pouva len na ochranu objektov alebo priestorov, v ktorch sa
nachdzaj skutone citliv aktva. Ide o aktva, ktorch hodnota si to vyaduje, t.j. je adekvtna
implementovanm opatreniam na ich ochranu.
Vo vine prpadov je fyzick ochrana realizovan tzv. mechanickmi zbrannmi
prostriedkami a technickmi zabezpeovacmi prostriedkami. Vstup z technickch
zabezpeovacch prostriedkov samozrejme me by vyveden do centrly skromnej
bezpenostnej sluby, alebo na in pult centralizovanej ochrany, spravovan napr. policajnm
zborom, take v tomto prpade ide o aksi kompromis medzi efektivitou ochrany (reaknm
asom fyzickej ochrany v prpade naruenia objektu) a nkladmi vynaloenmi na samotn
ochranu.
Sasou fyzickej bezpenosti s samozrejme aj alie opatrenia a postupy, a to najm
podmienky vstupu a pohybu osb v rmci chrnench objektov a priestorov, problematika
prstupu k samotnm IKT a vhodn spsoby ich umiestovania, najm vzhadom na potreby
a podmienky IKT na prostredie, ktor s in pre IKT a in pre loveka.
Zrove je potrebn riei fyzick bezpenos komplexne poas celho ivotnho cyklu IKT, nie
len fzu jeho pouvania v relnej prevdzke. Je dleit venova sa fyzickej bezpenosti vo
vetkch fzach ivotnho cyklu IKT, od vvoja ponc a koniac pri vyraovan a likvidci
zariaden. Pri dnenom vyuvan modernch technolgi, i u doma alebo v prci, by bolo
vemi krtkozrak, keby problematika riadenia fyzickej bezpenosti konila len na hranici
chrnench a jasne vymedzench priestorov a objektov. Dnes u je samozrejmosou, e v rmci
riadenia bezpenosti je potrebn riei aj spsoby a podmienky pre mobiln a vzdialen prcu
a s tm spojen problmy ochrany IKT, a v nich nachdzajcich sa dtovch aktv, aj mimo
chrnench priestorov konkrtnej organizcie.
V slade s uvedenmi skutonosami je tto kapitola rozdelen do niekokch zkladnch ast.
elom prvej asti je poskytn prehad o zkladnch prvkoch fyzickej bezpenosti. Druh as
je zameran na vysvetlenie pojmov ako s bezpenostn perimeter, chrnen objekt, chrnen
priestor a bezpenostn zna. Osobitn pozornos je venovan problematike umiestovania
a prstupu k IKT. Samostatn as je venovan pecifickm opatreniam ako s napr. organizan
opatrenia, prca mimo priestorov organizcie, ochrana proti neiaducemu elektromagnetickmu
vyarovaniu a pod. V poslednej asti sa strune pozrieme na tandard ANSI/TIA 942 - tandardy
183
Fyzick bezpenos | MF SR
telekomunikanej infratruktry pre dtov centr, ktor definuje tyri zkladn rovne
poiadaviek na dtov centr.
7.2 Ciele fyzickej ochrany IKT

V rmci fyzickej bezpenosti meme hovori, e nejde len o ochranu IKT zariaden ako takch
(i u systmov a aplikci, ktor podporuj vkon sluieb a innost konkrtnej organizcie,
alebo systmov a zariaden podpornej sieovej a komunikanej infratruktry), ale aj o ochranu
alch pecifickch aktv, ktormi s spravidla udia, objekty (priestory, kancelrie, budovy,
vrobne haly, at.) a informcie a daje v materilnej (fyzickej) podobe (napr. dokumenty,
sprvy, tlaiv, know-how, at.).
Poda normy STN ISO/IEC 27002 je cieom manamentu v tejto oblasti zabrnenie
neautorizovanmu fyzickmu prstupu, pokodeniu a ohrozovaniu priestorov a informci
spolonosti a predchdzanie strate, pokodeniu alebo kompromitcii aktv spolu s predchdzanm
preruenia aktivt a innost spolonosti.
Uveden norma zrove rozdeuje fyzick bezpenos a bezpenos prostredia na dve zkladn
oblasti. Prv oblas riei problematiku tzv. bezpench oblast, ako je napr. perimeter fyzickej
bezpenosti, opatrenia fyzickho vstupu, zabezpeenie kancelri, miestnost a prostriedkov,
ochrana pred vonkajmi hrozbami a hrozbami prostredia, prca v zabezpeench oblastiach
a verejne prstupn priestory, zsobovacie a expedin oblasti. Druh oblas sa zaober
problematikou bezpenosti zariaden ako takch. Ide najm o umiestnenie a ochranu zariaden,
podporn sluby, bezpenos kabele, drbu zariaden, bezpenos zariaden mimo priestorov
organizcie, bezpen likvidciu alebo optovn pouitie zariaden a premiestovanie majetku
organizcie.
V rmci kadej z uvedench oblast s definovan zkladn opatrenia, ktor je vhodn
implementova za elom zabezpeenia primeranej ochrany IKT zariaden a vetkch aktv
organizcie.
Dopady pri nedostatonej implementcii opatren fyzickej bezpenosti mu by spojen v tom
lepom prpade len s materilnou alebo minimlnou finannou stratou. Pri uplatnen
najhorieho scenra me s, nie len o pokodenie renom organizcie, ale aj o znan finann
straty, alebo sankcie, ktor mu spsobi prpadn krach celej spolonosti. V prpade systmov
kritickej infratruktry, ktorch naruenie, nedostatok, alebo znienie by mohlo spsobi
naruenie spoloenskej stability a bezpenosti ttu s tieto dopady ete omnoho zvanejie. No
asi najzvanejm dopadom by bolo, keby dolo, i u vplyvom toku prpadnho naruitea,
alebo vplyvu vonkajch faktorov, k stratm na udskch ivotoch.
Hlavnm cieom fyzickej bezpenosti a bezpenosti prostredia je elimincia hrozieb
a zranitenost a minimalizcia dopadov v prpade ich uplatnenia.
Vo veobecnosti meme poveda, e cieom fyzickej bezpenosti je zabezpeenie:
prstupu do priestorov, kde sa nachdzaj IKT len oprvnenm osobm a zabrnenie

vniknutia neoprvnench osb,
kontrolovanho pohybu neoprvnench osb (nvtev a tretch strn) tak, aby nedochdzalo
k neoprvnenej a neautorizovanej innosti nad IKT, aby nedochdzalo k narueniu
dvernosti, integrity alebo dostupnosti aktv organizcie,
umiestnenia IKT do vyhovujceho prostredia z pohadu jeho prevdzky alebo uskladnenia

(napr. teplota, tlak, vlhkos, antistatick prava, zlon napjanie a pod.),
umiestnenia IKT do vyhovujceho prostredia z pohadu dvernosti spracovvanch aktv

(napr. odpozorovanie obrazovky, odchytenie neiaduceho EMV a pod.),
umiestnenia IKT do prostredia, ktor eliminuje rizik vyplvajce z prrodnch vplyvov

(napr. poiar, zplava, dym, zemetrasenie a pod.),
184
umiestnenia IKT do prostredia, ktor eliminuje rizik vyplvajce z vplyvov okolitch

technickch a inch zariaden alebo pohybu osb, prpadne prepravy materilov (napr.
zatopenie z vodovodu alebo krenia, ruenie, vytrhnutie alebo preseknutie kblov,
mechanick pokodenie zariaden a pod.),
ochrany IKT a prslunch aktv v prpade jeho premiestovania alebo likvidcie,
ochrany IKT v prpade vzdialenej prce mimo priestorov organizcie.
7.3 Zkladn poiadavky na prostredie, v ktorom maj psobi IKT

Zkladnm problmom, ktor je potrebn v rmci riadenia fyzickej bezpenosti vyriei je
skutonos, e udia potrebuj pracovn podmienky odlin od podmienok, ktor s vhodn
a potrebn pre fungovanie a prevdzku IKT. Podmienky v priestoroch urench pre uloenie
serverov a archivciu dt s spravidla in ako pracovn prostredie pre zamestnancov. Ide najm
o teplotu, vlhkos a tlak prostredia ale aj o problm so statickou energiou, prpadne potrebou
zlonho napjania.
Pri nedodran podmienok vhodnch pre prevdzku informanch a komunikanch technolgi
me djs k doasnmu, alebo trvalmu narueniu ich funkcie. Zrove to plat aj opane, t.j.
pokia by sa lovek, napr. opertor alebo administrtor IKT, zdroval dlhiu dobu v prostred
umiestnenia IKT mu sa uho prejavi zdravotn problmy s doasnmi alebo aj trvalmi
nsledkami.
Okrem uvedenej skutonosti je potrebn vyriei aj poiadavky na prostredie vzhadom na
hrozby, ako s napr. poiar, zplava, zatopenie z internch rozvodov vody, prpadne krenia
alebo poiarneho systmu, ruenie, vytrhnutie alebo preseknutie kblov, mechanick pokodenie
zariaden a pod.
V prpade spracovvania citlivch informci s vysokou hodnotou pre organizciu je rovnako
dleit zabezpei prslun aktva z pohadu ich neoprvnenho odpozorovania, napr. na
obrazovke potaa, alebo odchytenm neiaduceho elektromagnetickho vyarovania a pod. Za
tmto elom je potrebn zohadni aj uveden skutonosti, resp. poiadavky na prostredie,
v ktorom maj by prevdzkovan prslun IKT.
Poslednou poiadavkou na prostredie je samozrejme poskytnutie dostatonch monost na
realizciu opatren tkajcich sa zabezpeenia prstupu len oprvnench osb, resp. zabrnenia
vniknutia neoprvnench osb. Ide najm o monos vybudovania alebo intalcie potrebnch
mechanickch zbrannch prostriedkov a technickch zabezpeovacch prostriedkov, ale aj
akejkovek inej podpornej infratruktry (napr. vedenie kblov, umiestenie poiarneho systmu,
vybudovanie antistatickej podlahy, zlonho genertora a pod.).
7.3.1
Hrozby a ich nositelia a negatvne vplyvy
Pre efektvne riadenie fyzickej bezpenosti je potrebn pozna zkladn skupinu hrozieb, ktor
s relevantn z pohadu fyzickho zabezpeenia a prpadne aj zkladnch nositeov tchto
hrozieb, aby bolo mon navrhn konkrtne protiopatrenia na eliminciu prslunch rizk
vyplvajcich z tchto hrozieb.
V slade s vyie uvedenm zkladnmi poiadavkami na prostredie, v ktorom maj psobi
IKT, meme hovori o tejto zkladnej skupine hrozieb:
myseln naruenie dvernosti, integrity alebo dostupnosti (napr. pokodenie, krde alebo
sabot, odpozorovanie citlivch informcii, odchytenie neiaduceho EMV a pod.),
nemyseln naruenie dvernosti, integrity alebo dostupnosti (napr. nemyseln mechanick

pokodenie, nemyseln preruenie dtovch alebo elektrickch veden, zabudnutie alebo
strata zariadenia alebo nosia dt, neprimeran manipulcia s IKT, nevhodn nvtevn
priestory alebo nedodranie reimovch pravidiel a pod.),
185
prrodn vplyvy (poiar, dym, zplava, zemetrasenie, zven pranos prostredia, a pod.),
poruchy podpornej infratruktry (preruenie dodvky elektrickej energie, porucha riadenia

klimatizcie, ventilcie, krenia, vodovodu, poiarneho systmu a pod.),
technick poruchy (konkrtne poruchy IKT, ruenie a pod.),
hrozba zneuitia zariaden alebo neoprvnenho prstupu k nim (a v nich spracovvanch,

prenanch alebo ukladanch dt) poas ich premiestovania alebo likvidcie,
hrozba zneuitia mobilnch zariaden alebo neoprvnenho prstupu k nim (a v nich

spracovvanch, prenanch alebo ukladanch dt) pri prci s nimi mimo zabezpeench
priestorov organizcie.
Pri aplikovan konkrtnych opatren fyzickej bezpenosti, organizanch opatren a nvrhu

prslunej dokumentcie a internch smernc v oblasti riadenia fyzickej bezpenosti je potrebn
zohadni aj alie skutonosti v svislosti s uvedenmi hrozbami. Ide najm o hrozby, ktor
vyplvaj z psobenia udskho faktoru, z prstupu tretch strn (napr. pracovnkov drby,
servisu, zsobovania alebo inch zmluvnch pracovnkov), z prstupu a spsobu vjazdu
motorovch vozidiel do objektu, z lokality a umiestnenia budovy alebo chrnenho priestoru,
z nchylnosti budovy na vonkajie vplyvy prostredia, z prpadnch teroristickch aktivt,
z neiaducich aktivt prepustench zamestnancov, zo sprvania sa zamestnancov na pracovisku
(napr. aj z dvodu povolenia alebo zakzania fajenia na pracovisku), zo spsobu prce
zamestnancov vzhadom na innosti organizcie (mobiln prca, kontakt s klientom na
priehradke a vo vyhradench priestoroch alebo v kancelri) a pod.
7.4 Prehad zkladnch prvkov fyzickej bezpenosti

Prostriedky na zaistenie fyzickej bezpenosti spadaj do kategrie klasick ochrana. Je to
zkladn druh ochrany, ktor tvor shrn opatren na priame zabezpeenie objektu a jeho
dleitch ast vytvorenm systmu zbran, prekonanie ktorch vyaduje urit as, pouitie
nstrojov a prostriedkov, zrunos pchatea a pod. [1].
Je potrebn si uvedomi prve uveden asov aspekt a aspekt nronosti, t.j. skutonos, e
neprekonaten ochrana neexistuje. Vetky opatrenia, ktor urobme s prekonaten. Otzkou
zostva len za ak as, a za akch inch, napr. technologickch, organizanch alebo alch
podmienok to bude mon. Z uvedenho dvodu sa pri aplikci fyzickej bezpenosti vyuva
kombincia pouitia mechanickch zbrannch a technickch zabezpeovacch prostriedkov
spolu s pouitm samotnej fyzickej ochrany prostrednctvom ud (napr. SBS) a v kombincii
s almi opatreniami najm organizanho charakteru.
Pouitie mechanickch zbrannch prostriedkov, ako s napr. dvere, plot, stena, mrea, rampa
alebo obdobn prekka slia najm na kontrolu a riadenie vstupu alebo vjazdu do objektu alebo
priestoru, ale zrove aj na zdranie prpadnho naruitea do doby prchodu pracovnkov
fyzickej ochrany alebo polcie. Ide o tzv. preventvne opatrenia, ktor doku za uritch
okolnost a pri sprvnom pouit zabrni v definovanom ase prpadnmu narueniu dvernosti,
integrity alebo dostupnosti informanch aktv. Okrem tchto opatren je mon vyui aj rzne
technick zabezpeovacie prostriedky (napr. systm detekcie naruenia priestoru, riaden systm
kontroly vstupu, poiarny hlsi a pod.), ktor vak v prevanej miere maj u len detektvny
charakter, t.j. doku identifikova konkrtnu hrozbu, znovu za uritch okolnost a podmienok
pouitia, ale nedoku jej zabrni. Preto je vemi dleit uveden prostriedky kombinova
a kombinova ich aj s inmi, najm tzv. reimovmi opatreniami.
elom tejto asti je poskytn prehad o zkladnch prvkoch fyzickej bezpenosti, ktor s
rozdelen na mechanick zbrann prostriedky, technick zabezpeovacie prostriedky
a podporn infratruktru.
186
7.4.1
Mechanick zbrann prostriedky (MZP)
Mechanick zbrann prostriedky maj za lohou sai alebo prakticky plne znemoni
pchateovi jeho vniknutie do chrnenho objektu, prpadne priestoru alebo zabrni manipulcii
s chrnenmi predmetmi.
Medzi zkladn mechanick zbrann prostriedky patria najm:
Vonkajie stavebn prvky:

-
Stavebn prvky budov:

-
steny, stropy, podlahy, strecha, vntorn prieky,
otvorov vplne, ako s napr. dvere, zrubne, okn, balknov dvere, rzne druhy
zabezpeenia vetracch otvorov, mree, rolety, okenice, bezpenostn flie, vrstven sklo
a pod.
Bezpenostn zmky a systmy:

-
rzne druhy oplotenia, barir, mrov, tie brny, zvory a pod.
najm zmky dver, okenn zmky, elektronick zmky.
Bezpenostn uzamykacie systmy:

-
trezory (nazvan aj schovn objekty), stabiln komorov trezory, bezpenostn

schrnky, bezpenostn kufrky, bezpenostn klietky a in.
V prpade mechanickch zbrannch prostriedkov by sa dala aplikova paralela s lnkami

reaze: celok je len tak bezpen, ako bezpen je jeho najslab lnok. V tomto duchu
meme odcitova napr. aj vyhlku NB . 336/2004 Z. z. o fyzickej bezpenosti a objektovej
bezpenosti, ktor hovor: Na urenie odolnosti hranice chrnenho priestoru je rozhodujca t
as hranice chrnenho priestoru, ktor m najniiu odolnos..
Bezpenos mechanickch zbrannch prostriedkov alebo ich odolnos voi prekonaniu je
charakterizovan tzv. prielomovou odolnosou.
Prielomov odolnos vyjadruje stupe pasvnej bezpenosti (mechanickej odolnosti)
mechanickch zbrannch prostriedkov. Stanovuje sa potom odporovch jednotiek (RU)
v prpade schovnch objektov, alebo dkou asovho intervalu (u ostatnch MZP), ktor s
potrebn na ich prekonanie [1].
Pri uren hodnoty prielomovej odolnosti sa zohaduje najm ohodnotenie uritho nradia, t.j.
obtianosti jeho zaobstarania a jeho obsluhy na mieste inu. Kategorizcia nradia zana pri
ahkom runom nrad (hmotnos pribline do 1,5 kg a dka pribline do 40 cm) a kon a pri
pecilnom a najm drahom nrad, ako s napr. termick tye, korunov vrtky a pod.
Samotn prekonanie, najm pri trezoroch, je rozdelen do dvoch kategrii. Ide bu o tzv.
iaston prielom alebo pln prielom mechanickho zbrannho prostriedku. Poda typu
a vekosti chrnenej veci v trezore me riziko predstavova u aj iaston prielom, aj pokia
by cez prslun otvor nemohlo djs k jej odcudzeniu, pretoe minimlne predstavuje riziko
znienia alebo pokodenia chrnenej veci.
7.4.1.1 Vonkajie stavebn prvky
Za vonkajie stavebn prvky, ktor mu, za uritch podmienok, zabezpeova funkciu
mechanickho zabezpeovacieho prostriedku meme povaova najm rzne druhy oplotenia,
barir, mrov, tie brny, zvory a pod.
Za zkladn mechanick zabezpeovac prostriedok obvodovej ochrany meme povaova tzv.
bariry. Na zklade poiadaviek bezpenosti je mon rozdeli bariry nasledovne:
s nzkou pasvnou bezpenosou - v podstate iba ohraniuj priestorovo zemie, a tm

chrnia pred neiaducim vstupom, s to v podstate ploty z rznych materilov,
187
so zvenou pasvnou bezpenosou - bariry pouvan k obvodovej ochrane objektov,

spravidla ide o pevn oplotenie pecilnej kontrukcie alebo mobiln cievkov bariry,
so zaruenou pasvnou bezpenosou - bariry pouvan k obvodovej ochrane objektov

s vysokm stupom rizika, me s o oplotenie pecilnej kontrukcie a do vky 5 m.
Bezpenostn oplotenie je v podstate obvodov (perimetrick) ochrana vonkajieho okolia

objektu, t.j. budovy, alebo priahlch pozemkov a inch chrnench ast. Me by vyroben
naprklad z betnovch alebo inch pevnch tvrnic vystuench oceovmi sieami alebo
prtmi, prpadne zo zvranho pletiva, doplnen ochranou v jeho vrchnej asti v podobe
ostnatho, i iletkovho drtu.
Pre vetky stavebn prvky, i u ide o bariry, mry, ploty, ale aj o posuvn alebo krdlov brny,
prpadne zvory, plat pravidlo, e pokia maj by pouit ako mechanick zbrann
prostriedky, t.j. nie len ako prostriedok na vymedzenie vlastnckych prv a urenie hranice
pozemku, alebo ako estetick doplnok, musia by dostatone odoln a technicky upraven tak,
aby dokzali odolva predpokladanm hrozbm naruenia.
7.4.1.2 Stavebn prvky budov
Stavebn prvky patria k prirodzenm ochrannm prostriedkom mechanickej plovej ochrany,
pretoe s spravidla zkladom celkovej stavebnej kontrukcie objektu. Ako bolo uveden vyie,
patria sem najm steny, podlaha, stropy, ale aj strechy budov a vntorn steny, resp. prieky.
Dleit je ich mechanick odolnos voi prielomu, resp. narueniu, ktor je zvisl
predovetkm od pouitho materilu a jeho hrbky. [2]
Poda pouitho stavebnho materilu sa vo vzahu k mechanickej odolnosti rozliuj:
ahk stavby, ktorch pasvna bezpenos je vemi nzka (patria sem napr. sdro-kartnov
prieky a vplne, vlnit a profilov plechy, murovan prieky z dutch tehl, priekov
betnov steny bez vstue, probetnov murivo a pod.),
pevn stavebn kontrukcie, ktor zabezpeuj, vzhadom na pouit stavebn materily

a dosahovan hrbku (napr. oceov vstue), vek klu mechanickej odolnosti, a tm aj
poadovan pasvnu bezpenos.
Pre zvenie bezpenosti me by do kontrukcie, najm vntornch prieok, vloen vrstva

oceovho plechu, ktor ak je potrebn dosiahnu vyiu triedu bezpenosti me by ete
posilnen vloenmi tenkostennmi profilmi.
Okrem pevnosti samotnch stavebnch kontrukci je dleit aj kvalita a mechanick
zabezpeenie a odolnos spomenutch otvorovch vpln, ako s najm dvere, zrubne, okn,
balknov dvere, rzne druhy vetracch otvorov, mree, rolety, okenice, bezpenostn flie,
vrstven sklo a pod.
Bezpenostn dvere, t.j. dvere odolnejie proti vlmaniu sa v zsade svojou funkciou nelia od
bench dver. Rozdeuj sa do samostatnch kategri. Rozdiely spovaj predovetkm
v pevnostnch parametroch, resp. v prielomovej odolnosti. Bezpenos tchto dver je zaloen
spravidla na bezpenostnch zrubniach, zvesoch dver, viacbodovom uzamykan a vntornej
bezpenostnej truktre. Doplnkovmi bezpenostnmi prvkami dver bva dverov priezor,
ktor me by klasick alebo panoramatick a dverov poistn retiazka umouj pootvorenie
dver na definovan vzdialenos a v tejto polohe dvere zaisti tak, aby nedolo k nsilnmu
vniknutiu nepovolanej osoby, prpadne napadnutiu osoby.
7.4.1.3 Bezpenostn zmky a systmy
Bezpenostn zmky a systmy tvoria najm zmky dver, okenn zmky, elektronick zmky,
zmky bezpenostnch uzamykacch systmov (schovnch objektov, bezpenostnch schrnok,
klietok a pod.).
Ich zkladnou bezpenostnou vlastnosou by mala by implementcia vhodnch ochrannch
prvkov a technolgi, ktor doku zabezpei odolnos zmku najm proti vyhmatnutiu, proti
188
odvtaniu, proti pouitiu nedetruktvnej dynamickej (tzv. bump-key) metdy, prpadne voi
inm pecilnym technikm. Cieom tchto opatren je, aby sa zmok dal otvori len s pouitm
prslunho ka, alebo odpovedajceho kdu v prpade pouitia elektronickho zmku.
Na zvenie bezpenosti je mon v niektorch pecifickch prpadoch poui aj prdavn
zmky. Ide najm o doplnkov uzamykacie zariadenia dverovho zadlabovacieho zmku, ktor
roziruj uzamykac systm dver, a tak zvyuj ich pasvnu bezpenos. Vyhotovuj sa aj
pecilne druhy zmkov, ktorch uzamykacia zostava je vytvoren inm spsobom ako
mechanickm, napr. magnetick, elektrick, elektromagnetick, kombinovan.
V niektorch prpadoch je vhodn pouitie aj okennch zmkov, najm pokia je dleit
zabrni neoprvnenmu otvoreniu okna z vntornej strany. Okenn kovania a uzvery
zabezpeuj dleit lohu z hadiska pasvnej bezpenosti. Musia dostatone zabezpeova
okenn krdlo proti vytlaeniu. V sasnej dobe sa vyrbaj v irokom sortimente prevane
z kovu a je mon takto kovania aj uzamyka vstavanou cylindrickou vlokou priamo v kuke
kovania.
Elektronick zmok je elektronick zariadenie vyuvan namiesto mechanickch zmkov. Me
sli nie len pre zamykanie a odomykanie trezorov, ale naprklad aj budov, prstrojov
a zariaden, prpadne na umonenie prstupu do potaa. Podobne ako mechanick zmok aj
elektrick zmok sa sklad zo zmku (z tacej a vyhodnocovacej jednotky) a elektronickho
ka. Niekedy sa pouva aj kombincia elektronick k v mechanickom ki (automobil),
alebo ovldanie jednho zmku dvoma spsobmi (vstupn brna v panelku sa otvra
elektronickm kom, ale aj mechanickm pre jeho energetick nezvislos). Ich pouitie je
vestrann, nutnou podmienkou vak je nepretrit dodvka elektrickej energie. Zkladnou
lohou vyhodnocovacej jednotky je prevzia pretan daj (kd) zo snmacej asti, deifrova
ho, porovna kd so zoznamom prpustnch kdov a rozhodn, i bude umonen prstup.
V kladnom prpade riadiaca jednotka vyle impulz koncovmu zariadeniu (efektoru) teda
samotnmu zmku, ktor sa odomkne. Zloitejie jednotky mu by doplnen o logovanie,
prpadne in spracovvanie a vyhodnocovanie dajov alebo o komunikciu s inmi systmami,
napr. s EZS a pod.[3]
7.4.1.4 Bezpenostn uzamykacie systmy
Pod bezpenostnmi uzamykacmi systmami rozumieme najm trezory, stabiln komorov
trezory, bezpenostn schrnky, bezpenostn kufrky, bezpenostn klietky a in pecilne
zariadenia, ktor umouj uzamkn predmet, ktor maj chrni, napr. kble na uzamknutie
prenosnch potaov a pod.
Trezorom je, poda zdroja [1], priestor ohranien pecilnou kontrukciou, ktor zaruuje
maximlne dosiahnuten bezpenos pre vntri uloen hodnoty (cenn predmety, dtov
nosie, peniaze, dleit doklady, listiny, perky, zlato alebo in cennosti) pred ich zneuitm
pokodenm, odcudzenm, alebo znienm. Musia ma zodpovedajcu trezorov zmku, priom
tto zmka, resp. systm zmky mus ma rovnak mechanick odolnos, t.j. mus by
v rovnakej bezpenostnej triede ako schovn objekt.
Rozdeuj sa do dvoch skupn:
Stabiln komorov trezory - s schovn objekty, ktor s pevnmi stavebnmi celkami

budov a doplnen pecilne kontrukne rieenmi trezorovmi dverami, maj vemi vysok
mechanick odolnos a prielomov odolnos tchto trezorov je zhodn s parametrami stien,
podlahy a stropov, rozdeuj sa na:
-
monolitick komorov trezory, ktor vznikaj priamo pri stavbe uloenm a spracovanm
betnovej zmesi so statickou a pecilnou vstuou do poadovanho tvaru,
panelov komorov trezory sa montuj priamo na stavbe z prslunch priemyslovo

vyrobench panelovch prvkov,
189
kombinovan komorov trezory, ktor vznikaj kombinciou predchdzajcich

stavebnch technolgi.
Mobiln trezory skriovho typu - s druhom schovnch objektov, ktor predstavuj vek
mnostvo rznych trezorov, pokladn, sejfov alebo skriovch trezorov, mu by rozdelen
do troch skupn:
-
komern schovn objekty a sejfy (prrun pokladniky, manipulan schrnky,

oceov skrine, ohovzdorn skrine, pokladnicov skrine, trezory na schovu dt, trezory
na zbrane a pod.),
vstavan trezory s spravidla jednoplov trezory uren na zamurovanie,
skriov trezory s pouvan predovetkm v bankovnctve, s kontruovan ako

viacplov so elezobetnovou vplou.
U trezorov s vym stupom bezpenosti (napr. pancierov pokladne) je do vplne vkladan

liatinov pancier, prpadne iaruvzdorn alebo meden doska.
Okrem klasickch trezorov je mon poui aj trezory, ktor s namontovan napr. do osobnch
alebo itkovch automobilov, prpadne poui osobn bezpenostn kufrky, naprklad na
prepravu zlonch kpii dt do vzdialenej lokality (napr. banky).
Bezpenostn klietky a in produkty z kovovej sieoviny umoujce ich uzamknutie ponkaj
nie len ochranu prstupu k samotnm IKT umiestnench naprklad v rack-och, ale aj ochranu pre
rzne scenre, ako naprklad proti zrteniu a prevencii voi padajcim objektom.
Samotn klietky mu by pripevnen k reglu, alebo pouit vertiklne ako oplotenie
a ukotven k podlahe, ako redukcia rizika vyplvajceho z pouvania vysokozdvinch vozkov,
alebo vonch predmetov padajcich z paliet v regloch.
Sieov ochrana je preto vhodn pre pouitie v bench skladoch rovnako ako v chladiarenskch
a mraziarenskch skladoch a najm v datacentrch so spolonm priestorom pre viacero
pouvateov.
Toto rieenie sa vyuva najm v dtovch centrch, kde sa v rmci jednho priestoru, resp.
miestnosti me nachdza viacero rack-ov viacerch subjektov, take je potrebn zamedzi
neoprvnenmu prstupu ud, najm administrtorov jednho subjektu k IKT inho subjektu.
7.4.2
Technick zabezpeovacie prostriedky (TZP)
Zkladnm rozdielom medzi mechanickmi zbrannmi prostriedkami a technickmi

zabezpeovacmi prostriedkami, ktor je zrejm aj z ich samotnho nzvu (zbrann vs.
zabezpeovacie), je skutonos, e technick zabezpeovacie prostriedky nedoku zabrni
prpadnmu narueniu alebo zneuitiu IKT zariaden. Doku chrnen priestor zabezpei, t.j.
identifikova prpadn naruenie alebo konkrtnu hrozbu, doku o tejto skutonosti informova
fyzick ochranu alebo policajn zbor, ale nedoku jej zabrni, aj ke meme poveda, e
v uritch prpadoch sa o to pokaj. Mme na mysli najm pouitie sirn s intenzitou zvuku za
prahom bolesti (viac ako 120 dB), prpadne pouitie inch, pre loveka neprjemnch,
technolgii alebo prostriedkov (napr. blikajce intenzvne svetlo, mikrovlnn iarenie pecifickej
vlnovej dky vyvolvajce u loveka pocit neprimeranho tepla a pod.), ktor maj za cie
odradi naruitea od alieho kodlivho konania a printi ho opusti chrnen priestor.
Technickmi zabezpeovacmi prostriedkami sa rozumej najm:
systmy na kontrolu vstupov do objektov a systmy sliace na elektronick preukazovanie

totonosti a oprvnenosti osb,
elektrick zabezpeovacie systmy (poplachov systmy na hlsenie naruenia),
elektrick poiarna signalizcia, prpadne vrtane automatickho poiarneho systmu,
190
kamerov systmy (i u s prenosom obrazu mimo chrnen priestor, napr. na PCO alebo
s uzatvorenm televznym okruhom v rmci chrnenho priestoru),
tiesov systmy a tiesov tlaidla,
zariadenia na detekciu ltok a predmetov,
zariadenia fyzickho nienia nosiov informci.
7.4.2.1 Systm kontroly vstupu

Systm kontroly vstupov je systm obsahujci technick a organizan opatrenia vrtane tch,
ktor sa tkaj zariaden potrebnch na riadenie vstupov. Zkladn funkcie systmu kontroly
vstupov s spracovanie, napjanie, samoochrana, programovatenos, ovldanie miesta prstupu,
identifikcia, zobrazovania, hlsenie a prpadne komunikcia s ostatnmi systmami.
lohou systmu kontroly vstupu je najm rozhodn, kto m povolen vstup, kde me by
prstup zskan, kedy je prstup povolen (ak systm tto funkciu poskytuje) a minimalizova
riziko nepovolenho vstupu. [1].
7.4.2.2 Elektrick zabezpeovac systm
Elektrick zabezpeovac systm je poplachov systm pre detekciu a indikciu prtomnosti,
vstupu alebo pokusu o vstup naruitea do strench objektov. Zkladn zostavu EZS tvor:
streda, jeden alebo viacej detektorov, jedno alebo viacej signalizanch zariaden prpadne
poplachovch prenosovch systmov, jedno alebo viacej napjacch zariaden, ktor mu by
kombinovan s inmi komponentmi EZS alebo s realizovan samostatne.
streda EZS je zariadenie pre prjem, spracovanie, ovldanie, indikciu a inicializciu
nslednho prenosu informci. asto m inteligentn spsob komunikcie medzi snmaom
a stredou, t.j. je pravidelne kontrolovan dostupnos a neporuenos snmaa, pri rdiovom
prenose me by sledovan prpadn ruenie a samotn komunikcia bva spravidla ifrovan.
Vetky druhy snmaov, magnetickch kontaktov a tlaidiel, mu by paralelne pripojen
a sasne sledovan pomocou dvojvodiovho vedenia vrtane ich okamitho stavu i ochrany
proti saboti. Me tie umoova programovanie a archivovanie dt prostrednctvom
potaa.
Detekn systm je zariadenie a elektrick intalcia, ktor sa pouva na prenos informci zo
siete automatickch detektorov prtomnosti nebezpeenstva. Poda zdroja [4] je detektor
(snma) zariadenie na vytvranie poplachovch stavov ako odoziev na nedovolen vniknutie
alebo pokus o vniknutie do chrnenho objektu, resp. priestoru, in nedovolen innos
naruitea alebo myseln konanie naruitea.
Detektory samotn sa rozliuj najm technolgiou, resp. pouitm princpom na detekciu
naruenia, i u ide o detekciu pohybu, otvorenia okien alebo dver, rozbitia okien a pod.
Zkladn typy detektorov s:
Pasvne infraerven (PIR) detektory - s snmae, ktor vytvraj poplachov stav ako
odozvu na zmenu rovne snmanho infraervenho iarenia spsoben osobami
pohybujcimi sa v snmanom priestore.
Infraerven zvora - je tak detekn zariadenie, ktor vytvra poplachov stav ako odozvu
na preruenie la infraervenho iarenia medzi vysielaom a prijmaom.
Detektory pohybu zaloen na inej technolgii:
dopplerovsk ultrazvukov detektor, ktor vytvra poplachov stav ako odozvu na

frekvenn posun ultrazvukovho iarenia od pohybujcej sa osoby,
dopplerovsk mikrovlnn detektor, ktor vytvra poplachov stav ako odozvu na

frekvenn posun mikrovlnnho iarenia po odraze od pohybujcej sa osoby,
alie pecilne druhy detektorov:

191
zahaj napr. detrukn detektory, ktor s schopn poda svojich kontruknch

vlastnost alebo spsobu intalcie iba jednorazovej detekcie,
pasvny detektor rozbitia skla - je detektor so snmacm prvkom pripevnenm na povrchu

sklenej tabule, ktor deteguje otrasov vlny riace sa sklom od momentu rozbitia,
signaliztor rozpojenia magnetickch kontaktov (magnetick detektor) - je tak detektor,

ktor vytvra poplachov stav ako odozvu na definovan zmenu magnetickho poa v
jeho bezprostrednej blzkosti spsoben naruenm chrnenho priestoru,
perimetrick systmy umoujce strenie plotu pomocou bezdrtovch akceleranch

RFID detektorov pripevnench na pletive, ktor doku detegova demont senzorov,
prestrihnutie plotu, pomal naklonenie, a pod.
Sasou EZS bvaj v pecifickch prpadoch aj tiesov hlsie (spravidla skryt tlaidlov
tiesov hlsie, prpadne pecilne kdy, ktorch pouitie vyvol tzv. tich poplach) uren
na manulne vytvranie poplachovho stavu osobami, ktor sa nachdzaj v stave ndze alebo
ohrozenia, a ktor s oboznmen s ich obsluhou.
7.4.2.3 Elektrick poiarna signalizcia
Elektrick poiarna signalizcia (EPS) je sbor hlsiov poiaru, stredn EPS a doplujcich
zariaden EPS, vytvrajci systm, ktor sli na preventvnu ochranu objektov pred poiarmi
tak, e akusticky a opticky signalizuje vznik a miesto poiaru. EPS samoinne alebo
prostrednctvom udskho initea urchuje odovzdvanie informci o poiari osobm,
urenm na vykonvanie hasiaceho zsahu. Zkladn zostava EPS pozostva z hlsiov poiaru,
hlsiovch liniek, stredn EPS, signalizanch liniek a doplujcich zariaden (signalizan
zariadenia, zariadenia diakovho prenosu informci, ovldacie jednotky, napjacie zariadenie a
pod.). Elektrick poiarna signalizcia mus identifikova najmenej jeden fyziklny jav alebo
chemick jav spsoben poiarom v strenom priestore, akusticky alebo opticky signalizova
poplach v strenom priestore a ovlda zariadenia, ktor s na u napojen. [5].
Okrem detektorov poiaru sa pouvaj aj tzv. plynov hlsie (ide o hlsie citliv na vskyt
konkrtnych plynov v rmci definovanho priestoru) a manulne tlaidlov hlsie elektrickej
poiarnej signalizcie, ktor sa pouvaj na run signalizovanie poiaru.
Systm poiarnej ochrany vak nemus by tvoren len uvedenmi prvkami a hlsimi, i u
optickho, teplotnho alebo manulneho charakteru, ale me by doplnen aj o automatick
hasiace zariadenie s prslunm typom hasiaceho mdia poda toho, o sa v chrnench
priestoroch nachdza a najm poda toho, i sa hasia priestory, kde sa nachdzaj udia alebo len
IKT zariadenia.
7.4.2.4 Kamerov systmy
Kamerov zostava v rmci uzatvorenho televzneho okruhu (tzv. CCTV - Closed Circuit
Television uzavret televzny okruh) je systm uren na video kontrolu, resp. monitorovanie
chrnench priestorov a objektov. Videozznam sa spravidla nahrva aby umooval aj sptn
monos, kontroly, resp. zistenie podrobnost o incidente. Kovou vlastnosou tchto systmov
ja najm citlivos a rozlenie pouitch kamier, resp. prslunch snmaov. V praxi sa pouva
vea typov snmaov zaloench na rznych technolgich, ktor umouj snmanie aj pri
zhorench podmienkach viditenosti, prpadne sa pouvaj v kombincii s prisvietenm, i u
vo viditenom alebo infraervenom spektre.
7.4.2.5 Zariadenia na fyzick nienie dtovch nosiov
Pri spracovan a nslednej potrebe znienia citlivch dt je potrebn poui zariadenie na fyzick
nienie dtovch nosiov. Uveden poiadavka je napr. definovan aj zkonom
. 395/2002 Z. z. o archvoch a registratrach. Na tento el s uren pecilne zariadenia,
ktorch efektivita je klasifikovan poda citlivosti dajov nachdzajcich sa na prslunch
nosioch, ktor sa maj znii. Dnes u existuj samostatn pecilne skartovacie zariadenia
v zvislosti na type mdia, ktor sa ma znii.
192
Ben skartovacie stroje skartuj spsobom, ktor postauje potrebm bench uvateov.
Pokia je citlivos informcii vyia, je potrebn poui u tak zariadenie, ktor zabezpeuje, e
benmi prostriedkami nie je mon skartovan materil zostavi do itatenej podoby. Pre
potreby vysokho zabezpeenia sa pouvaj zariadenia, kde skartovan materil me by
iastone zostaviten len s pouitm pikovch technolgi. Samozrejme s k dispozcii aj
zariadenia, kde skartovan materil je stopercentne nezostaviten.
7.4.3
Podporn infratruktra
Prvky podpornej infratruktry nezabezpeuj IKT z pohadu ochrany proti myselnmu

narueniu prpadnm tonkom. Mu vak minimalizova vplyv hrozieb nemyselnho
charakteru, ako napr. nemyseln zakopnutie a vytrhnutie dtovch kblov alebo kblov
napjania, a urite minimalizuj hrozby tkajce sa prrodnch vplyv a rznych porch IKT,
spsobench neprimeranmi podmienkami (napr. nevhodn teplota, vlhkos, alebo statick
energia, prpadne ruenie).
Zkladn prvky podpornej infratruktry tvoria najm:
dvojit podlahy alebo podlahy s antistatickou pravou,
serverov klimatizcia a tzv. studen a tepl uliky,
zlone zdroje napjania a genertory,
vedenia dtovch kblov a kblov napjania a dtov rozvdzae.
7.4.3.1 Dvojit podlahy

elom a dvodom na vybudovanie dvojitej podlahy je najm monos zabezpeenia prvodu
vzduchu pre ely chladenia, monos vedenia elektrointalcie a intalcie siet v relatvne
chrnenom prostred, ktor minimalizuje nemyseln preseknutie alebo vytrhnutie kblov
a monos umiestnenia rozvdzaov a dtovch alebo elektrickch zsuviek. Okrem tchto
dvodov je mon podlahovinu dvojitej podlahy upravi antistaticky (pre ely napr.
potaovch sl, vrobu elektroniky, alebo oblas telekomunikci) alebo vytvori
elektrostaticky vodiv podlahovinu uren pre aplikcie do priestorov s poiadavkou na
elektrostaticky vodiv prevedenie podlahy (napr. priestory s nebezpeenstvom vbuchu,
laboratri, RTG pracovisk, operan sly, a pod.). Dvojit podlaha m zrove aj vhodu
v prpade drby alebo zmeny, resp. rozirovan systmovch a komunikanch kapact, nakoko
umouje ahk prstupnos k elektrointalcii a intalcii siet a zrove poskytuje dostaton
flexibilitu tchto intalcii.
7.4.3.2 Serverov klimatizcia
V minulosti sa vo vine prpadoch v rmci chladenia serverovne pouvalo centrlne chladenie,
ktor chladilo miestnos ako tak a nezohadovalo sa rozloenie tepelnej zae. Rovnako
neboli implementovan technolgie, ktor by umoovali efektvnu regulciu chladenia do
jednotlivch rozvdzaov. S vvojom IKT a tandardov pre IKT sa samozrejme vyvjali aj
technolgie a tandardy pre dtov centr (Poznmka: O tandarde ANSI/TIA 942 - tandard
telekomunikanej infratruktry pre dtov centr, peme podrobnejie v samostatnej asti.),
ktor zefektvnili aj oblas a postupy tkajce sa chladenia IKT.
Klasick klimatizciu dnes u meme njs len pri starch serverovach. tandardn
klimatizcia poas svojej prevdzky vysuuje vzduch a tomuto sprievodnmu javu u nej nie je
mon zabrni. Niektor serverov miestnosti mu by citliv na takto znen vlhkos
vzduchu v priestore, pretoe such vzduch sa ahko elektrizuje, take me djs k pokodeniu
alebo znieniu IKT zariaden elektrostatickm vbojom.
V novch dtovch centrch sa dnes u urite stretneme s klimatizciou urenou pecilne pre
serverov miestnosti. Takto klimatizcia u doke serverov miestnos schladi rovnomerne
pomocou zdvojenej podlahy, ktor psob ako vzduchovod a otvormi pod servermi sa privdza
vzduch priamo na server s chladiacim vkonom poda jeho tepelnej produkcie. Takto chladenie
193
je ekonomickejie, pretoe chlad len konkrtny server a nie cel priestor. Navye vkon
klimatizcie je presne prertan na elektrick prkon a produkovan tepeln vkon jednotlivch
zariaden. Profesionlne klimatizcie do serverovch miestnost s schopn regulova okrem
teploty aj vlhkos vzduchu a udriava ju s mimoriadnou presnosou v blzkosti poadovanej
idelnej vlhkosti. Vina profesionlnych klimatizci urench do serverovch miestnost dnes
u doke chladi aj v takzvanom reime free-cooling von chladenie, to znamen, e
v obdob, kedy teplota vzduchu v exteriri poklesne pod cca +16C, prejde klimatizcia do tohto
reimu a chlad za pomoci kvalitne filtrovanho studenho vzduchu privdzanho vo vekom
mnostve z exteriru do interiru pomocou zabudovanej vzduchotechniky. Prevdzka
klimatizcie v reime vonho chladenia je energeticky mimoriadne nenron a v tomto reime
je mon uetri a 95% nkladov na chladenie v porovnan s prevdzkou tchto zariaden
v letnch mesiacoch.
Poda zdroja [6] sa v datacentrch pouva aj kompresorov chladenie. Jednotky s napojen na
niekoko nezvislch chladiacich okruhov. Such chladie na streche objektu zaisuj von
chladenie (tzv. freecooling) pri nzkych vonkajch teplotch, kedy je v klimatizanch
jednotkch pouvan glykolov vmennk miesto kompresorovho chladiaceho okruhu. Tm
dosahujeme a 60 percent spor elektrickej energie.
S ohadom na chlad a hluk sa v datacentrch stavaj oddelen sekcie v rmci serverovch
miestnost, z ktorch si pouvatelia mu konfigurova svoje servery, pre loveka v pohodlnom
kancelrskom prostred.
7.4.3.3 Studen a tepl uliky
K chladeniu prispieva smer prdenia vzduchu v serverovch miestnostiach systmom studench
a teplch uliiek. Chladn vzduch je rovnomerne distribuovan zdvojenou podlahou pribline
o vke 90 cm k rackovm skriniam z prednej strany. Ohriaty servermi je potom nasvan zo
zadnej strany rackov sp do klimatizcie prostrednctvom podhadu. Pre vyie tepeln zae
sa zavdza systm chladenia v zakrytch studench ulikch, pre extrmne zae s datacentr
vybaven rozvodmi pre pripojenie chladiacich jednotiek a chladench rackovch skr. [6].
Nasledujci obrzok graficky znzoruje tieto tepl a studen uliky. Tento obrzok je zo
spomenutho tandardu TIA-942, o ktorom budeme hovori v samostatnej kapitole. o je vak
dleit, je samotn fakt, e aj takto rove detailu je dnes predmetom tandardizcie, ktor
napomha dosiahnutiu prslunej rovne bezpenosti a ochrany IKT zariaden.
Obrzok 1: Tepl a chladn uliky poda TIA-942
194
7.4.3.4 Zlon zdroje a genertory

Zlon zdroje, tzv. UPS (Uninterruptible Power Supply), s zariadenia obsahujce najm
riadiacu jednotku a batriu, a ktor chrnia IKT v prpade vpadku hlavnho napjania. UPS
me zrove plni aj funkciu prepovej ochrany. Zlon zdroj, v prpade vpadku hlavnho
napjania, okamite zabezpe dodvku elektrickej energie z vntornch batri. Doba
zlohovania je priamo mern kapacite zlonho zdroja alebo nepriamo mern prkonu
zlohovanch zariaden. Teda o o vyia je za (vy prkon spotrebiov), tm niia je doba
zlohovania (doba, km zlon zdroj spotrebuje kapacitu vntornch batri). [7].
Okrem klasickch IKT zariaden ako s napr. serveri a sieov zariadenia sa dnes pouva vea
zariaden, ktor si z hadiska nepretritej prevdzky taktie vyaduj zlohovanie proti vpadku
prdu. Ide o zariadenia, ktor mu by dleitou sasou systmu fyzickej ochrany, take by
sme na ne nemali zabda pri vpote potrebnej kapacity UPS. Me s napr. o vrta na
elektrick pohon, ndzov osvetlenie, kamerov systmy, bezpenostn zmky, rzne riadiace
jednotky, automatick poiarny systm a pod.
UPS sa prevane pouvaj na zabezpeenie prevdzky pri krtkodobom vpadku napjania
alebo na zskanie asu potrebnho na korektn vypnutie IKT zariaden, aby nedolo k nhlej
strate dt. Pri prevdzke dleitch IKT, ktor si vyaduj nepretrit prevdzku nie je pouitie
UPS dostaton. V takomto prpade je potrebn poui elektrocentrlu.
Elektrocentrla alebo obecnejie benznov genertor, i benznov / diesel agregt predstavuje
kombinciu elektrickho genertora (alterntora) a motora, spojench do jednho zariadenia.
Okrem motora a alterntora elektrocentrla obvykle obsahuje palivov ndr, alej regultory
otok motora a naptia genertora, a nakoniec chladiaci, vfukov a mazac systm. Vie
elektrocentrly zvyajne maj batriu a elektrick tartr. pecilne upraven genertory, ktor
sa pouvaj ako zlon zdroje napr. v nemocninch zariadeniach, komunikanch strediskch,
dtovch centrlach, a inch dleitch zariadeniach sa spaj automaticky pri vysokom
zaaen elektrickej siete alebo pri jej vpadku. [8].
Zkladnm parametrom, ktor je pri genertoroch potrebn pozna je jeho vkon, ktor mus by
dostaton pre zsobovanie elektrickou energiou pripojench zariaden s definovanm prkonom.
Okrem toho je samozrejme dleit aj vstupn naptie a frekvencia naptia (v naich
podmienkach spravidla 230V alebo 400V a 50Hz).
7.5 Bezpenostn perimeter, chrnen objekt a chrnen priestor

Pod pojmom bezpenostn perimeter rozumieme vo veobecnosti priestor, nachdzajci sa okolo
stavebnho objektu, ktor spravidla kopruje hranicu pozemku patriacu k tomuto stavebnmu
objektu. Hranica tohto perimetra bva zabezpeen mechanickmi zbrannmi prostriedkami.
Chrnen objekt predstavuje stavebn objekt (budovu, halu, dom a pod.), ktorho pl je
zabezpeen mechanickmi zbrannmi prostriedkami.
Chrnen priestor je priestor vo vntri chrnenho objektu, ktor je spravidla stavebne alebo inak
ohranien a oddelen od okolitch priestorov nachdzajcich sa taktie vo vntri chrnenho
objektu, a ktor je zabezpeen mechanickmi zbrannmi prostriedkami.
tandardne sa implementcia mechanickch zbrannch prostriedkov a technickch
zabezpeovacch prostriedkov realizuje v rmci perimetra, ktor sa me, ale nemus nachdza
okolo chrnenho objektu, v rmci obvodu (pla) chrnenho objektu, vo vntri chrnenho
objektu v rmci chrnenho priestoru a v priamom okol chrnenho predmetu, resp. aktva.
Tomuto rozdeleniu zodpoved aj nasledovn zkladn rozdelenie typov ochrany:
Obvodov ochrana - zaisuje bezpenos okolo chrnenho objektu pouitm prslunch

MZP (napr. barira, plot, brna) a prpadne signalizuje naruenie perimetra objektu, ak s na
zabezpeenie perimetra pouit aj TZP.
195
Plov ochrana - zabrauje narueniu pla chrnenho objektu a vetkch vstupnch

a inch otvorov objektu pouitm prslunch MZP (napr. bezpenostn dvere a zmky,
mree, bezpenostn flie) a prpadne signalizuje naruenie pla chrnenho objektu, ak s
na zabezpeenie plovej ochrany pouit aj TZP.
Priestorov ochrana - zabezpeuje ochranu presne vymedzenho priestoru vntri chrnenho

objektu pouitm prslunch MZP (napr. bezpenostn dvere a zmky, spevnen prieky,
okenn zmky) a prpadne signalizuje javy s charakterom nebezpeenstva v chrnenom
priestore, ak s na zabezpeenie priestorovej ochrany pouit aj TZP.
Predmetov ochrana - zabezpeuje presne vymedzen priestory (miesta) vo vntri

chrnenho priestoru, v ktorch s uloen alebo sa nachdzaj chrnen predmety (aktva)
pouitm prslunch MZP (napr. trezor, bezpenostn schrnka, bezpenostn klietka),
najm pred ich odcudzenm alebo neoprvnenou manipulciou s nimi a prpadne signalizuje
naruenie tejto ochrany alebo pokus o naruenie, ak s na zabezpeenie predmetovej ochrany
pouit aj TZP.
Obrzok 2: Zkladn rozdelenie typov ochrany Zdroj: [9]

Okrem tchto zkladnch typov ochrany sa v praxi meme stretn aj s veobecnou definciou
ochrany objektu ako takho, ktor predstavuje shrn bezpenostnch, technickch a reimovch
opatren, ktor smeruj k prekazeniu akejkovek nepriateskej innosti proti objektu a osobm,
ktor sa nachdzaj v objekte, s cieom zabrni tokom na osoby a majetok, ktor smeruj
k poruovaniu stanovenho reimu, pokoja a poriadku.
V praxi sa asto hovor o tom, e tonk, ktor je motivovan, m dostatok asu, peaz
a prstupu ku zdrojom je schopn prekona ubovon ochranu. Jednou z najefektvnejch
metd, ako tonkovi sai prekonanie zabezpeenia je implementcia viacrovovej ochrany.
S viacrovovou ochranou svisia aj tzv. bezpenostn zny, ktor v podstate predstavuj
pecifick, najm chrnen priestory. Tieto bezpenostn zny sa rozliuj rznou rovou
prstupu, poda toho, i do konkrtnej zny m ma prstup napr. verejnos, nvteva, zmluvn
pracovnci, intern pracovnci, alebo len zky okruh internch pracovnkov, prpadne len vedenie
spolonosti a pod.
Meme poveda, e redukcia rizika naruenia dvernosti, integrity a dostupnosti chrnench
aktv, nachdzajcich sa v prslunej zne, neoprvnenmi osobami, ktor do prslunej zny
nemaj povolen vstup, predstavuje jeden z primrnych elov vytvorenia bezpenostnch zn.
196
Klasifikcia tchto aktv zrove znamen aj in rove ochrany a zabezpeenia prslunej zny,
kedy tto ochrana a zabezpeenie mus odpoveda najvyiemu stupu aktva, ktor sa v zne
nachdza.
Vytvorenie zn zrove umouje lepiu a presnejiu identifikciu miesta naruenia, m je
mon zabezpei efektvnej a rchlej zsah napr. strnej sluby v prpade naruenia zny,
najm v zloitch a lenitch objektoch.
7.6 Umiestovanie a prstup k IKT

7.6.1
Umiestovanie IKT
Pod bezpenm umiestovanm IKT rozumieme sbor opatren, ktor je potrebn uplatni pri
samotnom umiestnen IKT, ktor eliminuj hrozby psobiace na IKT vyplvajce najm
z okolitho prostredia. Bezpen umiestnenie IKT je tak umiestnenie, ktor predchdza
myselnmu alebo nemyselnmu pokodeniu, znieniu alebo neautorizovanmu oboznmeniu
sa so spracovvanmi, ukladanmi alebo prenanmi dajmi v rmci IKT. Meme poveda, e
spsoby bezpenho umiestovania IKT tvoria doplnok k ochrane IKT realizovanej
prostrednctvom mechanickch zbrannch prostriedkov a technickch zabezpeovacch
prostriedkov.
Pri umiestovan IKT do konkrtneho prostredia v rmci prslunch priestorov organizcie je
potrebn vyriei najm zabezpeenie umiestnenia IKT do prostredia, ktor eliminuje rizik, ako
s napr. poiar, zplava, zatopenie z internch rozvodov vody, prpadne krenia alebo poiarneho
systmu, vytrhnutie alebo preseknutie kblov, mechanick pokodenie zariaden, ruenie a pod.
Z tohto dvodu je potrebn v rmci konkrtneho objektu vybra vhodn priestory pre
umiestnenie miestnosti najm pre serveri, ale aj pre alie zariadenia, najm sieov prvky
umiestnen na samostatnch poschodiach a rzne telekomunikan a in zariadenia. Z pohadu
monho ruenia je dleit, aby sa priestory nenachdzali v blzkosti napr. telekomunikanch
antn, alebo inch zariaden s vysokm vkonom elektromagnetickho vyarovania. Na rozdiel
od novo projektovanch budov, kde sa s uvedenmi skutonosami pota u v rmci projektu,
nemus by tto loha jednoduch, a najm lacn, pri existujcich budovch. Je preto potrebn na
tieto skutonosti pamta a zahrn prslun kritria do vberu objektu alebo priestorov v rmci
objektu, napr. pri sahovan organizcie verejnej sprvy, ktor v naich podmienkach bva dos
ast.
V prpade, e prslun miestnos bola vybran a prpadne aj patrine upraven (napr. dvojit
podlaha, ochrana pre vedenie kblov, poiarny systm), je dleit dodriava urit sprvne
zsady a pravidl aj v rmci samotnej prevdzky, aby sa rizik, ktor sme eliminovali
umiestnenm IKT do patrinch priestorov nezvili naim nedbanlivm alebo neodbornm
sprvanm. Ide najm o umiestovane alebo ponechanie horavch materilov v priestoroch
serverovne (napr. kartnov obaly so zariaden), neprimeran otvranie okien alebo zabudnutie
ich zatvorenia, nemyseln vytrhnutie alebo preseknutie kblov a pod.
Okrem uvedench zkladnch pravidiel, tkajcich sa najm IS a podpornch zariaden, je
potrebn pamta na bezpenos vetkch typov IKT. V prpade spracovvania citlivch
informci s vysokou hodnotou pre organizciu je rovnako dleit pamta aj na pracovn alebo
prenosn potae a najm ich obrazovky alebo monitory. Vzhadom na neoprvnen
odpozorovanie citlivch informci, napr. na obrazovke potaa, alebo odchytenm neiaduceho
elektromagnetickho vyarovania, je potrebn umiestni tieto IKT zariadenia spsobom, ktor
eliminuje uveden riziko. V prpade elimincie rizika odpozorovania by obrazovky nemali by
umiestnen smerom k oknu, ak je na obrazovku viditenos napr. z protiahlej budovy, alebo
smerom do spolonch priestorov a ku dverm, ak je napr. priestor oddelen sklenenou priekou
alebo vplou, prpadne by nhly a neoakvan neoprvnen vstup do priestoru mohol
znamena oboznmenie sa s dajmi na obrazovke.
Elimincia rizika neiaduceho elektromagnetickho vyarovania je mon umiestnenm zariaden
do priestorov, ktor s od okolitho sveta oddelen dostatone hrubmi stenami, ktor doku
197
toto vyarovanie pohlti, napr. sutern budov, alebo pravou okolitch stien, podlahy a stropu,
vytvorenm tzv. Faradayovej klietky. Poslednou z monch prav je pouitie pecilneho a na
tento el vytvorenho zariadenia, tzv. chrnenho potaa. Bliie o tejto problematike sa
meme dota v asti 7.7.2.
Vetky IKT by samozrejme mali by umiestnen v priestoroch, ktor poskytuj dostaton
monosti na realizciu vetkch navrhnutch opatren, i u z pohadu hrozieb prostredia alebo
neoprvnenho prstupu (v prpade, ak ich pouitie a opodstatnenos je nutn a vyplva z analzy
rizk). Ide najm o dostaton fyzick miesto napr. pre intalciu uzamykatench klietok,
monos
vybudovania
alebo
intalcie
potrebnch
mechanickch
zbrannch
prostriedkov, intalciu technickch zabezpeovacch prostriedkov, intalciu napjacch kblov
pre MZP a TZP a intalciu dtovch kblov pre TZP, elektrointalciu a intalciu dtovch
rozvodov, ale aj intalciu akejkovek inej podpornej infratruktry, napr. vybudovanie dvojitej
podlahy vzhadom na vku miestnosti, umiestnenie zlonch zdrojov a prpadne aj zlonho
genertora, umiestenie a mont poiarneho systmu a jeho asti a pod.
7.6.2
Prstup k IKT
Kad objekt, kde sa predpoklad prstup verejnosti, by mal ma vylenen a jasne ohranien
vstupn znu prstupn verejnosti. Tto zna by mala by jasne oddelen od ostatnch zn, kde
vstup do tchto zn by mal by patrine zabezpeen, riaden a kontrolovan.
Na urenie, resp. identifikciu toho, i osoba m oprvnenie pre prslun rove sa zvykne
pouva farebn rozlenie jednotlivch zn, kde tomuto rozleniu zodpoved aj farebn
prevedenie identifikanch prveskov alebo kariet, ktor zamestnanci, zmluvn pracovnci alebo
nvtevy nosia na viditenom mieste a spravidla (okrem nvtev) tento identifikan prvesok
obsahuje aj fotografiu oprvnenej osoby. Identifikcia nvtev je realizovan kontrolou
a evidenciou osb, spravidla na vrtnici, alebo recepcii organizcie, na zklade ich
identifikanch dokladov (obiansky preukaz, alebo in relevantn doklad s fotografiou).
Nsledne pridelen, doasn identifikan karta bva oznaen slovom Nvteva a ako u bolo
uveden zvykne by aj farebne odlen. Pokia m by opatrenie v podobe zavedenia
identifikanch kariet alebo prveskov inn, musia nosenie na viditenom mieste tchto
identifikanch kariet dodriava vetci zamestnanci, vrtane lenov vedenia. V opanom
prpade by si nvteva, ktor nie je sprevdzan, mohla tto identifikan kartu schova a tm sa
neoprvnene vydva za legitmneho zamestnanca. Okrem tohto opatrenia, sa samozrejme,
vzhadom na charakter objektu a stupe klasifikcie chrnench aktv, odpora nvtevy
sprevdza oprvnenou osobou poas celho pohybu v rmci chrnenho objektu.
Uveden opatrenia je mon podpori aj almi organizanmi, prpadne technickmi
opatreniami, ako je napr. overenie identifikanho sla obianskeho preukazu v databze
stratench a ukradnutch obianskych preukazov, kontrola obsahu prenanch vec, kontrola
detektorom kovov a pod.
Pokia ide o prstup osb, ktor maj na starosti drbu v zmysle upratovacch, alebo
opravrenskch innost, prpadne servis IKT zariaden, tieto osoby by mali ma limitovan
prstup ku zdrojom organizcie, na zklade uplatnenia princpu need to do, t.j. mali by ma
k dispozcii len tie zdroje, ktor nevyhnutne potrebuj k svojej prci.
Okrem vyie uvedenej zny pre nvtevy sa odpora vytvorenie samostatnej zny pre
pracovnkov drby alebo pomocnho personlu. Takto zna zrove zabezpeuje, e personlu
starajcemu sa o drbu nie je umonen prstup k chrnenm priestorom vo vntri chrnenho
objektu, ie do pecilnych a samostatnch zn, kde sa nachdzaj citliv aktva.
Tento limitovan prstup by zrove mal by zmluvne upraven (v tzv. SLA Service Level
Agreement) a pokia ide o prstup do priestorov, v ktorch sa nachdzaj citliv dta, je nutn
podpsa aj zmluvu o mlanlivosti (tzv. NDA Non Disclosure Agreement), ktor upravuje
podmienky mlanlivosti o citlivch informcich, a ktor zrove zavdza aj sankcie za prpadn
nedodranie dohodnutch pravidiel. Podobne ako pri sprevdzan nvtev, rovnak pravidlo sa
v pecifickch prpadoch odpora aj pri vstupe pracovnkov drby alebo servisu do chrnench
198
priestorov s citlivmi aktvami, ktor by mali by do tchto priestorov sprevdzan prslunou

oprvnenou a pouenou osobou.
Podobn pravidl sa odpora prija aj v prpade prstupu inch zmluvnch pracovnkov tretch
strn, ktor napr. vykonvaj priamo prevdzku alebo administrciu konkrtnych zariaden.
Vzhadom na pravideln, prpadne ast prstup tchto ud, s relatvne dlhm asom pobytu
(napr. poas celch pracovnch hodn v rmci da), by vak bolo neefektvne ich sstavn
sprevdzanie. V tomto prpade sa k takmto pracovnkom pristupuje spravidla ako k vlastnm
zamestnancom s tm, e podmienky ich prce, vstupu, oprvnenia, povinnost, innost a lohy
by mali by upraven a oetren v zmluve medzi organizciu a prslunou treou stranou
a povinnos mlanlivosti by mala by oetren v individulnych zmluvch medzi organizciu
a prslunm pracovnkom. V rmci reimovch opatren je potrebn zabezpei aby tto
pracovnci nemali vstup do inch chrnench priestorov alebo k inm aktvam organizcie, ktor
nepotrebuj k svojej prci. Za tmto elom sa odpora podpori reimov opatrenia rznymi
technickmi prostriedkami, napr. systmom kontroly vstupu, intalovanm napr. uzamykatench
klietok, implementciou logovania, zaznamenvania a pravidelnho vyhodnocovania ich pohybu
a pod.
7.7 pecifick opatrenia

Riadenie informanej bezpenosti v oblasti fyzickej bezpenosti nie je len o implementci
mechanickch zbrannch prostriedkov, technickch zabezpeovacch prostriedkov a prpadne
podpornej infratruktry v kombincii s implementciou opatren na sprvne umiestnenie IKT
zariaden. Efektvne riadenie mus okrem uvedench skutonost obsahova aj sadu najm:
organizanch opatren, t.j. smernc a internch predpisov pre:

-
narbanie a pouvanie MZP a TZP,
reim kov od fyzickch zmkov a spsoby ich uloenia,
reim obhliadok a obchdzok strnej sluby (ak je pouit),
reim kontroly a odkladania nebezpench predmetov alebo nosiov informci,
vykonvanie kontrol dodriavania opatren,
vykonvania kontrol funknosti implementovanch prostriedkov a opatren a pod.,
veobecnch opatren na ochranu aktv, ako je napr.:

-
politika istho stola,
uzamykanie prenosnch potaov,
narbanie a ochrana dokumentov a pod.,
opatren na ochranu aktv v prpade prce mimo priestorov organizcie, ktor zahaj najm:
-
ochranu prenosnch mdi,
pouvanie mobilnch zariaden,
pripjanie mobilnch zariaden do internej siete organizcie.
V rmci uplatnenia politiky istho stola a istej obrazovky by organizcia mala

implementova urit zkladn pravidl a poiadavky na svojich zamestnancov, pouvateov
IKT zariaden, ktor by mali by jasne pecifikovan v prslunch smerniciach. Jednm zo
zkladnch pravidiel je, aby vytlaen dokumenty nezostvali v tlaiarni, ale je potrebn
zabezpei ich bezodkladn prevzatie, prpadne technologicky zabezpei fyzick vytlaenie a
po prchode ku tlaiarni, napr. pomocou ID tokenu, i u v bezkontaktnom alebo kontaktnom
preveden. V tomto prpade je vak potrebn technick podpora na strane tlaovho servera
199
a samotnch tlaiarn. alm dleitm pravidlom je, e pri opusten kancelrie alebo
pracoviska zamestnancom, by na stole nemali zostva, nijak dokumenty (informcie), ktor by
prpadn naruite mohol zneui. Je preto potrebn tlaen dokumenty, alebo nosie informci
(CD, DVD, USB tokeny) uzatvori do prslunho loiska (uzamykaten skrinka, schovn
objekt - trezor, a pod.). Preventvnym opatrenm pred nhodnm naruiteom, v tomto prpade
zlodejom, je aj implementcia uzamykania prenosnch potaov kblom o stl alebo in pevn
as v rmci pracoviska. Dleitm zkladnm pravidlom, ktor je potrebn uplatni vdy pri
opan pracovnho miesta, je zabezpeenie informanch aktv, s ktormi pracuje pracovn
stanica alebo prenosn pota, uzamknutm obrazovky tohto zariadenia, kedy je nsledne na
optovn pouitie potrebn zadanie prslunho hesla pouvatea.
Monosti prce z domu, resp. od klienta, ktor svisia s rozvojom technolgi prenosnch
potaov a rozvojom rieen vzdialenho prstupu umonili pouvateom vytvra hodnoty
relevantn predmetu innosti organizcie aj z prostred mimo fyzickch priestorov tejto
organizcie. Pokia sa v organizcii vyuvaj akkovek mobiln zariadenia, v ktorch sa mu
nachdza citliv aktva, alebo prostrednctvom ktorch je mon pripoji sa do internej siete
organizcie a tm zska prstup k citlivm aktvam, je potrebn uplatni na tieto mobiln
zariadenia podobn pravidl, ako boli uveden v predchdzajcom odseku. Napr. smart
telefny alebo tablety by mali by rovnako odkladan do uzamykatench skriniek, alebo by si
ich mal pouvate pri opusten pracoviska bra zo sebou, a taktie by na nich mali by
implementovan opatrenia uzamknutia displeja, prpadne klvesnice, vyadujce si zadanie PIN,
alebo hesla na ich optovn pouitie.
Mobiln zariadenia vak vo veobecnosti mu predstavova zven riziko zneuitia, i u ako
nstroja na vynanie citlivch informci z organizcie, alebo ako zdroja informci v prpade
ich ukradnutia alebo straty. Preto by malo by ich pouitie ako dtovho nosia limitovan
a pouvanie riaden jasnmi pravidlami. Intern koncept organizcie pre bezpenos mobilnch
zariaden a najm smartfnov, by mal zaha zavedenie systmu pre vzdialen manaovanie
tchto zariaden, tzv. Mobile device management, ktor riei ich bezpen pouvanie a zrove
ochranu aktv v prpade odcudzenia alebo straty tchto zariaden. Tento systm doke napr.
vynti ifrovanie dt nachdzajcich sa v pamti zariadenia alebo na pevnom disku, pouvanie
PKI identifikcie a autentifikcie do firemnej siete prostrednctvom virtulnych privtnych siet
(VPN), kontrolova, i nebol naruen firmvr telefnu (tzv. jail break pri android zariadeniach),
vynti a aktualizova AV ochranu, kontrolova intalovanie nedovolenho SW, vymaza pam
zariadenia v prpade jeho straty alebo ukradnutia, prpadne lokalizova polohu zariadenia na
zklade GPS a pod. Koncept ochrany mobilnch zariaden by mal obsahova aj ochranu dt
nachdzajcich sa na prenosnch mdich, ako s najm USB ke a CD a DVD nosie,
s pouitm a prpadne aj vyntenm pouitia nstrojov na ich ifrovanie. Tieto a alie opatrenia
bvaj spravidla implementovan IT oddelenm ako povinn politika priamo pri prvotnej
intalci operanch systmov a prslunch aplikci na pouvatesk potae a smartfny
a vinou nie s pod kontrolou pouvatea.
alie opatrenia organizanho charakteru by mali zaha najm hlsenie a spsoby hlsenia
bezpenostnch incidentov v svislosti so stratou alebo odcudzenm mobilnch zariaden
a samozrejme aj adekvtne reakcie na rchle rieenie zo strany zodpovednch osb (napr.
zablokovanie zariadenia, resp. jeho prstupu do internej siete, jeho vzdialen vymazanie slubu
konajcim opertorom a pod.). Dleitm faktom je upovedomenie zamestnancov, e pokia
nastane incident, je potrebn neodklada jeho nahlsenie. V prpade zistenia straty alebo
odcudzenia zariadenia je nutn rchla reakcia, ktor me zabrni alm kodm. Je dleit
neb sa ohlsi incident aj v takom prpade, ak by sa v konenom dsledku zistilo, e bol
bezpredmetn, napr. e zariadenie nebolo v skutonosti odcudzen, ale iba zaloen do vrecka
inch nohavc a pod. Tto skutonos bezodkladnho nahlsenia straty sa tka napr. aj
prstupovch kariet, ktor sa v organizcich asto vyuvaj na kontrolu a umonenie vstupu, i
u do samotnho objektu alebo aj do konkrtnych chrnench priestorov.
Okrem uvedench opatren je dleit aj evidencia a oznaovanie jednotlivch aktv
a definovanie pravidiel pre ich ochranu pri manipulcii s nimi. V tomto prpade hovorme
200
o podmienkach tzv. administratvnej bezpenosti, najm aktv, ktor maj charakter fyzickho
dokumentu, prpadne dtovho nosia. Ide najm o tvorbu tchto aktv, ich prjem, evidenciu,
prepravu, ukladanie, rozmnoovanie, vyraovanie a uchovvanie, prpadne in manipulciu.
V pecifickch prpadoch je mon zvi inok konkrtnych MZP alebo TZP pouitm
rznych inch pecilnych opatren. Ide napr. o intalciu tzv. bezpenostnho osvetlenia.
Bezpenostn osvetlenie bva intalovan ako podpora obvodovej ochrany. pecilne typy
svetiel mu by pouit ako odradzujci inok proti potencilnemu naruiteovi, prpadne sa
vyuvaj na prisvietenie pre strnu slubu alebo kamerov systm (najm za zhorench
svetelnch podmienok, kedy u tandardn citlivos snmaa kamery je nepostaujca) pre
monos videnia, o sa v danej oblasti deje, resp. kto, alebo o sa v tejto oblasti pohybuje. Me
s o svetlo vo viditenom spektre, prpadne o svetlo v infra-ervenom spektre. V pecilnych,
najm armdnych objektoch, mu by nasaden aj rzne in technolgie, ktor maj za cie
odradi loveka od alej innosti alebo ho donti opusti chrnen priestor. Ide napr.
o pouitie vysielaov mikrovlnnho iarenia pecifickej vlnovej dky vyvolvajce u loveka
pocit neprimeranho tepla, pouitie slzotvornho plynu, neprjemnch zvukov s intenzitou nad
hranicou bolesti udskho ucha a pod.
7.7.1
Rokovacie miestnosti - ochrana citlivch informci pri ich stnej prezentci
Problematika rokovacch miestnost je vhradnou zleitosou oblasti ochrany utajovanch

skutonost, ale rovnak princpy je mon poui aj v organizcich, ktor napr. vykonvaj
vskum alebo vvoj a potrebuj svoje know-how ochrni pred konkurenciou, take je mon
uplatni a implementova rovnak alebo podobn postupy a organizan opatrenia, prpadne len
niektor z nich.
V prpade, e sa na ochranu utajovanch skutonost proti nedovolenmu odpozorovaniu, ale
najm odposluchu bude budova pecilna miestnos, tzv. rokovacia miestnos, mala by spa
urit, alej pecifikovan podmienky a mala by sa taktie na tento pecifick chrnen priestor
spracova bezpenostn dokumentcia fyzickej bezpenosti a objektovej bezpenosti vyadovan
prslunou legislatvou.
Rokovacia miestnos je v podstate chrnen priestor uren na prerokovvanie a spracvanie
utajovanch skutonosti v podobe akusticko-optickej informcie, ktor je proti niku resp.
neoprvnenmu zznamu utajovanch skutonost zabezpeen komplexom bezpenostnch
opatren. Medzi zkladn formy zskania neoprvnenmu zznamu, ktorm sa sname zabrni,
patr akustick zaznamenvanie hovorov, optick zaznamenvanie hovorov, akusticko-optick
sledovanie, zachytenie a rekontrukcia parazitne vyiarench elektromagnetickch signlov
a kombincia uvedench foriem.
Komplex bezpenostnch opatren pozostva najm z:
jednoduchho zariadenia a vybavenia miestnosti len minimlnym a nutnm nbytkom

a zariadenm,
minimlneho a nutnho potu technickch prostriedkov v rokovacej miestnosti (z pouitia len

minimlnych a nutnch technickch prostriedkov chrnench proti NEV a certifikovanch
pre prslun stupe utajenia),
prpadnej intalcie elektroakustickch meniov s genertormi umu (na vetky mon

zvukovody a prechody, napr. klimatizciu, vetracie achty a pod. a steny rokovacej
miestnosti),
prpadnej intalcie piezoelektrickch meniov s genertormi umu na okenn tabule,
frekvennho scanera sliaceho na trval monitoring rdiovho frekvennho spektra poas

rokovania (ide najm o detektory rdiovho spektra, detektory aktvnych vysielacch
zariaden a aktvnych mobilnch telefnnych prstrojov, detektory intenzity
elektromagnetickho poa a pod.),
201
v odvodnench prpadoch intalcie vysokofrekvennej ruiky rdiotelefnneho signlu,
intalcie systmu zabezpeenia vstupu so systmom preukazovania totonosti osb

prslunej triedy prstupu a triedy rozpoznania,
intalcie kamerovho systmu na vstupe do rokovacej miestnosti v rmci uzatvorenho

televzneho okruhu, s vyvedenm vstupnho signlu na stanovite stleho vkonu strnej
sluby,
intalcia skartovacieho zariadenie spajce poiadavky na prslun bezpenostn stupe,
monosti zatemnenia okien (odpora sa poui bezpenostn reflexn flie, vo

vnimonch prpadoch mu by pouit okenice alebo zvesy, poprpade in vhodn
a postaujca forma zatemnenia okien),
zapeatenia a zabezpeenia (napr. uzamknutia) technickch prostriedkov a zsuviek

rozvodov,
okien zabezpeench alebo kontrukne rieench tak, aby ich nebolo mon otvori poas
rokovania,
intalcie bezpenostnch skriniek na odloenie osobnch vec a mobilnch telefnnych

prstrojov pred vstupom do rokovacej miestnosti,
intalcie detektora kovovch predmetov pred vstupom do miestnosti,
zabezpeenia poiadavky nemanipulova s inventrom miestnosti a zabezpeenia nemennosti

inventra miestnosti, pokia to nie je nevyhnutn,
vykonvania pravidelnch a nhodnch obrannch technickch prehliadok.
Medzi zkladn organizan opatrenia a zsady pobytu v rokovacej miestnosti patr

najm:
Pred rokovanm o utajovanch skutonostiach (zahjenm prce s utajovanmi informciami)

je potrebn:
-
skontrolova oprvnenos osb vstupujcich do rokovacej miestnosti,
skontrolova uloenie osobnch vec a mobilnch telefnnych prstrojov osb

vstupujcich do rokovacej miestnosti do bezpenostnej skrinky na to urenej,
zariadenm na detekciu kovovch predmetov skontrolova, i sa u niektorej z prtomnch

osb nenachdza zznamov zariadenie alebo in technick prostriedok na neoprvnen
zznam utajovanch skutonost,
skontrolova neporuenos peatenia technickch a komunikanch prostriedkov, ako aj

zsuviek vetkch rozvodov v rokovacej miestnosti,
skontrolova vypnutie vetkch nepotrebnch elektrickch spotrebiov a zariaden,
ak nie s okn vybaven bezpenostnou reflexnou fliou zatiahnu zvesy, prpadne

alzie alebo inm vhodnm spsobom zabezpei zatemnenie okien, aby nemohlo djs
k optickmu sledovaniu,
zapn ochrann a detekn zariadenia proti neoprvnenmu zznamu a skontrolova ich

funknos.
Poas rokovania o utajovanch skutonostiach musia by okn v rokovacej miestnosti

uzatvoren a je potrebn nepretrite kontrolova, prostrednctvom prslunch deteknch
zariaden, mon aktivovanie prostriedkov pre neoprvnen zznam a tie kontrolova
funknos tchto zariaden.
202
7.7.2
Elektromagnetick vyarovanie (EMV)
Podobne ako pecilne rokovacie miestnosti aj problematika neiaduceho elektromagnetickho

vyarovania je predovetkm fenomnom oblasti ochrany utajovanch skutonost. V praxi sme
vak zaznamenali aj prpady z bankovho sektora, kedy napr. neiaduce elektromagnetick
vyarovanie z ipu, ktor ovldal klvesnicu bankomatu, bolo tonkmi odchyten na
vzdialenos rdovo niekoko metrov, a na zklade nslednej analzy bol zskan PIN kd
pouvatea. Nsledne u len stailo zska kartu prslunej osoby, o v kombincii
s vreckovmi zlodejmi nebol iaden vek problm. Tento prklad dokazuje, e vyuitie toku
prostrednctvom tzv. postrannch kanlov, kedy jednm z tchto kanlov me by prve
elektromagnetick vyarovanie, me by poda ns relevantn aj mimo oblasti ochrany
utajovanch skutonost.
Poda zdroja [10] vetky elektronick a elektromechanick zariadenia uren na spracovanie
informci mu vytvra kompromitujce vyarovanie, ktor ak je zachyten a analyzovan,
prezrad vysielan, prijman alebo inm spsobom spracovvan informciu. Vo svete sa pre
ochranu pred tmto fenomnom pouva oznaenie TEMPEST. V SR sa pre uveden
problematiku pouva pojem ochrana pred neiaducim elektromagnetickm vyarovanm (alej
len "ochrana pred NEV"). Nevyhnutnos zabezpei ochranu utajovanch skutonost pred NEV
vyplva z 55 ods. 1 zkona 215/2004 Z. z. o ochrane utajovanch skutonost a o zmene
a doplnen niektorch zkonov. K tejto problematike vydal NB metodiku, ktor definuje
veobecn pravidl na zabezpeenie priestorov z hadiska ochrany pred neiaducim
elektromagnetickm vyarovanm. Cieom tejto metodiky je poskytn projektantom vo fze
projektovej prpravy veobecn pravidl, ktorch repektovanm je mon dosiahnu o najlepie
vlastnosti priestorov z hadiska ochrany pred neiaducim elektromagnetickm vyarovanm.
Zkladn pravidl definuj podmienky, kedy m priestor lepie vlastnosti z hadiska ochrany
pred NEV. Ide napr. o vekos samotnho priestoru (m je v kontrolovaten priestor, tm je
v elektromagnetick tlm priestoru, tm menie je riziko zneuitia neiaduceho vyarovania),
priestor dislokovan do podzemnch podla, priestor, ktor sa nachdza v strede objektu a je
obklopen almi stenami, priestor, ktorho steny s bez stavebnch otvorov, priestor, ktorho
steny s vej hrbky, priestor, ktorho steny s zhotoven zo svislho vodivho materilu
(napr. vodivo spojen kovov platne), a pod.
Okrem ochrany a zabezpeovania samotnch priestorov, v ktorch sa nachdzaj konkrtne IKT
zariadenia, je mon riziko neiaduceho elektromagnetickho vyarovania minimalizova aj
ochranou samotnch zariaden. V tomto prpade sa pouvaj spravidla certifikovan zariadenia,
ktor sami o sebe maj okolo seba tzv. Faradayovu klietku. Vaka tejto vlastnosti s odoln voi
TEMPEST tokom a je mon ich umiestni aj do priestorov, ktor by inak nevyhovovali
bezpenostnm poiadavkm na ochranu pred neiaducim elektromagnetickm vyarovanm.
7.8 Fyzick bezpenos dtovch centier

V svislosti so zabezpeenm a zvyovanm spoahlivosti dtovch centier je dleit definova
tandardizovan a kvantifikovaten pravidl, poda ktorch je mon jednotliv centr medzi
sebou objektvne porovnva a tm si vybra vhodn dtov centrum, poda poiadaviek
a potrieb prslunej organizcie, ie prevdzkovatea konkrtnych sluieb. Tto snaha je dleit
tie preto, aby sa na zklade tandardu mohol vytvori individulny intern pln budovania
a drby jednotlivch dtovch centier. Takto priemyseln tandard bol vytvoren obchodnou
asociciou pre telekomunikan priemysel TIA (Telecommunications Industry Association)
a jeho celoplon rozrenie vznamne prispieva k vyej rovni bezpenosti dtovch centier.
TIA je obchodn asocicia akreditovan ANSI (American National Standards Institute). V roku
2005 uverejnili dokument ANSI/TIA 942 tandardy telekomunikanej infratruktry pre dtov
centr, ktor definuj tyri rovne (zvan tier) dtovch centier. TIA-942 bol revidovan
v roku 2008 a neskr v roku 2010.
203
Meme poveda, e najjednoduchou rovou je tzv. Tier 1, ktor v podstate predstavuje

serverov miestnos spajca zkladn poiadavky na prostredie pre intalciu serverov.
Dostupnos sluieb tohto dtovho centra by mal by minimlne 99.671%. Nie je vyadovan
redundancia pre napjanie elektrickou energiou a chladenie. Me, ale nemus ma dvojit
podlahu, UPS, alebo diesel genertor. Akkovek preventvna drba si vyaduje plne vypnutie
data centra, take aj vetkch klientskch systmov, ktor s v om umiestnen.
Najprsnejou rovou je Tier 4, ktor je prispsoben pre prevdzku tzv. mission critical IKT
zariaden a systmov, s plne redundantnmi subsystmami a bezpenostnmi znami
s biometrickmi reimovmi opatreniami riadenia prstupu. Dostupnos sluieb dtovho centra
tejto rovne by mal by minimlne 99.995%. Obsahuje viaccestn aktvne napjanie elektrickou
energiou a viaccestn prvod chladenia. Zrove obsahuje redundantn komponenty, take
doke zvldnu najmenej jeden kritick incident bez preruenia sluby. Rovnako nie je potrebn
pozastavi klientsk systmy pokia je realizovan drba, nakoko redundancia prvkov pre
ely drby je dostaton na to, aby bolo mon prepn prevdzku na jednu as, km sa
realizuje drba na druhej asti.
TIA-942 je prvm tandardom, ktor pecificky adresuje infratruktru dtovch centier.
Primrne sa jedn o tandard telekomunikanej infratruktry, ale pribline polovica jeho obsahu
popisuje nroky na ostatn aspekty prostredia dtovch centier. Zrove poskytuje flexibiln
tandard truktrovanho kblovania pouitm tandardnch kblovch mdi.
7.9 Zver
Implementcia opatren a prostriedkov fyzickej bezpenosti nie je jednoduch zleitos, pretoe
m nezanedbaten vplyv na finann za organizcie. V idelnom prpade by ns tento
problm nemusel zaujma. V relnej praxi je vak vemi dleit implementova len skutone
nevyhnutn mechanick zbrann prostriedky, technick zabezpeovacie prostriedky a prvky
podpornej infratruktry, pretoe finann rozpoet na bezpenos bva znane obmedzen.
Nasadenie tchto prostriedkov by malo vyplva z analzy rizk, ktor pri analze samotnch
hrozieb a zranitenosti a ohodnoten rizk a najm monch dopadov mus zohadni aj hodnotu
chrnench aktv ako tak. Vade tam, kde je to vhodn je potrebn tieto prostriedky a prvky
podpori organizanmi opatreniami, ktor, ak s dobre navrhnut a efektvne vykonvan,
doku nahradi aj funkciu niektorch mechanickch alebo technickch prostriedkov.
204

[1]
Terminolgia bezpenostnho manamentu. vkladov slovnk. [Online] [Dtum: 24. 4

2013.] http://www.securityrevue.com/tbm/. Katedra bezpenostnho manamentu. Fakulta
pecilneho ininierstva. ilina.
[2]
MIKOLAJ, J. HOFREITER, L. MACH, V. MIHK, J. SELINGER, P.: Terminolgia

bezpenostnho manamentu, Vkladov slovnk., Koice, Multiprint s.r.o., 2004, ISBN 80969148-1-2
[3]
Elektronick k. [Online] [Dtum: 26. 7 2013.]

http://sk.wikipedia.org/wiki/Elektronick%C3%BD_k%C4%BE%C3%BA%C4%8D.
[4]
STN 33 4950 - Zariadenie poplachovch systmov na hlsenie naruenia. as 1 - 8.
[5]
Vyhlka MV SR . 726/2002 Z.z. ktorou sa ustanovuj vlastnosti elektrickej poiarnej

signalizcie, podmienky jej prevdzkovania a zabezpeenia jej pravidelnej kontroly.
[6]
Master DC - klimatizcia. [Online] [Dtum: 27. 9. 2013.] http://www.masterdc.sk/master-dcklimatizacie/.
[7]
Battery Import s. r. o. Zlon zdroje - nielen pre kancelrsk a vpoetn techniku. [Online]
[Dtum: 27. 9. 2013.] http://www.battery-import.cz/sk/zalozne-zdroje/?price_max=500.
[8]
EPROFI.SK s.r.o., Elektrocentrly. [Online] [Dtum: 27. 9. 2013.]

http://www.eprofi.sk/elektrocentraly.
[9]
Mach Vlastimil, Novkov Petronela. Aspekty prielomovej odolnosti mechanickch

zbrannch prostriedkov z hadiska potrieb projektu VEGA 1/098/11.
[10] Veobecn pravidl na zabezpeenie priestorov z hadiska ochrany pred neiaducim

elektromagnetickm vyarovanm. [Online] [Dtum: 27. 9. 2013.]
http://www.nbusr.sk/sk/oblasti-bezpecnosti/informacna-bezpecnost/neziaduceelektromagneticke-vyzarovanie.html. Nrodn bezpenostn rad.
[11] ANSI/TIA-942. tandardy telekomunikanej infratruktry pre dtov centr.
205
8 Kryptolgia I
Martin Stanek
8.1 vod
Cieom dokumentu je poskytn pragmatick pohad na kryptolgiu, s drazom na pouvan
kryptografick kontrukcie a ich svis s bezpenostnmi poiadavkami. Napriek tomu, e detaily
a vlastnosti kryptografickch kontrukci maj primrne matematick resp. informatick povahu,
obmedzme matematick strnku vkladu na minimum, aj za cenu niektorch zjednoduen.
Zujemcom o hlb pohad na tto problematiku mono odporui pecializovan odborn
literatru alebo vysokokolsk prednky.
Kryptolgia ako vedn oblas zaha kryptografiu a kryptoanalzu. Kryptografia sa venuje
nvrhu bezpenostnch kontrukci (vo forme algoritmov, protokolov a schm) s cieom
zabezpei ochranu bezpenostnch atribtov dt. Kryptoanalza skma monosti tokov na
kryptografick kontrukcie.
8.2 Zkladn pojmy, kryptografick kontrukcie a ich ciele

V tejto asti popisujeme zkladn kryptografick kontrukcie zabezpeujce dvernos, integritu
a autentickos (prpadne aj nepopieratenos autorstva) dajov. Zo zkladnch bezpenostnch
atribtov vynechme dostupnos, ktor kryptografia samotn zabezpei nedoke. Dostupnos
je otzkou vhodnej zvolenej redundancie dt, komponentov a pripojen, ako aj alch
technickch rieen a prevdzkovch postupov.
8.2.1
ifrovanie
Zkladn cie kryptografie je zabezpei dvernos dajov. Dvernos dajov sa zabezpeuje

ifrovanm, priom detaily konkrtneho rieenia sa obvykle lia poda toho, i sa ifruj daje
uloen na nosii dt (napr. disky, psky) alebo daje prenan potaovmi sieami.
ifrovanie transformuje daje pomocou ifrovacieho algoritmu a ifrovacieho ka do ich
ifrovanej/zaifrovanej podoby. Opan postup, teda zskanie pvodnch dt z ich zaifrovanej
podoby sa nazva deifrovanie a vyuva sa pri om deifrovac algoritmus a deifrovac k.
8.2.1.1 Symetrick ifrovanie
V prpade, e ifrovac a deifrovac k s rovnak, hovorme o symetrickch ifrch.
daje
ifrovanie
zaifrovan
daje
daje
deifrovanie
zaifrovan
daje
Najznmejm a najpouvanejm prkladom symetrickho ifrovacieho algoritmu je AES

(Advanced Encryption Standard). Z hadiska bezpenosti symetrickho ifrovania oakvame, e
tonk bez ka nie je schopn zo zaifrovanch dajov zska ich pvodn podobu napriek
tomu, e pozn ifrovac algoritmus. V sasnosti pouvanch ifrch je k vyberan ako
nhodn postupnos bitov pevnej dky. Naprklad AES m tri varianty, teda v podstate tri rzne
206
<Kryptolgia I | MF SR
ifrovacie algoritmy, liace sa okrem inho aj dkou pouitho ka: AES-128, AES-192,
AES-256. Nzov AES-n oznauje variant s n-bitovou dkou ka.
Dka ka je dleitm parametrom pre bezpenos ifrovacieho algoritmu ovplyvuje poet
potencilnych kov, ktor mus tonk vyska v prpade, e sa rozhodne prezrie priestor
vetkch kov. Kee takto tok plnm preberanm je mon vdy, je dleit aby poet
potencilnych kov znemooval efektvne vyskanie vetkch kov. V sasnosti mono
povaova ke s dkou 128 bitov (teda 2128 potencilnych kov) za dostatone bezpen,
pokia nie s bezpenostn slabiny v samotnom ifrovacom algoritme alebo v spsobe
generovania, distribcie a ochrany pouitch kov.
Z hadiska efektvnosti s symetrick ifrovacie algoritmy dostatone rchle na transparentn
ifrovanie a deifrovanie diskov osobnch potaov, komunikcie v potaovch sieach
a podobne, priom spomalenie spsoben takmto dodatonm spracovanm dajov je
zanedbaten. Viacer hardvrov zariadenia s v sasnosti kontruovan so zabudovanou
podporou pre kryptografick opercie, naprklad novie procesory obsahuj podporu pecilnych
intrukci pre implementciu AES.
8.2.1.2 Asymetrick ifrovanie
Samostatn trieda ifrovacch algoritmov vyuva na ifrovanie in k ako na deifrovanie,
priom deifrovac k nie je mon efektvne vypota zo ifrovacieho ka. V tomto prpade
hovorme o asymetrickom ifrovan, prpadne o ifrovan s verejnm kom. Ako nzov
napoved, ifrovac k (oznaovan aj ako verejn k) je zvyajne zverejnen a teda
ktokovek me ifrova. Deifrova je mon len so znalosou deifrovacieho ka (k bva
oznaovan ako skromn k). Najznmejm prkladom asymetrickho ifrovania je RSA.
Asymetrick ifry s kontruovan s vyuitm niektorch matematickch problmov. Svoju
bezpenos, teda napr. nemonos efektvne vypota skromn k z verejnho ka,
opieraj o zloitos rieenia tchto problmov. Ke v asymetrickch ifrch preto reprezentuj
konkrtne matematick objekty (a nie s to nhodne volen postupnosti bitov). Pri rovnakej
miere kryptografickej odolnosti ifry je dka kov asymetrickch ifier zvyajne podstatne
dlhia ako dka kov symetrickej ifry. Naprklad dka RSA kov 3072 bitov poskytuje
rovnak mieru kryptografickej odolnosti ako AES-128 113.
Z hadiska bezpenosti asymetrickho ifrovania oakvame, e tonk nie je schopn bez
znalosti skromnho ka zo zaifrovanch dajov zska ich pvodn podobu (alebo nejak
netrivilnu informciu o pvodnch dajoch). Pripomeme, e ifrovac k je verejne znmy,
a teda potencilny tonk m monos zaifrova ubovon daje.
8.2.1.3 Hybridn ifrovanie
Asymetrick ifrovanie a deifrovanie s z hadiska vpotovch nrokov ovea nronejie ako
ich symetrick nprotivky. S vhodn najm na ifrovanie krtkych dajov, tmi s najastejie
v praxi symetrick ke v tzv. hybridnch ifrovacch schmach. Hybridn ifrovacia schma
kombinuje symetrick a asymetrick ifrovac algoritmus nasledujcim spsobom:
113
Zdroj: NIST Special Publication 800-57 Recommendation for Key Management Part 1: General
(Revision 3), 2012.
207
Odosielate
symetrick k
K (nhodn)
daje M
symetrick
ifrovanie
verejn k
prjemcu
Prjemca
daje M
skromn k
prjemcu
asymetrick
ifrovanie
zaifrovan
k EK
symetrick
deifrovanie
asymetrick
deifrovanie
zaifrovan
daje EM
ifrovanie odosielate
Vstup: dta M, verejn k prjemcu
1. vygeneruje symetrick k K
2. zaifruje daje M symetrickou ifrou s
pouitm ka K (vsledok ozname
EM)
3. zaifruje k K asymetrickm
ifrovanm s pouitm verejnho ka
prjemcu (ozname EK)
Posielan daje (vstup): EK, EM
EK, EM
EK
EM
Deifrovanie prjemca
Vstup: EK, EM, vlastn skromn k
1. zska K deifrovanm EK, priom
pouije svoj skromn k
2. zska pvodn dta deifrovanm
EM, priom pouije k K
Vstup: M
Popis predpoklad posielanie dajov odosielateom k prjemcovi, avak hybridn prstup me

by pouit aj v prpade, e ifrovanie a deifrovanie vykonva rovnak osoba (vlastnk
skromnho ka) a dta s ukladan loklne, napr. na disk.
Vhodou hybridnho prstupu je efektvne ifrovanie, ke rozsahom vek daje s ifrovan
rchlym symetrickm algoritmom, priom zabezpeen distribciu symetrickho ka riei
asymetrick ifrovanie. Take jedin, o je potrebn zabezpei pred pouitm takejto schmy je
dveryhodn distribcia verejnho ka prjemcu. Verejn k je nemenn dlh as, napr.
jeden rok, a me by pouvan opakovane.
8.2.1.4 Porovnanie a pouitie
Typick rozdiely medzi symetrickm a asymetrickm ifrovanm sumarizuje nasledujca
tabuka:
208
Primrne pouitie
Komunikcia
Efektvnos
Dka kov
Distribcia kov
Symetrick ifrovanie
dvernos dajov ubovonho
rozsahu
Asymetrick ifrovanie
dvernos krtkych dt (typicky
napr. ke pre symetrick
ifrovanie)
1:1 obvykle dvaja astnci
N:1 ubovon poet
(jeden odosielate, jeden prjemca) odosielateov (ifrovac k je
verejn), jeden prjemca (skromn
deifrovac k)
rchle ifrovanie aj deifrovanie
pomal ifrovanie aj deifrovanie
obvykle 112 a 256 bitov (nhodn v zvislosti na konkrtnom
reazec bitov)
algoritme, niekoko sto a niekoko
tisc bitov
obvykle potrebn poui
relatvne jednoduch distribcia
kryptografick protokoly na
verejnho ka (avak potrebn
distribciu (dohodnutie) ka
overi jeho autentickos)
ifrovac algoritmus, i u symetrick alebo asymetrick, neposkytuje ochranu integrity ani

autentickosti prenanch dajov. Teda skutonos, e daje boli prenan/uloen zaifrovan
a spene sme ich deifrovali neznamen, e poas prenosu/uloenia zaifrovan dta neboli
tonkom zmenen.
Vnimkou s pecifick kontrukcie mdov symetrickch ifier, tzv. autentizovan ifrovanie.
V sasnosti s v praxi pouvan zriedkavo a na zabezpeenie integrity a autentickosti dajov s
pouvan in kryptografick kontrukcie.
ifrovanie mono njs v praxi vo vekom pote rznorodch aplikci. Uveme aspo niekoko
prkladov:
ifrovanie diskov osobnch potaov, kde sa daje transparentne pri tan z disku deifruj
a pri zpise na disk ifruj Bitlocker (tandardn nstroj v novch verzich operanho
systmu Windows, ifrovac algoritmus AES), TrueCrypt (multiplatformov aplikcia,
podpora viacerch ifrovacch algoritmov, okrem inch aj AES). Cieom takchto rieen je
zni riziko prezradenia dajov, napr. pri odcudzen prenosnho potaa.
ifrovanie komprimovanch zip archvov viacer aplikcie pre prcu so zip archvmi
umouj okrem komprimcie aj zaifrova vzniknut archvy s pouitm symetrickho
ifrovania (napr. 7-zip, WinZip pouvaj AES). ifrovac k je vypotan zo zadanho
hesla. Zaifrovan archv je nsledne mon deifrova a rozbali len s pouitm tohto hesla.
V prpade ad-hoc potreby posla citliv daje, priom nemme k dispozcii verejn k
prjemcu (alebo tento ani iadny verejn k nem), je asto najjednoduchm rieenm
daje zabali do ifrovanho archvu s pouitm dostatone silnho hesla. Nsledne archv
poleme prjemcovi mailom a heslo oznmime inm komunikanm kanlom (povedzme
SMS). Samozrejme, pokia doke tonk zska zaifrovan archv aj prenan heslo,
doke deifrova rovnako ako prjemca.
ifrovanie komunikcie v nezabezpeench sieach, napr. na Internete pri vyuvan
internetbankingu alebo pri prstupe na web strnky zabezpeujce e-mailov sluby.
Zabezpeenie komunikcie je v tchto situcich tandardne rieen protokolom TLS, ktor
okrem inch atribtov zabezpeuje aj dvernos prenanch dajov symetrickm
ifrovanm, priom konkrtny pouit algoritmus sa dohodne pri nadviazan spojenia medzi
internetovm prehliadaom a serverom.
8.2.2
Haovacie funkcie a autentizan kdy sprv
8.2.2.1 Haovacie funkcie

Kryptografick haovacie funkcie s algoritmy, ktor z ubovone dlhho vstupu vypotaj
209
hodnotu reazec bitov pevnej dky (ten nazveme odtlaok). Pre bene pouvan haovacie
funkcie m odtlaok dku 160 bitov v prpade haovacej funkcie SHA-1, 256 bitov v prpade
SHA-256 alebo 512 bitov v prpade SHA-512. lohou odtlaku je jednoznane reprezentova
vstupn daje/dokument.
Primrne pouitie haovacch funkci je v alch kryptografickch kontrukcich, naprklad v
autentizanch kdoch sprv, schmach digitlnych podpisov a pod. Haovacie funkcie
nevyuvaj iadny k a teda ktokovek vie vypota odtlaok k ubovonmu dokumentu.
Preto je samostatn pouitie haovacch funkci obmedzen len na detekciu naruenia integrity
dajov pri nhodnej (necielenej) zmene, alebo v situcich, ke tonk nem pln kontrolu nad
vetkmi komunikanmi kanlmi a neme okrem dajov modifikova aj ich odtlaok. V
opanom prpade tonk ahko dopota korektn odtlaok k pozmenenm dajom.
Uveme dva ilustran prklady pouitia haovacch funkci na kontrolu integrity:
Distribcia objemnch sborov (softvr, video a pod.) na internete, kde je na webovej strnke
zverejnen odtlaok takhoto sboru. Po stiahnut sboru me pouvate loklne vypota
jeho odtlaok a porovna hodnotu s odtlakom zverejnenm na internete. Rozdielnos
vypotanho a zverejnenho odtlaku signalizuje, e pri prenose dajov dolo k modifikcii,
naprklad spsobenej nespoahlivm prenosom alebo zmernou pravou. Samozrejme,
pokia tonk doke zmeni pri prenose nielen daje samotn, ale aj informciu o odtlaku
z webovej strnky, pouvate ni podozriv nespozoruje. Zdraznime, e haovacie funkcie
vo veobecnosti nezabezpeuj autentickos dajov.
Ochrana integrity sborov vypotanm ich odtlakov. Pokia odtlaky odlome (napr. na
neprepisovaten mdium), dokeme neskr optovnm vpotom odtlakov a ich
porovnanm s odloenmi hodnotami zisti, i a ktor zo sborov bol modifikovan. Kee
odtlaky s obvykle podstatne kratie ako zdrojov sbory, tento spsob ochrany poskytuje
len detekciu naruenia integrity a neumouje rekontruova pvodn obsah sborov (na
tento el sli zlohovanie). Na druhej strane je porovnvanie odtlakov prevdzkovo
jednoduchie ako porovnvanie celch kpi sborov.
Z hadiska rchlosti spracovania vstupu s haovacie funkcie porovnaten so symetrickmi

ifrovacmi algoritmami. Aby boli haovacie funkcie pouiten vo vyie uvedench aj
v alch kontrukcich oakvame, e haovacie funkcie maj vhodn bezpenostn vlastnosti.
Dve najzkladnejie vlastnosti s, e napriek znalosti haovacej funkcie:
z danho odtlaku nie je efektvne mon vypota dokument s takmto odtlakom,

nie je efektvne mon vypota dva rzne dokumenty s rovnakm odtlakom.
8.2.2.2 Autentizan kdy sprv

Autentizan kd sprvy (angl. Message Authentication Code, resp. MAC) je v podstate odtlaok
sprvy, pri vpote ktorho bol pouit k. Autentizan kdy sprv s teda aksi haovacie
funkcie s kom, priom asto s kontruovan prve z haovacch funkci. Najznmejou
kontrukciou je HMAC ide o veobecn kontrukciu, kde konkrtny algoritmus dostaneme
vobou podkladovej haovacej funkcie (napr. HMAC-SHA1).
210
sprva M
MAC
MAC = MAC ?
algoritmus
pre MAC
autentizan
kd MAC
M, MAC
algoritmus
pre MAC
Kee vpoet odtlaku zvis na ki, autentizan kdy sprv zabezpeuj autentickos
dajov. Samozrejme, len v prpade ak je k znmy len povolanm pouvateom. Najastejie
pouitie autentizanch kdov je pri ochrane komunikcie v potaovej sieti. V takom prpade
k zdieaj odosielate a prjemca. Pri posielan dajov k nim odosielate pripoj autentizan
kd. Prjemca vypota z prijatch dajov a ka autentizan kd a porovn ho s prijatm
autentizanm kdom. V prpade zhody je potvrden autentickos dajov. Pokia tonk
nepozn k pouit pri vpote odtlaku nedoke daje nepozorovane modifikova, lebo
nevie dopota korektn autentizan kd.
Dohodnutie/distribcia konkrtneho ka na takto el je zvyajne lohou nejakho
kryptografickho protokolu (naprklad TLS protokol dohodne k pre autentizan kdy pri
nadvzovan spojenia). Takmto spsobom je v sieovch protokoloch nsledne zabezpeovan
kad prenan paket algoritmy pre autentizan kdy sprv s dostatone rchle
(porovnatene so symetrickm ifrovanm).
Na druhej strane autentizan kdy nezabezpeuj nepopieratenos autorstva prenanch
sprv. Kee prjemca m k dispozcii rovnak k ako odosielate, autentizan kd
ubovonej sprvy doke vypota sm. To znamen, e odosielate doke poprie autorstvo
sprvy.
8.2.3
Digitlne podpisy
Schmy pre digitlne podpisy s asymetrick kryptografick kontrukcie, pozostvajce z

podpisovho algoritmu a z overovacieho algoritmu. Pouvate vygeneruje intanciu schmy
vygenerovanm dvojice kov skromnho a verejnho ka. Podpisov algoritmus vytvra
digitlny podpis z dokumentu a zo skromnho ka. Overovac algoritmus overuje korektnos
konkrtneho podpisu na zklade dokumentu a verejnho ka. Verejn k je obvykle
zverejnen a teda podpis me overi ktokovek.
Z dvodu efektvnosti aj z bezpenostnch dvodov nie je fakticky podpisovan dokument ako
tak, ale jeho odtlaok vypotan zvolenou haovacou funkciou. Preto je dleit, aby haovacia
funkcia spala vlastnosti spomnan v asti 2.2.1.
211
skromn
k
dokument M
dokument M
haovacia
funkcia
haovacia
funkcia
verejn
k
podpisov
algoritmus
overovac
algoritmus
M, podpis
podpis
podpis
Najznmejmi schmami pre digitlne podpisy s RSA a DSA (Digital Signature Algorithm).
Poznamenajme, e tandardn RSA podpisov schma sa od RSA schmy pre asymetrick
ifrovanie li vo viacerch implementanch detailoch. Napriek tomu je matematick povaha
asymetrickho pru kov rovnak a niekedy je jeden pr kov pouvan na oba ely (teda
v schme pre asymetrick ifrovanie aj v schme pre digitlne podpisy), hoci sa to neodpora.
Napriek tomu, e verejn k aj podpisov a overovac algoritmus s vone k dispozcii, nie je
efektvne mon bez znalosti skromnho ka vytvori k ubovonmu dokumentu korektn
podpis. To znamen, e digitlne podpisy poskytuj ochranu integrity a autentickosti dajov.
Navye, ak je pouvate jedin, kto m konkrtny skromn k, tak korektn digitlny podpis
dokumentu znemouje pouvateovi poprie vlastn podpis (hovorme o nepopieratenosti
autorstva). Samozrejme, praktick uplatnenie digitlnych podpisov si vyaduje vyriei
dveryhodn distribciu verejnch kov, monos vyhlsi neplatnos verejnho ka po
prpadnej kompromitcii skromnho ka a mnostvo alch praktickch otzok. Tie sa sna
riei tzv. infratruktra verejnch kov (PKI Public Key Infrastructure) aj s prslunm
prvnym rmcom 114.
Nasledujca tabuka porovnva zkladn charakteristiky haovacch funkci, autentizanch
kdov a digitlnych podpisov:
Haovacie funkcie
no
nie
Autentizan kdy
no
no
Digitlne podpisy
no
no
nie
nie
no
Ke
iadne
symetrick
Efektvnos
rchle
rchle
autentickos
jednotlivch paketov pri
prenose v sieti
Integrita
Autentickos
Nepopieratenos
autorstva
Typick aplikcia
kontrola integrity
statickch dt
asymetrick
pr kov
pomal
autentickos
dokumentov
8.3 Protokoly
Kryptografick protokoly s definovan ako postupnos krokov a vmen sprv medzi dvoma
alebo viacermi astnkmi, s cieom naplni dan/zvolen bezpenostn poiadavky, priom
114
V prostred SR je to zkon o elektronickom podpise a svisiace vyhlky NB SR.
212
vyuvaj rzne kryptografick kontrukcie.

Pokia spracovanie dajov zaha interakciu a prenos dajov medzi systmami alebo
pouvatemi, je z hadiska bezpenosti typicky potrebn zabezpei dve zkladn poiadavky:
1. Autentizcia komunikujcich astnkov teda kad astnk si over, e komunikuje
so elanm partnerom.
2. Dohodn a distribuova kryptografick ke, ktor sa v nslednej komunikcii pouij
na ifrovanie, vpoet autentizanch kdov, prpadne na zabezpeenie inch
bezpenostnch atribtov pomocou vhodnch kryptografickch kontrukci.
Uveden poiadavky napa najvznamnejia trieda kryptografickch protokolov protokoly pre
autentizciu a dohodnutie kov (tie s nsledne pouit na zabezpeenie alej komunikcie).
Prirodzene, obvykle s tieto protokoly vykonan pri nadvzovan spojenia. Najpouvanejie
protokoly tohto typu s TLS (Transport Layer Security, starie oznaenie SSL) a IPSec.
Prirodzene, autentizova astnka mono len na zklade nejakch dveryhodne distribuovanch
informci. Takou informciou me by verejn k, napr. vo forme certifiktu (najastej
spsob v prpade TLS) alebo zdiean tajn informcia dohodnut a distribuovan
dveryhodnm spsobom vopred (pomerne ast spsob v prpade IPSec). V prpade verejnho
ka dokazuje astnk svoju identitu tm, e preuke znalos prislchajceho skromnho
ka typicky podpe vhodn sprvu vyuijc svoj skromn k alebo je schopn deifrova
dta ifrovan s pouitm jeho verejnho ka.
Kee pouvate sa skr stretne s TLS ako s IPSec, navye je IPSec podstatne zloitejia
a variabilnejia sada protokolov, ilustrujme pouitie kryptografickch technk prve na TLS.
V TLS je pouit komunikan model klient-server, priom klient je ten astnk protokolu,
ktor zahajuje komunikciu, napr. webov prehliada pouvatea. V vode protokolu si klient
a server dohodn sadu nimi preferovanch a podporovanch kryptografickch technk. TLS
ponka ist flexibilitu pri vobe algoritmov a metd dohodnutia kryptografickch kov,
sksme sa preto zamera na jednu z monost, priom sa op nevyhneme istmu (znanmu)
zjednoduovaniu. Server pole klientovi svoj verejn k vo forme certifiktu podpsanho
nejakou certifikanou autoritou. Pokia m klient vhodnm spsobom zskan verejn k
certifikanej autority a dveruje jej, doke overi digitlny podpis na certifikte a tm
autentickos verejnho ka servera. Nsledne klient pouije zskan verejn k servera na
zaifrovanie dajov, z ktorch obaja odvodia kryptografick ke pre ifrovanie a vpoet
autentizanch kdov. Server daje deifruje pomocou svojho skromnho ka. Po zskan
kov je nadviazanie spojenia dokonen a vytvoren zabezpeen komunikan kanl je
k dispozcii aplikcii (teda napr. webovmu prehliadau).
Nasledujce obrzky ilustruj informcie o dvoch TLS spojeniach, jedno na web Ministerstva
financi SR a druh na vyhadva Google. Z uvedench informci si mono vimn rovnak
ifrovac algoritmus (RC4 so 128 bitovm kom) a rovnak verziu TLS protokolu (verzia 1.1).
Spojenia sa lia haovacou funkciou pouitou pre vpoet autentizanch kdov (MD5 vs. SHA1), mechanizmom pre vmenu ka (RSA vs. ECDHE_RSA) ako aj certifikanou autoritou,
ktor vydala certifikt verejnho ka webovho servera (RapidSSL CA vs. Google Internet
Authority).
213
Zkladn charakteristiky TLS s zhrnut v nasledujcej tabuke:

Autentizcia servera
Autentizcia klienta
Distribcia kov
Dvernos
Autentickos
prava aplikcie
vyuvajcej protokol
214
TLS (SSL)
povinn (znalos skromnho ka k verejnmu ku z certifiktu)
voliten (mlokedy pouvan, obvykle rieen po vytvoren TLS
spojenia)
viacer protokoly (odvodenie kov pre ifrovanie a autentizan kdy)
symetrick ifrovanie (podpora rznych algoritmov a mdov)
autentizan kdy (podpora rznych algoritmov)
zvyajne potrebn v aplikcii pecificky inicializova komunikan kanl
8.4 Hesl a kryptografick ke

8.4.1
Hesl
Hesl s najpouvanejm autentizanm prostriedkom. S prkladom autentizcie zaloenej na

znalosti, na rozdiel od autentizanch mechanizmov zaloench na vlastnctve (nieo o mte,
typicky rzne hardvrov tokeny) alebo identite (nieo m ste, typicky biometrick metdy).
Heslo je reazec znakov a obvykle ho vol pouvate sm. V niektorch systmoch/aplikcich
je obmedzen dka ako aj abeceda hesla napr. v prpade PIN kdov pouvanch pri
platobnch kartch alebo pri SIM kartch v mobilnch telefnoch.
Na bezpenos autentizcie vyuvajcej hesl vplva viacero faktorov, uveme tie
najvznamnejie:
Dka a nhodnos hesla m je heslo dlhie a nhodnejie, tm je niia

pravdepodobnos, e tonk heslo uhdne.
Spsob prenosu a overovania hesla heslo m by prenan cez komunikan kanl so
zabezpeenou dvernosou.
Spsob uloenia hesla na strane pouvatea v idelnom prpade si pouvate hesl
pamt, nezdiea hesl medzi rznymi systmami ani s inmi pouvatemi.
Spsob uloenia hesla na strane systmu (servera) hesl nie s uloen v otvorenom
tvare, pre znenie dopadov kompromitcie servera.
alie parametre autentizcie definovanie potu nespench pokusov zadania hesla,
po ktorom sa prstup pouvatea zablokuje (v prpade PIN kdov obvykle 3), vyntenie
zmeny hesla po definovanom ase a in opatrenia zniujce pravdepodobnos spenho
toku.
al spsob pouitia hesiel je odvodenie symetrickch kryptografickch kov. Predstavme si

naprklad situciu, e pouvate m svoj skromn k pre podpisov schmu uloen v sbore
na loklnom disku. Pre minimalizciu rizika kompromitcie ka je tento sbor zaifrovan.
Kee iadny pouvate si pravdepodobne nie je schopn zapamta o len 128 bitov dlh
nhodne zvolen symetrick k, tento sa v podobnch situcich odvod z hesla. Teda z hesla
zvolenho pouvateom je vypotan symetrick ifrovac k a ten nsledne pouit na
ifrovanie alebo deifrovanie sboru so skromnm kom. Podobne sa ke z hesiel
odvdzaj aj v inch situcich.
Samozrejme, nhodnos takto zskanho ka je niia ako keby bol volen skutone nhodne.
Na druhej strane je pouvate schopn si heslo zapamta. Bezpenos takhoto pouitia hesiel
ovplyvuje aj konkrtny algoritmus, ktorm sa heslo transformuje na k. Podobne ako pre in
kryptografick kontrukcie, aj v tomto prpade existuj vhodn tandardy.
Porovnanie odhadovanej nhodnosti pouvateskch hesiel (volench pouvateom) voi dke
nhodnho symetrickho ka je uveden v nasledujcej tabuke 115. Teda povedzme PIN dky
10 zloen z cifier 0-9 je pribline rovnako siln ako 15 bitov dlh symetrick k a heslo
dky 10 (zloen zo znakov 94 znakovej abecedy) je rovnako siln ako 21 bitov dlh
symetrick k.
115
Zdroj: NIST Special Publication 800-63-1 Electronic Authentication Guideline, 2011.
215
Dka hesla
4
8
10
16
22
PIN
10 znakov abeceda
[ekviv. dka ka v
bitoch]
9
13
15
21
27
Veobecn hesl
94 znakov abeceda
[ekviv. dka ka v
bitoch]
10
18
21
30
38
O sile pouvateskch hesiel je mon urobi si predstavu z tokov v relnom prostred. V roku
2012 bola publikovan databza odtlakov hesiel cca. 6,5 milina pouvateov sluby LinkedIn.
Jednoduch slovnkov tok bez pecilneho hardvru umonil v priebehu 4 hodn zisti hesl
cca. 900 tisc pouvateov. alie pokraovanie v slovnkovom toku viedlo pomerne skoro
celkovo k cca. 2 milinom zistench hesiel. Teda nezanedbaten as pouvateov vol
a pouva pomerne slab hesl.
8.4.2
Ke
Narbanie s kryptografickmi kmi je najvznamnejm faktorom ovplyvujcim bezpenos

kryptografickch kontrukci. Sprva kryptografickch kov zaha hlavne nasledujce
innosti:
1. Generovanie kov postupy vytvrania kov, vrtane pouitch zdrojov nhodnosti
(ke musia by nepredikovaten)
2. Distribcia kov spsob doruenia kov astnkom, vrtane naplnenia
bezpenostnch poiadaviek pri distribcii kov (ako s zabezpeenie ich dvernosti,
autentickosti a pod.)
3. Ukladanie a prstup ku kom (aj v prpadoch ich zlohovania a archivcie)
4. Nienie kov (po skonen ich pouvania)
Pri sprve kov je vhodn definova aj postupy pri kompromitcii alebo pri zneplatovan
kov, intervaly vmen kov a pod.
V prpade adekvtnej sprvy kov je bezpenos kryptografickch kontrukci uren hlavne
ich kryptografickou kvalitou a dkou pouvanch kov. Intitcie ako NIST, NSA (National
Security Agency), BSI (nemeck Bundesamt fr Sicherheit in der Informationstechnik) a in
vydvaj odporuenia pre vhodn algoritmy a dky kov. Naprklad NSA publikuje
poiadavky pre tzv. Suite B algoritmy 116 , kde pre zabezpeenie dvernosti dajov
klasifikovanch ako SECRET poaduje AES-128, pre daje klasifikovan ako TOP SECRET
poaduje AES-256; pouitie haovacej funkcie SHA-256 pre klasifikciu SECRET a SHA-384
pre TOP SECRET, at.
Z povahy kryptografickch kontrukci vyplva, e vdy je mon hada symetrick alebo
skromn k tak, e tonk vyska vetky monosti. Ilustrujme schopnos tonka prezrie
cel priestor kov v nasledujcej tabuke. Ako zklad je bran procesor Intel i7-2600 s
hardvrovou akcelerciou AES, schopn realizova viac ako 225 milinov deifrovacch operci
AES-128 za sekundu (8 paralelnch threadov/vlkien). V stpcoch je uvaovan individulny
tonk s jednm potaom, stredne vek firma s 500 potami a ako fiktvny prklad tonk,
ktor investuje do takchto procesorov cel prjem Slovenskej republiky za rok 2013.
116
Zdroj: http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml (mj 2013)
216
as toku
1 minta
1 hodina
1 de
30 dn
1 rok
100 rokov
Individulny tonk
1 procesor
[dka ka v bitoch]
Stredne vek firma

500 procesorov
[dka ka v bitoch]
33,7
39,6
44,1
49,1
52,7
59,3
42,6
48,5
53,1
58,0
61,6
68,3
Prjmy SR za 1 rok
(53,8 mil. procesorov)
[dka ka v bitoch]
59,3
65,2
69,8
74,7
78,3
85,0
Tabuka uvdza, ak vek priestor doke tonk za urit as prezrie, priom vekos
priestoru je vyjadren dkou ka v bitoch.
Podotknime, e tabuka m vlune ilustratvny charakter, in algoritmy maj in rchlos,
procesory sa zrchuj, zlacuj a pecializovan obvod skontruovan na tento el m
v pomere k cene vy vkon. Povedzme 1000-nsobne rchlej procesor by znamenal
pripotanie 10 k dke uvdzanch kov. Bez ohadu na to ponka tabuka dobr predstavu o
exponencilnom raste potu potencilnych kov s rastom ich dky a sn aj o dostatonej
dke 128 bitovho ka.
Podotknime, e tabuka ukazuje monosti tonka v situcii, ke s ke volen skutone
nhodne a s rovnakou pravdepodobnosou. tonk je v ovea lepej situcii, ak s niektor
ke pravdepodobnejie ako in, prpadne ak sa niektor ke urite nepouij. To plat
naprklad v situcii, ak s ke odvoden z hesiel.
Viacer kryptografick kontrukcie, napr. niektor podpisov schmy a protokoly, vyuvaj
alie nhodne volen parametre. Nhodnos, prpadne dvernos tchto parametrov m priamy
dopad na bezpenos kontrukci. To znamen, e implementcia mus dba na bezpenostn
poiadavky takchto parametrov. Ilustratvnym prkladom je prpad implementcie digitlnych
podpisov v hernch konzolch PlayStation 3 spolonosti Sony, s cieom zabrni nahratiu
a spusteniu neautorizovanho (nepodpsanho) kdu. Pouitie statickho namiesto nhodnho
parametra pri podpisovan algoritmom ECDSA viedlo v roku 2010 k prezradeniu skromnho
podpisovho ka.
8.4.2.1 Infratruktra verejnch kov
Asymetrick kryptografick kontrukcie, i u pre ifrovanie alebo digitlne podpisy, maj
hlavn vhodu v tom, e verejn ke mu by zverejnen a teda nie je potrebn zabezpeova
ich dvernos. Hlavnm problmom je vak autentickos verejnch kov. Ako sa odosielate
dajov uist o tom, e verejn ifrovac k adresta je naozaj adrestovm kom, a teda
nepole daje ifrovan povedzme tonkovm verejnm kom? Ako sa vieme uisti, e
verejn k, ktor pouijeme na overenie digitlneho podpisu, skutone patr proklamovanmu
autorovi dokumentu?
Tento problm je ahko rieiten v prostred s malm potom astnkov, ktor sa navzjom
poznaj a mu si svoje verejn ke odovzda osobne. Takto rieenie sa vak ned aplikova
vo veobecnom prpade vekho potu vzdialench alebo vopred neznmych astnkov. Cieom
infratruktry verejnch kov je definova technick (kryptografick) a organizan metdy
a postupy na dosiahnutie dveryhodnej distribcie verejnch kov. Infratruktra verejnch
kov (PKI public key infrastructure) prena dveru astnkov na dveryhodn subjekt
certifikan autoritu. Certifikan autorita vydva certifikty verejnch kov, o s digitlne
podpsan dtov truktry obsahujce okrem inho aj:
217
jednoznan identifikciu subjektu, pre ktor je certifikt vydan, naprklad domnov

meno web servera, meno a e-mailov adresa pouvatea a pod.,
verejn k subjektu, vrtane identifikcie konkrtneho kryptografickho algoritmu,
pre ktor je k uren,
el pouitia verejnho ka, i sli na ifrovanie alebo overovanie podpisov (tm

zrove hovor o ele pouitia zodpovedajceho skromnho ka),
interval platnosti certifiktu, urujci odkedy a dokedy je certifikt platn,
digitlny podpis certifikanej autority, umoujci overi autentickos vetkch dajov
v certifikte.
Fungovanie PKI sa opiera o dva predpoklady. Prvm je dvera astnkov, e certifikan

autorita si pln svoje lohy estne a bezpene. Druhm je dveryhodn distribcia verejnho
ka certifikanej autority, pomocou ktorho si vedia astnci overi podpis certifikanej
autority v certifiktoch a teda autentickos dajov v nich obsiahnutch. Obvykle sa takto
distribcia vykon zrove s distribciou softvru, napr. webov prehliadae obsahuj po
intalcii zoznam niekoko desiatok certifiktov verejnch kov certifikanch autort (tzv.
koreovch certifiktov), ktorm pouvatelia implicitne dveruj. Verejn k certifikanej
autority sa distribuuje vo formte samopodpsanho certifiktu, teda podpis sa overuje tm
verejnm kom, ktor je uveden v certifikte.
Hlavnou lohou certifikanej autority je vydva certifikty verejnch kov. To vyaduje
overi identitu subjektu, ktor iada o certifikt, aby nemohol tonk iada certifikt naprklad
pre server accounts.google.com. Zrove certifikan autorita overuje alie skutonosti, napr.
znalos skromnho ka zodpovedajceho k verejnmu ku subjektu. innosti certifikanej
autority, ktor nevyaduj prcu so skromnm kom s asto delegovan na registran
autoritu, zabezpeujcu kontakt so zkaznkmi (teda subjektmi so zujmom o vydanie vlastnho
certifiktu). S znme prklady z nedvnej minulosti, ke bezpenostn zlyhania certifikanej
autority alebo jej registranej autority viedli k vydaniu falonch certifiktov. Holandsk
certifikan autorita DigiNotar v dsledku bezpenostnch problmov vyhlsila v roku 2011
bankrot. V rovnakom roku zpasila s kompromitciou pouvateskho tu v registranej
autorite certifikan autorita Comodo.
Infratruktra verejnch kov mus zohadni aj kompromitciu skromnch kov
jednotlivch subjektov. V takom prpade je potrebn zneplatni certifikt ete pred uplynutm
intervalu platnosti uvedenho v certifikte. V princpe sa pouvaj dve rieenia zoznam
zneplatnench certifiktov (periodicky vydvan zoznam podpsan certifikanou autoritou)
a interaktvny protokol umoujci spta sa certifikanej autority na platnos/neplatnos
konkrtneho certifiktu on-line.
8.5 Zranitenosti a kryptografia

Najznmejou databzou softvrovch zranitenost je NVD (National Vulnerability Database),
ktor prevdzkuje NIST. NVD zranitenosti klasifikuje poda typu, zvanosti a inch atribtov.
V roku 2012 bolo v NVD publikovanch takmer 5300 zranitenost 117 . Samostatn kategriu
tvoria aj problmy spojen s implementciou, pouitm alebo naopak absenciou kryptografie.
Nasledujci graf zobrazuje rozloenie zranitenost publikovanch v roku 2012 poda ich typu.
Samozrejme, samotn poet zranitenost nehovor ni o ich zvanosti alebo relnej
zneuitenosti v praxi. Nakoniec, pokojne sta jedna zranitenos na kompromitciu prve vho
systmu.
117
Zdroj: http://nvd.nist.gov/home.cfm (mj 2013)
218
Poty zranitenost publikovanch v roku 2012 poda NVD

Buffer Errors
Cross-Site Scripting (XSS)
Permissions, Priviledges and Access Control
Input Validation
Resource Management Errors
Other
SQL Injections
Information Leak / Disclosure
Cross-Site Request Forgery (CSRF)
Numeric Errors
Code Injection
Path Traversal
Authentication Issues
Cryptographic Issues
Design Error
Race Conditions
Credentials Management
Configuration
Link Following
OS Command Injections
Format String Vulnerability
0
100
200
300
400
500
600
700
800
alch 814 zranitenost nebolo priradench do iadnej z uvedench kategri v dsledku

nedostatonch informci.
Z grafu je zrejm, e kryptografick zranitenosti nie s vemi ast. Bli pohad na
kryptografick zranitenosti s vysokou zvanosou prezrad niektor typick problmy spojen
s implementciou kryptografickch rieen:
pouitie nekvalitnho zdroja nhodnosti pri generovan kov,

nedostaton (nepln) kontrola certifiktov,
nekorektn implementcia kryptografickch algoritmov alebo protokolov,
fixn hesl servisnch tov alebo hesl odvoden z verejne znmych dajov.
8.6 tandardy a legislatvne poiadavky

Vina v praxi pouvanch kryptografickch kontrukci je tandardizovan. ifrovacie
algoritmy (symetrick aj asymetrick schmy), haovacie funkcie, autentizan kdy, schmy pre
digitlne podpisy ako aj alie kontrukcie s k dispozcii vo forme tandardov. Najastejie
pouvan tandardy vydva NIST a z pochopitench dvodov s iroko akceptovan
vrobcami softvru. Kryptografick protokoly, napr. TLS, IPSec, SSH a podobne, s najastejie
tandardizovan vo forme RFC (Request for Comments).
tandardy v oblasti informanej bezpenosti sa venuj kryptografii skr okrajovo, priom sa
sstredia najm na sprvu kov a pouitie tandardnch kryptografickch kontrukci.
Medzinrodn tandard ISO/IEC 27002 (Pravidl dobrej praxe manarstva informanej
bezpenosti) definuje nasledujce poiadavky pre kryptografick opatrenia:
219
Politika pouvania kryptografickch opatren zaha vytvorenie a implementciu

politiky, priom pouitie kryptografie m by identifikovan a zdvodnen vsledkami
analzy rizk.
Riadenie kov tkajce sa postupov a metd ochrany kryptografickch kov pri
ich generovan, distribcii, uloen, archivovan, zneplatovan a pod.
Hodnotenie a certifikcia IT systmov je cieom tandardu ISO/IEC 15408 (Common Criteria

for Information Technology Security Evaluation / Kritri na hodnotenie bezpenosti IT).
Kritri sa obvykle aplikuj na komponenty ako s naprklad operan systm, ipov karta,
firewall, databzov server, smerova a pod. Z hadiska kryptografie kritri definuj funkn
triedu Kryptografick podpora s dvoma mnoinami poiadaviek:
Sprva kryptografickch kov zaha generick poiadavky na generovanie,

distribciu, prstup a detrukciu kov s tm, e v systme s pouvan
tandardizovan kontrukcie.
Prevdzka kryptografie generick poiadavka na vykonvanie kryptografickch
operci v slade s explicitne definovanmi tandardami.
tandard FIPS 140-2 vydal NIST 118 a definuje bezpenostn poiadavky pre kryptografick
moduly. Ide o najastejie pouvan tandard pre bezpenostn posdenie kryptografickch
modulov. Moduly mu by rznorod kryptografick kninica operanho systmu, ifrovan
pamov USB k, ipov karta, hardvrov bezpenostn modul a pod. tandard definuje 4
bezpenostn rovne, od rovne 1 a po rove 4 s postupne sprsovanmi poiadavkami.
Medzi oblasti, v ktorch s poiadavky definovan patria pecifikcia modulu, roly, sluby,
autentizcia, fyzick bezpenos modulu, samotestovanie, sprva kov, elektromagnetick
vyarovanie a alie. V roku 2012 bolo vydanch 68 osveden o certifikcii na rovni 1, 95
osveden na rovni 2, 37 osveden na rovni 3 a iadne osvedenie na rovni 4 119 . Pre
zaujmavos, dosia existuje celkovo len 10 osveden na rovni 4 poda FIPS 140-2.
Podotknime, e certifikcia konkrtneho produktu nie je zrukou jeho bezpenosti. Certifikcia je
overenie splnenia konkrtnych poiadaviek a nie bezpenostn analza. Ilustratvnym prkladom
boli ifrovan pamov USB ke spolonost Verbatim, Kingston a SanDisk, certifikovan na
rovni 2 poda FIPS 140-2. V roku 2010 bezpenostn analza spolonosti SySS ukzala, e
k zaifrovanm dajom je mon sa dosta jednoduchou pravou riadiaceho programu bez
znalosti prstupovho ka. Napriek tomu maj certifikty produktov svoj vznam hovoria
o tom, e tvorcovia museli naplni ist bezpenostn poiadavky. Produkt s vhodnou rovou
certifikcie poda Common Criteria a FIPS 140-2 vzbudzuje viu dveru ako produkt bez
certifikcie.
8.6.1
Legislatva SR
Niektor kryptografick poiadavky mono njs aj v normatvnych prvnych aktoch SR. V tejto
asti uvedieme vybran prklady.
Vnos Ministerstva financi SR . 312/2010 Z. z. o tandardoch pre informan systmy
verejnej sprvy uvdza v asti Technick tandardy:
Protokol(y) IPSec pre zabezpeenie sieovch protokolov.

Protokol SSL (verzia 3.0) alebo TLS pre prenos dt, pre zabezpeenie prenosu
elektronickej poty, pri chrnenom prstupe k verejnm elektronickm potovm
118
FIPS PUB 140-2 Security Requirements for Cryptographic Modules

Zdroj: NIST: Cryptographic Module Validation Program, Validated FIPS 140-1 and FIPS 140-2
Cryptographic Modules, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm (mj
2013)
119
220
slubm, pri chrnenom prenose dt medzi klientom a webovm serverom a medzi

webovmi servermi, pri chrnenom verejnom prstupe k adresrovm slubm.
Formt S/MIME pre formt elektronickch potovch sprv pri ich chrnenom prenose.
Pre obsah webovho sdla poaduje vnos zverejnenie kontaktnej informcie, na ktorej mono
zska kontroln reazec znakov na overenie pravosti pouvanch certifiktov verejnch
kov pre elektronick sluby verejnej sprvy a elektronick potov sprvy; zverejnenie
najmenej jednho verejnho ka pre chrnen prenos elektronickch potovch sprv, ak
organizcia takto prenos poskytuje. tandardy sa vak nezmieuj o tom, o vnmaj ako
kontroln reazec znakov ani ako by tento mal presvedi pouvatea o pravosti certifiktu.
Faktom je, e viacer stredn orgny ttnej sprvy maj vydan certifikty pre webov servery
certifikanmi autoritami, ktor s tandardne dveryhodn vo webovch prehliadaoch.
Zverejnenie verejnch kov pre chrnen prenos elektronickch sprv je v sasnosti v praxi
vemi zriedkav.
Zaujmav je aj paragraf venovan ochrane proti kodlivmu kdu, kde sa okrem inho ocitli aj
poiadavka na podporu zabezpeenia autenticity a integrity sborov pomocou kryptografickch
prostriedkov, najm elektronickho podpisu a poiadavka na podporu ifrovania elektronickch
dokumentov.
Zkon . 215/2002 o elektronickom podpise v znen neskorch prepisov riei problematiku
elektronickch podpisov a svisiacej infratruktry verejnch kov. Kee technick realizcia
sa v plnej miere opiera o kryptografick techniky schm pre digitlne podpisy, nevyhnutne mus
zkon a svisiace vyhlky upravova aj podrobnosti pouitch kryptografickch kontrukci.
Z tohto hadiska je najzaujmavejia vyhlka Nrodnho bezpenostnho radu SR . 135/2009,
ktor okrem inho definuje formt a spsob vyhotovenia zaruenho elektronickho podpisu,
vrtane povolench haovacch funkci, podpisovch schm a alch kryptografickch
kontrukci.
Do psobnosti zkona . 215/2004 o ochrane utajovanch skutonost v znen neskorch
prepisov patr aj ifrov ochrana informci, teda zabezpeenie ochrany utajovanch skutonost
kryptografickmi metdami. Kee podrobnosti o kryptografickch kontrukcich s predmetom
ochrany poda zkona, nie s verejne prstupn.
8.7 Praktick rady na zver

Cieom tejto asti je ponknu niektor zkladn praktick rady tkajce sa vberu a pouitia
kryptografickch kontrukci. Odporania a varovania nie s vyerpvajce, s isto
subjektvne a mu existova aj in nzory.
221
Odporania
Pouvajte tandardn kryptografick algoritmy, schmy a protokoly
Pouvajte dostaton dky kov
Pravidelne mete ke a hesl
Dbajte na kvalitn generovanie kov a vobu hesiel
Majte premyslen, o robi po kompromitcii kov alebo hesiel
Ak mete, pouite certifikovan rieenia
Poznajte konfiguran monosti kryptografickch rieen a ich bezpenostn dopady
Dsledne overujte certifikty verejnch kov
Koreov certifikty zskajte dveryhodnm spsobom
Varovania
222
Kryptografia nie je miesto na kreativitu a ad-hoc rieenia

Dlhodobo nezmenen ke povaujte za prezraden
ifrovanie nezabezpeuje integritu ani autentickos dajov
Autentizan kdy ani digitlne podpisy nezabezpeuj dvernos
Obvykle je heslo najslabm kom v systme
Samopodpsan certifikt nehovor ni o autentickosti verejnho ka
Certifikcia nie je nhradou bezpenho pouvania
Kryptografia nenahrad in organizan a technick bezpenostn opatrenia
9 Kryptolgia II
Martin Stanek
9.1 vod
Dokument vone nadvzuje na predchdzajcu as Kryptolgia, priom postupne prehlbuje
informcie o kryptografickch kontrukcich. Napriek tomu, e obmedzme matematick strnku
vkladu na minimum a pri vklade pouijeme niektor zjednoduenia, nevyhneme sa niektorm
matematickm pojmom a zpisom. Dokument predpoklad, e itate je oboznmen
s poznatkami prezentovanmi v predchdzajcej asti Kryptolgia. Zujemcom o precznej a
ir pohad na tto problematiku mono znova odporui pecializovan odborn literatru
alebo vysokokolsk prednky.
9.2 Symetrick kontrukcie

Symetrick ifry mono rozdeli na blokov a prdov. Vinou s v praxi pouvan blokov
ifry. Dvodom je fakt, e najdleitejie tandardy (ako napr. tandardy vydan NIST) primrne
tandardizuj blokov ifry (v minulosti DES, v sasnosti AES). Navye, vobou vhodnho
mdu mono blokov ifru pouva aj ako prdov ifru.
9.2.1
Blokov ifry
Blokov ifrovacie a deifrovanie algoritmy s definovan pre bloky bitov pevnej dky, teda pre
ubovon k ifra zobrazuje blok vstupnch dt na blok zaifrovanch dt. Naprklad AES m
dku bloku 128 bitov, pre ubovon variant dky ka (teda 128, 192 alebo 256 bitov)
a 3DES m dku bloku 64 bitov. Blokov ifry s najastejie kontruovan viacnsobnou
iterciou jednoduchej transformcie (nazvanej kolo algoritmu). Pre kad kolo sa pouva
pecifick k, ktor je odvoden presne definovanm spsobom zo ifrovacieho ka.
Najpouvanejmi blokovmi iframi sasnosti s AES a 3DES. Z hadiska pouvania AES s
dleit nasledujce fakty:
Viacer novie procesory maj hardvrovo implementovan pecilne intrukcie pre

urchlenie AES algoritmu. To znamen vrazne urchlenie ifrovania a deifrovania pre
aplikcie/kninice, ktor takto implementciu vedia vyui. Ilustrciu vkonovch
rozdielov mono vidie v asti 6.1.
Pouitie AES s dlhmi kmi znamen mierne spomalenie ifrovania, kee AES-128
m 10 kl, AES-192 m 12 kl a AES-256 m 14 kl. Pre praktick pouitie je
spomalenie zanedbaten.
Z hadiska pouvania 3DES s dleit nasledujce fakty:
223
Kontrukcia 3DES algoritmu vyuva sekvenn zreazenie 3 transformci klasickej

ifry DES (primrne s cieom predi k, ktor m v DES dku len 56 bitov). Tm je
ovplyvnen aj rchlos algoritmu a vo veobecnosti s implementcie AES rchlejie
ako implementcie 3DES.
Efektvna dka ka (teda dka zodpovedajca kryptografickej sile ka) v 3DES je
v dsledku kontrukcie algoritmu menia ako set dok pouitch kov. Odpora sa
pouva 3DES s tromi nezvislmi kmi (dokopy 3 x 56 = 168 bitov), priom
efektvna dka kov je v tomto prpade 112 bitov.
<Kryptolgia II | MF SR
Operan mdy blokovch ifier

Pre ifrovanie dlhch dt je potrebn poui ifru vo vhodnom operanom mde. Rzne mdy sa
navzjom odliuj elom pouitia (napr. ifrovanie komunikcie alebo diskov),
implementanmi vlastnosami (napr. monos paralelizova ifrovanie a/alebo deifrovanie),
bezpenostnmi poiadavkami (dvernos a autentickos) a pod. NIST 120 rozdeuje odporan
a schvlen operan mdy poda elu pouitia do nasledujcich kategri:
dvernos (celkovo 5 mdov: ECB, CBC, OFB, CFB, CTR)

autentickos (CMAC)
autentizovan ifrovanie (CCM) a autentizovan ifrovanie s vysokou priepustnosou
(GCM)
dvernos pre blokov loisk dt, napr. disky (XTS)
dvernos a integrita kov (KW, KWP, TKW)
Uveden mdy nevyerpvaj monosti a rznorodos spsobov pouitia blokovch ifier.

Prklady alch mdov mono njs na strnke NIST 121.
asto pouvanm mdom blokovej ifry je CBC (Cipher Block Chaining). Naprklad AES-128
v CBC mde je povinnou sasou v implementcich TLS 1.2 122.
P1
P2
IV
P1
...
P2
IV
...
Ek
Ek
Dk
Dk
C1
C2
C1
C2
ifrovanie v CBC mde
deifrovanie v CBC mde
IV inicializan vektor (obvykle nhodn)

E, D ifrovacia a deifrovacia transformcia blokovej ifry
k k
Pi , Ci bloky otvorenho a bloky zaifrovanho textu
- opercia XOR
Z praktickho hadiska je pri implementcii CBC potrebn doriei spsob ifrovania potencilne
neplnch poslednch blokov, v prpade ke dka otvorenho textu nie je nsobkom dky
bloku. Obvykl rieenie je voba vhodnej vplne/zarovnania (tzv. padding). alou
120
Zdroj: NIST Special Publication 800-38A ... 800-38E (Recommendation for Block Cipher Modes of
Operation)
http://csrc.nist.gov/publications/PubsSPs.html
121
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
122
Zdroj: The Transport Layer Security (TLS) Protocol, Version 1.2, RFC 5246, 2008.
224
implementanou otzkou je voba a prenos inicializanho vektora. Ten sce nemus by tajn
(mono posiela spolu so zaifrovanm textom), ale m by nepredikovaten.
Sprvne implementovan CBC md je bezpen spsob pouitia blokovej ifry pre zabezpeenie
dvernosti dt. Nevhodn implementcia v konkrtnom prostred/protokole vak me dvernos
dt pokodi. Prkladom bol tzv. BEAST tok v roku 2011 na starie ale stle pouvan verzie
protokolov SSL/TLS. BEAST tok vyuva nevhodn spsob prenania inicializanch
vektorov medzi samostatnmi sprvami/paketmi v protokole. Podobne aj ostatn mdy vyaduj
starostliv implementciu pre dosiahnutie elanch bezpenostnch vlastnost.
Autentizovan ifrovanie
Autentizovan ifrovanie je pecifick md blokovch ifier, ktor okrem dvernosti
zabezpeuje sasne aj autentickos dajov. Obvykl zabezpeenie oboch poiadaviek je rieen
samostatnm ifrovanm a samostatnm vpotom hodnoty autentizanho kdu (tandardne
napr. v SSL/TLS, IPSec alebo SSH). Navye, existuje niekoko rznych kombinci ifrovania
a vpotu autentizanho kdu, z ktorch nie vetky s bezpen alebo vhodn v konkrtnej
situcii. Autentizovan ifrovanie spja obe opercie do jednej, m obvykle dosahuje vyiu
rchlos. Vhodou autentizovanho ifrovania je fakt, e md je popsan jednoznane a nie je
potrebn ho alej kombinova. Najznmejmi mdmi tohto typu s GCM (Galois Counter
Mode) a CCM (Counter with CBC-MAC). Napriek tomu, e v sasnosti nie je autentizovan
ifrovanie prli rozren, hoci naprklad CCM je povinnou sasou implementcie tandardu
IEEE 802.11i (WPA2), v budcnosti mono oakva jeho irie pouvanie.
9.2.2
Prdov ifry
Prdov ifry s kontruovan najastejie ako genertor pseudonhodnho prdu bitov

stavanho modulo 2 (teda opercia XOR) s bitmi vstupnch dt do zaifrovanho textu.
inicializan
vektor
inicializan
vektor
genertor
pseudonhodnej
postupnosti
vstupn
dta
zaifrovan
dta
ifrovanie
genertor
pseudonhodnej
postupnosti
zaifrovan
dta
pvodn
dta
deifrovanie
Najpouvanejou prdovou ifrou pokia ide o softvrov implementciu je RC4 (pomerne

frekventovan voba aj v SSL/TLS). pecializovan prdov ifry maj obvykle jednoduchiu
truktru ako blokov ifry a s vhodn najm pre hardvrov implementciu. Kee blokov
ifry je mon vhodnm mdom (napr. OFB, CTR alebo CFB) poui aj ako prdov ifry,
v praxi s vinou pouvan prve blokov ifry. K tomu prispieva aj fakt, e americk NIST
schvlil na pouitie vlune blokov symetrick ifry.
9.2.3
Haovacie funkcie
Od univerzlne pouitenej haovacej funkcie oakvame dve zkladn bezpenostn vlastnosti:

1. Odolnos voi njdeniu vzoru (jednosmernos): z danho odtlaku nie je efektvne
mon vypota dokument s takmto odtlakom.
225
2. Odolnos voi kolzim: nie je efektvne mon vypota dva rzne dokumenty
s rovnakm odtlakom.
Kolzie pre ubovon haovaciu funkciu mono hada tzv. narodeninovm tokom. Tento
tok vytvor odtlaky vekho potu sprv/dokumentov a nsledne had medzi odtlakami
aspo jednu dvojicu kolidujcich. V prpade, e odtlaok haovacej funkcie m dku bitov, tak
zloitos toku je v najhorom prpade ~ 2/2 . Pripomeme, e pre ubovon symetrick ifru
mono hada ke plnm preberanm v najhorom prpade so zloitosou ~ 2 (kde k je dka
ka v bitoch). Preto maj tandardizovan haovacie funkcie dky odtlakov zodpovedajce
dvojnsobku dok kov tandardizovanch symetrickch ifier. Typickm prkladom je AES128, AES-192, AES-256 vs. SHA-256, SHA-384, SHA-512 alebo naprklad 3DES vs. SHA-224
(kee efektvna dka ka pre 3DES je 112 bitov).
Nedvno prebehol verejn vber novho tandardu pre haovaciu funkciu SHA-3. Vaznm
algoritmom je Keccak. Ten umouje pota ubovon dku odtlaku, hoci tandardizovan
bud pravdepodobne dky zhodn s dkami odtlakov sady haovacch funkci SHA-2.
Zavenie tandardizcie SHA-3 je plnovan v roku 2014. Z praktickho hadiska je dleit
spomen, e sa nepredpoklad migrcia z SHA-2 na SHA-3, ale vzjomn koexistencia tchto
sd haovacch funkci.
Z hadiska rchlosti softvrovej implementcie je Keccak porovnaten s SHA-2 (samozrejme
v zvislosti na konkrtnej implementcii a procesore), dovouje vak efektvnu hardvrov
implementciu.
9.2.4
Autentizan kdy sprv
Najastejou kontrukciou autentizanch kdov sprv je HMAC, kontrukcia vyuvajca

haovaciu funkciu. HMAC je mon kontruova z ubovonej haovacej funkcie H takto:
HMAC(k, m) = H((k opad) || H((k ipad) || m)),
kde k oznauje symetrick k a m oznauje sprvu, ktorej autentizan kd potame. Hodnoty
ipad a opad s kontanty, obvykle definovan v konkrtnom tandarde. Opercia oznauje
XOR a opercia || oznauje zreazenie hodnt. Napriek dvojitej aplikcii haovacej funkcie H je
vpoet HMAC v podstate (pre dlhie sprvy) rovnako rchly ako vpoet odtlaku sprvy,
kee druh aplikcia H sa vykonva u len na krtkom vstupnom reazci.
Pre bezpenos HMAC nie je podstatn odolnos pouitej haovacej funkcie (s klasickou
kontrukciou) voi kolzim, take napriek njdeniu kolzi v MD5 alebo hrozbe njdenia kolzi
v SHA-1 s HMAC kontrukcie s tmito haovacmi funkciami (momentlne) bezpen.
Dka vstupu HMAC kontrukcie je rovnak ako dka vstupu haovacej funkcie. V praxi sa
vstup HMAC niekedy skracuje tak, e sa zoberie len definovan poet vstupnch bitov.
Vhodou takhoto prstupu je men objem prenanch dt v situcich, ke sa autentizan
kd pota ku kadmu (potencilne krtkemu) paketu. Naprklad IPSec umouje poui
HMAC-SHA-1-96, o je HMAC potan s pouitm haovacej funkcie SHA-1, kde zo 160 bitov
dlhho vsledku je na vstup danch prvch 96 bitov. Skracovanie vstupu nem vplyv na
rchlos vpotu HMAC.
Autentizan kdy sprv je mon kontruova aj z blokovch ifier pomocou pecifickch
autentizanch mdov (napr. CMAC). Taktie niektor haovacie funkcie umouj kontruova
MAC jednoduchie ako HMAC kontrukciou naprklad Keccak dovouje vypota MAC ako
odtlaok s tm, e k sa pripoj na zaiatok sprvy (takto pouitie vak nie je zatia ani
tandardizovan ani pouvan). Poznamenajme, e takto kontrukcia s MD5, SHA-1 alebo s
ubovonou funkciou z rodiny SHA-2 by bola trivilne napadnuten.
226
9.3 Asymetrick kontrukcie

Bezpenos asymetrickch kontrukci je postaven na matematickch problmoch, o ktorch
predpokladme, e nie s efektvne rieiten. Najastejmi pouvanmi problmami s:
9.3.1
Faktorizcia vekch sel pre zadan (ktor je sinom dvoch prvosel , ) je

lohou njs tieto prvosla. O zloitos tohto problmu pre dostatone vek sa
opieraj kontrukcie RSA schm.
Diskrtny logaritmus pre zadan hodnotu , kde je prvoslo, je vhodn
prvok z { , , , } a je nhodn, je lohou vypota . O zloitos tohto
problmu pre dostatone vek sa opiera kontrukcia DSA, Diffieho-Hellmanov
protokol (pozri as 9.3.3) a pod. Problm diskrtneho logaritmu mono sformulova aj
na inch matematickch objektoch, nielen v modulrnej aritmetike. astou, prakticky
pouvanou oblasou s eliptick krivky teda pouit matematick opercie s in.
Kee problm diskrtneho logaritmu m na eliptickch krivkch ete viu zloitos
ako v modulrnej aritmetike, sta na dosiahnutie rovnakej bezpenosti pouva kratie
ke (pozri as 9.5.1).
Asymetrick ifrovanie je najastejie pouvan v hybridnch schmach na ifrovanie

symetrickch kov. asto pouvanou asymetrickou schmou je RSA (navye je
najjednoduchie prezentovaten), ktorej hol, uebnicov verzia prebieha nasledovne:
RSA
Inicializcia: zvolia sa dve vek rzne prvosla , a vypota = ; zvol sa hodnota a
dopota hodnota tak, aby platil vzah 1 mod ( 1)( 1). Verejnm kom je
dvojica , ; skromn k je hodnota . Bez dopadu na bezpenos schmy je mon hodnotu
, nazvan aj verejn exponent, zvoli ako krtke slo, o m priazniv vplyv na rchlos
verejnej opercie 123 v RSA. Najastejou vobou bva = 65537, vaka vhodnej binrnej
reprezentcii sla. Pokia sa hovor o dke RSA ka, napr. 1024 alebo 2048 bitov, mysl sa
dka . Navye, rovnak dku m takmer vdy aj hodnota , nazvan aj skromn exponent.
ifrovanie je definovan pre ubovon text , reprezentovan ako slo z mnoiny {0,1, ,
1} , takto: () = mod . Deifrovanie zaifrovanch dajov sa vykon s pomocou
skromnho exponentu nasledovne: () = mod . Dsledkom rozline dlhch exponentov
je podstatne rchlejia verejn RSA transformcia ako skromn transformcia (pozri as 6.1).
V praxi sa deifrovanie urchuje alternatvnym vpotom s vyuitm matematickch vlastnost
modulrnej aritmetiky. To si vyaduje pamta dodaton hodnoty ako sas skromnho
ka, preto je dtov truktra obsahujca skromn RSA k obvykle bohatia. Prklad
vytvorenia RSA intancie je uveden v Prlohe A.
Priamoiare pouitie holej RSA schmy sa z bezpenostnch dvodov neodpora. Praktick

RSA ifrovanie pouva vhodn vplov schmu (padding). Obvykle pouvanmi schmami
s staria PKCS#1 v1.5 a novia OAEP (Optimal Asymetric Encryption Padding) 124. OAEP m
lepie bezpenostn vlastnosti a pri spracovan otvorenho textu pred samotnou verejnou RSA
transformciou vyuva alie kryptografick kontrukcie (haovaciu funkciu, pseudonhodn
genertor). Samozrejme, pri deifrovan je po skromnej RSA transformcii ete potrebn na
zskanie pvodnch dt odstrni vplyv OAEP.
123
Verejn RSA opercia zodpoved ifrovaniu v prpade asymetrickho ifrovania, resp. overovaniu
podpisu v prpade podpisovej schmy.
124
Obe s definovan napr. v Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1, RFC 3447.
227
9.3.2
Podpisov schmy
Podobne ako v prpade asymetrickho ifrovania je hol RSA podpisov schma jednoduch.
Pouijc rovnak oznaenia pre RSA schmu ako v predchdzajcej asti, je podpisovanie
odtlaku sprvy () realizovan s pomocou skromnho ka takto: = () mod , kde
je vsledn podpis. Kee ide o skromn RSA transformciu, mono vyui rovnak
urchovanie ako pri RSA deifrovan. Overenie podpisu spova v porovnan hodnt ()
a mod , priom pouvame verejn k tvorcu podpisu. Podpis je korektn, ak s obe
hodnoty rovnak.
V praxi sa op pouvaj na zvenie bezpenosti vhodn vplov schmy. Obvykle
pouvanmi vplovmi schmami s PKCS#1 v1.5 pre podpisy (zdrazujeme, e je to in
schma ako pri ifrovan) a novia PSS (Probabilistic Signature Scheme) 125 . RSA-PSS op
vyuva aj alie kryptografick kontrukcie (haovaciu funkciu, pseudonhodn genertor).
Napriek tomu, e z matematickho pohadu ni nebrni pouva rovnak intanciu RSA (teda
hodnoty , , a in) v podpisovej schme aj na ely asymetrickho ifrovania, takto pouitie
sa neodpora.
RSA je spolu s DSA a ECDSA sasou schvlenho tandardu 126. Vina v praxi pouvanch
podpisovch schm je preto niektor z tchto troch schm.
9.3.3
Protokoly na dohodnutie ka
lohou protokolov na dohodnutie (niekedy aj vmenu alebo distribciu) ka je ustanovi

medzi komunikujcimi stranami kryptografick ke a in parametre, ktor bud nsledne
pouit na ochranu prenanch dajov ifrovanm, vpotom autentizanch kdov a pod.
V praxi maj tieto protokoly za cie vzjomne autentizova jednu i obe komunikujce strany.
Diffieho-Hellmanov protokol (alej DH protokol ) sli na dohodnutie ka a vo svojej
pvodnej podobe je bez autentizcie. Priebeh protokolu pre astnkov A a B je nasledujci:
1. A B: , ,
( je vek prvoslo, je vhodn slo z {, , , } a je nhodne zvolen)
2. B A:
( je nhodne zvolen)
3. A vypota hodnotu = ( ) = a B vypota rovnak hodnotu = ( ) =

(v oboch prpadoch rtajc ), z ktorej nsledne mu obaja odvodi symetrick
ke pre ifrovanie, pre vpoet autentizanch kdov a pod.
Bezpenos DH protokolu pri pasvnom tonkovi, ktor odpova ale nezasahuje do
komunikcie medzi A a B, sa opiera o predpoklad, e pre vhodn , nie je mon z hodnt
a efektvne spota hodnotu . Pokia vak uvaujeme o tonkovi, ktor me prenan
sprvy v protokole meni, je mon na DH protokol toi (tzv. MITM man in the middle
tok, tonka ozname M):
125
126
1. A M(B): , ,
2. M B: , ,
sm)
3. B M(A):
4. M A:
(M zachyt sprvu uren pre B)

(M pole B namiesto toho in sprvu, kde si zvolil
(M zachyt sprvu uren pre A)

(M pole A namiesto toho in sprvu, kde si zvolil sm)
Obe definovan v RFC 3447.

NIST: FIPS PUB 186-4 Digital Signature Standard (DSS), 2013.
228
5. A vypota hodnotu = ( ) = a B vypota hodnotu = ( ) = ,

a teda s vysokou pravdepodobnosou kad odvod in ke. tonk M vie vypota
obe hodnoty takto: ( ) = a ( ) = . Nsledne doke M komunikova
s A aj B, v prpade potreby preifrovva a popri tom aj ta ich vzjomn
komunikciu.
DH protokol je zkladom pre vmenu ka v mnohch v praxi pouvanch protokoloch,

priom tieto obvykle pouvaj varianty DH protokolu tak, aby zamedzili MITM toku:
TLS 1.2 pecifikuje nasledujce varianty DH protokolu:

DH_anon anonymn DH protokol bez autentizcie, mon MITM tok.
DHE_RSA, DHE_DSS server generuje parametre , , priom tieto a svoju hodnotu
(pre nhodn ) podpe s pouitm podpisovej RSA schmy alebo s pouitm DSA
algoritmu definovanom v tandarde DSS. Server v takomto prpade disponuje a pole
klientovi certifikt verejnho ka, ktorm klient me podpis overi.
DH_RSA, DH_DSS podobne ako v predchdzajcom prpade, len parametre DH
protokolu s sasou certifiktu servera.
astou vobou pri dohodnut ka v TLS je RSA metda, kde klient zaifruje nhodne
zvolen hodnotu s pouitm verejnho RSA ka servera (verejn k servera je, samozrejme,
sasou certifiktu). Okrem uvedench variantov DH protokolu existuj aj varianty postaven
na eliptickch krivkch v takom prpade s oznaen prefixom EC, napr. ECDHE_RSA.
IPSec pre vzjomn autentizciu a dohodnutie ka sa pouva protokol IKE (Internet

Key Exchange), momentlne v starej a novej verzii IKEv1 a IKEv2. V oboch
prpadoch prebieha dohodnutie ka pomocou DH protokolu, priom autentizcia je
vykonan prostrednctvom ifrovania alebo podpisov s vyuitm verejnch
kov/certifiktov, autentizanch kdov s vyuitm zdieanho tajomstva (tzv.
preshared secret) alebo v prpade IKEv2 aj prostrednctvom vhodnej EAP metdy
(EAP Extensible Authentication Protocol).
SSH 2 (Secure Shell) jednou z metd na dohodnutie ka je pouitie DH protokolu
s tm, e server svoje parametre podpisuje, m sa zrove zabezpeuje ich autentickos.
9.4 Infratruktra verejnch kov

Zkladom pre zskanie certifiktu je vytvorenie pru kryptografickch kov pre asymetrick
schmu a sboru s poiadavkou na vydanie certifiktu. Poiadavka je vo forme CSR (Certificate
signing request) a pripja sa k iadosti o vydanie certifiktu. Sasou CSR s informcie
o subjekte a alie informcie potrebn pre nsledn vyuitie certifiktu, naprklad domnov
meno pre web server. Certifikan autority poskytuj nvody na sprvne vygenerovanie CSR pre
najastejie pouvan serverov platformy. Napr. v IIS 7 mono poui IIS Manager,
v Exchange 2010 Exchange Management Console, pre Apache obvykle openssl, pre Tomcat
nstroj keytool, pre Cisco ASA mono poui Cisco Adaptive Security Device Manager at.
CSR okrem verejnho ka a atribtov, ktor sa maj ocitn v certifikte, obsahuje aj podpis
tchto dt vytvoren s pouitm skromnho ka. Vaka tomu je zrejm, e tvorca CSR pozn
skromn k a atribty neboli zmenen (identitu subjektu vak mus overi
registran/certifikan autorita inak). Prklad vytvorenia CSR pomocou openssl je uveden
v prlohe B.
Certifikan autority zverejuj pravidl a postupy svojej innosti v tzv. certifikanom poriadku
(Certification Practice Statement CPS). Popis vydvania certifiktov, archivcie zznamov,
zneplatovania a obnovy certifiktov, bezpenostnch opatren a alch podrobnost innosti
229
napomhaj zvyova dveru v certifikan autoritu. Dvera bva obvykle umocnen

nezvislm auditom certifikanej autority 127.
Vyiu dveru v certifikt subjektu maj sprostredkova tzv. Extended Validation (EV)
certifikty, kde prslun pravidl definuje CA/Browser Forum dobrovon organizcia
zdruujca certifikan autority a tvorcov webovch prehliadaov 128 . EV certifikty sa od
obyajnch certifiktov formlne lia len pecifickm atribtom v certifikte. Rozdiel je vak
v podrobnejom postupe, akm certifikan autorita overuje identitu subjektu ale aj jednotliv
atribty budceho certifiktu. Naprklad, pri EV certifiktoch sa overuje aj vlastnctvo ku
kadmu domnovmu menu, a preto nemu by vydan hviezdikov certifikty s EV.
V podstate vetky vznamnejie banky v SR maj pre svoj internetbanking vydan EV
certifikty. Nasledujce obrzky ukazuj rozdiel v prezentovan SSL/TLS spojenia medzi
overenm certifiktom s EV (strnka nskej banky ICBC) a obyajnm overenm certifiktom
(strnka Ministerstva financi SR) v prehliadai Google Chrome. Pouitie zelenho podkladu
a uvedenie nzvu intitcie je charakteristick aj pre alie prehliadae ako napr. Internet
Explorer alebo Mozilla Firefox. Webov prehliadae ako Chrome alebo Firefox obsahuj
explicitn zoznam certifikanch autort (ich koreovch certifiktov), ktorch EV certifikty
akceptuj. Zelen prezentcia URL adresy je potom vyhraden vlune pre EV certifikty
vydan tmito certifikanmi autoritami.
Zoznam koreovch CA pre Mozilla Firefox (prirodzene, prienik so sadou CA v inch prehliadaoch je
znan), vrtane odkazov na vsledky prslunch auditov tchto CA mono njs na
http://www.mozilla.org/projects/security/certs/included/index.html
128
Pravidl s k dispozcii na https://www.cabforum.org/Guidelines_v1_4.pdf
127
230
tandardn spsoby ako overi, i certifikt nebol zneplatnen poas intervalu platnosti s CRL
(Certificate Revocation List) a OCSP (Online Certificate Status Protocol). V idelnom prpade by
pred pouitm certifiktu mala by jeho platnos okrem ostatnch testov overen aj voi CRL
alebo pomocou OCSP. Aplikcia potom mus riei situciu, ke tieto mechanizmy nie s
dostupn pokraova bez overenia alebo nepokraova vbec?
Adresy, na ktorch je mon njs CRL a/alebo OCSP s uveden v certifikte. CRL s pre
koncov (klientske) certifikty vydvan zvyajne denne interval je definovan v certifikanom
poriadku konkrtnej certifikanej autority. Zoznam sriovch sel zneplatnench certifiktov
v CRL obsahuje aj dvody zneplatnenia. Na zabezpeenie autentickosti je CRL podpsan
certifikanou autoritou. Pri vyuvan CRL je podstatn ma aktulnu verziu CRL.
OCSP je alternatvny spsob overenia predasnho zneplatnenia certifiktov. Vhodou oproti
CRL je men objem prenanch dajov (kee klient sa pta na jeden konkrtny certifikt) a
teoreticky erstv 129 , prakticky takmer erstv odpove o stave certifiktu. Odpove je
podpsan certifikanou autoritou.
9.5 Kryptoanalza a bezpenos kryptografickch kontrukci

Kad kryptografick kontrukcia je nchyln na tzv. generick toky, ktor nezvisia na
podrobnostiach a kvalitch kontrukcie. Typickm prkladom je tok plnm preberanm (tok
hrubou silou) na symetrick ifrovanie, ke tonk vyska postupne vetky potencilne ke.
V takom prpade nezle na tom, i je pouit ifra AES alebo in tok sa d realizova vdy.
Paradoxne, m rchlejia ifra, tm rchlejie bude aj preberanie kov. Zdraznime, e
generick tok je z hadiska tonka najhor mon. Pri ubovonej slabine kryptografickej
kontrukcie alebo nevhodnej implementcii me by tok efektvnej. Teda kvalitn
kryptografick kontrukcie a ich implementcie sa snaia dosiahnu, aby bol generick tok
zrove najlepm tokom, ktor m tonk k dispozcii.
129
pokia klient aj OCSP server podporuj pecifick rozrenie protokolu (nonce extension, RFC 6960)
231
Nasledujca tabuka sumarizuje generick toky na zkladn kryptografick kontrukcie:

Kontrukcia
Symetrick ifra
Haovacia funkcia
MAC
Asymetrick ifra
Podpisov schma
Generick tok (k dka ka, n vekos odtlaku/vstupu)

Prehadvanie priestoru vetkch kov ~ 2
Hadanie kolzi: narodeninov tok ~ 2/2
Hadanie vzoru: prehadanie a vyskanie vzorov ~ 2
Prehadvanie priestoru vetkch kov ~ 2 , resp. uhdnutie
korektnho autentizanho kdu k sprve ~ 2 .
Rieenie konkrtneho akho problmu (faktorizcia, vpoet
diskrtneho logaritmu a pod.)
Rieenie konkrtneho akho problmu, resp. tok na
haovaciu funkciu.
Kryptolgia pri analze kontrukci obvykle uvauje s o najsilnejm tonkom. To znamen,

e naprklad (neformlne a zjednoduene):
Pri ifrovacch schmach oakvame, e tonk sa zo zaifrovanch dt nedozvie o ich

deifrovanej podobe ni, napriek tomu, e budeme predpoklada schopnos tonka
necha si deifrova akkovek zaifrovan text (samozrejme s vnimkou ). Prirodzene,
pri asymetrickch ifrch m tonk, ako ktokovek in, schopnos ifrova ubovon
dta.
Pri podpisovch schmach budeme predpoklada schopnos tonka necha si podpsa
ubovon, nm zvolen sprvu; napriek tomu oakvame, e tonk nedoke vytvori
korektn podpis k nejakej sprve na ktorej podpis sa neptal.
Kontrukcie bezpen pri vemi silnom tonkovi potom zostan bezpen aj v prpade scenra
so slabm tonkom.
9.5.1
Ekvivalentn dky kov
Pri pouvan viacerch kryptografickch kontrukci je vhodn pouva tak dky kov, aby
zloitos toku na kad pouit kontrukciu bola pribline rovnak. Existuj rzne analzy a
odporuenia popisujce ekvivalentn dky kov 130 a odporuenia na vobu dok kov
poda citlivosti chrnench dajov alebo potrebnej doby ich ochrany. Uveme niekoko
prkladov zo sprvy projektu ECRYPT II 131. Vetky daje v tabuke s uveden v bitoch a s to
minimlne, navzjom ekvivalentn dky parametrov.
Symetrick k
Ochrana
4 roky
20 rokov
30 rokov
80
112
128
256
Vstup haovacej
funkcie
160
224
256
512
RSA modul
Eliptick krivka
1248
2432
3248
15424
160
224
256
512
V praxi je pouit dka kov diktovan hlavne tm, ak algoritmy a dky kov podporuj
tandardn kryptografick kninice/aplikcie. V prpade certifiktov verejnch kov s dky
ovplyvnen tm, ak verejn ke je ochotn certifikova vybran certifikan autorita.
Prehad mono njs na strnke http://www.keylength.com/

Zdroj: ECRYPT II Yearly Report on Algorithms and Keysizes, 2012
http://www.ecrypt.eu.org/documents/D.SPA.20.pdf
130
131
232
Ak sa pozrieme na verejn ke v certifiktoch 14 bnk a stavebnch sporiten so sdlom na

zem SR (stav k jlu 2013) zistme, e 11 z nich pouva na zabezpeenie internetbankingu
certifikt s RSA kom dky 2048 bitov, jedna certifikt s RSA kom dky 1024 bitov a dve
neposkytuj cez internet sluby, ktor by vyadovali zabezpeen komunikciu (teda
nepouvaj SSL/TLS). Analogick preskmanie monost SSL/TLS spojenia pre 10
najpopulrnejch webov (ako s google, facebook, baidu a pod. 132 ) uke nasledujce fakty
o verejnch kov v certifiktoch: 4 krt pouit RSA-2048, 3 krt pouit RSA-1024, 1 krt
ECDSA-256 a jeden web bez monosti SSL/TLS.
Predlovanie kov v certifiktoch zrove zvyuje vpotov zloitos operci a teda nroky
na server, ktor nadvzuje spojenia s vekm potom klientov (ilustran vkonov
charakteristiky s uveden v asti 6.1).
9.5.2
Ukladanie hesiel a kov
Hesl s stle najpouvanejm pouvateskm autentizanm mechanizmom. Pre znenie

dopadov kompromitcie servera, straty dvernosti zlohy servera, prpadne aktivt zlovonho
administrtora sa pouvatesk hesl v aplikcii/systme nemaj uklada v otvorenom tvare.
Idea je poui vhodn jednosmern transforman funkciu, ozname ju T, na spracovanie hesla
a uloi v aplikcii jej vsledok T(heslo). Pri autentizcii pouvatea sa nsledne zadan heslo
transformuje danou funkciou a vsledok sa porovn s uloenm vsledkom. V prpade zhody je
autentizcia pouvatea spen. Na ukladanie hesiel sa zvykn pouva pecilne navrhnut
funkcie ako napr. PBKFD2 (tto funkcia je pvodne navrhnut na odvodenie symetrickch
kryptografickch kov z pouvateskho hesla). Dleitmi bezpenostnmi parametrami
takchto funkci s:
Potadlo iterci sli na jednoduch riadenie rchlosti transformanej funkcie T. T je

iteratvna a nastavenm potadla je mon vpoet spomaova na elan rove.
Ukladanie hesiel je jednm z mla prkladov, ke je vysok vkon kryptografickej
kontrukcie prekkou bezpenosti. Pokia toti tonk zska hodnotu
transformovanho hesla T(heslo), doke testova potencilne hesl opakovanm
vpotom funkcie T pre rzne hesl a nslednm porovnanm vsledku s T(heslo).
Samozrejme, zvyovanie potadla spomauje aj ben overovanie hesla v aplikcii.
Avak km povedzme 1000 nsobn spomalenie z 0.5 ms na 0.5 sekundy je pre
pouvatea pri prihlsen urite akceptovaten, spomalenie toku preberanm hesiel
povedzme z 1 mesiaca na 1000 mesiacov (83,3 roka) rob tento tok nerealistickm.
Navye, obvykl politiky hesiel vynucuj zmenu hesla v kratch intervaloch.
So zvyajne nhodn reazec pridvan pri spracovan hesla. So je volen pre
kadho pouvatea zvl a zabezpeuje, e rovnak hesl sa pre rznych pouvateov
transformuj do rznych vsledkov. V opanom prpade, teda bez soli, tonk doke
testova hesl paralelne pre vetky zskan hodnoty T = {T(heslo 1 ), ..., T(heslo r )}.
Alternatvne doke tonk predvypota hodnoty asto pouvanch hesiel a po
kompromitcii transformovanch hesiel T paralelne vyhadva zhodu. Pouitie soli tieto
toky redukuje op na toky na individulne hesl.
Na zver k heslm pripomeme, e ubovon spsob uloenia hesiel nezvi odolnos slabch
hesiel voi slovnkovmu toku.
Bezpenos kryptografickch kontrukci podstatne zvis na uloen a pouvan kov. Jednou
z monost je pouitie tzv. hardvrovch bezpenostnch modulov (Hardware Security Module),
ktor zrove vykonvaj kryptografick opercie bez toho, aby ke opustili modul. Inak s
ke zvyajne uloen v sbore, priom jednm zo tandardnch formtov je PKCS#12. Tento
formt umouje ukladanie pouvateskch skromnch kov, certifiktov, symetrickch
poda rebrka popularity strnok hodnotenej spolonosou Alexa k mju 2013
(http://www.alexa.com/topsites)
132
233
kov a pod., priom podporuje rzne kombincie mdov pre dosiahnutie skromia a integrity
(obvykl kombincia vyuva symetrick mechanizmy odvdzajce ke z pouvateskho
hesla):
9.5.3
Md pre skromie ifrovanie prostrednctvom asymetrickej schmy, resp.

prostrednctvom symetrickho algoritmu s kom odvodenm z hesla.
Md pre integritu autentizan kd prostrednctvom HMAC s kom odvodenm
z hesla, resp. digitlny podpis prostrednctvom asymetrickej schmy.
Implementan a prevdzkov slabiny
Prinou viny tokov na implementovan kryptografick kontrukcie s slabiny v sprve

kov a slabiny v implementcii. V prpade protokolov je zvyajne problm v samotnom
protokole, bez ohadu na kryptografick silu/kvalitu pouitch algoritmov.
Bezpen implementcia kryptografickch kontrukci nie je trivilna loha. Vo veobecnosti
sta jedna implementan chyba (nedostatok) na naruenie bezpenostnch poiadaviek,
kompromitciu dajov alebo kov. Situcia je komplikovan tm, e niektor implementan
nedostatky neovplyvuj funknos, teda nie s vidie a pouvate ich nepocti. Uvedieme
niekoko prkladov:
toky postrannmi kanlmi (side-channel attacks) toky tohto typu vyuvaj

informcie zskan z prostredia ovplyvnenho kryptografickou operciou na zskanie
ka alebo chrnench dajov. Naprklad tzv. timing tok, ktor vyuva situciu,
ke dka asu vpotu zvis na hodnote ka a spracvanch dajoch. Ak pouijeme
tandardn 133 implementciu RSA, tak tatistickm spracovanm vieho mnostva
vzoriek typu (zaifrovan text, as deifrovania) mono zska skromn RSA k.
Podobne elektrick prkon najm jednoduchch zariaden, ako s napr. ipov karta
alebo integrovan obvod, je ovplyvnen prve vykonvanmi intrukciami. Tie vak
mu pri nevhodnej implementcii zvisie na hodnote ka, take pozorovanm zmien
v prkone zariadenia mono zska informciu o ki alebo rovno cel k.
Jednoduch prklad postrannho kanla je zvuk. Existuj experimenty, ktor
rekontruuj text/heslo na zklade zvuku vydvanho stlaenm jednotlivch klves na
klvesnici 134, PIN kdy na zklade triangulcie zvuku stlaenia klves na bankomate,
text na zklade zvuku vydvanho ihlikovou tlaiarou a pod. alm prkladom je
rekontrukcia PIN kdu s vyuitm informcie z pohybovho senzora telefnu alebo
gyroskopu, kee dotyky na pecifick miesta na obrazovke menia polohu telefnu 135.
Slabiny zaveden nesplnenm bezpenostnch predpokladov kryptografickch
kontrukci. Typickm predpokladom je naprklad nhodnos niektorch parametrov
v kontrukcich, ponc generovanm samotnch kov, pokraujc inicializanmi
vektormi, parametrami vplovch schm a pod. Zaujmav vskum v roku 2012
odhalil, e pribline 0,5% verejnch RSA kov v TLS certifiktoch na webe, ktor
bolo mon faktorizova a teda zska skromn k vaka tomu, e mali spolon
faktor s inm verejnm kom 136 . Dvodom bola nzka nhodnos pri generovan
kov, teda rovnako inicializovan genertor. Hoci ilo najm o embedded zariadenia
ako smerovae, VPN zariadenia, tlaiarne a pod., poukazuje to na nedostatky v
implementcii. Inm prkladom nzkej nhodnosti pri generovan kov bola upraven
implementcia openssl v Linuxovej distribcii Debian v rokoch 2006 a 2008, ktor
133
teda bez ochrany pred timing tokom

spenos rekontrukcie 10 znakovho hesla 69% pri 20 pokusoch tonka, Zdroj: L. Zhuang, F. Zhou,
J. D. Tygar: Keyboard Acoustic Emanations Revisited, ACM Transactions on Information and Systems
Security, Vol. 13, No. 1, pp 3:1-3:26, 2009.
135
Naprklad: L. Cai and H. Chen: On the Practicality of Motion Based Keystroke Inference Attack, 5th
International Conference on Trust & Trustworthy Computing, 2012.
136
Zdroj: https://factorable.net/
134
234
pokodila inicializciu pseudonhodnho genertora a viedla naprklad k obmedzenmu

potu prvosel (a teda RSA kov), ktor openssl dokzalo generova.
Slabiny v kryptografickch protokoloch minulos (aj sasnos) je dokladom toho, e
bezpen kryptografick protokoly je ak navrhn, implementova aj bezpene
pouva. Ilustratvnym prkladom je najpouvanej kryptografick protokol sasnosti
na webe SSL/TLS. Od vodnej verzie SSL v roku 1994 preiel vvoj protokolu
viacermi iterciami a verziami, ktor odstraovali (aj) bezpenostn slabiny. Napriek
tomu bol naprklad v roku 2009 zverejnen tzv. renegotiation tok, v roku 2011
BEAST tok, a v roku 2013 BREACH tok alebo lucky 13 tok 137 . Na druhej
strane, ambcia navrhn vlastn kryptografick protokol, podobne ako in
kryptografick kontrukciu, dopadne s vysokou pravdepodobnosou z bezpenostnho
hadiska ete horie.
Slab kryptografick algoritmy postupne s zriedkavejie prpady pouitia slabch
kryptografickch algoritmov. Svis to s dostupnosou implementci tandardnch
kontrukci, preto sa mlo vvojrov poka navrhn a implementova vlastn
kontrukcie. Prkladom slabho algoritmu je CSS (Content Scramble System), prdov
ifra uren na ifrovanie DVD, ktor nielene pouva 40 bitov k, ale navye je
mon na tento k toi ete podstatne efektvnejie ako prebranm vetkch 240
kov.
toky zavedenm chb (fault injection attacks) - vyuvaj monos poas vpotu
kryptografickej opercie spsobi nejak (vhodn) chybu vpotu. Potencilnymi
prostriedkami s znenia naptia, manipulcia s hodinovm signlom, zvenie teploty
a pod. Nslednou analzou chybnch vsledkov opercie je mon zska k 138.
Z hadiska zsad implementcie kryptografickch kontrukci mono odporui napr. NIST

Special Publication 800-21 Guideline for Implementing Cryptography In the Federal
Government 139.
9.6 Ilustran prklady

9.6.1
Vkonov porovnanie
V tejto asti uvedieme vkonov porovnanie vybranch kryptografickch algoritmov. Konkrtny

vkon sa me dramaticky li pri rznych platformch, implementcich, mdoch a pod.
Uveden hodnoty skr ilustruj relatvne vkonov rozdiely medzi jednotlivmi algoritmami.
Hodnoty boli zskan v nasledujcom prostred:
Platforma: procesor i7-2600, 3.40GHz, operan systm Ubuntu 12.04 LTS 64-bit
Implementcia: openssl 1.0.1
Vkonov charakteristiky pre ifrovanie a haovanie zodpovedaj spracovaniu 8kB blokov,
priom kryptografick opercie vykonvalo jedno aplikan vlkno (thread). Vo veobecnosti je
z tabuky badaten vznamn rozdiel medzi vkonom kryptografickch operci s hardvrovou
podporou a bez nej. Povimnutiahodn je aj rozdiel vkonu ifrovania a deifrovania
s hardvrovou podporou pri CBC mde. Tu sa prejavuje pipelining pri hardvrovej
implementcii paralelizovatench operci (napriek jednmu vlknu).
Prehad niektorch slabn s SSL/TLS mono njs v Ch. Meyer, J. Schwenk: Lessons Learned From
Previous SSL/TLS Attacks A Brief Chronology Of Attacks And Weaknesses,
(http://eprint.iacr.org/2013/049.pdf)
138
Naprklad prehad: A. Barenghi et al.: Fault Injection Attacks on Cryptographic Devices: Theory,
Practice, and Countermeasures, Proceedings of the IEEE, Vol. 100, Issue 11, pp. 30563076, 2012.
139
K dispozcii na http://csrc.nist.gov/publications/nistpubs/800-21-1/sp800-21-1_Dec2005.pdf
137
235
SW impl.
[MB/s]
AES-128-CTR
AES-128-CBC
AES-192-CBC
AES-256-CBC
3DES-CBC
RC4
SHA-1
SHA-256
SHA-512
127
106
90
28
891
717
215
335
HW podpora
AES-NI
(encrypt)
[MB/s]
4 125
749
623
537
HW podpora
AES-NI
(decrypt)
[MB/s]
4 121
4 064
3 509
3 055
Nasledujca tabuka porovnva vkon podpisovch schm RSA a ECDSA pri rznych dkach
kov. V prpade ECDSA je zvolen jedna zo sd eliptickch kriviek odporanch NIST 140.
V prpade RSA schmy je to zrove indikcia vkonu ifrovacej a deifrovacej transformcie
schm s rovnako dlhmi kmi. Pri interpretcii vsledkov je uiton uvedomi si, ak s
ekvivalentn dky kov medzi oboma schmami (pozri as 5.1).
RSA-1024
RSA-2048
RSA-4096
ECDSA-224
(nistp224)
ECDSA-256
(nistp256)
ECDSA-521
(nistp521)
9.6.2
podpisovanie
[opercie/s]
6 100
857
118
15 375
overovanie
[opercie/s]
93 281
27 496
7 370
7 349
9 024
3 697
3 252
1 501
S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions) je tandard pre ifrovanie a

podpisovanie elektronickej poty, podporovan vinou mailovch klientov (napr. Outlook,
Lotus Notes, Thuderbird). V prpade webovch potovch sluieb je zvyajne potrebn podporu
S/MIME riei doplnkami prehliadaov. Verejn ke pouvateov s distribuovan vo forme
X.509 certifiktov. Formt sprv je definovan ako CMS (Cryptographic Message Syntax).
V S/MIME sa pouvaj obvykl a tandardn kryptografick kontrukcie. Prehad povinne
implementovanch kontrukci v ostatnch troch verzich S/MIME je uveden v nasledujcej
tabuke (podotknime, e implementcie samozrejme zahaj podstatne iriu sadu algoritmov
kvli vzjomnej interoperabilite aj sptnej kompatibilite).
140
Zdroj: NIST: FIPS PUB 186-4 Digital Signature Standard (DSS), 2013.
236
Povinn v CMS
(MUST)
Haovacia funkcia
Podpisov schma
ka
Symetrick ifrovanie
3.0 (RFC 2633)

1999
SHA-1
DSA
DH
3.1 (RFC 3851)

2004
SHA-1
RSA, DSA
RSA
3DES CBC
3DES CBC
3.2 (RFC 5751)

2010
SHA-256
RSA
RSA
AES-128 CBC
In rieenie pre zabezpeenie dvernosti a autentickosti elektronickej poty je tandard OpenPGP

(s vone dostupnou implementciou GnuPG). Hlavn rozdiel oproti S/MIME je jednoduch
spsob sprvy a distribcie kov bez pouitia certifiktov, vzieb na certifikan autority
a pod. Inak poskytuje OpenPGP podobn kryptografick rieenie ako S/MIME. Pouitie
v mailovch klientoch vyaduje obvykle intalciu doplnku. OpenPGP formt sa asto pouva aj
pri podpisovan sborov, napr. pri distribcii softvrovch balkov.
9.7 Praktick rady na zver

Cieom tejto asti je ponknu niektor zkladn praktick rady tkajce sa vberu a pouitia
kryptografickch kontrukci. Odporania nie s vyerpvajce, s isto subjektvne a mu
existova aj in nzory.
Odporania
Uprednostnite AES-256 a SHA-512 pred inmi symetrickmi iframi a
haovacmi funkciami
Ak mete, uprednostnite schmy zaloen na eliptickch krivkch
Ak pouvate RSA schmy, uprednostnite RSA-OAEP pre ifrovanie a
RSA-PSS pre podpisovanie
Pouite haovaciu funkciu s dvojnsobnou dkou odtlaku ako je dka symetrickho ka
Hesl ukladajte a overujte vhodnm spsobom (algoritmus, so, potadlo)
Analyzujte innos aplikcie, ak kryptografick sluby (napr. pre overenie platnosti certifiktu) nebud k dispozcii
V praxi astokrt poiadavky na funknos a pohodlie vazia nad bezpenosou dbajte, aby to nebolo K.O.
237
9.8 Prlohy ilustran prklady

Ilustran prklady vyuvaj program openssl vo verzii 1.0.1.
A RSA schmy
Generovanie intancie RSA schmy (nerozliujeme, i je uren na ifrovanie alebo pre
podpisov schmu) s dkou ka 2048 bitov:
$ openssl genrsa -out myrsa.pem 2048
Generating RSA private key, 2048 bit long modulus
.............................+++
..........+++
e is 65537 (0x10001)
Poznamenajme, e v naom prklade je k uloen neifrovane, hoci openssl umouje k aj

ifrova s pouitm hesla. V sbore myrsa.pem s uloen jednotliv parametre RSA intancie
(samotn sbor obsahuje dta vo formte PEM kdovan v base64, ktor s v nasledujcom
vstupe zobrazen v asti writing RSA key). Vo vstupe s pre skrtenie vstupu vynechan
niektor riadky. K vznamu jednotlivch hodnt (pozri aj as 3.1, priom hodnoty exponent1,
exponent2 a coefficient s pouit na urchovanie skromnej RSA transformcie):
modulus hodnota
publicExponent hodnota
privateExponent hodnota
prime1, prime2 prvosla , (bez ujmy na veobecnosti v tomto porad)
exponent1, exponent2 hodnoty mod ( 1) a mod ( 1)
coefficient hodnota 1 mod
$ openssl rsa -in myrsa.pem -text

Private-Key: (2048 bit)
modulus:
00:b0:0d:cc:b8:65:95:4e:df:b2:f4:be:8d:1d:09:
c4:40:85:5b:3a:5a:c4:d7:97:07:12:dc:7b:43:9b:
<vynechanch alch 15 riadkov>
ec:ab
publicExponent: 65537 (0x10001)
privateExponent:
4f:63:99:aa:99:5c:4f:f9:fe:27:f1:79:8e:db:a5:
9c:f6:c5:e1:b5:a6:c8:15:39:c2:5e:9c:53:2b:81:
41
prime1:
00:e6:31:61:79:7c:85:69:79:f9:7c:eb:c2:c1:4a:
53:7a:96:02:77:c5:64:98:65:58:09:fb:be:62:22:
69:59:64:b7:3f:0f:a5:7e:cb
prime2:
00:c3:ca:9c:42:90:49:f2:9a:f8:84:b7:58:38:ff:
1f:7b:40:fa:fc:80:27:57:7f:ec:45:66:e9:79:26:
e0:47:52:4b:b6:2c:87:ad:a1
exponent1:
00:a5:ee:ee:be:ee:3e:15:7c:71:95:d5:35:3c:b4:
61:5c:ba:89:e8:e0:87:d5:3b:28:ad:79:a5:11:84:
d5:52:35:41:ca:d9:72:88:e5
238
exponent2:
01:f1:1e:7f:a2:82:b9:3f:44:3b:bc:bd:c9:42:ee:
83:00:6f:fc:d5:20:8e:c3:9c:0a:4c:2d:00:a0:9a:
12:a5:04:4f:38:3d:d8:41
coefficient:
4d:63:0d:03:cb:79:54:5c:a9:1e:28:a4:2d:27:01:
2c:6c:62:50:78:73:99:3e:cd:0a:06:6a:12:8f:42:
57:c4:fb:72:df:e0:40:07
writing RSA key
-----BEGIN RSA PRIVATE KEY----MIIEowIBAAKCAQEAsA3MuGWVTt+y9L6NHQnEQIVbOlrE15cHEtx7Q5vLfYhcgW5S
x1K8R+JSNYOOWbPmJrjzYqpgOz1roMnvpoxjSGK8SOYUk2es/6ZX/K4voHUDrsSc
yJ1rkaR3DKNMeKXW8M4YPPTH/CR1trDlgs4sUF2YS1fE+3Lf4EAH
-----END RSA PRIVATE KEY-----
Extrakcia verejnho ka a jeho sasti:

$ openssl rsa -in myrsa.pem -pubout -out myrsa-pub.pem
writing RSA key
$ openssl rsa -pubin -in myrsa-pub.pem -text
Public-Key: (2048 bit)
Modulus:
00:b0:0d:cc:b8:65:95:4e:df:b2:f4:be:8d:1d:09:
c4:40:85:5b:3a:5a:c4:d7:97:07:12:dc:7b:43:9b:
ec:ab
Exponent: 65537 (0x10001)
writing RSA key
-----BEGIN PUBLIC KEY----MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsA3MuGWVTt+y9L6NHQnE
QIVbOlrE15cHEtx7Q5vLfYhcgW5Sx1K8R+JSNYOOWbPmJrjzYqpgOz1roMnvpoxj
<vynechan alie 4 riadky >
qwIDAQAB
-----END PUBLIC KEY-----
ifrovanie a deifrovanie krtkeho textu pomocou RSA a vplne PKCS #1 v1.5 (implicitn
voba):
$ echo 'Kryptologia II - pokusny text' | openssl pkeyutl -encrypt -pubin inkey myrsa-pub.pem -out cipher.bin
$ openssl pkeyutl -decrypt -inkey myrsa.pem -in cipher.bin
Kryptologia II - pokusny text
Podpsanie a overenie podpisu sboru Kipling-IF.txt pomocou RSA a vplne PKCS #1 v1.5
(implicitn voba), priom pouijeme haovaciu funkciu SHA-256:
$ cat Kipling-IF.txt | openssl dgst -sha256 -binary | openssl pkeyutl -sign
-inkey myrsa.pem -out sig.bin -pkeyopt digest:sha256
$ cat Kipling-IF.txt | openssl dgst -sha256 -binary | openssl pkeyutl verify -sigfile sig.bin -pubin -inkey myrsa-pub.pem -pkeyopt
digest:sha256
Signature Verified Successfully
239
B PKI objekty a opercie

Nasledujca opercia vygeneruje intanciu RSA schmy s dkou ka 2048 bitov. Skromn a
verejn k bud (neifrovan) uloen v sbore myrsa.pem. V sbore mycsr.csr je uloen
CSR pre potencilnu iados o vydanie certifiktu certifikanou autoritou.
$ openssl req -new -newkey rsa:2048 -keyout myrsa.pem -nodes -subj
"/C=SK/L=Bratislava/O=Pokusna spolocnost/CN=www.pokusna-spolocnost.sk"
-out mycsr.csr
Generating a 2048 bit RSA private key
...+++
...........................................+++
writing new private key to 'myrsa.pem'
-----
Pozrime sa na truktru informci v CSR, priom samotn sbor mycsr.csr obsahuje dta vo
formte PEM kdovan v base64, ktor s v nasledujcom vstupe zobrazen v asti ohranienej
BEGIN/END CERTIFICATE REQUEST.
$ openssl req -in mycsr.csr -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=SK, L=Bratislava, O=Pokusna spolocnost, CN=www.pokusnaspolocnost.sk
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:f2:27:84:8c:30:67:3f:24:f9:02:b4:e9:b1:f6:
dc:68:a0:c2:f3:8b:33:5f:e8:25:f0:4f:5d:e5:88:
70:3f
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
e9:d6:9d:a0:8a:df:1b:ec:0c:9e:11:ca:b7:14:5b:00:cd:a2:
6f:a6:45:a5:b3:55:3e:6d:3d:6a:42:fd:3e:55:94:8b:f6:6e:
15:44:de:c0
-----BEGIN CERTIFICATE REQUEST----MIICqDCCAZACAQAwYzELMAkGA1UEBhMCU0sxEzARBgNVBAcMCkJyYXRpc2xhdmEx
GzAZBgNVBAoMElBva3VzbmEgc3BvbG9jbm9zdDEiMCAGA1UEAwwZd3d3LnBva3Vz
d2noeLVJEc0VRN7A
-----END CERTIFICATE REQUEST----Samopodpsan certifikt zskame (vrtane novej RSA intancie) naprklad takto:
$ openssl req -new -newkey rsa:2048 -keyout myrsa2.pem -nodes -subj
"/C=SK/L=Bratislava/O=Pokusna spolocnost/CN=www.pokusna-spolocnost.sk"
-x509 -days 1000 -out mycer2.cer
V nasledovnom ilustrujeme overenie certifiktu Ministerstva spravodlivosti SR pomocou OCSP.

MS SR m certifikt pre webov server vydan certifikanou autoritou GoDaddy (certifikt bol
uloen do sboru www.justice.gov.sk.pem):
$ openssl x509 -in www.justice.gov.sk.pem -serial -subject -issuer ocsp_uri -noout
240
serial=4B314FE688F8BC
subject= /OU=Domain Control Validated/CN=www.justice.gov.sk
issuer= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure
Certification Authority/serialNumber=07969287
http://ocsp.godaddy.com/
Overenie certifiktu pomocou OCSP nm poskytne tto odpove z certifikanej autority (v

sbore GoDaddy.pem je uloen certifikt CA, url adresa pre OCSP je z certifiktu MS SR
a sriov slo je taktie z tohto certifiktu):
$ openssl ocsp -nonce -issuer GoDaddyCA.pem -url http://ocsp.godaddy.com/ serial 0x4B314FE688F8BC
WARNING: no nonce in response
Response verify OK
0x4B314FE688F8BC: good
This Update: Aug 8 20:53:53 2013 GMT
Next Update: Aug 9 02:53:53 2013 GMT
Poznamenajme, e uveden vstup je len zostrunen verzia odpovede so zkladnmi

informciami. Podrobnej pohad na obsah OCSP dopytu a nslednej odpovede zskame
pridanm voby -text do prkazovho riadku. Za zmienku stoj varovanie, ktor hovor, e
odpove neobsahovala nonce a teda nie je vytvoren v momente dopytu, kee server
nepodporuje prslun rozrenie OCSP.
241
10 Siete, internet a telekomunikcie

Ladislav Hudec
Tto kapitola uebnch textov sa venuje bezpenosti potaovch siet a Internetu. Pokia boli
potae samostojace zariadenia bez pripojenia do inch systmov, bolo mon ich bezpenos
zaisti najm prostriedkami fyzickej bezpenosti, prpadne antivrusovmi nstrojmi na kontrolu
pouvanch externch pamovch mdi (naprklad prun disk). Snaha o spolon vyuvanie
najm drahch zariaden (naprklad farebn tlaiare) doviedla nvrhrov potaov k potrebe
vytvorenia monosti komunikcie medzi jednotlivmi samostojacimi potami a k vytvoreniu
potaovch siet. Pripojenie jednotlivch potaov do zostavy potaovej siete prinieslo
samozrejme alie a nov bezpenostn problmy. Rozahlos dnench potaovch siet
mono njs v mierke od potaovej siete v rmci jednej kancelrie alebo budovy a po svetov
potaov sie vytvoren s podporou telekomunikanch zariaden prakticky po celom svete.
A prve tto rozahlos potaovch siet a Internetu predstavuje zven monosti pre kodliv
aktivity, pretoe ponka vea miest prstupu do sieti.
Tmaticky mono tto kapitolu rozdeli na p ast. Tieto asti pokrvaj relevantn oblasti
bezpenosti v potaovch sieach a v Internete. V prvej asti s vysvetlen zkladn vlastnosti
systmu domnovch mien (DNS) a prklady tokov na tento systm. DNS predstavuje zkladn
stavebn kame potaovch siet a Internetu, pretoe bez neho nebud fungova alebo
fungova iba s akosami najpouvanejie sieov sluby ako je elektronick pota a webov
servery (systmy www). Druh as je venovan opisu elektronickej poty. Od zkladnej
funkcionality, kedy sprvy elektronickej poty mohli by iba obyajn texty napsan v kde USASCII, cez vylepen verziu MIME a po bezpen verziu S/MIME. V tretej asti je opsan
protokol HTTP. Tento protokol je asi najviac pouvanm aplikanm protokolom v Internete,
pretoe okrem inho zabezpeuje komunikciu klienta do sdel celosvetovej pavuiny www.
tvrt as je venovan vysvetleniu zkladnch koncepci virtulnych privtnych siet. Koncept
VPN je dleit pri bezpenom a cenovo efektvnom pripjan klienta k potaovej sieti
organizcie, pri vzdialenom prstupe k vybratm prostriedkom potaovej sieti organizcie ako
aj pri prepjan intranetov geograficky vzdialench sast jednej organizcie. V poslednej piatej
asti s opsan princpy fungovania nstrojov na detekciu alebo prevenciu pred prienikmi IDPS
do potaovej sieti. i sa u jedn o pevn sie alebo bezdrtov sie. S analyzovan detekn
vlastnosti a monosti nstrojov IDPS takisto ako ich umiestnenie v truktre sieti. Za kadou
asou uebnch textov s uveden zdroje, z ktorch erpal autor a ktor si me itate prpadne
pretudova. Tto monos sa ponka itateovi z toho dvodu, e prednky k jednotlivm
tmam s asovo obmedzen a nemu podrobne obsiahnu vetky prpadn poadovan detaily
tmy.
Vber tm ako aj tudijn text je napsan tak, e predpoklad znalosti zo sieovch technolgi
aspo na rovni zkladnch univerzitnch kurzov sieovch technolgi, prpadne znalost
zkladnch kurzov CCNA (Cisco Certified Network Associate) spolonosti CISCO.
10.1 Systm DNS

Smerovanie komunikcie v potaovch sieach medzi dvomi koncovmi potami sa
vykonva na zklade adries IP. In povedan, komunikujce koncov uzly sa identifikuj
adresami IP. seln vyjadrenie adresy IP je pre loveka obtiane na zapamtanie a navye adresa
IP toho istho sieovho rozhrania potaa sa me obas aj zmeni. Preto sa namiesto adresy IP
sieovho rozhrania zavdza meno sieovho rozhrania. Pre kad adresu IP mme teda
zaveden meno sieovho rozhrania (potaa), presnejie povedan domnov meno (domain
name). Toto domnov meno meme pouva namiesto adresy IP okrem identifikcie
242
Siete, internet a telekomunikcie | MF SR
samotnho mennho servera (name server), kde sa mus poui IP adresa. Treba ete
poznamena, e jedna IP adresa me ma priradench aj niekoko domnovch mien.
Meno sieovho rozhrania potaa a jemu pridelan adresa IP je definovan v databze DNS
(Domain Name System). DNS je celosvetovo distribuovan databza. Jednotliv asti tejto
databze s umiestnen na tzv. name (mennch) serveroch. Zkladn koncepcia systmu DNS
je pecifikovan v dokumentoch [RFC 1034] a [RFC 1035] iniciatvnej skupiny IETF (Internet
Engineering Task Force, iniciatvna skupina tvorby internetovch tandardov RFC). Princp
innosti systmu DNS je na Obrzku . 10.1.
Obrzok . 10.1: Princp innosti systmu DNS

10.1.1 Domny, subdomny a zny
Prostriedky Internetu s rozdelen do tzv. domn. Koncepciu vytvrania domn mono
demontrova na prklade vekej organizcie, ktor je registrovan na Slovensku. Na ele
organizcie je generlny riadite. Pretoe vak on neme robi vetko, bude organizcia
pravdepodobne rozdelen na sekcie. Kad sekcia m urit obmedzen autonmiu. Riadite
sekcie m prvomoc urobi priame rozhodnutie bez toho, aby si ptal povolenie od generlneho
riaditea. Podobne riadite sekcie neme robi v sekcii vetko, bude sekcia pravdepodobne
rozdelen na odbory. Kad odbor m urit obmedzen autonmiu. Riadite odboru m
prvomoc urobi priame rozhodnutie bez toho, aby si ptal povolenie od riaditea sekcie.
Domnov men s tvoren podobnm spsobom a bud asto odra hierarchick delegovanie
prvomoc. Uvaujme naprklad meno:
mojpocitac.mojeoddelenie.mojodbor.mojasekcia.mojaorganizacia.sk.
V tomto prklade vieme, e existuje jedno meno uzla mojpocitac, ktor sa nachdza
v subdomne
mojeoddelenie.mojodbor.mojasekcia.mojaorganizacia.sk.
Subdomna
mojeoddelenie.mojodbor.mojasekcia.mojaorganizacia.sk je jednou sudbdomnou domny
mojodbor.mojasekcia.mojaorganizacia.sk, at. Nakoniec je subdomna mojaorganizacia.sk jedna
zo subdomn domny sk.
Keby sme chceli zoveobecni vyie uveden prklad, tak meme poveda, e meno domny sa
uvdza v bodkovej notci a m veobecn syntax: reazec. reazec. reazec.... reazec., kde
prv reazec je meno potaa (rozhrania), al reazec je meno najniej vnorenej domny,
al vyej domny at. Pre jednoznanos sa na konci uvdza tie bodka, vyjadrujca
koreov (root) domnu.
243
Obrzok . 10.2: Hierarchick usporiadanie domn

Na obrzku . 10.2 je naznaen hierarchick usporiadanie domn. V koreni stromu je koreov
domna. Poiadavky na jej prevdzku s pecifikovan v [RFC 2870]. Subdomny koreovej
domny, tie nazvan domny najvyej rovni (TLD Top Level Domain), s dvojakho
typu. Jednak s to domny ttov ako je naprklad Slovensk republika (meno domny sk),
esk republika (meno domny cz). Men domn ttov s dvojpsmenov poda
medzinrodnch kdov ttov v zmysle normy ISO 3166. Potom s to tak zvan generick
domny. Tieto domny boli zaveden v poiatkoch Internetu a zachovali sa doposia. Prkladom
generickej domny je americk vldna domna (meno domny gov) alebo domna vzdelvacch
intitci (meno domny edu). Domny ttov s spravovan nrodnmi autoritami a registrciu
domn druhej rovni, tie nazvan aj domny podnikovej rovne (ELD Enterprise Level
Domain), za-bezpeuj tieto nrodn autority.
Domny druhej rovne si vinou spravuj na svojich mennch serveroch majitelia domny
alebo ich poskytovatelia internetovch sluieb. daje pre domnu druhej rovne napr. stuba.sk
nie s na rovnakom name serveri ako domna sk. S rozloen na mnoho mennch serverov.
daje o domne uloen na jednom mennom serveri s nazvan znou (zone file). Zna teda
obsahuje iba as domny. Zna je as priestoru mien, ktor obhospodaruje jeden menn server.
Obrzok . 10.3: Zna stuba.sk

Na Obrzku . 10.3 je znzornen, ako me by (hypoteticky) v domne stuba.sk
decentralizovan kompetencia (delegovanie) na niie sprvne celky. Take domna stuba.sk
obsahuje v sebe vetky subdomny, ale zna stuba.sk delegovala na in menn servery
prvomoci na zny fiit.stuba.sk, mtf.stuba.sk a fei.stuba.sk. Take zna stuba.sk obsahuje
domnu stuba.sk a na tri uveden vnimky. alie podrobnosti mono njs v [RFC 1591],
[RFC 1995], [RFC 1995] a [RFC 2136].
244
10.1.2 Preklad mena domny

Proces prekladu (rezolvencie) mena domny na adresu IP mono zhrn do tchto krokov:
1
Pouvatesk program zad poiadavku operanmu systmu (komponentu s nzvom

resolver) na preklad mena domny na adresu IP (prpadne preklad adresy IP na meno
domny).
Resolver sformuluje dopyt na menn server. Plnohodnotn (full) resolver m vyrovnvaciu
pam (pam cache), do ktorej uklad vsledky predolch dopytov na menn server. Zist,
i vo vyrovnvacej pamti m odpove na zadan dopyt. Ak no, odpove uloen v cache
pouije. Pahov (stub) resolver vyrovnvaciu pam nem.
Menn server skontroluje, i sa odpove na dopyt resolvera nachdza v jeho loklnej
autoritatvnej databze (databza obsahuje autoritatvne - nespochybniten daje) alebo vo
vyrovnvacej pamti, a ak no, potom vrti resolveru tto odpove. Ak nie, potom sa
menn server dopytuje alch dostupnch mennch serverov, ponc koreom stromu
DNS smerom nadol alebo tak vysoko v strome ako je to mon.
Pouvatesk program nakoniec dostane odpovedajcu adresu IP (alebo meno domny)
alebo chybov sprvu v prpade, e na dopyt sa ned odpoveda. tandardne sa programu
neposiela zoznam mennch serverov, ktor sa podieali na preklade.
Preklad mena domny je proces klient/server. Funkcia klienta (nazvan resolver alebo menn
resolver) je pre pouvatea transparentn a je volan aplikciou na preklad symbolickch vysoko
rovovch mien na relne adresy IP (alebo naopak). Menn server (oznaovan aj domnov
menn server) je serverov aplikcia zabezpeujca preklad medzi vysoko rovovmi menami
potaov a adresami IP. Sprvy dopytu a odpovede pri komunikcii resolvera s mennm
serverom a medzi mennmi servermi s prenan protokolom TCP alebo UDP.
Obrzok . 10.4: Pouitie plnho resolvera na preklad mena domny

Na Obrzku . 10.4 je znzornen princp funkcie programu operanho systmu s plnm
resolverom. Pouvatesk program iada pln resolver o preklad a ten potom (ak nem odpove
vo svojej vyrovnvacej pamti) prpadne alej iada menn server o preklad. Odpovede na
dopyty pln resolver odovzd pouvateskmu programu a tie si odpove ulo
do vyrovnvacej pamti pre budce pouitie.
Na Obrzku . 10.5 je znzornen princp funkcie programu operanho systmu s pahovm
resolverom. Pahov resolver je rutina nalinkovan s pouvateskm programom a postupuje
dopyty mennmu serveru na preklad. Odpovede na dopyty si uklad menn server do cache (a
nie pahov resolver). Na vine platforiem je pahov resolver implementovan
knininmi rutinami a tento typ resolvera sa vyskytuje ovea viac ako pln resolver.
245
Obrzok . 10.5: Pouitie pahovho resolvera na preklad mena domny

Dopyty na meno domny mu by dvojakho typu a to rekurzvne alebo iteratvne. Prznak
v dopyte na meno domny indikuje, i si klient poaduje rekurzvny dopyt a prznakov bit v
odpovedi uruje, i server podporuje rekurzvne dopyty. Rozdiel medzi rekurzvnym
a iteratvnym dopytom sa uke v prpade, ke menn server dostane iados, na ktor neme
pln odpove poskytn sm. Rekurzvny dopyt poaduje, aby server sm vydal dopyt na
zistenie poadovanch informci a vrtil klientovi pln odpove. Iteratvny dopyt znamen, e
menn server vrti klientovi tak informcie, ktor m k dispozcii, a klientovi vrti tie zoznam
alch serverov, ktor by mal klient kontaktova na skompletizovanie dopytu.
Odpovede na meno domny me by dvojakho typu a to autoritatvne alebo neautoritatvne.
Prznakov bit v odpovedi indikuje o ak typ odpovedi ide. Ke menn server dostane dopyt pre
domnu v zne, nad ktorou m oprvnenia (autoritu), menn server vrti vetky poadovan
informcie v odpovedi s nastavenm prznakom autoritatvna odpove. Ke obdr dopyt pre
domnu, nad ktorou nem oprvnenia (autoritu), jeho akcie s zvisl na nastaven prznaku
poiadavky rekurzie v dopyte:
Ke prznakov bit poiadavky rekurzie je nastaven a server podporuje rekurzvne

dopyty, server bude smerova svoj dopyt na al menn server. Bude to bu
autoritatvny menn server pre domnu pecifikovan v dopyte alebo to bude jeden z
koreovch mennch serverov. V prpade, e druh server nevrti autoritatvnu odpove
(naprklad, ak delegoval autoritu na in server), proces sa opakuje.
Ke server (alebo program plnho resolvera) dostane odpove, odpove ulo do
vyrovnvacej pamti z dvodu zlepenie priepustnosti pre opakovan dopyty. Odpove
je vo vyrovnvacej pamti uloen na pvodcom odpovede uren maximlnu dobu,
ktor je obsiahnut v 32 bitovom poli odpovede s nzvom TTL (Time To Live). Typick
hodnota TTL je 86400 seknd (jeden de).
Ke prznakov bit poiadavky rekurzie nie je nastaven alebo server nepodporuje
rekurzvne dopyty, server vrti akkovek informcie (relevantn dopytu) zo svojej
vyrovnvacej pamti a tie vrti zoznam alch mennch serverov, ktor musia by
kontaktovan pre autoritatvne informcie.
Menn server nemus ma autoritu nad iadnou znou, ale me ma autoritu nad jednou alebo
viacermi znami. V zsade je mon vyleni tri typy mennch serverov:
246
Primrny menn server. Tento server nata informcie o zne z disku a m autoritu nad
znou.
Sekundrny menn server. Tento menn server m autoritu nad znou, ale zskava
informcie o zne od primrneho servera prostrednctvom procesu znovho prenosu
(zone transfer). Aby boli informcie o zne na primrnom a sekundrnom serveri
synchronizovan, sekundrny server iada pravidelne o znov prenos (spravidla raz za

niekoko hodn) a primrny server aktivuje znov prenos v prpade aktualizcie
informci o zne. Menn server me fungova bu ako primrny alebo sekundrny
nmenn server pre viac domn alebo ako primrny pre niektor domny a ako
sekundrny pre ostatn. Primrny alebo sekundrny menn server pln vetky funkcie
caching only mennho servera (takto menn server m iba vyrovnvajcu pam).
Caching only menn server. Tento server nem autoritu nad iadnou znou. Vetky
daje zskava poda potreby od primrnych alebo sekundrnych mennch serverov. To si
vyaduje, aby obsahoval aspo jeden zznam NS (zznam o mennom serveri), ktor ho
odkazuje na menn server, z ktorho me inicilne zska informcie.
10.1.3 Zdrojov zznamy DNS

Distribuovan databza DNS sa sklad zo zznamov, ktorm hovorme zdrojov zznamy RR
(Resource Record). Zkladn typy zdrojovch zznamov s definovan v [RFC 1035], niektor
alie nov v [RFC 1183]. Tieto zznamy s rozdelen do tried. Ns bude zaujma iba trieda
internetovch zznamov. Zdrojov zznamy zabezpeuj mapovanie medzi menami domn a
sieovmi objektami. Najbenejie sieov objekty s adresy internetovch uzlov (hostov), ale
systm DNS je navrhnut tak, aby obsiahol irok rozsah rznych objektov.
Zna sa sklad zo skupiny zdrojovch zznamov zanajci zznamom SOA (Start Of
Authority). Zznam SOA identifikuje domnov meno zny. Bude sa tam nachdza zznam
o mennom serveri NS (Name Server) pre primrny menn server pre tto znu. Tie by sa tam
mohli nachdza zznamy NS pre sekundrne menn servery. Zznamy NS sa vyuvaj na
identifikciu autoritatvnych mennch serverov.
Na Obrzku . 10.6 je veobecn formt zdrojovho zznamu. Jednotliv polia vo formte maj
tento vznam:
247
Name je pole pre meno domny. Meno domny mus by definovan. Aj ke systm
DNS m vemi veobecn pravidl na vytvorenie domnovch mien odpora syntax pre
domnov men tak, aby minimalizovala pravdepodobnos chybnej interpretcie
domnovch mien aplikciami, ktor pouvaj resolver DNS. Domnov meno
repektujce odporan syntax by sa malo sklada z postupnosti reazcov, ktor
pozostvaj z alfanumerickch znakov alebo pomlky, priom kad reazec m dku 1
a 63 znakov zanajc psmenom. Kad pr reazcov je oddelen bodkou. Domnov
men nie s citliv na vekos psmen.
Type definuje typ zdroja v tomto zzname. Existuje viacero monch hodnt, ale
niektor z nich s benejie pouvan. Naprklad typ A (hodnota 1) predstavuje adresu
IPv4 hosta, typ NS (2) je autoritatvny mann server, typ CNAME (5) je kanonick meno
pre alias, typ SOA (6) je oznaenie zaiatku zny autority, typ KEY (25) je verejn k
zviazan s menom DNS, typ AAAA (28) je zznam adresy IPv6, at.
Class je oznaenie triedy rodinu protokolu. Jedinou bene pouvanou hodnotou je IN
(Internet systm).
TTL (Time To Live) je as v sekundch, poas ktorho je platn zdrojov zznam vo
vyrovnvacej pamti mennho servera. Tento as je uloen ako 32-bitov slo bez
znamienka. Typick hodnota pre zznamy ukazujce na adresy IP je 86400 (jeden de).
RDlength je cel 16-bitov slo bez znamienka, ktor pecifikuje v pote bajtov dku
poa RData.
RData je reazec bajtov s premenlivou dkou, ktor opisuje zdroj. Formt tchto
informci sa li poda typu a triedy zdrojovho zznamu.
Obrzku . 10.6: Veobecn formt zdrojovho zznamu

10.1.4 Sprvy DNS
Vetky sprvy v protokole DNS pouvaj jeden formt. Tento formt je zobrazen na Obrzku
. 10.7. Sprvu v tomto formte posiela resolver mennmu serveru. Resolver z tohto formtu
vyuva iba hlaviku sprvy (polia IDentification, Parameters, QDcount, ANcount, NScount,
ARcount) a sekciu otzky (Question Section). Odpovede a odovzdvanie dopytu vyuvaj ten
ist formt a s tm, e dopluj sekciu odpovedi, sekciu autority a sekciu alch informci
(Answer Section, Authority Section a Additional Information Section).
Hlavika sprvy m pevn dku 12 bajtov. Dky ostatnch sekci formtu sprvy s
premenliv. Jednotliv polia v hlavike sprvy maj tento vznam:
248
IDentification (ID) je 16 bitov identifikan slo sprvy. Tento identifiktor je

prekoprovan do odpovedi na dopyt (provanie dopytu a odpovedi) a me by pouit
na rozpoznanie odpovedi pri viacerch dopytoch zadanch v rovnakom ase.
Parameters je 16 bitov pole parametrov v takejto truktre:
Bit 0: prznak QR identifikuje dopyt (prznak nastaven na 1) alebo odpove (prznak
nastaven na 0)
Bity 1-4: prznak Op code je 4 bitov pole pecifikujce typ dopytu: 0 je tandardn
dopyt (QUERY), 1 je inverzn dopyt (IQUERY), 2 je iados o stav servera (STATUS)
Bit 5: prznak AA je prznak autoritatvnej odpovedi. Ak je nastaven v odpovedi na 1,
potom pecifikuje, e odpovedajci menn server je autoritou pre meno domny, ktor
bola poslan v dopyte
Bit 6: prznak TC je prznak skrtenia odpovedi. Prznak je nastaven, ak sprva bola
dlhia ako je dovolen dka pouitho transportnho protokolu UDP.
Bit 7: prznak RD je prznak poadujci rekurziu. Tento bit signalizuje mennmu
serveru, e sa poaduje rekurzvny preklad. Prznak je prekoprovan do odpovedi.
Bit 8: prznak RA je prznak dostupnosti rekurzie. Prznak indikuje, i menn server
podporuje rekurzvny preklad.
Bity 9-11: pole ZERO - 3 bity rezervovan pre budce pouitie, musia by nastaven na
0
Bity 12-15: pole Rcode - 4 bitov kd odpovede. Mon hodnoty tohto poa s 0 pre
bezchybn operciu, 1 pre chybu formtu (server nebol schopn interpretova sprvu), 2
pre poruchu servera (sprva nebola spracovan z dvodov problmov servera), 3 pre
chybu mena (meno domny v dopyte neexistuje, toto plat iba pri nastavenom prznaku
AA v odpovedi), 4 pre nie je implementovan (poadovan typ dopytu nie je na mennom
serveri implementovan), 5 pre odmietnutie (server odmieta odpoveda z dvodov
nastavenej politiky)
QDcount 16 bitov cel slo bez znamienka definujce poet poloiek v sekcii otzky
ANcount 16 bitov cel slo bez znamienka definujce poet zdrojovch zznamov
v sekcii odpovedi
NScount 16 bitov cel slo bez znamienka definujce poet zdrojovch zznamov
s mennmi servermi v sekcii autority
ARcount 16 bitov cel slo bez znamienka definujce poet zdrojovch zznamov
v sekcii dodatonch informci
Obrzku . 10.7: Formt sprvy DNS

Pole sekcie otzok (Question Section) vo formte sprvy DNS obsahuje dopyty pre menn
server, obsahuje QDcount (zvyajne 1) poloiek. alie tri polia sekci odpovede, autority
a alch informci (Answer Section, Authority Section a Additional Information Section)
obsahuj premenliv poet zdrojovch zznamov. Ich poet je definovan v odpovedajcich
poliach klaviky sprvy.
10.1.5 toky na DNS Man in the Middle
Analzou zkladnch tokov na systm DNS sa zaober tdia [SAI] (Security Associates
Institute). V nasedujcich astiach s uveden niektor z nich.
V prpade, e tonk je schopn odchytva komunikciu medzi klientom a DNS serverom,
potom tonk vie tie odchytva dopyty klienta na preklad mena a posla klientovi (namiesto
DNS servera) falon odpove, ktor mapuje meno domny na nesprvnu adresu IP.
Tento tok je zaloen na sbehu odpoved, a to falonej odpovedi od tonka a odpovedi
oprvnenho DNS servera. tonk mus na dopyt klienta na preklad mena odpoveda skorej ako
odpovie oprvnen DNS server. Zdranie odpovedi (ak je to nevyhnutn) oprvnenho DNS
servera je mon vykona zaslatm viacerch dopytov na preklad (simulcia toku DoS na DNS
server) alebo poiadavkou klienta na rekurzvny dopyt.
Demontrcia toku je na Obrzku . 10.8 a sklad sa z tchto krokov:
1
2
3
4
tonk sa umiestni v truktre sieti medzi klienta a menn server (sieov kolzna domna
s klientom alebo na segment, kde je umiestnen menn server)
Klient vykon dopyt DNS na preklad mena domny www.banka.sk
Dopyt je odchyten tonkom, ktor odpoved falonou informciou
Server DNS odpoved sprvnou informciou, ale tto informciu klient neakceptuje, pretoe
u dostal a akceptoval informciu od tonka.
Na realizciu takhoto toku existuj vone riten nstroje.
249
Obrzok . 10.8: tok na DNS typu Man in the Middle

10.1.6 toky na DNS cache poisoning
Ak klient v domne stuba.sk vykon dopyt na preklad mena domny www.banka.sk, typicky sa
vykon takto sekvencia udalost, ktor s dokumentovan na Obrzku . 10.9:
1
Klient kontaktuje jemu nakonfigurovan DNS server a poiada ho o preklad mena

domny www.banka.sk na adresu IP. Tento dopyt bude obsahova informciu o klientovom
sle zdrojovho portu UDP, adrese IP a ID transakcie DNS.
Klientov DNS server, pretoe nie je autoritatvnym pre domnu banka.sk, prostrednctvom
dopytov cez Internetov koreov servery DNS kontaktuje banka.sk server DNS a zska
odpove na dopyt.
Tento spen dopyt potom DNS server pole klientovi nasp a aj server DNS aj klient si
tto informciu uloia do vyrovnvacej pamti.
Na uvedenej sekvencii udalost si treba vimn tieto skutonosti:

1
V kroku 3 klient akceptuje iba tak sptn odpove od servera DNS, v ktorej server DNS
pouije sprvne slo zdrojovho portu, adresy IP a ID transakcie tak ako boli pouit pri
dopyte v kroku 1. Tieto tri poloky s jedinou formou autentizcie pouitej na akceptciu
odpoved DNS.
Sptn odpove od servera DNS domny www.banka.sk je uloen do cache na serveri
DNS ns1.stuba.sk a tie do vyrovnvac pamti na klientovi (v prpade plnho resolvera) a to
po dobu pecifikovan parametrom TTL. Ak in klient poiada server DNS ns1.stuba.sk o
preklad domnovho mena www.banka.sk poas platnosti tohto zznamu (dan TTL),
potom server DNS na tento dopyt vrti informciu zo svojej vyrovnvac amti a nebude
posiela dopyty na in menn servery (koreov, .sk a ns1.banka.sk).
250
Obrzok . 10.9: Preklad mena domny na adresu IP

Je potrebn rozliova ID medzi transakciou medzi klientom a mennm serverom a medzi
transakciou medzi mannmi servermi. V skutonosti ide o dve rzne transakcie DNS, teda ID
transakci bude samozrejme rzne.
Vyie uveden kroky mu by tonkom zneuit na umiestnenie falonej informcie do
vyrovnvac pamti ns1.stuba.sk. Na Obrzku . 10.10 sa tonk sna sprvne uhdnu ID
transakcie (16 bitov) pouitej pri komunikcii name serverov.
Aby to tonk dosiahol, urob toto:
1
Pole vek mnostvo iadost mennmu serveru ns1.stuba.sk o preklad, kad iados m
in falon zdrojov adresu IP, mena domny www.stuba.sk na adresu IP. Dvodom na
poslatie vekho potu iadost je to, e kadej iadosti bude pridelen jedinen ID
transakcie a aj ke vetky iadosti s pre to ist meno domny, kad iados bude
spracovvan nezvisle.
Menn server ns1.stuba.sk pole kad z tchto iadost na alie servery DNS a eventulne
ns1.banka.sk. To znamen, e menn server ns1.stuba.sk oakva vek mnostvo odpoved
od mennho servera ns1.banka.sk.
tonk vyuije tento akac interval na bombardovanie servera ns1.stuba.sk falonmi
odpoveami od servera ns1.banka.sk udvajcimi, e domne www.banka.sk odpoved
adresa IP, ktor je pod kontrolou tonka (falon adresa, falon infomcia). Kad
falon odpove m in ID transakcie. tonk dfa, e uhdne sprvne ID transakcie, t.j.
tak ako bolo pouit mennmi servermi.
Ak je tonk spen, bude falon informcia (falon IP adresa) uloen do varovnvacej

pamti servera DNS ns1.stuba.sk. Treba poznamena, e tento tok je viac menej tokom na
menn server, ktor m dopad na klienta pouvajceho cieov menn server s falonmi
informciami.
251
Obrzok . 10.10: Scenr toku na DNS cache poisoning

Teraz sa op vrme k trom autentizanm polokm dopytu a odpovede, t.j. ID transakcie,
zdrojovej adrese IP a slu zdrojovho portu. Zistenie zdrojovej adresy IP mennho servera je
priamoiare, pretoe poznme IP adresu mennho servera, ktormu klient posiela dopyty.
Zistenie sla zdrojovho portu je obanejie.
astejie no ako nie, softvr BIND (program omplementujci DNS protokoly) znovupouva to
ist slo zdrojovho portu na dopyty toho istho klienta, t.j. mennho servera BIND. To
znamen, e ak tonk m pod kontrolou nejak BIND autoritatvny menn server
(ns1.utocnik.sk), me ako prv zada dopyt na cieov menn server na preklad domnovho
mena z tonkovej domny (napr. www.utocnik.sk) a ke prde paket s rekurzvnym dopytom
na ns1.utocnik.sk, me tonk zisti slo zdrojovho portu na cieovom mennom serveri.
Je pravdepodobn, e bude pouit to ist slo zdrojovho portu aj ke obe pole dopyty pre
domnu, ktor bude unesen (hijacked). Odchytvanm vstupov troch po sebe idcich dopytov
pre rzne domnov men bolo naprklad zisten:
172.16.1.2.22343 > 128.1.4.100.53

172.16.1.2.22343 > 23.55.3.56.53
172.16.1.2.22343 > 42.14.212.5.53
Pri dopytoch na tri rzne menn servery vetky tri dopyty pouili slo zdrojovho portu 22343.
Zistenie zdrojovho slo portu je dokumentovan na Obrzku . 10.11.
252
Obrzok . 10.11: Zistenie sla zdrojovho portu na DNS BIND

BIND v4 a 8 pouva sekvenn prideovanie ID pre transakcie. Zo znamen, e tonk me
ahko njs aktulne ID jednoducho vykonanm dopytu na server a zistenm sla ID a znalosou,
e nasledujci dopyt BIND na al name server sa vykon s ID+1.
BIND v9 prideuje transakcim sla ID nhodne a neposiela viacnsobn rekurzvne dopyty pre
tie ist men domn.
10.1.7 Pouit zdroje
[RFC 1034]
MOCKAPETRIS, P.V.: Domain Names - Concepts and Facilities.

November 1987
[RFC 1035] MOCKAPETRIS, P.V.: Domain Names Implementation and
Specification. November 1987
[RFC 1183] EVERHART,
C.F.,
MAMAKOS,
L.A.,
ULLMANN,
R.,
MOCKAPETRIS, P.V.: New DNS RR Definitions. October 1990
[RFC 1591] POSTEL, J.: Domain Name System Structure and Delegation. March 1994
[RFC 1995] OTHA, M.: Incremental Zone Transfer in DNS. August 1996
[RFC 1996] VIXIE, P.: A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY). August 1996
[RFC 2136] VIXIE, P. (Editor), THOMSON, S., REKHTER, Y., BOUND, J.:
Dynamic Updates in the Domain Name System (DNS UPDATE). April
1997
[RFC 2870] BUSH, R., KARRENBERG, D., KOSTERS, M., PLZAK, R.: Root Name
Server Operational Requirements. June 2000
[SAI]
Attacking the DNS Protocol. Security Associates Institute. Sainstitute.org,
2003. Dostupn na
http://www.rootsecure.net/content/downloads/pdf/sans_attacking_dns_protocol.pdf.
Dtum prstupu 5.5.2010.
Dokumenty RFC s k dispozcii na webovom sdle http://www.ietf.org/
253
10.2 Bezpen elektronick pota

Prakticky vo vetkch distribuovanch prostrediach je elektronick pota najviac pouvan
sieov aplikcia. Pouvatelia oakvaj, e bud mc odosiela sprvy elektronickej poty
inm pouvateom, ktor s pripojen priamo alebo nepriamo k Internetu, bez ohadu na typ
operanho systmu potaa alebo komunikanho vybavenia. S rastcou dleitosou
elektronickej poty rastie aj poiadavka na jej bezpenos najm na autentickos a dvernos
sluieb elektronickej poty.
Bezpen elektronick pota S/MIME (Secure/Multipurpose Internet Mail Extension) je
bezpenostn vylepenie internetovho tandardu formtu elektronickej poty MIME. Vylepenie
je zaloen na vyuit technolgie haovacch funkci a kryptografie. Hoci aj bezpen pota PGP
(Pretty Good Privacy) je zaraden medzi tandardy IETF (Internet Engineering Task Force,
iniciatvna skupina tvorby internetovch tandardov RFC), je vysoko pravdepodobn, e
S/MIME sa stane priemyselnm tandardom pre obchodn a intitucionlne pouitie, zatia o
PGP zostane vobou pre osobn pouvanie bezpenej elektronickej poty mnohch
pouvateov. S/MIME je definovan v rade dokumentov, najdleitejie s [RFC 3370], [RFC
3850], [RFC 3851] a [RFC 3852].
Aby sme porozumeli bezpenej elektronickej pote S/MIME, musme ma najprv veobecn
predstavu o zkladnom formte sprvy elektronickej poty MIME. Ale k pochopeniu vznamu
MIME sa musme vrti k tradinmu formtu sprvy elektronickej poty definovanom v
tandarde [RFC 822]. Formt e-mailu v tomto formte sa ete dnes bene pouva. Najnovia
verzia tejto tradinej pecifikcii formtu je [RFC 5322]. Preto sa najprv budeme zaobera tmito
dvomi tandardmi a a potom sa vrtime k formtu S/MIME.
tandard [RFC 5322] definuje formt textovch sprv, ktor s odosielan pomocou
elektronickej poty. V kontexte [RFC 5322] je sprva viden ako oblka a obsah. Oblka
obsahuje akkovek informcie, ktor je potrebn prenies a dorui. Obsah vytvra objekt, ktor
je doruen prjemcovi. tandard [RFC 5322] sa vzahuje len na obsah. Avak tandard pre
obsah zahruje sadu hlaviiek, ktor me poui potov systm na vytvorenie oblky. tandard
je uren na uahenie zskavania tchto informci pomocou programov.
Obrzok . 10.12 : Zkladn truktra sprvy elektronickej poty

Celkov truktra sprvy poda [RFC 5322] je vemi jednoduch. Sprva sa sklad z uritho
potu riadkov zhlavia (header) a nasleduje neobmedzen text tela sprvy (body). Zhlavie je
oddelen od tela przdnym riadkom. Inak povedan, sprva je text US-ASCII (7 bitov kd) a
vetky riadky a do prvho przdneho riadku s povaovan za riadky zhlavia, ktor vyuva
as pouvateskho klienta potovho systmu. Riadok zhlavia sa obvykle sklad z hlaviky,
ktor je nasledovan dvojbodkou a alej nasledovan argumentom hlaviky. Formt dovouje,
aby bol jeden dlh riadok rozdelen do niekokch riadkov. Najastejie pouvan hlaviky s
From (Od), To (Komu), Subject (Predmet) a Date (dtum). alou bene sa vyskytujcou
hlavikou v zhlav poda [RFC 5322] je Message ID (ID sprvy). Tto hlavika obsahuje
254
jedinen identifiktor spojen s touto sprvou. Na Obrzku . 10.12 je zobrazenie zkladnej

truktry sprvy s prkladom sprvy.
10.2.1 Elektronick pota MIME
Formt MIME je rozrenm rmca poda [RFC 5322], ktor bol uren na rieenie niektorch
problmov a obmedzen pouitia protokolu SMTP (Simple Mail Transfer Protocol, tradin
protokol elektronickej poty definovan v [RFC 821]). Hlavn obmedzenie schmy protokolu
SMTP poda [RFC 5322] je to, e neme prena textov daje, ktor obsahuj znaky
nrodnch abecied, pretoe tie s reprezentovan 8 bitovm kdom s hodnotami desiatkovo 128
a viacej a SMTP je obmedzen iba na znaky reprezentovan 7 bitovm kdom ASCII. alm
obmedzenm je, e SMTP neme prena spustiten sbory alebo in binrne objekty.
Pouva sa vea schm na konverziu binrnych sborov do textovej formy, ktor jedin je
pouiten potovm systmom s protokolom SMTP. Bohuia iadna z tchto schm nie je
tandardom alebo aspo de facto tandardom.
pecifikciu MIME (vyjadren najm v [RFC 2045] a [RFC 2049]) mono charakterizova
nasledovne. Je definovanch p novch hlaviiek pre zhlavie sprvy poda [RFC 5322]. Tieto
hlaviky poskytuj informcie o tele sprvy. Je definovan rad novch formtov obsahu na
tandardizciu reprezentcie, ktor podporuj multimedilnu elektronick potu. S
definovan schmy kdovania prenosu umoujce konverziu akhokovek formtu obsahu do
tvaru, ktor je chrnen pred zmenou potovm systmom.
V MIME je definovanch p novch hlaviiek:
MIME-Version: Mus ma hodnotu parametra 1.0. Toto pole indikuje, e sprva je v

slade s [RFC 2045] a [RFC 2046].
Content-Type: Opisuje dostatone detailne daje obsiahnut v tele tak, e klient
elektronickej poty prjemcu me vybra vhodn prostriedok alebo mechanizmus na
reprezentciu dajov prjemcovi alebo inak pracova s dajmi vhodnm spsobom.
Content-Transfer-Encoding: Oznauje typ transformcie, ktor bol pouit na
reprezentciu tela sprvy spsobom, ktor je prijaten pre prenos poty.
Content-ID: Pouva sa na jednoznan identifikciu entt MIME v rznych kontextoch.
Content-Description: textov opis objektu v tele sprvy. Je to uiton v prpade, ke
objekt nie je itaten (napr. audio daje).
Neskorie bola v [RFC 2183] dodefinovan hlavika Content-Disposition, ktor uruje, i

prenan daje v tele sprvy s uren na automatick zobrazenie prjemcovi (inline) alebo nie
s uren k automatickmu zobrazeniu prjemcovi (attachment), t.j. prjemca ich m spracovva
rune (napr. sa jedn o sbor, ktor m by uloen na loklnom disku).
Niektor alebo vetky tieto hlaviky sa mu objavi v normlnom zhlav [RFC 5322].
Kompliantn implementcia MIME mus podporova hlaviky MIME-Version, Content-Type a
Content-Transfer-Encoding, hlaviky Content-ID a Content-Description a Content-Disposition s
voliten a me by prjemcom ignorovan.
Prevan as pecifikcie MIME sa tka defincie rznych typov obsahu. To odra potrebu
zabezpei tandardizovan spsoby zaobchdzania s najrznejmi reprezentciami v
multimedilnom prostred. Existuje sedem rznych hlavnch typov obsahu a celkom 15
podtypov. Vo veobecnosti typ obsahu deklaruje veobecn typ dajov a podtyp uruje urit
formt pre tento typ dajov.
Pre telo typu Text nie je potrebn iadny pecilny softvr na zskanie plnho vznamu textu
okrem podpory uvedenho sboru znakov. Primrny podtyp je Plain text (obyajn text), o je
jednoducho reazec znakov ASCII alebo znakov ISO 8859. Podtyp Enriched (obohaten,
definovan v [RFC 1896]) umouje viu flexibilitu formtovania.
255
Typ message poskytuje rad dleitch funkci MIME.
Podtyp rfc822 indikuje, e telo je cel sprva elektronickej poty vrtane hlaviky a tela.
Bez ohadu na meno tohto podtypu zapzdren sprva me by nielen jednoduch
sprva [RFC 5322], ale tie lubovon sprva MIME.
Podtyp partial umouje fragmentciu vekej sprvy do niekokch mench ast, ktor
treba na mieste urenia znovu posklada. Pre tento podtyp s pecifikovan v hlavike
Content-Type: Message/Partial alie tri parametre: identifiktor id, je rovnak pre
vetky fragmenty, slo sekvencie sequence number, je jedinen slo kadho
fragmentu a slo total je celkov poet fragmentov.
Podtyp external-body indikuje, e skuton daje, ktor by sa mali prepravova v tejto
sprve nie s obsiahnut v tele sprvy. Namiesto toho je v tele sprvy informcia
potrebn na prstup k dajom. Tak ako pri ostatnch typoch message m aj podtyp
external-body vonkajie zhlavie a vnoren sprvu so svojim vlastnm zhlavm. Jedin
potrebn pole vo vonkajom zhlav je hlavika Content-Type, ktor stanovuje podtyp
external-body. Vntorn zhlavie je zhlavie sprvy pre vnoren sprvu. Hlavika
Content-Type vo vonkajom zhlav mus obsahova parameter prstupu access-type,
ktor udva spsob prstupu ako je naprklad protokol FTP (File Transfer Protocol).
Typ image pecifikuje obrzok. Obsahom tela sprvy je obrzok. K jeho prezentcii je treba
odpovedajci prehliada. Podtyp jpeg indikuje, e obraz je vo formte JPEG, kdovanie JFTF.
Podtyp gif indikuje, e obraz je vo formte GIF.
Typ audio pecifikuje zvuk. Na prezentciu je treba odpovedajci prehrva. Podtypom je basic,
mono so vzorkovacm kmitotom 8 kHz.
Typ video pecifikuje video. Implicitn podtyp je mpeg, video vo formte MPEG.
Typ application odpoved alm typom dajov, typicky alebo neinterpretovatenm binrnym
dajom alebo informciam, ktor bud spracovan potovou aplikciou.
Typ multipart indikuje, e telo sprvy obsahuje viacero nezvislch ast (kompozitn sprva).
Hlavika Content-Type obsahuje parameter boundary (hranica), ktor definuje oddeova
medzi asami tela. Tto hranica by sa nemala vyskytova v iadnej asti sprvy. Kad hranica
v tele sprvy zana na novom riadku a pozostva z dvoch pomliek nasledovanch reazcom
znakov parametra boundary. Posledn hranica v tele sprvy oznaujca koniec poslednej asti m
aj na konci prponu dvoch pomliek. V kadej asti me by volitene obyajn zhlavie
MIME. Na Obrzku . 10.13 je schematicky znzornen prklad truktry sprvy typu multipart.
256
Obrzok . 10.13: Prklad truktry sprvy typu multipart s podtypom mixed

Existuj tyri podtypy typu multipart, kad z nich m rovnak celkov syntax.
257
Podtyp mixed sa pouva vtedy, ak telo sprvy sa sklad z viacerch nezvislch ast
a tieto asti s spojen v uritom porad.
Pre podtyp parallel nie je poradie jednotlivch ast tela sprvy vznamn. Ak je
prjemcov systm na to vybaven, jednotliv asti sprvy s prezentovan paralelne.
Mohlo by s naprklad o sprvu s dvomi asami. Jedna as obsahuje obrzok, druh
as obsahuje hlasov komentr k obrzku. Ak je na to prjemcov systm uspsoben, po
otvoren sprvy sa mu zobraz obrzok a sasne sa prehr zvukov komentr.
Pre podtyp alternative s rzne asti reprezentciou rovnakej informcie. Na Obrzku .
10.14 je uveden prklad sprvy s podtypom alternative. V tomto podtype s asti tela
sprvy uloen usporiadane v porad zvyovania preferenci. Nech sa telo sprvy sklad
z dvoch rovnakch textovch ast, prv as obsahuje hlaviku Content-Type: text/plain
a druh as obsahuje hlaviku Content-Type: text/enriched. Ak prjemcov systm je
schopn zobrazova sprvu vo formte text/enriched, potom sa tak urob. V opanom
prpade sa pouije formt obyajnho textu text/plain.
Podtyp digest sa pouva vtedy, ke kad z ast tela je interpretovan ako sprva [RFC
5322] so zhlavm. Tento podtyp umouje kontrukciu sprvy, ktorej asti s
individulne sprvy. Naprklad modertor skupiny zbiera sprvy elektronickej poty od
astnkov, spoj tieto sprvy a pole ich v jednej zapzdrenej sprve MIME.
Obrzok . 10.14: Prklad truktry sprvy typu multipart s podtypom alternative

Knonick tvar je dleit koncept v MIME a S/MIME. Knonick tvar je formt
zodpovedajci typu obsahu, ktor je tandardizovan na pouitie medzi systmami. To je na
rozdiel od natvneho tvaru, ktor predstavuje formt charakteristick pre konkrtny systm.
Kdovanie tela sprvy pri prenose vo formte MIME je alm vnym komponentom
pecifikcie MIME. Cieom je zabezpei spoahliv doruenie cez najiriu klu prostred.
tandard MIME definuje dve metdy kdovania dajov. Hlavika Content-Transfer-Encoding
me v skutonosti nadobda es hodnt. Tri z tchto hodnt (7 bitov, 8 bitov a binrne)
naznauj, e nebolo vykonan iadne kdovanie, ale tieto hodnoty poskytuj niektor
informcie o charaktere dajov. Pre prenos SMTP je bezpen pouva 7 bitov tvar. 8 bitov a
binrny tvar me by pouiten v inch svislostiach prenosu poty. alie hodnota hlaviky
Content-Transfer-Encoding je x-token vyjadrujca, e je pouit in kdovanie, ktor me by
pecifikovan dodvateom alebo konkrtnou aplikciou. Dve skuton definovan kdovacie
schmy s quoted-printable a base64. Tieto dve kdovacie schmy s definovan tak, aby
zabezpeili vber medzi technikou prenosu, ktor je v podstate loveku itaten a tm, aby boli
bezpen pre vetky typy dajov pri rozumnej miere kompaktnosti.
Kdovanie prenosu quoted-printable je uiton v prpade, ke daje vinou pozostvaj
prevane z oktetov, ktor zodpovedaj tlaitenm znakom ASCII. Znaky, ktor nie s bezpen
(nenachdzaj sa v 7 bitovom kde ASCII) s reprezentovan svojou hexadecimlnou
reprezentciou, pred ktor sa vlo znak = (mkk zarka). Naprklad reazec Jn Vojaik by
sa kdovalo ako J=E1n Voja=E8ik, pretoe hexadecimlny kd pre je E1 a pre je E8
a ostatn znaky s obsiahnut v 7 bitovom kde ASCII. Mkk zarka sa pouije aj na
ukonenie dlhho riadku sprvy tak, aby obmedzil dlku riadku sprvy na 76 znakov.
Kdovanie prenosu base64 je bene pouvan kdovanie ubovonch binrnych dt takm
258
spsobom, aby boli nepokoditen pri spracovan programom na prenos poty. Je to kdovanie
rovnak ako radix-64 s tm, e radix-64 priklad aj kontroln set kdovanch dajov.
Kdovanie znakov poda schmy base64 je na Obrzku . 10.15.
Obrzok . 10.15: Kdovacia tabuka base64

Jednoduch demontrcia fungovania kdovania poda schmy base64 sa uke na prklade.
Predpokladajme, e vstupn daje s tri slabiky (bajty) vyjadren binrne ako 10101010
01010101 11001100. Pri kdovan base64 sa tto postupnos rozdel na skupiny po iestich
bitoch. To znamen, e preskupenm dostaneme 101010 100101 010111 001100, o
v dekadickom vyjadren je 42 37 23 12 a v kde base64 je to postupnos znakov qlXM (bez
medzier medzi znakmi).
10.2.2 Funkcie S/MIME
Bezpen elektronick pota S/MIME ponka monos podpsania a/alebo ifrovania sprv
prostrednctvom tchto funkci:
Enveloped data (oblkovan daje): Sklad sa zo zaifrovanho obsahu lubovonho

typu a zaifrovanho ka (ktorm sa zaifroval obsah) a to pre kadho prjemcu.
Signed data (podpsan daje): Digitlny podpis je vytvoren tak, e sa vytvor
kontroln suma podpisovanho obsahu a tento kontroln set sa zaifruje privtnym
kom podpisovatea. Obsah a podpis s potom zakdovan pomocou schmy base64.
Sprvu s podpsanm obsahom me vidie iba prjemca s funkcionalitou S/MIME.
Clear-signed data (iba podpsan daje): Je vytvoren digitlny podpis obsahu rovnako
ako pri podpsanch dajoch. V tomto prpade je iba digitlny podpis kdovan
pomocou schmy base64. Vsledkom je, e prjemcovia bez funkcionalt S/MIME s
schopn preta obsahu sprvy aj ke neme overi podpis.
Signed and enveloped data (podpsan a oblkovan daje): iba podpsan a iba
ifrovan entity mu by vnoren. To znamen, e zaifrovan daje mu by
podpsan a podpsan daje alebo iba podpsan daje mu by zaifrovan.
S/MIME zavdza niekoko novch typov obsahu MIME. Vetky nov typy aplikci pouvaj
oznaenie PKCS (pecifikcie kryptografie s verejnm kom vydanch spolonosou RSA
Laboratories a sprstupnen pre S/MIME).
259
S/MIME zabezpeuje entity MIME pomocou podpisu, ifrovanm alebo obojm. Entita MIME
me by cel sprva (s vnimkou zhlav [RFC 5322]) alebo ak typ obsahu MIME je multipart,
potom entita MIME je jedna alebo viac podast sprvy. Entita MIME je vytvoren poda
tandardnch pravidiel vytvrania sprv MIME. Potom entita MIME plus niektor daje
svisiace s bezpenosou (identifikcia algoritmov a certifikty) s spracovan S/MIME
s vsledkom vytvorenia PKCS objektu. S PKCS objektom sa potom zaobchdza ako s obsahom
sprvy a je zabalen do MIME (vybaven vhodnmi hlavikami MIME).
Vo vetkch prpadoch je odoslan sprva konvertovan do knonickho tvaru. Najm pre dan
typ a podtyp je pouit vhodn knonick tvar pre obsah sprvy. Pre sprvu typu multipart je
pouit vhodn knonick tvar pre kad podas.
Pouitie kdovania prenosu si vyaduje osobitn pozornos. Vo vine prpadov bude
vsledkom pouitia bezpenostnho algoritmu vytvoren objekt, ktor je iastone alebo plne
vyjadren ako ubovon binrne daje. Tento objekt bude potom zabalen vo vonkajej sprve
MIME a kdovanie prenosu me by pouit v tomto bode, tandardne base64. Avak v prpade
sprvy multipart/signed je obsah sprvy v jednej z podast bezpenostnm procesom
nezmenen. Ak nie je tento obsah 7 bitov, prenos by mal by kdovan schmou base64 alebo
quoted-printable tak, aby nebolo iadne nebezpeenstvo zmeny obsahu, na ktor bol podpis
aplikovan.
Zkladn typy obsahu S/MIME s:
Pre typ multipart je podtyp Signed: iba podpsan sprva, ktor sa sklad z dvoch ast.
Prv as je sprva a druh je podpis.
Pre typ application je podtyp pkcs7-signature: typ obsahu pre podas podpisu sprvy
multipart/signed.
Pre typ application je podtyp pkcs7-mime. Bliiu pecifikciu uruje parameter
smime. Parameter smime=signedData oznauje podpsan entitu S/MIME. Parameter
smime=envelopedData oznauje zaifrovan entitu S/MIME. Parameter smime=
degenerate signedData oznauje, e entita S/MIME obsahuje iba certifikty.
Podtyp application/pkcs7-mime sa pouva pre jednu z troch kategri spracovania S/MIME,

kad s jedinenm parametrom smime-type (parameter smime-type nadobda hodnoty
signedData, envelopedData, degenerate signedData). Vo vetkch prpadoch vsledn entita
(alej len objekt) je reprezentovan vo forme znmej ako BER (Basic Encoding Rules), ktor je
definovan v ITU-T Odporaniach X.209. Formt BER sa sklad z ubovonch oktetovch
reazcov a predstavuje teda binrne dta. Takto objekt by mal by kdovan pri prenose
schmou base64 vo vonkajej sprve MIME.
Postup na vytvorenie entity MIME typu envelopedData je:
1
2
Generuj pseudonhodn relan k pre konkrtny symetrick ifrovac algoritmus

(naprklad triple DES).
Pre kadho prjemcu zaifruj relan k jeho verejnm kom z certifiktu. Pre kadho
prjemcu sa vytvor blok oznaen RecipientInfo, ktor obsahuje identifiktor (ID)
certifiktu verejnho ka prjemcu, identifiktor (ID) algoritmu pouitho na zaifrovanie
relanho ka a zaifrovan relan k.
Zaifruj obsah sprvy relanm kom a vlo do truktry envelopedData.
Bloky RecipientInfo s nasledovan zaifrovanm obsahom a vytvraj envelopedData. Tto

informcia je potom zakdovan schmou base64. Na Obrzku . 10.16 je znzornen schma
vytvorenia entity typu envelopedData pre dvoch prjemcov.
260
Na znovuzskanie zaifrovanej sprvy prjemca najprv deifruje sprvu poda schmy base64.
Potom prjemca pouije svoj privtny k a deifruje relan k. Nakoniec je obsah sprvy
deifrovan relanm kom.
Obrzok . 10.16: Postup vytvorenia entity envelopedData pre dvoch prjemcov

Typ smime oznaen signedData (parameter smime-type=signedData) me by pouit s
jednm alebo viacermi podpisovatemi. Pre nzornos sa uvedie opis prpadu s jednm
podpisovateom. Postup na vytvorenie entity MIME typu signedData je:
1
Vyber algoritmus na vytvorenie kontrolnho stu (naprklad SHA) a vypotaj kontroln

sumu (hash hodnotu) obsahu, ktor m by podpsan.
Zaifrujte kontroln sumu privtnym kom podpisovatea.
Priprav blok oznaen ako SignerInfo, ktor obsahuje certifikt verejnho ka

podpisovatea, identifikciu algoritmu na vpoet kontrolnej sumy, identifiktor
ifrovacieho algoritmu kontrolnej sumy a zaifrovan kontroln sumu.
Entita signedData sa sklad z radu blokov vrtane identifiktora algoritmu na vpoet kontrolnej
sumy sprvy, podpsanej sprvy a SignerInfo. Entita signedData me ete obsahova sadu
certifiktov verejnch kov od dveryhodnej alebo koreovej certifikanej autority, ktor s
potrebn na overenie platnosti podpisu. Tto informcia je potom zakdovan schmou base64.
Na obnovenie podpsanej sprvy a overenie podpisu, prjemca najprv odkduje base64. Potom
prjemca over platnos podpisu tak, e over platnos certifiktu a verejnm kom deifruje
zaifrovan kontroln sumu sprvy. alej vypota kontroln set podpsanej sprvy. Ak sa
rovnaj kontroln sty, jeden vytvoren prjemcom z podpsanej sprva a druh zisten
deifrovanm zaifrovanho kontrolnho stu podpsanej sprvy, potom je podpis sprvy
overen.
261
Obrzok . 10.17: truktra sprvy clear-signed

Iba podpsanie (clear-signed) je dosiahnut pomocou typu obsahu multipart a podtypu signed.
Ako u bolo spomenut, tento proces podpisovania nezaha transformciu sprvy, ktor je
podpsan, take sprva je odoslan v pvodnom tvare. Take prjemcovia s funkciami MIME,
ale nie s funkciami S/MIME, s schopn preta prichdzajcu sprvu.
Sprva multipart/signed m dve asti. Prv as me by akkovek typ MIME, ale mus by
vytvoren tak, e sa nebude meni v poas prenosu od zdroja k cieu. To znamen, e ak prv
as nie je 7 bitov, potom je potrebn, aby sa prv as zakdovala schmou base64 alebo
quoted-printable. Potom je tto as spracovan rovnakm spsobom ako signedData, ale v
tomto prpade je vytvoren objekt vo formte signedData, ktor m przdne pole obsahu sprvy.
Tento objekt je oddelen podpis. Potom je kdovan na prenos schmou base64 a stane sa
druhou asou sprvy multipart/signed. Tto druh as m type obsahu MIME application
a podtyp pkcs7-signature. Na Obrzku . 10.17 je ukka truktry sprvy.
Parameter protocol oznauje, e sa jedn o entitu iba podpsan (clear-signed) s dvomi asami.
Parameter micalg udva typ pouitej funkcie na vpoet kontrolnho stu. Prjemca me
overi podpis tm, e vypota kontroln set prvej asti a porovnanm ho s kontrolnm stom
zskanm z druhej asti.
262
10.2.3 Pouit zdroje
[RFC 821]
[RFC 822]
[RFC 1896]
[RFC 2045]
[RFC 2046]
[RFC 2047]
[RFC 2048]
[RFC 2049]
[RFC 2183]
[RFC 3370]
[RFC 3850]
[RFC 3851]
[RFC 3852]
[RFC 5322]
POSTEL, J.: Simple Mail Transfer Protocol. August 1982.

CROCKER, D. H.: Standard for the format of ARPA Internet text
messages. August 1982
RESNICK, P., WALKER, A.: The text/enriched MIME Content-type.
February 1996
FREED, N. , BORENSTEIN, N.: Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies. November 1996
(MIME) Part Two: Media Types. November 1996
(MIME) Part Three: Message Header Extensions for Non-ASCII Text.
November 1996
FREED, N. , KLENSIN, J., POSTEL, J.: Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures. November 1996
(MIME) Part Five: Conformance Criteria and Examples. November 1996
TROOST, R., DORNER, S., MOORE, K.: Communicating Presentation
Information in Internet Messages: The Content-Disposition Header Field.
August 1997
HOUSLY, R.: Cryptographic Message Syntax (CMS) Algorithms. August
2002
RAMSDELL, B. (Editor): Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling. July 2004
RAMSDELL, B.(Editor): Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification. July 2004
HOUSLY, R.: Cryptographic Message Syntax (CMS). July 2004
RESNICK, P.: Internet Message Format. October 2008
263
10.3 Protokol HTTP

spen fungovanie svetovej pavuiny www (world wide web) je vsledkom efektvnosti a
uitonosti celho hypermedilneho systmu, ktor implementuje. Okrem nstrojov HTML a
URL je protokol HTTP (Hypertext Transfer Protocol) pravdepodobne najdleitejou sasou
webu. Tento protokol vlastne prena hypertextov dokumenty a alie sbory medzi webovmi
servermi a webovmi klientmi. Tvorcovia protokolu http si "vypoiali" koncepciu hlaviiek
a typov mdi zo pecifikcie elektronickej poty [RFC 822] a [RFC 2045] a [RFC 2049].
V sasnosti sa najviac pouva verzia 1.1 protokolu HTTP, skrtene sa zapisuje HTTP/1.1. Tto
verzia je pecifikovan v dokumente [RFC 2616]. Bezpenostn a autentizan problmy s
pecifikovan v dokumente [RFC 2617]. Pri opise protokolu HTTP sa bude vychdza z tchto
pecifikci. pecifikcia HTTP/1.1 zabezpeuje sptn kompatibilitu so starmi verziami
protokolu HTTP/1.0 a HTTP/0.9.
10.3.1 Zkladn koncepcia protokolu
Protokol HTTP je typu klient/server. Vo svojej najjednoduchej podobe prevdzka protokolu
HTTP zahruje klienta protokolu HTTP, reprezentovanho zvyajne internetovm prehliadaom
na klientskom potai, a server protokolu HTTP, reprezentovanho zvyajne webovm
serverom. Po vytvoren spojenia TCP sa pri komunikcii realizuj dva kroky. Klient pole sprvu
so iadosou vo formte poda pravidiel tandardu HTTP iados HTTP (HTTP Request).
Tto sprva udva zdroj na serveri HTTP, ktor si klient el zska, alebo obsahuje informcie,
ktor maj by poskytnut serveru. Server HTTP prevezme a interpretuje iados klienta.
Vykon akcie tkajce sa iadosti a vytvor sprvu odpovede HTTP (HTTP Response), ktor
pole sp klientovi. Sprva odpovede indikuje i iados bola spen a ak je to vhodn, me
tie obsahova obsah klientom poadovanho zdroja.
V protokole HTTP/1.0 kad spojenie TCP obsahuje iba jednu takto vmenu, v protokole
HTTP/1.1 je monch takchto vmen v rmci jednho spojenia TCP viacero. Treba tie
poznamena, e server me v niektorch prpadoch odpoveda jednou alebo predbenou
odpoveou, predm ne odole pln odpove. Tto situcia me nasta v prpade, e server
odole predben odpove pouitm stavovho kdu 100 Continue pred skutonou odpoveou.
Jednoduch dvojica iados HTTP / odpove HTTP medzi klientom a serverom sa stva
zloitejou, ke s vo virtulnej komunikanej ceste medzi klientom a serverom umiestnen
sprostredkovatelia (intermediary). Ide o tak zariadenia ako proxy, brny alebo tunely, ktor
sa pouvaj na zvenie vkonu (priepustnosti), zaisteniu bezpenosti alebo vykonvaj in
potrebn funkcie pre konkrtnych klientov alebo servery. Proxy servery sa bene pouvaj na
webe, pretoe mu vrazne zlepi as odozvy pre skupinu podobnch klientskych potaov.
Ke je v komunikcii medzi klientom a serverom HTTP zapojen sprostredkovate HTTP
komunikcie, tak klient komunikuje so serverom prostrednctvom sprostredkovatea. To
znamen, e vetka premvka (traffic) medzi klientom a serverom prechdza
sprostredkovateom. Tto skutonos umouje sprostredkovateovi vykonva rzne funkcie
nad prechdzajcou premvkou, naprklad ukladanie do vyrovnvacej pamti (cache)
sprostredkovatea, preklad, agregcie alebo zapzdrenie. Na Obrzku . 10.18 je demontrovan
prklad komunikcie medzi klientom a serverom HTTP prostrednctvom jednho
sprostredkovatea. Jednoduch dvojica iados HTTP / odpove HTTP sa zmen na dve dvojice
(tyri kroky):
1
Klient HTTP odole sprvu iadosti sprostredkujcemu zariadeniu.
Sprostredkovate iados spracuje, vykon v prpade potreby zmeny v iadosti, a potom

pole iados na server.
264
Server HTTP preta a interpretuje iados, vykon prslun akcie a odole odpove.
Pretoe dostal svoju iados od sprostredkovatea, jeho odpove ide spt
sprostredkovateovi.
Sprostredkovate odpove spracuje, op prpadne urob zmenu, a potom ju pole klientovi.
Obrzok . 10.18: Komunikcia klient/server cez sprostredkovatea

Uveden prklad mono zoveobecni na viacero sprostredkovateov pri komunikcii medzi
klientom a serverom.
Pri komunikcii medzi klientom a serverom cez sprostredkovatea psob sprostredkovate vo
vzahu ku klientovi ako server a vo vzahu k serveru ako klient. Mnoh sprostredkovatelia s
navrhnut tak, aby boli schopn odpova rzne protokoly TCP/IP. Vina protokolov nevie o
existencii vloenho sprostredkovatea. Protokol HTTP vak obsahuje pecilnu podporu pre
uritch sprostredkovateov, ako s proxy servery, ktorm poskytuje nstroje (hlaviky) na
narbanie so iadosami a odpoveami HTTP.
Model normlnej komunikcie HTTP je mon zmeni prostrednctvom odkladania iadost
klientov a odpoved serverov na tieto iadosti do vyrovnvacej pamti cache (tejto metde sa
hovor caching). Ukladanie nedvno zskanch zdrojov do pamti cache je aplikovan rznymi
zariadeniami na webe, naprklad sprostredkovatemi typu proxy. Tieto zdroje je mon znovu
rchle zska z pamti cache, ke je zadan takto iados. Klient si sm do svojej pamti cache
uklad nedvno zskan dokumenty z webu tak, e ak o ne poiada op, mu mu by zobrazen
aj bez zadania iadosti na server. Ak je zadanie iadosti skutone nevyhnutn (poadovan
dokument sa v pamti cache klienta nenachdza), me kad sprostredkovate uspokoji
poiadavku na dokument, pokia ho sprostredkovate m vo svojej pamti cache.
Protokoly HTTP/0.9 a HTTP/1.0 podporovali iba prechodn spojenie medzi klientom a
serverom HTTP, o znamen, e v jednom spojen TCP bolo mon vykona jedin vmenu
iados HTTP/odpove HTTP. Takto model spojenia je vemi neefektvny pre modern web,
v ktorom klienti asto potrebuj vykona desiatky iadost na server. Protokol HTTP/1.1 funguje
tandardne s trvalmi spojeniami. Po vytvoren spojenia TCP me klient posla na server vea
iadost a jeden po druhom prijma odpovede. Tento model spojenia umouje rchlejie
zskanie sborov, etr prostriedky servera a etr rku psma internetovho pripojenia. Klient
me dokonca zreazi (pipeline) svoje iadosti odosielanm druhej iadosti ete predtm, ako
by musel najprv aka na odpove na prv iados. Protokol HTTP/1.1 stle podporuje
prechodov spoje z dvodu sptnej kompatibility, ke je to potrebn. Na Obrzku . 10.19 je
prklad trvalho spojenia klienta a servera HTTP.
265
Obrzok . 10.19: Prklad trvalho spojenia klienta a servera HTTP.

10.3.2 Formt sprvy iadosti
Vetky sprvy HTTP s v slade so truktrou nazvanou formt generickej sprvy. Tento
formt je zaloen na tandardoch sprv elektronickej poty [RFC 822] a [RFC 2045] a [RFC
2049], aj ke sa HTTP presne neriadi tmito formtmi. Kad sprva HTTP zana tartovacm
riadkom, potom obsahuje rad hlaviiek sprvy nasledovan przdnym riadkom a prpadne
telo sprvy. Telo sprvy me volitene obsahova zdroj ako je naprklad sbor, ktor je
prenan medzi klientom a serverom, a ukonenie sprvy (trailer). Tomuto zdroju sa hovor
entita.
iados HTTP pouva formt sprvy vychdzajci z generickho formtu sprvy a obsahuje v
porad tieto asti: riadok iadosti, veobecn hlaviky, hlaviky iadosti, hlaviky entity, przdny
riadok, prpadne telo sprvy a ukonenie (trailer) sprvy.
Generick tartovac riadok, ktorm zanaj vetky sprvy HTTP sa v prpade formtu sprvy
iadosti HTTP nazva riadok iadosti. Tento riadok m trojak el: indikuje prkaz alebo
akciu, ktor chce klient vykona, pecifikuje zdroje, nad ktormi by sa mala tto akcia vykona
a indikuje serveru, ak verzia protokolu HTTP pouva klient. Formlna syntax riadka iadosti
je:
<METHOD> <request-uri> <HTTP-VERSION>, kde
266
METHOD je typ akcie, ktor poaduje klient, aby bola vykonan serverom. Je vdy
uveden vekmi psmenami. V HTTP/1.1 existuje osem tandardnch metd, z ktorch
tri s bene pouvan, a to: GET, HEAD a POST.
request-uri - iados URI (Uniform Resource Identifier) je identifiktor prostriedku,
ktorho sa iados tka. Zatia o URI me teoreticky odkazova na URL (Universal
Resource Locator) alebo URN (Uniform Resource Name), v sasnej dobe je URI
takmer vdy URL HTTP, ktor repektuje pravidl tandardnej syntaxe Web URL.
tandardn spsob urenia zdroja v iadosti je zahrn cestu a nzov sboru v riadku
iadosti, zatia o pecifikciu hosta v osobitnej hlavike Host, ktor mus by pouit v
iadostiach HTTP/1.1.
HTTP-VERSION oznamuje serveru, ak verziu klient pouva a teda, ako interpretova
iados a to, o m posla a o neposiela klientovi vo svojej odpovedi.
Metda GET iada, aby server vyhadal zdroj uren adresou URL na riadku iadosti HTTP a
zdroj odoslal v odpovedi klientovi. Metda HEAD je rovnak ako GET s tm rozdielom, e
server neodole vlastn telo sprvy. To znamen, e odpove bude obsahova vetky hlaviky
ako by boli v odpovedi na ekvivalentn GET sprvu. Metda POST umouje klientovi posla
entitu na spracovanie na server, ktor obsahuje ubovon daje. Bene sa pouva na zaslanie
naprklad interaktvneho formulra HTML na server, program na serveri tento formulr spracuje
a vykon akcie na zklade vstupov z formulra a klientovi pole odpove. Metda OPTIONS
umouje klientovi poiada server, aby poslal informciu o podporovanch komunikanch
monostiach. Zdroj na serveri je pecifikovan URI. V prpade, e sa dopyt tka vlastnost celho
servera, potom sa namiesto URI pouije hviezdika. Metda PUT iada server, aby uloil entitu
z tela iadosti na URL, ktor je uveden v riadku iadosti. Rozdiel medzi metdami PUT a POST
je ten, e v metde PUT URI identifikuje v iadosti entitu, zatia o v POST URI identifikuje
program uren pre spracovanie entity v iadosti. Metda DELETE poaduje zruenie
pecifikovanho zdroja na serveri. Metda TRACE umouje klientovi obdra sp kpiu
iadosti, ktor sm poslal na server. Pouva sa na diagnostick ely.
Po riadku iadosti sa v sprve nachdzaj hlaviky, ktor klient chce zahrn do sprvy. Vetky
hlaviky pouvaj rovnak truktru, ale s rozdelen do kategri na zklade funkci, ktorm
slia:
Veobecn hlaviky sa tkaj hlavne samotnej sprvy, na rozdiel od jeho obsahu, a

slia na ovldanie jej spracovania alebo poskytuje prjemcovi alie informcie. Nie s
to pecifick hlaviky pre sprvu iadosti alebo odpovedi.
Hlaviky iadosti oznamuj serveru alie podrobnosti o povahe iadosti klienta
a dvaj klientovi viu kontrolu nad tm, ako je spracovan iados.
Hlaviky entt opisuj entity obsiahnut v tele iadosti, ak existuj. S opsan
v nasledujcej asti.
Hlaviky iadosti s samozrejme pouit iba v sprvach iadost, ale veobecn hlaviky a
hlaviky entity sa me objavi bu v sprvach iadost alebo v sprvach odpoved.
Veobecn hlaviky HTTP sa me vyskytn v kadej sprve iadosti alebo odpovedi HTTP.
Pouvaj sa na komunikciu informci o samotnej sprve a nie k jej obsahu. Veobecn
hlaviky sa pouvaj pre funkcie na stanovenie dtumu a asu sprvy, na riadenie ukladania
sprvy do pamti cache (caching) a na uvedenie metdy kdovania prenosu sprvy. alej s
strune opsan najdleitejie veobecn hlaviky. Hlavika Cache-control pecifikuje
direktvy pre sprvu realizcie ukladania sprv iadost a odpoved HTTP do pamti cache.
Hlavika Connection obsahuje intrukcie, ktor sa tkaj len tohto konkrtneho spojenia a
nesm by uloen na proxy a pouit pre alie spojenie. Najastejie pouitie tejto hlaviky je
s parametrom "close" (Connection: close). Tto hlavika m prednos pred predvolenm
sprvanm HTTP/1.1 trval spojenie a po odpovedi servera vnti ukonenie spojenia. Hlavika
Date oznauje dtum a as vzniku sprvy. Typickm prkladom me by: Date: Tue 05 Jun
2012 19:41:41 GMT. Hlavika Pragma sli na povolenie implementane pecifickch direktv
vzahujcich sa na vetky zariadenia v reazci iados/odpove. Ben pouitie tejto hlaviky
v sprve je na potlaenie caching "Pragma: no-cache". Hlavika Transfer-Encoding indikuje
ak kdovanie bolo pouit na sprvu s cieom korektnho prenesu medzi zariadeniami.
Hlavika Upgrade umouje zariadeniu klienta uri alie podporovan protokoly. Ak server
podporuje tie jeden z protokolov uvedench klientom, potom sa me so serverom dohodn na
aktualizcii spripojenia prostrednctvom alternatvneho protokolu. Hlavika Via je doplnen
sprostredkovateom na indikciu prjemcovi akmi brnami, proxy a/alebo tunelmi mu bola
dopraven iados alebo odpove. Tto hlavika umouje jednoduch sledovanie cesty sprvy a
zvldnutie aj potencilne komplexnho reazca zariaden medzi klientom a serverom. Hlavika
Warning sa pouva v prpade potreby poskytn alie informcie o stave sprvy.
Hlaviky iadosti HTTP sa uplatuj len v sprvach iadosti HTTP. Umouj klientovi
poskytn serveru informcie o sebe a poskytn viac podrobnost o iadosti a nad riadenm jej
267
vykonvania. alej s strune opsan najdleitejie veobecn hlaviky. Hlavika Accept

umouje klientovi oznmi serveru ak typy internetovch mdi je ochotn akceptova v
odpovedi. Hlavika me obsahova niekoko rznych typov a podtypov mdi MIME ([RFC
2045] a [RFC 2049]), s ktormi vie klient narba. Kad hlavika me by doplnen
parametrom q (hodnota kvality) vyjadrujcim preferenciu klienta. Hlavika Accept-Charset je
podobn ako Accept. Stanovuje ak sadu znakov je klient v odpovedi ochotn akceptova.
Hlavika Accept-Encoding je podobn ako Accept a Accept-Charset. Stanovuje ak kdovanie
obsahu je klient v odpovedi ochotn akceptova. Hlavika Accept-Language je podobn ako
predchdzajce hlaviky Accept-type. Stanovuje zoznam oznaen jazykov indikujci ak jazyky
klient podporuje alebo oakva, e server bude pouva vo svojej odpovedi. Hlaviku
Authorization pouva klient na predloenie autentizanch informci serveru. To nastva iba v
prpade, ke server vyaduje autentizciu, asto zaslanm stavovho kdu 401 Unauthorized v
odpovedi na klientovu inicilnu iados. Hlavika Expect oznauje urit typy akci, ktor
oakva klient, e server vykon. Zvyajne server akceptuje oznaen parametre, ak nie, server
pole odpove so stavovm kdom 417 Expectation Failed. Hlavika From obsahuje adresu
elektronickej poty pouvatea. Hlavika Host pecifikuje internetov uzol prostrednctvom
domnovho mena DNS a me tie obsahova pecifikciu sla portu. Tto hlavika je povinn
v iadosti HTTP/1.1. Hlavika If-Match rob metdu podmienenou pecifikovanm prznaku
entity tkajci sa konkrtnej entity, ktor klient chce pristpi. Hlavika If-Modified-Since rob
metdu podmienenou oznmenm serveru, aby v odpovedi poslal entitu iba vtedy, ak bola
zmenen od doby uvedenej v tejto hlavike. Inak server odole v odpovedi stavov kd 304 Not
modified. Hlavika If-None-Match predstavuje hlavikou s opanou podmienkou ako hlavika
If-Match. Hlavika If-Range je pouvan v kombincii s hlavikou Range a m umoni
klientovi kontrolu i bola entita zmenen a poiada server o zaslanie danej asti entity. Hlavika
If-Unmodified-Since je logickm opakom hlaviky If-Modified-Since. Hlavika MaxForwards stanovuje limit na poet postpen aliemu zariadeniu v reazci iadost. Pouva sa
iba s metdami TRACE alebo OPTIONS. Hlavika Proxy-Authorization je ako hlavika
Authorization, ale slia na predloenie autentizanch dajov proxy serveru. Hlavika Range
umouje klientovi poadova, aby mu server poslal iba as entity tak, e zad rozsah bajtov v
entite. Ak poadovan rozsah je platn, server odole iba poadovan as entity so stavovm
kdom 206 Partial Content. Hlavika Referer oznamuje serveru zdroj URL, z ktorho bola
zskan adresa URL aktulnej iadosti. Hlavika TE poskytuje informciu serveru o tom, ako si
klient praje zabezpei kdovanie prenosu entt poslanch serverom. Hlavika User-Agent
poskytuje informcie o klientovom softvri. Zvyajne ide o meno a slo verzie webovho
prehliadaa alebo in program posielajci iados. Proxy neupravuj toto pole pri postpen
iadosti aliemu zariadeniu, ale pouvaj hlaviku Via.
Na Obrzku . 10.20 s ukzan elementy truktry formtu sprvy iadosti HTTP a prklad
typov hlaviiek, ktor by mohla obsahova. Podobne ako vina iadost HTTP ani tto nenesie
iadnu entitu, take neexistuj iadne hlaviky entity a telo sprvy je przdne.
268
Obrzok . 10.20: Prklad formtu sprvy iadosti HTTP

10.3.3 Formt sprvy odpovedi
Odpove HTTP pouva formt sprvy vychdzajci z generickho formtu sprvy a obsahuje
v porad tieto asti: stavov riadok, veobecn hlaviky, hlaviky odpovede, hlaviky entity,
przdny riadok, prpadne telo sprvy a ukonenie (trailer) sprvy .
Generick tartovac riadok, ktorm zanaj vetky sprvy HTTP sa v prpade formtu sprvy
odpovede HTTP nazva stavov riadok. M dve funkcie: oznmi klientovi ak verziu
protokolu server pouva a oznmi vsledok spracovania iadosti klienta. Formlna syntax
stavovho riadku je:
<HTTP-VERSION> <status-code> <reason-phrase>, kdE
HTTP-VERSION je poloka v stavovom riadku, sli rovnakmu elu ako je to v

riadku iadosti v sprve iadosti. Oznamuje klientovi slo verzie protokolu, ktor server
pouva pre svoju odpove.
Status Code and Reason Phrase (Stavov kd a frza dvodu) poskytuj informcie o
vsledkoch spracovania iadosti klienta v dvoch rznych formch. Stavov kd je
trojmiestne slo oznamujce klientovi formlny vsledok vykonania jeho
predchdzajcej iadosti (na zklade tohto kdu me softvr klienta vykona prslun
akcie). Frza dvodu je al opisn textov reazec, ktor me by zobrazen
klientovi HTTP, aby klient videl ako server odpovedal.
Kad iados poslan klientom na server HTTP spsob jednu (alebo viacero) odpoved servera.
Prv riadok odpovede servera je stavov riadok, ktor obsahuje zhrnutie vsledkov spracovania
iadosti serverom. Stavov riadok obsahuje numerick stavov kd a text frzy dvodu.
Stavov kd HTTP je trojcifern slica zanajca slicou 1, 2, 3, 4 alebo 5. Stavov kd 1xx je
informan sprva, ktor poskytuje veobecn informciu, neindikuje spen vykonanie
iadosti HTTP alebo chybu. Stavov kd 2xx je sprva o spenom vykonan iadosti HTTP,
ktor indikuje, e matda uveden v iadosti bola serverom prijat, pochopen a akceptovan.
Stavov kd 3xx je sprva o presmerovan, ktor indikuje, e iados priamo nezlyhala, ale je
potrebn dodaton akcia predtm ne bude iados spene vykonan. Stavov kd 4xx je
sprva o chybe klienta, ktor indikuje, e iados HTTP je neplatn, obsahuje zl syntax alebo
neme by vykonan z nejakch inch dvodov pre chybu klienta. Stavov kd 5xx je sprva o
chybe servera, ktor indikuje, e iados HTTP je platn, ale server nebol schopn ju vykona z
dvodu jeho vlastnho problmu. Na Obrzku . 10.21 s uveden stavov kdy aj s frzou
dvodu poda [RFC 2616].
269
Obrzok . 10.21: Stavov kdy HTTP a frze dvodu

Sprva odpovedi bude vdy obsahova niekoko hlaviiek poskytujcich alie informcie o
sprve. Hlavika sprvy odpovede spadaj do tchto kategri:
Veobecn hlaviky, ktor sa vzahuj k samotnej sprve a nie s pecifick pre sprvy
odpovede alebo entite v tele sprvy. Jedn sa o rovnak ako veobecn hlaviky ako s
generick hlaviky, ktor sa mu vyskytn v sprvach iadost. Tieto hlaviky s
opsan v predchdzajcej asti
Hlaviky odpovedi poskytuj dodaton informcie, ktor roziruj vsledn informcie
v stavovom riadku. Server me tie vraca alie informcie o vsledkoch v tele sprvy
a to najm v prpade nastalej chyby.
Hlaviky entity opisuj entity obsiahnut v tele sprvy odpovedi, ak nejak je. Ide
o rovnak hlaviky entity, ktor sa mu objavi v sprve iadosti.
Hlaviky odpovede s samozrejme pouit iba v sprve odpovedi, zatia o ostatn s veobecn
s ohadom na typ sprvy.
Hlaviky odpovedi HTTP sa vyskytuj v sprvach odpoved HTTP. Poskytuj dodaton
informcie o funkcich a poiadavkch servera HTTP a vsledkoch spracovania iadosti klienta.
V tandarde HTTP/1.1 je definovanch dev hlaviiek odpoved. Hlavika Accept-Ranges
oznamuje klientovi, i server prijma alebo neprijma iadosti o iastkov obsah prostrednctvom
hlaviky Range, ak no, akho typu. Typick prklad je Accept-Range: bytes v prpade, e server
prijma bajtov rozsah alebo Accept-Range: none, ak rozsah iadosti nie je podporovan.
Hlavika Age oznamuje klientovi priblin vek zdroja, ako bol vypotan zariadenm
posielajcim odpove. Hlavika Etag pecifikuje znaku entity obsiahnutej v odpovedi.
Hlavika Location oznauje nov URL, ktor posiela server klientovi, aby ho klient pouil
namiesto URL, ktor klient pvodne poadoval. Hlavika Proxy-Authenticate je verzia hlaviky
WWW-Authenticate hlaviky. Je obsiahnut v odpovedi so stavovm kdom 407 Proxy
Authentication Required a indikuje ako proxy vyaduje od klienta vykona autentizciu.
Hlaviku Retry-After niekedy obsahuje odpove na nespen iadosti ako s iadosti s
vsledkom so stavovm kdom 503 Service Unavailable. Hlavika Server je serverov verzia
hlaviky User-Agent. Identifikuje typ a verziu softvru servera generujceho odpove. Proxy
neupravuje toto pole pri posvan odpovedi, proxy vlo svoje identifikan informcie do
hlaviky Via. Hlavika Vary pecifikuje i je na iados mon odpoveda odpoveou z pamti
270
cache. Hlavika WWW-Authenticate je obsahnut v odpovedi so stavovm kdom 401

Unauthorized a indikuje ako server vyaduje od klienta vykona autentizciu.
Hlaviky entity HTTP sa vyskytuj v sprvach adost alebo v sprvach odpoved, ktor
prenaj v tele sprvu entitu. Hlaviky opisuj povahu entity vrtane jej typu, jazyka
a kdovania s cieom zabezpei riadne spracovanie a prezentciu entity prijmajcim
zariadenm. V alom s strune opsan hlaviky entity HTTP/1.1. Hlavika Allow zabezpe
zoznam vetkch metd podporovanch konkrtnym zdrojom. Hlavika Content-Encoding
opisuje kad voliten metdu, ktor me by pouit na kdovanie entity. Hlavika ContentLanguage pecifikuje jazyk uren na pouitie entity. Toto je voliten hlavika a nemus by
vhodn pre vetky typy zdrojov. Hlavika Content-Length udva vekos entity v bajtoch. Tto
hlavika je dleit, pretoe je pouvan prjemcom na urenie konca sprvy. Hlavika
Content-Location pecifikuje zdrojov umiestnenie entity a to v tvare absoltneho alebo
relatvneho URL. Hlavika Content-MD5 obsahuje heovaciu hodnotu entity vypotan
heovacou funkciou MD5, pouva sa na kontrolu integrity sprvy. Hlavika Content-Range je
poslan v prpade, ke sprva obsahuje entitu, ktor je len asou celho zdroja. Naprklad
fragment sboru poslan v odpovedi na iados HTTP s metdou GET obsahujcu hlaviku
Range. Hlavika Content-Type pecifikuje medilny typ a podtyp entity a to spsobom vemi
podobnm ako sa pouva v hlavike MIME ([RFC 2045] a [RFC 2049]). Hlavika Expires
pecifikuje dtum a as, po uplynut ktorhu by mala by entita v sprve povaovan za "star"
(stale). Me by pouit na identifikciu uritch entt, ktor by mali by ponechan v pamti
HTTP cache na dlhiu alebo kratiu dobu ne je obvykl. Hlavika Last-Modified udva dtum
a as poslednej zmeny entity. Tto doba je uren na zklade informci servera.
HTTP podporuje dve rovne kdovania prenosu dajov. Prv z nich je kdovanie obsahu
(hlavika Content-Encoding), ktor sa pouva v niektorch prpadoch k transformcii entity
prenanej v sprve HTTP. Druh je kdovanie prenosu (hlavika Transfer-Encoding), ktor sa
pouva na zakdovanie celej sprvy HTTP, aby sa zaistila jej bezpen preprava. Kdovanie
obsahu je asto pouvan v prpade, ke entity s komprimovan na zvenie innosti
komunikcie, kdovanie prenosu sa pouva predovetkm na rieenie problmu svisiaceho s
identifikciou konca sprvy.
Vzhadom k tomu, e HTTP/1.1 pouva trval spojenie umoujce poslanie viacerch iadost
a odpoved v jednom spojen TCP, potrebuj klient a server nejak spsob identifikcie konca
jednej sprvy a zaiatku druhej sprvy. Jednoduchm rieenm je pouitie hlaviky ContentLength pecifikujcej vekos sprvy. To vak funguje len vtedy, ke sa vekos sprvy d
vopred ahko uri. Pre dynamick obsah alebo in prpady, v ktorch nie je mon vekos
sprvy ahko vypota pred poslanm dajov, me sa poui pecilne blokov kdovanie
prenosu. V tomto prenose je telo sprvy poslan ako postupnos blokov (chunk) a kad blok
zana informciou o dke bloku.
Ke je pouit blokov kdovanie prenosu, me odosielate sprvy presun urit hlaviky zo
zaiatku na koniec sprvy, ktorm sa potom hovor ukonenie. Prjemcom s interpretovan
rovnakm spsobom ako ben hlaviky. V takchto sprvach sa pouva pecilna hlavika
Trailer, ktor informuje prjemcu, aby po tele sprvy hadal ukonenia.
HTTP obsahuje funkciu dohadovanie obsahu, ktor umouje vber konkrtnej reprezentcie
zdroja, pokia m zdroj viac ako jednu reprezentciu. Existuj dve techniky dohadovania:
serverom riaden, v ktorej klient vo svojej iadosti uvedie hlaviky vyjadrujce jeho
preferencie a server sa sna o vber najvhodnejieho variantu, a agentom riaden, v ktorej
server odole klientovi zoznam alternatv dostupnch zdrojov a klient si vyberie jednu z nich.
271
Obrzok . 10.22: Prklad formtu sprvy odpovedi HTTP

Najastejie pouvan typ dohadovania obsahu v protokole HTTP je serverom riaden typ.
Klient odoslanm iadosti me uvies a tyri rzne hlaviky poskytujce informcie o tom, ako
by mal server vyplni jeho iados. Hlaviky mu obsahova voliten hodnoty kvality, ktor
uruj klientove relatvne preferencie medzi sborom alternatvnych charakteristk zdrojov ako je
typ mdia, jazyk, znakov sada a kdovanie. Ako prklad mono uvies hlaviku v iadosti
klienta Accept: text/html, text/*;q=0.7, */*;q=0.1. Touto hlavikou klient vyjadruje takto svoje
preferencie: moja preferencia (q=1) je textov dokument HTML, ak nie je dostupn, potom
preferujem nejak in typ dokumentu (q=0.7), ak nie je ani ten s preferenciou q=0.1 mi poli in
typ dokumentu, ktor je relevantn poadovanmu zdroju.
Vina sprv odpoved obsahuj entitu v tele sprvy. V prpade spenej iadosti na zskanie
zdroja, je v tele sprvy samotn zdroj. Odpovede indikujce nespen iadosti obyajne
obsahuj podrobn informcie o chybe v chybovej sprve, ktor je asto vo formte HTML.
Obrzok . 10.22 ilustruje kontrukciu odpovede HTTP a obsahuje prklad oboch hlaviiek a tela.
Stavov kd 200 znamen, e sa jedn o spen odpove na iados. Sprva obsahuje v tele
sprvy krtku textov HTML entitu.
10.3.4 Bezpenos a privtnos
Autentizan metdy pouit v protokole HTTP/1.1 s podrobne rieen v dokumente [RFC
2617]. Tento dokument vysvetuje dve autentizan metdy a to zkladn (basic) a metdou
digest (heovacou hodnotou). Zkladn autentizan metda predstavuje klasick autentizciu
menom a heslom. Ke klient odole iados na server, ktor vyaduje autentizciu pre prstup k
zdroju, server odole na pvodn iados klientovi odpove, ktor obsahuje hlaviku WWWAuthenticate. Klient potom pole nov iados obsahujcu hlaviku Authorization, ktor
obsahuje meno a heslo pouvatea kdovan schmou base64. Autentizcia metdou digest
pouva rovnak hlaviky ako zkladn autentizan metda, ale vyuva sofistikovanejie
techniky na vpoet heovacej hodnoty (jednorzovho hesla), ktor chrnia pred tonikmi
a zamedzuj odchyteniu autentizanch dajov. Metda digest nie je povaovan za tak siln ako
je autentizcia certifiktom verejnho ka, ale je ovea lepie ako zkladn autentizan
metda. Podrobnosti mono njs v dokumente [RFC 2617].
Protokol HTTP priamo neobsahuje iadny mechanizmus na ochranu privtnosti prenanch
dokumentov alebo sprv. Existuj vak dva rzne prstupy, ktormi sa to zvyajne zabezpeuje.
272
Najjednoduch spsob je ifrovanie zdroja na serveri a dodanie platnho deifrovacieho ka

iba oprvnenm pouvateom. Aj ke tonk zachyt cel sprvu, entita sama bude stle
zabezpeen. rove ochrany entity tu zvis na kvalite pouitho ifrovania. alou benejou
metdou je pouitie dodatonho protokolu, ktor je uren pecilne pre zabezpeenie
privtnosti transakcie HTTP. Vemi asto sa pouva protokol SSL (Secure Sockets Layer).
Servery pouvaj SSL na ochranu citlivch zdrojov, ako s naprklad zdroje spojen s
finannmi transakciami. Tieto s prstupn pomocou schmy URL "https" a nie "http" vo
webovom prehliadai. Verzia protokolu SSL prevzat do dokumentov IETF sa nazva protokol
TLS (Transport Layer Security).
Protokol HTTP je bezstavov protokol, pretoe server narba s kadou klientovou iadosou
nezvisle na predchdzajcich iadostiach. Tto charakteristika protokolu HTTP nie je
problmom pre vinu benho pouvania vo svetovej pavuine www, ale je to problm pre
interaktvne aplikcie ako elektronick obchody. Pouvate si jednotlivmi iadosami HTTP v
priebehu asu vyber tovar do nkupnho koka a server by mal sledova, e do koka uklad
tovar ten ist pouvate. Na podporu tchto aplikci, vina implementci HTTP obsahuje
voliten funkciu nazvan stavov manament poda [RFC 6265]. Ak je stavov manament
povolen, potom server odole klientovi mal mnostvo informci nazvanch cookie. Cookie je
uloen na klientskom potai a obsahuje dleit informcie relevantn konkrtnej webovej
aplikcii ako je meno zkaznka, poloky v nkupnom koku alebo meno a heslo. daje z cookie
s posielan sp na server s kadou nslednou iadosou s tm, e sa serveru dovouje tieto
informcie aktualizova a op posla klientovi sp. Cookies takto umouj serverom pamta
si pouvatesk daje medzi iadosami.
Koncepcia cookies m aj svoje potencilne problmy. Prvm problmom je prenos citlivch
informci. Nech naprklad pouvate pouva systm internetbankingu. Pouvate sa prihlsi
na server, ktor potom ulo meno konta a heslo (autentizan daje riadiace prstup k tu) do
cookie. Ak nie je aplikcia implementovan starostlivo, me by sprva obsahujca cookie
odchyten tonkom a tento me potom nsledne autentizan daje zneui. Alebo je mon
in scenr. Niekto znal me zska prstup do stroja pouvatea a me zska prstup do
sboru, kde s uloen cookie. Druhm problmom je neiadce pouitie cookies. Teoreticky
by cookie mali by pre pouvatea prnosom a nie problmom. Avak kad server me
vytvori cookie z akhokovek dvodu. V niektorch prpadoch by mohol server nastavi cookie
pre ely monitorovania sdiel, ktor pouvate navtvi. Takto aktivitu servera mu niektor
pouvatelia povaova za poruenie ich skromia. Vzhadom k tomu, e niektor webov
prehliadae neinformuj pouvatea, ke sa vytvor cookie, pouvate si nemus by toho ani
vedom. Tretm problmom s cookies tretej strany alebo nemyseln cookies. Zatia o
vina pouvateov si o cookies mysl, e cookies s vytvoren v kontexte prostriedku, ktor
konkrtne poaduj, cookie mu by vytvoren ubovonm serverom, ktormu je zaslan
iados. Naprklad pri odoslan iadosti http://www.firma.sk/index.htm me tto strnka
obsahova odkaz na logo firmy, ktor sa nachdza na serveri http://www.logafiriem.sk. Druh
sdlo me vytvori cookie na potai pouvatea, aj ke pouvate nemal nikdy v mysle
k tomuto sdlu pristpi. Tomuto sa hovor cookie tretej strany. Cookies tretch strn mu by
pouit on-line reklamnmi spolonosami a inmi na sledovanie sdiel, ktor pouvate
navtevuje. Z tohto dvodu s povaovan mnohmi za neiaduceho softvr s nzvom spyware.
Existuje mnoho vone ritench nstrojov, ktor umonia pouvateovi identifikova a
odstrni sledovacie cookie z potaa.
Miera kontroly cookie je vemi zvisl na kvalite a nastavench funkcich webovho
prehliadaa. Mnoho prehliadaov neposkytuj kontrolu toho, ako a kedy s cookies na stroji
pouvatea vytvoren, zatia o in prehliadae s v tomto ohade ovea lepie. Niektor
prehliadae umouj cookies zakza, ale zvyajne po intalcii prehliadaa s v
preddefinovanom nastaven zapnut. Najpozoruhodnejie v tomto ohade je populrny prehliada
Microsoft Internet Explorer, ktor m preddefinovan nastavenie cookies zapnut. To znamen,
e je tandardne nastaven tak, aby akceptoval vetky cookies bez obmedzenia a dokonca aj bez
hlsenia.
273
Webov prehliada Internet Explorer umouje vypn cookies, ale mus to urobi pouvate.
Tie umouje rozliova medzi cookies prvej strany a cookies tretch strn, ale op si to mus
zapn pouvate. Ostatn prehliadae maj sofistikovanejie nastavenia, ktor umonia
pouvateovi predpsa podmienky, pri ktorch sa cookie mu na pouvateovom stroji
vytvra a pri ktorch nie. Niektor prehliadae dokonca umouj pouvateovi nastavi
niektor lokality, od ktorch je mon prija cookie a uloi ho na pouvateovom stroji a
zrove zakazuje im prija cookie od ostatnch. Lepie prehliadae tie dovouj pouvateovi
vizulnu kontrolu cookies a selektvne vymazanie tch cookies, ktor pouvate nechce na
svojom stroji.
10.3.5 Pouit zdroje
[RFC 822]
[RFC 2045]
[RFC 2046]
[RFC 2047]
[RFC 2048]
[RFC 2049]
[RFC 2616]
[RFC 2617]
[RFC 6265]
CROCKER, D. H.: Standard for the format of ARPA Internet text

messages. August 1982
(MIME) Part One: Format of Internet Message Bodies. November 1996
(MIME) Part Two: Media Types. November 1996
(MIME) Part Three: Message Header Extensions for Non-ASCII Text.
November 1996
FREED, N. , KLENSIN, J., POSTEL, J.: Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures. November 1996
(MIME) Part Five: Conformance Criteria and Examples. November 1996
FIELDING, R., GETTYS, J., MOGUL, J. C., FRYSTYK, H., MASINTER,
L., LEACH, P., BERNERS-LEE, T.: Hypertext Transfer Protocol -HTTP/1.1. June, 1999
FRANKS, J., HALLAM-BAKER, P., HOSTETLER, J., LAWRENCE, S.,
LEACH, P., LUOTONEN, A., STEWART, L.: HTTP Authentication:
Basic and Digest Access Authentication. June 1999
BARTH, A.: HTTP State Management Mechanism. April 2011.
274
10.4 Virtulne privtne siete VPN

Virtulna privtna sie (Virtual Private Network) je rozrenie privtnej siete organizcie
(intranetu) cez verejn siete, ako je naprklad Internet alebo sie poskytovatea internetovch
sluieb ISP (Internet Service Provider), vytvorenm bezpenho privtneho spojenia. VPN
bezpene doprav informcie cez Internet pripojenm vzdialench pouvateov, poboiek
organizcie a obchodnch partnerov do rozrenej siete organizcie. VPN je virtulna sie. To
znamen, e fyzick infratruktra sieti mus by transparentn pre kad spojenie VPN. Vo
vine prpadov to tie znamen, e fyzick sie nie je vlastnen pouvateom VPN, ale je to
verejn sie spolone pouvan s mnohmi almi pouvatemi. Na podporu potrebnej
transparentnosti pre vyie vrstvy sa pouvaj techniky tunelovacch protokolov. VPN je
privtna sie, o v tomto kontexte znamen zaistenie privtnosti premvky prenanej cez VPN.
VPN premvka sa asto vykonva cez verejn siete a preto musia by realizovan opatrenia na
zaistenie potrebnej bezpenosti, ktor je poadovan pre kad jednotliv profil premvky cez
spojenie VPN. Tieto bezpenostn poiadavky s na ifrovanie dajov, autentizciu pvodu
dajov, bezpen generciu a vasn obnovu kryptografickch kov potrebnch na ifrovanie
a autentizciu a na ochranu pred tokmi znovopsielanm paketov a falovanm adresy. VPN je
sie a mus by prakticky tak chpan a mus by s ou narban ako s rozrenm sieovej
infratruktry organizcie. To sa tka zariaden a aplikci, ktor ju vytvraj, vrtane
smerovania a adresovania.
V praxi je mon rozpozna tri charakteristick scenre pouvania VPN [HEN06] a to je
pripojenie vzdialenho pouvatea do potaovej sieti organizcie, pripojenie obchodnho
partnera do potaovej sieti organizcie a prepojenie potaovej sieti poboky organizcie a
potaovej sieti v hlavnom sdle organizcie.
Obrzok . 10.23: Pripojenie vzdialenho pouvatea do siete organizcie

Pripojenie vzdialenho pouvatea do potaovej sieti organizcie i u z domu alebo na
cestch je mon bezpene a cenovo efektvne vykona prostrednctvom ISP a Internetu.
Jeden zo spsobov, ako realizova tento scenr je vyuitie tunelovacch protokolov ako L2TP,
PPTP alebo L2F. alm spsobom je pouitie protokolu IPSec (Internet Protocol Security), ak
vzdialen klient takto monos podporuje, a bezpenostnej brny. Tento prpad je
dokumentovan na Obrzku . 10.23. V idelnom prpade je mon poui kombinciu oboch
rieen, ktor zaist najlepiu ochranu a cenovo najefektvnej spsob vzdialenho prstupu.
Klient pristupuje k Internetu prostrednctvom telefnnej linky (naprklad technolgiou ADSL) do
siete ISP a potom zriauje autentizovan a ifrovan tunel medzi sebou a bezpenostnou brnou
na hranici intranetu. Pomocou autentizcie protokolom IPSec medzi vzdialenm klientom
a bezpenostnou brnou je mon chrni intranet pred nechcenmi a mono kodlivmi paketmi
IP. A zaifrovanm premvky, ktor sa prena medzi vzdialenm pouvateom a bezpenostnou
brnou, je mon zaisti privtnos premvky. alou monosou pripojenia klienta, naprklad
275
k serveru intenetbankingu, je vytvorenie bezpenho a autentizovanho tunela pomocou

protokolu SSL (Secure Socket Layer).
Pripojenie obchodnho partnera do potaovej sieti organizcie. Niekto sa rozhodne na
dosiahnutie takhoto pripojenia implementova protokolom Frame Relay a/alebo zakpi
prenajat okruhy (ttna pokladnica). Toto rieenie je asto drah a geografick psobnos me
by obmedzen. Nech naprklad organizcia je hlavnm dodvateom dielov pre vrobcu. Pre
hladk priebeh vroby je kritick, aby vrobca mal na dan as urit diely a v uritch
mnostvch. Treba navrhn jednoduch, rchly a efektvny spsob komunikcie medzi
organizciou a vrobcom. Vzhadom na dvernos a asov citlivos tchto informci vrobcu
nie je akceptovaten zverejnenie tchto dajov na webovej strnke vrobcu alebo ich
distribuovanie prostrednctvom mesanch sprv. Na zaistenie bezpenej komunikcie medzi
organizciou a vrobcom je mon zriadi VPN poda Obrzku . 10.24. VPN me by
zriaden medzi klientskou pracovnou stanicou na intranete organizcie a priamo serverom (server
obsahuje informcie o stave zsob dielcov a plne potrieb) umiestnenm na intranete vrobcu.
Klienti sa mu autentizova na bezpenostnej brne alebo smerovai, ktor chrni intranet
vrobcu a priamo na serveri vrobcu, v zvislosti na bezpenostnej politike vrobcu.
Obrzok . 10.24: Pripojenie obchodnho partnera do siete organizcie

Scenr prepojenia potaovej sieti poboky organizcie a potaovej sieti v hlavnom sdle
organizcie zaisuje bezpen prepojenie dvoch dveryhodnch intranetov. Bezpenos sa
zameriava ako na ochranu intranetu organizcie proti vonkajiemu tonkovi tak na
zabezpeenie dajov organizcie pri prenose cez verejn Internet. Prepojenie VPN (s vyuitm
Internetu) medzi pobokou a hlavnm sdlom organizcie me by zriaden ahko a me
splova bezpenostn potreby organizcie. Na Obrzku . 10.25 je dokumentovan jedno
rieenie prepojenia VPN medzi hlavnm sdlom organizcie a jej pobokami. Organizcia si
zakpi internetov prstup od ISP. Na hranici kadho z intranetov by mali by umiestnen,
z dvodov ochrany komunikcie organizcie, bezpenostn brny alebo smerovae so vstavanou
funkciou bezpenostnej brny alebo v niektorch prpadoch server s funkciou IPSec. V takomto
scenri nemusia klienti a servery podporova technolgiu IPSec, pretoe bezpenostn brna
(alebo smerova) s podporou IPSec by poskytoval potrebn autentizciu paketov a ifrovanie
dajov. Takto by vetky dvern informcie boli skryt pred nedveryhodnmi pouvatemi na
Internete a navye by bezpenostn brna odmietala prstup vetkm potencilnym tonkom.
Zriadenm pripojenia poboiek prostrednctvom VPN bude hlavn sdlo spolonosti schopn
komunikova bezpene a sporne so svojimi pobokami bez ohadu na to, kde sa poboky
geograficky nachdzaj. Prostrednctvom technolgie VPN kad poboka me tie rozri
rozsah svojho existujceho intranetu, zalenenm intranetov ostatnch poboiek, a tak vytvori
rozren potaov sie celej organizcie. Organizcia me potom ahko rozri takto
novovytvoren potaov sie pripojenm svojich obchodnch partnerov, dodvateov a
vzdialench pouvateov prostrednctvom naprklad technolgie IPSec.
276
Obrzok . 10.25: Pripojenie poboky organizcie do siete organizcie
10.4.1 Protokol L2TP

V tejto asti sa budeme zaobera protokolmi, ktor umouj spojenie na druhej vrstve (poda
sieovho referennho modelu ISO/OSI). tandardne ide o protokol PPP (Point to Point
Protocol) [RFC 1661], [RFC 2516] tunelovan cez in siete, bene siete IP. Zd sa to ako zloit
prstup obsahujci vek riu, ale tento prstup prina niekoko uitonch vhod pre
budovanie VPN. V skutonosti by bol poet internetovch scenrov VPN alebo monost bez
pouitia tunelovacch technk pre druh vrstvu dos obmedzen.
Protokol L2TP (Layer 2 Tunneling Protocol) je jednou zo tandardnch technk na zabezpeenie
vzdialenho pripojenia do sieti intranet organizcie. Protokol L2TP vznikol zlenm dvoch
rznych protokolov: Point-to-Point Tunneling Protocol (PPTP) [RFC 2637] a Layer 2
Forwarding (L2F) [RFC 2341]. L2TP je definovan v RFC 3931.
L2TP zabezpeuje techniku na zriadenie tunela PPP. Namiesto toho, aby protokol PPP bol
ukonen najbliom mieste POP ISP (Point Of Presence, prstupov miesto do siete ISP),
protokol L2TP zabezpe ukonenie protokolu PPP na poslednej prstupovej brne intranetu
organizcie. Tunel me zaa bu na vzdialenom hoste alebo na prstupovej brne ISP. L2TP
zabezpeuje spoahliv spsob pripojenia vzdialench pouvateov do VPN, ktor podporuje
premvku s viacermi protokolmi. To znamen, e podporuje vetky protokoly sieovej vrstvy
podporovan protokolom PPP. Okrem toho, pre spojenia cez Internet L2TP zabezpeuje podporu
vetkch privtnych adresovacch schm na sieovej vrstve.
Koncepcia protokolu L2TP predpoklad tieto entity:
Prstupov koncetrtor LAC (L2TP Access Concentrator) sa nachdza na POP ISP

a zabezpeuje fyzick spojenie vzdialenho pouvatea. Z koncentrtora LAC s alej
zriaden spojenia L2TP, ktor LAC smeruje na jeden alebo viacer servery LNS, na
ktorch tunely L2TP konia.
Sieov server LNS (L2TP Network Server). Na serveri LNS je ukonen spojenie
L2TP. Na ukonenie spojen vzdialench pouvateov na LNS me by pouit iba
jedno spojenie.
Sieov prstupov server NAS (Network Access Server) je point-to-point prstupov
zariadenie, ktor na poiadanie zabezpeuje prstup vzdialench pouvateov cez linky
PSTN (Public Switched Telephone Network) alebo ISDN (Integrated Services Digital
Network).
Na Obrzku . 10.26 je schematicky dokumentovan zkladn koncepcia protokolu L2TP.
277
Obrzok . 10.26: Koncepcia protokolu L2TP

Zriadenie relcie a tunela L2TP s zabezpeen v tchto krokoch:
1
Vzdialen pouvate iniciuje pripojenie protokolom PPP na NAS.
Server NAS akceptuje pripojenie.
Autentizcia koncovho pouvatea je vykonan na NAS prostrednctvom autorizanho

servera (tandardne server RADIUS).
Koncetrtor LAC je spusten pokusom koncovho pouvatea otvori spojenie s LNS na

vytvorenie tunela s LNS, ktor je umiestnen na hranici intranetu organizcie. Kad pokus
o pripojenie otvra spojenie a je riaden koncentrtorom LAC. Datagramy s posielan cez
tunel od koncentrtora LAC na server LNS. Zariadenie LAC a LNS eviduj stav
pripojenho pouvatea.
Vzdialen pouvate je autentizovan tie autentizanm serverom na brne LNS predtm,

ne je akceptovan vytvorenie tunela.
Server LNS akceptuje pripojenie a vytvor tunel L2TP.
Server NAS zaprotokoluje akceptovanie.
Server LNS si so vzdialenm pouvateom dohaduje protokolom PPP podmienky prenosu.
Odteraz mu by tunelovan daje medzi vzdialenm pouvateom a serverom LNS.
Protokol L2TP podporuje dva typy tunelov a to povinn a dobrovon tunel. Povinn tunel
L2TP je zriaden od LAC cez ISP a k LNS na sieti organizcii. Tento koncept si vyaduje
spoluprcu poskytovatea internetovch sluieb, ktor mus podporova protokol L2TP a mus
stanovi na zklade autentizanch informci, i me by L2TP pouit pre konkrtnu relciu
a kam m by tunel smerovan. Takto prstup nevyaduje iadne zmeny na strane vzdialenho
klienta a umouje centralizovan prideovanie adresy IP vzdialenmu klientovi sieou
organizcie. Takisto vzdialenmu klientovi ISP neposkytne prstup na Internet, okrem prstupu
cez brnu zo sieti organizcie. Takto organizovan prstup vzdialenho pouvatea na Internet
umouje organizcii lepie riadenie bezpenosti. Zriadenie povinnho tunela L2TP sa vykon
poda tejto postupnosti krokov:
1
Vzdialen pouvate iniciuje spojenie PPP do ISP.
ISP akceptuje spojenie a tm je zriaden linka PPP.
ISP vykon iaston autentizciu a zist meno pouvatea.
ISP udriava databzy mapujce pouvateov na sluby a na koncov body tunelov LNS.
LAC potom inicializuje tunel L2TP na LNS.
Ak LNS akceptuje spojenie, potom LAC zapzdri PPP do L2TP a odovzd ho prslunmu
tunelu.
278
LNS akceptuje tieto rmce, odstrni obal protokolu L2TP a alej ich spracovva ako
normlne prichdzajce rmce PPP.
LNS potom pouije autentizciu PPP na potvrdenie pouvatea a prirad mu adresu IP.
Dobrovon tunel L2TP je zriaden medzi vzdialenm klientom (ktor efektvne funguje ako
LAC) a serverom LNS v potaoveh sieti organizcie. Tto metda je podobn PPTP a je v
podstate pre ISP transparentn, ale vyaduje podporu L2TP na strane klienta. Tento prstup
umouje vzdialenmu klientovi prstup na Internet, takisto ako jedno alebo viacero pripojen
VPN sasne. Klient vak nakoniec skon pridelenm viacerch adries IP, jedna adresa IP od
ISP pre pvodn PPP spojenie a jedna adresa IP pridelen sieou organizcie pre tunel VPN
L2TP. Tm sa otvor klient a rovnako aj sie organizcie na potencilne toky zvonku. Tto
skutonos vyaduje potrebu klientskych aplikci na urenie sprvnych cieov pre ich dajov
premvky. Zriadenie dobrovonho tunela L2TP sa vykon poda tejto postupnosti krokov:
1
Vzdialen pouvate m u zriaden spojenie do ISP.
Klient L2TP (LAC) iniciuje tunel L2TP do LNS.
Ak LNS akceptuje spojenie, potom LAC zapzdri PPP do L2TP a pole ho tunelu.
Server LNS akceptuje tieto rmce, odstrni obal protokolu L2TP a spracuje ich ako
normlne prichdzajce rmce.
LNS potom pouije autentizciu PPP na potvrdenie pouvatea a prirad mu adresu IP.
Vytvorenie tunela prostrednctvom protokolu L2TP ete neznamen, e prenan daje s pred
tonkom skryt a pvod dajov je autentick. Tunel L2TP je vytvoren zapzdrenm rmca
L2TP do datagramu UDP a nslednm zapzdrenm do paketu IP. Zdrojov a cieov adresa
paketu IP spolone uruj koncov body tunela. Tto koncepcia je dokumentovan na Obrzku .
10.27 a predpoklad, e LAC a LNS s vybaven prslunm softvrom na vytvorenie
a ukonenie L2TP tunela, prpadne LNS je vybaven softvrom smerovaa. Pretoe vonkajie
zapzdrenie je protokolom IP, me by jednoducho namiesto protokolu IP pouit jeho
bezpenostn verzia IPSec. Takmto spsobom mono bezpenostne zaisti daje prenan
v tuneli L2TP, t.j. mu by priamoiaro pouit protokoly svisiace s IPSec a to AH
(Authentication Header), ESP (Encapsulating Security) a IKE (Internet Key Exchange).
Obrzku . 10.27: Zapzdrenie tunela L2TP

Pouitie technolgie IPsec v spojen s protokolom L2TP me poskytn bezpen spojenie endto-end medzi vzdialenmi pouvatemi a intranetom organizcie [RFC 3193]. IPSec me do
protokolu L2TP prida mechanizmus autentizcie jednotlivch paketov a kontroly integrity
namiesto jednoduchej autentizcie koncovho bodu tunela, ktor nie je zabezpeen proti tokom
z uzlov nachdzajcich sa v sieti pozd cesty spojenia tunela. Navye IPSec pridva do
protokolu L2TP ifrovacie funkcie na zaistenie dvernosti dajov prenanch v nklade L2TP
a na bezpeen spsob pre automatizovan generovanie a vmenu kryptografickch kov
v rmci spojenia tunela. Nasledujce Obrzky . 10.28 a 10.31 ukazuj alie prklady ako je
mon poui protokol IPSec v spojen s L2TP.
279
Obrzok . 10.28: Protokol IPSec je pouit na zabezpeenie povinnho tunela L2TP na

brnu VPN
Obrzok . 10.29: Protokol IPSec je pouit na zabezpeenie volitenho tunela L2TP na

brnu VPN
Obrzok . 10.30: Protokol IPSec je pouit na zabezpeenie povinnho tunela L2TP

end-to-end
280
Obrzok . 10.31: Protokol IPSec je pouit na zabezpeenie volitenho tunela L2TP

end-to-end
10.4.2 Protokol IPSec
tandard IPSec, pvodne pecifikovan v [RFC 2401], [RFC 2402], [RFC 2403], [RFC 2404],
[RFC 2406], [RFC 2408], [RFC 2409] a [RFC 2412], poskytuje metdu autentizcie a ochrany
dajov pri bezpenom prenose sprvy. IPSec obsahuje protokol ISAKMP/Oakley (Internet
Security Association a Key Management Protocol) a dva protokoly IPSec: IPSec ESP
(Encapsulating Security Protocol) a IPSec AH (Authentication Header). IPSec pouva na
ochranu dajov symetrick ifrovacie algoritmy. Symetrick ifrovacie algoritmy s asovo
efektvnejie a jednoduchie sa implementuj v hardvri. Tieto algoritmy potrebuj na
zabezpeenie ochrany dt bezpen spsob zriadenia a vmeny ifrovacch kov. Tto
monos zabezpeuj protokoly IKE (Internet Key Exchange) ISAKMP/ Oakley. IPSec tie
obsahuje niekoko spsobov vytvorenia autentizanch kdov sprv HMAC (Hashed Message
Authentication Code), z ktorch si je mon vybra, kad z nich poskytuje rznu rove
ochrany pred tokmi ako s man-in-the-middle, znovuposlanie paketu (packet replay) a toky na
integritu dajov.
Bezpenostn rozrenie protokolu IP protokolom IPSec m dve monosti: protokoly IPSec ESP
a IPSec AH. Zhlavie ESP (protokol IP 50) tvor jadro protokolu IPSec. Tento protokol, spolu s
dohodnutm sborom bezpenostnch parametrov, zabezpeuje ifrovanie dajovej asti paketu
(nklad paketu) a pouva alie ochrany (HMAC) na zaistenie integrity dajov, zaistenie proti
toku znovuposlatia paketu a toku typu man-in-the-middle. Volitene me IPSec ESP tie
zabezpei autentizciu chrnench dajov. Na Obrzku . 10.32 je dokumentovan zapzdrenie
paketu IP paketom IPSec ESP. Protokol IPSec AH (protokol IP 51) tvor druh as IPsec.
IPSec AH nezabezpeuje ifrovanie dajov benm spsobom, ale pridva k dajom v pakete
autentizan kd, ktor chrni paket pred neoprvnenou modifikciou. Medzi chrnen daje
paketu tie mono zahrn nemeniten polia v zhlav IP ako s polia adresy IP. Protokol IPSec
AH nezabezpeuje dvernos dajov, preto neme by iba sm pouit v prpade, e je
poiadavka na dvernos dajov. Na Obrzku . 10.32 je dokumentovan zapzdrenie paketu IP
paketom IPSec AH.
Protokol IPsec me fungova v dvoch reimoch vo vzahu k prenaniu dajov cez sie a to
v transportnom reime a v tunelovom reime. Jedntliv reimy sa lia v spsobe pouvania ako
aj v mnostve vyadovanej rie. Tunelov reim funguje tak, e cel paket IP je zapzdren
a chrnen. Pretoe tunelov reim skryje aj zhlavie IP pvodnho paketu IP, pridva sa nov
zhlavie IP, aby mohol by paket cez tunel spene prenesen. ifrovacie zariadenie pozn
adresy IP (zaiatok a koniec tunela) v novom zhlav a tieto adresy bvaj tandardne nastaven
pri konfigurcii sieovej brny (naprklad smerovaa). Tunelov reim me by zriaden
jednm alebo obidvomi protokolmi IPsec (ESP a AH). Vsledkom pouitia tunelovho reimu je
rozrenie pvodnho paketu IP asi o 20 bajtov z dvodu zavedenia novho zhlavia IP.
281
Tunelov reim je veobecne povaovan za bezpenej a flexibilnej ne transportn reim.

Tunelov reim IPSec ifruje zdrojov a cieov adresu IP pvodnho paketu a teda skrva tieto
informcie na nechrnenej sieti pred potecionlnym tonkom. Na Obrzku . 10.32 je
dokumentovan zapzdrenie paketu IP paketom IPSec v tunelovom reime. Transportn reim
IPSec sa zriadi tak, e do paketu IP sa za zhlavie IP vlo zhlavie ESP alebo AH. Obe adresy
IP sieovch uzlov, medzi ktormi je premvka chrnen IPsec, s viditen v IP hlavike aj po
prpadnom ifrovan paketu. Tento reim IPSec me by citliv na toky analzy premvky.
Pretoe nie je pridan iadne alie zhlavie IP, z toho vyplva menie rozrenie vekosti
paketu. Transportn reim me by zriaden jednm alebo oboma protokolmi IPSec ESP a AH.
Na Obrzku . 10.32 je dokumentovan zapzdrenie paketu IP paketom IPSec v transportnom
reime.
Obrzok . 10.32: Formty paketov protokolu IPSec a zabezpeenie jednotlivch ast

formtu
Protokoly IPSec ESP a ISPSec AH je mon poui samostatne alebo v kombincii. Vzhadom
k tomu, e kad protokol m dva reimy, existuje cel rad monch kombinci. Aby to bolo
ete komplikovanejie, bezpenostn asocicie SA (Security Association - bezpenostn
asocicia je dohoda medzi dvoma entitami zapojenmi do pouvania kryptografickch
prostriedkov) IPSec AH a IPSec ESP nemusia ma rovnak koncov body. Prakticky pouvan
s vak iba niektor scnare. Kombincie protokolov IPSec s realizovan s balkami SA a
existuj dva prstupy na ich vytvorenie a to transportn priahlos (transport adjacency)
a vnoren tunelovanie (nested tunneling). V prstupe transportnej priahlosti s oba
bezpenostn protokoly pouit v transportnom reime toho istho paketu IP. Tto metda je
praktick iba pre jednu rove kombincie. tandard IPSec stanovuje, e transportn priahlos
susedov me by pouit iba spsobom uvedenm na Obrzku . 10.33. To znamen, e pre
odchdzajce pakety mus by vykonan ifrovanie (vntorn SA) pred autentizciou (vonkajia
SA), zatia o pre prichdzajce pakety sa mus autentizcia vykona pred ifrovanm. Toto je
logick nslednos a tie etr zaaenie systmu deifrovanm v prpade, ke skorej zlyh
autentizcia paketu (a teda deifrovanie sa nemus vykona). V prstupe vnorenho tunelovania
(nested tunneling) s oba bezpenostn protokoly aplikovan za sebou. Po kadom aplikovan je
vytvoren nov paket IP a na tento paket je aplikovan al protokol. Tto metda nem iadne
obmedzenia na poet vnorench rovn. Ale viac ako tri rovne vnorenia s nepraktick. Na
Obrzku . 10.34 je prklad vnorenho tunelovania. Najprv sa na paket IP aplikuje protokol IPSec
ESP v transportnom reime a nsledne protokol IPSec AH v tunelovom reime.
282
Obrzok . 10.33: Pouitie protokolu IPSec na transportn priahlos
Obrzok . 10.34: Pouitie protokolu IPSec na vnoren tunelovanie

Na implementciu rieenia VPN so ifrovanm je nevyhnutn pravideln vmena relanch
ifrovacch kov. Zanedbanie vmeny relanch kov me spsobi zranitenos
ifrovanch dajov prenanch VPN na tok hrubou silou. IPsec riei tento problm protokolom
IKE [RFC 5996], ktor vyuva alie dva protokoly na autentizciu entt vyuvajce
kryptografick prostriedky (krypto entity) a na generovanie kov. IKE vyuva matematick
algoritmus Diffie-Hellmanovej vmeny kov na generovanie symetrickch relanch kov,
ktor s potom pouit krypto entitami. IKE tie riadi dojednanie alch bezpenostnch
parametrov ako je vber chrnench dajov, sila kov, pouit heovacie funkcie a i pakety
chrni pred znovuposielanm. Protokol ISAKMP bene pouva port UDP 500 ako zdrojov a
cieov port.
Bezpenostn asocicia SA (Security Association) je dohoda medzi dvomi krypto entitami. Tto
dohoda zahruje typ a silu ifrovacieho algoritmu pouitho na ochranu dajov. SA zahruje
metdu a silu autentizcie dajov a metdu vytvrania novch kov pre tto ochranu dajov.
Krypto entity s vytvoren poda alej uvedenho opisu.
Kad SA m stanoven dobu ivotnosti, poas ktorej je SA povaovan za platn. ivotnos je
meran v jednotkch asu existencie SA (v sekundch) a v jednotkch objemu prenesench
dajov (poet bajtov). ivotnos je dohodnut pri vytvoren SA. Tieto dve ivotnosti s
kontrolovan a vypranie jednej z nich zneplatn aktulnu SA. Za bench okolnost asov
283
ivotnos uplynie skorej ako objemov ivotnos. V prpade, e sledovan paket vyhovuje SA v
zverench 120 sekundch ivotnosti aktulneho SA, je tandardne vyvolan proces vytvorenia
novch relanch kov. Proces vytvorenia novch relanch kov zriadi nov aktulnu SA
predtm ne sa zru star SA. Vsledkom je plynul prechod zo starej SA na nov SA s
minimlnou stratou paketov v novej SA.
ISAKMP SA je jeden obojsmern bezpen dojednvac kanl pouvan oboma krypto entitami
na poslanie dleitch bezpenostnch parametrov entity, ako s bezpenostn parametre pre
IPSec SA (dajov tunel). tandardn politiky ISAKMP SA maj predvolen hodnotu ivotnosti
86.400 seknd (24 hodn) bez limitu na objem prenesench dajov.
IPsec SA je jednosmern komunikan kanl od jednej krypto entity do druhej krypto entity.
Skuton daje zkaznka prechdzaj iba IPSec SA a nikdy nie cez ISAKMP SA. Kad strana
IPSec tunela m pr IPSec SA na spojenie: jeden do vzdialenej krypto entity a druh zo
vzdialenej krypto entity. Tieto informcie o pre IPSec SA s uloen loklne v databze SA.
tandardn politiky IPsec SA maj predvolen ivotnos 3.600 seknd (1 hodinu) a objemov
ivotnos 4608000 kB.
Prv fza IKE predstavuje poiaton dojednanie obojsmernho ISAKMP SA medzi dvoma
krypto entitami. Tto fza sa asto nazva hlavn reim. Prv fza IKE zana vzjomnou
autentizciou krypto entt. Po spenej autentizcii sa krypto entity dohodn na ifrovacom
algoritme, heovacej funkcii a alch parametroch, potrebnch na vytvorenie ISAKMP SA.
Komunikcia medzi dvomi krypto entitami mu by predmetom odchytenia tonkom, ale
tonk m minimlnu ancu odhali ifrovac k. ISAKMP SA je pouit procesom IKE na
dojednanie bezpenostnch parametrov pre IPsec SA. Tieto informcie ISAKMP SA s uloen
loklne v databze SA kadej krypto entity.
Prv fza IKE m tri mon autentizan metdy:
Predvolen spolon k PSK (Pre-Shared Key). Predvolen spolon k je

administrtorom preddefinovan reazec ka vloen rune do kadej krypto entity a
sli na vzjomn identifikciu. Pomocou PSK s schopn dve krypto entity dojedna a
vytvori ISAKMP SA. PSK zvyajne obsahuje adresu IP hosta alebo podsiete a masku,
ktor je platn pre dan PSK.
Infratruktra verejnho ka PKI (Public Key Infrastructure) pomocou digitlnych
certifiktov X.509. Sasou certifiktu je nzov, sriov slo, doba platnosti a alie
informcie, ktor me zariadenie IPSec poui na urenie platnosti certifiktu.
Certifikty mu by tie zruen, o zariadenie IPSec odmietne na monos spenej
autentizcie.
Nhodn sla ifrovan RSA.
Na podporu premvky medzi krypto entitami cez NAT (Network Address Translator) alebo PAT
(Port Address Translator) zariadenia sa v sieti zavdza uzol IPSec NAT-T (Network Address
Translator - Transparency), ktor zapzdruje krypto pakety do obalu UDP a takto umouje
paketom prejs zariadeniami NAT alebo PAT. NAT-T je automaticky dojednan medzi dvoma
krypto entitami poas dojednvania ISAKMP s cieovm portom UDP 4500. Za zdrojov port sa
pouva nasledujci vy dostupn port. Ak je pouit port UDP 4500, potom sa cieov port
posunie na port UDP 4501, 4502 a tak alej, a pokia nie je zriaden relcia ISAKMP. NAT-T
je definovan v [RFC 3947].
V druhej fze IKE s procesom IKE pomocou obojsmernej ISAKMP SA dojednan asocicie
IPSec SA. Tto fza sa asto nazva rchly reim. Asocicie IPsec SA s vo svojej podstate
jednosmern, o spsobuje, e je oddelen vmena ka pre tok dajov od krypto entity a pre
tok dajov do krypto entity. Vhodou tejto stratgie je to, e daje prenan jednm smerom s
ifrovan inm kom ako daje prenan opanm smerom. To pre potencilneho tonka
znamen dvojnsobn nmahu pri snahe deifrova odchyten zaifrovan daje. Poas procesu
dojednania v rchlom reime sa krypto entity dohodn na kryptografickom sbore, heovacch
funkcich a ostatnch parametroch.
284
10.4.3 Protokol SSL/TLS

Protokol SSL vyvinula spolonos Netscape. Jeho verzia 3 bola publikovan ako predben
internetovdokument. (Ako historick dokument bol tento protokol opsan v [RFC 6101]).
Nsledne vznikla v rmci IETF (Internet Engineering Task Force, iniciatvna skupina pecialistov
navrhujca tandardy pre Internet) pracovn skupina TLS (Transport Layer Security) a navrhla
spolon tandard. Prv publikovan verziu TLS mono chpa v podstate ako SSL v3.1, ktor je
sptne kompatibiln s SSL v3. V tejto asti bude opsan zkladn charakteristika protokolu SSL
v3 a na zver hlavn rozdiely medzi SSL v3 a TLS [RFC 5246], [RFC 4346] a [RFC 2246].
Protokol TCP nezabezpeuje spoahliv bezpenostn slubu medzi komunikujcimi koncovmi
entitami (end-to-end security). Preto bolo nevyhnutn nad protokolom TCP v transportnej vrstve
navrhn al protokol SSL tak, aby protokol TCP bol schopn zabezpeova spoahliv
bezpen komunikciu dvoch koncovch entt. Samotn protokol SSL nie je jedin protokol, ale
predstavuje dve vrstvy protokolov. Na niej vrstve je protokol SSL Record Protocol (poskytuje
zkladn bezpenostn sluby rznym protokolom na vyej rovni, ako je naprklad protokol
HTTP) a na vyej vrstve s protokoly SSL Alert Protocol, SSL Change Cipher Spec Protocol
a SSL Handshake Protocol (pecifick protokoly SSL a s vyuit pri manamente SSL vmen).
Koncepcia protokolu SSL predpoklad relciu SSL a spojenie SSL, ktor s definovan takto:
Spojenie SSL je transport (poda defincie vrstvovho modelu OSI), ktor zabezpeuje
vhodn typ sluieb. Pre SSL toto spojenie zodpoved spojeniu odpovedajcich si entt
(sprvy medzi koncovmi uzlami SSL). Spojenia s doasn. Kad spojenie je
asociovan s jednou relciou.
Relcia SSL je asocicia medzi klientom a serverom. Relcie s vytvran
prostrednctvom protokolu SSL Handshake Protocol. Relcie definuj mnoinu
kryptografickch bezpenostnch parametrov, ktor mu by spolon medzi viacermi
spojeniami. Relcie sa vyuvaj na to, aby sa zamedzilo nronmu dohadovaniu
novch bezpenostnch parametrov pre kad spojenie.
SSL Record Protocol je protokol, ktor zabezpeuje dve sluby pre spojenia SSL a to
dvernos a integritu sprvy. SSL Handshake Protocol definuje spolon tajn ke, ktor s
vyuit pri konvennom ifrovan dajov nkladu SSL a pri tvobe autentizanho kdu sprvy
MAC (Message Authentication Code). Na Obrzku . 10.35 je zobrazen celkov funkcionalita
protokolu SSL Record Protocol. Tento protokol pri vysielan v zaiatonom uzle SSL
zabezpeuje prevzatie aplikanej sprvy, vykon fragmentciu sprvy do zvldnutench blokov,
volitene vykon kompresiu dajov bloku, ur autentizan kd bloku MAC, blok s pripojenm
autentizanm kdom zaifruje, prid zhlavie SSL a vyle ho v TCP segmente. Prijat TCP
segment v koncovom uzle SSL je potom poda protokolu SSL Record Protocol sptne
deifrovan, je verifikovan MAC bloku, volitene je blok dekompresovan a fragmenty s
zloen do sprvy pre aplikciu.
285
Obrzok . 10.35: Prenos dajov protokolom SSL Record Protocol

Change Cipher Spec Protocol je najjednoduch zo pecifickch protokolov SSL a pouva ho
protokol SSL Record Protocol. Pozostva z jedinej sprvy a z jedinho bajtu s hodnotou 1.
elom tejto sprvy je spsobi preklopenie pripravenej mnoina ifrovacch nstrojov (predtm
dohodnutej protokolom SSL Handshake Protocol) do aktulneho stavu a zaa pouva nov
mnoinu ifrovacch nstrojov v danom spojen.
Alert Protocol je vyuit pri prenose vstranch sprv SSL do odpovedajcej entity. Podobne
ako pri aplikanej sprve aj vstran sprvy s komprimovan a ifrovan poda nastavenho
aktvneho stavu. Kad sprva v tomto protokole sa sklad z dvoch bajtov. Prv bajt vyjadruje
zvanos sprvy a m hodnotu varovanie (warning) alebo fatlne (fatal). Ak je zvanos sprvy
fatlne, potom SSL okamite ukon spojenie, v ktorom vznikla situcia fatlne. Ostatn spojenia
relcie, v ktorom je spojenie so situciou fatlne, mu pokraova, ale v tejto relcii neme by
zriaden iadne nov spojenie.
Najkomplexnejou asou SSL je protokol SSL Handshake Protocol. Tento protokol umouje
vzjomn autentizciu klienta a servera, umouje dojednanie ifrovacieho algoritmu, algoritmu
na vpoet autentizanho kdu sprvy a kryptografickch kov pouitch na ochranu dajov
v SSL protokole. Protokol SSL Handshake Protocol sa vykon pred prenosom aplikanch
dajov. SSL Handshake Protocol pozostva z vmeny sprv medzi klientom a serverom. Sprvy
s zoskupen do tyroch fz. Na Obrzku . 10.36 je zobrazen postupnos vmeny sprv.
Sprvy v ztvorkch sa vymieaj volitene alebo zvisia na konkrtnej situcii a sprvy nie s
vdy poslan.
Prv fza Zriadenie bezpenostnch funkci. Tto fza sli na nadviazanie logickho
spojenia a na zriadenie bezpenostnch funkci, ktor bud s nm spojen. Tto fzu inicializuje
klient, ktor posiela sprvu client_hello s parametrami verzia (najvyia verzia SSL podporovan
klientom) a nhodn slo (klientom vytvoren nhodn slo pozostvajce z 32 bitovej hodnoty
asu a dtumu a 28 bajtov vytvorench nhodnm genertorom, vyuva sa pri vmene kov
proti tokom typu znovuprehratie). Na sprvu client_hello odpoved server sprvou
server_hello, ktor obsahuje rovnak parametre ako sprva client_hello. Interpretcia parametrov
sprvy server_hello je takto. Pole verzia obsahuje niiu verziu z verzi navrhnutej klientom a
najvyou verziou podporovanou serverom, nhodn slo je vytvoren serverom rovnakm
spsobom nezvisle na nhodnom sle klientovej sprve. Ak pole ID relcie (SessionID) klienta
bolo nenulov, potom tak ist hodnotu pouije aj server, v opanom prpade pole ID relcie
servera obsahuje hodnotu pre nov relciu. Pole ifrovacia suita (CipherSuite) obsahuje jednu
serverom vybrat ifrovaciu suitu zo ifrovacej suity navrhnutej klientom. Pole kompresie
(Compression) obsahuje kompresn metdu zvolen serverom z metd navrhnutch klientom.
286
Obrzok . 10.36: Vmena sprv v SSL Handshake Protocol

Prvm elementom v parametroch ifrovacej suity je metda vmeny kov (spsob, ktorm sa
dojedn vmena kryptografickch kov pre symetrick ifrovanie a MAC). S podporovan
tieto vmeny kov:
RSA tajn k je zaifrovan verejnm RSA kom prjemcu. Mus by k dispozcii

certifikt verejnho ka prjemcu.
Pevn Diffie Hellman (D-H) tto D-H vmena ka predpoklad, e server m
certifikt verejnho ka, ktor obsahuje verejn D- H parametre (prvoslo a
primitvny kore) a verejn D-H k. Klient poskytne svoje parametre verejnho D-H
ka v certifikte, ak sa poaduje autentizcia klienta, alebo v sprve vmeny ka.
Tto metda poskytuje pevn tajn k medzi komunikujcimi entitami, nakoko je
tajn k vypotan z pevnch verejnch D-H kov entt.
Doasn D-H - tto D-H vmena ka poskytuje vytvorenie doasnho
(jednorzovho) tajnho ka. V tomto prpade s verejn D-H parametre a verejn D-H
ke vymenen a podpsan odosielateovm privtnym kom RSA alebo DSS.
Prjemca me verifikova podpis pomocou odpovedajceho verejnho ka z
certifiktu. Tto vmena ka je najbezpenejia, pretoe poskytuje doasn
(jednorzov) autentizovan tajn k.
Anonymn DH - pouva D-H algoritmus vmeny ka bez autentizcie
komunikujcich entt. To znamen, e kad entita posiela svoje D-H parametre bez
autentizcie. Tento spsob vmeny ka je zraniten na tok man-in-the-middle, pri
ktorej tonk realizuje anonymn vmenu ka s obidvomi entitami (sprostredkovva
komunikciu entt ).
Fortezza technika definovan v schme Fortezza.
Druh fza Autentizcia servera a vmena ka. Tto fzu zane server poslanm svojho
certifiktu, ak je potreba jeho autentizcie. Sprva certificate je vyadovan pre kad metdu
vmeny kov s vnimkou anonymnho D-H. Ako alia sprva me by poslan
sprva server_key_exchange, pokia sa to poaduje. Nie je to poadovan v prpade, ke server
287
poslal certifikt s pevnmi D-H parametrami alebo bude pouit vmena kov RSA.
Sprva server_key_exchange je potrebn v tchto prpadoch:
Anonymn D-H. Sprva obsahuje dva verejn D-H parametre (prvoslo a primitvne
kore tohto sla) a verejn D-H k servera.
Doasn D-H. Sprva obsahuje dva verejn D-H parametre (prvoslo a primitvny
kore tohto sla), verejn D-H k servera spolu s podpisom tchto troch parametrov.
Vmena ka RSA (server pouva RSA, ale m iba podpisovac k RSA). To
znamen, e klient neme jednoducho posla tajn k zaifrovan verejnm kom
servera. Namiesto toho mus server vytvori doasn kov pr (verejn a privtny
k) RSA a poui sprvu server_key_exchange na odoslanie verejnho ka. Sprva
obsahuje dva parametre doasnho verejnho ka RSA (exponent a modul) a podpis
tchto parametrov.
Fortezza.
Neanonymn server (server nepouva anonymn D-H) me klienta poiada o certifikt.

Sprva certificate_request obsahuje dva parametre, a to typ certifiktu a certifikan autority.
Typ certifikt udva algoritmus verejnho ka a jeho pouitie. Naprklad RSA (algoritmus)/iba
na podpis (pouitie), RSA/pre pevn D-H (v tomto prpade je podpis pouit iba na autentizciu),
RSA/doasn D-H. Druh parameter v sprve certificate_request je zoznam nzvov
akceptovatench certifikanch autort. Zveren sprva v druhej fze, ktor sa vdy vyaduje,
je sprva servera server_done. Po odoslan tejto sprvy bude server aka na klientovu odpove.
Tto sprva neobsahuje iadne parametre.
Tretia fza Autentizcia klienta a vmena ka. Po prijat sprvy server_done by klient
mal overi, i server predloil platn certifikt (ak sa poaduje) a skontrolova, i s
akceptovaten parametre sprvy server_hello. Ak je vetko akceptovaten, klient pole sp
serveru jednu alebo viacero sprv. Ak server poadoval certifikt, klient zane tto fzu zaslanm
sprvy certificate. Ak klient nem k dispozcii vhodn certifikt, pole serveru namiesto
certifiktu varovanie no_certificate.
alej nasleduje sprva client_key_exchange, ktor mus by poslan v tejto fze. Obsah sprvy
zvis od typu vmeny ka takto:
RSA. Klient vygeneruje 48 bajtov pre-master tajomstvo a zaifruje ho pomocou

verejnho ka zo serverovho certifiktu alebo doasnho ka RSA zo sprvy
server_key_exchange.
Doasn alebo anonymn D-H. S poslan klientove verejn parametre D-H.
Pevn D-H. Verejn parametre D-H klienta boli poslan v sprve certificate, take obsah
tejto sprva je przdny.
Fortezza. Pol sa klientove parametre Fortezza.
Nakoniec v tejto fze me klient posla sprvu certificate_verify na potvrdenie explicitnej

verifikcie klientovho certifiktu. Tto sprva je poslan iba ako nsledn po akomkovek
klientskom certifikte, ktor m funkciu podpisovania (t.j. vetky certifikty s vnimkou tch,
ktor obsahuj pevn D-H parametre). Tto sprva obsahuje podpis zreazench
predchdzajcich sprv. Ak privtny k klienta je pre algoritmus DSS, potom sa pouva
algoritmus SHA-1 na vypotanie heovacej hodnoty zreazench predchdzajcich sprv. Ak
privtny k klienta je pre algoritmus RSA, potom sa za heovaciu hodnotu zoberie zreazenie
heovacch hodnt vypotanch zo zreazench predchdzajcich sprv algoritmom MD5
a SHA-1. V kadom prpade je elom overi, e klient vlastn skromn k pre verejn k
z certifiktu klienta. Aj keby niekto zneuval certifikt klienta, nie je schopn zabezpei
podpis, pretoe nem skromn k klienta.
288
tvrt fza Ukonenie. Tto fza ukon vytvorenie bezpeenho spojenia. Klient pole
sprvu change_cipher_spec a skopruje pripraven ifrovaciu suitu (CipherSpec) do aktulnej
ifrovacej suity. Stoj za zmienku, e tto sprva nie je sasou protokolu SSL Handshake
Protocol, ale je poslan pomocou protokolu Change Cipher Spec Protocol. Po tejto sprve klient
bezprostredne pole sprvu finished poda novej ifrovacej suity. Tto sprva potvrdzuje, e
vmena ka a autentizan procesy boli spen. Ako odpove na tieto dve sprvy klienta
pole server vlastn sprvu change_cipher_spec, skopruje pripraven ifrovaciu suitu
(CipherSpec) do aktulnej ifrovacej suity, a pole sprvu finished. V tomto bode je dohodnutie
ifrovacej suity ukonen a klient a server mu zaa vmenu dajov na aplikanej vrstve.
Protokol TLS je tandardizan iniciatva IETF, ktorej cieom je vytvorenie verzii Internetovho
tandardu protokolu SSL. Sasn verzia TLS je definovan v Internetovom tandarde [RFC
5246], ktor je vemi podobn SSL v3. alej sa pouke na niektor ich rozdiely. Formt
sprvy protokolu SSL Record Protokol je v TLS rovnak. Jedin rozdiel je v hodnotch verzi,
pre aktulnu verziu TLS je hodnota vyej verzie 3 a hodnota niej verzie je tie 3. Pri vpote
autentizanho kdu sprvy MAC existuj medzi SSL v3 a TLS dva rozdiely, a to v
pouvanom algoritme a rozsahu dajov, z ktorch sa pota autentizan kd. TLS pouva
algoritmus HMAC definovan v [RFC 2104]. TLS podporuje vetky vstran kdy protokolu
Alert Protocol definovan vo SSLv3 s vnimkou varovania no_certificate. V TLS s definovan
alie vstran kdy najm typu fatlne. V ifrovacch suitch existuje niekoko malch
rozdielov medzi SSL v3 a TLS. Pri vmene ka TLS podporuje vetky vmeny ka
definovan v SSL v3 s vnimkou Fortezza. Pri symetrickch ifrovacch algoritmoch TLS
obsahuje vetky symetrick ifrovacie algoritmy definovan v SSLv3 s vnimkou Fortezza.
V klientskych typoch certifiktu TLS definuje len tieto typy certifiktu, o ktor je mono
poiada v sprve certificate_request: rsa_sign, dss_sign, rsa_fixed_dh a dss_fixed_dh. TLS
nepodporuje systm Fortezza. V sprvach certificate_verify a finished TLS zahruje do
vpotu heovacej hodnoty men poet poloiek.
289
10.4.4 Pouit zdroje
[HEN06]
[RFC 1661]
[RFC 2104]
[RFC 2246]
[RFC 2341]
[RFC 2401]
[RFC 2402]
[RFC 2403]
[RFC 2404]
[RFC 2406]
[RFC 2408]
[RFC 2409]
[RFC 2412]
[RFC 2516]
[RFC 2637]
[RFC 3193]
[RFC 3931]
[RFC 3947]
[RFC 4346]
[RFC 5246]
[RFC 5996]
[RFC 6101]
HENMI, A., LUCAS, M., SINGH, A., CANTRELL, C.: Firewall Policies
and VPN Configurations. Syngress Publishing, Inc., 2006. ISBN: 159749-088-1
SIMPSON, W.: The Point-to-Point Protocol (PPP). July 1994
KRAWCZYK, H., BELLARE, M., CANETTI, R.: HMAC: KeyedHashing for Message Authentication. February 1997
DIERKS, T., ALLEN, C.: The TLS Protocol Version 1.0. January 1999.
VALENCIA, A., KOLAR, T.: Cisco Layer Two Forwarding (Protocol)
"L2F". May 1998
KENT, S., ATKINSON, R.: Security Architecture for the Internet
Protocol. November 1998
KENT, S., ATKINSON, R.: IP Authentication Header. November 1998
MADSON, C., GLENN, R.: The Use of HMAC-MD5-96 within ESP and
AH. November 1998.
MADSON, C., GLENN, R.: The Use of HMAC-SHA-1-96 within ESP
and AH. November 1998.
KENT, S., ATKINSON, R.: IP Encapsulating Security Payload (ESP).
November 1998
MAUGHAN, D., SCHERTLER, M., SCHNEIDER, M., TURNER, J.:
Internet Security Association and Key Management Protocol (ISAKMP).
November 1998.
HARKINS, D., CARREL, D.: The Internet Key Exchange (IKE).
November 1998.
ORMAN, H.: The OAKLEY Key Determination Protocol. November
1998.
MAMAKOS, L., LIDL, K., EVARTS, J., CARREL, D., SIMONE, D.,
WHEELER, R.: A Method for Transmitting PPP Over Ethernet (PPPoE).
February 1999
HAMZECH, K., PALL, G., VERTHEIN, W., TAARUD, J., LITTLE, W.,
ZORN, G.: Point-to-Point Tunneling Protocol (PPTP). July 1999
FREED, N. , BORENSTEIN, N.: Securing L2TP using IPsec. November
2001
PATEL, B., ABOBA, B., DIXON, W., ZORN, G., BOOTH, S.: Securing
L2TP using IPsec. November 2001
KIVINEN, T., SWANDER, B., HUTTUNEN, A., VOLPE, V.:
Negotiation of NAT-Traversal in the IKE. January 2005.
DIERKS, T.: The Transport Layer Security (TLS) Protocol Version 1.1.
April 2006.
DIERKS, T., RESCORLA, E.: The Transport Layer Security (TLS)
Protocol Version 1.2. August 2008.
KAUFMAN, C., HOFFMAN, P., NIR, Y., ERONEN, P.: Internet Key
Exchange Protocol Version 2 (IKEv2). September 2010.
FREIER, A., KARLON, P., KOCHER, P.: The Secure Sockets Layer
(SSL) Protocol Version 3.0. August 2011.
290
10.5 Systmy na detekciu/prevenciu proti prienikom (IDS/IPS)

Pri psan tejto asti autor erpal najm z publikcie [SCA07].
Detekcia prienikov je proces monitorovania udalost v potaovom systme alebo v sieti a ich
analyzovania na prznaky monch incidentov, ktor s poruenm alebo bezprostrednou hrozbou
poruenia politk potaovej bezpenosti, politk akceptovatenho pouitia alebo tandardnch
bezpenostnch praktk.
Systm detekcie prienikov (IDS Intrusion Detection Systm) je softvr, ktor automatizuje
proces detekcie prienikov. Novou verziou IDS je systm prevencie prienikov (IPS Intrusion
Prevention System), o je softvr, ktor m vetky schopnosti systmu detekcie prienikov a je
schopn poksi sa zastavi mon incidenty. Shrnne tieto technolgie nazvame IDPS
(Intrusion Detection/Prevention System)
Technolgie IDPS s primrne uren na identifikciu monch incidentov. IDPS me
detegova spen kompromitciu systmu tonkom, ktor vyuil slabinu systmu. IDPS
potom me oznmi incident bezpenostnmu manarovi, ktor okamite zane aktivity
reakcie na incident, aby sa minimalizovala koda spsoben incidentom. IDPS alej me
vytvori informan zznam, ktor je vyuit na rieenie incidentu. Vea IDPS me by
konfigurovanch tak, e rozpozn poruenie bezpenostnej politiky. Naprklad niektor IDPS
mu by konfigurovan nastaveniami podobnmi ako bezpenostn brna, ktor IDPS umonia
identifikova sieov premvku poruujcu politiku bezpenosti organizcie alebo politiku
akceptovatenho pouitia. Niektor IDPS mu monitorova prenos sborov a identifikova
mon podozriv prenosy, naprklad koprovanie rozsiahlej databzy na pouvatesk laptop.
Vea IDPS mu identifikova prieskumn aktivity tonka, ktor mu indikova
bezprostredn tok. Prkladom takchto prieskumnch aktivt je skenovanie portov na webovom
serveri. IDPS me blokova takto prieskum a upovedomi bezpenostnho administrtora.
Technolgie IPS technolgie sa lia od technolgi IDS jednou zsadnou vlastnosou,
technolgie IPS s schopn reagova na detegovan hrozbu tak, e sa pokaj zabrni, aby
bola hrozba spen. IPS pouvaj viacer techniky reakcie, ktor je mon rozdeli do tchto
skupn:
IPS zastavuje samotn tok. Naprklad ukon sieov spojenie alebo relciu
pouvatea, ktor je pouit na tok, alebo blokuje prstup na cie (alebo mon alie
pravdepodobn ciele) z toiaceho tu pouvatea, adresy IP alebo inch atribtov
tonka, alebo blokuje vetky prstupy na cielen uzol, slubu, aplikciu alebo al
zdroj.
IPS men bezpenostn prostredie. IPS na preruenie toku by mohol zmeni
konfigurciu inch bezpenostnch opatren. Benm prkladom je rekonfigurcia
sieovho zariadenia (naprklad bezpenostn brna, smerova, prepna ) na blokovanie
prstupu od tonka alebo na cie a zmenenie hostovej bezpenostnej brny na cie, aby
bezpenostn brna blokovala prichdzajci tok. Niektor IPS mu dokonca spsobi
aplikciu zplat na hosta v prpade, e IPS deteguje, e host m slabiny.
IPS men tonkov obsah. Niektor IPS technolgie mu odstrni alebo zmeni
kodliv as toku a tak tok spravia nekodn. Klasickm prkladom je IPS, ktor
odstrni prlohu s infikovanm sborom v sprve elektronickej poty a a potom umon,
aby oisten email dostal prjemca. alm prkladom je normalizcia
prichdzajcich iadost. To znamen, e proxy prebal obsah iadosti znienm
informcii hlaviky.
Technolgie IDPS nie s schopn zabezpei pln a presn detekciu prieniku. Me nasta
prpad, ke IDPS nesprvne identifikuje nekodn aktivity ako kodliv. Tento prpad
oznaujeme ako false positive. alm prpadom je, ke IDPS zlyh pri identifikcii kodlivch
291
aktivt. Tento prpad oznaujeme ako false negative. Nie je mon eliminova vetky prpady
false positive a false negative. V mnohch prpadoch pri zmene konfigurcie IDPS na potlaenie
false negative sa zvyuje vskyt false positive. Menenie konfigurcie IDPS s cieom zlepenia
presnosti detekcie sa nazva ladenie (tuning) technolgie IDPS.
10.5.1 tandardn detekn mechanizmy
Technolgie IDPS pouvaj vea mechanizmov na detegovanie incidentov. Zkladn triedy
deteknch mechanizmov s zaloen na prznakoch (signature based), anomlich (anomaly
based) a analze stavovch protokolov (stateful protocol analysis).
Detekn mechanizmus zaloen na prznakoch vychdza zo znalosti prznaku (vzorky), ktor
odpoved znmej hrozbe. Spova v podstate na procese porovnvania prznakov oproti
pozorovanm udalostiam s cieom identifikova mon incidenty. Prklady prznakov je
naprklad pokus o spustenie telnetu s loginom root, o je poruenie bezpenostnej politiky
spolonosti alebo sprva elektronickej poty s predmetom New games a s prlohou
newgames.exe, o s charakteristiky znmej formy kodlivho kdu. Tento mechanizmus je
vemi inn pri detekcii znmych hrozieb, ale neefektvny pri detekcii doteraz neznmych
hrozieb. Je to najjednoduchia metda, pretoe iba porovnva sasn jednotky aktivity (paket
alebo poloku v logu) so zoznamom prznakov pouitm opercie porovnania reazcov.
Detekn mechanizmus zaloen na anomlich je proces porovnania definovanej normlnej
aktivity oproti pozorovanm udalostiam s cieom identifikova vznamn odchlky. IDPS
vyuvajce tento mechanizmus detekcie maj uloen profily, ktor reprezentuj normlne
sprvanie takch objektov ako je pouvate, uzly, sieov spojenia alebo aplikcie. Profily s
vytvoren monitorovanm charakteristk typickej aktivity za ist as. IDPS potom pouva
tatistick metdy na porovnanie sasnch aktivt oproti prahom svisiacich s profilom.
Naprklad detekcia zvenho potu emailovch sprv oproti oakvanmu potu sprv
zaznamenanom v profile. Profily mu by vytvoren pre mnoho atribtov sprvania sa ako s
naprklad poty navtvench webovch strnok pouvateom, poet nespench prihlsen sa
na uzol, rove vyuitia procesora uzla v danom asovom intervale. Tento mechanizmus me
by vemi inn pri detekcii predtm neznmych hrozieb. Naprklad pota bol infikovan
neznmym kodlivm kdom, ktor spotrebovva potaov zdroje, posiela vek mnostvo
emailovch sprv, inicializuje vek mnostvo sieovch spojen a vykonva in aktivity, ktor
s vznamne odlin od zavedenho profilu pre tento pota. Inicilny profil je vytvoren v
trningovom intervale v trvan typicky dn alebo tdov. Nemyseln zahrnutie kodlivch
aktivt ako sasti profilu je spolonm problmom deteknho mechanizmu anomli
(administrtori rune modifikuj vytvoren profil tak, e z neho vyhadzuj znme kodliv
aktivity). Pri snahe vytvori presn profily, astokrt nastva situcia, kedy IDPS vytvra
vek mnostvo false positive alertov. Je to z toho dvodu, e zriedka vykonvan nekodliv
aktivity nie s zahrnut do profilu, a teda generuj alerty.
Detekn mechanizmus zaloen na analze stavovch protokolov je proces porovnania
dopredu urench profilov veobecne akceptovanch definci nekodnej aktivity protokolu pre
kad stav protokolu oproti sledovanm udalostiam s cieom identifikova odchlky (potencilne
kodliv stavy). Defincia protokolu je prevzat zo tandardizanch dokumentov RFC alebo ich
najrozrenejch implementci. Slovo stavov v analze stavovho protokolu znamen, e
IDPS je schopn porozumie a sledova stav sieovho, transportnho alebo aplikanho
protokolu, ktor obsahuj koncept stavu. Tento mechanizmus me identifikova neoakvan
postupnosti prkazov ako je opakovan zadanie toho istho prkazu alebo zadanie prkazu bez
predchdzajceho zadanie prkazu, na ktorom je zvisl. Primrnou nevhodou tohto
mechanizmu je jeho nronos na vpotov zdroje, pretoe pre kad protokol mus vytvori
nov intanciu stavovho stroja a teda pri viacerch sasne monitorovanch spojeniach mus
pre kad spojenie (a kad pouit stavov protokol) vytvori nov intanciu stavovho stroja.
Na Obrzku . 10.37 je prklad stavovho stroja pre transportn protokol TCP.
292
Obrzok . 10.37: Stavov stroj pre transportn protokol TCP

10.5.2 Technolgie IDPS
Typick komponenty rieen technolgi IDPS s senzor alebo agent, server manamentu,
databzov server a konzola manamentu.
Senzor alebo agent je prostriedok, ktor monitoruje alebo analyzuje aktivity. Oznaenie senzor
sa typicky pouva pre IDPS, ktor monitoruj siete. Oznaenie agent sa typicky pouva pre
hostov IDPS.
Server manamentu je centralizovan zariadenie, ktor prijma informcie od senzorov a
agentov a spravuje ich. Niektor servery manamentu vykonvaj analzu informci o udalosti,
ktor poskytli senzory alebo agenti, a s schopn identifikova udalosti, ktor individulne
senzory a agenti schopn nie s. Provanie informci o udalosti z viacerch senzorov alebo
agentov (naprklad udalost spustench z tej istej adresy IP) sa nazva korelcia. Niektor mal
nasadenia technolgi IDPS nepouvaj server manamentu, ale vina nasaden IDPS servery
manamentu pouva.
Databzov server je loisko na uloenie informci, ktor zaznamenali senzory, agenti a/alebo
server manamentu. Vea IDPS poskytuje podporu pre databzov servery.
Konzola manamentu je program, ktor zabezpeuje rozhranie medzi IDPS a jeho
administrtormi a pouvatemi. Typicky je tento program intalovan na tandardnom desktope
alebo laptope. Niektor konzoly s pouvan iba na administrciu IDPS ako je konfigurcia
senzorov alebo agentov, aktualizcia programovho vybavenia. In konzoly s pouvan
vlune iba na monitorovanie a analzu.
Vyie uveden komponenty IDPS mu by prepojen medzi sebou prostrednctvom
tandardnej sieti organizcie (in-band). V takomto prpade je vhodn vytvori oddelenie siete
manamentu od produknej sieti aspo na rovni virtulnej LAN (VLAN). Pouitie VLAN
293
zabezpeuje ochranu IDPS komunikcie (ale nie na takej rovni ako fyzicky oddelenej siete
manamentu), ale ochrana me zlyha pri chybnej konfigurcii VLAN alebo pri toku DoS na
produkn sie. Druhm rieenm je prepoji komponenty IDPS prostrednctvom oddelenej sieti
(out of band), ktor je vlune uren pre manament bezpenostnho softvru. Tejto oddelenej
sieti sa tie hovor sie manamentu. V takomto prpade mus ma senzor alebo agent alie
sieov rozhranie (rozhranie manamentu), ktorm je pripojen do siete manamentu. Toto
rieenie sieti efektvne izoluje sie manamentu od produknej sieti a skrva existenciu a identitu
IDPS pred tonkmi. alej chrni IDPS pred tokmi a zabezpeuje, e IDPS m k dispozcii
dostaton sieov priepustnos aj v prpade toku DoS na produkn sie. Nevhodou rieenia
s dodaton nklady na vytvorenie siete manamentu a nepohodlie pre administrtorov IDPS a
pouvateov IDPS, pretoe musia pre svoje innosti s IDPS pouva oddelen potae.
Detekn schopnosti technolgi IDPS s typicky rozsiahle a irok. Vina produktov pouva
kombinciu deteknch technk, ktor vo veobecnosti zabezpeuj presnejiu detekciu a viu
flexibilitu pri laden a prispsobovan (customizcii). Prklady ladiacich a prispsobovacch
monost IDPS technolgi:
Prahy (Thresholds) s hodnoty, ktor nastavuj limity medzi normlnym a

abnormlnym sprvanm. Prahy s najviac pouvan v deteknch mechanizmoch
zaloench na anomlich a analze stavovch protokolov.
ierne a biele zoznamy (Blacklists and Whitelists). ierny zoznam je zoznam
diskrtnych entt ako s hosty, sla TCP alebo UDP portov, typy a kdy ICMP,
aplikci, mien pouvateov, URL, mien sborov alebo sborovch rozren, ktor boli
v minulosti identifikovan ako sas kodlivch aktivt. Biely zoznam je zoznam
diskrtnych entt, ktor s znme ako nekodn. Zvyajne sa pouvaj na bze
granularity ako po protokoloch, na redukovanie alebo ignorovanie false positive
zahrujce znme nekodn aktivity z dveryhodnch hostov. ierne a biele zoznamy s
najastejie pouvan pri deteknch mechanizmoch na bze prznakov a analzy
stavovho protokolu.
10.5.3 Sieov IDPS

Senzory sieovch IDPS s dostupn v dvoch prevedeniach:
Zariadenie. V tomto preveden senzor pozostva zo pecializovanho hardvru a

softvru. Hardvr je optimalizovan na pouitie senzora vrtane pecializovanej karty
NIC a jej ovldaa na efektvne odchytvanie paketov a pecializovanch procesorov
alebo alch hardvrovch komponentov podporujcich analzu. as alebo cel
softvr me by z dvodu zvenia efektvnosti umiestnen vo firmvri. Tieto
zariadenia asto obsahuj prispsoben, utesnen operan systm, ku ktormu sa
nepredpoklad prstup administrtorov. Prklady: rad CISCO IDS 4200, IBM Real
Secure Network
Iba softvr. Niektor predajcovia predvaj senzorov softvr bez zariadenia.
Administrtori intaluj tento softvr na potae, ktor spluj urit pecifikcie.
Senzorov softvr me obsahova prispsoben (customized) operan systm alebo
senzorov softvr me by intalovan tandardnom operanom systme ako in
aplikcia. Prklady: Snort, Bro
Senzory mu by nasaden v dvoch reimoch:
294
Prechodov senzor (Inline) vetka monitorovan premvka prechdza senzorom

(podobne ako vetka premvka prechdza bezpenostnou brnou). M dve sieov
rozhrania na monitorovanie premvky siete (cez tieto rozhrania prechdza sieov
premvka) a jedno rozhranie manamentu na pripojenie do siete manamentu.
Pasvny senzor monitoruje kpiu skutonej sieovej premvky. iadna premvka

neprechdza senzorom.
V skutonosti s niektor prechodov senzory hybridy bezpenostn brna / IDPS zariadenie.

Primrnym dvodom pre nasadenie prechodovch senzorov IDPS je skutonos, aby boli
schopn zastavi tok blokovanm sieovej premvky. Prechodov senzory s typicky
umiestnen na tie miesta v sieti, kde s umiestovan bezpenostn brny a in sieov
bezpenostn zariadenia a to na hranici medzi sieami, na pripojen do externch siet a
hranicami medzi rozdielnymi vntornmi sieami, ktor by mali by oddelen. Prechodov
senzory, ktor nie s hybridy bezpenostn brna / IDPS zariadenie s asto umiestovan na
bezpenejiu stranu siete (z tej strany hranice, kde je sie bezpenejia), aby spracovvali men
objem premvky. Senzory mu by tie umiestnen na menej bezpenej strane sieti, aby
zabezpeovali ochranu redukovanm zae oddeovacieho zariadenia ako je bezpenostn brna.
Na Obrzku . 10.38 je prklad takejto architektry.
Pasvne senzory s typicky nasadzovan tak, aby monitorovali kov sieov miesta ako s
hranice medzi sieami, kov sieov segmenty ako s aktivity v demilitarizovanej zne
(DMZ). Pasvne senzory mu monitorova premvku prostrednctvom rznych metd, ako
naprklad:
Pokrvajci port (spanning port) - je port prepnaa, ktor je schopn vidie vetku
sieov premvku prechdzajcu cez prepna. Pripojenm senzora na pokrvajci
port me senzor monitorova premvku na / z vea uzlov. Tto metda monitorovania
je relatvne ahk a lacn.
Sieov prpojka (network tap) je priame prepojenie medzi senzorom a samotnm
fyzickm mdiom ako je naprklad optick vlkno. Prpojka dodva senzoru kpiu celej
sieovej premvky, ktor sa prena cez mdium.
Vyvaova zae IDS (load balancer IDS) je zariadenie, ktor dva dokopy a
smeruje premvku siete do monitorovacch systmov vrtane IDPS senzorov.
Vyvaova dostane kpiu sieovej premvky z jednho alebo viacerch pokrvajcich
portov alebo sieovch prpojok a dva dokopy premvku z rznych siet (naprklad
znovu sklad relciu, ktor bola rozdelen medzi dve siete).
Prklad architektry IDS s pasvnym senzorom je na Obrzku . 10.39.
Obrzok . 10.38: Prklad architektry IDPS s prechodvm senzorom

295
Obrzok . 10.39: Prklad architektry IDPS s pasvnym senzorom

Sieov IDPS poskytuj irok monosti bezpenostnch funkci, ktor mu by truktrovan
do tyroch kategri: zhromadenie informci, zaznamenanie, detekcia a prevencia.
Funkcia zhromadenia informci. Niektor sieov IDPS ponkaj obmedzen schopnosti
zhromaovania informci, o znamen, e zbieraj informcie o uzloch a sieovch aktivitch
zahrujcich tieto uzly. Prklady monost zhromaovania informci s: identifikcia uzla
(vytvorenie zoznamu uzlov pripojench do siete organizcie poda adries IP alebo adries MAC),
identifikcia operanch systmov (identifikcia operanch systmov a ich verzi, ktor sa
pouvaj v organizcii), identifikcia aplikci (identifikcia pouvanej verzie aplikcie tak, e
sleduje, ktor porty s pouvan a monitoruje urit charakteristiky komunikcie aplikcie).
Funkcia zaznamenania. Sieov IDPS typicky vykonvaj rozsiahle zaznamenanie dajov
majcich vzah k detegovanej udalosti. Tieto daje mu by pouit na potvrdenie platnosti
alertu, na vyetrenie incidentov a na korelciu udalost medzi IDPS a ostatnmi logovacmi
zdrojmi. Vina sieovch IDPS je schopn vykona zachytenie paketov. tandardne sa to
vykonva vtedy, ke sa generuje alert. Zachytvaj sa alebo nsledn aktivity v spojen po alerte
alebo sa zanamen cel spojenia (ak IDPS doasne uchovval predchdzajce pakety). Zznam
sieovho IDPS me vo veobecnosti obsahova tieto dajov polia (poloky): asov
peiatka (dtum a as), ID spojenia alebo relcie (typicky postupn alebo jedinen slo
priraden kadmu TCP spojeniu alebo podobnm skupinm paketov pre protokoly bez
spojenia), typ udalosti alebo alertu, rating (naprklad priorita, dleitos, dopad, dvernos),
protokol sieovej, transportnej a aplikanej vrstvy, zdrojov a cieov adresa IP, zdrojov a
cieov port TCP alebo UDP, alebo typy ICMP a kdy, poet slabk prenesench tmto
spojenm, dekdovan daje uitonho nkladu (payload), ako s iadosti a odpovede aplikcie,
informcie viace sa na stav (naprklad autentizovan meno pouvatea), vykonan preventvne
akcie (ak treba).
Funkcia detekcie. Sieov IDPS typicky ponkaj irok a veobecn detekn schopnosti.
Vina produktov vyuva kombinciu mechanizmov detekcie pomocou prznakov, anomli a
analzy stavovch protokolov (in-depth analysis bench protokolov). Detekn mechanizmy s
zvyajne pevne previazan, naprklad stroj na detekciu mechanizmu analzy stavovch
296
protokolov me rozobra aktivity do iadost a odpoved, priom kad z nich je preverovan na

anomlie a porovnan s prznakom znmych kodlivch aktivt. Detekn schopnosti mono
analyzova z tchto pohadov: typy detegovanch udalost, presnos detekcie, ladenie a
prispsobenie, obmedzenia technolgie. Najbenejie typy detegovanch udalost senzormi
sieovch IDPS s: prieskum a toky na aplikanej vrstve (naprklad odchytenie bannera,
preteenie vyrovnvacej pamti, toky na formtov reazce, hdanie hesla, prenanie
kodlivho kdu), prieskum a toky na transportnej vrstve (Naprklad skenovanie portov,
nezvyajn fragmentcia paketov, zplava SYN. Najfrekventovanejie analyzovan protokoly
transportnej vrstvy s TCP a UDP.), prieskum a toky na sieovej vrstve (naprklad falon spoofed adresa IP, nedovolen hodnota hlaviky IP), neoakvan aplikan sluby (naprklad
tunelovan protokoly, zadn vrtka, uzly vykonvajce neautorizovan aplikan sluby)
a poruenuie politiky (naprklad pouitie nevhodnch webovch sdiel, pouitie zakzanch
aplikanch protokolov).
Funkcia prevencie (prechodov senzory a niektor pasvne sieovch IDPS): ukonenie
aktulneho TCP spojenia (pasvny senzor IDPS me sksi ukoni existujcu relciu TCP
tak, e pole pakety TCP reset obidvom komunikujcim koncom, tto technika nie je v sasnosti
iroko pouvan, pretoe in prevenn schopnosti s efektvnejie), vykonanie prechodovho
firewallingu (vina senzorov IDPS ponka funkcie bezpenostnej brny, ktor mu by
pouit na zastavenie alebo odmietnutie podozrivej sieovej aktivity), obmedzenie na pouitie
prenosovho psma (v prpade, e urit protokol sa pouva nevhodne, ako naprklad na tok
DoS, distribciu kodlivho kdu alebo peer-to-peer zdieanie sborov, niektor prechodov
senzory IDPS mu obmedzi percento sieovho prenosovho psma), a zmena kodlivho
obsahu (niektor prechodov senzory IDPS mu sanova as paketu, o znamen, e je
nahraden kodliv obsah za nekodn obsah a sanovan paket je odoslan do svojho ciea).
Funkcie prevencie (aj pasvne aj prechodov senzory sieovch IDPS): rekonfigurcia inch
sieovch bezpenostnch zariaden (vea senzorov IDPS me da pokyn sieovm
bezpenostnm zariadeniam ako s bezpenostn brny, smerovae a prepnae na ich
rekonfigurciu s cieom blokovania uritho typu aktivity alebo ich smerovania inam),
vykonvanie programov tretch strn alebo skriptov (niektor senzory IDPS s schopn, v
prpade detekcie uritej kodlivej aktivity, vykona administrtorom uren skript alebo
program)
Vina senzorov IDPS dovouje administrtorom pecifikova prevencie schopn
konfigurcie pre kad typ alertu. Toto zvyajne zahruje povolenie alebo zakzanie
prevencie, rovnako ako pecifikovanie ktor prevenn monosti by mali by pouit. Niektor
senzory IDPS maj reim uenia alebo simulcie, ktor potla vetky preventvne akcie a
namiesto toho indikuje kedy by bola preventvna akcia vykonan. Tento reim umouje
administrtorom monitorova a jemne ladi preventvne schopnosti konfigurcie predtm ne sa
povolia, o redukuje riziko nhleho blokovania nekodnej aktivity.
10.5.4 Bezdrtov IDPS
Bezdrtov IDPS monitoruj bezdrtov sieov premvku a analyzuj jej bezdrtov sieov
protokoly s cieom identifikova podozriv aktivity zahrujce samotn protokoly.
WLAN (bezdrtov LAN) poda tandardu IEEE 802.11 maj dva zkladn architektonick
komponenty a to stanicu a prstupov bod. Stanica (STA) je bezdrtov koncov zariadenie.
Typickm prkladom STA je notebook, laptop, smartfn, tablet a alie zariadenia spotrebnej
elektroniky s vybavenm poda IEEE 802.11. Prstupov bod (AP Access Point) logicky
pripja STA k distribunmu systmu, ktorm je typicky pevn (drtovan) infratruktra
organizcie. Distribun systm je prostriedok, prostrednctvom ktorho mu STA
komunikova s pevnou LAN spolonosti a externou sieou ako je Internet. Prklad architektry
bezdrtovej LAN je na Obrzku . 10.40.
Niektor WLAN pouvaj tie bezdrtov prepnae (wireless switch). Je to zariadenie, ktor
funguje ako prostrednk medzi STA a AP (a distribunm systmom).
297
tandard IEEE 802.11 tie definuje tieto dve WLAN architektry a to ad hoc reim
a infratruktrny reim. Ad hoc reim nevyuva AP. Ad hoc reim, tie znmy ako peer-to-peer
reim, zahruje dve alebo viac STA komunikujcich priamo jeden s druhm. Znmym prpadom
tohto reimu s siete MANET (Mobile Ad-hoc NETwork). V infratruktrnom reime
prstupov bod logicky pripja STA k distribunmu systmu, ktor je typicky pevn (drtovan)
sie. Takmer vetky WLAN sa vyuvaj v infratruktrnom reime.
Kad modul AP v sieti WLAN m priraden meno, ktor sa nazva identifiktor mnoiny
sluieb SSID (Service Set IDentifier). SSID umouje STA odli jednu WLAN od druhej
WLAN. AP vysiela SSID vo formte obyajnho textu, take kad prijmajce bezdrtov
zariadenie sa me ahko dozvedie SSID kadej WLAN, ktor je v dosahu zariadenia.
Obrzok . 10.40: Prklad architektry bezdrtovej LAN

Bezdrtov aj pevn (drtovan) sie elia rovnakm veobecnm typom hrozieb, relatvne
riziko niektorch hrozieb sa vak vrazne li. Naprklad bezdrtov toky zvyajne vyaduj,
aby tonk alebo tonkove zariadenie bolo v tesnej fyzickej blzkosti k bezdrtovej sieti, na
druhej strane, mnoho tokov na pevnej siete mono vykonva na diaku z ubovonho miesta.
Navye, mnoho WLAN je nastavench tak, e nevyaduj autentizciu alebo vyaduj len slab
formy autentizcie, o znane uahuje tonkom vykonva niekoko typov tokov, naprklad
tok Man In The Middle. Vina hrozieb proti WLAN zahruj tonka s prstupom k
rdiovmu spojeniu medzi STA a AP (alebo medzi dvoma STA v reime ad hoc). Mnoho tokov
sa spolieha na monos tonka zachyti sieov komunikcie alebo vloi do komunikcie
alie sprvy. To dokumentuje najvznamnej rozdiel medzi ochranou bezdrtovej a pevnej
siete LAN: relatvna jednoduchos prstupu a zmena sieovej komunikcie.
Typick komponenty bezdrtovch IDPS s rovnak ako v sieovch IDPS: konzola,
databzov servery (volitene), servery manamentu a senzory. Vetky komponenty okrem
senzorov maj v podstate rovnak funkcie pre oba typy IDPS. Bezdrtov senzory maj rovnak
zkladn lohu ako sieov senzory IDPS, ale funguj vemi odline z dvodu zloitosti
monitorovania bezdrtovej komunikcie. Na rozdiel od sieovch IDPS, ktor mu vidie
vetky pakety siete, bezdrtov IDPS pracuj na princpe vzorkovania premvky. Existuj dve
frekvenn psma na monitorovanie (2,4 GHz a 5 GHz) a kad psmo je rozdelen do kanlov.
Senzor neme monitorova vetku premvku v psme naraz, v danom ase me
monitorova iba jeden kanl. Aby sa potlail tento handicap, senzory asto prepnaj medzi
monitorovanmi kanlmi. Tomuto mechanizmu sa hovor skenovanie kanlov (senzor
monitoruje kad kanl niekokokrt za sekundu).
Bezdrtov senzory s dostupn vo viacerch formch:
298
Venovan. Venovan senzor je zariadenie, ktor vykonva funkcie bezdrtovho IDPS,

ale neprena sieov premvku od zdroja k cieu. Venovan senzory s asto plne
pasvne a iba odchytvaj sieov premvku, ktor maj v danom kanle v dosahu.
Niektor pecializovan senzory vykonvaj analzu premvky samy, zatia o
ostatn senzory iba preposielaj sieov premvku na analzu na server
manamentu. Senzor je typicky pripojen k pevnej sieti. Venovan senzory s zvyajne
navrhnut ako pevn senzor (Je nasaden na uritom mieste a je typicky zvisl od
infratruktry organizcie, napr. energie, pevn sie. Pevn senzory s obvykle
zariadenia.) alebo ako mobiln senzor (Je uren na pouitie v pohybe. Naprklad
bezpenostn sprvca me pouva mobiln senzor pri prechdzkach po budove
spolonosti a hada kodliv AP.)
V spojen s AP. Niekok vrobcovia pridali funkcie IDPS do AP. Takto AP zvyajne
zabezpeuje menie monosti detekcie ako venovan senzor, pretoe AP sa mus rozdeli
s existujcim vpotovm vkonom na zabezpeenie prstupu do siete a monitorovanie
viacerch kanlov alebo psiem na kodliv aktivity.
V spojen s bezdrtovm prepnaom. Niektor bezdrtov prepnae tie ponkaj
niektor funkcie bezdrtovch IDPS ako sekundrne funkcie. Bezdrtov prepnae
obvykle neposkytuj tak detekn schopnosti ako v spojen s AP alebo venovan
senzory.
Komponenty bezdrtovch IDPS s typicky vzjomne prepojen prostrednctvom pevnej siete

(vi Obrzok . 10.41). Podobne ako pri sieovch IDPS, me by na komunikciu medzi
komponentmi IDPS vyuit tandardn (produkn) sie spolonosti alebo oddelen sie
manamentu. Niektor bezdrtov senzory IDPS (mobiln senzory) s pouvan samostatne a
nepotrebuj pevn sieov konektivitu.
Obrzok . 10.41: Prklad architektry bezdrtovch IDPS

Bezdrtov IDPS poskytuj niekoko typov bezpenostnch funkci. Pretoe bezdrtov IDPS je
relatvne nov forma IDPS, ich monosti sa medzi vrobcami v sasnej dobe vemi lia.
Funkcia zbierania informci. Vina bezdrtovch IDPS me zbiera informcie o
bezdrtovch zariadeniach. Prklady monost zbierania tchto informci s: identifikcia
zariaden WLAN (vina senzorov IDPS doke vytvori a udriava - na zklade SSID
a adries MAC) zoznam spozorovanch zariaden WLAN, vrtane AP, bezdrtovch klientov
299
a ad hoc (peer-to-peer) klientov), identifikcia WLAN (vina senzorov IDPS sleduje

pozorovan siete WLAN identifikujc ich poda SSID).
Funkcia zaznamenania. Bezdrtov IDPS zvyajne vykonvaj rozsiahle zaznamenanie dajov
tkajcich sa detegovanch udalost. Tieto daje mono poui na potvrdenie platnosti alertov,
vyetrovanie incidentov a na korelciu udalost medzi IDPS a alch zznamovch
zdrojov. dajov polia, zvyajne zaznamenan pomocou bezdrtovch IDPS, obsahuj asov
peiatka (zvyajne dtum a as), typ udalosti alebo alertu, priradenie priority a zvanosti,
zdrojov adresa MAC (vrobca je asto identifikovan poda adresy), slo kanla, ID senzoru,
ktor spozoroval udalos, vykonan preventvne akcie (ak nejak boli).
Funkcia detekcie. Bezdrtov IDPS doke detegova toky, chybn konfigurcie a
poruovania politiky na rovni protokolu WLAN, a to predovetkm skmanie
komunikanho protokolu IEEE 802.11. Bezdrtov IDPS neskmaj komunikciu na vych
rovniach (napr. adresy IP, aplikan nklad). Niektor produkty vykonvaj iba jednoduch
detekciu prznakov, zatia o in pouvaj kombinciu mechanizmu prznakov, mechanizmu
anomli a mechanizmu analzy stavovch protokolov. Typy udalost, ktor s najastejie
detegovan bezdrtovmi senzormi IDPS, pokrvaj: neoprvnen WLAN a zariadenia
WLAN (prostrednctvom svojich monost zbierania informci, vina bezdrtovch senzorov
IDPS s schopn detegova kodliv AP, neoprvnen STA a neoprvnen WLAN), slabo
zabezpeen zariadenia WLAN (Vina bezdrtovch senzorov IDPS je schopn identifikova
AP a STA, ktor nepouvaj nleit bezpenostn opatrenia. To zaha detegovanie chybnch
konfigurci a pouitie slabch protokolov WLAN a implementci protokolu.), nezvyajn
vzory pouitia (niektor senzory pouvaj mechanizmus anomli na detekciu nezvyajnch
vzorov pouitia WLAN), pouvanie bezdrtovch sieovch skenerov (mu detegova iba
pouvanie aktvnych skenerov), podmienky a toky Denial of Service (DoS) (naprklad
logick toky ako s zplavy (flooding), ktor predstavuje sasn posielanie vekho mnostva
sprv na AP a fyzick toky ako je ruenie (jamming), ktor predstavuje vyarovanie
elektromagnetickej energie na frekvencich siete WLAN tak, aby sa frekvencia stala pre WLAN
nepouiten) a impersonifikcia a toky Man In The Middle (Niektor bezdrtov senzory
IDPS mu detegova prpad, ke zariadenie sa sna sfalova identitu inho zariadenia. Tento
prpad me by zisten tak, e senzor identifikuje rozdiely v charakteristikch aktivity ako s
naprklad urit hodnoty v rmcoch.)
Funkcia prevencie. Senzory bezdrtovch IDPS ponkaj dva typy monost prevencie pred
prienikmi a to bezdrtov a drtov.
V prpade bezdrtovej prevencie niektor senzory s schopn vzduchom ukoni spojenia medzi
kodlivm alebo chybne konfigurovanm STA a autorizovanm AP alebo medzi oprvnenm
STA a kodlivm alebo chybne konfigurovanm AP. Senzory tto aktivitu zabezpeia zaslanm
sprvy koncovm bodom komunikcie, aby de-asociovali aktulnu relciu. Senzor potom
odmieta, aby bolo povolen nadviazanie novho spojenia.
V prpade drtovej prevencie niektor senzory mu da pokyn prepnau na pevnej sieti, aby
zablokoval sieov aktivitu zahajce konkrtne STA alebo AP a to poda adresy MAC
zariadenia alebo portu prepnaa. Ak STA naprklad posiela toky na server v pevnej sieti, senzor
me da pokyn pevnmu prepnau, aby blokoval vetku aktivitu na a z tohto STA. Tto
technika je inn iba pre blokovanie kodlivho STA alebo AP v komunikcii pevnej sieti.
Technika nezastav STA alebo AP od alieho vykonvania kodlivch aktivt prostrednctvom
bezdrtovch protokolov.
Tto as bola spracovan z uvedench zdrojov, najma vak sa opiera o prcu [SCA07].
Pre zujemcov o funkcie a nasadenie vone ritenho nstroja sieovho IDS Snort sa
odporaj publikcie [COX04], [ALD04] a [NOR03].
300
10.5.5 Pouit zdroje
[SCA07]
[BAC00]
[BEJ05]
[CRO02]
[END03]
[NOR03]
[RAS05]
[KRU05]
[COX04]
[ALD04]
301
SCARFONE, K., MELL, P.: Guide to Intrusion Detection and Prevention

Systems. Special Publication 800-94. NIST. February 2007.
BACE, R.: Intrusion Detection. Macmillan Technical Publishing, 2000.
BEJTLICH, R.: Extrusion Detection, Addison-Wesley, 2005.
CROTHERS, T.: Implementing Intrusion Detection Systems: A HandsOn Guide for Securing the Network, 2002. ISBN: 978-0-7645-4949-6
ENDORF, C. et al.: Intrusion Detection and Prevention, McGraw-Hill
Osborne Media, 2003.
NORTHCUTT, S., NOVAK, J.: Network Intrusion Detection: An
Analysts Handbook, Third Edition, New Riders, 2003. ISBN : 0-73571265-4
RASH, M., et al.: Intrusion Prevention and Active Response: Deployment
Network and Host IPS, Syngress, 2005.
KRUEGER, CH., VALEUR, F., VIGNA, G.: Intrusion Detection and
Correlation. Challenges and Solutions. Springer Science + Bussines
Media, Inc. 2005. ISBN: 0-387-23398-9
COX, K., J., GERG, C.: Managing Security with Snort and IDS Tools.
ORailly Publisher, 2004. ISBN 0-596-00661-6
ALDER, R. et all.: Snort 2.1 Intrusion Detection. Syngress Publishing.
2004. ISBN 1-931836-04-3
11 Plnovanie kontinuity innost

Michal Bubk
11.1 vod
Dostupnos IKT je jedna zo zkladnch poiadaviek informanej bezpenosti, ktor sa odvja od
dleitosti procesov a aktivt, pre ktor organizcia existuje. Monosti naruenia dostupnosti IKT
a nsledne aj procesov organizcie s pritom vemi irok. Siahaj od bench porch a zlyhan,
ktor sa nepodar vas vyriei a po prrodn katastrofy (poiar, povode, epidmia) a myseln
pokodenie (krde, terorizmus). Monosti organizcie zamedzi vskytu takchto udalost s
limitovan a potencilne nsledky katastroflne. Napriek tomu existuj monosti, ako pomocou
dslednej prpravy a systematickho prstupu zvlda tieto situcie a primerane zni dopady na
organizciu. V tejto kapitole sa budeme zaobera prve tm, o by mala organizcia spravi, aby
bola o najlepie pripraven zvldnu priebeh takej udalosti. Tto kapitola zko nadvzuje na asti
kapitoly 2: Analza rizk, Bezpenostn opatrenia a Spravovanie rizk.
Kee sa tto tma tka okrem IKT hlavne dostupnosti procesov organizcie, je dleit, aby kad
len organizcie mal zkladn prehad o problematike a bol schopn primerane svojej pozcii
participova na jednotlivch aktivitch na zabezpeenie dostupnosti.
Obsah kapitoly vychdza z metodiky spolonosti KPMG, ktor zohaduje akceptovan tandardy
pre tto oblas, ako s naprklad ISO 22301, BSI PAS77, ISO 27001 alebo COBIT. truktra
kapitoly reflektuje cyklus a nadvznos procesov v BCM oblasti a na zver popisuje poiadavky
uvdzan v legislatvnych aktoch SR a prehad relevantnch tandardov.
Vchodiskov stav vo vine organizci vzhadom na vskyt incidentov uvedench
v predchdzajcej kapitole je nasledovn. Bene bvaj prijat opatrenia ako naprklad pravideln
zlohovanie dajov (v niektorch prpadoch uchovvan na inom mieste), rmcov dohoda
s dodvateom hardvru alebo dohody o podpore s dodvatemi aplikci. alie pecifick
prpravn opatrenia vinou absentuj. Pri vskyte incidentu s potom monosti obnovy obmedzen
na obnovu dajov zo zlohy (za podmienky, e zlohy neboli tie zasiahnut a e je dostupn
potrebn infratruktra). Ak si obnova vyaduje zloitejie kony a zapojenie tretch strn, ako
naprklad konfigurciu hardvru alebo databzy, me to niekokonsobne predi celkov dobu
obnovy. V prpade zasiahnutia vieho rozsahu IKT me by problm s prioritizciou, t.j. v akom
porad obnovova jednotliv prvky IKT. Okrem tchto technickch zleitost sa hromadia
problmy aj na strane biznisu, ke pouvatelia nemu pracova pre nedostupnos prostriedku,
ktor potrebuj na svoju prcu.
Rieenm ako zvldnu incidenty ovplyvujce dostupnos s o najniou ujmou je systematick
prprava a realizcia premyslench aktivt nazvanch shrnne plnovanie kontinuity innost
(anglicky Business continuity planning alebo Business continuity management - BCM). Je to proces
podporovan vedenm organizcie, ktor identifikuje potencilne dopady a ktorho cieom je
vytvori tak postupy a prostredie, ktor umon zabezpei kontinuitu a obnovu kritickch procesov
a innost organizcie na vopred stanoven rove v prpade ich naruenia alebo straty. BCM je
zameran hlavne na bezpenostn incidenty s relatvne nzkou frekvenciou vskytu, ktor ale mu
ma potencilne vysok dopad, naprklad prrodn katastrofy, epidmie, poiar v miestnosti so
servermi a pod. Prnosom BCM v tchto prpadoch je znenie dopadu incidentu a skrtenie doby
obnovy po incidente.
Nosnou aktivitou BCM je prprava a udriavanie aktulnych plnov kontinuity innost (anglicky
Business Continuity Plan - BCP) a plnov obnovy (anglicky Recovery Plan - RP). Spolone sa
nazvaj aj akn plny. Akn pln je sada dokumentovanch postupov a informci pre pouitie v
prpade vskytu incidentu, ktor umonia organizcii obnovu a prevdzku kritickch
302
Plnovanie kontinuity innost | MF SR
procesov/innost na akceptovatenej preddefinovanej rovni (BCP), respektve obnovu a prevdzku

zdroja/prostriedku, ktor je vyuvan kritickm procesom (RP).
Nasledujci obrzok (pozri obr. 11.1 prevzat z metodiky KPMG [1]) popisuje priebeh a zvldnutie
bezpenostnho incidentu s pomocou BCM aktivt. Horizontlna os predstavuje asov priebeh
jednotlivch aktivt:
Obr. 11.1 asov priebeh incidentu

Pred vskytom incidentu je prevdzka na tandardnej rovni, pripravuj sa akn plny a s
vykonvan alie prpravn lohy. V pravidelnch intervaloch sa vykonva zlohovanie dajov.
Po vskyte incidentu sa spaj aktivity reakcie na incident (bliie popsan v kapitole Bezpenos
prevdzky). rove prevdzky klesne v dsledku incidentu na nulov alebo obmedzen rove.
Po vyetren incidentu s aktivovan prslun plny kontinuity innost. Spa sa obnova
zasiahnutch prostriedkov pomocou havarijnch plnov. Kritick procesy s postupne obnoven
najprv na minimlnu rove a nsledne na tandardn rove pred incidentom.
Vyhodnotenie zvldnutia incidentu a pouitia aknch plnov.
Jednotliv aktivity BCM bud podrobnejie popsan v nasledujcich astiach.
303
11.2 Procesn cyklus BCM

V nadvznosti na predchdzajcu as, ktor popsala podstatu a vznam BCM sa budeme v tejto
asti zaobera zavdzanm BCM v organizci. BCM pozostva z postupnosti nadvzujcich krokov,
ktor sa cyklicky opakuj. Z hadiska asovej nadvznosti mono BCM cyklus rozdeli na tyri
hlavn fzy; (a riadiace aktivity, ktor sa uplatuj v priebehu celho cyklu) obr. 11.2, prevzat z [1]:
Riadenie BCM vytvorenie riadiaceho rmca.
Ohodnotenie ohodnotenie aktv z hadiska ich vznamu pre organizciu, analza rizk, urenie
priort a zvislost.
Plnovanie vber opatren, ktor zabezpeia kontinuitu a obnovu kritickch procesov

organizcie na poadovanej rovni.
Implementcia zavdzanie opatren, prprava aknch plnov a realizcia kolen.
Monitorovanie overenie a udriavanie pripravenosti organizcie zabezpei kontinuitu a

obnovu kritickch procesov.
Obr. 11.2 Procesn cyklus BCM

V nasledujcich astiach rozoberieme innosti, ktor sa v jednotlivch fzach BCM vykonvaj,
podrobnejie.
11.2.1 Riadenie BCM
Na dosiahnutie vsledkov, ktor sa od BCM oakvaj je potrebn primeran miera jeho formalizcie v rmci organizcie vytvorenie riadiaceho rmca BCM. Tento zaha organizan zabezpeenie BCM, t.j. stanovenie rol, zodpovednost a prvomoc, obsadenie definovanch rol
kvalifikovanmi osobami a zabezpeenie potrebnch zdrojov, i u technickch alebo finannch.
Sasou riadiaceho rmca je aj definovanie a popis pravidiel vykonvania BCM aktivt a ich
primeran zachytenie v internej legislatve organizcie.
11.2.1.1 Organizan zabezpeenie
Za primeran rove BCM, rovnako ako za cel informan bezpenos, zodpoved cel vedenie
organizcie. len vedenia zodpovedn za IB by mal by zodpovedn aj za BCM. Ak organizcia
ustanovila komisiu pre IB, tto by mala riei aj otzky svisiace s BCM. Za rieenie operatvnych
304
loh v BCM oblasti zodpoved manar IB, respektve vo vch organizcich me by

ustanoven samostatn funkcia BCM koordintora.
Povinnosti osb a orgnov v BCM s nasledovn:
11.2.1.1.1 Vedenie/Komisia pre IB
Schvauje relevantn dokumenty politika BCM, metodika BCM, nvrhy opatren, akn plny,
pln testovania a pod.
Berie na vedomie/schvauje vsledky analzy rizk a vsledky analzy dopadov.
Vykonva dohad nad innosou Manara IB.
Zabezpeuje zdroje potrebn pre vkon aktivt BCM.
11.2.1.1.2 Manar IB
Prprava a udriavanie politiky BCM a metodiky BCM
Realizcia analzy dopadov a analzy rizk
Prprava nvrhov opatren
Prprava aknch plnov
Realizcia kolen a aktivt na zvyovanie povedomia
Prprava plnu testovania
Koordincia a realizcia testovania
Vyhodnocovanie testovania
Na splnenie uvedench povinnost potrebuje Manar IB vzhadom na irok zber BCM sinnos
od ostatnch zainteresovanch osb, predovetkm vlastnkov procesov a sprvcov prostriedkov.
Oakva sa od nich hlavne as pri:
ohodnoten procesu v rmci analzy rizk a analzy dopadov,
prprave nvrhu opatren,
prprave plnov kontinuity innost a plnov obnovy,
testovan plnov kontinuity innost a plnov obnovy.
11.2.1.1.3 Audit
BCM je dleit oblas informanej bezpenosti, priom podmienky v ktorch psob sa dynamicky
menia. Z uvedenho vyplva potreba ma istotu, e prijat opatrenia s aktulne a inn. Preto by
oblas BCM mala by predmetom pravidelnho auditu, i u samostatnho alebo v rmci auditu IB.
Audit BCM by sa mal zameriava predovetkm na:
stav a dodriavanie riadiacich dokumentov (politika BCM a metodika BCM),
realizciu a aktulnos analzy rizk a analzy dopadov,
nvrh a innos opatren,
stav prpravy aknch plnov a ich aktulnos,
testovanie aknch plnov.
305
11.2.1.2 kolenia a povedomie

Veobecn povinnos organizcie zabezpei kolenia a budovanie povedomia v IB je popsan v
kapitole 2.8. Z pohadu BCM je dleit zabezpei, aby osoby vymenovan v predchdzajcej asti
mali potrebn znalosti na vykonvanie svojich povinnost. Vedenie organizcie a manari potrebuj
chpa celkov kontext BCM a by si vedom bezpenostnch rizk a poiadaviek, aby mohli
prijma kvalifikovan rozhodnutia. Manar IB mus vedie vykonva niektor innosti priamo
a koordinova, respektve podporova ostatnch pri plnen ich povinnost. Vlastnci procesov
a sprvcovia zdrojov/prostriedkov potrebuj rozumie ako poui znalosti z ich oblasti pri zapojen
sa do analzy rizk, nvrhu opatren a prpravy aknch plnov.
11.2.1.3 BCM dokumenty
BCM dokumenty s sasou internej legislatvy organizcie a formalizuj oblas BCM v psomnej
podobe. Z pohadu bezpenostnej politiky ide o podriaden dokumenty, zvzn pre vetkch
zamestnancov organizcie, ktor detailnejie popisuj a rozvjaj oblas BCM. Bezpenostn politika
(alebo in jej podriaden dokumenty mimo BCM dokumentov) by mala zrove definova
nasledovn body relevantn pre BCM:
spsob realizcie analzy rizk a analzy dopadov,
identifikcia relevantnch dopadov, hrozieb a zranitenost,
spsob urenia kritickch procesov a ich podpornch zdrojov/prostriedkov,
systm kolen a zvyovania povedomia.
Za prpravu a udriavanie BCM dokumentov je zodpovedn Manar IB. BCM dokumenty musia
by schvlen vedenm organizcie a sprstupnen v slade s pravidlami organizcie pre intern
legislatvu.
11.2.1.3.1 Politika BCM
Politika BCM vychdza z bezpenostnej politiky, je jej podriaden a dopa jej ustanovenia. Politika
BCM definuje nasledovn body:
ciele organizcie v oblasti BCM,
zvzok vedenia organizcie smerom k BCM,
stanovenie rozsahu oblast organizcie, ktor s pokryt BCM,
zadefinovanie rol a zodpovednost.
11.2.1.3.2 Metodika BCM

Tento dokument popisuje konkrtne postupy realizcie BCM procesov v organizcii, ktor s prli
detailn na to, aby boli uveden v politike BCM alebo v bezpenostnej politike. Metodika BCM
popisuje nasledovn body:
identifikcia relevantnch opatren,
spsob prpravy aknch plnov,
spsob testovania aknch plnov.
11.2.2 Ohodnotenie
Cieom aktivt tejto fzy je:
identifikova a popsa kritick procesy a innosti organizcie,
identifikova zdroje a prostriedky, ktor s nevyhnutn pre fungovanie kritickch procesov,

306
identifikova zvislosti medzi procesmi,
uri maximlnu dobu vpadku kritickch (MTO) procesov a zdrojov,
identifikova hrozby, zranitenosti a rizik, ktor mu narui dostupnos kritickch procesov,
uri ciele pre dosiahnutie poadovanho stavu odolnosti - cieov as obnovenia (RTO) a
cieov bod obnovenia (RPO).
Uveden body s rieen v rmci dvoch aktivt - analza rizk a analza dopadov, ktor s popsan v
kapitole 2. V tejto asti sa budeme detailnejie venova tm aspektom oboch aktivt, ktor s dleit
z pohadu BCM:
Prprava zoznamu procesov a urenie vlastnctva procesov: Identifikcia innost, ktor

organizcia realizuje na plnenie svojho poslania (procesov) a informci spracovvanch v rmci
procesov. Procesy a informcie s tzv. primrne aktva, na rovni ktorch sa vykonva
ohodnotenie dopadov (pozri normu [2]). Za prpravu zoznamu procesov vhodnho pre ely
analzy rizk a analzy dopadov zodpoved manar IB v spoluprci s vlastnkmi procesov.
Vlastnk procesu je osoba, ktor m konen zodpovednos za vykonvanie procesu a zrove
uruje spsob vykonvania procesu. Pri identifikcii procesov a ich vlastnkov sa odpora
vychdza z organizanej truktry a organizanho poriadku organizcie. Pri realizcii analzy
rizk a analzy dopadov po prv krt sa neodpora s do prli vekho detailu.
Identifikovanch procesov s rdovo desiatky.
Ohodnotenie dopadov: Vlastnk procesu s podporou manara IB ohodnot dopady vpadku

procesu v rznych asovch rozsahoch a na definovanej stupnici.
-
asov rozsahy v akch sa ohodnocuje dopad (ak je vka dopadu pri vpadku procesu na
jednu hodinu, jeden de, jeden tde a pod.) s definovan v metodike BCM a musia by
prispsoben podmienkam organizcie. Naprklad pre organizciu poskytujcu on-line sluby
je dleit ohodnoti vpadok u v intervale desiatok mint. Prklad asovch rozsahov je
uveden na obrzku (pozri obr. 11.3 prevzat z metodiky KPMG [1]):
Obr. 11.3 Prklad asovch rozsahov

-
Stupnica stanovuje hodnoty, ktor je mon priradi dopadu. Me by vyjadren slovne

(nzky, stredn, vysok), alebo selne.
Typy dopadov, prklady finann, dopad na reputciu, prevdzkov, poruenie zkonnch

povinnost, poruenie zmluvnch zvzkov, osobn bezpenos (ohrozenie ivota a zdravia),
ohrozenie verejnho poriadku a pod.
Prklad tabuky dopadov je uveden na obrzku (pozri obr. 11.4 prevzat z metodiky KPMG
[1]):
307
Obr. 11.4 Prklad tabuky dopadov
Identifikcia zvislost medzi procesmi a nsledn korekcie: Vlastnk procesu identifikuje in

procesy, ktorch dostupnos je potrebn pre jeho proces. Respektve identifikuje procesy, ktor
vyaduj dostupnos vlastnkovho procesu. Takto postupuj vetci vlastnci procesov a pomocou
krovej kontroly s identifikovan vetky zvislosti medzi procesmi. V prpade vznamnch
zvislost, je potrebn zvi korekciu ohodnotenia dopadov. Prklad:
-
Vlastnk procesu A ohodnotil dopad vpadku procesu A na rovni stredn.
Vlastnk procesu B ohodnotil dopad vpadku procesu B na rovni vysok.
Vlastnk procesu B identifikoval vysok zvislos procesu B na procese A.
Vlastnk procesu A potvrdil zvislos procesu B na procese A.
Na zklade identifikovanej zvislosti je dopad vpadku procesu A korigovan na rove

procesu B, t.j. vysok.
Urenie MTO, RTO a RPO: Vlastnk procesu ur v slade s predchdzajcim ohodnotenm

dopadov maximlnu dobu vpadku, cieov as obnovenia a cieov bod obnovenia svojho
procesu.
Identifikcia potrebnch zdrojov a prostriedkov: Vlastnk procesu ur, ktor zdroje

a prostriedky, ktor s pre jeho proces nevyhnutn. Prklady zdrojov s aplikcie/informan
systmy, technick prostriedky a infratruktra, daje (vo fyzickej aj elektronickej podobe),
udsk zdroje, lokality, tretie strany (dodvatelia). Poda identifikovanch zvislost sa na zdroje
a prostriedky prenaj ohodnotenia z rovne procesov. Prklad:
-
Vlastnk procesu A ohodnotil maximlnu dobu vpadku procesu A na rovni 1 de.
Vlastnk procesu A identifikoval vysok zvislos procesu A na softvrovej aplikcii X.
Maximlna doba vpadku aplikcie X bude uren na zklade procesu A na rovni 1 de.
V prpade, e je jeden zdroj alebo prostriedok potrebn pre viac procesov s rznymi hodnotami, berie
sa do vahy niia hodnota. Prklad:
-
Vlastnk procesu A ohodnotil maximlnu dobu vpadku procesu A na rovni 1 de.
308
Vlastnk procesu A identifikoval vysok zvislos procesu A na softvrovej aplikcii X.
Vlastnk procesu B ohodnotil maximlnu dobu vpadku procesu B na rovni 4 hodiny.
Vlastnk procesu B identifikoval vysok zvislos procesu B na softvrovej aplikcii X.
Maximlna doba vpadku aplikcie X bude uren ako niia hodnota ohodnotenia procesov
A a B, t.j. na rovni 4 hodiny.
Urenie priority procesov: Usporiadanie procesov poda predchdzajcich ohodnoten a poda

zverov analzy rizk. Kritriami pre urenie priority procesu je mon negatvny dopad a riziko
vpadku.
11.2.3 Plnovanie
Cieom aktivt tejto fzy je oetrovanie tch rizk, ktorch hodnota prevyuje akceptovaten rove
a zrove, pri ktorch sa dopad hrozby prejav v naruen dostupnosti procesov a innost
organizcie. Z monost na oetrovanie rizk (redukcia, zachovanie, vyhnutie sa a prenesenie) sa
BCM zaober redukciou rizika - zavedenm predovetkm koreknch opatren a prenanm rizika.
Nvrhy opatren na redukciu a prenanie rizika rozliujeme poda typu aktva na ktor psob
hrozba prslunho rizika. Nasledujce asti s preto truktrovan poda jednotlivch typov aktv a
popisuj prklady konkrtnych opatren.
Dleitm krokom pri vbere opatren na oetrovanie rizk je analza ekonomickej efektvnosti
(pozri kapitolu 2.8). Vzhadom na to, e opatrenia z oblasti BCM oetruj viacero individulnych
rizk, je dleit porovnva nklady zavedenia opatren s ich kumulatvnym prnosom. Prklad:
Zlon vpotov centrum zabezpe pri vpadku primrneho centra dostupnos vetkch aplikci,
ktor s prevdzkovaten zo sekundrneho vpotovho centra. Nklady na zlon centrum treba
preto porovnva s kumulatvnym prnosom znenia vetkch rizk, ktor svisia s aplikciami
prevdzkovatenmi zo zlonho centra.
11.2.3.1 Opatrenia pre IKT prvky a daje
Zkladnm opatrenm pre daje a softvrov vybavenie je zlohovanie a obnova zo zlohy. Pri
implementcii tohto opatrenia je dleit zodpoveda tri otzky: frekvencia zlohovania, rozsah
zlohovania a umiestnenie zloh. daje zskan v rmci fzy ohodnotenia doku zodpoveda vetky
tieto otzky. Pre urenie primeranej frekvencie a rozsahu zlohovania je urujci parameter cieov
bod obnovenia (RPO). K vhodnmu umiestneniu zloh nm okrem inho pome aj parameter
cieov as obnovenia (RTO). Tma zlohovania je podrobne rozobrat v kapitole 6 bezpenos
prevdzky.
alm opatrenm je rozloenie IKT prvkov do rznych geografickch oblast, naprklad na u
spomnan primrne a zlon vpotov centr. V primrnom vpotovom centre je umiestnen
produkn prevdzka informanch systmov a zlon sli pre prpad vpadku primrneho centra.
Rozliujeme rzne stupne pripravenosti zlonho centra. Plat pri tom, e m via je
pripravenos, tm rchlejie sa zrealizuje obnova, ale zrove je rieenie nkladnejie. Prklady
pripravenosti zlonho vpotovho centra s nasledovn:
Postupn obnova (angl. Cold Site alebo Cold Standby): Dopredu pripraven prenosn alebo
trval priestory primeranej vekosti, ktor maj zaveden napjanie elektrickou energiou a
telekomunikan pripojenie. Intalcia a konfigurcia hardvru a softvru a obnova dajov sa
vykon dodatone.
Strednodob obnova (angl. Warm Site alebo Warm Standby): Obsahuje to ist o
predchdzajci bod, plus navye nenakonfigurovan hardvr, softvr a sieov komponenty.
Konfigurcia hardvru a softvru a obnova dajov sa vykon dodatone.
Rchla obnova (angl. Hot Site alebo Hot Standby): Navye oproti predchdzajcemu bodu
obsahuje nakonfigurovan a pripraven hardvr aj softvr. Potreba obnovy dajov zo zlohy.
309
Oproti vymenovanm monostiam existuj aj rieenia vysokej dostupnosti (angl. High Availability
Clusters) vyuvajce technolgie ako zrkadlenie (angl. mirroring) a rozloenie vkonu na viac
prvkov (angl. load balancing). Tieto rieenia umouj obnovu bez akejkovek straty sluby.
V tomto prpade nehovorme o primrnom a zlonom centre ale o dvoch (alebo dokonca viacerch)
zrkadlench centrch (angl. mirrored sites), ktor s z pohadu technickej vybavenosti na rovni
primrneho centra. Toto rieenie je vhodn poui pri vysokch potencilnych dopadoch, naprklad
pre elektronick sluby vkonu ttnej moci (eGovernment), obchodovanie cez Internet alebo sluby
elektronickho bankovnctva.
11.2.3.2 Opatrenia pre udsk zdroje
udsk zdroje s pecifick typ aktva, ke na jednej strane vykonvaj vetky neautomatizovan
procesy organizcie a na druhej strane s nositemi schopnost a znalost. Prve pecifick
schopnosti a znalosti jednotlivcov obmedzuj jednoduch nahradenie chbajcej osoby inou.
Nedostupnos udskch zdrojov me by spsoben udalosami na rovni jednotlivcov (choroba,
zranenie, smr) alebo vch skupn (epidmia), priom priebeh konkrtneho scenra je vemi
individulny. Zrove pouitenos jednotlivch opatren je rzna pre jednotliv organizan
jednotky organizcie, respektve pre jednotliv osoby. Z tchto dvodov je vemi nron vybra
jedin sprvne opatrenie, ktor pome vo vetkch prpadoch. Namieste je preto kombincia
viacerch opatren. Prklady opatren pre udsk zdroje:
Navenie potu pracovnkov oproti skutonm potrebm: Toto opatrenie umon vykry
neoakvan vpadky (prceneschopnos) a zrove zvyuje flexibilitu pri plnovan pracovnch
loh.
Dokumentcia postupov a znalost: Aktulna a prehadn dokumentcia pracovnch postupov,

znalost a sksenost umon v prpade vpadku rchlej a efektvnej nstup nhradnch
udskch zdrojov.
Prekrvajce sa pracovn pozcie: Rozsah jednotlivch pracovnch pozci nie je disjunktn,

ale existuj medzi nimi prieniky. Prpadn vpadok je potom mon vykry zo zostvajcich
zdrojov.
Zastupitenos / Plnovanie nstupnctva: Na konkrtnu pracovn pozciu pripad viac osb,

ktor sa v prpade vpadku vedia zastpi.
Rotcia zamestnancov: Pravidelnou rotciou zamestnancov sa docielia irie znalosti a ir

zber jednej osoby, ako je jej aktulna pozcia. Prpadn vpadok je potom mon vykry
zo zostvajcich zdrojov, ktor dan prcu v minulosti vykonvali.
Pouitie tretch strn: Ak to dovouje povaha prc, jednou z nhradnch alternatv s extern
zamestnanci. Pri pouit tejto stratgie sa odpora njs vhodnho dodvatea a dohodn s nm
podmienky vopred. Vzah s dodvateom me by postaven na kontrakte typu SLA, t.j. je
presne stanoven rove sluby, ktor mus dodvate dodra.
Za zavdzanie uvedench opatren s zodpovedn vlastnci procesov, ktorm z ich pozcie vyplvaj
aj prvomoci riei personlne otzky. loha manara IB je metodicky podporova a koordinova
vlastnkov procesov a nsledne kontrolova realizciu vybranch opatren.
11.2.3.3 Opatrenia pre priestory
Opatrenia uveden v tejto kapitole sa tkaj priestorov, ktor vyuvaj pracovnci organizcie pre
realizciu procesov organizcie. Opatrenia pre vpotov centr v ktorch s umiestnen centrlne
IKT prvky s popsan v asti 11.2.3.1. Nedostupnos priestorov mu spsobi hrozby ako poiar,
zplavy, prrodn katastrofy, demontrcie, nepokoje, terorizmus a pod.
Prklady opatren pre udsk zdroje:
310
Alternatvne priestory v rmci organizcie: Organizcia disponuje niekokmi lokalitami,

ktor s od seba geograficky vzdialen a maj von kapacity s pripravenmi pracovnmi
priestormi. V prpade nedostupnosti niektorej z lokalt sa pracovnci presun do druhej lokality
poda poradia priority procesov, ktorch kontinuitu je potrebn zaisti,
Alternatvne priestory poskytnut treou stranou: Organizcia uzavrie dohodu o poskytnut

nhradnch pracovnch priestorov treou stranou. Me s o recipron dohodu, kedy
poskytovanie priestorov nie je primrnou innosou tretej strany a poskytuje ich za prsub
rovnakej pomoci v prpade nedostupnosti jej vlastnch priestorov. Druh monos je dohoda na
komernom zklade, ke tretia strana poskytuje alternatvne priestory za odplatu ako svoju
primrnu innos.
Prca z domu: Ak je to technicky realizovaten a dovouje to povaha prc, je mon nariadi

pracovnkom prcu z domu.
Umiestnenie alternatvnych priestorov by nemalo by prli blzko pri hlavnch priestoroch, aby
nepodliehali rovnakmu riziku vpadku a zrove by nemali by prli aleko, aby to nesaovalo
presun a logistiku pracovnkov a pracovnch prostriedkov.
Pre uveden opatrenia je dleit mobilita pracovnch prostriedkov.
11.2.3.4 Opatrenia pre dodvateov
Spravidla kad organizcia vyuva v dnenej dobe dodvateov. Prkladom dodvatemi
poskytovanch sluieb mu by telekomunikan sluby, vvoj a drba softvru, prvne
poradenstvo, spracovanie miezd a pod. Dodvatelia pritom podliehaj vlastnm rizikm, ktor sa
mu prejavi nedostupnosou ich sluieb, o nsledne me ma negatvny vplyv na dostupnos
procesov organizcie, ktor vyuva sluby dodvatea. Vzhadom na to, e opatrenia na strane
dodvatea s mimo kontroly organizcie, potrebuje organizcia aplikova vlastn opatrenia na
oetrovanie rizk svisiacich s dodvatemi, ako naprklad:
Zvenie potu dodvateov: Aktvne vyuvanie niekokch dodvateov na ten ist druh
sluby. Pri vpadku jednho dodvatea sa rozloia dodvky na ostatnch.
Identifikcia vhodnch alternatvnych dodvateov: Organizcia si vopred vyhad
vhodnch nhradnch dodvateov a prpadne dohodne podmienky dodvky sluieb, ktor
vyuije a v momente vpadku hlavnho dodvatea.
Dohody o rovni poskytovanch sluieb (SLA): Zaviazanie dodvatea k dodraniu
stanovench rovn sluieb. Prkladom parametrov me by dostupnos sluby
v percentch, maximlna doba reakcie na mimoriadnu situciu, maximlna doba na
vyrieenie mimoriadnej situcie a obnovu sluieb a pod. Stanovenie sankci a povinnosti
nahradi kodu pri nedodran stanovench rovn sluieb.
Poiadavky na zabezpeenie BCM na strane dodvatea: Sasou poiadaviek na
dodvatea me by poiadavka preukza primeran schopnos obnovy. Dodvate sa
me naprklad preukza certifiktom na svoj systm riadenia kontinuity innost vydan
nezvislou certifikanou autoritou, alebo umon organizcii vykona extern audit.
11.2.4 Implementcia
Cieom aktivt tejto fzy je na jednej strane implementova opatrenia vybran v predchdzajcej fze
a na druhej strane pripravi akn plny a vykoli personl tak, aby boli zaveden opatrenia pri
vskyte incidentu o najinnejie. Samotn zavdzanie opatren je popsan v kapitole 2. V tejto
asti sa zameriame na prpravu aknch plnov a kolenia personlu.
11.2.4.1 Prprava aknch plnov
Na vysvetlenie vznamu jednotlivch aknch plnov pouijeme BSI tandard [3], s relatvne
jednoduchou truktrou plnov:
311
Pln okamitej reakcie (Immediate measures plan) popisuje kroky na prvorad zabezpeenie
bezpenosti a ochrany osb.
Prruka krzovho tmu (Crisis team guide) spolu s plnom krzovej komunikcie (Crisis
communication plan) dvaj nvod na zvldnutie krzovho stavu a popisuj riadenie
komunikcie poas krzovho stavu.
Plny kontinuity innost (Business continuity plans) popisuj reakciu organizcie na vpadok
kritickch procesov spsoben bezpenostnm incidentom. Pln kontinuity innost tvor sada
dokumentovanch postupov a informci, ktor umonia organizcii obnovu a prevdzku
kritickch procesov na akceptovatenej preddefinovanej rovni. Prklad truktry plnu
kontinuity innost je uveden v prlohe 11.5.1.
Plny obnovy (Recovery plans) obsahuj dokumentovan postupy a informcie, ktor umonia
organizcii obnovu a prevdzku zdroja/prostriedku. Plny obnovy dopaj plny kontinuity
innost. Prklad truktry plnu obnovy je uveden v prlohe 11.5.2.
Akn plny s pripravovan pre procesy a zdroje/prostriedky v zvislosti od ich priority

urenej vo fze ohodnotenia a v slade s opatreniami urenmi vo fze plnovania.
Na prprave aknch plnov sa na jednej strane podieaj vlastnci a vykonvatelia procesov,

respektve sprvcovia zdrojov a prostriedkov, ktor do prpravy plnov vloia svoje znalosti
a sksenosti s danm procesom, respektve zdrojom/prostriedkom. Na strane druhej je to manar IB,
ktorho lohou je zabezpei slad aknch plnov s poiadavkami na obnovu ktor maj naplni,
slad s celkovm kontextom BCM v organizcii a konzistentn formu.
Pripraven akn plny musia by schvlen vedenm organizcie.
Po prprave a schvlen aknch plnov je potrebn vykoli osoby zahrnut do aknch plnov tak,
aby boli schopn akn plny pouva a dosiahnu poadovan vsledky. Za prpravu a realizciu
kolen je zodpovedn manar IB. S obsahovou asou kolen mu pomu vlastnci procesov a
sprvcovia zdrojov, ktor sa podieali na prprave plnov.
11.2.5 Monitorovanie
Cieom aktivt tejto fzy je overenie a udriavanie pripravenosti organizcie zabezpei kontinuitu a
obnovu kritickch procesov a innost. Akn plny sa vo vine prpadov nepodar napsa na prv
krt dostatone dobre. Na dosiahnutie poadovanej spoahlivosti aknch plnov je potrebn ich
opakovan precviovanie (testovanie). Pravideln testy aknch plnov a v prpade potreby aj
nsledn pravy zrove pomhaj udriava akn plny aktulne a zvyuj bezpenostn
povedomie zainteresovanch osb.
Najspoahlivejia forma overenia pripravenosti organizcie je pouitie aknch plnov pri vskyte
skutonho bezpenostnho incidentu. Kad takto prpad mus by sptne posden a mus by
vyhodnoten, i boli pouit akn plny primeran a i nepotrebuj alie pravy.
alou aktivitou v rmci monitorovania je previerka, i s v organizcii dosiahnut ciele pre oblas
BCM stanoven bezpenostnou politikou.
11.2.5.1 Testovanie aknch plnov
Pravidelnm testovanm a precviovanm aknch plnov dosahuje organizcia hne niekoko
cieov:
odhalenie prpadnch nedostatkov, chb a nepresnost v plnoch,
zlepenie informovanosti a povedomia o informanej bezpenosti u zainteresovanch

pracovnkov,
nadobudnutie a precviovanie potrebnch zrunost,
312
efektvnejie pouitie plnov,
zskanie istoty, e sa (vedenie organizcie a zamestnanci) me na akn plny spoahn v

prpade vskytu bezpenostnho incidentu.
Za organizciu testovania, vkon testovania a nsledn aktualizciu aknch plnov zodpoved

manar IB. Pri organizcii testovania mus bra do vahy viacero faktorov. Predovetkm je to
priorita procesov a zdrojov/prostriedkov, pre ktor s akn plny pripraven. alej s to nklady na
testovanie, predovetkm v podobe asu zainteresovanch pracovnkov. Na zver s to rizik spojen
s jednotlivmi typmi testov.
Testovanie aknch plnov je potrebn vykonva v opakovanch cykloch minimlne na ronej
bze. Jeden cyklus obsahuje nasledovn kroky:
prprava a schvlenie plnu testovania na cel cyklus (naprklad rok),

prprava a schvlenie jednotlivch testov,
vkon testovania v dohodnutom ase,
dokumentcia priebehu a vsledkov testovania,
analza a vyvodenie zverov.
11.2.5.1.1 Pln testovania

Manar IB je zodpovedn za prpravu plnu testovania aknch plnov, priom zohadn vsledky
analzy rizk, analzy dopadov a predchdzajce plny testovania. V rmci plnu ur vhodn typy
testov (typy testov s popsan v prlohe 11.5.3) jednotlivch aknch plnov a obdobie vykonania
testovania. Pln testovania mus by nsledne schvlen vedenm organizcie.
Manar IB je nsledne zodpovedn za prpravu detailnho nvrhu kadho testu, priom zvi
vetky mon negatvne dopady testu na prevdzku a funknos innost organizcie. Vyhodnoten
musia by nasledovn oblasti:
kritickos procesov,
prepojenie s ostatnmi procesmi,
vhodn typy testov,
dostupnos zdrojov potrebnch na vykonanie plnovanch testov.
Nvrhy jednotlivch testov musia by nsledne schvlen vedenm organizcie.

11.2.5.1.2 Vkon testu a jeho dokumentcia
Manar IB je zodpovedn za realizciu jednotlivch testov v stanovenom termne poda plnu
testovania a za zabezpeenie dokumentcie priebehu testovania (napr. vo forme protokolu
z testovania). Na testovan sa podieaj osoby popsan v nvrhu testu poda pokynov manara IB.
11.2.5.1.3 Analza a vyvodenie zverov
Po ukonen testu je manar IB zodpovedn za vykonanie analzy priebehu a vsledkov testovania
v spoluprci s relevantnmi astnkmi testu, respektve s almi osobami (napr. vlastnk aktva).
Analza by sa mala zamera na:
vyhodnotenie vhodnosti a primeranosti obnovovacch postupov,
vyhodnotenie vhodnosti a primeranosti alternatvnych postupov,
vyhodnotenie asovho trvania jednotlivch krokov aknho plnu,
vyhodnotenie internej a externej komunikcie,
313
vyhodnotenie potreby prekolenia jednotlivch zamestnancov.
Vsledkom analzy je zhodnotenie spenosti testu, popis nedostatkov zistench poas testu a ak je
to potrebn popsanie nvrhov na npravu a zmeny.
11.2.5.2 Vyhodnotenie aktivcie aknch plnov
Po vskyte bezpenostnho incidentu, poas ktorho bol aktivovan akn pln je potrebn vykona
analzu a vyhodnotenie pouitia aknho plnu. Za vyhodnotenie aktivcie aknch plnov a ich
prpadn aktualizciu zodpoved manar IB. Analza je kov pre ohodnotenie schopnosti
organizcie pouva akn plny a pre prpadn zlepovanie aknch plnov. Analza sa podobne
ako pri analze testovania aknch plnov zameriava na:
vyhodnotenie vhodnosti a primeranosti obnovovacch postupov,
vyhodnotenie vhodnosti a primeranosti alternatvnych postupov,
vyhodnotenie asovho trvania jednotlivch krokov aknho plnu,
vyhodnotenie internej a externej komunikcie,
vyhodnotenie potreby prekolenia jednotlivch zamestnancov.
Vsledkom analzy je rovnako ako pri analze testovania aknch plnov zhodnotenie spenosti
pouitia plnu, popis nedostatkov zistench poas pouitia plnu a ak je to potrebn popsanie
nvrhov na npravu a zmeny.
11.2.5.3 Previerka BCM funkcie
Oblas BCM by mala by, rovnako ako in oblasti organizcie, predmetom previerky zo strany
manamentu a auditu. elom previerky je posdenie dosiahnutia cieov stanovench v
bezpenostnej politiky pre oblas BCM, respektve uistenie sa o vhodnosti, adekvtnosti a efektivite
BCM funkcie. V rmci rozsahu previerky mu by naprklad nasledovn body:
organizan rmec BCM
BCM dokumenty
proces, vsledky a aktulnos analzy rizk a analzy dopadov
nvrhy a implementcia opatren
stav a pokrytie aknch plnov
realizcia plnu testovania aknch plnov
Zvery previerky BCM funkcie, spolu so zvermi z testovania aknch plnov a z vyhodnotenia
aktivcie aknch plnov tvoria vchodisk na kontinulne zlepovanie BCM funkcie.
11.3 BCM v legislatvnych aktoch SR a tandardoch

Oblas BCM je parcilne rieen v niekokch legislatvnych aktoch. S to najm Vnos MFSR .
312/2010 o tandardoch pre ISVS [4], zkon . 45/2011 o kritickej infratruktre [6] a zkon .
122/2013 Z. z. o ochrane osobnch dajov a o zmene a doplnen niektorch zkonov [7].
V rmci tandardov existuj tandardy zameran pecificky na oblas BCM (napr. ISO 22301 [9]),
ako aj tandardy so irm zberom, ktor sa venuj BCM ako podoblasti informanej bezpenosti
(napr. ISO/IEC 27001 [10]).
314
11.3.1 Vnos MFSR . 312/2010 o tandardoch pre ISVS

Vnos definuje bezpenostn tandardy pre ISVS v rozsahu paragrafov 28 a 42, ktor s doplnen
v svisiacom Metodickom pokyne . MF/23579/2011 [5]. Pre oblas BCM s relevantn nasledovn
poiadavky:
30 Manament rizk pre oblas informanej bezpenosti
d) analyzovanie procesov povinnej osoby, ktor s podstatn pre plnenie innosti povinnej osoby z
hadiska ich zvislosti od informanch systmov verejnej sprvy, a urenie procesov, ktor nemu
prebieha v prpade vpadku alebo obmedzenia funknosti prslunch informanch systmov
verejnej sprvy; tieto procesy s kritickmi procesmi
e) analyzovanie rizk vyplvajcich z hrozieb pre informan systmy verejnej sprvy, od ktorch
zvisia kritick procesy; tieto informan systmy s kritickmi informanmi systmami verejnej
sprvy
f) vypracovanie plnov na obnovu innosti nefunknch, pokodench alebo zniench kritickch
informanch systmov verejnej sprvy
Komentr:
Body d) a e) s v podstate poiadavkou na vykonanie analzy dopadov a analzy rizk a zrove
popisuj ako uri kritick procesy a kritick ISVS.
Bod f) je jednoznan poiadavka na prpravu plnov obnovy pre kritick ISVS.
34 Fyzick bezpenos a bezpenos prostredia
f) zabezpeenie, aby boli existujce zlon kapacity informanho systmu verejnej sprvy,
zabezpeujce funknos alebo nhradu informanho systmu verejnej sprvy, umiestnen v
sekundrnom zabezpeenom priestore, dostatone vzdialenom od zabezpeenho priestoru
Doplnenie metodickho pokynu:
V tejto poiadavke nie s myslen archivan alebo prevdzkov zlohy, ale zloha funknosti
systmu (sekundrny server a podobne).
Komentr:
Poiadavka v podstate uruje poadovan rove opatren, a to pre informan systmy ako aj pre
lokality.
i) stanovenie parametrov pre informan systmy verejnej sprvy, ktor definuj maximlnu
prpustn dobu vpadku informanho systmu verejnej sprvy a vytvorenie a zavedenie opatren,
ktor s zameran na rieenie obnovy prevdzky v prpade vpadku informanho systmu verejnej
sprvy
Komentr:
Poiadavka stanovi maximlnu prpustn dobu vpadku pre ISVS, priom tto hodnota sa d poui
ako referenn pri testovan obnovy. Druh as vety hovor veobecne o opatreniach na rieenie
obnovy prevdzky v prpade vpadku ISVS, o je iba inak pomenovan pln obnovy.
38 Zlohovanie
d) zabezpeenie vykonania testu obnovy informanho systmu verejnej sprvy a dajov z
prevdzkovej zlohy najmenej raz za jeden rok.
Komentr:
Poiadavka na minimlnu frekvenciu testovania plnu obnovy ISVS.
39 Fyzick ukladanie zloh
b) fyzick ukladanie druhej kpie archivanej zlohy v inom objekte, ako sa nachdzaj technick
prostriedky informanho systmu verejnej sprvy, ktorho daje boli archivovan tak, aby bolo
minimalizovan riziko pokodenia alebo znienia dtovch nosiov archivanej zlohy v dsledku
poiaru, zplavy alebo inej ivelnej pohromy
Doplnenie metodickho pokynu:
Dvodom je, aby pri pokoden budovy resp. miestnosti, kde sa nachdza server alebo in sasti
informanho systmu nenastalo zrove znienie oboch archivanch kpi. Je vhodn, aby napr.
vzhadom na ohrozenie poiarom nebola ako objekt uloenia susediaca budova.
315
Komentr:
Zopakovanie a spresnenie poiadavky na rove opatren z bodu f) 34.
11.3.2 Zkon . 45/2011 Z.z. o kritickej infratruktre
Pre oblas BCM s relevantn nasledovn poiadavky zkona:
9 Povinnosti prevdzkovatea
(1) Prevdzkovate je povinn ochraova prvok pred naruenm alebo znienm. Na ten el
prevdzkovate je povinn:
b) zavies bezpenostn pln...
10 Bezpenostn pln
(1) Bezpenostn pln obsahuje popis monch spsobov hrozby naruenia alebo znienia prvku,
zraniten miesta prvku a bezpenostn opatrenia na jeho ochranu.
(2) Bezpenostn opatrenia na ochranu prvku s najm mechanick zbrann prostriedky, technick
zabezpeovacie prostriedky, bezpenostn prvky informanch systmov, fyzick ochrana,
organizan opatrenia, kontroln opatrenia a ich vzjomn kombincia.
Komentr:
Sasou bezpenostnho plnu me by aj pln obnovy prvku ako kombincia technickch
a organizanch opatren na jeho ochranu.
niektorch zkonov
Vyhlka radu na ochranu osobnch dajov z 13. jna 2013 o rozsahu a dokumentcii
bezpenostnch opatren [8] ustanovuje poda 20 ods. 3 zkona . 122/2013 Z. z. o ochrane
osobnch dajov a o zmene a doplnen niektorch zkonov [7] nasledovn poiadavky v oblasti
BCM:
4
Bezpenostn smernica poda 19 ods. 2 zkona obsahuje:
e) postupy pri havrich, poruchch a inch mimoriadnych situcich vrtane preventvnych
opatren na znenie rizika vzniku mimoriadnych situci a monost efektvnej obnovy stavu pred
havriou, poruchou alebo inou mimoriadnou situciou.
Komentr:
Bod e) je jednoznan poiadavka na prpravu plnu obnovy pre informan systm, v ktorom s
spracvan osobn daje.
11.3.4 Prehad tandardov pre oblas BCM
BCM ako jednu z kovch oblast IB njdeme v tandardoch, ktor sa zaoberaj celou rkou
problematiky IB. Zkladn s normy ISO/IEC rady 2700xx konkrtne s to ISO/IEC 27001
Information security management systems Requirements [10] a ISO/IEC 27002 Code of
practice for information security management [11], ktor zavdzaj systematick prstup k riadeniu
IB v organizcii (pozri kapitolu 2). Poiadavka na plny kontinuity innosti je zaraden
do bezpenostnej politiky a rozobrat podrobnejie v samostatnej kapitole normy.
Z rady noriem ISO/IEC 2700xx je aj norma ISO/IEC 27031:2011 Information technology Security
techniques Guidelines for information and communication technology readiness for business
continuity [13], ktor popisuje procesy na prevenciu, predikciu a riadenie udalost tkajcich sa IKT,
ktor mu narui kontinuitu innost organizcie.
alie normy z rady 2700xx popisujce dleit sasti BCM oblasti s ISO/IEC 27005
Information security risk management [2] a ISO/IEC TR 27008 Guidance for auditors on ISMS
controls (focused on the information security controls) [12]. Bli popis je uveden v kapitole 2.
Samostatn ISO norma, ktor sa venuje manamentu kontinuity innost je ISO 22301 Societal
security Business continuity management systems --- Requirements [9]. Norma popisuje systm
316
manamentu kontinuity innost (angl. Business Continuity Management System) zaloen na

rovnakom prstupe (PDCA cyklus) ako systm manamentu IB poda normy ISO/IEC 27001 [10].
Organizcie si mu poda normy ISO 22301 certifikova svoj systm manamentu kontinuity
innost.
Okrem medzinrodnch tandardov existuj aj nrodn tandardy a metodick materily. Strune
spomenieme najdleitejie z nich.
Britsk intitt pre tandardy (British Standards Institution) vydal v roku 2006 britsk nrodn
tandard BS 25999 - Business Continuity Management [14], z ktorho sa neskr vyvinul
medzinrodn tandard ISO 22301.
Americk NIST (National Institute of Standards and Technology Nrodn intitt pre tandardy a
technolgie) vydal NIST Special Publication 800-34 Rev. 1 - Contingency Planning Guide for
Federal Information Systems [15]. Publikcia poskytuje truktrovan nvod a odporania na
zavedenie procesu plnovania kontinuity pre obnovu informanch systmov po havrii. Dokument
bol pripraven pre americk federlne informan systmy, ale minimlne ako inpircia je
pouiten aj v slovenskch podmienkach.
Nemeck BSI vydal niekoko tandardov zameranch na IB. Posledn z nich BSI Standard 100-4:
Business Continuity Management [3] popisuje, ako vyvin, zavies a udriava v organizcii systm
na riadenie kontinuity innosti. tandard sa d poui bu samostatne, alebo ako doplnok
k predchdzajcim tandardom zameranm na ISMS (pozri kapitolu 2).
317
11.4 Zdroje a literatra

[1]
Metodika KPMG Business Continuity Management Toolkit
[2]
ISO/IEC 27005 Information technology Security techniques Information security risk

management
[3]
BSI Standard 100-4 Business Continuity Management, v.1.0. Federal Office for Information
Security, Bonn, 2009
[4]
Vnos . 312/2010 Z.z. Ministerstva financi Slovenskej republiky o tandardoch pre

informan systmy verejnej sprvy
[5]
Metodick pokyn Ministerstva financi Slovenskej republiky . MF/23579/2011-165 k

vnosu Ministerstva financi Slovenskej republiky z 9. jna 2010 . 312/2010-132 Z. z. o
tandardoch pre informan systmy verejnej sprvy
[6]
Zkon . 45/2011 Z.z. o kritickej infratruktre
[7]
Zkon . 122/2013 Z. z. o ochrane osobnch dajov a o zmene a doplnen niektorch

zkonov
[8]
Vyhlka radu na ochranu osobnch dajov z 13. jna 2013 o rozsahu a dokumentcii
bezpenostnch opatren
[9]
ISO 22301 Societal security Business continuity management systems --- Requirements
[10] ISO/IEC 27001 Information technology -- Security techniques -- Information security

management systems -- Requirements
[11] ISO/IEC 27002 Information technology Security techniques Code of practice for
information security controls
[12] ISO/IEC 27008 Security techniques -- Guidelines for auditors on information security
management systems controls
[13] ISO/IEC 27031 Information technology Security techniques Guidelines for
information and communication technology readiness for business continuity
[14] BS 25999 - Business Continuity Management
[15] NIST Special Publication 800-34 Rev. 1 - Contingency Planning Guide for Federal
Information Systems
318
11.5 Prlohy
V tejto asti uvdzame truktru plnov kontinuity innost a plnov obnovy odporan poda
metodiky KPMG [1], ktor vychdza zo tandardov [3], [14] a [15]. Kapitola alej obsahuje rmcov
typy testov aknch plnov. Plny by mali obsahova, respektve aspo rmcovo upravova
nasledovn:
11.5.1 Plny kontinuity innost
daje o dokumente plnu
Kto pln vytvoril
Kto pln schvlil
Vlastnk plnu / osoba zodpovedn za jeho aktualizciu
Distribcia a umiestnenie plnu (ktor osoby k plnu maj prstup a kde s umiestnen jeho
elektronick a papierov kpie)
Referencie na in dokumenty
daje o procese
daje o procese, ktorho sa pln tka.
Popis procesu vychdzajci z informci zskanch v rmci analzy dopadov a analzy rizk, t.j.
vstupy, jednotliv aktivity a vstupy procesu.
Vlastnk procesu a jeho zstupcovia (nzov funkcie aj men).
Parametre procesu zskan v rmci analzy dopadov MTO, RTO a RPO.
Zdroje a prostriedky potrebn pre proces - aplikcie/informan systmy, technick prostriedky a

infratruktra, daje, udsk zdroje, lokality, tretie strany a pod.
Pravidl aktivcie plnu

Popis kritri, ktor musia by splnen na aktivciu plnu a urenie osoby alebo osb s prvomocou
rozhodn o aktivcii plnu.
Popis scenru/scenrov
Vymenovanie a strun popis scenrov, na ktor sa pln kontinuity innost vzahuje. Prklady
scenrov:
Nedostupnos aplikcie softvrov aplikcia pouvan v rmci procesu nie je dostupn. Nie je
pri tom dleit, i je problm v samotnej aplikcii alebo na niej rovni chyba databzy,
operanho systmu alebo hardvrov chyba.
Obmedzenie funknosti aplikcie s aplikciou sa d pracova, ale nie je plne funkn. Niektor
moduly a funkcionality s dostupn a niektor nie.
Nedostupnos budovy pracovn priestory s nepouiten naprklad z dvodu poiaru, alebo

musia by evakuovan naprklad kvli hrozbe bombovho toku.
Vpadok podpornch sluieb (elektrina, voda, krenie)
Vpadok sluieb dodvatea extern dodvka sluieb dodvatea nie je mon, naprklad kvli
incidentu na strane dodvatea.
Nedostupnos udskch zdrojov osoba a lebo osoby vykonvajce procesy nie s k dispozcii
naprklad kvli prceneschopnosti.
319
Pre niektor z uvedench scenrov mu plny kontinuity innost pokrva viac procesov.
Naprklad pre scenr nedostupnos lokality je pripraven jeden pln, ktor pokryje vetky procesy
vykonvan v danej lokalite namiesto niekokch individulnych plnov pre jednotliv procesy.
Takto pln mus primerane reflektova prioritu procesov.
Obmedzenia a predpoklady
Popis obmedzen plnu, ktor nie s pokryt naprklad vskyt kombincie scenrov. Popis
predpokladov potrebnch pre vkon plnu naprklad dostupnos kvalifikovanho personlu,
dostupnos komunikanch sluieb a pod.
Prpravn lohy
Vymenovanie a popis aktivt, ktor maj by vykonan pred tm, ako je pln pouit pri realizcii
scenra. Me s o jednorazov ako aj opakovan a kontinulne aktivity. Prklady prpravnch loh:
Zabezpeenie nhradnch priestorov
Zabezpeenie nhradnej techniky
Prprava internej a externej komunikcie
Dohodnutie SLA s dodvateom
Aktvny monitoring
Kad loha mus ma priraden osobu zodpovedn za jej vykonanie alebo vykonvanie.
Identifikcia problmu
Popis stavu, situcie alebo udalosti, ktor indikuj, e nastal negatvny scenr a e m by
aktivovan prslun pln kontinuity innost. Prklady monost identifikcie problmu:
Automatick notifikcie technickch prostriedkov
Identifikcia zamestnancami IT oddelenia
Hlsenie dodvatea
Identifikcia pouvatemi (zamestnancami)
Identifikcia zkaznkmi
Kvli efektvnej komunikcii a vyhnutiu sa duplicitnm hlseniam je dleit uri kontaktn osoby,
ktor bud dan stav alebo udalosti hlsi. Naprklad vedci oddelenia alebo jeho zstupca hlsi
vpadok aplikcie za cel oddelenie, namiesto individulnych hlsen kadho zamestnanca
oddelenia.
Fza reakcie
Popis aktivt, ktor maj by vykonan bezprostredne po identifikcii problmu. Tieto aktivity s
zrove popisovan v inej asti tudijnch materilov kurzu - riadenie bezpenostnch incidentov.
Prklady:
Informovanie relevantnch osb - vlastnk procesu alebo inch svisiacich aktv, manar IB
Potvrdenie scenra
Aktivcia krzovho riadenia
Aktivcia svisiaceho havarijnho plnu
Rozhodnutie o alternatvnom procese
Informovanie alch osb - kontaktn centrum, intern pouvatelia
320
Alternatvne innosti
Alternatvne spsoby vkonu procesu (ak existuj) vykonvan poas doby obnovy a do obnovenia
plnej prevdzky. Prklady alternatvnych innost:
Realizcia procesu v alternatvnych priestoroch
Prca z domu
Realizcia procesu nhradnm personlom
Pouitie kancelrskeho softvru namiesto aplikcie
Manulne spracovanie dajov namiesto automatizovanho
Informovanie o vpadku na web strnke, prostrednctvom kontaktnho centra, na socilnych

sieach
Obnovovacie postupy
Aktivity smerujce k obnoveniu plnej prevdzky procesu. Prklady:
Aktivcia a realizcia svisiaceho havarijnho plnu
Obnova dajov zo zlohy
Retart IKT systmov
Realizcia krokov, ktor nie s uveden v havarijnom plne
Obnova zdrojov a prostriedkov pre ktor neexistuje havarijn pln
Obnova v spoluprci s dodvateom
Kontroln lohy
Aktivity vykonvan pred prechodom do plnej prevdzky na zskanie primeranho uistenia, e bola
obnova spen. Prklady kontrolnch loh:
Kontrola dostupnosti a funknosti IKT systmov
Kontrola obnovy a aktulnosti dajov
Kontrola dostupnosti priestorov
Potvrdenie dostupnosti personlu
lohy po obnoven
Aktivity upratovacieho charakteru, ktor je mon vykona a po obnoven, respektve nie je
nevyhnutn ich vykona v rmci obnovy. Prklady loh po obnoven:
Vysporiadanie sa s dajmi, ktor nemohli by spracovan poas vpadku alebo boli

spracovanmi alternatvnym spsobom
Odstrnenie informcie o vpadku z web strnky, kontaktnho centra
Informovanie relevantnch osb vlastnk procesu, manar IB
Kontaktn daje
Telefonick a emailov kontakty na vetky osoby uveden v plne.
321
11.5.2 Plny obnovy

daje o dokumente plnu
Kto pln vytvoril
Kto pln schvlil
Vlastnk plnu / osoba zodpovedn za jeho aktualizciu
Distribcia a umiestnenie plnu (ktor osoby maj k plnu prstup a kde s umiestnen jeho
elektronick a papierov kpie)
Referencie na in dokumenty
daje o zdroji/prostriedku
daje o zdroji/prostriedku, ktorho sa pln tka.
Popis zdroja/prostriedku vychdzajci z informci zskanch v rmci analzy dopadov a analzy

rizk.
Vlastnk zdroja/prostriedku a jeho zstupcovia (nzov funkcie aj men).
Parametre svisiacich (podporovanch) procesov zskan v rmci analzy dopadov MTO, RTO
a RPO. V prpade, e existuje viac svisiacich procesov s rznymi hodnotami tchto parametrov,
berie sa do vahy najniia hodnota parametra.
Stratgia obnovy uren pre zdroj/prostriedok v rmci fzy plnovania.
Pravidl aktivcie plnu

Popis kritri, ktor musia by splnen na aktivciu plnu a urenie osoby alebo osb s prvomocou
rozhodn o aktivcii plnu.
Popis scenru/scenrov
Vymenovanie a strun popis scenrov obnovy, ktor s rieen v rmci havarijnho plnu. Prklady
scenrov:
Obnova konfigurcie aplikcie/databzy/operanho systmu
Optovn intalcia aplikcie/ databzy/ operanho systmu
Vmena hardvrovho komponentu
Optovn intalcia celho hardvru
Obmedzenia a predpoklady
Popis obmedzen plnu, ktor nie s pokryt a popis predpokladov potrebnch pre vkon plnu
naprklad dostupnos kvalifikovanho personlu, dostupnos vhodnch priestorov, dostupnos
komunikanch sluieb a pod.
Prpravn lohy
Vymenovanie a popis aktivt, ktor maj by vykonan pred tm, ako je pln pouit pri realizcii
scenra. Me s o jednorazov ako aj opakovan a kontinulne aktivity. Prklady prpravnch loh:
Udriavanie konfiguranej databzy
Zlon kpia (image) informanho systmu
Zabezpeenie nhradnho hardvru

322
Dohodnutie SLA s dodvateom hardvru
Aktvny monitoring
Kad loha mus ma priraden osobu zodpovedn za jej vykonanie alebo vykonvanie.
Identifikcia problmu
Popis stavu, situcie alebo udalosti, ktor indikuj, e dolo k vpadku a e m by aktivovan
prslun havarijn pln. Prklady monost identifikcie problmu:
Aktivcia havarijnho plnu z nadradenho plnu kontinuity innosti
Automatick notifikcie technickch prostriedkov
Identifikcia zamestnancami IT oddelenia
Hlsenie dodvatea
Identifikcia pouvatemi (zamestnancami)
Identifikcia zkaznkmi
Kvli efektvnej komunikcii a vyhnutiu sa duplicitnm hlseniam je dleit uri kontaktn osoby,
ktor bud dan stav alebo udalosti hlsi. Naprklad vedci oddelenia alebo jeho zstupca hlsi
vpadok aplikcie za cel oddelenie, namiesto individulnych hlsen kadho zamestnanca
oddelenia.
Fza reakcie
Popis aktivt, ktor maj by vykonan bezprostredne po identifikcii problmu. Tieto aktivity s
zrove popisovan v inej asti tudijnch materilov kurzu - riadenie bezpenostnch incidentov.
Prklady:
Informovanie relevantnch osb - vlastnk aktva, manar IB
Potvrdenie problmu
Vber scenra obnovy
Obnovovacie postupy
Aktivity smerujce k obnoveniu zdroja/prostriedku poda zvolenho scenra. Prklady:
Obnova konfigurcie aplikcie/databzy/operanho systmu
Optovn intalcia aplikcie/ databzy/ operanho systmu
Vmena hardvrovho komponentu
Optovn intalcia celho hardvru
Kontroln lohy
Aktivity vykonvan pred prechodom do plnej prevdzky na zskanie primeranho uistenia, e bola
obnova spen. Prklady kontrolnch loh:
Kontrola dostupnosti a funknosti IKT systmov
Kontrola obnovy a aktulnosti dajov
lohy po obnoven
323
Aktivity upratovacieho charakteru, ktor je mon vykona a po obnoven, respektve nie je

nevyhnutn ich vykona v rmci obnovy. Prklady loh po obnoven:
Vysporiadanie sa s dajmi, ktor nemohli by spracovan poas vpadku
Informovanie relevantnch osb vlastnk procesu, manar IB
Kontaktn daje
Telefonick a emailov kontakty na vetky osoby uveden v plne.
11.5.3 Typy testov aknch plnov
Na testovanie aknch plnov existuj rzne typy a varicie testov. Typy testov uveden v tejto
kapitole mono povaova za generick prstupy. Realizciu konkrtneho testu v praxi treba
prispsobi predmetu testovania, okolnostiam a charakteru organizcie.
Test od stola (angl. Desk check)
Preverenie aktulnosti dajov v plne a prpadne ich doplnenie alebo oprava.
Zloitos:
nzka
Odporan frekvencia: rone
astnci:
manar IB
Rekapitulcia (angl. Walk-through)
Teoretick prejdenie aknho plnu bod po bode bez jeho skutonej realizcie. Diskusia o
jednotlivch bodoch plnu medzi astnkmi testu s cieom poukza na nezrovnalosti a kritick
asti aknho plnu.
Vzhadom na teoretick realizciu testu je potrebn, aby osoba, ktor test vedie (napr. BCM
koordintor) na zaiatku vysvetlila vetky zjednoduenia a nhrady (napr. kto reprezentuje osoby
a subjekty, ktor sa na teste nezastuj, ale s uveden v plne).
Zloitos:
nzka
Odporan frekvencia: rone
astnci:
manar IB a osoby definovan v aknom plne
Simulcia
astnci testu vykonvaj vetky aktivity popsan v aknom plne, avak v pripravenom umelom
prostred, napr. mimo benho pracovnho asu, v nhradnej lokalite a s informanmi systmami
v testovacom prostred bez pouitia produknch dajov. Podobne ako pri rekapitulcii je potrebn
vysvetli vetky zjednoduenia a nhrady.
Zloitos:
stredn
Odporan frekvencia: raz za 1 - 2 roky
astnci:
Testovanie vybranch kritickch aktivt
Popis
Realizuje sa podobne ako test plnu v plnom rozsahu v "ostrom" prostred, ale niektor aktivity s
vynechan, respektve zrealizovan v testovacom prostred (napr. interakcia s treou stranou).
Zloitos:
stredn
Odporan frekvencia: raz za 2 3 roky
astnci:
Realizcia aknho plnu v plnom rozsahu
Popis
Realizcia plnu v plnom rozsahu, t.j. vykonanie vetkch krokov poda plnu v "ostrej" prevdzke.
Pln sa iniciuje napr. vyhlsenm nedostupnosti budovy, vypnutm informanho systmu alebo
324
odpojenm dodvky elektrickej energie. Poda cieu testu astnci mu aj nemusia by informovan
o tom, e sa jedn o test.
Zloitos:
vysok
Odporan frekvencia: raz za 2 3 roky
astnci:
manar IB a vetci zamestnanci ovplyvnen vpadkom
325
12 Legislatva a etika
Ivan Oravec a Jozef Stanko
12.1 vod
Ochrana informci a IKT, prostrednctvom ktorch sa tieto informcie spracovvaj, prenaj
alebo v nich ukladaj, si okrem tandardizcie a technickch noriem vyaduje aj ochranu na rovni
legislatvy Eurpskeho spoloenstva a zrove aj na rovni legislatvy prslunch ttov. Vhodn
a efektvny prvny rmec je prvm nutnm a kovm, nie vak postaujcim, predpokladom
zabezpeenia primeranej ochrany prv jednotlivca a organizci, i u skromnho alebo verejnho
sektora.
A na zklade tohto rmca meme poveda, e prpadn zneuitie IKT je protiprvne a zrove
meme v takomto prpade zasiahnu a vyvodi zodpovednosti a prslun sankcie. Prve mon
sankcie definovan v prslunom prvnom rmci mu psobi aj ako odradzujci inok pre
potencilnych tonkov od budcich pokusov o naruenie alebo zneuitie IKT. Legislatva
Slovenskej republiky vak nie je zameran len na potlanie kriminality pouitm trestnho zkona
a trestnho poriadku, ale definuje tie konkrtne podmienky tandardizcie informanej bezpenosti
a riadenia bezpenosti informanch a komunikanch technolgi digitlneho priestoru. Tieto
podmienky ozrejmuj prva a povinnosti pouvateov, prevdzkovateov a sprostredkovateov
sluieb.
V slade s uvedenmi skutonosami je tto kapitola rozdelen do troch zkladnch ast. elom
prvej asti je identifikcia definci, prv, povinnost a prpadnch sankci vyplvajcich zo
veobecnej legislatvy, tkajcej sa informanej bezpenosti ako takej, ktor vyplvaj z trestnho
zkona, trestnho poriadku a autorskho zkona.
Druh as je zameran na pecializovan legislatvu, ktor vo vej alebo menej miere
(v zvislosti od konkrtneho prvneho predpisu a oblasti, ktor pokrva) u priamo riei
a tandardizuje aj problematiku informanej bezpenosti v jej prslunch oblastiach. Ide najm
o predpisy tkajce sa informanch systmov verejnej sprvy, ochrany osobnch dajov a kritickej
infratruktry.
V rmci tretej asti s vymenovan niektor pecifick prvne predpisy, ktor u netandardizuj
problematiku IB a riadenia IB ako tak, ale obsahuj urit prvky a poiadavky na pouvateov a
prevdzkovateov, i u z pohadu zabezpeenia IB alebo z pohadu riadenia IB. Ide najm
o predpisy tkajce sa elektronickho podpisu, ochrany utajovanch skutonost, elektronickho
obchodu, elektronickch komunikci a poskytovania zdravotnej starostlivosti.
Okrem uvedench troch zkladnch asti je predmetom tejto kapitoly aj prehad legislatvy E,
ktor ma rovnako vzah a svis s informanou bezpenosou.
V samostatnch astiach s zrove popsan aj in tmy svisiace s legislatvou ohadom
informanej bezpenosti, prpadne s etickmi a morlnymi princpmi. Ide najm o popis vzahu
medzi ochranou skromia zamestnanca a prvami zamestnvatea v svislosti s monitorovanm
innost zamestnanca na pracovisku, popsanie spsobu implementcie legislatvnych predpisov do
internej legislatvy organizcie a o problematiku etiky, etickch princpov a morlnych kdexov.
Posledn dve asti sa venuj problematike verejnho obstarvania a jeho previazania s IB a forenznej
analze.
Pri jednotlivch relevantnch astiach ku konkrtnemu legislatvnemu predpisu sme sa snaili
zvrazni zkladn prva a povinnosti tkajce sa jednotlivca (vo veobecnosti pouvatea IS)
a zkladn prva a povinnosti organizcie (vo vine prpadoch sprvcu alebo prevdzkovatea IS).
326
Legislatva a etika | MF SR
12.2 Prehad veobecnej legislatvy vzahujcej sa na IB

Technologick pokroky a rozrenie Internetu mu spsobova nekonzistencie v prvnych pravch
jednotlivch ttov. tandardizciu zabezpeuj na najvyej rovni medzinrodn zmluvy. Jednou
z komplikci, ktor je potrebn riei pri vytvran prvnych predpisov v tejto oblasti je definovanie
hmotnch pravidiel pre aksi virtulnu sie, kee pojmy pouvan v informanej bezpenosti
podliehaj uritej virtulnosti a teda nemaj charakter fyzickho prvku, pokia ide o normatvne
prvne akty, medzinrodn zmluvy a prvne predpisy, prvne predpisy komunitrneho prva
a normatvne prvne akty vntrottnej povahy [2]
Rovnako psobnos a kompetencie jednotlivch ttov, resp. prslunch orgnov innch
v trestnom konan je geograficky obmedzen, o vo virtulnom svete nie je mon zabezpei. Aj
napriek skutonosti, e napr. 10 ods. 9 Trestnho poriadku definuje monos vytvorenia spolonho
medzinrodnho vyetrovacieho tmu, uri geografick miesto inu vo virtulnom svete,
a geografick miesto odkia bol tento in spchan a jeho jednoznan priradenie konkrtnym
orgnom konkrtnej krajiny, je v sasnosti vo vine prpadov nemon loha. Prve tento aspekt
bude urite vekou vzvou blzkej budcnosti pre vetkch prvnikov a legislatvcov zaoberajcich
sa kriminalitou a trestnmi inmi v kybernetickom priestore, nie len v rmci Slovenskej republiky,
ale urite aj v rmci E a celho sveta.
Jednotliv prvne normy s rozdelen do rznych prvnych odvetv. Pokia ide o internetov prvo,
najviac definci, pojmov a prvnych vzahov vo veobecnej rovine mono njs v obianskom
prve. Obianske prvo vak neobsahuje zvltnu as, ktor by vymedzovala konkrtne aktivity na
internete. Obiansky zkonnk definuje pojmy ako spsobilos k prvnym konom, alebo inm
prvnym skutonostiam, zkladn prva a povinnosti, charakteristiku obiansko-prvnych vzahov
a zkladn princpy obianskeho prva, napr. ochrana dobrej viery, ochrana prv tretch osb, alebo
tie zsadu, e vetko o je dovolen, nie je zakzan. Dleit rolu dnes maj aj individulne
prvne akty, najm judikatra Najvyieho sdu Slovenskej republiky, ale aj judikty sdov E,
ktor aplikciou na konkrtne prklady z praxe osvetuj a interpretuj prvne normy obsiahnut
v normatvnych aktoch. Lepiu prvnu pravu informanej bezpenosti vak njdeme v Trestnom
prve, pod ktor spad trestn zkon a trestn poriadok a v autorskom zkone. S v nich obsiahnut
najm prvne vzahy svisiace s potaovmi programami, licenn zmluvy tkajce sa softvru,
defincia osoby s prvami k rozmnoenine potaovho programu a pod. [2].
12.2.1 Trestn zkon a trestn poriadok
12.2.1.1 Prehad a psobnos
Trestn prvo, do ktorho mono zahrn trestn zkon a trestn poriadok vo veobecnosti uruje
druh a vku trestov za (predovetkm) myseln a spoloensky kodliv iny. Trestn prvo vak
rozliuje aj trestn iny z nedbanlivosti.
Trestn zkon (zkon . 300/2005 Z. z. trestn zkon v znen neskorch predpisov) sa zaober tzv.
hmotnm trestnm prvom, ktor hovor, ak konanie je trestn, ak sankcie je mon vyvodi
z takhoto konania a ak opatrenia mono poui proti pchateom trestnch inov. Trestn zkon
upravuje podmienky pre vyvodenie trestnej zodpovednosti, druhy trestov, druhy ochrannch
opatren, ukladanie trestov a definuje skutkov podstaty trestnch inov.
Trestn poriadok (zkon . 301/2005 Z. z. trestn poriadok v znen neskorch predpisov), na rozdiel
od trestnho zkona riei najm tzv. procesn rmec. Definuje postupy orgnov innch v trestnom
konan pri vyetrovan trestnch inov a tie prva a povinnosti osb, ktor sa na trestnom konan
zastuj.
asov psobnos
Medzi zkladn atribty pri ukladan trestov za spchan iny sa povauje tzv. asov psobnos,
ktor hovor, e trestnos inu sa posudzuje poda zkona innho v ase, kedy bol in spchan.
327
Pokia od asu, kedy bol trestn in spchan do asu, kedy sa vyna rozsudok nadobudn innos
viacer zkony, trestnos inu sa posudzuje poda toho zkona, ktor je pre pchatea priaznivej.
zemn psobnos
Trestn zkon je mon vyui iba pre posudzovanie trestnho inu spchanho na zem Slovenskej
republiky, alebo aspo iastone spchanho na zem Slovenskej republiky, a tie spchanho na
palube lode, alebo lietadla so ttnou vlajkou Slovenskej republiky. Prpadne sa me jedna
o trestn in ohrozujci zujmy chrnen tmto zkonom.
Osobn psobnos
Pri postihovan trestnch inov sa me jedna bu o pchatea, ktor je obanom Slovenskej
republiky, alebo m na zem Slovenska trval pobyt. Tie sa pouva pri postihovan trestnho inu,
ktor je spchan proti obanovi Slovenskej republiky a to aj v prpade, ak je v mieste spchania inu
tento in trestn a aj v prpade, ak v mieste jeho vykonania nepodlieha iadnemu postihu
vyplvajcemu z miestneho zkona.
Druhy trestnch inov
Z pohadu zkladnej klasifikcie trestnch inov meme hovori o preine, zloine a obzvl
zvanom zloine.
Prein je trestn in spchan z nedbanlivosti. Ide o in, ktorho trest je poda tohto zkona
ustanoven na odatie slobody na menej ako 5 rokov.
Zloin je tak trestn in, ktor bol spchan myselne a je poda tohto zkona potrestan odatm
slobody na viac ako 5 rokov.
Za obzvl zvan zloin sa povauje tak zloin, ktor je poda ustanovenia tohto zkona
potrestan odatm slobody s dolnou hranicou sadzby 10 rokov.
Miesto spchania trestnho inu
Za miesto spchania trestnho inu sa povauje kad miesto, na ktorom pchate konal, nastal
v om, alebo poda predstavy pchatea mal nasta trestn in predpokladan tmto zkonom.
Prprava na zloin
Prprava na zloin zaha tak konanie, ktor spova v organizovan zloinu, zadovaovan
nstrojov na jeho spchanie, v spolovan sa s nebezpenmi skupinami za elom jeho spchania aj
v prpade, ak k nemu nedjde.
Trestnos zanik, ak pchate upustil od alieho konania smerujceho k zloinu, alebo urobil
o prprave na trestn in oznmenie orgnu innmu v trestnom konan, alebo Policajnmu zboru.
Tto trestnos vak v iadnom prpade nezanik, ak bol trestn in u spchan.
Pokus trestnho inu
Pokusom trestnho inu je konanie, ktor priamo smeruje k jeho dokonaniu, ak k nemu v konenom
dsledku nedjde.
Pokus trestnho inu je trestn poda sadzby ustanovenej na dokonan trestn in.
Ustanovenm o trestnosti pokusu o trestn in vak nie je dotknut trestnos inho inu, ktor
pchate tmto pokusom spchal.
328
Zavinenie
Trestn in je spchan myselne, ak pchate chcel spsobom uvedenm v zkone porui, alebo
ohrozi zujem chrnen tmto zkonom, prpadne vedel, e svojim konanm me tak poruenie,
alebo ohrozenie spsobi.
Trestn in je spchan z nedbanlivosti, ak si pchate uvedomuje, e svojim konanm me porui,
alebo ohrozi chrnen zujem, ale sa bez primeranch dvodov domnieval, e k takmuto
poruenie/ohrozeniu nedjde. Tie me s o nedbanlivos, ak pchate nevie, e svojim konanm
me spsobi poruenie, alebo ohrozenie, ale by o tom vzhadom na svoje osobn pomery
a okolnosti vedie mohol. Pre trestnos inu je potrebn myseln zavinenie, pokia zkon
neustanov inak.
V prpade ach nsledkov, ktor mohli nasta aj z nedbanlivosti aj z myselnej trestnej innosti sa
povauje tento a nsledok za priaujcu okolnos, alebo za okolnos, ktor vyaduje pouitie
vyej trestnej sadzby.
Pchate, spolupchate a astnk trestnho inu
Pchate je ten, kto trestn in spchal sm. Ak sa na spchan trestnho inu podieaj dve, alebo
viacer osoby, povauj sa za spolupchateov.
astnkom na dokonanom trestnom ine je organiztor, nvodca, objednvate alebo pomocnk.
Organiztor zosnoval spchanie trestnho inu, nvodca naviedol inho na spchanie trestnho inu,
objednvate poiadal inho na spchanie trestnho inu a pomocnk poskytol inmu pomoc, najm
zadovenm prostriedkov odstrnenm prekok, radou, utvrdzovanm v predsavzat, subom
pomc po trestnom ine.
astnk je potrestan rovnakm trestom ako pchate.
Okolnosti vyluujce trestn zodpovednos
Pokia pchate nedovil trnsty rok ivota, nie je trestne zodpovedn. Rovnako nie je trestne
zodpovedn nepretn pchate trpiaci duevnou poruchou, ktor mu znemouje rozpozna
protiprvnos trestnho inu, alebo ovlda svoje konanie.
Shlas pokodenho
in inak trestn je akceptovan ako nie trestn, pokia je vykonan s vnym a dobrovonm
shlasom pokodenho a nie je namieren proti jeho ivotu, alebo zdraviu.
V prpade informanej bezpenosti meme toto znenie aplikova naprklad na spsanie striktnej
zmluvy o bezpenostnom zhodnoten zahajcom napr. penetran testovanie informanch
systmov. V zmluve by malo by stanoven, do akej hbky, v akom rozsahu a v akej maximlnej
agresivite mu by penetran testy preveden.
12.2.1.2 Potaov kriminalita
Na oficilnom webe Ministerstva vntra [3] sa dotame, e:
Pod pojmom potaov kriminalita alebo High-Tech Crime sa skrva vyuvanie informanch
technolgi, najm potaov na pchanie trestnej innosti. Jej rozmach je priamomern
postupujcej informatizcii spolonosti. Eurpske krajiny povauj tto formu trestnej innosti za
jednu z globlnych hrozieb a jednm z nstrojov na jej potieranie je Dohovor o potaovej
kriminalite z 23. novembra 2001. Slovensk republika tento dohovor ratifikovala v roku 2007.
Potaov kriminalitu upravuje najm 247 trestnho zkon, do ktorho s premietnut princpy
Dohovoru o kybernetickom zloine CETS . 185/2001, vydanom Radou Eurpy.
329
Pokodenie a zneuitie zznamu na nosii informci

Poda 247 trestnho zkona sa potrest odatm slobody ten, kto v mysle spsobi inmu kodu
alebo in ujmu alebo zadovi sebe alebo inmu neoprvnen prospech zska neoprvnen prstup
do potaovho systmu, k inmu nosiu informci alebo jeho asti a jeho informcie neoprvnene
pouije, alebo tak informcie neoprvnene zni, pokod, vymae, pozmen alebo zni ich kvalitu,
alebo urob zsah do technickho alebo programovho vybavenia potaa, alebo vkladanm,
prenanm, pokodenm, vymazanm, znenm kvality, pozmenenm alebo potlaenm potaovch
dt mar funknos potaovho systmu alebo vytvra neautentick dta s myslom, aby sa
povaovali za autentick alebo aby sa s nimi takto na prvne ely nakladalo.
Meme kontatova, e tto as zkona upravuje prpady zneuitia informanho systmu
ktoroukovek zo znmych foriem potaovej kriminality. Veobecn formulcia tohto odseku
pokrva vek rozsah potaovej trestnej innosti od distribcie neleglnych kpi softvru a po
sofistikovan formy organizovanho hackingu.
Zrove sa, rovnako ako v predchdzajcom odseku, potrest ten, kto na el spchania inu
uvedenho v predchdzajcom odseku neoprvnene sleduje prostrednctvom technickch
prostriedkov neverejn prenos potaovch dt do potaovho systmu, z neho alebo v rmci
potaovho systmu, alebo zaobstar alebo sprstupn potaov program a in zariadenia alebo
potaov heslo, prstupov kd alebo podobn daje umoujce prstup do celho potaovho
systmu alebo do jeho asti.
Znenie tejto asti 247 trestnho zkona pokrva sledovanie, odpovanie, alebo in techniky
kompromitcie prenosu dt a pokrva aj oblas neoprvnench prstupov do informanch systmov.
V tejto asti trestn zkon oetruje predovetkm neoprvnen innos zneuitia privilgi
a neoprvnen prstup k dtam, ktor s viazan na dotknut osobu v zmysle platnho zkona .
122/2013 o ochrane osobnch dajov, prpadne maj inak kritick charakter poda zkona a ich
kompromitcia predstavuje riziko finannej, alebo hospodrskej straty, prpadne straty renom.
Potae a IKT vo veobecnosti mu by pouit na pchanie irokho spektra trestnej innosti
zahajceho vydieranie, vyhranie, rozirovanie detskej pornografie, pchania drogovej trestnej
innosti, podvodu a pod.
Za neleglnu innos by mali by jej pchatelia aj patrine potrestan, take zkon samozrejme
pamt aj na sankcie v prpade dokzania viny. Ak pchate spcha in uveden v 247 a spsob
nm znan kodu potrest sa odatm slobody na jeden a p rokov. Odatm slobody na tri a
osem rokov sa pchate potrest, ak spchanm inu spsob kodu vekho rozsahu, alebo spcha
tento in ako len nebezpenho zoskupenia. Jednotliv druhy trestnej innosti s samozrejme
ohodnocovan individulne poda platnho trestnho zkona.
12.2.1.3 Neoprvnen nakladanie s osobnmi dajmi
Ochrana osobnch dajov je dnes vemi citlivo vnman tma. Na rovni trestnho zkona je jej
venovan najm 374, ktor sa venuje neoprvnenmu poskytovaniu, sprstupovaniu
a zverejovaniu osobnch dajov a zrove aj sankcim, ktor hrozia v prpade poruenia tohto
ustanovenia zkona. Ten, kto neoprvnene poskytne, sprstupn alebo zverejn osobn daje o inom
zhromaden v svislosti s vkonom verejnej moci alebo uplatovanm stavnch prv osoby, alebo
osobn daje o inom zskan v svislosti s vkonom svojho povolania, zamestnania alebo funkcie a
tm poru veobecne zvznm prvnym predpisom ustanoven povinnos, potrest sa odatm
slobody a na jeden rok. Zrove je mon pchatea potresta odatm slobody a na dva roky, ak
spchanm inom spsob vnu ujmu na prvach dotknutej osoby, prpadne in vykon verejne,
alebo zvanejm spsobom konania.
12.2.1.4 Vyetrovanie a skrten vyetrovanie - Rozsah vyetrovania
Vyetrovanie sa vykonva predovetkm o zloinoch a v pecilnych prpadoch aj o menej
zvanch preinoch. Ak je potrebn vykona vyetrovanie aspo o jednom z trestnch inov,
330
vykon sa vyetrovanie o vetkch trestnch inoch toho istho obvinenho aj proti vetkm
obvinenm, s ktormi trestn iny svisia.
Spolon postup vo vyetrovan nariauje, e kony ktor sa vykonvaj vo vyetrovan vykonva
zodpovedn policajt osobne. Postupuje vo vyetrovan tak, aby o najrchlejie zadovil podklady
na objasnenie skutku v rozsahu potrebnom na posdenie prpadu a zistenie pchatea trestnho inu.
Policajt vykonva vetky kony samostatne v slade so zkonom a vas. Zadovauje dkazy bez
ohadu na to, i svedia v prospech, alebo neprospech obvinenho. Obvinen nesmie by k vsluchu
nezkonne nten.
Na vyetrovanie preinov je mon pristpi k skrtenmu vyetrovaniu. Ak policajt povauje
vyetrovanie, alebo skrten vyetrovanie za skonen a jeho vsledky za postaujce na podanie
nvrhu na obalobu, alebo na in rozhodnutie, umon obvinenmu, obhajcovi, pokodenmu, jeho
splnomocnencovi, alebo opatrovnkovi v primeranej lehote pretudova spisy a poda nvrhy na
doplnenie vyetrovania, alebo skrtenho vyetrovania. Vyetrovanie obzvl zvanch zloinov je
potrebn skoni do iestich mesiacov od vznesenia obvinenia. V ostatnch prpadoch do tyroch
mesiacov.
Obvinen, pokoden a zastnen osoba maj prvo kedykovek v priebehu vyetrovania, alebo
skrtenho vyetrovania iada prokurtora, aby bol preskman postup policajta, najm, aby boli
odstrnen prieahy, alebo in nedostatky vo vyetrovan, alebo skrtenom vyetrovan. Policajt mus
iados bez mekania predloi. Prokurtor je povinn iados preskma a o vsledku iadatea
upovedomi.
12.2.2 Autorsk zkon a oblas duevnho vlastnctva
12.2.2.1 Autorsk prvo a majetkov prvo
Autorsk prvo je upraven autorskm zkonom . 618/2003 Z. z. o autorskom prve a o prvach
svisiacich s autorskm prvom v znen neskorch predpisov (alej len autorsk zkon). Tento
zkon zvyuje prvnu istotu zastnench autorskoprvnych subjektov a dva im viu zmluvn
vonos. Zretene oddeuje autorsk prva od vhradnch majetkovch prv ( 16 autorskho
zkona).
Osobnostnch prv sa autor neme vzda, tieto prva s neprevoditen a smrou autora zanikaj.
Dielo mono po smrti jeho autora poui vdy len spsobom nezniujcim jeho hodnotu a uvedenm
mena autora, pokia nejde o anonymn dielo. Na rozdiel od osobnostnch prv, majetkov prva
trvaj poas ivota autora a ete 70 rokov po jeho smrti. Autor me dielo pouva a udeova inm
osobm oprvnenie na vkon tohto prva.
Zkon upravuje dva typy autorskej zmluvy. Zmluvu o vytvoren diela a licenn zmluvu. Zmluva
o vytvoren diela zavzuje autora vytvori dielo pre objednvatea, avak objednvateovi nevznik
prvo dielo poui. Na el udelenia prv dielo poui sli licenn zmluva. Udelenm licencie je
autor povinn strpie zsah do svojho prva. Existuje monos licenciu udeli bezodplatne, naprklad
na charitatvne ely. V licennej zmluve je potrebn vyhradi spsob, alebo spsoby pouitia diela.
Zkon vyslovene vyluuje, aby bola licenn zmluva vydan na spsob pouitia, ktor v ase
uzatvorenia zmluvy ete nie je znmy.
Osobitn ustanovenia zahaj majetkov prva pre zamestnaneck dielo. Majetkov prva
k zamestnaneckmu dielu vlastn zamestnvate, ak nie je dohodnut inak. Zamestnvate me
prvo vkonu majetkovch prv postpi tretej osobe len so shlasom autora. Toto neplat, ak ide
o predaj podniku, alebo samostatnej organizanej zloky podniku.
Osobnostn prva sa zamestnvateovi ako autorovi zachovvaj, ale jeho majetkov prva
vykonva zamestnvate vo vlastnom mene a na vlastn et, v prpade, e sa zamestnanec
a zamestnvate nedohodli inak. Tento in prpad by bol naprklad, ak by zamestnanec
a zamestnvate podpsali zmluvu o tom, e zamestnanec bude uvdza vytvoren dielo na verejnosti
pod vlastnm menom.
331
V tejto svislosti sa napr. potaov program, ktor nie je spolonm dielom, povauje za
zamestnaneck dielo aj vtedy, ak bolo celkom, alebo sasti vytvoren na zklade zmluvy o vytvoren
diela. V tomto prpade sa objednvate povauje za zamestnvatea. Odstpenm od zmluvy
o vytvoren diela zanik aj prvo vykonva majetkov prva autora.
pecifick asti tkajce sa ochrany duevnho vlastnctva vak njdeme aj v 281, 282 a 283
trestnho zkona. Ide najm o poruovanie prv k ochrannej znmke, k oznaeniu pvodu vrobku
a k obchodnmu menu, poruovanie priemyselnch prv a poruovanie autorskho prva.
Poruovanie prv k ochrannej znmke, oznaeniu pvodu vrobku a obchodnmu menu
Tto as trestnho zkona (281) oetruje najm distribciu falone oznaench kpi originlnych
tovarov. Ten, kto uvedie do obehu tovar alebo poskytne sluby neoprvnene oznaen oznaenm
zhodnm alebo zamenitenmi s ochrannou znmkou, ku ktorej prvo pouva ju patr inmu,
potrest sa odatm slobody a na tri roky. Rovnako sa potrest ten, kto na dosiahnutie
hospodrskeho prospechu uvedie do obehu tovar neoprvnene oznaen oznaenm zhodnm alebo
zamenitenm so zapsanm oznaenm pvodu vrobku a zemepisnm oznaenm vrobku, ku
ktormu prvo pouva ho patr inmu, alebo neoprvnene pouije oznaenie zhodn alebo
zameniten s obchodnm menom alebo nzvom prvnickej osoby alebo fyzickej osoby.
Sankcie za tento in sa pohybuj a vo vke troch rokov pri menej zvanch, alebo vo vke tri a
osem rokov pri zvanch kodch spsobench tmto trestnm inom.
Poruovanie priemyselnch prv
Na prpady najm neoprvnench zsahov do softvrovch patentov, dizajnu, alebo topografie
elektronickho potaovho systmu (patentovan elektronick zariadenia, potae, smartfny,
technolgie a pod.) pamt 282 trestnho zkona. Odatm slobody sa potrest ten, kto
neoprvnene zasiahne do prv k patentu, itkovmu vzoru, dizajnu, alebo topografii
polovodiovho vrobku.
Sankcie odatia slobody sa pohybuj v rozmedz jeden rok a p rokov pri zvanch kodch.
V prpade kd vekho rozsahu alebo ak bol pchate len nebezpenho zoskupenia je mon
uloi trest a vo vke tri a osem rokov.
Poruovanie autorskho prva
Paragraf 283 trestnho zkona oetruje problematiku zneuitia a poruovania autorskch prv k dielu
vo veobecnosti, najm umeleck diela, zvukov a obrazov zznamy, ale aj softvrov diela, resp.
produkty ako tak, ale zrove s legislatvne oetren aj prpady zneuitia masmdi pomocou IKT
pre renie potencilne nebezpench poplanch sprv, ako sme tomu boli svedkami v eskej
republike v roku 2007. Vtedy medilna skupina s nzvom Ztohoven uskutonila vstup na jeden
z vysielaov pouvanch eskou televziou a zneuila jednu z kamier pouvanch pre iv prenos
z Krkono. V rannom vysielan sa vtedy na T2 v relcii Panorma odvysielal fiktvny vbuch
atmovej bomby s panormou Krkono na pozad. asto sa tento akt uvdzal ako hacking
vysielania eskej televzie. Mnoho divkov bolo okovanch. Bolo podan trestn oznmenie pre
renie poplanej sprvy, ktor ale sudca nepotvrdil. Za tento skutok bola skupina paradoxne ocenen
vznamnou cenou Nrodnej Galrie.
Ak by bol tento skutok spchan dnes na zem SR, tak by sa pchate pravdepodobne trestu
nevyhol. Klasifikcia tohto inu a aj prpadn sankcia, ktor je mon za tento in uloi, je totito
uveden priamo v spomenutom 283 trestnho poriadku, poda ktorho ten, kto neoprvnene
zasiahne do zkonom chrnench prv k dielu, umeleckmu vkonu, zvukovmu zznamu alebo
zvukovo-obrazovmu zznamu, rozhlasovmu vysielaniu alebo televznemu vysielaniu alebo
databze, potrest sa odatm slobody. V praxi je skutok poda tohto paragrafu postihnuten
odatm slobody a na dva roky. Pri zvanejom spsobe konania, alebo vej kode je takto in
postihnuten odatm slobody na es mesiacov a tri roky a pri spsoben znanej kody me
332
djs k odatiu slobody na jeden a p rokov. V prpade, ak je poruenie tohto zkona inom
viacerch osb v rmci nebezpenho zoskupenia, potrest sa odatm slobody na tri a osem rokov.
12.2.2.2 Rozmnoovanie a prava potaovho programu
Na rozmnoovanie a pravu potaovch programov sa vzahuje autorsk prvo v plnom rozsahu.
Zdroj [4] uvdza, e:
Prvna ochrana potaovch programov, ktor s vsledkom tvorivej duevnej innosti autorov programtorov, vychdza aj u ns predovetkm z autorskho prva.
...
Predmetom ochrany autorskho prva vak neme by to, o objektvne existuje nezvisle od
loveka, resp. nieo, k omu mu dospie nezvisle viacer autori. Predmetom ochrany preto nie je
sama mylienka, ale je to prve tvoriv spracovanie tejto mylienky.
...
Ak s pri konkrtnom potaovom programe splnen pojmov znaky diela v zmysle autorskho
zkona, autorsk zkon mu poskytuje absoltnu ochranu, ktor psob proti vetkm tretm osobm.
V alom texte sme sa zamerali predovetkm na relevantn asti autorskho zkona tkajce sa
autorskho diela vo forme softvru.
Rozmnoovanie a prava potaovho programu
Poda 35 autorskho zkona me oprvnen uvate rozmnoeniny potaovho programu bez
shlasu autora vyhotovi rozmnoeninu tejto rozmnoeniny potaovho programu alebo vykona
na nej pravu alebo preklad, ak je takto rozmnoenina, prava alebo preklad nevyhnutn na
prepojenie potaovho programu s potaom na el a v rozsahu, na ktor bol nadobudnut,
vrtane oprv chb v potaovom programe, alebo na nahradenie oprvnene nadobudnutej
rozmnoeniny potaovho programu (zlon rozmnoenina). Inak povedan, ide najm
o vyhotovenie kpie alebo dtovho obrazu u vytvorenho potaovho programu na ely jeho
pouvania. Takisto je celkom leglne vyhotovenie zlonej kpie, ktor zostane vo vlastnctve
oprvnenho pouvatea. Toto prvo nemono vyli v licennch podmienkach pre jeho
pouvanie (poda odseku 4 tohto paragrafu).
Oprvnen uvate rozmnoeniny potaovho programu me bez shlasu autora preskma,
pretudova alebo preska funknos potaovho programu s cieom uri mylienky alebo
princpy, ktor s zkladom akejkovek asti programu, a to poas nahrvania, zobrazovania,
vysielania, overovania funknosti a ukladania programu do pamte, na ktor bol oprvnen.
Tto as zkona teda dva priestor potencilnym pokusom o reverzn ininierstvo existujceho
softvru, pokia ho vykonva oprvnen uvate. Takto vyhotoven rozmnoenina vak nesmie by
ren alej. Ak sa alie pouitie rozmnoeniny potaovho programu stane neoprvnenm,
kad takto rozmnoenina, prava alebo preklad sa mus znehodnoti.
Uveden prvo zrove nemono zmluvne vyli a v uvedench prpadoch nevznik povinnos
uhradi autorovi odmenu.
Sptn preklad potaovho programu zo strojovho kdu do zdrojovho jazyka
potaovho programu
Paragraf 36 autorskho zkona definuje podmienky pravy softvrovho produktu pre vlastn
potrebu a reverznho ininierstva. Shlas autora sa nevyaduje na vyhotovenie rozmnoeniny kdu
potaovho programu alebo prekladu jeho formy, ak je to nevyhnutn na zskanie informcie
potrebnej na dosiahnutie vzjomnej sinnosti nezvisle vytvorench potaovch programov s
inmi potaovmi programami, ak tto innos vykonva oprvnen uvate rozmnoeniny
potaovho programu, alebo informcia nevyhnutn na dosiahnutie vzjomnej sinnosti nebola
predtm bene dostupn osobm oprvnenm na rozmnoovanie alebo preklad, alebo sa tieto
innosti dotkaj iba asti potaovho programu a s nevyhnutn na dosiahnutie vzjomnej
sinnosti nezvisle vytvorench potaovch programov.
333
Informciu zskan poda predchdzajceho odseku nemono poui na dosiahnutie inho ciea, ako
je dosiahnutie vzjomnej sinnosti nezvisle vytvorench potaovch programov, nemono ju
poskytn inm osobm okrem takho pouitia, ktor je nevyhnutn na zabezpeenie vzjomnej
sinnosti nezvisle vytvorench potaovch programov, nemono ju poui ani na zabezpeenie
vvoja, vroby alebo na obchodovanie s potaovm programom, ktor je podobn vo svojom
vyjadren a rovnako ju nie je mon poui na innos, ktorou by sa poruilo prvo autora.
Shlas autora na uveden innosti sa vyaduje na vyhotovenie rozmnoenn potaovch
programov, ak by takto vyhotovenie rozmnoenn bolo v rozpore s riadnym vyuvanm
potaovho programu alebo by bezdvodne zasahovalo do prvom chrnench zujmov autora
potaovho programu. Vyhotovenie rozmnoeniny strojovho kdu potaovho programu alebo
preklad jeho formy nemono zmluvne vyli. Znamen to, e ak pokroilmi technikami
reverznho ininierstva odkoprujeme strojov kd aplikcie a budeme schopn jeho as iastone
previes do kdu vyieho jazyka, neporuili sme tm iaden paragraf autorskho zkona. Je vak
nutn myslie na odsek 2 psm. c) citovanho paragrafu, v ktorom sa uvdza, e s takto
modifikovanm programom nemono obchodova a nemono ho pouva, ak el tohto ponania
je v rozpore s platnmi licennmi podmienkami pre pouvanie tohto softvru.
12.2.3 alie prva a povinnosti organizcie poda veobecnej legislatvy
Vyetrovanie trestnej innosti
Zkladn prva a povinnosti organizcie pri zisovan a vyetrovan trestnej innosti, ktorej bola
obeou, alebo takej, ktor spchali zamestnanci pomocou IKT prostriedkov organizcie s
definovan v 3 Trestnho poriadku.
V slade s ods. 1 3 Trestnho poriadku s ttne orgny, vyie zemn celky, obce a in prvnick
osoby a fyzick osoby povinn poskytn sinnos orgnom innm v trestnom konan a sdu pri
plnen ich loh, ktor svisia s trestnm konanm.
Poda znenia odseku 2 uvedenho paragrafu je organizcia povinn bez mekania oznamova
orgnom innm v trestnom konan skutonosti nasvedujce tomu, e bol spchan trestn in
a vas vybavova doiadania orgnov innch v trestnom konan a sdov.
Pouitie ITP prostriedkov
V prpade pouitia informano-technickch prostriedkov s v slade s 10 ods. 20 prevdzkovatelia
verejnch telefnnych siet, poskytovatelia elektronickch telekomunikanch siet, poskytovatelia
elektronickch telekomunikanch sluieb, potov podnik, dopravcovia a in zasielatelia a ich
zamestnanci povinn poskytn nevyhnutn sinnos pri pouit informano-technickch
prostriedkov.
12.3 pecializovan legislatva a oblasti pravy vo vzahu k IB

Rozvoj a rozrenie IKT so sebou nesie zvyujci sa poet hrozieb a rizk, medzi ktor patr najm
naruenie skromia, vyzradenie osobnch dajov, krde identity, hrozby pre bezpenos
a spoahlivos siet, rzne formy kybernetickho zloinu (cybercrime) a rozirovanie neleglneho
obsahu.
esk zkon o kybernetickej bezpenosti je poda eskej organizcie Nrodn centrum kybernetick
bezpenosti (NCKB), ktor je relatvne novm odborom eskho nrodnho bezpenostnho radu
(NB), postaven na dvoch zsadch a troch pilieroch. Tto schma sa d vemi dobre aplikova aj
na slovensk legislatvu v oblasti kybernetickej bezpenosti. Prvou zsadou je minimalizcia zsahov
do prv skromnoprvnych subjektov, druhou zsadou je individulna zodpovednos za bezpenos
vlastnch informanch systmov. Tri piliere tvoria:
bezpenostn opatrenia (tandardizcia),

334
hlsenie kybernetickch bezpenostnch incidentov,
protiopatrenia, tzn. reakcie na incidenty [5].
Je preto nevyhnutn legislatvne podpori ochranu osobnch dajov, dodriavanie bezpenostnch

tandardov pri prevdzke systmov na spracovanie osobnch a inch citlivch dajov a svisiace
oblasti ochrany kritickej infratruktry, utajovanch skutonost, informanch systmov verejnej
sprvy a zkonnho rmca na vyvodenie trestnoprvnej zodpovednosti za poruovanie tchto ttom
stanovench podmienok.
Trestnoprvnej zodpovednosti bola venovan predchdzajca as. Tto as je venovan
jednotlivm pecifickm zkonom, ktor spravidla priamo definuj opatrenia informanej
bezpenosti. Zrove rieia a tandardizuj problematiku a spsoby riadenia informanej bezpenosti
v jej prslunch oblastiach. Ide najm o predpisy tkajce sa informanch systmov verejnej
sprvy, ochrany osobnch dajov a kritickej infratruktry.
12.3.1 Zkon . 275/2006 Z. z. o informanch systmoch verejnej sprvy a o zmene
a doplnen niektorch zkonov
Informan bezpenos je poda normy STN ISO/IEC 27001 ochrana informcie pred irokm
spektrom hrozieb, ktorej cieom je najm zaistenie kontinuity obchodnch procesov, minimalizcia
strt a maximalizcia nvratnosti investci do obchodnch procesov ale aj do procesov riadenia IB.
tandard STN ISO/IEC 27001 je lokalizovanou verziou medzinrodnho tandardu ISO a definuje
poiadavky na systm riadenia informanej bezpenosti. Je aplikovaten na kad typ organizcie
bez ohadu na predmet innosti, alebo jej vekos. Jeho cieom je zlepovanie informanej
bezpenosti, ochrana osobnch dajov, kontinuita prevdzkovch innost, riadenie rizk, slad s
legislatvnymi poiadavkami a poiadavkami tandardov a minimalizcia nkladov.
Samotnm riadenm IB v organizcii sa zaober alia norma z rady 2700x, ktorou je STN ISO/IEC
27002. Jednou zo zkladnch oblast riadenia definovanch touto normou je aj oblas sladu
s legislatvou.
Previazanie tchto noriem na legislatvu a legislatvne poiadavky, resp. previazanie informanej
bezpenosti a legislatvy nezana a nekon len pri tejto oblasti sladu, ale je zrejm aj z alch
oblast riadenia IB definovanch v uvedenej norme.
Najmarkantnejm prkladom tohto zkeho vzahu je zkon . 275/2006 Z. z. o informanch
systmoch verejnej sprvy a o zmene a doplnen niektorch zkonov (alej len zkon o ISVS)
a najm prslun vnos . 312/2010 Z. z. Ministerstva financi Slovenskej republiky o tandardoch
pre informan systmy verejnej sprvy (alej len vnos o tandardoch ISVS). Meme dokonca
tvrdi, e zkladom a vzorom pre nvrh vnosu o tandardoch bola prve tto norma riadenia IB.
tandardizcia pomocou tchto noriem me zabezpei lepiu organizciu prce, efektvnejie
procesy, bezpenej prenos a uchovvanie dt, dvernejie vzahy so zkaznkom a vo veobecnosti
je vyuiten ako referenn rmec, pokrvajci vetky aspekty fungujceho klovatenho
bezpenostnho modelu. Medzi dvody, preo je dleit vypracovva a nasadzova tandardy patr
lepia variabilita pri vbere dodvatea podpory, spravidla lepia bezpenos rieen nasadench
poda otvorench a technologicky neutrlnych sborov pravidiel spojench s vytvorenm, rozvojom
a vyuvanm informanch systmov verejnej sprvy. Integrovatenos s inmi informanmi
systmami je taktie vekou vhodou tandardizcie.
Informatizcia spolonosti a s ou svisiaca informan bezpenos verejnej sprvy je vymedzen
citovanm zkonom o ISVS. Zkon upravuje prva a povinnosti povinnch osb v oblasti ISVS.
Vymedzuje tie zkladn podmienky na zabezpeenie integrovatenosti a bezpenosti informanch
systmov verejnej sprvy, upravuje sprvu a prevdzku strednho portlu, postup pri vydvan
elektronickho odpisu dajov z ISVS a vstupu z ISVS.
335
Povinn osoby zabezpeuj prevdzku ISVS. Na el tohto zkona sa povinnmi osobami myslia
ministerstv a ostatn stredn orgny ttnej sprvy, orgny miestnej ttnej sprvy, obce
a samosprvne kraje a Kancelria Nrodnej rady Slovenskej republiky, prezidenta SR, Kancelria
stavnho sdu SR, Kancelria sdnej rady SR, Kancelria verejnho ochrancu prv, Generlna
prokuratra SR a Najvy kontroln rad SR, Socilna poisova, rad pre dohad nad zdravotnou
starostlivosou, zdravotn poisovne, Tlaov agentra SR.
Samotn zkon sa vzahuje len na informan systmy verejnej sprvy ako tak. Neriei informan
bezpenos veobecne ako jeden celok. Najm z uvedenho dvodu je aktulne v prprave zkon
ohadom informanej bezpenosti, ktor bude pokrva nie len ISVS, ale riadenie IB veobecne pre
cel eGovernment a cel verejn sprvu. Zkon by mal definova tzv. base line bezpenostn
poiadavky a poiadavky riadenia IB spolon pre vetky orgny verejnej sprvy s tm, e pokia
bud niektor intitcie poadova rozrenie alebo sprsnenie tchto poiadaviek, vzhadom na
svoje pecifik a pecifick agendu (napr. poiadavka ifrovania pri ochrane utajovanch skutonost
alebo ochrane telekomunikanho tajomstva a pod.), bud tak mc urobi vo svojej kompetennej
legislatve. Tmto prstupom bud minimalizovan rzne duplicity, ktor sa dnes objavuj v rznych
zkonoch a zrove bude zabezpeen jednotn postup riadenia informanej bezpenosti so
zachovanm prslunch kompetenci a rznych pecifickch poiadaviek, ktor s nad rmec
tandardnch poiadaviek a opatren. alou nezanedbatenou vhodou tohto prstupu bude
zjednotenie terminolgie pouvanej v oblasti riadenia informanej bezpenosti na legislatvnej
rovni.
Zkladn rmec informanej bezpenosti verejnej sprvy je nartnut v dokumente Nrodn
stratgia pre informan bezpenos v Slovenskej republike, ktor bol schvlen uznesenm vldy
Slovenskej republiky . 570 zo da 27. augusta 2008.
Legislatvny zmer zkona o informanej bezpenosti bol schvlen uznesenm vldy SR .136/2010
zo da 25. februra 2010.
12.3.1.1 Zkladn prva a povinnosti povinnej osoby
Povinn osoby vypracovvaj koncepcie rozvoja ISVS, zabezpeuj plynul, bezpen a spoahliv
prevdzku ISVS, s zodpovedn za predchdzanie zneuitiu IS, sprstupuj verejnosti daje z ISVS,
zabezpeuj organizan, odborn a technick zabezpeenie a s povinn prednostne pouva
sieov infratruktru.
Ministerstvo (rozumej MFSR) na seku informanch systmov verejnej sprvy vypracva nrodn
koncepciu informatizcie verejnej sprvy SR, usmeruje tvorbu a schvauje koncepcie rozvoja ISVS
povinnch osb s ohadom na tandardy a slad s nrodnou koncepciou informatizcie verejnej
sprvy SR, vydva tandardy, sleduje stav a hodnot rozvoj ISVS a o vsledkoch informuje vldu SR.
Tie koordinuje budovanie informanch systmov verejnej sprvy na nrodnej a medzinrodnej
rovni a navrhuje asov a vecn viazanie rozpotovch prostriedkov.
Ministerstvo tie zverejuje vypracovan tandardy, rozhodnutia a in informcie tkajce sa ISVS.
Zrove kontroluje dodriavanie povinnost ustanovench tmto zkonom, prijma opatrenia na
npravu zistench nedostatkov a uklad sankcie za poruenie povinnost ustanovench tmto
zkonom.
rad vldy Slovenskej republiky vykonva sprvu, prevdzku a rozvoj Govnetu a strednho portlu
a zabezpeuje lohy nrodnho prevdzkovatea centrlnej informanej infratruktry a centrlnej
komunikanej infratruktry Slovenskej republiky pre verejn sprvu.
12.3.1.2 Vzba zkona na riadenie IB
V slade s 3 ods. 4 psm. b), c) a i) zkona o ISVS s jednotliv povinn osoby povinn:
zabezpeova plynul, bezpen a spoahliv prevdzku informanch systmov verejnej

sprvy, ktor s v ich sprve, vrtane organizanho, odbornho a technickho zabezpeenia,
336
zabezpeova informan systm verejnej sprvy proti zneuitiu,
zabezpeova, aby bol informan systm verejnej sprvy v slade so tandardmi informanch
systmov verejnej sprvy (alej len "tandardy").
Na zklade uvedenho je jasne vidie, e pokia chce povinn osoba uveden povinnosti zabezpei,
najm zabrni zneuitiu a pokia chce dosiahnu plynul, bezpen a spoahliv prevdzku
informanch systmov verejnej sprvy, mus sa postara o patrin riadenie informanej
bezpenosti vo vetkch jej oblastiach poda prslunch tandardov, resp. vnosu o tandardoch
ISVS. Za poruenie tchto povinnost tkajcich sa riadenia IB je mon povinnej osobe udeli aj
sankcie, a to a do vky 35000 EUR.
12.3.2 Vnos o tandardoch pre ISVS
Samotn vnos o tandardoch pre ISVS neriei len problematiku riadenia IB ale tandardizuje aj
alie oblasti. Konkrtne v slade s 1 vnosu o tandardoch pre ISVS ide o nasledovn oblasti:
technick tandardy, vzahujce sa na technick prostriedky, sieov infratruktru a programov

prostriedky, a to
-
tandardy pre prepojenie,
tandardy pre prstup k elektronickm slubm,
tandardy pre webov sluby,
tandardy pre integrciu dt,
tandardy prstupnosti a funknosti webovch strnok, vzahujce sa na aplikan programov

vybavenie poda zkona,
tandardy pouitia sborov, vzahujce sa na formty vmeny dajov,
tandardy nzvoslovia elektronickch sluieb, vzahujce sa na sieov infratruktru,
bezpenostn tandardy, vzahujce sa na technick prostriedky, sieov infratruktru,

programov prostriedky a daje, a to
-
tandardy pre architektru riadenia,
tandardy minimlneho technickho zabezpeenia,
dtov tandardy, vzahujce sa na daje, registre a selnky,
tandardy elektronickch sluieb verejnej sprvy, vzahujce sa na daje, registre, selnky

a aplikan programov vybavenie poda zkona,
tandardy projektovho riadenia, vzahujce sa na postupy a podmienky spojen s vytvranm

a rozvojom informanch systmov verejnej sprvy.
Oblas riadenia IB, ktor vychdza z uvedench medzinrodnch a u aj lokalizovanch noriem STN
ISO/IEC 27001 a STN ISO/IEC 27002 a je definovan v paragrafoch 28 a 42. Tto oblas je
rozdelen na nasledovn asti:
tandardy pre architektru riadenia (28-31) - pokrva oblasti ako s napr. samotn riadenie IB,
personlna bezpenos, riadenie rizk a kontrola riadenia IB,
tandardy minimlneho technickho zabezpeenia (32-42) pokrva oblasti ako je napr.

ochrana proti kodlivmu SW, bezpenos siet, fyzick bezpenos, aktualizcia SW,
identifikcia a hodnotenie zranitenost, riadenie bezpenostnch incidentov, zlohovanie
a ukladanie dt, riadenie prstupu a prstupovch prv, prstup tretch strn a aktualizcia IKT.
337
Viac informci a podrobnost je mon njs v samotnom znen zkona o ISVS, (v jeho upravenom
plnom znen k 1. jlu 2011), vnose o tandardoch o ISVS a alch svisiacich prvnych
predpisoch, ktor je mon njs na strnke [7].
Podrobnejie informcie k jednotlivm oblastiam bezpenosti definovanmi v rmci vnosu s
detailne popsan v alch kapitolch tchto tudijnch materilov, ktor rozoberaj problematiku
riadenia IB v prslunch oblastiach.
niektorch zkonov
Nrodn rada slovenskej republiky schvlila a od 1.7.2013 uviedla do platnosti nov zkon
. 122/2013 Z. z. o ochrane osobnch dajov (alej len zkon o OOU), ktor nahrdza pvodn
zkon . 428/2002 Z. z. o ochrane osobnch dajov.
Nvrh zkona o OOU vychdza z povinnost, ktor uklad eurpska nia, konkrtne Smernica
Eurpskeho parlamentu a Rady 95/46/ES, zverov a odporan hodnotenia sprvneho uplatovania
schengenskho acquis v Slovenskej republike pre oblas ochrany osobnch dajov a vsledky
analzy sasne platnho zkona z pohadu aplikcie v praxi [8].
Garancia ochrany osobnch dajov je zakotven v stave, preto mus by legislatvne zapracovan.
Spolieha sa na individulne iniciatvy prevdzkovateov a sprostredkovateov nesta, preto je vo
veobecnosti nutn ochrana osobnch dajov na rovni zkona. Tak je mon stanovi nie len
kvalitatvne parametre pri ich spracovvan, prenose, ukladan, sprostredkovvan a likvidovan, ale
najm zkladn opatrenia na ich ochranu.
Na to, aby sme mohli hodnoti potrebu legislatvneho rmca pre ochranu bezpenosti tzv.
dotknutch osb, teda vetkch fyzickch osb, ktorch sa osobn daje tkaj, mali by sme si
vymenova a zhodnoti hrozby. Uvedieme si jeden z monch pohadov, resp. aksi formalizovan
model, ktor ukazuje na zkladn ivotn cyklus spracovania osobnch dajov a najm na mon
hrozby, ktor v jednotlivch fzach tohto ivotnho cyklu ohrozuj dvernos, integritu a dostupnos
osobnch dajov:
Zbieranie informci (information

o dotknutch osobch:
-
sledovanie (surveillance),
vyetrovanie (interrogation).
collection)
spsoby
zhromaovania
informci
Spracovvanie informci (information processing) ukladanie, analza a manipulcia s dtami:

-
agregcia zhromaovanie informci zo zdrojov tretch strn,
identifikcia rozpoznanie osoby na zklade jej atribtov,
socilna neistota (insecurity) vysuje v zven zranitenos osb pri zneuit ich
osobnch dajov,
sekundrne pouitie (secondary use) pouitie dajov zhromadench na in el, ktor nie
je prepojen s pvodnm, bez udelenia shlasu touto dotknutou osobou,
exklzia neinformovanie dotknutej osoby a jej nulov kontrola nad spsobom spracovania
jej osobnch dajov.
Rozirovanie informci (information dissemination) spsob akm sa daje prenaj (alebo

existuje hrozba ich neoprvnenho prenania) smerom k tretm stranm:
-
Naruenie dvery (breach of confidentiality) vo vzahu medzi prevdzkovateom

a dotknutou osobou dolo k narueniu vzjomnej lojality.
338
Prezradenie (disclosure) nik citlivch osobnch dajov.
Vystavenie (exposure) nedodranie bezpenostnch zsad pri prenan a ukladan dt,

ktor ich vystavuje riziku ohrozenia.
Zven dostupnos (increased accessibility) replikcia dt na viacer mdi a do viacerch

geografickch lokalt ich vystavuje riziku ohrozenia.
Vydieranie (blackmail) pokia djde k niku osobnch dajov, mu by tieto daje

zneuit na vydieranie dotknutej osoby.
Privlastnenie (appropriation) pri zloine kradnutia identity me djs k privlastneniu

osobnch dajov dotknutej osoby.
Skreslenie (distortion) manipulcia osobnch dajov za elom diskreditcie, alebo

kompromitcie dotknutej osoby.
Napadnutie (Invasion):
-
Prienik (intrusion) naruenie skromia dotknutej osoby. Me by v najmiernejom prpade

neoprvnen pasvne pozorovanie dotknutej osoby.
myseln zasahovanie do skromia (decisional interference) aktvne naruenie skromia

dotknutej osoby, obmedzovanie jej prv a slobd.[9]
Zkon o OOU upravuje ochranu prv fyzickch osb pred neoprvnenm zasahovanm do ich
skromnho ivota pri spracvan ich osobnch dajov. Vymedzuje prva, povinnosti
a zodpovednos pri spracvan osobnch dajov fyzickch osb. Samozrejme, zrove upravuje aj
postavenie, psobnos a organizciu radu na ochranu osobnch dajov Slovenskej republiky.
Zkon sa vzahuje na kadho, kto spracva osobn daje, uruje el a prostriedky spracvania
alebo poskytuje osobn daje na spracvanie. Ako sme uviedli vyie nvrh zkona o OOU vychdza
z povinnost, ktor nm uklad eurpska nia a tento fakt sa prejavil aj na psobnosti zkona, pretoe
poda 2 zkona o OOU sa tento zkon vzahuje aj na prevdzkovateov, ktor nemaj sdlo,
organizan zloku, prevdzkare alebo trval pobyt na zem Slovenskej republiky, ale s
umiestnen v zahrani na mieste, kde sa uplatuje prvny poriadok Slovenskej republiky. Dokonca
meme tvrdi, e zkon v uritch prpadoch nepozn hranice SR a dokonca ani hranice E,
pretoe ten ist 2 zkona o OOU hovor, e zkon sa vzahuje aj na prevdzkovateov, ktor nemaj
sdlo, organizan zloku, prevdzkare alebo trval pobyt na zem lenskho ttu E, ak na ely
spracvania osobnch dajov vyuvaj plne alebo iastone automatizovan alebo in ako
automatizovan prostriedky spracvania umiestnen na zem Slovenskej republiky, priom tieto
prostriedky spracvania nie s vyuvan vlune len na prenos osobnch dajov cez zemie
lenskch ttov.
alm dleitm faktom je skutonos, e zkon o OOU sa v podstate vzahuje len na osobn daje,
ktor s spracovvan automatizovanmi prostriedkami, i u plne alebo iastone, alebo s
spracovvan inmi ako automatizovanmi prostriedkami spracvania, ktor s sasou
informanho systmu alebo s uren na spracvanie v informanom systme.
Zkon o OOU sa nevzahuje na osobn daje, ktor fyzick osoba spracva sama, alebo na daje,
ktor boli zskan nhodne bez predchdzajceho urenia, alebo zmeru spracovania.
Vemi dleitou poiadavkou zkona je skutonos, e osobn daje mono spracva len spsobom
ustanovenm zkonom o OOU a v jeho medziach tak, aby nedolo k porueniu zkladnch prv
a slobd dotknutch osb, najm k porueniu ich prva na zachovanie udskej dstojnosti alebo k
inm neoprvnenm zsahom do ich prva na ochranu skromia.
12.3.3.1 Zkladn prva a povinnosti jednotlivca
Oprvnenou osobou sa v zmysle zkona rozumie kad fyzick osoba, ktor prichdza do styku s
osobnmi dajmi v rmci svojho pracovnho pomeru, ttnozamestnaneckho pomeru, sluobnho
339
pomeru, lenskho vzahu, na zklade poverenia, zvolenia alebo vymenovania, alebo v rmci vkonu
verejnej funkcie, a ktor spracva osobn daje.
Fyzick osoba sa stva oprvnenou osobou dom jej pouenia prevdzkovateom. Prevdzkovate je
povinn poui osobu najm o prvach a povinnostiach ustanovench zkonom o OOU
a o zodpovednosti za ich poruenie ete pred uskutonenm prvej opercie s osobnmi dajmi.
Pouenie by malo obsahova najm rozsah oprvnen, popis povolench innost a podmienky
spracvania osobnch dajov.
V prpade, e dolo k zsadnej a podstatnej zmene pracovnho, sluobnho alebo funknho
zaradenia, a tm sa vznamne zmenil obsah nplne pracovnch innost, alebo sa podstatne zmenili
podmienky, alebo rozsah spracvanch osobnch dajov je prevdzkovate povinn optovne poui
oprvnen osobu.
Jednou z najdleitejch povinnost pre oprvnen osoby je poiadavka na zachovvanie
mlanlivosti. Oprvnen osoba je povinn zachovva mlanlivos o osobnch dajoch, s ktormi
prde do styku. Dleitou skutonosou je aj fakt, e tieto daje nesmie vyui ani pre osobn
potrebu a bez shlasu prevdzkovatea ich nesmie zverejni a nikomu poskytn ani sprstupni.
Povinnos mlanlivosti samozrejme plat aj pre in fyzick osoby, ktor prdu do styku s osobnmi
dajmi u prevdzkovatea alebo sprostredkovatea, i u nhodne alebo myselne. Povinnos
mlanlivosti samozrejme trv aj po ukonen spracvania osobnch dajov.
Okrem tchto zkladnch povinnost pre fyzick osoby, zkon o OOU jasne definuje aj zkladn
prva jednotlivcov, o ktorch sa osobn daje spracovvaj. Zkladnm prvom je ochrana prv
dotknutch osb. Prva dotknutej osoby s v zkone o OOU definovan na relatvne detailnej rovni,
take v alom texte uvedieme len zkladn fakty.
Dotknut osoba m prvo na zklade psomnej iadosti od prevdzkovatea vyadova najm:
potvrdenie, i s alebo nie s osobn daje o nej spracvan,
vo veobecne zrozumitenej forme presn informcie o zdroji, z ktorho zskal jej osobn daje
na spracvanie,
zoznam jej osobnch dajov, ktor s predmetom spracvania,
opravu alebo likvidciu svojich nesprvnych, neplnch alebo neaktulnych osobnch dajov,
ktor s predmetom spracvania,
likvidciu jej osobnch dajov, ktorch el spracvania sa skonil (ak s predmetom

spracvania radn doklady obsahujce osobn daje, me poiada o ich vrtenie),
likvidciu jej osobnch dajov, ktor s predmetom spracvania, ak dolo k porueniu zkona,
blokovanie jej osobnch dajov z dvodu odvolania shlasu pred uplynutm asu jeho platnosti,
ak prevdzkovate spracva osobn daje na zklade shlasu dotknutej osoby.
Taktie je dleit spomen aj to, e dotknut osoba na zklade psomnej iadosti m prvo u
prevdzkovatea namieta voi:
spracvaniu jej osobnch dajov, o ktorch predpoklad, e s alebo bud spracvan na ely
priameho marketingu bez jej shlasu, a iada ich likvidciu,
vyuvaniu osobnch dajov na ely priameho marketingu v potovom styku, alebo
poskytovaniu osobnch dajov na ely priameho marketingu.
12.3.3.2 Zkladn prva a povinnosti organizcie

Podobne ako pre fyzick osoby, povinnos mlanlivosti sa vzahuje aj na organizciu, resp.
prevdzkovatea. Prevdzkovate je rovnako ako oprvnen osoba povinn zachovva mlanlivos
340
o osobnch dajoch, ktor spracva. Povinnos mlanlivosti trv aj po ukonen spracvania

osobnch dajov.
Kovou asou zkona z pohadu informanej bezpenosti je urite jeho druh hlava, ktor
pojednva o bezpenosti osobnch dajov. Zodpovednos za bezpenos osobnch dajov je
jednoznane ponechan na pleciach prevdzkovatea.
Prevdzkovate je povinn chrni spracvan osobn daje pred ich pokodenm, znienm, stratou,
zmenou, neoprvnenm prstupom a sprstupnenm, poskytnutm alebo zverejnenm, ako aj pred
akmikovek inmi neprpustnmi spsobmi spracvania. Za tmto elom je prevdzkovate
povinn, z pohadu informanej bezpenosti, prija primeran technick, organizan a personlne
opatrenia (alej len bezpenostn opatrenia) zodpovedajce spsobu spracvania osobnch
dajov. Pri nvrhu konkrtnych bezpenostnch opatrn mus do vahy zobra najm pouiten
technick prostriedky, dvernos a dleitos spracvanch osobnch dajov, a najm rozsah
monch rizk, ktor s spsobil narui bezpenos alebo funknos informanho systmu. Inak
povedan je potrebn poui, tzv. Risk based approach prstup, ktor najskr vyaduje vykonanie
analzy rizk, kde na zklade jej vsledkov s prijat a implementovan prslun bezpenostn
opatrenia.
Prijat a implementovan bezpenostn opatrenia mus prevdzkovate zdokumentova
v bezpenostnej smernici alebo v bezpenostnom projekte, v zvislosti od toho, i spracva osobitn
kategrie osobnch dajov a od toho, i je jeho systm prepojen s verejne prstupnou potaovou
sieou. Bezpenostn projekt vymedzuje rozsah a spsob bezpenostnch opatren potrebnch na
eliminovanie a minimalizovanie hrozieb a rizk psobiacich na informan systm z hadiska
naruenia jeho bezpenosti, spoahlivosti a funknosti.
Jednoznan previazanie zkona o OOU s informanou bezpenosou a bezpenostnmi tandardmi
je vidie z povinnosti prevdzkovatea poda, ktorej mus bezpenostn projekt vypracova nie len
v slade s tmito tandardmi, ale aj prvnymi predpismi a medzinrodnmi zmluvami, ktormi je
Slovensk republika viazan.
Nakoko bezpenostn opatrenia maj taktie svoj vlastn ivotn cyklus je potrebn zabezpei ich
pravideln aktualizciu vzhadom na aktulne podmienky a vvoj. Za tmto elom je
prevdzkovate povinn bez zbytonho odkladu zabezpeova aktualizciu prijatch
bezpenostnch opatren tak, aby zodpovedala prijatm zmenm pri spracvan osobnch dajov,
a to a do ukonenia spracvania osobnch dajov v informanom systme.
Kee na celkovej bezpenosti maj svoj podiel aj jednotliv pracovnci prevdzkovatea je
potrebn, aby prevdzkovate oboznmil vetky oprvnen osoby s obsahom bezpenostnej
dokumentcie v rozsahu potrebnom na plnenie ich loh. Ide najm o oboznmenie s ich prvami
a povinnosami, ktor sa od nich vyaduj pre zaistenie ochrany osobnch dajov. Oboznmenie
oprvnench osb s obsahom bezpenostnej smernice je prevdzkovate povinn na iados radu
hodnoverne preukza. Tto povinnos si navye mus prevdzkovate splni pri kadej zmene
bezpenostnej dokumentcie. V prpade, ak prevdzkovate spracva osobn daje prostrednctvom
20 a viac oprvnench osb mus psomne poveri zodpovedn osobu dohadom nad dodriavanm
ustanoven zkona o OOU. Zodpovednou osobou, me by iba fyzick osoba, ktor m spsobilos
na prvne kony v plnom rozsahu, je bezhonn a m platn potvrdenie radu o absolvovan skky
z oblasti ochrany osobnch dajov.
Z dvodov zabezpeenia celkovej bezpenosti a efektvneho dohadu radu na ochranu osobnch
dajov podliehaj informan systmy, v ktorch sa spracovvaj osobn daje registrci
a osobitnej registrci. O informanch systmoch, ktor nepodliehaj registrcii alebo osobitnej
registrcii, je prevdzkovate povinn vies evidenciu, a to najneskr odo da zaatia spracvania
dajov v tchto informanch systmoch. Zkon samozrejme definuje aj konkrtne podmienky, kedy
ide iba o registrciu, a kedy o osobitn registrciu, a rovnako aj podmienky samotnej registrcie
a osobitnej registrcie, ktor musia jednotliv prevdzkovatelia naplni.
341
12.3.4 Vyhlka . 164/2013 Z. z. o rozsahu a dokumentcii bezpenostnch opatren

radu na ochranu osobnch dajov Slovenskej republiky vydal 13. jna 2013 vyhlku k zkonu
o OOU, ktor pojednva o rozsahu a dokumentcii bezpenostnch opatren.
Ide o vyhlku, ktor v rmci ochrany osobnch dajov, detailne tandardizuje informan
bezpenos v oblasti vedenia konkrtnej dokumentcie, ktor napomha efektvnemu riadeniu
informanej bezpenosti.
Vyhlka definuje dokumentciu prijatch bezpenostnch opatren, ktor popisuje cel proces
spracvania osobnch dajov od ich zskavania po ich likvidciu. Obsah dokumentcie sa mus
zhodova so skutonm stavom implementovanch bezpenostnch opatren pri spracvan
osobnch dajov. Bezpenostn opatrenia musia by zdokumentovan prehadne a jednoznane.
Vyhlka popisuje najm nasledovn dokumentciu:
psomn zmluvu, ak prevdzkovate poveril spracvanm osobnch dajov sprostredkovatea,
psomn zznamy o pouen oprvnench osb,
psomn poverenie zodpovednej osoby,
zznamy o kontrolnej innosti prevdzkovatea zameranej na dodriavanie bezpenosti

informanho systmu,
zznamy o zistench bezpenostnch incidentoch vplvajcich na bezpenos osobnch dajov

a zznamy o nadvznch postupoch, ktormi prevdzkovate zabezpeil obnovenie bezpenosti
informanho systmu,
bezpenostn smernicu,
bezpenostn projekt.
Obsah a rozsah poslednch dvoch uvedench typov dokumentcie je popsan detailnejie

v samostatnch paragrafoch vyhlky.
12.3.5 Zkon . 45/2011 Z. z. o kritickej infratruktre
Kritick infratruktru definuje zdroj [6] nasledovne:
Koncepcia ochrany kritickej infratruktry na Slovensku bola prijat uznesenm vldy SR . 120 zo
14. februra 2007. V tejto koncepcii je kritick infratruktra oznaen ako t as nrodnej
infratruktry, ktorej znienie alebo znefunknenie v dsledku psobenia rizikovho faktora spsob
ohrozenie alebo naruenie hospodrskeho a politickho chodu ttu alebo ohrozenie ivota a zdravia
obyvatestva.
Nepretrit vyhodnocovanie rizk v kritickej infratruktre na nrodnej rovni vytvra predpoklady
na lep odhad monch ohrozen a tm na vytvranie efektvnejch postupov a prostriedkov na
zvyovanie bezpenosti.
Meme kontatova, e uveden poiadavky koncepcie ochrany kritickej infratruktry boli
premietnut do zkon . 45/2011 Z. z. o kritickej infratruktre (alej len zkon o KI). Poiadavka
na monitorovanie a vyhodnocovanie rizk v kritickej infratruktre je iastone rieen
prostrednctvom organizcie CSIRT.SK. CSIRT.SK je pecializovan tvar DataCentra (rozpotovej
organizcie Ministerstva financi SR), ktor m za cie zabezpei primeran rove ochrany
nrodnej informanej a komunikanej infratruktry. Poskytuje aktvne a proaktvne sluby pre
klientov definovan uznesenm vldy . 479/2009.[10]
Zkon o KI ustanovuje organizciu a psobnos orgnov ttnej sprvy na seku kritickej
infratruktry, postup pri urovan prvku kritickej infratruktry, povinnosti prevdzkovatea pri
ochrane prvku kritickej infratruktry a zodpovednos za poruenie tchto povinnost. Me sa tie
jedna o obrann infratruktru poda osobitnho predpisu.
342
ttnu sprvu na seku kritickej infratruktry vykonva vlda SR, Ministerstvo vntra SR,
Ministerstvo hospodrstva SR, Ministerstvo financi SR, Ministerstvo dopravy, vstavby
a regionlneho rozvoja SR, Ministerstvo ivotnho prostredia SR a Ministerstvo zdravotnctva SR.
Meme poveda, e rovnako ako pri zkone o ISVS aj povinnosti definovan v zkone o KI
vychdzaj z medzinrodnch tandardov riadenia IB. Organizcia, resp. prevdzkovate prvku
kritickej infratruktry je povinn ochraova prvok pred naruenm alebo znienm. Na tento el je
prevdzkovate povinn najm:
uplatni pri modernizcii prvku technolgiu, ktor zabezpeuje jeho ochranu,
zavies bezpenostn pln, a tento pravidelne prehodnocova,
oboznmi svojich zamestnancov v nevyhnutnom rozsahu s bezpenostnm plnom,
precvii poda bezpenostnho plnu aspo raz za tri roky modelov situciu hrozby naruenia
alebo znienia prvku,
postupova poda bezpenostnho plnu v prpade hrozby naruenia alebo znienia prvku.
Bezpenostn pln obsahuje popis monch spsobov hrozby naruenia alebo znienia prvku,
zraniten miesta prvku a bezpenostn opatrenia na jeho ochranu. Bezpenostn opatrenia na
ochranu prvku s najm mechanick zbrann prostriedky, technick zabezpeovacie prostriedky,
bezpenostn prvky informanch systmov, fyzick ochrana, organizan opatrenia, kontroln
opatrenia a ich vzjomn kombincia. Rozsah bezpenostnch opatren na ochranu prvku sa uruje
na zklade posdenia hrozby naruenia alebo znienia prvku.
Zkon o KI tie uruje alie detaily v svislosti s informanou bezpenosou, tkajce sa najm:
postupov pri urovan prvku kritickej infratruktry ( 8),
postupov pre vypracovanie bezpenostnho plnu (prloha . 2),
oznaovania citlivej informcie, ktor mus by oznaen slovami Kritick infratruktra

nezverejova ( 12),
vyraovania prvku a prvku eurpskej kritickej infratruktry ( 13),
priestupkov pri poruen povinnosti, alebo myselnom vyzraden citlivej informcie ( 14),
inch sprvnych deliktov a s nimi svisiacich pokt ( 15).
12.4 In pecifick legislatva vo vzahu k IB

V rmci tejto pecifickej asti si strune uvedieme prehad niektorch pecifickch prvnych
predpisov, ktor u netandardizuj problematiku IB a riadenia IB ako tak, ale obsahuj urit
prvky a poiadavky na pouvateov a prevdzkovateov, i u z pohadu zabezpeenia IB alebo
z pohadu riadenia IB. Ide najm o predpisy tkajce sa elektronickho podpisu, ochrany
utajovanch skutonost, elektronickho obchodu, elektronickch komunikci a poskytovania
zdravotnej starostlivosti. Meme poveda, e tieto predpisy vo vej alebo menej miere aplikuj
prvky informanej bezpenosti a riadenia informanej bezpenosti, ktor s tandardizovan v rmci
pecializovanej legislatvy.
Povinnosti pre organizcie vyplvajce z tchto prvnych predpisov nie s pre ely tchto
tudijnch materilov dleit, nakoko nejde o veobecn povinnosti pre vetky intitcie verejnej
sprvy ale o povinnosti pre vybran organizcie (prevane skromnho sektora), poskytujce
prslun pecifick sluby zva na zklade pecilneho povolenia, certifikcie alebo akreditcie.
Spomenut prvne predpisy uvdzame z dvodu veobecnho a ucelenejieho prehadu legislatvy
majcej vplyv alebo vzah s informanou bezpenosou ako takou. Okrem tohto dvodu povaujeme
343
za nutn ich spomen najm z pohadu povinnost v svislosti s informanou bezpenosou

a ochranou informci alebo skromia, ktor definuj pre jednotlivcov, resp. pouvateov
prslunch sluieb definovanch konkrtnym prvnym predpisom. Pre pouvateov s zrove
dleit aj informcie o ich prvach, ktor v uritch prpadoch nepriamo vyplvaj z povinnost
definovanch pre prslun organizciu.
12.4.1 Zkon . 215/2002 Z. z. o elektronickom podpise
Na Slovensku sa elektronick podpis vyuva v rznych formch, najm vak v bankovom sektore,
u viac ako 15 rokov. Najv rozmach zaznamenal po roku 2002, kedy vznikla tto prvna prava
zkonom . 215/2002 o elektronickom podpise a o zmene a doplnen niektorch zkonov v znen
neskorch predpisov (alej len zkon o EP) a zrove dolo k zrovnoprvneniu vlastnorunho
podpisu v psomnej forme s tzv. zaruenm elektronickm podpisom ( 40 ods. 4 Obianskeho
zkonnka). Prijatie tejto normy okrem inho umonilo vznik celej PKI infratruktry. Na zklade
zkona o EP vznikli certifikan autority, akreditovan certifikan autority, koreov certifikan
autority NB, bolo vydanch niekoko tisc certifiktov a kvalifikovanch certifiktov verejnch
kov pre fyzick osoby. Vzniklo tie viacero aplikci pre vyhotovovanie a overovanie
elektronickho podpisu a objavili sa aj certifikovan aplikcie pre zaruen elektronick podpis.[11]
Elektronick podpis (EP) je jednm z nstrojov, prostrednctvom ktorho je mon vykona
autorizciu (podpsanie) elektronickho dokumentu konkrtnou osobou. Jeho alou
nezanedbatenou bezpenostnou funkciou, ktor vychdza z podstaty samotnho elektronickho
podpisu na bze asymetrickej kryptografie, je monos kontroly zachovania integrity podpisovanho
dokumentu. Zkon o EP upravuje vzahy vznikajce v svislosti s vyhotovovanm a pouvanm
elektronickho podpisu, prva a povinnosti fyzickch osb a prvnickch osb pri pouvan
elektronickho podpisu, hodnovernos a ochranu elektronickch dokumentov podpsanch
elektronickm podpisom. Uvdza tie poiadavky na rozsah auditu certifikanch autort. Rozsah
auditu certifikanej autority je pomerne irok, kee innos certifikanej autority nespova iba
v manamente kov, ale zaha napr. aj dodranie fyzickej a reimovej bezpenosti nad
pecifickou mnoinou aktv.
Gestorom zkona o EP je Nrodn bezpenostn rad, ktor vykonva innosti kontroly
dodriavania tohto zkona, posudzuje iadosti o akreditciu certifikanch autort na zem SR,
udeuje a odnma certifikanm autoritm akreditciu a vydva osvedenia o akreditcii. Vydva
certifikty verejnch kov akreditovanm certifikanm autoritm, zverejuje vlastn verejn k
a vydva certifikt svojho vlastnho verejnho ka, eviduje certifikan autority psobiace na
Slovensku, vedie zoznam akreditovanch certifikanch autort a zverejuje ho na svojom webovom
sdle. Zruuje certifikt akreditovanej certifikanej autority, ak jej bola odat prvomoc, alebo ak
ukonila svoju innos, vedie register zahraninch certifikanch autort, ktorch certifikty boli
radom uznan na pouitie v SR.
Elektronick podpis je navrhnut s ohadom na pouvatesk jednoduchos a praktick vznam,
preto prva a povinnosti jednotlivca na pouvanie priamo vyplvaj zo zkona.
Pouvanie elektronickho podpisu ( 5)
V styku s orgnmi verejnej moci sa pouva elektronick podpis, alebo zaruen elektronick podpis.
Ak sa pouva zaruen elektronick podpis, tento mus by vyhotoven prostrednctvom
skromnho k, na ktor je vydan kvalifikovan certifikt, ktor vydala akreditovan certifikan
autoritou a tento certifikt mus obsahova rodn slo dritea certifiktu.
Overovate overuje elektronick podpis prostriedkami na overovanie elektronickho podpisu
vyuitm podpsanho elektronickho dokumentu a verejnho ka patriaceho udvanmu
podpisovateovi. Pri overovan elektronickho podpisu overovate me poadova overenie
344
pravosti verejnho ka, to znamen toho, e verejn k patr podpisovateovi. Na tento el

me poui certifikt verejnho ka podpisovatea.
Na rozdiel od obyajnho elektronickho podpisu, kde overovate me vykona urit, vyie
uveden, overenia, pri overovan zaruenho elektronickho podpisu overovate u mus overi
urit, zkonom definovan skutonosti. Ide najm o verifikovanie toho, i verejn k na overenie
zaruenho elektronickho podpisu patr podpisovateovi, ktor sa mus vykona na zklade
kvalifikovanho certifiktu verejnho ka.
Povinnosti v prpade vydania mandtneho certifiktu (7)
Jedna z poslednch noviel zkona o EP priniesla aj monos vydva, tzv. mandtne certifikty pre
fyzick, ale aj prvnick osoby. Fyzickej osobe konajcej v mene inej fyzickej osoby, alebo fyzickej
osobe podnikateovi, prpadne prvnickej osobe me by rovnako vydan kvalifikovan
certifikt, ktor oprvuje tto fyzick osobu kona v mene inej, v certifikte uvedenej, fyzickej
osoby.
Z uvedenej skutonosti vak pre takto zastupovan fyzick osobu vyplva minimlne jedna dleit
povinnos, ktorou je poiadanie o zruenie mandtneho certifiktu v prpade, e oprvnenie osoby
bolo zruen alebo zaniklo. V prpade, e zastupovan osoba zomrela, bola vyhlsen za mtvu,
zanikla alebo bola zruen, prena sa tto povinnos o zruenie certifiktu na samotnho drite
mandtneho certifiktu.
Povinnosti dritea certifiktu (22)
Medzi alie zkladn povinnosti dritea certifiktu vo veobecnosti patr poda 22 najm:
zaobchdza so svojm skromnm kom s nleitou starostlivosou tak, aby nemohlo djs
k zneuitiu jeho skromnho ka,
uvdza presn, pravdiv a pln informcie vo vzahu k certifiktu svojho verejnho ka,
neodkladne poiada certifikan autoritu, ktor spravuje jeho certifikt, o zruenie certifiktu,
ak zist, e dolo k neoprvnenmu pouitiu jeho skromnho ka, alebo ak hroz neoprvnen
pouitie jeho skromnho ka, alebo ak nastali zmeny v dajoch uvedench v certifikte.
Za kodu spsoben poruenm povinnost zodpoved drite certifiktu poda veobecnch

predpisov o nhrade kody.
Zruovanie certifiktov ( 15)
Drite certifiktu by mal zrove pozna aj povinnosti certifikanej autority, ktor mu vydal
prslun certifikt v svislosti s jeho monm zruenm. Certifikan autorita je totito povinn
zrui certifikt, ktor spravuje, ak zist, e neboli splnen poiadavky poda zkona o EP, alebo ak
zist, e certifikt nebol vydan na zklade pravdivch dajov. Najdleitejou podmienkou zruenia
z pohadu dritea certifiktu je ale monos, kedy drite, alebo osoba, ktorej daje s uveden
v certifikte, sama poiada o zruenie certifiktu z akchkovek dvodov, ktormi samozrejme
spravidla bvaj bezpenostn dvody, prpadne zmena identifikanch dajov.
Taktie me o zruenie certifiktu poiada sd, prpadne to me by certifikan autorita, ktor
poiada o zruenie certifiktu, v prpade, ak drite zomrel, alebo v prpade, ak drite certifiktu
zanikol ako prvnick osoba.
alm dvodom pre zruenie certifiktu me by, e skromn k patriaci k certifiktu pozn in
osoba, ne osoba uveden v certifikte. O zruenie certifiktu me okrem dritea certifiktu
zaiada aj zastupovan osoba.
Priestupky a sprvne delikty na seku elektronickho podpisu (26 a 27)
Poda 26 sa priestupku dopust ten, kto:
345
zneuije skromn k podpisovatea,
predlo nepravdiv daje pri podvan iadosti o vydanie certifiktu,
poru povinnos bezodkladne poiada o zruenie certifiktu.
Za uveden priestupok poda prvho bodu mono uloi pokutu do vky 33000 EUR a za
priestupok poda poslednch dvoch bodov mono uloi pokutu a do vky 66000 EUR.
Rovnako je mon, v slade s 27, uloi pokutu aj poskytovateovi certifikanch sluieb, prpadne
inej relevantnej prvnickej osobe, za poruenie prslunch povinnost vyplvajcich zo zkona, a to
a do vky 332000 EUR.
Povinnosti v prpade vydania mandtneho certifiktu (7)
Podobne ako pri povinnostiach jednotlivca v svislosti so sprvou mandtnych certifiktov, platia
rovnak povinnosti aj pre organizciu verejnej moci, v mene ktorej bol prslun mandtny
certifikt vydan.
Kvalifikovan certifikt me by vydan aj fyzickej osobe, ktor m oprvnenie na vykonvanie
innosti poda osobitnho predpisu (napr. notrovi, advoktovi, exektorovi a pod.), fyzickej osobe,
ktor vykonva funkciu poda osobitnho predpisu (napr. sudcovi, prokurtorovi a pod.) a fyzickej
osobe, ktor je verejnm funkcionrom.
Z uvedenej skutonosti pre prslun orgn verejnej moci, v mene ktorho je mandtny certifikt
vydan, vyplva povinnos bezodkladne poiada o zruenie tohto mandtneho certifiktu, ak
oprvnenie osoby alebo postavenie osoby uvedenej v mandtnom certifikte bolo zruen, alebo
zaniklo.
alie pecifick povinnosti tkajce sa organizcie vyplvajce zo zkona o EP
Zkon o EP umouje certifikanm autoritm prevdzkovanie, tzv. registranch autort, ktor
nemusia by integrlnou sasou a internou zlokou certifikanej autority, ale me s
o samostatn prvne subjekty, prpadne orgny verejnej moci, ktor v mene prslunej certifikanej
autority bud vykonva vybran certifikan innosti spojen najm s vydvanm a ruenm
certifiktov. V prpade, e sa povinn organizcia verejnej moci stane takouto registranou autoritou
jej zkladnou povinnosou je, e mus kona v mene certifikanej autority alebo na zklade zmluvy
uzatvorenej s prslunou certifikanou autoritou.
V takomto prpade je registran autorita vo svojej innosti viazan certifikanm poriadkom
certifikanej autority, v ktorej mene kon, alebo s ktorou m uzatvoren zmluvu.
Registran autorita najm prijma iadosti o vydanie certifiktu a kontroluje slad dajov v iadosti
o vydanie certifiktu s dajmi v predloenom preukaze totonosti iadatea o vydanie certifiktu. Na
zklade overench dajov odosiela iados o vydanie certifiktu certifikanej autorite. Po spracovan
tejto iadosti prslunou certifikanou autoritou a doruen vydanho certifiktu od certifikanej
autority odovzdva tento certifikt protokolrnym spsobom samotnmu iadateovi, resp. driteovi
certifiktu.
12.4.1.3 Vzba zkona na riadenie IB
Vzah zkona o EP s poiadavkami noriem ohadom informanej bezpenosti a riadenia IB je mon
vidie najm pri povinnostiach kladench na jednotliv certifikan a akreditovan certifikan
autority. Okrem pecifickch povinnost vyplvajcich z vydvania, ruenia a celkovej sprvy
certifiktov, definuje zkon o EP (a najm prslun vyhlky Nrodnho bezpenostnho radu
k tomuto zkonu) aj povinnosti, ktor sa priamo tkaj IB a riadenia IB. Ide naprklad o pravideln
vykonvanie nezvislch bezpenostnch auditov, vedenie bezpenostnej a prevdzkovej
dokumentcie s minimlnym predpsanm obsahom, o poiadavky na audtorov a na samotn rozsah
a vkon auditu.
346
12.4.2 Zkon . 215/2004 Z. z. o ochrane utajovanch skutonost

Zkon o ochrane utajovanch skutonost sa v podstate skoro cel venuje bezpenostnm
poiadavkm, avak poiadavkm nad pecifickm typom aktva, ktorm s utajovan skutonosti.
Ochrana utajovanch skutonost (povinnos postpen z E a NATO) bola dvodom vzniku
Nrodnho bezpenostnho radu v roku 2001. Vytvorenie optimlneho systmu ochrany
utajovanch skutonost je preto jeho primrnou lohou.
Samotn zkon chpe ochranu utajovanch skutonost ako sbor opatren, ktor pokrva vetky
zkladn oblasti, ktormi je personlna bezpenos, administratvna bezpenos, ifrov ochrana
informci, fyzick bezpenos, objektov bezpenos, bezpenos technickch prostriedkov a
priemyseln bezpenos. Meme kontatova, e najdetailnejie rozpracovanou oblasou, resp.
oblasou, ktorej je venovan najv draz je jednoznane oblas personlnej bezpenosti, v rmci
ktorej sa vykonvaj bezpenostn previerky na preverenie bezpenostnej spoahlivosti osoby, ktor
sa bude oboznamova s utajovanou skutonosou. Samozrejme pozornos je venovan aj zvynm
uvedenm oblastiam. Motivciou pre kladenie drazu na oblas personlnej bezpenosti boli
pravdepodobne praktick sksenosti a nepsan pravidlo, ktor hovor, e najslabm lnkom
v informanej bezpenosti je vdy udsk faktor.
Koncepciu ochrany utajovanch skutonost schvlila vlda Slovenskej republiky Uznesenm
. 475 zo da 30.5.2007. Dvodom schvlenia tejto koncepcie bolo najm formulovanie hlavnch
princpov ochrany utajovanch skutonost a systmovch poiadaviek na cieov systm ochrany
utajovanch skutonost v rmci SR.
Zkon . 215/2004 na ochranu utajovanch skutonost a o zmene a doplnen neskorch predpisov
(alej len zkon o US) teda upravuje podmienky na ochranu utajovanch skutonost, najm prva
a povinnosti prvnickch osb, obc a fyzickch osb pri ich ochrane. Zrove upravuje a definuje
psobnos Nrodnho bezpenostnho radu a psobnos alch ttnych orgnov zaoberajcich sa
utajovanmi skutonosami.
Pvodcom utajovanej skutonosti je prvnick osoba alebo fyzick osoba, ktor je oprvnen
rozhodn, e informcia alebo vec je utajovanou skutonosou, uri stupe utajenia a rozhodn o
zmene alebo zruen stupa jej utajenia.
Oprvnenou osobou je prvnick osoba alebo fyzick osoba, ktor je uren na oboznamovanie sa s
utajovanmi skutonosami, alebo ktorej oprvnenie na oboznamovanie sa s utajovanmi
skutonosami vzniklo zo zkona.
Nepovolanou osobou je fyzick osoba, ktor nie je oprvnen oboznamova sa s utajovanmi
skutonosami, alebo ktor nie je oprvnen oboznamova sa s utajovanmi skutonosami nad
rozsah, ktor jej je uren.
Zkladn povinnosti oprvnenej osoby s najm:
zachovva pred nepovolanou osobou a pred cudzou mocou mlanlivos o informcich

a veciach obsahujcich utajovan skutonosti poas utajenia tchto skutonost, a to aj po zniku
oprvnenia oboznamova sa s utajovanmi skutonosami,
dodriava veobecne zvzn prvne predpisy upravujce ochranu utajovanch skutonost,
oznmi neodkladne vedcemu neoprvnen manipulciu s utajovanmi skutonosami a zujem

nepovolanch osb o utajovan skutonosti a spolupracova s radom na objasnen prin
neoprvnenej manipulcie s utajovanmi skutonosami,
oznmi neodkladne vedcemu skutonos, ktor by mohla ma vplyv na jej oprvnenie

oboznamova sa s utajovanmi skutonosami, ako aj kad skutonos, ktor by mohla ma
vplyv na takto oprvnenie inej oprvnenej osoby.
347
Medzi zkladn povinnosti vetkch bench obanov, resp. nepovolanch osb, patr povinnos
neodkladnho odovzdania zskanej alebo njdenej utajovanej skutonosti NB alebo tvaru
Policajnho zboru. Prjemca takto odovzdanej utajovanej skutonosti je zrove na poiadanie
povinn vystavi odovzdvajcemu potvrdenie o jej prevzat.
Povinnosti vedceho ( 8)
Ochranu utajovanch skutonost je povinn zabezpei v ttnom orgne tatutrny orgn, v obci
starosta, vo vyom zemnom celku predseda a v inej prvnickej osobe tatutrny orgn (alej len
"vedci"). Ak je tatutrnym orgnom kolektvny orgn za vedceho sa v slade so zkonom o US
povauje psomne poveren len kolektvneho orgnu.
Vedci najm uruje zkladn vymedzenie utajovanch skutonost, lehoty, zmeny a zruenia stupa
utajenia. Uruje tie koncepciu ochrany utajovanch skutonost a vytvra podmienky na jej
zabezpeenie. Vytvra funkcie, pri ktorch vkone sa mu oprvnen osoby oboznamova
s utajovanmi skutonosami, zabezpeuje vykonanie bezpenostnej previerky 1.stupa, prpadne
iada rad o bezpenostn previerky vyieho stupa. Zabezpeuje pouenie osb, ktor sa maj
oboznamova s utajovanmi skutonosami stupa utajenia vyhraden postpenmi Slovenskej
republike cudzou mocou. Medzi alie jeho povinnosti patr napr. vedenie evidencie a zoznamov
oprvnench osb a osb, ktorm toto oprvnenie zaniklo, oznamuje radu zmenu rozsahu
oboznamovania sa s utajovanmi skutonosami, informuje rad o zaat plnenia loh vskumu,
vvoja, projekcie a vroby, oznamuje vopred radu prpravu a uzatvorenie medzinrodnej zmluvy
a vykonva alie opatrenia na seku ochrany utajovanch skutonost vyplvajce zo zkona o US.
Z pohadu informanej bezpenosti meme poveda, e medzi najdleitejie povinnosti patr
povinnos neodkladne oznamova NB neoprvnen manipulciu s utajovanmi skutonosami
a pokusy naruenia ochrany utajovanch skutonost a povinnos vypracova ron sprvu o
kontrole ochrany utajovanch skutonost, v ktorej je potrebn uvies najm daje o pote
vykonanch kontrol, zistench nedostatkoch a prijatch opatreniach na ich npravu.
alie svislosti tkajce sa organizcie
V svislosti s ochranou utajovanch skutonost, medzi alie povinnosti organizcie patria najm
povinnosti v oblasti ochrany objektov a chrnench priestorov, systmovch prostriedkov,
technickch prostriedkov a ifrovej ochrany informci. Meme poveda, e vetky tieto povinnosti
vyplvaj z medzinrodnch tandardov IB, avak v rmci tohto zkona s definovan pecificky pre
ochranu aktv, ktormi s utajovan skutonosti. Detailn poiadavky a popis konkrtnych opatren
je definovan v prslunch vyhlkach NB k zkonu o US.
12.4.3 Zkon . 351/2011 Z. z. o elektronickch komunikcich
Zkon upravuje podmienky na poskytovanie elektronickch komunikanch siet a sluieb,
podmienky na pouvanie rdiovch zariaden, regulciu elektronickch komunikci, prva
a povinnosti podnikov a uvateov elektronickch komunikanch siet a sluieb, ochranu
elektronickch komunikanch siet a sluieb a efektvne vyuvanie frekvennho spektra a sel.
Zaha tie paragrafy tkajce sa ochrany skromia a ochrany spracvania osobnch dajov v oblasti
elektronickch komunikci a ochrany telekomunikanho tajomstva. Netka sa vak obsahu sluieb,
ktor sa poskytuj prostrednctvom elektronickch komunikanch siet.
Uvate je osoba, ktor pouva, alebo poaduje poskytovanie verejnej sluby. Za uvatea sa
povauje aj astnk a koncov uvate. Koncov uvate je osoba, ktor pouva verejn slubu,
alebo poaduje jej poskytovanie a tto slubu alej neposkytuje a ani prostrednctvom nej
neposkytuje alie sluby. Koncovm uvateom je spotrebite, alebo v prpade rozhlasovch
a televznych programov aj posluch a divk.
348
Najdleitejou povinnosou pre jednotlivca z pohadu informanej bezpenosti je povinnos

zachovva telekomunikan tajomstvo. Telekomunikan tajomstvo je povinn zachovva kad,
kto prde s jeho predmetom do styku, i u pri poskytovan siet a sluieb, pri pouvan sluieb,
alebo nhodne, prpadne akmkovek inm spsobom.
Telekomunikanm tajomstvom sa rozumie:
obsah prenanch sprv,
svisiace daje komunikujcich strn, ktormi s telefnne slo, obchodn meno a sdlo
prvnickej osoby, alebo obchodn meno a miesto podnikania fyzickej osoby (podnikatea) alebo
osobn daje fyzickej osoby, ktormi s meno, priezvisko, titul a adresa trvalho pobytu,
prevdzkov daje a
lokalizan daje.
Predmetom telekomunikanho tajomstva nie s daje, ktor s zverejnen v telefnnom zozname.

Zkon definuje podnik, ktorm je kad osoba, ktor poskytuje sie, alebo slubu. Poskytovanie
siete, alebo sluby v oblasti elektronickch komunikci pre tretiu osobu je podnikanm. Zkon alej
vymedzuje psobnos orgnov ttnej sprvy v oblastiach, ktor zkon upravuje. Orgny ttnej
sprvy v oblasti elektronickch komunikci s Ministerstvo dopravy, vstavby a regionlneho
rozvoja SR a Telekomunikan rad SR.
Organizcia, resp. v zmysle defincie zkona podnik, je povinn prija zodpovedajce technick a
organizan opatrenia na ochranu bezpenosti svojich sluieb, a ak je to nevyhnutn, aj v sinnosti s
poskytovateom verejnej siete. Prijat opatrenia musia zabezpei tak rove bezpenosti sluieb,
ktor je primeran existujcemu riziku s ohadom na stav techniky a nklady na ich realizciu.
Zkon pamt aj na ochranu osobnch dajov, pretoe podniku dva aj povinnos informova
astnka o tom, ak osobn daje sa zskavaj a spracvaj, na zklade akho prvneho dvodu, na
ak el a ako dlho sa bud spracva. Tto informciu mus podnik poskytn najneskr pri
uzavret zmluvy o poskytovan verejnch sluieb.
Okrem tejto povinnosti s definovan aj kroky, ktor mus podnik, ktor poskytuje verejn sluby,
vykona pri poruen ochrany osobnch dajov. V takomto prpade mus podnik:
bezodkladne oznmi Telekomunikanmu radu SR poruenie ochrany osobnch dajov,
bezodkladne informova dotknutch astnkov a uvateov o poruen ochrany osobnch

dajov,
na poiadanie radu informova dotknutch astnkov a uvateov o poruen ochrany

osobnch dajov, ak poruenie ochrany osobnch dajov me ma negatvny vplyv na
dotknutch astnkov a uvateov,
vies zoznam prpadov poruen ochrany osobnch dajov, ktor obsahuje podstatn skutonosti
spojen s tmito porueniami, ich nsledky a prijat opatrenia na npravu.
pecificky sa bezpenosou zaober 63 o Telekomunikanom tajomstve a piata as o Ochrane

siet a zariaden (64).
Telekomunikan tajomstvo mono sprstupni radu, astnkovi a uvateovi, ktorho sa tka,
jeho oprvnenm zstupcom alebo prvnym nstupcom. Samozrejme zkon pamt aj na vnimky,
ktor s taxatvne vymenovan, a za ktorch je mon telekomunikan tajomstvo postpi napr.
inmu orgnu ttu. Takto vnimka mus by spravidla odobren sdom alebo vykonan na prkaz
sdu. Ide najm o prpady kedy s daje, ktor s predmetom telekomunikanho tajomstva,
potrebn napr. pre ptranie po nezvestnch osobch a odcudzench motorovch vozidlch alebo
mobilnch zariadeniach. Zkon aj v tomto prpade pamt na bezpenos a ochranu
349
telekomunikanho tajomstva, pretoe v takomto prpade, pokia podnik tieto informcie poskytuje
v elektronickej forme, mus ich poskytn len v zaifrovanom tvare.
Zkon zrove oetruje a definuje zkladn podmienky na bezpenos a integritu verejnch siet
a sluieb. Podnik, ktor poskytuje verejn siete alebo verejn sluby, je povinn prija
zodpovedajce technick a organizan opatrenia na ochranu bezpenosti svojich siet a sluieb,
ktor s ohadom na stav techniky musia zabezpei rove bezpenosti, ktor je primeran
existujcemu riziku. Opatrenia sa prijmaj najm s cieom predchdza bezpenostnm incidentom
a minimalizova vplyv bezpenostnch incidentov na uvateov a vzjomne prepojen siete.
Z defincie meme vidie, e samotn implementcia opatren by mala by zaloen, podobne ako
pri zkone o ochrane osobnch dajov, na tzv. Risk based approach prstupe, ktor najskr
vyaduje vykonanie analzy rizk.
Okrem uvedenho prstupu by sa mali poui aj opatrenia z oblasti zabezpeenia kontinuity
podnikateskch innost, pretoe zkon priamo od podniku, ktor poskytuje verejn siete, poaduje
udriavanie integrity svojich siet s cieom zarui kontinuitu poskytovania sluieb prostrednctvom
tchto siet.
Rovnako je na rovni zkona oetren aj oblas riadenia bezpenostnch incidentov, nakoko
podnik, ktor poskytuje verejn siete alebo sluby, je povinn bezodkladne informova rad
o naruen bezpenosti alebo integrity, ktor mali vznamn vplyv na prevdzku siet alebo sluieb.
Zrove, ak ide o osobitn riziko ohrozenia bezpenosti siete, poskytovate verejnch sluieb je
povinn informova dotknutch astnkov o tomto riziku a monostiach npravy vrtane
pravdepodobnch nkladov potrebnch na odvrtenie ohrozenia.
12.4.4 Zkon . 22/2004 Z. z. o elektronickom obchode
Zkon . 22/2004 Z. z. o elektronickom obchode (alej len zkon o EO) upravuje vzahy medzi
poskytovateom sluieb informanej spolonosti a ich prjemcom, ktor vznikaj pri ich komunikci
na diaku, poas spojenia elektronickch zariaden elektronickou komunikanou sieou a spovaj
na elektronickom spracovan, prenose, uchovvan, vyhadan, alebo zhromaovan dt vrtane
textu, zvuku a obrazu.
Zkon o EO tie upravuje dohad nad dodriavanm zkona a medzinrodn spoluprcu
v elektronickom obchode.
Sluby informanej spolonosti me poskytova kad fyzick osoba a prvnick osoba bez
povolenia, alebo registrcie. Toto sa vzahuje aj na poskytovatea sluieb, ktor poskytuje sluby
informanej spolonosti z lenskho ttu.
Poskytovate je povinn prjemcovi sluby na elektronickom zariaden poskytn informcie
o svojom nzve, obchodnom mene a sdle, daovom identifikanom sle, adrese elektronickej poty
a tel. sle a pod. Tieto musia by prjemcovi ahko a trvalo prstupn. Zavy a dary musia by od
benej komunikcie ahko rozliten a podmienky pre ich zskanie musia by prstupn,
zrozumiten a jednoznan. Poskytovate nesmie zasiela nevyiadan elektronick potu.
Ak poskytovate sluieb uskutouje komern komunikciu v mene alebo na et inej osoby, mus
by tto osoba identifikovan. Zkon ale alej neriei a nehovor akm spsob m by tto
identifikcia zabezpeen.
Ak poskytovate sluieb poskytuje sluby informanej spolonosti, nie je povinn sledova
informcie ani oprvnen vyhadva informcie, ktor sa prenaj alebo ukladaj. Ak sa vak
dozvie o protiprvnosti takch informci, je povinn odstrni ich z elektronickej komunikanej
siete alebo aspo zamedzi k nim prstup. Sd me nariadi poskytovateovi sluieb ich odstrnenie
350
z elektronickej komunikanej siete aj vtedy, ak sa poskytovate sluieb o ich protiprvnosti

nedozvedel.
alie paragrafy sa tkaj najm:
zmlv uzatvorench pomocou elektronickch zariaden ( 5),
vylenia zodpovednosti poskytovatea sluieb ( 6),
dohadu ( 7),
medzinrodnej spoluprce v elektronickom obchode ( 8).
12.4.5 Zkon . 576/2004 Z. z. o zdravotnej starostlivosti

Poslednm z prezentovanch zkonov je zkon . 576/2004 Z. z. o zdravotnej starostlivosti, slubch
svisiacich s poskytovanm zdravotnej starostlivosti a o zmene a doplnen niektorch zkonov (alej
len zkon o zdravotnej starostlivosti alebo zkon o ZS).
Tento zkon upravuje poskytovanie zdravotnej starostlivosti a sluieb svisiacich s poskytovanm
zdravotnej starostlivosti, prva a povinnosti fyzickch osb a prvnickch osb pri poskytovan
zdravotnej starostlivosti, postup pri mrt a vkon ttnej sprvy na seku zdravotnej starostlivosti.
Zkon o ZS priamo nedefinuje povinnosti pre jednotlivca ako takho z pohadu informanej
bezpenosti, ale prina minimlne niekoko opatren, ktor sa tkaj jednotlivca, resp. zdravotnej
dokumentcie vedenej o konkrtnom obanovi.
Priamo 20 zkona o ZS definuje formy vedenia zdravotnej dokumentcie a zrove zavdza aj
niekoko zkladnch opatren pri jej veden. Zdravotn dokumentcia sa historicky vedie primrne
v psomnej forme. Pokia vak poskytovate zdravotnej starostlivosti chce vies zdravotn
dokumentciu v elektronickej forme, me, ale mus by opatren elektronickm podpisom. Zkon
ale zrove ustanovuje aj vnimky a obmedzenia kedy, resp. ktor typ zdravotnej dokumentcie
neme by veden elektronicky, ale len vlune psomnou formou.
Otzkou pre prvnikov poda ns zostva fakt, i skutone ani takto definovan typy zdravotnej
dokumentcie nemu by veden elektronicky, pretoe 40 Obianskeho zkonnka hovor, e
psomn forma je zachovan vdy pokia je podpsan zaruenm elektronickm podpisom.
alm poda ns, tak trochu paradoxom, je fakt, e zkon jasne nepecifikuje koho elektronick
podpis m by na zdravotnej dokumentcii, v prpade jej vedenia v elektronickej forme, pouit.
Minimlne by malo s o elektronick podpis poskytovatea zdravotnej starostlivosti, ale urite by
bolo vhodn poui aj elektronick podpis prjemcu zdravotnej starostlivosti, ie vlastnka
zdravotnej dokumentcie, ktorm by zrove bolo potvrden poskytnutie a prijatie deklarovanej
zdravotnej starostlivosti.
Zkladn poiadavky na vedenie zdravotnej dokumentcie s:
zdravotn dokumentcia v elektronickej forme s elektronickm podpisom sa vedie na

zznamovom nosii v textovej forme, grafickej forme alebo v audiovizulnej forme,
zdravotn dokumentciu mono vies v elektronickej forme s elektronickm podpisom, len ak:
-
bezpenostn kpie dtovch sborov sa vyhotovuj poda tandardov zdravotnckej

informatiky najmenej jedenkrt za kad pracovn de,
o vytvorench zlonch kpich dtovch sborov sa vedie presn evidencia a tie sa

ukladaj na mieste prstupnom len osobm oprvnenm vyhotovova zlon kpie,
pred uplynutm doby ivotnosti zpisu na archvnom mdiu je z archivovanch dt

vyhotoven kpia a daje zo starho nosia sa odstrnia,
351
archvne kpie sa vytvraj najmenej jedenkrt za rok, priom spsob vyhotovenia

archvnych kpi znemouje vykona v nich dodaton zsahy.

Medzi zkladn povinnosti organizcie, poskytovatea zdravotnej starostlivosti, ktor vedie
zdravotn dokumentciu patria poiadavky ohadom zabezpeenia a uchovvania zdravotnej
dokumentcie. Zkon o ZS jasne definuje zodpovednos, poda ktorej za zabezpeenie zdravotnej
dokumentcie zodpoved poskytovate. Poskytovate je povinn uklada a ochraova zdravotn
dokumentciu tak, aby nedolo k jej pokodeniu, strate, znieniu alebo k zneuitiu. Pokia chce
poskytovate tto poiadavku naplni, nezostva mu ni in len implementova opatrenia prslunch
tandardov z oblasti informanej bezpenosti.
Okrem zkladnch bezpenostnch opatren s definovan aj poiadavky na jej archivciu.
Zdravotn dokumentciu, ktor vedie veobecn lekr, uchovva poskytovate 20 rokov po smrti
osoby. In zdravotn dokumentcia sa archivuje 20 rokov od poslednho poskytnutia zdravotnej
starostlivosti prslunej osobe.
Poskytovate je zrove povinn zabezpei, aby k osobitnej zdravotnej dokumentcii nemali prstup
in osoby ako oetrujci lekr a v nevyhnutnom rozsahu oprvnen zdravotncki pracovnci.
12.5 Prehad relevantnej legislatvy E vzahujcej sa na riadenie IB

Legislatva EU zlepuje globlne podmienky pre dveru a bezpenos medzi lenskmi krajinami.
Zavedenm veobecne zvznch pravidiel vo forme zkonov vytvra prostredie pre efektvnu
medzinrodn spoluprcu v potlan kybernetickho zloinu a svisiacich rizk.
Medzinrodn prvo upravuje autorsk prvo a ochranu duevnho vlastnctva. pecializovan
agentra OSN, ktor bola zaloen v roku 1970 pod nzvom Svetov organizcia duevnho
vlastnctva (WIPO), m prispieva k ochrane duevnho vlastnctva na celom svete prostrednctvom
spoluprce medzi 184 lenskmi ttmi. Slia na to Parsky zvz (Medzinrodn zvz na ochranu
priemyslovho vlastnctva) a Bernsk zvz (Medzinrodn zvz na ochranu literrnych
a umeleckch diel). Zaober sa tie administratvou 23 medzinrodnch zmlv, ktor sa zaoberaj
priemyslovm vlastnctvom a autorskm prvom. WIPO Copyright Treaty ochrauje potaov
programy a databzy a WIPO Performance and Phonograms Treaty chrni prva umelcov [2].
OSN tie vydalo manul pre prevenciu a kontrolu potaovho zloinu, ktor menuje konkrtne
orgny zaoberajce sa kybernetickm prvom. Ide predovetkm o OSN, Radu Eurpy, Organizciu
pre hospodrsku spoluprcu a rozvoj (OECD). Manul sa zaober konkrtne kyberterorizmom,
kybernetickou vojnou a tzv. Hi-tech hrozbami [2].
Elektronick zmluvn prvo (e-commerce) predstavuje al dleit dokument, ktorm je vzorov
zkon pre elektronick podpisy z roku 2001, ktor zavdza zkladn kritria pre zavdzanie
elektronickho podpisu. Takisto Konvencia OSN vydan v roku 2005 riei pouvanie elektronickch
prostriedkov v medzinrodnch obchodnch zmluvch.
innos Medzinrodnej obchodnej komory v Pari (ICC, MOK) zaha vydanie doloiek Incoterms
z roku 2000, ktor sa zaoberaj elektronickou vmenou informci [2].
Dleitm je tie dohovor Rady Eurpy . 185 o kybernetickej kriminalite zo da 23.11.2001, ktor
sa stal innm 1.7.2004. Jeho hlavnou lohou je harmonizcia niektorch zkladnch skutkovch
podstt a zavedenie efektvneho reimu spoluprce medzi jednotlivmi ttmi. Dohovor definuje
vznamn pojmy ako je potaov systm, potaov dta, poskytovate sluby apod. Neskr bol
k tomuto dohovoru pripojen Dodatkov protokol zo da 28.1.2003, ktor sa zaober renm
xenofbneho a rasistickho obsahu. Vyplnil tm medzery Dohovoru, ktor okrem detskej
pornografie problematiku kodlivho obsahu neupravuje. Upravuje tie skutkov podstaty 9
zkladnch trestnch inov, ktor s rozdelen do 4 skupn. Najzvanejie s trestn iny svisiace
s detskou pornografiou. Spchanie trestnho inu mus by myseln, teda vyluuje nedbalos.
352
Dodaton nleitosti zahaj jednania spsobujce zvan kodu, spchanie inu vo vzahu k PC
systmu a pod [2].
EU vydala mnostvo smernc a inch zvznch dokumentov, tkajcich sa priamo i nepriamo
problematiky internetovch deliktov. S to napr.:
Smernica Rady 91/250/EHS zo da 14.05.1991, o prvnej ochrane potaovch programov.
Rozhodnut Rady 92/242/EHS zo da 31.03.1992, o bezpenosti informanch systmov.
Rmcov rozhodnutie Rady 2000/375/JHA zo da 29.05.2000, o boji proti detskej pornografii na

Internete.
Rmcov rozhodnutie Rady 2001/413/SVV zo da 28.05.2001 o potieran podvodov a falovania

bezhotovostnch platobnch prostriedkov.
Smernica Eurpskeho parlamentu a Rady 96/9/ES zo da 11.03.1996 o prvnej ochrane databz.
Smernica Eurpskeho parlamentu a Rady 2000/31/ES zo da 08.06.2000 o elektronickom

obchode.
Smernica Eurpskeho parlamentu a Rady 2002/19/ES zo da 07.03.2002 o prstupe k sieam

elektronickch komunikci a priradenm zariadeniam a o ich vzjomnom prepojen.
Smernica Eurpskeho parlamentu a Rady 2002/20/ES o oprvnen pre siete a sluby.
Smernica Eurpskeho parlamentu a Rady 2002/22/ES zo da 07.03.2002 o univerzlnej slube a

prvach uvateov tkajcich sa siet a sluieb elektronickch komunikci.
Smernica Eurpskeho parlamentu a Rady 2002/58/ES zo da 12.07.2002 o skrom a

elektronickch komunikcich.
Rmcov rozhodnut Rady 2005/222/SVV zo da 24.02.2005 o tokoch proti informanm

systmom.
Smernica Eurpskeho parlamentu a Rady 2006/24/ES o uchovvan dajov vytvranch alebo

spracovvanch v svislosti s poskytovanm verejne dostupnch sluieb elektronickch
komunikci alebo verejnch komunikanch siet a elektronickch komunikci (autorizan
smernica).
Spolon postoj Rady . 16/2009 zo da 16.02.2009 o zmene niektorch smernc.
Tieto smernice s len zlomkom vetkch dokumentov, ktor Eurpska nia vydala v svislosti
s harmonizciou ttnych legislatv v oblasti informanej bezpenosti a svisiacich oblast. [2]
Vo februri tohto roka Eurpska komisia zverejnila stratgiu pre oblas kybernetickej bezpenosti
(tzv. otvoren, bezpen a chrnen kybernetick priestor), ktorej snahou je definova spolon
politiku lenskch ttov v tejto oblasti. Stratgia definuje nasledovn zkladn oblasti, resp. priority:
dosahovanie odolnosti voi kybernetickm tokom,
prudk znenie potaovej kriminality,
rozvjanie politiky a spsobilost kybernetickej obrany, ktor svisia so spolonou bezpenostnou

a obrannou politikou,
rozvjanie priemyselnch a technologickch zdrojov na ely kybernetickej bezpenosti,
vytvorenie politiky sdrnho medzinrodnho kybernetickho priestoru pre Eurpsku niu a

presadzovanie zkladnch hodnt E [7].
353
Poda [7] komisia zrove zverejnila aj pripravovan smernicu o opatreniach na zabezpeenie

vysokej spolonej rovne bezpenosti siet a informci v celej nii, ktor je hlavnm
mechanizmom, vyplvajcim z tejto stratgie. Medzi hlavn opatrenia smernice patria nasledovn:
lensk tt mus prija nrodn stratgiu bezpenosti siet a informci a uri vntrottny
orgn prslun pre bezpenos siet a informci, disponujci dostatonmi finannmi
a udskmi zdrojmi, na ely predchdzania rizikm a incidentom v tejto oblasti, ich rieenia a
reagovania na ne,
vytvra sa mechanizmus spoluprce medzi lenskmi ttmi a Komisiou na ely vzjomnho

vasnho varovania o rizikch a incidentoch prostrednctvom chrnenej infratruktry a na ely
spoluprce a organizcie pravidelnch hodnoten,
prevdzkovatelia mimoriadne dleitch infratruktr v niektorch pecifickch odvetviach,

poskytovatelia sluieb informanej spolonosti a orgny verejnej sprvy musia prija postupy
riadenia rizk a podva sprvy o vznamnch bezpenostnch incidentoch.
12.6 Vntorn legislatva organizcie v oblasti riadenia IB

Ako sme u spomenuli, norma ISO 27002 poskytla vzor pre legislatvny rmec pre metodiky
a tandardy informanej bezpenosti vo vnose MFSR . 312/2010 Z. z. o tandardoch pre
informan systmy verejnej sprvy. Norma ISO 27002 hovor o legislatvnom slade so zkonmi,
ale aj o slade so smernicami. Aj ke sa niektor legislatvne normy venuj nielen veobecnm
nleitostiam, ale v niektorch prpadoch uvdzaj aj znan detaily, napr. v prpade vyhlok k
zkonu o elektronickom podpise (napr. obsah bezpenostnch dokumentov, reim kov, nleitosti
bezpenostnho plnu a pod), i v prpade vyhlky k zkonu o ochrane osobnch dajov (o rozsahu
a dokumentcii bezpenostnch opatren), nie je tto rove dostaton pre ely konkrtnej
organizcie, pretoe kad organizcia m svoje pecifick podmienky, i u riadenia alebo
prevdzky. Prve tmto pecifickm podmienkam je potrebn venova zven pozornos
a zohadni ich pri tvorbe internej legislatvy organizcie (tzv. smernc v oblasti riadenia informanej
bezpenosti).
Medzi oblasti, ktor by sa mali implementova v rmci vntornch smernc riadenia informanej
bezpenosti organizcie, patria najm dobr praktiky definovan v ISO 27002 a v zkone
o informanch systmoch verejnej sprvy (ISVS). Organizcie teda nemaj povinnos vyma
iadne nov prevdzkov tandardy, ale mu si natudova a osvoji tieto veobecn normy. Po ich
prevzat je mon prava poda konkrtnych poiadaviek a pecifk organizcie.
Inak povedan intern smernice by mali jednoznane vychdza z aktulnej legislatvy a noriem
a mali by poskytn primeran rove detailu prispsoben konkrtnym podmienkam organizcie,
ktor samozrejme neme poskytn legislatva alebo veobecn normy. Jednotliv smernice alebo
akty riadenia by mali poskytova dostatok informci pre osoby, ktorm s uren, aby tieto osoby
mali jasne definovan svoje prva, povinnosti, innosti a lohy, ktor sa od nich v rmci organizcie
oakvaj, najm v svislosti s informanou bezpenosou.
12.7 Anonymita a skromie vs. monitorovanie zamestnancov

spene a efektvne riadenie IB si za uritch okolnost vyaduje monitorovanie aktivt v rmci
informanch systmov, ktor s predmetom ochrany. Pod pojmom aktivity rozumieme v prvom
rade aktivity systmu ako takho z pohadu jeho efektvneho fungovania, manamentu kapact
prevdzky a pod., ktorch vyhodnocovanie nm pomha zabezpei IS najm z pohadu aspektu jeho
dostupnosti, prpadne integrity. Nakoko je vak potrebn zabezpei systm aj z pohadu
zachovania dvernosti spracovvanch, uchovvanch alebo prenanch dt je potrebn
monitorova aj aktivity jednotlivch pouvateov systmu, i u internch alebo externch.
354
Prve pri monitorovan tchto aktivt vak prevdzkovate systmu me narazi na rzne
obmedzenia a prva monitorovanch osb, vyplvajce z legislatvneho rmca, najm z pohadu
zachovania ich skromia alebo prpadnej anonymity.
Prvo na skromn ivot a jeho ochranu je zakotven u v Dohovore Rady Eurpy o ochrane
udskch prv a zkladnch slobd z roku 1950, v lnku 7 Charty zkladnch prv E a rovnako aj
v druhom oddiely stavy SR. Okrem tchto predpisov je mon urit formulcie ohadom
skromia njs aj v Obianskom zkonnku.
Okrem prva na skromie, by vak malo by, v slade s lnkom 22 stavy SR, zaruen aj listov
tajomstvo, tajomstvo dopravovanch sprv a inch psomnost a ochrana osobnch dajov. Poda
tohto lnku nikto nesmie porui listov tajomstvo ani tajomstvo inch psomnost a zznamov, i
u uchovvanch v skrom, alebo zasielanch potou, alebo inm spsobom. Rovnako sa zaruuje
tajomstvo sprv podvanch telefnom, telegrafom alebo inm podobnm zariadenm. Samozrejme
vnimkou mu by prpady, ktor ale musia by ustanoven na rovni zkona. Ide napr.
o bezpenos ttu, vyetrovanie kriminlnych inov a pod.
Toto prvo sa vak v svislosti so zabezpeenm informanej bezpenosti, resp. ochrany dajov v IS,
dostva do konfrontcie s ochranou prv zamestnvatea a jeho podnikateskch innost, resp.
v prpade verejnej sprvy, zkonom danch innost. Problmom, resp. bodom konfrontcie, me
by aj fakt, e v zujme zamestnvatea monitorova zamestnancov asto nebva len ochrana
informci, ale napr. aj sledovanie efektivity ich pracovnej innosti, vyuvanie pracovnho asu,
vyuvanie zdrojov zamestnvatea na prpadn skromn aktivity a pod.
Meme poveda, e v rmci legislatvy SR, je tejto problematike najvia pozornos venovan
v Zkonnku prce (zkon . 311/2001 Z. z. Zkonnk prce).
Poda lnku 11 zkladnch zsad Zkonnka prce me zamestnvate o zamestnancovi
zhromaova len osobn daje svisiace s kvalifikciou a profesionlnymi sksenosami
zamestnanca a daje, ktor mu by vznamn z hadiska prce, ktor zamestnanec m vykonva,
vykonva alebo vykonval.
Konkrtnejie sa problematike skromia na pracovisku v svislosti s monitorovanm zamestnancov
venuje 13 Zkonnka prce, ktor okrem inho hovor:
Zamestnvate nesmie bez vnych dvodov spovajcich v osobitnej povahe innost
zamestnvatea nara skromie zamestnanca na pracovisku a v spolonch priestoroch
zamestnvatea tm, e ho monitoruje, vykonva zznam telefonickch hovorov uskutoovanch
technickmi pracovnmi zariadeniami zamestnvatea a kontroluje elektronick potu odoslan z
pracovnej elektronickej adresy a doruen na tto adresu bez toho, aby ho na to vopred upozornil.
Ak zamestnvate zavdza kontroln mechanizmus, je povinn prerokova so zstupcami
zamestnancov rozsah kontroly, spsob jej uskutonenia, ako aj dobu jej trvania a informova
zamestnancov o rozsahu kontroly, spsobe jej uskutonenia, ako aj o dobe jej trvania.
Pokia by sme sa pozreli na uveden definciu podrobnejie urite by sme si vimli minimlne dve
zsadn skutonosti. Tou prvou je, e zamestnvate mus ma vny dvod nara skromie
zamestnanca. Druhou je fakt, e zamestnvate by mal zamestnancov informova o rozsahu kontroly,
spsobe jej uskutonenia, ako aj o dobe jej trvania.
Naneastie zkon nepecifikuje, o s to vne dvody a ani neuvdza iadne prklady, o presne by
sa mohlo povaova za vny dvod, ktor by oprvoval zamestnvatea k uvedenm innostiam
monitorovania a narania skromia. Mme za to, e monitorovanie z pohadu bezpenosti, t.j.
zachovania dvernosti, integrity a dostupnosti informanch aktv zamestnvatea me by
povaovan za vny dvod v zmysle vyie uvedenej defincie zkona.
Nemalo by sa vak zabda na informovanie zamestnancov o tom, e takto kontroly s na
pracovisku realizovan. Zrove by mal by rozsah a spsob tchto kontrol primeran elu a nemal
by nara skromie zamestnanca viac ako je pre dan el nevyhnutn. Vetky pouit kontroln
a monitorovacie opatrenia by nemali zasahova do skromia zamestnanca, t.j. mali by sa pouva
355
nstroje a postupy, ktor napr. sleduj prtomnos vrusov alebo inho kodlivho softvru, alebo
zaznamenvaj aktivity v systme, ale ktor nevykonvaj, z pohadu ochrany skromia, neiaducu
analzu obsahu e-mailovej komunikcie, obsahu prezeranch strnok na internete, neodpovaj
telefonick alebo IP komunikciu a pod. Inak povedan mali by sa zaznamenva len daje typu
dka hovoru alebo prstupu, slo volanho alebo ID osoby v prpade chatu, dtum a hodina zaiatku
a konca udalosti a pod. Zamestnvate by sa mal vyvarova neprimeranm zsahom do skromia,
ktorm me by napr. sledovanie obrazovky zamestnanca, monitorovanie stlaench klves (tzv.
keylogger) sledovanie obsahu skromnch e-mailov, odpovanie komunikcie a pod.
Samozrejmosou Zkonnka prce je okrem inho aj prvo zamestnanca, ktor sa domnieva, e jeho
skromie na pracovisku alebo v spolonch priestoroch bolo naruen, domha sa prvnej ochrany
na sde.
12.8 Etika a morlny kdex

Kde kon zkon, nastupuje etika a morlny kdex. Aj tmito slovami by sa dal charakterizova
vznam slov etika a morlny kdex, najm vzhadom na skutonos, e zkony a prvne predpisy
nedoku, a ani nemu definova vetky potrebn detaily a konkrtne kroky alebo postupy.
V uritch pecifickch prpadoch je preto potrebn definova urit zsady rozumnho sprvania
sa, tzv. morlne kdexy. Definovanie tchto zsad me, v niektorch prpadoch, sli aj na
zvenie profesionlneho renom a dveryhodnosti v konkrtnu organizciu alebo spolonos, resp.
ud, ktor s jej sasou. Definovanie a samozrejme aj riadenie sa prslunmi etickmi
a profesionlnymi kdexmi meme vidie najm pri organizcich zaoberajcimi sa oblasou
riadenia, bezpenosti a kontroly informanch systmov a technolgi (napr. medzinrodn
organizcia ISACA - Information Systems Audit and Control Association).
Etika je vznamnm predpokladom pre formovanie spoloenskho ducha. innos jedinca sa sklad
z rozlinch rozhodnut, ktor maj rozdielny rozsah priaznivch a nepriaznivch dopadov na ivot
ostatnch jedincov existujcich v tej istej spolonosti (a vyuvajcich tie ist technologick rieenia
a informan prostriedky). Chpeme ju ako nuku o udskch zmeroch, rozhodnutiach a vzahoch.
Etika sama o sebe nepodva trukturlny rmec, ani dobr prax pre sprvne rozhodovania, nesna sa
diktova jednotlivcom v spolonosti, ako sa maj sprva. Namiesto toho tuduje vzahy a mravn
postoje, aby mohla lepie porozumie uritm pohntkam a spsobom rozhodovania tchto jedincov.
Toto porozumenie me sli k zostaveniu pecifickch pravidiel a systmov morlnych princpov,
ktor ovplyvuj nae jednanie. Obecn etika a hlavn etick smery tvoria neodmysliten sas
demokratickej kultry bez ohadu na existujce technolgie. Dodriavanie etickch princpov pri
pouvan Internetu a IKT vbec je zkladnm predpokladom udrania bezpenosti ttu a skromia
obanov. V svislosti so sasnm trendom v oblasti rozvoja technolgi a ich priaznivch dopadov
na n kadodenn ivot je tie nutn poukza na etick a morlnu strnku pouvateov a rovnako
aj sprvcov tchto technolgi. Predstava toho, o jedinec povauje za sprvne vychdza z postojov,
hodnt a pravidiel, ktor sa menia vzhadom na okolie a kultru. Obe strany (subjekt prijmatea aj
morlne vzory, ktor ns obklopuj) s menn v ase a kontexte, ktor me by politick,
spoloensk a technologick. Jedinec si vytvra urit hodnotov preferenciu na zklade uritch
stretov hadsk a hodnt vtepovanch odpozorovanm sprvania poda veobecne akceptovanch
noriem. Tieto veobecne prijman normy sprvania mu by formalizovan a preveden do
prvnych noriem a prkazov, tm dochdza k vytvoreniu legislatvneho rmca, alebo do noriem
platnch v rmci organizcie. Od legislatvy sa neformalizovan etika li tm, e nie je prvne
zakotven a jej poruenie neme by sdne vymhan, za uritch podmienok vak me by stle
sankcionovan.
Naa sloboda je zvisl na mnohch initeoch, ktor nm zrove poskytuj zkladn oporu pre
osobn rozvoj. Kad jedinec by mal preto poskytova ostatnm priestor na tak osobn slobodu,
ak si sm el ma a tm vytvori zklad pre rozvoj vzjomnej cty [12].
356
Tvorba, sprstupovanie a renie informci masovm mdiom, ako je Internet ponka platformu pre
formovanie charakteru jedincov koexistujcich v spolonosti. Vzrast preto potreba definovania
morlnych pravidiel pre narbanie s informciami.
Nedostatok informci me ma za nsledok nesprvne formovanie rebrka hodnt a s tm
svisiace nesprvne rozhodovanie. Dostatok informci tie nie je zrukou toho, e jedinec bude
rozhodova sprvne, je preto dleit vyvi mnostvo prijmanch informci s ich hodnotou vo
vzahu k individulnym cieom a kultrnym zvyklostiam. Zkladnm predpokladom slobodnho
rozhodovania je prsun pravdivch informci a prve Internet vytvra vkonn platformu pre renie
poloprvd a nepravdivch informci. Kontrola nad distribuovanmi informciami v tak irokej a
technologicky diverzifikovanej sieti je problematick. Napriek tomu, e zrove vytvra idelne
podmienky na renie osobnho nzoru, vystavuje ns tie riziku, e vyjadrenm vlastnho nzoru
narume inak dobre fungujce vzahy. Sloboda slova a prejavu, je jednm zo zkladnch udskch
prv a tvor zklad demokratickej spolonosti. Preto prve sloboda slova mus nasledova urit
pravidl diplomacie a za iadnych okolnost nesmie poruova, alebo obmedzova prva ostatnch
[12].
12.8.1 Morlne kdexy
Profesijn kdexy nie s prvne zakotven, tvoria len urit pomocn rmce pri rozhodovan
v hraninch situcich, vychdzaj z obecnej etiky a spoloenskch princpov.
Morlny kdex profesionla v oblasti IT by mal vychdza z niekokch zkladnch princpov:
chrni prvo na skromie pouvateov informanho systmu, ktor spravuje,
repektova prvo na duevn vlastnctvo, zsady intelektulnej slobody,
dodriava zsady ochrany osobnch dajov, zakotven v legislatve,
nepresadzova vlastn zujmy na kor pouvateov,
zodpovedne zabrni cenzre,
dodriava hranice medzi vlastnm presvedenm a profesijnmi povinnosami.
12.8.2 Potaov kriminalita a etick hacking

Meme kontatova, e etick hacking je v podstate auditom, t.j. hodnotenm bezpenosti systmu,
vrtane pokusu o naruenie danho systmu pomocou rovnakch technk, ak by v praxi pouil
nebezpen tonk. Samotn naruenie systmu sa nazva penetranm testom. Cieom takejto
innosti je poskytn objednvateovi auditu sprvu o zranitenostiach, ktor mu pome zbavi sa
vetkch zranitenost testovanho systmu, idelne ete predtm, ne by mohol by vystaven
relnemu riziku.
V rmci etickho hackingu organizcie dochdza spravidla k manulnemu posudzovaniu bezpenosti
sieovej infratruktry, vo vine prpadoch aj s vyuitm automatizovanch nstrojov. Samotn
vstup automatizovanch nstrojov nie je ani zaleka postaujci, pretoe hrozby svisiace so
zranitenosami sa navzjom zosiluj a spolu predstavuj omnoho vyie riziko, ktor mus by
posden sksenm profesionlom v oblasti informanej bezpenosti.
Pred vykonanm auditu sa zvyajne podpisuje zmluva, ktor definuje v akom rozsahu a do akej hbky
bude testovanie bezpenosti preveden. Dohaduje sa tie rove agresivity, ktor mu etick hackeri
pri tejto innosti poui, aby sa neohrozila produkn, alebo inak dleit infratruktra, definuj sa
prpadn miery sankci, ktor vyplvaj z nedodrania podmienok zmluvy a pod.
357
12.9 Verejn obstarvanie IKT

Ministerstvo financi Slovenskej republiky rznymi nvrhmi opatren prispelo k elnmu,
transparentnmu a efektvnemu obstarvaniu IKT. Na zklade podnetov od odbornej aj laickej
verejnosti vydalo Nvrh opatren na zvenie transparentnosti v svislosti s nkupom a vyuvanm
informano-komunikanch technolgi vo verejnom sektore. Nsledne boli vypracovan rzne
metodick usmernenia.
alm dleitm initeom, ktor prispel k vyej transparentnosti verejnho obstarvania je zkon
. 25/2006 Z. z. o verejnom obstarvan a o zmene a doplnen niektorch zkonov. Je dleit
korigova pokrytie biznis procesov informanmi systmami a podporova konkurenn prostredie,
nediskriminova rzne spsoby poskytovania sluieb pri nkupe prostriedkov IKT. Prve tento zkon
o verejnom obstarvan m za lohu zaisti nezvislos projektov na konkrtnych proprietrnych
rieeniach a zabrni nevyhnutnej zvislosti objednvatea na konkrtnych dodvateoch.
rad pre verejn obstarvanie zrove vydal aj metodick usmernenie [13], ktorho hlavn body s
zhrnut v nasledovnom texte.
Predmet zkazky m by vymedzen jednoznane, zrozumitene, plne a nestranne. Technick
poiadavky maj by uren tak, aby zabezpeili rovnak prstup pre vetkch uchdzaov.
Technick poiadavky sa nesm odvolva na konkrtneho vrobcu, vrobn postup, znaku, patent,
typ, krajinu, oblas alebo miesto pvodu. Pokia nemono opsa predmet zkazky dostatone presne
a zrozumitene, je mon poui odkaz na normy, tandardy, osvedenia, environmentlne
charakteristiky, priom takto odkaz mus by doplnen slovami alebo ekvivalentn. Je vhodn
vyui medzinrodn metodiky a tandardy (ITIL, Rational Unified Process, Extreme Programming,
a pod.). Technick pecifikcie by mali spa opisn spsob s funknmi parametrami. Preto je
sprvne pecifikova napr. databzov softvr s podporou min. vekosti databzy 2GB, ale
konkrtne nemenova MS SQL, My SQL, Oracle, DB2, Sybase a pod.. Pri hardvri je idelne
pouitie orientanch kritri, tzv. benchmarkov. Pri obstarvan softvru je jedinm obmedzenm
tkajcim sa technickch pecifikci neuvdzanie znaky resp. vrobcu. Orientan kritri
benchmarky pre softvr v praxi neexistuj, ale existuj urit porovnaten vlastnosti. Vsledky
porovnvania vrazne zvisia od poskytovatea takchto tatistk a pouitej metdy.
Pri vytvran technickch pecifikci sa postupuje tzv. dvojrovovou technikou, teda najprv sa
zadvaj rmcov pecifikcie a nsledne s spresnen ako prloha dodvateskej zmluvy. Je
dleit, aby u rmcov pravidl pomerne presne popisovali oakvan funkcionality a vstupy.
Existuje riziko, e dodvate vypracuje to, o chce on a nie to, o chce objednvate. Je preto
potrebn pozna prostredie verejnho obstarvatea (tdie uskutonitenosti, analzy nkladov a
prnosov) a vyvodi potrebn opatrenia.
Pri obstarvanie softvru s hlavnm kritriom tzv. celkov nklady na vlastnctvo softvru (tzv.
TCO - Total Cost of Ownership). Verejn sprva by mala pri obstarvan softvru zabezpei
rovnak podmienky pre posudzovanie softvru. Mali by by tie vyslen a zohadnen nklady na
prpadn odstpenie od pouvania licencie (po ukonen trvania kontraktu). Cieom obstarvania by
malo by vyvarovanie sa tzv. uzamknutiu sa, teda zvislosti na dlhodobom kontrakte s jedinm
dodvateom. V prpade, e dodvate ponka softvr tretej strany, jeho cena mus by plne
transparentn, t.j. v slade s trhovou hodnotou.
alm nrokom je podpora otvorench tandardov, tzn. verejn sprva by mala pouva otvoren
tandardy pri technickej pecifikcii obstarvanch tovarov a sluieb. Pri obstarvan by mala
poadova tak softvrov rieenia, ktor s v slade s otvorenmi tandardami, m sa zvi poet
potencilnych dodvateov a vyhne sa uzamknutiu na jedinom konkrtnom.
Zabezpeenie znovu pouitia softvru znamen, e ak m verejn sprva majetkov prva k systmu,
nvrhu alebo architektre, tak pri novej zkazke, ktor spa predpoklad na znovu pouitie ho vyuije
a nebude vyvja obdobn projekt odznova.
358
Metodick usmernenie tie predpoklad zabezpeenie leglnosti pouvania softvru vytvorenho na

zkazku. Pri nkupe softvru by sa verejn sprva mala prezentova ako jedna entita a tm
zabezpei prenositenos softvru. Metodick usmernenie odpora, aby dodvka tovaru bola vo
forme tzv. EUPL licencie (GPLv2 kompatibiln) vade tam, kde je to mon.
Pri vbere dodvatea je nutn uprednostni o najniie nklady na vyuvanie SW z dlhodobho
hadiska (napr. na obdobie 4 rokov) a odpora sa, aby verejn obstarvate uskutonil prieskum
trhu, t.j. vykonal intern, alebo extern analzu produktov na trhu.
Pre ely stanovenia predpokladanej hodnoty zkazky nie je mon zkazku umelo rozdeli.
Stanovenie hodnoty zkazky na poskytnutie sluieb je nronejie ako stanovenie hodnoty zkazky
na dodanie tovaru, preto je potrebn ohodnoteniu sluieb venova zven pozornos.
12.9.1.1 Verejn obstarvanie IKT a bezpenos
Problmom pri verejnom obstarvan bva napr. vysok pecifickos mnohch IKT
projektov, pre ktor na trhu neexistuje dostatok dodvateov. Tm je vznamne poruen
etick pravidlo a povinnos nezaujatho a transparentnho obstarvania. Inm prpadom
me by skutonos, e dodan produkt sce vkonnostne zodpoved poiadavkm, ale
nastvaj kolzie s kompatibilitou s existujcim prostredm IKT objednvatea. m lepie je
popsan predmet zkazky, tm menej prce a problmov pri obstarvan IKT nastane.
Na zklade aktulnych sksenosti a praxe meme kontatova, e neoddelitenou sasou
sanch podkladov by mali by aj poiadavky:
z pohadu bezpenosti rieenia a poadovanej bezpenostnej funkcionality obstarvanch

systmov a aplikci,
na vykonanie, od dodvatea nezvislho, posudzovania kvality implementcie,
na vykonanie nezvislho auditu sladu s poiadavkami legislatvy, najm vnosu MFSR

o tandardoch pre ISVS, ete pred ukonenm a odovzdanm diela,
na vykonanie nezvislho bezpenostnho auditu systmov a aplikci a auditu sladu naplnenia

definovanch bezpenostnch poiadaviek, rovnako pred odovzdanm a akceptovanm
samotnho diela.
Uveden prstup umouje efektvne vynakladanie prostriedkov, nakoko prpadn nedostatky musia
by odstrnen v rmci dodvky a nie a na zklade dodatonch change requestov za dodaton
finann nklady. Zrove sa eliminuje riziko, e bude do prevdzky spusten systm, ktor
predstavuje bezpenostn riziko pre dta a informcie, ktor tento systm spracovva.
Je dleit zabezpei aby bezpenos bola integrlnou sasou projektu, t.j. u jeho vodnch
analytickch fz a samozrejme aj fzy nvrhu rieenia a samotnej implementcie a zverench
testov. Vo vea prpadoch je bezpenos len okrasn prvesok, ktor sa na rieenie zaves niekedy
na konci projektu, alebo vbec.
Rovnako je potrebn myslie na poiadavky tkajce sa testovanie systmu, najm ak bude potrebn
niektor testy vykona na produknch, tzv. ostrch dtach, napr. v testovacom prostred
dodvatea. V tomto prpade sa odpora zvoli vhodn typ anonymizcie tchto dt, tak aby
anonymizovan dta nemali iadnu vypovedaciu hodnotu ale zrove aby spali poiadavky
potrebn na samotn testovanie funknosti systmu.
V prpade obstarvania zloitejch systmov, resp. systmov, kedy sasou dodania nie je len
produkn prostredie ale napr. aj vvojov alebo minimlne testovacie prostredie je potrebn
v poiadavkch zadefinova aj prslun bezpenostn poiadavky vyplvajce z uvedenej
skutonosti, napr. poiadavky na infratruktru, sieov prostredie, prpadne aj fyzick oddelenie
jednotlivch prostred a pod.
359
Rovnako je potrebn pri uzatvran zmluvnho vzahu s vybranm dodvateom pamta aj na tzv.
NDA (Non Disclosure Agreement) dohody, ie ustanovenia o zachovvan mlanlivosti
a samozrejme aj na tzv. SLA (Service Level Agreement) dohody, ktor pecifikuj rovne
poskytovanch sluieb, najm pre ely drby a servisu ale aj v prpade, e dodvate priamo
poskytuje (outsourcuje) slubu, ktor by mal za tandardnch okolnost poskytova objednvate.
12.10 Forenzn analza

Cieom forenznej analzy je spravidla potvrdi, alebo vyvrti podozrenie z neleglnej innosti, t.j.
usvedi pchatea, alebo dokza nevinu obvinenho. Na tento el sa poda prsnych pravidiel
zskavaj dkazy z tzv. dkazovch mdi tak, aby tieto dkazy neboli napadnuten na sde.
alm krokom v postupe je analyzova zskan dkazy a bezpene ich uchova. Medzi etick
pravidl, ktor je forenzn analytik povinn pri spracovan dodra patr prezentcia vsledkov
analzy iba oprvnenm adrestom.
Legislatva v oblasti sdneho vyetrovania viazan na aspekty forenznej analzy je pokryt sdnym
poriadkom, zkonom o znalcoch a zkonom o policajnom zbore. Uveden zkony iastone
stanovuj aj to, ak postupy je vhodn pri forenznej analze zvoli.
Postupy pri forenznej analze vak spravidla nasleduj rmec [14]:
prprava,
otvorenie prpadu,
zskavanie dkazov,
bezpen uchovanie dkazov,
analza dkazov,
vytvorenie hlsenia,
uzatvorenie prpadu,
svedectvo.
12.10.1
Poiadavky na zaistenie dkazov pouitench v prvnych konoch
Dkazovmi mdiami s v prpade vyetrovania bezpenostnch incidentov spravidla pevn disky,

flash disky, CD a DVD, pamov karty. Zkladnou dobrou praktikou v svislosti s vyetrovanm je
vytvori bitov obraz analyzovanho mdia.[14]
Tento by mal by vytvoren na tento el certifikovanmi nstrojmi, ktor doku urobi obraz
pamovho mdia jedna k jednej, vrtane przdneho pamovho miesta, resp. miesta aktulne
neobsadenho iadnym sborom. Nie vetky nstroje, ktor doku urobi napr. obraz HDD s na
takto innos vhodn, pretoe vina komernch alebo aj free produktov vykonva len obraz
obsadenho pamovho miesta a navye pre znenie nrokov na kapacitu uloenia takto
vytvorenho obrazu realizuj aj komprimciu tchto dt.
Operan pam je mon vyetrova pri zapnutom zariaden, ktorho funkn stav nie je dobr
vychyova, dochdza tm k neiaducemu pozmeneniu informci o tom, ako bol pota pouvan
v ase incidentu. Problmom je, e stav pamte sa pri beiacom systme men bez ohadu na aktivity
svisiace s forenznou analzou.
Forenzn analza pamovch modulov vyuva fakt, e ben mazanie je nedokonal za
normlnych okolnost vymazan dta s vysokou pravdepodobnos nie s vymazan bezpene. Pokia
pchate nepouil sofistikovan spsoby niekokonsobnho vymazania a prepsania disku
vygenerovanmi nhodnmi dtami, je mon ich obnova a tie zistenie asu vymazania.
360
alm dkazovm materilom s logy sieovch zariaden a serverov poskytujcich sluby, pokia
sa uchovvaj relatvne, resp. vzhadom na konkrtny prpad dostatone dlho. Okrem prpadnho
vyhodnocovania incidentov je mon ich poui aj na optimalizciu prevdzky systmu alebo siete.
Logovacie zznamy sieovch zariaden sa tie asto exportuj do geograficky vzdialench lokalt
a preto je u aj v mlo zloitch infratruktrach takmer nemon sa ich zbavi.
Dkazy je mon zbiera pri aktvnom zariaden (in vivo), alebo pri neaktvnom zariaden (post
mortem) [14].
Pri prvom spsobe sa najefektvnejie analyzuje operan pam a je mon z nej vydolova vek
mnostvo informci. Pri realizcii tohto druhu analzy na systme je neprpustn dverova vstupu
aplikci systmovch binrnych sborov naintalovanch na inkriminovanom systme. Je preto
uiton ma k dispozcii dveryhodn binrne sbory. Sbory zskavan z tohto druhu analzy maj
rzne stupne volatility (doasnosti). Preto sa dostupnmi prostriedkami zskava v prvom rade
cache procesora, neskr me nasledova obraz pamte RAM, swap pam, pevn disky a pamov
mdi USB, CD a DVD mdi. Tento spsob zskavania dkazov umouje obs pln ifrovanie dt
uloench na disku, pretoe s odifrovan pouitm kov uloench v operanej pamti. Tieto
ke je mon z beiaceho systmu extrahova. Tto techniku vyuvaj naprklad aj tonci pri
pokusoch o kompromitciu beiacich systmov metdou cold boot attack.
Druh spsob analzy je menej komplikovan, vyaduje niiu rove expertzy. Nevhodou me
by, pri uritch typoch incidentov, niia efektivita zskavania relevantnch dkazov a tie ich
niie konen mnostvo. V takomto prstupe sa pomocou pecifickch nstrojov analyzuje zskan
obraz mdia.
Pri vyetrovan bezpenostnch incidentov sa postupuje v slade s niekokmi hlavnmi atribtmi,
ktormi s:
korektnos meme zarui, e zskan dta s toton s dtami na originlnom mdiu,
autentickos zskan dta sme skutone zskali z analyzovanho zariadenia v danom ase,
integrita dta, ktor sme zskali, nesm by pozmenen voi originlu,
minoritne tie dvernos a dostupnos, ktor ale nie s priamym predmetom vyetrovania,
opakovatenos kad krok vyetrovania je mon zopakova na zklade dokumentcie

s pouitm bezpene uloench originlnych dkazovch materilov,
akceptovatenos metda mus by sdom akceptovan ako legitmna,
spoahlivos metda mus by dokzatene sprvna,
logick nadvznos na predmet prpadu.
ifrovanie dt obvinenmu pome zachova ich dvernos, ale prtomnos ifrovacieho softvru,
alebo priamo zaifrovanie celho disku me nepriamo naznaova snahu pchatea o skrvanie
dkazov. Rovnako je to s prtomnosou steganografickch nstrojov urench na skrvanie dt do
zdanlivo bench multimedilnych sborov, akmi s obrzok, alebo audio/video sekvencia. Pre
obvinenho je asto rozumnejie si v prpade steganografie vytvori a aplikova vlastn algoritmus.
Pri steganografii sa toti d uplatni podobn pravidlo ako pre pouvanie ifrovania, e ak obvinen
dokzatene pouil steganografick nstroj, me to by pre sd nepriamym nznakom jeho viny.
Tieto prpady je vak nutn posudzova v svislosti s inmi faktami, ktor s o obvinenom znme
nebolo by legitmne obvinenho odsdi kvli pouvaniu anonymizanch technk, ifrovania, alebo
steganografie, ktorch vyuvanie je inak na zem Slovenskej republiky celkom leglne.
Nstroje, ktorch vrobcovia proklamuj, e maj tzv. anti-forenzn funkcionalitu s asto
neinn. Znienie dt, ktor slia ako materil pre forenzn analzu, je v praxi vemi nron. Ani
fyzick likvidcia asto nie je postaujca, urit asti dt je mon zrekontruova aj zo znienho
361
mdia. Pre vyiu presnos zisten je uiton dkazy zskan pri forenznej analze IKT doplni
metadtami a nedigitlnymi dkazmi a tm zska komplexn obraz o incidente [14].
12.11 Zver
V svislosti s informatizciou sa verejn sektor stva zvislm na robustnch informanch
systmoch a ich uplatnen, najm v oblasti zdravotnctva, energetiky, verejnej sprvy
a elektronickho obchodu. Je prakticky nerealizovaten riei zabezpeenie IKT systmov pomocou
individulnych projektov a je nutn stanovi systematick bezpenostn poiadavky. innosti
koordincie ochrany digitlneho priestoru s zo zkona zabezpeovan viacermi ttnymi aj
nettnymi intitciami. Legislatva v oblasti informanej bezpenosti vznamne prispela k zlepeniu
stavu informanej bezpenosti v Slovenskej republike.
Zrove meme kontatova, e m pozitvny trend, nakoko boli identifikovan aktivity ohadom
prpravy a prijmania alch novch predpisov, ako je napr. zkon o informanej bezpenosti.
Je vak potrebn si uvedomi, e prijatm samotnch zkonov sa problm s informanou
bezpenosou nevyriei. Vvoj v oblasti IKT a aj v oblasti zranitenosti a ich zabezpeovania je
fenomn, ktor sa ned zastavi, take tto imaginrnu a virtulnu vojnu o bezpenos systmov
a nimi spracovvanch, prenanch alebo uchovvanch informci bude potrebn vies neustle.
Z uvedenho dvodu je potrebn, aktulnym podmienkam a okolnostiam, neustle prispsobova nie
len samotn systmy, ale aj prslun legislatvne rmce.
362

[1]
Trestn prvo. Wikipedia, slobodn encyklopdia. [Online] [Dtum: 24. 7 2013.]

http://sk.wikipedia.org/wiki/Trestn%C3%A9_pr%C3%A1vo.
[2]
Alica Virdzekov. Trestnoprvna prava internetovej kriminality. Katedra trestnho prva.

[Online] [Dtum: 3. 7 2013.] http://is.muni.cz/th/210734/pravf_m/DP_tisk.pdf.
[3]
Potaov kriminalita, duevn vlastnctvo. Ministerstvo vntra Slovenskej republiky.

[Online] [Dtum: 21. 6 2013.] http://www.minv.sk/?pocitace-dusevne.
[4]
Daniela Greguov, Miroslav Chlipala, Boris Susko. Autorskoprvna ochrana potaovch

programov na Slovensku. Prvne minimum. [Online] [Dtum: 21. 6 2013.]
http://www.epi.sk/66/Autorskopravna-ochrana-pocitacovych-programov-naSlovensku_6648.aspx.
[5]
Petr Krm. Zkon o kybernetick bezpenosti: co v nm stoj? Root.cz. [Online] [Dtum:

27. 9. 2013.] http://www.root.cz/clanky/zakon-o-kyberneticke-bezpecnosti-co-v-nemstoji/#ic=articles-related&icc=zakon-o-kyberneticke-bezpecnosti-nutny-zbytecny-cinebezpecny-18352.
[6]
VS. Nrodn politika pre elektronick komunikcie. [Online] [Dtum: 27. 9. 2013.]
http://www.telecom.gov.sk/index/open_file.php?file=telekom/Strategia/Politika/NPEK2009/
NPEK_09_13.pdf.
[7]
Informatizacia.sk. Aktulna legislatva pre oblas informatizcie spolonosti v gescii

Ministerstva
financi
SR.
[Online]
[Dtum:
1.
7
2013.]
http://www.informatizacia.sk/legislativa-sr/684s.
[8]
Ochrana osobnch dajov po novom - zkon . 122/2013 Z.z. [Online] [Dtum: 2. 7 2013.]
http://www.zrrlz.sk/informacie-zrrlz/5-i359/ochrana-osobnych-udajov-po-1-7-2013.
[9]
Daniel J. Solove. I've got nothing to hide and other misunderstandings of privacy. [Online]
[Dtum: 27. 9. 2013.] http://crysp.uwaterloo.ca/courses/pet/F07/cache/solove.pdf.
[10] CSIRT.SK.
Informan
brora.
[Online]
[Dtum:
http://www.csirt.gov.sk/img/infobrochure.pdf. DataCentrum. MFSR.
19.
2013.]
[11] Elektronick podpis a PKI. Sluby informanej bezpenosti. KPMG Slovensko s.r.o.
[12] Viliam Vateha. Wikileaks z hadiska informanej etiky. Masarykova univerzita v Brn.
[13] Metodick pokyn pre tandardn nleitosti verejnho obstarvania a zmlv pre IKT v1.0.
[Online]
[Dtum:
22.
8
2013.]
http://www.informatizacia.sk/ext_dokmetodicky_pokyn_std_obstaravanie_1-0/15176c. MFSR.
[14] Mgr. Luk Hlavika. Forenzn analza IKT. [Online] [Dtum: 24. 7 2013.]
http://www.dcs.fmph.uniba.sk/~gazi/uib/materialy/forensic.pdf
363
13 Potaov kriminalita a jej vyetrovanie

Frantiek Sovi
13.1 vod
S rastcim nasadenm modernch informano-komunikanch technolgi (IKT) rastie aj poet
potaovch bezpenostnch incidentov, ktorch nsledky mu znane obmedzi alebo pokodi
aktivity kadej intitcie alebo organizcie. Aj pri vemi dobre prepracovanom manamente
informanej bezpenosti treba pota so vznikom bezpenostnho incidentu. Pritom urit as
incidentov me ma a trestnoprvnu povahu, resp. mono ich zaradi do kategrie potaovej
kriminality. V tomto prpade kov rolu zohrvaj dveryhodn, vasne zskan, korektne a sprvne
zabezpeen stopy, ktor mu by pouit nielen pri vyetrovan, ale aj ako dkazy pri eventulnom
sde. Dodaton zskavanie dkazov me by vemi komplikovan loha, niekedy a nevykonaten.
Preto pri preetrovan vetkch incidentov (nielen zrejme kriminlnych) treba hne od poiatku
postupova akoby ilo o trestno-prvnu zleitos.
13.2 Predpoklady ochrany pred incidentmi

Kad intitcia alebo organizcia mus chrni svoje innosti a biznis procesy pred akmkovek
naruenm bezpenostnmi incidentmi (alej len incidenty). Nevyhnutnm predpokladom spenho
identifikovania, rieenia i preetrovania incidentov je vytvori nleit organizan, materilne
a odborn podmienky na to, aby bolo mon rozpozna a nsledne reagova na incidenty. Metodolgia
reakcie na incidenty typicky zdrazuje nielen prpravu, ale predovetkm prevenciu pred incidentmi,
a to zaistenm dostatonej bezpenosti systmov, siet a aplikci.
Hlavnm predpokladom spenho zvldania incidentov v organizcii je existencia aspo jednho
odbornka - analytika v organizcii, ktor pozn problematiku bezpenostnch incidentov, je schopn
rozpozna incident a okamite posdi jeho zvanos a nsledne aj adekvtne reagova. Tomuto
odbornkovi sa aj v organizcii nahlasuj bezpenostn incidenty. Existencia takhoto odbornka (a
jeho innos) je v sasnosti povaovan za zkladn podmienka korektnho plnu reakcie na incident
[5]. V mench organizcich me tto rolu vykonva bezpenostn manar, vo vch je vhodn
ma vylenenho pecialistu len na otzky bezpenostnch incidentov.
V procese rieenia incidentov je detekcia incidentu najaou lohou. Analytik na rieenie
potaovch bezpenostnch incidentov (alej budeme pouva analytik incidentov) je
zodpovedn za analyzovanie nejednoznanch a neplnch symptmov a mus vedie uri, o sa
deje, resp. o sa vlastne stalo. Aj ke existuj urit automatizovan technick prostriedky, ktorch
pouitie o nieo zjednoduuje detekciu incidentov, stle najlepm rieenm je zsah sksenho
odbornka, ktor je schopn inne a rchle analyzova prznaky a vykona vhodn akcie. Bez
takhoto odbornka bude detekcia a analza incidentov neefektvna a nsledne mu by prijat drah
alebo chybn rozhodnutia.
Vemi dleit je tie udra poet incidentov nzky (napr. sprvnym aplikovanm ISMS), aby
analytik incidentov nebol zahlten a mal dos asu adekvtne na incidenty reagova. V prpade, e
bezpenostn opatrenia nie s dostaton, me sa vyskytn vek poet incidentov, na ktor potom
analytik nie je schopn primerane reagova. Neprimeran reakcia na incident me vies k spomaleniu
a neplnej reakcii, ktor sa prejavia negatvnejm dopadom na pracovn procesy (napr. rozsiahlejie
kody, dlhia doba nedostupnosti dajov a sluieb), a v neposlednej rade aj v strate uritch stp o
incidente.
Na mieste je porovnanie s problematikou poiarnej bezpenosti kad organizcia mus ma
ohlasovu poiarov, poiarnu hliadku a poiarneho technika (bu vlastnho alebo externho).
364
Potaov kriminalita a jej vyetrovanie | MF SR
Podobne treba ma aj ohlasovu potaovch bezpenostnch incidentov a hliadku pre

bezpenostn incident, ktor ovlda aj potrebn kontakty pre eventulne alie postupy.
Samotn zbieranie stp o incidente je u komplikovanejia zleitos, ktor vyaduje - z viacerch
dvodov - viaclenn tm pozostvajci zo sksench a vysokokvalifikovanch lenov na rieenie
bezpenostnch incidentov (vysvetlen v alom).
13.3 Potaov kriminalita

Pod pojmom potaov kriminalita sa mysl kriminalita, kde cieom alebo nstrojom zloinnho
toku s informan systmy a ich komponenty. Teda nielen potae, programy, dta, ale aj
telekomunikan siete a zariadenia, a aj neautomatizovan zloky ako s sprvcovia,
prevdzkovatelia, pouvatelia, dotknut osoby, a pod. Mono by bolo vhodnejie hovori o
informatickej kriminalite, ale termn potaov je veobecne zauvan (v zahraninej literatre
sa meme stretn aj s termnom kybernetick kriminalita, resp. cybercrime).
V zsade mono trestn iny spadajce do oblasti potaovej kriminality rozdeli do 3 kategri:
1
Trestn iny vo vzahu k hmotnmu IKT majetku, t.j. k hardvrovm komponentom IS (krdee
a pokodenia potaov, ich prsluenstva, telekomunikanch prostriedkov a nosiov informci
a pod.).
Trestn iny vo vzahu k nehmotnmu IKT majetku, t.j. k programovmu vybaveniu, databzam,
k inm dajom, resp. k informcim spracovvanm v uritom prostred IKT.
Trestn iny, pri ktorch je pota prostriedkom k ich pchaniu. Ide najm o tzv. hospodrsku
kriminalitu pchan s pouitm potaov (podvody, sprenevery, at.), ale aj in trestn innos
realizovan prostrednctvom potaov (napr. ohovranie, podnecovanie i schvaovanie
trestnho inu, detsk pornografia, krdee digitlnej identity a pod.).
Prv kategria potaovej kriminality sa v mnohom odliuje od ostatnch dvoch. Logicky sce patr
do druhej kategrie, ale je pecifick pri jej identifikovan. V podstate ide o klasick zloin
odcudzenia alebo pokodenia hmotnej veci - majetku, preto sa dnes chpe skr ako majetkov
kriminalita v klasickom vzname. Pri preetrovan tchto incidentov je takmer okamite zrejm, e
ide o trestn in (nieo evidentne chba alebo je pokoden alebo znien - na posdenie oho netreba
zvltne schopnosti). Nsledn aktivity evidentne spadaj do kompetencie policajnch orgnov, ktor
pri preetrovan zbieraj skr fyzick stopy (napr. daktyloskopick stopy), vpovede svedkov,
zznamy z kamier, a pod.
Ostatn dve kategrie mono chpa ako trestn iny s nehmotnou podstatou IKT, resp. kriminalitu
svisiacu s digitlnym obsahom prostriedkov IKT. Tento druh kriminality si vyaduje aj nov metdy
vyetrovania, v ktorch kovm dkazom zvyajne je tzv. digitlna stopa.
13.3.1 Digitlna stopa
V slovenskom prvnom systme - ako v oblasti verejnho prva, tak aj v oblasti skromnoprvnej plat princp neobmedzenho predkladania dkazov a ich vonho hodnotenia prslunm orgnom
verejnej moci. Poda trestnho poriadku me za dkaz sli vetko, o me prispie k objasneniu
veci, predovetkm vpovede svedkov, znaleck posudky, veci a listiny, dokumentcia inu,
obhliadka a tie zaisten stopy [2].
Kad technologick zariadenie, ktor zskava, spracovva, prena alebo uchovva dta, zanechva
zznamy (obrazy) o svojej innosti. V oblasti IKT je to predovetkm digitlna stopa, ktor mono
definova ako akkovek informcia s vypovedacou hodnotou uloen alebo prenan v digitlnej
365
Potaov kriminalita a jej vyetrovanie| MF SR
binrnej forme, ktor me by predloen sdu ako vecn dkaz s vypovedacou hodnotou (defincia
poda Scientific Working Group on Digital Evidence) [1]. V tejto defincii je kladen draz na
predkladanie dkazu sdu, a prve predloitenos dkazu sdu je hlavnm kritriom spenosti
korektnho a spravodlivho vyrieenia takhoto incidentu. Uveden defincia je otvoren akejkovek
technolgii: digitlna stopa pokrva nielen potae a informan systmy, ale aj oblas digitlnych
prenosov (mobiln telefny, digitlnu TV), digitlne video- a audio- zznamy, digitlne fotografie,
dta kamerovch systmov a elektronickch zabezpeovacch systmov a pod.
Originlne digitlne stopy sa nachdzaj na fyzickch objektoch, ktormi s produkn
technologick nosie informci [2]. V praxi s to pevn disky potaov, rzne pamov mdi
(diskety, CD a DVD disky, pamov karty, dtov psky at.). Originlna digitlna stopa m
najvyiu vypovedaciu hodnotu a je aj sdne bez problmov akceptovan ako dkaz. Ale zaistenie
fyzickho objektu (napr. celho potaa) je dos problematick, nakoko ten bva sasou
informanho systmu v produkcii, alebo je dokonca fyzick objekt geograficky na inom mieste (napr.
server aj v inej krajine). Preto sa dnes zvyajne pracuje s dupliktom digitlnej stopy, o je presn
digitlna reprodukcia vetkch dtovch objektov obsiahnutch na originlnom fyzickom objekte na
fyzick rovnak typ dtovho mdia (kompletn image vytvoren v pomere 1 : 1). V prpade, kedy
nie je mon zaisti fyzick objekty s originlnymi digitlnymi stopami, je nutn vyhotovi dva
duplikty stopy jeden bude uloen a zapeaten na bezpenom mieste (napr. v trezore) pre potreby
sdu ako referenn a s druhm (pracovnm) sa vykonva kriminalistick forenzn analza. Urit
problm nastva v situcii diakovho prstupu, pokia sa nedostaneme k fyzickmu nosiu dt
a zhotoveniu dupliktu vetkch bitov nachdzajcich sa na vzdialenom nosii dt v pomere 1 : 1 nie
je mon. Potom pracujeme s tzv. kpiou digitlnej stopy, kedy vytvrame dtov objekty
s rovnakm informanm obsahom, ale na fyzick mdium, ktor me by odlinho typu ne je
pvodn fyzick objekt (lebo nevieme zisti jeho typ). Musme vak pota s tm, e takto nemusme
zska vetky informcie, ktor mu by na pvodnom mdiu skryt alebo nekoprovaten. Ich
preukazn hodnota pred sdom je preto slabia.
Kad pochybenie pri zskavan a zabezpeovan digitlnych stp sa pri dkaznom riaden na sde
me vypomsti, alebo me da obvinenmu pchateovi do rk monosti ako spochybni cel
procesn alebo i vecn vyetrovanie potaovho zloinu.
13.3.2 Zbieranie digitlnych stp a zaobchdzanie s nimi
V slovenskom prvnom systme (z formlneho hadiska) kriminalistick stopy (aj digitlne) sa stvaj
dkazmi iba vtedy, ak s akceptovan sdom, resp. orgnmi innmi v trestnom konan. Teda je urit
prvny formlny rozdiel medzi stopou a dkazom (v anglosaskej literatre sa toto nezvykne
rozliova, lebo vetko je dkaz - evidence).
V sdnom konan je dleit jasne zdokumentova, ako boli vetky stopy (potencilne dkazy)
zskan a nsledne aj ochrnen - vrtane kompromitovanho systmu. Digitlne stopy musia by
vyzbieran poda procedr, ktor s v slade s prslunmi zkonmi, a je vhodn riadi sa pokynmi
prvnikov, prpadne na zklade predchdzajcich diskusi s orgnmi innmi v trestnom konan tak,
aby tieto stopy boli prijaten pre sd ako dkazy. O kadej stope ako potencilnom dkaze mus by
veden detailn zznam nasledujceho zloenia [4]:
366
identifikcia nosia informcie (naprklad miesto, sriov slo, slo modelu, meno
uzla, adresa MAC sieovho rozhrania, adresa IP sieovej karty uzla),
meno, priezvisko a slo telefnu kadho jednotlivca, ktor zbieral alebo narbal s dkazom
poas vyetrovania incidentu,
dtum a as kadho narbania s potencilnym dkazom,
miesto uloenia dkazu.
Zbieranie digitlnych stp zo zdrojov potaa m niektor zloitosti. Vo veobecnosti je iaduce

zska stopu zo systmu ihne ako vzniklo podozrenie, e sa incident mohol vyskytn. Vea
incidentov spsobuje dynamick vskyt reaze udalost, ktor treba zachyti. Prvotn snmka systmu
(zaznamenanie okamitho stavu systmu) je omnoho prospenejia pri identifikcii problmu a jeho
zdrojov, ne vina ostatnch akci vykonanch v tejto etape. Z dkaznho pohadu je omnoho lep
snmok systmu ako momentlne je ne vykona snmok a potom, o analytici, systmov
administrtori a al svojou nepozornosou alebo aj nemyselne zmenili stav systmu poas
vyetrovania. Pouvatelia a administrtori si musia by vedom postupov, ktor musia dodra, aby
zachovali pvodn stopu.
Pred koprovanm sborov z napadnutho prvku (potaa, uzla a pod.) je asto iaduce zachyti
prechodn informcie, ktor nemu by zaznamenan do systmovho sboru alebo zlohy (image
backup), ako s sasn sieov spojenia, login relcie, otvoren sbory, konfigurcie sieovch
rozhran a obsah pamti. Tieto prechodn informcie mu obsahova vodtko k identite tonka a k
pouitej metde toku. Tie je dleit zdokumentova odchlku loklnych hodn uzla od skutonho
asu. S ist rizik spojen so zbieranm informci zo ivho systmu, lebo kad vykonan aktivita
na uzle sama o sebe zmen stav uzla. A navye, na ivom systme me by stle prtomn tonk,
ktor me detegova aktivity analytika.
13.3.3 Zaisovanie dkazov bezpenostnch incidentov
Pretoe efektvna reakcia na incidenty je komplexn loha, vytvorenie tmu reakcie na incidenty a na
rieenie incidentov vyaduje primeran zdroje a organizan opatrenia. Samozrejme, menie
spolonosti a organizcie si zvyajne nemu dovoli zamestnva tm pecialistov na rieenie
bezpenostnch incidentov. Je to zvykom len vo vekch firmch alebo pecializovanch intitcich,
na ktor sa v prpade potreby mono obrti (na odporanie vlastnho odbornka na bezpenostn
incidenty v vode spomnan ohlasova bezpenostnch incidentov) [4,5].
Nepretrit monitorovanie hrozieb bezpenostnmi nstrojmi, ako s naprklad IDS a antivrusov
ochrana, je zkladnou podmienkou. Rozhodujcim je jednak zavedenie jasnch procedr
ohodnocovania aktulneho a potencilneho dopadu incidentov na pracovn innosti organizcie ako aj
implementcia efektvnych metd zbierania dajov, analyzovania a oznamovania incidentov. Je tie
dleit vytvori vzahy a zavies vhodn komunikan mechanizmy s ostatnmi tvarmi organizcie
(napr. prvny tvar, personlny tvar).
Sksen analytik mus by schopn iba pomocou minimlneho potu prkazov zozbiera aj dynamick
stopy bez toho, aby nechcene zmenil nsledn stopy. Jednoduch, ale zle vybrat prkaz me
nevratne znii dkaz. Navye, vykonva prkazy napadnutho potaa je tie nebezpen, pretoe
prkazy mu by zmenen alebo nahraden (naprklad Trjsky k, rootkits) z dvodu skrvania
informci alebo spsobenia alej kody. Analytici musia pouva prkazy a ostatn potrebn sbory
z dveryhodnch zdrojov (z floppy disku alebo CD s ochranou na zpis) tak, aby vykonvan prkazy
sa realizovali bez intervencie kdu alebo pouvania sborov z napadnutho systmu. Analytici mu
tie poui programy s blokovanm zpisu, ktor brnia systmu zapisova na vlastn disk potaa.
Ako u bolo spomenut, bezprostredne po zozbieran prechodnch dajov mus analytik vytvori
kpie diskov v pomere 1 : 1 na mdi s ochranou proti zpisu, pretoe takto obsahuj vetky daje
z napadnutch diskov, vrtane zruench sborov a sborovch fragmentov. Ak sa predpoklad, e
zozbieran stopy o incidente bud predmetom sdneho konania alebo internho disciplinrneho
konania, mus analytik urobi aspo dve pln kpie diskov, sprvne ich oznai a jednu kpiu
bezpene uloi vlune ako referenn bude pouit ako dkaz.
367
13.3.4 Analza digitlnych stop

Prehliadac softvr je dleit nielen na zskanie obrazu disku (image), ale tie na automatizciu
viny procesov analzy. Zvyajne je potrebn:
identifikovanie a obnovenie fragmentov sborov, skrytch a zruench sborov a adresrov

z ubovonej lokcie disku (ako s naprklad pouit a von priestor),
preverenie truktr sborov, ich hlaviiek a alch charakteristk s cieom uri, ak typy
dajov kad sbor obsahuje, nespoliehajc sa na znaku rozrenia sborov (naprklad .doc,
.jpg, .mp3),
zobrazenie obsahu vetkch grafickch sborov,
vykonanie komplexnho prehadania,
grafick zobrazenie adresrovej truktry zskanho mdia,
vytvranie sprv, a pod.
Poas zbierania digitlnych stp je rozumn zska aj kpie logovacch sborov z ostatnch
podpornch zdrojov (naprklad logy z bezpenostnej brny - tie ukazuj IP adresu pouit pri toku).
Takisto ako pri zbieran stp z disku a inch mdi, musia by logovacie sbory zapsan a uchovan
na mdium s ochranou proti zpisu. Aj tu jedna kpia logovacch sborov mus by uloen ako
referenn (neskr me predstavova dkaz), zatia o druh me by pouit pri obnoven stavu
systmu pri incidente pre potreby analzy. Mnoh analytici na ochranu integrity uloench logovacch
sborov pouvaj kryptografick haovaciu funkciu, pomocou ktorej vypotaj ich haovacie
hodnoty (message digest). Podobne, ako v prpade postihnutho uzla, musia analytici zaznamena
loklny as podpornho zdroja a jeho odchlku od relneho asu.
Analytik me pri analze incidentu poadova opakovanie aspektu incidentu, ktor nebol adekvtne
zaznamenan. Naprklad, pouvate sa pripojil k kodlivej web strnke, ktor potom kompromitovala
jeho pracovn stanicu. Pritom na pracovnej stanici nezostal iaden zznam o toku. Analytik me na
in pracovn stanicu naintalova odchytva paketov a bezpenostn softvr, pripoji sa k tej istej
web strnke ete raz, zaznamena a analyzova tok a zisti, o sa vlastne stalo. Analytik mus by
vemi opatrn pri duplikcii takchto tokov, aby svojou aktivitou nemyselne nespsobil vskyt
inho incidentu.
13.3.5 Prprava na rieenie incidentov
Je vhodn, aby tm pre bezpenostn incidenty mal prichystan tzv. pohotovostn kufrk (jump kit), o
je vlastne prenosn kufrk obsahujci materil, ktor bude pravdepodobne len tmu potrebova pri
vyetrovan incidentu mimo stleho pracoviska. Pohotovostn kufrk mus by vdy plne pripraven,
pretoe kedykovek me vznikn v spolonosti vny incident a len tmu si ho vyzdvihne a
presunie sa na miesto vyetrovania incidentu. Pohotovostn kufrk typicky obsahuje [4]:
laptop vybaven vhodnm softvrom (napr. paketov sniffer, prehliadae),

zlohovacie zariadenia, przdne mdi,
zkladn sieov zariadenia a kble,
generan mdium s operanm systmom s aktulnymi zplatami OS,
aplikan programov vybavenie,
poznmkov blok na poznmky,
fotoapart (mono poui aj zabudovan v mobilnom telefne).
Zmyslom pohotovostnho kufrka je umoni rchlejiu reakciu: len tmu si nemus na mieste
vyetrovania incidentu poiiava materil, pretoe si ho prinesie v kufrku. Cena za vybavenie
368
pohotovostnho kufrka a jeho udriavanie sa organizcii vrti v znen dopadu incidentu, pretoe
vymedzenie incidentu bude pomocou pohotovostnho kufrka rchlejie a efektvnejie. Takisto
zbieranie digitlnych stp, ktor mono neskr bud pouit aj ako dkazn materil pred sdom,
bude od poiatku uskutoovan poda poadovanch procedr.
Tm pre bezpenostn incidenty mus pri preetrovan incidentu dokumentova kad vykonan krok.
Ak tm doiel k zveru, e sa incident vyskytol, mus rchlo vykona prvotn analzu a uri rozsah
incidentu (ktor siete, systmy alebo aplikcie boli postihnut), kto a odkia spsobil incident a ako sa
incident realizoval (ak boli pouit nstroje alebo metdy toku, ktor zranitenosti boli zneuit).
Prvotn analza mus poskytn dostatok informci, aby si tm stanovil prioritu nslednch aktivt,
ako s vymedzenie incidentu a podrobnejia analza inkov incidentu. V prpade pochybnost mus
tm na rieenie predpoklada najhor prpad, pokia dodaton analzy neuku inak.
V procese rieenia incidentov je najaou lohou prve detekcia incidentu. Analytici incidentov s
zodpovedn za analyzovanie nejednoznanch a neplnch symptmov, a musia uri, o sa vlastne
stalo. Aj ke existujce technick rieenia o nieo zjednoduuj detekciu incidentov, najlepm
rieenm je vytvorenie tmu na rieenie incidentov pozostvajceho zo sksench a
vysokokvalifikovanch lenov, ktor s schopn inne a rchle analyzova prekurzory
a nznaky/prznaky incidentov a vykona vhodn akcie. Bez dobre trnovanho a schopnho tmu
bude detekcia a analza incidentov neefektvna a mu by prijat drah alebo chybn rozhodnutia.
tvar na rieenie incidentov mus preetrova kad incident. Mus rchlo vykona prvotn analzu
a uri rozsah incidentu (ktor siete, systmy alebo aplikcie boli postihnut, kto alebo odkia spsobil
incident a ako sa incident realizoval, ak boli pouit nstroje alebo metdy toku, ktor zranitenosti
boli zneuit). Prvotn analza mus poskytn tvaru na rieenie incidentov dostatok informci, aby
bolo mon stanovi prioritu nslednch aktivt, ako s vymedzenie incidentu a podrobnejia analza
inkov incidentu. V prpade pochybnost mus tvar na rieenie incidentov predpoklada najhor
prpad, pokia dodaton analzy neuku in vlastnosti incidentu.
13.3.6 Identifikcia tonka
Pri preetrovan incidentu je asto vznesen poiadavka (napr. od vlastnkov aktv) na identifikciu
tonka. Aj ke tto informcia me by dleit najm v prpade, ke organizcia chce poda
trestn oznmenie na tonka, musia sa lenovia tmu na rieenie incidentov sstredi na vymedzenie
a odstrnenie incidentu a obnovu po incidente. Identifikcia tonka je asto asovo nron proces
(a nezriedka aj mrny), ktor odahuje analytikov od dosiahnutia ich primrneho ciea
minimalizcie dopadu incidentu na obchodn aktivity spolonosti. alej s opsan najastejie
vykonvan innosti na identifikciu tonka [5]:
369
Potvrdenie tonkovej IP adresy analytik me sksi potvrdi pomocou sluieb ping,

traceroute alebo almi metdami verifikujcimi konektivitu, e IP adresa nebola sfalovan
(spoofing). Tento prstup vak dokazuje len to, e existuje uzol s takou IP adresou a odpoved
na iadosti. Ak tento uzol neodpoved, neznamen to, e tto IP adresa nie je relna, uzol toti
me by nakonfigurovan tak, e ignoruje sluby ping a traceroute. tonk mohol tie
obdra dynamick adresu (naprklad z mnoiny dialup modemov), ktor bola u priraden
niekomu inmu. Naviac, ak IP adresa je relna a analytik ju pinguje, tonk me by
upozornen, e jeho aktivity s detekovan. V prpade, e sa vyskytne takto situcia predtm,
ako bol incident plne vymedzen, me tonk spsobi alie kody, ako je vymazanie
disku s dkazmi o toku. Analytik incidentov pri stanoven platnosti IP adresy mus zvi
zskanie a pouvanie IP adresy tonka od inej organizcie (napr. od poskytovatea
internetovch sluieb ISP) - tmto sa pred tonkom skryje skuton iadate o IP adresu.
Skenovanie tonkovho systmu niektor analytici urobia viac na kontrolu IP adresy
tonka ne je vykonanie sluieb ping a traceroute, mu spusti skener portov, skener
zranitenost a alie nstroje, aby zozbierali viac informci o tonkovi. Skener me

naprklad indikova povanie Trjskych kon na tonkovom systme, o implikuje, e
samotn tonkov uzol bol napadnut. Analytici by mali konzultova skenovanie uzla
tonka s prvnikmi ete pred jeho vykonvanm, pretoe takto skenovanie me by
v rozpore s vntornmi predpismi spolonosti a dokonca aj s nrodnou prvnou pravou.
Skmanie tonka prostrednctvom vyhadvacch nstrojov pri vine tokov,
analytik incidentu zska aspo nejak daje tkajce sa monej identity tonka, naprklad
zdrojov IP adresa, e-mailov adresa alebo prezvka na Internet Relay Chat (IRC).
Preskmanie Internetu na tieto daje me vies k zskaniu viacerch informci o tonkovi,
napr. mailing zoznam tkajci sa podobnch tokov alebo dokonca web strnky tonka.
Takto skmanie tonka nie je vo veobecnosti potrebn predtm, ne incident bol plne
vymedzen.
Vyuitie databzy incidentov niekoko neformlnych skupn zbiera a konsoliduje logy IDS
a bezpenostnch brn z rznych spolonost do databzy incidentov. Niektor z tchto
databz umouj analytikom skma zznamy odpovedajce uritm IP adresm. Analytici
mu poui databzu a zisti, i in spolonosti oznmili podozriv aktivity z toho istho
zdroja. Samozrejme, napadnut spolonos me skontrolova svoje vlastn zznamy
incidentov alebo databzu na podobn aktivity.
Monitorovanie monch komunikanch kanlov tonkov alia metda, ktor
pouvaj niektor analytici na identifikciu tonkov, je monitorovanie komunikanch
kanlov tonka. Naprklad, tonci sa mu zhromaova na istch kanloch IRC
a chvli sa svojimi spenmi akciami. Samozrejme, e informcie zskan takmto
spsobom nie s hotov fakty, ale musia by alej skman a verifikovan.
13.3.7 Cena (za rieenie) bezpenostnho incidentu

Z vyie uvedenho je zrejm, e rieenie bezpenostnho incidentu me by vemi nkladn
a zdhav procedra. Ako bolo niekokokrt zdraznen, rieenie potaovch bezpenostnch
incidentov si vyaduje prtomnos vysokokvalifikovanch a sksench odbornkov, ktorch je
nedostatok na pracovnom trhu. A t, nakoko ich nie je vea, maj svoju hodnotu. Sadzba pecialistov
skromnch firiem zaoberajcimi sa rieenm bezpenostnch incidentov, zbieranm digitlnych stp,
eventulne obnovou sprvnej innosti informanho systmu po incidente, sa zana pri 1 000 eur na
de. Pritom u komplikovanejch incidentoch ide o innos trvajcu nie dni, ale tdne, a zvyajne sa
podiea na tejto innosti aj viac pecialistov (asto aj prvnikov). Vsledn cena za tieto kony sa
me vyplha na niekoko desiatok tisc eur, o me by vek problm pre intitcie v ttnom
a verejnom sektore. A treba podotkn, e spech prpadnho nslednho sdneho procesu poda
doterajch sksenost je vemi otzny. Digitlne stopy v roli dkazov nie s sdmi vdy akceptovan
opak je skr pravdou [1]. tatistiky pokia existuj - uvdzaj len nzky poet odsdench
pchateov tokov na IKT z odhalench (dajne je len asi 10% pchateov aj prvoplatne
odsdench).
tt ponka pomoc v tejto oblasti, a to prostrednctvom intittu sdnych znalcov (znaleckch
organizci) schvlench Ministerstvom spravodlivosti SR, pecializovanej intitcie CSIRT.SK
zriadenej Ministerstvom financi SR a najnovie aj prostrednctvom kriminalistickch expertov
Kriminalistickho a expertzneho stavu PZ SR.
370
13.4 Znaleck innos

Intitt znalectva bol pvodne zaveden pre potreby sdnej praxe v minulosti sa pouval termn
sdny znalec. Dnes sa od prvlastku sdny upa, pretoe znaleck innos m sli pre potreby
irokej verejnosti teda aj mimo sdnictva [6, 7].
Znalec je odbornk, ktor spa podmienky stanoven zkonom . 382/2004 Z. z. (o znalcoch,
tlmonkoch a prekladateoch a o zmene a doplnen niektorch zkonov [3]) a je zapsan do zoznamu
znalcov vedenom Ministerstvom spravodlivosti SR. Poda tohto zkona sa znalcom stva fyzick
osoba, ktor - okrem inho - je bezhonn, zskala vzdelanie v odbore (ktor je predmetom innosti),
vykonva prax v odbore najmenej sedem rokov, zloila odborn skku z odboru, zloila sub znalca.
Poda Vyhlka .490/2004 Z.z., znalci s veden v zozname znalcov a vykonvaj znaleck innos
ako:
a)
b)
c)
d)
fyzick osoby,
prvnick osoby,
zamestnanci znaleckej organizcie,
lenovia znaleckho stavu.
Ministerstvo spravodlivosti uruje odbory a v ich rmci odvetvia znalectva (zvyajne na podnet sdov
alebo orgnov verejnej moc). Kad odbor a odvetvie s oznaovan 6-miestnym selnm kdom.
Celkovo znalcov vedench Ministerstvom je niekoko tisc asi pre stovku odvetv. Obzvl laickej
verejnosti me by nejasn, e na akho znalca sa v danej veci obrti. Z hadiska posudzovania
potaovch incidentov m vznam znalectvo technickho zamerania, resp. odbory 10 0000
(Elektrotechnika) a 49 0000 (Kriminalistika). Ide predovetkm o tieto znaleck odvetvia [7]:
10 1000 Bezpenos a ochrana informanch systmov,
10 0600 Elektronick komunikcie,
10 0200 Elektronika,
10 0800 Nosie zvukovch a zvukovoobrazovch zznamov,
10 0701 Odhad hodnoty elektrotechnickch zariaden a elektroniky,
10 0400 Riadiaca technika, vpotov technika,
49 2000 Kriminalistick informatika.
almi oblasami, kde me by znalec uvedench odvetv npomocn, s:
stanovenie hodnoty elektrotechnickch zariaden (vrtane IKT),

ohodnocovanie programovch systmov ako podkladov pre stanovenie ceny,
vypracovanie posudkov pre orgny inn v trestnom konan,
zabezpeovanie digitlnych stp a alch analytickch konov,
posudzovanie zhodnosti programovho vybavenia pre autorsko-prvne spory,
spracovanie odbornch vyjadren ako podkladov pre podanie trestnho oznmenia,
posudzovanie prevdzkovej schopnosti a hodnoty prstrojov a programovho vybavenia,
posudzovanie plnenia a kompletnosti dodvok a zmlv pre obchodn spory a reklamcie,
posudzovanie projektov pred realizciou, kontrola ich realizcie a vslednho efektu,
vypracovvanie rznych odbornch stanovsk (napr. o ochrane dt, a pod.).
Poda zkona pri vkone znaleckej innosti je kad povinn poskytn znalcovi pln sinnos.
Poskytnutie sinnosti je zo zkona vymoiten, a naopak, neposkytnutie sinnosti znalcovi me
371
ma
za
nsledok
sthanie
http:/www.jaspi.justice.gov.sk.
pre
marenie
spravodlivosti.
Viac
informcii
na
13.5 CSIRT.SK
Computer Emergency Response Team (CERT) alebo Computer Security Incidents Response Team
(CSIRT) s organizcie zdruujce pecialistov na informan bezpenos, ktorch primrnou lohou
je zisovanie monch hrozieb na potaov systmy, ich vyhodnocovanie, koordinciu reakcie na
vzniknut bezpenostn incidenty, a v neposlednom rade aj na pomoc pri nprave vzniknutch kd,
zhromaova informcie o potaovch bezpenostnch incidentoch a rizikch z nich
vyplvajcich, urchlenej distribcie tchto informci k relevantnm adrestom a koordincie ich
innost v prpade incidentu [9].
Prv organizcia CERT bola zaloen v roku 1988 americkm radom DARPA. Jej vznik bol
podnieten tokom potaovho erva (znmeho ako Morrisov Worm), ktor ochromil
nezanedbaten as vtedajej siete Internet, predovetkm v USA. Dnes existuje po celom svete viac
ako 200 rznych tmov typu CERT/CSIRT (vldnych, firemnch i privtnych), ktor spolupracuj na
bze vzjomnej dvery (rovn s rovnm) a vzjomnej vmeny informci [3]. Okrem inho, aj na
podporu rozvoja spoluprce tchto jednotiek v rmci Eurpskej nie vznikla v roku 2004 agentra
ENISA (European Network and Information Security Agency), ktor je zameran na koordinciu
a zdieanie informci medzi lenskmi ttmi Eurpskej nie v oblasti informanej bezpenosti. Jej
prvnym zkladom je nariadenie Rady ES . 460/2004.
Computer Security Incident Response Team Slovakia CSIRT.SK bol zriaden v roku 2010 ako
pecializovan tvar DataCentra (rozpotovej organizcie Ministerstva financi SR) s cieom
zabezpei primeran rove ochrany nrodnej informanej a komunikanej infratruktry (NIKI) na
Slovensku, kritickej informanej infratruktry a jej technologickch prvkov [9]. CSIRT.SK
zabezpeuje sluby spojen so zvldnutm bezpenostnch incidentov, odstraovanm ich nsledkov a
nslednou obnovou innosti informanch systmov a svisiacich informanch a komunikanch
technolgi v rmci NIKI 141 v spoluprci s vlastnkmi a prevdzkovatemi NIKI, telekomunikanmi
opertormi, poskytovatemi internetovch sluieb a prpadne inmi ttnymi orgnmi (napr. polcia,
vyetrovatelia, sdy), podiea sa na budovan a rozirovan poznania verejnosti vo vybranch
oblastiach informanej bezpenosti, aktvne kooperuje so zahraninmi organizciami a reprezentuje
SR v oblasti informanej bezpenosti na medzinrodnej rovni.
CSIRT.SK poskytuje sluby pre klientov (pre vlastnkov a sprvcov informanch systmov intitci
verejnej sprvy) definovan uznesenm vldy . 479/2009, a to hlavne:
Aktvne sluby CSIRT-u:
141
varovania / upozornenia na bezpenostn rizik,

reakcia na incidenty,
analza incidentov,
tvorba manulov pre rieenie najastejie sa vyskytujcich incidentov,
koordincia innost pri reakci na incidenty,
analza bezpenostnch rizk a zranitenost,
reakcia na kodliv softvr,
analza kodlivho softvru.
Nrodnej informanej a komunikanej infratruktry
372
Proaktvne sluby CSIRT-u:
oznmenia o incidentoch,
technologick dozor,
vzdelvanie a budovanie veobecnho povedomia v oblasti informanej bezpenosti,
konfigurcia a drba bezpenostnch nstrojov, aplikci a infratruktry,
sluby detekcie prienikov,
distribcia informci tkajcich sa informanej bezpenosti,
monitorovanie stavu hrozieb v oblasti IKT,
konzultan innos v oblasti informanej bezpenos,
asistencia a zakolenie pri budovan vlastnch tmov pre rieenie incidentov.
Viac informci mono zska na: http:/www.csirt.gov.sk.
13.6 Kriminalistick expertza a policajn postupy

Kriminalistick expertza sa od znaleckej innosti li predovetkm v tom, e kriminalistika
zhromauje kriminalistick stopy (mu by neskr pouit aj ako sdne dkazy) tak, aby umonila
vyptranie a usvedenie pchatea, km znaleck posudok je sm o sebe dkazom [11]. Kriminalistika
psob predovetkm v trestnom konan, km znaleck innos sa vyuva nielen v sdnictve
a notrstve, ale aj v obiansko-prvnom konan, v sprvnom konan, pri prvnych konoch obanov a
organizci (napr. predaj, kpa, reklamcie). Na druhej strane, kriminalistom zo zkona prislchaj
vie monosti pri vyetrovan (napr. predvedenie svedka alebo zadranie podozrivho, a pod.) ne
znalcom. alia odlinos je v tom, e znaleck innos je vykonvan zvyajne ako vedajia
innos inak zamestnanch odbornkov (asto vysokokolsk pedaggovia), km kriminalista je
hlavn zamestnanie. Z uvedenho vyplva, e ak je situcia evidentne jasn (je podozrenie, e
bezpenostn incident je trestnm inom), treba sa obrti na ktorkovek tvar Policajnho zboru
SR, prpadne prokuratry alebo orgny inn v trestnom konan, ktormi s policajt (poveren
prslunk a vyetrovate) a prokurtor. Kad z tchto orgnov m pri vyetrovan trestnch inov
svoje miesto. Orgny inn v trestnom konan pri vyetrovan trestnch inov postupuj zkonom
stanovenm spsobom, ktor je zameran na zistenie skutonost a dkazov dleitch pre
rozhodnutie, i v danej veci m by zaat trestn sthanie a vznesen obvinenie uritej osoby, alebo i
m by vydan in rozhodnutie (napr. vec odovzd prslunmu orgnu na prejednanie priestupku
alebo inho sprvneho deliktu), ako aj na vykonanie innch a nevyhnutnch opatren smerujcich
proti pchaniu trestnch inov.
V prpade spchania trestnho inu, ke orgn inn v trestnom konan pristupuje k vyetrovacej
innosti, nachdza spravidla u len nsledky danej udalosti, ktor prebehli v minulosti, ie zmeny v
stave situcie v podobe hmotnch a nehmotnch objektov, ku ktorm dolo nsledkom uritho
konania v dsledku spchania trestnho inu. Na dosiahnutie elu trestnho konania je potrebn aby
orgny inn v trestnom konan obstarali veci dleit pre trestn konanie.
Ak bol bezpenostnm incidentom spchan trestn in, poda Trestnho poriadku (zkon . 301/2005
Z. z.) policajt zane trestn sthanie vo veci a vykon vyetrovanie. Ak je na podklade zistench
skutonost po zaat trestnho sthania dostatone odvodnen zver, e trestn in spchala urit
osoba, policajt bez mekania vyd uznesenie o vznesen obvinenia, ktor ihne oznmi obvinenmu
a vykon vyetrovanie. Pre spen vyetrenie trestnho inu sa odpora priloi vetky materily a
dokumenty, ktor mu by npomocn pri vyetrovan danho bezpenostnho incidentu. Za dkaz
me sli vetko, o me prispie na nleit objasnenie veci a o sa zskalo z dkaznch
prostriedkov poda Trestnho poriadku alebo poda osobitnho zkona. Po skonen vyetrovania
373
a pretudovan vyetrovacieho spisu oprvnenmi osobami policajt pod prokurtorovi nvrh na

podanie obaloby poda prslunho ustanovenia Trestnho poriadku.
Bliie kontakty na tvary Policajnho zboru njdete na internetovej strnke Ministerstva vntra SR
http://www.minv.sk/?kontakty-prezidia-policajneho-zboru.
13.7 Praktick rady o robi

1
3
4
5
6
7
8
Dbajte na realizciu dobrch bezpenostnch opatren a dodrujte bezpenostn politiku

organizcie. Mnoho vhodnch a sprvne nastavench opatren (bezpenostnch plotov) vrazne
zniuje poet incidentov, odrdza potencilnych tonkov, a t aj ke predsa zatoia, pri
prekonvan niektorho z viacerch bezpenostnch plotov pravdepodobne zanechaj stopu.
Urite minimlne jednho odbornka na rieenie bezpenostnch incidentov (analytika
incidentov) a tto skutonos dajte na vedomie vetkm pouvateom ako adresu na
nahlasovanie incidentov. Vytvrajte povedomie, aby vetci zamestnanci nahlasovali tejto osobe
vetky incidenty alebo netandardn situcie a to bez zbran (kadmu sa me sta
nemyselne malr, preto netreba robi mtveho chrobka, lebo as je asto rozhodujci inite
pri zabrnen vch nsledkov). A pri myselnom a zmernom ine to pchate nebude hlsi,
naopak, bude zatka aj ke ho odhalme.
S odbornou erudciou sa snate zaisti vetky relevantn stopy (aj digitlne).
Pri komplikovanejch incidentoch sa nesname vetko robi svojpomocne, ale prizvite na pomoc
ihne sksench odbornkov (monost je viacero: CSIRT.SK, kriminalisti, sdni znalci,
renomovan skromn firmy alebo profesijn asocicie zaoberajce sa informanou
bezpenosou).
Ak incident naznauje trestn innos, konzultujte to ihne s prvnikom (najlepie svojim), a a
nsledne informujte orgny inn v trestnom konan (polciu).
Vyhnite sa publikovaniu incidentu na verejnosti bulvrne mdia ete iaden incident nevyrieili,
ale zvili len svoju sledovanos.
Pokia problm dsledne nezanalyzujete a neprekonzultujete s prvnikom (prpadne znalcom),
nekomunikujte s protistranou (pchateom).
Pokia sa d, vyhnite sa sdnemu sporu, idelne je mimosdne rieenie (napr. dohoda o urovnan,
rozhodcovsk riadenie a pod. okovek okrem sdu). Vnimkou me by incident, kde ide
skr o prvne a kriminlne otzky (ne vecn otzky), a v tom prpade je sdne riadenie vhodou
a asto aj nutnosou.
13.8 Zver
V blzkej budcnosti ns akaj dve vek vzvy. Prvou a dlhodobou je prehlbovanie informatizcie
ttnej sprvy, tzv. e-government. Druhou, sce asovo vymedzenou, ale z pohadu vzniku
potaovch bezpenostnch incidentov vemi vnou vzvou, bude nae predsednctvo Eurpskej
nie v roku 2016. D sa predpoklada, e obidve tieto skutonosti spsobia znan nrast potaovej
kriminality, na o sa Slovensko mus dsledne pripravi. asto vznik otzka, i je mon sa spene
brni nrastu potaovho zloinu. Odpove je: no. A nielen mon ale aj nutn hlavne nrastom
prevencie, ale tie nrastom represie. Zaoberali sme sa viac-menej otzkami postupu represvnych
orgnov. Je treba zdrazni, e bez mimoriadneho drazu kladenho na prevenciu (vhodn
bezpenostn procedry, bezpenostn opatrenia, bezpenostn povedomie, at.), nie je spen boj
proti potaovmu zloinu vbec mon.
374
13.9 Literatra:
[1]
Ivor J. et al: Trestn prvo, kriminalistika, bezpenostn vedy a forenzn disciplny v kontexte
kontroly kriminality. Vydavatestvo Ale enk, Plze 2013.
[2]
Porada V. Straus J.: Kriminalistick stopy teria, metodologie, prax. Vydavatestvo Ale
enk, Plze 2012.
[3]
Mates P. Smejkal V.: E-government v esk republice prvni a technologick aspekty.

Nakladatestvo Leges, Praha 2012.
[4]
Hudec L.: Vyetrovanie potaovch bezpenostnch incidentov. In: Zbornk prednok zo

SASIB konferencie Informan bezpenos 2007, Bratislava 2007.
[5]
Hudec L.: Rieenie potaovch bezpenostnch incidentov. In: Zbornk prednok AEC
2003.
[6]
Zkon . 382/2004 Z. z. o znalcoch, tlmonkoch a prekladateoch a o zmene a doplnen

niektorch zkonov.
[7]
http://www.jaspi.justice.gov.sk
[8]
Jansa L. Otevel P.: Softwarov prvo Praktick prvodce prvn problematikou v IT.
Nakladatestvo Computer Press, Brno 2011.
[9]
CSIRT.SK - Informan brora. http://www.csirt.gov.sk/img/infobrochure.pdf.
[10] imovek I. et al: Kriminalistika. Vydavatestvo Ale enk, Plze 2011 (kap.42 - Kov P.:
Metodika vyetrovania potaovej kriminality).
[11] http://www.wikipedia.sk znalectvo (2013).
[12] http://www.minv.sk/?kontakty-prezidia-policajneho-zboru
375
14 Prlohy
14.1 Strun vkladov slovnk informanej bezpenosti
Daniel Olejr
vod
Tto prloha obsahuje strun vkladov slovnk termnov informanej bezpenosti. Pri jej
zostavovan autor vychdzal z terminologickho slovnka vydanho metodickm pokynom
Ministerstva financi Slovenskej republiky a doplnil ho o alie pojmy (o. i. z normy ISO 27000).
Prloha obsahuje vber 250 najastejie pouvanch pojmov informanej bezpenosti a posli
itateom rchlejie sa zorientova pri tdiu tohto tudijnho materilu.
Hesl slovnka s organizovan nasledovne: slovensk termn, [jeho anglick ekvivalent], vklad
pojmu. Ak sa vo vklade pouvaj in pojmy, ktor sa nachdzaj v slovnku, s vysdzan kurzvou
a oznaen . Viacslovn pojmy s usporiadan poda kovho slova. Pri skratkch vo
veobecnosti a pri anglickch skratkch, ktor nemaj slovensk ekvivalent zvl, uvdzame odkaz
na heslo vykladajce pojem oznaen skratkou. Pojmy, ktor nemaj slovensk ekvivalent uvdzame
pod pvodnm anglickm nzvom. Kee vina pojmov informanej bezpenosti vznikla
v anglicky hovoriacom prostred, pre uahenie vyhadvania v slovnku je k slovnku pripojen
anglicko-slovensk register.
Vkladov as
A
aktvum [asset] okovek, o m pre organizciu hodnotu. Aktva s hmotn (zariadenia,
infratruktra, personl) a nehmotn (informcie, know-how, dobr meno). Mu sa sta objektom
hrozby alebo cieom toku a vyaduj si ochranu.
analza rizk [risk analysis] proces pochopenia podstaty rizika a stanovenia rovne rizika
anonymita [anonymity] 1. bezpenostn sluba umoujca pouvateovi systmu vyuva zdroje
systmu bez prezradenia pouvateovej identity 2. bezpenostn poiadavka na rieenie, systm
alebo nejak slubu, aby pri interakcii pouvatea so systmom (pouvan rieenia, sluby) nebola
prezraden pouvateova identita
atribt [attribute] vlastnos, charakteristick rta alebo prvlastok entity, ktor me kvantitatvne
alebo kvalitatvne rozli lovek, technick zariadenie alebo program
atribtov autorita [attribute authority] vydavate atribtovch certifiktov, dveryhodn tretia
strana, ktor je oprvnen posdi pravos predloench atribtov a ich spojenie so iadateom
o vydanie atribtovho certifiktu, alebo driteom certifiktu verejnho ka, ku ktormu m by
atribtov certifikt vydan a v prpade kladnho vsledku vyda o tom osvedenie v podobe
atribtovho certifiktu.
audit [audit] formlne preskmanie, preskanie alebo verifikcia skutonho stavu systmu alebo
jeho definovanej asti na zhodu alebo slad so stanovenmi oakvaniami
376
Prlohy| MF SR
autentifikcia/autentizcia [authentication] potvrdenie deklarovanej identity nejakej entity

autentickos [autenticity] vlastnos, ktor znamen, e deklarovan identita entity je pravdiv
autorita asovch peiatok [timestamping authority] dveryhodn tretia strana (v SR akreditovan
CA), ktor poskytuje sluby asovch peiatok (vydvanie, overovanie)
autorizcia [authorization] udelenie oprvnen nejakej entite na prstup k zdrojom
systmu/organizcie a/alebo na ich vyuvanie
B
bezpenostn architektra [security architecture] sbor princpov, ktor popisuj (a) bezpenostn
sluby, ktor od systmu poaduj jeho pouvatelia (b) komponenty systmu, ktor maj
implementova dan sluby (c) vkonostn rovne/parametre jednotlivch komponentov potrebn na
to, aby sa dokzali vyporiada s predpokladanmi hrozbami.
bezpenostn funkcia [security function] implementane nezvisl spsob realizcie bezpenostnej poiadavky; bezpenostn opatrenie je realizciou jednej alebo viacerch bezpenostnch
funkci,
bezpenostn politika (intitcie) [security policy] formlny dokument schvlen vedenm
intitcie, ktorm sa podrobnejie rozpracovvaj bezpenostn ciele intitcie, upresuje rove
bezpenostnch poiadaviek, stanovuje zodpovednos za informan bezpenos v intitcii a
rmcovo definuj spsoby na dosiahnutie stanovench cieov
bezpenostn poiadavka [security requirement] pecifikcia ohranien na usporiadanie aktva,
spsob jeho pouvania alebo na innos intitcie, ktorch cieom je elimincia alebo znenie
pravdepodobnosti rizika spojenho s pouvanm aktva, alebo innosou intitcie,
bezpenostn zruka [security assurance] miera naplnenia bezpenostnej poiadavky odvoden
od spsobu (bezpenostnch opatren), akm bola bezpenostn poiadavka realizovan
bezpenostn opatrenie [security measure/control] technick, organizan, prvne alebo in
rieenie, ktor plne alebo iastone odstrauje zranitenos aktva, a/alebo zniuje
pravdepodobnos naplnenia hrozby a/alebo v prpade jej naplnenia zniuje jej dopad na aktvum
a organizciu, ktor ho vlastn,
bezpenostn povedomie [awareness] poznanie potreby ochrany informcie a IKT ako aj povinnosti
osobne sa na nej podiea
bezpenostn prostredie [security environment] sbor externch entt, procedr, pravidiel
a podmienok, ktor maj vplyv na bezpen vvoj, prevdzku, innos a drbu systmu
bezpenostn smernice [security directives] s podrobnejm opisom jednotlivch
bezpenostnch opatren a spravidla pozostvaj z opisu technickch, organizanch, prvnych,
personlnych a inch rieen.
bezpenostn incident [security incident] pozri incident
bezpenostn mechanizmus [security mechanism] konkrtna implementcia bezpenostnej
funkcie
bezpenostn projekt [security project] komplexn posdenie bezpenostnch potrieb/poiadaviek
na systm a nvrh spsobu, ako im efektvne vyhovie. Pozostva z bezpenostnho zmeru,
analzy rizk a bezpenostnch smernc.
377
Prlohy| MF SR
bezpenostn zmer [security target] formlny dokument schvlen vedenm intitcie, ktorm
vedenie intitcie deklaruje zkladn ciele intitcie v oblasti informanej bezpenosti
bezpenos, informan [information security] 1. idelny stav systmu, kedy vetko funguje
v slade s oakvaniami (bezpenostnou politikou) 2. multiodborov disciplna, ktor sa zaober
hrozbami voi systmom/aktvam a metdami, ako aktva pred hrozbami chrni, 3. innosti
zameran na dosiahnutie idelneho stavu systmu.
bezpenos pomocou utajovania [security by obscurity] snaha udra alebo zvi bezpeenos
systmu utajenm nvrhu alebo kontrukcie bezpenostnho mechanizmu. V kryptolgii sa tento
prstup povauje za prekonan.
biometrick autentifikcia [biometric authentication] overenie deklarovanej identity osoby na
zklade jej biometrickch dajov
biometrick charakteristiky [biometric characteristics] parametre odvoden od fyziologickch
vlastnost loveka
biometrick daje [biometric data] daje
biometrickch charakteristk nejakej osoby
zskan
zanamenvanm
alebo
meranm
biometrick [biometric] tkajci sa pecifickch fyziologickch alebo behaviorlnych charakteristk

(atribtov) predstavujcich identitu uritej osoby
C
CA [CA] pozri certifikan autorita
certifikan autorita [certification authority] dveryhodn tretia osoba, ktor najm vydva
certifikty verejnch kov, poskytuje informcie o ich platnosti, ru predasne ich platnos a
poskytuje aj in certifikan sluby.
certifikan autorita, koreov [root certification authority, R-CA] v hierarchicky usporiadanej
PKI najvyie postaven CA, ktor spravuje (vydva, ru a poskytuje informcie o platnosti)
certifikty verejnch kov podriadench CA
certifikan cesta [certification path] je postupnos certifiktov (verejnch kov) 1 ,2 , ,
tak, e drite certifiktu je vydavateom certifiktu +1 , priom 1 je cerifikt verejnho ka
znmej (napr. koreovej) CA a je certifikt, ktorho platnos je potrebn overi
certifikan sluba [certification service] vydvanie certifiktov, zruovanie platnosti certifiktov,

poskytovanie zoznamu zruench certifiktov, potvrdzovanie existencie a platnosti certifiktov,
vyhadvanie a poskytovanie vydanch certifiktov, vydvanie asovch peiatok, dlhobob
archivcia podpsanch elektronickch dokumentov a i.
certifikt [certificate] 1. dokument, ktor potvrdzuje pravdivos, pravos alebo kvalitu nieoho alebo
vlastnctvo nieoho, 2. dokument vydan nezvislou oprvnenou autoritou deklarujci, e
posudzovan system (zariadenie alebo vrobok) spa funkcionlne, kvalitatvne, bezpenostn a in
poiadavky definovan v certifikanch kritrich 3. digitlny certifikt
certifikt verejnho ka [public key certificate] dokument, ktorm vydavate (CA) potvrdzuje
identitu dritea danho certifiktu a spja ho s verejnm kom uvedenm v certifikte, m
umouje poui verejn k z certifiktu na overenie toho, i digitlny/elektronick podpis vytvoril
drite certifiktu. Okrem verejnho ka certifikt verejnho ka obsahuje aj alie daje
potrebn na overenie platnosti certifiktu a digitlneho/elektronickho podpisu. Certifikt verejnho
378
Prlohy| MF SR
ka je podpsan digitlnym/elektronickm podpisom vydavatea certifiktu. Pozri X-509

certifikt
certifikt, atribtov [attribute certificate] digitlny certifikt, ktor spja mnoinu popisnch
dajovch poloiek odlinch od verejnho ka bu priamo s menom nejakho subjektu, alebo s
certifiktom verejnho ka. Atribtov certifikt digitlne podpisuje a vydva atribtov autorita.
certifikt, digitlny [digital certificate] certifikt verejnho ka alebo atribtov certifikt
certifikt, koreov [root certificate] certifikt verejnho ka koreovej certifikanej
autority, ktor si R-CA sama vydala na svoj verejn k a podpsala skromnm kom
tvoriacim pr k verejnmu ku, uvedenmu v danom certifikte.
certifikt, zruenie [revocation of certificate] kon, ktorm na podnet dritea certifiktu alebo
inej, zkonom oprvnenej osoby CA predasne ukon platnos certifiktu, ktor vydala a o ktorho
zruenie bola poiadan
cie opatren [control objective] vrok popisujci, o sa m dosiahnu prostrednctvom zavedenia
opatrenia
cieov as obnovenia [Recovery Time Objective RTO] maximlny prpustn as trvania vpadku
procesu alebo sluby. Obnova systmu me relne trva kratie, ako je RTO. Na rozdiel od MTO
vyjadruje RTO ciele a ambcie organizcie, priom plat e RTO MTO.
cieov bod obnovenia [Recovery Point Objective RPO] maximlny prpustn vek dajov,
ktor sa musia da obnovi zo zloh v prpade vpadku systmu. RPO uruje frekvenciu zlohovania
systmu/dajov.
citliv informcia [sensitive information] 1. informcia, ktorej odhalenie, zmena, znienie alebo
zneprstupnenie me ma negatvny dopad na jej vlastnka alebo pouvatea, 2. informcia, ktor je
za citliv prehlsen zkonom alebo vntornmi predpismi organizcie.
citliv ale neklasifikovan informcia [sensitive but unclassified information] informcia, ktor
nie je oznaen ako klasifikovan (v SR utajovan skutonosti), ale narbanie s ktorou je upraven
legislatvou alebo vntornmi predpismi organizcie.
CRL pozri zoznam zruench certifiktov
asov peiatka [timestamp] potvrdenie vydan dveryhodnou treou stranou, e dokument pre
ktor sa asov peiatka vydva, existoval pred asovm okamihom zachytenm v asovej peiatke.
asov peiatka m podobu haovacej hodnoty danho dokumentu, zreazenho s asovm dajom
(doplnenm autoritou asovch peiatok) podpsanej digitlnym/elektronickm podpisom autority
asovch peiatok.
D
deklasifikova informciu [declassify] rozhodnutie oprvnenej autority o zruen pvodnej
klasifikcie informcie. Po tomto rozhodnut sa informcia stva neklasifikovanou, alebo me by
klasifikovan znova (prehodnotenie pvodnej klasifikcie)
De Jedna [Day One] de, kedy je zverejnen zplata na odhalen zranitenos systmu alebo
aplikcie
379
Prlohy| MF SR
De Nula [Day Zero] de, ke sa odhal nov zranitenos systmu alebo aplikcie
deifrova [decipher] transformova ifrov text na pvodn otvoren text. Na deifrovanie sa
pouva deifrovacia transformcia a v prpade symetrickch ifier tajn k, v prpade
asymetrickch ifier skromn k adresta
digitlny odtlaok (textu) [digital fingerprint] kontroln set textu
distribcia kov [key distribution] metdy zaistenia toho, aby oprvnen osoby (a len oni) poznali
tajn ke symetrickho kryptosystmu alebo verejn ke partnerov pre komunikciu
pomocou asymetrickho kryptosystmu ete pred zaiatkom komunikcie.
distribuovan tok typu denial of servis [distributed denial of servis attack, DDoS] tok typu
denial of servis, veden z viacerch potaov na cieov systm, so zmerom spsobi jeho
preaenie a zamedzi mu poskytovanie sluieb
dosledovatenos [accountability] bezpenostn poiadavka (na systm), aby bolo mon
stanovi, kto je zodpovedn za bezpenostne relevantn aktivity v systme
dostupnos [availability] poiadavka, aby zdroje systmu boli k dispozcii oprvnenej osobe 1. vdy
ke o to poiada, 2. do asu t od okamihu, ke o to poiada, 3. s pravdepodobnosou meranou
podielom doby, ke s poadovan zdroje k dispozcii ku celkovej dobe (napr. 24 x 7 znamen, e
systm je dostupn nepretrite 24 hodn denne a 7 dn v tdni)
dvera [trust] 1. pocit istoty (asto nepodloen), e (a) systm nezlyh (b) e systm rob len to, o
m robi a nevykonva iadne neiadce innosti 2. vo veobecnosti, ak entita A dveruje entite B,
znamen, e entita A predpoklad, e sa entita B bude sprva presne tak, ako entita A oakva.
dvernos [confidentiality] 1. bezpenostn poiadavka, ktorej naplnenie znamen, e sa
informciu obsiahnut v sprve (dokumente) nedozvedia nepovolan osoby 2. druh najni stupe
klasifikanej schmy utajovanch skutonost
dveryhodn (overen) vpotov bza [trusted computing base] bezpenostn jadro systmu
predstavovan sborom bezpenostnch mechanizmov systmu (hardvrovch, softvrovch a
firmvrovch) ktorch kombincia je zodpovedn za presadzovanie bezpenostnej politiky.
drite certifiktu [certificate holder] v prpade digitlneho certifiktu poda tandardu X509
osoba, ktorej meno alebo pseudonym je uveden v poloke Subject
dvojfaktorov autentifikcia [two-factor autentication] autentifikcia entity na zklade dvoch
nezvislch metd overenia jej proklamovanej identity
E
entita [entity] akkovek objekt (lovek, zviera, vec, mylienka, abstraktn objekt), ktor je
jedinen a zhodn len so sebou samm (t.j. niem sa odliuje od podobnch objektov). Entita sa
vyznauje mnoinou atribtov, ktor tvoria jej identitu.
efektivita [efficiency] vzah medzi dosiahnutmi vsledkami a vynaloenm silm (vynaloenmi
zdrojmi)
extern kontext [external context] vonkajie prostredie, v ktorom sa organizcia sna dosiahnu
svoje ciele
F
380
Prlohy| MF SR
fyzick bezpenos [physical security] fyzick prostriedky na ochranu systmu pred krdeou,
zneuitm, nhodnm pokodenm, technickmi poruchami a prrodnmi vplyvmi.
G
genertor kov [key generator] genertor nhodnch alebo pseudonhodnch sel, ktor s
bu priamo pouvan ako kryptografick ke, alebo sa z nich vytvraj kryptografick ke
genertor nhodnch sel [random numbers generator] technick alebo prrodn systm, ktor na
zklade nhodnch procesov prebiehajcich v systme alebo jeho okol men svoj stav, priom stav
systmu je mon vyjadri slom a budci stav systmu nie je predpovedaten na zklade znalosti
predchdzajcich stavov
genertor pseudonhodnch sel [pseudorandom numbers generator] systm deterministicky
generujci postupnos sel, ktor nie je pomocou tatistickch testov odliten od nhodnej
postupnosti a pre ktor je ak vypota z predchdzajcich hodnt nasledujce hodnoty. Poiaton
hodnota (stav) genertora pseudonhodnch sel sa nazva inicializan vektor.
generovanie kov [key generation] 1. metdy a algoritmy na vytvranie kryptografickch
kov 2. pouitie metd a algoritmov na vytvranie kryptografickch kov
granularita [granularity] 1. relatvna miera jemnosti nastavenia mechanizmu na riadenie prstupu
2. vekos najmenej jednotky informcie, ktor mono individulne chrni v dveryhodnom
systme
H
hacker [hacker] lovek hadajci zranitenosti systmov s cieom vyui ich na prienik do
systmov. Hacker sa neusiluje ani o zisk, ani o pokodenie systmov.
haovacia funkcia [hash function] zobrazenie, ktor textu ubovonej konenej dky prirad reazec
pevnej dky. Pozri kryptograficky siln haovacia funkcia
haovacia hodnota [hash value, hash] vsledok vpotu haovacej funkcie
heslo [password] tajn reazec znakov znmy len uritej entite (a overovateovi identity), ktor
sa pouva na autentifikciu danej entity
hrozba [threat] okovek, o je potencilne schopn priamo alebo nepriamo spsobi kodu na
systme, alebo informcich ktor sa v om spracovvaj
hierarchick PKI [hierarchic PKI] PKI s architektrou hviezdy, alebo koreovho stromu, na
vrchole ktorej stoj koreov CA, ktor vydva certifikty verejnch kov podriadenm CA.
Tieto vydvaj certifikty verejnch kov koncovm pouvateom, alebo predstavuj koreov
autority niej rovne pre asti PKI.
I
identifikcia [identification] deklarcia identity nejakej entity. (V praxi napr. prihlsenie sa do
systmu menom.)
identifiktor [identifier] informan alebo materilny objekt na zklade ktorho je mon
jednoznane uri bu identitu entity, alebo samotn entitu.
381
Prlohy| MF SR
identita [identity] mnoina atribtov nejakej entity, ktor ju jednoznane odliuje od inch entt
podobnho druhu v nejakej oblasti aplikovatenosti identity. Identita je meno, osobn daje
nejakho loveka, identifiktor, preukaz, rodn slo a pod.
incident [incident] udalos alebo situcia, ktor spsob alebo me spsobi neiadce preruenie
innosti, stratu, ndzov stav alebo krzu v nejakej organizcii, alebo v systme.
informcia [information] zkladn pojem s rozlinou interpretciou v rznych oblastiach.
V informatike informcia predstavuje opis nejakej skutonosti (relnej alebo fiktvnej) zaznamenan
v podobe dajov. Informcia predstavuje obsah dajov a daje s formou zpisu informcie.
informcia, klasifikcia [information classification] pozri klasifikcia dajov
informan a komunikan infratruktra [information and communication infrastructure] pozri
infratruktra, informan
informan a komunikan technolgie, IKT [information and communication technology, ICT]
technolgie, ktor vznikli spojenm potaov, telekomunikanch siet a masovokomunikanch
prostriedkov, vyuvajce digitlne kdovanie informcie a spolon komunikan kanly pre
prenos dajov.
informan systm [information system] aplikcia, sluba, technick zariadenie alebo in prvok,
ktor spracovva informciu
infratruktra [infrastructure] z hadiska organizcie je infratruktrou vetko to, o sa priamo
nepodiea na plnen poslania organizcie, vrtane toho, o organizcia nevlastn, ale o vak pre
plnenie svojho poslania nevyhnutne potrebuje.
infratruktra, kritick [critical infrastructure] infratruktra, ktorej naruenie, zneprstupnenie
alebo znefunknenie me spsobi stratu schopnosti organizcie plni svoje poslanie, spsobi jej
finann stratu, ktor nedoke kompenzova alebo spsob ohrozenie zdravia a ivota ud.
infratruktra, informan [information infrastructure] infratruktra, ktor sli na zskavanie,
prenos, spracovvanie a uchovvanie informci.
infratruktra verejnho ka [public key infrastructure] sbor hardvrovch a softvrovch
prostriedkov, politk, procedr a ud potrebnch na zaistenie manamentu certifiktov verejnch
kov a poskytovanie inch certifikanch sluieb.
inicializan vektor [initialization vector, seed] poiaton hodnota (stav) genertora
pseudonhodnch sel, z ktorej je odvoden postupnos pseudonhodnch sel
integrita [integrity] 1. zkladn bezpenostn poiadavka na daje, ktorej naplnenie znamen, e
daje nie je mon zmeni bez toho, aby to ich vlastnk alebo adrest nemohol zisti. 2. v irom
zmysle je integrita bezpenostn poiadavka na vylenie neoprvnench zmien v systmoch; t.j.
zmien hardvru, programovho vybavenia alebo dajov.
J
jedin odhlsenie [single sign-off] korektn ukonenie viacerch innost (prebiehajcich aj na
viacerch systmoch) pomocou jedinho odhlsenia
jedin prihlsenie [single sign-on] metda umoujca riadenie prstupu na viacer rzne systmy
pomocou prihlsenia sa na jedin systm
jednorazov heslo [one time password] heslo na jedno pouitie
382
Prlohy| MF SR
K
kanl, komunikan [communication channel] 1. fyzick mdium (kovov vodi, optick vlkno,
priestor pre renie signlov a pod.) ktor je schopn sprostredkova renie signlov, prenajcich
informciu 2. logick spojenie medzi astnkmi komunikcie, ktor me by vytvoren ad hoc len
pre konkrtnu komunikciu a me vyuva rzne druhy fyzickch mdi
kanl, skryt [covert channel] metda prenosu informcie pomocou vedajieho (skrytho) efektu
nejakej udalosti alebo innosti nejakho mechanizmu pvodne urenho na in el.
klasifikcia dajov [data classification] (bezp.) kategorizcia, posdenie potrieb ochrany dajov z
hadiska dostupnosti, dvernosti, integrity, autentickosti a i. a ich nsledn zaradenie do
klasifikanej kategrie (triedy) zodpovedajcej tmto potrebm.
klasifikan schma [classification scheme] zvyajne systm hierarchicky usporiadanch tried,
spolu s pravidlami, umoujcimi zaradi daje do prve jednej z tried a bezpenostnmi
poiadavkami pre jednotliv triedy
klasifikovan informcia [classified information] 1. (veob.) informcia zaraden do niektorej
z klasifikanch tried 2. (SR) informcia patriaca medzi utajovan skutonosti
k na ifrovanie kov [key encryption key] k uren na ifrovanie/deifrovanie
kryptografickch kov na ochranu ich dvernosti poas ich prenosu alebo uchovvania
k, tajn [secret key] parameter symetrickch ifier (kryptosystm symetrick), ktor sa pouva
tak na ifrovanie otvorench, ako aj na deifrovanie ifrovch textov.
k, skromn [private key] jeden z dvojice kryptografickch kov asymetrickho
ifrovacieho systmu. (tm druhm je verejn k). Skromn k sa nezverejuje a pouva sa na
1. vytvranie digitlnych podpisov alebo 2. na deifrovanie ifrovch textov, ifrovanch
pomocou verejnho ka
k, verejn [public key] druh z dvojice kryptografickch kov asymetrickho ifrovacieho
systmu. Tento k je verejne dostupn, i u prostrednctvom zoznamu, alebo certifiktu
verejnho ka a sli na ifrovanie sprv urench driteovi verejnho ka a na
overovanie digitlnych/ elektronickch podpisov.
kd [code] 1. mnoina kdovch slov, 2. program
kontinuita innosti [business continuity] kroky, ktor organizcia podnik na to, aby zabezpeeila
nepretrit dostupnos svojich kuovch funkci (sluieb, zdrojov) pre ich oprvnench pouvateov
kontroln set/suma [checksum] seln hodnota vypotan na zklade textu/dokumentu/ sboru
(najastejie pomocou haovacej funkcie), ktor sli na ochranu integrity textu/dokumentu/
sboru
korekcia, opravn innos [corrective action] innos, ktorej cieom je eliminova prinu
zistenho nesladu (slad) alebo inej neelanej situcie
krde identity [identity theft] predstieranie cudzej identity za elom zskania neoprvnench
vhod. Predchdza mu zskanie identifikanch dajov a prostriedkov na autentifikciou osoby, za
ktor sa podvodnk chce vydva.
kryptoanalza [cryptanalysis] 1. vedn disciplna zaoberajca sa vvojom metd ltenia
(rozbjania) ifier. 2. ltenie (rozbjanie) ifry
kryptografia [cryptography] vedn disciplna zaoberajca sa nvrhom kryptosystmov (ifier)
kryptografick transformcia [cryptographic transformation] ifrovacia alebo deifrovacia
transformcia
383
Prlohy| MF SR
kryptografick k [cryptographic key] parameter kryptografickch transformci. Me by

utajovan, ale aj verejne znmy (v prpade asymetrickch kryptosystmov).
kryptograficky siln kontroln set [cryptographic checksum] kontroln set (napr. selne
kdovanch znakov dokumentu), vyuvajci kryptografick transformcie, pre ktor je vpotovo
vemi ako zvldnuten (a) njs/zostroji tak vstup (dokument, sbor), ktorho kontroln set
nadobda dan hodnotu, (b) njs dva rzne vstupy, ktorch kontroln sty s zhodn.
kryptografick protokol [cryptographic protocol] postupnos predpsanch komunikanch a
vpotovch krokov vykonvanch dvoma alebo viacermi subjektami pre dosiahnutie konkrtneho
kryptografickho ciea, napr. autentifikcie, distribcie ka a pod.
kryptolgia [cryptology] vedn disciplna zaoberajca sa tdiom kryptosystmov (ifier).
Pozostva z kryptografie a kryptoanalzy
kryptosystm [cryptosystem] dvojica kryptografickch transformci (, ), kde je ifrovacia
a D deifrovacia transformcia
kryptosystm s verejnm kom [public key cryptosystem] asymetrick ifra, pre ktor m
kad jej pouvate dvojicu kryptografickch kov: skromn a verejn. Skromn k je
utajen a verejn k je zverejnen napr. pomocou certifiktu verejnho ka. Na ifrovanie
sprvy odosielate pouva verejn k adresta, adrest ifrov sprvu deifruje pomocou
svojho skromnho ka.
kybernetick priestor [cyberspace] pvodne metaforick oznaenie prostredia v ktorom prebieha

prenos a spracovanie digitlnej zaznamenanej informcie. V sasnosti oznauje informan a
komunikan infratruktru organizcie, ttu alebo globlnu informan a komunikan
infratruktru. V slovenskom prostred sa pojem kybernetick priestor pouva na oznaenie
informanej a komunikanej infratruktry, urenej na spracovanie utajovanch skutonost.
kybernetick zloin [cybercrime] protiprvna innos, ktor (a) je zameran na informan
a komunikan systmy, alebo (b) ich vyuva na nekal ciele
M
manament certifiktov [certificate management] vydvanie, distribcia, uchovvanie, overovanie
platnosti, pouvanie a ruenie certifiktov
manament informano-bezpenostnch incidentov [information security incident management]
procesy odhaovania, nahlasovania, vyhodnocovania informano-bezpenostnch incidentov,
reakci na ne, ich rieenia a pouenia sa z nich
manament kov [key management] generovanie, distribcia, pouvanie, uchovvanie,
aktualizcia a nienie kryptografickch kov
maximlna doba vpadku [maximum tolerable outage - MTO alebo Maximum tolerable period of
disruption MTPD] najdlhia mon doba vpadku procesov alebo innost organizcie, po ktorej
uplynut nastan pre organizciu neakceptovaten dopady
miera [measure] atribt (veliina) a metda na kvantitatvne urenie jej hodnoty
384
Prlohy| MF SR
N
nhodn slo [random number] vsledok innosti genertora nhodnch sel
nhodn [random] proces, ktorho priebeh sa neriadi iadnymi deterministickmi zkonitosami;
tie stav alebo vsledok takho procesu. Podstatnou rtou nhodnho procesu je nepredvdatenos
vsledku
naruenie bezpenosti [security violation] akt alebo udalos, ktor nie je v slade s bezpenostnou
politikou systmu alebo organizcie
nepopretie [repudiation] schopnos dokza, e nastala nejak udalos, alebo bola vykonan nejak
innos a o/kto bol/o jej pvodcom/vykonvateom
nepopretie pvodu [non repudiation of origin] bezpenostn poiadavka na dokument, ktorej
naplnenie znamen, e tvorca (odosielate) dokumentu nebude mc poprie, e dokument vytvoril
(poslal)
nepopretie prijatia [non repudiation of receipt] bezpenostn poiadavka na dokument/sprvu,
(resp. na systm doruovania dokumentov) ktorej naplnenie znamen, e adrest neme poprie, e
dokument prijal
neslad [non-conformity] nesplnenie poiadavky
O
oblas aplikovatenosti identity [identity applicability domain] mnoina entt, ktor maj
identitu danho typu, v ktorej dan identita postauje na jednoznan odlenie jednotlivch entt.
Oblasou aplikovatenosti identity me by naprklad mnoina dospelch slovenskch
obanov, identitou daje uveden v obianskom preukaze, hodnoty dajov z konkrtneho OP
predstavuj identitu dritea danho OP.
obnova innosti [business recovery] kroky, ktor organizcia mus podnikn na to, aby po
bezpenostnom incidente, havrii alebo katastrofe o najrchlejie obnovila informan
a komunikan infratruktru podporujcu jej kritick innosti (disaster recovery)
odopretie sluby [denial of servis, DoS] vsledok akcie, alebo niekokch akci, ktor znemouje
systmu a/alebo aplikcii (najastejie z dvodu preaenia) sprvne fungova a poskytova
poadovan sluby
odpovanie [eavesdropping] monitorovanie komunikcie prebehajcej po prenosovom kanli s
cieom zska kpiu prenanch dajov
odvoden miera [derived measure] miera, ktor je definovan ako funkcia dvoch alebo viacerch
hodnt zkladnch mier
opatrenie [measure] pozri bezpenostn opatrenie
osobn informcie [personal information] informcie vzahujce sa na fyzick osobu, ktorch
kompromitcia by mohla dan fyzick osobu nejako pokodi
osobn daje [personal data] 1. daje obsahujce osobn informcie 2. daje tkajce sa fyzickch,
fyziologickch, psychickch, mentlnych, ekonomickch, kultrnych a podobnch atribtov urenej
alebo uritenej osoby
overi [verify] otestova alebo dokza pravdivos nejakho faktu alebo pravdivos i presnos
nejakej hodnoty
385
Prlohy| MF SR
overovanie [verification] 1.proces skmania informcie, aby sa urila pravdivos nejakho tvrdenia
alebo sprvnos/presnos nejakej hodnoty 2. proces porovnvania dvoch rovn pecifikcie nejakho
systmu s cieom zisti, i s v slade.
P
paradox, narodeninov [birthday paradox] paradox vyplvajci z odpovede na dve otzky: koko
ud mus by v miestnosti, aby tam s pravdepodobnosou vou alebo rovnou 0.5 boli dvaja, ktor 1.
sa narodili v danom dni roka 2. maj narodeniny v ten ist de. Paradox je v tom, e v prvom prpade
to mus by aspo 183 ud, km v druhom len 26 ud. Tento paradox sa vyuva v kryptoanalze.
personlna bezpenos [personnel security] opatrenia na zaistenie toho, aby sa minimalizovala
pravdepodobnos myselnch tokov a nemyselnch chb internch pracovnkov na systm, resp.
pri prci so systmom. Opatrenia zahaj vber, preverovanie, prpravu, monitorovanie, personlu;
procedry pri zmene pracovnho zaradenia a ukonen zamestnania v organizcii.
PKI pozri infratruktra verejnho ka
plaintext [plaintext] vstupn daje pre nejak kryptografick transformciu. Ak daje neboli
predtm kryptograficky spracovvan, plaintext je zrove otvorenm textom (cleartext). V praxi sa
asto pojem plaintext stotouje s pojmom otvoren text.
pln kontinuity innosti [business continuity plan, BCP] vstup plnovania kontinuity innosti.
Pln na zabezpeenie svislej innosti organizcie zahajci aj neinformatick aspekty, ako je
zaistenie kovch ud, obnovu informanch zdrojov, zariaden, krzov komunikciu, ochranu
dobrho mena. Pln kontinuity innosti obsahuje aj preventvne, detekn a korekn opatrenia.
pln obnovy [disaster recovery plan, DRP] postupnos krokov na o najrchlejie odstrnenie
nsledkov havrie/karastrofy a obnovu kritickej informanej infratruktry organizcie
plnovanie, havarijn [disaster recovery planning] plnovanie innosti pre prpad havri
(preventvne opatrenia, detekcia havri, opatrenia na zmiernenie nsledkov havrie, opatrenia na
odstrnenie nsledkov havrie pln obnovy)
plnovanie kontinuity innosti [business continuity planning] vytvranie. implementcia,
testovanie a revzie plnov kontinuity innosti
podpis, digitlny [digital signature] bezpenostn funkcia garantujca integritu dokumentu, pre
ktor bola vytvoren a identitu entity, ktor digitlny podpis vytvorila. V praxi m podobu
haovacej hodnoty podpisovanho dokumentu zaifrovanej pomocou skromnho ka
podpisovatea.
podpis, elektronick [electronic signature] poda direktvy EC 93/99, daje v elektronickej
forme, ktor s pripojen k inm elektronickm dajom alebo s logicky spojen s inmi
elektronickmi dajmi, a ktor slia ako metda na dkaz ich autentickosti. V tomto chpan je
elektronick podpis slab ako digitlny podpis, pretoe defincia elektronickho podpisu Direktvy
nehovor ni o rovni zruk.
podpis, elektronick pokroil [advanced electronic signature] je digitlny/elektronick podpis
vytvoren pomocou bezpenho zariadenia na vytvranie elektronickch podpisov, ktor m
podpisovate pod kontrolou. V slovenskej legislatve mu zodpoved zaruen elektronick podpis.
podpis, vlastnorun [handwritten signature] vlastnorune napsan meno, alebo znaka
jednoznane urujca osobu, ktor podpis vytvorila (podpisovate) a jej shlas s obsahom dokumentu,
ktor vytvorenm podpisu potvrdila
386
Prlohy| MF SR
potvrdenie platnosti [validation] 1. potvrdenie sprvnosti alebo korektnosti nejakej kontrukcie, 2.

oficilne potvrdenie zhody posudzovanej veci s nejakm tandardom
povinn riadenie prstupu [mandatory access control] typ riadenia prstupu, v ktorom operan
systm obmedzuje schopnos subjektu, alebo procesu vykonva nejak innosti, alebo pristupova k
zdrojom systmu.
preventvna innos [preventive action] innos zameran na eliminovanie potencilneho
nesladu alebo inej potencilnej neiadcej situcie
prienik [penetration] spen, opakovaten neoprvnen prstup k chrnenmu zdroju v systme
priestor, digitlny [digital space] globlnym digitlnym priestorom je Zhrnutie (a) vetkch
informanch a komunikanch technolgi, ich programovho vybavenia a dokumentcie
opisujcej ich truktru, konfigurciu a innos; (b) informci, ktor sa prostrednctvom nich
prenaj, spracovvaj alebo uchovvaj, (c) procesov, ktor v nich prebiehaj (d) podpornej
infratruktry zabezpeujcej ich innos, (e) ud zabezpeujcich ich innos (f) vzahov medzi
entitami digitlneho priestoru a pravidiel upravujcich tieto vzahy.
priestor, kybernetick [cyberspace] 1. informan a komunikan infratruktra organizcie,
ttu, alebo globlna 2. v SR podpriestor digitlneho priestoru SR, v ktorom sa spracovvaj utajovan
skutonosti
princp najmenieho privilgia [least privilege principle] podstata princpu spova v tom, e kad
entita (lovek, program, proces) v systme m prstup len k tm zdrojom ktor potrebuje na plnenie
svojho poslania
princp potreby pozna [need-to-know principle] in verzia princpu najmenieho privilgia: lovek
m prstup len k tm informcim, ktor potrebuje pozna na plnenie svojich pracovnch povinnost
prstup [access] 1. monos a schopnos entity vyuva zdroje systmu 2. interakcia entity
a systmu
prstupov prva [access rights] oprvnenia na prstup k zdrojom systmu a na vykonvanie
vybranch operci s nimi (napr. tanie a zpis dajov, spanie programov)
procedra [procedure] pecifick spsob, ako vykona nejak innos alebo proces
proces [process] postupnos navzjom svisiacich innost, ktor transformuje vstupy na vstupy
pseudonymita [pseudonymity] bezpenostn sluba umoujca uchova v tajnosti identitu
entity pred neoprvnenmi osobami tm, e sa namiesto mena pouva pseudonym. Oprvnen
osoba pozn meno osoby nahraden pseudonymom.
R
registran autorita [registration authority, RA] samostatn organizcia, alebo organizan zloka
certifikanej autority, ktor pre certifikan autoritu zabezpeuje niektor sluby (kontakt s klientmi,
prijmanie iadost o vydanie/zruenie certifiktu).
riadenie prstupu [access control] opatrenia na zaistenie toho, aby prstup ku zdrojom (aktvam)
mali len oprvnen entity a len v slade s ich prstupovmi prvami
riziko [risk] veliina zvisiaca od zvanosti hrozby a pravdepodobnosti, e sa hrozba napln.
Matematicky sa vyjadruje ako stredn hodnota dopadu hrozby na aktvum.
387
Prlohy| MF SR
riziko, analza [risk analysis] pozri analza rizk

riziko, akceptovaten [acceptable risk] rove zvykovho rizika, ktor je organizcia
schopn/ochotn tolerova
riziko, identifikcia [risk identification] proces vyhadvania, rozpoznvania a popsania rizk
riziko, kritri [risk criteria] referenn hodnoty, oproti ktorm sa vyhodnocuje vznamnos
rizika
riziko, oetrenie [risk treatment] proces modifikcie rizika
riziko, stanovenie [risk assesment] celkov proces identifikcie rizika, analzy rizk a
vyhodnotenia rizika
riziko, vyhodnotenie [risk evaluation] proces porovnvania vsledkov analzy rizk s kritriami
rizika, ktorho cieom je rozhodnutie, i je riziko a/alebo jeho hodnota akceptovaten alebo
tolerovaten
riziko, zvykov [residual risk] riziko, ktor ostalo po prijat opatren
robotick sie [botnet] mnoina potaov infiltrovanch zlomysenm softvrom, umoujcim
ich ovldanie zo vzdialenho riadiaceho centra. Takto siete sa vyuvaj na renie spamu a na
toky na vybran ciele na Internete.
rootkit [rootkit] sbor nstrojov, pomocou ktorch me tonk zska oprvnenia na rovni
sprvcu systmu.
rozhodovacie kritri [decision criteria] prahov hodnoty, ciele alebo vzory, ktor sa pouvaj na
rozhodnutie o (potrebe) innosti, alieho skmania alebo na popsanie rovne dvery v dosiahnut
vsledok
rozsah auditu [audit scope] pecifikcia toho, o sa pri audite bude posudzova a voi omu
S
sieov bezpenos [network security] ochrana siet a sieovch sluieb pred neoprvnenou
modifikciou, znienm alebo nikom dajov, zneprstupnenm sluieb a tie zaistenie zruk, e sie
sprvne funguje a nevznikaj iadne kodliv vedajie efekty
siln autentifikcia [strong autentication] autentifikcia zaloen na dvoch alebo viacerch
nezvislch metdach na overenie identity entity
slovnkov tok [dictionary attack] tok na systm, v ktorom sa na riadenie prstupu
(autentizciu pouvateov) pouvaj hesl, ktorho podstatou je preberanie slovnka
potencilnych hesiel
sniffer [sniffer] program umoujci monitorovanie komunikcie prebiehajcej prostrednctvom siete
socilne ininierstvo [social engineering] netechnick metdy prieniku do systmov zaloen na
interakcii s inmi umi, ktorch sa tonk sna nejakm spsobom oklama a prim k tomu, aby
poruili normlne pouvan bezpenostn postupy.
softvrov pirtstvo [software piracy] neoprvnen koprovanie, distribcia a pouvanie
potaovch programov, ktor spadaj pod zkon na ochranu autorskch prv
so [salt] nhodn hodnota, ktor sa pouva na zvenie odolnosti hesiel oproti slovnkovm
tokom, na generovanie kryptografickch kov a pod.
spam [spam] nevyiadan elektronick pota
388
Prlohy| MF SR
spoahlivos [reliability] schopnos/vlastnos entity sprva sa konzistentne zamanm spsobom

a dosahova poadovan vsledky
spoof [spoof] pokus neoprvnenej osoby zska prstup do systmu vydvanm sa za in
(oprvnen) osobu
spracovanie informcie [information processing] zber, prenos, uchovvanie (vlastn spracovvanie:
triedenie, spjanie vber), pouvanie, archivcia a nienie informcie
sprva rizk [risk management] identifikcia rizk, odhad rizk, vyhodnotenie rizk, prijatie opatren a
monitorovanie zostatkovch rizk, prehodnocovanie rizk.
stanovenie rizika [risk assesment] pozri riziko, stanovenie
skromnos [privacy] bezpenostn poiadavka na daje, ktorej naplnenie znamen, e osoba,
ktorej sa daje tkaj, m monos rozhodn, komu, ak a za akch podmienok sa daje, ktor sa jej
tkaj poskytn a skontrolova, i sa jej rozhodnutia dodruj
slad [conformity] splnenie nejakej poiadavky
systm [system] informan a komunikan systm sliaci na spracovanie informcie
systm riadenia informanej bezpenosti [information security management system]
systematick prstup k rieeniu informanej bezpenosti v organizcii zaloen na sbore formlne
zdokumentovanch a vzjomne koordinovanch bezpenostnch politk stanovujcich ciele a rove
informanej bezpenosti v organizcii, zodpovednos za IB, organizan zabezpeenie, upravujcich
poiadavky na personlnu bezpenos, vzahy s externmi partnermi, fyzick bezpenos,
prevdzkov a komunikan bezpenos, ochranu prstupu a slad s legislatvou.
ifra [cipher] synonymum pojmu kryptosystm

ifra, absoltne bezpen [unconditionally secure cipher] ifra, ktor sa dokzatene ned rozbi
ani s vynaloenm ubovone vekch prostriedkov. Prkladom taketo ifry je Vernamova ifra.
ifra, asymetrick [asymmetric cipher] 1. ifra, v ktorej sa na ifrovanie pouva in k
ako na deifrovanie, 2.kryptosystm s verejnm kom
ifra, blokov [block cipher] podstata tejto ifry je v tom, e sa otvoren text rozdel na asti rovnakej
dky (bloky), ktor sa nsledne ifruj pomocou toho istho tajnho ka. Vsledkom ifrovania je
postupnos blokov ifrovho textu, ktor sa deifruj pomocou deifrovacej transformcie a tajnho
ka.
ifra, klasick [classic cipher] synonymum pre symetrick ifru
ifra, permutan [permutation cipher] podstata permutanej ifry je v tom, e sa poprehadzuje
poradie znakov otvorenho textu. Tajnm kom je permutcia, urujca nov poradie znakov.
ifra, prdov [stream cipher] podstata tejto ifry je v tom, e sa z tajnho ka (inicializan
vektor alebo seed) generuje postupnos kov. Otvoren text je rozdelen na krtke bloky (asto
jednotliv znaky alebo bity) a v i-tom kroku sa i-ta as otvorenho textu ifruje pomocou i-teho
ka: ( , ) = . Pri deifrovan sa pouva ten ist genertor kov s rovnakm tajnm
kom a v i-tom kroku sa deifruje ( , ) = .
ifra, substitun [substitution cipher] substitun ifra nahrdza znaky otvorenho textu
znakmi ifrovho textu. ifra me by monoalfabetick, ke sa znak otvorenho textu nahrdza
zakadm tm istm znakom ifrovho textu, alebo polyalfabetick, ke sa znak otvorenho textu
389
Prlohy| MF SR
nahrdza jednm z viacerch (potencilne aj vetkch) znakov ifrovho textu. Vber ifrovho znaku
pre dan znak otvonho textu je dan ifrovacm kom.
ifra, symetrick [symmetric cipher] ifra, v ktorej sa na ifrovanie a deifrovanie pouva ten
ist tajn k
ifra, Vernamova [Vernam cipher] absoltne bezpen ifra. Text (binrny reazec) sa ifruje
pomocou kryptografickho ka rovnakej dky tak, e sa i-ty bit ka sta modulo 2 s i-tym
bitom otvorenho textu (deifrovanie ifrovho textu sa rob rovnako). Kryptografick k sa na
ifrovanie me poui len raz a mus by nhodn.
ifrovacia transformcia [encryption/enciphering transformation] pozri transformcia ifrovacia
ifrovanie [encryption, enciphering] transformcia otvorenho textu na ifrov pomocou
ifrovacej transformcie a ifrovacieho ka
ifrovanie od odosielatea po prjemcu [end-to-end encryption] ochrana dvernosti prenanch
sprv zaloen na tom, e odosielate sprvu zaifruje, pole ju v ifrovanej podobe prjemcovi,
ktor ju deifruje.
ifrov text [ciphertext] pozri text, ifrov
T
text, otvoren [cleartext] text, ktor nebol modifikovan iadnou kryptografickou transformciou
text, ifrov [ciphertext] vsledok zaifrovania otvorenho textu pomocou ifrovacej
transformcie E (a ifrovacieho ka).
transformcia deifrovacia [denciphering transformation] injektvne zobrazenie D, ktor
ifrovmu textu prirad otvoren text m. Deifrovacia transformcia mva okrem ifrovho textu
aj druh parameter, k, deifrovac k. K deifrovacej transformcii prislcha opan ifrovacia
transformcia E. Obe transformcie s spojen vzahom ((, ), ) = .
transformcia ifrovacia [enciphering transformation] spravidla injektvne zobrazenie E
(encryption, enciphering), ktor sprve m (otvorenmu textu) prirad ifrov text c. ifrovacia
transformcia m spravidla dva argumenty ifrovac k k a sprvu m: (, ) = . K
ifrovacej transformcii prislcha opan , deifrovacia transformcia D. Obe transformcie s
spojen vzahom ((, ), ) = .
U
innos [effectivness] rozsah v ktorom boli vykonan plnovan innosti a dosiahnut plnovan
vsledky
daje [data] forma zznamu informcie v informanch a komunikanch systmoch
udalos [event] vskyt alebo zmena pecifickej mnoiny okolnost
udalos relevantn pre informan bezpenos [information security event] identifikovan
vskyt stavu systmu, sluby alebo siete, ktor indikuje mon poruenie bezpenostnej politiky,
alebo zlyhanie bezpenostnho opatrenia; alebo dovtedy neznma situcia, ktor me ma vznam z
hadiska informanej bezpenosti
nik dajov [data leakage] nhodn tok citlivch dajov k neoprvnenej entite
390
Prlohy| MF SR
rove rizika [level of risk] hodnota rizika; v kvantitatvnom vyjadren stredn hodnota dopadu
prslunej hrozby na dan aktvum; pri kvalitatvnom vyjadren hodnota zohadujca dopad
hrozby na aktvum a pravdepodobnos jej naplnenia
tonk [attacker] osoba, ktor vykonva tok na systm, alebo nejak aktvum
systmu/organizcie
ton potencil [attack potential] znalosti, motivcia a prleitos tonka uskutoni spen
tok
tok [attack] cieavedom pokus o vyuitie nejakej zranitenosti systmu/aktva za elom
zskania neoprvnench privilgi, alebo pokodenia/znienia danho aktva, alebo niektorho
niektorho z inch aktv systmu/organizcie.
tok hrubou silou [brute force attack] kryptoanalytick tok zaloen na preberan vetkch
monost (naprklad monch deifrovacch kov, otvorench textov)
tok plnm prehadvanm [exhaustive attack] tok hrubou silou
tok typu denial of servis [denial of servis (DoS) attack] tok na systm/aplikciu s cieom
dosiahnu odmietnutie sluby
V
vniknutie [intrusion] hrozba, pri naplnen ktorej neoprvnen osoba zskava prstup k citlivm
dajom tm, e obde (myselne alebo nemyselne) bezpenostn opatrenia systmu.
voliten riadenie prstupu [discretionary access control] riadenie prstupu zaloen na tom, e
(a) oprvnenia na innos v systme s viazan na entity, ktor musia preukza svoju identitu (b)
entity s vlastnkmi systmovch zdrojov (napr. dajov), a mu inm entitm prideli alebo oda
prstupov prva k tmto zdrojom.
vyslenie rizk [risk assesment] analytick innos zameran na systm alebo organizciu, ktorej
vsledkom je identifikcia 1. aktv systmu (organizcie) 2. relevantnch hrozieb voi aktvam
systmu (organizcie) 3. bezpenostnch poiadaviek na systm (organizciu) 4. zranitenost
aktv 5. vpoet vetkch rizk vyplvajcich z relevantnch hrozieb voi aktvam systmu
(organizcie)
vydavate certifiktu [certificate issuer] v prpade digitlneho certifiktu certifikan autorita,
in intitcia oprvnen certifikova vrobky, sluby, ud, organizcie a vydva o kladnom
vsledku certifikcie osvedenie v podobe certifiktu.
vmena kov [key exchange] protokoly na vmenu, dohodnutie alebo vytvorenie tajnho ka
pre bezpen komunikciu dvoch alebo viacerch strn.
vyuitie [exploit] explicitne definovan spsob, ako narui bezpenos systmu vyuitm nejakej
jeho zranitenosti
X
X-509 [X-509] Odporanie ITU-T X509, ktor definuje rmec na poskytovanie a podporu
autentifikcie pvodu dajov a autentifikcie seberovnch (peer) entt. X-509 obsahuje formty X-509
certifiktu verejnho ka, X-509 atribtovho certifiktu a X-509 zoznamu zruench certifiktov.
391
Prlohy| MF SR
Z
zadn vrtka [trap door] skryt softvrov alebo hardvrov mechanizmus, ktor po aktivcii
umon obchdza bezpenostn mechanizmy systmu
zkladn miera [base measure] miera, ktor je funkcionlne nezvisl od inch mier
zapisova klvesnice [key logger] zlomysen program nepozorovane zaznamenvajci stlanie
klves na klvesnici, ktor nsledne poskytuje ttu informciu inmu, ako je prihlsen pouvate.
zkladn bezpenostn tandardy [security baselines] tandardy pecifikujce minimlny
(zkladn) sbor bezpenostnch opatren, ktor s za normlnych okolnost vhodn pre vinu
organizci s podobnm technickm a programovm vybavenm a provnatenmi bezpenostnmi
potrebami
zznam auditu [audit log] asovo usporiadan zoznam zpisov o bezpenostne relevantnch
udalostiach v systme. Zpis o bezpenostne relevantnej udalosti obsahuje minimlne as, popis
udalosti a identifiktor entity, ktor udalos spsobila.
zlomysen softvr [malicious software, malware] ervy, vrusy, trjske kone a in programy
vytvoren s cieom zska pre svojho pouvatea neoprvnen privilgi na cudzom potai, alebo
jeho majitea pokodi.
zneuitie identity [identity fraud] nezkonn zmena identity
zoznam zruench certifiktov [certificate revocation list, CRL] zoznam certifiktov, ktorm
bola z nejakch dvodov predasne zruen platnos. Vydva ho certifikan autorita, ktor dan
certifikty vydala a mus by v krtkych asovch intervaloch (de) aktualizovan a verejne prstupn.
zranitenos [vulnerability] vlastnos, spsob pouitia alebo okolnos umoujce naplnenie nejakej
pecifickej hrozby. Napr. pripojenie nechrnenho potaa k Internetu umouje hackersk tok,
neaktulna databza vrusov je zranitenosou umoujcou napadnutie potaa zlomysenm
softvrom.
392
Prlohy| MF SR
14.2 Anglicko-slovensk register
acceptable risk
akceptovaten riziko
access
prstup
access control
riadenie prstupu
access rights
prstupov prva
accreditation
akreditcia
accountability
dosledovatenos
advanced electronic signature
pokroil/zdokonalen elektronick podpis
air gap
fyzick oddelenie
anonymity
anonymita
asset
aktvum
attribute
atibt
attribute certificate
atribtov certifikt
attack
tok
attack potential
ton potencil
attacker
tonk
attack, brute force
tok plnm preberanm
audit
audit
audit log
zznam auditu
audit scope
rozsah auditu
authentication
autentifikcia/autentizcia
autenticity
autentickos
authorization
autorizcia, udelenie oprvnenia
availability
dostupnos
archive
archv, archivova
assymetric cryptosystem
asymetrick kryptosystm
assymetric cipher
asymetrick ifra
awareness
(bezpenostn) povedomie
backup
zlohova
base measure
zkladn miera
biometric
biometrick
biometric authentication
biometrick autentifikcia
393
Vkladov slovnk | MF SR
biometric characteristics
biometrick charakteristiky
biometric data
biometrick daje
birthday paradox
narodeninov paradox
block cipher
blokov ifra
botnet
robotick sie, botnet
brute force
hrub sila
brute force attack
tok hrubou silou
business continuity
kontinuita innosti
business continuity plan, bcp
pln kontinuity innosti
business continuity planning
plnovanie kontinuity innosti
business recovery
obnova innosti
CA
certifikan autorita
certificate
certifikt, certifikova
certificate holder
drite certifiktu
certificate issuer
vydavate certifiktu
certificate management
manament certifiktov
certificate revocation
zruenie platnosti certifiktu
certification authority
certifikan autorita
certification path
certifikan cesta
certificate revocation list, CRL
zoznam zruench certifiktov
certification service
certifikan sluba
cipher
ifra
cipher block chaining, cbc
zreazovanie ifrovch blokov, (md ifrovania blokovch ifier)
ciphertext
ifrov text
checksum
kontroln set
classic cipher
klasick ifra
classification scheme
klasifikan schma
cleartext
otvoren text
code
kd
communication channel
komunikan kanl
confidentiality
dvernos
conformity
konformnos, slad
control
prostriedok, opatrenie, riadenie
control objective
cie opatrenia
394
corrective action
korekcia, opravn innos
covert channel
skryt kanl
critical infrastructure
kritick infratruktra
CRL
zoznam zruench certifiktov
cryptanalysis
kryptoanalza
cryptographic chcecksum
kryptograficky siln kontroln set
cryptographic protocol
kryptografick protokol
cryptographic transformation
kryptografick transformcia
cryptography
kryptografia
cryptology
kryptolgia
cryptosystem
kryptosystm, ifra
cybercrime
kybernetick zloin
cyberspace
kybernetick priestor
data
daje
data classification
klasifikcia dajov
data leakage
nik dajov
day one
de jedna
day zero
de nula
deciphering
deifrovanie
declassify
deklasifikova (informciu)
decision criteria
rozhodovacie kritri
decryption
deifrovanie
decryption transformation
deifrovacia transformcia
denial of service
odopretie sluby
denial of service attack, DoS tok typu denial of service

attack
derived measure
odvoden miera
dictionary attack
slovnkov tok
digital certificate
digitlny certifikt
digital fingerprint
digitlny odtlaok (dokumentu)
digital signature
digitlny podpis
digital space
digitlny priestor
disaster recovery plan, DRP
pln obnovy
disaster recovery planning
havarijn plnovanie
395
discretionary access control

distributed denial
attack, DDoS
of
voliten riadenie prstupu
service distribuovan tok typu denial of service
DoS
odopretie sluby
eavsdropping
odpovanie
ECB
elektronick kdov kniha
effectivness
innos
efficiency
efektivita
electronic code book
elektronick kdov kniha, ifrovac mod blokovch ifier
electronic signature
elektronick podpis
enciphering
ifrovanie
enciphering transformation
ifrovacia transformcia
encryption
ifrovanie
encryption transformation
ifrovacia transformcia
end-to-end encryption
ifrovanie od odosielatea po prjemcu
entity
entita
event
udalos
exhaustiv attack
tok plnm prehadvanm
exploit
vyuitie
external context
extern kontext
granularity
granularita, jemnos
hacker
hacker
handwritten signature
vlastnorun podpis
hash
haovacia hodnota
hash function
haovacia funkcia
identification
identifikcia
identifier
identifiktor
identity
identita
identity fraud
zneuitie identity
identity theft
krde identity
incident
incident
information
informcia
information and communication informan a komunikan technolgie, IKT

technology, ICT
information classification
396
klasifikcia informcie
information infrastructure
informan infratruktra
information processing
spracovanie informcie
information security
informan bezpenos
information security event
udalos relevantn pre informan bezpenos
information security
management
incident manament informano-bezpenostnch incidentov
information security management systm manamentu informanej bezpenosti, SMIB

system, ISMS
information system
informan systm
initialization vector
inicializan vektor, poiaton hodnota PRNG
infrastructure
infratruktra
incident
incident
integrity
integrita
intrusion
vniknutie
key
key encryption key
k na ifrovanie kov
key exchange
vmena kov
key generation
generovanie kov
key logger
zapisova klvesnice
key management
manament kov
key, cryptographic
kryptografick k
key, public
verejn k
key, private
skromn k
key, secret
tajn k
least privilege principle
princp najmenieho privilgia
level of risk
rove rizika
malicious software
zlomysen softvr
malware
zlomysen softvr
mandatory access control
povinn riadenie prstupu
maximum tolerable outage
maximlna doba vpadku
maximum tolerable period of maximlna doba vpadku

disruption
measure
1. miera, 2. opatrenie
need-to-know principle
princp potreby pozna
network security
sieov bezpenos
397
non-conformity
neslad
non-repudiation
nepopretie
non repudiation of origin
nepopretie pvodu
non repudiation of receipt
nepopretie prijatia
one time password
jednorazov heslo
password
heslo
personal data
osobn daje
personal information
osobn informcie
personnel security
personlna bezpenos
physical security
fyzick bezpenos
plaintext
plaintext
penetration
prienik
permutation cipher
permutan ifra
preventive action
preventvna innos
privat key
skromn k
privacy
skromnos, skromie
pseudonymity
pseudonymita
procedure
procedra
process
proces
pseudorandom number gererator, genertor pseudonhodnch sel

PRNG
public key infrastructure, PKI
infratruktra verejnho ka
public key
verejn k
public key certificate
certifikt verejnho ka
public key cryptography
asymetrick kryptografia, kryptografia verejnho ka
public key cryptosystem
kryptosystm s verejnm kom
random
nhodn
random number
nhodn slo
random number generator
genertor nhodnch sel
Recovery Point Objective
cieov bod obnovenia
Recovery Time Objective
cieov as obnovenia
registration authority
registran autorita
reliability
spoahlivos
residual risk
zvykov riziko
398
risk
riziko
risk, acceptable
akceptovaten riziko
risk acceptance
akceptovanie rizika
risk analysis
analza rizk
risk assesment
stanovenie rizk
risk criteria
kritri rizika
risk evaluation
vyhodnocovanie rizika
risk identification
identifikcia rizika
risk management
sprva rizk
risk treatment
oetrenie rizika
risk, residual
zvykov riziko
root CA
koreov ca
root certificate
koreov certifikt
rootkit
rootkit
salt
so
secret key
tajn k
security
bezpenos
security assurance
bezpenostn zruka
security architecture
bezpenostn architektra
security awareness
bezpenostn povedomie
security baselines
zkladn bezpenostn tandardy
security by obscurity
bezpenos pomocou utajovania
security directives
bezpenostn smernice
security environment
bezpenostn prostredie
security function
bezpenostn funkcia
security goal
bezpenostn cie
security incident
bezpenostn incident
security measure/control
bezpenostn opatrenie
security policy
bezpenostn politika
security project
bezpenostn projekt
security requirement
bezpenostn poiadavka
security target
bezpenostn zmer
security violation
naruenie bezpenosti
seed
poiaton hodnota genertora pseudonhodnch sel
399
sensitive information
citliv informcia
sensitive but unclassified
citliv ale neklasifikovan (informcia)
single sign off
jedin odhlsenie
single sign on
jedin prihlsenie
signatory
podpisovate
signature
podpis
sniffer
sniffer
social engineering
socilne ininierstvo
software piracy
softvrov pirtstvo
spam
spam
spoof
spoof
stream cipher
prdov ifra
strong authentication
siln autentifikcia
substitution cipher
substitun ifra
symmetric cipher
symetrick ifra
system
systm
timestamp
asov peiatka
threat
hrozba
trap door
zadn/tajn vrtka
trusted computing base
dveryhodn vpotov bza
trust
dvera
two-factor authentication
dvojfaktorov autentifikcia
unconditionally secure cipher
absoltne bezpen ifra
validation
potvrdenie platnosti
verification
overovanie
verify
overi
Vernam cipher
Vernamova ifra
vulnerability
zranitenos
400
Zoznam literatry
[1]
D.Olejr a kol. Vkladov slovnk termnov z informanej bezpenosti, MF SR, Bratislava,

2009
[2]
B.Schneier Applied cryptography, 2nd. ed. John Willey&Sons, New York, 1996
[3]
wikipedia http://en.wikipedia.org/wiki/
[4]
http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf
[5]

management systems Overview and vocabulary
401
14.3 Zoznam skratiek
BCM
angl. Business Continuity Management (manament kontinuity innosti)
BIA
angl. Business Impact Analysis (analza dopadov na biznis)
CGEIT Certified in the Governance of Enterprise IT

CISA angl. Certified Information Systems Auditor
CISM angl. Certified Information Security Manager
IKT
informan a komunikan technolgie
IS
informan systm
ISACA angl.
ISVS
Information Systems Audit and Control Association
Informan systmy verejnej sprvy
MF SR Ministerstvo financi Slovenskej republiky

MTO
angl. Maximum tolerable outage (maximlna doba vpadku)
MTPD angl. Maximum tolerable

vpadku/preruenia)
NIKI
period
of
disruption
Nrodn informan a komunikan infratruktra
PDCA angl. Plan Do Check Act

RPO
angl. Recovery Point Objective (cieov bod obnovenia)
RTO
angl. Recovery Time Objective (cieov as obnovenia)
SLA
angl. Service Level Agreement
402
(maximlna
prpustn
doba

Stud 2014 02 IT IB Ucitelia

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Stud 2014 02 IT IB Ucitelia

Uploaded by

Copyright:

Available Formats

Projekt

Vypracovanie tandardov zkladnch znalost, metodickch

Zstupcovia oprvnench osb

tudijn materily vypracoval odborn tm v zloen (bez titulov, poda abecedy):

Ministerstvo financi Slovenskej republiky

Bratislava, december 2013

Zklady informanej bezpenosti | MF SR

2 Manament informanej bezpenosti ...................................................................................18

Bezpenostn stratgia a bezpenostn politika organizcie ..........................................19

Implementcia Bezpenostnej stratgie/politiky.............................................................21

Zapojenie zamestnancov do IB procesu..........................................................................23

Budovanie know-how v informanej bezpenosti ..........................................................25

Analza rizk ...................................................................................................................26

Spravovanie rizk ............................................................................................................33

Bezpenostn audit .........................................................................................................34

Prloha. Katalg elementrnych hrozieb .........................................................................42

Prloha. Zoznam zranitenost .........................................................................................43

Prloha. Obsah bezpenostnej politiky ............................................................................47

Prloha. Klasifikcia informcie a systmov ...................................................................48

Znalostn tandardy pre oblas IB ..................................................................................52

3 Architektra, modely a hodnotenie ......................................................................................69

Operan systm ....................................................................................................72

Databzov systm .................................................................................................75

Virtualizcia, cloud ................................................................................................76

Model klient-server ................................................................................................76

Bezpenostn funkcie vrstiev .................................................................................77

Hodnotenie systmov ......................................................................................................79

Funkn bezpenostn poiadavky ........................................................................80

Poiadavky na bezpenostn zruky ......................................................................82

Zklady informanej bezpenosti | MF SR

Poiadavky na vyhodnocovanie PP a ST ...............................................................83

rovne hodnotenia (EAL) ......................................................................................83

Vznam a rizik hodnotenia produktov poda CC .................................................84

4 Riadenie prstupu .................................................................................................................86

Zoznam pouitej literatry ............................................................................................125

5 Aplikan bezpenos ........................................................................................................126

Bezpenostn chyby v softvri .............................................................................127

Konfiguran chyby .............................................................................................127

Nedostatky v bezpenosti prevdzky ...................................................................127

Aplikan bezpenostn funkcie ...................................................................................128

Dleit vahy pri vobe bezpenostnch funkci ...............................................128

Aplikan bezpenostn funkcie ..........................................................................129

Typick zranitenosti aplikci a opatrenia proti nim ...................................................132

Typick zranitenosti aplikci .............................................................................132

Opatrenia na znenie dopadov aplikanch chb ...............................................138

Pouvanie otvorench tandardov ...............................................................................143

Tvorba informanch systmov (poiadavky Vnosu o tandardoch pre ISVS) .........145

Zoznam pouitch zdrojov............................................................................................149

6 Bezpenos prevdzky .......................................................................................................150

Pokrytie biznis procesov operciami IS ...............................................................151

innosti manamentu prevdzky .........................................................................152

Kontroln mechanizmy ........................................................................................153

Riadenie zmien .....................................................................................................157

Nstroje automatizcie manamentu prevdzky ..................................................161

Vyuitie tretch strn pri dodvke sluieb (outsourcing) ..............................................162

Rizik vyuitia tretch strn..................................................................................162

Ochrana proti kodlivmu kdu ....................................................................................162

Ochrana proti phishingu .......................................................................................164

Ochrana proti vrusom ..........................................................................................164

6.4.3 pecifick hrozby svisiace s pouvanm mobilnch zariaden a vzdialenou prcou

Automatizcia detekcie a rieenia bezpenostnch incidentov ............................168

Redundancia sieovej infratruktry a zlohovanie dt ................................................168

Klastre s vysokou dostupnosou ..........................................................................169

Zlohovanie a obnova ..........................................................................................169