Skuteczny backup i zasada 3-2-1 w praktyce, czyli na co uważać przy jej implementacji
Zasada 3-2-1 to bardzo podstawowa reguła, którą należy stosować przy wdrażaniu rozwiązań do backupu. W uproszczeniu sprowadza się do następujących elementów:
- powinieneś zawsze posiadać trzy instancje swoich danych (dane oryginalne oraz dwie kopie zapasowe),
- powinieneś zawsze przechowywać swoje kopie zapasowe na dwóch typach nośnika (np. takie jak dyski twarde, chmura, taśmy),
- co najmniej jedna kopia zapasowa powinna być przechowywana poza miejscem gdzie znajdują się zarówno dane źródłowe i ich kopie.
Zainfekowany system kopii zapasowych w przedsiębiorstwie z branży opakowań spożywczych
U jednego z naszych klientów, przedsiębiorstwa z branży produkcji opakowań spożywczych, system do backupu został wdrożony w formie centralnie zarządzanej platformy backupowej o następującej specyfice:
- centralny serwer zarządzający agentami backupu, wdrożony lokalnie, w formie maszyny wirtualnej,
- agenci kopii zapasowych zainstalowani wewnątrz maszyn fizycznych, kopia maszyn wirtualnych realizowana bezagentowo (przez API środowiska wirtualizacji),
- pliki kopii zapasowych przechowywane na lokalnej macierzy, replikowane na drugą macierz w zapasowym centrum danych oraz wybrane rewizje krytycznych kopii zapasowych replikowane do chmury,
- replikowane kopie zapasowe są zaszyfrowane (szyfrowanie symetryczne), klucz szyfrujący zarządzany przez centralny serwer kopii zapasowych,
- klient posiadał scentralizowany system zarządzania hasłami (sieciowy manager haseł w postaci tzw. virtual appliance),
- środowisko wirtualizacji- Vmware vSphere/ESXi.
Zainfekowany system backupów po stronie klienta
Infrastruktura wspomnianej organizacji późną jesienią tego roku została dotknięta incydentem wywołanym przez ransomware qilin, który zaatakował bezpośrednio serwery wirtualizacji z zainstalowanym oprogramowaniem VMware ESXi. Infekcja ta dotyka systemu operacyjnego wirtualizatora, a więc działa w pewnej warstwie abstrakcji od samych systemów maszyn wirtualnych, jak i systemu backupowego. Zagrożenie to uszkadza całe środowisko wirtualne, wyłączając maszyny działające na hypervisorach, usuwając ich migawki i szyfrując pliki tzw. dysków wirtualnych.
Uruchomienie maszyn nie jest możliwe, co jest o tyle problematyczne, że w tym wypadku jedną z nich był serwer zarządzający- umożliwiający zarządzanie kluczem szyfrującym dla zreplikowanych kopii zapasowych.
Ponadto, fraza zabezpieczająca klucz szyfrujący (wymagana do wprowadzenia np. w procesie odzyskiwania danych z zabezpieczonych kopii zapasowych) była przechowywana w menedżerze haseł, który jak już wspomniano, był systemem w postaci maszyny wirtualnej.
Odzyskanie środowiska było możliwe tylko z lokalnej macierzy, którą ze względów bezpieczeństwa organizacja odłączyła od sieci, ponieważ wektor ataku nie był znany i istniało ryzyko, że ostatnie kopie zapasowe mogą zostać również zaszyfrowane. W konsekwencji, atak ten wywołał:
- całkowitą przerwę w funkcjonowaniu środowiska produkcyjnego na okres dłuższy, niż zakładanych w scenariuszach określonych w planach BCP organizacji
- utratę starszych rewizji kopii zapasowych (brak możliwości odtwarzania z nich danych) – było to o tyle problematyczne, że na lokalnej macierzy były przechowywane tylko najświeższe kopie danych. Repliki kopii zapasowych dotyczyły się bardzo starych danych, traktowanych przez organizację jako swojego rodzaju archiwa- dość krytyczne, ponieważ przechowywane na nich dane były objęte politykami wymuszonymi przez regulacje prawne
- koszty związane z usługami z zakresu odpowiedzi na incydenty i informatyki śledczej- znacznie wyższe niż przewidywane przez wzgląd na presję czasową wywołaną potrzebą jak najszybszego odtworzenia środowiska na wypadek awarii
Powyższe studium przypadku ukazuje, że podczas wdrażania i stosowania zestawów dobrych praktyk istotne jest również rozważanie różnego rodzaju scenariuszy. Modelowanie zagrożeń i potencjalnego przebiegu incydentów pozwala na zbudowanie rozwiązań bezpieczeństwa lepiej dopasowanych do specyfiki danego środowiska biznesowego. W przypadku zasady 3-2-1 zestawy danych i kopii zapasowych są traktowane jako pojęcie ogólne. Same natomiast zestawy danych wstępują w różnej postaci – niektóre z nich, głównie przez wzgląd na ich krytyczność, należy potraktować innym mechanizmem kopii zapasowej, nawet w sposób nadmiarowy.
Co w takim wypadku można było zrobić inaczej
- przeprowadzić analizę zbiorów posiadanych danych, a dokonując klasyfikacji, nie tylko skatalogować ich krytyczność, ale również formę. Kopia zapasowa maszyn wirtualny często nie będzie wystarczająca – dla pewnych systemów indywidualnie należy realizować kopie na poziomie plików, silników bazodanowych czy nawet pojedynczych obiektów,
- dywersyfikować wykorzystywane technologie – w myśl zasady ,,defense-in-depth”- warto mieć więcej niż jedno rozwiązanie do backupu, od więcej niż jednego producenta, w innym modelu architektury (np. jeden system jako centralny serwer zarządzania kopią + agenci, a drugi jako zintegrowane rozwiązanie do backupu typu ,,appliance”),
- regularnie przeprowadzać analizy biznesowe w ramach procesów wdrażania/realizowania BCP; które uwzględniają różne scenariusze testowe, czerpiąc przy ich tworzeniu ze znanych incydentów i wiedzy na temat nowych wektorów cyberataków.
Nasze rozwiązanie
W obliczu zastanego problemu zrealizowaliśmy dla klienta audyt bezpieczeństwa, na podstawie którego później przekazaliśmy analizę zdarzenia i zalecenia, co należałby poprawić. Wdrożyliśmy również nowe rozwiązanie do back-upów – Acronis w modelu MSP, w którym serwer zarządzjący jest zupełnie odizolowany od infrastruktury klienta, a cloud storage zlokalizowany jest w polskim Data Center.
Artykuły referencyjne do tej podatności:
https://kapitanhack.pl/2023/12/05/nieskategoryzowane/ransomware-qilin-atakuje-serwery-vmware-esxi/
https://www.bleepingcomputer.com/news/security/linux-version-of-qilin-ransomware-focuses-on-vmware-esxi/
