I-03 Prístup k projektu (pristup_k_projektu)

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.

35

36

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.

37

38

= 2. 1 Použité skratky a pojmy =

39

40

|Skratka|Popis

41

|**AFPM**|Autorizácia funkciou prístupového miesta (historicky používané označenie "Klik")

42

|**API**|Application programming interface [Angl.], Aplikačné programovacie rozhranie

43

|**ASiC**|Associated signature containers [Angl.], Pridružené podpisové kontajnery

44

|**BOK**|Bezpečnostný osobný kód

45

|**CAdES**|CMS advanced electronic signatures [Angl.], sada rozšírení podpísaných údajov syntaxe kryptografických správ

46

|**CAMP**|Centrálna API manažment platforma

47

|**CEP**|Centrálna elektronická podateľňa

48

|**CPK **|Centrálny podpisový komponent

49

|**DTBS/R**|Data to be signed representation [Angl.], hash dokumentu

50

|**eDoPP**|Elektronický doklad o povolení pobytu

51

|**eID**|Elektronický občiansky preukaz

52

|**eIDAS**|Electronic IDentification, authentication and trust services [Angl.], Európsky štandard pre elektronickú komunikáciu

53

|**ESI**|Electronic signatures and infrastructures [Angl.], Elektronické podpisy a infraštruktúry

54

|**FO**|Fyzická osoba

55

|**G2G**|Government to government [Angl.], komunikácia verejnej správy medzi sebou pomocou middleware platformy

56

|**GUI**|Graphical user interface [Angl.], grafické užívateľské rozhranie

57

|**HSM**|Hardware security module [Angl.], špecializované hardvérové zariadenia, ktoré využívajú silné fyzické a logické bezpečnostné techniky na ochranu dôležitých kľúčov pred nezákonným prístupom a zmenami.

58

|**IAM**|Identity access management [Angl.], zabezpečenie centrálnej správy identít, autentifikačných údajov a autorizácií

59

|**IS**|Informačný systém

60

|**ISVS**|Informačný systém verejnej správy

61

|**KCCKB**|Kompetenčné a certifikačné centrum kybernetickej bezpečnosti

62

|**KEP**|Kvalifikovaný elektronický podpis

63

|**META IS**|Centrálny metainformačný systém verejnej správy

64

|**MVP**|Minimum viable product [Angl.], produkt v minimálnom použiteľnom hu

65

| |

66

|**NFC**|Near field communication [Angl.], technológia na bezpečnú a rýchlu bezdrôtovú komunikáciu do vzdialenosti 4 cm.

67

|**OPZ**|Opis predmetu zákazky

68

|**OVM**|Orgán verejnej moci

69

|**PAdES**|PDF advanced electronic signatures [Angl.], PDF dokument vhodný pre zdokonalený elektronický podpis

70

|**PO**|Právnická osoba

71

|**PTK**|Prípravná trhová konzultácia

72

|**RPO**|Recovery Point Objective [Angl.], akceptovateľná doba od poslednej zálohy

73

|**RTO**|Recovery Time Objective [Angl.], cieľový čas obnovy business procesu

74

|**QA**|Quality assurance [Angl.], zabezpečenie/posúdenie kvality

75

|**QSCD**|Qualified signature creation device [Angl.], kvalifikované zariadenia na vyhotovenie elektronického podpisu

76

|**REST API**|Representational state transfer API, aplikačné programovacie rozhranie ktoré spĺňa obmedzenia architektonického štýlu REST

77

|**SDK**|Software development kit [Angl.], súbor nástrojov pre vývoj softvéru

78

|**SSO**|Single sign-on [Angl.], jednotné prihlásenie pre prihlásenie pomocou jedného ID do ktoréhokoľvek z niekoľkých súvisiacich, ale nezávislých softvérových systémov.

79

|**SW**|Software

80

|**ÚPVS **|Ústredný portál verejnej správy

81

|**WebSSO**|IAM služba Single Sign-On (SSO) - „jednotné prihlásenie sa“

82

|**XAdES**|XML advanced electronic signatures [Angl.], sada rozšírení odporúčania XML-DSig vhodná pre zaručené elektronické podpisy

83

|**ZEP**|Zaručený elektronický podpis

84

|**NASES**|Národná agentúra pre sieťové a elektronické služby

85

|**MIRRI SR**|Ministerstvo investícií, regionálneho rozvoja a informatizácie Slovenskej republiky

86

|**BOK**|Bezpečnostný osobný kód (šesťmiestny – slúži na identifikáciu uživateľa a prístup do schránky www.slovensko.sk)

87

|**KEP PIN**|Kvalifikovaný elektronický podpis – Personal Identification Number (šesťmiestny)

88

|**SKRATKA/POJEM**|POPIS

89

90

= 3. Popis navrhovaného riešenia =

91

92

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

93

94

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

95

96

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,

97

98

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

99

100

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.

101

102

103

Prax a skúsenosti pri vybavovaní životných situácii elektronicky v zmysle § 3 písm. q) zákona č. 95/2019 Z.z. o informačných technológiách vo verejnej správe a o zmene na doplnení niektorých zákonov v znení neskorších predpisov, (ďalej ako „zákon č. 95/2019“) prostredníctvom občanov ukazujú, že z pohľadu používateľa je podpisovanie podaní najnáročnejšou činnosťou pri vytváraní podania, a to na portáli slovensko.sk a na špecializovaných portáloch v zmysle § 5 ods. 3 zákona č. 305/2013 Z.z. o elektronickej podobe výkonu pôsobnosti OVM a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej ako „zákon č. 305/2013 o e-Governmente“), ktoré majú implementovaný mechanizmus podpisovania prostredníctvom podpisových aplikácií (poskytovaných na stiahnutie na ÚPVS), a to najmä z dôvodu komplikovanej inštalácie komponentov určených na podpisovanie, obmedzenia prehliadačov pri inicializácii podpisovej aplikácie z webového prehliadača ako aj nutnosti poznať viaceré unikátne identifikátory ako je BOK či KEP PIN. Pri vytváraní podania je najviac neúspešných krokov z dôvodu zlyhania podpisovania.

104

105

Alternatívou, ktorá by zabezpečila jednotné, jednoduché, intuitívne a komfortné používateľské prostredie, v ktorom sa bude podpisovanie realizovať, je implementácia spoločného modulu, t. j. Centrálny podpisový komponent (CPK), v rámci jeho poskytovania sú viaceré možností vyhotovenia KEP aj bez nutnosti použitia čítačky čipových kariet, a to s pomocou mobilných zariadení (s možnosťou autorizácie s využitím eID 2.0), ako aj zjednodušenej formy autorizácie (autorizácia funkciou prístupového miesta), ktorá zabezpečí rýchlejší a používateľsky komfortnejší spôsob podpisovania vybraných úkonov a služieb nevyžadujúcich autorizáciu na úrovni KEP, a to aj bez nutnosti inštalovania osobitného SW t.j. lokálnej podpisovej aplikácie, či poznania unikátnych identifikátorov ako napr. KEP PIN (v prípade autorizácie cez AFPM).

106

107

Riešenie bude slúžiť pre všetky komunikačné kanály a prístupové miesta ako napríklad Slovensko v mobile, ÚPVS, špecializované portály, ISVS a pod. a zároveň bude umožňovať využívanie nielen pre verejný, ale aj komerčný sektor, tretie strany. Verejný obstarávateľ v prílohe č. 10 „Katalóg požiadaviek“ uvádza služby, ktoré požaduje dodať v rámci tohto predmetu zákazky.

108

109

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

110

111

* Úprava alebo implementácia konštruktora podania (vypĺňacej funkcie formulára podania)

112

* 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

113

* 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

114

115

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

116

117

== 3.1 Rozsah navrhovaného riešenia z pohľadu VO ==

118

119

V rámci CPK verejný obstarávateľ požaduje dodávku hlavných funkcií, ktoré sú predmetom zákazky:

120

121

**Centrálny podpisový komponent**

122

123

* **implementácia CPK**, ktorá umožní výber lokálnej podpisovej aplikácie na desktope cez jednotné rozhrania a integračné komponenty (knižnice) CPK, podpisovanie kvalifikovaným a zdokonaleným elektronickým podpisom ako aj kvalifikovanou elektronickou pečaťou. CPK musí vedieť do KEP aj Kvalifikovanej elektronickej pečate zahrnúť kvalifikovanú elektronickú časovú pečiatku. CPK má podporovať aj možnosť viacnásobného podpisovania, ale riadenie viacnásobného podpisovania podľa požiadaviek koncovej služby (napr. kto autorizuje a v akom poradí) bude realizované funkcionalitou konštruktora správ mimo CPK. Zároveň má podporovať vytvorenie elektronického podpisu odosielaného elektronického dokumentu, ktorý predstavuje vytváranie kvalifikovaných pečatí pracovníkom OVM cez používateľské rozhranie v zmysle § 23 ods. 1 zákona č. 305/2013 Z.z. o e-Governmente - náhrada alebo prepoužitie (integrácia) jestvujúcej funkcionality CEP (Modul centrálnej elektronickej podateľne, aplikačná služba METAIS kód=sluzba_is_1370).

124

125

* **Plug-in do web prehliadača,** CPK poskytne integrácie, prostredníctvom ktorých bude možné po zaradení do META IS a prejavení vôle dodávateľov podpisových aplikácií jednoducho pridať aplikácie ďalších dodávateľov služieb spojených s podpisovaním. Plug-in umožní pre lokálne podpisové aplikácie registráciu pri inštalácii, štart aplikácie, odovzdanie objektu na podpis a prebratie podpísaného objektu.

126

127

**Implementácia autorizácie funkciou prístupového miesta **(AFPM, tiež používané označenie "Klik"), ktorá predstavuje autorizáciu  v zmysle § 23 ods. 1 písm. a) bod 2 zákona č. 305/2013 Z.z. o e-Governmente. Jej funkčnosť bude zabezpečovať nový požadovaný komponent AFPM.

128

129

**Implementácia autorizácie prostredníctvom eID 2.0 a eDoPP 2.0 (NFC KEP), ktorá predstavuje autorizáciu v zmysle § 23 ods. 1 písm. a) bod 1 zákona č.305/2013 Z.z. o e-Governmente. **

130

131

132

== 3.2 FÁZY DODANIA DIELA ==

133

134

Verejný obstarávateľ požaduje dodanie diela, jeho nasadenie na produkčné prostredie a realizáciu v jednej fáze (1. release) s predpokladaným termínom dodania a nasadenia do 10 mesiacov odo dňa nadobudnutia účinnosti Zmluvy o dielo.

135

136

Nižšie uvedené výstupy predmetu zákazky sú detailne popísané v rozsahu požiadaviek, ktoré tvoria neoddeliteľnú súčasť tohto OPZ.

137

138

Verejný obstarávateľ požaduje nasledovný rozsah v rámci jednej fázy (1. Release):

139

140

* Implementácia a produkčné nasadenie aplikačných komponentov CPK,

141

142

* Sprístupnenie API CPK na CAMP,

143

144

* Poskytnutie súčinnosti pri integrácii služieb CPK do konštruktora správ na ÚPVS,

145

146

* Podpísanie súboru v CPK bez možnosti prihlásenia,

147

148

* Viacnásobné podpísanie dokumentu bez nutnosti prihlásenia,

149

150

* 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í,

151

152

* Integrácia na IAM a UPVS za účelom využitia štátom garantovanej identity na prihlásenie do CPK pomocou WebSSO,

153

154

* Vytvorenie náhľadu na podpisovanie dát podľa vizualizačných schém pre formulár a podpisované súbory,

155

156

* Overenie povolených možností autorizácie evidovaných pre danú službu v MetaIS,

157

158

* Návrh dátovej štruktúry pre AFPM a vloženie príslušného formulára do MEF,

159

160

* Vytvorenie autorizácie prostredníctvom funkcie prístupového miesta a jej implementácia v CPK,

161

162

* Implementácia overovania auditných záznamov v CPK,

163

164

* 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),

165

166

* 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/>>url:https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2023/401/]]).

167

168

* Komponent “Autorizácia prostredníctvom eID 2.0” a jeho integrácia do CPK

169

170

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

171

172

*  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,

173

174

* Súčasťou komponentu je SDK pre mobilné zariadenia umožňujúce vytvorenie bezpečného komunikačného kanálu a relácie medzi CPK a mobilnou aplikáciou na výmenu dát na podpis.

175

176

* Viacnásobná autorizácia funkciou prístupového miesta

177

178

*  Podpis viacerými osobami funkciou prístupového miesta (viac oprávnených osôb podpisuje jedno podanie v korektnom poradí).

179

180

* Pri viacnásobnej autorizácii AFMP sa použije štruktúra dohodnutá na pracovných skupinách.

181

182

* 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).

183

184

* Overenie podpisov na podaní a prílohách.

185

186

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

187

188

* Vytvorenie MessageDigest - digitálny odtlačok dát určených na podpisovanie.

189

190

* Pripájanie časovej pečiatky (k dokumentu a/alebo k podpisu).

191

192

Verejný obstarávateľ uvádza súvisiace súčasti k riešeniu CPK, ktoré nie sú predmetom zákazky podľa tohto zadania, ale nakoľko musí byť zabezpečená kompatibilita medzi dodávaným riešením v jednej fáze uvedenej vyššie a súčasne s nižšie uvedenými bodmi:

193

194

* Úprava alebo implementácia konštruktora podania (vypĺňacej funkcie formulára podania),

195

196

* 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,

197

198

* 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

199

200

* Nasadenie inkrementu 4 aplikácie Slovensko v mobile, ktorý nám zabezpečí novú verziu eID frameworku SDK na komunikáciu s NFC čipom.

201

202

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

203

204

205

= 4. Architektúra riešenia projektu =

206

207

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.

208

209

[[image:1760011396743-116.png]]

210

211

212

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

213

214

215

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

216

217

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

218

219

//Podporované nepodpísané súbory~://

220

221

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

222

223

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

224

225

* //.pdf .xml .asics .scs .asice .sce .p7m//

226

227

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

228

229

* //.zep .zepx .xzep//

230

231

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

232

233

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.

234

235

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>>url:https://www.slovensko.sk/sk/institucie-formulare-a-ziado/spolocna-autorizacia-ovm]] 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.

236

237

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

238

239

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.

240

241

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

* XAdES

* PAdES

* CAdES

* JAdES

* ASiC

* a do budúcna ďalšie ktoré budú definované v rámci novely eIDAS a nie sú momentálne uvedené

249

250

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.

251

252

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.

253

254

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í.**

255

256

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

257

258

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

259

260

== 4.1 Predpoklady realizácie projektu rozvoja ==

261

262

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

263

264

265

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.

266

1. Používateľ je oprávnený v zmysle prístupu k službám.

267

1. Používateľ úspešne vytvorí elektronické podanie.

268

1. ISVS OVM využívajúci služby CPK je integrovaný s ÚPVS.

269

1. Pre niektoré spôsoby podpisovania je nutné mať aktivovanú mobilnú aplikáciu, ktorá nie je predmetom zákazky.

270

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

271

272

[[image:1760011440620-379.png]]

273

274

275

== 4.2 Biznis vrstva a aplikačná architektúra ==

276

277

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

278

279

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

280

281

CPK pracuje v štyroch krokoch :

282

283

1. prijme objekt alebo objekty na autorizáciu a kontext podpisu (identifikácia služby, povinné osoby, spôsob autorizácie)

284

1. zvolí spôsob autorizácie a vyberie vhodný certifikát podľa konfigurácie služby v MetaIS

285

1. zabezpečí vytvorenie podpísaného objektu buď vlastnou funkcionalitou, alebo pomocou vystavených služieb lokálnej podpisovej aplikácie

286

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

287

288

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

289

290

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

291

292

* 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

293

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

294

* Autorizácia prostredníctvom KEP na mobile pomocou eID 2.0 alebo eDoPP a NFC.

295

* Autorizácia OVM - vytvorenie elektronického podpisu/elektronickej pečate odosielaného elektronického dokumentu (rozhodnutia).

296

297

[[image:1758714093952-136.png]]

298

299

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

300

301

302

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.

303

304

=== 4.2.1 Proces autorizácie podania – všeobecne ===

305

306

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

307

308

1. Aktivácia CPK, počas ktorého konštruktor správ doručí do CPK

309

11. objekt na autorizáciu, alebo odkaz na ich umiestnenie v úložisku,

310

11. kontext autorizácie, čiže dodatočné informácie o koncovej službe (identifikácia služby, povinné osoby, spôsob autorizácie)

311

1. Výber z povolených spôsobov autorizácie na základe údajov z Meta IS

312

1. V prípade autorizácie (vytvorenia el. podpisu) lokálnou podpisovou aplikáciou:

313

11. Overenie dostupnosti podpisovej aplikácie (overenie, že aplikácia je nainštalovaná a pripravená na komunikáciu s CPK),

314

11. Výmena informácií o poskytovaných službách podpisovej aplikácie (napr. poskytovaná služba vizualizácie, overenia certifikátov atď.),

315

11. Inicializácia podpisovacieho procesu v podpisovej aplikácií.

316

1. Výber poskytovateľa a certifikátu

317

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

318

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

319

1. Overenie či prihlásená osoba je oprávnená vytvoriť podpis:

320

11. V prípade AFPM opätovným prihlásením,

321

11. V ostatných prípadoch zadaním BOK a PIN k QSCD.

322

1. Vytvorenie MessageDigest - digitálny odtlačok dát určených na podpis.

323

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

324

1. Vytvorenie autorizovaného objektu podľa zvoleného spôsobu autorizácie:

325

11. Napríklad podpisového kontajnera vo formáte ASiC, alebo

326

11. Vytvorenie a odoslanie Sk-Talk správy v prípade AFPM.

327

1. Vrátenie výsledku autorizácie do komponentu, ktorý inicioval autorizáciu (napr. konštruktor podaní, konštruktor správ).

328

1. Vrátenie riadenie konštruktoru s informáciou o výsledku autorizácie a/alebo odoslania.

329

330

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.

338

339

340

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.

341

342

343

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

344

345

346

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.

347

348

349

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.

350

351

352

== 4.2.2 Spôsoby autorizácie ==

353

354

**4.2.2.1 Autorizácia podania elektronickým podpisom používateľa pomocou eID alebo eDoPP**

355

356

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

357

358

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.

359

360

**4.2.2.2 Autorizácia funkciou prístupového miesta (AFPM)**

361

362

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

363

364

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.

365

366

367

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

368

369

* Volanie Služby CPK vykonal systém s príslušným oprávnením,

370

* Zhoda SenderId / SubjectId - autentifikovaná osoba je zhodná s odosielateľom správy,

371

* Minimálny QAA Level 3 / Level of Assurance prihlásenia používateľa,

372

* Opätovné prihlásenie pred odoslaním podania sa bude kontrolovať vekom tokenu,

373

* Validácia nakonfigurovaných akceptovaných autorizačných prostriedkov pre službu a formulár v MetaIS (kód služby v METAIS),

374

* Kontrola zastupovania v prípade PO.

375

376

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:

377

378

|**ID**|**Krok**|**Realizátor**

379

|1.|Používateľ vyplní podanie|Konštruktor

380

|2.|Používateľ sa rozhodne autorizovať|Konštruktor

381

|3.|Aktivácia CPK, CPK preberie dokumenty a kontext|CPK

382

|4.|Používateľ vyberie AFPM|CPK

383

|5.|Zobrazenie náhľadu podania s odkazom na prílohy.|CPK

384

|5.1|Zobrazenie upozornenia, že používateľ si vybral AFPM, bude vyzvaný na opätovné prihlásenie a že autorizáciou bude podanie aj odoslané.|CPK

385

|6.|Používateľ klikne na „Autorizovať a odoslať”|CPK

386

|7.|Používateľ sa autentifikuje minimálne na úrovni „pokročilá“ (pomocou eID alebo mID)|CPK

387

|8.|CPK overí autentifikáciu, identitu odosielateľa a zastupovanie|CPK

388

|8.1|CPK vytvorí pečate CPK/MIRRI pre každý objekt ktorý nebol podpísaný|CPK

389

|8.2|CPK vytvorí autorizačnú informáciu, ktorú tiež zapečatí pečaťou CPK/MIRRI|CPK

390

|8.3|CPK vytvorí a odošle Sk-Talk správu do schránky adresáta v eDesk s rolou, ktorá mu umožní odoslať do G2G a odoslané podanie vloží do priečinka odoslaných správ prihláseného používateľa (SaveApplicationToOutbox)|CPK

391

|9|CPK odošle informáciu o realizácii autorizácie AFPM|CPK

392

393

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

394

395

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.

396

397

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.

398

399

400

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

401

402

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

403

404

Predpokladom pre tento scenár podpisovania:

405

406

* Aktivovaná mobilná aplikácia previazaná s konkrétnou identitou z IAM modulu,

407

* Podania, dokumenty, prílohy budú ukladané do momentu odoslania na dočasnom úložisku podporujúcom S3 protokol,

408

* V momente úspešnej autorizácie budú súbory z dočasného úložiska odstránené.

409

410

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.

411

412

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:

413

414

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

415

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

416

* Vytvorenie bezpečného komunikačného kanálu a relácie medzi CPK a mobilnou aplikáciou.

417

** Komunikačný kanál musí byť implementovaný v súlade s Normami **ETSI TS 119 101** a **ETSI TS 119 102,**

418

** Mobilná aplikácia musí čítať URL uvedené v Push notifikácii a QR kóde a následne komunikovať s poskytnutými URL.

419

* Verifikácia platnosti podpisového certifikátu. Vykonávať sa bude na backende CPK.

420

* Konverzia dokumentu do štandardizovaného formátu. Vykonávať sa bude na backende CPK.

421

* Vytvorenie podpisu (zašifrovanie dát na podpis) v mobilnej aplikácii pomocou eID frameworku.

422

* Vloženie podpisu do dokumentu. Vykonávať sa bude na backende CPK.

423

* Získanie časovej pečiatky z CEP Vloženie časovej pečiatky volaním komponentu CEP, služby „

424

425

**4.2.2.4 Autorizácia OVM**

426

427

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

428

429

* 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).

430

* 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>>url:https://upvi.sharepoint.com/sites/SITVS_dokumenty/OREG_Dokumenty/01_Centrálna_dátová_kancelária/NKIVS_Audit_SITVS%20(External)/CPK/Projektová%20dokumentácia%20pripravená/Príloha%20č.%201%20Opis%20predmetu%20zákazky.docx#_Autorizácia_podania_elektronickým]] alebo kapitoly [[4.4.4 Autorizácia eID 2.0 alebo eDoPP 2.0 s NFC rozhraním (podpisovanie na mobile)>>url:https://upvi.sharepoint.com/sites/SITVS_dokumenty/OREG_Dokumenty/01_Centrálna_dátová_kancelária/NKIVS_Audit_SITVS%20(External)/CPK/Projektová%20dokumentácia%20pripravená/Príloha%20č.%201%20Opis%20predmetu%20zákazky.docx#_Autorizácia_eID_2.0]] tohto dokumentu.

431

432

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.>>url:https://kp.gov.sk/pf/_layouts/PFSharePointProject/Login.aspx?ReturnUrl=%2fpf%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252Fpf%252Fzdielane%255Fdokumenty%252FIntegr%25C3%25A1cia%2520na%2520UPVS%252F03%255FIntegra%25C4%258Dn%25C3%25A9%2520manu%25C3%25A1ly%252FCEP%252FUPG%252D1%252D1%252DIntegracny%255Fmanual%255FUPVS%255FCEP%2520v3%255F8%255F3%252Edocx&Source=%2Fpf%2Fzdielane%5Fdokumenty%2FIntegr%C3%A1cia%20na%20UPVS%2F03%5FIntegra%C4%8Dn%C3%A9%20manu%C3%A1ly%2FCEP%2FUPG%2D1%2D1%2DIntegracny%5Fmanual%5FUPVS%5FCEP%20v3%5F8%5F3%2Edocx]] 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>>mailto:integracie@nases.gov.sk]], alebo využiť oficiálny kontakt uvedený vo verejnom obstarávaní.

433

434

435

=== 4.2.3 Overovanie podpisov ===

436

437

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

438

439

440

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

441

442

443

=== 4.2.4 Odstránenie podpisov na nepodanom podaní - Odobratie podpisu ===

444

445

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

446

447

448

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

449

450

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.

|(((

Kód KS

//(z MetaIS)//

)))|Názov KS|Používateľ KS //(G2C/G2B/G2G/G2A)//|(((

Životná situácia

//(+ kód z MetaIS)//

)))|Úroveň elektronizácie KS

;[[image:1758714262218-833.png]]

466

467

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

468

469

470

=== 4.3.1 Jazyková podpora a lokalizácia ===

471

472

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

473

474

475

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

476

477

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

478

479

|**Kód ISVS **//(z MetaIS)//|**Názov ISVS**|(((

480

**Modul ISVS**

481

482

//(zaškrtnite ak ISVS je modulom)//

)))|(((

**Stav IS VS**

(AS IS)

)))|**Typ IS VS**|(((

488

**Kód nadradeného ISVS**

489

490

//(v prípade zaškrtnutého checkboxu pre modul ISVS)//

)))

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

496

497

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

498

499

|**Kód ISVS **//(z MetaIS)//|**Názov ISVS**|(((

500

**Modul ISVS**

501

502

//(zaškrtnite ak ISVS je modulom)//

503

)))|**Stav IS VS**|**Typ IS VS**|(((

504

**Kód nadradeného ISVS**

505

506

//(v prípade zaškrtnutého checkboxu pre modul ISVS)//

)))

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

513

514

|Kód IS|Názov ISVS|Spoločné moduly podľa zákona č. 305/2013 e-Governmente

515

| | |//Vyberte jednu z možností.//

516

| | |//Vyberte jednu z možností.//

517

| | |//Vyberte jednu z možností.//

518

519

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

520

521

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

522

523

|Kód IS|Názov ISVS|Spoločné moduly podľa zákona č. 305/2013 e-Governmente

524

|isvs_14363|Centrálny Podpisový Komponent|//Modul elektronického doručovania//

525

|isvs_14363|Centrálny Podpisový Komponent|//Autentifikačný modul//

526

|isvs_14363|Centrálny Podpisový Komponent|//Modul elektronických schránok//

527

|isvs_14363|Centrálny Podpisový Komponent|//Modulu elektronických formulárov//

528

|isvs_14363|Centrálny Podpisový Komponent|//Notifikačný modul//

529

|isvs_14363|Centrálny Podpisový Komponent|//Modul centrálnej elektronickej podateľne//

530

|isvs_14363|Centrálny Podpisový Komponent|//Centrálna API Manažment Platforma//

531

|isvs_14363|Centrálny Podpisový Komponent|//Slovensko v mobile//

532

|isvs_14363|Centrálny Podpisový Komponent|//METAIS/ Lokator//

533

534

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

535

536

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

|(((

Kód ISVS

//(z MetaIS)//

)))|(((

Názov ISVS

)))|(((

Kód integrovaného ISVS

548

549

//(z MetaIS)//

550

)))|Názov integrovaného ISVS

551

|isvs_14363|Centrálny Podpisový Komponent|//N/A//|//SNCA - Overovanie certifikátov, časová pečiatka//

552

|isvs_14363|Centrálny Podpisový Komponent|//N/A//|//Lokálne podpisové aplikácie -rozlične štartovanie v Rel1 a Rel2//

553

| | | |

554

555

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

556

557

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

|(((

Kód AS

//(z MetaIS)//

)))|Názov AS|(((

ISVS/modul ISVS

//(kód z MetaIS)//

)))|(((

Aplikačná služba realizuje KS

570

571

//(kód KS z MetaIS)//

572

)))

573

|as_65708|Získanie informácie o koncovej službe|isvs_14363|

574

|as_65710|Získanie poskytovateľov podpisových služieb|isvs_14363|

575

|as_65709|Získanie informácie o poskytovateľovi podpisových služieb|isvs_14363|

576

|as_65711|Vytvorenie elektronického podpisu|isvs_14363|ks_37950

577

|as_65712|Vytvorenie podpisu funkciou autorizácie prístupovým miestom (AFPM)|isvs_14363|

578

|as_65713|Stiahnutie podpísaného objektu|isvs_14363|

579

|as_65733|Pridanie poskytovateľa autorizačných služieb|isvs_14363|

580

|as_65728|Zmena poskytovateľa autorizačných služieb|isvs_14363|

581

|as_65729|Odstránenie podpisov na objekte – zrušenie podpisov|isvs_14363|

582

|as_65730|Kontrola podpisov na objekte|isvs_14363|ks_37950

583

|as_65731|Vytvorenie podpisu nahratého súboru|isvs_14363|ks_37950

584

|as_65732|Vytvorenie viacnásobného podpisu|isvs_14363|ks_37950

585

|as_66521|Využitie Spoločných modulov UPVS|isvs_14363|

586

587

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

588

589

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

|(((

AS

(Kód MetaIS)

)))|(((

Názov AS

)))|(((

Realizuje ISVS

(kód MetaIS)

Integrácia na AS poskytovateľa

(kód MetaIS)

)))

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

614

615

Z ISVS nebudú poskytované údaje do IS CSRU

616

617

618

|ID OE|Názov (poskytovaného) objektu evidencie|Kód ISVS poskytujúceho OE|Názov ISVS poskytujúceho OE

| | | |

| | | |

| | | |

=== 4.3.10 Konzumovanie údajov z IS CSRU – TO BE ===

624

625

ISVS nebude konzumovať údaje z IS CSRU

|ID OE|(((

Názov (konzumovaného) objektu evidencie

632

)))|Kód a názov ISVS konzumujúceho OE z IS CSRÚ|Kód zdrojového ISVS v MetaIS

| | | |

| | | |

| | | |

=== 4.4 Dátová vrstva ===

638

639

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.

640

641

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

642

643

Š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.)

644

645

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.

646

647

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.

648

649

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.

650

651

| **Názov elementu**|**Typ**|**Kardinalita**|**Popis**

652

|AuthorizationInfo|Zložený typ|1|Štruktúra vkladaná do Sk-Talk pre identifikáciu typu autorizácie a súvisiacich údajov

653

|Authorization|Zložený typ|1..n|Obsahuje údaje o jednej autorizácii. Umožňuje viacnásobný výskyt pre každý autorizovaný dokument v správe.

654

|AuthorizedObjectId|Text|1|Identifikátor objektu v správe - v MessageContainer.

655

|AuthorizationType|Zložený typ|1|Typ autorizácie - povinný údaj. Číselníková hodnota podľa číselníka v METAIS Do budúcna môžu pribúdať rôzne ďalšie formy autorizácie.

656

Poznámka: V prípade autorizácie s KEP / AdES-QC sa nevypĺňa, nakoľko v takom prípade sa zohľadňuje atribút IsSigned pre daný objekt, z čoho vyplýva, že sa daný objekt má spracovať v elektronickej podateľni ako štandardný formát podpisu s kvalifikovaným certifikátom.

657

|CodelistCode| | |Použitý spôsob autorizácie (CL009011 - Základný číselník spôsobov autorizácie v METAIS)

658

|CodelistItem|Zložený typ|1|Položka číselníka

659

|ItemCode|Text|1|Kód položky

660

|ItemName|Text|1|Slovný názov typu autorizácie

661

|AuthorizationDateTime|DateTime|1|Dátum a čas autorizácie. Povinný udaj.

662

|SystemId|Text|0..1|Identifikácia informačného systému, pomocou ktorého bola vykonaná autorizácia (primárne by mal byť použitý kód ISVS podľa METAIS). Povinný v závislosti od typu autorizácie. V prípade autorizácie odoslaním podania po opakovanej autentifikácii sa uvádza povinne.

663

|AuthorizedBy|Zložený typ|1|Identifikačné údaje osoby, ktorá autorizovala dokument. V prípade autorizácie vo vlastnom mene sa v položkách ActorId a SubjectId uvádza rovnaká hodnota. V prípade autorizácie odoslaním podania s opakovanou autentifikáciou v zastúpení sa uvádza údaj o zastupujúcej osobe v ActorId aj o zastúpenej osobe v SubjectId.

664

|Actor|Zložený typ|1|

665

|ActorID|Text| |

666

|Actor.FormattedName|Text| |

667

|Actor.IssuerForeignerID|Text| |Kód krajiny vydávajúcej identifikátor osoby

668

|Delegation|Číslo| |Typ zastupovania – používa sa najmä zákonné zastupovanie, potrebné pre spracovanie niektorých typov žiadostí (napr. § 16 ods. 6 zákona eGov).

669

|DelegationMediatorID|Text| |ID zastupovania (atribút uvádzaný v SAML tokene prihlásenej a autorizujúcej osoby)

670

|Subject|Zložený typ|1|

671

|SubjectID|Text| |

672

|Subject.FormattedName|Text| |

673

|AuthorizationDocument|Zložený typ|1..n|Povinný min. 1 súbor preukazujúci vykonanú autorizáciu - obsah elektronického podpisu (pečate) autorizovaného dokumentu. V ďalšom preukazujúcom dokumente môže byť poskytnutý ďalší dôkaz, napr. záznam v LogFile

674

|Type|Text|1|Typ preukazujúceho súboru (vymenované hodnoty): Signature (preferovaný typ), LogFilerecord

675

|Document|Text|1|Hodnota preukazujúceho dokumentu zakódovaná do base64 (pre preferovaný typ Signature bude preukazujúcim dokumentom META-INF\*signature*.* z ASIC kontajnera alebo export podpisu z PDF dokumentu vo formáte PADES príslušného autorizovaného objektu.)

676

677

=== 4.4.1 Údaje v správe organizácie ===

Uvedené vyššie

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

Uvedené vyššie

=== 4.4.3 Referenčné údaje ===

688

689

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

690

691

692

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

Irelevantné

|**ID OE**|(((

**Názov referenčného registra /objektu evidencie**

699

700

//(uvádzať OE z tabuľky v kap. 4.3.2)//

701

)))|**Názov referenčného údaja **(atribúty)|**Identifikácia subjektu, ku ktorému sa viaže referenčný údaj**|**Zdrojový register a registrátor zdrojového registra**

| | | | |

| | | | |

| | | | |

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

Irelevantné

|ID OE|(((

Názov referenčného údaja /objektu evidencie

713

714

//(uvádzať OE z tabuľky v kap. 4.3.2)//

715

)))|Konzumovanie / poskytovanie|Osobitný právny predpis pre poskytovanie / konzumovanie údajov

716

| | |Vyberte jednu z možností.|

717

| | |Vyberte jednu z možností.|

718

| | |Vyberte jednu z možností.|

719

720

=== 4.4.4 Kvalita a čistenie údajov ===

721

722

Irelevantné pre projekt

723

724

**4.4.4.1 Zhodnotenie objektov evidencie z pohľadu dátovej kvality**

725

726

Irelevantné pre projekt

|ID OE|(((

Názov Objektu evidencie

731

732

//(uvádzať OE z tabuľky v kap. 4.3.2)//

)))|(((

Významnosť kvality

//1 (malá) až 5 (veľmi významná)//

)))|(((

Citlivosť kvality

//1 (malá) až 5 (veľmi významná)//

741

)))|(((

742

Priorita //– poradie dôležitosti//

743

744

//(začnite číslovať od najdôležitejšieho)//

)))

| | | | |

| | | | |

| | | | |

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

751

752

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

753

754

755

|Rola|Činnosti|Pozícia zodpovedná za danú činnosť (správca ISVS / dodávateľ)

756

|**Dátový kurátor**|Evidencia požiadaviek na dátovú kvalitu, monitoring a riadenie procesu|Dátový kurátor správcu IS

757

|**Data steward**|Čistenie a stotožňovanie voči referenčným údajom|Pracovník IT podpory

758

|**Databázový špecialista**|Analyzuje požiadavky na dáta, modeluje obsah procedúr|Dodávateľ

759

|**Dátový špecialista pre dátovú kvalitu**|Spracovanie výstupov merania, interpretácie, zápis biznis pravidiel, hodnotiace správy z merania|Dátový špecialista pre dátovú kvalitu – nová interná pozícia v projekte

760

|***Iná rola (doplniť)**| |

761

762

=== 4.4.5 Otvorené údaje ===

763

764

Irelevantné pre projekt

|(((

Názov objektu evidencie / datasetu

769

770

//(uvádzať OE z tabuľky v kap. 4.3.2)//

)))|(((

Požadovaná interoperabilita

(//3★ - 5★)//

)))|(((

Periodicita publikovania

779

780

//(týždenne, mesačne, polročne, ročne)//

781

)))

782

| |Vyberte jednu z možností.|Vyberte jednu z možností.

783

| |Vyberte jednu z možností.|Vyberte jednu z možností.

784

| |Vyberte jednu z možností.|Vyberte jednu z možností.

785

| |Vyberte jednu z možností.|Vyberte jednu z možností.

786

| |Vyberte jednu z možností.|Vyberte jednu z možností.

787

| |Vyberte jednu z možností.|Vyberte jednu z možností.

788

789

=== 4.4.6 Analytické údaje ===

790

791

Irelevantné pre projekt

792

793

794

|ID|Názov objektu evidencie pre analytické účely|Zoznam atribútov objektu evidencie|Popis a špecifiká objektu evidencie

795

| |//napr. Dataset vlastníkov automobilov//|//identifikátor vlastníka; EČV; typ_vozidla; okres_evidencie;...//|//- dataset obsahuje osobné informácie (r.č. vlastníka)//

| | | |

| | | |

=== 4.4.7 Moje údaje ===

800

801

Irelevantné pre projekt

|ID|(((

Názov registra / objektu evidencie

806

807

//(uvádzať OE z tabuľky v kap. 4.3.2)//

808

)))|Atribút objektu evidencie|Popis a špecifiká objektu evidencie

| | | |

| | | |

| | | |

| | | |

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

815

816

Irelevantné pre projektu

|ID|(((

Register / Objekt evidencie

821

822

//(uvádzať OE z tabuľky v kap. 4.3.2)//

823

)))|Referenčné údaje|Moje údaje|Otvorené údaje|Analytické údaje

| | |☐|☐|☐|☐

| | |☐|☐|☐|☐

| | |☐|☐|☐|☐

| | |☐|☐|☐|☐

| | |☐|☐|☐|☐

| | |☐|☐|☐|☐

== 4.5 Technologická vrstva ==

832

833

=== 4.5.1 Prehľad technologického stavu - AS IS ===

N/A

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

839

840

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

841

842

|Parameter|Jednotky|Predpokladaná hodnota|Poznámka

843

|Počet interných používateľov|Počet|10 000|Pocet OVM krat pocet zodpo. Zamestnancov

844

\\4500 platných certifikátov

845

|Počet súčasne pracujúcich interných používateľov v špičkovom zaťažení|Počet|2000|20-25%

846

|Počet externých používateľov (internet)|Počet|5,000,000|Rádovo miliony

847

|Počet externých používateľov používajúcich systém v špičkovom zaťažení|Počet|10,000|10-40%

848

|Počet transakcií (podaní, požiadaviek) za obdobie|Počet/obdobie|500 000/ denne|štatistiky

849

|Objem údajov na transakciu|Objem/transakcia|1 MB|Štatistiky,

850

851

|Objem existujúcich kmeňových dát|Objem| |Vzhľadom k tomu, že sa jedná o technické riešenie, nie je potrebné uchovávať kmeňové dáta.

852

| | | |

853

854

=== 4.5.3 Návrh riešenia technologickej architektúry ===

855

856

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

857

858

859

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

860

861

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.

862

863

[[image:1758714307028-452.png]]

864

865

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

866

867

868

-obe ralizuju VM a na nich pobezi

869

~-~- K8S **PaaS **(Kubernetes Platform as a Service)

~-~- DB as **PaaS**

~-~- Storage **PaaS **(Storage as a Service)

874

875

876

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.

\\

|(((

Kód infraštruktúrnej služby

884

885

//(z MetaIS)//

886

)))|Názov infraštruktúrnej služby|(((

887

**Kód využívajúceho ISVS**

888

889

//(z MetaIS)//

890

)))|**Názov integrovaného ISVS**

891

|TBD|TBD|//CPK//|//TBD//

| | | |

| | | |

| | | |

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.

897

898

899

|(% rowspan="2" %)Prostredie|(% rowspan="2" %)(((

900

901

902

Kód infraštruktúrnej služby

903

904

//(z MetaIS)//

905

)))|(% rowspan="2" %)Názov infraštruktúrnej služby/ Služba z katalógu cloudových služieb pre zriadenie výpočtového uzla |(% colspan="4" %)Požadované kapacitné parametre služby

906

(doplňte stĺpec parametra, ak je dôležitý pre konkrétnu službu)

907

|Dátový priestor (GB)|Tier diskového priestoru|Počet vCPU|RAM (GB)

908

|Vývojové| |(((

909

**IaaS **PCA (Infrastructure as a Service - Private Cloud Appliance)

910

911

K8S **PaaS **(Kubernetes Platform as a Service)

DB as **PaaS**

Storage **PaaS **(Storage as a Service)

916

)))|100|Tier 2|2|4

917

|Testovacie| |(((

918

**IaaS **PCA (Infrastructure as a Service - Private Cloud Appliance)

919

8S **PaaS **(Kubernetes Platform as a Service)

DB as **PaaS**

Storage **PaaS **(Storage as a Service)

924

)))|100|Tier 2|2|4

925

|Produkčné| |(((

926

**IaaS **PCA (Infrastructure as a Service - Private Cloud Appliance)

927

8S **PaaS **(Kubernetes Platform as a Service)

DB as **PaaS**

Storage **PaaS **(Storage as a Service)

)))|300|Tier 1|16|36

|(((

ďalšie...

(uviesť názov)

)))| | | | | |

|Prostredie|Ďalšie služby potrebné na prevádzku projektu z katalógu služieb vládneho cloudu (stručný popis / názov)|(((

Kód služby

//(z MetaIS)//

)))|Parametre pre službu (doplňte stĺpec parametra, ak je dôležitý pre konkrétnu službu)

944

|Vývojové|(((

945

Backup as a Service (BaaS)

946

947

Monitoring as a Service (MaaS)

948

949

Azure Kubernetes Service (AKS)

)))|(((

infra_sluzba_229

infra_sluzba_230

infra_sluzba_635

)))|

|Testovacie|(((

Backup as a Service (BaaS) Monitoring as a Service (MaaS)

961

962

Azure Kubernetes Service (AKS)

)))|(((

infra_sluzba_229

infra_sluzba_230

infra_sluzba_635

)))|

|Produkčné|(((

Backup as a Service (BaaS) Monitoring as a Service (MaaS)

974

975

Azure Kubernetes Service (AKS)

)))|(((

infra_sluzba_229

infra_sluzba_230

infra_sluzba_635

)))|

|(((

ďalšie...

(uviesť názov)

)))| | |

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

992

993

[[Katalóg služieb Vládneho cloudu SR>>url:https://katalog.statneit.sk/index.php?s_ziadost_ID=&s_sl_typ_name=&s_uroven_Name=&s_ziadost_Nazov=Azure+Kubernetes+Service&s_ziadatel_Nazov=&s_ziadost_Zakladny_popis_sluzby=&s_ziadost_Klasifikacia_Sluzby=&s_ziadost_key_words=&s_kat_serv_name=&tb_ziadatel_tb_kategoriaPageSize=]]

994

995

996

== 4.6 Bezpečnostná architektúra ==

997

998

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:

999

1000

* Zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe

1001

* Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti

1002

* Zákon č. 45/2011 Z.z. o kritickej infraštruktúre

1003

* 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

1004

* 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

1005

* vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov

1006

* 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)

1007

* Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

1008

1009

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.

1010

1011

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

1012

1013

1014

= 5 Závislosti na ostatné ISVS / projekty =

1015

1016

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

|Stakeholder|(((

Kód projektu /ISVS

//(z MetaIS)//

)))|Názov projektu /ISVS|Termín ukončenia projektu|Popis závislosti

| | | | |

| | | | |

= 6 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.

1031

1032

1033

= 7 Prevádzka a údržba =

1034

1035

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

1036

1037

== 7.1 Úrovne podpory používateľov ==

1038

1039

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

1040

1041

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

1042

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

1043

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

1044

1045

== 7.2 Hodnoty úrovní poskytovania služieb, Incidenty, Problémy ==

1046

1047

|(% colspan="2" %)**Parameter**|Hodnota

1048

|(% colspan="2" %)**Plánovaná doba dostupnosti služby**|Nepretržite, 24 hodín denne / 7 dní v týždni

1049

|(% rowspan="3" %)**Doba odozvy na Incident**|**Kategória A**|30 minút

1050

|**Kategória B**|1 hodina

1051

|**Kategória C**|4 hodiny

1052

|(% rowspan="3" %)**Doba vyriešenia Incidentu**|**Kategória A**|24 hodín

1053

|**Kategória B**|48 hodín

1054

|**Kategória C**|96 hodín

1055

|(% rowspan="3" %)**Doba Vyriešenia Problému**|**Kategória A**|7 dní

1056

|**Kategória B**|14 dní

1057

|**Kategória C**|30 dní

1058

|(% colspan="2" %)**Doba plánovanej údržby služby**|Posledná sobota a nedeľa v 3., 6., 9. a 12. mesiaci kalendárneho roka

1059

|(% colspan="2" %)**Minimálna celková plánovaná doba dostupnosti služby**|**99,5 %**

1060

1061

|**Označenie závažnosti incidentu**|**Dopad**|**Popis dopadu**

1062

|**1**|**katastrofický**|katastrofický dopad, priamy finančný dopad alebo strata dát,

1063

|**2**|**značný**|značný dopad alebo strata dát

1064

|**3**|**malý**|malý dopad alebo strata dát

1065

1066

= 8 Požiadavky na personál =

1067

1068

Podrobne uvedené v Projektovom zámere.

1069

1070

1071

= 9 Implementácia a preberanie výstupov projektu =

1072

1073

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

= 10 Prílohy =

N/A

Wiki zdrojový kód pre I-03 Prístup k projektu (pristup_k_projektu)