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...................................................................................................................... 2

1.1 História zmien........................................................................................................................................ 2

2.    ÚČEL DOKUMENTU.................................................................................................................................... 3

3. Použité skratky....................................................................................................................................... 3

3.    POPIS NAVRHOVANÉHO RIEŠENIA.......................................................................................................... 3

ARCHITEKTÚRA RIEŠENIA PROJEKTU........................................................................................................... 4

4.1 Biznis vrstva.......................................................................................................................................... 4

4.1.1........................................................................................................... Prehľad koncových služieb – budúci stav:............................................................................................................................................. 8

4.1.2......................................................................................................................... Jazyková podpora a lokalizácia................................................................................................................................................ 8

4.2 Aplikačná vrstva.................................................................................................................................... 8

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

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

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

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

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 CPDI)........................................................................................... 13

4.2.6................................................................................. Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE............................................................................................................................. 13

4.2.7............................................................................................................ Poskytovanie údajov z ISVS do IS CPDI............................................................................................................................................. 13

4.2.8...................................................................................................................... Konzumovanie údajov z IS CPDI............................................................................................................................................... 13

4.3 Dátova vrstva....................................................................................................................................... 14

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

4.3.2............................................................................................................................................... Dátový rozsah projektu..................................................................................................................................... 15

4.3.3............................................................................................................................................... Kvalita a čistenie údajov................................................................................................................................... 17

4.4 Referenčné údaje.................................................................................................................................. 18

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

4.4.2............................................ Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CPDI.............................................................................................................................................. 18

4.5 Otvorené údaje..................................................................................................................................... 18

4.6 Analytické údaje................................................................................................................................... 19

4.7 Moje údaje............................................................................................................................................. 19

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

4.9 Technologická vrstva.......................................................................................................................... 20

4.9.1............................................................................................................................................. Prehľad technologického stavu......................................................................................................................... 20

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

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

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

4.10       Bezpečnostná architektúra......................................................................................................... 21

5.    ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY........................................................................................ 22

6.    ZDROJOVÉ KÓDY..................................................................................................................................... 22

7.    PREVÁDZKA A ÚDRŽBA........................................................................................................................... 22

7.1 Prevádzkové požiadavky....................................................................................................................... 22

7.1.1................................................................................................................................ Úrovne podpory používateľov......................................................................................................................................... 22

7.1.2................................................................................................................ Riešenie incidentov – SLA parametre.............................................................................................................................................. 23

7.2 Požadovaná dostupnosť IS................................................................................................................... 24

7.2.1....................................................................................................................................... Dostupnosť (Availability)......................................................................................................................................... 24

7.2.2......................................................................................................................... RTO (Recovery Time Objective).............................................................................................................................................. 25

7.2.3........................................................................................................................ RPO (Recovery Point Objective).............................................................................................................................................. 26

8.    POŽIADAVKY NA PERSONÁL................................................................................................................... 26

9.    Implementácia a preberanie výstupov projektu..................................................................... 26

10.  Prílohy.................................................................................................................................................. 26

1. POPIS ZMIEN DOKUMENTU
   1. História zmien

1. ÚČEL DOKUMENTU

V súlade s Vyhláškou č. 401/2023 Z.z. je dokument P-03 a I-03 Prístup k projektu určuje a bližšie popisuje architektúru riešenia, požiadavky na celkovú funkcionalitu riešenia, bezpečnosť, ako i ďalšie oblasti, ktoré súvisia s navrhovaným riešením, bližšie špecifikovaným v dokumente Projektový zámer.

3. Použité skratky

1. POPIS NAVRHOVANÉHO RIEŠENIA

Výstupom projektu by mal byť komplexný systém pre automatizovaný zber a správu geopriestorových informácií o technickej (utility) infraštruktúre na území SR, ktorá podlieha štátnej regulácií. Samotný projekt Atlas pasívnej infraštruktúry bude nadrezortným systémom, ktorý nemôže zdieľať GIS architektúru s už existujúcou architektúrou v projekte IS MSRŠD (a jeho rozvoja) z dôvodu jeho primárneho zamerania na funkčnosti pre meranie a mapovanie pokrytie, je štrukturálne iný a každá sieť fyzickej infraštruktúry (energetická, vodné hospodárstvo, tepelná energetika, plynárenská, sieť budov a výstavby) bude potrebovať vlastnú vrstvu so špecifickými požiadavkami a analytickými nástrojmi. Zároveň bude potrebné splniť všetky bezpečnostné predpoklady a zabezpečenie takéhoto systému, ktorý bude obsahovať dáta o zbieranej FI vyššou úrovňou ako je zabezpečenie v pripravovanom rozvoji projektu IS MSRŠD. Projekt Atlas pasívnej infraštruktúry tvorí spoločný program spolu s projektom GigaoOffice, nakoľko IS MSRŠD ako ISVS projektu GigaOffice je prvým zdrojom dát telekomunikačnej infraštruktúry, pre spustenie ISVS Atlas pasívnej infraštruktúry. Atlas pasívnej infraštruktúry nepreberá dáta o pokrytí. IS MSRŠD je určený a zameraný na úsek verejnej správy telekomunikácií. Jeho hlavnou úlohou je zber informácií a vyhodnocovanie informácií o telekomunikačnom pokrytí a pasívnej telekomunikačnej infraštruktúre, ktorá samotné pokrytie zabezpečuje. Atlas pasívnej infraštruktúry je prijímateľom dát a v synergii s ostatnými dátami o infraštruktúre (elektrická, vodovodná, plynová a podobne) tvorí ucelený a komplexný pohľad na infraštruktúru ako celok. V súčasnosti IS MSRŠD obsahuje informácie a dáta o telekomunikáciách zo zberu vykonaného v roku 2024 odovzdaných jednotlivými poskytovateľmi elektronických a komunikačných služieb a sietí a prevádzkovateľmi telekomunikačnej infraštruktúry.  

1. ARCHITEKTÚRA RIEŠENIA PROJEKTU

1. 1. Biznis vrstva

Architektúra z biznis pohľadu riešenia sa bude koncentrovať na zber a poskytovanie údajov o existujúcej aj plánovanej fyzickej infraštruktúre identifikovanej na území Slovenskej republiky.

Modulárne zostavenie riešenia bude schopné poskytovať služby pre oblasti:

• Zberu dát (mimo telekomunikačnej infraštruktúry, kde zber pokrýva IS MSRŠD a vlastníkom dát je ÚPREKaPS)   
• Vstup archívnych materiálov
• Plánovanie a budovanie nových trás infraštruktúry (mimo telekomunikačnej infraštruktúry, ktorú pokrýva IS MSRŠD a ich vlastníkom je ÚPREKaPS)   
• Poskytovanie informácií
• Zobrazovanie informácií v agregátoch

Riešenie bude pracovať primárne s priestorovými informáciami vo vektorovom tvare, doplnenými rozširujúcou údajovou štruktúrou popisujúcou kvalitatívne parametre jednotlivých objektov.

Riešenie bude oprávneným používateľom umožňovať využitie pokročilej priestorovej analytiky za účelom podpory rozhodovania a plánovania výstavby – štatistiky o využiteľnej fyzickej infraštruktúre, prípadne pokrytie územia a % obyvateľstva fyzickou infraštruktúrou orgánom štátnej a verejnej správy lepšie plánovanie budúceho rozvoja infraštruktúry.

Riešenie zároveň umožní kontrolu navrhovaných trás infraštruktúry voči stretom záujmov s priestorom legislatívnej ochrany, alebo inak chránenej lokality.

Riešenie umožní kontrolu súladu plánovej trasy s obmedzeniami:

• Legislatívne obmedzenia
• Ochranné pásma a chránené územia (podľa aktuálneho delenia)
• Prírodné rizikové oblasti
• Rizikové oblasti industriálne, vrátane environmentálnych záťaží
• Stret s líniou existujúcej infraštruktúry

Podporená bude hlavne :

• Výstavba ďalšej generácie telekomunikačných sietí, šírenie prístupu k širokopásmovému internetu jeho rýchlejším a cenovo efektívnejším budovaním.
• Regulačné rozhodnutia príslušných regulačných úradov podporené analýzami konsolidovaných priestorových informácií o fyzickej infraštruktúre SR.

Publikovanie informácií o plánovaných výstavbách povinne pri prípade prác úplne alebo čiastočne financovaných z verejných prostriedkov a voliteľne pri aktivitách pripravovaných zo súkromných zdrojov pre efektívnejšiu koordináciu a zdieľanie nákladov stavebných prác.

Aktéri v roliach poskytovateľov a žiadateľov informácií budú vytvárať základné dátové toky centralizovaného riešenia.

Hlavnými aktérmi systému budú:

• Povinné osoby - ústredné orgány štátnej správy, miestne orgány štátnej správy, vyššie územné celky a obce
• Prevádzkovatelia sietí - podniky alebo osoby ktoré prevádzkujú alebo uskutočňujú výstavbu siete alebo siete určenej na poskytovanie služieb výroby, prepravy alebo distribúcie plynu, výroby alebo distribúcie elektriny, zabezpečovania verejného osvetlenia, výroby, distribúcie alebo dodávky tepla, prevádzkovania verejnej kanalizácie a prevádzky železničnej a cestnej infraštruktúry, prístavov a leteckej infraštruktúry.
• Prevádzkovatelia elektronických komunikačných sietí - primárni žiadatelia o informácie o pasívnej infraštruktúre, zároveň aj poskytovatelia údajov.

V špecifickom postavení budú partneri projektu:

• JIM - zo zákona realizuje zber priestorových a technických informácií o telekomunikačnej FI a vystupuje v pozícii správcu údajov a prístupov k nim. Zdrojom dát je IS MSRŠD.
• MŽP - garant NIPI a správca štruktúry priestorových údajov zodpovedný za implementáciu INSPIRE, zároveň podľa princípu jedenkrát a dosť využíva priestorové informácie o verejných vodovodoch a kanalizáciách ktoré je povinný zhromažďovať a vyhodnocovať.

Obrázok 1 - Business architektúra navrhovaného riešenia

V nasledujúcej tabuľke uvádzame popis jednotlivých služieb, ktoré budú realizované v rozhraní navrhovaného riešenia:

Tabuľka mapovania stakeholderov na biznis role

Nasledujúca schéma detailne popisuje služby a procesy súvisiace s poskytovaním informácií o FI. Základnými udalosťami spúšťajúcimi poskytovanie informácie o FI sú zaregistrovanie žiadosti o informáciu o FI a zaregistrovanie informácie o plánovanej výstavbe FI. Obe sú iniciované prevádzkovateľmi sietí.

Obrázok 2 - Popis služieb a funkčných blokov pre poskytovanie informácií o fyzickej infraštruktúre

V nasledujúcej tabuľke uvádzame popis jednotlivých procesov a funkcií, ktoré zabezpečujú poskytovanie informácií o FI:

Nasledujúca schéma detailne popisuje služby a procesy súvisiace so zberom údajov o FI.

Obrázok 3 - Popis služieb a funkčných blokov pre zber údajov o FI

V nasledujúcej tabuľke uvádzame popis jednotlivých procesov a funkcií, ktoré zabezpečujú zber údajov o FI:

1. 1. 1. Prehľad koncových služieb – budúci stav:

1. 1. 1. Jazyková podpora a lokalizácia

Požiadavky na jazykovú lokalizáciu riešenia a používateľské prostredie bude pre verejný portál implementované v slovenskom a anglickom jazyku.

1. 1. Aplikačná vrstva

Aplikačná architektúra rámcovo predpokladá pre vytvorenie riešenia využitie komponentového modelu. Pre vytvorenie integračných väzieb budú publikované webové služby. Komunikácia s oprávnenými používateľmi riešenia bude prebehať cez verejný webový portál a API rozhranie. Správy pre aktívne notifikovanie používateľov systému budú odosielané do e-schránok UPVS prípadne na registrované mailové adresy. 

Verejný webový portál bude tiež zverejňovať neštruktúrované oznamy. Jadrom aplikačných komponentov budú GIS moduly zabezpečujúce prácu s priestorovými datasetmi prevádzkovateľov sietí. 

Doplnia ich zákaznícky vyvinuté komponenty pre komunikáciu s poskytovateľmi a žiadateľmi údajov s webovým rozhraním prístupným v rámci verejného webového portálu. 

Riešenie bude doplnené aj o datasety pre funkčné požiadavky riešenia stretu plánovaných trás infraštruktúry s obmedzeniami, resp. prekážkami pri návrhu a optimalizácii budúcej trasy. 

Dôležitým komponentom bude integračné rozhranie riešenia, ktorá bude konsolidovať a riadiť všetky integračné väzby riešenia. 

Samostatným komponentom bude ServiceDesk, ktorého úlohou bude zabezpečiť bezproblémovú prevádzku a technickú komunikáciu s používateľmi systému. 

Okrem integrácií na IS štátnej správy sa budú môcť na IS Atlas pasívnej infraštruktúry integrovať aj informačné systémy prevádzkovateľov siete. Integračné rozhranie bude poskytovať webové služby, primárne formou REST API, na automatizované odovzdávanie informácií o existujúcej fyzickej infraštruktúre a plánovaných výstavbách.

V nasledujúcej tabuľke uvádzame popis aplikačných služieb:

V nasledujúcej tabuľke uvádzame popis aplikačných rozhraní:

V nasledujúcej tabuľke uvádzame popis aplikačných komponentov:

Okrem integrácie s informačnými systémami štátnej správy bude možné prepojiť IS Atlas pasívnej infraštruktúry aj so systémami prevádzkovateľov sietí. Integračné rozhranie zabezpečí webové služby na automatizované odovzdávanie údajov o existujúcej fyzickej infraštruktúre a plánovaných výstavbách.

Systém bude integrovaný aj s RPI na účely publikácie otvorených údajov o fyzickej infraštruktúre, v súlade s povinnosťami vyplývajúcimi zo zákona o Národnej infraštruktúre pre priestorové informácie (NIPI) č. 3/2010 Z. z. v znení neskorších predpisov. Pre zabezpečenie komunikácie s používateľmi bude systém prepojený na ÚPVS, ktorý umožní odovzdávanie notifikácií do elektronických schránok oprávnených subjektov, v prípade spustenia plánovaného projektu Centrálny notifikačný modul (CNM), tak integrácia prebehne na nový CNM, ktorý sa plánuje uviesť do prevádzky.  

Na zobrazovanie podkladových máp s dôrazom na informácie z katastra nehnuteľností bude systém integrovaný s Geoportálom ÚGKK (ZBGIS), čím sa zabezpečí vizualizácia územných údajov v kontexte fyzickej infraštruktúry. Systémy Úradu pre reguláciu elektronických komunikácií a poštových služieb nebudú s IS Atlas pasívnej infraštruktúry technicky prepojené priamo.

Integrácia na ISVS MSRŠD bude vo forme prijímania dávkových údajov, 1-krát denne, z MSRŠD prostredníctvom OpenAPI rozhrania, ktoré je plánované v rozvoji projektu MSRŠD.

1.  
   1. 1. Rozsah informačných systémov

V AS IS stave nie je prevádzkovaný žiadny IS VS v oblasti predmetu projektu.

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

Obrázok č.3 Model aplikačnej architektúry

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

V AS IS stave nie je prevádzkovaný žiadny IS VS v oblasti predmetu projektu.

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

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

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

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

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

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

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

1. 1. 1. Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

1. 1. 1. Poskytovanie údajov z ISVS do IS CPDI

V rámci Atlasu pasívnej infraštruktúry budú poskytované objekty evidencie do IS CPDI a ich bližšia špecifikácia bude zapracovaná v rámci fázy Analýza a dizajn riešenia.

Tabuľka č.9 Prehľad ISVS a objektov evidencie poskytovaných do IS CPDI – budúci stav

1. 1. 1. Konzumovanie údajov z IS CPDI

Tabuľka č. 10 Prehľad ISVS a objektov evidencie konzumovaných z IS CPDI – budúci stav

1. 1. Dátova vrstva

1. 1. 1. Údaje v správe organizácie

Medzi inžinierske siete patrí fyzická infraštruktúra na prepravu úžitkových výrobkov - potrubia na prepravu ropy, plynu, chemikálií, vody, kanalizačných a tepelných produktov - a káble na prenos elektriny, káblové distribučné systémy atď.

Každá organizácia má rozdielne zodpovednosti, čo ovplyvní druh údajov, ktoré zhromažďuje, spravuje a používa. Niektoré organizácie budú používať jednoduché, zatiaľ čo iné budú mať zložitejšie dátové modely.

Táto špecifikácia údajov je základným rámcom, ktorý môže dodávateľ systému prispôsobiť a rozšíriť podľa svojich potrieb. Špecifikácia je zameraná na základné priestorové objekty vyžadované sieťami. Nie sú zahrnuté všetky priestorové objekty špecifické pre aplikácie (napr. Senzory na meranie prietoku). Negeografické údaje (napr. Informácie o prietoku v m3 / s) sú tiež mimo rozsahu tejto špecifikácie.

Rozsah špecifikácie produktu INSPIRE Utility Networks Data obsahuje šesť rôznych tém nástrojov:

• Vodná sieť
• Kanalizačná sieť
• Elektrická sieť
• Siete ropy, plynu a chemikálií
• Tepelná sieť
• Telekomunikácie

Charakteristiky špecifikácie

Kľúčovými charakteristikami dátových setov technických sietí sú:

• Obsahujú informácie využívané vo verejnom sektore pri podpore budovania efektívnych technických sietí (elektrina, telekomunikácie, voda, kanalizácia atď.).
• Informácie sú uplatniteľné od miestnej až po európsku úroveň prevádzky.
• Údaje predstavujú štruktúru alebo metódy prevádzky, ktoré sú stabilné v čase (aj keď sa časti obsahu údajov často menia, napríklad telekomunikácie).
• Podporuje cezhraničné (celoeurópske) aplikácie.
• Keďže sú súčasťou európskej infraštruktúry priestorových údajov, údaje sa môžu ľahšie používať s inými druhmi údajov, ako sú geografické názvy, administratívne jednotky a adresy atď.

Celkový opis využíva pomerne jednoduchú štruktúru informácií opisujúcich takéto služby, medzi ktorými sú:

• Umiestnenie prvku;
• Poskytovateľ služby
• Základné technické charakteristiky, ako napríklad kapacita alebo podrobnosti o type poskytovanej službe.

Priestorové rozlíšenie a topológia

Topológia v GIS je všeobecne definovaná ako priestorový vzťah medzi spojovacími alebo susednými prvkami a je nevyhnutným predpokladom pre priestorové operácie, ako je napríklad analýza siete. Technické siete možno opísať ako sieť NaN (Node-Arc-Node) s použitím dvoch základných geometrických typov: bodov (aka uzlov) a polyčiar (aka oblúkov). Topológie NaN môžu byť smerované v závislosti od špecifického typu siete (t.j. vodovodné siete sú smerované, zatiaľ čo elektronické komunikačné siete nie sú). Takáto štruktúra topológie umožňuje automatizovaný spôsob spracovania chýb pri digitalizácii a úpravách a umožňuje pokročilé priestorové analýzy.

Súvisiace „negeografické“ údaje

Veľká časť údajov používaných pri prevádzke fyzickej infraštruktúry je klasifikovaná ako špecifická pre aplikácie. Na maximalizáciu opätovného použitia by spojenie takýchto údajov s priestorovými objektmi malo byť definované slabou väzbou v tom zmysle, že údaje sú definované ako samostatné dátové objekty v databáze. Tieto údaje potom môžu byť opätovne použité v rôznych aplikáciách a všetky súvisiace informácie môžu byť zdieľané a vymieňané podľa potreby.

Bežné typy profilu sieťových sietí obsahujú typy káblov, potrubí a kanálov. Tieto tri typy majú rôzne asociácie, ktoré možno použiť na modelovanie ich vzťahov v reálnom živote:

• Kanál môže obsahovať viac iných kanálov, napr. v prípade, že vonkajší kanál je väčšia konštrukcia obsahujúca viacero menších kanálov;
• Kanál môže obsahovať viac potrubí, napr. v prípade, že potrubie funguje ako ochranná vrstva alebo ako konštrukcia na udržanie potrubí spolu;
• Kanál môže obsahovať viac káblov
• Potrubie môže obsahovať viac ďalších potrubí, napr. v prípade, že druhé potrubie slúži na udržanie množstva vnútorných rúrok spolu;
• Potrubie môže obsahovať viacero káblov.

1.  
   1. 1. Dátový rozsah projektu

Analýza údajov UML Modelu INSP a požiadaviek  predpokladá zber minimálne základnej skupiny údajov o technických objektoch infraštruktúry pre potreby projektu:

• Rúra
• Stožiar
• Kontrolná komora
• Káblovod
• Vstupná šachta
• Rozvodná skriňa
• Budova
• Anténa
• Anténny systém
• Veža
• Stĺp
• Oporný bod nadzemného vedenia

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

Schéma 2 - UML Dátový model pre INSPIRE Utility

1. 1. 1. Kvalita a čistenie údajov
         1. Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Vzhľadom na charakter údajov poskytovaných IS CPDI je významnosť kvality údajov pre biznis procesy je významnosť a citlivosť kvality údajov a priorita pre meranie dátovej kvality objektov evidencií rovnaká (najvyššia).

Tabuľka č.12 Kategorizácia objektov evidencie z pohľadu dátovej kvality – budúci stav

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

Tabuľka č.13 Prehľad rolí a personálneho zabezpečenia pre riadenie dátovej kvality

1. 1. Referenčné údaje
      1. Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

Predmetom projektu nie je návrh na vyhlásenie a zmeny referenčných údajov.

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

1. 1. 1. Identifikácia údajov pre konzumovanie alebo poskytovanie údajov  do/z CPDI

Tabuľka č.15 Prehľad konzumovaných/poskytovaných referenčných údajov – budúci stav

1.  
   1. Otvorené údaje

V tejto časti je potrebné uviesť informácie súvisiace s otvorenými údajmi z pohľadu TO BE stavu projektu.

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

Všetky dáta, databázy a datasety vytvorené alebo spravované v rámci informačného systému Atlas pasívnej infraštruktúry, ktoré neobsahujú zákonom chránené údaje, budú poskytované pod otvorenou licenciou Creative Commons Attribution 4.0 International (CC BY 4.0). Táto licencia umožňuje voľné zdieľanie, úpravu a využitie údajov aj na komerčné účely.

1. 1. Analytické údaje

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

• 1. Moje údaje
•  

Predmetom projektu nie je sprístupnenie údajov pre službu Moje údaje

Tabuľka č.18 Prehľad údajov identifikovaných pre službu „moje údaje“ – budúci stav

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

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

1. 1. Technologická vrstva
      1. Prehľad technologického stavu

V AS IS stave nie je prevádzkovaný žiadny IS VS v oblasti predmetu projektu.

1. 1. 1. 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

1. 1. 1. Návrh riešenia technologickej architektúry

Technologická architektúra riešenia bude postavená na hybridnom cloudovom riešení MIRRI cloudu a virtualizačnej platforme vládneho cloudu, prevádzkovaného Ministerstvom vnútra SR, a využije služby IaaS na hosťovanie sady virtuálnych serverov aj kontajnerizačné platformy.. Tieto servery budú rozdelené podľa aplikačných vrstiev na:

• Front office – zabezpečujúci komunikáciu s používateľmi,
• Middle office – sprostredkovávajúci aplikačnú logiku a integrácie,
• Back office – určený na spracovanie a ukladanie dát.

Architektúru doplnia obslužné komponenty, ako sú load balancery a reverzné proxy servery, ktoré budú riadiť vyvažovanie záťaže a smerovanie komunikácie.

Na rozhraní s internetom bude nasadené API Gateway appliance, preferovane fyzického typu, ktoré zabezpečí bezpečnú komunikáciu a kontrolu prístupu k API rozhraniam. Komunikačné toky budú riadené medzi izolovanými subdoménami, čím sa zvýši bezpečnosť a modularita systému. Bude aplikovaný princíp API First.

 Kvôli vyššej bezpečnosti budú komponenty GIS modul, Mapový server a Priestorová DB umiestnené vo Vládnom cloude.

Virtuálne dátové úložiská budú optimalizované pre vysokú rýchlosť čítania a zápisu, aby sa zabezpečila plynulá práca s veľkým objemom priestorových dát.

Vzhľadom na to, že hybridné cloudové riešenie vo forme PaaS momentálne nedokáže pokryť požiadavky navrhovaného systému, architektúra bude doplnená o špecifické komponenty na mieru, ktoré zabezpečia:

• Riadenie dátových tokov,
• Konsolidáciu integrácií,
• Vysokovýkonné úložiská prispôsobené na prácu s rozsiahlymi datasetmi.

Požadované funkcionality datacentra

• Backup & Restore – zálohovanie konfigurácií, snapshoty serverov, zálohy a obnovy databáz.
• Clustering – eliminácia jednotlivých bodov zlyhania (SPOF) prostredníctvom clustrov aplikačných serverov.
• Load balancing – dynamické rozdelenie záťaže medzi jednotlivé clustery.
• SDN (Software Defined Networking) – softvérovo definovaná sieťová infraštruktúra.
• Virtual storage – virtualizované úložiská s vysokou kapacitou a rýchlosťou.
• Network partitioning – izolácia siete do samostatných subnetov.
• Data replication – replikácia dát na úrovni dátových storageov pre zabezpečenie dostupnosti a redundancie.

Obrázok 5 - Technologická architektúra navrhovaného riešenia

V prípade nedostatčne pripraveného MIRRI cloud riešenie bude jeho pripravovaná časť presunutá do a prevádzkovaná vo vládnom cloude.

Prístup z externého prostredia

Pomocou VPN bude zabezpečené prepojenie oprávnených povinných osôb so serverovou infraštruktúrou, pričom bude možné bezpečne pristupovať k jednotlivým serverom.

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

               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

1. 1. Bezpečnostná architektúra

Vzhľadom na to že v rámci systému budú  zhromažďované a spracovávané údaje, ktoré môžu mať povahu vyhradených informácií, systém bude musieť byť zabezpečený spôsobom ktorým poskytne adekvátnu ochranu týchto údajov. Bezpečnostná architektúra predpokladá vybudovanie komplexného systému ochrany, ktorý bude implementovaný technickými prostriedkami, ktoré zahŕňajú dedikované bezpečnostné prostriedky tvoriace súčasť aplikačných komponentov a infraštruktúry ako aj netechnické prostriedky pre manažment informačnej bezpečnosti.

Bezpečnostná architektúra bude zahŕňať nasledovné oblasti:

• dodržiavanie pravidiel riadenia informačnej bezpečnosti (podľa zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov v znení neskorších predpisov, medzinárodnej normy ISO/IEC 27001:2013 a podľa zákona č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy a doplnení niektorých zákonov v znení neskorších predpisov),
• systém riadenia aplikačnej bezpečnosti, monitorovanie bezpečnosti a incident management, segmentácia siete, monitoring a ochrana sieťového spojenia, hardening staníc a whitelisting aplikácií.

Pri návrhu sa požaduje zohľadniť nasledovné kritériá bezpečnosti:

• architektúra technických prvkov musí byť navrhnutá tak, aby v kooperácii s ostatnými oblasťami riešenia, ako napr. sieťová a aplikačná architektúra, umožnila stálu dostupnosť a škálovateľnosť,
• pre pripájanie externých IS musí byť vytvorený bezpečný a autentizovaný komunikačný kanál,
• autentizácia používateľov pristupujúcich k IS musí byť adekvátna spôsobu ich pripojenia a oprávnení používateľov na činnosti v IS,
• pri návrhu komunikácie medzi ISVS a externých systémov sa musí používať štandardný spôsob komunikácie medzi systémami, predovšetkým webové služby, schválené dátové prvky a identifikátory,
• príslušné dátové typy pre údaje prenášané webovými službami sa požaduje navrhnúť tak, aby bola umožnená účinná kontrola špecializovanými bezpečnostnými mechanizmami; artefakty vytvorené počas fázy návrhu musia byť vytvárané podľa jednotných pravidiel tak, aby umožňovali jednoznačné bezpečnostné overenie najmä s dôrazom na typy a formu údajov, spôsob ich spracovávania, zabezpečenia integrity a riadenie prístupu k nim.

Realizácia systému si vyžiada zabezpečenie prevádzky, správy a údržby IS v súlade s požiadavkami riadenia informačnej bezpečnosti. Systém musí zohľadňovať všetky požiadavky kladené zákonom č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov  v znení neskorších predpisov, zákonom č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy a doplnení niektorých zákonov v znení neskorších predpisov a súvisiacich právnych predpisov.

Pre prístup k administratívnemu rozhraniu budú prevádzkované služby zápisu administrátora s mapovaním na riadenie prístupov, s osobitným ohľadom na zvýšenú bezpečnosť (samostatné školenie každého zamestnanca, viacfaktorové prihlasovanie, vyhradené lokality prístupu).

1. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

Realizácia pripravovaného projektu je závislá na iných projektoch.

1. ZDROJOVÉ KÓDY

Bude dodržaný princíp otvorenosti, tzn. duševným vlastníkom všetkých výstupov, vrátane technológie a zdrojového kódu bude štát.

Zdrojové kódy vytvorené počas projektu sa budú zverejňovať v zmysle § 31 vyhlášky č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy v nadväznosti na § 15 ods. 2 písm. d) prvý bod zákona č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov buď  pre verejnosť bez obmedzenia (podľa § 31 ods. 4 písm. a) vyhlášky) alebo s obmedzenou dostupnosťou iba pre orgán vedenia a orgány riadenia (podľa § 31 ods. 4 písm. b) vyhlášky) spolu s odôvodnením v závislosti od jeho charakteru a posúdenia z hľadiska bezpečnosti a súvisiacich okolností.

Konkrétne v zmysle § 15 ods. 2 písm. d) zákona č. 95/2019 Z. z. informačných technológiách vo verejnej správe:

Vo fáze prípravy a obstarania projektu je správca povinný akceptovať také zmluvné podmienky, podľa ktorých:

zdrojový kód vytvorený počas projektu bude otvorený v súlade s licenčnými podmienkami verejnej softvérovej licencie Európskej únie podľa osobitného predpisu, a to v rozsahu, v akom zverejnenie tohto kódu nemôže byť zneužité na činnosť smerujúcu k narušeniu alebo k zničeniu informačného systému verejnej správy,

je jediným a výhradným disponentom so všetkými informáciami zhromaždenými alebo získanými počas projektu a prevádzky projektom vytvoreného riešenia vrátane jeho zmien a servisu a

pri zmene dodávateľa pôvodný dodávateľ poskytne správcovi úplnú súčinnosť pri prechode na nového dodávateľa, najmä v oblasti architektúry a integrácie informačných systémov.

Všetky zdrojové kódy vytvorené v rámci projektu budú uložené a zverejnené bez obmedzení v centrálnom repozitári verejnej správy dostupnom na adrese github MIRRI. Súčasťou odovzdávania bude aj detailná vývojárska dokumentácia a návody na inštaláciu a konfiguráciu.

Všetky zdrojové a strojové kódy, ako aj ďalšie výstupy vytvorené v rámci projektu, budú poskytnuté pod licenciou EÚPL (Európska verejná licencia). Táto požiadavka bude zahrnutá v zmluvných podmienkach s dodávateľom.

1. PREVÁDZKA A ÚDRŽBA

1. 1. Prevádzkové požiadavky
      1. Úrovne podpory používateľov

Úrovne podpory používateľov:

Help Desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

L1 podpory IS (Level 1, priamy kontakt zákazníka) - jednotný kontaktný bod prevádzkovateľa (NASES) 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ď.

L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS na základe zmluvy o podpore IS (zabezpečuje prevádzkovateľ v spolupráci s úspešným uchádzačom). 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.

L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).

Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najzložitejší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 SW nástroj pre nahlasovanie a riešenie incidentov a pre vybrané skupiny užívateľov (používatelia verejného portálu) cez telefón a email,

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

Podporu úrovne L1 a L2 bude vykonávať budúci prevádzkovateľ riešenia (NASES) existujúcimi prostriedkami cez Kontaktné centrum a pracovníkov podpory.

Podpora úrovne L3 sa bude riadiť pravidlami SLA, ktorú Správca IS uzatvorí s treťou stranou. Minimálne požiadavka na SLA sú uvedené nižšie v tejto kapitole.

1. 1. 1. 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:

Vysvetlivky k tabuľke

(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 verejným obstarávateľom a vyriešením incidentu úspešným uchádzačom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je úspešný uchádzač oprávnený požadovať od verejného obstarávateľa schválenie riešenia 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é verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. 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.

1. 1. Požadovaná dostupnosť IS

1. 1. 1. Dostupnosť (Availability)

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ť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok. Orientačný zoznam dostupnosti je uvedený v nasledovnom prehľade:

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd

Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:

• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective) - aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove

Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:

• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok

V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa. Potom je potrebné mať vhodným spôsobom ošetrenú úroveň dostupnosti, ktorú musí dodávateľ dodržať. Zvyčajne je dostupnosť súčasťou dohody o úrovni poskytovaných služieb (SLA).

1. 1. 1. RTO (Recovery Time Objective)

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.

Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút
• Synchrónny replikácie dát - nulový výpadok

1. 1. 1. RPO (Recovery Point Objective)

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ť.

Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút, strata sa blíži k nule
• Synchrónny replikácie dát - nulová strata

1. POŽIADAVKY NA PERSONÁL

Podrobne uvedené v Projektovom zámere.

1. Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu budú realizované podľa vyhlášky č. 401/2023 Z. z. v zmysle ustanovení.

1. Prílohy

N/A