PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03
podľa vyhlášky MIRRI č. 401/2023 Z. z.

PRÍSTUP K PROJEKTU

 Vzor pre manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z. 

Schvaľovanie dokumentu

1. História dokumentu

1. Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Predkladaný Prístup k projektu v zmysle vyššie uvedenej vyhlášky obsahuje opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy.

Prístup k projektu zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

1. 
   
   1. Použité skratky a pojmy

1. 
   
   1. Konvencie pre typy požiadaviek (príklady)

Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné, nefunkčné a technické.

Funkčné  požiadavky majú nasledovnú konvenciu:

FRxx

FR           – funkčná požiadavka

xx            – číslo požiadavky

Nefunkčné a technické požiadavky majú nasledovnú konvenciu:

NRxx

NR          – nefukčná a technická požiadavka

xx            – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.

1. Popis navrhovaného riešenia

Architektúra riešenia vychádza z cieľa projektu na zvýšenie úrovne kybernetickej a informačnej bezpečnosti v rámci MZVEZ SR. Opatrenia oblasti kybernetickej a informačnej bezpečnosti sú prierezovými opatreniami v rámci fungovania a kompetencií MZVEZ SR. Cieľom projektu nie je úprava existujúcej biznis a aplikačnej architektúry agendových systémov MZVEZ SR. Projekt sa zameriava na technologické prvky a nástroje za účelom prevencie, detekcie a mitigácie hrozieb spôsobených kybernetickými útokmi a na znižovanie škôd z nich vyplývajúcich. Priamo tak prispieva k vyššej kontinuite pri prevádzke agendových informačných systémov MZVEZ SR.

Projekt sa zameriava najmä na nasledovné oblasti v súlade s výzvou:

-              riadenie prístupov,

-              bezpečnosť pri prevádzke informačných systémov a sietí,

-              ochrana proti škodlivému kódu,

-              sieťová a komunikačná bezpečnosť,

-              zaznamenávanie udalostí a monitorovanie,

-              riešenie kybernetických bezpečnostných incidentov,

-              kryptografické opatrenia,

-              kontinuita prevádzky.

Cieľový stav projektu prináša nasledovné:

• Zlepšená bezpečnosť: Vďaka centrálnej správe, URL filteringu, secure DNS a vylepšenej autentifikácii bude celá infraštruktúra lepšie chránená pred kybernetickými hrozbami.
• Efektívnejšia správa siete: Centrálny monitoring a manažment umožnia jednoduchšiu správu a rýchlejšie riešenie incidentov bez potreby manuálnych zásahov na jednotlivých komponentoch.
• Flexibilita a škálovateľnosť: SD-WAN umožní flexibilné prispôsobovanie siete aktuálnym potrebám a lepšiu optimalizáciu pre zahraničné lokality alebo cloud.
• Vyššia dostupnosť a výkon: Modernizované sieťové prvky, ako napríklad load-balancer a vylepšené VPN pripojenia, zabezpečia vyššiu dostupnosť služieb a rýchlejšie spracovanie sieťového prenosu.
• Lepšie reakcie na incidenty: Automatizované riešenia pre zraniteľnosti a bezpečnostné incidenty zabezpečia rýchlejšie obnovovanie infraštruktúry po bezpečnostných problémoch.

Bližší popis k jednotlivým prvkom budúceho riešenia v rámci projektu je popísaný na úrovni biznis, aplikačnej a technologickej vrstve tohto dokumentu.

1. Architektúra riešenia projektu

Architektúra riešenia projektu je bližšie rozpracovaná na úrovni biznis vrstvy, aplikačnej vrstvy, technologickej vrstvy a bezpečnostnej vrstvy.

1. 
   
   1. Biznis vrstva

Obrázok 1 - Biznis architektúra riešenia

MZVEZ SR ako prevádzkovateľ základnej služby v súlade so zákonom č. 69/2018 Z. z. o kybernetickej bezpečnosti v rámci bezpečnostnej analýzy identifikoval potenciálne bezpečnostné riziká spôsobené zastaranými infraštruktúrnymi prvkami a platformami, ktoré funkčne nepokrývajú aktuálne rastúce hrozby vyplývajúce kybernetických a bezpečnostných incidentov.

V rámci oblastí, ktoré sú podporené aj výzvou č. PSK-MIRRI-616-2024-DV-EFRR ide o nasledovné:

1. Nástroje pre zavedenie zálohovania na obnovu siete a informačného systému vrátane pravidelného testovania obnovy záloh
2. Nástroje pre manažment konfigurácií počítačových sietí
3. Nástroje na manažment zraniteľností kybernetickej bezpečnosti a riadenie záplat a aktualizácií
4. Nástroje pre zavedenie viacfaktorovej autentifikácie
5. Nástroje, ktorých cieľom je zvýšiť schopnosť detekcie škodlivých aktivít a bezpečnostných incidentov, resp. ochrana koncových bodov, dát, dátových prenosov a sieťovej komunikácie

Nástroje pre zavedenie zálohovania na obnovu siete a informačného systému vrátane pravidelného testovania obnovy záloh

V rámci projektu sa zavádza nástroj na centrálny manažment sietí pomocou jednotnej centralizovanej platformy, vrátane bezpečnostných pravidiel pre infraštruktúrne bezpečnostné prvky ako je firewall. Integruje prevenciu hrozieb, filtrovanie adries URL, DNS, informovanosť o aplikáciách, identifikáciu používateľov, kontrolu prístupu a filtrovanie s podporou zálohovania na obnovu siete, vrátane pravidelného testovania záloh.

Nástroje pre manažment konfigurácií počítačových sietí

V rámci projektu sa zavádza nástroj na centrálny manažment sietí pomocou jednotnej centralizovanej platformy, vrátane bezpečnostných pravidiel pre infraštruktúrne bezpečnostné prvky ako je firewall. Integruje prevenciu hrozieb, filtrovanie adries URL, DNS, informovanosť o aplikáciách, identifikáciu používateľov, kontrolu prístupu a filtrovanie.

Nástroje na manažment zraniteľností kybernetickej bezpečnosti a riadenie záplat a aktualizácií

V rámci projektu sa zavádzajú 2 nástroje na manažment zraniteľností:

1. Aktívne prvky ochrany perimetra – nové NGFW s podporou SD-WAN, URL filtering, Secure DNS,
2. Prvky ochrany EDR - rozšírené možnosti detekcie kybernetických hrozieb v porovnaní s tradičným antivírusovým softvérom; identifikácia známych aj neznámych kybernetických hrozieb a schopnosť reagovať okamžite; vylepšená viditeľnosť na koncovom zariadení a centralizovaný pohľad na všetky aktivity koncových zariadení v rámci organizácie.

Nástroje pre zavedenie viacfaktorovej autentifikácie

V rámci projektu sa rozšíri licenčné pokrytie viacfaktorovej autentifikácie plošne pre všetkých zamestnancov MZVEZ SR, ktorí pristupujú k systémom MZVEZ SR.

Nástroje, ktorých cieľom je zvýšiť schopnosť detekcie škodlivých aktivít a bezpečnostných incidentov, resp. ochrana koncových bodov, dát, dátových prenosov a sieťovej komunikácie

V rámci projektu sa zavádza systém EDR pre všetky koncové stanice a servery, ktorý prináša:

• systém pre monitorovanie a vyhodnocovanie kybernetických udalostí na koncových zariadeniach v sieti MZVEZ SR zabezpečí riešenie kybernetických bezpečnostných incidentov a ich monitorovanie, zaznamenávanie, vyhodnocovanie na koncovom zariadení. 
• ponúka rozšírené možnosti detekcie kybernetických hrozieb v porovnaní s tradičným antivírusovým softvérom. Dokáže identifikovať známe aj neznáme kybernetické hrozby a reagovať okamžite, ako efektívnejší nástroj proti stále vyvíjajúcim sa kybernetickým útokom. Súčasne poskytuje vylepšenú viditeľnosť na koncovom zariadení, poskytuje centralizovaný pohľad na všetky aktivity koncových zariadení v rámci organizácie. Poskytne bezpečnostným tímom identifikovať potenciálne hrozby a rýchlo konať.
• zabezpečí rýchlejšie reakcie na vzniknuté prevádzkové incidenty. Automatizáciou počiatočných reakcií pomáha EDR bezpečnostným tímom rýchlejšie reagovať na hrozby, čím sa minimalizujú škody a dopady na prevádzku a obnovu dát.
• umožní vylepšené vyhľadávanie hrozieb, prostredníctvom pokročilých analytických možností EDR, ktoré umožňujú bezpečnostným tímom proaktívne vyhľadávať hrozby v rámci siete a odhaľovať skryté zraniteľnosti ešte pred ich zneužitím na zariadení.

Bližší popis k technickej implementácii, infraštruktúrnym prvkom a aplikačným nástrojom je v kapitole Technologická vrstva.

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

Súčasťou projektu nie sú budované ani rozvíjané žiadne koncové služby. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do koncových a aplikačných služieb MZVEZ SR poskytovaných v rámci informačných systémov v správe MZVEZ SR.

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

Požiadavky na jazykovú lokalizáciu riešenia a používateľské prostredie dodávaných nástrojov bude v slovenskom alebo anglickom jazyku.

1. 
   
   1. Aplikačná vrstva

Obrázok 2 - Aplikačná architektúra TO-BE

Aplikačná vrstva MZVEZ SR pozostáva z viacerých informačných systémov podporujúcich výkon funkcií a činností definovaných na úrovni biznis architektúry. Je rozdelené primárne do nasledujúcich oblastí.

Front-end: predstavujú špecifické, najmä rezortné komponenty pre interakciu s používateľmi – Portály zamerané na poskytované elektronické služby, služby iných agendových systémov a komunikačný kanál formou mobilnej aplikácie Svetobežka.

Externé ISVS: externé systémy integrované so systémami MZVEZ SR (napr. CISMA, RFO, RPO a pod.)

Spoločné e-GOV moduly: združujú spoločné komponenty, ktoré riešia interakciu s používateľmi (občanmi, podnikateľmi a zamestnancami verejnej správy) – napr. modul elektronických schránok, autentifikačný modul, platobný modul, modul centrálnej elektronickej podateľne, modul elektronických formulárov, modul elektronického doručovania, notifikačný modul, modul procesnej integrácie a integrácie údajov.

Integračná vrstva: rieši integráciu a vzájomnú interoperabilitu informačných systémov verejnej správy SR na úrovni aplikačnej a dátovej integrácie a zabezpečuje služby.

Aplikačná vrstva: podporujú výkon konkrétnej agendy a realizujú kľúčové aplikačné služby pre oblasť dokladov, vízové služby, konzulárne služby a služby vnútornej správy. Súčasťou aplikačnej vrstvy sú aj prierezové Nástroje pre informačnú a kybernetickú bezpečnosť v rámci MZVEZ SR.

1. 
   
   1. 
      
      1. Rozsah informačných systémov – AS IS

N/A

V rámci projektu nie sú budované ani rozvíjané žiadne informačné systémy. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do informačných systémov MZVEZ SR v správe MZVEZ SR.

1. 
   
   1. 
      
      1. Rozsah informačných systémov – TO BE

N/A

V rámci projektu nie sú budované ani rozvíjané žiadne informačné systémy. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do informačných systémov MZVEZ SR v správe MZVEZ SR.

Súčasťou projektu sú nástroje pre zabezpečenie cieľov projektu v oblasti kybernetickej a informačnej bezpečnosti.

1. 
   
   1. 
      
      1. Využívanie nadrezortných a spoločných ISVS – AS IS

N/A

V rámci projektu nie sú budované ani rozvíjané žiadne informačné systémy. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do informačných systémov MZVEZ SR v správe MZVEZ SR.

1. 
   
   1. 
      
      1. Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013  e-Governmente – TO BE

N/A

V rámci projektu sa neplánuje integrácia ISVS na nadrezortné ISVS. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do informačných systémov MZVEZ SR v správe MZVEZ SR.

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

N/A

V rámci projektu sa neplánuje integrácia ISVS MZVEZ SR na ISVS iných organizácií. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do informačných systémov MZVEZ SR v správe MZVEZ SR.

1. 
   
   1. 
      
      1. Aplikačné služby pre realizáciu koncových služieb – TO BE

N/A

V rámci projektu sa neplánuje rozšírenie ani budovanie aplikačných služieb ISVS MZVEZ SR. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do koncových služieb ani aplikačných služieb poskytovaných informačnými systémami MZVEZ SR.

1. 
   
   1. 
      
      1. Aplikačné služby na integráciu – TO BE

N/A

V rámci projektu sa neplánuje rozšírenie ani budovanie aplikačných služieb ISVS MZVEZ SR. Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Projekt teda žiadnym spôsobom nezasahuje do koncových služieb ani aplikačných služieb poskytovaných informačnými systémami MZVEZ SR.

1. 
   
   1. 
      
      1. Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR.

1. 
   
   1. 
      
      1. Konzumovanie údajov z IS CSRU – TO BE

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR.

1. 
   
   1. Dátová vrstva

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR.

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

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR.

1. 
   
   1. 
      
      1. Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR.

1. 
   
   1. 
      
      1. Referenčné údaje

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. .Predmetom projektu nie sú referenčné údaje.

1. 
   
   1. 
      
      1. Kvalita a čistenie údajov

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. Predmetom projektu nie sú opatrenia v oblasti riadenia kvality údajov.

1. 
   
   1. 
      
      1. Otvorené údaje

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. Predmetom projektu nie sú opatrenia v oblasti publikovania otvorených údajov.

1. 
   
   1. 
      
      1. Analytické údaje

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. Predmetom projektu nie sú opatrenia v oblasti analytických údajov.

1. 
   
   1. 
      
      1. Moje údaje

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. Predmetom projektu nie sú opatrenia v oblasti publikovania mojich údajov.

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

N/A

Ciele projektu sú definované v oblasti kybernetickej a informačnej bezpečnosti v rámci rezortu MZVEZ SR. Cieľom projektu nie je úprava evidovaných údajov, koncových ani aplikačných služieb agendových informačných systémov MZVEZ SR. Predmetom projektu nie sú opatrenia v oblasti publikovania mojich údajov.

1. 
   
   1. Technologická vrstva

1. 
   
   1. 
      
      1. Prehľad technologického stavu - AS IS

Obrázok 3 - Technologická architektúra AS-IS

Súčasná technologická infraštruktúra MZVEZ SR je prevádzkovaná na 2 centrálnych lokalitách v ústredí MZVEZ SR a Datacentre na Kopčianskej a na 92 vzdialených lokalitách zastupiteľských úradov SR, geograficky rozložených po celom svete.

Súčasná infraštruktúra MZVEZ SR pozostáva z rôznych segmentov, ktoré podporujú širokú škálu používateľov: externých používateľov, interných používateľov v centrále, a interných používateľov v zastupiteľských úradoch.

Prístupová vrstva je členená na viacero logicky oddelených segmentov, ktoré sú oddelené firewallmi so stanovenými pravidlami formou ACL. Prístup k informačnému prostrediu MZVEZ SR je možný prostredníctvom:

• Internet,
• LAN,
• WAN.

Dôležitou vlastnosťou všetkých prístupových kanálov je ochrana prenášaných dát.

Ako ochranný mechanizmus je implementovaná technológia, ktorá prostredníctvom IPSec štandardu zabezpečuje šifrovanie prenášaných dát medzi centrálnymi a vzdialenými lokalitami WAN siete.

LAN sieť v centrálnych lokalitách je naimplementovaná ako dvojvrstvová. Jadro LAN siete tvoria redundantné vysokovýkonné L3 prepínače, ktorých úlohou je agregovať pripojenie LAN prepínačov z prístupovej vrstvy.

Do centrálnych prepínačov na oboch centrálnych lokalitách je pripojený firewallový systém, ktorý poskytuje bezpečné pripojenie LAN sietí do Govnetu a Internetu. Firewallový systém poskytuje ukončenie šifrovaných VPN pripojení z externých sietí do LAN siete MZVEZ SR.

Členenie infraštruktúry je možné do nasledovných funkčných celkov:

1. Front-end:

• 
  
  • 
    
    • 
      
      • Front-end poskytuje používateľom prístup k aplikáciám a službám prostredníctvom endpointov.

2. Back-end:

• 
  
  • 
    
    • 
      
      • Endpointy back-endu sú zodpovedné za správu systémových prístupov a interakcie.
      • Virtualizačná platforma umožňuje nasadenie viacerých aplikácií a prostredí na zdieľanom HW.
      • Load-balancer vyvažuje záťaž medzi servermi.
      • Diskový priestor poskytuje infraštruktúrne služby úložiska.
      • Sieťové a databázové služby sú základné komponenty pre prenos dát a správu systémov.

3. Služby kybernetickej a informačnej bezpečnosti:

• 
  
  • 
    
    • 
      
      • Služby pre manažment a zálohovanie konfigurácie sieťových prvkov sú limitované zastaranými technológiami, ktoré neposkytujú dostatočnú podporu pre novšie bezpečnostné protokoly napr. SD-WAN.
      • Služby pre bezpečnú sieťovú komunikáciu a viacfaktorovú autentifikáciu: pokrytie existujúcimi licenciami pre plošné nasadenie dvojfaktorovej autentifikácie nie je dostatočné, čo znamená, že len časť používateľov má prístup k tomuto dôležitému bezpečnostnému mechanizmu.
      • Riadenie zraniteľností a detekcia škodlivých aktivít na endpointoch sú čiastočne k dispozícii, detekciou nie sú pokryté všetky prvky infraštruktúry a riadenie zraniteľností je obmedzené úrovňou sofistikovanosti nástroja ako aj nedostatočným licenčným pokrytím.

4. Integrácia:

• 
  
  • 
    
    • 
      
      • Integračné endpointy sú zodpovedné za komunikáciu na služby systémov 3. strán bez aplikácie nástrojov na detekciu škodlivých aktivít.

5. Perimetrická bezpečnosť:

• 
  
  • 
    
    • 
      
      • Existujúci NG Firewall s končiacou podporou výrobcu poskytuje len základnú ochranu, no chýbajú moderné funkcie ako detekcia a detailná hĺbková analýza paketov, ktoré sú nevyhnutné pre zvládanie pokročilých hrozieb.

Niektoré zo súčasných sieťových prvkov a bezpečnostných zariadení nie sú už podporované výrobcom alebo im končí podpora, čo znamená, že neexistujú nové bezpečnostné záplaty ani aktualizácie. To zvyšuje riziko zraniteľností a znižuje schopnosť infraštruktúry brániť sa proti moderným hrozbám. Rovnako manažment týchto zastaraných prvkov je zložitejší, vyžaduje viac manuálnych zásahov a znižuje efektívnosť operácií. Neexistuje centralizovaný manažment, čo znamená, že každé zariadenie musí byť spravované individuálne, čo súčasne zvyšuje riziko chýb a tým ohrozuje kontinuitu prevádzky.

1. 
   
   1. 
      
      1. Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Projekt nemá vplyv na existujúce výkonnostné a kapacitné požiadavky.

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

Obrázok 4 - Technologická architektúra TO-BE

Technická architektúra -cieľový stav:

Po upgrade sa infraštruktúra výrazne vylepší, predovšetkým v oblastiach centrálneho monitoringu, správy sietí, a kybernetickej bezpečnosti. Nové prvky a technológie prinesú modernejšie riešenia na zvládanie bezpečnostných rizík, ako aj zlepšenie výkonnosti siete.

1. Modernizované sieťové prvky:

• 
  
  • 
    
    • 
      
      • Application Gateway a VPN Gateway budú modernizované, aby zlepšili bezpečnosť a výkonnosť správy pripojení. Nové verzie týchto prvkov poskytnú vyššiu odolnosť voči útokom, ako napríklad DDoS, a zabezpečia rýchlejší a stabilnejší prenos dát.

2. Centrálna správa a monitoring:

• 
  
  • 
    
    • 
      
      • Centrálny monitoring a manažment: V budúcom stave budú všetky kľúčové sieťové a bezpečnostné prvky spravované z jedného centrálneho miesta. To umožní lepší prehľad o aktuálnom stave infraštruktúry, rýchlejšiu reakciu na incidenty a automatizované hlásenia o stave siete a bezpečnosti. Centrálny monitoring tiež zníži manuálne zásahy potrebné na správu jednotlivých komponentov.

3. Zavedenie SD-WAN:

• 
  
  • 
    
    • 
      
      • SD-WAN (Software Defined WAN): S implementáciou SD-WAN sa infraštruktúra stane flexibilnejšou a lepšie pripravenou na dynamické potreby siete. SD-WAN umožní optimalizovať sieťový prenos medzi rôznymi lokalitami a cloudovými službami, zlepšiť latenciu a zvýšiť efektivitu využívania dostupných sieťových zdrojov.

4. Rozšírené bezpečnostné riešenia:

• 
  
  • 
    
    • 
      
      • URL filtering: Implementácia URL filtra poskytne lepšiu ochranu pred nevhodným alebo nebezpečným obsahom. Tento prvok automaticky blokuje prístup k stránkam, ktoré by mohli obsahovať malware, phishing alebo iné hrozby.
      • Secure DNS (bezpečné DNS): Secure DNS bude chrániť používateľov pred škodlivými webovými stránkami a útokmi na úrovni DNS (ako DNS spoofing). To prispeje k bezpečnejšej komunikácii a obmedzí riziko infiltrácie cez zraniteľnosti DNS.

5. Zlepšenia v kybernetickej bezpečnosti:

• 
  
  • 
    
    • 
      
      • Služby pre manažment a zálohovanie konfigurácie sieťových prvkov: Automatizácia konfigurácií umožní rýchlejšie zotavenie z incidentov a ľahšie obnovenie konfigurácií.
      • Služby pre bezpečnú sieťovú komunikáciu a viacfaktorovú autentifikáciu: Vylepšené autentifikačné mechanizmy znižujú riziko neoprávneného prístupu a pridávajú ďalšie vrstvy bezpečnosti.
      • Služby pre riadenie zraniteľností: Rýchlejšie identifikovanie zraniteľností a automatizované nasadzovanie bezpečnostných záplat.
      • Služby pre detekciu škodlivých aktivít na endpointoch: Rozšírená detekcia anomálií a ransomware útokov s použitím umelej inteligencie (AI) a strojového učenia.

6. Perimetrická bezpečnosť – NG Firewall:

• 
  
  • 
    
    • 
      
      • NG Firewall bude po upgrade poskytovať lepšiu ochranu perimetra. Nové funkcie firewallu umožnia detailnejšiu analýzu sieťovej prevádzky a riadenie prístupových pravidiel na základe hĺbkovej analýzy paketov.

Celkové výhody budúceho stavu:

• 
  
  • 
    
    • 
      
      • Zlepšená bezpečnosť: Vďaka centrálnej správe, URL filteringu, secure DNS a vylepšenej autentifikácii bude celá infraštruktúra lepšie chránená pred kybernetickými hrozbami.
      • Efektívnejšia správa siete: Centrálny monitoring a manažment umožnia jednoduchšiu správu a rýchlejšie riešenie incidentov bez potreby manuálnych zásahov na jednotlivých komponentoch.
      • Flexibilita a škálovateľnosť: SD-WAN umožní flexibilné prispôsobovanie siete aktuálnym potrebám a lepšiu optimalizáciu pre zahraničné lokality alebo cloud.
      • Vyššia dostupnosť a výkon: Modernizované sieťové prvky, ako napríklad load-balancer a vylepšené VPN pripojenia, zabezpečia vyššiu dostupnosť služieb a rýchlejšie spracovanie sieťového prenosu.
      • Lepšie reakcie na incidenty: Automatizované riešenia pre zraniteľnosti a bezpečnostné incidenty zabezpečia rýchlejšie obnovovanie infraštruktúry po bezpečnostných problémoch.

Konkrétne bude predmetom projektu dodávka hardvéru, softvéru a služieb pre infraštruktúru:

• 
  
  • 
    
    • 
      
      • Aktívny bezpečnostné zariadenie v počte 92 kusov pre zahraničné lokality
      • Centrálne aktívne bezpečnostné zariadenie v počte 2 kusov
      • Centrálny manažment na riadenie konfiguračných zmien zálohovania a vytvárania aplikačných dátových tokov
      • Nástroj detekciu a riadenie zraniteľností na endpointoch
      • Licencie pre rozšírenie pokrytia dvojfaktorovou autentifikáciou

Funkčné prevádzkové požiadavky na aktívne bezpečnostné zariadenia:

• 
  
  • 
    
    • 
      
      • Prevencia kybernetického útoku založeného na súboroch, jeho identifikácia a okamžité zastavenie,
      • Podpora strojového učenia (ML) na centrálnom zariadení,
      • Automatizácia bezpečnostných politík a odporúčaní, ktoré šetria čas a znižujú riziko zlyhania ľudského faktora,
      • Umožňujú koncovú viditeľnosť, bezpečnostné politiky, reportovanie a forenznú analýzu založenú na používateľoch a skupinách – nielen na IP adresy,
      • Poskytujú administrátorom dynamické bezpečnostné akcie založené na správaní sa koncových používateľov na obmedzenie podozrivých, alebo zlomyseľných používateľov,
      • Zavedenie kontrol a  aplikácia bezpečnostných politík na prenosy šifrované pomocou SSL/TLS, na prichádzajúce aj odchádzajúce aplikačné dátové toky vrátane TLSv1.3 a HTTP2.

Hardvérové požiadavky pre aktívne bezpečnostné zariadenie určené pre zahraničné lokality MZVEZ SR:

• 
  
  • 
    
    • 
      
      • Firewall priepustnosť - aplikačný mix minimálne 3 Gbps
      • Threat priepustnosť - aplikačný mix minimálne 2 Gbps
      • IP Sec VPN priepustnosť - aplikačný mix  minimálne 1,5 Gbps
      • Podpora:
        • OSPFv2/v3, BGP statického smerovania
        • Multicast PIM-SSM, IGMP v1, v2,v3
        • Meranie siete pre optimalizáciu aplikačných tokov ako sú jitter, packet loss, latency
        • Podpora dynamickej zmeny trasy
        • Podpora šifrovacích protokolov
        • Key exchange: IKEv2
        • Šifrovanie: minimálne AES  256-bit
        • Authentication minimálne : SHA-256, SHA-384, SHA-512
      • Sieťové rozhrania:
        • 8x 1G RJ45 minimálne
        • 1x 10/100/1000 out-of-band management port
      • Podpora hardvéru na obdobie 3 rokov vrátene subskripcií aktualizácií.

Hardvérové požiadavky na centrálne aktívne bezpečnostné zariadenia:

• 
  
  • 
    
    • 
      
      • Firewall priepustnosť - aplikačný mix minimálne 19 Gbps
      • Threat priepustnosť - aplikačný mix minimálne 10 Gbps
      • IP Sec VPN priepustnosť - aplikačný mix  minimálne 9 Gbps
      • Podpora:
        • OSPFv2/v3, BGP statického smerovania
        • Multicast PIM-SSM, IGMP v1, v2,v3
        • Meranie siete pre optimalizáciu aplikačných tokov ako sú jitter, packet loss, latency
        • Podpora dynamickej zmeny trasy
        • Podpora šifrovacích protokolov
        • Key exchange: IKEv2
        • Šifrovanie: minimálne AES  256-bit
        • Authentication minimálne : SHA-256, SHA-384, SHA-512
      • Sieťové rozhrania:
        • 8x 1G/10G SFP/SFP+ minimálne
        • 4x 25G SFP28 minimálne
        • 1x 10/100/1000 out-of-band management port
      • Podpora hardvéru na obdobie 3 rokov vrátene subskripcií a aktualizácií.

Centrálny manažment na riadenie konfiguračných zmien zálohovania a vytvárania aplikačných dátových tokov

Poskytuje sieťovú kybernetickú bezpečnosť pomocou jednotnej centralizovanej platformy, vrátane bezpečnostných pravidiel pre infraštruktúrne bezpečnostné prvky ako je firewall. Integruje prevenciu hrozieb, filtrovanie adries URL, DNS, informovanosť o aplikáciách, identifikáciu používateľov, kontrolu prístupu a filtrovanie.

• 
  
  • 
    
    • 
      
      • Podpora na obdobie 3 rokov vrátene subskripcií a aktualizácií.

Nástroj detekciu a riadenie zraniteľností na endpointoch

EDR – systém pre monitorovanie a vyhodnocovanie kybernetických udalostí na koncových zariadeniach v sieti MZVEZ SR zabezpečí riešenie kybernetických bezpečnostných incidentov a ich monitorovanie, zaznamenávanie, vyhodnocovanie na koncovom zariadení. 

EDR ponúka rozšírené možnosti detekcie kybernetických hrozieb v porovnaní s tradičným antivírusovým softvérom. Dokáže identifikovať známe aj neznáme kybernetické hrozby a reagovať okamžite, ako efektívnejší nástroj proti stále vyvíjajúcim sa kybernetickým útokom. Súčasne poskytuje vylepšenú viditeľnosť na koncovom zariadení, poskytuje centralizovaný pohľad na všetky aktivity koncových zariadení v rámci organizácie. Poskytne bezpečnostným tímom identifikovať potenciálne hrozby a rýchlo konať.

Zabezpečí rýchlejšie reakcie na vzniknuté prevádzkové incidenty. Automatizáciou počiatočných reakcií pomáha EDR bezpečnostným tímom rýchlejšie reagovať na hrozby, čím sa minimalizujú škody a dopady na prevádzku a obnovu dát.

Umožní vylepšené vyhľadávanie hrozieb, prostredníctvom pokročilých analytických možností EDR, ktoré umožňujú bezpečnostným tímom proaktívne vyhľadávať hrozby v rámci siete a odhaľovať skryté zraniteľnosti ešte pred ich zneužitím na zariadení.

Funkčné prevádzkové požiadavky na EDR riešenie:

• 
  
  • 
    
    • 
      
      • Prístup pre analytikov SOC prostredníctvom prihlásenia sa do jednej centrálnej manažment konzoly, prístup ku všetkým dátam, aktívam, alertom a zraniteľnostiam, ktoré sú zbierané, generované alebo sprístupňované zo všetkých monitorovaných zariadení,
      • Možnosť prispôsobiť/nastaviť politiky, pravidlá a procesy dodaného riešenia pomocou jednej centrálnej manažment konzoly, alebo API rozhrania,
      • Poskytovať retenciu údajov z agentov nasadených na koncových bodoch, ktoré sú uložené v centrálnom úložisku, po dobu minimálne 1 roka. Údajmi sa rozumejú všetky telemetrické dáta alebo nespracované (tzv. raw) udalosti (spustenie procesu, príkazu alebo inej aktivity na koncovom bode), ktoré EDR riešenie získava kontinuálne z koncového bodu.
      • Poskytovať možnosť dodatočne rozšíriť retenciu údajov zvýšením kapacity úložiska.
      • Zabezpečiť požadované funkcionality na koncovom bode jedným agentom,
      • Vyžaduje sa aby všetky komponenty riešenia bolo možné nainštalovať a prevádzkovať v On Premise alebo Cloude,
      • Podpora integrácie s  bezpečnostnými nástrojmi pomocou API,
      • Podpora možnosti inštalácie bez požiadavky na reštart koncového bodu,
      • Všetka komunikácia medzi agentom a centrálnou manažment konzolou je šifrovaná,
      • Dáta musia byť uložené na šifrovaných úložiskách,
      • Podporuje integrovanie MISP platformy za účelom obohacovania obsahu o ďalšie informácie o hrozbách (Threat Intelligence tretích strán) a ich pravidelnú aktualizáciu,
      • Framework MITRE ATT&CK pre pomenúvanie/klasifikáciu detekčných pravidiel.
      • Vlastné detekčné pravidlá musí byť možné kategorizovať podľa frameworku MITRE ATT&CK.

Predmetom projektu bude dodávka a podpora softwarového vybavenia na detekciu a monitoring:

• 
  
  • 
    
    • 
      
      • EDR Protect, Respond, Monitor, Discover Subscription 2,125 Endpoints na obdobie 3 rokov vrátene aktualizácií.

Predmetom projektu bude dodávka softwarového vybavenia na rozšírenie dvojfaktorovej autentifikácie prostredníctvom mobilných zariadení:

• 
  
  • 
    
    • 
      
      • Software one-time password tokens for iOS, Android and Windows Phone mobile devices. Perpetual licenses for 1000 users.

Súvisiace služby:

• 
  
  • 
    
    • 
      
      • Analýza prevádzkového prostredia MZVEZ SR
      • Vypracovanie dokumentácie pre nasadenie
      • Inštalácia, konfigurácia, POC
      • Testovanie a ladenie konfigurácie
      • Nasadenie EDR systému
      • Finálne ladenie a hardening aktívnych bezpečnostných zariadení po distribúcii na zahraničné lokality
      • Dokumentácia skutočného vyhotovenia riešenia

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

Kapitola nie je relevantná pre projekt, nakoľko projekt nepočíta s využitím služieb vládneho cloudu. Projekt je zameraný na zvýšenie úrovne kybernetickej a informačnej bezpečnosti MZVEZ SR formou nákupu technických prostriedkov, programových prostriedkov a služieb v oblasti kybernetickej a informačnej bezpečnosti.

1. 
   
   1. Bezpečnostná architektúra

Navrhovaná bezpečnostná architektúra je v súlade s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS,  pre manipuláciu so samotnými dátami, alebo technické/technologické zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• Vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• Vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (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)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

1. Závislosti na ostatné ISVS / projekty

Projekt nie je závislý od iných ISVS alebo projektov.

1. Zdrojové kódy

Projekt je zameraný na zvýšenie úrovne kybernetickej a informačnej bezpečnosti MZVEZ SR formou nákupu hardvéru a bezpečnostného softvéru. Bezpečnostný softvér, ktorý je súčasťou projektu má charakter Preexistentného obchodne dostupného proprietárneho SW. Tento SW je na trhu bežne dostupný, t. j. ponúkaný na území Slovenskej republiky alebo v rámci Európskej únie  bez obmedzení a spĺňa znaky výrobku alebo tovaru v zmysle slovenskej legislatívy. Vzhľadom na to, že SW nie je vyrábaný/dodávaný na základe špecifických potrieb MZVEZ SR a aplikujú sa naň osobitné licenčné podmienky, nie je táto kapitola pre projekt relevantná. V prípade ak v rámci projektu dôjde k vytvoreniu autorského diela budú sa preň aplikovať ustanovenia v súlade s odporučeniami MIRRI a príslušnej legislatívy za účelom zabezpečenia časovo a územne neobmedzenej nevýhradnej licencie a zdrojových kódov pre použitie iným orgánom riadenia, ak to bezpečnostná politika MZVEZ SR umožní. Z povahy legislatívy realizáciou projektu nejde o vendor-lock ale využitie existujúcich preexistentných nástrojov a platforiem, ktoré sú poskytované viacerými subjektmi ako aj služby späté s ich inštaláciou, konfiguráciou a prevádzkou.

1. Prevádzka a údržba

Prevádzka a údržba bude prebiehať na úrovni interných kapacít MZVEZ SR v rozsahu L1-L3 (L3 podpora bude zabezpečená aj v rámci štandardných podpôr hardvérových a softvérových nástrojov výrobcom/dodávateľom). Pre hlásenie incidentov a problémov bude využívaný nástroj service-desku. Úlohou pracovníkov service-desku je riešenie incidentov, problémov a požiadaviek na úrovni identifikácie, preverenia, postúpenia zodpovednej osobe na vykonanie opravy, resp. kontaktovanie zazmluvnenú podporu výrobcu/dodávateľa v prípade komplexnejších problémov L3.

1. 
   
   1. Prevádzkové požiadavky

Manažment prevádzkových požiadaviek bude riadený internou dokumentáciou MZVEZ SR v rozsahu a spôsobom pre L1-L3.

1. 
   
   1. 
      
      1. Úrovne podpory používateľov

Service-desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

L1 podpora - 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 podpora - 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 podpora - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťažnejších hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov, ktorú v prípade komplexnejších problémov a incidentov bude zabezpečovať výrobca/dodávateľ implementovaných nástrojov.

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

Service-desk je dostupný pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v service-desku,

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

Služby podpory prevádzky na úrovni L3, ak ju nebude možné zabezpečiť internými kapacitami, bude zabezpečená od výrobcu/dodávateľa HW a SW nástrojov. Táto podpora bude po realizácii projektu financovaná z interných zdrojov MZVEZ SR.

1. 
   
   1. 
      
      1. Riešenie incidentov – SLA parametre

V rámci navrhovaného projektu sa nepredpokladá zmena existujúcich SLA parametrov prevádzkovaných ISVS v správe MZVEZ SR.

1. 
   
   1. Požadovaná dostupnosť IS:

V rámci navrhovaného projektu sa nepredpokladá zmena súčasných výkonnostných požiadaviek a požiadaviek na dostupnosť, zálohovanie a obnovu prevádzkovaných ISVS v správe MZVEZ SR.

1. Požiadavky na personál

V rámci projektu vystupujú nasledovné role:

• Projektový manažér
• Biznis vlastník
• Kľúčový používateľ
• Manažér kybernetickej a informačnej bezpečnosti
• Špecialista na publicitu
• Špecialista pre bezpečnosť IT (dodávateľ)

Podrobný popis postavenia, zodpovedností a povinností jednotlivých rolí v projekte je bližšie uvedený v Projektovom zámere k projektu.

1. Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu bude prebiehať podľa metodiky waterfall v súlade s vyhláškou č. 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy a v súlade s riadiacou dokumentáciou finančného mechanizmu OP SK,  prostredníctvom ktorého má byť projekt financovaný.

1. Prílohy

1.História dokumentu

2.Účel dokumentu

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.
Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky má obsahovať opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.
Inštrukcia: Šedý text v celom dokumente predstavuje nápoveď pre vyplnenie dokumentu, po vyplnení kapitol odporúčame text šedou farbou vymazať.
Dokumenty ukladajte s prefixom I_XX.
Odporúčame, aby ste si TABUĽKOVÉ VSTUPY  vo formáte EXCEL spravovali v jednom centrálnom súbore s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

2.1Použité skratky a pojmy

2.2Konvencie pre typy požiadaviek (príklady)

Zvoľte si konvenciu pre označovanie požiadaviek, súborov, atď. Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné (funkcionálne), nefunkčné (kvalitatívne, výkonové a pod.). Podskupiny v hlavných kategóriách je možné rozšíriť podľa potrieb projektu, napríklad:
Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:
FRxx

• U – užívateľská požiadavka
• R – označenie požiadavky
• xx – číslo požiadavky
  Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:
  NRxx
• N – nefunkčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky
  Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.
  Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, musia byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek I-04 (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

3.Popis navrhovaného riešenia

Opis navrhovaného riešenia sa spracováva až po definovaní vybranej alternatívy riešenia na základe výsledkov MCA z dokumentu Projektový zámer (I-02).
Obsahom tejto kapitoly je manažérsky sumár navrhovaného riešenia z pohľadu architektúry.

4.Architektúra riešenia projektu

Spracovanie a rozsah tejto kapitoly závisí od typu projektu – budovanie ISVS, rozvoj ISVS, migrácia do vládneho cloudu, nákup HW atď. Napríklad pri budovaní/rozvoji ISVS navrhujete všetky vrstvy architektúry (biznis, aplikačná, technologická), pri nákupe HW alebo migrácii systému na infraštruktúrne cloudové služby nie je potrebné popisovať detailne biznis a aplikačnú vrstvu architektúry, postačuje v príslušných kapitolách uviesť len nevyhnutné detaily ilustrujúce dopad projektu v týchto vrstvách, aby príslušné zainteresované osoby mohli vyhodnotiť, akým spôsobom ich projekt ovplyvní.
Architektúra navrhovaného riešenia projektu musí byť v súlade s funkčnými, nefunkčnými a technickými požiadavkami definovanými v katalógu požiadaviek (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek, I-04 Katalóg požiadaviek ).
V  dokumente Prístup k projektu popíšte súčasný stav (ďalej AS IS) architektúry aj s príslušným architektonickým modelom a budúci stav (ďalej TO BE) architektúry riešenia aj s príslušným architektonickým modelom.
AS IS architektúra a TO BE architektúra musia byť spracované tak, aby bol zreteľný výsledok projektu (zmena).
Obsah tejto kapitoly je tiež prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs). Objednávateľ¹ plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom centrálneho metainformačného systému verejnej správy (MetaIS) bezodkladne podľa § 12 ods. 1 písmeno b zákona 95/2019 Z.z.
Objednávateľ priebežne aktualizuje evidenciu e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs), vrátane architektonických modelov. Pri odovzdaní výstupu I-03 Prístup k projektu objednávateľ v rámci výstupu M-06 Evidencia e-Government komponentov v MetaIS,:

• vytvorí náhľady architektúry v modelovacom nástroji, ktorý môže byť buď integrovaný na spoločný repozitár  architektonických modelov verejnej správy², alebo ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov,
• uloží architektonické modely súčasnej a budúcej architektúry riešenia buď do repozitára architektonických modelov verejnej správy alebo do projektovej dokumentácie I-03 Prístup k projektu ako prílohu  vo výmennom formáte pre uloženie modelu,³ 
• aktualizuje v MetaIS e-Government komponenty, ktoré budú realizované alebo menené projektom alebo veľkou zmenovou požiadavkou a to koncové služby, ISVS, ich moduly, aplikačné služby, atribúty a vzájomné vzťahy týchto e-Government komponentov a ich vzťahy (integrácie) na spoločné ISVS alebo ISVS iných správcov, ktoré budú využívať. 
  Orgán vedenia vyhodnotí náležitosti výstupu I-03 a M-06 v súlade s prílohou č. 2 vyhlášky MIRRI č. 401/2023 Z.z.
  Vyžadujeme, aby návrh architektúry bol zakreslený pomocou modelovacieho jazyka Archimate minimálne vo verzii 3 (linka na špecifikáciu: https://www.opengroup.org/archimate-forum/archimate-overview). Pre modelovanie a popis AS IS aj TO BE architektúry odporúčame použiť modelovací nástroj⁴, ktorý podporuje export modelu do štandardizovaného formátu „The Open Group ArchiMate Model Exchange File Format Standard“.
  V návrhu zohľadnite usmernenia z používateľskej príručky centrálneho metainformačného systému verejnej správy (aktuálna verzia je zverejnená na: https://metais.vicepremier.gov.sk/help) pre popis, modelovanie a zápis informácií o komponentoch do metainformačného systému verejnej správy (ďalej MetaIS).
  Pre detailnejší popis procesov, ktorých sa projekt týka je možné použiť tiež modelovací jazyk BPMN (ISO 19510) a modelovací nástroj, ktorý podporuje tento jazyk a export súborov podľa špecifikácie BPMN 2.0⁵. Pre analýzu a modelovanie procesov využite metodiky optimalizácie procesov MV SR pripravené v rámci projektu Optimalizácia procesov vo verejnej správe: https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave.
  Pre detailnejší návrh riešenia v aplikačnej vrstve je možné použiť aj jazyk UML (ISO 19505).
  Modely môžu obsahovať viac náhľadov na riešenú oblasť tak, aby dostatočne zrozumiteľne popisovali architektúru riešenia a e-Government komponenty, ktoré majú byť predmetom dodávky projektu, ako aj ich vzťahy a závislosti navzájom a vzťahy na ostatné komponenty eGov (napr. spoločné moduly ústredného portálu verejnej správy, iné vlastné alebo externé ISVS, služby alebo dátové registre).

4.1Biznis vrstva

Doplňte výstižné grafické zobrazenia (pohľady na model biznis architektúry) a popis AS IS stavu biznis vrstvy architektúry a krátky popis TO BE stavu z pohľadu biznis architektúry,
Doplňte popis súčasného - AS IS - stavu biznis vrstvy:

• Identifikácia kľúčových životných situácii (ŽS), ktorých sa projekt týka. Sústrediť sa menší počet najdôležitejších životných situácií, ktoré predstavujú väčšinu ekonomických nákladov občanov/podnikateľov a nákladov úradov.
• Identifikácia existujúcich koncových služieb, ktorých sa projekt týka
• Procesné diagramy, ktoré popisujú postupnosť krokov, komunikácie a zodpovedností, ktoré sú v súčasnom stave potrebné pre vyriešenie každej dotknutej ŽS alebo poskytnutie koncovej služby, vypracované v súlade s metodikou optimalizácie procesov MV SR (či už v spolupráci s MV SR v rámci projektu Optimalizácie procesov alebo samostatnom projekte),
• Optimalizačné príležitosti, ktoré popisujú možnú zmenu vo výkone procesov VS, v IKT podporujúcich výkon procesov, prípadne v organizačnom zabezpečení výkonu procesov ŽS.
• Ukazovatele a metriky dôležité pre vyhodnotenie aktuálneho stavu poskytovania služieb, napr.:
• • skutočné počty podaní (interakcií, návštev úradov) pre jednotlivé kroky a životné situácie,
  • skutočné časy trvania jednotlivých krokov v procese vybavenia ŽS,
  • skutočné finančné príjmy, spojené s jednotlivými procesnými krokmi (správne poplatky, prípadné pokuty a sankcie),
  • skutočné finančné náklady, spojené s jednotlivými procesnými krokmi (náklady na tlač, obálkovanie, poštovné, atď.).
    Doplňte popis budúceho - TO BE - stavu biznis vrstvy:
• Doplňte výstižné grafické zobrazenia (pohľady na model architektúry riešenia) a popis TO BE stavu navrhovaného riešenia vybraného na základe MCA (Multikriteriálna analýza) popísanej v Projektovom zámere. Navrhované riešenie musí korešpondovať s procesnými diagramami a musí popisovať spôsob dosiahnutia a monitoringu prínosov uvedených v CBA,
• Uveďte a znázornite popis zmien medzi súčasným a budúcim stavom navrhovaného riešenia,
• Identifikujte a popíšte projektom budované, resp. rozvíjané koncové služby. Do tabuľky prehľadu koncových služieb uveďte všetky projektom budované/rozvíjané koncové služby, ktoré budú výstupom projektu. Projektom budované/rozvíjané koncové služby musia byť evidované v MetaIS s fázou životného cyklu Plánovaná a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy. Projektom budované/rozvíjané koncové služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.1 (https://metais.vicepremier.gov.sk/help),
• Procesné diagramy, ktoré popisujú postupnosť krokov, komunikácie a zodpovedností, ktoré budú potrebné pre vyriešenie každej dotknutej ŽS alebo poskytnutie koncovej služby, vypracované v súlade s metodikou optimalizácie procesov MV SR (či už v spolupráci s MV SR v rámci projektu Optimalizácie procesov alebo samostatnom projekte),
• Očakávané ukazovatele a metriky dôležité pre vyhodnotenie dosiahnutia cieľov projektu a vyhodnotenie úrovní poskytovania služieb, napr.:
  • očakávané počty podaní (interakcií, návštev úradov) pre jednotlivé kroky a životné situácie,
  • očakávané časy trvania jednotlivých krokov v procese vybavenia ŽS,
  • očakávané finančné príjmy, spojené s jednotlivými procesnými krokmi (správne poplatky, prípadné pokuty a sankcie),
  • očakávané finančné náklady, spojené s jednotlivými procesnými krokmi (náklady na tlač, obálkovanie a poštovné, atď.).
• Trvanie vybavenia ŽS zdôvodní predkladateľ projektu jedným z nasledujúcich spôsobov:
  • Vynechanie procesného kroku z dôvodu reformy (zmeny legislatívy) a/alebo jeho automatizácie (čas potrebný na vykonanie tohto kroku tak bude 0).
  • Odhadom dĺžky trvania procesného kroku v budúcom stave (čas potrebný na vykonanie tohto kroku bude iný ako v súčasnom stave).
  • Odhadom dĺžky trvania nového procesnú kroku, ktorý vznikol z dôvodu procesnej reformy, zmeny legislatívy či zmeny fungovania informačného systému (čas potrebný na vykonanie tohto kroku bude väčší ako nula).
    
    Obrázok 1 Procesný diagram - príklad

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

Obrázok 2 Model biznis architektúry (aktéri-koncoví používatelia, koncové služby, procesy) – príklad

4.1.2Jazyková podpora a lokalizácia

Uveďte a do katalógu požiadaviek zaevidujte požiadavky na jazykovú podporu a lokalizáciu používateľského rozhrania a výstupov do viacerých jazykov v riešení TO BE stavu.

4.2Aplikačná vrstva

Popíšte aplikačnú architektúru riešenia na úrovni ISVS, ich modulov a vzťahov medzi nimi a vzťahov na externé prostredie. Podľa potreby zvýraznite dôležité zmeny v architektúre, dôležité vzťahy a toky dát, vzťah riešených ISVS s okolím a externými SVS.
Budované/rozvíjané informačné systémy, vrátene ich modulov musia byť evidované v MetaIS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS kap. 2.1.4 (https://metais.vicepremier.gov.sk/help).
Uveďte model a popis AS IS stavu aplikačnej vrstvy architektúry: informačné systémy (ISVS), aplikačné služby a ich podpora realizácie koncových služieb.
Uveďte model a popis TO BE stavu navrhovaného riešenia aplikačnej vrstvy architektúry s prepojením na biznis architektúru – ako aplikačná architektúra a jej komponenty podporuje realizáciu biznis služieb, riešenia živ. situácií a splnenie cieľov projektu

Obrázok 3 Model aplikačnej architektúry – príklad

Obrázok 4 Príklad náhľadu architektúry v notácii ArchiMate s hlavnými e-Government komponentami a ich vzťahmi podľa metamodelu evidencie eGovernment komponentov v MetaIS

4.2.1Rozsah informačných systémov – AS IS

Uveďte dotknuté ISVS a ich moduly AS IS:

4.2.2Rozsah informačných systémov – TO BE

Uveďte informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu – TO BE stav:

4.2.3Využívanie nadrezortných a spoločných ISVS – AS IS

Uveďte informácie o využívaných, resp. nevyužívaných nadrezortných ISVS (Spoločných ISVS a spoločných blokov SaaS) – AS IS stav. Všetky realizované integrácie na nadrezortné ISVS v AS IS stave musia byť evidované v MetaIS.

4.2.4Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE

Uveďte plánované využívanie nadrezortných a spoločných ISVS v TO BE stave.

• Povinnosť využívať nadrezortné ISVS ustanovuje najmä zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) a iné legislatívne predpisy. Prehľad a informácie o nadrezortných ISVS sú uvedené v prílohe P8 Zoznam nadrezortných blokov a podporných spoločných blokov Používateľskej príručky MetaIS.

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

Uveďte v nasledujúcej tabuľke prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb inf. systémov tretích strán v TO BE stave.
Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS .

4.2.6Aplikačné služby pre realizáciu koncových služieb – TO BE

Uveďte v nasledujúcej tabuľke budované aplikačné služby, realizáciu koncových služieb aplikačnou službou, koncová služba by mala byť realizovaná aspoň jednou aplikačnou službou (KS môžu realizovať aj viaceré aplikačné služby). Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS.

4.2.7Aplikačné služby na integráciu – TO BE

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS):

• Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy,
• Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.3.1 a kap. 2.1.3.3.2. Detailný popis služieb IS CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
• Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gatewy).
• Budované aplikačné služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.

  AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)

• Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona 305/2013 Zz. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:

• Na informáciu sú v nasledujúcich diagramoch vzory modelovania integrácie na nadrezortné a spoločné moduly podľa § 10 zákona 305/2013 Zz podľa usmernenia v Používateľskej príručke MetaIS. Vo vašom finálnom dokumente tieto vzory vymažte a nahraďte svojím diagramom ilustrujúcim plánované integrácie:
  
  Obrázok 5 Integrácie na spoločné moduly ÚPVS – ref. príklad
  
  Obrázok 6 Integrácie na IS CAMP- referenčný príklad
  
  Obrázok 7 Integrácie na IS CSRÚ – ref. príklad
  
   

4.2.8Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

Uveďte v nasledujúcej tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Uveďte v nasledujúcej tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

4.3Dátová vrstva

Každá organizácia by mala mať zavedený systematický manažment údajov (vrátane nastavenie príslušných procesov a metodík pre správu celého životného cyklu údajov) a byť schopná evidovať a spravovať údaje v strojovo-spracovateľnej podobe. V kapitolách nižšie je potrebné popísať AS IS a následne TO BE stav organizácie z pohľadu údajov, ich štruktúry a následného výkonu príslušnej agendy vo vzťahu k projektu.

4.3.1Údaje v správe organizácie

Popíšte dátovú architektúru riešenia na úrovni objektov evidencie a vzťahov medzi nimi v AS IS stave. Pri popise je potrebné vychádzať z metodiky Ministerstva vnútra - Metodika identifikácie, vizualizácie a referencovania údajov pri dátovom modelovaní vo verejnej správe (zverejnená na stránke https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave v Aktivite 5).

• Uveďte diagramy tried a štruktúrovaný popis entít a atribútov vhodný aj pre strojové spracovanie. Diagram tried uveďte vo forme úplného logického modelu.
• Popíšte procesy riadenia životného cyklu správy údajov, kde je potrebné zrozumiteľne zdokumentovať dátové štruktúry, proces tvorby údajov, štatistické metodológie (ak budú použité), dátové zdroje, kontext a ďalšie aspekty manažmentu údajov. Proces riadenia pre manažment údajov musí byť zavedený nad informačnými systémami, ktoré obsahujú objekty evidencie a budú riešené v projekte.
• Popíšte zavedenie systematického manažmentu údajov v organizácií.
• Po organizačnej stránke je podmienkou zavedenie role dátového kurátora (dátový architekt) v organizácii, v rozsahu ako ju definuje strategická priorita Manažment údajov a strategická priorita Otvorené údaje, ktorý bude zodpovedný za koncept systematického manažmentu údajov a úpravu organizačnej štruktúry smerom k vytvoreniu rezortnej dátovej kancelárie.

4.3.2Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Pre budované informačné systémy vytvorte tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom.

• Úlohou doménového modelu je vizuálne znázorniť rozsah predmetných údajov daného projektu, pričom je možné abstrahovať od nepodstatných detailov. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk),
• V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
• Doménový model by mal byť v súlade s existujúcim Centrálnym modelom údajov verejnej správy (viac informácií na: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/interoperabilita/ a https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.).
• Pre modelovanie doménového modelu je potrebné stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v novom modeli použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML (pre zjednodušený doménový model môžete použiť aj jazyk ArchiMate).
• V prípade, že sa používa dátový prvok z Centrálneho dátového modelu je nutné použiť skrátenú formu URI identifikátora daného prvku, napr. pper:PhysicalPerson je skrátený tvar https://data.gov.sk/def/ontology/physical-person/PhysicalPerson

ID OE	Objekt evidencie - názov	Objekt evidencie - popis	Referencovateľný identifikátor URI dátového prvku
			(Ak nie je priradené URI uveďte „Nemá“)
			Obrázok 8 Doménový model - príklad Obrázok 9 Zjednodušený doménový model - príklad

4.3.3Referenčné údaje

V národnej koncepcii informatizácie verejnej správy bol zadefinovaný princíp „jedenkrát a dosť“, ku ktorému boli ďalej detailnejšie rozpracované úlohy v dokumente Strategická priorita Manažment údajov. Cieľom je dosiahnutie stavu, kedy orgány verejnej moci pri poskytovaní svojich služieb odstránia povinnosti občanov alebo podnikateľských subjektov predkladať údaje vo forme rôznych výpisov, odpisov, potvrdení, atď., ktorými už disponuje verejná správa v rámci svojich registrov.
Za účelom dosiahnutia TO BE stavu, z ktorého bude benefitovať občan / podnikateľský subjekt úsporou svojho času a prostriedkov, je potrebné popísať viacero nasledujúcich krokov na úrovni participujúcich subjektov verejnej správy:

• Popísať, aká je aktuálna kvalita údajov v zdrojových registroch,
• Uviesť dôvod vyhlásenia referenčných údajov (údaje musia byť k subjektu evidencie jedinečné a k týmto údajom je podľa osobitných predpisov uvedená domnienka správnosti),
• Uviesť poskytovateľov a konzumentov (vlastníkov) údajov do centrálnej platformy dátovej integrácie (modulu procesnej integrácie a integrácie údajov slúžiacim pre výmenu údajov pri výkone verejnej moci elektronicky),
• Popísať legislatívu a procesy vo verejnej správe (konkrétnej životnej situácie), pre konkrétne údaje identifikované v projekte (odstránenie legislatívnych povinností predkladať úradom výpisy a potvrdenia a automatizácia procesov viažucich sa k životným situáciám a interakcie s občanom / podnikateľským subjektom).

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

V tejto časti dokumentu je potrebné definovať/popísať rozsah a štruktúru na úrovni registrov / objektov evidencie / údajov, ktoré sa navrhujú vyhlásiť za referenčné v naviazanosti na ich zrealizovateľné vzájomné zdieľanie medzi subjektami verejnej správy a dodržanie pravidla, že za referenčné údaje/atribúty sú vyhlasované také údaje/atribúty, ktoré sú k subjektu evidencie jedinečné a práve tie, ktoré využívajú subjekty verejnej správy pri realizácii princípu „1 x a dosť“.

• Popísať a zdôvodniť navrhované objekty evidencie k vyhláseniu za referenčné z pohľadu ich dátovej kvality v zmysle podkapitoly venujúce sa kvalite a čisteniu údajov,
• Popísať, ako bude zabezpečená dostupnosť poskytovania navrhovaných objektov evidencie za referenčné (t.j. v rámci nich údaje/atribúty) cez Modul procesnej integrácie a integrácie údajov, t.j. integráciou cez jeho dátovú časť - IS CSRÚ,
• Uviesť časový harmonogram procesu vyhlasovania a zmeny referenčných údajov. Informácie o procese vyhlasovania a zmeny referenčných údajov sú uvedené v metodickom usmernení MIRRI o postupe zaraďovania referenčných údajov do zoznamu referenčných údajov vo väzbe na referenčné registre a vykonávania postupov pri referencovaní: https://metais.vicepremier.gov.sk/confluence/download/attachments/2621442/Metodicke_usmernenie_UPVII_3639_2019_oDK_1_FINAL.pdf?version=1&modificationDate=1554714761337&api=v2
• V nasledujúcej tabuľke uveďte návrh na vyhlásenie a zmeny referenčných údajov, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

Identifikujte a uveďte v nasledujúcej tabuľke potenciálnych konzumentov objektov evidencie, ktoré budú poskytnuté na dátovú integráciu realizáciou projektu, vrátane ich oprávnenosti/nároku na konzumovanie v zmysle konkrétnych ustanovení osobitných právnych predpisov na strane konzumenta, prípadne aj na strane poskytovateľa. V nadväznosti na uvedené identifikujte osobitné právne predpisy (až na úroveň konkrétneho ustanovenia), ktoré je nutné novelizovať v záujme dosiahnutia TO BE stavu využitia údajov a jeho bezproblémovej aplikovateľnosti.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:
Poznámka: Pre úspešné napojenie ISVS na IS CSRÚ v roli konzumenta údajov je nutné postupovať podľa integračného manuálu IS CSRÚ.

4.3.4Kvalita a čistenie údajov

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

Zhodnoťte objekty evidencie so zameraním sa na významnosť kvality údajov pre biznis procesy (možné riziká v dôsledku dátovej nekvality), t.j. ak bude údaj nepresný, bude mať nesprávnu hodnotu, formát, nebude vyplnený, alebo stotožnený voči referenčnému registru, ako významne to ovplyvní príslušnú agendu:

• uveďte, či a ako bude zapracovaná možnosť overenia hodnoty údaja,
• uveďte, či bude zapracované pri zadávaní údajov obmedzenie hodnôt, napríklad formou číselníka, alebo podmienok,
• uveďte, či budú dáta migrované z iného ISVS.
  V nasledujúcej tabuľke vyhodnoťte významnosť a citlivosť kvality údajov a prioritu (poradie dôležitosti) pre meranie dátovej kvality objektov evidencií – t.j. poradie, v akom bude správca ISVS približne realizovať meranie dátovej kvality a čistiť údaje. Prvé 2 záznamy sú vyplnené ako príklad. Vymažte, resp. prepíšte ich vlastnými údajmi. Riadky v tabuľke doplňte podľa potreby.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

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

V nasledujúcej tabuľke definujte potrebné kapacity pre zabezpečenie riadenia dátovej kvality – napr. dátový kurátor, data steward, dátový špecialista pre dátovú kvalitu, databázový špecialista, projektový manažér a pod. (informácie k téme: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/datova-kvalita/ )

4.3.5Otvorené údaje

V nasledujúcej tabuľke doplňte objekty evidencie, ktoré budú realizáciou projektu sprístupnené ako otvorené údaje. Uveďte názov objektu evidencie (identifikované v kapitole dátový rozsah projektu) pre kategóriu otvorených údajov a stanoviť úroveň požadovanej kvality (interoperability) otvorených údajov. Pravidlá pre úroveň interoperability verejných otvorených údajov sú stanovené v https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=23986518.
Požadovaná kvalita:

• Automatizované publikovanie otvorených údajov v kvalite 3★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk). Formát CSV, XML, ODS, JSON
• Automatizované publikovanie otvorených údajov v kvalite 4★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON
• Automatizované publikovanie otvorených údajov v kvalite 5★ (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na data.gov.sk) Formát údajov RDF, OWL, TriX, JSON.
  V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE:

4.3.6Analytické údaje

Analytické údaje predstavujú obrovskú skupinu dát získavaných vysokou rýchlosťou z vysokého počtu rôznych typov zdrojov. V priestore verejnej správy sa jedná o dátové zdroje, ktoré sú vytvárané a spravované jednotlivými organizáciami za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Tieto údaje môžeme okrem uvedenej primárnej funkcie využiť aj na analytické spracovanie, tak aby verejná správa dokázala využívať svoje údaje pre potreby prípravy analýz, na podporu rozhodovania, riadenia a lepší návrh politík. Podmienkou pre plné využitie potenciálu údajov vo verejnej správe je ich poznanie (informácie o dátových zdrojoch, ich obsahu a atribútoch) a zabezpečenie prístupu k analytickým údajom pre analytické jednotky.  
V nasledujúcej tabuľke uveďte, ktoré objekty evidencie budú projektom pripravené na analytické účely a sprístupňované pre analytické jednotky (napr. pre systém Konsolidovaná Analytická Vrstva – KAV: https://data.gov.sk/id/egov/isvs/9655 ).
Informácie k sprístupneniu dátových zdrojov organizácie na analytické účely: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/analyticke-udaje/

4.3.7Moje údaje

V tejto časti je potrebné uviesť informácie súvisiace s údajmi, ktoré spadajú do kategórie mojich údajov, z pohľadu budúceho TO BE stavu projektu. Za moje údaje sa považujú najmä: 

• množina údajov o konaní, ktoré sa týkajú fyzickej osoby alebo právnickej osoby 
• množina údajov, vrátane osobných údajov, viažucich sa k fyzickej osobe alebo právnickej osobe ako ku subjektu evidencie, ktoré sú predmetom evidovania povinným subjektom, 
• množina údajov obsiahnutých v návrhu na začatie konania, žalobe, rozhodnutí, žiadosti, sťažnosti, vyjadrení, stanovisku a ohlásení alebo inom dokumente, ktorý vydáva v konaní povinný subjekt, viažuci sa ku konkrétnej fyzickej osobe alebo právnickej osobe.
  Relevantné údaje budú sprístupnené prostredníctvom modulu procesnej integrácie a integrácie údajov - modul Manažmentu osobných údajov pre dotknuté osoby (občanov a podnikateľov) na základe preukázania elektronickej identity osoby. Podmienkou je zabezpečiť, aby údaje identifikované pre službu moje údaje boli prístupné elektronicky v strojovo-spracovateľnom formáte automatizovaným spôsobom cez aplikačné programovacie rozhranie, alebo prostredníctvom modulu procesnej integrácie a integrácie údajov.
  Informácie k sprístupneniu dátových zdrojov organizácie pre službu moje údaje:
  https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/moje-udaje/ .
  Minimálny rozsah pre vyhlásenie dátových prvkov za moje údaje, ktoré musí žiadateľ v projekte zabezpečiť: 
• označenie povinného subjektu, 
• názov ISVS v ktorom je dátový prvok obsiahnutý, 
• kód informačného systému, v ktorom je dátový prvok obsiahnutý, podľa centrálneho metainformačného systému, 
• označenie dátového prvku, 
• strojovo-spracovateľný formát dátového prvku, 
• technickú špecifikáciu aplikačného programovacieho rozhrania, 
• ďalšie doplňujúce informácie. 
• transparentný pohľad na prístup k údajom subjektu, k logom (kto pristupoval k údajom, za akým účelom a kedy). 
  V prípade, že predkladateľ projektu disponuje údajmi, ktoré spadajú do kategórie mojich údajov, je potrebné vyplniť nasledovnú tabuľku. V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

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

Vyplňte nasledujúcu súhrnnú tabuľku pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.
V tabuľke uveďte OE z tabuľky uvedenej v kapitole 4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE.

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Uveďte popis a model technologickej vrstvy AS IS stavu, používané výpočtové prostriedky, konfigurácie siete, problematické body, ktoré je potrebné projektom riešiť.

4.4.2Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Doplňte pre TO BE stav do nasledujúcej tabuľky požiadavky na výkonnostné parametre, kapacitné požiadavky, ktoré majú vplyv na výkon, sizing prostredia, napr. počet interných používateľov, počet externých používateľov, počet spracovávaných procesov, dokumentov, komunikáciu medzi vrstvami architektúry IS, využívanie sieťovej infraštruktúry (Govnet, LAN, VPN, …).

4.4.3Návrh riešenia technologickej architektúry

Uveďte návrh a model architektúry technologickej vrstvy s prihliadnutím na zavedenie Cloud-Native ako štandardu pre vývoj nových ITVS a pre programovanie starých ITVS do nového štandardu a na zavedenie štandardu vytvárania a používania zdieľaných služieb.
V prípade, že riešenie nepredpokladá využívanie cloudových služieb z katalógu služieb vládneho cloudu (Iaas,PaaS,SaaS podľa katalógu služieb VC), je potrebné nevyužitie cloudových služieb z katalógu služieb vládneho cloudu dostatočne zdôvodniť.
Taktiež požiadavky riešenia na HW, SW a licencie v zmysle požadovaného sizingu pre vývojové, testovacie a produkčné prostredie je potrebné uviesť v dokumente BC/CBA na príslušných kartách.
V popise návrhu riešenia je požadované uviesť:

• prístup k riešeniu technologickej architektúry a súvisiace architektonické rozhodnutia
• popis požiadaviek na prevádzkové prostredia (vývoj, test, produkčné)
• diagram nasadenia a komunikačnej infraštruktúry.
  Pri výbere požiadaviek na riešenie, je potrebné klásť dôraz na výber služieb, ktoré sú založené na najmodernejších technológiách, prostredníctvom ktorých bude vytvorený predpoklad na vývoj/tvorbu moderného ISVS. Pre navrhované riešenie odporúčame použiť prístup pre vývoj takzvaných Cloud Native aplikácií. Riešenie „Cloud-native“ ISVS, je v čo najväčšej miere nezávislé na umiestnení v cloude, resp. datacentre. Nezávislosť novo vyvíjaného ISVS od cloudového prostredia by malo byť základnou prioritou a podmienkou architektúry ISVS.

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

Zaevidujte v MetaIS využívanie infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

• Vývojové – určené pre vývoj systému
• Testovacie – určené pre testy nových modulov, úprav, zmenových požiadaviek a retesty na úrovni upgrade‑ov (nie pre záťažové testovanie).
• Produkčné – určené pre produkčnú (ostrú) prevádzku systému
• Ďalšie existujúce alebo plánované prostredia, ktoré budú potrebné, napr. predprodukčné, integračné, fix prostredie
  Poznámky:
  Ak potrebujete pre príslušné prostredie viaceré infraštruktúrne služby, pridajte si potrebné riadky.
  V prípade, že neplánujete využitie cloudových služieb z katalógu služieb vládneho cloudu, uveďte v tabuľke požadovaných výpočtových zdrojov (sizing) pre jednotlivé prostredia parametre výpočtových zdrojov, ktoré plánujete v projekte použiť. Namiesto názvu a kódu infraštruktúrnej služby uveďte kód a názov výpočtového zdroja evidovaného v MetaIS.
  V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách. V rámci verejného obstarávania je potrebné potenciálneho uchádzača o zákazku požiadať o návrh technologickej infraštruktúry potrebnej pre implementáciu a prevádzku navrhovaného riešenia. Dodávateľ by pre svoj návrh technologického prostredia mal využiť hlavne cloudové služby vládneho cloudu uvedené v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

4.5Bezpečnostná architektúra

Uveďte popis AS IS stavu z pohľadu súčasného riešenia bezpečnostnej architektúry,
Uveďte popis TO BE stavu riešenia bezpečnostnej architektúry (+ popis alternatív),
Uveďte súlad navrhovanej bezpečnostnej architektúry s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS, pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia. Ide najmä o:

• Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe
• Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 Z. z. o štandardoch pre informačné technológie verejnej správy
• vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (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)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.
  Stručne popíšte postupy na dosiahnutie potrebnej úrovne bezpečnosti a spôsob zabezpečenia aktív projektu na jednotlivých vrstvách architektúry (dôvernosť, dostupnosť a integrita).
  Uveďte požiadavky na realizáciu Bezpečnostného projektu⁶
  Doplňte požiadavky na používateľské role, správu prístupov a správu aplikácie:
• Interní používatelia (pracovníci jednotlivých organizačných jednotiek, pracovníci administrácie a správy aplikácie, pracovníci prevádzky a podpory)
• Externí používatelia (zákazníci, partneri - tretie strany).

5.Závislosti na ostatné ISVS / projekty

Uveďte sumárny prehľad všetkých projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá.
Uveďte ako záujmové osoby (stakeholder) organizačné jednotky verejnej správy zodpovedné za poskytnutie potrebnej súčinnosti pre pripravovaný projekt.

6.Zdrojové kódy

Doplňte požiadavky na zdrojové kódy (napr. zo vzorovej zmluvy). Aké druhy, formy a štruktúry zdrojových kódov požadujte odovzdať. Stručne popíšte aj spôsob ich preberania, periodicitu (pri akých míľnikoch) a spôsob archivácie,
Doplňte pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do Zmluvy o dielo alebo zmluvy na podporu (ZoD/SLA).
Naviažte preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.
Navrhnite spôsob, ako predísť „Vendor lock-in“ = t.j. dodávané riešenie musí byť v súlade so Zákonom o ITVS (ktorý „vendor lock-in“ nepovoľuje). Následne ustanovenia predchádzaniu vendor-lockinu musia byť zahrnuté aj v ZoD a SLA.
Usmernenia pre oblasť zdrojových kódov:

• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/
• Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en

7.Prevádzka a údržba

Doplňte popis AS IS stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Doplňte popis TO BE stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

7.1Prevádzkové požiadavky

Uveďte popis L1 úrovne – požiadavky / očakávania
Uveďte popis L2 úrovne – požiadavky / očakávania
Uveďte popis L3 úrovne – požiadavky / očakávania
Uveďte štandardný čas podpory, čas/rýchlosť odstraňovania vád, dostupnosť systému, zálohovanie, plán obnovy systému, atď.
Uveďte požadované SLA na služby systémovej a aplikačnej podpory – servisné služby vzťahujúce sa na produkčné a testovacie prostredie IS.

7.1.1Ú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 verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ).
• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).
  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 IS Solution manager a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v IS Solution manager,
• Dostupnosť L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní),

7.1.2Rieš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:

• 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.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (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).

7.2.2RTO (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

7.2.3RPO (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

8.Požiadavky na personál

Doplniť požiadavky na projektové personálne zabezpečenie (projektové role a ich obsadenie).
Doplniť rámcové požiadavky na obsadenie TO BE procesu.
Doplniť požiadavky potrebných školení a certifikátov.

9.Implementácia a preberanie výstupov projektu

Posúďte a doplňte spôsoby realizácie projektu a ich dopad na harmonogram projektu a preberanie výstupov pripravovaného projektu.
V zmysle Vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je potrebné posúdiť výber spôsobu realizácie projektu metódou waterfall, metódou agile alebo metódou waterfall s prvkami metódy agile.
V zmysle vyhlášky 401/2023 Zz o riadení projektov a zmenových požiadaviek v prevádzke je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

• Inkrement musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenia do produkcie. Je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu a každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu, alebo pokračovať ďalším inkrementom.
• Ak realizačná fáza veľkých projektov pozostáva z dodania jedného funkčného celku alebo dodania výlučne technických prostriedkov, objednávateľ v produkte PI-03 Prístup k projektu a v M-05 Analýza nákladov a prínosov - BC/CBA, posúdi a vyhodnotí aj alternatívy rozdelenia na inkrementy na preukázanie ekonomickej nevýhodnosti alebo technických obmedzení rozdeliť projekt na inkrementy.

10.Prílohy

V prípade potreby doplňte zoznam príloh 
Poznámka: odporúčame, aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom súbore formátu EXCEL – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.
Inštrukcie k verejnému pripomienkovaniu:

• Podľa §4 ods. 10 vyhlášky č. 401/2023 Z.z je potrebné zrealizovať pripomienkovanie Projektového prístupu odbornou verejnosťou, zaevidovať a vyhodnotiť pripomienky odbornej verejnosti.
• Oznámenie o začatí verejného pripomienkovania zverejniť v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia.
• Dať na schválenie riadiacemu výboru výstupy po zverejnení vyhodnotenia pripomienok.
• Vyhodnotenie zverejniť na webovom sídle objednávateľa (do projektového adresára).
  1 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
  2 https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
  3 The Open Group ArchiMate Model Exchange File Format Standard a špecifikácia BPMN 2.0
  4 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
  5 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
  6 Správca ISVS je povinný zaviesť v organizácii systém riadenia informačnej (a kybernetickej) bezpečnosti a vypracovať bezpečnostný projekt pre ISVS podľa vyhlášky Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy)
  Strana 23/23