I-03 Prístup k projektu (pristup_k_projektu)

PRÍSTUP K PROJEKTU

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

Schvaľovanie dokumentu

1. História dokumentu

2. Účel dokumentu

2.1 Použité skratky a pojmy

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

3. Popis navrhovaného riešenia

MPSVR prevádzkuje svoje informačné systémy v nasledovných lokalitách:

• dátové centrum MPSVR – toto dátové centrum je používané pre prevádzku bezpečnostných, komunikačných, archívnych a podporných systémov,
• dátové centrum prenajaté – je zmluvne poskytované treťou stranou spolu s infraštruktúrou a jej prevádzkou a bežia z neho kritické informačné systémy,
• privátna časť Vládneho cloudu IaaS1 na Kopčianskej ulici v Bratislave, v ktorom bežia niektoré nové systémy poskytujúce služby občanom,
• privátna časť Vládneho cloudu IaaS2 v Tajove, v ktorom beží jeden nové systémy poskytujúci služby občanom.

Koľko je aktuálne (k 31.8.2024) v ktorej lokalite prevádzkovaných IS je na nasledujúcom grafe:

Obrázok 1: počet ITVS prevádzkovaných v jednotlivých lokalitách

Pod informačným systémom ITVS, v dokumente rozumieme všetky IS definované v METAIS, ktoré nie sú zrušené alebo prevádzkované formou SaaS, plus spoločnú zdieľanú podpornú infraštruktúru. Počet serverov je na nasledujúcom obrázku:

Obrázok 2: počet serverov per lokalita

Celkovo má MPSVR 427 serverov, z toho 23 fyzických (okrem  virtualizačných serverov), 258 virtuálnych a 146 poskytovaných formou IaaS. Tri hlavné ITVS, najväčšie a úzko previazané, nad ktorými sú realizované zmeny preZS sú: DMS, RSD a ISSZ. MPSVR postupne pripravuje, alebo už realizuje, ich transformácii na cloudové ITVS avšak stále existuje viacero obmedzení, ktoré tomu v tomto v horizonte 3 rokov bránia. Hlavné sú:

• Použitím technológie zo začiatku storočia, konkrétne implementácie RMI-IIOP od IBM vo IBM WebSphere Application Server v8, je určujúca limitácia, že všetky komponenty, servery aj klientske stanice, musia byť v rovnakej sieti. Nie je možné použiť NAT alebo ipsec tunely nakoľko zvolená implementácia ich nepodporuje.
• Používajú sa fyzické hardvérové PCI HSM karty, ktoré nie je zatiaľ možné nahradiť softvérovým riešením.
• Z dôvodu úspory finančných prostriedkov sú virtuálne servery používajúce licenčný softvér od spoločností IBM a Oracle prevádzkované na špeciálnej oddelenej infraštruktúre tak, aby bola možná virtualizácia a v maximálnej miere sa využívali licencie, resp. vyťažil hardvér. Prechodom do cloudu by bolo potrebné dokúpiť licencie v značnom finančnom objeme preto MPSVR naštartovala v dotknutých IS zmenu týchto softvérov na open source verzie.
• Veľký objem uložených dokumentov, nakoľko dlhé roky časť úkonov na úrade práce potrebovalo písomné potvrdenia, ktoré sa skenovali a ukladali do DMS, kde zatiaľ nie je prevádzkovaný archivačný systém. Celkový objem dát je 385 TB a záloh 1,3 PB.

Kritické systémy bežia na vypožičanej infraštruktúre od externého dodávateľa, ktorá zahŕňa jej umiestnenej v prenajatom dátovom centre, pripojenie do internej sieti a prevádzku. Táto situácia, vendor lock-in, limituje rozvoj a zabezpečenie infraštruktúry pre ITVS poskytujúce základné služby rezortu. Kvôli tomuto obmedzeniu nie je možné ani zrealizovať zabezpečenie kontinuity prevádzky.  

Kritické systémy prevádzkované na vypožičanej infraštruktúre sú kľúčové pre plnenie úloh MPSVR. Z 12 základných služieb je na nich prevádzkovaných 8, plus pre 2 ďalšie ISVS sú v nej prevádzkované backend komponenty, úzko previazané so základnými službami. Ide o ISVS pre riadenie sociálnych dávok, služieb zamestnanosti, register klientov, centrálny IDM, podporu detských domov a DMS. Produkčné prostredia týchto systémov budú migrované od externého poskytovateľa do DC1. Ostatné prostredia do DC2. V prípade výpadku niektorej lokality (okrem DC2) budú prostredia v DC2 výkonovo utlmené a na ich mieste spustené ISVS z dotknutej lokality.

Cieľová architektúra MPSVR počíta v strednodobom horizonte s umiestnením všetky IS do cloudových prostredí a s vybudovaním druhej dostupnej lokality v dátovom centre MPSVR. Primárne v nej budú bezpečnostné, manažovacie, podporné systémy a kópie záloh dát ITVS z ostatných lokalít. MPSVR predpokladá, že tento stav plnohodnotne dosiahne po roku 2028. Navrhovaná aktuálna architektúra preto predpokladá prevádzku IS v cloudových prostrediach a prevádzku infraštruktúry v dvoch lokálnych dátových centrách.

Obrázok 3: návrh rozmiestnenia infraštruktúry v dátových centrách

Microsoft Offie 365 je v architektúre uvedený zámerne. MPSVR začína používať aplikácie vybudované nad prostriedkami (Power Apps) poskytovanými týmto cloudovým prostredím. Platforma SharePoint Online je plánovaná ako cieľová platforma pre niektoré aplikácie postavené nad klasickým SharePoint riešením.

Zabezpečenie vysokej dostupnosti vníma MPSVR v dvoch rovinách: minimalizácia výpadkov komponentov IS použitím štandardných virtualizačných a klastrových technológií v rámci lokality a zabezpečenie pokračovania prevádzky aj v prípade výpadku jedného cloudových prostredí alebo lokálneho dátového centra. Kritické ITVS sú vybudované tak, aby boli v rámci lokality odolné voči výpadku jedného fyzického komponentu. Na výpadok lokality však pripravené nie sú. Nevyhovujúce zabezpečenie kontinuity prevádzky bolo aj súčasťou nálezov auditov kybernetickej bezpečnosti.

Zabezpečenie dostupnosti v rámci lokality nebudeme podrobnejšie popisovať. Je dosiahnuté použitím štandardných technológií. Aj pre jej zabezpečenie medzi lokalitami je navrhované použiť v maximálne možnej miere štandardné technológie. V niektorých prípadoch, napr. ITVS umiestnené vo Vládnom cloude sú však možnosti limitované.

Medzi lokalitami budú využité nasledovné štandardné technológie:

• automatické preklápanie sieťovej komunikácie s ohľadom na dostupnosť služieb,
• replikácia dát na úrovni virtualizovaného prostredia,
• replikácia dát na úrovni databáz,
• replikácia dát na úrovni diskových polí,
• zabezpečenie kontajnerizačnej platformy,
• obnova dát zo záloh.

Navrhované riešenia sa snažia v maximálne možnej miere využívať vlastnosti technológie v zabezpečení replikácie, zálohy, kopírovania dát medzi lokalitami.

4. Architektúra riešenia projektu

4.1 Biznis vrstva

Biznis vrstva sa plánovanými zmenami nemení.

4.2 Aplikačná vrstva

Aplikačná vrstva sa plánovanými zmenami nemení. Pre niektoré ITVS bude upravený model nasadenia zohľadňujúci riešenie zabezpečenia kontinuity prevádzky ale tieto zmeny sú minimálne a nemajú vplyv na aplikačnú funkcionalitu ako takú.

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

Prevádzky nasledovných informačných systémov uvedených v nasledujúcej tabuľke bude dotknutá realizáciou projektu, a to buď ich zlepšením ich výkonu alebo kapacity migráciou na novú cieľovú infraštruktúru alebo zvýšením ich dostupnosti touto infraštruktúrou alebo vybudovaním riešenia kontinuity ich prevádzky:

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

Identický so súčasným stavom.

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

Využívanie nadrezortných a spoločných ISVS týmto projektom nie je menené. Služby poskytované jednotlivými ISVS sú publikované pomocou WAF cez sieť GOVNET. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity je z pohľadu nadrezortných a spoločných OSVS transparentná, tzn. nemá dopad na spôsob ich publikovania.

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

Využívanie nadrezortných a spoločných ISVS týmto projektom nie je menené. Služby poskytované jednotlivými ISVS sú publikované pomocou WAF cez sieť GOVNET. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity je z pohľadu nadrezortných a spoločných OSVS transparentná, tzn. nemá dopad na spôsob ich publikovania.

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

Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši dostupnosť integračnej platformy MPSVR, ale nemení existujúce integrácie.

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

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity nezavádza nové aplikačné služby.

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

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity nezavádza nové aplikačné služby.

4.2.8 Poskytovanie údajov z ISVS do IS CPDI – TO BE

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši dostupnosť integračnej platformy MPSVR, ale nemení existujúce integrácie ani poskytovanie údajov z existujúcich ISVS do IS CPDI.

4.2.9 Konzumovanie údajov z IS CPDI – TO BE

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši dostupnosť integračnej platformy MPSVR, ale nemení existujúce integrácie ani konzumovanie údajov z IS CPDI.

4.3 Dátová vrstva

Dátová vrstva je identická so súčasným stavom. Implementáciou projektu sa nemení.

4.3.1 Údaje v správe organizácie

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

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

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.3.3 Referenčné údaje

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.3.4 Kvalita a čistenie údajov

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.3.5 Otvorené údaje

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.3.6 Analytické údaje

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.3.7 Moje údaje

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

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

Týmto projektom nie je menené. Obmena HW komponentov a konfigurácia zabezpečenia kontinuity zvýši zabezpečenie a dostupnosť diskových polí a databáz, v ktorých sú údaje uložené ale nemení ich formát, technológiu uloženia ani prístup k nim.

4.4 Technologická vrstva

4.4.1 Prehľad technologického stavu - AS IS

V infraštruktúre sa celkovo používajú nasledovné technológie:

• fyzické servery s architektúrou procesorov x86, x64 a IBM Power
• VMware vSphere 7
• operačné systémy Windows Server 2008 R2 a novšie, Linux 6 a novšie
• Microsoft SQL Server 2012 a novšie
• Oracle Database 19c
• PstgreSQL 11 a novšie
• IBM WebSphere Application Server Network Deployment 8.5.5
• Red Hat JBoss 7 a Red Hat WildFly 11 a novšie
• IBM Cognos Business Intelligence 10.2
• Red Hat OpenShift 4

4.4.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

V nasledujúcej tabuľke sú predpokladané parametre pre ŽS:

Pri návrhu výkonu a kapacity sa vychádzalo zo súčasného stavu nakoľko modifikácia súčasných systémov, resp. prechod z manuálnych činností na automatizované, zásadne nezmení mieru ich vyťaženia.

MPSVR plánuje infraštruktúru v lokálnych dátových centrách minimalizovať, ale v tomto momente sa nevie zatiaľ vyhnúť jej potrebe. Cieľovým stavom v krátkodobom horizonte je preto hybridná infraštruktúra, skladajúca sa z viacerých Vládnych cloudov a dvoch lokálnych dátových centier, označovaných v tomto dokumente ako DC1 a DC2.

Informačné systému sú prevádzkované vo Verejných cloudoch a DC1. DC2 má dve úlohy:

1. poskytuje pre produkčné prostredia IS vo VC a DC1 dostatočný výkon a kapacitu pre prevádzku v prípade zlyhania niektorého z primárnych centier,
2. poskytuje dostatočný výkon a kapacitu pre mnohé používané systémy pre správu a bezpečnosť infraštruktúry, primárne koncových staníc a užívateľov.

Principiálne by väčšina systémov z bodu 2 mohla ležať aj vo Vládnom cloude ale z podstaty svojej činnosti narábajú s väčšími objemami dát, ktoré distribuujú užívateľom, majú špecifické požiadavky na sieťové linky a je odporúčané ich prevádzkovať na rovnakej vysoko priepustnej privátnej sieti ako sú koncové zariadenia užívateľov.

V zmysle plánov koncepcie uvažovanej MPSVR, DC1 po presťahovaní všetkých IS do cloudového prostredia časom zanikne. Predbežne sa s tým počíta niekedy po roku 2028. Aby bola infraštruktúra v DC1 čo najmenšia, architektúra riešenia počíta s tým, že bude obsahovať len produkčné prostredia IS, ktoré zatiaľ nemôžu alebo s ešte len transformujú do cloudového prostredia. Testovacie prostredia budú umiestnené v DC2 a v prípade potreby, resp. výpadku niektorého z cloudou alebo DC1, budú automaticky prednastavenými prioritami obmedzené tak, aby bola z DC2 možná plnohodnotná prevádzka produkčných prostredí.

4.4.2.1 Výkon a kapacita infraštruktúry DC1

V DC1 musí byť prevádzkované to, čo je dnes pre IS poskytované v produkčných prostrediach externého poskytovateľa prevádzky a MPSVR. Plus potrebná zdieľaná infraštruktúra ako Active Directory kontroléri, monitoring a pod. Pre nárast výkonu a kapacity v najbližších rokoch odhadujeme nasledovné pravidlá:

• potrebný výkon cpu bude rásť najbližšie 3 roky o 5% a potom, vďaka postupnej migrácii IS do cloudov, bude postačovať na ďalšie 3 roky,
• potrebná kapacita pamäte bude rásť najbližšie 3 roky o 5% a potom, vďaka postupnej migrácii IS do cloudov, bude postačovať na ďalšie 3 roky,
• potrebná kapacita diskového priestoru bude rásť najbližšie 3 roky o 10% a potom, vďaka postupnej migrácii IS do cloudov, bude postačovať na ďalšie 3 roky.

Predpokladá sa, že spoločná infraštruktúra v DC1 bude veľmi podobná dnešnej prevádzkovanej u externého poskytovateľa prevádzky. V sumáre je potom možné definovať nároky nasledovne:

Tieto údaje sú kumulované z rôznych typov výkonu. Zároveň existuje niekoľko limitácií:

• odporúčaná architektúra poštového systému je iná, kapacitne náročnejšia, ako dnes prevádzkovaná,
• je nutné dodržať licenčné obmedzenia vyplývajúce z použitého softvéru od spoločnosti IBM, Microsoft a Oracle,
• aplikačné a databázové servery DMS požadujú vysoký výkon a špecifické kapacity.

Sumárny pohľadu uvedený v tabuľke vyššie je preto nedostatočný. V architektúre sa počíta pre systémy s nasledovnými typmi serverov:

• virtualizačné, alebo hyper-konvergované servery pre moderné aplikácie,
• virtualizačné, alebo hyper-konvergované servery pre legacy aplikácie,
• virtualizačné servery spĺňajúci licenčné podmienky IBM,
• virtualizačné servery spĺňajúci licenčné podmienky Oracle,
• server pre MS Exchange,
• zálohovací server,
• analytický server.

V nasledujúcej tabuľke je počet typov serverov, počet ich jadier a prepočet podľa oversubsription parametra na výsledný počet zahŕňajúcich jadier:

V ideálnom prípade by vyťaženosť v bežnej prevádzke mala byť 80%, tzn. malo by byť vyťažených 1 062 jadier, čo pasuje so spočítanými požiadavkami. A pre definované typy serverov a ich počet je v nasledujúcej tabuľke predpokladaná veľkosť pamäte, pričom je pre jednotlivý typ servera definované HA, tzn. koľko serverov môže zlyhať aby stále bolo dostatok pamäte:

Server by mal mať v bežnej prevádzke ideálne zaplnenú pamäť na 80%, takže celková veľkosť pamäte je 11,6TB. V konfigurácii je vyššie kapacita z dôvodu, že aktuálne je ešte 116 server s operačným systémom starším ako Windows Server 2016, s celkovou kapacitou 3,75 TB. Prechodom na novší operačný systém sa bude musieť ich pamäť zvýšiť z dôvodu systémových požiadaviek v priemer o 50%, čo vychádza následne celková pamäť na 11,8 TB s rezervou pri 80% vyťažení.

Potrebná disková kapacita je definovaná v tabuľke vyššie. V prostredí MPSVR sa používajú 3 druhy diskových priestorov (kedysi to boli aj samostatné diskové polia, dnes sú to už len fyzickými diskami oddelené skupiny):

• A = rýchle disky, prezentované SSD diskami, na ktorých ležia databázy a zdieľané súborové systémy ktoré potrebujú rýchle IO (vyrovnávacie diskové cache),
• B = bežné disky, na ktorých ležia operačné systémy, súborové systémy a pod,
• C = veľké a pomalé disky, na ktorých primárne ležia dokumenty DMS a zálohy.

V architektúre bola prezentovaná snaha čo najviac sa priblížiť ku cloudovej koncepcii softvérovo definovaného dátového centra. Disky pre operačné systémy a v skupine B, v objeme 24TB budú realizovaná ako softvérovo definované úložisko na virtualizovaných serveroch (HCI). Skupina A, rýchle disky, bude pre databázy a je v objeme 61TB. Bude poskytovaná z dôvodu výkonu samostatným diskovým poľom. Skupina C, pomalé a veľké disky má objem 467TB. Bude tiež poskytovaná samostatným diskovým poľom. Hlavný dôvod je cena, nakoľko spojením diskových priestorov skupiny A a C do jedného diskového poľa automaticky implikuje požiadavku na diskové pole triedy Enterprise.

4.4.2.2 Výkon a kapacita infraštruktúry DC2

Pre DC2 platia závery a obmedzenia uvedené v predchádzajúcej kapitole. Bude obsahovať aktuálny výkon a kapacitu dnes bežiacich spoločných komponentov v dátovom centre MPSVR a výkon a kapacitu pre všetky neprodukčné prostredia z infraštruktúry u externého poskytovateľa prevádzky a dátového centra MPSVR.

Oproti DC1 môžeme brať pri testovacích prostrediach oversubscription 6:1, čo pri povinnom minimálne počet serverov znamená 1 HCI Server - bežná prevádzka navyše. Oproti DC1. Celkový procesorový výkon bude nasledovný:

Pri pamäti je situácia v oboch prípadoch rovnaká, a výsledné požiadavky sú v nasledujúcej tabuľke.

V neprodukčných prostrediach sa používajú orezané vzorky dát a preto požadované výsledné kapacity nie sú oveľa vyššie ako v prípade DC1. V nasledujúcej tabuľke sú celkové hodnoty a ich umiestnenie:

• A – samostatné diskové pole s kapacitou 83 TB,
• disky operačných systémov a skupina B – 52 TB vytvorené na softvérovo definovanom diskovom priestore na virtualizačných serveroch,
• C – samostatné diskové pole s kapacitou 467 TB.

4.4.3 Návrh riešenia technologickej architektúry

Koncepcia sietí a ich ochrany v rámci projektu je založená na štandardnom modeli perimetrovej, servisnej a internej vrstve. Z dôvodu zvýšenia bezpečnosti na jednej strane, a minimalistického počtu serverov na druhej strane je v štandardnom návrhu koncepcie niekoľko zmien. Celkovú koncepciu je možné vidieť na nasledovnom obrázku:

Obrázok 4: koncepcia sietí s dátovými tokmi

Zahŕňa dve dátové centrá, všetky vrstvy, pripojenie na externých partnerov, ale nezahŕňa manažment sieť (bude uvedené neskôr). Na úrovni perimetra je dvojica firewallov. Pripojenia tretích strán (GOVNET, SOCNET, FINNET, ...) sú ukončené priamo na firewalloch. Celková použiteľná priepustnosť prepojov na externé strany je odhadovaná na 24Gbps, čo udáva aj požadovanú kombinovanú priepustnosť perimeter firewallu. Tento tok dát bude na perimeter firewalle kontrolovaný podľa svojho smeru a zdroja bezpečnostnými nástrojmi firewallu, ako sú ips/ids, antivírus, antimalvér, url filtrovanie a pod.

V predkladanom projekte je zahrnutá len sieťová infraštruktúra v jednom dátovom centre. Infraštruktúra v druhom dátovom centre čiastočne existuje a čiastočne sa aktuálne obstaráva v rámci iného projektu.

Technologická architektúra počíta v maximálne možnej miere s virtualizáciou aj dnes fyzických serverov. Základom sú bežné hyper-konvergované servery, ktoré majú všetky časti (cpu, pamäť, sieť, disky) softvérovo virtualizované. 95% operačných systémov bude prevádzkovaných na týchto serveroch.

Druhou skupinou serverov sú tiež hyper-konvergované servery, v ktorých pobežia operačné systémy vyžadujúce si vysoký procesorový výkon, pamäť a diskový priestor z externého diskového poľa. Ide prevažne o produkčné aplikačné a databázové servery DMS.

Treťou skupinou sú servery, ktoré musia byť z licenčného hľadiska použitého softvéru (IBM, Oracle) izolované a musia mať z licenčného pohľadu špecifickú virtualizáciu.

Ďalej sú samostatné servery, v jednotkách kusov, ktoré z logiky svojej prevádzky musia byť oddelené:

• server pre zálohovanie uchovávajúci zálohované údaje,
• server pre DWH, kde prevádzka podlieha veľkým výkonnostným výkyvom, ktoré nie sú predikovateľné.

Sieťová infraštruktúra je minimalistická, počíta s rozšírením maximálne o 20%. Použité sú bežné prepínače bez špeciálnych vlastností až na 4 ks prepínačov pre HCI, ktoré tvoria so servermi ucelené centrálne manažované riešenie, vrátane plošných aktualizácií kódov. Súčasťou sieťovej infraštruktúry je aj dvojica loadbalancerov, ktoré sú kľúčové pre zabezpečenie vysokej dostupnosti. Majú modul dynamického DNS servera, navzájom sa synchronizujú a publikujú okolitému svetu, v ktorom dátovom centre alebo cloude práve požadované služby bežia. Sieťovú infraštruktúru dopĺňa dvojica firewallov, ktorá obsahuje v sebe všetky bezpečnostné prvky v zmysle kybernetického zákona, vrátane kontroly komunikácie na malvéri, ransomveri a iné kybernetické hrozby.

Diskový priestor pre 90% serverov je softvérovo definovaný v rámci HCI. V riešení sú 3 samostatné diskové polia. Porovnaním toto riešenie vyšlo ako cenovo najvýhodnejšie. Principiálne, diskové pole pre zálohy musí byť oddelené od ostatných zariadení, na ktorom sú samotné dáta. Toto diskové pole bude slúžiť ako capacity tier pre zálohy, pričom hot tier bude umiestnený v samotnom zálohovacom servery. Diskové pole bude podporovať immutability uložených záloh, tzn. ich neprepisovateľnosť a odolnosť voči útokom. Druhé dve diskové polia sú svojimi nárokmi úplne odlišné a preto sú oddelené. Prvé je pre databázy, ktoré už dnes sú prevádzkované na SSD diskoch a majú požiadavky na vysokú priepustnosť a nízku odozvu. Posledné diskové pole je naopak, archív pre dokumenty, kde je podstatná vysoká kapacita 95% priestoru a menej rýchosť. Len zvyšných 5%, prvé 3 mesiace životnosti dokumentu, je potrebný priestor na rýchlych diskoch.

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

Konkrétne cloudové služby Vládneho cloudu pre modulárne mikrolužby rozširujúce bakendové systémy budú špecifikované až vo fáze dizajnu implementácie ŽS.

4.5. Bezpečnostná architektúra

MPSVR má v zmysle kybernetického zákona uvedené do praxe príslušné interné predpisy. V navrhovanej infraštruktúre sú zariadenia určené na perimetrovú bezpečnosť, vrátane potrebných subskripcií pre zvýšenú ochranu webového prístupu k IS a prevenciu proti vírusom, malvérom a ransamvérom. Špecifikované zariadenie posunie aktuálnu bezpečnosť na novú úroveň.

V aktuálnom prostredí je už niekoľko rokov zrealizovaná podrobná segmentácia siete. Každá vrstva každého IS je v samostatných virtuálnych sieťach a prestup medzi týmito sieťami je povolený len z konkrétnej IP adresy a portu na konkrétnu IP adresu a port. Realizácia trvala 2 roky a je zdokumentovaná v zmysle definovaných pravidiel na firewalloch. Bude prenesená do novej infraštruktúry.

V aktuálnom prostredí je riešenie manažmentu zraniteľnosti od spoločnosti Qualys. Pravidelne sa nálezy a rizikovosti vyhodnocujú a na mesačnej báze sú systémy aktualizované (z dôvodu konfliktu s aplikačnými nasadzovaniami sú niektoré mesačné termíny vynechané). Manažment zraniteľností sa poskytuje pre fyzické zariadenia, manažment karty, virtualizáciu, operačné systémy a štandardný softvér.

V aktuálnom prostredí prebieha postupný hardening operačných systémov. Z dôvodu čo najmenších dopadov na dostupnosť a nízke náklady, prebieha hardening všetkých nových serverov. Hardening je následne kontrolovaný automatizované nástrojmi manažmentu zraniteľnosti voči CIS benchmarkom. Akceptované skóre je minimálne 90% a je sada akceptovaných nesúladov s CIS benchmarkom. Väčšinou z dôvodu dostatočného nastavenia v zmysle interných smerníc (napr. pravidlá tvaru hesiel).

V aktuálnom prostredí je ako prevencia pred vírusmi, malvérmi a ransamvérom nasadená kombinácia produktov ESET antivírus s Qualys EDR. Táto, spolu s manažmentom zraniteľností a hardeningom budú plne nasadené aj v novej infraštruktúre.

Oproti predchádzajúcemu, nanovo vybudované bude zálohovanie. Aktuálna implementácia je z roku 2009 a je vlastnostiam už chýbajú základné veci dnešnej doby ako záloha kontajnerov, neprepisovateľné zálohy alebo verifikácia záloh voči vírusom. Všetky potrebné komponenty sú zahrnuté v projekte.

Implementáciou predkladaného projektu sa bezpečnostná architektúra nemení, v niektorých oblastiach rozširuje. Softvérové licencie dnes používaných bezpečnostných nástrojov pokrývajú celé prostredie a budú zmigrované na novú infraštruktúru, resp. sú viazané s migrovanými virtuálnymi servermi.

5. Závislosti na ostatné ISVS / projekty

N/A

6. Zdrojové kódy

Štandardnou požiadavkou MPSVR je aby všetky zdrojové kódy, vrátane nasadzovacích a provizionovacích skriptov boli uložené v Centrálnom repozitári zdrojových kódov MPSVR.

7. Prevádzka a údržba

• Súčasťou špecifikácií zariadení a softvéru je požadovaná pravidelná údržba (kontrola, aktualizácie). Táto bola špecifikovaná per typ zariadenia. Takisto boli per typ a rolu zariadenia požadované aj servisné SLA.

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) - jednotný kontaktný bod verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
• 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č).

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ťiaž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:

a možného dopadu:

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

Majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia

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

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

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)
• Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2 Požadovaná dostupnosť IS:

MPSVR nemá pre všetky IS definované dobu ich prevádzky a dostupnosť. Prístup k dostupnosti odvodzuje z použitých technológií. Cieľový stav z pohľadu parametrov dostupnosti je v nasledujúcich podkapitolách.

7.2.1 Dostupnosť (Availability)

Dostupnosť (Availability) znamená, že dáta alebo iné zariadenie sú prístupné v okamihu ich potreby. Vyjadruje sa v percentách dostupného času. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť.

Aktuálne majú IS RSD a ISSZ zmluvne zabezpečenú dostupnosť služieb 4h. tzn. na úrovni 99,9%.

7.2.2 RTO (Recovery Time Objective)

RTO (Recovery Time Objective) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celého prevádzky nedostupného systému (softvér). RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému. Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.

IS RSD, ISSZ a DMS tvoria integrálny úzko prepojený celok a preto ich RTO je dané najdlhším časom obnovy každého jedného z nich. Z dôvodu vysokého objemu údajov má najdlhšie RTO = 24h IS DMS. K tomuto RTO bola definovaná infraštruktúra a nároky na prenosové linky.

7.2.3 RPO (Recovery Point Objective)

RPO (Recovery Point Objective) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.

Pre rôzne údaje sú definované nasledovné RPO:

• neobchodné údaje vo virtuálnych serveroch (softvér, konfigurácie, logy, ...) = 15 min,
• dokumenty v DMS = 1 hod,
• údaje v databázach = 5 min.

Tieto RPO sú definované pri dosiahnutí dostupnosti existujúcimi replikačnými nástrojmi. V prípade úplného zmazania údajov z diskov, je RPO definícia daná obnovou zo záloh, kde je RPO definované nasledovne:

• obnova virtuálneho servera = 24 hod,
• dokumenty v DMS = 7 dní,
• údaje v databázach = 1 hod.

8. Požiadavky na personál

Pracovné náplne a povinnosti projektového tímu budú súčasťou menovacích dekrétov a budú v súlade s vyhláškou č.401/2023.

9. Implementácia a preberanie výstupov projektu

Implementácia a preberanie výstupov projektu budú definované v rámci projektového iniciálneho dokumentu (PID).

Realizácia a ukončenie projektu je plánované 09/2025. Vzhľadom na jeho  financovanie z Plánu obnovy a odolnosti existuje časová rezerva pre prípadný posun odhadovaných termínov do 03/2026.

Rámcový harmonogram projektu je uvedený v nasledujúcej tabuľke:

Projekt bude realizovaný metódou waterfall, má definované konkrétne projektové výstupy, ktorých dodanie bude podmienkou pre akceptáciu jednotlivých aktivít projektu. Jednotlivé etapy realizačnej fázy môžu prebiehať paralelne, pričom detailný harmonogram spolu s vyznačenými závislosťami medzi jednotlivými aktivitami a ich výstupmi bude odsúhlasený RV po podpise zmluvy s dodávateľom. Projekt má definované konkrétne projektové výstupy, ktorých dodanie bude podmienkou pre akceptáciu jednotlivých aktivít projektu.

10. Prílohy

n/a