Administrator średniej firmy produkcyjnej odpowiada na pytanie o ransomware jednym zdaniem: „mamy niezmienne kopie na macierzy”. Pytanie kontrolne brzmi wtedy zawsze tak samo: czy konto, którym zarządza on produkcją, pozwala skrócić okres retencji tych kopii? Jeżeli tak, mechanizm chroni przed pomyłką operatora, a nie przed atakującym, który to konto przejął trzy tygodnie temu i od tamtej pory spokojnie się rozgląda.
Ten tekst rozdziela trzy rzeczy, które w rozmowach o kopiach zapasowych zlewają się w jedną: właściwość nośnika, granicę administracyjną i procedurę odtworzenia. Każde twierdzenie o mechanizmie podpieramy dokumentem z datą wydania, bo różnica między „nie da się skasować” a „nie da się skasować tym kontem” decyduje o tym, czy firma wróci do pracy. Nie porównujemy produktów — opisujemy mechanizm, który u każdego dostawcy wygląda tak samo, tylko nazywa się inaczej.
Czym różni się kopia niezmienna od migawki i od kopii offline?
Trzema rzeczami: tym, gdzie leży, komu podlega i jak szybko jest osiągalna. Migawka to punkt w czasie wewnątrz tego samego systemu pamięci masowej — dzieli z nim sprzęt, konsolę i zwykle także konta administracyjne. Jest najszybszym sposobem cofnięcia zmiany i najsłabszym zabezpieczeniem przed kimś, kto ma uprawnienia do tej konsoli.
Kopia offline nie ma ścieżki sieciowej do środowiska produkcyjnego, więc złośliwe oprogramowanie nie może jej dosięgnąć. Przewodnik #StopRansomware (CISA, FBI, NSA i MS-ISAC, wersja 3.0 z października 2023 r.) otwiera listę praktyk zaleceniem, by „utrzymywać offline, szyfrowane kopie zapasowe krytycznych danych i regularnie testować dostępność oraz integralność kopii w scenariuszu odtwarzania po awarii” (tłumaczenie własne). Cena jest oczywista: nośnik trzeba podłączyć, a to kosztuje czas w godzinie, w której czasu nie ma.
Kopia niezmienna jest kompromisem między jednym a drugim. Jest osiągalna siecią jak migawka, ale zablokowana przed zmianą jak taśma w sejfie. NIST w publikacji SP 800-209 „Security Guidelines for Storage Infrastructure” (październik 2020) definiuje niezmienność jako „zdolność do zablokowania danych po ich utworzeniu, co uniemożliwia ich zmianę lub usunięcie” (tłumaczenie własne). Definicja mówi o danych — nie o polityce, która o tej blokadzie decyduje, i to jest cała trudność tego tematu.
Ramka: migawka chroni przed błędem w danych, kopia offline przed dostępem sieciowym, kopia niezmienna przed skasowaniem. To trzy różne zagrożenia. Wybieranie jednej z trzech jako „tej najlepszej” jest pytaniem źle postawionym — one się uzupełniają, a nie zastępują.
Co dokładnie blokuje mechanizm niezmienności?
Blokuje zapis i usunięcie danych w zadeklarowanym oknie retencji — i tylko to. Technicznie realizują to mechanizmy z rodziny WORM (write once, read many), blokady obiektu w pamięci obiektowej oraz polityki retencji w oprogramowaniu kopii zapasowych. NIST SP 1800-11 „Data Integrity: Recovering from Ransomware and Other Destructive Events” (wersja finalna, wrzesień 2020, NCCoE) opisuje bezpieczne składowanie jako zdolność „do przechowywania danych z dodatkowymi środkami ochrony, takimi jak technologie Write Once Read Many (WORM) lub szyfrowanie danych” (tłumaczenie własne).
Czego mechanizm nie blokuje, to zmiany samej polityki. Okres retencji jest konfiguracją, a konfiguracją ktoś zarządza. Rekomendacja IS-SS-R10 z NIST SP 800-209 wymienia niezmienną pamięć masową — blokady retencji, blokady repozytorium, polityki niezmienności — jako środek, który „może pomóc dodatkowo odizolować i chronić dane odtworzeniowe” (tłumaczenie własne). Słowo „dodatkowo” jest tu kluczowe: publikacja stawia je jako dziesiątą rekomendację po dziewięciu dotyczących izolacji, nie zamiast nich.
Konsekwencja projektowa jest jedna. Pytanie „czy mamy niezmienne kopie” dotyczy funkcji produktu; pytanie „kto i z jakiego konta może skrócić retencję” dotyczy bezpieczeństwa. Odpowiedź na pierwsze bywa twierdząca tam, gdzie odpowiedź na drugie brzmi „administrator domeny”.
Dlaczego kopia w tej samej domenie uwierzytelniania nie chroni przed ransomware?
Bo atakujący nie łamie mechanizmu — loguje się do niego. Przewodnik #StopRansomware odnotowuje to wprost: „operatorzy ransomware często wyszukują i zbierają poświadczenia przechowywane w atakowanym środowisku i używają ich, by próbować uzyskać dostęp do rozwiązań kopii zapasowych; wykorzystują też publicznie dostępne exploity przeciwko niezaktualizowanym systemom kopii zapasowych” (tłumaczenie własne).
NIST SP 800-209 odpowiada na to rekomendacją IS-SS-R2, która jest najostrzejszym zdaniem całej publikacji w tej sprawie: „systemy pamięci masowej przechowujące kopie odtworzeniowe po cyberataku powinny być zarządzane z wyznaczonych systemów zarządzania, oddzielonych od środowiska produkcyjnego i od każdego innego systemu połączonego z produkcją (w tym od mechanizmów ochrony danych). Nie powinno być możliwe uzyskanie dostępu do takich systemów zarządzania za pomocą zwykłych poświadczeń (w tym produkcyjnych i zwykłych backupowych)” (tłumaczenie własne).
Rekomendacja IS-SS-R3 dopowiada, po co: „zapewnia to, że w razie skompromitowania poświadczeń administratora IT atakujący nie może ich użyć do uzyskania dostępu do kopii odtworzeniowych po cyberataku” (tłumaczenie własne). To nie jest postulat estetyczny — to jedyna właściwość, która odróżnia kopię odporną na atak od kopii odpornej na awarię. Ten sam wniosek stoi u podstaw architektury zerowego zaufania: NIST SP 800-207 (sierpień 2020) w trzeciej zasadzie stwierdza, że „uwierzytelnienie i autoryzacja do jednego zasobu nie przyznaje automatycznie dostępu do innego zasobu” (tłumaczenie własne).
Które warstwy trzeba rozdzielić, żeby niezmienność miała sens?
Trzy, i NIST SP 800-209 nazywa je osobnymi rekomendacjami. Pierwsza to nośnik i system: według IS-SS-R1 kopie odtworzeniowe „powinny być tworzone w wyznaczonych, oddzielonych środowiskach pamięci masowej”, a „w chmurach prywatnych oznacza to fizycznie rozdzielone systemy pamięci masowej”, zaś „w chmurach publicznych — osobne konta (lub ich odpowiednik)” (tłumaczenie własne). Druga to konsola zarządzania (IS-SS-R2, omówiona wyżej). Trzecia to poświadczenia (IS-SS-R3): dostęp do kopii odtworzeniowych ma wąska grupa używająca danych logowania innych niż te do codziennych obowiązków.
Do tego dochodzą dwie rekomendacje, o których w projektach zapomina się najczęściej. IS-SS-R4 wymaga, by „kopie odtworzeniowe po cyberataku były składowane poza lokalizacją, w której składowane są dane produkcyjne” (tłumaczenie własne). IS-SS-R5 zakazuje, by kopie odtworzeniowe zależały od produkcyjnej kopii bazowej — co uderza w popularny schemat, w którym cała historia przyrostowa wisi na jednym pełnym backupie stojącym obok produkcji.
Jest jeszcze warstwa, której nie widać na schemacie: sposób odtwarzania. Zgodnie z IS-SS-R7 „kopie odtworzeniowe po cyberataku nie powinny być montowane, eksportowane ani mapowane do hosta lub aplikacji”, lecz odtwarzane „(wypychane) do odizolowanego środowiska przejściowego (lub odseparowanego air gapem), a nie bezpośrednio na docelowe hosty lub aplikacje” (tłumaczenie własne). Kopia niezmienna zamontowana jako dysk na zainfekowanym serwerze przestaje być izolowana, choć nadal jest niezmienna.
Kto może skrócić okres retencji i dlaczego to jest właściwe pytanie?
Bo to jedyne pytanie, na które odpowiedź da się sprawdzić, a nie zadeklarować. Niezmienne repozytorium jest warte tyle, ile jego granica administracyjna — ten sam wniosek notujemy przy okazji przejęcia Object First przez firmę Veeam, gdzie ocena urządzenia sprowadza się do tego, kto i skąd może zmienić politykę, a nie jak nazywa się mechanizm.
W typowym wdrożeniu odpowiedzi są trzy i różnią się o rząd wielkości pod względem ryzyka. Retencję może skracać konto administratora domeny produkcyjnej — wtedy ochrona jest pozorna. Może ją skracać osobne konto w systemie backupu uwierzytelniane w tej samej domenie — wtedy ochrona kończy się w chwili przejęcia kontrolera domeny. Albo może jej nie skracać nikt do upływu terminu, a zmiana polityki wymaga dwóch osób z poświadczeniami spoza produkcji — i dopiero to odpowiada rekomendacjom IS-SS-R2 i IS-SS-R3.
Pytanie dotyczy też dostawcy: jeżeli kopia leży w chmurze, granicą administracyjną jest konto w tej chmurze; jeżeli w urządzeniu w serwerowni — konto serwisowe producenta. Projekt, który tych ścieżek nie opisuje, opisuje część układu. Zaprojektowanie granicy i procedury odtwarzania mieści się w zakresie kompleksowych usług dla rozwiązań backupowych.
Czy air gap to to samo co niezmienność?
Nie, choć oba słowa padają w tym samym zdaniu ofert. Rekomendacja IS-SS-R8 z NIST SP 800-209 rozróżnia dwa poziomy: ścisłe wdrożenia air gap „powinny zapewniać pełną separację fizyczną i sieciową”, natomiast pewne technologie pamięci masowej wprowadzają mniej ścisłe mechanizmy izolacji, również nazywane air gapem, które „polegają na wyłączaniu portów danych i otwieraniu ich na ograniczony czas okresowej synchronizacji z systemem produkcyjnym” (tłumaczenie własne).
Różnica jest praktyczna, nie terminologiczna. Air gap odbiera atakującemu ścieżkę dostępu przez większość okna czasowego; niezmienność odbiera mu prawo do zmiany danych wtedy, gdy ścieżkę ma. Mechanizm z okresowym otwieraniem portów łączy obie słabości, jeśli okno synchronizacji jest sterowane z produkcji.
Publikacja zaleca ważyć skuteczność każdej z technik „w oparciu o wartość danych i możliwości przeciwnika” (tłumaczenie własne), a przy ścisłych wdrożeniach wymienia zagrożenia, o których łatwo zapomnieć: kanały sygnałowe, bezprzewodowe zdolności transmisyjne sprzętu i wystawione porty danych. Osobno o tym, dlaczego rozdzielenie kopii od infrastruktury produkcyjnej jest własnym wymogiem, piszemy w tekście o zasadzie 3-2-1 w backupie.
Czego niezmienność nie rozwiązuje?
Trzech rzeczy, z których każda potrafi wywrócić odtworzenie. Po pierwsze — wycieku. Niezmienna kopia gwarantuje, że dane będą, nie że nie zostaną skopiowane. Model podwójnego wymuszenia, w którym napastnik najpierw wynosi dane, a dopiero potem szyfruje, jest wobec niezmienności obojętny.
Po drugie — czasu. Niezmienność nie skraca odtwarzania; potrafi je nawet wydłużyć, jeśli kopia leży w pamięci obiektowej o niskim koszcie i niskiej przepustowości odczytu. Rekomendacja RA-SS-R4 z NIST SP 800-209 mówi, że zdolność do dotrzymania celu czasu odtworzenia „powinna być badana całościowo, z uwzględnieniem wszystkich zależnych i powiązanych składników” (tłumaczenie własne) — a nie mierzona szybkością samego nośnika.
Po trzecie — kosztu błędu konfiguracji. Przewodnik #StopRansomware formułuje to jako ostrzeżenie: „korzystaj z niezmiennej pamięci masowej z ostrożnością, ponieważ nie spełnia ona kryteriów zgodności niektórych regulacji, a błędna konfiguracja może narzucić znaczny koszt” (tłumaczenie własne). Blokada retencji ustawiona na trzy lata zamiast trzydziestu dni jest nieodwracalna z definicji — i płatna co miesiąc. Rachunek za samo odtworzenie po ataku rozkładamy na czynniki w tekście o tym, ile kosztuje ransomware dla firmy.
Co jeszcze musi znaleźć się w kopii, żeby odtworzenie w ogóle było możliwe?
Znacznie więcej niż pliki użytkowników i bazy danych. Rekomendacja RA-SS-R1 wymienia elementy, które muszą być objęte ochroną, żeby odtworzenie po ataku było wykonalne — w oryginale są to „wolumeny pamięci masowej, krytyczne systemy plików, bazy danych, obrazy oprogramowania, certyfikaty, klucze szyfrujące, pliki startowe, informacje katalogowe, listy kontroli dostępu, ustawienia wirtualizacji i pliki konfiguracyjne” (tłumaczenie własne).
RA-SS-R2 dodaje składniki zależne — wymienia wprost „Active Directory i DNS” oraz zewnętrzne systemy zarządzania kluczami (tłumaczenie własne) — bez których odtworzenie danych nie odtwarza działającej usługi. To najczęstsza luka, jaką widzimy przy przeglądach: kopia obejmuje dane biznesowe i nie obejmuje tego, co pozwala je uwierzytelnić i zaadresować.
RA-SS-R9 dokłada wymóg, który zmienia sposób projektowania: „dane powinny być oddzielone od aplikacji, aby umożliwić ich odtworzenie bez przywracania zainfekowanego kodu lub oprogramowania” (tłumaczenie własne). Kopia obrazu maszyny wirtualnej sprzed ataku bywa kopią maszyny już skompromitowanej — a wtedy odtworzenie jest przywróceniem punktu wyjścia napastnika.
Jak sprawdzić u siebie, czy kopia jest naprawdę niezmienna?
Czterema krokami, z których żaden nie wymaga projektu ani zgody zarządu — wystarczy okno serwisowe i dwie osoby. To procedura, którą stosujemy na wejściu do przeglądów środowisk backupowych, zanim padnie pytanie o architekturę docelową.
Krok pierwszy: próba skrócenia retencji. Z konta administratora środowiska produkcyjnego spróbuj zmienić politykę retencji na repozytorium kopii. Jeżeli operacja się powiedzie albo choćby pojawi się w interfejsie jako dostępna, mechanizm nie spełnia IS-SS-R2 i chroni przed pomyłką, nie przed atakiem.
Krok drugi: odtworzenie próbne do środowiska izolowanego. RA-SS-R5 wymaga okresowego odtworzenia testowego potwierdzającego, że kończy się powodzeniem i mieści w wymaganym czasie. Wypchnij kopię do środowiska przejściowego, nie na cel produkcyjny (IS-SS-R7), i zmierz czas — nie przepisuj go z karty katalogowej.
Krok trzeci: kontrola kompletu zależności. Sprawdź na liście z RA-SS-R1 i RA-SS-R2, czy kopia obejmuje usługę katalogową, DNS, klucze i konfiguracje. Odtworzenie bazy bez uwierzytelnienia jest odtworzeniem pliku, nie usługi.
Krok czwarty: higiena kopii. RA-SS-R11 zaleca skanowanie kopii odtworzeniowych narzędziami antywirusowymi i analitycznymi, a gdy komplet jest za duży, skanowanie podzbioru z zapisem, które kopie objęto. Bez tego kroku nie wiadomo, którą wersję odtwarzać. Ten sam test odtworzeniowy jest jednocześnie najtwardszym dowodem w audycie — piszemy o tym w tekście o strategiach zapobiegania ransomware.
Jak często weryfikować izolację i kondycję kopii?
Co najmniej raz w roku, a przy danych wrażliwych częściej. Rekomendacja IS-SS-R9 wymaga okresowych przeglądów izolacji przynajmniej raz w roku; o systemach wrażliwych i cennych mówi, że „mogą wymagać audytu co najmniej kwartalnego oraz po każdej większej zmianie — zależnie od tego, co nastąpi wcześniej” (tłumaczenie własne). Wyniki przeglądu mają być udokumentowane.
Kondycja kopii to osobny zegar. RA-SS-R8 każe okresowo potwierdzać, że kopie są w dobrym stanie — bez istotnych błędów w dziennikach, ze sprawnym nośnikiem — nie rzadziej niż raz w roku, a jako punkt wyjścia proponuje „utrzymywanie proporcji próby na poziomie od rzędu do półtora rzędu wielkości niższym niż częstotliwość wykonywania kopii” (tłumaczenie własne).
Warto zestawić to z wymaganiem CIS Critical Security Control 11 „Data Recovery”, które w warstwie celu brzmi krótko: „ustanów i utrzymuj praktyki odtwarzania danych wystarczające do przywrócenia objętych zakresem zasobów przedsiębiorstwa do stanu sprzed incydentu i stanu zaufanego” (tłumaczenie własne; odczyt strony CIS 18 września 2026 r.). Słowo „zaufanego” robi tu całą robotę: przywrócenie stanu sprzed incydentu nie wystarcza, jeśli ten stan zawierał już implant napastnika.
Od czego zacząć, zależnie od tego, co już masz?
Od rozpoznania, na którym z trzech poziomów stoi dzisiejszy układ. Poniższa tabela jest narzędziem decyzyjnym: kolumna środkowa opisuje obserwowalny stan, a nie deklarację dostawcy, więc każdą pozycję da się sprawdzić w ciągu jednego okna serwisowego.
| Stan zastany | Jak go rozpoznać bez projektu | Pierwszy krok | Rekomendacja źródłowa |
|---|---|---|---|
| Kopie bez blokady | polityka retencji edytowalna z konsoli backupu bez dodatkowego uwierzytelnienia | włączyć blokadę retencji na repozytorium kopii odtworzeniowych | IS-SS-R10 |
| Blokada jest, konta wspólne | konto administratora domeny widzi repozytorium i może zmienić politykę | wydzielić konsolę zarządzania i poświadczenia spoza produkcji | IS-SS-R2, IS-SS-R3 |
| Konta rozdzielone, brak testu | nikt nie potrafi podać daty ostatniego odtworzenia próbnego | zaplanować odtworzenie do środowiska izolowanego i zmierzyć czas | RA-SS-R5, IS-SS-R7 |
| Test jest, zakres niepełny | w kopii brakuje usługi katalogowej, DNS albo kluczy | uzupełnić zakres o składniki zależne i powtórzyć test | RA-SS-R1, RA-SS-R2 |
| Wszystko powyżej działa | jest data przeglądu izolacji i data skanowania kopii | ustawić kadencję przeglądów i udokumentować wyniki | IS-SS-R9, RA-SS-R8, RA-SS-R11 |
Kolejność ma znaczenie. Włączenie blokady retencji przy wspólnych kontach daje poczucie bezpieczeństwa bez jego przyrostu, a przy okazji potrafi zablokować pojemność na lata. Dopiero komplet — blokada, rozdzielenie kont i zmierzony test — zamienia zdanie „mamy niezmienne kopie” w twierdzenie, które da się obronić przed audytorem i przed napastnikiem.
Ramka na koniec: jedno pytanie do zadania jutro brzmi: z jakiego konta i z jakiej konsoli da się dziś skrócić retencję naszych kopii? Odpowiedź „nie wiem” też jest odpowiedzią — i jest tą najczęstszą.
Projektowanie granicy administracyjnej wokół kopii, wybór mechanizmu i test odtworzeniowy prowadzimy jako jedno zadanie w ramach usług backupu i disaster recovery. Mechanizmy niezmienności w środowisku Veeam opisujemy osobno w tekście o platformie Veeam Backup & Replication — tam chodzi o implementację u jednego dostawcy, tutaj o właściwość układu niezależną od nazwy produktu.
Źródła przywołane w tekście: NIST SP 800-209 „Security Guidelines for Storage Infrastructure” (październik 2020); NIST SP 1800-11 „Data Integrity: Recovering from Ransomware and Other Destructive Events” (wersja finalna, wrzesień 2020, NCCoE); NIST SP 800-207 „Zero Trust Architecture” (sierpień 2020); #StopRansomware Guide (CISA, FBI, NSA, MS-ISAC, wersja 3.0, październik 2023); CIS Critical Security Control 11 „Data Recovery” (odczyt 18 września 2026 r.).
Najczęściej zadawane pytania
Czym jest backup niezmienny (immutable) i przed czym naprawdę chroni?
To kopia zapisana w taki sposób, że po utworzeniu nie da się jej zmienić ani usunąć przed upływem zadeklarowanego okresu retencji. NIST w publikacji SP 800-209 „Security Guidelines for Storage Infrastructure" (październik 2020) definiuje niezmienność jako „zdolność do zablokowania danych po ich utworzeniu, co uniemożliwia ich zmianę lub usunięcie" (tłumaczenie własne). Chroni to przed skasowaniem kopii — ale tylko w takim zakresie, w jakim osoba lub proces zdolny skrócić retencję jest oddzielony od środowiska produkcyjnego. Jeżeli tym samym kontem można zarządzać produkcją i polityką retencji, mechanizm chroni przed pomyłką, a nie przed atakującym.
Czy niezmienna kopia w chmurze wystarczy, żeby przestać się martwić o ransomware?
Nie. Przewodnik #StopRansomware (CISA, FBI, NSA i MS-ISAC, wersja 3.0 z października 2023 r.) ostrzega: „korzystaj z niezmiennej pamięci masowej z ostrożnością, ponieważ nie spełnia ona kryteriów zgodności niektórych regulacji, a błędna konfiguracja może narzucić znaczny koszt" (tłumaczenie własne). Ten sam przewodnik odnotowuje, że operatorzy ransomware zbierają poświadczenia znalezione w atakowanym środowisku i używają ich, by sięgnąć do rozwiązań kopii zapasowych. Niezmienność jest jednym z warunków, nie całą odpowiedzią.
Czym niezmienna kopia różni się od migawki i od kopii offline?
Migawka jest punktem w czasie wewnątrz tego samego systemu i dzieli z nim los oraz zwykle domenę zarządzania — skasowanie woluminu lub przejęcie konsoli macierzy usuwa także migawki. Kopia offline jest fizycznie odłączona, więc atakujący nie ma do niej ścieżki sieciowej, ale jej odtworzenie wymaga czasu na podłączenie nośnika. Kopia niezmienna jest osiągalna siecią i jednocześnie zablokowana przed zmianą na czas retencji. Te trzy właściwości nie zastępują się nawzajem i w praktyce projektowej występują razem.
Czy air gap i niezmienność to to samo?
Nie. NIST SP 800-209 w rekomendacji IS-SS-R8 rozróżnia dwa poziomy: ścisłe wdrożenia air gap „powinny zapewniać pełną separację fizyczną i sieciową", a obok nich istnieją mniej ścisłe mechanizmy izolacji, również nazywane air gapem, które „polegają na wyłączaniu portów danych i otwieraniu ich na ograniczony czas okresowej synchronizacji z systemem produkcyjnym" (tłumaczenie własne obu fragmentów). Air gap odbiera atakującemu ścieżkę dostępu; niezmienność odbiera mu prawo do zmiany danych, do których dostęp ma. Ta sama rekomendacja każe ważyć skuteczność każdej z technik „w oparciu o wartość danych i możliwości przeciwnika" (tłumaczenie własne).
Jak sprawdzić, czy kopia w mojej firmie jest naprawdę niezmienna?
Najkrótszy sprawdzalny test to próba skrócenia retencji z konta administratora produkcji — jeśli się uda, mechanizm nie chroni przed przejęciem tego konta. Drugim krokiem jest odtworzenie próbne, bo NIST SP 800-209 w sekcji 4.8 każe organizacjom zweryfikować, że krytyczne zasoby danych „dają się odtworzyć wiernie, spójnie i w całości" (tłumaczenie własne) — a nie tylko że kopie powstają. Trzecim — sprawdzenie, czy w kopii są składniki zależne: usługa katalogowa, DNS, klucze szyfrujące i pliki konfiguracyjne. Bez nich odtworzenie danych nie odtwarza usługi.
