Atak ransomware nie musi zaszyfrować wszystkich systemów, aby zatrzymać organizację. Wystarczy, że niedostępny stanie się system finansowy, poczta, środowisko produkcyjne albo baza danych mieszkańców czy klientów. Dlatego pytanie, jak zbudować politykę kopii zapasowych, nie dotyczy wyłącznie administratora IT. To decyzja zarządcza o tym, jak długo organizacja może działać bez kluczowych danych i ile danych może bezpowrotnie utracić.
Dobra polityka backupu nie jest opisem harmonogramu wykonywanego przez wybrane narzędzie. Powinna określać odpowiedzialność, zakres ochrony, dopuszczalny czas odtworzenia, retencję, sposób testowania oraz zasady reagowania, gdy kopia okaże się niekompletna lub niedostępna. Tylko wtedy stanowi realny element SZBI, ciągłości działania i przygotowania do audytu.
Od ryzyka biznesowego do parametrów RPO i RTO
Punktem wyjścia nie powinno być pytanie: „ile miejsca potrzebujemy na backup?”. Najpierw należy zidentyfikować procesy krytyczne oraz systemy, które je obsługują. W przedsiębiorstwie będzie to na przykład ERP, księgowość, system sprzedaży, dokumentacja techniczna i poczta. W jednostce publicznej dochodzą rejestry, systemy dziedzinowe, dane obywateli oraz dokumentacja obiegu spraw.
Dla każdego systemu warto ustalić dwa parametry. RPO, czyli Recovery Point Objective, określa maksymalną akceptowalną utratę danych wyrażoną w czasie. Jeśli RPO wynosi cztery godziny, organizacja akceptuje odtworzenie danych do stanu sprzed maksymalnie czterech godzin. RTO, czyli Recovery Time Objective, wskazuje z kolei, jak szybko usługa musi wrócić do działania po incydencie.
Te wartości muszą wynikać z analizy wpływu na biznes, a nie z życzeń. RTO na poziomie jednej godziny dla wszystkich systemów może oznaczać nieproporcjonalne koszty infrastruktury, licencji i obsługi. Z drugiej strony deklarowanie RTO 72 godziny dla systemu obsługującego płatności, produkcję lub usługi dla obywateli często jest ryzykiem nie do zaakceptowania. Właściwa polityka różnicuje wymagania – inne dla środowiska krytycznego, inne dla systemów wspierających, a jeszcze inne dla archiwów.
Jak zbudować politykę kopii zapasowych krok po kroku
Po ustaleniu priorytetów należy opisać zakres danych i systemów objętych kopią. W praktyce pomijane bywają konfiguracje firewalli, przełączników, maszyn wirtualnych, repozytoria kodu, klucze kryptograficzne, kontenery, dyski współdzielone oraz dane przechowywane w usługach SaaS. Kopia serwera plików nie pomoże, jeśli po awarii nie da się odtworzyć konfiguracji tożsamości, uprawnień lub aplikacji, z której te pliki korzystają.
Dokument powinien jasno wskazywać właściciela biznesowego systemu, osobę odpowiedzialną za wykonanie i nadzór nad backupem oraz osobę uprawnioną do zatwierdzenia odtworzenia. Jest to szczególnie istotne w organizacjach, gdzie IT obsługuje dostawca zewnętrzny. Odpowiedzialności nie można pozostawić w domyśle ani ograniczyć do zapisu „backup realizuje firma informatyczna”.
W polityce warto zawrzeć co najmniej cztery elementy operacyjne:
- klasyfikację systemów i danych według krytyczności;
- częstotliwość tworzenia kopii pełnych, przyrostowych i replik;
- okresy retencji oraz zasady bezpiecznego usuwania danych;
- procedurę odtwarzania, eskalacji i dokumentowania wyników testów.
Częstotliwość kopii musi być spójna z RPO. Codzienny backup nie spełni wymogu RPO cztery godziny, nawet jeśli przechowywany jest w trzech lokalizacjach. Z kolei tworzenie kopii co 15 minut dla danych, które zmieniają się raz dziennie, może zwiększać koszty i obciążenie bez wymiernej korzyści. Polityka powinna określać wyjątki i uzasadniać je poziomem ryzyka.
Zasada 3-2-1 i ochrona przed ransomware
Powszechnie stosowana zasada 3-2-1 zakłada utrzymywanie trzech kopii danych, na dwóch różnych nośnikach, z czego jedna poza podstawową lokalizacją. To dobry punkt wyjścia, ale przy współczesnych atakach ransomware często nie wystarcza. Napastnicy celowo szukają konsol backupowych, kont uprzywilejowanych i repozytoriów kopii, aby uniemożliwić odzyskanie danych przed żądaniem okupu.
Dlatego polityka powinna wymagać przynajmniej jednej kopii odpornej na modyfikację lub usunięcie przez określony czas. Może to być repozytorium immutable, nośnik odłączany od środowiska albo rozwiązanie wykorzystujące odseparowaną lokalizację i inne poświadczenia administracyjne. Wybór technologii zależy od budżetu, skali danych oraz wymagań RTO, lecz zasada jest stała: osoba, która przejmie konto administratora domeny lub serwera, nie może automatycznie uzyskać możliwości skasowania wszystkich kopii.
Rozdzielenie dostępu jest równie ważne jak lokalizacja danych. Konta administracyjne systemów produkcyjnych i platformy backupowej powinny być osobne, chronione silnym uwierzytelnianiem wieloskładnikowym i objęte monitoringiem. Warto rejestrować operacje usuwania, zmiany retencji oraz wyłączania zadań backupowych. Dla środowisk o podwyższonym ryzyku takie zdarzenia powinny trafiać do SOC lub zespołu odpowiedzialnego za triage incydentów.
Retencja, GDPR i wymagania formalne
Retencja kopii zapasowych bywa błędnie traktowana jako wyłącznie parametr techniczny. Tymczasem zbyt krótki okres przechowywania może uniemożliwić odtworzenie danych po późno wykrytym incydencie, a zbyt długi zwiększa koszty i zakres danych osobowych pozostających w zasobach organizacji.
W odniesieniu do GDPR należy rozróżnić kopie operacyjne od archiwum. Backup służy przede wszystkim zapewnieniu dostępności i integralności danych, a nie ich przechowywaniu bez terminu. Polityka powinna wskazywać okresy retencji dla konkretnych klas systemów, sposób nadpisywania lub usuwania kopii oraz zasady obsługi żądań osób, których dane dotyczą. Usunięcie danych z systemu produkcyjnego nie zawsze oznacza natychmiastowe usunięcie ich z każdej historycznej kopii, ale organizacja musi umieć uzasadnić taki model i ograniczyć możliwość nieuprawnionego przywrócenia danych.
Dla podmiotów objętych NIS2, KSC lub wymaganiami ISO 27001 polityka backupu jest dowodem, że organizacja zarządza ryzykiem ciągłości działania. Sama procedura nie zapewni zgodności. Audytor lub organ nadzorczy będzie oczekiwał potwierdzeń realizacji: raportów z zadań, wyników testów, rejestrów incydentów, decyzji o wyjątkach oraz śladów przeglądu polityki przez kierownictwo.
Test odtwarzania jest ważniejszy niż raport „backup completed”
Poprawny status zadania backupowego oznacza jedynie, że narzędzie zakończyło określoną operację. Nie potwierdza, że system uruchomi się po odtworzeniu, baza danych zachowa spójność, a użytkownicy odzyskają wymagane uprawnienia. Wiele organizacji odkrywa ten problem dopiero podczas incydentu, kiedy czas RTO zaczyna realnie wpływać na działalność.
Polityka powinna definiować częstotliwość i zakres testów. Krytyczne systemy warto testować częściej, przy czym test nie zawsze musi oznaczać pełne odtworzenie całego środowiska. Można okresowo odtwarzać wybrane maszyny, bazy danych, pliki lub konfiguracje w wydzielonej strefie testowej. Kluczowe jest potwierdzenie, że kopia jest kompletna, możliwa do uruchomienia i pozwala osiągnąć deklarowane RPO oraz RTO.
Każdy test należy udokumentować: zakres, datę, wykorzystaną kopię, rzeczywisty czas odtworzenia, wykryte problemy i działania korygujące. Jeżeli odtworzenie trwało osiem godzin, a polityka deklaruje RTO cztery godziny, nie jest to drobna uwaga administracyjna. To ryzyko biznesowe wymagające decyzji – inwestować w zmianę rozwiązania, ograniczyć zakres systemu albo formalnie zmienić oczekiwania wobec dostępności.
Polityka musi działać również podczas kryzysu
Dokument powinien zawierać prostą ścieżkę postępowania na wypadek cyberataku, awarii infrastruktury lub błędu ludzkiego. Przed rozpoczęciem odtwarzania należy ocenić, czy środowisko źródłowe jest bezpieczne. Przy ransomware przywrócenie danych do nadal zainfekowanej sieci może doprowadzić do ponownego zaszyfrowania systemów w ciągu kilku minut.
Dlatego proces odzyskiwania powinien być powiązany z planem reagowania na incydenty i planem ciągłości działania. Najpierw następuje izolacja, analiza przyczyny i ocena zasięgu naruszenia, potem decyzja o czystym punkcie odtworzenia, a dopiero następnie przywracanie usług według ustalonej kolejności. W organizacjach bez całodobowych kompetencji bezpieczeństwa warto wcześniej ustalić kontakty eskalacyjne oraz zasady współpracy z zespołem SOC.
Politykę należy przeglądać nie rzadziej niż raz w roku oraz po każdej istotnej zmianie infrastruktury, migracji do chmury, wdrożeniu nowego systemu lub poważnym incydencie. Najlepszy moment na poprawę backupu jest przed awarią, gdy można spokojnie zweryfikować ryzyko, odpowiedzialności i możliwości odtworzenia. Gdy organizacja potrafi udowodnić, że jej kopie są chronione, aktualne i regularnie odtwarzane, zyskuje coś więcej niż dokument do audytu – realną zdolność do kontynuowania działalności.