Ciągłość i przywracanie: Przywracanie, które nikt nie testował

Każdy pulpit kopii zapasowych pokazuje zielone ptaszki. Zadania wykonane, zasada przechowywania spełniona, magazyn wykorzystany zgodnie z oczekiwaniami. Nic z tego nie mówi, czy możesz przywrócić kontroler domeny z bare metal w poniżej czterech godzin podczas rzeczywistego incydentu. Przepaść między "kopia zapasowa powiodła się" a "przywracanie powiodło się" to miejsce, gdzie większość planów ciągłości dyskretnie zawodzi.

Dlaczego ptak kłamie

Oprogramowanie kopii zapasowych raportuje sukces, gdy kończy zapisywanie bajtów do miejsca docelowego. Nie wie, czy te bajty są użyteczne. Kopia zapasowa SQL Server może zostać wykonana czysto i pozostać nieprzysstosowalna, ponieważ łańcuch dziennika transakcji przerwał się trzy dni wcześniej i nikt tego nie zauważył. Migawki VM mogą wyglądać dobrze w konsoli, natomiast leżący u ich podstaw VSS writer po cichu się nie powiódł wewnątrz gościnnego systemu operacyjnego, tworząc obraz spójny na podstawie awarii (a nie spójny z aplikacją).

Operatorzy ransomware wiedzą o tym. Grupy korzystające z playbooków w stylu Conti w poprzednich incydentach celowo atakowały infrastrukturę kopii zapasowych — usuwały kopie w tle za pomocą vssadmin delete shadows /all /quiet, wyłączały repozytoria Veeam, szyfrowały cele kopii zapasowych oparte na NAS, które były dostępne przez SMB. Jeśli twoje kopie zapasowe znajdują się w tym samym segmencie sieci co produkcja z poświadczeniami domenowymi, które mogą ich dotykać, są celem, a nie siecią bezpieczeństwa.

Zbuduj książkę runbooków przywracania, nie politykę kopii zapasowych

Plan ciągłości wymaga instrukcji przywracania krok po kroku napisanych dla osoby, która normalnie tego nie robi. Zapisz:

• Dokładną kolejność odzyskiwania (kontrolery domeny i DNS najpierw, potem aplikacje podstawowe, potem wszystko inne)
• Gdzie znajdują się poświadczenia do konsoli kopii zapasowych, jeśli twój magazyn haseł jest również wyłączony
• Konkretne polecenie przywracania lub ścieżkę konsoli, nie "użyj Veeam do przywrócenia maszyny wirtualnej"
• Oczekiwany czas trwania na system, na podstawie rzeczywistych testów, a nie numerów marketingowych dostawcy

W przypadku Veeam Backup & Replication oznacza to dokumentowanie rzeczywistych kroków: otwórz konsolę, przejdź do Backups > Disk, kliknij prawym przyciskiem myszy punkt przywracania, wybierz Instant VM Recovery lub Full VM Restore w zależności od scenariusza i wybierz hosta docelowy z wystarczającą wolną pojemnością. Jeśli twój główny host jest również narażony, potrzebujesz drugiego, izolowanego hosta już zidentyfikowanego i licencjonowanego.

Testuj przywracania według harmonogramu, nie z kaprysu

Wybierz rotację. Co miesiąc przywróć jeden krytyczny system do izolowanej sieci VLAN i sprawdź, czy się uruchamia, uwierzytelnia i prawidłowo serwuje dane. Co kwartał uruchom pełnozakresowy test: przywróć kontroler domeny, serwer plików i główną bazę danych do izolowanej infrastruktury, a następnie niech ktoś spoza zespołu kopii zapasowych spróbuje się zalogować i ściągnąć raport.

W przypadku baz danych nie tylko przywracaj plik .bak — zweryfikuj go:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

Następnie rzeczywiście przywróć go do instancji testowej i uruchom DBCC CHECKDB wobec niego. Kopia zapasowa, która przejdzie VERIFYONLY, może nadal zawierać logiczne uszkodzenie, które pojawia się tylko podczas jej zapytywania.

W przypadku systemów Linux używających czegoś takiego jak Bacula lub restic, przetestuj rzeczywistą ścieżkę przywracania:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Następnie porównaj przywrócone pliki konfiguracyjne z produkcją, aby potwierdzić, że nic dyskretnie nie zniknęło.

Kopie niezmienne i zasada 3-2-1-1

Klasyczna zasada 3-2-1 (trzy kopie, dwa typy nośników, jedno poza lokalizacją) wymaga aktualizacji na era ransomware: 3-2-1-1, gdzie dodatkowa "1" to kopia niezmienne lub odseparowana. Object lock na magazynie zgodnym z S3 (Wasabi, Backblaze B2 lub AWS S3 z włączonym Object Lock) zapobiega usuwaniu lub modyfikacji przez określone okno przechowywania, nawet przez konto z poświadczeniami administratora. Skonfiguruj go za pomocą:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Tryb COMPLIANCE oznacza, że nikt, nawet konto główne, nie może skrócić przechowywania ani wcześnie usunąć objektów. To ma znaczenie, gdy atakujący ma uprawnięcia administratora domeny.

Mierz RTO i RPO za pomocą rzeczywistych numerów, nie domysłów

Cel czasu odzyskiwania i cel punktu odzyskiwania brzmią jak ćwiczenia biurowe, aż do momentu, gdy dyrektor zapyta "ile danych tracimy i jak długo nie działamy." Zmierz czasy twojej ostatniej trójki testów przywracania. Jeśli twój cel RPO to jedna godzina, ale zadanie kopii zapasowej uruchamia się co sześć godzin, masz udokumentowaną lukę, i lepiej znaleźć tę lukę w ćwiczeniu scenariuszowym niż podczas rzeczywistego zdarzenia szyfrowania o 2 rano w sobotę.

Uruchom test, zapisz rzeczywisty czas zegarowy i porównaj go z tym, co obiecałeś w dokumencie odzyskiwania po awarii. Różnica między tymi dwoma numerami to rzeczywisty stan twojego planu ciągłości.

Aby uzyskać więcej informacji na temat wzmacniania chronionych systemów i tworzenia przepływów pracy reagowania na incydenty, sprawdź powiązane segmenty Blue Team i Digital Forensics na Korra Studio.