PRÍSTUP K PROJEKTU

 manažérsky výstup I-03

podľa vyhlášky MIRRI č. 401/2023 Z. z. 

Schvaľovanie dokumentu

1.    História dokumentu

2.    Účel dokumentu

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.

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.

2.1       Použité skratky a pojmy

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
• R – označenie požiadavky
• xx – číslo požiadavky

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

NRxx

• N – nefunkčná požiadavka (NFR)
• R – označenie požiadavky
• xx – číslo požiadavky

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

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.

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

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

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.

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.

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

1. Homogénnosť
   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
2. Škálovateľnosť
   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í.
3. Redundancia
   Sanácia datacentra bude navrhnuté tak, aby sa dalo v budúcnosti rozšíriť cez dve lokality
4. Konektivita
   Obnova a redesign perimetra pod kontrolou NCZI
5. Monitoring a centrálny logging
   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
6. Zálohovanie a obnova dát
   Obnova zálohovania a prechod z tape na disk to disk riešenia pre rýchlejšiu obnovu
7. Automatizácia
   Nastavenie automatizácia pre prideľovanie zdrojov a post install aktivít ako konfigurácia, patching, compliance a podobne
8. DevSecOps
   Zriadenie jednotnej platformy pre súčastné a budúce informačné systémy

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.

 4.1       Biznis vrstva

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.

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

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

4.1.2       Jazyková podpora a lokalizácia

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

4.2       Aplikačná vrstva

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

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

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.

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

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.

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

• 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)
• 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.
• 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,…)
• Zachovanie súčasného logického členenia architektúry
• 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)
• Aplikácie sanované v rámci produkčného prostredia, budú rovnako sanované na predprodukčnom prostredí
• 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

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.

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.

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

4.2.9       Konzumovanie údajov z IS CSRU – TO BE

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

4.3       Dátová vrstva

4.3.1       Údaje v správe organizácie

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

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

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

4.3.3       Referenčné údaje

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

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

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

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

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

4.3.4       Kvalita a čistenie údajov

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

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

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

4.3.5       Otvorené údaje

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

4.3.6       Analytické údaje

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

4.3.7       Moje údaje

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

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

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

4.4       Technologická vrstva

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

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:

• Lenovo x3550 M4, Lenovo x3650 M4
• UCS C240 M3, UCS C240 M5SX, BE7000H
• IBM x3650 M3, IBM x3850 X5
• Huawei RH2288 v3, Huawei RH2288H v5
• Dell PowerEdge R430, Dell PowerEdge R730

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

• HPE Alletra 6010, HPE Alletra 6030, HPE Alletra 6050
• HP 3PAR StoreServ 7200, HP 3PAR StoreServ 7400
• HP StoreEasy 1850
• Huawei OceanStor 2200 V3
• Backup - HPE Nimble HF40
• 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:

• CISCO2811-16TS
• ASR1000-ESP10, ASR1002-10G-SHA/K9
• C8500L-8S4X
• C9300-24T-E
• WS-C4900M, WS-C4948E, WS-C4948
• N7K-C7010, WS-C6509-E, VS-C6506E-SUP2T
• N5K-C5548UP, N2K-C2224TP-1GE, N9K-C93180YC-FX, N5K-C5010P-BF, N5K-C5672UP
• DS-C9148D-8G32P-K9, DS-C9148D-4G16P-K9, DS-C9124D-4G24P-K9
• WS-C3750X-24T-S, WS-C3560CG-8TC-S, WS-C3850X-48T-L
• 0024980000X24
• Zabbix
• IBM Umbrella monitoring
• 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:

• CSACS-1121-K9, CSACS-3415-K9
• ASA5585-S20X-K9, ASA5515-SSD120-K9,
• ASA5540-AIP40-K9
• Cisco ASA 5580, ASA5580-20, ASA5515X, ASA5505, ASA5516-FPWR-K9
• Cisco ASASM
• Cisco Security Manager
• FG-1800F, FG-601E, FG 301E
• M300/GPS/MQ
• NH2068, NH2047, NH2033
• 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.

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.

4.4.3       Návrh riešenia technologickej architektúry

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

Storage

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

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.

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.

Dostupné produkčné diskové polia:

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

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

• NZIS prod internal storage do NZIS prod Tenanta
• NZIS prod perimeter storage do NZIS prod Tenanta
• NZIS predprod storage do NZIS predprod Tenanta
• JRUZ storage do JRUZ tenanta
• 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.

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

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

• Infraštruktúra v podobe využitia standalone rackmount serverov
• Infraštruktúra v podobe využitia Blade serverov
• Infraštruktúra v podobe využitia HCI konceptu

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.

Sieťová infraštruktúra

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.

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.

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.

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

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.

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

• Dostupné funkcionality
• Udržateľnosť riešenia
• Previazanie a integrácia na riešenie virtualizácie a iných častí riešenia

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

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

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

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.

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

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.

Náhľad - schéma prepojenia

4.5       Bezpečnostná architektúra

Sieťová bezpečnosť - Perimeter

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

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.

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.

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

Sieťová bezpečnosť - IS to IS komunikácia
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í.

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:

• Pre komunikáciu externých IS bude využitý cluster IDG vo WAN edge
• Pre komunikáciu interných IS bude využitý IDG cluster v Internal block

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.

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.

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.

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.

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

Bezpečnosť serverov, správa zraniteľností
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.

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:

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

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

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.

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

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

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

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

 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.

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.

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.

Bezpečnosť aplikácií / HSM
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í.
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).

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.

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.

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

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:

• na úrovni microservices (napr. ochrana kontajnerov / podov, ochrana serverless funkcií, aplikačná ochrana / WAF na úrovni ingress)
• ochrana CI/CD – DevOPs prostredia (napr. kontrola / scanning obrazov (images), kontrola / scanning funkcií (functions), kontrola IAC) integrovaná v rámci CI/CD pipeline,
• ochrana kubernetes infraštruktúry (napr. monitorovanie stavu k8s prostredia – Posture Management, threat intelligence, threat hunting)

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

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

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.

5.    Závislosti na ostatné ISVS / projekty

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.

6.    Zdrojové kódy

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

7.    Prevádzka a údržba

7.1       Prevádzkové požiadavky

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í
• 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ľ).
• 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.

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:

možný dopad:

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

Vyžadované reakčné doby:

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

1. a) Majú prioritu 3 a nižšiu
2. b) Vzťahujú sa výhradne k dostupnosti testovacieho prostredia
3. 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:

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

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

7.2       Požadovaná dostupnosť IS:

7.2.1       RTO (Recovery Time Objective)

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

7.2.2       RPO (Recovery Point Objective)

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

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.

9.    Implementácia a preberanie výstupov projektu

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.

10. Prílohy

Príloha : Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html

Koniec dokumentu