Kopia zapasowa, której nigdy nie odtworzono, nie jest potwierdzonym zabezpieczeniem. Jest założeniem. W czasie awarii serwera, błędu administratora lub ataku ransomware liczą się nie deklaracje dostawcy backupu, lecz odpowiedź na trzy pytania: czy dane można odzyskać, ile to potrwa i czy odzyskana wersja pozwoli organizacji kontynuować pracę. Dlatego pytanie, jak testować kopie zapasowe, powinno znaleźć się w procedurach bezpieczeństwa, planie ciągłości działania i harmonogramie pracy IT.
Dla zarządu test backupu jest kontrolą ryzyka operacyjnego. Dla działu IT – sprawdzianem konfiguracji, uprawnień, infrastruktury i procedur. Dla organizacji objętych NIS2, KSC, ISO 27001 lub ISO 22301 stanowi dowód, że mechanizm odtwarzania działa w praktyce, a nie tylko na diagramie architektury.
Dlaczego wykonanie backupu nie wystarcza
System może raportować poprawne wykonanie zadania, mimo że kopia jest niekompletna, zaszyfrowana przez atakującego, zapisana na niedostępnym repozytorium albo niemożliwa do odtworzenia w wymaganej wersji aplikacji. Szczególnie częsty problem dotyczy baz danych i systemów biznesowych. Kopia plików może istnieć, ale bez spójnego zrzutu bazy, kluczy szyfrujących, konfiguracji usługi lub dzienników transakcyjnych odtworzenie systemu nie przywróci działania procesu.
Test ujawnia również problemy organizacyjne. Administrator może znać hasło do konsoli backupowej, ale podczas jego nieobecności nikt nie ma dostępu. Odtworzenie może wymagać zatwierdzenia przez właściciela systemu, którego nie uwzględniono w procedurze. W kryzysie takie luki wydłużają przestój bardziej niż sama awaria techniczna.
Wymagania norm i regulacji nie sprowadzają się do posiadania nośnika z kopią. ISO 27001 w obszarze kopii zapasowych oczekuje, że organizacja wdroży i sprawdza proces backupu zgodnie z ustalonymi wymaganiami biznesowymi. NIS2 wzmacnia podejście oparte na zarządzaniu ryzykiem, ciągłości działania i obsłudze incydentów. Częstotliwość testów nie musi być identyczna w każdej firmie, ale musi wynikać z krytyczności usług oraz zostać uzasadniona i udokumentowana.
Jak testować kopie zapasowe: od pliku do pełnego odtworzenia
Najbezpieczniej budować program testów warstwowo. Nie każdy test wymaga zatrzymania produkcji, ale pojedyncze odzyskanie pliku nie potwierdza gotowości do odtworzenia całego środowiska.
Test integralności i monitoringu
Pierwsza warstwa obejmuje automatyczną weryfikację zadań backupowych. Należy sprawdzać status wykonania, kompletność danych, błędy transmisji, wykorzystanie pojemności repozytorium i poprawność retencji. Alert o błędzie powinien trafiać do konkretnej osoby lub zespołu, z określonym czasem reakcji. Sam raport wysłany na nieczytaną skrzynkę nie jest kontrolą.
Warto też regularnie weryfikować, czy kopie są objęte zasadą 3-2-1-1-0: trzy kopie danych, na co najmniej dwóch różnych nośnikach, jedna poza główną lokalizacją, jedna odizolowana lub niezmienialna oraz zero błędów wykrytych po weryfikacji. Model trzeba dopasować do środowiska. Mała organizacja może korzystać z chmury i lokalnego repozytorium, a instytucja publiczna z dodatkowej lokalizacji zapasowej i wydzielonej infrastruktury odtwarzania.
Test odtworzenia pojedynczych danych
Co najmniej raz w miesiącu warto odzyskać reprezentatywne pliki, foldery, skrzynki pocztowe lub rekordy systemu. Test powinien obejmować różne źródła danych: udziały plikowe, pocztę, bazy danych, środowiska wirtualne i usługi chmurowe, jeśli są wykorzystywane.
Nie wystarczy sprawdzić, że plik da się pobrać. Osoba odpowiedzialna za system powinna potwierdzić jego użyteczność: czy dokument otwiera się poprawnie, czy wersja jest właściwa, czy dane są kompletne i czy uprawnienia dostępu zostały zachowane. Taki test pozwala szybko wykryć błędną politykę retencji albo nieprawidłowo skonfigurowane objęcie zasobu backupem.
Test odtworzenia systemu lub usługi
Kolejny poziom to odzyskanie maszyny wirtualnej, serwera fizycznego albo aplikacji w wydzielonym środowisku testowym. Należy odtworzyć nie tylko system operacyjny, ale też zależności: bazę danych, konfigurację, certyfikaty, konta usługowe, integracje i połączenia sieciowe.
Wynik testu powinien odpowiedzieć na pytanie, czy usługa realizuje proces biznesowy. Dla systemu finansowo-księgowego będzie to na przykład możliwość zalogowania, odczytu danych i wykonania kontrolnej operacji. Dla systemu obiegu dokumentów – dostęp do dokumentu, metadanych i historii. Test techniczny bez akceptacji właściciela biznesowego bywa zbyt wąski.
Ćwiczenie disaster recovery
Najbardziej wartościowe są okresowe ćwiczenia odtworzenia krytycznej usługi po scenariuszu awarii. Mogą zakładać niedostępność serwerowni, zaszyfrowanie infrastruktury, utratę konta administratora lub awarię usługi chmurowej. Ćwiczenie powinno obejmować uruchomienie zespołu, decyzję o przełączeniu na tryb awaryjny, komunikację z kierownictwem i odtworzenie usługi w alternatywnej lokalizacji.
Nie trzeba zaczynać od pełnoskalowanej symulacji całej organizacji. Dla wielu firm rozsądnym pierwszym krokiem będzie półroczny test jednej usługi krytycznej. Z czasem warto objąć scenariuszem także dostawców, systemy komunikacji oraz procedury pracy ręcznej. Właśnie wtedy wychodzą na jaw zależności, których nie widać w konsoli backupu.
RTO i RPO: mierniki, które nadają testom sens
Test odtwarzania musi mieć kryteria powodzenia. Dwa podstawowe parametry to RTO i RPO. RTO określa maksymalny dopuszczalny czas przywrócenia usługi, natomiast RPO wskazuje, jak dużą utratę danych w czasie organizacja akceptuje.
Jeżeli RPO systemu sprzedażowego wynosi cztery godziny, backup wykonywany raz na dobę nie spełnia wymagania. Jeżeli RTO wynosi osiem godzin, a ostatni test odtworzenia trwał dwa dni, organizacja ma lukę w ciągłości działania niezależnie od tego, że kopia formalnie istnieje. Parametry powinny zostać zatwierdzone przez właścicieli procesów, a nie ustalone wyłącznie przez IT.
Podczas testu mierz rzeczywisty czas: od zgłoszenia incydentu, przez identyfikację właściwej kopii i przygotowanie środowiska, po potwierdzenie działania przez użytkownika biznesowego. To pozwala odróżnić teoretyczną wydajność narzędzia od realnej zdolności organizacji do odzyskania usługi.
Bezpieczne warunki testów
Odtwarzanie należy wykonywać poza środowiskiem produkcyjnym, chyba że scenariusz został formalnie zatwierdzony i zabezpieczony. Testowa sieć powinna być odseparowana, aby odtworzona maszyna nie wysłała komunikacji do produkcji, nie uruchomiła automatycznych integracji ani nie nadpisała aktualnych danych.
W scenariuszach ransomware szczególną uwagę trzeba poświęcić kopiom niezmienialnym oraz odizolowanym. Test powinien potwierdzić, że administrator odtworzy dane z wersji sprzed incydentu, a atakujący nie mógł usunąć lub zaszyfrować repozytorium przez przejęte konto uprzywilejowane. Konieczna jest też kontrola dostępu do konsoli backupowej, wieloskładnikowe uwierzytelnianie i rozdzielenie ról administracyjnych.
Przed rozpoczęciem ćwiczenia należy przygotować zakres, termin, osoby odpowiedzialne, dane testowe i warunki przerwania prac. Nie chodzi o nadmierną biurokrację. Chodzi o uniknięcie sytuacji, w której test powoduje realną niedostępność usługi lub naruszenie poufności danych osobowych.
Dokumentacja, która wytrzymuje audyt i incydent
Każdy test powinien zakończyć się protokołem. Dokument należy traktować jako materiał operacyjny, a nie wyłącznie załącznik dla audytora. Powinien zawierać datę, testowany zakres, użyte źródło kopii, osoby uczestniczące, uzyskane RTO i RPO, wynik walidacji biznesowej, wykryte niezgodności oraz właściciela działania korygującego z terminem realizacji.
Warto rejestrować także przypadki nieudane. Ukrywanie błędów daje fałszywe poczucie bezpieczeństwa. Dobrze prowadzony rejestr pokazuje natomiast, że organizacja wykrywa problemy, ocenia ryzyko i skutecznie je usuwa. To istotne podczas audytu ISO 27001, przeglądów SZBI i oceny dojrzałości w obszarze NIS2 lub KSC.
Smartech-IT rekomenduje powiązanie wyników testów z rejestrem ryzyka, planem ciągłości działania oraz procedurą reagowania na incydenty. Jeżeli test wskazuje, że odtworzenie krytycznego systemu przekracza RTO, nie jest to wyłącznie problem administratora. To ryzyko biznesowe wymagające decyzji o zmianie architektury, częstotliwości backupu, zasobów odtworzeniowych albo priorytetów usług.
Częstotliwość testów zależy od ryzyka
Dla danych o niskiej krytyczności wystarczy zazwyczaj regularny test plików i okresowe sprawdzenie pełnego odtworzenia. Systemy obsługujące finanse, produkcję, usługi publiczne, dane osobowe lub procesy krytyczne wymagają częstszych testów oraz ćwiczeń scenariuszowych. Dodatkowy test należy przeprowadzić po istotnej zmianie infrastruktury, migracji do chmury, aktualizacji systemu backupowego, zmianie kluczy szyfrujących albo incydencie bezpieczeństwa.
Najgorszym momentem na poznanie rzeczywistego czasu odtworzenia jest poniedziałkowy poranek po ataku ransomware. Warto zaplanować pierwszy test dla jednej kluczowej usługi, zmierzyć wynik i zamknąć wykryte działania korygujące. Dopiero potwierdzona zdolność odzyskania danych daje organizacji podstawę, by mówić o ciągłości działania z pełnym przekonaniem.