PRÍSTUP K PROJEKTU

(Verzia dokumentu v1.01/07_2021)

Identifikovanie požiadaviek na technickú časť riešenia

Identifikácia projektu

Schvaľovanie dokumentu

OBSAH

1. POPIS ZMIEN DOKUMENTU.. 3

1.1         História zmien. 3

1. ÚČEL DOKUMENTU.. 4

2.1         Konvencie používané v dokumentoch – označovanie požiadaviek. 4

1. POPIS NAVRHOVANÉHO RIEŠENIA. 4
2. ARCHITEKTÚRA RIEŠENIA PROJEKTU.. 4

4.1         Biznis vrstva. 5

4.2         Aplikačná vrstva. 7

4.2.1      Rozsah informačných systémov. 7

4.2.2      Využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS). 9

4.2.3      Prehľad plánovaného využívania podporných spoločných blokov (SaaS). 10

4.2.4      Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky – spoločné moduly. 10

4.2.5      Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky - modul procesnej integrácie a integrácie údajov  (IS CSRÚ). 10

4.2.6      Poskytovanie údajov z ISVS do IS CSRÚ.. 10

4.2.7      Konzumovanie údajov z IS CSRU.. 11

4.3         Dátova vrstva. 12

4.3.1      Údaje v správe organizácie. 12

4.3.2      Dátový rozsah projektu. 12

4.3.3      Kvalita a čistenie údajov. 13

4.4         Referenčné údaje. 14

4.4.1      Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné. 14

4.4.2      Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU.. 15

4.5         Otvorené údaje. 15

4.6         Analytické údaje. 15

4.7         Moje údaje. 16

4.8         Prehľad jednotlivých kategórií údajov. 16

4.9         Technologická vrstva. 17

4.9.1      Prehľad technologického stavu. 17

4.9.2      Požiadavky na výkonnostné parametre, kapacitné požiadavky. 17

4.9.3      Návrh riešenia technologickej architektúry. 17

4.9.4      Využívanie služieb z katalógu  služieb vládneho cloudu. 18

4.9.5      Jazyková lokalizácia. 18

4.10       Bezpečnostná architektúra. 18

1. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY. 20
2. ZDROJOVÉ KÓDY. 20
3. PREVÁDZKA A ÚDRŽBA.. 20

7.1         Prevádzkové požiadavky. 20

7.1.1      Úrovne podpory používateľov: 20

7.2         Požadovaná dostupnosť IS: 22

7.2.1      Dostupnosť (Availability). 23

7.2.2      RTO (Recovery Time Objective). 23

7.2.3      RPO (Recovery Point Objective). 23

1. POŽIADAVKY NA PERSONÁL. 24
2. IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU. 24
3. PRÍLOHY. 24 

1.     POPIS ZMIEN DOKUMENTU

1.1         História zmien

2.     ÚČEL DOKUMENTU

V súlade s Vyhláškou 85/2020 Z.z. o riadení projektov predstavuje dokument Projektový zámer v rámci iniciačnej fázy rozpracovanie detailných informácií prípravy projektu “Moderné technológie v TSK”.

2.1         Konvencie používané v dokumentoch – označovanie požiadaviek

Architektúrne požiadavky používajú konvenciu:

Napr.

A_AB_Oxx

• A – architektúrna požiadavka
• AB – označenie systému  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

Infraštruktúrne požiadavky používajú konvenciu:

Napr.

IP_nn_ORxx

• IP – infraštruktúrna požiadavka
• nn – identifikácia  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

3.     POPIS NAVRHOVANÉHO RIEŠENIA

Predkladaný projekt je zameraný na využitie smart technológií v prostredí TSK. Cieľom projektu je vybudovanie integračnej platformy, získavanie údajov z externých senzorov a zariadení, ich vzájomné prepojenie, analýza údajov a podpora rozhodovania pre tvorbu a/alebo reguláciu politík TSK vrátane poskytovania údajov koncovým používateľom s cieľom efektívneho nakladania s verejnými zdrojmi.

Špecifické ciele:

7.4 Zvýšenie kvality, štandardu a dostupnosti eGovernment služieb pre občanov

Typ aktivity:   E. Podpora budovania inteligentných miest a regiónov

Podaktivita:   E.1 Inteligentné systémy riadenia, monitorovania, prediktívnej údržby a prevencie

• inteligentné systémy na monitorovanie a manažment budov / smart energetický management budov,

7.5. Zlepšenie celkovej dostupnosti dát vo verejnej správe s dôrazom na otvorené údaje

Typ aktivity: H. Implementácia nástrojov pre zdieľanie, integráciu a riadenia kvality dát s dôrazom na otvorené dáta

Podaktivita: H.1: Identifikácia zdrojov otvorených dát a ich kvality (vrátane následného zverejnenia výstupných údajov spracovaných v užívateľskom formáte na internete/prostredníctvom emailu)

Podaktivita: H.2: Automatizácia procesov tvorby, zdieľania, integrácie a riadenia kvality dát s dôrazom na otvorené dáta

7.6  Zlepšenie digitálnych zručností a inklúzie znevýhodnených jednotlivcov do digitálneho trhu

Typ aktivity:   J. Zavedenie nástrojov pre podporu asistovaného života a telemedicíny

Podaktivita:   vo výzve nie je špecifická podaktivita definovaná

V aktuálnom stave TSK neráta so zapojením jednotlivých miest a obcí do projektu, avšak plánovaná integračná platforma bude budovaná škálovateľne a modulárne, ponúkne možnosti a rozhrania na zapojenie týchto subjektov v budúcnosti.

Predkladaný projekt je možné rozdeliť do troch tematických blokov:

• Energetický manažment budov v správe TSK

Merania dátových vstupov budú realizované IoT prvkami individuálne koncipovanými do setov vzhľadom na špecifiká jednotlivých budov. Takýmto špecifikom môže byť potreba podružného merania, alebo absencia plynovej prípojky. Štandardne však set pozostáva z nasledovných prvkov: 

1. vodomer/vodomer TÚV
2. plynomer
3. elektromer
4. kalorimeter
5. snímač externého prostredia (hydrometeorologické informácie)
6. snímače vnútorného prostredia (vzduchotechnika kvalita ovzdušia v budove a pohyb osôb)

Na prenos údajov do integračného komponentu  budú využívané moderné komunikačné siete ako LoraWan. Periódy merania a prenosu informácií do  platformy sú limitované výdržou batérií meračov, snímačov meteorologických údajov i snímačom parametrov vnútorného prostredia budov. Z uvedeného dôvodu budú jednotlivé prvky IoT individuálne administrovateľné a perióda odosielania údajov upraviteľná správcom integračného komponentu. Každý IoT prvok musí byť certifikovaný pre profesionálne použitie.

Riadiace systémy technických zariadení budov a ekosystém IoT prvkov by mali spĺňať nasledujúce požiadavky:
- sledovať poruchové a prevádzkové stavy a notifikovať o potrebe zásahu
- v reálnom čase komunikovať prostredníctvom bezdrôtových sietí
- snímať údaje o vnútornom a vonkajšom prostredí na rôznych miestach a prenášať ich do budovanej smart platformy
- byť flexibilné v prípade zmien (funkčné doplnenie)
- byť rozšíriteľné v prípade väčších nárokov (škálovateľnosť)
- mať možnosť integrovať zariadenia rôznych výrobcov do jedného systému (vzájomná kompatibilita)
- na najnižšej úrovni riadenia mať možnosť individuálne i skupinovo obojsmerne komunikovať
- byť programovateľné, na vyšších úrovniach riadenia mať možnosť meniť parametre regulačných slučiek
- mať možnosť adaptívneho samoučiaceho riadenia (doména integračného komponentu)
- vykazovať spoľahlivosť, bezpečnosť a servisnú dostupnosť
- cenovú optimálnosť

Meteorologické údaje zo snímačov externého prostredia umožnia presnejší výpočet dennostupňov pre vykurovanie a chladenie. Informácia o dennostupňoch spolu s informáciou o priemernej teplote vnútorného prostredia v referenčných miestnostiach nám poskytujú možnosť prepočtu skutočnej spotreby tepla na vykurovanie a spotreby chladu na chladenie v danom roku na dlhodobé podmienky.

• Monitoring mostov v správe TSK

Inteligentný monitoring zdravia mostov je komplexné riešenie, ktoré umožňuje merať životnú fázu a zdravotný stav mostu alebo mostnej konštrukcie za pomoci inštalácie senzorov na báze optovláknových meracích systémov na vonkajšiu alebo vnútornú konštrukciu. Táto technológia dokáže merať rôzne statické zmeny ako napr. záťaž, napätie a tlak na konštrukciu, dynamické vibrácie, stav a vývoj trhlín, priehyb a náklony nosníkov, teplotné zmeny a pomocou prediktívnej metódy predpovedať možný vývoj a správanie danej konštrukcie.

Všeobecne platí, že k oprave a k celkovej obnove mostov je lepšie pristúpiť v čase, keď je most ešte schopný prevádzky aj napriek známkam postupnej devastácie. Čiastočné obmedzenie dopravy na takomto moste v priebehu opravy je síce nepríjemné, ale oveľa prijateľnejšie ako kompletná uzávera mosta. Preto je v dnešnej dobe potrebné starostlivo sledovať stav mostov na komunikáciách s dôrazom na mosty, ktoré sú na hlavných dopravných trasách, a okamžite pristúpiť k opravám v prípade detekcie porúch resp. dôkladným sledovaním, takýmto poruchám predísť.

Ďalšiou výhodou monitorignu stavebných konštrukcií a mostov je výrazne zníženie nákladov, ak dokážeme predísť napríklad úplnemu uzavretiu mostov. Vyhnúť sa tejto udalosti dokážeme prevenentívným monitorovaním a plánovanou údržbou na základe nameraných dát. Vďaka včasnej analýze a vyhodnocovania stavu mostov je v budúcnosti možné sa lepšie pripraviť a náplanovať samotnú údržbu takejto konštrukcie. Dôkazom sú aj výroky samotných kontrolórov „Kontrolóri tvrdia, že príčinou je neúčinný systém ich rekonštrukcií, opráv a údržby.“

Dôkladnou analýzou stavu mostov dokážeme zamedziť úplnej uzávere takejto konštrukcie. Dôsledkom čoho by mohli vzniknúť dlhé obchádzky a zvýšením intenzity premávky najmä nákladnej dopravy sa zhorší stav ciest a mostov aj na obchádzkových trasách. Môžu byť taktiež ohrozené základné potreby obyvateľov v týchto oblastiach.

Preukázateľne dokážeme pomocou využívania monitorovacích zariadení, znížiť frekvenciu fyzickej kontroly stavebných konštrukcií, dokonca v niektorých prípadoch úplne vylúčiť a tým výrazne znížiť prevádzkové náklady konštrukcie.

• Telemedicína

Pre oblasť telemedicíny bude implementované riešenie zabezpečovať automatický zber dát  z mobilných zariadení vo forme zdravotníckych  náramkov, bude vyhodnocovať zozbierané dáta a sprostredkovávať výsledky meraní zdravotnickému personálu. Meranými dátami budú  vitálne funkcie pacientov, pričom by malo ísť minimálne o 4 funkcie - telesná teplota, hladina kyslíku v krvi - saturácia, krvný tlak, tep. Navrhované zariadenia sú certifikovanou zdravotníckou pomôckou a k pre ich implementáciu bolo vytipované interné oddelenie Nemocnice v Bojniciach, ktorá je súčasťou siete regionálnych poskytovateľov zdravotnej starostlivosti TSK.

Predmetom projektu bude teda riešenie, ktoré bude nezávislé na nemocničnom informačnom systéme, a bude pozostávať z týchto častí:

•         mobilné zariadenie - zdravotnícky náramok  so senzormi umožňujúcimi „kontinuálny“ zber dat
•         technologické riešenie (HW brány) pre zaistenie  komunikácie medzi náramkom a modulom telemedicíny, tj. predovšetkým zber dát z náramkov  a  ich prenos do databázy modulu telemedicíny
•    modul telemedicína, ktorý zahrňuje
• databázu pre zber dát
•             web aplikáciu pre administráciu portálu modulu telemedicíny,, vyhodnotenie dat, dohľadové a notifikačné
• centrum
• komunikačné (API) rozhranie medzi prístupovými bránami, nemocničným informačným systémom a SMS/e-mail bránami
•         monitory pre dohľadové centrá (DC) na vybraných oddeleniach nemocnice

4.     ARCHITEKTÚRA RIEŠENIA PROJEKTU

Pre popis architektúry predmetného dopytového projektu bol zvolený sumárny náhľad architektúry pre biznis, aplikačnú a technologickú vrstvu, ktoré sú popísané v rámci jednotlivých podkapitol.

4.1         Biznis vrstva

Nakoľko je predmetom projektu vybudovanie Integračného komponentu a jeho modulov, v súčasnom stave takéto aplikačné vybavenie nie je v správe TSK. Jednotlivé procesy, funkcie a kompetencie sú realizované analógovo alebo bez špeciálnej IT podpory. 

Z pohľadu budúceho stavu biznis vrstvy architektúry boli identifikované 3 kategórie používateľov: zamestnanec TSK, zamestnanec OVM alebo OvZP, občan alebo podnikateľ. Z pohľadu prístupu k systému títo vystupujú v roli konzumenta údajov alebo používateľa integračnej platformy. Analogicky sú dátové výstupy z uvedenej platformy dostupné buď prostredníctvom webrozhrania tenkého klienta alebo v podobe štatistických údajov publikovaných na webovom sídle TSK, resp. v prenesenom význame na data.gov.sk. Výstupom projektu nebudú koncové služby pre G2B/G2C. Integračný komponent a jeho analytika je vnímaná ako funkcionalita typu G2E/G2G. Všetky biznis oblasti dotknuté projektom sú reprezentované tematickými biznis funkciami agregujúcimi jednotlivé funkcionality modulov. V prípade energetického manažmentu sa jedná o funkciu zberu a monitoring energetických a prevádzkových údajov, automatizovane a pravidelne s analytikou nad získanými dátami s dôrazom na konzistenciu spotreby, upozornenia na neočakávané udalosti a získanie údajov pre komplexný energetický manažment napr. v podobe znižovania spotreby alebo zmeny dodávateľských vzťahov. Funkcionalita zberu údajov o mostnej infraštruktúre reprezentuje systematický proces získavania relevantných prevádzkových údajov s cieľom dosiahnuť optimalizáciu údržby, predĺženie životnosti mostného telesa a správu infraštruktúry na základe overiteľných údajov. Funkcionalita telemedicíny reprezentuje proces automatizovaného digitálneho merania vitálnych funkcií pacienta s cieľom získať tieto údaje bezkontaktne, bez osobnej interakcie medzi zdravotníckym personálom a pacientom a následným prepisom získaných údajov z analógovej do digitálnej podoby.

Tabuľka č.1 Prehľad koncových služieb, ktoré budú výstupom projektu

4.2      Aplikačná vrstva

Na úrovni aplikačnej vrstvy architektúry je kľúčovým prvkom Integračný komponent (isvs_11174), ktorý pozostáva z nezávislých tematických modulov Telemedicína, Mosty a Energetický manažment reprezentovaných biznis funkciami na úrovni nadradenej biznis architektúry. Dátové zdroje týchto modulov sú aplikačne spracovávané a vizualizované prostredníctvom portálového rozhrania Integračného komponentu a prístup k údajom je diferencovanými podľa špecifických používateľských práv pre daný modul. Pre zabezpečenie interoperability Integračného komponentu bude tento disponovať aj OPEN API rozhraním pre pripojenie tretích strán. Požiadavkou na riešenie je dynamická škálovateľnosť z pohľadu dopĺňania nových modulov alebo aj používateľov systémov.

Aplikačná vrstva bude získavať a spracovávať informácie z IoT prvkov umiestnených v úvodnej fáze projektu. Dátový tok IoT prvkov smeruje prostredníctvom jednotlivých modulov do Integračnej platformy prostredníctvom aplikačnej služby Spracovanie údajov. Integračný komponent v tomto zmysle zabezpečuje:

• Príjem dát z interných a externých IS – funkcionalita ako vstupná API brána zabezpečí príjem prichádzajúcich správ resp. údajov z interných systémov (prípadne externých systémov v budúcnosti);

• Poskytovanie dát - funkcionalita ako výstupná API brána zabezpečí poskytovanie dát;

• Distribúcia dát – funkcionalita bude realizovať odovzdávanie dát do interných databáz na ďalšie spracovanie dát, umožní riadenie naplánovaných úloh;

• Manažment rozhraní – funkcionalita umožní riadiť prístupy k dátovým rozhraniam a dátovým sadám.

• Príjem dát – funkcionalita umožní prijať dáta z centrálnej údajovej základne na ďalšie spracovanie resp. validáciu;

• Spracovanie a validácia dát – funkcionalita umožní prijaté dáta validovať, spracovať a uložiť do údajovej základne;

• Analytické nástroje– funkcionalita zabezpečí analytické spracovanie validovaných a uložených dát a vytváranie reportov a pohľadov na získané a spracované dáta.

• Vizualizácia dát – funkcionalita poskytne nástroje pre náhľad nad zozbieranými dátami pre dashboard a vizualizáciu pomocou geolokačných dát;

• Tvorba reportov – funkcionalita umožní tvorbu reportov zo spracovaných a zanalyzovaných dát, umožní poskytovať rôzne prehľady, zostavy a štatistiky z dát vrátane historických dát. Reporty bude možné distribuovať na základe nastavených prístupových práv;

• Export dát – funkcionalita umožní vytvoriť export, alebo nastaviť pravidelné exporty dát z/do úložiska;

• Manažment prístupov a identít – funkcionalita bude realizovať riadené prístupov k nástrojov a zdrojom podľa pravidiel definovaných pomocou rolí

4.2.1       Rozsah informačných systémov

Tabuľka č.2 Prehľad dotknutých informačných systémov v projekte – súčasný stav

Tabuľka č. 3 Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav

Tabuľka č.4 Prehľad budovaných aplikačných služieb – budúci stav

4.2.2       Využívanie nadrezortných centrálnych blokov a podporných spoločných blokov (SaaS)

V rámci projektu sa vzhľadom na charakter predkladaného projektu nepredpokladá využívanie nadrezortných centrálnych blokov a podporných spoločných modulov

Tabuľka č.5 Prehľad integrácii ISVS na nadrezortné centrálne bloky – súčasný stav

4.2.3       Prehľad plánovaného využívania podporných spoločných blokov (SaaS)

V rámci projektu sa vzhľadom na charakter predkladaného projektu nepredpokladá využívanie podporných spoločných blokov

Tabuľka č.6 Prehľad integrácii ISVS na podporné spoločné bloky (SaaS) – budúci stav

4.2.4       Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky – spoločné moduly

V rámci projektu sa vzhľadom na charakter predkladaného projektu nepredpokladajú integárcie na nadrezortné centrálne bloky

Tabuľka č.7 Prehľad integrácii ISVS na spoločné moduly – budúci stav

4.2.5       Prehľad plánovaných integrácií ISVS na nadrezortné centrálne bloky - modul procesnej integrácie a integrácie údajov  (IS CSRÚ)

Vzhľadom na rozsah a charakter projektu neboli identifikované vhodné integrácie na nadrezortné centrálne bloky - IS CSRU.

Tabuľka č.8  Prehľad integračných väzieb medzi ISVS a IS CSRÚ – budúci stav

4.2.6       Poskytovanie údajov z ISVS do IS CSRÚ

Vzhľadom na rozsah a charakter projektu neboli identifikované údaje vhodné na poskytovanie do IS CSRU. Údaje budú poskytované iba do KAV prostredníctvom CSRÚ ako je podpísané v kapitole 4.6.

4.2.7       Konzumovanie údajov z IS CSRU

Vzhľadom na rozsah a charakter projektu neboli identifikované údaje vhodné na konzumovanie z IS CSRU.

4.3      Dátova vrstva

4.3.1       Údaje v správe organizácie

V rámci úradu TSK nie je v súčasnosti realizovaný projekt týkajúci sa kvality a manažmentu dát.

4.3.2       Dátový rozsah projektu

Tabuľka č.11 Prehľad objektov evidencie v jednotlivých ISVS/registroch  súvisiace s projektom – budúci stav

4.3.3       Kvalita a čistenie údajov

4.3.3.1       Zhodnotenie objektov evidencie z pohľadu dátovej kvality

V rámci úradu TSK nie je v súčasnosti realizovaný projekt týkajúci sa kvality a manažmentu dát.

4.3.3.2       Role a predbežné personálne zabezpečenie pri riadení dátovej kvality

V rámci úradu TSK nie je v súčasnosti realizovaný projekt týkajúci sa kvality a manažmentu dát.

4.4      Referenčné údaje

4.4.1       Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

Vzhľadom na rozsah a charakter projektu neboli identifikované údaje vhodné na vyhlásenie za referenčné.

Tabuľka č.14 Prehľad identifikovaných referenčných údajov – budúci stav

4.4.2       Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CSRU

Vzhľadom na rozsah a charakter projektu bude prostredníctvom CSRÚ prebiehať transfer analytických údajov do KAV.

4.5      Otvorené údaje

Otvorené údaje budú publikované automatizovane z isvs_11174 Integračný komponent na data.gov.sk, ktorý má implementované patričné aj evidenčné aplikačné služby.

Tabuľka č.16 Prehľad otvorených údajov – budúci stav

4.6      Analytické údaje

Tabuľka č.17 Prehľad sprístupnených dátových zdrojov určených na analytické účely – budúci stav

4.7      Moje údaje

Vzhľadom na rozsah a charakter projektu neboli identifikované údaje vhodné na publikovanie ako Moje údaje. 

4.8      Prehľad jednotlivých kategórií údajov

Tabuľka č.19 Kategorizácia údajov z pohľadu ich využiteľnosti (účelu)  - budúci stav

4.9      Technologická vrstva

4.9.1       Prehľad technologického stavu

V súčasnom stave nie je prevádzkovaná smart platforma ani implementovaná IoT senzorika.

4.9.2       Požiadavky na výkonnostné parametre, kapacitné požiadavky

Tabuľka č.20 Prehľad vybraných kapacitných a výkonových požiadaviek– budúci stav

4.9.3       Návrh riešenia technologickej architektúry

Technologická architektúra vychádza zo súčasného prostredia a infraštruktúry TSK.

4.9.4       Využívanie služieb z katalógu  služieb vládneho cloudu

Nerelevantné, nebudú využívané služby vládneho cloudu, dotknuté IS budú prevádzkované na infraštruktúre TSK.

                Tabuľka č.21 Prehľad požiadaviek na výpočtové kapacity prevádzkových prostredí vo vládnom cloude – budúci stav

Tabuľka č.22 Ďalšie doplnkové služby z katalógu cloudových služieb – budúci stav

4.9.5       Jazyková lokalizácia

Jazyková lokácia bude v slovenskom jazyku, po analýze sa zvážia pre niektoré oblasti prípadne jazyky národnostných menšín vrátane anglického jazyka.

4.10   Bezpečnostná architektúra

Základnými východiskami pre rozvíjané riešenie bezpečnosti IS sú rovnako ako v súčasnom stave právne predpisy ako zákon č. 18/2018 o ochrane osobných údajov, zákon č. 95/2019 o informačných technológiách vo verejnej správe a s ním súvisiaca vyhláška č. 78/2020 o štandardoch pre informačné technológie verejnej správy a ďalej ISO/IES 27000, Common Criteria a OWASP Guides a dodatočných požiadaviek prevádzkovateľa systému.

Bezpečnosť v rámci riešenia budovaným navrhovaným projektom sa musí riadiť predovšetkým zákonom č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov pričom musí byť zabezpečená implementácia požiadaviek zo zákona v podobe komplexných technických a organizačných procesov pre bezpečnosť informácií do prostredia IS v správe PSK. Po implementácií opatrení bude IS vyhovovať požiadavkám zákona o kybernetickej bezpečnosti (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov) a zákona č. 18/2018 o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

Pre riešenie bezpečnosti v rámci navrhovaného projektu bude spracovaný bezpečnostný projekt a samotný návrh funkčnosti bude vychádzať z uvedeného projektu. V rámci predmetu projektu budú ďalej realizované penetračné testy a všetky prístupy k údajom a riešeniu budú zabezpečené riadením prístupov na základe hierarchie, ktoré bude kompletne logované. Všetky prenosy medzi systémami ako aj nový systém bude zabezpečený šifrovaním prostredníctvom protokolu HTTPS.

Bezpečnostný projekt zároveň zabezpečí, aby vyššie uvedené opatrenia ku kybernetickej bezpečnosti boli zohľadnené a koordinované s ich aplikáciou v rámci prostredia mesta.

Riešenie spĺňa opatrenia na bezpečnosť prenosu a spracovania dát vďaka:

• dedikovanej prenosovej infraštruktúry, prostredníctvom dedikovanej vlastnej sieti alebo dedikovanej IoT sieti;

• podpore VPN;

• podpore šifrovanej komunikácie, v rámci dedikovanej IoT siete ako aj internetovej siete na úrovni SSL protokolu;

• zabezpečeniu hierarchie a logovania prístupov v aplikácii.

Dostupnosť dát a systému bude zaistená aj na úrovni SLA poskytovateľom služby, alebo pravidelným zálohovaním a možnosťou obnovenia dát. Konkrétny popis prevádzky a riešenia katastrofických scenárov vznikne počas samotného projektu. Ochrana proti DDoS útokom je riešená na úrovni infraštruktúry. Ochrana proti bežnému preťaženiu systému je riešená škálovaním a tiež využitím existujúcej virtualizačnej technológie tiež ako nástroja pre zabezpečenie vysokej dostupnosti.

Dostupnosť bude taktiež zabezpečená monitorovacím softvérom, ktorý zabezpečí pravidelnú kontrolu dostupnosti (a validity) dát, ktoré sú preberané zo systémov tretích strán. Ak nejaké dáta prestanú prichádzať, alebo prichádzajú v nesprávnom formáte, nie sú dostupné na rozhraní alebo sú dostupné v zlom formáte, používateľ bude notifikovaný a problém bude ihneď riešený.

Z pohľadu bezpečnosti bude celá komunikácia na všetky rozhrania prebiehať prostredníctvom zabezpečenej komunikácie a najmodernejších kryptografických metód založených na kryptografii pomocou tzv. SSL cez HTTPS protokol.

Všetky aktivity v platforme budú auditované a auditné logy budú prístupné na kontrolu.

5.     ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Nerelevantné, nie sú známe závislosti na iných projektoch rozvoja IT.

Tabuľka č. 23 Prehľad projektov, ktoré sú v štádiu vývoja a v korelácii s pripravovaným projektom

6.     ZDROJOVÉ KÓDY

Zdrojové kódy budú vo vlastníctve TSK a pri návrhu a implementácii budú aplikované technológie na otvorených licenciách vychádzajúc z:

• Centrálny repozitár zdrojových kódov: https://www.zakonypreludi.sk/zz/2020-78/znenie-20200501#p31
• Overenie zdrojového kódu s cieľom jeho prepoužitia: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p7-3-c 
• Spôsoby zverejňovania zdrojového kódu: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p8-9 
• Inštrukcie k EUPL licenciám: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf 

7.     PREVÁDZKA A ÚDRŽBA

Zabezpečenie prevádzky, údržby a podpory bude zabezpečené prostredníctvom SLA zmluvy financovanej z vlastných finančných zdrojov, ktorá pokryje prevádzku IS z vlastných finančných zdrojov. Žiadateľ deklaruje dostatočné finančné kapacity a alokované ľudské zdroje na zabezpečenie prevádzky a udržateľnosti riešenia min. počas obdobia udržateľnosti riešenia.

Úroveň podpory bude zabezpečená v 3 úrovniach s nasledujúcim označením:
prvú úroveň podpory (L1) bude zabezpečotvať TSK podpora druhej úrovne (L2) bude zabezpečovaná dodávateľom, Prevádzkovateľom technologickej infraštruktúry SK, tretia úroveň podpory (L3), bude zabezpečovaná dodávateľsky

Definícia:

• Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.

• Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.

• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Pre služby sú definované takéto SLA:

Help Desk je dostupný cez príslušný manažment systém a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované formou ticketov.

Dostupnosť L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní),

Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou  dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.

Označenie naliehavosti incidentu:

možný dopad:

Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

(2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu TSK a vyriešením incidentu 

(3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

• (4) Incidenty nahlásené PSK dodávateľovi v rámci testovacieho prostredia 

1. Majú prioritu 3 a nižšiu
2. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia
3. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2      Požadovaná dostupnosť IS:

7.2.1       Dostupnosť (Availability)

Dostupnosť (Availability) znamená, že dáta alebo iné zariadenie sú prístupné v okamihu ich potreby. Vyjadruje sa v percentách dostupného času.

Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Navrhovaná dostupnosť je na úrovni  98,5% dostupnosť.

7.2.2       RTO (Recovery Time Objective)

RTO (Recovery Time Objective) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celého prevádzky nedostupného systému (softvér).

Tradičné zálohovanie - výpadok a obnova by mala trvať max. do 24 hod. 

7.2.3       RPO (Recovery Point Objective)

RPO (Recovery Point Objective) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.

Tradičné zálohovanie - výpadok a obnova by mala trvať max. do 24 hod. 

8.     POŽIADAVKY NA PERSONÁL

Zostavuje sa Riadiaci výbor (RV), v minimálnom zložení:

• Predseda RV
• zástupca vlastníkov procesov objednávateľa
• zástupca kľúčových používateľov objednávateľa
• zástupca dodávateľa (dopĺňa sa až po VO / voliteľný člen)

9.     IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU

V zmysle Vyhlášky 85/20202 Zz o projektovom riadení bude spôsob realizácie projektu metódou waterfall.

Jednotlivé výstupy ako produkty projektu sú definované v Projektovom zámere v kapitole 4.

10.  PRÍLOHY

Rozloženie IoT setov

Koniec dokumentu