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

Povinná osoba	Mesto Košice
Názov projektu	Konto Košičana
Zodpovedná osoba za projekt	Patrik Pavlovský (Projektový manažér)
Realizátor projektu	Mesto Košice
Vlastník projektu	Vladimír Fabián, Mesto Košice Schvaľovanie dokumentu
Položka	Meno a priezvisko	Organizácia	Pracovná pozícia	Dátum	Podpis (alebo elektronický súhlas)
Vypracoval	Patrik Pavlovský	CX DIZAJN s.r.o.	Konzultant	30.9.2024

1.História dokumentu

2. Účel dokumentu

2.1. Použité skratky a pojmy

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

3.Popis navrhovaného riešenia

Obyvatelia Košíc môžu od mája 2024 získať digitálny autentifikátor (Konto Košičana), ktorým sa môžu zjednodušene autentifikovať pri používaní mestských služieb všade tam, kde nie je zákonom vyžadovaná úroveň autentifikácie dosiahnuteľná len eID.

Konto Košičana umožňuje mestu získať dôveryhodné údaje, ktoré môže použiť pre adresnejší a proaktívnejší výkon svojich kompetencií a to napr. pri výbere miestnych daní a poplatkov za služby (predvyplnený personalizovaný platobný príkaz do mobilu cez notifikáciu), pri spracovávaní oznámení (automatické párovanie rodinných príslušníkov, ich psov, áut, či nehnuteľností), ako aj pri poskytovaní mestských služieb (parkovanie, knižnica, odpad, nahlasovanie porúch, zimná údržba...). Vytvorením konsolidovanej a vierohodnej databázy obyvateľov bude môcť predchádzať stratám z vyhýbania sa plateniu miestnych daní a poplatkov (približne 1mil. € ročne), ako aj vytvárať motivačné programy a odmeny pre komunitné angažovaných obyvateľov zlepšujúcich život v meste ostatným. Mestu sa vymanením z vendor-locku znížia prevádzkové náklady. Mesto bude napríklad môcť nahradiť poštové služby digitálnymi notifikáciami, zníži náklady spojené s prevádzkou autentifikačných a notifikačných modulov a mestských aplikácií tretími stranami, a zvýšením miery digitálnej komunikácie zníži náklady, ktoré generuje tlač a distribúcia listovej úradnej komunikácie (v r.2O24 sa očakáva fyzická distribúcia približne 130 tisíc výmerov, pri rozšírení čom po minulé roky bolo len približne 9% doručovaných elektronicky).

Košičania sa v súčasnosti môžu do svojho konta prihlásiť buď cez samostatnú doménu konta www.konto.kosice.sk, alebo cez portál elektronických služieb Košíc www.esluzbykosice.sk. Z hľadiska funkcionalít je Košičanom umožnené vytvoriť, aktivovať a spravovať svoj profil (t.j. konto). Konto Košičana má responzívne používateľské rozhranie navrhnuté tak, aby poskytovalo intuitívnu a prehľadnú navigáciu aj pri rozširovaní životných situácií (resp. z pohľadu mesta agendy), v ktorých budú môcť Konto Košičania využiť.

Za pomoci prostriedkov z dopytovej výzvy PSK-MIRRI-620-2024-DV-EFRR chceme občanom poskytnúť pristúpiť ku svojmu kontu aj prostredníctvom mobilnej aplikácie. Konto Košičana chceme navyše rozšíriť z pohľadu používateľa o nasledujúce funkcionality:

• Možnosť identifikácie pomocou QR kódu v mestských systémoch;
• Prehľad dôležitých udalostí mesta Košíc (odpad, podujatia, údržby) v kalendári, vrátane možnosti personalizovania kalendára pridávaním/odoberaním udalostí;
• Prijímanie push notifikácií s všeobecných informáciami z mesta Košice, ale aj personalizovaných notifikácii v súvislosti so zmenami stavu podaní voči mestu, alebo blížiacimi sa kalendárovými udalosťami
• Možnosť prihlásenia a odhlásenia sa na odber notifikácii podľa svojho výberu
• Možnosť zaplatiť dane a poplatky zo svojho zariadenia kreditnou kartou alebo pomocou GooglePay, ApplePay    
• Možnosť objednať si a zaplatiť za služby mesta Košíc zo svojho zariadenia kreditnou kartou alebo pomocou GooglePay, ApplePay
• Vidieť históriu svojich platieb
• Zoznam kariet vydávaných alebo platných na území mesta Košíc.
• Možnosť vytvárať všeobecné podania pre mesto Košice bez nutnosti podpisovania
• Možnosť sprístupňovať dáta zo svojho konta tretím stranám , ktoré sa na systéme konta zaintegrujú, aby mohli využívať jeho funkcionality;

Súčasná iterácia Konta Košičana umožňuje autentifikovať sa pri:

• Prístupe do portálu eSlužby Košice
• Prístupe do portálu Konta Košičana

Budúca iterácia Konta Košičana umožní identifikovať sa QR kódom resp. autentifikovať sa aj pri:

• kúpe a kontrole vstupného do mestských služieb (napr. pri vstupe do mestskej knižnice, plavárne, zoo, športovísk, MHD)

V súčasnosti používatelia po prihlásení v Konte uvidia:

• Osobné údaje evidované agendovým systémom mesta Košice
• Daňové výmery pre daň z nehnuteľnosti, za psa, komunálny odpad a drobné stavebné odpady (za posledné dva roky)
• stav platieb a začatých konaní voči mestu

Budúca iterácia Konta Košičana už však umožní v Konte vidieť aj:

• online platby realizované cez Kontom Košičana
• históriu online platieb realizovaných Kontom Košičana
• históriu podnetov odoslaných mestu
• kalendár a detail udalostí konaných v meste
• kalendár a detail údržby vykonávanej v meste
• novinky v meste komunikované magistrátom
• aktuálne a minulé notifikácie
• aktuálne a minulé správy
• údaje o spolupodielníkoch evidovaných agendovým systémom mesta Košice
• údaje o psoch evidovaných agendovým systémom mesta Košice na svoju osobu
• údaje o nehnuteľnostiach evidovaných agendovým systémom mesta Košice na svoju osobu

Cez konto im mesto pri súčasnej iterácii posiela notifikácie a správy v rámci agendy:

• výberu miestnych daní a poplatkov (doručenie elektronického výmeru)

Budúca iterácia Konta Košičana už však mestu umožní posielať do Konta notifikácie a správy:

• pri zmene stavu začatých konaní
• pri zmene stavu vykonaných platieb
• pri dôležitých novinkách a udalostiach v meste, na ktoré chce magistrát upriamiť pozornosť
• pri blížiacej sa kalendárovej udalosti
• pri možnosti využiť zľavu v službách poskytovaných mestom
• pri blížiacom sa konci cestovného lístka alebo predplatného vstupného;

Konto Košičana bude inými slovami po novom Košičanom pomáhať v týchto situáciách:

• Platba miestnej dane alebo poplatku na základe výmeru (nehnutelnosť, pes, odpad)
• Cestovanie MHD
  • Prehľad odchodov MHD, určenie obľúbených spojov, nákup cestovného lístka na MHD, detail lístka,  história jázd, koniec platnosti mesačného lístka, obnovenie platnosti lístka
• Parkovanie (zobrazenie mestských pravidiel, kúpa parkovacieho lístka, detail lístka, história nákupov, koniec platnosti lístka, obnova platnosti lístka)
• Účasť na udalostiach konajúcich sa v meste (kalendár udalostí, personalizácia kalendára, detaily udalostí, notifikácia o blížiacom sa podujatí…)
• Platba za mestské služby, napr.vstupné do ZOO, plaváreň, futbalový a hokejový štadión, knižnica.
• Informovanie sa o prebiehajúcich a plánovaných údržbách v meste

Technickým predpokladom funkčnosti zamýšľaných rozšírení sú nasledovné zmeny na frontende / backende:

• Doplnenie UI portálu Konta Košičana
• Vytvorenie mobilnej aplikácie Konta Košičana
• Aktualizácia modulu pre spracovanie správ
• Vytvorenie modulu pre kalendár
• Vytvorenie modulu pre podnety
• Vytvorenie podpory pre kalendár eventy
• Vytvorenie prepojenia medzi kalendárovými eventami a notifikáciami
• Aktualizácia notifikačného modulu o push notifikácie
• Aktualizácia notifikačného modulu o SMS
• Vytvorenie modulu pre platby
• Vytvorenie modulu mestský marketplace
• Vytvorenie modulu pre účtovanie
• Vytvorenie modulu pre objednávkový systém
• Integrácia na systémy mesta resp. systémy tretích strán
  • ISVS NORRIS LCD

Po úspešnej realizácii zamýšľaných rozšírení Konta Košičana mesto zvýši počet agiend, pri vykonávaní ktorých bude môcť proaktívne elektronicky komunikovať s obyvateľmi. Rozšíreniami z dlhodobého hľadiska ušetrí na prevádzkových nákladoch (ušetrí na poštovnom, zrýchli čas procesovania, ušetrí na prevádzke špecifických IS).

Úspešná realizácia zamýšľaných rozšírení Konta Košičana zvýši počet situácií, v ktorých sa budú môcť používatelia jednoduchšie autentifikovať. Zjednoduší sa pre nich aj dohľadanie informácií v týchto situáciách, pretože ich nájdu v konte po prihlásení. Zvýši sa počet situácií, v ktorých budú mať rýchlejší a pohodlnejší prístup ku správam a informáciám od mesta z mobilu, tabletu či počítača.

4.Architektúra riešenia projektu

4.1. Biznis vrstva

Návrh uvažuje s vytvorením služieb pre používateľov, ktorých poskytovanie bude podporené sústavou biznis procesov. Primerane sú zohľadnené požiadavky z NKIVS pre nové digitálne služby. Dôležitá je natívna integrovateľnosť vytvorených komponentov a opakovaná použiteľnosť kódov alebo stavebných prvkov.

Jednotlivé procesy a služby, ako bolo už spomenuté, sú doménovo riešene na základe organizačnej štruktúry MMK. V súčasnosti ich centrálnymi bodmi sú Kancelária prvého kontaktu a elektronickou formou reprezentovanou portálom eSlužby, portálom kosice.sk a portálom konto.kosice.sk.

4.1.1. Kancelária prvého kontaktu

Poskytuje biznisové služby procesnou formou, kde jednotlivé agendy referátov MMK, spracúva formou:

• osobného kontaktu s občanom resp. zástupcom organizácie
• telefonickou cestou pomocou Call Centra
• elektronickou cestou pomocou emailovej komunikácie

4.1.2. Portál eSlužby Košice

Poskytuje biznisové služby elektronickou formou, prostredníctvom jeho portálu. Informuje  a spracúva podania, žiadosti a hlásenia formou:

• Formulárového riešenie integrovaného na moduly ÚPVS (V závislosti od typu služby však požaduje použitie elektronickej služby autentifikácie a autorizácie (podpisovania) pomocou eID  (ÚPVS, MVSR))
• Vlastných formulárov
• Web rozhrania

4.1.3. Portál kosice.sk

Poskytuje informačné služby a dokumentáciu MMK formou.

• Web rozhrania
• File (object) systému

4.1.4. Portál konto.kosice.sk

Poskytuje základné služby pre registráciu, autentifikáciu do konta Košičana, personalizované služby načítavanie osobných údajov, ktoré mesto vedie o občanovi  a  momentálne aj výmery k daniam a  poplatkom s možnosťou stiahnutia dokumentov v PDF formáte a zaplatenia pomocou Pay By Square.

• Web rozhrania
• File (object) systému

Uvedený diagram zobrazuje závislosť biznisových funkcii a procesov MMK od týchto biznisových servisov.

Platenie daní

• AS IS
  • stanem sa majiteľom/teľkou nehnuteľnosti v rámci Košíc
  • podám daňové priznanie ku dani z nehnuteľnosti
  • dostanem rozhodnutie o výmere dane z nehnuteľnosti poštou do schránky
  • bankovým prevodom zaplatím daň z nehnuteľnosti

• TO BE (za predpokladu, že už mám aktívne Konto Košičana)
  • stanem sa majiteľom/teľkou nehnuteľnosti v rámci Košíc
  • podám daňové priznanie ku dani z nehnutelnosti
  • dostávam notifikáciu o novej správe v rámci Konta Košičana, preberám rozhodnutie o výmere dane
  • cez platobnú bránu daň rovno zaplatím
  • dostávam notifikáciu o prijatí platby

Účasť na podujatiach v meste

• AS IS
  • uvidím reklamu na podujatie (v novinách / city lighty / billboardy / plagáty)
  • vyhľadávam informácie o podujatí (google / soc. siete mesta)
  • nájdem informácie, rozhodnem sa kúpiť si lístok (online / offline)
  • manuálne si vytváram pripomienku v kalendári
  • kalendár mi pripomenie udalosť
  • zúčastním sa na podujatí
• TO BE
  • mesto ma notifikuje o blížiacom sa podujatí (v aplikácii)
  • otváram notifikáciu, dozvedám sa základné informácie o podujatí (v aplikácii)
  • aplikácia mi umožňuje ihneď kúpiť lístok (v aplikácii)
  • po zaplatení lístka mi aplikácia ponúka vytvorenie pripomienky v kalendári
  • kalendár mi pripomenie udalosť
  • zúčastním sa na podujatí

Platba za mestské služby

• AS IS
  • rozhodnem sa zaplatiť si členský poplatok do mestskej knižnice, pretože si chcem požičiavať knihy
  • hľadám stránku mestskej knižnice, aby som zistil/a cenu a informácie potrebné k platbe
  • píšem mestskej knižnici email so žiadosťou o pridelenie čitateľského čísla
  • otváram internet banking a manuálne vypĺňam platobné údaje podľa inštrukcií na stránke
  • vykonávam platbu
  • čakám na potvrdenie o sprocesovaní platby (môže trvať aj 2 dni)
  • prichádzam do knižnice, požičiavam si knihu
     
• TO BE (za predpokladu, že už mám aktívne Konto Košičana)
  • rozhodnem sa zaplatiť si členský poplatok do mestskej knižnice, pretože si chcem požičiavať knihy
  • v aplikácia vyhľadám mestskú knižnicu
  • zvolím si typ členského a ihneď ho aj zaplatím
  • obratom získavam potvrdenie o platbe
  • prichádzam do knižnice, požičiavam si knihu

4.2. Aplikačná vrstva

Aplikačná architektúra zohľadňuje toto členenie pomocou Domain Driven Architektúry a funkcionalitu zgrupuje v týchto modeloch. Moduly môžu byť realizované viacerými aplikačnými službami, ktoré môžu byť v aplikačnej a  technologickej vrstve realizované SaaS službami tretích strán, VM alebo node-mi.

Hlavnou požiadavkou na realizáciu modulov a ich servisov aby boli realizované ako samostatné SaaS služby, ktoré sú prepojené len identifikačnými prostriedkami Konto Košičana a unikátnym identifikátorom registrovaného občana.

Aplikačná architektúra je postavená na nasledujúcich princípoch:

• modularita - modulárna architektúra ideálnou voľbou pre komplexné a rozsiahle softvérové systémy, kde je dôležitá škálovateľnosť, flexibilita a opätovné použitie, lepšia správa závislostí, lepšia izolácia chýb, udržateľnosť a dlhodobý rozvoj, jednoduchšia integrácia nových technológií, zjednodušená spolupráca tímov a vytvárania subprojektov.
• multiténantnosť - mestu ako poskytovateľa softvéru ako služby modulov (SaaS), pomáha optimalizovať náklady a zlepšiť efektivitu svojich IT operácií, nielen v rámci jeho agendy, ale aj agendy mestských podnikov a organizácii spravovaných mestom
• otvorenosť - systém je navrhnutý tak, aby bol interoperabilný s inými systémami a aby umožňoval prístup, úpravu a rozširovanie prostredníctvom verejných štandardov alebo otvoreného kódu. Ako verejný štandard je zvolený OpenAPI, OIDC, OAuth2
• OPEN API - každý implementovaný servis komunikuje prostredníctvom REST API, ktoré vystavuje na svoje verejné ako aj privátne aplikačné služby
• bezpečnosť - zabezpečuje ochranu údajov, systémov a sietí pred neoprávneným prístupom. Autentifikáciu a autorizácia či už občanov alebo integrovaných servisov zabezpečuje Azure B2C SSO Identity Provider pomocou protokolu OIDC, OAuth2.

4.2.1. Aplikačná architektúra centrálnych bodov MMK - AS IS

AS IS architektúra vyobrazujúca závislosť biznisových funkcii a procesov MMK od týchto biznisových servisov.

4.2.2. Aplikačná architektúra centrálnych bodov MMK - TO BE

TO BE architektúra vyobrazujúca závislosť biznisových funkcii a procesov MMK od týchto biznisových servisov.

Samotný diagram je dosť rozmerný, preto v nasledujúcich kapitolách sú uvedené a zobrazené diagramy s ohľadom na funkcionalitu jednotlivých modulov.

TO BE architektúra kontinuálne pridáva do už existujúceho stavu nové aplikačné služby, ktoré rozšíria portfólia existujúcich modulov, ako aj samotné nové moduly. S nárastom modulov a služieb rastie aj nutnosť ich koncových služieb v administratívnej oblasti.

4.2.2.1

TO BE architektúra modulu KKAuthentification

V AS IS stave autentifikačný modul zabezpečuje registráciu a autentifikáciu do Konta Košičana prostredníctvom služieb Azure Cloudu. Zároveň poskytuje autentifikáciu a integráciu aplikácií do ekosystému Konta Košičana.

V TO BE stave sa rozširuje o nové aplikačné služby v rámci:

• deaktivácia Konta Košičana
• registrovania a autentifikácie administrátorov Konta Košičana.
• manažment administrátorov v systéme Konta Košičana.
• manažment oprávnení administrátorov v systéme Konta Košičana.

Vyobrazenie závislosti existujúceho a rozšíreného autentifikačného modulu od biznisových servisov MMK

4.2.2.2

TO BE architektúra modulu KKProfile

V AS IS stave modul profilu zabezpečuje konsolidáciu údajov o Košičanoch vedených mestom Košice v systéme LCS Norris a zároveň poskytuje tieto údaje registrovaným občanom. V súčasnosti poskytuje osobné údaje a údaje o daniach a poplatkoch.

V TO BE stave modul bude rozšírený o služby v súvislosti s platbami a notifikáciami, ako aj rozšírený o prístup z mobilnej aplikácie Konta Košičana.

Vyobrazenie závislosti rozširujúceho sa modulu na správu osobného profilu od biznisových servisov MMK.

4.2.2.3

TO BE architektúra modulu KKAplication

V AS IS stave modul profilu zabezpečuje:

• registráciu interných aplikácii a servisov do ekosystému Konta Košičana.
• registráciu externých aplikácii a servisov do ekosystému Konta Košičana.
• manažment prístupových práv aplikácii a servisov.

V TO BE stave modul bude rozširovaný o ďalšie služby v súvislosti s nastaveniami novo vzniknutých aplikácii, nových a existujúcich prístupových práv.

Vyobrazenie závislosti existujúceho modulu na integráciu aplikácii a servisov do ekosystému Konta Košičana.

4.2.2.4

TO BE architektúra modulu KKMessage

Modul predstavuje jeden z hlavných komunikačných komponentov multikanálového prístupu mesta Košíc k informovanosti občanov ako aj základ pre proaktivitu v komunikácii medzi mestom a občanmi.

V AS IS stave modul profilu zabezpečuje:

• vytváranie a manažment správ konkrétnym používateľom Konta Košičana.
• vytváranie a manažment správ do skupín, na ktoré sa používatelia Konta Košičana zaregistrovali.
• posielanie správ na email pomocou modulu notifikácii.

V TO BE stave sa rozširuje o nové aplikačné služby v rámci:

• Formátovanie správ podľa typu notifikácie.
• Rozšírenie správ o požadované akcie (proaktivita) 
• Manažment správ vlastnených používateľom.
• Manažment správ systémom - mazanie.

Vyobrazenie závislosti rozširujúceho modulu na spracovanie správ medzi IS mesta a Kontom Košičana.

4.2.2.5

TO BE architektúra modulu KKNotification

Modul predstavuje jeden z hlavných komunikačných komponentov multikanálového prístupu mesta Košíc k informovanosti občanov ako aj základ pre proaktivitu v komunikácii medzi mestom a občanmi.

V AS IS stave modul profilu zabezpečuje:

• posielanie správ na email.

V TO BE stave sa rozširuje o nové aplikačné služby v rámci:

• posielanie správ pomocou push notifikácii.
• alternatívne posielanie správ pomocou SMS.

Vyobrazenie závislosti rozširujúceho sa modulu na spracovanie notifikácii medzi ISVS mesta, tretích strán a Kontom Košičana.

4.2.2.6

TO BE architektúra modulu KKIdentificaton

Vyobrazenie závislosti nového modulu na spracovanie identifikácie medzi ISVS mesta, integrovanými tretími stranami a Kontom Košičana.

4.2.2.7

TO BE architektúra modulu KKCalendar

Vyobrazenie závislosti nového modulu na správu kalendára udalostí v Konte Košičana.

4.2.2.8

TO BE architektúra modulu KKPayment

Vyobrazenie závislosti nového modulu na zadávanie a spracovanie platieb v Konte Košičana.

4.2.2.9

TO BE architektúra modulu KKMarketplace

Vyobrazenie závislosti nového modulu pre vytváranie a spravovanie platobných položiek a zliav pre Konto Košičana.

4.2.2.10

TO BE architektúra modulu KKOrder

Vyobrazenie závislosti nového modulu na vytváranie a evidenciu objednávok a zliav k nim v Konte Košičana. 

4.2.2.11

TO BE architektúra modulu KKBilling

Vyobrazenie závislosti nového modulu na vytváranie dokladov a výkazov o zrealizovaných platbách v Konte Košičana.

4.2.2.12

 TO BE architektúra modulu KKInitiative

Vyobrazenie závislosti nového modulu na zadávanie a spracovanie podnetov občanov v Konte Košičana.

4.2.2.13 TO BE architektúra modulu KKCard

Vyobrazenie závislosti nového modulu na evidenciu a manažment kariet vlastnených občanom v Konte Košičana.

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

4.2.4. Jazyková podpora a lokalizácia

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

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

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

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

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

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

• .

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

.

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

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

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

4.2.13. Konzumovanie údajov z IS CSRU – TO BE

4.3. Dátová vrstva

4.4. Technologická vrstva

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

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

Súčasná hlavná technologická vrstva je postavená na Azure Cloude a vlastnej infrastrukture, ktorý v súčasnosti obhospodaruje aj dôležité aplikačné a koncové služby magistrátu. Obe cloudy minimálne obmedzujú IaaS a PaaS služby a tým teda ani nevymedzujú technológie operačných systémov resp. programovacie jazyky. So zavedením architektonických princípov konta Košičana je tu snaha o prenositeľnosť služieb, ktorú sa snaží mesto zabezpečiť dokerizáciou.

​​Z pohľadu riadenia Konta Košičan systému, najdôležitejším alebo core komponentom je Azure B2C Ténant manažujúci integrujúce sa aplikácie, riadenie rolí a prístupov k API pre integrované aplikácie, administrátorov a občanov registrovaných do Konta Košičana. Samotný Azure Cloud poskytuje aj svoje kapacity pre web riešenia.

Infraštruktúra MMK poskytuje výpočtový a diskový výkon pre backendové a webové servisy.

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

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

Budúci stav zohľadňuje už existujúci stav a pridáva do schémy ďalšie služby IaaS, PaaS a SaaS služby nevyhnutné pre realizáciu biznisových požiadaviek Konta Košičana. Ide predovšetkým o integráciu:

• Firebase pre potreby push notifikácii k mobilnej aplikácii.
• UPVS pre potrebu registrácie pomocou eID a mID
• Mailjet pre potreby odosielania emailov pomocou REST API a ich customizácie

V MMK Infraštruktúre taktiež vznikne nová dátová vrstva pre potreby nových servisov.

Technologická architektúra bude v identická v oboch prostrediach spracovaných MMK a to testovacom TEST a produkčnom PROD. Výkonnostná požiadavka pre testovacie prostredie je polovica výkonnú produkčného prostredia.

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

4.5. Bezpečnostná architektúra

Návrh na bezpečnostné opatrenia vychádza z platnej legislatívy a súčasného stavu. Konto Košičana vzniká ako skupina existujúcich a nových modulov ISVS, ktoré bude používaný tak ako  MMK, spoločnosti s účasťou mesta tak aj riadne integrované tretie strany.

4.5.2. Zabezpečenie komunikácie

Komunikácia bude prebiehať pomocou REST volaní, vo formátoch údajov JSON. Prenos dát bude pre REST prebiehať cez protokol HTTPS, certifikát bude vydaný dôveryhodnou certifikačnou autoritou. Služby vystavené navonok budú popísané podľa štandardu Open API Standard 3.0 (Swagger).

Dáta budú chránené pri prenose symetrickým šifrovaním alebo asymetrickým šifrovaním na základe zvoleného prenosového protokolu.

Všetky komunikačné kanály budú známe a popísané. Jednotlivé komponenty systému budú oddelené podľa vrstiev plniacich špecifickú úlohu:

1.     Prístupová vrstva,

2.     Aplikačná vrstva,

3.     Databázová vrstva.

Jednotlivé vrstvy sú a budú umiestnené v separátnych, logicky oddelených sieťových segmentoch pričom komunikácia medzi nimi bude umožnená na základe pravidiel nastavených vo firewalle. Komunikácia bude kontinuálne monitorovaná a filtrovaná.

Za implementáciu monitoring eventov je v zmysle časti "K" prílohy č.2 vyhlášky 179/2020, ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy Kategórie III, nesie zodpovednosť prevádzkovateľ ISVS a je povinný spomínané opatrenia nasadiť. Na serveroch bude host-based firewall nakonfigurovaný podľa princípu najmenšieho privilégia (least privilege).

Správcovské a monitorovacie rozhrania sieťových prvkov a serverov nesmú byť prístupné priamo z externej siete, internetu. Správcovské a monitorovacie rozhrania musia byť prístupné len z vopred špecifikovaných sietí (napr. administrátorská sieť) - viď časť "E" prílohy č.2 vyhlášky 179/2020. Prístup a forma pripojenia pre SKIT bude definovaná správcom tejto infraštruktúry a práva na prístup budú pridelené pre SKIT podľa platných pravidiel a politík.

Webový portál bude prístupný výlučne prostredníctvom protokolu HTTPS. S ohľadom na best practices sa k webovému portálu nebude pristupovať prostredníctvom HTTP.

Identita webového portálu bude zabezpečená platným, dôveryhodným certifikátom vydaným na doménu, na ktorej je dostupný. Identita webového portálu bude zabezpečená certifikátom s Extended Validation. Webový portál nesmie používať nedôveryhodné alebo vypršané SSL/TLS certifikáty.

Údaje, ktoré sú citlivé z hľadiska integrity alebo dôvernosti, sa musia prenášať iba prostredníctvom zašifrovaného spojenia SSL/TLS.

Webový portál bude:

1.     podporovať TLS 1.2a TLS 1.3,

2.     podporovať šifry, ktoré majú vlastnosť Perfect Forward Secrecy (PFS),

3.     dodržiavať negociačný postup negociácie TLS spojenia, popísaný v RFC 5746, kvôli zraniteľnosti Insecure renegociation a riziku útoku typu MitM,

Webový portál nebude podporovať

1.     SSLv2, SSLv3, TLS 1.0 a TLS 1.1,

2.     šifry s kľúčom kratším ako 112 bitov a blokom kratším ako 64 bitov,

3.     NULL ciphers a anonymný Diffie-Hellman algoritmus,

4.     export (EXP) šifry,

5.     RC4, DES a 3DES. Šifry s CBC módom by mali byť nahradené bezpečnejšími AEAD šiframi,

6.     klientom iniciovanú SSL/TLS renegociáciu šifrovacích kľúčov (kvôli DoS útoku),

Použité šifry a protokoly SSL/TLS by mali byť odolné voči známym typom útokov, ako napríklad: FREAK, BEAST (používanie TLS 1.2, pri TLS 1.0 nepoužívanie šifry s AES), BREACH (Pri SSL/TLS musí byť vypnutá http kompresia), POODLE, LOGJAM, TLS Crime (TLS kompresia bude vypnutá).

Dĺžka kľúča asymetrickej šifry RSA, DSA v X.509 certifikáte musí byť aspoň 2048 bitov. Toto neplatí pre ECDSA, kedy na dosiahnutie vysokej bezpečnosti postačujú kratšie kľúče – napríklad 256 bitov. X.509 certifikáty musia byť hashované bezpečnými hashovacími funkciami (napr. kvôli možnosti kolíznych útokov nesmie byť použitý algoritmus MD5).

Pre všetky kryptografické operácie musia byť použité kryptograficky silné generátory pseudonáhodných čísel.

Webový server bude chránený WAF (web aplikačný firewall - viď časť "I" prílohy 2 vyhlášky 179/2020) minimálne s nasledujúcou funkcionalitou:

1.     Detekcia a prevencia známych útokov (Code injection – SQL, XSS, Command, XPATH, ...),

2.     Kontrola používateľských vstupov pre Web server prostredníctvom whitelistu a ich prekódovanie do HTML entít alebo podobných bezpečných náhrad.

3.     Kontrola používateľských vstupov pre API Gateway prostredníctvom blacklistu.

Server bude pri SSL/TLS používať HSTS - HTTP Strict Transport Security. Nastavené by mali byť direktívy:

1.     max-age=<číslo> – počet sekúnd, počas ktorých má prehliadač automaticky konvertovať všetky HTTP požiadavky do HTTPS

2.     includeSubDomains – indikuje, že všetky subdomény aplikácie musia používať HTTPS

V odpovediach webového servera sa nesmú nachádzať hlavičky prezrádzajúce použitú technológiu a / alebo jej verziu (Server, X-Powered-By, X-AspNet-Version a pod.).

Aplikácia musí korektne inštruovať prehliadač, aby neukladal citlivé informácie, prenášané prostredníctvom HTTPS, do cache (a aby neboli bez kontroly opäť prístupné z histórie prehliadania) minimálne v rozsahu: Cache-Control:no-cache,no- store,private,must-re-validate,max-age=0,no-transform; Expires:0; Pragma:no-cache

Webové správcovské rozhrania musia byť dostupné iba prostredníctvom SSL/TLS.

4.5.3. Zabezpečenie integrity

Validácia vstupov bude vykonávaná na strane servera a bude vykonávaná aj na strane klienta. Všetky používateľské vstupy musia byť kontrolované na strane servera prostredníctvom whitelistov alebo regulárnych výrazov v kontexte, v ktorom sú použité.

Proces webového servera aj proces backendovej databázy musí byť konfigurovaný tak, aby bežal pod unikátnym používateľským kontom s limitovanou množinou privilégií (napr. v oddelenej schéme).

Webový server bude konfigurovaný tak, aby súbory s webovým obsahom boli procesom prislúchajúcim službe webového servera prístupné na čítanie, no nie na zápis. Procesy webového servera nebudú mať právo zápisu do priečinkov, kde je uchovávaný verejný obsah.

OS bude nakonfigurovaný tak, aby dočasné súbory vytvorené procesmi webového servera boli obmedzené na určený a vhodne zabezpečený priečinok. Ak je to možné, prístup k dočasným súborom by mal byť obmedzený na procesy, ktoré ich vytvorili.

Integrita auditných záznamov a logov musí byť zabezpečená vhodnými kryptografickými prostriedkami a vynucovaná pomocou oddelenia právomocí. Bude použitý centrálny logovací a auditovací nástroj určený budúcim prevádzkovateľom.

4.5.4. Riadenie prístupu

Právo na vykonávanie privilegovaných operácií musí byť obmedzené na poverených administrátorov.

Privilegované prístupy (administrátorské prístupy) sa musia realizovať pomocou šifrovaných kanálov z vopred definovaných kontrolovaných pracovných staníc (viď časti "E" a "K" prílohy č.2 vyhlášky 179/2020 - jedná sa o súčinnosť prevádzkovateľa). Administrátori prostredia, v ktorom sa komponenty riešenia prevádzkujú, môžu vykonávať svoje aktivity len spôsobom, ktorý im neumožňuje vymazať stopy ich aktivít (viď časť "K" prílohy č.2 vyhlášky 179/2020). Na tento účel pristupujú na manažované systémy výhradne cez systém riadenia privilegovaného prístupu (PAM - privileged access management). Prístup môže byť realizovaný formou jump servera spravovaného nezávislým bezpečnostným oddelením, na ktorom sa nahrávajú všetky používateľské relácie (viď časť "E" prílohy č.2 vyhlášky 179/2020). Prístup na manažment rozhrania serverov CAMP je umožnený výhradne z PAM, nikdy nie z pracovných staníc používaných na bežnú prácu. Prístup na PAM by mal byť chránený dvojfaktorovou autentifikáciou.

Lokálny administrátor webservera musí byť unikátny pre každý webový server.

Všetky servery a syslog servery musia byť synchronizované s dôveryhodným NTP serverom.

Pre každý virtuálny host na fyzickom webserveri musí existovať separátny log (viď časť "D" prílohy č.2 vyhlášky 179/2020).

V logoch musia byť uvedené:

1.     timestamp - kedy udalosť nastala, vrátane určenia časovej zóny,

2.     verejná IP adresa používateľa,

3.     dopytovaná stránka/URL,

4.     HTTP kód odpovede servera,

5.     veľkosť odpovede servera v bytoch,

6.     obsahy hlavičiek User-Agent a Referrer,

7.     V prípade záznamov o udalostiach súvisiacich s autentifikáciou alebo s činnosťou autentifikovaného používateľa je nutné zaznamenať účet a akciu aká bola vykonaná.

4.5.4. Definícia používateľských rolí

Základné pravidlo pre definovanie používateľských rolí je pravidlo nezlučiteľnosti rolí a oddelenia právomocí. Žiadna osoba nesmie disponovať takou kombináciou právomocí, ktorá by jej umožnila vykonať na systémoch operácie vedúce k narušeniu dostupnosti, dôvernosti alebo integrity dát. Toto platí rovnako pre dáta uložené v aplikácii ako aj prevádzkové dáta technológie, na ktorej aplikácia beží.

4.5.5. Manažment používateľov

Musia byť odstránené všetky testovacie a pôvodné účty z produkčných systémov. Každý používateľ a administrátor musia mať jedinečné ID.

Základné pravidlá pre manažment používateľov v prostredí, v ktorom sa riešenie prevádzkuje, sú nasledovné:

1.     Privilégiá sa prideľujú podľa princípu need-to-know,

2.     Privilégiá sa prideľujú podľa princípu least privilege,

3.     Privilégiá sa prideľujú tak, aby sa neporušili pravidlá nezlučiteľnosti privilégií a oddelenia právomocí,

4.     Administrátori siete a operačných systémov nesmú byť zároveň administrátori bezpečnosti,

5.     Žiadatelia o prístup nesmú byť schopní schváliť si vlastné žiadosti,

6.     Žiadatelia o prístup si nesmú byť schopní sami vytvárať účty.

Vývojári a testeri nesmú mať za normálnych okolností prístup na produkčné systémy. Existujú však výnimočné prípady kedy takéto prístupy môžu byť poskytnuté - viď časť "J" písmeno g) prílohy č.2 vyhlášky 179/2020.

Tvorcovia reportov nesmú byť zároveň ich schvaľovateľmi.

Dokumentácia k prideleným roliam musí byť pravidelne kontrolovaná a pridelené role prehodnocované. Dokumentácia prístupu rolí systémom musí byť pravidelne kontrolovaná a pridelené prístupy prehodnocované. O vykonaní kontroly musí byť vedený záznam.

Používateľské a administrátorské prístupy môžu byť pridelené len na základe schválených žiadostí. Prístupové údaje (meno a heslo) používané pre bežnú prácu sa nesmú používať pre vykonávanie privilegovaných operácií.

Prvotné heslá musia byť komunikované bezpečným spôsobom a musí byť vynútená ich zmena pri prvom prihlásení. Kvalita hesiel vyžadovaná aplikáciou ako aj podpornou infraštruktúrou musí byť v súlade s heslovou politikou organizácie.

Aplikácia musí pre všetky autorizačné mechanizmy implementovať politiku, pri ktorej je zakázané všetko, čo nie je explicitne povolené (default-deny). Aplikácia musí vyžadovať autentifikáciu pre každú privilegovanú operáciu (napr. meno a heslo na prvotné prihlásenie, token). Aplikácia musí implementovať autentifikáciu a autorizáciu na strane servera.

4.5.6. Ochrana osobných údajov a Bezpečná autentifikácia používateľa

Používateľ pristupuje k funkcionalite cez mobilnú, webovú aplikáciu alebo integrovaný ISVS (tretia strana). Pre prácu v musí byť používateľ autentifikovaný. Nasledovné autentifkácie už sú súčasťou ISVS Konta Košičana :

1)     Autentifikácia pre Konta Košičana

a)     OIDC (JWT, OAuth2) - prihlasovanie pomocou emailu a  hesla, využitie autentifikácie pomocou Azure B2C služieb

2)     Autentifikácia aplikácii

a)     OIDC(JWT, OAuth2) - v prípade prístupu aplikácie, teda akýchkoľvek integrovaných ISVS (tretia strana), má ako možnosť autentifikácie využitie autentifikácie pomocou Azure B2C služieb

3)     Autentifikácia administrátorov

a)     OIDC (JWT, OAuth2) - prihlasovanie pomocou emailu a  hesla, a, využitie autentifikácie a utorizácie pomocou Azure B2C služieb

4.5.7. Ukladanie a ochrana osobných údajov

Konto Košičan pracuje aj s osobnými údajmi, ktoré mesto vedie o občanoch mesta Košíc a ich uloženie je v agendových systémoch MMK. Konto košicana tieto údaje neduplikuje a ako zdroj pravdy aj naďalej využíva agendový systém. K osobným údajom ma po autentifkácii a následnom overení autorizačnyćh tokenov len prihlásený občan.

Dáta budú prenášané v zašifrovanej forme a rozšifrovanie sa udeje až u konzumenta.

4.5.8.  Komunikácia s tretími stranami

Azure B2C Téneant tvorí integračnú a bezpečnostnú vrstvu pre komunikáciu s riadne integrovanými tretími strany (ISVS, komerčné subjekty). Integrované tretie strany sa budú k publikovaným službám pripájať cez REST API publikovanými a dokumentovanými v súlade so štandardom OAS3.0.

Integrované tretie strany budú volať metódy príslušných API vystavené na zabezpečených end-pointoch zo siete internet, ku ktorým budú mať povolený prístup. Zabezpečenie komunikácie bude:

1.     HTTPS spojenie je zabezpečené TLS minimálne vo verzii 1.2 a vyššej s použitím AEAD šifier

2.     pomocou OIDC, Oauth2 JWT tokenov,

Komunikácia bude na báze REST a formáty budú, nie výlučne, XML a JSON.

4.5.9. Pravidlá pre bezpečnú komunikáciu pre vývoj

Pri konfigurácii a vývoji súčasní riešenia budú aplikované tieto pravidlá (a musí ich primerane implementovať aj integrovaná tretia strana):

1)     Ukladanie dát a súkromie:

a)     Pre integrované mobilné aplikácie sa na ukladanie citlivých údajov (prihlasovacie údaje, šifrovacie kľúče) sa použije “bezpečné úložisko“ daného systému na to určené (Keychain/Keystore), prípadne sa mobilná aplikácia pripája cez svoj backend,

b)     Citlivé údaje nebudú ukladané mimo aplikačný kontajner a bezpečného úložiska,

c)      Citlivé údaje sa nebudú zapisovať do logov, záloh aplikácie ani zdieľané s tretími stranami ak to nie je súčasťou funkcionality,

d)     UI neumožní zobraziť heslo alebo PIN,

e)     Citlivé údaje budú odstránené z náhľadu obrazovky, ak ide aplikácia do pozadia,

f)      Citlivé údaje nebudú uložené lokálne na zariadení, v prípade potreby sú získavané zo služby a uložené iba v pamäti,

g)     Citlivé údaje sú odstránené z pamäte bezprostredne po použití,

h)     Lokálne úložisko je vymazané po väčšom počte neúspešných pokusov prihlásenia do aplikácie,

2)     Šifrovanie:

a)     Aplikácia nevyužíva ten istý šifrovací materiál na rôzne účely,

b)     Pri generovaní náhodných hodnôt sa použije dostatočne bezpečný generátor,

3)     Autentifikácia pre tretie strany:

a)     Na prístup k vzdialenej službe je potrebná autentifikácia,

b)     Autentifikačná služba vydá podpísaný prístupový token (JWT) s krátkou životnosťou.

c)      Po odhlásení užívateľom je prístupový token odstránený z pamäte aplikácie,

d)     Po exspirácii platnosti tokenu sa relácia ukončí a dôjde k odhláseniu užívateľa,

e)     Aplikácia informuje o citlivých aktivitách s účtom - zoznam zariadení, IP adresa, poloha, ... s možnosťou zablokovania prístupu,

f)      Spôsoby prihlásenia sú definované a vynútené na strane služby,

4)     Sieťová komunikácia:

a)     Prenášané dáta sú šifrované s TLS, aplikácia overuje X.509 certifikáty a akceptuje iba vydané dôveryhodnou CA,

b)     Aplikácia používa najnovšie bezpečnostné knižnice,

5)     Interakcia:

a)     Aplikácia neumožní spustiť JavaScript kód z neznámych zdrojov,

b)     Aplikácia používa safe-serialization API pri object deserializácií,

c)      Používa sa mechanizmus CORS,

6)     Kvalita a nastavenie buildov aplikácií a ich súčastí:

a)     Všetky developerské pomocné kódy, nastavenia, back-door sú odstránené

b)     Aplikácia neloguje detailné chyby,

c)      Všetky použité knižnice tretích strán sú identifikované, overené a skontrolované že neobsahujú známe zraniteľnosti,

d)     Aplikácia správne narába s výnimkami a ich odchytávaním,

e)     Pri release zostavení sa použijú nástroje na obfuskáciu kódu, tak aby základná statická analýza kódu neodhalila dôležitý kód alebo dáta.

7)     Implementácia v čo najväčšej miere OWASP TOP 10 odporúčaní pre webové rozhranie:

a)     Broken Access Control,

b)     Cryptographic Failures,

c)      Injection,

d)     Insecure Design,

e)     Security Misconfiguration,

f)      Vulnerable and Outdated Components,

g)     Identification and Authentication Failures,

h)     Software and Data Integrity Failures,

i)       Security Logging and Monitoring Failures,

j)       Server-Side Request Forgery.

5. Závislosti na ostatné ISVS / projekty

6. Zdrojové kódy

7. Prevádzka a údržba

7.1. Prevádzkové požiadavky

7.1.1. Úrovne podpory používateľov

7.1.2. Riešenie incidentov – SLA parametre

Označenie naliehavosti incidentu:

možný dopad:

 Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

Vysvetlivky k tabuľke

(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

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

(3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

(4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

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

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

Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2. Požadovaná dostupnosť IS:

8.Požiadavky na personál

9.Implementácia a preberanie výstupov projektu

Projekt bude realizovaný metódou waterfall. V zmysle Vyhlášky 401/2023 Z.z. budú výstupy jednotlivých fáz predkladané na schválenie riadiacemu výboru projektu.

10. Prílohy