everzia 0_27_final Zavedenie služieb Platform as a Service Štúdia zameraná na služby vládneho cloudu

Transcription

1 everzia 0_27_final Zavedenie služieb Platform as a Service Štúdia zameraná na služby vládneho cloudu :56:32 Tento dokument obsahuje 54 strán Obsah 1 Základné informácie 1.1 Prehľad 1.2 Dôvod 1.3 Rozsah 2 Manažérske zhrnutie 2.1 Motivácia 2.2 Popis aktuálneho stavu Legislatíva Architektúra Prevádzka 2.3 Alternatívne riešenia Alternatíva A Platforma vyskladaná z open source komponentov pre poskytovanie kontajnerov, služieb a softvéru" Alternatíva B Natívna PaaS platforma pre PaaS služby, kontajnery a SW licencie" Alternatíva C Platforma - Dodávateľské riešenie" Multikriteriálna analýza Výber alternatívy 2.4 Popis budúceho stavu Legislatíva Architektúra 3 Správa a riadenie - governance Komunikácia a správa vzťahov s odberateľmi služieb Riadenie rizík a klasifikácia aplikácii Správa alokácii Správa súladu s legislatívou a pravidlami Priebežná údržba katalógu služieb 4 Rozvoj interných služieb 5 Služby z katalógu PaaS cloudových služieb 6 Natívna PaaS platforma 7 Poskytovanie a správa licencií V tejto oblasti je v zmysle horeuvedeného potrebné zabezpečiť: Pay per use model Proces manažovania softvérových licencií software asset management 8 Devops Jednotné postupy, metodiky a nástroje Roly Pravidlá a požiadavky pre vývoj aplikácii navrhovanie aplikácii pre cloud Dokumentácia procesov Správa katalógu služieb Riadenie zdrojov Onboarding nových aplikácii

2 Onboarding existujúcich aplikácii Školenia Prevádzka Ekonomická analýza Zoznam obrázkov Obrázok č. 1 Model motivácie Obrázok č. 2 Prostredia vládneho cloudu súčasný stav Obrázok č. 3 Gartner magic quadrant pre PaaS Obrázok č. 3 G2 Crowd Grid pre PaaS Obrázok č. 4 Biznis architektúra PaaS Obrázok č. 5 Architektúra informačných systémov Obrázok č. 6 Technologická architektúra Obrázok č. 7 Implementácia a migrácia Zoznam tabuliek Tabuľka 1 Skratky a značky Tabuľka 2 Základné informácie zhrnutie Tabuľka 3 Motivácia budúci stav Tabuľka 4 Legislatíva aktuálny stav Tabuľka 5 Biznis architektúra aktuálny stav Tabuľka 6 Architektúra informačných systémov aktuálny stav Tabuľka 7 Technologická architektúra aktuálny stav Tabuľka 8 Bezpečnostná architektúra aktuálny stav Tabuľka 9 Prevádzka aktuálny stav Tabuľka 10 Alternatíva A Tabuľka 11 Alternatíva B Tabuľka 12 Alternatíva C Tabuľka 13 Multikriteriálna analýza Tabuľka 14 Legislatíva budúci stav Tabuľka 15 Biznis architektúra budúci stav Tabuľka 16 Architektúra informačných systémov budúci stav Tabuľka 17 Technologická architektúra budúci stav Tabuľka 18 Implementácia Tabuľka 19 Bezpečnostná architektúra budúci stav Tabuľka 20 Prevádzka budúci stav Tabuľka 21 Ekonomická analýza budúci stav Použité skratky a pojmy Tabuľka 1 Skratky a značky Skratka / Značka AA/IAM Amazon AWS API Aplikačný kontajner CBA CI/CD CMS CSP DDoS Vysvetlenie Identity and Access Management Amazon Web Services Application Programming Interface Samostatný balík SW, ktorý obsahuje všetko potrebné k svojmu behu. Je možné ho jednoducho spustiť v akomkoľvek kompatibilnom prostredí bez nutnosti zložitej inštalácie. Po spustení beží kontajner vo vlastnom priestore, vyhradenom hosťujúcim operačným systémom. Má vlastné sieťové rozhranie (IP adresu) a vlastný file systém. V kontajneri by mal bežať len jeden proces. Cost Benefit Analysis (Nákladovo prínosová analýza) continuous integration / continuous delivery Content Management System Cloud Service Provider distributed denial-of-service DevOps súbor procesov medzi vývojom a prevádzkou, skratka z developer operations

3 DFŠ DMZ DNS DOS DPH EA ENPV FTP FW HSM HW IaaS Detailná funkčná špecifikácia Demilitarizovaná zóna Domain name system Disk Operating System Daň z pridanej hodnoty Enterprise agreement Expected Net Present Value File trensfer protocol firewall Hardware security module Hardware Infrastructure as a Service IAM Identity and Access Management ICO IKT IP IPS ISVS JSON KPI LAN LDAP MetaIS MF SR MPK MS SQL MV SR NBU SR NKIVS NTP OPII OPIS OS SW OVM IBM Cloud Orchestrator Informačná a komunikačná technológia Internet protocol Intrusion prevention system Informačný systém verejnej správy JavaScript Object Notation Kľučový ukazovateľ výkonnosti Local Area Network Lightweight Directory Access Protocol Metainformačný systém Ministerstvo financií Slovenskej republiky Medzirezortné pripomienkové konanie Microsoft SQL Ministerstvo vnútra Slovenskej republiky Národný bezpečnostný úrad Slovenskej republiky Národná koncepcia informatizácie verejnej správy Network Time Protocol Operačný program Integrovaná infraštruktúra Operačný program Informatizácia spoločnosti Operating system Software Orgány verejnej moci

4 PaaS PBP PoC REST RISC RPO RTO SAM SAML SAP SDLC SDN SIEM SLA SMTP SP SPLA SW ŠU TCO UX VM VPN VS WAN Platform as a Service Rok návratu investície Proof of Concept Representational state transfer Reduced instruction set computer Recovery point objective Recovery time objective Software Asset Management Security Assertion Markup Language Program na riadenie ľudských zdrojov Systems development life cycle Software-defined networking Security Information and Event Management) Service-level agreement Simple Mail Transfer Protocol Strategická Priorita "Vládny Cloud" Service Provider License Agreement Software Štúdia uskutočniteľnosti Total cost of ownership User experience design Virtual Machine Virtual Private Network Verejná správa Wide Area Network 1. Základné informácie 1.1. Prehľad Tabuľka 2 Základné informácie zhrnutie Zdôvodnenie využitia národného projektu a vylúčenia výberu projektu prostredníctvom výzvy

5 Predložená ŠU sa zameriava na vybudovanie systému, ktorý: rozšíri vládny cloud o služby typu Platform as a Service (ďalej aj ako PaaS") poskytovania serverového softvéru formou pay-as-you-go"/ pay per use" a prostredníctvom natívnej PaaS platformy, zavedie súčasné postupy a trendy (devops a governance) do riadenia a prevádzky PaaS vládneho cloudu,rozšíri v súčasnosti poskytované služby Infrastructure as a Service (ďalej aj ako IaaS") súvisiace s PaaS, bude poskytovať predpripravené centrálne komponenty na využitie pre iné ISVS Rozvoj týchto oblastí je buď priamo uvedený v NKIVS a dokumente Strategická priorita Vládny cloud (ďalej aj ako SP Vládny cloud)". Dôvodom je splnenie nasledovných cieľov: splnenie úloh vyplývajúcich z NKIVS, zefektívnenie využívania SW a HW zdrojov vládneho cloudu, implementácia nových moderných služieb pre odberateľov, zjednodušenie plánovania cez predpripravené služby s vopred známymi SLA a architektúrou, ktoré redukujú komplexnosť prípravy architektúry a finančného plánovania, zrýchlenie vývoja vďaka prostrediam pre vývoj a testovanie, ktoré sú dostupné vo veľmi krátkom čase a vďaka nasadzovaniu celých prostredí (vrátane nasadených aplikácii) automatizovaným spôsobom, flexibilita škálovania cez zdieľanie SW prostriedkov a ich prideľovanie podľa potreby, čo rozširuje spôsoby úspor prostredníctvom cloudu, stabilita a zlacnenie prevádzky vďaka novým postupom ako DevOps s podporou PaaS automatizácie, ktoré umožňujú rýchlejšie a bezpečnejšie riešenie zmenových požiadaviek a incidentov. V neposlednom rade je zavedenie PaaS služieb potrebné z dôvodu efektívnosti a rozvoja vízie egovernmentu. Aby vládny cloud vedel podporovať novo budované systémy v rámci egovernmentu, je potrebné, aby bola funkcionalita doplnená podľa možností čo najskôr. Iba tak bude možné efektívne poskytovať služby novým projektom. Služby PaaS zároveň sú súčasťou ISVS vládneho cloudu, ktorý prevádzkuje Ministerstvo vnútra SR (ďalej aj ako MVSR) v zmysle uznesenia vlády SR č. 247/2014. Prijímateľ/ partner národného projektu a dôvod jeho určenia Ministerstvo vnútra Slovenskej republiky je správcom a prevádzkovateľom ISVS vládneho cloudu, ktorého súčasťou v cieľovom riešení bude poskytovanie trojice služieb IaaS, PaaS a SaaS. Tento projekt sa zameriava na vybudovanie funkcionality a modulu predmetného ISVS, ktorý bude dodávať funkcionalitu PaaS. Budovanie, prevádzkovanie a poskytovanie služieb vládneho cloudu MVSR je v súlade s NKIVS, strategickou prioritou vládny cloud a v zmysle uznesenia vlády SR č. 247/2014. Partnerom národného projektu bude Úrad podpredsedu vlády Slovenskej republiky pre investície a informatizáciu (ďalej len ÚPPVII ), ktorý je v zmysle ods. 34a, bodu 1b) Zákona č. 575/2001 Z. z. o organizácii činnosti vlády a organizácii ústrednej štátnej správy ústredným orgánom štátnej správy pre oblasť informatizácie spoločnosti. V súlade s Operačným programom Integrovaná infraštruktúra si bude ÚPPVII uplatňovať maximálne 3 % oprávnených výdavkov projektu pre implementáciu štandardov riadenia informačno - technologických projektov, ktoré zabezpečia aktívnu participáciu na riadení projektu a komplexné riadenie budovania informačnej spoločnosti. Príslušnosť národného projektu k relevantnej časti PO7 OPII INVESTIČNÁ PRIORITA 2c): Posilnenie aplikácií IKT v rámci elektronickej štátnej správy, elektronického vzdelávania, elektronickej inklúzie, elektronickej kultúry a elektronického zdravotníctva ŠPECIFICKÝ CIEĽ 7.8: Racio nalizácia prevádzky informačných systémov pomocou egovernment cloudu Indikatívna výška finančných prostriedkov určených na realizáciu národného projektu Eur s DPH 1.2. Dôvod

6 Dôvodom vypracovania tejto ŠU je posúdenie výhodnosti, alternatív, podmienok a vytvorenie predpokladov pre realizáciu projektu a jeho financovanie z prostriedkov OPII. Riešenie bude poskytovať podporné služby pre všetky povinné osoby spravujúce ISVS. Hlavným dôvodom vypracovania tejto ŠU je posúdenie uskutočniteľnosti projektu PaaS vládneho cloudu, ktorého ciele sú nasledovné: splniť úlohy vyplývajúce z NKIVS a nadväzujúcich dokumentov, efektívnejšie (v zmysle ceny a rýchlosti nasadenia) poskytovanie vybraných platforiem a softvéru, efektívnejšie využívanie HW a SW zdrojov súčasného cloudu, možnosť škálovania výkonu automatickým pridávaním ďalších zdrojov pre vhodne navrhnuté aplikácie, interné vybudovanie devops tímu, ktorý bude mať nástroje, schopnosti a kapacity dosiahnuť nasledovné: riadenie životného cyklu aplikácii, od zdrojového kódu až po nasadenie príslušných aplikácii, ich komponentov a prepojení, centralizácia a optimalizácia celkovej prevádzky ISVS. Z toho vyplýva možnosť plánovať a riadiť celoštátne IT ako aj vytvoriť predpoklady pre jednoduchšie zavedenie enterprise architektúry do verejnej správy. Jedným z cieľov je tiež dobehnúť technologický dlh a aplikovať moderné spôsoby riadenia infraštruktúry používané aj v komerčnom svete podľa prieskumu z roku 2016 boli devops využívané v 74 % až 81 % ud-survey organizácii. Vybudovanie devops tímu predstavuje kritickú časť projektu, keďže na tomto tíme bude záležať, ako sa bude riešenie využívať, a teda ako budú realizované benefity projektu. Riešenie priamo nadväzuje na nasledujúce strategické dokumenty: Národná koncepcia informatizácie verejnej správy, schválené strategické priority Národnej koncepcie informatizácie verejnej správy, pozičný dokument Európskej komisie k vypracovaniu Partnerskej dohody a programov na Slovensku na roky , kde jednou z piatich priorít je moderná a odborná verejná správa, Návrh centralizácie a rozvoja dátových centier v štátnej správe", ktorý bol schválený uznesením vlády SR č. 247/2014, Referenčná architektúra Informačného systému verejnej správy v cloude, najmä v časti "Pravidlá a požiadavky pre vývoj aplikácii navrhovanie aplikácii pre cloud" 1.3. Rozsah Predložená ŠU vychádza z architektonického rámca verejnej správy a nadväzuje na Architektonickú víziu verejnej správy definovanú v NKIVS a strategických prioritách. Cieľom tejto ŠU je poskytnúť strategický rámec, plánovaný rozsah, očakávaný časový harmonogram, závislosti na iné projekty a odporúčania ďalších aktivít, z ktorých treba pri realizácií implementácie vychádzať. Štúdia popisuje aktuálny stav governance a správy životného cyklu aplikácii v prostredí egovernmentu, keďže to je jedna z oblastí, kde sú zrejmé veľké rezervy štátneho IT a je to jedna z oblastí, ktorej táto štúdia má ambíciu adresovať. V časti Motivácia sú rámcovo vymenované oblasti rozvoja a definované princípy a požiadavky. Sú to najmä NKIVS a príslušné strategické priority, ktoré tvoria ďalšie požiadavky a základný rámec riešenia a sú detailne popísané v príslušných dokumentoch. Tu je uvedený iba stručný prehľad. Predmetom tejto štúdie uskutočniteľnosti je rozvoj vládneho cloudu rozšírením poskytovaných služieb o služby typu Platform as a Service (PaaS) s cieľom poskytnúť odberateľom služieb funkcie, ktoré zjednodušia a zefektívnia vývoj, nasadenie a prevádzku aplikácii vrátane ďalších služieb (poskytnutie licencií, API Managementu, autentifikácia, DevOps služieb, atď.). To všetko s ultimátnym biznis cieľom podporiť agilitu a zároveň znížiť cenu vývoja nových softvérových biznis riešení. Rozsah projektu bol rámcovo stanovený nasledovne: zavedenie natívnej PaaS platformy, rozvoj IaaS služieb súvisiacich so zavedením PaaS, optimalizácia činností, zavedenie procesov devops a governance nad vládnym cloudom, zavedenie modelu poskytovania softvérových licencií formou pay-as-you-go", príprava spoločných predpripravených komponentov. 2. Manažérske zhrnutie Štúdia uskutočniteľnosti sa venuje realizovateľnosti a možnostiam implementácie PaaS platformy nad existujúcim riešením vládneho cloudu. Implementácia PaaS platformy je uvedená v NKIVS a jej strategických prioritách ako jeden z cieľov informatizácie. PaaS platforma v ponímaní tohto dokumentu predstavuje prostredie pre vývoj a nasadzovanie aplikácii v cloude, ktoré je navrhnuté tak, že podporuje celý životný cyklus aplikácie, vrátane zostavovania, testovania, nasadenia, správy a aktualizácií aplikácie. Používanie navrhovanej PaaS platformy prináša pre zákazníkov nasledovné výhody: centralizácia funkcií správy prostredia, aplikačnej infraštruktúry a správy softvérových licencií umožní realizovať úspory z rozsahu a pre odberateľov zjednoduší proces vývoja a správy ich aplikácií, zrýchlenie vývoja vďaka prostrediam pre vývoj a testovanie, ktoré sú dostupné vo veľmi krátkom čase a vďaka nasadzovaniu celých prostredí (vrátane nasadených aplikácii) automatizovaným spôsobom, flexibilita škálovania cez zdieľanie SW prostriedkov a ich prideľovanie podľa potreby, čo rozširuje spôsoby úspor prostredníctvom cloudu,

7 stabilita a zlacnenie prevádzky vďaka novým postupy ako DevOps s podporou PaaS automatizácie, ktoré umožňujú rýchlejšie a bezpečnejšie riešenie zmenových požiadaviek a incidentov. ŠU analyzuje 3 základné prístupy, ako je možné pristupovať k projektu, sú to: implementácia platformy svojpomocne vyskladaním z open source nástrojov a poskytovanie SW vrátane open source, implementácia platformy pre provisioning a SW licencie vrátane open source, spolu s platformou na kontajnery založenou na open source technológiách, ako v prípade prístupu B, avšak implementácia kompletnej platformy založenej na dodávateľskom riešení Microsoft, IBM alebo Oracle. Na základe analýzy, prieskumu existujúcich riešení, možností MVSR a multikriteriálnej analýzy bola vybraná alternatíva B, pričom pri jej implementácii bude kladený dôraz na jednoduchosť riešenia (v zmysle architektúry, prevádzky ako aj počtu poskytovaných služieb) a jeho postupné rozširovanie po získaní skúseností s prevádzkou. Súčasťou dodávky musí byť nielen samotné technické riešenie ale aj vybudovanie, dokumentácia a nastavenie skupín procesov devops a governance. Merateľné ukazovatele Merateľný ukazovateľ OPII: Dodatočný počet inštitúcií štátnej správy zapojených do egovernment cloudu Ďalšie potenciálne navrhované biznis KPI stanovené na základe reálnych možností a predpokladaného potenciálu projektu sú: aspoň 60% projektov OPII bude využívať softvérové licencie poskytované cez PaaS, úspora z centrálneho nákupu SW licencií - 5%, úspora počtu licencií z dôvodu vyššej efektívnosti a zavedenia SAM procesov 6%, aspoň 40% projektov OPII bude využívať služby cloud natívnej platformy PaaS alebo jednotný devops, zefektívnenie vývoja a nasadenia zmien pri využívaní služieb CI/CD projekty využívajúce tieto služby nebudú potrebovať prostredia a tímy na vykonávanie devops operácii, pričom odhad úspor vo je výške 5% (tento odhad nie je možné zaradiť medzi merateľné ukazovatele z dôvodu, že nie je možné ho jednoducho zmerať, je tu však uvedený z dôvodu logickej príslušnosti). Dosiahnutie týchto KPI je plánované do dvoch rokov od začiatku plnej prevádzky projektu. Predpoklady naplnenia týchto cieľov sú: dôsledná implementácia princípu cloud first, kedy by systémy financované z OPII mali byť nasadená na PaaS platformu vládneho cloudu, projekty, pre ktoré z časových dôvodov nebudú služby PaaS ešte k dispozícii musia deklarovať pripravenosť migrácie do vládneho cloudu - a aj s ňou rátať s ohľadom na finančné prostriedky, presmerovanie finačných prostriedkov na SW licencie z jednotlivých OVM na MVSR (pomocou programu 0EK na UPVII). Stručný popis a návod pre OVM na využívanie PaaS služieb Ak chce OVM začať využívať služby PaaS vládneho cloudu, tak prvý krok vedie do zoznamu infraštruktúrnych služieb publikovaného v MetaIS, kde sú služby PaaS neustále aktualizované. Stručný návod pre OVM je rozdelený podľa typu služby. Natívna PaaS platforma Nové OPII projekty by mali (pokiaľ nedostanú výnimku) automaticky využívať služby PaaS natívnej platformy. Aby OVM zabezpečilo, že platforma bude správne a bez prekážok používaná, je odporúčané nasledovné: dať do VO podmienky vývoja cloud natívnych aplikácii, ktoré sú definované na stránke ako aj v dokumente Referenčná architektúra Informačného systému verejnej správy v cloude, najmä v časti "Pravidlá a požiadavky pre vývoj aplikácii navrhovanie aplikácii pre cloud" momentálne prichádzajú do úvahy 2 možnosti, na ktorých bude natívny PaaS postavený: Cloud Foundry a OpenShift. Aj keď migrácia aplikácie, ktorá dodržiava vyššie uvedené kritéria by mala byť priamočiara a bez komplikácii, pre istotu odporúčame sledovať, na ktorej platforme bude natívny PaaS postavený a dať zodpovedajúcu inštrukciu dodávateľom, natívna PaaS platforma sa netýka iba veľkých projektov, je možné tu nasadiť aj malé aplikácie, čo by malo zjednodušiť život najmä interným zamestnancom OVM. Nasadenie aplikácie by malo byť významne jednoduchšie. Predpoklad spustenia týchto služieb je do roka od ukončenia obstarávania. Poskytovanie SW pay per use Služby poskytovania SW predstavujú nasledovné: nákup SW, vrátane licencií, starostlivosť o SW vrátane aktualizácii a podpory. OVM je motivované využiť tieto služby predovšetkým z nákladového hľadiska - licencie poskytované vládnym cloudom budú lacnejšie z dôvodu úspor z rozsahu (cena ktorú OVM dostane cez PaaS vládneho cloudu sa očakáva, že bude efektívnejšia ako cena ktorú si OVM dokáže obstarať samostatne). Ak chce OVM použiť iné licencie, bude musieť osloviť MVSR, či je schopné poskytnúť služby podľa požiadaviek, ak MVSR vydá negatívne stanovisko, tak OVM môže použiť aj iný softvér. Každopádne je pre OVM odporúčané v tejto veci kontaktovať MVSR, ktoré za týmto účelom bude mať zriadený dedikovaný kontaktný bod. Aktuálny zoznam poskytovaného SW sa nachádza v MetaIS v popise príslušných infraštruktúrnych služieb. Predpoklad spustenia týchto služieb je na konci projektu PaaS. PaaS komponenty

8 Tieto komponenty predstavujú stavebné bloky ISVS, ktoré by mali byť univerzálne použiteľné pre väčšinu projektov. Ich dostupnosť bude vo forme open source zdrojového kódu, ktorý bude k dispozícii pre ostatné OVM na použitie. Výhodou týchto komponentov bude súlad s jednotlivými riešeniami slov. egovernemntu (napr. autentifikačný server MVSR, single sign on s UPVS atď). Dostupnosť komponentov sa predpokladá na konci projektu, čiastkové výsledky však môžu byť už skôr. PaaS služby Tieto služby budú využívané aj interne (pre potreby vládneho cloud a zálohovanie tam nasadených ISVS), avšak budú k dispozícii aj pre systémy, ktoré nie sú v vládnom cloude. Služby sú nasledovné: backup - bude možné realizovať zálohovanie PaaS, IaaS a lokálnych (OVM) údajov do vládneho cloudu prostredníctvom softvéru VeeaM, disaster recovery - táto služba umožní zálohovanie údajov aj s celou infraštruktúrou - ktorá môže byť naštartovaná s poslednou backup kópiou po výpadku primárneho systému. HSM moduly predstavujú hardvérový komponent vo vládnom cloude, ktorú bude k dispozícii pre jednotlivé ISVS. Spustenie týchto služieb sa očakáva ku koncu projektu, HSM moduly môžu byť k dispozícii aj skôr. Špecifikácia týchto služieb nie je taká detailná ako v prípade natívnej PaaS platformy, detaily by mali byť zrejmné počas fázy DFŠ po ukončení obstarávania. Ministerstvo vnútra súčasne s touto štúdiou uskutočniteľnosti predkladá aj nasledovné štúdie: Digitálne pracovné prostredie zamestnanca Ministerstva vnútra Slovenskej republiky Riadenie procesov a dát pre OÚ, PZ a HaZZ Centrálne komponenty správneho konania vo verejnej správe Ich spoločným prepojením je vybudovanie prostredia informačných systémov, ktoré môžu fungovať aj samostatne (napr. registratúra, registratúrne stredisko, archív, priestupkové konanie, meranie výkonnosti procesov, notifikácie o stave konania a pod) alebo ako súčasť agendového informačného systému na podporu správneho konania. Zákon č. 71/1967 o správnom konaní (správny poriadok) upravuje všeobecné procesné pravidlá pre správne konania, ktoré platia pre všetky štátne (alebo správne) orgány, ktoré v správnych konaniach rozhodujú. Podľa definície uvedenej v ustanovení 1 správneho poriadku, sa správny poriadok vzťahuje na konanie, v ktorom v oblasti verejnej správy správne orgány rozhodujú o právach, právom chránených záujmoch alebo povinnostiach fyzických osôb a právnických osôb, ak osobitný zákon neustanovuje inak. Keďže správne orgány vystupujú v roli toho, kto rozhoduje právne záväzným spôsobom o právach, povinnostiach, alebo právom chránených záujmoch, je veľmi dôležité, aby bol jednoznačne a jasne stanovený postup a pravidlá, ako má správny orgán pri svojom rozhodovaní postupovať. Tieto postupy a pravidlá sú zároveň predmetom bežiaceho národného projektu Optimalizácia procesov vo verejnej správe realizovaný cez Operačný program Efektívna verejná správa (ďalej len OP EVS) a ktorého výstupy boli podkladom pre tieto a nasledovné štúdie MV SR. Dokument Strategická priorita - Rozvoj agendových informačných systémov a využívanie centrálnych spoločných blokov uvádza, že ak pri vedení konania (agendy) správny orgán musí postupovať zákonným spôsobom, teda v súlade s napríklad správnym poriadkom a/alebo osobitnými právnymi predpismi, v rámci konkrétnej oblasti, tak by mal tento postup podporovať aj agendový informačný systém, ktorý by mal byť postupne migrovaný do natívnej cloudovej architektúry. V nej bude využívať spoločné časti agendových aj iných procesov (napr. prihlasovanie do aplikácie, centrálne doručovanie, zaručená konverzia, registratúra a pod.), ktoré budú vo väčšej či menšej miere zastrešované novými (SaaS) centrálnymi spoločnými blokmi a prepojené s unikátnou logikou podporujúcou špecifické časti procesov, pričom sa očakáva celková modernizácia informačných systémov aplikovaním princípov NKIVS (otvorené API, automatizované vybavenie služieb, jeden krát a dosť a pod.). Takto definovaná architektúra poskytuje možnosť pre pracovníkov zodpovedných za informačné systémy na jednotlivých OVM vybrať riešenie, ktoré bude spĺňať požiadavky biznis zadania. Pod pojmom natívna cloudová architektúra chápeme sadu pravidiel a princípov, ktoré vedú k vyššej schopnosti absorbovať (napr. pomocou jasného oddelenia biznis logiky aplikácie od IT prostredia/zdrojov/infraštruktúry) a lepšie využívať (napr. biznis logika je písaná tak, aby vedela v každom kroku spracovania využívať možnosť paralelnej práce a bolo ju tak možné flexibilne škálovať) dynamicky sa meniace prostredie, v ktorom je daný agendový IS prevádzkovaný. Predkladané štúdie popisuje jednotlivé centrálne bloky potrebné pre budovania agendových natívnych cloudových aplikácií, ktoré sú rozpracované v NKIVS Strategických prioritách Lepšie služby, Lepšie dáta a Strategická architektúra, pričom je možné ich realizovať pomocou nasledovných vrstiev: Užívateľské prostredie Orchestrácia Aplikačné domény Infraštruktúra Užívateľské prostredie bude zodpovedné za štandardizované zobrazovanie informácií používateľom a za zabezpečenie reakcie na používateľove príkazy, tak aby sa užívateľ pri zmene alebo doplnení systému nemusel učiť jeho nové ovládanie. Ako užívateľa si možno tiež predstaviť iný

9 program/počítač. Touto vrstvou sa primárne zaoberá štúdia uskutočniteľnosti Digitálne pracovné prostredie zamestnanca Ministerstva vnútra Slovenskej republiky. Výstupy (aj priebežné) tejto štúdie budú využité v projektoch definovaných v štúdiách Centrálne komponenty správneho konania vo verejnej správe a Riadenie procesov a dát pre OÚ, PZ a HaZZ. Využitie výstupov tejto štúdie je aj pre face-lifting fron-endu aplikácii, ktoré už teraz síce ponúkajú množstvo elektronických služieb, ale pri ich implementácii sa neuplatňoval prístup na zjednotenie pracoviska v danej agende. Ako príklad môžeme uviesť priame využitie pri následnom vytvorení workdesku pre osobitnú matriku, ktorá je v súčasnej dobe realizovaná tromi, samostatnými a neprepojenými IT systémami (Centrálny informačný systém matrík, registratúra Fabasoft a Modul správnych poplatkov). Každá aplikácia má vytvorený vlastný front-end klienta, ale v podstate s rovnakými údajmi (ako napr. meno, priezvisko, trvalá adresa, výška správneho poplatku a pod). Orchestrácia úlohou tejto vrstvy je realizovanie end-to-end biznis procesov (BPMN), Case managementu (CMNN) alebo biznis rozhodnutí (DMN). Optimalizačný projekt ku dňu definoval cca 2700 prípadov použitia (use-case). Tieto prípady použitia (use case) zachytávajú funkčné správanie systému opisom vzťahu medzi systémom a používateľom systému. Používateľ systému, tzv. aktér, vyvoláva interakciu so systémom. Každý prípad použitia predstavuje sériu činností a udalostí z pohľadu aktéra. Pri konsolidácii prípadov použitia (stále prebiehajúcej v čase prekladania týchto štúdií) boli identifikované opakujúce sa požiadavky na IT podporu v rámci biznis procesov, ktoré je možné modelovať ako znovu použiteľné procesné služby (napríklad načítanie údajov z referenčného registra fyzických osôb, odoslanie rozhodnutia na doručenie, obnova časovej pečiatky nad údajom v registri, automatické správoplatnenie rozhodnutia ak sú splnené zákonné podmienky, odolanie notifikácie o zmene stavu konania a pod). Takto dosiahneme aj na procesnej vrstve oddelenie biznis (napr. na obrázku uvedené ako centrálne bloky správneho konania) a technologických (napr. na obrázku uvedené ako procesná orchestračná platforma) procesov. Pričom biznis proces iba definuje (cez prípad použitia) rozhranie aké biznis údaje sú odoslané do technologického procesu a/alebo prípadne požadované ako výstup z technologického procesu. Biznis proces pritom vôbec nemusí zaujímať ako sa, kde, kedy a kým sa daný proces vykonáva. To umožní reorganizovať biznis proces (napr. v prípade organizačných zmien v danej agende, delimitácie práce a pod) bez nutnosti meniť niečo v technologickom procese. To isté ale platí aj pre technologický proces, ktorý sa môže zmeniť pri zmene poskytovaných služieb (napr. pribudne nový systém s referenčnými údajmi, na ktorý je povinnosť sa napojiť) bez nutnosti niečo meniť v biznis procese. Aj týmto spôsobom ideme realizovať princípy definované v dokumente Referenčná architektúra Informačného Systému Verejnej Správy v Cloude Takto realizované prípady použitia umožnia: Biznis procesy nebudú previazané (loosely coupled) s využívanými back-end systémami. Biznis procesy by mali byť čo najviac nezávislé od prevádzkovanej architektúry. Biznis procesy budú môcť mať samostatný životný cyklus, ktorý je ideálne nezávislý od životných cyklov používaných IT systémov.

10 Súčasnú prevádzku rôznych verzií biznis a technologických procesov. Toto umožní podporu pre štandardnú legislatívnu požiadavku aby bežiace konania dobehli podľa vtedy platnej legislatívy, a nové konania už boli realizované podľa aktuálnej legislatívy. Biznis procesy by mali pracovať iba s údajmi, ktoré sú nutné na podporu práce v danej agende. Dodávať aj informácie o požitý údajov o klientovi (agenda, kto a za akým účelom) do aplikácie/službe Moje dáta. Touto vrstvou sa primárne zaoberá štúdia uskutočniteľnosti Riadenie procesov a dát pre OÚ, PZ a HaZZ. Výstupy (aj priebežné) tejto štúdie budú využité v projektoch definovaných v štúdii Centrálne komponenty správneho konania vo verejnej správe a Digitálne pracovné prostredie zamestnanca Ministerstva vnútra Slovenskej republiky. Zároveň tu vznikne prepojenie registrov MV SR na platformu integrácie údajov (a.k.a. CSRU.), takže z pohľadu OVM bude nutné vybudovať iba jedno napojenie na platformu integrácie údajov, aby získali prístup k všetkým dostupným údajov v rámci verejnej správy. Aplikačné domény Tu sa nachádza ucelená aplikačná logika pre danú agendu/biznis oblasť. Iba tu je miesto, kde sa nachádzajú biznis informácie, ich stavy a biznis pravidlá, avšak technické detaily ich zapisovania sú delegované do infraštruktúrnej vrstvy. Touto vrstvou sa primárne zaoberá štúdia uskutočniteľnosti Centrálne komponenty správneho konania vo verejnej správe. Výstupy (aj priebežné) tejto štúdie budú využité v projektoch definovaných v nasledovných štúdiách MV SR (ako napríklad agendový systém pre register mimovládnych neziskových organizácií, agendový systém pre živnostenský register, agendový systém pre register zbraní a streliva a pod), iných OVM (napr. agendový systém pamiatkového úradu), ktoré sú založené na správnom konaní. Infraštruktúra poskytuje generické, technické kapacity, ktoré podporujú vyššie vrstvy: posielanie správ medzi aplikáciami, trvalé (persistence) uloženie informácií z aplikačnej domény, poskytovanie plug-in-ov pre používateľské prostredie, a pod. Touto vrstvou sa primárne zaoberá štúdia uskutočniteľnosti Zavedenie služieb Platform as a Service. Výstupy (aj priebežné) tejto štúdie budú využité v projektoch definovaných v štúdiách Cent rálne komponenty správneho konania vo verejnej správe, Riadenie procesov a dát pre OÚ, PZ a HaZZ a Digitálne pracovné prostredie zamestnanca Ministerstva vnútra Slovenskej republiky. Nakoľko jasné oddelenie medzi jednotlivými vrstvami dovoľuje všetky projekty spustiť spoločne, na čo sa MV SR v súčasnosti aj personálne pripravuje. Vzťah medzi jednotlivými štúdiami je uvedený na nasledovnom obrázku.

11 Tieto spolu predkladané štúdie sú zamerané pre agendové konanie, ktoré sú založené na správnom konaní, ale tie isté princípy budovania agendových IS platia aj pre iné typy konaní, ktoré sú definované v legislatíve (napr. daňové konanie podľa zákona č. 563/2009 Z. z.. o správe daní (daňový poriadok) a o zmene a doplnení niektorých zákonov a pod.). Ministerstvo vnútra Slovenskej republiky ide následne predložiť tri ďalšie štúdie uskutočniteľnosti a to na agendové systémy pre: Živnostenské podnikanie Registrácie mimovládnych neziskových organizácií Register zbraní a streliva (vrátane zapojenia doteraz iba čisto papierových evidencií pre vedenie predajní so zbraňami a strelivom, alebo pre poľovnícke združenia a pod). Ich časovanie je uvedené na nasledovnom obrázku:

12

13 2.1. Motivácia Tabuľka 3 Motivácia budúci stav Súhrnný popis Motiváciou zavedenia PaaS služieb vládneho cloudu je snaha o efektívne a hospodárne narábanie s IKT zdrojmi ako aj personálnymi zdrojmi pri prevádzke a vývoji aplikácii. Používanie služieb PaaS so sebou prináša nasledovné výhody: centralizácia aktivít, ktoré sú spoločné pre väčšinu aplikácii a projektov, a s tým spojené úspory z rozsahu, automatizácia činností a s tým spojená menšia náročnosť na ľudskú prácu, štandardizácia prostredí, automatizácia provisioningu cloudových služieb, zvýšenie kontroly implementačného procesu aplikácií, rýchlejšie nasadzovanie aplikácii, možnosť odberateľov služieb sústrediť sa na vlastný vývoj aplikácii, bez potreby starať sa o HW a SW, úspory z rozsahu pri obstarávaní HW a SW, väčšia efektívnosť vyplývajúca zo zdieľania zdrojov, lepšia škálovateľnosť aplikácii. Zavedenie vládneho cloudu na Slovensku je zakotvené aj ako jedna z priorít a špecifických cieľov v NKIVS 2016 a ďalej rozvinutá v strategickej priorite Vládny cloud, pričom tu je uvedená aj motivácia prečo bola táto priorita zvolená. V NKIVS 2016 sú uvedené nasledovné termíny pre tieto aktivity: definovanie filozofie postupného rozširovania služieb PaaS a nastavenie pravidiel prevádzky služieb PaaS (do decembra 2016), nasadenie základného súboru služieb Platforma ako služba" (do decembra 2017), postupné sprístupňovanie ďalších služieb PaaS podľa vopred vypracovaného harmonogramu (do júna 2020) a to v zmysle, že najprv sa pripraví čo najjednoduchšie riešenie (t.j. štandardná implementácia bez veľkej customizácie, iba obmedzený počet služieb a komponentov) a na základe skúseností a dopytu sa budú služby rozširovať. Obrázok č. 1 Model motivácie Riziká Spresnenie identifikovaných rizík N/A

14 Kritéria kvality Diagramy, modely, obrázky v plnom rozlíšení Splnenie definovaných KPI Prílohy: Tabuľka 3 Výstupy projektu a kritéria kvality 2.2. Popis aktuálneho stavu Legislatíva Tabuľka 4 Legislatíva aktuálny stav Súhrnný popis. Vládny cloud, jeho budovanie a rozvoj je v súčasnosti definovaný v nasledovných dokumentoch: NKIVS 2016, Strategická priorita vládny cloud, Uznesenia vlády SR č. 247/2014 "Návrh centralizácie a rozvoja dátových centier v štátnej správe". Pre vládny cloud ako ISVS platia aj nasledovné zákony, vyhlášky a predpisy: Zákon č. 275/2006 Z. z. o informačných systémoch verejnej správy, Zakon 305/2013 Z. z. o egovernmente, Výnos o štandardoch 55/2014 Z.z., najmä v nasledovných častiach: modely poskytovania cloudových služieb a typy cloud computingu, správa cloud computingu, vytváranie a rozvoj cloud computingu, používanie cloudových služieb. Pre vybudovanie systému je legislatíva postačujúca, pre vývoj aplikácii a ich následnú jednoduchú prevádzku by bolo vhodné aktualizovať štandardy o požiadavky na aplikácie vypývajúce z PaaS platformy. Riziká Spresnenie identifikovaných rizík: n/a Prílohy Diagramy, modely, obrázky v plnom rozlíšení n/a Architektúra Biznis architektúra Tabuľka 5 Biznis architektúra aktuálny stav Súhrnný popis

15 Vládny cloud v súčasnosti pozostáva z dvoch lokalít. Ako prvé bolo vybudované IaaS riešenie umiestnené v novovybudovanom nadrezortnom dátovom centre Ministerstva financií SR (ďalej len MF SR), ktoré je primárne určené pre nové projekty informačných systémov prevádzkované vo vládnom cloude. Iniciálne prostredie umožnilo proof of concept (PoC)" pre nadrezortný cloud, definovanie technologických štandardov a prevádzkových procesov, poskytuje vysoko dostupné škálovateľné a bezpečné IaaS služby pre vývojové, testovacie, predprodukčné a produkčné prostredia nových informačných systémov. Druhou časťou je IKT infraštruktúra pre poskytovanie IaaS služieb v Datacentre MV SR, ktorá je rozšírená o funkcionalitu replikácie medzi Datacentrom MV SR a Datacentrom MF SR. Toto riešenie v súčasnosti umožňuje jednoduchý prístup k IaaS službám na vyžiadanie vo virtuálnom prostredí. Tieto služby môžu byt prideľované alebo uvoľňované s flexibilným časovým obmedzením a to na základe voliteľného škálovania, nezávisle od lokality zdrojov a prístupu k nim. Z vrstvy PaaS nie je vo vládnom cloude implementované ani poskytované žiadne PaaS služby. Pre PaaS je fungovanie nad existujúcim IaaS stanovená ako podmienka a navyše táto štúdia identifikovala potreby niektorých rozšírení IaaS služieb z dôvodu možnosti efektívneho zavedenia PaaS služieb. Preto popisujeme aj stav IaaS a jeho služieb. Cloud v súčasnosti poskytuje služby publikované na sk.cloud ako aj nasledovné služby (ktoré nemusia byť priamo publikované v katalógu): Cloud v súčasnosti poskytuje nasledovné služby pre odberateľov IaaS služieb cloudu: vytvorenie projektu, vytvorenie topológie infraštruktúry, vytvorenie Virtuálnych serverov a diskov, vytvorenie interných FW pravidiel, vytvorenie externých FW pravidiel, poskytnutie load balancingových služieb, pridelenie virtuálnych IP, pripojenie do internetu a štátnych privátnych sietí, windows server Update Services. Pre prevádkovateľa cloudu sú poskytnuté nasledovné IaaS služby: zálohovanie snímky virtuálneho servera, Intrusion Prevention System, Intrusion Detection System, DDos ochrana, Network Behavioral Analysis, Security Information & Event Management, monitoring - IKT infraštruktúra. Na základe skúseností a nových požiadaviek získaných od OVM počas prevádzky vyplynula potreba implementovať aj ďalšie služby na rozmedzí IaaS a PaaS, ktoré neboli predmetom pôvodného projektu implementácie IaaS: zálohovania ( backup ) a archiváciu, dostupné aj pre aplikačnú vrstvu - aby mohli OVM nastavovať svoj vlastný backup, HSM moduly - aby bolo možné v cloude prevádzkovať aj komponenty vyžadujúce vyššiu mieru bezpečnosti a PKI infraštruktúru,

16 kontinuálny interný monitoring poskytovaných služieb a vyhodnocovanie spätnej väzby od používateľov, vrátane definície SLA a KPI - aby bolo možné lepšie merať a riadiť cloudové služby. Vo Vládnom cloude MVSR je v súčasnosti prevádzkovaných 65 ISVS, ďalšie sú v rôznom procese prípravy a nasadzovania. V roku 2015 bola realizovaná analýza IKT, pričom jedným z jej výstupov je aj prehľad softvéru zastúpeného v jednotlivých ISVS v rámci štátneho IT. Z jej výsledkov vyplýva, že prostredie štátneho IT z pohľadu serverového SW je z hľadiska zastúpenia dodávateľmi heterogénne, avšak - traja najväčší dodávatelia majú spolu približne 87% zastúpenie. Toto východisko je jeden z motivátorov implementácie pay-as-you-go resp. pay per use modelu, kde je potrebné sa dohodnúť aspoň s dvomi dodávateľmi, aby model fungoval (a open source, kde však dohoda nie je nevyhnutným predpokladom). Governance V súčasnosti je úroveň implementácie procesov riadenia vývoja a nasadzovania projektov silne ovplyvnená technologickou a organizačnou vyspelosťou (sub)dodávateľov a zvládnutím ich komunikácie. Slabé využívanie jednotlivých nástrojov, ich prepojenia a automatizácie rutinných činností do end2end procesov vytvára prekážku pre kratšie vývojové cykly a efektívnejšie zavádzanie zmien v projektových artefaktoch. Testovanie a prechod od implementačných prác k nasadzovaniu systémov sa takmer výlučne realizuje v poslednej fáze vývoja a je vykonávané nárazovým spôsobom, čo má negatívny dopad na ich kvalitu. Pre riadenie projektov VS sú používané rôzne aplikácie umiestnené často mimo prostredia klienta. Nástroje sú implementované ako izolované prvky, chýbajú integračné väzby, ktoré by zefektívnili priebeh celého vývojového a nasadzovacieho cyklu. Využíva sa len minimálna automatizácia rutinných činností. Stav projektov je ťažké vyhodnocovať, chýbajú štandardy, nie sú žiadne aplikácie na KPI. Technologicky sú v súčasnosti využívané pre kontrolu vývoja a nasadzovania do prevádzky rôzne platformy podľa preferencií dodávateľov. Škála zahrňuje open source produkty, custom riešenia špecifické pre určité aplikácie (SAP), prípadne platformy (Oracle, MS). Riešenia sú často nekompatibilné a technická integrácia je komplikovaná. Riziká Spresnenie identifikovaných rizík: R-1 Chýbajúce governance procesy a z toho vyplývajúce neefektívne riadenie R-2 Neefektívne vyťaženie (alokácie) hardvérových prostriedkov R-3 Neoptimálne procesy prevádzky Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká

17 Architektúra informačných systémov Tabuľka 6 Architektúra informačných systémov aktuálny stav Súhrnný popis Aplikačná architektúra cloudu je založená na technológii OpenStack, ktorý beží na pozadí IBM Cloud Orchestrator (ICO) produktu vo verzii 2.4, ktorý je doplnený o webovú aplikáciu, ktorá slúži ako nadstavba na objednávanie služieb provisioning pre odberateľov služieb. ICO ako softvérový produkt postavený na vrstve OpenStack realizuje cez túto vrstvu komunikáciu s hypervízormi VMware VSphere PowerVC Komunikácia znamená alokovanie zdrojov a vytvorenie VM, evidenciu, riadenie a zrušenie VM. Rovnakým kanálom, t. j. komunikáciou s ICO s hypervízormi je realizovaná alokácia zdrojov a tvorba doplnkového diskového priestoru (volumu) pre príslušnú VM, vrátane priradenie volumu k VM. ICO sa tiež používa vlastné definície sietí ku ktorým sú VM prideľované a zabezpečuje správne nastavenie adries vytváraných VM. Štruktúra serverov IBM Cloud Orchestrator (ICO) servery sú rozdelené do troch entít nazývaných regióny. Okrem serverov v regiónoch existuje základný server pre inštaláciu, aktualizáciu a ukladanie inštalačných dát ICO, tzv. deployment server. Použitý OS je rovnaký pre všetky servery, Red Hat Enterprise Linux 6.5 pre kompatibilitu s ICO 2.4. Servery ICO sú virtuálne, v prostredí VMware, v štruktúre VMware VSphere je pre ne vyhradený dedikovaný VMware Cluster Architektúra je znázornená na nasledovnom obrázku: Architektúra cloudového prostredia umožňuje realizovať maximálne 4 nezávislé prostredia, ako je znázornené na nasledovnom obrázku. Obrázok č. 2 Prostredia vládneho cloudu súčasný stav

18 Vyššie znázornené prostredia sú automaticky vytvárané pri využívaní služieb cez existujúci samoobslužný portál postavený nad OpenStack-om. Z pohľadu administrácie cloudu, riadenie celého životného cyklu aplikácie (resp. ISVS) začína vývojom, testovaním, pokračuje nasadením a prevádzkou až po archiváciu. V súčasnosti sú tieto aktivity pre projekty realizované vo verejnej správe vo veľkej miere pod kontrolou dodávateľa konkrétnej aplikácie, keďže štátne organizácie nemajú technické a predovšetkým ľudské kapacity. ISVS sú síce prevádzkované v datacentrách inštitúcii verejnej správy, avšak reálne sú často krát spravované (najmä pri zložitejších systémoch) pôvodným dodávateľom. Výsledkom býva závislosť od dodávateľa, neprehľadnosť a rôznorodosť riešení (každý dodávateľ používa svoje frameworky), nekonsolidované aplikačné zdroje, ako aj problémy a oneskorenia pri nasadzovaní, prevádzkovaní a odstraňovaní chýb v aplikáciách. Procesy pre každú aplikáciu sú zväčša časovo náročné, jedinečné a nereplikovateľné, v podstate je nemožné nasadiť automatizáciu. Riziká Spresnenie identifikovaných rizík: R-4 Nedostatočná automatizácia R-5 Nízke využívanie služieb vzhľadom na neposkytovanie moderných služieb R-6 Nižšia efektívna utilizácia HW Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Technologická architektúra Tabuľka 7 Technologická architektúra aktuálny stav Súhrnný popis

19 Súčasný stav predstavuje v podstate technologickú architektúru riešenia IaaS, založeného na technológii OpenStack, pričom rovnaké riešenie je nasadené v oboch DC, MVSR aj MFSR. Obidve lokality sú navzájom prepojené a riešenie umožňuje replikáciu dát medzi oboma centrami, Súčasťou HW architektúry je aj orchestračná platforma na správu IaaS infraštruktúry. Riziká Spresnenie identifikovaných rizík: N/A Prílohy Diagramy, modely, obrázky v plnom rozlíšení Bezpečnostná architektúra

20 Tabuľka 8 Bezpečnostná architektúra aktuálny stav Súhrnný popis Bezpečnostnú architektúru cloudového riešenia IaaS tvoria: softvérovo definované siete oddeľujúce jednotlivé prostredia a riešenia, automatizácia konfigurácie siete, nasadené firewall na jednotlivých segmentoch siete, prístup z externých sietí do vrstvy DMZ je chránený dvojicou firewall-ov a dvojicou IPS od rôznych výrobcov, prístup z externých sietí do vrstvy DMZ musí byť špecificky povolený a definovaný a zároveň sa aplikuje definovaná komunikačná matica, možnosť prepojiť projekt v cloude so sieťou zákazníka pomocou zabezpečeného site to site VPN tunela hybridný model cloudu, centrálne zbieranie a spracovanie bezpečnostných udalostí a incidentov v systéme SIEM, implementovaná DOS ochrana na vstupe z externých sietí, redundancia sieťových a bezpečnostných prvkov N+1. Riziká Spresnenie identifikovaných rizík: R9: Neexistencia bezpečnostného projektu vládneho cloudu Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Prevádzka Tabuľka 9 Prevádzka aktuálny stav Súhrnný popis Prevádzka IaaS vládneho cloudu je v súčasnosti zabezpečovaná pracovníkmi MV SR pre obidve lokality Tajov a Kopčianska. MF SR poverilo výkonom prevádzky MV SR za lokalitu Kopčianska, datacentrum Kopčianska je naďalej v správe MF SR. MV SR zabezpečuje prevádzku a podporu pracovníkmi SITB, vrátane procesu implementácie projektov na úrovni IaaS. Poskytované sú aj služby podpory cez Call Centrum MV SR, ako aj prostredníctvom implementovaného systému Service Desk, ktorý je dostupný pre odberateľov a kde je možné evidovať jednotlivé incidenty. Zabezpečenie prevádzky pracovníkmi MV SR je v súčasnosti v režime 15/5 od 7:00-22:00hod, zabezpečenie celého procesu poskytovania služieb IaaS prevádzkou je v režime 8/5. Samotná prevádzka technológií vládneho cloudu v režime vysokej dostupnosti je zabezpečená v režime 24/7, 98%. V súčasnosti prebieha obstaranie SLA na podporu prevádzky vládneho cloudu. Služby IaaS, ktoré vládny cloud v súčasnosti poskytuje sú dostupné v MetaIS aj na stránke sk.cloud v katalógu služieb. Okrem služieb IaaS sú pre prevádzkovateľa dostupné aj nasledovné služby: Intrusion Prevention System, Intrusion Detection System, DDos ochrana, Network Behavioral Analysis, Security Information & Event Management, monitoring. Riziká Spresnenie identifikovaných rizík: R-7Prevádzka nie je dostatočne pokrytá internými pracovníkmi, čo brzdí operatívu aj rozvojové projekty R-8 Nedostatočná forma dodávateľskej podpory môže mať za následok dlhšie odstraňovanie problémov

21 Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká 2.3. Alternatívne riešenia Cieľom tejto štúdie je preskúmať a definovať možnosť vybudovania softvérového riešenia poskytujúceho služby PaaS nad už vybudovaným IaaS vládneho cloudu, ktorý sa nachádza v dvoch lokalitách. Riešenie PaaS bude budované ako nadstavba súčasného cloudu a teda bude v plnej miere využívať služby a možnosti oboch vybudovaných dátových centier, pričom musí rešpektovať aj ich obmedzenia. Možnosti technického riešenia už vybudovaných cloudových centier teda de facto predstavujú požiadavky na budúce riešenie PaaS, ktoré je predmetom tejto štúdie uskutočniteľnosti. Toto technické riešenie je rámcovo popísané v tejto časti. NKIVS 2016 aj dokument Strategická priorita Vládny Cloud (ďalej aj ako SP Vládny Cloud") uvádzajú nasledovné skupiny služieb: Toto základné delenie rozširuje dokument SP Vládny Cloud na nasledovné skupiny uvedené na obrázku

22 Jedná sa o nasledovné skupiny služieb: služby prezentačnej vrstvy, služby integračnej a orchestračnej vrstvy, služby aplikačnej vrstvy, služby databázovej vrstvy, služby bezpečnosti, služby monitoringu a manažmentu. Je potrebné dodať, že tento dokument neadresuje všetky požiadavky dokumentu SP vládny cloud, ktorý je veľmi široký a obsahuje veľmi veľa užitočných a progresívnych požiadaviek. Implementáciou všetkých požiadaviek by projekt narástol do veľmi veľkého rozsahu, čo je v protiklade s cieľmi v NKIVS (čo najmenšie projekty). Avšak vzhľadom na skúsenosti a ponaučenia z implementácie rozsahovo veľkých (aj cloudových) OPIS projektov bol zvolený prístup postupnej implementácie a rozdelenia projektov na menšie časti. To znamená, že v uvažovanom projekte bude implementovaná iba časť požiadaviek (uvedené v tejto štúdii v kapitole Služby z katalógu cloudových služieb), ktoré odhadovo prinášajú najvyšší úžitok za vynaložené prostriedky (tzv. "low hanging fruit"). Z dokumentu SP vládny cloud nie sú adresované nasledovné oblasti: workflow funkcionalita, logovanie udalostí (dostupné iba interne), processing údajov a analytika. Ďalšia funkcionalita bude pridávaná na základe skúseností z implementácie a prevádzky postupným rozvojom riešenia a inkrementálnym rozširovaním poskytovaných služieb. Niektoré služby a celá PaaS platforma môžu byť na začiatku poskytované v režime beta", až kým MVSR nenazbiera dostatok skúseností s ich prevádzkou. Súčasťou projektu bude aj fáza PoC a následná pilotná prevádzka, ktorá vyústi ukončením projektu do beta prevádzky. Doba beta prevádzky bude závislá od prevádzkových skúseností MVSR s platformou a poskytovaním služieb. Pôvodný koncept stanovoval rozvoj dvoch hlavných dátových centier, ktoré budú tvoriť základ vládneho cloudového riešenia, a ktoré budú medzi sebou prepojené pre účely zálohovania a následnej možnej obnovy - tzv. disaster recovery. Aktuálne prebehli kroky, aby sa obidve centrá zjednotili pod prevádzkou MVSR a tým pádom vystupovali ako jeden egov Cloud v dvoch geografických lokalitách. Tento cloud bude mať zároveň aj jeden spoločný katalóg služieb (momentálne sú k dispozícii iba služby IaaS). Pre všetky varianty riešenia platia nasledovné požiadavky: využitie, rozvoj a integrácia existujúceho cloudového riešenia vrátane samoobslužného portálu pre zriadenie a rušenie služieb,, zabezpečenie funkcionality natívnej PaaS platformy, rozvoj centrálnych komponentov pre iné ISVS, rozvoj interných služieb IaaS súvisiacich s PaaS, nevyhnutnou súčasťou sú procesy devops a governance a ich zavedenie do prostredia MVSR, možnosť integrácie riešenia s verejným cloudom, riešenie musí byť založené na existujúcich komponentoch (open source, alebo komerčných) s obmedzeným vlastným vývojom, pričom cieľom

23 tejto požiadavky je, aby riešenie bolo podľa možností čo najviac štandardné, riešenie musí predstavovať systém na správu PaaS platformy spolu s manažovaným poskytovaním vendorských a open source SW licencií prevádzkovaných na virtualizačnej platforme IaaS. Z prieskumu využívania PaaS služieb (založených najmä na Cloud Foundry a Openshift) vyplýva, že k nasadeniu sa pristupuje opatrne a tieto služby sa spočiatku využívajú najmä na aplikácie s menšou úrovňou kritickosti. Ďalej teda porovnávame predovšetkým tieto dve alternatívy, ktoré majú najviac referencií v prostredí verejnej správy. Jedným z kritérii ich výberu bola tiež lokálna dostupnosť podpory, čo oba produkty spĺňajú. Krajina PaaS riešenie Typ nasadenia Zdroj USA Cloud Foundry Na verejnom Amazon cloude UK Cloud Foundry Na verejnom Amazon cloude Holandsko Cloud Foundry Na verejnom Pivotal cloude Belgicko OpenShift Vlastný privátny cloud Estónsko Ericsson Hyperscale hybridný cloud Austrália Cloud Foundry Na verejnom Amazon cloude Kanada - BC OpenShift Vlastný privátny cloud Alternatíva A Platforma vyskladaná z open source komponentov pre poskytovanie kontajnerov, služieb a softvéru" Tabuľka 10 Alternatíva A Súhrnný popis Táto alternatíva prináša služby PaaS vo forme predpripravených riešení komerčného a open source softvéru jednotlivým odberateľom služieb. Riešenie bude vybudované ako platforma pozostávajúca z ucelenej sady nástrojov umožňujúca vývoj, deployment a manažovanie cloudových aplikácií. Riešenie musí zároveň umožniť automatizovaný provisioning a správu celého stacku (s využitím existujúceho OpenStack) vrátane poskytovaných nástrojov, middlewaru, všetkých prostredí, licenčného komerčného a opensource sw pre všetky agendové projekty a systémy verejnej správy SR. Riešenie bude využívať jednotný systém DevOps, procesný a aplikačný model pre kontinuálne integrácie a delivery procesy s využitím definovaných opensource a komerčných produktov. Riešenie bude poskytovať podporu pre vývoj, manažovanie, buildovanie, deploying a testovanie aplikácíi. Súčasťou riešenia je aj platforma vyskladaná z open source nástrojov na manažovanie kontajnerov, ktorá nebude dodávaná vendorom, ale bude vyskladaná z vhodného mixu open source komponentov (napr. Kubernetes). Nevyhnutnou súčasťou tohto riešenia je aj zavedenie SAM (Software Asset Management) procesov (bližšie popísaných v časti Pay per use) a zmluvné ošetrenie poskytovania komerčného SW. Predpokladom tohto riešenia je rozšírenie služieb IaaS: služby zálohovania a archivácie pre celú infraštruktúru s aplikačným rozhraním dostupným pre prevádzkované aplikácie ISVS. Súčasťou tohto riešenia je aj: unifikovaný reportingový nástroj, meranie využívania licencií vrátane prepojenia na reportingový nástroj, služby logovania s aplikačným rozhraním dostupným pre prevádzkované aplikácie ISVS, služby IAM a správy užívateľov s aplikačným rozhraním dostupným pre prevádzkované aplikácie ISVS, jednotný manažment API rozhraní poskytovaných prostredníctvom PaaS služieb (vrátane kontroly bezpečnostných pravidiel pri volaniach API a poskytovania služieb Identity Mediator) vyhodnocovanie spätnej väzby od používateľov, vrátane definície a vyhodnocovania SLA a KPI, zavedenie governance a devops procesov, štandardizácia procesov aplikačného vývoja.

24 Výhody: menej komponentov ako v alternatíve B a tým pádom potenciálne jednoduchší systém, dobrá znalosť riešenia (OpenStack) a skúsenosť s prevádzkou, jednoduchšia integrácia na existujúcu infraštruktúru vladneho cloudu, vyšší stupeň automatizácie, správa celého stacku a efektívnejšie využívanie HW a SW zdrojov vládneho cloudu, potenciálne nižšia cena, menšia náročnosť na prevádzku a z toho vyplývajúce personálne požiadavky. Nevýhody: nižšia podpora aplikačných developerov a nižšia efektivita vývoja a manažovania cloud-natívnych aplikácií - iba poskytovanie kontajnerov, nespĺňa plne duch zadania (NKIVS a SP Vládny cloud), predovšetkým ciele ako automatizáciu procesov kompilácie, nasadzovania a testovania Alternatíva B Natívna PaaS platforma pre PaaS služby, kontajnery a SW licencie" Tabuľka 11 Alternatíva B Súhrnný popis Toto riešenie predstavuje kombináciu riešenia A a implementáciu PaaS platformy ako jedného z dvojice produktov Cloud Foundry alebo Openshift. Tieto produkty budú nasadené nad platformou OpenStack existujúceho Vládneho cloudu. PaaS bude vybudovaná ako kombinácia pozostávajúca z platformy umožňujúcej vývoj, deployment a manažovanie aplikácií v cloude s využitím kontajnerových technológií ( Cloud Foundry / Openshift ) pri vývoji napr. web nekritických aplikácií a ucelenej sady nástrojov umožňujúce vývoj, deployment a manažovanie cloudových aplikácií. Táto časť zároveň musí umožniť automatizovaný provisioning a správu celého stacku vrátane poskytovaných nástrojov, middlewaru, všetkých prostredí, licenčného komerčného a opensource sw pre všetky agendové projekty a systémy verejnej správy SR. Riešenie bude využívať jednotný systém DevOps (t.j. jednotný devops tím spravujúci všetky aplikácie nasadené na PaaS platforme), procesný a aplikačný model pre kontinuálne integrácie a delivery procesy s využitím definovaných opensource a komerčných produktov. Kontajnerová platforma sa bude implementovať v dlhšom časovom intervale vzhľadom na vyššiu zložitosť a najmä potrebu implementácie školenia a zavedenia procesov prevádzky celej platformy. Súčasťou projektu je aj osveta, školenia a podpora pre konzumentov PaaS služieb, ako aj odbornej verejnosti (dodávateľov implementácii pre konzumentov služieb)- Nasadenie samotnej platformy sa predpokladá súčasne s ostatnými komponentmi, avšak v režime public beta", do ostrej prevádzky bude spustená až po zavedení všetkých relevantných procesov a získaní skúseností. Počas tejto doby bude k dispozícii zvýšená podpora dodávateľa riešenia.

25 Súčasťou tohto riešenia pre oblasť aplikácii a služieb nad IaaS a PaaS je aj: začlenenie monitoringu využívania a záťaže jednotlivých hlavných komponentov súčasného IaaS riešenia (ktorého dáta musia byť sprístupnené IaaS), unifikovaný reportingový nástroj, meranie využívania licencií vrátane prepojenia na reportingový nástroj, prideľovanie zdrojov doplnenie funkcionality za účelom lepšieho riadenia zdieľania a poolingu zdrojov súčasných cloudových služieb pre natívny PaaS, lepšie pokrytie zálohami (momentálne riešenie pokrýva iba zálohy VM), dostupnosť zálohovania aj pre odberateľov služieb, vyhodnocovanie spätnej väzby od používateľov, vrátane definície a vyhodnocovania SLA a KPI, zavedenie governance a devops procesov. Výhody: platforma, ktorá obsahuje technológiu kontajnerov umožní výraznú podporu developerom a teda efektívnejší vývoj a prevádzku cloud natívnych aplikácií v súlade s aktuálnymi trendmi v oblasti IT, obe riešenia (OpenShift, Cloud Foundry) predstavujú súbor navzájom integrovaných produktov, ktoré fungujú a dostávajú aktualizácie ako celok, čiže nie je potrebné realizovať vzájomné integračné testovania, ktoré sú nutné pri každej čiastkovej aktualizácii, možnosť postupného pridávania služieb a rozširovania katalógu podľa schopností prevádzky a skúseností. Nevýhody: implementácia a prevádzka ďalšieho technologického celku, potreba odborného a kapacitného rozšírenia prevádzkového tímu, zložitejšia prevádzka. OpenShift vs. Cloud Foundry Obidve platformy poskytujú riešenie, ktoré je možné prevádzkovať in-house na vlastnom HW. V prípade OpenShift je to buď komerčné riešenie priamo do OS Redhat vrátane supportu OpenShift Container Platform", alebo čistá open source edícia OpenShift Origin (ktorá však neobsahuje všeky nástroje ako Container Platform edícia). V prípade Cloud Foundry je taktiež možné použiť čisté Open Source riešenie. Ďalej sú k dispozícii rôzne ponuky priamo od výrobcu Pivotal, ale aj od tretích strán ako IBM, Atos a iné, ktoré však predstavujú cloudové riešenie, vedia však riešenie nasadiť aj na privátnom cloude. Na základe prieskumu (napr. aj tu sa javí, že z technického hľadiska sú obidve platformy porovnateľné. Odporúčanie je teda výber platformy na základe TCO riešenia a predovšetkým na základe možnej podpory priamo od výrobcu. Odhad ceny RedHat OpenShift RedHat poskytuje produkt Red Hat OpenShift Container Platform Standard Support, ktorého cenníková cena je Eur za 2 jadrá pri platbe podpory na 3 roky. Z toho vyplýva, že jedno jadro stojí Eur ročne. RedHat poskytuje aj Premium support, kde hlavným rozdielom je podpora 24x7, tu cena vychádza na Eur pri platbe na 3 roky. Pri odhadovanej konfigurácii 96 jadier vychádza ročná cena Eur bez DPH ročne pri Standard support a Eur bez DPH ročne za Premium support. Odhad ceny Cloud Foundry Cloud Foundry je softvér poskytovaný rôznymi vendormi, ako napr. Pivotal, Atos, IBM, a i. Cenová ponuka od firmy Pivotal na 50 inštancií (projektov) je nasledovná Pivotal Cloud Foundry Operations Manager (Foundation) - $28,281 ročne Pivotal Application Service (Elastic Runtime) - $157,140 ročne za 50 inštancií Pivotal Services Suite for Pivotal Cloud Foundry (voliteľná položka) - $128,570 ročne na 25 inštancií. súčasťou prvého nákupu sú aj jednorazové tzv. Dojo služby v cene $100,000 - predstavujú de fakto tréningy. Táto alternatíva predstavuje kombináciu alternatívy A s natívnou kontajnerovou PaaS platformou, pričom vzájomným doplnením sa eliminuje väčšina nevýhod, ktoré boli spomenuté pri alternatíve A. Doplnením cloud natívnej platformy OpenShift/Cloudfoundry sa zároveň vytvárajú predpoklady na postupnú modernizáciu štátneho IT, avšak benefity môžu byť realizované hneď súčasne s využívaním existujúcej IaaS platformy. Odberateľ služby si môže vybrať buď služby platformy IaaS alebo PaaS. PaaS platforma zase predstavuje potenciál do budúcnosti, keď sa budú vo vládnom cloude poskytovať služby umožňujúce vývoj a deployment aplikácií a služieb podľa najnovších trendov a best practice. Táto alternatíva PaaS umožňuje efektívne využívať HW a SW zdroje a motivuje odberateľov služieb budovať cloudové aplikácie v súlade s prijatou devops metodikou. Zároveň však s prevádzkou takejto platformy ani aplikácii na platforme nie sú v štátnom IT žiadne skúsenosti. Táto alternatíva si vyžaduje značné odborné a kapacitné posilnenie prevádzkového tímu vládneho cloudu. Z tohto dôvodu je súčasťou návrhu vybudovanie devops a governance tímov, bez ktorých riešenie nebude dlhodobo udržateľné Alternatíva C Platforma - Dodávateľské riešenie" Tabuľka 12 Alternatíva C

26 Súhrnný popis Táto alternatíva predstavuje nasadenie hotového riešenia od komerčných vendorov, akými sú technológie Microsoft Azure on premise, alebo Oracle Cloud Machine. Riešenie MS Azure stack Riešenie Azure stack predstavuje obraz verejného cloudu Azure s menšou kapacitou, prevádzkovaného na lokálnom hardvéri v sieti MVSR. Prostredie manažuje zákazník. K dispozícii sú všetky relevantné služby poskytované v Azure cloude. Riešenie je po viacerých meškaniach k dispozícii od októbra Riešenie Oracle Cloud Services Riešenie predstavuje službu od Oracle, ktorá zabezpečuje rovnakú funkcionalitu ako Oracle Public Cloud, avšak priamo v internej sieti dátového centra vládneho cloudu na dedikovanom hardvéri Oracle. Riešenie je spravované priamo Oraclom, čo znamená výraznú redukciu potrebných nástrojov, znalo a zdrojov. V prípade potreby je možné využiť prostredie verejného Oracle cloud prostredia, bez nutnosti rekonfigurácie platformy. K dispozícii sú služby najčastejš využívané v štátnej správe: Databáza ako služba, Aplikačný server ako služba, Integračná platforma/soa ako služba. Základné charakteristiky výpočtového modelu cloud@customer: 1.Jednoduchý, samoobslužný výber a aktivácia z predpripraveného katalógu služieb. 2.Elasticita a výkon na požiadanie. 3.Riešenie je poskytované formou predplatenej služby, t.j. náklady sú rozdelené na celé obdobie využívania služby. 4.Merateľnosť využívaných služieb - PaaS služby môžu byť spoplatnené formou pay-per-use"/pay-as-you-go, zákazník platí len za služby, ktoré využív a v čase, v ktorom ich naozaj používa; možnosť voľby spoplatnenia hodinovou, resp. mesačnou sadzbou. Porovnanie Oracle a Microsoft Oracle Cloud a MS Azure ako riešenia na lokálnom HW predstavujú obraz svojich verejných cloudov. Tieto aktuálne porovnával Gartner, ktorý ich znázornil aj na známom Magic Quadrant z júna Z tohto porovnania vyplýva, že Azure je jednoznačne vyspelejšie riešenie. Z pohľadu MVSR je nevýhodou Oracle aj fakt, že riešenie je manažované priamo Oracle-om a MVSR by teda nemalo nad riešením plnú manažérsku kontrolu, bolo by skôr používateľom ako v prípade verejného cloudu. Ako s možnou alternatívou teda štúdia v tejto alternatíve uvažuje iba s riešením MS Azure stack. Odhad ceny Azure stack V rámci porovnania alternatív bola v spolupráci s Microsoftom odhadnutá cena za Azure stack v konfigurácii 4 nodov, 96 jadier a 40TB diskového priestoru. Cena v prípade Azure stack pozostáva z dvoch hlavných položiek:

27 jednorázová cena za HW Eur - Azure stack (funguje iba na dedikovanom hardvéri, kupuje sa ako jeden celok (softvér spolu s hardvérom ako appliance). ročná cena za prevádzku, ktorá sa platí na základe reálneho využitia (ako v prípade cloud riešenia), v najhoršom prípade (t.j. plné využívanie celý rok) Eur. Výhody: Rýchle nasadenie, overené riešenie, dostupná podpora od jedného silného dodávateľa/výrobcu. Skúsenosti dodávateľov, keďže Azure má veľký podiel na trhu. Lacnejšie riešenie na začiatku - platí sa za základe reálneho využívania. Nevýhody: Nie je k dispozícii zdrojový kód. Riziko vendor lock-in", t.j. v prípade potreby veľmi zložitý prechod na alternatívne, resp. konkurenčné riešenie. Nemožnosť využiť existujúce zdroje vládneho cloudu, Pri vyššom využívaní vyššie ceny v porovnaní s konkurenciou. Rozdiel medzi alternatívou B a C je najmä v tom, že Azure stack nie je open source. Výhodou Azure riešenia však je, že prináša kópiu druhého najväčšieho cloud-u do privátneho cloudu, avšak aj s cenovým modelom podobným tomu, ako Microsoft účtuje za svoj verejný Azure cloud - formou Pa per use.čo znamená, že riešenie je lacnejšie na začiatku pri menšom využívaní, avšak samozrejme s väčším využívaním rastie aj cena za produkt.

28 Multikriteriálna analýza Jednotlivé alternatívy je možné realizovať pomocou viacerých produktov. Vyspelosť a používanosť produktov je znázornená na Magic Quadrant od Gartneru vyššie, ako aj na podobnom zobrazení G2 Crowd Grid pre PaaS ( ment=all) na obrázku nižšie. Obrázok č. 4 G2 Crowd Grid pre PaaS Multikriteriálna analýza porovnáva jednotlivé varianty na základe kritérií, ktoré boli zvolené ako najviac reprezentujúce potenciálne benefity a riziká celkového riešenia. Hodnotenia jednotlivých bodov boli spravené na základe expertného odhadu a prieskumu. Cieľom tejto multikriteriálnej analýzy bolo čo najjednoduchším spôsobom a transparentným spôsobom vyhodnotiť jednotlivé alternatívy riešenia. Dve KO kritéria boli vyznačené v tabuľke boldom. Tieto kritéria boli zvolená na základe toho, že MVSR aktuálne nemá skúsenosti s prevádzkou PaaS riešenia a preto je jednoduchosť prevádzky a dostupnosť silného lokálneho partnera kľúčová pre implementáciu a následnú úspešnú prevádzku. Tabuľka 13 Multikriteriálna analýza Alternatíva/Kritérium Alt. A Alt. B - Cloud Foundry Alt. B - OpenShift Alt. C - Azure Jednoduché aktualizácie a prevádzka Nie Áno Áno Áno Dostupnosť lokálneho partnera na podporu Nie Áno, s rizikom Áno Áno Schopnosť fungovať na existujúcom vládnom cloude Áno Áno Áno Nie Existujúce skúsenosti MVSR s podobnými riešeniami Nie Nie Nie Nie Riešenia v štátnej správe - referencie Nie Áno Áno Áno, s rizikom Multi-vendor (vrátane linuxu) Áno Áno Áno Áno Multi-tenant Áno Áno Áno Áno Dokumentácia Áno, s rizikom Áno Áno Áno Komerčná podpora Nie Áno, s rizikom Áno Áno

29 Open source Áno Áno Áno Nie Vysoká dostupnosť Áno, s rizikom Áno Áno Áno Výber alternatívy Z multikriteriálnej analýzy vyplývajú ako vhodné alternatívy B a C. Alternatívu B je možné vylúčiť z dôvodu, že nespĺňa KO kritérium jednoduchosť implementácie, prevádzky a aktualizácie spolu s dostupnosťou podpory. Alternatíva A je scenár, kde by PaaS platformu bolo možné realizovať aj prostredníctvom integrácie samostatných open source nástrojov, čo však predpokladá veľké nároky na skúsenosti a integráciu, čo v súčasných podmienkach predstavuje veľké riziko. Alternatíva B predstavuje implementáciu už integrovaného a overeného riešenia, ktoré je podporované a dostáva aktualizácie ako celok. Zároveň alternatíva B umožňuje oveľa rýchlejšie nasadenie a prevádzku, čo je v kontexte očakávaní ostatných OPII projektov kľúčové. Nezávisle od výsledku multikriteriálnej analýzy (kde ako prípustná vychádza iba alt. B) sa javí, že najvhodnejšou alternatívou je implementovať alternatívu B, ktorá predstavuje komponenty, služby a poskytovanie SW rozšírené práve o natívnu PaaS platformu. Z dôvodu efektívneho vynakladania s prostriedkami je nevyhnutné aby poskytované licencie spĺňali spôsob licencovania Pay-as-you-go, ako nevyhnutnú podmienku zaradenia na nich postavených služieb do katalógu poskytovaných služieb. Toto zabezpečí naplnenie cieľov NKIVS, umožní štátu poskytovať aj moderné služby založené na kontajneroch a tým pádom zmierniť technologickú medzeru medzi modernými komerčnými a štátnymi projektmi. Rozdiel medzi alternatívou C a alternatívou B je v type cloud natívnej PaaS platformy a v hardvéri, na ktorom platforma funguje. Cenový pohľad na altenatívy je súčasťou CBA Popis budúceho stavu Z uvažovaných alternatív bola vybraná alternatíva B: Natívna PaaS platforma pre PaaS služby, kontajnery a SW licencie Legislatíva Tabuľka 14 Legislatíva budúci stav Súhrnný popis Riešenie musí zabezpečiť súlad s nasledujúcimi právnymi predpismi: Výnos č. 55/2014 Z.z. o štandardoch. Zákon č. 275/2006 z.z. o informačných systémoch verejnej správy a o zmene a doplnení niektorých zákonov v znení neskorších predpisov, schváleným zákonom o Informačnej bezpečnosti (v gescii NBU SR), Zakon 305/2013 Z. z. o egovernmente. V rámci projektu by mali byť pripravené nasledovné nové predpisy alebo ich aktualizácie: doplnenie Výnosu č. 55/2014 Z.z. o štandardy pre vývoj cloudových aplikácii, nasadzovanie aplikácii v zmysle CI/CD, doplnenie Výnosu č. 55/2014 Z.z. o nové štandardy, ako napr. REST, JSON, kontajnery, serverless služby, 12 faktorová aplikácia, atď., Počas projektu bude nutné sledovať a pripomienkovať nasledovné legislatívne normy, tak aby nevznikli legislatívne prekážky pri prevádzke ISVS vo vládnom cloude.: Pripravovaným zákonom o ITVS, ktorého zámer bol pripravený a odporúčaný MFSR na schválenie vláde SR. Kritériá kvality Spresnenie kritérií kvality: Q-1.1, Q-1.2 Q-1.1: Navrhnuté zmeny legislatívy v MPK Riziká Spresnenie identifikovaných rizík: R-1.1, R-1.2

30 R-1.1: Legislatívna príprava bude meškať, respektíve zmeny nebudú schválené v požadovanej forme R-1.2: Politické riziko pri zmene vlády Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Tabuľka 3 Výstupy projektu a kritéria kvality Architektúra V tejto časti je popísaná architektúra vybraného riešenia. Všetky mená uvedených produktov sú ilustratívne, použité za účelom lepšieho popisu, čo má dané riešenie spĺňať. V prípadnom verejnom obstarávaní môže uchádzač použiť ekvivalentné, alebo podobné produkty, resp. riešenia Biznis architektúra Tabuľka 15 Biznis architektúra budúci stav Súhrnný popis Nové riešenie z biznis pohľadu predstavuje rozšírenie katalógu cloudových služieb dostupných pre odberateľov, s čím súvisí aj rozvoj interných služieb, procesov a governance. Riešenie je možné rozdeliť do nasledovných logických celkov, ktoré svojou súčinnosťou podporujú efektívne fungovanie celej platformy a teda poskytovanie služieb odberateľom: rozvoj IaaS služieb vládneho cloudu za účelom integrácie IaaS a PaaS častí, implementácia natívnej PaaS platformy založenej na Cloud Foundry alebo Openshift, poskytovanie predpripravených PaaS centrálnych komponentov pre iné ISVS, poskytovanie softvérových licencií a podpory pay per use/pay-as-you-go model, rozvoj devops nástroje, ľudia a procesy, rozvoj governance procesov. Z hľadiska biznis architektúry je poskytovanie PaaS služieb založené na využívaní už existujúcich IaaS služieb dátového centra MVSR. Občan používa služby aplikácie, ktorá je prevádzkovaná príslušným OVM správcom ISVS. Ak sa správca riadi princípom cloud first", tak jeho ISVS používa služby platformy, ktoré poskytuje MVSR nad svojím dátovým centrom ako PaaS. Ak je ISVS vybudovaný podľa princípov, ktoré pre plné využívanie PaaS vyžaduje, tak správca ISVS sa nemusí starať o administrátorské" činnosti od správy HW až po úroveň aplikačného servera. Správca zabezpečuje vytvorenie aplikácie a jej nasadenie pomocou nástrojov PaaS. SLA parametre služieb Súčasťou každej služby v katalógu je aj úroveň, s akou bude príslušná služba poskytovaná. Návrh parametrov služieb pripravuje prevádzkovateľ a odsúhlasuje medzirezortný orgán pozostávajúci z UPVII a MVSR. Nevyhnutnou súčasťou SLA problematiky je aj interné meranie úrovne definovaných parametrov služieb a ich prezentácia na status" stránke dostupnej pre odberateľov služieb. MVSR výhľadovo pri PaaS ráta aj s nasadením aplikácii a platforiem ako: procesná platforma, integračno-orchestračná platforma, prípadne aj CSRÚ, alebo IS_RPaD.

31 Obrázok č. 5 Biznis architektúra PaaS 3. Správa a riadenie - governance Nevyhnutnou súčasťou prevádzky je aj správa životného cyklu cloudového riešenia PaaS ako aj samotných aplikácii, ktoré sa v ňom nachádzajú a vzťahov s odberateľmi. Tento fakt je dôležitý najmä z dôvodu absencie platieb za využívanie služieb, t.j. odberatelia nebudú priamo finančne motivovaní optimalizovať svoje alokácie ako aj využívanie cloudu. Toto sa týka nielen PaaS služieb, ale najmä IaaS služieb, ktoré sú zo svojej povahy menej zdieľané. Procesy správy a riadenia (governance) sú popísané v častiach nižšie. Na správu a riadenie cloudu by mal byť zriadený medzirez ortný orgán, kde by boli zastúpene MVSR a UPVII. Rada orgánu by vykonávala dohľad nad katalógom služieb, navrhovala nové služby a odsúhlasovala rušenie nepoužívaných služieb.

32 3.1. Komunikácia a správa vzťahov s odberateľmi služieb Správa vzťahov s odberateľmi služieb zahŕňa: kontakt s odberateľom služby, dohadovanie kontraktu, udržiavanie dobrých vzťahov a podpora, monitorovanie sťažností Riadenie rizík a klasifikácia aplikácii Každá aplikácia pred povýšením do prevádzky musí prejsť klasifikáciou a ohodnotením rizík. Hodnotiť by sa mali minimálne nasledovné parametre: kritickosť, RPO, RTO, potenciál napadnutia útokom, škálovateľnosť a výkon, predpoklad zaťaženia zdrojov v čase Správa alokácii Najefektívnejším alokačným mechanizmom sú vo všeobecnosti peniaze. Keďže služby štátneho cloudu sú poskytované bezodplatne, je potrebné tento mechanizmus nahradiť iným. V PaaS vrstve vládneho cloudu budú zdroje iniciálne schvaľované prevádzkovateľom na základe objednávky od odberateľa služby po úspešnom absolvovaní výkonnostných, prípadne aj bezpečnostných testov. Neskôr však budú manažované na základe merania pod správou prevádzkovateľa, t.j. dynamicky riadené zdroje v čase (kombináciou automatických a manuálnych zásahov) Správa súladu s legislatívou a pravidlami Proces správy súladu s legislatívou je governance procesom, ktorý pomocou neustáleho dohľadu zabezpečuje zhodu medzi legislatívou a poskytovanými službami, resp. spôsobom ich používania. Z tohto pohľadu je relevantné najmä nariadenie GDPR účinné od , zákon o ISVS (resp. v budúcnosti zákon o ITVS a výnos o štandardoch 3.5. Priebežná údržba katalógu služieb Priebežné pridávanie a odoberanie služieb na základe dopytu a výsledkov merania využívania existujúcich služieb. 4. Poskytovanie a správa licencií V strategickej priorite Vládny cloud bolo načrtnutých viacero možností, ako budú nakupované a poskytované komerčné licencie za účelom ich poskytnutia odberateľom služieb. Boli to:

33 centrálny nákup výhradne iba SW licencií, inštalácia odberateľom služby, PaaS platforma s predplatenými licenciami SW produktov, ktoré sú priamo k dispozícii, pay per use/pay-as-you-go" model, pri ktorom sa predpokladá inštalácia a príprava komerčného SW na využitie v PaaS (t.j. ako turn-key solution), avšak platiť sa bude iba za využívaný SW. Medzi ďalšie uvažované možnosti patrili aj: kompletné zabezpečenie licencií odberateľom (súčasná situácia) Pay per use model Vzhľadom na menšiu ako očakávanú rýchlosť migrácie existujúcich ISVS do cloudu a s tým spojenú menšiu vypovedaciu hodnotu analýzy štátneho IKT a využívaných SW produktov je pravdepodobnosť spoľahlivej predpovede, aké produkty budú na PaaS platforme využívané, pomerne nízka. Zároveň sa na trhu s cloudovými službami presadzuje model platby za skutočne využívané zdroje, resp. licencie (on demand, pay per use, Pay per use, časové tarifikácie atď). Vzhľadom na tento fakt, bol zvolený model Pay per use. S jeho využitím sa ráta na: komerčné licencie a support, open source licencie, resp. ich support. V prípade implementácie modelu pay-per-use/pay-as-you-go je nevyhnutné dohodnúť právny a technologický rámec poskytovania služieb a dosiahnuť konsenzus so zapojenými dodávateľmi. Rozumným návrhom je model tarifikácie - t.j. platby za každú použitú licenciu a časový interval (rok, pol roka, mesiac, deň), pričom pod použitou licenciou sa myslí reálne použitie definovanej kapacity/výkonnosti licencie v produkčnom prostredí odberateľom služby. Meracie obdobie - časový interval bude každým zúčastneným vendorom za produkt. Je potrebné poznamenať, že zaradenie do katalógu je podmienené uzatvorením dohody s vendorom ohľadom konkrétneho produktu, ktorá bude definovať aj rámcové detaily spôsobu merania tarifikácie. Nevyhnutnosťou je mať robustný proces správy SW licencií (Software Asset Management SAM) popísaný v ďalšej časti a podľa dohody s výrobcami aj jeden až niekoľko meracích nástrojov merajúcich reálne využitie licencií ktorému bude výrobca dôverovať vrátane podkladov pre alokáciu spotrebovaných licencií jednotlivými OVM. V prípade potreby iných SW ako budú poskytované prostredníctvom PaaS je možnosťou inštalácia odberateľom služieb na zdroje získané cez IaaS služby (t.j. na virtuálny stroj vo vlastnej správe). Obstaranie produktu bude v zodpovednosti odberateľa služby. Pri produktoch poskytovaných cez Pay per use model bude administrácia, patchovanie a údržba SW zabezpečená z pohľadu odberateľa služby transparetne. Počíta sa s nasledovnými možnosťami: open source produkty, pri ktorých bude možné tieto činnosti efektívne automatizovať, budú činnosti zabezpečené automaticky, resp. budú priamo súčasťou cloud natívnej platformy, komerčné produkty a produkty, pri ktorých bude autmatizácia technicky zložitá budú aktualizácie, inštalácie a údržba vykonávané manuálne, resp. automaticky s prispením administrátora z devops tímu. Návrh produktov, ktoré budú poskytované ako platforma prostredníctvom katalógu služieb, je nasledovný: Databázová vrstva: MS SQL, IBM DB2, Oracle DB, PostreSQL, MySQL, MongoDB. Prezentačná vrstva: Wordpress, Drupal, MS Sharepoint. Aplikačná vrstva: Tomcat, Node.js, Nginx, Apache, IBM WAS, MS IIS, MS Exchange (ako PaaS služba, predpokladom je, že bude prevádzkovaný jeden v multitenant režime), Oracle Weblogic Suite. Integračná vrstva

34 Oracle SOA Suite, WSO2. Tento návrh produktov obsahuje iba obmedzený počet SW, resp. aplikácii, s cieľom mať jednoduchú implementáciu a spustenie služby pay-as-you-go. Po overení funkčnosti a poskytovaní služieb môže byť SW doplnený. Keďže katalóg poskytovaných produktov bude dynamický riešenie by malo umožniť pridávať a odoberať produkty z katalógu administrátorským zásahom, resp. inštaláciou príslušného komponentu (alebo doplnením VM/kontajnerového repozitáru). Tento katalóg produktov bude súčasťou katalógu cloudových služieb a bude podliehať rovnakému procesu životného cyklu. Táto štúdia ráta s rýchlym a dynamickým pridávaním a odoberaním poskytovaných SW v pay-as-you-go režime z katalógu na základe potrieb a reálneho dopytu, pričom overenie dopytu by sa udialo vždy zaradením nových služieb (SW) v beta" režime. Voliteľne bude (na začiatku v beta" režime) poskytované aj priebežné patchovanie poskytovaného softvéru. Na základe zastúpenia dodávateľov v štátnej správe boli oslovení traja najväčší dodávatelia SW. Pay per use Microsoft Microsoft má štandardné licenčné programy pokrývajúce poskytovateľov cloudových služieb, pričom je možné využiť nasledovné možnosti: Cloud service provider (CSP) model, kde sa platí formou Pay per use na mesačnej báze, toto je program primárne pre poskytovateľov cloudových služieb, pričom pri priamom porovnaní je cena vyššia ako pri klasickom nákupe licencií. SPLA Services Provider License Agreement podobný model ako CSP, staršieho typu, kde pri priamom porovnaní je cena vyššia ako pri klasickom nákupe licencií. Enteprise agreement (EA) - je programom pre klasický nákup licencií pre veľké organizácie a štátnu správu, kde sa platí cena na tri roky, je tu však možnosť využiť presun licencií medzi jednotlivými subjektmi verejnej správy a optimalizovať ich týmto spôsobom, čo môže byť zaujímavé najmä vzhľadom na veľkosť celej štátnej správy. Kombinácia vyššie uvedených. V súčasnosti prebiehajú rokovania o novej zmluve štátu s Microsoft-om ohľadne desktopových licencií pre štátnych zamestnancov. Prípadná zmluva MVSR na serverové licencie by mohla byť súčasťou tohto rokovania za predpokladu, pričom motiváciou je predpoklad vyrokovania lepšej ceny. Tieto modely by mali byť priebežne posudzované a ich biznis case vyhodnotený pre každý produkt v rámci procesu SAM. Pay per use IBM IBM má viacero licenčných modelov v závislosti od produktov, ktoré sú prenositeľné na cloud (Azure, Amazon, IBM Bluemix atď.). Tieto modely sú po dohode aplikovateľné aj na budované PaaS riešenie a poskytovanie SW licencií v prostredí vládneho cloudu. IBM zároveň poskytuje možnosť Pay per use na mesačnej báze, finálna dohoda a zmluva s MVSR však musí byť predmetom rokovaní a je predpokladom implementácie tejto časti PaaS a zapojenia vendora do riešenia. Pay per use Oracle Oracle má viacero licenčných modelov pre celú škálu cloud služieb IaaS a PaaS pre koncových zákazníkov. Medzi základné patrí Metered cloud services, služba je platená podľa aktuálnej spotreby meranej v hodinách, alebo mesiacoch, alebo non-metered, kedy je daná služba predplatená na dané obdobie. Tieto služby sú však poskytované priamo nad Oracle cloudom, alebo pomocou tzv. Oracle cloud machine, čo predstavuje podobný koncept ako Azure on premise od Microsoftu. Z hľadiska klasického licenčného modelu (on-premise) pripadá do úvahy štandardná licenčná zmluva Oracle, kde je možné zakúpiť licencie na definovaný objem CPU, podľa štandardnej licenčnej metriky minimálne na 1 rok (s 1 ročným supportom). Je potrebné vziať do úvahy obmedzenia na typ použitej virtualizácie, resp. takzvaného partitioningu CPU, kde je možné použiť ako hard paritioning LPAR na platforme IBM Power. Tento model je relevantný aj pre PaaS riešenie MVSR. V tejto oblasti je v zmysle vyššie uvedeného návrhu poskytovania a prevádzky SW pre odberateľov potrebné zabezpečiť automatizáciu pomocou nasledovnej funkcionality:

35 repozitár VM, resp. docker kontajnerov s predpripraveným komerčným a open source softvérom pomocou OpenStack, resp. cloud natívnej PaaS platformy, platformu na automatizáciu poskytovania a údržby komerčných a vybraných open source licencií Proces manažovania softvérových licencií software asset management Nevyhnutným predpokladom dobrej správy licencií je zavedený proces manažovania licencií, tzv. software asset management (ďalej aj ako SAM"), ktorý by mal byť pokrytý internými pracovníkmi MVSR. Súčasťou by mali byť: procesy SAM vrátane manažmentu kontraktov s vendormi aj odberateľmi služby, inventory manažmentu, manažmentu súladu s licenčnou politikou, manažmentu požiadaviek, nasadzovanie aplikácii a optimalizácie licenčného modelu odberateľa služieb ako aj celkového licenčného modelu cloudu MVSR, podmienky využívania služieb PaaS/IaaS, ktoré budú zahŕňať celý životný cyklus služby (a napr. pokryjú skutočnosť, že VM nepoužívané viac ako určitú definovanú dobu budú reportované a môžu byť pokynom vymazané/odzálohované, aby na nich neboli zbytočne alokované licencie, ktoré môžu byť prepoužité inde), dedikovaný tím, ktorý bude schvaľovať, optimalizovať, kontrolovať a poskytovať konzultácie ohľadom využívania komerčného a open source softvéru a ich podpory pre odberateľov služieb, monitorovacie nástroje využívaného/nasadeného softvéru, monitorovacie nástroje, ktoré budú v reálnom čase dohliadať na metriky, ktoré budú pre každý typ SW dopredu dohodnuté (vyťaženie jadier, konkurentní používatelia a pod.) v rámci dohody s príslušnými vendromi o pay-as-you-go. Ďalšou možnosťou kooperácie s dodávateľmi licencií je sprístupnenie výstupov SAM, napríklad reportov, prípadne audit procesov za účelom uistenia dodávateľov licencií o ich vyspelosti a dôveryhodnosti. Z pohľadu SW vendora prichádzajú do úvahy nasledovné možnosti, resp. ich kombinácie: na základe inštalácie (napr. logovanie na základe toolu, vykoná nasadenie SW pre odberateľa služby), self monitoring a poskytovanie reportov SW vendorom, pravidelné audity zo strany SW vendorov, vzdialený monitoring/auditing, kombinácia vyššie uvedených možností. Vendori potvrdili svoju pripravenosť poskytovať licencie tu popísaným modelom (pay-as-you-go platba za inštaláciu) om IBM dňa a Microsoft dňa Predpokladá sa požadovať platba za aktívnu inštaláciu bežiacu vrámci definovanej jednotky času. Spoločnosť Oracle do času spracovania štúdie tento model nepotvrdila. Kritériá kvality Spresnenie kritérií kvality: Q -2.1, Q-2.2, Q-2.3, Q-2.4 Q-2.1Miera úplnosti a optimalizácie procesov Q-2.2 Miera splnenia požiadaviek NKIVS Q-2.3 Jednoduchosť a nízka komplexita riešenia Riziká Spresnenie identifikovaných rizík: R-2.1, R-2.2 R-2.1 Riešenie bude náročné na prevádzku (kapacitne a vedomostne) R-2.2 Procesy devops a governance sa nepodarí pretaviť do praxe Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Tabuľka 3 Výstupy projektu a kritéria kvality

36 Architektúra informačných systémov Tabuľka 16 Architektúra informačných systémov budúci stav Súhrnný popis 5. Rozvoj interných služieb Interné služby predstavujú kvalitatívny rozvoj a postupné dopĺňanie služieb, ako je uvedené aj v časti 8.3 strategickej priority Vládny cloud. Služby IaaS sú známe a predpokladá sa pomerne rýchly rast ich používania. Na IaaS službách sú postavené a prevádzkované informačné systémy štátu, zároveň existuje know-how na ich prevádzku a podporu. Rozvojom interných služieb sa zabezpečí doplnenie katalógu pre odberateľov služieb a internej funkcionality o oblasti, ktoré vyplynuli zo skúseností zo súčasnej prevádzky Vládneho cloudu. Veľkou dopĺňanou oblasťou je poskytovanie SW, ktorý bude poskytovaný prostredníctvom 3 základných spôsobov (pozri aj obrázok nižšie):

37 ako SW nasadený a prevádzkovaný na virtuálnych strojoch IaaS za pomoci samoobslužného portálu, ako SW nasadený a prevádzkovaný na kontajneroch PaaS platformy, ako natívna služba PaaS platformy. Súčasťou rozvoja je aj 6. Služby z katalógu PaaS cloudových služieb Katalóg služieb predstavuje ponuku pre odberateľov služieb, pričom prakticky tieto služby je možné nakonfigurovať dvomi spôsobmi: Automaticky cez samoobslužný (self-care) portál automatizačnej platformy, ktorá má umožňovať odberateľovi nielen výber niektorej z ponúkaných služieb, ale musí zabezpečiť aj automatizáciu komplexnejších topológii a vzájomných závislostí jednotlivých platformových služieb. Takáto samoobslužná zóna je zvyčajne interaktívny portál, prostredníctvom ktorého môžu používatelia nasadiť, monitorovať a spravovať služby podľa svojich požiadaviek. Výberom cez samoobslužný portál, odkiaľ požiadavka prejde schvaľovacím a manuálnym nastavením príslušnej konfigurácie prostredníctvom zamestnancov správcu. Jedná sa najmä o zložitejšie konfigurácie, ako napríklad tie, ktoré zohľadňujú špecifické požiadavky na dodržiavanie pravidiel alebo výkonových požiadaviek. Pre odberateľa služieb by mal byť tento výber na prvý pohľad transparentný, jediný rozdiel by pre neho mal byť iba v rýchlosti zriadenia služby služby v prvej, "automatickej" skupine budú zriadené okamžite, služby aktivované manuálne budú zriadené v súlade s príslušnou SLA. Podstatným aspektom platformy poskytujúcej služby je práve zoznam poskytovaných služieb, ich parametrov a SLA. Predpokladom zaradenia služby je najmä vysoká frekvencia využívania. Detailné technické a SLA parametre Predpokladajú sa nasledovné služby, ktorých technické a SLA parametre budú detailizované v DFŠ projektu ktorý zabezpečí rozšírenie IaaS vrstvy. Sieťové služby: DNS, VPN gateway komponent umožňujúci zriadenie VPN prístupu za účelom prístupu, alebo prepojenia sietí, NTP časové služby (poskytovanie služieb NTP odberateľom, súčasné riešenie NTP je iba pre interné účely, prípadne si odberateľ musí NTP službu sám nainštalovať na VM), Služby backupu: backup riešenie - komplexný backup VM, kontajnerov ako aj podporovaných aplikačných dát. Služby MS Exchange poskytovanie MS Exchange služieb v multitent režime pre odberateľov služby (poskytovanie platformy Exchange ako služby) Bezpečnostné služby:

38 security: sieťové multitenantné HSM moduly, správa certifikátov (správa životného cyklu certifikátov), IAM vrátane správy kľúčov a certifikátov (správa admin prístupov, certifikátov potrebných na prístup rolí). Služby cloud natívnej platformy: multitenant služby cloud natívnej platformy, vrátane jej prevádzky a devops (t.j. odberateľ služby poskytne kód a dostane deploynutú aplikáciu), Služby poskytovania SW pay per use: poskytovanie špecifických softvérových licencií (aj open source), vrátane poradenstva SAM, Služby PaaS komponentov: poskytovanie špecifických komponentov, ktoré bude odberateľ služby využívať vo svojom riešení, pričom sa predpokladajú nasledovné komponenty (resp. spoločné bloky), ktoré budú využívané v iných ISVS: modul autentifikácia (OpenID/SAML2/oAuth2/X509/basic authentifik./... konektor a spoločná funkcionalita AA/IAM založená na LDAP komponente, ktorý bude poskytovať služby pre všetky zúčastnené komponenty), modul API proxy & gateway. Z pohľadu vertikálneho členenia poskytovaných služieb budú poskytované v nasledovných oblastiach: Prezentačné služby Služby integračnej funkcionality Služby aplikačnej vrstvy Služby manažmentu dát (DB SQL, nosql)

39 Služby pre podporu vývoja Infraštruktúrne služby v MetaIS sú definované nasledovne: Typ infraštruktúrnej služby Natívna PaaS platforma Poskytovanie SW pay per use Poskytovanie SW pay per use Poskytovanie SW pay per use Poskytovanie SW pay per use PaaS služby PaaS služby PaaS služby PaaS služby PaaS komponenty PaaS komponenty PaaS komponenty Meno infraštruktúrnej služby PaaS služby cloud natívnej platformy Služby databázovej vrstvy vo vládnom cloude Integračné služby vo vládnom cloude Prezentačné služby vo vládnom cloude Služby aplikačnej vrstvy vo vládnom cloude HSM moduly ako služba vládneho cloudu Backup ako služba vládneho cloudu Disaster recovery ako služba vládneho cloudu NTP služby vládneho cloudu API proxy&gateway modul v Paas cloude - spoločný blok Autentifikačný modul v PaaS cloude - spoločný blok Služby MS Exchange vo vládnom cloude Detailné technické parametre ako aj návrh SLA týchto služieb bude súčasťou DFŠ projektu. Definitívne SLA týchto služieb bude určené na základe skúseností s prevádzkou a schopností MVSR poskytovať služby. Je však možné očakávať štandardne obvyklé SLA konfigurácie ako v prípade obdobných služieb na trhu. 7. Natívna PaaS platforma Predstavou tejto štúdie je poskytovanie PaaS služieb v primeranom rozsahu s možnosťou postupného rozvoja. Podľa možností by väčšina služieb mala byť samokonfigurovateľná pomocou samoobslužného portálu, v niektorých prípadoch, najmä pri menej používaných službách sa predpokladá aj manuálna konfigurácia za pomoci interného administrátora. Platforma bude vybudovaná ako kombinácia pozostávajúca z platformy umožňujúcej vývoj, deployment a manažovanie aplikácií v cloude s využitím kontajnerových technológií ( Cloud Foundry / Openshift ) pri vývoji aplikácií. PaaS platforma je navrhnutá ako ucelená sady nástrojov umožňujúce vývoj, deployment a manažovanie cloudových aplikácií. Táto časť zároveň musí umožniť automatizovaný provisioning a správu celého stacku (s využitím OpenStack) vrátane poskytovaných nástrojov, middlewaru, všetkých prostredí, licenčného komerčného a opensource sw pre komplexné agendové projekty štátnej správy SR. Zároveň bude PaaS pozostávať za účelom podpory vývoja a prevádzky natívnych cloudových aplikácií a mikroslužieb jednou z dvojice produktov Cloud Foundry a Redhat Openshift, ktoré obe majú referencie nasadenia v government prostredí (viď časť Alternatívne riešenia), pričom miera customizácie by mala byť podľa možností čo najmenšia, aby bola zabezpečená kompatibilita a jednoduchá možnosť aktualizácie. Vzhľadom na obmedzené skúsenosti táto štúdia predpokladá síce kompletnú inštaláciu PaaS platformy, avšak v katalógu služieb pre odberateľov budú tieto služby vypublikované s nižšou úrovňou SLA ako v prípade služieb typu IaaS, prípadne môžu byť nejaký čas označené ako public beta". Na začiatku sa predpokladá prevádzka v pomere 80% IaaS služieb k 20% PaaS služieb. Odstránenie beta prívlastku sa predpokladá postupne v priebehu 1-2 rokov od spustenia projektu, tak ako budú získavané skúsenosti s prevádzkou jednotlivých PaaS služieb. V budúcnosti sa postupne očakáva preklopenie utilizácie služieb v prospech PaaS služieb. Jedná sa o rozvoj a doplnenie nasledovných oblastí: rozšírenie katalógu služieb o vybrané PaaS služby štandardne poskytované (výrobcom podporovaný buildpack) PaaS vrstvou (pre každú vrstvu vertikálneho členenia), monitoring využívania a záťaže jednotlivých komponentov PaaS natívnej platformy, unifikovaný reportingový nástroj, meranie využívania licencií v PaaS natívnej platforme,

40 zavedenie governance a devops procesov. služba buildovania, nasadenia a spustenia aplikácie prostredníctvom cloud natívnej aplikácie, kontajnerová služba (prevádzka kontajnerov), repozitár kontajnerov (vrátane kontajnerov s predpripraveným komerčným a open source softvérom), pričom vybrané komponenty môžu byť poskytované aj ako služba, jedná sa predovšetkým o štandardné služby ako SQL, http server, load balancer, workflow atď.), t.j. budú to kontajnery, ktoré budú prevádzkované pre zákazníka, ktorý bude mať prístupné iba aplikačné funkcie, pre jednotlivé procesy budú definované a udržiavané metodické príručky a záväzné postupy/metodiky pre používateľov služieb (s vyššou mierou granulatity pre používanie natívneho PaaS na zabezpečenie striktnejších predpokladov správneho fungovania automatizačných mechanizmov platformy a prevádzkovej bezpečnosti a stability). 8. Platforma pre automatizáciu poskytovania komerčných licencií V oblasti poskytovania licencií pre model Pay per use je potrebné zabezpečiť: self care portál, pomocou ktorého bude možné vytvoriť objednávku a sledovať stav "svojich" služieb, zabezpečiť podľa možností automatizovaným spôsobom provisioning, billing a životný cyklus služieb, zabezpečiť prevádzku softvéru, vrátane aktualizácii tak, aby pre používateľa bola služba podľa možností transaprentná. V prípade open source licencií sa predpokladá, že väčšina SW bude zabezpečená prostredníctvom cloud natívnej PaaS platformy. Pre ostatné prípady bude vybudované riešenie, ktoré zabezpečí vyššie uvedené funkcie. 9. Backup služby a Exchange služby Súčasťou projektu je aj poskytovanie služieb typu Backup a Exchange a ich podľa možností aj ich (aspoň čiastočná) integrácia do samobslužného portálu. Backup služby budú poskytované na základe customizovaného krabicového riešenia, pričom odberateľom umožnia nasledovné: zálohovať obrazy strojov, resp. kontajnerov ako aj biznis údaje, vrátane snapshotov a replikácie, poskytovanie služby typu disaster recovery pomocou replikácie údajov do cloudu, resp. inej lokality. Príkladom implementácie sú produkty firmy Veeam. Exchange služby predstavujú komplexné transparentné poskytovanie služieb Exchange, kde sú pre odberateľa služby zriadené ové schránky v multitenant režime. K dispozícii bude štandardná funkcionalita MS Exchange, pričom administráciu bude zabezpečovať prevádzkovateľ cloudu. 10. Devops Dostupnosť nových automatizovaných nástrojov na správu a podporu nasadzovania aplikácii dala za vznik novej kategórii správcov, nazývaných aj Devops - anglického developer operations". Ide o vysoko automatizované poskytovanie služieb prevádzky ako aj nasadzovania a tunningu aplikácii za pomoci špecializovaných nástrojov a postupov s cieľom zásadne zrýchliť a štandardizovať prevádzku, to všetko popri zvýšení efektívnosti a tým pádom znížení celkovej ceny. Tieto aktivity vykonávajú, nastavujú a dohliadajú na ne dedikovaní operátori, ktorí majú znalosti nielen z prevádzkovania, ale najmä z automatizácie procesov buildovania, tvorby prostredí, nasadzovania ako aj samotnej prevádzky aplikácii v prostrediach PaaS a IaaS. DevOps je kľúčovým komponentom realizovateľnosti platformy PaaS vládneho cloud a z hľadiska bezpečnosti a prevádzky je jednoznačne kritickým prvkom. Zároveň platí, že devops procesy definované v tejto štúdii sú jednotné a slúžia na prevádzku celého riešenia vládneho cloudu, t.j. IaaS aj PaaS častí. Devops v ponímaní tejto štúdie predstavuje: všetky postupy, metodiky a nástroje používané devops tímom MVSR, ktoré budú dodané v rámci projektu, samotní ľudia členovia devops tímu MVSR zaradení do jednotlivých rolí,

41 financovanie tohto tímu počas trvania projektu ako aj po jeho skončení. Predmetom budúceho projektu zo strany potenciálneho dodávateľa je spoločne s MVSR interaktívne navrhnúť procesy devops, pričom sa predpokladá, že dodávateľ prinesie know-how v tejto oblasti a zohľadní požiadavky a špecifiká vyplývajúce z prevádzky government cloudu. Výsledkom sú jednotné postupy, metodiky a nástroje popísané nižšie Jednotné postupy, metodiky a nástroje Prevádzka a správa IaaS a PaaS riešení musí byť založená na jednotných a zdokumentovaných nástrojoch, postupoch a procesoch, keďže sa predpokladá, že prevádzkové tímy MVSR budú fungovať na základe procesov ITIL. Dodané technické metodiky a dokumentácia technických procesov musia zahŕňať popis používania funkcií a služieb, ktorých využitie sa predpokladá počas procesu správy celého cloudového riešenia a musí obsahovať minimálne nasledovné oblasti (pričom v zátvorke je pre lepšiu predstavu uvedený príklad nástroja za účelom lepšieho vysvetlenia oblasti, ktorú majú devops postupy, metodiky a nástroje zahŕňať, pričom je možnosť nie povinnosť použiť niektoré z vymenovaných nástrojov): správu OS (Linux, AIX, Windows), nástroje na automatizáciu a release management, správu cloudového riešenia PaaS (Cloud Foundry, Openshift), vrátane nástrojov na uľahčenie manažmentu riešenia, continous integration / development (Jenkins, Travis, Gitlab), aktualizácie poskytovaného SW, repozitár kódu (Git), samotná cloud natívna platforma, webové a aplikačné servery (IIS, Nginx, Tomcat, Apache), Cluster management (Kubernetes, Docker swarm, Mesos), Monitoring a Alerting (Nagios, Spectrum, Zabbix,),Poznámka: interné monitorovacie nástroje nemusia byť dodávané ako riešenie pre odberateľov služieb, je na zváženie, či ich nie je efektívnejšie nakupovať ako službu, resp. ako hotovú aplikáciu a poskytnúť rozhranie odberateľom služieb, tak aby si mohli nastaviť sledovanie podľa vlastných potrieb. Reverse proxy (Cisco, F5, Squid), API Management, Gateway a Identity Mediation (Apigee, CA API Gateway, WSO2, Tyk) Load balancer (HAproxy, Cisco, F5), Caching (Memchached, Redis), zálohovanie a disaster recovery (Veeam), testovanie (Testrail, Selenium, Cucumber, OWASP ZAP, Veracode), helpdesk a issue management, wiki (CA ServiceDesk, JIRA, Confluence), podpora prevádzky, bezpečnostné nástroje (Clair, Nessus, TrapX, Phishme), automatizačnú platformu, ktorá integruje a využíva niektoré vyššie spomenuté jednoúčelové nástroje a zároveň zabezpečí integráciu s cloud platformou (napr. Buildmaster, Urbancode, Automic, CA Release Management). V zátvorkách uvedené produkty predstavujú overené a používané produkty pre uvedené oblasti. Primárne sa predpokladá využitie nástrojov/produktov ktoré sú už používané pre danú oblasť v IaaS, ak nie sú vhodné pre potreby DevOps tak využitie uvedených produktov v zátvorkách je vhodné v budúcom riešení Roly Súčasťou devops procesov implementovaných na MVSR by mali byť nasledovné predpokladané roly/okruhy: admin a platformový developer/release manažér, zodpovedný najmä za automatizovanú prípravu prostredí (naozaj rovnaké prostredia si vyžadujú automatizované nasadzovanie), správu prostredia na buildovanie a automatizáciu nasadzovania (vrátane správy repozitáru artefaktov, systému verzionovania pipeline atď.), tester, zodpovedný najmä za funkčné a výkonnostné testovanie, ako aj prípravu scenárov na test prostredí, ale aj zabezpečenia nového prostredia na každý test, bezpečnostný špecialista, zodpovedný za dohľad nad celkovým riešením z bezpečnostného hľadiska, nastavovanie operačných bezpečnostných pravidiel, spoluprácu s ostatnými rolami pri bezpečnostnom dohľade a spolupráci pri bezpečnostnom testovaní, sieťový špecialista, zodpovedný za sieťové nastavenia a ich optimalizáciu, vrátane nastavovania clusteringu, softvérových sietí a monitorovania sieťovej prevádzky, monitorovací špecialista, zodpovední najmä za automatizované monitorovanie používateľov, logov, konfiguračných zmien, bezpečnosti, výkonu, ako aj za nastavenie systému na automatickú detekciu vybraných problémov, licenčný špecialista, zodpovedný za zmluvy s vendormi, nastavenie platformy a pravidiel poskytovania SW, optimalizáciu licenčného modelu pre odberateľov služieb, ako aj priebežnú optimalizáciu celkového portfólia SW,

42 support špecialista, zodpovedný za poskytovanie podpory odberateľom služieb. Tieto roly budú pokryté internými zamestnancami MVSR, pričom predmetom projektu je detailný návrh činnosti (job description) každej roly a jej zahrnutie do navrhovaných procesov. Úlohou devops tímu bude najmä: efektívna prevádzka vládneho cloudu, vrátane cloud natívnej platformy moderným spôsobom v zmysle devops za pomoci nástrojov uvedených v časti "Jednotné postupy, metodiky a nástroje", starostlivosť o aplikácie odberateľov služieb z infraštruktúrneho a platformového hľadiska (t.j. aktualizácie krabicového SW, nasadzovanie dodaných nových verzií, bežné prevádzkové záležitosti, príprava prostredí atď), podpora pracovníkov jednotlivých OVM pri nasadzovaní a prevádzke aplikácii vo vládnom cloude, testovanie aplikácii, ktoré OVM chce nasadiť do cloudu, najmä z pohľadu bezpečnosti a výkonu, nastavovanie sietí, najmä z pohľadu výkonu a bezpečnosti pre interné fungovanie ako aj pre jednotlivé aplikácie OVM, podpora a výkon nasadzovania legacy aplikácii na cloud natívnu platformu Pravidlá a požiadavky pre vývoj aplikácii navrhovanie aplikácii pre cloud Aby aplikácie mohli správne fungovať na natívnom PaaS riešení a zároveň boli využité, možnosti automatizácie a zefektívnenia na PaaS riešení, musia dodržiavať isté podmienky a pravidlá, ktoré budú povinným predpokladom nasadenia aplikácie do cloudu. Súčasťou riešenia a jeho finálnym výstupom musí byť komplex dokumentov, ktorý vznikne po konzultáciách s prevádzkovým tímom, bude zohľadňovať všetky existujúce best practice, detailne popisovať všetky požiadavky a podmienky pre vývoj aplikácií, ktoré budú prevádzkované vo vládnom cloude. Množina nutných, ale nie postačujúcich podmienok je: self contained (t.j. všetky updaty databázy, filesystému, vlastného kódu a iných súčastí musia byť v jednom balení), konfigurácia je uložená parametricky a nie je súčasťou aplikácie (aby bolo možné automaticky nasadzovať aplikáciu na rôzne prostredia), využívanie kontajnerov, nie priamo VM (ak to licenčný SW umožňuje), využívanie iba cloudom podporovaných služieb a frameworkov, automatizované unit testy, bezpečnostné testy a prípadne akceptačné testy sú súčasťou každého release aplikácie, aplikácie musia byť navrhnuté tak, aby vedeli využiť škálovanie do šírky (pridávanie serverov) a nespoliehali sa na škálovanie výkonu (výkonnejší server, disky atď), aplikácie sú rozdelené na menšie celky nezávislé subsystémy využívajúce kontajnery, prípadne serverless" architektúru, povinné využívanie vybraných služieb cloudu (napr. autentifikácia). V zásade je ale možné konštatovať, že požiadavky na aplikácie sú analogické ako pri používaní CI/CD procesov a nasadzovaní aplikácii do PaaS komerčných cloudov. Ak budú aplikácie vyvíjané s ohľadom na používanie v cloude a splnení požiadaviek špecifických pre štátny cloud (t.j. najmä čo sa týka podporovaných frameworkov/technológií), tak aplikácia bude fungovať správne. Požiadavky na fungovanie a vývoj cloud-ready aplikácii je možné nájsť vo väčšom detaile na čo predstavuje zdroj, na ktorom je založený aj tento zoznam. Je potrebné sa riadiť aj odporúčaniami z dokumentu Referenčná architektúra Informačného systému verejnej správy v cloude, najmä v časti "Pravidlá a požiadavky pre vývoj aplikácii navrhovanie aplikácii pre cloud". Cloud natívna platforma musí umožnovať aj beh aplikácii, ktoré priamo nespĺňajú požiaddavky 12 faktorov a cloud native prístupy, ale bude možné po menších úpravách preniesť aj pôvodné aplikácie, resp. nové, ktoré neboli vyvíjané natívne pre PaaS Dokumentácia procesov Správa katalógu služieb Katalóg služieb je dynamickým zoznamom, ktorý by mal reagovať na dostupné technologické možnosti ako aj potreby odberateľov služieb. Správcom katalógu bude MVSR, ktoré ho bude aktualizovať v pravidelných intervaloch podľa technologických možností ako aj spätnej väzby od odberateľov služieb Riadenie zdrojov

43 Riadenie zdrojov je kontinuálny, podľa možností v maximálnej miere automatizovaný proces (tu v zmysle interného riadenia, riadenie a prideľovanie zdrojov odberateľom služieb je riešené v časti Alokácie). Je jedným z kľúčových technologických procesov, ktoré zaisťujú efektivitu využívania technologických zdrojov. Riešenie musí podporovať automatické riadenie a prideľovanie zdrojov podporovaným aplikáciám, ako aj možnosť manuálneho nastavenia obmedzení a možností (napr. na základe SLA) Nasadzovanie (o nboarding) nových aplikácii nae PaaS platformu Pre nové aplikácie je proces onboardingu dobre definovaný. Aplikácia (alebo kód) môžu byť zväčša nahrané priamo na platformu pomocou natívnych nástrojov, alebo ako kontajner. V oboch prípadoch vstup prichádza priamo od developera odberateľa služby, alebo z automatizovaného systému na nasadzovanie (continuous integration/development nástroje) Onboarding existujúcich aplikácii Pre už existujúce aplikácie je situácia nie tak jednoznačná a je viacero nie priamočiarych možností, ako tieto aplikácie prevádzkovať: niektoré existujúce aplikácie môžu byť prevádzkované natívne bez zmeny, to je zväčša prípad iba aplikácii, ktoré sú už zabalené v kontajneroch, aplikácie, ktoré môžu byť prevádzkované s malými modifikáciami, pričom modifikácie sú závislé od použitého frameworku, ktorý môže využívať služby PaaS platformy, aplikácie, ktoré môžu byť prevádzkované na IaaS platforme (t.j. ako sú), ale budú dostupné pre ostatné komponenty už bežiace na PaaS platforme cez API, nejakú bránu alebo brokera (typickým príkladom sú veľké monolitické aplikácie). Budované riešenie musí umožniť všetky spomenuté možnosti. Obrázok č. 6 Architektúra informačných systémov Školenia Nevyhnutným predpokladom budúceho riešenia sú školenia a školiace materiály ku všetkým dodaným technológiám, ktoré musia byť súčasťou projektu a následnej prevádzky systému. Kritériá kvality Spresnenie kritérií kvality: Q -3.1, Q-3.2, Q-3.3 Q-3.1 Plnenie cieľov NKIVS a schválených strategických dokumentov Q-3.2Miera flexibility riešenia Q-3.3Integrácia modulov procesná a dátová integrácia pre všetky moduly, eliminácia potreby dávkovej výmeny údajov

44 Riziká Spresnenie identifikovaných rizík: R-3.1, R-3.2 R-3.1Riešenie nebude dostatočne flexibilné R-3.2 Integrácia na iné systémy ISVS R-3.3 Proces vývoja nebude dostatočne agilne reagovať na požiadavky zákazníka Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Tabuľka 3 Výstupy projektu a kritéria kvality Technologická architektúra Tabuľka 17 Technologická architektúra budúci stav Súhrnný popis

45 Technologická architektúra je založená na využívaní IaaS služieb vládneho cloudu, ktorý pozostáva z dvoch lokalít - datacentrum MFSR a datacentrum MV SR. Nad službami IaaS, resp. virtualizačnou vrstvou budú vybudované PaaS služby. Riešenie je z technologického hľadiska možné logicky rozdeliť na 3 časti: rozšírenie cloudových služieb o spoločné komponenty doplnenie provisioningu SW licencií nad VM, vybudovanie PaaS platformy Ako bolo uvedené v popise súčasného stavu, vládny cloud je založený na platforme OpenStack, ktoré je manažované custom samoobslužným portálom. Riešenie PaaS platformy musí byť v súlade s existujúcim techologickou architektúrou a musí zabezpečiť nevyhnutnú konzistenciu riadenia zdrojov vládneho cloudu. a umožniť efektívnu a spoľahlivú prevádzku vládneho cloudu. Za týmto účelom musí riešenie PaaS platformy realizovať integráciu s existujúcim riešením IaaS prostredníctvom OpenStack ako aj integráciu na existujúci samoobslužný portál. Na začiatku sa z dôvodu počiatočnej neznalosti a nepripravenosti (na strane odberateľov služieb, ale aj prevádzkovateľa) predpokladá malé vyťaženie PaaS platformy, avšak s postupným nábehom skúseností na strane prevádzkovateľa (najmä devops tím) ako aj odberateľov služieb sa očakáva rýchle zvyšovanie využitia PaaS služieb. Vzhľadom na vyťaženosť súčasného cloudu a viacerými požiadavkami odberateľov na doplnenie poskytovaných služieb IaaS o ďalšie služby, predovšetkým pre VM ( XXXLarge a služby HSM ), je súčasťou projektu aj čiastočné rozšírenie HW prostriedkov. V súlade s možnosťami načrtnutými v SP Vládny cloud, riešenie PaaS platformy by malo v prípade potreby umožniť aj prevádzku v hybridnom cloude. Predpokladané prevádzkové parametre sú závislé a odvíjajú sa najmä od parametrov existujúceho IaaS riešenia. Predpokladajú sa však nasledovné: prevádzka 24x7, dostupnosť 99.9 %. Služby PaaS platformy (Cloud Foundry / OpenShift) budú v prvej nábehovej fáze poskytovené a garantované s SLA s nižšími parametrami, vzhľadom na menšiu vyspelosť technológie a nedostatok prevádzkových skúseností (public beta), pričom v budúcnosti sa predpokladá konvergencia na parameter s SLA na IaaS. Z tohto dôvodu sa v prvej fáze z hľadiska kategorizácie predpokladá, že na kontajnerových technológiách budú implementované nekritické mikroslužby a aplikácie (z hľadiska bezpečnosti, kritickosti a dostupnosti pre procesy OVM). Obrázok č. 7 Technologická architektúra Kritériá kvality Spresnenie kritérií kvality: Riziká Spresnenie identifikovaných rizík:

46 Prílohy Diagramy, modely, obrázky v plnom rozlíšení Implementácia Tabuľka 18 Implementácia Súhrnný popis Implementácia je predpokladaná v piatich prelínajúcich sa fázach: Fáza I. Analýza a dizajn: konzultačno-analytické práce spojené s identifikáciou potrebných zdrojov, detailný návrh komponentov a nástrojov, ktoré budú použité v riešení, detailná analýza a funkčná špecifikácia, návrh procesov a školení, implementácia a ukážka prototypu riešenia (spolu s DFŠ). Fáza II. - Nákup krabicového HW a SW Nákup licencií a potrebného HW Fáza III. Implementácia: agilná implementácia a nasadenie v súlade s bežným SDLC (pre neštandardné komponenty), Proof of Concept, ktorý bude čo najrýchlejšie obsahovať PaaS natívnu platformu, v prípade úspechu bude pokračovať pilotnou prevádzkou, obvyklé testovania vrátane UX testovania komponentov pre odberateľov služieb aj interných používateľov. zvýšená podpora počas beta" prevádzky, priebežné školenia a knowledge transfer. Fáza IV. Testovanie: testovanie je integrálnou súčasťou každej fázy a každého modulu riešenia, v prípade vývoja ide testovanie ruka v ruke s agilným vývojom, v prípade krabicových riešení sa jedná predovšetkým o testovanie potenciálnych integrácii a fungovanie riešenia v prostredí MVSR a egovernmentu. Fáza V. Nasadenie: Po dokončení a vyladení systému prechod na plnú prevádzku systému už plne v gescií MVSR, dokončenie školení a knowledge transfer Je potrebné klásť dôraz na: podľa možností agilný prístup k vývoju s častým dodávaním prototypov a testovaním (a tvorba DFŠ súbežne s vývojom prototypu/obrazoviek), zabezpečenie dostatočného projektového tímu na strane zákazníka minimálne na úrovni garantov, ktorí sa vedia projektu venovať na dennej báze, dodržiavanie princípov projektového riadenia PRINCE2 (definované produkty s akceptačnými kritériami, zmenový rozpočet, tolerancie jednotlivých míľnikov, etáp a aj samotných produktov), knowledge transfer - transfer vedomostí od dodávateľa členom devops tímu. Harmonogram implementácie Míľnik Schválenie štúdie Harmonogram ukončenia od času t t Vytvorenie súťažných podkladov t+3 Schválenie NFP t+8

47 Verejné obstarávanie t+18 DFŠ a prvé prototypy t+24 Definícia procesov devops a pay-per-use t+27 Nákup krabicového SW a HW t+27 Implementácia PaaS natívneho riešenia t+28 Integrácia všetkých komponentov a procesov t+31 Testovanie t+34 Beta prevádzka zvýšená podpora t+34 Plná prevádzka koniec projektu t+37 Kritériá kvality Spresnenie kritérií kvality: Q-5.1 Dodržiavanie plánu projektu Q-5.2 Funkčné projektové registre a manažment zmien Q-5.3 Definované produkty s konkrétnymi a merateľnými kritériami Riziká Spresnenie identifikovaných rizík: R-5.1 Spolupráca zúčastnených strán nebude dostatočná R-5.2 Chyby zistené pri testovaní sa nepodarí odstrániť do času uvedenia do prevádzky Prílohy Diagramy, modely, obrázky v plnom rozlíšení Tabuľka 2 Riziká Tabuľka 3 Výstupy projektu a kritéria kvality Bezpečnostná architektúra Tabuľka 19 Bezpečnostná architektúra budúci stav