Ciągłość działania w LCC: backup i Disaster Recovery

Aktualności
Zdjęcie przedstawiające komponenty komputera

SOC wykrył ransomware, ale część urzędu została zaszyfrowana. Sprawdź, jak zaplanować backup, RPO, RTO, Disaster Recovery i ciągłość działania LCC.

SOC wykrył ransomware, ale część urzędu została zaszyfrowana. Sprawdź, jak zaplanować backup, RPO, RTO, Disaster Recovery i ciągłość działania LCC.

LCC wykryje cyberatak. Czy urząd potrafi po nim wznowić działanie?

Jest 2:40 w nocy. SOC wykrywa masowe zmiany plików, EDR/XDR izoluje część urządzeń, a zespół blokuje przejęte konto administratora. Rozprzestrzenianie ataku zostaje ograniczone. Mimo tego kilka serwerów i część danych są już zaszyfrowane.

W tym momencie pojawia się pytanie inne niż podczas wykrywania i reakcji: ile czasu potrzebuje urząd, aby ponownie realizować najważniejsze zadania? Zielony raport z backupu nie odpowie, które systemy trzeba uruchomić pierwsze, czy kopia jest bezpieczna ani jak obsługiwać mieszkańców podczas przestoju.

Cyberbezpieczeństwo nie kończy się na zatrzymaniu ataku. SOC, SIEM, XDR, firewall i procedury zmniejszają ryzyko, wykrywają zagrożenia i umożliwiają szybką reakcję, ale żadna organizacja nie może zakładać ich stuprocentowej skuteczności. Potrzebny jest drugi filar: cyber resilience, czyli zdolność do bezpiecznego odtworzenia systemów i kontynuowania działalności po poważnym incydencie.

Ten artykuł uzupełnia główny materiał VigilHorizon: Lokalne Centrum Cyberbezpieczeństwa dla samorządów – jak zbudować je wspólnie i utrzymać po dotacji. Nie powtarza całego programu LCC. Koncentruje się na tym, co ma się wydarzyć po skutecznym ataku, aby urząd odzyskał systemy, dane i zdolność realizacji zadań publicznych.

Co warto wiedzieć

  • Backup nie jest jeszcze ciągłością działania. Kopia danych ma wartość dopiero wtedy, gdy można ją bezpiecznie odtworzyć w określonej kolejności i czasie.
  • Najpierw określa się krytyczność procesów, a dopiero później technologię. Nie każdy system potrzebuje takiego samego poziomu ochrony.
  • RPO i RTO są decyzjami organizacji. Muszą wynikać z wpływu niedostępności na zadania publiczne i zostać potwierdzone w testach.
  • Backup odporny na ransomware wymaga separacji. Przejęcie produkcji nie może automatycznie dawać możliwości zniszczenia ostatniej dobrej kopii.
  • Disaster Recovery odtwarza środowisko IT, a Business Continuity utrzymuje pracę urzędu. Oba plany muszą działać razem.
  • Pięcioletnia trwałość wymaga przewidywalnego TCO. Budżet powinien finansować bezpieczeństwo kopii, monitoring, testy i gotowość specjalistów, a nie tylko odnowienia licencji.

SOC wykrył ransomware. Co dzieje się dalej?

Wykrycie ransomware uruchamia działania ograniczające: izolację urządzeń, blokadę kont, odcięcie komunikacji, zabezpieczenie dowodów i ocenę zakresu incydentu. Celem jest zatrzymanie dalszej kompromitacji. Nie oznacza to jednak, że środowisko jest gotowe do odtworzenia.

Zanim zespół sięgnie po kopie, musi ustalić co najmniej:

  • kiedy prawdopodobnie rozpoczęła się kompromitacja;
  • które konta i systemy zostały przejęte;
  • czy atakujący uzyskał dostęp do infrastruktury backupowej;
  • który punkt w czasie można uznać za bezpieczny;
  • które usługi są najważniejsze dla realizacji zadań urzędu;
  • gdzie powstanie czyste środowisko recovery;
  • kto zatwierdzi przywrócenie systemów do produkcji.

Odtwarzanie rozpoczęte zbyt wcześnie może wprowadzić mechanizm ataku do odbudowanego środowiska. Odtwarzanie bez priorytetów może zużyć czas na systemy mniej ważne, podczas gdy kluczowy proces nadal stoi.

To moment, w którym proces obsługi incydentu przechodzi od ograniczania ataku do bezpiecznego odtworzenia środowiska. Nie ma między tymi etapami ostrej granicy. Incident Response wskazuje prawdopodobne okno kompromitacji i warunki bezpiecznego powrotu, a zespół recovery wykorzystuje te informacje do wyboru właściwego punktu odtworzenia, ustalenia kolejności działań, przeprowadzenia testów i uruchomienia usług.

Dlaczego backup to nie to samo co ciągłość działania?

Wiele samorządów posiada już system backupu. Pytanie „czy wykonujecie backup?” jest jednak znacznie mniej istotne niż: „czy potraficie skutecznie odtworzyć środowisko po całkowitej utracie podstawowej infrastruktury?”

Backup może istnieć, a mimo to:

  • być dostępny dla ransomware;
  • znajdować się w tej samej lokalizacji lub strefie ryzyka;
  • korzystać z tych samych kont administracyjnych i tej samej domeny;
  • nie obejmować wszystkich danych, konfiguracji i systemów;
  • mieć błędną retencję albo uszkodzone punkty przywracania;
  • nigdy nie zostać użyty w pełnym teście;
  • wymagać kilku dni ręcznej pracy przy odtwarzaniu;
  • nie odpowiadać kolejności i zależnościom między usługami.

Pojęcia backup, Disaster Recovery i Business Continuity odpowiadają na różne pytania:

Warstwa Pytanie Oczekiwany rezultat
Backup Czy istnieje możliwa do użycia kopia danych i konfiguracji? Chroniona kopia, właściwa retencja i potwierdzona integralność
Disaster Recovery Jak i w jakiej kolejności ponownie uruchomimy systemy IT? Plan odtworzenia tożsamości, sieci, serwerów, baz, aplikacji i zależności
Business Continuity Jak urząd będzie realizował najważniejsze zadania podczas niedostępności IT? Tryb awaryjny, decyzje, komunikacja, priorytety i procedury zastępcze

„Kopia zapasowa odpowiada na pytanie, czy mamy dane. Dojrzały plan ciągłości odpowiada, jak urząd będzie działał jutro rano, jeżeli dziś w nocy straci całą podstawową infrastrukturę.”

Co wynika z dokumentacji programu LCC?

W minimalnym zakresie zadań wskazano ochronę danych w systemach informacyjnych, w tym:

  • wykonywanie kopii zapasowych logicznie i fizycznie odseparowanych od danych przetwarzanych w systemach;
  • testowanie kompletności kopii;
  • testowanie możliwości odtworzenia danych.

Załącznik odwołuje się również do przepisów obejmujących dokumentowanie, testowanie i utrzymywanie planów ciągłości działania, planów awaryjnych oraz planów odtworzenia działalności. Wprost z minimalnego zadania wynikają więc separacja kopii i testy odtworzenia, natomiast plany DR i BCP tworzą szerszy kontekst prawny oraz operacyjny przywołany w dokumentacji.

Program nie narzuca jednej architektury backupu, konkretnego produktu, określonych wartości RPO/RTO ani takiej samej częstotliwości testów dla wszystkich systemów. Off-site, immutable backup, oddzielna domena zarządzająca czy Infrastructure as Code są rozwiązaniami projektowymi dobieranymi do ryzyka, a nie automatycznie literalnymi wymogami naboru.

Najpierw trzeba wiedzieć, co jest naprawdę krytyczne

Nie wszystkie systemy urzędu wymagają takiego samego poziomu ochrony. Racjonalna architektura zaczyna się od pytania, które zadania publiczne muszą działać i jak długo mogą korzystać z trybu awaryjnego. Dopiero później przypisuje się im systemy, dane, zależności i parametry recovery.

Business Impact Analysis, nawet w uproszczonej formie, powinna wskazać:

  • proces i jego właściciela;
  • maksymalny tolerowany czas zakłócenia;
  • wymagane dane, aplikacje i zależności;
  • minimalny poziom obsługi w trybie awaryjnym;
  • skutki niedostępności;
  • priorytet odtworzenia.

Przykładowa klasyfikacja może wyglądać następująco:

Poziom Charakterystyka Decyzja projektowa
Tier 1 – krytyczny Niedostępność szybko zatrzymuje kluczowe zadania lub powoduje istotne ryzyko Najkrótsze uzasadnione RTO/RPO, najwyższy poziom separacji, częstsze testy i gotowy tryb awaryjny
Tier 2 – ważny Krótki przestój jest możliwy, ale usługa powinna zostać szybko przywrócona Odtworzenie po Tier 1, kontrolowana utrata danych i regularne testy
Tier 3 – pozostały Dłuższa niedostępność nie blokuje najważniejszych procesów Dłuższe cele recovery i niższy koszt ochrony, bez rezygnacji z kopii i dokumentacji

Klasyfikacji nie nadaje się raz na zawsze. Zmiana systemu, integracji, przepisów lub sposobu pracy może zmienić jego krytyczność. Dlatego BIA i przypisanie do tierów trzeba okresowo przeglądać.

RPO i RTO: dwa parametry, które powinien znać urząd

RPO (Recovery Point Objective) odpowiada na pytanie: ile najnowszych danych organizacja może utracić? Jeżeli RPO wynosi 4 godziny, urząd akceptuje możliwość utraty zmian z maksymalnie około czterech godzin poprzedzających incydent.

RTO (Recovery Time Objective) odpowiada na pytanie: jak długo system lub usługa mogą pozostawać niedostępne? Jeżeli RTO wynosi 8 godzin, usługa powinna zostać przywrócona w czasie nieprzekraczającym przyjętego celu.

Parametr Przykład modelowy Co trzeba sprawdzić
RPO = 4 godziny Po odtworzeniu może zabraknąć zmian z ostatnich około czterech godzin Częstotliwość kopii, replikację, spójność aplikacyjną i moment ostatniej czystej kopii
RTO = 8 godzin Usługa powinna wrócić w ciągu ośmiu godzin od uzgodnionego punktu startowego Czas decyzji, przygotowania środowiska, transferu danych, odbudowy zależności, walidacji i dopuszczenia do pracy

Każdy krytyczny system powinien mieć uzasadnione cele RPO i RTO. Trzeba również ustalić, od którego momentu mierzy się RTO i co oznacza „system odtworzony”. Działająca maszyna wirtualna nie oznacza gotowej usługi, jeżeli brakuje tożsamości, sieci, bazy, integracji albo akceptacji właściciela procesu.

RPO i RTO nie są obietnicą z cennika technologii. Są decyzjami organizacji, które architektura, procedury i zespół mają potwierdzić podczas testów. Im krótsze cele, tym zwykle wyższy koszt, dlatego nie należy automatycznie nadawać najwyższego poziomu ochrony wszystkim systemom.

Jak zbudować backup odporny na ransomware?

Atakujący coraz częściej próbuje zniszczyć kopie przed uruchomieniem szyfrowania w produkcji. Dlatego odporność nie może opierać się na jednym zabezpieczeniu. Potrzebny jest model warstwowy.

Kopie lokalne i off-site

Kopia lokalna może przyspieszyć odtworzenie po typowej awarii. Kopia off-site ogranicza ryzyko wspólnej utraty produkcji i backupu. Sama inna lokalizacja nie wystarczy jednak, jeżeli oba środowiska są zarządzane tymi samymi poświadczeniami.

Separacja środowisk, tożsamości i uprawnień

Konta administrujące produkcją nie powinny automatycznie mieć prawa usuwania kopii. Backup wymaga odrębnych ról, silnego uwierzytelniania, MFA, minimalnych uprawnień i kontroli działań uprzywilejowanych.

Niezmienność i kopia offline

Immutable backup lub mechanizmy WORM mogą utrudnić modyfikację i usunięcie kopii w okresie retencji. Kopia offline dodatkowo ogranicza powierzchnię ataku. Żaden z tych mechanizmów nie zwalnia z ochrony kont, konfiguracji, kluczy, retencji i procedury dostępu awaryjnego.

Monitoring infrastruktury backupowej

Należy monitorować nie tylko powodzenie zadań, lecz także nietypowe kasowanie punktów przywracania, zmianę retencji, wyłączenie ochrony, anomalie wolumenu danych, błędy weryfikacji i logowania administracyjne. Zdarzenia z backupu powinny trafiać do procesu obsługi incydentów.

Retencja obejmująca okres sprzed kompromitacji

Najnowsza kopia może zawierać skutki wcześniejszego włamania. Retencja musi umożliwiać wybór odpowiedniego punktu, a Incident Response powinien pomóc ustalić bezpieczny moment odtworzenia.

Ochrona przed przypadkowym i celowym usunięciem

Potrzebne są mechanizmy opóźnionego usuwania, podwójnej akceptacji tam, gdzie ma to uzasadnienie, alerty o zmianach polityk oraz rejestrowanie działań administratorów. Przejęcie jednego konta nie powinno wystarczyć do nieodwracalnego zniszczenia wszystkich kopii.

Najważniejsza zasada brzmi: atakujący, który przejmie środowisko produkcyjne, nie powinien automatycznie uzyskać możliwości zniszczenia ostatniej dobrej kopii danych.

Więcej szczegółów zawiera materiał Jak wygląda architektura backupu odpornego na ransomware.

Disaster Recovery: odtworzenie całego środowiska

Backup odpowiada przede wszystkim na pytanie: „czy mamy kopię danych?”. Disaster Recovery odpowiada: „jak uruchomimy ponownie cały system?”

Pełne odtworzenie środowiska urzędu może obejmować:

  • usługi tożsamości i bezpieczne konta administracyjne;
  • DNS, routing, VPN i segmentację;
  • konfiguracje firewalli i urządzeń sieciowych;
  • serwery fizyczne, hypervisory i maszyny wirtualne;
  • bazy danych oraz ich spójność transakcyjną;
  • systemy dziedzinowe i integracje między nimi;
  • certyfikaty, klucze i konfiguracje aplikacji;
  • walidację techniczną oraz akceptację właściciela procesu.

Kolejność ma znaczenie. Aplikacja może nie wystartować bez bazy, baza bez właściwej tożsamości, a dostęp użytkowników bez DNS i sieci. Plan DR powinien więc zawierać mapę zależności, warunki rozpoczęcia, konkretne kroki, odpowiedzialnych, przewidywane czasy, kryteria akceptacji i procedurę powrotu.

Przy poważnym ransomware potrzebne może być czyste środowisko recovery, ze zweryfikowanymi poświadczeniami, konfiguracjami i obrazami systemów. Przed udostępnieniem użytkownikom usługa powinna przejść test bezpieczeństwa i test biznesowy.

Wiedza o odtwarzaniu nie może znajdować się wyłącznie w głowie jednego administratora. Plan ma być zrozumiały dla zastępcy i wykonalny także wtedy, gdy część zespołu, dokumentacji lub podstawowych kanałów komunikacji jest niedostępna.

Dlaczego test odtworzeniowy jest ważniejszy niż raport „backup OK”?

Zielony raport zwykle potwierdza, że zadanie backupowe zakończyło się bez zgłoszonego błędu. Nie dowodzi, że wszystkie wymagane dane znajdują się w kopii, aplikacja uruchomi się poprawnie, zależności są znane, a zespół osiągnie założone RTO.

Testy warto budować warstwowo:

Poziom testu Co potwierdza Typowy dowód
Odtworzenie pliku lub obiektu Podstawową dostępność i integralność kopii Protokół z wynikiem, czasem i walidacją treści
Odtworzenie maszyny lub bazy Możliwość uruchomienia komponentu i spójność danych Logi, test integralności i osiągnięte parametry
Odtworzenie usługi Działanie aplikacji wraz z zależnościami Scenariusz funkcjonalny zaakceptowany przez właściciela usługi
Pełny test DR Gotowość ludzi, infrastruktury, procedur i komunikacji Raport ćwiczenia, czasy etapów, problemy, decyzje i działania naprawcze
Scenariusz ransomware Recovery po założonej kompromitacji produkcji Potwierdzenie separacji, czysta ścieżka zaufania oraz walidacja bezpieczeństwa i biznesu

Raport z testu powinien wskazać:

  • co rzeczywiście odtworzono;
  • z jakiego punktu i w jakim czasie;
  • czy osiągnięto RPO i RTO;
  • jakie wystąpiły błędy;
  • czy dokumentacja była aktualna;
  • kto zaakceptował wynik;
  • jakie działania naprawcze ustalono i kto jest ich właścicielem.

Częstotliwość testów powinna wynikać z krytyczności, tempa zmian, ryzyka i zobowiązań. Program LCC nie ustanawia jednej częstotliwości dla wszystkich systemów. Test trzeba również powtórzyć po istotnej zmianie architektury, procedury, dostawcy albo po poważnym incydencie.

Praktyczne przygotowanie ćwiczeń rozwija artykuł Czy Twój backup działa? Testy odtworzeniowe w praktyce.

Business Continuity: co urząd robi, zanim IT zostanie odtworzone?

Disaster Recovery dotyczy przede wszystkim odtworzenia infrastruktury IT. Business Continuity określa, jak działa cała organizacja, zanim systemy wrócą do normalnej pracy.

Jeżeli kluczowa usługa będzie niedostępna przez 12 godzin, plan powinien odpowiedzieć:

  • kto aktywuje tryb ciągłości działania;
  • które zadania publiczne mają pierwszeństwo;
  • kto podejmuje decyzje i odpowiada za komunikację;
  • jak informowani są pracownicy, mieszkańcy i jednostki organizacyjne;
  • które operacje można wykonywać ręcznie lub w ograniczonym zakresie;
  • jak rejestrować i później wprowadzić dane z pracy awaryjnej;
  • jak działają kanały komunikacji, jeśli podstawowe zasoby są niedostępne;
  • jakie kryteria pozwalają zakończyć tryb awaryjny.

Procedura zastępcza nie może omijać ochrony danych, zasad dostępu ani rozliczalności. Kartka papieru lub prywatny komunikator mogą wydawać się szybkim rozwiązaniem, ale bez wcześniejszych zasad tworzą nowe ryzyko.

Celem nie jest wyłącznie odtworzenie serwera. Celem jest utrzymanie zdolności urzędu do realizacji zadań publicznych.

Relację między BIA, BCP i DRP szerzej opisuje artykuł Plan Disaster Recovery i Business Continuity Plan – jak połączyć DRP i BCP.

Jak połączyć SOC i Disaster Recovery?

Wspólny proces powinien działać od pierwszego alertu do bezpiecznego wznowienia usług.

Etap Główna odpowiedzialność Rezultat
Detect SOC / VigilHorizon Wykrycie sygnału i utworzenie sprawy
Analyze SOC + właściciele środowiska Ocena zakresu, krytyczności i prawdopodobnego początku kompromitacji
Contain SOC, Incident Response i JST Izolacja urządzeń, kont lub segmentów z kontrolą wpływu na usługi
Eradicate Incident Response + administratorzy Usunięcie mechanizmów ataku, zamknięcie dróg dostępu i przygotowanie czystego recovery
Recover SecureVault + JST Odtworzenie danych, infrastruktury i zależności z właściwego punktu
Restore Business JST + SecureVault Przywrócenie procesów, walidacja usług i kontrolowany powrót użytkowników
Lessons Learned LCC i Partnerzy Aktualizacja detekcji, playbooków, konfiguracji, DRP, BCP i testów

Granice odpowiedzialności trzeba ustalić przed incydentem. SOC może zarekomendować izolację, ale JST ocenia wpływ na zadania publiczne. Zespół recovery odtwarza system, właściciel procesu potwierdza działanie usługi, a kierownictwo decyduje o priorytetach i komunikacji.

Tak powstaje zamknięta pętla. Informacja o przyczynie ataku pomaga wybrać czystą kopię. Problemy ujawnione w recovery poprawiają telemetrię i playbooki. Wynik testu DR aktualizuje BIA oraz cele RPO/RTO.

Jak wykorzystać automatyzację w Disaster Recovery?

Incydent ransomware nie jest dobrym momentem na zastanawianie się, jak odtworzyć infrastrukturę. Kroki powinny być wcześniej przygotowane, udokumentowane i przetestowane. Tam, gdzie jest to możliwe i bezpieczne, automatyzacja może obejmować:

  • harmonogram i kontrolę wykonania kopii;
  • automatyczną weryfikację spójności;
  • testowe uruchamianie wybranych zasobów;
  • alarmowanie o zmianie retencji, błędach i anomaliach;
  • automatyczne raportowanie;
  • skrypty odtworzeniowe;
  • Infrastructure as Code tam, gdzie ma zastosowanie;
  • runbooki z kontrolowanymi punktami decyzyjnymi;
  • zbieranie dowodów z testów;
  • aktualizację dokumentacji po zmianach.

Automatyzacja zmniejsza liczbę ręcznych czynności, skraca czas recovery i ogranicza ryzyko błędu pod presją. Nie wszystko powinno być jednak automatyczne. Wybór punktu odtworzenia, uznanie środowiska za czyste, zmiana kluczy czy zgoda na powrót do produkcji wymagają kontekstu i jasno przypisanej odpowiedzialności.

Automatyzacja ma przyspieszać wykonanie znanych kroków, a nie ukrywać decyzje.

Gdzie open source może ograniczyć koszt utrzymania?

Podobnie jak w warstwie wykrywania i reakcji, rozwiązania ciągłości działania powinny być dobierane na podstawie bezpieczeństwa, funkcjonalności, integracji, kosztu całego cyklu życia, dostępności kompetencji i ryzyka vendor lock-in.

Dojrzałe technologie open source mogą mieć zastosowanie w wybranych elementach monitoringu, orkiestracji, automatyzacji, dokumentowania konfiguracji czy budowy środowiska recovery. Nie należy jednak przyjmować zasady „open source za wszelką cenę”.

Brak opłaty licencyjnej nie oznacza braku kosztu. Trzeba uwzględnić wdrożenie, aktualizacje, utrzymanie, integracje, testy, wsparcie i dostępność osób zdolnych usunąć awarię. Najważniejszy jest TCO w całym okresie trwałości oraz możliwość rzeczywistego utrzymania rozwiązania przez kolejne lata.

Największe ryzyko: technologia, której nie będzie za co utrzymywać

W projekcie dotacyjnym łatwo skoncentrować się na dniu odbioru. Tymczasem prawdziwy test rozpoczyna się po zakończeniu finansowania.

Model niepożądany:

dotacja → drogie rozwiązanie → koniec finansowania → wysokie koszty licencji → ograniczenie zakresu ochrony → brak pieniędzy na testy i specjalistów.

Model preferowany:

analiza potrzeb → racjonalna technologia → automatyzacja → procedury → testy → usługa utrzymaniowa → przewidywalny TCO.

Koszt warstwy ciągłości działania powinien obejmować:

  • pojemność, retencję i wzrost danych;
  • drugą lokalizację lub usługę off-site;
  • transfer danych i łącza potrzebne do odtworzenia;
  • licencje, infrastrukturę i wsparcie;
  • monitoring bezpieczeństwa backupu;
  • cykliczne testy oraz środowisko testowe;
  • personel, dyżury i dostęp do specjalistów;
  • utrzymanie DRP, BCP, skryptów i dokumentacji;
  • ćwiczenia oraz usuwanie problemów wykrytych w testach;
  • plan migracji lub wyjścia od dostawcy.

Po zakończeniu projektu pieniądze powinny finansować przede wszystkim bezpieczeństwo kopii, monitoring, testy, kompetencje, aktualizację procedur i gotowość do odtworzenia – nie wyłącznie przedłużanie licencji.

Dlaczego projekt należy zacząć od audytu ciągłości działania?

Nie należy zakładać, że wszystkie systemy trzeba wymienić. Najpierw trzeba sprawdzić:

  • jakie systemy backupu już istnieją i co faktycznie obejmują;
  • gdzie znajdują się kopie;
  • jakie są retencje;
  • kto posiada uprawnienia administracyjne;
  • czy istnieje kopia off-site;
  • czy kopie są odporne na modyfikację i usunięcie;
  • kiedy wykonano ostatni test odtworzeniowy;
  • jakie RPO i RTO rzeczywiście osiągnięto;
  • czy istnieje aktualny DRP i BCP;
  • czy dokumentację można wykorzystać podczas niedostępności produkcji;
  • czy środowisko recovery i kolejność odtwarzania są znane;
  • czy procedury mogą wykonać co najmniej dwie osoby.

Odpowiedź „nie” nie oznacza automatycznie konieczności zakupu nowej platformy. Może wskazywać na brak procedury, separacji kont, odpowiedniej retencji, dokumentacji, testu albo właściciela. Dopiero GAP Analysis pokazuje, czy lukę można usunąć konfiguracją lub procesem, czy potrzebna jest zmiana technologii.

Pierwszym krokiem może być audyt odporności kopii i zdolności odtworzeniowej, a nie przygotowanie listy produktów.

Jak zapewnić działanie po zakończeniu finansowania?

Projektując warstwę ciągłości działania LCC, od początku trzeba patrzeć na cały pięcioletni okres trwałości. Rozwiązanie powinno być:

  • możliwe do utrzymania technicznie i finansowo;
  • ekonomicznie przewidywalne;
  • udokumentowane i dostępne także poza środowiskiem produkcyjnym;
  • automatyzowane tam, gdzie zmniejsza to ryzyko;
  • regularnie testowane;
  • niezależne od pojedynczej osoby;
  • rozwijane wraz ze zmianami infrastruktury JST;
  • objęte jasnym podziałem odpowiedzialności między Lidera, Partnerów i dostawców;
  • wyposażone w plan migracji oraz wyjścia z usług i licencji.

Trwałość wymaga kalendarza testów, budżetu działań naprawczych, aktualizacji BIA, RPO/RTO, DRP i BCP oraz regularnego raportowania do kierownictwa. Zmiana systemu, dostawcy, sieci lub sposobu pracy powinna uruchamiać przegląd dokumentacji i zależności.

Nie chodzi o stworzenie systemu, który dobrze wygląda w dniu odbioru. Chodzi o zdolność, która pięć lat później nadal pozwoli odtworzyć urząd po poważnym cyberincydencie.

Podstawa formalna i źródła

Treść zweryfikowano na podstawie aktualnych materiałów programu LCC i źródeł technicznych:

Wartości RPO/RTO, częstotliwość testów i architektura muszą wynikać z potrzeb konkretnego partnerstwa. Artykuł ma charakter edukacyjny i nie zastępuje dokumentacji naboru, BIA ani projektu technicznego.

Podsumowanie

SOC może szybko wykryć i ograniczyć ransomware, ale nie gwarantuje, że urząd wznowi pracę. Do tego potrzebne są chronione kopie, właściwy punkt odtworzenia, mapa zależności, czyste środowisko recovery, przetestowany plan DR oraz procedury działania organizacji podczas przestoju.

W modelu LCC wykrywanie, reakcja, odtworzenie i ciągłość działania powinny być projektowane jako jeden proces. Kończy się on dopiero wtedy, gdy systemy są bezpieczne, zadania publiczne ponownie działają, a wnioski z incydentu poprawiają zarówno detekcję, jak i przygotowanie do kolejnego odtworzenia.

Założenia programu, zasady partnerstwa JST, finansowanie, obowiązkowe zadania i model utrzymania po dotacji wyjaśnia główny artykuł VigilHorizon o Lokalnych Centrach Cyberbezpieczeństwa.

Czy Wasz urząd posiada backup, czy rzeczywistą zdolność do odtworzenia? SecureVault może zweryfikować istniejące kopie, ich lokalizację, odporność na ransomware, RPO/RTO, Disaster Recovery, testy i procedury awaryjne. Audyt powinien wskazać zarówno realne luki, jak i elementy obecnej infrastruktury, które warto zachować i wykorzystać w docelowym modelu. Rozpocznijmy od audytu obecnego modelu, aby zaplanować rozwiązanie możliwe do utrzymania również po zakończeniu finansowania.

Najczęściej zadawane pytania (FAQ)

Dowiedz się więcej

Powrót do Aktualności

Kategorie

  • Aktualności
  • Disaster Recovery i ciągłość działania

Zobacz również

Nie wiesz który pakiet jest odpowiedni dla twojej firmy?
Wypełnij krótką ankietę

Wypełnij krótki formularz, a pomożemy Ci wybrać rozwiązanie, które realnie
ochroni Twoją firmę i zapewni jej ciągłość działania nawet w przypadku awarii.