Cel: weryfikacja odporności backupów na ataki ransomware
Odporne kopie zapasowe to ostatnia bariera, gdy produkcja zostanie zaszyfrowana. Celem jest nie tyle „posiadanie backupu”, ile możliwość pewnego odtworzenia danych w czasie zgodnym z RTO/RPO, bez ryzyka, że kopie także zostały zaszyfrowane lub nadpisane. Weryfikacja musi być dowodem w działaniu: test przywracania, kontrola izolacji, potwierdzona niemodyfikowalność (immutability) oraz wskaźniki pokazujące, że proces działa stale.
Cechy odpornego systemu backupów
Izolacja
Repozytorium backupów nie może być dostępne z tych samych sieci i kont, które obsługują produkcję. Minimalny model: dedykowana strefa sieciowa, kierunkowe reguły dostępu (tylko push z proxy/agentów), brak interaktywnego logowania z kont produkcyjnych, oddzielna domena/PKI dla usług backupowych.
Wersjonowanie
Backup bez wielu punktów przywracania to pozór bezpieczeństwa. Wymagane są: retencja wielowersyjna, polityki GFS (daily/weekly/monthly), możliwość przywrócenia do konkretnego punktu w czasie oraz wiarygodne metadane spójności (hashy, katalogów).
Szyfrowanie
Dane w locie i w spoczynku powinny być szyfrowane, ale klucze nie mogą być trzymane razem z repozytorium. Kluczowe jest rozdzielenie ról: system backupu szyfruje, ale materiał kluczowy rotuje osobny HSM/KMS, do którego nie mają dostępu konta aplikacyjne produkcji.
Immutability (WORM)
Mechanizm, który uniemożliwia modyfikację lub usunięcie bloków danych i metadanych przez określony czas retencji. W praktyce: obiektowe WORM (S3 Object Lock w trybie Compliance/Governance), niekasowalne snapshoty, air-gap w formie fizycznej lub logicznej.
Testy praktyczne, które realnie wykrywają słabości
Symulacja szyfrowania plików
Na wydzielonym sandboxie odtwórz fragment produkcji, uruchom kontrolowane szyfrowanie plików (np. prosty skrypt, który zmienia rozszerzenia i treść), a następnie wykonaj inkrementalny backup. Sprawdź: czy system wykrywa nietypową entropię/masowe zmiany, czy polityki retencji nie nadpisują „zdrowych” wersji, i czy alerty docierają zanim stare wersje znikną.
Symulacja utraty danych
Usuń testowo część danych w środowisku odtwarzania i zweryfikuj przywrócenie do konkretnego punktu z zachowaniem uprawnień, atrybutów i ACL. Mierz czas od zlecenia do gotowości systemu. Wynik porównaj do RTO i RPO – jeśli je przekraczasz, odporność jest tylko teoretyczna.
Próba zaszyfrowania repozytorium backupów
Spróbuj celowo z poziomu konta „zwykłego” operatora usunąć lub nadpisać bloki w repozytorium. Jeżeli się udało, immutability nie działa. Dodatkowo wyłącz na próbę sieć produkcyjną i zobacz, czy backupy wciąż napływają kanałem kontrolowanym (proxy, dedykowane łącze). Brak kanału lub brak bufora oznacza ryzyko „ciszy w backupach” podczas incydentu.
Sprawdzanie izolacji: sieć, uprawnienia, konta usługowe
Odporność zaczyna się od ograniczenia wektora ruchu. Zrób mapę przepływów: produkcja → proxy/agent → repozytorium. Reguły zapory mają być jednokierunkowe. Zablokuj RDP/SSH do repozytorium spoza strefy administracyjnej backupu. Włącz MFA i PAM dla kont uprzywilejowanych.
Segregacja kont: osobne konta usługowe do backupu i do odtwarzania, bez prawa logowania interaktywnego, z minimalnymi uprawnieniami. Dostęp operatorów przez jump-host z pełnym nagrywaniem sesji. Żądaj biletu w systemie zmian dla każdej operacji kasowania lub skrócenia retencji.
Weryfikacja immutability/WORM
Nie opieraj się na deklaracji dostawcy. Przeprowadź testy:
- Ustaw okres retencji testowej (np. 7–14 dni) i spróbuj skrócić go kontem admina – operacja powinna się nie udać lub wymagać ścieżki awaryjnej z zatwierdzeniem poza systemem.
- Spróbuj usunąć obiekt przed końcem retencji – operacja powinna być blokowana, a w logach musi pozostać audyt.
- Zweryfikuj, że metadane i katalogi są objęte WORM, nie tylko dane – brak tego często pozwala „oszukać” odtwarzanie.
Jeśli używasz snapshotów: sprawdź, czy nie da się ich zdemontować ani skompromitować z poziomu tej samej domeny uprawnień, co produkcję. Dla chmury – włącz blokady usuwania wersji i polityki retencji egzekwowane przez usługę, nie przez skrypty.
Analiza logów i wykrywanie anomalii
Ustal baseline: ile danych dziennie przybywa, jaka jest typowa liczba plików, entropia, tempo błędów. Zbieraj metryki do SIEM/observability i ustaw progi anomalii: skok entropii, masowe zmiany rozszerzeń, gwałtowny wzrost „file rename”, nagłe braki inkrementów.
Praktyczne alerty: „brak backupu z hosta X dłużej niż 24h”, „zauważono 10× większy wolumen zmienionych bloków”, „próba skrócenia retencji/zmiany polityki”. Alert bez procedury to spam – każdemu alertowi przypisz akcję i właściciela.
Testy przywracania po ataku: procedura i miary
Przetestuj pełny scenariusz: identyfikacja „czystego” punktu, odtworzenie systemu na izolowanej infrastrukturze, walidacja aplikacyjna i podpis właściciela procesu. Mierz RTO (czas przywrócenia usługi) i RPO (maksymalna utrata danych). Zapisuj wyniki do rejestru testów.
Sprawdź integralność wersji: porównanie hashy, spójność baz (CHECKDB, consistency check), odtworzenie dzienników transakcyjnych do wybranego punktu. Jeżeli musisz odtwarzać wiele razy, spisz „kroki skracające” – to wskazuje, gdzie automatyzować.
Audit uprawnień i kluczy szyfrowania
Przejrzyj, kto ma prawo: zmiany retencji, usuwania, wyłączania WORM, podglądu kluczy, eksportu konfiguracji. Rotuj tajemnice: klucze KMS/HSM, hasła kont usługowych, tokeny API. Zasada najmniejszych uprawnień i separacja obowiązków: jedna osoba nie powinna móc jednocześnie skrócić retencji i zatwierdzić wyjątku.
Test odzyskania kluczy: czy potrafisz przywrócić kopie bez dostępu do podstawowego KMS? Jeżeli nie – w incydencie możesz utknąć mimo „dobrych” backupów.
Narzędzia i automatyzacja testów odporności
Nie ma jednego złotego narzędzia. Skuteczny zestaw to: planator zadań testowych (CI/CD lub narzędzie orkiestracji), skrypty odtwarzania infrastruktury jako kodu, narzędzia porównywania hashy, skanery anomalii, SIEM oraz moduły immutability w warstwie storage. Automatyzuj co się da: cykliczne testy przywracania na małych próbkach, raporty RTO/RPO, testy prób usunięcia obiektów WORM.
Lista kontrolna i rekomendacje naprawcze
- Izolacja: oddzielna strefa sieciowa, jednokierunkowy ruch, brak interaktywnego logowania.
- Immutability: WORM na danych i metadanych, test realnego braku możliwości skrócenia retencji.
- Wersjonowanie: GFS i jasne RPO per system.
- Szyfrowanie: osobny KMS/HSM, rotacja i audyt dostępu.
- Monitoring: baseline, progi anomalii, akcje do alertów.
- Testy odtwarzania: regularne, mierzone, z podpisem właściciela procesu.
- Uprawnienia: zasada najmniejszych uprawnień, rozdzielenie ról, MFA, PAM.
- Dokumentacja: rejestr testów, playbook incydentowy, ścieżki wyjątków.
Gdy którykolwiek punkt nie przechodzi testu, wprowadź szybkie poprawki: zablokuj kanały administracyjne do repozytorium, włącz WORM choćby na krótkiej retencji, dodaj progi anomalii, i zaplanuj priorytetowo automatyczny test przywracania co najmniej raz w tygodniu dla reprezentatywnego systemu.
FAQ: krótkie odpowiedzi na częste pytania
Jak często testować przywracanie?
Minimum raz w miesiącu dla krytycznych systemów, a małe próbki nawet codziennie w trybie automatycznym.
Czy chmura rozwiązuje problem?
Nie. Bez włączonego WORM/locków wersji, odseparowanych kont i polityk, backup w chmurze może zostać skasowany tak samo jak on‑prem.
Co mierzyć na co dzień?
RTO, RPO, odsetek udanych zadań, czas od wykrycia anomalii do reakcji, liczbę prób modyfikacji retencji zablokowanych przez WORM.
