Ransomware najpierw kasuje kopie zapasowe — jak zbudować backup, którego atakujący nie usunie

Firmy przygotowują się na ransomware tak, jakby atak był wydarzeniem punktowym: pewnego ranka pliki są zaszyfrowane, pojawia się żądanie okupu, zaczyna się odtwarzanie z kopii. W praktyce wygląda to inaczej. Zanim cokolwiek zostanie zaszyfrowane, atakujący jest już w sieci — czasem od kilku dni, czasem od kilku tygodni. I pierwszą rzeczą, której szuka, nie jest baza danych ani udział plikowy. Jest nią backup. Bo firma, która potrafi się odtworzyć, nie ma powodu płacić.

Dlaczego repozytorium kopii jest pierwszym celem, a nie ostatnim

Logika atakującego jest czysto ekonomiczna. Szyfrowanie produkcji to dźwignia negocjacyjna, ale działa tylko wtedy, gdy nie ma alternatywy. Dlatego typowy scenariusz wygląda tak: przejęcie konta z uprawnieniami administratora, rozpoznanie środowiska, znalezienie konsoli systemu backupu, usunięcie lub zaszyfrowanie repozytorium i snapshotów — a dopiero na końcu szyfrowanie danych produkcyjnych.

To wyjaśnia, dlaczego tak wiele firm z „poprawnie działającym backupem" i tak traci dane. Kopia była. Tylko że leżała na serwerze w tej samej sieci, w tej samej domenie, dostępna z tego samego konta administratora, które atakujący zdążył już przejąć. Kopia, którą można skasować poświadczeniami z produkcji, jest kopią wyłącznie do momentu włamania.

Niezmienialność, retention lock i air gap — trzy poziomy oporu

Odporność kopii buduje się warstwowo i warto rozróżniać poziomy, bo różnią się kosztem i skutecznością.

Niezmienialność (immutability) oznacza, że raz zapisany blok danych nie może zostać nadpisany ani skasowany przed upływem zadeklarowanego okresu — nawet przez konto administracyjne. To mechanizm po stronie repozytorium, nie polityki. Nie da się go „wyłączyć na chwilę", bo dokładnie o to chodzi.

Retention lock to jego uzupełnienie: blokada zmiany samej polityki retencji. Bez niej atakujący nie musi kasować danych — wystarczy, że skróci okres przechowywania do zera i poczeka, aż system posprząta się sam.

Air gap to fizyczne lub logiczne odcięcie kopii od sieci produkcyjnej: nośnik wypinany po zakończeniu zadania, repozytorium widoczne tylko w wąskim oknie czasowym, albo kopia w infrastrukturze, do której nie prowadzi żadna trasa z sieci firmowej. Jest najbardziej kłopotliwy operacyjnie i dlatego zwykle stosuje się go do jednej, najstarszej kopii — tej, która ma przetrwać wszystko inne.

Oddziel uwierzytelnienie, nie tylko dyski

Najczęstszy błąd w projektach backupu polega na tym, że separacja kończy się na sprzęcie. Kopia trafia na inną macierz, do innej serwerowni — ale loguje się do niej tym samym kontem domenowym co do reszty środowiska.

Repozytorium kopii nie powinno należeć do produkcyjnej domeny. Konta obsługujące backup powinny być lokalne dla systemu kopii, chronione uwierzytelnianiem wieloskładnikowym i nieużywane do niczego innego. Ruch sieciowy do repozytorium warto ograniczyć do konkretnych adresów i portów potrzebnych do zapisu, a dostęp do konsoli backupu traktować jak dostęp do sejfu, a nie jak kolejną aplikację wewnętrzną. Jeśli przejęcie jednego konta administratora domeny daje dostęp i do produkcji, i do kopii — separacji faktycznie nie ma.

Druga lokalizacja: kopia, której nie obejmie ten sam incydent

Niezmienialność chroni przed skasowaniem. Nie chroni przed pożarem, zalaniem, długą przerwą w zasilaniu ani przed zajęciem sprzętu. Dlatego przynajmniej jedna kopia powinna leżeć poza budynkiem, w którym pracuje produkcja — najlepiej w obiekcie z dwutorowym zasilaniem, zasilaniem awaryjnym UPS oraz agregatem prądotwórczym, klimatyzacją precyzyjną i całodobową ochroną (source: sprintdatacenter.pl/kolokacja-serwerow-w-sdc). To nie jest kwestia paranoi, tylko prostego rozdzielenia ryzyk: incydent, który dotyka jedną lokalizację, nie może z definicji dotknąć drugiej.

Szerzej o samej logice drugiego ośrodka pisaliśmy we wpisie Disaster Recovery i kopia zapasowa w drugiej lokalizacji, a o różnicy między kopią a planem odtwarzania — w tekście Backup to nie Disaster Recovery.

Test odtworzenia — jedyny dowód, że backup istnieje

Zadanie backupu zakończone statusem „sukces" mówi tylko tyle, że dane zostały zapisane. Nie mówi, czy dadzą się odczytać, czy maszyna wstanie, czy aplikacja ruszy, ani ile to potrwa. Odpowiedź na te pytania daje wyłącznie test odtworzenia — wykonany na środowisku izolowanym, z zapisanym czasem trwania i listą tego, co nie zadziałało za pierwszym razem.

Warto go zaplanować cyklicznie i udokumentować, bo obowiązki w zakresie ciągłości działania wynikające z NIS2 i znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa egzekwuje się na podstawie dowodów, a nie deklaracji. Przy okazji: to jedyny moment, w którym dowiesz się, że Twoje realne RTO jest dwa razy dłuższe niż zakładane. Kontrolę bieżącego stanu środowiska ułatwia monitoring 24/7/365 — cichy błąd zadania kopii przez trzy tygodnie to scenariusz spotykany częściej, niż się wydaje.

Ile to realnie kosztuje

Odporna kopia poza firmą nie musi oznaczać dużego projektu. Przestrzeń na backup w Sprint Data Center rozliczana jest za gigabajt — 0,20 PLN netto miesięcznie za GB, a pakiety dodatkowego transferu zaczynają się od 45 PLN netto (source: sprintdatacenter.pl/uslugi-dodatkowe). Jeśli wolisz trzymać własny sprzęt, kolokacja 1U to 90 PLN netto miesięcznie plus energia liczona jako 46 PLN netto za każde 100 W mocy zasilacza, z transferem 10 TB i ochroną anty-DDoS w standardzie (source: sprintdatacenter.pl/kolokacja-serwerow-w-sdc). Przy pierwszym zasiewie danych bywa wygodniejsze wypożyczenie dysku USB na 48 godzin (80 PLN netto jednorazowo), a prace fizyczne przy sprzęcie wykonuje technik w ramach usługi zdalnych rąk — 170 PLN netto za godzinę w dni robocze w godzinach 8:00–20:00 (source: sprintdatacenter.pl/uslugi-dodatkowe).

Podsumowanie

Backup odporny na ransomware to nie osobny produkt, tylko cztery decyzje projektowe: niezmienialność zapisu, blokada polityki retencji, oddzielne uwierzytelnienie i druga lokalizacja — spięte regularnym testem odtworzenia. Każdą z nich można wdrożyć etapami, zaczynając od tej, której u Ciebie brakuje najbardziej.

Jeśli chcesz przenieść kopie poza własną serwerownię, sprawdź kolokację serwerów w Sprint Data Center albo przestrzeń na backup w usługach dodatkowych. Chętnie policzymy wariant dopasowany do Twojego wolumenu danych i wymaganego czasu odtworzenia.

FAQ – najczęściej zadawane pytania o backup odporny na ransomware

Czy kopia na NAS-ie w innym pomieszczeniu wystarczy jako zabezpieczenie przed ransomware?

Zwykle nie. Jeśli NAS jest widoczny z sieci produkcyjnej i obsługiwany kontem domenowym, atakujący dotrze do niego tą samą drogą co do serwerów. Fizyczna odległość w obrębie jednego budynku nie zmienia ścieżki dostępu — liczy się separacja sieciowa i uwierzytelnienia oraz niezmienialność zapisu.

Czym różni się niezmienialność od zwykłej ochrony przed zapisem?

Ochronę przed zapisem administrator może wyłączyć — i dokładnie to zrobi atakujący, który przejmie jego konto. Niezmienialność jest egzekwowana przez samo repozytorium przez zadeklarowany czas i nie da się jej skrócić z poziomu konsoli. To różnica między polityką a mechanizmem.

Jak często testować odtwarzanie z kopii zapasowej?

Zależy od krytyczności systemu, ale rozsądne minimum to jeden pełny test odtworzenia kluczowej usługi na kwartał i test pojedynczych plików co miesiąc. Ważniejsza od częstotliwości jest dokumentacja: zapisany czas odtworzenia i lista problemów, które wystąpiły.

Czy backup w drugiej lokalizacji jest wymagany przez NIS2?

Przepisy nie narzucają konkretnej technologii ani liczby ośrodków — wskazują obowiązki w obszarze zarządzania ryzykiem i ciągłości działania. W praktyce udokumentowana kopia poza podstawową lokalizacją wraz z testami odtworzenia jest najprostszym sposobem wykazania, że te obowiązki są realizowane.

Ile danych trzeba trzymać w kopii niezmienialnej?

Nie musisz obejmować nią wszystkiego. Zacznij od zbiorów, bez których firma się zatrzyma: baz produkcyjnych, konfiguracji systemów, dokumentacji i poczty. Resztę można trzymać w standardowej retencji — to obniża koszt bez pogarszania scenariusza odtworzenia po ataku.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.