projekt_2359_Pristup_k_projektu_detailny

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.

112

113

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.

114

115

116

== {{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

504

* R – označenie požiadavky

505

* xx – číslo požiadavky

506

507

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

**NRxx**

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

512

* R – označenie požiadavky

513

* xx – číslo požiadavky

514

515

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

516

517

518

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

519

520

521

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.

522

523

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

524

525

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

526

527

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.

528

529

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.

530

531

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

532

533

1. Homogénnosť

534

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

535

1. Škálovateľnosť

536

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

537

1. Redundancia

538

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

539

1. Konektivita

540

Obnova a redesign perimetra pod kontrolou NCZI

541

1. Monitoring a centrálny logging

542

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

543

1. Zálohovanie a obnova dát

544

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

545

1. Automatizácia

546

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

547

1. DevSecOps

548

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

549

550

551

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

552

553

554

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.

555

556

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

557

558

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: ===

563

564

565

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

566

567

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

568

569

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

570

571

572

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

573

574

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

575

576

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

577

578

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.

579

580

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

581

582

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.

583

584

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

585

586

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

587

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

588

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

589

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

590

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

591

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

592

* 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

593

594

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.

595

596

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.

597

598

=== {{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 ===

599

600

601

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

602

603

(% class="wrapped" %)

604

|(((

605

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

620

621

//(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:

656

657

658

(% class="wrapped" %)

659

|(((

660

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

675

676

//(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 ===

707

708

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

709

710

711

=== {{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 ===

712

713

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

718

719

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

724

725

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

730

731

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

732

733

734

=== {{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 ===

735

736

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

737

738

739

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

740

741

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

742

743

744

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

745

746

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

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.3.2Dátovýrozsahprojektu-Prehľadobjektovevidencie-TOBE"/}}4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - 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.

755

756

757

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

758

759

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

760

761

==== {{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é ====

762

763

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

764

765

==== {{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 ====

766

767

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

768

769

770

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

771

772

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

773

774

==== {{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 ====

775

776

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

781

782

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

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.7Mojeúdaje"/}}4.3.7 Moje údaje ===

793

794

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

799

800

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

805

806

807

=== {{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"]]

812

813

814

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:

815

816

* Lenovo x3550 M4, Lenovo x3650 M4

817

* UCS C240 M3, UCS C240 M5SX, BE7000H

818

* IBM x3650 M3, IBM x3850 X5

819

* Huawei RH2288 v3, Huawei RH2288H v5

820

* Dell PowerEdge R430, Dell PowerEdge R730

821

822

823

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

824

825

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

826

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

827

* HP StoreEasy 1850

828

* Huawei OceanStor 2200 V3

829

* Backup - HPE Nimble HF40

830

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

831

832

833

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

834

835

* CISCO2811-16TS

836

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

837

* C8500L-8S4X

838

* C9300-24T-E

839

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

840

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

841

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

842

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

843

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

844

* 0024980000X24

845

* Zabbix

846

* IBM Umbrella monitoring

847

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

852

853

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

854

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

855

* ASA5540-AIP40-K9

856

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

857

* Cisco ASASM

858

* Cisco Security Manager

859

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

860

* M300/GPS/MQ

861

* NH2068, NH2047, NH2033

862

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

879

880

881

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.

882

883

(% 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 ===

972

973

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

974

975

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

976

977

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

978

979

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.

980

981

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.

982

983

Dostupné produkčné diskové polia:

984

985

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

986

987

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

988

989

* NZIS prod internal storage do NZIS prod Tenanta

990

* NZIS prod perimeter storage do NZIS prod Tenanta

991

* NZIS predprod storage do NZIS predprod Tenanta

992

* JRUZ storage do JRUZ tenanta

993

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

994

995

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

1000

1001

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

1002

1003

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

1004

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

1005

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

1006

1007

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.

1008

1009

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

1010

1011

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.

1012

1013

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.

1014

1015

1016

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.

1017

1018

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

1019

1020

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.

1021

1022

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

1023

1024

* Dostupné funkcionality

1025

* Udržateľnosť riešenia

1026

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

1031

1032

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

1037

1038

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

1039

1040

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.

1041

1042

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

1043

1044

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.

1045

1046

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

1047

1048

Náhľad - schéma prepojenia

1049

1050

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

1051

1052

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

1053

1054

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

1055

1056

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.

1057

1058

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.

1059

1060

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

1061

1062

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

1063

1064

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

1065

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

1066

1067

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:

1068

1069

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

1070

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

1071

1072

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.

1073

1074

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.

1075

1076

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.

1077

1078

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.

1079

1080

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

1081

1082

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

**~ **

**~ **

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

1089

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.

1090

1091

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:

1092

1093

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

1094

1095

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

1096

1097

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.

1098

1099

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

1100

1101

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

1102

* 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

1103

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

1104

1105

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

1106

1107

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.

1108

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

1109

1110

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.

1111

1112

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.

1113

1114

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.

1115

1116

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

1117

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

1118

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

1119

1120

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.

1121

1122

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.

1123

1124

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.

1125

1126

1127

**Bezpečnosť kubernetes**

1128

1129

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:

1130

1131

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

1132

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

1133

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

1134

1135

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

1136

1137

**Bezpečnostný monitoring**

1138

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

1139

1140

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.

1141

1142

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

1143

1144

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 =

1149

1150

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

1151

1152

1153

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

1154

1155

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

1156

1157

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

1158

1159

1160

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

1161

1162

1163

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

1164

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

1165

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

1171

1172

1173

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

1174

1175

1176

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

1181

1182

1183

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.

1184

1185

1186

Označenie naliehavosti incidentu:

1187

1188

(% class="wrapped" %)

1189

|(((

1190

**Označenie naliehavosti incidentu**

1191

)))|(((

1192

**Závažnosť incidentu**

1193

)))|(((

1194

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

1209

1210

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.

1215

1216

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:

1224

1225

Nastavenie parametrov systému Poskytovateľom alebo

1226

1227

(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" %)

1242

|(((

1243

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

1276

1277

1278

(% class="wrapped" %)

1279

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

1280

**Matica priority incidentov**

1281

)))|(% 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" %)

1328

|(((

1329

**Označenie priority incidentu**

1330

)))|(((

1331

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

1332

)))|(((

1333

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

1334

)))|(((

1335

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

1336

1337

(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" %)(((

1371

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.

1377

1378

1379

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

1380

1381

1382

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

1383

1384

1385

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

1386

1387

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

1388

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

1389

1. c) Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

1390

1391

1392

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

1393

1394

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

1395

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

1396

1397

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

1420

)))

1421

|(% 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.

1432

)))

1433

|(((

1434

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

1439

1440

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

1441

1442

· 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) ===

1448

1449

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

1454

1455

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

1456

1457

1458

= {{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 =

1467

1468

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 =

1473

1474

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