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.

115

116

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky obsahuje opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

\\

== {{id name="projekt_2359_Pristup_k_projektu_detailny-2.1Použitéskratkyapojmy"/}}2.1 Použité skratky a pojmy ==

\\

**~ **

(% class="wrapped" %)

|(((

**ID**

)))|(((

**SKRATKA**

)))|(((

**POPIS**

)))

|(((

1.

)))|(((

API

)))|(((

Application programming interface

)))

|(((

2.

)))|(((

BPMN

)))|(((

Business Process Model and Notation

)))

|(((

3.

)))|(((

CSRÚ

)))|(((

Centrálna správa referenčných údajov

)))

|(((

4.

)))|(((

DevOps

)))|(((

Je skrátený názov pre developer, security alebo aj automatizovaný devops ako súbor procesov medzi vývojom a prevádzkou, skratka z developer operations. Vysvetlenie detail viď [[https:~~/~~/en.wikipedia.org/wiki/DevOps>>url:https://en.wikipedia.org/wiki/DevOps||shape="rect"]]

)))

|(((

5.

)))|(((

DMS

)))|(((

Document management system

)))

|(((

6.

)))|(((

EDR

)))|(((

Endpoint Detection and Response

)))

|(((

7.

)))|(((

ezdravie

)))|(((

Programové označenie Národného zdravotníckeho informačného systému

)))

|(((

8..

)))|(((

EÚ

)))|(((

Európska únia

)))

|(((

9.

)))|(((

HW

)))|(((

Hardware

)))

|(((

10.

)))|(((

HLD

)))|(((

High level dizajn – vysokoúrovňový dizajn napr architektúru, bezpečnosť

)))

|(((

11.

)))|(((

IaaS

)))|(((

Infrastructure as a service

)))

|(((

12.

)))|(((

IAM

)))|(((

Identity and Access Management

)))

|(((

13.

)))|(((

IKT

)))|(((

Informačno-komunikačné technológie

)))

|(((

14.

)))|(((

IS

)))|(((

Informačný systém

)))

|(((

15.

)))|(((

IS VS

)))|(((

Informačný systém verejnej správy

)))

|(((

16.

)))|(((

ISZI

)))|(((

Informačný systém zdravotníckych indikátorov

)))

|(((

17.

)))|(((

JRÚZ

)))|(((

Jednotná referenčná údajová základňa rezortu zdravotníctva.

)))

|(((

18.

)))|(((

KPI

)))|(((

Key performance indicator – Kľúčové indikátory, prostredníctvom ktorých sa meria naplnenie cieľov projektu.

)))

|(((

19.

)))|(((

K+D

)))|(((

koncept oddelenia K=klinických a D=demografických dát

)))

|(((

20.

)))|(((

LLD

)))|(((

Low level dizajn – nízkoúrovňový dizajn napr. pre architektúru, bezpečnosť. Obsahuje detailné dizajny až na úrovní nastavení parametrov

)))

|(((

21.

)))|(((

MDM

)))|(((

Mobile device management

)))

|(((

22.

)))|(((

MIRRI

)))|(((

Ministerstvo investícií, regionálneho rozvoja a informatizácie Slovenskej republiky

)))

|(((

23.

)))|(((

MV SR

)))|(((

Ministerstvo vnútra SR

)))

|(((

24.

)))|(((

MZ SR

)))|(((

Ministerstvo zdravotníctva Slovenskej republiky

)))

|(((

25.

)))|(((

NCZI

)))|(((

Národné centrum zdravotníckych informácií

)))

|(((

26.

)))|(((

NKIVS

)))|(((

Národná koncepcia informatizácie verejnej správy

)))

|(((

27.

)))|(((

NZIS

)))|(((

Národný zdravotnícky informačný systém

)))

|(((

28.

)))|(((

OOÚ

)))|(((

Ochrana osobných údajov

)))

|(((

29.

)))|(((

PO

)))|(((

Plán obnovy a odolnosti

)))

|(((

30.

)))|(((

OVM

)))|(((

Orgán verejnej moci

)))

|(((

31.

)))|(((

PaaS

)))|(((

Platform as a service

)))

|(((

32.

)))|(((

PILOT

)))|(((

PILOT - Prevádzka riešenia na vybraných aktéroch na produkčnom prostredí.

)))

|(((

33.

)))|(((

PoC

)))|(((

PoC - Proof of Concept - Implementovaný prototyp riešenia nasadený do produkčnej prevádzky a overený E2E testami minimálne s využitím mockov

)))

|(((

34.

)))|(((

PR

)))|(((

Projektové riadenie

)))

|(((

35.

)))|(((

PrZS

)))|(((

Prijímateľ zdravotnej starostlivosti

)))

|(((

36.

)))|(((

PZS

)))|(((

Poskytovateľ zdravotnej starostlivosti

)))

|(((

37.

)))|(((

ROLLOUT

)))|(((

ROLLOUT - Postupné pripájanie ostatných aktérov na produkčnom prostredí.

)))

|(((

38.

)))|(((

RFO

)))|(((

Register fyzických osôb

)))

|(((

39.

)))|(((

RPO

)))|(((

Register právnických osôb

)))

|(((

40.

)))|(((

RÚVZ

)))|(((

Regionálne úrady verejného zdravotníctva

)))

|(((

41.

)))|(((

SDL metodika

)))|(((

Security development lifecycle – interná metodika pre postup implementácie vydaný NCZI.

)))

|(((

42.

)))|(((

SFTP

)))|(((

SSH File Transfer Protocol

)))

|(((

43.

)))|(((

SLA

)))|(((

Service level agreement

)))

|(((

44.

)))|(((

SOAP

)))|(((

Simple Object Access Protocol

)))

|(((

45.

)))|(((

SOAR

)))|(((

Security orchestration, automation and response

)))

|(((

46.

)))|(((

SR

)))|(((

Slovenská republika

)))

|(((

47.

)))|(((

SW

)))|(((

Softvér

)))

|(((

48.

)))|(((

ŠÚ SR

)))|(((

Štatistický úrad Slovenskej republiky

)))

|(((

49.

)))|(((

ŠÚKL

)))|(((

Štátny ústav pre kontrolu liečiv

)))

|(((

50.

)))|(((

ÚDZS

)))|(((

Úrad pre dohľad nad zdravotnou starostlivosťou

)))

|(((

51.

)))|(((

VÚC

)))|(((

Vyšší územný celok alebo iný povoľovací orgán

)))

|(((

52.

)))|(((

ZS

)))|(((

Zdravotná starostlivosť

)))

\\

== {{id name="projekt_2359_Pristup_k_projektu_detailny-2.2Konvenciepretypypožiadaviek(príklady)"/}}2.2 Konvencie pre typy požiadaviek (príklady) ==

// //

**Funkcionálne (používateľské) požiadavky **majú nasledovnú konvenciu:

**FRxx**

* U – užívateľská požiadavka

510

* R – označenie požiadavky

511

* xx – číslo požiadavky

512

513

**Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky** majú nasledovnú konvenciu:

**NRxx**

* N – nefunkčná požiadavka (NFR)

518

* R – označenie požiadavky

519

* xx – číslo požiadavky

520

521

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

\\

= {{id name="projekt_2359_Pristup_k_projektu_detailny-3.Popisnavrhovanéhoriešenia"/}}3. Popis navrhovaného riešenia =

\\

NCZI na prevádzku agendových systémov používa zastaranú aplikačnú a hardwarovú architektúru z roku 2012. Vek samotnej hardwarovej infraštruktúry je teda viac ako 12 rokov, bez podpory výrobcu a bez možnosti zakúpenia podpory výrobcov. Jadro aplikácie eZdravia (NZIS) je prevádzkované na exspirovanom systémovom softvéri, ako aj databázovej platforme. Tento stav sa zásadne podpisuje na neplánovaných výpadkoch, čo spôsobuje významné zhoršovanie dostupnosti poskytovaných služieb z hľadiska bezpečnosti a stability, a taktiež nedostupnosti ďalších zdrojov na strane infraštruktúry pre nové rozvojové projekty. V neposlednom rade neplánované výpadky vyvolávajú neplánované a neplánovateľné výdavky, ktoré vždy riešia prevádzkovú situáciu zo svojej podstaty iba čiastočne.

530

531

V súčasnej architektúre je dnes stav, ktorý sa používa len pre PROD a PRE-PROD prostredie alebo jednotlivé prostredia nie sú homogenizované cez rôzne IS, úplne tu absentuje prostredie pre TEST a DEV, ktoré sú plne v réžii rôznych dodávateľov. Do NCZI sa už len nasadzuje do PRE-PROD a potom do PROD prostredí. Počas bežnej prevádzky sú zdroje alokované pre testovacie a vývojové prostredia, v čase aktivácie záložných prostredí, čo je považované za mimoriadnu situáciu, sú testovacie a vývojové prostredia potlačené, prípadne úplne deaktivované.

532

533

Z pohľadu zabezpečenia má eZdravie špecifickú architektúru z dôvodu ochrany citlivých zdravotníckych záznamov, pričom sa používa K+D bezpečnostný koncept. Princíp spočíva v oddelení K=klinických a D=demografických dát. Demografické dáta sú uložené v JRUZoch kde sú osobné údaje pacientov a Klinické dáta sú uložené v eZdravie čo sú zdravotné záznamy pacientov. Cieľom tejto architektúry bolo dosiahnuť to, aby sa ani na admin úrovni nedali spojiť klinické záznamy pacienta s jeho identitou. Informačné systémy eZdravia obsahujú hlavne citlivé zdravotnícke dáta o občanoch SR a majú strategický význam pre Slovenskú republiku. Táto potreba je v nesúlade s akoukoľvek úvahou o migrácii takýchto dát alebo systémov do prostredí globálnych, alebo i lokálnych privátnych poskytovateľov cloudových služieb. Zároveň na základe výstupov spoločnej expertnej skupiny NCZI a MIRRI ako orgánu vedenia pre oblasť informatizácie bola na základe technických a bezpečenostných požiadaviek možnosť migrácie do vládneho/SK cloudu vylúčená ako nerealizovateľná.

534

535

Nové projekty rozvoja IT sú už koncipované tak, aby boli použité moderné architektonické a bezpečnostné princípy, kontajnerizácia a prenositeľnosť medzi prostrediami s použitím DevSecOps. Preto je pre MZ a NCZI urgentná potreba sanácie súčasného datacentra. Projekt predstavuje ideu modernizácie, nevyhnutnej miery redesignu a novej architektúry zastaralej infraštruktúry, konsolidáciu základných infraštruktúrnych služieb pod jednotné platformy a jednotnú správu tak aby boli použiteľné nielen pre súčasné informačné systémy ale aj pre budúce ohlásené projekty ktoré budú spadať pod správu NCZI.

536

537

NCZI práve preto považuje za nutnosť sanácie súčasnej infraštruktúry a jej modernizácie a prispôsobenie aj na beh cloud native aplikácií za strategické rozhodnutie. Adresuje totiž všetky výzvy, ktorým dnes zdravotnícky rezort čelí a poskytne plnú kontrolu nad kritickými informačnými systémami a zároveň zjednoduší ich prevádzku. Z pohľadu celého rezortu MZ SR (ako aj kľúčovej organizácie akou je NCZI) je mimoriadne dôležité zachovanie práve kontroly z dlhodobého hľadiska prevádzkovaním informačných systémom od vrstvy infraštruktúry až po aplikačnú úroveň a úroveň riadenia prístupov a zabezpečenia bezpečnosti. Len tento prístup umožní efektívne reagovať na budúci vývoj a prípadné hrozby.

538

539

**Zámer sanovať a modernizovať infraštruktúru NCZI, bude obsahovať nasledovné:**

540

541

1. Homogénnosť

542

Kľúčové komponenty musia byť identické a pripravené na prevádzku konkrétnych typov služieb. Z pohľadu prevádzky sa stále jedná o obmedzenú sadu hardvérových a softvérových zdrojov, ktoré umožňujú vysokú mieru optimalizácie prevádzkových procesov. Zjednodušuje sa tým prevádzka a vzájomná kompatibilita

543

1. Škálovateľnosť

544

Súvisí s bodom 1, bude navrhnuté tak aby sa dali doplniť ďalšie výpočtové a úložné zdroje už do do nových riešení.

545

1. Redundancia

546

Sanácia datacentra bude navrhnuté tak, aby sa dalo v budúcnosti rozšíriť cez dve lokality

547

1. Konektivita

548

Obnova a redesign perimetra pod kontrolou NCZI

549

1. Monitoring a centrálny logging

550

Zriadenie nového monitoringu, ktorý bude vykonávaný centrálne naprieč všetkými informačnými systémami NCZI na úrovni fyzickej ale aj aplikačnej infraštruktúry

551

1. Zálohovanie a obnova dát

552

Obnova zálohovania a prechod z tape na disk to disk riešenia pre rýchlejšiu obnovu

553

1. Automatizácia

554

Nastavenie automatizácia pre prideľovanie zdrojov a post install aktivít ako konfigurácia, patching, compliance a podobne

555

1. DevSecOps

556

Zriadenie jednotnej platformy pre súčastné a budúce informačné systémy

\\

= {{id name="projekt_2359_Pristup_k_projektu_detailny-4.Architektúrariešeniaprojektu"/}}4. Architektúra riešenia projektu =

\\

Vzhľadom na skutočnosť, že projekt svojim charakterom predstavuje predovšetkým obnovu infraštruktúry na komponenty s podporou, kontajnerizáciou a aktualizáciu prevádzkových platforiem, migrácii systému na infraštruktúrne cloudové služby nie je ťažisko popisu architektúry na biznis a aplikačnej vrstve, ale na technologickej vrstve.

565

566

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.1Biznisvrstva"/}}// //4.1 Biznis vrstva ===

567

568

Kapitola je nerelevantná vzhľadom na HW typ projektu. Implementáciou projektu nedôjde k procesným zmenám z hľadiska G2B, G2C, G2G. Implementované zmeny vyplynú iba z podstaty úprav na infraštruktúrnej vrstve. Motiváciou projektu nie je zmena biznis architektúry procesov dotknutých ISVS.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.1.1Prehľadkoncovýchslužieb–budúcistav:"/}}4.1.1 Prehľad koncových služieb – budúci stav: ===

\\

Predmetom projektu nie je budovanie ani rozvoj koncových služieb.

577

578

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.1.2Jazykovápodporaalokalizácia"/}}4.1.2 Jazyková podpora a lokalizácia ===

579

580

Jazyková podpora a lokalizácia používateľského rozhrania a výstupov je anglický resp. slovenský jazyk.

\\

== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2Aplikačnávrstva"/}}4.2 Aplikačná vrstva ==

585

586

Riešenie musí umožňovať škálovanie automaticky v určenom rozsahu. Riešenie musí podporovať operačné systémy Windows, RHEL, Suse, CentOS a Ubuntu, a zároveň musí umožniť použitie vlastného image operačného systému používateľmi. Riešenie musí umožňovať používanie procesorov od spoločností AMD a Intel a zároveň musí byť schopné podporiť použitie oboch procesorov súčasne v riešení.

587

588

Riešenie poskytne možnosť prevádzkovania v multi-cloud prostredí (v spolupráci s lokálnymi riešeniami, VMware, hybridné cloudové riešenia, ...)

589

590

Riešenie poskytne možnosť zdieľania virtuálnych zdrojov medzi viacerými cloudovými riešeniami v multi-cloud prostredí pripadne v reálnom verejnom cloude, zároveň umožní centrálnu správu takéhoto riešenia. Riešenie musí umožniť, aby tenant vedel presúvať pracovné zaťaženie z riešenia do verejného cloudu. Riešenie musí byť tiež prepojené s verejným cloudom.

591

592

Riešenie musí umožniť vytvorenie softvérovo definovaného dátového centra (SDDC), ktoré bude súčasťou celého riešenia a bude komunikovať prostredníctvom vnútornej a rýchlej siete (backbone) v rámci tohto riešenia. Zároveň musí byť zabezpečené, aby SDDC nepoužívalo internetové pripojenie a všetka komunikácia prebiehala cez internú sieť riešenia. Riešenie musí byť flexibilné a škálovateľné, to znamená, že bude možné ľahko meniť a prispôsobovať riešenie podľa potreby, bez toho aby bolo potrebné riešiť zložité a drahé zmeny infraštruktúry. Požiadavka na dostupnosť v SLA (Service Level Agreement) je minimálne 99,9%. Konkrétne to znamená, že riešenie by malo byť k dispozícii takmer nepretržite, so zanedbateľným množstvom času nedostupnosti v priebehu jedného roka. Riešenie bude zabezpečené monitorovaním každej aktivity, ktorá sa týka prístupu do dátového centra a miestnosti. Každá intervencia v rámci podpory, ktorá zahŕňa vzdialený prístup dodávateľa do riešenia, bude monitorovaná a prístupy budú zaznamenané.

593

594

Riešenie bude zabezpečované vrátane komplexnej podpory pre obnovu a dopĺňanie hardvéru, ako aj k poskytovaniu L1, L2 a L3 podpory na zabezpečenie manažovateľnosti, dostupnosti a výkonnosti riešenia. S cieľom zabezpečiť spoľahlivosť a neustálu prevádzku riešenia, bude neustále monitorovaná výkonnosť a funkčnosť hardvéru a prijímané preventívne opatrenia, aby sa minimalizovali prípadné výpadky alebo poruchy. Okrem toho podpora bude k dispozícii v prípade akejkoľvek potreby, aby bola zabezpečená maximálna a kontinuálna dostupnosť a plná funkčnosť vzhľadom na kritický význam prevádzkovaných systémov a dát. V prípade výmeny hardvéru bude vyžadovaná plná zodpovednosť za všetky úkony súvisiace s výmenou, aby sa minimalizoval prípadný výpadok služieb, a NCZI nebude musieť zasahovať ani logisticky zabezpečovať výmenu.

595

596

Návrh sanačného prostredia bude kladený dôraz na nasledujúce princípy:

597

598

* Zachovanie architektúr a konceptov pôvodných riešení, ktorým bude toto riešenie k dispozícii. Napr. vrátane K+D konceptu (zachovanie súčasného konceptu oddelenia zdravotných a osobných údajov)

599

* V úvodnej fáze nie je cieľom prerábať tieto architektúry, ale sanovať problémy súvisiace so zastaralým HW a SW vybavením, úzkymi hrdlami (škálovanie výkonu) a výpadkami HW komponentov.

600

* Architektonické zmeny v pôvodných riešeniach môžu byť predmetom následných fáz alebo iných CR (napr. prerobenie komponentu ESB,…)

601

* Zachovanie súčasného logického členenia architektúry

602

* Využitie súčasnej infraštruktúry (prepojenie novej a súčasnej infraštruktúry pri zachovaní použiteľných existujúcich HW a SW komponentov)

603

* Aplikácie sanované v rámci produkčného prostredia, budú rovnako sanované na predprodukčnom prostredí

604

* Rozšíriteľnosť architektúry o nové zóny pre ďalšie prostredia (napr. TEST, PREDPROD, ...), kontajnerizáciu a napojenie na existujúcu architektúru

605

606

Riešenie musí podporovať multi-tenant s logickým oddelením prostredia orgán riadenia. Riešenie bude schopné podporovať funkciu, ktorá umožní orgánu riadenia vytvoriť vlastné logické členenie pre svoje podriadené organizácie v ich prostredí. Prepojenie v rámci multi-tenant bude komunikovať cez vnútornú a rýchlu sieť riešenia (backbone) a nesmie vyjsť von do internetu.

607

608

Riešenie musí umožňovať definovanie a vynucovanie politík a auditov pre multi-tenant riešenie, ktoré pomôžu zabezpečiť správne riadenie a kontrolu. Týmto sa zabezpečí efektívny governance a kontrola nad celým riešením. Riešenie musí mať vysokú mieru bezpečnosti, aby zabezpečilo ochranu dát a aplikácií pred rôznymi bezpečnostnými hrozbami a útokmi. Bezpečnostné opatrenia by mali byť dostatočne silné na to, aby zabránili neoprávnenému prístupu k dátam a chránili ich pred stratou, krádežou alebo poškodením. Zároveň by riešenie malo poskytovať základné bezpečnostné funkcie, ako sú autentifikácia, autorizácia a šifrovanie dát, aby sa minimalizoval riziko úniku dát alebo ich poškodenia. Riešenie musí umožňovať efektívne riadiť náklady pomocou odporúčaní a prognóz, ktoré pomáhajú docieliť lepšie ceny. To znamená, že musí obsahovať prehľadný dashboard, ktorý umožňuje sledovať a predikovať náklady na zdroje bežiace v cloudovom riešení. Okrem toho by malo byť možné prideliť rozpočty a stanoviť soft limit hranice, na ktoré systém automaticky upozorní pri ich prekročení. Toto všetko prispeje k efektívnejšiemu riadeniu nákladov a k lepšiemu hospodáreniu s finančnými prostriedkami.

609

610

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.1Rozsahinformačnýchsystémov–ASIS"/}}4.2.1 Rozsah informačných systémov – AS IS ===

\\

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

615

616

(% class="wrapped" %)

617

|(((

618

**Kód ISVS **//(z MetaIS)//

)))|(((

**Názov ISVS**

)))|(((

**Modul ISVS**

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

)))|(((

**Stav IS VS**

(AS IS)

)))|(((

**Typ IS VS**

)))|(((

**Kód nadradeného ISVS**

633

634

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

)))

|(((

isvs_400

)))|(((

Národný zdravotnícky informačný systém

)))|(((

☐

)))|(((

prevádzkovaný a plánujem rozvíjať

)))|(((

agendový

)))|(((

\\

)))

|(((

isvs_7756

)))|(((

Jednotná referenčná údajová základňa

)))|(((

☐

)))|(((

prevádzkovaný a plánujem rozvíjať

)))|(((

agendový

)))|(((

\\

)))

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.2Rozsahinformačnýchsystémov–TOBE"/}}4.2.2 Rozsah informačných systémov – TO BE ===

// //

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

\\

(% class="wrapped" %)

674

|(((

675

**Kód ISVS **//(z MetaIS)//

)))|(((

**Názov ISVS**

)))|(((

**Modul ISVS**

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

)))|(((

**Stav IS VS**

(AS IS)

)))|(((

**Typ IS VS**

)))|(((

**Kód nadradeného ISVS**

690

691

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

)))

|(((

isvs_400

)))|(((

Národný zdravotnícky informačný systém

)))|(((

☐

)))|(((

prevádzkovaný a plánujem rozvíjať

)))|(((

agendový

)))|(((

\\

)))

|(((

isvs_7756

)))|(((

Jednotná referenčná údajová základňa

)))|(((

☐

)))|(((

prevádzkovaný a plánujem rozvíjať

)))|(((

agendový

)))|(((

\\

)))

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.3VyužívanienadrezortnýchaspoločnýchISVS–ASIS"/}}4.2.3 Využívanie nadrezortných a spoločných ISVS – AS IS ===

723

724

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.4PrehľadplánovanýchintegráciíISVSnanadrezortnéISVS–spoločnémodulypodľazákonač.305/2013e-Governmente–TOBE"/}}4.2.4 Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE ===

729

730

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.5PrehľadplánovanéhovyužívaniainýchISVS(integrácie)–TOBE"/}}4.2.5 Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE ===

735

736

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.6Aplikačnéslužbyprerealizáciukoncovýchslužieb–TOBE"/}}4.2.6 Aplikačné služby pre realizáciu koncových služieb – TO BE ===

741

742

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.7Aplikačnéslužbynaintegráciu–TOBE"/}}4.2.7 Aplikačné služby na integráciu – TO BE ===

747

748

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.8PoskytovanieúdajovzISVSdoISCSRÚ–TOBE"/}}4.2.8 Poskytovanie údajov z ISVS do IS CSRÚ – TO BE ===

753

754

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.2.9KonzumovanieúdajovzISCSRU–TOBE"/}}4.2.9 Konzumovanie údajov z IS CSRU – TO BE ===

759

760

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3Dátovávrstva"/}}4.3 Dátová vrstva ==

765

766

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.1Údajevspráveorganizácie"/}}4.3.1 Údaje v správe organizácie ===

767

768

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.2Dátovýrozsahprojektu-Prehľadobjektovevidencie-TOBE"/}}4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE ===

773

774

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.3Referenčnéúdaje"/}}4.3.3 Referenčné údaje ===

779

780

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

781

782

==== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.3.1Objektyevidenciezpohľaduprocesuichvyhláseniazareferenčné"/}}4.3.3.1 Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné ====

783

784

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

785

786

==== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.3.2Identifikáciaúdajovprekonzumovaniealeboposkytovanieúdajovdo/zCSRU"/}}4.3.3.2 Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CSRU ====

787

788

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.4Kvalitaačistenieúdajov"/}}4.3.4 Kvalita a čistenie údajov ===

793

794

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

795

796

==== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.4.1Rolyapredbežnépersonálnezabezpečeniepririadenídátovejkvality"/}}4.3.4.1 Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality ====

797

798

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.5Otvorenéúdaje"/}}4.3.5 Otvorené údaje ===

803

804

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.6Analytickéúdaje"/}}4.3.6 Analytické údaje ===

809

810

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.7Mojeúdaje"/}}4.3.7 Moje údaje ===

815

816

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.3.8Prehľadjednotlivýchkategóriíúdajov"/}}4.3.8 Prehľad jednotlivých kategórií údajov ===

821

822

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

// //

== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.4Technologickávrstva"/}}4.4 Technologická vrstva ==

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.4.1Prehľadtechnologickéhostavu-ASIS"/}}4.4.1 Prehľad technologického stavu - AS IS ===

// //

Pre obsiahlosť architektonického modelu neuvádzame náhľad, architektonický model je samostatnou prílohou projektu a vo forme náhľadu je dostupný tu: [[https:~~/~~/www.nczisk.sk/Documents/projekty/Priloha_c_1_Architektura_NZIS_AS_IS.pdf>>url:https://www.nczisk.sk/Documents/projekty/Priloha_c_1_Architektura_NZIS_AS_IS.pdf||shape="rect"]]

\\

Súčasné prostredie je prevádzkované na serveroch týchto typových rád s rôznymi konfiguráciami CPU, RAM, HDD a PCIe kariet:

839

840

* Lenovo x3550 M4, Lenovo x3650 M4

841

* UCS C240 M3, UCS C240 M5SX, BE7000H

842

* IBM x3650 M3, IBM x3850 X5

843

* Huawei RH2288 v3, Huawei RH2288H v5

844

* Dell PowerEdge R430, Dell PowerEdge R730

\\

Ako dátové úložiská sú v prostredí využívané v rôznych počtoch:

849

850

* HPE Alletra 6010, HPE Alletra 6030, HPE Alletra 6050

851

* HP 3PAR StoreServ 7200, HP 3PAR StoreServ 7400

852

* HP StoreEasy 1850

853

* Huawei OceanStor 2200 V3

854

* Backup - HPE Nimble HF40

855

* Backup páskové mechaniky – HP MSL8096 a HP MSL4048, HPE MSL3040

\\

Ako sieťové komponenty sú v prostredí využívané v rôznych počtoch vrátane manažment nástrojov:

860

861

* CISCO2811-16TS

862

* ASR1000-ESP10, ASR1002-10G-SHA/K9

863

* C8500L-8S4X

864

* C9300-24T-E

865

* WS-C4900M, WS-C4948E, WS-C4948

866

* N7K-C7010, WS-C6509-E, VS-C6506E-SUP2T

867

* N5K-C5548UP, N2K-C2224TP-1GE, N9K-C93180YC-FX, N5K-C5010P-BF, N5K-C5672UP

868

* DS-C9148D-8G32P-K9, DS-C9148D-4G16P-K9, DS-C9124D-4G24P-K9

869

* WS-C3750X-24T-S, WS-C3560CG-8TC-S, WS-C3850X-48T-L

870

* 0024980000X24

871

* Zabbix

872

* IBM Umbrella monitoring

873

* Cisco Prime Infrastructure,

* Cisco DCNM,

\\

Ako bezpečnostné komponenty sú v prostredí využívané v rôznych počtoch vrátane manažment nástrojov:

879

880

* CSACS-1121-K9, CSACS-3415-K9

881

* ASA5585-S20X-K9, ASA5515-SSD120-K9,

882

* ASA5540-AIP40-K9

883

* Cisco ASA 5580, ASA5580-20, ASA5515X, ASA5505, ASA5516-FPWR-K9

884

* Cisco ASASM

885

* Cisco Security Manager

886

* FG-1800F, FG-601E, FG 301E

887

* M300/GPS/MQ

888

* NH2068, NH2047, NH2033

889

* F5-BIG-i10800-D, F5-BIG-i5800, F5-Big-IP i2600

* 8441-52X, 8436-52X

* HSM PCIe nShield

**~ **

Schému zapojenia/funkčnú schému a ďalšie prevádzkové/biznisové/architektúrne /bezpečnostné informácie nie je možné poskytnúť ich citlivosť ,a to z povahy prevádzkovaných dát.

**~ **

Nie je možné poskytnú detailnejšie technické parametre jednotlivých komponentov a to z dôvodu že tieto zariadenia už v súčasnosti disponujú zraniteľnosťami, ktoré by mohli byť v budúcnosti zneužité proti NCZI.

// //

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.4.2Požiadavkynavýkonnostnéparametre,kapacitnépožiadavky–TOBE"/}}4.4.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE ===

\\

Motiváciou implementácie projektu nie sú rastúce požiadavky na výkon v zmysle nárastu počtu používateľov, špičkového výkonu, transakcií či iných údajov v tabuľke nižšie.

910

911

(% class="wrapped" %)

|(((

**Parameter**

)))|(((

**Jednotky**

)))|(((

**Predpokladaná hodnota**

)))|(((

**Poznámka**

)))

|(((

Počet interných používateľov

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

|(((

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

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

|(((

Počet externých používateľov (internet)

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

|(((

Počet externých používateľov používajúcich systém v špičkovom zaťažení

)))|(((

Počet

)))|(((

Ostáva

\\

)))|(((

\\

)))

|(((

Počet transakcií (podaní, požiadaviek) za obdobie

)))|(((

Počet/obdobie

)))|(((

Ostáva

\\

)))|(((

\\

)))

|(((

Objem údajov na transakciu

)))|(((

Objem/transakcia

)))|(((

Ostáva

)))|(((

\\

)))

|(((

Objem existujúcich kmeňových dát

)))|(((

Objem

)))|(((

Ostáva

)))|(((

\\

)))

|(((

Ďalšie kapacitné a výkonové požiadavky ...

)))|(((

\\

)))|(((

Ostáva

)))|(((

\\

)))

\\

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.4.3Návrhriešeniatechnologickejarchitektúry"/}}4.4.3 Návrh riešenia technologickej architektúry ===

1001

1002

V sanovanom riešení bude zachovaná pôvodná architektúra, komponenty, procesy a bezpečnostné opatrenia, aby bol prechod na sanačné prostredie čo najmenej zložitý. To zabezpečí kontinuitu a minimalizuje riziká spojené s migráciou. Ako bolo uvedené a vyplýva z motivácie projektu, v súčasnom stave sú prevádzkované aj nepodporované verzie operačných systémov, databáz, platforiem, frameworkov, čo má pri riešení prevádzkovaných stavov malo neželaný procesný dopad. Preto sa počas sanácie, ako aj samotnej migrácie služieb bude vykonávať podrobné monitorovanie a reporting, aby boli včas identifikované problémy a následne sa zabezpečilo ich riešenie. Z uvedeného dôvodu je možné poskytnúť iba obmedzenú granularitu popisu zapojenia budúceho riešenia, aj to na vyžiadanie. Konrétne technologické prvky sú predmetom nacenenia projektu na karte HW a licencie v prílohe M-05 Analýza nákladov a prínosov (CBA).

1003

1004

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-Storage"/}}Storage ===

1005

1006

Pre oblasť storage infraštruktúry je zámerom vo veľkej miere využívať existujúce diskové kapacity sanovaných riešení a pre nové časti využiť softvérovo definovaného storage (SD storage).

1007

1008

V prostredí NZIS a JRUZ sú diskové polia nie staršie ako rok a bolo by finančne neefektívne nechať ich expirovať v procese výmeny prostredí. Zariadenia sú relatívne nové a hlavne sú s platným supportom výrobcu.

1009

1010

Nie je predpoklad, aby aplikačné komponenty presúvané do sanačných tenantov v novom prostredí mali diametrálne odlišné nároky na výkon alebo kapacitu oproti stavu, keď boli v pôvodnom riešení. Tým pádom takéto zdieľanie neohrozujú existujúce riešenia. Prípadný možný dočasný zvýšený nárok v čase migrácie aplikačných komponentov na nové prostredia po ich premigrovaní odpadá. Je možné túto vec ale mitigovať plánovaním migrácií. Oproti obstarávaniu nových storage sa jedná o obrovské šetrenie finančných zdrojov.

1011

1012

Dostupné produkčné diskové polia:

1013

1014

* Nové: HPE Alletra 6050, 2x HPE Alletra 6030 , HPE Alletra 6010, HPE Nimble HF40

1015

1016

Existujúce diskové polia navrhujeme vyzdieľať do nového prostredia podľa príslušnosti do jednotlivých tenantov:

1017

1018

* NZIS prod internal storage do NZIS prod Tenanta

1019

* NZIS prod perimeter storage do NZIS prod Tenanta

1020

* NZIS predprod storage do NZIS predprod Tenanta

1021

* JRUZ storage do JRUZ tenanta

1022

* Výnimka: NZIS prod backup storage by slúžil aj na zálohovanie celého nového prostredia. V prípade, ak sa ukáže potreba navýšenia kapacít v tomto poli, je určite lacnejšie riešiť to rozširovaním diskových políc s diskami, ako obstarávaním nového poľa. Jedná sa o cenovo najefektívnejšie riešenie.

1023

1024

Pre potvrdenie vyššie uvedených predpokladov je nutné ukončiť migráciu dát zo starých diskových polí na nové polia HPE Alletra a následne ešte vyhodnotiť dopad nových zmien plánovaných na nasadenie na prostredia. V prípade ak polia nebudú disponovať dostatočnými zdrojmi je možné ísť cestou ich upgradu alebo pre nové riešenie využiť concept SD storage.

**~ **

**Serverová infraštruktúra**

1029

1030

Pre oblasť serverovej infraštruktúry sú možné 3 rôzne smery riešenia:

1031

1032

* Infraštruktúra v podobe využitia standalone rackmount serverov

1033

* Infraštruktúra v podobe využitia Blade serverov

1034

* Infraštruktúra v podobe využitia HCI konceptu

1035

1036

Každý z týchto prístupov má svoje výhody a nevýhody. Ale na každom z nich je možné vystavať riešenie pre Sanačné prostredie. Rozdiel bude v tom, do akej miery dokáže dané riešenie podporiť všetky možnosti navrhovanej architektúry. Po zvážení požiadaviek, obmedzení a celkového návrhu pre sanačné prostredie navrhujeme HCI infraštruktúru, ktorá integruje výpočtový výkon, úložisko, virtualizačné zdroje a centrálnu správu do uceleného systému. Presný návrh serverovej infraštruktúry bude ale predmetom analýzy.

1037

1038

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-Sieťováinfraštruktúra"/}}Sieťová infraštruktúra ===

1039

1040

Pri návrhu sieťovej infraštruktúry si je potrebné vychádzať z požiadavky na veľkú mieru integrácie nového riešenia s pôvodnými riešeniami nasadenými na dostupných prostrediach.

1041

1042

Z pohľadu zdieľania komponentov s produkčným prostredím bude implementovaná obnova perimetra NZIS. Po jeho zrealizovaní bude tento perimeter slúžiť aj pre potreby sanačného prostredia a bude predstavovať vstupnú bránu do riešenia.

1043

1044

1045

Z dôvodu úzkej previazanosti na existujúce prostredia a nepridávania komplexity do správy prostredí je možné zachovať 2ks DC prepínačov Nexus Cisco, ktoré by plnili rolu kolabovaného spine/leaf. Z pohľadu škálovateľnosti je možné neskôr tieto 2 switche rozšíriť (napr.aj o existujúce zariadenia z NZIS prod internal). Reálne však táto potreba nebude ešte dlho aktuálna.

1046

1047

Týmto výberom bude zabezpečená bezproblémová interoperatibilita s existujúcimi riešeniami a vyhnutie sa problémom s nekompatibilitou, stabilitou riešenia, prípadne inou interpretáciou funkcionalít u rôznych vendorov. Taktiež nebude potrebné, aby bol prevádzkový tím vyškolený na ďalšiu technológiu..

1048

1049

Z pohľadu pripojenia serverovej infraštruktúry je preferované vytvoriť konvergovanú LAN a FC prevádzku, teda taktiež kontinuita konceptu zvoleného už aj v existujúcom riešení NZIS.

1050

1051

Pre zabezpečenie podpory flexibility sieťového prostredia s previazanosťou na návrh architektúry je preferované realizovať koncept softvérovo definovaného sieťového riešenia (SDN). Výber konkrétneho riešenia bude analýzy jednotlivých riešení z viacerých pohľadov akými sú napr.:

1052

1053

* Dostupné funkcionality

1054

* Udržateľnosť riešenia

1055

* Previazanie a integrácia na riešenie virtualizácie a iných častí riešenia

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.4.4Využívanieslužiebzkatalóguslužiebvládnehocloudu"/}}4.4.4 Využívanie služieb z katalógu služieb vládneho cloudu ===

1060

1061

Špecifické integrácie absolútne vylučujú možnosť umiestnenia sanačného prostredia mimo priestorov súčasného DC.

//__ __//

Na úrovni MIRRI SR a NCZI sa v mesiaci 05/24 uskutočnilo technické stretnute expertných skupín NCZI a MIRRI. Vykonala sa prezentácia súčasných prevádzkovaných systémov a služieb, architektúry, bezpečnosti prevádzkovaných prostredí NCZI (eZdravie, JRUZ, ISZI, ...) s cieľom detailnejšie oboznámiť zúčastnených expertov MIRRI SR. Otázky, ktoré vznikli v priebehu prezentácie boli zodpovedané na mieste expertami NCZI.

1066

1067

V súčasnosti sú vysúťažené nové projekty (RISEZ, OPE, životné situácie, ...), ktoré majú inovovať, rozširovať, alebo nahradiť niektoré komponenty systému eZdravia, ako aj iných informačných systémov mimo eZdravia. Po podpise zmlúv budú prebiehať technické stretnutia, s cieľom zadefinovať technické požiadavky na prostredie, ktoré bude v súlade s prijatou koncepciou. Hrozí riziko, že realizácia projektov bude pozdržaná z dôvodu absencie vhodnej infraštruktúry, architektúry a zavedených moderných procesov, čo je v kompetencií objednávateľa (NCZI).

1068

1069

Preto je nevyhnutné priorizovať vypracovanie akčného plánu, pokračovať v pracovných skupinách a revalidovať pripravované projekty tak, aby sa zabezpečila následná transformácia, modernizácia a presunutie nového eZdravia mimo sanované a sanačné prostredie.

1070

1071

Sanácia prostredia pomáha iba predchádzať výpadkom a kolapsu celého eZdravia, avšak všetky riziká spojené so zachovaním pôvodného nepodporovaného SW naprieč riešením zostávajú zachované.

1072

1073

Ako vyplýva zo zápisu stretnutia, expertné skupiny za účasti oddelenia architektúry MIRRI SR dospeli k záveru, že z vyššie uvedených dôvodov, ako aj z dôvodu detailnej technickej znalosti prostredia, odporúčajú expertné skupiny NCZI a MIRRI SR využitie delimitovaných rackových státí. Zároveň vybudovať sanačné preprodukčné a produkčné prostredie NZIS/eZdravie v priamej kompetencii súčasného prevádzkovateľa (NCZI) a zabezpečiť migráciu všetkých služieb eZravia do nové sanačného prostredia. Je nevyhnutné dôrazne zabezpečiť maximálnu mieru virtualizácie, ktorá bude úzko prepojená s existujúcimi prostrediami a poskytne priestor na postupné sanovanie existujúcich častí riešenia.

1074

1075

// [[image:attach:image-2024-9-10_23-41-56-1.png]]//

1076

1077

Náhľad - schéma prepojenia

1078

1079

== {{id name="projekt_2359_Pristup_k_projektu_detailny-4.5Bezpečnostnáarchitektúra"/}}4.5 Bezpečnostná architektúra ==

1080

1081

**Sieťová bezpečnosť - Perimeter**

1082

1083

V rámci efektívneho použitia použiteľnej aktuálnej infraštruktúry budú pôvodné a sanačné riešenie zdieľať pre tento účel rovnaké bezpečnostné a sieťové technológie, umiestnené v rámci Internet edge a WAN edge blokoch v pôvodnom prostredí.

1084

1085

Rovnako budú využité aj web aplikačné firewally F5 i10800 ASM v rámci arch. bloku Perimeter blok na ochranu perimetrových webových / API rozhraní aplikácií v oboch častiach prostredia.

1086

1087

V počiatočných fázach ostanú tieto bloky umiestnené v rámci pôvodného prostredia a zároveň budú využívané novým prostredím. Vo fáze, keď bude do nového prostredia premigrovaná kritická väčšina assetov, sa premigrujú / presunú do nového prostredia aj tieto bloky a následne budú analogicky využívané oboma časťami prostredia až do úplného zániku pôvodného prostredia.

1088

1089

[[image:attach:image-2024-9-10_23-40-55-1.png]]

1090

1091

Náhľad - prístup do nového prostredia - perimeter

1092

1093

**Sieťová bezpečnosť - IS to IS komunikácia

1094

**PROD: Pre komunikáciu vyžadujúcu zabezpečenie pomocou špecializovaných brán IBM DataPower Gateway (IDG), budú v prechodnom stave využité technológie v rámci architektonických blokov WAN Edge a Internal blok v pôvodnom riešení.

1095

1096

IBM DataPower zariadenia v clustroch sú v dvoch rôznych modeloch, z ktorých jeden má vyhlásené EoL. Výkonovo sú však oba modely dostatočné aj pre obsluhu nového prostredia. V počiatočných fázach ostanú tieto clustre umiestnené v rámci pôvodného prostredia a zároveň budú využívané novým prostredím nasledovne:

1097

1098

* Pre komunikáciu externých IS bude využitý cluster IDG vo WAN edge

1099

* Pre komunikáciu interných IS bude využitý IDG cluster v Internal block

1100

1101

Týmto spôsobom budú zároveň využívané v úvodných fázach aj interné sieťové firewally Cisco v rámci pôvodného riešenia.

1102

1103

V rámci nasledujúcich fáz budú IDG clustre virtualizované a presunuté do nového prostredia s využitím virtualizácie výpočtového výkonu aj sieťových zdrojov. Zariadenia bez podpory sa pri migrácii vymenia za novo zakúpené virtuálne zariadenia.

1104

1105

Sieťové firewally budú v novom prostredí virtualizované a integrované s platformou softvérovo definovanej siete. Z toho dôvodu bude nevyhnutné v rámci analýzy (a prípadne aj PoC) overiť výrobcu a konkrétny model integrovaných SW-definovaných NGFW.

1106

1107

PredPROD, TEST, JURZ: Použijú sa rovnaké koncepty a aj postup ako pri PROD prostredí. Prostredie TEST bude využité ako PoC pre migráciu do nového prostredia.

1108

1109

[[image:attach:image-2024-9-10_23-41-15-1.png]]

1110

1111

Náhľad - prístup do nového prostredia - IS to IS

**~ **

**~ **

**Bezpečnosť serverov, správa zraniteľností

1118

**V rámci bezpečnosti serverov sa dodrží aktuálna koncepcia bezpečnostných mechanizmov a technológií, ktoré budú v sanačnom prostredí nasadené v nových/aktuálnych verziách. Pre tieto technológie budú v rámci sanačného prostredia vybudované nové, aktuálne nástroje na ich správu.

1119

1120

PROD: Keďže sa v rámci pôvodného prostredia neobnovili licencie pre komponenty bezpečnosti serverov, v niektorých prípadoch bude potrebné zvoliť stratégiu, ako postupovať pri zabezpečovaní licencií pre nové prostredie:

1121

1122

alternatíva 1: doplatenie licencií v pôvodnej infraštruktúre, ktoré neboli pôvodne zakúpené v minulosti, následne bude výrobcom umožnené zakúpenie nových licencií pre nové prostredie (výrazne drahšie, zachovaná kontinuita technológie),

1123

1124

alternatíva 2: zmena danej technológie na alternatívnu (vrátane zváženia zmeny výrobcu), ktorá poskytuje bezpečnostné mechanizmy poskytované pôvodnou alternatívou (nie je kontinuita, potreba nabrať novú technológiu ale je príležitosť lepšie prispôsobiť novú technológiu zmenám v novom prostredí),

1125

1126

Tento problém už bol riešený pri niektorých CR a bude potrebné zakomponovať čiastkové alebo dočasné riešenia, ktoré pri tom vznikli.

1127

1128

Servery budú chránené podľa jednotlivých bodov v rámci Schém sanácie aplikácií nasledovne:

1129

1130

* S0 – bez zmeny, ponechanie na existujúcej infraštruktúre, ponechané pôvodné neaktuálne komponenty, správa pôvodným manažmentovým nástrojom,

1131

* S1 – ponechanie súčasnej platformy a nasadenie na sanované eZdravie - Ponechané pôvodné neaktuálne komponenty, správa pôvodným manažmentovým nástrojom

1132

* S2 – upgrade na novú platformu a nasadenie na sanované eZdravie - finálny stav v rámci sanácie, na novej platforme budú nasadené aktuálne verzie bezpečnostných komponentov, ktoré sa zaradia do nových nástrojov na správu, vybudovaných pre tento účel v sanačnom prostredí.

1133

1134

V rámci realizovania PoC bude potrebné aj overenie kompatibility nových bezpečnostných komponentov

1135

1136

Predpokladáme, že dočasné riešenia v rámci jednotlivých CR budú v konfigurácii „nová platforma, nové bezpečnostné komponenty, správa novými manažmentami v sanačnom prostredí“. Samotné aplikácie nemusia byť nevyhnutne sanované (presunuté do sanačného prostredia), preto je potrebné aby bola možnosť spravovať tieto bezpečnostné komponenty novým manažmentom zo sanačného prostredia.

1137

Pokiaľ budú v novom prostredí eZdravia servery v schéme S1, nebude možné odpojiť pôvodnú infraštruktúru, pôvodnú manažmentovú sieť a ani pôvodné manažmentové nástroje pre správu týchto technológií.

1138

1139

V pôvodnom prostredí nasadená správa zraniteľností bude nahradená službou monitorovania a správy zraniteľností, ktorú poskytuje NCZI SOC a pôvodné zariadenia budú vyradené z prevádzky.

1140

1141

PredPROD, TEST, JURZ: Použijú sa rovnaké koncepty a aj postup ako pri PROD prostredí. Prostredie TEST bude využité ako PoC pre migráciu do nového prostredia.

1142

1143

Pre prostredie PredPROD a TEST sa vybudujú separátne nástroje na správu, aby bolo možné testovať aj aktualizácie týchto nástrojov.

1144

1145

**Bezpečnosť aplikácií / HSM

1146

**V novom prostredí je plánované využiť v maximálnej možnej miere sieťové hardvérové bezpečnostné moduly (Hardware security module - HSM), ktorých služby bude možné využívať aplikáciami, bežiacimi vo virtualizovanom, softvérovo definovanom prostredí.

1147

V novom prostredí bude okrem šifrovania na aplikačnej úrovni použité aj transparentné šifrovanie s využitím HSM - na databázu „DB Z“ v zmysle Bezpečnostnej architektúry (dokument HLDSec, kde je táto databáza nazvaná RDBMS-Z).

1148

1149

Ak sa splnenie výkonnostných požiadaviek na HSM operácie bude ukazovať ako technicky nemožné alebo nerealizovateľné či výrazne neefektívne z hľadiska celkových nákladov, bude v krajnom prípade možné využiť interné HSM vo fyzických serveroch, ktoré bude možné zahrnúť do nového prostredia – toto ale nie je v žiadnom prípade odporúčané riešenie.

1150

1151

Možnosti prechodu na sieťové HSM a určenie ich výkonnostnej dostatočnosti budú musieť zrealizovať vývojári respektíve vlastníci jednotlivých aplikácií v rámci PoC. Nakoľko sa v rámci Fázy 1 nepočíta so zmenami na úrovni zdrojového kódu aplikácií, tak pokiaľ sa to ukáže ako nevyhnutnosť pri zmene výrobcu HSM, nebude možné v rámci Fázy 1 zmeniť výrobcu HSM, t.j. bude potrebné zostať pri produktoch nCipher.

1152

1153

V rámci návrhu využitia sieťových HSM v novom prostredí pre ďalšie fázy budú posúdené ich vlastnosti v oblasti bezpečnosti, výkonnosti, flexibility a škálovateľnosti, pričom bude zvažovaná aj zmena výrobcu. Bude však potrebné overiť aj kompatibilitu s aplikáciami a identifikovať prípadné potrebné zmeny v zdrojovom kóde.

\\

**Bezpečnosť kubernetes**

1158

1159

V súlade s Metodikou DevSecOps objednávateľa budú v rámci nových prostredí, podporujúcich cloud native technológie (kubernetes / k8s) použité mechanizmy na ochranu takýchto prostredí na viacerých úrovniach:

1160

1161

* na úrovni microservices (napr. ochrana kontajnerov / podov, ochrana serverless funkcií, aplikačná ochrana / WAF na úrovni ingress)

1162

* ochrana CI/CD – DevOPs prostredia (napr. kontrola / scanning obrazov (images), kontrola / scanning funkcií (functions), kontrola IAC) integrovaná v rámci CI/CD pipeline,

1163

* ochrana kubernetes infraštruktúry (napr. monitorovanie stavu k8s prostredia – Posture Management, threat intelligence, threat hunting)

1164

1165

Správa cloud native technológií bude poskytovaná ako SaaS služba v rámci cloudu.

1166

1167

**Bezpečnostný monitoring

1168

**Bezpečnosť sanačného prostredia bude monitorovaná prostredníctvom dedikovaného prostredia NCZI SOC.

1169

1170

Bude potrebná analýza NCZI SOC prostredia s ohľadom na licenčné a výkonnostné parametre. V prípade potreby bude nutné doplniť licencie alebo hardvér, potrebný na prenos bezpečnostných informácií zo sanačného prostredia do NCZI SOC, licencie a prípadný potrebný hardvér v rámci NCZI SOC.

1171

1172

= {{id name="projekt_2359_Pristup_k_projektu_detailny-5.ZávislostinaostatnéISVS/projekty"/}}5. Závislosti na ostatné ISVS / projekty =

1173

1174

Kapitola je nerelevantná, naplnenie KPI a cieľov projektu nie je závislé od iných ISVS a projektov rozvoja IT. Avšak naopak, rozvojové projekty NCZI a naplnenie ich cieľov je závislé na implementácii predkladaného projektu.

**~ **

= {{id name="projekt_2359_Pristup_k_projektu_detailny-6.Zdrojovékódy"/}}6. Zdrojové kódy =

1179

1180

Kapitola je nerelevantná, nakoľko sa jedná o HW projekt. Predmetom projektu sú úpravy na infraštruktúrnej a technologickej vrstve.

\\

= {{id name="projekt_2359_Pristup_k_projektu_detailny-7.Prevádzkaaúdržba"/}}7. Prevádzka a údržba =

1185

1186

== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.1Prevádzkovépožiadavky"/}}7.1 Prevádzkové požiadavky ==

1187

1188

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.1.1Úrovnepodporypoužívateľov"/}}7.1.1 Úrovne podpory používateľov ===

\\

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

\\

* ** L1 podpory IS** (Level 1, priamy kontakt zákazníka) – zabezpečuje Národné centrum zdravotníckych informácií

1197

* **L2 podpory IS** (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ).

1198

* **L3 podpory IS** (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).

\\

**__Definícia:__**

* **Podpora L1 (podpora 1. stupňa)** - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.

\\

* **Podpora L2 (podpora 2. stupňa)** – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.

\\

* **Podpora L3 (podpora 3. stupňa)** - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.1.2Riešenieincidentov–SLAparametre"/}}7.1.2 Riešenie incidentov – SLA parametre ===

\\

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.

\\

Označenie naliehavosti incidentu:

1225

1226

(% class="wrapped" %)

1227

|(((

1228

**Označenie naliehavosti incidentu**

1229

)))|(((

1230

**Závažnosť incidentu**

1231

)))|(((

1232

**Popis naliehavosti incidentu**

)))

|(((

**A**

)))|(((

**Kritická**

)))|(((

Je to vada spôsobená vážnou chybou a/alebo nedostatkom dodávanej softvérovej aplikácie, pričom táto chyba a/alebo nedostatok zabraňuje používaniu dodávanej softvérovej aplikácie. Nie je možné poskytnúť požadovaný výstup z IS.

)))

|(((

**B**

)))|(((

**Vysoká**

)))|(((

Je vada, spôsobená chybou a/alebo nedostatkom dodávanej softvérovej aplikácie, pričom táto chyba a/alebo nedostatok obmedzuje používanie dodávanej softvérovej aplikácie nasledovne:

1247

1248

Niektoré aplikačné funkcie (moduly, komponenty, objekty, programy) dodávanej softvérovej aplikácie nie sú funkčné alebo nie je umožnený prístup k niektorej aplikačnej funkcii (modulu, komponentu, objektu, programu) dodávanej softvérovej aplikácie

alebo

(ii) Nie je možné vykonať výber niektorých údajov alebo nie je možné vyhotoviť niektorý výstup z databázy údajov dodávanej softvérovej aplikácie alebo nie je možné vykonať prístup k niektorým údajom v databáze údajov dodávanej softvérovej aplikácie.

1253

1254

napr. tlač pomocných výstupov, zostavy, funkčnosť nesúvisiaca s vyrubením a pod.

)))

|(((

**C**

)))|(((

**Stredná**

)))|(((

Do tejto kategórie spadajú všetky chyby a/alebo nedostatky spojené s používaním dodávanej softvérovej aplikácie, ktoré nie sú klasifikované ako závažné alebo kritické vady, pričom však čiastočne obmedzujú používanie dodávanej softvérovej aplikácie a vyžadujú si:

1262

1263

Nastavenie parametrov systému Poskytovateľom alebo

1264

1265

(ii) Vzniknutá vada a/alebo nedostatok má za príčinu miernu nepohodlnosť pri práci so softvérovou aplikáciou, ktorá je však funkčná.

)))

|(((

**D**

)))|(((

**~ Nízka**

)))|(((

Kozmetické a drobné chyby.

)))

\\

možný dopad:

\\

(% class="wrapped" %)

1282

|(((

1283

**Označenie závažnosti incidentu**

)))|(((

**~ **

**Dopad**

)))|(((

**Popis dopadu**

)))

|(((

**1**

)))|(((

**katastrofický**

)))|(((

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

)))

|(((

**2**

)))|(((

**značný**

)))|(((

značný dopad alebo strata dát

)))

|(((

**3**

)))|(((

**malý**

)))|(((

malý dopad alebo strata dát

)))

**~ **

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

\\

(% class="wrapped" %)

1320

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

1321

**Matica priority incidentov**

1322

)))|(% colspan="3" %)(((

**Dopad**

)))

|(((

**Katastrofický - 1**

)))|(((

**Značný - 2**

)))|(((

**Malý - 3**

)))

|(% rowspan="3" %)(((

**Naliehavosť**

)))|(((

**Kritická - A**

)))|(((

1

)))|(((

2

)))|(((

3

)))

|(((

**Vysoká - B**

)))|(((

2

)))|(((

3

)))|(((

3

)))

|(((

**Stredná - C**

)))|(((

2

)))|(((

3

)))|(((

4

)))

**~ **

**Vyžadované reakčné doby:**

**~ **

(% class="wrapped" %)

1369

|(((

1370

**Označenie priority incidentu**

1371

)))|(((

1372

**Reakčná doba^^(1)^^ od nahlásenia incidentu po začiatok riešenia incidentu**

1373

)))|(((

1374

**Doba konečného vyriešenia incidentu od nahlásenia incidentu (DKVI) ^^(2)^^**

1375

)))|(((

1376

**Spoľahlivosť ^^(3)^^**

1377

1378

(počet incidentov za mesiac)

)))

|(((

**1**

)))|(((

0,5 hod.

)))|(((

4 hodín

)))|(((

1

)))

|(((

**2**

)))|(((

1 hod.

)))|(((

12 hodín

)))|(((

2

)))

|(((

**3**

)))|(((

1 hod.

)))|(((

24 hodín

)))|(((

10

)))

|(((

**4**

)))|(((

1 hod.

)))|(% colspan="2" %)(((

1412

Vyriešené a nasadené v rámci plánovaných releasov

)))

**~ **

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

1430

1431

1. a) Majú prioritu 3 a nižšiu

1432

1. b) Vzťahujú sa výhradne k dostupnosti testovacieho prostredia

1433

1. c) 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:

1438

1439

* Služby systémovej podpory na požiadanie (nad paušál)

1440

* Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)

1441

1442

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

\\

// //

== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.2PožadovanádostupnosťIS:"/}}7.2 Požadovaná dostupnosť IS: ==

**// //**

(% class="wrapped" %)

|(((

**Popis**

)))|(((

**Parameter**

)))|(((

**Poznámka**

)))

|(((

**Prevádzkové hodiny**

)))|(((

8 hodín

)))|(((

Po – Pia, 8:00 - 16:00

1466

)))

1467

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

**Servisné okno**

)))|(((

14 hodín

)))|(((

od 17:00 hod. - do 7:00 hod. počas pracovných dní

)))

|(((

24 hodín

)))|(((

od 00:00 hod. - 23:59 hod. počas dní pracovného pokoja a štátnych sviatkov Servis a údržba sa bude realizovať mimo pracovného času.

1478

)))

1479

|(((

1480

**Dostupnosť produkčného prostredia IS**

)))|(((

99,5%

)))|(((

· Vždy sa za takúto dobu považuje čas od 0.00 hod. do 23.59 hod. počas pracovných dní v týždni.

1485

1486

· Nedostupnosť IS sa počíta od nahlásenia incidentu Zákazníkom v čase dostupnosti podpory Poskytovateľa (t.j. nahlásenie incidentu na L3 v čase od 6:00 hod. - do 18:00 hod. počas pracovných dní). Do dostupnosti IS nie sú započítavané servisné okná a plánované odstávky IS.

1487

1488

· V prípade nedodržania dostupnosti IS bude každý ďalší začatý pracovný deň nedostupnosti braný ako deň omeškania bez odstránenia vady alebo incidentu.

)))

**// //**

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.2.1RTO(RecoveryTimeObjective)"/}}7.2.1 RTO (Recovery Time Objective) ===

1494

1495

V rámci projektu sa očakáva tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni.

// //

=== {{id name="projekt_2359_Pristup_k_projektu_detailny-7.2.2RPO(RecoveryPointObjective)"/}}7.2.2 RPO (Recovery Point Objective) ===

1500

1501

V rámci projektu sa očakáva tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni.

\\

= {{id name="projekt_2359_Pristup_k_projektu_detailny-8.Požiadavkynapersonál"/}}8. Požiadavky na personál =

// //

Projekt sa bude riadiť v súlade s platnou legislatívou v oblasti riadenia projektov IT. Pre potreby riadenia projektu bude vytvorený riadiaci výbor projektu a budú menovaní členovia Riadiaceho výboru projektu (ďalej len „RV“), projektový manažér a členovia projektového tímu. Zloženie a popis rolí je obsahom kapitoly 9. Projektového zámeru.

**~ **

= {{id name="projekt_2359_Pristup_k_projektu_detailny-9.Implementáciaapreberanievýstupovprojektu"/}}9. Implementácia a preberanie výstupov projektu =

1514

1515

Projekt bude v zmysle Vyhlášky 401/2023 Z.z. o projektovom riadení realizovaný metódou waterfall. V zmysle vyhlášky 401/2023 Z.z. o projektovom riadení je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov. V projekte je definovaný jeden inkrement na obdobie hlavných aktivít.

// //

= {{id name="projekt_2359_Pristup_k_projektu_detailny-10.Prílohy"/}}10. Prílohy =

1520

1521

**Príloha : **Zoznam rizík a závislostí (Excel): [[//https:~~/~~/www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html//>>url:https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html||shape="rect"]]

\\

Koniec dokumentu

\\

\\

// //

\\

\\

Wiki zdrojový kód pre pristup_k_projektu

Aplikácie

Navigácia

Tips

Moje posledné úpravy

Need help?