Pobierz plik PDFSprawozdanie z audytu desygnacyjnego LSI UM

Transkrypt

RZECZPOSPOLITA POLSKA
MINISTERSTWO FINANSÓW
GENERALNY INSPEKTOR KONTROLI SKARBOWEJ
DO1.9011.18.2016.3.BPS.513018
Sprawozdanie
z audytu desygnacyjnego Lokalnego Systemu
Informatycznego Województwa Śląskiego
wykorzystywanego przy wdrażaniu
Regionalnego Programu Operacyjnego
w perspektywie 2014-2020
KOD CCI 2014 PL 16M 2O P012
Warszawa, lipiec 2016 roku
Dokument zawiera 71 stron
Sprawozdanie z audytu desygnacyjnego LSI 2014
Urzędu Marszałkowskiego Województwa Śląskiego
SPIS TREŚCI
1.
INDEKS SKRÓTÓW............................................................................................5
2.
CEL I ZAKRES PRAC.........................................................................................6
3.
OPIS STANU FAKTYCZNEGO – STRESZCZENIE ......................................6
4.
POLITYKI BEZPIECZEŃSTWA INFORMACJI..........................................10
4.1.
Kierunki bezpieczeństwa informacji określane przez kierownictwo...............10
4.1.1.
Dokument polityki bezpieczeństwa informacji........................................10
4.1.2.
Przegląd polityki bezpieczeństwa informacji...........................................15
5.
ORGANIZACJA BEZPIECZEŃSTWA INFORMACJI................................16
5.1.
Organizacja wewnętrzna ................................................................................16
5.1.1.
Role i odpowiedzialności za bezpieczeństwo informacji.........................16
6.
BEZPIECZEŃSTWO ZASOBÓW LUDZKICH .............................................16
6.1.1.
7.
Uświadamianie, kształcenie i szkolenie z zakresu bezpieczeństwa
informacji .................................................................................................16
KONTROLA DOSTĘPU ....................................................................................18
7.1.
Wymagania biznesowe wobec kontroli dostępu..............................................18
7.1.1.
Polityka kontroli dostępu .........................................................................18
7.1.2.
Dostęp do sieci i usług sieciowych ..........................................................19
7.2.
Zarządzanie dostępem użytkowników .............................................................20
7.2.1.
Rejestrowanie i wyrejestrowanie użytkowników.....................................20
7.2.2.
Przydzielanie dostępu użytkownikom......................................................20
7.2.3.
Zarządzanie prawami uprzywilejowanymi ..............................................21
7.2.4.
Zarządzanie poufnymi informacjami uwierzytelniającymi
użytkowników ..........................................................................................21
7.2.5.
Przegląd praw dostępu użytkowników.....................................................21
7.2.6.
Odbieranie i dostosowywanie dostępu.....................................................22
7.3.
Odpowiedzialność użytkowników ...................................................................23
7.3.1.
Stosowanie poufnych informacji uwierzytelniających ............................23
7.4.
Kontrola dostępu do systemów i aplikacji ......................................................24
7.4.1.
Ograniczenie dostępu do informacji ........................................................24
7.4.2.
Procedury bezpiecznego logowania .........................................................25
7.4.3.
System zarządzania hasłami.....................................................................25
7.4.4.
Użycie uprzywilejowanych programów narzędziowych .........................26
7.4.5.
Kontrola dostępu do kodów źródłowych .................................................26
8.
KRYPTOGRAFIA ..............................................................................................27
Strona 2 z 71
8.1.
Zabezpieczenia kryptograficzne......................................................................27
8.1.1.
Polityka stosowania zabezpieczeń kryptograficznych .............................27
8.1.2.
Zarządzanie kluczami...............................................................................28
9.
BEZPIECZEŃSTWO FIZYCZNE I ŚRODOWISKOWE .............................28
9.1.
Obszary bezpieczne.........................................................................................28
9.1.1.
Fizyczna granica obszaru bezpiecznego ..................................................28
9.1.2.
Fizyczne zabezpieczenie wejścia .............................................................28
9.1.3.
Zabezpieczenie biur, pomieszczeń i obiektów.........................................29
9.2.
Sprzęt ..............................................................................................................30
9.2.1.
Lokalizacja i ochrona sprzętu...................................................................30
9.2.2.
Systemy wspomagające ...........................................................................31
9.2.3.
Bezpieczeństwo okablowania ..................................................................31
9.2.4.
Konserwacja sprzętu ................................................................................32
9.2.5.
Wynoszenie aktywów ..............................................................................32
9.2.6.
Bezpieczeństwo sprzętu i aktywów poza siedzibą...................................33
9.2.7.
Pozostawienie sprzętu bez opieki.............................................................33
10.
BEZPIECZNA EKSPLOATACJA....................................................................34
10.1. Procedury eksploatacyjne i odpowiedzialność ...............................................34
10.1.1. Dokumentowanie procedur eksploatacyjnych .........................................34
10.1.2. Zarządzanie zmianami .............................................................................35
10.1.3. Oddzielenie środowisk rozwojowych, testowych i produkcyjnych .........35
10.2. Ochrona przed szkodliwym oprogramowaniem .............................................36
10.2.1. Zabezpieczenie przed szkodliwym oprogramowaniem ...........................36
10.3.
Kopie zapasowe ..............................................................................................37
10.4. Rejestrowanie zdarzeń i monitorowanie.........................................................38
10.4.1. Rejestrowanie zdarzeń .............................................................................38
10.4.2. Ochrona informacji w dziennikach zdarzeń.............................................39
10.4.3. Rejestrowanie działań administratorów i operatorów..............................39
10.4.4. Synchronizacja zegarów...........................................................................39
10.5. Nadzór nad oprogramowaniem produkcyjnym...............................................40
10.5.1. Instalacja oprogramowania w systemach produkcyjnych........................40
10.6. Zarządzanie podatnościami technicznymi ......................................................40
10.6.1. Zarządzanie podatnościami technicznymi ...............................................40
11.
BEZPIECZEŃSTWO KOMUNIKACJI...........................................................41
11.1. Zarządzanie bezpieczeństwem sieci ................................................................41
11.1.1. Zabezpieczenia sieci.................................................................................41
11.1.2. Rozdzielenie sieci.....................................................................................41
12.
POZYSKIWANIE, ROZWÓJ I UTRZYMANIE SYSTEMÓW ...................42
12.1. Wymagania związane z bezpieczeństwem systemów informacyjnych.............42
12.1.1. Analiza i specyfikacja wymagań związanych z bezpieczeństwem
informacji .................................................................................................42
Strona 3 z 71
12.1.2.
Ochrona transakcji usług aplikacyjnych ..................................................46
12.2. Bezpieczeństwo w procesach rozwoju i wsparcia...........................................47
12.2.1. Przegląd techniczny aplikacji po zmianach w platformie produkcyjnej..47
12.2.2. Prace rozwojowe zlecane podmiotom zewnętrznym ...............................48
12.2.3. Testy akceptacyjne systemów ..................................................................48
12.3. Dane testowe...................................................................................................49
12.3.1. Ochrona danych testowych ......................................................................49
13.
RELACJE Z DOSTAWCAMI...........................................................................50
13.1. Bezpieczeństwo informacji w relacjach z dostawcami ...................................50
13.1.1. Polityka bezpieczeństwa informacji w relacjach z dostawcami ..............50
13.2. Zarządzanie usługami świadczonymi przez dostawców .................................51
13.2.1. Monitorowanie i przegląd usług świadczonych przez dostawców ..........51
13.2.2. Zarządzanie zmianami w usługach świadczonych przez dostawców ......52
14.
ZARZĄDZANIE INCYDENTAMI ZWIĄZANYMI
Z BEZPIECZEŃSTWEM INFORMACJI .......................................................53
14.1.
Zarządzanie incydentami związanymi z bezpieczeństwem informacji oraz
udoskonaleniami.............................................................................................53
14.1.1. Odpowiedzialności i procedury................................................................53
14.1.2. Zgłaszanie zdarzeń związanych z bezpieczeństwem informacji .............54
14.1.3. Zgłaszanie słabości związanych z bezpieczeństwem informacji .............55
14.1.4. Ocena i podejmowanie decyzji w sprawie zdarzeń związanych
z bezpieczeństwem informacji .................................................................55
14.1.5. Reagowanie na incydenty związane z bezpieczeństwem informacji .......56
14.1.6. Wyciąganie wniosków z incydentów związanych z bezpieczeństwem
informacji .................................................................................................56
15.
ASPEKTY BEZPIECZEŃSTWA INFORMACJI W ZARZĄDZANIU
CIĄGŁOŚCIĄ DZIAŁANIA .............................................................................58
15.1. Ciągłość bezpieczeństwa informacji ...............................................................58
15.1.1. Planowanie ciągłości bezpieczeństwa informacji ....................................58
15.1.2. Wdrożenie ciągłości bezpieczeństwa informacji .....................................59
15.1.3. Weryfikowanie, przegląd i ocena ciągłości bezpieczeństwa informacji..60
16.
USTALENIA I REKOMENDACJE..................................................................61
Strona 4 z 71
1.
INDEKS SKRÓTÓW
ABI
Administrator Bezpieczeństwa Informacji
ADO
Administrator Danych Osobowych
AMI
Administrator Merytoryczny Instytucji
ASI
Administrator Systemu Informatycznego
ASI
Administrator Systemu Informatycznego
CCTV
Telewizja przemysłowa
DMZ
Demilitarized zone (ograniczonego zaufania)
EFRR
Europejski Fundusz Rozwoju Regionalnego
EFS
Europejski Fundusz Społeczny
ePUAP
elektroniczna Platforma Usług Administracji Publicznej
GAM
Globalny Administrator Merytoryczny
GASI
Główny Administrator Systemów Informatycznych
HTTPS
Hypertext Transfer Protocol
IZSI
Instrukcja Zarządzania Systemem Informatycznym
LAN
Local Area Network
LS 2014
Centralny System Teleinformatyczny
LSI 2014
Lokalny System Informatyczny 2014 Województwa
Śląskiego
LTO6
Linear Tape-Open wersja 6
MIR
Ministerstwo Infrastruktury i Rozwoju
NASK
Naukowa i Akademicka Sieć Komputerowa
OPZ
Opis Przedmiotu Zamówienia
PBDO
Polityka Bezpieczeństwa Danych Osobowych
PBI
Polityka Bezpieczeństwa Informacji
PIFE
Punkt Informacyjny Funduszy Europejskich w Katowicach
REGON
Rejestr Gospodarki Narodowej
RPO
Regionalny Program Operacyjny
SEKAP
System Elektronicznej Komunikacji Administracji Publicznej
SKD
System Kontroli Dostępu
SOPZ
Szczegółowy Opis Przedmiotu Zamówienia
SSL
Secure Sockets Layer
SVN
Subversion – System Kontroli Wersji
SZBI
System Zarządzania Bezpieczeństwem Informacji
Strona 5 z 71
TLS
Transport Layer Security
UM
Urząd Marszałkowski
UM WSL
Urząd Marszałkowski Województwa Śląskiego
uodo
Ustawa o ochronie danych osobowych
Urząd
Urząd Marszałkowski Województwa Śląskiego
ustawa
wdrożeniowa
Ustawa z dnia 11 lipca 2014 r. o zasadach realizacji
programów w zakresie polityki spójności finansowanych
w perspektywie finansowej 2014-2020
VPN
Virtual Private Network
WSDL
Web Services Description Language
2.
CEL I ZAKRES PRAC
Art. 124 ust. 2 rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 1303/2013
z dnia 17 grudnia 20013 r. ustanawiającego wspólne przepisy dotyczące
Europejskiego Funduszu Regionalnego, Europejskiego Funduszu Społecznego,
Funduszu Spójności, Europejskiego Funduszu Rolnego na rzecz Rozwoju Obszarów
Wiejskich oraz Europejskiego Funduszu Morskiego i Rybackiego oraz
ustanawiającego przepisy ogólne dotyczące Europejskiego Funduszu Rozwoju
Regionalnego, Europejskiego Funduszu Społecznego, Funduszu Spójności
i Europejskiego Funduszu Morskiego i Rybackiego oraz uchylającego rozporządzenie
Rady (WE) nr 1083/2006 nakłada na niezależny podmiot audytowy obowiązek
dokonania oceny spełnienia przez instytucję zarządzającą i instytucję certyfikującą
kryteriów desygnacji określonych w załączniku XIII do rozporządzenia (UE)
nr 1303/2013, w tym kryterium dotyczącego wymogów w stosunku do systemu
elektronicznego gromadzenia, rejestracji i przechowywania danych, przy zachowaniu
standardów bezpieczeństwa uznanych w skali międzynarodowej.
Celem audytu desygnacyjnego jest uzyskanie racjonalnego zapewnienia, że instytucja
zarządzająca i instytucja certyfikująca spełniają kryteria desygnacji określone
w załączniku XIII do rozporządzenia (UE) nr 1303/2013 w zakresie funkcjonalności
i bezpieczeństwa systemów informatycznych, wspierających realizację programów
operacyjnych współfinansowanych ze środków UE.
3.
OPIS STANU FAKTYCZNEGO – STRESZCZENIE
System LSI 2014 w ramach RPO WSL 2014-2020 jest podstawowym elementem
Lokalnego Systemu Informatycznego Województwa Śląskiego, przygotowanym
zgodnie z intencją określoną w dokumencie pt. „Zasady zarządzania LSI 2014
w ramach RPO WSL 2014-2020”, w celu:
a) wspomagania zarządzania i wdrażania RPO WSL 2014-2020;
Strona 6 z 71
b) zapewnienia narzędzia informatycznego dla wnioskodawców/beneficjentów
służącego do przygotowania dokumentów;
c) zmniejszenia obciążeń administracyjnych
zaangażowanych we wdrażanie programu;
beneficjentów
i
instytucji
d) usprawnienia i przyspieszenia pracy instytucji;
e) wspomagania wybranych procesów.
Regionalny Program Operacyjny Województwa Śląskiego na lata 2014-2020 (RPO
WSL 2014-2020) został przygotowany na podstawie rozporządzenia ogólnego,
rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 1301/2013 z dnia
17 grudnia 2013 r. w sprawie Europejskiego Funduszu Rozwoju Regionalnego
i przepisów szczególnych dotyczących celu „Inwestycje na rzecz wzrostu
i zatrudnienia” oraz w sprawie uchylenia rozporządzenia (WE) nr 1080/2006 oraz
rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 1304/2013 z dnia
17 grudnia 2013 r. w sprawie Europejskiego Funduszu Społecznego i uchylającego
rozporządzenie Rady (WE) nr 1081/2006, a także na podstawie ustawy wdrożeniowej.
RPO WSL 2014-2020 jest jednym z 16 programów operacyjnych zarządzanych
i wdrażanych na poziomie regionalnym i jest jednym z instrumentów realizacji
Umowy Partnerstwa, która jest dokumentem określającym strategię interwencji
Funduszy Europejskich w ramach trzech polityk unijnych w Polsce w latach 20142020. RPO WSL 2014-2020 został zaakceptowany przez Komisję Europejską w dniu
18 grudnia 2014 roku. Dokument „Umowa Partnerstwa 2014-2020. Wspólna Lista
Wskaźników Kluczowych 2014-2020 katalog definicji dla Celów Tematycznych
finansowanych z Europejskiego Funduszu Rozwoju Regionalnego, Funduszu Spójności
oraz dla pomocy technicznej” – wersja WLWK v.5 z 7 marca 2014 r.
W ramach RPO WSL 2014-2020 funkcjonuje dwanaście merytorycznych osi
priorytetowych (finansowanych z EFRR i EFS) oraz jedna oś dedykowana działaniom
w zakresie pomocy technicznej (finansowana w całości z EFS) na rzecz całego RPO
WSL 2014-2020.
Dostęp do systemu posiadają pracownicy Instytucji Zarządzającej i Instytucji
Pośredniczących oraz podmioty wnioskujące o dofinansowanie, które obecnie mają
dostęp do tworzenia wniosków o dofinansowanie.
Dane gromadzone w systemie, wspólnie z Centralnym Systemem Teleinformatycznym
SL2014, pozwalają na uzyskanie pełnego wykazu informacji, o których mowa
w załączniku nr III, określającym wymagane dane dla operacji finansowanych z EFS,
EFRR, FS oraz EFMR, rozporządzenia delegowanego KE nr 480/2014, z wyłączeniem
pól wynikających z charakterystyki Regionalnego Programu Operacyjnego
Województwa Śląskiego. Szczegółowy wykaz danych został przedstawiony
w załączniku do sprawozdania.
System LSI 2014 stanowi odpowiedni system zapewniający zbieranie, rejestrowanie
i przechowywanie danych w formie elektronicznej dla projektów realizowanych
Strona 7 z 71
w ramach RPO WSL, przy czym pełna funkcjonalność wymagana przepisami UE
realizowana jest z udziałem systemu SL2014.
W ramach weryfikacji wymogu kontrolnego „czy istnieją odpowiednie procedury
w celu zapewnienia bezpieczeństwa i utrzymania systemu komputerowego,
integralności i poufności danych, uwierzytelniania nadawcy, i przechowywania
dokumentów i danych” zweryfikowano procedury administrowania systemem
teleinformatycznym LSI 2014, a w obszarze „ochrony osób fizycznych w zakresie
przetwarzania danych osobowych” potwierdzono realizację zasad określonych
przepisami uodo oraz zasad wynikających z Polityki Bezpieczeństwa Danych
Osobowych (PBDO) oraz Instrukcji Zarządzania Systemem Informatycznym w UM
WSL. Dokumentacja bezpieczeństwa danych osobowych została przedstawiona
w pkt. 4.1.1
Infrastruktura systemu LSI 2014 jest scentralizowana. System w całości znajduje się
w serwerowni UM w Katowicach przy ul. Dąbrowskiego 23. System utrzymywany
jest przez firmę zewnętrzną w zakresie świadczenia asysty technicznej oraz
utrzymania LSI RPO WSL 2014. Za koordynację utrzymania i rozwoju systemu
odpowiada Zespół systemów informatycznych Wydziału Rozwoju Regionalnego UM.
System pracuje na sprzęcie należącym do Urzędu. Obecnie jest rozwijany w zakresie
zmian w funkcjonalności i naprawy błędów.
W rozdziałach 4-15 niniejszego Sprawozdania zawarto szczegółowy opis stanu
faktycznego, stwierdzony podczas audytu. Na potrzeby audytu desygnacyjnego
systemu LSI 2014 przyjęto następującą skalę oceny rekomendacji:
 Istotne – ustalenie ma wpływ na opinię na temat spełnienia przez Instytucję
kryteriów desygnacji, określonych w załączniku nr XIII do rozporządzenia UE
nr 1303/2013;
 Nieistotne – ustalenie nie ma wpływu na opinię na temat spełnienia przez
Instytucję kryteriów desygnacji, określonych w załączniku nr XIII do
rozporządzenia (UE) nr 1303/2013.
Zidentyfikowane w wyniku audytu ustalenia i wydane zalecenia (zawarte
w sprawozdaniu wstępnym) zostały wdrożone przed wydaniem sprawozdania
ostatecznego (co zostało potwierdzone w wyniku audytu follow-up) poza poniżej
wskazanymi 15 rekomendacjami sklasyfikowanymi jako nieistotne.
Poniższa tabela prezentuje podsumowanie wszystkich zidentyfikowanych kwestii
w podziale na poszczególne obszary, które pozostają niewdrożone. Szczegółowy opis
wraz z rekomendacjami został zawarty w sprawozdaniu w Rozdziale 16 Ustalenia
i Rekomendacje.
Lp.
Rekomendacja
Istotna
1.
Aktualizacja PBI w zakresie
klasyfikacji
informacji
i postępowania z nią (4.1.1)
Strona 8 z 71
Nieistotna
X
2.
Określenie wykazu stosowanych
zabezpieczeń (4.1.1)
X
3.
Plan szkoleń użytkowników
systemu LSI 2014 (6.1.1)
X
4.
Przegląd dostępów (7.2.5)
X
5.
Zmiana hasła przez użytkownika
(7.3.1)
X
6.
Deponowanie haseł (7.4.3)
X
7.
Mechanizmy
i
kryptograficzne (8.1.1)
X
8.
Rejestrator CCTV (9.1.3)
9.
Drzwi
centralnego
backupu (9.2.1)
metody
X
systemu
X
10. Procedura zarządzania zmianami
(10.1.2)
X
11. Rejestrowanie
zdarzeń
i monitorowanie (10.4.1)
X
12. Zarządzanie
podatnościami
technicznymi (10.6.1)
X
13. Komitet
Bezpieczeństwem
(14.1.4)
X
14. Plan
zapewnienia
działania (15.1.1)
Sterujący
Informacji
ciągłości
X
15. Testowanie ciągłości działania
(15.1.3)
SUMA:
X
0
Strona 9 z 71
15
4.
POLITYKI BEZPIECZEŃSTWA INFORMACJI
4.1. Kierunki bezpieczeństwa informacji określane przez kierownictwo
4.1.1.
Dokument polityki bezpieczeństwa informacji
System LSI 2014 w ramach RPO WSL 2014-2020 jest dedykowanym systemem
informatycznym, który powstał w celu obsługi Regionalnego Programu
Operacyjnego Województwa Śląskiego. System przygotowany został zgodnie
z intencją określoną w dokumencie pt. „Zasady zarządzania LSI 2014 w ramach
RPO WSL 2014-2020”, w celu:

wspomagania zarządzania i wdrażania RPO WSL 2014-2020;

zapewnienia
narzędzia
wnioskodawców/beneficjentów
dokumentów;

zmniejszenia obciążeń administracyjnych beneficjentów i instytucji
zaangażowanych we wdrażanie programu;

usprawnienia i przyspieszenia pracy instytucji;

wspomagania wybranych procesów.
informatycznego
dla
służącego
do
przygotowania
Przy składaniu wniosku o dofinansowanie w ramach RPO WSL 2014-2020
wnioskodawcy są zobowiązani przygotować wniosek aplikacyjny w LSI 2014.
Wniosek o dofinansowanie złożyć można jedynie w wersji elektronicznej.
LSI 2014 został uruchomiony dla obsługi RPO WSL 2014-2020 wdrażanego
przez Instytucję Zarządzającą - Urząd Marszałkowski Województwa Śląskiego,
Śląskie Centrum Przedsiębiorczości oraz Wojewódzki Urząd Pracy
w Katowicach. Śląskie Centrum Przedsiębiorczości oraz Wojewódzki Urząd
Pracy w Katowicach to Instytucje Pośredniczące we wdrażaniu RPO WSL 20142020.
Właścicielem systemu jest Urząd Marszałkowski Województwa Śląskiego,
w którym obowiązuje polityka bezpieczeństwa - Polityka Bezpieczeństwa
Informacji stanowiąca załącznik nr 1 do Zarządzenia nr 00028/2016 Marszałka
Województwa Śląskiego z dnia 28 kwietnia 2016 roku.
Przedmiotowym zarządzeniem zostały wprowadzone do użytku służbowego
nw. dokumenty:

Polityka Bezpieczeństwa Informacji (PBI), stanowiąca załącznik nr 1 do
ww. zarządzenia;

Polityka Bezpieczeństwa Danych Osobowych (PBDO), stanowiąca
załącznik nr 2 do ww. zarządzenia;

Instrukcja Zarządzania Systemem Informatycznym (IZSI), stanowiąca
załącznik nr 3 do ww. zarządzenia;
Strona 10 z 71

Instrukcja Użytkownika
ww. zarządzenia;

Procedura Zarzadzania Dostępem (PZD), stanowiąca załącznik nr 5 do
ww. zarządzenia;

Procedura Postępowania z Incydentami (PPI), stanowiąca załącznik
nr 6 do ww. zarządzenia;

Słownik, stanowiący załącznik nr 7 do ww. zarządzenia.
(IU),
stanowiąca
załącznik
nr 4
do
Dokument główny Polityki Bezpieczeństwa Informacji określa, że „informacje
są rodzajem aktywów niezbędnych w działalności Urzędu Marszałkowskiego
Województwa Śląskiego. Aktywa te posiadają określoną wartość, dlatego
wymagają ochrony przed różnymi zagrożeniami.
Niniejsza Polityka Bezpieczeństwa Informacji wraz z politykami szczegółowymi
stanowią zatwierdzone przez kierownictwo Urzędu Marszałkowskiego
Województwa Śląskiego podejście do ochrony informacji oraz ustanawiają ramy
funkcjonowania Systemu Zarządzania Bezpieczeństwem Informacji.”
Dokument PBI zawiera m.in.:

podstawy prawne oraz normy krajowe i międzynarodowe w zakresie
zarządzania bezpieczeństwem informacji, wykorzystane na etapie
opracowywania PBI;

definicje bezpieczeństwa informacji i pojęć z nim związanych;

cel i zakres Polityki Bezpieczeństwa Informacji;

deklarację kierownictwa Urzędu – Marszałka Województwa Śląskiego
pełnego wsparcia dla podejmowanych działań uzasadnionych realizacją
celów zabezpieczenia danych osobowych przetwarzanych w Urzędzie
oraz zapewnienia środków niezbędnych do realizacji celów Systemu
Zarządzania Bezpieczeństwem Informacji.
Dokumentacja bezpieczeństwa opiera się na wytycznych zawartych w polskich
normach grupy ISO 27000.
W Polityce Bezpieczeństwa Informacji została określona formalna struktura
organizacji bezpieczeństwa informacji w Urzędzie Marszałkowskim, w ramach
której określono role i ich odpowiedzialności w zakresie funkcjonowania SZBI.
Zgodnie z polityką funkcjonują niżej wskazane role:

Kierownictwo Urzędu - Administrator Danych Osobowych (ADO) –
Marszałek/Zarząd Województwa Śląskiego. Na podstawie udzielonego
upoważnienia w imieniu ADO działa Sekretarz Województwa –
Dyrektor Urzędu. Administrator Danych Osobowych realizuje
obowiązki wynikające z przepisów prawa, regulacji wewnętrznych,
w tym PBI i polityk niższego rzędu;

Administrator Bezpieczeństwa Informacji (ABI)/Zastępca ABI, którzy
w szczególności wypełniają obowiązki określone w art. 36a ust. 2
Ustawy o ochronie danych osobowych oraz wydanych na jej podstawie
rozporządzeń; inicjują i podejmują przedsięwzięcia w zakresie
Strona 11 z 71
doskonalenia systemu zarządzania bezpieczeństwem informacji, w tym
proponują zmiany aktualizacyjne dokumentacji przetwarzania danych.
Zakres obowiązków ABI określa pkt 6.2 PBI. Zgodnie z PBI ABI we
współpracy z GASI zobowiązany jest co najmniej raz w roku dokonać
przeglądu dokumentacji pod kątem jej aktualności, kompletności
i konieczności zmian;

Główny Administrator Systemu Informatycznego (GASI), Wydział
ds. Informatyki którego rolę pełni dyrektor/zastępca dyrektora
Wydziału ds. Informatyki lub osoba upoważniona. Zakres obowiązków
GASI określa pkt 6.3 PBI. GASI odpowiada, w szczególności za:
 bezpieczeństwo systemów teleinformatycznych Urzędu oraz ich
zgodność z przepisami prawa;
 pełni nadzór nad Administratorami Systemów Informatycznych
(ASI);
 zapewnia prowadzenie dokumentacji, rejestrów i wykazów
wymaganych przepisami prawa oraz wskazanych w PBI
i politykach szczegółowych.
Jednocześnie zdefiniowane zostały obowiązki:

Administratorów Systemów
Uprawnień (ASI/AU):
Informatycznych,
Administratorów
Zgodnie z treścią PBI każdy system informatyczny (rozumiany jako
narzędzie programowe służące do przetwarzania danych,
w szczególności danych osobowych) używany w Urzędzie powinien
mieć wyznaczonego minimum jednego ASI, który odpowiada za
kwestie techniczne oraz zarządzanie uprawnieniami. W przypadku
systemów zewnętrznych wyznacza się Administratora Uprawnień
odpowiedzialnego za zarządzanie uprawnieniami użytkowników
w danym systemie;

Bezpośredniego
organizacyjnej:
przełożonego
pracownika,
kierownika
komórki
Zobowiązany jest wypełniać obowiązki wynikające z przepisów prawa,
regulacji wewnętrznych, w tym PBI i polityk szczegółowych, w tym
nadzoruje codzienne przestrzeganie zasad i obowiązków przez
podległych sobie pracowników;

osoby upoważnionej – użytkownika systemu;

właściciela aktywów;

wydziału ds. kadr:
który, zgodnie z treścią PBI (pkt 6.8), na bieżąco odnotowuje zmiany
w zatrudnieniu pracowników w systemie informatycznym służącym do
obsługi kadrowej Urzędu;
W polityce określone zostały obowiązujące w Urzędzie Marszałkowskim
narzędzia i metody zarządzania bezpieczeństwem. Określono:
Strona 12 z 71

zakres Systemu Zarządzania Bezpieczeństwem Informacji – pkt 5.1
PBI;

cele działań w zakresie ochrony i zapewniania bezpieczeństwa
informacji w Urzędzie, w tym założono ograniczanie ryzyka
związanego z zagrożeniami dla bezpieczeństwa informacji,
a w przypadku ich wystąpienia ograniczanie ich skutków;

zasady kierowania działaniami związanymi z bezpieczeństwem
informacji, gdzie przyjęto (pkt 5.4) ogólne zasady bezpieczeństwa
przetwarzania informacji;

procedurę postępowania z incydentami – załącznik nr 6 do zarządzenia
nr 00028/2016 Marszałka Województwa Śląskiego; zgodne z zasadami
określonymi w Instrukcji Zarządzania Systemem Informatycznym;

Instrukcję Zarządzania Systemem Informatycznym - załącznik nr 2 do
ww. zarządzenia;

Politykę Bezpieczeństwa Danych Osobowych.
W trakcie prac audytowych uzyskano informację o zamówieniu pt. „Doradztwo
w
zakresie
dostosowania
systemu
zarządzania
bezpieczeństwem
teleinformatycznym dla Urzędu Marszałkowskiego Województwa Śląskiego
w Katowicach przy ul. Ligonia 46”. Przedmiotowe zamówienie – zapytanie
ofertowe z dnia 3 lutego 2016 r. obejmuje poniższej określony zakres prac.
Etap I:
Aktualizacja
istniejącej
teleinformatycznego:
dokumentacji
a) weryfikacja dokumentacji w kontekście
załącznika A normy ISO/IEC 27001;
obszaru
stosowanych
bezpieczeństwa
zabezpieczeń
b) aktualizacja funkcjonujących procedur i dokumentacji;
c) opracowanie nowych procedur i dokumentacji.
Etap II:
Szacowanie ryzyka utraty bezpieczeństwa teleinformatycznego:
a) opracowanie dokumentacji procesu zarządzania ryzykiem;
b) przeprowadzenie szacowania ryzyk wraz z ich wyszczególnieniem;
c) opracowanie wyników w postaci raportu;
d) przygotowanie planu działań minimalizujących ryzyka nieakceptowalne.
Etap III:
Doradztwo w zakresie procesu zarządzania ciągłością działania:
a) opracowanie planu zarządzania
obowiązujących przepisów prawnych;
ciągłością
b) testowanie planów ciągłości działania.
Strona 13 z 71
działania
na
podstawie
Ogólnie przyjętymi zasadami zarządzania systemami informatycznymi
w Urzędzie Marszałkowskim są zasady wynikające z Instrukcji Zarządzania
Systemem Informatycznym.
Instrukcja wyznacza minimalne standardy dotyczące administrowania
i zabezpieczenia systemu informatycznego używanego w Urzędzie
Marszałkowskim Województwa Śląskiego do przetwarzania informacji. Zakres
przedmiotowy stosowania Instrukcji obejmuje całokształt wewnętrznego
systemu informatycznego przeznaczonego do przetwarzania danych, w tym
danych osobowych.
W Instrukcji określone zostały środki bezpieczeństwa stosowane do systemów
informatycznych eksploatowanych na serwerach, komputerach podłączonych do
sieci lokalnej oraz komputerach niepodłączonych do sieci teleinformatycznej,
w tym wskazano wymóg utrzymania wykazu sprzętu i oprogramowania oraz
jego bieżącej aktualizacji. Za nadzór nad wykazem odpowiedzialny jest GASI.
Wykaz prowadzony jest za pomocą Ewidencji Sprzętu Komputerowego,
oprogramowania do audytu stacji roboczych oraz narzędzia „Dziennik
serwerów”.
Instrukcja zawiera, w formie załączników, wzory formalnych dokumentów
wykorzystywanych w procesie zarządzania bezpieczeństwem informacji
w Urzędzie oraz stanowi szczegółowe zasady przetwarzania danych osobowych
w systemach informatycznych
W Urzędzie Marszałkowskim Województwa Śląskiego obowiązuje Polityka
Bezpieczeństwa Danych Osobowych.
PBDO określa specyficzne kwestie związane z realizacją obowiązków
Administratora Danych Osobowych i dotyczy danych osobowych
przetwarzanych w Urzędzie Marszałkowskim Województwa Śląskiego, w celu
zachowania bezpieczeństwa ich przetwarzania.
Zakres przedmiotowy stosowania niniejszej Polityki obejmuje wszystkie zbiory
danych osobowych Urzędu, niezależnie od sposobu i formy ich przetwarzania.
W zakresie podmiotowym PBDO obowiązuje wszystkie osoby przetwarzające
dane osobowe na rzecz Administratora Danych.
PBDO UM WSL określa w szczególności zasady powierzenia danych
osobowych do przetwarzania (pkt 10 PBDO). W taki sposób, że ABI wskazuje
i weryfikuje proponowane zapisy umowy. Umowy te podlegają przyjętej w UM
procedurze akceptacji umów.
Dokumenty formalne (polityki) nie podają zasad klasyfikacji informacji oraz
zasad regulujących sposób ich ochrony. PBI definiuje jedynie, że informacje są
rodzajem aktywów, które posiadają określoną wartość, w związku w czym
wymagają ochrony przed zagrożeniami oraz określenia (w pkt. 6.7) ich
właścicieli, tzw. właścicieli zasobów.
Strona 14 z 71
Rekomendacja 1
Aktualizacja PBI w zakresie klasyfikacji informacji
i postępowania z nią.
Uzupełnieniem wymagań PBI w aspekcie bezpiecznego korzystania z systemu
LSI 2014 jest jego „Regulamin”, który określa zasady funkcjonowania systemu
oraz dokument Zasady zarządzania LSI 2014 w ramach RPO WSL 2014-2020.
Dokumenty polityki bezpieczeństwa w głównej mierze wskazują zabezpieczenia
dotyczące bezpieczeństwa systemów informatycznych. Nie wskazują na
wszystkie zabezpieczenia obowiązujące w obszarze bezpieczeństwa informacji,
np. dotyczące bezpieczeństwa zasobów ludzkich, prowadzenia cyklicznej oceny
podatności i zagrożeń, prowadzenia analizy ryzyka.
Rekomendacja 2
Określenie wykazu stosowanych zabezpieczeń w UM.
Regulamin dostępny jest na stronie internetowej https://lsi.slaskie.pl/.
Użytkownik podczas logowania do LSI 2014 ma dostęp do dokumentu
i możliwość zapoznania się z jego treścią. Z kolei Zasady Zarządzania LSI 2014,
zastrzeżone do użytku wewnętrznego, dostępne są wyłącznie pracownikom
Instytucji Zarządzającej i Instytucji Pośredniczących RPO WSL 2014-2020.
Dokument reguluje kwestie organizacyjne i określa zasady współpracy
w zakresie zarządzania LSI 2014, jak również wskazuje zasady bezpieczeństwa
oraz bezpiecznej pracy z systemem.
System LSI 2014 Województwa Śląskiego objęty jest Systemem Zarządzania
Bezpieczeństwem Informacji funkcjonującym w Urzędzie Marszałkowskim
Województwa Śląskiego. Poszczególne elementy tego systemu zostaną opisane
w niniejszym Sprawozdaniu, w sposób właściwy do zakresu audytu.
4.1.2.
Przegląd polityki bezpieczeństwa informacji
Polityka Bezpieczeństwa Informacji Urzędu Marszałkowskiego jest dokumentem
wprowadzonym w życie Zarządzeniem nr 00028/2016 Marszałka Województwa
Śląskiego z dnia 28 kwietnia 2016 r.
Ostatniej aktualizacji PBI dokonano ww. zarządzeniem. Zmiany nastąpiły
w związku z audytem LSI 2014 realizowanym przez IA (Ministerstwa
Finansów).
Za aktualizację dokumentacji bezpieczeństwa odpowiada ABI we współpracy
z GASI, który w przypadku zidentyfikowania konieczności zmian w ramach
przeglądu lub poza nim we współpracy z pozostałymi osobami pełniącymi
funkcje w ramach SZBI przedstawia propozycje zmian do ADO.
Strona 15 z 71
5.
ORGANIZACJA BEZPIECZEŃSTWA INFORMACJI
5.1. Organizacja wewnętrzna
5.1.1.
Role i odpowiedzialności za bezpieczeństwo informacji
Podstawowe wytyczne w zakresie rozdzielenia obowiązków w obszarze
zarządzania bezpieczeństwem zostały opisane w Polityce Bezpieczeństwa
Informacji Urzędu Marszałkowskiego. Podstawową zasadą przyjętą w celu
zapewnienia bezpieczeństwa przetwarzanych informacji jest rozdzielenie
obowiązków, które zostało określone w pkt. 6 PBI.
Zgodnie z treścią polityki funkcjonują role: ADO, ABI, GASI, ASI, dla których
określono zakres zadań i obowiązków. Zadania ADO realizuje zgodnie
z upoważnieniem Sekretarz Województwa – Dyrektor Urzędu. Dyrektor
Wydziału Informatyki realizuje nadzór nad ASI oraz odpowiada za realizację
zadań określonych w PBI. Do pełnienia roli ABI upoważniony został pracownik
urzędu, który został zgłoszony do rejestru administratorów bezpieczeństwa,
prowadzonego przez GIODO. Za koordynowanie prac związanych z
wdrożeniem Lokalnego Systemu Informatycznego 2014-2020 (LSI 2014), jego
obsługę, zmiany i rozbudowę, w tym zarządzanie użytkownikami i ich
uprawnieniami odpowiada Zespół systemów informatycznych (RR-ZSI), który
w strukturze organizacyjnej podlega Dyrektorowi Wydziału Rozwoju
Regionalnego (RR). Za zapewnienie wsparcia w obsłudze głównych aplikacji
UM WSL, m.in. LSI odpowiada Zespół ds. aplikacji zarządzania i
programowania Referatu Informatyki (AI).
Role kont użytkowników zostały scharakteryzowane i określone w dokumencie
Zasady zarządzania LSI 2014 w ramach RPO WSL 2014-2020. Rozdzielone
zostały funkcje administratora technicznego (pracownik AI) oraz
merytorycznego (właściwy przedstawiciel strony biznesowej). Załącznik nr 8 do
Zasad zarządzania LSI 2014 określa podział zadań pomiędzy AMI a GAM.
6.
BEZPIECZEŃSTWO ZASOBÓW LUDZKICH
6.1.1.
Uświadamianie, kształcenie i szkolenie z zakresu bezpieczeństwa
informacji
System LSI 2014 jest nowopowstałą aplikacją realizowaną na podstawie umowy
nr 2475/RR/2014/FS zawartej w dniu 31 lipca 2014 r. pomiędzy Województwem
Śląskim z siedzibą w Katowicach przy ul. Ligonia 46, a spółką cywilną pod
nazwą ART4NET, wyłonioną w trybie przetargu nieograniczonego o numerze
sprawy AI-ZP.272.1.00060.2014.AKU zgodnie z przepisami ustawy z dnia 29
stycznia 2004 r. Prawo zamówień publicznych.
Strona 16 z 71
Przedmiotem umowy była cyt.: „usługa: wytworzenia, uruchomienia, asysty
technicznej i utrzymania Lokalnego Systemu Informatycznego dla Regionalnego
Programu Operacyjnego Województwa Śląskiego na lata 2014-2020”.
Zobowiązaniem wykonawcy wynikającym z tej umowy było wykonanie zakresu
prac będącego przedmiotem umowy zgodnie z OPZ, aktualnym poziomem
wiedzy technicznej, obowiązującymi przepisami oraz należytą starannością.
Wymaganiem umowy było, aby każda z osób zaangażowanych w realizację
zamówienia ze strony wykonawcy podpisała przed przystąpieniem do jego
realizacji zobowiązanie do niegromadzenia, nieudostępniania i nieujawniania
żadnych danych osobom trzecim, zgodnie ze wzorem zawartym w załączniku
nr 3 do umowy.
Wykonawca realizował szkolenia zgodnie z zakresem przedmiotu zamówienia.
Szkolenia kierowane były dla administratorów i kluczowych użytkowników
systemu. Zaznaczyć należy, że szkolenia w zakresie obsługi systemu LSI 2014
realizował również, niezależnie od wykonawcy, Zespół systemów
informatycznych Wydziału Rozwoju Regionalnego. Podczas prac audytowych
(audyt na miejscu w dniach 1-4 marca 2016 r.) odnotowano realizację przez
Zespół systemów informatycznych szkolenia dedykowanego administratorom
LSI 2014. Szkolenie dotyczyło eksportu danych oraz wypełniania wniosku
o nadanie uprawnień do SL 2014. Według uzyskanych informacji szkolenia
użytkowników i operatorów realizowane są w ramach bieżących potrzeb, siłami
własnymi Zespołu systemów informatycznych Wydziału RR.
W trakcie realizowanych czynności audytowych nie udało się potwierdzić, że
wszyscy użytkownicy systemu zostali przeszkoleni.
Rekomendacja 3
Plan szkoleń użytkowników systemu LSI 2014.
Potwierdzono jedynie cykliczną realizację szkoleń z zakresu ochrony danych
osobowych i bezpieczeństwa informacji. Szkolenia są planowane, a ich
harmonogram
dostępny
jest
na
stronie
intranetowej
UM –
zakładka: „Realizacja standardów/Bezpieczeństwo
informacji/Szkolenia”
(http://intranet.slaskie.pl/pp/section/219/).
Strona 17 z 71
7.
KONTROLA DOSTĘPU
7.1. Wymagania biznesowe wobec kontroli dostępu
7.1.1.
Polityka kontroli dostępu
Dla systemu LSI 2014 polityka kontroli dostępu została określona
w dokumencie Zasady zarządzania LSI 2014 w ramach RPO WSL 2014-2020.
Do systemu dostęp mają: Wydział Rozwoju Regionalnego UM, Wydział
Europejskiego Funduszu Społecznego UM, Wydział Europejskiego Funduszu
Rozwoju Regionalnego UM, Wojewódzki Urząd Pracy w Katowicach, Śląskie
Centrum Przedsiębiorczości oraz beneficjenci. Zarządzaniem użytkownikami
systemu zajmują się Administratorzy Merytoryczni w Instytucji Zarządzającej
– UM. Uprawnienia dla pracowników Instytucji Zarządzającej nadaje Globalny
Administrator Merytoryczny (GAM). Obowiązuje procedura nadawania
uprawnień dla użytkowników systemu LSI 2014 (operatorów). W procesie
nadawania uprawnień rozdzielone zostały role w obszarze wnioskowania,
autoryzacji wniosku oraz zarządzania dostępem. W Zasadach zarządzania
LSI 2014 określono wymaganie przeglądu aktywności użytkowników, które
wykonuje GAM, w poszczególnych instytucjach do 15 dnia każdego miesiąca.
Ich wyniki w formie elektronicznej ze stanem aktywności przekazywane są do
AMI. W przypadku użytkowników, których konta nie były aktywne przez
2 miesiące, AMI wnioskuje o wycofanie uprawnień zgodnie z procedurą
wycofania uprawnień. Przedstawiony raport uprawnień dla operatorów
i administratorów LSI z dnia 26 lutego 2016 roku przedstawia listę
użytkowników wraz z informacją o uprawnieniach grupowych i systemowych
przypisanych użytkownikowi, jak również informacją o statusie konta
(niezablokowane, zablokowane, aktywowane, brak aktywacji). Raport
potwierdza, że konto systemowe administratora globalnego jest zablokowane,
a użytkownicy uprzywilejowani korzystają ze swoich imiennych kont.
Wymagania bezpieczeństwa w zakresie kontroli dostępu, w tym dostępu
fizycznego określone zostały w dokumentacji bezpieczeństwa (PBI, IZSI,
PBDO, PZD). Wynika z nich, że:

dostęp do pomieszczeń jest ograniczony. Dostęp do pomieszczeń
posiadają jedynie upoważnieni pracownicy zgodnie z przyjęta
procedurą – Procedurą Zarządzania Dostępem, stanowiącą załącznik
nr 5 do Zarządzenia nr 00028/2016 Marszałka Województwa Śląskiego
z dnia 28 kwietnia 2016 roku;

osoby postronne lub nieposiadające upoważnienia do dostępu do
danego pomieszczenia, mogą przebywać w pomieszczeniu wyłącznie
w obecności pracownika posiadającego stosowne upoważnienie;
Strona 18 z 71

w celu zapewnienia pełnej kontroli osób trzecich z firm świadczących
usługi wymagane jest stosowanie odpowiednich klauzul w umowach;

w obszarze chronionym (pomieszczenia techniczne, serwerownia,
archiwum, kasa, itp.) stosuje się dodatkowe środki kontroli personelu
oraz stron trzecich;

określono szczegółowe zasady ochrony serwerowni i pomieszczeń
technicznych.
7.1.2.
Dostęp do sieci i usług sieciowych
System LSI 2014 jest systemem centralnym dla RPO WSL utrzymywanym
przez Urząd Marszałkowski Województwa Śląskiego. Utrzymanie w zakresie
asysty technicznej i naprawy błędów powierzono firmie Alterout IT Sp. z o. o.
z siedzibą w Gdańsku, na mocy umowy zawartej w dnia 4 maja 2016 r.
Aplikacja produkcyjna dostępna jest pod adresem https://lsi.slaskie.pl.
Dostępna w Internecie jest również, pod adresem https://lsi.slaskie.pl, wersja
szkoleniowa tej aplikacji. Dostęp realizowany jest za pośrednictwem
przeglądarki internetowej oraz szyfrowanego protokołu HTTPS. W celu
zapobiegania przechwytywania i zmieniania przesyłanych danych zastosowano
szyfrowanie za pomocą protokołu TLS (Transport Layer Security).
Konfiguracja serwerów systemu LSI 2014 pozwala na zestawianie połączenia
szyfrowanego wyłącznie za pomocą protokołu TLS w wersji 1.1 oraz wyższej.
W UM funkcjonują wymagania w zakresie zdalnego dostępu do systemu –
pkt 6.3. Instrukcji Zarządzania Systemem Informatycznym. Dostęp poprzez
VPN realizowany jest zgodnie z obowiązującą procedurą. Dostęp poprzez
kanał szyfrowany mogą uzyskać podmioty zewnętrzne, które podpisały z UM
umowy na wytworzenie, dostarczenie i/lub serwis oprogramowania
użytkowanego w ramach systemów informatycznych Urzędu.
Wnioski o dostęp zdalny (załącznik nr 1 do IZSI) weryfikuje i zatwierdza
GASI. Wnioski muszą być umotywowane, a dostęp pracowników musi
wynikać z konieczności realizacji obowiązków służbowych, m.in. z uwagi na
sprawowany nadzór nad prawidłowością funkcjonowania całodobowych
serwisów lub usług sieciowych Urzędu.
W ramach realizacji Umowy nr 2475/RR/2014/FS na wytworzenie,
uruchomienie, asystę techniczną i utrzymanie LSI 2014 wykonawca systemu
LSI 2014 posiadał, na czas realizacji umowy, zdalny dostęp do serwera
produkcyjnego oraz środowiska testowego.
System LSI 2014 autoryzowany jest poprzez certyfikat wystawiony przez
centrum certyfikacji Unizeto Technologies S.A. Certyfikat – ważny jest do
19 sierpnia 2018 roku.
W zakresie oceny skuteczności pracy systemów bezpieczeństwa sieciowego
przeprowadzono testy polegające na próbach otwarcia, na stanowisku
użytkownika, stron zabronionych. Testy zakończono wynikiem pozytywnym.
W przypadku blokowania dostępu do treści stron WWW system generuje
komunikat o przyczynie zablokowania dostępu.
Strona 19 z 71
7.2. Zarządzanie dostępem użytkowników
7.2.1. Rejestrowanie i wyrejestrowanie użytkowników
Wytyczne w zakresie nadawania uprawnień określone zostały w dokumencie
Zasady zarządzania LSI 2014 w ramach RPO WSL 2014-2020 dostępnym dla
pracowników IZ oraz IP.
Proces nadawania uprawnień opiera się na realizacji wniosków:

o nadanie/zmianę/wycofanie uprawnień do Lokalnego Systemu
Informatycznego Regionalnego Programu Operacyjnego Województwa
Śląskiego na lata 2014-2020 (LSI 2014) dla pracownika instytucji
(Załącznik nr 1 do Zasad zarządzania LSI 2014);

o założenie konta w ramach Lokalnego Systemu Informatycznego (LSI
2014) Regionalnego Programu Operacyjnego Województwa Śląskiego
na lata 2014-2020 dla Członka (Załącznik nr 4 do Zasad zarządzania
LSI 2014);

o powołania do pełnienia funkcji Administratora Merytorycznego LSI.
Użytkownicy nie będący pracownikami instytucji ogłaszającej nabory
rejestrują się sami potwierdzając rejestrację za pomocą linku wysłanego na
adres e-mail podany przy rejestracji. Wyrejestrowanie jest dokonywane przez
administratora na wniosek użytkownika.
Użytkownicy będący pracownikami instytucji ogłaszającej nabór zostają
zgłoszeni zgodnie z procedurą i po weryfikacji administrator tworzy dla nich
konto. Na adres e-mail użytkownika wysyłany jest link umożliwiający nadanie
hasła.
7.2.2. Przydzielanie dostępu użytkownikom
Wnioskodawcy i Beneficjenci zakładają konta samodzielnie zgodnie
z Instrukcją obsługi użytkownika Lokalnego Systemu Informatycznego 2014 dla
Wnioskodawców i Beneficjentów RPO WSL 2014-2020. W przypadku
utracenia dostępu przez Beneficjenta/Wnioskodawcę do profilu (brak dostępu
do maila, brak dostępu do loginu właściciela profilu), na pisemny wniosek
właściciela profilu GAM przydzieli uprawnienia właściciela profilu innemu
użytkownikowi.
Zgodnie z PBI przyjęta zasadą jest przydzielanie praw dostępu tylko w
zakresie niezbędnym do wykonywania określonego zadania (pkt 5.4 PBI).
Zasady przydzielania dostępu użytkownikom UM określone zostały w
Procedurze Zarządzania Dostępem. Uprawnienia do systemu informatycznego
realizowane są za pomocą wniosku o uprawnienia. Wniosek sporządzany jest
przez bezpośredniego przełożonego użytkownika lub osobę przez niego do
tego wyznaczoną za pomocą dedykowanego systemu informatycznego eABI
i podpisywany w wersji papierowej. W przypadku przetwarzania w systemie
Strona 20 z 71
informatycznym danych osobowych konieczne jest również sporządzenie
upoważnienia do przetwarzania danych osobowych Wzory upoważnień
stanowią załączniki do PBDO. Dla każdej osoby, upoważnianej do pracy
w systemie informatycznym, określony zostaje dostęp oraz poziom uprawnień
do systemów przetwarzania danych w zależności od zajmowanego stanowiska
i przydzielonych obowiązków służbowych, z jednoczesnym wskazaniem, czy
konieczne jest odebranie lub zmiana uprawnień dotychczasowych. Podpisany
wniosek składany jest w oryginale do zatwierdzenia do ABI, a następnie
przekazywany do realizacji do właściwego ASI/AU.
7.2.3. Zarządzanie prawami uprzywilejowanymi
Zarządzania prawami uprzywilejowanymi realizowane jest analogicznie jak
zostało to przedstawione w punkcie 7.2.2 „Przydzielanie dostępu
użytkownikom”.
7.2.4. Zarządzanie poufnymi informacjami uwierzytelniającymi użytkowników
Na wniosku o przyznanie dostępu, stanowiącym załącznik nr 1 do Zasad
zarządzania LSI 2014 w ramach RPO WSL 2014-2020 użytkownik potwierdza,
iż został przeszkolony w zakresie obsługi LSI 2014 oraz zapoznał się
i zobowiązuje się do stosowania zasad bezpieczeństwa LSI 2014.
Hasła użytkowników nie są przekazywane drogą mailową. Do użytkownika
trafia e-mail zawierający link, poprzez który dokonuje się aktywacji konta oraz
ustalenie hasła.
7.2.5. Przegląd praw dostępu użytkowników
Bezpośrednim zarządzaniem uprawnieniami zajmują się Administratorzy
Merytoryczni Instytucji Zarządzającej. W dokumencie Zasady zarządzania LSI
2014 w ramach RPO WSL 2014-2020 określono zasady wykonywania
przeglądów aktywności użytkowników (pkt 5 Zasad zarządzania LSI). GAM
wykonuje
raport
przedstawiający
stan
aktywności
użytkowników
(w poszczególnych instytucjach) do 15 dnia miesiąca, następującego po
miesiącu którego dotyczy i przekazuje wyniki w formie elektronicznej ze stanem
aktywności do AMI w poszczególnych instytucjach, których pracownicy
korzystają z systemu. W przypadku użytkowników, których konta nie były
aktywne przez 2 miesiące, AMI wnioskuje o wycofanie uprawnień zgodnie
z procedurą wycofania uprawnień.
Administrator Merytoryczny Instytucji odpowiada za weryfikację i przegląd
praw dostępu. Raport uprawnień dla operatorów i administratorów w systemie
LSI RPO WSL 2014-2020, który podlegał ocenie, wskazuje przypisane
użytkownikowi uprawnień kategoryzowanych jako grupowe i systemowe.
W UM weryfikacja uprawnień oparta jest na informacjach z aplikacji o nazwie
System Uprawnień Pracowniczych.
Strona 21 z 71
Zasady realizacji przeglądu praw dostępu użytkowników określa Procedura
Zarządzania Dostępem, stanowiąca załącznik nr 5 do Zarządzenia
nr 00028/2016 Marszałka Województwa Śląskiego. Zgodnie z przyjętymi
zasadami przeglądy przeprowadzają ASI/AU nie rzadziej jednak niż raz na
6 miesięcy. Przegląd polega na:
a) porównaniu stanu elektronicznego rejestru uprawnień prowadzonego przez
ABI ze stanem faktycznym w danym systemie informatycznym;
b) przeglądzie nadanych zakresów uprawnień pod kątem zasad wymienionych
w pkt. 5 Procedury Zarządzania Dostępem;
c) zidentyfikowaniu użytkowników, którzy nie wykazują aktywności w domenie
Active Directory UM (brak logowań powyżej 6 miesięcy lub w innym okresie
zgodnym z zasadami obowiązującymi dla danej aplikacji).
W trakcie audytu nie potwierdzono realizacji takich przeglądów,
w szczególności nie potwierdzono wykonywania przeglądów dla wykrywania
kont nieaktywnych na poziomie kontrolera domeny.
Rekomendacja 4
Przegląd dostępów.
7.2.6. Odbieranie i dostosowywanie dostępu
Wycofanie uprawnień dokonywane jest za pomocą tego samego formularza co
nadanie oraz zmiana uprawnień. Zakres uprawnień pozostaje niewypełniony,
a pozostałe pola z części 1 wniosku zostają oznaczone jako „nie dotyczy”,
w przeciwnym razie wniosek jest traktowany jako niepoprawny.
Odbieranie uprawnień następuje na podstawie wniosku zatwierdzonego przez
kierownika właściwej komórki organizacyjnej, który przesyłany jest do
Administratora Merytorycznego. Następnie Administrator blokuje konto
i przesyła pocztą elektroniczną, na adres wskazany we wniosku, informację
o odebraniu uprawnień do aplikacji.
Procedury nadawania/modyfikowania/odbierania uprawnień charakteryzuje ten
sam sposób postępowania i przepływu informacji.
Dodatkowo udokumentowano i przyjęto do stosowania procedurę blokowania
dostępu do profilu użytkownika LSI 2014 z przyczyn bezpieczeństwa. Procedura
określona została jako odstępstwo od zapisów Instrukcji Wykonawczych
w zakresie funkcjonowania systemu zarządzania i kontroli IZ pkt 9.2.3.
Procedura określa przebieg czynności/zadań, odpowiedzialnego za ich
realizację, termin wykonania oraz kanał komunikacyjny służący do
przekazywania powiadomień. Dodatkowo określony został wymóg prowadzenia
rejestru zgłoszeń dotyczących blokowania kont użytkowników LSI 2014 z
przyczyn bezpieczeństwa, jak również określono czynność informowania
bezpośredniego przełożonego użytkownika o odebraniu uprawnień. Zgodnie z
Procedurą Postępowania z Incydentami o zaistniałych incydentach
informowany jest ABI.
Strona 22 z 71
7.3. Odpowiedzialność użytkowników
7.3.1.
Stosowanie poufnych informacji uwierzytelniających
Stosowanie danych uwierzytelniających zostało opisane w opublikowanym na
stronie systemu LSI 2014 w dokumencie: „Instrukcja użytkownika Lokalnego
Systemu Informatycznego 2014 dla Wnioskodawców/Beneficjentów”.
Wszyscy użytkownicy zobowiązani są do przestrzegania Regulaminu, w tym
zasad bezpieczeństwa w nim opisanych, jak również zakładając konto
w systemie akceptują jego postanowienia.
Użytkownicy – wnioskodawcy/beneficjenci w systemie używają haseł
skonfigurowanych zgodnie z zasadami bezpieczeństwa podanymi w „Instrukcji
użytkownika
Lokalnego
Systemu
Informatycznego
2014
dla
Wnioskodawców/Beneficjentów”, cyt.: „Celem zwiększenia bezpieczeństwa
hasła (siły hasła) należy użyć kombinacji znaków specjalnych, dużych i małych
liter oraz cyfr. Przykładowo, można zastąpić niektóre litery znakami specjalnymi
(np. A=4, O=0, S=5=$, a=@, i=!=&, 8=B itp.). Jednocześnie należy wziąć pod
uwagę, iż tak skonstruowane hasło powinno być łatwe do zapamiętania. W celu
zwiększenia siły hasła można zastępować litery ich odpowiednikami w liczbach
lub znakach specjalnych lub odwrotnie, przykładowo: A=4, O=0, S=5=$, a=@,
i=!=&, 8=B itp. Bezpieczne hasło powinno zawierać:
 min. 8 znaków;
 dużą literę;
 małą literę;
 przynajmniej jedną cyfrę;
 znaki specjalne (np. !,@,$,% itp.).
Hasło nie powinno zawierać:
 loginu do Systemu;
 imienia lub nazwiska.
System LSI 2014 wymusza zmianę hasła co 30 dni.”
Użytkownicy – pracownicy IZ oraz IP zobowiązani są do przestrzegania zasad
bezpieczeństwa (pkt. 12 Zasad zarządzania LSI 2014), w tym zaleceń
dotyczących haseł użytkowników.
Strona 23 z 71
Użytkownicy są zobowiązani do ustawienia ekranów monitorów w taki sposób,
aby uniemożliwić osobom postronnym wgląd lub spisanie informacji aktualnie
wyświetlanej na ekranie monitora. Użytkownik zobowiązany jest również do
przestrzegania zasady czystego biurka. W szczególności przed opuszczaniem
swego stanowiska pracy użytkownik powinien schować wszelkie dokumenty
związane z używanym systemem oraz informatyczne nośniki danych (płyty CD,
DVD, pendrive itp.).
Ustalono, że zmiana hasła przez użytkownika w systemie LSI 2014 nie wymaga
podania hasła dotychczasowego.
Rekomendacja 5
Zmiana hasła przez użytkownika.
7.4. Kontrola dostępu do systemów i aplikacji
7.4.1.
Ograniczenie dostępu do informacji
W aplikacji zastosowano ograniczanie dostępu do informacji wyłącznie
niezbędnych do wykonywania obowiązków służbowych. Użytkownik po
stronie beneficjenta widzi tylko dane w systemie w zakresie projektu, który
realizuje. Użytkownicy widzą tylko wnioski obsługiwane w ramach osi
w zakresie realizowanych działań, które obsługują. W systemie zastosowano
podział uprawnień użytkowników poprzez przypisanie użytkownikom
uprawnień grupowych oraz uprawnień systemowych, przy czym na wniosku
o nadanie/zmianę/modyfikację uprawnień określa się uprawnienia do funkcji
systemu. Aby poprawnie procedować wniosek o dofinansowanie oraz wniosek
o płatność realizowana jest weryfikacja formalna oraz merytoryczna
wykonywana przez co najmniej dwóch pracowników. Tak procedowany
wniosek jest następnie zatwierdzany. Szczegółowe procedury w tym zakresie
określają instrukcje wykonawcze:

„Instrukcje wykonawcze Instytucji Zarządzającej Regionalnym
Programem Operacyjnym Województwa Śląskiego na lata 2014-2020”,
stanowiące załącznik nr 1 do Uchwały Zarządu Województwa
Śląskiego nr 190/90/V/2016 z dnia 2 lutego 2016 r.;

„Instrukcje wykonawcze Śląskiego Centrum Przedsiębiorczości
Instytucji Pośredniczącej Regionalnego Programu Operacyjnego
Województwa Śląskiego na lata 2014-2020”, stanowiące załącznik nr 1
do Uchwały Zarządu Województwa Śląskiego nr 195/90/V/2016 z dnia
2 lutego 2016 r.;

„Instrukcje wykonawcze Wojewódzkiego Urzędu Pracy w Katowicach
Instytucji Pośredniczącej – Regionalnego Programu Operacyjnego
Województwa Śląskiego na lata 2014-2020”, stanowiące załącznik nr 1
do Uchwały Zarządu Województwa Śląskiego nr 196/90/V/2016 z dnia
2 lutego 2016 r.
System zaprojektowano tak, aby nawet użytkownik z teoretycznie
największymi uprawnieniami nie był w stanie ocenić i zaakceptować wniosku.
Strona 24 z 71
Analogiczna sytuacja jest w przypadku użytkowników z innymi
uprawnieniami. Wyjątek stanowią Administratorzy Merytoryczni, których
uprawnienia pozwalają na wykonywanie wszystkich czynności jednak nie
biorą oni udziału w obsłudze wniosków w systemie.
7.4.2.
Procedury bezpiecznego logowania
Aby uzyskać dostęp do systemu użytkownicy muszą znać swój login i hasło.
Użytkownicy tworzą swój login w trakcie rejestracji w systemie LSI 2014.
Tworząc konto w systemie oświadczają, że zapoznali się z Regulaminem,
akceptują jego postanowienia i oświadczają o zapoznaniu się z informacją
dotyczącą zasad ochrony danych osobowych w systemie LSI 2014.
Złożoność hasła wymuszana jest na użytkowniku poprzez funkcjonalność
systemu. Polityka haseł była przedmiotem badania podczas testowania
mechanizmów kontrolnych systemu LSI 2014. W Systemie są używane hasła
skonfigurowane zgodnie z zasadami bezpieczeństwa opisanymi już w punkcie
4.3.1 Stosowanie poufnych informacji uwierzytelniających. System podczas
zmiany hasła generuje komunikaty ułatwiające zidentyfikowanie rozbieżności
pomiędzy hasłem o wymaganej sile np. hasło zbyt krótkie, hasło nie może być
takie samo jak używane. Potwierdzenie zgodności loginu i hasła umożliwia
dostęp do systemu. Podczas wpisywania znaki wpisywanego hasła nie są
ujawniane.
7.4.3.
System zarządzania hasłami
System zarządzania hasłami w aplikacji LSI 2014 określony został
w dokumencie Zasady zarządzania LSI 2014 w ramach RPO WSL 2014-2020.
Stosuje się hasła o wymaganej złożoności i odpowiadające wymaganiom
rozporządzenia z dnia 29 kwietnia 2004 r. w sprawie dokumentacji
przetwarzania
danych
osobowych
oraz
warunków
technicznych
i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy
informatyczne służące do przetwarzania danych osobowych.
Użytkownicy po stronie Instytucji Zarządzającej stosują się do polityki haseł
określonej w Instrukcji Użytkownika i Instrukcji Zarządzania Systemem
Informatycznym, która to instrukcja jest dokumentem dedykowanym
administratorom oraz pracownikom Wydziału ds. Informatyki UM.
Polityka haseł wymuszona jest przez kontroler domeny. Dostęp do systemów
w trybie administracyjnym odbywa się poprzez indywidualne konta
administratorów. Co najmniej dwóch administratorów odpowiada za
administrację systemem/zasobem w trybie administracyjnym. Obowiązuje
przyjęty system zastępstw osób pełniących rolę administratorów.
Jednocześnie w IZSI określono, że usługa katalogowa może służyć do
uwierzytelniania użytkownika w innych systemach informatycznych Urzędu,
stanowić tzw. pojedynczy punkt logowania (ang. „single sign on” - SSO).
Podczas prac audytowych nie potwierdzono deponowania haseł wymaganych
do zarządzania systemem LSI 2014.
Strona 25 z 71
Rekomendacja 6
7.4.4.
Deponowanie haseł.
Użycie uprzywilejowanych programów narzędziowych
Konta stacji roboczych pracowników UM są kontami użytkowników
z ograniczonymi uprawnieniami, które definiowane są na kontrolerze domeny
i zarządzane w punkcie centralnym dla wszystkich pracowników. W UM
przyjęto standard konfiguracji stacji roboczych pracowników oraz określono
listę programów zatwierdzonych do użytkowania. Standard konfiguracji
utrzymuje Zespół ds. Help Desk w Referacie Informatyki. Zgodnie z Instrukcją
Użytkownika o dopuszczeniu do użytkowania nowego oprogramowania
niezależnie od licencji decyduje GASI. Dla każdego typu komputera lokalny
service desk utrzymuje listę obrazów stacji roboczych utworzonych
programem Acronis True Image File. Zasady instalacji oprogramowania na
stacjach roboczych użytkowników określa Instrukcja Użytkownika. Dodatkowe
oprogramowane niezbędne do wykonywania obowiązków służbowych
instalowane jest na zatwierdzony przez kierującego komórką organizacyjną
wniosek użytkownika i podlega akceptacji przez GASI.
7.4.5.
Kontrola dostępu do kodów źródłowych
W trakcie tworzenia systemu LSI 2014 przez firmę ART4NET Spółka cywilna,
kody źródłowe przechowywane były w systemie SVN wykonawcy, który
bezpośrednio odpowiadał za wgrywanie na serwery nowych wersji aplikacji.
Dostęp do serwerów odbywał się poprzez dedykowane łącze VPN. Wszystkie
serwery podlegały archiwizacji zgodnie z polityką kopii zapasowych (kopia
przyrostowa co 24 godziny).
Nowy wykonawca – firma Alterout IT Sp. z o.o. wersjonuje zmiany w kodzie
źródłowym w aplikacji GIT. Synchronizacja plików aplikacji odbywa się
poprzez SFTP – synchronizacja katalogów na serwerach UM. Archiwizacji
w trybie kopii przyrostowej co 24 godziny podlega wersja szkoleniowa oraz
produkcyjna LSI 2014.
Dostęp do serwerów systemu LSI 2014 ze strony UM posiadają wyłącznie
administratorzy techniczni tego systemu.
8.
KRYPTOGRAFIA
8.1. Zabezpieczenia kryptograficzne
8.1.1.
Polityka stosowania zabezpieczeń kryptograficznych
W zakresie zasad dotyczących stosowania zabezpieczeń kryptograficznych
w celu ochrony poufności przesyłanych danych oraz uwierzytelnienia
użytkowników w UM określono wymagania dotyczące:
Strona 26 z 71

zasad posługiwania się w UM podpisem elektronicznym (pkt 8
Instrukcji Użytkownika);

składowania w systemie przetwarzania haseł użytkownika w formie
zaszyfrowanej (pkt 7 ppkt f Instrukcji Zarządzania Systemem
Informatycznym);

wymagania zestawiania połączeń szyfrowanych pomiędzy komórkami
organizacyjnymi mieszczącymi się w różnych budynkach
w Katowicach za pomocą protokołu MACsec oraz połączeń VPN dla
połączeń stałych między różnymi jednostkami UM i podmiotami
zewnętrznymi (pkt 6.2 i pkt 6.3 IZSI);

stosowania środków ochrony kryptograficznej do ochrony danych
przesyłanych do i z systemów informatycznych poprzez sieć publiczną
wobec danych wykorzystywanych do uwierzytelnienia (pkt 18 IZSI);

mechanizmów
kryptograficznych
dla
bezprzewodowej Wi-Fi (pkt 6.4 IZSI);

szyfrowania za pomocą programów 7-Zip, WinRAR lub PGP
przesyłanych pocztą elektroniczną danych chronionych w postaci
jawnej, w szczególności dotyczy to danych osobowych lub innych
służbowych informacji (pkt 13.3 ppkt g IZ);

szyfrowania dysków wewnętrznych komputerów przenośnych (pkt 15
ppkt c IZSI).
stosowania
łączności
Dostęp do aplikacji systemów LSI 2014 możliwy jest za pomocą bezpiecznego
protokołu HTTPS. Użytkownicy uzyskują dostęp do aplikacji poprzez
przeglądarkę internetową, łącząc się przy wykorzystaniu protokołu HTTPS do
serwerów warstwy prezentacji – protokół TLS szyfruje połączenie pomiędzy
przeglądarką użytkownika a serwerem aplikacyjnym.
Zgodnie z uzyskanymi informacjami, w UM nie jest wykorzystywana
infrastruktura klucza publicznego (PKI) oraz nie funkcjonuje dokument
polityki stosowania zabezpieczeń kryptograficznych.
Jednocześnie ustalono, że zapisy w IZSI dotyczące zabezpieczeń
kryptograficznych są zbyt ogólne i nie wskazują zalecanych algorytmów,
długości kluczy szyfrujących oraz sposobów zarządzania nimi.
Rekomendacja 7
8.1.2.
Mechanizmy i metody kryptograficzne.
Zarządzanie kluczami
W UM nie została wdrożona infrastruktura klucza publicznego (PKI),
w związku z czym nie funkcjonują szczegółowe dokumenty w tym zakresie.
Zarządzanie kluczami kryptograficznymi realizowane jest przez serwis, który
odpowiada za szyfrowanie dysków wewnętrznych komputerów przenośnych.
Należy nadmienić, że UM korzysta z usług kwalifikowanego Centrum
Certyfikacji jakim jest Unizeto Technologies S.A., którego obowiązki i zasady
Strona 27 z 71
funkcjonowania określa Regulamin Kwalifikowanych Usług Certyfikacyjnych
CERTUM PCC oraz Polityka Certyfikacji. Dokumenty dostępne są pod
adresem www.certum.pl.
9.
BEZPIECZEŃSTWO FIZYCZNE I ŚRODOWISKOWE
9.1.
Obszary bezpieczne
9.1.1.
Fizyczna granica obszaru bezpiecznego
System utrzymywany jest w serwerowni znajdującej się w budynku przy
ul. Dąbrowskiego 23 w Katowicach, która jest współdzielona ze Śląskim
Centrum Społeczeństwa Informacyjnego. Dostęp do serwerowni odbywa się
z holu głównego – zejście schodami do korytarza prowadzącego do
serwerowni. W lokalizacji nie wydzielono strefy bezpieczeństwa w obszarze
dostępu do serwerowni. Każdy kto znajduje się w strefie biurowej ma
swobodny dostęp do pomieszczeń w budynku. Przy portierni funkcjonuje
punkt dyżurny służby ochrony budynku realizujący monitoring wizyjny,
który monitoruje (kamery CCTV) ciągi komunikacyjne, w tym korytarz
prowadzący do serwerowni. Punkt prowadzi książkę wejść i wyjść do
serwerowni. Wydawanie kluczy odbywa się po weryfikacji na podstawie list
dostępowych.
9.1.2.
Fizyczne zabezpieczenie wejścia
Dostęp pracowników do serwerowni realizowany jest:

poprzez pobranie kluczy do serwerowni w punkcie służby ochrony,
poprzedzone weryfikacją tożsamości osoby pobierającej klucz. Osoba
ta wpisuje się do książki wejść, a zdając klucz wypisuje się.
Dodatkowo pomieszczenie serwerowni objęte jest Systemem Kontroli
Dostępu. Pracownicy wchodząc do serwerowni posługują się indywidualnymi
kartami dostępowymi, przy czym funkcjonuje pewna liczba kart przypisanych
do kont generycznych (anonimowych), np. „OCHRONA OCHRONA”,
„OCHRONA NOWA”. W trakcie przeprowadzonych czynności
sprawdzających uzyskano informację z systemu SKD o wejściach/wyjściach
do/z pomieszczenia serwerowni.
Ustalono, że dziennik wejść/wyjść do serwerownia oraz imienne karty dla
pracowników, zapewniają rozliczalność dostępu do serwerowni systemu
LSI 2014.
9.1.3.
Zabezpieczenie biur, pomieszczeń i obiektów
Strona 28 z 71
Zasady bezpieczeństwa fizycznego zostały określone w IU (pkt 16) zgodnie,
z którymi:

dostęp do pomieszczeń o standardowym poziomie ochrony jest
ograniczony jedynie dla upoważnionych pracowników zgodnie
z przyjętą procedurą (pkt 16.1 IU);

klucze do pomieszczeń pobierane/zdawane są u wyznaczonych osób
(np. pracownik ochrony);

pracownik może posiadać imienną kartę magnetyczną dostępu do
służbowego pomieszczenia wydaną na czas pracy w Urzędzie i pobraną
za pisemnym potwierdzeniem odbioru;

w czasie godzin pracy pomieszczenia nadzorowane są przez
pracowników upoważnionych do samodzielnego dostępu do
pomieszczenia;

każde pomieszczenie na czas każdej nieobecności pracownika należy
zamykać na klucz (lub elektro-zamek).
Dodatkowo określono, że osoby postronne, lub nieposiadające upoważnienia
do dostępu do danego pomieszczenia, mogą przebywać w pomieszczeniu
wyłącznie w obecności pracownika posiadającego stosowne upoważnienie.
Określono również ogólne wymogi bezpieczeństwa pracy w obszarze
przetwarzania danych osobowych (pkt 4 PBDO). Obszar przetwarzania
danych zabezpiecza się przed dostępem osób nieuprawnionych na czas
nieobecności w nim osób upoważnionych do przetwarzania danych
osobowych.
W pomieszczeniach serwerowni oraz technicznych znajdują się urządzenia
dostępowe (np. switch, router), zabezpieczające (np. firewall) oraz zbiór
wszystkich sieciowych systemów informatycznych.
Zbiór wymagań w zakresie zabezpieczenia fizycznego obszaru przetwarzania
określa IZSI. W pkt. 20 niniejszego dokumentu określone zostały
zabezpieczenia fizyczne, w tym stosowane zabezpieczenia dla pomieszczenia
serwerowni:
a) wejście zabezpieczone zamkiem spełniającym normy w zakresie trwałości
oraz bezpieczeństwa (odpowiednia klasa odporności na włamanie) lub
zamkiem magnetycznym;
b) odbywa się całodobowy monitoring wejścia oraz wewnątrz serwerowni;
c) system ppoż, wraz z systemem gaszenia gazem;
d) czujnik zalania;
e) system kontroli dostępu;
f) książka wejść i wyjść.
Serwerownia jest pomieszczeniem współdzielonym ze Śląskim Centrum
Społeczeństwa Informacyjnego, które jest jednostką budżetową
Województwa Śląskiego. Zasady współużytkowania serwerowni określa
zawarte Porozumienie nr 33/AI/2016 z dnia 1 czerwca 2016 roku.
Strona 29 z 71
Serwerownia systemu LSI 2014 monitorowana jest poprzez systemy CCTV.
Pierwszy z nich – podgląd z kamer w punkcie dyżurnym służby ochrony
monitoruje ciągi komunikacyjne, drugi system (kamera) monitoruje
czynności wykonywane w serwerowni. Obraz z kamery CCTV znajdującej
się w serwerowni nie jest rejestrowany, daje wyłącznie podgląd na to co
dzieje się w pomieszczeniu. Dostęp do serwerowni systemu LSI 2014
posiadają pracownicy ochrony budynku z punktu dyżurnego służby ochrony
znajdującego się przy portierni - punkt rejestracji wejść/wyjść do/z
serwerowni. Dostęp do serwerowni systemu LSI 2014, uprawnionych
pracowników ochrony, odbywa się zgodnie z „Procedurą awaryjnego
wejścia do serwerowni”.
Ustalono, że obraz z kamery CCTV znajdującej się w serwerowni nie jest
rejestrowany, daje wyłącznie podgląd na to co dzieje się w pomieszczeniu.
Rekomendacja 8
Rejestrator CCTV.
9.2. Sprzęt
9.2.1.
Lokalizacja i ochrona sprzętu
Sprzęt wchodzący w skład systemu LSI 2014 znajduje się w serwerowni
zlokalizowanej na poziomie -1 budynku przy ulicy Dąbrowskiego 23.
W serwerowni znajduje się kamera systemu telewizji przemysłowej CCTV
administratora budynku – Śląskiego Zarządu Nieruchomości, zaś na zewnątrz
system CCTV ogólny dla całego budynku. Serwerownia posiada system
kontroli dostępu oparty o karty dostępowe. Drzwi do serwerowni
charakteryzują się podwyższoną wytrzymałością na włamanie – drzwi
klasy C3. UPS znajduje się również na tej samej kondygnacji, w oddzielnym
pomieszczeniu. Dostęp do pomieszczenia z UPS-em możliwy jest z tego
samego korytarza co do serwerowni. Bezpieczeństwo zasilania zapewnia
samoczynne załączanie rezerwy, które umożliwia automatyczne przełączenie
źródła zasilania z podstawowego na rezerwowe.
Centralny system backupowy UM oraz środowisko do odtwarzania systemów
z kopii bezpieczeństwa zlokalizowane jest w budynku przy ulicy Ligonia 46,
przy czym macierz dyskowa znajduje się w pomieszczeniu 172 na kondygnacji
pierwszej budynku, a biblioteka taśmowa LTO6 w pomieszczeniu 374 na
kondygnacji trzeciej budynku. Oba pomieszczenia
posiadają okno
wychodzące na wewnętrzny zadaszony dziedziniec. Szyby okna pomieszczenia
374 oklejone są folią refleksyjną. Drzwi do obu pomieszczeń to standardowe
drzwi biurowe oznaczone jako pomieszczenia techniczne. Dostęp do tego
pomieszczenia odbywa się z korytarza ogólnie dostępnego dla interesantów
UM.
Ustalono, że drzwi do pomieszczeń systemu backupowego to standardowe
drzwi biurowe nie spełniające wymagań w zakresie wytrzymałości na
włamanie oraz odporności pożarowej.
Strona 30 z 71
Rekomendacja 9
9.2.2.
Drzwi centralnego systemu backupu.
Systemy wspomagające
Serwerownia i pomieszczenia systemu backupowego (pomieszczenie
techniczne 172 i 374) zostały wyposażone w systemy wspomagające.
Zainstalowano w nich klimatyzację, na którą składają się co najmniej dwie
jednostki, w taki sposób, że w serwerowni głównej pracują cztery jednostki
w sposób ciągły, a w pomieszczeniach systemu backupowego jedna jednostka
w sposób ciągły, a druga pozostaje w zapasie. W pomieszczeniach
zamontowany jest system wczesnego ostrzegania o pożarze. W serwerowni jest
to centrala automatycznego gaszenia IGNIS 1520M, która odpowiada za
wykrywanie pożaru i uruchamiania stałych urządzeń gaśniczych, a
w pomieszczeniach 172 i 374 są to czujki ppoż. W serwerowni zamontowany
jest system gaszenia gazem HFC227. Serwerownia posiada zdywersyfikowane
łącze zasilania, a w przypadku utraty zasilania system UPS. Systemy te są
podawane okresowym przeglądom. Uzyskane dowody audytowe potwierdzają
realizację przeglądów w poniższym zakresie:

UPS – ostatni przegląd serwisowy 2 kwietnia 2015 r.;

system gaszenia gazem, w tym przegląd centrali alarmowej IGNIS –
ostatni przegląd 7 grudnia 2015 r.;

klimatyzacja – ostatni przegląd 2 grudnia 2015 r.;

ppoż, systemów alarmowych, SKD, CCTV – ostatni przegląd dnia
27 października 2015 r.
9.2.3.
Bezpieczeństwo okablowania
System LSI 2014 pracuje w dedykowanym pomieszczeniu. W serwerowni
zainstalowana została podniesiona podłoga. Okablowanie strukturalne
poprowadzone zostało w podłodze, w sposób ograniczający przypadkowe
uszkodzenie. Wykorzystywane jest okablowanie światłowodowe dla szkieletu
sieci oraz miedziane do podłączenia komputerów pracowników. W korytarzach
okablowanie sieci LAN prowadzone jest w zamykanych rynnach PCV
prowadzonych w sposób uniemożliwiający bezpośredni dostęp do nich.
9.2.4.
Konserwacja sprzętu
Zasady konserwacji sprzętu określono w IZSI (pkt 13). Określono m.in., że:

Za okresową konserwację sprzętu odpowiada Wydział ds. informatyki,
pod nadzorem GASI;

Sprzęt jest konserwowany zgodnie z zaleceniami producenta/dostawcy
(zakres, częstotliwość), wyłącznie przez uprawniony personel;
Strona 31 z 71

W przypadku przekazania sprzętu poza obszar przetwarzania danych,
usuwane są z niego nośniki zawierające dane;

Za bieżące utrzymanie sprzętu (niewymagające ingerencji we wnętrze
urządzenia) odpowiada użytkownik sprzętu zgodnie z Instrukcją
Użytkownika;

W przypadku konieczności przekazania sprzętu do naprawy należy
uwzględnić wytyczne dotyczące sposobu postępowania z nośnikami
zawierającymi dane;

Zgłoszenie awarii sprzętu realizowane są za pomocą narzędzia:
http://helpdesk.slaskie.pl/;

Nośniki na gwarancji zawierające dane nie podlegają serwisowaniu
poza siedzibą Urzędu;

Podpisane umowy serwisowe muszą zawierać odpowiednie zapisy
zapewniające ochronę danych.
Wydział Informatyki i Administracji odpowiada za prowadzenie umów
serwisowych oraz zapewnienie ciągłości utrzymania serwisu urządzeń
i sprzętu w zakresie swojej właściwości.
9.2.5. Wynoszenie aktywów
Użytkownicy systemu informatycznego UM pracują na komputerach
stacjonarnych. Z komputerów przenośnych korzystają administratorzy
techniczni. W Instrukcji Użytkownika (IU) określono zasady wynoszenia
aktywów poza obszar przetwarzania danych (pkt 4.2), w tym określono
procedurę uzyskania zezwolenia na wyniesienia sprzętu.
Z uwagi na zakres obowiązków Zarząd Województwa, Sekretarz
Województwa – Dyrektor Urzędu, kierownicy komórek organizacyjnych
(Dyrektorzy Wydziałów i ich zastępcy) mogą wynosić, poza obszar
przetwarzania danych, przydzielony przenośny sprzęt komputerowy.
Wynoszenie informacji (np. akt spraw, danych elektronicznych) poza obszar
przetwarzania dopuszczalne jest wyjątkowo w uzasadnionych przypadkach
oraz wyłącznie za wiedzą i zgodą przełożonego. Odpowiedzialność za
wyniesione informacje ponosi pracownik oraz przełożony.
Przenoszenie dokumentów pomiędzy budynkami zajmowanymi przez Urząd
odbywa się za wiedzą bezpośredniego przełożonego zgodnie z zasadami
określonymi w pkt. 12 IU.
Zgodę na wyniesienie sprzętu uzyskuje się od kierownika komórki
organizacyjnej, w której zatrudniony jest pracownik. Wzór wniosku stanowi
załącznik nr 2 do IU. Oryginały wniosków archiwizuje komórka
merytoryczna użytkownika, a skan zatwierdzonego wniosku przesłany jest
pocztą elektroniczną do GASI.
9.2.6.
Bezpieczeństwo sprzętu i aktywów poza siedzibą
Strona 32 z 71
Aktywa powierzane pracownikowi, takie jak komputery, zapisywane są
w rejestrze i przypisywane użytkownikowi do czasu ich zwrotu. Przydzielony
użytkownikowi
sprzęt
komputerowy
wraz
z
zainstalowanym
oprogramowaniem może być wykorzystywany wyłącznie do celów
służbowych. Użytkownik jest zobowiązany do dbania o ochronę
powierzonego sprzętu komputerowego.
W Instrukcji Zarządzania (pkt 15) określone zostały zasady dotyczące
bezpieczeństwa komputerów przenośnych, a w Instrukcji Użytkownika
określono ogólne zasady korzystania z urządzeń mobilnych. Szczegółowe
zasady przyznawania i korzystania ze służbowych telefonów komórkowych
określa Zarządzenie Marszałka Województwa w sprawie sposobu
gospodarowania
składnikami
majątku
ruchomego
w
Urzędzie
Marszałkowskim Województwa Śląskiego.
9.2.7. Pozostawienie sprzętu bez opieki
Wytyczne w zakresie „pracy w systemie informatycznym”, w tym
zakończenia lub zawieszenia pracy zawarte zostały w Instrukcji Użytkownika.
Zgodnie z treścią instrukcji – pkt 5.5 „Zawieszenie pracy” określono, że:
„Użytkownik przerywający pracę na stacji roboczej obowiązany jest
aktywować wygaszacz ekranu lub w inny sposób zablokować dostęp do stacji
roboczej. Skrót klawiszowy służący do szybkiego blokowania stacji roboczej
to windows (pomiędzy klawiszami CTRL i ALT) + L.
W przypadku dłuższej nieobecności należy zakończyć otwarte sesje poprzez
wylogowanie się a pomieszczenie zamknąć.
Ekran komputera powinien być wyposażony we włączający się po 5 minutach
od przerwania pracy wygaszacz ekranu. Wznowienie pracy (wyświetlania)
następuje dopiero po podaniu odpowiedniego hasła.”
Strona 33 z 71
10.
BEZPIECZNA EKSPLOATACJA
10.1. Procedury eksploatacyjne i odpowiedzialność
10.1.1.
Dokumentowanie procedur eksploatacyjnych
Instrukcje użytkowe dla wnioskodawców/beneficjentów publikowane są na
stronie informacyjnej Lokalnego Systemu Informatycznego 2014
(http://rpo.slaskie.pl/czytaj/lokalny_system_informatyczny_2014/). Link do tej
strony informacyjnej znajduje się również na stronie systemu LSI 2014
(https://lsi.slaskie.pl/). Dostępne informacje to m.in.:

Filmy instruktażowe;

Wymagania techniczne i konfiguracyjne;

Instrukcja składania wniosków;

Instrukcja użytkownika Lokalnego Systemu Informatycznego 2014 dla
Wnioskodawców/Beneficjentów RPO WSL 2014-2020;

Instrukcja składania wniosków, korespondencji i protestów w ramach
naborów dotyczących projektów finansowanych ze środków
Regionalnego Programu Operacyjnego Województwa Śląskiego 20142020;

Instrukcja zmiany załączników we wniosku o dofinansowanie
zwróconym do poprawy;

Regulaminy.
Urząd publikuje i uaktualnia opisy procedur funkcjonujących w UM w BIP
oraz katalogu usług SEKAP.
W ramach weryfikacji wymogu kontrolnego „czy istnieją odpowiednie
procedury w celu zapewnienia bezpieczeństwa i utrzymania systemu
komputerowego, integralności i poufności danych, uwierzytelniania nadawcy,
i przechowywania dokumentów i danych” zweryfikowano procedury
administrowania systemem teleinformatycznym LSI 2014, a w obszarze
„ochrony osób fizycznych w zakresie przetwarzania danych osobowych”
potwierdzono realizację zasad określonych przepisami uodo oraz zasad
wynikających z Polityki Bezpieczeństwa Danych Osobowych (PBDO)
oraz Instrukcji Zarządzania Systemem Informatycznym w UM WSL.
Dokumentacja bezpieczeństwa danych osobowych została przedstawiona
w pkt. 4.1.1.
Administratorzy techniczni dysponują procedurami w zakresie tworzenia
i odtwarzania kopii zapasowych (systemów operacyjnych, baz danych), jak
również dokumentem o nazwie „Dokumentacja techniczna LSI 2014”, który
stanowi opis składowych funkcjonalnych systemu oraz określa kroki instalacji
i konfiguracji systemu LSI.
Strona 34 z 71
10.1.2.
Zarządzanie zmianami
Zarządzanie zmianami w ramach umowy z firmą ART4NET odbywało się
w ramach wymagań wynikających z umowy na realizację „usługi: wytworzenia,
uruchomienia, asysty technicznej i utrzymania Lokalnego Systemu
Informatycznego dla Regionalnego Programu Operacyjnego Województwa
Śląskiego na lata 2014-2020”. Obecnie system jest utrzymywany przez firmę
Alterout IT Sp. z o. o. z siedzibą w Gdańsku na mocy umowy z dnia 4 maja
2016 roku. Zakresem tej umowy jest asysta techniczna i utrzymanie LSI 2014,
w tym: wykonywanie prac związanych z bieżącym utrzymaniem systemu,
modyfikacjami istniejących elementów/modułów oraz tworzeniem nowych
elementów systemu, w tym naprawy błędów. Ponadto Wykonawca zobowiązany
jest do prowadzenia szkoleń dla administratorów i kluczowych użytkowników
systemu dla nowych modułów i funkcjonalności. Wymagania w zakresie
realizacji zmian, w szczególności czasów naprawy awarii i usterek zostały
określone w załączniku nr 1 do ww. umowy.
UM obecnie jednak nie dysponuje formalną procedurą zarządzania zmianami.
Rekomendacja 10
10.1.3.
Procedura zarządzania zmianami.
Oddzielenie środowisk rozwojowych, testowych i produkcyjnych
Urząd Marszałkowski Województwa Śląskiego utrzymuje dwa wirtualne
serwery, na których pracuje system LSI 2014 (aplikacja i baza danych pracuje na
jednym serwerze). System w wersji produkcyjnej i w wersji szkoleniowej
pracują na jednym systemie operacyjnym, z kolei system w wersji
developerskiej oraz w wersji testowej pracują na drugim systemie operacyjnym.
Wszystkie wersje systemu dostępne są w Internecie, przy czym do wersji
developerskiej dostęp ograniczony jest wyłącznie z wybranych adresów IP.
Zasadę rozdzielenia systemów produkcyjnych od testowych określa, w pkt. 16.2.
Instrukcja Zarządzania Systemem Informatycznym. Zgodnie z wymaganiami
ASI odpowiada aby:
a) oprogramowanie do opracowywania i testowania było oddzielone od siebie;
b) procesy testowania i wytwarzania aplikacji były rozdzielone;
c) stosowane były różne od siebie hasła do systemów produkcyjnych
i deweloperskich.
Strona 35 z 71
10.2. Ochrona przed szkodliwym oprogramowaniem
10.2.1.
Zabezpieczenie przed szkodliwym oprogramowaniem
IZSI określa w pkt. 9 stosowane w UM WSL zabezpieczenia systemu przed
szkodliwym oprogramowaniem. Określono m.in. wymagania:
„Ruch w sieci komputerowej, zabezpieczony za pomocą urządzeń UTM oraz
translacji adresów NAT. Ruch sieciowy jest monitorowany w celu kontroli
przepływu danych między siecią publiczną, a siecią wewnętrzną.
Poczta elektroniczna jest zabezpieczona przed przesyłaniem SPAM oraz
oprogramowania złośliwego za pomocą dedykowanego rozwiązania typu
SPAM- firewall.
Na wszystkich stacjach roboczych oraz serwerach zainstalowane jest
oprogramowanie antywirusowe.
Funkcjonowanie oprogramowania antywirusowego
centralnie przez oprogramowanie konsoli zarządzającej.
nadzorowane
jest
Za politykę antywirusową odpowiedzialny jest Wydział ds. Informatyki.
Program antywirusowy i konfiguracja systemu musi zapewniać kontrolę całego
systemu informatycznego:
 na bieżąco,
 przynajmniej raz dziennie, jeżeli z przyczyn technicznych nie możliwe jest
jej zapewnienie na bieżąco,
 każdorazowo przy korzystaniu z nośników wymienialny
 po stwierdzonej pozytywnej infekcji systemu informatycznego.
Po zasygnalizowaniu przez system antywirusowy wystąpienia wirusa
użytkownik systemu powinien natychmiast powiadomić o tym fakcie ASI, który
musi podjąć odpowiednie kroki:
a) zidentyfikować wirus i określić obszar wystąpienia,
b) odseparować część systemu objętą wirusem od całości,
c) przystąpić do usuwania wirusa, zgodnie z wymogami stosowanego
programu antywirusowego,
d) w razie konieczności, należy ponownie wgrać system i dane systemu
z ostatnich aktualnych kopii systemu, przetestować poprawność systemu,
Strona 36 z 71
e) opisać zdarzenie zgodnie z procedurą zgłaszania zdarzeń.
W UM WSL zastosowano oprogramowanie antywirusowe ESET Secure
Enterprise. System składa się z centralnej konsoli oraz aplikacji klienckiej
instalowanej na komputerach użytkowników. Użytkownicy nie mogą zmieniać
ustawień oprogramowania. System aktualizuje sygnatury automatycznie oraz
posiada skonfigurowaną opcję pełnego skanowania raz w tygodniu. Komputery
beneficjentów nie podlegają polityce ochrony przed szkodliwym
oprogramowaniem stosowanej w UM WSL, przy czym zgodnie
z Regulaminem określającym zasady funkcjonowania LSI każdy użytkownik
systemu odpowiada za zapewnienie bezpieczeństwa pracy systemu w zakresie
od niego zależnym, w tym ochrony przed niepowołanym dostępem do danych,
utratą danych, niepowołaną modyfikacją danych.
Serwery LSI 2014 mają zapewnioną ochronę AV na bramie internetowej
w trybie on-line, jak również dodatkową ochronę AV na samych serwerach.
10.3. Kopie zapasowe
Instrukcja Zarządzania Systemem Informatycznym UM WSL określa
w pkt. 10:

zasady wykonywania i przechowywania kopii zapasowych;

zasady oznaczania taśm magnetycznych;

procedurę testowego odtwarzania kopii bezpieczeństwa.
Na centralny system backupowy UM składają się następujące elementy:

serwer z oprogramowaniem IBM Tivoli Storage Manager,

macierz dyskowa IBM DS3400,

biblioteka taśmowa IBM TS3100 LTO6.
Centralny system backupowy zlokalizowany jest w budynku przy
ul. Ligonia 46, w innej lokalizacji niż produkcyjne środowisko przetwarzania
danych.
Sposób wykonywania backupu realizowany jest w modelu D2D2T: „dysk to
dysk to tape”. Dane z systemów serwerowych zapisywane są na macierzy
dyskowej z wykorzystaniem deduplikacji, a następnie na taśmach
magnetycznych w bibliotece taśmowej LTO6. Deduplikacja danych pozwala
na lepsze wykorzystanie przestrzeni dyskowej na macierzy dyskowej,
eliminuje identyczne bloki danych. W trakcie wykonywania czynności
audytowych ustalono, że niewykorzystywane taśmy LTO6 przechowywane są
w sejfie, a biblioteka taśmowa wykorzystuje tylko połowę załadowanych taśm.
Taśmy LTO6 pozostają cały czas w bibliotece taśmowej, nie podlegają
procedurze składowania z zapewnieniem ich ochrony przed uszkodzeniem w
Strona 37 z 71
wyniku np. pożaru – spalenia, oddziaływania wysokiej temperatury, czy
zalania.
Archiwizacja danych wykonywana jest codziennie, po północy, na dyski
macierzy RAID (z deduplikacją), a następnie na taśmy magnetyczne
w bibliotece taśmowej (bez deduplikacji). Backup realizowany jest według
metody ang. progressive incremental backup (backup przyrostowy wieczny).
W pierwszym kroku wykonywany jest pełny backup wzorcowy. W ramach
każdego następnego backup-u przesyłane są wyłącznie różnice. W przypadku
maszyn wirtualnych, przesyłane są zmienione bloki dysków wirtualnych
maszyn bazując na mechanizmie VMware CBT (Change Block Tracking), co
zmniejsza okno backupowe oraz potrzebne pasmo sieci. Zastosowane
rozwiązanie – centralny system backupowy cechuje się wysoką
niezawodnością i odpornością na awarie (wszystkie główne komponenty
sprzętu są zdublowane), przy czym dane z pojedynczej taśmy magnetycznej
można odtworzyć jedynie w systemie, w którym taśma została zapisana.
Odczyt danych poza systemem będzie bezwartościowy.
W ramach przechowywania kopii bezpieczeństwa zasada delokalizacji kopii
zapasowych spełniona jest w taki sposób, że biblioteka taśmowa oraz macierz
dyskowa znajduje się w innej lokalizacji jak system produkcyjny i
jednocześnie są od siebie oddzielone, tzn. biblioteka taśmowa znajduje się w
innym pomieszczeniu od tego, w którym pracuje macierz dyskowa.
Szczegółowy opis dotyczący lokalizacji urządzeń backupowych znajduje się
w pkt. 9.2.1. Lokalizacja i ochrona sprzętu.
10.4. Rejestrowanie zdarzeń i monitorowanie
10.4.1.
Rejestrowanie zdarzeń
Ustalono, że zapisy w IZSI dotyczące logowania zdarzeń w systemach oraz
urządzeniach IT w celu rejestrowania zdarzeń oraz zbierania materiału
dowodowego są niewystarczające. Wymagania w tym obszarze określone w
IZSI zostały opisane w punkcie 19. Dzienniki systemowe.
Ustalono, że dzienniki systemów podlegają archiwizacji w ramach
wykonywanych kopii bezpieczeństwa, a UM nie wykorzystuje oprogramowania
do zbierania i agregacji logów systemowych w celu korelacji zdarzeń.
Rekomendacja 11
Rejestrowanie zdarzeń i monitorowanie.
Strona 38 z 71
10.4.2.
Ochrona informacji w dziennikach zdarzeń
W Instrukcji Zarządzania Systemem Informatycznym UM WSL (pkt 19)
określono, że obligatoryjnie odnotowuje się:
a) dostęp do systemu z uprawnieniami administracyjnymi;
b) dostęp do konfiguracji systemu, w tym konfiguracji zabezpieczeń;
c) dostęp do danych podlegających prawnej ochronie w zakresie wymaganym
przepisami prawa.
Jednocześnie zaleca się aby były odnotowywane, o ile jest to możliwe
technicznie:
a) działania użytkowników nieposiadających uprawnień administracyjnych;
b) zdarzenia systemowe o mniejszym znaczeniu dla funkcjonowania systemu;
c) zdarzenia i parametry środowiska, w którym eksploatowany jest system.
Logi systemowe są archiwizowane przez ASI (kopie zapasowe systemów).
Informacje w dziennikach przechowywane są od dnia ich zapisu przez dwa lata,
lub zgodnie z obowiązującymi dany system szczegółowymi przepisami prawa.
Ustalono, że dzienniki systemów podlegają archiwizacji w ramach
wykonywanych kopii bezpieczeństwa, a UM nie wykorzystuje oprogramowania
do zbierania i agregacji logów systemowych w celu korelacji zdarzeń (patrz:
Rekomendacja 11).
10.4.3.
Rejestrowanie działań administratorów i operatorów
Zgodnie z IZSI UM WSL (pkt 19) ASI odpowiedzialny jest za prowadzenie
dzienników zdarzeń systemu oraz informowanie ABI o nieprawidłowościach
wykrytych w systemie.
Referat Informatyki stosuje systemy dziedzinowe (Firewall, System
AntySPAM-owy, AV, Kontroler Domeny) do monitorowania sieci, urządzeń
oraz stacji komputerowych, na których pracują użytkownicy UM WSL.
Zasady konfiguracji systemów wymagają konfiguracji, która zapewniać będzie
rejestrowanie prób nieautoryzowanego dostępu.
10.4.4.
Synchronizacja zegarów
Potwierdzono synchronizację zegarów systemu LSI 2014 ze źródłem czasu. Do
synchronizacji zegarów wykorzystywany jest protokół NTP (ang. Network Time
Protocol). Dla stacji roboczych źródłem synchronizacji czasu są kontrolery
domeny. Główny kontroler domeny synchronizuje się z publicznym serwerem
NTP NASK – ntp.nask.pl
Strona 39 z 71
10.5. Nadzór nad oprogramowaniem produkcyjnym
10.5.1.
Instalacja oprogramowania w systemach produkcyjnych
Zmiany w systemie LSI 2014 realizowane są przez pracowników firmy Alterout
IT Sp. z o.o. Z kolei sprzęt utrzymywany jest przez pracowników Referatu
Informatyki UM WSL. Za instalację wydań i poprawek do systemu LSI 2014
odpowiada również firma Alterout IT Sp. z o.o.. Za nadzór w zakresie
dokonywanych zmian odpowiadają Administratorzy techniczni systemu
LSI 2014, przy czym sam proces nie jest sformalizowany. Realizacja instalacji
oprogramowania w systemach została podzielona na modyfikacje i wdrożenia
nowych elementów – patrz opis w pkt. 12.2.1 Przegląd techniczny aplikacji po
zmianach w platformie produkcyjnej.
10.6. Zarządzanie podatnościami technicznymi
10.6.1.
Zarządzanie podatnościami technicznymi
W UM funkcjonuje wdrożony mechanizm aktualizacji produktów firmy
Microsoft w oparciu o narzędzie WSUS, które pełni funkcję serwera aktualizacji
między innymi dla stacji roboczych. Nie potwierdzono funkcjonowania
formalnych zasad zarządzania podatnościami technicznym, w tym zasad
wprowadzania zmian wynikających z instalacji poprawek do systemów,
urządzeń. ASI nie są zobowiązani do uzyskiwania aktualnych informacji
o technicznych podatnościach dotyczących wykorzystywanych przez UM
systemów operacyjnych, baz danych, narzędziowych i aplikacyjnych oraz
szacowania stopnia narażenia tych systemów na podatności, a zaobserwowana
podatność mająca wpływ na system teleinformatyczny UM nie podlega
zgłoszeniu i ocenie.
Rekomendacja 12
Zarządzanie podatnościami technicznymi.
Strona 40 z 71
11.
BEZPIECZEŃSTWO KOMUNIKACJI
11.1. Zarządzanie bezpieczeństwem sieci
11.1.1.
Zabezpieczenia sieci
Zgodnie z IZSI Urzędu Marszałkowskiego Województwa Śląskiego w pkt. 6
określono zasady kontroli dostępu do sieci i korzystania z usług sieciowych a
w IU w pkt. 13 określono zasady korzystania przez użytkowników z dostępu
do sieci, w tym sieci Internet
Sieci lokalne UM są zarządzane i nadzorowane przez Wydział Informatyki
i Administracji. Aby ochronić je przed zagrożeniami pochodzącymi z sieci
publicznej kontroluje się ruch sieciowy poprzez urządzenia typu Firewall
realizujący funkcje IPS i AV. Pracę wydziału nadzoruje GASI. Przesyłanie
danych pomiędzy lokalizacjami UM, przez sieć publiczną, odbywa się
bezpiecznymi kanałami szyfrowanymi w technologii VPN. Otwieranie stron
WWW przez użytkowników jest monitorowane.
Dostęp do Internetu odbywa się przez system bezpieczeństwa Firewall
realizowany przez oprogramowanie PaloAlto – ochrona w zakresie URL
Filtering oraz Threat Prevention (IPS z funkcją AV oraz ochroną przed atakami
typu DDOS). Ochrona antySPAM-owa realizowana jest poprzez Barracuda
Spam Firewall – funkcja antySPAM i AV Firewall. Systemy bezpieczeństwa
posiadają wymagane wsparcie serwisowe i gwarancyjne.
11.1.2.
Rozdzielenie sieci
W UM WSL:

sieci lokalne są rozdzielone na segmenty;

dostęp do sieci jest kontrolowany przez systemy zaporowe, które
realizują zarówno kontrolę routingu, jak też kontrolę stanu połączeń
oraz zestawiają tunele VPN;

w dostępie użytkowników do Internetu pośredniczy system
bezpieczeństwa Firewall, który blokuje dostęp do stron lub aplikacji
uznanych za niebezpieczne lub zawierających niedozwolone treści;

przesyłanie poczty elektronicznej odbywa
pośredniczące, przypisane do strefy DMZ.
się
przez
bramki
W UM WSL stosuje się segregację sieci. System domenowy nadzorują
Administratorzy Domeny – pracownicy zespołu usług sieciowych. System
LSI 2014 pracuje w dedykowanej podsieci. Dostęp do podsieci kontrolowany
jest poprzez listy kontroli dostępu na firewall-u, które filtrują ruch do serwerów
aplikacyjnych znajdującymi się w strefie ograniczonego zaufania.
Strona 41 z 71
12.
POZYSKIWANIE, ROZWÓJ I UTRZYMANIE SYSTEMÓW
12.1. Wymagania związane z bezpieczeństwem systemów informacyjnych
12.1.1.
Analiza i specyfikacja wymagań związanych z bezpieczeństwem
informacji
System informatyczny LSI 2014 został stworzony na potrzeby obsługi
funduszy europejskich w perspektywie finansowej 2014-2020. System wpierać
będzie fundusze wydatkowane w ramach Regionalnego Programu
Operacyjnego Województwa Śląskiego. W ramach RPO WSL 2014-2020
funkcjonuje dwanaście merytorycznych osi priorytetowych (finansowanych z
EFRR i EFS) oraz jedna oś dedykowana działaniom w zakresie pomocy
technicznej (finansowana w całości z EFS).
Oś Priorytetowa I Nowoczesna gospodarka
1.1 Kluczowa dla regionu infrastruktura badawcza;
1.2 Badania Rozwój i innowacje w przedsiębiorstwach;
1.3 Profesjonalizacja IOB.
Oś Priorytetowa II Cyfrowe śląskie
2.1 Wsparcie rozwoju cyfrowych usług publicznych;
Oś Priorytetowa III Konkurencyjność MŚP
3.1 Poprawa warunków do rozwoju MŚP;
3.2 Innowacje w MŚP;
3.3 Technologie informacyjno-komunikacyjne w działalności gospodarczej;
3.4 Dokapitalizowanie
Przedsiębiorczości.
zewnętrznych
źródeł
dofinansowania
Oś Priorytetowa IV Efektywność energetyczna, odnawialne źródła energii
i gospodarka niskoemisyjna
4.1 Odnawialne źródła energii;
4.2 Efektywność energetyczna i odnawialne źródła energii w mikro, małych
i średnich przedsiębiorstwach;
Strona 42 z 71
4.3 Efektywność energetyczna i odnawialne źródła energii w infrastrukturze
publicznej i mieszkaniowej;
4.4 Wysokosprawna Kogeneracja.
4.5 Niskoemisyjny transport miejski oraz efektywne oświetlenie.
Oś Priorytetowa V Ochrona środowiska i efektywne wykorzystanie zasobów
5.1 Gospodarka wodno-ściekowa;
5.2 Gospodarka odpadami;
5.3 Dziedzictwo kulturowe;
5.4 Ochrona różnorodności biologicznej;
5.5 Wzmocnienie potencjału służb ratowniczych.
Oś Priorytetowa VI Transport
6.1 Drogi wojewódzkie;
6.2 Transport kolejowy.
Oś Priorytetowa VII Regionalny rynek pracy
7.1 Aktywne formy przeciwdziałania bezrobociu;
7.2 Poprawa zdolności do zatrudnienia osób poszukujących pracy
i pozostających bez zatrudnienia;
7.3 Wsparcie dla osób zamierzających rozpocząć prowadzenie działalności
gospodarczej;
7.4 Wspomaganie procesów adaptacyjnych i modernizacyjnych w regionie
(działania z zakresu outplacementu);
7.5 Wsparcie osób zamierzających rozpocząć prowadzenie działalności
gospodarczej poprzez instrumenty finansowe.
Oś Priorytetowa VIII Regionalne kadry gospodarki opartej na wiedzy
8.1 Wspieranie rozwoju warunków do godzenia życia zawodowego
i prywatnego;
8.2 Wzmacnianie
potencjału
przedsiębiorców i ich pracowników;
adaptacyjnego
przedsiębiorstw,
8.3 Poprawa dostępu do profilaktyki, diagnostyki i rehabilitacji leczniczej
ułatwiającej pozostanie w zatrudnieniu i powrót do pracy.
Oś Priorytetowa IX Włączenie społeczne
Strona 43 z 71
9.1 Aktywna integracja;
9.2 Dostępne i efektywne usługi społeczne i zdrowotne;
9.3 Rozwój ekonomii społecznej w regionie.
Oś Priorytetowa X Rewitalizacja oraz infrastruktura społeczna i zdrowotna
10.1 Infrastruktura ochrony zdrowia;
10.2 Rozwój mieszkalnictwa socjalnego, wspomaganego i chronionego oraz
infrastruktury usług społecznych;
10.3 Rewitalizacja obszarów zdegradowanych;
10.4 Poprawa stanu środowiska miejskiego.
Oś Priorytetowa XI Wzmocnienie potencjału edukacyjnego
11.1 Ograniczenie przedwczesnego kończenia nauki szkolnej oraz
zapewnienie równego dostępu do dobrej jakości edukacji elementarnej,
kształcenia podstawowego i średniego;
11.2 Dostosowanie oferty kształcenia zawodowego do potrzeb lokalnego
rynku pracy – kształcenie zawodowe uczniów;
11.3 Dostosowanie oferty kształcenia zawodowego do potrzeb lokalnego
rynku pracy – kształcenie zawodowe osób dorosłych;
11.4 Podnoszenie kwalifikacji zawodowych osób dorosłych.
Oś Priorytetowa XII Infrastruktura edukacyjna
12.1 Infrastruktura wychowania przedszkolnego;
12.2 Infrastruktura kształcenia zawodowego;
12.3 Instytucje popularyzujące naukę.
Oś Priorytetowa XIII Pomoc techniczna
13.1 Pomoc Techniczna.
Koncepcja budowy i odzwierciedlenia procesów biznesowych w systemie
bazuje na doświadczeniach zdobytych w poprzedniej perspektywie finansowej.
System zrealizowany został w oparciu o umowę z wykonawcą zewnętrznym
firmą ART4NET. Zadaniem LSI 2014 jest obsługa całego cyklu życia projektu
od momentu złożenia wniosku o dofinansowanie przez beneficjenta, aż do
zakończenia jego rzeczowej i finansowej realizacji oraz ostatecznego
rozliczenia wraz z elementami sprawozdawczości i kontroli projektów, zgodnie
z obowiązującymi procedurami.
Strona 44 z 71
W ramach testów aplikacji zbadany został zakres pól wynikający
z rozporządzenia 480/2014. Wykaz danych zapisywanych i przechowywanych
w LSI 2014 przedstawiony został w załączniku do Sprawozdania. W systemie
LSI 2014 nie są gromadzone wszystkie wymienione dane. Wynika to między
innymi z:

charakterystyki programu operacyjnego;

braku pełnej funkcjonalności systemu (brak wniosków o płatność) –
osiągnięcie funkcjonalności planowane było na koniec marca 2016 ,
przy czym obsługa wniosków o płatność wprowadzona została do
aplikacji na początku czerwca 2016 roku;

współdziałania z Centralnym Systemem Teleinformatycznym
(SL 2014) – cześć danych znajdować się będzie w centralnym systemie
SL 2014;

zapewnienia komunikacji z wykorzystaniem SEKAP lub ePUAP.
System LSI 2014 stanowi odpowiedni system zapewniający zbieranie,
rejestrowanie i przechowywanie danych w formie elektrycznej dla projektów
realizowanych w ramach RPO WSL, przy czym pełna funkcjonalność
wymagana przepisami UE realizowana jest z udziałem systemu SL 2014.
Ustalono, że:

system umożliwia beneficjentowi śledzenie realizacji projektu on-line
poprzez dostęp do listy projektów, na której m.in. widoczne są statusy
elementów projektu oraz otrzymują informacje poprzez e-mail'e
o istotnych zdarzeniach związanych z projektem;

system umożliwia raportowanie na podstawie uprzednio określonych
kryteriów danych z załącznika III rozporządzenia 480/2014;

system zapewnia wymianę danych pomiędzy IZ, IP oraz beneficjentami
w ten sposób, że system jest współużytkowany przez IZ, IP
i beneficjentów w odpowiednim dla nich zakresie. Ponadto do
komunikacji wykorzystywane są także systemy SEKAP oraz ePUAP,
które
zapewniają
mechanizm
autentyczności
i integralności
przekazywanych danych;

system zapewnia komunikację z SL2014 poprzez WSDL oraz moduł
importu;

system
zapewnia
integrację
ze
stronami
internetowymi:
http://rpo.slaskie.pl/lsi/nabory/ , http://www.scp-slask.pl/lsi/nabory/ ;

dokumentację techniczną pełni dokumentacja systemu LSI 2014 oraz
dokumentacja SEKAP;

zastosowano mechanizmy kontrolne w zakresie obliczania sumy
kontrolnej pola NIP w trakcie tworzenia profilu beneficjenta (walidacja
danych identyfikacyjnych beneficjenta);

zastosowano mechanizmy kontrolne w zakresie obliczania sumy
kontrolnej plików wniosków (wniosek oraz załączniki);
Strona 45 z 71

zapewniono komunikację z systemem REGON (Bazą Internetową
Regon);

pola finansowe przyjmują tylko cyfry bez możliwości wprowadzenia
innych znaków klawiatury i wartości ujemnych;

czynności możliwe do wykonania w systemie (dostępne przyciski)
zależą od grupy uprawnień, do której został przypisany pracownik.
Wnioski o dofinansowanie w ramach RPO Województwa Śląskiego na lata
2014-2020 mogą być składane wyłącznie w formie dokumentu elektronicznego
za pośrednictwem SEKAP lub ePUAP. Przesyłki z wnioskami muszą zostać
podpisane elektronicznie przy pomocy jednego z trzech sposobów: podpisu
złożonego
przy
pomocy
klucza
weryfikowanego
certyfikatem
kwalifikowanym, podpisu złożonego przy pomocy klucza weryfikowanego
certyfikatem CC SEKAP, podpisu złożonego przy użyciu Profilu Zaufanego
ePUAP.
System zbudowany jest w technologii cienkiego klienta. Dostępny jest pod
adresem https://lsi.slaskie.pl/
LSI 2014 oparty jest na architekturze warstwowej:
1. Warstwa kliencka (kod generowany dla przeglądarki internetowej, tworzący
interfejs za pomocą którego wprowadzane są dane i wykonywane operacje na
istniejących danych);
2. Warstwa aplikacji (kod zarządzający systemem, wykonujący działania
zgodnie z określoną logiką biznesową, pośredniczący pomiędzy warstwą
kliencką a bazą danych);
3. Warstwa bazy danych (przechowująca wprowadzone dane w określonej
strukturze).
Aplikacja dostępna jest zarówno dla pracowników instytucji, jak również dla
beneficjentów. W aplikacji rejestrowane są modyfikacje dokumentów oraz
zmiany ich statusu. Wyświetlane są informacje o dacie modyfikacji oraz
użytkowniku dokonującym zmiany.
12.1.2.
Ochrona transakcji usług aplikacyjnych
Wszelkie czynności na danych są logowane tak, aby tworzyła się historia
zmian danych od momentu ich utworzenia. System zaprojektowany został w
sposób zapewniający, że wszystkie zbierane w nim dane są wprowadzane
przez osoby, które zostały zidentyfikowane. Autoryzacja przez login i hasło
dotyczy zarówno pracowników Instytucji Zarządzającej, jak też beneficjentów.
Komunikacja z systemem jest szyfrowana poprzez Hypertext Transfer Protocol
Secure. Certfikat SSL wydany został przez centrum Unizeto Technologies S.A.
12.2. Bezpieczeństwo w procesach rozwoju i wsparcia
Strona 46 z 71
12.2.1.
Przegląd techniczny aplikacji po zmianach w platformie produkcyjnej
Zmiany w aplikacji na platformie produkcyjnej poprzedzone są testami.
Zmiany są podzielone na dwa rodzaje: modyfikacje i wdrożenia nowych
elementów. W ramach bieżących modyfikacją istniejących modułów
i elementów systemu termin realizacji zmiany jest każdorazowo uzgadniany.
Po zgłoszeniu przez wykonawcę danego elementu do testów UM WSL w ciągu
18 dni roboczych zgłasza wykonawcy wykryte błędy lub nie wnosi uwag.
W przypadku zgłoszenia błędów wykonawca jest zobligowany do ich naprawy
w ciągu 12 dni roboczych i ponownego przekazania elementu do testów.
Zamawiający w terminie 12 dni roboczych przeprowadza ponownie testy.
W przypadku powtórnego wykrycia błędów UM WSL ma prawo do naliczenia
kary umownej.
Dla przykładu przeprowadzane zmiany obejmują:

usuwanie/zmianę/dodawanie elementów interfejsu/formularzy aplikacji
np. nowych pól, przekształcenie pola tekstowego na słownikowe, formy
opisowej na tabelaryczną itp.;

bieżącą zmianę wzorów formularzy (wniosków o dofinansowanie, o
płatność, pefs) oraz harmonogramów. Nowe wzory stanowią kolejne
wersje możliwe pod podpięcie do naborów (w przypadku WND i
WNP);

dodawanie lub modyfikację: widoków prezentowanych danych, zakresu
gromadzonych danych, formuł liczących, warunków dostępu i walidacji
danych;

zmianę/dodawanie funkcjonalności do istniejących modułów, np.
nowych statusów, walidacji, filtrów, automatyzacji pól, uprawnień;

zmianę struktury bazy danych;

zmianę sposobu i zakresu prezentacji zgromadzonych danych
(przykładowo: dodawanie podsumowań, możliwość wyświetlania
zakresu modyfikacji formularza w odniesieniu do poprzednich wersji
formularzy);

poprawę ergonomii użytkowania wskazanych elementów interfejsu;

dostosowywanie systemu do zmieniających się:
 przepisów prawa (ustawy, rozporządzenia krajowe i unijne),
 wytycznych Ministerstwa Rozwoju,
 dokumentów programowych (SZOOP, RPO),
 procedur wdrażania RPO WSL,
 schematów XML Schema w zakresie eksportu plików XML do SL
2014.
Strona 47 z 71
Stała kontrola działania mechanizmów zapewniających integrację z systemami
zewnętrznymi, reagowanie na zmiany i dostosowywanie mechanizmów
wbudowanych w LSI:
 Baza Internetowa REGON (BIR),
 SEKAP,
 SL2014,
 MantisBT,
 Strony internetowe: http://rpo.slaskie.pl/lsi/nabory/, http://www.scpslask.pl/lsi/nabory/.
Modyfikacje wprowadzane są w środowisku testowym, a po ich
przetestowaniu przez użytkowników wprowadzane na środowisko produkcyjne
i szkoleniowe.
Wdrożenia nowych elementów realizowane są w środowisku developerskim.
Po testach użytkowników nowe elementy systemu wprowadzane są na
środowisko produkcyjne, szkoleniowe i testowe. Do obsługi błędów oraz
realizacji zleceń instalacji wykorzystywana jest platforma typu „bug trucker”.
Platforma utrzymywana jest przez firmę Alterout IT Sp. z o.o. na jego
platformie sprzętowej. Za wszelkie zmiany wprowadzane na poszczególnych
platformach systemu LSI 2014 odpowiada ww. firma zewnętrzna. Patrz:
Rekomendacja 10.
12.2.2.
Prace rozwojowe zlecane podmiotom zewnętrznym
UM WSL w ramach umowy nr 2475/RR/2014/FS na wytworzenie,
uruchomienie, asystę techniczną i utrzymanie LSI 2014 wytworzenie
i uruchomienie systemu LSI 2014 powierzył firmie ART4NET Spółka cywilna.
W chwili obecnej za utrzymanie systemu i asystę techniczną na mocy umowy
nr 1064/RR/2016 z dnia 4 maja 2016 roku odpowiada firma Alterout IT Sp.
z o. o. Tryb i zakres świadczenia usług określa załącznik nr 1 do umowy.
12.2.3.
Testy akceptacyjne systemów
Zgodnie z Umową nr 2475/RR/2014/FS na wytworzenie, uruchomienie, asystę
techniczną i utrzymanie LSI 2014 wymagana była realizacja testów
z prowadzonego procesu tworzenia oprogramowania, w ramach których
założono wykorzystanie elementów zwinnych metodyk wytwarzania
oprogramowania, polegających na intensywnej bieżącej komunikacji
z wykonawcą i pomiędzy zaangażowanymi instytucjami, krótkich cyklach
wytwórczych i ich testowaniu. Realizowanie testów akceptacyjnych przed
odbiorem oprogramowania, wykonywane było na systemie testowym
(https://lsi-test.slaskie.pl/).
Zgodnie z umową w zakresie realizacji asysty technicznej i utrzymania
systemu LSI 2014 z firmą Alterout IT Sp. z o. o. proces realizowany jest w
Strona 48 z 71
sposób analogiczny, tzn.: pierwsze testy wykonuje wykonawca, następnie
przekazuje wprowadzone zmiany do testów do urzędu. W testach poza
zgłaszającymi i administratorami uczestniczą wybrani użytkownicy.
Ewentualne błędy wykryte w trakcie testowania są weryfikowane
i przekazywane wykonawcy do naprawy. Następnie proces jest powtarzany.
Cały proces replikowanych testów dokumentowany jest w narzędziu typu „bug
tracker”.
12.3. Dane testowe
12.3.1.
Ochrona danych testowych
Zgodnie z zapisami umowy nr 2475/RR/2014/FS na wytworzenie,
uruchomienie, asystę techniczną i utrzymanie LSI 2014 w OPZ stanowiącym
element umowy określono, że cyt. „Wykonawca na własne potrzeby (w celu
testowania systemu) przygotuje bazę danych do wykonywania operacji dla
wersji testowej systemu. W miarę postępów prac i testów Zamawiający
i Wykonawca wspólnie wytworzą bazę danych do wykonywania operacji na
istniejących danych dla wersji szkoleniowej systemu. Na dalszych etapach prac
gdy pierwsze moduły systemu będą już działały produkcyjnie, możliwe będzie
na podstawie uzgodnień stron skopiowanie danych do pozostałych baz z bazy
produkcyjnej. Przy kopiowaniu baz może zachodzić potrzeba anonimizacji
danych osobowych”.
W trakcie przeprowadzonego wywiadu ustalono, że dane testowe każdorazowo
przygotowywane były przez użytkowników po stronie IZ oraz IP dla
przeprowadzenia planowanych testów. Rodzaj przeprowadzonych testów
zależał od realizowanej modyfikacji lub zmiany w systemie. Wykorzystywane
dane do testów nie były danymi rzeczywistymi. Jest to zgodne z wymaganiami
określonymi w pkt. 16.2 IZSI, który określa, że „należy unikać stosowania
danych zawierających dane identyfikujące osobę lub inne poufne dane
w charakterze danych testowych. Wykorzystywanie danych produkcyjnych do
testów możliwe jest po zastosowaniu anonimizacji zgodnie art. 7 pkt 3 UODO
oraz że w przypadku konieczności używania do testów danych rzeczywistych,
należy stosować Procedurę Zarządzania Dostępem.”
Strona 49 z 71
13.
RELACJE Z DOSTAWCAMI
13.1. Bezpieczeństwo informacji w relacjach z dostawcami
13.1.1.
Polityka bezpieczeństwa informacji w relacjach z dostawcami
UM WSL kontroluje realizację umów z zewnętrznymi dostawcami usług
informatycznych i serwisowych. Umowy są realizowane zgodnie
z wymaganiami prawnymi, co każdorazowo potwierdza na zawierane umowie
upoważniony radca prawny. Referat merytoryczny już na etapie przetargu
składa oświadczenie dot. konsultacji zakresu technicznego szczegółowego
opisu przedmiotu zamówienia (SOPZ) z Wydziałem Informatyki
i Administracji – Referat Informatyki i ABI. Ewentualne strategiczne zmiany
SOPZ na etapie umowy podlegają tej samej procedurze. Zespół systemów
informatycznych kontroluje wykonawcę poprzez narzędzia przewidziane
w SOPZ i umowie. Wymagany sposób nadzoru realizacji umowy odbywa się
poprzez bieżący kontakt z wykonawcą, protokolarne odbieranie etapów
realizacji umowy, narzędzia informatyczne do komunikacji, zabezpieczenia
karami umownymi. Za nadzór w tym zakresie odpowiada Wydział Rozwoju
Regionalnego, Referat Administracyjny, Zespół ds. zamówień publicznych.
Celem takiej kontroli jest zapewnienie odpowiedniego poziomu usług i ich
bezpieczeństwa. Działania dostawców są monitorowane i weryfikowane
zgodnie z postanowieniami umowy.
Zgodnie z Instrukcją Zarzadzania Systemem Informatycznym (pkt 16.3)
w umowach zawieranych z wykonawcami należy uwzględniać kwestie
związane z bezpieczeństwem informacji, szczególnie dotyczące:
a) zachowania poufności;
b) informacji podlegających ochronie, w tym danych osobowych;
c) spełniania wymogów prawnych;
d) praw własności intelektualnej i prawa autorskiego;
e) zasad informowania o naruszeniach.
W celu zapewnienia kontroli osób trzecich z firm świadczących usługi Urząd
określa w umowach klauzule dotyczące:

obowiązku przeszkolenia swojego personelu przez wykonawcę
z zakresu ochrony danych osobowych oraz możliwości weryfikowania
przez Urząd wiedzy i zachowań personelu zewnętrznego w tym
zakresie;

określenia miejsc wyłączonych z dostępu dla
zewnętrznych (serwerownia, kasa, archiwum, itp.);
Strona 50 z 71
pracowników

każdorazowego wyznaczenia pracownika do nadzoru personelu
zewnętrznego;

upoważnienia do dostępu, który jest możliwy tylko po uzyskaniu
pisemnej zgody ABI;

zachowania poufności wszelkich informacji o Urzędzie na czas trwania
umowy oraz po jej ustaniu;

określenia prawa do przeprowadzenia audytu wykonawcy w zakresie
weryfikacji i oceny realizacji wymagań wynikających z umowy.
W ramach umowy nr 2475/RR/2014/FS na wytworzenie, uruchomienie, asystę
techniczną i utrzymanie Lokalnego Systemu Informatycznego dla Regionalnego
Programu Operacyjnego Województwa Śląskiego na lata 2014-2020 określone
zostały następujące wymagania względem podmiotu realizującego umowę –
firmy ART4NET:

Każda z osób zaangażowanych w realizację zamówienia ze strony
Wykonawcy podpisze przed przystąpieniem do jego realizacji
zobowiązanie do niegromadzenia, nieudostępniania i nieujawniania
żadnych danych osobom trzecim zgodnie ze wzorem zawartym
w załączniku nr 3 do umowy;

Wykonawca podpisze niezbędne dokumenty i oświadczenia wynikające
z Polityki Bezpieczeństwa Informacji Urzędu.
Szczegółowe wymagania dotyczące realizacji zamówienia określone zostały
w Opisie Przedmiotu Zamówienia stanowiącym załącznik nr 1 do ww.
Umowy.
Z kolei w umowie zawartej z firmą Alterout IT Sp. z o. o na utrzymanie
systemu i asystę techniczną znajdują się analogiczne zapisy dotyczące
zobowiązania wykonawcy do zachowania tajemnicy oraz nieudostępniania
i nieujawniania żadnych danych z Systemu osobom trzecim.
13.2. Zarządzanie usługami świadczonymi przez dostawców
13.2.1.
Monitorowanie i przegląd usług świadczonych przez dostawców
System LSI 2014 utrzymywany jest na sprzęcie własnym Urzędu
Marszałkowskiego. Usługi developerskie są świadczone przez wyłonionego na
drodze postępowania przetargowego wykonawcę zewnętrznego. W umowie
znajdują się zapisy regulujące zasady współpracy, które obowiązują strony.
Umowa zawiera np. czasy reakcji na zgłaszane błędy ze względu na ich
istotność oraz jest podzielona na etapy, a wypłata środków następuje po odbiorze
danego etapu.
Ustalono, że zapisy dotyczące monitorowania i przeglądu usług wykonawcy
określane w umowach zapewniają UM możliwości dokonywania audytów
i przeglądów wykonawcy.
Strona 51 z 71
13.2.2.
Zarządzanie zmianami w usługach świadczonych przez dostawców
Proces realizowany jest w oparciu o wymagania wynikające z treści zawartych
umów i zostały przedstawione w pkt. 10.1.2 – Zarządzania zmianami.
Strona 52 z 71
14.
ZARZĄDZANIE INCYDENTAMI ZWIĄZANYMI
Z BEZPIECZEŃSTWEM INFORMACJI
14.1. Zarządzanie incydentami związanymi z bezpieczeństwem informacji oraz
udoskonaleniami
14.1.1.
Odpowiedzialności i procedury
W UM obowiązuje Procedura Postępowania z Incydentami, której celem
funkcjonowania jest zapewnienie szybkiej, skutecznej i zorganizowanej oceny
zdarzeń i reakcji na incydenty związane z bezpieczeństwem informacji.
Uzupełnieniem do przedmiotowej procedury jest Instrukcja Użytkownika,
zgodnie z którą odbywa się zgłaszanie zdarzeń i słabości (podatności).
Zgodnie z procedurą postępowania z incydentami ABI jest zobowiązany do
przyjęcia zgłoszenia, umieszczenia go w prowadzonym rejestrze zdarzeń
i słabości, którego wzór określa załącznik nr 1 do ww. procedury, oraz oceny
takiego zdarzenia. ABI i GASI odpowiadają za ocenę zdarzeń i podjęcie
odpowiedniej działań w zakresie wynikającym z przydzielonych obowiązków.
Zgodnie z Instrukcją Użytkownika każda osoba, użytkownik systemów
informacyjnych Urzędu ma obowiązek odnotowania i zgłaszania tak szybko,
jak to jest możliwe, zdarzeń i słabości (podatności) związanych
z bezpieczeństwem informacji. Wymaga się, aby odnotowywać wszystkie
ważne szczegóły (np. objawy problemu, treść błędu, działania, wiadomości
z ekranu, błędy konfiguracji itd.)
Osoba zgłaszająca odpowiada za możliwie wyczerpujące opisanie zdarzenia
adekwatnie do posiadanej wiedzy i umiejętności.
W ramach odpowiedzialności poszczególnych ról określono, że:

Użytkownik: Zobowiązany jest do niezwłocznego powiadomienia ABI
oraz uczestniczy w przygotowaniu raportu stwierdzenia naruszenia
bezpieczeństwa;

ABI: Podejmuje czynności wyjaśniające przyczyny zaistnienia
incydentu, a w przypadku potwierdzenia jego wystąpienia uzupełnia
raport naruszenia bezpieczeństwa o ustalenia z przeprowadzonego
dochodzenia oraz wyciąga wnioski dotyczące niezbędnych do podjęcia
działań. We współpracy z GASI proponuje w uzasadnionych
przypadkach Administratorowi Danych wdrożenie nowych lub
modyfikację istniejących zabezpieczeń, wdrożenie nowych lub
aktualizację istniejących procedur;

GASI: Dba o bezpieczeństwo systemów teleinformatycznych Urzędu
oraz ich zgodność z przepisami prawa; Przeprowadza postępowanie
wyjaśniające w celu ustalenia okoliczności i przyczyn naruszenia
Strona 53 z 71
bezpieczeństwa. Podejmuje działania
ponownym wystąpieniem zagrożenia;
chroniące
system
przed

Kierownictwo Urzędu - ADO: Podejmuje decyzję o dalszym trybie
postępowania w przypadku naruszenia bezpieczeństwa informacji.;

ABI oraz GASI zobowiązani są do informowania ADO o wszelkich
awariach systemu informatycznego, a w szczególności o przypadkach
nadużyć
spowodowanych
przez
użytkowników
systemu
informatycznego.
W systemie LSI 2014 w zakresie obsługi incydentów bezpieczeństwa
obowiązuje zasada określona w pkt. 12.6 dokumentu „Zasady zarządzania LSI
2014 w ramach RPO WSL 2014-2020”, która zobowiązuje wszystkich
użytkowników systemu do zgłaszania wszelkich incydentów związanych
z naruszeniem zasad bezpieczeństwa do bezpośredniego przełożonego oraz
administratora.
Określono również przebieg wsparcia technicznego i obsługi błędów
w systemie LSI 2014. Za pośrednictwem wsparcia technicznego istnieje
możliwość zgłoszenia propozycji zmiany funkcjonalności aplikacji LSI 2014
lub zgłoszenie problemu nie będącego błędem aplikacji. Możliwe jest
dokonywanie zgłoszeń przez: użytkownika, wnioskodawcę, użytkownika
instytucji oraz członka KOP.
Zgłoszenie błędu przez użytkownika instytucji dokonywane jest do AMI na
właściwy administratorowi adres e-mail. Pozostali użytkownicy zgłaszają
błędy mail-owo do GAM (mailto: [email protected]) W przypadku braku
możliwości rozwiązania problemu przez Administratora Merytorycznego
Instytucji, AMI rejestruje zgłoszenie na wewnętrznej platformie zgłaszania
błędów (aplikacja typu „bug trucker”). Takie zgłoszenie jest wówczas
realizowane przez GAM.
Pytania dotyczące systemu beneficjent/wnioskodawca zobowiązany jest
kierować do PIFE na adres mailowy: [email protected]
Regulamin dostępny dla użytkowników systemu określa, że w przypadku
zauważenia błędów w działaniu Systemu użytkownik zobowiązany jest zgłosić
to Administratorowi na adres e-mail: [email protected]
14.1.2.
Zgłaszanie zdarzeń związanych z bezpieczeństwem informacji
Od chwili udostępnienia wersji produkcyjnej systemu LSI 2014 nie
odnotowano zgłoszenia incydentu bezpieczeństwa dotyczącego tego systemu.
Sposób zgłaszania takich zdarzeń został określony w „Zasadach zarządzania
LSI 2014 w ramach RPO WSL 2014-2020”.
Użytkownicy LSI 2014 zobowiązani są do zgłaszania wszelkich incydentów
związanych z naruszeniem zasad bezpieczeństwa do bezpośredniego
Strona 54 z 71
przełożonego oraz Administratora. Regulamin dostępny dla użytkowników
systemu określa, że w przypadku zauważenia błędów w działaniu Systemu
użytkownik zobowiązany jest zgłosić to Administratorowi na adres e-mail:
[email protected]
Określono procedurę zgłaszania zdarzeń bezpieczeństwa i ich obsługi, która
została formalnie określona i zatwierdzona jako odstępstwo od zapisów
Instrukcji Wykonawczych IZ RPO. Procedura nosi nazwę „Instrukcji
blokowania dostępu do profilu użytkownika LSI 2014 z przyczyn
bezpieczeństwa”. Przedmiotowa procedura definiuje kolejność realizowanych
czynności wraz z określeniem czasu ich realizacji, kanału komunikacyjnego
oraz odpowiedzialnego za realizację czynności procesu.
Z kolei z dokumentacji bezpieczeństwa UM wynika, że zdarzenia
bezpieczeństwa użytkownicy zobowiązani są zgłaszać do ABI. Sposób
powiadomienia ABI o wystąpieniu zdarzenia jest określony. Zasady i tryb
zgłaszania zdarzeń przez użytkowników systemów informatycznych określa
Instrukcja Użytkownika.
W UM funkcjonuje lokalny system Help Desk, który rejestruje zdarzenia
związane z bezpieczeństwem informacji. Przebieg procesu jest zarządzany
i realizowany zgodnie z przyjętym schematem działania.
14.1.3.
Zgłaszanie słabości związanych z bezpieczeństwem informacji
Zgodnie z informacją dostępną dla użytkowników systemu w Regulaminie
dostępnym na stronie logowania użytkownik zobowiązany jest, w przypadku
zauważenia błędów w działaniu systemu, zgłosić to Administratorowi na adres
e-mail: [email protected].
14.1.4. Ocena i podejmowanie decyzji w sprawie zdarzeń związanych
z bezpieczeństwem informacji
Ocenę i decyzję w sprawie zdarzeń związanych z bezpieczeństwem informacji
podejmują, zgodnie z zakresem swoich kompetencji administratorzy
merytoryczni, administratorzy techniczni oraz ABI, który zobowiązany jest
podejmować czynności wyjaśniające przyczyny zaistnienia incydentu. ADO,
po zapoznaniu się z informacją przedstawioną przez ABI, podejmuje decyzję
o dalszym trybie postępowania z incydentami, w tym zobowiązany jest podjąć
działania zapewniające bezpieczeństwo systemu informatycznego.
W UM nie funkcjonuje żaden organ nadzorujący dokonujący oceny oraz
rekomendacji podjęcia działań naprawczych i korygujących w zakresie zdarzeń
związanych z bezpieczeństwem informacji. W procesie oceny i analizy
przyczyn
incydentów
nie
uczestniczą
przedstawiciele
komórek
odpowiedzianych za bezpieczeństwo organizacji. Obecny realizowany proces
opiera się głównie o rolę ABI i GASI, którzy jednak nie posiadają
Strona 55 z 71
wystarczającego umocowania w organizacji do poprawy działania oraz
wdrażania wszystkich wymaganych zabezpieczeń.
Rekomendacja 13
14.1.5.
Komitet Sterujący Bezpieczeństwem Informacji.
Reagowanie na incydenty związane z bezpieczeństwem informacji
Zgodnie z Regulaminem użytkownik zauważone błędy w działaniu systemu
zobowiązany jest zgłosić Administratorowi na adres e-mail: [email protected]
Regulamin wskazuje na konieczność zgłaszania wszelkich zagrożeń
bezpieczeństwa, a sposób reagowania na incydenty bezpieczeństwa przez
osoby zaangażowane w ich obsługę został określony szczegółową procedurą:
„Instrukcją blokowania dostępu do profilu użytkownika LSI 2014 z przyczyn
bezpieczeństwa”, w tym zostały wskazane czasy reakcji i obsługi zdarzenia –
potencjalnego incydentu.
14.1.6. Wyciąganie wniosków z incydentów związanych z bezpieczeństwem
informacji
Z uzyskanych informacji wynika, iż ABI z udziałem GASI odpowiada za
wyjaśnienie przyczyny zaistnienia incydentu bezpieczeństwa informacji, w tym
sporządza dokumentację opisującą incydent bezpieczeństwa. W uzasadnionych
przypadkach proponuje Administratorowi Danych wdrożenie nowych lub
modyfikację istniejących zabezpieczeń. ABI prowadzi Rejestr zdarzeń
i słabości, w którym odnotowuje zgłaszane zdarzenia i dokonuje ich
klasyfikacji.
Od stycznia 2015 roku do marca 2016 roku odnotowane zostały w UM cztery
naruszenia bezpieczeństwa informacji, z czego istotnym dla bezpieczeństwa
infrastruktury IT systemu LSI 2014 było zdarzenie w serwerowni systemu
zlokalizowanej w budynku na ul. Dąbrowskiego 23. Do zdarzenia doszło poza
godzinami pracy urzędu, o godz. 6:15, w dniu 24 kwietnia 2015 roku (piątek).
Przyczyną wystąpienia zdarzenia był fałszywy alarm wygenerowany przez
czujkę ppoż zlokalizowaną w tej serwerowni. W trakcie podjętej próby wejścia
do serwerowni przez służbę ochrony doszło do zablokowania zamka
w drzwiach, co uniemożliwiło ich otwarcie. W wyniku automatycznego
wezwania przez system alarmowy na miejsce przybyła Straż Pożarna, która
wyważyła drzwi i weszła do serwerowni.
W związku ze zdarzeniem podjęto następujące działania:

Wzmożono nadzór (wizyjny i personalny) pomieszczenia serwerowni
do czasu zamontowania nowych drzwi;
Strona 56 z 71

Przeprowadzono audyt czujek przeciwpożarowych;

Zamontowano nowe drzwi do serwerowni
wytrzymałości na włamanie – drzwi klasy C3.
o
podwyższonej
Przedstawione zdarzenie było przyczyną dokonania przeglądu i weryfikacji
systemu kontroli dostępu w zakresie zapewnienia rozliczalności dostępu
personelu do serwerowni systemu LSI 2014. W wyniku podjętych działań
opracowano i wdrożono „Procedurę awaryjnego wejścia do serwerowni”.
Wykorzystywany jest jeden dziennik wejść/wyjść do serwerowni. Wpisy do
dziennika są weryfikowane i dokonywane w punkcie służby ochrony.
W związku z tym zdarzeniem wydano rekomendację o numerze 8:
„Rejestrator CCTV”.
Strona 57 z 71
15.
ASPEKTY BEZPIECZEŃSTWA INFORMACJI W ZARZĄDZANIU
CIĄGŁOŚCIĄ DZIAŁANIA
15.1. Ciągłość bezpieczeństwa informacji
15.1.1.
Planowanie ciągłości bezpieczeństwa informacji
Podstawowymi dokumentami definiującymi proces zarządzania ciągłością
działania infrastruktury teleinformatycznej Urzędu Marszałkowskiego jest
„Plan zachowania ciągłości działania infrastruktury teleinformatycznej
Urzędu Marszałkowskiego Województwa Śląskiego”. Dokument został
wprowadzony do użytku służbowego zarządzeniem nr 00002/2013 Marszałka
Województwa Śląskiego z dnia 3 stycznia 2013 roku i był już oceniany
w trakcie realizowanych audytów w ramach perspektywy finansowej 20072013.
Założeniem określonym w dokumencie jest przedstawienie opisu sposobów
przeprowadzenia czynności w obszarach:

działania zespołu kryzysowego w stanie, gdy zostaną zakłócone
warunki realizacji procesów i podprocesów krytycznych związanych
z
zadaniami
delegowanymi
w Urzędzie
Marszałkowskim
Województwa Śląskiego;

wznawiania działalności po likwidacji skutków związanych ze
zdarzeniem, które spowodowało sytuację kryzysową;

zapewnienia funkcjonowania urzędu w warunkach kryzysowych
w zastępczych miejscach pracy.
Dokument wskazuje również, że zawarte w nim zadania mają być
dostosowywane do bieżących warunków i wykonywane są na polecenie i za
zgodą Dyrektora AI.
Określono założenie organizacyjne, aby w zależności od zaistniałej sytuacji
kryzysowej i bieżącego obciążenia zadaniami kierownik Referatu Informatyki
na polecenia Dyrektora Wydziału AI stworzył, zgodnie z niniejszym
dokumentem zespół kryzysowy złożony z pracowników Referatu Informatyki.
Zespół będzie tworzony z pracowników Referatu Informatyki w zależności od
rodzaju kryzysu, uwarunkowań zewnętrznych i aktualnego nakładu pracy
w przypadku wystąpienia sytuacji uniemożliwiającej pracę zgodnie
z procedurami.
Zidentyfikowane sytuacje kryzysowe oraz sytuacje awaryjne dotyczą
wyłącznie:
Strona 58 z 71

braku dostępu do danych, sieci, Internetu;

braku łączności telefonii stacjonarnej;

braku zasilania.
W ocenie Instytucji Audytowej dokument „Plan zachowania ciągłości
działania infrastruktury teleinformatycznej Urzędu Marszałkowskiego
Województwa Śląskiego” nie spełnia przyjętych założeń określonych w tym
dokumencie. Tym samym nie pozwala na skuteczne zarządzania ciągłością
działania kluczowych procesów biznesowych realizowanych przez urząd.
Należy również wskazać, że dokument nie posiada żadnej metryki, tj. nie
pozwala na identyfikację jego wersji oraz dokonanych zmian w dokumencie, w
tym kto dokonywał tych zmian i w jakim zakresie. Jedyną wskazówką jest
załącznik do planu zachowania ciągłości działania – scenariusz, który wskazuje
zarządzenie nr 00002/2013 Marszałka Województwa Śląskiego z dnia
3 stycznia 2013 roku.
Przedstawiony dokument jest tym samym, który obowiązywał w roku 2012.
Dokument nie był nigdy aktualizowany oraz nie zawiera aktualnych planów
postępowanie w przypadku wystąpienia awarii lub katastrofy – nie daje
gwarancji zapewnienia ciągłości działania urzędu.
Rekomendacja 14
Plan zapewnienia ciągłości działania.
Należy tu jednak wskazać, że z uwagi na podjęte przez UM działania, tj.
realizację zamówienia pn. „Doradztwo w zakresie dostosowania systemu
zarządzania
bezpieczeństwem
teleinformatycznym
dla
Urzędu
Marszałkowskiego Województwa Śląskiego w Katowicach przy ul. Ligonia
46”, w zakresie którego jest opracowanie Planu zarządzania ciągłością
działania wydana rekomendacja została zaklasyfikowana jako „nieistotna”.
Etapy realizacji zamówienia zostały wskazane w części Sprawozdania
w pkt 4.1.1 Dokument polityki bezpieczeństwa informacji.
15.1.2.
Wdrożenie ciągłości bezpieczeństwa informacji
Przedstawiony do oceny dokument „Plan zachowania ciągłości działania
infrastruktury teleinformatycznej Urzędu Marszałkowskiego Województwa
Śląskiego” wskazuje na odpowiedzialność kierownika Referatu Informatyki,
tj.: że w zależności od zaistniałej sytuacji kryzysowej i bieżącego obciążenia
zadaniami to właśnie kierownik Referatu Informatyki na polecenie Dyrektora
Wydziału AI powołuje zespół kryzysowy w skład, którego wchodzą jedynie
pracownicy Referatu Informatyki. Taki zespół ma być tworzony
z pracowników RI w zależności od rodzaju kryzysu, uwarunkowań
zewnętrznych i aktualnego nakładu pracy w przypadku wystąpienia sytuacji
uniemożliwiającej pracę zgodnie z procedurami.
Strona 59 z 71
15.1.3.
Weryfikowanie, przegląd i ocena ciągłości bezpieczeństwa informacji
W dokumencie określającym proces zarządzania ciągłością działania
infrastruktury teleinformatycznej Urzędu Marszałkowskiego tj. „Planie
zachowania ciągłości działania infrastruktury teleinformatycznej Urzędu
Marszałkowskiego Województwa Śląskiego” określono, że ze względu na
charakter dokumentu wymaga on ciągłej aktualizacji i dostosowywania
zawartych w nim treści do bieżących potrzeb i warunków. Wszelkie konieczne
zmiany zawartych w nim treści do bieżących potrzeb i warunków wykonywane
są na polecenie i za zgodą Dyrektora AI.
Zgodnie z uzyskanymi informacjami nie przeprowadzono testów ciągłości
działania, w szczególności działania kluczowych elementów infrastruktury
teleinformatycznej, m.in. działania serwerowni, serwerowni backupowej,
zasilania awaryjnego. Nie potwierdzono wykonywania cyklicznych
przeglądów PZCD.
Rekomendacja 15
Testowanie ciągłości działania.
Strona 60 z 71
16.
USTALENIA I REKOMENDACJE
Rekomendacja 1
nieistotna
Aktualizacja PBI w zakresie klasyfikacji informacji i postępowania z nią
(4.1.1)
Ustalenie
W dokumentach formalnych UM WSL nie wskazano zasad klasyfikacji
informacji i zasad ich ochrony.
Wniosek
Brak klasyfikacji informacji powoduje ryzyko błędnego sposobu ochrony
aktywów informacyjnych. Klasyfikacja informacji powinna być zgodna
z aktami prawnymi oraz ważnością aktywów informacyjnych
w organizacji. Budowa zasad bezpieczeństwa dla ochrony aktywów
informacyjnych wymaga dokonania klasyfikacji informacji przetwarzanych
w UM WSL.
Treść
rekomendacji
Zaleca się ustanowienie wytycznych w zakresie oznaczania i klasyfikacji
informacji oraz określenie zasad bezpieczeństwa dla aktywów
informacyjnych (grup informacji).
Odpowiedź UM
Rekomendacja zostanie rozważona. Niemniej biorąc pod uwagę specyfikę
Urzędu, np:
• większość procesów w Urzędzie polega na przetwarzaniu danych
osobowych;
• informacje chronione na podstawie ustawy o ochronie informacji
niejawnych przetwarzane są osobno na podstawie osobnych regulacji
wewnętrznych (określa je Pełnomocnik ds. Ochrony Informacji
Niejawnych);
• ze względu na ustawę o dostępie do informacji publicznej granica
pomiędzy informacją publiczną i prywatnością podmiotu danych jest
wyznaczana każdorazowo w trakcie rozpatrywania wniosków o dostęp do
informacji publicznej;
opracowanie klasyfikacji informacji, która:
• byłaby prosta (niewielka ilość kategorii);
• byłaby jednoznaczna (brak wątpliwości przy przydzielaniu kategorii);
• miałaby wartość dodaną względem stanu bez jej stosowania; będzie
utrudnione, o ile w ogóle możliwe.
Stanowisko IA
Rekomendacja niewdrożona, otwarta. Stan wdrożenia rekomendacji
zostanie zweryfikowany podczas audytu systemu.
Strona 61 z 71
Rekomendacja 2
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Stanowisko IA
Rekomendacja 3
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Określenie wykazu stosowanych zabezpieczeń w UM (4.1.1)
Dokumenty polityki bezpieczeństwa UM WSL w głównej mierze wskazują
zabezpieczenia dotyczące bezpieczeństwa systemów informatycznych. Nie
wskazują na wszystkie zabezpieczenia obowiązujące w obszarze
bezpieczeństwa informacji, np. dotyczące bezpieczeństwa zasobów
ludzkich.
Sytuacja, w której stosowanie zasad bezpieczeństwa wynika głównie
z doświadczenia i wiedzy pracownika powoduje ryzyko błędnego lub
niewłaściwego użycia zabezpieczeń do ochrony aktywów informacyjnych.
Z dokumentacji bezpieczeństwa informacji powinny wynikać zasady
(zabezpieczenia) dla ochrony aktywów informacyjnych oraz
odpowiedzialności za ich aktualność i zgodność z wymaganiami
prawnymi.
Należy określić jakie są stosowane zabezpieczenia w UM WSL. Zaleca się
uzupełnić PBI UM WSL lub opracować deklarację stosowanych
zabezpieczeń w oparciu o załącznik A normy ISO 27001.
Zgodnie z normą 27001 w wersji 2014-12 nie ma obowiązku
opracowywania deklaracji stosowanych zabezpieczeń. Proponuje się
odstąpienie od rekomendacji. Niemniej jednak rekomendacja
wprowadzenia „deklaracji" zostanie rozważona.
Rekomendacja podtrzymana. Stan wdrożenia rekomendacji zostanie
zweryfikowany podczas audytu systemu.
Plan szkoleń użytkowników systemu LSI 2014 (6.1.1)
Ustalono, że szkolenia użytkowników LSI 2014 realizowane są w ramach
bieżącego zapotrzebowania. Nie podlegają planowaniu formalnemu oraz
cyklicznej ich realizacji. Stosowane praktyki uniemożliwiają ponadto na
potwierdzenie liczby przeszkolonych użytkowników.
Brak planowanych szkoleń, w szczególności dedykowanych nowym
użytkownikom skutkuje ryzykiem niewłaściwej obsługi systemu.
Zaleca się planować szkolenia dla użytkowników LSI 2014.
Zaleca się również by proces realizacji szkoleń pozwalał na potwierdzenia
zrealizowanych szkoleń oraz grupy przeszkolonych użytkowników.
Strona 62 z 71
Odpowiedź UM
Zgodnie z dokumentem „Zasady zarządzania LSI 2014 w ramach RPO
WSL 2014-2020" użytkownik rozumiany jako pracownik Instytucji
Zarządzającej lub Pośredniczącej przed uzyskaniem dostępu do systemu
LSI 2014 zostaje przeszkolony w wymaganym zakresie. Liczba
przeszkolonych użytkowników jest możliwa do jednoznacznego określenia
na podstawie ilości użytkowników w systemie LSI 2014.
Zgodnie z rekomendacją do końca maja br. zostanie opracowany plan
szkoleń pracowników Instytucji Zarządzającej i Pośredniczących na rok
bieżący. Dla lat kolejnych zostaną opracowane plany szkoleń nie później
niż w ostatnim kwartale roku poprzedzającego rok, którego plan dotyczy.
Odpowiednie zapisy zostaną wprowadzone do Zasad Zarządzania LSI
2014. Planowany termin wdrożenia zmian w tym zakresie to 12 maj 2016 r.
Stanowisko IA
Rekomendacja 4
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Stan wdrożenia rekomendacji zostanie zweryfikowany podczas audytu
systemu.
Przegląd dostępów (7.2.5)
Ustalono brak wykonywania
użytkowników domeny UM.
cyklicznych
przeglądów
aktywności
Brak przeglądów aktywności użytkowników powoduje ryzyko
nieuprawnionego dostępu do danych przetwarzanych w systemie
informatycznym UM WSL.
Zaleca się prowadzenie przeglądów aktywności użytkowników na poziomie
kontrolera domeny i dokumentowanie ich realizacji.
Przeglądy są prowadzone cyklicznie w oparciu o nadsyłane informacje od
ABI dotyczące wyłączenia kont użytkowników zwolnionych bądź
przebywających poza pracą przez dłuższy okres czasu (powyżej 30 dni) lub
też włączenia kont użytkowników w chwili powrotu na stanowisko pracy.
Nowa polityka bezpieczeństwa definiuje okresowe przeglądy kont
użytkowników, które będą się odbywać regularnie raz na pół roku. Działanie
takie zostanie odnotowane w dzienniku serwerów.
Rekomendacja zostanie ujęta w trakcie aktualizacji PBI (prace nad
kompleksową aktualizacją PBI są na ukończeniu - planowany termin
zatwierdzenia aktualizacji PBI to koniec kwietnia 2016 r.).
Stanowisko IA
systemu.
Strona 63 z 71
Rekomendacja 5
nieistotna
Zmiana hasła przez użytkownika (7.3.1)
Ustalenie
Ustalono, że zmiana hasła przez użytkownika w systemie LSI 2014 nie
wymaga podania hasła dotychczasowego.
Wniosek
Brak mechanizmu autoryzacji zmiany hasła skutkuje ryzykiem
nieuprawnionej zmiany poufnych informacji uwierzytelniających.
Treść
rekomendacji
Zaleca się, aby zmiana hasła użytkownika wymagała podania hasła
dotychczasowego.
Odpowiedź UM
Do końca II kwartału zostanie dodane wymuszenie podania hasła
dotychczasowego przy zmianie hasła w LSI 2014.
Stanowisko IA
systemu.
Rekomendacja 6
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Deponowanie haseł (7.4.3)
Podczas prac audytowych nie potwierdzono
wymaganych do zarządzania systemem LSI 2014.
deponowania
haseł
Brak zdeponowania haseł niezbędnych do zarządzania systemem LSI 2014
powoduje ryzyko opóźnienia podjęcia czynności administracyjnych
w przypadku wystąpienia katastrofy lub niedostępności kluczowego
personelu.
Zaleca się zdeponowanie haseł administracyjnych systemów serwerowych/
bazy danych w miejscu o chronionym dostępie, zgodnie z przyjętymi
w UM wymaganiami.
Obecne zapisy PBI nie sprawdziły się, wymóg deponowania haseł zostanie
usunięty w trakcie aktualizacji PBI. Zatwierdzenie aktualizacji PBI
planowane jest na koniec kwietnia 2016 r.
Na dalszym etapie zostaną rozważone inne rozwiązania z zakresu
zachowania ciągłości działania.
Uzupełnienie odpowiedzi przez UM:
Zgodnie z wcześniej przekazaną informacją, wymóg zostanie usunięty
z Polityki Bezpieczeństwa Informacji, w związku z powyższym nie będzie
już konieczności jego realizowania przez ASI. Tego typu zabezpieczenie
nie znajduje się na liście zabezpieczeń z normy ISO 27002, oczywiście
może być rozpatrywane jako dodatkowe zabezpieczenie, spoza katalogu
opisanego normą. W dalszej perspektywie, po analizie ryzyka której
pierwsza iteracja ma być przeprowadzona zgodnie z przekazanymi
informacjami przy pomocy zewnętrznej firmy doradczej, być może
Strona 64 z 71
zaistnieje potrzeba wprowadzenia z powrotem tego lub innych
zabezpieczeń w badanym obszarze. Będzie to ewentualnie przedmiotem
kolejnej aktualizacji PBI w tym zakresie.
Stanowisko IA
Rekomendacja 7
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Stanowisko IA
systemu.
Mechanizmy i metody kryptograficzne (8.1.1)
Ustalono, że zapisy w IZSI dotyczące zabezpieczeń kryptograficznych są
minimalne i nie wskazują zalecanych algorytmów, długości kluczy
szyfrujących oraz sposobów zarządzania nimi.
Brak określenia stosowanych mechanizmów i metod kryptograficznych
spowodować
może
ryzyko
stosowania
przestarzałych
lub
skompromitowanych
rodzajów/wersji
mechanizmów
i
metod
kryptograficznych.
Zaleca się opracowanie minimalnych wymagań w zakresie stosowania
mechanizmów i metod kryptograficznych. Dotyczy to m.in.: zalecanych
oraz zakazanych do użycia algorytmów, długości kluczy szyfrujących,
sposobu zarządzania kluczami kryptograficznymi, ograniczeń oraz zaleceń
korzystania z szyfrowania oraz określenia zasad aktualizacji tych
informacji.
Zapisy PBI zostaną uzupełnione w obszarach dotyczących stosowania
zabezpieczeń kryptograficznych. Rekomendacje dotyczące odrębnej
polityki zostaną rozważone.
systemu.
Strona 65 z 71
Rekomendacja 8
nieistotna
Ustalenie
Wniosek
Rejestrator CCTV (9.1.3)
Ustalono, że obraz z kamery CCTV znajdującej się w serwerowni nie jest
rejestrowany, daje wyłącznie podgląd na to co dzieje się w pomieszczeniu.
Brak właściwego zabezpieczenia kluczowych obszarów przetwarzania
danych skutkuje wzrostem ryzyka w zakresie zabezpieczenia fizycznego
newralgicznego obszaru przetwarzania przed wpływem czynnika
ludzkiego, działania terrorystycznego, w tym nie gwarantuje rozliczalności
działań personelu.
Treść
rekomendacji
Zaleca się aby obraz z kamery CCTV znajdującej się w serwerowni
systemu LSI 2014 był rejestrowany i dostępny przez wskazany i
wymagany przez urząd czas.
Odpowiedź UM
Do końca roku 2016 zostanie zainstalowany nowy system CCTV wewnątrz
serwerowni z funkcją rejestracji obrazu przez wymagany czas.
Stanowisko IA
systemu.
Rekomendacja 9
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Stanowisko IA
Drzwi centralnego systemu backupu (9.2.1)
Ustalono, że drzwi do pomieszczeń systemu backupowego to standardowe
drzwi biurowe nie spełniające wymagań w zakresie wytrzymałości na
włamanie oraz odporności pożarowej.
Brak właściwego zabezpieczenia kluczowych obszarów przetwarzania
danych skutkuje wzrostem ryzyka w zakresie zabezpieczenia fizycznego
newralgicznego obszaru przetwarzania przed wpływem katastrofy lub
działania terrorystycznego.
Zaleca się zabezpieczać wejścia do pomieszczeń systemu backupowego
drzwiami dedykowanym dla pomieszczeń bezpiecznych.
W przypadku zgody właściciela budynku, zostaną wymienione drzwi do
pomieszczenia systemu kopii bezpieczeństwa na dedykowane dla
pomieszczeń bezpiecznych. Realizacja planowana jest do końca 2016 roku.
systemu.
Strona 66 z 71
Rekomendacja 10
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Procedura zarządzania zmianami (10.1.2)
UM nie dysponuje formalną procedurą zarządzania zmianami w systemie
LSI 2014.
Brak wytycznych w zakresie kontroli rozwijania funkcjonalności systemu
powoduje ryzyko, iż zmiany będą miały negatywny wpływ na działanie
systemu.
Zaleca się opracowanie wytycznych kontroli zmiany w aplikacji,
uwzględniających sposób komunikacji z wykonawcą, określanie zakresu
funkcjonalnego, odbioru i testowania zmian oraz określenie
odpowiedzialności personelu w zakresie podejmowanych decyzji.
Zaleca się określić wymagania w zakresie realizacji
technicznego po zmianach w platformie produkcyjnej.
przeglądu
Odpowiedź UM
Do końca II kwartału 2016 r. zostaną opracowane stosowne wytyczne
i wymagania.
Stanowisko IA
Rekomendacja niewdrożona, otwarta. Stan wdrożenia rekomendacji
zostanie zweryfikowany podczas audytu systemu.
Rekomendacja 11
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Rejestrowanie zdarzeń i monitorowanie (10.4.1)
Ustalono, że zapisy w IZSI dotyczące logowania zdarzeń w systemach oraz
dowodowego są niewystarczające. Ustalono, że dzienniki systemów
podlegają archiwizacji w ramach wykonywanych kopii bezpieczeństwa,
a UM nie wykorzystuje oprogramowania do zbierania i agregacji logów
systemowych w celu korelacji zdarzeń.
Brak określenia zasad tworzenia, przechowywanie i przeglądania
dzienników zdarzeń skutkuje brakiem rozliczalności działań użytkowników
i administratorów
oraz
brakiem
skutecznego
rejestrowania
alarmów/sygnałów alarmowych.
Zaleca się określić zasady logowania zdarzeń w systemach oraz
dowodowego.
Zaleca się tworzyć, przechowywać i systematycznie przeglądać dzienniki
zdarzeń rejestrujące działania użytkowników i administratorów, alarmy,
usterki oraz zdarzenia związane z bezpieczeństwem informacji.
Zaleca się wdrożyć mechanizmy agregujące dzienniki zdarzeń z różnych
systemów w celu skonsolidowanego monitorowania, identyfikacji zdarzeń
istotnych z punktu widzenia bezpieczeństwa oraz archiwizacji dla celów
audytu.
Strona 67 z 71
Odpowiedź UM
Stanowisko IA
Rekomendacja 12
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Wdrożenie mechanizmów agregacji i korelacji informacji pochodzących
z dzienników systemów (logów) będzie przedmiotem analiz także pod
kątem możliwości finansowych Urzędu.
systemu.
Zarządzanie podatnościami technicznymi (10.6.1)
Podczas prac audytowych nie potwierdzono funkcjonowania formalnych
zasad zarządzania podatnościami technicznym, w tym zasad wprowadzania
zmian wynikających z instalacji poprawek do systemów, urządzeń.
Brak formalnego procesu analizy podatności technicznych skutkuje
ryzykiem narażenia organizacji na zagrożenia wynikające z podatności
systemów lub urządzeń.
Zaleca się zidentyfikowanie procesu zarządzania podatnościami
technicznymi oraz opracowanie wytycznych umożliwiających ocenę
stopnia narażenia organizacji na podatności i podejmowanie odpowiednich
środków w celu przeciwdziałania związanemu z nimi ryzyku.
Zaleca się ponadto aby proces zarządzania podatnościami technicznymi
uwzględniał ich testowanie i ocenę przed ich instalacją w systemach
produkcyjnych. Zaleca się utrzymać ścieżkę rewizyjną dla wszystkich
wprowadzanych zmian wynikających z instalacji poprawek.
Odpowiedź UM
Wraz z wprowadzeniem nowej PBI zostanie opracowana procedura
zarządzania podatnościami technicznymi posiadanej infrastruktury.
Stanowisko IA
systemu.
Strona 68 z 71
Rekomendacja 13
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Odpowiedź UM
Komitet Sterujący Bezpieczeństwem Informacji (14.1.4)
Ustalono, że w UM WSL nie funkcjonuje żadne organ nadzorujący
dokonujący oceny oraz rekomendacji podjęcia działań naprawczych
i korygujących w zakresie zdarzeń związanych z bezpieczeństwem
informacji, którego decyzje wpływałyby na poprawę stanu bezpieczeństwa
urzędu.
Brak organu zarządczego dokonującego oceny oraz podejmującego decyzje
w zakresie poprawy stanu bezpieczeństwa UM WSL skutkuje ryzykiem
niepodjęcia działań naprawczych przez kierownictwo urzędu lub
zaniechaniem podjęcia takich działań.
Należy powołać organ zarządczy (np. Komitet Sterujący Bezpieczeństwem
Informacji), który będzie zobowiązany do oceny stanu bezpieczeństwa
Urzędu oraz rozstrzygania w zakresie podjęcia działań naprawczych
i korygujących w zakresie bezpieczeństwa informacji.
We wcześniejszych wersjach PBI opisane było analogiczne ciało, jednak
w praktyce nie funkcjonowało i zapisy zostały usunięte. Zgodnie
z proponowanymi rozwiązaniami do wprowadzenia w zaktualizowanej
PBI, ABI we współpracy z GASI na bazie incydentów proponować będą
Administratorowi Danych wdrożenie nowych lub modyfikację istniejących
zabezpieczeń, wdrożenie nowych lub aktualizację istniejących procedur.
Uzupełnienie odpowiedzi przez UM:
Zgodnie z odpowiedzią przekazaną wcześniej, nie jest przewidziane
w najbliższej aktualizacji PBI tworzenie tego typu ciała. Nowe procedury
dot. obsługi zdarzeń i incydentów przewidują elementy komunikacji ABI
oraz GASI z Administratorem Danych. Na bazie doświadczeń jakie
pojawią się w związku z funkcjonowaniem zmienionych procedur, być
może zasadny będzie powrót do koncepcji wprowadzenia tego typu
rozwiązań jak "Komitet Sterujący Bezpieczeństwem Informacji".
Podkreślenia wymaga fakt, iż tego typu ciało istniało w PBI UMWSL do
zmian przeprowadzonych w roku 2014, lecz w praktyce nie
funkcjonowało. Ze względu na wagę rekomendacji, proponuję powrócić
do dyskusji na ten temat w terminie późniejszym. Zwracam także uwagę,
iż tego typu decyzje należą do Administratora Danych.
Stanowisko IA
systemu.
Strona 69 z 71
Rekomendacja 14
nieistotna
Plan zapewnienia ciągłości działania (15.1.1)
Ustalono, że w UM WSL nie funkcjonuje Plan zapewnienia ciągłości
działania, tj. plan zawierający szczegółowe procedury postępowania
w przypadku wystąpienia katastrofy lub rozległej awarii.
Ustalenie
Brak określenia sposobów przeciwdziałania przerwom w dostępności
systemu LSI 2014, a także ochrony krytycznych procesów biznesowych
przed awarią lub katastrofą skutkuje ryzykiem niedostępności.
Wniosek
Zaleca się opracowanie i zatwierdzenie Planu zapewnienia ciągłości
działania określającego co najmniej:
Treść
rekomendacji
- rodzaj awarii;
- skutki awarii;
- osoby podejmujące działania naprawcze;
- rodzaj działania naprawczego;
lub przyjęcie założeń, że w niekorzystnych sytuacjach wymagania
w zakresie bezpieczeństwa informacji (role, odpowiedzialności,
podejmowane działania) pozostają takie same jak w normalnych
warunkach eksploatacyjnych, z tym że podjęte działania prewencyjne
wynikają z przeprowadzonej analizy ryzyka i mają na celu zapewnienie
ciągłości działania systemu LSI 2014.
Odpowiedź UM
Stanowisko IA
Rekomendacja 15
nieistotna
Ustalenie
Wniosek
Treść
rekomendacji
Rekomendacja zostanie zrealizowana do końca roku 2016 r.
systemu.
Testowanie ciągłości działania (15.1.3)
Zgodnie z uzyskanymi informacjami nie przeprowadzono testów ciągłości
działania, w szczególności działania kluczowych elementów infrastruktury
teleinformatycznej, m.in. działania serwerowni, serwerów systemu
LSI 2014, serwerowni backupowej, zasilania awaryjnego.
Brak testowania planów ciągłości działania, w tym testowania działania
kluczowych elementów infrastruktury teleinformatycznej skutkować może
negatywnym wynikiem wykonania testów.
Zaleca się przetestowanie planów ciągłości działania, w szczególności
przeprowadzenie co najmniej testów serwerowni, serwerów systemu
LSI 2014, serwerowni backupowej, zasilania awaryjnego (przełączenie na
redundantną linię zasilającą) oraz prowadzenie rejestru wykonanych
Strona 70 z 71
testów.
Odpowiedź UM
Stanowisko IA
Do końca 2016 roku zostaną zmodyfikowane plany ciągłości działania.
Zostanie dodane ich testowanie oraz dokumentowanie wyników
przeprowadzonych testów.
systemu.
Wiesław Jasiński
/podpisano elektronicznie/
Strona 71 z 71

Pobierz plik PDFSprawozdanie z audytu desygnacyjnego LSI UM

Transkrypt

Podobne dokumenty

Lista złożonych wniosków w ramach konkursu nr RPSL.11.02.02

działanie 2.1 Wsparcie rozwoju cyfrowych usług społecznych

Wzmocnienie potencjału edukacyjnego