Niezmienne kopie zapasowe chroniące przed oprogramowaniem ransomware
Jak chronić kopie zapasowe firmy przed oprogramowaniem ransomware za pomocą niezmiennej pamięci masowej obiektów?
Niezmienna pamięć masowa obiektów chroni kopie zapasowe przed oprogramowaniem ransomware, uniemożliwiając ich usunięcie. Gdy w zasobniku ustawiona jest blokada obiektu (Object Lock), warstwa pamięci masowej odrzuca każde żądanie usunięcia lub nadpisania do momentu wygaśnięcia okresu retencji, w tym żądania zawierające ważne dane uwierzytelniające administratora.
Dlaczego kopie zapasowe są pierwszym celem nowoczesnego oprogramowania ransomware
Celowy schemat ataku: zaszyfrować lub usunąć kopie zapasowe, a następnie dane produkcyjne
Operatorzy nowoczesnego oprogramowania ransomware sprofesjonalizowali swój scenariusz działania. Przed uruchomieniem ładunku szyfrującego w środowisku produkcyjnym atakujący spędzają dni na mapowaniu sieci w poszukiwaniu luk w zabezpieczeniach: identyfikują serwer kopii zapasowych, dane uwierzytelniające pracowników i hasła pozostawione w skryptach oraz politykę dostępu chroniącą każde repozytorium. Gdy uzyskają dostęp i znajdą się na pozycji, najpierw wyłączają lub usuwają te kopie, a następnie szyfrują dane produkcyjne.
Ta sekwencja jest celowa. Firma, która może przywrócić dane w ciągu kilku godzin, ma niewielką motywację do zapłaty; firma, której kopie zostały usunięte kilka dni wcześniej, nie ma takiej możliwości, a atakujący właśnie na to liczy. Atak tego rodzaju nie polega tylko na szyfrowaniu danych, lecz na usuwaniu każdej ścieżki przywracania, jaką posiada firma.
Dlatego pojedyncze przejęte dane uwierzytelniające stanowią obecnie największe ryzyko w strategii ochrony. Kontrola dostępu oraz zabezpieczenia tożsamości, bezpieczeństwa i operacji stanowią pierwszą linię obrony, ale hakerzy i próby nieautoryzowanego dostępu na tym nie poprzestają: konto z uprawnieniami do zapisu w zasobniku pamięci masowej może w ciągu kilku minut usunąć każdy obiekt i każdą datę retencji, chyba że warstwa pamięci masowej sama odrzuci takie polecenie.
Zamknij ścieżkę dostępu: MFA, świadomość zagrożeń phishingowych i ćwiczenia przywracania danych
Niezmienność chroni kopię, ale nie chroni drzwi, przez które wszedł atakujący. Prawie każdy incydent zaczyna się od skradzionych danych uwierzytelniających, a phishing pozostaje najczęstszą metodą ataku, zazwyczaj w postaci wiadomości e-mail, która wygląda na rutynową. Wokół samej warstwy pamięci masowej liczą się trzy mechanizmy kontrolne.
Wymagaj uwierzytelniania wieloskładnikowego (MFA) w konsoli pamięci masowej oraz na każdym koncie, które może zmienić politykę retencji. Uwierzytelnianie wieloskładnikowe jest tutaj najcenniejszym mechanizmem kontrolnym, ponieważ MFA przerywa etap ponownego wykorzystania danych uwierzytelniających, od którego zależą tego typu cyberataki, a MFA w konsoli można szybko wdrożyć. Przechowuj dane uwierzytelniające usług w menedżerze haseł, a nie w skryptach, i sprawdzaj, czy rotacja haseł faktycznie ma miejsce. Zapewnij personelowi regularne szkolenia z zakresu podejrzanych wiadomości e-mail i menedżerów haseł, aby pracownik, który otrzyma taką wiadomość, zgłosił ją zamiast otwierać. Personel znający model zagrożeń jest tańszą formą ochrony niż jakikolwiek produkt, a zagrożenia docierające do poinformowanego pracownika zazwyczaj na tym się kończą, a zgłoszenie pracownika jest często najwcześniejszym sygnałem, jaki od niego otrzymujesz. Przeprowadzaj również regularne ćwiczenia przywracania danych: jedynym sposobem na zidentyfikowanie uszkodzonej ścieżki odzyskiwania jest przetestowanie jej, zanim zrobi to incydent. Śledź również próby usunięcia w zasobniku: skok liczby odmów usunięcia jest wiarygodnym wczesnym sygnałem, że poświadczenia zostały przejęte. Śledź również aktualizacje polityk, ponieważ aktualizacje retencji są tym, czego atakujący próbuje w pierwszej kolejności.
Nic z tego nie zastępuje segmentacji sieci ani ochrony punktów końcowych po stronie produkcji i nie stanowi pełnych ram cyberbezpieczeństwa. Jest to warstwa, która chroni przed sytuacją, w której pojedyncze przejęte konto pracownika prowadzi do awarii w całej firmie.
Cyberubezpieczenia i audyty wymagają teraz możliwych do wykazania niezmiennych kopii
Ubezpieczyciele odnawiający polisy cybernetyczne zadają teraz bezpośrednie pytania: czy te kopie są niezmienne, czy są logicznie odizolowane od środowiska produkcyjnego i czy możecie wykazać pomyślny test przywracania? Firmy, które nie potrafią odpowiedzieć na to pytanie, przedstawiając dowody, muszą liczyć się z wyższymi składkami lub odmową zawarcia polisy. Większość firm odkrywa to dopiero przy odnawianiu polisy, a nie wcześniej. Pierwszym krokiem jest ustanowienie i udokumentowanie procesów przywracania kopii zapasowych, a następnie przeprowadzanie regularnych testów przywracania i bieżące monitorowanie, aby upewnić się, że nadal działają one w miarę zmian w środowisku.
Wymogi dotyczące zgodności z przepisami zmierzają w tym samym kierunku, podobnie jak kwestionariusze dotyczące bezpieczeństwa danych klientów. Niezależnie od tego, czy wynika to z kontroli ISO 27001, audytów sektorowych, czy własnej oceny ryzyka klienta, odpowiedź „mamy kopie zapasowe” nie jest już akceptowalna. Każda organizacja stojąca w obliczu współczesnych zagrożeń cybernetycznych musi coraz częściej udowadniać, że kopia zapasowa nie może zostać zmieniona ani usunięta przez określony okres przechowywania, niezależnie od tego, który pracownik lub konto podejmie taką próbę.
Ten dowód ma znaczenie, ponieważ niezmienna kopia zapasowa wymiernie zmniejsza szansę na to, że jeden przejęty poświadczenie zniszczy zarówno środowisko produkcyjne, jak i ścieżkę jego przywracania. Poprzeczka przesunęła się z „kopia zapasowa istnieje” na „jesteśmy w stanie wykazać ścieżkę przywracania, której atakujący nie może łatwo zniszczyć”.
Zasada 3-2-1 i dlaczego to właśnie niezmienna kopia jest tą, która cię ratuje
Trzy kopie, dwa nośniki, jedna poza siedzibą (oraz jedna niezmienna)
Zasada 3-2-1, czyli trzy kopie na dwóch nośnikach, z których jedna znajduje się poza siedzibą firmy, stanowi fundament ochrony danych od dekady i logika ta pozostaje aktualna: jeśli jeden system lub lokalizacja zawiedzie, pozostaje inna ścieżka.
Oprogramowanie ransomware zmienia tę kalkulację. Jeśli atakujący może uzyskać dostęp do każdej kopii za pomocą tych samych poświadczeń lub tej samej ścieżki sieciowej, samo „przechowywanie poza siedzibą” nie chroni Twojej firmy; jedynie przenosi ryzyko w inne miejsce. Dlatego wiele firm i zespołów ds. kopii zapasowych traktuje teraz tę zasadę jako 3-2-1 plus jedna niezmienna kopia: kopia zapasowa, która przetrwa nawet po skompromitowaniu reszty środowiska.
Co „niezmienność” faktycznie oznacza na poziomie pamięci obiektowej
Niezmienność nie jest ustawieniem wewnątrz oprogramowania, lecz gwarancją wymuszaną przez warstwę pamięci masowej. Przy włączonej funkcji Object Lock i ustawionym okresie retencji system odrzuca wszelkie próby usunięcia lub nadpisania danych do momentu wygaśnięcia tego okresu, w tym żądania wykonane z uprawnieniami administratora.
Nie ma znaczenia, czy żądanie używa poprawnego hasła pracownika, skompromitowanego konta, czy samego ładunku ransomware: system z założenia nie pozwoli na taką zmianę. To chroni kopię przed techniką, na której polega to złośliwe oprogramowanie, wykorzystującą skradziony dostęp do modyfikacji lub usunięcia wszystkiego, do czego może dotrzeć.
Trzy sposoby tworzenia kopii zapasowych w pamięci obiektowej OVHcloud
Firmom, które poszukują niezawodnego, suwerennego celu dla swojej strategii retencji opartego na pamięci obiektowej (zgodnej z S3)*, OVHcloud oferuje zespołom ds. kopii zapasowych trzy praktyczne ścieżki, w zależności od tego, czy preferują opcję zarządzaną, samodzielną konfigurację czy integrację z istniejącą platformą.
Zarządzanie Natywne dla OVHcloud usługi Instance, Volume i Databases Backup
W przypadku obciążeń w chmurze publicznej (Public Cloud), natywne usługi OVHcloud – Instance Backup, Volume Backup oraz Databases Backup – zapisują dane bezpośrednio w pamięci obiektowej, bez konieczności budowania czy utrzymywania potoku S3. Ta ścieżka jest odpowiednia dla zespołów, które oczekują ochrony przy minimalnym nakładzie operacyjnym. Jeśli Twoje obciążenia działają w środowisku Kubernetes, ta sama ochrona rozciąga się na wolumeny trwałe za pośrednictwem Managed Kubernetes Service. Płaszczyzna sterowania, w tym etcd, jest zarządzana przez OVHcloud, więc nie jest to element, którego Twój zespół musi tworzyć kopię zapasową.
Zbuduj to samodzielnie za pomocą interfejsu S3 API (awscli, Rclone, Plakar, Restic, Duplicati)
Zespoły z doświadczeniem w S3 mogą podłączyć własny potok do zasobnika (bucket) za pomocą standardowych narzędzi: awscli lub AWS SDK do zadań skryptowych, Rclone do przepływów synchronizacji lub narzędzi open-source, takich jak Plakar, Restic, Duplicati i wielu innych, do tworzenia deduplikowanych i szyfrowanych kopii. Plakar to suwerenna opcja open-source, która nie jest uzależniona od narzędzi żadnego konkretnego dostawcy. Ponieważ API S3 jest wspólnym mianownikiem, testujesz lokalnie, a do środowiska produkcyjnego przechodzisz jedynie po zmianie punktu końcowego (endpoint).
Użyj własnego narzędzia: Veeam, HYCU, Cohesity, Veritas NetBackup, CloudCasa i wiele innych narzędzi.
Większość środowisk korporacyjnych korzysta już z platformy ochrony. OVHcloud Object Storage posiada certyfikat Veeam Ready, a rozwiązania HYCU, Cohesity i Veritas NetBackup są również kompatybilne. W przypadku Kubernetes, zarówno Velero, jak i CloudCasa obsługują Object Storage jako cel za pośrednictwem interfejsu S3 API. Niezmienność jest konfigurowana w narzędziu dla danego zasobnika, więc ochrona pozostaje zachowana nawet w przypadku naruszenia bezpieczeństwa aplikacji: warstwa pamięci masowej wymusza retencję niezależnie.
Czterowarstwowa ochrona, która ma zastosowanie do wszystkich trzech ścieżek
Bez względu na to, którą ścieżkę wybierzesz, model bezpieczeństwa pozostaje taki sam: spraw, aby kopii nie dało się usunąć, zachowaj czystą historię, odizoluj ją w drugiej lokalizacji oraz chroń wrażliwe dane i ich poufność. Te środki bezpieczeństwa współpracują ze sobą, aby zapobiec zniszczeniu całego punktu odzyskiwania przez jedno przejęte konto pracownika.
Object Lock (WORM): niemożliwy do usunięcia przez okres przechowywania
Object Lock zmienia przechowywany obiekt w coś, czego nie można usunąć ani nadpisać do momentu wygaśnięcia okresu przechowywania, nawet przez konto z dostępem administratora. Po włączeniu, funkcja Object Lock jest z założenia nieodwracalna dla danego zasobnika (bucket), co sprawia, że chroni ona również przed działaniami osób z wewnątrz organizacji. Legal Hold dodaje bezterminową blokadę na określone obiekty, co jest przydatne, gdy zestaw plików musi zostać zachowany poza standardowym okresem. Ta kontrola sprawia, że niezmienność staje się rzeczywista, a nie teoretyczna, a Twój plan reagowania na incydenty powinien dokumentować ją z podziałem na zasobniki i okresy przechowywania.
Wersjonowanie: zachowaj czystą historię każdego obiektu
Wersjonowanie zachowuje każdą poprzednią wersję pliku zamiast zastępować ją w tym samym miejscu, dzięki czemu uszkodzony plik nigdy nie nadpisuje własnej historii. Jeśli plik zostanie nadpisany lub zmieniony przed wejściem blokady w życie, wcześniejsza czysta wersja tego pliku pozostaje dostępna, plik po pliku, co w ogóle umożliwia przywracanie na poziomie plików. Wersjonowanie jest wymagane do poprawnego działania Object Lock, dlatego włącz obie te funkcje podczas tworzenia zasobnika. Chroni to również przed błędami ludzkimi i przypadkowym usunięciem przez pracowników w samym potoku kopii zapasowych, a nie tylko przed oprogramowaniem ransomware.
Asynchroniczna replikacja S3: izolowana kopia w drugim regionie
Asynchroniczna replikacja S3 przechowuje automatyczną kopię bucketu w oddzielnym regionie OVHcloud, niezależną od głównych poświadczeń, chyba że dostęp zostanie wyraźnie przyznany. Zapewnia to izolowaną kopię zewnętrzną, której wymaga strategia 3-2-1, bez konieczności ręcznego przesyłania. W połączeniu z funkcją Object Lock, atakujący musiałby posiadać poświadczenia w dwóch regionach, aby dotrzeć do każdej kopii.
Szyfrowanie danych w spoczynku: SSE-C oraz klucze zarządzane przez OVHcloud (SSE-OVHcloud Managed Keys)
Szyfrowanie w spoczynku chroni poufność wrażliwych plików, jeśli warstwa pamięci masowej zostanie kiedykolwiek osiągnięta przez osobę z zewnątrz, a szyfrowanie w tranzycie zabezpiecza je w drodze z Twoich aplikacji i baz danych, niezależnie od tego, czy potok działa lokalnie, czy z odległego regionu. OVHcloud Object Storage obsługuje SSE-C, gdzie zarządzasz kluczem szyfrującym, oraz SSE-OVHcloud Managed Keys, gdzie OVHcloud zarządza cyklem życia klucza, zapewniając bezpieczną opcję w obu przypadkach i eliminując powszechną lukę w zabezpieczeniach w potokach typu „zrób to sam”. Integracja z usługą zarządzania kluczami (Key Management Service) w celu niezależnej kontroli materiału klucza znajduje się w planach rozwoju Object Storage, więc na razie należy polegać na SSE-C. Ta warstwa odnosi się do poufności, a nie niezmienności, ale nadal ma znaczenie, ponieważ naruszenia danych ocenia się na podstawie tego, co było możliwe do odczytania: zaszyfrowane obiekty są znacznie mniej przydatne dla atakującego niż te możliwe do odczytania.
W przypadku środowisk regulowanych powyżej 5 TiB lub gdy chcesz poznać drugą opinię na temat projektu retencji i replikacji, architekt rozwiązań może przejrzeć Twoją architekturę, udostępnić projekt referencyjny i pomóc zabezpieczyć politykę retencji, o którą zapyta audytor, oraz potwierdzić, że jest ona zgodna z Twoim celem przywracania danych.
Odzyskiwanie bez drugiego uderzenia
11 dziewiątek trwałości oraz SLA dostępności 99,99% w 3-AZ
Kopia zapasowa, której nie można szybko przywrócić, nie jest zbyt użyteczna. Cała infrastruktura OVHcloud Object Storage została zaprojektowana z myślą o trwałości na poziomie jedenastu dziewiątek (99,999999999%), a nie tylko w regionach 3-AZ, więc utrata danych z powodu awarii sprzętu jest niezwykle mało prawdopodobna, niezależnie od tego, gdzie znajduje się kopia. SLA dostępności na poziomie 99,99% dotyczy trybu wdrożenia 3-AZ. Administratorzy potrzebują, aby cel przywracania był dostępny w momencie wystąpienia incydentu bezpieczeństwa, a nie tylko dowodu na to, że dane były wcześniej bezpieczne. Jest to również wymiar najwyżej oceniany przez klientów: Stabilność na poziomie 4,51/5 i dostępność na poziomie 4,50/5 w wynikach NPS.
Brak opłat za transfer danych wychodzących przy przywracaniu między usługami OVHcloud
Przywracanie dużej ilości danych po incydencie nie powinno generować nieprzewidzianych kosztów w przypadku już i tak kosztownego zdarzenia. Między usługami OVHcloud nie ma opłat za transfer danych wychodzących (egress fees), więc przywracanie danych do instancji Public Cloud, serwera Bare Metal lub jakiegokolwiek innego zasobu OVHcloud nie wiąże się z oddzielną opłatą za transfer, a koszt przywracania pozostaje przewidywalny. Dzięki temu łatwiej zaplanować budżet na odzyskiwanie danych, gdy czas ma największe znaczenie.
Stosuj warstwową retencję, aby kontrolować koszty: Standard → Active Archive → Cold Archive
Nie każda kopia wymaga tej samej klasy pamięci masowej przez ten sam czas. Polityki cyklu życia przenoszą obiekty ze Standard do Active Archive w celu średnioterminowego przechowywania, a następnie do Cold Archive w celu przechowywania zgodnego z przepisami, podczas gdy Object Lock pozostaje w mocy dla każdej klasy.
Active Archive kosztuje około 4,5 € za TiB, a Cold
Archive około 1,7 € za TiB – obie opcje są znacznie tańsze niż Standard w przypadku danych, które rzadko przywracasz. Takie warstwowanie pozwala firmie zachować wieloletnią, niezmienną politykę retencji dla celów zgodności, spełniając większość wymagań branżowych, bez konieczności płacenia przez cały czas stawek za pamięć premium. Regularnie przeglądaj i aktualizuj politykę cyklu życia w miarę zmiany wymagań dotyczących retencji lub wolumenów danych.
Suwerenność i zgodność: RODO, HDS, ISO 27701, brak narażenia na CLOUD Act
Dane kopii zapasowych często zawierają jedne z najcenniejszych i najbardziej wrażliwych informacji firmy: zrzuty baz danych, stan aplikacji, własność intelektualną, pełne migawki systemów, a czasem dane osobowe objęte RODO. Miejsce przechowywania tych danych oraz właściwa jurysdykcja prawna mają znaczenie dla suwerenności cyfrowej, ochrony danych oraz wymagań specyficznych dla sektora, takich jak HDS czy ISO 27701, w tym dla operatorów infrastruktury krytycznej i branż regulowanych.
OVHcloud Object Storage jest hostowany i obsługiwany w europejskich centrach danych, bez narażenia na ustawę CLOUD Act, ponieważ OVHcloud nie jest firmą podlegającą wymogom ujawniania informacji wynikającym z tego prawa. Obecne certyfikaty obejmują ISO 27001, 27017, 27018 oraz 27701 w zakresie zarządzania prywatnością, a kwalifikacja SecNumCloud dla Object Storage jest w planach. To sprawia, że pamięć masowa staje się częścią szerszego zarządzania ryzykiem, strategii zgodności i operacji biznesowych organizacji, a nie tylko narzędziem operacyjnym.
Rozpocznij: okres próbny za 200 €, centrum kopii zapasowych oraz architekt rozwiązań
Utwórz projekt Public Cloud , włącz Object Lock i wersjonowanie w nowym buckecie, a następnie skieruj swoje istniejące narzędzie na punkt końcowy i uruchom jedno rzeczywiste zadanie. Kredyt próbny w wysokości 200 € pokrywa ten test oraz przywracanie danych, które potwierdza jego działanie. W przypadku danych regulowanych lub projektów replikacji wieloregionalnej skontaktuj się z architektem rozwiązań. Strona Object Storage oraz centrum Identity, Security & Operations obejmują pozostałe kwestie.
* S3 jest znakiem towarowym zastrzeżonym przez Amazon Technologies, Inc. Usługi OVHcloud nie są sponsorowane, zatwierdzone ani powiązane z Amazon Technologies, Inc.