I-03 Prístup k projektu (pristup_k_projektu)

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.

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.

1. 1. Použité skratky a pojmy

1. Popis navrhovaného riešenia

Z hľadiska subjektu sa projekt týka MIRRI SR. MIRRI SR je ústredným orgánom štátnej správy pre

a)      riadenie, koordináciu a dohľad nad využívaním finančných prostriedkov z fondov Európskej únie,

b)  oblasť investícií v rozsahu strategického plánovania a strategického projektového riadenia, ako aj koordináciu investičných projektov a vypracovanie národného strategického investičného rámca v pôsobnosti Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky, a vnútroštátnu implementáciu Agendy 2030,

c)      regionálny rozvoj vrátane koordinácie prípravy politík regionálneho rozvoja,

d)      centrálne riadenie informatizácie spoločnosti a tvorbu politiky jednotného digitálneho trhu, rozhodovanie o využívaní verejných prostriedkov vo verejnej správe pre informačné technológie, centrálnu architektúru integrovaného informačného systému verejnej správy a koordináciu plnenia úloh v oblasti informatizácie spoločnosti.

Z hľadiska ISVS sa tento projekt týka isvs_14363 Centrálny podpisový komponent, pričom sa požaduje dodanie diela, jeho nasadenie na produkčné prostredie a realizáciu v dvoch fázach:

• 1. Fáza MVP (MVP - Minimal Viable Product) - fáza s predpokladaným termínom dodania a nasadenia do 3 mesiacov odo dňa nadobudnutia účinnosti ZMLUVY
• 2. Fáza - ďalší rozvoj po realizácii MVP fázy s predpokladaným termínom dodania a nasadenia  do 10 mesiacov  odo dňa nadobudnutia účinnosti ZMLUVY

V rámci 1. fázy bude dodaný  nasledovný rozsah - MVP (MVP -Minimal Viable Product):

• Implementácia a produkčné nasadenie aplikačných komponentov CPK
• Sprístupnenie API CPK na Centrálnej API manažment platforme (CAMP)
• Poskytnutie súčinnosti pri integrácii služieb CPK do konštruktora správ na ÚPVS
• Podpísanie súboru v CPK bez možnosti prihlásenia
• Viacnásobné podpísanie dokumentu bez možnosti  prihlásenia
• Poskytnutie súčinnosti zo strany verejného obstarávateľa pri integrácii súčasných a nových lokálnych podpisových aplikácií
• Integrácia na IAM a UPVS za účelom využitia štátom garantovanej identity  na prihlásenie do CPK  pomocou WebSSO
• Vytvorenie náhľadu na podpisovanie dát podľa vizualizačných schém (v zmysle Diagramu č. 1)  pre formulár a podpisované súbory
• Overenie povolených možností autorizácie evidovaných pre danú službu v MetaIS
• Návrh dátovej štruktúry pre AFPM a vloženie príslušného formulára do MEF
• Vytvorenie autorizácie prostredníctvom funkcie prístupového miesta a jej implementácia v CPK
• Implementácia overovania auditných záznamov v CPK
• Prepoužitie (integrácia) služby pre vytvorenie elektronického podpisu odosielaného elektronického dokumentu (aplikačná služba METAIS kód=sluzba_is_1370 v CEP )
• Vrátenie autorizovaných objektov späť do žiadateľského systému / do schránky eDesk (odoslané správy)
• Priama integrácia na klientský podpisovač vo fáze 1. musí byť konfiguračne nastaviteľná pre ponuku používateľovi v CPK (Táto integrácia sa predbežne plánuje po implementácii fázy 2. vypnúť a ponechať len podpisovanie cez dodaný plug-in v čase keď budú pripravené podpisové aplikácie)
• Technická, produktová a projektová dokumentácia CPK podľa Vyhlášky Ministerstva investícií, regionálneho rozvoja a informatizácie SR č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy (ďalej len „Vyhláška MIRRI SR č. 401/2023 Z.z.“ (https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2023/401/)

Obrázok 1 Spolupráca komponentov MVP fáza

V rámci 2. fázy bude dodané nasledovné funkčnosti - Rozvoj požaduje:

• Komponent “Autorizácia prostredníctvom eID 2.0” a jeho integrácia do CPK viac info v kapitole 5.1.4
  • Autorizácia prostredníctvom eID 2.0 je modernizovaný spôsob elektronickej autentifikácie občanov, ktorý využíva čipové karty (elektronické občianske preukazy) vybavené pokročilými bezpečnostnými prvkami. Tento systém umožňuje bezpečný prístup k elektronickým službám štátu a iných OVM.
  •  Integráciou eID 2.0 do CPK sa zjednoduší autentifikácia a autorizácia používateľov, ktorí sa budú môcť pomocou svojich eID kariet (elektronických občianskych preukazov) jednoducho a bezpečne autentifikovať svoju identitu a autorizovať operácie, čo uľahčuje prístup k elektronickým službám a transakciám.
• Viacnásobná autorizácia funkciou prístupového  miesta
  • Podpis viacerými osobami funkciou prístupového miesta (viac oprávnených osôb podpisuje jedno podanie v korektnom poradí).
• Pri viacnásobnej autorizácii AFMP sa použije štruktúra dohodnutá na pracovných skupinách
• Poskytnutie súčinnosti pri zmenách v UPVS umožňujúcich Podpis lokálneho súboru podporovanými formami autorizácie (eID a/alebo eID 2.0)
• Overenie podpisov na podaní a prílohách
• Implementácia SDK (pluginu do web prehliadača podporovanej verzie webového prehliadača” podľa §16 písm. d) Vyhlášky č. 78/2020) povinného pre integráciu na lokálne podpisové aplikácie poskytovateľov
• Vytvorenie MessageDigest - digitálny odtlačok dát určených na podpisovanie
• Pripájanie časovej pečiatky (k dokumentu a/alebo k  podpisu),

Obrázok 2 Spolupráca komponentov finálneho riešenia

V súvislosti s riešením CPK, musí byť zabezpečená kompatibilita medzi dodávaným riešením v dvoch fázach uvedených vyššie a súčasne s  nižšie uvedenými bodmi:

• Úprava alebo implementácia konštruktora podania (vypĺňacej funkcie formulára podania)
• Prijatie a spracovanie správy s podaním autorizovaným funkciou prístupového miesta na rozhraní G2G ÚPVS a zobrazenie v schránke správ modulu eDesk na ÚPVS
• Overenie autorizácie funkciou prístupového miesta s využitím komponentu CEP pri doručovaní a preberaní takto autorizovaného podania v schránke v eDesk na ÚPVS 

MIRRI SR, NASES a úspešný uchádzač zabezpečia súčinnosť pri integrácií dodávaných komponentov.

1. Architektúra riešenia projektu

CPK, ktorý verejný obstarávateľ požaduje a ktorý je predmetom tejto zákazky, má poskytnúť služby pre centrálne podpisovanie a riadenie procesu podpisovania. Musí byť  otvorený pre dynamické pridávanie nových komponentov alebo modulov zabezpečujúcich podpisovanie (napr. vzdialené podpisovanie). CPK má poskytnúť definované rozhranie cez ktoré integrovaná podpisová služba bude môcť poskytnúť informácie o rozsahu služieb a formáte podpisov ktoré poskytuje.

Diagram 3: Aplikačný pohľad na požadované riešenie

Verejný obstarávateľ požaduje, aby komponent CPK pozostával z grafického webového používateľského rozhrania (GUI), servisnej vrstvy – služby vystavené cez REST API a backend časti. Webová aplikácia bude slúžiť na vytváranie podpisov pre používateľov pri podpisovaní ľubovoľných elektronických úradných dokumentov, ako aj pri tvorbe elektronických podaní a bude prístupná z ktoréhokoľvek bodu ISVS. Tieto ako aj všetky ostatné funkcionality, budú mať reprezentáciu vo forme REST služieb sprístupnených cez integračnú platformu. Dielo odbremení používateľa, ktorý si už ďalej nemusí inštalovať rôzne typy podpisových aplikácií.

CPK umožní podpísať elektronický dokument alebo podanie kvalifikovaným alebo zdokonaleným elektronickým podpisom alebo pečaťou. V prípade použitia pečate využitím HSM modulu musí byť používateľ autentifikovaný, overené jeho  zastupovanie PO alebo OVM a musí mať priradenú rolu R_EDESK_SIGN. Používateľ musí mať možnosť výberu z jestvujúcich certifikátov a filtrovať zoznam certifikátov podľa typu (mandátny certifikát, KEP, KEPe pečať – HSM modul). Formáty podpisovaného dokumentu aj podpísaného dokumentu sú definované štandardmi uvedenými v kapitole 7 „Nutné  legislatívne požiadavky“ (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, ďalej ako „Vyhláška ÚPVII č. 78/2020 Z.z.“ § 46, § 47 a § 48 ).

Podporované nepodpísané súbory:

• .pdf .doc .docx .odt .txt .xml .rtf .png .gif .tif .tiff .bmp .jpg .jpeg

Podporované podpísané súbory na podpis a overenie:

• .pdf .xml .asics .scs .asice .sce .p7m

Podporované podpísané súbory len na overenie:

• .zep .zepx .xzep

Verejný obstarávateľ požaduje, aby každá služba si mohla konfiguračne nastaviť zoznam povolených typov súborov na podpis.

CPK umožní aj podpísanie lokálneho elektronického súboru a nahratie dokumentu a možnosť konverzie integráciou na príslušnú službu CEPu do povinných formátov PDF/A-2 až 4. Maximálna podporovaná veľkosť lokálneho súboru má byť max. 100 MB s možnosťou konfigurácie na požiadavku verejného obstarávateľa.

CPK tiež umožní a poskytne funkcionalitu pre hromadné podpisovanie elektronických úradných dokumentov či viacerými používateľmi (viacnásobné podpísanie elektronických dokumentov alebo podaní). Zároveň umožní aj spoločnú autorizáciu viacerých elektronických dokumentov konfiguračne podľa typu osoby používateľa vzhľadom na povinnosť vytvárať spoločnú autorizáciu zo strany OVM a nemožnosť vytvárania spoločne autorizovaných podaní zo strany FO/PO. Podpisový kontajner sa vyskladáva na serveri CPK, nie lokálne, tým pádom sa aj všetky citlivé dokumenty nahrávajú na server CPK.

CPK integráciou na službu vytvorenia časovej pečiatky zabezpečí jej pridanie pre každý podpis do podpisovaného dokumentu alebo podania.

Je požadovaná implementácia funkcionality pre zobrazenie podpisov predchádzajúcich osôb pri viacnásobnom podpisovaní spolu s kvalifikovanou elektronickou časovou pečiatkou.

CPK má podporovať nasledujúce formáty podpisov a podpisových kontajnerov.

• XAdES
• PAdES
• CAdES
• ASiC
• a do budúcna ďalšie ktoré budú definované v rámci novely eIDAS a nie sú momentálne uvedené

Po úspešnom a kompletnom podpísaní dokumentu nastane kontrola všetkých už vytvorených podpisov a vráteniu podpísaného dokumentu do komponentu, ktorý inicializoval volanie CPK. CPK bude preberať podmienky autorizácie podľa informácií k už poskytovaným službám v systéme METAIS, obsahujúce požadovanú úroveň autentifikácie, typ používateľa (FO/PO, OVM), minimálnu úroveň autorizácie podania a zoznam metód autorizácii, ktoré budú na základe tejto konfigurácie služby používateľovi dostupné. Kontrola podpisov na prílohách podania bude konfigurovateľná v zmysle podmienok poskytovania služby v METAIS.

Overovanie podpísaných dokumentov a podaní bude možné vykonať prostredníctvom služby CEP alebo SNCA. Konkrétna služba bude došpecifikovaná až v DNR. Validačný report bude vo formáte poskytovanom CEP, resp. SNCA. CPK musí zabezpečiť používateľsky prijateľnú vizualizáciu výsledku overenia.

Súčasťou predmetu zákazky  CPK bude JavaScript knižnica, ktorú bude možné poskytnúť správcom ISVS a prevádzkovateľom iných portálových riešení, ktorí budú integrovať služby CPK  do ich informačných systémov. Súčasťou predmetu zákazky riešenia CPK je aj návrh jednotného integračného štandardu a súčinnosť pre zabezpečenie integrácie nových verzií lokálnych podpisových aplikácií.

Realizácia procesu podpísania sa požaduje výhradne v online režime, tzn. že pri využívaní CPK komponentu je potrebné mať internetové spojenie so službami CPK. Pred vytváraním podpisu je nutné vykonať validáciu certifikátu, ktorý k úkonu chceme využiť. Požadujeme, aby pri realizácii podpisu bolo možné do podpisu súboru (dokumentu, dát formulára podania) vložiť časovú pečiatku (využitím služby centrálnej podateľne CEP alebo akéhokoľvek iného dôveryhodného poskytovateľa služby časovej pečiatky).

CPK bude vytvárať systémové aj aplikačné záznamy o svojej činnosti. Záznamy budú distribuované do centrálneho systému zberu logov a prevádzkového dohľadu v NASES. Vybrané aplikačné záznamy aktivít budú poskytované aj pre používateľov aplikácie, aby si sami mohli skontrolovať záznamy, ktoré vykonali alebo boli vykonané v ich zastúpení. Záznamy o aktivitách, ktoré budú určené aj pre používateľov musia používateľsky zrozumiteľne popisovať zaznamenanú aktivitu: čas aktivity, meno používateľa a zástupcu, ich ID, výsledok aktivity, zrozumiteľný popis aktivity alebo chyby, identifikácia objektu, s ktorým bola aktivita vykonaná.

1. 1. Predpoklady realizácie projektu rozvoja

Aby sa mohli realizovať všetky scenáre použitia, je nutné mať splnené nasledujúce predpoklady:

1. Používateľ bude autentifikovaný do prostredia ÚPVS. V prípade autorizácie pomocou AFPM je vyžadovaná forma autentifikácie minimálne na úrovni “pokročilá”. Pri ostatných formách autorizácie je nutnosť autentifikácie definovaná OVM.
2. Používateľ je oprávnený v zmysle prístupu k službám.
3. Používateľ úspešne vytvorí elektronické podanie.
4. ISVS OVM využívajúci služby CPK je integrovaný s ÚPVS.
5. Pre niektoré spôsoby podpisovania je nutné mať aktivovanú mobilnú aplikáciu, ktorá nie je predmetom zákazky.

CPK po zrealizovaní poslednej autorizácie neuchováva podpísané dokumenty ani podania.

1.  
   1. Biznis vrstva a aplikačná architektúra

Po splnení vyššie uvedených predpokladov bude možné prostredníctvom kanála, v ktorom podanie vzniká, vyvolať služby vystavené na novom CPK komponente. CPK má implementovať viaceré spôsoby autorizácie, pričom ale tieto spôsoby autorizácie nebudú navzájom plne zastupiteľné. Možné spôsoby autorizácie pre konkrétnu službu majú byť poskytované podľa údajov evidovaných na príslušných biznis službách v Meta IS. Pre každú službu bude v METAIS evidované, akými spôsobmi je možné ju autorizovať.

Úlohou komponentu CPK nie je zabezpečiť vytváranie formulárov podaní a príloh. Komponent  CPK vie autorizovať jeden alebo viac objektov, v rámci jedného podania, ktoré vyžadujú podpis v závislosti od kontextu (identifikácia služby, povinné osoby, spôsob autorizácie). Komponent vystavuje rozhranie, pomocou ktorého získa odkaz alebo priamo zoznam objektov na autorizáciu.

CPK pracuje v štyroch krokoch :

1. prijme  objekt alebo objekty na autorizáciu a kontext podpisu (identifikácia služby, povinné osoby, spôsob autorizácie)
2. zvolí spôsob autorizácie a vyberie vhodný certifikát podľa konfigurácie služby v MetaIS
3. zabezpečí vytvorenie podpísaného objektu buď vlastnou funkcionalitou, alebo pomocou vystavených služieb lokálnej podpisovej aplikácie
4. a následne vráti podpísané objekty do volajúceho informačného systému, alebo v prípade  AFPM odošle Sk-Talk správu.

Keďže z dokumentu musí byť vypočítaný hash (DTBS/R) a vizualizácia dát na podpis je počas podpisovania nutné, aby bol ukladaný na dočasnom úložisku a po odovzdaní riadenia volajúcej aplikácii vymazaný.

V CPK v súčasnosti požadujeme  tieto možnosti autorizácie v zmysle vyjadrenia vôle / podpisovaním:

• Autorizácia prostredníctvom KEP alebo AdES-QC (t.j. uznaného spôsobu autorizácie) na desktope. V tomto prípade sa očakáva integrácia CPK na lokálne podpisové aplikácie zabezpečujúce vytvorenie elektronického podpisu v prostredí ÚPVS
• Autorizácia funkciou prístupového miesta (AFPM).
• Autorizácia prostredníctvom KEP na mobile pomocou eID 2.0 alebo eDoPP a NFC.
• Autorizácia OVM - vytvorenie elektronického podpisu/elektronickej pečate odosielaného elektronického dokumentu (rozhodnutia).

Diagram 4: Architektúra CPK – Proces podpísania všeobecne

Medzi konštruktorom správ a samotným CPK je zvýraznený tok dát, ktorý umožni výmenu objektov na podpis. CPK má k dispozícii dátový tok do lokálnej podpisovej aplikácie.

1. 1. 1. Proces autorizácie podania – všeobecne

Zovšeobecnený popis procesu vykonania autorizácie jednou osobou v CPK nad jedným objektom:

1. Aktivácia CPK, počas ktorého konštruktor správ doručí do CPK
   1. objekt na autorizáciu, alebo odkaz na ich umiestnenie v úložisku,
   2. kontext autorizácie, čiže dodatočné informácie o koncovej službe (identifikácia služby, povinné osoby, spôsob autorizácie)
2. Výber  z povolených spôsobov autorizácie na základe údajov z Meta IS
3. V prípade autorizácie (vytvorenia el. podpisu) lokálnou podpisovou aplikáciou:
   1. Overenie dostupnosti podpisovej aplikácie (overenie, že aplikácia je nainštalovaná a pripravená na komunikáciu s CPK),
   2. Výmena informácií o poskytovaných službách podpisovej aplikácie (napr. poskytovaná služba vizualizácie, overenia certifikátov atď.),
   3. Inicializácia podpisovacieho procesu v podpisovej aplikácií. 
4. Výber poskytovateľa a certifikátu
   1. je nutné overiť, či so zvolenými certifikátmi možno realizovať autorizáciu a pri negatívnom výsledku umožniť novú voľbu spôsobu a poskytovateľa.
5. Zobrazenie objektu na autorizáciu vo formáte podľa prezentačnej schémy (ak sú v objekte už iné podpisy alebo pečate, zobrazí stručnú informáciu o ich stave). V prípade AFPM sa okrem zobrazenia dát na podpis zobrazí aj  upozornenie, že autorizácia bude vykonaná funkciou prístupového miesta.
6. Overenie či prihlásená osoba je oprávnená vytvoriť podpis:
   1. V prípade AFPM opätovným prihlásením,
   2. V ostatných prípadoch zadaním BOK a PIN k QSCD.
7. Vytvorenie MessageDigest - digitálny odtlačok dát určených na podpis.
8. Zašifrovanie MessageDigestu vybraným poskytovateľom podpisových služieb a vybratým privátnym kľúčom používateľa. Poskytovateľ musí používať kryptografické algoritmy, ktoré sú povolené v podpisovej politike NBU. V súlade s nariadením sa nesmie uvádzať odkaz na podpisovú politiku vo vytváraných kvalifikovaných elektronických podpisoch a pečatiach.
9. Vytvorenie autorizovaného objektu podľa zvoleného spôsobu autorizácie:
   1. Napríklad podpisového kontajnera vo formáte ASiC, alebo
   2. Vytvorenie a odoslanie Sk-Talk správy v prípade AFPM.
10. Vrátenie výsledku autorizácie do komponentu, ktorý inicioval autorizáciu (napr. konštruktor podaní, konštruktor správ). 
11. Vrátenie riadenie konštruktoru s informáciou o výsledku autorizácie a/alebo odoslania.

Samotná práca s podpisovaným objektom  môže byť  celá alebo čiastočne vykonaná na strane CPK alebo podpisovej aplikácie.

Podrobný popis

Po úspešnej autentifikácii do prostredia ÚPVS prostredníctvom jedného z kanálov a zároveň po úspešnom vytvorení konkrétneho podania sa používateľ rozhodne, či potrebuje autorizovať toto podanie alebo iba  prílohu dokumentu k samotnému podaniu. CPK mu podľa definície používateľskej služby v METAIS ponúkne zoznam akceptovaných autorizačných spôsobov. Používateľovi bude zobrazené GUI rozhranie komponentu CPK, v ktorom bude ponúknutý ucelený zoznam prípustných foriem autorizácie.

Používateľ vyberie želanú formu, CPK realizuje potrebnú integráciu, zabezpečia sa kontroly  ako overenie tokenov, kontrola autentifikácie minimálne na úrovni QAA L3, QA kontroly a podobne.

Následne sa vykoná samotné podpísanie podania a zapečatenie. V ďalšom kroku prebehne overenie všetkých podpisov na podaní, vrátane podpisov  na prílohách (ak sú podpísané). Používateľ bude mať možnosť aj v tomto kroku ešte podpisy odobrať a vrátiť sa späť.

V prípade, že používateľom  zvolený objekt nebude môcť byť podpísaný,  pretože pre želanú formu podpisu nemá vyhovujúci certifikát, CPK vráti používateľa na zoznam akceptovaných autorizačných spôsobov.

CPK následne podpísané objekty vráti späť do systému, ktorý o podpis žiadal. Alternatívne bude možné si kópiu autorizovaného objektu stiahnuť na vlastné úložisko. Pri každej aktivite, ktorá sa bude týkať  podpísania vznikne auditný záznam.

1. 1. 1. Spôsoby autorizácie
         1. Autorizácia podania elektronickým podpisom používateľa pomocou eID alebo eDoPP

Autorizácia KEP v zmysle § 23 ods. 1 písm. a) bod 1  zákona č. 305/2013 Z.z. o e-Governmente a Autorizácia uznaným spôsob autorizácie podľa § 1 ods.1 písm. a) v zmysle Vyhlášky MIRRI SR č. 511/2022 Z.z. o uznaných spôsoboch autorizácie (ďalej ako „Vyhláška MIRRI SR č. 511/2022 Z.z.).

Prostredníctvom KEP bude možné podpísať každé elektronické podanie, rozhodnutie a ich prílohy, ktoré sa nachádzajú v ÚPVS. Pre výber a overenie možnosti použiť uznaný spôsob autorizácie bude zavedený krok pre overenie možnosti spôsobov autorizácie na základe údajov o službe z Meta IS repozitára. Po výbere spôsobu autorizácie (KEP, alebo uznaný spôsob autorizácie) bude požívateľovi pri realizácii podpisu ponúknutá možnosť výberu z jeho dostupných certifikátov. Po realizácii výberu bude vyzvaný na zadanie PIN k podpisovaciemu kľúču. V prípade, že boli predchádzajúce kroky úspešné, bude vytvorený elektronický podpis a podpisový kontajner podpisovaného objektu (podania, rozhodnutia, alebo prílohy). Používateľ dostane možnosť stiahnuť si už podpísaný objekt do lokálneho súboru.

1. 1. 1. 1. Autorizácia funkciou prístupového miesta (AFPM)

Autorizácia  použitím na to určenej funkcie ústredného portálu alebo špecializovaného portálu v zmysle § 23 ods. 1 písm. a) bod 2 zákona č.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).

Jedná sa o zjednodušený proces autorizácie vybraných podaní a služieb odoslaním elektronického podania do elektronickej schránky OVM prostredníctvom ÚPVS alebo prostredníctvom špecializovaného portálu po opätovnej autentifikácii do prostredia ÚPVS. Osoba je  autentifikovaná najmenej na úrovni „pokročilá“. CPK poskytne GUI pre zabezpečenie svojej funkcionality.

Pri volaní tejto služby  CPK dôjde k nasledujúcim kontrolám:

• Volanie Služby CPK  vykonal systém s príslušným oprávnením,
• Zhoda SenderId / SubjectId - autentifikovaná osoba je zhodná s odosielateľom správy,
• Minimálny QAA Level 3 / Level of Assurance prihlásenia používateľa,
• Opätovné prihlásenie pred odoslaním podania sa bude kontrolovať vekom tokenu,
• Validácia nakonfigurovaných akceptovaných autorizačných prostriedkov pre službu a formulár v MetaIS (kód služby v METAIS),
• Kontrola zastupovania v prípade PO.

AFPM nebude k dispozícii pre podpis lokálne nahratého súboru (bez podania). Prílohy obsahujúce iné podpisy sa pomocou AFPM neautorizujú. Popis krokov pri AFPM:

Autorizačná informácia z bodu 8.2 bude realizovaná novou dátovou štruktúrou. Dátová štruktúra bude prenášaná ako objekt v správe s Class AUTHORIZATION, v ktorej uvedie údaje o autorizovaných dokumentoch, použitom spôsobe autorizácie ako aj údaje o samotnej autorizácii.  Štruktúra je navrhnutá tak, aby ju bolo možné v budúcnosti využiť aj pre iné spôsoby autorizácie. Detailný popis je v Prílohe č. 1 Opisu predmetu zákazky „Návrh dátovej štruktúry pre AFPM“.

Prijatie, spracovanie a overenie podania na strane G2G rozhrania ÚPVS, zobrazenie informácie o tomto spôsobe autorizácie v eDesk a overenie autorizácie v CEP nie sú predmetom zákazky  podľa tohto zadania.

Podpis viacerými osobami funkciou prístupového miesta (viac oprávnených osôb podpisuje jedno podanie v korektnom poradí) bude súčasťou fázy 2 v zmysle kapitoly 4.

1. 1. 1. 1. Autorizácia eID 2.0 alebo eDoPP 2.0 s NFC rozhraním (podpisovanie na mobile)

Autorizácia KEP v zmysle § 23 ods. 1 písm. a) bod 1 zákona č.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).

Predpokladom pre tento scenár podpisovania:

• Aktivovaná mobilná aplikácia previazaná s konkrétnou identitou z IAM modulu,
• Podania, dokumenty, prílohy budú ukladané do momentu odoslania na dočasnom úložisku podporujúcom S3 protokol,
• V momente úspešnej autorizácie budú súbory z dočasného úložiska odstránené.

Proces podpísania prostredníctvom eID 2.0 prvku je podpisovaním KEP. Certifikáty budú však v tomto prípade prístupné prostredníctvom komunikačného protokolu NFC.

Existujúci eID framework v mobilnej aplikácii „Slovensko v mobile“ umožňuje komunikovať cez NFC s eID 2.0 a podpísať ľubovoľný textový reťazec pomocou certifikátov uložených na eID 2.0 zariadení s NFC chipom. Od používateľa si vypýta BOK a KEP PIN.  Pre podpísanie dokumentu sú potrebné nasledovné funkcionality:

• Získanie a vytvorenie DTBS/R reprezentácie dokumentu (Data To Be Signed Representation) podľa ETSI EN 319 102-1).  Aktivitu vykoná backend  CPK.
• Zobrazenie podpisovaného dokumentu používateľovi spolu s údajmi o podaní, type a názvu dokumentu a prípadnými už existujúcimi podpismi. Môže byť samotný dokument, alebo vygenerovaný náhľad. Návrh riešenia musí podporovať pravidlá prístupnosti.
• Vytvorenie bezpečného komunikačného kanálu a relácie medzi CPK a mobilnou aplikáciou.
  •  Komunikačný kanál musí byť implementovaný v súlade s Normami ETSI TS 119 101 a ETSI TS 119 102, 
  • Mobilná aplikácia musí čítať URL uvedené v Push notifikácii a QR kóde a následne komunikovať s poskytnutými URL.
• Verifikácia platnosti podpisového certifikátu. Vykonávať sa bude na backende CPK.
• Konverzia dokumentu do štandardizovaného formátu. Vykonávať sa bude na backende CPK.
• Vytvorenie podpisu (zašifrovanie dát na podpis) v mobilnej aplikácii pomocou eID frameworku.
• Vloženie podpisu do dokumentu. Vykonávať sa bude na backende CPK.
• Získanie časovej pečiatky z CEP Vloženie časovej pečiatky volaním komponentu CEP, služby „              
  1. 1. 1. Autorizácia OVM

Pri Autorizácii OVM ide o nasledovné spôsoby a služby autorizácie vykonávanej pracovníkmi OVM:

• Vytvorenie elektronického podpisu odosielaného elektronického dokumentu, ktorý predstavuje autorizáciu vytváranie kvalifikovaných pečatí v zmysle § 23 ods. 1 zákona č.305/2013 Z.z. o e-Governmente náhradou alebo prepoužitím (integráciou) jestvujúcej funkcionality CEP (Modul centrálnej elektronickej podateľne, aplikačná služba METAIS kód=sluzba_is_1370, služby DITEC_CEP_PODPISANIE_DOKUMENTOV a DITEC_CEP_PODPISANIE_DOKUMENTOV2 podľa integračného manuálu CEP).
• Vytvorenie elektronického podpisu odosielaného elektronického dokumentu, ktorý predstavuje autorizáciu v zmysle § 23 ods. 3 zákona č.305/2013 Z.z. o e-Governmente - vytváranie kvalifikovaného podpisu konkrétnou osobou alebo osobou v konkrétnom postavení, kedy OVM na autorizáciu použije KEP vyhotovený s použitím mandátneho certifikátu, ku ktorému sa pripojí kvalifikovaná elektronická časová pečiatka. Vtedy musí CPK realizovať autorizáciu podľa kapitoly 4.4.2 Autorizácia podania elektronickým podpisom používateľa pomocou eID alebo eDoPP alebo kapitoly 4.4.4 Autorizácia eID 2.0 alebo eDoPP 2.0 s NFC rozhraním (podpisovanie na mobile) tohto dokumentu.

Autorizácia sa uskutoční volaním celej služby pečatenia z CEP. V CEP vzniká celý formát podpisu a podpisový kontajner. Spôsob integrácie na CEP je v integračnom manuáli. V prípade, že uchádzač nedisponuje prístupovými údajmi k PFP portálu na nahliadnutie integračných manuálov, budú tieto manuály na vyžiadanie poskytnuté zo strany verejného obstarávateľa. Uchádzač môže kontaktovať e-mailovú adresu integracie@nases.gov.sk, alebo využiť oficiálny kontakt uvedený vo verejnom obstarávaní.

1. 1. 1. Overovanie podpisov

CPK komponent bude podporovať viacnásobné podpisovanie (pridanie podpisu ďalšej osoby). Pri viacnásobnom podpisovaní treba  overiť a zobraziť už existujúce podpisy na podpisovanom objekte. CPK preto integruje službu CEP pre overenie podpisov a overenie AFPM tak, aby bola k dispozícii v procesoch a službách poskytovaných CPK. Overenie AFPM bude nová funkcionalita implementovaná v CEP. Rozšírenie funkcionality CEP  pre overenie AFPM a jej využitie v procese zasielania podaní do eDesk nie je predmetom tejto zákazky.

Overenie AFPM bude riešené rozšírením služieb CEP tak, aby služba overenia podpisu rozoznávala tento spôsob autorizácie podania. Overenie tohto typu autorizácie bude tiež doplnené do štandardného procesu overovania podpisov na správach zasielaných do eDesk, aby OVM mohli využiť výsledok overenia vo svojich procesoch spracovania podania podobným spôsobom, ako podania autorizované el. podpisom klienta

1. 1. 1. Odstránenie podpisov na nepodanom podaní - Odobratie podpisu

Komponent CPK má vystavovať aj službu, ktorá zabezpečí zrušenie podpisov na predtým podpísaných dokumentoch, tzv. „odpodpísanie“. Táto služba je implementovaná a poskytovaná v CEP a do CPK bude integrovaná, nebude ju duplicitne implementovať.

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

Samotný ISVS ma vystavenú jedinú koncovu službu “Vytvorenie a kontrola podpisov nahratého súboru”. Používatelia ktorými sú občania, podnikatelia, alebo OVM buď používajú ISVS cez túto službu alebo prostredníctvom KS iných ISVS ktoré v procese riešenia konkrétnych životných situácií potrebujú podpísať alebo pečatiť podanie, rozhodnutie alebo iný úradný dokument.

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

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

Jazyková podpora e uvedená v katalógu požiadaviek . Pod čislami ID_105, ID_106, ID_107, ID_108

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

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

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

Z pohľadu ISVS sú v tabuľke uvedené dotknuté systémy:

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

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

Z pohľadu integrácií sa budú využívať nasledovné nadrezortné a spoločné ISVS

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

V nasledujúcej tabuľke sú uvedené predpokladané integrácie na iné Informačné systémy

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

V nasledujúcej tabuľke sú uvedené dotknuté aplikačné služby, ktoré budú vybudované v rámci projektu rozvoja

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

V rámci projektu nebude vytvorená aplikačná služba na integráciu

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

Z ISVS nebudú poskytované údaje do IS CSRU

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

ISVS nebude konzumovať údaje z IS CSRU

1.  
   1. Dátová vrstva

Navrhovaná štruktúra sa bude používať aktuálne pre autorizáciu odoslaním podania po predchádzajúcej autentifikácii. Štruktúra je navrhnutá tak, aby ju bolo možné využiť aj pre iné spôsoby autorizácie v budúcnosti.

Zdôvodnenie potreby vytvorenia dátovej štruktúry:

Štandard pre elektronické správy Sk-Talk a jednotný formát elektronických správ MessageContainer majú v súčasnosti pevne stanovené elementy, ktoré nie je možné využiť pre uvádzanie údajov o použitom spôsobe autorizácie. V prípade autorizácie vo formátoch zdokonalených elektronických podpisov ASiC, PAdES alebo v slovenských formátoch XAdES_ZEP, ZEPf (používaných podľa legislatívy účinnej do 30.6.2016) sa autorizácia objektu vyznačuje v atribúte IsSigned, na základe ktorého sa určuje, či sa má daný objekt považovať za autorizovaný a overiť štandardnými overovacími nástrojmi v elektronickej podateľni podporujúcimi tieto formáty podpisov. (V podateľniach sa štandardne overujú KEP/pečať, zdokonalený elektronický podpis založený na kvalifikovanom certifikáte, zdokonalený elektronický podpis kvalifikovanej služby validácie alebo kvalifikovanej služby uchovávania.)

Z uvedeného dôvodu sa pre tieto prípady navrhuje vytvoriť novú dátovú štruktúru prenášanú ako objekt v správe s Class AUTHORIZATION, v ktorej daný informačný systém (špecializovaný portál) uvedie údaje o použitom spôsobe autorizácie, ako aj údaje o samotnej autorizácii.

OVM si pre účely automatizovaného spracovania takejto formy autorizácie musia upraviť svoje informačné systémy tak, aby v doručenej správe vyhľadávali dátovú štruktúru v Class AUTHORIZATION a vyhodnocovali resp. zobrazovali jej obsah obdobne, ako v prípade výsledku overenia podpisov.

Za týmto účelom sa navrhuje aj úprava zobrazenia elektronickej správy v elektronickej schránke, aby zobrazovala v čitateľnej forme informáciu o použitom spôsobe autorizácie odoslaním.

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

Uvedené vyššie

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

Uvedené vyššie

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

V rámci projektu nebudú vytvárané referenčné údaje

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

Irelevantné

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

Irelevantné

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

Irelevantné pre projekt

1. 1. 1. 1. Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Irelevantné pre projekt

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

Irelevantné pre projekt. Vzhľadom, že povaha projektu nie je dátového charakteru, nebudú nižšie uvedené pozície na projekte využité.

1.  
   1. 1. Otvorené údaje

Irelevantné pre projekt

1. 1. 1. Analytické údaje

Irelevantné pre projekt

1.  
   1. 1. Moje údaje

Irelevantné pre projekt

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

Irelevantné pre projektu

1. 1. Technologická vrstva

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

N/A

1. 1. 1. Pož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, …).

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

Návrh riešenia technologickej architektúry je v Projektovom zámere

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

Projekt bude prevádzkovaný v prostredí NASES alebo vo vládnom cloude.  Konkrétne typy databáz, aplikačných serverov, úložísk a iných infraštrukturálnych služieb budú identifikované vo fáze Analýza a dizajn projektu. Zatiaľ je vytvorený len predbežný návrh a modelový príklad vychádzajúci z využitia infraštruktúrnych služieb podľa názvoslovia používaného v NASES.

IaaS PCA (Infrastructure as a Service - Private Cloud Appliance) (NASES ma aj  alternativu Hyperflex - IaaS kde bezi virtualizovane prostredie)

-obe ralizuju VM a na nich pobezi
-- K8S PaaS (Kubernetes Platform as a Service)

-- DB as PaaS

-- Storage PaaS (Storage as a Service)

Nižšie uvedená tabuľka nie je uvedené z dôvodu že zatial pracujeme len s generickou typologiu služieb a ešte neboli vybrane finálne PaaS a IaaS konkrétnych dodavateľov uvádzané v MetaIS.

 

V nižšie uvedenej tabuľke je predpokladané využitie infraštruktúrnych služieb pre definované prostredia, pričom ich detailizácia a väzba na katalóg požiadaviek bude doplnená po fáze Analýza a dizajn projektu.

Toto len ak by to malo napríklad vlastny IAM, backup alebo monitoringg....

Katalóg služieb Vládneho cloudu SR

1. 1. Bezpečnostná architektúra

Realizovaný projekt bude v súlade s 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.

V rámci verejného obstarávania bude definovná požiadavka na dodávateľa, aby bol dodaný ISVS v súlade s vyššie uvedenými normami.

Súčasťou dodávky bude aj bezpečnostný projektu

1. Závislosti na ostatné ISVS / projekty

V nasledujúcej tabuľke sú uvedené závislosti projektu na iných projektoch

1. Zdrojové kódy

Bude dodržaný princíp otvorenosti, tzn. duševným vlastníkom všetkých výstupov, vrátane technológie a zdrojového kódu bude štát. Výnimku predstavuje Preexistentný zdrojový kód, na ktorý sa vzťahuje osobitný právny režim.

1. Prevádzka a údržba

Poskytovateľ služby je povinný zabezpečiť prevádzkovú podporu dodávaného diela  a všetkých jeho súčastí na obdobie dvoch (2) rokov s možnosťou opcie na nasledujúce dva (2) roky.

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

Verejný obstarávateľ požaduje, aby  poskytovateľ služby realizoval Help Desk nasledovnej úrovne podpory

• L1 podpora: (Level 1) – Jednotný priamy kontakt pre používateľov nového riešenia. Zabezpečené zamestnancami verejného obstarávateľa a/alebo ním určených osôb.
• L2 podpora: (Level 2) – Postúpenie požiadaviek od L1 podpory. Zabezpečené zamestnancami verejného obstarávateľa a/alebo ním určených osôb.
• L3 podpora: (Level 3) – Postúpenie požiadaviek od L2, prípadne L1 podpory. Zabezpečené Poskytovateľom služby na základe uzavretej zmluvy.

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

• Help Desk je dostupný prostredníctvom telefonického kontaktu alebo e-mailu. 
• Dostupnosť L2 a L3 podpory pre IS je 10x7 (10 hodín x 7 dní v týždni od 8:00h do 18:00h ).
  1. Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t. j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou.

• 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 zo strany poskytovateľa služby umožňujúceho pokračovať v prevádzke, na nevyhnutne nutnú dobu.(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L2 a L3 a jeho prevzatím na riešenie.

(2) Doba konečného vyriešenia incidentu (DKVI) znamená obnovenie štandardnej prevádzky - čas medzi  nahlásením incidentu verejným obstarávateľom a vyriešením incidentu Poskytovateľom služby (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je Poskytovateľ služby oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

Incidenty nahlásené verejným obstarávateľom  Poskytovateľ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 pre prevádzkovú podporu 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).
  1. Výkonnosť a dostupnosť služieb

1. 1. Služby riadenia systémovej a aplikačnej podpory (paušál)

Servisné služby vzťahujúce sa na produkčné aj testovacie prostredie systému, ktoré je prevádzkované v infraštruktúre vládneho cloudu medzi ktoré patria: činnosti správy a údržby systémového softvéru a  systému  (vrátane kontroly príslušných operačných systémov, kontroly logov, naplnenosti diskového priestoru, operačnej pamäte, správy komunikačnej matice pre jednotlivé služby produktov, sledovania informácií výrobcov a dodávateľov zariadení, príslušných bezpečnostných riešení, patchov a nutných aktualizácií, správa služieb infraštruktúry (DNS, NTP, VPN), monitorovanie vyťaženosti systému, monitorovanie sieťovej komunikácie, monitorovanie naplnenosti databáz, správa certifikátov interných/externých, prideľovanie systémových prostriedkov (CPU, Disk, RAM), vytváranie záloh, nasadzovanie nových verzií, riešenie úloh, vykonávanie preventívnej údržby, udržiavanie systému v súlade s bezpečnostnou dokumentáciou, súčinnosť a odstraňovanie zistení z bezpečnostného auditu.

Servisné služby budú realizované so zámerom:

• Uvedenie systému  do plne funkčného stavu alebo poskytnutie náhradného riešenia (po poruchách, chybách) podľa definovaných parametrov  pre produkčné prostredie pre nové riešenie CPK.
• Podpora systémového softvéru a aplikačného softvéru  v produkčnom aj testovacom prostredí (vrátane riešenia vzniknutých problémov).
• Nasadzovanie nových verzií aplikačného programového vybavenia do testovacieho a produkčného prostredia.
• Lokalizácia potenciálnych problémov pri používaní prostredia.
• Optimalizácia prevádzky na základe odsúhlasených návrhov riešení.
• Aktualizácia prevádzkovej, používateľskej a bezpečnostnej dokumentácie vyplývajúcej z aktuálneho nastavenia systému.
• Poskytovanie podpory pri integrácii CPK s inými systémami a aplikáciami používanými objednávateľom.

1. 1. Činnosti správy a údržby systémového softvéru a aplikačného softvéru  vykonávané priebežne (paušál)

Priebežná správa a údržba CPK

Tieto činnosti sa vykonávajú v pravidelných intervaloch s cieľom preventívne identifikovať možné problémy. Ide zväčša o monitorovanie a kontrolovanie definovaných parametrov na základe vopred definovaného profylaktického plánu. Výsledky kontrol budú evidované v reporte s návrhom preventívnych akcií na elimináciu neštandardných stavov systému.

Evidencia a reportovanie

• Spracovávanie požadovaných reportov a operatívnych informácií: O stave prevádzky, poskytovania služieb, výsledkoch monitoringu, kontrol a auditov.
• Vedenie technických a prevádzkových evidencií: Vrátane technickej dokumentácie, nastavení parametrov, evidencie technických prostriedkov, používateľských príručiek, evidencie dodávateľov a kontaktných osôb.
• Poskytovanie štatistických informácií: Pre verejného obstarávateľa a ním určené osoby.

Evidencia a reportovanie bude stanovené po vzájomnej dohode medzi poskytovateľom služby a verejným obstarávateľom.

Zabezpečovanie kvality služieb

Predkladanie návrhov opatrení na zlepšenie kvality služieb prevádzky a implementáciu schválených opatrení:

• Plánovanie a riadenie preventívnej údržby
• Riadenie preventívnej údržby a opráv: Vrátane prevádzkových a bezpečnostných auditov.
• Riadenie vnútorných procesov: A spolupráce s ostatnými zložkami.

Administrácia a manažment:

• konfigurovanie a správa diskových subsystémov,
• vytváranie, konfigurovanie a rušenie prístupových účtov v OS,
• vytváranie a rušenie adresárových štruktúr,
• prideľovanie,  odoberanie a správa prístupových práv,
• správa bezpečnostnej a skupinovej politiky,
• rekonfigurácia parametrov operačných systémov a systémového aplikačného vybavenia,
• plánovaný a neplánovaný shutdown, reštart alebo štart systému, odpájanie a zapájanie systémov,
• inštalácia aktualizácií a patchov štandardného systémového softvéru,
• vytváranie a evidencia firewallových pravidiel,
• konfigurovanie integrácií na iné informačné systémy verejnej správy.
• Implementácia a udržiavanie bezpečnostných opatrení na ochranu údajov spracovávaných prostredníctvom CPK, vrátane šifrovania a kontrol prístupu.

Zálohovanie a obnova:

• konfiguračný manažment zálohovacieho systému,
• zálohovanie a obnova systémového softvéru,
• vytváranie, konfigurácia a správa zálohovacích scriptov,
• vykonávanie pravidelných a nepravidelných záloh systému,
• evidencia a správa systému záloh,
• obnova systémového softvéru (OS + systémové utility),
• obnova konfigurácie a parametrov komponentov,
• zálohovanie a obnova databáz.

Monitoring:

Dodávateľ špecifikuje optimálne nastavenie monitorovania udalostí dodávaného riešenia v produkčnom prostredí, a neprodukčných prostrediach (napr. testovacie prostredie). Monitoringové udalosti budú v reálnom čase doručované do existujúcich monitoringových nástrojov verejného obstarávateľa.  Monitoring pokrýva minimálne tieto oblasti:

• bezpečnostný monitoring,
• aplikačný monitoring,
• infraštruktúrny monitoring,
• reporting zraniteľností,
• výkonnostný / kapacitný monitoring,
• monitorovanie dostupnosti a odozvy,
• monitorovanie dostupnosti a odozvy HW,
• monitorovanie kapacity dostupných zdrojov,
• monitorovanie kapacity dostupných HW zdrojov,
• monitorovanie diskových subsystémov,
• monitorovanie vyťaženia operačnej pamäte a CPU,
• monitorovanie výkonnosti sieťových subsystémov,
• monitorovanie prírastkov databáz a transakčných logov,
• monitorovanie indexov a konzistencie databáz,
• kontrola vykonávania pravidelných backupov,
• monitorovanie prevádzkových udalostí
• kontrola integrity kritických systémových súborov.
  1. Požiadavky služby systémovej podpory na požiadanie (nad paušál) 

Prevádzkové činnosti, ktoré budú poskytované nad rámec služieb v rámci systémovej a aplikačnej podpory (SLA):

• Riešenie systémových a prevádzkových chýb súvisiacich s potrebou funkčnej úpravy nastavených procesov;
• Školenia garantov a používateľov;
• Poskytovanie služieb odborných a technických konzultácii nad rámec činností uvedených v rámci SLA (tento dokument) v kapitole 1.1.1;
• Ďalšie činnosti a služby aplikačnej podpory súvisiace so zabezpečením prevádzky systému;
• Aktualizácia používateľskej a technickej dokumentácie po každej zmene systému;
  1. Požiadavky služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

Činnosti súvisiace s rozvojom systému. Tieto činnosti zahŕňajú implementáciu schválených požiadaviek používateľov na zmenu funkčnosti systému najmä:

• Rozširovanie funkcionality systému - Analýza, návrh a vývoj rozšírenia, vylepšenia a/alebo modifikácie aplikačného softvéru, na základe metodických a/alebo legislatívnych zmien; 
• Vykonanie úprav v nastavení modulov systému voči implementovanej funkčnosti a existujúcim nastaveniam;
• Programovanie nových funkcií v rámci existujúcich modulov systému;
• Vykonávanie úprav do existujúcich integračných rozhraní;
• Programovanie a implementácia nových integračných rozhraní;
• Realizácia testov podľa testovacích scenárov;
• Projektové riadenie zmien v zmysle Vyhlášky MIRRI SR č. 401/2023 z 9. októbra 2023 o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy;
• Aktualizácia používateľskej a technickej dokumentácie po každej zmene systému.

Zmena funkčnosti zahŕňa pridanie, modifikáciu alebo zrušenie akejkoľvek časti systému a súvisiacej dokumentácie. Zmena funkčnosti môže byť vyvolaná legislatívnou požiadavkou a/alebo požiadavkou používateľov na zlepšenie existujúcej funkcionality alebo zavedenie novej funkcionality v novom riešení CPK.

1. Požiadavky na personál

Podrobne uvedené v Projektovom zámere.

1. Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu budú realizované 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í.

1. Prílohy

N/A