Gdy w instytucji wystąpi awaria, kierownictwo oczekuje błyskawicznej reakcji ze strony służb IT. Aby zapewnić bezpieczeństwo, informatycy zmagają się z szeregiem czasochłonnych zadań. Z pomocą w takich przypadkach przychodzi plan ciągłości działania.
Co w zakresie utrzymania ciągłości działania urzędu robią informatycy? Wdrażają złożone plany kopii zapasowych lokalnych i wyniesionych. Zapobiegają nieuprawnionemu ujawnieniu, modyfikacji, usunięciu lub zniszczeniu informacji zapisanych na nośnikach. Monitorują pracę systemu druku, macierzy dyskowych SAN i NAS. Projektują i wdrażają polityki zarządzania energią, zabezpieczają środowisko przed utratą danych w sytuacji braku zasilania w energię elektryczną. Reagują na incydenty bezpieczeństwa, opracowują czynności naprawcze i korygujące. Konfigurują zabezpieczenia styku sieci lokalnej z internetem, aby bronić zasobów jednostek samorządu terytorialnego (dalej: jst). Realizują politykę tożsamości, zapewniając dostęp do usług osobom uprawnionym, administrują wirtualnymi serwerami i sieciami, instalują oraz konfigurują usługi świadczone w systemach teleinformatycznych. Ponadto instalują, konserwują i obsługują systemy monitoringu wizyjnego. Współpracują z policją oraz z jednostkami organizacyjnymi w celu poprawy bezpieczeństwa cybernetycznego. Utrzymują kontakty z zewnętrznymi podmiotami celem pozyskiwania informacji o nowych technologiach informatycznych. Dodatkowo na bieżąco studiują nowe przepisy prawa polskiego oraz unijnego. Świadczą wsparcie dla użytkowników końcowych oraz obsługują obrady rad i komisji. Wdrażają mechanizmy bezpieczeństwa zgodnie z zapisami Systemu Zarządzania Bezpieczeństwem Informacji, z których wynika, że poza wyżej wymienionymi zadaniami, na które z trudem wystarcza czasu, należy jeszcze opracować szczegółowe plany ciągłości działania i regularnie je testować.
Szczegóły procedury
Plan ciągłości działania (Business Continuity Planning; dalej także: plan) to zbiór procedur i informacji, które należy opracować na wypadek sytuacji kryzysowej lub zdarzenia losowego, np.: incydentu cyberbezpieczeństwa, awarii, pożaru czy zalania lub powodzi. Plan definiuje procedury mające na celu przywrócenie funkcjonowania systemów, aplikacji i infrastruktury, wskazuje obowiązki poszczególnych osób oraz zespołów, odpowiedzialnych za sprawne przywracanie systemów do działania po awarii. Pamiętajmy, że plan to tylko dokument, który jest elementem holistycznego procesu zarządzania ciągłością działania. Według normy ISO 22301 zarządzanie ciągłością działania identyfikuje potencjalne zagrożenia i wpływ, jakie te zagrożenia, jeśli wystąpią, mogą wywrzeć na działalność biznesową organizacji. Ponadto zapewnia ramy do budowania odporności organizacyjnej z możliwością skutecznej reakcji, która zabezpiecza interesy kluczowych interesariuszy, reputację, markę i działania tworzące wartość. Z badań przedstawionych przez Mercer (itwa.pl/yl) wynika, że aż 51% firm nie ma planów na wypadek zdarzenia losowego, w konsekwencji czego grozi im utrata ciągłości działania. W badaniu firmy Infinite Blue (itwa.pl/yk) dotyczącym przydatności planów ciągłości działania „How Prepared Were You – A Business Continuity Retrospective of the Covid-19 Pandemic” wzięło udział ponad 300 organizacji. Respondentów pytano o wykorzystanie planów ciągłości działania oraz planów odtwarzania po awarii. W wynikach czytamy: 45% specjalistów IT przyznało, że plany dotyczące reakcji na pandemię w momencie wybuchu COVID-19 nie były w rzeczywistości pomocne lub nie działały zgodnie z ich przeznaczeniem, zaś 81% badanych stwierdziło, że ich plany wymagały poprawy, ponieważ wcześniej przeoczono mnóstwo zależności. Patrząc przez pryzmat wyników zza oceanu, można przypuszczać, że w jst występuje podobna sytuacja.
Uwzględniając procedowanie zmiany przepisów prawa w zakresie ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (tekst jedn. DzU z 2020 r., poz. 164 ze zm.), które wprowadzają od stycznia 2026 r. obowiązek elektronicznego zarządzania dokumentacją, można stwierdzić, że obecna kadencja samorządowa jest przełomowa i przed włodarzami miast i gmin stoi wielkie wyzwanie przeprowadzenia transformacji z tradycyjnych papierowych obiegów dokumentów do elektronicznych systemów zarządzania dokumentacją klasy EZD. W obecnej sytuacji po utracie danych zapisanych w systemach elektronicznych można je odtworzyć z oryginałów papierowych. Po zmianie większość dokumentów będzie miała tylko postać elektroniczną. Z powyższego wynika wniosek, że w dobie tak wielkich zmian należy zwrócić szczególną uwagę na bezpieczeństwo informacji – jst muszą przejść z biernego planowania do aktywnego zarządzania procesami związanymi z mitygacją ryzyka oraz ciągłością działania systemów krytycznych.
Wdrożenie skutecznego planu
Pierwszym krokiem w tworzeniu planu ciągłości działania jest powołanie interdyscyplinarnego zespołu złożonego z przedstawicieli każdego działu firmy. Zespół ten powinien mieć lidera odpowiedzialnego za koordynację działań oraz jego zastępcę, który przejmie obowiązki w razie nieobecności lidera. Warto zadbać o to, aby w zespole znalazła się też osoba ze ścisłego kierownictwa. Każdy dział organizacji powinien być reprezentowany przez co najmniej jednego pracownika, aby zapewnić, że żaden istotny obszar nie zostanie pominięty i będzie mógł działać w przypadku awarii. Członkowie zespołu będą pełnić funkcję ambasadorów projektu w swoich działach, zajmując się szkoleniem reszty zespołu, identyfikacją procesów i ustalaniem standardów planu.
Pierwszym zadaniem dla zespołu powinna być analiza ryzyka (Risk Analysis; dalej: RA). To zadanie obejmuje kompleksową identyfikację zagrożeń, ocenę ich skali oraz prawdopodobieństwa wystąpienia. Analiza ryzyka pozwala zidentyfikować działania, które mogą mieć najgorsze skutki dla organizacji, i umożliwia przygotowanie się na nie. Ważnym, choć czasem pomijanym, elementem analizy ryzyka jest ocena i sprawdzenie podatności firmy na ataki hakerskie i ransomware.
Kolejne zadanie to analiza wpływu na biznes (Business Impact Analysis; dalej: BIA), która ocenia finansowe, operacyjne i fizyczne skutki przerwania procesów lub usług. Pomaga to zrozumieć rodzaje ryzyk i zagrożeń związanych z działalnością operacyjną, reputacją jst, zaufaniem obywateli do organów samorządu, pracownikami oraz łańcuchami dostaw. Analiza ta może skupiać się na zależnościach w łańcuchu dostaw, minimalnym czasie potrzebnym do przywrócenia działalności operacyjnej oraz minimalnej liczbie personelu potrzebnego do utrzymania ciągłości działania w firmie. Dzięki dokładnej analizie BIA jst może zidentyfikować kluczowe obszary konieczne do utrzymania ciągłości funkcjonowania systemów IT. Analizowane są nie tylko procesy, ale również lokalizacje, pracownicy i usługi. W analizie stosuje się dwa kluczowe wskaźniki: RTO (Recovery Time Objective), określający czas potrzebny na odtworzenie procesów po awarii, oraz RPO (Recovery Point Objective), który odnosi się do akceptowalnego poziomu utraty danych sprzed awarii. Po przeprowadzeniu analizy RA i BIA firma będzie w stanie określić najważniejsze obszary dla zapewnienia ciągłości biznesowej, na których należy skoncentrować się podczas opracowywania planu.
Następnie można opracować plan ciągłości działania we współpracy z przedstawicielami wszystkich działów, który będzie zawierał szczegółowe elementy pozwalające organizacji na skuteczne zarządzanie i przywrócenie działalności po przerwie. Szczegółowy i dobrze zorganizowany plan ciągłości działania zapewnia, że organizacja jest przygotowana na nieprzewidziane przerwy i może szybko wrócić do normalnego funkcjonowania.
Odzyskiwanie systemu po awarii
Przy tworzeniu BCP nie można zapominać o planie odzyskiwania po awarii (Disaster Recovery Plan; dalej: DRP). Obejmuje on zestaw procedur niezbędnych do przywrócenia systemu w sytuacji awaryjnej – uwzględnia różne scenariusze awarii, takie jak problemy we własnym centrum danych, awarie u dostawcy usług czy poważne błędy systemowe. Celem DRP jest jak najszybsze „postawienie systemu na nogi” po awarii, co pozwala na odzyskanie dostępu do danych. Plan odzyskiwania po awarii stanowi kluczowy element BCP i zawiera konkretne kroki do wdrożenia w sytuacji kryzysowej, dlatego w jego opracowywanie powinny być zaangażowane osoby odpowiedzialne za kluczowe aspekty działania jst. Dzięki dobrze przygotowanemu DRP można zminimalizować czas niedostępności systemu oraz ograniczyć straty. Warto zaznaczyć, że DRP obejmuje m.in. procedury odzyskiwania danych z backupu.
Kolejnym etapem wdrażania sprawnie działającego BCP jest testowanie. Dokumentacja planu to tylko początek – oszczędzanie na testowaniu może prowadzić do złudnego poczucia bezpieczeństwa. Każda jst powinna mieć plan ciągłości działania, jednak nie może on pozostawać zbyt długo nieużywany. Kluczowym elementem BCP jest więc regularne testowanie proponowanych rozwiązań, co umożliwia sprawdzenie, czy plan rzeczywiście działa i czy pracownicy są w stanie przestrzegać ustalonych procedur. Testowanie BCP pozwala na ocenę skuteczności zespołu, weryfikację koordynacji działań oraz dopracowanie poszczególnych elementów planu.
Wszystkie osoby odpowiedzialne za testowanie BCP czy DRP mogą zrobić prosty test polegający na prawdziwej symulacji uruchomienia procedur przez kierownictwo jst bez udziału głównego informatyka. Często w trakcie testowania planów BCP okazuje się bowiem, że nie wiadomo, kto ma klucze do budynku, jaki jest kod do alarmu, zapasowe pomieszczenie do odtworzenia serwerowni nie istnieje, bo zostało zaadaptowane i udostępnione zewnętrznej organizacji, a w zapasowej lokalizacji nie ma przyłącza z energią elektryczną. Dodatkowo podczas takiego testu może się okazać, że podczas wystąpienia awarii, np. zalania (uszkodzenia rury z bieżącą wodą i wyciekającej wody) nie wiadomo, kogo powiadomić, do kogo zadzwonić po pomoc itp.
Powtarzające się problemy
Przeprowadzając audyty DRP w większych i mniejszych jednostkach, można spotkać się z kilkoma powtarzającymi się obszarami do poprawy. Brak opracowanych i wdrożonych planów kopii zapasowych, bez których nie wiadomo, gdzie są przechowywane kopie zapasowe. W stresującej sytuacji informatyk błądzi myślami i szuka na udziałach sieciowych katalogu „Backup”. Po odnalezieniu okazuje się, że kopia zapasowa jest bezpieczna i zaszyfrowana, ale niestety hasło było ustalone trzy lata temu i nikt go nie pamięta, a w dokumentacji brak wpisu. Po długich godzinach odzyskiwania hasła metodą brute force okazuje się, że przy rozpakowaniu w powłoce systemu operacyjnego archiwum zgłasza błąd plików. Po wnikliwej analizie okazuje się, że rozwiązaniem jest użycie dearchiwizatora producenta oprogramowania do backupu. Po rozpakowaniu brakuje plików, np.: poczta@urzad.pst. Przyczyną jest zła konfiguracja lub brak działającej usługi Volume Shadow Copy. W trakcie wykonywania kopii zapasowej program nie potrafił skopiować otwartego pliku w programie pocztowym. Kolejnym problemem okazuje się okno czasowe do wykonania kopii zapasowych. Często przyjmujemy uśrednioną wartość, np.: pół godziny na kopię pulpitu i dokumentów. Użytkownicy potrafią odłożyć na pulpicie katalog zawierający 1000 zdjęć i filmów, co znacząco wydłuży czas wykonywania kopii zapasowych. Jeśli godzina rozpoczęcia procesu kopii jest ustawiona na 30 minut przed końcem pracy, a kopia nie zdąży się wykonać w całości i zostać wysłana do godz. 16:00, to nieświadomy problemu użytkownik wyłączy komputer wraz z końcem pracy. Programy do wykonywania kopii zgłaszają błędy poprzez zmianę koloru ikony, wysyłają wiadomości email z opisem błędów itp. Niestety, użytkownicy ignorują takie ostrzeżenie i finalnie okazuje się, że kopia nie wykonuje się od miesięcy.
Kolejnym problemem jest prawidłowa konfiguracja samego programu do kopii zapasowych. Zdarzają się błędnie wpisane ścieżki katalogów źródłowych i kopiują się zasoby nie tego użytkownika lub wskazana jest ścieżka docelowa do nieistniejącego udziału. Może się też okazać, że przy wysyłce danych przez FTP administrator zmienił hasło dla użytkownika do wysyłki kopii, ale w programach pozostało stare hasło. Ustawiona zbyt duża liczba pełnych kopii zapasowych do przechowywania powoduje zapełnienie udziału, a w konsekwencji brak kopii z całej jednostki. Maksymalne zapełnienie przestrzeni dyskowej w popularnych serwach plików uniemożliwia ich usunięcie z poziomu FTP lub SMB i wymaga logowania się przez SSH do powłoki systemu.
Aktualizacja procedur
Cykliczne sprawdzanie poprawności planów ciągłości działania z uwzględnieniem DRP w środowisku testowym, poprzez pełne odtworzenie danych wraz z uruchomieniem usług i sprawdzeniem poprawności działania, minimalizuje ryzyko wystąpienia wcześniej wymienionych problemów i pozwala skutecznie unikać incydentów związanych z utratą danych.
Procedury zawarte w planie muszą być na bieżąco aktualizowane i dostosowywane do szybko zmieniających się realiów środowiskowych oraz nowych technologii. Ważne jest także regularne szkolenie nowych menedżerów i pracowników. Systematyczne aktualizowanie planu jest niezbędne, aby skutecznie chronić firmę przed awariami i innymi zagrożeniami. Tworząc, utrzymując i doskonaląc System Zarządzania Ciągłością Działania, organizacja nie tylko zabezpiecza swoje korzyści i interesy, ale także dba o interesy swoich partnerów biznesowych i klientów. Przekazuje w ten sposób jasny komunikat, że w przypadku problemów i zakłóceń można na niej polegać i że jest wiarygodnym partnerem. Mając na uwadze zapisy dyrektywy Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii, zmieniającej rozporządzenie (UE) nr 910/2014 i dyrektywę (UE) 2018/1972 oraz uchylającej dyrektywę (UE) 2016/1148 (dyrektywa NIS 2) (DzUrz UE L 333 z 27.12.2022) i wytyczne dotyczące zachowania bezpieczeństwa łańcucha dostaw, należy wymagać od partnerów jst, aby również w odpowiedni sposób zabezpieczali swoje zasoby krytyczne.
Wskazane czynności i działania są niezbędnym elementem w systemie zarządzania ciągłością działania. Wymagają zaangażowania i dużych nakładów pracy wielu osób, w szczególności działu IT urzędu. Obsługa bieżąca użytkowników często odsuwa opisane czynności na dalszy plan, co w konsekwencji może spowodować poważne problemy w kryzysowej sytuacji i utratę wizerunku organizacji.
Autor
Witold Bzdęga
Autor od blisko 20 lat jest informatykiem w administracji samorządowej, a dodatkowo wspiera jednostki oświaty, kultury i opieki społecznej. Od wielu lat szkoli pracowników różnych podmiotów w zakresie cyberbezpieczeństwa. Interesuje się problematyką ochrony informacji, mitygacji ryzyka, rolą samorządów w budowie społeczeństwa informacyjnego i informatycznymi rozwiązaniami usprawniającymi pracę urzędów.
