Disaster Recovery w energetyce nie powinien ograniczać się do wykonywania kopii zapasowych. Skuteczny plan DR musi uwzględniać procesy krytyczne, zależności IT/OT, RTO i RPO, konfiguracje SCADA, PLC i DCS, role decyzyjne, bezpieczeństwo odtwarzanego środowiska oraz regularne testy. Jego celem jest nie tylko odzyskanie systemów, ale przede wszystkim bezpieczne przywrócenie krytycznych funkcji technologicznych.
W sektorze energetycznym zapewnienie ciągłości działania jest jednym z kluczowych elementów bezpieczeństwa i niezawodności infrastruktury krytycznej. Rosnąca złożoność środowisk technologicznych, integracja systemów IT i OT oraz rozwijające się zagrożenia cybernetyczne sprawiają, że organizacje muszą być przygotowane nie tylko do zapobiegania incydentom, ale również do reagowania na zakłócenia i bezpiecznego odtwarzania krytycznych procesów.
Skuteczny Plan Disaster Recovery dla zakładu energetycznego powinien określać, które procesy oraz systemy IT i OT należy odtworzyć w pierwszej kolejności, kto podejmuje decyzje, z jakich kopii zapasowych można skorzystać, jakie są wymagane czasy odtworzenia oraz w jaki sposób bezpiecznie przywrócić proces technologiczny.
Istotną rolę w budowaniu takiej odporności odgrywają Plany Ciągłości Działania, czyli PCD lub BCP. Pozwalają one zidentyfikować procesy krytyczne, określić dopuszczalne skutki i czas trwania zakłóceń oraz zaplanować działania niezbędne do utrzymania funkcjonowania zakładu w sytuacji awaryjnej.
Integralnym elementem tego podejścia jest Disaster Recovery, czyli planowanie i realizacja odtwarzania infrastruktury technicznej, systemów informatycznych i technologicznych oraz danych niezbędnych do przywrócenia normalnego funkcjonowania organizacji.
Wartość dobrze przygotowanych i regularnie testowanych planów PCD i DR wykracza poza spełnienie wymagań normatywnych. To przede wszystkim:
- większa przewidywalność działań w sytuacji kryzysowej,
- ograniczenie czasu przestoju,
- lepsza koordynacja zespołów IT, OT i utrzymania ruchu,
- ochrona integralności systemów i danych,
- możliwość bezpiecznego przywrócenia kluczowych funkcji technologicznych.
Czym różni się Plan Ciągłości Działania od Disaster Recovery?
Plan Ciągłości Działania, określany również jako Business Continuity Plan, odpowiada na pytanie:
Jak organizacja utrzyma najważniejsze procesy na akceptowalnym poziomie podczas zakłócenia?
Disaster Recovery odpowiada natomiast na pytanie:
Jak odtworzyć systemy, dane i infrastrukturę techniczną niezbędne do przywrócenia zakłóconych procesów?
Plan Ciągłości Działania, czyli BCP lub PCD, określa sposób utrzymania najważniejszych procesów podczas awarii, cyberataku albo niedostępności infrastruktury. Disaster Recovery koncentruje się na odtworzeniu zasobów technicznych, w tym:
- systemów IT,
- systemów OT i ICS,
- infrastruktury komunikacyjnej,
- serwerów i baz danych,
- systemów SCADA i DCS,
- stacji inżynierskich,
- konfiguracji sterowników PLC,
- danych i dokumentacji technicznej.
W zakładzie energetycznym PCD może przewidywać przejście do lokalnego sterowania lub alternatywnego sposobu prowadzenia procesu technologicznego. Plan DR musi natomiast określać, jak bezpiecznie odtworzyć systemy sterowania, serwery SCADA, bazy danych, stacje inżynierskie czy konfiguracje sterowników PLC.
Oba plany muszą być ze sobą ściśle powiązane.
Nie można skutecznie zaplanować odtwarzania infrastruktury bez wcześniejszego ustalenia, które procesy są krytyczne i jak długo mogą pozostawać niedostępne.
Od czego rozpocząć przygotowanie planu Disaster Recovery?
Podstawą przygotowania planów ciągłości działania i Disaster Recovery powinna być analiza wpływu na działalność, czyli Business Impact Analysis, uzupełniona oceną ryzyka.
BIA pozwala:
- zidentyfikować procesy krytyczne,
- określić skutki ich niedostępności,
- ustalić priorytety odtwarzania,
- rozpoznać zależności pomiędzy procesami, systemami i dostawcami,
- określić wymagane zasoby,
- zdefiniować akceptowalny czas zakłócenia.
Na podstawie wyników BIA i oceny ryzyka należy opracować scenariusze utraty ciągłości działania, które uwzględniają specyfikę infrastruktury, występujące zagrożenia oraz konsekwencje zakłócenia krytycznych procesów technologicznych.
W zakładzie energetycznym scenariusze mogą obejmować między innymi:
- awarię serwerów lub infrastruktury sieciowej,
- niedostępność systemu SCADA lub DCS,
- utratę stacji inżynierskiej,
- uszkodzenie lub błędną konfigurację sterownika PLC,
- awarię centrum danych,
- niedostępność kluczowego dostawcy,
- utratę łączności pomiędzy lokalizacjami,
- zaszyfrowanie systemów przez ransomware,
- kompromitację kont uprzywilejowanych,
- zniszczenie lub modyfikację kopii zapasowych,
- awarię zasilania lub infrastruktury technicznej,
- brak dostępności kluczowego personelu.
W sektorze energetycznym szczególne znaczenie ma uwzględnienie wzajemnych zależności pomiędzy systemami IT i OT, infrastrukturą techniczną, personelem oraz dostawcami usług.
Scenariusze powinny obejmować nie tylko bezpośrednie skutki awarii lub cyberataku, lecz również potencjalny wpływ na bezpieczeństwo ludzi, środowisko, ciągłość dostaw oraz możliwość bezpiecznego przywrócenia procesu technologicznego.
Jak wyznaczyć priorytety odtwarzania systemów IT i OT?
Jednym z najważniejszych rezultatów analizy BIA jest ustalenie priorytetów procesowych oraz parametrów odtworzeniowych.
W praktyce wykorzystuje się między innymi dwa podstawowe parametry:
RTO – Recovery Time Objective
RTO określa docelowy czas przywrócenia procesu, usługi lub systemu po wystąpieniu zakłócenia.
RPO – Recovery Point Objective
RPO określa maksymalny akceptowalny okres utraty danych, wyrażony w czasie. Parametr ten wskazuje, do jakiego momentu organizacja musi być w stanie odtworzyć dane po awarii.
Przykładowo system nadzoru technologicznego może wymagać znacznie krótszego czasu odtworzenia niż system administracyjny. Nie oznacza to jednak, że priorytety powinny być wyznaczane wyłącznie na poziomie poszczególnych aplikacji.
W środowisku OT samo określenie RTO i RPO nie wystarczy. Należy również uwzględnić:
- zależności pomiędzy systemami,
- dostępność infrastruktury sieciowej i komunikacyjnej,
- kolejność uruchamiania komponentów,
- integralność konfiguracji,
- wymagane wersje oprogramowania i firmware’u,
- procedury walidacji,
- warunki bezpiecznego ponownego uruchomienia instalacji.
Priorytetem powinno być przywrócenie krytycznej funkcji technologicznej, a nie wyłącznie pojedynczego systemu informatycznego.
Czy backup wystarczy do zapewnienia Disaster Recovery?
Nie. Backup jest koniecznym elementem strategii Disaster Recovery, ale sam nie zapewnia możliwości bezpiecznego odtworzenia działalności.
Regularne wykonywanie kopii zapasowych to podstawa planu DR. W infrastrukturze energetycznej zakres backupu powinien jednak wykraczać poza tradycyjne serwery, maszyny wirtualne i bazy danych.
Kopie zapasowe powinny obejmować również:
- konfiguracje sterowników PLC,
- konfiguracje systemów DCS i SCADA,
- projekty aplikacji operatorskich,
- konfiguracje urządzeń sieciowych,
- ustawienia zabezpieczeń,
- konfiguracje stacji inżynierskich,
- dokumentację techniczną,
- licencje,
- pliki instalacyjne,
- właściwe wersje oprogramowania i firmware’u.
Istotne jest również zabezpieczenie kopii przed modyfikacją, zaszyfrowaniem lub usunięciem podczas cyberataku. W zależności od środowiska może to wymagać zastosowania izolacji, przechowywania kopii offline, separacji uprawnień albo mechanizmów niezmienności danych.
Podczas audytu weryfikacji powinna podlegać nie tylko regularność tworzenia kopii zapasowych, lecz także:
- kompletność backupu,
- integralność danych,
- dostępność kopii,
- odporność kopii na kompromitację,
- sposób zarządzania uprawnieniami,
- możliwość odtworzenia wymaganych wersji systemów,
- skuteczność procesu przywracania,
- zgodność rzeczywistych czasów odtworzenia z założonymi wartościami RTO.
Jak połączyć zarządzanie incydentem z procedurami Disaster Recovery?
Poważny incydent wymaga skoordynowania działań zespołów cyberbezpieczeństwa, IT, OT, utrzymania ruchu oraz kierownictwa zakładu.
Procedury powinny jednoznacznie określać:
- kto podejmuje decyzję o aktywacji PCD i DR,
- kiedy incydent techniczny staje się sytuacją kryzysową,
- kto odpowiada za izolację zagrożonych systemów,
- jak zabezpieczane są dowody i informacje o incydencie,
- w jaki sposób organizacja zapewni alternatywną komunikację,
- kto odpowiada za poszczególne etapy odtwarzania,
- kto zatwierdza ponowne uruchomienie instalacji technologicznej.
W przypadku cyberataku szczególnie ważne jest rozdzielenie trzech etapów:
- ograniczenia i izolacji zagrożenia,
- analizy zakresu kompromitacji,
- właściwego odtwarzania systemów i danych.
Przywrócenie systemu z backupu bez wcześniejszego potwierdzenia bezpieczeństwa środowiska może doprowadzić do ponownej kompromitacji. Jeżeli źródło incydentu nadal pozostaje aktywne albo wykorzystana luka nie została usunięta, odtworzony system może zostać ponownie zaatakowany.
W sektorze energetycznym decyzja o powrocie do pracy produkcyjnej musi uwzględniać zarówno wymagania cyberbezpieczeństwa, jak i bezpieczeństwa procesowego oraz technologicznego.
Jak testować Plan Disaster Recovery w środowisku OT?
Zgodnie z podejściem ISO 22301 Plan Disaster Recovery powinien być regularnie testowany przez organizacje. Dopiero test pozwala ocenić, czy organizacja rzeczywiście potrafi odtworzyć systemy, dane i procesy w założonym czasie.
W praktyce warto stosować kilka poziomów weryfikacji.
Ćwiczenia typu tabletop
Są to symulacje sytuacji kryzysowej prowadzone z udziałem osób odpowiedzialnych za podejmowanie decyzji. Pozwalają sprawdzić role, odpowiedzialności, sposób eskalacji, komunikację oraz kryteria aktywacji planów.
Testy techniczne
Obejmują odtwarzanie danych, konfiguracji lub wybranych systemów w kontrolowanym i odizolowanym środowisku.
Ćwiczenia zintegrowane
Pozwalają sprawdzić współdziałanie zespołów IT, OT, utrzymania ruchu, cyberbezpieczeństwa, komunikacji i zarządzania kryzysowego.
W środowisku OT testy muszą być prowadzone w sposób kontrolowany, bez narażania bezpieczeństwa ludzi, instalacji i ciągłości procesu technologicznego. Część scenariuszy powinna być weryfikowana na systemach testowych, symulatorach lub w środowiskach odseparowanych od produkcji.
Każde ćwiczenie powinno zakończyć się raportem obejmującym:
- rzeczywisty czas odtworzenia,
- porównanie wyniku z zakładanym RTO,
- zakres odzyskanych danych,
- wykryte problemy techniczne i organizacyjne,
- brakujące zasoby lub kompetencje,
- wnioski,
- działania doskonalące,
- właścicieli działań i sposób ponownej weryfikacji.
Jakie są najczęstsze błędy w planach PCD i Disaster Recovery?
Z perspektywy audytorskiej szczególnie istotne są poniższe problemy. Mogą one prowadzić do ustaleń audytowych, a w określonych okolicznościach również do stwierdzenia niezgodności z wymaganiami systemu zarządzania ciągłością działania.
-
Nieadekwatne scenariusze utraty ciągłości działania
Scenariusze awaryjne nie wynikają z przeprowadzonej analizy ryzyka i rzeczywistych zależności technologicznych. W efekcie nie uwzględniają zagrożeń specyficznych dla infrastruktury zakładu oraz skutków zakłócenia krytycznych procesów.
-
Brak regularnych testów PCD i Disaster Recovery
Organizacja posiada opracowane plany, ale nie prowadzi cyklicznych ćwiczeń i testów potwierdzających ich skuteczność.
W rezultacie nie wiadomo, czy procedury, zasoby i zakładane czasy odtworzenia pozwolą na rzeczywiste przywrócenie krytycznych procesów w sytuacji awaryjnej.
-
Niepełny zakres kopii zapasowych
Organizacja nie posiada kompletnych kopii środowiska IT i OT, obejmujących wszystkie systemy, dane, konfiguracje i komponenty niezbędne do odtworzenia krytycznych procesów technologicznych.
-
Brak potwierdzenia możliwości odtworzenia
Kopie zapasowe są wykonywane, ale organizacja nie weryfikuje regularnie ich integralności ani możliwości skutecznego przywrócenia środowiska.
-
Nieaktualna dokumentacja
Plany nie uwzględniają zmian infrastruktury, konfiguracji, zależności technologicznych, dostawców, personelu lub struktury organizacyjnej.
-
Niejasny podział odpowiedzialności
Nie określono, kto aktywuje plan, kto odpowiada za izolację systemów, kto podejmuje decyzje techniczne i kto zatwierdza powrót instalacji do normalnej pracy.
-
Brak udokumentowanego doskonalenia
Ćwiczenia wykazują problemy, ale działania naprawcze nie są skutecznie realizowane ani ponownie weryfikowane.
Z perspektywy audytorskiej kluczowe znaczenie ma nie tylko formalna zgodność PCD i DR z wymaganiami normy ISO 22301. Najważniejsza jest możliwość potwierdzenia, że wdrożone rozwiązania zapewniają organizacji rzeczywistą zdolność do utrzymania i odtworzenia krytycznych procesów.
Disaster Recovery a NIS2. Jakie znaczenie ma ciągłość działania?
Dyrektywa NIS2 wymienia ciągłość działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii oraz zarządzanie kryzysowe wśród środków zarządzania ryzykiem cyberbezpieczeństwa. Energetyka znajduje się natomiast wśród sektorów o wysokiej krytyczności objętych zakresem regulacji. [eur-lex.europa.eu], [eur-lex.europa.eu]
ISO 22301 zapewnia ramy do budowania i doskonalenia systemu zarządzania ciągłością działania. NIS2 wzmacnia natomiast znaczenie ciągłości działania i odtwarzania po incydencie jako elementów zarządzania ryzykiem cyberbezpieczeństwa.
Rzeczywista odporność zakładu nie wynika jednak z samego posiadania certyfikatu, dokumentacji czy technologii backupowych. Powstaje poprzez połączenie:
- procesów,
- ludzi i kompetencji,
- systemów IT i OT,
- procedur reagowania,
- bezpiecznych kopii zapasowych,
- komunikacji kryzysowej,
- regularnie testowanych zdolności odtworzeniowych.
W infrastrukturze krytycznej najważniejsze pytanie nie brzmi:
„Czy mamy Plan Disaster Recovery?”
Znacznie ważniejsze jest pytanie:
„Czy potrafimy bezpiecznie odtworzyć kluczowe procesy, kiedy naprawdę przestaną działać?”
Właśnie na to pytanie powinien odpowiadać skutecznie przeprowadzony audyt ciągłości działania i Disaster Recovery.
Jakub Szymecki
Inzynier Projektowy
Audytor Systemów OT
Telefon: +48 451-575-842
E‑mail: Jakub.Szymecki@tt-cs.com.pl
FAQ – Najczęściej zadawane pytania o Disaster Recovery w energetyce
Co to jest Disaster Recovery?
Disaster Recovery to zestaw procedur, zasobów i rozwiązań służących do odtworzenia systemów, danych oraz infrastruktury technicznej po awarii, cyberataku lub innym poważnym zakłóceniu.
Czym różni się Plan ciągłości działania od Disaster Recovery?
Plan ciągłości działania określa, jak organizacja będzie utrzymywać kluczowe procesy podczas zakłócenia. Disaster Recovery opisuje, jak zostaną odtworzone systemy, dane i infrastruktura niezbędne do przywrócenia tych procesów.
Co powinien zawierać Plan Disaster Recovery dla zakładu energetycznego?
Plan powinien określać zakres systemów i procesów, scenariusze awaryjne, priorytety odtwarzania, parametry RTO i RPO, role i odpowiedzialności, sposób aktywacji planu, zasoby techniczne, lokalizacje kopii zapasowych, kolejność odtwarzania oraz sposób testowania procedur.
Jakie dane i konfiguracje należy zabezpieczać w środowisku OT?
Oprócz tradycyjnych danych i serwerów należy uwzględnić konfiguracje PLC, DCS i SCADA, projekty aplikacji operatorskich, ustawienia urządzeń sieciowych, konfiguracje stacji inżynierskich, dokumentację techniczną, licencje oraz właściwe wersje oprogramowania i firmware’u.
Co oznaczają RTO i RPO?
RTO określa docelowy czas przywrócenia procesu lub systemu. RPO określa maksymalny akceptowalny okres utraty danych, wyrażony w czasie.
Jak często należy testować Plan Disaster Recovery?
Częstotliwość powinna wynikać z ryzyka, krytyczności procesów, zmian w środowisku oraz przyjętego programu ćwiczeń. Plan powinien być również ponownie weryfikowany po istotnych zmianach infrastruktury, procesów, dostawców lub organizacji.
Czy odtworzenie systemu z backupu kończy obsługę cyberataku?
Nie. Przed odtworzeniem należy ustalić zakres kompromitacji, ograniczyć zagrożenie i potwierdzić bezpieczeństwo środowiska. W przeciwnym razie odtworzony system może zostać ponownie zaatakowany.
Czy NIS2 wymaga Disaster Recovery?
NIS2 wskazuje ciągłość działania, zarządzanie kopiami zapasowymi, odtwarzanie po awarii oraz zarządzanie kryzysowe jako elementy środków zarządzania ryzykiem cyberbezpieczeństwa. [eur-lex.europa.eu]
