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

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.

2.1Použité skratky a pojmy

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

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

Technické požiadavky majú nasledovnú konvenciu:

TRxx:

• 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

Inštitút zaručenej konverzie možno považovať za jeden zo základných pilierov dôveryhodnosti elektronického výkonu verejnej moci, ktorá sa ako základný koncept právneho štátu začala na Slovensku uplatňovať zavedením zákona č. 305/2013 Z. z. od roku 2013. Celý výkon verejnej moci po roku 2013 je postavený na predpoklade, že orgány verejnej moci budú komunikovať s občanmi a podnikateľmi (a preferovane aj naopak) výlučne elektronicky. Tento prístup výrazne znižuje administratívnu záťaž na oboch stranách a zrýchľuje interné procesy, pričom ušetrený čas je možné efektívne využiť pri realizácii jednotlivých konaní.

Predpokladom elektronickej komunikácie je okrem iného aj dôveryhodnosť obsahu komunikácie, teda dokumentu alebo informácie, ktorá je v komunikácii použitá. Nestačí teda len jednoznačne a nespochybniteľne identifikovať subjekty, ktoré medzi sebou pri výkone moci komunikujú, ale je potrebné disponovať pravými a autentickými, teda nespochybniteľnými informáciami a dokumentmi. Vzhľadom na to, že prechod z papierovej podoby dokumentov je dlhodobý proces, zákon č. 305/2013 Z. z. definoval pravidlá, pri splnení ktorých je možné pri výkone verejnej moci použiť v komunikácii pôvodne elektronické, ako aj pôvodne papierové, ale do elektronickej podoby transformované (konvertované) dokumenty. A práve proces konverzie je pre účely zákona tým momentom, ktorý predurčuje autenticitu a tým aj nespochybniteľnosť a v konečnom dôsledku bezpečnosť celého procesu. Zákon pomenúva inštitút zaručenej konverzie ako akt, pri ktorom sa vopred definovaným, overiteľným a nespochybniteľným postupom prevádza určitý formát alebo fyzická podoba dokumentu na iný/inú. Potreba vytvorenia Elektronického Zoznamu Zaručených Konverzií (ďalej len EZZK) vychádza primárne z aplikačnej praxe oprávnených osôb vykonávajúcich zaručenú konverziu. Počas platnosti súvisiacej legislatívy dochádzalo k prípadom, kedy oprávnené osoby nedokázali zabezpečiť jednoznačnú preukázateľnosť pravosti obsahu vykonanej konverzie a jej overiteľnosť, čo mohlo viesť k zneužitiu tohto inštitútu napríklad ante-datovaním zaručenej konverzie, zmenou identifikátorov a pod.

Vytvorenie EZZK 2.0 ako centrálneho modulu, obsahujúceho údaje o vykonaných zaručených konverziách (ďalej aj ako ZK) a záznamoch o týchto ZK, je primárne motivované platnou legislatívou, je však nevyhnutné vnímať ho aj v kontexte nasledovných prínosov:

• Osvedčovacia doložka o zaručenej konverzii je v aktuálnej podobe zložitá, obsahuje duplicitné údaje voči centrálnej evidencii a jej údaje je potrebné často manuálne overovať voči centrálnej evidencii. Je preto potrebné doložku zjednodušiť iba na evidenčné číslo a všetky údaje o bezpečnostných prvkoch pôvodného dokumentu budú iba v centrálnej evidencii
• Centralizáciou údajov o vykonaných ZK na jednom mieste sa vytvára predpoklad pre časovo a ekonomicky efektívny elektronický prístup k týmto informáciám pre účely rôznych konaní.
• Zjednotenie identifikátora záznamu o vykonanej ZK – evidenčného čísla, ktoré bude centrálne vytvárané a poskytované všetkým oprávneným osobám vytvára predpoklad pre bezrozporovú identifikáciu

vykonanej ZK

• Vytvorenie EZZK ako samostatného systému, obsahujúceho prvky bezpečného a dôveryhodného uchovávania informácií, zaručuje originalitu a pravosť (autenticitu) poskytnutej informácie.
• EZZK je preferovane budovaný ako samostatný informačný systém, prevádzkovaný vo vládnom cloude; tým je zaručená maximálna ekonomická efektívnosť a bezpečnosť prevádzky;

Zaručená konverzia vstúpila do praxe na základe ustanovení zákona č. 305/2013 Z. z. o e-Governmente a bola realizovaná s využitím špecializovaných SW aplikácií a IT nástrojov v prostredí oprávnených osôb (napríklad notár, advokát, OVM), ktoré boli spočiatku povinné viesť vlastné lokálne evidencie záznamov o vytvorených ZK. Za účelom eliminácie možných zneužití pri vytváraní ZK bola novelou zákona o eGov legislatívne určená povinnosť viesť centrálnu evidenciu záznamov o vykonaných ZK v gescii UPPVII SR (súčasné MIRRI SR). Na základe tejto zákonnej povinnosti bol k 1.12.2019 spustený do prevádzky IS “Elektronický záznam o zaručených konverziách” ako modul k IS Integrovaných obslužných miest (ďalej len „modul EZZK“ a “modul IOM”). Zmyslom centrálnej evidencie je sprístupnenie záznamov o vykonanej zaručenej konverzii používateľom, ktorí môžu na jednom mieste overiť či bol pôvodný dokument skonvertovaný oprávnenou osobou v súlade so zákonom a tiež či je obsah vytvorenej ZK totožný s pôvodným originálom. Tým sa výrazným spôsobom zvyšuje právna istota pri používaní dokumentov vytvorených procesom ZK.

Konvertovaný dokument je akýkoľvek dokument, ktorý vznikol zaručenou konverziou z listinnej do elektronickej podoby, z elektronickej do listinnej podoby alebo z elektronickej do inej elektronickej podoby. Zaručená konverzia je bližšie definovaná vo Vyhláške 70/2021 Z.z. Ministerstva investícií, regionálneho rozvoja a informatizácie SR o zaručenej konverzii (ďalej len “ministerstvo”).

4.Architektúra riešenia projektu

S

4.1Biznis vrstva

Obrázok 1- Biznis architektúra EZZK – súčasný stav

Funkcionalitu systému je možné rozdeliť do nasledovných skupín:

• Portál EZZK - webový portál určený:
  • Verejnosti - poskytuje služby bez potreby prihlásenia.
    • Poskytnutie záznamu o vykonanej zaručenej konverzii

• 
  
  • Oprávneným osobám - po prihlásení poskytuje služby:
    • Poskytnutie evidenčného čísla
    • Spotreba evidenčného čísla
    • Prijatie záznamu o vykonanej zaručenej konverzii
    • Poskytnutie záznamu o vykonanej zaručenej konverzii

• Verejné služby - sú webové služby určené systémom poskytujúcim zaručenú konverziu. Služby sú dostupné iba prihláseným používateľom (oprávneným osobám). Dostupné sú nasledovné funkcie:
  • Poskytnutie evidenčného čísla
  • Spotreba evidenčného čísla
  • Prijatie záznamu o vykonanej zaručenej konverzii
  • Poskytnutie záznamu o vykonanej zaručenej konverzii
• Interné služby - zabezpečujú procesy spojené so spracovaním EZZK a správou evidenčných čísel
• Podporné služby - služby potrebné pre fungovanie systému ako takého. Zabezpečujú integráciu na externé systémy, autentifikáciu, autorizáciu, dlhodobé uchovanie dát a ďalšie nevyhnutné služby.

Systém počíta s prepojením na nasledovné externé systémy:

• ÚPVS SM - spoločné moduly ÚPVS;
• TSA - pre získanie časových pečiatok;
• CA - pre overovanie platnosti certifikátov;

Biznis architektúru súčasného EZZK predstavujú nasledujúce procesy:

• 01 Proces zaručenej konverzie
• 02 Proces poskytnutia evidenčného čísla
• 03 Proces spotreby evidenčného čísla
• 04 Proces zaevidovania záznamu
• 05 Proces overenia osvedčovacej doložky

01 Proces zaručenej konverzie – súčasný stav

Obrázok 2- Proces zaručenej konverzie – súčasný stav

Popis procesu zaručenej konverzie

1. Oprávnená osoba je povinná vyžiadať si od centrálnej evidencie (EZZK) pred začatím vykonávania zaručenej konverzie evidenčné číslo záznamu o vykonanej zaručenej konverzii.
2. Záznam o konverzii je elektronický dokument, vyplnený podľa elektronického formulára, ktorý je zverejnený v module elektronických formulárov podľa § 10 ods. 3 písm. e) zákona č. 305/2013 Z. z. o e-Governmente.
3. Všetky údaje o vykonanej zaručenej konverzii musia byť centrálnej evidencii poskytnuté do 24 hodín od jeho vytvorenia.

02 Proces poskytnutia evidenčného čísla – súčasný stav

Obrázok 3 - Proces poskytnutia evidenčného čísla – súčasný stav

Proces poskytnutia evidenčného čísla je synchrónny

1. Proces poskytnutia evidenčného čísla začína v IS oprávnenej osoby. V IS oprávnenej osoby je vytvorená požiadavka, ktorá je odoslaná do centrálnej evidencie. 
2. Centrálna evidencia po prijatí požiadavky vykoná autentifikáciu a autorizáciu volajúceho systému.
3. Ak volajúci systém nemá oprávnenie pre volanie služby, centrálna evidencia vytvorí synchrónnu odpoveď o odmietnutí požiadavky a procesný tok zaručenej konverzie musí byť v IS oprávnenej osoby ukončený. 
4. Ak volajúci systém má oprávnenie na volanie služby, centrálna evidencia vykoná vygenerovanie evidenčného čísla v stave Pridelené. Počet pridelených evidenčných čísel je závislý od konfigurácie oprávnenej osoby v systéme. Pre osoby, ktoré majú oprávnenie na pridelenie sady evidenčných čísel, bude pridelená množina evidenčných čísel zodpovedajúca konfigurácii oprávnenej osoby. 
5. Proces poskytne evidenčné čísla, ktoré nie sú spotrebované. Ak oprávnená osoba požiada o poskytnutie EČ, pričom existuje taký počet nespotrebovaných EČ pre osobu podľa konfigurácie osoby v centrálnej evidencii, oprávnenej osobe nebude nové EČ poskytnuté. 
6. Centrálna evidencia vytvorí synchrónnu odpoveď o spracovaní požiadavky, pričom súčasťou odpovede je priradené evidenčné číslo resp. sada evidenčných čísel.
7. Procesný tok poskytnutia EČ vykonanej zaručenej konverzie je v IS oprávnenej osoby ukončený.

03 Proces spotreby evidenčného čísla – súčasný stav

Evidenčné číslo je spotrebované v nasledovných prípadoch:

1. V centrálnej evidencii je evidovaný záznam o vykonanej zaručenej konverzii s týmto EČ, alebo
2. Automatická spotreba centrálnou evidenciou do 24. hodiny dňa pridelenia EČ, alebo
3. Oprávnená osoba požiada aplikačnou službou o spotrebu EČ.
    

Obrázok 4 - Proces spotreby evidenčného čísla – súčasný stav

Proces spotreby evidenčného čísla je synchrónny. 

1. Proces spotreby EČ začína v IS oprávnenej osoby. V IS oprávnenej osoby je vytvorená požiadavka, ktorá je odoslaná do centrálnej evidencie. 
2. Centrálna evidencia po prijatí požiadavky vykoná autentifikáciu a autorizáciu volajúceho systému.
3. Ak volajúci systém nemá oprávnenie pre volanie služby, centrálna evidencia vytvorí synchrónnu odpoveď o odmietnutí požiadavky. IS oprávnenej osoby, ktorý má oprávnenie na poskytnutie EČ má zároveň oprávnenie na spotrebu EČ. 
4. Ak volajúci systém má oprávnenie na volanie služby, centrálna evidencia vykoná spotrebu EČ t.j. zmení stav EČ na Spotrebované. V prípade, ak oprávnenej osobe zlyhá proces vykonávania zaručenej konverzie napr. z dôvodu zlyhania IS oprávnenej osoby a oprávnená osoba nebude schopná zistiť poskytnuté EČ, zavolá službu Spotreba EČ bez uvedenia evidenčného čísla. Centrálna evidencia v takomto prípade spotrebuje najstaršie nespotrebované EČ. 
5. Centrálna evidencia vytvorí synchrónnu odpoveď o spracovaní požiadavky. Procesný tok spotreby EČ je ukončený.

04 Proces zaevidovania záznamu – súčasný stav

Obrázok 5 - Proces zaevidovania záznamu – súčasný stav

Proces zaevidovania záznamu o vykonanej zaručenej konverzii je synchrónny so synchrónnou odpoveďou na požiadavku o zaevidovanie EZZK

1. Proces zaevidovania záznamu o vykonanej zaručenej konverzii začína v IS oprávnenej osoby. V IS oprávnenej osoby je vytvorená požiadavka, ktorá je odoslaná do centrálnej evidencie. 
2. Centrálna evidencia po prijatí požiadavky vykoná autentifikáciu a autorizáciu volajúceho systému.
3. Ak volajúci systém nemá oprávnenie pre volanie služby, centrálna evidencia vytvorí synchrónnu odpoveď o odmietnutí požiadavky a procesný tok zaručenej konverzie musí byť v IS oprávnenej osoby ukončený. 
4. Ak volajúci systém má oprávnenie na volanie služby, centrálna evidencia vykoná validáciu dátovej štruktúry prijatého kontajnera EZZK (Container). Ak dátová štruktúra nie je platná, centrálna evidencia vytvorí synchrónnu odpoveď o odmietnutí požiadavky a procesný tok odoslania dávky EZZK musí byť v IS oprávnenej osoby ukončený. 
5. Ak dávka bola vytvorená (podľa hodnoty elementu DateCreated v kontajneri) do dňa nasledujúceho po dni zriadenia centrálnej evidencie, centrálna evidencia vytvorí synchrónnu odpoveď o odmietnutí požiadavky a procesný tok odoslania dávky ZK musí byť v IS oprávnenej osoby ukončený. 
6. Ak dátová štruktúra kontajnera ZK je platná, centrálna evidencia vykoná vyhľadanie kontajnera v evidencii na základe hodnoty elementu MessageId. Ak je kontajner ZK v centrálnej evidencii evidovaný, dávka bude centrálnou evidenciou odmietnutá, inak bude kontajner ZK zaevidovaný. Pre každý ZK v kontajneri zároveň centrálna evidencia vykoná kontrolu evidenčného čísla, ktorý je uvedený v elemente Id v objekte ZK. Ak evidenčné číslo je priradené inej oprávnenej osobe alebo k evidenčnému číslu už existuje iný ZK, bude celá dávka centrálnou evidenciou odmietnutá a procesný tok odoslania dávky ZK musí byť v IS oprávnenej osoby ukončený.
7. Pre každé EČ v dávke bude zaznamenaná spotreba. 
8. Centrálna evidencia zaeviduje kontajner ZK do evidencie a vytvorí synchrónnu odpoveď o prijatí požiadavky na zaevidovanie ZK obsiahnuté v kontajneri a procesný tok zaručenej konverzie môže byť v IS oprávnenej osoby ukončený. 

05 Proces overenia osvedčovacej doložky – súčasný stav

Obrázok 6 - Proces overenia osvedčovacej doložky – súčasný stav

Popis procesu overenia osvedčovacej doložky vyhľadávaním evidenčného čísla v EZZK.

1. Podávajúca osoba predloží orgánu verejnej moci (alebo inému typu osoby - FO/PO) dokument vytvorený zaručenou konverziou.
2. Orgán verejnej moci povinne (a iné osoby nepovinne) vyhľadá na základe evidenčného čísla záznam o vykonanej konverzii v EZZK.
3. Orgán verejnej moci povinne (a iné osoby nepovinne) skontroluje údaje v osvedčovacej doložke voči záznamu v EZZK.
4. V prípade, že nebude zistená chyba, dokument OVM akceptuje (ostatné osoby nemajú tento postup predpísaný).

Biznis architektúra – budúci stav

Systém EZZK bude slúžiť oprávneným osobám ako aj občanom. Občania aj oprávnené osoby môžu k službám, systému pristupovať cez GUI rozhranie webového Portálu EZZK a overovať v minulosti vykonané ZK. Oprávnené osoby majú k dispozícii aj Verejné služby prostredníctvom IS Oprávnenej osoby). IS Oprávnenej osoby (IS Oprávnenej osoby sú špecializované aplikácie tretích strán, ktoré zaručené konverzie vykonávajú a pomocou API rozhrania komunikujú so systémom EZZK).

• Verejné služby - sú webové služby určené systémom poskytujúcim zaručenú konverziu.

Autorizované služby dostupné iba prihláseným používateľom (oprávneným osobám). Dostupné sú nasledovné funkcie:

• 
  
  • Prijatie záznamu o vykonanej zaručenej konverzii
  • Poskytnutie záznamu o vykonanej zaručenej konverzii

Neautorizované služby dostupné aj neprihláseným používateľom. Dostupné sú nasledovné funkcie:

• 
  
  • Vyhľadanie a poskytnutie záznamu o vykonanej ZK

• Vystavené Verejné služby sú realizované internými službami
• Interné služby - zabezpečujú procesy spojené so spracovaním EZZK a správou evidenčných čísel
• Podporné služby - služby potrebné pre fungovanie systému ako takého. Zabezpečujú integráciu na externé systémy, registráciu oprávnených osôb, autentifikáciu, autorizáciu, dlhodobé uchovanie dát a ďalšie nevyhnutné služby.
  • Podporné služby sa integrujú na Spoločné moduly ÚPVS.

Biznis procesy – budúci stav

V TO BE stave oproti AS IS stavu zostávajú iba procesy 01, 04 a 05 z AS IS stavu. Procesy 02 a 03 (poskytnutie a spotreba EČ) v TO BE stave nebudú existovať, nakoľko EČ vznikne až v rámci zaevidovania záznamu.

Biznis proces v TO BE stave sú:

01 Proces zaručenej konverzie

04 Proces zaevidovania záznamu

05 Proces overenia osvedčovacej doložky

06 Proces automatizovaného overenia osvedčovacej doložky - TO BE (Nová služba pre overenie elektronických doložiek)

01 Proces zaručenej konverzie – budúci stav

Obrázok 8 - Proces zaručenej konverzie TO BE

Popis procesu zaručenej konverzie TO BE

1. Proces začína požiadavkou na konverziu dokumentu
2. Nasleduje vykonanie základných krokov: konverzia dokumentu – sken, tlač, konverzia do iného formátu); vyplnenie štruktúry záznamu o konverzii bez EČ; predpríprava doložky (voliteľné)
3. Odoslanie záznamu o konverzii do EZZK
4. Žiadosť o poskytnutie EČ
5. Prijatie a kontrola záznamu v Centrálnej evidencii
6. Vygenerovanie EČ
7. Predvyplnenie OD (xml)
8. Prijatie EČ a predvyplnenej OD
9. Spojenie OD s kontrolovaným dokumentom
10. Koniec procesu

04 Proces zaevidovania záznamu – budúci stav

Obrázok 9 - Proces zaevidovania záznamu TO BE

Popis procesu zaevidovania záznamu TO BE

1. Proces začína požiadavkou na zaevidovanie záznamu o ZK
2. Vytvorenie SOAP/REST správy s požiadavkou
3. Autentifikácia a autorizácia volajúceho systému (IAM UPVS/CAMP) – v AS IS stave – meno heslo, v TO BE stave – autentifikačný certifikát.
4. Spracovanie záznamu zo zaručenej konverzie, kontrola logickej konzistentnosti- kontrola na logické chyby (napr. absencia niektorého zo zoznamu dokumentov v informáciách o bezpečnostných prvkoch), a overenie podpisov ak sa vo fáze DNR rozhodne o potrebe podpisovania záznamu.
5. Vygenerovanie EČ
6. Predvyplnenie OD (xml)
7. Odoslanie predvyplnenej OD z centrálnej evidencie a sprístupnenie záznamu v EZZK
8. Prijatie EČ a predvyplnenej OD
9. Spojenie OD s konvertovaným dokumentom

05 Proces overenia osvedčovacej doložky a získania informácie o bezpečnostných prvkoch vyhľadávaním EČ v EZZK – budúci stav

Obrázok 10 - Proces overenia OD a získania informácie o bezpečnostných prvkoch vyhľadávaním EČ v EZZK – TOBE

Popis procesu overenia osvedčovacej doložky a získania informácie o bezpečnostných prvkoch vyhľadávaním EČ v EZZK - TO BE

1. Proces začína požiadavkou na overenie OD
2. Vytorenie SOAP/REST správy s požiadavkou
3. Autentifikácia a autorizácia  volajúceho systému (IAM UPVS/CAMP) – v AS IS stave – meno heslo, v TO BE stave – autentifikačný certifikát.
4. Vyhľadanie EČ v centrálnej evidencii
5. Vytvorenie synchrónnej odpovede o spracovaní požiadavky (API - súbor obsahujúci záznam vložený v odpovedi, GUI je bez autentifikácie iba pri overení záznamu - zobrazenie celého záznamu, GUI musí prehľadne zobraziť údaje zo záznamu (vrátane vizuálnej interpretácie štruktúry podpisov)
6. Prijatie synchrónnej odpovede o spracovaní požiadavky
7. Oboznámenie sa s údajmi zo záznamu a overenie OD

06 Proces automatizovaného overenia osvedčovacej doložky - TO BE (Nová služba pre overenie elektronických doložiek)

Obrázok 11- Proces automatizovaného overenia osvedčovacej doložky – TO BE (Nová služba – pre overenie elektronických doložiek)

Popis procesu automatizovaného overenia osvedčovacej doložky - TO BE (Nová služba pre overenie elektronických doložiek)

1. Proces začína požiadavkou na overenie OD
2. Vytvorenie SOAP/REST správy s požiadavkou pre overenie OD
3. Autentifikácia a autorizácia  volajúceho systému (IAM UPVS/CAMP) – v AS IS stave – meno heslo, v TO BE stave – autentifikačný certifikát.
4. Základná kontrola súboru (veľkosť, vírusy...)
5. Overenie autorizácie OD
6. Kontrola zhody údajov v OD voči údajom v zázname o vykonanej zaručenej konverzii
7. Vytvorenie synchrónnej odpovede o spracovaní požiadavky (API - súbor obsahujúci zoznam rozdielov vložený v odpovedi, GUI je bez autentifikácie iba pri overení OD - zobrazenie zoznamu rozdielov, GUI musí prehľadne zobraziť zoznam rozdielov (vrátane vizuálnej interpretácie štruktúry údajov)
8. Prijatie synchrónnej odpovede o výsledku kontroly so zoznamom rozdielov
9. Oboznámenie sa s výsledkom kontroly OD

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

4.1.2Jazyková podpora a lokalizácia

Požiadavky na jazykovú lokalizáciu riešenia v stave TO BE budú zabezpečené v SK a EN jazyku.

4.2Aplikačná vrstva

Aplikačná architektúra – súčasný stav

Obrázok 12 - Aplikačná architektúra AS IS EZZK

Aktuálny informačný systém sa delí nasledovne

Frontend moduly:

• Portál EZZK - Single page aplikácia pre správu evidenčných čísel a záznamov o zaručenej konverzii
• Verejné webové služby EZZK - služby modulu EZZK vystavené do internetu určené pre systémy a aplikácie oprávnených osôb. Obsahujú funkcie pre prihlásenie a samotné biznis funkcie určené pre oprávnené osoby.
• Interné webové služby EZZK - služby modulu EZZK vystavené pre potreby EZZK portálu.
• Služby registrácie - slúžia registračnej stránke modulu Externý web IOMO pre zabezpečenie registrácie oprávnených osôb do systému EZZK.

Backend moduly:

• EZZK - modul EZZK zabezpečuje biznis procesy spojené so spracovaním EZZK a správy evidenčných čísiel pomocou orchestrácie volania ostatných modulov systému.
• EP.Core - modul elektronickej podateľne, ktorý slúži na overovanie platnosti podpisových certifikátov pre jednotlivé EZZK.
• ZZK Validator - validácia súboru so záznamami o zaručenej konverzii
• ZZK- modul pre správu záznamov o zaručenej konverzii poskytujúci služby pre portál EZZK
• ZZK Signer - podpisovanie záznamov o zaručenej konverzii
• MDA - modul dlhodobej archivácie dokumentov zabezpečuje kontinuitu overenia podpísaných dokumentov.
• DMS - modul document management system umožňuje uchovávanie dokumentov spolu s ich metadátami.
• IAM - zabezpečuje správu používateľov systému, poskytuje prihlasovacie a autorizačné služby.
• LOG - modul určený pre uchovávanie záznamov o aktivitách používateľov a chybových hlásení.
• EČ - modul pre správu evidenčných čísel poskytujúci služby pre portál EZZK

Modul integrácie na ÚPVS - sada modulov určených na komunikáciu so službami ÚPVS

Aplikačná architektúra – budúci stav

V rámci obrázku nižšie je uvedený návrh architektúry budúceho riešenia.

Obrázok 13 - Aplikačná architektúra – budúci stav

Štruktúra budúceho ISVS je navrhnutá nasledovne:

• Portál EZZK - Aplikácia s responzívnym rozhraním v súlade s dizajn manuálom ID-SK (idsk.gov.sk) pre správu evidenčných čísel a záznamov o zaručenej konverzii
  • Verejnosti aj Oprávneným osobám - poskytuje služby bez potreby prihlásenia.
    • Poskytnutie záznamu o vykonanej zaručenej konverzii

• EZZK Core
  • Verejné webové služby EZZK - služby modulu EZZK vystavené do internetu cez CAMP určené pre systémy a aplikácie oprávnených osôb. Obsahujú funkcie pre prihlásenie a samotné biznis funkcie určené pre oprávnené osoby.
  • Interné webové služby EZZK - služby modulu EZZK vystavené pre potreby EZZK portálu.
• ZZK Validator - validácia súboru so záznamami o zaručenej konverzii
• ZZK modul pre správu záznamov o zaručenej konverzii poskytujúci služby pre portál EZZK
  • Správa evidenčných čísel  - Modul pre správu evidenčných čísel poskytujúci služby pre portál EZZK.
  • Osvedčovacie doložky  - Modul pre generovanie  Osvedčovacích doložiek
• Využitie Spoločných modulov ÚPVS - Aplikačná služba pre potreby integrácie na UPVS
• Konzumovanie služieb z API GW - Aplikačná služba pre potreby integrácie na SNCA/ Kvalifikované dôveryhodné služby

4.2.1Rozsah informačných systémov – 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.

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

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

Projekt neplánuje poskytovať údaje do IS CSRÚ.

4.2.9Konzumovanie údajov z IS CSRU – TO BE

Projekt neplánuje konzumovať údaje z IS CSRÚ.

4.3Dátová vrstva

4.3.1Údaje v správe organizácie

Centrálna evidencia EZZK bude implementovať a vystavovať rozhranie pre prijatie záznamu o vykonanej zaručenej konverzii. Centrálna evidencia záznam zvaliduje a v prípade vyhovenia validačným pravidlám vygeneruje evidenčné číslo záznamu, ktoré vloží do novej dátovej štruktúry osvedčovacej doložky a túto štruktúru poskytne na výstupe volania.

Každý zaevidovaný záznam bude v evidencii priradený k jeho evidenčnému číslu a osobe resp. subjektu, ktorý záznam vyhotovil resp. zaevidoval. V rámci prijatia záznamu sa bude vykonávať aj základná validácia záznamu a v prípade nesúladu záznamu s validačnými pravidlami bude prijatie záznamu zamietnuté v synchrónnej odpovedi.

Prístup k rozhraniu bude umožnený len osobám oprávneným vykonávať zaručenú konverziu (osoby s prideleným prístupom v rámci centrálnej API GW). Pôvodné záznamy o vykonanej zaručenej konverzii museli byť autorizované kvalifikovaným elektronickým podpisom alebo kvalifikovanou pečaťou osoby vykonávajúcej zaručenú konverziu. Pre nové záznamy sa bude vyžadovať autorizácia a autentifikácia.

Centrálna evidencia bude implementovať a vystaví aplikačné rozhranie pre poskytnutie údajov prijatých záznamov o vykonanej zaručenej konverzii ako aj celých záznamov na základe evidenčného čísla. Pri poskytovaní záznamov bude zabezpečená ochrana osobných údajov podľa § 39 ods. 5 zákona o e-Governmente. Aplikačné rozhranie bude poskytovať všetky záznamy uchovávané v EZZK od jej vzniku - záznamy vytvorené podľa všetkých dátových štruktúr zverejnených pre záznamy o vykonanej zaručenej konverzii, ktoré budú migrované do nového riešenia.

Aplikačné rozhranie bude vo výstupe volania služby poskytovať aj informáciu, o ktorú dátovú štruktúru sa jedná.
Centrálna evidencia bude poskytovať rozhranie aj pre poskytovanie záznamov, pre ktoré neboli v pôvodnom EZZK overené podpisy alebo časové pečiatky ako platné, pričom poskytne vo výstupe služby aj informáciu o neplatnosti danej autorizácie záznamu. Prístup k rozhraniu bude umožnený ľubovoľnej autentifikovanej osobe. Aplikačné rozhranie pre poskytnutie údajov bude využívané aj vo verejnom grafickom rozhraní EZZK pre overenie osvedčovacej doložky a zobrazenie údajov o bezpečnostných prvkoch, kde sa nebude vyžadovať autentifikácia (systém sa autentifikuje v mene MIRRI SR a poskytne údaje zo záznamu v grafickom rozhraní).

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

4.3.3Referenčné údaje

Predmetom projektu nie je vyhlasovanie údajov za referenčné.

4.3.4Kvalita a čistenie údajov

Predmetom projektu nie je kvalita a čistenie údajov.

4.3.5Otvorené údaje

Predmetom projektu nie je zverejňovanie otvorených údajov.
4.3.6Analytické údaje

Predmetom projektu nie je zverejňovanie analytických údajov.

4.3.7Moje údaje

Predmetom projektu nie je zverejňovanie „mojich“ údajov.

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

Predmetom projektu nie je čistenie, resp. manažment údajov.

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Serverová časť systému je umiestnená v dátovom centre MVSR (resp. dátových centrách). Nasledujúci diagram znázorňuje logické servery (uzly) systému, ich zapojenie resp. umiestnenie, aké sú medzi servermi závislosti a z čoho sa skladajú jednotlivé uzly: 

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

EZZK KS - LB

Predstavuje logický alebo fyzický uzol zabezpečujúci smerovanie požiadaviek do externých lokalít.

EZZK WS - LB

Predstavuje logický alebo fyzický uzol zabezpečujúci smerovanie požiadaviek z externých lokalít.

EZZK Portal

Predstavujú logický alebo fyzický uzol zabezpečujúci spracovanie požiadaviek klientskej aplikácie portálu pomocou využitia interných služieb aplikácie EZZK.

EZZK Portal AS - LB , EZZK AS - LB

Predstavujú logický alebo fyzický uzol zabezpečujúci smerovanie požiadaviek na jednotlivé farmy serverov v rámci jednej lokality. Môže byť riešené napr. prostredníctvom F5 Local Traffic Manager.

EZZK Portal AS

Logický uzol EZZK AS predstavuje aplikačný uzol (virtuálny alebo fyzický server, samostatný server alebo farmu serverov) pre aplikačnú logiku spojenú so spracovaním EZZK a evidenčných čísiel ako aj sprostredkovanie komunikácie so službami ÚPVS. Uzol je umiestnený vo vrstve V2 a pristupuje na databázový uzol EZZK DB.

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

4.4.3Návrh riešenia technologickej architektúry

Navrhované riešenie projektu bude prevádzkované v technologickom prostredí služieb vládneho cloudu. Projekt bude realizovaný najmä formou vývoja a úprav softvéru a integrácií. V projekte sa nepredpokladá nákup HW. Riešenie bude prednostne umiestnené a prevádzkované vo vládnom cloude v súlade so zákonom č. 95/2019 (zákon o informačných systémoch vejrejnej správy). Pre každý komponent bude vyhodnotená požadovaná klasifikácia cloudovej služby podľa metodiky MIRRI SR, podľa ktorej budú zvolené potrebné cloudové služby z privátnej alebo verejnej časti služieb vládneho cloudu. Pri výbere cloudových služieb sa kladie dôraz na minimalizáciu rizika vendor lock-in. Ak je to možné, preferujú sa služby, ktoré sú ľahko zameniteľné, nie sú špecifické pre konkrétneho poskytovateľa a podporujú jednoduchú prenositeľnosť riešenia. Výhodou je možnosť kontajnerizácie namiesto tradičnej virtualizácie.

Budú vytvorené minimálne tri prevádzkové prostredia: 1.Vývojové 2.Testovacie 3.Produkčné.

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

Navrhované riešenie bude prevádzkované využitím služieb vládneho cloudu. Vytvorené budú minimálne nasledovné prostredia: vývojové, testovacie a produkčné prostredie (ideálne aj preprodukčné prostredie). Žiadateľ (MIRRI SR) poskytne infraštruktúru využitím služieb vládneho cloudu na úrovni IaaS, pričom bude požadovať poskytovanie služby s úrovňou zabezpečenia U3.

Navrhované riešenie projektu má byť vyvinuté tak, aby bolo bude prevádzkované v technologickom prostredí služieb vládneho cloudu. Projekt bude realizovaný najmä formou vývoja a úprav softvéru a integrácií. V projekte sa nepredpokladá nákup HW. Riešenie bude prednostne umiestnené a prevádzkované vo vládnom cloude v súlade so zákonom č. 95/2019 (zákon o informačných systémoch verejnej správy). Pre každý komponent bude vyhodnotená požadovaná klasifikácia cloudovej služby podľa metodiky MIRRI SR, podľa ktorej budú zvolené potrebné cloudové služby z privátnej alebo verejnej časti služieb vládneho cloudu. Pri výbere cloudových služieb je kladený dôraz na minimalizáciu rizika vendor lock-in. Ak je to možné, preferujú sa služby, ktoré sú ľahko zameniteľné, nie sú špecifické pre konkrétneho poskytovateľa a podporujú jednoduchú prenositeľnosť riešenia. Výhodou je možnosť kontajnerizácie namiesto tradičnej virtualizácie.

4.5Bezpečnostná architektúra

Súčasťou riešenia bude vypracovanie Bezpečnostného projektu, ktorý bude vypracovaný súčasne s Detailným návrhom riešenia (DNR), aby opatrenia z bezpečnostného projektu boli zapracované do DNR a dodaného diela.

MIRRI SR bude v rámci implementácie riešenia požadovať poskytnutie súčinnosti pri implementácii bezpečnostných požiadaviek a požiadavkách na vykonanie penetračného testovania (vrátane prípravy testovacích scenárov) a odstránenia nedostatkov, vrátane overenia súladu diela s bezpečnostnými požiadavkami špecifikovanými v Bezpečnostnom projekte a Metodike pre systematické zabezpečenie organizácií verejnej správy v oblasti informačnej bezpečnosti (dostupná na https://www.csirt.gov.sk/wp-content/uploads/2021/08/MetodikaZabezpeceniaIKT_v2.1.pdf, https://www.csirt.gov.sk/doc/MetodikaZabezpeceniaIKT_v2.0.pdf), zároveň bude MIRRI SR od dodávateľa riešenia žiadať poskytnutie súčinnosti pri odstránení nedostatkov zistených pri penetračnom testovaní - CSIRT.SK

V rámci projektu bude rovnako realizovaný nezávislý bezpečnostný audit vrátane auditu zdrojového kódu integrácií, a takisto penetračných testov:

• Vykonanie auditu komponentov, ktoré sú výstupom plnenia diela, vrátane inštalácií a konfigurácií prípadných centrálnych BI nástrojov alebo centrálnych nástrojov pre dátovú vedu,
• Štruktúrovaný popis nálezov auditu vo formáte XLS s prioritizáciou a návrhom riešenia.
• Overenie zapracovania pripomienok a odstránenia nálezov brániacich riadnemu používaniu predmetu diela.

Bezpečnostná architektúra budúceho stavu bude 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é / 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 a o zmene a doplnení niektorých zákonov
• zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov
• 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.
• smernica Európskeho parlamentu a Rady (EÚ) (EÚ) 2022/2555 zo 14. decembra 2022 o opatreniach na zabezpečenie vysokej spoločnej úrovne kybernetickej bezpečnosti v Únii, ktorou sa mení nariadenie (EÚ) č. 910/2014 a smernica (EÚ) 2018/1972 a zrušuje smernica (EÚ) 2016/1148 (smernica NIS 2)
• zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej aj „zákon o kybernetickej bezpečnosti“),
• vyhláška Národného bezpečnostného úradu č. 164/2018 Z. z., ktorou sa určujú identifikačné kritériá prevádzkovanej služby (kritériá základnej služby),
• vyhláška Národného bezpečnostného úradu č. 165/2018 Z. z., ktorou sa určujú identifikačné kritériá pre jednotlivé kategórie závažných kybernetických bezpečnostných incidentov a podrobnosti hlásenia kybernetických bezpečnostných incidentov,
• vyhláška Národného bezpečnostného úradu č. 264/2023 Z. z. ktorou sa mení a dopĺňa vyhláška Národného bezpečnostného úradu č. 362/2018 Z. z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení,
• vyhláška Národného bezpečnostného úradu č. 493/2022 Z. z. o audite kybernetickej bezpečnosti,
• zákon č. 301/2023 Z. z. ktorým sa mení a dopĺňa zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov v znení neskorších predpisov a ktorým sa menia a dopĺňajú niektoré zákony,
• 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, ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy,
• 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) – GDPR,
• zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov v znení neskorších predpisov,
• Metodika analýzy rizík kybernetickej bezpečnosti - Metodika analýzy rizík pre uplatnenie v procesoch riadenia rizika v zmysle požiadaviek zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti (NBÚ)

5.Závislosti na ostatné ISVS / projekty

6.Zdrojové kódy

V rámci dodania diela bude MIRRI SR požadovať dodávanie zdrojového priebežné počas projektu vrátane dokumentácie a inštrukcií na zostavenie a nasadenie jednotlivých súčastí systému.

Požiadavka na zabezpečenie kvality zdrojových kódov podľa metodiky: Metodicke-usmernenie-024077-2023-oSBAA-1.pdf (gov.sk).

Požiadavka na zabezpečenie kvality 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
• Ochrana proti Vendor lock: dostupné zdokumentované zdrojové kódy, konfigurovateľnosť riešenia, prevádzkovateľnosť riešenia v réžii NASES/MIRRI (t.j. dostupné administrátorské rozhrania pre prevádzku), v prípade potreby overenia podpisov (ak vyplynie z analýzy že je potrebné ich použitie) použitie centrálnych služieb ÚPVS namiesto lokálnych.

Ďalej uvádzame požiadavku na uloženie a zverejnenie bez obmedzení zdrojových kódov a ich popisov v centrálnom repozitári verejnej správy https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2020/78/20240701#paragraf-31.nadpis

7.Prevádzka a údržba

Zhotoviteľ riešenia bude povinný zabezpečiť prevádzkovú podporu systému a všetkých jeho súčastí na obdobie minimálne troch (3) rokov s možnosťou opcie na nasledujúce dva (2) roky po finálnej akceptácii a odovzdaní Diela.

V prípade odovzdania a akceptácie ľubovoľnej časti diela pred finálnou akceptáciou diela bude Zhotoviteľ povinný zabezpečiť prevádzkovú podporu pre takúto časť Diela aj pred finálnou akceptáciou Diela, pričom náklady na túto podporu a prevádzku musia budú zahrnuté v cene Diela.

7.1Prevádzkové požiadavky

7.1.1Úrovne podpory používateľov

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

• L1 podpory nového riešenia (Level 1, jednotný priamy kontakt pre používateľov nového riešenia) - zabezpečené zamestnancami Objednávateľa a ním určených osôb a/alebo NASES;
• L2 podpory nového riešenia (Level 2, postúpenie požiadaviek od L1 podpory)- zabezpečené zamestnancami Objednávateľa a ním určených osôb a/alebo NASES;
• L3 podpory nového riešenia (Level 3, postúpenie požiadaviek od L2, prípadne L1 podpory) - zabezpečené Zhotoviteľom na základe Zmluvy.

Pre prevádzkovú podporu sú definované takéto SLA:

• Help Desk je dostupný cez dedikovanú aplikáciu na hlásenie incidentov,
• Dostupnosť L3 podpory pre IS je 9x5 (9 hodín x 5 dní od 8:00h do 17:00h počas pracovných dní).
• Zhotoviteľ umožní nahlasovania servisných požiadaviek pracovníkmi L1 a L2 (preferované poradie)
  •  elektronicky cez integráciu na vystavené webové služby
  •  emailom na definovanú servisnú adresu, 
  •  telefonicky cez zákaznícke číslo;

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, alebo služieb integrovaných IS. Pričom Zhotoviteľ musí byť súčinný pri odstraňovaní vzniktnutých incidentov mimo prostredia IS.

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:

• Za odstránenie chyby sa považuje aj nasadenie dočasného náhradného riešenia umožňujúceho pokračovať v prevádzke.

(1) Reakčná doba je čas medzi nahlásením incidentu Objedná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 Objednávateľom a vyriešením incidentu Zhotoviteľom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu Objednávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť Objednávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je Zhotoviteľ oprávnený požadovať od Objednávateľa schválenie riešenia incidentu.

Incidenty nahlásené Objednávateľom Zhotoviteľovi v rámci testovacieho prostredia:

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

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

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

“Náhradné riešenie” je riešenie, ktoré nahradí poskytovanú Službu do doby opravy pôvodných prostriedkov potrebných na funkcionalitu Služby. Náhradné riešenie je poskytnuté na dohodnutý, alebo nevyhnutný čas.

7.2Požadovaná dostupnosť IS:

8.Požiadavky na personál

Uvedené v Projektovom zámere.

9.Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu bude realizované v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy v zmysle ustanovení podľa § 5 a nasledovných ustanovení.

10.Prílohy

Strana 23/23