projekt_2924_Pristup_k_projektu_detailny

Naposledy upravil Admin-metais MetaIS 2024/11/07 12:21

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

Riadenie_KaIB_VZ.png

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

Aplikacna_vrstva.png

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.

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

Architektura.png

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

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