Kopie zapasowe¶

Obecnie najczęściej w wyniku incydentów związanych z nieautoryzowanym dostępem (np. w wyniku ataku Ransomware) atakujący dążą do zniszczenia kopii zapasowych. Ma to na celu zwiększenie presji na zaatakowaną instytucję w celu wymuszenia zapłaty okupu. Zaszyfrowanie danych atakowanej instytucji z jednoczesnym pozostawieniem możliwości odzyskania tych danych jest z perspektywy atakującego niepożądane. Dla atakowanej instytucji taka sytuacja byłaby kłopotliwa, ale po pewnym przestoju powróciłaby do normalnego działania. Jeżeli jednak nie będzie dostępu do danych zapasowych, powrót do normalnego funkcjonowania jest niemożliwy, co podnosi prawdopodobieństwo uiszczenia okupu. Skoncentrowani na szantażu atakujący doskonale o tym wiedzą, dlatego niszczenie kopii zapasowych jest jednym z ich priorytetów.

Często instytucje wprowadzające procedury i systemy do tworzenia i przechowywania danych zapasowych koncentrują się na klasycznej architekturze. Mechanizmy zarządzające kopiami zapasowymi danych projektowane są z uwzględnieniem ryzyka utraty danych i odtwarzania w wyniku awarii. Projektowane w taki sposób metodyki nie oferują ochrony danych przed inteligentnym atakującym zdeterminowanym do zniszczenia kopii. Ryzyko wystąpienia incydentu bezpieczeństwa w postaci ataku Ransomware jest na tyle wysokie, że warto zastanowić się nad weryfikacją i ewentualnym rozwinięciem mechanizmów zarządzania kopiami zapasowymi.

Zasada 3-2-1¶

Podstawową praktyką jest zarządzanie kopiami bezpieczeństwa zgodnie z zasadą 3-2-1. Zasada ta wprowadza zarówno redundancję posiadanych kopii jak i systemów przechowywania oraz lokalizacji docelowych. W skrócie zasadę można przedstawić jako zestaw trzech punktów:

• Posiadanie wielu (minimum 3) kopii danych
• Stosowanie wielu (minimum 2) systemów do przechowywania kopii bezpieczeństwa
• Przechowywanie jednej kopii bezpieczeństwa w innej lokalizacji

Błędy w implementacji zasady 3-2-1¶

Prawidłowe zastosowanie podstawowej zasady 3-2-1 mogłoby w wielu przypadkach utrudnić lub uniemożliwić wykonanie zadań atakujących. Jednak bardzo często ta zasada nie jest poprawnie implementowana.

Instytucje i organizacje często stosują dedykowane rozwiązania do agregowania i przechowywania kopii zapasowych swoich danych. Specjalistyczne systemy oferują wiele możliwości konfiguracyjnych, które umożliwiają klientowi wprowadzenie dobrych praktyk zarządzania kopiami zapasowymi danych. Systemy te jednak często skonfigurowane są jedynie w podstawowy sposób jako mechanizm do kopiowania danych z jednego miejsca do drugiego. Pomimo możliwości jakie oferują takie rozwiązania, dane są przechowywane jako pojedyncza kopia zapisana na pojedynczym serwerze.

Często w organizacjach sam serwer kopii zapasowych jest częścią infrastruktury Active Directory. Po kompromitacji domeny w wyniku ataku dane zapasowe są ostatnim elementem jaki może pomóc zaatakowanej instytucji w odtworzeniu prawidłowego funkcjonowania. Atakujący kompromitując domenę przejmuje także pełną kontrolę nad środowiskiem kopii zapasowych.

Podobny przykład może obejmować wdrożenie serwera do zarządzania kopiami bezpieczeństwa w postaci maszyny wirtualnej. Sam pomysł wirtualizacji w tym przypadku nie stanowi problemu. Największym błędem jest jednak brak odpowiedniej separacji. Przykład błędnej implementacji może obejmować instalację maszyny wirtualnej do zarządzania kopiami na wirtualizatorze, który sam jest częścią środowiska Active Directory. W sytuacji ataku i przejęcia kontroli nad domeną atakujący może zniszczyć wszystkie maszyny uruchomione na takim wirtualizatorze.

Poprawne zastosowanie zasady 3-2-1¶

Poprawna architektura i konfiguracja pierwotnej zasady 3-2-1 może obejmować ryzyko wystąpienia incydentu bezpieczeństwa. Podstawowe zasady mogą też zostać rozszerzone o dodatkowe elementy.

1. Trzy kopie danych¶

Ta zasada powinna uwzględniać jednocześnie dostęp do danych, możliwość szybkiego odtworzenia w wyniku awarii czy ataku oraz bezpieczeństwo kopii.

• Pierwsza kopia danych to dane produkcyjne dostępne dla użytkowników i systemów w ramach normalnego działania organizacji
• Druga kopia danych stanowi dane zapasowe. Są to kopie wykonywane automatycznie i przechowywane na domyślnym serwerze kopii zapasowych. Te dane mają być możliwie szybko dostępne w wypadku awarii.
• Trzecia kopia danych nie powinna być łatwo dostępna z poziomu tego samego (domyślnego) serwera kopii zapasowych. Może to być dodatkowy zasób przestrzeni dyskowej, albo kolejny serwer.

2. Wiele technologii¶

Drugi punkt rozwija punkt pierwszy. Zakłada przechowywanie drugiej kopii danych w technologii innej niż główny mechanizm. Ta kopia powinna być przechowywana całkowicie poza domyślną infrastrukturą kopii zapasowych.

• Może to być inny dostawca rozwiązań kopii zapasowych.
• Na tym serwerze może być zastosowany inny mechanizm uwierzytelniania (z uwierzytelnianiem wieloskładnikowym), autoryzacji i inne poświadczenia administratora.
• Innym podejściem może być dodatkowy serwer z innym systemem operacyjnym, który przechowuje dane w innym formacie.

Jako rozwinięcie punktu drugiego można wziąć pod uwagę separację środowiska kopii zapasowych od reszty zasobów w ramach domeny Microsoft Active Directory. Posiadanie serwerów kopii poza środowiskiem domeny może być mniej wygodne dla administratora, ale często warte rozważenia z perspektywy bezpieczeństwa.

3. Dodatkowa kopia poza pozostałymi mechanizmami¶

Zależnie od wymagań, możliwości i zasobów, przechowywanie kopii danych poza pozostałymi systemami można rozwiązać na wiele sposobów. Kilka przykładów może obejmować:

• Zastosowanie kolejnego fizycznego serwera czy sieciowego zasobu dyskowego
• Środowisko chmurowe zapewniane przez zewnętrznego dostawcę
• Nośnik, na który dane są kopiowane.

Zasada 3-2-1-1-1¶

Naturalnym rozszerzeniem podstawowych zasad wprowadzającym dodatkowe mechanizmy ochrony danych w wyniku ataku może być posiadanie kopii danych, której nie da się w prosty sposób usunąć czy zniszczyć.

Warte rozważenia jest wprowadzenie technologii pozwalającej na posiadania kopii danych w wersji "Immutable" zwanej także WORM (Write Once Read Many). Tego typu kopie po pierwotnym utworzeniu nie posiadają możliwości nadpisania czy usunięcia danych. Możliwości tworzenia kopii w takiej formie często oferują w swoich produktach dostawcy rozwiązań kopii zapasowych. Jednak zastosowanie technologii WORM w formie oferowanej przez dostawców wiąże się także z weryfikacją i ewentualną ochroną innych elementów infrastruktury. Dane w technologii WORM zapisane na macierzy dyskowej, którą zniszczy atakujący nie pomoże w ochronie tych danych.

Inną metodą może być oparcie architektury kopii bezpieczeństwa o technologię taśmową LTO (Linear Tape-Open) WORM czy (w mniejszej skali) nośniki optyczne (np. Blu-ray).

Wprowadzenie omówionych powyżej porad rozszerza klasyczną regułę 3-2-1 do 3-2-1-1-1 i może być podsumowane jako:

• Posiadanie wielu (minimum 3) kopii danych
• Posiadanie wielu (minimum 2) technologii przechowywania
• Posiadanie 1 kopii w innej lokalizacji
• Posiadanie 1 kopii w wersji WORM (np. taśmy LTO, immutable cloud storage)
• Posiadanie 1 kopii całkowicie offline

Dodatkowe testowanie¶

Czasem w ramach rozszerzenia zasad zarządzania kopiami bezpieczeństwa stosuje się też zapis 3-2-1-1-0 gdzie ostatnia cyfra "0" oznacza zero błędów. Według tego schematu wykonane kopie powinny być testowane, aby upewnić się, że w razie potrzeby będą niezawodne.

Klasyfikacja danych¶

Zależnie od przeznaczenia różne poziomy kopii zapasowych mogą przechowywać różne dane. Na poziomie pierwszym i drugim mogą być dane najbardziej aktualne, do których wymagany jest szybki dostęp. Mogą to być pliki, dokumenty i aktualne bazy danych na których opiera się ciągłość działania podmiotu. W momencie ich utraty działanie instytucji może zostać wstrzymane, a wszystkie zasoby skupione są na procesie odtwarzania.

Na poziomie trzecim dane przechowywane offline albo w trybie WORM mogą być aktualizowane rzadziej. Takie dane nie wymagają ciągłej aktualizacji, ale w sytuacji konieczności odtworzenia działania infrastruktury w wyniku ataku mogą okazać się krytyczne. Do tej kategorii można zaliczyć kopie zapasowe aplikacji i systemów, klucze i certyfikaty kryptograficzne czy też rzadziej aktualizowane dokumenty (np. dokumenty prawne, bazy danych pracowników itd.)

Golden Image¶

W ramach kopii zapasowych można przechowywać zabezpieczony stan zainstalowanych i skonfigurowanych systemów i aplikacji tzw. Golden Image. Tego typu kopie są wykonywane stosunkowo rzadko. Najczęściej wraz z instalacją nowych systemów, albo cyklicznie w celu odtworzenia możliwie aktualnego stanu danego systemu. Obrazy mogą być przechowywane poza podstawowym mechanizmem zarządzania kopiami bezpieczeństwa. Dane tego typu nie są często używane ale kopia obrazu może być stosunkowo szybko użyta w celu odtworzenia stanu zniszczonego systemu.

W ramach przygotowania na sytuacje awaryjne organizacja może posiadać wiele wersji systemów w postaci Golden Image. Takie kopie mogą reprezentować różne stany poszczególnych systemów. Mogą to być zainstalowane i wstępnie skonfigurowane systemy operacyjne, albo kopie całych serwerów. W takim przypadku obraz Golden Image może składać się z systemu oraz zainstalowanych i skonfigurowanych aplikacji.

Po wystąpieniu awarii czy incydentu przygotowany wcześniej obraz typu Golden Image pozwala pominąć proces instalacji. Taki obraz może zostać odtworzony z nośnika kopii bezpieczeństwa i skopiowany na nowy serwer. Po wstępnej aktualizacji systemu i aplikacji mogą zostać skopiowane na niego odtworzone dane i całość może zostać ponownie wprowadzona do działania produkcyjnego.

W sytuacji zniszczenia przez atakujących całej infrastruktury serwerowej (np. serwery zaszyfrowane po ataku Ransomware) skorzystanie z obrazów Golden Image pozwala znacznie przyspieszyć odtwarzanie środowiska w porównaniu do ręcznej instalacji i konfiguracji każdego systemu. Dodatkową korzyścią jest to, że administrator może uruchomić wymagane usługi w odseparowanym środowisku i zapewnić tym samym ciągłość działania instytucji. Takie podejście sprawia, że odtwarzana infrastruktura może być uruchamiana po kolei i równolegle do zabezpieczania śladów incydentu.

Logi systemowe¶

W środowisku, w którym instytucja nie posiada innych mechanizmów agregowania i analizy logów systemowych może objąć logi mechanizmem kopii zapasowych. Atakujący często czyszczą logi na skompromitowanych maszynach. Posiadanie kopii logów może pomóc w analizie po wystąpieniu incydentu.

Dedykowany serwer kopii zapasowych¶

W ramach rozwinięcia punktu 2 z zasady 3-2-1 można rozważyć wprowadzenie dedykowanego serwera kopii zapasowych skonfigurowanego specjalnie z uwzględnieniem ryzyka ataku mającego na celu zniszczenie kopii zapasowych.

W tej sekcji przedstawiono w kilku punktach koncepcję architektury serwera kopii zapasowych, który mógłby zostać wprowadzony jako dodatek do istniejącej infrastruktury. Tego typu rozwiązanie może być stosunkowo prosto zaprojektowane i wprowadzone w organizacji. Całość może być oparta w pełni o technologie typu open-source.

Przykład zasad implementacji¶

1. Maszyna będąca dodatkowym serwerem kopii bezpieczeństwa posiada inny system operacyjny niż domyślny system kopii zapasowych.

   W sytuacji kiedy oryginalny mechanizm zarządzania kopiami zapasowymi jest oparty o systemy Windows. Dodatkowy serwer może pracować pod kontrolą systemu Linux.

2. Maszyna ta jest dodatkowo zabezpieczona

   Domyślnie nowo instalowane systemy operacyjne posiadają wiele usług, które nie są wymagane w przypadku maszyny dedykowanej do zarządzania kopiami bezpieczeństwa. Taka maszyna powinna być zabezpieczona (tzw. hardening) poprzez wyłączenie wszelkich innych usług poza komunikacją związaną z kopiami oraz dostępem administracyjnym.

3. Dostęp administracyjny do aplikacji

   Dostęp administracyjny do mechanizmu zarządzania kopiami powinien być zapewniony inaczej niż analogiczny dostęp na maszynie domyślnej. System może posiadać dedykowane konta administracyjne. Dostęp administracyjny powinien odbywać się z zastosowaniem MFA poza domeną Active Directory.

4. Dostęp administracyjny do serwera

   Zarządzanie serwerem na którym działa usługa zarządzania kopiami bezpieczeństwa odbywa się z wykorzystaniem reguł dostępu dla maszyny administratora. Administracja odbywa się przy użyciu innych mechanizmów niż stosowane domyślnie (np. dostęp przez SSH z wykorzystaniem klucza kryptograficznego)

5. Serwer może posiadać wiele interfejsów sieciowych do różnych rodzajów komunikacji

   Maszyna może mieć dwa interfejsy sieciowe oraz zestaw reguł dostępowych. Ruch produkcyjny tzw. Data Plane (transfer kopii zapasowych) może odbywać się przy użyciu dedykowanej sieci. Ruch administracyjny tzw. Management Plane może odbywać się drugim interfejsem. Cały ruch produkcyjny odbywa się zgodnie ze zdefiniowanymi regułami i bez możliwości komunikacji poza siecią lokalną. Wszelkie próby nawiązania z tej maszyny połączeń na zewnątrz automatycznie świadczą o kompromitacji i oznaczają próbę eksfiltracji danych.

   flowchart LR
       subgraph Klient
           K[Dane]
       end
   
       subgraph Server
           Int1[int1: DataPlane]
           Int2[int2: ManagementPlane]
           DB[(Zasób)]
       end
   
       subgraph Administrator
           A[SSH]
       end
   
       K --> |Allow| Int1
       Int1 -.-> DB
       Klient -.-> |Unrechable| Int2
       A --> |Allow| Int2

6. Transfer danych w trybie PULL

   Cały transfer danych odbywa się na żądanie serwera i jest przez niego inicjowany. Dane z maszyn źródłowych nie są wysyłane. Serwer łączy się do maszyny źródłowej i pobiera dane z lokalizacji, które wcześniej zostały dla niego udostępnione w trybie do odczytu. Serwer źródłowy zezwala jedynie na połączenia przychodzące od serwera docelowego. W ten sposób nawet po kompromitacji maszyny źródłowej atakujący nie uzyska żadnych przydatnych informacji pozwalających mu zaatakować dodatkowy serwer kopii bezpieczeństwa.

   sequenceDiagram
       participant Win as Maszyna Źródłowa Windows
       participant Linux as Server Kopii Linux
       participant Zasob as Zasób kopii zapasowych
   
       Linux->>Linux: Uruchom mechanizm kopii (cyklicznie)
       Linux->>Win: Połącz / Zamontuj
       Linux->>Win: Skanuj w poszukiwaniu nowych plików
       alt Nowe dane
           Linux->>Win: Pobierz dane
           Win-->>Zasob: Pobieranie
           Linux->>Win: Rozłącz / odmontuj
   
       else Brak nowych danych
           Linux->>Win: Rozłącz / odmontuj
   
       end
   
       Linux-->>Zasob: Zarządzanie danymi (kompresja, rotacja it.)

7. Serwer kopii pracuje w trybie offline

   Z perspektywy komunikacji produkcyjnej dodatkowy serwer nie musi być dostępny w sieci na stałe jak inne serwery usługowe. Serwer taki może cyklicznie w określonych interwałach uruchamiać usługę związaną z pobraniem kopii danych. Po wykonaniu kopii danych może wyłączyć (czy też zablokować) interfejs danych produkcyjnych i przejść do trybu offline. W tym trybie może wykonywać pozostałe zadania związane z kompresją, weryfikacją czy rotowaniem danych. Poza dostępem administratora maszyna nie przyjmuje żadnych nienawiązanych wcześniej połączeń.

Ostatnia aktualizacja artykułu: 2026-09-02.