projekt_2924_Pristup_k_projektu_detailny
PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03 podľa vyhlášky MIRRI č. 401/2023 Z. z.
Povinná osoba | Mesto Skalica |
Názov projektu | Zvýšenie úrovne informačnej a kybernetickej bezpečnosti mesta Skalica |
Zodpovedná osoba za projekt | Tibor Ružička |
Realizátor projektu | Mesto Skalica |
Vlastník projektu | Mesto Skalica |
Schvaľovanie dokumentu
Položka | Meno a priezvisko | Organizácia | Pracovná pozícia | Dátum | Podpis (alebo elektronický súhlas) |
Schválil | Mgr. Oľga Luptáková | Mesto Skalica | Primátorka | 08.07.2024 |
|
1. História dokumentu
Verzia | Dátum | Zmeny | Meno |
1.1 | 08.07.2024 | Finálna verzia projektovej dokumentácie | Tibor Ružička |
2. Účel dokumentu
V súlade s Vyhláškou 401/2023 Z. z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia. Dokument Prístup k projektu obsahuje opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy.
2.1 Použité skratky a pojmy
SKRATKA/POJEM | POPIS |
API | Application Programming Interface |
CPU | Centrálna procesorová jednotka |
GB | Gigabajt |
HDD | Hard drive |
HTTPS | Hypertext transfer protocol secure |
HW | Hardware |
IKT | Informačno komunikačné technológie |
IPS | Intrusion prevention systems |
ISVS | Informačný systém verejnej správy |
KaIB | Kybernetická a informačná bezpečnosť |
LAN | Miestna sieť |
MIRRI | Ministerstvo investícií, regionálneho rozvoja a informatizácie Slovenskej republiky |
MS | Microsoft |
NFP | Nenávratný finančný príspevok |
OS | Operačný systém |
PIP | Projektová iniciačná prevádzka |
RAM | Operačná pamäť |
REST | Representational State Transfer |
RV | Riadiaci výbor |
SMB | Server Message Block |
SNMP | Simple Network Management Protocol |
SPAN | Switched port analyzer |
SQL | Structured query language |
SSD | Solid state drive |
SSH | Secure shell |
SW | Software |
VM | Virtual machine |
VPN | Virtuálna privátna sieť |
WP | Work Packages |
2.2 Konvencie pre typy požiadaviek (príklady)
Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu: FRxx
- U – užívateľská požiadavka
- R – označenie požiadavky
- xx – číslo požiadavky
Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu: NRxx
- N – nefukčná požiadavka (NFR)
- R – označenie požiadavky
- xx – číslo požiadavky
Ostatné typy požiadaviek môžu byť ďalej definované PM.
3. Popis navrhovaného riešenia
Popis navrhovaného riešenia je uvedený v Projektovom zámere, kap. Motivácia a rozsah projektu – Realizované činnosti v rámci projektu.
4. Architektúra riešenia projektu
4.1 Biznis vrstva
Predmetom projektu je riadenie informačnej a kybernetickej bezpečnosti a realizácia opatrení KaIB definovaných najmä v zákonoch č. 69/2018 Z. z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov (ďalej len „Zákon o KB") a č. 95/2019 Z. z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov (ďalej len „Zákon o ITVS“) pre hlavný cieľ, čím je zvýšenie úrovne informačnej a kybernetickej bezpečnosti v Meste Skalica.
Predmetom projektu sú primárne tie oblasti, v ktorých žiadateľ identifikoval najnižšiu technickú vybavenosť, najvyššiu mieru rizika, a najvyššie dopady, prípadne kde má najvyššiu mieru nesúladu s výsledkom auditu kybernetickej bezpečnosti. Pri výbere a nastavení oprávnených podaktivít žiadateľ vychádzal najmä z požiadaviek určených Zákonom o KB, Zákonom o ITVS v znení zákona č. 301/2023 Z. z. a príslušných vykonávacích právnych predpisov.
Jednotlivé biznis funkcie bezpečnostnej architektúry sú znázornené na nasledovnom obrázku.
Obrázok č. 1: Biznis funkcie Informačnej a kybernetickej bezpečnosti
4.1.1 Prehľad koncových služieb – budúci stav:
Predmetom projektu nie je budovanie koncových služieb.
4.1.2 Jazyková podpora a lokalizácia
Neaplikuje sa.
4.2 Aplikačná vrstva
V kap. 4.1 (obrázok č. 1) sú definované biznis funkcie KaIB s príslušnými činnosťami. Tieto činnosti realizuje Mesto Skalica na základe konzultácií a výsledkov auditu kybernetickej bezpečnosti. Tieto činnosti predstavujú tvorbu bezpečnostnej dokumentácie, aktivity manažéra kybernetickej bezpečnosti a implementáciu softvérových a hardvérových nástrojov na zvýšenie súladu s odporúčanými opatreniami. Aplikačnú architektúru projektu tvoria riešenia pre oblasť informačnej a kybernetickej bezpečnosti, ktoré znázorňuje obrázok č. 2. Bližší popis jednotlivých aplikačných vrstiev uvádzame v podkapitolách nižšie.
Obrázok č. 2: Aplikačná vrstva projektu
A) Spracovanie povinnej dokumentácie a návrh procesov minimálne na úrovni požiadaviek zákona č. 69/2018 Z.z. o kybernetickej bezpečnosti a zákona č. 95/2019 Z. z. o informačných technológiách
Kompletná a aktuálna bezpečnostná dokumentácia je nevyhnutným základom pre efektívne riadenie informačnej a kybernetickej bezpečnosti každej organizácie. Tvorí základnú štruktúru pre ďalší rozvoj v tejto oblasti a implementáciu dodatočných bezpečnostných opatrení a technických bezpečnostných riešení. Práve bezpečnostná dokumentácia je nevyhnutným predpokladom pre prijímanie adekvátnych, efektívnych, vyvážených a optimálnych bezpečnostných opatrení.
Navrhované riešenie
Realizácia projektu umožní spracovanie kompletnej povinnej bezpečnostnej dokumentácie v rozsahu vyhovujúcemu platnej legislatíve a teda bude zahŕňať:
- Organizáciu kybernetickej bezpečnosti a informačnej bezpečnosti
- Riadenie rizík kybernetickej bezpečnosti a informačnej bezpečnosti
- Personálnu bezpečnosť
- Riadenie prístupov
- Riadenie kybernetickej bezpečnosti a informačnej bezpečnosti vo vzťahoch s tretími stranami
- Bezpečnosť pri prevádzke informačných systémov a sietí
- Hodnotenie zraniteľností a bezpečnostných aktualizácií
- Ochranu proti škodlivému kódu
- Sieťovú a komunikačnú bezpečnosť
- Akvizíciu, vývoja a údržby informačných sietí a informačných systémov
- Zaznamenávanie udalostí a monitorovania
- Fyzickú bezpečnosť a bezpečnosť prostredia
- Riešenie kybernetických bezpečnostných incidentov
- Kryptografické opatrenia,
- Kontinuitu prevádzky
- Audit, riadenia súladu a kontrolných činností
Podrobnejší popis sa nachádza v Projektovom zámere, kapitola Motivácia a rozsah projektu.
B) Implementácia mechanizmov pre potreby zabezpečenia infraštruktúry žiadateľa umiestnenej v cloude
Pre zabezpečenie jednej z hlavných častí kybernetickej bezpečnosti v IT prostredí je nevyhnutné zabezpečiť dôslednú kontrolu komunikácie na perimetri organizácie, aby okrem ochrany firewallom boli zabezpečené aj špecifické dátové toky ako maily, WEB komunikácia, spracovanie podozrivých kódov v izolovanom prostredí.
Navrhované riešenie
Navrhované riešenie bude obsahovať súbor bezpečnostných procesov a nasadených technických riešení, ktorých úlohou bude zabezpečenie infraštruktúry žiadateľa umiestnenej v cloude. Konkrétne sa bude jednať o nasledovné riešenie:
Forti Sandbox – HW appliance
Forti Sandbox je vysokovýkonné bezpečnostné riešenie, ktoré využíva technológiu AI/strojového učenia a pomáha identifikovať a izolovať pokročilé hrozby v reálnom čase. FortiSandbox kontroluje súbory, webové stránky, adresy URL a sieťový prenos pre škodlivú aktivitu, vrátane zero-day hrozieb pričom využíva technológiu sandboxingu na analýzu podozrivých súborov v zabezpečenom virtuálnom prostredí.
Forti Mail / relay – virtual appliance
Platforma FortiMail je súčasťou integrovaného softvérového riešenia, ktoré poskytuje výkonný a flexibilný antispam, antivírus, archiváciu e-mailov, protokolovanie a reportovanie prichádzajúcej a odchádzajúcej e-mailovej prevádzky.
Forti Web / WAF – virtual appliance
FortiWeb je webový aplikačný firewall (WAF), ktorý chráni webové aplikácie a rozhrania API z útokov, ktoré sa zameriavajú na známe a neznáme zraniteľnosti a pomáha udržiavať súlad s kyber predpismi. Použitie strojového učenia FortiWeb chráni aplikácie pred známymi zraniteľnosťami a pred hrozbami zero-day. Vysoký výkon, virtuálne zariadenia a kontajnery nasadzované na mieste alebo v cloude, môže slúžiť akejkoľvek veľkosti organizácie – od malých podnikov až po poskytovateľov služieb, dopravcov a veľké podniky.
Forti Analyzer – virtual appliance
FortiAnalyzer je výkonné zariadenie na správu log protokolov, analytiku a je reporting platformou, ktorá poskytuje organizáciám centrálnu konzolu na správu, automatizáciu, management, čo umožňuje zjednodušenie zabezpečenia správy, proaktívnu identifikáciu, nápravu rizík a úplnú viditeľnosť celej oblasti útoku. FortiAnalyzer je integrovaný s Fortinet Security Fabric. Sieťové a bezpečnostné tímy s detekciou v reálnom čase, sú predurčené na zabezpečenie centralizovanej analýzy a komplexnej bezpečnosti.
Podrobnejší popis sa nachádza v Projektovom zámere, kapitola Motivácia a rozsah projektu.
- C) Riešenie centrálneho bezpečnostného manažmentu pre koncové stanice - centrálna správa a manažment koncových zariadení – XDR
Navrhované je riešenie, ktoré umožní diaľkové nasadenie klientov na koncové zariadenia - 80 ks, zobrazovanie údajov o prevádzke na koncovej stanici v reálnom čase, centrálny provisioning klientov.
Riešenie umožní poskytovať informácie na koncovej stanici (verzia, OS, IP/MAC adresa, profil užívateľa), stav klientskej stanice, ako aj možnosť reportovať telemetriu na úrovni centrálnej správy. Riešenie bude kompatibilné s MS WIN, MacOS, iOS, Linux
Riešenie umožní jednoduché používateľské rozhranie centralizovaného manažmentu.
Podrobnejší popis sa nachádza v Projektovom zámere, kapitola Motivácia a rozsah projektu.
D) Nasadenie dvojfaktorovej autentifikácie
Implementácia dvojfaktorovej autentifikácie (2FA) je efektívna metóda na posilnenie bezpečnosti účtov, pretože pridáva ďalšiu úroveň ochrany.
Čo je to dvojfaktorová autentifikácia (2FA)
Tento spôsob zabezpečenia vyžaduje predloženie dvoch rôznych typov dôkazov na prístup k účtu, čím sa zvyšuje ochrana. Prvky požadované v 2FA sú:
Faktor znalostí: Informácie, ktoré pozná iba používateľ, ako napríklad heslo alebo PIN.
Faktor vlastníctva: Niečo, čo používateľ vlastní, napríklad inteligentná karta, bezpečnostný token alebo mobilné zariadenie.
Logika tejto metódy je taká, že aj keď sa niekomu podarí odhaliť heslo používateľa (faktor znalostí), na prístup k účtu bude stále potrebný druhý faktor (faktor vlastníctva). To výrazne znižuje riziko neoprávneného prístupu, čo značne sťažuje hackovanie.
Dvojfaktorová autentifikácia je široko používaná. Bežné riešenia zahŕňajú prijímanie jednorazového kódu prostredníctvom SMS, generovanie kódov prostredníctvom mobilnej aplikácie, ako je Google Authenticator alebo Authy, alebo používanie biometrických údajov, ako sú odtlačky prstov alebo rozpoznávanie tváre.
Táto forma autentifikácie je kľúčová pre kybernetickú bezpečnosť, chráni citlivé údaje a často sa používa na zabezpečenie rôznych online účtov, ako sú e-maily, bankové služby, sociálne siete a kryptomenové peňaženky.
Navrhované riešenie
Predmetom navrhovaného technického riešenia je nasadenie 2FA overovania. Ako druhý faktor bude využívaný HW token pre jeho spoľahlivosť a jednoduché pridelenie používateľovi. Dvojfaktorová autentifikácia je v súčasnosti takmer nevyhnutnou formou zabezpečenia takmer všetkých účtov a služieb, ktoré sú dôležité. Dvojfaktorová autentifikácia umožní ochrániť od neautorizovaného prístupu útočníkov aj v prípade ak získajú prihlasovacie údaje, nakoľko sa nedostanú cez overenie v druhom kroku. S ohľadom na uvedené bude v rámci realizácie projektu riešený práve tento systém ochrany pre potreby zabezpečenia VPN pripojenia do LAN siete mesta.
Podrobnejší popis sa nachádza v Projektovom zámere, kapitola Motivácia a rozsah projektu.
E) Nasadenie nástroja na riadenie kybernetickej bezpečnosti v prostredí mesta Skalica
V súčasnej dobe je žiadúce, aby organizácie riadili svoje systémy kybernetickej bezpečnosti v čase. Pretože len aktuálne procesy a data, ktoré kopírujú aktuálne požiadavky sú schopné dodať cielenú kvalitu riešenia. Systém riadenia by mal poskytovať nasledovné funkcionlity:
- Podporuje agendu MKB (Manažéra kybernetickej bezpečnosti)
- Hodnotenie súladu kybernetickej bezpečnosti voči Slovenskej legislatíve
- Organizácia bezpečnosti
- Identifikácia a evidencia aktív ZS
- Mapa súvislostí aktív ZS
- Identifikácia hrozieb a zraniteľností
- Analýza rizík
- Hodnotenie rizík
- Plán zvládanie rizík
- Plán kontinuity
- Hodnotenie dodávateľov
Navrhované riešenie
Navrhované technické riešenie bude pozostávať z nasadenia informačného systému na riadenie, revízie a aktualizáciu rizikovej analýzy umožňujúcim riadiť riziká, aktíva, zraniteľnosti a hrozby. Systém bude schopný dokumentovať históriu a bude auditovateľný. Pôjde o systém klient – server nasadený u Prevádzkovateľa na jeho serveri bez závislosti na cloudových službách a aktualizáciách cez internet.
Zoznam funkčných vlastností systému:
- Správa aktív – vedenie zoznamu aktív subjektu, vrátane ich vlastníkov
- Správa zraniteľností – vedenie zoznamu rozpoznaných zraniteľností, vrátane ich vlastníkov
- Správa hrozieb – vedenie zoznamu rozpoznaných hrozieb
- Správa opatrení – vedenie zoznamu opatrení potrebných na potlačenie zraniteľností
- Správa vzťahov – evidencia rozpoznaných vzťahov medzi aktívami a zraniteľnosťami
- Správa rizík – identifikácia a ohodnotenie rizík na základe pravdepodobností hrozieb, uplatňovaných opatrení a dopadov na subjekt.
Užívateľské rozhranie a výstupy systému:
- Pre interakciu s používateľom bude k dispozícií webové rozhranie bez špeciálnych nárokov na webový prehliadač
- Výstupy budú realizované vo forme prehľadov a zostáv vo formáte PDF.
Používatelia a ich správa:
- Evidencia používateľov, oprávnených pristupovať k subjektom a identifikovať resp. manažovať ich riziká bude umožňovať širokú integráciu na existujúce systémy správy používateľov
- Oprávneným používateľom bude možné prideliť role s rôznym stupňom oprávnení.
Spôsob nasadenia a použitia systému:
- Systém bude dodaný vo forme neobmedzenej licencie pre jedného používateľa
- Súčasťou dodania bude aj inštalácia, implementácia a zaškolenie obsluhy
Po dodaní systému bude vytvorená pracovná pozícia manažéra pre riadenie rizík, ktorý bude prostredníctvom informačného systému vykonávať:
- Tvorbu analýz rizík podľa potreby a požiadaviek manažéra informačnej bezpečnosti
- Pravidelné hodnotenie a ošetrovanie rizík
- Tvorbu plánu eliminácie rizík
- Správu aktív a ich vlastníkov
- Dohľad nad riadením rizík
Podrobnejší popis sa nachádza v Projektovom zámere, kapitola Motivácia a rozsah projektu.
4.2.1 Rozsah informačných systémov – AS IS
Existujúce informačné systémy, ktoré sú využívané v prostredí Mesta Skalica budú v stave AS IS premigrované do virtuálneho prostredia TO BE bez zmeny funkcionality. Prehľad IS uvádza tabuľka č. 1 nižšie.
Systém | Popis |
ISS | Databázový systém pre Verejnú správu |
DISS | Prijatá a odoslaná elektronická pošta |
4.2.2 Rozsah informačných systémov – TO BE
Predmetom projektu nie je implementácia nových informačných systémov. Existujúce informačné systémy, ktoré sú využívané v prostredí Mesta Skalica budú v stave AS IS premigrované do virtuálneho prostredia TO BE bez zmeny funkcionality.
4.2.3 Využívanie nadrezortných a spoločných ISVS – AS IS
Predmetom projektu nie je využívanie nadrezortných a spoločných ISVS.
4.2.4 Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE
Predmetom projektu nie je realizácia integrácií.
4.2.5 Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE
Predmetom projektu nie je realizácia integrácií.
4.2.6 Aplikačné služby pre realizáciu koncových služieb – TO BE
Predmetom projektu nie je realizácia aplikačných služieb
4.2.7 Aplikačné služby na integráciu – TO BE
Predmetom projektu nie je realizácia integrácií.
4.2.8 Poskytovanie údajov z ISVS do IS CSRÚ – TO BE
Predmetom projektu nie je poskytovanie údajov do IS CSRÚ.
4.2.9 Konzumovanie údajov z IS CSRU – TO BE
Predmetom projektu nie je konzumovanie údajov z IS CSRÚ.
4.3 Dátová vrstva
4.3.1 Údaje v správe organizácie
Predmetom projektu nie je spracovanie, resp. práca s údajmi ako objektmi evidencie.
4.3.2 Dátový rozsah projektu - Prehľad objektov evidencie - TO BE
Predmetom projektu nie je spracovanie, resp. práca s údajmi ako objektmi evidencie.
4.3.3 Referenčné údaje
Projekt nepracuje s referenčnými údajmi
4.3.4 Kvalita a čistenie údajov
Predmetom projektu nie je riešenie kvality a čistenia údajov.
4.3.5 Otvorené údaje
Predmetom projektu nie je riešenie otvorených údajov.
4.3.6 Analytické údaje
Predmetom projektu nie je riešenie analytických údajov.
4.3.7 Moje údaje
Predmetom projektu nie je riešenie témy „Moje údaje“.
4.3.8 Prehľad jednotlivých kategórií údajov
Predmetom projektu nie sú „objekty evidencie“.
4.4 Technologická vrstva
4.4.1 Prehľad technologického stavu - AS IS
Infraštruktúrne prostredie Mesta Skalica je v súčasnosti tvorené nasledovnými vrstvami:
- LAN sieť
- Štrukturovaná kabeláž v rámci objektov v areáli Mestského úradu Skalica
- Metalické a optické prepoje v areáli MsÚ,
- Aktívne prvky LAN siete
- 6 manažovatelných switchov
- Perimeter a pripojenie do Internetu
- Pripojenie do internetu je realizované Rádiom od lokálnej spoločnosti EHS s.r.o. a Firewallom Fortigate v správe externej spoločnosti
- Sieť je duálne segmentovaná PC, tlačiarne spolu IP telefóny samostatne
- Servre
- 6 cloudových serverov s inštalovanými OS MS Windows server 2019, 2 cloudové linuxové servery
- informačný systém samosprávy,
- je implemetované MS Active directory
- existujúce zálohovanie pre servery aj pre dokumenty užívateľov
- Užívatelia
- Cca 80 užívateľov pripojených v pracovnej skupine do siete, využívajúcich zdroje serverov z riadenia identity
- Ochrana koncových staníc – Sentinel One
- Prístup na WiFi prostredníctvom Guest Siete bez možnosti pripojenie do lokálnej siete
4.4.2 Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE
Parameter | Jednotky | Predpokladaná hodnota | Poznámka |
Počet interných používateľov | Počet | 80 | PC/Notebooky |
Počet súčasne pracujúcich interných používateľov v špičkovom zaťažení | Počet | 80 | PC/Notebooky |
Počet externých používateľov (internet) | Počet | 0 |
|
Počet externých používateľov používajúcich systém v špičkovom zaťažení | Počet | 0 |
|
Počet transakcií (podaní, požiadaviek) za obdobie | Počet/obdobie | Neaplikuje sa |
|
Objem údajov na transakciu | Objem/transakcia | Neaplikuje sa |
|
Objem existujúcich kmeňových dát | Objem | Neaplikuje sa |
|
4.4.3 Návrh riešenia technologickej architektúry
Nová infraštruktúra by mala spĺňať nároky vyplývajúce so zákona o kybernetickej bezpečnosti a umožňovať prevádzkovať existujúce systémy. Návrhom je :
- Zavedenie systému logovania a monitoringu sieťovej infraštruktúry a prevádzky
- Zisťovanie a notifikácie prípadných útokov a prienikov do infraštruktúry
- Zabezpečenie jednotlivých úrovní perimetra (mail-relay, web aplikačný firewall, sandbox)
- Zvýšenie úrovne zabezpečenia prístupu do infraštruktúry a k informačným systémov z internetu
- Zavedenie systému riadenia kybernetickej bezpečnosti
Schematický nákres riešenia technologickej architektúry znázorňuje obrázok č. 3 nižšie.
Obrázok č. 3: Náhľad technologickej architektúry
4.5 Bezpečnostná architektúra
Predmetom projektu je implementácia opatrení pre oblasť informačnej a kybernetickej bezpečnosti, architektúra je uvedená v kap. 4 Architektúra projektu. Navrhovaný projekt a jeho architektúra bude budovaná v súlade s nasledujúcimi právnymi predpismi:
- Zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe
- Zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti
- Zákon č. 45/2011 Z. z. o kritickej infraštruktúre
- Vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 78/2020 z. z. o štandardoch pre informačné technológie verejnej správy
- Vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu č. 179/2020 z. z. ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
- Vyhláška Úradu na ochranu osobných údajov Slovenskej republiky č. 158/2018 Z. z. o postupe pri posudzovaní vplyvu na ochranu osobných údajov
- Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27.apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
- Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov
5. Závislosti na ostatné ISVS / projekty
Projekt nie je závislý na iných ISVS, resp. projektoch.
6. Zdrojové kódy
Vlastníkom zdrojových kódov v prípade vývoja SW diela bude Mesto Skalica v súlade s platnou legislatívou. Dôležité usmernenia pre oblasť zdrojových kódov sú:
- Centrálny repozitár zdrojových kódov - § 31 Vyhlášky 78/2020 Z. z.: https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2020/78/20240401
- Overenie zdrojového kódu s cieľom jeho prepoužitia a spôsoby zverejňovania zdrojového kódu: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/
- Inštrukcie k EUPL licenciám: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf
7. Prevádzka a údržba
7.1 Prevádzkové požiadavky
7.1.1 Úrovne podpory používateľov
Podpora používateľov bude realizovaná cez 2 úrovne podpory, s nasledujúcim označením:
- L1 podpory IS (Level 1, priamy kontakt zákazníka) bude zabezpečovať prevádzka Mesta Skalica
- L2 podpory IS (Level 2, postúpenie požiadaviek od L1) bude zabezpečovaná dodávateľom
Definícia:
- Podpora L1 (podpora 1. stupňa) - začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.
- Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť.
- Dostupnosť L2 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní)
7.1.2 Riešenie incidentov – SLA parametre
Označenie naliehavosti incidentu:
Označenie naliehavosti incidentu | Závažnosť incidentu | Popis naliehavosti incidentu |
A | Kritická | Kritické chyby, ktoré spôsobia úplné zlyhanie systému ako celku a nie je možné používať ani jednu jeho časť, nie je možné poskytnúť požadovaný výstup z IS |
B | Vysoká | Chyby a nedostatky, ktoré zapríčinia čiastočné zlyhanie systému a neumožňuje používať časť systému |
C | Stredná | Chyby a nedostatky, ktoré spôsobia čiastočné obmedzenia používania systému |
D | Nízka | Kozmetické a drobné chyby |
možný dopad:
Označenie závažnosti incidentu | Dopad | Popis dopadu |
1 | katastrofický | Katastrofický dopad, priamy finančný dopad alebo strata dát, |
2 | značný | Značný dopad alebo strata dát |
3 | malý | Malý dopad alebo strata dát |
Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:
Matica priority incidentov | Dopad | |||
Katastrofický - 1 | Značný - 2 | Malý - 3 | ||
Naliehavosť | Kritická - A | 1 | 2 | 3 |
Vysoká - B | 2 | 3 | 3 | |
Stredná - C | 2 | 3 | 4 | |
Nízka - D | 3 | 4 | 4 |
Vyžadované reakčné doby:
Označenie priority incidentu | Reakčná doba(1) od nahlásenia incidentu po začiatok riešenia incidentu | Doba konečného vyriešenia incidentu od nahlásenia incidentu (DKVI) (2) | Spoľahlivosť (3) (počet incidentov za mesiac) |
1 | 0,5 hod. | 4 hodín | 1 |
2 | 1 hod. | 12 hodín | 2 |
3 | 1 hod. | 24 hodín | 10 |
4 | 1 hod. | Vyriešené a nasadené v rámci plánovaných releasov |
Vysvetlivky k tabuľke
(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L2 a jeho prevzatím na riešenie.
(2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu úspešným uchádzačom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je úspešný uchádzač oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.
(3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.
(4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.
Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:
- Služby systémovej podpory na požiadanie (nad paušál)
- Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)
Pre tieto služby budú dohodnuté osobitné parametre dodávky.
7.2 Požadovaná dostupnosť IS:
Popis | Parameter | Poznámka |
Prevádzkové hodiny | 8 hodín | od 8:00 hod. - do 16:00 hod. počas pracovných dní |
Servisné okno | 8 hodín | od 8:00 hod. - do 16:00 hod. počas pracovných dní |
Dostupnosť produkčného prostredia IS | 98,5% | 98,5% z 24/7/365 t.j. max ročný výpadok je 66 hod. Maximálny mesačný výpadok je 5,5 hodiny. Vždy sa za takúto dobu považuje čas od 0.00 hod. do 23.59 hod. počas pracovných dní v týždni. Nedostupnosť IS sa počíta od nahlásenia incidentu Zákazníkom v čase dostupnosti podpory Poskytovateľa (t.j. nahlásenie incidentu na L2 v čase od 8:00 hod. - do 16:00 hod. počas pracovných dní). Do dostupnosti IS nie sú započítavané servisné okná a plánované odstávky IS. V prípade nedodržania dostupnosti IS bude každý ďalší začatý pracovný deň nedostupnosti braný ako deň omeškania bez odstránenia vady alebo incidentu. |
7.2.1 Dostupnosť (Availability)
Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok. Očakávaná 98,5 % dostupnosť znamená maximálny výpadok 66 hodín za rok.
7.2.2 RTO (Recovery Time Objective)
Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.
- Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
7.2.3 RPO (Recovery Point Objective)
Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.
- Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
8. Požiadavky na personál
8.1 Personál potrebný na projektové riadenie
Najvyššia úroveň riadenia projektu bude zastúpená v zmysle metodiky riadenia projektov PRINCE2 Riadiacim výborom projektu „RV“, ktorý bude zasadať v nasledovnom zložení:
- Predseda Riadiaceho výboru
- Projektový manažér
- Vlastník procesov
- Zástupca prevádzky (kľúčový používateľ)
- Zástupca dodávateľa
Okrem RV bude v rámci projektu zriadený tiež projektový tím žiadateľa, ktorý bude zložený:
- Manažér kybernetickej a informačnej bezpečnosti
- Kľúčový používateľ
Riadiaci výbor projektu v kooperácii s projektovým tímom bude zriadený pre účely usmerňovania a riadenia projektu ako celku. Projektový tím bude zodpovedať za celkový úspech projektu a bude zároveň nositeľom zodpovednosti a autority v rámci projektu. Okrem iného bude koordinovať činnosti publicity a informovanosti projektu a zdieľať informácie o projekte smerom k dotknutým osobám „stakeholderom“ a to počas celej doby trvania projektu a počas existencie projektového výboru samotného.
Riadiaci výbor bude schvaľovať najmä nasledovné:
- Hlavné plány projektu
- Autorizovať prípadne odchýlky od dohodnutých plánov
- Bude autorizovať ukončenie všetkých hlavných aktivít projektu (viď časový harmonogram)
- Bude zodpovedať za zabezpečenie príslušných zdrojov projektu (aj vo vzťahu k dodávateľom)
- Schvaľuje rolu Projektového manažéra
- Zodpovedá za schválenie projektovej iniciačnej dokumentácie „PID“
- Bude zodpovedať za celkové usmerňovanie projektu (sledovanie projektu v rámci tolerancií)
- Bude prehodnocovať ukončené etapy a schvaľovať prechody do ďalších etáp (aplikovateľné práve na podmienky prístupu „waterfall“...
- Na konci projektu bude zabezpečovať, aby boli produkty odovzdané uspokojivo
- Bude zodpovedať za schválenie/akceptáciu výstupov a schválenie záverečnej správy (preberacie protokoly, akceptácia predmetu projektu...).
Projektový tím bude zabezpečovať samotnú realizáciu projektu v kooperácii s dodávateľom a pripravovať potrebné dokumenty k schváleniu riadiacim výborom.
ID | Meno a Priezvisko | Pozícia | Oddelenie | Rola v projekte |
1. | Mgr. Oľga Luptáková | primátorka | Kancelária primátora | Predseda RV |
2. | Mgr. Juraj Spáčil | Vedúci | Oddelenie všeobecnej správy | Vlastník procesov/člen RV |
3. | Tibor Ružička | Informatik | Oddelenie všeobecnej verejnej správy | Zástupca prevádzky (kľúčový používateľ)/člen RV a člen projektového tímu |
4. | Vybratý v rámci VO | Zástupca dodávateľa | Dodávateľ | Člen RV bez hlasovacieho práva |
5. | Vybratý v rámci VO | Projektový manažér | Dodávateľ | Projektový manažér/člen RV bez hlasovacieho práva |
6. | Pavol Svrček | Manažér kybernetickej bezpečnosti | Oddelenie všeobecnej verejnej správy | Manažér kybernetickej a informačnej bezpečnosti (člen projektového tímu) |
Podrobnejšie informácie o projektovom tíme sa nachádzajú v Projektovom zámere, v kapitole 9. PROJEKTOVÝ TÍM.
8.2 Personál potrebný na zabezpečenie TO BE procesu
Realizáciou projektu nepredpokladáme potrebu navýšenia súčasného stavu personálu zabezpečujúceho chod IS Mestas Skalica. Chod implementovaných riešení bude zabezpečovaný súčasným personálom a v prípade nutnosti odborných zásahov bude prevádzka zabezpečená dodávateľom v zmysle platnej SLA, viď informácie uvedené v kapitole 7. PREVÁDZKA A ÚDRŽBA.
9. Implementácia a preberanie výstupov projektu
Projekt bude realizovaný metódou Waterfall. Tento prístup počíta s detailným naplánovaním jednotlivých krokov a následnom dodržiavaní postupu pri vývoji alebo realizácii projektu. Projektovému tímu je daný minimálny priestor na zmeny v priebehu realizácie. Vodopádový prístup je vhodný a užitočný v projektoch, ktoré majú jasný cieľ a jasne definovateľný postup a rozdelenie prác. Výstupy projektu akceptuje riadiaci výbor projektu bližšie informácie sú uvedené v Projektovom zámere, časť 9 – Projektový tím).
10. Prílohy
Príloha č. 1 Zoznam rizík a závislostí
Príloha č. 2 Katalóg požiadaviek