Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
>MĹ,Ž Evidenční Č. smlouvy Objednatele: S-263-030/ 2019
ˇ/ Č. ;.z 1/2019-030-SML/1
470,. ;‰°f.,ˇ
4.- '.›".'.“n.l,ì ›1 Výtisk č.:
'
Smlouva o poskytování sluzeb
DOK „Aktualizace systému a poskytnutí technické podpory“
uzavřená podle § 1746 Odst. 2 Zákona č. 89/2012 Sb., občanský Zákoník (dále jen
„Občanský Zákoník“)
Článek I.
Smluvní strany
1. Česká republika - Ministerstvo dopravy
Sídlo: nábřeží Ludvíka Svobody 1222/12, 110 15 Praha 1
óó003008
IČO; CZ66003008
DIČ;
Zastoupena:
Bankovní spojení: ČNB Praha 1, Na Příkopě 28
č. účtu: ,
(dále jen „Objednatel“)
WAK 2. System, spol. S r.o.
Sídlo:
IČO; 25720384
DIČz CZ25720384
Zastoupena:
Bankovní spojení: Raiffeisenbank, a.s.
č-úflvz 16.12.1998
Datum registrace:
Spisová Značka: oddíl C, vložka 64160 vedená u Městského soudu v Praze
(dále jen ,,Poskytovatel“)
Čıánøk II.
Předmět Smlouvy
l . Předmětem této smlouvy je závazek Poskytovatele Zajistit pro Objednatele služby
DOK aktualizace a technické podpory informačního systému Dopravní informační systém
(dále jen ,,DOK“) podle specìfikace uvedené v Odst. 2. tohoto článku Smlouvy, a Závazek
Objednatele za řádně poskytnuté služby Zaplatit Poskytovateli dohodnutou cenu podle
čl. V. této Smlouvy.
2. Předmětem této smlouvy je zajištění následujících služeb rozdělených do dvou oblastí:
1 / 15
Evidenční Č. smlouvy Qbjednatelez S-263-030/2019
Č. in 1 /2019-030-SML/1
DOK Oblast I - Aktualizace systému
DOK Předmětem Aktualizace systému je Zajištění podmínek kybemetické bezpečnosti
a implementace nařízení GDPR.
DOK I.l Veřejná část systému
DOK Předmětem aktualizace veřejné části Systému bude:
DOK 0 Konverze databází systému za účelem provozu systému v prostředí vyšší verze
SQL Serveru. Verze SQL serveru bude určena Obj ednatelem v objednávce dodávky a bude
vyhovovat požadavkům kybemetické bezpečnosti.
0 Odstranění asp stránek S nutností autentizace zobrazování dat v mapových podkladech
a S tím souvisejících funkčností.
DOK 0 Konverze komponent systému pro prostředí platfonny .NET 4 (akt. runtime
a zajištění verze release).
0 Kontrola funkčnosti systému po provedených konverzích včetně funkčnosti systému na
protokolu https.
0 Implementace Opatření proti útokům SQL inj ection a Cross Site Scripting parametrìzací
dotazů a auditem skriptů jednotlivých asp stránek (cca 100 asp souborů).
0 Kontrola funkčnosti a bezpečnosti Systému po provedených úpravách.
DOK 0 Instalace a ověření funkčností systému a jeho bezpečnosti v novém systémovém
prostředí Objednatele. Realizace opatření proti případným Zjivsvteným zranitelnostem.
1.2 Implementace Nařízení GDPR u celého systému DOK
Předmětem implementace bude:
0 Fyzické odstranění všech osobních údajů Z celého Systému DOK.
0 Úprava formulářů s ohledem na odstranění osobních údajů.
0 Odstranění odkazu na databázi bezpečnostních poradců. “
0 Vizuální kontrola obsahu Název a Poznámka části Ekologické havárie (38.000
záznamů) a vymazání osobních údajů (jména osob, registrační značky dopravních
prostředků, rodná čísla, atd.).
0 Kontrola funkčnosti a bezpečnosti Systému po provedených úpravách.
DOK 0 Instalace a ověření funkčností Systému a jeho bezpečnosti v novém systémověm
prostředí Objednatele. Realizace opatření proti případným Zjivsvteným zranitelnostem.
2 / 15
Evidenční Č. smlouvy Objednatele: S-263-030/2019
Č. in 1/2019-030-SML/1
DOK Oblast II - Zajišťování pravidelné technické podpory systému
DOK Předmětem pravidelné technicke' podpory systému bude:
' Hotline -libovolného rozsahu.
' Vzdálená čtvrtletní servisní údržba databáze a softwarová prohlídka systému.
' Práce (dle oboustranně potvrzéného předávacího protokolu) související se
zabézpéčéním rutinního provozu systému V celkovém rozsahu 10 hodin/rok:
- Nasazení aktualizací Soflwarových komponent, které nejsou Standardní
součástí operačního systému.
- Spolupráce při nasazování aktualizací softwarových komponent, které jsou
standardní součástí operačního Systému, řešení případných nekompabilit.
- Spolupráce při odstraňování Zranitelností, které budou zjištěny
v komponentách aplikace.
Předmět plnění musí být Poskytovatelem předán Objednateli v řádném a provozuschopném
stavu, bez vad a zjevných nedodělků, a to včetně procesu akceptace Objednatelem.
Podkladem pro a/kceptaci bude „Přédávací protokol Poskytovatelé“.
Čıánøk III.
Doba, místo a způsob plnění
Služby je Poskytovatel povinen poskytovat průběžně od data účinnosti Smlouvy (dle článku
XIV. odst. 1 této smlouvy) v následujících termínech:
DOK a) Oblast I- Aktualizace systému
Etapa I. 1: do tří měsíců ode dne účinnosti této smlouvy
Etapa I. 2: do tří měsíců ode dne účirmosti této smlouvy
I
Plnění služeb bude realizováno formou vzdálené instalace úpravy do připraveného I
I
I
systémového prostředí určeného serveru. Předání provedených služeb bude oznáníéno
4-4
odpovědným osobám Objednatele (dle článku VII. této smlouvy) elektronicky, pomocí 444
emailové zprávy formou „Přédávacího protokolu Poskytovatelé“.
DOK b) Oblast II - Zajišťování pravidelné technické podpory Systému od následujícího
měsíce, kdy bylo ze strany Objednatele akceptováno plnění dle čl. III odst. I písm. a) a
to po dobu 48 měsíců.
Plnění služeb bude realizováno formou servisního zásahu pomocí vzdáleného přístupu
nebo v rámci osobní návštevy povereného pracovníka Poskytovatelé v systémovém
prostředí určeného serveru. Předání provedených Služeb bude oznámeno odpovědným
3/15
Evidenční Č. smlouvy Objednatele: S-263-030/2019
Č. in 1 /2019-030-SML/1
osobám Objednatele (dle článku VII. této Smlouvy) elektronicky, pomocí emailové
Zprávy formou „Předávacího protokolu Poskytovatelé“.
Smlouva se uzavírá na dobu 51 měsíců od data její účinnosti dle čl. XIV. odst. 1 této
V Smlouvy popř. do vyčerpání částky ve výši maximální celkové ceny smlouvy dle čl. odst.
1 této smlouvy, nastane-li dříve.
Místem plnění předmětu smlouvy je Sídlo Objednatele.
Požadavky na Poskytovatelé mohou vznášet písemně pouze oprávněné osoby Objednatele:
Případné Změny oprávněných osob budou Poskytovateli sděleny písemně.
Objednatel je povinen do jednoho měsíce od data účinnosti smlouvy (dle článku XIV. odst.
1 této smlouvy) Zajistit pro Poskytovatelé aktuální verze Windows a SQL serveru, včetně
DOK Zajištění vzdáleného přístupu pro administrátory IS (prostřednictvím Serveru na
vnitřní síti)
Zajištění systémového prostředí bude oznámeno odpovědným osobám Poskytovatele (dle
článku VII. této smlouvy) elektronicky prostřednictvím e-mailové Zprávy, která bude
obsahovat systémové parametry prostředí a SQL Serveru, přístupové údaje a nastavená
přístupová oprávnění.
Povinnosti vyplývající ZPřílohy č. 4 této smlouvy se vztahují pouze k prostředí
Spravovanému Poskytovatelem. Zálohování provádí Objednatel.
Dokumentace bude provedena v souladu S ustanovením článku 8 Přílohy č. 3 této smlouvy
a bude obsahovat zejména:
- administrátorskou dokumentaci, včetně instalačního manuálu
HW SW - konfiguraci použitého
a pro provoz
Článek IV.
Schválení poskytnutých služeb
1 Poskytovatel splní Svou povimıost řádně poskytnout služby dnem, kdy je příslušná činnost
řádně vykonána a její výstup je akceptován Objednatelem dle odst. 2 tohoto článku.
4 / 15
Evidenční Č. smlouvy Objednatele: S-263-030/2019 'Í
Č. i.z 1/2019-030-SML/1
1
Řádné splnění povinností Poskytovatele Osvědčí Objednatel podpisem Akceptačního
protokolu u oblasti I jednorázově a u oblasti II za každé 3 kalendářní měsíce, přičemž každá
ze stran obdrží po jednom jeho vyhotovení. Časová náročnost plnění předmětu Smlouvy dle
čl. II. této Smlouvy musí být v Akceptačním protokolu vyčíslena v členění na jednotlivé
činnosti.
Akceptační protokol musí obsahovat minimálně tyto infonnace:
0 Soupis provedených Služeb,
0 doba strávená řešením
0 informaci, Zda výstupy byly Objednatelem akceptovány, akceptovány
S výhradami, či neakceptovány,
0 datum akceptace,
0 podpisy odpovědných osob za obě Strany.
Zjistí-li Objednatel v plnění Poskytovatele nebo při předání výstupů Služeb zjevné vady,
je povinen o tom sepsat zápis S uvedením zjištěných vad, podepsaný oprávněnou osobou
Objednatele. takovém případě je lhůta Poskytovatele Ana analýzu zjištěných vad 10
pracovních dnů od doručení tohoto zápisu.
Lhůta pro odstranění zjištěných vad činí 10 pracovních dnů ode dne doručení tohoto zápisu
Poskytovateli. Do doby odstranění vad není Objednatel povinen podepsat Akceptační
protokol ani zaplatit cenu za poskytnuté Služby.
Pokud Obj ednatel do 10 pracovních dnů po předání výstupů Služeb neakceptuje poskytnuté
plnění nebo nepředá Poskytovateli zápis S uvedenými Zjištěnými vadami, je Poskytovatel
povinen Objednatele písemně vyzvat k akceptaci nebo k oznámení případných vad. Pokud
Objednatel v dodatečné lhůtě 10 pracovních dnů ode dne doručení oznámení Poskytovatele
podle předchozí věty nepředá Poskytovateli zápis S uvedenými Zjištěnými vadami, je plnění
Poskytovatele považováno za akceptované Objednatelem.
Článek V.
Celková cena
Smluvní Strany se dohodly, že celková cena za poskytování služeb, nepřesáhne částku
ve výši 248.400,- Kč bez DPH, tj. 300.564,- Kč S DPH. Detail ceny je uveden V Příloze č.
1, která je nedílnou Součástí této smlouvy.
5/15
Evidenční Č. smlouvy Objednatele: S-263-030/2019
Č. jn 1 /2019-030-SML/1
Ceny dle tohoto článku jsou cenami maximálními a nepřekročitelnými a zahrnují veškeré
náklady Poskytovatelé související S plněním předmětu této smlouvy.
V případě změny DPH dané právními předpisy bude k ceně bez DPH přiúčtována daň dle
sazby platné ke dni zdanitelného plnění.
Čıánøk vı.
Platební a fakturační podmínky
Cena Za plnění předmětu této Smlouvy bude Objednatelem placena na základě
Poskytovatelem řádně vystavené faktury, po ukončení jednotlivých etap (včetně akceptace
Objednatelem) dle čl. III. odst. 1 písm. a) této smlouvy, resp. za každé 3 kalendářní měsíce
zpětně V případě plnění dle čl. III. odst. l písm. b) této Smlouvy.
Dnem platby se rozumí den, kdy je fakturovaná částka odeslána Z účtu Obj ednatele na účet
Poskytovatelé uvedený na faktuře, který musí odpovídat číslu uvedenému v záhlaví této
Smlouvy nebo číslu účtu uvedenému V registru plátců DPH. Případnou Změnu čísla účtu je
Poskytovatel povinen Objednatelì písemně oznámit a na Zpětný dotaz Obj ednatele opětovně
písemně potvrdit, jinak je Objednatel oprávněn fakturu vrátit Poskytovateli podle
odst. 7 tohoto článku.
Objednatel nebude poskytovat Poskytovateli žádné Zálohy na cenu za plnění předmětu
smlouvy v jakékoli fomıě.
Smluvní Strany se dohodly na době splatnosti jednotlivých faktur 30 kalendářních dnů ode
dne jejich doručení Objednatelì. Faktury Poskytovatelé budou předávány elektronicky na
emailovou adresu Objednatele ebo datovou schránkou.
Oprávnění fakturovat cenu vznikne Poskytovateli po odsouhlasení a převzetí plnění
Objednatelem formou Akceptačního protokolu, jehož kopii je Poskytovatel povinen
k faktuře připojit.
__
F aktura vystavená Poskytovatelem musí obsahovat náležitosti daňového dokladu stanovené
právními předpisy, evidenční číslo a název smlouvy Objednatele. Poskytovatel bude
fakturovat poskytnuté Služby Zvlášť, resp. v členění dle jednotlivých Služeb uvedených
v Příloze č. l této Smlouvy.
V případě, že faktura nebude obsahovat stanovené náležitosti, anebo údaje v ní obsažené
budou chybné, je Objednatel oprávněn zaslat ji ve lhůtě splatností zpět Poskytovateli
k doplnění či opravě, aniž se tím dostane do prodlení S jejím zaplacením; lhůta splatnosti
počíná bevzvet Znovu ode dne doručení bezvadné faktury Objednatelì.
6 / 15
Evidenční Č. Smlouvy Objednatele: S-263-030/2019
Č. in 1 /2019-030-SML/1
Čıánøk VII.
Odpovědné osoby
Osoby odpovědné za řádné Splnění povirmostí dle této Smlouvy jsou:
0 na Straně Poskytovatelé:
ı na Straně Objednatele:
Článek VIII.
Povinnosti a práva Poskytovatelé
Poskytovatel je povinen spolupracovat S oprávněnými pracovníky Objednatele ve věci
plnění předmětu této Smlouvy.
Poskytovatel je povinen na požádání informovat Objednatele o průběhu plnění předmětu
této smlouvy akceptovat nebo řádně vypořádat jeho doplňující pokyny a připomínky
Související S plněním předmětu této Smlouvy. ˇ,
Zjistí-li Objednatel v průběhu plnění předmětu této Smlouvy nedostatky, je Poskytovatel
povinen na písemnou výzvu tyto nedostatky bezodkladně odstranit nebo řádně vypořádat
bez nároku na navýšení celkové ceny, nejdéle však do 10 pracovních dnů ode dne doručení
výzvy.
Poskytovatel je povinen upozornit Objednatele na nevhodnost jím udělených pokynů,
jestliže tuto nevhodnost mohl Zjistit při vynaložení odbomé péče. Poskytovatel je však
povinen pokyny Objednatele splnit, trvá-li na tom Objednatel i přes jeho upozomění,
v takovém případě však Poskytovatel neodpovídá za tím vzniklou škodu.
7/15
É* Ť
n. 13Oo.1nba2splejn.Vjoř11ibúeeaS.beP0čpdoškn.ěopdpePonkpýa9sooálřospaPer.m8zkdyesspnkřtob.rávakyzp7OnkkříyeesePáv.štáosobye6Ptteynlmkzošnsoke.tl5vjétPcooeyedtspdkí.vlctaOiaeěoohsOvtcPkmoroopomaPabhonvdspdavkbaoohypěváPdhřtoidjřnaoksndtnyvlsjřtáPovtáeesuionSěetyavpyotakeonoepsjaulkndddátmpetteosottyvvsříadkzyépncířlpnlorelvtnretztaekkyntptetařhmnvrluoaá,oloneodtyvtojétaotůoeoěaeattípdtvuýettuueýoevtjsdpdzntsseřcioížaolcnovsvlaeeíoopleícoielsommotvhtíateytjsltpulšdshhoyb.pevlýatpmuS,ieíjrežem,looovokelrtnoenoápláeojnePsmatelzbípneáíoalaucmuvpeíedbjojáíěoldlkvzokpir.viřjpíszsept.anháupnyuíppcpgenaeyiřvkzjjooěoobvíělsrkoioeáyčeýaevponnpvensynn,dveoptntcenkííodlpteOzěielsooiomrkhámšeíndvbíbsneejdVunpvppnánížžákmáiojžoípppsoenlnarcřevčékíouzenobřrjrnpeeednltíánetnnvpyhddze.aieuoejjnmorezviděentdřounplpnddkolnžahXsVpnaměntbbeeodcřýeoIueepéyontějaěnepozdopphe.vmjsnřheviabnkševtzdtsdlmooíděoíleooiíoouyněpouzonrvczpěm,pudicmdvsnjjdlírpdíěžaíoMthoěhoésvmaienůscskgnožihožuoltrtttožědněshoílmuvánzosá.apěz5uolenřodutanijalndoscSpraátsíšoSbho2asdítkpphuoeáébvářmvliesllptpntSotríanumvaeellotnamerlooěnr5vatšísdtnoévpsdOosírvalnzocýEtkosteěpybomnussmuckpouěpovoacovítUsřinmjtěmoovlonrunvhadete.pevnsvOltsantybSaítnřěuvvdřadmnbézoavuazpndcu,ímžýsypenjílauuhýícnváíoocddscciaectolvcopeyevvshEhhpřchotosbédtituyhřvbnahákáevoetůupopvnueúov,ierddoítzsnozpiřpmarděldčvjpypánneedcěonndketyneaaěsaooe.lnjěkrjužuhomeůdeůsěvmtvnputiah,eoíithslnpětjíSeiyltlouhtlíZteVoičpdtřceknonnvkéíoam,ospnídOírnudpnpěučatvsypoíbroopůonréaadvjamčusSshnvrajdtsvřípseůyOČálůeaemuyocVáž.etrjoesřob.biMvntjOlbovtíidždazdejfisdSběésvbkiovoocnoynuntiekdmehumoějcphnuSvděvoazikdlmltueuPdleoívaanpsVteonošddSáoělodbodkoytůttérševaímnadoutdmsynluu.u.useeaatlhadmvk.alebezdalovrknoeteupčyynPloábsoVpooyýtlemltetioýtidžruéjvcsomleúaOéSzonstvltmoeosvhmedypttbooaoořkvjaíirn.opyjnyruceleuybap,épuoeéveaotíjatrSzetVčČSíidOvíZdcidopppavmec.ecsnbřOmívcssooévplsceholllennajbdheltvp,rčeanšořeosoetzíkeějářáíoonozritěseomvzeudmřeuv,e,tuíasteunujznlnnnp1vndájdpivvlíoňvíeááaın/yínjýtvndsiey:obk'tymřva.Sa2aseěsnmSconn,veůeitalkOneeSptíOhdaý.lpteopvízPoís1nm-mombůptemllslřrppní92anaujzo.taienosoýbo-6jétezikvsdpělnmy3Oíktedpyeííunin~i3irynždpsíímOsáOkiapnáremdy3i-áátrymo.ř0clsoesne/iůMltšě2miLee0./mn11í9
I
›
8/15
Evidenční Č. Smlouvy Objednatele: S-263-030/2019
Č. in 1/2019-030-SML/1
Poskytovatel je oprávněn uvádět systém DOK, jako svoje dílo vytvořené pro Objednatele
(pouze pro obchodní prezentaci nebo reference provedených prací V rámci obchodních
nabídek).
V případě, že bude Objednatel v prodlení S plněním dle čl. III odst. 5 této Smlouvy, budou
O počet dnů prodlení Objednatele posunuty časové lhůty Poskytovateli pro plnění dle čl. III
odst. 1 této Smlouvy.
Článek IX.
Povinnosti a práva Objednatele
Obj ednatel se zavazuje poskytnout Poskytovateli potřebné podklady, odbomé konzultace a
součinnost nutnou k plnění předmětu této smlouvy.
Objednatel se zavazuje umožnit vstup pracovníkům Poskytovatele na pracoviště
Objednatele během jeho pracovní doby za účelem plnění předmětu této Smlouvy.
Objednatel je oprávněn svolávat po dohodě S Poskytovatelem pracovní schůzky k řešení
Spomých otázek, souvisejících S plněním předmětu Smlouvy.
Objednatel bude na požádání konzultovat v průběhu realizace plnění s Poskytovatelem
přijatá řešení a to nejpozději do 10 pracovních dnů od doručení písemné žádosti, pokud není
dohodnuto jinak. Objednatel zajistí pro takovéto konzultace účast kvalitˇıkovaných
pracovníků.
Objednatel je oprávněn vyjadřovat se písemně k předkládaným písemným materiálům
Poskytovatele, ato nejpozději do 10 pracovních dnů od jejich doručení, pokud není
dohodnuto jinak. Připomínky Obj ednatele je Poskytovatel povinen náležitě vypořádat.
Objednatel poskytne na vyžádání Poskytovateli konzultaci k bezpečnostnímu testování
Systému DOK, a to nejpozději do jednoho měsíce ode dne vyžádání.
Článek X.
Smluvní pokuta, úrok z prodlení
V případě prodlení Objednatele S úhradou řádně vystavené faktury je Objednatel povinen
zaplatit Poskytovateli úrok Z prodlení v zákonné výši Z dlužné částky za každý započatý
den prodlení.
V případě prodlení Poskytovatelé S řádným poskytnutím služeb v termínu stanoveném dle
čl. III. odst. 1 této Smlouvy nebo S plněním povìrmostí stanovených V čl. VIII. odst. 3 této
Smlouvy, je Poskytovatel povinen Zaplatit Objednateli smluvní pokutu ve výši 100,- Kč
9/15
› ..___4_„__
Evidenční Č. Smlouvy Objednatele: S-263-030/ 2019
Č. ).z 1/2019-O30-sML/1
V Za každý Započatý den prodlení. případě porušení povimıosti stanovených v čl.
VIII. odst. 13 Zaplatí Poskytovatel Objednateli Smluvní pokutu ve výši 10.000,- Kč.
Smluvní pokuta a úrok Z prodlení jsou splatné ve lhůtě 30 kalendářních dnů ode dne
doručení jejich vyúčtování druhé smluvní straně.
Zaplacením smluvní pokuty není dotčen nárok Objednatele na náhradu škody ani povinnost
Poskytovatelé řádně dokončit příslušné plnění předmětu Smlouvy, popř. odstranit vady.
Článek XI.
Ukončení smlouvy, odstoupení od smlouvy
Smluvní vztah vzniklý na základě této Smlouvy lze ukončit těmito způsoby:
a) písemným odstoupením od Smlouvy Za podmínek uvedených v § 2002 Občanského
Zákoníku v případě podstatného porušení smlouvy druhou smluvní Stranou,
b) písemným odstoupením od smlouvy v souladu S § 2001 Občanského zákoníku v případě
porušení smluvních povinností druhou Smluvní stranou uvedených v odst. 2 tohoto
článku smlouvy.
c) písemnou dohodou smluvních stran v souladu S § 1981 Občanského zákoníku,
d) písemnou výpovědí.
Smluvní Strany se dohodly, že jsou oprávněny odstoupit od Smlouvy dle odst. l písm. b)
tohoto článku:
a) Objednatel v případě porušení povinností Poskytovatelé stanovených v čl. VIII. odst. 8,
9, 10 nebo 13 této smlouvy,
b) každá ze smluvních stran v případě porušení povinností druhou smluvní Stranou
stanovených v čl. XII odst. 1 nebo čl. XIV odst. 4 této Smlouvy.
Účinky odstoupení od Smlouvy nastávají dnem doručení písemného oznámení o odstoupení
druhé smluvní Straně.
Kterákoliv Smluvní Strana může tuto Smlouvu písemně vypovědět bez uvedení důvodu
s jednoměsíční výpovědní lhůtou, která počíná běžet dnem doručení písemné výpovědi
druhé Smluvní straně. Vypovědět Smluvní vztah lze nejdříve po dokončení oblasti I.
Ukončením smlouvy není dotčen nárok na zaplacení smluvní pokuty nebo úroku Z prodlení,
pokud již dospěl, případně nárok na náhradu škody vzniklé porušením této Smlouvy.
10/15
Evidenční Č. smlouvy Objednatele: 5-263-030/2019
Č. j.z 1 /2019-030-SML/1
Článek XII.
Další ujednání
Žádná ze smluvních stran není oprávněna poskytnout třetím osobám jakékoliv informace
o podmínkách této Smlouvy a souvisejících S touto smlouvou, jejichž obsahem mohou být
důvěmé informace, osobní a citlivé údaje, informace týkající se obchodního tajemství,
technologie nebo know-how, S výjimkou povinnosti poskytovat informace podle zvláštních
předpisů. Ustanovení odst. 5 tohoto článku tím není dotčeno.
Závazky dle předchozího odstavce tohoto článku zůstávají v platnosti i po ukončení
účinnosti této smlouvy.
Dnem předání jakéhokoliv plnění Poskytovatelem Objednateli dle smlouvy, které naplňuje
znaky autorského díla podle příslušných právních předpisů, uděluje Poskytovatel
Objednateli, jakož i dalším osobám, které mají tohoto plnění pro účely Smlouvy využívat, V
oprávnění k užití (licenci) takovéhoto plnění všemi způsoby nezbytnými pro účely smlouvy
bez množstevního nebo územního omezení. Tato licence je ke každé části plnění 1
akceptované podle smlouvy udělena jednorázově jako licence nevýhradni, neodvolatelná
a udělená na celou dobu tn/ání majetkových práv k dílu. Odměna Poskytovatelé
za poskytnutí licence je zahrnuta v ceně za poskytování služeb. Součástí licence je i Souhlas
Poskytovatele udělený Objednateli k provedení jakýchkoliv změn nebo modifikací
uvedeného plnění, a to i prostřednictvím třetích osob, a souhlas k poskytnutí oprávnění užít
toto plnění třetím osobám dle uvážení Objednatele, oprávnění spojit plnění s jiným
autorským dílem, zařadit do jiného díla, zařadit do Soubomého dila a takto je užít způsobem l
dle tohoto odstavce, oprávnění k rozmnožování plnění, oprávnění k užívání zdrojových
kódů a dokumentace plnění včetně jejich poskytnutí třetím osobám pro dobu po ukončení
této smlouvy.
Poskytovatel je povinen Objednateli předat veškeré aktuální zdrojové kódy provozované
aplikace a technickou dokumentaci, na jejichž základě bude mít Objednatel možnost provést l
případný další rozvoj bez součimosti S Poskytovatelem. Veškerá data jsou ve vlastnictví
Objednatele.
Poskytovatel bere na vědomí a souhlasí S tím, že Objednatel v souladu se zákonem
č. 340/2015 Sb., o zvláštních podmínkách účimıosti některých smluv, uveřejňování těchto
smluv a o registru smluv (Zákon o registru smluv), ve Znění pozdějších předpisů, uveřejní
celé znění smlouvy, včetně jejich příloh, změn a dodatků v registru smluv.
11/15
Evidenční Č. smlouvy Objednatele: S-263-030 / 2019
Č. in 1/2019-030-SML/1
Čıánøk XIII.
Ochrana osobních údajů
Smluvní strany se po dobu zpracování osobních údajů Zavazují dodržovat povinnosti
stanovené v Nařízení EU č. 2016/679 ze dne 27. dubna 2016, o ochraně fyzických osob v
souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o znıšení
Směmìce 95/46/ES (obecné nařízení o ochraně osobních údajů) (dále jen „Nařízení
GDPR“).
Budou-li informace poskytnuté Objednatelem či třetími stranami, které jsou nezbytné pro
plnění dle této Smlouvy, obsahovat údaje podléhající režimu zvláštní ochrany podle
Nařízení GDPR, je Poskytovatel povinen zajistit ochranu poskytnutých údajů podle
Nařízení GDPR, zejména:
a) je oprávněn v rámci plnění předmětu této smlouvy zpracovávat osobní údaje pouze
v rozsahu nezbytném pro řádné plnění předmětu této Smlouvy;
oprávněn zpracování osobních údajů v rámci plnění předmětu této smlouvy vv
Sverit,
není
V b)
a to ani zčásti, jiné osobě bez předchozího písemného souhlasu Objednatele. případě
svěření zpracování osobních údajůjiné osobě odpovídá Poskytovatel za to, že tato osoba
zajistí ochranu osobních údajů ve stejném rozsahu jako je Poskytovatel povinen podle
této Smlouvy;
c) postupovat v souladu S pokyny Objednatele stanovenými pro zpracování osobních
údajů;
d) zavázat mlčenlivostí veškeré osoby podílející se na zpracování osobních údajů;
e) přijmout veškerá opatření k ochraně zabezpečení zpracování osobních údajů uvedená
`
zejména v čl. 32 Nařízení GDPR;
GDPR Í) poskytovat Objednateli součinnost nezbytnou pro splnění povinností Objednatele vůči a
subjektům osobních údajů při výkonu jejich práv podle kapitoly III. Nařízení
pro zabezpečení ochrany osobních údajů podle čl. 32 až 36 Nařízení GDPR;
g) poskytnout Objednateli veškeré informace nezbytné k doložení splnění povinností podle
tohoto článku;
h) vést záznaıny o zpracování osobních údajů, které Poskytovatel provádí pro Objednatele;
12 / 15
Evidenční Č. Srnlouvy Objednatele: S-263-030/2019
Č. ;.z 1/2019-030-SML/1
i) neprodleně Objednateli oznámit případnou ztrátu, poškození, nebo neoprávněné
zpřístupnění osobních údajů, popř. jakýkoliv jiný bezpečnostní incident dle Nařízení
GDPR ve svevvrené oblasti Zpracování osobních údajů;
j) umožnit provedení auditů a kontrol plnění povinností podle tohoto článku Objednatelem
nebo jím povevrv enou osobou a poskytnout k tomu nezbytnou součinnost;
GDPR k) dodržovat další povirınosti a podmínky stanovené Nařízením V Souvislosti se
zpracováním a ochranou osobních údajů;
1) pokud podle názoru Poskytovatele určitý pokyn Objednatele porušuje Nařízení GDPR
nebo jiné obecně závazné předpisy týkající se ochrany osobních údajů, je Poskytovatel
povinen o této skutečnosti Objednatele neprodleně informovat;
m)při ukončení zpracovávání osobních údajů v souladu S touto Smlouvou je Poskytovatel
povinen zlikvidovat veškeré poskytnuté osobní údaje a osobní údaje zpracovávané
V rámci plnění předmětu této smlouvy.
Čıánøk XIV.
Závěrečná ustanovení
Tato smlouva nabývá platnosti dnem jejího podpisu oběma smluvními stranami a účinnosti
dnem uveřejnění v registru smluv.
Závazkové vztahy vzniklé podle této smlouvy a na jejím základě se řídí zejména
Občanským zákoníkem.
Tuto smlouvu lze měnit, upravovat či doplňovat pouze fomıou písemných, vzestupně
číslovaných dodatků, odsouhlasených a podepsaných oběma smluvními stranami. Tyto
dodatky se stávají nedílnou součástí této smlouvy.
Žádná Ze smluvních stran není oprávněna postoupit či jinak převést svá práva nebo
povinnosti vyplývající Z této smlouvy bez předchozího písemného souhlasu druhé smluvní
strany.
Tato smlouva je vyhotovena ve čtyřech (4) vyhotoveních s platností originálu, Z nichž
Objednatel obdrží tři (3) a Poskytovatel jedno (1) vyhotovení.
Nedílnou Součástí této smlouvy je následující příloha:
Příloha č. 1: Cenová tabulka
Příloha č. 2: Kontrolní list smlouvy dle vyhl. č. 82/2018 Sb., O kybemetické bezpečnosti
(VOKB)
13/ 15
Evidenční Č. Smlouvy Objednatele: S-263-030/ 2019
Č. in 1/2019-030-SML/1
Příloha č. 3: Architektonické principy Ministerstva dopravy
Příloha č. 4: Pravidla pro provozovatele IS (BPI-O4)
V Praze, dne......flfl.'.lU.' Z019 V Praze, dne .... .7.ÍÍ'9
14/15
Evidenční Č. Smlouvy Objednatele: S-263-030/2019
Č. in 1/2019-030-SML/1
/ PrVíloha V 1 Smlouvy
c.
Cenová tabulka
Položka Cena Počet Cena Výše Cena v Kč
v Kč bez Jednotka v Kč bez
DPH včetně DPH za
DPH za jednotek DPH za
21% v celkový počet
jednotku celkový jednotek
počet Kč
jednotek
I. Aktualizace 1.350,- 1 hodina 120 162.000,- 34.020, - 196.020,-
Systému DOK
II. Technická 1-300; 1 měsíc 48 86-400,- 18.144 104.544,-
podpora provozu 248.400,- 52.164, - 300.564,-
Systému DOK
CELKEM
15 / 15
Příloha č 2 k č.j.: 1/2019-030-SML/1
Kontrolní list smlouvy dle vyhl. č. 82/2018 Sb., o kybernetické bezpečnosti (VOKB)
DOK Smlouva o poskytování služeb „Aktualizace systému a poskytnutí technické p0dpory“,
ev. č. S-263-030/2019
Smlouva dle VOKB obsahuje tato ustanovení:
0 bezpečnost informací - čl. XII, odst. 1 - osobní a citlivé údaje, čl. XIII. - GDPR,
přílohou smlouvy jsou Pravidla pro provozovatele IS (BPI-04), Architektonické
principy Ministerstva dopravy,
0 oprávnění užívat data - čl. XII, odst. 4- Další ujednání
0 O autorství kódu a licencích ~ čl. XII, odst. 3 a 4, čl. XII, odst. 4
0 O kontrole a auditu dodavatele - čl. VIII- realizační tým, čl. XIII, odst. 2, písm. j)
MD MD 0 o pravidlech případného řetězení dodavatelů (zachování povinností) - čl. VIII, odst. 11
0 O povinnosti dodržovat BPI a Architektonické principy - tyto dokumenty jsou
přílohou smlouvy v aktuálním znění
0 o řízení změn - čl. IV - schválení poskytnutých služeb, čl. VIII - povinnosti a práva
poskytovatele, čl. IX - povinnosti a práva objednatele
0 o souládu Smlouvy S právními předpisy - čl. V, odst. 3, čl. VIII, odst. 9 a 10, čl. XII. odst.
5 - sledování a realizace legislativních změn, Přílohy č. 3 a č. 4
0 o povinnosti dodavatele/provozovatele řídit incidenty, řídit rizika a informovat - čl. VIII
- povinnosti a práva poskytovatele, čl. IX - povinnosti a práva objednatele
0 o významných změnách na straně dodavatele/provozovatele - čl. III - doba, místo a
způsob plnění, čl. VII - odpovědné osoby
0 o ošetření případného ukončení smlouvy Z pohledu bezpečnosti informací (exit plán) - čl.
XII “ další ujednání
0 o řízení kontinuity (havarijní plány) - obsaženo v Pravidlech pro provozovatele IS
a Architektonických principech Ministerstva dopravy
0 o specifikaci formátů dat a provozních informací pro předávání správci (kontinuální
i na vyžádání) - čl. III, odst. 1, 5 a 6, čl. IV, odst. 2, čl. IX, odst. 6, technická data podle
Pravidel pro provozovatele IS
0 o pravidlech pro likvidaci dat ~ čl. XII, odst. 1, 2 - další ujednání, čl. XIII, odst. 2, písm.
m), čl. XIV, odst. 4
0 o právu jednostranně odstoupit od smlouvy (zejména V případě významné změny kontroly
nad dodavatelem, resp. nad jeho základními aktivy) - čl. XI, odst. 1, 2, 3 a 4
X 0 o sankcích za porušení povinností - čl. VIII, odst. 12, čl. - smluvní pokuta, úrok
Z prodlení, čl. XI, odst. 5
n
Datum:
Podpis:
ČESKÁ Nar.ı„zenı, na, mevstka „mm „č„,„„S„
REPUBLIKA
MINISTERSTVO Sekce legislativně právní 22 l 2019
DOPRAVY
ˇV
cn
Architektonické principy Ministerstva dopravy
Vydáno náměstkem Sekce legislativně právní
dne 22.1. 2019
č. j. 1/2019-330-RDK/l
ČESKÁ Nařízení náměstka „mm ,.,č„,„„„„
REPUBLIKA Sekce legı, slat,ıvne_, pra,vnı,
MINISTERSTVO 22 ' 1 ˇ 2019
DOPRAVY °ˇ. SRKB/1
OBSAH
Článek l Seznam Použité Zkratky a příloh 3 .................................................................................. ..
Článek 2
Článek 3 Působnost 4 ..................................................................................................................... ..
MD Architektonické principy pro dodavatele/ provozovatele informačních systémů 4 ,_
Článek 4 Architektonické principy pro provozovatele infrastruktury ......................................... _. 7
Článek 5 Architektonické principy pro dodavatele/provozovatele HelpDesku 9 .......................... ..
Článek 6 výjimky 0 ....................................................................................................................... _.
Článek 7 Změny MD infonnačnich systémů .............................................................................. ..9
Í Přechodná ustanovení 10 ................................................................................................ _.
Článek 8
Článek 9 Revize 10 nařízení .......................................................................................................... ..
Článek l0 Zrušovací ustanovení 10 ................................................................................................. _.
Článek l l Účinnost IO ..................................................................................................................... _.
Příloha Č. l - Dokumentace vjednotlivých fázích projektů. ll
2/l4
ČLÁNEK ı POUŽITÉ ZKRATKY A SEZNAM PRV Iı LOH
l.l Použité Zkratky/pojmy
Zkratka Význam
MD °
MD ` BPI
Mv Ministerstvo dopravy Ceské republiky
KB Bezpečnostní politika infonnací Ministerstva dopravy
Ministerstvo vnitra České republiky
Kybemetická bezpečnost \
MV MV L
OHA
J
Odbor hlavního architekta
J
IS Informační systém
RFC Request For Comments, tj. žádost o komentáře
VLAN Virtuální lokální počítačová síť
í
HelpDesk Kontaktní místo pro uživatele IS MD, určené pro předávání infonnací
O incidentech, požadavcích na úpravy IS a podobně
` NDA
j Dohoda o mlcenlivosti
vendor Situace, kdy je Zákazník závislý na určitém dodavateli nebo
dodavatelích a nemůže přejít k jiným dodavatelům nebo využívat jiný
lock produkt bez Značných nákladů na tuto Změnu at` již Zprávních
či technických důvodů
IPS p „SYStem Pro detekcia Prevenci Průniku
SIEM , Rízení bezpečnostních infonnací a událostí
Právní Jedná se zejména o zákon č. 365/2000 Sb. ve Znění prováděcích
předpisy předpisů, Zákon č. 181/2014 Sb. ve Znění prováděcích předpisů, zákon
WSDL č. 250/2017 Sb. ve Znění prováděcích předpisů, nařízení GDPR aj.
J
HTTP
Popis rozhraní webové služby
í
i Hypertextovzpřenosový protokol
trace Metoda protokolu HTTP
TCP Transportní vrstva internetového protokolu
UDPS P
Uživatelský datagramový protokol
firewall Část počítačové sítě, která Zvýšuje bezpečnost síťového provozu
IP Intemetovýprotokol
_ j
IPv4, IPv6
Vylepšené verze intemetového protokolu lP
URL
Adresa určující umístění prostředku/dokumentu na ıntemetu
proxy
Počítačové zaříZení,lkteré slouží k propojení webového prohlížeče
server aintemetu
Hyper-V Označení pro jednu Z technik virtualizace hardwaru počítače/Serveru
VMware Produkt, který Zajišťuje virtualizací jednoho nebo více počítáčů
SLA na jednom hostitelském počítači
j
Dohoda o úrovni Služeb
VLAN Virtuální místní počítačová síť, Slouží k logickćmu rozdělení počítačové
CMDB sít č
I
Konfigurační databáze, úložiště dat používané pro Záznam atributů
konfiguračních položek provozního prostředí a vztahů mezi
konfiguračními položkami po celou dobu jgjich životního cyklu
3/l4
l.2 Seznam příloh
íslo Název
l Dokumentace v jednotlivých fázích projektu
MV Architektonické principy
2 k I9. l I. 2015 (jedná se O odkaz, není fyzicky
řílohou)
MD Bezpečnostní politika infomıací
3 včetně příloh (jedná se o odkaz, není
fyzickıpřílohou)
ČLÁNEK 2 PÚSOBNOST
2.1 Toto nařízení je vydáváno v souladu S Článkem IO Služebního předpisu č. I8 státního
tajemníka Ministerstva dopravy Ze dne 20. prosince 2018 Organizační řád.
2.2 Tyto architektonické principy navazují na požadavky vyplývající Z právních předpisů
MD ana architektonické principy stanovované MV. Jsou závazné pro zadavatele
a dodavatele IS MD, a to jak IS tvořených pro zcela na klíč (např. Registr silničních
MD vozidel, Centrální registr řidičů aj.). tak těch částí IS, které se specificky pro
vytvářejí nad obecně vytvořenými a více uživateli Sdílenými částmi IS (např.
ekonomický systém, personální Systém aj.). Při výběru IS, které jsou upravovány
MD pro potřeby
doplňováním speciálně napsaných částí. by Architektonické principy
MD měly být rovněž Zohledňovány vmíře ekonomicky odůvodnitelné; článek 6
se uplatní obdobně.
2.3 MD Tvorba a provoz IS musí vycházet Z právních předpisů, přijaté informační koncepce
MD MD MD a BPI
(resp. jejich relevantních částí). Obecné principy IS jsou převzaty
Z požadavků MV, a to jsou:
0 dostupnost,
0 použitelnost,
důvěryhodnost,
transparentnost,
bezpečnost,
spolupráce a sdílení,
udržitelnost,
technologická neutralita,
MV integrita (tzn. provoz systému garantuje integritu dat; není však uváděn ve výše
citovaných požadavcích k datu vydání tohoto dokumentu).
2.4 Podrobnosti/výklad lze nalézt na stránkách www.mvcr.cz'. Architektonické principy
MV požadované
k 19. I I. 20l 5 jsou pro uvedeny v příloze. vždyje však nutno pracovat
MV S aktuální verzí publikovanou
na webových stránkách.
ČLÁNEK 3 APRRCOHVIOTZEOKVTAOTNEILCEKÉINPFROıNRcMıAPC_YNIıfCııHo DoDAyATELE/
MD 3.1 Dodavatelé IS SYSTÉMŮ MD
jsou povinni se řídit následujícími architektoníckými principy.
3.2 Architektonické principy pro tvorbu IS
' Konkrétní odkaz v době tvorby tohoto dokumentu: http://www.mvcr.cz/Soubor./architektonicke-principy-vs-
cr.aspx
4/I4
Využívat výlučně architekturu „tenkého klienta“, tj. navrhovat a realizovat IS
výhradně tak, aby na straně pracovni stanice uživatele nebylo nutno instalovat žádný
pro IS speciálně vytvořený software (preferovaným klientem je Standardní webový
prohlížeč).
Využivat důsledně vrstvené architektury, tzn. například při komunikaci
S operačním systémem nebo databází lze využívat pouze standardizovaných rozhrani
a standardní komunikační protokoly dle RFC.
Dokumentace IS musí být komplexní a úplná a musí umožnit instalaci
a konfiguraci IS třetí stranou.
IS nesmi vyžadovat pro svůj provoz administrátorská práva k produkčnímu
prostředí serverů a dalšího hardware, virtualizační platfonrıy. operačních systémů
a databází; datový model nesmí být dynamicky měněn.
Plně oddělit kód IS a data IS, tj. v kódu IS nesmí být žádné uživatelsky definované
konstanty/parametry, odkazy na extemí Zdroje (např. důvěryhodné certifikační
autority) atp. Veškeré možnosti změny nastavení musí být realizovatelné
konfiguračně (S autentizaci, autorizaci i logováním) bez potřeby zásahu do kódu IS.
Použití jen tzv. uzavřených číselníků/roletek (položka "ostatní" jen
v odůvodněných případech), tzn. koncový uživatel nesmi mít možnost „volně“ tvořit
obsah číselníků. Jedná se především O číselníky/roletky, které umožňují vkládat data.
podle kterých se následně třídí, vybírají nebo páruji infomıace. Změna (doplnění.
odmazání apod.) číselníků musí být realizovatelná konfiguračně (S autentizaci,
autorizaci i logováním) bez potřeby zásahu do kódu IS; ideálně jako samostatně
přidělitelné oprávnění či role v IS (Supenıživatel).
Zdrojový kód IS musí obsahovat komentáře v relaci s programátorskou
dokumentací minimálně ke každé použité funkci/proceduře/třídě/komponentě
na takove' úrovni, která umožní orientaci, porozumění kódu a jeho úpravy
programátorům. kteří Se na vývoji IS nepodíleli.
V průběhu přípravy tvorby resp. Změny IS bude vytvořen a ze strany Objednatele
(věcný odbor MD) schválen procesní model fungování zamýšleného IS resp. části IS
po změně, který bude obsahovat minimálně popis případů použití, rámcový návrh
obrazovek (wireframe) a logický datový model. Procesní model musí být schválen
Objednatelem ještě před zahájením programování.
Data musí být ukládána výhradně v databázích (případně do filesystćmu) ve struktuře
odpovídající datovému modelu a musí být možne' jednotlivé datové položky vyhledat
a přečíst prostředky databáze (resp. operačního Systému). tj. bez nutnosti použít
vlastni IS. Přímý přístup do databáze (resp. k filesystému S daty) smí být povolen
administrátorovi pro každý jednotlivý případ na základě schválení Manažerem KB.
Komunikace S jinými IS musi být realizována pomocí webových Služeb n_(web
services) S popisem funkcí, vstupů a výstupů v jazyce WSDL. '
Pro komunikaci přes HTTP smí být povoleny pouze nezbytné HTTP metody.
Povolené nevyužité metody (např. zapnutí trace) představuji zranitelnost a mohou
způsobovat nežádoucí účinky (např. při útoku na Server) a proto jejich použití musi
být omezeno. IS musí splňovat RFC a další definované standardy (např. vyplnění
hlaviček včetně flagů, nastavení cookies apod.)
IS smí k síťové komunikaci využívat pouze statických portů (na serverové Straně)
TCP nebo UDP portů (dynamické porty na straně Serveru neumožňují
nakonfigurovat firewall). K Síťové komunikaci je možné použít IPv4 i IPv6 (obě
altemativy bez nutnosti zásahu do IS).
m) IS musí umožňovat komunikaci S uživateli přes proxy server.
5/I4
_ -V7
n) bdKeorzykpnótudotgunroIsaStí.iiZcpkmréěognpraraomksortyvřpáetndokígyrvapíIoSi.ucžkíývchanaélgoIrSitmmuůs,ífubnýktcíkaondfiégleukrokvlaíčtůelmnuésíbbeýzt
3.3 Architektonické principy pro provoz IS zásahu
možná
dc))ba))mMvZInavuaUsnIenSejsesSpišarLíptoškgvaomAtteeebluěuřrrýmožnes(éetvíiebvícátnčndhčnýpetéeábycrtp,sýfhntokotsiiěvrodmn,teommíovelzHpovcyekuboáhžathyýnnsneonptaereyodeéélnpnmrpdotooa-ovognyucnVsasie,zoarttcjaeviguuksaaapepýoVpknncmyculMotoíheinmwsackněntpaahktčeiočro)paznmnem.rsbíeIe.opoytSnvoSrvtoitánnWakzyée,)oonř,nvketpveankšrztaejtpobnesríyproonjrýtsuaetopnjjřrvéefieúocypdmdsvhzíroaroiuoxžzcnfčbinekpáuumíjýrsncsácotgIhohílvoSuonvszsíaáimu,ennllZrmcísovomiopžeduěžrer(evnnáennnyovcetyéujhůvoszméajodpaíuerrřřdnoíeooadjzivheeoonlovnvfdseizíésitrdutna(tkrolpuIIóaoáaSvSd.ltvn.áyncáěn)íhnno.cyyh
3.4 Architektonické principy pro bezpečnost IS
j)ih) )gk)IvpínioSU)Aří(eIemnddnrcivnrc)SObúaIo)fnfio)chamese)pdlv)SvsoeIplhhglnbuopnaomůrěkyřpzSsársiePuleedsrskháloahUu.řIpešzěřtmvrirtdIzaoIásemírnvSžxermuriaecšaoráSoopnSvžopeonáioaínijkooacnzyoevtkvmicnbibtczdřtndžtemmžežuérhčožmatieouanýoynoíaíeuáuomnhenrlýtdnu(ptéívvsnbmlalnilsocooíinnfeřyáIksaKríeuýotnahsýžcuístíSdolnýrízapjBmpphetíomepoíornnunmřozeřnpaodln)av.uIhpumeaáímmu.vzřrčaoSčukínSasloarčsavú.oojmáamídmvtacmýujttetuznIcaeskneažsnreooasiohcund(uslSšnnaeštstpižjnnsíedzžhpýar8edisepuakntuputteiěiruutkaorn1ižnoleípiuétnržkoišrbtijtioezoílš/jzrz/ééioroolntepsnnelhppijmaíee2énZvizrptýmzřefřtkřnosvcbínmae0amaařnsdi.iecrouiéidmyesmetpísdskai1tůk.agdovhrhínsšnlízohuynl4eoehzcllřmniusktlnpvlivt',eolsamuáhceaáutaieémáátedežÚkSeůdzpšjlá,nvužclštínamrčkpinubraemeıázínocisoetíínyétnttl.ppnoocn,enegvv,takAée.oiižveínrvíunavavíjveuščrurzsvkekleá.)tomiěteípeeécnatsetIómon,aršcevncšecmmnchňcSiěéůIíádgulkbcháktseíínezihehSlneooseeeledhyeynttzn((onioSIúvovkrerémíonběeooairiížkpShdhháááýhílanknojponvoeZrarnoocjdnpteíu(aztvolcájaojopvvívřehúoížrakdehiieýdžřenžmčypýeidUmeséhomofvireceuevvssržollnspkpoíldsiKuh(RneanthsetooáovoohěrclnatedvístBdvíntugLvdvtléčásakušlčabe.duyavěuh)půiišályádéktelnnyyonllpontemidrznečyítanétodvénáfníuumev.ětviíooOntdsnehuíuušoýídsfonýcekěeooíbAdn.nož.edzcynažmoísd)vrd)írkiuSssanoh,oUtinlkn.cnpcacvoyátíylbsuanřotehuRIhiamtsaúcbptcrsiuúHtvsmoSs,otbtiodtLřihaěetdlstpyeokttríeaaéžidz,pkaténřaálšejisdohmzžnmiořtmjieřnmšášůnkel)pvpuáýneiuedíciokůO,tíáe.uoeonerhvd)zlposnvcbašapžmpěláeuežčiyn.okodyetdíeiihooiánssknéaéhřocvnnramrvíyšKsatůieláaúdosíIužímDhmeuáoubt.eaBmtúčkStiedtaůotunyíllzseynpdtíeun)lslenícuvnbínlu,naldeSntctanheopkiiyjejvcataěiti(žZnrHcmvneuhitsdeksbri.pihoěům,mýo,zeětntzůdTaoičotkbvzasrnuaoévusmnnžnatcéjorkTratcctntpsžáTaiřsaetelinaiůBionouonPaínhneeeIr.i.nzoePpzíuto(bímroiSkkýzuhkIcbbsnihéonvsocájáordýýhúaslapé(ytamsshkeúroMttprtbarohttvluyeúřsžvaodvyDo,sdruto.akudvnsepuyoviozZeala.luždžtanditěžnkčmnthabeSk.iiěansjltííakéšeaokoIaovdveínůitidknampdáZavanhrEošáalaaoýrcynzttáásaílnhyManjjneâveodcuai,htmjáriyea)llaattohdtmoibsěopíilat..ítnřvtnvycéž)baraýeěbíeéí.hýetkjnzeycn.ítnyěemcéíhm
I
t
›
-.
6/I4
pro různé kategorie (kombinace rolí) uživatelů (např. editor a čtenář). IS Odhlásí
uživatele po určité době nečinnosti. Tato doba je konfigurovatelná a pro důležité IS
(rozhodnutí Architekta KB) může být odlišná pro různé kategorie (kombinace rolí)
uživatelů.
Autorizace, povolující uživateli oprávnění k operacím, se provádí vůči jeho roli v IS.
IS provádí autorizační omezení přístupu uživatele při každém provádění jakékoli
operace či Skupiny operací. Pravidlo se neaplikuje na veřejně přístupné operace. kde
není potřeba oprávnění k přístupu na operace rozlišovat.
Architektonické principy pro dokumentaci a eliminaci „vendor lock“
MD IS je/bude implementován do prostředí (operační Systémy, databázové Stroje,
autentízační mechanismy apod.), které je již dominantně využíváno.
Dodavatel pro vývoj a provoz využije pouze prostředky, které mají zajištěnu
dlouhodobou podporu výrobce spolu S perspektivou rozvoje produktu výrobcem.
Testovací a provozní prostředí IS (hardware, software) schvaluje (resp. definuje)
MD Objednatel. Schválení Objednatele podléhá i jakékoliv další prostředí (včetně
vývojového), pokud se v něm vyskytují data (včetně dat anonymizovaných
či pseudonymizovaných).
OHA MV Dokumentace musí být zpracována podle právních předpisů, pravidel
MD (viz webové stránky www.mvcr.cZ) a intemích požadavků
na dokumentaci,
které jsou uvedeny v Přiloze č. I tohoto nařízení.
Dokumentace musi obsahovat minimálně:
0 datový model,
0 uživatelskou dokumentaci (včetně školicí), i
I
0 programátorskou dokumentaci,
okomentovaný kompletní Zdrojový kód IS,
administrátorskou dokumentaci včetně instalačního manuálu,
extemí knihovny, resp. kódy třetích stran, nezbytné k funkčnímu Sestavení IS,
skripty pro sestavení IS (jsou-li použity),
0 bezpečnostní dokumentaci včetně havarijních plánů a plánů obnovy,
0 hesla a šifrovací klíče (jsou-li použity),
0 Roll-aut plán/Exit strategii,
0 provozní deník.
IS musí obsahovat uživatelskou dokumentaci on-line dostupnou na obrazovkách.
IS musí obsahovat tzv. „info-proužek“ umožňující Z centrálního pracoviště
provozovatele IS informovat uživatele stručným sdělením v průběhu užívání IS, aniž
by činnost uživatelů tímto sdělcním přerušovala.
.Ă
Součástí dodávky a jeji ceny musí být komplexní licenční, resp. další práva k užívání
a úpravám dodaných kódů a dokumentací k časově a teritoriálně neomezenému užití
(včetně možnosti postoupit je pro účely úprav a rozvoje třetím stranáın). Tato práva
se musejí týkat i rozvoje dodaného IS.
ČLÁNEK 4 ARCHITEKTONICKÉ PRINCIPY
PRO PROVOZOVATELE INFRASTRUKTURY
Architektonické principy pro vývojové, testovací a provozní prostrvedi
I
a) Využívat preferovaně dedikované (privátní) cloudy fyzicky umístěné v ČR.
b) Oddělené Zdroje a monitoring jednotlivých provozovaných IS (alespoň vırtuálně).
c) Oddčlená Správa/administrace zdrojů a monitoringu jednotlivých provozovaných IS. =
I
7/I4
_' DN* 'ˇ ' ˇ"
d) Dodavatel/provozovatel využije pouze prostředky, které mají zajištěnu dlouhodobou
podporu výrobce spolu S perspektivou rozvoje produktu výrobcem.
e) Dodavatel/provozovatel realizuje prostředí na škálovatelných produktech S možností
flexibilni a bezpečné změny (tj. bez nutnosti reinstalace IS, realizovatelné
v definovaných maintenance oknech apod.).
Í) Testovací a provozní prostředí (hardware, Software) schvaluje (resp. definuje)
MD Objednatel. Schválení Objednatele podléhá i jakékoliv další prostředí (včetně
vývojového), pokud se vněm vyskytují data (včetně dat anonymizovaných
či pseudonymizovaných).
g) Testovací a produkční (a všechna další) prostředí musí být oddělena minimálně
na úrovni (virtuálních) serverů i sítě (VLAN, IP).
4.2 Architektonické principy pro provoz infrastruktury
H
a) Dodavatel musí udržovat aktuální CMDB.
b) U použitých standardních technologických komponent jsou v maximální možné míře
odstraněny veškeré částí, které nejsou nezbytné pro jejich fungování (nejsou
instalovány nepotřebné komponenty, aplikační SW. vprostředí nejsou uloženy
zdrojové kódy). Smí být instalovány pouze komponenty nezbytné pro provoz, správu
a dohledy IS/infrastruktury.
c) Zajištění provozu a dostupnosti infrastruktury a řešení provozních incidentů je
definováno v SLA (včetně vyhodnocovacích metrik), který je Součástí smlouvy
' O provozu prostředí.
d) Musí být definovány' postupy a časová okna pro údržbu prostředí a změnové řízení
(Patch Management. Release Management).
4.3 Architektonické principy pro dokumentaci infrastruktury
OHA MV a) Dokumentace musí být zpracována podle právních předpisů, pravidel
MD (viz webové stránky www.mvcr.cZ) a intemich požadavků
na dokumentaci,
které jsou uvedeny v Příloze č. l tohoto nařízení.
b) Dokumentace musí obsahovat minimálně:
0 datový model včetně popisu umístění dat,
0 administrátorskou dokumentaci včetně instalačního manuálu,
bezpečnostní dokumentaci včetně havarijních plánů a plánů obnovy,
HW SW Seznam a popis
a prvků včetně popisu/schématu jejich propojení,
HW konfiguraci a typ použitého
a SW,
hesla a šifrovací klíče (jsou-li použity),
infomıace o licenčních pravidlech použitého SW,
Roll-aut plán/Exit strategii,
provozní deník. \`
4.4 Architektonické principy pro bezpečnost infrastruktury
a) Infrastruktura musi dodržet/naplnit všechna (relevantní) ustanovení platné BPI MD.
b) Infrastruktura musí Zajistit veškeré Iogování své činnosti minimálně vrozsahu
stanoveném Zákonem č. 181/2014 Sb. ve Znění prováděcích předpisů.
c) Prvky infrastruktury musí umožnit Zasílání logů do systémů třetích stran (např.
SIEM).
d) Umožnit monitoring chování infrastruktury a provozovaných lS včetně možnosti
vyhodnocování systémy' třetích stran (např. napojení na centrální dohledový Systém).
8/14
I
e) Zálohy dat jsou ukládány jinde než na produkčním Serveru a pro důležité IS
(rozhodnutí Architekta KB) i v jiné lokalitě. Funkčnost obnovy ze záloh musí být
pravidelně kontrolována/ověřována.
f) Záznamy O provozu (logy) jsou ukládány pro důležité IS (rozhodnutí Architekta KB)
na jiném Serveru / Zařízení S vlastnim operačním systémem, než na kterém jsou
Záznamy vytvářeny.
MD g) Testovací, provozní i jakékoliv další prostředí (včetně vývojového), pokud se v něm
vyskytují data (včetně dat anonymizovaných či pseudonymizovaných), musí být
od veřejných i jiných (včetně prostředí pro provoz jiných IS) datových sítí odděleno
minimálně jedním firewallem dozorováno IPS.
ČLÁNEK 5 ARCHITEKTONICKÉ PRINCIPY
PRO DODAVATELE/PROVOZOVATELE HELPDESKU
5.1 Architektonické principy pro integrace HelpDeSku
MD a) Pro podporu uživatelů musí mít každý IS implementován HelpDesk, který zajistí
podporu a evidenci průběhu řešení požadavků uživatelů a incidentů v rámci LI
(Základní úroveň podpory), L2 (úroveň S hlubší technickou znalostí systému) a L3
(expertní Znalost systému) podpory. Vrámcí implementace IS je nutné přesně
stanovit, kdo bude zajišt`ovat jednotlivé úrovně podpory, jak budou tyto úrovně
spolupracovat a jak bude měřena doba řešení.
b) HelpDesk musí podporovat měření kvality dodavatelem poskytovaných Služeb
(SLA), včetně reportovacích nástrojů.
MD c) Pokud se tak
Sdodavatelem dohodne, může dodavatel provozovat vlastní
MD HelpDesk stím. že do centrálního HelpDesku
musejí být zasílány veškeré
incidenty a informace, které mají vazbu na výše uvedené měření kvality Služeb
a reportování míry dodržování dohodnutých parametrů kvality služeb (SLA).
5.2 Architektonické principy pro dokumentaci HelpDeSku
a) Dokumentace HelpDeSku musí splňovat všechny požadavky na IS provozované
na MD.
b) Dokumentace provozu/činnosti HelpDeSku (může být realizováno např. funkčností
aplikace IlelpDeSku) musí obsahovat úplný průběh řešení požadavku včetně
časových záznamů.
ČLÁNEK 6 VÝJIMKY
6.1 Dodavatel může žádat o výjimky Z těchto Architektonických principů MD. Výjimky
musí dodavatel písemně zdůvodnit (včetně doby trvání výjimky). předložit a požádat
o stanoviska Manažera a Architekta KB na odboru ICT (0330). O povolení výjimky,
MD resp. O podmínkách, Za kterých je výjimku možno akceptovat, rozhoduje ředitel Odboru
ICT (0330) na základě výše uvedených stanovisek.
6.2 V případě žádosti O výjimku zustanovení odkazovaných dokumentů je nutné žádat
MD dle jimi definovaných procesů a o podání takove' žádosti infonnovat ředitele Odboru ICT
(0330).
ČLÁNEK 7 ZMĚNY INFORMAČNÍCH SYSTÉMŮ MD
MD OHA 7.1 Pokud Dodavatel předkládá
návrh na změnu IS, která podléhá Schválení MV,
musí si předem vyžádat stanovisko Manažera KB MD.
9/14
Ťì
7.2 Manažer KB si může po realizaci vyžádat doložení
překážkou V akceptaci,
podmínek může být Splnění podmínek; nesplnění těchto
resp.
dodávky/řešení. důvodem k neakceptaci
ČLÁNEK 8 PŘECHODNÁ USTÁNOVENÍ
8.1 MD jSpkAiořrouipcmčmoháěpuisřlžtteieeintxkovtnsršutěoerivc.apnhoěujžPaez,rkeocahSevvltpšátapašanřkečoínnvpSííoacpdvhrOěáonZpıasrántosiatjatvodanukunkotíolipzůml.dmnlvěěonýnuíjyhiomaIderSo.ckbhPáipot,lkeykunctodíoulnbcoiviucácdk.hoýucZPhrpporrpoirnviScátniádcpviěuapnjůyífciíúnvpašrnaIačSkvnyí,maujsečíansupoltbavýnttééí
ČLÁNEK 9 REVIZE NAŘÍZENÍ
9.1 Revize naıˇízeni se provádí povimě v těchto případech:
BVyrlráázmmjcciišitřěaenkštneuenaísloiiuznlacacidededSnotpšuolžobaykldeaivzdkemynětnifáìmkovváMBnVPn.IedMoDst.atek
OHA V a) v oblasti
upraveny
b)
c)
9.2 Vpřípadě, že jsou činnosti uvedenć v tomto architektury IS MD.
předpisem, postupuje se podle tohoto předpisu.
nařízení Zvláštním právním
ČLÁNEK 10 ZRUŠOVACÍ USTÁNOVENÍ
10.] Zrušuje se Nařízení ředitele odboru ICT č.j. 1/2018-330~RDK/l
dopravy“.
„Architektonické principy Ministerstva ze dne 21. prosince 2018
ČLÁNEK ıı ÚČINNOST
1 l.l Toto nařízení nabývá účinnosti dnem 22.
\
10/14
Příloha č. l - Dokumentace v jednotlivych fázích projektů
Dokumentace v jednotliıých fázích projektů
Tento dokument je Součástí metodiky řízení projektů, protože tvorba dokumentace probíhá
postupně v rámci životního cyklu projektu. Níže je pak popsáno, který dokument by měl v jaké
etapě projektu vzniknout a co by mělo být jeho obsahem.
I. etapa (návrh):
Projektové dokumenty podle rozhodnutí vedoucího projektu nebo zvoleného standardu
(např. Základní dokument projektu, Plán
Katalog rizik, Změnové požadavky) projektu, Metodika vedení projektu, Zápisy,
II. etapa (vývoj):
Školicí příručka, Uživatelská příručka, Instalační příručka, Administrátorské příručka.
Systémová dokumentace a Vývojová dokumentace.
Ill. etapa (Pilotní provoz):
Provozní dokumentace (katalogové listy, Způsob Zajištění provozní podpory. Způsob
Zajištění podpory uživatelů, Způsob měření SLA, provozní deník), projektové dokumenty
(především pak Zápisy a Změnové požadavky, které
vzniknou v rámci Pilotního provozu),
Závěrečná zpráva/Vyhodnocení Pilotního provozu.
IV. etapa (příprava produkčního provozu):
Aktualizace provozní dokumentace a veškerých dokumentů vnávaznosti na Změny.
provedené v průběhu Pilotního provozu.
V. etapa (podpora nebo zajištění produkčního provozu):
Aktualizace veškerých dokumentů v návaznosti na změny, provedené
v průběhu laděním/optimalizace Systému).
Poznámky:
l. Projektové dokumenty (Základní dokument projektu, Prováděcí projekt, Závěrečná
Zpráva/Vyhodnocení Pilotního provozu) Se řídí pravidly projektového řízení.
požadované dokumenty musejí Veškeré
nebo explicitně ve Smlouvě. být smluvně zajištěny buď odkazem na příslušný
Standard,
2. Všechny požadované dokumenty je nutné zahrnout explicitně do smlouvy (stačí odkaz
na standard, pokud existuje) a případně v ní ještě detailnějí upřesnit obsahovou
Stránku.
MD 3.
Bezpečnostní dokumentace vychází ZBPI a může být Součástí (jednou Zkapítol)
Administrátorské příručky - viz výše. Manažer KB.
Schvaluje ji
ll/14
r ___ __Ň,_
4. Upřesnění kdokumentům, jejichž obsahová stránka není podrobněji specifikována
v Release Managemenfu:
Šıxøıiapfúnčıxn (øápøviáá áøánvøıøı)
Slouží pro provádění školení „běžných“ uživatelů, klíčových uživatelů a administrátorů.
Uživatelská příručka (odpovídá dodavatel)
Obsahuje návod práce se systémem, včetně popisu scénářů použití (jak co udělám), menu.
obrazovek, chybových
stavů.
Instalační příručka (odpovídá dodavatel)
Je rozdělena do několika oblastí, přičemž odkazy mezi jednotlí\ými dokumenty jsou
případně prováděny v části prerekvizíty instalace:
1) databáze
a. popis instalačního baliku, jednoznačná identifikace. obsah
b. prerekvizíty instalace
ˇ
c. instalace
- postup instalace
- kontrola logů
- chybové Stavy
- adresářová/DB struktura instalace (kde se co po instalaci nachází)
2) aplikační vrstva (může být rozdělena do části: webové služby, tenký klient, workflow,
plánované úlohy, každá pak obsahuje níže uvedené části)
a. popis instalačního
pro instalaci balíku, jednoznačná identifikace, obsah, popis adresářů
b. prerekvizity instalace
- konfigurace bezpečnostních mechanismů (včetně hesel a Šifrovacích klíčů)
- konfigurace
Sítě
- další...
c. instalace
- postup instalace, kontrola logů. chybové stavy, adresářová „
(kde se co po instalaci nachází) struktura instalace
d. konfigurace
- popis konfiguračních souborů a významu parametrů včetně požadovaného
nastavení
e. konfigurace dohledu a monitoringu
3) klient
a. popis instalačního balíku, jednoznačná identifikace, co klient obsahuje, popis
adresářů pro instalaci
b. prerekvizity instalace
c. instalace
12/I4
- postup instalace, kontrola logů, chybové adresářová
(kde se co po instalaci nachází)
stavy, Struktura instalace
d. konfigurace
- popis konfiguračních souborů a významu parametrů
nastavení včetně požadovaného
Adminılvtrátorská příručka (odpovídá dodavatel)
Na jejím základě musí být administrátor schopen provádět veškeré činnosti, které jsou nutné
Zálohování. Zároveň musí obsahovat metodiku pro Zjištění, že je
pro řádný chod IS včetně oddělení projektového řízení.
IS nefiınkční. Akceptuje ji
I) obecné informace o fungování IS
2) databáze
a. Seznarrı a popis pravidelně prováděných činností
DB b. popis využití volání funkci
Stroje
c. popis bezpečnostních funkcí a způsobu jejich aplikace
d. popis log souborů a způsob jejich vyhodnocování
e. popis chybových stavů a jejich náprava
3) aplikační vrstva
a. Seznam a popis pravidelně prováděných čimıostí -
b. popis využití a volání systémových zdrojů
c. popis bezpečnostních funkcí a způsobu jejich aplikace
d. popis log souborů a Způsob jejich vyhodnocování
e. popis chybových stavů a jejich náprava
f. popis číselníků ajejich význam
4) klient
a. Seznam a popis pravidelně prováděných činností
b. popis bezpečnostních funkcí a způsobu jejich aplikace
c. popis log souborů a způsob jejich vyhodnocování
d. popis chybových stavů a jejich náprava.
Systémová dokumentace (odpovídá dodavatel)
amjSoOreebbochtssphoaoiarhdthzaoeiauvvkksjntayaeýotznmpejiionencípjkepiiýjdocsreshonntfiuIuvSppnpyyorghM.piooDnivdmcs.ánienoptí.„yclol.eesdonvygyísyi.ttkaévyıopZnřoáufesrunt(onaruvegpsZeoypeňv.jáŠjkmnmeáíéuhl“noosavijaIpeStrd,esonlponlaptoňlolseotitvřviaieýtbvcpyhýopkipmooniožtnsdaeudugrarlaoavůzckp)heoyrpv,aSičnjseídit,nalnýoněcgmévhisayaoIzbrSueo.cbbvhoPiýarrtcůoezhtkpvotůčuksmeróoutodunbs/ůěuí
Je určena zejména pro oddělení provozu, jehož vedouci ji také akceptuje:
logiky IS včetně návrhu začlenění do stávajícího systému
I) popis funkce a rozhraní
2) Seznam a popis
3) Seznam využívaných rozhraní jiných IS
4) popis toku a objemů dat
5) požadavky na Změny a nastaveni spolupracujících IS
I3/I4
Íì
6) lpmbříeeeczcdepháneavččnánninoísíspmtodůda;tm(ímrndeeekszfpyi.inmicobedeuzplroeylč,ín; o..s.p)t;onpoíicshrmabonedazeplkeočmn-uosntipnkoíapcieasr;chpaioutpteieksnttulirozygaočv(noíácdnhdíěalpeaondí.a)umtoodriuzlaůčníIcSh,
7)
Vývojová dokumentace (odpovídá dodavatel)
OHA Poskytuje veškeré potřebné podklady pro další rozvoj a údržbu systému. Musí proto
obsahovat popis architektury (v souladu S požadavky MV) a veškeré analytické
dokumenty, tedy:
l) popis stavových diagramů S datovými toky (event - flow diagram)
2) namapování aplikačních objektů na logický datový model
3) namapování logického datového modelu na fyzický datový model
4) podrobná programátorské dokumentace
požadavků architektury) (jednotnou formou komentovaného kódu podle
vš
`l Konkrétní rozsah Vývojové dokumentace
projektového řízení, které ji také akceptuje. může pro daný projekt upřesnit oddělení
Provozní dokumentace (odpovídají administrátoři _IS)
Dokumentuje průběh produkčního provozu, Specifická nastavení konkrétní implementace
a veškeré provozní zásahy, tedy:
HW l) Seznam a popis
prvků včetně popisu/schématu jejich propojení
SW 2) Seznam a popis prvků včetně popisu/schématu jejich propojení
HW 3) konfigurace a typ použitého
SW 4) konfigurace a verze použitého
(včetně informace O licenčních pravidlech)
5) popis rozmístění dat
6) dokumentace specifických nastavení (např. Zálohování, politik pro ıˇízení přístupu apod.)
7) provozní deník - dokumentace veškerých provozních
nastavení, instalace bezpečnostních i jiných oprav zásahů a úprav (např. Změny
či aplikační vrstvy) operačního Systému. databáze
8) dokumentace průběžně prováděných testů (např. test fimkčnosti záloh) v antiviru,
9) dokumentace změn v prostředí IS
dohledový Systém apod.) a podpůmých systémů (např. změny
10) havarijní plány a plány obnovy
I
l
14/14
l
Příloha č. 4
Pravidla pro provozovatele IS
X
'
OBSAH
ČÁST I. Úvodní ustanovení
Kapitola l pojmů Definice ............................ ..... .........
Kapitola 2
a zkratek .... .................... ............ ..4
ČÁST II.
Rozsah působnosti ........................................................................
Kapitola l
Kapitola 3 4 ..
Organizace bezpečnosti informací .......................................................................................................
.. 4
Role, odpovědnosti a pravomoci .... . . . . .. .. .
Oddělení povinností
. .......... .... ..
.....................................................................
_. ø..
Kapitola 4
Výjimky ustanovených Z
ČÁST III.
Hodnocenípodpůrných V r
ČAST informačních IV.
Kapitola 1
Q Kapitola 2
Kapitola 3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
ČÁST Kryptografická v.
................................................................................................. O'\Uı(/IÍCJI
pravidel ..
...............................................................................
..
Řizønı' aktiv........ . ..
přisınpn.................................. ..6
Požadavky na řízení přístupu ........... .... ..... ......... ...... .. É ..... ..
Řízení přístupu k síťovým službám ............................................................ O\
..
Správa a řízení přístupu uživatelů .................................................................. _. \1
..
Zřízení a zrušení uživatelského účtu............................................................................
Zřízení přístupu uživatele ..... ..
ORŘdíízpzeeonnvííědcphnrirovásintlěeungžýoicvvhaantaeýulctůhenptřií.z.s.a.tč.u.n.p.í.o.c.v.h.ý..ic..nh..f.po..rr..ám..av..c..í...u..ž..i.v..a..t..elů
Řízení přístupu k ................................................
Bezpečné postupy ©€\b\Ó\O\O%%%0O
systémům a aplikacím
přihlášení
ŘPíozužeintííppřríisvtiulpeugokveazndýcrhojoobvsélmu.u.ž.n..ký..óc..dh..u..p.p.r..ro..og..gr..ra..ammůu
.... ..
opatření .................................................................. _ı_ı
..
Kapitola l Generátory náhodných čísel .. ....... ..... ...... 10
Kapitola 2 SSpyrmeátvraickkleí'čůaalgcoerrittimfiykáAtsůymet.r..i..c..k..é...a..l..g.o..r..i.t..m..y...a...h..a.s..h..o..v..ací ......................................... _. l0
Kapitola 3 _.
funkce ll
ČÁST VI. .............................
Kapitola l Bezpečnost provozu.. ............................................................................................ .. ll
....
1.1
1.2 ŘDPíorzkoevunomízeznnmítěapnco.se..t.p.u.r.p.oyvoazondípcohvpěodsntousptůi ......... ............ .. ............... 11
1.3
1.4 .............................................................. .. ll
Kapitola 2 ........ ..
Kapitola 3
............
kódem Plánování kapacit ......... 11
................... .................... 12
Princip oddělení prostředí 12
Ochrana před škodlivým 13 . . . . . . . . . . . . . ..
vývoje, testování a provozu .............
Zálohování .......
........................................................ _. 13
Kapitola 4 Monitorování ...................................................................................
4.1 _. 14
4.2 záznamy Požadavky na .a.u..d.i..t.n..í............................................................................................... 14
4.3 Monitorování uživatelských ............. .. ..
4.4
4.5 DMZ Monitorování . 14 ........... ..
4.6 15
4.7 Monitorování
4.8 Monitorování nn 15
4.9 uživatelských stanic ............................ .....
standardních serverů a technologických
4.10 serverů v stanic............
4.11 „CHRANENE“ SLOMMMyocooonghnnncyiriihttatrooonoorrčrnaoiooinvavzvnuááaáodnncnsiííetítinbshsíaeíoecdzťrdhmpoviievenznčýráincůzsohZtsnpprtarránmatívůcockorhů.vů..zá......ava....ř.a....o.íj.....pz.í.....ee.c...n..rí....í.á.c....t.h.....o....r....ů............. øø 15
4.12 .................... 15
16
Kapitola 5 in1`ormace......... 16
16
5.1 ............... 16
5.2
...........................................
centrálního
SIEM MD provozem Součinnost s 17
Řízení a kontrola provozního .. .. .... . ........ ...... 17
Nasazení do provozu ......... 17
Provoz softwaru . . . . . . . . . . . . . . . . ..
l7
.................................................
..
. .... . . . . . ..
................................................................................................................................. 17
MD Příloha BPl č. 4: Pravidla pro provozovatele .. 18
2/27
5.3 Pravidelné kontroly 19 .................................................................................................................. ..
5.4 19 ................................................................................. ..
na Systémy Instalace softwaru provozní
Kapitola 6
Kapitola 7 Správa a řízení technických Zranitelností ..................................................................... _. I9
Audity 20 IS ...................................................................................................................... ..
ČÁST VII. Bezpečnost komunikací ....... ..... ...... ...... ................ ........ ....20
Kapitola l Správa bezpečnosti 20 sítě ................................................................................................ _.
1.1 Nastavení síťových prvků a jejich vzájemná komunikace ................................................... ..21
1.2 21
1.3 Změny v síťové infrastruktuře .........................................
1.4
Bezpečnost bezdrátových sítí .................. .......21
Kapitola 2
Internetová gateway pro uživatele .......... .. 22
2.1 MD Vzdálené přístupy do IS
......................... .. 22
23
Práce na dálku ................................................................................................................. ..
CAST VIII. Akvizice, vývoj a údržba systémů . ........ ....... ........... ........ ..... ..23
Kapitola 1 Bezpečnostní požadavky ........ 23 ................................... ..
1.1 Analýza a specifikace požadavků ............................. 23 .................................... ..
1.2
1.3 Zabezpečení aplikačních služeb ve veřejných sítích.......... 23
Kapitola 2 Ochrana 24 transakcí aplikačních služeb ................................................................................... ..
Kapitola 3 Bezpečnost v procesech vývoje a podpory .................................................................. .. 24
Data pro 25 testování ........................................................................................................ ._
ČÁST IX. Řízení incìdentů bezpečnosti informací... ....... ...... ............... .......
Kapitola l Odpovědnost postupy 25 a
Kapitola 2 .................................... .. .......................................................... ..
Kapitola 3
Kapitola 4 Podávání zpráv O incidentech bezpečnosti informací 25 ................................ ..
Kapitola 5
Podávání zpráv O zranitelnostech bezpečnosti informací ............................................ .. 26
Odezva na 26 incidenty bezpečnosti informací ................................................................. ..
Shromažďování důkazů 26 ............................................................................................... ._
ČÁST x. Řízení kontinuity činností ....... ............ ....... ....... ...... ..27
ČÁST X1. Soulad S požadavky ......... ............. ......................... ....... ........
ČÁST XII. Přechodná ustanovení ...... ........ ........ ..... .............. ....... ..... ..27
MD Příloha BPI č. 4: Pravidla pro provozovatele 3/27
ČÁST I. ÚVODNÍ USTANOVENÍ
Knpiıøın 1 DEFINICE POJMŮ A ZKRATEK
Administrátor: zaměstnanec pověřený provozovatelem IS správou a provozem svěřeného
informačního systému nebo zařízení ICT infrastruktury.
DMZ: demilitarizovaná Zóna (speciální typ počítačové sítě, která se využívá ke zvýšení
bezpečnosti komunikace S vnějším prostředím a plní roli firewallu).
MD HelpDesk: kontaktní místo pro všechny uživatele IS pro případ potíží nebo požadavků.
IDS: Intmsion Detection System (systém detekce průniků do IS).
MD Informační
hodnotu.
aktivum: jakákoli informace nebo prostředek pro práci S ní, který má pro nějakou
Informační systém (IS): informační infrastruktura, Soustava aplikací, organizačních opatření,
procedur a souvisejících služeb pro tvorbu, Získávání, Zpracování, ukládání a prezentaci informací.
Incident: jakákoli odchylka od popsaného stavu, resp. výpadek služby.
IPS: Intrusion Prevention System (systém prevence průniků do IS).
Bezpečnostní incident: událost v IS, která způsobila narušení důvěmosti, integrity, dostupnosti
nebo neodmítnutelnosti informace v důsledku selhání bezpečnostních opatření nebo porušení
bezpečnostní politiky.
OTP: jednorázové heslo (One Time Password).
Podpůrné informační aktivum: technické informační aktivum, zaměstnanci a dodavatelé,
podílející se na provozu, rozvoji, správě nebo bezpečnosti IS.
MD MD Provozovatel IS: subjekt,
a se stanovenou spolehlivostí
ICT).
Zajisvťující provoz daného IS tak, aby odpovídajícím způsobem
podporoval procesy intemích IS je Odbor
(provozovatelem
SIEM: (Security Information and Event Management) Systém pro automatickou korelaci
„podezřelých událostí“, jejich vyhodnocování a reporting.
Správce IS: vedoucí Zaměstnanec, který určuje účel Zpracování informací a podmínky
provozování IS.
tpTerecochghnrniaicmkcéokvéaápiionndffpooůrrmmmaéaččnsnílíuažkbatyik.vtaiv(upmř:edevfyšzíimckaápliiknačfnoírmaačdnaítabaáktziovvaý (především hardware ICT),
SW), telekomunikační a další
Vlastník (garant) informačního aktiva: vedoucí zaměstnanec, který odpovídá Za zajištění
rozvoje, použití a bezpečnosti informačního aktiva.
Kapitola 2 ROZSAH PŮSOBNOSTI
MD Tato příloha BPI
stanovuje Základní pravidla, Zásady a principy pro provozovatele (resp.
administrátorů a jejich Subjekty jsou Zavázány k plnění této přílohy
nadřízených) IS MD. Extemí
smluvně.
MD Příloha BPI č. 4: Pravidla pro provozovatele 4/27
ČÁST II. ORGANIZACE BEZPEČNOSTI INFORMACÍ
Knpiıøın 1 ROLE, oDPovÉDNoSTI A PRAVOMOCI
Řøfliıøı ođhønn ICT:
řídí dokumentaci infrastruktury ICT,
definuje pravidla pro evidenci informačních aktiv vrozsahu služeb. poskytovaných
Odborem ICT,
MD definuje pravidla pro dokumentaci služeb IS
včetně zálohování,
zajišťuje implementaci a monitorování bezpečnostních opatření vrozsahu služeb,
poskytovaných Odborem ICT,
řídí rizika služeb, poskytovaných Odborem ICT,
řídí technické zranitelností,
vede a průběžně aktualizuje Seznam bezpečnostních výjimek vsouladu Spožadavky
přílohy č.6 BPI MD.
MD Administrátor (není podstatné, zda se jedná o zaměstnance nebo extemího subjektu):
průběžně aktualizuje evidenci svěřených informačních aktiv v souladu S BPI MD,
zajišťuje zabezpečení všech svěřených infomıačních aktiv v souladu S BPI MD,
předchází vzniku bezpečnostních incidentů a problémů a aktivně postupuje
při oznamování, odhalování a likvidaci jejich následků,
Spolupracuje při analýzách rizik, hodnocení“ stavu informační bezpečnosti
a při bezpečnostních auditech,
spolupracuje při zavádění a realizaci bezpečnostních opatření,
spolupracuje při zajištění kontinuity činností a plánů obnovy po havárii,
Spolupracuje při provádění bezpečnostních auditů, analýz zranitelností a penetračních
testů.
Kzpiıøın 3 oDDĚLENÍ POVINNOSTÍ
Provozovatel zajistí dodržování pravidla neslučitelnosti provozních, bezpečnostních a kontrolních
rolı Dále zajistí, aby:
pracovníci vývoje nebyli oprávněni provádět administraci provozních serverů, které byly
předány do správy provozovatele IS,
administrátoři neměli oprávnění umožňující editaci vzdálených auditních záznamů (logů),
administrátoři neměli oprávnění umožňující manipulaci S daty na spravovaných zařízeních,
pokud tato oprávnění nepotřebují k plnění svých pracovních povinností (pracovní
povinností je míněn i Zásah provedený na zdokumentovanou žádost vlastníka informačního
aktiva) nebo neexistuje možnost oddělení těchto práv vzhledem k architektuře systému,
administrátoři neměli administrátorská oprávnění k zařízením, která nespravují a nenesou
za jejich provoz odpovědnost,
administrátoři nemohli používat privilegovaný účet pro jinou než administrátorskou
činnost S výjimkou účtů pro správu koncových stanic,
veškeré účty umožňující přístup do systému byly vedeny na konkrétní osobu, nikoliv
na roli.
MD Příloha BPI č. 4: Pravidla pro provozovatele 5/27
'
Kapitola 4 VÝJIMKY Z USTANOVENÝCH PRAVIDEL
MD Výjimky Z pravidel stanovených
architektury Systému, omezenou
specialistů ICT), musí být předem
ZptdrooaukctoouvmnpeířnítlkooahvpoaaucniýBtmoPuIzpnůesboob(esvmpedscůcishfilvekádolkueunyptrMeaaccnhonavinžcíekcréhehompoKovmBie.nzneonsít,i7
ČÁST III. HODNOCENÍ PODPŮRNÝCH INFORMAČNÍCH
AKTIV
siVtnlafusoptrnnměíamkčnhpflooıddonpoůcaemkntéíihv,oaniamnujfesohíromžoadčZpnpoírvhaíocdoaavktátniíhvoasdepnrdooacvneáéndíípjopedrhpioůmhmáomédínihoncofeonirínm.afčoSnrtímuapačeknňtíihhvooudmnaokptcoiedvínlaíí.pS ondepjvůymšéšhíom
ČÁST IV. N H 2 TUPU z‹ ı-nn
"U iw 2‹ U) ı-ın
Knpiıøıø 1 POŽADAVKY NA ŘÍZENÍ PŘÍSTUPU
Všem uživatelům mohou být Ppřřiipdřěildeěnlaovpáonuízeužitvaaktoevláskoýpcrhávpnrěánví,plakttíerzááspaodtaře„bcuojíneknívypkoovnoálveánno,í
svých pracovních povinností.
je zakázáno“.
Administrátor je oprávněn přidělit uživateli oprávnění, pokud jsou splněny tyto podmínky:' č. 5
uživatelského oprávnění bylo schváleno správcem IS v souladu S přílohou
I přidělení
BPI MD.
I
I SonappsořtižadavědelnaoívvkáunymíotaéžtňvouypjuřežííljvoeáhdnyníoBpzPřnIíasčMtnuDép,ouvrýčcehníprzáovdpjosvoěudvneodsetniyzaaupdirtonvíáZděánzénaompeyra(cloeg,y) v souladu
I pokud jsou pro řízení přístupu
použity biometrické
s platnou legislativou. prostředky, musí být použity v souladu
MD Administrátoři jsou povinni alespoň
mzjuisšítěandémi„nniosnt-rcátoomřpilinaenpcreod“lsetnaěvyřeš(inta.př.
lexximsětseíncčeněúčktountzraomlěosvtantanpcřeí,stkutpeorvýájiožprnáavnění.nePpřríapcaujden)é
MD b(pvvPnnpS,řuereoeo,irdouvubSsoIsIeIIžyčtpltopiíáurueSotcpsájždtjduhkoúvtníSídřžsočvaíýlvéeivdoačeacelavboudatytanhteanymdésžtjdvýřitkarnnáeepíooíncověeldřcizsdlhažsíiaeskeíyrtksmctoZnntžsépetp1hrnníeéeturll)2átepcnmúépiae0trpřhčaůucmmcomolíntidůorolasovdyntjzůmvytlhlíošneán.nun)oděeokíě.mpsepgacrunukysuoTiv(hoDysymysddcaknl.utěbeteíktjuažoéýfjopýe,ıeatmuíMclˇsubduůhvúhůýsoánlvb,aotčtnžtorýyzútdanaenthtnačydněoIovoatá)ůospbúosmůl“ldvěd)řčettuaízeo.meyetlsanndunnileíbíZaePsdáysnelrvveoeytímsuaosynékútšpktvvmtuačupeelioízolždtdolnňfctvyomípeíiodea,iáuvřj,kvhpnnveíadaauponialconmtjsreonoed,aéuítuybhampsrtvydoosoSoíánantldtcžtBteéaeobtípoeaPjbnularoldnvIdohooktikéyaav.řokottrMřvievvedopdekDobrýovošnoyřuý,eíbáždiúcněvastčuhíupáodevžopuntpaimerhnservvdosloeevaokpeahctyblypsnpheonulioéoliájžuétttsunaířmvkzísktvezůéepyoabČatrúynam(ÁoápčnknýěvSrtpetapsccopyiToothelvzddnIamdnapamItúuíomSnoííčIcsb.ěcrtnVhpíusiů.ykrtybodnnú(Kdý:lečúaaoeteočzpdnxtezubiatc,trhtyveeuooatkmnšlttndieeeeeosonbrltubyy3ýeyě,l
MD Příloha BPI č. 4: Pravidla pro provozovatele
6/27
Při konfiguraci systému musí administrátor nastavit politiku pro uživatelská hesla, která bude
kontrolovat dodržování požadavků Vyhlášky O kybemetické bezpečnosti (Správa a ověřovánıı
identit).
uPzoakmučdendomjidenikmáulznaěm3č0enmíinúučttuneZbodůdvoozdáusavheulkaédhmoinipsotčrtáutonrea.úspevsv ných přihlášení, musí být účet
JinnvAeniedekfjmpoovviolynnnviisniovtsaslříctvneheršínoáaoStsktípopteuioroj,zvunIžéaokSitlmkteečklírnaeoéssénmithuísfeonlijúoiknčuakpýtžcuocueíjhč.ítnmhcuajeí.súhneroileoúpvkSsrnoslpieneadrtsuůventevmýerěcenůtrhtimyezhmpapřocaaidithnřslí(ýdáncícšaílehpemnřjía.íkucetbAíehsuDontd)etea,jiunztjépaeečonsnutlpíizuoczževhabicěsnbilelauSnozžkdáezoůrbavvjoiávěvsenertioňyvt,hnZdiopžatdrlřenašnííýcpřomsipviířtáidiv.shoaylsjasasítžecéenímním,yí
mppHooeivksmıluonadnıststoepaonnnudeežagsríamdvtěnai'ítvJíndpěirvsonterSšioibvSfulrtcioiévvmnásuníyíscVthhéeosmsdeukl.Snyoesvjtasétimlunvě,jošpítreaivlcřgeeomnržéitmmnoueshš,oikuftreovrvyýaužnjeíétv i odobě. Administrátoři J'sou
dıstrıbucı systému dostupný,
silnejsi algoritmy dodávané
Je-li to technicky možné, kjiasnnotáuelmeíamcd.mhinaiustternáttiozřaičnpíochvisnlnuižeubmonženbiotje(dpřníopraádznoěvýucphřehdensoesltnZiats)ílsainlýncohu
autentizaci - např. použití
odděleným komunikačním
kunVžappiřřvkaiíothpmelaluaidšněoidvkoápranoučíučnžaeiíntmmoíuskbjíaeendzsánpploleurňčoápnvzoýaoumtvžénikhátasoénlmeáhdleukesjmlípacř,fíiyhpzmlaiuarcšsakoímyveátobnrdýíyt)d:ěktloettnooýmmhueos'dluorkčoegmneuýnnmeirkzoaavřčáínnzíoehnoíomfk,fa-lnniáenlbeuo (nezávisle
musí být
použitého
I maximální doba platnosti OTP od jeho vydání nebo zaslání: 5 minut, nebo vyžádání
I nového OTP (co nastane dříve),
minimální délka: ll znaků (Z množiny O-9), nebo 7 znaků (z množiny a-z + 0-9).
Kapiıøın 2 ŘÍZENÍ PŘÍSTUPU K SÍŤOVÝM SLUŽBÁM
Pro řízení přístupu uživatelů k
politiky Active Directory. Tyto pracovním Stanicím musí být vytvořeny a aplikovány Skupinové
politiky specifikuje Odbor ICT.
Na pracovních stanicích
je zakázáno sdílet celé disky i jednotlivé adresáře kromě standardního
systémového Sdílení.
MD dUNtmZvNžoaaeaeaikkmcvsuěahsapmsubttaoetžayenlninnleivnadtéčsaenaantrmdcscýedoieyeclnchsmípmhakcruáopýhosszhrctíeohuoaslsžnbueotioýrsvovtvtakpreeatřeápnnericřílieshhieccplpu.írhoaoccvšuAjehošndelvtemnujaěiys(etnnsmcíkeihíprzstoolvtaidobeurksbkrýzáákáyuttelzo.,onváuříkoýnžiecposiíhjevtssniaúlsostpdluupeíoožallphbmceůoáonebmvmícei,aíznptnopktipivtosiřeokdsízráloktaéreoobbemvnjnennéos,zěohop)soeupvtčřm(šiiisupehtersoclirípfáhnvršutnbe)enáyýrnkvsteíčnemtnvrěkiovynnsesýbarotkcaubpáhv.tíeměezryTucneažhiyničtspyvonoakaíuutámdmtežlemleueícyůnvh.tpSauairynmznoséíaivtsčsoétnvmzmíěínůumnc.í,iée
K technologickým Stanicím mají uživatelé zakázaný přístup, mohou k nim přistupovat pouze jejich
administrátoři, případně povevrvení technici.
KArcbheiztpeekčtnKosBtnaípmřpírpavdknůěmjmmeonhoovuitpěřipsotvuěpřoevnaít
pouze jmenovitě určení administrátoři, Manažer KB,
uživatelé.
MD Příloha BPI č. 4: Pravidla pro provozovatele 7/27
'
Knpiıøın 3 SPRÁVA A ŘÍZENÍ PŘÍSTUPU UŽIVATELŮ
3.1 Zřízení a zrušení uživatelského účtu
Administrátoři mohou zřídit či zrušit uživatelský účet pouze na základě schváleného požadavku.
Každý uživatelský účet musí mít unikátní ID v rámci systému, kde je zřízen. které odpovídá
jmenné konvenci Odboru ICT.
Administrátořijsou povinni minimálně lx měsíčně (doporučeno je po 1. dnu v měsíci) kontrolovat
přidělení přístupových oprávnění uživatelům, kteří již nejsou zaměstnanci MD, jsou dlouhodobě
nepřítomni, resp. S nimi byla ukončena spolupráce jako S extemisty. Pokud administrátor zjistí
přidělení oprávnění takovému uživateli, musí okamžitě účet Zneplatnit.
3.2 Zřízení přístupu uživatele
Administrátoři jsou oprávněni uživatelským úcv tům nastavit prvístupová oprávnění pouze
na základě schváleného požadavku.
Jakékoliv Změny v nastavení přístupových oprávnění mohou administrátoři provádět pouze
na základě schválených požadavků, nebo při řešení havarijních situací (je-li to nezbytné
pro vyřešení situace), nebo pokud ponechání přístupových práv ohrožuje provoz nebo stabilitu
systému. O změně přístupových práv, která nebyla provedena na základě schváleného požadavku
nebo nebyla hlášena jako bezpečnostní incident, musí administrátoři bez zbytečného odkladu
informovat dotčeného uživatele nebo jeho nadřízeného.
Je zakázáno zřizování hromadných nebo skupinových uživatelských účtů, případně sdílení těchto
účtů. Takovéto účty jsou administrátoři povinni smazat nebo zakázat okamžitě při jejich detekci
ajejich existenci hlásit jako bezpečnostní incident.
Přístupová oprávnění musí být definována jako vazba na pracovní pozici zaměstnance (definuje
nadřízený zaměstnanec), v případě změny pracovní pozice musí administrátoři odpovídajícím
způsobem změnit i přístupová oprávnění uživatelského účtu zaměstnance.
3.3 Řízení privilegovaných přístupových práv
Privilegovaný přístup k prvku lS muozve mít přidělen pouze pracovník, který je povevrven administrací
(obdobně platí i pro účty umožňující částečnou administraci, např. backup). Seznam pracovníků
s administrátorskými resp. privilegovanými oprávněními musí být Součástí provozní
dokumentace.
Administrátorské účty se nesmějí pouzvırvat pro činnosti nesouvisející S administrací. Pro bevvznou
agendu musí administrátor využívat neprivilegovaného účtu, pro jednotlivý administrativní Zásah
je doporučeno používat příkazy pro spuštění aplikace s jinými právy, než je aktuální login (“runas°
resp. “Su do“), případně bezpečné (např. ,,ssh“) připojení ke službě vyhrazené na daném serveru
pro administraci umožňující pouze lokální připojení. Toto ustanovení se nevztahuje na uživatelské
účty, které mají přidělená administrátorská práva pro pracovní Stanice.
Pro administraci i jakoukoliv jinou činnost je zakázáno přímé přihlašování kimplicitním
(defaultním) systémovým účtům určeným pro administraci. Musí být vytvořen účet pro každou
fyzickou osobu provádějící administraci. která následně použije utìlitu “runas“ resp. “Su do`.
případně použije bezpečné (např. ,,ssh“) připojení ke službě vyhrazené na daném Servenı
pro administraci umožňující pouze lokální připojení.
Administrátoři jsou povinni účelně používat všechny dostupné mechanismy pro řízení přístupu
ACL (např.
či nastavení packet filtru na síťovém rozhraní). Pokud je to technicky možné, jsou
povinni využívat přidaných hodnot trusted systémů.
MD Příloha BP! č. 4: Pravidla pro provozovatele 8/27
3zA.ad4pmiisnoivsattrŘáídtzooeřnrieígjicsshtorruůá,npSoěkvnuiýnpcnihinaavuwythueežneítlviazutaUčmnNoížIcnXhoUsitnaifponoradmsoatbcanívěo)uv,žaitpvaoptkreuáldvůajekteakzodvréojnůasmtaOvSení(núačpeřl.nép.ráva
uvkPbpVcřýrwšhetvoeeodoficvábvtcyhnnáioínníávvhuylátéocnnasmeíokhyumnoesvasvtplétotéaihearmojplt(ynřáe=oihlfhmseueoutkssnsilnalníaeaaží,,smmdpjmuřékeíi-tsmSleíepibrznřýébtnteooýbadtvptymáoéreluvsecom)álah.nuálnívžniiyizoHcnvgoekeaeevystsnmáelmmeanloíoirioožlpbonvenýřdeámétedsn,,dědmíáaploínlřhseeioetnbspmuýsýlrpůtmpanvžrékn(áemoínvetammbřczpeýueiřtptn.ímřizioapshaksdřylsoaimáslbičštáZěnenén.ainmíopsíumto)Surm.kžMáeaitSSnvnotkauárettoyljeíneulámeshndzev(íasmynllaemněapnounřobc.au,iožnlvhimoeavuusvatlvstézaeeíhlmdmeeeěubsmnnýsl)ýto.uí
3sA.od5fmtiwnairsutrOvádžtpdooyrvpjěoedvnpionosentinnustežaiplvraaoctidellesůnyěstzémměunintevbýochsoízťíovaéuhtoentpirzvakčuníainjfaokrémhoakcoelviývrodbacleš.ího zařízení či
Odpovědnosti uživatelůjsou definovány v Příloze č. 3 BPI MD.
3.6 Řízení přístupu k systémům a aplikacím
MD sAsAoddtummaviininnosiievssjettínrrcéááíttvosoˇjřCřeiiAjviSjjcssThooIuuvyIpzpVoro,vaviizKnnaennpniiiítmoc.plhoreuáž2níivttaétthoenpseřltíarliopvhiřyáeldBníPkIohemsplrao, m(ji,e,tžParcarvíeisdpaleakmtřiuínjziíemnaíplopižřzíaosdtvauavptuk“yv).šneachsníalu hesla
rizika
Administrátoři jsou povinni ukládat šifrovací klíče chráněné pomocí .,pasSphrase“, pokud
neslouží pro automatický provoz.
klíč
Administrátoři jsou pSuopveirnunžii,vaptoelku(d,,rjoeot“t,oretsep.ch,n,iacdkmyinimsotržantéor.“)z.ajistit běh služeb pod jinými
oprávněními, než má
idptaAntoeed'tvcmfieihiunmnnnžoíniicvicskhkatyrnszfáaýoimjtrumiooesbřžwtaioinatlrés,jlo,csvsohajýuyvsbmsáoyptluoéesvpkmnyioůýsnvjmntiaiinémzpnmippoiůodůmuovssžbypoínnurbvžěeaeaí)bvtmv.ooa„(vtkanacapnpcařýřpei.mlsdisavknysacýpecocnínrhutmvtr,ehíorolpnůd“oemnkploiuotnsdute„yžbtjíyarevluadsotantolýešmdcúí“čohemžslsenynlcsééuht,žéaepmanbřůiiaz.ssá,tAmr,udoydpmvoaieřveníňamzi,teosnntpírůjoiá“oknt,pauorkvřdá,yivujjnžensiěeotntžíuío
uuUžmiovsažetnreviletir,ův,kytkkedroéenáojnmeíetzoníětjveayckuhéžniiStcíyksyCtPémUmo,ožvnRééA,úMlS,ohuyžm,iívsjatetaeanldasmkidýnimisisktuúrčáattypo,ordkpoteobrvnéiěn.meonhonaustdaívikty
svému nastavení
limity takovému
MD 3vkA.d7pimřniínfpioasrdtměrBaáefčtyznozípřimeicčkjanéskéhotoupipovpřsůíomtsvutipunpynuipkřz-iazhjalivřsaíıtsvzipeteřnnííímpoazndaiějtiošvrtzěidnnáíglmeponřédíhbsotoumppéřuíhsoatudčpoiunznoeorxsuttiepmoiesxctteůelmoiu(spdtoůobsíuVti)zráollsiaohgpuo.ovdápníomr,y
Administrátoři jsou povinni, je-li to technicky možné, implementovat takovou
pro přihlášení. která zajistí:
politiku
SW I
I
I
unihhžáneeisfpsvlloooaorvtměnneodeelvubbsáuuknpddéíreejomuppuéžřřhniieovondzaáantčišdeuláethevníeáospnOlří(oin,"šhaplpraařea.stškpono.mvnéeatmazcaniíikphtřvuoinžhjjailimvánpéšaýrentcnaeahícl,očspivřkkníhýtípemeaksrdlaéeaucm(žhdi,uaovzapSntooeebernlrp/usaoečkzsruéekejnypmeoto)m,ndevpeounržveyááš)ddi,ěnftréopvioanunfzéoenpno"ašdpcoaebtěn,čéi
MD Příloha BPI č. 4: Pravidla pro provozovatele
9/27
I automatické odhlášení uživatele nebo uzamčení pracovní stanice po l5 minutách
nečinnosti.
MD přpoAřídopzímžaeliankonídhoiaysvpvtařBkrínPáysIýttnomuřapiupn“řa)jis(sth.oaal,uváMpešonoepnínžoiívtapmoidornlaoniavvitkáipnykzíoya“dnjp)ioar.sblotniohtěge)osolvcaáah,nríddaeanflpuišřníípsomrtvouattpnieůéc,hvd,nebČirfiucÁntkSoeýTvmafIonrúéIctVe,ov“kKČůa(pmÁhiSrtunTobalIýehe2VúsItlt,aoé.tkKoavčapiáuizstttioomlm(ieaPntri4aimvcáitkldéýnltmíao
Pro SSH autentizaci administrátorů k systémům není povoleno používání pouze jména + hesla.
3.8 Použití privilegovaných obslužných programů
aaAsddyZmmsaijitninésiitmssitůttr,rápáattoboouřyřizivešjpesovocvuihrnnopnyzoivsuiažznhianuvmiaestzzateijalitsentmoiutvžs,eipanvobéauymtšetulěSžůnicvméhavtpeávrlleoep'gnřrmíýoasmhtmiulypipupřprířakiscstostuvuypapsolovtyvýéamvmtiýokhveroýpaZmrddánrvaěondjpěrůnoemídsjmáiiúrm.čůitmeZsmepajrumasžvéioovnuavabtaeonjlrýseů.comhu
3.9 Řízení přístupu ke zdrojovému kódu programu
Ke zdrojovým kódům programů mohou přistupovat pouze pracovníci pověření vývojem (případně
pracovníci provádějící audit zdrojového kódu).
Zdrojový kód nesmí být umístěn na provozních serverech; zdrojový kód aktuálně testovaných
aplikací může být v případě potřeby ve výjimečných případech umístěn na testovacích serverech.
Vývojáři nesmějí být zároveň administrátory provozních serverů.
ČÁST v. KRYPTOGRAFICKÁ OPATŘENÍ
dBv(cpAnorPydsaokkmIpotiluřuonumM.klieDoas(nltdt.otyourdy,káD,etSiáknondkllřůstíoeitečadprlopaéraIvancSoéks,eoe,uhjbkzoeektasdzoevpbopnroýhkeéfidvoučgáadmnřujvneséryíéntuavatžcuísíbael,rpvc.oáaeížtjksepíptnavreyíocnmpvikěoiácorktlnezytraniupetízm,tiráfoáShilvgooknýrfádkírattnrmoůwfioy)aibccpryketepaéonžoagíoažrcdapbahhidoefisaraztcravprdknlkiewiáybyčka.u,nvrciooeedpsk)aatt,cktieilřrmíeépučntřůjsíoísíhsaool(utpuajřošliiugnnvoéýSjrehcyeiodhshtetomřnséyeycmm,šueěe)vlnnbíénetmpzéýrotpecožssehpitčp.vunřpopoídrtoslavnvtolkíanzšůmtíeí
vPřtiévtoýbkěarpuitaollgeoarivtýmsůleadskíylyhmoedcnhocaenniísmaůpřsíesaldumšinnýimsitrdáotopřoiruřčíedínímmiin.imálními požadavky uvedenými
Kapiıøın 1 GENERÁTORY NÁHODNÝCH ČÍSEL
MD preferuje použití
V generátoru je potřeba
fyzikálního generátoru náhodných čísel. případě provozování takovéhoto
zajistit Statistické testování na kvalitu výstupu a test funkčnosti generátoru.
Vpnvnaseáslehptkuořaéddívhopneoannýdáícěhphoompčdučoánsíutséžíeeihlčtobníjýíegtpheosnpteeoarutknádřateosvobnteralaáukvh.áezo,andjíinasétb(ihy,to,Svnegeheeddon“ád)ev.nraáýltMaonnreouúptžro(iečnPdniaRíkkNoovGvvšaiet-cemhlPonsžýreneuoZásdpltnoůě-szoRíbdasonksnadaátožhmivotýdeNslnulnémeýhdcbokheyraptoGdačeokánsotetveraéčtahnetoíčotcnrohě)
MD Příloha BPI č. 4: Pravidla pro provozovatele 10/27
Kapiıøın 2 ASLYMGEOTRRIITCMKYÉAAHLAGSOHROIVTAMCYI_AFSUYNMKECTERIcKÉ
Výběr šifrovacích algoritmů a hashovacích funkcí se řídí aktuálními doporučeními Národního
úřadu pro kybemetickou a infomıační bezpečnost.
Použitíjiných algoritmů a funkcí musí být schváleno jako výjimka V souladu S přílohou č. 6 BPI
MD.
Knpiıøıx 3 SPRAVA KLE2 C5., > CERTIEIKÁTÚ
kkupPllřoíísiuččyžeevmi,ýeatbtéěpurhlriooouckžkkueséldnyíímčšaeienftkoarrl,yjíičuetcevahk,ékoéshZtdvoailosjaatsmartaekinszýbiyueccmctnheeví.ítpronTiadkeclmníokítčébneohj,eoepkom,papřlišípgsisootfsrmurtipuoutsvpmaíkunpejřýbeicýthkkplooívdčtmaittřp,)eor,bmopatumovoivéžtžsmaatdidc,ynaizivddmkoklapyáílljčneenin.ítammopjožreponihzésosapžhripuovo:voužtégisnettíníheoorb(ocnnvyaoákpvnlřuí.u
Za správu klíčů a certifikátů odpovídá garant certifikátu. Tj. každá dvojice klíčů asymetrické
garanta. Jeho povinností
kryptografie a každý klíč symetrické kryptografie má svého je:
I zajistit bezpečné uložení kopie klíče,
I
podílet se na rozhodnutí. které klíče a certifikátyje možné nasadit pro určitou aplikaci,
I používání klíčů a certifikační
zajistit certifikátů ve shodě s certifikační politikou vydávající
autority,
bezpečné předání klíčů správcům serverů, respektive aplikací,
kontrolovat využívání klíčů a certifikátů,
vést přehled, kde jsou jednotlivé klíče a certifikáty používány a komu byly předány.
vést
přehled O platnosti certifikátů a Zajistit jejich včasnou obnovu.
v případě potřeby Zajistit odvolání certifikátu.
ČÁST VI. BEZPEČNOST PROVOZU
Kapiıøın 1 PROVOZNÍ POSTUPY A ODPOVÉDNOSTI
1.1 Dokumentace provozních postupů
Veškeré provozní postupy musí být dokumentovány. Provozní postupy musí jednoznačně
popisovat všechny postupů jsou
i plány Zálohování, rutinně prováděné Zásahy v IS MD. Nedílnou Součástí těchto
havarijní plány a plány obnovy systému po havárii.
MD Všechna zařízení v lS
musí být (jako podpůmá informační aktiva) identifikována a evidována.
Tato eyidence musí být
klasifikována přinejmenším bezpečnostním klasifikačním stupněm ,,PRO
VNITRNI POTREBU“.
Evidence pracovních stanic musí obsahovat minimálně následující údaje:
HW SW I informace O
i konfiguraci Stanice (včetně konfigurace síťových připojení
I a standardních aplikací),
informace o všech provozních aktivitách (včetně data a času a jména administrátora, který
Zásah provedl),
I
I informace o konfiguraci softwaru instalovaného nad rámec standardních instalací.
informace o přidělení stanice konkrétnímu uživateli (včetně zdůvodnění a účelu).
Evidence serverů musí obsahovat minimálně následující údaje:
MD Příloha BPI č. 4: Pravidla pro provozovatele ll/27
I HW SW infomıace O i konfiguraci serveru (včetně konfigurace
I
a běžících služeb nebo '“démonů“), síťových připojení
informace o všech provozních aktivitách (včetně data a času a jména administrátora,
zásah provedl),
I který
I
I informace o instalovaném software (aplikace, databáze ...),
infom1ace O požadavcích a realizaci zálohování dat i systému,
informace O klasifikačním stupni na serveru uloženy nebo
zpracovávány, informací, které jsou
I informace O konfiguraci instalovaného bezpečnostního
událostí, software a nastavení auditování
I infomıace o fyzickém umístění,
I informace o administrátorech zodpovědných za provoz
Evidence síťových prvků (,,huby“, ,,switche“, ,,routery“, Serveru i jednotlivých aplikací.
minimálně následující údaje:
„firewally“ ...) musí obsahovat
HW SW I informace O konfiguraci i zařízení včetně informací o nastavení auditování
událostí,
I
I informace o fyzickém umístění,
informace O všech
zásah provedl), provozních aktivitách (včetně data a času ajména administrátor.
I infomıace který
Součástí evidencí o administrátorech zodpovědných za provoz zařízení. administrátorů. K těmto
prvků IS musí být ke každému prvku i Seznam jeho
evidencím mohou přistupovat pouze:
KB I _
I
I
I
aočzautaddbemmineěitíznsopiřtpeisnrčtao-nrnoácmvstioštožneřvíncic-ohohnbsmlytotaesžčZstnttiáeoezncsbíhnte)apz,črpmtoeyečnvníašoiesmztcoáihpžnin(ysoMuzsaápntzranozžaáezmpráiyzs,nu armeayljeOvísamnytspntoíévcměheřceihnn,ífkoZtraemmraěécsjítsno(aunnacvpiřj).ej-iicnhmfosožpnrnnáaovcsěet,
a další zaměstnanci, kteří
informace potřebují ke své práci (např. HelpDesk) - přístupy
definované po domluvě s administrátory daného Zařízení nebo základě
systému na
pracovních povinností.
1.2 Řízení změn
MD Všechny změny, prováděné V rámci IS podléhají změnovému řízení. Za změny ve smyslu
ustanovení této kapitoly nejsou považovány rutinní provozní zásahy.
aakzsaKddrydmammmsoiěižitnmnndniéiěiéyssmsttputrrvřrzááíayámttptpjooěaorřírdnřai.můiě)c,opzjvPkoasmaodřsoutížykuszayíesphdtneoaooívprnvviřenmaanejeonnndebnýiocdoocuhnphgáásorzyssdOeaslkotmtuzyk,žétmuemaněmbůnko.en,taunyeltAktrýnztýazpaáecaolrszitaýýařjjcdzeeihnazjsbatíínsjídhhéieooosmstpdicíoodanhutodiačýžpůmirkaaanaádinlkd.aoithutszeNeatralrainuc.mainzozaánmvpkěosýrlngppoayrravd,aěodavzkmtoůéovmtasajoutneasmatýdínunncíasohbltíýýzltpazirsřdyvaeíýoczmckoeuhkvunsnmíííkenccoíhnrimte-pvoaylovu(jirnánázačnedápuyřtnřjio,.tetr
,ZdPao,ořtCkíýzuHkedRánÁízNsmeĚZěNpZnrÉaaař“íc,szoevvnmáýíuvmasnjíreíocbzzíomscěhasnhyuesimtknérfZmoonůrmaměmpaercponerváoovzkzoulázjsaníasíchicífihcdkhooúvtbpvaeoanzdrépsůetčoabndtesonzoséupthenčlíáčasntstoiiestcIthSni.níMomdlaoongtaikýželke,aárspisKřefiBíkZp.aaačřdnínízěemnísesvtduDopMtnýZěk,má
1.3 Plánování kapacit
MD Příloha BP] č. 4: Pravidla pro provozovatele
12/27
ZApkadpPrdtleřalmpeátníárioneipénndktoaoioecvpdsvlbiárntánnnoěorněísváí)uetzt.akxíknoltaiřřSvápeíikodšazmluáecemýíčncnicuáííthShssujzjdtíbeaíemjpdthbeěrpnrokvnrooátytobtvyulnvel,žpioraéřívzozimvýMídnaůcpívDjvhocýí.vhhbskiíeeěosPddxrtřmoatouizjpprediíopormsilronoí.zjáufeainčdtnoeamwtvntoa(áoírndlnveiSijíátsej(okeikúioralophvopodlaávžapáráicondšniktvowtíaěvěapmpádra(runncenioíos)atpvsíbařvto,u.bízdýúu,oOtvo,udspaczcebyhloírsoouhautrslčdpépueonomodvíčuItnéeCř“ětteTpanb.Sakyayy,mOssikěarttaagbťéappaymvalnycipziř)iakrez.tjaošaicpeSsčeuntnosiííalhtyzjnlsenoveydsáčsdnttmaeoésýmtmnsckíynoyht,au,ě
1.4 Princip oddělení prostředí vývoje, testování a provozu
man(Vdroaýmedžvsiponno.jiéssotntvproréoývá,umtéizohtřeoeisdphatpoatoryvjro.eadvjcwoiíazcPrhnaoeíka)cpunhrnodoenzvysaotřmmzíaiínzkzeíopanrvcípoéi,rb.oívsthlteaařsstettdnvoíívcpámírnuíodsavítonzeabnnýíMítamonmpdaordžožěsenltréeř,enKdyíB..m.uTTTseyesítstotopovtřevásíántpníyaídnnnneoaésvdmýěcvojhýsíjovibbeýmnrtkízmypíirsosúovcdfáhatvjdwáiěalnjrieyte
HW SW pNoodvmýíčinhkayr.dwTayastrcoehvpčaoilduSmjoíefjntekwyaMradeneafimžnůuežjríeKZBba.ýmtěsntansaanzceinOdabžoproutéI,CTc,o jsou splněny předem definované
případněje upřesňují pro konkrétní
Na provozních serverech nesmí být instalovány překladače a systémové
nezbytné pro Správu. utility, které nejsou
KB pZPrrtoaevccoohvznnniííccckihýczvhaýřvíčizoejpneír,onvMeoasznmnaěíjžcíherdmůívtodaaůdmmuinnesinísítbmrýtoátžnonarévs,rkžýmeunpsarvííkspotřumpíppe'ankdznpaérčvonývíjooizpmnakítyřmeunsíc.hpvráolsittřeadíd.minPiostkruádtořtio
Knpiıøın 2 OCHRANA PŘED ŠKODLIVÝM KÓDEM
KB SW O jnWvAšmsJayidkoaatmnouknvviddošaoplnoegřřiiowcíeevschsnnmétho,herrszounáan,ážéntt,kiz)fiaoeóv.lnrmdaepůau.strmme.eortlVviTjsveekaršpýkpyřkzc“řoíoha,ívpdksýamllásdauiztsěšiváaonlýnnpféoimootvctwpíépařvrcreryh„oebopvgyíogamanztrumaneasrotíwmíehalůbdoybemeoýevukzta“mudnasaumtůdcnesmvdhínaiíovcltndášhiabínlsýc,eěttisnrp.eárianMtonn/Aoasteřnktnirtitavaeeilircživoréhneivosáprrvtřnoo(eaívsulmsaeýolnrvoutvascšiteohnvrfréiiytaardwnoaOasuvlrd.ýšebíonspoáosmserfuotrtesflrvawomyíwčajpanrenIbreíuCýeemtxTtsií.pscistrnemuoyjsnusíttds,tareíléártoelmevsbnkeápýícmn.tim
Nastavení antivirové kontroly pro uživatele jsou administrátoři povinni konfigurovat takovým
způsobem, aby ji uživatelé nemohli vypínat.
Svévolně
Administrátoři mohou na provozní Systémy instalovat pouze software, který -.jj
požadavkům stanoveným v odstavci 5.4 (.,lnstalace softwaru na provozní systémy 6 ˇ).
odpovídá
Administrátoři odpovídají za to, že veškerý software na serverech i pracovních
instalován, konfigurován pravděpodobnost napadení škodlivým stanicích je
byla minimalizována. To a spravován tak, aby
znamená Zejména: programem
I požadování autentizace pro každé spojení se serverem či stanicí ze sítě (intemí i veřejné),
I Zakázání všech vzdálených spojení se servery i stanicemi, která nejsou potřebná
I činnosti, dohled či správu, pro výkon
I
vypnutí všech voleb (,,features“), které nejsou potřebné pro provoz Serveru či pracovní
stanici, resp. pro práci uživatelů,
bezpečné nastavení všech programů komunikujících po síti,
MD Příloha BP! č. 4: Pravidla pro provozovatele
13/27
I pravidelná aktualizace v Závislosti na nově objevených chybách a zranitelnostech.
Administrátoři jsou dále povinni provádět pravidelné kontroly jimi spravovaných Zařízení
na přítomnost škodlivého kódu.
Knpiıøıa 3 ZÁLOHOVÁNÍ
Požadavky na četnost, frekvenci, dostupnost a dobu uchování záloh stanoví vlastník
zpracovávaných infonnací V závislosti
na dopadech nedostupnosti či ztráty dat. Veškeré zálohy
musí podléhat obdobným ochranným opatřením jako původní data a musí být klasifikovány
klasifikačním stupněm stejným nebo vyšším,jako jejich nejvýše klasifikovaná předloha.
Administrátoři zodpovědní za Zálohování jsou povinni:
I zajistit dostatečnou Zálohovací kapacitu,
I pravidelně (doporučeno alespoň lx za rok) kontrolovat životnost použitých Zálohovacích
médií dle Specifikací výrobce (média S končící životností nahradit),
I pravidelně (doporučeno alespoň lx za rok) kontrolovat čitelnost zálohovaných dat
I pravidelně (doporučeno alespoň lx za rok) provádět testovací obnovu dat.
Kzpiıøıa 4 MONITOROVÁNÍ
4.1 Požadavky na auditní záznamy
Administrátoři jsou povinni nastavit na spravovaných systémech logování minimálně
dle požadavků této přílohy BPI MD. Pro konkrétní systémy může být správcem IS požadováno
logování nad rámec BPI MD. Každý záznam
infomıace: této přílohy V logu musí obsahovat minimálně tyto
datum a čas, kdy k události došlo,
ID uživatele (či automatu),
zdroj (IP adresa, lokální konzole a podobně).
vlastní auditní informaci.
V logovacích souborech nesmí být při chybných i úspěšných přihlášeních Zaznamenáváno heslo.
Administrátoři jsou povinni při vzdáleném on-line logování zajistit zasílání definovaných
(domluvených při přípravě on-line logování) Záznamů v případě, že v definované době nedošlo
k žádné události, která by auditní záznam vygenerovala (,,keep alive“); tato doba je minimálně 300
sekund, pro konkrétní systémy může být na základě klasifikace zpracovávaných infomıací
Zkrácena.
Veškeré uvažované změny v nastavení logování (vynucené např. změnami v provozu zařízení,
jeho upgradem nebo nahrazením) jsou administrátoři povinni bez prodlení oznámit
použití vzdáleného logování i pracovníkům odpovědným za provoz Manažerovi
KB: v případě systémů pro
Sběr těchto logů.
V případě, že oZphřlíátlseoichthynMiBacnPkaIýžceMhrDo,(vpiřpířKpíBapdanaděnzěajžidánadlýašcíth)řoíddvíýůcjíviodmdokůkuu.mneennítacmeo.žnjséouzaajdimstiintistlroágtoovřáinípovpiondnlie
požadavků této
tuto Skutečnost
MD Výpadek auditních funkcí požadovaných touto přílohou BPI musí být řešenjako bezpečnostní
incident.
MD Příloha BPI č. 4: Pravidla pro provozovatele 14/27
4.2 Monitorování uživatelských aplikací
iaVnušdseitctanhlíoncvyhanaépuhldoiáklSaoWcset.ímumsoíhuomuožňaoplviaktacneastvayvuežníívaltogopvráonsítřVednkíyže uvedeném rozsahu. Pro záznam
systému či
operačního jiného
Bezpečnostní log aplikace musí zaznamenávat úsp D (D‹ (ik Cbx . neusp ~ O‹ ‹ C dálosti minimálně
rozsahu: ._ U) :J CD
V tomto
informace o přihlášení a odhlášení uživatelů i administrátorů, politiky pro logování),
infomıace O (včetně nastavení
informace O změnách v metodě zabezpečení
provedených změnách dat,
informace O
informace o přístupech uživatelů k informacím klasifikovaným stupněm ,,CHRÁNĚNÉ",
importech a exportech
dat.
KB pnAradamvikinldieaslstirmfiáuktsaoíčrnbsíýtmtanssoctvhuívpnánilaezniáonkflMoaardmněaacdžío,ehrosedemykSteMranýnmeaibžoeajrpílemimkpaKocvBeěřpperrnaacvouiujdelo.asoaVbrloaousz.tsnaíh logování v závislosti
nastavení auditních
4.3 Monitorování uživatelských stanic
ú„(Lsapodpogměkoišuvnndáiésnttíi ronametjuúoessríspt“ěbešýcnth(érnzeiasucppdk.ányluovtsmotopinžřanmíséivl,nšuiešmctnháaéklungžjělieovnVbaáttlpeonrlmíostkoýsčkctruheopnzísis)tnaaěnh)piu.oc:íucBzhee.zBpueežzčipnveoačstnteonlsíůtmnlíozgalořmgauzmseůínžýezmabzývnteadmoseskntuápuvipanntěý
přihlášení a odhlášení, '
Správa uživatelů a skupin,
připojení a odpojení extemích Zařízení,
změny v metodě zabezpečení,
použití uživatelských práv.
Velikost těchto logů musí být nastavena minimálně na 163 84 kB, staré události budou přepisovány
novými až V případě potřeby.
.le-li na uživatelské stanici instalován jiný operační systém než standardní Windows, je jeho
administrátor povinen zajistit logování událostí na úrovni popsané V této kapitole.
4.4 Monitorování standardních serverů a technologických stanic
KB Logování
pravidla a
musí být zapnuto vnazávvšiselcohstsiernvaerselcuhž.báScphrápvocsekyIStovveanspýoclhupsreárcvierSeMma.nažerem stanoví
rozsah logování
Bezpečnostní log musí zaznamenávat úspěšné i neúspěšné události minimálně V tomto rozsahu:
informace o přihlarsvení a odhlásvení,
informace O změnách V metodě zabezpečení (včetně nastavení politiky pro Ä
připojení a odpojení extemích zařízení, logování).
informace o změně identity (,,su“ nebo “runas"),
informace o Spouštění a zastavování služeb nebo “démonů“.
informace O změně systémového data,
informace o vypnutí nebo restartu systému.
4.5 Monitorování serverů v DMZ
DMZ Všechny servery V musí vzdáleně logovat události Vyžadované pro logování standardních
serverů a navíc také:
I informace O odmítnutých paketech z intemích „Packetových“ filtrů.
MD Příloha BP! č. 4: Pravidla pro provozovatele 15/27
I informace O neúspěšném přístupu ke službě Z “tcp wrapperu",
I infonnace od procesů obsluhujících aplikační vrstvu („http“, .,smtp“, a podobně).
Logovaná musí být minimálně IP adresa a čas přístupu, ale pokud je to možné, i další informace
(např. kompletní hlavičky paketů).
Administrátor stanoví na základě dohody S Manažerem KB pravidla a rozsah logování V závislosti
na službách poskytovaných serverem. Vlastní
nastavení auditních pravidel musí být schváleno
Manažerem KB nebojím pověřenou osobou.
4.6 Monitorování serverů zpracovávajících „CI-IRÁNĚNÉ“ informace
Všechny servery, které pracují S infonnacemi klasifıkovanými bezpečnostním klasifikačním
stupněm „Cl-IRANENE“ musí vzdáleně logovat události vyžadované pro logování standardních
serverů a navíc také:
I informace O odmítnutých paketech Z intemích „packetových“ filtrů,
I informace o neúspěšném přístupu ke službě Z „tcp wrapperu“,
SW I relevantní informace Z aplikačního
(pokud si administrátor není jist relevancí
KB informací pro centrální logování, určí ji ve spolupráci S Manažerem
pověřenou osobou). nebo jím
Administrátor Stanoví na základě dohody S Manažerem KB pravidla a rozsah logování v závislosti
na informacích zpracovávaných serverem. Vlastní
nastavení auditních pravidel musí být schváleno
Manažerem KB nebojím pověřenou osobou.
4.7 z Monitorování síťových prvků -
Všechny síťové prvky musí logovat následující události:
I úspěšné i neúspěšné pokusy o přihlášení nebo odhlášení k síťovému prvku,
I
změny v konfiguraci,
I výpadky dostupnosti zařízení a síťových tras.
4.8 Monitorování bezpečnostních zařízení
Všechny bezpečnostní prvky musí vzdáleně logovat události vyžadované pro logování
standardních serverů a navíc také:
I informace o odmítnutých paketech Z intemích „packetových“ filtrů,
I informace O neúspěšném přístupu ke službě Z „tcp wrapperu“,
I všechny zásahy do konfigurace i do všech dalších součástí systému (např. Změny
v datových souborech).
Administrátor stanoví na základě dohody S Manažerem KB pravidla a rozsah logování V závislosti
na službách poskytovaných serverem. Vlastní
nastavení auditních pravidel musí být schváleno
Manažerem KB nebo jím pověřenou osobou.
1
4.9 Ochrana auditních záznamů
MD Administrátoři jsou povinni auditní záznamy klasifikovat dle BPI a dále je vzhledem
ke klasifikačnímu stupni odpovídajícím způsobemˇchránit. Pro klasifikaci platí, že logy musí být
klasifikovány přinejmenším stupněm „PRO VNITRNI POTREBU“.
Auditní záznamyjsou administrátoři povinni uchovávat minimálně po dobu jednoho roku, nebo
dle ustanovení platné legislativy, pokud tato Stanoví delší čas. Kratší dobu uchovávání logů lze
stanovit pouze v případě vzdáleného logování událostí do centrálního Systému pro sběr logů
(případně SIEM), nebo výjimkou udělenou Manažerem KB nebojím pověřenou osobou.
Administrátoři jsou povinni na vyžádání Manažera KB Zajistit vzdálené logování událostí
do centrálního systému pro sběr logů (SIEM) na jimi spravovaných zařízeních. Konkrétní Způsob
MD Příloha BP] č. 4: Pravidla pro provozovatele 16/27
,_ Ý:
realizace vzdáleného logování bude stanoven dle možností monitorovaného zařízenıı
S maximalizací využití nástrojů na Zařízení instalovaných.
K auditním záznamům mohou přistupovat pouze:
I administrátoři zodpovědní za provoz Zařízení, které logy vytváří, v takovém
I administrátoři systému pro zpracování logů (pouze
archivované), pro logy
systému
I KB Manažer KB, Architekt a bezpečnostní správci jednotlivých IS (dále jen pracovníci
I
v oblasti bezpečnosti) pouze čtení,
auditoři (pouze v rámci auditu a se souhlasem Manažera KB) - pouze čtení.
Pp.lrrea-olcIIiIIzoavtjnoipaaaaaíkasvdrdddcdttnmvmvmmilmeeeiikiiinconsnnpůnnihgiimiio)insůsdsěsvsitttmůjktětcrrrrvírřkáááIáuěáetyttmtDrctnooooíSyořhířřmřt,hiriioiojsopvežkdsřsjpánýenííircvétrosceopěv,athsnřveutntíonarpimrýszerůátokmcnslluhaímhpnoIivcěoígaDvjkhhůupcaSíolec,pzmiinrmaumktířoínassríttvceíyáz,íoblsepbznotnjnřýíneíéeít-mmímssl(amudtimsszuoěyízptjdáťsaooíprnotřvržvíéíátmoeýmmzeícnuectphysnhrsptaníábnpardimváěrromcasrvýi(klkscnymepůhbidor,lěsuomlhortjogosoríglzůežcáuůoárít.ngpvovůieép(r,šsropsaůřžk(,kdíaýIopmdaDpaípaSřadltvíuniksdpněktyiřaeucítnpinsníS)tíakIucsnophEosdeMupídszč)rťěmááoolsízevtčnnníýtmaíeemínmsstírpůímo)lť,príiřopv:ívoksýmutůcizumhtpe
I
administrátoři síťových prvků nesmějí mít administrátorský přístup k provozním serverům
a aplikacím.
4.10 Logy o činnosti administrátorů a operátorů
puaČržioionrvvngaooatsznetnliiíůz.cahpčrZnziaěavřinímlazeesontgžíaon.vvéea,nniýcmhutsaekújočívtůéhboýmtuslcoíghorbváýántněín,zyajzep-nrlaoitmietnenácahvrnáuinšcyeknyídomzoežlsnotgérů,.anyoLdoptgoěyvc,íhtdoajej-ípliriadvtmoiilnetigesoctvhranánitýoccřkhiy
4.11 Synchronizace hodin
MD Všechny
musí mít
časovým
sspeerrravvveeirryde,emlpnrěac(omnvienníbiomSájtliannniěýcmejezaddnrdoaolujšeízmapprřdveeksnyn)éihsnofyrnčacashstrur,uoknstiuczrhoyvv,áálknteensrýyémsptOoéudmžboíovvrýajeíčmassIyCsSTt.céemnotvrýálčnaísm,
MD 4.12 Součinnost s provozem centrálního SIEM
Provozovatel je povinen na žádost Manažera KB v rozsahu a čase jím stanoveném zajistit
předávání logů Systému k
vyhodnocování do centrálního SIEM MD. “
Knpiıøın 5 ŘÍZENÍ A KONTROLA ı>RovoZNÍHo SOFTWARU
5.1 Nasazení do provozu
AsOAdldpmumtžiiibnnmyiia,sslttpirrrázáototoovkřřatiineojrjsousuoousjuaepdoppovoruivonisnnktinřoiemzdapjeioinksnsttueiartnlčtnoevenas,stpeoaaudršmoiutznděuirnsmížtíornvaeapcptoioutoazřpeeptbriknomoývacmolhzpinzosíonlveučaižnnetobbyuenzpenseebačzodnbuodystéktnmonéomínppůdor.onohelnpetodskssyyytssottvéémámunu.í.
Předávání aplikací, systémů, upgrade a nových verzí do provozu se realizuje vsouladu
S pracovními postupy
Odboru ICT. Do provozního prostředíje instalují administrátoři příslušných
zařízení, systémů či aplikací.
MD Příloha BPI č. 4: Pravidla pro provozovatele 17/27
I'
Pro uvedení nově implementovaných systémů do provozu musí být splněny minimálně tyto
podmínky:
I předaná dokumentace včetně bezpečnostní specifikace, havarijních plánů a plánů obnovy
je akceptována,
MD I
I
je akceptován bezpečnostní model (bezpečnostní požadavky specifikované touto přílohou
BPI MD, případně další požadavky, uplatněné ze strany v rámci daného projektu),
úspěšné provozní testy,
I úspěšné bezpečnostní testy,
I školení uživatelů i obsluhy (je-li potřebné nebo účelné - rozhodují administrátoři, resp.
uživatelé),
I další podmínky specifikované v zadání či řízené dokumentaci.
Splnění výše uvedených podmínek musí potvrdit Architekt KB a schválit Manažer KB.
.le-li nový Systém dodáván a implementován extemím subjektem, platí po akceptaci Stejná pravidla
pro systémy dodávané a implementované intemě.
jako
Smlouva o implementaci musí obsahovat podmínku úspevvsného ukončení akceptačních testů
před Zaplacením implementace (resp. podstatné části této platby).
V případě, že implementace
probíhá v samostatných etapách, musí být stanovena akceptační
kritéria pro každou etapu.
Administrátoři mohou převzít do provozu pouze zařízení, jehož bezpečnost byla prověřena
bezpečnostními musí obsahovat minimálně „scan“ na zjištění existence známých
testy. Tyto testy
zranitelností; pmnřeoíbpžoandénjéíprmodavlséšcsíhtvttáeelssettyny,ýpokputaezrreténnersa.tvanyVobvrípařnMíéapmandavěžzeonrraksuKaBzzae.řníízBeenmzínp.eočhnaostpnrívků„scsaen“shporodvnáýdmí
Manažer KB
nastavením, je
.le-li to technicky možné, jsou administrátoři povinni nahradit nebo přejmenovat implicitní
(defaultní) systémové účty (,,root“, ,,administrator“, ,,guest“. ...).
5.2 Provoz
psAbldpuámrdniaeůnviooasbvtsparalnáháýtoncovůřhaiotzbjaiřsnínoozfuveoynpríomsvjayiscsnoetnuéiomadkuvmoyipntnovfiiogsřhutairrvtáaártcpioriiřo.isvyopszotnvéíinmnduio,akujjeem-jeliincthtaozcmúičěenvlášnceéhc,h.zaVszepnšrkaaemvreoévnaáZnvmýaěcthniysdyvoskthoéamvnaůfir,giujkrntaíeccrihá
pvdJoeoetddfřanuevonabtknkeýčolcnnůhíkmrúénkcteoenbnlíokůuzaaomřdduíobszsoíetrnaíůbtýetčnMnemoDbiuo.nizamssPaktoluučpipeizitntoeuvláanndZomasniřtíanazidesnmnetiíjrnnáiitvsžoetšrírůáftmuojonrežůkdn.čnýnotílpmoičvecýtec,lhkkutzearnřýeízszemaníjíistsínpervbaýovkoovnzaatřvíšvzeíecnchíe
,
MD pkVolzdadlsáeilfiepknoaážčandísampvrskátůvuatpéntzěoamřpíř„zíeClnoHíh,Ry ABkPNt!eErNá E“pr(aacCuzAjaSíříTzSeVnlílim,niKfauopmriímtsaotclěeanmýiI,miOkdVlsatDsaMivfiZekc,ovlm.auln)sý.ímiprobbfleızaptečšniforsotvnaínmě
nAseedjrmvsieonriuůsntaerázdtbaolyřštiíncéjhspzorauořípZzaoejvniiíšntIněCinTí.ucdAhrdožmdoiuvnaistsltuoržtáeetbvořřseeinrjévseopruoů,upzouevžiipnvonarittezylasknkáeýzzcabhtystvtnasényipscrtaoémszuíaťjvioššvteýěccnhhínpcyrhpvookdrůtu.y,slkutžeerbé
Při správě zařízení umístěných v DMZjsou administrátoři povinni řídit se ustanoveními zvláštního
předpisu stanovujícím požadavky na provoz zařízení v DMZ.
SW Administrátoři jednotlivých zařízení jsou povinni umožnit a zajistit instalaci a konfiguraci
potřebné
bezpečnostního definovaného Manažerem KB a komunikační prostupy. V případě,
MD Příloha BPI č. 4: Pravidla pro provozovatele 18/27
A
I
SW SW tapžeresZotdjkůeáo.zkiauntms.teanZltaacoevpatrnaůékkoapvzoénthéíožejsSoukonmppeoamvtaoižžboinlváiátnZoyuprkvooývnsoktzrunépítycnhíZcdhůnávsotdrůo,kjoůmmuppsroíonetmnuottnoiastkovurýtisentčgunpoySsytZstapdérmmoiuvn,eidsZetnrnááýtcmohér
5.3 Pravidelné kontroly
MD posApvAřdprldnímroamapisačirrntvnuaivniošvsísveystktnayrarnínásáa(ýtttebocénoxeřhěmřizijsiuptsejmjutyčsjusasnoeosktouuíoérsvipmtbzpéoůiiýovktsvioaSoin,hyunnplsžbniráteioošépvrembrěymnuyařoi,lvienyixtaiipddspřemřtořlíeáunípjšlIíěpaenS,adně(dnoadnějjopéeaprodkonovnoravplouleřboučeídežezpezenermpnnnaoěeyévásjčupíennarečojknaasneovutědúmutnntáoípo(olrruskiiiomnzuemvacoéěizvn-sdsáaaetínncnčíětsí,an).ylně.seua)tmrAlénčdýjmaemzej.niuíítnzOjivsbidslsoehttauziasrbtplt,áoenetrčíznoynkdír,oaaszkúajttstinpeesoírtokícénduheodnjbůenenlvmeděooabng)djoáů.,í
ubpAžýoditrmvtiaynhtilvesáeltšsreskántýtaacovhřuias.tj.ařlsnieoisšucte.ennp“ao.vDijneantkieokpcrbeaevztipadekečolnvnoéěsht(ondípooproitnruc,uičdkeetnnetor.ýjenKejonenídtnuroovlueadmeěnTsCíVčPpnrěo)i vokUzoDnntíPrdoolpkoouvramtteůnTtsCaecPi,nieUmtuýDksPáí
KB aSMAddaammndiimnaniižisnestitrrsrátátrtoáořtiřoirsjeesmnzoenunábamopmeovánijitníknamoijvsévopyuoutvežpsěíotvřvoaeivtnnánýnniíássZtZerraaokmnjěientsipetlrmnnoaovsnkytejoíáncdtřariojtsle.luab'iionnp.tergáSrvinvtýěysnsloeudpbkroyorvotáěvdcéěhhttoo systému.
v součinnosti
testů musí být
5.4 Instalace softwaru na provozní systémy
Instalaci software na provozní Zařízení mohou provádět pouze
provoz. administrátoři zodpovědní za jeho
SW GNU SW AindsmtIIiIIanliosSsvnSIstooaáoSorfpnfffářtntttt.pwwewwoaoabaarrruroreezeeoejijdjjenepepesfososoopdccfvlrohhteímtvgvwdařáááaáčellrlnbneeezíěnnnacýslhapzOitlpdaodcaňrm,kekuboinotjožncuíiveíircvpýsíeeanMtknmnarpoDýááons,I,ptdlCroočeparTibdřcenunníaomjěopví)nscadn,teídíaínnn,apíěsénotsZhedapsaobnmremioáíízcvjnaetueřk.n,ídyuznS:tdeeáonvrMíhyv.oalteenvrdfaoy,rřžeaeebenerwdýzaeaprlmiešeníčtKn(eBzioma,sěřpt,írzozeanřkííozmveenjíre,čhnobíezsppporeuáčžvniěotsíj,te
SW CRC zsjPdbPepvaoa-řrětllkeařiíoudecčvdnokýiýůvnncnáse(ohvtsdpsaatorilznašočaaýhlvcřcooíeoívhddzákeesčvnennoiýíífprkutrkoopwcoobonahsnvcrkottieervřrnéeáonnjdtvliesnna,yuoiínumcmýZotaucžvjahiíňdps.mmutoiijv-vtníe,eiCvcrřsyvíeketcnjrrlmnáíiootécdmobiděřerfaizeitjpdkoipeuavnočncéévndihiosoanísd,ntntaěcitn;iyíaphobcrvopehoěozevřsdpceipoetkdrbčeánn-nkvěoocíc)seny.tk,zkoilnzastiadtrcřmeoíiknlznécyeiih,nsoítžarreáaeptsdoreiuřannjivfdeoojadsrsnntmotáaunicoíníphosřortiniaasglsoiapunčnrčánáětlívuncmě,íh
SPRÁVA A TECHNICKÝCH Kapiıøın ó
ŘÍZENÍ
SW ZRANITELNOSTÍ brZAerědalhmneiivsntalienusltžntnoerísbátctíaho,řabipkeltjzieskproaeécučíjn.psooosvutinnvínctihétsoleodbolvaoaspttriaivpnofpsorkroymtadocaveánonýyz.sryaAsndtimtéiemnlinnsoetsortváeltcihovřňaiujvjíyscuoížucíhvpaontveisgnlanutižievzbanjípimsrtoiztspliůnessdtooavbláaecnmií
MD Příloha BPl č. 4: Pravidla pro provozovatele
19/27
kPoonkzuudltboevzápneočnSosMtanníaž„epartecmh“KnBegtaatki,vaněbyovblyilvaňzujveážpernoavovzhozdanřáízeknoím,pemnuzsaíčnbíý,t jeho (ne)nasazení
případně detekční
opatření. Záznam do provozní dokumentace musí být proveden i v případě, že „patch“ instalován
nebude. Tento Záznam musí obsahovat detailní informace O tom. která komponenta zařízení a proč
instalaci „patche“ neumožňuje, a dále pak patření přijatá pro minimalizaci rizik plynoucích
Z neinstalování ,,patche“. Pro instalaci bezpečnostních ,,patchů“ musí být minimálně jednou
měsíčně vyhrazena časová okna v SLA daného systému.
Nápravná opatření, která jsou administrátorům uložena, mohou být aplikována až na základě
souhlasu Manažera KB.
SW Software
pověření
na Servery a technologická PC mohou instalovat pouze jejich administrátoři a k tomu
Na uživatelské stanice mohou instalovat i pověření uživatelé,
pracovníci. kteří mají
přidělena příslušná oprávnění, musí však dodržet ustanovení této přílohy BPI MD.
Kapitola 7 AUDITY IS
Administrátoři jsou povinni poskytnout nezbytné součinnosti pracovníkům provádějícím audit
nebo kontrolu podle schváleného plánu auditů a plánu testů (neplánovanou kontrolu nıusí schválit
ředitel Odboru ICT). Bezpečnostní testy jsou prováděny podle pracovního
Manažer KB nebo
postupu, který definuje Manažer KB.
Pracovníci provádějící audit nebo testy musí mít přístup pouze pro čtení. Je-li pro provedení auditu
potřebné vyšší přístupové oprávnění, musí být tato
nebo testů skutečnost S administrátory předem
MD konzultována a přístupová oprávnění schválena Manažerem KB. Přístup k auditním záznamům je
možný pouze podle pravidel stanovených touto přílohou BPI nebo se souhlasem Manažera
KB. Konfigurační a Systémové soubory mohou být zpřístupněny pouze jako izolované kopie.
zKÚasBpběeašzřnpeéedčintpeolrseotvnOeíddbieonncríiudepnIetC.nTePtjerenaebčtnerízacpčhenčínttoeessstttůnbíem(zniapnpřcaeidddecenhníotzeímthevosžtidonyv.faonrémhoovánsíysatdémmiun)istnreántíorůp,oMvaanžoavžáenroa
ČÁST VII. BEZPEČNOST KOMUNIKACÍ
Obecné bezpečnostní požadavky na správu síťových prvků se řídí příslušnými ustanoveními této
přílohy BPI MD.
Kapiıøın 1 SPRÁVA BEZPEČNOSTI SÍTĚ
MD Jakékoliv propojení interní Sítě S veřejnými datovými sítěmi musí být schváleno administrátory
Síťové infrastruktury a Manažerem KB. lnstalovat komunikační zařízení do Sítě smějí pouze
administrátoři Síťové infrastruktury.
MD Provoz mezi veřejnými sítěmi nebo sítěmi třetích stran a sítí
FW Konfigurace ;
FW musí být
musí být řízen pomocí fırewallů.
musí vycházet Z principu, co není dovoleno, je zakázáno. Povolené prostupy skrz
zrızenı. součástí provozní dokumentace; pro každý prostup musí být uveden důvod jeho
MD Služby, poskytované ze Sítě do prostředí lntemetu (webové servery, ftp Servery, VPN
a podobně) musí být umístěny v DMZ.
MD Vybrané body propojení sítě s veřejnými datovými sítěmi nebo sítěmi třetích stran a rozhraní
zónami musí být monitorovány a řízeny IDS nebo IPS.
mezi vybranými bezpečnostními
MD Příloha BPI č. 4: Pravidla pro provozovatele 20/27
Administrátoři Síťové infrastruktury jsou povinni zajistit potřebné propojení pro bezpečnostní
MD monitoring a vyhodnocování dat IDS nebo IPS. Nasazování jednotlivých komponent Systému IDS
nebo IPS je realizováno dle potřeb a schválených zdrojů pro tuto oblast.
Při komunikaci je zakázáno využívat sdíleného média na linkové vrstvě modelu OSI, pokud to
nevynucuje technologie.
1.1 Nastavení síťových prvků a jejich vzájemná komunikace
Administrátoři „routerů“ i „firewallů“ jsou povinni nastavovat základní filtrační pravidla, která
podobně).
vyplývají Z RFC (popisujících konkrétní protokoly a
Pro správu síťových prvků musí být vytvořena fyzicky (nebo na úrovni VLAN) oddělená
management Síť.
spvAcrzdomhditvánoláikelsonetlěnruopáuatoomMsřeoaircnvíasežírpuťeroor,vte.ýomRckAhoKDlBzIua.U„řSsí“zs,ehn“,ít,jaDimsa,omuketdpeeorvj“ei,nt,noi,mTopAžrCnoAé,aCuSnt+een“btoinzveaybcuiožípvvozaddtoájblinenýnoécuhba,depmzřipínepičasndtonruěactpeeřciphsontuoužlpíoogvviaaitt
Administrátoři jsou povinni využít prvků autentizace u „routovacích“ protokolů a dalšího
Zabezpečení, které dovoluje implementace těchto protokolů.
1.2 Změny v síťové infrastruktuře
nzVeembšěoknemrmuéusszíímbběýýnttynSovívťásoíviťýnomfviraésamtdrmmuiokntdiuesrtlaruábtumodurosyvísáebnsýattapsvaecrnhavlheáallvneaěnryisjenMíSatnpávlaaážjníecprír.eompKříBp.adPřneedúsrpeěašlinzéahcoí takových
ukončení
Změnou v síťovém modelu se rozumí:
I změna oproti pravidlům a požadavkům stanoveným touto přílohou BPI MD, nebo
zvláštním předpisem stanovujícím požadavky na provoz v
nebo struktury jednotlivých síťových demilitarizovaných zónách,
modifikace propojení segmentů či vytvoření nových,
změna v IP plánu,
změny statických „routovacích“ pravidel a „routovacích“ tabulek,
změny. které by mohly
I změny ve struktuře mít dopady na funkčnost bezpečnostních prvků, např.: či
evidencí síťových prvků a prostupů mezi síťovými segmenty
sítěmi,
I Změny V konfiguraci IDS Zařízení v síťových prvcích.
I libovolné změny v konfiguraci segmentů Sítě, které slouží pro přenos dat mezi
bezpečnostními Systémy.
I zavádění nových technologií,
I a další, které administrátoři síťové infrastruktury budou považovat za zásadní;
1.3 Bezpečnost bezdrátových sítí
Instalaci zařízení pro poskytování služeb bezdrátové sítě mohou provádět pouze k tomu pověření
pracovníci provozních útvarů se souhlasem administrátorů Síťové infrastruktury.
MD Administrátoři jsou povinni nastavit zařízení umožňujících bezdrátový přístup do sítě tak, aby
byly naplněny minimálně tyto požadavky:
I zařízení nesmí umožňovat anonymní přístup,
I
pro autentizaci zařízení k bezdrátové síti musí být použit minimálně jeden Z těchto
mechanismů:
CA MD I uživatelský certifikát vydaný intemí
- Certifikační autorita - nebo jinou
důvěryhodnou certifikační autoritou schválenou manažerem KB,
MD Příloha BPI č. 4: Pravidla pro provozovatele 21/27
ıqr
MAC MD pPZřarříoímvzIoIoezndíotd,mpIaaurlkkstontoeute8ovjmer0cýímá2hcae.rhtbnčlaýueazxnt.ssaupřmvlpíekyňřzcouitejhpmvnoíaíáujřnnjeveieinýnskíšmymaenouceažseuubndvomSýieutcodnspedeíoínpntuoézbrzjýááeetplznonvpnížíoaapmzumařdžřaíyaiípuvtzatkOoedeyněnmí,p,t,iřinžijnzepieeaomhsčujáomnmelěíonnjmýžíěcňphurWbjvýPzítkaAaedřp2dmríř,o,ezísestiunnuítapcehIr(nPjoísabodssuíratephěsruuoj.ípcoíjenmpařii)npiopmjoáeunlzane.ě
Manažer KB nebojím
pověřený zaměstnanec je oprávněn provádět detekci a testy
sítí V okolí provozních
prostor MD. bezdrátových
1.4 Internetová gateway pro uživatele
MD PpUořžvíiosvIIltaeutnpehunéoltamvétspopotržu(a(on“zv8tiai0og)ttmka,ěpoktsrloetoymwnsuaaatnnyupci“poikyrnatepcyboipourSz“oeaipkrppeoořrxmexotsuyepn“mtoiiuvsksteotoarlécv„e)eignra.émutžoApeidhrwvmooaaittyunoe“iklspůoptřlordiyuásotztnoulaeřpnipZotvoetiavméntoettltockuem„níjglýsanscotíthutee:ěwmpMaeortyDtu“.ejcphso,ouuzpeovpiřnensi:centrální
https (443),
ftp (20, 21),
aAdjmeihnoisvZtyddraurálžotšííojvřoápivnoíáut.ézItPeUodaná„dalrgoeazsstátaeki.lwmaaduyěs“ívjýsbjoýitumlkpoyo,gviosnvcnáhinvyánlameinnniéiZmMaáajlinsnatěižtevlrroeogmzosvKaáhBnuí.:přístupu uživatelů k lntemetu
přihlašovací jméno (např. Z Active Directory MD) nebo jiné
datum a čas.
požadované ,,url“. jednoznačné určení uživatele,
msTitynutipomnálělomgnyě„mpPuoRsdOíobbVýutNjIevdeTnŘvoNšheIochrPokkOouTpiaŘíEncaBh Uvk“ylž.aásdiáfAnidkmíoijvneiásnptyorspáktřyoitřnnieojumjtesMnoaušínmapžobeverizonpnveiičnKtoBys.ttonílmogkylasuicfhiokvaáčvnaítm
VZDÁLENÉ PŘÍSTUPY Do MD Knpiıøıa 2
nVeesšpklenríédddeekeffilifniniieincncioitvsšaakiuénftopreuořnvítbasiectzzíuapcpčheynčíamncluohgssomtírneibíctýmhtpůao,klnoiintsifkmiuůgup(rrsooivlpánřáníysatututapek.n,tTaiazbtayIocensp,eoulvimítocižekfnaaimkltuyosrpíořvioápbosajauehtnoeínvztaiatzřaímczieen)ni,ímmá,lkntěe:rá
VPN MD mPkAirodnonmiifmni„áigslisuttnrzderěoáe-áv:tfktaoiao-ntzřsiictijtaiaekk,“tkýelaccipbhheřynkníootsvllstyokuighýpviocyídhvaěmpllurZšyosaířcívíhýzbšseýenítíťuosvdvppeeýoojcdfuehiežnnníípoé,řvviapáponnolýajicethinbcíee.zpnpraeočknlvoizsedtnántlíseknépýomlizptaiřřkííazs,etnuípk.tekrsáítmi1Pusí
I je musí
I obsahovat
definici autentizačních mechanismů - důvěryhodný certifikát
„pre-shared“ klíč (délka znaků, použití velkých nebo bezpečně vyměněný
a speciálních znaků), alespoň 20 a malých písmen, číslic
definici šifrovacích algoritmů,
MD Příloha BPl č. 4: Pravidla pro provozovatele
22/27
„_ _ ,_ . _ „ˇ .›
_ ýfiıàì A z--~›zzz zfl Ý `““~ˇfˇŤ “' `;: _“
_
I VPN definici technologií pro spojení.
MVZašanedcaehžfinenyriecimtyttKoěBc.hptooliptoilkiytik(azojdepjoivcíhdazjmíěandyminčiistraákttouřailiszaecrev)eromvuýscíh zařízení pro vzdálený přístup.
být před aplikací schváleny
Vzdálené přístupy extemích subjektů musí být schváleny Manažerem KB.
2.1 Práce na dálku
K MD sítipřímsotuhpoyumuvszdíáblýetněvyptřviostřuepnoyvaotddzěalmeěnsétnpařnícsit,updoovdéavbaotdeyl:é, extemí spolupracovníci a další.
Pro tyto
klientský přístup pro zaměstnance MD,
klientský přístup pro extemisty,
VPN MMDD iVnefšrkaestrréuppkřřtí„íusssrittytuu.epp-tpporr-ooSiddtooed“daavvaatteellee,,mkkottheeřřoííunnaadodavpaprrtoaevcluáůjdmíějnízapeřixímtspetlmueípmňesonpvtraaátcviupozsauyřzsíetzéemnníůez((b,,,y,Sstiintteěe--ttoon--uSsitittneeo““)u).„ část
ČÁST VIII. AKVIZICE, VÝVOJ A ÚDRŽBA SYSTÉMŮ
Knpiının 1 BEZPEČNOSTNÍ POŽADAVKY
Bezpečnostní požadavky systémů
v těchto musí splňovat veškeré zákonné požadavky na informace
systémech Zpracovávané a dále musí splňovat požadavky stanovené touto přílohou BPl
MD.
Aplikace nmpeřosíhsmtoíuupp;rbjaýictnoévpařitennfSáoširenmnfaaocrepmonauecszemmeěidj,aítkabt,eýrtkéepnřkeetjnseáoršuýemnpyrmoaánjiejuísžkifrvyuatntěeg.lovčáinaíplpioktařceebnné.a Po síti (intemí
základě svých
i veřejné)
oprávnění
1.1 Analýza a specifikace požadavků
V mZi jáoekhhlooaudjnebídýntboetMzlapinevčaýnžcohesrtkenomímppKooBnžeansdttaa.vnkoyvezmnáuyvsiedsaljloíšsítbiýptonžasaopdulačáávsnktoyívvapyrnpvélomýtvnpaíojuíažcniíatlZíýazSnoyaflptýřwzaiyrperraiavziojkve.ahnoéahrochsiotfetkwtaurřee
MD Při
fIIormknuaalppaalccniiětnpyíožzparádokavovonzknnůýícachhvpýúobtžěvaraudrůařveakšůeúntíavapmrouůžsaípdrbaoývvtkáůdz,ěojhuílcveíedcdnheěnanýkycczheepvtjamBčéPnnlía tyto skutečnosti:
testy,
a v jejích přílohách,
(provozní i bezpečnostní)
I dřívější bezpečnostní a provozní incidenty, j
I KB další požadavky Manažera a výsledky '
I analýzy rizik,
naplnění dalších předem stanovených výběrových bezpečnostních,
uživatelských a podobně) kritérií. (provozních,
1.2 Zabezpečení aplikačních služeb ve veřejných sítích
ApliIIkačckpvneoošírumetžSiucfílhnivunikažáyktbtayyc,ScepeerrrtvoisevferioykzásotemvyruavssnecíérhyvpváreploaevrneotéřvneeěMjrřDnůeý.ncímhu(dssaívtéo)bvýýticdehznatsjiíittšyítcěhanamšuišsfiírfodrváoálvneáínsíppřmliňoakvoaamtu:utneintkiazcaiceS klienty
serverů
MD Příloha BPI č. 4: Pravidla pro provozovatele
23/27
MD veškerá komunikace (včetně autentizace uživatelů) musí být
přílohy BPI (tj. aplikace nedělají ani „redirect“ šifrována dle požadavků této
Z HTTP být
navázáno pouze na HTTPS), na HTTPS, spojení může
na front-end
serverech nesmí být trvale uchovávána data a nesmí obsahovat databáze
uživatelů,
veškeré přístupy uživatelů musí být logovány pFoWd,lempůožžeadbaývtkpůotvéotloepnřaílpoohuyzBePIdeMfiDn,ovaná
servery musí být od veřejných odděleny
komunikace, sítí
I vseýnm/ěenryůmdaptruomvoozžunjěíncaímvzráůjzenménáslkuožmbuynziákkaaczen.íkům nesmí být kromě nezbytné aplikační
1.3 Ochrana transakcí aplikačních služeb
OchranjmcvkpaiaeueronpršstoýlntkríicicaefkhvonibraevskýáCcšáaýtekAtkckůedcnhroeíne(éfmebuakiusžpoontmnilmrověisiuavajkyknnátíasaseinčtcalbknékůeSýíamcteccmehzmemaůneukmsžSazcsluemeikíuspžobísstevnýpocbtšlcvbhnemýoávnimtnuávatiylshývp,erímšonkauesýzoužpccemžilhhnpitňnvooodOyavnůTtappevetooPněltžtrmevnaayimredhmnzbamoieiovůnmdkížándsylýeryencsuslběhttheýéaýkttcmntymeušotrriovotafeinumprfnitouoiécežsvkknáaaítýtnčdoimanuabzítvýaacopktdčhoypndha:říšuopímitcilfo)forsr,iahoetkvom,táuoncB(raenePramtIp)iof,sMimtkDoráac,tnyíě
douzpaopopmdalmůopikisžrtnoooniivbkvísayottarzvká(nycmtmuíeoižiřpdinnittoiiaíkmmcauááipcmllleecnnirnekěětrtiatfacjioiecfekbeiádnnk,tnáoeůot)vbůuaovkzays„aždyrdoasšoéntetéýs“mctsuhccmhejdvěrsáastoilníufeocinůukpéáotavau.ui,tCnooAnrpiirjtpaeořzvjuikeí;dodmentltuppnrtrroooooslvktvoeoevndadvteteyrnndoidáílovmudmárumnkžsuíooísnvíCfáuiRnačgíLdiumn,riicanteciprestoz,itváfroziáklktntaeoeačřnrmniáýí
certifikáty
protistrany musí být ověřeny (podpis
CRL),
certifikátem vydávající CA, kontrola
tnZkraomaněnf,sni,aogfkuurčronkaníoctnúeedfnakidjrgoeyuv,ąrýıactchoe“g,ratsjfe.irncvekenýrcíehcnhpurtonnséetspřmerědojkgíůraabmpýoltvikáatnrcíví,ajlee možná bez zásahu do aplikace pouhou
uchovávány žádné
uživatelské ani
přístup k datům smı' být umožněn
transakční data musí pouze přes aplikaci na frontendovém serveru,
umožněn přístup, být uložena administrátorům nesmí být k těmto
šifrovaně,
veškeré použité údajům
BPI MD. šifrovací algoritmy a délky klíčů musí
splňovat požadavky této přílohy
Kapitola 2 musí BEZPEČNOST V PROCESECH VÝVOJE A PODPORY
SW Při vývoji být dodrženy minimálně tyto podmínky:
OWASP MD nPIappáb(vnřarsepZfiyaytzrrevcrmpaíjoíovesejmvjýtčnneůéovrna,ntonzuoéjacevsitCxaaýtřuiapvnírssalrotzíeppijuderjlkinLmíáiaíio-Iavkcbldpnpaeuriřdelac,íaurilesIsyktsSt,aaunyrcpesydneuabte,lnoéDbšepmaoíobytslobayjimeetsuszjitSysi-pkeéscaeícmhtOčuuhéunpremmroiesueostmen,lltyžue,nnsWvíiSíalettnopabtgonbnnodýažAívatppaárlpnddčnldí,aáěi,.osvnt.cdki.íoary)ctžvih(emšanorneuanaycpsdnřhSíoa.epmucbkoesIuýorttrtTmuoaiIučddntLenoieynivfk-PíkeiyrannoícIvojpenvýertf,cáréotonto,zroybábmcPplaepůřCotřzíhIieplovodeovDýnčházvSynnaoSýSíBhje)áPoc,-vjIvuýerýTvinchotíhejym
MD Příloha BPI č. 4: Pravidla pro provozovatele
24/27
ˇ
ı
I vývojové prostředí musí být oddčleno od provozního i testovacího, přístup do vývojového
prostředí mohou mít pouze pověření pracovníci,
MD I pro vývoj podobě jako pro testování nesmějí být použita ostrá data,
I zdrojové kódy aplikací ve správě nebo vlastnictví musí být klasifikovány
přinejmenším klasifikačním stupněm „PRO VNITŘNÍ POTŘEBU“ (a podle této
klasifikace S nimi musí být nakládáno),
I u aplikací a systémů dodávaných na klíč musí být smluvně zajištěno, že zdrojové kódy
budou majetkem MD,
I aplikace musí pracovat pod vlastním účtem, který nemá superuživatelská oprávnění,
I musí být uplatněna zásada minimální manipulace S daty (aplikace nebo její funkční části
nepracují s daty a nepřistupují k datům, která nejsou pro vykonávanou činnost potřeba)
aminimálních přístupových práv (aplikace nebo její funkční části mají pouze taková
oprávněni. která potřebují pro vykonávanou činnost),
Je-li vývoj realizován extemě, musí dodavatel předem potvrdit dodržení ustanovení této kapitoly.
Knpiıøıfl 3 DATA PRO TESTOVÁNÍ
Testování nesmí probíhat nad ostrými daty. Pro potřeby testování musí být vytvořena vlastní data,
která obsahem neodpovídají produkčním datům (při zajištění dostatečné vypovídající hodnoty
testování).
CvAr ST IX. RvrIZENIr INC'IDENTUO BEZPECVNOSTI
INFORMACI
Kapiıøıa 1 oDPovÉDNosT A POSTUPY
Povinnosti uživatelů i administrátorů a příslušné postupy pro zvládání bezpečnostních incidentů
jsou podrobně popsány v Příloze č. l l.
Vlastníci informačních aktiv a správci IS jsou povinni činit taková opatření, aby nedocházelo
ke vzniku bezpečnostních incidentů.
Administrátořijsou zejména povinni dbát na předcházení bezpečnostním incidentům (jsou povinni
zajistit zejména nepřetržité automatizované vyhodnocování bezpečnostních událostí) a neprodleně
reagovat v případě, že bezpečnostní incident nastane.
Bezpečnostními incidenty se rozumí stav systému, služby nebo Sítě, ukazující na možné porušení
bezpečnosti informací (obecně nebo vyplývající Z bezpečnostní dokumentace) nebo selhání
bezpečnostních opatření.
Knpiıøıfl 2 PODÁVÁNÍ _zPRÁv o INCIDENTECH BEZPEČNOSTI
INFORMACI
Hlášení bezpečnostních incidentů se provádí dle ustanovení v Příloze č. ll.
Administrátoři systémů, kterých se nalezený bezpečnostní incident dotýká, jsou dále povinni:
I bezodkladně zasáhnout přiměřeným způsobem tak, aby znemožnili pokračování zjištěného
nežádoucího stavu,
MD I bezodkladně infonnovat
způsobem dohodnutým se správcem IS a S Manažercm KB,
I zajistit veškeré dostupné auditní záznamy pro případ jejich potřeby při vyšetřování
bezpečnostního incidentu či přípravě a realizaci nápravných opatření. Tyto záznamy jsou
administrátoři na vyžádání povinni předat pracovníkům V oblasti bezpečnosti,
I řešit (případně navrhnout řešení) následky bezpečnostního incidentu,
MD Příloha BPI č. 4: Pravidla pro provozovatele 25/27
ÚV'
I
MKDB I
aiunaplnadrtpjfmoeířoitvmírnéasmistlaostuivtšvakornndotáýísntchtMtohorrraaoyúnřnlteaitušvtžěeavcenrhíšrpů.teřaocíčhsiysnsyyntsaeétvbmsézůovmn,éůdih,okodukatnveaabrdteéřezílbpzůyee.čmnnNéooehhsnoltí-nyalíibhsýpontoálpiiurnnpaccriivaddaceeonmnvtotauež,tmnpázrřjeaissepna.ážaedvnmrpyiho,nužiarsadetsoripvám.atpotilrnefmpnoeoámnvpıtiroanavcevainut
Knpiıøın 3 BPEOZDPÁEVCÁNNOÍSZTPIRıÁNVı‹O`oZRRMAAcNıITELNOSTECH
MD MVoZašpraiantcnařihegtnneeiílm,nzeoannsmattpěřujs.etjnvnaaeyknduocožisímtvojaasžttoenukIé,Sprokivtzeiirnkýonv.iurmioonzžfpoňorurmjuoevSauptpřlioadtzěnjlěiensvntíveýhnmríioZzprbřayní,isttreuelspnpoo.svtýpímřieakpnoranháalvtáys.SittávjiajvícríábmeczipeIčnncoidsetnntí
ODEZVA NA INCIDENTY BEZPEČNOST] INFORMACÍ KB KKaAppdoimsIItiIIonouilaMzavsvplřaZpaeptiýrteodnnropnoršes4oáířafžvemottíkožénaaibapounísedžtcařmntreiormdeinooevvaěpumyvznn,asos,ahítytčtíthožiosnřodetveadbnonéabdýořuSámtnřtedtlapůZéšíaíapr,rezvbnřazaneOiaaseknváínnltidvtusuéatreee.éadheeizrlháhlsbomýeeolpnyycNpnm.oozlehlosnsaank(etuantmsííiomean-eědnecmdazlsothnnařrplitdaaettíeenbnmlamčzznaieinecíeeeztznnázínmnneapicpeéaélsečsinerhnmtčnceáanoornahíxvsasáozvtathyMtrsáeasosaoatlamyntrinmeoíisyéapnostmntmiažopeža)uéntdloev,,fnmřaMnlrroeluáoauianrhšspnníímnptr.KafcjaooahdoežBcudcoríet,potmsrjavoýoyeařdakrvsemtáoaotKši,tpvéenBjrnamjip,íseáůsnřjot,ivérunnomáaěk,dtnbntáoeájelrrezvrMeejpérsaíehpppnč.oumeoanvlovžosiiihesnpmantnoirreinnuana:KíivcBmZoibp.r.ivýlanatnefNnimoatéperevmonlmrdtnojžooaveescbahtnintíoéě
nmdZkPiuoptřksekiůoríulsséimotovebabbnynpsltooařyvauheecšzovneeevínmaíiabtbnoepudbizřl,edpíoezekpsnpčadttendiiečonfinsrskěoteoasncziitíihdnncoocíh"dihkdhnpooeaéořnvžetaiparnnrpicdoorjiavondvjévíezekncvnpůithřiluíkj.pčsljiboáeneunyz"ůaopdedi(mčpndincoonoivipdsěsoettdrnnrtnuíáučéht,eooontrsioeondpcobyoiydvdbkeiponandotze,vunei.kmndznenayaziznndocaohimkldeueenmdnaetňntootvpaadrctoaív)sskd.uyutZsevtáčzéznnmoinsokatlvim,é,
MD dvZonnapálavodrsyztíincáZhsílpsřekidannzéýacvZhádaiěnnnacílidýpezrntoaůd.řuekšteůnía
bezpečnostních incidentů jsou povinni zaměstnanci zohlednit
služeb V rámci tak aby se pravděpodobnost nebo
snížila
SHROMAŽĎOVÁNÍ DÚKAZŮ Knpiıøın 5
V rIáImcvppizpveřlvřeeššalešdektádkatenšaeřtrýttreomnénnnuiííeembvbpVbuoeyryozážžzrpzváápeepndřdřčžííaaínimsnnsomtitoésuuuutpppnnřndpmieíiortdcotsophhptivprosuoriaypzuna)cnncc,oéiíoadvvddennmlnoíiíotkknůgkuiůyůmjsmmsetroznvváuettoaooabbcřdslliimayaissssntttpiiyiéřssembtbtdeůreéaázzmttppůoveeřeččpvinnoeoopuSsssozvttvvéeiiié,npsvsnpoppiorvsr:váoěávěuvřělřěe.aendný(uýmZmáSšzšepnertatařřmveeiyndnílímypm,oidinlncdéciahidnadejeýnínmtctůiíů
MD Příloha BPI č. 4: Pravidla pro provozovatele
26/27
I _ _~Ťfl__ìì`,»
V_ _.,
/V zl'
Ĺ
.
nl' I nastavit na vyžádání detailnější logování dle požadavků pracovníků v oblasti bezpečnosti
pověřených šetřením íncidentů, pokud to negativně neovlìvní provoz Systému,
I předat pracovníkům V oblasti bezpečnosti pověřeným šetřením incidentů veškeré další
požadované dostupné infomıace o konfiguraci a provozu systémů ve Své správě.
ČÁST X. x‹ N M NÍ I-ıx KONTINUITY ČINNOSTÍ
Podrobněji jsou požadavky na havarijní plány popsány v příloze č. 9, na řízení incídentů a
problémů pak v přílohách č. 10 a ll.
ČÁST XI. SOULAD S POŽADAVKY
Administrátoři systémů a Zařízení jsou povinní dodržovat obecně závazné právní předpisy.
MD Administrátoři jsou povinni dodržovat pravidla a bezpečnostní opatření definovaná intemí
bezpečnostní dokumentací MD.
ČÁST XII. PŘECHODNÁ USTANOVENÍ
Do doby zajištění technických prostředků a podmínek pro dodržování pravidel pro provozovatele
je nutné postupovat v co největší možné míře souladu s touto přílohou BPI MD.
MD Příloha BPI č. 4: Pravidla pro provozovatele 27/27