Kupní smlouva
uzavřená podle ustanovení § 2079 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „smlouva“)
1. Smluvní strany
Kupující: Ostravská univerzita
Provozní jednotka: Centrum informačních technologií
sídlo: Xxxxxxxxx 0, 000 00 Xxxxxxx
zastoupená: doc. Mgr. Xxxxxx Xxxxxxxx, Ph.X., rektorem Ostravské univerzity
IČ: 61988987
DIČ: CZ61988987
bankovní spojení: ČNB Ostrava
č. účtu: 931761/0710
(dále jen „kupující“ nebo „OU“ nebo „zadavatel“)
Prodávající: CompuNet s. r. o.
sídlo: Xxxxxxxx 000/0, 000 00 Xxxxx 0
zapsaná v obchodním rejstříku Krajského soudu v Praze, oddíl C, vložka 118594 zastoupená: Ing. Xxxxxx Xxxxxxxxx, jednatelem
IČ: 27608514
DIČ: CZ27608514
bankovní spojení: Komerční banka a. s.
č. účtu: 51-1998450287/0100
(dále jen „prodávající“)
2. Základní ustanovení
2.1. Tato smlouva je uzavřena na základě zadávacího řízení na veřejnou zakázku „Generační obměna Logmanager vč. servisní podpory na 5 let“ v rámci projektu Národního plánu obnovy pro oblast vysokých škol pro roky 2022-2024 s názvem FlexibilitOU k rozvoji profesních dovedností s reg. č. NPO_OSU_MSMT-16610/2022 (dále jen „projekt“).
2.2. Smluvní strany prohlašují, že údaje v článku 1. této smlouvy a taktéž oprávnění k podnikání jsou v souladu s právní skutečností v době uzavření smlouvy. Smluvní strany se zavazují, že změny dotčených údajů oznámí bez prodlení druhé straně.
3. Předmět koupě
3.1. Předmětem koupě dle této smlouvy je rozšíření stávajícího nástroje Logmanager (Model LOGM- 48TB-D-G3 sériové číslo 55DDG13) na zaznamenávání, analýzu a řešení provozních a bezpečnostních událostí ze systémů a aplikací v prostředí Ostravské univerzity, specifikovaného v Příloze č. 1, která je nedílnou součástí této smlouvy (dále jen „zboží“), jakož i záruční a mimozáruční servisní podpora uvedená v této příloze v délce trvání 5 let (dále jen „servisní podpora“).
3.2. Prodávající se zavazuje předat kupujícímu zboží uvedené v čl. 3.1. této Smlouvy a blíže specifikované v Příloze č. 1 této smlouvy a umožnit kupujícímu nabýt ke zboží vlastnické právo. Kupující se zavazuje zboží převzít a zaplatit prodávajícímu kupní cenu poté, kdy dojde k
implementaci zboží do stávající infrastruktury (dále jen „implementace“). Řádně provedenou implementaci si smluvní strany potvrdí akceptačním protokolem viz níže.
3.3. Jakost, provedení, vlastnosti a další specifikace zboží včetně jeho množství jsou uvedeny v Příloze č. 1 této smlouvy.
3.4. Předání zahrnuje rovněž dopravu na místo plnění spolu s předáním následující dokumentace: uživatelská dokumentace - návod k použití a údržbě (elektronická podoba), technická dokumentace, doklady k servisní podpoře po dobu 5 let (zejména k zapojení do stávající infrastruktury – vč. schémat či nákresů, k nastavení, k bezpečnostním zásahům atd.), dokumenty vyžadované obecně závaznými právními předpisy a českými a evropskými normami ČSN a EN, a dále dokument dokládající, že zboží je určeno pro český trh, jakož i veškeré další dokumenty, které vyplývají ze specifikace uvedené v Příloze č. 1 této Smlouvy. Požadované doklady a dokumenty musí být předloženy v českém jazyce (dále vše jen jako „dokumentace“).
3.5. Prodávající prohlašuje, že:
3.5.1. je výlučným vlastníkem zboží, které kupujícímu předá,
3.5.2. zboží je nové (tzn. nepoužité, ani repasované), určené pro český trh
3.5.3. zboží má vlastnosti, které si smluvní strany ujednaly a není-li takového ujednání, takové vlastnosti, které prodávající nebo výrobce popsal nebo které kupující mohl očekávat s ohledem na povahu zboží,
3.5.4. zboží se hodí k účelu, který vyplývá zejm. z této smlouvy,
3.5.5. zboží vyhovuje požadavkům právních předpisů,
3.5.6. kupující je oprávněn užívat software dodávaný spolu se zbožím, a to v rozsahu a
způsobem, který odpovídá účelu pořízení a jeho povaze,
3.5.7. zboží je bez jakýchkoli vad, a to i právních.
3.6. Prodávající je při realizaci předmětu plnění smlouvy povinen dodržet platné technické normy a ekologické požadavky, minimalizovat množství obalového materiálu a použít obaly šetrné k životnímu prostředí, tedy budou recyklované nebo recyklovatelné.
4. Lhůta, místo a způsob plnění
4.1. Prodávající je povinen předat předmět koupě do 2 měsíců ode dne nabytí účinnosti této smlouvy. Prodávající oznámí kupujícímu termín dodání v pracovní dny v době 9:00 až 15:00 hodin, min. 5 dnů předem, a to písemně.
4.2. Místem předání zboží je Centrum informačních technologií Ostravské univerzity, Bráfova 5, 701 03 Ostrava (dále také „místo plnění“ a „místo dodání“).
4.3. Osobou oprávněnou za prodávajícího je Xxxxxxxxx Xxxxxxxx, e-mail: xxxxxxxx@xxxxxxxx.xx, tel: 000 000 000
4.4. Osobou oprávněnou k převzetí zboží je Xxxx Xxxxxx, e-mail: xxxx.xxxxxx@xxx.xx, tel. 000 000 000.
4.5. Předání zboží bude potvrzeno podpisem oprávněných osob prodávajícího a kupujícího na akceptačním protokolu po ukončení akceptačního testování dle čl. 5 této smlouvy s hodnocením
„akceptováno“ s uvedením data předání zboží. Pouze zboží, které projde akceptačním testováním
s hodnocením „akceptováno“, lze považovat za řádně předané.
5. Akceptační testování
5.1. Prodávající v návaznosti na předání zboží kupujícímu zahájí na základě výzvy kupujícího akceptační testování zboží.
5.2. Akceptační testování zboží bude provádět prodávající za účasti zaměstnanců kupujícího, kteří mu poskytnou potřebnou součinnost.
5.3. Akceptační testování zboží se skládá z provedení následujících aktivit prodávajícím:
a) základní nastavení zboží (HW komponent a SW k jejich řízení a správě) a jeho konfigurace tak, aby mohlo pracovat v prostředí kupujícího,
b) ověření funkčních a výkonových parametrů zboží dle požadovaných hodnot uvedených v Příloze č. 1 této Smlouvy.
5.4. Akceptační testování zboží bude ukončeno vyhotovením akceptačního protokolu.
5.5. V případě, že testované zboží (HW komponenty nebo SW k jejich řízení a správě) neprojde úspěšným otestováním, tzn. že dodané zboží nebude prokazatelně splňovat parametry požadované v Příloze č. 1 této Smlouvy, bude výsledkem akceptačního testování zboží hodnocení
„neakceptováno“ a tento výsledek bude uveden v akceptačním protokolu. V takovém případě může kupující vyzvat prodávajícího ke zjednání nápravy dodáním a instalací takového zboží (HW komponent a/nebo SW k jejich řízení a správě), jehož parametry budou v souladu s parametry požadovanými Příloze č. 1 této Smlouvy a akceptační testování zboží proběhne znovu v souladu s článkem 5.2., 5.3. a 5.4. této Smlouvy. V případě, že výsledkem akceptačního testování bude hodnocení „neakceptováno“, zboží není považováno za řádně a včas předané.
5.6. V případě, že testované zboží (HW komponenty a SW k jejich řízení a správě) projde úspěšným otestováním, resp. znovuotestováním dle čl. 5.5., tzn. že dodané zboží bude prokazatelně splňovat parametry požadované v Příloze č. 1 této Smlouvy, bude výsledkem akceptačního testování zboží hodnocení „akceptováno“ a tento výsledek bude uveden v akceptačním protokolu. Uvedeným se dodané zboží považuje za akceptované (předané).
6. Cena a platební podmínky
6.1. Celková kupní cena za předmět koupě dle čl. 3 této Smlouvy byla dle výsledku zadávacího řízení stanovena ve výši:
v Kč bez DPH | DPH v Kč | v Kč včetně DPH |
2 799 000,- | 587 790,- | 3 386 790,- |
6.2. Rozpis kupní ceny je součástí Přílohy č. 2 – Položkový rozpočet této smlouvy.
6.3. Sjednaná kupní cena je konečná a není možné ji překročit. Prodávající prohlašuje, že kupní cena obsahuje jeho veškeré nutné náklady spojené s řádným a včasným splněním závazků dle této smlouvy, zejm. s řádným předáním zboží kupujícímu a souvisejícím plněním dle čl. 3.2. a 3.4. této smlouvy.
6.4. Sjednané jednotkové ceny je možné změnit, pouze pokud v průběhu platnosti této smlouvy dojde ke změnám sazeb DPH podle zákona č. 235/2004 Sb., o dani z přidané hodnoty.
6.5. Platba bude uskutečněna na základě daňového dokladu vystaveného prodávajícím po převzetí veškerého zboží kupujícím a implementaci dle bodu 3.2. této Smlouvy, se splatností do 30 dnů ode dne doručení daňového dokladu kupujícímu. Daňový doklad (faktura) bude obsahovat náležitosti daňového a účetního dokladu podle zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů a zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a dále údaj, že zboží bude hrazeno z projektu Národního plánu obnovy pro oblast vysokých škol pro roky 2022-2024 s názvem „FlexibilitOU k rozvoji profesních dovedností“ s reg. č. NPO_OSU_MSMT-16610/2022. Daňový doklad nesplňující předepsané náležitosti bude kupujícím vrácen do dne splatnosti daňového dokladu k opravě, s tím že lhůta splatnosti počíná běžet znovu ode dne doručení opraveného či nově vystaveného daňového dokladu.
6.6. Prodávající se zavazuje ve výčtu položek na faktuře uvést název položek zboží, jak je uvedeno v
Příloze č. 1 této smlouvy. K faktuře bude přiložena kopie akceptačního protokolu.
6.7. Prodávající je povinen zasílat faktury elektronickými prostředky na adresu
6.8. Povinnost kupujícího uhradit fakturu je splněna dnem odepsání příslušné částky z účtu kupujícího.
6.9. Prodávající přebírá nebezpečí změny okolností ve smyslu § 1765 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“).
6.10. Kupující neposkytne prodávajícímu žádnou zálohu.
7. Smluvní pokuty
7.1. V případě prodlení prodávajícího s předáním zboží nebo jeho části kupujícímu oproti lhůtě stanovené v čl. 4.1., je kupující oprávněn požadovat na prodávajícím smluvní pokutu ve výši 0,1 % z celkové kupní ceny nedodaného zboží (včetně DPH) za každý i započatý den prodlení, min. však 500,- Kč za každý den prodlení. Tato smluvní pokuta bude uplatněna rovněž v případě prodlení s odstraněním vad, se kterými kupující zboží převzal ve smyslu bodu 4.7.
7.2. V případě prodlení prodávajícího s plněním povinností v rámci servisní podpory v čl. 8 této Smlouvy a pro servisní podporu v Příloze č.1 je Kupující oprávněn požadovat na Prodávajícím smluvní pokutu ve výši 500 Kč za každý i započatý den prodlení.
7.3. V případě prodlení kupujícího s úhradou faktury proti sjednanému termínu je prodávající oprávněn požadovat na kupujícím smluvní pokutu ve výši 0,1 % z dlužné částky za každý i započatý den prodlení.
7.4. Uplatněním nároku na smluvní pokutu není dotčeno oprávnění kupujícího požadovat náhradu škody způsobenou porušením povinnosti ze strany prodávajícího, které je zajištěno smluvní pokutou.
7.5. Smluvní pokuty jsou splatné na výzvu.
8. Nebezpečí škody na zboží a přechod vlastnictví
8.1. Nebezpečí škody na zboží a vlastnické právo ke zboží přechází na kupujícího v okamžiku podpisu
akceptačního protokolu s výsledkem „akceptováno“.
9. Záruční doba a reklamační podmínky
9.1. Prodávající poskytuje plnou záruku (bez jakékoliv finanční spoluúčasti kupujícího) na veškeré věcné (materiálové či výrobní) a právní vady pro dodané zboží v délce 60 měsíců.
9.2. Záruční doba počíná běžet dnem podpisu akceptačního protokolu.
9.3. Vady, na něž se vztahuje záruka dle tohoto článku, je kupující povinen uplatnit nejpozději do konce záruční doby. Veškeré vady, závady a poruchy, které budou nárokovány ze záruky, bude odstraňovat prodávající, nebo osoba prodávajícím písemně pověřená.
9.4. Prodávající garantuje, že v záruční době budou odstraněny veškeré záruční vady do 14 kalendářních dnů od data jejich prokazatelného nahlášení kupujícím, pokud se smluvní strany nedohodnou jinak.
9.5. Lhůta uvedená pro odstranění vady se počítá poté, kdy prodávající obdrží písemné nahlášení vady. Za písemné nahlášení se považuje datová nebo e-mailová zpráva.
9.6. Pokud má zboží vadu, jejíž odstranění by bylo vzhledem k povaze vady neúměrné, nebo vadu, která brání řádnému užívání, bude provedena výměna zboží. Týká-li se vada jen součásti zboží, bude provedena výměna součásti zboží. Výměna zboží bude provedena ve lhůtě 14 kalendářních dnů od data jejich prokazatelného nahlášení kupujícím, pokud se smluvní strany nedohodnou jinak.
9.7. Výměnou vadného zboží není dotčeno právo kupujícího na náhradu škody způsobené vadným zbožím včetně nákladů kupujícího spojených s výměnou vadného zboží.
9.8. V ostatním budou záruční vady odstraňovány za podmínek servisní podpory.
10. Servisní podpora
10.1. Ke zboží poskytne prodávající servisní podporu v délce trvání 5 let, jejíž podmínky jsou upraveny v Příloze č. 1 této Smlouvy. V rámci této podpory zajistí prodávající nezbytnou údržbu a aktualizace zboží, včetně odstraňování závad a incidentů.
10.2. Prodávající je povinen informovat kupujícího neprodleně o změně kontaktních údajů pro nahlášení vad a havárií, a to písemnou formou.
11. Licenční ujednání
11.1. Prodávající poskytuje kupujícímu nevýhradní oprávnění k výkonu práva užít (licenci) programové vybavení, a to v časově neomezeném rozsahu, v územním rozsahu pro Českou republiku a v ostatním rozsahu tak, jak je nezbytné k řádnému užívání programového vybavení nebo souvisejících HW komponent.
11.2. Prodávající prohlašuje, že je oprávněn poskytnout kupujícímu oprávnění k výkonu práva programové vybavení užít, a to v rozsahu a způsoby podle ustanovení této smlouvy. Další licenční ujednání upravuje Příloha č. 1 této Smlouvy.
12. Ostatní ujednání
12.1. V případě rozporu mezi touto Smlouvou a Přílohou č. 1má přednost znění Přílohy č. 1.
12.2. Kupující je povinným subjektem dle zákona č. 340/2015 Sb., o registru smluv (dále jen “zákon o registru smluv“). Prodávající bere na vědomí a výslovně souhlasí s tím, že tato Smlouva včetně všech jejích změn a dodatků podléhá uveřejnění v Registru smluv (informační systém veřejné správy, jehož správcem je Ministerstvo vnitra). Kupující se zavazuje, že provede uveřejnění této Smlouvy dle příslušného zákona o registru smluv.
12.3. V případě podstatného porušení smlouvy je kupující oprávněn odstoupit od smlouvy pouze částečně.
12.4. Kupující zveřejní Smlouvu včetně všech jejich změn a dodatků v plném znění. V případě, že Smlouva nebo dodatek obsahuje utajované informace, obchodní tajemství dle § 504 obč. zákoníku, osobní/citlivé údaje, práva duševního vlastnictví či jiné informace, které nelze poskytnout při postupu podle předpisů upravujících svobodný přístup k informacím (dále jen „chráněné informace“), je Prodávající povinen nejpozději v den uzavření Smlouvy tuto skutečnost sdělit Kupujícímu, tyto informace přesně identifikovat a kvalifikovat právní důvod jejich ochrany. Tyto části Smlouvy (chráněné informace) pak Kupujícím nebudou uveřejněny. V opačném případě je Prodávající seznámen se skutečností, že zveřejnění Smlouvy v plném znění dle citovaných zákonů se nepovažuje za porušení obchodního tajemství a že Xxxxxxx neobsahuje ani jiné chráněné informace a Prodávající s jejím zveřejněním výslovně souhlasí.
12.5. Tato smlouva nabývá platnosti dnem jejího uzavření a účinnosti dnem uveřejnění smlouvy v
Registru smluv.
12.6. Prodávající je dle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě, v platném znění, osobou povinnou spolupůsobit při výkonu finanční kontroly.
12.7. Prodávající je povinen umožnit všem subjektům oprávněným k výkonu kontroly z projektu, z jehož prostředků je dodávka hrazena, provést kontrolu veškeré dokumentace vč. účetních dokladů souvisejících s plněním zakázky, a to po dobu minimálně do 31.12.2035. Pokud je v českých právních předpisech stanovena lhůta delší, musí ji Prodávající použit. Tyto doklady budou uchovávány způsobem stanoveným platnými právními předpisy. Subjekty oprávněné k výkonu kontroly mají právo přístupu i k těm částem nabídek, smluv a souvisejících dokumentů, které podléhají ochraně podle zvláštních právních předpisů (např. jako obchodní tajemství, utajované skutečnosti) za předpokladu, že budou splněny požadavky kladené právními předpisy (např.
zákonem č. 255/2012 Sb., o kontrole (kontrolní řád), v platném znění). Oprávnění kontroly dle předchozí věty se vztahuje i na případné subdodavatele Prodávajícího.
12.8. Ve věcech touto smlouvou výslovně neupravených se bude tento smluvní vztah řídit ustanoveními obecně závazných právních předpisů, zejména občanským zákoníkem a předpisy souvisejícími.
12.9. Smlouva je vyhotovena ve dvou stejnopisech s platností originálu a každá ze smluvních stran obdrží po jejich podpisu jedno vyhotovení, pokud je smlouva uzavřena v listinné podobě.
12.10. Tato smlouva může být měněna nebo doplňována pouze písemnými číslovanými dodatky podepsanými oprávněnými zástupci obou smluvních stran; to neplatí pro čl. 4.3 a čl. 4.4, ve kterých lze jednostranně měnit nebo doplňovat kontaktní osoby, a to na základě písemného oznámení příslušné smluvní strany doručeného druhé smluvní straně na adresu sídla nebo datovou schránkou.
12.11. Kupující je vůči Prodávajícímu oprávněn odstoupit od Smlouvy, nebo jakékoliv její části, pokud Kupující jakýmkoli způsobem pozbude svého práva vynakládat finanční prostředky na úhradu ceny za předmět plnění, nebo toto právo bude jakkoliv omezeno, či zkráceno. Zejména půjde o případy, kdy poskytovatel příspěvku (např. MŠMT) buďto příslušný příspěvek vůči Kupujícímu neposkytne vůbec, nebo ho jakkoliv sníží (zkrátí), nebo prohlásí příspěvek, či jeho část za neuznatelný (nebo nezpůsobilý) k hrazení ceny za předmět plnění. Jestliže nastane kterýkoli z uvedených případů, právo Prodávajícího na náhradu případné škody, nebo újmy je zcela a od počátku vyloučeno. Tímto není dotčeno právo Prodávajícího na vypořádání v souladu s příslušnými právními předpisy.
12.12. Prodávající se zavazuje, že na fakturu uvede vždy takové bankovní spojení, které bude do tuzemské banky, a které bude mít v době vystavení a splatnosti faktury zveřejněno správcem daně způsobem umožňujícím dálkový přístup, tak, jak to vyžaduje zákon o DPH, aby se Kupující nedostal do pozice ručitele za odvod DPH za Prodávajícího z důvody platby na nezveřejněný či na zahraniční bankovní účet.
12.13. Pokud se Prodávající do data splatnosti faktury stane tzv. nespolehlivým plátcem DPH ve smyslu ustanoven § 106a zákona o DPH a Kupující se tak dostane do pozice, kdy dle zákona o DPH ručí za odvod DPH ze strany Prodávajícího, je Prodávající povinen o této skutečnosti Kupujícího bezodkladně informovat.
12.14. Pokud se Kupující dostane do pozice, kdy ze zákona ručí za odvod DPH za Prodávajícího (např. z důvodů popsaných v bodě 12.12. nebo 12.13. tohoto článku), je Kupující oprávněn uhradit Prodávajícímu hodnotu faktury pouze ve výši bez DPH a DPH odvést na účet místně příslušného správce daně Prodávajícího a Prodávající s tímto postupem souhlasí. Dále v případě, že nastanou skutečnosti uvedené v bodě 12.12. tohoto článku, má Kupující také právo pozastavit platbu celé částky závazku, a to do doby, než mu Prodávající sdělí číslo takového bankovního účtu, který je veden v české bance a je zveřejněn správcem daně. Závazek se tím v obou případech považuje za splněný řádně a včas a Kupující se nedostává do prodlení s úhradou.
12.15. Kupující si dále vyhrazuje právo uplatnit institut zvláštního způsobu zajištění daně z přidané hodnoty podle § 109a zákona o DPH. V případě, že nastanou okolnosti umožňující Kupujícímu (příjemci zdanitelného plnění) uplatnit zvláštní způsob zajištění daně podle § 109a zákona o DPH, bude Kupující (příjemce zdanitelného plnění) o této skutečnosti Prodávajícího (poskytovatele zdanitelného plnění) informovat. Při použití zvláštního způsobu zajištění daně bude příslušná výše DPH zaplacena na osobní depozitní účet Prodávajícího (poskytovatele zdanitelného plnění) vedený u jeho místně příslušného správce daně, a to v původním termínu splatnosti. V případě, že Kupující (příjemce zdanitelného plnění) institut zvláštního způsobu zajištění daně z přidané hodnoty ve shodě s tímto ujednáním uplatní, bude tato úhrada považována za splnění části závazku Kupujícího (příjemce) odpovídajícího příslušné výši DPH sjednané jako součást sjednané ceny za zdanitelné plnění. Závazek Kupujícího zaplatit sjednanou smluvní cenu včetně DPH
(základ daně na účet určený dodavatelem a příslušnou DPH na depozitní účet vedeny u místně příslušného správce daně dodavatele, v rámci zajištění daně) se tímto považuje za splněný řádně a včas a Kupující se nedostává do prodlení s úhradou. Použití institutu zajištění daně je na rozhodnutí Kupujícího (příjemce zdanitelného plnění), který musí před realizací úhrady závazku z titulu poskytnutého plnění vyhodnotit případná rizika ručení za daň nezaplacenou dodavatelem. Kupující nepotřebuje k uplatnění institutu zvláštního zajištění daně souhlas Prodávajícího.
12.16. Ustanovení 12.12. až 12.15. se týkají prodávajícího, kterému je přiděleno české DIČ.
12.17. Prodávající se zavazuje zajistit v rámci plnění této Smlouvy legální zaměstnávání osob a zajistí pracovníkům podílejícím se na plnění Smlouvy férové a důstojné pracovní podmínky. Férovými a důstojnými pracovními podmínkami se rozumí takové pracovní podmínky, které splňují alespoň minimální standardy stanovené pracovněprávními a mzdovými předpisy. Prodávající je povinen zajistit splnění požadavků tohoto ustanovení Smlouvy i u svých poddodavatelů. Nesplnění povinností Prodávajícího dle tohoto ujednání Xxxxxxx se považuje za podstatné porušení Xxxxxxx s možností odstoupení objednatele od této Smlouvy. Odstoupení od této Smlouvy je v takovém případě účinné doručením písemného oznámení o odstoupení od Smlouvy druhé smluvní straně.
12.18. Prodávající je povinen Kupujícímu uhradit veškerou škodu, která mu vznikne nedodržením povinností uvedených výše v tomto článku, a navíc je Kupující oprávněn odstoupit od této Smlouvy. Odstoupení se stává účinným dnem jeho doručení Prodávajícímu.
12.19. Smluvní strany po přečtení smlouvy potvrzují, že obsahu smlouvy porozuměly, že smlouva vyjadřuje jejich pravou, svobodnou a vážnou vůli, nebyla uzavřena v tísni či za nápadně nevýhodných podmínek a na důkaz této skutečnosti ji podepisují.
12.20. Nedílnou součástí smlouvy jsou níže uvedené přílohy. Přílohy:
Příloha č. 1 – Technická specifikace předmětu plnění Příloha č. 2 – Položkový rozpočet
Za kupujícího dne ……….…. doc. Mgr. Digitálně podepsal xxx. Xxx. Xxxx Xxxx Xxxxxxx, Xxxxxxx, Ph.D. Ph.D. Datum: 2024.07.01 09:03:34 +02'00' | Za prodávajícího dne …………….. Ing. Xxxxx Digitally signed by Xxx. Xxxxx Xxxxxxx Xxxxxxx Date: 2024.06.14 13:57:00 +02'00' | |
xxx. Xxx. Xxxx Xxxxxxx, Ph.D. rektor Ostravské univerzity | Xxx. Xxxxx Xxxxxxx, jednatel Compunet s. r. o. |
Příloha č. 1 – Technická specifikace předmětu plnění
Technická specifikace předmětu plnění
Generační obměna Logmanager vč. servisní podpory na 5 let
Předmětem zakázky je návrh, dodávka, implementace a následná podpora rozšíření stávajícího nástroje Logmanager na zaznamenávání provozních a bezpečnostních událostí v prostředí zadavatele. Tento nástroj aktuálně slouží pro sběr a analýzu logů s možností následné analýzy a řešení bezpečnostních událostí/incidentů ze systémů a aplikací zadavatele určeným hodnocením aktiv a bezpečnostních potřeb organizace. Požadujeme zapojení systému do vysoké dostupnosti a navýšení výkonu. Navržené rozšíření nástroje musí umožnit zapojení do clusteru se stávajícím systémem, synchronizaci jeho konfigurace i dříve pořízených dat v rámci databáze.
Od rozšíření nástroje očekáváme naplnění požadavků vyplývajících zejména z připravované vyhlášky
o bezpečnostních opatřeních poskytovatele regulované služby v režimu vyšší povinnosti (NIS2).
Nástroj po rozšíření proto musí být schopen zaznamenat všechny bezpečnostní a relevantní provozní události a tyto uchovat nejméně po dobu 18 měsíců. Nástroj musí být dále schopen zajistit vysokou dostupnost dat, přesné časové razítko ke všem pořízeným událostem a umožnit zachování důvěrnosti a integrity pořízených dat po celou dobu jejich životního cyklu. Pro efektivní využití musí i rozšířený nástroj umět generovat reporty o aktivitách systémů i uživatelů, včetně auditních reportů na vyžádání, nebo se stanovenou periodicitou s definovatelným obsahem.
Cílem je mít jednotné a plně resilientní úložiště logů s pokročilými nástroji analýzy a upozorňování, ke kterému budou mít přístup pouze autorizovaní pracovníci zadavatele. Nezbytnou nutností je vyloučit možnost modifikace logů ze strany administrátorů nebo uživatelů. Nástroj i po rozšíření musí dále umožňovat snadnou klasifikaci dat, tvorbu uživatelsky definovaných parserů, filtrů, upozornění a korelací bez účasti výrobce nebo dodavatele ve snadno pochopitelném grafickém rozhraní bez nutnosti používat znalostí programátora. Dokumentace musí poskytnout jednoznačný návod, jak takovéto činnosti provádět, a to včetně široké škály vzorových příkladů.
Zálohování konfigurace i dat a jejich obnova je nezbytnou nutností, kterou musí dodaný systém podporovat i v rámci clusteru. Dodaný nástroj proto musí podporovat možnost i dalšího horizontálního i vertikálního rozšíření formou clusteru N+1 a zálohování vzniklých dat na externí zálohovací systém. Zálohováním dat na externí systém musí umožnit dosáhnout požadavku na délku uložení logovaných událostí po dobu minimálně 18 měsíců. Platí však, že požadujeme, aby systém umožňoval on-line zobrazit hodnoty nad všemi interně uloženými daty za libovolné časové období bez nutnosti nejprve modifikovat konfiguraci systému nebo parametry uložených dat.
Součástí dodávky musí být úplná a podrobná dokumentace systému v češtině. Proto v rámci podání nabídky požadujeme předložit kompletní dokumentaci k celému systému a poznámky k vydání (release notes) k systému i všem návazným komponentům. Není přípustné předložit českou dokumentaci, která bude odkazovat do dokumentace, která bude v jiném jazyce, než je čeština. Stávající nástroj provozujeme vlastními lidskými zdroji, proto by nabízený systém měl i nadále umožňovat našim pracovníkům IT provádět základní i středně pokročilé konfigurace bez nutnosti konzultovat dodavatele nebo výrobce. Nabízený nástroj proto musí splňovat existující parametry uživatelské přívětivosti a integrity uživatelského rozhraní a vyhnout se nutnosti používaní skriptů, maker, konfigurací v příkazové řádce nebo terminálu. Dále by dokumentace měla poskytnout jednoznačné návody, jak konfigurovat nejčastější zdrojová zařízení pro spolupráci s nabízeným systémem.
Pokud jsou v nabízeném řešení zahrnuty jakékoliv licence, jejich legální používání nesmí být časově omezeno. Nabízené řešení tedy musí být plně funkční i po uplynutí doby placené podpory.
• Technická specifikace
Zadavatel vyžaduje, aby nabízené řešení mělo níže požadované funkce již v době podání nabídky, nikoliv aby se jednalo o budoucí funkce plánovaných verzí software pro nabízené řešení.
Řešení SEM/SIEM do 10000 událostí/s s minimálně 120 TB velikostí databáze | ||
Potvrďte, že nabízené řešení splňuje uvedené parametry. Požadované dokumenty přiložte k nabídce. Požadované URL odkazy doplňte do technické specifikace. | ||
1. Obecné požadavky na systém pro centralizovanou správu logů, událostí a strojových dat | ||
1.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ů. Doložte katalogový list produktu (datasheet) podrobně popisující hardwarové i softwarové parametry nabízeného systému. | Datasheet naleznete zde: xxxxx://xxxxxxx xxx.xxx/xx/xxx pora#document s-for-download |
1.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. | ANO, splňuje |
1.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, splňuje |
1.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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/parser /parsers/ |
Požadujeme předložit příslušnou dokumentaci k vytváření parserů a testování jejich funkčnosti. | ||
Systém umožňuje v grafickém rozhraní vizuálního programovacího jazyka snadné 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ě. | Dokumentace zde: xxxxx://xxx.xxx | |
1.5 | Požadujeme předložit příslušný odkaz na dokumentaci popisující funkčnost třídění vstupních dat. | xxxxxxx.xxx/x atest/cz/web- interface/parser |
/classifiers/ |
1.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 požadujeme podporu 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. Předložte detailní komunikační matrici nabízeného systému a dokumentaci k nastavení sběru z databází v grafickém rozhraní systému. | Komunikace Logmanageru zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/additio nal- informations/co mmunication- of-logmanager/ |
1.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, splňuje |
1.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, splňuje |
1.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, splňuje |
1.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, splňuje |
1.11 | Možnost sběru událostí minimálně ve formátech RAW, Syslog RFC5424, CEF, LEEF, JSON RFC8259. | ANO, splňuje |
1.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, splňuje |
1.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í. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/web- interface/logs/r eports/ |
1.14 | Systém provádí konsolidaci logů na interním storage logovacího systému. | ANO, splňuje |
1.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 odkaz na dokumentaci nebo pdf popisující způsob vytváření reportů. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/web- |
interface/logs/r eports/ | ||
1.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, splňuje |
1.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, splňuje |
1.18 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/netwo rk/dns/ |
1.19 | 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 odkaz na dokumentaci popisující nastavení systému v jednotném grafickém rozhraní tak, aby získával logy z Office365/Mircosoft365. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/sourc es/ |
1.20 | V případě krátkodobého (do 10 minut) až dvojná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, splňuje |
1.21 | 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, splňuje |
1.22 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/logs/d ashboards/ |
1.23 | 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, splňuje |
1.24 | 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, splňuje |
1.25 | 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, splňuje |
1.26 | 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 odkaz na online dokumentaci nebo připojit pdf aktuální kompletní dokumentace k ověření jednotlivých vlastností navrhovaného systému. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/ |
1.27 | Systém umožňuje kapacitní i výkonovou škálovatelnost. | ANO, splňuje |
1.28 | Č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ě 100TB dat. | ANO, splňuje |
1.29 | Požadujeme, aby ze systému bylo možné za běhu vytáhnout libovolné dva disky, bez ztráty dat a vlivu na funkčnost řešení. Redundance disků nesmí ovlivňovat požadovanou kapacitu úložiště. | ANO, splňuje |
1.30 | Pokročilá telemetrie a monitoring stavu systému. Systém musí umět zobrazovat kromě běžných telemetrických dat o svojí činnosti i data ohledně rychlosti indexování, délce fronty dat čekající na zpracování a rychlosti odezvy DNS serverů vyřizujících DNS PTR odpovědi. Dále musí umožňovat alertování při překročení prahových hodnot nebo chybě systému, s odesláním upozornění pomocí SMTP nebo Syslogu. | ANO, splňuje |
1.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í. Požadujeme předložit dokumentaci, ze které je zřejmé, jakým způsobem je realizována konfigurace v rámci jednotné konzole. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/ |
1.32 | Požadujeme, aby systém umožňoval 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. Připojte odkaz na dokumentaci popisující vytváření uživatelských rolí v grafickém rozhraní systému. | Systémové skupiny: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/web- interface/users/ system-groups/ Databázové skupiny: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/web- interface/users/ database- groups/ |
1.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, splňuje |
1.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, splňuje |
2. Minimální HW parametry požadovaného systému |
2.1 | Jedna hardwarová appliance o velikosti max. 2U, včetně lyžin umožňujících vysunutí zapnutého systému z racku pro servisní účely. | ANO, splňuje |
2.2 | 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, splňuje |
2.3 | 2 procesory, min. 16 jader každý, s podporou HyperThreadingu nebo Multi-Threadingu. | ANO, splňuje |
2.4 | Min. 128GB DDR-4 a NVMe paměťové pole pro zpracování dat v čase blízkém reálnému (Near Real-Time). | ANO, splňuje |
2.5 | Minimálně 120TB pro integrovanou databázi podporovanou HW akcelerovaným SAS RAID řadičem s read-write cache min. 8GB. Řadič diskového pole musí obsahovat zálohovací baterii nebo být vybaven flash pamětí. | ANO, splňuje |
2.6 | 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, splňuje |
2.7 | Ventilátory redundantní a vyměnitelné za provozu. | ANO, splňuje |
2.8 | Napájecí zdroje redundantní a vyměnitelné za chodu (hotplug). | ANO, splňuje |
2.9 | 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, splňuje |
2.10 | Systém pro vzdálenou správu serveru včetně potřebné licence, pokud je třeba (obdoba HP iLO, Dell iDRAC apod). | ANO, splňuje |
3. Výkonnostní a SW parametry systému | ||
3.1 | 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, splňuje |
3.2 | 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. Požadujeme předložení posledních 4 poznámek k novému vydání (release notes) pro kontrolu parametrů navrhovaného systému. | Release notes v českém jazyce zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/introdu ction/release- notes/ |
3.3 | 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. Popište podrobně způsob realizace downgrade, nebo přiložte odkaz na dokumentaci s detailním popisem. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/additio nal- informations/lo gmanager- software- downgrade/ |
3.4 | Průměrný trvalý příjem min. 10000 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, splňuje |
3.5 | Příjem ve špičce minimálně 20000 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, splňuje |
3.6 | 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ě 500 GB uložených událostí za den. Integrovaná databáze musí mít čistou velikost nejméně 120 TB a nad to musí podporovat kompresi ukládaných dat. | ANO, splňuje |
3.7 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/parser /parsing-rules/ |
3.8 | 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, splňuje |
3.9 | 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ě. Doložte odkazem na dokumentaci, ze které je zřejmé, jakým způsobem se vkládají testovací zprávy během psaní nového uživatelského parseru a jakým způsobem je prezentován výstup testu. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/parser /parsing-rules/ |
3.10 | 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, splňuje |
3.11 | 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, splňuje |
3.12 | 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. Doložte odkazem na dokumentaci, jakým způsobem se cluster vytváří a jakým způsobem se provádí obnovení po možném výpadku jednotlivých zúčastněných komponent. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/syste m/cluster/ |
3.13 | 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ě. Popište použitou technologii zabezpečení komunikace v rámci clusteru. | Logmanager využívá pro bezpečné sestavení clusteru i komunikaci s Logmanager Forwardery pevně dané kryptografické algoritmy: pro dohodu na klíči používá Diffieho– Hellmanův protokol s využitím eliptických křivek s křivkou Curve25519, samotné šifrování má podobu autentizovanéh o šifrování šifrou ChaCha20 a autentizační funkcí Poly1305 s hašovací funkcí BLAKE2. Pro klíče hašovacích tabulek používá SipHash. Použitý je UDP |
port 51820 pro Cluster a UDP port 51821 pro komunikaci Logmanager <- > Logmanager Forwarder. | ||
3.14 | V případě rozšíření systému na cluster musí navrhovaný systém zajistit bezvýpadkovost sběru logů. | ANO, splňuje |
3.15 | Řešení musí obsahovat mezipaměť diskového subsystému typu NVRAM o kapacitě minimálně 6TB. | ANO, splňuje |
3.16 | 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, splňuje |
3.17 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/syste m/backup- restore/ |
3.18 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/syste m/backup- restore/ |
4. Alerty | ||
4.1 | Systém je schopen na základě uživatelsky zadaných podmínek splněných v přijatých datech vygenerovat alert. | ANO, splňuje |
4.2 | Text emailu vygenerovaného alertem musí být uživatelsky definovatelný s proměnnými, které jsou vyplněny z přijaté rozparsované události. | ANO, splňuje |
4.3 | Systém musí obsahovat výrobcem předpřipravené sety/vzory alertů a korelací. | ANO, splňuje |
4.4 | 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í. | Dokumentacez de: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/additio nal- informations/ev ents- |
processing-in- blockly/defined- xml- blocks/special- blocks/special- elements/send- alert/ | ||
4.5 | 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. Doložte 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/web- interface/logs/s yslog-output/ |
4.6 | 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). Doložte odkazem na dokumentaci, jakým způsobem lze v jednotném grafickém rozhraní systému definovat a přiřazovat značky. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/additio nal- informations/ev ents- processing-in- blockly/defined- xml- blocks/data- structures- blocks/messag e-add-tag/ |
4.7 | 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, splňuje |
5. Sběr událostí z Microsoft prostředí | ||
5.1 | 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 odkazem na dokumentaci popisující požadované vlastnosti integrovaného Windows agenta. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/logman ager-beats- agent/logmana ger- orchestrator/ |
5.2 | 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ř. zašli pouze logy z adresářů eventview System, Security, Sysmon a Terminal Services a zahoď logy s EventId 7036. | ANO, splňuje |
5.3 | 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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/logman ager-beats- agent/beats- agents/ |
5.4 | 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, splňuje |
5.5 | 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, splňuje |
5.6 | 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. Doložte odkazem na dokumentaci, jakým způsobem se nastavují parametry sběru logů globálně a jakým způsobem u konkrétního agenta. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/logman ager-beats- agent/beats- agents/ |
5.7 | 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í 300 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. Jedná se o klíčovou funkci, proto budeme před uzavřením smlouvy požadovat předvedení požadovaných funkcí, stability i výkonnostní kapacity nabízeného systému pro sběr logů z prostředí Microsoft. | Logmanager Agent je kombinací vlastního vývoje a OpenSource. Není potřeba dokládat více než odkaz na licenční ujednání Logmanager. |
6. Podpora pro sběr událostí z poboček | ||
6.1 | 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. Doložte odkazem na dokumentaci, jakým způsobem realizujete sběr událostí z poboček. | Dokumentace: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- |
interface/sourc es/forwarder/ | ||
6.2 | 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. | Dokumentace: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/web- interface/sourc es/forwarder/ |
6.3 | Ř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, splňuje |
6.4 | Ř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. | Dokumentace zde: xxxxx://xxx.xxx xxxxxxx.xxx/x atest/cz/additio nal- informations/co mmunication- of-logmanager/ |
6.5 | Řešení musí poskytovat kapacitu vyrovnávací paměti pro minimálně 100 GB událostí, které na pobočce mohou vzniknout během výpadku spojení mezi pobočkou a datovým centrem. | ANO, splňuje |
6.6 | Řešení pro sběr dat z poboček musí mít výkon minimálně 5 tisíc událostí/s, a to i v trvalé zátěži. | ANO, splňuje |
6.7 | Řešení musí poskytnout podporu pro sběr událostí na identických UDP i TCP portech jako hlavní dodaný systém. | ANO, splňuje |
6.8 | Řešení musí být k dispozici jako fyzický systém nebo jako virtuální systém pro VMware ESXi a Hyper-V. | ANO, splňuje |
6.9 | Řešení musí být schopno komunikovat z pobočky na centrálu i přes vícenásobný překlad adres (NAT). | ANO, splňuje |
7. Vysoká dostupnost, softwarová podpora a záruka na hardware | ||
7.1 | Požadujeme volitelnou podporu pro nasazení ve vysoké dostupnosti. | ANO, splňuje |
7.2 | Hardware záruka je požadovaná minimálně 5letá servisní podpora na hardware apliance s opravou v místě instalace serveru a s garantovanou odezvou následující pracovní den od nahlášení případné závady. | ANO, splňuje |
7.3 | Systém musí podporovat vygenerování TSR (technického support reportu) pro možnost diagnostiky bez vzdáleného přístupu. | ANO, splňuje |
7.4 | Softwarová podpora výrobce na aktualizaci systému a parserů na 5 let. Podpora musí obsahovat aktualizaci SW minimálně 4x ročně, opravy chyb a telefonickou a emailovou podporu s diagnostikou vzdáleným přístupem. | ANO, splňuje |
Nabízené řešení dodavatele
Námi nabízené řešení je Logmanager-XL se 120TB databází a 5 letou HW a SW podporou včetně instalace. Nástroj
Logmanager-XL splňuje veškeré minimální požadavky Zadavatele uvedené v zadávací dokumentaci.
Logmanager-XL včetně 5 leté HW a SW podpory včetně instalace
POPIS | PRODUKT.OZN. | POČET |
Logmanager-XL – samostatný box 5 let HW support, 1x Logmanager-VF, Logmanager-A, 120 TB databáze, server Dell | LOGM-XL | 1 |
Instalace provedená certifikovaným technikem CompuNet Popis instalace je uveden v dokumentu „Logmanager_implementace“ | CN_INST | 1 |
Logmanager-XL SW podpora 1 rok | LOGM-XL-RNWL-1y | 5 |
V rámci nabízeného řešení je poskytnutí základního školení operátora systému Logmanager přímo výrobcem. Jedná se o 1denní školení pro 1 osobu v Praze (po předložení voucheru).
Úplná a podrobná dokumentace k celému systému a poznámky k vydání (release notes) k systému i všem návazným komponentům jsou uvedeny na stránkách výrobce zde - xxxxx://xxx.xxxxxxxxxx.xxx/xxxxxx/xx/ a xxxxx://xxx.xxxxxxxxxx.xxx/xxxxxx/xx/xxxxxxxxxxxx/xxxxxxx-xxxxx/
Produktový list je přiložen jako samostatný dokument a tvoří nedílnou součást nabídky nebo lze dokument stáhnout
zde - xxxxx://xxxxxxxxxx.xxx/xx/xxxxxxx#xxxxxxxxx-xxx-xxxxxxxx
Popis instalace uveden v dokumentu „Logmanager_implementace“ a tvoří nedílnou součást nabídky.
Popis HW a SW podpory výrobce
Služby podpory pro systém Logmanager zahrnují HW služby a Podporu systému. Jejich cílem je zvýšení dostupnosti, bezpečnosti a ochrany investice do celého systému Logmanager.
Hardware služby
Hardware (HW) služby od výrobců HW zahrnují:
• délka supportu: 5 let
• výměna vadného HW následující pracovní den
Podpora systému (SW podpora)
Podpora na systém Logmanager zahrnuje:
• délka podpory: 5 let
• režim podpory: 8x5 = v pracovní dny od 9:00 do 17:00 (Středoevropského času)
• reakční doba 3 pracovní dny
• nová verze Logmanager softwaru
• nová verze Logmanager parserů
• opravy chyb softwaru
• ke každému dodanému kusu HW appliance Logmanager je k dispozici jedna licence na virtuální
forwarder
Verze softwaru je podporována do chvíle vydání nové verze.
Logmanager a.s., si vyhrazuje právo vyřešení reklamace poskytnutím licence k novější verzi systému.
Logmanager Support Portal
Webový portál podpory se nachází na adrese xxxxx://xxxxxxx.xxxxxxxxxx.xxx/.
Pro založení ticketu skrze support portál, klikněte na „Submit a ticket“ a následujte průvodce. Pro lepší identifikaci zařízení a problému doporučujeme vyplnit volitelné položky, případně připojit přílohu.
Na portále si můžete založit účet a spravovat v něm všechny své požadavky na podporu. Založení účtu navíc zjednoduší zakládání ticketů v budoucnu.
Logmanager Podpora přes email
Chcete-li využít možnost vyžádání podpory přes email. Odešlete svůj požadavek na xxxx@xxxxxxxxxx.xxx, automaticky se založí ticket. Reagovat můžete pouze ze svého emailu nebo webového rozhraní.
Pokud se později rozhodnete pro založení účtu na portále, využijte emailovou adresu, kterou jste použili na poslání žádosti o podporu. Tickety budou automaticky spárovány a vy je odtud můžete spravovat.
Reklamace HW
Servery DELL mají záruku 5 let. Záruku lze ověřit online dle sériového čísla zde:
• xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/xx/xx/xxxxx0?xxxxxxxxxxxx
Při problému se serverem, který je v záruce, kontaktujte zákaznický servis příslušného výrobce. Než tak učiníte, připravte si sériové číslo, stručnou informaci o problému a co mu předcházelo, jaké kroky jste podnikli a případné chybové hlášky. Z místa, z něhož je fyzicky dosažitelný reklamovaný produkt, zavolejte na linku podpory pro svou zemi.
Servery DELL mají v ceně podporu ProSupport a ProSupport Plus. Podpora ProSupport je v ceně serveru, platí
automaticky.
Rozšířená podpora ProSupport Plus je rovněž v ceně produktu, pro její aktivaci si musíte nastavit možnost vzdáleného přístupu pro techniky firmy DELL. Součástí služby je SupportAssist, která nabízí vzdálené sledování, automatizovaný sběr informací o stavu systému, automatické vytváření servisních případů a proaktivní kontaktování ze strany technické podpory (do hodiny od detekce problému). Zákazníci s podporou ProSupport Plus využívají všech výhod podpory SupportAssist, včetně prediktivní detekce závad a měsíčních optimalizačních zpráv.
Detailní informace o službách podpory pro servery DELL lze najít na webových stránkách xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxxxxxxxxxxxxxx/xx-xx. Seznam kontaktů na servisní střediska pro jednotlivé státy najdete zde:
• xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxxxxxx/xx/xx/xxxxx0/xxxxxxx/xxxxxxx-xxxxxxxxxxx/xxxxxxxxxxxxx-xxxxxxx- services/international-contact-center
DELL linka podpory pro ČR (komunikují česky nebo slovensky): 225 772 969 nebo 225 772 727. Po založení případu na lince obdrží zákazník číslo servisního incidentu “Service Request Number”, pod kterým budou vedené veškeré poznámky k případu.
Alternativou úvodního telefonátu je registrace problému přes xxxx://xxx.xxxx.xxx/xxxxxxx. Po zadání Service Tag (=sériového čísla, má 7 znaků), ho systém najde a vygeneruje kód Express Service Code. Objeví se druh poskytované (a aktivní) záruky a seznam možných problémů daného produktu:
• puštění a napájení
• pevný disk a řadiče RAID
• řadič iDRAC, CMC, LifeCycle
• operační systém
• procesor a paměť
• úložiště
• sítě
• software
Po zvolení druhu problému bude zákazník kontaktován technikem společnosti DELL.
Technická podpora a reklamace Logmanageru
V případě jakýchkoliv dalších dotazů nebo případných reklamací nás kontaktujte na adrese
Příloha č. 2 – Položkový rozpočet
položka č. | název položky | maximální cena celkem v Kč bez DPH | nabídková cena v Kč bez DPH |
1 | dodávka řešení (HW a SW) vč. instalace | 2 900 000,00 | 1 499 000,00 |
2 | podpora výrobce pro SW i HW 5 let | 1 300 000,00 | |
Celková nabídková cena veřejné zakázky | 2 799 000,00 |