Gdy kluczowy system w Twojej firmie ulegnie awarii, najtrudniejsze jest ustalenie, co przywrócić w pierwszej kolejności, kto ma do tego dostęp, której kopii zapasowej można zaufać i jak długo firma może działać bez tego systemu.
Właśnie wtedy wiele małych i średnich przedsiębiorstw (MŚP) dostrzega przepaść między posiadaniem kopii zapasowych a posiadaniem rzeczywistego planu odzyskiwania. Kopia zapasowa może zawierać potrzebne dane, ale nie decyduje o kolejności odzyskiwania, nie przydziela obowiązków, nie weryfikuje, czy przywracanie działa, ani nie rozwiązuje problemu brakujących danych logowania administratora podczas awarii.
Plan odzyskiwania po awarii IT nadaje temu procesowi strukturę, zanim dojdzie do zakłóceń. Określa, które systemy są najważniejsze, jak szybko należy je przywrócić, jaką utratę danych firma może tolerować, jakie strategie zapobiegania utracie danych wdrożyć, kto odpowiada za każdy krok odzyskiwania i jak chronione są krytyczne dane logowania. Taka jasność pozwala zapobiec przekształceniu się incydentu IT w długotrwały przestój, utratę przychodów lub szerszy kryzys operacyjny.
Co to jest plan odzyskiwania po awarii IT?
Ciągłość działania a odzyskiwanie po awarii IT
Co musi obejmować Twój plan odzyskiwania po awarii IT
Co musi określać Twój plan odzyskiwania po awarii IT
Odzyskiwanie danych logowania: pomijany scenariusz odzyskiwania po awarii
Szablon planu odzyskiwania po awarii
Jak przetestować swój plan odzyskiwania po awarii IT
Oprzyj odzyskiwanie na systemach, danych i dostępie
Co to jest plan odzyskiwania po awarii IT?
Plan odzyskiwania po awarii IT to udokumentowany proces przywracania systemów technologicznych po zakłóceniach. Koncentruje się na warstwie IT firmy: danych, aplikacjach, urządzeniach, infrastrukturze, usługach chmurowych, dostępie administratora, kopiach zapasowych oraz osobach odpowiedzialnych za odzyskiwanie.
Praktyczny plan odzyskiwania IT powinien odpowiadać na pytania takie jak:
- Które systemy muszą zostać przywrócone w pierwszej kolejności?
- Jak długi przestój może tolerować firma?
- Jaka utrata danych jest akceptowalna?
- Gdzie są przechowywane kopie zapasowe?
- Kto może przywrócić systemy?
- Które dane logowania administratora są potrzebne?
- W jaki sposób zespół potwierdzi, że przywrócone systemy są bezpieczne i nadają się do użytku?
- Jak firma będzie komunikować się z personelem i klientami, jeśli główne kanały będą niedostępne?
Plan odzyskiwania po awarii powinien wykraczać poza radzenie sobie z cyberatakami: musi obejmować codzienne problemy, takie jak awaria sprzętu, utracone dane logowania i przypadkowe usunięcie. Musi również obejmować przerwy w świadczeniu usług zewnętrznych, takie jak zakłócenia platform chmurowych lub narzędzi SaaS, błędy konfiguracji oraz odejście kluczowych pracowników bez przekazania krytycznego dostępu.
Odzyskiwania nie należy projektować podczas awarii. Musi ono zostać zaplanowane, przypisane do odpowiedzialnych osób, skomunikowane i przetestowane, zanim Twoja firma będzie musiała na nim polegać.
Ciągłość działania a odzyskiwanie po awarii IT
Ciągłość działania i odzyskiwanie po awarii IT są często traktowane jako to samo, ale rozwiązują różne problemy.
Ciągłość działania polega na utrzymaniu funkcjonowania firmy podczas zakłóceń. Obejmuje komunikację z klientami, tymczasowe przepływy pracy, obowiązki personelu, koordynację z dostawcami oraz decyzje o tym, które usługi muszą być kontynuowane, nawet jeśli normalne systemy są niedostępne.
Odzyskiwanie po awarii IT koncentruje się na technologii stojącej za tą pracą. Określa, w jaki sposób systemy, dane, aplikacje, kopie zapasowe i dostęp administratora zostaną przywrócone, aby firma mogła bezpiecznie powrócić do normalnego działania.
Jako przykład rozważmy awarię systemu CRM. Plan ciągłości działania może wyjaśniać, jak zespoły ds. sprzedaży lub wsparcia obsługują klientów, gdy CRM nie działa. Plan odzyskiwania IT wyjaśnia, kto kontaktuje się ze sprzedawcą, które dane muszą zostać przywrócone, jaka kopia zapasowa lub eksport są dostępne, jakie dane logowania są wymagane i jak zespół potwierdzi, że system jest ponownie bezpieczny w użyciu.
W przypadku wielu MŚP ta luka ujawnia się dopiero podczas incydentu. Pracownicy wiedzą, kto skontaktowałby się z klientami, ale nie wiedzą, kto może przywrócić system bilingowy. Wiedzą, że istnieją kopie zapasowe, ale nie wiedzą, czy przywracanie było kiedykolwiek testowane. Wiedzą, że jeden pracownik zazwyczaj zajmuje się kwestiami IT, ale nie wiedzą, co się stanie, jeśli ta osoba będzie niedostępna, ani gdzie są przechowywane hasła administratora, jeśli nie będzie z nią kontaktu.
Co musi obejmować Twój plan odzyskiwania po awarii IT
Dobry plan odzyskiwania po awarii IT nie musi być zbyt długi, ale musi być na tyle szczegółowy, aby można go było wdrożyć w stresującej sytuacji.
Docelowy czas odzyskiwania (RTO)
Docelowy czas odzyskiwania, czyli RTO, określa, jak szybko system musi zostać przywrócony. System płatności może wymagać przywrócenia w ciągu kilku godzin, podczas gdy wewnętrzny pulpit raportowania może tolerować dłuższy przestój.
Określaj wartości RTO na podstawie wpływu na biznes, a no nie na podstawie preferencji technicznych, ponieważ koszt przestoju to problem zarówno biznesowy, jak i techniczny. Zapytaj, które systemy wpływają na przychody, zobowiązania wobec klientów, obowiązki prawne, bezpieczeństwo i produktywność pracowników.
Docelowy punkt odzyskiwania (RPO)
Docelowy punkt odzyskiwania, czyli RPO, określa akceptowalną utratę danych, co pomaga w ustaleniu właściwych strategii zapobiegania utracie danych (DLP). Jeśli system ma RPO wynoszące jedną godzinę, kopie zapasowe lub replikacja muszą wspierać odzyskiwanie do mniej więcej tego punktu.
Jeśli RPO wynosi jeden dzień, firma akceptuje większą lukę w danych. RPO pomaga również określić częstotliwość tworzenia kopii zapasowych, ponieważ im krótsze RPO, tym częściej musisz tworzyć kopie zapasowe. Systemy krytyczne wymagają zatem częstszego tworzenia kopii zapasowych niż systemy o niskim priorytecie.
Poziomy priorytetów systemów
Nie wszystkie systemy powinny być przywracane w tym samym czasie. Plan odzyskiwania po awarii dla małych firm powinien dzielić systemy na poziomy priorytetów.
- Poziom 1: Systemy wymagane do podstawowej działalności, bezpieczeństwa, komunikacji lub generowania przychodów.
- Poziom 2: Ważne systemy, które mogą tolerować krótki przestój.
- Poziom 3: Systemy o niższym priorytecie, które można przywrócić po ustabilizowaniu działalności firmy.
Typowe systemy poziomu 1 mogą obejmować pocztę e-mail, dostawcę tożsamości, menadżera haseł, systemy finansowe, bazę danych klientów, chmurową przestrzeń dyskową i platformy komunikacyjne.
Strategia kopii zapasowych
Twoja strategia kopii zapasowych powinna określać:
- Dla jakich elementów tworzona jest kopia zapasowa i jak często
- Gdzie są przechowywane kopie zapasowe
- Kto ma do nich dostęp
- Jak testowane jest przywracanie
NCSC opublikowało również(nowe okno) zasady tworzenia kopii zapasowych odpornych na oprogramowanie ransomware dla rozwiązań chmurowych i lokalnych, zwracając uwagę, że dane w kopii zapasowej nie są domyślnie odporne na oprogramowanie ransomware i należy je ocenić pod kątem tego zagrożenia.
Skuteczna strategia kopii zapasowych zazwyczaj obejmuje niedostępne (offline) lub niezmienne kopie zapasowe dla krytycznych danych, regularne testy, udokumentowane kroki przywracania oraz oddzielne dane logowania do administrowania kopiami zapasowymi.
Stanowiska i zakres odpowiedzialności
Plan odzyskiwania po awarii powinien wskazywać konkretnych właścicieli, a nie tylko zadania. Jeśli cała wiedza o odzyskiwaniu spoczywa na jednej osobie, firma ponosi ryzyko osobowe, a także ryzyko IT. Określ, kto:
- Kieruje odzyskiwaniem
- Przywraca systemy
- Kontaktuje się ze sprzedawcami
- Zatwierdza dostęp awaryjny
- Komunikuje się wewnętrznie
- Dokumentuje decyzje
Co musi określać Twój plan odzyskiwania po awarii IT
| Element | Na co odpowiada |
| RTO | Jak szybko każdy system musi zostać przywrócony? |
| RPO | Jak dużą utratę danych firma może zaakceptować? |
| Poziomy priorytetów | Które systemy są przywracane w pierwszej kolejności, a które mogą poczekać? |
| Strategia kopii zapasowych | Do czego tworzona jest kopia zapasowa, gdzie jest przechowywana i czy przetestowano przywracanie? |
| Stanowiska i zakres odpowiedzialności | Kto kieruje odzyskiwaniem, przywraca systemy, kontaktuje się ze sprzedawcami i zatwierdza awaryjne zmiany? |
Odzyskiwanie danych logowania: pomijany scenariusz odzyskiwania po awarii
Odzyskiwanie po awarii często koncentruje się na danych, serwerach i kopiach zapasowych. W praktyce jednak odzyskiwanie może się nie powieść, ponieważ zespół nie ma dostępu do systemów potrzebnych do przywrócenia działania.
Odzyskiwanie danych logowania wymaga odpowiedzi na pytania:
- Kto ma dostęp do kont administratora?
- Gdzie są przechowywane dane logowania do kopii zapasowych?
- Które konta mogą przywrócić krytyczne systemy?
- Co się stanie, jeśli hasło zostanie utracone, zagrożone lub będzie w posiadaniu niedostępnej osoby?
- Czy awaryjne dane logowania są chronione i kontrolowane?
- Czy dostęp można szybko unieważnić i ponownie przydzielić?
Jeśli dane logowania do kopii zapasowych są przechowywane w przeglądarce jednego pracownika, kody odzyskiwania są przechowywane w prywatnej notatce, a udostępnione hasła administratora krążą na czacie, firma może nie być w stanie sprawnie odzyskać danych podczas incydentu.
A biznesowy menadżer haseł pomaga zmniejszyć to ryzyko poprzez scentralizowanie krytycznych danych logowania w zaszyfrowanych sejfach, przydzielanie dostępu według stanowisk oraz ułatwienie unieważniania lub ponownego przydzielania dostępu, gdy ktoś odchodzi lub zmieniają się obowiązki. Proton Pass for Business pomaga zespołom generować silne hasła, bezpiecznie przechowywać dane logowania, korzystać z bezpiecznego udostępniania i chronić wrażliwy dostęp przed ujawnieniem na czatach i w arkuszach kalkulacyjnych.
Jako menadżer haseł dla zespołów IT, Proton Pass wspiera scentralizowane zarządzanie danymi logowania, zasady dotyczące haseł, bezpieczne udostępnianie, raportowanie i logi, wdrażanie SCIM oraz integracje SSO. To sprawia, że odzyskiwanie danych logowania jest łatwiejsze, ponieważ dostęp do krytycznych systemów nie zależy od jednej osoby, jednego profilu przeglądarki ani jednego nieudokumentowanego hasła.
Szablon planu odzyskiwania po awarii
Plan odzyskiwania po awarii działa najlepiej, gdy jest wystarczająco szczegółowy, aby kierować działaniami podczas awarii, ale jednocześnie prosty, aby zespół mógł z niego korzystać pod presją. W przypadku MŚP szablon powinien koncentrować się na najważniejszych kwestiach: co należy przywrócić, jak szybko, z której kopii zapasowej, przez kogo i za pomocą jakich danych logowania.
1. Zakres
Określ, które systemy, usługi, lokalizacje, urządzenia i dane obejmuje plan.
Treść szablonu: Ten plan odzyskiwania po awarii IT obejmuje systemy, dane, usługi, dane logowania i sprzedawców wymaganych do przywrócenia krytycznych operacji firmy [Nazwa firmy] po zakłóceniach technologicznych.
2. Inwentaryzacja systemów krytycznych
Utwórz listę systemów, na których polega Twoja firma, i przypisz im poziomy priorytetów.
Treść szablonu: Krytyczne systemy zostaną pogrupowane w Poziom 1, Poziom 2 i Poziom 3 na podstawie wpływu na biznes, docelowego czasu odzyskiwania, docelowego punktu odzyskiwania oraz zależności od innych systemów.
3. Cele odzyskiwania
Określ RTO i RPO dla każdego priorytetowego systemu.
Treść szablonu: Każdy system musi mieć udokumentowany docelowy czas odzyskiwania i docelowy punkt odzyskiwania. Cele te powinny być weryfikowane co najmniej raz w roku oraz po istotnych zmianach w systemie.
4. Proces tworzenia i przywracania kopii zapasowych
Udokumentuj, gdzie są przechowywane kopie zapasowe, jak często są tworzone, kto ma do nich dostęp i jak działa testowanie przywracania.
Treść szablonu: Kopie zapasowe muszą być chronione przed nieautoryzowanym dostępem, w stosownych przypadkach przechowywane oddzielnie od głównych systemów i testowane zgodnie z regularnym harmonogramem. Procedury przywracania muszą być udokumentowane dla systemów Poziomu 1.
5. Odzyskiwanie danych logowania i dostępu
Określ, gdzie są przechowywane krytyczne dane logowania i kto ma do nich dostęp podczas odzyskiwania.
Treść szablonu: Dane logowania administratora, dane logowania do kopii zapasowych, kody odzyskiwania oraz dostęp dostawcy wymagany do odzyskiwania po awarii must być przechowywane w zatwierdzonym, zaszyfrowanym sejfie. Dostęp musi być ograniczony do upoważnionych stanowisk i weryfikowany po zmianach stanowisk, zakończeniu współpracy z pracownikami oraz ćwiczeniach z odzyskiwania.
6. Stanowiska i eskalacja
Określ właścicieli procesów odzyskiwania, ich zastępców oraz ścieżki eskalacji.
Treść szablonu: Każde stanowisko ds. odzyskiwania musi mieć głównego właściciela i właściciela zapasowego. Plan musi określać, kto kieruje odzyskiwaniem, kto przywraca systemy, kto kontaktuje się ze sprzedawcami, kto przekazuje aktualizacje i kto zatwierdza awaryjne zmiany.
7. Plan komunikacji
Określ, jak firma komunikuje się wewnętrznie i zewnętrznie podczas awarii IT.
Treść szablonu: Podczas wydarzenia związanego z odzyskiwaniem danych wewnętrzne aktualizacje będą udostępniane za pośrednictwem [zatwierdzony kanał]. Komunikacja zewnętrzna z klientami, sprzedawcami, ubezpieczycielami lub organami regulacyjnymi musi zostać zatwierdzona przez [stanowisko/zespół].
8. Częstotliwość testowania i przeglądów
Określ, jak często plan jest testowany i aktualizowany.
Treść szablonu: Ten plan odzyskiwania po awarii będzie testowany co najmniej [raz w roku / dwa razy w roku] i weryfikowany po poważnych incydentach, zmianach w systemach, zmianach dostawców lub nieudanych ćwiczeniach z odzyskiwania.
Jak przetestować swój plan odzyskiwania po awarii IT
Plan odzyskiwania po awarii staje się przydatny dopiero wtedy, gdy zostanie przetestowany w warunkach przypominających rzeczywiste zakłócenia. Kopia zapasowa, która istnieje, ale nigdy nie została przywrócona, to wciąż tylko założenie. Stanowisko ds. odzyskiwania, które rozumie tylko jedna osoba, to wciąż zależność. Dane logowania administratora, których nikt nie może znaleźć podczas awarii, to wciąż przeszkoda.
Na początku testowanie nie musi być skomplikowane. W przypadku większości MŚP celem jest wykazanie, że firma potrafi przywrócić odpowiednie systemy za pomocą właściwych ludzi i przy użyciu odpowiednich danych logowania w realnych ramach czasowych.
1. Ćwiczenie symulacyjne (tabletop)
Wybierz prawdopodobny scenariusz, np. atak oprogramowania ransomware na udostępnione pliki, awarię chmurowej przestrzeni dyskowej, przypadkowe usunięcie danych klientów lub nagłą utratę dostępu do konta administratora. Przeanalizujcie krok po kroku, co zespół zrobiłby w pierwszej godzinie, kto by kierował działaniami, z którymi sprzedawcami należałoby się skontaktować, które systemy miałyby priorytet i jakich informacji by brakowało.
2. Przetestuj przywracanie
Wybierz krytyczny plik, bazę danych, skrzynkę pocztową lub eksport systemu i potwierdź, że można go przywrócić do stanu używalności. Sprawdź, czy przywrócone dane są wystarczająco świeże, czy uprawnienia nadal działają i czy zespół wie, gdzie znajduje się kopia zapasowa.
3. Testuj regularnie
Jako praktyczny punkt odniesienia MŚP powinny testować plan co najmniej raz w roku, zgodnie z wytycznymi NIST zawartymi w publikacji specjalnej 800-34, wersja 1(nowe okno), a także częściej po istotnych zmianach systemowych lub zmianach dostawców.
4. Przetestuj odzyskiwanie danych logowania
Potwierdź, że upoważnione osoby mają dostęp do kont administratora kopii zapasowych, kont administratora chmury, portali sprzedawców, kodów odzyskiwania i awaryjnych danych logowania bez polegania na przeglądarce, prywatnych notatkach czy pamięci jednego pracownika. Celem nie jest niepotrzebne ujawnianie wrażliwych haseł. Chodzi o potwierdzenie, że model dostępu nadal działa, gdy firma znajduje się pod presją.
Po każdym teście udokumentuj, co się nie udało, co trwało zbyt długo, oraz wyznacz konkretną osobę i termin na wdrożenie każdej poprawki. Dobry test to nie taki, w którym wszystko przebiega idealnie. To taki, który ujawnia luki, gdy firma ma jeszcze czas na ich usunięcie.
Oprzyj odzyskiwanie na systemach, danych i dostępie
Użyteczny plan odzyskiwania po awarii IT zapewnia firmie kolejność odzyskiwania, przypisanych właścicieli, realistyczny obraz akceptowalnego przestoju oraz sposób na utrzymanie ciągłości działania i odzyskanie dostępu do systemów, które umożliwiają ciągłość pracy.
W przypadku MŚP może to zadecydować o różnicy między krótką przerwą a długotrwałą awarią. Jeśli poczta e-mail, oprogramowanie finansowe, chmurowa przestrzeń dyskowa, systemy klienckie lub konta administratora są niedostępne, zespół musi wiedzieć, co jest najważniejsze, kto może podjąć działania i jakie dane logowania są wymagane, aby bezpiecznie przywrócić dostęp.
Dlatego planowanie odzyskiwania powinno obejmować systemy, dane i dostęp łącznie. Kopie zapasowe mogą przywrócić pliki, ale to dane logowania umożliwiają zespołowi odzyskanie kontroli nad systemami niezbędnymi do odzyskania sprawności. Dane logowania administratora, portale sprzedawców, konta kopii zapasowych, kody odzyskiwania i udostępnione dane logowania operacyjne — wszystko to musi być chronione, uporządkowane i dostępne dla właściwych osób, gdy coś pójdzie nie tak.
A biznesowy menadżer haseł pomaga wzmocnić tę część planu. Dzięki krytycznym danym logowania przechowywanym w zaszyfrowanych sejfach haseł i udostępnianym wyłącznie upoważnionym osobom, firma jest mniej zależna od przeglądarki jednego pracownika, jego prywatnych notatek czy pamięci podczas wydarzenia związanego z odzyskiwaniem danych.
