disaster recovery (DR)

Disaster recovery (DR) to planowanie i przeprowadzanie technicznego odtworzenia systemów, danych i infrastruktury po poważnej awarii albo katastrofie. NIST definiuje plan DR (DRP, disaster recovery plan) jako spisany plan odtworzenia jednego lub więcej systemów informatycznych w zapasowym obiekcie, w odpowiedzi na poważną awarię sprzętu lub oprogramowania albo zniszczenie infrastruktury ^[1]. Polski słownik NSC 7298 tłumaczy DRP jako „plan odtworzenia po katastrofie” i odsyła do planu ciągłości działania ^[3]. Disaster recovery jest węższe od planu ciągłości: dotyczy systemów, a nie procesów całej organizacji.

Jak działa

Przewodnik NIST SP 800-34 opisuje DRP jako plan skupiony na systemach, który ma przywrócić działanie systemu, aplikacji albo ośrodka obliczeniowego w zapasowej lokalizacji po sytuacji nadzwyczajnej ^[2]. Według przewodnika DRP obejmuje tylko te zakłócenia, które wymagają przeniesienia ^[2]. Po przeniesieniu każdy system odtwarza się według własnego planu awaryjnego (ISCP) ^[2].

SP 800-34 dzieli działania po awarii na trzy fazy ^[2]:

• aktywacja i powiadomienie — decyzja o uruchomieniu planu na podstawie skutków przestoju i zawiadomienie zespołu;
• odtwarzanie — przywrócenie działania w zapasowej lokalizacji albo z użyciem zasobów awaryjnych;
• rekonstytucja — testy i sprawdzenie działania, powrót do normalnej pracy i przygotowanie na kolejne awarie ^[2].

Kolejność tych faz pokazuje schemat poniżej.

RYS. 1Fazy odtwarzania według SP 800-34

Ramy czasowe wyznaczają dwa parametry: RTO, czyli dopuszczalny czas przestoju, i RPO, czyli dopuszczalna utrata danych. Oba ustala się w analizie wpływu na działalność.

Rodzaje zapasowych lokalizacji

SP 800-34 wymienia trzy typowe rodzaje zapasowych ośrodków, uporządkowane według gotowości do pracy, oraz dwa warianty ^[2].

Dla strony internetowej odpowiednikiem zimnej lokalizacji jest kopia i konto u drugiego dostawcy, na którym dopiero trzeba postawić serwis. Gorącą lokalizacją jest serwer zapasowy z aktualną kopią, gotowy do przełączenia.

W prawie

Prawo Unii używa własnych nazw. Rozporządzenie wykonawcze 2024/2690 do dyrektywy NIS2 mówi o „planie ciągłości działania i przywrócenia normalnego działania po wystąpieniu sytuacji nadzwyczajnej” ^[5]. Wymaga planów tworzenia kopii zapasowych, które określają czas przywrócenia, kompletność kopii, w tym danych konfiguracyjnych, oraz przechowywanie kopii poza siecią systemu i w odległości chroniącej przed szkodą w głównej lokalizacji ^[5]. Nakazuje też regularne testy odzyskiwania kopii i dokumentowanie ich wyników ^[5].

DORA mówi o „planach reagowania i przywracania sprawności ICT” ^[4]. Przy odtwarzaniu danych z kopii na własnych systemach podmiot finansowy ma korzystać z systemów oddzielonych fizycznie i logicznie od głównego systemu ICT ^[4]. Plany trzeba testować co najmniej raz w roku oraz po istotnych zmianach w systemach wspierających krytyczne funkcje ^[4].

W WordPressie

Na stronach WordPress disaster recovery sprowadza się zwykle do odtworzenia serwisu z kopii zapasowej (backup) na tym samym albo nowym serwerze. Dokumentacja WordPressa przypomina, że kopia plików nie obejmuje bazy danych, bo baza działa w osobnym systemie, najczęściej MySQL albo MariaDB ^[6]. Zaleca kolejność: przy tworzeniu kopii najpierw baza, potem pliki; przy odtwarzaniu najpierw pliki, potem import bazy ^[6]. Jeśli dane dostępowe do bazy się zmieniły, trzeba je poprawić w wp-config.php ^[6].

Dokumentacja radzi też trzymać 3–5 ostatnich kopii w różnych miejscach ^[6]. Kopia leżąca wyłącznie na tym samym serwerze nie pomoże, gdy padnie serwer albo gdy ransomware zaszyfruje cały katalog konta. Chroni przed tym kopia niezmienna (immutable backup).

Po włamaniu odtworzenie ma dodatkowy krok. Poradnik WordPress.org nazywa kopie krytycznym elementem ciągłości działania i zaleca, by przed sprzątaniem wykonać jeszcze jedną kopię zainfekowanego środowiska jako materiał odniesienia ^[7]. Zaleca też zmianę haseł do wszystkich punktów dostępu, w tym FTP i SFTP, panelu WordPressa, panelu hostingu i bazy MySQL ^[7]. Bez tego odtworzona strona wraca z tą samą tylną furtką (backdoor) i tymi samymi skradzionymi hasłami. Szerzej opisuje to czyszczenie przejętej strony.

Dobre praktyki

• Opisać procedurę odtworzenia krok po kroku: gdzie są kopie, kto ma do nich dostęp, w jakiej kolejności przywracać pliki i bazę ^[6].
• Trzymać kopie poza siecią serwera produkcyjnego, jak wymaga tego rozporządzenie 2024/2690 dla objętych nim podmiotów ^[5].
• Regularnie sprawdzać odtwarzanie na środowisku testowym (staging). SP 800-34 zaleca, by ćwiczenia dla systemów o średnim znaczeniu obejmowały odtworzenie systemu z kopii ^[2].
• Włączyć plan DR do reagowania na incydenty, żeby decyzja o odtworzeniu zapadała w ustalonym trybie.
• Po odtworzeniu sprawdzić logowanie, formularze i płatności, zanim przywrócenie działania uzna się za zakończone.

Historia i przykłady

SP 800-34 Rev. 1 ukazał się w maju 2010 roku ^[2]. Nowsza definicja w słowniku NIST, pochodząca z CNSSI 4009-2022, opisuje DRP jako drugi plan używany przez zarządzających ryzykiem, stosowany, gdy organizacja musi w swoich pierwotnych obiektach odzyskać utraconą zdolność działania w okresie godzin lub dni ^[1]. Polski odpowiednik „plan odtworzenia po katastrofie” podaje słownik NSC 7298 z 1 września 2021 roku ^[3].