Věc: Vysvětlení zadávací dokumentace č. 2, 3, 4 a 5

Naše zn. 35522/2022-SŽ-GŘ-O8

Vyřizuje P. Xxxxxxxx

Datum 17. 5. 2022

Sektorová nadlimitní veřejná zakázka dle § 56 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“), na dodávky s názvem:

„Centrální Log Management“

Správa železnic, státní organizace (dále jen „Zadavatel“), obdržela dne 12. 5. 2022 v 9:36 hodin žádost o vysvětlení zadávací dokumentace č. 2, dne 12. 5. 2022 v 10:17 hodin žádost

o vysvětlení zadávací dokumentace č. 3, dne 12. 5. 2022 v 15:36 hodin žádost o vysvětlení

zadávací dokumentace č. 4 a dne 12. 5. 2022 v 18:28 hodin žádost o vysvětlení zadávací

dokumentace č. 5.

Zadavatel na doručené žádosti o vysvětlení zadávací dokumentace č. 2, 3, 4 a 5 k veřejné zakázce odpovídá následovně:

Dotaz č. 1

Zadavatel požaduje u referenční zakázky č.1 minimální objem logů zpracovávaných systémem na úrovni 9TB. Z našich zkušeností vyplývá, že běžná velikost jednoho řádku logu se pohybuje cca 0,5KB na řádek. Při požadavku na takový objem denně uložených dat to znamená, že by referenční zakázka musela sbírat řádově jednotky statisíců EPS (Event per second) v denním průměru. Může zadavatel potvrdit, zda platí uvedený parametr u referenční zakázky a nejedná se o chybu? Reference na takovýto denní objem logů se pravděpodobně v rámci České republiky nevyskytuje. Případně zda může dodavatel definovat požadavek na referenční hodnotu v EPS.

Odpověď č. 1

Zadavatel nejprve uvádí, že očekávaný objem logů a EPS v kapitole 4.1 Technické přílohy je maximálním odhadem vycházejícím z velkého cílového počtu zdrojů logů a očekávaného množství událostí na různých kategoriích zdrojů. Přesnější odhad EPS a detailní odhad objemu logů nemá Zadavatel k dispozici a očekává, že bude součástí výstupů analýzy podle kapitoly 6.1 Technické přílohy.

Zadavatel se rozhodl netrvat na podmínce minimálního objemu logů, která je uvedena u Významné zakázky č. 1 a č. 2. Zadavatel tedy provádí změnu zadávací dokumentace a vypouští (bez náhrady) z textu Zadávací dokumentace tento údaj, tzn. že:

- u Významné zakázky č. 1 je odstraněn text uvedený u třetí odrážky „minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 9 TB/den“,

- u Významné zakázky č. 2 je odstraněn text uvedený u třetí odrážky „minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 1 TB/den“.

Pokud jde o ostatní podmínky uvedené u Významné zakázky č. 1 a č. 2, tak tyto zůstávají bez změny.

1/10

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČO: 709 94 234 DIČ: CZ 709 94 234

xxx.xxxxxxxxxxxxxx.xx

Zadavatel současně uvádí, že na profilu zadavatele je společně s tímto vysvětlením zadávací dokumentace uveřejněna upravená Zadávací dokumentace a Příloha č. 6 Zadávací dokumentace s názvem “Čestné prohlášení ke splnění technické kvalifikace – seznam významných dodávek”, v nichž je tato změna promítnuta.

Dotaz č. 2

U všech referenčních zakázek zadavatel specifikuje parametry a vyžaduje podmínku, že musí být tyto parametry splňovat při uvedení pro provozu. Podobné systémy se dodávají postupně v dílčích celcích a postupně rostou v aktuální stav, který se může od doby uvedení do provozu lišit násobně. Akceptuje dodavatel referenční zakázky, které splňují kritéria v aktuálním stavu, ale nikoliv při uvedení do provozu?

Odpověď č. 2

Zadavatel se rozhodl provést změnu zadávací dokumentace a umožnit dodavatelům pro účely prokázání technické kvalifikace doložit významné zakázky, které budou splňovat podmínky vyžadované zadávací dokumentací nejpozději k okamžiku uveřejnění zadávací dokumentace.

Vzhledem k tomu Zadavatel mění text zadávací dokumentace, a to následovně.

- u Významné zakázky č. 1 je nyní (mimo jiné) uvedeno, že „minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu je: 600“ a “minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být v okamžiku předání do provozu: 3”.

Tento text se u Významné zakázky č. 1 mění a nové znění těchto dvou požadavků je následující: „minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace je: 600“ a “minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3“,

- u Významné zakázky č. 2 je nyní (mimo jiné) uvedeno, že „minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu je: 600“.

Tento text se u Významné zakázky č. 2 mění a nové znění tohoto požadavku je následující: „minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace je: 600“.

Dotaz č. 3

V technické specifikaci, bod F4 je uveden požadavek Funkcionalita pro udělení časového razítka a digitálního podpisu logů musí být realizována prostřednictvím interní certifikační autority. Může zadavatel přesněji specifikovat tento požadavek, jak by měla tato funkcionalita fungovat? jaké časové razítko je myšleno? Jaké logy by se měli digitálně podepisovat a jakým způsobem, zároveň prosíme uvést, jaké možnosti jsou v rámci integrace s interní CA

Odpověď č. 3

Zadavatel očekává, že dodavatelé sami navrhnou způsob využití časových razítek a elektronických podpisů pro ochranu integrity a prokazatelnosti ukládaných logů v souladu s platnou legislativou.

Zadavatel se v této souvislosti rozhodl doplnit informace uvedené v Příloze č. 2 Zadávací dokumentace s názvem “Popis aplikací a prostředí”. Upravená Příloha č. 2 Zadávací dokumentace bude v souladu s § 98 odst. 2 ZZVZ poskytnuta dodavatelům, kteří podepsali Dohodu o ochraně

důvěrných informací, resp. kteří požádali Xxxxxxxxxx o poskytnutí příslušné části Zadávací dokumentace.

Dotaz č. 4

V technické specifikaci, bod F6 je uvedena možnost poskytnout testovací prostředí ve virtuálním prostředí, znamená to tedy, že HW prostředky, včetně virtualizace, zajistí zadavatel?

Odpověď č. 4

Zadavatel trvá na dikci Technické přílohy, která požaduje, aby dodavatel v rámci dodávky řešení vybudoval všechna prostředí včetně případných virtualizačních platforem a testovacích instancí.

Dotaz č. 5

V technické specifikaci, bod A4 zadavatel předpokládá možnosti využití virtualizace. Může zadavatel přesně specifikovat pro jaké komponenty (dle bodu A1) očekává dodávku včetně HW a pro jaké je možné použít virtuální prostředí zadavatele?

Odpověď č. 5

Zadavatel trvá na dikci Technické přílohy, která požaduje, aby dodavatel sám navrhnul rozsah a způsob virtualizace komponent řešení v souladu s požadavky a následně vybudoval potřebné virtualizační platformy včetně dodávky HW.

Dotaz č. 6

Nedošlo u zadavatele k záměně významných zakázek číslo 1 a 2, kdy u zakázky s nižším finančním objemem požadujete násobně vyšší objem zpracovávaných logů a u zakázky s cenou výrazně vyšší požadujete jen zlomek?

Odpověď č. 6

Zadavatel uvádí, že se rozhodl netrvat na podmínce minimálního objemu logů, která je uvedena u Významné zakázky č. 1 a č. 2. Zadavatel tedy provádí změnu zadávací dokumentace a vypouští (bez náhrady) z textu zadávací dokumentace tento údaj, tzn. že:

- u Významné zakázky č. 1 je odstraněn text uvedený u třetí odrážky „minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 9 TB/den“,

- u Významné zakázky č. 2 je odstraněn text uvedený u třetí odrážky „minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 1 TB/den“.

Pokud jde o ostatní podmínky uvedené u Významné zakázky č. 1 a č. 2, tak tyto zůstávají bez změny.

Dotaz č. 7

Proč ve významné zakázce číslo 3 nemohou být součástí ceny licence a u předchozích významných zakázek 1 a 2 ano? Licence jsou pochopitelné a nutné k naplnění tohoto finančního objemu požadovaného v referencích.

Odpověď č. 7

Cílem Zadavatele je, aby dodavatelé Významnou zakázkou č. 3 prokázali svoji schopnost poskytovat konzultační služby v oblasti kybernetické bezpečnosti i mimo dodávky technologických řešení.

Zadavatel trvá na podmínkách, které jsou uvedeny v zadávací dokumentaci u Významné zakázky č. 3.

Dotaz č. 8

Vzhledem k abnormálním požadavkům na reference, trvá zadavatel na podmínce, že prokazovaní členové realizačního týmu musí teoreticky být již členy týmu z referenčních zakázek, jelikož jinak nenaplní podmínky uvedené v ZD?

Odpověď č. 8

Zadavatel nejprve uvádí, že v Zadávací dokumentace není stanoven (uveden) požadavek, aby referenční zakázky uváděné členy realizačního týmu byly shodné s referenčními zakázka (tj. významnými zakázkami) dodavatele.

Zadavatel se rozhodl netrvat na podmínce minimálního objemu zpracovávaných logů, která je uvedena u referenčních zakázek všech členů realizačního týmu a současně se Zadavatel rozhodl umožnit členům realizačního týmu pro účely prokázání technické kvalifikace doložit referenční zakázky, které budou splňovat podmínky vyžadované zadávací dokumentaci nejpozději k okamžiku uveřejnění zadávací dokumentace. Pokud jde o další požadavky Zadavatele uvedené v zadávací dokumentace u členů realizačního týmu, tak tyto zůstávají bez změny.

Vzhledem k uvedenému Zadavatel mění text zadávací dokumentace, a to následovně.

Senior Architekt CLM

− Aktuální znění požadavku

“má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den; minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být v okamžiku předání do provozu: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den; minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu byl: 600”.

− Nové znění požadavku

dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600”.

Senior System Engineer

− Aktuální znění požadavku

nebo

− Nové znění požadavku

“má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600”.

Senior Analytik

− Aktuální znění požadavku

“má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den; minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být v okamžiku předání do provozu: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den; minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu byl: 600

nebo

má zkušenost s alespoň 1 projektem na realizaci služeb v oblasti kybernetické bezpečnosti a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH, s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent, SW licencí a podpory po předání do provozu.”

− Nové znění požadavku

“má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600

nebo

Projektový manažer

− Aktuální znění požadavku

nebo

− Nové znění požadavku

“má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu

činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600

nebo

Zadavatel současně uvádí, že na profilu zadavatele je společně s tímto vysvětlením zadávací dokumentace uveřejněna upravená Zadávací dokumentace a Příloha č. 6 Zadávací dokumentace s názvem “Čestné prohlášení ke splnění technické kvalifikace – seznam členů realizačního týmu”, v nichž je tato změna promítnuta.

Dotaz č. 9

Je si zadavatel vědom rozsahu požadavků, které jsou definovány pouze pro funkce Log management systému? Xxxxxxx konstatuje, že tento rozsah je z jeho pohledu extrémně nadstandardní a vylučuje z realizace české výrobce tohoto systému, neboť reference tohoto rozsahu čeští výrobci nemají a striktně poukazuje na nadnárodní výrobce.

Odpověď č. 9

Zadavatel potvrzuje, že požadavky uvedené v zadávací dokumentaci včetně požadavků na funkce log management systému jsou stanovené odpovědně podle potřeb Zadavatele a podle podmínek provozu jeho prostředí IT a OT.

Dotaz č. 10

Dodavatel by rád upozornil Xxxxxxxxxx, že je jakožto povinná osoba povinný postupovat v souladu se zákonem 181/2014 Sb., ve znění pozdější aktualizace, dle §3, odst. j vyhlášky 82/2018 Sb., podle kterého je povinný řídit zdroje systému. V zadávací dokumentaci však není nikde přesně specifikováno. Bez upřesnění konkrétních požadavků nelze zdroje systému řídit. Žádáme proto Zadavatele, aby konkrétní požadavky upřesnil.

Odpověď č. 10

Zadavatel potvrzuje, že v souladu s požadavky dle § 3 písm. j) vyhlášky č. 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), ve znění pozdějších předpisů, řídí zdroje a zaznamenává informace

o SŘBI, jak je upraveno v jeho interních předpisech. Požadavky zadávací dokumentace na dodávku CLM byly stanoveny odpovídajícím způsobem v souladu s interními předpisy Zadavatele.

Dotaz č. 11

V kapitole 4.4 Zadávací dokumentace je uvedena tabulka s přehledem Bezpečnostních technologií. Objem logů není nikde uveden. Dodavatel požaduje doplnění tohoto údaje. Bez něj není možno navrhnout vyhovující řešení.

Odpověď č. 11

Zadavatel odkazuje na údaje uvedené v kapitole 4.1 Souhrnné objemy logů v Technické příloze, které považuje za postačující pro předběžné určení řešení. Zadavatel očekává, že detailní údaje k jednotlivým technologiím budou předmětem Analýzy zpracované dodavatelem podle kapitoly

6.1 Technické přílohy.

Dotaz č. 12

V kap. 3.2.3.1 (ISOŘ CDS) je popsáno, že logy jsou dostupné v souboru. Zadavatel dále požaduje bezagentové řešení dle specifikace A3. Dodavatel požaduje po Zadavateli upřesnění, jakou formou bude posílat logy do CLM. Bez této technické specifikace nelze navrhnout řešení tak, aby Dodavatel vyhověl čl. 4.1 Zadávací dokumentace, a dále mohl naplnit požadavky dle č. 6.2.1. a celkově navrhnout bezpečnostní opatření dle §5 zákona 181/2014 Sb., ve znění pozdější aktualizace.

Odpověď č. 12

Zadavatel očekává, že způsoby doručování logů z jejich zdrojů do centrálního úložiště navrhne dodavatel a budou součástí technického návrhu, který Zadavatel poptává jako součást dodávky podle kapitoly 6.2 Technické přílohy. Je tedy na dodavateli, aby v rámci analýzy podle kapitoly

6.1 Technické přílohy posoudil dostupné prostředky a přenosové protokoly a možnosti jejich použití pro naplnění všech požadavků na řešení.

Dotaz č. 13

Ve funkčním požadavku A12 Zadavatel požaduje zpracování přijatých logů do 5 vteřin. požaduje doplnění kritického parametru, jímž je specifikace EPS ve „špičce“. Bez tohoto parametru Dodavatel není schopen navrhnout a dodat řešení tak, aby Dodavatel vyhověl čl. 4.1 Zadávací dokumentace, a dále mohl naplnit požadavky dle č. 6.2.1. a celkově navrhnout bezpečnostní opatření dle §5 zákona 181/2014 Sb., ve znění pozdější aktualizace.

Odpověď č. 13

Zadavatel uvedený dotaz chápe tak, že je to dodavatel, kdo požaduje doplnění parametru EPS ve „špičce“.

Zadavatel upřesňuje požadavek A12 kapitoly 5.2 Technické přílohy tak, že doplňuje za text „Sběr a vyhodnocení přijatých logů musí probíhat v reálném čase s maximálním zpožděním 5 sekund“ tento odstavec „Uvedené zpoždění musí systém dodržet i při krátkodobém nárůstu toku logů na třicetinásobek toků uvedených v kapitole 4“.

Zadavatel očekává, že schopnost řešení absorbovat zvýšené toky logů z jednotlivých typů zdrojů bude vyhodnocena v technickém návrhu, který předloží dodavatel.

Zadavatel uvádí, že na profilu zadavatele je společně s tímto vysvětlením zadávací dokumentace uveřejněna upravená Příloha č. 1 Zadávací dokumentace s názvem “Technická příloha”, v níž je uvedené doplnění promítnuto.

Závěr

Zadavatel provedl změny zadávací dokumentace dle § 99 odst. 2 ZZVZ, přičemž provedené změny mohou rozšířit okruh možných účastníků zadávacího řízení. S ohledem na tuto skutečnosti přistupuje Zadavatel k prodloužení lhůty pro podání nabídek o celou její původní délku.

Lhůta pro podání nabídek je nově stanovena do 23. 6. 2022 v 10:00 hodin.

Příloha č. 1 – Zadávací dokumentace

Příloha č. 2 – Příloha č. 1 Zadávací dokumentace (jedná se rovněž o přílohu č. 1 Smlouvy) – Technická příloha

Příloha č. 3 – Příloha č. 6 Zadávací dokumentace – Čestné prohlášení ke splnění technické kvalifikace (seznam význam. zakázek) Čestné prohlášení ke splnění technické kvalifikace (seznam realizačního týmu)

V Praze dne 17. 5. 2022

.......................................

Xxx. Xxxxx Xxxxxx

ředitel Správy železničních informačních technologií

Naše zn. 26302/2022-SŽ-GŘ-O8

Vyřizuje Xxxxx Xxxxxxxx

Datum 17. 5. 2022

ZADÁVACÍ DOKUMENTACE

k nadlimitní sektorové veřejné zakázce na dodávky zadávané v otevřeném řízení podle § 56 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen

„ZZVZ“), s názvem

„Centrální Log Management“

(dále jen „Zadávací dokumentace“)

Identifikační údaje Zadavatele a osoby zastupující Zadavatele:

Název: Správa železnic, státní organizace

Sídlo: Dlážděná 1003/7, Praha 1 – Nové Město, PSČ 110 00 IČO: 709 94 234

DIČ: CZ 70994234

Zapsaný v obchodním rejstříku vedeném Městským soudem v Praze oodílu A, vložce 48384

Zastoupen: Bc. Xxxxx Xxxxxxxx, MBA, generálním ředitelem Profil Zadavatele: xxxxx://xxxxxxx.xxxxxxxxxxxxxx.xx/

1/29

Správa železnic, státní organizace

zapsána v obchodním rejstříku vedeném Městským soudem v Praze, spisová značka A 48384

Sídlo: Dlážděná 1003/7, 110 00 Praha 1

IČ: 709 94 234 DIČ: CZ 709 94 234

xxx.xxxxxxxxxxxxxx.xx

1. Druh veřejné zakázky a zadávacího řízení:

1.1. Hlavní předmět veřejné zakázky ve smyslu § 15 ZZVZ odpovídá veřejné zakázce na dodávky.

1.2. Zadavatel zadává veřejnou zakázku v souvislosti s výkonem své relevantní činnosti ve smyslu § 153 odst. 1. písm. f) ZZVZ. Jedná se proto o sektorovou veřejnou zakázku.

1.3. Xxxxxxx zakázka je v souladu s § 56 a násl. ZZVZ zadávána jako nadlimitní sektorová veřejná zakázka na dodávky v otevřeném řízení ve smyslu § 3 písm. b) ZZVZ.

2. Účel veřejné zakázky:

Správa železnic, státní organizace jako subjekt povinný v souladu s ustanoveními § 3 písm. c), d), ve znění § 2 písm. e) zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále také „ZoKB“), musí provádět bezpečnostní opatření (viz § 5 ZoKB) v rozsahu nezbytném pro zajištění kybernetické bezpečnosti informačního systému kritické informační infrastruktury, komunikačního systému kritické informační infrastruktury. Konsolidace sběru provozních a bezpečnostních logů ze systémů a sítě Zadavatele je jedním ze způsobů, jak naplnit tyto povinnosti.

3. Předpokládaná hodnota

3.1. Předpokládaná hodnota veřejné zakázky činí 98.000.000, - Kč bez DPH. Zadavatel stanovil předpokládanou hodnotu jako maximální, nepřekročitelnou a zahrnující veškeré náklady spojené s plněním předmětu veřejné zakázky.

3.2. Podání nabídky s nabídkovou cenou v korunách českých bez DPH za předmět této veřejné zakázky vyšší než je maximální předpokládaná hodnota předmětu této veřejné zakázky dle článku 3.1. této Zadávací dokumentace bude Zadavatelem posouzeno jako nesplnění zadávacích podmínek a bude mít za následek vyloučení účastníka ze zadávacího řízení.

4. Předmět plnění veřejné zakázky a další informace:

4.1. Předmětem plnění veřejné zakázky je realizce Centrálního Log Managementu (dále jen

„CLM“). Tento CLM zajistí sběr, zpracování, dlouhodobé zaručené ukládání, umožní analyzovat a dlouhodobě ukládat záznamy o událostech v komponentách, systémech a aplikacích Správy železnic, státní organizace, tak, aby byly prokazatelné, chráněné a udržované v souladu se zákonnými a dalšími vyjmenovanými požadavky. Bližší specifikace předmětu plnění je uvedena v Technické příloze, která tvoří Přílohu č. 1 této Zadávací dokumentace, a v Závazném vzoru Smlouvy, který tvoří Přílohu č. 10 této Zadávací dokumentace.

4.2. Zadavatel provozuje informační systémy kritické informační infrastruktury a předmět plnění veřejné zakázky je určen pro jejich provozování. Zadavatel je proto povinen řídit se ZoKB.

Dne 17. prosince 2018 vydal Národní úřad pro kybernetickou a informační bezpečnost (dále jen „NÚKIB“), na základě ZoKB, Varování, č. j. 3012/2018NÚKIB-E/110, kde uvedl, že: „Použití technických nebo programových prostředků následujících společností, včetně jejich dceřiných společností, představuje hrozbu v oblasti kybernetické bezpečnosti:

− Huawei Technologies Co., Ltd, Šen-čen, Xxxxxx xxxxxx xxxxxxxxx

− ZTE Corporation, Šen-čen, Xxxxxx xxxxxx xxxxxxxxx“.

Dne 4. ledna 2019 vydal NÚKIB Metodiku k varování ze dne 17. prosince 2018 (dále jen

„metodika“), kde jsou mj. určeny i postupy pro aktualizaci analýzy rizik. V souladu s vydanou metodikou Zadavatel provedl analýzu rizik související s předmětnou veřejnou zakázkou na dodávky, jak je jeho povinností podle § 5 a § 8 vyhlášky č. 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, ve znění pozdějších předpisů. V návaznosti na to Zadavatel identifikoval rizika spojená s výše uvedenými technickými a programovými prostředky jako neakceptovatelná a současně opatření k jejich zvládání, kterým je nepřipuštění použití těchto prostředků v rámci plnění veřejné zakázky.

V souladu s § 4 odst. 4 ZoKB Zadavatel zohledňuje požadavky vyplývající z bezpečnostních opatření při výběru dodavatele pro Zadavatelem zajišťované služby informačních systémů v kategorii KII (Kritické informační infrastruktury).

Zadavatel tak na základě varování NÚKIB, navazující metodiky a provedené analýzy rizik, ve spojení s § 4 odst. 4 ZoKB, nepřipouští v rámci plnění veřejné zakázky použití technických nebo programových prostředků společností (výrobců), které jsou uvedené v současné době platném varování NÚKIB jako hrozba v oblasti kybernetické bezpečnosti.

Pokud by některý z dodavatelů ve své nabídce nerespektoval zákaz uvedený v předchozím odstavci, tzn. že by pro plnění veřejné zakázky chtěl použít technické nebo programové prostředky výše uvedených společností (výrobců), Zadavatel přistoupí k vyloučení takového dodavatele ze zadávacího řízení, a to s odkazem na § 48 odst. 2 písm. a) ZZVZ.

4.3. Klasifikace předmětu veřejné zakázky:

• Kód CPV: 30210000-4 – Stroje na zpracování dat (technické vybavení)

• Kód CPV: 72268000-1 – Dodávka programového vybavení

• Kód CPV: 72245000-4 – Smluvní analýza systémů a programování

• Kód CPV: 72253200-5 - Systémová podpora

4.4. Zadavatel uvádí, že níže uvedené části zadávací dokumentace vypracovala osoba odlišná od Zadavatele, ato konkrétně:

Část zadávací dokumentace						Označení osoby
Technická příloha (Příloha č. 1 této Zadávací dokumentace) Popis aplikací a prostředí (Příloha č. 2 této Zadávací dokumentace)						Deloitte Advisory s.r.o., IČO: 275 82 167, se sídlem Italská 2581/67, Vinohrady, 120 00 Praha 2
Šablona nabídky dokumentace),	(Příloha	č.	3	této	Zadávací
Matice požadavků dokumentace)	(Příloha	č.	4	této	Zadávací

5. Doba plnění a místo plnění veřejné zakázky:

5.1. Doba plnění veřejné zakázky

Doba plnění veřejné zakázky je vymezena v Závazném vzoru Smlouvy, tj. v Příloze č. 10 této Zadávací dokumentace.

5.2. Místo plnění veřejné zakázky

Místo plnění veřejné zakázky je specifikováno v Závazném vzoru Smlouvy, tj. v Příloze č. 10 této Zadávací dokumentace.

6. Sociálně a environmentálně odpovědné zadávání, inovace

6.1. Zadavatel při vytváření zadávacích podmínek, včetně pravidel pro hodnocení nabídek, a výběru dodavatele, postupoval tak, aby v co nejvyšší možné míře naplnil zásady sociálně odpovědného zadávání, environmentálně odpovědného zadávání a inovací tak jak jsou definovány v § 28 odst. 1 písm. p) až r) ZZVZ (dále jen „odpovědné zadávání“). Vzhledem k tomu, že jednotlivé postupy odpovědného zadávání nebyly v ZZVZ ani v jiném zákoně taxativně vymezeny a současně je odpovědné zadávání stále se velmi dynamicky vyvíjejícím institutem veřejného zadávání, Zadavatel při vytváření podmínek zvažoval použití zejména těch prvků odpovědného zadávání, které byly v době vytváření zadávacích podmínek jednoznačně vymezitelné a vymahatelné, a současně byla u nich vysoká míra jistoty, že Zadavatel jejich aplikací neporuší ostatní zásady uvedené v § 6 ZZVZ a také principy 3E vyplývající ze zákona č. 320/2011 Sb. o finanční kontrole ve veřejné správě, ve znění pozdějších předpisů.

6.2. Zadavatel neaplikuje v zadávacím řízení prvky odpovědného zadávání. Zadavatel zvážil při vytváření zadávacích podmínek uplatnění prvků odpovědného zadávání, které byly Zadavateli známy při vytváření této zadávací dokumentace, a došel k závěru, že uplatnění těchto prvků není vzhledem k povaze a smyslu zakázky možné z těchto důvodů:

6.2.1. S ohledem na předmět plnění veřejné zakázky je nutné dbát na vysokou profesionalitu dodavatele, kvalifikovaný servis s vysokou cenou práce a kybernetickou bezpečnost. S poukazem na tyto skutečnosti není možné do plnění předmětu veřejné zakázky zapojit osoby s nízkou kvalifikací.

6.2.2. Při plnění veřejné zakázky nevznikají negativní dopady na životní prostředí.

6.3. Zadavatel aplikuje v zadávacím řízení níže uvedené prvky odpovědného zadávání:

6.3.1. Zadavatel pro snížení administrativní náročnosti při zpracování nabídek připravil pro dodavatele vzorové dokumenty (zejména čestná prohlášení), která mohou dodavatelé využít. Vzorové dokumenty (zejména čestná prohlášení) jsou přílohami této Zadávací dokumentace.

6.3.2. Zadavatel požaduje, aby dodavatel při realizaci veřejné zakázky pro Zadavatele zajistil pro své dodavatele (tj. poddodavatele) rovnocenné platební podmínky, jako má sjednány dodavatel se Zadavatelem. Prvek odpovědného zadávání a povinnosti dodavatele s ním spojené Zadavatel definoval v následujících ustanoveních Závazného vzoru Smlouvy, který je Přílohou č. 10 této Zadávací dokumentace: článek 6.10. a 17.3. písm. e) Závazného vzoru Smlouvy.

7. Prohlídka místa plnění:

7.1. Zadavatel neprovádí prohlídku místa plnění ve smyslu ustanovení § 97 ZZVZ, neboť její uskutečnění není pro účely průběhu zadávacího řízení či plnění veřejné zakázky nezbytné.

8. Požadavky Zadavatele na kvalifikaci dodavatelů

8.1. Zadavatel požaduje dle § 73 ZZVZ po účastnících zadávacího řízení předložení dokladů a informací k prokázání splnění kvalifikace.

8.2. Kritéria kvalifikace

Zadavatel požaduje, aby dodavatelé prokázali:

a) svou základní způsobilost dle § 74 a § 75 ZZVZ;

b) svou profesní způsobilost dle § 77 ZZVZ;

d) svou technickou kvalifikaci dle § 79 ZZVZ;

8.3. Forma prokazování splnění kvalifikace

8.3.1. Dodavatel prokáže splnění kvalifikace ve všech případech příslušnými doklady, pro dostatečné prokázání postačuje předložení těchto dokladů formou prostých kopií.

8.3.2. Za účelem prokázání kvalifikace Zadavatel přednostně vyžaduje doklady evidované v systému, který identifikuje doklady k prokázání splnění kvalifikace (systém e-Certis).

8.3.3. Zadavatel vylučuje možnost, aby dodavatelé pro účely podání nabídky požadované doklady o kvalifikaci dle článku 8 této Zadávací dokumentace nahradili čestným prohlášením dle § 86 ZZVZ.

8.3.4. Dodavatel může nahradit požadované doklady jednotným evropským osvědčením pro veřejné zakázky ve smyslu § 87 ZZVZ. Vzor jednotného evropského osvědčení je stanoven prováděcím nařízením Komise (EU) 2016/7 ze dne 5. ledna 2016, kterým se zavádí standardní formulář jednotného evropského osvědčení pro veřejné zakázky (dostupný např. na internetové adrese: xxxx://xxx-xxx.xxxxxx.xx/xxxxx- content/CS/TXT/?uri=uriserv%3AOJ.L_.2016.003.01.0016.01.CES).

8.3.5. Dodavatel není povinen předložit Zadavateli doklady osvědčující skutečnosti obsažené v jednotném evropském osvědčení pro veřejné zakázky, pokud Zadavateli sdělí, že mu je již předložil v předchozím zadávacím řízení, za podmínky, že identifikuje dané zadávací řízení.

8.3.6. Povinnost předložit doklad může dodavatel splnit odkazem na odpovídající informace vedené v informačním systému veřejné správy ve smyslu 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ů, nebo v obdobném systému vedeném v jiném členském státu, který umožňuje neomezený dálkový přístup. Takový odkaz musí obsahovat internetovou adresu a údaje pro přihlášení a vyhledání požadované informace, jsou-li takové údaje nezbytné. V ČR jde zejména o výpis z obchodního rejstříku, výpis z veřejné části živnostenského rejstříku nebo výpis ze seznamu kvalifikovaných dodavatelů.

8.3.7. Dodavatel předkládá doklady prokazující splnění kvalifikace ve formě prosté kopie. Vybraný dodavatel má povinnost postupem dle § 122 odst. 3 písm. a) ZZVZ před uzavřením smlouvy Zadavateli předložit originály nebo ověřené kopie dokladů o kvalifikaci, pokud již nebyly v zadávacím řízení předloženy.

8.3.8. Doklady prokazující základní způsobilost podle § 74 ZZVZ a profesní způsobilost podle § 77 odst. 1 ZZVZ musí prokazovat splnění požadovaného kritéria způsobilosti nejpozději v době 3 měsíců přede dnem zahájení zadávacího řízení.

8.3.9. V případech, kdy Zadavatel v rámci prokázání splnění kvalifikace požaduje předložení čestného prohlášení dodavatele, musí takové čestné prohlášení obsahovat Zadavatelem požadované údaje.

8.3.10. Pokud ZZVZ nebo Zadavatel požaduje předložení dokladu podle právního řádu České republiky, může dodavatel předložit obdobný doklad podle právního řádu státu, ve kterém se tento doklad vydává. Tento doklad musí být předložen spolu s jeho překladem do českého jazyka. Bude-li mít Zadavatel pochybnosti o správnosti předkladu, je oprávněn si vyžádat předložení úředně ověřeného překladu dokladu do českého jazyka tlumočníkem zapsaným do seznamu znalců a tlumočníků podle zákona č. 36/1997 Sb., o znalcích a tlumočnících, ve znění pozdějších předpisů. Povinnost připojit k dokladům překlad do českého jazyka se nevztahuje na doklady ve slovenském jazyce. Doklady o vzdělání, např. vysokoškolské diplomy, lze předkládat rovněž v latinském jazyce.

8.3.11. Certifikáty vyžadované v rámci technické kvalifikace je možné předložit v rámci nabídky v anglickém jazyce bez jejich překladu do českého jazyka.

8.4. Prokázání kvalifikace prostřednictvím jiných osob dle § 83 ZZVZ

8.4.1. Dodavatel může určitou část ekonomické kvalifikace, technické kvalifikace nebo profesní způsobilosti s výjimkou kritéria podle § 77 odst. 1 ZZVZ prokázat prostřednictvím jiných osob. Dodavatel je v takovém případě povinen Zadavateli předložit:

a) doklady prokazující splnění profesní způsobilosti podle § 77 odst. 1 ZZVZ jinou osobou,

b) doklady prokazující splnění chybějící části kvalifikace prostřednictvím jiné osoby,

c) doklady o splnění základní způsobilosti podle § 74 ZZVZ jinou osobou a

d) písemný závazek jiné osoby k poskytnutí plnění určeného k plnění veřejné zakázky nebo k poskytnutí věcí nebo práv, s nimiž bude dodavatel oprávněn disponovat v rámci plnění veřejné zakázky, a to alespoň v rozsahu, v jakém jiná osoba prokázala kvalifikaci za dodavatele. Má se za to, že požadavek podle písm. d) je splněn, pokud obsahem písemného závazku jiné osoby je společná a nerozdílná odpovědnost této osoby za plnění veřejné zakázky společně s dodavatelem. Prokazuje-li však dodavatel prostřednictvím jiné osoby kvalifikaci a předkládá doklady podle § 79 odst. 2 písm. a),

b) nebo d) ZZVZ vztahující se k takové osobě, musí dokument podle písm. d) obsahovat závazek, že jiná osoba bude vykonávat stavební práce či služby, ke kterým se prokazované kritérium kvalifikace vztahuje

8.4.2. Dodavatelé a jiné osoby prokazují (mohou prokázat) kvalifikaci společně.

8.4.3. Dodavatel a jiná osoba, jejímž prostřednictvím dodavatel prokazuje ekonomickou kvalifikaci podle § 78 ZZVZ, nesou společnou a nerozdílnou odpovědnost za plnění veřejné zakázky.

8.4.4. Zadavatel upozorňuje, že povinnost doložit veškeré doklady uvedené výše v tomto článku platí i v případě, kdy je část kvalifikace prokazována poddodavatelem poddodavatele (pod- poddodavatelem).

8.5. Prokazování kvalifikace v případě společné účasti dodavatelů dle § 82 ZZVZ

8.5.1. V případě společné účasti dodavatelů prokazuje základní způsobilost dle § 74 a § 75 ZZVZ a profesní způsobilost podle § 77 odst. 1 ZZVZ každý dodavatel samostatně.

8.5.2. Nabídka více dodavatelů musí dále splňovat následující předpoklady:

Jeden z dodavatelů bude určen jako vedoucí účastník odpovědný za veřejnou zakázku a toto určení bude potvrzeno předložením zmocnění k zastupování všech ostatních dodavatelů.

Zadavatel vyžaduje, aby odpovědnost za plnění veřejné zakázky nesli všichni dodavatelé podávající společnou nabídku společně a nerozdílně.

8.6. Prokazování kvalifikace získané v zahraničí dle § 81 ZZVZ

8.6.1. V případě, že byla kvalifikace získána v zahraničí, prokazuje se doklady vydanými podle právního řádu země, ve které byla získána, a to v rozsahu požadovaném Zadavatelem.

8.6.2. Výpis z evidence Rejstříku trestů vydává Rejstřík trestů. Potvrzení pro daňové nedoplatky zahraničních dodavatelů v ČR vydává Finanční úřad pro Prahu 1 a potvrzení pro nedoplatky zahraničních dodavatelů v ČR na pojistném a na penále na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti vydává Pražská správa sociálního zabezpečení.

8.7. Změny kvalifikace účastníka zadávacího řízení dle § 88 ZZVZ

8.7.1. Pokud po předložení dokladů nebo prohlášení o kvalifikaci dojde v průběhu zadávacího řízení ke změně kvalifikace účastníka zadávacího řízení, je účastník zadávacího řízení povinen tuto změnu Zadavateli do 5 pracovních dnů oznámit a do 10 pracovních dnů od oznámení této změny předložit nové doklady nebo prohlášení ke kvalifikaci. Zadavatel může tyto lhůty prodloužit nebo prominout jejich zmeškání. Povinnost podle věty první účastníku zadávacího řízení nevzniká, pokud je kvalifikace změněna takovým způsobem, že:

a. podmínky kvalifikace jsou nadále splněny,

b. nedošlo k ovlivnění kritérií hodnocení nabídek.

8.7.2. Dozví-li se Zadavatel, že dodavatel nesplnil shora uvedenou povinnost, vyloučí jej ze zadávacího řízení.

8.8. Výpis ze seznamu kvalifikovaných dodavatelů dle § 228 ZZVZ

8.8.1. Předložení dokladu o zapsání dodavatele do seznamu kvalifikovaných dodavatelů vedeného Ministerstvem pro místní rozvoj dle § 226 až § 232 ZZVZ nahrazuje v souladu s § 228 ZZVZ doklad prokazující profesní způsobilost podle § 77 ZZVZ v tom rozsahu, v jakém údaje ve výpisu ze seznamu kvalifikovaných dodavatelů prokazují splnění kritérií profesní způsobilosti, a základní způsobilost podle § 74 ZZVZ v plném rozsahu. Výpis ze seznamu kvalifikovaných dodavatelů nesmí být k poslednímu dni, ke kterému má být prokázána základní způsobilost nebo profesní způsobilost, starší než tři měsíce.

8.9. Předložení certifikátu dle § 234 ZZVZ

8.9.1. Platným certifikátem vydaným v rámci schváleného systému certifikovaných dodavatelů lze podle § 234 ZZVZ prokázat kvalifikaci v zadávacím řízení. Má se za to, že dodavatel je kvalifikovaný v rozsahu uvedeném na certifikátu.

8.10. Důsledek nesplnění kvalifikace

8.10.1. Dodavatel, který nesplní kvalifikaci v požadovaném rozsahu a ZZVZ a touto zadávací dokumentací požadovaným nebo dovoleným způsobem, bude Zadavatelem z účasti v zadávacím řízení vyloučen. Pokud se jedná o vybraného dodavatele, pak ve smyslu § 48 odst. 8 ZZVZ musí z těchto důvodů být vyloučen ze zadávacího řízení.

9. Základní způsobilost dle § 74 a § 75 ZZVZ

9.1. Zadavatel v souladu s ustanovením § 73 ZZVZ požaduje prokázání základní způsobilosti podle § 74 ZZVZ následujícím způsobem:

a) Způsobilým není dodavatel, který byl v zemi svého sídla v posledních 5 letech před zahájením zadávacího řízení pravomocně odsouzen pro trestný čin uvedený v příloze č. 3 ZZVZ nebo obdobný trestný čin podle právního řádu země sídla dodavatele; k zahlazeným odsouzením se nepřihlíží.

Dodavatel prokazuje splnění podmínek základní způsobilosti v tomto kritériu ve vztahu k České republice předložením výpisu z evidence Rejstříku trestů.

b) Způsobilým není dodavatel, který má v České republice nebo v zemi svého sídla v evidenci daní zachycen splatný daňový nedoplatek.

Dodavatel prokazuje splnění podmínek základní způsobilosti v tomto kritériu ve vztahu k České republice a k zemi svého sídla předložením potvrzení příslušného finančního úřadu a písemného čestného prohlášení ve vztahu ke spotřební dani (dodavatel může použít vzor Čestného prohlášení ke splnění základní způsobilosti, které tvoří Přílohu č. 5 této Zadavací dokumentace).

c) Způsobilým není dodavatel, který má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném nebo na penále na veřejné zdravotní pojištění.

Dodavatel prokazuje splnění podmínek základní způsobilosti v tomto kritériu ve vztahu k České republice a k zemi svého sídla předložením písemného čestného prohlášení (dodavatel může použít vzor Čestného prohlášení ke splnění základní způsobilosti, které tvoří Přílohu č. 5 této Zadavací dokumentace).

d) Způsobilým není dodavatel, který má v České republice nebo v zemi svého sídla splatný nedoplatek na pojistném nebo na penále na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti.

Dodavatel prokazuje splnění podmínek základní způsobilosti v tomto kritériu ve vztahu k České republice a k zemi svého sídla předložením potvrzení příslušné okresní správy sociálního zabezpečení.

e) Způsobilým není dodavatel, který je v likvidaci, proti němuž bylo vydáno rozhodnutí o úpadku, vůči němuž byla nařízena nucená správa podle jiného právního předpisu nebo v obdobné situaci podle právního řádu země sídla dodavatele.

Dodavatel prokazuje splnění podmínek základní způsobilosti v tomto kritériu ve vztahu k České republice předložením výpisu z obchodního rejstříku, nebo předložením písemného čestného prohlášení v případě, že není v obchodním rejstříku zapsán.

9.2. Je-li dodavatelem právnická osoba, musí podmínku uvedenou v odstavci 9.1 písm. a) splňovat tato právnická osoba a zároveň každý člen statutárního orgánu. Je-li členem statutárního orgánu dodavatele právnická osoba, musí podmínku uvedenou shora v odstavci 9.1. písm. a) splňovat:

a. tato právnická osoba,

b. každý člen statutárního orgánu této právnické osoby a

c. osoba zastupující tuto právnickou osobu v statutárním orgánu dodavatele.

9.3. Účastní-li se zadávacího řízení pobočka závodu:

9.3.1. zahraniční právnické osoby, musí podmínku uvedenou v odstavci 9.1. písm. a) splňovat tato právnická osoba a vedoucí pobočky závodu,

9.3.2. české právnické osoby, musí podmínku uvedenou shora v odstavci 9.1. písm. a) splňovat:

a. tato právnická osoba,

b. každý člen statutárního orgánu této právnické osoby a

c. osoba zastupující tuto právnickou osobu v statutárním orgánu dodavatele

d. vedoucí pobočky závodu.

9.4. Zadavatel nemusí ve smyslu § 75 odst. 2 ZZVZ uplatnit důvod pro vyloučení účastníka zadávacího řízení, i když nesplnil podmínky základní způsobilosti, pokud:

a. by vyloučení účastníka znemožnilo zadání veřejné zakázky v tomto zadávacím řízení a

b. naléhavý veřejný zájem, zejména veřejné zdraví nebo ochrana životního prostředí, vyžaduje plnění veřejné zakázky.

9.5. Účastník zadávacího řízení může v souladu s § 76 ZZVZ prokázat, že i přes nesplnění základní způsobilosti podle § 74 ZZVZ nebo naplnění důvodu nezpůsobilosti podle § 48 odst. 5 a 6 ZZVZ obnovil svou způsobilost k účasti v zadávacím řízení, pokud v průběhu zadávacího řízení Zadavateli doloží, že přijal dostatečná nápravná opatření. To neplatí po dobu, na kterou byl účastník zadávacího řízení pravomocně odsouzen k zákazu plnění veřejných zakázek nebo účasti v koncesním řízení.

9.6. Pokud Zadavatel dospěje k závěru, že způsobilost účastníka zadávacího řízení byla obnovena, ze zadávacího řízení jej nevyloučí nebo předchozí vyloučení účastníka zadávacího řízení zruší.

10. Profesní způsobilost dle § 77 ZZVZ

10.1. Zadavatel v souladu s ustanovením § 73 ZZVZ požaduje prokázání profesní způsobilosti dle § 77 ZZVZ následujícím způsobem:

a) Dodavatel prokazuje splnění profesní způsobilosti ve vztahu k České republice předložením výpisu z obchodního rejstříku nebo jiné obdobné evidence, pokud jiný právní předpis zápis do takové evidence vyžaduje.

Dodavatel prokazuje splnění tohoto kritéria profesní způsobilosti předložením výpisu z obchodního rejstříku či jiné obdobné evidence.

10.2. Doklady k prokázání profesní způsobilosti dodavatel nemusí předložit, pokud právní předpisy v zemi jeho sídla obdobnou profesní způsobilost nevyžadují.

11. Ekonomická kvalifikace dle § 78 ZZVZ

11.1. Zadavatel nepožaduje ekonomickou kvalifikaci.

12. Technická kvalifikace dle § 79 ZZVZ

12.1. Splnění technické kvalifikace prokáže dodavatel, který předloží seznam významných zakázek, jehož vzor je součástí Přílohy č. 6 této Zadávací dokumentace, s obdobným charakterem plnění, jako je předmět veřejné zakázky, poskytnutých za posledních 5 let před zahájením zadávacího řízení včetně uvedení:

⮚ ceny (resp. finančního objemu) významné zakázky bez DPH

⮚ doby jejich poskytnutí

⮚ identifikace objednatele včetně kontaktu na zodpovědnou osobu, která může Xxxxxxxxxx realizaci významné zakázky potvrdit

⮚ popis předmětu plnění významné zakázky.

12.1.1. Vymezení minimální úrovně kvalifikačního požadavku:

Dodavatel v nabídce doloží minimálně 3 reference (významné zakázky), které poskytl za posledních 5 let před zahájením zadávacího řízení. Zadavatel upozorňuje, že dodavatel je povinen prokázat technickou kvalifikaci 3 různými referencemi (významnými zakázkami) - není tedy možné, aby jedna reference (významná zakázka) byla použita opakovaně. Významné zakázky musí kumulativně splňovat následující požadavky:

Významná zakázka č. 1

⮚ předmětem významné zakázky je realizace systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce;

⮚ finanční objem této významné zakázky musí činit minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM;

⮚ minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace je: 600;

⮚ minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3.

Významná zakázka č. 2

⮚ předmětem významné zakázky je realizace systému CLM;

⮚ finanční objem této významné zakázky musí činit minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM;

⮚ minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace je: 600.

Významná zakázka č. 3

⮚ předmětem významné zakázky je realizace služeb v oblasti kybernetické bezpečnosti;

⮚ finanční objem této významné zakázky musí činit minimálně 10 mil. Kč bez DPH, s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent, SW licencí a podpory po předání do provozu.

Zadavatel přitom požaduje, aby jedna z výše uvedených významných zakázek byla realizována pro kritickou informační infrastrukturu ve smyslu zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů, a dále aby jedna z výše uvedených významných zakázek byla realizována pro prostředí systému řízení technologických celků. Tyto dva požadavky může dodavatel prokázat jednou referenční zakázkou (tj. referenční zakázkou, která byla realizována pro kritickou informační infrastrukturu a současně byla realizována i pro prostředí systému řízení technologických celků).

12.1.2. Zadavatel požaduje, aby pro účely prokázání technické kvalifikace byly předkládány pouze významné zakázky, které byly dodavatelem v posledních 5 letech před zahájením zadávacího řízení zcela dokončeny.

12.1.3. Za významnou zakázku lze pro účely prokázání kritérií technické kvalifikace dle § 79 odst. 2 písm. b) ZZVZ a článku 12.1. této Zadávací dokumentace považovat výhradně takovou zakázku, jejíž realizace nebyla objednatelem předčasně ukončena (zejména odstoupením od smlouvy) z důvodu porušení smluvních či zákonných povinností na straně dodavatele.

12.1.4. Způsob prokázání splnění tohoto kvalifikačního požadavku:

Dodavatel prokáže splnění kvalifikačního požadavku předložením seznamu, který bude obsahovat významné zakázky, něhož bude vyplývat splnění všech výše uvedených požadavků Zadavatele. Vzor seznamu, který je rovněž čestným prohlášení, je součástí Přílohy č. 6 této Zadávací dokumentace.

Odstraněno: <#>minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 9 TB/den;¶

Odstraněno: <#>předání do provozu

Odstraněno: <#>Výzvy Odstraněno: předání do provozu Odstraněno: Výzvy

Odstraněno: <#>minimální objem logů zpracovávaných systémem v okamžiku předání do provozu je: 1 TB/den;¶

Odstraněno: <#>předání do provozu

Odstraněno: <#>Výzvy

12.2. Osvědčení o vzdělání a odborné kvalifikaci člena realizačního týmu

12.2.1. Členové realizačního týmu budou odpovědní za činnosti, které bude dodavatel provádět v průběhu realizace veřejné zakázky. Realizační tým musí být složen z minimálně 7 osob, přičemž každá osoba v realizačním týmu může zastávat pouze jednu pozici.

12.2.2. Členové realizačního týmu musí splňovat následující kvalifikaci.

12.2.3. Vymezení minimální úrovně kvalifikačního požadavku:

Dodavatel prokáže splnění kvalifikačního požadavku, pokud doloží, že disponuje minimálně 7 osobami, z nichž každá splňuje veškeré níže uvedené požadavky pro danou pozici:

Senior Architekt XXX – tuto pozici bude zastávat minimálně 1 osoba

⮚ má minimálně 10letou praxi v oblasti návrhu architektury informační bezpečnosti,

⮚ má minimálně 5letou praxi na pozici architekta informační bezpečnosti,

⮚ má zkušenost s realizací alespoň dvou projektů v oblasti realizace systému CLM, který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení,

⮚ má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600,

⮚ disponuje certifikátem GSA nebo CISSP nebo CSAP+ nebo jiným platným certifikátem s obdobným nebo vyšším rozsahem,

⮚ má jazykovou znalost českého jazyka (případně slovenského) na úrovni psaného i mluveného projevu umožňující pracovní komunikaci,

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

⮚ má jazykovou znalost anglického jazyka potřebnou pro porozumění technické dokumentace (tj. dokumentu obsahujícího odbornou terminologii v oblasti předmětu plnění veřejné zakázky).

Zadavatel pro úplnost uvádí, že každá osoba, která bude zastávat pozici Senior Architekt CLM, musí doložit min. 3 reference (resp. zkušenost s min. 3 projekty), které jsou vymezeny výše, s tím, že není možné použít 1 referenci (zkušenost s projektem) opakovaně – tzn. že musí být předloženy min. 3 různé reference (projekty).

Senior System Engineer – tuto pozici budou zastávat minimálně 3 osoby

⮚ má minimálně 8letou praxi v oblasti návrhu architektury informační bezpečnosti,

⮚ má zkušenost s realizací alespoň jednoho projektu v oblasti realizace systému CLM, který byl dokončen v poledních 5 letech před zahájením tohoto zadávacího řízení,

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM, který byl realizován pro prostředí systému řízení technologických celků, a který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600,

⮚ disponuje certifikátem GSEC nebo SSCP nebo CSSP nebo CSAP+ nebo jiným platným certifikátem s obdobným nebo vyšším rozsahem,

⮚ má jazykovou znalost českého jazyka (případně slovenského) na úrovni psaného i mluveného projevu umožňující pracovní komunikaci,

⮚ má jazykovou znalost anglického jazyka potřebnou pro porozumění technické dokumentace (tj. dokumentu obsahujícího odbornou terminologii v oblasti předmětu plnění veřejné zakázky).

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Zadavatel pro úplnost uvádí, že každá osoba, která bude zastávat pozici Senior System Engineer, musí doložit min. 2 reference (resp. zkušenost s min. 2 projekty), které jsou vymezeny výše, s tím, že není možné použít 1 referenci (zkušenost s projektem) opakovaně – tzn. že musí být předloženy min. 2 různé reference (projekty).

Senior Analytik – tuto pozici budou zastávat minimálně 2 osoby

⮚ má minimálně 5letou praxi v oblasti informační bezpečnosti,

⮚ má minimálně 3letou praxi v oblasti korporátních analýz v oblasti kybernetické bezpečnosti,

⮚ má zkušenost s alespoň 1 projektem na realizaci systému CLM využívajícího typově shodný SW stejného výrobce jako je nabízen dodavatelem v této veřejné zakázce a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 10 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 10 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600; minimální počet lokalit, ve kterých se zdroje logů nacházejí, musí být nejpozději v okamžiku uveřejnění této Zadávací dokumentace: 3

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600

nebo

⮚ disponuje certifikátem CompTIA Security+ nebo jiným platným certifikátem s obdobným nebo vyšším rozsahem,

⮚ má jazykovou znalost českého jazyka (případně slovenského) na úrovni psaného i mluveného projevu umožňující pracovní komunikaci,

⮚ má jazykovou znalost anglického jazyka potřebnou pro porozumění technické dokumentace (tj. dokumentu obsahujícího odbornou terminologii v oblasti předmětu plnění veřejné zakázky).

Zadavatel pro úplnost uvádí, že každá osoba, která bude zastávat pozici Senior Analytik, musí doložit min. 1 referenci (resp. zkušenost s min. 1 projektem), která je vymezena výše.

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Projektový manažer – tuto pozici bude zastávat minimálně 1 osoba

⮚ má minimálně 5letou praxi na pozici Project Manager,

nebo

má zkušenost s alespoň 1 projektem na realizaci systému CLM a tento byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení; finanční objem projektu činil minimálně 20 mil. Kč bez DPH s tím, že v této finanční částce nesmí být zahrnuta hodnota HW komponent a podpory po předání do provozu, tzn. že finanční objem 20 mil. Kč bez DPH musí být naplněn pouze ve vztahu k systému CLM; minimální počet zdrojů logů připojených do systému nejpozději v okamžiku uveřejnění této Zadávací dokumentace byl: 600

nebo

⮚ má alespoň 1 zkušenost s řízením implementačního projektu, který byl dokončen v posledních 5 letech před zahájením tohoto zadávacího řízení, a jeho celková hodnota činila alespoň 20.000.000 Kč bez DPH,

⮚ disponuje certifikátem PRINCE2 nebo jiným platným certifikátem s obdobným nebo vyšším rozsahem,

⮚ má jazykovou znalost českého jazyka (případně slovenského) na úrovni psaného i mluveného projevu umožňující pracovní komunikaci,

⮚ má jazykovou znalost anglického jazyka potřebnou pro porozumění technické dokumentace (tj. dokumentu obsahujícího odbornou terminologii v oblasti předmětu plnění veřejné zakázky).

Zadavatel pro úplnost uvádí, že každá osoba, která bude zastávat pozici Projektový manažer, musí doložit min. 1 referenci (resp. zkušenost s min. 1 projektem), která je vymezena výše.

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 9 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: předání do provozu

Odstraněno: Výzvy

Odstraněno: minimální objem logů zpracovávaných systémem v okamžiku předání do provozu byl: 1 TB/den;

Odstraněno: předání do provozu

Odstraněno: Výzvy

Zadavatel požaduje, aby alespoň jeden člen realizačního týmu byl držitelem platného certifikátu k nabízenému CLM, z něhož bude vyplývat, že tento člen realizačního týmu splňuje veškeré podmínky dané výrobcem CLM pro jeho instalaci. Předmětný certifikát předloží dodavatel v rámci své nabídky.

12.2.4. Způsob prokázání splnění tohoto kvalifikačního požadavku:

Dodavatel prokáže splnění kvalifikačního požadavku předložením následujících dokumentů, z nichž bude vyplývat splnění výše uvedených požadavků:

⮚ jmenného seznamu realizačního týmu, který je součástí Přílohy č. 6 této Zadávací dokumentace,

⮚ certifikátů (pozn. certifikáty je možné předložit v rámci nabídky v anglickém jazyce bez jejich překladu do českého jazyka).

13. Jiná kritéria kvalifikace dle § 167 odst. 1 ZZVZ

Dodavatel nepožaduje předložení jiných kritérií kvalifikace.

14. Požadavky Zadavatele na způsob zpracování nabídkové ceny:

14.1. Způsob zpracování nabídkové ceny

14.2. Dodavatel ve své nabídce uvede celkovou nabídkovou cenu v korunách českých bez DPH, přičemž tato bude předmětem hodnocení nabídek dle článku 18.2. této Zadávací dokumentace. Celková nabídková cena nesmí být dle článku 3. této Zadávací dokumentace vyšší než předpokládaná hodnota veřejné zakázky.

14.3. Dodavatelé jsou povinni pro účely stanovení celkové nabídkové ceny vyplnit tabulku, která je součástí Přílohy č. 4 této Zadávací dokumentace - dodavatelé konkrétně vyplní list s názvem „A. Nabídková cena“. Na uvedeném listu jsou uvedeny jednotlivé části dodávky (viz sloupec C tabulky), z nichž se předmět plnění bude skládat. Dodavatelé jsou povinni ke každé jednotlivé části dodávky uvést nabídkovou cenou, tzn. že do sloupce E (pozn. místa určená k vyplnění dodavatelem jsou v tabulce označena oražovou barvou) dodavatel uvede jednotkovou nabídkovou cenu v Kč bez DPH, a to ke každé části dodávky. Nabídková cena za předpokládaný počet jednotek (pozn. předpokládaný počet jednotek je uvede ve sloupci F tabulky a pokrývá celou dobu realizace veřejné zakázky) se ve vztahu ke každé části dodávky vypočte automaticky (viz sloupec H tabulky), to samé platí i pro celkovou nabídkovou cenu, která bude předmětem hodnocení nabídek.

14.4. Zadavatel dále uvádí, že plnění veřejné zakázky rozdělil do dílčích plnění, které jsou zřejmé ze Závazného vzoru Smlouvy (tj. z Přílohy č. 10 této Zadávací dokumentace) a z Technické přílohy (tj. z Přílohy č. 1 této Zadávací dokumentace), a současně stanovil platební milníky (viz Příloha č. 10 této Zadávací dokumentace – Závazný vzor Smlouvy), přičemž požaduje, aby jednotkové nabídkové ceny byly dodavatelem stanoveny tak, aby byla respektována následující pravidla:

• nabídková cena za fázi č. 1 (tj. za část dodávky „Analýza“) a nabídkové cena za fázi č. 2 (tj. za část dodávky „Definice Technického návrhu implementace“) muže činit maximálně 10 % z celkové nabídkové ceny;

• nabídková cena za fázi č. 3 (tj. za část dodávky „Dodávka HW“ a „Dodávka licencí ke Standardnímu SW) může činit maximálně 35 % z celkové nabídkové ceny;

• nabídková cena za fázi č. 4 (tj. za část dodávky „Dodávka SW a licencí (vyjma licencí ke Standardnímu SW)“, „Dodávka Produkčního a testovacího prostředí, Instalace, Konfigurace a Testování“, „Pilotní provoz“, „Dokumentace a Školení“ a „Předání do provozu“) může činit maximálně 40 % z celkové nabídkové ceny;

• nabídková cena za fázi č. 5 (tj. za část dodávky „Zajištění technické podpory provozu“ a „Nadstandardní služby“) musí činit minimálně 15 % z celkové nabídkové ceny.

Nerespektování těchto požadavků ze strany dodavatele bude považováno za nesplnění zadávacích podmínek.

14.5. Dodavatel je povinen vyplnit jednotkovou nabídkovou cenu u všech položek, resp. jednotlivých částí dodávky, uvedených v tabulce na listu „A. Nabídková cena“. Nevyplnění ceny u některé z položek nebo uvedení hodnoty 0 u některé z položek může být důvodem pro vyloučení dodavatele ze zadávacího řízení.

14.6. Celková nabídková cena v Kč bez DPH bude automaticky spočítána po vyplnění tabulky na listu „A. Nabídková cena“, resp. jejích oranžově označených částí. Tabulka uvedená v Příloze č. 4 této Zadávací dokumentace má nastavený automatický výpočet, dodavatel proto nesmí zasahovat do nastavených vzorců této přílohy, ani doplňovat další položky.

14.7. Celková nabídková cena stanovená v tabulce je cenou modelovou, tzn. že jde o předpokládaný objem plnění stanovený pro účely hodnocení nabídek. Pro plnění veřejné zakázky proto budou závazné jednotkové nabídkové ceny (tj. nabídkové ceny uvedené ve sloupci E tabulky). Jednotkové ceny dle nabídky dodavatelů lze měnit pouze v případě změny výše DPH v důsledku změny právních předpisů. V případě, že dojde ke změně zákonné sazby DPH, je vybraný dodavatel povinen k ceně bez DPH účtovat DPH v platné výši.

14.8. Za správné vyplnění cenové tabulky (tj. tabulky, která je součástí Přílohy č. 4 této Zadávací dokumentace), které bude provedeno v souladu se zadávacími podmínkami, odpovídá účastník zadávacího řízení.

14.9. Jednotkové ceny musí obsahovat veškeré náklady související s předmětem veřejné zakázky.

14.10. Mimořádně nízká nabídková cena

V souladu s § 113 ZZVZ posoudí Zadavatel mimořádně nízké nabídkové ceny před odesláním oznámení o výběru dodavatele. Zadavatel požádá účastníka zadávacího řízení o písemné zdůvodnění způsobu stanovení mimořádně nízké nabídkové ceny, bude-li tato v jeho nabídce identifikována. Žádost o zdůvodnění mimořádně nízké nabídkové ceny se považuje za žádost podle § 46 ZZVZ, lze ji doplňovat a vznést opakovaně.

15. Jiné požadavky Zadavatele na plnění veřejné zakázky:

15.1. Návrh realizace

15.1.1. Zadavatel uvedl v Technické příloze, která tvoří Přílohu č. 1 této Zadávací dokumentace, své požadavky kladené na CLM, které musí každý dodavatel respektovat, a vedle toho minimální výčet činností, z nichž se má dodávka, resp. předmět plnění skládat.

15.1.2. Každý dodavatel je povinen ve své nabídce předložit svůj návrh realizace (resp. návrh řešení) a tento popsat. Návrh realizace přitom musí respektovat požadavky Zadavatele kladené na CLM a musí v něm být zohledněny i jednotlivé činnosti dle Technické přílohy, která tvoří Přílohu č. 1 této Zadávací dokumentace. Dodavatel návrh realizace zpracuje do dokumentu, který je označen jako Šablona nabídky, a který tvoří Přílohu č. 3 této Zadávací dokumentace.

15.1.3. Zadavatel předložený návrh realizace v rámci posouzení splnění podmínek účasti v zadávacím řízení posoudí, a to z toho pohledu, zda v něm byly zohledněny a respektovány všechny požadavky Zadavatele uvedené v Technické příloze, tj. v Příloze č. 1 této Zadávací dokumentace.

15.1.4. Pokud dodavatelem předložený návrh realizace nebude vyhovovat požadavkům Zadavatele (zadávacím podmínkám), Zadavatel přistoupí k vyloučení takového dodavatele, ze zadávacího řízení s odkazem na § 48 odst. 2 písm. a) ZZVZ. Zadavatel k tomuto pro úplnost dodává, že dodavatel není oprávněn po uplynutí lhůty pro podání nabídek předložený návrh realizace měnit.

15.2. Požadavky Zadavatele

15.2.1. Zadavatel uvedl v Příloze č. 4 této Zadávací dokumentace list s názvem „B0. Povinné požadavky TS bez hodnocení“. Zadavatel požaduje, aby tento list, který nesouvisí s hodnocením nabídek ve smyslu článku 18. této Zadávací dokumentace, dodavatel vyplnil a předložil v rámci své nabídky (pozn. dodavatel vyplní celou Přílohu č. 4 této Zadávací dokumentace, a tuto předloží ve své nabídce). Zadavatel k tomuto dodává, že místa určená k vyplnění jsou v tabulce označena oranžovou barvou.

15.2.2. Zadavatel na listu s názvem „B0. Povinné požadavky TS bez hodnocením“ uvedl výčet jednotlivých požadavků a jejich popis (viz sloupec D a E tabulky). Dodavatel je povinen do sloupce F ke každému jednotlivému požadavku uvést „ANO“, pokud jeho návrh řešení daný požadavek splňuje, nebo „NE“, pokud jeho návrh řešení daný požadavek nesplňuje. Zadavatel v této souvislosti zdůrazňuje, že předložený (nabízený) návrh realizace musí naplňovat všechny požadavky uvedené na listu s názvem „B0. Povinné požadavky TS bez hodnocení“, jinak by nebyly naplněny zadávací podmínky.

15.2.3. Dodavatel současně uvede do sloupce G tabulky odkaz na konkrétní část svého návrhu realizace (viz článek 15.1. této Zadávací dokumentace) nebo konkrétní (relevantní) text použitý v návrhu realizace; z uvedeného odkazu či textu přitom musí vyplývat, zda konkrétní požadavek dodavatelem předložený návrh realizace naplňuje či nikoliv.

15.3. Využití poddodavatele

15.3.1. Zadavatel požaduje, aby účastník zadávacího řízení v nabídce:

a) určil části veřejné zakázky, které hodlá plnit prostřednictvím poddodavatelů, a

b) předložil seznam poddodavatelů, pokud jsou dodavateli známi a uvedl, kterou část veřejné zakázky bude každý z poddodavatelů plnit.

15.3.2. Dodavatel může pro splnění své povinnosti dle předchozího článku (tj. článku 15.2.1.) využít Seznam poddodavatelů, který je Přílohou č. 11 této Zadávací dokumentace.

15.3.3. Vybraný dodavatel je povinen předložit zadavateli identifikační údaje poddodavatelů, a to nejpozději do 10 pracovních dnů od doručení oznámení o výběru dodavatele, pokud jsou známi. Poddodavatelé, kteří nebyli identifikováni podle věty první a kteří se následně zapojí do plnění veřejné zakázky, musí být identifikováni, a to před zahájením plnění veřejné zakázky

16. Varianty nabídky

16.1. Zadavatel nepřipouští varianty nabídky.

17. Návrh smlouvy

17.1. Dodavatel je povinen využít Závazný vzor Smlouvy, který tvoří přílohu této Zadávací dokumentace.

17.2. Dodavatel není oprávněn činit změny či doplnění Závazného vzoru Smlouvy, vyjma údajů, u nichž vyplývá z jejich obsahu povinnost doplnění (označené jako „doplní dodavatel“ či jiným obdobným způsobem). V případě nabídky podávané společně několika dodavateli je dodavatel oprávněn upravit Závazný vzor Smlouvy toliko s ohledem na tuto skutečnost; totéž platí, je-li dodavatelem fyzická osoba.

17.3. Dodavatel je povinen Závazný vzor Smlouvy doplněný dle výše uvedených pokynů učinit součástí nabídky.

18. Způsob hodnocení nabídek:

18.1. Kritéria hodnocení

18.1.1. Hodnotícím nabídek bude provedeno v souladu s § 114 a násl. ZZVZ podle ekonomické výhodnosti nabídek, na základě nejnižší nabídkové ceny a kvality nabízeného řešení.

18.1.2. Zadavatel stanovil v souladu s § 115 ZZVZ pro hodnocení nabídek následující hodnotící kritéria:

	Kritéria hodnocení	Váha
A.	Celková nabídková cena bez DPH	60 %
B.	Výchozí funkcionality	25 %
C.	Preference	15 %

18.1.3. Vyhodnocení nabídek v jednotlivých kritériích hodnocení bude provedeno bodovací metodou dle popisu uvedeného níže u jednotlivých kritérií hodnocení. Výsledné hodnocení bude provedeno tak, že jednotlivá bodová hodnocení nabídek v rámci jednotlivých kritérií hodnocení (kritéria A, B a C) budou přepočteny vahou příslušného kritéria hodnocení uvedenou v tabulce výše. Na základě součtu výsledných bodových hodnot získaných po provedeném přepočtení vahami jednotlivých kritérií hodnocení bude stanoveno celkové pořadí nabídek tak, že jako nejvhodnější bude hodnocena nabídka s nejvyšším celkovým počtem bodů v součtu za všechny kritéria hodnocení. Maximální počet bodů činí 100.

18.1.4. Při veškerých výpočtech v rámci hodnocení nabídek budou čísla zaokrouhlována na dvě desetinná místa podle matematických pravidel.

18.1.5. Pro případ rovnosti výsledných hodnot jednotlivých nabídek bude nejvýhodnější nabídka toho účastníka zadávacího řízení, který předložil nabídku s nejnižší nabídkovou cenou. Pokud bude i po aplikaci tohoto pravidla platit stav rovnosti dvou či více nabídek, rozhodne o výběru nejvhodnější z těchto nabídek čas podání, přičemž bude platit, že lépe se umístí ta nabídka, která byla podána dříve.

18.1.6. Dodavatel není oprávněn podmínit jím navrhované podmínky, které jsou předmětem hodnocení, další podmínkou. Podmínění nebo uvedení několika rozdílných hodnot, které jsou předmětem hodnocení, může být důvodem pro vyloučení dodavatele ze zadávacího řízení.

18.2. Hodnotící kritérium „Celková nabídková cena bez DPH“

18.2.1. V rámci tohoto kritéria hodnocení bude Zadavatel hodnotit Celkovou nabídkovou cenu v Kč bez DPH, která bude automaticky vypočtena v Příloze č. 4 této Zadávací dokumentace, resp. na listu s názvem „A. Nabídková cena“, poté co dodavatel vyplní do tabulky jednotkové nabídkové ceny k jednotlivým částem dodávky – nabídkové ceny budou doplněny dodavatelem do všech oranžově označených polí tabulky.

18.2.2. Nejvýhodnější nabídkou v rámci tohoto kritéria hodnocení bude nabídka s nejnižší Celkovou nabídkovou cenou v Kč bez DPH. Taková nabídka získá 100 bodů. Ostatní nabídky získají počet bodů v poměru nejnižší Celkové nabídkové ceny v Kč bez DPH k hodnocení Celkové nabídkové ceně v Kč bez DPH podle vzorce:

Počet bodů = 100 *

nejnižší Xxxxxxx nabídková cena v Kč bez DPH hodnocená Celková nabídková cena v Kč bez DPH

18.3. Hodnotící kritérium „Výchozí funkcionality“

18.3.1. Zadavatel bude v rámci tohoto kritéria hodnotit kvalitu nabízeného řešení, a to v tom směru, zda dodavatelem nabídnutý Standardní Software (pozn. definice tohoto pojmu je uvedena v Příloze č. 10 této Zadávací dokumentace, tj. v Závazném vzoru Smlouvy, resp. v jejích součástech) bude naplňovat jednotlivé požadavky Zadavatele (tyto požadavky jsou uvedeny v Příloze č. 4 této Zadávací dokumentace, a to konkrétně na listu s názvem „B1. Povinné požadavky TS s hodnocením kvality“) již svými výchozími funkcionalitami (tzn. že nebude nutné realizovat dovývoj Standardního Softwaru pro potřeby Zadavatele), nebo zda dodavatelem nabídnuté řešení nebude naplňovat rovnou jednotlivé požadavky Zadavatele a bude tak nutný dovývoj daného řešení, přičemž tento dovývoj zajistí, že všechny jednotlivé požadavky Zadavatele budou naplněny.

Zadavatel přitom bude lépe hodnotit takové řešení, které naplní, co nejvíce požadavků Zadavatele již výchozími funkcionalitami. Lze totiž očekávat, že Standardní Software bude pro Zadavatele výhodnější, neboť bude v čase dodavatelem rozvíjen a zlepšován, přičemž s tímto nebudou na straně Zadavatele vznikat finanční náklady. V případě řešení, které bude nutné dovyvinout, tak aby byly naplněny všechny požadavky Zadavatele, je nutné počítat s tím, že zlepšování části řešení, která bude ze strany dodavatele vyvinuta (dovyvinuta) pro potřeby Zadavatele, nebude probíhat v rámci běžného rozvoje Standardního Softwaru a bude tak možné jen za předpokladu dalších vynaložených nákladů ze strany Zadavatele; Zadavatel proto bude tento způsob řešení hodnotit méně výhodněji.

Dodavatel pro účely tohoto kritéria využije Přílohu č. 4 této Zadávací dokumentace – konkrétně list s názvem „B1. Povinné požadavky TS s hodnocením kvality“, na němž je uveden výčet jednotlivých požadavků Zadavatele a jejich popis (viz sloupec D a E tabulky). Dodavatel bude na uvedeném listu vyplňovat pouze políčka, která jsou označena oranžovou barvou.

Pokud bude dodavatelem nabízený Standardní Software uvedený požadavek rovnou splňovat, do sloupce G tabulky dodavatel uvede „ANO“ a obdrží 1 bod; pokud ovšem dodavatelem nabízené řešení uvedený požadavek bude splňovat až nadstavbovým řešením, tj. dovývojem, do sloupce G tabulky dodavatel uvede „NE“ a obdrží 0 bodů. Sloupec H tabulky se vždy vyplní automaticky, a to dle odpovědi, kterou dodavatel uvede do sloupce G tabulky. Přidělený počet bodů bude patrný ze sloupce J tabulky. Dodavatel může takto získat maximálně 100 bodů – počet získaných bodů bude zřejmý z tabulky nacházející se v horní části listu s názvem „B1. Povinné požadavky TS s hodnocením kvality“, a to poté co dodavatel vyplní sloupec G tabulky.

Dodavatel současně na list s názvem „B1. Povinné požadavky TS s hodnocením kvality“ uvede do sloupce I tabulky odkaz na konkrétní část svého návrhu realizace (viz článek 15.1. této Zadávací dokumentace) nebo konkrétní (relevantní) text použitý v návrhu realizace; z uvedeného odkazu či textu přitom musí vyplývat, zda konkrétní požadavek bude naplněn rovnou nebo bude naplněn až nadstavbovým řešením, tj. dovývojem. Zadavatel k tomuto dodává, že odkaz či text uvedený ve sloupci I tabulky musí být v souladu s odpovědí, kterou dodavatel uvedl do sloupce G (resp. H) tabulky.

Následně bude vypočteno bodové hodnocení dle následujícího vzorce:

Počet bodů získaných dodavatelem, jehož nabídka je hodnocena

Počet bodů = 100 *

Maximální možný počet bodů, který lze v tomto kritériu

hodnocení získat (tj. 100 bodů)

Jako nejvýhodnější bude dle tohoto kritéria hodnocena nabídka dodavatele, kterému bude přidělen nejvyšší počet bodů.

Zadavatel dodává, že dodavatel je povinen v Příloze č. 4 této Zadávací dokumentace – konkrétně na listu s názvem „B1. Povinné požadavky TS s hodnocením kvality“ - vyplnit i sloupec F tabulky (pozn. tento sloupec F nesouvisí s hodnotícím kritériem „Výchozí funkcionality“). Do tohoto sloupce dodavatel doplní, zda jím nabízené řešení (tj. nabídnutý Standardní Software nebo nabídnuté řešení počítající s dovývojem) daný požadavek vůbec naplňuje. Zadavatel v této souvislosti uvádí, že nabízený návrh realizace musí vždy jednotlivé požadavky naplňovat, jinak by nebyly naplněny zadávací podmínky.

Zadavatel dále upozorňuje dodavatele, že součástí Přílohy č. 4 této Zadávací dokumentace je i list s názvem „B0 Povinné požadavky TS bez hodnocení“. Tento list ovšem nesouvisí s hodnocením nabídek. Význam tohoto listu a informace týkající se vyplnění tohoto listu Zadavatel uvedl v článku 15.2. této Zadávací dokumentace.

Zadavatel upozorňuje, že Přílohu č. 4 této Zadávací dokumentace, resp. její list s názvem „B1. Povinné požadavky TS s hodnocením kvality“, není možné po uplynutí lhůty pro podání nabídek doplňovat či jakkoliv upravovat. Pokud Zadavatel při hodnocení nabídek zjistí, že údaj uvedený dodavatelem na listu s názvem „B1. Povinné požadavky TS s hodnocením kvality“ neodpovídá údajům uvedeným v předloženém návrhu řešení (tzn. že údaje uvedené v těchto dokumentech budou ve vzájemném rozporu), přistoupí bez dalšího k vyloučení konkrétního dodavatele ze zadávacího řízení pro nesplnění zadávacích podmínek.

18.4. Hodnotící kritérium „Preference“

Zadavatel v Příloze č. 4 této Zadávací dokumentace – konkrétně na listu s názvem „C.

„Preference“ - identifikoval 7 architektonických oblastí, kde formuloval své technické preference vyplývající z architektonického prostředí Zadavatele. Zadavatel bude preferovat, a tudíž i lépe hodnotit takové řešení (návrh realizace), které bude uvedené preference naplňovat.

Dodavatel pro účely tohoto kritéria využije Přílohu č. 4 této Zadávací dokumentace – konkrétně list s názvem „C. Preference“, na němž jsou uvedeny preference Zadavatele (viz sloupec D a E tabulky). Dodavatel bude na uvedeném listu vyplňovat pouze políčka, která jsou označena oranžovou barvou.

Pokud dodavatelem nabízené řešení bude preferenci Zadavatele naplňovat, do sloupce F tabulky dodavatel uvede „ANO“ a obdrží 1 bod; pokud ovšem dodavatelem nabízené řešení nebude preferenci Zadavatele naplňovat, do sloupce F tabulky dodavatel uvede „NE“ a obdrží 0 bodů. Sloupec G tabulky se vždy vyplní automaticky, a to dle odpovědi, kterou dodavatel uvede do sloupce F tabulky. Přidělený počet bodů bude patrný ze sloupce I tabulky. Dodavateli může takto získat maximálně 7 bodů – počet získaných bodů bude zřejmý z tabulky nacházející se v horní části listu s názvem „C. Preference“, a to poté co dodavatel vyplní sloupec F tabulky.

Dodavatel současně na list s názvem „C. Preference“ uvede do sloupce H tabulky odkaz na konkrétní část svého návrhu realizace (viz článek 15.1. této Zadávací dokumentace) nebo konkrétní (relevantní) text použitý v návrhu realizace; z uvedeného odkazu či textu musí přitom vyplývat, zda nabízení řešení bude preferenci Zadavatele naplňovat či nikoliv. Zadavatel k tomuto dodává, že odkaz či text uvedený ve sloupci H tabulky musí být v souladu s odpovědí, kterou dodavatel uvedl do sloupce F (resp. G) tabulky.

Následně bude vypočteno bodové hodnocení dle následujícího vzorce:

Počet bodů získaných dodavatelem, jehož nabídka je hodnocena

Počet bodů = 100 *

Maximální možný počet bodů, který lze v tomto kritériu

hodnocení získat (tj. 7 bodů)

Jako nejvýhodnější bude dle tohoto kritéria hodnocena nabídka dodavatele, kterému bude přidělen nejvyšší počet bodů.

Zadavatel upozorňuje, že Přílohu č. 4 této Zadávací dokumentace, resp. její list s názvem „C. Preference“, není možné po uplynutí lhůty pro podání nabídek doplňovat či jakkoliv upravovat. Pokud Zadavatel při hodnocení nabídek zjistí, že údaj uvedený dodavatelem na listu s názvem „C. Preference“ neodpovídá údajům uvedeným v předloženém návrhu řešení (tzn. že údaje uvedené v těchto dokumentech budou ve vzájemném rozporu), přistoupí bez dalšího k vyloučení konkrétního dodavatele ze zadávacího řízení pro nesplnění zadávacích podmínek.

19. Zadávací dokumentace:

19.1. Uveřejnění Zadávací dokumentace

19.1.1. Zadávací dokumentací se rozumí veškeré písemné dokumenty obsahující zadávací podmínky, sdělované nebo zpřístupňované účastníkům zadávacího řízení při zahájení zadávacího řízení, včetně změn či doplnění zadávací dokumentace podle § 99 ZZVZ, včetně formulářů podle § 212 ZZVZ a výzev uvedených v příloze č. 6 ZZVZ.

19.1.2. V souladu s § 96 odst. 1 a 2 ZZVZ je Zadávací dokumentace zveřejněna na profilu Zadavatele na internetové adrese: xxxxx://xxxxxxx.xxxxxxxxxxxxxx.xx/. Tamtéž budou uveřejňovány i vysvětlení, změny nebo doplnění Zadávací dokumentace této veřejné zakázky.

19.1.3. Součástí Zadávací dokumentace jsou důvěrné informace ve smyslu § 36 odst. 8 ZZVZ v návaznosti na zákon č. 181/2014 Sb., o kybernetické bezpečnosti, ve znění pozdějších předpisů, resp. vyhlášku č. 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, ve znění pozdějších předpisů. Jde zejména o dokument s názvem „Popis aplikací a prostředí“, který tvoří Přílohu č. 2 této Zadávací dokumentace; tento dokument nebude dodavatelům zpřístupněn na profilu Zadavatele a Zadavatel je v souladu s ustanoveními § 36 odst. 8 ZZVZ a § 96 odst. 2 ZZVZ předá osobně dodavatelům po uzavření Dohody o ochraně důvěrných informací, která je uvedena jako Příloha č. 9 této Zadávací dokumentace.

19.1.4. Dodavatelé převezmou uvedenou Přílohu č. 2 této Zadávací dokumentace na základě protokolu osobně v sídle Zadavatele po předchozí domluvě se Zadavatelem. Dodavatel není oprávněn si pořizovat jakékoliv opisy či kopie příslušné přílohy Zadávací dokumentace obsahující informace důvěrné povahy.

19.1.5. Dodavatelé jsou povinni vrátit příslušnou Přílohu č. 2 této Zadávací dokumentace zpět nebo je zničit či odstranit ze všech svých uložišť, a to nejpozději do 5 pracovních dnů od uplynutí lhůty pro podání nabídek.

19.1.6. Vybranému dodavateli, se kterým bude uzavřena Smlouva, bude Příloha č. 2 této Zadávací dokumentace (která bude i přílohou Závazného vzoru Smlouvy) ponechána pro potřeby plnění veřejné zakázky.

19.2. Vysvětlení Zadávací dokumentace

19.2.1. Zadavatel může Zadávací dokumentaci vysvětlit, pokud takové vysvětlení, případně související dokumenty, uveřejní na profilu Zadavatele, a to nejméně 5 pracovních dnů před uplynutím lhůty pro podání nabídek.

19.2.2. Pokud žádost o vysvětlení Zadávací dokumentace doručí dodavatel ve stanové lhůtě písemnou formou, a to elektronicky, Zadavatel vysvětlení uveřejní prostřednictvím elektronického nástroje E-ZAK, včetně přesného znění žádosti bez identifikace tohoto dodavatele, na profilu Zadavatele. Zadavatel není povinen vysvětlení poskytnout, pokud není žádost o vysvětlení doručena včas, a to alespoň 3 pracovní dny před uplynutím shora uvedené lhůty 5 pracovních dnů. Písemná žádost tedy musí být Zadavateli doručena nejpozději 8 pracovních dnů před uplynutím lhůty pro podání nabídek. Pokud Zadavatel na žádost o vysvětlení, která není doručena včas, vysvětlení poskytne, nemusí uvedené lhůty dodržet. Žádost o vysvětlení Zadávací dokumentace musí být podána v českém jazyce, na žádost podanou v jiném, než v českém jazyce se hledí jako by nebyla podána včas.

19.2.3. Pokud dodavatel požádá o vysvětlení ve vztahu k neveřejné části Zadávací dokumentace, Zadavatel vysvětlení rozešle všem dodavatelům, kteří splnili podmínky pro obdržení neveřejné části zadávací dokumentace. V případě, že dodavatel získá přístup k neveřejná části poté, co byl již takový dotaz rozeslán, obdrží spolu s dokumenty obsaženými v neveřejné části i takové vysvětlení Zadávací doumentace.

19.2.4. Zadavatel i v tomto případě není povinen vysvětlení poskytnout, pokud není žádost o vysvětlení doručena včas, a to alespoň 3 pracovní dny před uplynutím shora uvedené lhůty

5 pracovních dnů. Písemná žádost tedy musí být Zadavateli doručena nejpozději 8 pracovních dnů před uplynutím lhůty pro podání nabídek. Pokud Zadavatel na žádost o vysvětlení neveřejné části Zadávací dokumentace, která není doručena včas, vysvětlení poskytne, nemusí uvedené lhůty dodržet, i tato žádost musí být podána v českém jazyce.

19.3. Zadavatel je oprávněn uveřejnit na profilu Zadavatele za podmínek § 99 ZZVZ rovněž změnu nebo doplnění Zadávací dokumentace.

20. Závaznost pokynů Zadavatele

20.1. Informace a údaje uvedené v této Zadávací dokumentaci vymezují závazné požadavky Zadavatele na plnění veřejné zakázky. Tyto požadavky je dodavatel povinen plně a bezvýhradně respektovat při zpracování své nabídky. Neakceptování požadavků Zadavatele uvedených v této Zadávací dokumentaci může být považováno za nesplnění zadávacích podmínek s následkem vyloučení dodavatele ze zadávacího řízení.

20.2. V případě, že zadávací podmínky obsahují odkazy na specifická označení výrobků a služeb, která platí pro určitého podnikatele (osobu) za příznačná, umožňuje Zadavatel použití i jiných, kvalitativně a technicky obdobných řešení, které naplní Zadavatelem požadovanou funkcionalitu (byť jiným způsobem).

21. Komunikace mezi Zadavatelem a dodavatelem:

21.1. Veškerá komunikace mezi Zadavatelem a dodavatelem musí být v souladu s § 211 ZZVZ vedena pouze písemnou formou, a to elektronicky, s výjimkou případů vymezených v ustanovení § 211 odst. 3 ZZVZ. Doručování písemností a komunikace mezi Zadavatelem a dodavatelem bude ze strany Zadavatele probíhat prostřednictvím elektronického nástroje E-ZAK (na adrese: xxxxx://xxxxxxx.xxxxxxxxxxxxxx.xx/), který splňuje podmínky vyhlášky č. 260/2016 Sb., o stanovení podrobnějších podmínek týkajících se elektronických nástrojů, elektronických úkonů při zadávání veřejných zakázek a certifikátu shody, ve znění pozdějších předpisů. Na komunikaci ze strany dodavatelů učiněnou elektronicky, avšak nikoliv prostřednictvím elektronického nástroje E-ZAK, bude tedy Zadavatel vždy odpovídat prostřednictvím elektronického nástroje.

21.2. Zpracování osobních údajů včetně jejich zvláštních kategorií případně poskytnutých v průběhu zadávacího řízení je Zadavatelem prováděno pouze za účelem zadání Veřejné zakázky, přičemž Zadavatel v celém procesu ochrany osobních údajů postupuje v souladu s Nařízením Evropského parlamentu a Rady (EU) 2016/679, o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES, obecně závaznými právními předpisy a vnitřními předpisy Zadavatele, které agendu ochrany osobních údajů upravují.

22. Požadavky Zadavatele na zpracování nabídky, způsob podání nabídek a otevírání nabídek

22.1. Účastník předloží úplnou elektronickou verzi nabídky, a to s využitím elektronického nástroje E-ZAK. Způsob správného podání nabídky v elektronické podobě na veřejnou zakázku je uveden v uživatelské příručce elektronického nástroje E-ZAK pro dodavatele, která je k dispozici na internetové stránce profilu Zadavatele: xxxxx://xxxxxxx.xxxxxxxxxxxxxx.xx/xxxxxx.xxxx.

22.2. Pro tyto účely a v souladu se ZZVZ systém vyžaduje registraci účastníků a elektronický podpis založený na kvalifikovaném certifikátu. Podáním nabídky účastník se stanovenou formou komunikace a doručování souhlasí a zavazuje se poskytnout veškerou nezbytnou součinnost, zejména provést registraci v elektronickém nástroji E-ZAK a pravidelně kontrolovat doručené zprávy.

22.3. Účastník je povinen přiložit ke své nabídce čestné prohlášení o tom, že v souvislosti se zadávacím řízením na předmětnou veřejnou zakázku neuzavřel a neuzavře s jinými osobami zakázanou dohodu ve smyslu zákona č. 143/2001 Sb., o ochraně hospodářské soutěže a o změně některých zákonů (zákon o ochraně hospodářské soutěže), ve znění pozdějších předpisů. Vzor čestného prohlášení je upraven jako Příloha č. 7 této Zadávací dokumentace.

22.4. Pro zpracování nabídky Zadavatel doporučuje níže uvedené řazení dokladů a dokumentů:

a) Obsah nabídky,

b) Čestné prohlášení ve vztahu k zakázaným dohodám (dodavatel v této souvislosti použije Přílohu č. 7 této Zadávací dokumentace),

c) Čestné prohlášení ve vztahu k zákonu o registru smluv (dodavatel v této souvislosti použije Přílohu č. 8 této Zadávací dokumentace),

d) Čestné prohlášení ke střetu zájmů (dodavatel v této souvislosti použije Přílohu č. 12 této Zadávací dokumentace),

e) Doklady prokazující splnění základní způsobilosti (dodavatel v této souvislosti použije Přílohu č. 5 této Zadávací dokumentace a dále předloží doklady dle článku 9.1. této Zadávací dokumentace),

f) Doklady prokazující splnění profesní způsobilosti,

g) Doklady prokazující splnění technické kvalifikace (dodavatel v této souvislosti použije Přílohu č. 6 této Zadávací dokumentace),

h) Návrh realizace, který bude zpracován dle článku 15.1. této Zadávací dokumentace (dodavatel v této souvislosti použije Přílohu č. 3 této Zadávací dokumentace),

i) Matice požadavků obsahující údaje nezbytné pro hodnocení nabídek dle článku 18. této Zadávací dokumentace (dodavatel v této souvislosti použije Přílohu č. 4 této Zadávací dokumentace),

j) Závazný vzor Smlouvy (dodavatel v této souvislosti použije Přílohu č. 10 této Zadávací dokumentace),

k) Seznam poddodavatelů (dodavatel v této souvislosti použije Přílohu č. 11 této Zadávací dokumentace),

l) Ostatní dokumenty, které mají dle dodavatele tvořit nabídku.

22.5. Nabídka musí být podána elektronickými prostředky prostřednictvím elektronického nástroje E-ZAK, který je profilem Zadavatele, a to v českém jazyce nebo v souladu s ustanovením § 45 odst. 3 ZZVZ. Zadavatel nepřipouští podání nabídky v listinné podobě ani v jiné elektronické formě mimo elektronický nástroj E-ZAK.

22.6. Nabídky podávané v elektronické podobě účastník doručí do konce níže uvedené lhůty pro podání nabídek, a to prostřednictvím elektronického nástroje E-ZAK na níže uvedenou elektronickou adresu xxxxx://xxxxxxx.xxxxxxxxxxxxxx.xx/.

22.7. Dokumenty musí být do systému E-ZAK vkládány jako jeden soubor (ve výše uvedených formátech) nebo více zkomprimovaných souborů ve formátu zip, rar nebo 7z, bez použití hesla. Zkomprimované soubory nesmí obsahovat žádný další zkomprimovaný soubor. Zadavatel upozorňuje, že systém elektronického zadávání veřejných zakázek E-ZAK umožňuje pracovat se soubory o velikosti nejvýše 50 MB za jeden takový soubor, příp. zkomprimované soubory. Soubory většího rozsahu je nutno před jejich odesláním prostřednictvím E-ZAK vhodným způsobem rozdělit. Velikost samotné nabídky jako celku není nijak omezena.

22.8. Lhůta pro podání nabídek bude stanovena prostřednictvím elektronického nástroje E-ZAK.

22.9. Otevírání nabídek je neveřejné a bude zahájeno po uplynutí lhůty pro podání nabídek.

23. Informace pro dodavatele a podmínky pro uzavření smlouvy:

23.1. Zadavatel si v souladu s § 170 ZZVZ vyhrazuje právo zrušit zadávací řízení.

23.2. Požadavky Zadavatele pro uzavření smlouvy

23.2.1. Vybraný dodavatel je povinen Zadavateli na písemnou výzvu učiněnou dle § 122 odst. 3 písm. a) ZZVZ předložit doklady prokazující kvalifikaci dle této Zadávací dokumentace (tj. předložení originálů nebo ověřených kopií dokladů o kvalifikaci).

23.2.2. U vybraného dodavatele, je-li českou právnickou osobou, Zadavatel zjistí údaje o jeho skutečném majiteli podle zákona upravujícího evidenci skutečných majitelů (dále jen "skutečný majitel") z evidence skutečných majitelů podle téhož zákona (dále jen "evidence skutečných majitelů").

Vybraného dodavatele, je-li zahraniční právnickou osobou, Zadavatel vyzve k předložení výpisu ze zahraniční evidence obdobné evidenci skutečných majitelů nebo, není-li takové evidence,

a) ke sdělení identifikačních údajů všech osob, které jsou jeho skutečným majitelem, a

b) k předložení dokladů, z nichž vyplývá vztah všech osob podle předchozího písmene

a) k dodavateli; těmito doklady jsou zejména:

- výpis ze zahraniční evidence obdobné veřejnému rejstříku,

- seznam akcionářů,

- rozhodnutí statutárního orgánu o vyplacení podílu na zisku,

- společenská smlouva, zakladatelská listina nebo stanovy.

23.2.3. Zadavatel vyloučí vybraného dodavatele, je-li českou právnickou osobou, která má skutečného majitele, pokud nebylo možné zjistit údaje o jeho skutečném majiteli z evidence skutečných majitelů (k zápisu zpřístupněnému v evidenci skutečných majitelů po odeslání oznámení o vyloučení dodavatele se nepřihlíží). Zadavatel vyloučí vybraného dodavatele, je- li zahraniční právnickou osobou, pokud nepředložil údaje.

23.2.4. Zadavatel upozorňuje, že preferuje uzavírání smluv v elektronické podobě prostřednictvím některého druhu zaručených elektronických podpisů. V případě, že dodavatel není schopen k takovému postupu zajistit Zadavateli součinnost, žádáme, aby Zadavatele o této skutečnosti informoval ve své nabídce, a to v průvodní zprávě k nabídce.

24. Střet zájmů dle zákona č. 159/2006 Sb., o střetu zájmů, ve znění pozdějších předpisů

24.1. Dle § 4b zákona č. 159/2006 Sb., o střetu zájmů, ve znění pozdějších předpisů (dále jen

„Zákon o střetu zájmů“) se nesmí účastnit zadávacích řízení dle ZZVZ jako účastník zadávacího řízení nebo jako poddodavatel, prostřednictvím kterého účastník zadávacího řízení prokazuje kvalifikaci, obchodní společnost, ve které veřejný funkcionář uvedený v § 2 odst. 1 písm. c) Zákona o střetu zájmů nebo jím ovládaná osoba vlastní podíl představující alespoň 25 % účasti společníka v obchodní společnosti.

24.2. Zadavatel požaduje, aby dodavatel a jeho poddodavatel, prostřednictvím kterého prokazuje kvalifikaci, nebyli ve střetu zájmů dle § 4b Zákona o střetu zájmů. Skutečnost, že dodavatel a jeho poddodavatel, prostřednictvím kterého prokazuje část kvalifikace, nejsou ve střetu zájmů dle § 4b Zákona o střetu zájmů, prokáže dodavatel předložením čestného prohlášení, jehož vzor tvoří Přílohou č. 12 této Zadávací dokumentace v žádosti o účast.

24.3. Vybraný dodavatel je povinnen předložit k výzvě Zadavatele dle § 122 odst. 3 písm. b) ZZVZ doklady a informace, z nichž nepochybně vyplyne, že vybraný dodavatel i všichni poddodavatelé, jimiž vybraný dodavatel prokazuje kvalifikaci, splňují podmínku neexistence střetu zájmů ve smyslu § 4b Zákona o střetu zájmů a tohoto článku Zadávací dokumentace. V případě vybraného dodavatele nebo jeho poddodavatele, prostřednictvím kterého vybraný dodavatel prokazoval část kvalifikace, je-li zahraniční právnickou osobou, je vybraný dodavatel povinnen předložit zejména doklady ve smyslu § 122 odst. 5 ZZVZ a to i ve vztahu k příslušnému poddodavateli, prostřednictvím kterého vybraný dodavatel prokazoval část kvalifikace.

24.4. V případě, že účastník zadávacího řízení bude postupovat v rozporu s článkem 24. této Zadávací dokumentace, bude účastník zadávacího řízení vyloučen ze zadávacího řízení.

25. Registr smluv

25.1. Zadavatel je povinen uveřejňovat uzavřené smlouvy v registru smluv na základě ustanovení zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv, ve znění pozdějších předpisů (dále jen

„ZRS“).

25.2. Zadavatel na základě výše uvedeného požaduje, aby účastník pro účely uveřejnění smlouvy v registru smluv ve smlouvě, která bude nedílnou součástí nabídky, označil její části, které jsou předmětem obchodního tajemství nebo ty části, ve kterých jsou obsaženy informace, které nemohou být v registru smluv uveřejněny na základě ustanovení § 3 odst. 1 ZRS.

25.3. Pokud účastník ve smlouvě, která bude nedílnou součástí nabídky, označí její části nebo určité informace dle článku 25.2. této Zadávací dokumentace, je účastník povinen předložit Čestné prohlášení. Vzor čestného prohlášení je zpracován jako Příloha č. 8 této Zadávací dokumentace. Tímto čestným prohlášením účastník prohlašuje, že jím uvedené údaje a skutečnosti kumulativně naplňují všechny definiční znaky obchodního tajemství tak, jak je vymezeno v ustanovení § 504 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „obchodní tajemství“) a pro případ, že by takto označené údaje a skutečnosti nenaplňovaly znaky obchodního tajemství a takto znečitelněná smlouva by byla v důsledku toho uveřejněna způsobem odporujícímu ZRS, nese účastník veškerou odpovědnost.

25.4. Výše uvedené čestné prohlášení dle článku 25.3. této Zadávací dokumentace účastník nedokládá v případě, že neoznačí ve smlouvě, která bude nedílnou součástí nabídky, žádné takové časti nebo informace ve smyslu článku 25.2. této Zadávací dokumentace.

25.5. Účastník odpovídá za správnost a pravdivost veškerých údajů a skutečností, které jím budou uvedeny ve výše uvedeném čestném prohlášení. Zadavatel nebude přezkoumávat jejich pravdivost.

25.6. Výjimkou z povinnosti uveřejnění smlouvy v registru smluv jsou důvody uvedené v ustanovení § 3 odst. 2 ZRS. Je-li účastník subjektem uvedeným v ustanovení § 3 odst. 2 písm. k) ZRS (případně je subjektem uvedeným v ustanovení § 3 odst. 2 ZRS dle jiného písmene, než je zde uvedeno), doporučuje Xxxxxxxxx, aby účastník tuto skutečnost uvedl v nabídce. V případě, že tak účastník neučiní, bude Zadavatel postupovat, jako by na smlouvu nedopadala výjimka uvedená v ustanovení § 3 odst. 2 písm. k) ZRS (případně jiná výjimka dle ustanovení § 3 odst. 2 ZRS dle jiného písmene, než je zde uvedeno) a Zadavatel neodpovídá za škodu nebo jakoukoliv jinou újmu tímto postupem vzniklou.

Přílohy zadávací dokumentace

Příloha č. 1. Technická příloha (tato příloha vymezuje předmět veřejné zakázky)

Příloha č. 2. Popis aplikací a prostředí (nezveřejněna na profilu Zadavatele - tato příloha bude poskytnuta dodavatelům po podpisu Dohody o ochraně důvěrných informací)

Příloha č. 3. Šablona nabídky Příloha č. 4. Matice požadavků

Příloha č. 5. Čestné prohlášení ke splnění základní kvalifikace

Příloha č. 6. Čestné prohlášení ke splnění technické kvalifikace (seznam význam. zakázek) Čestné prohlášení ke splnění technické kvalifikace (seznam realizačního týmu)

Příloha č. 7. Čestné prohlášení ve vztahu k zakázaným dohodám Příloha č. 8. Čestné prohlášení ve vztahu k zákonu o registru smluv Příloha č. 9. Dohoda o ochraně důvěrných informací

Příloha č. 10. Závazný vzor Smlouvy Příloha č. 11. Seznam poddodavatelů

Příloha č. 12. Čestné prohlášení ke střetu zájmů

Xx. Xxxx Xxxxxxx, MBA

generální ředitel

Draft

Příloha č. 1 Zadávací dokumentace

Klasifikace: Veřejný dokument

TECHNICKÁ PŘÍLOHA – SPECIFIKACE TECHNICKÝCH POŽADAVKŮ PRO ZADÁVACÍ ŘÍZENÍ CENTRALNÍHO LOG MANAGEMENTU

Správa železnic, státní organizace Sídlo: Dlážděná 1003/7, 110 00 Praha 1

zapsána v obchodním rejstříku vedeném MěstskýmIČO: 709 94 234 DIČ: CZ 709 94 234

0/38soudem v Praze, spisová značka A 48384

xxxxxxxxxxxxxx.xx

Obsah

1 Verze dokumentu 3

2 Seznam zkratek 4

Computer security incident response team 4

Česká státní norma 4

Garant podpůrného aktiva 4

3 Úvod 7

3.1 Předmět plnění veřejné zakázky 7

4 Současný stav a popis prostředí 9

4.1 Souhrnné objemy logů 9

4.2 Specifické aplikace SŽ 10

4.3 Generické systémy a aplikace 11

Odstraněno: 8

Odstraněno: 9

Odstraněno: 10

4.3.1 Doménové řadiče, operační systémy, služby 11

Odstraněno: 10

4.3.2 Síťové technologie 16

Odstraněno: 15

4.4 Bezpečnostní technologie 18

5 Požadavky CLM 19

5.1 Funkční požadavky 19

5.2 Architektura řešení 22

5.3 SW a HW 23

5.4 Zajištění vysoké dostupnosti 24

5.5 Integrace 24

5.6 Požadavky dle § 22 vyhlášky č. 82/2018 25

Odstraněno: 17

Odstraněno: 18

Odstraněno: 21

Odstraněno: 22

Odstraněno: 23

Odstraněno: 24

5.6.1 Bezpečnostní monitoring jako součásti CLM 27

Odstraněno: 26

5.7 Počet uživatelů CLM 28

6 Požadavky na dodávku 29

6.1 Analýza 29

6.2 Definice Technického návrhu implementace 29

6.3 Dodávka SW, HW a licencí 32

Odstraněno: 27

Odstraněno: 28

Odstraněno: 31

6.3.1 Dodávka HW 32

Odstraněno: 31

6.3.2 Dodávka SW a licencí 32

Odstraněno: 31

6.4 Dodávka Produkčního a testovacího prostředí 33

6.5 Instalace 33

6.6 Konfigurace 33

6.7 Testování 34

Odstraněno: 32

Odstraněno: 33

6.7.1 Funkční testy 34

Odstraněno: 33

6.7.2 Zátěžové testy 34

Odstraněno: 33

6.7.3 Bezpečnostní testy 34

Odstraněno: 33

6.7.4 Sken zranitelností 35

Odstraněno: 34

6.7.5 Testy zajištění kontinuity 35

Odstraněno: 34

6.8 Pilotní provoz 35

6.9 Dokumentace 36

6.10 Školení 37

6.11 Předání do provozu 37

6.12 Zajištění technické podpory provozu 37

6.13 Nadstandardní služby 38

Odstraněno: 34

Odstraněno: 35

Odstraněno: 36

Odstraněno: 37

1 Verze dokumentu

Verze dokumentu	Datum	Autor	Změny
5.00	20.1.2022	Správa železnic
5.01	17.5.2022	Správa železnic

2 Seznam zkratek

Níže uvedená tabulka obsahuje seznam zkratek a pojmů použitých v rámci této Technické specifikace.

Přehled zkratek a pojmů:

Zkratka	Popis
AD, MS AD	Microsoft Active Directory
ATP/ATI	Advanced Threat Protection
AKB	Architekt kybernetické bezpečnosti
API	Rozhraní pro programování aplikací (Application Programming Interface)
BU	Bezpečnostní událost
CA	Certifikační autorita
CERT	Computer emergency response team
CISO	Manažer informační bezpečnosti (Chief Information Security Officer)
CMDB	Konfigurační databáze (Configuration Management Database)
CSIRT	Computer security incident response team
ČSN	Česká státní norma
CLM, CLS	Centrální Log Management, Centrální logovací systém
DLP	Data Loss Prevention
EPS	Počet událostí za sekundu (Events per Second)
GPA	Garant primárního aktiva
GPdA	Garant podpůrného aktiva
HA	Režim vysoké dostupnosti (High Availability), např. prostřednictvím redundance
Hardening	Hardening je proces zabezpečení konfigurace systému takovým způsobem, který omezí výskyt zranitelností využitelných útočníkem
HIPS	Host Intrusion Prevention System
HW	Hardware
ICT	Informační a komunikační technologie (Information and Communication TechnoLogies)
IDM	Správa uživatelských účtů (Identity Management)
IS	Informační systém
ISVS	Informační systémy veřejné správy
ITSM	IT Service Management

KBI	Kybernetický bezpečnostní incident
KII	Kritická informační infrastruktura
LDAP	Lightweight Directory Access Protocol
XXX	Xxxxx úrovňový design (Low Level Design)
MB	Mega Byte
MCAS	Microsoft Cloud App Security
MD	Člověkoden, pracovní čas jedné osoby odpovídající jednomu pracovnímu dni, tedy typicky 8 hodin (man-day)
MDM	Správa mobilních zařízení (Mobile Device Management)
MFA	Vícefázové ověření (Multifactor Authentication)
On-premise	On-premise software je takový software, který lze instalovat a provozovat v prostorách organizace, která jej využívá
OS	Operační Systém
OTP	Jednorázové heslo (One Time Password)
PAM	Správa privilegovaných přístupů (Privileged Access Management)
PD	Pracovní Den
PKI	Infrastruktura správy a distribuce veřejných klíčů (Public Key Infrastructure)
Privilegovaný účet	Uživatelský účet informačního systému s širokou nebo neomezenou množinou administrátorských oprávnění
RDP	Protokol na přenos vzdálené plochy (Remote Desktop Protocol)
SIEM	Systém pro správu bezpečnostních událostí (Security Information and Event Management)
SLA	Dohoda o úrovni poskytovaných služeb (Service Level Agreement)
SSH	Zabezpečený protokol pro připojení k serverům
SSO	Systém jednotného přihlášení (Single Sign-On)
Stress skript	Skript nebo funkcionalita, která simuluje zátěž systému, například generuje logy apod.
SW	Software
SŽ	Správa železnic, státní organizace
UAS	Uživatelsko-aplikační síť
Uchazeč	Subjekt, který se v rámci tohoto zadávacího řízení uchází o dodávku řešení Centrálního Log Managementu. Uchazeč, který bude vybrán SŽ, se stane dodavatelem
Uživatel CLM	Uživatel CLM je administrátor (interní či externí), který používá CLM řešení pro přístup k záznamům/logům ze spravovaných koncových systémů. Uživatel CLM je také administrátor CLM, který provádí dohled na správný běh CLM a správu jeho konfigurací

Seznam zkratek pro specifické aplikace SŽ:

Zkratka	Popis
ASVC	Automatické stavění vlakových cest
DŘT	Dispečerská řídicí technika
ČD-IS	České dráhy informační systém?
DDTS	Dálková diagnostika technologických systémů
CDP	Centrální dispečerské pracoviště
CDS	Centrální dispečerský systém
DŽDC	Dispečer železniční dopravní cesty
DŽIN	Dispečer železniční infrastruktury
ED	Elektro dispečer
GVD	Grafikon vlakové dopravy
SSZT	Správa sdělovací a zabezpečovací techniky
ST	Správa tratí
SŽE	Správa železniční energetiky
TDS	Technologický a dohledový systém
TECHLAN	Technologická datová síť
TLS	Technologický systém železniční dopravní cesty
TDCDP	Traťový dispečer dálkového ovládání zabezpečovacího zařízení na CDP
VPN	Virtuální privátní síť (Virtual Private Network)
VS	Vlakové soupravy
ŽDC	Železniční dopravní cesta
ZZ	Zabezpečovací zařízení

3 Úvod

Tento dokument je přílohou a nedílnou součástí zadávacího řízení pro výběr dodavatele Centrálního Log Managementu (dále jen “CLM“), pro organizaci Správa železnic, státní organizace (dále jen „SŽ“). Dokument popisuje technické a jiné požadavky na nový CLM. Dále popisuje současný stav prostředí významné pro vznik nového CLM.

3.1 Předmět plnění veřejné zakázky

Předmětem plnění veřejné zakázky je realizace CLM pro SŽ. Tento CLM zajistí sběr, zpracování, dlouhodobé zaručené ukládání, umožní analyzovat a dlouhodobě ukládat záznamy o událostech v komponentách, systémech a aplikacích SŽ tak, aby byly prokazatelné, chráněné a udržované v souladu se zákonnými a dalšími vyjmenovanými požadavky.

Detekce kybernetických bezpečnostních událostí a vyhodnocování kybernetických bezpečnostních událostí není předmětem této veřejné zakázky.

Tato zakázka bude obsahovat následující poptávané oblasti:

- Analýza

o Analýza současného stavu a vytvoření konceptu CLM (podrobněji viz. kapitola 6.1)

- Technický návrh (podrobněji viz. kapitola 6.2)

o Návrh architektury CLM - Vybraný dodavatel na základě analýzy vypracuje Technický návrh implementace v rozsahu a detailu LLD

o Definice procesů a procedur souviseních s řízením CLM

- Dodávka komponent CLM a jejich integrace do prostředí SŽ

o Dodávka hardware, software a licencí (podrobněji viz. kapitola 6.3)

o Zajištění produkčního i testovacího prostředí CLM (podrobněji viz. kapitoly 6.4 a 6.5)

o Konfigurace a připojení zdrojů logů CLM (podrobněji viz. kapitola 6.6)

o Provedení testů architektonických, funkčních, bezpečnostních a ostatních požadavků CLM (podrobněji viz. kapitola 6.7)

o Zajištění pilotního provozu CLM, jeho vyhodnocení a realizace případných nápravných opatření (podrobněji viz. kapitola 6.8)

- Servisní podpora

o Provedení školení obsluhy CLM (podrobněji viz. kapitoly 6.9 a 6.10)

o Předání CLM do produkčního užívání (podrobněji viz. kapitola 6.11)

o Poskytnutí technické podpory provozu CLM (podrobněji viz. kapitoly 6.12 a 6.13)

Způsob realizace CLM musí zajistit mimo jiné soulad s požadavky §22 Vyhlášky č. 82/2018 Sb. - Zaznamenávání událostí informačního a komunikačního systému, jeho uživatelů a administrátorů – a jeho prováděcích předpisů.

Detailní popis výše uvedených požadavků CLM je uveden v následujících kapitolách tohoto dokumentu.

4 Současný stav a popis prostředí

IT aktiva (dále jen “aktiva”) určená pro napojení na CLM jsou geograficky rozprostřena po celém území České republiky a rozdělena do následujících skupin:

a) Specifické aplikace SŽ

b) Generické systémy a aplikace - operační systémy, databáze, virtuální instance, aktivní prvky a další

c) Bezpečnostní technologie - systémy zařazené jako bezpečnostní prvky v rámci infrastruktury SŽ

S ohledem na citlivost informací detailně popisujících Specifické aplikace SŽ a jejich geografické umístění, budou tyto informace dostupné Uchazeči pouze na základě podepsané dohody o mlčenlivosti jejíž vzor je v Příloze č. 9 Zadávací dokumentace

4.1 Souhrnné objemy logů

Výpočet odhadu objemu logů a EPS, který bude zpracovávat CLM, vychází z informací dostupných v době zveřejnění tohoto dokumentu. Dále u aktiv, pro která nejsou žádné informace o objemu logů k dispozici, odhad souhrnného objemu vychází z předpokladu 70% vytíženosti maximální kapacity aktiva. Pro některá aktiva byl zvolen prostý odhad dle velikosti SŽ.

Uvedené objemy a informace jsou dynamického charakteru a při změně logovací strategie může dojít k jejich změně.

V rámci analýzy provedené vybraným dodavatelem mohou být poskytnuty informace z provozního monitoringu a data zatížení jednotlivých aktiv pro provedení vlastního odhadu velikosti a typu logů – zejména pro aktiva, která v následujících kapitolách nemají uvedený objem logů nebo další informace.

Pro každou skupinu aktiv je specifikována podmnožina aktiv podle seznamu primárních a podpůrných aktiv, která tvoří kritickou informační infrastrukturu a musí být tedy řízena podle § 22, vyhlášky č.82/2018 a požadavků definovaných v Kapitole 5.6 Požadavky dle

§ 22 vyhlášky č. 82/2018.

Skupina	Objem dat za 24 hodin	Z toho podíl kritické informační infrastruktury	EPS
Specifické aplikace SŽ	800 GB	25 %	20 000
Generické systémy a aplikace	17 TB	25 %	100 000
Bezpečnostní technologie	2 TB	30 %	15 000
Celkem	19,8 TB	5,05 TB	135 000

4.2 Specifické aplikace SŽ

Přehled specifických aplikací SŽ, včetně formátu a odhadu objemu sbíraných logů podle metodiky uvedené v Kapitole 4.1. Souhrnné objemy logů.

Přehled specifických aplikací SŽ:

ID	Typ			Název aplikace	Objemu logů za den [MB]	Formát
1	Specifické	aplikace	SŽ	DŘT	4 514	log, csv
2	Specifické	aplikace	SŽ	DDTS	-	n/a
3	Specifické	aplikace	SŽ	ISOŘ	1,04	SQL DB, txt
4	Specifické	aplikace	SŽ	ISOŘ RDV	0,44	SQL DB, txt
5	Specifické	aplikace	SŽ	EDD	124 275	log
6	Specifické	aplikace	SŽ	GTN (celkem 650 instancí)	200 000	log
7	Specifické	aplikace	SŽ	ROSA I	43 571	txt
8	Specifické	aplikace	SŽ	Portál provozování dráhy	14,4	adresářová struktura, události v samostatných souborech log
9	Specifické	aplikace	SŽ	KADR	-	SQL, DB, txt
	Specifické	aplikace	SŽ	GRADO (celkem až 150 instancí)	1 400	html, log
10	Specifické	aplikace	SŽ	GRADO (celkem až 150 instancí)	1 400	html, log
11	Specifické	aplikace	SŽ	ComposT	-	syslog, DB logy Oracle, txt formát apl. logu
12	Specifické	aplikace	SŽ	Rozkazy	2 028	log, členěno podle zdroje, systémové logy Windows, txt
13	Specifické	aplikace	SŽ	SAP ERP (R/3, do budoucna S/4)	-	-
14	Specifické	aplikace	SŽ	Spisová služba (ERMS)	-	-
15	Specifické	aplikace	SŽ	Dodavatelé, odběratelé – žádanky systém	-	-
16	Specifické	aplikace	SŽ	IS C.E.Sta	-	-
17	Specifické	aplikace	SŽ	ISPD	-	-
18	Specifické	aplikace	SŽ	Provozní stav sítě tratí (PSST)	-	-
19	Specifické	aplikace	SŽ	Hybridní model zúčtování TEE	-	-
20	Specifické	aplikace	SŽ	DCS (Data Collection System) - sběr dat z elektroměrů lokomotiv	-	-
21	Specifické	aplikace	SŽ	Zákaznický portál Energie	-	-
22	Specifické	aplikace	SŽ	KAC (Kontrolně-analytické centrum)	-	-
23	Specifické	aplikace	SŽ	Centrální rozkazy	-	-
24	Specifické	aplikace	SŽ	CI Common interface	-	-

25	Specifické aplikace SŽ	CSV	-	-
26	Specifické aplikace SŽ	Datový sklad SŽDC	-	-
27	Specifické aplikace SŽ	DOMIN (TSI databáze omezení infrastruktury)	-	-
28	Specifické aplikace SŽ	ETD – Electronic Timetable Display	-	-
29	Specifické aplikace SŽ	EZOP – Elektronický zobrazovací panel	-	-
30	Specifické aplikace SŽ	IS MIMOZA	-	txt
31	Specifické aplikace SŽ	KANGO-IS komplexní sestava jízdního řádu	0,5	-
32	Specifické aplikace SŽ	KAPO	120	txt
33	Specifické aplikace SŽ	REVOZ (Registr vozidel)	20	txt
34	Specifické aplikace SŽ	VITAMIN	100	txt
35	Specifické aplikace SŽ	RNE TIS (Europtirails)	-	-
36	Specifické aplikace SŽ	KISKAN SŽDC	-	-
37	Specifické aplikace SŽ	MIMOZA PŘEKÁŽKY aplikační server	5	txt
38	Specifické aplikace SŽ	MIMOZA PŘEKÁŽKY klient	0,25	txt
39	Specifické aplikace SŽ	MIMOZA PŘEKÁŽKY importní modul	120	txt

4.3 Generické systémy a aplikace

Přehled generických systémů a aplikací, včetně typu logu a odhadu objemu sbíraných logů, a počtu instancí systémů podle metodiky uvedené v Kapitole 4.1. Souhrnné objemy logů.

Generické systémy a aplikace jsou rozděleny na:

a) Doménové řadiče, operační systémy, služby

b) Síťové technologie

4.3.1 Doménové řadiče, operační systémy, služby

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

Active Directory

doména UADF

Odhad Logů v MB za den:4 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

Active Directory

doména UADF

Odhad Logů v MB za den:240 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADF

Odhad Logů v MB za den:21 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD01

Odhad Logů v MB za den:4 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD01

Odhad Logů v MB za den:15 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD01

Odhad Logů v MB za den:280 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD02

Odhad Logů v MB za den:5 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD02

Odhad Logů v MB za den:30 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména UADFD02

Odhad Logů v MB za den:25 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

Active Directory

doména MADF

Odhad Logů v MB za den:2 000 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 4 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména MADF

Odhad Logů v MB za den:37 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 4 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména MADF

Odhad Logů v MB za den:4 000 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 4 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména OADF

Odhad Logů v MB za den:1 500 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména OADF

Odhad Logů v MB za den:2 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména OADF

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména EADF

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Active Directory

doména EADF

Odhad Logů v MB za den:5 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

Active Directory

doména EADF

Odhad Logů v MB za den:20 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale doménu tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange CAS server

Odhad Logů v MB za den:250 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale systém tvoří 6 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange CAS server

Odhad Logů v MB za den:40 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 6 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange CAS server

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale systém tvoří 6 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange Content servery

Odhad Logů v MB za den:1 500 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale systém tvoří 15 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange Content servery

Odhad Logů v MB za den:80 000 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 15 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Server

MS Exchange Content servery

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale systém tvoří 15 serverů. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:20 Typ Logu: Windows Log

Application log

V budoucnu budou službu zajišťovat 4 servery, služba je využívána ve VELICE omezené míře, v budoucnu dojde k výraznému navýšení využití.

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

Služba

Doménový řadič

Odhad Logů v MB za den:150 Typ Logu: Windows Log

Security log

V budoucnu budou službu zajišťovat 4 servery, služba je využívána ve VELICE omezené míře, v budoucnu dojde k výraznému navýšení využití.

Služba

Doménový řadič

Odhad Logů v MB za den:50 Typ Logu: Windows Log

System log

V budoucnu budou službu zajišťovat 4 servery, služba je využívána ve VELICE omezené míře, v budoucnu dojde k výraznému navýšení využití.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Application log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Služba

Doménový řadič

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

Typ

Koncový systém

Počet prvků

/ instancí

Poznámka

APP

PROXY

Odhad Logů v MB za den:200 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

APP

PROXY

Odhad Logů v MB za den:10 Typ Logu: Windows Log

System log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

APP

PROXY

Odhad Logů v MB za den:10 Typ Logu: Windows Log

Security log

Hodnoty za jeden server, ale systém tvoří 2 servery. Je tedy potřeba uvažovat o násobku objemu dat logů.

APP

PROXY

Typ Logu: w3c file

Odhad Logů v MB za den:50 000

Provozní proxy logy – logování jednotlivých přístupů

Logy jsou zálohovány a ručně a uchovány pro případné analýzy mimo server.

APP

Doménový řadič

Odhad Logů v MB za den:60 typ Logu Windows Log

Suma za všechny generované logy.

APP

Doménový řadič

Odhad Logů v MB za den:60 typ Logu Windows Log

Suma za všechny generované logy.

Doménový řadič

Odhad Logů v MB za den:11 404 800

Suma za všechny generované logy.

Oracle databáze

4.3.2 Síťové technologie

ID	Typ	Typová řada	Páteř	Počet	Pozn.
1	DWDM páteřní boxy + repeatery	Cisco ONS 15454	ANO	22
2	SDH páteřní boxy Cisco ONS	Cisco ONS 15454	ANO	30
3	SDH páteřní boxy Nortel	OME 6150	ANO	2
4	SDH páteřní boxy Ericsson	SPO 1460	ANO	14
5	SDH přístupové boxy Cisco ONS	Cisco ONS 15305	NE	549

6	SDH přístupové boxy Ericsson				SPO 1460	NE	122
7	SDH přístupové boxy Alcatel				Alcatel-Lucent 1646	NE	57
8	Páteřní datové uzly INTRANET (UAS)				Cisco C 3xxx, C 7xxx, ISR 2xxx, ISR 3xxx, ASR 9xx, ASR 1xxx,	ANO	50
9	Páteřní datové uzly technologické				Cisco ISR 2800, ASR 900	ANO	7
10	Přístupové datové uzly technologické				Cisco ISR 2xxx, 4xxx, 8xx, 9xx	NE	6
11	Přístupové (UAS)	datové	uzly	INTRANET	Cisco C2xxx, C3xxx, ISR všech řad	NE	187
12	Páteřní datové uzly MPLS P				Cisco ASR 9000, ASR 100	ANO	4
13	Páteřní datové uzly MPLS CE				Cisco ASR 900	ANO	3
14	Přístupové datové uzly MPLS PE Cisco				Cisco ASR 900, ASR 9000	ANO	93
15	Přístupové datové uzly MPLS PE NOKIA				7705 - SAR	NE	24
16	VoIP gateways				Cisco C 3700, ISR 2xxx, 4xxx	NE	187
	VoIP gateways				Cisco C 3700, ISR 2xxx, 4xxx	NE	187
17	Switche páteř INTRANET (UAS)				C 29xx, C3xxx, C4000, C6xxx, C9xxx	ANO	39
18	Switche páteř v technologických sítích				C3xxx	ANO	2
19	Switche L3 INTRANET (UAS)				C3xxx, C9xxx	NE	95
20	Switche L2 INTRANET (UAS)				typicky C2950, 2960 C9200	NE	2	810	Malé procento "non Cisco" switchů, např. HP, Zyxel a další
21	Switche L3 TECHLAN				C3xxx, C4000, C9xxx	NE	178
22	Switche L2 TECHLAN				C29xx, C3xxx, C92xx	NE	2	210
23	WiFi controllery				AIR CT25xx, C98xx	ANO	16
24	WiFi AP (řízené controllerem)				AIR AP18xx, IW37xx, C9105	NE	377
25	WiFi AP (autonomní)				Ubiquiti, TRENDnet	NE	6
26	Firewally				ASA, FPW, Fortigate	NE	41

4.4 Bezpečnostní technologie

ID	Typ	Název	Objemu logů za den [MB]	Formát
1	Bezpečnostní technologie	Logserver (ČD-IS)	-	-
2	Bezpečnostní technologie	Azure AD Connect	-	-
3	Bezpečnostní technologie	Azure AD	-	-
4	Bezpečnostní technologie	Vícefaktorové autentizace	-	-
5	Bezpečnostní technologie	PKI	-	-
6	Bezpečnostní technologie	MFA	-	-
7	Bezpečnostní technologie	CA	-	-
8	Bezpečnostní technologie	MDM	-	-
9	Bezpečnostní technologie	Compliance Management	-	-
10	Bezpečnostní technologie	MCAS	-	-
11	Bezpečnostní technologie	ATP/ATI	-	-
12	Bezpečnostní technologie	Bitlocker	-	-
13	Bezpečnostní technologie	Časové servery	-	-
14	Bezpečnostní technologie	Antivirové řešení	-	-
15	Bezpečnostní technologie	PAM	-	-
16	Bezpečnostní technologie	IDM	-	-
17	Bezpečnostní technologie	Tacacs+	-	-
18	Bezpečnostní technologie	Radius	-	-

5 Požadavky CLM

5.1 Funkční požadavky

Název požadavku

Popis požadavku

Škálovatelnost prostředí

• Navrhované řešení musí splňovat všechna kritéria pro budoucí rozšíření systému a škálovatelnost o další:

a) Zdrojové systémy

b) Funkční logování

c) Operace s logy

d) Filtrování

e) Šablony

f) Hardware

• Navržená architektura prostředí musí umožnovat škálování a zvětšování v rámci použitého HW a SW.

• Škálovatelnost celého systému musí být do budoucna schopná akceptovat až pětinásobný objem stávajících logů

Systém musí umožnovat funkcionalitu dlouhodobého uložení logů (logy, které se nebudou dále zpracovávat) dle následujících požadavků:

Dlouhodobé uložení logů

• Dlouhodobě uložené logy musí být uloženy odděleně od CLM úložiště

• Úložiště (HW i SW) dlouhodobě ukládaných logů je součástí dodávky budoucího dodavatele

• Délka uschování všech logů mimo logů primárných a podpůrných aktiv SŽ v dlouhodobě ukládacím režimu: 12 měsíců

• Délka uschování logů primárných a podpůrných aktiv SŽ v dlouhodobě ukládacím režimu: 18 měsíců a v souladu s požadavky § 22, vyhlášky č.82/2018

• CLM systém musí být schopen provádět dlouhodobé ukládání na externím uložišti a mít možnost připojit se na externí uložiště (dlouhodobé úložiště uložiště třetích stran)

Název požadavku

Popis požadavku

Požadavky na funkcionality zpracování logů

• Minimální délka uchování aktuálních logů s možností zpracování: 30 dnů

• Možnost provádění kombinovaných forenzních vyhledávacích možností

v uživatelské konzoli s možností nastavení minimálně následujících parametrů:

a) Zdroj logu (s možností vlastního pojmenování zdroje nebo skupiny zdrojů)

b) Čas vzniku události

c) Čas přijetí logu

d) Kombinace vyhledání s možností podmiňování IF (tj. na základě jedné události v “systému A“ a současně v případě vzniku další události

v „systému B“ vygeneruj akci – e-mail, upozornění, apod.)

e) Automatizované a plánované aktivity v podobě výše popsaného požadavku

f) Možnost vytvoření aktivit na základě nálezu vyhledávaného řetězce

g) vyhledávání musí umožnit hledat kromě zadaných hodnot také s uvedením “wildcards” nebo regulárních výrazů, a to pro všechny podporované atributy (nejen pro vyjmenované)

• Sběr a ukládání nestrukturovaných logů všech datových typů

• Logy se musí ukládat v původním stavu a nesmí být umožněno jejich editování

• Možnost indexace logů

• Možnost automatizace zpracování s pomocí skriptů

• Možnost vizualizace s přednastavenými šablonami

• Možnost normalizace a standardizace dle přednastavených šablon

• Možnost autorizačních oprávnění na úrovni zdroje logů

• Možnost provádět log enrichment na základě aktivit jiných logů a zdrojů

• Logování v reálném čase s maximálním zpožděním nižším než 5 sekund

• Možnost vyhledání a seskupení logových sestav na základě externího zdroje, například stažených šablon

• Možnost zpracování událostí (událost je jeden či více záznamů logicky spojených a zároveň provedených ve stejný časový okamžik)

• Možnost zpracování více událostí korelovaných přes identifikátor

ID Název požadavku Popis požadavku

Zabezpečení

F4 prostředí

F5 Cloudové Logy

• CLM řešení musí používat šifrované uložiště. Musí být použit takový kryptografický algoritmus, který odpovídá požadavkům NÚKIB v dokumentu MINIMÁLNÍ POŽADAVKY NA KRYPTOGRAFICKÉ ALGORITMY

• CLM řešení musí používat autentizační a autorizační mechanismy založené na Centrálním IDM systému implementovaném v SŽ

CLM řešení musí mít možnost lokálního zakládání a využívání účtů pro případ nedostupností autentizačních služeb centrálního IDM

• CLM řešení musí mít možnost oddělení prostředí pro jednotlivé instance systémů

• CLM řešení musí mít Administrátorskou konzoli s možností administrace všech komponent, služeb a nastavení

• Všechny komponenty CLM řešení musí splňovat požadavky kybernetické bezpečnosti v podobě hardeningu systémů. Budoucí Dodavatel musí doložit jaký způsob hardeningu je použit

• CLM řešení musí umožnovat přidělení oprávnění pro uživatele na úroveň typu logu a zdroje logu.

• Aktivity všech uživatelů log managementu v rámci SŽ se musí logovat minimálně v tomto rozsahu a současně tak, aby byl splněn požadavek § 22 vyhlášky č. 82/2018:

a) Přihlášení

b) Neúspěšný pokus o přihlášení

c) Odhlášení

d) Úpravy v systému

e) Pokus o neautorizovanou úpravu

f) Smazání údajů

g) Úpravy prav uživatelů

h) Smazání uživatele

i) Přístup do lokálního uložiště logů

j) Přihlášení pod administrátorským účtem

k) Pokus o neautorizovanou změnu

• Funkcionalita pro udělení časového razítka a digitálního podpisu logů musí být realizována prostřednictvím interní certifikační autority.

• CLM řešení musí umožnovat automatické anonymizace datových sestav, logů a událostí na základě přednastaveného algoritmu/příkazu.

• Před předáním do provozu na všech komponentách systému musí být proveden hardening všech jednotlivých komponent CLM dle CIS Benchmarku poslední aktualizace pro každou komponentu. (Pro komponenty, pro které neexistuje CIS benchmark, musí být prokázán hardening systémů ekvivalentním způsobem.) Součástí předávky do provozu jsou i všechny testy uvedené v kapitole Testování.

• Všechny datové toky musí být šifrované a současně takto musí být zabezpečena i citlivá komunikace mezi komponentami, s externími systémy nebo s uživateli.

Musí být použit takový algoritmus, který odpovídá požadavkům NÚKIB

v dokumentu MINIMÁLNÍ POŽADAVKY NA KRYPTOGRAFICKÉ ALGORITMY

• Navrhované řešení musí být schopno jako zdroj logů napojit cloudové technologie a systémy v rámci budoucí rozšiřitelnosti a škálovatelnosti.

• Navrhované řešení musí umět logovat jakékoliv aplikace nebo operační systémy realizované v těchto cloudových prostředích:

a) Microsoft Azure

b) Google

c) AWS

d) SAP

• Navrhované řešení musí mít základní šablony pro logování výše uvedených cloudových prostředí.

Název požadavku

Popis požadavku

Testovací prostředí

• V rámci dodávky CLM řešení musí být vybudované testovací prostředí. Vývojové/testovací prostředí bude sloužit k testování aktualizací a nových verzí systémů dodaných výrobcem. Zároveň v něm bude probíhat vývoj a testování funkcionalit v rámci rozšiřování zdrojových systémů

• Testovací/vývojové prostředí musí zajistit všechny požadované funkční parametry jako prostředí produkční a musí obsahovat minimálně po jedné z komponent použité v produkčním prostředí, aby tak obě prostředí byla identická z pohledu podporovaných funkcí a komponent, a bylo tak možné v testovacím/vývojovém prostředí řádně otestovat veškeré funkcionality a vlastnosti konfigurovatelné

v produkčním prostředí.

• SŽ požaduje minimálně 20 administrátorských účtů pro testovací prostředí.

• Testovací/vývojové prostředí nemusí být nasazeno v režimu vysoké dostupnosti a může být instalováno kompletně ve virtuálním prostředí (i v případě, pokud by Uchazeč navrhl pro produkční prostředí některou z komponent jako fyzický HW).

• Všechny změny v rámci řešení (zejména upgrade, bezpečnostní záplaty, nové funkcionality a další nové verze řešení nebo jeho částí) musí být řádně otestovány Uchazečem ještě před nasazením do produkčního prostředí SŽ. V rámci implementace řešení lze produkční prostředí považovat za testovací až do fáze akceptačních testů.

5.2 Architektura řešení

ID	Název požadavku	Popis požadavku
A1	Technologie CLM	• Architektura CLM řešení musí obsahovat minimálně následující logické komponenty: a) Kolektor b) Aplikační server / službu pro zpracování Logů/Engine c) Centrální uložiště d) Load Balancer e) Buffer f) Dashboard g) Konzoli/Modul pro nahlížení Logů, tj. prezentační vrstvu h) Administrační konzoli i) Konzoli pro tvorbu pravidel, filtru a vyhledávání j) Dlouhodobé uložiště
A2	Využití cloud řešení	• Je požadováno on-premise řešení
A3	Použití agentů	• Požadované řešení je bezagentní.
A4	Komponenty	• Uchazeč musí navrhnout vhodné umístění všech komponentů jím navrženého řešení dle síťové architektury SŽ. • SŽ předpokládá využití virtualizace, pokud Uchazeč nespecifikuje nutnost použití dedikovaného HW. • Síť SŽ je routována tak, aby připojované systémy byly dostupné z kterékoliv lokality. • Aktuální síťové technologie jsou uvedeny v Příloze č. 2. Zadávací dokumentace.
A5	Load Balancer	• Vzhledem ke zpracování velkého počtu logů architektura musí obsahovat Load Balancer.
A6	Filtering	• Navržená architektura musí obsahovat možnost/funkcionalitu pro filtrování logů.

Název požadavku

Popis požadavku

Collecting

• Navržená architektura musí obsahovat potřebné množství kolektorů, pro zpracování všech logů v reálném čase.

Dashboard

• Navržená architektura musí obsahovat komponentu uživatelského dashboardu

s možnostmi vizualizace a personalizace dostupných logových sestav, s možností tvorby reportů, jejích exportů do jiných formátů, apod.

Dlouhodobé úložiště

• Navržená architektura musí obsahovat návrh dlouhodobého úložiště pro uschování logů v časové ose uvedené ve funkčních požadavcích.

• Architektura musí umět rozlišit logy a typ jejích uložiště, ke kterým musí být přístup v reálném čase a k logům dlouhodobě uloženým.

A10

Redundance nodů

• Navržená architektura musí obsahovat HA a redundantní nody, nejlépe v podobě geografického clusteru.

• Navržená architektura musí splňovat požadované parametry dle servisního modelu uvedeného v kapitole Zajištění technické podpory provozu tak, aby byl dodržen požadavek na SLA za jakýchkoliv okolností.

A11

Buffering

• Navržená architektura musí obsahovat buffer pro průtok logů a jejích udržení ve frontě v minimální délce 6 hodin, pro případ přetížení nebo nedostupnosti (údržby) backendových systémů.

A12

Reálný čas

• Sběr a vyhodnocení přijatých logů musí probíhat v reálném čase s maximálním zpožděním 5 sekund.

• Uvedené zpoždění musí systém dodržet i při krátkodobém nárůstu toku logů na třicetinásobek toků uvedených v kapitole 4.

5.3 SW a HW

ID	Název požadavku	Popis požadavku
H1	Využití virtualizace	• CLM řešení je preferováno ve virtuální podobě. Uchazeč musí v nabídce specifikovat: o Přesné vyčíslení dopadů na zdrojové servery při použití agentů, tj. vyčíslení performance, diskové zátěže a jiných omezení stávající kapacity o Počet požadovaných virtuálních serverů a fyzických serverů a jejich parametrů s ohledem na dostatečnou výkonnost řešení a současnou adekvátnost parametrů o Požadavky na parametry komunikačních tras a síťových prostupů mezi jednotlivými komponentami řešení o Konektivita a konfigurace komunikačních sítí podle podaného technického návrhu zajistí SŽ • V případě, že Uchazečem navržené řešení obsahuje některou komponentu na fyzickém HW, Uchazeč musí v nabídce popsat důvod užití. • Virtualizace je možná pouze na úrovni centrálního HA řešení. • Pro virtualizaci musí být použita platforma VMWare v poslední verzi • V případě využití virtualizace musí Uchazeč v nabídce specifikovat také cenu za HW a SW také pro použitou virtualizační platformu. Tato cena je součástí nabídky Uchazeče.
H2	Velikost úložiště pro dlouhodobé ukládání	• Součástí dodávky CLM musí být návrh úložiště pro dlouhodobé uložení logů. Uchazeč musí v nabídce specifikovat potřebnou kapacitu, typ úložiště a připojení.
H3	HW a SW jako součást dodávky	• Veškerý hardware bude součásti dodávky a bude naceněn v nabídce v rámci projektu implementace CLM.

ID	Název požadavku	Popis požadavku
H4	Popis a Lokalita HW a SW	• Veškerý HW a SW, který bude součást dodávky bude popsán v položkovém seznamu obsahující povinné atributy: o Označení o Název komponenty (produktu) o Role komponenty v systému o Popis umístění komponenty (včetně geografické lokalizace) o Technická specifikace produktu o Množství o Cena
H5	Technologie pro virtualizace	• Virtualizace prostředí je realizovaná technologií VMWare nebo Hyper-V
H6	Technologie pro servery	• Servery jsou realizované na OS Windows Server nebo na OS Linux jedné z distribucí SuSe, CentOS, RedHat
H7	Technologie pro databáze	• Databáze jsou realizované technologií Oracle DB nebo MS SQL nebo MySQL
H8	Technologie pro aplikační servery	• Platforma aplikačních serverů je realizovaná technologií Oracle WebLogic nebo JBoss

5.4 Zajištění vysoké dostupnosti

Název požadavku

Popis požadavku

Vysoká dostupnost CLM

• Produkční prostředí CLM musí být instalováno v režimu HA. Musí být zajištěno, aby při výpadku jedné části systému nebyla dotčena funkčnost celého řešení.

• Každá z komponent CLM, která je nezbytná pro provoz CLM, musí obsahovat minimálně dvě samostatné instance provozované v HA režimu s maximální dobou přepnutí v řádu jednotek sekund.

• Řešení vysoké dostupnosti musí být automatické. Řešení, která vyžadují jakoukoliv manuální intervenci pro přepnutí mezi instancemi v případě vzniku chybového stavu, nejsou přípustná.

5.5 Integrace

ID	Název požadavku	Popis požadavku
I1	Integrace s IDM řešením	• Součástí dodávky musí být integrace CLM řešení se systémem Centrálního ověřování (IDM). • SŽ požaduje dodávku přesné specifikace REST API na straně CLM řešení, které bude IDM využívat.
I2	Lokálně vytvořené účty	• CLM řešení musí umožnovat vytvářet i lokálně privilegované účty, tj. účty, které nejsou spravovány pomocí IDM systému.
I3	Integrace se helpdesk systémem	• CLM řešení musí být schopné integrace s ITSM (helpdesk) systémem. • CLM řešení musí být schopné integrace s Zabbix systémem • CLM řešení musí být schopné integrace s Active Directory systémem • CLM řešení musí být schopné jak manuálně, tak i automaticky založit servisní požadavek (ticket). • CLM řešení musí být schopné automaticky založit servisní požadavek (ticket) s možností úpravy ticketu automatickým pravidlem. • CLM řešení musí být možné do budoucna integrovat se CMDB tak, aby bylo možné ze CMDB databáze získávat data.

5.6 Požadavky dle § 22 vyhlášky č. 82/2018

V rámci Centrálního Log Managementu a jeho funkčních, bezpečnostních a ostatních požadavků musí být splněny funkcionality bezpečnostního logování tak, aby v přiměřené míře a za přiměřených nákladů a v rámci řádného hospodaření s náklady, bylo možné dodržet všechny požadavky uvedené v § 22, vyhlášky č. 82/2018.

Požadavek

Požadavky na realizaci v rámci organizace Správa železnic

Zaznamenávání událostí informačního a komunikačního systému, jeho uživatelů a administrátorů

• CLM musí splňovat možnost zaznamenávat události informačních a komunikačních systémů bez ohledu na jejich způsob sběru, různorodost nebo technickou komplikovanost.

• Současně musí mít možnost zaznamenávat všechny uživatelské události.

• CLM musí mít možnost zaznamenávat výše zmíněné události kritické infrastruktury pro:

a) Specifické aplikace Správy železnic

b) Generické infrastrukturní páteřní a kritické systémy (myšleno nespecifické standardní a univerzální systémy z platforem Microsoft, Linux, Unix apod.)

c) Bezpečnostní technologie jako firewally, sondy apod., aktivní a jiné instance použité v rámci architektury kybernetické bezpečnosti

Záznam bezpečnostních a provozních událostí

• Uchazeč musí v rámci nabídky a implementace CLM dodat takové řešení, které bude schopné zaznamenávat události kritických aktiv informačního a komunikačního systému.

• V rámci organizace SŽ se jedná o páteřní a kritické infrastrukturní a specifické systémy, které budou posílat události do CLM.

• Všechny bezpečnostně provozní informace/události musí být zaznamenány, tj. minimálně v rozsahu událostí, které mohou způsobit narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací.

• Budoucí Dodavatel navrhne a naimplementuje systém, který umožní zaznamenávat všechny zdrojové informace v systémech Správy železnic

v RAW podobě (neměnitelná podoba logů, tak, jak byla vytvořena původním zdrojem).

Aktualizace rozsahu IT aktiv

• CLM musí mít možnost pružně reagovat na stávající aktiva a na aktiva, která do budoucna na základě rozhodnutí povinné osoby přibydou do kritické infrastruktury a systémů. Funkcionalita auto discovery (funkce pro zjišťování nových zdrojů logů) není požadována.

Jednoznačná síťovou identifikaci zařízení původce

• CLM musí mít jednoznačnou a konkrétní možnost na základě defaultní funkcionality zajistit jednoznačnou původní identifikaci zdroje logů i v případě, že po cestě do CLM byla změněna (dále musí mít možnost zobrazit RAW Log v původní nezměněné podobě).

Identifikace data a času

• CLM řešení umožní zaznamenávat datum a čas událostí tak, aby byl záznam unikátní bez ohledu na zdrojové systémy a jejích různorodost, současně bude zpětně identifikovatelný pro daný zdroj a čas.

• Časová synchronizace musí probíhat s časovými servery SŽ.

Identifikace typu činnosti

• CLM řešení musí být schopné logovat typ činnosti, například spuštěné služby nebo jiné činnosti, které budou vznikat na základě několika kritérií výskytu logů.

Identifikace původce činnosti

• CLM řešení musí poskytnout informaci o identifikaci zdrojového technického aktiva (systém, zařízení apod.).

• CLM řešení musí zaznamenávat a ukládat informaci o identifikaci zdrojového technického aktiva (systém, zařízení apod.).

• V případě implementace u SŽ musí mít každý log konkrétně uvedený zdroj (který bude možné pojmenovat dalším názvem).

Identifikace identity původce činnosti

• CLM řešení musí být schopné zajistit zobrazení identifikace účtu, který bude unikátní/poskytnutý systémem a ve kterém byla provedena změna.

• CLM řešení musí být schopno zaznamenávat identifikaci účtu, který bude unikátní/poskytnutý systémem a ve kterém byla provedena změna.

Identifikace zařízení původce činnosti

• V případě síťových prvků musí být jasně a konkrétně propsána všechna zdrojová zařízení v rámci prezentace logů v dashboardu nebo libovolném, nejen grafickém zobrazení.

S10

Identifikace úspěšnosti činnosti

• Pokud to zdrojový systém umožnuje, musí být CLM nastaven tak, aby logoval úspěšnou nebo neúspěšnou činnost jakéhokoliv charakteru ve zdrojovém systému a současně toto kritérium musí být jako jedna z možností filtrace.

S11

Zajištění ochrany informací

• CLM systém musí konkrétně jasně a explicitně dodržovat zásady celistvosti, důvěryhodnosti a dostupnosti veškerých sbíraných dat.

• CLM systém musí šifrovat veškerý obsah dat. Musí být použit takový kryptografický algoritmus, který odpovídá požadavkům NÚKIB v dokumentu MINIMÁLNÍ POŽADAVKY NA KRYPTOGRAFICKÉ ALGORITMY

• CLM systém musí mít možnost napojení na (již existující) SSO a dále musí mít možnost použít autorizační mechanismy s možností multifaktorové autorizace. CLM systém musí mít možnost použít kartu s certifikátem pro ověření interního uživatele SŽ. Budoucí Dodavatel nebude implementovat SSO řešení.

• V systému CLM musí být použitá interní certifikační autorita pro podepisování logů.

• Systém CLM musí umožnovat podepisovat batch (balíček) informací, nikoliv samotné logy. Budoucí Dodavatel navrhne vhodný způsob deklarace a prokázání času v podepsaných balíčcích.

• Veškerá komunikace bude zabezpečena prostřednictvím standardních protokolů dle požadavků NÚKIB v dokumentu MINIMÁLNÍ POŽADAVKY NA KRYPTOGRAFICKÉ ALGORITMY

S12

Identifikace přihlašování a odhlašování ke všem účtům, a to včetně neúspěšných pokusů

• CLM musí zaznamenávat všechna přihlášení, včetně neúspěšných pokusů do všech systémů označených jako kritická informační infrastruktura.

S13

Identifikace činností provedených administrátory

• CLM musí zaznamenávat veškeré události a aktivity, které byly prováděny administrátory.

S14

Identifikace manipulace s účty, oprávněními a právy

• CLM musí zaznamenávat jakékoliv manipulace s účty, jejích oprávněními a právy.

S15

Identifikace neprovedení činností v důsledku nedostatku přístupových práv a oprávnění

• CLM musí zaznamenávat všechny nedokončené činnosti které vznikly na základě nedostatečných oprávnění, současně tyto události musí být možné filtrovat prostřednictvím předem nastavených filtrů.

S16		Identifikace činností uživatelů, které mohou mít vliv na bezpečnost informačního a komunikačního systému	• CLM musí umožnovat monitorovat a sbírat veškeré události ohledně činností konkrétních uživatelů a dále tyto logy musí být možné filtrovat na základě kritérií.
S17		Identifikace zahájení a ukončení činností technických aktiv	• CLM musí umožnovat editaci (přidání – odebrání) zdrojových systémů logů tak, aby bylo možné pružně reagovat na zahájení a ukončení činností kritických systémů.
S18		Identifikace kritických i chybových hlášení technických aktiv	• CLM musí umožnovat sbírat kritické a chybové události v rámci kritické infrastruktury a současně tyto události musí být filtrovatelné, tj. musí být nastavena možnost filtrace na základě předem definovaných kritérií.
S19		Identifikace přístupů k záznamům o událostech, pokusy o manipulaci se záznamy o událostech a změny nastavení nástrojů pro zaznamenávání událostí	• CLM musí umožnovat sbírat jakékoliv události vzniklé při pokusech o změnu logů nebo jakoukoliv manipulaci s logy a současně musí umožnovat tyto události alarmovat prostřednictvím e-mailu nebo jiného komunikačního kanálu odpovědným osobám.
S20		Zajištění synchronizace jednotného času technických aktiv nejméně jednou za 24 hodin	• CLM musí umožnovat synchronizaci času minimálně jednou za 24 hodin, a v případě zjištění nesrovnalostí musí umožnovat odeslat alarm prostřednictvím e-mailu nebo jiného komunikačního kanálu.
	S21	Dlouhodobé uložení logů	• CLM musí uschovávat veškeré logy v souladu s požadavkem F2 v kapitole 5.1 • K těmto záznamům musí mít přístup a odpovídá za ně odpovědná osoba – CISO nebo jiná určená osoba.

5.6.1 Bezpečnostní monitoring jako součásti CLM

S ohledem na § 22, vyhlášky č. 82/2018 a realizaci CLM v prostředí SŽ, musí navrhnuté řešení být schopné spravovat elementární požadavky z platformy bezpečnostního monitoringu.

Požadavek

Požadavky na realizaci v rámci organizace Správa železnic

S22

Dashboard a zobrazení aktuálních událostí za jednotlivý předem nastavený časový úsek

Navrhované řešení musí umět zobrazit události dle nastaveného časového úseku v rámci uživatelského dashboardu.

S23

Alerting

• Navrhované řešení musí umět zasílat upozornění na základě předem nastavených kritérií na specifické adresy jednotlivých uživatelů skrze specifické kanály (e-mail, SMS, hlasová zpráva nebo chat).

• Navrhované řešení musí umět komunikovat s dalšími systémy prostřednictvím zasílání zpráv nebo prostřednictvím komunikace API do jiných systémů.

S24

Korelace logů

Základní korelace logů na základě předem stanovených filtrů a kritérií s možností jednoznačné identifikace ohroženého aktiva.

S25

Šablony

Řešení musí umožnovat práci se šablonami a tvorby základních šablon včetně možností zapojení bezpečnostních kritérií.

5.7 Počet uživatelů CLM

Níže uvedená tabulka uvádí přehled počtu uživatelů, kteří budou přistupovat do systému CLM a dalších parametrů pro stanovení sizingu licencí a HW:

Typ uživatele	Počet uživatelů / Parametr
Administrátor	100
Jmenný uživatel	Maximálně 500
Současně připojení uživatelé v běžném provozu	Maximálně 20
Současně připojení uživatelé ve špičce	Maximálně 40
Průměrná délka uživatelské relace za den	4 hod

6 Požadavky na dodávku

Definice požadavků na provedení činností v rámci zavedení CLM do prostředí SŽ. Dodávka se musí skládat alespoň z níže uvedených činností:

1. Vypracování analýzy

2. Definice Technického návrhu implementace

3. Dodávka SW, HW a licencí

4. Dodávka Produkčního a testovacího prostředí

5. Instalace

6. Konfigurace

7. Testování

8. Pilotní provoz

9. Dokumentace

10. Školení

11. Předání do provozu

12. Zajištění technické podpory provozu

13. Nadstandardní služby

SŽ požaduje popis návrhu realizace jednotlivých výše uvedených činností. Tento popis bude součástí nabídky podle šablony v Příloze č. 3 Zadávací dokumentace.

6.1 Analýza

Analýza současného stavu, zpřesnění požadavků a vytvoření konceptu CLM. Vybraný dodavatel provede vlastní analýzu nutnou k tvorbě technického návrhu implementace a k zajištění všech potřeb nutných k plnění požadavků podané nabídky.

Výstupem analýzy bude obecný popis komponent, jejich vztahů, kapacit atd., dále je požadován popis architektury budoucího CLM, popis operačního modelů a procesů dotčených CLM.

Výstup analýzy musí být oboustranně schválen (SŽ i budoucím dodavatelem) před zahájením kroku Definice technického návrhu implementace. Technický návrh implementace musí vycházet ze schváleného znění výstupu Analýzy a být s ním plně v souladu.

6.2 Definice Technického návrhu implementace

Před zahájením integračních aktivit musí vzniknout dokument Technický návrh implementace obsahující popis technického řešení CLM. Znění tohoto dokumentu musí být oboustranně schválené SŽ i Budoucím Dodavatelem a poté tvoří závazný dokument pro nové CLM řešení.

Kapitola

Popis

Úvod

• Popis účelu dokumentu, popis rozsahu, cíle, katalog změn a dopady

LLD specifikace

• Specifikace celé implementace na úrovni LLD, včetně popisu architektury, členění a všech funkčních požadavků uvedených v technické specifikaci SŽ

Business požadavky

• Specifické požadavky business vlastníka na integraci, implementaci a obsah, se současným přihlédnutím

k funkčním požadavkům

HW a SW prostředí

• Detailní popis potřebného HW a SW včetně rozpisu všech modulů, aktiv, virtuálních instancí do úrovně virtuálních kontejnerů (pokud budou použity)

• Všechny hardwarové komponenty (servery, počítače) a environmentální software používaný v systému. Popis obecné konfigurace hardwaru a vysvětlení, jak se funkce definované ve funkční specifikaci mapují na hardware.

• Popis všech částí komponent a uveďte podrobnější informace o hardwarovém a softwarovém prostředí:

o primární konfigurace hardwaru

o seznam dalších hardwarových konfigurací (např. záložní systémy)

o vztah mezi hardwarem a externími rozhraními

o seznam veškerého SW potřebného k implementaci a přiřazené k HW

• Detailní přehled všech licencí

Struktura systému

• Popis struktury systému, které ukazuje subsystémy a jejich vzájemný vztah. Definice hlavních datových toků mezi subsystémy a hlavními databázovými přístupy

• Popis diagramu se shrnutím každého subsystému

• Definice součásti systémů a subsystémů a komponent a popis vztahů mezi nimi včetně jejich rozhraní

Architektura databáze

• Popis databáze bez ohledu na to, zda se jedná o SQL nebo non SQL databázi

• Definice základních databázové schéma

• Popis databázové struktury

Funkční požadavky a jejich řešení

• Popis technického řešení pro každý funkční požadavek konkrétně. Funkční požadavky jsou uvedeny v Kapitole 5.1 Funkční požadavky

• Ilustrace výstupu funkčních požadavků v podobě řešení a příkladů implementované technologie

Požadavky na architekturu řešení a její implementační řešení rozkreslené v jazyce ArchiMate 3

• Popis architektury řešení a její rozkreslení v jazyce ArchiMate 3 nebo v jiném adekvátním

• Architektura musí obsahovat minimálně všechny komponenty, popis datových toků, služby a popis zajištění vysoké dostupnosti s ohledem na celkovou architekturu

Požadavky na zajištění vysoké dostupnosti a jejích řešení

• Popis řešení vysoké dostupnosti s popisem kritických scénářů a rizik

T10

Škálovatelnost technologického řešení

• Popis, jakým způsobem bude realizována škálovatelnost celého řešení, uvedené na příkladech

T11

Uživatelé

• Popis uživatelů a jejich rolí, definice řešení požadavku na uživatele

T12	Bezpečností požadavky a jejich řešení	• Popis řešení bezpečnostních požadavků
T13	Uživatelské prostředí	• Popis uživatelské prostředí, uveďte řešení všech požadavků a funkcionalit v rámci uživatelského prostředí včetně dashboardu
T14	Postup instalace	• Popis postupu instalace, jednotlivé komponenty, SW a licence
T15	Potřebné součinnosti a jejích rozsah v čase	• Popis veškerých požadavky na součinnost na straně útvarů a rolí na straně SŽ včetně časové posloupnosti požadavků, mimo jiné požadavky na změny konfigurací komunikačních sítí a síťových prvků
T16	Testování a rozsah testů	• Popis testovacích scénářů
T17	Nasazení produkčního prostředí	• Popis způsobu, postupu a posloupnosti v nasazení produkčního prostředí • Popis technických detailů včetně identifikace jednotlivých komponent na úrovní názvů nebo IP adres.
T18	Popis systémů a aplikací které budou nasazeny jako zdroj logů	• Uvedení jmenovitě (dle názvu nebo jiného unikátního identifikátoru) všech instancí systémů nebo technologií, které budou zapojeny do CLM
T19	Popis zpracování logů	• Popis detailně zpracování logů, včetně možnosti korelace, filtrace, obohacování, tvorby událostí, alarmů a všech ostatních funkcionalit životního cyklu logování, požadovaných v rámci funkčních požadavků • Uvedení předpokládané objemy dat a EPS pro plánované zapojení technologií a systémů zpracované na konci analýzy
T20	Popis procesů	• Popis procesů spojených s CLM a s ohledem na prostředí SŽ • Popis minimálně těchto procesů: o Přidání nových typů zdrojů logů nebo integrace nových modulů/funkcí do CLM o Proces s popisem adaptace změn s návazností na stávající change management SŽ v době akceptace projektu o Práce s Logy, nové filtry, vyhledávaní, tvorba události o Tvorba alertu (zohlednit celý životní cyklus od vzniku logu, po jeho zpracování – korelace, enrichment apod. až do vzniku alertu) o Práce s uživateli o Nastavení dashboardu o Odebrání systémů z CLM o Aktualizace systému
T21	Aktualizace systémů	• Popis provádění aktualizací jednotlivých komponent systémů
T22	Předpokládaná rizika a jejích dopady	• Popis technologických/technických rizik spojených s implementaci systému, provozem a jejích dopady
T23	Konfigurační nastavení	• Popis konfiguračního nastavení u těch nastavení, u kterých to bude zřejmé na konci analýzy
T24	Postup obnovy v podobě instalačních kroků a jejích konfigurace	• Popis obnovy v případě selhání systému nebo ztráty dat, současně uveďte způsob nahrání konfigurací

T25

Konkrétní projekt plán s vazbou na Technický návrh implementace

• Popis konkrétního a kompletního projektového plánu s ohledem a vazbou na implementační projekt a potřebné součinnosti

T26

Plnění požadavků dle kybernetického zákona a popis řešení

• Přesná, konkrétní a závazná definice, jakým způsobem budou řešeny všechny požadavky v rámci požadavků dle Zákona č.181/2014 a Vyhlášky č. 82/2018 o kybernetické bezpečnosti

• Popis způsob řešení každého požadavku

6.3 Dodávka SW, HW a licencí

Součástí návrhu dodávky (SW, HW i licencí) a její ceny je zajištění technické podpory a plné funkčnosti po dobu pěti let a to zejména v oblastech:

• Explicitní potvrzení garance výrobce všech komponent CLM o zachování životnosti a plné technické podpory dané komponenty

• Zajištění technické podpory budoucím dodavatelem, specifika jsou uvedena v kapitole 6.13

6.3.1 Dodávka HW

Uchazeč dále navrhne parametry a věcný seznam HW potřebného pro běh všech navržených SW komponent řešení, a to formou přehledové tabulky parametrů

s uvedením, zda se musí jednat o dedikovaný HW či virtuální nasazení. Veškerý HW musí být součástí dodávky. Prostor pro montáž HW a stojany budou zajištěny SŽ v rámci vlastních datacenter.

Věcný seznam HW bude přílohou a nedílnou součástí nabídky (konkrétně dokumentu s názvem „Šablona nabídky“). Věcný seznam HW bude obsahovat jednotlivé položky HW, přičemž ke každé položce bude alespoň uvedeno následující:

• jednoznačná specifikace výrobku – uvedením názvu výrobce, názvu (obchodního pojmenování) výrobku a typového čísla výrobku;

• počet kusů dané položky HW, který bude pro kompletní řešení dodán;

• cena jednoho kusu položky a cenu za všechny kusy dané položky, a to vždy bez DPH i s DPH (uvedené ceny budou mít pouze informativní charakter pro představu SŽ o způsobu stanovení nabídkové ceny za dodávku HW).

Součástí dodávky HW bude Software vztahující se k Hardware ve smyslu závazného návrhu Xxxxxxx a jejích příloh.

6.3.2 Dodávka SW a licencí

Uchazeč ve své nabídce stanoví a položkově uvede veškeré potřebné SW a licence SW, které budou nutné pro zavedení a správu CLM a zároveň budou součástí dodávky. Dodané licence musí zaručit všechny funkcionality nabízeného CLM.

Seznam potřebného SW a licencí SW bude přílohou a nedílnou součástí nabídky (konkrétně dokumentu s názvem „Šablona nabídky“). Seznam potřebného SW a licencí SW bude obsahovat jednotlivé položky SW a licencí, přičemž ke každé položce bude alespoň uvedeno následující:

• jednoznačná specifikace položky;

• typ SW podle závazného návrhu Smlouvy a jejích příloh – tedy to, zda se jedná o SW v režimu Standardního Software, nebo Unikátního Software;

• rozpad celkové ceny za danou položku (případně pouze celková cena za danou položku SW, pokud se celková cena neskládá z dílčích cen), a to vždy bez DPH i s DPH u každé dílčí ceny i celkové ceny (uvedené ceny budou mít pouze informativní charakter pro představu SŽ o způsobu stanovení nabídkové ceny za dodávku SW a licencí).

6.4 Dodávka Produkčního a testovacího prostředí

SŽ požaduje vybudovaní dvou prostředí – produkčního a vývojového/testovacího. Produkční prostředí bude postupně rozvíjeno v souladu s harmonogramem projektu.

Požadavky na testovací prostředí jsou uvedeny v kapitole 5.1 Funkční požadavky.

6.5 Instalace

Instalace řešení bude provedena do infrastruktury SŽ, která je založena

na virtuální platformě, resp. na fyzický server, pokud takový bude Uchazečem v řešení navrhnut. Veškerý HW musí být součástí dodávky.

SW komponenty dodané v rámci řešení budou instalovány v poslední verzi dostupné v době akceptace projektu. Uchazeč dále zajistí nasazení a aktivaci všech licencí, resp. licenčních klíčů. Architektura instalovaného CLM řešení, včetně identifikace komponent, přehledu instalovaných verzí a použitých licencí a licenčních klíčů bude součástí instalační dokumentace. Instalace je provedena nejprve pro testovací, poté pro produkční prostředí.

6.6 Konfigurace

Uchazeč provede veškerou potřebnou konfiguraci CLM řešení a všech jeho komponent dle požadavků této Technické specifikace včetně součinnosti při konfiguraci sítě. SŽ je odpovědné za zajištění konektivity komunikačních sítí, tj. za provedení změn v konfiguraci síťových prvků.

Xxxxxxx provede návrh vybraných procesů souvisejících s CLM.

Připojení definovaných zdrojů logů dle navržené etapizace projektu do dodaného CLM řešení.

6.7 Testování

V rámci fáze Definice Technického návrhu implementace budou budoucím Dodavatelem navrhnuty testovací scénáře, které budou pokrývat následující oblasti a parametry řešení.

Akceptační testy jsou ukončeny nahlášením výsledku a předáním seznamu nalezených vad SŽ. Po odstranění významných vad (úroveň středně závažné a více) budou akceptační testy opakovány a ověří tak kvalitu předávaného CLM řešení. U ostatních vad se provedou akceptační testy s ohledem na ověření řešení pouze příslušné vady.

Podmínkou akceptace dodávky je provedení všech navržených testů s výsledkem akceptovaným SŽ.

6.7.1 Funkční testy

Funkční testy ověří, že implementované CLM řešení poskytuje bezchybně všechny požadované funkcionality uvedené v tomto dokumentu a jeho přílohách, včetně řádné integrace s koncovými systémy SŽ. Funkční testy ověří plnou dostupnost koncových systémů dle požadavku na implementaci v rámci jednotlivých etap projektu.

6.7.2 Zátěžové testy

Zátěžové testy musí být realizovány v takovém rozsahu, aby prostřednictvím stress skriptů ověřily zátěžově celé komplexní řešení v minimálním objemu dvojnásobku standardního provozu.

Document Metadata

Table of Contents

Věc: Vysvětlení zadávací dokumentace č. 2, 3, 4 a 5

Document Metadata