Twój backup nie działa — i dowiesz się o tym podczas ataku ransomware

Problem

Test odtwarzania backupu — o tym właśnie zapomniała firma handlowa zatrudniająca około 40 pracowników. Backup serwera z systemem ERP wykonywał się codziennie o 23:00, a administrator dostawał maila z potwierdzeniem „Backup completed successfully”. Wszyscy spali spokojnie — aż do dnia, w którym macierz dyskowa odmówiła posłuszeństwa.

Przy próbie odtworzenia okazało się, że od siedmiu miesięcy kopie obejmowały tylko część wolumenu z bazą danych. Zadanie backupowe kończyło się „sukcesem”, bo technicznie się wykonywało — tyle że po zmianie układu dysków nikt nie zaktualizował jego konfiguracji. Firma odzyskała dane sprzed siedmiu miesięcy. Resztę odtwarzano tygodniami z faktur i maili.

Przyczyna

Komunikat „backup zakończony sukcesem” mówi tylko tyle, że zadanie się wykonało — nie mówi nic o tym, czy z powstałej kopii da się cokolwiek odtworzyć. Między jednym a drugim jest przepaść, w którą wpadają kolejno:

• zmiany w infrastrukturze (nowy dysk, nowa baza, przeniesiona aplikacja), o których backup „nie wie”,
• kopie uszkodzone lub niekompletne, których nikt nigdy nie otworzył,
• brak procedury: wiadomo, że „jest backup”, ale nikt nie wie, jak i w jakim czasie przywrócić z niego działającą firmę,
• ransomware szyfrujący także kopie, bo leżały na tym samym serwerze, w dostępnym udziale sieciowym.

Inżynieryjne rozwiązanie

W środowiskach krytycznych obowiązuje zasada: backup istnieje dopiero wtedy, gdy przeszedł test odtwarzania. Przenoszę ją do każdej firmy, którą się opiekuję:

1. Reguła 3-2-1 — trzy kopie danych, na dwóch różnych nośnikach, w tym jedna poza firmą (offline lub w niezależnej lokalizacji). Kopia odłączona od sieci jest odporna na ransomware.
2. Automatyczny test odtwarzania — cyklicznie (co miesiąc lub co kwartał) kopia jest odtwarzana na środowisko testowe: system wstaje, baza się montuje, aplikacja odpowiada. Wynik trafia do protokołu.
3. Zmierzony czas odtworzenia (RTO) — po teście wiadomo nie „że się da”, ale w ile: np. „pełne odtworzenie serwera ERP: 40 minut”. To liczba, którą właściciel firmy może zestawić z kosztem godziny przestoju.
4. Monitoring spójności — alert nie wtedy, gdy zadanie się nie wykona, ale też wtedy, gdy kopia jest podejrzanie mała, niekompletna lub gdy zmienił się zakres danych.

Wniosek biznesowy

Koszt wdrożenia testowanych backupów w małej firmie to ułamek kosztu jednego dnia przestoju — nie mówiąc o siedmiu miesiącach utraconych danych. Jeżeli dziś wiesz o swoim backupie tylko tyle, że „się robi”, to znaczy, że nie wiesz, czy go masz.

Pytanie kontrolne na dziś: kiedy ostatnio ktoś w Twojej firmie odtworzył cokolwiek z kopii zapasowej — i ile to trwało? Jeśli odpowiedź brzmi „nie wiem”, porozmawiajmy.

Najczęstsze pytania

Czym różni się RPO od RTO?
RPO (Recovery Point Objective) to maksymalna akceptowalna utrata danych, liczona czasem od ostatniej dobrej kopii — RPO 24 godziny oznacza, że firma godzi się na utratę co najwyżej jednego dnia pracy, a backup musi biec przynajmniej raz na dobę. RTO (Recovery Time Objective) to z kolei maksymalny czas, w jakim system musi wrócić do działania po awarii — z przykładu z tego wpisu, zmierzone RTO 40 minut. Oba parametry ustala się osobno dla każdego systemu, bo serwer poczty i baza ERP rzadko mają te same wymagania biznesowe. Bez tego rozróżnienia trudno w ogóle rozmawiać o tym, jaką częstotliwość backupu i jaki plan odtwarzania firma faktycznie potrzebuje.

Czy przetestowany backup wystarczy, żeby przetrwać atak ransomware?
Nie zawsze — sam test odtwarzania mówi, że kopia jest kompletna i da się z niej wstać, ale ransomware celuje właśnie w backup, nie tylko w produkcję. Jeśli kopie zapasowe są dostępne z tej samej sieci i tych samych poświadczeń co reszta infrastruktury, atakujący, który przejął dostęp administracyjny, potrafi je zaszyfrować albo skasować razem z produkcją. Standardem branżowym jest tu zasada 3-2-1-1: co najmniej trzy kopie danych, na dwóch różnych nośnikach, jedna poza siedzibą firmy, i co najmniej jedna niemodyfikowalna (immutable) lub fizycznie odseparowana (air-gapped) — czyli taka, której nie skasuje nawet ktoś z przejętymi uprawnieniami administratora.