Nowa fala ransomware atakująca kopie zapasowe w chmurze: świeże techniki i skuteczne zabezpieczenia

Nowa fala ransomware a kopie zapasowe w chmurze – dlaczego sytuacja się zmieniła

Rola backupu jako ostatniej linii obrony a nowa rzeczywistość

Przez lata strategia obrony przed ransomware opierała się na jednym prostym założeniu: „miej dobre kopie zapasowe, a poradzisz sobie z szyfrowaniem danych”. Klasyczny scenariusz wyglądał tak: malware szyfrowało pliki lub całe dyski, użytkownicy tracili dostęp do systemów produkcyjnych, a administratorzy odtwarzali dane z backupu sprzed ataku. Czas przestoju był bolesny, ale organizacja odzyskiwała kontrolę bez płacenia okupu.

Ten model załamał się w momencie, gdy przestępcy zrozumieli, że realnym przeciwnikiem nie jest antywirus, ale zdolność odtworzeniowa organizacji. Jeśli kopie zapasowe są kompletne, aktualne i bezpieczne, to szantaż traci sens. Jeśli jednak atakujący wyeliminuje lub skompromituje backup, wartość okupu rośnie dramatycznie. Dlatego nowa fala ransomware nie traktuje kopii zapasowych jako „skutku ubocznego” ataku, ale jako pierwszoplanowy cel operacji.

Zmienił się też poziom profesjonalizacji gangów ransomware. Dzisiejsze grupy funkcjonują jak firmy IT: korzystają z modeli RaaS (Ransomware as a Service), mają specjalistów od penetracji, adminów, „obsługę klienta”, a nawet SLA dotyczące kluczy deszyfrujących. W takim ekosystemie inwestycja w rozwój technik niszczenia lub szyfrowania backupu jest po prostu opłacalna – zwiększa stopę zwrotu z każdego udanego włamania.

Od szyfrowania pojedynczych serwerów do uderzania w zdolność odtworzeniową

W starszych kampaniach ransomware celem były głównie stacje robocze lub wybrane serwery plików. Nawet jeśli część środowiska padła, zawsze pozostawały działające fragmenty infrastruktury. Administratorzy mogli odizolować zainfekowane maszyny, oczyścić środowisko i odtworzyć dane z backupu. Atak był bolesny, ale dawało się go „przeżyć” bez płacenia.

Obecnie scenariusz wygląda inaczej. Przestępcy myślą w kategoriach „całej organizacji jako ofiary”. Celem jest sparaliżowanie nie tylko serwerów aplikacyjnych, ale też procesu przywracania. Dlatego nowa fala ransomware:

• szuka i przejmuje konta administracyjne backupu,
• modyfikuje lub skraca polityki retencji,
• wyłącza zadania backupu albo „pozoruje” ich poprawne działanie,
• niszczy lub szyfruje istniejące punkty przywracania,
• uderza równolegle w backup lokalny i backup w chmurze.

Jeśli atakujący zniszczy zdolność odtworzeniową, organizacja traci realną alternatywę dla zapłaty. Nawet jeśli nie chce płacić z powodów etycznych, presja biznesowa, regulacyjna i czasu przestoju może ją do tego zmusić. To właśnie dlatego backup w chmurze stał się priorytetowym celem – jest kluczem do szybkiego powrotu do działania.

Chmura, BaaS i nowy model ataku

Rosnąca popularność rozwiązań chmurowych i modeli Backup as a Service (BaaS) zmieniła krajobraz techniczny. Dla wielu organizacji chmura stała się podstawową lokalizacją kopii zapasowych, a często także jedyną. To daje liczne korzyści: elastyczność, brak potrzeby zarządzania taśmami, łatwiejszą automatyzację. Z perspektywy cyberprzestępców to jednak również centralny punkt ataku.

Nowoczesne systemy backupu w chmurze są sterowane przez konsolę zarządzającą – dostępną przez przeglądarkę, API lub CLI. Jeśli napastnik uzyska do niej dostęp (bezpośrednio lub przez przejęte konto IAM), może w jednym miejscu:

• usunąć repozytoria backupowe,
• skasować lub skrócić polityki retencji,
• wyłączyć zadania backupu lub zmodyfikować ich harmonogram,
• dezaktywować funkcje immutable/WORM, jeśli nie są odpowiednio chronione.

Im silniej organizacja polega na chmurze jako jedynym lub głównym środowisku backupowym, tym większe konsekwencje powoduje przejęcie tej pojedynczej konsoli. Pojawia się też problem współdzielonej odpowiedzialności (shared responsibility): dostawca chmury zapewnia infrastrukturę, ale konfigurację backupu, tożsamości i uprawnień pozostawia po stronie klienta. W praktyce oznacza to, że słaba konfiguracja IAM w chmurze może zniweczyć nawet najlepsze technologicznie rozwiązanie backupowe.

Dlaczego backup w chmurze jest dziś celem nr 1 dla ransomware

Główne powody, dla których nowa fala ransomware atakuje kopie zapasowe w chmurze w pierwszej kolejności, można streścić w kilku punktach:

• Maksymalizacja presji szantażu – jeśli backup jest zniszczony, ofiara ma niewielkie pole manewru. Groźba „utracicie wszystko” brzmi inaczej, gdy jednocześnie upadł plan awaryjny.
• Podwójne i potrójne wymuszenia – poza szyfrowaniem danych przestępcy wykradają je i grożą publikacją. Jeśli dodatkowo zniszczą backup, ofiara traci możliwość spokojnej analizy sytuacji i stopniowego przywracania.
• Centralizacja zasobów – nowoczesny backup w chmurze jest scentralizowany. Wystarczy przejąć jedno konto lub jedną konsolę, aby mieć wpływ na całą infrastrukturę kopii zapasowych.
• Błędy konfiguracyjne – wiele wdrożeń BaaS jest chronionych słabiej niż krytyczne systemy produkcyjne. Brak MFA na koncie backup admina, używanie tych samych haseł, niewystarczające logowanie – to codzienność.

Efekt jest taki, że nowa fala ransomware nie jest już tylko problemem „blokady dostępu do danych”. To zintegrowana kampania mająca na celu jednoczesne uderzenie w produkcję, backup i reputację organizacji. Odpowiedź na nią wymaga zupełnie innego podejścia do projektowania zabezpieczeń kopii zapasowych w chmurze.

Jak działają współczesne ataki ransomware na backup w chmurze – łańcuch kill chain

Etap rozpoznania i inwentaryzacji środowiska kopii zapasowych

Nowoczesne ataki ransomware przebiegają w sposób uporządkowany i zorganizowany. Po początkowym włamaniu przestępcy zwykle nie przechodzą od razu do szyfrowania. Zamiast tego prowadzą długotrwałe rozpoznanie, którego jednym z kluczowych celów jest zlokalizowanie i zrozumienie środowiska kopii zapasowych – w tym backupu w chmurze.

Dostanie się do wewnętrznej sieci następuje najczęściej przez:

• phishing ukierunkowany (spear phishing) na administratorów lub użytkowników z wyższymi uprawnieniami,
• podatne serwery VPN lub bramy zdalnego dostępu bez aktualnych łatek,
• słabo zabezpieczone usługi zdalnego pulpitu (RDP) wystawione do Internetu,
• błędy w implementacji MFA (np. brak MFA na wszystkich krytycznych usługach, MFA fatigue).

Po uzyskaniu przyczółka w środku atakujący zaczynają skanować środowisko w poszukiwaniu agentów backupu, serwerów centralnego zarządzania, konsol BaaS i powiązanych usług. Robią to narzędziami znanymi również z legalnej administracji: skanery portów, narzędzia AD, komendy PowerShell, inwentaryzacja procesów i usług.

Charakterystyczne jest szukanie:

• nazw usług i procesów powiązanych z popularnymi systemami backupu,
• plików konfiguracyjnych zawierających adresy serwerów backupowych i dane logowania,
• skryptów automatyzacyjnych (PowerShell, Bash, Python), które łączą się z API dostawców chmurowych lub usług BaaS,
• modułów integracyjnych w systemach CI/CD lub narzędziach orkiestracji (np. Ansible, Terraform).

Celem tej fazy jest mapa infrastruktury backupu: gdzie są przechowywane kopie (lokalnie i w chmurze), jakim kontem są zarządzane, jakie zabezpieczenia obowiązują (MFA, sieć, role IAM) i które elementy są najsłabsze.

Eskalacja uprawnień i przejęcie tożsamości

Po rozpoznaniu przestępcy przechodzą do fazy eskalacji uprawnień. Tu kluczowa jest walka o przejęcie kont i tożsamości, które dają dostęp do zarządzania backupem w chmurze. Może to być konto:

• backup admina w systemie BaaS,
• global admina w tenantach SaaS (np. Microsoft 365, Google Workspace),
• administrator subskrypcji w chmurze publicznej (Azure, AWS, GCP),
• konto serwisowe używane przez narzędzia automatyzacji do zarządzania politykami backupu.

Do eskalacji uprawnień wykorzystywane są m.in.:

• luki w konfiguracji Active Directory (nadmierne uprawnienia, stare konta adminów, brak segmentacji),
• reuse haseł – to samo hasło na wielu kontach, w tym w chmurze,
• SIM swapping i przejmowanie SMS-ów do MFA,
• ataki typu MFA fatigue (masowe wysyłanie powiadomień push, aż użytkownik zaakceptuje),
• błędy w konfiguracji SSO/OAuth umożliwiające wydanie tokenów z szerokimi uprawnieniami.

Kluczowym elementem jest przejęcie tożsamości z najwyższymi możliwymi uprawnieniami w zakresie backupu. Raz przejęte konto global admina lub root w chmurze daje możliwość nie tylko kasowania zasobów, ale również tworzenia kolejnych uprzywilejowanych kont, wyłączania logów czy modyfikowania mechanizmów audytu. Atakujący starają się przy tym działać tak, aby nie wzbudzać alarmu – zmiany wprowadzają stopniowo, często w godzinach nocnych i w dni wolne.

Niszczenie lub szyfrowanie kopii zapasowych przed właściwym atakiem

Gdy napastnik zrozumie środowisko i przejmie odpowiednie uprawnienia, przechodzi do fazy przygotowania gruntu. Na tym etapie głównym celem stają się kopie zapasowe – zarówno lokalne, jak i te przechowywane w chmurze. Typowe działania obejmują:

• wyłączanie lub modyfikację zadań backupu – zadania są zatrzymywane albo harmonogramy zmieniane tak, aby nie wykonywały się regularnie,
• skracanie polityk retencji – np. z 90 dni do 7 dni, co po kilku tygodniach oznacza brak „starych” punktów przywracania, które nie są dotknięte infekcją,
• usuwanie punktów przywracania – ręczne lub skryptowe czyszczenie snapshotów i backupów,
• wyłączanie lub obchodzenie funkcji WORM/immutable, jeśli są chronione tylko logicznie (bez odpowiedniej separacji ról),
• szyfrowanie repozytoriów backupowych z użyciem tego samego lub innego ransomware niż w środowisku produkcyjnym.

Bardzo charakterystyczne jest opóźnienie właściwego szyfrowania produkcji. Przestępcy czekają, aż skrócone polityki retencji „zadziałają” i stare, wartościowe punkty przywracania zostaną usunięte w sposób całkowicie zgodny z konfiguracją. W jednym z udokumentowanych przypadków zmieniono retencję z 90 do 7 dni i dopiero po miesiącu uruchomiono masowe szyfrowanie. W logach wszystko wyglądało „normalnie” – system backupu po prostu robił to, co kazał mu „administrator”.

Na końcu, gdy kopie zapasowe są już zniszczone lub skompromitowane, uruchamiana jest właściwa faza ataku: jednoczesne szyfrowanie kluczowych systemów, wyciek danych i żądanie okupu. Wówczas jest już zwykle za późno na reakcję – organizacja dopiero wtedy odkrywa, że jej plan odtwarzania opierał się na backupach, które w praktyce nie istnieją lub są bezużyteczne.

Świeże techniki ataków na kopie zapasowe w chmurze – przegląd trendów

Ataki na warstwę tożsamości i uprawnień (IAM, SSO, OAuth)

Współczesne ransomware chmurowe koncentruje się na warstwie tożsamości. To nie firewalle czy same serwery backupu są pierwszym celem, ale konta użytkowników i usługi IAM, SSO oraz OAuth, które decydują, kto i do czego ma dostęp. Przejęcie konta root w chmurze lub global admina w tenantach SaaS jest często równoznaczne z przejęciem pełnej kontroli nad backupem w chmurze.

Do popularnych technik należą:

• password spraying i credential stuffing – wykorzystanie wycieków haseł z innych serwisów i ich automatyczne testowanie na portalach chmurowych; mało który administrator używa unikalnego, izolowanego hasła tylko do backupu,
• MFA fatigue – masowe wysyłanie powiadomień push do aplikacji uwierzytelniających, aż użytkownik w końcu kliknie „Akceptuj”, często w nocy lub w stresującej sytuacji,
• SIM swapping – przejęcie numeru telefonu używanego do SMS-ów MFA przez socjotechnikę u operatora telekomunikacyjnego,

Wykorzystywanie API dostawców chmurowych i BaaS do „legalnego” niszczenia backupu

Nowa generacja grup ransomware coraz częściej nie atakuje bezpośrednio serwerów backupu, tylko korzysta z oficjalnych API dostawców chmurowych i BaaS. Z ich perspektywy to bezpieczniejsze i bardziej „czyste” – operacje wykonywane są z poziomu konta z odpowiednimi rolami, wyglądają jak normalna administracja i są trudniejsze do zaklasyfikowania jako incydent.

Typowe scenariusze obejmują:

• masowe usuwanie snapshotów i wolumenów przy użyciu API IaaS (np. EC2, Azure VM, Compute Engine) – często z wcześniej przygotowanym skryptem PowerShell/CLI,
• modyfikację polityk lifecycle w obiektowych repozytoriach backupowych (S3, Azure Blob, GCS), tak aby dane były szybciej usuwane lub przenoszone do tańszych, wolniejszych klas storage,
• zmiany w konfiguracji BaaS poprzez ich API (zmiana retencji, wyłączanie jobów, modyfikacja repozytoriów),
• tworzenie nowych kluczy dostępowych (API keys, access keys) dla przejętych kont serwisowych, aby zachować trwały dostęp i możliwość powrotu.

Z perspektywy SOC te działania często nie wyglądają podejrzanie – administratorzy również czasem wykonują hurtowe operacje. Różnica polega na wzorcach i korelacji w czasie: np. w krótkim oknie czasowym pojawia się kilkaset operacji kasowania snapshotów na różnych kontach, z jednego adresu IP lub z tej samej tożsamości federowanej.

Jeżeli logowanie API nie jest wysyłane do centralnego systemu SIEM i nie ma profilowania „normalnego” zachowania dla kont backupowych, takie akcje przechodzą bez echa. Formalnie wszystko odbywa się zgodnie z uprawnieniami konta – z punktu widzenia chmury nie widać „atakującego”, tylko uprawnionego użytkownika.

Ataki na warstwę metadanych, indeksów i katalogów backupu

Wiele organizacji koncentruje się na samych plikach backupu, a zapomina o metadanych i indeksach, które umożliwiają ich efektywne wykorzystanie. Dla grup ransomware to atrakcyjny cel, bo nie zawsze trzeba zniszczyć wszystkie dane – czasem wystarczy unieczynnić system przywracania.

Spotykane techniki obejmują:

• uszkadzanie baz katalogowych backupu (np. SQL/NoSQL przechowujących informację o jobach, punktach przywracania, lokalizacjach danych),
• modyfikację wpisów katalogowych, tak aby narzędzie backupowe „widziało” backupy jako niekompatybilne, niekompletne lub należące do innego środowiska,
• atak na serwery indeksowania pełniące rolę warstwy pośredniej między danymi a konsolą zarządzania,
• sabotaż konfiguracji repozytoriów – np. zmiana ścieżek, kluczy szyfrujących, credentiali używanych do podłączania storage.

Dla administratora efekt bywa mylący: pliki backupu fizycznie istnieją w chmurze, ale system backupowy raportuje je jako nieczytelne, „orphaned” lub nieprzypisane do żadnej polityki. Odbudowa takiego środowiska bywa możliwa, lecz wymaga głębokiej znajomości mechanizmów wewnętrznych i często angażuje support producenta – co wydłuża RTO o wiele godzin lub dni.

Wykorzystanie funkcji legalnego usuwania danych (GDPR, retention policies)

Trend regulacyjny sprzyja przestępcom. Coraz więcej rozwiązań SaaS i BaaS oferuje funkcje „legal hold”, „right to be forgotten” czy automatycznego kasowania po okresie retencji związanym z RODO. Źle skonfigurowane stają się narzędziem w rękach ransomware.

Jeśli atakujący przejmie konto z uprawnieniami do zarządzania politykami retention, może:

• skrócić globalne okresy przechowywania dla całych klas danych (np. poczta, pliki współdzielone, dane CRM) w sposób zgodny z regulacjami, ale sprzeczny z potrzebami odtwarzania,
• oznaczyć konkretne zbiory jako dane do usunięcia w ramach procesu privacy, co uruchomi nieodwracalne procedury kasowania w zapleczu dostawcy,
• modyfikować wyjątki i „legal hold”, tak aby zdjąć ochronę z danych objętych obecnie postępowaniami prawnymi lub audytami.

Takie działania, jeśli są rozłożone w czasie, trudno odróżnić od biznesowych decyzji compliance. W wielu organizacjach nikt nie porównuje systematycznie zmian w politykach retention z planem odtwarzania ani nie weryfikuje ich pod kątem odporności na ataki.

Podszywanie się pod usługę backupu w łańcuchu CI/CD i DevOps

W środowiskach DevOps backup często jest częścią pipeline’ów CI/CD. Skrypty tworzą snapshoty testowych baz danych, zrzuty konfiguracji Kubernetes, backupy klastrów itp. To wygodne, ale wprowadza nowe wektory ataku.

Napastnik, który przejmie kontrolę nad środowiskiem CI/CD (Git, runner, orchestrator), może:

• podmienić skrypty backupowe tak, aby zamiast realnego backupu tworzyły zaszyfrowane lub puste archiwa,
• dodać etap „cleanup” kasujący stare snapshoty i artefakty backupowe po każdej udanej kompilacji,
• wstrzyknąć złośliwy kod do kontenerów lub agentów backupu budowanych i dystrybuowanych z pipeline’u,
• przekierować backupy do innego, kontrolowanego przez nich storage (exfiltration w przebraniu backupu).

Ryzyko rośnie tam, gdzie klucze do chmury (access keys, service principals) są trzymane w pipeline’ach lub repozytoriach jako sekrety i mają zbyt szerokie uprawnienia. Jeśli tymi samymi credentialami zarządzane są środowiska produkcyjne i backupowe, przejęcie jednego z nich automatycznie otwiera drogę do drugiego.

Ataki „living-off-the-land” w chmurze (LOLBins/LOLBas)

W tradycyjnych sieciach techniki „living-off-the-land” wykorzystują wbudowane narzędzia systemowe (PowerShell, WMI, certutil). W chmurze analogiem są wbudowane narzędzia administracyjne dostawców – konsola webowa, CLI, shell w przeglądarce, Cloud Functions, automatyzacja polityk.

Takie ataki na backup w chmurze polegają na:

• użyciu wbudowanych CLI (aws, az, gcloud) do zarządzania bucketami backupowymi, snapshotami, kluczami KMS,
• tworzeniu lub modyfikowaniu funkcji serverless, które okresowo czyszczą dane, rotują klucze szyfrujące lub przenoszą backupy do trudno dostępnych lokalizacji,
• wykorzystaniu wbudowanych mechanizmów orkiestracji (np. AWS Systems Manager, Azure Automation) do wykonywania skryptów czyszczących na skalę całej organizacji,
• maskowaniu się wśród normalnych operacji serwisowych, np. okien utrzymaniowych.

Taki styl ataku jest wyjątkowo trudny do wykrycia klasycznymi narzędziami EDR, ponieważ nie wymaga wgrywania dodatkowego malware do środowiska chmurowego. Całość odbywa się na poziomie uprawnień i konfiguracji, które z definicji są dynamiczne.

Słabe punkty typowych wdrożeń backupu w chmurze

Nadmierna wiara w samą obecność backupu w chmurze

Częsty błąd polega na utożsamianiu „backup w chmurze” z „bezpieczeństwo”. Dane są co prawda kopiowane do innego środowiska, ale model zaufania pozostaje taki sam: te same konta administracyjne, ta sama domena, te same klucze. Jeśli atakujący przejmie kontrolę nad środowiskiem on-prem, to praktycznie z marszu uzyskuje dostęp do backupu w chmurze.

W praktyce wygląda to tak, że:

• serwer backupu korzysta z tego samego AD, co reszta infrastruktury,
• konto „backupadmin” ma dostęp zarówno do konsoli backupu, jak i do portalu chmurowego,
• nie ma odrębnych procesów weryfikacji operacji backup/restore (brak zasady „czterech oczu”).

W takiej konfiguracji atakujący po eskalacji do domenowego admina natychmiast uzyskuje uprzywilejowany dostęp do konsoli backupu, repozytoriów chmurowych oraz polityk retencji. Fizyczne odseparowanie danych nic nie daje, jeśli logiczna kontrola pozostaje w jednych rękach.

Brak realnej separacji ról i przywilejów

W wielu organizacjach funkcja „Backup Administrator” jest przydzielana z przyzwyczajenia wszystkim inżynierom infrastruktury, a role IAM w chmurze mają bardzo szeroki zakres. Efekt to płaska struktura uprawnień, w której trudno zidentyfikować, kto naprawdę potrzebuje dostępu do jakiego elementu backupu.

Typowe symptomy:

• jeden lub dwa „superkonta” z pełnym dostępem do wszystkiego, używane na co dzień,
• brak oddzielenia roli „tworzy backup” od roli „usuwa backup” i „modyfikuje polityki”,
• to samo konto służy do operacji administracyjnych i do integracji automatyzacji (skrypty, CI/CD),
• rola „Owner” lub „Global Administrator” w chmurze nadana całym grupom AD.

Jeśli uprawnienia nie są granulowane, trudno jest nawet wprowadzić skuteczną detekcję nadużyć. Próba ustawienia alertu „gdy ktoś kasuje więcej niż X backupów dziennie” kończy się lawiną fałszywych alarmów, bo zgodnie z konfiguracją większość operacji i tak wykonują te same superkonta.

Niedostosowane polityki retencji i brak rozproszenia w czasie

Admini często projektują retencję backupów pod kątem kosztów storage i wymogów prawnych, a nie pod kątem odporności na scenariusz „cichego sabotażu”. Jeśli wszystkie kopie są przechowywane w krótkim horyzoncie (np. 14–30 dni) i brak jest wersji miesięcznych lub kwartalnych, pojedyncza zmiana polityki retencji potrafi wyczyścić całą historię w kilka tygodni.

Problem pogłębia się, gdy:

• backupy aplikacji SaaS (np. M365) mają krótką, jednolitą retencję,
• warstwa archiwum (np. taśmy, tier „glacier”) nie jest stosowana lub jest konfigurowana ręcznie „ad hoc”,
• nie ma „twardych” punktów kontrolnych (np. nieusuwalne miesięczne backupy pełne).

Atakujący, który zmodyfikuje retencję, może spokojnie czekać na to, aż system w pełni „legalnie” wyczyści starsze dane. Jeżeli nikt nie analizuje trendów pojemności repozytoriów i liczby punktów przywracania w dłuższym okresie, taki proces pozostaje niezauważony aż do incydentu.

Koncentracja na szyfrowaniu danych, ignorowanie kontroli dostępu

Szyfrowanie backupu w chmurze jest standardem, ale często stanowi alibi dla braku solidnej kontroli dostępu. Organizacja czuje się bezpiecznie, bo dane są zaszyfrowane, jednak klucze KMS są zarządzane przez te same osoby i konta, które administrują całym środowiskiem.

Najczęstsze pułapki:

• jeden klucz KMS do wielu krytycznych repozytoriów backupowych,
• rola „Key Admin” i „Key User” przypisana tym samym grupom,
• brak wymogu oddzielnego zatwierdzania operacji „disable key” lub „schedule key deletion”,
• brak kopii zapasowych samych kluczy (np. HSM offline, inny tenant) lub procedury ich odzyskiwania.

Atak na warstwę kluczy bywa prostszy niż masowe kasowanie danych. Wystarczy wyłączyć lub usunąć klucz, a backup pozostaje nienaruszony, lecz nieodczytywalny. Taka operacja często jest trudniejsza do odwrócenia niż przywrócenie danych z archiwum.

Niedojrzałe monitorowanie i brak testów odtwarzania z perspektywy ataku

Wiele firm przeprowadza testy odtwarzania w trybie „grzecznościowym”: przywracany jest wybrany serwer lub baza, zwykle z najnowszego punktu. Rzadko kiedy symuluje się scenariusz, w którym atakuje się właśnie środowisko backupu: kasuje część repozytoriów, skraca retencję, psuje indeksy.

Słabości są widoczne szczególnie tu:

• monitoring skupia się na wynikach jobów (sukces/porażka), a nie na anomaliach w samych konfiguracjach,
• brakuje alertów konfiguracyjnych (zmiany retencji, wyłączenie jobów, usuwanie repozytoriów),
• nikt nie weryfikuje regularnie możliwości przywracania w innym tenantcie / regionie / domenie,
• brakuje scenariuszy „tabletop” zakładających pełne przejęcie konta backup admina.

Jeśli testy DR kończą się na sprawdzeniu, czy najnowszy backup da się odtworzyć na tej samej infrastrukturze, nie ma realnego obrazu odporności na nową falę ransomware. Przy realnym incydencie okazuje się, że brakuje nie tylko danych, ale także kompetencji i procedur.

Architektura odpornego backupu w chmurze – założenia i wzorce

Model „zero trust” dla backupu – separacja domen zaufania

Oddzielenie kontroli nad danymi od kontroli nad infrastrukturą

Klucz do „zero trust” w backupie to rozdzielenie kto kontroluje infrastrukturę (hosty, klastry, tenanty, VPC/VNet) od tego, kto kontroluje dane backupowe (repozytoria, klucze szyfrujące, polityki retencji). Te dwa wektory nie mogą się spotykać w jednym koncie „wszechwiedzącym” administratora.

Praktyczna implementacja wygląda zwykle następująco:

• oddzielny tenant / subskrypcja / konto w chmurze przeznaczone wyłącznie na backup i funkcje DR,
• osobne grupy tożsamości (AD/AAD/IdP) dla adminów backupu i dla adminów produkcji,
• brak stałego SSO infrastruktura → backup: dostęp tylko przez zatwierdzane wnioski i tymczasowe role z ograniczonym zakresem,
• rozłączność ról: osoba, która może zatrzymać produkcję, nie może usunąć backupów i odwrotnie.

Taka segmentacja powoduje, że przejęcie domenowego admina, root-a w Kubernetes czy konta global admina w SaaS nie wystarczy do zniszczenia całego zaplecza backupowego. Atakujący musi wykonać dodatkowe kroki, które są łatwiejsze do monitorowania i blokowania (wnioski o podniesienie uprawnień, niecodzienne logowania, dostęp z nowych lokalizacji).

Wielowarstwowy model backupu: „gorący”, „ciepły” i „zimny” poziom zaufania

Backup w chmurze nie powinien być pojedynczym bytem. Bardziej odporny jest model, w którym istnieją trzy poziomy kopii, z różnym czasem dostępu i różnym poziomem zaufania do środowiska, które je obsługuje:

• warstwa „gorąca” (hot) – szybkie, częste backupy i snapshoty, służące do przywracania incydentów operacyjnych (błąd wdrożenia, awaria hosta); najbliżej produkcji i najbardziej narażone na kompromitację,
• warstwa „ciepła” (warm) – backupy okresowe, zazwyczaj w innej strefie dostępności lub regionie, przechowywane w dłuższej retencji, z częściowo innym zestawem uprawnień,
• warstwa „zimna” (cold) – docelowo izolowane repozytoria (inny tenant, inne konto, inna domena), dostępne tylko przez specjalne procedury; to ostateczna linia obrony przeciwko scenariuszom kryptolockera i sabotażu.

Dla każdej warstwy definiuje się inny profil ryzyka i inne wymagania:

• w „gorącej” priorytetem jest RPO/RTO, więc akceptuje się większe ryzyko, ale zarządza się nim przez monitoring i automatyczną detekcję anomalii,
• w „ciepłej” kosztem jest dłuższy czas przywracania, lecz w zamian wymusza się ściślejsze kontrole dostępu (MFA, just-in-time, role tymczasowe),
• w „zimnej” nacisk kładzie się na nienaruszalność: tu dopuszczalne są nawet ręczne procesy i dłuższy czas reakcji, o ile gwarantują, że dane nie zostaną usunięte ani nadpisane.

Izolowane domeny tożsamości i minimalny trust z IdP

Jeśli ten sam IdP (np. Azure AD lub centralny IdP SAML) kontroluje zarówno środowiska produkcyjne, jak i backupowe, kompromitacja tego IdP umożliwia przejęcie wszystkiego. Dlatego przy projektowaniu odpornego backupu w chmurze stosuje się izolację domen tożsamości.

Może to oznaczać:

• oddzielny tenant IdP dla środowiska „backup/DR”,
• osobny katalog (directory) w ramach tego samego dostawcy, ale z innym łańcuchem uprawnień i niezależną grupą właścicieli,
• lokalne konta awaryjne (break-glass) z silnymi politykami dostępu, przechowywane w offline-owym sejfie haseł.

Jeśli nie da się zastosować pełnej separacji, minimalizuje się zaufanie między domenami:

• kontroluje się, które grupy z głównego IdP mogą uzyskać dostęp do roli w tenantcie backupowym,
• dla każdej takiej roli wymusza się silny MFA (np. FIDO2) i krótkie sesje,
• regularnie przegląda się mapowanie grup i usuwa wyjątki, które „tymczasowo” stały się permanentne.

„WORM by design”: nieusuwalne backupy i blokada modyfikacji

Ransomware uderza przede wszystkim w możliwość modyfikacji lub usuwania kopii. Dlatego w architekturze odpornej na tego typu ataki centralnym elementem jest mechanizm WORM (Write Once Read Many) lub jego chmurowe odpowiedniki (object lock, immutable backups, retention lock).

W praktyce mechanizm ten powinien mieć kilka cech:

• retencja zapisywana w metadanych obiektu (a nie tylko w konfiguracji joba backupowego),
• blokada zmiany retencji w dół bez specjalnej procedury (np. zewnętrzna zgoda, ticket zatwierdzony przez inną jednostkę),
• niemożność masowego wyłączenia „immutability” jednym kliknięciem przez to samo konto, które zarządza backupem na co dzień,
• logowanie każdej operacji WORM (włącz/wyłącz, skróć/wydłuż retencję) do niezależnego systemu SIEM.

Dobrym wzorcem jest podział na:

• poziom polityk – admin backupu definiuje, że dla danej klasy danych obowiązuje np. 7 lat nieusuwalności,
• poziom technicznej blokady – inna rola, w innym systemie, faktycznie zakłada blokadę na bucket/obiekt według zadanej polityki,
• poziom audytu – niezależny zespół (np. kontroli wewnętrznej) otrzymuje raporty o każdej próbie modyfikacji WORM.

Segmentacja storage i kluczy szyfrujących

Aby atak na jeden element infrastruktury nie pociągał za sobą całego backupu, separuje się nie tylko konta i role, ale też samą przestrzeń dyskową oraz klucze szyfrujące.

Kilka praktycznych zasad:

• różne klastry/regiony/chmurowi providerzy powinny mieć oddzielne klucze KMS/HSM,
• backup danych o różnym profilu wrażliwości (np. HR vs. logi techniczne) powinien korzystać z odrębnych kluczy i ról „Key User”,
• role administracyjne do zarządzania storage nie powinny automatycznie mieć uprawnień do operacji na kluczach (encrypt/decrypt, disable, schedule deletion),
• najwrażliwsze klucze dla warstwy „zimnej” powinny mieć swój osobny cykl życia i odrębną procedurę odtwarzania (np. backup w fizycznym HSM).

Skutkiem jest sytuacja, w której atakujący, który zdoła wyłączyć backup w jednym regionie lub przejąć jeden zestaw kluczy, nie ma automatycznego dostępu do reszty kopii. Musi powtórzyć wysiłek dla każdej domeny kluczy, co daje czas na detekcję i reakcję.

Just-in-time i „cztery oczy” dla operacji wrażliwych

W środowiskach o wysokiej odporności na ransomware nie ma stałych uprawnień typu „może wszystko zawsze”. Zamiast tego praktykuje się dostęp just-in-time oraz zasadę „czterech oczu” dla wybranych operacji.

Do operacji, które powinny wymagać dodatkowej autoryzacji, zalicza się m.in.:

• trwałe skrócenie retencji backupów,
• usuwanie repozytoriów lub kontenerów backupowych,
• wyłączanie lub usuwanie kluczy KMS,
• zmiana polityk WORM/immutable,
• masowe wyłączanie jobów backupowych lub schedulera.

Just-in-time można wdrożyć np. przez:

• system zarządzania uprzywilejowanymi kontami (PAM), który wydaje czasowe bilety dostępu,
• automatyczne przydzielanie ról w chmurze na określony czas na podstawie zatwierdzonego zgłoszenia,
• wymóg drugiej autoryzacji (np. innego członka zespołu lub przełożonego) przy próbie wykonania krytycznej operacji.

Rozproszone ścieżki odzyskiwania: „escape hatches” poza głównym środowiskiem

Jeśli przyjmuje się założenie, że całe główne środowisko (domena, IdP, główny tenant chmurowy) może być skażone, potrzebne są alternatywne ścieżki odzyskiwania. Chodzi o to, by w scenariuszu persystentnego ataku na infrastrukturę nadal dało się odtworzyć kluczowe systemy.

Elementy takiej architektury to m.in.:

• odrębny „clean room” – wydzielony tenant/konto/region, gdzie odtwarza się dane w kontrolowany sposób (z ograniczonym dostępem i ścisłą inspekcją),
• niezależna ścieżka logowania – alternatywny IdP lub lokalne konta break-glass, pozwalające zalogować się do środowiska DR, gdy główne SSO jest skompromitowane,
• automatyczne runbooki (Infrastructure as Code + skrypty), które są weryfikowane i przechowywane również poza głównym repozytorium Git (np. wydrukowane lub zapisane w offline-owym sejfie).

W dobrze zaprojektowanym scenariuszu test odtworzenia obejmuje nie tylko przywrócenie danych, ale realne wejście do „clean roomu” i uruchomienie kluczowych systemów bez polegania na skażonym IdP i sieci produkcyjnej.

Odporne na atak pipeline’y backupowe

W dojrzałych środowiskach backup w chmurze jest w dużej mierze zautomatyzowany – i słusznie. Jednak ta automatyzacja musi samej sobie ufać jak najmniej. Pipeline’y orkiestrujące backup i kopiowanie danych między warstwami również wymagają osobnej architektury bezpieczeństwa.

Dobry wzorzec to:

• osobna platforma CI/CD dla skryptów backupowych lub przynajmniej osobny „project” z innymi secretami i politykami dostępu,
• tokeny krótkoterminowe zamiast statycznych kluczy w pipeline’ach,
• twarde ograniczenia uprawnień technicznych kont pipeline’ów: mogą pisać do repozytoriów i modyfikować joby, ale nie mogą ich usuwać ani skracać retencji,
• obowiązkowe code review i skanowanie IaC/skriptów pod kątem operacji destrukcyjnych (delete, truncate, disable, reduce-retention),
• logowanie wszystkich wywołań API pochodzących z konta CI/CD do niezależnego systemu logów (np. osobny tenant log analytics).

W jednym z praktycznych przypadków, w którym udało się powstrzymać sabotaż backupu, krytyczna różnica polegała właśnie na tym, że pipeline’y mogły tworzyć snapshoty i kopiować je do „zimnej” warstwy, ale absolutnie nie miały uprawnień do usuwania istniejących kopii ani do zmiany retencji. Próba ataku ujawniła się w logach jako seria nieudanych wywołań API.

Monitoring zorientowany na intencje, nie tylko na błędy

Tradycyjne monitorowanie backupu skupia się na statusach zadań. W kontekście nowej fali ransomware istotniejsze staje się monitorowanie intencji – czyli próby wykonania operacji, które zwykle są rzadkie, ale mają ogromne znaczenie.

Zakres monitoringu powinien obejmować co najmniej:

• zmiany polityk retencji, w tym każdorazowe skrócenie okresu przechowywania,
• operacje na kluczach szyfrujących (disable, schedule deletion, rotation poza harmonogramem),
• tworzenie, modyfikowanie i kasowanie repozytoriów / bucketów backupowych,
• masowe wyłączenia jobów i harmonogramów,
• zmiany konfiguracji WORM/immutable i polityk dostępu do storage,
• nietypowe wzorce logowań do systemów backupowych (nowe lokalizacje, nowe urządzenia, brak wcześniejszej historii).

Użyteczne bywają również wskaźniki pojemnościowe:

• zbyt szybki spadek ilości danych w repozytoriach w porównaniu z historycznym trendem,
• nagły spadek liczby punktów przywracania w oknie retencji,
• brak nowych backupów dla wybranej grupy krytycznych systemów przy jednoczesnym braku błędów jobów (czyli joby zostały „legalnie” wyłączone).

Takie sygnały powinny być kierowane do zespołów odpowiedzialnych za bezpieczeństwo, nie tylko do zespołu backupu. Często inżynier backupu jest za blisko codziennych zmian, by od razu zobaczyć anomalię, która dla analityka SOC będzie oczywista.

Testy odtwarzania w trybie „atak na backup”

Sama architektura nie wystarczy, jeśli nie jest regularnie weryfikowana z perspektywy przeciwnika. Coraz częściej praktykuje się testy DR, które zakładają, że środowisko backupu jest celem ataku, a nie tylko źródłem danych.

Najczęściej zadawane pytania (FAQ)

Dlaczego ransomware coraz częściej atakuje kopie zapasowe w chmurze?

Ransomware uderza w backup w chmurze, ponieważ to on decyduje, czy organizacja ma realną alternatywę dla zapłacenia okupu. Jeśli kopie zapasowe są zniszczone lub skompromitowane, szantażujący znacząco zwiększa presję – ofiara traci możliwość spokojnego przywracania środowiska i analizowania szkód.

Dodatkowo backup w chmurze jest zwykle scentralizowany i zarządzany z jednej konsoli. Przejęcie jednego konta administracyjnego (lub konta IAM) pozwala atakującemu wyłączyć zadania backupu, skrócić retencję i usunąć punkty przywracania w całej organizacji. To szybkie i bardzo opłacalne z perspektywy przestępcy.

Jak w praktyce wygląda atak ransomware na backup w chmurze?

Typowy scenariusz obejmuje najpierw ciche rozpoznanie: po włamaniu do sieci przestępcy szukają serwerów backupu, konsol BaaS, agentów oraz skryptów łączących się z API chmury. Wykorzystują do tego narzędzia administracyjne, skanery i skrypty, żeby zbudować mapę całej infrastruktury kopii zapasowych.

Kolejny krok to eskalacja uprawnień i przejęcie kont administracyjnych – backup admina, global admina w SaaS, administratora subskrypcji w chmurze czy kont serwisowych. Dopiero mając ten dostęp, modyfikują polityki retencji, wyłączają zadania, usuwają repozytoria i równolegle przygotowują właściwe szyfrowanie środowiska produkcyjnego.

Jakie błędy konfiguracji backupu w chmurze najczęściej wykorzystują przestępcy?

Najczęściej chodzi o proste zaniedbania, które otwierają drogę do przejęcia konsoli backupu lub kont chmurowych. Spotykane są m.in. brak MFA na kontach backup adminów, używanie tych samych haseł co do systemów produkcyjnych, zbyt szerokie role IAM oraz brak segmentacji sieciowej dla serwerów i agentów backupu.

Drugą kategorią są błędne założenia dotyczące usług BaaS i modelu shared responsibility. Klienci traktują usługę backupu „w chmurze” jako automatycznie bezpieczną, a tymczasem konfiguracja ról, retencji, kontroli dostępu i logowania leży po ich stronie. Jeśli zatem konto z uprawnieniami do konsoli BaaS zostanie przejęte, przestępca może w pełni zniszczyć zdolność odtworzeniową.

Jak zabezpieczyć backup w chmurze przed ransomware w pierwszej kolejności?

Podstawą jest podejście „backup jako system krytyczny”. Oznacza to m.in. włączenie silnego MFA na wszystkich kontach administracyjnych, ograniczenie dostępu sieciowego do konsol backupu i serwerów zarządzających oraz rozdzielenie ról – inne konta do administracji produkcją, inne do administracji kopią zapasową.

W praktyce skuteczne są też: wykorzystanie funkcji immutable/WORM tam, gdzie to możliwe, utrzymywanie co najmniej jednej kopii offline lub w innej strefie bezpieczeństwa, regularne testy odtwarzania oraz monitorowanie logów dostępowych do systemów backupowych i kont IAM. Jeśli coś „nagle” skraca retencję lub wyłącza zadania – powinien pojawić się alarm.

Czy backup w chmurze wystarczy jako jedyne zabezpieczenie przed ransomware?

Nie, jeśli jest jedynym mechanizmem i nie ma dodatkowych warstw ochrony. Sam fakt trzymania kopii w chmurze nie rozwiązuje problemu, bo nowoczesne gangi ransomware traktują tę infrastrukturę jako kluczowy cel ataku. Przejęcie jednej konsoli może oznaczać utratę całej historii backupów.

Bezpieczniej jest łączyć różne modele: backup w chmurze, kopie w innej lokalizacji lub innym koncie/tenancie, segmentację środowisk oraz mechanizmy immutable. Liczy się nie tylko ilość kopii, ale przede wszystkim ich odporność na modyfikację po stronie atakującego oraz realne, sprawdzone procedury odtwarzania.

Na co zwrócić uwagę przy wyborze usługi Backup as a Service (BaaS) pod kątem ransomware?

Kluczowe są funkcje bezpieczeństwa, a nie tylko cena i wygoda. Ważne jest, czy BaaS oferuje natywne mechanizmy immutable/WORM, jak wygląda integracja z IAM dostawcy chmury (granularne role, MFA, polityki haseł) oraz jakie są możliwości logowania i audytu działań administracyjnych.

Warto też sprawdzić, czy da się łatwo izolować różne środowiska (produkcyjne, testowe) w osobnych tenantach lub subskrypcjach, czy usługa umożliwia automatyczne testy odtwarzania oraz czy dostawca jasno określa podział odpowiedzialności za konfigurację bezpieczeństwa. Jeśli te elementy są niejasne, ryzyko skutecznego ataku ransomware na backup znacząco rośnie.