Immutable Backup.
Moda czy konieczny element ochrony danych?

Jeszcze kilka lat temu podstawowa strategia backupowa w wielu firmach wyglądała podobnie: dane produkcyjne na serwerze, kopia na NAS-ie lub serwerze backupowym, dodatkowy backup okresowo wysyłany do drugiej lokalizacji.

Taki model nadal może być skuteczny, ale współczesne ataki coraz częściej obejmują również infrastrukturę backupową.

Atakujący, który przejmie konto administratora, nie musi od razu szyfrować serwerów produkcyjnych. Może najpierw odnaleźć system backupowy, usunąć punkty przywracania, skrócić retencję, wyłączyć zadania, skasować kopie off-site albo przejąć klucze szyfrujące. Dopiero po ograniczeniu możliwości odtworzenia danych rozpoczyna właściwe szyfrowanie albo wymuszenie.

Z tego powodu niezmienny backup stał się ważną warstwą nowoczesnej strategii ochrony danych.

Nie jest jednak magiczną funkcją, która automatycznie zabezpiecza każdą kopię. Skuteczność immutability zależy od rodzaju mechanizmu, uprawnień administratorów, retencji, architektury storage i sposobu wdrożenia.

Czym jest immutable backup?

Immutable backup to kopia, której przez określony czas nie można zmodyfikować ani usunąć standardowymi operacjami. Mechanizm może być realizowany przez Object Lock w storage obiektowym, system plików z obsługą niezmienności, hardened repository, sprzętowy lub programowy WORM, taśmy przechowywane poza napędem lub odseparowany serwer z restrykcyjnym modelem uprawnień.

Amazon S3 Object Lock wykorzystuje model WORM, czyli Write Once Read Many, i może blokować usunięcie lub nadpisanie określonej wersji obiektu przez ustalony czas albo bezterminowo. Backblaze B2 udostępnia podobny mechanizm Object Lock, który uniemożliwia zmianę lub usunięcie chronionego pliku przed wskazaną datą.

Immutability nie zawsze oznacza to samo

Określenie „immutable" bywa używane do opisania bardzo różnych poziomów ochrony.

Dlaczego niezmienny backup stał się ważny?

Ransomware atakuje również kopie zapasowe

Atakujący wiedzą, że firma posiadająca działający backup ma mniejszą motywację do zapłacenia okupu. Dlatego przed zaszyfrowaniem produkcji mogą próbować przejąć serwer backupowy, konsolę administracyjną, repozytorium, konta chmurowe lub klucze szyfrujące.

Jeżeli backup można skasować z tego samego konta, które administruje produkcją, atakujący może zniszczyć obie warstwy. Immutability ogranicza ten scenariusz, ponieważ sam dostęp do konsoli backupowej nie powinien wystarczyć do usunięcia chronionych danych.

Ochrona przed błędem administratora

Nie każda utrata backupu jest skutkiem ataku. Administrator może przypadkowo usunąć niewłaściwe zadanie, skrócić retencję, uruchomić pruning na złym repozytorium albo wyczyścić storage podczas migracji. Odpowiednio skonfigurowana blokada retencji daje czas na wykrycie błędu i odzyskanie danych.

Ochrona przed złośliwym działaniem wewnętrznym

Odchodzący administrator, zewnętrzny dostawca lub osoba korzystająca z przejętego konta może celowo usunąć dane lub backupy. Immutability nie rozwiązuje całego problemu insider threat, ale ogranicza możliwość natychmiastowego zniszczenia wszystkich punktów przywracania.

Ochrona przed zbyt szybką propagacją błędu

Replikacja i synchronizacja mogą bardzo szybko przenieść usunięcie, błędną wersję pliku lub zaszyfrowane dane. Niezmienna retencja pozwala zachować starszy punkt mimo propagacji obecnego, uszkodzonego stanu.

Czy immutable backup chroni przed każdym ransomware?

Nie. Niezmienność chroni istniejące punkty przywracania przed zmianą albo usunięciem przez określony czas. Nie gwarantuje, że backup zawiera poprawne dane, został wykonany przed atakiem, nie zawiera już zaszyfrowanych plików ani da się przywrócić.

Jeżeli atakujący pozostaje w środowisku przez 60 dni, a immutable retention wynosi 14 dni, wszystkie dostępne punkty mogą już zawierać dane po kompromitacji.

Dlatego niezmienny backup trzeba połączyć z monitoringiem, dłuższą retencją, wykrywaniem anomalii, testami restore, ochroną tożsamości i segmentacją. Więcej o kompletnej strategii w artykule Czy Twoje backupy przetrwają ransomware?

Retention lock a zwykła retencja

Sama deklaracja „przechowujemy kopie przez 30 dni" nie oznacza więc, że są one niezmienne przez 30 dni. Trzeba sprawdzić, kto może zmienić politykę, kto może usunąć obiekt, czy blokada działa w trybie governance czy compliance i czy można usunąć cały bucket lub konto.

Jak działa S3 Object Lock?

Object Lock działa na wersjach obiektów. Do jego prawidłowego wykorzystania potrzebne jest wersjonowanie - zablokowana zostaje konkretna wersja pliku, której nie można nadpisać ani usunąć w okresie retencji.

Można zastosować domyślny czas retencji dla bucketu, retencję przypisaną do konkretnego obiektu albo legal hold bez określonej daty końcowej. Object Lock nie oznacza jednak, że każdy produkt backupowy automatycznie korzysta z niego poprawnie - narzędzie musi obsługiwać wersjonowanie obiektów, mechanizm retencji, właściwy model usuwania i zachowanie łańcuchów backupowych.

Veeam i niezmienny backup

Veeam obsługuje kilka modeli immutability:

• -Hardened Repository - lokalne lub zdalne repozytorium Linux chroniące pliki backupowe przez określony okres,
• -Object storage - Veeam może korzystać z immutability udostępnianej przez kompatybilny storage obiektowy,
• -Taśmy i WORM - przechowywanie danych na nośnikach taśmowych albo WORM.

Każdy z tych modeli ma inne wymagania, koszt i czas przywracania.

Czy Proxmox Backup Server zapewnia pełną immutability?

Proxmox Backup Server posiada kilka mechanizmów pomagających chronić kopie, ale trzeba je prawidłowo interpretować. Więcej o samym PBS piszemy w artykule Czy naprawdę warto wdrożyć PBS?

Protected backup

Backup można oznaczyć jako chroniony, dzięki czemu nie zostanie automatycznie usunięty przez zadania pruning. Nie jest to jednak pełny WORM. Osoba posiadająca odpowiednie uprawnienia administracyjne może usunąć ochronę i sam backup.

Ograniczenie prawa usuwania

Proxmox rekomenduje, aby klient backupowy otrzymywał minimalne uprawnienia i nie posiadał prawa usuwania kopii. Retencja powinna być wykonywana przez zadania prune uruchamiane lokalnie na PBS. Chroni to między innymi przed sytuacją, w której przejęty host Proxmox usuwa swoje backupy.

Drugi PBS i pull sync

Kopie można synchronizować na drugi Proxmox Backup Server. Bezpieczniejszym modelem jest pobieranie backupów przez serwer docelowy, zamiast wypychania ich z produkcji przy użyciu konta mającego szerokie uprawnienia. Drugi PBS powinien posiadać oddzielne konta, niezależną administrację, własną retencję i ograniczony dostęp sieciowy.

Object storage w PBS

Aktualna linia PBS rozwija obsługę storage obiektowego, ale sam fakt wykorzystania S3 nie oznacza jeszcze poprawnie działającego Object Lock dla każdego scenariusza. Obsługę konkretnego backendu, retencję i proces restore trzeba potwierdzić dla używanej wersji oraz architektury. Roadmapa PBS wskazuje wdrożenie obsługi S3 i object storage jako datastore backend.

PBS może być istotną częścią odpornej strategii, ale nie należy opisywać każdej kopii na PBS jako pełnego immutable backupu odpornego na administratora root.

Backblaze B2, Wasabi i inne storage S3-compatible

Backblaze B2 oferuje Object Lock zgodny z modelem WORM. Po ustawieniu retencji plik nie może zostać zmieniony ani usunięty do określonej daty. Przed wdrożeniem trzeba sprawdzić, czy używane oprogramowanie backupowe wspiera Object Lock B2, sposób ustawiania retencji, tryb governance lub compliance oraz koszty przechowywania i pobierania.

Nie każdy storage kompatybilny z API S3 obsługuje Object Lock w identyczny sposób. Samo oznaczenie usługi jako „S3-compatible" nie gwarantuje prawidłowego działania immutability - trzeba potwierdzić zgodność z używanym systemem backupowym, tryby retencji i zachowanie przy usuwaniu bucketu.

Amazon S3, Glacier i Hetzner Storage Box

Amazon S3 Object Lock może być używany zarówno do ochrony przed ransomware, jak i realizacji wymagań WORM. Klasy storage takie jak Glacier obniżają koszt długoterminowego przechowywania, ale mogą mieć dłuższy czas odzyskania i opłaty za restore. Nie należy wybierać archiwalnej klasy wyłącznie na podstawie ceny za gigabajt - trzeba sprawdzić, czy czas przywrócenia odpowiada RTO firmy.

Hetzner Storage Box może być używany jako lokalizacja off-site, ale nie należy automatycznie przedstawiać go jako odpowiednika S3 Object Lock, WORM czy hardened repository. Można zwiększyć bezpieczeństwo przez oddzielne konto, snapshoty i pull backup, ale to nadal nie ten sam poziom gwarancji co natywny Object Lock w trybie compliance.

Czy immutable backup musi być w chmurze?

Nie. Niezmienną ochronę można zbudować lokalnie, w drugim Data Center, w chmurze publicznej, na taśmach lub w storage obiektowym. Chmura ułatwia geograficzną separację i daje dostęp do Object Lock, ale wprowadza koszt transferu, zależność od dostawcy i wymagania dotyczące kluczy oraz regionu danych.

Lokalny hardened repository może zapewnić szybki restore, ale nie chroni przed utratą całej lokalizacji. Najlepszy model często łączy oba podejścia.

Immutability a szyfrowanie oraz backup offline

Szyfrowanie chroni poufność danych przed odczytaniem przez nieuprawnioną osobę. Immutability chroni kopię przed usunięciem lub zmianą. Zaszyfrowany backup może zostać skasowany. Niezmienny backup bez szyfrowania może zostać odczytany po uzyskaniu dostępu do storage. Dobrze zaprojektowana kopia powinna oferować oba mechanizmy.

Immutable backup jest dostępny online, ale chroniony technicznie przed zmianą - zaletą jest szybki i zautomatyzowany dostęp. Backup offline nie jest stale dostępny w sieci, może być lepiej odseparowany od ataku, ale wymaga obsługi nośników i okresowego podłączania. W środowiskach krytycznych warto rozważyć połączenie obu modeli.

Czy regulacje wymagają immutable backupu?

Nie należy automatycznie twierdzić, że RODO, ISO 27001, NIS2 albo DORA wymagają konkretnego produktu lub funkcji nazwanej immutable backup. Wymagania mogą dotyczyć odporności systemów, ciągłości działania, ochrony przed nieuprawnioną zmianą i możliwości odtworzenia.

Immutability może być bardzo skutecznym środkiem pomagającym spełnić te wymagania. Sama obecność Object Lock nie oznacza jednak zgodności - potrzebne są również procedury, analiza ryzyka, dokumentacja i testy.

Czy każda firma potrzebuje immutable backup?

Nie ma sensownej granicy liczby pracowników. Firma zatrudniająca pięć osób może posiadać krytyczny system księgowy, dane medyczne albo środowisko produkcyjne, którego utrata zatrzyma działalność. Firma zatrudniająca sto osób może posiadać dane łatwe do odtworzenia z innych systemów.

Decyzję należy oprzeć na pytaniach: ile kosztuje utrata danych, czy ransomware może dotrzeć do backupu, czy konto administratora produkcji może usunąć kopie, jak długo atak może pozostać niewykryty i czy istnieje kopia poza lokalizacją.

Dla większości firm posiadających krytyczne dane przynajmniej jedna warstwa odporna na modyfikację jest obecnie bardzo rozsądnym standardem.

Kiedy zwykły backup może być wystarczający?

Prostszy model może być akceptowalny, gdy dane można łatwo odtworzyć, koszt ich utraty jest niski, system nie jest krytyczny, istnieje fizyczna kopia offline, a backup jest dobrze odseparowany i monitorowany.

Nadal trzeba posiadać więcej niż jedną kopię, kopię poza głównym systemem, retencję i test restore. Brak immutability nie oznacza automatycznie braku backupu - oznacza jednak mniejszą odporność na część współczesnych scenariuszy ataku.

Jak dobrać czas niezmiennej retencji?

Zbyt krótki okres może nie objąć czasu, przez jaki napastnik pozostawał w środowisku. Zbyt długi może powodować wysokie koszty storage i brak możliwości usunięcia niepotrzebnych danych.

Przy wyborze należy uwzględnić czas wykrywania incydentów, częstotliwość backupów, liczbę punktów przywracania, typ danych i wymagania prawne. Często stosuje się kilka poziomów: krótka retencja częstych kopii, dłuższa retencja kopii dziennych, miesięczne albo roczne punkty archiwalne. Nie każdy punkt musi mieć identyczny okres immutability.

Jak wygląda dobra architektura?

Jak wdrożyć immutable backup krok po kroku?

1. 1 Inwentaryzacja danych: co jest chronione, gdzie znajdują się dane, kto jest właścicielem, jakie jest RPO i RTO.
2. 2 Analiza obecnych uprawnień: kto administruje produkcją, kto backupem, które konto może usuwać kopie, czy działa MFA.
3. 3 Wybór modelu: hardened repository, Object Lock, WORM, offline, drugi niezależny PBS lub kombinacja kilku mechanizmów.
4. 4 Ustalenie retencji: okres musi wynikać z analizy ryzyka, a nie z domyślnej wartości producenta.
5. 5 Separacja administracyjna: oddzielna tożsamość, oddzielne MFA, minimalne role, brak usuwania po stronie źródła.
6. 6 Wdrożenie pilotażowe: najpierw chroni się wybraną grupę danych i sprawdza zapis, blokadę, retencję, pruning i koszty.
7. 7 Test próby usunięcia: potwierdzenie, że konto backupowe nie może skasować kopii, a administrator produkcji nie może ominąć retencji.
8. 8 Test restore: kopia musi zostać odtworzona do izolowanego środowiska.
9. 9 Monitoring: zgłaszanie braku immutability, zmiany polityki, wygasającej retencji i nieudanego restore.

Najczęstsze błędy

Osoba przejmująca produkcję z tego samego konta przejmuje również backup. Ochrona przed pruning w PBS nie jest tym samym co blokada odporna na administratora. A dane mogą być niezmienne, choć nikt nie posiada informacji, kluczy i procedury potrzebnej do restore.

Czy immutable backup jest droższy i wolniejszy w restore?

Może generować dodatkowy koszt, ponieważ zablokowanych danych nie można wcześniej usunąć. Na koszt wpływają ilość danych, przyrost dzienny, czas retencji, liczba wersji oraz opłaty za operacje i transfer podczas restore. Nie zawsze jednak immutability jest osobno płatną funkcją - część dostawców oferuje ją w ramach storage.

Niezmienność sama w sobie nie musi spowalniać odtwarzania. Czas zależy przede wszystkim od klasy storage, lokalizacji, prędkości sieci i rodzaju repozytorium. Lokalny hardened repository może oferować bardzo szybki restore, a archiwalna klasa storage w chmurze może wymagać znacznie dłuższego oczekiwania. W projekcie trzeba oddzielić wymagania dotyczące ochrony od wymagań dotyczących szybkości odzyskania.

Jak sprawdzić, czy obecny backup jest naprawdę immutable?

Warto odpowiedzieć na pytania:

1. 1 Czy administrator może ręcznie usunąć kopię?
2. 2 Czy można skrócić aktywną retencję?
3. 3 Czy przejęte konto produkcyjne ma dostęp do repozytorium?
4. 4 Czy działa tryb governance czy compliance?
5. 5 Czy zabezpieczone są wszystkie wersje obiektów?
6. 6 Czy można usunąć cały bucket albo konto?
7. 7 Czy drugi serwer ma niezależne uprawnienia?
8. 8 Czy testowaliśmy próbę usunięcia?
9. 9 Czy testowaliśmy restore?
10. 10 Czy klucze szyfrujące są dostępne poza chronionym środowiskiem?

Jeżeli odpowiedzi są niejasne, hasło „immutable" może być wyłącznie nazwą funkcji w ofercie, a nie realną gwarancją ochrony.

Podsumowanie

Immutable backup nie jest chwilową modą. Jest odpowiedzią na realny problem: atakujący coraz częściej próbują niszczyć kopie przed uderzeniem w systemy produkcyjne.

Niezmienność ogranicza możliwość usunięcia backupu, skrócenia retencji, nadpisania punktu i zniszczenia kopii przejętym kontem. Nie zastępuje jednak backupu off-site, szyfrowania, natywnych kopii baz, monitoringu ani testów restore.

Najskuteczniejsza strategia łączy kilka warstw: lokalny backup umożliwiający szybkie odzyskanie, kopię poza główną lokalizacją, warstwę immutable lub offline, oddzielne konta administracyjne oraz regularne testy odtworzenia.

W PRO-Admin nie zaczynamy od wyboru dostawcy Object Lock. Najpierw analizujemy dane, RPO, RTO, retencję, istniejące repozytoria i model uprawnień. Dopiero później dobieramy hardened repository, drugi PBS, storage S3, kopię offline lub połączenie kilku technologii. Celem nie jest posiadanie funkcji nazwanej „immutable". Celem jest zachowanie przynajmniej jednej sprawnej kopii nawet wtedy, gdy produkcja i główne konta administracyjne zostaną przejęte.