ZADÁVACÍ DOKUMENTACE
Naše zn. 26302/2022-SŽ-GŘ-O8
Vyřizuje Xxxxx Xxxxxxxx
Datum 4. 4. 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 Xxxxxxxxxx: 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
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. Veřejná 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 Xxxxxxx, 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í objem logů zpracovávaných systémem v okamžiku předání do provozu je: 9 TB/den;
⮚ minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu je: 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.
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í objem logů zpracovávaných systémem v okamžiku předání do provozu je: 1 TB/den;
⮚ minimální počet zdrojů logů připojených do systému v okamžiku předání do provozu 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.
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í 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,
⮚ 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,
⮚ 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í,
⮚ 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,
⮚ 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).
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í 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,
⮚ 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.
Projektový manažer – tuto pozici bude zastávat minimálně 1 osoba
⮚ má minimálně 5letou praxi na pozici Project Manager,
⮚ 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,
⮚ 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.
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 „X. Xxxxxxxxx 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 „X. Xxxxxxxxx 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 „X. Xxxxxxxxx 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 | |
X. | Xxxxxxx 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 „X. Xxxxxxxxx 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ů
elektronicky podepsal 14. 4. 2022
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
4.3.1 Doménové řadiče, operační systémy, služby 11
4.3.2 Síťové technologie 16
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
5.6.1 Bezpečnostní monitoring jako součásti CLM 27
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
6.3.1 Dodávka HW 32
6.3.2 Dodávka SW a licencí 32
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
6.7.1 Funkční testy 34
6.7.2 Zátěžové testy 34
6.7.3 Bezpečnostní testy 34
6.7.4 Sken zranitelností 35
6.7.5 Testy zajištění kontinuity 35
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
1 Verze dokumentu
Verze dokumentu | Datum | Autor | Změny |
5.00 | 20.1.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 | |||||||
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
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka |
1 | Active Directory | doména UADF | 1 | 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ů. |
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka | |
2 | Active Directory | doména UADF | 1 | 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ů. | |
3 | Active Directory | doména UADF | 1 | 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ů. | |
4 | Active Directory | doména UADFD01 | 1 | 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ů. | |
5 | Active Directory | doména UADFD01 | 1 | 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ů. | |
6 | Active Directory | doména UADFD01 | 1 | 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ů. | |
7 | Active Directory | doména UADFD02 | 1 | 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ů. | |
8 | Active Directory | doména UADFD02 | 1 | 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ů. | |
9 | Active Directory | doména UADFD02 | 1 | 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ů. | |
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka | |
10 | Active Directory | doména MADF | 1 | 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ů. | |
11 | Active Directory | doména MADF | 1 | 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ů. | |
12 | Active Directory | doména MADF | 1 | 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ů. | |
13 | Active Directory | doména OADF | 1 | 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ů. | |
14 | Active Directory | doména OADF | 1 | 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ů. | |
15 | Active Directory | doména OADF | 1 | 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ů. | |
16 | Active Directory | doména EADF | 1 | 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ů. | |
17 | Active Directory | doména EADF | 1 | 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ů. | |
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka | |
18 | Active Directory | doména EADF | 1 | 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ů. | |
19 | Server | MS Exchange CAS server | 1 | 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ů. | |
20 | Server | MS Exchange CAS server | 1 | 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ů. | |
21 | Server | MS Exchange CAS server | 1 | 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ů. | |
22 | Server | MS Exchange Content servery | 1 | 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ů. | |
23 | Server | MS Exchange Content servery | 1 | 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ů. | |
24 | Server | MS Exchange Content servery | 1 | 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ů. | |
25 | Služba | Doménový řadič | 1 | 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í. | |
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka | |
26 | Služba | Doménový řadič | 1 | 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í. | |
27 | Služba | Doménový řadič | 1 | 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í. | |
28 | Služba | Doménový řadič | 1 | 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ů. | |
29 | Služba | Doménový řadič | 1 | 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ů. | |
30 | Služba | Doménový řadič | 1 | 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ů. | |
31 | Služba | Doménový řadič | 1 | 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ů. | |
32 | Služba | Doménový řadič | 1 | 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ů. | |
33 | Služba | Doménový řadič | 1 | 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ů. | |
ID | Typ | Koncový systém | Počet prvků / instancí | Poznámka | |
34 | APP | PROXY | 1 | 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ů. | |
35 | APP | PROXY | 1 | 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ů. | |
36 | APP | PROXY | 1 | 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ů. | |
37 | APP | PROXY | 1 | 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. | |
38 | APP | Doménový řadič | 1 | Odhad Logů v MB za den:60 typ Logu Windows Log Suma za všechny generované logy. | |
39 | APP | Doménový řadič | 1 | Odhad Logů v MB za den:60 typ Logu Windows Log Suma za všechny generované logy. | |
40 | OS | Doménový řadič | 1 | Odhad Logů v MB za den:11 404 800 Suma za všechny generované logy. | |
41 | DB | 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 | |||||
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
ID | Název požadavku | Popis požadavku | ||
F1 | Š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ů: | ||||
F2 | 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) | ||
ID | Název požadavku | Popis požadavku | ||
F3 | 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 | |
F4 | Zabezpečení prostředí | • 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 | |
F5 | Cloudové Logy | • 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í. |
ID | Název požadavku | Popis požadavku |
F6 | 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ů. |
ID | Název požadavku | Popis požadavku |
A7 | Collecting | • Navržená architektura musí obsahovat potřebné množství kolektorů, pro zpracování všech logů v reálném čase. |
A8 | 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. |
A9 | 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. |
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
ID | Název požadavku | Popis požadavku | ||
D1 | 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.
ID | Požadavek | Požadavky na realizaci v rámci organizace Správa železnic | ||
S1 | 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 | ||
S2 | 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). | ||
S3 | 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. | ||
S4 | 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ě). | ||
S5 | 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Ž. | ||
S6 | 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ů. | ||
S7 | 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). | ||
S8 | 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. | ||
S9 | 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.
ID | 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í.
ID | Kapitola | Popis |
T1 | Úvod | • Popis účelu dokumentu, popis rozsahu, cíle, katalog změn a dopady |
T2 | 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Ž |
T3 | 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 |
T4 | 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í |
T5 | 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í |
T6 | 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 |
T7 | 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 |
T8 | 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 |
T9 | 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 Xxxxxxx 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.
6.7.3 Bezpečnostní testy
Úlohou bezpečnostních testů je ověřit, že jsou všechny komponenty zabezpečeny dle požadavků definovaných v tomto dokumentu a přílohách, např. že je zabezpečený přístup k CLM, přístup k logům a nastavení mají pouze autorizované osoby a jejich přístup je logován, zálohy konfigurace a dat jsou řádně šifrovány, uživatelé mají přístup pouze do přidělených bezpečnostních segmentů apod.
Bezpečnostní testy budou realizovány SŽ, nikoliv Budoucím Dodavatelem.
6.7.4 Sken zranitelností
Provedení skenu zranitelností všech komponent, kde výsledky nesmí obsahovat žádnou zranitelnost, která je hodnocená jako středně závažná nebo horší.
Zranitelnosti hodnocené nízkou závažností a nižší mohou být akceptovány SŽ. Pokud nebudou akceptovány, musí budoucí dodavatel zajistit jejich odstranění. Výsledky všech skenů budou prezentovány pro každou jednotlivou komponentu a musí být akceptovány SŽ.
6.7.5 Testy zajištění kontinuity
Úlohou testů je ověřit dostupnost CLM řešení v případě výpadku jednotlivých komponent a ověřit jeho funkčnost.
Testování bude provedeno Budoucím Dodavatelem za součinnosti SŽ. Budoucí Dodavatel k realizaci testů zajistí:
• Nástroje a komponenty potřebné pro testování
• Přípravu návrhu testování a hodnotících kritérií
• Přípravu testovacích scénářů
• Přípravu prostředí a testovacích dat (v součinnosti se SŽ)
• Testovací protokoly s výstupy testů
• Seznam defektů a způsob a harmonogram jejich odstranění
6.8 Pilotní provoz
Pilotní provoz bude proveden v produkčním prostředí s cílem otestovat funkčnost CLM v omezeném objemu zdrojových dat, avšak při plné funkcionalitě.
• Budoucí Dodavatel sám navrhne rozsah aktiv pro pilotní provoz. Tento rozsah musí být akceptován SŽ před zahájením pilotního provozu.
• Budoucí Dodavatel navrhne kritéria ukončení pilotního provozu s minimálními požadavky:
o Pilotní provoz bude realizován minimálně po dobu jednoho měsíce.
o V rámci pilotního provozu bude začleněno minimálně 10 zdrojů logů z každé skupiny logů.
o V rámci pilotního provozu bude realizován skutečný provoz CLM, tj. vyhodnocování logů, nikoliv nastavování nebo konfigurace systému samotného.
o Kritéria ukončení pilotního provozu musí schválit SŽ.
o Po ukončení Pilotního provozu budou prezentována závěrečná zpráva zástupcům SŽ. Tato zpráva bude obsahovat shrnutí
pozorovaných nedostatků, chyb atp., které je nutné odstranit před nasazením CLM do produkčního prostředí v plné funkcionalitě.
• Požadavky na Servisní podporu v režimu SLA musí odpovídat produkčnímu provozu i v pilotním provozu.
• Během pilotního provozu musí být provedena demonstrace přepnutí systémů v rámci HA.
• CLM nemůže být plně spuštěn v produkčním prostředí, dokud nebude SŽ akceptována realizace nápravných opatření vycházejících z pozorování během pilotního provozu.
6.9 Dokumentace
Dokumentace CLM musí obsahovat originální dokumentaci dodanou výrobci všech součástí CLM řešení i dokumentaci popisující nasazení CLM řešení
v prostředí SŽ.
Originální dokumentace výrobce všech součástí CLM řešení musí být předána v elektronické podobě (formát PDF nebo MS Word) a musí být provedena
v českém nebo anglickém jazyce.
Dokumentace popisující integraci CLM řešení v prostředí SŽ musí být předána v elektronické editovatelné podobě ve formátu MS Word a musí být provedena v českém jazyce.
Dokumentace musí pokrývat minimálně následující oblasti:
• Instalační dokumentace:
o Popis architektury
o Komunikační matice komponent
o Instalované verze
o Licence
o Instalační postup pro případ havárie
• Implementační dokumentace:
o Popis nastavení komponent CLM řešení
o Popis způsobu integrace (jednotlivých typů koncových systémů)
o Popis konfigurace zálohování CLM řešení
o Uživatelská příručka
o Popis uživatelského rozhraní CLM řešení z pohledu uživatele
o Popis uživatelských postupů při práci s CLM řešením
• Administrátorská příručka:
o Popis uživatelského rozhraní CLM řešení z pohledu administrátora
o Popis základních úkonů nutných pro údržbu CLM řešení a standardní profylaktické testy
o Popis způsobu aktualizace
o Popis způsobu modifikace nastavení
o Popis dodání nebo odebrání nových komponent
o Popis přidání nových zdrojů logů
• Zajištění kontinuity provozu:
o Popis postupu obnovy ze zálohy
o Doporučení pro dlouhodobé ukládání (nahrané uživatelské relace a související data)
o Popis postupu v případě havárie jednotlivých komponent včetně postupu obnovy do provozního stavu
• Dokumentace skutečného stavu
o Dokumentace změn a výjimek schválených v průběhu dodávky.
6.10 Školení
Uchazeč musí zajistit proškolení odpovědných osob SŽ na úrovni administrace řešení v rozsahu umožňujícím provádět:
• Běžný rutinní provoz a údržbu dodávaného CLM řešení včetně provedení příslušných konfiguračních změn
• Řešení obvyklých problémů
• Správu uživatelských oprávnění
• Integraci koncového systému
• Analýzu zaznamenaných uživatelských relací
• Monitoring stavu zařízení
• Zálohování a obnovu konfigurace a dat
• Tvorbu pohledů a reportů
Školení musí být v rozsahu min 32 vyučovacích hodin na každou roli. Musí být vykonáno prezenčně, včetně praktických cvičeních na systému a musí být zakončeno testem.
6.11 Předání do provozu
Uchazeč musí zajistit předání plného CLM řešení do produkčního užívání (již fáze Pilotního provozu bude provozována v produkčním prostředí).
Před předáním CLM do produkčního užívání musí být splněna všechna akceptační kritéria vycházející z předcházejících kapitol (6.1 až 6.10), která musí být písemně akceptována SŽ.
6.12 Zajištění technické podpory provozu
Uchazeč musí zaručit, že CLM řešení bude funkční a použitelné v prostředí SŽ a bude odpovídat požadavkům uvedeným v Technickém návrhu implementace a vlastnostem deklarovaným v dokumentaci výrobce dodané uchazečem.
Předmětem technické podpory je poskytování expertních služeb, které budou využívány zejména pro podporu činností SŽ v případě problémů s dodaným řešením a jako doplněk k zajištění odborné pomoci v případech vyžadujících expertní znalost.
Měření SLA bude realizováno na straně SŽ, prostřednictvím jeho servisdeskového systému.
Technická podpora provozu musí být v souladu se závazným návrhem smlouvy a jejími přílohami, tj. zejména se standardizovaným dokumentem SŽ – Zvláštní obchodní podmínky pro Zakázky v oblasti ICT.
6.13 Nadstandardní služby
Maximální souhrn nadstandardních služeb bude činit ročně 120 MD dle konkrétních potřeb pro rozložení čerpání SŽ.
SŽ požaduje uvést cenu za následující položky ve formě ceny za 1MD a celkové ceny za položku podle předpokládaného objemu čerpání:
Položka | Předpokládané čerpání v MD za rok |
Konzultace nad rámec paušálu, tj. nad rámec základních služeb poskytnutých v projektu | 25 |
Zásah v lokalitě SŽ na vyžádání, mimo servisní smlouvu | 25 |
Školení nad rámec základních školení | 10 |
Změnová řízení a dovývoj | 60 |
Celková cena za výše uvedené položky musí být součástí cenové nabídky Budoucího Dodavatele.
Příloha č. 2 Zadávací dokumentace
Popis aplikací a prostředí SŽ
Tento dokument nebude dodavatelům zpřístupněn na profilu Zadavatele a Zadavatel jej 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.
Viz bod 19.1.3 a násl. Zadávací dokumentace.
1/1
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
Draft
Příloha č. 3 Zadávací dokumentace
Klasifikace: Veřejný dokument
ŠABLONA – POUZE TECHNICKÁ NABÍDKA
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/5
soudem v Praze, spisová značka A 48384
xxxxxxxxxxxxxx.xx
1 Úvod
Uchazeč v této kapitole popíše alespoň uvedení do problematiky a seznámení s nabídkou.
2 Pochopení požadavků SŽ na celkovou dodávku a technické prostředky
Uchazeč v této kapitole popíše alespoň pochopení potřeb a záměru SŽ.
3 Manažerské shrnutí
Uchazeč v této kapitole uvede alespoň následující informace:
1. Obecný a netechnický popis celého řešení, který v nízké úrovni detailu popisuje všechny klíčové aspekty nabízené služby
2. Shrnutí splnění všech požadavků uvedených v technické příloze zadávací dokumentace
4 Popis CLM
4.1 Popis architektury
Uchazeč v této kapitole uvede alespoň souhrnný a detailní popis architektury řešení CLM, který musí prokazatelně popisovat všechny části CLM, které jsou součástí nabídky a všechny součinnosti požadované od SŽ. V této kapitole musí být uveden způsob řešení všech požadavků popsaných v kapitole 5.2, 5.4 a 5.5 v Technické příloze ZŘ.
4.2 Popis využitého HW, SW a licencí
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis veškerého HW, SW a licencí, které budou poskytnuty na základě nabídky.
V této kapitole musí být uveden způsob řešení všech požadavků popsaných v kapitole 5.3 v Technické příloze ZŘ.
4.3 Popis lokalit
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis lokalit ve kterých uchazeč předpokládá sběr logů nebo instalaci jakéhokoliv HW nebo SW.
4.4 Škálovatelnost řešení
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis možností škálovatelnosti nabízeného řešení ve vztahu k budoucímu možnému rozšíření řešení nebo sledovaných aktiv.
4.5 Uživatelé
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis uživatelů a rolí, které budou v CLM zavedeny včetně očekávaných požadavků na tyto uživatele a role. V této kapitole musí být uveden způsob řešení všech požadavků popsaných v kapitole 5.7 v Technické příloze ZŘ.
5 Funkční požadavky a jejich řešení
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech funkčních požadavků uvedených v kapitole 5.1 Funkční požadavky v Technické příloze ZŘ.
6 Bezpečností požadavky a jejich řešení
6.1 Požadavky dle § 22 vyhlášky č. 82/2018
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků dle § 22 vyhlášky č. 82/2018 uvedených
v kapitole 5.6 požadavky v Technické příloze ZŘ.
7 Popis dodávky
7.1 Popis analýzy současného stavu
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.1 v Technické příloze ZŘ.
7.2 Popis technického návrhu implementace
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.2 v Technické příloze ZŘ.
7.3 Popis dodávky SW, HW a licencí
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.3 v Technické příloze ZŘ.
7.4 Popis produkčního a testovacího prostředí
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.4 v Technické příloze ZŘ.
7.5 Popis instalace CLM
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.5 v Technické příloze ZŘ.
7.6 Popis konfigurace CLM
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.6 v Technické příloze ZŘ.
7.7 Popis testování CLM
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.7 v Technické příloze ZŘ.
7.8 Popis realizace pilotního provozu
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.8 v Technické příloze ZŘ.
7.9 Popis dodané dokumentace
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.9 v Technické příloze ZŘ.
7.10 Popis školení
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.10 v Technické příloze ZŘ.
7.11 Popis způsobu předání do provozu
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.11 v Technické příloze ZŘ.
7.12 Popis způsobu zajištění technické podpory provozu
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.12 v Technické příloze ZŘ.
7.13 Popis dodávky nadstandardních služeb
Uchazeč v této kapitole uvede alespoň souhrnný, detailní a jednoznačný popis způsobu splnění všech požadavků uvedených v kapitole 6.13 v Technické příloze ZŘ.
8 Potřebné technické předpoklady a součinnosti
Uchazeč uvede všechny předpoklady a požadovanou součinnost, které podmiňují dodání nabízeného řešení v rozsahu a kvalitě popsaném v této nabídce.
Formuláře pro posouzení naplnění povinných požadavků a hodnocení ekonomické výhodnosti
ZŘ CENTRALNÍ LOG MANAGEMENT (CLM)
Tento soubor obsahuje formuláře pro:
- posouzení naplnění povinných požadavků Technické Specifikace (dále též jen TS. TS je přílohou č. 1 Zadávací dokumentace na Centrální Log Management)
- vyplnění nabídkové ceny
- hodnocení kvality nabízeného řešení
List "X. Xxxxxxxxx cena " slouží k přehlednému zobrazení a rozpadu cenové nabídky požadovaného řešení, včetně posouzení souladu nabídkové ceny s cenovým omezením.
List "B0. Povinné požadavky bez hodnocení" slouží k posouzení dalších povinných požadavků TS, které však nejsou hodnoceny ve smyslu kvality jejich naplnění.
List "B1. Povinné požadavky s hodnocením" slouží k posouzení povinných požadavků TS a hodnocení kvality jejich naplnění.
List "C. Preference " slouží k indikaci, zda nabízené řešení představuje technologicky preferované komponenty.
Identifikace účastníka: Testovací účastník
Postup pro vyplnění souboru
Nejprve účastník vyplní položku Identifikace uchazeče na řádku 17 tohoto listu. Dále pokračuje s vyplňováním dalších listů. Na každém listu je popis konkrétních kroků pro jeho správné vyplnění.
Legenda zabarvených polí:
textové doplnění pole
výběr z předdefinovaných možností
X. Xxxxxxxxx cena
Účastník vyplní jednotkovou cenu dle jednotlivých částí dodávky pro předdefinovaný počet jednotek. Účastník je povinnen dodržovat uvedená omezení
B0. Povinné požadavky bez hodnocení
Účastník určí, zda navrhované řešení požadavek splňuje a popíše jeho technické řešení. Uvedené požadavky nejsou součástí hodnocení kavlity.
B1. Povinné požadavky TS s hodnocením kvality
Účastník určí, zda nabízené řešení povinný požadavek technické specifikace (TS) splňuje, popíše jeho technické řešení a zvolí, jakým způsobem je požadavek splněn.
C. Hodnocení nabízeného řešení dle technologických preferencí Účastník určí, zda je navrhované řešení dle TS preferované, a poskytne popis technického řešení daného požadavku.
Příloha č. 5 Zadávací dokumentace
Čestné prohlášení ke splnění základní způsobilosti
Účastník:
Obchodní firma/jméno …………
Sídlo/místo podnikání …………
IČO …………
Zastoupen …………
který podává nabídku na nadlimitní sektorovou veřejnou zakázku s názvem „Centrální Log Management“, č.j. 26302/2022-SŽ-GŘ-O8, tímto pro účely prokázání základní způsobilosti dle
§ 74 odst. 1 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“) čestně prohlašuje, že je dodavatelem
1) který nemá v České republice nebo v zemi svého sídla v evidenci daní zachycen splatný daňový nedoplatek ve vztahu ke spotřební dani;
2) který nemá 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í;
31) který není v likvidaci2, proti němuž nebylo vydáno rozhodnutí o úpadku3, vůči němuž nebyla nařízena nucená správa podle jiného právního předpisu4 nebo v obdobné situaci podle právního řádu země sídla dodavatele.
V …………………… dne ………………………
1 Čestné prohlášení ve vztahu k § 74 odst. 1 písm. e) ZZVZ předkládá dodavatel v případě, že není zapsán v obchodním rejstříku.
2 § 187 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů.
3 § 136 zákona č. 182/2006 Sb., o úpadku a způsobech jeho řešení (insolvenční zákon), ve znění pozdějších předpisů.
4 Například zákon č. 21/1992 Sb., o bankách, ve znění pozdějších předpisů, zákon č. 87/1995 Sb., o spořitelních a úvěrních družstvech a některých opatřeních s tím souvisejících a o doplnění zákona České národní rady č. 586/1992 Sb., o daních z příjmů, ve znění pozdějších předpisů, zákon č. 363/1999 Sb., o pojišíovnictví a o změně některých souvisejících zákonů.
1/1
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
Příloha č. 6 Zadávací dokumentace
Čestné prohlášení ke splnění technické kvalifikace – seznam členů realizačního týmu
Účastník:
Obchodní firma/jméno ………….
Sídlo/místo podnikání ………….
IČO ………….
Zastoupen ………….
který podává nabídku na nadlimitní sektorovou veřejnou zakázku s názvem „Centrální Log Management“, č.j. 26302/2022-SŽ-GŘ-O8, tímto předkládá seznam techniků nebo technických útvarů, které se budou podílet na plnění veřejné zakázky, a osvědčení o vzdělání a o odborné kvalifikaci a současně čestně prohlašuje, že veškeré údaje níže uvedené jsou pravdivé.
1/28
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
Pozice č. 1 – Senior Architekt CLM1: [dodavatel na toto místo doplní jméno, příjmení a titul osoby, která bude tuto pozici zastávat]
Vztah člena realizačního týmu k dodavateli2 | [DOPLNÍ DODAVATEL] | |||||||
Název certifikátu (certifikát GSA nebo CISSP nebo CSAP+ nebo jiný platný certifikát s obdobným nebo vyšším rozsahem) | [DOPLNÍ DODAVATEL – DODAVATEL OZNAČÍ CERTIFIKÁT, CERTIFIKÁTU] | JEHOŽ | JE | DRŽITELEM, | A | SOUČASNĚ | PŘILOŽÍ | KOPII |
Držitel platného certifikátu k nabízenému CLM3 | [DOPLNÍ DODAVATEL - ANO/NE] | |||||||
Znalost anglického jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] | |||||||
Znalost českého (případně slovenského) jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] | |||||||
Praxe v oblasti návrhu architektury informační bezpečnosti | [DOPLNÍ DODAVATEL POČET LET PRAXE V DANÉ OBLASTI] | |||||||
1 Pokud bude tuto pozici zastávat více osob, dodavatel zkopíruje tuto tabulku dle potřeby.
2 Dodavatel uvede některou z následujících alternativ: pracovní poměr, dohoda o pracovní činnosti, dohoda o provedení práce, člen statutárního orgánu, OSVČ, příp. další možnost. Pro vyloučení pochybností Zadavatel uvádí, že pokud je člen realizačního týmu OSVČ, bude považován za jinou osobu ve smyslu § 83 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, se všemi důsledky z toho vyplývajícími.
3 Z uvedeného certifikátu musí vyplývat, že člen realizačního týmu splňuje veškeré podmínky dané výrobce CLM pro jeho instalaci. Zadavatel vyžaduje, aby alespoň jeden člen realizačního týmu byl držitelem tohoto certifikátu, přičemž tento certifikát musí být předložen v rámci nabídky dodavatele.
Praxe na pozici architekta informační bezpečnosti | [DOPLNÍ DODAVATEL POČET LET PRAXE V DANÉ OBLASTI] |
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í | [DOPLNÍ DODAVATEL] Projekt č. 1 Označení projektu: |
Doba realizace projektu: | |
Označení objednatele včetně kontaktu pro ověření uvedených informací: | |
Náplň projektu: | |
Pozice v projektu: | |
Projekt č. 2 | |
Označení projektu: | |
Doba realizace projektu: | |
Označení objednatele včetně kontaktu pro ověření uvedených informací: | |
Náplň projektu: | |
Pozice v projektu: |
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 | [DOPLNÍ DODAVATEL] Projekt č. 1 Označení projektu: Doba realizace projektu: Označení objednatele včetně kontaktu pro ověření uvedených informací: Náplň projektu: Pozice v projektu: |
NEBO | |
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 |
Pozice č. 2 – Senior System Engineer4: [dodavatel na toto místo doplní jméno, příjmení a titul osoby, která bude tuto pozici zastávat]
Vztah člena realizačního týmu k dodavateli5 | [DOPLNÍ DODAVATEL] |
Název certifikátu (certifikát GSEC nebo SSCP nebo CSSP nebo CSAP+ nebo jiný platný certifikát s obdobným nebo vyšším rozsahem) | [DOPLNÍ DODAVATEL – DODAVATEL OZNAČÍ CERTIFIKÁT, JEHOŽ JE DRŽITELEM, A SOUČASNĚ PŘILOŽÍ KOPII CERTIFIKÁTU] |
Držitel platného certifikátu k nabízenému CLM6 | [DOPLNÍ DODAVATEL - ANO/NE] |
Znalost anglického jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] |
Znalost českého (případně slovenského) jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] |
Praxe v oblasti návrhu architektury informační bezpečnosti | [DOPLNÍ DODAVATEL POČET LET PRAXE V DANÉ OBLASTI] |
4 Pokud bude tuto pozici zastávat více osob, dodavatel zkopíruje tuto tabulku dle potřeby.
5 Dodavatel uvede některou z následujících alternativ: pracovní poměr, dohoda o pracovní činnosti, dohoda o provedení práce, člen statutárního orgánu, OSVČ, příp. další možnost. Pro vyloučení pochybností Zadavatel uvádí, že pokud je člen realizačního týmu OSVČ, bude považován za jinou osobu ve smyslu § 83 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, se všemi důsledky z toho vyplývajícími.
6 Z uvedeného certifikátu musí vyplývat, že člen realizačního týmu splňuje veškeré podmínky dané výrobce CLM pro jeho instalaci. Zadavatel vyžaduje, aby alespoň jeden člen realizačního týmu byl držitelem tohoto certifikátu, přičemž tento certifikát musí být předložen v rámci nabídky dodavatele.
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í | [DOPLNÍ DODAVATEL] Projekt č. 1 Označení projektu: |
Doba realizace projektu: | |
Označení objednatele včetně kontaktu pro ověření uvedených informací: | |
Náplň projektu: | |
Pozice v projektu: |
[DOPLNÍ DODAVATEL] | |
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 | Projekt č. 1 Označení projektu: Doba realizace projektu: Označení objednatele včetně kontaktu pro ověření uvedených informací: Náplň projektu: Pozice v projektu: |
NEBO | |
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 |
Pozice č. 3 – Senior System Engineer: [dodavatel na toto místo doplní jméno, příjmení a titul osoby, která bude tuto pozici zastávat]
Vztah člena realizačního týmu k dodavateli7 | [DOPLNÍ DODAVATEL] |
Název certifikátu (certifikát GSEC nebo SSCP nebo CSSP nebo CSAP+ nebo jiný platný certifikát s obdobným nebo vyšším rozsahem) | [DOPLNÍ DODAVATEL – DODAVATEL OZNAČÍ CERTIFIKÁT, JEHOŽ JE DRŽITELEM, A SOUČASNĚ PŘILOŽÍ KOPII CERTIFIKÁTU] |
Držitel platného certifikátu k nabízenému CLM8 | [DOPLNÍ DODAVATEL - ANO/NE] |
Znalost anglického jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] |
Znalost českého (případně slovenského) jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - ANO/NE] |
Praxe v oblasti návrhu architektury informační bezpečnosti | [DOPLNÍ DODAVATEL POČET LET PRAXE V DANÉ OBLASTI] |
7 Dodavatel uvede některou z následujících alternativ: pracovní poměr, dohoda o pracovní činnosti, dohoda o provedení práce, člen statutárního orgánu, OSVČ, příp. další možnost. Pro vyloučení pochybností Zadavatel uvádí, že pokud je člen realizačního týmu OSVČ, bude považován za jinou osobu ve smyslu § 83 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů, se všemi důsledky z toho vyplývajícími.
8 Z uvedeného certifikátu musí vyplývat, že člen realizačního týmu splňuje veškeré podmínky dané výrobce CLM pro jeho instalaci. Zadavatel vyžaduje, aby alespoň jeden člen realizačního týmu byl držitelem tohoto certifikátu, přičemž tento certifikát musí být předložen v rámci nabídky dodavatele.
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í | [DOPLNÍ DODAVATEL] Projekt č. 1 Označení projektu: |
Doba realizace projektu: | |
Označení objednatele včetně kontaktu pro ověření uvedených informací: | |
Náplň projektu: | |
Pozice v projektu: |
[DOPLNÍ DODAVATEL] | |
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 | Projekt č. 1 Označení projektu: Doba realizace projektu: Označení objednatele včetně kontaktu pro ověření uvedených informací: Náplň projektu: Pozice v projektu: |
NEBO | |
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 |
Pozice č. 4 – Senior System Engineer: [dodavatel na toto místo doplní jméno, příjmení a titul osoby, která bude tuto pozici zastávat]
Vztah člena realizačního týmu k dodavateli9 | [DOPLNÍ DODAVATEL] |
Název certifikátu (certifikát GSEC nebo SSCP nebo CSSP nebo CSAP+ nebo jiný platný certifikát s obdobným nebo vyšším rozsahem) | [DOPLNÍ DODAVATEL – DODAVATEL OZNAČÍ CERTIFIKÁT, JEHOŽ JE DRŽITELEM, A SOUČASNĚ PŘILOŽÍ KOPII CERTIFIKÁTU] |
Držitel platného certifikátu k nabízenému CLM10 | [DOPLNÍ DODAVATEL - ANO/NE] |
Znalost anglického jazyka na úrovni požadované v článku 12.2.3. ZD | [DOPLNÍ DODAVATEL - |