analiza wpływu na działalność

Analiza wpływu na działalność (business impact analysis, BIA) ustala, które procesy organizacji są krytyczne i jakie straty finansowe, prawne oraz wizerunkowe przynosi ich przerwa w czasie. Glosariusz NIST definiuje ją krótko jako proces analizy funkcji operacyjnych i skutków, jakie może na nie mieć zakłócenie ^[2]. Polski słownik NSC 7298 opisuje ją jako analizę wymagań, funkcji i współzależności w systemie informatycznym ^[3]. Według NIST celem BIA jest powiązanie systemu z krytycznymi procesami i usługami, a na tej podstawie opisanie skutków zakłócenia ^[1]. Wyniki analizy są podstawą wyznaczenia RTO i RPO ^[1].

Jak działa

Przewodnik NIST SP 800-34 opisuje BIA jako kluczowy krok całego planowania awaryjnego ^[1]. Wymienia trzy etapy, które zwykle składają się na analizę ^[1]. Pokazuje je schemat poniżej.

RYS. 1Trzy etapy BIA według NIST

Procesy i krytyczność. Ustala się procesy wspierane przez system i skutki jego przestoju dla każdego z nich ^[1]. Czas przestoju powinien odzwierciedlać maksimum, które organizacja zniesie, nadal wypełniając swoje zadania ^[1]. NIST zaleca, by ten czas ustalać razem z właścicielami procesów, kierownictwem i menedżerami ^[1]. Skutki można wyrażać w jednostkach zrozumiałych dla organizacji, na przykład w kategorii „koszty” liczonej nadgodzinami czy opłatami ^[1].

Wymagane zasoby. Realistyczne odtworzenie wymaga oceny zasobów potrzebnych do wznowienia procesów i ich współzależności ^[1]. NIST wymienia jako przykłady obiekty, personel, sprzęt, oprogramowanie, pliki danych, komponenty systemu i kluczowe dokumenty ^[1].

Priorytety odtwarzania. To ostatni etap. Priorytety ustala się z uwzględnieniem krytyczności procesu, skutków przerwy, dopuszczalnego przestoju i zasobów systemu ^[1]. Wynikiem jest hierarchia kolejności odtwarzania systemów ^[1].

Wielkości wyznaczane w BIA

Analiza kończy się liczbami, które później trafiają do planu ciągłości działania. NIST definiuje trzy z nich.

Wielkości te są ze sobą powiązane. Ponieważ RTO ma zapewnić, że MTD nie zostanie przekroczony, RTO musi zwykle być krótsze niż MTD ^[1]. RPO nie wchodzi w skład MTD. Zależy od tego, ile utraty danych proces zniesie w trakcie odtwarzania ^[1]. NIST zaleca, by BIA wykonać już na etapie inicjowania systemu i powtarzać ją, gdy zmieniają się jego komponenty ^[1].

W przepisach

BIA pojawia się w prawie Unii. Rozporządzenie DORA stanowi, że podmioty finansowe przeprowadzają analizę wpływu na działalność swojego narażenia na poważne zakłócenia ^[4]. Rozporządzenie wykonawcze 2024/2690, wydane do dyrektywy NIS2, mówi o kompleksowej analizie określającej maksymalny dopuszczalny czas przestoju i cele dotyczące czasu przywrócenia normalnego działania ^[5]. Oba akty używają więc pojęć, które NIST nazywa MTD i RTO.

BIA różni się od szacowania ryzyka. Szacowanie pyta, jak prawdopodobne jest zdarzenie i jakie będą jego skutki. BIA zakłada, że przerwa już nastąpiła, i pyta, ile kosztuje każda godzina. Obie analizy się uzupełniają: szacowanie ryzyka wskazuje, czemu zapobiegać, BIA – co odtwarzać najpierw. NIST zauważa, że część skutków wskazanych w BIA można ograniczyć środkami zapobiegawczymi, które są preferowane, gdy są wykonalne i opłacalne ^[1].

W WordPressie

Dla strony na WordPressie BIA zaczyna się od pytania, jakie procesy od niej zależą. Witryna wizytówka, blog firmowy i sklep WooCommerce mają różne progi. Przestój sklepu oznacza utracone zamówienia, przestój formularza kontaktowego – utracone zapytania, a wyciek bazy klientów – obowiązki z RODO.

Drugi etap, spis zasobów, w WordPressie jest dobrze określony. Dokumentacja wymienia dwie części witryny: pliki, czyli rdzeń, wtyczki, motywy, obrazy i inne pliki, oraz bazę danych z wpisami, komentarzami i danymi generowanymi przez stronę ^[6]. Do tego dochodzą zasoby zewnętrzne: hosting, domena, DNS, operator płatności i poczta. Każdy z nich ma własny czas odtworzenia.

Z BIA wynika też częstotliwość kopii zapasowej (backup). Dokumentacja WordPressa zaleca kopie raz w tygodniu dla mniejszych stron z niewielką liczbą wpisów, a codziennie dla stron bardzo aktywnych ^[6]. Poleca przechowywanie co najmniej 3–5 ostatnich kopii w różnych miejscach, na przykład na serwerze, w chmurze i na komputerze lokalnym ^[6]. Sklep przyjmujący zamówienia przez cały dzień może jednak potrzebować krótszego RPO niż jedna doba, co pokazuje dopiero analiza wpływu.

Typowe zdarzenia, które warto przeanalizować dla witryny:

• ransomware albo przejęcie serwera, gdy trzeba odtwarzać całość z kopii;
• atak odmowy usługi (denial of service), gdy dane są całe, ale strona jest niedostępna;
• podatność we wtyczce wymagająca wyłączenia funkcji do czasu poprawki;
• awaria u dostawcy hostingu, na którą właściciel strony nie ma wpływu.

Dobre praktyki

• Analizować procesy, a nie „stronę” jako całość: sklep, formularz i blog mają różne MTD ^[1].
• Ustalać dopuszczalny przestój z właścicielami procesów, a nie tylko z działem IT ^[1].
• Spisywać zasoby razem z zależnościami od dostawców ^[1].
• Sprawdzać, czy harmonogram kopii spełnia wyznaczone RPO, i regularnie testować odtwarzanie.
• Powtarzać BIA po każdej większej zmianie witryny, na przykład po uruchomieniu sklepu ^[1].