SMLOUVA
Evidenční číslo smlouvy ČNB:00-000-00
SMLOUVA
o dodávce Entrust nShield Connect XC Mid včetně poskytování podpory
uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, mezi:
115 03 Praha 1
zastoupenou: Ing. Xxxxxxx Xxxxxxxxx, ředitelem sekce informatiky
a
Xxx. Xxxxxxx Xxxxxxxx, ředitelem sekce správní
(dále jen „objednatel“)
a
…..
zapsaná v obchodním rejstříku vedeném ………….oddíl .., vložka …
sídlo: …
IČO: ……
DIČ: ……
zastoupení: ……………….
č. bank. účtu: ………/…. (účet je zveřejněn podle § 98 zákona o DPH)
Část A
Upgrade stávajícího systému pro QSCD a poskytování související podpory
Předmět smlouvy
Předmětem této smlouvy je povinnost zhotovitele:
provést v prostředí objednatele upgrade technických i programových prostředků formou náhrady současných 2 ks HSM (Hardware Security Modul) appliancí Entrust nShield Connect 1500+ dodáním nových 2 ks Entrust nShield Connect XC Mid (dále jen „HSM moduly“), včetně instalace, implementace a konfigurace v prostředí objednatele tak, aby nově dodané HSM moduly splňovaly po implementaci požadavky na QSCD (Qualified Seal Creation Device) zařízení,
zajistit, aby na nově dodané HSM moduly kvalifikovaný poskytovatel služeb vytvářejících důvěru vydal certifikáty, které budou použity pro vnitřní službu kvalifikované pečeti ve standardním systémovém prostředí objednatele,
pro účely a po dobu testování před vlastním upgrade vytvořit ověřovací testovací prostředí na modulech nově dodaných nebo ekvivalentních (shodné konfigurace) a v případech, kde je to možné, provést migraci stávajících klíčů a certifikátů,
vypracovat realizační studii a projektovou dokumentaci skutečného stavu implementace a úprav HSM modulů a navazujícího software,
zaškolit max. 6 odborných pracovníků objednatele,
zajistit zpětný odběr stávajících HSM modulů dle specifikace uvedené v příloze č. 4 této smlouvy, bodě „1.8 HSM moduly“ s omezením na tři základní licence na modul (dále jen „stávající HSM moduly“) (Ustanovení bude v souladu s bodem 5.5 Zadávací dokumentace případně vypuštěno, a to v návaznosti na nabídku vybraného dodavatele)
(dále také jako „dílo“).
Dílo musí splňovat funkční požadavky uvedené v příloze č. 4 smlouvy. Dílo musí být realizováno v souladu s návrhem technického řešení obsaženým v příloze č. 6.
Dílo bude realizováno v následujících etapách:
První etapa zahrnuje vypracování realizační studie zhotovitelem, dle vzoru realizační studie uvedeném v příloze č. 8, která bude obsahovat veškeré informace nezbytné pro implementaci nově dodaných technických a programových prostředků do prostředí objednatele, postup upgrade a migrace současných HSM modulů objednatele na nově dodané HSM moduly včetně mapování funkčních požadavků a vlastností uvedených v příloze č. 4 tak, aby byla prokázána jejich realizovatelnost, a dále pak popis režimu provozní podpory.
Druhá etapa (testovací provoz) zahrnuje:
dodávku technických a programových prostředků podle specifikace uvedené v příloze č. 1 a v souladu s akceptovanou realizační studií (viz 1. etapa),
vytvoření dedikovaného testovacího prostředí na zhotovitelem dodaném (novém nebo ekvivalentním) HSM modulu v QSCD režimu. Na toto testovací prostředí budou napojeny vybrané informační systémy objednatele, resp. taktéž jejich testovací verze (testovat se budou vždy zástupci technologie používané na serverech objednatele).
Následovat bude testovací provoz v délce 2 týdnů od okamžiku zprovoznění testovacího prostředí, zahrnující posouzení souladu navrhovaného řešení se zadáním podle testovacích scénářů, ukázky základních operací s novým HSM v QSCD režimu.
Součástí plnění v této etapě je i dodání či zpřístupnění dokumentace výrobce technických prostředků a programových prostředků.
Třetí etapa (přechod do ostrého provozu) zahrnuje:
instalaci a konfiguraci všech nově dodaných technických a programových prostředků (viz 2. etapa) v provozním prostředí;
zaškolení (max. 6 odborných zaměstnanců objednatele) v délce, kterou určí zhotovitel tak, aby zaměstnanci byli zaškoleni v rozsahu dle přílohy č. 2;
migraci provozního prostředí stávajících prostředků na nově dodané technické a programové prostředky tak, aby došlo k vytvoření provozního prostředí nových HSM modulů v QSCD režimu a v konfiguraci pro jejich vysokou dostupnost, asistence při provedení instalace a úpravách programového vybavení na všechny aplikační servery dle přílohy č. 3 a migraci dat dle přílohy č. 2 a přílohy č. 4 pro stávající aplikace objednatele. Příslušné činnosti zajišťuje zhotovitel za asistence a součinnosti pracovníků objednatele;
etapa dále zahrnuje vytvoření nových certifikátů pro kvalifikovanou pečeť, které pořizuje objednatel, tj. budou ji realizovat pracovníci objednatele za asistence zhotovitele v místě plnění.
Po kompletní konfiguraci napojení stávajících informačních systémů objednatele na upravené HSM moduly bude proveden zkušební provoz v délce 2 týdnů, během kterého bude ověřeno, zda dodané řešení splňuje veškeré požadavky objednatele uvedené v příloze č. 4, a bude provedeno měření významných provozních stavů dodaného řešení a případně návrh optimalizace.
Čtvrtá etapa zahrnuje vypracování projektové dokumentace, v níž bude zachycen popis skutečného stavu implementace nových HSM modulů v QSCD režimu a provozních postupů a jejíž součástí bude i aktualizace současného havarijního plánu. Seznam požadované dokumentace je uveden v příloze č. 2. Xxxxxxxxxx je povinen předat objednateli projektovou dokumentaci v elektronické podobě ve formátu MS Word 2010 a vyšší (případně PDF), včetně dokumentace všech verzí software, resp. firmware.
Činnosti uvedené výše u jednotlivých etap jsou podrobněji popsány v příloze č. 4.
Zhotovitel se dále zavazuje dodávat objednateli na základě jeho objednávek další dodatečné technické a programové prostředky, a to za podmínek stanovených v rámci čl. VI této smlouvy.
Zhotovitel se zavazuje poskytovat pro stávající i nově dodané technické a programové prostředky provozní podporu a další činnosti dle čl. V této smlouvy.
Zhotovitel prohlašuje, že dodané technické prostředky budou nové a nepoužité (maximálně z továrny zahořelé z výroby), popř. zapnuté pro ověření funkčnosti v rámci případné kompletace prostředků zhotovitelem před dodáním.
8. Dílo bude prováděno v pracovní dny v době od 8.00 hod. do 17.00 hod., nedohodnou-li se smluvní strany jinak.
9. Místem plnění budou prostory výpočetního střediska v objektech objednatele na adrese:
Praha 1, Senovážná xx. 0,
Praha 5, Strojírenská 175.
10. K technickým ani programovým prostředkům nebude poskytován vzdálený přístup.
11. Objednatel se zavazuje za poskytnutá plnění uhradit ceny dle čl. III této smlouvy.
Lhůty, způsob předání díla
Objednatel převezme dílo jako celek pouze tehdy, pokud:
- byly odsouhlaseny všechny dílčí etapy na základě dílčích akceptačních protokolů, jak je stanoveno dále v tomto článku, a případné vady byly odstraněny,
- zhotovitel dodal kompletní řešení prosté vad a včetně požadované dokumentace,
- zhotovitel poskytl veškeré potřebné licence pro provoz řešení,
- zhotovitel předal v elektronické podobě na sjednaném datovém médiu (např. CD, DVD, USB Flash disk) veškeré podklady a dokumenty potřebné ke správě a údržbě díla.
Převzetí díla jako celku bude uskutečněno podpisem závěrečného akceptačního protokolu, a to do 5 pracovních dnů od ukončení čtvrté etapy. Tím bude plnění předáno objednateli k běžnému provoznímu využití. Ukončení každé etapy stvrdí pověřené osoby smluvních stran podpisem dílčího akceptačního protokolu.
Smluvní strany vzájemně dohodly pro jednotlivé etapy dle čl. I odst. 3 této smlouvy následující lhůty:
zhotovitel předá objednateli realizační studii do 10 týdnů od obdržení výzvy k zahájení plnění. Tato doba zahrnuje i připomínková kola objednatele v délce nejvýše 1 týden pro každé připomínkové kolo (očekávají se nejméně 2 připomínková kola s tím, že objednatel vznese připomínky vždy nejpozději do 5 pracovních dnů od obdržení návrhu realizační studie k případným připomínkám). Objednatel předá zhotoviteli písemnou výzvu k zahájení plnění nejpozději do 3 měsíců od uzavření této smlouvy na mailovou adresu pověřené osoby zhotovitele;
druhá etapa bude ukončena nejpozději do 22 týdnů od obdržení výzvy k zahájení plnění. Testovací provoz v délce 2 týdnů bude realizován jako poslední činnost druhé etapy;
třetí etapa bude zhotovitelem dokončena nejpozději do 34 týdnů od obdržení výzvy k zahájení plnění. Zkušební provoz v délce 2 týdnů bude probíhat po kompletní konfiguraci a migraci. V posledním týdnu zkušebního provozu bude provedeno vyhodnocení, na jehož základě zhotovitel vypracuje návrh případné optimalizace. Termíny zaškolení odborných zaměstnanců objednatele dohodnou smluvní strany podle realizační studie, zaškolení musí proběhnout po instalaci a konfiguraci nově dodaných technických a programových prostředků;
čtvrtá etapa zahrnující dokumentaci specifikovanou v příloze č. 2 bude ukončena do 39 týdnů od obdržení výzvy k zahájení plnění. Tato doba zahrnuje i připomínková kola objednatele v délce nejvýše 2 týdnů pro každé připomínkové kolo (očekávají se nejméně 2 připomínková kola s tím, že objednatel vznese připomínky vždy nejpozději do 5 pracovních dnů od obdržení návrhu dokumentace k případným připomínkám).
Každá etapa bude považována za ukončenou pouze tehdy, pokud bude plnění prosté vad, nerozhodne-li se objednatel přijmout předmět akceptace s výhradami. V takovém případě budou jednotlivé výhrady zaznamenány v dílčím akceptačním protokolu a zhotovitel je oprávněn pokračovat v navazující etapě. Pokud objednatel přijme předmět akceptace s výhradami, musí být vady odstraněny do termínu uvedeného v dílčím akceptačním protokolu.
Akceptaci s výhradami nelze provést, pokud existuje alespoň 1 podstatná vada implementovaného díla. Podstatné vady implementovaného díla jsou vady, které způsobují tak závažné problémy, že objednatel nemůže dílo nebo jeho klíčovou část používat, ovládat nebo konfigurovat. Zhotovitel není oprávněn pokračovat v navazující etapě, dokud nebudou podstatné vady odstraněny a objednatel předmět prací neodsouhlasí bez výhrad.
K akceptačnímu protokolu vyhotovenému zhotovitelem vyjádří objednatel své stanovisko vždy nejpozději do 5 pracovních dnů od jeho obdržení. Pokud tak neučiní, má se za to, že s uvedeným závěrem souhlasí.
Objednatel se zavazuje umožnit zhotoviteli vykládku a úschovu technických prostředků v prostorách objednatele určených k instalaci v termínu, o kterém bude zhotovitelem zpraven nejméně tři pracovní dny předem.
Objednatel převezme technické prostředky do úschovy a zajistí jejich bezpečné uskladnění do zahájení instalace.
Objednatel si vyhrazuje možnost prodloužit lhůtu(y) uvedenou(é) v tomto článku, a to přiměřeně okolnostem, na základě písemné a odůvodněné žádosti zhotovitele, ve které zhotovitel doloží, že objektivně nemůže pokračovat v plnění dle této smlouvy z důvodu neposkytnutí povinné a nezbytné součinnosti objednatelem, nebo z důvodu skutečností stojících na straně zhotovitele, které ani zhotovitel jednající s náležitou péčí nemohl předvídat a které sám nezpůsobil (včetně např. výpadku či zdržení v dodavatelsko-odběratelském řetězci, výpadku v pracovní síle zhotovitele z důvodu opatření uložených orgány veřejné moci, nikoli však v důsledku protiprávního jednání zhotovitele, zdržení v plnění jiných smluvních partnerů objednatele, kterého se plnění dle této smlouvy dotýká a které nebylo způsobeno objednatelem). Žádost zhotovitele dle tohoto odstavce musí být objednateli doručena v dostatečném předstihu před uplynutím lhůt(y) dle tohoto článku a musí obsahovat i návrh jejich prodloužení, ten však není pro objednatele závazný. Úprava lhůt(y) bude provedena formou dodatku ke smlouvě.
Cena plnění a platební podmínky
(dodavatel ceny nevyplňuje, bude doplněno podle nabídky vybraného dodavatele při uzavření smlouvy)
Ceny plnění uvedené v odst. 2 až 5 tohoto článku byly stanoveny dohodou smluvních stran v úrovni bez DPH a zahrnují veškeré náklady zhotovitele spojené s plněním podle této smlouvy.
Cena díla činí celkem …………. Kč, z toho cena zaškolení dle čl. I odst. 1 písm. e) činí …………. Kč. Podrobnější rozpis ceny je obsažen v příloze č. 7 smlouvy.
Cena za plnění na výzvu podle čl. V odst. 5 této smlouvy bude stanovena jako součin počtu skutečně odpracovaných hodin a hodinové sazby, která činí …………. Kč bez DPH. K této ceně bude připočtena cena za výjezd (cena zahrnuje náklady na cestu tam a zpět a ztrátu času na cestě), která činí bez DPH …………. Kč.
Paušální cena za podporu nově dodaných technických a programových prostředků podle čl. V této smlouvy činí měsíčně …………. Kč. V případě dalších dodávek technických a programových prostředků může být paušální cena za provozní podporu na základě dohody smluvních stran zvýšena nejvýše o 25 % z ceny dodávky. Zvýšení ceny podpory bude provedeno dodatkem ke smlouvě.
Paušální cena za podporu stávajících technických a programových prostředků podle čl. V této smlouvy činí měsíčně …………. Kč.
Ceny jednotlivých komponent v případě dalších dodávek technických a programových prostředků jsou stanoveny v příloze č. 7.
Ceny zahrnují veškeré náklady zhotovitele na realizaci předmětu plnění. K cenám bude účtována DPH v sazbě platné v den uskutečnění příslušného zdanitelného plnění.
Daňový doklad na cenu díla dle odst. 2 tohoto článku je zhotovitel oprávněn vystavit nejdříve v den podpisu závěrečného akceptačního protokolu o předání a převzetí díla.
Cena za plnění na výzvu podle odst. 3 tohoto článku bude hrazena na základě daňového dokladu vystaveného nejdříve po poskytnutí služby. Přílohou daňového dokladu bude i objednatelem odsouhlasený výkaz práce.
Paušální cena podle odst. 4 a odst. 5 tohoto článku bude hrazena měsíčně na základě daňového dokladu vystaveného nejdříve ke dni uskutečnění zdanitelného plnění, kterým je poslední den měsíce, ve kterém bylo příslušné plnění poskytováno. Paušální cena podpory zahrnuje veškeré náklady (včetně náhradních dílů, práce, dopravného apod.) zhotovitele spojené s jejím poskytováním.
Doklady k úhradě (fakturu) zašle zhotovitel elektronicky jako přílohu e-mailové zprávy na adresu xxxxxxx@xxx.xx ve formátu ISDOC. Pokud není možné vytvořit doklad ve formátu ISDOC, je možné zasílat jej ve formátu PDF. V jedné e-mailové zprávě smí být pouze jeden doklad k úhradě. Mimo vlastní doklad k úhradě může být přílohou e‑mailové zprávy jedna až sedm příloh k dokladu ve formátech PDF, DOC, DOCX, XLS, XLSX. Přijaty budou i doklady k úhradě v jiném formátu, který bude v souladu s evropským standardem elektronické faktury. Nebude-li možné zaslat doklad k úhradě elektronicky, zašle jej zhotovitel v analogové formě na adresu:
Česká národní banka
sekce rozpočtu a účetnictví
odbor účetnictví
Na Příkopě 28
115 03 Praha
Doklad k úhradě bude obsahovat údaje podle § 435 občanského zákoníku a bankovní účet, na který má být placeno, a který je uveden v záhlaví této smlouvy nebo který byl později aktualizován zhotovitelem (dále jen „určený účet“). Daňový doklad bude nadto obsahovat náležitosti stanovené v zákoně o dani z přidané hodnoty. Nezbytnou náležitostí každého dokladu je také číslo této smlouvy (ve formátu ISDOC v poli ID ve skupině Contract References). Pokud doklad bude postrádat některou ze stanovených náležitostí nebo bude obsahovat chybné údaje, je objednatel oprávněn jej vrátit zhotoviteli, a to až do lhůty splatnosti. Nová lhůta splatnosti začíná běžet dnem doručení bezvadného dokladu.
V případě, že bude v dokladu k úhradě uveden jiný než určený účet, je pověřený pracovník zhotovitele povinen na základě výzvy objednatele sdělit na e-mailovou adresu, ze které byla výzva odeslána, zda má být zaplaceno na bankovní účet uvedený v dokladu, nebo na určený účet. V tomto případě se doklad k úhradě nevrací s tím, že lhůta splatnosti začíná běžet až dnem doručení sdělení zhotovitele podle předchozí věty.
Splatnost dokladů k úhradě je 14 dnů od doručení objednateli. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu objednatele ve prospěch zhotovitele.
Výše paušální ceny za období kratší, než je sjednané období, se vypočte jako alikvotní část sjednané ceny.
Ke konci kalendářního roku, nejdéle však do 31. 12., je zhotovitel povinen písemně sdělit objednateli, jakou část z uhrazené roční ceny za podporu programových prostředků tvoří cena nových verzí představující jejich technické zhodnocení.
Zhotovitel je oprávněn navrhnout změnu hodinové sazby dle odst. 3 a paušální ceny dle odst. 4 tohoto článku v návaznosti na vývoj indexu cen tržních služeb, stejné období předchozího roku = 100, konkrétně index „Tržní služby celkem“ sloupec „Průměr od počátku roku“, a to průměr za předchozí kalendářní rok, který vyhlašuje Český statistický úřad. Ceny mohou být zvýšeny maximálně o částku odpovídající předmětné roční inflaci. Úprava ceny bude provedena formou dodatku ke smlouvě a nabývá účinnosti dnem účinnosti dodatku. První úpravu cen může zhotovitel navrhnout po uplynutí dvou let od zahájení poskytování podpory.
Smluvní strany se dohodly, že objednatel je oprávněn započíst jakoukoli svou peněžitou pohledávku za zhotovitelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce zhotovitele za objednatelem, ať splatné či nesplatné.
Další povinnosti smluvních stran, pověření zaměstnanci
Objednatel se zavazuje vytvořit zhotoviteli k instalaci potřebné podmínky, zejména:
zajistit provozní odstávky aplikací dotčených migrací dat s tím, že v rámci geografického clusteru bude v pracovní době možná odstávka vždy jen jednoho serveru clusteru. Odstávky celého clusteru je možné provádět jen během víkendu. Takovou odstávku je nutné avizovat nejméně 10 pracovních dnů předem. Maximální přípustné doby provozních odstávek jsou uvedeny v příloze č. 4, část Provozní odstávky;
zajistit potřebné rekonfigurace technických a programových systémů dotčených přechodem na dodávané prostředky za podmínky, že neohrozí stávající provoz;
přidělit IP adresy pro dodávané prostředky;
zajistit přístup odborných zaměstnanců zhotovitele na příslušná pracoviště objednatele.
Pověřenými zaměstnanci pro:
technická jednání a k předání a převzetí plnění jsou:
- za objednatele: (bude doplněno po podpisu smlouvy)
- za zhotovitele: …………., tel.: ………., email: …………(dodavatel doplní libovolný počet osob)
jednání o obchodních otázkách a změnách smlouvy:
- za objednatele: (bude doplněno po podpisu smlouvy)
- za zhotovitele: …………., tel.: ………., email: …………(dodavatel doplní libovolný počet osob)
řešení problémů v rámci provozní podpory (právo zadávat požadavky):
- za objednatele: (bude doplněno po podpisu smlouvy)
- za zhotovitele: …………., tel.: ………., email: …………(dodavatel doplní libovolný počet osob)
Zhotovitel prohlašuje, že jím dodané technické i programové prostředky, které jsou předmětem plnění podle této smlouvy, pochází od certifikovaného/autorizovaného distributora a poskytovatele technické podpory pro Českou republiku („ČR“) a jsou určeny pro prodej v ČR. Zhotovitel je po dobu účinnosti této smlouvy povinen na požádání objednateli tuto skutečnost doložit, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
4. Xxxxxxxxxx je povinen zajistit, aby jeho pracovníci, kteří se budou podílet na plnění této smlouvy, splňovali kvalifikační kritéria, která objednatel požadoval v kvalifikačních požadavcích zadávacího řízení na předmět této smlouvy (bod 7.3.1 až 7.3.4. zadávací dokumentace k veřejné zakázce s názvem „Upgrade HSM modulů Entrust“). Zhotovitel je po dobu účinnosti této smlouvy povinen na požádání kvalifikaci jednotlivých osob objednateli doložit, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
5. V případě poskytování služeb prostřednictvím poddodavatele platí všechna relevantní ustanovení tohoto článku také pro poddodavatele a jeho pracovníky, kteří se budou na plnění smlouvy podílet. V případě, že zhotovitel splnil některý z požadavků stanovených objednatelem v zadávací dokumentaci zadávacího řízení na předmět této smlouvy prostřednictvím poddodavatele, je povinen v případě změny tohoto poddodavatele objednatele do 3 pracovních dnů od této změny, Zhotovitel je na požádání objednatele povinen prokázat, že nový poddodavatel tento požadavek splňuje, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
6. Zhotovitel musí zajistit, že HSM zařízení objednatele bude provozováno v režimu QSCD. HSM nebo jejich součásti musí být zároveň uvedeny na seznamu kvalifikovaných prostředků - xxxxx://xxxxxxxxxx.xx.xxxxxx.xx/xxxx/xxxxxxxxxxxx-xxxx/#/xxxxxx/xxxxxx/xxxx/XXXX_XXXX
a zhotovitel musí být schopen zajistit dodání certifikátů pro kvalifikovanou pečeť pro tato zařízení. Tuto povinnost musí zhotovitel splňovat po celou dobu účinnosti smlouvy a je povinen ji na požádání objednateli prokázat, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
7. Objednatel si vyhrazuje právo ověřit si skutečnosti dle odst. 3 až 6 tohoto článku. Objednatel si dále vyhrazuje právo prověřovat schopnost zhotovitele dostát lhůtám definovaným v článku V odst. 3 (např. existence záložních HSM modulů, schopnost dopravit potřebná zařízení v daných časových lhůtách do ČNB apod.).
Provozní podpora
Zhotovitel poskytuje objednateli provozní podporu pro stávající technické a programové prostředky, a to ode dne následujícího po podpisu akceptačního protokolu 1. etapy do dne podpisu akceptačního protokolu 3 etapy.
Zhotovitel poskytuje objednateli provozní podporu pro nově dodané technické a programové prostředky, a to ode dne následujícího po dni podpisu akceptačního protokolu 3. etapy.
Podmínky pro provozní podporu stávajících i nově dodaných technických a programových prostředků, klasifikace vad (kritické/nekritické) a navazující požadavky a lhůty jsou následující:
Pokud uskutečnění servisního zásahu bude vyžadovat provozní odstávku, musí zhotovitel dodržet maximálně stanovené časy odstávek dle přílohy č. 4 - požadavek „Provozní odstávky“.
Odstraňování kritických závad technických a programových prostředků:
Za kritickou závadu se považuje taková závada, kdy na úrovni operačního systému serveru běžícího v libovolné lokalitě:
nejsou dostupné kryptografické klíče nebo s nimi není možné realizovat digitální podpis a dešifrování (ověření podpisu);
není možné generovat klíčový pár a žádost o certifikát;
není dostupné ani jedno HSM a není to způsobeno závadou na komunikační trase zajišťované objednatelem.
Mezi kritické závady dále patří také zásadní výkonnostní závady, v důsledku nichž nejsou splněny ani jedním HSM podmínky stanovené v rámci přílohy č. 4 - požadavek „Výkonnost“.
Řešení kritické závady musí být zahájeno nejpozději do 2 hodin a závada musí být odstraněna do 24 hodin od nahlášení závady.
Odstraňování nekritických závad technických prostředků:
Za nekritickou závadu se považuje taková závada dodaných technických prostředků, která neohrožuje vlastní provoz těchto prostředků, zejména:
závady na managementu HSM;
výpadek jedné z redundantních komponent HSM.
Řešení nekritické závady musí být zahájeno nejpozději do 4 hodin a závada musí být odstraněna nejpozději do 5 pracovních dní od nahlášení závady.
Při vzniku nekritické závady programových prostředků bude zahájeno řešení závady nejpozději do 2 pracovních dnů po jejím ohlášení zhotoviteli. Na jejím odstranění musí zhotovitel pracovat bez zbytečného odkladu a přerušení a musí využít všech prostředků k dosažení nápravy.
Odstranění nekritické závady musí být dokončeno nejpozději do 10 pracovních dnů od jejího nahlášení. Dohodou smluvních stran může být tato lhůta prodloužena v případě, kdy zhotovitel prokáže objektivní důvody, které mu brání v odstranění vady.
Součástí podpory předmětných technických a programových prostředků je i jejich provozní údržba. Provozní údržba technických a programových prostředků zahrnuje 1x za pololetí provedení kontroly funkce všech HSM modulů včetně kontroly logů na zařízeních samotných a na klientech, provedení analýzy a naplánování případného zásahu.
Zhotovitel bude na výzvu objednatele poskytovat další činnosti, zejména se jedná o asistenci při generování párů klíčů, konzultace k provozním a vývojovým činnostem, konzultace k plánovaným změnám a jejich realizace, implementace opravných a nových verzí v prostředí objednatele a aktualizaci konfigurace a dokumentace, pokud na ni bude mít implementace vliv.
Zhotovitel v rámci zajištění provozní podpory poskytne nové a opravné verze všech programových prostředků. Součástí podpory je také informování objednatele o nových nebo opravných verzích.
Pokud závadu zjistí zhotovitel, oznámí ji neprodleně objednateli a další postup při jejím odstraňování se řídí ustanoveními tohoto článku s tím, že stanovené lhůty běží od oznámení závady objednateli.
Zhotovitel je srozuměn s tím, že veškerá komunikace při hlášení a řešení závad bude mezi objednatelem a pracovníky zhotovitele probíhat v českém jazyce. Při eskalaci řešení problémů k výrobci technických a programových prostředků je akceptována i komunikace v anglickém jazyce.
Služby poskytované zhotovitelem musí vyhovovat technickým specifikacím a požadavkům výrobce příslušného technického prostředku.
Požadavky na odstranění závad a na ostatní služby podle této smlouvy budou hlášeny na tel: ……………… (doplní dodavatel), nebo e-mailem na mailovou adresu zhotovitele: ……………………… (doplní dodavatel, případně dodavatel může doplnit další způsob nahlašování). Přijetí požadavku na servisní zásah je zhotovitel povinen potvrdit e-mailem na adresu osob uvedených v čl. IV odst. 2 písm. c), a to nejpozději do 2 hodin od nahlášení požadavku.
O každém provedeném servisním zásahu nebo údržbě vyhotoví pracovník zhotovitele zápis o provedení práce, který stvrdí svým podpisem přejímající pracovník objednatele.
Zhotovitel souhlasí s tím, že pokud nebude možné na vadné komponentě prokazatelně bezpečně smazat data objednatele, nemůže být tato komponenta předána zhotoviteli k provedení opravy. Oprava v tomto případě musí proběhnout v prostorech objednatele.
Zhotovitel souhlasí s tím, že při výměně vadného média, nebo komponenty, na které jsou/byla data objednatele a nelze prokazatelně tato data bezpečně vymazat (typicky paměťová média, čipové karty apod.), nebudou tato média nebo komponenty po výměně vráceny zhotoviteli a objednatel zajistí jejich odpovídající mechanickou likvidaci (viz též požadavek uvedený v příloze č. 4 - „Opravy HW“).
Odstranění závady zahrnuje jak výměnu nebo opravu vadného technického nebo programového prostředku, tak zprovoznění nového nebo opraveného prostředku včetně jeho úplné konfigurace.
Článek VI
Dodatečné technické a programové prostředky
Zhotovitel se zavazuje dodat či dodávat objednateli na základě jeho objednávky nebo jednotlivých objednávek další dodatečné technické a programové prostředky specifikované v příloze č. 1 a č. 7 této smlouvy, a to až do maximálního množství uvedeného v příloze č. 7 této smlouvy. Zhotovitel je povinen tyto technické a programové prostředky objednateli dodat vždy do 30 kalendářních dnů od doručení objednávky. Objednatel si vyhrazuje dodání těchto technických a programových prostředků vůbec nepožadovat, případně požadovat dodávku pouze některých, případně dodání menšího množství.
Objednávky budou předkládány prostřednictvím elektronické pošty na e-maily pověřených osob zhotovitele uvedené v čl. IV odst. 2 písm. b) této smlouvy.
Převzetí dodávky objednatel potvrdí poté, co ověří její funkčnost a kompatibilitu. Potvrzení o převzetí plnění vystaví kterákoliv z pověřených osob objednatele dle čl. IV odst. 2 a následující pracovní den je prostřednictvím elektronické pošty zašle na e-maily pověřených osob zhotovitele uvedené v čl. IV odst. 2. Objednatel ověří funkčnost a kompatibilitu do 10 pracovních dnů od podpisu dodacího listu objednatelem. Objednatel je oprávněn akceptovat plnění bez výhrad také tím, že do 12 dnů od podpisu dodacího listu objednatelem neodešle potvrzení o převzetí plnění nebo oznámení o tom, že plnění má vady.
Provozní podpora dle čl. V se vztahuje i na technické a programové prostředky dodané dle tohoto článku.
Smluvní pokuty, úrok z prodlení
V případě prodlení zhotovitele má objednatel právo požadovat smluvní pokutu:
ve výši 2 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 2 písm. a) této smlouvy;
ve výši 2 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 2 písm. b) této smlouvy;
ve výši 10 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 2 písm. c) této smlouvy;
ve výši 2 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 2 písm. d) této smlouvy.
V případě prodlení zhotovitele má objednatel právo požadovat smluvní pokutu:
a) ve výši 20 000 Kč za každou hodinu prodlení ve lhůtě pro zahájení řešení kritické závady dle čl. V odst. 3 písm. b) této smlouvy;
b) ve výši 20 000 Kč za každou hodinu prodlení ve lhůtě pro odstranění kritické závady dle čl. V odst. 3 písm. b) této smlouvy;
c) ve výši 1 000 Kč za každou hodinu prodlení ve lhůtě pro zahájení řešení nekritické vady technických prostředků dle čl. V odst. 3 písm. c) této smlouvy;
d) ve výši 1 000 Kč za každý pracovní den prodlení ve lhůtě pro odstranění nekritické vady technických prostředků dle čl. V odst. 3 písm. c) této smlouvy;
e) ve výši 1 000 Kč za každý pracovní den prodlení ve lhůtě pro zahájení řešení nekritické závady programových prostředků dle čl. V odst. 3 písm. d) této smlouvy;
f) ve výši 1 000 Kč za každý pracovní den prodlení ve lhůtě pro odstranění nekritické závady programových prostředků dle čl. V odst. 3 písm. d) této smlouvy;
g) ve výši 2 000 Kč za každou hodinu prodlení ve lhůtě pro potvrzení přijetí požadavku na servisní zásah dle čl. V odst. 10 této smlouvy.
V případě, že se po dobu 12 měsíců ode dne předání díla prokáže, že nebyly splněny některé z požadavků uvedených v příloze č. 4 („Striktně vyžadované funkce a vlastnosti“), jejichž splnění požadoval objednatel jako povinné (tzn. vlastnosti označené „musí“ „bude“), má objednatel právo požadovat smluvní pokutu ve výši 100 000 Kč za každý případ nedodržení takového požadavku. Tím není dotčeno právo na odstoupení od smlouvy ani na náhradu vzniklé škody.
V případě, že bude na zařízení v jedné lokalitě (počítáno pro každou lokalitu zvláště; všechny komponenty dodané do jedné lokality jsou počítány jako jedno zařízení) více závad než 10 za 12 měsíců, má objednatel právo požadovat smluvní pokutu ve výši 5 000 Kč za každý případ závady nad počet 10.
V případě prodlení zhotovitele ve lhůtě pro prokázání skutečností požadovaných objednatelem podle článku IV odst. 3 až 5 této smlouvy je objednatel oprávněn požadovat smluvní pokutu ve výši 1 000 Kč za každý den prodlení.
V případě prodlení zhotovitele ve lhůtě pro prokázání skutečností požadovaných objednatelem podle článku IV odst. 6 této smlouvy je objednatel oprávněn požadovat smluvní pokutu ve výši 3 % z celkové ceny podle článku III odst. 2 této smlouvy za každý započatý měsíc prodlení.
V případě porušení povinnosti zhotovitele dle čl. IX odst. 1 je objednatel oprávněn požadovat smluvní pokutu ve výši 50 000 Kč za každé jednotlivé porušení mlčenlivosti.
V případě porušení jakékoliv povinnosti zhotovitele dle čl. X je objednatel oprávněn požadovat smluvní pokutu ve výši 50 000 Kč za každé jednotlivé porušení.
V případě porušení kterékoli povinnosti stanovené v čl. XI odst. 1 až 3 této smlouvy je objednatel oprávněn účtovat zhotoviteli smluvní pokutu ve výši 100 000 Kč za každý případ porušení.
V případě prodlení zhotovitele v kterékoliv lhůtě dle čl. XI odst. 4 a 5 této smlouvy je objednatel oprávněn účtovat zhotoviteli smluvní pokutu ve výši 1 000 Kč za každý pracovní den prodlení.
Ujednáními o smluvní pokutě není dotčeno právo smluvních stran na náhradu škody.
V případě prodlení s uhrazením daňového dokladu zaplatí objednatel zhotoviteli úrok z prodlení podle předpisů občanského práva.
Článek VIII
Vlastnictví, nebezpečí škody na věci a licenční ujednání
Vlastnictví k technickým prostředkům dle této smlouvy přechází na objednatele dnem převzetí díla. Právo užívání programových prostředků nabývá objednatel ode dne jejich instalace.
Dnem převzetí nových technických prostředků objednatelem do úschovy přechází nebezpečí škody na těchto prostředcích na objednatele.
Zhotovitel poskytuje objednateli nevýhradní, nepřevoditelnou a časově i množstevně neomezenou licenci umožňující užívat předmětný SW pouze pro vnitřní potřebu objednatele. Odměna za poskytnutí licence je zahrnuta v ceně díla.
Objednatel není povinen dodané licence využít.
Součástí licence je příslušná dokumentace v elektronické podobě.
Zhotovitel prohlašuje, že práva, která touto smlouvou poskytuje, mu náleží bez jakéhokoliv omezení, a odpovídá za škodu, která by objednateli vznikla, pokud by toto prohlášení bylo nepravdivé.
Licence poskytnuté dle této smlouvy se vztahují i na veškeré poskytnuté aktualizace předmětného software (tj. update/upgrade/patch/hotfix atd.).
Mlčenlivost, bezpečnostní požadavky objednatele
Zhotovitel se zavazuje zajistit, že jeho pracovníci, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech skutečnostech, se kterými se u objednatele seznámí a které nejsou veřejně známy. Povinnost mlčenlivosti není časově omezena.
Zhotovitel se zavazuje v plném rozsahu dodržovat bezpečnostní požadavky objednatele, které jsou uvedeny v příloze č. 5 této smlouvy a požadavky kybernetické bezpečnosti vyplývající z čl. X této smlouvy.
Článek X
Kybernetická bezpečnost
1. Zhotovitel bere na vědomí, že objednatel je provozovatelem informačních systémů kritické informační infrastruktury dle ustanovení § 3 písm. c) zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů (dále jen „ZKB“) a provozovatelem významných informačních systémů dle ustanovení § 3 písm. e) ZKB, zejména informačních systémů ABO/ABO-K, CERTIS, SKD, KRZR a JERRS.
2. Zhotovitel je při plnění této smlouvy v postavení významného dodavatele ve smyslu § 2 písm. n) a § 8 odst. 1 písm. f) a odst. 2 vyhlášky č. 82/2018 Sb., bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů (dále jen „VKB“).
3. Xxxxxxxxxx bere na vědomí, že je v souladu s § 8 odst. 1 písm. b) VKB veden v seznamu významných dodavatelů objednatele.
4. Rozsah zapojení zhotovitele na zajištění bezpečnosti aktiv informačních systémů kritické informační infrastruktury a aktiv významných informačních systémů používaných v prostředí objednatele je určen předmětem této smlouvy.
5. Zhotovitel je při poskytování plnění oprávněn užívat data, předaná mu objednatelem za účelem plnění předmětu smlouvy či data za tímto účelem získaná, pouze v rozsahu nezbytném ke splnění smlouvy a pouze v souladu s touto smlouvou a příslušnými právními předpisy, tj. zejména ZKB a VKB.
6. Xxxxxxxxxx se zavazuje zajistit, aby jeho pracovníci či poddodavatelé zhotovitele a jejich pracovníci v plném rozsahu dodržovali obecná pravidla pro dodavatele v oblasti bezpečnosti IT uvedená v příloze č. 9 (dále jen „pravidla bezpečnosti“).
7. Xxxxxxxxxx se zavazuje při výkonu své činnosti včas a prokazatelně upozornit objednatele na zřejmou nevhodnost jeho příkazů či doporučení vztahujících se k pravidlům bezpečnosti, jejichž následkem může vzniknout újma nebo nesoulad s právními předpisy, a zajistit ve spolupráci s objednatelem náhradní způsob naplnění pravidel bezpečnosti, pokud stávající řešení přestalo být funkční a efektivní.
8. Zhotovitel je srozuměn s tím, že objednatel provádí v pravidelných intervalech hodnocení rizik v souvislosti s informačními systémy dle odst. 1 tohoto článku, kterých se týká poskytování plnění dle této smlouvy.
9. Xxxxxxxxxx se zavazuje informovat objednatele o tom, jakým způsobem řídí bezpečnostní rizika spojená s plněním předmětu této smlouvy a dále jaká jsou zbytková rizika související s plněním této smlouvy.
10. Dojde-li u zhotovitele k výskytu bezpečnostních incidentů vzniklých v souvislosti s plněním této smlouvy na informačních systémech, jichž se plnění dle této smlouvy týká, zavazuje se zhotovitel o těchto bezpečnostních incidentech bezodkladně informovat objednatele. Zhotovitel se dále zavazuje oznamovat objednateli bezodkladně neobvyklé chování informačních systémů objednatele.
11. Xxxxxxxxxx se zavazuje informovat objednatele o významné změně ovládání zhotovitele. Ovládáním se rozumí vliv, ovládání či řízení dle § 71 a násl. zákona č. 90/2012 Sb., o obchodních korporacích, ve znění pozdějších předpisů, či ekvivalentní postavení, a to do 5 pracovních dnů od uskutečnění této změny.
12. Zhotovitel se zavazuje informovat objednatele o změně vlastnictví či oprávnění nakládat se zásadními aktivy využívanými zhotovitelem k plnění této smlouvy, a to do 5 pracovních dnů od uskutečnění této změny.
13. Zhotovitel je povinen zajistit, aby byly v případě ukončení smlouvy veškerá data a informace získané či vzniklé v souvislosti s plněním této smlouvy likvidovány bezpečným způsobem, který zaručí, že nebude možné zrekonstruovat jednotlivé datové struktury, části dat a informací do podoby, jež by umožnila identifikovat obsah a zpracování nebo použití dat a/nebo informací na konkrétním nosiči dat. Xxxxxxxxxx je přitom povinen zajistit soulad postupu při likvidaci dat s přílohou č. 4 VKB. Zhotovitel je v případě ukončení smlouvy rovněž povinen předat objednateli čipové karty a přístupové údaje nezbytné pro správu zhotovitelem upgradovaného technického řešení HSM modulů, a to nejpozději v den ukončení smlouvy.
14. Dojde-li za dobu účinnosti této smlouvy ke změnám ZKB a/nebo VKB takového charakteru a rozsahu, že s nimi nebude smlouva v souladu, zavazují se smluvní strany uzavřít písemný dodatek k této smlouvě, jehož předmětem bude úprava či doplnění práv a povinností smluvních stran, a to bez zbytečného odkladu poté, co legislativní změny ZKB a/nebo VKB nabydou platnosti.
Článek XI
Další povinnosti zhotovitele
Zhotovitel potvrzuje, že ke dni účinnosti této smlouvy on ani jeho poddodavatelé nenaplňují definiční znaky subjektů uvedených v čl. 5k nařízení Rady (EU) 2022/576 ze dne 8 dubna 2022, kterým se mění nařízení (EU) č. 833/2014 o omezujících opatřeních vzhledem k činnosti Ruska destabilizujícím situaci na Ukrajině (dále také jako „nařízení č. 2022/576“) nebo subjektů uvedených v čl. 1h rozhodnutí Rady (SZBP) 2022/578 ze dne 8. dubna 2022, kterým se mění rozhodnutí 2014/512/SZBP o omezujících opatřeních vzhledem k činnostem Ruska destabilizujícím situaci na Ukrajině (dále jen „rozhodnutí 2022/578“), kterým je zakázáno zadat či plnit jakoukoli veřejnou zakázku nebo koncesní smlouvu ve smyslu v tomto ustanovení uvedeného nařízení či rozhodnutí. Subjekty naplňující definiční znaky subjektů uvedených v čl. 5k nařízení č. 2022/576 nebo subjektů uvedených v čl. 1h rozhodnutí 2022/578 budou dále označovány jako „určené subjekty“.
Xxxxxxxxxx dále potvrzuje, že ke dni účinnosti této smlouvy není osobou uvedenou v příloze I nařízení Rady (EU) č. 269/2014 ze dne 17. března 2014 o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění jeho změn (dále také jako „nařízení č. 269/2014“) nebo v příloze rozhodnutí Rady 2014/145/SZBP ze dne 17. března 2014 o omezujících opatřeních vzhledem k činnostem narušujícím nebo ohrožujícím územní celistvost, svrchovanost a nezávislost Ukrajiny, ve znění jeho změn (dále také jako „rozhodnutí 2014/145/SZBP“). Osoba uvedená v příloze I nařízení č. 269/2014 nebo v příloze rozhodnutí Rady 2014/145/SZBP bude dále označována jako „určená osoba“.
Zhotovitel se současně zavazuje, že určeným osobám dle předchozího odstavce (není-li jí sám) nebo v jejich prospěch nezpřístupní žádné finanční prostředky ani hospodářské zdroje získané v souvislosti s plněním dle této smlouvy, a to přímo ani nepřímo.
V případě, že by v průběhu účinnosti této smlouvy zhotovitel nebo jeho jakýkoliv poddodavatel naplnili definiční znaky určeného subjektu nebo se zhotovitel stal určenou osobou, je zhotovitel povinen o takové skutečnosti objednatele bez zbytečného odkladu, nejpozději do 2 pracovních dnů od nastání takové skutečnosti, písemně informovat. Vznikne-li objednateli v souvislosti s porušením této povinnosti jakákoliv škoda, je zhotovitel tuto škodu objednateli povinen v plné výši nahradit.
Dojde-li za dobu účinnosti této smlouvy ke změnám v kterémkoliv z výše uvedených nařízení Rady (EU) či rozhodnutí Rady nebo k přijetí jakékoliv jiné nové legislativy tak, že bude nezbytné dát tuto smlouvu s nařízením Rady (EU), rozhodnutím Rady nebo jinou novou legislativou do souladu, zavazují se smluvní strany uzavřít písemný dodatek k této smlouvě, jehož předmětem bude úprava či doplnění práv a povinností smluvních stran v rámci této smlouvy (sankční mechanismy či nové možnosti ukončení smlouvy z toho nevyjímaje), a to bez zbytečného odkladu, nejpozději do 15 pracovních dnů poté, co změny nařízení Rady (EU), rozhodnutí Rady či jiná nová legislativa nabydou platnosti, nedohodnou-li se smluvní strany jinak.
Článek XII
Odstoupení od smlouvy, výpověď
V případě, že některá ze smluvních stran podstatně poruší smluvní povinnost vyplývající pro ni z této smlouvy, je druhá smluvní strana oprávněna od smlouvy odstoupit. Objednatel je oprávněn odstoupit i od části smlouvy.
Xxxxxxxxxx bere na vědomí, že pro objednatele je nezbytné, aby veškeré dodané technické a programové prostředky splňovaly všechny požadavky/požadované funkce uvedené v příloze č. 4.
Za podstatné porušení smluvní povinnosti se považuje zejména, ale nejen:
- ze strany zhotovitele:
nesplnění kteréhokoli požadavku/požadované funkce uvedených v příloze č. 4,
prodlení zhotovitele s ukončením kterékoliv dílčí etapy dle čl. I odst. 3 písm. a) až d) této smlouvy po dobu delší než 30 kalendářních dnů,
případ, kdy se v rámci zkušebního provozu dle čl. I odst. 3 písm. c) této smlouvy vyskytnou takové vady implementovaného díla, které objednatel vyhodnotí jako podstatné a tyto nebudou odstraněny ani v určené dodatečné přiměřené lhůtě,
prodlení zhotovitele se zahájením prací na odstraňování kritické závady v rámci provozní podpory do 2 hodin od nahlášení podle čl. V této smlouvy,
prodlení zhotovitele se zahájením prací na odstraňování nekritické závady v rámci provozní podpory programových prostředků do 2 pracovních dnů od nahlášení podle čl. V této smlouvy,
případ, kdy zhotovitel nebude schopen v rámci implementace dodržet maximálně stanovené časy odstávek dle přílohy č. 4 - požadavek „Provozní odstávky“,
porušení kterékoliv povinnosti zhotovitele dle čl. IV odst. 3 až 7,
rozpor mezi licencemi uvedenými v příloze č. 1 a licencemi skutečně dodanými. Jedná se zejména o rozpory ve způsobu licencování nebo v jejich množství;
ze strany objednatele:
prodlení s úhradou dokladů k úhradě delší než 30 dnů.
Objednatel je dále oprávněn odstoupit od smlouvy v případě významné změny kontroly nad zhotovitelem dle čl. X odst. 11 nebo změny vlastnictví či oprávnění nakládat se zásadními aktivy využívanými zhotovitelem k plnění této smlouvy dle čl. X odst. 12 této smlouvy.
Objednatel je oprávněn odstoupit od této smlouvy, a to i v její jakékoliv části, také v případě, kdy na základě písemné informace od zhotovitele či z vlastní iniciativy shledá, že zhotovitel nebo jeho kterýkoliv poddodavatel naplnili definiční znaky určeného subjektu nebo zhotovitel se stane určenou osobou nebo zhotovitel neuzavře dodatek ke smlouvě ve smyslu čl. XI odst. 5 této smlouvy.
Smluvní strany si sjednávají, že objednatel je oprávněn zrušit tuto smlouvu zaplacením odstupného ve výši 50 000 Kč na účet zhotovitele, a to kdykoli do akceptace realizační studie [článek I odst. 3 písm. a)]. Zrušení smlouvy je účinné zaplacením sjednaného odstupného na bankovní účet zhotovitele. Zaplacením odstupného zanikají všechna práva a povinnosti obou smluvních stran vyplývající ze zrušené smlouvy s výjimkou závazku mlčenlivosti zhotovitele.
V případě odstoupení od smlouvy objednatelem před ukončením zkušebního provozu se zhotovitel zavazuje na své náklady uvést dotčené IS/aplikace do původního stavu a zajistit odvoz technických a programových prostředků, a to nejpozději do 30 dnů ode dne doručení oznámení o odstoupení od smlouvy.
Smluvní strany se dohodly, že objednatel je oprávněn kdykoliv v průběhu insolvenčního řízení zahájeného na majetek zhotovitele odstoupit od této smlouvy.
Odstoupení od smlouvy je účinné dnem doručení oznámení o odstoupení od smlouvy druhé smluvní straně.
Smlouva se v části týkající se podpory uzavírá na dobu neurčitou a lze ji vypovědět v 12 měsíční výpovědní lhůtě, která počíná běžet prvním dnem kalendářního měsíce následujícího po doručení písemné výpovědi druhé smluvní straně.
Objednatel je oprávněn vypovědět tuto smlouvu, a to i v její jakékoliv části, bez výpovědní doby v případě, kdy na základě písemné informace od zhotovitele či z vlastní iniciativy shledá, že zhotovitel nebo jeho kterýkoliv poddodavatel naplnili definiční znaky určeného subjektu nebo zhotovitel se stane určenou osobou nebo zhotovitel neuzavře dodatek ke smlouvě ve smyslu čl. XI odst. 5 této smlouvy. Tato výpověď je účinná dnem jejího doručení zhotoviteli.
Uveřejnění smlouvy a skutečně uhrazené ceny za plnění smlouvy
1. Xxxxxxxxxx si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy. Profilem objednatele je elektronický nástroj, prostřednictvím kterého objednatel, jako veřejný zadavatel dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“) uveřejňuje informace a dokumenty ke svým veřejným zakázkám způsobem, který umožňuje neomezený a přímý dálkový přístup, přičemž profilem objednatele v době uzavření této smlouvy je xxxxx://xxxx.xxx.xx/.
Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.
Uveřejňování bude prováděno dle ZZVZ a příslušného prováděcího předpisu k ZZVZ.
Část B
Odprodej stávajících HSM modulů
(tato část smlouvy se použije pouze v případě, že dodavatel využije možnosti zpětného odběru dle bodu 5.5 Zadávací dokumentace)
Článek XIV
Předmět plnění
Objednatel prodává zhotoviteli 2 ks stávajících HSM modulů za cenu uvedenou v čl. XVI této smlouvy.
Zhotovitel předmět plnění podle odst. 1 tohoto článku za tuto cenu kupuje a přejímá do svého vlastnictví s tím, že je mu znám jeho technický stav ke dni předání a převzetí.
Článek XV
Lhůta, místo a způsob předání plnění
Zhotovitel se zavazuje převzít stávající HSM moduly nejpozději do okamžiku převzetí díla dle čl. II odst. 1 této smlouvy.
Místem plnění je objekt objednatele na adrese: Xxxxx 0, Xxxxxxxxx xx. 0 x Xxxxx 0, Xxxxxxxxxxxx 000.
Předání a převzetí stávajících HSM modulů bude potvrzeno podpisem protokolu o předání a převzetí stávajících modulů, který podepíše alespoň jedna z pověřených osob za každou smluvní stranu.
Článek XVI
Cena plnění a platební podmínky
(dodavatel cenu nedoplňuje, bude doplněna při uzavření smlouvy podle nabídky vybraného dodavatele)
Cena 2 ks stávajících HSM modulů byla stanovena dohodou smluvních stran a činí bez DPH celkem ... Kč. K ceně bude účtována DPH v platné sazbě.
Úhrada ceny bude provedena na základě daňového dokladu vystaveného objednatelem nejdříve v den uskutečnění zdanitelného plnění, kterým je den podpisu protokolu o předání a převzetí stávajících HSM modulů.
Článek XVII
Záruka
S ohledem na to, že se jedná o použité HSM moduly, neposkytuje prodávající na stávající HSM moduly žádnou záruku.
Článek XVIII
Přechod nebezpečí škody a vlastnické právo
Nebezpečí škody na stávajících HSM modulech přechází na zhotovitele okamžikem podepsání protokolu o jejich předání a převzetí.
Vlastnické právo ke stávajícím HSM modulům přechází na zhotovitele okamžikem uhrazení jejich ceny.
Článek XIX
Smluvní pokuta
V případě prodlení zhotovitele ve lhůtě pro převzetí stávajících HSM modulů podle článku XV odst. 1 této smlouvy je objednatel oprávněn požadovat smluvní pokutu ve výši 500 Kč za každý den prodlení.
Část C
Společná ustanovení
Článek XX
Závěrečná ustanovení
Smlouva nabývá platnosti a účinnosti dnem podpisu oprávněnými zástupci obou smluvních stran.
Smlouva může být měněna a doplňována pouze formou písemných vzestupně číslovaných dodatků podepsaných oprávněnými zástupci obou smluvních stran, není-li ve smlouvě uvedeno jinak. Dodatek v elektronické podobě se považuje za řádně podepsaný objednatelem, je-li podepsán kvalifikovanými elektronickými podpisy. To neplatí v případě změny pověřených osob nebo jejich kontaktních údajů dle článku IV odst. 2, kdy bude změna provedena jejím písemným oznámením druhé smluvní straně.
Práva a povinnosti vzniklé z této smlouvy mohou být postoupeny pouze po předchozím písemném souhlasu objednatele. Za písemnou formu se nepovažuje e-mail či jiné elektronické zprávy.
Zhotovitel prohlašuje, že po dobu účinnosti této smlouvy bude mít sjednáno pojištění pro případ vzniku odpovědnosti za škodu způsobenou třetí osobě v souvislosti s plněním této smlouvy, a to s pojistným plněním ve výši nejméně 5 000 000 Kč (slovy: pět milionů korun českých) s tím, že jeho spoluúčast nepřevyšuje 5 %. Zhotovitel se zavazuje, že pojištění v uvedené výši a rozsahu zůstane účinné po celou dobu účinnosti této smlouvy a do 5 pracovních dnů od výzvy objednatele je zhotovitel povinen toto objednateli prokázat.
Použije-li zhotovitel při své činnosti podzhotovitele, nahradí škodu jím způsobenou, jakoby ji způsobil sám.
Smlouva je sepsána v českém jazyce. Veškerá komunikace mezi smluvními stranami vztahující se k této smlouvě bude probíhat v českém nebo slovenském jazyce, nebude-li smluvními stranami v konkrétním případě dohodnuto jinak.
7. Závazkové vztahy touto smlouvou založené se řídí českým právním řádem, zejména zákonem č.89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů.
8. Smluvní strany se dohodly, že případný spor, který vznikne z této smlouvy nebo v souvislosti s ní bude rozhodován výlučně podle českého práva obecnými soudy v České republice.
9. Xxxxxxx je vyhotovena ve třech stejnopisech, z nichž objednatel obdrží dvě a zhotovitel jedno vyhotovení./Smlouva je vyhotovena v elektronické podobě, přičemž každá ze smluvních stran obdrží vyhotovení smlouvy opatřené elektronickými podpisy (před uzavřením smlouvy bude zvolena varianta dle dohody smluvních stran
10. Odpověď strany této smlouvy podle § 1740 odst. 3 občanského zákoníku s dodatkem nebo odchylkou není přijetím nabídky, ani když podstatně nemění podmínky nabídky.
11. Smluvní strany vylučují uplatnění ustanovení § 1765 a § 1766 a § 2620 občanského zákoníku na svůj smluvní vztah založený touto smlouvou, čímž se ruší nárok dodavatele na jednání podle § 1765 odst. 1 občanského zákoníku. Dodavatel tímto přebírá nebezpečí změny okolností dle § 1765 odst. 2 občanského zákoníku.
Přílohy:
č. 1 Specifikace dodávaných technických a programových prostředků (doplní dodavatel)
č. 2 Specifikace činností
č. 3 Seznam zařízení objednatele
č. 4 Technická a funkční specifikace předmětu plnění
č. 5 Bezpečnostní požadavky objednatele
č. 6 Návrh technického řešení (bude doplněno z nabídky vybraného dodavatele při uzavření smlouvy)
č. 7 Podrobný rozpis ceny plnění (bude doplněno z nabídky vybraného dodavatele při uzavření smlouvy)
č. 8 Vzor realizační studie
č. 9 Obecná pravidla pro dodavatele v oblasti bezpečnosti IT
V ………… dne: ………….. V Praze dne: …………..
Za zhotovitele: Za objednatele:
……………………………….. ……………………………….
doplní dodavatel Xxx. Xxxxx Xxxxxxx
ředitel sekce informatiky
………………………………..
Xxx. Xxxxxx Xxxxxx
ředitel sekce správní
Příloha č. 1
Specifikace technických prostředků a programových prostředků
(Dodavatel doplní tuto přílohu formou výčtu příslušných part-numberů programových a technických prostředků a jejich popisu tak, aby z tohoto výčtu a na základě dokumentace v nabídce či volně dostupné na internetu bylo možno ověřit splnění funkčních požadavků uvedených v příloze č. 4 této smlouvy.)
……………………………
……………………………
……………………………
……………………………
……………………………
Detailní specifikace požadovaných činností zhotovitele
Činnost |
Poznámka |
Zapojení nově dodaných technických a programových prostředků do datových struktur ČNB a instalace/úpravy HW/SW |
Zapojení nových technických prostředků v režimu vysoké dostupnosti a připojení všech stávajících serverů. Instalace a úpravy HSM a základní konfigurace, instalace a úpravy SW pro management a SW/skriptu pro dohled na dedikovaném serveru (pokud to bude nutné). . |
Instalace a úpravy SW na serverech |
Asistence při instalaci a případných úpravách veškerého dodaného SW na všech serverech z platforem Linux i Windows. Maximální přípustné doby provozních odstávek jsou uvedeny v příloze č. 4, část Provozní odstávky; |
Testovací provoz s HSM v QSCD režimu |
definice jednotlivých kroků a součinnosti, detailní harmonogram a specifikace testů, volba ochrany klíčů • nový SecWorld včetně nového RFS na novém nebo ekvivalentním HSM v eIDAS konfiguraci (testovací provedení ACS) • vytvoření konfigurace pro klienty • ověření v testovacích aplikacích • test migrace klíčů CA a jedné z aplikací • dokumentace postupu a plán ostrého přechodu |
Konfigurace a provoz HSM v QSCD režimu |
•Vytvoření základní konfigurace nových HSM modulů v režimu QCSD (včetně vytvoření ACS setu); •Vytvoření pomocného OCS setu pro autorizaci požadavků na vytváření OCS setů a softkaret a operace s nimi pro jiné účely než kvalifikovanou pečeť z důvodů provozu ve striktním FIPS módu; •Reset HSM a jeho nová inicializace do HSM infrastruktury v QSCD režimu; •Doplnění nového HSM do HSM infrastruktury (nový modul nebo výměna za jiný v rámci technické podpory) v QSCD režimu; •Aktualizace firmware; •Vytvoření nového OCS setu pro potřeby kvalifikované pečeti; •Vygenerování klíčů pro kvalifikovanou pečeť, žádosti o příslušný kvalifikovaný certifikát a jeho import; •Obnova OCS setu pro kvalifikovanou pečeť na nové čipové karty; •Zničení/smazání klíčů a OCS setů pro kvalifikovanou pečeť, které již nejsou nadále potřebné; •Protokolární dokumentace provedených operací.“ |
Migrace klíčů do nových HSM v QSCD režimu |
Vypracování migračního postupu a asistence při migraci dat aplikací dle požadavků uvedených v příloze č. 4. v části Migrace dat. Maximální přípustné doby provozních odstávek jsou uvedeny v příloze č. 4 v části Provozní odstávky; Realizuje zástupce zhotovitele při migraci dat pro MS PKI 2016 a pro jednu z aplikací. Migraci dat z ostatních aplikací zajišťuje dle dodaného postupu ČNB za účasti zástupce zhotovitele. |
Skripty |
Úprava skriptů pro dohled, pokud to bude nutné. |
Optimalizace |
Zkušební provoz po ukončení migrace, provedení měření významných provozních stavů dodaného řešení a návrh optimalizace konfigurace. |
Zaškolení |
Zaškolení proběhne v prostorech objednatele po instalaci a konfiguraci v rozsahu max. 1 den pro max. 6 odborných pracovníků objednatele. Předmětem zaškolení bude seznámit technické správce HSM a komponent systémového prostředí ČNB (typicky operační systém Windows Server a Oracle Linux; dále pak správce certifikační autority provozované na Windows serveru) s:
Při zaškolení může být využita aktualizovaná dokumentace viz níže či potřebné materiály připraví a dodá zhotovitel. |
Dokumentace |
|
*) instalační deník by měl být veden formou el. souboru, kde se průběžně (pokud možno okamžitě) zaznamenávají provedené akce a nastavení.
**) Havarijní plán by měl obsahovat všechny nezbytné informace pro zaměstnance objednatele, jak mají postupovat v případě závady a jakou součinnost musí poskytovat případně zhotoviteli. Měl by obsahovat zejména následující informace:
o umístění nezbytných záznamů (logů) vedoucí k bližší identifikaci závady a základní informace o tom, jak logy analyzovat (případně informaci, že konkrétní log je určen pro analýzu ve vyšších stupních podpory a jak se tento log dá uložit do souboru, aby mohl být odeslán např. e-mailem)
o postupech při typických závadách a chybových hlášeních a popis postupu/ů jak blíže identifikovat závadu. V této části by měl být uveden popis typických závad, které mohou nastat a mohou být odstraněny zaměstnanci objednatele (např. při výpadku jednoho HSM -> je potřeba uvést HSM do stavu on-line příkazem „abcd“; nefunguje komunikace mezi serverem a HSM-> je potřeba ověřit zda je příslušný port HSM funkční a následně provést akci „xyz“; atd.). Rozsah těchto typických závad bude záviset na složitosti navrženého řešení. Mezi typické „závady“ považujeme i postupy při vypínání a zapínání systému, jak po předchozím korektním vypnutí, tak i po neočekávaném vypnutí.
o postupech při atypických závadách (např. informaci o tom, že se má kontaktovat servisní podpora).
o postupu při havárii lokality, tj. zejména postup jak zprovoznit systémy v druhé lokalitě.
-
Platforma
(účel)
verze OS
Aplikační Cluster
Počet licencí celkem
poznámka
Virtualizace – OracleVM 3.4.7
Základní registry
Oracle Linux Server release 7.9
Ano
4
Geocluster Windows
2 servery provozní CA
Win 2016 LTSC
Ano
4
Exadata
Databáze
Oracle Linux Server release 7.9
Ano
12
Virtualizace – Vmware vSphere 7
LTD server/Secusign
Win 2016 LTSC
Ne
4
RFS
Win 2012R2
Ne
2
Server pro Management / dohled, pro upgrade bude objednatelem připraven server s Win 2016 LTSC
Ostatní
Kořenová CA
Win 2016 LTSC
Ne
2
Vývojáři
Win 10 LTSC 2019
Ne
4
Příloha č. 4
Technická a funkční specifikace předmětu plnění
Terminologie
Cluster - skupina zařízení (zpravidla serverů nebo HSM), která umožňuje zajistit obnovu zpracování v řádu jednotek minut po výpadku některé z komponent. Vzájemná vzdálenost zařízení od sebe může být do desítek metrů.
Cluster geografický/geocluster - obdoba lokálního clusteru s tím rozdílem, že i data jsou zdvojená a tato technologie umožňuje kompletní obnovu zpracování ve fyzicky jiné lokalitě (vzdálenost desítky kilometrů). V různých lokalitách jsou nejen servery, ale i HSM.
High Availability – řešení, které zajišťuje dohodnutou spolehlivost zpracování nebo systémů. V tomto řešení je typicky zajištěno, že při výpadku jedné (nebo i více komponent) není zpracování narušeno.
IS (Informační systém/aplikace) - je funkční celek, který slouží k získávání, uchovávání, přenášení, zpracovávání a poskytování informací pomocí informačních technologií. Zahrnuje informační technologie, data, správu informačního systému a zaměstnance, kteří ji zajišťují, uživatele a vzájemné vazby mezi nimi.
Slot (Softcard, ACS) – samostatně přístupný, bezpečnostně oddělený prostor se samostatnou autentizací, sloužící jako úložiště pro klíče a certifikáty. Je vytvořen konfiguračními prostředky HSM.
Data – jedná se o páry kryptografických klíčů a souvisejících certifikátů, pokud není uvedeno jinak
MSCS (Microsoft Cluster Service) – SW dodávaný firmou Microsoft zajišťující funkci clusteru. Tento SW je součástí MS Windows Enterprise Edition.
Oracle VM – Oracle Virtualization Manager
Oracle LVM – Oracle Linux Virtualization Manager (založené na KVM)
Synchronní/Asynchronní přenos - pojmem synchronní přenos je označován typ přenosu, kdy data z jednoho HSM do druhého jsou automatizovaně přenesena na základě jejich změny v jednom z HSM. Naproti tomu při asynchronním přenosu jsou data po změně přenesena až na základě pokynu obsluhy.
ZP – záložní pracoviště ČNB Praha-Zličín.
HSM (Hardware Security Module) – bezpečnostní modul pro uchování certifikátů a klíčů aplikací a PKI. Modul zajišťuje prostřednictvím uložených klíčů elektronický podpis nebo dešifrování.
PKI (Public Key Infrastructure) – infrastruktura veřejných klíčů
CAPI (CryptoAPI) – je aplikační programové rozhraní, které umožňuje šifrování a digitální podpis pro aplikace v systému Windows
CNG (Cryptography API Next Generation) – je náhrada za CryptoAPI
FIPS 140-2 (Federal Information Processing Standards) – standardy, které ve verzi 140-2 specifikují požadavky na kryptografické moduly
EAL (Evaluation Assurance Level) – udává, na jaké úrovni testování daný produkt vyhověl bezpečnostním kritériím (Common Criteria)
USB (Universal Serial Bus) – je univerzální sériová sběrnice pro připojení periferií k počítači
CSP (Cryptographic Service Provider) – zprostředkovatel kryptografických služeb v systému Windows
KSP (Key Storage Provider) – je náhrada za CSP v systému Windows
PKCS (Public Key Cryptographic Standards) – je skupina standardů pro kryptografii s veřejným klíčem navržená a publikovaná společností RSA Security
SIEM (Security Information Event Management) – je nástroj pro správu bezpečnostních informací a událostí
RSA, SHA-2 – kryptografické algoritmy
Popis současného stavu a infrastruktury HSM v ČNB
Obecné informace
V ČNB jsou v provozu dvě výpočetní střediska. Obě tato střediska jsou provozována systémem aktiv-aktiv, tj. v obou střediscích jsou zpracovávány různé informační systémy. Běžný uživatel není schopen rozlišit, ve kterém středisku je jeho požadavek zpracován. V případě potřeby (havárie, údržba,….) je zpracování konkrétního informačního systému přesunuto na jiný uzel.
Do prostředí (geografických) clusterů jsou umísťovány IS přímo podporující jednu nebo více kritických činností ČNB. Jiné IS se do tohoto prostředí umisťují jen výjimečně (např. z licenčních důvodů, striktního požadavku na shodnost akceptačního a provozního prostředí apod.).
V případě havárie je výpadek ve zpracování (doba mezi zastavením IS a jeho nastartováním na jiném serveru) v délce do 5 minut pro ČNB akceptovatelný. V případě plánované údržby je nutné konkrétní dobu přesunu zpracování individuálně dohodnout se správcem příslušného IS (liší se dle IS, zpravidla na počátku nebo konci pracovní doby).
Komunikační infrastruktura
Jedno výpočetní středisko je umístěno v budově ústředí v Praze 1 a druhé v Praze 5 - Zličín. Obě střediska jsou plnohodnotně vybavena jak po stránce komunikační (LAN), tak i po stránce zpracování a uložení dat (servery, disková pole, magnetopáskové knihovny). Z kapacitního hlediska převažuje (počty serverů, objemy dat) objekt ústředí, ve kterém jsou také umístěny systémy nevyžadující zdvojení (méně významné IS, systémy pro testování a vývoj apod.).
Obě výpočetní střediska jsou propojena optickými vlákny (single mode) dvěma nezávislými trasami.
Prostředí HighAvailability (HA)
V ČNB je nasazeno několik typů prostředí HA. V zásadě je lze rozdělit na prostředí, kde je HA podporováno na úrovni celých virtuálních strojů a na prostředí na úrovni jednotlivých aplikací uvnitř serveru (virtuálního nebo fyzického). Obě tyto úrovně mají různý stupeň automatizace.
V současné době jsou v ČNB provozovány dvě virtualizační platformy – VMware a Oracle VM. Zde jsou využívány funkcionality typu FailOver (přesun celého virtuálního stroje (VM) při havárii hypervizoru) a SRM (VMware Site Recovery Manager).
V oblasti aplikační je na operačním systému Oracle Linux Server využíván software HP MC/ServiceGuard (MC/SG), k němuž byly v ČNB vyvinuty scripty zajišťující manipulaci s příslušnými disky v návaznosti na operace vyžadované clusterem.
V prostředí operačního systému Windows je provozován Microsoft Cluster Server (MSCS) s arbitrem - File share witness.
.
Úložiště klíčů
V ČNB je využíváno několik typů úložišť. V zásadě je lze rozdělit na prostředí softwarová, kde jsou klíče uloženy v operačním systému nebo databázi a na prostředí hardwarová, kdy jsou klíče uloženy na čipových kartách nebo HSM modulech. Pokud je využito standardních úložišť MS Windows (MS PKI 2016 LTSC), nejsou pro aplikace realizovány žádné specifické programové nadstavby. V ostatních případech jsou pro aplikace vytvořeny programové moduly, které umožňují spolupráci s příslušným úložištěm.
Popis stávajícího prostředí HSM
Security World
Security world (SecW) je kompletní infrastruktura, která slouží k zabezpečení kompletního životního cyklu šifrovacích a podepisovacích klíčů.
Vlastní security world se skládá z těchto komponent:
• jeden nebo více Entrust HSM modulů;
• set administrátorských čipových karet (ACS) pro správu a obnovu security world;
• volitelně jeden nebo více setů operátorských čipových karet nebo softkaret pro ochranu vybraných aplikačních klíčů
• vybrané klíče a certifikáty zašifrované hlavním klíčem security worldu (Security World key) uložené na klientských počítačích mimo vlastní HSM moduly.
Jeden security world sdílí společný hlavní klíč (Security World key) pro všechny použité HSM moduly pro zabezpečení klíčů a souvisejících dat mimo vlastní HSM moduly.
SecWorld je provozován v režimu FIPS Level 3 a verzi SW 11.72.02 a FW 2.55.1. certifikovaných pro QSCD. Podrobnosti k ostatním komponentám jsou popsány níže.
Administrátorský set čipových karet (ACS)
Sada administrátorských čipových karet, na kterých jsou uloženy fragmenty master klíče celého security world tak, aby byl nutný přístup k n různým čipovým kartám z celkového počtu N administrátorských karet.
Set čipových karet, které mají k dispozici správci PKI, využity jsou OCS sety velikosti k/N u obou CA.
V případě vybraných aplikací nebo rozhraní je použita alternativa k fyzickým čipovým kartám v podobě tzv. softcards, což jsou virtuální SW varianty čipové karty.
Jedná se o soubor se zašifrovaným klíčem, který je uložen na příslušném klientovi a chráněn heslem.
Tato varianta je používána pro aplikace využívající PKCS#11 rozhraní.
Uplatněná architektura zabezpečení security world umožňuje uchovávat klíčové konfigurace a data mimo vlastní HSM moduly v šifrované podobě. Za tímto účelem každý HSM modul používá vzdálený souborový systém na definovaném klientovi.
Na tomto souborovém systému jsou uloženy zálohy konfigurací jednotlivých modulů, které je možné použít např. při obnově poškozeného HSM modulu. Dále jsou sem ukládány všechny klíče a certifikáty, které jsou k dispozici v rámci celého security world.
Synchronizace mezi jednotlivými klienty se neprovádí.
Klientem je počítač s IP adresou, který fyzicky komunikuje s konkrétním HSM modulem. Pro každého takového klienta je třeba mít na příslušném HSM modulu klientskou licenc
i, která je pevně spjata s konkrétním HSM modulem.
Pro případ požadavku řešení v režimu vysoké dostupnosti jsou k dispozici 2 HSM moduly a každý klient je registrován na 2 HSM modulech.
Na klientu je nainstalováno aplikační SW vybavení Entrust zajišťující krom jiného režim vysoké dostupnosti a soubory s klíči v zašifrovaném formátu pro konkrétní IS.
Aplikací se v rámci terminologie myslí především použité aplikační rozhraní. Přehled využívaných aplikačních rozhraní uvádí následující seznam:
PKCS #11 aplikace – aplikace a technologie používající PKCS#11 rozhraní –
Oracle Linux Server (2+2záložní) servery, celkem 2 IS (využívají IAIK PKCS#11)
Exadata (2+2záložní) - celkem 2 IS (využívají IAIK PKCS#11);
MS Win LTD server (1+1test) – celkem 4 IS (využívají PKCS#11).
Microsoft CNG CSP - PKI infrastruktura MS Windows – 1x kořenová CA a 1+1 provozní CA (MS Cluster)
V prostředí jsou zapojeny dva HSM moduly Entrust nShield Connect 1500+ v HA režimu. Každý z modulů má 16 licencí.
Moduly jsou nastaveny následujícím způsobem:
jsou součástí jednoho security world, používají stejné RFS;
záznamy událostí se zaznamenávají jak v modulu, tak i na RFS.
V rámci celkové infrastruktury HSM modulů je v produkčním SecW rovněž konfigurován náhradní modul, který je možné v rámci stávající podpory dočasně zapůjčit po dobu nezbytně nutnou na opětovné zprovoznění standardního produkčního HSM modulu.
Standardní systémové prostředí ČNB (výňatek pro účely této smlouvy)
Standardní systémové prostředí je soubor konkrétních produktů technického a programového vybavení včetně pravidel pro jejich provoz a dále seznam definovaných služeb, které souhrnně tvoří základní platformu pro provoz informačních systémů a informačních technologií (IS/IT) v prostředí České národní banky (ČNB).
Prostředí datové sítě
Klientské stanice připojeny rychlostí typicky 100 Mbsec-1 100Base-T
Servery připojeny typicky rychlostí 1 Gb 1000Base-T
Mezi servery a klientskými stanicemi pouze L3 konektivita, mezi servery možná L2 nebo L3 konektivita
Adresace dle RFC 1918 (10.x.y.z)
Plně přepínaná síť s redundantním jádrem
Serverové prostředí
Platforma architektury x86 - MS Windows Server 2012R2 nebo 2016 LTSC, cp 1250
Platforma Oracle Exadata
Platforma Oracle Linux Server Release 7.9
Platforma VMware vSphere 7
Platforma Oracle VM 3.4.7, v plánu upgrade na Oracle Linux VM (založené na KVM)
Monitoring systémů
System Center Operations Manager 2012 R2 – centrální sběr logů
QUALYS – monitoring zranitelností
Využívané certifikáty pro el. pečeť
Certifikáty jsou smluvně zajištěny a poskytovány certifikační autoritou PostSignum.
1. Striktně vyžadované funkce a vlastnosti:
V následující tabulce jsou uvedeny požadavky, které musí být zhotovitelem ve finálním řešení splněny. U jednoho „požadavku“ (=řádku tabulky) může být současně i několik požadovaných vlastností (viz např. požadavek „spolehlivost“), které musí být splněny všechny.
Použité výrazy jsou poplatné obecné terminologii a nejrozšířenějším technologiím. V některých místech se však mohou lišit od technologie nabízené zhotovitelem (vše není možné popsat zcela obecně). V tom případě musí zhotovitel jasně vysvětlit vzájemný vztah nabídnutého řešení a požadavku objednatele a zdůvodnit způsob splnění požadavku. Rozhodující je splnění příslušné funkce nebo vlastnosti po její funkční/výkonové stránce nikoliv způsob jakým je výsledku dosaženo.
Požadavek |
Popis |
Poznámka/zdůvodnění |
Dostupnost |
Řešení musí být odolné proti výpadku. Jednotlivé komponenty musí být zdvojené, nesmí existovat tzv. „Single Point of Failure“. |
Pro potřeby ČNB je důležitá spolehlivost a bezvýpadkovost systému jako celku. |
Spolehlivost |
Je vyžadováno:
|
Pokud bude požadavek na zajištění dostupnosti dat do 6 hod řešen studenou zálohou ve formě dalšího zařízení, musí být toto zařízení v nabídce uvedeno.
Vysoká spolehlivost provozu je součástí zajištění dostupnosti dat. V noci probíhá dávkové zpracování v délce několika hodin. Případné odstávky při výměně vadných komponent, upgrade FW/mikrokódu nebo konfigurační změny mající dopad na provoz systému jsou v ČNB organizačně náročné. Zajištění bezchybného uložení dat je pro ČNB jedním z prioritních požadavků.
Zhotovitel musí na základě svých kontraktů s výrobce/distributorem zajistit takovou úroveň podpory, aby bylo možné problém eskalovat k výrobci (případně pověřené organizaci), kde se tímto problémem budou seriózně zabývat. Výsledné stanovisko samozřejmě může být závislé na konkrétní situaci (bude/nebude vytvořen fix, bude implementováno do nové verze FW apod.).
Každá závada znamená čas zaměstnanců ČNB strávený její řešením. A to přináší na straně objednatele určité náklady.
S ohledem na význam HSM není naprosto přípustné, aby zhotovitel prováděl jakékoliv ladění FW/mikrokódu nebo jiného dodaného SW v prostředí ČNB. |
Režim vysoké dostupnosti |
V rámci řešení musí být zajištěn režim vysoké dostupnosti. Mezi dvěma různými instalačními lokalitami. Technologie musí být transparentní a může vyžadovat pouze konfigurační zásah do IS.
|
ČNB má v provozu tzv. nouzové záložní pracoviště, které je provozováno systémem aktiv-aktiv, tj. v obou lokalitách jsou provozovány různé IS. V případě výpadku/odstávky je zpracování převedeno do druhé lokality. Toto nouzové pracoviště je také koncipováno jako „disaster recovery“ centrum ČNB. |
Zabezpečení dat |
Data musí být zabezpečena proti selhání nebo přetížení prostřednictvím clusterového řešení (zdvojení komponent) a zálohováním dat do bezpečného úložiště a jejich rozdělení na více částí.
Pokud je vyžadován pro tuto funkci speciální hardware, musí být dodán v takovém množství, aby odpovídal minimální poptávané kapacitě a dvěma nezávislým zálohám. |
Pro případ selhání obou nodů clusteru musí být k dispozici odpovídajícím způsobem zabezpečená záloha. |
Zabezpečení proti úniku dat |
HSM a servery jsou umístěny v prostorech s omezeným přístupem v dedikovaném uzamčeném racku. V případě pokusu o fyzické narušení HSM musí dojít k automatickému vymazání dat a to i v případě že bude HSM ve vypnutém stavu. |
HW, kde bude umístěn klíčový materiál včetně záloh, bude umístěn v prostorech s omezeným přístupem v dedikovaném uzamčeném racku nebo v trezoru podle typu média. |
Ochrana investic |
Požadované funkce řešení musí být aplikačně nezávislé (změna verze IS/aplikace nesmí mít vliv na funkce poskytované řešením). |
Všechny poskytované funkce musí být nezávislé na IS. Pro všechny informační systémy musí být poskytované služby transparentní, tj. nesmí existovat vazba mezi informačními systémy a řešením ve smyslu nutnosti certifikace výrobcem dodaného HW nebo SW. |
Připojení |
Připojení je vyžadováno prostřednictvím minimálně 2 nezávislých přípojek LAN. |
V ČNB je vybudovaná infrastruktura LAN, která umožňuje připojení zařízení do dvou nezávislých síťových prvků. |
Množství připojených serverů |
Navržená technologie musí umožňovat připojení minimálně 14 serverů ke každému nodu.
|
V budoucnu se předpokládá navýšení počtu připojených serverů. |
Kapacita a prostor pro data |
Celková kapacita pro data (v každé lokalitě) musí být minimálně 20 klíčových párů a certifikátů o velikosti každého klíče/certifikátu max. 4096 bitů. Tyto klíčové páry musí být možné umístit do minimálně 10 slotů.
|
Požadavek na celkovou kapacitu vychází, ze současného stavu a z očekávaného nárůstu pro další období.
Vysvětlení pojmu „celková kapacita pro data (v každé lokalitě)“: je to prostor, který může být přidělen nějakému serveru/ům (aplikacím). |
Kapacitní rozšiřitelnost |
. Nabízené zařízení musí umožnit další rozšíření nad rámec dodatečných technických a programových prostředků specifikovaných smlouvou. To vše bez koncepčního zásahu do navrženého řešení. Kapacitní rozšiřování nesmí mít dopad na provoz již instalovaných komponent.
Rozšíření musí být v rámci navrženého řešení, tj. veškeré dodané i rozšířené kapacity musí být spravovány a provozovány jako jeden celek. Zejména z hlediska provozu se musí jednat o celek, který mj. umožní připojení nových kapacit k serverům bez potřeby složitých rekonfigurací. |
V závislosti na skutečných potřebách je nelze vyloučit další požadavky na kapacitní rozšíření, ale toto rozšíření není v tuto chvíli předmětem dodávky. |
Výkonnost |
Každé HSM v nabízené konfiguraci musí být schopno realizovat minimálně 800 TPS algoritmem RSA s klíčem o velikosti 4096 bitů. Splnění požadavku je nutné doložit prohláše ním výrobce. |
Výkonnost musí být jednoznačně doložena výrobcem.
|
Výkonnostní rozšiřitelnost |
Navržené řešení musí umožňovat rozšíření nejméně o dalších 800 TPS algoritmem RSA s klíčem o velikosti 4096 bitů v každé lokalitě.
Rozšíření musí být v rámci navrženého řešení, tj. veškeré nově dodané i rozšířené kapacity musí být spravovány a provozovány jako jeden celek. Zejména z hlediska provozu se musí jednat o celek, který mj. umožní připojení nových kapacit k serverům bez potřeby složitých rekonfigurací. |
Z hlediska výkonnosti se očekává v následujících 3-4 letech možný nárůst počtu požadovaných podpisových operací a proto musí být zajištěna možnost výkonnostního rozšíření. Rozšíření není v tuto chvíli předmětem dodávky. |
Operace s HSM |
Zařízení musí umožnit zvětšení počtů slotů bez ztráty uložených dat.
Změny na HSM (přidání/odebrání serveru nebo přidání/odebrání slotu u jednoho HSM) v žádném případě nesmí ovlivnit provoz ostatních serverů (aplikací) připojených k HSM ani ostatních HSM jako celku. |
Funkce nutná z důvodu zabezpečení nezávislého přístupu serverů jen k přiděleným slotům. |
Homogenita |
Navržené řešení musí být homogenní, tzn. že ke všem komponentám musí být přistupováno rovnocenně. Tím je míněno, že veškeré komponenty stejného významu nebo funkce musí mít také stejná privilegia, omezení, stejné funkce a odpovídající výkonnost.
Není proto přípustné, aby ke slotům některého z HSM nebylo možné přistupovat z některého ze serverů.
Je vyžadováno jednotné řešení z hlediska zajištění správy navrženého řešení.
Navržené řešení musí být symetrické (shodné) pro obě lokality. |
Z důvodu flexibility (možnost bezproblémové změny umístění aplikací) a z důvodu zjednodušení správy musí být navržené řešení stejné pro obě lokality (ústředí/ZP). |
Ladění výkonnosti/přesun zpracování na jiný HSM |
Je požadována funkcionalita SW umožňující přesun zpracování na druhý HSM s menším zatížením. Přesun musí proběhnout on-line vzhledem k aktivitě serveru a bez narušení jeho provozu. Tato funkcionalita nemusí zajišťovat automatický návrh přesunů ani jej automaticky provádět. Pokud bude SW umět automatické přesuny, musí být možné je zablokovat nebo alespoň konfigurovat na uživatelské úrovni. |
Jedná se o „poloautomatickou“ optimalizaci zátěže HSM bez nutnosti odstávek provozu v případě kdy je jeden HSM např. v určitou denní dobu přetížen. |
Kompatibilita s prostředím ČNB |
Při realizaci informačního systému je nutné zajistit, aby programové komponenty realizovaného IS nebyly v rozporu s komponentami dalších provozovaných IS. Realizovaný IS tedy musí být provozovatelný v systémovém prostředí ČNB a současně nesmí narušovat funkčnost ostatních IS.
Navržené řešení musí dodržovat standardy uvedené v části „Popis současného stavu a infrastruktury ČNB“. |
|
Kompatibilita aplikací |
Musí být zajištěn provoz MS PKI 2016 a ostatních aplikací na platformě Oracle Linux Server, pracujících v režimu vysoké dostupnosti. Přesun aplikací mezi lokalitami nesmí mít vliv na funkčnost clusteru těchto aplikací, ani dodaného řešení jako celku.
|
Režim vysoké dostupnosti je v prostředí MS Windows 2016 realizován jako geografický cluster MSCS. Na platformě Oracle Linux Server je cluster realizován jako lokální prostřednictvím SW HP MC/ServiceGuard s geografickou nadstavbou ČNB. |
Kompatibilita serverů |
Navržené řešení musí umožnit připojení serverů na platformách uvedených v tabulce „Seznam zařízení objednatele“. Kompletní seznam serverů včetně je uveden v příloze č. 3.
Možnost připojení těchto serverů v kombinaci s operačním systémem musí být výrobcem HSM podporována. Jedná se zejména o serverové operační systémy/platformy: MS Windows Server 2016 a Oracle Linux Server release 7.9, které mohou být provozovány buď na fyzickém HW, nebo na virtualizační platformě VMware 7, OracleVM 3.4.7, nebo Oracle Exadata.
Dále musí být podporováno připojení serverů s operačními systémy Windows 2012 a Windows 2016 a Oracle Linux Server 7.9 |
Navržené řešení musí zajistit možnost připojení stávajícího technického vybavení (serverů) a umožňovat i rozvoj do budoucna (přechod na vyšší verze provozovaného programového vybavení-operačních systémů). Vynucená změna operačních systémů nebo jejich verzí je v rámci nasazení řešení zcela vyloučena. |
Rozhraní pro programátory a aplikace |
Na serverech viz „kompatibilita serverů“ musí být k dispozici rozhraní PKCS#11 a rozhraní pro programovací jazyk Java. Zároveň musí být k dispozici rozhraní MS CNG pro servery s operačním systémem Windows Server 2012 a vyšším.
Funkce a možnosti rozhraní musí být dokumentovány a musí být dodán příslušný SDK včetně příkladů použití. |
Je nutné vybavit minimálně dvě pracoviště dvou programátorů. |
Základní funkce |
Musí být možné generovat klíčový pár v HSM a žádost o certifikát. Tato žádost musí být vygenerována ve formátu PKCS#10 včetně diakritiky.
Certifikát musí být následně možné naimportovat do HSM ve formátu X.509v3 a to v kódování DER nebo base 64.
S takto uloženými nebo vygenerovanými klíči musí být možné realizovat digitální pečeť a dešifrování (ověření pečeti), prostřednictvím rozhraní MS CNG CSP, PKCS#11 a IAIK PKCS#11.
Pokud je pro některou z funkcí nutný alternativní postup, musí být zhotovitelem podrobně popsán. Všechny nezbytné skripty i případné utility (např. OpenSSL) musí být součástí dodávky a zhotovitelem podporovány!
Zhotovitel musí zajistit, že HSM zařízení objednatele bude provozováno v režimu QSCD. HSM nebo jejich součásti musí být zároveň uvedeny na seznamu kvalifikovaných prostředků - xxxxx://xxxxxxxxxx.xx.xxxxxx.xx/xxxx/xxxxxxxxxxxx-xxxx/#/xxxxxx/xxxxxx/xxxx/XXXX_XXXX a zhotovitel musí být schopen zajistit dodání certifikátů pro kvalifikovanou pečeť pro tato zařízení. |
Jedná se o minimální a povinný výčet funkcí.
|
Množina podporovaných kryptografických algoritmů |
Minimálně musí být podporován asymetrický algoritmus RSA o délce klíče až 4096 bitů, hešovací algoritmus SHA-256 a symetrický algoritmus AES o velikosti klíče 256 bitů.
|
Volitelně mohou být podporovány další algoritmy. |
Autentizační mechanismus |
Pro přístup je vyžadována minimálně autentizace prostřednictvím hesla, přístup ke klíčům omezen pouze na vymezené servery.
Musí být možné v případě aplikací vynutit použití pouze jednoho autentizační údaje, pokud řešení disponuje autentizačním mechanismem, který pro přístup vyžaduje více částí. |
V případě aplikací není přípustné, aby byl vyžadován více než jeden autentizační údaj pro přístup ke klíčům. Nesplnění tohoto požadavku by vyžadovalo značné úpravy na straně aplikací. Případné náklady spojené s úpravou komponent zhotovitel musí zahrnout do celkových nákladů na realizaci. |
Zabezpečení proti infiltraci a odposlechu komunikace |
Proti zneužití odposlechem na sběrnici nebo na síti musí řešení umožnit vytvoření důvěryhodného kanálu mezi sebou a participující aplikací. Řešení i aplikace musí být nastavené tak, aby vyžadovaly vytvoření důvěryhodného kanálu před tím, než si mezi sebou začnou vyměňovat jakékoliv kryptograficky citlivé informace tak, jak to vyžaduje FIPS 140-2 Level 3. |
Objednatel bude realizovat pravidelné testy HSM monitorovacím nástrojem Qualys. |
Bezpečnostní certifikace |
Řešení musí zajistit minimálně certifikaci odpovídající úrovni EAL 4+ nebo kompatibilní, případně FIPS 140-2 Level 3 nebo vyšší a musí v tomto módu také pracovat. |
Certifikace musí být doložena příslušným certifikátem. |
Systém provozu |
V obou lokalitách budou IS provozovány systémem active-active, tj. v každé lokalitě mohou s kteroukoliv částí řešení v režimu HA komunikovat za běžného provozu různé IS. |
Tento systém umožňuje využití pořízených kapacit v běžném provozu k rozložení zátěže mezi jednotlivé servery. |
Duální připojení serverů |
Požadován je nejen FailOver, ale i load balancing (všechny cesty mezi serverem a HSM musí být v normálním režimu aktivní a musí nad nimi být zajištěn load balancing). Tato povinnost platí pro servery dle přílohy č. 3. Ztráta některé z cest k HSM nesmí mít dopad na činnost serveru s výjimkou snížení propustnosti, tj. nesmí dojít k činnosti serveru, která povede k jeho nefunkčnosti (např. přesun zpracování aplikací na jiný uzel geoclusteru). |
Pro některé náročné IS je nebo v budoucnu může být nezbytné současné využití více komunikačních kanálů k HSM tak, aby došlo k rozložení zátěže mezi jednotlivými HSM.
Ztrátou dostupnosti některé z cest k HSM nesmí být ovlivněna řádná činnost operačního systému nebo aplikací. |
Dopad na provoz serverů |
Dodávaný SW nesmí mít zásadní dopad na výkonnost serveru. Vyžadováno je tedy řešení, které má minimální dopad na celkovou zátěž serveru (tj. jeho CPU, RAM, NIC,….). Pokud bude navřeno řešení s dopadem na výkonnost serveru, nesmí mít větší dopad, než 10% výkonu CPU, nejvýše 10% kapacity RAM a nejvýše 10% LAN. |
Zatížení serveru dodávanými komponentami nesmí zásadním způsobem omezovat výkonnost provozovaných aplikací. |
Zátěž komponent síťového prostředí ČNB |
Navržené řešení nesmí neúměrně zvyšovat zátěž prvků stávajícího systémového prostředí ČNB. Navýšení zátěže každé z komponent systémového prostředí je povoleno nejvýše o 10%. |
Navržené řešení nesmí zcela svévolně, resp. pouze pro zajištění své vlastní režie navyšovat zátěž síťových komponent současného prostředí ČNB. Tím by mohla vzniknout nutnost některé z komponent posílit. |
Rozměry a chlazení |
Případně nově dodávané technické prostředky musí být umístitelné v těchto prostorech ČNB:
Praha 1, Senovážná ul. 3 (místnosti VP304) Prxxx 0, Strojírenská 175 (místnost PP117)
Zařízení bude v objektu ústředí umístěno do standardního 19“ stojanu ČNB (výrobce Triton, 42U 600x900mm, bez podstavce, s krytím IP20).
Zařízení musí být dodáno včetně komponent, které umožní montáž do tohoto typu stojanu.
V objektu ústředí je vytvořen systém tzv. teplé uličky. Zařízení jsou tedy ve stojanech s přívodem chladného vzduchu před stojan a výdech ohřátého vzduchu je zadem do zastřešené uličky a odtud je odváděn pryč.
V objektu ZP bude k dispozici stojan obdobných parametrů jako v ústředí.
V ZP Zličín je v současné době chlazení zajištěno foukáním chladného vzduchu do zdvojené podlahy. V budoucnu se předpokládá stejný systém jako v Senovážné, tedy systém teplé a studené uličky.
Dodávaná zařízení musí splňovat podmínku sání na přední straně a výdech na zadní straně v kombinaci s umístěním do stojanu ČNB. |
Požadavek vychází ze specifikace prostor očekávaného umístění. Jiný stojan by přinesl problémy se zastřešením teplé uličky a s chlazením prostoru.
|
Napájení |
Požadováno je připojení na rozvod s napětím 230V (=jednofázové) s jištěním nejvýše 25A.
Je požadováno zajištění uložených dat tak, aby i při výpadku napájení trvajícím nejvýše 24 hodin nebyla tato ztracena (např., baterie pro zálohování). |
Ve výpočetních střediscích ČNB jsou rozvaděče připraveny pro připojení systémů s 1 fázovým napájením.
|
Diagnostika |
HSM musí mít zajištěnu trvalou diagnostiku poruch. V případě poruchy musí HSM problém hlásit objednateli, který rozhodne o urgentnosti odstranění závady. Pokud budou mít úpravy vliv na funkčnost stávajících skriptů, musí být v rámci dodávky upraveny. |
Pro zajištění maximální spolehlivosti a včasného zajištění nápravy je vyžadována trvalá diagnostika poruch řešení. |
Dohledový nástroj/skript |
Diagnostika musí být realizována buď prostřednictvím dohledového nástroje, nebo skriptu, který musí zajistit:
Dohledový nástroj/skript musí splňovat minimálně tato bezpečnostní kritéria:
|
Z důvodu zajištění správy a minimalizace nároků na správu je požadováno zajištění odpovídajícího nástroje/skriptu a jeho funkčnosti i po rozšíření.
Pro dohledový nástroj/skript může je ze strany ČNB poskytnut 1x Virtuální server (max. 1xCPU, 2GB RAM, 30 GB HDD) s připojením do LAN. Více viz příloha č. 4. |
Konfigurační změny |
Řešení musí umožňovat minimálně tyto uživatelsky (=zaměstnanci ČNB) prováděné operace:
Řešení musí umožňovat minimálně tyto zhotovitelem prováděné operace:
Provádění všech operací musí být on-line, tj. bez přerušení přístupu k datům, výkonnost může být částečně snížena (týká se uživatelsky i zhotovitelem prováděných operací). Konfiguraci lokálního zabezpečení je možné přenést na uživatele. Tyto konfigurační změny musí být možné provádět prostřednictvím CLI, případně GUI (týká se uživatelsky prováděných operací). Konfigurační změny je možné provádět pouze za následujících „bezpečnostních kritérií“:
|
Pro pružné a efektivní využití HSM je nezbytné zajistit možnost konfiguračních změn HSM na úrovni zaměstnanců objednatele.
Další požadované operace musí zajistit technická podpora zhotovitele. |
Manipulace v clusteru-funkčnost clusteru |
Pro zajištění funkce geografického clusteru musí být zajištěny minimálně tyto funkce:
Provádění všech operací musí být on-line, tj. bez přerušení přístupu k datům, výkonnost může být částečně snížena.
Přechod na druhý node clusteru musí proběhnout automatizovaně na platformách dle přílohy č. 4.
Provedení operace musí být zajištěno do 4 minut (čas od okamžiku výpadku některé komponenty do okamžiku kdy jsou přístupné operačnímu systému v druhé lokalitě. |
|
Řídící komunikace a ovládání |
Komunikace pro řízení a ovládání řešení (např. konfigurační změny, FailOver při havárii atd.) může být realizována různými způsoby. Zhotovitel musí specifikovat používané porty pro tuto komunikaci (nastavení lokálních firewallů na serverech, např. IP tables).
Řídící komunikace s HSM musí být možná z příkazové řádky (CLI) nebo prostřednictvím grafického rozhranní (GUI) |
Pro konfigurační a řídící potřeby není nutné zajistit bezvýpadkový provoz (případný server zajišťuje ČNB). |
Zálohování konfigurace |
Musí být zajištěna možnost zálohování konfigurace řešení na serveru (pokud systém sám o sobě neprovádí tuto zálohu i do jiného vzdáleného prostoru). Musí být také zajištěna možnost zálohování konfigurace jednotlivých HSM. |
Jedná se minimálně o požadavek na možnost automatického vytvoření textového (čitelného) reportu o konfiguraci dané komponenty (konfigurace HSM, serverů,…) pro potřeby případné nutné obnovy (ruční vložení). |
Auditing |
Logy řešení musí být externě ukládány ve formátu se stanovenou strukturou a významem dat – dokumentace formátu a možnost jeho strojového zpracování je veřejně dostupná. |
Textový výstup je nezbytný pro budovaný systém SIEM. |
Migrace dat |
Po provedení rozšíření bude důležitým a náročným okamžikem migrace dat. Na tuto operaci bude kladen zřetel a ČNB neumožní dlouhodobé odstávky.
Podmínky pro provedení migrace dat jsou následující:
1) Migrační postup pro MS PKI 2016: Musí být zajištěna možnost migrace/import klíčů stávající PKI bez nutnosti generace nových klíčů a certifikátů a reinstalace PKI. Zhotovitel zajišťuje migraci/import. Pokud bude nutné realizovat reinstalaci PKI pro testování, pak musí být také provedena zhotovitelem.
Podmínkou realizace je zachování vrstvy MSCS v prostředí Windows a zachování stávajících dat.
2) Migrační postup pro ostatní aplikace (i v clusteru): Musí být zajištěna migrace/import stávajících dat aplikací bez nutnosti generace nových dat a bez změny konfigurace aplikací. Zhotovitel zajišťuje kompletní migraci.
Podmínkou realizace je zachování stávajících dat, pokud je to legislativně možné. |
Prioritními požadavky jsou ochrana dat, minimalizace odstávek a minimalizace rizik plynoucích z přechodu (např. performance problémy).
V nabídce musí být uvedeny navržené principy migrace a jejich dopady na nedostupnost dat.
|
Provozní odstávky |
Při instalaci SW vybavení a migraci dat musí být dodrženy následující podmínky:
Odstávky jsou možné jen po předchozí domluvě se zadavatelem! |
|
Opravy HW |
Pro případ poruchy musí být HSM vybaveno funkcí, která v případě poruchy (tj. i ve vypnutém stavu) zajistí prokazatelné vymazání dat.
V případě výměny samotných nosičů s daty ČNB bude postupováno následovně: - u nosičů s magnetickou vrstvou bude demontována elektronika a budou znehodnoceny v tzv. magnetické peci (degausser) a zhotovitel si je na své náklady vyzvedne následující pracovní den po výměně (snahou bude provést znehodnocení okamžitě po výměně, ale zejména pro lokalitu Zličín toto nelze zajistit); - magnetické nosiče, kde nebude možné elektronickou část demontovat, ČNB nevrací a zajistí jejich mechanické zničení. - ostatní nosiče ČNB nevrací a zajistí jejich mechanické zničení. |
Ochrana dat patří mezi klíčové požadavky ČNB. Pokud nebude možné prokazatelně zajistit vymazání dat, není možné HSM jako celek předat zhotoviteli k opravě mimo ČNB.
Tento způsob oprav se týká všech nosičů, které obsahují data ČNB a současně na nich nedochází k jejich ztrátě dat při odpojení napájení (tedy veškeré technologie pevných disků, flash disků, čipových karet apod.)
Znehodnocení nebo zničení zajišťují zaměstnanci objednatele. |
Licencování |
Není rozhodující forma licencování programového vybavení – SW (tj. zda jsou licence na server nebo na kapacitu). Zhotovitel však ve své nabídce musí uvést veškerý dodávaný SW včetně způsobu jeho licencování a včetně počtu dodávaných kusů.
Součástí dodávky budou i veškeré licenční podmínky a případné licenční klíče. |
Licence musí pokrýt minimální požadované množství serverů viz příloha č. 4 a minimální počet slotů (viz „Kapacita a prostor pro data“) a pracoviště 2 programátorů (SDK). |
Omezení
A) Technická omezení
V rámci implementace (realizace) musí zhotovitel dodržet standardy ČNB a současně musí respektovat současnou infrastrukturu tak, aby nedošlo ke změnám, které by mohly ovlivnit funkčnost systémů ČNB.
Jedná se zejména o specifikace uvedené v popisu současného stavu, standardech ČNB, kompatibilitu řešení se stávajícími technologiemi (příloha č. 4), dodržení požadovaných funkcí a vlastností a zajištění dostatečné bezpečnosti.
B) Dopad na IS a servery
Navržené řešení nesmí mít negativní dopad na vlastní IS a servery na kterých běží, tj. zvýšení jejich zátěže z pohledu CPU, RAM, síťových interface apod. Vzhledem k tomu, musí být striktně dodrženy definované parametry viz „Striktně vyžadované funkce a vlastnosti“.
Z hlediska výkonnosti musí nové řešení zajistit minimálně stejné odezvy (při realizaci podpisu nebo dešifrování) jako jsou v současné době, aby nedošlo ke zpomalení provozovaných IS.
C) Zachování stávajícího stavu aplikací/IS
Stávající aplikace/IS nebudou přeprogramovány a budou i nadále používat současná volání služeb HSM modulu (PKCS#11, IAIK PKCS#11 a CNG CSP) a maximálně budou upravena konfiguračně, že mohou volat jiný HSM modul (jiný hostname apod.).
Bezpečnostní požadavky objednatele
Zhotovitel odpovídá za to, že do objektů objednatele (dále jen „ČNB“) budou vstupovat nebo vjíždět pouze jeho pracovníci, kteří jsou jmenovitě uvedeni v písemném seznamu schváleném ČNB (dále jen „seznam“). Tato povinnost se vztahuje i na posádky vozidel zhotovitele vjíždějících do garáží ČNB za účelem složení a naložení nákladu. Seznam zhotovitel předloží ČNB nejpozději v den podpisu smlouvy.
Seznam bude obsahovat tyto položky: jméno, příjmení a číslo průkazu totožnosti pracovníků zhotovitele. Součástí seznamu je ,,Prohlášení o poučení subjektů osobních údajů“ o podmínkách zpracování osobních údajů a o právech subjektů údajů ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších předpisů (dále jen „ZOOÚ“) a ve smyslu obecného nařízení o ochraně osobních údajů - Nařízení Evropského parlamentu a Rady (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 zrušení směrnice 95/46/ES („GDPR“). Zhotovitel v něm prohlásí a nese odpovědnost za to, že jeho pracovníci uvedení v seznamu byli poučeni:
o tom, že zhotovitel předá jejich osobní údaje v rozsahu: jméno, příjmení a číslo průkazu totožnosti České národní bance, sídlem Na Příkopě 28, Praha 1 v rámci plnění této smlouvy, a to za účelem ochrany práv a oprávněných zájmů ČNB (zajištění evidence osob vstupujících do budovy ČNB z důvodu ochrany majetku a osob a správy přístupového systému ČNB);
o veškerých právech subjektu údajů, která mohou uplatnit vůči zhotoviteli a ČNB, zejména o právu právo na přístup k osobním údajům, které jsou o nich zpracovávány, právo na námitku proti zpracování osobních údajů, požadovat nápravu situace, která je v rozporu s právními předpisy, zejména formou zastavení nakládání osobními údaji, jejich opravou, doplněním či odstraněním a právem podat stížnost k Úřadu pro ochranu osobních údajů.
Zhotovitel si je vědom povinností vyplývajících pro správce osobních údajů z GDPR, které nabývá účinnosti 25. května 2018, a obsah poučení upraví tak, aby požadavky tohoto nařízení ode dne jeho účinnosti splňoval.
Požadavky na případné doplňky a změny schváleného seznamu pracovníků zhotovitele je nutno neprodleně oznámit ČNB. Případné doplňky a změny podléhají schválení ČNB. Osoby neschválené ČNB nemohou vstupovat do objektů ČNB, přičemž ČNB si vyhrazuje právo neuvádět důvody jejich neschválení.
Při příchodu do objektů ČNB pracovníci zhotovitele sdělí důvod vstupu, prokáží se osobním dokladem a podrobí se bezpečnostní kontrole. Osoby, které nejsou uvedeny na seznamu, nebudou do objektu ČNB vpuštěny.
Schválení pracovníci zhotovitele musí dbát pokynů bankovních policistů, které se týkají režimu vstupu, pohybu a vjezdu do objektu ČNB. Pracovníci zhotovitele budou do prostorů ČNB vstupovat a v těchto prostorách se pohybovat v režimu návštěv, to znamená vždy pouze v doprovodu zaměstnance ČNB nebo zaměstnance referátu bankovní policie ČNB.
V případě mimořádné události se pracovníci zhotovitele musí řídit pokyny bankovních policistů nebo dozorujícím zaměstnancem ČNB a dále instrukcemi vyhlašovanými vnitřním rozhlasem.
Pracovníci zhotovitele nesmí vnášet do prostor ČNB nebezpečné předměty, jako jsou střelné zbraně, výbušniny apod. O tom co je a není nebezpečný předmět, rozhodují bankovní policisté v souladu s vnitřními předpisy ČNB.
ČNB si vyhrazuje právo nevpustit do objektů ČNB pracovníka zhotovitele, který je zjevně pod vlivem alkoholu, drog nebo jiné omamné látky.
Bez písemného povolení ČNB je zakázáno fotografování a pořizování videozáznamů z interiéru objektů ČNB.
Ve všech prostorech objektů ČNB je přísný zákaz kouření a používání otevřeného ohně. O povolení práce se zvýšeným požárním nebezpečím požádá zhotovitel písemnou formou vždy nejpozději jeden pracovní den před zahájením prací, dozorujícího zaměstnance ČNB. Dále se pracovníci zhotovitele musí zdržet poškozování či zcizení majetku ČNB, a dále zdržet se nevhodného chování vůči zaměstnancům a návštěvníkům ČNB.
Pracovníci zhotovitele uvedení na seznamu se musí před započetím výkonu práce v objektech ČNB prokazatelně seznámit, ve smyslu předpisů o požární ochraně, bezpečnosti a hygieně práce, se specifikami daných objektů ČNB (např. způsob vyhlášení požárního poplachu, určení ohlašovny požáru, seznámení s únikovými cestami, poplachovými směrnicemi, evakuačním plánem, umístěním věcných prostředků požární ochrany apod.). ČNB je oprávněna kdykoliv podrobit kontrole kterékoliv pracovníka zhotovitele uvedeného na seznamu z dodržování těchto předpisů a ustanovení.
Příloha č. 6
(bude doplněno z nabídky vybraného dodavatele)
Příloha č. 7
Podrobný rozpis ceny plnění (v Kč bez DPH)
(bude doplněno podle nabídky vybraného dodavatele)
Příloha č. 8
|
Projekt ID projektu
„Název projektu“
Realizační studie
Verze |
|
Datum verze |
|
Autor |
|
Vedoucí projektu poskytovatele |
|
Vedoucí projektu objednatele |
|
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze |
Datum |
Autor |
Popis změny |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Obsah
1 Úvod
1.1 Účel dokumentu
1.2 Seznam pojmů a zkratek
1.3 Přehled použitých symbolů
1.4 Legislativa, technické normy a standardy
2 Realizace věcného zadání
2.1 Analýza procesů
2.2 Analýza funkčních a procesních požadavků
3 Technická realizace řešení
3.1 Integrace s IS ČNB
3.2 Migrace dat
3.3 Bezpečnost
3.3.1 Analýza bezpečnostních požadavků
3.3.2 Autentizace a autorizace, řízení přístupu
3.3.3 Logování
3.3.4 Zabezpečení síťové komunikace a uložených dat
3.3.5 Soulad s legislativou (Compliance)
3.4 Návrh architektury technického řešení
3.4.1 Požadavky na systémové prostředí
3.5 Způsob implementace do systémového prostředí ČNB
4 Návrh projektové realizace
4.1 Detailní harmonogram realizace
4.2 Požadavky na součinnost (pro externí dodávku)
4.3 Akceptační testy
4.4 Školení
4.5 Dokumentace
5 Popis režimu provozní podpory
6 Registr změn
Hlavní kapitoly realizační studie jsou povinné, struktura podkapitol je doporučená, možno ji rozšiřovat či upravovat dle potřeb projektu.
[Dokument realizační studie popisuje způsob realizace, aktivace a následného provozu služby včetně analýzy funkčních požadavků, softwarové architektury a systémových požadavků tak, aby byla prokázána realizovatelnost všech objednatelem zadaných požadavků. Text kurzívou v hranatých závorkách je návodem, neměl by zůstat součástí výsledného dokumentu.]
[Výčet klíčových zkratek a pojmů s jejich vysvětlením]
Termín/Zkratka |
Popis/Význam |
|
|
|
|
|
|
|
|
|
|
[Popis použitých grafických symbolů v dokumentu]
Grafický symbol |
Význam |
|
|
|
|
|
|
[Seznam legislativy, standardů a norem používaných při realizaci řešení.]
Č. zákona/ ČSN..... ISO...... |
Název/Popis |
|
|
|
|
2.Realizace věcného zadání
[Kapitola obsahuje analýzu procesů spojených s používáním nyní implementovaného řešení HSM modulů v prostředí Objednatele a jejich převod/změnu pro nově implementované HSM modulu provozované v QSCD režimu. Pro jejich grafické znázornění lze použít například UML Activity diagram, nebo BPMN (Business Process Model and Notation), dále diagramy typu MS Visio apod.].
[Kapitola obsahuje mapování požadavků na cílové řešení – viz příloha č. 4 návrhu smlouvy („Technická a funkční specifikace předmětu plnění“). Popis tak ve stručné formě představuje způsob realizace jednotlivých požadavků.]
ID1) |
Popis požadavku |
Název funkcionality |
Poznámka / jak bude realizováno |
|
|
|
|
|
|
|
|
|
|
|
|
3.Technická realizace řešení
[Kapitola obsahuje:
popis možností integrace řešení HSM modulů provozovaných v QSCD režimu s jednotlivými stávajícími a budoucími (projektovanými) IS ČNB,
detailní popis rozhraní pro komunikaci s IS ČNB.]
[Kapitola obsahuje analýzu přechodu z původního zapojení a provozu HSM modulů a nově projektované zapojení z hlediska jejich převoditelnosti a datové migrace (tj. jednoznačné srovnání datových objektů, které budou využívány při migraci dat mezi oběma systémy) a popis vlastní migrace. Na analýze se podílejí jak zadavatel, tak poskytovatel.]
[Kapitola obsahuje popis řešení z hlediska bezpečnosti, integrity a důvěrnosti dat, relevantní normy, politiky a standardy, vnitřní předpisy Objednatele.]
[Podkapitola obsahuje analýzu bezpečnostních požadavků.]
[V podkapitole je popsán princip řízení přístupů k informacím resp. informačním aktivům nové řešení HSM modulů v QSCD režimu: jakým prostřednictvím přistupují interní a externí uživatelé, popis technických (aplikačních) účtů – bez časového omezení; způsob automatického blokování účtů uživatelů při ukončení zaměstnaneckého poměru v ČNB, povolené protokoly apod.]
[V podkapitole je popsán způsob logování a monitorování logů, napojení na SIEM.]
[V podkapitole je popsán způsob, jak je zabezpečena síťová komunikace mezi HSM moduly a klientskými informačními systémy a zabezpečení uložených dat – FileSystem/DataBase/jiné.]
[V podkapitole je popsán způsob, jak je zabezpečen soulad s legislativou – např. ZoKB, ISO20022, eIDAS apod. V případě, že navrhované řešení nebude splňovat nějaké legislativní požadavky, uvede se to v této kapitole včetně zdůvodnění proč.]
[Kapitola popisuje globální architekturu řešení HSM modulů v QSCD režimu a fyzickou architekturu nasazení řešení v infrastruktuře ČNB s ohledem na provoz, high-availability, monitoring, zálohování a archivaci.]
[Podkapitola obsahuje SW a HW specifikaci pro nasazení v prostředí ČNB. Součástí je i sizing HW prostředků pro účely implementace. Různá prostředí provoz/test/vývoj/školení/atd. jsou popsána zvlášť.]
Tabulka 1: HW specifikace
Prvek |
Typ |
Výkon |
RAM |
Disková kapacita |
Síťové rozhraní |
Poznámka |
APP1 |
Virtuální server |
2 – 4 virtuální CPU, 2 – 3 GHz |
4 – 8 GB |
15 GB |
100 Mbps |
|
|
|
|
|
|
|
|
Tabulka 2: SW specifikace
Prvek |
OS |
Databázové služby |
Aplikační služby |
Poznámka |
APP1 |
Windows Server 2016 R2 ENG x64 |
Oracle client 10g |
MS IIS 7.5 XXX.XXX 3.5 SP1 |
|
|
|
|
|
|
[Kapitola obsahuje postup nasazení řešení do cílového prostředí s ohledem na stanovení příslušné součinnosti ze strany ČNB.]
4.Návrh projektové realizace
[Harmonogram realizace uvádí rozpad realizace projektu do jednotlivých přírůstků (dílčích plnění), etap, fází a činností s ohledem na dodržení stanovených termínů/lhůt. Harmonogram musí obsahovat milníky pro předání díla nebo jeho částí k akceptačnímu řízení.]
[V kapitole je uveden rozsah kapacit požadovaných poskytovatelem po objednateli]
ID |
Popis součinnosti |
Rozsah |
Čerpání |
|
|
|
|
Legenda:
ID: jedinečný identifikátor požadované součinnosti
Popis součinnosti: popis aktivit, požadovaných poskytovatelem po objednateli
Rozsah: odhadovaný rozsah požadovaných kapacit v čld
Čerpání: četnost, způsob čerpání kapacit např. 1x týdně; 2hod v Pá
[V kapitole je uveden seznam všech připravovaných akceptačních testů, které kompletně ověří požadovanou funkcionalitu systému a zodpovědnost za vypracování testovacích scénářů]
ID testu |
Testovaná oblast |
Testovací scénář |
ID požadavku2) |
Testovací scénář vypracovává |
|
|
|
|
|
Legenda:
ID scénáře: jedinečný identifikátor testovacího scénáře
Testovaná oblast: oblast testování např.: Komunikace s IS na Oracle Linux, ….
Testovací scénář: popis testovacího scénáře
ID požadavku: jedinečné identifikátory požadavků objednatele, které jsou daným testovacím scénářem ověřovány.
Testovací scénář vypracovává: jméno/firma autora testovacího scénáře
[Kapitola detailněji popisuje způsob zajištění školení a proškolení příslušných pracovníků, okruh školených uživatelů a správců, kdo zodpovídá za zpracování školící dokumentace a pokud není uvedeno v harmonogramu, tak i předpokládané termíny školení]
[V kapitole je uveden seznam technické, provozní a uživatelské dokumentace a zodpovědnost za její zpracování/aktualizaci.]
5.Popis režimu provozní podpory
[Kapitola detailněji popisuje způsob zajištění provozní podpory. Jedná se například o konkretizaci kontaktních bodů podpory a kontaktního místa pro dodávku náhradního HSM modulu. Dále o případnou doplňkovou diagnostiku a mechanizmu uzavření řešení závady.]
6.Registr změn
[V kapitole je uveden seznam změn oproti předběžné studii/zadávací dokumentaci, jejich akceptace a jejich dopady do projektu – časové, zdrojové a finanční.]
ID změny |
Popis změny |
Akceptována Ano/Ne |
Realizace (termín, zdroje a finance) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Příloha č. 9
Obecná pravidla pro dodavatele v oblasti bezpečnosti IT
Pokud jsou tato obecná pravidla v rozporu s ustanovením textu smlouvy nebo zadávací dokumentace nebo její jinou přílohou, má přednost ustanovení textu smlouvy nebo zadávací dokumentace nebo její jiná příloha.
Poskytovatel je povinen zajistit, že jeho pracovníci či poddodavatelé a jejich pracovníci, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech skutečnostech, se kterými se u objednatele seznámí a které nejsou veřejně dostupné. Povinnost mlčenlivosti není časově omezena.
Poskytovatel je rovněž povinen chránit informace, které nejsou veřejně dostupné, zejména předanou dokumentaci, před jejich prozrazením a/nebo zpřístupněním neoprávněným osobám a dále použít získané informace výhradně pro účely plnění smlouvy s ČNB.
Poskytovatel nemá vzdálený přístup k systémům a do počítačové sítě ČNB.
Pracovníci poskytovatele, kteří budou samostatně přistupovat k informačním systémům a systémovému prostředí ČNB, se před nebo při prvním přístupu musí seznámit s bezpečnostními požadavky a svými povinnostmi vyplývajícími z vnitřních předpisů ČNB.
Poskytovatel a jeho pracovníci nejsou oprávněni:
obcházet bezpečnostní mechanizmy prostředků výpočetní techniky;
sdělovat své přístupové údaje k systémům ČNB;
sdílet přístup k systémům ČNB (umožnit jinému pracovat pod uživatelovým oprávněním);
provádět akce požadované třetí osobou (instalace softwaru, návštěva webových stránek apod.) bez ověření oprávněnosti požadavku.
Poskytovatel a jeho pracovníci jsou povinni:
okamžitě nahlásit sekci informatiky ČNB, pokud identifikují možnost obejití bezpečnostních mechanizmů prostředků výpočetní techniky. To neplatí pro dodavatele, jejichž předmět smlouvy obsahuje tuto činnost;
při opuštění pracovní stanice stanici uzamknout (např. vytažením multifukčního průkazu ze stanice) nebo se odhlásit, a ověřit, že k odhlášení/uzamčení opravdu došlo;
bezpečně zlikvidovat nepotřebná výměnná média (např. CD/DVD, flash disk, paměťová karta) prostřednictvím služby HelpDesku ČNB;
bez prodlení odebrat z tiskárny vytištěné dokumenty, popřípadě pro zajištění důvěrnosti použít zabezpečený tisk, pokud to nastavení tiskárny umožňuje;
v případě detekce viru nebo podezření na přítomnost škodlivého kódu neprodleně kontaktovat HelpDesk ČNB a stanici kompletně prověřit antivirovým programem za případné spolupráce HelpDesku ČNB.
Pracovníci poskytovatele nesmí:
zaznamenávat heslo tak, aby mohlo být snadno identifikováno (týká se i zapisování do elektronických dokumentů, např. Notepad). Pro uchování je možné použít například bezpečné úložiště na čipové kartě uživatele (SmartNotes);
používat stejná hesla v systémech ČNB a pro přístup do dalších systémů a aplikací mimo ČNB (např. soukromá e-mailová schránka, Facebook, LinkedIn).
Pracovníci poskytovatele nejsou oprávněni:
používat soukromou e-mailovou schránku pro činnosti související s plněním dle smlouvy, kromě výjimečné situace, která nesnese odkladu a při níž hrozí nebezpečí z prodlení v případě nedostupnosti nebo poruchy pracovního e-mailu;
nastavovat automatické přeposílání e-mailů z pracovní e-mailové adresy mimo systémové prostředí ČNB;
ukládat jiné než veřejné informace mimo úložiště pod správou ČNB nebo poskytovatele (případně pod správou smluvně zajištěného partnera), zejména do cloudových služeb (např. xxxx.xx, xxxxxxxxxxxx.xx, Google Disk, Microsoft OneDrive a další).
Poskytovatel a jeho pracovníci nejsou oprávněni:
nepovoleně používat, kopírovat a šířit software, jako např.:
instalovat nebo spouštět na počítačích ČNB soukromě pořízený software (včetně softwaru licencovaného na uživatele jako soukromou osobu);
instalovat nebo spouštět na počítačích ČNB z internetu stažený software (včetně komerčního software, software typu shareware, freeware, public domain a software licencovaného modelem GPL – General Public Licence). To neplatí v případech, kdy předmět smlouvy obsahuje tuto činnost;
instalovat či přenášet software ve vlastnictví ČNB na jiné počítače ČNB, na své soukromé počítače nebo na počítače třetích stran nebo pořizovat kopie softwaru instalovaného v počítači ČNB. To neplatí
pro situace výslovně schválené a popsané v jiném vnitřním předpisu (např. vzdálený přístup ze zařízení, které není ve vlastnictví ČNB) a
v případech, kdy předmět smlouvy obsahuje tuto činnost;
používat nebo poskytnout neoprávněně jiným uživatelům sériová čísla, licenční klíče, hardwarové klíče nebo jiné technické prostředky sloužící k zajištění ochrany nebo jednoznačné identifikaci vlastníka licence softwaru získané v ČNB;
bránit spouštění nástrojů sloužících pro automatizované kontroly nainstalovaného a spouštěného softwaru a provádět činnosti, které by vedly ke zkreslení získaných dat z těchto nástrojů.
Archivace elektronické pošty
Zpráva zaslaná tak, že alespoň jedním z adresátů zprávy je emailová adresa ...@xxx.xx, se ukládá současně s přijetím i do dlouhodobého archivního úložiště.
Veškeré zprávy odesílané z emailové adresy ...@xxx.xx se ukládají do dlouhodobého archivního úložiště současně s odesláním.
Kontrola přístupu na Internet
Z důvodu zvláštní povahy činnosti ČNB a z toho plynoucí povinnosti zajištění bezpečnosti informačních systémů ČNB, z nichž některé jsou součástí kritické informační infrastruktury státu, jsou přístupy uživatelů na Internet ze sítě ČNB automaticky zaznamenávány na úrovni domén 2. řádu (tj. např. xxx.xx).
1) ID požadavku objednatele ze zadávací dokumentace případě identifikace části smlouvy, kde se požadavek nachází.
2) Požadavky z předběžné studie (funkční a specifické)
19