Disaster Recovery Plan — jak zachować spokój podczas katastrofy?

Bez względu na to, jaki system ochrony danych jest stosowany w firmie, nigdy nie ma stuprocentowej pewności, że nie zostaną one utracone. Jedną z najczęstszych przyczyn utraty danych są błędy ludzkie. Nie można ich uniknąć, ale można odpowiednio się przygotować na wypadek niespodziewanej sytuacji kryzysowej. Należy stworzyć plan będący podstawowym dokumentem gwarantującym bezpieczeństwo oraz ciągłość działania przedsiębiorstwa (ang. Disaster Recovery Plan). Plan ten powinien zawierać m.in. opis kroków jakie należy podjąć w sytuacji utraty danych.

Plan bez planu

Z ankiety przeprowadzonej przez Kroll Ontrack wśród 195 administratorów i osób odpowiedzialnych za bezpieczeństwo informatyczne wynika, że jedynie 38 proc. z nich deklaruje posiadanie takiego planu oraz poddaje go regularnym testom. Zaledwie 9 proc. testuje swój plan częściej niż raz na 5 miesięcy, a 29 proc. robi to minimum raz w roku. Dużym problemem, który wyłania się z wyników badania, jest także brak świadomości osób odpowiedzialnych za bezpieczeństwo IT co do tego, jak taki plan powinien wyglądać. Zaledwie 18 proc. respondentów jest absolutnie pewnych, że Disaster Recovery Plan w ich firmie istnieje, a 15 proc. przyznaje, że takiego planu nie ma. Natomiast aż 66 proc. badanych odpowiedziało, że nie mają pewności, czy w ich firmie taki dokument w ogóle powstał.

Kalkulacja ryzyka

Istotnym elementem planu na wypadek awarii jest uwzględnienie kolejności działań. Kalkulację ryzyka związanego z utratą danych należy przeprowadzić, zanim jeszcze do niej dojdzie. Podstawą jest założenie, że w każdej chwili może nastąpić nieoczekiwana i niemożliwa do przewidzenia awaria, o trudnym do oszacowania zasięgu, która może sparaliżować działanie infrastruktury IT i — w konsekwencji — funkcjonowanie całości lub części przedsiębiorstwa. Odpowiednio przygotowany plan pozwoli w momencie awarii systemu uniknąć gorączkowej i chaotycznej akcji ratunkowej. W tym celu trzeba wziąć pod uwagę dwa najważniejsze wskaźniki:

  • RPO (Recovery Point Objective) — wskaźnik ten jest wartością czasu, w jakim firma może sobie poradzić bez dostępu do swoich danych i infrastruktury. Przykładowo w przypadku sklepu internetowego istotne jest rozważenie sytuacji, w której przestaje działać cała infrastruktura IT lub jakaś jej konkretna część, np. klient nie będzie miał dostępu do strony sklepu, pracownicy nie będą mogli realizować zamówień, transakcje nie będą rejestrowane ani realizowane. Na jak długą przerwę w działaniu systemu firma może sobie pozwolić? Jakie będą straty i jaka będzie ich skala?
  • RTO (Recovery Time Objective) — to maksymalny czas, w którym konieczne jest odzyskanie danych i pełne wznowienie działania systemu. W celu oszacowania tego czasu należy wziąć pod uwagę pierwszy wskaźnik, ale również możliwości infrastruktury, pracowników, a także okoliczności, które mogą wystąpić. Trzeba przy tym pamiętać, że zgodnie z wynikami badań 93 proc. przedsiębiorstw, które zmagały się z problemem utraty kluczowych danych dłużej niż dziesięć dni, upadło w ciągu roku od awarii, a aż 50 proc. zbankrutowało od razu.

Dla szacowania obu wskaźników bardzo ważne jest prawidłowe ustalenie potencjalnych kosztów dla przedsiębiorstwa. Istotna jest także odpowiedź na pytanie, kiedy koszty związane z przerwą w świadczeniu usług i/lub z utratą danych staną się dla firmy krytyczne. Oczywiście należy w tym wypadku wziąć pod uwagę wiele czynników. Rozbudowa infrastruktury zabezpieczającej dane minimalizuje ryzyko ich utraty, ale zwiększa koszty obsługi samego systemu. Ponadto istotne jest również zastanowienie się nad tym, jakie rozwiązania będą odpowiednie dla danego sektora. Czasem dobrze jest zainwestować w szybsze i bezpieczniejsze systemy kopii zapasowej, chroniące krytyczne z punktu widzenia działalności firmy procesy, a w innych przypadkach w ogóle zrezygnować z przywracania kopii zapasowej. Zamiast tego można zdecydować się na zlecenie procesu odzyskiwania danych zewnętrznej firmie, która przeprowadzi cały proces szybko i sprawnie.

Sztuka wyboru

Kalkulacja uwzględniona w planie musi opierać się przede wszystkim na uświadomieniu sobie kosztów nieoczekiwanej awarii systemu. Mogą to być między innymi:

  • koszty finansowe związane z utratą klientów, którzy nie mogli skorzystać z usług w trakcie awarii,
  • koszty związane z opóźnieniami w realizacji zamówień,
  • koszty opóźnień związanych z przestojem, wynikające z braku możliwości wykonywania zadań przez pracowników,
  • koszty związane z roszczeniami klientów,
  • straty wizerunkowe i biznesowe.

Z drugiej strony należy oszacować koszty działań, które mają służyć przeciwdziałaniu potencjalnym awariom lub reagowania kryzysowego. Mogą one obejmować między innymi:

  • koszty utrzymywania pracownika lub całego działu zajmującego się ciągłością działania infrastruktury albo koszty związane ze zleceniem tych usług firmie zewnętrznej,
  • koszty infrastruktury technicznej, w tym przeznaczonej na potrzeby kopii zapasowej,
  • koszty ewentualnego odzyskiwania danych w przypadku ich utraty.

Wypadkowa tych czynników powinna pomóc w określeniu priorytetów planu — należy podjąć decyzję, ile środków i wysiłku można przeznaczyć na ochronę przed zagrożeniami, a więc na szeroko pojętą profilaktykę. Istotny jest także wybór krytycznych z punktu widzenia działania firmy elementów, które będą chronione i ratowane w pierwszej kolejności.

Jak stworzyć plan?

Dotychczasowe wskazówki powinny dać podstawę do stworzenia strategii na wypadek niespodziewanej awarii. Należy zbudować listę kluczowych elementów infrastruktury, określić ich priorytet i dla każdego opracować model postępowania na wypadek awarii. Dokumenty Disaster Recovery Plan powinny zawierać następujące elementy:

  • Podział ról i obowiązków — każdy pracownik musi znać pole swojego działania i wiedzieć, co zrobić, gdy zaobserwuje symptomy awarii. Jest to o tyle ważne, że natychmiastowa reakcja pozwoli szybciej opanować sytuację i zmniejszyć szkody.
  • Sposób reagowania na kryzys — należy stworzyć procedurę postępowania w przypadku awarii. Musi ona zostać jak najszybciej wykryta, zdiagnozowana i zgłoszona przełożonemu.
  • Plan naprawczy — scenariuszy awarii może być sporo, ale można wypracować pewne ogólne plany naprawcze, które mogą zostać zastosowane, jeśli będzie to konieczne. Odpowiedni plan powinien zostać jak najszybciej wdrożony.
  • Procedury — każdy z pracowników powinien wiedzieć, co ma robić w przypadku awarii. Ważne jest ścisłe stosowanie się do procedur — pozwoli to uniknąć działań chaotycznych i nieprzemyślanych.
  • Dokumentacja — szczegóły awarii, a także wszystkie działania podjęte w celu jej usunięcia, muszą zostać szczegółowo opisane. Jest to ważne szczególnie w przypadku awarii infrastruktury IT, w której niezbędne będzie skorzystanie z usług firmy odzyskującej dane, gdyż opis sytuacji może znacznie skrócić proces odzyskiwania.
  • Szczegóły systemu — każdy plan naprawczy musi zostać uzupełniony o szczegóły infrastruktury, której dotyczy, a więc pełny spis inwentaryzacyjny wykorzystywanego sprzętu, szczegóły dotyczące konfiguracji systemu, dane dotyczące posiadanych kopii zapasowych (kiedy były aktualizowane, gdzie konkretnie się znajdują, na jakich nośnikach), etc.

Należy pamiętać, że każdy plan naprawczy musi być regularnie testowany, aktualizowany i dostosowywany do zmieniającej się infrastruktury i warunków funkcjonowania firmy. W przeciwnym wypadku stanie się tylko nic nie znaczącym dokumentem, który w przypadku poważnej awarii zamiast pomóc, spowoduje jeszcze więcej zamętu i dezorganizacji.

Autor:

Adam Kostecki

Specjalista do Spraw Rozwoju i Bezpieczeństwa

Kroll Ontrack

Źródło: Kroll Ontrack