Dlaczego ransomware czyni kopie zapasowe celem, a nie siatką bezpieczeństwa
Przez lata backup był tym wyjątkiem, który pozwalał przetrwać atak ransomware: zaszyfrowane środowisko produkcyjne odtwarzano z kopii zapasowej i szło się dalej. Atakujący nadrobili jednak zaległości. W badaniu Veeam 2025 Ransomware Trends, obejmującym 1300 organizacji dotkniętych atakiem, 89% miało zaatakowane repozytoria kopii zapasowych jako element ataku — nie jako działanie poboczne, lecz jako pełnoprawny cel w ramach kill chain. Zniszczenie lub uszkodzenie planu awaryjnego przed zaszyfrowaniem środowiska produkcyjnego to dziś standardowa procedura, ponieważ pozbawia ofiarę jakiejkolwiek przewagi, zanim jeszcze dotrze żądanie okupu.
Efekt widać w danych o odzyskiwaniu. Raport Sophos State of Ransomware 2025 pokazał, że tylko 54% organizacji użyło kopii zapasowych do odtworzenia danych po ataku — najniższy wskaźnik w sześcioletniej historii tego badania. Wśród organizacji, które ostatecznie zapłaciły więcej niż pierwotnie żądano, 38% wskazało niedziałające lub wadliwe kopie zapasowe jako powód, dla którego nie miały lepszej opcji. Kopia zapasowa, która istnieje tylko na papierze, to nie to samo co kopia, którą da się bez problemu odtworzyć pod presją czasu.
Ta różnica — między „mamy kopie zapasowe” a „mamy kopie zapasowe odporne na ransomware” — sprowadza się do trzech filarów: niezmienności, izolacji i przetestowanego procesu przywracania. To nie są niezależne mechanizmy, które można dowolnie mieszać i dopasowywać. Brak choćby jednego z nich sprawia, że pozostałe dwa nie rekompensują straty — niezmienna kopia zapasowa, do której atakujący nie ma dostępu, jest użyteczna tylko wtedy, gdy faktycznie da się z niej odtworzyć dane, a dobrze przetestowany plan przywracania jest bezwartościowy, jeśli kopia, na której się opiera, została usunięta, zanim jeszcze rozpoczęto ćwiczenia.
Trzy filary — szczegółowo
1. Niezmienność: kopie zapasowe, których atakujący nie może dotknąć
Niezmienność oznacza, że kopii zapasowej nie da się zmienić ani usunąć w oknie retencji — ani przez błędnie skonfigurowany skrypt retencji, ani przez przejęte konto administratora, ani przez atakującego, który zdobył już poświadczenia administratora domeny. W praktyce wymusza się ją przez blokadę obiektów (object lock) w chmurze lub w pamięci masowej obiektowej, sprzęt typu WORM (Write Once Read Many — zapis jednokrotny, odczyt wielokrotny) albo hartowane (hardened) repozytorium linuksowe z blokadami retencji egzekwowanymi na poziomie warstwy przechowywania, niezależnie od mechanizmów kontroli dostępu samej aplikacji backupowej.
To rozróżnienie ma znaczenie, bo współczesne grupy ransomware aktywnie poszukują repozytoriów kopii zapasowych osiągalnych za pomocą poświadczeń produkcyjnych i usuwają je lub szyfrują jako pierwsze, zanim jeszcze dotkną danych podstawowych. Jeśli to samo konto administracyjne, które zarządza oprogramowaniem do backupu, może również usunąć punkty przywracania sprzed miesiąca, niezmienność w rzeczywistości nie obowiązuje — to tylko ustawienie, które wystarczająco uprzywilejowany atakujący wyłączy w kilka minut.
Wytyczne CISA dotyczące ransomware są w tej kwestii jednoznaczne: utrzymuj kopie zapasowe offline, szyfrowane i niezmienne, weryfikuj je regularnie i traktuj je jako ostatnią linię obrony, a nie jako pierwszą przeszkodę, którą musi pokonać atakujący.
2. Izolacja: osobna warstwa tożsamości i kopia, do której atakujący w ogóle nie ma dostępu
Niezmienność chroni kopię zapasową przed zmianą. Izolacja chroni ją przed samym dostępem do niej. Te dwa mechanizmy się uzupełniają, a nie zastępują — a organizacje, które wdrażają tylko jeden z nich, zwykle odkrywają tę lukę dopiero podczas realnego incydentu, a nie podczas przeglądu architektury.
Izolacja składa się z dwóch elementów. Pierwszy to osobna warstwa tożsamości — infrastruktura backupowa nie powinna ufać tej samej domenie Active Directory, tym samym poświadczeniom administracyjnym ani temu samemu płaskiemu segmentowi sieci co środowisko produkcyjne. Przejęty kontroler domeny nie powinien automatycznie oznaczać przejętego środowiska backupowego — jeśli tak się dzieje, atakującemu wystarczyło przejąć jedną rzecz, a nie dwie. Drugi element to prawdziwie kopia offline lub w pełni odizolowana (air-gap) — co najmniej jedna kopia danych krytycznych, która nie ma żadnej stałej ścieżki sieciowej ze środowiska produkcyjnego, niezależnie od tego, czy osiąga się to przez rotację taśm offline, odłączony cel replikacji podłączany do sieci tylko na krótko w celu odebrania danych, czy warstwę chmurową bez trwałych poświadczeń przechowywanych gdziekolwiek w zasięgu środowiska produkcyjnego.
Z badań Veeam wynika, że organizacje, które priorytetowo traktują tego rodzaju warstwową, izolowaną odporność, odzyskują sprawność po atakach ransomware nawet siedmiokrotnie szybciej niż te, które tego nie robią, przy wyraźnie mniejszej utracie danych po drodze. To właśnie izolacja umożliwia tę różnicę: to różnica między atakującym, który musi wykonać realną dodatkową pracę, by dotrzeć do punktu przywracania, a takim, który ma już otwartą sesję do niego, ponieważ dzieli on warstwę tożsamości z systemami, które właśnie przejął.
3. Przetestowane przywracanie: udowodnij odtwarzalność, zanim będzie potrzebna
Najmniej efektowny z trzech filarów to zarazem ten, który organizacje pomijają najczęściej — i widać to w wynikach. W badaniu branżowym z 2025 roku 62% organizacji przyznało, że nie przeprowadza regularnych testów tworzenia i przywracania kopii zapasowych, a 37% stwierdziło, że nie było w stanie odzyskać danych w wymaganym docelowym czasie przywrócenia (RTO) właśnie dlatego, że kopie zapasowe były niekompletne albo po prostu nigdy nie zostały zweryfikowane. Pewność siebie i rzeczywistość rozjeżdżają się tu wyraźnie: ponad 60% organizacji wierzy, że jest w stanie odzyskać sprawność po awarii w ciągu kilku godzin, ale gdy się to faktycznie sprawdza, udaje się to tylko mniej więcej jednej trzeciej.
Nieprzetestowane procesy przywracania zawodzą w sposób, który pozostaje niewidoczny aż do momentu, gdy ma to największe znaczenie: przerwane łańcuchy kopii zapasowych, brakujące zależności zapewniające spójność aplikacji, poświadczenia kont serwisowych wygasłe miesiące wcześniej albo runbooki napisane dla topologii infrastruktury, która już nie istnieje. Pominięcie weryfikacji niesie ze sobą ryzyko poważniejsze niż zwykły przestój — szacuje się, że 63% organizacji ryzykuje ponowne wprowadzenie infekcji podczas przywracania, ponieważ pod presją czasu pomija skanowanie integralności i malware, w efekcie odzyskując ten sam złośliwy ładunek, który spowodował awarię.
Prawdziwy program przetestowanego przywracania oznacza zaplanowane, pełne ćwiczenia odtworzeniowe w izolowanym środowisku odzyskiwania — a nie tylko powiadomienia typu „zadanie backupu zakończone sukcesem” — zweryfikowane względem RTO, których biznes rzeczywiście potrzebuje, a nie liczb, które po prostu dobrze wyglądają w prezentacji.
Jak to wygląda, gdy wszystkie trzy filary działają
Dane Sophos z 2025 roku dają użyteczny kontrprzykład dla nagłówkowych statystyk: wśród organizacji, których dane zostały zaszyfrowane przez atakującego, 97% było w stanie je odzyskać. Różnica między tą grupą a niewielką mniejszością, której się to nie udało, niemal zawsze sprowadza się do tego, że jeden z trzech filarów był w praktyce słabszy, niż wyglądał na papierze — blokada retencji, którą dało się obejść przy pomocy niewłaściwej roli, „osobna” sieć backupowa, która wciąż ufała tej samej domenie, albo proces przywracania, który nigdy nie został przećwiczony od początku do końca.
Cena błędu
Te trzy filary to nie abstrakcyjna lista dobrych praktyk — przekładają się bezpośrednio na to, ile kosztuje incydent ransomware i jak długo trwa. Średni koszt odzyskania sprawności po ataku ransomware, nieuwzględniający ewentualnie zapłaconego okupu, sięga około $1.53 million. Tylko 53% ofiar w pełni odzyskało sprawność w ciągu tygodnia; reszta spędziła w jakimś stanie zakłócenia dłużej niż siedem dni, a przestój, utracona produktywność i praca zespołu reagowania na incydenty kumulowały się z dnia na dzień.
Stan zabezpieczeń backupu to jedna z niewielu zmiennych w tym równaniu, którą organizacja w pełni kontroluje. To, czy pierwsze uderzenie atakującego w repozytorium kopii zapasowych się powiedzie, zależy wyłącznie od decyzji podjętych miesiące wcześniej — nie w trakcie samego incydentu. Zanim aktor zagrożenia zdobędzie poświadczenia administratora domeny i zacznie sondować twoją platformę backupową, niezmienność, izolacja i przetestowane przywracanie albo już działają, albo nie — pod presją nie ma już okazji, by je wdrożyć.
Częste błędy, które po cichu podważają wszystkie trzy filary
W analizach poincydentalnych regularnie powtarza się kilka schematów:
- Mylenie snapshotów z kopiami zapasowymi. Snapshot VMware to migawka stanu w danym momencie, przechowywana na tym samym datastore co chroniona przez nią maszyna wirtualna — a nie niezależna kopia. Rośnie w sposób nieograniczony, obniża wydajność i znika w chwili, gdy przestaje istnieć datastore. Snapshoty to funkcja wygody służąca do krótkotrwałego cofania zmian, a nie strategia odzyskiwania danych.
- Traktowanie „niezmienności” jako punktu do odhaczenia, a nie zweryfikowanej właściwości. Object lock i polityki retencji trzeba przetestować dokładnie pod kątem tej roli administracyjnej, która zarządza platformą backupową — nie wystarczy je jedynie opisać w dokumentacji konfiguracyjnej.
- Nazywanie „izolowaną” drugiej kopii w tej samej domenie tożsamości. Jeśli te same poświadczenia, które zostały przejęte w środowisku produkcyjnym, umożliwiają uwierzytelnienie do repozytorium kopii zapasowych, separacja geograficzna czy platformowa nie zapewnia realnej izolacji.
- Mierzenie sukcesu ukończeniem backupu, a nie weryfikacją przywracania. Zielony znacznik przy wczorajszym zadaniu mówi tylko, że dane gdzieś zapisano. Nie mówi, że da się je odzyskać, że są spójne z perspektywy aplikacji i że są wolne od złośliwego oprogramowania, które w pierwszej kolejności wymusiło przywracanie.
W czym pomaga BackupSec
W BackupSec pomagamy zespołom w dużych organizacjach zarządzać środowiskami backupowymi dokładnie w oparciu o te trzy filary — nie zastępując platformy backupowej, lecz sprawiając, że bezpieczeństwo backupu staje się obserwowalne, doradzalne i możliwe do udowodnienia.
Nasze podejście łączy trzy warstwy:
- ZeroMON zapewnia ciągłą obserwowalność całego środowiska backupowego — monitoring gotowy pod Veeam, ze śledzeniem zadań w czasie rzeczywistym, automatycznymi kontrolami bezpieczeństwa, śladami audytowymi umożliwiającymi analizę driftu konfiguracji oraz raportami zgodności generowanymi jednym kliknięciem. To ta warstwa, która zmienia stwierdzenie „niezmienność jest skonfigurowana” z założenia w dowód.
- ZeroTAM zapewnia dedykowane doradztwo eksperckie w zakresie architektury backupu, projektowania izolacji i planowania odzyskiwania po ransomware — to warstwa ludzka, której potrzebuje większość organizacji, by zrozumieć, co ich środowisko backupowe naprawdę im mówi, i zaprojektować izolację, która przetrwa kontakt z realnym incydentem.
- ZeroPEN przeprowadza testy penetracyjne infrastruktury backupowej dokładnie tak, jak zrobiłby to prawdziwy przeciwnik — atakując warstwy zarządzania, kontrole dostępu i ustawienia niezmienności — a następnie uruchamia rzeczywiste scenariusze przywracania, by potwierdzić, że możesz odzyskać dane w sposób czysty, kompletny i w zadeklarowanym RTO, a nie tylko że zadanie backupu zgłosiło sukces.
BackupSec wdrażany jest on-premise, łączy się z aplikacjami backupowymi wyłącznie przez dostęp API w trybie tylko do odczytu i nigdy nie przenosi danych backupowych poza twoje środowisko.
Porozmawiaj z BackupSec o bezpieczeństwie swojego backupu →
Chcesz sprawdzić, czy twoje własne kopie zapasowe wytrzymałyby taki test? Oceń swoje środowisko za pomocą bezpłatnego Backup Security Assessment.