Procurement observatory.

<!-- PAGE 1 -->**Příloha č. 1_Specifikace předmětu plnění veřejné zakázky „Systém osobních kamer pro výkon" Specifikace předmětu plnění k**

MP Brno rozhodla o změně způsobu používání osobních minikamer každá strážník svoji kameru na systém vydávání a sdílení kamer s

**veřejné zakázce:**

Popis systému: Kamery budou vydávány strážníkovi /uživateli na základě přiložení čipu RFID 125 KHz (každý strážník tento typ čipu již má) ke čtečce kameru z dokovací stanice, která bude nejlépe implementací čteček do systému doporučuji zrealizovat zkoušku s zaručena kompatibilita). Strážník tuto kameru použije při výkonu služby a následně ji vrátí po příchodu na služebnu do dokovací stanice. Kamera se přihlásí do systému a poskytne strážníkovi soubory (audio a video) které pořídil systému AIS MP (Agendový informační systém městské policie poskytnut v části:

***Popis integrace do systému Informačního systému městské policie ( MP)*** **.**

V případě odchodu opět do lokalit se bude celý proces opakovat.

**Požadavky na systém:**

- Jednotlivé kamery budou **spravovány centrálně administrátory (min 4x)**

do dokovací stanice

- Správa uživatelů bude probíhat prostřednictvím
- Každý uživatel bude mít přístup pouze k
- Kamery budou chráněny heslem (případně jiným prvkem proti zneužití při ztrátě)
- Systém osobních kamer bude komunikovat s zadavatel
- Uživatel /strážník **nebude** mít možnost jakýmkoliv způsobem měnit nastavení kamery
- Při ztrátě kamery nebude mít případný nálezce možnost stažení a prohlížení záznamů
- Celý systém bude v českém jazyce – určeny pro český trh
- Systém umožní export dat pro evidenci
- Při ztrátě, poškození, zničení, likvidaci, nebo naopak přidání nové kamery do systému bude tyto úkony provádět administrátor MP Brno
- Systém bude umožňovat rozšíření a to o
- Záruka na systém **minimálně 24 měsíců**
- Systém při vydávání kamer bude respektovat tu skutečnost, že vybere nejvhodnější kameru na organizačním celku a budově, stažení záznamů, nabití apod.

**„Systém osobních kamer pro výkon"**

, která bude součástí systému a systém vydá připravená tak, aby je mohl zpracovat a zařadit do ze systému, kdy má centrální správou. k provozu našimi čipy, aby byla Brno) – přesný popis je (před vlastní

***AIS***

**Active Directory**

záznamům které pořídil AIS MP. Síťovou infrastrukturu poskytne

**CZ distribuce** , veškeré komponenty budou

**min. 50 %** vzhledem k dodávce kam uživatel naposledy kameru vložil pro po zasunutí (AD)

<!-- PAGE 2 -->**Minimální rozsah datových exportů z důvodu evidence:**

- Sériové číslo kamery
- Vlastní pojmenování kamery
- Model kamery
- Verze firmwaru
- Aktuálně přiřazený uživatel (nebo bez uživatele)
- Status zadokovaná nebo používaná
- Čas posledního zadokování nebo vydání
- Informace o tom, kde je zadokovaná nebo byla naposledy
- Vlastní jméno tohoto HW (například dle služebny či jednotky)
- Číslo portu, respektive doku v rámci daného HW
- Počet nabíjecích cyklů kamery
- Tag – jakýkoliv popisek vytvořený administrátorem u kamery
- Exportované soubory budou minimálně ve formátu .xlsx
- Výpis bude možné udělat k aktuálnímu dni a času s přesností na minuty

**Popis integrace do systému Informačního systému městské policie Brno (ISMP): Technická specifikace – softwarová část**

*Správa záznamů osobních kamer strážníků*

1. **Základní informace**

Tato část dokumentu vymezuje technické, funkční a integrační požadavky na softwarovou část řešení pro správu osobních (body – worn) kamer strážníků Městské policie Brno (dále jen „MP Brno"). Předmětem této přílohy je popis implementace, integrace, parametrizace, akceptačních testů, zaškolení uživatelů a administrátorů a poskytování podpory softwarového řešení zajišťujícího kompletní životní cyklus videozáznamu od okamžiku přidělení kamery strážníkovi přes automatický upload záznamů po jejich archivaci, zpřístupnění v rámci agendového informačního systému (dále jen „AIS") a řízené mazání v souladu s retenčními pravidly.

<!-- PAGE 3 -->1. **Definice pojmů a zkratek**

**UDÁLOSTNÍ ZÁZNAM** – záznam, který strážník v AIS přiřadil k události, **UNC** – Universal Naming Convention – formát síťové cesty \\\\server\\share\\...

**RFID** – Radio Frequency Identification – bezkontaktní identifikace čipem **RBAC** – Role – Based Access Control – řízení přístupu na základě rolí

**FILESHARE – síťové** souborové úložiště typu Windows Server (SMB/CIFS), nasazené a spravované zadavatelem

**DOKOVACÍ STANICE** – zařízení pro nabíjení kamery a přenos záznamů do serverové části **cardID** – Atribut v AD obsahující identifikátor RFID čipu přiřazeného uživateli **BWC** – Body – Worn Camera – osobní kamera nošená strážníkem **AIS** – Agendový informační systém MP Brno, kde strážník přiřazuje záznamy k jednotlivým událostem **AD –** Active Directory – adresářová služba MP Brno pro správu identit a autentizaci uživatelů

1. **Logická architektura řešení**

Systém se skládá z následujících logických komponent, které musí spolu s dodávanými kamerami a dokovacími stanicemi tvořit funkční, otestovaný a zadavatelem akceptovaný celek: serverová aplikace provozovaná on – premises v datovém centru zadavatele (virtuální prostředí VMware vSphere). databázová vrstva ukládající metadata, konfiguraci, stavy zařízení, audit log a referenční data uživatelů synchronizovaná z AD, úložiště videozáznamů realizované jako síťový fileshare (Windows Server, protokol SMB 3.x), nasazený a spravovaný zadavatelem. Dodavatel musí zajistit plnou kompatibilitu systému s tímto úložištěm, webové uživatelské rozhraní (dále jen „Web GUI") pro strážníky, dozorčí směn, auditory a administrátory, Rozhraní pro integraci s AIS pro otevření UNC cesty k záznamům konkrétního uživatele, software dokovacích stanic zajišťující přenos záznamů z kamery do úložiště a hlášení stavů do serverové části, modul identifikace uživatele pomocí RFID čipu komunikace s dokovací stanicí, resp. přidělovací jednotkou,

**3.1 Referenční datový a procesní tok**

Životní cyklus záznamu:

**Přidělení kamery:** Strážník před nástupem do služby přiloží RFID čip k čtečce u přidělovací/dokovací stanice. Systém na základě hodnoty čipu (přečtené přes RFID) vyhledá

<!-- PAGE 4 -->v AD uživatele s odpovídající hodnotou atributu cardID, ověří oprávnění a přidělí mu konkrétní kameru (uvolní ji z dokovací stanice a světelnou nebo zvukovou signalizací ji indikuje).

**Pořizování záznamu:** Strážník v průběhu služby pořizuje záznamy. Spojení kamera–uživatel je po celou dobu služby jednoznačně evidováno.

**Návrat a upload:** Po skončení služby strážník zasune kameru do dokovací stanice. Dokovací stanice automaticky zahájí přenos záznamů do síťového fileshare. Záznamy jsou uloženy do složky konkrétního uživatele (podle sAMAccountName / userPrincipalName z AD).

**Evidence v AIS:** Strážník v AIS u konkrétní události klikne na odkaz „Přidat záznam"; AIS volá otevření UNC cesty v Průzkumníku Windows a zpřístupní složku s videi daného strážníka, ze které uživatel vybraný soubor přiřadí k události. Záznam je po úspěšném zkopírovaní z úložiště automaticky odstraněn.

1. **Funkční požadavky**

**4.1 Přidělení kamery přes RFID**

Doba odezvy od přiložení čipu do uvolnění kamery NESMÍ přesáhnout 3 sekundy při standardním zatížení systému. Systém musí podporovat režim „jeden strážník – libovolná volná kamera". Systém musí signalizovat přidělenou kameru vizuálně (LED) a/nebo akusticky na stanici a současně ve Web GUI u operátora/dozorčího směny. Při neznámém čipu (cardID nenalezeno v AD) nebo u uživatele bez oprávnění musí systém přidělení odmítnout a událost zaznamenat do audit logu. Systém musí párovat RFID → uživatele na základě atributu cardID v Active Directory (bez nutnosti udržovat duplicitní registr čipů). Systém musí podporovat přidělení konkrétní kamery uživateli na základě přiložení jeho RFID čipu ke čtečce u přidělovací/dokovací stanice.

**4.2 Dokování a upload záznamů**

Systém musí poskytovat provozní metriky dokovací stanice (obsazenost slotů, stav nabíjení, probíhající přenosy, chyby) a předávat je do Web GUI a syslog/SIEM. Systém musí evidovat u každého záznamu min.: identifikátor záznamu, identifikátor kamery, identifikátor přiděleného uživatele (AD), datum/čas začátku a konce záznamu, délku, velikost, hash, datum/čas uploadu.

<!-- PAGE 5 -->Po úspěšném přenosu musí být provedeno ověření integrity (hash) souboru proti zdroji v kameře. Záznam v kameře smí být smazán až po úspěšném ověření. Přenos musí být zabezpečený a odolný vůči výpadku sítě – při přerušení pokračuje od posledního úspěšně přeneseného bloku. Po zasunutí kamery do dokovací stanice musí systém automaticky, bez zásahu uživatele, zahájit přenos všech nestažených záznamů do síťového fileshare.

**4.3 Struktura úložiště a adresářové členění**

Síťový fileshare je nasazen a spravován zadavatelem. Cílová struktura v síťovém fileshare musí být následující (konkrétní UNC cesta k sdílení je předmětem konfigurace při implementaci): \\\\\<server\>\\\<share\>\\\<sAMAccountName\>\\\<YYYY\>\\\<MM\>\\\<DD\>\\\<camID\>_\<timestamp\>. \<ext\> Systém musí podporovat SMB protokol verze minimálně 3.0 a komunikaci přes Kerberos (nikoliv NTLMv1/v2) pod dedikovaným service accountem s nejmenšími možnými oprávněními. Zadavatel zajistí konfiguraci fileshare pro SMB 3.x a Kerberos autentizaci dle požadavků dodavatele. Názvy souborů musí obsahovat identifikátor kamery a časové razítko začátku záznamu ve formátu RRRRMMDD_HHMMSS a musí umožňovat jednoznačnou identifikaci bez metadat. Systém musí podporovat konfigurovatelnou strukturu podsložek podle data (např. RRRR/MM/DD) a volitelně podle kamery. Na uživatelskou složku musí být automaticky nastaveny NTFS ACL tak, aby do ní měl přístup daný uživatel (R), členové definovaných AD skupin dozorčí/supervisor (R), auditor (R) a service account DEMS (modify). Ostatním NESMÍ být přístup povolen. Kořenová složka uživatele musí být pojmenována podle atributu sAMAccountName (nebo jiného jednoznačného AD atributu dle konfigurace) a musí vzniknout automaticky při prvním uploadu záznamů tohoto uživatele.

**4.4 Integrace s Active Directory**

Při deaktivaci účtu v AD musí systém okamžitě odepřít přístup do Web GUI a zablokovat další přidělování kamer danému uživateli; existující záznamy a přiřazení zůstávají beze změny. Systém musí podporovat více doménové prostředí a strukturu organizačních jednotek (OU) odpovídající členění MP Brno (služebny / revíry). Synchronizace změn z AD (přidání/odebrání uživatele, změna cardID, členství ve skupině) musí proběhnout do 15 minut od změny v AD a musí běžet i v plánovaném denním plném synchronizačním cyklu. Role musí být mapovány na AD skupiny. Mapování musí být konfigurovatelné bez zásahu dodavatele.

<!-- PAGE 6 -->Systém musí číst z AD min. atributy: sAMAccountName, userPrincipalName, displayName, mail, cardID (nebo jiný zadavatelem určený atribut pro RFID), memberOf. Autentizace uživatelů do Web GUI musí probíhat proti AD pomocí protokolu LDAPS nebo Kerberos (SSO, integrovaná autentizace Windows).

**4.5 Integrace s AIS**

Integrace s agendovým informačním systémem MP Brno bude realizována prostřednictvím funkcionalit dodaného systému a AIS. Po vrácení kamery do dokovací stanice se spustí kopírování záznamů do home adresáře strážníka. Jakmile se záznamy zkopírují všechny, dodaný systém v adresáři vytvoří .txt soubor, ve kterém budou informace o dokončení operace. AIS po přihlášení strážníka zkontroluje stav kopírování záznamů a otevře rozhraní pro import videozáznamů. V tomto rozhraní bude k dispozici seznam čísel jednacích se základním popisem a dále seznam video souborů dostupných na základě UNC cesty uživatele. Následně strážník metodou drag & drop přiřadí vybrané videozáznamy k odpovídajícím událostem v AIS. AIS následně předá videozáznamy ke zpracování komprimační službě.

**4.5.1 Otevření UNC cesty z AIS**

Přístup k UNC cestě musí být řízen výhradně NTFS/SMB oprávněními odvozenými z AD – nikoliv sdíleným heslem nebo lokálním účtem. Zavoláním z AIS musí otevřít standardní okno Průzkumníka Windows na příslušné UNC cestě (např. explorer.exe /e,"\\\\server\\share\\novak"); způsob otevření (URL handler, helper utility, ClickOnce apod.) navrhne dodavatel a odsouhlasí si ho se zadavatelem a dodavatelem AIS. Systém musí poskytnout AIS endpoint / funkci, kterým AIS pro daného uživatele získá UNC cestu ke složce obsahující jeho stažené záznamy (typicky \\\\server\\share\\sAMAccountName\), případně filtr na období.

**4.6 Web GUI a rolový model (RBAC)**

Všechny akce ve Web GUI (přihlášení, přehrání, stažení, export, změna metadat, uzamčení/odemčení) musí generovat záznam v audit logu. Web GUI musí umožnit export záznamu (stažení souboru) s auditním záznamem a volitelnou doplňkovou metadatovou kartou (PDF) obsahující hash, čas, uživatele, kameru a důvod exportu. Export musí být dostupný pouze rolím oprávněným dle konfigurace.

<!-- PAGE 7 -->Systém musí implementovat RBAC s minimálně rolemi: strážník (vidí jen vlastní záznamy), dozorčí směny (vidí záznamy podřízené směny), supervisor (služebna), administrátor (konfigurace), auditor (read – only + audit log). Role musí být mapovány na AD skupiny. Web GUI musí umožnit online přehrávání videa včetně posunu časové osy bez nutnosti stahovat celý soubor lokálně. Web GUI musí umožnit vyhledávání a filtrování záznamů podle:

- uživatele, kamery, období, služebny (AD OU), příznaku „přiřazeno k události", stavu uploadu, hash. Web GUI musí být plně lokalizováno do českého jazyka (rozhraní i systémové hlášky). Web GUI musí být dostupné přes prohlížeč Microsoft Edge (Chromium) a Google Chrome v aktuální a předchozí major verzi;
- bez nutnosti instalace tlustého klienta.

**4.7 Audit log**

Metadata záznamu musí být při každé změně (např. přiřazení k události) verzována – předchozí stav lze auditně zrekonstruovat. Systém musí umožnit export audit logu do SIEM zadavatele přes syslog (RFC 5424) nebo ekvivalentní zabezpečený kanál (TLS). Audit log musí být chráněn proti úpravám a mazání i privilegovanými uživateli (včetně lokálního administrátora serveru) – technickou realizaci (např. podepisování, hash chain,) popíše dodavatel v nabídce. Záznam v audit logu musí obsahovat minimálně: časové razítko (NTP synchronizované, s přesností na sekundu), identifikátor uživatele (AD), IP adresu, typ akce, cílový objekt, výsledek (úspěch/selhání). Systém musí vést neoddělitelný audit log všech administrativních i uživatelských akcí (přihlášení, přehrání, stažení, přiřazení k události, skartace, změny konfigurace, pokusy o přístup bez oprávnění).

**4.8 Retence a řízená skartace záznamů**

Retenční pravidla nesmí být pevně zakódována; musí být konfigurovatelná ve Web GUI osobou s rolí administrátora a musí splňovat minimálně tyto základní požadavky zadavatele: Systém musí umožnit reporting – počet záznamů po jednotlivých stavech retence, nadcházející skartace, legal hold – a tento report generovat minimálně jednou denně. Skartace musí proběhnout způsobem, který znemožňuje rekonstrukci dat běžnými forenzními prostředky (bezpečné mazání / overwrite, event. crypto – shred, pokud je úložiště šifrované na úrovni objektu). Systém musí umožnit individuální prodloužení retence konkrétního záznamu (tzv. legal hold) rolí supervisor/administrátor s povinným zadáním důvodu. Před plánovanou skartací musí systém generovat skartační protokol (kdo, co, kdy) a uložit ho do audit logu; protokol musí být auditovatelný.

<!-- PAGE 8 -->1. **Ostatní požadavky**

**5.1 Provozní prostředí**

Systém musí podporovat provoz v plně oddělené síti MP Brno bez přístupu do veřejného internetu; aktualizace musí být dodávány offline (instalační balíček). Databáze musí být buď (a) MS SQL Server verze podporované zadavatelem, nebo (b) open – source DB (PostgreSQL) – v obou případech bez doplatku za runtime licenci. Dodavatel musí v nabídce uvést minimální HW požadavky (v CPU, RAM, disk – OS/DB/cache) pro všechny komponenty při cílovém dimenzování (viz 5.2). Dodavatel musí dodat aplikaci vč. detailního instalačního postupu pro Windows Server / Linux, který umožní zadavateli vlastní instalaci ve vSphere. Serverová část musí být dodána jako on – premise řešení provozované ve virtualizační platformě zadavatele VMware vSphere (verze 7.x nebo vyšší). Cloudové řešení (SaaS) NENÍ přípustné.

**5.2 Výkon, kapacita, dostupnost**

Systém musí být horizontálně nebo vertikálně škálovatelný bez nutnosti reinstalace při navýšení počtu kamer/uživatelů. RPO pro metadata a audit log musí být max. 1 hodina, RTO max. 4 hodiny. Videosoubory uložené na fileshare musí být zálohovány zálohovacím SW zadavatele – dodavatel popíše kompatibilní postup. Dostupnost služby (DEMS jako celek mimo plánované odstávky) musí být min. 99 % v rámci kalendářního měsíce, měřeno na úrovni Web GUI. Systém musí zvládnout současný upload min. 30 kamer z různých dokovacích stanic, aniž by se response time API nebo Web GUI zvýšil nad 2s. Systém musí být dimenzován pro minimálně 300 aktivních strážníků MP Brno. Počet kamer se neprovazuje 1:1 s uživateli (sdílení ve směnách) – dodavatel v nabídce navrhne sizing pro dodaný počet kamer dle HW části.

**5.3 Bezpečnost a soulad**

Dodavatel musí deklarovat a po dobu podpory dodržet proces řízení zranitelností – reakci na kritické CVE do 7 kalendářních dnů, vydání patche nebo kompenzačního opatření do 30 kalendářních dnů. Dodavatel musí umožnit provedení penetračního testu a bezpečnostního auditu zadavatelem (nebo jím pověřenou třetí stranou) bez dopadu na záruku. Systém musí podporovat integraci s SIEM zadavatele (syslog, příp. CEF) a zasílat tam bezpečnostně relevantní události (neúspěšné přihlášení, změny oprávnění, skartace, pokusy o přístup do cizí složky).

<!-- PAGE 9 -->Hesla a tajné klíče (service účty, client_secret OAuth) NESMÍ být uloženy v čitelné podobě; doporučeno je využití Windows Credential Store / Group Managed Ser nebo obdobného bezpečného úložiště. Veškerá komunikace mezi komponentami (kamera/dock AIS, prohlížeč ↔ server) musí být šifrována (TLS 1.2 a vy Řešení musí respektovat zákon č. 181/2014 Sb., 82/2018 Sb., v platném znění (logování, řízení přístupu, správa zranitelností, aktualizace). Řešení musí být v souladu s Nařízením GDPR a zákonem č. 110/2019 Sb., o zpracování osobních údajů, včetně záznamu o činnostech zpracování, práva subjektu údajů a bezpečnosti zpracování.

**5.4 Instalace, monitoring, zálohování**

Dodavatel musí specifikovat, co a jak zálohovat, a výsledek musí být obnovitelný bez součinnosti dodavatele (DR drill jako součást akceptace). Systém musí poskytovat health – check endpoint pro monitoring zadavatele (typicky Zabbix / PRTG) a exportovat metriky (např. Prometheus / WMI / SNMP). Dodavatel musí poskytnout skripty / postupy pro automatizovanou instalaci a upgrade komponent.

1. **Integrační rozhraní – souhrn**

vice Account (gMSA) ↔ server, server ↔ šší, SMB 3.x). o kybernetické bezpečnosti, a vyhlášku č. AD, server ↔

**6.1 Přehled rozhraní**

Zálohovací SW zadavatele – dodavatele) Monitoring (SNMP/HTTP) SIEM (syslog/CEF) – Audit log a AIS – UNC handler – Otevření Průzkumníka Windows na složce daného uživatele Fileshare (SMB 3.x, provozovaný zadavatelem) – Dokovací stanice (HW) – Přenos videa kamera části RFID čtečka (dock) – Identifikace uživatele při přidělování kamery AD (LDAP/LDAPS, Kerberos) uživatel Zálohování DB, audit logu a konfigurace (doporučený postup od

- Health –
- check, metriky výkonu a stavu zařízení bezpečnostní události Úložiště videosouborů, NTFS ACL dle AD → fileshare, hlášení stavů, dle specifikace HW Čtení uživatelů a skupin, SSO do Web GUI, překlad RFID →

<!-- PAGE 10 -->1. **Dokumentace, školení, záruka a podpora**

Dodavatel musí v nabídce popsat eskalační matici a kontaktní kanály (mail, HelpDesk portál, telefon, popř. ServiceNow webhook). Dodavatel musí poskytovat minoritní a majoritní upgrade po dobu podpory (včetně bezpečnostních patchů) bez dodatečných nákladů. Dodavatel musí nabídnout pozáruční podporu (maintenance) na min. 5 let s reakční dobou: kritická vada – 4 hod (24/7), vysoká – NBD (business hours), ostatní – 5 BD. Podrobný SLA bude součástí smlouvy. Dodavatel musí poskytnout záruku v délce min. 24 měsíců od akceptace, pokrývající odstranění vad, bezpečnostních chyb a nekompatibility s dodaným HW. Dodavatel musí zajistit školení - 2× skupina administrátorů (min. 8 hod), Dodavatel musí dodat v českém jazyce: administrátorskou příručku, uživatelskou příručku pro strážníka a dozorčího, instalační a provozní dokumentaci, integrační příručku (AD, AIS, SIEM).

1. **Akceptační kritéria**

Plnění bude akceptováno po úspěšném provedení níže uvedených testů (výčet je minimální, dodavatel MÁ PRÁVO navrhnout další): End – to – end test přidělení kamery RFID čipem – úspěšné přidělení, kontrola záznamu v audit logu a signalizace ve Web GUI. Test paralelního dokování a uploadu 30 kamer – ověření integrity (hash), vytvoření správných složek dle sAMAccountName, nastavení NTFS ACL. Test integrace s AIS – volání API (přiřazení záznamu k události), prodloužení retence, zablokování automatického mazání. Test otevření UNC cesty z AIS – kliknutí otevře Průzkumníka Windows na správnou složku, přístup je dán AD oprávněními. Test retence – běžný záznam se po 14 dnech automaticky smaže, událostní zůstane, vygeneruje se skartační protokol. Test deaktivace uživatele v AD – okamžitý dopad na Web GUI a přidělování kamer.

<!-- PAGE 11 -->**Specifikace KAMERA typ Kamery VELKÉ provedení –**

úhel záběru horizontálně úhel záběru vertikálně Citlivost rozlišení – nastavitelně minimálně v těchto úrovních fps

**VELKÁ (41 ks):**

**pro jednotky používající taktickou vestu**

min 135 úhlových stupňů min 75 úhlových stupňů min 0,1 LUX 1920 x 1080 a 1280 x 720 min 25fps/50 Hz WDR Elektronický stabilizátor obrazu ANO ANO (EIS /720 p) /korekce soudkovitosti Mikrofon ANO Audio min 48KHz. 128 kbps Krytí min IP67 Stanby mode Doba záznamu do přepisu s kryptováním Kryptování záznamu Prealarm VIDEO nastavitelné Prealarm AUDIO nastavitelné min 24 hod min 24 hod ANO min rozsah: 0–120 sec min rozsah: 0–120 sec

| Výdrž při rozlišení 720 p s aktivovaným prealarmem | min | 14 hod |
| --- | --- | --- |
| Výdrž při rozlišení 1080 p s aktivovaným prealarmem | min | 13 hod |

| Tok dat mezi kamerou a systémem při |  | 100Mbit/sec (pozn.: mezi kamerou a prvním HW |
| --- | --- | --- |
| zadokováním | min | prvkem systému) |

|  |  | ANO – GPS, GLONASS, GALILEO (všechny |
| --- | --- | --- |
| Satelitní určování polohy |  | systémy) |
| Senzory |  | 3-osy gyroskop, akcelerometr |

<!-- PAGE 12 -->Uživatelský interface Provozní teploty okolí Spuštění vice kamer prostřednictvím jedné kamery Hmotnost Rozměry v x š x h Aktivace nahrávání – tlačítkem Systém uchycení Barevné provedení min statusové indikátory, audio, vibrace min rozsah: -20 - +50 °C ANO (venkovní prostory – překážek min 10 m) max 180 g – bez držáku/klipu max 95 x 70 x 30 (mm) umístěno na přední stěně a zabírá min. celkové čelní plochy Klick Fast Systém + úchyt na takticku vestu dle nabídky Tmavé barvy (černá, tmavě šedá, tmavě modrá) vzdálenost bez 15 %

**Specifikace KAMERA typ malá (181 ks):**

**Kamery MALÉ provedení –**

úhel záběru horizontálně úhel záběru vertikálně Citlivost rozlišení – nastavitelně minimálně v těchto úrovních fps

**pro org. celky používající běžnou výstroj**

min 110 úhlových stupňů min 60 úhlových stupňů min 0,1 LUX 1920 x 1080 a 1280 x 720 min 25fps/50 Hz WDR Elektronický stabilizátor obrazu Mikrofon ANO ANO (EIS /720 p) / korekce soudkovitosti ANO

| Audio | min | 48KHz. 128 kbps |  |
| --- | --- | --- | --- |
| Krytí | min | IP54 |  |

<!-- PAGE 13 -->

| Výdrž při rozlišení 720 p s aktivovaným prealarmem | min | 9,5 hod |
| --- | --- | --- |
| Výdrž při rozlišení 1080 p s aktivovaným prealarmem | min | 8 hod |

Stanby mode Doba záznamu do přepisu s kryptováním Kryptování záznamu Prealarm VIDEO nastavitelné Prealarm AUDIO nastavitelné Satelitní určování polohy Senzory Uživatelský interface Provozní teploty okolí Spuštění vice kamer prostřednictvím jedné kamery Hmotnost Rozměry v x š x h Aktivace nahrávání – tlačítkem min 16 hod min 24 hod ANO min rozsah: 0–120 sec min rozsah: 0–120 sec není podmínkou 3-osy gyroskop, akcelerometr min statusové indikátory, audio, vibrace min rozsah: -20 - +40 °C NE max 100 g – bez držáku/klipu max 85 x 55 x 20 (mm) ANO

| Tok dat mezi kamerou a systémem při |  | 100Mbit/sec (pozn.: mezi kamerou a prvním |
| --- | --- | --- |
| zadokování | min | HW prvkem systému) |

| systém uchycení |  | úchyt na oděv dle nabídky |
| --- | --- | --- |
| Barevné provedení |  | Tmavé barvy (černá, tmavě šedá, tmavě modrá) |

<!-- PAGE 14 -->**Počty budov a organizačních celků pro stanovení technologických prvků a kamer:**

| budova | org. celek | velké kamery (ks) | malé kamery (ks) | pozn. |
| --- | --- | --- | --- | --- |
| Křenová 4 | Jednotka dopravní |  | 35 |  |
| Křenová 4 | Revír – Střed |  | 30 |  |
| Nováčkova 16 | Revír – Sever |  | 15 |  |
| Kovárenská 1 | Revír – Jih |  | 15 |  |
| Velkopavlovická 25 | Revír – Východ |  | 15 |  |
| Medlánecká 29 | Revír – Pole |  | 15 |  |
| Horova 28 | Revír – Tábor |  | 15 |  |
| Labská 9 | Revír – Západ |  | 15 |  |
| Labská 9 | Jednotka pořádková | 35 |  |  |
| Nám. 28.dubna 61 | Revír – Bystrc |  | 15 |  |
| Přístavní 40 | Jednotka poříční |  | 6 |  |
| Kaštanová 34 | Jednotka psovodů | 5 |  |  |
| Palcary 50 | Odchytová služba | 1 |  | Detašované pracoviště Jednotka psovodů |
| Štefánikova 43 | Ředitelství MP Brno |  | 5 |  |
|  | celkem | 41 | 181 |  |

Počet budov: 12 Počet pracovišť: 14

Hmotnost malé kamery do: 100 g bez klipu Hmotnost velké kamery do: 180 g bez klipu

**Další požadavky:**

<!-- PAGE 15 -->1. Bude provedeno 14 denní testování v provozu, přičemž od každého typu kamery budou k dispozici 2 kusy včetně veškerého potřebného příslušenství. Uchazeči mohou nabídnout variantní typy klipů k jednotlivým kamerám, které však nebudou mít vliv na nabídkovou cenu. Instalace bude provedena včetně potřebné infrastruktury, aby bylo možno ověřit kompletní využití systému dle zadání, celcích MP Brno. Přípravné období na spuštění testování 14 dní.
2. Budou vyčísleny **licenční náklady,** na provoz systému let po jednotlivých letech, které musí provozovatel hradit pro zajištění funkčnosti systému.
3. Budou dodány dokovací stanice na jednotlivé organizační celky tak, aby bylo možno nabíjet současně 100 % dodaných kamer
4. Nad rámec potřebných dokovacích stanic bude dodáno jako náhradní díl 2 kusy od každého typu – dle faktické skutečnosti podle toho, kolik pozic (bude součástí nabídkové ceny viz položka č. 7 kompletní funkční HW systém dle ZD a jejích příloh řádcích 2 a 4 tabulky).
5. Členění cenové nabídky:

**Předmět Nabídková cena v Sazba Kč bez DPH DPH v %**

1. **Cena za 1 ks včetně veškerého požadovaného příslušenství kamera TYP VELKÁ**
2. **Cena za 41 ks včetně veškerého požadovaného příslušenství kamera TYP VELKÁ**
3. **Cena za 1 ks včetně veškerého požadovaného příslušenství kamera TYP MALÁ**
4. **Cena za 181 ks včetně veškerého požadovaného příslušenství kamera TYP MALÁ**
5. **Cena za 41 ks kamera TYP VELKÁ a 181 ks kamera TYP MALÁ včetně veškerého požadovaného příslušenství (∑ řádků 2 a 4)**

a to na dvou organizačních na dobu 5-ti po sobě jdoucích bude mít dokovací stanice níže uvedené tabulky, tj. cena za mimo položek uvedených v

**Samostatně DPH v Kč Nabídková cena v Kč s DPH**

<!-- PAGE 16 -->1. **Cena za kompletní SW dle ZD a jejích příloh**
2. **Cena za kompletní funkční HW systém dle ZD a jejích příloh mimo položek uvedených v řádcích 2 a 4**
3. **Cena za licence po dobu 24 měsíců, tj. po dobu předpokládané záruky**
4. **Cena za licence na dobu 5-ti let po skončení prvotní licence**
5. **Cena za práce za celé plnění dle ZD a jejích příloh**
6. **Celková nabídková cena (∑ řádků 2, 4, 6-8, 10) Nabízený typ KAMERA TYP VELKÁ Nabízený typ KAMERA TYP MALÁ**

*Pozn.: Nabídková cena uvedená v nabídce musí zahrnovat veškeré náklady související s plněním předmětu této zakázky včetně dopravy do místa plnění – budovy MP Brno dle rozpisu. Součástí sjednané ceny jsou veškeré poplatky a náklady dodavatele nezbytné pro řádné a úplné plnění zakázky. Další náklady již k nabídkové ceně nebudou účtovány.* 6) Systém bude kompletně nainstalován a uveden do provozu dodavatelem v koordinaci se zadavatelem.

1. Předpokládaná částka 4 650 000,- Kč vč. DPH činí součet položek č. 2, 4, 6-8, 10 nabídkové tabulky – viz výše a dále cena za licenci na dobu 5 let po skončení 24 měsíců ve výši 100.000,- Kč vč. DPH/5 let – řádek 9 tabulky.

**Celková předpokládaná hodnota** této zakázky tedy činí **4.750.000,-** Kč vč. DPH

Page 1

**Příloha č. 1_Specifikace předmětu plnění veřejné zakázky „Systém osobních kamer pro výkon" Specifikace předmětu plnění k**

MP Brno rozhodla o změně způsobu používání osobních minikamer každá strážník svoji kameru na systém vydávání a sdílení kamer s

**veřejné zakázce:**

Popis systému: Kamery budou vydávány strážníkovi /uživateli na základě přiložení čipu RFID 125 KHz (každý strážník tento typ čipu již má) ke čtečce kameru z dokovací stanice, která bude nejlépe implementací čteček do systému doporučuji zrealizovat zkoušku s zaručena kompatibilita). Strážník tuto kameru použije při výkonu služby a následně ji vrátí po příchodu na služebnu do dokovací stanice. Kamera se přihlásí do systému a poskytne strážníkovi soubory (audio a video) které pořídil systému AIS MP (Agendový informační systém městské policie poskytnut v části:

***Popis integrace do systému Informačního systému městské policie ( MP)*** **.**

V případě odchodu opět do lokalit se bude celý proces opakovat.

**Požadavky na systém:**

- Jednotlivé kamery budou **spravovány centrálně administrátory (min 4x)**

do dokovací stanice

- Správa uživatelů bude probíhat prostřednictvím

- Každý uživatel bude mít přístup pouze k

- Kamery budou chráněny heslem (případně jiným prvkem proti zneužití při ztrátě)

- Systém osobních kamer bude komunikovat s zadavatel

- Uživatel /strážník **nebude** mít možnost jakýmkoliv způsobem měnit nastavení kamery

- Při ztrátě kamery nebude mít případný nálezce možnost stažení a prohlížení záznamů

- Celý systém bude v českém jazyce – určeny pro český trh

- Systém umožní export dat pro evidenci

- Při ztrátě, poškození, zničení, likvidaci, nebo naopak přidání nové kamery do systému bude tyto úkony provádět administrátor MP Brno

- Systém bude umožňovat rozšíření a to o

- Záruka na systém **minimálně 24 měsíců**

- Systém při vydávání kamer bude respektovat tu skutečnost, že vybere nejvhodnější kameru na organizačním celku a budově, stažení záznamů, nabití apod.

**„Systém osobních kamer pro výkon"**

, která bude součástí systému a systém vydá připravená tak, aby je mohl zpracovat a zařadit do ze systému, kdy má centrální správou. k provozu našimi čipy, aby byla Brno) – přesný popis je (před vlastní

***AIS***

**Active Directory**

záznamům které pořídil AIS MP. Síťovou infrastrukturu poskytne

**CZ distribuce** , veškeré komponenty budou

**min. 50 %** vzhledem k dodávce kam uživatel naposledy kameru vložil pro po zasunutí (AD)

Page 2

**Minimální rozsah datových exportů z důvodu evidence:**

- Sériové číslo kamery

- Vlastní pojmenování kamery

- Model kamery

- Verze firmwaru

- Aktuálně přiřazený uživatel (nebo bez uživatele)

- Status zadokovaná nebo používaná

- Čas posledního zadokování nebo vydání

- Informace o tom, kde je zadokovaná nebo byla naposledy

- Vlastní jméno tohoto HW (například dle služebny či jednotky)

- Číslo portu, respektive doku v rámci daného HW

- Počet nabíjecích cyklů kamery

- Tag – jakýkoliv popisek vytvořený administrátorem u kamery

- Exportované soubory budou minimálně ve formátu .xlsx

- Výpis bude možné udělat k aktuálnímu dni a času s přesností na minuty

**Popis integrace do systému Informačního systému městské policie Brno (ISMP): Technická specifikace – softwarová část**

*Správa záznamů osobních kamer strážníků*

1. **Základní informace**

Tato část dokumentu vymezuje technické, funkční a integrační požadavky na softwarovou část řešení pro správu osobních (body – worn) kamer strážníků Městské policie Brno (dále jen „MP Brno"). Předmětem této přílohy je popis implementace, integrace, parametrizace, akceptačních testů, zaškolení uživatelů a administrátorů a poskytování podpory softwarového řešení zajišťujícího kompletní životní cyklus videozáznamu od okamžiku přidělení kamery strážníkovi přes automatický upload záznamů po jejich archivaci, zpřístupnění v rámci agendového informačního systému (dále jen „AIS") a řízené mazání v souladu s retenčními pravidly.

Page 3

1. **Definice pojmů a zkratek**

**UDÁLOSTNÍ ZÁZNAM** – záznam, který strážník v AIS přiřadil k události, **UNC** – Universal Naming Convention – formát síťové cesty \\\\server\\share\\...

**RFID** – Radio Frequency Identification – bezkontaktní identifikace čipem **RBAC** – Role – Based Access Control – řízení přístupu na základě rolí

**FILESHARE – síťové** souborové úložiště typu Windows Server (SMB/CIFS), nasazené a spravované zadavatelem

**DOKOVACÍ STANICE** – zařízení pro nabíjení kamery a přenos záznamů do serverové části **cardID** – Atribut v AD obsahující identifikátor RFID čipu přiřazeného uživateli **BWC** – Body – Worn Camera – osobní kamera nošená strážníkem **AIS** – Agendový informační systém MP Brno, kde strážník přiřazuje záznamy k jednotlivým událostem **AD –** Active Directory – adresářová služba MP Brno pro správu identit a autentizaci uživatelů

1. **Logická architektura řešení**

Systém se skládá z následujících logických komponent, které musí spolu s dodávanými kamerami a dokovacími stanicemi tvořit funkční, otestovaný a zadavatelem akceptovaný celek: serverová aplikace provozovaná on – premises v datovém centru zadavatele (virtuální prostředí VMware vSphere). databázová vrstva ukládající metadata, konfiguraci, stavy zařízení, audit log a referenční data uživatelů synchronizovaná z AD, úložiště videozáznamů realizované jako síťový fileshare (Windows Server, protokol SMB 3.x), nasazený a spravovaný zadavatelem. Dodavatel musí zajistit plnou kompatibilitu systému s tímto úložištěm, webové uživatelské rozhraní (dále jen „Web GUI") pro strážníky, dozorčí směn, auditory a administrátory, Rozhraní pro integraci s AIS pro otevření UNC cesty k záznamům konkrétního uživatele, software dokovacích stanic zajišťující přenos záznamů z kamery do úložiště a hlášení stavů do serverové části, modul identifikace uživatele pomocí RFID čipu komunikace s dokovací stanicí, resp. přidělovací jednotkou,

**3.1 Referenční datový a procesní tok**

Životní cyklus záznamu:

**Přidělení kamery:** Strážník před nástupem do služby přiloží RFID čip k čtečce u přidělovací/dokovací stanice. Systém na základě hodnoty čipu (přečtené přes RFID) vyhledá

Page 4

v AD uživatele s odpovídající hodnotou atributu cardID, ověří oprávnění a přidělí mu konkrétní kameru (uvolní ji z dokovací stanice a světelnou nebo zvukovou signalizací ji indikuje).

**Pořizování záznamu:** Strážník v průběhu služby pořizuje záznamy. Spojení kamera–uživatel je po celou dobu služby jednoznačně evidováno.

**Návrat a upload:** Po skončení služby strážník zasune kameru do dokovací stanice. Dokovací stanice automaticky zahájí přenos záznamů do síťového fileshare. Záznamy jsou uloženy do složky konkrétního uživatele (podle sAMAccountName / userPrincipalName z AD).

**Evidence v AIS:** Strážník v AIS u konkrétní události klikne na odkaz „Přidat záznam"; AIS volá otevření UNC cesty v Průzkumníku Windows a zpřístupní složku s videi daného strážníka, ze které uživatel vybraný soubor přiřadí k události. Záznam je po úspěšném zkopírovaní z úložiště automaticky odstraněn.

1. **Funkční požadavky**

**4.1 Přidělení kamery přes RFID**

Doba odezvy od přiložení čipu do uvolnění kamery NESMÍ přesáhnout 3 sekundy při standardním zatížení systému. Systém musí podporovat režim „jeden strážník – libovolná volná kamera". Systém musí signalizovat přidělenou kameru vizuálně (LED) a/nebo akusticky na stanici a současně ve Web GUI u operátora/dozorčího směny. Při neznámém čipu (cardID nenalezeno v AD) nebo u uživatele bez oprávnění musí systém přidělení odmítnout a událost zaznamenat do audit logu. Systém musí párovat RFID → uživatele na základě atributu cardID v Active Directory (bez nutnosti udržovat duplicitní registr čipů). Systém musí podporovat přidělení konkrétní kamery uživateli na základě přiložení jeho RFID čipu ke čtečce u přidělovací/dokovací stanice.

**4.2 Dokování a upload záznamů**

Systém musí poskytovat provozní metriky dokovací stanice (obsazenost slotů, stav nabíjení, probíhající přenosy, chyby) a předávat je do Web GUI a syslog/SIEM. Systém musí evidovat u každého záznamu min.: identifikátor záznamu, identifikátor kamery, identifikátor přiděleného uživatele (AD), datum/čas začátku a konce záznamu, délku, velikost, hash, datum/čas uploadu.

Page 5

Po úspěšném přenosu musí být provedeno ověření integrity (hash) souboru proti zdroji v kameře. Záznam v kameře smí být smazán až po úspěšném ověření. Přenos musí být zabezpečený a odolný vůči výpadku sítě – při přerušení pokračuje od posledního úspěšně přeneseného bloku. Po zasunutí kamery do dokovací stanice musí systém automaticky, bez zásahu uživatele, zahájit přenos všech nestažených záznamů do síťového fileshare.

**4.3 Struktura úložiště a adresářové členění**

Síťový fileshare je nasazen a spravován zadavatelem. Cílová struktura v síťovém fileshare musí být následující (konkrétní UNC cesta k sdílení je předmětem konfigurace při implementaci): \\\\\<server\>\\\<share\>\\\<sAMAccountName\>\\\<YYYY\>\\\<MM\>\\\<DD\>\\\<camID\>_\<timestamp\>. \<ext\> Systém musí podporovat SMB protokol verze minimálně 3.0 a komunikaci přes Kerberos (nikoliv NTLMv1/v2) pod dedikovaným service accountem s nejmenšími možnými oprávněními. Zadavatel zajistí konfiguraci fileshare pro SMB 3.x a Kerberos autentizaci dle požadavků dodavatele. Názvy souborů musí obsahovat identifikátor kamery a časové razítko začátku záznamu ve formátu RRRRMMDD_HHMMSS a musí umožňovat jednoznačnou identifikaci bez metadat. Systém musí podporovat konfigurovatelnou strukturu podsložek podle data (např. RRRR/MM/DD) a volitelně podle kamery. Na uživatelskou složku musí být automaticky nastaveny NTFS ACL tak, aby do ní měl přístup daný uživatel (R), členové definovaných AD skupin dozorčí/supervisor (R), auditor (R) a service account DEMS (modify). Ostatním NESMÍ být přístup povolen. Kořenová složka uživatele musí být pojmenována podle atributu sAMAccountName (nebo jiného jednoznačného AD atributu dle konfigurace) a musí vzniknout automaticky při prvním uploadu záznamů tohoto uživatele.

**4.4 Integrace s Active Directory**

Při deaktivaci účtu v AD musí systém okamžitě odepřít přístup do Web GUI a zablokovat další přidělování kamer danému uživateli; existující záznamy a přiřazení zůstávají beze změny. Systém musí podporovat více doménové prostředí a strukturu organizačních jednotek (OU) odpovídající členění MP Brno (služebny / revíry). Synchronizace změn z AD (přidání/odebrání uživatele, změna cardID, členství ve skupině) musí proběhnout do 15 minut od změny v AD a musí běžet i v plánovaném denním plném synchronizačním cyklu. Role musí být mapovány na AD skupiny. Mapování musí být konfigurovatelné bez zásahu dodavatele.

Page 6

Systém musí číst z AD min. atributy: sAMAccountName, userPrincipalName, displayName, mail, cardID (nebo jiný zadavatelem určený atribut pro RFID), memberOf. Autentizace uživatelů do Web GUI musí probíhat proti AD pomocí protokolu LDAPS nebo Kerberos (SSO, integrovaná autentizace Windows).

**4.5 Integrace s AIS**

Integrace s agendovým informačním systémem MP Brno bude realizována prostřednictvím funkcionalit dodaného systému a AIS. Po vrácení kamery do dokovací stanice se spustí kopírování záznamů do home adresáře strážníka. Jakmile se záznamy zkopírují všechny, dodaný systém v adresáři vytvoří .txt soubor, ve kterém budou informace o dokončení operace. AIS po přihlášení strážníka zkontroluje stav kopírování záznamů a otevře rozhraní pro import videozáznamů. V tomto rozhraní bude k dispozici seznam čísel jednacích se základním popisem a dále seznam video souborů dostupných na základě UNC cesty uživatele. Následně strážník metodou drag & drop přiřadí vybrané videozáznamy k odpovídajícím událostem v AIS. AIS následně předá videozáznamy ke zpracování komprimační službě.

**4.5.1 Otevření UNC cesty z AIS**

Přístup k UNC cestě musí být řízen výhradně NTFS/SMB oprávněními odvozenými z AD – nikoliv sdíleným heslem nebo lokálním účtem. Zavoláním z AIS musí otevřít standardní okno Průzkumníka Windows na příslušné UNC cestě (např. explorer.exe /e,"\\\\server\\share\\novak"); způsob otevření (URL handler, helper utility, ClickOnce apod.) navrhne dodavatel a odsouhlasí si ho se zadavatelem a dodavatelem AIS. Systém musí poskytnout AIS endpoint / funkci, kterým AIS pro daného uživatele získá UNC cestu ke složce obsahující jeho stažené záznamy (typicky \\\\server\\share\\sAMAccountName\), případně filtr na období.

**4.6 Web GUI a rolový model (RBAC)**

Všechny akce ve Web GUI (přihlášení, přehrání, stažení, export, změna metadat, uzamčení/odemčení) musí generovat záznam v audit logu. Web GUI musí umožnit export záznamu (stažení souboru) s auditním záznamem a volitelnou doplňkovou metadatovou kartou (PDF) obsahující hash, čas, uživatele, kameru a důvod exportu. Export musí být dostupný pouze rolím oprávněným dle konfigurace.

Page 7

Systém musí implementovat RBAC s minimálně rolemi: strážník (vidí jen vlastní záznamy), dozorčí směny (vidí záznamy podřízené směny), supervisor (služebna), administrátor (konfigurace), auditor (read – only + audit log). Role musí být mapovány na AD skupiny. Web GUI musí umožnit online přehrávání videa včetně posunu časové osy bez nutnosti stahovat celý soubor lokálně. Web GUI musí umožnit vyhledávání a filtrování záznamů podle:

- uživatele, kamery, období, služebny (AD OU), příznaku „přiřazeno k události", stavu uploadu, hash. Web GUI musí být plně lokalizováno do českého jazyka (rozhraní i systémové hlášky). Web GUI musí být dostupné přes prohlížeč Microsoft Edge (Chromium) a Google Chrome v aktuální a předchozí major verzi;

- bez nutnosti instalace tlustého klienta.

**4.7 Audit log**

Metadata záznamu musí být při každé změně (např. přiřazení k události) verzována – předchozí stav lze auditně zrekonstruovat. Systém musí umožnit export audit logu do SIEM zadavatele přes syslog (RFC 5424) nebo ekvivalentní zabezpečený kanál (TLS). Audit log musí být chráněn proti úpravám a mazání i privilegovanými uživateli (včetně lokálního administrátora serveru) – technickou realizaci (např. podepisování, hash chain,) popíše dodavatel v nabídce. Záznam v audit logu musí obsahovat minimálně: časové razítko (NTP synchronizované, s přesností na sekundu), identifikátor uživatele (AD), IP adresu, typ akce, cílový objekt, výsledek (úspěch/selhání). Systém musí vést neoddělitelný audit log všech administrativních i uživatelských akcí (přihlášení, přehrání, stažení, přiřazení k události, skartace, změny konfigurace, pokusy o přístup bez oprávnění).

**4.8 Retence a řízená skartace záznamů**

Retenční pravidla nesmí být pevně zakódována; musí být konfigurovatelná ve Web GUI osobou s rolí administrátora a musí splňovat minimálně tyto základní požadavky zadavatele: Systém musí umožnit reporting – počet záznamů po jednotlivých stavech retence, nadcházející skartace, legal hold – a tento report generovat minimálně jednou denně. Skartace musí proběhnout způsobem, který znemožňuje rekonstrukci dat běžnými forenzními prostředky (bezpečné mazání / overwrite, event. crypto – shred, pokud je úložiště šifrované na úrovni objektu). Systém musí umožnit individuální prodloužení retence konkrétního záznamu (tzv. legal hold) rolí supervisor/administrátor s povinným zadáním důvodu. Před plánovanou skartací musí systém generovat skartační protokol (kdo, co, kdy) a uložit ho do audit logu; protokol musí být auditovatelný.

Page 8

1. **Ostatní požadavky**

**5.1 Provozní prostředí**

Systém musí podporovat provoz v plně oddělené síti MP Brno bez přístupu do veřejného internetu; aktualizace musí být dodávány offline (instalační balíček). Databáze musí být buď (a) MS SQL Server verze podporované zadavatelem, nebo (b) open – source DB (PostgreSQL) – v obou případech bez doplatku za runtime licenci. Dodavatel musí v nabídce uvést minimální HW požadavky (v CPU, RAM, disk – OS/DB/cache) pro všechny komponenty při cílovém dimenzování (viz 5.2). Dodavatel musí dodat aplikaci vč. detailního instalačního postupu pro Windows Server / Linux, který umožní zadavateli vlastní instalaci ve vSphere. Serverová část musí být dodána jako on – premise řešení provozované ve virtualizační platformě zadavatele VMware vSphere (verze 7.x nebo vyšší). Cloudové řešení (SaaS) NENÍ přípustné.

**5.2 Výkon, kapacita, dostupnost**

Systém musí být horizontálně nebo vertikálně škálovatelný bez nutnosti reinstalace při navýšení počtu kamer/uživatelů. RPO pro metadata a audit log musí být max. 1 hodina, RTO max. 4 hodiny. Videosoubory uložené na fileshare musí být zálohovány zálohovacím SW zadavatele – dodavatel popíše kompatibilní postup. Dostupnost služby (DEMS jako celek mimo plánované odstávky) musí být min. 99 % v rámci kalendářního měsíce, měřeno na úrovni Web GUI. Systém musí zvládnout současný upload min. 30 kamer z různých dokovacích stanic, aniž by se response time API nebo Web GUI zvýšil nad 2s. Systém musí být dimenzován pro minimálně 300 aktivních strážníků MP Brno. Počet kamer se neprovazuje 1:1 s uživateli (sdílení ve směnách) – dodavatel v nabídce navrhne sizing pro dodaný počet kamer dle HW části.

**5.3 Bezpečnost a soulad**

Dodavatel musí deklarovat a po dobu podpory dodržet proces řízení zranitelností – reakci na kritické CVE do 7 kalendářních dnů, vydání patche nebo kompenzačního opatření do 30 kalendářních dnů. Dodavatel musí umožnit provedení penetračního testu a bezpečnostního auditu zadavatelem (nebo jím pověřenou třetí stranou) bez dopadu na záruku. Systém musí podporovat integraci s SIEM zadavatele (syslog, příp. CEF) a zasílat tam bezpečnostně relevantní události (neúspěšné přihlášení, změny oprávnění, skartace, pokusy o přístup do cizí složky).

Page 9

Hesla a tajné klíče (service účty, client_secret OAuth) NESMÍ být uloženy v čitelné podobě; doporučeno je využití Windows Credential Store / Group Managed Ser nebo obdobného bezpečného úložiště. Veškerá komunikace mezi komponentami (kamera/dock AIS, prohlížeč ↔ server) musí být šifrována (TLS 1.2 a vy Řešení musí respektovat zákon č. 181/2014 Sb., 82/2018 Sb., v platném znění (logování, řízení přístupu, správa zranitelností, aktualizace). Řešení musí být v souladu s Nařízením GDPR a zákonem č. 110/2019 Sb., o zpracování osobních údajů, včetně záznamu o činnostech zpracování, práva subjektu údajů a bezpečnosti zpracování.

**5.4 Instalace, monitoring, zálohování**

Dodavatel musí specifikovat, co a jak zálohovat, a výsledek musí být obnovitelný bez součinnosti dodavatele (DR drill jako součást akceptace). Systém musí poskytovat health – check endpoint pro monitoring zadavatele (typicky Zabbix / PRTG) a exportovat metriky (např. Prometheus / WMI / SNMP). Dodavatel musí poskytnout skripty / postupy pro automatizovanou instalaci a upgrade komponent.

1. **Integrační rozhraní – souhrn**

vice Account (gMSA) ↔ server, server ↔ šší, SMB 3.x). o kybernetické bezpečnosti, a vyhlášku č. AD, server ↔

**6.1 Přehled rozhraní**

Zálohovací SW zadavatele – dodavatele) Monitoring (SNMP/HTTP) SIEM (syslog/CEF) – Audit log a AIS – UNC handler – Otevření Průzkumníka Windows na složce daného uživatele Fileshare (SMB 3.x, provozovaný zadavatelem) – Dokovací stanice (HW) – Přenos videa kamera části RFID čtečka (dock) – Identifikace uživatele při přidělování kamery AD (LDAP/LDAPS, Kerberos) uživatel Zálohování DB, audit logu a konfigurace (doporučený postup od

- Health –

- check, metriky výkonu a stavu zařízení bezpečnostní události Úložiště videosouborů, NTFS ACL dle AD → fileshare, hlášení stavů, dle specifikace HW Čtení uživatelů a skupin, SSO do Web GUI, překlad RFID →

Page 10

1. **Dokumentace, školení, záruka a podpora**

Dodavatel musí v nabídce popsat eskalační matici a kontaktní kanály (mail, HelpDesk portál, telefon, popř. ServiceNow webhook). Dodavatel musí poskytovat minoritní a majoritní upgrade po dobu podpory (včetně bezpečnostních patchů) bez dodatečných nákladů. Dodavatel musí nabídnout pozáruční podporu (maintenance) na min. 5 let s reakční dobou: kritická vada – 4 hod (24/7), vysoká – NBD (business hours), ostatní – 5 BD. Podrobný SLA bude součástí smlouvy. Dodavatel musí poskytnout záruku v délce min. 24 měsíců od akceptace, pokrývající odstranění vad, bezpečnostních chyb a nekompatibility s dodaným HW. Dodavatel musí zajistit školení - 2× skupina administrátorů (min. 8 hod), Dodavatel musí dodat v českém jazyce: administrátorskou příručku, uživatelskou příručku pro strážníka a dozorčího, instalační a provozní dokumentaci, integrační příručku (AD, AIS, SIEM).

1. **Akceptační kritéria**

Plnění bude akceptováno po úspěšném provedení níže uvedených testů (výčet je minimální, dodavatel MÁ PRÁVO navrhnout další): End – to – end test přidělení kamery RFID čipem – úspěšné přidělení, kontrola záznamu v audit logu a signalizace ve Web GUI. Test paralelního dokování a uploadu 30 kamer – ověření integrity (hash), vytvoření správných složek dle sAMAccountName, nastavení NTFS ACL. Test integrace s AIS – volání API (přiřazení záznamu k události), prodloužení retence, zablokování automatického mazání. Test otevření UNC cesty z AIS – kliknutí otevře Průzkumníka Windows na správnou složku, přístup je dán AD oprávněními. Test retence – běžný záznam se po 14 dnech automaticky smaže, událostní zůstane, vygeneruje se skartační protokol. Test deaktivace uživatele v AD – okamžitý dopad na Web GUI a přidělování kamer.

Page 11

**Specifikace KAMERA typ Kamery VELKÉ provedení –**

úhel záběru horizontálně úhel záběru vertikálně Citlivost rozlišení – nastavitelně minimálně v těchto úrovních fps

**VELKÁ (41 ks):**

**pro jednotky používající taktickou vestu**

min 135 úhlových stupňů min 75 úhlových stupňů min 0,1 LUX 1920 x 1080 a 1280 x 720 min 25fps/50 Hz WDR Elektronický stabilizátor obrazu ANO ANO (EIS /720 p) /korekce soudkovitosti Mikrofon ANO Audio min 48KHz. 128 kbps Krytí min IP67 Stanby mode Doba záznamu do přepisu s kryptováním Kryptování záznamu Prealarm VIDEO nastavitelné Prealarm AUDIO nastavitelné min 24 hod min 24 hod ANO min rozsah: 0–120 sec min rozsah: 0–120 sec

| Výdrž při rozlišení 720 p s aktivovaným prealarmem | min | 14 hod |
| --- | --- | --- |
| Výdrž při rozlišení 1080 p s aktivovaným prealarmem | min | 13 hod |

| Tok dat mezi kamerou a systémem při |  | 100Mbit/sec (pozn.: mezi kamerou a prvním HW |
| --- | --- | --- |
| zadokováním | min | prvkem systému) |

|  |  | ANO – GPS, GLONASS, GALILEO (všechny |
| --- | --- | --- |
| Satelitní určování polohy |  | systémy) |
| Senzory |  | 3-osy gyroskop, akcelerometr |

Page 12

Uživatelský interface Provozní teploty okolí Spuštění vice kamer prostřednictvím jedné kamery Hmotnost Rozměry v x š x h Aktivace nahrávání – tlačítkem Systém uchycení Barevné provedení min statusové indikátory, audio, vibrace min rozsah: -20 - +50 °C ANO (venkovní prostory – překážek min 10 m) max 180 g – bez držáku/klipu max 95 x 70 x 30 (mm) umístěno na přední stěně a zabírá min. celkové čelní plochy Klick Fast Systém + úchyt na takticku vestu dle nabídky Tmavé barvy (černá, tmavě šedá, tmavě modrá) vzdálenost bez 15 %

**Specifikace KAMERA typ malá (181 ks):**

**Kamery MALÉ provedení –**

úhel záběru horizontálně úhel záběru vertikálně Citlivost rozlišení – nastavitelně minimálně v těchto úrovních fps

**pro org. celky používající běžnou výstroj**

min 110 úhlových stupňů min 60 úhlových stupňů min 0,1 LUX 1920 x 1080 a 1280 x 720 min 25fps/50 Hz WDR Elektronický stabilizátor obrazu Mikrofon ANO ANO (EIS /720 p) / korekce soudkovitosti ANO

| Audio | min | 48KHz. 128 kbps |  |
| --- | --- | --- | --- |
| Krytí | min | IP54 |  |

Page 13

| Výdrž při rozlišení 720 p s aktivovaným prealarmem | min | 9,5 hod |
| --- | --- | --- |
| Výdrž při rozlišení 1080 p s aktivovaným prealarmem | min | 8 hod |

Stanby mode Doba záznamu do přepisu s kryptováním Kryptování záznamu Prealarm VIDEO nastavitelné Prealarm AUDIO nastavitelné Satelitní určování polohy Senzory Uživatelský interface Provozní teploty okolí Spuštění vice kamer prostřednictvím jedné kamery Hmotnost Rozměry v x š x h Aktivace nahrávání – tlačítkem min 16 hod min 24 hod ANO min rozsah: 0–120 sec min rozsah: 0–120 sec není podmínkou 3-osy gyroskop, akcelerometr min statusové indikátory, audio, vibrace min rozsah: -20 - +40 °C NE max 100 g – bez držáku/klipu max 85 x 55 x 20 (mm) ANO

| Tok dat mezi kamerou a systémem při |  | 100Mbit/sec (pozn.: mezi kamerou a prvním |
| --- | --- | --- |
| zadokování | min | HW prvkem systému) |

| systém uchycení |  | úchyt na oděv dle nabídky |
| --- | --- | --- |
| Barevné provedení |  | Tmavé barvy (černá, tmavě šedá, tmavě modrá) |

Page 14

**Počty budov a organizačních celků pro stanovení technologických prvků a kamer:**

| budova | org. celek | velké kamery (ks) | malé kamery (ks) | pozn. |
| --- | --- | --- | --- | --- |
| Křenová 4 | Jednotka dopravní |  | 35 |  |
| Křenová 4 | Revír – Střed |  | 30 |  |
| Nováčkova 16 | Revír – Sever |  | 15 |  |
| Kovárenská 1 | Revír – Jih |  | 15 |  |
| Velkopavlovická 25 | Revír – Východ |  | 15 |  |
| Medlánecká 29 | Revír – Pole |  | 15 |  |
| Horova 28 | Revír – Tábor |  | 15 |  |
| Labská 9 | Revír – Západ |  | 15 |  |
| Labská 9 | Jednotka pořádková | 35 |  |  |
| Nám. 28.dubna 61 | Revír – Bystrc |  | 15 |  |
| Přístavní 40 | Jednotka poříční |  | 6 |  |
| Kaštanová 34 | Jednotka psovodů | 5 |  |  |
| Palcary 50 | Odchytová služba | 1 |  | Detašované pracoviště Jednotka psovodů |
| Štefánikova 43 | Ředitelství MP Brno |  | 5 |  |
|  | celkem | 41 | 181 |  |

Počet budov: 12 Počet pracovišť: 14

Hmotnost malé kamery do: 100 g bez klipu Hmotnost velké kamery do: 180 g bez klipu

**Další požadavky:**

Page 15

1. Bude provedeno 14 denní testování v provozu, přičemž od každého typu kamery budou k dispozici 2 kusy včetně veškerého potřebného příslušenství. Uchazeči mohou nabídnout variantní typy klipů k jednotlivým kamerám, které však nebudou mít vliv na nabídkovou cenu. Instalace bude provedena včetně potřebné infrastruktury, aby bylo možno ověřit kompletní využití systému dle zadání, celcích MP Brno. Přípravné období na spuštění testování 14 dní.

1. Budou vyčísleny **licenční náklady,** na provoz systému let po jednotlivých letech, které musí provozovatel hradit pro zajištění funkčnosti systému.

1. Budou dodány dokovací stanice na jednotlivé organizační celky tak, aby bylo možno nabíjet současně 100 % dodaných kamer

1. Nad rámec potřebných dokovacích stanic bude dodáno jako náhradní díl 2 kusy od každého typu – dle faktické skutečnosti podle toho, kolik pozic (bude součástí nabídkové ceny viz položka č. 7 kompletní funkční HW systém dle ZD a jejích příloh řádcích 2 a 4 tabulky).

1. Členění cenové nabídky:

**Předmět Nabídková cena v Sazba Kč bez DPH DPH v %**

1. **Cena za 1 ks včetně veškerého požadovaného příslušenství kamera TYP VELKÁ**

1. **Cena za 41 ks včetně veškerého požadovaného příslušenství kamera TYP VELKÁ**

1. **Cena za 1 ks včetně veškerého požadovaného příslušenství kamera TYP MALÁ**

1. **Cena za 181 ks včetně veškerého požadovaného příslušenství kamera TYP MALÁ**

1. **Cena za 41 ks kamera TYP VELKÁ a 181 ks kamera TYP MALÁ včetně veškerého požadovaného příslušenství (∑ řádků 2 a 4)**

a to na dvou organizačních na dobu 5-ti po sobě jdoucích bude mít dokovací stanice níže uvedené tabulky, tj. cena za mimo položek uvedených v

**Samostatně DPH v Kč Nabídková cena v Kč s DPH**

Page 16

1. **Cena za kompletní SW dle ZD a jejích příloh**

1. **Cena za kompletní funkční HW systém dle ZD a jejích příloh mimo položek uvedených v řádcích 2 a 4**

1. **Cena za licence po dobu 24 měsíců, tj. po dobu předpokládané záruky**

1. **Cena za licence na dobu 5-ti let po skončení prvotní licence**

1. **Cena za práce za celé plnění dle ZD a jejích příloh**

1. **Celková nabídková cena (∑ řádků 2, 4, 6-8, 10) Nabízený typ KAMERA TYP VELKÁ Nabízený typ KAMERA TYP MALÁ**

*Pozn.: Nabídková cena uvedená v nabídce musí zahrnovat veškeré náklady související s plněním předmětu této zakázky včetně dopravy do místa plnění – budovy MP Brno dle rozpisu. Součástí sjednané ceny jsou veškeré poplatky a náklady dodavatele nezbytné pro řádné a úplné plnění zakázky. Další náklady již k nabídkové ceně nebudou účtovány.* 6) Systém bude kompletně nainstalován a uveden do provozu dodavatelem v koordinaci se zadavatelem.

1. Předpokládaná částka 4 650 000,- Kč vč. DPH činí součet položek č. 2, 4, 6-8, 10 nabídkové tabulky – viz výše a dále cena za licenci na dobu 5 let po skončení 24 měsíců ve výši 100.000,- Kč vč. DPH/5 let – řádek 9 tabulky.

**Celková předpokládaná hodnota** této zakázky tedy činí **4.750.000,-** Kč vč. DPH