K U P N Í S M L O U V A
K U P N Í S M L O U V A
uzavřená dle ustanovení § 2079 a násl. zákona č. 89/2012 Sb., občanského zákoníku (dále jen „občanský zákoník“)
Smluvní strany
1. Aricoma Systems a.s.
se sídlem: Xxxxxxxxxx 0000/00, 000 00 Xxxxxxx
zastoupená Xxx. Xxxxxxxx Xxxxxx, člen představenstva IČO: 04308697
DIČ: CZ04308697
Spisová značka - B 11012 vedená u Krajského soudu v Ostravě bankovní spojení: Česká spořitelna a.s., číslo účtu: 6563752/0800
(dále jen „prodávající“)
a
2. Zdravotnická záchranná služba Kraje Vysočina, příspěvková organizace
Xxxxxxxxxxx 00, 000 00 Xxxxxxx
IČO: 47366630
DIČ: CZ47366630 - neplátce DPH
zastoupená ředitelkou Ing. Xxxxxxxxxxx Xxxxxxx
bankovní spojení: KB Jihlava, číslo účtu: 26736681/0100 (dále jen „kupující“)
uzavírají tímto kupní smlouvu dle příslušných ustanovení občanského zákoníku.
uzavírají tímto kupní smlouvu v rámci veřejné zakázky malého rozsahu na dodávku a implementaci systému pro centralizované ukládání a správu logů (ev. č. xxxxxxx XX 6/24)
Článek I.
Předmět smlouvy
1. Předmětem smlouvy je dodávka a implementace centrálního úložiště pro sběr a analýzu logů (SEM/SIEM řešení) s možností následné analýzy a řešení bezpečnostních událostí/incidentů z kritických systémů a aplikací dle specifikace uvedené v Příloze č. 1 kupní smlouvy a dále technická podpora HW a SW a licenční oprávnění k SW.
2. Kupující se zavazuje převzít dodané zboží do svého vlastnictví a zaplatit prodávajícímu dohodnutou kupní cenu.
Článek II.
Dodací podmínky
1. Prodávající dodá kupujícímu předmět koupě nejpozději do 45 dnů od data účinnosti smlouvy.
2. Prodávající je povinen v dodací lhůtě dle odst. 1 dodat do sídla kupujícího kompletní dodávku včetně implementace a oživení. Prodávající je povinen předat kupujícímu společně s dodávkou veškerou dokumentaci potřebnou k provozu zařízení (tj. návod k obsluze, záruční list atd. v českém jazyce). Dále prodávající předá i úplnou a podrobnou dokumentaci systému v českém jazyce, obsahem i kvalitou musí být srovnatelná s aktuální dokumentací v originálním jazyce. V případě, že je potřebné zaškolení, bude poskytnuto ve stejné lhůtě.
3. Vlastnické právo, jakož i nebezpečí škody na věci přechází na kupujícího okamžikem převzetí předmětu koupě.
4. Prodávající vyrozumí kupujícího nejméně 3 dny před zamýšleným datem dodání o tom, že hodlá předat předmět koupě, aby byl kupující schopen poskytnout mu potřebnou součinnost. Kontaktní osoba kupujícího: Xxx. Xxxxxx Xxxxxxx, tel.: 000 000 000, xxxxxxx@xxxxxxxxxxx.xx
5. O předání bude vyhotoven písemný předávací protokol podepsaný oběma smluvními stranami.
6. Prodávající je povinen zajistit, že předmět plnění dle této smlouvy bude trvale splňovat bezpečnostní požadavky uvedené v příloze č. 3 této smlouvy.
Článek III.
Místo plnění
1. Místem plnění je sídlo kupujícího Zdravotnická záchranná služba Kraje Vysočina, příspěvková organizace, Vrchlického 61, 586 01 Jihlava.
Článek IV.
Doba plnění
1. Prodávající je povinen předat kupujícímu předmět koupě nejpozději do 45 dnů od data účinnosti smlouvy. Licenční oprávnění se sjednávají na neomezenou dobu, technická podpora HW a SW na dobu pěti let.
Článek V.
Kupní cena
1. Kupující se zavazuje zaplatit za zboží uvedené v příloze č. 1 této smlouvy kupní cenu ve výši:
POPIS | CENA CELKEM V KČ | ||
BEZ DPH | SAZBA DPH | VČETNĚ DPH | |
CENA CELKEM ZA PŘEDMĚT PLNĚNÍ | 863 075,00 | 181 245,75 | 1 044 320,75 |
a to na základě faktury vystavené prodávajícím. Celková cena je stanovena jako nejvýše přípustná se započtením veškerých nákladů (rizika, zisk, finanční vlivy, licenční oprávnění, technická podpora atd..).
2. Pro účely fakturace je rozhodná celková cena, tedy cena včetně DPH. Fakturační adresa je totožná se sídlem kupujícího. K faktuře musí být připojen dodací list.
3. Smluvní strany se dohodly, že v případě změny zákonných sazeb DPH nebudou uzavírat písemný dodatek k této smlouvě o změně výše ceny, a DPH bude účtována podle předpisů platných v době uskutečnění zdanitelného plnění.
4. Úhrada bude realizována bezhotovostním převodem ve lhůtě 15 dnů ode dne vystavení faktury na účet prodávajícího, který je správcem daně (finančním úřadem) zveřejněn způsobem umožňujícím dálkový přístup ve smyslu ustanovení § 98 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů. Tuto celkovou cenu lze změnit pouze z důvodu změny zákonných sazeb DPH.
5. Pokud se po dobu účinnosti této smlouvy prodávající stane nespolehlivým plátcem ve smyslu ustanovení § 106a zákona o DPH, smluvní strany se dohodly, že kupující uhradí DPH za zdanitelné plnění přímo příslušnému správci daně. Kupujícím takto provedená úhrada je považována za uhrazení příslušné části smluvní ceny rovnající se výši DPH fakturované prodávajícím.
6. Kupující je oprávněn fakturu s udáním důvodu vrátit před uplynutím lhůty její splatnosti, pokud má závady v obsahu. Oprávněným vrácením faktury přestává běžet původní lhůta splatnosti. Doručením nové faktury počíná běžet nová lhůta splatnosti.
Článek VI.
Záruka na jakost
1. Záruka na předmět plnění činí 60 měsíců. Záruční lhůta počíná běžet dnem řádného předání předmětu koupě.
2. Poskytnutá záruka na jakost znamená, že dodané zboží bude po dobu záruky plně funkční a bude mít vlastnosti odpovídající právním předpisům, obsahu technických norem, eventuálně dalších technických požadavků či norem (např. ISO), které má zboží splňovat, a které se na dané zboží vztahují, a bude mít vlastnosti uváděné výrobcem či prodávajícím.
3. Kupující (oprávněná osoba) nahlásí prodávajícímu závady/reklamace na kontaktní místo prodávajícího prostřednictvím e-mailu nebo telefonicky. Prodávající potvrdí kupujícímu e-mailem nebo telefonicky, že obdržel výzvu k odstranění poruchy. V potvrzení uvede označení evidované poruchy a termín zahájení prací na odstraňování poruchy. Vady se zpravidla odstraňují na pracovištích kupujícího, nebude-li v konkrétním případě dohodnuto jinak. V případě, že vady budou po dohodě odstraňovány na pracovišti prodávajícího, náklady na přepravu nese prodávající. V případě neodstranitelné záruční závady se prodávající zavazuje k výměně stávající vadné věci za věc novou se shodnými parametry.
4. Tam, kde to povaha servisních služeb umožňuje, budou servisní služby poskytovány dálkově elektronickými prostředky.
5. Záruční závady budou odstraněny bezplatně následující pracovní den od nahlášení závady, pokud se strany nedohodnou jinak.
6. Kontaktní údaje prodávajícího pro potřeby nahlášení závady, reklamace:
kontaktní osoba: Xxxxxx Xxxxxxx
telefon: x000 000 000 000
Článek VII.
Sankce
1. V případě, že kupující nedodrží dobu splatnosti faktur dle čl. V odst. 4, má prodávající právo požadovat úrok z prodlení ve výši 0,03 % z dlužné částky včetně DPH za každý započatý den prodlení.
2. Kupující si vyhrazuje právo požadovat smluvní pokutu ve výši 1 000,- Kč za každý započatý den, kdy je prodávající byť i jen zčásti v prodlení s dodáním předmětu koupě. Tím není dotčeno právo kupujícího požadovat v plném rozsahu i náhradu škody prodlením prodávajícího způsobené.
3. Kupující si vyhrazuje právo požadovat smluvní pokutu ve výši 500,- Kč za každý započatý den, kdy je prodávající byť i jen zčásti v prodlení s odstraněním záruční vady (resp. náhradou neopravitelného předmětu koupě) dle čl. VI.
4. Prodávající se zavazuje zachovat mlčenlivost o všech skutečnostech, týkajících se osobních, majetkových a jiných obdobných poměrů kupujícího, s nimiž se při plnění podle této smlouvy seznámí. Pro případ pochybností platí, že jde o skutečnost chráněnou mlčenlivostí dle tohoto ujednání smlouvy. Porušením závazku k povinné mlčenlivosti dle tohoto ujednání není sdělování chráněných skutečností v rámci plnění nějaké oznamovací povinnosti dle zákona. Pro případ porušení tohoto závazku prodávajícího se prodávající zavazuje zaplatit kupujícímu smluvní pokutu ve výši 100 000,-Kč za každý zjištěný případ tohoto porušení.
5. Ustanovení odst. 4 včetně výše uvedené smluvní pokuty se přiměřeně uplatní i pro porušení povinností vyplývajících z obecně závazných předpisů upravujících ochranu osobních údajů ze strany prodávajícího.
Článek VIII.
Odstoupení od smlouvy
1. Kromě důvodů stanovených občanským zákoníkem je kupující oprávněn odstoupit od smlouvy v případě, že na straně prodávajícího dojde k dodání zboží, které nebude splňovat požadavky uvedené v příloze č. 1 smlouvy, a pokud prodávající nesjedná nápravu do 7 dnů, přestože bude na tuto skutečnost písemně upozorněn.
2. Kupující si vyhrazuje právo odstoupit od smlouvy v případě, že prodávající nedodá řádně předmět koupě ani do 15 dnů po uplynutí lhůty uvedené ve čl. IV odst. 1.
3. Smluvní strany se dohodly, že v případě odstoupení od smlouvy nebo její části nezaniká právo kupujícího na úhradu smluvní pokuty dle čl. VII odst. 2.
4. Odstoupení je účinné okamžikem doručení písemného oznámení o odstoupení druhé smluvní straně.
Článek IX.
Další ujednání
1. Tato smlouva nabývá platnosti dnem podpisu a účinnosti dnem uveřejnění v informačním systému veřejné správy - Registru smluv.
2. Smluvní strany berou na vědomí, že text smlouvy bude zveřejněn v informačním systému veřejné správy
- Registru smluv. Přílohu č. 1 a č. 2 považuje kupující za obchodní tajemství ve smyslu § 504 občanského zákoníku a dle příslušných právních předpisů jej tedy není možné zveřejnit spolu se smlouvou. Povinnost zveřejnění splní kupující. V případě nesplnění zákonné povinnosti je smlouva do tří měsíců od jejího podpisu bez dalšího zrušena od samého počátku.
3. Práva a povinnosti výslovně neupravené touto smlouvou se řídí příslušnými ustanoveními občanského zákoníku.
4. Nedílnou součástí smlouvy je příloha č. 1: Podrobná technická specifikace, č. 2: Seznam podporovaných systémů a č. 3: Bezpečnostní požadavky.
5. Jakékoliv změny nebo doplňky této smlouvy nebo přílohy ke smlouvě musí být provedeny formou písemných, číslovaných dodatků, odsouhlasených a podepsaných oběma smluvními stranami.
6. Prodávající prohlašuje, že se před uzavřením smlouvy nedopustil v souvislosti se zadávacím řízením sám nebo prostřednictvím jiné osoby žádného jednání, jež by odporovalo zákonu nebo dobrým mravům nebo by zákon obcházelo, zejména že nenabízel žádné výhody osobám podílejícím se na zadání veřejné zakázky, na kterou s ním zadavatel uzavřel smlouvu, a že se zejména ve vztahu k ostatním účastníkům nedopustil žádného jednání narušujícího hospodářskou soutěž.
7. Kupující má právo vypovědět tuto smlouvu v případě, že v souvislosti s plněním účelu této smlouvy dojde ke spáchání trestného činu. Výpovědní lhůta v takovém případě činí 3 dny a začíná běžet dnem následujícím po dni, kdy bylo písemné vyhotovení výpovědi doručeno prodávajícímu.
8. Smluvní strany prohlašují, že si tuto smlouvu přečetly, že se dohodly na celém jejím obsahu, že se smluvními podmínkami souhlasí a že smlouva nebyla podepsána v tísni ani za nápadně jednostranně nevýhodných podmínek.
9. Tato smlouva je vyhotovena v elektronické formě a je podepsaná platnými uznávanými elektronickými podpisy. Každá ze smluvních stran obdrží smlouvu v elektronické formě.
V Jihlavě dne V Jihlavě dne
Xxx. Xxxxxxxxxx Xxxxxx
Digitálně podepsal Xxx. Xxxxxxxxxx Xxxxxx Datum: 2024.07.25
13:10:56 +02'00'
Xxx. Xxxxxxxx Xxxxxx
Digitálně podepsal Xxx. Xxxxxxxx Xxxxxx
Datum: 2024.07.25
…..…………..…………………..
08:10:01 +02'00'
………………………………….
za kupujícího za prodávajícího
Xxx. Xxxxxxxxxx Xxxxxx Xxx. Xxxxxxxx Xxxxxx ředitelka člen představenstva
Příloha č. 1 : Technická specifikace
Popis - Řešení SEM do 2000 událostí za sekundu s minimálně 12TB velikostí databáze | Splňuje | |
Obecné požadavky na systém pro centralizovanou správu logů, událostí a strojových dat | ||
1 | Systém pracuje jako hardwarová appliance s jedním uceleným webovým rozhraním pro všechny administrátorské i operátorské činnosti. Nevyžaduje instalaci dalších systémů a aplikací, vyjma podpory sběru na pobočkách a agenta pro sběr Windows logů. | Ano |
2 | Systém provádí zpracování událostí z předdefinovaných zdrojů logů napříč výrobci aplikací, operačních systémů a síťového hardware (viz příloha č. 2 - Seznam podporovaných systémů). | Ano |
3 | Veškerá konfigurace systému se musí provádět v grafickém rozhraní jednotné uživatelské webové konzole. Systém poskytuje podporu pro vizuální programování pro všechny kroky zpracování strojových dat. Ve webové konzoli se nepřipouští konfigurace za využití skriptů, maker nebo textových konfiguračních polí, do kterých se složité textové skripty/makra vkládají. | Ano |
4 | Systém umožňuje dopsání parserů pro výše neuvedená zařízení uživatelem bez nutnosti spolupráce s výrobcem nebo dodavatelem (vč. subdodavatelů) nabízeného systému - Uživatelsky definované parsery. Dokumentace musí obsahovat přehledný návod na vytváření zákaznických parserů a systém musí obsahovat možnost testování a ladění zákaznických parserů v jednotném ovládacím grafickém webovém rozhraní viz bod č. 1. Vytváření a testování parserů nesmí mít vliv na provoz systému. Pro psaní parserů nesmí být použito textové psaní programového kódu ale tzv. vizuální programování, které automaticky opravuje uživatele a upozorňuje ho na chyby. Požadujeme předložit příslušnou dokumentaci k vytváření parserů a testování jejich funkčnosti. | Ano |
5 | Systém umožňuje v grafickém rozhraní vizuálního programovacího jazyka snadno provádět třídění a značkování vstupních dat pro jejich další zpracování. Nepřipouští se nastavování třídění vstupních dat ve formě skriptu/makra zobrazeného v textovém okně. Předložte příslušný odkaz na dokumentaci výrobce popisující funkčnost třídění vstupních dat. | Ano |
6 | Systém přijímá a zpracovává logy, události a další strojově generovaná data prostřednictvím minimálně následujících protokolů: SYSLOG (dle RFC3164, RFC5424, RFC5425) a RELP. Systém musí umožňovat příjem logů i na rozsahu alespoň 50 UDP a TCP portů pro zjednodušené třídění vstupních zpráv. Dále je požadována podpora sběru strojových dat z databází s nastavením v grafickém menu systému minimálně pro databáze MSSQL, MySQL, Oracle a PostgreSQL a to bez nutnosti instalovat na databázový server doplňkový software nebo agenta. | Ano |
7 | Přijaté logy systém standardizuje do jednotného formátu a logy jsou normalizovány (rozdělovány) do příslušných polí dle jejich typu. Zároveň systém uchovává i originální verzi zpráv. Integrované parsery systému automaticky přidávají ke zprávám, kterých se to týká, meta informace o jaký druh zprávy se jedná, minimálně požadujeme rozlišení těchto druhů zpráv: úspěšné přihlášení, neúspěšné přihlášení, odhlášení, konfigurační změna, značka/tag. Tyto meta informace musí být možné přidávat i v uživatelsky definovaných parserech. | Ano |
8 | Hodnoty jednotlivých parsovaných polí je možné v definici parseru přetypovat a standardizovat alespoň na tyto základní druhy: číslo, IP adresa, MAC adresa, URL. Nad uloženými čísly je pak možné při prohledávání dat provádět matematické operace (součty všech hodnot, průměry, nejmenší/největší hodnota apod.). | Ano |
9 | Systém zachovává původní informaci ze zdroje logu o časové značce události, ale nedůvěřuje jí a vytváří vlastní důvěryhodné časové razítko ke každému logu, které vzniká v okamžiku přijetí logu systémem a kterým se systém defaultně řídí. | Ano |
10 | Všechna pole a položky přijaté systémem jsou automaticky indexovány. Nad všemi položkami je možné ihned provádět vyhledávání bez nutnosti dodatečného ručního indexování administrátorem. | Ano |
11 | Možnost sběru událostí minimálně ve formátech RAW, Syslog RFC5424, CEF, LEEF, JSON RFC8259. | Ano |
12 | Systém nesmí v žádném případě umožnit mazání nebo modifikování již uložených logů v rámci požadované retence. A to ani libovolnou konfigurační změnou - administrátorovi s nejvyššími oprávněními k navrhovanému systému. Každý zpracovaný log musí mít dohledatelný unikátní identifikátor, který umožní jeho jednoznačnou identifikaci. | Ano |
13 | Systém musí umožňovat konfiguraci filtrace nerelevantních událostí v grafickém rozhraní vizuálního programovacího jazyka. Pro psaní filtrace nesmí být použito textové psaní programového kódu ale tzv. vizuální programování, které automaticky opravuje uživatele a upozorňuje ho na chyby. Předložte odkaz na dokumentaci popisující způsob filtrování nerelevantních událostí. | Ano |
14 | Systém provádí konsolidaci logů na interním storage logovacího systému. | Ano |
15 | Systém umožňuje snadné vyhledávání událostí a okamžité vytváření grafických reportů (ad hoc) bez nutnosti dodatečného programování nebo aplikování dotazů v SQL jazyce. Reportovací nástroj musí být integrální součástí navrhovaného systému a musí se obsluhovat v jednotném rozhraní nabízeného produktu. Předložte link nebo pdf popisující způsob vytváření reportů. | Ano |
16 | Systém provádí ucelenou vizualizaci logů, událostí a strojových dat (grafy událostí). Vizualizace musí být dynamická, tj. volbou v jednom grafu se ostatní příslušné grafy v pohledu na data upraví dle požadované volby automaticky. | Ano |
17 | Systém umožňuje snadno vytvářet grafické znázornění událostí v dashboardech nad všemi uloženými daty za libovolné časové období bez nutnosti nejprve modifikovat konfiguraci systému nebo parametrů uložených dat. Historická data v požadované délce retence uložená v systému je možné prohledávat okamžitě bez časových prodlev opětovného importu nebo dekomprimace starších dat, prohledávání dat nesmí vyžadovat manuální konfiguraci a zásahy uživatele. | Ano |
18 | Systém podporuje nativní získávání logů z Office365/Microsoft365 prostředí bez ohledu na použitou licenci 365 prostředí a bez nutnosti instalovat dodatečné externí komponenty. Požadujeme předložit link na dokumentaci popisující nastavení systému v jednotném grafickém rozhraní tak, aby získával logy z Office365/Mircosoft365. | Ano |
19 | V případě krátkodobého (do 10 minut) až dvounásobného přetížení systému proti jeho tabulkovým hodnotám nesmí dojít ke ztrátě logů nebo nesprávnému stanovení časového razítka. Všechny přijaté nezpracované logy/události musí být ukládány do vyrovnávací paměti. | Ano |
20 | Systém musí umožňovat unifikované vyhledávání napříč všemi typy dat a zařízeními dle normalizovaných polí (uživatelské jméno, zdrojová IP, značka/tag apod.). | Ano |
21 | Systém musí mít možnost uložení uživatelem vytvořených pohledů na data (dashboardů) pro budoucí zpracování. Továrně dodané pohledy na data nesmí jít administrátorem ani uživatelem systému nevratně modifikovat nebo smazat. | Ano |
22 | Systém obsahuje reportovací nástroj s přednastavenými nejběžnějšími reporty a možností vlastních úprav a vytvoření nových pohledů. Pro vytváření nových pohledů na data není přípustné používat povinně SQL jazyk. | Ano |
23 | Systém obsahuje předpřipravené pohledy na uložená data dle jednotlivých kategorií zdrojových zařízení i dle logického členění. | Ano |
24 | Na základě pohledu na uložená data lze provést export dat ve strukturovaném formátu tak, jak jsou v továrně nastaveném nebo uživatelsky nastaveném pohledu data skutečně zobrazena. | Ano |
25 | Konfigurační a Systémové rozhraní a dokumentace k těmto rozhraním musí být identické v anglickém i v českém jazyce. Nepřipouští se omezená dokumentace v českém jazyce nebo zjednodušená dokumentace odkazující na další dokumentaci v anglickém jazyce, případně na dokumentaci třetích stran. Požadujeme předložit link na online dokumentaci nebo připojit pdf aktuální kompletní dokumentace k ověření jednotlivých vlastností navrhovaného systému. | Ano |
26 | Systém nabízí kapacitní i výkonovou škálovatelnost. | Ano |
27 | Čistá kapacita úložného prostoru (kapacita diskového pole) dostupná pro uložená data nabízeného systému musí být minimálně 12TB. | Ano |
28 | Ze systému musí být možné za běhu vytáhnout libovolný disk, bez ztráty dat a vlivu na funkčnost řešení. Redundance disků nesmí ovlivňovat požadovanou kapacitu úložiště. | Ano |
29 | Monitoring stavu systému - alertování při překročení prahových hodnot nebo chybě systému, přeposlání upozornění pomocí SMTP nebo Syslog. | Ano |
30 | Systém musí obsahoval REST-API pro integraci s externím monitorovacím systémem (Zabbix, Nagios, MRTG a další) a umožňoval autorizovaný přístup ke strukturované databázi logů. Zadavatel požaduje předložit vzorový návod na integraci s externím monitorovacím systémem. | Ano |
31 | Jednotná centrální webová konzole s jednotným grafickým rozhraním pro přístup k logům, alertům, reportům a pro správu systému. Z této konzole se provádí veškerá konfigurace, správa i analýza logů. Není přípustné, aby navrhovaný systém měl více rozdílných konzolí od různých výrobců s rozdílným ovládáním nebo aby se konfigurace musela provádět mimo jednotné webové rozhraní. | Ano |
32 | Systém musí umožňovat jednotné vytváření uživatelských rolí definujících přístupová práva k uloženým událostem na základě typu zdrojů a značek a k jednotlivým ovládacím komponentům systému. | Ano |
33 | Dodaný systém musí obsahovat ucelené all-in-one řešení pro parsování a normalizaci přijatých událostí bez nutnosti dodatečné instalace externích aplikací nebo systémů. Jedinou přípustnou výjimkou je monitorování systémů Windows pomocí agentů. | Ano |
34 | Systém musí podporovat ověřování uživatele systému na externím LDAP serveru. V případě výpadku externího LDAP systému musí podporovat ověření lokálního účtu. Systém automaticky zaznamenává uživatelská jména u akcí provedených konkrétním uživatelem. | Ano |
Minimální HW parametry požadovaného systému | ||
35 | Jedna hardwarová appliance o velikosti max. 1U, včetně ramena pro kabelový management umožňujícího vysunutí zapnutého systému z racku pro servisní účely. | Ano |
36 | HW appliance obsahuje veškeré potřebné komponenty (CPU, RAM, diskový prostor) pro svoji činnost a je nezávislá na dalších systémech. | Ano |
37 | 1 procesor, min. 16 jader, s podporou HyperThreadingu nebo Multi-Threadingu. | Ano |
38 | RAM Min. 64GB DDR-4. | Ano |
39 | Minimálně 12TB pro integrovanou databázi podporovanou HW akcelerovaným SAS RAID řadičem. Řadič diskového pole musí obsahovat zálohovací baterii nebo být vybaven flash pamětí. | Ano |
40 | V systému minimálně 4 ks stejných RAID edition disků určených pro použití v datacentrech, o rychlosti minimálně 7200 otáček/m (z výkonových důvodů). | Ano |
41 | Minimálně 4x 1Gbit LAN porty + 1x dedikovaný 1Gbit port pro management HW. Konfigurace všech parametrů síťového rozhraní včetně link agregace dle LACP (802.3ad), VLAN a IP adresace v jednotném webovém rozhraní systému. | Ano |
42 | Větráky v systému musí být vyměnitelné za provozu a redundantní. | Ano |
43 | 2x napájecí zdroje s redundancí napájení 1+1. | Ano |
44 | Virtuální KVM (tj. převzetí textové i grafické konzole serveru a zajištění přenosu povelů z klávesnice a myši vzdáleného počítače. | Ano |
45 | Systém pro vzdálenou správu serveru včetně potřebné licence, pokud je třeba (obdoba HP iLO, Dell iDRAC apod.). | Ano |
Minimální výkonnostní a SW parametry systému | ||
46 | Systém funguje formou HW appliance (všechny části systémů je možné nastavit v centrální webové konzoli a není nutné editovat žádné konfigurační soubory, scripty nebo makra v příkazové řádce). | Ano |
47 | Aktualizace systému jsou distribuovány v jednotném balíku a jejich instalace je prováděna uživatelsky přes centrální webovou správcovskou konzoli. Všechny aktualizace musí být prováděny z webového prostředí bez potřeby asistence dodavatele/výrobce dodávaného systému. | Ano |
48 | Systém musí podporovat downgrade v jednom kroku, pro případ problémů s novou verzí systému po upgrade. Není přípustný downgrade pouze za součinnosti výrobce. | Ano |
49 | Průměrný trvalý příjem min. 2000 událostí/s. Výkon musí být dosažen na požadované množství událostí s průměrnou délkou zpráv minimálně 700Byte trvale. Systém musí prokazatelně kompletně zpracovat přijaté události včetně vytváření očekávaných metadat (DNS-PTR, čísla a jména ASN, geolokace), zajišťovat normalizaci, zamezovat ztrátě přijatých událostí nebo posunutí důvěryhodného časového razítka oproti času skutečného příjmu každé události. | Ano |
50 | Špičkový příjem minimálně 4000 událostí/s po dobu nejméně 10 minut a průměrnou délkou minimálně 700byte. Systém musí prokazatelně kompletně zpracovat přijaté události, zamezovat ztrátě ukládaných dat nebo posunutí důvěryhodného časového razítka oproti času skutečného příjmu zpráv. Při zpracování dat během špičkového příjmu akceptujeme zpoždění zobrazení zpracovávaných dat. Systém ani ve špičkovém výkonu nesmí dovolit ztrátu dat, skluz důvěryhodného časového razítka nebo jiné prokazatelné vady na zpracovávaných datech oproti zpracování při průměrném trvalému příjmu událostí. | Ano |
51 | Licenčně neomezený počet zařízení pro příjem zasílaných událostí. Licenčně neomezený počet událostí v GB za den nebo licence na minimálně 200GB uložených událostí za den. Integrovaná databáze musí mít čistou velikost nejméně 12 TB a nad to musí podporovat kompresi ukládaných dat. | Ano |
52 | Uživatelská konfigurace klasifikace dat, parserů, filtrů a alertů se provádí pomocí vizuálního programovacího jazyka v centrální správcovské webové konzoli. Vizuální programovací jazyk musí uživateli umožnit psát konfigurace bez nutnosti znalosti programování (např. Node-RED, Microsoft VPL, Blockly apod.). Vizuální programovací jazyk není prezentován textově, ale graficky formou schémat-symbolů, které reprezentují aplikační logiku a kontrolují syntaxi. Doložte odkazem na dokumentaci systém vizuálního programování a popisu jednotlivých použitých komponent vizuálního programování nástroje. | Ano |
53 | Konfigurace uživatelských parserů musí umožňovat automatické doplňování DNS reverzních záznamů, čísel a jmen autonomních sítí, geolokační informace a identifikace výrobce zařízení podle MAC adresy. | Ano |
54 | Systém musí podporovat doplňování zpráv o informace z textových prohledávacích tabulek. (např. k uživatelskému jménu doplnit z textové prohledávací tabulky informaci o jeho emailu, členství v AD skupinách a podobně). Pro automatickou aktualizaci takto uložených doplňujících informací musejí být tyto textové prohledávací tabulky naplnitelné pomocí REST API nabízeného systému a modifikovatelné přes jednotné webové rozhraní. Doložte odkazem na dokumentaci, jakým způsobem lze plnit textové tabulky prostřednictvím REST-API nabízeného systému. | Ano |
55 | Možnost on-line ladění uživatelsky definovaných parserů - při jejich vytváření je možné vložit skupinu testovacích zpráv, při změně je okamžitě zobrazena výsledná podoba rozparsovaných dat a případná chybová hlášení s upozorněním na chybná místa vytvářeného parseru. Pro snadnější vytváření parserů požadujeme mít možnost vložení minimálně 20 testovacích zpráv současně. | Ano |
56 | V centrální správcovské konzoli je možné přidávat k jednotlivým zdrojům dat, aplikacím, zařízením nebo IP subnetům tzv. značky, označující například umístění zařízení, typ zařízení, kritičnost zařízení apod. Systém obsahuje předdefinované značky, které automaticky přidává k přijímaným zprávám. Příklady značek: konfigurační změna, úspěšné ověření uživatele, neúspěšné ověření uživatele, zpráva přišla z windows, zpráva byla vygenerována firewallem atd... | Ano |
57 | Všechny přidávané značky jsou ukládány s každou přijatou událostí, na základě značky je možné filtrovat data nebo omezovat oprávnění uživatelů systému k jednotlivým událostem. | Ano |
58 | Pro budoucí nasazení ve vysoké dostupnosti a výkonnostní rozšíření je vyžadována podpora sestavení ve vysoké dostupnosti – požadujeme podporu minimálně 4 nodů v clusteru. Nastavení clusteru se musí kompletně realizovat v grafickém rozhraní správcovské konzole v jednom kroku, není přípustné konfigurovat sestavení scripty, makry nebo úpravou textové konfigurace systému a pomocí ručních restartů služeb. Systém ve vysoké dostupnosti musí přehledně informovat o stavu clusteru a procesu synchronizace databází. Dokumentace k realizaci vysoké dostupnosti musí být kompletní a popisovat všechny kroky sestavování a obnovení v případě výpadku komponenty clusteru. | Ano |
59 | Vícenodový cluster se chová i ovládá jako jednotný systém, nutnost nezávislé konfigurace na každé jednotce v clusteru je vyloučena. Vícenodový cluster umožnuje geolokační oddělení a pro komunikaci v rámci clusteru musí využívat definovaný TCP/UDP port pro snadné nastavení prostupy firewallu. Veškerá komunikace v rámci clusteru musí být šifrovaná s vysokým kryptografickým standardem pro bezpečné vytvoření privátní virtuální sítě na síťové vrstvě. | Ano |
60 | V případě využití více nodů v clusteru se automaticky zrychluje zpracování vstupních dat a vyhledávání v již uložených datech. | Ano |
61 | V případě rozšíření systému na cluster musí navrhovaný systém zajistit bezvýpadkovost sběru logů. | Ano |
62 | Systém musí umožňovat export dat ve formátu vhodném pro další strojové zpracování bez dodatečných omezení na časové období, množství nebo obsah exportovaných dat. Během exportu je možné označit pouze vybraná pole, která mají být do exportu zahrnuta. | Ano |
63 | Podpora zálohování nebo obnovení konfigurace v jednom kroku a jednom souboru pro celý systém. Doložte odkazem na dokumentaci, jakým způsobem se provádí zálohování a obnova konfigurace systému. | Ano |
64 | Podpora důvěryhodného zálohování dat na externí systém. Požadováno plánované i ad-hoc zálohování. Zálohy dat musejí být vhodně kompresovány a umožnit v budoucnosti obnovení bez ohledu na verzi systému, ve které byla záloha pořízena. Doložte odkazem na dokumentaci, jakým způsobem se realizuje zálohování a obnova záloh. | Ano |
Alerty | ||
65 | Systém je schopen na základě uživatelsky zadaných podmínek splněných v přijatých datech vygenerovat alert. | Ano |
66 | Text e-mailu vygenerovaného alertem musí být uživatelsky definovatelný s proměnnými, které jsou vyplněny z přijaté rozparsované události. | Ano |
67 | Systém musí obsahovat výrobcem předpřipravené sety/vzory alertů a korelací. | Ano |
68 | Systém musí provádět konfigurace alertů a korelací pomocí vizuálního programovacího jazyka. Vizuální programovací jazyk není prezentován čistě textově, ale textově-grafickou formou, která vizualizuje aplikační logiku vytvářeného alertu. Konfigurace alertů musí umožňovat okamžitou kontrolu funkčnosti výstupu alertu nebo korelace vložením příslušné testovací zprávy, včetně zobrazení upozornění na případné uživatelské chyby. Doložte odkazem na dokumentaci, jakým způsobem realizujete konfiguraci a testovaní alertů a korelací. | Ano |
69 | Jako výstupní pravidlo Alertu musí systém umět odeslat událost, která alert vyvolala, na externí systém minimálně prostřednictvím SMTP nebo Syslogu přes TCP protokol. U Syslog protokolu požadujeme možnost definice formátu odesílaných dat pro snazší integraci se systémy třetích stran - účastík doloží odkazem na dokumentaci, jakým způsobem se zpráva, která vyvolala spuštění alertu, odesílá na externí systém a jak se definuje formát odesílání dat. | Ano |
70 | V alertech je možné nejen využívat, ale i přiřazovat značky (příklad: pošli alert jen v případě, že se událost stala na kritickém serveru a je označen názvem lokality, nebo pokud událost obsahuje podmínku, přiřaď novou značku). | Ano |
71 | Systém podporuje základní funkce SIEM - funkce pro korelace událostí a upozornění s hraničními limity. Definice korelačních pravidel je prováděna pomocí vizuálního programovacího jazyka a musí obsahovat možnost vložení testovací zprávy a zobrazení výsledku testu o provedené akci. | Ano |
Sběr událostí z Microsoft prostředí | ||
72 | Události z Microsoft prostředí jsou vyčítány pomocí agenta instalovaného přímo v koncových systémech. Windows agent musí současně podporovat jak monitoring interních windows logů, tak monitoring textových souborových logů. Agent se nesmí instalovat individuálně, ale prostřednictvím MS AD Group Policy a nesmí vyžadovat žádnou konfiguraci na cílovém systému. Doložte odkaz na dokumentaci popisující požadované vlastnosti integrovaného Windows agenta. | Ano |
73 | Agent provádí instalaci a podporuje centralizovanou konfiguraci Microsoft Sysmon pro obohacení logů, včetně globálního a selektivního zapínaní/vypínaní služby Sysmon a výběr z několika přednastavených konfigurací Sysmon v grafickém rozhraní centrální správcovské konzole systému. Doložte odkazem na dokumentaci, jakým způsobem se provádí centralizované řízení a konfigurace Microsoft Sysmon služby. | Ano |
74 | Agent sběru z Microsoft podporuje globální i lokální nastavení filtrace odesílaných událostí pomocí centrální správcovské konzole. Například, zašli pouze logy z adresářů eventview Systém, Security, Sysmon a Terminal Services a zahoď logy s EventId 7036. | Ano |
75 | Filtrace odesílaných událostí agenty se konfiguruje pomocí vizuálního programovacího jazyka z centrální správcovské konzole systému. Logy nastavené k filtraci jsou filtrovány na straně windows agenta a nejsou nijak odesílány po síti. Vizuální programovací jazyk není prezentován textově, ale textově-grafickou formou, která vizualizuje aplikační logiku vytvářeného alertu. Doložte odkazem na dokumentaci, jakým způsobem se vytváří a přiřazují filtry pro Windows agenty pro sběr logů a jakým způsobem se testuje účinnost filtru. | Ano |
76 | Windows agent nevyžaduje administrátorské zásahy na koncovém systému – je centrálně spravovaný a jeho konfigurace musí být kompletně realizována v grafickém rozhraní systému bez využití skriptů nebo maker. Konfigurace musí být automaticky distribuována přímo z centrální konzole systému. Tj. vlastní správa a aktualizace Windows agenta se neprovádí z Group Policy. | Ano |
77 | Komunikace Windows agenta a centrálního systému musí být zabezpečena TLS 1.2 a výše a musí podporovat ověřování certifikátem. | Ano |
78 | Windows agent podporuje sběr nejen ze základních systémových logů (Aplikace, Zabezpečení, Instalace, Systém), ale je možné z centrální konzole v grafickém rozhraní nastavit i sběr všech ostatních logů ve složce Protokoly aplikací a služeb a logy rozšířené Sysmonem. Dále musí Windows agent podporovat centralizované nastavení z administrátorské konzole systému pro sběr textových logů včetně možnosti výběru jejich formátu. | Ano |
79 | Windows agent automaticky doplňuje ke všem odesílaným událostem jejich textový popis tak, jak je zobrazen v Prohlížeči událostí (Event Viewer) na koncovém systému. K bezpečnostním událostem hodným pozornosti doplňuje značku a popis dle MITRE ATT&CK® matrice a k takto detekovaným procesům a souborům automaticky vytváří SHA256 hash. | Ano |
80 | Počet instalací Windows agenta by neměl být licenčně a časově omezen, pokud je licenčně nebo časově omezen, tak požadujeme dodání licencí na Windows agenty v množství 100 na dobu předpokládané morální životnosti produktu – 7 let. Předpokládáme instalaci agentů na všechny systémy současně, proto je nutné potvrdit, zda systém výkonnostně splňuje tento požadavek. | Ano |
Podpora pro sběr událostí z poboček | ||
81 | Systém musí obsahovat centrálně spravované řešení, které sbírá události na pobočkách a umožní jejich odeslání po saturované lince bez ztráty dat. | Ano |
82 | Systém musí podporovat centralizovanou správu pro sběr událostí přímo z centrálního úložiště dat včetně dokumentace požadavků na virtualizaci a komunikační matici pro šifrovaný přenos dat. | Ano |
83 | Řešení musí být schopno automaticky navázat spojení s centrálním úložištěm dat a přenášená data šifrovat. V případě výpadku spojení mezi pobočkou a centrálou musí spojení automaticky obnovit. | Ano |
84 | Řešení musí komunikovat po definovaném TCP/UDP portu, aby mohl být snadno nastaven prostup přes firewally a řešena kvalita služby (QoS) pro přenos událostí. Doložte odkazem na dokumentaci, jak vypadá komunikační matice pro připojení řešení pro sběr událostí na pobočkách. | Ano |
85 | Řešení musí poskytovat kapacitu vyrovnávací paměti pro min. 100 GB událostí, které na pobočce mohou vzniknout během výpadku spojení mezi pobočkou a datovým centrem. | Ano |
86 | Řešení pro sběr dat z poboček musí mít výkon min. 5 tisíc událostí/s, a to i v trvalé zátěži. | Ano |
87 | Řešení musí poskytnout podporu pro sběr událostí na identických UDP i TCP portech jako hlavní dodaný systém. | Ano |
88 | Řešení musí být k dispozici jako fyzický systém nebo jako virtuální systém pro VMware ESXi a Hyper-V. | Ano |
89 | Řešení musí být schopno komunikovat z pobočky na centrálu i přes vícenásobný překlad adres (NAT). | Ano |
Vysoká dostupnost, SW Podpora a záruka na hardware | ||
90 | Možnost podpory pro nasazení ve vysoké dostupnosti. | Ano |
91 | HW - požadovaná 5 letá servisní podpora na hardware appliance s opravou v místě instalace serveru a s garantovanou odezvou následující pracovní den od nahlášení případné závady. | Ano |
92 | Systém musí podporovat vygenerování TSR (technického support reportu) pro možnost diagnostiky bez vzdáleného přístupu. | Ano |
93 | SW - podpora výrobce na aktualizaci systému a parserů na 5 let. Podpora musí obsahovat aktualizaci SW min. 3x ročně, opravy chyb a telefonickou a e-mailovou podporu s diagnostikou vzdáleným přístupem. | Ano |
Implementace | ||
94 | Nastavení systému a jeho konfigurace tak, aby mohl pracovat v prostředí zadavatele, včetně dodávky nezbytné kabeláže. | Ano |
95 | Instruktáž pro uživatele vzorové konfigurace stávajících systémů a zařízení zadavatele tak, aby posílaly logy do dodávaného systému: Cisco IOS, Fortinet, Microsoft server, Microsoft Exchange server, Microsoft SQL server | Ano |
96 | Instruktáž pro uživatele vzorové instalace Windows agenta na systémy požadované zadavatelem a jeho konfigurace – viz odstavec „Sběr událostí z Microsoft prostředí“ | Ano |
97 | Konfigurace systému pro komunikaci s nainstalovanými Windows agenty. | Ano |
98 | Vytvoření a uložení vlastního dashboardu a reportu, nastavení pravidelného odesílání reportu e-mailem vybraným zaměstnancům zadavatele – jeden vzorový dashboard. | Ano |
99 | Vytvoření vzorového alertu specifikovaného zadavatelem, odstavec SW parametry a odstavec Alerty (příklad: pošli alert jen v případě, že se událost stala na konkrétním vybraném Windows serveru, který běží v lokalitě XYZ). | Ano |
Veškeré vybavení a zařízení dodávané dodavatelem bude nové, nepoužité, nerepasované a bude určené pro použití v ČR.
Příloha č. 2 - Minimální seznam podporovaných zdrojů logů | |
Seznam podporovaných zdrojů logů | Splňuje |
Apache httpd | Ano |
Apache Tomcat | Ano |
ArcSight CEF (generický/standardizovaný formát) | Ano |
Brocade FC switches | Ano |
Cisco IOS | Ano |
Cisco IronPort | Ano |
Cisco Nexus | Ano |
Cisco SMB | Ano |
Cisco UCS | Ano |
Cisco WLC | Ano |
Dell iDrac (Server OoB management) | Ano |
Dropbear SSH (~součást Embedded Linux distribucí) | Ano |
FlowMon | Ano |
Fortigate | Ano |
FortiGate-Lite (optimalizované pro výkon) | Ano |
FortiManager | Ano |
FreeRADIUS | Ano |
HAProxy (structured rfc5425 logformat) | Ano |
HPE Aruba Clearpass | Ano |
HPE Aruba Instant AP (WLAN) | Ano |
HPE Aruba Mobility Controller (WLAN) | Ano |
HPE Comware WLAN | Ano |
HPE iLo (Server OoB management) | Ano |
HPE IMC | Ano |
HPE routers | Ano |
HPE switches Aruba OS | Ano |
HPE switches Aruba-CX OS | Ano |
HPE switches Comware OS | Ano |
JSON (generický/standardizovaný formát) | Ano |
Kerio Connect | Ano |
Kerio Control | Ano |
Linux Bash commands log | Ano |
Linux Cron | Ano |
Linux Freeradius | Ano |
Linux Iptables | Ano |
Linux Postfix | Ano |
Microsoft Azure (API) | Ano |
Microsoft Exchange | Ano |
Microsoft Exchange tracking textový log (2010-2019) | Ano |
Microsoft SharePoint | Ano |
Microsoft SQL | Ano |
Microsoft Windows Defender | Ano |
Microsoft Windows DHCP textový log | Ano |
Microsoft Windows DNS debug textový log | Ano |
Microsoft Windows Firewall (EVTx i textový log) | Ano |
Microsoft Windows IIS / FTP server textový log | Ano |
Microsoft Windows IIS / Webserver textový log | Ano |
Microsoft Windows logy z Event View (libovolný EVTx adresář) | Ano |
Microsoft Windows logy z libovolného textového souboru | Ano |
Microsoft Windows Sysmon | Ano |
Microsoft365 (API) | Ano |
Mikrotik | Ano |
MySQL | Ano |
Nginx | Ano |
Office365 | Ano |
OpenSSH server | Ano |
PostgreSQL | Ano |
RFC5425 (generický/standardizovaný formát) | Ano |
Synology NAS DSM | Ano |
VEEAM Backup and Restore | Ano |
Vmware vCenter a ESXi (od verze 7.0.2 přes API) | Ano |
Příloha č. 3 - Bezpečnostní požadavky
Účelem této přílohy je v souladu s ustanovením § 4 odst. 4 zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), v platném znění (dále jen „ZoKB“), ve spojení v přílohou č. 7 k vyhlášce č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti) (dále jen „Vyhláška“) stanovit závazné bezpečnostní opatření, která se vztahují na Dodavatele, jehož předmětem plnění pro Objednatele je (výhradně či jako součást předmětu plnění jiné služby) vývoj, implementace a/nebo servis software či hardware (dále také jen „SW“ či „HW“), a/nebo který v souvislosti s plněním pro Objednatele přistupuje do informačního systému Objednatele, který byl určen informačním systémem základní služby v souladu se zákonem č. 181/2014 Sb., (dále také „ISZS“), a/nebo který v rámci poskytovaného plnění pro Objednatele zpracovává, a/nebo přenáší a/nebo ukládá a/nebo archivuje data a provozní údaje Objednatele a/nebo jeho zákazníků (dále také jen „Bezpečnostní opatření“).
1. OBECNÉ POŽADAVKY
1.1 Poskytovatel se při poskytování plnění pro Objednatele zavazuje plnit následující povinnosti:
1.1.1 postupovat v souladu s platnými právními předpisy, zejména pak v souladu s požadavky vyplývajícími pro Objednatele, jakožto správce a provozovatele informačního sytému základní služby, ze ZoKB a Vyhlášky a reflektovat případné novely uvedených právních předpisů či novou právní úpravu;
1.1.2 nestanoví-li dohoda stran jinak, Poskytovatel jmenuje nejpozději do 3 dnů po uzavření Smlouvy zodpovědnou kontaktní osobu pro potřeby zajištění plnění Bezpečnostních opatření vyplývajících ze Smlouvy a související komunikace mezi Smluvními stranami (dále také jen „Kontaktní osoba“). Kontaktní osobu sdělí Poskytovatel Objednateli písemně v téže lhůtě. Případnou změnu Kontaktní osoby na straně Poskytovatele je Poskytovatel povinen Objednateli nahlásit do 5 dnů od provedení změny;
1.1.3 zajistit, aby Kontaktní osoba Poskytovatele nejpozději do 30 dnů od uzavření Smlouvy potvrdila písemně Objednateli, že všechny osoby podílející se na poskytování plnění této Smlouvy za stranu Poskytovatele a/nebo jeho podposkytovatelé byli prokazatelně seznámeni s těmito Bezpečnostními opatřeními;
1.1.4 pokud při plnění předmětu smlouvy Poskytovatel zpracovává osobní údaje pro Objednatele, zavazuje se Poskytovatel uzavřít s Objednatelem smlouvu o zpracování osobních údajů v souladu s nařízením Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů) a zákonem č. 110/2019 o zpracování osobních údajů;
1.1.5 předmět plnění nesmí být nevyhovující z hlediska informační bezpečnosti, přičemž za nevyhovující je považováno jakékoli plnění, které obsahuje technologie/klíčové prvky, vůči jejichž výrobcům příslušný správní orgán vydal opatření v souladu se ZoKB, a které dle analýzy rizik představují vysoké riziko;
1.1.6 dodržovat příslušná ustanovení bezpečnostních politik, metodik a postupů Objednatele, resp. platné řídící dokumentace Objednatele či její části, pokud byl Poskytovatel s takovými dokumenty nebo jejich částmi seznámen, a to bez ohledu na způsob, jakým byl s takovou dokumentací Objednatele seznámen (např. školením, protokolárním předáním příslušné dokumentace Zhotoviteli, elektronickým předáním prostřednictvím e-mailu, zřízením přístupu Zhotoviteli na sdílené úložiště aj.);
1.1.7 realizovat bezpečnostní opatření pro ochranu dat souvisejících s plněním předmětu Smlouvy;
1.1.8 zabezpečit veškerý přenos dat a informací z pohledu bezpečnostních požadavků na jejich důvěrnost, integritu a dostupnost během poskytování plnění pro Objednatele;
1.1.9 že plnění bude obsahovat jen ty součásti, které jsou objektivně potřebné pro řádné provozování SW a/nebo které jsou specifikovány výslovně ve smlouvě, zejména, že SW ani HW nebude obsahovat žádné nepotřebné komponenty apod.;
1.1.10 pokud součástí plnění je i instalace operačního systému případně SW třetích stran, v průběhu jeho instalace budou použity nejnovější aktualizované verze těchto produktů;
1.1.11 veškeré důvěrné informace1 poskytnuté Objednatelem při poskytování plnění nebudou uchovávány v nešifrovaném tvaru a budou chráněny vůči neautorizovanému přístupu, pokud nebude mezi smluvními stranami v konkrétním případě dohodnuto jinak;
2. POŽADAVKY NA SYSTÉMOVOU A PROVOZNÍ BEZPEČNOSTNÍ DOKUMENTACI
2.1 Nedílnou součástí poskytovaného plnění je zdokumentování všech bezpečnostních nastavení, funkcí a mechanismů formou zpracování bezpečnostní dokumentace. Poskytovatel se v rámci poskytovaného plnění pro Objednatele zavazuje předat Objednateli dokumentaci minimálně v následujícím rozsahu:
a. provozní a bezpečnostní dokumentace skutečného provedení,
b. popis autorizačního konceptu a oprávnění,
c. zálohovací a archivační postupy,
d. instalační a konfigurační postupy;
e. bezpečností nastavení.
3. FYZICKÁ OCHRANA A BEZPEČNOST PROSTŘEDÍ
3.1 Poskytovatel se zavazuje dodržovat provozní řády budov (režimová opatření) a využívaných prostor, zejména pak v oblasti fyzické ochrany bezpečnostních zón, kde jsou umístěny komponenty systémů ISZS anebo datové nosiče (dále také jen „Pracoviště“).
3.2 Poskytovatel se zavazuje, že na Pracovišti neponechá volně dostupná instalační, záložní nebo archivní média ani dokumentaci k systému ISZS, který je předmětem plnění dle této smlouvy.
4. ŘÍZENÍ PŘÍSTUPU
4.1 Poskytovatel bere na vědomí, že přístup k systému ISZS je možné povolit pouze fyzické identitě zaměstnance Poskytovatele (popřípadě Podposkytovatele) zaevidované v registru identit Objednatele, a to na základě požadavku Poskytovatele na přístup.
4.2 Poskytovatel bere na vědomí, že jeho zaměstnanec musí poskytnout své osobní údaje Objednateli, a to v rozsahu nutném pro zřízení přístupu, v opačném případě Objednatel není povinen přístup k systému ISZS zaměstnanci Poskytovatele povolit. Zaměstnanec Poskytovatele s přiděleným přístupem (fyzickým, logickým) k systému ISZS, bere na vědomí, že dochází ke zpracování osobních údajů během vyhodnocování údajů o pohybu a prováděných aktivitách v prostorách Objednatele (např.: monitoring pomocí řešení Security Information and Event Management).
4.3 Poskytovatel bere na vědomí, že přidělení oprávnění zaměstnanci Poskytovatele musí být řízeno principem nezbytného minima a není nárokové.
4.4 Poskytovatel se zavazuje, že udělený přístup nesmí být sdílen více zaměstnanci Poskytovatele nebo Podposkytovatele.
1 Za důvěrné informace se ve smyslu této přílohy považují zejména identifikační údaje certifikátu, hesla, přístupová oprávnění, konfigurační soubory, systémové programy, kritické knihovny, obnovovací procedury apod.
4.5 Poskytovatel se zavazuje, že vzdálený přístup do systému ISZS bude vždy uskutečněn pouze prostřednictvím zabezpečeného připojení definovaným Objednatelem.
4.6 Poskytovatel se zavazuje, že před připojením koncového zařízení, mobilní koncového zařízení nebo aktivního síťového prvku jako síťové switche, WiFi access pointy, routery či huby do počítačové sítě zažádá o schválení připojení kontaktní osobu na straně Objednatele.
4.7 Poskytovatel se zavazuje, že nebude instalovat a používat zejména typy nástrojů Keylogger, Sniffer, Analyzátor zranitelností a Port Scanner, Backdoor, rootkit a trojský kůň nebo jinou podobu malware.
4.8 Poskytovatel se zavazuje, že všechny jeho informační systémy, které se připojují do síťové infrastruktury Objednatele, jsou a budou chráněny proti malware.
4.9 Poskytovatel se zavazuje, že nebude vyvíjet, kompilovat a šířit v jakékoliv části systému ISZS programový kód, který má za cíl nelegální ovládnutí, narušení, nebo diskreditaci systému ISZS nebo nelegální získání dat a informací.
4.10 Poskytovatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Objednateli v ISZS:
a) neukládali, nesdíleli, data i informace eticky nevhodného obsahu, odporující dobrým mravům nebo poškozující jméno Objednatele;
b) nestahovali, nesdíleli, neukládali, nearchivovali a/nebo neinstalovali datové a spustitelné soubory v rozporu s licenčními podmínkami nebo autorským zákonem;
c) nezasílali řetězové emaily.
4.11 Poskytovatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Objednateli, kteří přistupují do interní sítě nebo ISZS Objednatele, měli v externím zařízení typu notebook/počítač aplikovány bezpečnostní záplaty a nainstalovanou, spuštěnou a aktualizovanou antivirovou ochranu;
4.12 Poskytovatel se zavazuje zajistit, aby osoby podílející se na poskytování plnění Objednateli, kteří přistupují do interní sítě a/nebo systému ISZS Objednatele chránili autentizační prostředky a údaje k systémům ISZS Objednatele. Poskytovatel bere na vědomí, že v případě neúspěšných pokusů o autentizaci uživatele může být příslušný účet zablokován a řešen jako kybernetická bezpečnostní událost ve smyslu příslušné řídící dokumentace a mohou být uplatněny příslušné postupy zvládání kybernetické bezpečnostní události (např. okamžité zrušení přístupu k informačním aktivům fyzických osob externího subjektu).
5. MONITOROVÁNÍ ČINNOSTÍ
5.1 Poskytovatel bere na vědomí, že veškerá jeho aktivita a jeho plnění realizované v systémovém prostředí Objednatele budou Objednatelem průběžně a pravidelně monitorovány a vyhodnocovány s ohledem na obsah smlouvy a interních dokumentů Objednatele, se kterými byl Poskytovatel seznámen.
6. PŘEDÁNÍ A PŘEVZETÍ PLNĚNÍ
6.1 Poskytovatel bere na vědomí, že nedodržení Bezpečnostních opatření Objednatele včetně požadavku na předání kompletní systémové a provozní dokumentace je vadou bránící převzetí předmětu Smlouvy, přičemž Objednatel není do doby odstranění příslušné vady plnění povinen plnění převzít.
6.2 Poskytovatel odpovídá za to, že systémy dodávané do ISZS budou obsahovat nejnovější bezpečnostní aktualizace (patche)2.
2 Aktualizace software na vyšší vývojovou verzi.
7. VÝMĚNA INFORMACÍ
7.1 Pokud je předmětem Smlouvy výměna informací mezi smluvními stranami, musí být mezi smluvními stranami uzavřena dohoda o ochraně předmětných informací, zejména při jejich výměně, uložení, archivaci a ukončení smlouvy.
7.2 Poskytovatel se zavazuje, že veškerý přenos dat a informací musí být dostatečně zabezpečen pomocí aktuálně odolných kryptografických algoritmů a kryptografických klíčů.
8. AUTORSTVÍ
8.1 Poskytovatel se při poskytování plnění pro Objednatele zavazuje zajistit, aby při plnění Smlouvy dodržel podmínky stanovené zákonem č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů.
8.2 Další požadavky mohou být stanovené ve Smlouvě.
9. OPRÁVNĚNÍ UŽÍVAT DATA
9.1 Poskytovatel je při poskytování plnění pro Objednatele oprávněn užívat data předaná Poskytovateli Objednatelem za účelem plnění předmětu Smlouvy, avšak vždy pouze v rozsahu nezbytném ke splnění předmětu Smlouvy.
9.2 Poskytovatel se při poskytování plnění pro Objednatele zavazuje nakládat s daty pouze v souladu se Smlouvou a příslušnými právními předpisy, zejména XxXX a Vyhláškou a dalšími souvisejícími právními předpisy.
10. ŘÍZENÍ ZMĚN
10.1 Objednatel v rámci řízení změn v ISZS přezkoumává možné dopady změn a určuje významné změny dle Vyhlášky.
10.2 Objednatel u významných změn dokumentuje jejich řízení, provádí analýzu rizik, přijímá opatření za účelem snížení všech nepříznivých dopadů spojených s významnými změnami, aktualizuje bezpečnostní politiku a bezpečnostní dokumentaci, zajistí testování ISZS a zajistí možnost navrácení do původního stavu.
10.3 Objednatel má povinnost informovat Poskytovatele o výsledcích řízení změn, které mají dopady na plnění předmětu Smlouvy ze strany Poskytovatele.
10.4 Poskytovatel má povinnost přijmout účinná opatření ke snížení nepříznivých dopadů v souladu s výsledky řízení změn uvedených v čl. 11.3.
10.5 Poskytovatel se zavazuje poskytnout Objednateli veškerou nezbytnou součinnost při analýze souvisejících rizik, přijímání opatření za účelem snížení všech nepříznivých dopadů spojených se změnami, aktualizaci bezpečnostní dokumentace, souvisejícím testováním a zajištění možnosti navrácení do původního stavu.
10.6 V případě realizace penetračního testování nebo testování zranitelnosti řešení poskytne Poskytovatel Objednateli veškerou potřebnou součinnost.
11. INFORMAČNÍ POVINNOST POSKYTOVATELE
11.1 Poskytovatel má povinnost bez zbytečného odkladu informovat Objednatele o významné změně ovládání Poskytovatele podle zákona č. 90/2012 Sb., o obchodních společnostech a družstvech (zákon o obchodních korporacích) nebo změně vlastnictví základních aktiv, jakož i změně v oprávnění Poskytovatele nakládat s aktivy, které jsou využívány k plnění předmětu Smlouvy.
11.2 Poskytovatel má povinnost informovat Objednatele o způsobu řízení rizik, jakož i o zbytkových rizicích souvisejících s plněním předmětu Smlouvy, a to na základě písemné výzvy Objednatele.
12. PODPOSKYTOVATELÉ
12.1 Poskytovatel nezapojí do poskytování plnění dle této Smlouvy žádného dalšího Podposkytovatele bez předchozího konkrétního nebo obecného povolení Objednatele.
12.2 Poskytovatel se zavazuje, že se bude řídit požadavky Objednatele na řízení bezpečnosti informací a poskytne Objednateli veškerou nezbytnou součinnost v otázkách řízení bezpečnosti informací a pokud využívá při poskytování plnění Podposkytovatele, zajistí, že bude Objednateli poskytnuta veškerá nezbytná součinnost v otázkách řízení bezpečnosti informací také od těchto Podposkytovatelů.
12.3 Poskytovatel je povinen předat Objednateli kontaktní údaje všech osob dodávajících systémovou a technickou podporu pro řešení.
12.4 Pokud Poskytovatel využívá za účelem plnění předmětu Smlouvy Podposkytovatele, musí být tomuto Podposkytovateli uloženy na základě smlouvy s Poskytovatelem stejné povinnosti k dodržování smluvních ujednání, jaká jsou sjednaná touto Přílohou mezi Objednatelem a Poskytovatelem.
12.5 Poskytovatel se zavazuje předložit Objednateli, na základě jeho písemného vyzvání, příslušnou smlouvu s Podposkytovatelem.
12.6 Poskytovatel má povinnost zajistit, že Podposkytovatel bude v souladu s požadavky, které Objednatel ukládá na základě této Přílohy Poskytovateli.
12.7 Poskytovatel odpovídá za to, že jeho Podposkytovatelé nebudou jednat v rozporu s bezpečnostními opatřeními vyplývajícími z této Přílohy; v případě, že dojde k nedodržení těchto požadavků ze strany Podposkytovatele Poskytovatele, považuje se každé takové nedodržení požadavků za porušení povinnosti Poskytovatele dle Xxxxxxx.
13. KONTROLA A AUDIT POSKYTOVATELE
13.1 Poskytovatel se zavazuje poskytnout Objednateli veškeré informace potřebné k doložení toho, že byly splněny povinnosti vyplývající z této Přílohy, jakož i ze ZoKB a Vyhlášky, a za tímto účelem se zavazuje umožnit Objednateli provedení kontrol, včetně auditů prováděných Objednatelem či auditorem, kterého Objednatel k auditu pověří, a poskytne k těmto kontrolám a auditům veškerou potřebnou součinnost.
13.2 Poskytovatel je povinen Objednateli zpřístupnit veškerou potřebnou dokumentaci pro účely kontroly či auditu, zejména výčet technických a organizačních opatření.
13.3 Poskytovatel má povinnost určit svého zástupce (případně své zástupce), který bude po dobu provádění kontroly či auditu přítomen.
13.4 Kontrola nebo audit mohou být provedeny v prostorách Poskytovatele nebo jeho Podposkytovatele a Poskytovatel má povinnost tyto kontroly nebo audity Objednateli či Objednateli pověřené osobě umožnit či možnost jejich provedení v prostorách podposkytovatele zajistit, přispět k nim a poskytnout Objednateli či Objednateli pověřené osobě k jejich provedení maximální možnou součinnost, kterou lze po Poskytovateli rozumně požadovat. Počet a frekvence kontrol ani auditů nejsou nijak omezeny.
13.5 Objednatel má povinnost písmeně oznámit Poskytovateli provedení kontroly či auditu, a to nejméně 14 dnů před provedením kontroly či auditu. Součástí oznámení bude i seznam osob, které jsou pověřeni ze strany Objednatele k provedení kontroly či auditu.
13.6 Výstupem v provedené kontroly či auditu může být auditní zpráva; s jejími výsledky bude Poskytovatel seznámen a může se k nim vyjádřit.
13.7 Poskytovatel je dále povinen umožnit provedení kontroly či auditu i ze strany dozorových orgánů.
13.8 Poskytovatel je povinen pravidelně provádět také vlastní hodnocení rizik a kontrolu zavedených bezpečnostních opatření. Tato kontrola probíhá v pravidelných intervalech stanovených Objednatelem, na žádost Objednatele nebo v případě vzniku kybernetického bezpečnostního incidentu v rámci poskytované služby nebo v případě, že se vznik bezpečnostního incidentu jeví jako pravděpodobný. O výsledku kontroly podá Poskytovatel Objednateli bez zbytečného odkladu písemnou kontrolní zprávu.
14. OCHRANA DŮVĚRNÝCH INFORMACÍ
14.1 Strany se zavazují zachovat mlčenlivost o veškerých informacích, osobních údajích, datech či zprávách, o nichž se dozvěděly v souvislosti s přípravou či plněním této Smlouvy (dále jen „důvěrné informace“), a to včetně předmětu Smlouvy, vlastní spolupráce a vnitřních záležitostí Stran.
14.2 Důvěrné informace ve smyslu této Smlouvy nepředstavují utajované informace klasifikované stupněm
„důvěrné“ ve smyslu zákona č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti, ve znění pozdějších předpisů.