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.

109

110

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

**ID**

)))|(((

**SKRATKA**

)))|(((

**POPIS**

)))

(% class="" %)|(((

1.

)))|(((

API

)))|(((

Application programming interface

)))

(% class="" %)|(((

2.

)))|(((

BPMN

)))|(((

Business Process Model and Notation

)))

(% class="" %)|(((

3.

)))|(((

CSRÚ

)))|(((

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

)))

(% class="" %)|(((

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

)))

(% class="" %)|(((

5.

)))|(((

DMS

)))|(((

Document management system

)))

(% class="" %)|(((

6.

)))|(((

EDR

)))|(((

Endpoint Detection and Response

)))

(% class="" %)|(((

7.

)))|(((

ezdravie

)))|(((

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

)))

(% class="" %)|(((

8..

)))|(((

EÚ

)))|(((

Európska únia

)))

(% class="" %)|(((

9.

)))|(((

HW

)))|(((

Hardware

)))

(% class="" %)|(((

10.

)))|(((

HLD

)))|(((

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

)))

(% class="" %)|(((

11.

)))|(((

IaaS

)))|(((

Infrastructure as a service

)))

(% class="" %)|(((

12.

)))|(((

IAM

)))|(((

Identity and Access Management

)))

(% class="" %)|(((

13.

)))|(((

IKT

)))|(((

Informačno-komunikačné technológie

)))

(% class="" %)|(((

14.

)))|(((

IS

)))|(((

Informačný systém

)))

(% class="" %)|(((

15.

)))|(((

IS VS

)))|(((

Informačný systém verejnej správy

)))

(% class="" %)|(((

16.

)))|(((

ISZI

)))|(((

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

)))

(% class="" %)|(((

17.

)))|(((

JRÚZ

)))|(((

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

)))

(% class="" %)|(((

18.

)))|(((

KPI

)))|(((

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

)))

(% class="" %)|(((

19.

)))|(((

K+D

)))|(((

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

)))

(% class="" %)|(((

20.

)))|(((

LLD

)))|(((

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

)))

(% class="" %)|(((

21.

)))|(((

MDM

)))|(((

Mobile device management

)))

(% class="" %)|(((

22.

)))|(((

MIRRI

)))|(((

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

)))

(% class="" %)|(((

23.

)))|(((

MV SR

)))|(((

Ministerstvo vnútra SR

)))

(% class="" %)|(((

24.

)))|(((

MZ SR

)))|(((

Ministerstvo zdravotníctva Slovenskej republiky

)))

(% class="" %)|(((

25.

)))|(((

NCZI

)))|(((

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

)))

(% class="" %)|(((

26.

)))|(((

NKIVS

)))|(((

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

)))

(% class="" %)|(((

27.

)))|(((

NZIS

)))|(((

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

)))

(% class="" %)|(((

28.

)))|(((

OOÚ

)))|(((

Ochrana osobných údajov

)))

(% class="" %)|(((

29.

)))|(((

PO

)))|(((

Plán obnovy a odolnosti

)))

(% class="" %)|(((

30.

)))|(((

OVM

)))|(((

Orgán verejnej moci

)))

(% class="" %)|(((

31.

)))|(((

PaaS

)))|(((

Platform as a service

)))

(% class="" %)|(((

32.

)))|(((

PILOT

)))|(((

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

)))

(% class="" %)|(((

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

)))

(% class="" %)|(((

34.

)))|(((

PR

)))|(((

Projektové riadenie

)))

(% class="" %)|(((

35.

)))|(((

PrZS

)))|(((

Prijímateľ zdravotnej starostlivosti

)))

(% class="" %)|(((

36.

)))|(((

PZS

)))|(((

Poskytovateľ zdravotnej starostlivosti

)))

(% class="" %)|(((

37.

)))|(((

ROLLOUT

)))|(((

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

)))

(% class="" %)|(((

38.

)))|(((

RFO

)))|(((

Register fyzických osôb

)))

(% class="" %)|(((

39.

)))|(((

RPO

)))|(((

Register právnických osôb

)))

(% class="" %)|(((

40.

)))|(((

RÚVZ

)))|(((

Regionálne úrady verejného zdravotníctva

)))

(% class="" %)|(((

41.

)))|(((

SDL metodika

)))|(((

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

)))

(% class="" %)|(((

42.

)))|(((

SFTP

)))|(((

SSH File Transfer Protocol

)))

(% class="" %)|(((

43.

)))|(((

SLA

)))|(((

Service level agreement

)))

(% class="" %)|(((

44.

)))|(((

SOAP

)))|(((

Simple Object Access Protocol

)))

(% class="" %)|(((

45.

)))|(((

SOAR

)))|(((

Security orchestration, automation and response

)))

(% class="" %)|(((

46.

)))|(((

SR

)))|(((

Slovenská republika

)))

(% class="" %)|(((

47.

)))|(((

SW

)))|(((

Softvér

)))

(% class="" %)|(((

48.

)))|(((

ŠÚ SR

)))|(((

Štatistický úrad Slovenskej republiky

)))

(% class="" %)|(((

49.

)))|(((

ŠÚKL

)))|(((

Štátny ústav pre kontrolu liečiv

)))

(% class="" %)|(((

50.

)))|(((

ÚDZS

)))|(((

Úrad pre dohľad nad zdravotnou starostlivosťou

)))

(% class="" %)|(((

51.

)))|(((

VÚC

)))|(((

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

)))

(% class="" %)|(((

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

503

* R – označenie požiadavky

504

* xx – číslo požiadavky

505

506

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

**NRxx**

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

511

* R – označenie požiadavky

512

* xx – číslo požiadavky

513

514

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.

523

524

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

525

526

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

527

528

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.

529

530

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.

531

532

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

533

534

1. Homogénnosť

535

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

536

1. Škálovateľnosť

537

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

538

1. Redundancia

539

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

540

1. Konektivita

541

Obnova a redesign perimetra pod kontrolou NCZI

542

1. Monitoring a centrálny logging

543

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

544

1. Zálohovanie a obnova dát

545

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

546

1. Automatizácia

547

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

548

1. DevSecOps

549

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.

558

559

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

560

561

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.

570

571

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

572

573

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

578

579

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

580

581

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

582

583

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.

584

585

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

586

587

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.

588

589

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

590

591

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

592

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

593

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

594

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

595

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

596

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

597

* 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

598

599

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.

600

601

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.

602

603

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

608

609

(% class="" %)|(((

610

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

625

626

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

)))

(% class="" %)|(((

isvs_400

)))|(((

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

)))|(((

☐

)))|(((

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

)))|(((

agendový

)))|(((

\\

)))

(% class="" %)|(((

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

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

681

682

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

)))

(% class="" %)|(((

isvs_400

)))|(((

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

)))|(((

☐

)))|(((

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

)))|(((

agendový

)))|(((

\\

)))

(% class="" %)|(((

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

714

715

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

720

721

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

726

727

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

732

733

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

738

739

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

744

745

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

750

751

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

756

757

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

758

759

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

764

765

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

770

771

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

772

773

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

774

775

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

776

777

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

778

779

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

784

785

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

786

787

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

788

789

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

794

795

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

800

801

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

806

807

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

812

813

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:

830

831

* Lenovo x3550 M4, Lenovo x3650 M4

832

* UCS C240 M3, UCS C240 M5SX, BE7000H

833

* IBM x3650 M3, IBM x3850 X5

834

* Huawei RH2288 v3, Huawei RH2288H v5

835

* Dell PowerEdge R430, Dell PowerEdge R730

\\

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

840

841

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

842

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

843

* HP StoreEasy 1850

844

* Huawei OceanStor 2200 V3

845

* Backup - HPE Nimble HF40

846

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

851

852

* CISCO2811-16TS

853

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

854

* C8500L-8S4X

855

* C9300-24T-E

856

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

857

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

858

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

859

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

860

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

861

* 0024980000X24

862

* Zabbix

863

* IBM Umbrella monitoring

864

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

870

871

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

872

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

873

* ASA5540-AIP40-K9

874

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

875

* Cisco ASASM

876

* Cisco Security Manager

877

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

878

* M300/GPS/MQ

879

* NH2068, NH2047, NH2033

880

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

(% class="" %)|(((

**Parameter**

)))|(((

**Jednotky**

)))|(((

**Predpokladaná hodnota**

)))|(((

**Poznámka**

)))

(% class="" %)|(((

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

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

(% class="" %)|(((

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

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

(% class="" %)|(((

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

)))|(((

Počet

)))|(((

Ostáva

)))|(((

\\

)))

(% class="" %)|(((

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

)))|(((

Počet

)))|(((

Ostáva

\\

)))|(((

\\

)))

(% class="" %)|(((

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

)))|(((

Počet/obdobie

)))|(((

Ostáva

\\

)))|(((

\\

)))

(% class="" %)|(((

Objem údajov na transakciu

)))|(((

Objem/transakcia

)))|(((

Ostáva

)))|(((

\\

)))

(% class="" %)|(((

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

)))|(((

Objem

)))|(((

Ostáva

)))|(((

\\

)))

(% class="" %)|(((

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

991

992

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

993

994

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

995

996

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

997

998

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.

999

1000

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.

1001

1002

Dostupné produkčné diskové polia:

1003

1004

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

1005

1006

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

1007

1008

* NZIS prod internal storage do NZIS prod Tenanta

1009

* NZIS prod perimeter storage do NZIS prod Tenanta

1010

* NZIS predprod storage do NZIS predprod Tenanta

1011

* JRUZ storage do JRUZ tenanta

1012

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

1013

1014

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

1019

1020

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

1021

1022

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

1023

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

1024

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

1025

1026

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.

1027

1028

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

1029

1030

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.

1031

1032

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.

1033

1034

1035

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.

1036

1037

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

1038

1039

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.

1040

1041

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

1042

1043

* Dostupné funkcionality

1044

* Udržateľnosť riešenia

1045

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

1050

1051

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

1056

1057

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

1058

1059

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.

1060

1061

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

1062

1063

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.

1064

1065

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

1066

1067

Náhľad - schéma prepojenia

1068

1069

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

1070

1071

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

1072

1073

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

1074

1075

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.

1076

1077

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.

1078

1079

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

1080

1081

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

1082

1083

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

1084

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

1085

1086

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:

1087

1088

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

1089

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

1090

1091

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.

1092

1093

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.

1094

1095

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.

1096

1097

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.

1098

1099

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

1100

1101

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

**~ **

**~ **

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

1108

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

1109

1110

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:

1111

1112

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

1113

1114

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

1115

1116

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.

1117

1118

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

1119

1120

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

1121

* 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

1122

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

1123

1124

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

1125

1126

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.

1127

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

1128

1129

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.

1130

1131

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.

1132

1133

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.

1134

1135

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

1136

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

1137

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

1138

1139

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.

1140

1141

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.

1142

1143

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

1148

1149

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:

1150

1151

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

1152

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

1153

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

1154

1155

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

1156

1157

**Bezpečnostný monitoring

1158

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

1159

1160

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.

1161

1162

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

1163

1164

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 =

1169

1170

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 =

1175

1176

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

1177

1178

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

1187

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

1188

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

1215

1216

(% class="" %)|(((

1217

**Označenie naliehavosti incidentu**

1218

)))|(((

1219

**Závažnosť incidentu**

1220

)))|(((

1221

**Popis naliehavosti incidentu**

)))

(% class="" %)|(((

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

)))

(% class="" %)|(((

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

1236

1237

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.

1242

1243

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

)))

(% class="" %)|(((

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

1251

1252

Nastavenie parametrov systému Poskytovateľom alebo

1253

1254

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

)))

(% class="" %)|(((

**D**

)))|(((

**~ Nízka**

)))|(((

Kozmetické a drobné chyby.

)))

\\

možný dopad:

\\

(% class="" %)|(((

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

)))|(((

**~ **

**Dopad**

)))|(((

**Popis dopadu**

)))

(% class="" %)|(((

**1**

)))|(((

**katastrofický**

)))|(((

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

)))

(% class="" %)|(((

**2**

)))|(((

**značný**

)))|(((

značný dopad alebo strata dát

)))

(% class="" %)|(((

**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="" %)|(% colspan="2" rowspan="2" %)(((

1308

**Matica priority incidentov**

1309

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

**Dopad**

)))

(% class="" %)|(((

**Katastrofický - 1**

)))|(((

**Značný - 2**

)))|(((

**Malý - 3**

)))

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

**Naliehavosť**

)))|(((

**Kritická - A**

)))|(((

1

)))|(((

2

)))|(((

3

)))

(% class="" %)|(((

**Vysoká - B**

)))|(((

2

)))|(((

3

)))|(((

3

)))

(% class="" %)|(((

**Stredná - C**

)))|(((

2

)))|(((

3

)))|(((

4

)))

**~ **

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

**~ **

(% class="" %)|(((

**Označenie priority incidentu**

1357

)))|(((

1358

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

1359

)))|(((

1360

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

1361

)))|(((

1362

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

1363

1364

(počet incidentov za mesiac)

)))

(% class="" %)|(((

**1**

)))|(((

0,5 hod.

)))|(((

4 hodín

)))|(((

1

)))

(% class="" %)|(((

**2**

)))|(((

1 hod.

)))|(((

12 hodín

)))|(((

2

)))

(% class="" %)|(((

**3**

)))|(((

1 hod.

)))|(((

24 hodín

)))|(((

10

)))

(% class="" %)|(((

**4**

)))|(((

1 hod.

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

1398

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

1416

1417

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

1418

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

1419

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:

1424

1425

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

1426

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

1427

1428

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

**Popis**

)))|(((

**Parameter**

)))|(((

**Poznámka**

)))

(% class="" %)|(((

**Prevádzkové hodiny**

)))|(((

8 hodín

)))|(((

Po – Pia, 8:00 - 16:00

1451

)))

1452

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

**Servisné okno**

)))|(((

14 hodín

)))|(((

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

)))

(% class="" %)|(((

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.

1463

)))

1464

(% class="" %)|(((

1465

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

)))|(((

97%

)))|(((

· 97% z 24/7/365 t.j. max ročný výpadok je 10,95 dňa. Maximálny mesačný výpadok je 21,9 hodiny.

1470

1471

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

1472

1473

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

1474

1475

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

1481

1482

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

1487

1488

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 =

1501

1502

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 =

1507

1508

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

\\

\\