Smlouva o dodávce centrálního digitálního archivu České pošty Číslo 2021/01697

Smlouva o dodávce centrálního digitálního archivu České pošty č.2021/01697

Smlouva o dodávce centrálního

digitálního archivu České pošty

Číslo 2021/01697

Česká pošta, s.p.
se sídlem:	Politických vězňů 000/0, 000 00 Xxxxx 0
IČO:	47114983
DIČ:	CZ47114983
zastoupen:	Ing. Xxxxxxxxxx Xxxxxxxx, ředitelem úseku ICT a eGovernment
zapsán v obchodním rejstříku u:	Městského soudu v Praze, oddíl A, vložka 7565
bankovní spojení:	xxx. xxx
(dále jako „Objednatel“)

a

GC System a.s.
se sídlem:	Xxxxxxxx 000/00, Xxxxxx, 000 00 Xxxx
IČO:	64509826
DIČ:	CZ 64509826
zastoupena:	Ing. Xxxxxxx Xxxxxxxx, předsedou představenstva
zapsána v obchodním rejstříku u:	Krajského soudu v Brně, oddíl B, vložka 1927
bankovní spojení:	xxx.
	čxxx
(dále jako „Dodavatel“)

dále jednotlivě jako „Smluvní strana“ nebo společně jako „Smluvní strany“ uzavírají v souladu s ustanovením § 1746 odst. 2 zákona č. 89/2012 Sb., občanského zákoníku, ve znění pozdějších předpisů (dále jen „Občanský zákoník“), zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, ve znění pozdějších předpisů (dále jen „Autorský zákon“), a zákonem č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „Zákon o zadávání veřejných zakázek“), tuto smlouvu o dodávce centrálního digitálního archivu České pošty (dále jen „Smlouva“).

Preambule

Objednatel provedl zadávací řízení k veřejné zakázce „Centrální Digitální Archiv ČP“ (dále jen „Zadávací řízení“) na uzavření této Smlouvy. Tato Smlouva je uzavřena s Dodavatelem na základě výsledku Zadávacího řízení. Objednatel tímto ve smyslu ust. § 1740 odst. 3 Občanského zákoníku předem vylučuje přijetí nabídky na uzavření této Xxxxxxx s dodatkem nebo odchylkou.

1. Účel Smlouvy

   1. Účelem této Smlouvy je zajistit naplnění legislativních povinností Objednatele formou vybudování Centrálního digitálního archivu České pošty, s.p. (dále jen „CDA“). CDA představuje digitální obdobu fyzického archivu pro dlouhodobé ukládání informací a dokumentů Objednatele a má zajistit efektivní správu a archivaci elektronických dokumentů Objednatele.

2. Předmět Smlouvy

   1. Předmětem této Smlouvy je závazek Dodavatele k provedení implementace a zajištění provozu CDA v souladu se Smlouvou a svou nabídkou v Zadávacím řízení, který zahrnuje:

1. dodávku hardwarových komponent – kompletní hardware potřebný pro dlouhodobé garantované uložení dokumentů a dat, včetně provozu řešení CDA, a jeho instalace, včetně veškeré dokumentace (např. produktová, uživatelská). Specifikace HW dodávaného Dodavatelem je uvedena v Příloze č. 1 a 3 Smlouvy (dále jen „HW CDA“);

2. dodávku plně funkčního softwarového řešení CDA, customizaci, implementaci, integraci, testování, seznámení administrátorů a uživatelů s prostředím CDA, dodání dokumentace a uživatelských příruček, poskytnutí zdrojových kódů doprogramovaných částí softwaru CDA, importních skriptů pro prvotní migraci a exportních skriptů pro případný export dat ze softwaru CDA do následného systému, projektové vedení a udělení práva software CDA užít, tj. Licenci v rozsahu dále uvedeném ve Smlouvě. Požadavky na software CDA jsou blíže uvedeny v Příloze č. 1 a 2 Smlouvy (dále jen „SW CDA“);

3. migraci stávajících, již existujících dat ze stávajícího systému Objednatele EMC CENTERA do nově navrženého prostředí CDA;

4. technickou podporu hardwarových a softwarových komponent – maintenance CDA po dobu 48 měsíců, zahrnující

• metodickou podporu archivace (aktualizace dokumentace a uživatelských příruček k CDA, seznámení administrátorů a uživatelů s prostředím CDA),

• zajištění legislativního souladu CDA po celou dobu účinnosti Xxxxxxx,

• technickou podporu hardwarových a softwarových komponent CDA,

• aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA,

postupem dle této Smlouvy, a to v požadované kvalitě a úrovních dle Přílohy č. 1 Smlouvy (služby technické podpory a maintanance CDA společně dále jen „Podpora“);

(plnění dle čl. 2.1 Smlouvy společně jen „Plnění“). Bližší specifikace Plnění je uvedena v Příloze č. 1 - 4 Smlouvy.

2. Dodavatel se zavazuje poskytnout Plnění ve sjednaném čase, rozsahu a sjednaným způsobem. Dodavatel se zavazuje poskytnout Plnění v provedení a jakosti odpovídající aktuálnímu stavu technologického vývoje v dané kategorii produktů, jakož i požadavkům Objednatele vymezeným v Příloze č. 1 - 3 Smlouvy. Dodavatel převede vlastnické právo k hmotných složkám Plnění, tj. k hardwarovým komponentům, dokumentacím a uživatelským příručkám na Objednatele.

3. Objednatel se tímto zavazuje Plnění poskytnuté v souladu se Smlouvou převzít a zaplatit za něj sjednanou cenu dle čl. 3 Smlouvy.

4. Po uzavření Smlouvy sdělí Objednatel Dodavateli evidenční číslo pro účely fakturace Plnění.

1. Cena Plnění a platební podmínky

   1. Celková cena za poskytnutí Plnění dle čl. 2.1 písm. a) – c) Smlouvy činí 23.036.882 Kč bez DPH (slovy: dvacettřimilionůtřicetšesttisícosmsetosmdesátdva korun českých). Celková cena zahrnuje:

1. Cenu za dodávku HW CDA dle čl. 2.1 písm. a) Xxxxxxx ve výši: 8.299.515 Kč bez DPH (slovy: osmmilionůdvěstědevadesátdevěttisícpětsetpatnáct korun českých);

2. Cenu za implementaci SW CDA dle čl. 2.1 písm. b) Xxxxxxx ve výši: 9.537.367 Kč bez DPH (slovy: devětmilionůpětsettřicetsedmtisíctřistašedesátsedm korun českých);

3. Cenu za migraci stávajících dat dle čl. 2.1 písm. c) Xxxxxxx ve výši: 5.200.000 Kč bez DPH (slovy: pětmilionůdvěstětisíc korun českých).

2. Za poskytování Podpory dle čl. 2.1 písm. d) Smlouvy v požadované kvalitě a úrovních se sjednává měsíční cena ve výši 247.776 Kč bez DPH (slovy: dvěstěčtyřicetsedmtisícsedmsetsedmdesátšest korun českých).

3. Platební kalendář za řádně poskytnuté Plnění dle čl. 2.1 písm. a) – c) Xxxxxxx:

Plnění	Platební milník
Dodávka a instalace HW CDA (čl. 2.1 písm. a) Smlouvy)	Po řádném dodání HW CDA komponentů, instalaci a potvrzení Předávacího protokolu dle čl. 5.4 Smlouvy.
Implementace SW CDA, integrace do systému Objednatele (čl. 2.1 písm. b) Smlouvy)	Po řádné implementaci a integraci CDA do prostředí Objednatele, úspěšném ukončení testování, seznámení pracovníků Objednatele s CDA a potvrzení Akceptačního prokolu dle čl. 5.5 Smlouvy.
Migrace stávajících dat (čl. 2.1 písm. c) Smlouvy)	Po řádném dokončení migrace stávajících dat z EMC CENTERA do SW CDA a potvrzení Akceptačního protokolu dle čl. 5.5 Smlouvy.

4. Daňový doklad v případě Plnění dle čl. 2.1 písm. a) až c) Xxxxxxx bude vystaven Dodavatelem v souladu s platebním kalendářem po řádném poskytnutí příslušné části Plnění bez vad v souladu se Smlouvou. Nedílnou součástí daňového dokladu je Objednatelem potvrzený Předávací protokol dle čl. 5.4 Smlouvy (v případě Plnění dle čl. 2.1 písm. a) Smlouvy)/Akceptační protokol dle čl. 5.5 Smlouvy (v případě Plnění dle čl. 2.1 písm. b) a c) Smlouvy), stvrzující řádné poskytnutí části Plnění Objednateli. Dnem uskutečnění zdanitelného plnění je den potvrzení Předávacího protokolu dle čl. 5.4 Smlouvy /Akceptačního protokolu dle čl. 5.5 Smlouvy Objednatelem.

5. Cena Podpory dle čl. 2.1 písm. d) Xxxxxxx poskytnuté v příslušném kalendářním měsíci bude Objednatelem hrazena měsíčně předem. Dodavatel vystaví daňový doklad vždy první den příslušného období poskytování Podpory (kalendářního měsíce), tento den se zároveň považuje za den uskutečnění zdanitelného plnění.

6. Měsíční cena za poskytování Podpory bude účtována a hrazena ode dne zahájení poskytování Podpory. O úrovni poskytování Podpory v daném kalendářním měsíci je povinností Dodavatele vyhotovit Report SLA.

7. Pokud bude Podpora poskytována jen po část kalendářního měsíce, hradí se za příslušný kalendářní měsíc poměrná část měsíční ceny Podpory. V případě, že dojde k ukončení Smlouvy před uplynutím období, za které byla Objednatelem uhrazena cena za Podporu předem, je Dodavatel povinen nejdéle do 10 kalendářních dnů od data ukončení Smlouvy vystavit a zaslat Objednateli opravný daňový doklad na částku uhrazené Podpory, kterou Objednatel nespotřeboval, a tuto částku zaslat na účet Objednatele uvedený v záhlaví této smlouvy.

8. Celková cena za poskytnutí Plnění dle čl. 2.1 písm. a) – c) Smlouvy a jednotková cena Podpory dle čl. 2.1 písm. d) Xxxxxxx je konečná a nejvýše přípustná a jsou v ní zahrnuty veškeré náklady Dodavatele související s poskytováním Plnění, veškeré odměny za využití Licence dle čl. 8 Smlouvy ve sjednaném rozsahu i cena všech hmotných nosičů či jiných předmětů, jejichž prostřednictvím bude předáno Plnění.

9. Cena Plnění zahrnuje veškeré náklady Dodavatele spojené s řádným a úplným plněním Smlouvy a poskytnutím Plnění Objednateli, včetně těch, které ve Smlouvě výslovně uvedeny nejsou, ale Dodavatel jakožto odborník a osoba poskytující Plnění s odbornou péčí podle Xxxxxxx o nich ke dni nabytí účinnosti Smlouvy při vynaložení úsilí, které lze spravedlivě požadovat, vědět měl nebo mohl vědět, že jsou k poskytnutí řádného Plnění nezbytné.

10. V ceně dodávky HW CDA jsou zahrnuty zejména:

1. doprava do místa plnění určeného Objednatelem;

2. náklady na balení;

3. clo, celní poplatky, daně (vyjma DPH, která bude připočítána v souladu s čl. 2.4 Všeobecných obchodních podmínek, které tvoří Přílohu č. 6 Smlouvy) a zálohy;

4. recyklační poplatky a ekologická likvidace a činnosti s ní spojené;

5. Záruka za jakost a záruční servis v rozsahu stanoveném Smlouvou; a

6. veškeré jiné náklady a poplatky nezbytné pro řádné plnění Smlouvy.

1. Splatnost daňového dokladu vystaveného Dodavatelem je šedesát (60) kalendářních dní ode dne vystavení Dodavatelem.

2. Objednatel neposkytuje Dodavateli jakékoliv zálohy na cenu.

3. Dodavatel se zavazuje, že na výzvu Objednatele bude akceptovat oboustranné elektronické zasílání dokladů spojených s poskytováním Plnění (zejména daňové doklady) prostřednictvím portálu SAP Ariba Network. Dodavatel se zavazuje v takovém případě zaregistrovat na portále SAP Ariba Network. Objednatel iniciuje registraci Dodavatele k portálu SAP Ariba Network zasláním elektronické výzvy na kontaktní e-mail Dodavatele (čl. 12.1 Smlouvy). Objednatel prohlašuje, že pro požadované aktivity Dodavatele v rámci nákupního procesu je postačující registrace se standardním účtem Ariba Network, který je bezplatný. Je-li Dodavatel již v SAP Ariba Network registrován, pak lze pro elektronickou komunikaci využít existující AN-ID.

4. Nevyzval-li Objednatel Dodavatele k zasílání daňových dokladů prostřednictvím portálu SAP Ariba ve smyslu čl. 3.13 Xxxxxxx, zašle Dodavatel fakturu - daňový doklad Objednateli způsobem dle čl. 2.6 Všeobecných obchodních podmínek, které tvoří Přílohu č. 6 Xxxxxxx (dále jen „VOP“).

1. Doba, místo Plnění

   1. Plnění dle čl. 2.1 písm. a) – c) této Smlouvy bude Dodavatelem poskytnuto v souladu se závazným harmonogramem (dále jen „Harmonogram“).

   Milník - dílčí Plnění	Termín
   Dodávka a instalace HW CDA (čl. 2.1 písm. a) Smlouvy)	D + 3 měsíce
   Migrace stávajících dat (čl. 2.1 písm. c) Smlouvy)	D + 6 měsíců
   Implementace SW CDA, integrace do systému Objednatele (čl. 2.1 písm. b) Xxxxxxx), zahájení poskytování Podpory	D + 12 měsíců
   Vysvětlivky: D ……… den nabytí účinnosti Smlouvy

   2. Poskytování Podpory dle čl. 2.1 písm. d) Xxxxxxx bude Dodavatelem zahájeno po předání SW CDA do produkčního prostředí na základě podpisu Akceptačního protokolu dle čl. 5.5 Smlouvy k dílčímu Plnění dle 2.1 písm. b) Smlouvy.

   3. Místem plnění je: Česká pošta, s.p., Xxxxxxxx 00/0, Xxxxx 0, a Xxxxxxxx 0, Xxxxx 00.

2. Kontrola a akceptace

   1. Řádným poskytnutím Plnění se rozumí implementace požadovaného HW CDA a SW CDA, včetně migrace dat a integrace komunikačního rozhraní do interní infrastruktury Objednatele tak, aby Objednatel mohl zahájit využívání Licence dle čl. 8 Smlouvy a bylo mu umožněno užívání SW CDA ve sjednaném rozsahu.

   2. Spolu s předmětem Plnění bude předána také veškerá dokumentace (produktová, uživatelská) vztahující se k HW CDA a k SW CDA, bez níž by nemohlo docházet k řádnému užívání CDA. Dokumentace bude předána v elektronické podobě, v českém jazyce.

   3. Plnění dle čl. 2.1 písm. a) Xxxxxxx je Xxxxxxxxx povinen dodat Objednateli v souladu s Harmonogramem v pracovní dny v čase od 8:00 do 16:00 hod.

   4. Předání a převzetí HW CDA proběhne na základě protokolárního předání instalovaného HW CDA. Smluvní strany provedou fyzickou kontrolu předávaného HW CDA v místě předání a v případě řádného Plnění podepíšou předávací protokol na dodaný HW CDA (dále jen „Předávací protokol“). HW CDA lze předávat i po částech.

   5. Kontrola a akceptace Plnění dle čl. 2.1 písm. b) a písm. c) Smlouvy probíhá podle parametrů uvedených v Příloze č. 1 Smlouvy, po testování CDA pracovníky Objednatele a je potvrzena podpisem akceptačního protokolu (dále jen „Akceptační protokol“), a to následujícím způsobem:

1. Dodavatel zpracuje návrh Akceptačního protokolu a předkládá jej Objednateli. Předání a akceptace Objednatelem bude potvrzena podpisem zástupce Objednatele ve věcech technických na Akceptačním protokolu.

2. Objednatel akceptaci Plnění odmítne v případě, že Plnění vykazuje
   na základě vyhodnocení akceptačních kritérií specifikovaných v Příloze č. 1 Smlouvy natolik vážné vady, že nemůže sloužit svému účelu vůbec nebo s výraznými omezeními. V případě méně vážných vad může Objednatel akceptaci Plnění odmítnout nebo Plnění akceptovat s výhradami. Neodmítnutí převzetí Plnění však nezbavuje Objednatele jeho nároků z odpovědnosti Xxxxxxxxxx za vady.

3. V případě, že předání nebo akceptace byla provedena s výhradami Objednatele, je Dodavatel povinen zjednat nápravu do pěti (5) kalendářních dnů, nebude-li dohodou Smluvních stran stanoveno jinak.

4. Bylo-li dílčí Plnění předáno a akceptováno, je Dodavatel oprávněn vystavit daňový doklad na část ceny. Bylo-li předáno nebo akceptováno s výhradou, Dodavateli vznikne právo na zaplacení části ceny a vystavení daňového dokladu až po zjednání nápravy a bezvýhradné akceptaci části Plnění.

6. Práva a povinnosti smluvních stran

   1. Plnění musí být poskytnuto bez jakýchkoli vad, ať již faktických či právních, v souladu s veškerými právními předpisy, technickými požadavky a technickými a bezpečnostními normami, které se na Plnění vztahují, a to jak normami závaznými, tak doporučujícími.

   2. V rámci realizace předmětu Smlouvy má každá Smluvní strana zejména následující povinnosti:

1. vzájemně spolupracovat a poskytovat druhé Smluvní straně veškeré informace potřebné pro řádné plnění svých povinností vyplývajících ze Smlouvy;

2. poskytovat druhé Smluvní straně úplné, pravdivé a včasné informace o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění dle Smlouvy;

3. plnit své povinnosti vyplývající ze Smlouvy tak, aby nedocházelo k prodlení s plněním povinností vázaných k jednotlivým termínům.

1. Objednatel se zavazuje v termínech stanovených touto Smlouvou, jinak v termínech odpovídajících postupu realizace Plnění, poskytnout Dodavateli potřebnou součinnost v následujícím rozsahu:

1. poskytovat Xxxxxxxxxx potřebné dokumenty a informace, je-li povinnost k jejich poskytnutí uvedena ve Smlouvě (včetně příloh) nebo bylo-li tak dohodnuto v rámci jednání Smluvních stran;

2. umožnit pracovníkům Dodavatele uvedeným v písemném seznamu předloženém Dodavatelem v předem dohodnutém termínu přístup na pracoviště Objednatele, je-li to nezbytné pro realizaci předmětu Smlouvy, a umožnit Dodavateli vzdálený přístup do informačních systémů Objednatele, je-li to pro realizaci předmětu Smlouvy nezbytné;

3. seznámit Xxxxxxxxxx s interními pravidly a předpisy Objednatele v oblasti bezpečnosti ICT systémů a BOZP, které bude Dodavatel povinen dodržovat;

4. dle potřeby a řešeného tématu zajistit účast a součinnost odpovědných pracovníků Objednatele při schvalování, analýzách, testování, akceptaci, seminářích, školeních, apod.;

5. poskytovat informace o ostatních projektech v daném prostředí, pokud budou mít jakýkoli vliv na plnění povinností Dodavatele z této Smlouvy;

6. zajistit součinnost třetích stran, které nejsou v přímém smluvním vztahu s Dodavatelem, avšak jejichž činnost se přímo i nepřímo může dotýkat plnění dle této Smlouvy, pokud bude tato součinnost nezbytná pro plnění povinností Dodavatele;

7. zajistit datovou a internetovou konektivitu, tj. komunikační kanál poskytující připojení k dílčím systémům Objednatele.

1. Dodavatel se v souvislosti s realizací předmětu této Smlouvy zavazuje zejména:

1. poskytovat Plnění v souladu se Smlouvou, řádně a včas, s řádnou a odbornou péčí a potřebnými odbornými schopnostmi pro poskytování Plnění tak, aby bylo dosaženo účelu Smlouvy;

2. poskytovat Plnění v souladu s obecně závaznými právními předpisy a pokyny Objednatele, pokud tyto nejsou v rozporu s těmito normami nebo zájmy Objednatele. Dodavatel je povinen při výkonu své činnosti včas písemně upozornit Objednatele na zřejmou nevhodnost jeho pokynů, jejichž následkem může vzniknout újma nebo nesoulad s obecně závaznými právními předpisy. Pokud Objednatel navzdory tomuto upozornění trvá na svých pokynech, Dodavatel neodpovídá za jakoukoli újmu vzniklou v této příčinné souvislosti;

3. při plnění předmětu této Smlouvy brát na zřetel provozní potřeby Objednatele, postupovat podle pravidel obvyklých pro zpracování dat a v úzké součinnosti s Objednatelem provádět jednotlivá dílčí Plnění;

4. pokud v průběhu plnění povinností dle Smlouvy vznikne na straně Dodavatele potřeba využít služeb třetí strany - poddodavatele, učinit tak jen po předchozím souhlasu Objednatele a jen tehdy, pokud bude nový poddodavatel splňovat potřebnou kvalifikaci. V případě, že Objednatel souhlas k využití poddodavatele neudělí, není Dodavatel oprávněn takovou poddodávku udělit. V případě souhlasu Objednatele a následného využití služeb třetí strany bude Xxxxxxxxx odpovídat za třetí stranu, jako by plnil sám, včetně odpovědnosti za způsobenou újmu. Dodavatel je povinen zajistit, aby jeho poddodavatel poskytoval plnění v souladu s touto Smlouvou a dodržoval veškerá ujednání mezi Smluvními stranami;

5. informovat bezodkladně Objednatele o jakýchkoliv zjištěných překážkách Plnění, byť by za ně Dodavatel neodpovídal a o uplatněných nárocích třetích osob, které by mohly Plnění ovlivnit;

6. dbát, aby nebyla poškozena dobrá obchodní pověst a dobré jméno Objednatele. Při poskytování plnění musí Dodavatel vždy sledovat zájmy Objednatele;

7. činit všechna potřebná opatření k tomu, aby jeho činností nedošlo ke škodám na majetku Objednatele, jeho zaměstnanců nebo třetích stran, anebo k poškození zdraví zaměstnanců Objednatele nebo třetích osob, jimž by Objednatel za takto způsobenou újmu odpovídal;

8. odčinit majetkovou i nemajetkovou újmu vzniklou Objednateli činností, nečinností nebo opomenutím Dodavatele;

9. pro poskytování Plnění neužívat zaměstnance Objednatele, ani s nimi v této souvislosti neuzavírat jakýkoliv právní vztah s výjimkou potřebné a přiměřené součinnosti, není-li v této Smlouvě stanoveno jinak;

10. na vyžádání Objednatele se zúčastnit osobní schůzky (mimo jednání projektového týmu), pokud Objednatel požádá o schůzku nejpozději dva (2) pracovní dny předem. V mimořádně naléhavých případech je možno tento termín po dohodě obou Smluvních stran zkrátit;

11. dodržovat veškerá interní pravidla a předpisy Objednatele týkající se bezpečnosti ICT systémů, BOZP a požární ochrany, byl-li s nimi Objednatelem seznámen, a účastnit se na výzvu Objednatele školení v oblasti bezpečnosti ICT systémů, pravidel BOZP a požární ochrany Objednatele;

12. poskytovat součinnost při  provozních úpravách SW CDA s tím, že součinnost poskytovaná nad rámec požadavků Objednatele na SW CDA dle Přílohy č. 1 Smlouvy bude poskytována jako Xxxxxxx;

13. plnit v kvalitě potřebné pro dosažení parametrů stanovených v Příloze č. 1 Smlouvy a odpovídat za to, že případné vady Plnění poskytnutého dle Smlouvy řádně odstraní, případně nahradí plněním bezvadným v souladu se Smlouvou;

14. umožnit Objednateli kontrolovat, zda Dodavatel poskytuje Plnění řádně;

15. mít po celou dobu trvání Smlouvy sjednáno pojištění odpovědnosti za majetkové i nemajetkové újmy způsobené v souvislosti s plněním Smlouvy Dodavatelem nebo osobou, za niž odpovídá, s pojistnou částkou nejméně 1 000 000 Kč (slovy: jeden milion korun českých). Při vzniku pojistné události zabezpečuje ihned po jejím vzniku veškeré úkony vůči pojistiteli Dodavatel. Objednatel je povinen poskytnout v souvislosti s pojistnou událostí Dodavatele veškerou součinnost, která je v jeho možnostech. Dodavatel je povinen doložit Objednateli na výzvu doklad o uzavření pojištění a úhradě pojistného dle tohoto písm. o) do 5 pracovních dnů od obdržení výzvy;

16. po skončení poskytování Plnění odevzdat dokumentaci skutečného provedení projektu.

7. Realizační tým

   1. Dodavatel je povinen za účelem poskytování Plnění zajistit dostatečnou kapacitu svých pracovníků s odpovídající kvalifikací a zkušenostmi.

   2. Dodavatel je povinen za účelem poskytování Plnění dle této Smlouvy ustavit členy realizačního týmu pro realizaci této Smlouvy a určit jejich pravomoci (dále jen „Realizační tým“). Seznam členů Realizačního týmu je uveden v Příloze č. 5 Smlouvy. Dodavatel zajistí kontinuitu členů Realizačního týmu v průběhu trvání Smlouvy. Bude-li ze závažných důvodů vzniklých na straně Dodavatele nutné nahradit kteréhokoliv člena Realizačního týmu či rozšířit Realizační tým, bude po předchozím projednání s Objednatelem nahrazen/doplněn novým členem týmu s odpovídající nebo vyšší kvalifikací, a to do pěti (5) pracovních dní od oznámení důvodů pro nahrazení/doplnění Objednateli.

   3. Jednotlivé činnosti prováděné v rámci Plnění nespadající do činností členů Realizačního týmu uvedeného v Příloze č. 5 Smlouvy, mohou být prováděny i jinými osobami, než členy Realizačního týmu. Tím však není dotčena odpovědnost členů Realizačního týmu dle jejich pozic i za takto provedené činnosti.

   4. Dodavatel je povinen předložit Objednateli před zahájením Plnění seznam pracovníků, pro které bude požadovat přístup na pracoviště Objednatele a vzdálený přístup do informačního systému Objednatele, je-li to pro plnění Smlouvy nezbytné.

8. Práva duševního vlastnictví

1. K písemným výstupům Dodavatele poskytnutým v rámci poskytování Plnění a k tzv. unikátním počítačovým programům, tedy počítačovým programům vytvořeným výhradně pro potřeby Objednatele, které mají povahu autorského díla dle Autorského zákona (dále jen „autorské dílo“), je Objednateli Dodavatelem poskytována pro území České republiky nevýhradní licence bez omezení co do množství a způsobu užití, a to po celou dobu trvání majetkových práv autorských k takovému autorskému dílu. Licence dle tohoto odstavce se automaticky vztahuje i na všechny nové verze, aktualizované verze, i na úpravy a překlady autorského díla, dodané Xxxxxxxxxxx. Jako součást licence dle tohoto odstavce uděluje Dodavatel Objednateli i souhlas k provedení jakýchkoliv změn nebo modifikací výsledků uvedených autorských děl, a to i prostřednictvím třetích osob a výslovný souhlas k postoupení licence dle tohoto odstavce a k poskytnutí oprávnění užít tyto výsledky třetím osobám dle uvážení Objednatele, to vše bez nutnosti dalšího souhlasu ze strany Dodavatele.

2. Bude-li výsledkem Plnění nebo jiné činnosti Dodavatele prováděné dle této Smlouvy počítačový program, který nebyl vytvořen výhradně pro potřeby Objednatele, ale jedná se zejména o tzv. standardní počítačový program Dodavatele nebo třetí strany, který je autorským dílem, nabývá Objednatel licenci dle tohoto odstavce k takovému standardnímu počítačovému programu dnem poskytnutí autorského díla Objednateli k užívání. Součástí licence dle tohoto odstavce je rovněž neomezené právo Objednatele poskytnout třetím osobám podlicenci k užití autorského díla v obvyklém uživatelském rozsahu. Nebude-li možné po Dodavateli spravedlivě požadovat udělení podlicence k takovému standardnímu počítačovému programu, je Dodavatel povinen na to písemně Objednatele upozornit spolu s náležitým odůvodněním a zajistit poskytnutí podlicence nebo licence k takovému standardnímu počítačovému programu Objednatelem určeným osobám. Licence dle tohoto odstavce se automaticky vztahuje i na všechny nové verze, aktualizované verze, i na úpravy a překlady autorského díla, dodané Xxxxxxxxxxx.

1. Pro účely této Smlouvy se Licencí rozumí licence v rozsahu dle odst. 8.1 Smlouvy a licence v rozsahu dle odst. 8.2 Smlouvy.

2. Dodavatel je povinen postupovat tak, aby udělení Licence k autorskému dílu zabezpečil, a to bez újmy na právech třetích osob.

3. Licenci Dodavatel poskytne od předání SW CDA do produkčního prostředí na základě podpisu Akceptačního protokolu dle čl. 5.5 Smlouvy k dílčímu Plnění dle 2.1 písm. b) Smlouvy. Licence k SW CDA je touto Smlouvou poskytována za účelem zajištění archivace dokumentů pracovníky Objednatele při zajištění funkcionalit CDA popsaných v Příloze č. 1, 2 a 4 Smlouvy. Objednatel není povinen poskytnutou Licenci využít.

4. Pro vyloučení všech pochybností se stanoví výslovně, že odměna a náhrada nákladů za poskytnutí Licence dle tohoto čl. 8 Smlouvy je součástí ceny za Plnění dle čl. 2.2 písm. a) - c) Smlouvy uvedené v čl. 3.1 věta první Smlouvy.

1. Práva z vadného plnění, záruka za jakost, záruční servis

   1. Plnění má vady, jestliže nebylo poskytnuto tak, jak bylo sjednáno nebo poruší-li Dodavatel svou povinnost v souvislosti s poskytováním Plnění. Za vady se považují i vady v dokladech a dokumentech dodaných spolu s předmětem Plnění a právní vady.

   2. Dodavatel odpovídá za vady, které má Plnění v okamžiku jeho převzetí Objednatelem, i když se vada stane zjevnou až po této době. Dodavatel odpovídá rovněž za jakoukoliv vadu, jež vznikne po okamžiku převzetí Plnění, jestliže je způsobena porušením povinnosti Dodavatele, a za vadu HW CDA uplatněnou Objednatelem v záruční době dle čl. 9.5 Xxxxxxx (dále jen „Záruka za jakost“).

   3. Objednatel je oprávněn požadovat odstranění vad předmětu Plnění, a to odstraněním závady, bezplatným dodáním nového předmětu Plnění bez vad, případně doplněním chybějící části předmětu Plnění nebo je oprávněn žádat slevu z ceny předmětu Plnění nebo od Smlouvy odstoupit a žádat vzájemné vrácení plnění, přičemž právo volby má výhradně Objednatel.

   4. Dodavatel dále prohlašuje, že je oprávněn Plnění v rozsahu sjednaném v této Smlouvě Objednateli dodat, že uzavřením a plněním této Smlouvy neporušuje žádná práva duševního vlastnictví, ani jiná práva třetích osob. Dodavatel odpovídá za to, že Objednatel užíváním SW CDA v rozsahu poskytnuté Licence neporušuje žádná práva třetích osob. Dodavatel je povinen umožnit Objednateli nerušené užívání SW CDA v rozsahu udělené Licence a chránit jej, ať sám nebo prostřednictvím výrobce SW CDA, před nároky třetích osob vznesenými vůči Objednateli v souvislosti s užíváním SW CDA.

   5. Dodavatel dále poskytuje záruku, že HW CDA dodaný Objednateli v rámci plnění této Smlouvy má ke dni podpisu Předávacího protokolu funkční vlastnosti uvedené v Příloze č. 1 a 3 Smlouvy. Dodavatel poskytuje na HW CDA Záruku na jakost po dobu dvaceti čtyř (24) měsíců, není-li ve Smlouvě stanovena u části HW CDA doba delší, přičemž záruční doba začne plynout ode dne potvrzení Předávacího protokolu k HW CDA.

   6. V případě záručních vad dle čl. 9.5 Smlouvy je Objednatel povinen vady písemně oznámit Dodavateli prostřednictvím e-mailu odpovědnými osobami Objednatele na adresu odpovědných osob Dodavatele do patnácti (15) dnů ode dne jejich zjištění. Dodavatel prošetří oznámenou vadu z toho pohledu, zda se na ni vztahuje Záruka za jakost dle této Smlouvy. Objednatel mu přitom poskytne potřebnou součinnost, a to zejména pro odhalení příčiny vady. Požadavky na záruční servis jsou blíže specifikovány v odst. 11.2 Přílohy č. 1 Smlouvy.

10. Bezpečnost ICT systémů

    1. Objednatel v souladu s vyhláškou č. 82/2018 Sb., o 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), stanovuje touto Smlouvou pravidla řízení bezpečnosti informací.

    2. Dodavatel je povinen zúčastnit se bezpečnostního školení organizovaného Objednatelem a  dodržovat při výkonu své činnosti všechny bezpečnostní požadavky stanovené pro přístup pracovníků externích subjektů  do informačního systému Objednatele.

    3. Objednatel je oprávněn kdykoli prověřovat dodržování bezpečnostních požadavků stanovených Smlouvou. V průběhu auditu má Objednatel přístup k interním předpisům a systémům vztahujícím se k bezpečnosti ICT systémů podle této Smlouvy. Objednatel se zavazuje, že k informacím, které získá od Dodavatele za účelem ověření, zda je Dodavatelem řádně zajištěna bezpečnost ICT systémů, zachová mlčenlivost.

    4. Na případná negativní zjištění, vyplývající z auditu, týkající se dodržování bezpečnostních požadavků Dodavatelem, Objednatel Dodavatele bezodkladně upozorní. Dodavatel je povinen zjednat nápravu, a to ve lhůtě 30 kalendářních dnů od upozornění Objednatele. V případě, že Xxxxxxxxx neprovede nápravu ve lhůtě dle předchozí věty, je Objednatel oprávněn od Smlouvy odstoupit.

    5. Dodavatel je povinen hlásit vzniklé bezpečnostní incidenty, případně i podezření na ně Objednateli.

    6. Dodavatel je povinen nastavit transparentní proces řízení změn a Objednatele prokazatelně informovat způsobu řízení rizik na straně Dodavatele a o jeho významných změnách, zejména změnách fyzického umístění servisních / dohledových / vývojových zařízení, zavedení nových servisních / dohledových / vývojových nástrojů, zavedení nových technologií a aktualizaci stávajících provozních postupů a bezpečnostních politik. Dodavatel Objednatele informuje dále o zbytkových rizicích souvisejících s plněním Smlouvy.

11. Nemožnost plnění

    1. Jestliže vznikne na straně Dodavatele nemožnost plnění dle § 2006 a § 2007 Občanského zákoníku, Dodavatel písemně uvědomí bez zbytečného odkladu, nejpozději však do pěti (5) kalendářních dnů od jejího vzniku, o této skutečnosti a její příčině Objednatele. Pokud není jinak stanoveno písemně Objednatelem, bude Dodavatel pokračovat v realizaci svých povinností vyplývajících ze smluvního vztahu v rozsahu svých nejlepších možností a schopností a bude hledat alternativní prostředky pro realizaci té části plnění, kde není možné plnit. Pokud by podmínky nemožnosti plnění trvaly déle než devadesát (90) kalendářních dní, je Objednatel oprávněn od Smlouvy odstoupit.

    2. Ustanovení tohoto odstavce Xxxxxxx nezbavuje žádnou ze Smluvních stran její povinnosti k úhradě plateb v té době již splatných.

12. Odpovědní pracovníci

    1. Odpovědnými pracovníky Objednatele a Dodavatele ve věcech obchodních pro účely této Smlouvy jsou:

       1. Za Objednatele:

xxx

xxx

xxx

2. Za Dodavatele:

xxx

xxx

xxx

2. Odpovědnými pracovníky Objednatele a Dodavatele ve věcech technických pro účely této Smlouvy jsou:

   1. Za Objednatele:

xxx

xxx

xxx

2. Za Dodavatele:

xxx

xxx

xxx

3. Helpdesk Dodavatele: xxx, xxx

3. Pouze odpovědní pracovníci Objednatele a Dodavatele jsou oprávněni vznášet vůči druhé Smluvní straně požadavky související s plněním této Smlouvy. Smluvní strany se zavazují v průběhu plnění Smlouvy nezměnit odpovědné pracovníky bez závažných důvodů. V případě změny odpovědného pracovníka je Smluvní strana povinna neprodleně o této skutečnosti písemně informovat druhou Smluvní stranu.

1. Smluvní pokuty, odpovědnost za újmu

   1. V případě prodlení Objednatele s dodržením kterékoli lhůty stanovené v Harmonogramu je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 2 000,- Kč (slovy: dva tisíce korun českých) za každý započatý den prodlení.

   2. V případě prodlení Objednatele s dodržením kterékoli lhůty stanovené pro poskytování Podpory dle Přílohy č. 1 Smlouvy je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 1 000,- Kč (slovy: jeden tisíc korun českých) za každou započatou hodinu prodlení a každou vadu.

   3. V případě nedostupnosti Helpdesk Podpory je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 10 000,- Kč (slovy: deset tisíc korun českých) za každý jednotlivý případ.

   4. V případě prodlení s poskytováním záručního servisu ve lhůtách dle odst. 11.2 Přílohy č. 1 Smlouvy je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 5 000,- Kč (slovy: pět tisíc korun českých), a to za každou započatou hodinu prodlení a každou vadu.

   5. V případě ztráty či poškození, pozměnění či zneužití dat Objednatele ze strany Dodavatele je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 500 000,- Kč (slovy: pět set tisíc korun českých) za každý jednotlivý případ.

   6. V případě prokazatelného prodlení povinné Smluvní strany s poskytnutím součinnosti není druhá Smluvní strana v prodlení s plněním svých závazků závislých na poskytnutí součinnosti povinné Smluvní strany a veškeré lhůty se o prokazatelné prodlení povinné Smluvní strany prodlužují, nedohodnou-li se Smluvní strany jinak.

   7. V případě porušení kterékoli z povinností Dodavatele dle čl. 10 Smlouvy Bezpečnost ICT systémů Smlouvy je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 100 000,- Kč (slovy: sto tisíc korun českých) za každý případ porušení.

   8. V případě nesplnění povinnosti Dodavatele doložit sjednání pojištění a úhrady pojistného ve lhůtě dle čl. 6.4. písm. o) Smlouvy je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 10 000 Kč (slovy: deset tisíc korun českých) za každý případ porušení.

   9. Za každé jednotlivé porušení povinnosti, týkající se ochrany Obchodního tajemství a Důvěrných informací dle čl. 10.1 VOP je povinná Smluvní strana povinna uhradit porušením dotčené Smluvní straně smluvní pokutu ve výši 250 000,- Kč (slovy: dvě stě padesát tisíc korun českých).

   10. Za každé jednotlivé porušení čl. 8 těla Xxxxxxx Práva duševního vlastnictví ze strany Dodavatele, je Xxxxxxxxx povinen uhradit Objednateli smluvní pokutu ve výši 250 000,- Kč (slovy: dvě stě padesát tisíc korun českých).

   11. V případě, že se kterékoli prohlášení Dodavatele dle čl. 9.1 VOP ukáže, byť jen z části, jako nepravdivé, je Dodavatel povinen uhradit Objednateli smluvní pokutu ve výši 0,5 % z ceny za Plnění dle čl. 2.2 písm. a) - c) Smlouvy uvedené v čl. 3.1 věta první Smlouvy.

   12. Vyúčtování smluvní pokuty musí být druhé Smluvní straně zasláno doporučeně s dodejkou, smluvní pokuta je splatná v době 30 (slovy: třiceti) kalendářních dnů ode dne doručení vyúčtování.

   13. Uplatněním jakékoliv smluvní pokuty není nijak dotčeno právo Objednatele na náhradu skutečně způsobené majetkové i nemajetkové újmy v rozsahu přesahujícím zaplacenou smluvní pokutu.

   14. V případě, že dojde k porušení povinnosti Dodavatele, jež zakládá nárok Objednatele na odstoupení od Smlouvy, je Objednatel oprávněn bez ohledu na skutečnost, zda využije svého práva na odstoupení od Smlouvy, účtovat Dodavateli smluvní pokutu ve výši 100 000,- Kč (slovy: sto tisíc korun českých) za každý případ porušení takové povinnosti. Tím není dotčeno právo na vymáhání způsobené újmy.

   15. Pro vyloučení pochybností se stanoví, že čl. 11.1 VOP se neuplatní.

2. Doba trvání Smlouvy

   1. Tato Xxxxxxx nabývá platnosti dnem jejího podpisu Smluvními stranami a účinnosti dnem uveřejnění v registru smluv podle zákona o registru smluv. Plnění předmětu této Smlouvy v době od platnosti Xxxxxxx do její účinnosti se považuje za plnění podle této Smlouvy a práva a povinnosti z něj vzniklé se řídí touto Smlouvou.

   2. Tato Xxxxxxx se uzavírá na dobu určitou, a to na dobu 48 měsíců ode dne potvrzení Akceptačního protokolu k implementaci SW CDA a jeho integraci do systému Objednatele dle čl. 2.1 písm. b) Smlouvy Objednatelem.

   3. Účinnost této Smlouvy lze ukončit předčasně před sjednanou dobou trvání výhradně ze zákonných důvodů, písemnou dohodou Smluvních stran, výpovědí nebo odstoupením z důvodů uvedených v zákoně nebo v této Smlouvě.

   4. V případě zániku smluvního závazkového vztahu založeného Xxxxxxxx je Dodavatel povinen poskytnout Objednateli nebo Objednatelem určené třetí osobě nezbytnou součinnost
      za účelem zajištění řádného exportu dat Objednatele do jiného úložiště dat tak, aby Objednateli nevznikla újma, přičemž Dodavatel se zavazuje tuto součinnost poskytovat s odbornou péčí, zodpovědně, a to do doby zániku smluvního závazkového vztahu založeného Xxxxxxxx. Dodavatel je povinen v rámci součinnosti dle předchozí věty poskytnout Objednateli nebo jím určeným třetím osobám informace potřebné k převedení činností dle této Smlouvy novému Dodavateli Služeb či  novému Dodavateli služeb podobných Službám či s nimi jinak spojených. Úhrada nákladů spojených s poskytnutím součinnosti dle tohoto odstavce je zahrnuta v ceně dle čl. 3.1 věta první Smlouvy.

   5. Po ukončení Smlouvy zůstává zachována platnost a účinnost ustanovení Smlouvy, týkající se odpovědnosti za vady, záruky za jakost, licenčních ujednání, ochrany Důvěrných informací, ochrany Osobních údajů, smluvních pokut, náhrady újmy a jiných ze své povahy přetrvávajících nároků či závazků.

3. Závěrečná ustanovení

   1. Tato Smlouva a vztahy z ní vyplývající se řídí právním řádem České republiky, zejména příslušnými ustanoveními Občanského zákoníku a Zákona o zadávání veřejných zakázek.

   2. Smluvní strany si ve smyslu ust. § 1765 odst. 2 Občanského zákoníku ujednaly, že Dodavatel na sebe přebírá nebezpečí změny okolností.

   3. Smluvní strany se dohodly, že ustanovení § 1799 a 1800 Občanského zákoníku se nepoužijí.

   4. V případě rozporu mezi Smlouvou a přílohami Smlouvy mají přednost ustanovení Smlouvy, resp. jejích dodatků. V případě rozporu mezi ustanoveními jednotlivých příloh, mají přednost přílohy v pořadí, které odpovídá jejich očíslování dle čl. 15.12 Smlouvy.

   5. Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů, vzniklých na základě této Smlouvy nebo v souvislosti s touto Smlouvou, a k jejich vyřešení zejména prostřednictvím jednání odpovědných pracovníků nebo jiných pověřených subjektů.

   6. Změna kontaktních osob a spojení uvedených v čl. 12 Smlouvy a změna členů Realizačního týmu dle Přílohy č. 5 Smlouvy nevyžaduje změnu Xxxxxxx formou uzavření dodatku ke Smlouvě a je účinná v okamžiku doručení oznámení o této změně druhé Smluvní straně, aniž by bylo nutno vyhotovovat dodatek k této Smlouvě.

   7. Tato Smlouva je uzavírána v elektronické podobě, přičemž elektronické kopie souboru s podpisy obou Smluvních stran se považují za rovnocenné originály. Každá ze Smluvních stran obdrží 1 kopii elektronického souboru se Smlouvou s podpisem obou Smluvních stran s platností originálu.

8. Smluvní strany tímto prohlašují, že neexistuje žádné ústní ujednání, smlouva či řízení některé Smluvní strany, které by nepříznivě ovlivnilo výkon jakýchkoliv práv a povinností dle této Smlouvy. Zároveň potvrzují svým podpisem, že veškerá ujištění a dokumenty dle této Smlouvy jsou pravdivé, platné a právně vymahatelné.

9. Pro případ, že tato Xxxxxxx není uzavírána za přítomnosti obou Smluvních stran, platí, že Smlouva nebude uzavřena, pokud ji Dodavatel podepíše s jakoukoliv změnou či odchylkou, byť nepodstatnou, nebo dodatkem, ledaže Objednatel takovou změnu či odchylku nebo dodatek následně schválí.

10. Smluvní strany potvrzují, že se s textem VOP seznámily před podpisem této Smlouvy a je jim znám jejich význam v souladu a ve spojitosti se Smlouvou. Dále Smluvní strany potvrzují, že veškerým ustanovením Smlouvy a VOP plně a bez jakýchkoli obtíží porozuměly a nepovažují je za nevýhodná. VOP představují závaznou a nedílnou součást Smlouvy.

11. Nedílnou součástí této Smlouvy jsou následující Přílohy:

Příloha č. 1 Specifikace požadovaného Plnění

Příloha č. 2 Požadavky na SW CDA

Příloha č. 3 Technická specifikace HW CDA

Xxxxxxx x. 0 Popis řešení CDA Dodavatele

Příloha č. 5 Realizační tým

Příloha č. 6 Všeobecné obchodní podmínky Objednatele

NA DŮKAZ TOHO, že Smluvní strany s obsahem Xxxxxxx souhlasí, rozumí ji a zavazují se k jejímu plnění, připojují své podpisy a prohlašují, že tato Xxxxxxx byla uzavřena podle jejich svobodné a vážné vůle prosté tísně, zejména tísně finanční.

V Praze	V Praze
___________________________	___________________________
Xxx. Xxxxxxxx Xxxxxxx ředitel úseku ICT a eGovernment Česká pošta, s.p.	Xxx. Xxxxxx Xxxxxxx předseda představenstva GC System a.s.

Podepsáno elektronicky Podepsáno elektronicky

Za formální správnost a dodržení všech interních postupů a pravidel ČP: xxx, xxx ICT bezpečnost

Příloha č. 1 Smlouvy: Specifikace požadovaného Plnění

1. Cíl Plnění

Cílem Plnění je řešení, které na rozdíl od stávajícího, nebude jednoznačně závislé na jedné technologické platformě, bude dostatečně otevřené pro jiné technologie a jiná řešení. Řešení musí být dostatečně customizovatelné a provozovatelné bez závislosti na dodavateli. Řešení bude umožňovat rozšíření směrem k novým technologiím, jako jsou např. CLOUD, nebo Data on Demand a nebude limitováno kapacitně, časově a funkčně oproti potřebám Objednatele.

Cílem je vybudování Centrálního digitálního archivu zadavatele (dále jen „CDA“), který bude provozován plně na infrastruktuře Objednatele. Bude přístupný uživatelům Objednatele (interním i externím). Prostřednictvím prohlížeče bude CDA na straně uživatelského rozhraní plně integrováno do používaných a standardních rozhraní Objednatele. CDA bude plně pod správou provozních útvarů DICTG Objednatele. CDA tak bude universálním standardizovaným úložištěm pro účely služby archivace celého podniku Objednatele. Dále pak musí vyhovovat ustanovením platné legislativy, standardizovaným interním procesům a zvyklostem Objednatele. Rozhraní CDA bude umožňovat integraci a komunikaci s okolními aplikacemi bez zásadního omezení.

2. Předmět plnění

Předmětem Plnění je implementace a provoz CDA, které se skládá z následujících částí:

• Softwarové řešení CDA zahrnující poskytnutí Licence, implementaci, integraci, testování, zaškolení, dodání dokumentace, projektové vedení;

• Hardwarové komponenty CDA – kompletní hardware potřebný pro dlouhodobé garantované uložení dokumentů a dat, včetně provozu řešení CDA;

• Služby - migrace obsahu ze stávajícího systému EMC CENTERA na navržené řešení;

• Služby technické podpory hardwarových a softwarových komponent – maintenance CDA (metodická podpora archivace, aktualizace dokumentace a uživatelských příruček k CDA, seznámení administrátorů a uživatelů s prostředím CDA, zajištění legislativního souladu po celou dobu účinnosti Smlouvy, aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA, technická podpora hardwarových a softwarových komponent).

3. Všeobecné informace

1. Popis současného prostředí

V obou lokalitách, které mají být zahrnuty do řešení CDA, může Dodavatel využít následující prostředky, které zajistí Objednatel:

1. Hardware

• síťová konektivita, datové a telefonní sítě zahrnující:

• propojení hlavní a záložní lokality.

• připojení do Internetu (připojení mimo infrastrukturu Objednatele je umožněno pouze v odůvodněných případech);

• napájení;

• chlazení;

• switch pro napojení na infrastrukturu Objednatele;

• firewall nebo případně balancer (využití bude řešeno v rámci cílové architektury a fáze analýzy řešení, využití bude muset Dodavatel jednoznačně podložit argumenty);

• rack pro umístění potřebné technologie.

1. Software, služby

• zdroj uživatelských účtů MS AD;

• služby TSA (autority časových razítek);

• služby elektronických pečetí;

• služba monitoringu (pro zasílání logů a stavu kompoment);

• emailový (SMTP) server.

Objednatel u těchto součástí řešení přebírá odpovědnost za jejich připravenost, kvalitu služby a jejich provoz. Objednatel po akceptaci díla bude provozovatelem celého řešení.

3. Všeobecné požadavky

Navrhované řešení musí být realizováno v souladu s platnými právními normami:

• nařízením eIDAS (910/2014/ES) o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu, včetně navazujících prováděcích předpisů (zákonem č. 297/2016 Sb., zákonem č. 298/2016 Sb., příp. dalšími);

• zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů;

• zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů,
  ve znění pozdějších předpisů;

• zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých zákonů, ve znění pozdějších předpisů;

• zákon č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů;

• zákon č. 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 „zákon o kybernetické bezpečnosti“);

• Objednatel požaduje řešení sestavené z produktů a technologií, které jsou v době podání nabídky běžně dostupné na trhu a pro které na trhu existuje technická podpora, kterou může poskytnout běžným dostupným způsobem více dodavatelů.

Cílem požadovaného řešení je zajistit dlouhodobé důvěryhodné uložení elektronických dokumentů a dat na dobu alespoň 25 let.

V CDA budou elektronické dokumenty a data uloženy po dobu stanovenou příslušnými legislativními předpisy nebo interními normativními akty (dále jen „INA“). Po uplynutí této doby musí být umožněno realizovat rozhodnutí, zda daný dokument nebo data, budou nadále archiválií nebo bude provedeno vyřazení z archivu.

Pro vyloučení pochybností Objednatel explicitně požaduje splnění následujících všeobecných požadavků, které mohou být upřesněny v dalším popisu řešení níže:

• Objednatel trvá na tom, aby součástí nabídkové ceny byly všechny služby, Licence i HW komponenty tvořící řešení;

• Objednatel nepřipouští využití stávajících HW a SW komponent s výjimkou těch, které jsou vyjmenovány v části Popis současného prostředí;

• Objednatel trvá na tom, aby všechny součásti řešení byly v době dodání nové (ne starší než rok) a nepoužité;

• Objednatel požaduje, aby řešení odpovídalo referenčnímu modelu OAIS (Open Archival Information System);

• Objednatel požaduje, aby řešení umožňovalo využití CLOUD technologií (např. MS XXXXX);

• Řešení musí být navrženo tak, aby umožnilo Objednateli využívat jen takovou kapacit úložišť, kterou nezbytně potřebuje v daný okamžik (Capacity On-demand). Toto ustanovení se týká kapacity vyšší než uvedená minimální kapacita;

• Objednatel požaduje vybudování záložního pracoviště, které bude v maximální možné míře sdílet prostředky Dodavatele, nicméně musí být schopné a zcela autonomní v případě výpadku, jakékoliv komponenty (nebo celé lokality) z primární lokality a zajišťovat službu ve stejné kvalitě jako je tomu v primární lokalitě;

• Řešení musí být navrženo takovým způsobem, aby dokumenty a data neopustila infrastrukturu a zázemí Objednatele s výjimkou certifikátů pro potřeby ověření jejich platnosti. Objednatel požaduje použití certifikátů vydaných kvalifikovanými poskytovateli certifikačních služeb dle Ministerstva vnitra ČR, zejména CA PostSignum. Shoda je požadována minimálně v rozsahu požadavků na prostředky a data pro elektronický podpis a na dokumenty v digitální podobě definovaných v zákoně č. 499/2004 Sb., v zákoně č. 297/2016 Sb. a v zákoně č. 298/2016 Sb. Seznam certifikačních autorit bude vytvářen v průběhu provozu, avšak řešení musí být připraveno i na rozšíření certifikátů. Toto rozšíření však nesmí být řešeno automatickým způsobem, tato funkce musí být závislá na manuální akceptaci administrátorem.

3. Softwarové řešení CDA

   1. Požadavky na CDA

Návrh řešení CDA musí vycházet z následujících funkčních a specifických požadavků. Funkčními požadavky se rozumí konkrétní funkcionality poskytované komponentou tak, aby systém naplnil očekávání uživatele. Funkcionalitami rozumíme množinu vstupů, transformací a výstupů celého řešení. Pod specifickými požadavky se rozumí požadavky na komponentu, které ji nepopisují z pohledu jejího chování, ale z pohledu jejího návrhu, výkonnostních a kvalitativních parametrů.

2. Základní funkční požadavky

• Systém CDA zabezpečí archivaci dokumentů a dat dle příslušných legislativních předpisů a INA;

• Řešení musí umožňovat uložení dat nejméně na dobu 25 let;

• Systém CDA umožní příjem vstupních archivních balíčků, jejich prověření v rámci karantény, dlouhodobé uložení a opětovné poskytnutí uživatelům. V souladu se standardem Národního digitálního archivu musí být tyto archivní balíčky implementovány dle standardu METS;

• Systém CDA zajistí podporu procesů spojených s vyřazováním dokumentů z archivu;

• Systém CDA zajistí kontrolu bezpečnosti vstupních dokumentů a dat a to formou karanténní části, kde budou dokumenty a data testovány na škodlivé kódy prostřednictvím antivirové ochrany (malware, včetně zero-day hrozby.).

1. Další funkční požadavky

• Ke každému dokumentu bude veden transakční log zachycující veškeré operace
  s dokumentem;

• Ke každému dokumentu bude veden Elektronický evidenční list, v rámci kterého budou vedeny záznamy o poskytnutí dokumentu, včetně žádostí o přístupy;

• CDA bude schopen vytvářet proces vyřazení z archivu pro jednotlivé archiválie nebo postoupení vyššímu stupni archivu;

• Systém CDA umožní také manuální příjem dokumentů;

• Evidence a editace metadat u jednotlivých dokumentů;

• Vyhledávání dokumentů podle metadat;

• Zařazování dokumentů do spisů, kde každý spis může obsahovat 1 až N dokumentů;

• Evidence papírových dokumentů mimo CDA. V CDA jsou k papírovému dokumentu uloženy metadatové položky, které usnadňují jeho dohledání ve fyzickém archivu;

• Systém CDA musí umožnit integraci aplikace spisové služby „EZOP ČP“ jako jednoho z možných zdrojových systémů CDA.

1. Základní specifické požadavky

• Navrhované řešení musí být v souladu s nařízením eIDAS (910/2014/ES) o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu;

• Návrh musí vycházet ze standardu OAIS – ISO 14 721 (Open Archival Information System);

• Systém CDA musí zajistit nemodifikovatelné, trvalé a důvěryhodné uložení archivovaných dokumentů;

• Důvěryhodnost dokumentů bude zajištěna pomocí technologií kvalifikované elektronické pečetě a elektronického časového razítka;

• Umožnuje souborový přístup alespoň na úrovni NFS a nebo jako variantní CIFS, SMB, WebDAV, SOAP nebo REST API, API S3 nebo Swift.

1. Další specifické požadavky

• Systém CDA je určen pro dlouhodobé uchovávání dokumentů a dat v souladu s právními předpisy;

• Data do systému CDA budou primárně přenášena pomocí standardního automatizovaného elektronického rozhraní, které CDA poskytne;

• Uživatelé systému CDA jsou vedeni v IDM v rámci Objednatele;

• Zdrojové systémy budou se systémem CDA integrovány volně, tzv. "loose coupling";

• Systém CDA musí podporovat tyto služby: systémové (tj. administrace APV, brána – firewall pro vstup a výstup do CDA, databázové služby, elektronická pošta, systémový a bezpečnostní audit), uživatelské (tj. automatizace kancelářské práce, příjem, zpracování a zpřístupnění dat), dále v rámci logické vrstvy archivace dokumentů, služby PKI (tj. elektronické podepisování dokumentů, časová razítka a ověřování elektronických podpisů).

3. Funkční specifikace CDA

Řešení vycházející z funkčních a nefunkčních požadavků a předpokladů uvedených v předchozí kapitole je založeno na rozdělení systému CDA na tři logické komponenty. První komponentou je Brána CDA (dále jen „Brána“), která představuje viditelnou část archivu a poskytuje jak automatizované rozhraní pro integraci systémů, tak i grafické uživatelské rozhraní pro práci uživatelů. Druhou komponentou je samotný archivní systém (dále jen „Archiv“), který se skládá z logické (softwarové) části starající se o procesy v archivu a fyzické (hardwarové) části starající se o bezpečné uložení dat. Tyto dvě komponenty (Brána, Archiv) jsou odděleny fyzickým firewallem a komunikují spolu po fyzicky oddělených komunikačních kanálech. Třetí komponentou je tzv. badatelna, která zajišťuje nahlížení na archiválie a procesy spojené s poskytnutím kopie dokumentu uživateli (dále jen „Badatelna“). Funkční schéma takto navrženého systému zobrazuje:

Diagram 1

Brána je s Archivem integrována pomocí definovaného rozhraní. Mimo toto rozhraní neprobíhá mezi těmito komponentami žádná jiná komunikace. Jednotlivé komponenty a jejich integrace jsou podrobněji popsány dále v dokumentu.

1. Brána

Brána představuje rozhraní archivu, které jasně odděluje prostor zdrojových systémů, uživatelů
a samotného Archivu. Brána poskytuje komunikační rozhraní pro vstup dokumentů, funkce pro práci archivářů, funkce Badatelny a přehledové a statistické funkce poskytující informace o stavu Archivu. Brána je tvořena jednou nebo více vzájemně integrovanými aplikacemi, které implementují požadované funkce.

Řešení zajišťuje fyzické i logické oddělení brány a vyčlenění určitých funkcí mimo samotný archiv:

• Oddělení Brány a Archivu a Badatelny je pomocí firewallu, který jasně definuje možné komunikační prostředky;

• Zajištění bezpečnosti, kdy případné útoky nebo jiné pokusy o napadení či průnik budou vedeny na Bránu, nikoliv na samotný Archiv;

• Volné spojení Archivu a zdrojových systémů. Zdrojové systémy nejsou integrovány přímo
  s archivní částí. V případě změn v archivní části tak nedochází k ovlivnění integrace zdrojových systémů a naopak.

• Prostředky pro práci uživatelů umožňují provádění úprav v návaznosti na rozvoji klientských prostředků (pracovní stanice, mobilní zařízení, softwarová výbava, standardy) bez nutnosti zásahu do archivní části.

2. Vstup dokumentů

Vstupní Brána poskytuje jak prostředky pro automatický příjem dokumentů a dat od zdrojových systémů, tak i funkce pro ruční vkládání dokumentů do Archivu. Dokumenty i data jsou přijímány do karanténní části Archivu, kde jsou podrobeny zkoumání z pohledu vhodného formátu, úplnosti metadat, platnosti prvků elektronického zabezpečení a přítomnosti škodlivého kódu.

Automatický příjem dokumentů

Automatický příjem dokumentů probíhá pomocí jasně definovaného rozhraní. Brána musí být schopna použití následující možnosti integrace:

• Skener souborového systému – Brána poskytne pro každý systém, který není schopen integrace pomocí pokročilejších technologií, složku, na vyhrazeném souborovém systému. Do této složky zapisuje zdrojový systém data spolu s popisnými metadaty. Všechny evidované složky Brána (nebo její externí součást) pravidelně monitoruje a nově přidané soubory předává archivu ke zpracování;

• Webové služby typu SOAP – Standardní prostředek pro systémovou integraci. Data k archivaci jsou zasílána jako příloha (např. pomocí standardu MTOM). Metadata jsou zaslána uvnitř SOAP zprávy jako parametry volání;

• Webové služby typu REST – Standardní prostředek pro systémovou integraci. Data k archivaci jsou zasílána v těle POST požadavku.

Každé zpřístupněné rozhraní musí být zabezpečeno takovým způsobem, aby nemohlo být využito jiným než oprávněným subjektem. Vždy musí být jasné, jaký zdrojový systém požadavek do Archivu zaslal.

Ruční vstup dokumentů

Systém musí podporovat ruční vstup dokumentů a dat přes uživatelské rozhraní Brány, v rámci které probíhá běžná práce pověřených pracovníků Objednatele. Proces následného zpracování dokumentu a dat se neliší od dokumentu vstupujícího skrz automatické rozhraní, a to včetně kontroly v rámci karanténní části.

Karanténa dokumentů

V rámci karantény jsou u dokumentu provedeny následující kontroly:

• Vhodnost datového formátu – Do Archivu jsou přijímány pouze soubory definovaných datových typů. Z pohledu dlouhodobého uchování jsou některé formáty vhodnější než jiné;

• Úplnost popisných metadat – Vstupující dokument musí být popsán množinou definovaných metadat. Tato metadata se dle modelu OAIS archivují spolu s dokumentem;

• Platnost prvků elektronického zabezpečení dokumentů – U souborů vybraných datových typů, které podporují elektronické bezpečnostní prvky (elektronický podpis/pečeť, elektronické časové razítko), jsou tyto prvky validovány. Typicky se jedná o formáty PDF;

• Integrita dokumentů – Stejně jako platnost elektronického podpisu/značky je kontrolována
  i integrita samotného dokumentu, zda od podpisu dokumentu nedošlo k jeho modifikaci;

• Přítomnost škodlivého kódu – Dokument je testován na přítomnost škodlivého kódu, který by mohl ohrozit bezpečnost Archivu, ale především ohrozit koncové příjemce dokumentu.

Dokument, který nevyhoví v rámci kontrol definovaným kritériím je zařazen do seznamu problematických dokumentů. Další postup je na rozhodnutí archiváře.

Kromě klasické antivirové ochrany musí karanténa zajišťovat i ochranu např. před následujícími hrozbami:

• Malware zneužívající zero-day zranitelností – tedy malware, pro který ještě neexistují antivirové signatury;

• Polymorfní malware výrazně měnící svoje chování a vnitřní strukturu;

• Malware, který se aktivuje na základě uživatelské interakce (kliknutí myší, zobrazení
  a interakce s dialogovým oknem, scrollování apod.);

• Malware, který se aktivuje až po určitém předem definovaném datu;

• Malware, který je distribuován ve formě downloaderu, který sám o sobě neobsahuje škodlivý kód a jehož jedinou úlohou je stáhnout vlastní tělo malware.

3. Archivní činnosti

Tento funkční modul pokrývá svými funkcionalitami veškerou běžnou práci archivářů Objednatele v CDA, v rámci které mohou dokumenty vyhledávat, prohlížet, upravovat metadata, poskytovat dokument dalším subjektům nebo dokument z Archivu vyřadit v rámci procesu vyřazení z Archivu.

Vyhledání elektronických i papírových dokumentů

Modul Brány musí obsahovat index souborů v Archivu, pomocí kterého lze veškerý obsah v Archivu dohledat. Vyhledávat musí být možné podle všech definovaných metadatových položek. U položek, které mají číselníkový charakter, musí být ve formuláři nabídka položek číselníku. Podoba výsledků vyhledávání musí být uživatelsky konfigurovatelná, aby si mohl uživatel zobrazit přehled takových metadatových položek, které jsou smysluplné pro jeho práci. Seznam musí být možné exportovat ze systému ve vhodném datovém formátu (minimálně CSV, Excel 2007 a vyšší).

Očekávaná charakteristika indexace:

• Indexování všech data a objektů do specializované indexovací databázi;

• Indexování všech metadat do specializované indexovací databázi;

• Rozprostření index databáze mezi více nódů.

K libovolné položce v seznamu výsledků vyhledávání je možné si zobrazit detailní náhled se všemi evidovanými informacemi k dokumentu. V případě elektronického dokumentu odpovídajícího formátu je zobrazen také náhled na tento dokument (viz funkci Náhled na dokumenty). V případě potřeby je možné stáhnout si kopii elektronického dokumentu, nebo kopii dokumentu odeslat do Badatelny (viz funkci Zpřístupnění elektronického dokumentu). V případě papírového dokumentu je zobrazeno jeho umístění v papírovém archivu.

Výsledky vyhledávání jsou omezeny oprávněními uživatele. Pokud nemá uživatel na dokument právo, nezobrazuje se ve výsledcích a neexistuje žádný jiný způsob, kterým by se uživatel k tomuto dokumentu mohl dostat.

Editace/doplnění metadat dokumentu

Každá položka evidovaná v Archivu (elektronický i papírový dokument, případně jiný záznam) je popsána sadou definovaných archivních metadat (definováno v rámci konfigurace systému). Dokument do Archivu vstupuje již s nejnutnější sadou metadat, které ho jednoznačně identifikují (např. předmět dokumentu a číslo jednací). Pokud dokument při vstupu do Archivu neobsahuje veškeré povinné metadatové položky, může být na základě rozhodnutí oprávněného uživatele nebo na základě konfigurace systému odmítnut. V opačném případě má oprávněný uživatel možnost povinná metadata doplnit. Kromě povinných metadat může být dokument popsán další řadou nepovinných metadatových položek, které mohou být doplňovány časem. Editace metadat probíhá skrz připravené formuláře systému po vyhledání konkrétního dokumentu (viz funkci Vyhledání elektronických i papírových dokumentů).

Metadata, se kterými dokument do archivu vstupuje, jsou archivována spolu s dokumentem. Další metadata jsou ukládána v rámci provozní databáze Archivu a slouží pro usnadnění práce archivářů. Kromě archivních metadat, mohou být k dokumentu připojeny i technická metadata, která jsou v režii systému a uživatel je běžně needituje (může si je však zobrazit).

Náhled na dokumenty

Systém umožňuje uživatelům prohlížet obsah elektronických dokumentů uložených v archivu bez nutnosti stahovat dokument na pracovní stanici uživatele a použití dalšího softwaru. Tato funkce je dostupná pro běžně používané formáty elektronických dokumentů (minimálně formáty PDF, PDF-A, DOC, DOCX, XLS, XLSX, RTF, JPEG, PNG, GIF, PS, EPS, SVG, TIFF). Funkce je dostupná v rámci detailu dokumentu po jeho vyhledání (viz funkci Vyhledání elektronických i papírových dokumentů).

Zpřístupnění elektronického dokumentu / důkazního materiálu

Po přijetí žádosti o zpřístupnění dokumentu z Archivu, musí mít uživatel možnost vyhledat tento dokument v Archivu a pomocí připraveného formuláře k němu zaevidovat žádost o zpřístupnění.
K elektronické žádosti musí být možnost připojit samotný dokument žádosti, který je pak archivován v systému a propojen se zaevidovanou žádostí. Následuje spuštění procesu, v rámci kterého systém čeká na vložení povolení ke zpřístupnění. Každý oprávněný uživatel má k dispozici seznam takto zpracovávaných dokumentů. Po zaevidování povolení ke zpřístupnění může oprávněný uživatel dát pokyn systému ke zpřístupnění „kopie“ dokumentu v rámci Badatelny, nebo si stáhnout jeho „kopii“ a zaslat ji žádajícímu subjektu prostřednictvím jiného kanálu.

Součástí požadavku na poskytnutí archivního dokumentu může být i požadavek na prokázání jeho důvěryhodnosti a poskytnutí k tomu potřebných materiálů. Pro tyto potřeby musí být systém schopen vygenerovat ke konkrétnímu archivovanému dokumentu důkazní materiál, obsahující všechny nezbytné informace pro prokázání důvěryhodnosti dokumentu.

Evidence papírových dokumentů

I když je primárním účelem systému CDA archivace elektronických dokumentů a dat, musí systém umožnit evidenci také některých papírových dokumentů, které jsou uloženy v archivu. Papírový dokument je v systému evidován jako entita, která je popsána sadou metadat. Důležitým údajem je umístění dokumentu ve fyzickém papírovém archivu.

Do této evidence bude migrován obsah ze stávajícího evidenčního spisového systému EZOP, případně dalších systémů, které jsou u Objednatele provozovány.

Vyřazení elektronických dokumentů

Na základě jednoznačných znaků je archivář schopen vytvořit seznam dokumentů, které jsou navrženy k vyřazení z Archivu. Oprávněný uživatel tento seznam postupně prochází a po prozkoumání každého jednotlivého dokumentu rozhodne, zda bude dokument z Archivu odstraněn/znepřístupněn, nebo bude předán nadřazenému archivu. Rozhodnutí je evidováno v rámci logů Archivu.

Administrace a konfigurace archivu

Systém musí být konfigurovatelný z pohledu metadatových položek. V rámci systému je možné vytvářet třídy (typy) dokumentů a jim přidělovat různé množiny povinných a nepovinných metadat. Samotné metadatové položky jsou předmětem konfigurace. Definice metadatové položky obsahuje nejméně: datový typ (znak, řetězec, číslo, logická hodnota), název, popis, forma pořízení. Forma pořízení může být textové pole, výběr z číselníku, zaškrtávací tlačítko, případně další možnosti.

4. Badatelna

Badatelna musí být implementována jako fyzicky oddělená komponenta od zbytku systému, ale musí být integrována s ostatními komponentami, a to zabezpečeným způsobem. Badatelna slouží pro dočasné krátkodobé zpřístupnění uživatelské kopie archivovaného dokumentu oprávněným osobám v režimu pouze pro čtení. Do Badatelny se kopie souboru archivovaného dokumentu dostává systémovým procesem na pokyn oprávněného uživatele, který vyřizuje příslušnou žádost o zpřístupnění. Badatelna detailně eviduje práci badatele se zpřístupněným dokumentem a tyto informace zpátky propaguje do systému CDA, kde jsou uchovávány v rámci tzv. badatelského listu (dále jen „Badatelský list“).

V rámci Badatelny jsou evidování jednotliví badatelé a jejich přístupy do systému. Identita badatele je do systému zadána obsluhou Badatelny při první návštěvě.

Funkce a používání Badatelny musí splňovat minimálně následující požadavky:

5. Obecné požadavky

• Badatelna musí umožnit pracovat s dokumenty minimálně ve formátech PDF, PDF-A, DOC, DOCX, XLS, XLSX, RTF, JPEG, PNG, GIF, PS, EPS, SVG0, TIFF. U obrazových formátů je požadováno zobrazování přímo v aplikaci v dynamické komponentě a automatické opatřování vodoznakem (viz. definice níže);

• Obsah zdrojových obrazových dat (master copy) je nutné zpracovat tzv. tilováním, tzn. optimalizací objemu pro zobrazování na koncových stanicích (user copy);

• V souladu s požadavky na bezpečnost musí být Badatelna zcela autonomní, fyzicky
  i logicky oddělená od zbývajících částí řešení;

• Data zpřístupněných dokumentů v Badatelně (tzv. user copy) musí být
  z bezpečnostního hlediska logicky i fyzicky oddělené od originálních dat dokumentů (tzv. master copy);

• Aktivita badatelů i administrátorů nad dokumenty musí být detailně logována tak, aby bylo zpětně zřejmé, kdo a jakým způsobem s dokumenty pracoval (viz. Generování Badatelského listu níže).

Administrátorovi Badatelny musí být umožněno:

• Vyhledávat dokumenty a připravovat dokumenty nebo dávky dokumentů k zpřístupnění;

• Zpřístupnit dokumenty nebo dávku dokumentů konkrétnímu uživateli/badateli a to i na časově omezenou dobu;

• Předat badateli unikátní identifikátor pro přihlášení;

• Ukončit zpřístupnění dokumentů badateli dle unikátního identifikátoru;

• Zobrazit detailní log aktivit, které badatel prováděl;

• Generování badatelského listu s přehledem detailních aktivit, které badatel prováděl;

• Zobrazit si přehled probíhajících badání (připojených badatelů) s detailní informací o jejich aktuální aktivitě.

Uživateli/Badateli musí být umožněno:

• Přihlásit se do badatelny na základě údajů, které obdrží od administrátora a následně se odhlásit;

• Zobrazit zpřístupněné dokumenty formou přehledné tabulky s inline vyhledáváním a řazením v jednotlivých datových sloupcích;

• Zobrazit detail dokumentu obsahující minimálně obsah a metadata. Obrazový obsah musí být zobrazen dynamickým způsobem a objemově optimalizovaným způsobem (tzv. tilováním), pomocí komponenty, která umožní uživateli dynamické zvětšování a posouvání obrazového obsahu;

• Zobrazit a stáhnout obsah dokumentu v nezkreslené podobě bez ztráty detailu (když je povoleno v rámci daného zpřístupnění);

• Vyhledávat v zpřístupněných dokumentech fulltextovým způsobem a to jak v obsahu (v případě přítomnosti OCR vrstev v PDF souborech, i tam), tak v metadatech.

6. Statistika

Tento funkční modul poskytuje statisticko-provozní informace o Archivu, jedná se především o:

• Celkový objem dokumentů v Archivu – počet dokumentů, celková velikost;

• Zbývající dostupný prostor v Archivu – velikost a odhadovaný počet dokumentů (na základě průměrné velikosti dokumentů v archivu). Odhad doby, po kterou bude stačit stávající kapacita Archivu;

• Přírůstek dokumentů za daný interval (den, týden, měsíc, rok). Systémů může zobrazovat např. graf přijatých dokumentů v definované agregaci;

• Počty problematických dokumentů;

• Počty dokumentů navržených k vyřazení;

• Počty dokumentů, u kterých se vyřizuje žádost o zpřístupnění.

Dále systém pro každého uživatele zobrazuje následující seznamy:

• Seznam archivovaných dokumentů v zadaném období (např. včera, tento týden, minulý týden, tento měsíc, ...);

• Seznam problematických dokumentů, které nebylo možné automaticky archivovat a vyžadují zásah oprávněného uživatele;

• Seznam dokumentů, u kterých se vyřizuje žádost o zpřístupnění;

• Seznam dokumentů navržených ke zneplatnění.

3. Logická vrstva CDA

Logická (aplikační/softwarová) vrstva CDA je tvořena komponentou důvěryhodného elektronického Archivu, která se stará o zachování důvěryhodnosti uložených elektronických dokumentů.

1. Digitální kontinuita a důvěryhodnost dokumentu

Dlouhodobé uložení dokumentů podepsaných elektronickým podpisem založeným na kvalifikovaném certifikátu implikuje potřebu řešit problém omezené platnosti tohoto certifikátu. S nezanedbatelnou pravděpodobností se může stát, že v době, kdy je potřeba prokázat důvěryhodnost dokumentu, může být certifikát, na kterém je podpis založen již neplatný (ať už z důvodu vypršené stanované platnosti nebo účelné revokace z důvodu kompromitace samotného certifikátu). Při současném využití elektronického časového razítka je však možné platnost certifikátu podpisu prokazovat k času orazítkování, kdy byl certifikát ještě platný.

Kvalifikovaný certifikát, na kterém je založeno časové razítko má však také omezenou platnost. Toto omezení bude řešeno procesem přerazítkování, kdy je objekt nebo soubor fixovaný časovým razítkem, opatřen novým časovým razítkem vždy před vypršením platnosti certifikátu posledního platného časového razítka.

Ani tím však není zcela zaručena prokazatelnost důvěryhodnosti dokumentu. Informace použité pro ověření dokumentu v čase označení časovým razítkem mají také omezenou platnost. Jedná se především o CRL seznamy certifikačních autorit, odpovědi OCSP služeb, použité certifikáty a jejich hierarchická struktura. V rámci řešení je požadováno uložení všech informací použitých pro ověření a zajištění jejich důvěryhodnosti a dlouhodobé platnosti spolu s archivovaným dokumentem.

2. Validace dokumentu

Dokument podepsaný osobním elektronickým podpisem založeným na kvalifikovaném certifikátu, nebo označen elektronickou pečetí založenou na kvalifikovaném certifikátu je tímto bezpečnostním prvkem zafixován. Systém musí kontrolovat platnost certifikátu, na kterém je podpis založen. Validace certifikátu spočívá v kontrole, zda jej vydala důvěryhodná autorita a zda je certifikát platný a nebyl uveden na seznamu zneplatněných certifikátů certifikační autority. Systém musí zajistit validaci kvalifikovaných certifikátů akreditovaných certifikačních autorit vedených v Trusted Service List (TSL) příslušných států Evropské unie.

3. Balíčkování

Systém podporuje tvorbu archivních balíčků zajišťujících dlouhodobou platnost celé sady dokumentů, což vede k optimalizaci procesu razítkování a přerazítkování dokumentů tak, aby byly minimalizovány náklady za razítka od časové autority. Systém balíčkování musí splňovat minimálně následující vlastnosti:

• Možnost balíčkování dokumentů nezávisle na jejich typu, významu, různých přístupových právech a bez jejich vzájemného vztahu.

• Mazání jednotlivých dokumentů z balíčku, bez narušení možnosti prokázat důvěryhodnost ostatních dokumentů z balíčku.

• Poskytování důkazních informací k jednotlivým dokumentům bez nutnosti znalosti obsahu ostatních dokumentů ve stejném archivním balíčku.

4. Evidence

Logická vrstva archivu si vede vlastní index obsahu uloženého ve fyzické vrstvě nezávislý na Bráně a úložišti.

3. Fyzická vrstva CDA

Součástí řešení musí být takový typ úložiště, který bude ve shodě se zákonem č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů.

3. Nasazení a integrace CDA do prostředí

CDA bude umístěno ve dvou na sobě nezávislých a geograficky oddělených lokalitách následovně:

• DC ČP Praha Malešice;

• DC ČP Praha Olšanská.

S ohledem na odhadovanou zátěž Archivu a vzdálenost obou lokalit je nutný režim Disaster Recovery, kdy je běžný provoz směrován pouze na primární lokalitu. Dokumenty v primární lokalitě jsou automaticky replikovány do sekundární lokality.

Kromě provozního prostředí je požadováno také prostředí testovací. Testovací prostředí má svoje aplikační a databázové servery, může však využívat úložný hardware produkčního prostředí, kde má vytvořený striktně oddělený prostor. Testovací prostředí slouží pro ověřování veškerých změn, před jejich aplikací na provozní prostředí.

1. Integrace

Modul Archivu poskytuje služby, které modulu brány umožňují ukládat nové dokumenty do Archivu, nebo získat již archivované soubory i s důkazním materiálem o jejich životním cyklu. Komunikace Brány a Archivu probíhá pomocí transportního protokolu HTTP/HTTPS po interní síti Archivu. Oba moduly jsou odděleny firewallem, který umožňuje pouze tuto komunikaci. Modul archivu je integrován s garantovaným úložištěm pomocí API, které úložiště poskytuje. Žádný jiný modul s garantovaným úložištěm přímo nekomunikuje, pouze skrz služby logické vrstvy. Modul archivu není přímo integrován s žádnou interní, nebo externí službou. Pokud potřebuje funkcionality takové služby, jsou zprostředkovány skrz Bránu.

Technické detaily a nastavení pravidel pro komunikaci mezi jednotlivými segmenty (ACL) Objednatel konkrétně nestanovil, aby ponechal dodavatelům prostor pro návrh řešení, které bude splňovat celkové požadavky specifikované v Příloze č. 2 Smlouvy.

2. Migrace současného prostředí

Odhadovaný počet dokumentů, které bude nutné zmigrovat bude cca 23mil. Celkový objem dat je odhadovaný na cca 7TB. Objednatel požaduje po dodavateli archivu zajištění a poskytnutí takové formy připravy prostředí, která bude odpovídat požadavkům pro zajištění migrace, které v soucčasné době nejsou znamé, a proto je Objednatel nemůže nadále zpřesnit. Zdrojová platforma, kde jsou data uložena, je Dell EMC Centera. Zmigrovaná data budou do provedení implementace CDA uložena plně v prostředí Objednatele.

3. Předpokládané objemy dat

Předpokládaný počet nových dokumentů předaných do archivu ročně nebo denně, kde iniciální odhady jsou: vlastní digitalizace (digitalizační linka) cca 10% a dalším vstupem bude příjem z externích dat cca 90%. Následující údaj vychází z celkového objemu dat a může se rok od roku lišit. Odhadem bude předpokládaný objem dat v průměru za jeden rok cca 3TB. Maximální předpokládaný počet dokumentu zaslaných za jeden den za kontrolu malware: Denní zatížení nebude rovnoměrné a bude záležet na aktuální situaci. Z toho plyne, že počty mohou být různé, a proto tento parametr Objednatel nestanovil.

3. Bezpečnost CDA

   1. Obecné požadavky

Objednatel požaduje:

• zabezpečit plnění ustanovení vyplývajících ze zákona č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů;

• respektování opatření informační bezpečnosti ze zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů;

• zabezpečit přípravu na provedení interního auditu úložiště podle metodiky DRAMBORA (Digital Repository Audit Method Based on Risk Assessment).

2. Provozní bezpečnost

CDA bude provozován v prostředí, které uplatňuje prostředky fyzické a kybernetické bezpečnosti:

• pro zajištění ochrany na úrovni objektů nebo souborů;

• pro zajištění ochrany v rámci objektů nebo souborů zajištěním zvýšené bezpečnosti vymezených prostor, ve kterých jsou umístěná technická aktiva systému;

• pro ochranu informací a jednotlivých technických aktiv systému, v souladu s interními předpisy a v souladu se zákonem o kybernetické bezpečnosti;

• pro zajištění zabezpečení řešení musí být funkčně i provozně a fyzicky odděleno uživatelské rozhraní (Brána CDA) od samotného Archivu;

• Zajištění možnosti anonymizace dat.

3. Technická opatření

Technická opatření pro zajištění informační bezpečnosti v souladu s interními předpisy a v souladu se zákonem o kybernetické bezpečnosti, zajišťující zejména:

• ověření identity uživatelů a možnost definice požadovaných heslových politik,

• řízení přístupových oprávnění,

• ochranu před škodlivým kódem,

• aplikační bezpečnost,

• využívaní vhodných kryptografických prostředků,

• dostupnost informací,

• fyzické oddělení komponent Archiv, Badatelna, Brána

• zaznamenávaní činností systému a uživatelů,

• zabezpečení možnosti logování všech komponent systému,

• zajištění napojení na systémy monitorování a dohledu, tak aby bylo možné detekovat a vyhodnotit kybernetické bezpečnostní události.

V následujících podkapitolách jsou uvedeny technická opatření, které musí být zajištěny vzhledem k povaze a architektuře systému CDA.

4. Bezpečnost archivovaných dokumentů

Všechny archivované soubory musí být před samotnou archivací zkontrolované na přítomnost malware. Řešení nesmí spoléhat pouze na detekci podle známých signatur, ale provádí pokročilejší behaviorální analýzu chování souboru v různých situacích.

5. Bezpečnost databází

Provozní databáze budou respektovat doporučení výrobce databáze a související „best practice“ v oblasti zabezpečení databází. Základní body zabezpečení lze rozdělit do několika oblastí.

Autentizace a autorizace

Databázové účty budou respektovat platná pravidla, zákonné předpisy a interní normativní akty ohledně komplexity hesla. To se týká nejen databázových účtů nutných pro provoz samotných aplikací a elektronického archivu, ale všech dalších účtů ve stejné databázi. To je důležité z pohledu omezení kompromitace účtů vlastního archivu prostřednictvím jiných, méně zabezpečených databázových uživatelů. Všechny databázové účty budou také respektovat politiku minimálních nutných oprávnění, tedy budou mít přístup pouze k takovým funkcím a objektům nebo souborům databáze, které nezbytně potřebují. Toto se týká i případných veřejných (PUBLIC) rolí v databázi, kterým budou odebrána veškerá nepotřebná oprávnění. Nepotřebné implicitní databázové účty budou v provozních databázích uzamknuty, servisní a další potřebné účty nebudou mít výchozí hesla, nýbrž hesla podle platných doporučení jako účty ostatní. Na provozních databázích nebude umožněna lokální OS autentizace, ani vzdálená OS autentizace.

Provoz a audit

Celé řešení bude funkční na podporovaných verzích databáze příslušného výrobce, včetně nainstalovaných posledních vydaných bezpečnostních balíčků. Po příslušném otestování bude možný upgrade na vyšší verzi databáze, stejně tak instalace potřebných opravných a bezpečnostních balíčků. Mimo standardní ošetření zranitelností prostřednictvím bezpečnostních záplat řešení musí umožnovat pokročilou ochranu před cíleným útokem na zveřejňované zranitelnosti databází včetně proaktivního monitoringu provozu nad databází tak, aby bylo možné podezřelou aktivitu včas vyhodnotit a zamezit případnému útoku. Auditovány musí být minimálně neúspěšné pokusy o jakékoli operace, přístup privilegovaných uživatelů, a veškeré servisní operace nad databází. Auditní záznamy je nutné ukládat, pořizovat a přistupovat k nim nezávisle tak, aby nebyla možná jejich kompromitace ze strany databázového správce.

Testovací prostředí bude respektovat stejné politiky jako prostředí produkční. Pokud bude vyžadován přístup širšího okruhu uživatelů, případně by z testovacích důvodů nebylo možné dodržet některá bezpečnostní pravidla, musí být možné při zachování funkčnosti provozovat toto prostředí bez obsahu, nebo s účinně pozměněnými citlivými daty.

Databázové zálohy

Provozní databáze budou v pravidelných intervalech zálohovány.

6. Kontrola změn a integrity prostředí

Součástí řešení musí být nástroj umožňující nastavení politik pro přístup ke konfiguračním souborům a registrům pro prevenci neoprávněných zásahů. Veškeré změny v těchto souborech musí být monitorovány.

Pro zachování integrity prostředí musí řešení dále umožňovat zamezení spouštění veškerých neautorizovaných a neznámých aplikací v prostředí CDA.

7. Síťová bezpečnost

Segmentace sítě

Síť musí být vhodně segmentovaná a přístup mezi Archivem, Bránou a externími systémy musí být bezpečně řízen:

Komunikace mezi Bránou a Archivem musí být omezena na minimum nezbytných služeb.

Mezi Archivem a externími systémy nesmí probíhat žádná přímá komunikace.

Komunikace mezi jednotlivými segmenty musí být kontrolovaná na síťové i aplikační vrstvě.

Oddělení provozu mezi Badatelnou, Archivem, Bránou a externími systémy musí být realizováno na bázi fyzického oddělení komunikačních kanálů. Logické oddělení jednotlivých částí systému pomocí principu VLAN (IEEE 802.1q) není považováno za dostatečné.

Analýza bezpečnosti provozu

Servery hostující jednotlivé součástí CDA musí být proaktivně chráněny před kybernetickými hrozbami a útoky. Objednatel musí poskytovat dostatečnou součinnost při nastavení auditingu a logování. Řešení proto musí podporovat funkcionality jako detekce a blokace neautorizovaných síťových požadavků, blokace nevyužívaných portů, aplikační monitoring, ochrana před exploity a ochrana před dalšími relevantními hrozbami.

Zpracování, detekci a analytickou činnost bude zajišťovat Objednatel prostřednictvím svého pracoviště SOC a není to předmětem této Smlouvy. Dodavatel je povinen pouze poskytnout součinnost při uvedených činnostech, a to v rozsahu min. 1MD/ měsíc (Dodavatel zohlední potřebný počet MD dle svých zkušeností z obdobných projektů).

3. Hardware komponenty pro funkčnost řešení

   1. Hardware

Hardware potřebný pro fungování celého řešení musí být zahrnut v ceně. Jedná se především
o servery, úložiště, bezpečnostní a síťové prvky v primární i záložní lokalitě.

Specifikace HW jsou uvedeny v Příloze č. 3 Smlouvy.

Celé řešení musí být schopné splnit následující funkcionalitu (mimo jiné):

• Minimálně 3 kopie souborů/objektů napříč nody

• Podpora ověřovacích technologií uživatelských identit - AD, LDAP, RADIUS

• Zařízení musí umět funkci datové ochrany Erase-coding, tzn. rozdělení souboru/objektu do několika menších objektů a uložení těchto objektů na různé nody clusteru a to i geograficky. Takto rozdělený objekt musí být dostupný z jakéhokoliv nodu z daného klasteru.

• Zařízení musí podporovat funkci nesmazatelnosti a neměnnosti dokumentu/objektu.

2. Digitalizační pracoviště

Z důvodu existence již provozovaných digitalizačních pracovišť Objednatele pro provoz spisové služby, budou tato pracoviště využita i pro účely CDA. Dodávka digitalizačního pracoviště tedy NENÍ předmětem této Smlouvy.

3. Pracovní stanice uživatelů

U jednotlivých archivářů se předpokládá využití stávajících standardně vybavených PC s přístupem do sítě Objednatele s danou SW konfigurací dle schválených standardů Objednatele – standard Windows 10. Objednatel požaduje, aby nabízené řešení bylo kompatibilní s touto konfigurací.

V případě, že řešení předpokládá úpravu pracovních stanic, musí být tato skutečnost uvedena v popisu řešení CDA v Příloze č. 4 Smlouvy. Pokud tato úprava znamená i náklady na úpravu stanic v podobě hardware nebo dodatečných licencí, nese je Dodavatel a je povinen tyto náklady zahrnout do ceny za poskytnutí Plnění dle čl. 2.1 písm. a) – c) Xxxxxxx.

3. Služby

   1. Dostupnost systému CDA

Požadovaná dostupnost celého systému pro dlouhodobé uchovávání elektronických dokumentů a dat je v pracovní dny a v pracovní době od 08.00 do 16.00 hod (doba provádění servisních zásahů). SLA systému Objednatel požaduje na úrovni dostupnosti obsahu CDA 99%.

2. Záruční servis

Dodavatel zajistí bezplatný záruční servis HW CDA po dobu Záruky za jakost, tj. po dobu 24 měsíců od převzetí dodávky HW CDA na základě Předávacího protokolu, není-li ve Smlouvě stanovena u u části HW CDA doba delší. Objednatel v době záruky nebude používat zdrojové kódy k změnám programového vybavení.

V případě, že oprávněná osoba Objednatele (obsluha CDA) nahlásí na základě dohodnutých procesů pro udržení SLA Dodavateli incident, musí jej Dodavatel následně řešit. Souhrn incidentů, odstávek a jiných skutečností, které mají vliv na dostupnost CDA, bude Dodavatel v měsíčním režimu reportovat Objednateli. Report bude obsahovat dobu nedostupnosti CDA, vyhodnocení SLA, důvody a příčiny incidentů, řešení a opatření (návrhy a stavy) pro odstranění či mitigaci příčin a plán výpadků a bude poskytován Objednateli v elektronické podobě.

Záruční doba neběží po dobu, po kterou Objednatel nemůže užívat HW pro jeho vady, za které odpovídá Xxxxxxxxx. Dodavatel zajistí Objednateli záruční servis včetně dodávky potřebných náhradních dílů. Případná výměna pevných disků bude prováděna na místě plnění s tím, že nefunkční vadné disky zůstávají natrvalo v majetku Objednatele.

Předmětem záručního servisu se rozumí:

• Dodavatel bude trvale udržovat v pohotovosti potřebný počet vlastních pracovníků pro zásahy v rámci záručních oprav, jejichž seznam je povinen předat Objednateli (s osobními údaji nutnými k zabezpečení vstupu do objektu).

• Záruční opravy hardwarových komponent a aktualizace firmware dodaného řešení.

Servisní zásah v rámci Záruky za jakost je ukončen odsouhlasením určeným pracovníkem Objednatele poté, co Dodavatel oznámí uvedení zařízení do plného provozního stavu a ten zkontroluje plnou funkčnost systému.

Součástí záručního servisu HW CDA je i zabezpečení telefonického a emailového Helpdesku pro pracovníky centrálního dohledu Objednavatele pro příjem oznámení o nefunkčnosti systému nebo jeho komponent.

Po dobu Záruky za jakost na HW CDA je Dodavatel povinen poskytnout Objednateli záruční servisní podporu s těmito parametry poskytování:

• 7x24 pro registraci požadavků přes internet (Helpdesk),

• reakční doba do 2 hodin od nahlášení vady v pracovní době,

• 5x8 (pracovní dny 8:00 – 16:00) pro dobu odezvy,

• zahájení zásahu nejpozději Next Business Day (následující pracovní den).

3. Technická podpora hardwarových a softwarových komponent – maintenance CDA

Dodavatel zajistí Podporu podle čl. 2.1 písm. d) Xxxxxxx po dobu 48 měsíců od akceptace dodávky CDA na základě Akceptačního protokolu v souladu s požadavky na dostupnost CDA. Objednatel v době poskytování Podpory nebude používat zdrojové kódy k změnám programového vybavení.

V případě, že oprávněná osoba Objednatele (obsluha CDA) nahlásí na základě dohodnutých procesů pro udržení SLA Dodavateli incident, musí jej Dodavatel následně řešit. Souhrn incidentů, odstávek a jiných skutečností, které mají vliv na dostupnost CDA, bude Dodavatel v měsíčním režimu reportovat Objednateli. Report bude obsahovat dobu nedostupnosti CDA, vyhodnocení SLA, důvody a příčiny incidentů, řešení a opatření (návrhy a stavy) pro odstranění či mitigaci příčin a plán výpadků a bude poskytován Objednateli v elektronické podobě.

Předmětem Podpory se rozumí:

• Dodavatel bude trvale udržovat v pohotovosti potřebný počet vlastních pracovníků pro zásahy, jejichž seznam je povinen předat Objednateli (s osobními údaji nutnými k zabezpečení vstupu do objektu)

• technická podpora,

• opravy hardwarových a softwarových komponent CDA a aktualizace firmware dodaného řešení,

• údržba SW licencí,

• aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA,

• legislativně-právní upgrade SW CDA (zajištění legislativního souladu po celou dobu účinnosti Smlouvy),

• bezpečnostní patche,

• aktualizace dokumentace a uživatelských příruček k CDA,

• seznámení administrátorů a uživatelů s prostředím CD.

Servisní zásah je ukončen odsouhlasením určeným pracovníkem Objednatele poté, co Dodavatel oznámí uvedení zařízení do plného provozního stavu a ten zkontroluje plnou funkčnost systému.

Součástí Podpory je i zabezpečení telefonického a emailového Helpdesku pro pracovníky centrálního dohledu Objednatele pro příjem oznámení o nefunkčnosti systému nebo jeho komponent.

V rámci Podpory Dodavatel zajistí odstranění zjištěných vad (poruch) na konkrétním místě a opětovné uvedení zařízení do provozu v těchto lhůtách:

• 5x8 (pracovní dny 8:00 – 16:00) pro dobu odezvy,

• 7x24 pro registraci požadavků přes internet,

• reakční doba do 2 hodin od nahlášení vady v pracovní době,

• zahájení zásahu nejpozději Next Business Day (následující pracovní den).

• Odstranění poruchy:

• havarijní porucha (způsobí přerušení celkového provozu) - odstranění poruchy do 24 hodin od nahlášení Objednatelem,

• běžná porucha (omezení funkčnosti jednotlivých zařízení) - odstranění poruchy do 80 hodin od nahlášení Objednatelem,

• poškození nebo drobné poruchy (nemají vliv na schopnost systému plnit požadované funkce ve vyhovující kvalitě) – zahájení opravy do 80 hodin od nahlášení Objednatelem.

O závažnosti poruchy rozhoduje výhradně Objednatel.

Součástí Podpory (u SW se jedná o komerční programové vybavení, nebo i speciálně vyvinuté aplikační programové vybavení, pokud bude součástí řešení CDA) je zajištění Služby Media Retention (vyměněné nosiče dat se při opravě nevracejí).

Provozní zajištění vychází ze standardů ISO 20000 a ISO 27002.

3. Požadavky na akceptaci dodávaného CDA

Akceptační procedura zahrnuje ověření, zda Dodavatelem provedené Plnění vedlo ke smluvenému výsledku, tedy zda odpovídá specifikaci, která je na základě Smlouvy závaznou, a to porovnáním skutečných vlastností jednotlivých částí poskytnutého Plnění s jejich specifikací obsaženou ve Smlouvě, včetně jejích příloh.

Akceptace řešení je podmíněna prokázáním komplexní funkčnosti v následujících bodech:

1. Splnění všech požadavků uvedených v Příloze č. 2 Smlouvy a

2. Splnění technických požadavků na HW CDA uvedených v Příloze č. 1 a 3 Smlouvy.

Příloha č. 2 Smlouvy: Požadavky Objednatele na SW CDA

1. Legislativní a normativní požadavky

Poř. č.	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
1	Řešení je vybudováno dle referenčního modelu OAIS = Open archival information system (Reference Model, ISO 14721).	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
2	Řešení musí pro zajištění dlouhodobé důvěryhodnosti digitálních archiválií využívat elektronického podpisu a časového razítka v souladu s ETSI standardy rozšířeného elektronického podpisu AdES.	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
3	Navrhované řešení je v souladu s nařízením eIDAS (910/2014/ES) o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu včetně následně přijatých a v době podání nabídky platných prováděcích předpisů (zákon č. 297/2016 Sb., zákon č. 298/2016 Sb.).	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
4	Řešení podporuje proces dlouhodobé archivace dle normy ETSI:	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
	Kontrola platnosti elektronických podpisů připojených k archiválii. To zahrnuje neporušenost kontrolního součtu a platnost certifikátu.	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
	Připojení technických metadat: aktuální verze CRL (seznam zneplatněných certifikátů), OCSP odpovědi, případně další.	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
	Připojení časového razítka tak, aby kontrolní součet chránil nejen samotnou archiválii, ale i její metadata.	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky
	Periodické připojování dalších časových razítek tak, aby každé další bylo připojeno před vypršením platnosti předchozího.	ANO	Kap. 2.1 Legislativní a normativní požadavky nabídky

2. Požadavky na proces archivace

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
5	Řešení je schopno důvěryhodně ukládat elektronické archiválie po neomezenou dobu (z pohledu aktuálních technologií, legislativy).	ANO	Kap. 2.2.2. Archiv
6	Řešení umožňuje příjem vstupních dat včetně archivních balíčků, jejich prověření v rámci karantény, dlouhodobé uložení a opětovné poskytnutí archiválií oprávněným žadatelům.	ANO	Kap. 2.2.2. Archiv
7	Řešení podporuje procesy spojené s vyřazováním archiválií z archivu.	ANO	Kap. 2.2.2. Archiv
8	Řešení zajišťuje trvalé, neměnné a důvěryhodné uložení archivovaných elektronických archiválií.	ANO	Kap. 2.2.2. Archiv
9	Důvěryhodnost uložených elektronických archiválií je zajištěna pomocí technologií uznávaného elektronického podpisu a kvalifikovaného časového razítka.	ANO	Kap. 2.2.2. Archiv
10	Řešení umožňuje tvorbu archivních balíčků zajišťujících dlouhodobou platnost celé sady elektronických archiválií.	ANO	Kap. 2.2.2. Archiv
11	Dlouhodobá platnost elektronických archiválií je udržována pomocí přerazítkování archivních balíčků.	ANO	Kap. 2.2.2. Archiv
12	Elektronické archiválie je možné balíčkovat nezávisle na jejich typu, významu, různých přístupových právech a bez jejich vzájemného vztahu.	ANO	Kap. 2.2.2. Archiv
13	Důkazní materiál je poskytován k jednotlivým elektronickým archiváliím bez ohledu na ostatní dokumenty v balíčku, bez jejich kompromitace a bez ohledu zda v čase poskytnutí důkazního materiálu existují.	ANO	Kap. 2.2.2. Archiv
14	Řešení umožňuje řízení procesu tvorby balíčků dle různých archivačních politik.	ANO	Kap. 2.2.2. Archiv
15	Řešení umožňuje nastavit archivační politiky s ohledem na optimalizaci procesu razítkování.	ANO	Kap. 2.2.2. Archiv
16	Řešení umožňuje periodickou kontrolu platnosti certifikátů časových razítek a provádí automatickou obnovu časových razítek.	ANO	Kap. 2.2.2. Archiv
17	V případě, že archiválie prošla procesem vyřazení a byla určena k odstranění, systém umožní mazání jednotlivých archiválií z balíčku, bez narušení možnosti prokázat důvěryhodnost ostatních archiválií z balíčku.	ANO	Kap. 2.2.2. Archiv
18	Archivní balíčky a jejich důvěryhodnost musí být nezávislé na vlastnostech archivního úložiště.	ANO	Kap. 2.2.2. Archiv
19	Při příjmu elektronických dokumentů do archivu je kontrolována integrita archivovaného dokumentu, zda od podepsání dokumentu elektronickým podpisem nedošlo k jeho modifikaci.	ANO	Kap. 2.2. a 2.2.1 Brana
20	Řešení umožňuje poskytnutí archiválie ve formě výstupního DIP balíčku jako důkazního materiálu.	ANO	Kap. 2.2.2. Archiv
21	Řešení ověřuje při kontrole platnosti elektronických podpisů a časových razítek platnost kvalifikovaných certifikátů vydaných kvalifikovanými poskytovateli služeb vytvářejících důvěru, které poskytují služby v rámci Evropské unie.	ANO	Kap. 2.2.2. Archiv
22	Řešení musí ukládat veškeré informace nutné pro ověření/prokázání právní platnosti archiválií, a to i po vypršení platnosti certifikátů, na kterých jsou založeny elektronické podpisy.	ANO	Kap. 2.2.2. Archiv
23	Řešení umožňuje archivaci elektronických archiválií libovolných formátů.	ANO	Kap. 2.2.2. Archiv
24	U archiválií lze ukládat různá metadata, minimálně v rozsahu typů text, celé číslo, číslo s desetinou čárkou, logická hodnota a datum) včetně vícehodnotových metadat.	ANO	Kap. 2.2.2. Archiv
25	Řešení podporuje proces vedení evidence, v rámci které jsou vedeny informace o dokuementech kde došlo k vyřazení z archivu.	ANO	Kap. 2.2.2. Archiv
26	Ke každé archiválii je veden badatelský list, v rámci kterého jsou vedeny také záznamy o poskytnutí kopie archiválie nebo důkazního materiálu.	ANO	Kap. 2.2.3 Badatelna
27	Systém obsahuje monitoring operací zachycující veškeré operace s archiválií.	ANO	Kap. 2.2.2. Archiv
	Ukládání záznamů o veškerých operacích s archiválií.	ANO	Kap. 2.2.2. Archiv
	Rozhraní pro zobrazení záznamů o operacích s konkrétní archiválií.	ANO	Kap. 2.2.2. Archiv
	Rozhraní pro vyhledávání v těchto záznamech napříč všemi archiváliemi, vytváření sestav, reporting a varovné mechanismy upozorňující na nestandardní nebo podezřelé chování.	ANO	Kap. 2.2.2. Archiv

3. Požadavky na uživatelské funkce

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
28	Řešení umožňuje ruční vstup elektronických dokumentů prostřednictvím uživatelského rozhraní Brány. Takto vložený dokument prochází stejným procesem, jako vstupní dokument zaslaný jiným systémem prostřednictvím rozhraní.	ANO	Kap. 2.2.1 Brána
29	Archiválie je možné vyhledávat pomocí metadatových položek, fulltextově, nebo kombinací obou způsobů.	ANO	Kap. 2.2.2. Archiv
30	Podoba výsledků vyhledávání je uživatelsky konfigurovatelná (ve smyslu zobrazených dat ve výsledkové sadě - např. řazení, množina zobrazených metadat).	ANO	Kap. 2.2.2. Archiv
31	Výsledky vyhledávání jsou omezeny přístupovými právy uživatele.	ANO	Kap. 2.2.2. Archiv
32	Výsledky vyhledávání je možné exportovat ve vhodném formátu.	ANO	Kap. 2.2.2. Archiv
33	K vybrané položce výsledku vyhledávání je možné si zobrazit detailní informace.	ANO	Kap. 2.2.2. Archiv
34	Oprávněný uživatel může editovat vybraná metadata archiválie.	ANO	Kap. 2.2.2. Archiv
35	Množiny evidovaných metadat je možné konfigurovat zvlášť pro různé typy archiválií. Konfiguraci metadat je možné měnit v průběhu života systému.	ANO	Kap. 2.2.2. Archiv
36	Možnost zobrazení vybraných formátů dokumentů v podobě náhledu, bez nutnosti stažení celého dokumentu na pracovní stanici uživatele. Požadovány jsou alespoň tyto formáty: Office dokumenty (DOC, DOCX, XLS, XLSX, PPT, PPTX, ODT, ODS, ODP), PDF dokumenty, Rastrové obrázky (TIFF včetně vícestránového TIFF, JPEG, BMP, PNG, GIF), HTML soubory.	ANO	Kap. 2.2.2. Archiv
37	Vyhledané archiválie je možné zpřístupnit prostřednictvím Portálu Badatelna, který slouží pro dočasné zpřístupnění “kopie“ archivovaného dokumentu oprávněným (ztotožněným) osobám v režimu pouze pro čtení.	ANO	Kap. 2.2.2. Archiv
38	Systém obsahuje prohlížeč dokumentů, který umožňuje přidávat k zobrazovanému dokumentu popisky, poznámky, grafické symboly (čáry, šipky, geometrické obrazce) – tzv. anotace a musí umožnit uložit anotace bez modifikace zobrazeného dokumentu. Prohlížeč také umožňuje stránkovat, zvětšovat/zmenšovat, otáčet a tisknout zobrazované dokumenty včetně jejich anotací.	ANO	Kap. 2.2.2. Archiv
39	V rámci Badatelského portálu je zaznamenávána činnost ztotožněného uživatele s vyžádanou poskytnutou kopií archiválie. Údaje jsou zapisovány do badatelského listu.	ANO	Kap. 2.2.3. Badatelna
40	Archiváři jsou v rozsahu jeho oprávnění k dispozici statistické informace o archivu a jeho využití, např.: celkový objem archiválií v archivu, objem archiválií daného typu, přírůstek archiválií za dané období, a jiné. Tyto informace jsou dostupné v podobě standardizovaných reportů. Archivář si ale může vytvořit sestavu podle vlastních potřeb.	ANO	Kap. 2.2.2. Archiv
41	Dodaný systém CDA disponuje nástroji pro tvorbu, údržbu a správu workflow, umožňující zasílat e-mailové notifikace pro nastavené situace (např. příjem nevalidního dokumentu) a obsahující workflow systém a nástroje pro definování, spouštění, reporting a správu workflow, umožňující ad-hoc definování úloh koncovým uživatelem v průběhu zpracování konkrétní instance workflow, podporující přidělování úkolů na konkrétního uživatele nebo na celou roli v rámci řešení konkrétních úkolů. Součástí řešení musí být administrační prostředí pro návrh a správu workflow realizované formou webové aplikace.	ANO	Kap. 2.2. Architektura navrženého řešení
42	Je zajištěna podpora procesu založení a schválení požadavku na poskytnutí informací z archivu.	ANO	Kap. 2.2.2. Archiv
43	Všechny části řešení (Brána, Archiv, Badatelský portál, GUI atd.) podporují práci s formáty minimálně PDF, PDF/A; MS Office – DOC, DOCX, PPT, PPTX, XLS, XLSX, RTF; JPG, GIF,TIF/TIFF, PNG, XML.	ANO	Kap. 2.2.2. Archiv

4. Specifické požadavky

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
44	Systém podporuje provoz na fyzickém i virtualizovaném hardware.	ANO	Kap. 2.2. Architektura navrženého řešení
45	Systém je provozován v primární a záložní lokalitě, testovací instance je pouze v primární lokalitě.	ANO	Kap. 2. Popis řešení +
46	Uživatelská vrstva tvořená webovou aplikací bude podporovat všechny běžně používané prohlížeče: MS Edge, Firefox, Chrome, Opera v aktuálních verzích (se zpětnou kompatibilitou nejméně o jednu verzi oproti aktuální v době nasazení systému).	ANO	Kap. 2.2. Architektura navrženého řešení
47	Použité Licence Archivu a Brány jsou omezeny počtem uživatelů na maximum 5000 uživatelů. Počtem zpracovaných dokumentů není Licence omezena.	ANO	Kap. 2.2. Architektura navrženého řešení
48	Použité Licence Badatelského portálu jsou omezeny počtem uživatelů na maximum 5000 uživatelů. Počtem zpracovaných dokumentů není Licence omezena.	ANO	Kap. 2.2. Architektura navrženého řešení

5. Požadavky na architekturu systému

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
49	Systém se skládá ze tří vrstev: Brána Uživatelská a integrační vrstva, která zabezpečuje práci uživatelů a poskytuje rozhraní pro napojení dalších systémů. V rámci Brány je také implementována Karanténa. Archiv Procesy v archivu; udržuje dlouhodobou platnost důvěryhodných elektronických prvků a garantované dlouhodobé uložení dat. Badatelský portál umožňuje nahlížení do archiválií externím subjektům.	ANO	Kap. 2.2. Architektura navrženého řešení
50	Brána a Archiv jsou od sebe odděleny firewallem s jasně definovanými pravidly komunikace a komunikují spolu po oddělených kanálech.	ANO	Kap. 2.2. Architektura navrženého řešení
51	Badatelský portál je od ostatních částí systému striktně oddělený, jsou na něm uloženy kopie archiválií z Archivu ve formě metadat a u vybraných archiválií jejich interpretacemi s vodoznakem, s Archivem CDA komunikuje výhradně přes firewall.	ANO	Kap. 2.2. Architektura navrženého řešení
52	Systém poskytuje jedno nebo více standardních rozhraní (např. WS/SOAP, WS/REST), pomocí kterých jsou s  CDA integrovány zdrojové systémy (tj. systémy, ze kterých pocházejí elektronické dokumenty).	ANO	Kap. 2.2. Architektura navrženého řešení
53	Jednotlivé vrstvy nejsou pevně integrovány a komunikují mezi sebou pomocí jasně definovaných standardních rozhraní.	ANO	Kap. 2.2. Architektura navrženého řešení
54	Uživatelská vrstva je realizovaná jako webová aplikace (lehký klient) pomocí současných technologií (HTML, CSS, Javascript a potřebné serverové technologie). Uživatelskou vrstvu pro práci koncových uživatelů musí být možné modifikovat, přizpůsobit nebo doplnit o nové funkcionality řízeným a zdokumentovaným způsobem.	ANO	Kap. 2.2.2 Archiv + kap. 2.2.3. Badatelna
55	Systém umožňuje používat externí evidenci uživatelských účtů a rolí typu LDAP. Vedle toho disponuje systém interní evidencí uživatelských účtů.	ANO	Kap. 2.2. Architektura navrženého řešení
56	Řešení podporuje autorizaci přiřazením uživatelských rolí, které nabízejí určitou sadu funkcí (podpora 6 různých uživatelských rolí: Admin, Analyst, Operator, Monitor, Auditor, API_analyst).	ANO	Kap. 2.2. Architektura navrženého řešení
57	Komponenty, které potřebují komunikovat s fyzickým úložištěm dokumentů (Archivem), s ním komunikují prostřednictvím logické vrstvy. Žádná komponenta s Archivem nekomunikuje přímo.	ANO	Kap. 2.2.2 Archiv
58	Vybraným uživatelům – archivářům – je umožněn přístup přímo do části Archivu prostřednictvím uživatelského rozhraní Archivu. Logická vrstva Archivu poskytuje služby DMS pro práci s archiváliemi.	ANO	Kap. 2.2.2 Archiv
59	Součástí CDA je SW pro anonymizaci. Archiválie nebude při procesu anonymizace stažena na PC archiváře, SW umožní co nejefektivnější práci vč. možnosti automatizace, anonymizovaná část nesmí být vložena do dokumentu jako oddělitelná vrstva, ale musí trvale znečitelnit zobrazitelná data.	ANO	Kap. 2.2.2 Archiv
60	Systém zajistí zabezpečené oddělení Badatelského portálu od vlastního Archivu.	ANO	Kap. 2.2. Architektura navrženého řešení
61	Badatelský portál umožní řízení přístupových oprávnění pro administrátora a registraci a správu externích uživatelů ve skupinách: registrovaný uživatel, ztotožněný uživatel.	ANO	Kap. 2.2. Architektura navrženého řešení
62	Badatelský portál má funkce pro vyhledávání archiválií, včetně historie hledání pro aktuální sezení, listování v seznamu vyhledaných archiválií, zobrazení náhledů na archiválie s vodoznakem ve webovém prohlížeči, zobrazení příslušných metadat, formuláře pro žádosti o poskytnutí elektronické kopie původní archiválie v původním rozlišení, případně elektronické kopie s právní závazností (důkazní materiál), pracovní prostor pro ztotožněné uživatele s možností stáhnout si vyžádané archiválie, uživatelské statistiky pro ztotožněné uživatele (např. seznam realizovaných/běžících žádostí o poskytnutí kopie původních archiválií s časovým rozlišením a podobně).	ANO	Kap. 2.2.3. Badatelna

6. Požadavky na dostupnost systému

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
63	Systém je pro uživatele dostupný od 6:00 do 18:00, maximální výpadek je 1% během kalendářního roku.	ANO	Kap. 2.2. Architektura navrženého řešení, Kap. 5.1.1 Dostupnost systému
64	Systém je provozován ve dvou geograficky oddělených lokalitách.	ANO	Kap. 2.2. Architektura navrženého řešení, Kap. 5.1.1 Dostupnost systému
65	Archivní data, včetně dat brány, jsou replikována do záložní lokality. Požadovaný čas přechodu (RTO – Recovery Time Objective) provozování systému z hlavní (aktivní) lokality na záložní (pasivní) lokalitu je 12 hodin. Po této době musí záložní lokalita RPO (Recovery Point Objective) poskytovat plnou funkcionalitu a výkon jako lokalita hlavní.	ANO	Kap. 2. Popis řešení, Kap. 5.1.1 Dostupnost systému

7. Požadavky na úložiště archivních dat

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
66	Zabezpečení dat před ztrátou – úložiště podporuje mechanismy minimalizující možnost ztráty dat.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
67	Fyzické datové úložiště musí umožnit provádět zálohy uložených dat. Řešení musí provádět zálohy uložených dat pomocí jiné technologie než je použita pro samotné datové úložiště a tím vytvořit dodatečnou kopii a ochranu archivovanách.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
68	Zabezpečení dat před změnou – úložiště garantuje, že uložená data nemohou být uživatelským zásahem smazána ani nijak pozměněna (retence). Výjimkou je archivářem naplánované a provedené vyřazení z archivu.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
69	Dlouhodobá rozšiřitelnost/upgrade – úložiště je možné bezproblémově rozšířit/upgradovat po celou dobu jeho provozu bez negativního vlivu na uložená data.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
70	Úložiště je možné upgradovat za běhu bez výpadku provozu.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
71	Podpora replikace a provoz ve více lokalitách – úložiště podporuje provoz ve více geograficky oddělených lokalitách. Data je možné automaticky synchronně replikovat mezi oběma lokalitami. Výpadek jakékoliv komponenty ve kterékoliv lokalitě nesmí způsobit nefunkčnost replikace a nedostupnost úložiště. Data musí být aktivně dostupná v obou lokalitách bez nutnosti provádění přechodu mezi lokalitami.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
72	Organizace dat – data v úložišti je možné organizovat do logických prostorů s oddělenou správou.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
73	Úložiště umožňuje šifrování uložených dat.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
74	Úložiště poskytuje služby komprese nebo deduplikace dat.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
75	S úložištěm lze komunikovat pomocí různých protokolů.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
	K uloženým datům lze přistupovat minimálně pomocí protokolů NFS.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
	S úložištěm lze pracovat pomocí poskytnutého API.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat
	Úložiště má nativní podporu ukládání metadat a práce s nimi.	ANO	Kapitola č. 5.1.2 – Úložiště archivních dat

6. Bezpečnost archivovaných dokumentů

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
76	Veškeré příchozí dokumenty jsou testovány na přítomnost malware na základě behaviorální analýzy, tak aby bylo možné detekovat běžně rozšířený malware, a zároveň následující typy malware:	ANO	Kap. 2.5 Bezpečnost prostředí + kap. 2.5.1 Vlastnosti karantény
	Pokročilý vícestupňový malware založený výlučně na analýze chování a bez použití podpisů, reputačních databází nebo statických pravidel.	ANO	Kap. 2.5.1 Vlastnosti karantény
	Malware pro který nebyly vytvořeny signatury.	ANO	Kap. 2.5.1 Vlastnosti karantény
	Polymorfní malware.	ANO	Kap. 2.5.1 Vlastnosti karantény
	Zero-day exploit a APT hrozby proti desktopovým aplikacím a webovým prohlížečům s použitím různých verzí desktopových aplikací, webových prohlížečů a jejich pluginů za účelem zjištění zneužití malwaru pro konkrétní verzi už při jejich prvním výskytu.	ANO	Kap. 2.5.1 Vlastnosti karantény
	Malware s podmíněnou aktivací (např. předem stanovené datum, specifická akce uživatele apod.).	ANO	Kap. 2.5.1 Vlastnosti karantény
77	Behaviorální analýza probíhá v prostředí architektury x86 a x64 a zahrnuje následující operační systémy ve virtuálních počítačích: Windows 10 RS4/RS5, Windows 8, Windows 7, Windows 7 SP1, Mac OS X. Aplikace: MS Office 2007 a novější, Adobe Reader 9 a novější (v souladu se standardně vybavenými PC).	ANO	Kap. 2.5.1 Vlastnosti karantény
78	Řešení analyzuje různé formáty příchozích dokumentů (minimálně PDF, PDF/A, ZFO, MS Office – DOC, DOCX, PPT, PPTX, XLS, XLSX, RTF, JPG, GIF, TIF/TIFF, PNG a XML, PS1, JS, PY ).	ANO	Kap. 2.5.1 Vlastnosti karantény
79	Testování příchozích dokumentů musí probíhat před začátkem procesu archivace. Neotestované soubory se nesmí dostat do segmentu archivu.	ANO	Kap. 2.5.2 Detailní popis
80	Testování příchozích dokumentů musí probíhat kompletně v infrastruktuře zadavatele.	ANO	Kap. 2.5 Bezpečnost prostředí a její podkapitoly
81	Řešení umožňuje automatizované včasné (v karanténní části) vyřazení dokumentů ze zpracování pokud představují jakoukoliv hrozbu pro celé řešení nebo jeho část.	ANO	Kap. 2.5.2 Detailní popis
82	Dokumenty vyřazené ze zpracování jsou bezpečně uloženy mimo ostatní dokumenty a je zamezeno možnosti ohrožení systému nebo jeho části.	ANO	Kap. 2.5.2 Detailní popis
83	Analýza souborů se provádí v prostorách zákazníka. Žádný zákaznický údaj, soubory nebo objekty nejsou odesílány do cloudu pro provádění dynamické analýzy útoku.	ANO	2.5.1. Vlastnosti karantény
84	Řešení provádí dynamickou analýzu souborů ve virtuálním prostředí (sandbox) jako součást přizpůsobeného hypervisorového frameworku, který je speciálně vytvořen pro účely bezpečnostní analýzy a který není založen na standardním / komerčním hypervisoru, aby se zabránilo detekci sandboxu.	ANO	Kap. 2.5 Bezpečnost prostředí + kap. 2.5.1. Vlastnosti karantény
85	Řešení nabízí detailní informace z analýzy včetně: webových odkazů zapojených do útoku, hash všech objektů, kompletní auditu chování škodlivého softwaru v koncovém zařízení.	ANO	Kap. 2.5.2 Detailní popis
86	Řešení je schopno současně analyzovat více souborů ve stejném virtuálním stroji s chováním všech objektů, které jsou součástí vícefázových / vícenásobných útoků.	ANO	Kap. 2.5.2 Detailní popis
87	Uživatel systému má možnost rozhodnout o dalším způsobu zpracování dokumentů označených jako ohrožující.	ANO	Kap. 2.5.2 Detailní popis
88	Řešení poskytuje komplexní výsledky behaviorální analýzy a detailní report o chování detekovaného malware (změny v registrech, změny v souborovém systému, síťová komunikace apod.). Tyto informace jsou dostupné uživatelům systému.	ANO	Kap. 2.5 Bezpečnost prostředí + kap. 2.5.1 Vlastnosti karantény
89	Vyjma komunikace Badatelského portálu funguje řešení v režimu jednosměrné komunikace (žádná data zadavatele se neodesílají do internetu, z internetu je přípustné stahovat aktualizace a komunikovat s TSA).	ANO	Kap. 2.5.2 Detailní popis
90	Řešení umožňuje v případě potřeby přepnutí do offline režimu (žádná komunikace z/do internetu, manuální instalace aktualizací) bez dodatečných nákladů.	ANO	Kap. 2.5.2 Detailní popis

7. Bezpečnost prostředí archivu

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
91	Jednotlivé části systému jsou segmentovány prostřednictvím firewallu:	ANO	Kap. 2.5 Bezpečnost prostředí a její podkapitoly
	Řešení umožňuje nastavení pravidel pro komunikaci mezi jednotlivými segmenty (ACL).	ANO	Kap. 2.5 Bezpečnost prostředí a její podkapitoly
	Řešení umožňuje tzv. statefull packet inspection provozu procházejícího mezi segmenty.	ANO	Kap. 2.5 Bezpečnost prostředí a její podkapitoly
	Řešení umožňuje analyzovat provoz procházející mezi segmenty sítě na aplikační vrstvě.	ANO	Kap. 2.5 Bezpečnost prostředí a její podkapitoly
92	Před přístupem uživatele k CDA je ověřena jeho identita.	ANO	Kap. 2.1 Popis řešení
	Řešení zajišťuje splnění předem definovaných heslových politik. Zabezpečení uloženého obsahu (dokumentů, složek, vlastních objektů) je: pomocí přiřazení konkrétních přístupových oprávnění (čtení, zápis/modifikace, mazání) odděleně k metadatům a k obsahu pro konkrétní uživatele nebo jejich skupiny v tzv. seznamech oprávnění. pomocí dalších atributů objektu – např. pokud má atribut dokumentu „typ dokumentu“ hodnotu „X“, je tento dokument (a všechny další dokumenty, které mají tento atribut s touto hodnotou) zobrazen definovatelné skupině uživatelů, přestože toto oprávnění není přítomno v seznamu oprávnění těchto dokumentů. Navržená platforma umožňuje kombinaci obou principů zabezpečení obsahu pomocí seznamů oprávnění a pomocí dalších atributů.	ANO	Kap. 2.2. Architektura navrženého řešení
93	Systém umožňuje nastavovat a měnit oprávnění pomocí seznamů oprávnění minimálně těmito způsoby: Přímé přiřazení přístupového oprávnění k objektu koncovým uživatelem, administrátorem nebo aplikací pomocí standardního prezentačního rozhraní nebo pomocí API. Pomocí dědičnosti, kdy nově vzniklý objekt přebírá oprávnění z objektu nadřazeného. Výchozí nastavení zabezpečení pro kategorii dokumentu, které se automaticky aplikuje při jeho vytvoření. Automatické přiřazení a změna oprávnění dle předem definované šablony pro každou fázi životního cyklu dokumentu (draft/ ke schválení/ schváleno/ publikováno).	ANO	Kap. 2.2. Architektura navrženého řešení
94	Systém umožňuje zaznamenávat a uchovávat údaje o veškerých operacích, které byly platformou provedeny nebo které byly požadovány a z důvodu nedostatečných přístupových oprávnění nebyly provedeny. Zaznamenávají a uchovávají se minimálně tyto údaje: Požadavek na operaci. Kdo operaci proved/chtěl provést. Výsledek požadavku. Datum a čas. Je možné definovat, které operace mají být takto auditovány a jak detailní má audit být.	ANO	Kap. 2.2. Architektura navrženého řešení + Kap. 2.6 Bezpečnost dat a informací a jeho podkapitoly
95	Řešení umožňuje zamezení stažení definovaných souborů koncovým uživatelem na jeho pracovní stanici, takový soubor musí být možné pouze prohlížet v integrovaném prohlížeči dokumentů v rámci internetového prohlížeče.	ANO	Kap. 2.2.2. Archiv
96	Jednotlivé bezpečnostní komponenty umožňují napojení na systém dohledu (SIEM). Řešení je schopno odeslat oznámení o zjištěných událostech alespoň pomocí následujících metod: email, http, rsyslog, snmp. Pro integraci s existujícími systémy pro monitorování zabezpečení jsou podporovány následující formáty rsyslog: CEF, LEEF, JSON, XML.	ANO	Kap. 2.2. Architektura navrženého řešení + kap. 2.5
97	V případě výpadku jakékoliv bezpečnostní komponenty v systému není narušena dostupnost služeb.	ANO	Kap. 2.5. Bezpečnost prostředí Archivu

8. Bezpečnost databází

Číslo	Požadavek	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
98	Řešení je provozováno a plně funkční na podporovaných verzích databáze příslušného výrobce, včetně nainstalovaných posledních vydaných bezpečnostních balíčků.	ANO	Kap. 2.6 Bezpečnost dat a informací
99	Řešení musí pravidelně automaticky provádět bezpečnostní testy a vyhodnocovat tak zranitelnosti a hrozby pro provozní databáze, výsledky se dle definovatelného postupu následně doručují příjemcům. Řešení musí podporovat i CVE identifikaci, hledání konfiguračních zranitelností dle CSI a STIG, identifikovat nadměrná a překryv oprávnění.	ANO	Kap. 2.6.3 Modul vyhledávání zranitelností
100	Řešení musí umožňovat rozšíření o monitoring databázového provozu v reálném čase a poskytovat možnost aktivního blokování (podle alespoň ip adresy, uživatelského jména, databáze, tabulky, sloupce, typu databáze) Rozšíření musí být umožněno pouze za pomoci přidání licence bez dalších změn v infrastruktuře.	ANO	Kap. 2.6 Bezpečnost dat a informací + Kap. 2.2. Popis řešení + Kap. 2.5. Bezpečnost prostředí archivu
101	Testovací prostředí je možné efektivně provozovat při zachování plné funkčnosti bez obsahu či s vhodně pozměněnými citlivými daty.	ANO	Kap. 2.6.1 Modul ochrany databází
102	Systém umožňuje pravidelné zálohování provozních databází s následnou možností plné obnovy systému z těchto záloh.	ANO	Kap. 5.1.2 – Bezpečnost databází
103	Zálohy provozních databází je možné ukládat v šifrované podobě bez dopadu na jejich použití pro obnovu systému.	ANO	Kap. 5.1.2 – Bezpečnost databází
104	Řešení obsahuje mechanismy, jak nezávisle na DB správci a zásahu do databáze kontrolovat přístup a provoz nad databází, včetně možnosti omezení přístupu k databázi mimo standardní pracovní okno či okruh uživatelů. To se týká nejen přístupu přes vlastní aplikační logiku systému, ale jakoukoli další cestou.	ANO	Kap. 2.6.1 Modul ochrany databází
105	Řešení umožňuje pořizovat minimálně auditní záznamy o neúspěšných pokusech o jakoukoli operaci, přístup privilegovaných uživatelů a servisní operace nad databází.	ANO	Kap. 2.6.1 Modul ochrany databází
106	Auditní záznamy je možné ukládat, pořizovat a přistupovat k nim tak, aby byly oddělené od správy vlastní databáze a nebyla tak možná jejich nežádoucí modifikace ze strany databázového správce, případně dalších privilegovaných uživatelů.	ANO	Kap. 2.6.1 Modul ochrany databází
107	Řešení obsahuje a respektuje na úrovni databáze seznamy řízení přístupu (ACL).	ANO	Kap. 2.6.1 Modul ochrany databází
108	Řešení musí umožňovat nepřetržitý monitoring používání a toku citlivých údajů uložených v databázích.	ANO	Kap. 2.6. Bezpečnost dat a informací + Kap. 2.6.1 Modul ochrany databází
109	Řešení by se mělo být schopno učit odhalit anomálie aby identifikovalo: nové uživatele, nové typy objektů žádaných uživatelem, změnu chování v SQL struktuře, změnu chování v přístupovém čase.	ANO	2.6.1 Modul ochrany databází
110	Řešení je schopno klasifikovat data pro identifikaci citlivých informací v databázích.	ANO	Kap. 2.6.4 GDPR a compliance
111	Řešení umožňuje, dle nastavených politik maskovat citlivá data, například pro potřeby testování.	ANO	Kap. 2.6.1 Modul ochrany databází
112	Řešení umožňuje zasílat poplachy událostí které identifikuje pomocí: emailu, syslog události, programovatelného API rozhraní.	ANO	Kap. 2.6. Bezpečnost dat a informací
113	Definice pro vyhodnocování by měly být aktualizovány nejméně každé čtvrtletí.	ANO	Kap. 2.6.3 Modul vyhledávání zranitelností
114	Řešení obsahuje alespoň vzorové sady pravidel pro požadavky GDPR.	ANO	Kap. 2.6.4 GDPR a compliance
115	Řešení umožňuje vytváření vlastních klasifikačních pravidel dle: regulárních výrazů, porovnání se slovníkem, programovatelného API rozhraní.	ANO	Kap. 2.6.4 GDPR a compliance
116	Řešení umožňuje vytváření automatizovaných reportů dle naplánovaného rozsahu.	ANO	Kap. 2.6. Bezpečnost dat a informací

Příloha č. 3 Smlouvy: Technická specifikace HW CDA

Čxxxx	Xxxxxxxxx xa HW	Splňuje ANO/NE	Odkaz na popis řešení v Příloze č. 4 Smlouvy
01	2x objektové nebo souborové úložiště 2 zařízení určená pro ukládání datových objektů převážně statického charakteru Replikace musí být provedena při uložení synchronně do dvou zařízení.	ANO, popis řešení Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
02	Požadovaná HW architektura - škálovatelné řešení s možností využití Capacity on Demand	ANO, uvést řešení Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
03	Intra-Cluster migrace - objekty nebo soubory uložené v clusteru nejsou přenášeny po vnější datové síti - veškeré zabezpečení objektů/souborů nebo jejich skupiny nesmí být narušeno	ANO, popis zajištění Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
04	Požadovaná odolnost proti HW poruše - současné selhání až 4 libovolných disků nebo 1 libovolný celý node - v nabízené konfiguraci - možnost zvýšení HW redundance prostým zvýšením počtu node v clusteru - selhání v jedné lokalitě nesmí mít vliv na funkčnost a dostupnost replikovaných dat v zařízení v lokalitě druhé (vybrané datové oblasti - tenants -zařízení se replikují mezi sebou)	ANO, uvést odolnost proti poruše nabízené konfigurace Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
05	Počáteční konfigurace musí obsahovat minimálně - 5x identických cluster node v případě objektové úložiště, 3x identických cluster node v případě souborového úložiště - disky pro data o kapacitě min. 1TB, počet bude určen dodavatelem, tak aby bylo zajištěna použitelá kapacita 35TB - síťová rozhraní podle specifikace viz níže - redundantní napájení 230V - servis jednotlivých cluster node bez použití nářadí	ANO, uvést počet node Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
06	Rack s následujícím vybavením - standardní datový rack pro servery podle doporučení výrobce - redundantní napájecí rozvody - redundantní aktivní síťové prvky - cable management řešení	ANO, uvést konfiguraci Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
07	Kapacitní nároky na datové centrum (RACK, #U), konektivitu (počet a kapacita portů), napájení a spotřebu energie nabízené startovací konfigurace	Popis Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
08	Vnější konektivita objektového úložiště - minimální - 4x 10Gbit/s Ethernet porty, s možností rozšíření jejich počtu adekvátně s kapacitou a výkonem - Rozhraní - SFP+ moduly, musí být součástí nabídky	ANO, uvést skutečné parametry Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
09	Rozšiřitelnost vnější konektivity objektového úložiště bez nutnosti zvýšení počtu node v clusteru - celkem alespoň 8x 10Gbit a / nebo 25Gbit/s (celkem alespoň 8 portů, v kombinaci 10Gb a 25Gb Ethernet) - celkem alespoň 4x 100Gbit/s (celkem alespoň 8x 10Gb/25Gb a 4x 100Gb) Rozšíření formou doplnění příslušného typu rozhraní, za provozu	ANO, uvést rozšiřitelnost Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
10	Interní propojení všech cluster node redundantní sítí s kapacitou - minimálně - 10Gbit/s Ethernet Potřebná redundantní síťová infrastruktura pro min. 16 cluster node musí být součástí nabízeného HW řešení Propojení mezi cluster node a vnější konektivita jsou fyzicky oddělené segmenty sítě	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
11	Minimální nabízená kapacita - 60TB raw - 35TB dostupné v provozním typu zajištění dat s garancí odolnosti proti selhání Do kapacitních výpočtů nesmí být zahrnuto - komprese, deduplikace, tenký provisioning a další nástroje pro datové redukce	ANO, uvést skutečné dosažené parametry pro objekty korespondující s bodem 16 Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
12	Možnost rozšíření na minimálně na 10-tinásobek minimální startovací čisté kapacity. Uchazeč popíše způsob jakým zadavatel může čerpat kapacitu úložtě dle rostoucích potřeb. Uvede cenu za minimální jednotku (min 10 TB čisté kapacity) a dobu nutnou k navýšení kapacity (max 1 týden).	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
13	Startovací minimální počet uložených objektů nebo souborů	MIN 1,8 milionu Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
14	Maximální možná kapacita počtu uložených objektů nebo souborů	MIN 1 miliarda Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
15	Minimální požadovaná propustnost pro práci s objekty.	100KB object size Read Objects/s 3000 Write Objects/s 600 100MB object size Read MB/s 1300 Write MB/s 200 Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
16	Součástí dodávky budou všechny licence potřebné pro provoz a správu řešení	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
17	Architektura úložiště je speciálně navržena pro ukládání velkého objemu datových objektů na velmi dlouhou dobu. Musí umožňovat garanci jedinečnosti, nezměnitelnosti a retence ukládaných dat. Pro budoucí rozvoj pak jejich snadný přenos mezi různými typy cluster node nebo HW platforem bez narušení autenticity.	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
18	Multitenancy na úrovni dat	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
19	Licence pro uložení dat v režimu plné ochrany	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
20	Pro běžný porovoz nebude umožněn přístup k privilegovanému administrátoru.	ANO, popis zajištění bezpečnosti přístupu privilegovaného administrátora Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
21	Nativní ochrana dat dle nabízeného řešení	ANO, popis řešení Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
22	Jestliže je použito objektový typ úložiště - zajistěte následující funkcionalitu: Nativní vyhledávání v metadatech uložených objektů bez nutnosti provozování externí databáze přímo jako vlastnost objektového úložiště. Musí umožnit doplňovat vlastní informace k uloženým objektům v plně programovatelných metadatech a následně v nich vyhledávat. Vyhledávací algoritmus v metadatech nesmí být omezen počtem objektů	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
23	Možnost detailního sledování provozu prostřednictvím SNMP	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
24	Data at Rest Encryption	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
25	Replikace objektů nebo souborů mezi dodanými úložišti, asynchronní. V případě potřeby musí být možno objekty nebo soubory asycnchronně replikovat do páskových úložišť Uchazeč popíše způsob přístupu k datům v situacích výpadku lokality z pohledu aplikace.	ANO, popis řešení, dodavatel popíše způsob přístupu k datům v situacích výpadku lokality z pohledu aplikace. Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
26	Audit pro všechny operace, které jsou s daty a úložištěm prováděny	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
27	Možnost obousměrné georeplikace ve dvou nebo více lokalitách se zachováním single name space a možností konkurenčního přístupu k jedněm datům z více lokalit. Automatický failover archivační aplikace ČP mezi lokalitami v případku nedostupnosti.	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
28	Podporované protokoly objektové úložiště: - S3 včetně dodatečných rozšíření, jako je Atomic Append, Byte Range Updates a ACLS (data uložená v S3 musí být současně čitelná pro HDFS, NFS a Swift) - HDFS verze 2.7 (data uložená v HDFS musí být současně čitelná pro S3, NFS a Swift) - Swift V2 API, včetně Swift / Keystone v3 Authentication (data uložená ve Swift musí být současně čitelná pro HDFS, NFS a S3) - NFS v3 (data uložená ve NFS musí být současně čitelná pro HDFS, Swift a S3) - CIFS výhodou - uvést řešení - REST API Podporované protokoly souborové úložiště: - NFS v3 - CIFS výhodou - uvést řešení	ANO, minimálně tyto uvedené verze Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
29	Pro objektové úložiště: Dostupnost SDK a komunikačních interface (API) pro tyto platformy (= výrobcem OS podporované verze) Windows, CentOS, RedHat, SuSe, Solaris	ANO, uvést výčet nebo kompatibility matici Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
30	Vysoká dostupnost – 99% , systém nesmí obsahovat SPOF	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
31	Online konfigurace a zcela transparentní škálovatelnost a výměna HW (bez jakéhokoli dopadu na provoz – přepínaní záložní cesty z pohledu serveru, nutnost restartu OS, atd.)	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
32	Rozšířená záruka na 4 roky v režimu NBD response.	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
33	Součástí záručních i servisních podmínek a služeb je dodávka a provedení upgrade firmware po celou dobu platnosti smlouvy	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
34	Vadné datové nosiče zůstávají v majetku zadavatele	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.
35	Zapojení do call-home systému dodavatele	ANO Uvedeno v příloze č. 4	Kap. 5.2 Technická specifikace HW CDA.

Příloha č. 4 Smlouvy: Popis řešení CDA Dodavatele

Obsah

Preambule 2

1 Účel Smlouvy 2

1.1 Účelem této Smlouvy je zajistit naplnění legislativních povinností Objednatele formou vybudování Centrálního digitálního archivu České pošty, s.p. (dále jen „CDA“). CDA představuje digitální obdobu fyzického archivu pro dlouhodobé ukládání informací a dokumentů Objednatele a má zajistit efektivní správu a archivaci elektronických dokumentů Objednatele. 2

2 Předmět Smlouvy 2

2.1 Předmětem této Smlouvy je závazek Dodavatele k provedení implementace a zajištění provozu CDA v souladu se Smlouvou a svou nabídkou v Zadávacím řízení, který zahrnuje: 2

a) dodávku hardwarových komponent – kompletní hardware potřebný pro dlouhodobé garantované uložení dokumentů a dat, včetně provozu řešení CDA, a jeho instalace, včetně veškeré dokumentace (např. produktová, uživatelská). Specifikace HW dodávaného Dodavatelem je uvedena v Příloze č. 1 a 3 Smlouvy (dále jen „HW CDA“); 2

b) dodávku plně funkčního softwarového řešení CDA, customizaci, implementaci, integraci, testování, seznámení administrátorů a uživatelů s prostředím CDA, dodání dokumentace a uživatelských příruček, poskytnutí zdrojových kódů doprogramovaných částí softwaru CDA, importních skriptů pro prvotní migraci a exportních skriptů pro případný export dat ze softwaru CDA do následného systému, projektové vedení a udělení práva software CDA užít, tj. Licenci v rozsahu dále uvedeném ve Smlouvě. Požadavky na software CDA jsou blíže uvedeny v Příloze č. 1 a 2 Smlouvy (dále jen „SW CDA“); 2

c) migraci stávajících, již existujících dat ze stávajícího systému Objednatele EMC CENTERA do nově navrženého prostředí CDA; 2

d) technickou podporu hardwarových a softwarových komponent – maintenance CDA po dobu 48 měsíců, zahrnující 2

metodickou podporu archivace (aktualizace dokumentace a uživatelských příruček k CDA, seznámení administrátorů a uživatelů s prostředím CDA), 3

zajištění legislativního souladu CDA po celou dobu účinnosti Xxxxxxx, 3

technickou podporu hardwarových a softwarových komponent CDA, 3

aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA, 3

postupem dle této Smlouvy, a to v požadované kvalitě a úrovních dle Přílohy č. 1 Smlouvy (služby technické podpory a maintanance CDA společně dále jen „Podpora“); 3

2.2 Dodavatel se zavazuje poskytnout Plnění ve sjednaném čase, rozsahu a sjednaným způsobem. Dodavatel se zavazuje poskytnout Plnění v provedení a jakosti odpovídající aktuálnímu stavu technologického vývoje v dané kategorii produktů, jakož i požadavkům Objednatele vymezeným v Příloze č. 1 - 3 Smlouvy. Dodavatel převede vlastnické právo k hmotných složkám Plnění, tj. k hardwarovým komponentům, dokumentacím a uživatelským příručkám na Objednatele. 3

2.3 Objednatel se tímto zavazuje Plnění poskytnuté v souladu se Smlouvou převzít a zaplatit za něj sjednanou cenu dle čl. 3 Smlouvy. 3

2.4 Po uzavření Smlouvy sdělí Objednatel Dodavateli evidenční číslo pro účely fakturace Plnění. 3

3 Cena Plnění a platební podmínky 3

3.1 Celková cena za poskytnutí Plnění dle čl. 2.1 písm. a) – c) Smlouvy činí 23.036.882 Kč bez DPH (slovy: dvacettřimilionůtřicetšesttisícosmsetosmdesátdva korun českých). Celková cena zahrnuje: 3

a) Xxxx za dodávku HW CDA dle čl. 2.1 písm. a) Xxxxxxx ve výši: 8.299.515 Kč bez DPH (slovy: osmmilionůdvěstědevadesátdevěttisícpětsetpatnáct korun českých); 3

b) Cenu za implementaci SW CDA dle čl. 2.1 písm. b) Xxxxxxx ve výši: 9.537.367 Kč bez DPH (slovy: devětmilionůpětsettřicetsedmtisíctřistašedesátsedm korun českých); 3

c) Cenu za migraci stávajících dat dle čl. 2.1 písm. c) Xxxxxxx ve výši: 5.200.000 Kč bez DPH (slovy: pětmilionůdvěstětisíc korun českých). 3

3.2 Za poskytování Podpory dle čl. 2.1 písm. d) Smlouvy v požadované kvalitě a úrovních se sjednává měsíční cena ve výši 247.776 Kč bez DPH (slovy: dvěstěčtyřicetsedmtisícsedmsetsedmdesátšest korun českých). 3

3.3 Platební kalendář za řádně poskytnuté Plnění dle čl. 2.1 písm. a) – c) Smlouvy: 4

Plnění 4

Platební milník 4

Dodávka a instalace HW CDA (čl. 2.1 písm. a) Smlouvy) 4

Po řádném dodání HW CDA komponentů, instalaci a potvrzení Předávacího protokolu dle čl. 5.4 Smlouvy. 4

Implementace SW CDA, integrace do systému Objednatele (čl. 2.1 písm. b) Smlouvy) 4

Po řádné implementaci a integraci CDA do prostředí Objednatele, úspěšném ukončení testování, seznámení pracovníků Objednatele s CDA a potvrzení Akceptačního prokolu dle čl. 5.5 Smlouvy. 4

Migrace stávajících dat (čl. 2.1 písm. c) Smlouvy) 4

Po řádném dokončení migrace stávajících dat z EMC CENTERA do SW CDA a potvrzení Akceptačního protokolu dle čl. 5.5 Smlouvy. 4

3.4 Daňový doklad v případě Plnění dle čl. 2.1 písm. a) až c) Xxxxxxx bude vystaven Dodavatelem v souladu s platebním kalendářem po řádném poskytnutí příslušné části Plnění bez vad v souladu se Smlouvou. Nedílnou součástí daňového dokladu je Objednatelem potvrzený Předávací protokol dle čl. 5.4 Smlouvy (v případě Plnění dle čl. 2.1 písm. a) Smlouvy)/Akceptační protokol dle čl. 5.5 Smlouvy (v případě Plnění dle čl. 2.1 písm. b) a c) Smlouvy), stvrzující řádné poskytnutí části Plnění Objednateli. Dnem uskutečnění zdanitelného plnění je den potvrzení Předávacího protokolu dle čl. 5.4 Smlouvy /Akceptačního protokolu dle čl. 5.5 Smlouvy Objednatelem. 4

3.5 Cena Podpory dle čl. 2.1 písm. d) Xxxxxxx poskytnuté v příslušném kalendářním měsíci bude Objednatelem hrazena měsíčně předem. Dodavatel vystaví daňový doklad vždy první den příslušného období poskytování Podpory (kalendářního měsíce), tento den se zároveň považuje za den uskutečnění zdanitelného plnění. 4

3.6 Měsíční cena za poskytování Podpory bude účtována a hrazena ode dne zahájení poskytování Podpory. O úrovni poskytování Podpory v daném kalendářním měsíci je povinností Dodavatele vyhotovit Report SLA. 4

3.7 Pokud bude Podpora poskytována jen po část kalendářního měsíce, hradí se za příslušný kalendářní měsíc poměrná část měsíční ceny Podpory. V případě, že dojde k ukončení Smlouvy před uplynutím období, za které byla Objednatelem uhrazena cena za Podporu předem, je Dodavatel povinen nejdéle do 10 kalendářních dnů od data ukončení Smlouvy vystavit a zaslat Objednateli opravný daňový doklad na částku uhrazené Podpory, kterou Objednatel nespotřeboval, a tuto částku zaslat na účet Objednatele uvedený v záhlaví této smlouvy. 4

3.8 Celková cena za poskytnutí Plnění dle čl. 2.1 písm. a) – c) Smlouvy a jednotková cena Podpory dle čl. 2.1 písm. d) Xxxxxxx je konečná a nejvýše přípustná a jsou v ní zahrnuty veškeré náklady Dodavatele související s poskytováním Plnění, veškeré odměny za využití Licence dle čl. 8 Smlouvy ve sjednaném rozsahu i cena všech hmotných nosičů či jiných předmětů, jejichž prostřednictvím bude předáno Plnění. 5

3.9 Cena Plnění zahrnuje veškeré náklady Dodavatele spojené s řádným a úplným plněním Smlouvy a poskytnutím Plnění Objednateli, včetně těch, které ve Smlouvě výslovně uvedeny nejsou, ale Dodavatel jakožto odborník a osoba poskytující Plnění s odbornou péčí podle Smlouvy o nich ke dni nabytí účinnosti Smlouvy při vynaložení úsilí, které lze spravedlivě požadovat, vědět měl nebo mohl vědět, že jsou k poskytnutí řádného Plnění nezbytné. 5

3.10 V ceně dodávky HW CDA jsou zahrnuty zejména: 5

a) doprava do místa plnění určeného Objednatelem; 5

b) náklady na balení; 5

c) clo, celní poplatky, daně (vyjma DPH, která bude připočítána v souladu s čl. 2.4 Všeobecných obchodních podmínek, které tvoří Přílohu č. 6 Xxxxxxx) a zálohy; 5

d) recyklační poplatky a ekologická likvidace a činnosti s ní spojené; 5

e) Záruka za jakost a záruční servis v rozsahu stanoveném Smlouvou; a 5

f) veškeré jiné náklady a poplatky nezbytné pro řádné plnění Smlouvy. 5

3.11 Splatnost daňového dokladu vystaveného Dodavatelem je šedesát (60) kalendářních dní ode dne vystavení Dodavatelem. 5

3.12 Objednatel neposkytuje Dodavateli jakékoliv zálohy na cenu. 5

3.13 Dodavatel se zavazuje, že na výzvu Objednatele bude akceptovat oboustranné elektronické zasílání dokladů spojených s poskytováním Plnění (zejména daňové doklady) prostřednictvím portálu SAP Ariba Network. Dodavatel se zavazuje v takovém případě zaregistrovat na portále SAP Ariba Network. Objednatel iniciuje registraci Dodavatele k portálu SAP Ariba Network zasláním elektronické výzvy na kontaktní e-mail Dodavatele (čl. 12.1 Smlouvy). Objednatel prohlašuje, že pro požadované aktivity Dodavatele v rámci nákupního procesu je postačující registrace se standardním účtem Ariba Network, který je bezplatný. Je-li Dodavatel již v SAP Ariba Network registrován, pak lze pro elektronickou komunikaci využít existující AN-ID. 5

3.14 Nevyzval-li Objednatel Dodavatele k zasílání daňových dokladů prostřednictvím portálu SAP Ariba ve smyslu čl. 3.13 Xxxxxxx, zašle Dodavatel fakturu - daňový doklad Objednateli způsobem dle čl. 2.6 Všeobecných obchodních podmínek, které tvoří Přílohu č. 6 Xxxxxxx (dále jen „VOP“). 5

4 Doba, místo Plnění 5

4.1 Plnění dle čl. 2.1 písm. a) – c) této Smlouvy bude Dodavatelem poskytnuto v souladu se závazným harmonogramem (dále jen „Harmonogram“). 5

4.2 Poskytování Podpory dle čl. 2.1 písm. d) Xxxxxxx bude Dodavatelem zahájeno po předání SW CDA do produkčního prostředí na základě podpisu Akceptačního protokolu dle čl. 5.5 Smlouvy k dílčímu Plnění dle 2.1 písm. b) Smlouvy. 6

4.3 Místem plnění je: Česká pošta, s.p., Xxxxxxxx 00/0, Xxxxx 0, a Xxxxxxxx 0, Xxxxx 00. 0

5 Kontrola a akceptace 6

5.1 Řádným poskytnutím Plnění se rozumí implementace požadovaného HW CDA a SW CDA, včetně migrace dat a integrace komunikačního rozhraní do interní infrastruktury Objednatele tak, aby Objednatel mohl zahájit využívání Licence dle čl. 8 Smlouvy a bylo mu umožněno užívání SW CDA ve sjednaném rozsahu. 6

5.2 Spolu s předmětem Plnění bude předána také veškerá dokumentace (produktová, uživatelská) vztahující se k HW CDA a k SW CDA, bez níž by nemohlo docházet k řádnému užívání CDA. Dokumentace bude předána v elektronické podobě, v českém jazyce. 6

5.3 Plnění dle čl. 2.1 písm. a) Xxxxxxx je Xxxxxxxxx povinen dodat Objednateli v souladu s Harmonogramem v pracovní dny v čase od 8:00 do 16:00 hod. 6

5.4 Předání a převzetí HW CDA proběhne na základě protokolárního předání instalovaného HW CDA. Smluvní strany provedou fyzickou kontrolu předávaného HW CDA v místě předání a v případě řádného Plnění podepíšou předávací protokol na dodaný HW CDA (dále jen „Předávací protokol“). HW CDA lze předávat i po částech. 6

5.5 Kontrola a akceptace Plnění dle čl. 2.1 písm. b) a písm. c) Smlouvy probíhá podle parametrů uvedených v Příloze č. 1 Smlouvy, po testování CDA pracovníky Objednatele a je potvrzena podpisem akceptačního protokolu (dále jen „Akceptační protokol“), a to následujícím způsobem: 6

a) Dodavatel zpracuje návrh Akceptačního protokolu a předkládá jej Objednateli. Předání a akceptace Objednatelem bude potvrzena podpisem zástupce Objednatele ve věcech technických na Akceptačním protokolu. 6

b) Objednatel akceptaci Plnění odmítne v případě, že Plnění vykazuje na základě vyhodnocení akceptačních kritérií specifikovaných v Příloze č. 1 Smlouvy natolik vážné vady, že nemůže sloužit svému účelu vůbec nebo s výraznými omezeními. V případě méně vážných vad může Objednatel akceptaci Plnění odmítnout nebo Plnění akceptovat s výhradami. Neodmítnutí převzetí Plnění však nezbavuje Objednatele jeho nároků z odpovědnosti Xxxxxxxxxx za vady. 6

c) V případě, že předání nebo akceptace byla provedena s výhradami Objednatele, je Dodavatel povinen zjednat nápravu do pěti (5) kalendářních dnů, nebude-li dohodou Smluvních stran stanoveno jinak. 7

d) Bylo-li dílčí Plnění předáno a akceptováno, je Xxxxxxxxx oprávněn vystavit daňový doklad na část ceny. Bylo-li předáno nebo akceptováno s výhradou, Dodavateli vznikne právo na zaplacení části ceny a vystavení daňového dokladu až po zjednání nápravy a bezvýhradné akceptaci části Plnění. 7

6 Práva a povinnosti smluvních stran 7

6.1 Plnění musí být poskytnuto bez jakýchkoli vad, ať již faktických či právních, v souladu s veškerými právními předpisy, technickými požadavky a technickými a bezpečnostními normami, které se na Plnění vztahují, a to jak normami závaznými, tak doporučujícími. 7

6.2 V rámci realizace předmětu Smlouvy má každá Smluvní strana zejména následující povinnosti: 7

a) vzájemně spolupracovat a poskytovat druhé Smluvní straně veškeré informace potřebné pro řádné plnění svých povinností vyplývajících ze Smlouvy; 7

b) poskytovat druhé Smluvní straně úplné, pravdivé a včasné informace o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění dle Smlouvy; 7

6.3 Objednatel se zavazuje v termínech stanovených touto Smlouvou, jinak v termínech odpovídajících postupu realizace Plnění, poskytnout Dodavateli potřebnou součinnost v následujícím rozsahu: 7

6.4 Dodavatel se v souvislosti s realizací předmětu této Smlouvy zavazuje zejména: 8

7 Realizační tým 10

7.1 Dodavatel je povinen za účelem poskytování Plnění zajistit dostatečnou kapacitu svých pracovníků s odpovídající kvalifikací a zkušenostmi. 10

7.2 Dodavatel je povinen za účelem poskytování Plnění dle této Smlouvy ustavit členy realizačního týmu pro realizaci této Smlouvy a určit jejich pravomoci (dále jen „Realizační tým“). Seznam členů Realizačního týmu je uveden v Příloze č. 5 Smlouvy. Dodavatel zajistí kontinuitu členů Realizačního týmu v průběhu trvání Smlouvy. Bude-li ze závažných důvodů vzniklých na straně Dodavatele nutné nahradit kteréhokoliv člena Realizačního týmu či rozšířit Realizační tým, bude po předchozím projednání s Objednatelem nahrazen/doplněn novým členem týmu s odpovídající nebo vyšší kvalifikací, a to do pěti (5) pracovních dní od oznámení důvodů pro nahrazení/doplnění Objednateli. 10

7.3 Jednotlivé činnosti prováděné v rámci Plnění nespadající do činností členů Realizačního týmu uvedeného v Příloze č. 5 Smlouvy, mohou být prováděny i jinými osobami, než členy Realizačního týmu. Tím však není dotčena odpovědnost členů Realizačního týmu dle jejich pozic i za takto provedené činnosti. 10

7.4 Dodavatel je povinen předložit Objednateli před zahájením Plnění seznam pracovníků, pro které bude požadovat přístup na pracoviště Objednatele a vzdálený přístup do informačního systému Objednatele, je-li to pro plnění Smlouvy nezbytné. 10

8 Práva duševního vlastnictví 10

8.1 K písemným výstupům Dodavatele poskytnutým v rámci poskytování Plnění a k tzv. unikátním počítačovým programům, tedy počítačovým programům vytvořeným výhradně pro potřeby Objednatele, které mají povahu autorského díla dle Autorského zákona (dále jen „autorské dílo“), je Objednateli Dodavatelem poskytována pro území České republiky nevýhradní licence bez omezení co do množství a způsobu užití, a to po celou dobu trvání majetkových práv autorských k takovému autorskému dílu. Licence dle tohoto odstavce se automaticky vztahuje i na všechny nové verze, aktualizované verze, i na úpravy a překlady autorského díla, dodané Xxxxxxxxxxx. Jako součást licence dle tohoto odstavce uděluje Dodavatel Objednateli i souhlas k provedení jakýchkoliv změn nebo modifikací výsledků uvedených autorských děl, a to i prostřednictvím třetích osob a výslovný souhlas k postoupení licence dle tohoto odstavce a k poskytnutí oprávnění užít tyto výsledky třetím osobám dle uvážení Objednatele, to vše bez nutnosti dalšího souhlasu ze strany Dodavatele. 10

8.2 Bude-li výsledkem Plnění nebo jiné činnosti Dodavatele prováděné dle této Smlouvy počítačový program, který nebyl vytvořen výhradně pro potřeby Objednatele, ale jedná se zejména o tzv. standardní počítačový program Dodavatele nebo třetí strany, který je autorským dílem, nabývá Objednatel licenci dle tohoto odstavce k takovému standardnímu počítačovému programu dnem poskytnutí autorského díla Objednateli k užívání. Součástí licence dle tohoto odstavce je rovněž neomezené právo Objednatele poskytnout třetím osobám podlicenci k užití autorského díla v obvyklém uživatelském rozsahu. Nebude-li možné po Dodavateli spravedlivě požadovat udělení podlicence k takovému standardnímu počítačovému programu, je Dodavatel povinen na to písemně Objednatele upozornit spolu s náležitým odůvodněním a zajistit poskytnutí podlicence nebo licence k takovému standardnímu počítačovému programu Objednatelem určeným osobám. Licence dle tohoto odstavce se automaticky vztahuje i na všechny nové verze, aktualizované verze, i na úpravy a překlady autorského díla, dodané Xxxxxxxxxxx. 10

8.3 Pro účely této Smlouvy se Licencí rozumí licence v rozsahu dle odst. 8.1 Smlouvy a licence v rozsahu dle odst. 8.2 Smlouvy. 11

8.4 Dodavatel je povinen postupovat tak, aby udělení Licence k autorskému dílu zabezpečil, a to bez újmy na právech třetích osob. 11

8.5 Licenci Dodavatel poskytne od předání SW CDA do produkčního prostředí na základě podpisu Akceptačního protokolu dle čl. 5.5 Smlouvy k dílčímu Plnění dle 2.1 písm. b) Smlouvy. Licence k SW CDA je touto Smlouvou poskytována za účelem zajištění archivace dokumentů pracovníky Objednatele při zajištění funkcionalit CDA popsaných v Příloze č. 1, 2 a 4 Smlouvy. Objednatel není povinen poskytnutou Licenci využít. 11

8.6 Pro vyloučení všech pochybností se stanoví výslovně, že odměna a náhrada nákladů za poskytnutí Licence dle tohoto čl. 8 Smlouvy je součástí ceny za Plnění dle čl. 2.2 písm. a) - c) Smlouvy uvedené v čl. 3.1 věta první Smlouvy. 11

9 Práva z vadného plnění, záruka za jakost, záruční servis 11

9.1 Plnění má vady, jestliže nebylo poskytnuto tak, jak bylo sjednáno nebo poruší-li Dodavatel svou povinnost v souvislosti s poskytováním Plnění. Za vady se považují i vady v dokladech a dokumentech dodaných spolu s předmětem Plnění a právní vady. 11

9.2 Dodavatel odpovídá za vady, které má Plnění v okamžiku jeho převzetí Objednatelem, i když se vada stane zjevnou až po této době. Dodavatel odpovídá rovněž za jakoukoliv vadu, jež vznikne po okamžiku převzetí Plnění, jestliže je způsobena porušením povinnosti Dodavatele, a za vadu HW CDA uplatněnou Objednatelem v záruční době dle čl. 9.5 Xxxxxxx (dále jen „Záruka za jakost“). 11

9.3 Objednatel je oprávněn požadovat odstranění vad předmětu Plnění, a to odstraněním závady, bezplatným dodáním nového předmětu Plnění bez vad, případně doplněním chybějící části předmětu Plnění nebo je oprávněn žádat slevu z ceny předmětu Plnění nebo od Smlouvy odstoupit a žádat vzájemné vrácení plnění, přičemž právo volby má výhradně Objednatel. 11

9.4 Dodavatel dále prohlašuje, že je oprávněn Plnění v rozsahu sjednaném v této Smlouvě Objednateli dodat, že uzavřením a plněním této Smlouvy neporušuje žádná práva duševního vlastnictví, ani jiná práva třetích osob. Dodavatel odpovídá za to, že Objednatel užíváním SW CDA v rozsahu poskytnuté Licence neporušuje žádná práva třetích osob. Dodavatel je povinen umožnit Objednateli nerušené užívání SW CDA v rozsahu udělené Licence a chránit jej, ať sám nebo prostřednictvím výrobce SW CDA, před nároky třetích osob vznesenými vůči Objednateli v souvislosti s užíváním SW CDA. 11

9.5 Dodavatel dále poskytuje záruku, že HW CDA dodaný Objednateli v rámci plnění této Smlouvy má ke dni podpisu Předávacího protokolu funkční vlastnosti uvedené v Příloze č. 1 a 3 Smlouvy. Dodavatel poskytuje na HW CDA Záruku na jakost po dobu dvaceti čtyř (24) měsíců, není-li ve Smlouvě stanovena u části HW CDA doba delší, přičemž záruční doba začne plynout ode dne potvrzení Předávacího protokolu k HW CDA. 12

9.6 V případě záručních vad dle čl. 9.5 Smlouvy je Objednatel povinen vady písemně oznámit Dodavateli prostřednictvím e-mailu odpovědnými osobami Objednatele na adresu odpovědných osob Dodavatele do patnácti (15) dnů ode dne jejich zjištění. Dodavatel prošetří oznámenou vadu z toho pohledu, zda se na ni vztahuje Záruka za jakost dle této Smlouvy. Objednatel mu přitom poskytne potřebnou součinnost, a to zejména pro odhalení příčiny vady. Požadavky na záruční servis jsou blíže specifikovány v odst. 11.2 Přílohy č. 1 Smlouvy. 12

10 Bezpečnost ICT systémů 12

10.1 Objednatel v souladu s vyhláškou č. 82/2018 Sb., o 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), stanovuje touto Smlouvou pravidla řízení bezpečnosti informací. 12

10.2 Dodavatel je povinen zúčastnit se bezpečnostního školení organizovaného Objednatelem a  dodržovat při výkonu své činnosti všechny bezpečnostní požadavky stanovené pro přístup pracovníků externích subjektů  do informačního systému Objednatele. 12

10.3 Objednatel je oprávněn kdykoli prověřovat dodržování bezpečnostních požadavků stanovených Smlouvou. V průběhu auditu má Objednatel přístup k interním předpisům a systémům vztahujícím se k bezpečnosti ICT systémů podle této Smlouvy. Objednatel se zavazuje, že k informacím, které získá od Dodavatele za účelem ověření, zda je Dodavatelem řádně zajištěna bezpečnost ICT systémů, zachová mlčenlivost. 12

10.4 Na případná negativní zjištění, vyplývající z auditu, týkající se dodržování bezpečnostních požadavků Dodavatelem, Objednatel Dodavatele bezodkladně upozorní. Dodavatel je povinen zjednat nápravu, a to ve lhůtě 30 kalendářních dnů od upozornění Objednatele. V případě, že Xxxxxxxxx neprovede nápravu ve lhůtě dle předchozí věty, je Objednatel oprávněn od Smlouvy odstoupit. 12

10.5 Dodavatel je povinen hlásit vzniklé bezpečnostní incidenty, případně i podezření na ně Objednateli. 12

10.6 Dodavatel je povinen nastavit transparentní proces řízení změn a Objednatele prokazatelně informovat způsobu řízení rizik na straně Dodavatele a o jeho významných změnách, zejména změnách fyzického umístění servisních / dohledových / vývojových zařízení, zavedení nových servisních / dohledových / vývojových nástrojů, zavedení nových technologií a aktualizaci stávajících provozních postupů a bezpečnostních politik. Dodavatel Objednatele informuje dále o zbytkových rizicích souvisejících s plněním Smlouvy. 12

11 Nemožnost plnění 13

11.1 Jestliže vznikne na straně Dodavatele nemožnost plnění dle § 2006 a § 2007 Občanského zákoníku, Dodavatel písemně uvědomí bez zbytečného odkladu, nejpozději však do pěti (5) kalendářních dnů od jejího vzniku, o této skutečnosti a její příčině Objednatele. Pokud není jinak stanoveno písemně Objednatelem, bude Dodavatel pokračovat v realizaci svých povinností vyplývajících ze smluvního vztahu v rozsahu svých nejlepších možností a schopností a bude hledat alternativní prostředky pro realizaci té části plnění, kde není možné plnit. Pokud by podmínky nemožnosti plnění trvaly déle než devadesát (90) kalendářních dní, je Objednatel oprávněn od Smlouvy odstoupit. 13

11.2 Ustanovení tohoto odstavce Xxxxxxx nezbavuje žádnou ze Smluvních stran její povinnosti k úhradě plateb v té době již splatných. 13

12 Odpovědní pracovníci 13

12.1 Odpovědnými pracovníky Objednatele a Dodavatele ve věcech obchodních pro účely této Smlouvy jsou: 13

a) Za Objednatele: 13

b) Za Dodavatele: 13

12.2 Odpovědnými pracovníky Objednatele a Dodavatele ve věcech technických pro účely této Smlouvy jsou: 13

a) Za Objednatele: 13

b) Za Dodavatele: 13

c) Helpdesk Dodavatele: xxx, xxx 13

12.3 Pouze odpovědní pracovníci Objednatele a Dodavatele jsou oprávněni vznášet vůči druhé Smluvní straně požadavky související s plněním této Smlouvy. Smluvní strany se zavazují v průběhu plnění Smlouvy nezměnit odpovědné pracovníky bez závažných důvodů. V případě změny odpovědného pracovníka je Smluvní strana povinna neprodleně o této skutečnosti písemně informovat druhou Smluvní stranu. 14

13 Smluvní pokuty, odpovědnost za újmu 14

13.1 V případě prodlení Objednatele s dodržením kterékoli lhůty stanovené v Harmonogramu je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 2 000,- Kč (slovy: dva tisíce korun českých) za každý započatý den prodlení. 14

13.2 V případě prodlení Objednatele s dodržením kterékoli lhůty stanovené pro poskytování Podpory dle Přílohy č. 1 Smlouvy je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 1 000,- Kč (slovy: jeden tisíc korun českých) za každou započatou hodinu prodlení a každou vadu. 14

13.3 V případě nedostupnosti Helpdesk Podpory je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 10 000,- Kč (slovy: deset tisíc korun českých) za každý jednotlivý případ. 14

13.4 V případě prodlení s poskytováním záručního servisu ve lhůtách dle odst. 11.2 Přílohy č. 1 Smlouvy je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 5 000,- Kč (slovy: pět tisíc korun českých), a to za každou započatou hodinu prodlení a každou vadu. 14

13.5 V případě ztráty či poškození, pozměnění či zneužití dat Objednatele ze strany Dodavatele je Objednatel oprávněn požadovat a Dodavatel povinen zaplatit smluvní pokutu ve výši 500 000,- Kč (slovy: pět set tisíc korun českých) za každý jednotlivý případ. 14

13.6 V případě prokazatelného prodlení povinné Smluvní strany s poskytnutím součinnosti není druhá Smluvní strana v prodlení s plněním svých závazků závislých na poskytnutí součinnosti povinné Smluvní strany a veškeré lhůty se o prokazatelné prodlení povinné Smluvní strany prodlužují, nedohodnou-li se Smluvní strany jinak. 14

13.7 V případě porušení kterékoli z povinností Dodavatele dle čl. 10 Smlouvy Bezpečnost ICT systémů Smlouvy je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 100 000,- Kč (slovy: sto tisíc korun českých) za každý případ porušení. 14

13.8 V případě nesplnění povinnosti Dodavatele doložit sjednání pojištění a úhrady pojistného ve lhůtě dle čl. 6.4. písm. o) Smlouvy je Objednatel oprávněn požadovat od Dodavatele zaplacení smluvní pokuty ve výši 10 000 Kč (slovy: deset tisíc korun českých) za každý případ porušení. 14

13.9 Za každé jednotlivé porušení povinnosti, týkající se ochrany Obchodního tajemství a Důvěrných informací dle čl. 10.1 VOP je povinná Smluvní strana povinna uhradit porušením dotčené Smluvní straně smluvní pokutu ve výši 250 000,- Kč (slovy: dvě stě padesát tisíc korun českých). 14

13.10 Za každé jednotlivé porušení čl. 8 těla Xxxxxxx Práva duševního vlastnictví ze strany Dodavatele, je Xxxxxxxxx povinen uhradit Objednateli smluvní pokutu ve výši 250 000,- Kč (slovy: dvě stě padesát tisíc korun českých). 15

13.11 V případě, že se kterékoli prohlášení Dodavatele dle čl. 9.1 VOP ukáže, byť jen z části, jako nepravdivé, je Dodavatel povinen uhradit Objednateli smluvní pokutu ve výši 0,5 % z ceny za Plnění dle čl. 2.2 písm. a) - c) Smlouvy uvedené v čl. 3.1 věta první Smlouvy. 15

13.12 Vyúčtování smluvní pokuty musí být druhé Smluvní straně zasláno doporučeně s dodejkou, smluvní pokuta je splatná v době 30 (slovy: třiceti) kalendářních dnů ode dne doručení vyúčtování. 15

13.13 Uplatněním jakékoliv smluvní pokuty není nijak dotčeno právo Objednatele na náhradu skutečně způsobené majetkové i nemajetkové újmy v rozsahu přesahujícím zaplacenou smluvní pokutu. 15

13.14 V případě, že dojde k porušení povinnosti Dodavatele, jež zakládá nárok Objednatele na odstoupení od Smlouvy, je Objednatel oprávněn bez ohledu na skutečnost, zda využije svého práva na odstoupení od Xxxxxxx, účtovat Dodavateli smluvní pokutu ve výši 100 000,- Kč (slovy: sto tisíc korun českých) za každý případ porušení takové povinnosti. Tím není dotčeno právo na vymáhání způsobené újmy. 15

13.15 Pro vyloučení pochybností se stanoví, že čl. 11.1 VOP se neuplatní. 15

14 Doba trvání Smlouvy 15

14.1 Tato Xxxxxxx nabývá platnosti dnem jejího podpisu Smluvními stranami a účinnosti dnem uveřejnění v registru smluv podle zákona o registru smluv. Plnění předmětu této Smlouvy v době od platnosti Xxxxxxx do její účinnosti se považuje za plnění podle této Smlouvy a práva a povinnosti z něj vzniklé se řídí touto Smlouvou. 15

14.2 Tato Xxxxxxx se uzavírá na dobu určitou, a to na dobu 48 měsíců ode dne potvrzení Akceptačního protokolu k implementaci SW CDA a jeho integraci do systému Objednatele dle čl. 2.1 písm. b) Smlouvy Objednatelem. 15

14.3 Účinnost této Smlouvy lze ukončit předčasně před sjednanou dobou trvání výhradně ze zákonných důvodů, písemnou dohodou Smluvních stran, výpovědí nebo odstoupením z důvodů uvedených v zákoně nebo v této Smlouvě. 15

14.4 V případě zániku smluvního závazkového vztahu založeného Smlouvou je Dodavatel povinen poskytnout Objednateli nebo Objednatelem určené třetí osobě nezbytnou součinnost za účelem zajištění řádného exportu dat Objednatele do jiného úložiště dat tak, aby Objednateli nevznikla újma, přičemž Dodavatel se zavazuje tuto součinnost poskytovat s odbornou péčí, zodpovědně, a to do doby zániku smluvního závazkového vztahu založeného Smlouvou. Dodavatel je povinen v rámci součinnosti dle předchozí věty poskytnout Objednateli nebo jím určeným třetím osobám informace potřebné k převedení činností dle této Smlouvy novému Dodavateli Služeb či  novému Dodavateli služeb podobných Službám či s nimi jinak spojených. Úhrada nákladů spojených s poskytnutím součinnosti dle tohoto odstavce je zahrnuta v ceně dle čl. 3.1 věta první Smlouvy. 15

14.5 Po ukončení Smlouvy zůstává zachována platnost a účinnost ustanovení Smlouvy, týkající se odpovědnosti za vady, záruky za jakost, licenčních ujednání, ochrany Důvěrných informací, ochrany Osobních údajů, smluvních pokut, náhrady újmy a jiných ze své povahy přetrvávajících nároků či závazků. 16

15 Závěrečná ustanovení 16

15.1 Tato Smlouva a vztahy z ní vyplývající se řídí právním řádem České republiky, zejména příslušnými ustanoveními Občanského zákoníku a Zákona o zadávání veřejných zakázek. 16

15.2 Smluvní strany si ve smyslu ust. § 1765 odst. 2 Občanského zákoníku ujednaly, že Dodavatel na sebe přebírá nebezpečí změny okolností. 16

15.3 Smluvní strany se dohodly, že ustanovení § 1799 a 1800 Občanského zákoníku se nepoužijí. 16

15.4 V případě rozporu mezi Smlouvou a přílohami Smlouvy mají přednost ustanovení Smlouvy, resp. jejích dodatků. V případě rozporu mezi ustanoveními jednotlivých příloh, mají přednost přílohy v pořadí, které odpovídá jejich očíslování dle čl. 15.12 Smlouvy. 16

15.5 Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů, vzniklých na základě této Smlouvy nebo v souvislosti s touto Smlouvou, a k jejich vyřešení zejména prostřednictvím jednání odpovědných pracovníků nebo jiných pověřených subjektů. 16

15.6 Změna kontaktních osob a spojení uvedených v čl. 12 Smlouvy a změna členů Realizačního týmu dle Přílohy č. 5 Smlouvy nevyžaduje změnu Xxxxxxx formou uzavření dodatku ke Smlouvě a je účinná v okamžiku doručení oznámení o této změně druhé Smluvní straně, aniž by bylo nutno vyhotovovat dodatek k této Smlouvě. 16

15.7 Tato Smlouva je uzavírána v elektronické podobě, přičemž elektronické kopie souboru s podpisy obou Smluvních stran se považují za rovnocenné originály. Každá ze Smluvních stran obdrží 1 kopii elektronického souboru se Smlouvou s podpisem obou Smluvních stran s platností originálu. 16

15.8 Smluvní strany tímto prohlašují, že neexistuje žádné ústní ujednání, smlouva či řízení některé Smluvní strany, které by nepříznivě ovlivnilo výkon jakýchkoliv práv a povinností dle této Smlouvy. Zároveň potvrzují svým podpisem, že veškerá ujištění a dokumenty dle této Smlouvy jsou pravdivé, platné a právně vymahatelné. 16

15.9 Pro případ, že tato Smlouva není uzavírána za přítomnosti obou Smluvních stran, platí, že Smlouva nebude uzavřena, pokud ji Dodavatel podepíše s jakoukoliv změnou či odchylkou, byť nepodstatnou, nebo dodatkem, ledaže Objednatel takovou změnu či odchylku nebo dodatek následně schválí. 16

15.10 Smluvní strany potvrzují, že se s textem VOP seznámily před podpisem této Smlouvy a je jim znám jejich význam v souladu a ve spojitosti se Smlouvou. Dále Smluvní strany potvrzují, že veškerým ustanovením Smlouvy a VOP plně a bez jakýchkoli obtíží porozuměly a nepovažují je za nevýhodná. VOP představují závaznou a nedílnou součást Smlouvy. 16

15.11 Nedílnou součástí této Smlouvy jsou následující Přílohy: 17

Příloha č. 1 Smlouvy: Specifikace požadovaného Plnění 18

3.1.1 Hardware 19

3.1.2 Software, služby 19

3.1.3 Všeobecné požadavky 19

4.1 Požadavky na CDA 22

4.2 Základní funkční požadavky 22

4.3 Další funkční požadavky 22

4.4 Základní specifické požadavky 23

4.5 Další specifické požadavky 23

5.1 Brána 24

5.2 Vstup dokumentů 25

5.4 Badatelna 29

5.5 Obecné požadavky 30

5.6 Statistika 31

6.1 Digitální kontinuita a důvěryhodnost dokumentu 32

6.2 Validace dokumentu 32

6.3 Balíčkování 32

6.4 Evidence 33

8.1 Integrace 34

8.2 Migrace současného prostředí 34

8.3 Předpokládané objemy dat 35

9.1 Obecné požadavky 35

9.2 Provozní bezpečnost 35

9.3 Technická opatření 36

9.4 Bezpečnost archivovaných dokumentů 36

9.5 Bezpečnost databází 36

9.6 Kontrola změn a integrity prostředí 37

9.7 Síťová bezpečnost 37

10.1 Hardware 38

10.2 Digitalizační pracoviště 39

10.3 Pracovní stanice uživatelů 39

11.1 Dostupnost systému CDA 39

11.2 Záruční servis 39

11.3 Technická podpora hardwarových a softwarových komponent – maintenance CDA 40

Příloha č. 2 Smlouvy: Požadavky Objednatele na SW CDA 43

1. Legislativní a normativní požadavky 43

2. Požadavky na proces archivace 44

3. Požadavky na uživatelské funkce 46

4. Specifické požadavky 48

5. Požadavky na architekturu systému 49

6. Požadavky na dostupnost systému 51

7. Požadavky na úložiště archivních dat 52

8. Bezpečnost archivovaných dokumentů 54

9. Bezpečnost prostředí archivu 56

10. Bezpečnost databází 58

Příloha č. 3 Smlouvy: Technická specifikace HW CDA 62

Příloha č. 4 Smlouvy: Popis řešení CDA Dodavatele 68

1. Úvod 80

2. Popis SW řešení 81

2.1 Legislativní a normativní požadavky 82

2.2 Architektura navrženého řešení 84

2.2.1 Brána 87

2.2.2 Archiv 89

2.2.3 Badatelna 93

2.2.3.1 Administrační část 94

2.2.3.2 Badatelská část 96

2.3 Migrace 97

2.3.1 Export 98

2.3.2 Zpracování dat 98

2.4 Příprava produkčního provozu 99

2.4.1 Balíčkování 99

2.4.2 Import 99

2.5 Bezpečnost prostředí archivu, bezpečnost dokumentů 100

2.5.1 Vlastnosti karantény 100

2.5.2 Detailní popis 101

2.6 Bezpečnost dat a informací 102

2.6.1 Modul ochrany databází 103

2.6.2 Modul ochrany souborů, integrita 104

2.6.3 Modul vyhledávání zranitelností 105

2.6.4 GDPR a compliance 106

3. Součinnost 108

4. Licenční podmínky licence Bezpečný digitální archiv 109

4.1 Licenční model a rozsah licence Bezpečný digitální archiv 109

4.1.1 Licenční model 109

4.1.2 Doplňující licenční podmínky 111

4.2 Mezinárodní smlouva IBM Passport Advantage 112

5. Popis HW řešení 113

5.1 Popis SW řešení – doplnění 113

5.1.1 Dostupnost systému 113

5.1.2 Bezpečnost databází 114

5.1.3 Úložiště archivních dat 114

5.2 Technická specifikace HW CDA 116

6. HelpDesk GC System 125

Příloha č. 5 Smlouvy: Realizační tým 128

1.Úvod

Tento dokument popisuje řešení nabízené dodavatelem GC System a.s. a jeho poddodavateli IBM Česká republika, spol. s x.x. x Xxxxxx, s.r.o.. Tento dokument je současně vypracován v souladu s požadavky zadavatele Česká pošta, a.s. obsaženými v Příloze č. 1 Smlouvy ( Přílohy č.4 Zadávací dokumentace „Vzor smlouvy“) - „Specifikace požadovaného Plnění“  .

2.Popis SW řešení

Návrh řešení naplňuje požadavky Zadavatele na dodání řešení, které na rozdíl od stávajícího, není jednoznačně závislé na jedné technologické platformě, a je dostatečně otevřené pro jiné technologie a jiná řešení. Řešení je dostatečně customizovatelné a provozovatelné bez závislosti na dodavateli. Řešení umožňuje rozšíření směrem k novým technologiím, jako jsou např. CLOUD, nebo Data on Demand.

Součástí navrhovaného řešení je:

• Softwarové řešení CDA zahrnující poskytnutí Tyto licence budou dodány zákazníkovi prostřednictvím dohodnutého obchodního kanálu.

• Veškerý hardware bude dodán společností GCSystem nebo některým z jeho partnerů, jak je požadováno Zadavatelem. Zároveň tak bude splněn požadavek zadavatele, že archivní data, včetně dat brány, jsou replikována do záložní lokality a jednotlivé komponenty jsou od sebe odděleny fyzicky i logicky. Další kvalitativní požadavky na celkový návrh řešení jsou navrženým řešením splněny.

• dodávku plně funkčního softwarového řešení CDA, customizaci, implementaci, integraci, testování, seznámení administrátorů a uživatelů s prostředím CDA, dodání dokumentace a uživatelských příruček, poskytnutí zdrojových kódů doprogramovaných částí softwaru CDA, importních skriptů pro prvotní migraci a exportních skriptů pro případný export dat ze softwaru CDA do následného systému, projektové vedení a udělení práva software CAD užít, tj. licenci v rozsahu dále uvedeném ve Smlouvě (dále jen „SW CDA“);

• Nasazení a zprovoznění bezpečnostních technologií, které zajistí splnění požadovaných vlastností systému.

• Migrace dat do záložní lokality, tak aby požadované parametry RTO a RPO byly splněny.

• Služby - migrace obsahu ze stávajícího systému EMC CENTERA na navržené řešení;

• Služby technické podpory hardwarových a softwarových komponent – maintenance CDA (metodická podpora archivace, aktualizace dokumentace a uživatelských příruček k CDA, seznámení administrátorů a uživatelů s prostředím CDA, zajištění legislativního souladu po celou dobu účinnosti Smlouvy, aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA, technická podpora hardwarových a softwarových komponent). Především pak níže:

• technickou podporu hardwarových a softwarových komponent – maintenance CDA po dobu 48 měsíců, zahrnující

• metodickou podporu archivace (aktualizace dokumentace a uživatelských příruček k CDA, seznámení administrátorů a uživatelů s prostředím CDA),

• zajištění legislativního souladu CDA po celou dobu účinnosti Xxxxxxx,

• technickou podporu hardwarových a softwarových komponent CDA,

• aktualizace SW CDA nebo zajištění software maintenance od výrobce SW CDA,

• technickou podporu poskytujeme na plnění, která dodáváme, a to v rozsahu požadavků ZD, konkrétně:

• reakční doba do 2 hodin od nahlášení vady v pracovní době,

• 5x8 (pracovní dny 8:00 – 16:00) pro dobu odezvy,

• zahájení zásahu nejpozději Next Business Day (následující pracovní den).

2.1Legislativní a normativní požadavky

Archiv je navržen, aby splňoval požadavky na dlouhodobé ukládání a archivaci informací dle referenčního modelu OAIS (Open archival information system), který popisuje ČSN ISO 14721. Pro uchování dlouhodobé důvěryhodnosti archiválií je použito elektronického podpisu a časového razítka v souladu s ETSI standardy rozšířeného elektronického podpisu AdES.

Řešení splňuje požadavky Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 (Nařízení eIDAS) o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu.

Elektronické podpisy, časová razítka a kvalifikované certifikáty odpovídají normě ETSI a to v oblastech:

• Ověření platnosti elektronických podpisů a jejich kontrola u archiválií, včetně neporušení kontrolního součtu a platnost certifikátu.

• Připojuje technický metadata k archiválii. CRL (seznam zneplatněných certifikátů), OCSP odpovědi, případně další.

• Připojení časového razítka. Kontrolní součet tak chrání nejen samotnou archiválii, ale i její metadata.

• Zajišťuje pravidelné připojení dalších časových razítek před vypršením platnosti předchozího.

2.2Architektura navrženého řešení

Architektura:

Hlavní funkční celky jsou:

• Brána

• Archiv

• Badatelna

Pokud je textu zmíněn archiv s malým „a“, pak má uchazeč na mysli archiv obecně, je-li zmíněn s velkým „A“, pak se jedná o konkrétní funkční celek CDA.

Funkční celky jsou od sebe odděleny firewallem a komunikace probíhá pomocí jasně definovaných kanálech (WS/SOAP, REST). Na základě definovaných pravidel.

Systém je provozován v primární a záložní lokalitě, testovací instance je pouze v primární lokalitě. Počty uživatelů jsou omezeny dle příslušných upřesnění Zadavatele (viz xxxx 00, 00 Xxxxxxx x.0) Tyto požadavky Zadavatele jsou jednoznačně splněny v rámci licenčního ujednání.

FileNet

Základními komponenty pro Bránu a Archiv jsou FileNet Content Engine a FileNet BPM Engine.

FileNet Content Engine umožňuje ukládání obsahu dokumentů, jejich metadat a řízení přístupu. Lze vytvářet strukturu složek a vazeb mezi jednotlivými dokumentů. Na Bráně zde budou uložené dokumenty a balíčky čekající na import do Archivu, úložiště pro badatelnu. V Archivu ukládá Archiválie, dokumenty balíčků, razítek a certifikátů. Content engine má široké možnosti vyhledávání pomocí webového klienta. Je možné vytvářet i uložené hledání a to jak v rámci aplikace, tak si uživatel může vytvořit vlastní. Vyhledávání najde pouze obsah, ke kterému má daný uživatel dostatečná oprávnění. Vyhledávat lze fulltextově nebo podle metadat. Je možné nastavit formát zobrazení výsledku. Vyhledané dokumenty lze prohlížet případně exportovat.

Klient Content Enginu je webová aplikace, ze které bude vycházet uživatelské rozhraní. Součástí klienta je prohlížeč Daeja ViewONE. V prohlížeči je možné zobrazit, zvětšit, stránkovat, otáčet a tisknout zobrazený dokument. Umožňuje vytváření grafických anotací dokumentů. Prohlížené dokumenty se zobrazí přímo v prohlížeči, není nutné je stahovat a ukládat na pracovní stanici uživatele.

FileNet BPM Engine obsahuje nástroje pro automatické a manuální spouštění a řízení procesů. Procesy jsou řízeny pomocí Workflow. Předdefinované procesy budou v rámci Brány řídit vstup dokumentů a balíčků, spouštění a orchestraci služeb. V Archivu budou přednastavené procesy řídit přerazítkování, generování kopií pro badatelnu a skartační procesy. FileNet BPM Engine obsahuje pro vytváření uživatelských workflow a jejich spouštění.

Řízení přístupu

Pro řízení přístupových práv k archiváliím využívá systém možnosti platformy FileNet. Uživatelé jsou autorizováni vůči LDAP nebo Active Directory, kde jsou vynucovány heslové a další politiky pro zajištění autentizace a autorizace. Práva lze definovat i pro skupiny (Administrátoři, Analytici, Operátoři, Auditoři a případně i další), do kterých lze zařadit uživatele nebo servery a jejich služby. Přístup lze přidělit i speciálním rolím jako autor dokumentu nebo autorizovaný uživatel.

U strukturovaných dat lze nastavit dědičnost sad oprávnění. To funguje pro složky i pro složené dokumenty. Lze určit i hloubku zanoření, pokud bude dědičnost práv platit.

FileNet nabízí řízení přístupu pomocí Markings. Nastavuje přístupová práva na základě hodnot metadat dokumentu. Toho lze dobře využít pro skartační prcesy (Records Management).

Další úroveň řízení přístupu lze aplikovat na přístup k vybraným metadatům dokumentu.

Audit

Auditní log lze nastavit detailně na jednotlivé třídy, dokonce na vlastnosti. Popřípadě může být nastaveno mazání starých záznamů s ohledem na šetrné využití zdrojů.

Služby a workflow mají své vlastní auditní logy, které mohou sledovat jednotlivé operace.

Auditní logy umožňují napojení na systém dohledu, na SIEM od společnosti IBM, který je také součástí nabídky. Vybrané auditní logy lze poslat i pomocí: emailu, http, rsyslog, snmp. Integraci s existujícími systémy pro monitorování zabezpečení je možné využít formáty rsyslog: CEF, LEEF, JSON, XML.

V případě výpadku jakékoliv bezpečnostní komponenty v systému není narušena dostupnost služeb.

Technické požadavky

Webové aplikace jsou optimalizované pro aktuální verze webových prohlížečů: Chrome, Edge , Opera, Firefox i Internet Explorer (i když Zadavatel IE z požadavků odstranil, zároveň se zpětnou kompatibilitou nejméně o jednu verzi oproti aktuální v době nasazení systému). Lze očekávat, že v dohledné budoucnosti nebude výrobcem podporován Internet Explorer a původní verze Edge. Lze použít všechny prohlížeče, které splňují bezpečnostní kritéria v předepsané konfiguraci, zejména bez schválených pluginů. Výkon některých částí aplikací se může pro různé prohlížeče lišit.

Veškerá komunikace mezi těmito částmi řešení je pomocí standardních komunikačních rozhraní (např. WS-SOAP, LDAP a CMIS). Obdobně budou pro komunikaci s externímy systémy, ze kterých budou data (el. dokumenty) do CDA zasílána, implementována standardní rozhraní WS-SOAP a WS-REST.

Navržené řešení disponuje nástroji pro tvorbu, údržbu a správu workflow, umožňující zasílat e-mailové notifikace pro nastavené situace (např. příjem nevalidního dokumentu) a obsahující workflow systém a nástroje pro definování, spouštění, reporting a správu workflow, umožňující ad-hoc definování úloh koncovým uživatelem v průběhu zpracování konkrétní instance workflow, podporující přidělování úkolů na konkrétního uživatele nebo na celou roli v rámci řešení konkrétních úkolů. Součástí řešení je administrační prostředí pro návrh a správu workflow realizované formou webové aplikace.

Všechny části řešení (Brána, Archiv, Badatelský portál, GUI atd.) podporují práci s požadovanými formáty PDF, PDF/A; MS Office – DOC, DOCX, PPT, PPTX, XLS, XLSX, RTF; JPG, GIF,TIF/TIFF, PNG, XML.

Systém je možné provozovat jak na fyzickém hardware, tak i s využitím virtualizačního prostředí. Dle požadavků Zadavatele bude nasazeno v primární a sekundární lokalitě, dle technických požadavků Zadavatele. Jeho požadovaná dostupnost je dodavatelem zajištěna navrhovaným řešením.

I ntegrace:

2.2.1Brána

Brána zajišťuje vstup dokumentů za pomoci integračních služeb a uživatelské rozhraní pro ruční vkládání dokumentů a Archivní služby.

Integrační služby

• FileNet Content engine pro ukládání obsahu.

• FileNet BPM engine, který řídí a orchestruje ostatní služby a požadavky. Například proces poskytnutí informací z archivu a další.

• Základem je služba pro vstup SIP balíčků dle standardu METS, případně dokumentů ve formátu PDF/PAdES. Po přijetí příchozího dokumentu se uloží do dočasného úložiště. Předáním na další služby je provedena 4 stupňová validace, součástí, které je i karanténa na škodlivý kód a malware.

• Služba pro vstup samostatných dokumentů a popis metadat, vytvoří SIP balíček a ten předá do archivu. Používá samostatná rozhraní Ethernet pro správu a pro účely skenování souborů.

• Ruční vložení přes webové rozhraní využije služby pro vytvoření SIP balíčku.

• Rozhraní pro pracovníky archivu, kteří rozhodují o přijetí dokumentů do archivu, které neprošly kontrolou. Autentizace a autorizace je napojena na LDAP server Archivu.

• Scanner filesystému bude sledovat složku na filesystému, odkud převezme SIP balíček, nebo samostatný obsah a metadata.

• Služba pro základní kontrolu integrity dokumentu a metadat. Dokument, který nevyhoví v rámci kontrol definovaným kritériím je zařazen do seznamu problematických dokumentů. Další postup je na rozhodnutí archiváře.

• Služba pro předání obsahu do karantény. Zajistí rozbalení obsahu SIP balíčku a předání do karantény, kde jsou všechny příchozí dokumenty podrobeny důkladné vícestupňové analýze. Asynchronně vyhodnotí výsledek kontroly v karanténě.

• Služba pro komunikaci s badatelnou:

• Nabízí badatelně seznam dokumentů s vybranými metadaty

• Přijímá požadavky z badatelny na dokumenty

• Služba předá badatelně kopii požadovaného dokumentu s metadaty

• Zajistí i zpětný zápis logu o aktivitách s dokumentem v badatelně

• Slouží jako dočasné úložiště pro kopie dokumentů pro badatelnu. Tyto dokumenty jsou označeny identifikátorem žadatele-badatele a také datem do kdy jsou dokumenty k dispozici na zpřístupnění. Po tomto datu jsou dokumenty automaticky odstraněny z dočasného úložiště, a pro opětovné zpřístupnění je nutné podat novou žádost.

Řízení stavu a předávání informací jednotlivým službám řídí workflow na BPM Enginy platformy FileNet.

Pro minimalizaci ztráty dat v případě nepředvídaných událostí je nutné, aby zdrojové systémy, které odesílají data do archivu, tato data držely ještě 24 hodin po odeslání do archivu.

Kontroly v rámci Karantény:

• Vhodnost datového formátu – Do Archivu jsou přijímány pouze soubory definovaných datových typů. Z pohledu dlouhodobého uchování jsou některé formáty vhodnější než jiné;

• Úplnost popisných metadat – Vstupující dokument musí být popsán množinou definovaných metadat. Tato metadata se dle modelu OAIS archivují spolu s dokumentem;

• Platnost prvků elektronického zabezpečení dokumentů – U souborů vybraných datových typů, které podporují elektronické bezpečnostní prvky (elektronický podpis/pečeť, elektronické časové razítko), jsou tyto prvky validovány. Typicky se jedná o formáty PDF;

• Integrita dokumentů – Stejně jako platnost elektronického podpisu/značky je kontrolována i integrita samotného dokumentu, zda od podpisu dokumentu nedošlo k jeho modifikaci;

• Přítomnost škodlivého kódu – Dokument je testován na přítomnost škodlivého kódu, který by mohl ohrozit bezpečnost Archivu, ale především ohrozit koncové příjemce dokumentu.

2.2.2Archiv

Část Archiv je koncipována jako autonomní a na ostatních částech nezávislá část. Je to z důvodu, aby nebyla ohrožena důvěryhodnost a platnost archivovaných dokumentů v případě, kdy dojde k napadení nebo poškození zbývajících částí řešení. Součástí Archivu je fyzické úložiště dokumentů, které je řízeno a integrováno pouze s logickou vrstvou Archivu, která spravuje metadata dokumentů ukládané do vlastní databáze a binární obsahy dokumentů ukládané do fyzického úložiště.

Samotný Archiv dokumentů vyžaduje pro svou plnou funkčnost přístup k akreditované TSA, která je integrována pomocí komponenty Archivní služby a slouží k ověřování a vytváření kvalifikovaných časových razítek.

Archiv má svůj samostatný LDAP server vyhrazený pouze pro Archiváře a Administrátory Archivu. Uživatelé jsou spravováni odděleně, včetně skupin a rolí. LDAP poskytuje autorizaci a autentizaci pro archiváře pro schvalování dokumentů, u kterých neproběhla validace atributů nebo kontrola v karanténě.

Archiv je založen na samostatné instanci FileNet Content engine, který zajišťuje ukládání archiválií, spravuje přístupová práva.

Zajišťuje klíčovou funkci řešení - udržuje dlouhodobou platnost důvěryhodných elektronických prvků a garantované dlouhodobé uložení dat. Řešení je schopno důvěryhodně ukládat elektronické archiválie po neomezenou dobu (z pohledu aktuálních technologií, legislativy). Zajišťuje tedy trvalé, neměnné a důvěryhodné uložení archivovaných elektronických archiválií. Dlouhodobá platnost elektronických archiválií je udržována pomocí přerazítkování archivních balíčků. Řešení umožňuje řízení procesu tvorby balíčků dle různých archivačních politik a umožňuje nastavit archivační politiky s ohledem na optimalizaci procesu razítkování.

FileNet BPM engine má na starosti přerazítkování pro dlouhodobé důvěryhodné ověřování archiválií a životní cykly (skartaci nebo trvalou archivaci). Dlouhodobá platnost elektronických archiválií je udržována pomocí přerazítkování archivních balíčků. Řídí proces tvorby balíčků dle různých archivačních politik a umožňuje nastavit archivační politiky s ohledem na optimalizaci procesu razítkování. Této funkce je dosaženo pravidelným automatickým vytvářením archivních balíčků z nových dokumentů a z dokumentů, jimž se blíží termín pro přerazítkování. Elektronické archiválie je možné balíčkovat nezávisle na jejich typu, významu, různých přístupových právech a bez jejich vzájemného vztahu. Řešení tedy umožňuje tvorbu archivních balíčků zajišťujících dlouhodobou platnost celé sady elektronických archiválií.

Dále FileNet BPM engine vyřizuje požadavky z badatelny, vytváří kopie pro badatele. Předává kopie na bránu, kde probíhá anonymizace kopií pro badatele. Řídí procesy spojené s vyřazováním archiválií z archivu. V případě, že archiválie prošla procesem vyřazení a byla určena k odstranění, systém umožní mazání jednotlivých archiválií z balíčku bez narušení možnosti prokázat důvěryhodnost ostatních archiválií z balíčku. Je také vedena evidence, v rámci které jsou vedeny informace o dokumentech, u nichž došlo k vyřazení z archivu.

Uložené elektronické archiválie jsou periodicky kontrolovány na platnosti certifikátů časových razítek a provádí se automatická obnova časových razítek. Doporučená doba pro přerazítkování je 2 až 4 týdny před uplynutím termínu, z důvodu zajištění platnosti dokumentu i pro případ, že dojde k výpadku služby TSA nebo jiných neočekávaných událostí. Řešení ověřuje při kontrole platnosti elektronických podpisů a časových razítek platnost kvalifikovaných certifikátů vydaných kvalifikovanými poskytovateli služeb vytvářejících důvěru, které poskytují služby v rámci Evropské unie.

Ukládány jsou veškeré informace nutné pro ověření/prokázání právní platnosti archiválií, a to i po vypršení platnosti certifikátů, na kterých jsou založeny elektronické podpisy. Pakliže je požadován elektronický originál elektronické archiválie jako důkazní materiál, pak je poskytován k jednotlivým elektronickým archiváliím bez ohledu na ostatní dokumenty v balíčku, bez jejich kompromitace a bez ohledu zda v čase poskytnutí důkazního materiálu existují. Toho je dosaženo tak, že bude podepsán balíček obsahující kontrolní součty jednotlivých dokumentů v tomto balíčku. Jako důkaz bude poskytnut tento soubor, takže nebudou kompromitovány ostatní dokumenty. Poskytnutí archiválie je ve formě výstupního DIP balíčku jako důkazního materiálu.

Logická vrstva Archivu zajišťuje služby pro správu dokumentů a lze se s ní integrovat pomocí standardního rozhraní CMIS, WS-SOAP, WS-REST, Java a .NET API. Fyzická vrstva Archivu je tvořena fyzickým HW úložištěm poskytujícím souborový systém NFS a CIFS. Archivní balíčky a jejich důvěryhodnost jsou nezávislé na vlastnostech archivního úložiště.

K jednotlivým dokumentům v Archivu jsou ukládána metadata včetně evidence o fyzickém uložení analogových dokumentů. Řešení umožňuje ukládat libovolný binární obsah bez ohledu na formát dokumentu a pro jednotlivé typy dokumentů definovat různá metadata, minimálně v rozsahu typů text, celé číslo, číslo s desetinnou čárkou, logická hodnota a datum včetně vícehodnotových metadat. Množiny evidovaných metadat je možné konfigurovat zvlášť pro různé typy archiválií. Konfiguraci metadat je možné měnit v průběhu života systému.

Práce archiváře:

Pro práci s archivem dokumentů je k dispozici uživatelské rozhraní Archivu, realizované jako webová aplikace pomocí technologií HTML5, CSS3 a Javascript, která poskytuje přístup k požadovaným uživatelským funkcím pomocí rozhraní na bráně a přímým přístupem do webového klienta v rámci prostředí Archivu. Vybraným uživatelům – archivářům – je umožněn přístup přímo do části Archivu prostřednictvím uživatelského rozhraní Archivu. Logická vrstva Archivu poskytuje služby DMS pro práci s archiváliemi.

U vybraných typů dokumentů je možné nastavit, aby si jej uživatel nemohl stáhnout na PC, ale aby byl pouze zobrazen v prostředí prohlížeče internetu.

Zobrazení vybraných formátů dokumentů v podobě náhledu je možné v prohlížeči Daeja ViewONE, který je součástí webové aplikace, bez nutnosti stažení celého dokumentu na pracovní stanici uživatele, a to v těchto formátech: Office dokumenty (DOC, DOCX, XLS, XLSX, PPT, PPTX, ODT, ODS, ODP), PDF dokumenty, Rastrové obrázky (TIFF včetně vícestránkového TIFF, JPEG, BMP, PNG, GIF), HTML soubory. Systém obsahuje prohlížeč dokumentů, který umožňuje přidávat k zobrazenému dokumentu popisky, poznámky, grafické symboly (čáry, šipky, geometrické obrazce) – tzv. anotace a anotace lze uložit bez modifikace zobrazeného dokumentu. Prohlížeč také umožňuje stránkovat, zvětšovat/zmenšovat, otáčet a tisknout zobrazené dokumenty včetně jejich anotací.

Archiváři jsou v rozsahu jeho oprávnění k dispozici statistické informace o archivu a jeho využití, např.:

• celkový objem archiválií v archivu,

• objem archiválií daného typu,

• přírůstek archiválií za dané období,

Tyto informace jsou dostupné v podobě standardizovaných reportů. Archivář si ale může vytvořit sestavu podle vlastních potřeb.

V rámci práce archiváře může oprávněný uživatel editovat vybraná metadata archiválie. Je také možné archiválie vyhledávat, a to pomocí metadatových položek, fulltextově, nebo kombinací obou způsobů. Podoba výsledků vyhledávání je uživatelsky konfigurovatelná (ve smyslu zobrazených dat ve výsledkové sadě - např. řazení, množina zobrazených metadat). Výsledky vyhledávání jsou omezeny přístupovými právy uživatele a lze je exportovat ve vhodném formátu. K vybrané položce výsledku vyhledávání je možné si zobrazit detailní informace.

Vyhledané archiválie je možné zpřístupnit prostřednictvím Badatelny, která slouží pro dočasné zpřístupnění “kopie“ archivovaného dokumentu oprávněným (ztotožněným) osobám v režimu pouze pro čtení. Je zajištěna podpora procesu založení a schválení požadavku na poskytnutí informací z archivu.

Součástí CDA je SW pro anonymizaci archiválií. Tento SW zajistí převod dokumentu na obrazovou podobu (v případě textových formátů (např. pdf) i odstranění případné textové vrstvy) a následnou co nejefektivnější anonymizaci v okně prohlížeče vč. možnosti automatizace. Tím bude zajištěno, že archivář nemusí daný dokument stahovat do PC a že dojde k trvalé anonymizaci dat (nebude se jednat o oddělitelnou vrstvu). Webová aplikace pro anonymizaci je na bráně. Archiv vytváří kopie dokumentu ve formě rastrového obrázku. Kopii je možné anonymizovat. Anonymizovaná kopie má libovolný počet verzí. Archivář rozhoduje, kterou verzi poskytne konkrétnímu badateli. Jednu anonymizovanou verzi lze poskytnout více badatelům, nebo je možné vytvořit různé anonymizované verze pro různé badatele.

Systém obsahuje monitoring operací zachycující veškeré operace s archiválií:

• Ukládání záznamů o veškerých operacích s archiválií.

• Rozhraní pro zobrazení záznamů o operacích s konkrétní archiválií.

• Rozhraní pro vyhledávání v těchto záznamech napříč všemi archiváliemi, vytváření sestav, reporting a varovné mechanismy upozorňující na nestandardní nebo podezřelé chování.

V Archivu jsou k dispozici tyto služby:

• FileNet Content Engine pro ukládání archiválií a metadat. Je napojen na LDAP server archivu.

• FileNet BPM engine pro řízení přerazítkování a životního cyklu dokumentů. Orchestruje ostatní služby a požadavky brány.

• LDAP server Archivu. Udržuje odděleně seznam uživatelů archivu, jejich role.

• Vytvoření rastrové verzované kopie dokumentu včetně vodoznaku. Uložení anonymizované verze kopie.

• Služba přerazítkování archivačních balíčků. Přerazítkuje se dokument, který obsahuje hashe obsahu dokumentů, včetně metadat. Zároveň se ukládají veškerá data pro validaci razítek, certifikáty a klíče. Balíček tedy obsahuje podepsané a digitálně orazítkové jednoznačné hashe archiválií. Díky tomu lze ověřit, že archiválie nebyla změněna. Zároveň lze poskytnout důkazní materiál, který ověří, že archiválie nebyla změněna a ostatní dokumenty nebudou kompromitovány. Pomocí hashe lze ověřit, že dokument nebyl změněn a to včetně původních metadat. Z hashe nelze vygenerovat obsah žádného dokumentu. Pro dlouhodobé ověření služba přerazítkuje dokument balíčku a ten bude udržovat platný. Pokud bude skartována některá archiválie z balíčku, neovlivní to možnost ověřit ostatní archiválie.

• Služba pro sestavení důkazního materiálu. Vytvoří DIP balíček, který bude obsahovat obsah, metadata dokumentu, klíče, certifikáty pro ověření platnosti dokumentu.

• Služba pro výpočet statistiky archivu. Sleduje celkový objem archiválií, objem podle jednotlivých typů archiválií, přírůstek za dané období. Archivář si může definovat vlastní sestavu, na základě které se vygeneruje report.

• Webový klient pro přímý přístup do archivu. Přístupný pouze pro uživatele archivu.

2.2.3Badatelna

Badatelna je vytvořena jako autonomní uživatelská aplikace, která je integrována na dočasné úložiště Brány a bude napojena na hlavní LDAP server. Od ostatních částí systému je striktně oddělená. V jejím rámci jsou zde uloženy kopie archiválií z Archivu ve formě metadat a u vybraných archiválií i jejich interpretacemi dokumentů opatřené vodoznakem, s Archivem CDA komunikuje výhradně přes firewall.

Badatelna je samostatný modul. Součástí plnění je modul Badatelna integrovaný do celkového řešení CDA, zejména Bránu a Archiv. Umožňuje nahlížení do archiválií.

Níže jsou názorně popsané hlavní funkcionality systému, které budou v cílovém stavu konfigurovány a upraveny pro potřeby specifických funkčních a nefunkčních požadavků Zákazníka.

Badatelna má funkce pro vyhledávání archiválií, včetně historie hledání pro aktuální sezení, listování v seznamu vyhledaných archiválií, zobrazení náhledů na archiválie s vodoznakem ve webovém prohlížeči, zobrazení příslušných metadat, formuláře pro žádosti o poskytnutí elektronické kopie původní archiválie v původním rozlišení, případně elektronické kopie s právní závazností (důkazní materiál), pracovní prostor pro ztotožněné uživatele s možností stáhnout si vyžádané archiválie, uživatelské statistiky pro ztotožněné uživatele (např. seznam realizovaných/běžících žádostí o poskytnutí kopie původních archiválií s časovým rozlišením a podobně).

Frontend technologií je Angular, jQuery a HTML5. Dalšími použitými technologiemi jsou Java8, WildFly, Apache Solr, OpenSeadragon.

Pro vyloučení všech pochybností uvádíme, že zde nabízené řešení v plné míře splňuje požadavky Zadávací dokumentace, a to zejména požadavky kladené na komponentu Badatelny definované v příslušných kapitolách ZD.

2.2.3.1Administrační část

Administrátor badatelny se přihlašuje svými služebními přihlašovacími údaji, přihlašování se ověřuje vůči LDAP/AD zákazníka.

Seznam badatelů

Tabulka všech osob, které v minulosti navštívili badatelnu, a byl jim vytvořen přístup. Tabulka zobrazuje jméno, příjmení, email a číslo OP badatele (případně další atributy dle konfigurace). Po kliknutí na konkrétní řádek se zobrazí detail badatele s možností úpravy osobních údajů badatele.

Pole Hledat nad tabulkou umožňuje fulltextové vyhledávání ve všech záznamech. Pokud badatel ještě nemá vytvořený účet, tlačítkem Přidat badatele je možné jej založit.

Každý řádek nabízí 3 akce (tlačítka):

• Upravit (tužka) – otevře detail badatele s možností úpravy

• Zpřístupnit dokumenty (list) – spustí proces zpřístupnění dokumentů badateli

• Odstranit (koš) – smaže záznam o badateli

Zpřístupnění dokumentů badateli

Prvním krokem je nastavení platnosti přihlašovacího tokenu, který bude vygenerován badateli. Kliknutím do pole Vypršení účtu je možné zvolit datum a čas. Kliknutím na tlačítko Pokračovat proces pokročí k výběru dokumentů ke zpřístupnění.

Kliknutím na tlačítko Přidat dokumenty se otevře dialogové okno se seznamem dokumentů v dočasném archivu určených pro badatelnu. Předvyberou se dokumenty určené pro daného badatele. Pole Hledat umožňuje fulltextové vyhledávání v dokumentech dočasného archivu. Zaškrtnutím jednoho nebo více dokumentů a kliknutím na tlačítko Přidat dokumenty jsou dokumenty přidány do dávky ke zpřístupnění. Tuto operaci lze opakovat. Na úrovni dokument je možné specifikovat, na kterých zařízeních v rámci badatelny bude dokument přístupný. Jednotlivá zařízení v badatelně jsou identifikované na úrovni fixních IP adres a názvů zařízení.

Pokud je již seznam dokumentů v dávce kompletní, kliknutím na tlačítko Zpřístupnit dokumenty jsou dokumenty zpřístupněny badateli a v dialogovém okně se administrátorovi zobrazí vygenerovaný přihlašovací token, který předá badateli.

Aktivní přihlášení

Tabulka všech aktuálně platných přihlašovacích tokenů. Obsahuje jméno a příjmení badatele, přihlašovací token a jeho platnost. Každý záznam v tabulce obsahuje tlačítko Ukončit relaci, které okamžitě ukončí platnost daného přihlašovacího tokenu.

Záznamy o aktivitě dokumentu

V sekci Záznamy o aktivitě v hlavní nabídce v pravém sloupci se zobrazí tabulka všech dokumentů, pro které existuje nějaký záznam o jeho aktivitě. Po kliknutí na řádek dokumentu nebo na tlačítko lupy u něj se zobrazí detail aktivity daného dokumentu.

Každý záznam o aktivitě obsahuje jméno a příjmení badatele, typ události (Akce) a datum a čas události (Poslední přístup).

Aktivitou dokumentu může být:

• Zobrazení detailu dokumentu badatelem

• Zobrazení obrazové vrstvy některé stránky dokumentu badatelem

• Zobrazení textové vrstvy některé stránky dokumentu badatelem

• Vyžádání tisku některé stránky dokumentu badatelem

U posledních tří typů aktivity je vždy uvedeno i číslo dotyčné stránky (Strana).

Záznamy o aktivitě badatele

V sekci Zobrazit aktivitu badatele v seznamu badatelů se zobrazí modální okno se seznamem všechakcí badatele nad všemi jemu zveřejněnými dokumenty.

Aktivitou badatele může být:

• Zobrazení detailu dokumentu – název dokumentu je uveden v sloupci Dokument

• Zobrazení obrazové vrstvy některé stránky dokumentu – číslo dotyčné stránky je uvedeno v sloupci Parametr a název dokumentu v sloupci Dokument

• Zobrazení textové vrstvy některé stránky dokumentu – číslo dotyčné stránky je uvedeno v sloupci Parametr a název dokumentu v sloupci Dokument

• Vyžádání tisku některé stránky dokumentu – číslo dotyčné stránky je uvedeno v sloupci Parametr a název dokumentu v sloupci Dokument

• Vyhledávání v dokumentech – vyhledávaný výraz je uveden v sloupci Parametr

2.2.3.2Badatelská část

V rámci Badatelny je zaznamenávána činnost ztotožněného uživatele s vyžádanou poskytnutou kopií archiválie. Veškeré úkony badatele v rámci badatelské části jsou logovány do badatelského listu, jde zejména o tyto hlavní úkony:

• Přihlášení,

• Vyhledání dokumentu

• Zobrazení detailu dokumentu

• Zobrazení obrazových dat dokumenty (se specifikací konkrétně, o které obrazové data jde)

• Listování v seznamu dokumentů

• Odhlášení

Přihlášení

Po spuštění badatelny v prohlížeči se badateli zobrazí pole pro zadání přihlašovacího tokenu. Po jeho zadání a kliknutí na tlačítko Přihlásit se se badateli zobrazí seznam zpřístupněných dokumentů.

Seznam dokumentů

Seznam všech zpřístupněných dokumentů v rozsahu název a náhled první stránky. Po kliknutí na název nebo obrázek dokumentu se otevře jeho detail.

Fulltextové vyhledávání

V horní části badatelny je ústřední vyhledávací pole pro fulltextové vyhledávání ve zpřístupněných dokumentech. Hledaný výraz se vyhledává v názvech i všech metadatech dokumentů.

Detail dokumentu

Detail dokumentu obsahuje přehled všech metadat zpřístupněného dokumentu a možnost prohlížet si obrazová data dokumentu tlačítkem Prohlížet nebo kliknutím na náhled první stránky.

Při prohlížení obrazových dat je v pravé části prohlížeče zobrazen seznam všech stránek dokumentu v podobě jejich náhledů. Detail obrazu stránky lze přibližovat a oddalovat pomocí tlačítek ve vrchní části nebo kolečkem myši. Obraz je také možné zobrazit na celou obrazovku.

Historie hledání

Historie hledání zaznamenává všechna hledání badatele v rámci jeho sezení. Je tedy možné se vrátit na seznam výsledků hledání z minulosti kliknutím na Historie vyhledávání v hlavním menu badatelny.

Odhlášení

Po kliknutí na jméno badatele v pravém horním rohu badatelny se rozbalí uživatelské menu s možností Odhlásit. Po odhlášení automaticky končí platnost přihlašovacího tokenu a badatel již není schopen se s tímto tokenem přihlásit znovu.

2.3Migrace

V této kapitole je uveden návrh řešení migrace. Finální řešení bude modifikováno podle výsledků implementační analýzy a dodavatel souhlasí, že takto modifikovaná varianta migrace jím bude realizována.

Zadavatel má data uložená v prostředí EMC Centera, které zajišťuje jejich důvěryhodné uložení. Proces migrace je vedle technického řešení navržen právě s ohledem na zajištění co nejvyšší míry zachování důvěryhodnosti migrovaných dat, čehož je dosaženo:

• pomocí vygenerování a porovnávání kontrolního součtu u každého souboru,

• tím, že proces migrace bude validován důvěryhodnou autoritou (např. renomovanou advokátní kanceláří nebo příslušným znalcem).

Soubory a jejich metadata budou z EMC Centera vyexportovány pomocí jednorázového exportního SW nástroje. Celkový objem dat je cca 7TB, 23 000 000 souborů. Očekáváme, že Zaxxxxxxx xoskytne dostatečně kvalitní a výkonově dostačující výstup, který umožní provézt migraci v požadovaném čase všechna data budou po exportu z EMC Centery až do provedení implementace CDA uložena plně v prostředí Zadavatele, stejně jako podporu pro provedení této činnosti.

V této části bude dodáno:

• Vytvoření exportního nástroje

• Provedení exportu dat

• Uložení dat do prostředí Zadavatele

• Zpracování metadat

Jednotlivé kroky a činnosti migrace se v rámci finální analýzy budou ještě precizovat na základě detailních požadavků klienta a jeho možností zajistit součinnost pro tuto aktivitu.

2.3.1Export

Než se začne se samotným exportem, musí být hotova přesná definice podmínek, jaké je nebytné dodržet při práci s daty v rámci migrace.

V následujícím kroku budou analyzována data v EMC Centera a na základě výsledku bude vyvinuta SW rutina, která zajistí automatický export definovaných dat. Na vzorku dat bude otestována funkčnost exportu a po případných úpravách bude proveden export samotný.

Exportovaná data se skládají ze souborů a metadat. Soubory jsou zafixovány pomocí výpočtu a uložení kontrolního součtu. Uložena jsou také všechna původní metadata s vazbou na příslušné soubory.

Pokud dojde u některých dat při exportu k chybovému stavu, bude to uvedeno v logu a následně bude rozhodnuto, jak s těmito daty bude naloženo. Data budou uložena v prostředí Zadavatele, takovým způsobem aby nemohlo dojít k jejich modifikaci, ani ztrátě.

2.3.2Zpracování dat

V této fázi budou zpracována a doplněna metadata. Původní metadata budou zachována a k nim se jako další vrstva připojí metadata nová tak aby bylo evidentní, která metadata byla původní. Na zpracování metadat bude vytvořen samostatný konverzní SW nástroj s rozšířeným logováním. Předpokládáme, že se bude jednat o cca 7 dokumentových tříd (není omezující podmínka). Součástí plnění bude analýza a návrh metadat. Jedním z nových metadat bude i kontrolní součet souvisejícího souboru. Podle výsledku analýzy bude probíhat kontrola, vytěžení, čištění, automatické doplnění a případně i další operace. Může být kontrolován obsah některých položek metadat. Typicky jde o kontrolu rozsahu číselných údajů, ověření zda položky typu datum obsahují smysluplné datum spadající do období od-do, ověření vyplnění povinných položek, případné nahrazení původních hodnot metadat novými na základě konverzních tabulek dodaných zadavatelem a podobně. Pro potřeby takových kontrol se předpokládá, že zadavatel specifikuje, o které položky se má jednat, jakým způsobem mají být ověřovány, a jaké výchozí hodnoty mají být dosazeny v případě, že původní hodnota je mimo povolený rozsah, nebo není zadána.

Uvažovaná pracnost předpokládá, že podobným způsobem nebude kontrolováno více než pět jednotlivých položek metadat v rámci každé dokumentové třídy.

Součástí procesu konverze bude testovací sada a její kontrola. Po případných úpravách bude provedena samotná konverze a vyhodnocení logu.

2.4Příprava produkčního provozu

V této kapitole je uveden návrh přenosu migrovaných dat do cílového prostředí CDA. Finální řešení bude modifikováno podle výsledků implementační analýzy a dodavatel souhlasí, že takto modifikovaná varianta jím bude realizována.

Zpracovaná data z EMC Centery budou ve formě SIP balíčků organizovaných dle standardů METS importována v nezměněné formě k dlouhodobému důvěryhodnému uložení do nového cílového prostředí CDA. Také bude na základě výsledku implementační analýzy provedena transformace a doplnění metadat.

Všechna data budou po exportu z EMC Centery až do provedení implementace CDA uložena plně v prostředí Objednatele.

V této části bude dodáno:

• Vytvoření SIP balíčků

• Import do cílového úložiště

V následující tabulce jsou vyjmenovány činnosti, které uchazeč provede v rámci přípravy produkčního provozu.

2.4.1Balíčkování

Po vyčištění a nachystání metadat (toto je provedeno v rámci migrace) může být spuštěno balíčkování. Za tímto účelem bude vytvořena jednoúčelová konzolová konverzní aplikace, která převede soubory a metadata na výstupní SIP balíčky, organizované dle standardů METS, určené k importu do nového cílového prostředí. Konverzní nástroj bude vytvářet logy, které budou obsahovat podrobné informace o jednotlivých konvertovaných dokumentech a výsledcích konverze. Pokud se vyskytne v průběhu zpracování některého dokumentu chyba, bude tento dokument zapsán do samostatného seznamu dokumentů, které nebylo možno konvertovat. Konverzní nástroj si bude také evidovat informace o všech doposud zpracovaných dokumentech.

Konverze do SIP balíčků může být časově náročná. Upřesnit časový rozsah bude možné po vyhodnocení testovací sady s reprezentativním vzorkem dat. Vyskytne-li se z provozních důvodů nutnost běh aplikace přerušit, může obsluha toto kdykoli učinit. Při dalším spuštění bude provedeno nastavení konverze tak, aby pokračovala od místa přerušení.

Budou sdružovány informace o průběhu konverze jednotlivých dokumentů a počtu již zpracovaných dokumentů. Po skončení konverze se běh konverzního nástroje automaticky zastaví a bude vypsána informace o jejím ukončení a celkovém počtu zpracovaných dokumentů.

2.4.2Import

Po otestování správnosti obsahu SIP balíčků je provedena testovací migrace, tedy nahrání zvoleného vzorku dat do cílového úložiště. Součástí importu bude spočítání kontrolního součtu každého souboru a porovnání s původním kontrolním součtem provedeným při exportu z prostředí Centery. V případě rozdílu kontrolních součtů nebudou dané SIP balíčky importovány do cílového prostředí a bude provedena analýza příčiny rozdílu kontrolních součtů. O tom, co se bude dít s nenaimportovanými SIP balíčky, rozhodne po doporučení uchazeče zadavatel.

Po ověření funkčnosti nahrávání SIP balíčků do testovacího úložiště bude spuštěn proces nahrávání všech SIP balíčků do cílového prostředí. Stejně jako v testovací části je počítán kontrolní součet a stejně se také postupuje při jeho nerovnosti.

Tento proces bude časově náročný.

2.5Bezpečnost prostředí archivu, bezpečnost dokumentů

Řešení pro zajištění a ochranu dat je pro digitální archiv klíčovou komponentou. Jako takové je třeba věnovat velké úsilí ochraně takových dat a zajištění konzistence a integrity.

Behaviorální analýza dokumentů probíhá ve specializovaném virtualizačním prostředí, které je postaveno na řešení předního vendora těchto technologií, které je plně integrováno do celkového řešení, které zde pro Zadavatele (Česká pošta) představujeme. Navrhované řešení je segmentováno do jednotlivých zón a jejich komunikace je striktně oddělena firewallem (firewall cluster), který umožňuje pokročilé kontroly (deep packet a statefull inspection, ACL, virtual patching apod..). Součástí řešení je zároveň nasazení SIEM řešení pro sběr logů z komponent navrhovaného prostředí CDA. Toto řešení je možné integrovat na další komponenty a zajistit tak komplexitu přehledu a detekce kybernetických hrozeb.

Navrhové řešení naplňuje požadavky Zadavatele z pohledu bezpečnosti a provozu takových systémů, dle příslušných předpisů požadovaných v rámci ZD.

2.5.1Vlastnosti karantény

Navrhované řešení je velice flexibilní v rámci konfigurace virtuálního stroje, kde je možné instalovat a konfigurovat různé aplikace, včetně specifických zákaznických aplikací a aplikací třetích stran. Tato flexibilita umožňuje testovat dokumenty v prostředí, které je pokud možno, co nejpodobnější prostředí zákazníka. Standardně se používá tzv. gold image, která je používána jako standardní image pro instalaci pracovních stanic u zákazníka. To zaručuje maximální bezpečnost v případě, že dochází k pokusům o útok s využitím interních informací o infrastruktuře zákazníka, používaných aplikací, typických konfigurací aplikací apod. Nicméně ve vysoce customizovaném prostředí České pošty, je nutné využít upravené images, které odpovídají co nejvíce prostředí Zadavatele. Tato varianta je součástí řešení, které zde Dodavatel představuje.

Vlastní testovací prostředí je připraveno pomocí Virtual boxu, nicméně následně se použije Image Preparation tool, prostřednictvím kterého dojde k odstranění stop po virtuálním prostředí. Tím je zajištěna vlastní bezpečnost a nemožnost kompromitace prostředí vlastního prostředí karantény, neboť pro odeslání do takto připravené image jsou připravené rutines, které nemohou vlastní firmware zařízení kompromitovat.

Dokumenty k testování zasílá do karanténního řešení systém ECM prostřednictvím standardního a velmi dobře zdokumentovaného API. Pro testovaný dokument je v rámci řešení spuštěna instance virtuálního stroje, ve kterém probíhá behaviorální analýza testovaného dokumentu včetně případných souvisejících souborů a objektů. Karanténa provádí v rámci spuštění testovaného dokumentu ve virtuálním stroji analýzu bez nutnosti disponovat příslušnou virovou signaturou a to na základě chování testovaného dokumentu. Nicméně je vhodné provést komplexní hodnocení testovaného dokumentu, tj. včetně kontroly vůči známým signaturám. V takto dedikovaném a zcela izolovaném prostředí při testování dokumentu ve virtuálním stroji je zachyceno i případné polymorfní chování malware.

Zároveň je možné této flexibility využít i pro paralelní testování v méně zabezpečených virtuálních strojích (např. WinXP) tak, aby bylo co nejrychleji a nejefektivněji odhalit, že dochází k pokusům o útok na infrastrukturu zákazníka (jako jsou Zero-Day attacks nebo APT), které by se nemusely u standardně nakonfigurovaným virtuálním strojům projevit díky vyššímu zabezpečení těchto standardních virtuálních strojů. V rámci analýzy chování testovaných dokumentů ve virtuálním stroji jsou simulovány činnosti uživatelů a další simulace, které mohou nastat v reálném prostředí (posun času apod.)

Pro kontrolu obsahu souborů je v karanténě navrženo řešení, které podporuje požadované formy OS: Windows XP, Win7, Win8/8.1, Win 10 (až do verze uvedené H2/2019 - 1909), Windows Server 2003, 2008, 2012, 2016, 2019 a  Mac OS. Díky customizaci je možné nahrát virtuálně libovolnou aplikaci, včetně MS Office 2007 a vyšší a Adobe Reader 9 a  vyšší, prohlížeče souborů .ZFO aj.

Standardně podporované soubory jsou uvedeny níže. Nicméně prostřednictvím customizace a přípravy řešení, s kterým Dodavatel počítá v rámci řešení, je možné testovat téměř jakýkoliv typ souborů. Plně podporované soubory: .bat, .cmd, .chm, .csv, .class, .dll, .doc, .docx, .exe, .sys, .crt, .html, .jar, .js, .jse, .lnk, .pdf, .ppt, .pps, .pptx, .ppsx, .ps1, .rtf, .vbe, .vbs,, .xls, .xlsx, .xltx, .xlsm, .xlam, .xltm, .xml. Mezi soubory, které Dodavatel má již otestované u jiných zákazníků a které jsou součástí požadavků na testování v rámci CDA patří i následující přílohy: .zfo, .jpg, .gif, .tif, .tiff, .png .py., pdf/a. Nicméně jak již bylo zmíněno, v rámci řešení je možné testovat téměř jakýkoliv typ přílohy. Tyto přílohy budou testovány v prostředí Zadavatele a analýza se bude provádět v infrastruktuře Zadavatele., tak jak vyžaduje ZD. Je možné zapnout i další pokročilé funkce, které mohou přinést další úroveň bezpečnosti a které mohou eliminovat některé další false/positive incidenty.

2.5.2Detailní popis

Navržené řešení je propojené s ECM systémem prostřednictvím API a po dokončení inspekce poskytuje výsledky testování. ECM systém na základě těchto výsledku rozhodne o dalším způsobu zpracování testovaných dokumentů. Testování dokumentů na přítomnost malware jsou prováděna před vlastní archivací dokumentu. Na základě výsledků tohoto testování je teprve rozhodnuto, jestli daný dokument bude dál puštěn do standardního procesu archivace, případně bude vyřazen z tohoto procesu (nebude propuštěn do prostředí Archivu). Soubory, které jsou testovány na přítomnost malware, nejsou odeslány mimo prostředí Zadavatele. V případě detekce závadného obsahu v testovaném dokumentu vrátí karanténa chybový kód. Na základě tohoto bude daný dokument, případně soubor, vyřazen ze standardního zpracování v rámci ECM. Takto detekované dokumenty jsou uloženy v prostoru, který nemůže nijak ohrozit další dokumenty. Uživatel ECM má možnost rozhodnout, jak s daným dokumentem bude naloženo. Toto testování, jak již bylo uvedeno, je prováděno v prostředí Zadavatele a soubory nebo objekty nejsou odesílány na cloudu pro dynamickou analýzu. V případě detekce malware systém poskytuje v rámci dodávaného řešení detailní reporting a podrobnou analýzu, která převyšuje požadavky kladené na ně v rámci ZD. Systém tento report generuje ke každému zpracovanému souboru, která je dostupná v přehledné a interaktivní formě v prostředí navrhovaného řešení, případně je možné vyexportovat výsledky analýzy do externího PDF reportu.

Pro zpracování a vyhodnocení vícefázových a vícenásobných útoků je možné pomocí skriptů zajistit paralelní zpracování. Dále jsou uvedeny typy souborů, které jsou vhodné pro takový typ zpracování:

1. Archivní soubory: .7z, .ace, .amg, .apk, .arj, .hqx, .bz2, .bzip2, .cab, .crx, .gzip, .gz, .iso, .lha, .lharc, .lzh, .bin.macbin, .eml, .email, .msg, .arc, .rar, .sis, .sit, .sitx., .tar, .tgz, .tnef, .winmail.dat, .win.dat, .uue, .wim, .xz, .zip.

2. Kromě archivu, či jednotlivých souborů, lze vložit i „bundle“ souborů (např. spustitelné soubory, které mají být v dané adresářové struktuře.

Zároveň je možné takové zpracování řešit prostřednictvím skriptů typu .bat.

Typicky je Karanténí řešení zapojeno tak, že komunikuje jednosměrně s update serverem přes web proxy, která dovoluje pouze tento druh komunikace (aktualizace), případně je možné provádět aktualizace vlastních reputačních a hash databází ručně. Případně je možné toto řešení napojit na vlastní management server, který Karanténě poskytuje zdroj „updates“. Navrhovaná řešení naplňují požadavky na přepnutí do režimu “offline” a vlastní analýza detailně stanoví možnosti nasazení v prostředí Zadavatele.

2.6Bezpečnost dat a informací

Jako součást nabídky za část bezpečnost a ochrany informací a dat uložených v archivu přináší Dodavatelem osvědčenou technologii, která je použita u mnoha poskytovatelů a zpracovatelů osobních a citlivých informací. Touto technologií je IBM Guardium. Je samozřejmé, že data jsou provozována na database prostředí plně podporovaných výrobcem, které je plně aktualizované (poslední bezpečnostní hotifixy, patches a updates.).

Právě z důvodu, že data jsou jedním z nejcennějších majetků firem, je potřeba tyto data chránit, ovšem tak, aby to neomezilo zaměstnance a funkčnost vlastních systémů. Celé řešení je dle požadavku postaveno na logicky a fyzicky oddělených komponentách Brána, Archiv, Badatelna, které běží na rozdílném HW a různých bezpečnostních zónách oddělné prostřednictvím firewallu. Na serverech jsou agenti pro zajištění integrity a ochrany dat, stejně tak jsou příslušné operace monitorovány a logy jsou vyhodnocovány v centrálním SIEM. Databázová data jsou chráněna prostřednictvím produktu IBM Guardium

Řešení IBM Security Guardium poskytuje centralizovaný monitoring, ochranu, automatickou analýzu dat a jejich kategorizaci, vysokou škálovatelnost, vytváření a uchovávání auditních záznamů a mnoho dalšího, a to vše v reálném čase jak nad strukturovanými, tak i nestrukturovanými daty. Řešení umožňuje posílat poplachy událostí přes syslog, email, snmp, ticketovací systém a i možnost vytvořit si vlastní poplach v programovacím jazyku java využívající API externích systémů.

Řešení nabízí možnosti vybírat si z předdefinovaných reportů anebo vytvářet vlastní reporty, případně kopírovat stávající, a ty libovolně upravovat. Je možné měnit zobrazení z pohledu sloupců, nastavovat podmínky zobrazení, časové intervaly, řazení dat, apod.

Komplexní návrh řešení se skládá z modulů pro ochranu databází, souborů a vyhledávání zranitelností.

2.6.1Modul ochrany databází

V databázích jsou často uložené údaje o zákaznících, obchodních transakcích a další důležité firemní informace. Jedná se často o jedny z nejcennějších informací ve firmě. Přesto k databázím často mají přístup téměř všichni zaměstnanci firmy, protože data z nich potřebují ke své každodenní práci. Může tedy docházet k situacím, kdy jsou data z databáze zcizena nebo poškozena nespokojeným zaměstnancem. Dalším rizikem pro databáze jsou externí hackeři, kteří chtějí data získat a využít pro svůj prospěch například jejich prodáním na černém trhu nebo vydíráním okradené společnosti.

Řešení ochrany databází umožňuje zaznamenávat, co se děje v databázi bez toho, aby to výrazně ovlivnilo výkon databáze. Zaznamenané informace jsou poté v reálném čase analyzovány. Pokud dojde k podezřelé události, je zasláno upozornění na příslušná místa, případně dojde k blokaci akce, která může vést k úniku dat. Veškerou monitorovanou aktivitu a detekované podezřelé události si mohou pověření pracovníci prohlédnout v přehledné webové konzoli, kde mohou také nastavovat bezpečnostní politiky, tvořit reporty a třeba i definovat citlivá data, kterým má být věnována speciální pozornost během monitoringu.

Kontrola provozu je prováděna v reálném čase. Guardium podporuje mnoho různých typů databází, je tedy možné na jednom místě monitorovat aktivitu nad všemi firemními databázemi. Konkrétně řešení funguje tak, že na operačním systému, kde je umístěna databáze je nainstalovaná malá sonda, takzvaná S-TAP, která monitoruje vše, co se na databázi děje a tato data poté odesílá do Guardium appliance, kde se data analyzují a korelují. Výhodou tohoto přístupu je to, že Guardium dokáže odhalit i útoky a příkazy (případně je omezit nebo zakázat) od privilegovaných uživatelů, kteří se mohou do databáze připojit přímo a nepřistupují k ní přes aplikaci nebo přes síť. Záznamy o takových aktivitách nejsou uloženy na DB serverech a tudíž je znemožněn zásah takového privilegovaného uživatele do logu.

Dalšími funckionalitami v modulu ochrany databází je behaviorální analýza uživatelů (Risk Spotter), která dokáže upozornit na anomálie v chování jednotlivých uživatelů s využítím strojového učení. Je možné s ní detekovat nové uživatele, nové objekty v provozní komunikaci, změny chování jednotlivých uživatelů z pohledu pracovní doby. Funkcionalita Aktivní analýzy hrozeb je zase určená pro detekci kybernetických útoků na databáze (SQL injection a další typy útoků).

Funkcionalita Aktivní analytiky hrozeb je zase zaměřená na detekci kybernetických útoků typu SQL injection další (např ACL - Na základě ACL seznamů je možné automaticky vytvořit baseline pravidla v řešení IBM Guardium, apod.).

Guardium appliance umí korelovat a zpracovávat data z většiny komerčně používaných databází a big data řešení, například: Oracle, IBM DB2, Microsoft SQL Server, Sybase, Postgres, MariaDB, mySQL, IBM Informix, Teradata, NoSQL, MongoDB a Hadoop.

Pro potřeby auditingu má Guardium předpřipravenou širokou škálu reportů a umožňuje pokročilé vyhledávání v záznamech. Záznam a vyhodnocení auditních záznamů je možné napojit a integrovat se systémy SIEM, které jsou zcela mimo prostředí, které logy generuje (syslog formát), LDAP databázemi a ticketovacími systémy. Zároveň je možné pro testovací databáze nastavit maskovací či redakční politiky, které dokáží zneviditelnit nebo pozměnit obsah jednotlivých dat v rámci testování. Je možné definovat variabilní politiky, u kterých lze nastavit flexibilně pro jaké atributy komunikace bude maskování probíhat

2.6.2Modul ochrany souborů, integrita

Ochrana nestrukturovaných dat jako například MS Office souborů, zdrojových kódů, konfiguračních souborů a dalších je jedním z klíčových bodů bezpečnosti ve firmě. Know-how firem, smlouvy a další důležité informace jsou uloženy v těchto souborech.

Modul ochrany souborů dokáže monitorovat a kontrolovat přístup k souborům v celém prostředí firmy, díky tomu získají zákazníci přehled o tom kdo, kam, kdy a jak přistupoval k jejich souborům. Systém dokáže tyto informace využít a dát je do vzájemných souvislostí a upozorňovat na případné podezřelé aktivity uživatelů.

Veškeré politiky jsou tvořeny modulárně, připojení dalších souborových systémů tedy nevyžaduje složité nastavování a politiky jsou automaticky aktivovány po instalaci agenta na souborový systém.

Aby řešení zjistilo, jaká data jsou na souborovém systému, spouští pravidelně na systémech neinvazivní operaci, která prohledá soubory a zašle o nich informaci. Vlastní řešení poté tato data zpracuje a vyhodnotí citlivost souborů dle předdefinovaných politik. K definici dat používá například informace o lokaci souborů, jména souborů, velikost, datum poslední modifikace, vlastník souboru, přístupová práva k souboru a další. Nastavené politiky zamezí spuštění neznámých nebo neautorizovaných aplikací

Modul ochrany souborů je tedy vhodný pro:

• Ochranu konfiguračních a aplikačních souborů, které jsou volně dostupné na aplikačních a databázových serverech.

• Ochranu souborů obsahujících důvěrná osobní data jako například čísla kreditních karet, čísla účtů, rodná čísla a další.

• Ochranu souborů, které mají být modifikovány pouze pomocí k tomu určených aplikací před neoprávněným přímým přístupem.

• Ochranu zdrojových kódů přístupných například na build serveru firmy.

Architektura řešení je obdobná jako architektura modulu ochrany databází. Na serveru nebo klientské stanici je nainstalována takzvaná sonda nebo agent, který odesílá informace ze systému do vlastního managementu řešení, které tyto spravuje agenty spravuje. V navrhovaném řešení je tento management modul umístěn v Cloudu (je možné jej umístit i do prostředí Azure). Detailní popis nasazení řešení, bude součásti analýzy, kde Zadavatel jednoznačně uvede v kterém Cloud prostředí požaduje nasazení tohoto modulu, nastavení konektivity a vlastních politik. V kombinaci s nasazení next-gen firewall, poskytuje toto řešení možnou blokaci portů, ochranu před kybernetickými hrozbami, monitoring a ochranu před exploity

2.6.3Modul vyhledávání zranitelností

Databáze a souborové systémy v IT prostředí se často mění. Dochází ke změnám v uživatelských účtech, konfiguracích, či se objevují nové aktualizace, které se pravidelně stahují aktualizují každé čtvrtletí. Ve většině organizací a firem nedochází k centralizované a systematické kontrole těchto změn, které by omezovaly rizika se změnami spojené. Občasné ruční kontroly nastavení bývají zdlouhavé, nepřesné a náchylné na chyby.

Součástí řešení je i modul vyhledávání zranitelností. Jedná se o centralizovanou platformu pro řízení rizik spojených s datovou infrastrukturou. Guardium provádí pravidelné skenování prostředí a hledá chybějící aktualizace, slabá hesla, známé chyby v nastavení a další bezpečnostní rizika. Informace o nejnovějších hrozbách získává z IBM X-Force výzkumu.

Skenování se neomezuje pouze na databázové systémy, ale je možné ho provádět i nad big data, data warehousech a dalších platformách pro uchovávání dat. Všechny nalezené informace jsou automaticky zpracovány v přehledném reportu spolu s doporučenými best-practices, jak nalezené zranitelnosti opravit.

Zranitelnosti jsou seřazeny dle závažnosti v závislosti na typu zranitelnosti a informacích o skenovaném zařízení, které má Guardium k dispozici. Skenování lze provádět jak pravidelně (plánovaně), tak v daném okamžiku přímo z Guardium konzole. Všechny reporty je možné exportovat v mnoha různých formátech jako například .PDF, Syslog, CSV a další. Reporty je možné automaticky odesílat zainteresovaným osobám a automatizovat tím auditní procesy.

Guardium umožňuje provádět zaměstnancům, starajícím se o bezpečnost, skenování zranitelností bez spolupráce s ostatními IT zaměstnanci. To pomáhá k menší zátěži IT a také k rozdělení jednotlivých pravomocí v rámci společnosti. Skenery Guardium jsou nastavené tak, aby minimálně zatěžovaly databázové systémy a nedocházelo k ohrožení dostupnosti. Guardium dokáže v případě, že má provádět skenování v době kdy je databáze zatížena provést pouze testy na velmi nebezpečné zranitelnosti a ostatní testy provést později. Stejně tak je možné pozastavit testování na konkrétní zranitelnost, než bude opravena, aby nedocházelo ke zbytečnému vytváření dlouhých, bezobsažných reportů. Výstupy z jednotlivých datových zdrojů je možné v reportech spojovat do logických celků pro celkové zpřehlednění reportu.

Modul vyhledávání zranitelností je tedy vhodný pro:

• Skenování jednotlivých databází a hledání zranitelností jako chybějících patchů, slabých hesel a nevhodných nastavení.

• Tvorbu a export přehledných reportů. Export do .PDF, CSV, Syslog.

• Doporučené best-practices pro opravení nalezených zranitelností

• Jednotná konzole pro kontrolu a správu všech zranitelností v databázích, big data a data warehousech.

• Eskalaci a odesílání reportů o nalezených zranitelnostech pro účely auditingu

2.6.4GDPR a compliance

V květnu roku 2016 vešlo v platnost Obecné nařízení na ochranu osobních údajů. Nyní běží dvouletá implementační lhůta pro nasazení technických a organizačních opatření pro zajištění souladu s novou regulací.

Jedním z hlavních témat je prevence úniku či znehodnocení dat, jak strukturovaných, tak nestrukturovaných. Celé nařízení se pak zabývá převážně udržením kontroly nad osobními údaji a udržení vysoké úrovně jejich zabezpečení.

IBM Security Guardium je platforma, která pomáhá řešit značnou část z technických požadavků regulace. Díky monitoringu databází i nestrukturovaných dat a aplikovaní behaviorální analýzy dokáže v reálném čase zjistit podezřelé chování spojené s osobními údaji i dalšími citlivými aktivy organizace. Zároveň je díky vlastním prvkům proaktivní ochrany nebo ve spoluprací s dalšími bezpečnostními prvky infrastruktury, schopna podezřelé aktivity zastavit, popřípadě podstoupit přezkoumání. Řešení obsahuje sady pravidel pro soulad s GDPR.

Platforma v sobě již nyní přímo obsahuje tzv. GDPR akcelerátor v jehož rámci jsou nastaveny odpovědi na jednotlivé požadavky Nařízení. Řešení IBM Guardium obsahuje vlastní klasifikační funkcionalitu pro rozpoznání citlivých údajů v databázích a souborech. V řešení jsou například před připravená klasifikační pravidla z pohledu GDPR compliance. Zároveň řešení obsahuje předpřipravené klasifikační politiky a také nástroje pro tvorbu vlastních klasifikačních pravidel.

IBM Guardium je tak odpovědí na komplexní otázku monitoringu dat velkým krokem technického charakteru pro dostatečnou odpověď na požadavky Obecného nařízení.

3.Součinnost

Níže jsou uvedeny další požadavky na součinnosti objednatele pro implementaci i provoz řešení. Všechny ostatní požadavky na součinnosti objednatele budou uvedeny následně v řídícím dokumentu.

• Vzdálený přístup

• Administrátoři

  • Součinnost administrátorů objednatele při instalacích, nastavení uživatelských oprávnění, provedení nezbytných prací v Active Directory, případně IDM.

  • Zajištění přístupů LDAP - přístup k LDAP serveru objednatele pro potřeby autentizace do administrační části Badatelna v rámci CDA CP – vytvoření a označení skupiny badatelna_admin, do které si zákazník přiradí osoby, kterým chce udělit přístup do administrace

• Přístup do stávajícího prostředí EMC Centera za účelem provrdení migrace

• Součinnost popsaná v kapitolách Migrace a Příprava produkčního provozu

4.Licenční podmínky licence Bezpečný digitální archiv

4.1Licenční model a rozsah licence Bezpečný digitální archiv

4.1.1Licenční model

Tento dokument popisuje licenční podmínky licence dodávaného řešení Bezpečný Digitálního Archivu pro zadavatele Česká pošta. Licence bude zákazníkovy poskytnuta ve formě „managed licence“ tedy licenční modelem, kdy zákazník získá stanovenou licenci k plnému užívání dle níže uvedených licenčních podmínek na dobu platnosti uzavřené smlouvy, a to včetně produktové podpory. Po uplynutí smluvní doby, po kterou má zákazník licenci k plnému užívání včetně platné produktové podpory, má zákazník možnost pokračovat v plném využívání poskytnuté licence bez produktové podpory anebo zakoupit produktovou podporu dle podmínek Passport Advantage Agreement (viz Kapitola 2 tohoto dokumentu).

Níže uvedená text uvádí seznam prvků řešení Bezpečného digitálního archivu, které jsou do licence zahrnuty a licenční podmínky dané části licencovaného řešení Bezpečný Digitálního Archivu.

Modul Brána

Část řešení Bezpečný digitální archiv Brána je licencována na základě licenčního modelu VPC pro stanovený počet standardních autorizovaných uživatelů a archivářů, kteří mohou komponentu Brány využívat. V rámci licence řešení Bezpečný digitální archiv získává zákazník k plnému užívání licenční právo pro 5000 standardních autorizovaných uživatelů a 20 archivářů využívajícím komponentu Brána. V rámci těchto licenčních podmínek získává zákazník právo k plnému využívání komponenty řešení Brána pro testovací, produkční i DR prostředí CDA.

V případě, že počet autorizovaných uživatelů využívajících komponentu Archiv překročí výše uvedené počty, je zákazník povinen konzultovat rozšíření stávající licence s dodavatelem.

Odkaz na detailní licenční podmínky:

xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/0X000000X0XXXX000000000X000X0000?XxxxXxxxxxxx

Modul Archiv

Část řešení Bezpečný digitální archiv Archiv je licencován na základě licenčního modelu VPC pro stanovený počet standardních autorizovaných uživatelů a archivářů, kteří mohou komponentu Archiv využívat. V rámci licence řešení Bezpečný digitální archiv získává zákazník k plnému užívání licenční právo pro 5000 standardních autorizovaných uživatelů a 20 archivářů využívajícím komponentu Archiv. V rámci těchto licenčních podmínek získává zákazník právo k plnému využívání komponenty řešení Archiv pro testovací, produkční i DR prostředí CDA.

V případě, že počet autorizovaných uživatelů využívajících komponentu Archiv překročí výše uvedené počty, je zákazník povinen konzultovat rozšíření stávající licence s dodavatelem.

Odkaz na detailní licenční podmínky:

xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/0X000000X0XXXX000000000X000X0000?XxxxXxxxxxxx

Modul MS Office View

Část řešení Bezpečného digitálního archivu MS Office View je licencována na základě licenčního modelu UVU (User Value Unit) pro stanovený počet standardních autorizovaných uživatelů a archivářů, kteří mohou komponentu MS Office View využívat. V rámci licence řešení Bezpečný digitální archiv získává zákazník k plnému užívání licenční právo pro 5000 standardních autorizovaných uživatelů a 20 archivářů využívajících řešení MS Office View. V rámci těchto licenčních podmínek získává zákazník právo k plnému využívání komponenty řešení MS Office View pro testovací, produkční i DR prostředí CDA.

V případě, že počet autorizovaných uživatelů přistupujících k řešení MS Office View překročí výše uvedené počty, je zákazník povinen zakoupit rozšíření stávající licence.

Odkaz na detailní licenční podmínky: xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/000000XX0000000X0000000X000X00XX?XxxxXxxxxxxx

Modul Redakce

Část řešení Bezpečného digitálního archivu Redakce je licencována na základě licenčního modelu UVU (User Value Unit) pro stanovený počet standardních autorizovaných uživatelů a archivářů, kteří mohou komponentu Redakce využívat. V rámci licence řešení Bezpečný digitální archiv získává zákazník k plnému užívání licenční právo pro 5000 standardních autorizovaných uživatelů a 20 archivářů využívajících řešení Redakce. V rámci těchto licenčních podmínek získává zákazník právo k plnému využívání komponenty řešení Badatelna pro testovací, produkční i DR prostředí CDA.

V případě, že počet autorizovaných uživatelů přistupujících k řešení Redakce překročí výše uvedené počty, je zákazník povinen zakoupit rozšíření stávající licence.

Odkaz na detailní licenční podmínky: xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/000000XX0000000X0000000X000X00XX?XxxxXxxxxxxx

Databázový monitoring

Databázový monitoring jako součást řešení Bezpečný digitální archiv je licencován pomocí licenčního modelu MVS (Managed Virtual Server). Zakoupená licence pokrývá fyzický server hostující modul Brána a fyzický server hostující modul Archiv v produkčním prostředí. Na těchto serverech není implementována virtualizační platforma případně je v rámci implementované virtualizační platformy instalován pouze jeden virtuální server. Celkový počet licencovaných fyzických/virtuálních serverů pro databázový monitoring je dva.

V případě, že se počet monitorovaných fyzických nebo virtuálních serverů rozšíří nad rámec výše uvedeného popisu zakoupené licence, je zákazník povinen zakoupit rozšíření stávající licence tak, aby pokrývala aktualizované potřeby zákazníka.

Odkaz na detailní licenční podmínky: xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/000XX0XX00000X000000000X000X0XXX?XxxxXxxxxxxx

xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/0X00XXX000X00X0X0000000X000X0X00?XxxxXxxxxxxx

Bezpečnostní monitoring (SIEM řešení)

Bezpečnostní monitoring jako součást řešení Bezpečný digitální archiv je licencován pomocí licenčního modelu EPS (Event per Second). Zakoupená licence pokrývá výkon bezpečnostního monitoringu na úrovni 100 EPS.

V případě, že počet událostí za sekundu v dlouhodobém průměru přesáhne hladinu 100 EPS, je nutné zakoupit rozšíření stávající licence tak, aby pokrývala aktualizované potřeby zákazníka, v opačném případě dojde ke ztrátě událostí sbíraných a vyhodnocovaným řešením bezpečnostního monitoringu.

Odkaz na detailní licenční podmínky: xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/X00000000X000XX0000000XX000X0000?XxxxXxxxxxxx

xxxx://xxx-00.xxx.xxx/xxxxxxxx/xxx/xxxxx.xxx/xxxxxxxx/000X000000XXX0X0000000XX000X0X00?XxxxXxxxxxxx

4.1.2Doplňující licenční podmínky

• Zákazník obdrží zdrojové kódy k částem řešení Bezpečnostní Digitální archiv, která byla vyvíjena přímo na míru zákazníkovi na základě jeho specifických požadavků

• Licence Bezpečný digitální archiv je využívána pro DR prostředí pouze v případě, že nedochází k jejímu využívání v prostředí produkčním a naopak. (lze používat pouze v případě nastavení Active/Passive. Pokud přejdeme do režimu Active/Active, je nutno rozšířit stávající licenci)

• Definice typů licencovaných uživatelů v rámci řešení Bezpečný digitální archiv

  • Standardní autorizovaného uživatel – V kontextu detailních licenčních podmínek je standardní autorizovaný uživatel synonymem pro pojem externí uživatel

  • Archivář – V kontextu detailních licenčních podmínek je standardní autorizovaný uživatel synonymem pro autorizovaného uživatele

4.2Mezinárodní smlouva IBM Passport Advantage

Odkaz na Mezinárodní smlouvu IBM Passport Advantage xxxx://xxxxxx.xxx.xxx.xxx/xxxxxxxx/xxxxxxxxxxxxxxxxx/XX_Xxxxxxxxxx/XX_Xxxxxxxxx_Xxxxx.xxx?_xxx0.000000000.0000000000.0000000000-0000000000.0000000000

5.Popis HW řešení

5.1Popis SW řešení – doplnění

V rámci této kapitoly je rozšířen popis sw řešení, který přímo souvisí s dodávanými hw technologiemi. Pro snazší orientaci v textu je popis rozdělen do jednotlivých bodů tak, aby přímo odkazovali na konkrétní položky v daných kapitolách.

5.1.1Dostupnost systému

Bod 63 - Systém je pro uživatele dostupný od 6:00 do 18:00, maximální výpadek je 1% během kalendářního roku.

Ano, navrhované řešení splňuje požadavky na dostupnost a maximální délku výpadek.

Bod 64 - Systém je provozován ve dvou geograficky oddělených lokalitách.

Ano, navrhované řešení je rozloženo do dvou geograficky oddělených lokalit. Úložiště je složeno ze čtyř nódů, kdy v každé lokalitě jsou umístěny dva nódy úložiště. Úložiště ukládá data také do dvou lokalit synchronním způsobem, tak aby výpadek lokality neznamenal nedostupnost a ztrátu dat.

Bod 65 - Archivní data, včetně dat brány, jsou replikována do záložní lokality. Požadovaný čas přechodu (RTO – Recovery Time Objective) provozování systému z hlavní (aktivní) lokality na záložní (pasivní) lokalitu je 12 hodin. Po této době musí záložní lokalita RPO (Recovery Point Objective) poskytovat plnou funkcionalitu a výkon jako lokalita hlavní.

Ano, navrhované řešení ukládá data do dvou lokalit synchronním způsobem, tak aby výpadek lokality neznamenal nedostupnost a ztrátu dat. Úložiště je složeno ze čtyř nódů, kdy v každé lokalitě jsou umístěny dva nódy úložiště schopné samostatného provozu pouze v jedné lokalitě. V případě nutnosti přechodu do záložní lokality je část úložiště ve druhé lokalitě manuálně převedan do aktivního režimu a umožňuje provoz a poskytuje plnou funkcionalitu a výkon jako lokalita hlavní.

Archivní data, včetně dat brány jsou umístěny v replikovaných a oddělených úložných prostorách a umožňují zajistit v případě výpadku primární lokality, přesun plné funkcionality do záložní lokality tak, že budou dodrženy požadavky na parametry pro RTO a RPO, které jsou kladeny na dodávané řešení v rámci Zadávací dokumenty. Detailní postupy řešení pro Disaster Recovery (viz čl.8 Přílohy č.1 Smlouvy) budou popsány a stanou se nedílnou součástí analýzy celého řešení.

5.1.2Bezpečnost databází

Bod 102 - Systém umožňuje pravidelné zálohování provozních databází s následnou možností plné obnovy systému z těchto záloh.

Ano, nabízené řešení umožňuje provádění online záloh provozních databází a jejich transakčních logů. Tyto zálohy databází následně umožňují provedení plné obnovy ze záloh.

Bod 103 - Zálohy provozních databází je možné ukládat v šifrované podobě bez dopadu na jejich použití pro obnovu systému.

Ano, zálohy provozních databází je možné šifrovat. Šifrování záloh, v předpokládaném nastavení kdy jsou klíče ukládány v zálohovacím řešení, nemá dopad na následnou obnovu.

5.1.3Úložiště archivních dat

Bod 66 - Zabezpečení dat před ztrátou – úložiště podporuje mechanismy minimalizující možnost ztráty dat. Uveďte jaké.

Ano, úložiště poskytuje následující mechanismy minimalizující možnost ztráty dat:

• Distribuce dat do dvou lokalit.

• Distribuce plnohodnotných replik mezi lokality + ochrana replik odpovídající dvěm paritám.

• Pravidelné provádění kontrol validnosti replik.

• Schopnost provedení opravného procesu kontrolující validnost replik a jejich synchronost.

• Asynchronní dodatečná kopie dat s možností nastavení expirace a nesmazatelnosti.

Bod 67 - Fyzické datové úložiště musí umožnit provádět zálohy uložených dat. Řešení musí provádět zálohy uložených dat pomocí jiné technologie než je použita pro samotné datové úložiště a tím vytvořit dodatečnou kopii a ochranu archivovanách. Popište, jak je požadavku dosaženo.

Ano, úložiště provádí asynchronní zálohu (dodatečnou repliku) dat. Zálohy jsou prováděny jinou technologií než první dvě kopie archivovaných dat. U záložní kopie je možné volit vlastní retence, počet udržovaných kopií a případně nesmazatelnost.

Bod 68 - Zabezpečení dat před změnou – úložiště garantuje, že uložená data nemohou být uživatelským zásahem smazána ani nijak pozměněna (retence). Výjimkou je archivářem naplánované a provedené vyřazení z archivu.

Ano, úložiště poskytuje možnost na úrovni uložených archivních dat do úložiště tyto data nastavovat do nezměnitelného a nesmazatelného stavu. Tyto data pak podléhají době nastavené retence po kterou nelze měnit ani mazat vybraná data. V případě potřeb archiváře, je možné tito politiky měnit a případně data mazat při vyřazení z archivu.

Bod 69 - Dlouhodobá rozšiřitelnost/upgrade – úložiště je možné bezproblémově rozšířit/upgradovat po celou dobu jeho provozu bez negativního vlivu na uložená data.

Ano, uložiště je možné rožířovat jak kapacitině tak výkonově. Rošíření a upgrade je možné provádět bez dopadu na provoz úložiště a uložená data.

Bod 70 - Úložiště je možné upgradovat za běhu bez výpadku provozu. Popište, jak je požadavku dosaženo.

Ano, úložiště je možné upgradovat za běhu bez výpadku. Kapacity je možné doplňovat pomocí rozšíření stávajících storage nódů / polí, případně jejich doplněním. V obou případech je bezvýpadkový průběh doplnění kapacit tento:

• Fyzické doplnění disků do stávajících storage nódů / polí.

• Fyzická instalace a zapojení dalšího storage nódu / pole.

• Detekce nově doplněných kapacit na úrovni úložiště.

• Definice disků do vybraného poolu úložiště pomocí CMD nebo GUI na úrovni úložiště.

• Možné provedení rozložení dat pomocí tzv. „restripe“ procesu.

Bod 71 - Podpora replikace a provoz ve více lokalitách – úložiště podporuje provoz ve více geograficky oddělených lokalitách. Data je možné automaticky synchronně replikovat mezi oběma lokalitami. Výpadek jakékoliv komponenty ve kterékoliv lokalitě nesmí způsobit nefunkčnost replikace a nedostupnost úložiště. Data musí být aktivně dostupná v obou lokalitách bez nutnosti provádění přechodu mezi lokalitami.

Ano, navrhované řešení ukládá data do dvou lokalit synchronním způsobem. Archivovaná data jsou poskytována aktivně v obou lokalitách. Je tedy možné s archivovanými data plnohodnotně pracovat ve kterékoliv lokalitě.

Úložiště je složeno ze čtyř nódů, kdy v každé lokalitě jsou umístěny dva nódy úložiště schopné samostatného provozu pouze v jedné lokalitě. Všechny komponenty úložiště jsou v obou lokalitách vysoce dostupné, tedy výpadek jakékoliv komponenty ve kterékoliv lokalitě nezpůsobuje dostupnost archivovaných dat.

Úložiště poskytuje data aktivně přes obě lokality bez nutnosti provádění přechodu mezi lokalitami. Úložiště je plně paralelní, tedy je možné současného provozu a práce s daty ze kterékoliv lokality.

Bod 72 - Organizace dat – data v úložišti je možné organizovat do logických prostorů s oddělenou správou.

Ano, úložiště poskytuje rozdělení celého úložiště na menší celky. Tyto celky mají následně samostatně definované:

• Prostory metadat.

• Politiky nesmazatelnosti a neměnosti.

• Přístupová práva uživatelů.

• Správu těchto celků přes GUI a CMD.

• Kvóty.

Bod 73 - Úložiště umožňuje šifrování uložených dat.

Ano, úložiště má možnost šifrování archivovaných dat a to jak u primárních / synchronních kopií, tak kopií asynchronních.

Bod 74 - Úložiště poskytuje služby komprese nebo deduplikace dat.

Ano, úložiště má možnost komprese a deduplikace archivovaných dat.

Bod 75 - S úložištěm lze komunikovat pomocí různých protokolů. Protokoly uveďte.

• K uloženým datům lze přistupovat minimálně pomocí protokolů NFS.

Ano, úložiště podporuje NFS v3 a v4.

• S úložištěm lze pracovat pomocí poskytnutého API. Uveďte formu API.

Ano, úložiště poskytuje REST API.

• Úložiště má nativní podporu ukládání metadat a práce s nimi.

Ano, úložiště umožňuje ukládání a práce s metadaty archivovaných dat – podpora systémových i uživatelských metadat.

5.2Technická specifikace HW CDA

Tato kapitola blíže popisuje jednotlivé body uvedené v rámci Přílohy č.3 Zadávací dokumentace. Popis technické specifikace HW řešení je dále rozložen na jednotlivé body tak, jak jsou uvedeny a formátovány v Příloze č.3.

Bod č. 1 - 2x objektové nebo souborové úložiště. 2 zařízení určená pro ukládání datových objektů převážně statického charakteru. Replikace musí být provedena při uložení synchronně do dvou zařízení.

Ano, úložiště je souborového charakteru s možným objektovým přístupem. Primární kopie jsou ukládány synchronně do dvou zařízení, dvou souborových úložišť schopných na sobě nezávisle pracovat. Primární kopie dat jsou ukládány synchronně do dvou geograficky oddělených lokalit.

Bod č. 2 - Požadovaná HW architektura - škálovatelné řešení s možností využití Capacity on Demand

Ano, v rámci řešení je nabízeno Capacity on Demand úložiště dle předpokládaných přírustků kapacity ze zadávací dokumentace ve výši 3 TB ročně.

Bod č. 3 - Intra-Cluster migrace

- objekty nebo soubory uložené v clusteru nejsou přenášeny po vnější datové síti

- veškeré zabezpečení objektů/souborů nebo jejich skupiny nesmí být narušeno

Ano, nabízené úložiště má vlastní redundantní datovou síť pro Intra-cluster komunikaci. Tato datová síť je používána pro intra-cluster komunikaci a pro replikaci dat. Pouze administrátor úložiště je schopen provádět správu úložiště a to vnitřními příkazy prováděnými také po oddělené síti úložiště. Úložiště zaručuje zabezpečení souborů.

Bod č. 4 - Požadovaná odolnost proti HW poruše

- současné selhání až 4 libovolných disků nebo 1 libovolný celý node - v nabízené konfiguraci

Ano, odolnost proti poruše až 4 libovolných disků je řešena synchronní replikou do dvou kopií dat, kdy každá kopie je dále chráněna dvojitou paritní ochranou. Je tedy možné aby došlo k výpadku libovolných 4 disků a přesto bude úložiště dostupné.

Výpadek jednoho nódu neovlivňuje dostupnost úložiště. Úložiště je v každé z lokalit odolné proti výpadku nódu bez dopadu na dostupnost úložiště.

- možnost zvýšení HW redundance prostým zvýšením počtu node v clusteru

Ano, v případě potřeby je možné navýšit počet replik doplněním nódů případně storage nódů / polí v klastru a tím i redundanci dat. Úložiště umožňuje navýšit počet synchronních replik na 3 a navíc umožňuje navýšit počet asynchronních replik.

- selhání v jedné lokalitě nesmí mít vliv na funkčnost a dostupnost replikovaných dat v zařízení v lokalitě druhé (vybrané datové oblasti - tenants -zařízení se replikují mezi sebou)

Ano, navrhované řešení ukládá data do dvou lokalit synchronním způsobem. Archivovaná data jsou poskytována aktivně v obou lokalitách. Je tedy možné s archivovanými daty plnohodnotně pracovat ve kterékoliv lokalitě.

Úložiště je složeno ze čtyř nódů, kdy v každé lokalitě jsou umístěny dva nódy úložiště schopné samostatného provozu pouze v jedné lokalitě. Všechny komponenty úložiště jsou v obou lokalitách vysoce dostupné, tedy výpadek jakékoliv komponenty ve kterékoliv lokalitě nezpůsobuje dostupnost archivovaných dat. Vybrané datové oblasti jsou synchronně replikovány mezi lokalitami.

Bod č. 5 - Počáteční konfigurace musí obsahovat minimálně

- 5x identických cluster node v případě objektové úložiště, 3x identických cluster node v případě souborového úložiště

Ano, úložiště obsahuje čtyři nódy klastru rozložené vždy po dovu do dvou geograficky oddělených lokalit.

- disky pro data o kapacitě min. 1TB, počet bude určen dodavatelem, tak aby bylo zajištěna použitelá kapacita 35TB

Ano, úložiště má kapacity složeny z disků 8TB 7.2K NL-SAS. Čistá kapacita po paritní ochraně poskytuje použitelnou kapacitu 35TB.

- síťová rozhraní podle specifikace viz níže

Ano, síťová rozhraní jsou upřesněna v bodě 8.

- redundantní napájení 230V

Ano, všechny prvky mají redundantní napajení 230V.

- servis jednotlivých cluster node bez použití nářadí

Ano, všechny nódy klastru je možné servisovat bez použití nářadí.

Bod č. 6 - Rack s následujícím vybavením

- standardní datový rack pro servery podle doporučení výrobce

- redundantní napájecí rozvody

- redundantní aktivní síťové prvky

- cable management řešení

Ano, součástí nabídky je rack do každé lokality splňující požadavky na napájení, požadované síťové prvky a ramena pro správu kabelů.

Bod č. 7 - Kapacitní nároky na datové centrum (RACK, #U), konektivitu (počet a kapacita portů), napájení a spotřebu energie nabízené startovací konfigurace.

Řešení má tyto nároky na datové centrum:

• 1. lokalita

  • 26 U rackových jednotek

  • 3906W

  • 36x C13/C14 PDU zásuvky

• 2. lokalita

  • 26 U rackových jednotek

  • 4004 W

  • 34x C13/C14 PDU zásuvky

Zapojení řešení do prostředí zákazníka předpokládme pomocí firewallů v každé lokalitě 2x 1Gb Ethernet.

Bod č. 8 - Vnější konektivita objektového úložiště - minimální

- 4x 10Gbit/s Ethernet porty, s možností rozšíření jejich počtu adekvátně s kapacitou a výkonem

- Rozhraní - SFP+ moduly, musí být součástí nabídky

Ano, vnější konektivita úložiště je realizována v každé lokalitě pomocí 4x 10Gbit/s Ethernet portů. Součástí nabídky jsou SFP+ moduly případně kompatibilní DAC kabeláž.

Bod č. 9 - Rozšiřitelnost vnější konektivity objektového úložiště bez nutnosti zvýšení počtu node v clusteru

- celkem alespoň 8x 10Gbit a / nebo 25Gbit/s (celkem alespoň 8 portů, v kombinaci 10Gb a 25Gb Ethernet)

- celkem alespoň 4x 100Gbit/s (celkem alespoň 8x 10Gb/25Gb a 4x 100Gb)

Rozšíření formou doplnění příslušného typu rozhraní, za provozu.

Ano, úložiště umožňuje výše uvedenou rozšiřitelnost vnější konektivity. Rozšíření je možné provést za provozu.

Bod č.10 - Interní propojení všech cluster node redundantní sítí s kapacitou - minimálně - 10Gbit/s Ethernet

Potřebná redundantní síťová infrastruktura pro min. 16 cluster node musí být součástí nabízeného HW řešení

Propojení mezi cluster node a vnější konektivita jsou fyzicky oddělené segmenty sítě

Ano, nabízené úložiště má vlastní redundantní datovou síť o rychlosti 10Gb/s pro Intra-cluster komunikaci.

Aktivní prvky realizující interní datovou síť poskytují možnost zapojení až 20 nódů klastru v obou lokalitách.

Propojení nódů klastru a vnější konektivita jsou fyzicky odděleny.

Bod č.11 - Minimální nabízená kapacita

- 60TB raw

- 35TB dostupné v provozním typu zajištění dat s garancí odolnosti proti selhání

Ano, nabízené úložiště nabízí pro každou z kopií dat min. 60 TB raw kapacit a min. 35 TB dostupné kapacity. Dostupná kapacita 35TB je uvažována po zajištění paritní ochrany a zaručení vysoké dostupnosti.

Do kapacitních výpočtů není zahrnuta komprese, deduplikace, tenký provisioning a další nástroje pro datové redukce.

Bod č.12 – Možnost rozšíření na minimálně na 10-tinásobek minimální startovací čisté kapacity.

Uchazeč popíše způsob jakým zadavatel může čerpat kapacitu úložtě dle rostoucích potřeb.

Uvede cenu za minimální jednotku (min 10 TB čisté kapacity) a dobu nutnou k navýšení kapacity (max 1 týden).

Ano, úložiště je rozšířitelné minimálně na 10-tinásobek startovací čisté kapacity.

Možné způsoby rozšíření jsou uvedeny v odpovědi na bod „Bod 70 - Úložiště je možné upgradovat za běhu bez výpadku provozu.“ této nabídky.

Cena navýšení kapacity o 10 TB je 62.000 Kč. Toto rozšíření bude uplatněno po vyčerpání Capacity on Demand, která je daná odhadem rozšíření po dobu projektu.

Bod č.13 – Startovací minimální počet uložených objektů nebo souborů MIN 1,8 milionu

Ano, úložiště splňuje uvedenou minimální hodnotu. Celkový počet je ovlivněn vlastností archivovanch dat a ukládaných metadat, lze však předpokládat možnost uložení vyšších desítek milionů souborů.

Bod č.14 – Maximální možná kapacita počtu uložených objektů nebo souborů MIN 1 miliarda

Ano, úložiště umožňuje uložení maximálně 2^64 souborů.

Bod č.15 – Minimální požadovaná propustnost pro práci s objekty.

100KB object size

Read Objects/s 3000

Write Objects/s 600

100MB object size

Read MB/s 1300

Write MB/s 200

Ano, souborové úložiště poskytuje požadovaný výkon.

Bod č.16 – Součástí dodávky budou všechny licence potřebné pro provoz a správu řešení

Ano, součástí řešení jsou všechny licence potřebné pro provoz a správu řešení. Za infrastrukturní část se jedná o souborový systém a SW pro zálohování. Dále pak nezbytné operační systémy.

Bod č.17 – Architektura úložiště je speciálně navržena pro ukládání velkého objemu datových objektů na velmi dlouhou dobu.

Musí umožňovat garanci jedinečnosti, nezměnitelnosti a retence ukládaných dat.

Pro budoucí rozvoj pak jejich snadný přenos mezi různými typy cluster node nebo HW platforem bez narušení autenticity.

Ano, úložiště je navrženo jako vysoce škálovatelné s limity v řádu YB. Úložiště poskytuje možnost na úrovni uložených archivních dat do úložiště tyto data nastavovat do nezměnitelného a nesmazatelného stavu. Tyto data pak podléhají době nastavené retence po kterou nelze měnit ani mazat vybraná data.

Klastr úložiště poskytuj snadný bezvýpadkový přenos dat mezi jinými typy klastr nódů a HW platformy bez narušení autenticity.

Bod č.18 – Multitenancy na úrovni dat

Ano, úložiště poskytuje rozdělení na více logických celků. Je možné tyto celky fyzicky oddělit a pracovat s funkcionalitami úložiště odděleně.

Bod č.19 – Licence pro uložení dat v režimu plné ochrany

Ano, licence pokrývá všechny funkcionality úložiště a pokrývá uložení dat v režimu plné ochrany.

Bod č.20 – Pro běžný porovoz nebude umožněn přístup k privilegovanému administrátoru.

- popis zajištění bezpečnosti přístupu privilegovaného administrátora

Ano, pro běžný provoz může být znemožněn přístup k privilegovanému účtu administrátora. Tento přístup může být v běžném provozu nepovolen, je však možné ho na vyžádání poskytnout například pro účely řešení technických problémů. Je možné nastavit dvoufaktorovu autentikaci privilegovanému účtu.

Bod č.21 – Nativní ochrana dat dle nabízeného řešení

Ano, úložiště nabízí nativní možnost ochrany dat synchronní replikací, asynchronní replikací a využití dvojité (případně trojité) paritní ochrany dat. Nabízené řešení kombinuje tyto ochrany dat:

• Dvě synchronní kopie dat.

• Každá synchronní kopie dat navíc chráněna dvojitou paritní ochranou.

• Dodatečná asynchronní kopie.

• Asynchronní kopie navíc chráněna dvojitou paritní ochranou.

Bod č.22 – Jestliže je použito objektový typ úložiště - zajistěte následující funkcionalitu:

Nativní vyhledávání v metadatech uložených objektů bez nutnosti provozování externí databáze přímo jako vlastnost objektového úložiště.

Musí umožnit doplňovat vlastní informace k uloženým objektům v plně programovatelných metadatech a následně v nich vyhledávat.

Vyhledávací algoritmus v metadatech nesmí být omezen počtem objektů

Nabízené řešení je postaveno na souborovém úložišti.

Bod č.23 – Možnost detailního sledování provozu prostřednictvím SNMP

Ano, úložiště poskytuje SNMP dohled a MIB.

Bod č.24 – Data at Rest Encryption

Ano, úložiště podporuje „Data at Rest“ šifrování .

Bod č.25 – Replikace objektů nebo souborů mezi dodanými úložišti, asynchronní.

Ano, viz odpověď na bod „Bod č.21 – Nativní ochrana dat dle nabízeného řešení“.

V případě potřeby musí být možno objekty nebo soubory asycnchronně replikovat do páskových úložišť

Ano, úložiště poskytuje možnost nativní asynchronní repliky do páskového úložiště.

Uchazeč popíše způsob přístupu k datům v situacích výpadku lokality z pohledu aplikace.

- , popis řešení, dodavatel popíše způsob přístupu k datům v situacích výpadku lokality z pohledu aplikace.

Navrhované řešení ukládá data do dvou lokalit synchronním způsobem. Archivovaná data jsou poskytována aktivně v obou lokalitách. Je tedy možné s archivovanými data plnohodnotně pracovat ve kterékoliv lokalitě.

Navrhované řešení ukládá data do dvou lokalit synchronním způsobem, tak aby výpadek lokality neznamenal nedostupnost a ztrátu dat. Úložiště je složeno ze čtyř nódů, kdy v každé lokalitě jsou umístěny dva nódy úložiště schopné samostatného provozu pouze v jedné lokalitě. V případě nutnosti přechodu do záložní lokality je část úložiště ve druhé lokalitě manuálně převedan do aktivního režimu a umožňuje provoz a poskytuje plnou funkcionalitu a výkon jako lokalita hlavní.

Úložiště poskytuje data aktivně přes obě lokality bez nutnosti provádění přechodu mezi lokalitami. Úložiště je plně paralelní, tedy je možné současného provozu a práce s daty ze kterékoliv lokality.

Bod č.26 – Audit pro všechny operace, které jsou s daty a úložištěm prováděny

Ano, úložiště umožňuje zapnout auditní logování operací nad úložištěm.

Bod č.27 – Možnost obousměrné georeplikace ve dvou nebo více lokalitách se zachováním single name space a možností konkurenčního přístupu k jedněm datům z více lokalit.

Ano, úložiště podporuje replikaci až ve třech lokalitách a zachovává jednotný jmenný prostor. Přístup k datům je paralelní a aktivní ze všech lokalit.

Automatický failover archivační aplikace ČP mezi lokalitami v případku nedostupnosti.

Ano, viz. odpovědi na body „Bod č.25 – Replikace objektů nebo souborů mezi dodanými úložišti“, "Bod č. 4 - Požadovaná odolnost proti HW poruše" a "Bod 71 - Podpora replikace a provoz ve více lokalitách".

Data jsou uložena na diskovém prostoru, který odpovídá požadavkům na podporu replikací, georeplikací. Součástí navrhovaného prostředí je i nasazení a dodávka technologie zajišťující automatický failover v případě nedostupnosti. Tento failover je řešen kombinací dodávaného hardware a software s vyvinutou částí na úrovni skriptů, konfigurací a postupů nasazení.

Bod č.28 – Podporované protokoly objektové úložiště:

- S3 včetně dodatečných rozšíření, jako je Atomic Append, Byte Range Updates a ACLS (data uložená v S3 musí být současně čitelná pro HDFS, NFS a Swift)

- HDFS verze 2.7 (data uložená v HDFS musí být současně čitelná pro S3, NFS a Swift)

- Swift V2 API, včetně Swift / Keystone v3 Authentication (data uložená ve Swift musí být současně čitelná pro HDFS, NFS a S3)

- NFS v3 (data uložená ve NFS musí být současně čitelná pro HDFS, Swift a S3)

- CIFS výhodou - uvést řešení

- REST API

Je nabízeno souborové úložiště.

Podporované protokoly souborové úložiště:

- NFS v3

- CIFS výhodou - uvést řešení

Ano, úložiště podporuje protokoly NFSv3, NFSv4 a SMB/CIFS.

Bod č.29 – Pro objektové úložiště:

Dostupnost SDK a komunikačních interface (API) pro tyto platformy (= výrobcem OS podporované verze)

Windows, CentOS, RedHat, SuSe, Solaris

- ANO/NE, minimálně tyto uvedené verze

ANO/NE, uvést výčet nebo kompatibility matici

Je nabízeno souborové úložiště.

Bod č.30 – Vysoká dostupnost – 99% , systém nesmí obsahovat SPOF

Ano, nabízené úložiště poskytuje vysokou dostupnost 99% a neobsahuje SPOF.

Bod č.31 – Online konfigurace a zcela transparentní škálovatelnost a výměna HW (bez jakéhokoli dopadu na provoz – přepínaní záložní cesty z pohledu serveru, nutnost restartu OS, atd.)

Ano, úložiště umožňuje konfiguraci za chodu a online a transparentní škálovatelnost a výměnu HW.

Bod č.32 – Rozšířená záruka na 4 roky v režimu NBD response.

Ano, součástí řešení je rozšířená záruka v režmu NDB response na 4 roky.

Bod č.33 – Součástí záručních i servisních podmínek a služeb je dodávka a provedení upgrade firmware po celou dobu platnosti smlouvy

Ano, součástí řešení je i možnost a pravidelné provádění upgradu firmware.

Bod č.34 – Vadné datové nosiče zůstávají v majetku zadavatele

Ano, součástí je služba nevracení disků.

Bod č.35 – Zapojení do call-home systému dodavatele

Ano, úložiště bude integrováno pomocí call-home do systému dodavatele / výrobce.

6.HelpDesk GC System

Technické řešení HelpDesk GC System (dále HD) je dostupné na webové URL xxx. Požadavky do HD je možno zadávat přes webový formulář (viz Obrázek 3 - Formulář pro zadání nového požadavku do HD), pomocí strukturovaného emailu zaslaného na hxxx a nebo telefonicky přes operátora HD.

Po přijetí tiketu je tento zpracován operátorem HD a předán řešitelské skupině dodavatele k vyřešení. Součástí zadání tiketu je i priorita (závažnost) tiketu, na základě které je v systému automaticky hlídáno SLA.

Při každé změně (dotaz na doplňující informace, informace o vyřešení apod.) v tiketu je zadavatel i řešitel emailem informován o provedené změně.

Obrázek 1 - Přihlašovací stránka HD

Obrázek 2 - Přehled zadaných požadavků v HD

Obrázek 3 - Formulář pro zadání nového požadavku do HD

Příloha č. 5 Smlouvy: Realizační tým

Xxxxx a příjmení	Pracovní pozice v Realizačním týmu
xxx	Projektový manažer
xxx	IT Architekt
xxx	DB specialista
xxx	Specialista bezpečnosti
xxx	Systémový specialista pro oblast datových úložišť
xxx	Systémový specialista pro oblast datových úložišť

Příloha č. 6 Smlouvy: Všeobecné obchodní podmínky Objednatele

Strana 129 (celkem 129)