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ę