Ciągłość działania: BIA, BCP, DRP, RTO i RPO

BIA — Business Impact Analysis

BIA analizuje wpływ niedostępności procesu w kolejnych przedziałach czasu. Powinna uwzględniać skutki: dla zdrowia i bezpieczeństwa, operacyjne i produkcyjne, finansowe, prawne i regulacyjne, dla klientów i pacjentów, reputacyjne, dla łańcucha dostaw, dla innych procesów oraz dla jakości i integralności danych.

BIA nie jest ankietą IT. Warsztaty prowadzi się z właścicielami procesów, a wyniki są zatwierdzane przez właściwych dyrektorów.

RTO — Recovery Time Objective

RTO to docelowy czas przywrócenia procesu, usługi lub systemu po zakłóceniu. Nie oznacza obietnicy bezwarunkowej — jest wymaganiem, które trzeba zweryfikować technicznie, kosztowo i podczas testów.

Przykład: jeżeli proces wysyłki leków musi zostać przywrócony w ciągu ośmiu godzin, system magazynowy, integracje, dostęp pracowników, łączność i dane muszą posiadać odpowiednie cele odtworzenia. Nie wystarczy ustalić RTO tylko dla aplikacji.

RPO — Recovery Point Objective

RPO określa, ile danych organizacja może maksymalnie utracić, wyrażając to jako czas. RPO cztery godziny oznacza, że po awarii organizacja akceptuje odtworzenie danych do stanu sprzed maksymalnie czterech godzin.

• częstotliwość kopii lub replikacji
• architektura baz danych
• koszty łączy i przechowywania
• sposób potwierdzania integralności
• procedury odtworzenia i uzgadniania transakcji

MTPD i MBCO

MTPD to maksymalny tolerowany okres zakłócenia, po którym skutki stają się nieakceptowalne. MBCO to minimalny poziom zdolności biznesowej, który trzeba utrzymać podczas zakłócenia. RTO powinno być krótsze od MTPD i uwzględniać czas potrzebny na stabilizację oraz wznowienie pełnej pracy.

BCP — plan ciągłości działania

• kryteria aktywacji
• role, zastępstwa i dane kontaktowe
• priorytety usług
• procedury manualne i alternatywne
• wymagane zasoby i lokalizacje zastępcze
• komunikacja i zależności od dostawców
• zasady powrotu do normalnego działania
• sposób rejestrowania decyzji

DRP — plan odtworzenia po awarii

• co odtwarzamy i w jakiej kolejności
• z jakiego środowiska i kopii
• jakie konta oraz klucze są wymagane
• jak działa komunikacja, gdy podstawowa domena lub poczta jest niedostępna
• jak potwierdzamy integralność i bezpieczeństwo
• kto akceptuje przejście do pracy
• jak cofamy błędne odtworzenie
• jak dokumentujemy rzeczywiste RTO i RPO

Backup a disaster recovery

Pragmatyczne zasady backupu

• krytyczne kopie oddzielić logicznie i administracyjnie od środowiska produkcyjnego
• stosować kopię odporną na usunięcie lub modyfikację w adekwatnym zakresie
• szyfrować kopie i bezpiecznie zarządzać kluczami
• monitorować powodzenie zadań, pojemność i anomalie
• testować odtworzenie, nie tylko wykonanie kopii
• chronić konta administratorów backupu za pomocą MFA/PAM
• utrzymywać kopie konfiguracji urządzeń i usług chmurowych
• dokumentować rzeczywiste czasy i utratę danych
• uwzględniać systemy SaaS — odpowiedzialność dostawcy nie zawsze obejmuje oczekiwaną retencję i odtworzenie
• przeprowadzać testy po istotnych zmianach

Jak prowadzić test

1. Ustal cel i scenariusz.
2. Zdefiniuj kryteria sukcesu.
3. Wybierz bezpieczny zakres i dane testowe.
4. Uruchom procedurę bez podpowiadania zespołowi każdego kroku.
5. Mierz czas od decyzji do dostępności usługi.
6. Zweryfikuj integralność i funkcję biznesową.
7. Sprawdź komunikację i zależności.
8. Udokumentuj problemy.
9. Przypisz właścicieli i terminy.
10. Powtórz test po poprawkach.

Mierniki

• procent procesów krytycznych z zatwierdzonym BIA
• procent usług z uzgodnionym RTO/RPO
• odsetek kopii zakończonych poprawnie i testów restore zakończonych sukcesem
• rzeczywisty czas odtworzenia względem RTO i rzeczywista utrata danych względem RPO
• liczba niezamkniętych działań po testach
• aktualność danych kontaktowych i runbooków
• odsetek dostawców krytycznych z potwierdzonymi planami ciągłości

Najczęstsze błędy

• kopiowanie RTO między systemami bez BIA
• RTO krótsze niż technicznie możliwe, bez budżetu
• nieuwzględnienie tożsamości, DNS, sieci i kluczy
• testowanie pojedynczego pliku zamiast usługi
• przechowywanie kopii pod tymi samymi uprawnieniami co produkcja
• brak planu dla utraty personelu lub dostawcy
• BCP bez procedur manualnych
• brak zatwierdzenia wyniku testu przez biznes
• nieaktualne runbooki
• brak komunikacji awaryjnej poza podstawową pocztą

Materiały mają charakter edukacyjny i nie stanowią opinii prawnej ani gwarancji zgodności. Zakres obowiązków zależy od indywidualnej sytuacji organizacji, aktualnych przepisów, aktów wykonawczych i stanowisk właściwych organów. Przed podjęciem decyzji wymagającej interpretacji prawa należy przeprowadzić analizę odpowiednią dla danego podmiotu.