S3 Object Lock: kopia, której nie da się skasować – WORM, retencja i Anty-Ransomware

Blog WebDisk · kategoria: Bezpieczeństwo · czas czytania: ~12 minut

W skrócie:- S3 Object Lock zamienia magazyn obiektów w WORM (write once, read many): zapisany plik można czytać, ale przez zadany okres żadne żądanie S3 – także administratora czy właściciela konta – nie zmieni go ani nie usunie.- To dziś podstawowa obrona kopii zapasowych przed ransomware, które rutynowo kasuje backupy, zanim zaszyfruje produkcję.- W WebDisk Files ten mechanizm nazywa się Anty-Ransomware: włączasz go przełącznikiem na magazynie i masz magazyn klasy WORM na kopie zapasowe. >Nie pracujesz z terminalem? Pomiń przykłady kodu – opis mechanizmu i sekcja o WebDisk dają pełny obraz.

Współczesny atak ransomware rzadko zaczyna się od szyfrowania. Napastnik, który zdobył dostęp do infrastruktury, najpierw spędza w niej dni albo tygodnie – i w tym czasie metodycznie szuka kopii zapasowych. Kasuje je, szyfruje albo psuje po cichu. Dopiero gdy ofiara nie ma do czego wrócić, uruchamia właściwe szyfrowanie i wystawia żądanie okupu. Logika jest brutalnie prosta: firma, która ma sprawny backup, nie zapłaci.

Wniosek z tysięcy takich incydentów brzmi: kopia zapasowa, którą da się usunąć tymi samymi uprawnieniami, którymi ją zapisano, nie jest zabezpieczeniem – jest złudzeniem zabezpieczenia. Potrzebna jest kopia, której nie skasuje ani napastnik z przejętymi kluczami, ani omylny skrypt, ani – co najtrudniejsze do przyjęcia — my sami w złym dniu. W świecie S3 dokładnie to robi Object Lock. W tym artykule wyjaśniamy, jak działa, pokazujemy przykłady użycia i opisujemy, jak zbudowaliśmy na nim funkcję Anty-Ransomware w WebDisk Files.

WORM: pomysł starszy niż chmura

WORM (write once, read many – „zapisz raz, czytaj wiele razy”) to koncepcja znana od dziesięcioleci. Najbardziej swojski przykład to płyta CD-R: nagraną raz zawartość można odczytywać do woli, ale nie da się jej nadpisać ani wymazać — fizyka nośnika po prostu na to nie pozwala. Banki i archiwa od lat używają nośników i macierzy WORM tam, gdzie prawo wymaga, by zapis pozostał nietknięty: rejestry transakcji, dokumentacja medyczna, korespondencja podlegająca nadzorowi.

S3 Object Lock przenosi tę gwarancję do magazynu obiektów – bez specjalnego sprzętu. Blokadę egzekwuje sama warstwa magazynu: żądanie usunięcia lub nadpisania chronionej wersji obiektu jest odrzucane, niezależnie od tego, kto i z jakimi uprawnieniami je wysłał. To kluczowa różnica wobec zwykłych uprawnień (polityk IAM): politykę ktoś z odpowiednim dostępem może zmienić – blokady WORM w trybie Compliance nie zdejmie żadne żądanie S3.

Fundament: wersjonowanie

Object Lock nie działa w próżni – wymaga wersjonowania bucketa (bucket — pojemnik na pliki w magazynie S3, odpowiednik dysku czy udziału; w usługach WebDisk nazywamy go magazynem). Wersjonowanie sprawia, że magazyn nigdy niczego nie nadpisuje w miejscu: każdy zapis pod istniejącą nazwą tworzy nową wersję obiektu, a poprzednie zostają. „Usunięcie” pliku w wersjonowanym buckecie też nie kasuje danych – dokłada tylko znacznik usunięcia (delete marker), spod którego starsze wersje da się w każdej chwili wyjąć.

Dopiero na tym fundamencie blokada ma sens, bo Object Lock chroni konkretne wersje obiektów. Praktyczna konsekwencja, którą warto zrozumieć: zapis nowej zawartości pod tą samą nazwą nie jest blokowany – powstaje po prostu kolejna wersja. Chroniona wersja leży nienaruszona obok. Obrazowo:

plik „raport.pdf” w buckecie z Object Lock:

  [znacznik usunięcia] ← plik „zniknął” z listingu…
  v2 zapis ransomware ← …„nadpisany” śmieć wylądował OBOK, nie zamiast
  v1 🔒 Compliance do 1.11 ← oryginał: nietykalny, gotowy do przywrócenia

Ransomware może więc „nadpisać” Twoje pliki zaszyfrowanym śmieciem i „skasować” je z listingu, ale oryginalne, zablokowane wersje przetrwają – i będzie można do nich wrócić.

Dwa tryby i dwa mechanizmy blokady

Blokadę wersji można założyć na dwa sposoby i w dwóch trybach – i te rozróżnienia są najważniejszą techniczną częścią tego artykułu.

Retencja (retention) – blokada terminowa: wersja ma datę retain-until-date, przed którą nie można jej usunąć ani zmienić. Datę można ustawić wprost przy zapisie obiektu albo skonfigurować domyślną retencję bucketa (np. „każdy nowy obiekt: 90 dni”) – wtedy ochrona obejmuje wszystko automatycznie, bez współpracy ze strony zapisującego narzędzia.

Tryby retencji:

• Governance – blokada z furtką: zwykli użytkownicy nie mogą nic zrobić, ale wskazani użytkownicy ze specjalnym uprawnieniem (s3:BypassGovernanceRetention) mogą blokadę skrócić lub zdjąć. Dobre do porządkowania procesów i na okres testów: chroni przed pomyłką, nie chroni przed napastnikiem, który przejmie konto uprzywilejowane.
• Compliance – blokada bez furtki w warstwie S3: do upływu daty retencji wersji nie usunie żadne żądanie S3 – niezależnie od tego, czy wyśle je właściciel konta, administrator organizacji, czy napastnik z przejętym kontem uprzywilejowanym. Okres można wyłącznie wydłużyć, nigdy skrócić. To jest tryb właściwy dla ochrony przed ransomware i dla wymogów prawnych. (Poza warstwą S3 u każdego dostawcy pozostaje co najwyżej ściśle kontrolowana, audytowana procedura operatorska – jak wygląda u nas, opisujemy uczciwie w FAQ.)
• Legal hold – blokada bezterminowa, niezależna od retencji: włącznik „wstrzymaj wszystko do odwołania” na pojedynczej wersji. Nie ma daty końca; zdejmuje ją świadoma decyzja osoby z odpowiednim uprawnieniem. Używana, gdy trwa spór prawny albo śledztwo i danych nie wolno ruszyć, dopóki sprawa się nie zakończy.
• Czas trwania – Governance: do daty retencji · Compliance: do daty retencji · Legal hold: do odwołania
• Można skrócić/zdjąć? – Governance: tak, ze specjalnym uprawnieniem · Compliance: nie – żadnym żądaniem S3 · Legal hold: tak, uprawnieniem legal hold
• Można wydłużyć? – Governance: tak · Compliance: tak (tylko wydłużyć) · Legal hold: nie dotyczy
• Typowe zastosowanie – Governance: procesy wewnętrzne, testy · Compliance: ransomware, wymogi prawne · Legal hold: spory sądowe, śledztwa

Zrób to sam: WORM w terminalu

Zanim zaczniesz. Przykłady używają aws CLI skonfigurowanego jak w poprzednich artykułach cyklu (aws configure + --endpoint-url Twojego dostawcy – pomijamy go niżej dla czytelności). Ostrożnie z prawdziwymi danymi: blokad Compliance nie da się cofnąć – dlatego wszystkie ćwiczenia niżej używają retencji 1 dnia i testowego bucketa; wartości produkcyjne pokazujemy w komentarzach.

Object Lock włącza się przy tworzeniu bucketa (o doposażaniu istniejącego — w FAQ):

# 1. bucket z włączonym Object Lock (wersjonowanie włącza się automatycznie)
aws s3api create-bucket --bucket backup-worm \
  --object-lock-enabled-for-bucket

# 2. domyślna retencja Compliance — UWAGA: ten krok jest nieodwracalny w skutkach,
# każdy nowy obiekt będzie nietykalny przez zadany okres
aws s3api put-object-lock-configuration --bucket backup-worm \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":1}}}'
# do ćwiczeń: 1 dzień · w produkcji dla backupów: {"Mode":"COMPLIANCE","Days":90}

# 3. zwykły upload — ochrona nakłada się sama, narzędzie backupowe
# nie musi nic wiedzieć o Object Lock
aws s3 cp backup-2026-08-02.tar.gz s3://backup-worm/

Od tej chwili każda zapisana wersja jest nietykalna przez zadany okres. Sprawdźmy:

# metadane wersji: tryb blokady i data, do której obowiązuje
aws s3api head-object --bucket backup-worm --key backup-2026-08-02.tar.gz
# "ObjectLockMode": "COMPLIANCE",
# "ObjectLockRetainUntilDate": "...",

# próba trwałego usunięcia chronionej wersji
aws s3api delete-object --bucket backup-worm \
  --key backup-2026-08-02.tar.gz --version-id "<id-wersji>"
# → AccessDenied — i właśnie o to chodzi

A co ze zwykłym aws s3 rm, bez wskazywania wersji? Zadziała „pomyślnie” – i to nie jest dziura w ochronie:

aws s3 rm s3://backup-worm/backup-2026-08-02.tar.gz
# sukces — ale to tylko znacznik usunięcia z sekcji o wersjonowaniu!

aws s3api list-object-versions --bucket backup-worm
# chroniona wersja wciąż istnieje pod znacznikiem — dane są nietknięte

Plik zniknął z listingu, ale nie z magazynu; przywrócenie to usunięcie znacznika lub pobranie wersji po jej identyfikatorze.

Ochronę pojedynczej wersji można też ustawić jawnie przy zapisie (tak ustawiona data ma pierwszeństwo przed domyślną retencją bucketa) albo później – pamiętając, że w trybie Compliance ruch jest możliwy tylko w jedną stronę:

# jawna blokada przy zapisie (do ćwiczeń: data dzień naprzód;
# w produkcji np. rok: 2027-08-02)
aws s3api put-object --bucket backup-worm --key raport-roczny.pdf \
  --body raport-roczny.pdf \
  --object-lock-mode COMPLIANCE \
  --object-lock-retain-until-date "2026-08-03T00:00:00Z"

# wydłużenie ochrony istniejącej wersji (skrócenie → odmowa)
aws s3api put-object-retention --bucket backup-worm --key raport-roczny.pdf \
  --version-id "<id-wersji>" \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2026-08-04T00:00:00Z"}'

# legal hold: wstrzymaj do odwołania (niezależnie od dat retencji)
aws s3api put-object-legal-hold --bucket backup-worm --key raport-roczny.pdf \
  --legal-hold '{"Status":"ON"}'

Retencja to nie tylko blokowanie – to też sprzątanie

Polityka retencji ma dwie strony. Pierwsza mówi: „nie wolno usunąć przed upływem terminu”. Druga – równie ważna – mówi: „po upływie terminu usuń automatycznie”. Tę drugą realizują reguły lifecycle magazynu. W parze z Object Lock daje to samoczyszczący się magazyn WORM: kopie są nietykalne przez okres ochrony, a po jego upływie znikają same – bez skryptów, bez crona, bez ręcznego przeglądania. Reguła lifecycle uszanuje przy tym aktywną blokadę: wersja chroniona nie zostanie usunięta przed swoją datą retencji.

Domykając przykład z poprzedniej sekcji – sprzątanie wersji dopasowane do 90-dniowej retencji produkcyjnej:

aws s3api put-bucket-lifecycle-configuration --bucket backup-worm \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "sprzataj-po-ochronie",
      "Status": "Enabled",
      "Filter": {},
      "Expiration": { "Days": 90 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 90 }
    }]
  }'

Dobrze ustawiona retencja to zawsze kompromis: zbyt krótka nie obroni przed napastnikiem, który cierpliwie czeka (włamanie następuje nieraz na długo przed szyfrowaniem); zbyt długa mnoży koszty przechowywania i może kolidować z obowiązkami usuwania danych (o tym w FAQ). Dla kopii zapasowych rozsądnym minimum ochrony nienaruszalnej jest ok. 90 dni – plus dłuższe, rzadsze kopie archiwalne.

Uczciwy bilans: czego Object Lock nie załatwi

• Compliance znaczy Compliance. Pomyłka działa w obie strony: jeśli zablokujesz 10 TB śmieci na 7 lat, będziesz je przechowywać (i opłacać) przez 7 lat. Nie ma przycisku „skasuj wyjątkowo” – wyjątki od nieusuwalności ograniczają się do ściśle regulowanych sytuacji opisanych w regulaminie usługi. Retencję ustawia się z rozmysłem, a testy robi na krótkich okresach.
• Wersje kosztują. Magazyn z wersjonowaniem i retencją przechowuje wszystko, co zapisano w okresie ochrony – także wersje „nadpisane” przez ransomware. To cena gwarancji; budżetując backup WORM, licz: pojemność × liczba kopii w oknie retencji.
• Blokada chroni integralność, nie poufność. Napastnik z dostępem nadal może dane odczytać i wykraść. Przed tym chronią szyfrowanie (pisaliśmy o SSE w tym cyklu), kontrola dostępu i krótkotrwałe poświadczenia (pisaliśmy o STS).
• WORM nie zastępuje zasad backupu. Niezmienialna kopia w jednym magazynie to wciąż jedna kopia. Reguła 3-2-1 (trzy kopie, dwa nośniki, jedna poza lokalizacją) obowiązuje nadal – Object Lock utwardza jedno z jej ogniw.
• Nowe zapisy nie są blokowane. Object Lock unieruchamia istniejące wersje; nie powstrzyma nikogo przed dosypywaniem nowych obiektów do bucketa. Limity, kwoty i monitoring zapisów to osobna warstwa.

Anty-Ransomware w WebDisk Files

W WebDisk Files cały opisany mechanizm jest opakowany w jedną funkcję o jednoznacznej nazwie: Anty-Ransomware. Działa na poziomie dodatkowego magazynu (bucketa) i włącza się przełącznikiem – z okresem ochrony od 90 dni do 7 lat (minimum to świadomie 90 dni: włamania poprzedzają szyfrowanie tygodniami, krótsza ochrona bywa iluzją):

• Pod maską to po prostu S3 Object Lock w trybie Compliance: każda wersja każdego pliku w magazynie jest niemodyfikowalna i nieusuwalna do upływu okresu ochrony. Gwarancję egzekwuje warstwa magazynu, a nie aplikacja – pozostaje w mocy nawet przy kompromitacji samej aplikacji czy konta administratora organizacji. Właśnie o taki model chodzi w obronie przed ransomware.
• Decyzja jest jednokierunkowa – i mówimy o tym wprost: magazynu z włączonym Anty-Ransomware nie da się „odblokować” ani skrócić okresu ochrony jego zawartości. Nie da się też usunąć magazynu, dopóki chroni jakiekolwiek wersje. To nie jest ograniczenie, które staramy się obejść – to jest istota produktu.
• Do pary dostępna jest auto-rotacja: reguła retencji, która po upływie zadanego okresu trwale usuwa stare obiekty – realizowana politykami lifecycle po stronie magazynu, bez żadnego crona po stronie aplikacji. Na magazynie z Anty-Ransomware okres rotacji jest równy okresowi ochrony (pliki znikają równo z końcem zabezpieczenia); na zwykłym magazynie okres wybierasz sam. W połączeniu daje to wspomniany samoczyszczący się magazyn WORM.
• Funkcja przeszła ocenę skutków dla ochrony danych (DPIA, RODO art. 35) — bo nieusuwalność danych musi być pogodzona z prawem do ich usunięcia; okres ochrony dobiera się więc świadomie do charakteru danych. Dokument udostępniamy klientom B2B na życzenie – jako wsad do ich własnych ocen skutków.

Scenariusz użycia, dla którego to zbudowaliśmy, jest prosty: bezpieczny cel backupu klasy WORM. Wskaż magazyn Anty-Ransomware jako cel kopii zapasowych — przez S3 (dowolne narzędzie backupowe piszące do S3 – ochronę nakłada domyślna retencja bucketa, więc narzędzie nie musi w ogóle wiedzieć o Object Lock), przez aplikację webową albo desktopową. Każda kopia, którą zapiszesz, staje się nietykalna automatycznie. Kopie zapasowe kluczowych elementów naszej własnej platformy również trzymamy w magazynach WORM z S3 Object Lock.

Uwaga dla użytkowników narzędzi z natywną obsługą Object Lock (np. Veeam): takie oprogramowanie samo zarządza retencją per obiekt i zgodnie z wymaganiami producenta potrzebuje bucketa z włączonym Object Lock, ale bez domyślnej retencji i bez reguł lifecycle – dokumentacja integracji ostrzega, że domyślne blokady na buckecie mogą prowadzić do nieprzewidywalnej utraty danych. Magazyn Anty-Ransomware (z wymuszoną retencją Compliance i auto-rotacją) jest zaprojektowany dla narzędzi, które o Object Lock nie wiedzą; dla Veeam i podobnych potrzebny jest osobno skonfigurowany bucket zgodny z wytycznymi producenta – napisz do nas, pomożemy.

Warstwy uzupełniające w Files znasz już z poprzednich artykułów cyklu: wersjonowanie plików, szyfrowanie w spoczynku (SSE-S3 per magazyn, SSE-C per organizacja) i kontrola dostępu. Object Lock domyka ten zestaw od strony integralności: nawet jeśli wszystko inne zawiedzie, kopia sprzed ataku istnieje i da się z niej wrócić.

Częste pytania

Czy mogę poprosić WebDisk o usunięcie pliku z magazynu Anty-Ransomware przed upływem ochrony? Żadną operacją S3, przez panel ani „od ręki” – nie. Blokadę egzekwuje warstwa magazynu i nie zdejmie jej ani administrator Twojej organizacji, ani napastnik z przejętymi kluczami, ani nasz support. Wyjątki ograniczają się do ściśle regulowanych, audytowanych sytuacji przewidzianych w regulaminie usługi – takich jak realizacja obowiązków prawnych – i nie da się ich uruchomić cicho, zdalnie ani skompromitowanymi kluczami S3. Dla scenariusza ransomware oznacza to brak furtki.

Pomyliłem się i zablokowałem dane na za długo. Co teraz? W warstwie S3 – nic; dane pozostaną do upływu retencji. Dlatego: nowe polityki testuj na krótkich okresach i osobnym buckecie, retencję domyślną ustawiaj ostrożnie, a bardzo długie okresy rezerwuj dla danych, co do których masz pewność. Tryb Governance istnieje właśnie po to, by procesy dotrzeć, zanim przełączysz się na Compliance.

Czy ransomware może zaszyfrować pliki w magazynie z Object Lock? Może co najwyżej dopisać zaszyfrowane wersje obok chronionych – oryginały pozostaną nietknięte i odtwarzalne. Nie może ich nadpisać w miejscu ani usunąć. Odtworzenie sprowadza się do przywrócenia wersji sprzed ataku.

Czy Object Lock da się włączyć na istniejącym buckecie? To zależy od platformy i wersji: AWS pozwala doposażyć istniejący bucket, w Ceph RGW umożliwiają to dopiero najnowsze wydania – w tym zakresie liczy się wersja, na której działa Twój dostawca. W Files rozwiązujemy to wprost: Anty-Ransomware włączasz przy zakładaniu magazynu (może to być też istniejący, pusty magazyn); dla magazynu z danymi tworzysz nowy chroniony i kopiujesz je do niego.

Co się stanie z magazynem Anty-Ransomware, gdy zamknę konto? Ochrona nie znika wraz z kontem: magazynu nie da się usunąć, dopóki chroni jakiekolwiek wersje, więc jego skasowanie jest planowane i wykonuje się dopiero po wygaśnięciu okresu ochrony. Zasady rozliczeń w tym okresie znajdziesz w regulaminie usługi – uwzględnij okres ochrony w decyzji o jego długości.

Jak WORM godzi się z RODO i prawem do usunięcia danych? Świadomym doborem zakresu i okresu. Do magazynu WORM trafiają kopie zapasowe i archiwa, nie codzienny obieg danych osobowych; okres ochrony dobiera się tak, by bilansował ryzyko ransomware z obowiązkami usuwania. W Files funkcja przeszła DPIA (RODO art. 35) właśnie po to, by ten bilans był udokumentowany – a skrajne przypadki, jak realizacja obowiązków prawnych, obsługiwane są w trybie przewidzianym regulaminem usługi.

Governance czy Compliance – od czego zacząć? Jeśli dopiero układasz proces backupu: Governance na czas dotarcia procedur (chroni przed pomyłką, pozwala posprzątać), potem Compliance na produkcyjne kopie. Jeśli celem jest obrona przed ransomware albo wymóg prawny – docelowo zawsze Compliance; furtka Governance jest dokładnie tym, co przejęte konto uprzywilejowane może wykorzystać.

Podsumowanie

Object Lock odwraca zwykłą logikę uprawnień: zamiast pilnować, kto może usuwać dane, sprawia, że przez zadany czas nie może nikt – żadnym żądaniem S3. Trzy rzeczy warto zapamiętać:

• fundamentem jest wersjonowanie – blokada chroni wersje, więc „nadpisane” przez napastnika pliki mają nietknięte oryginały,
• Compliance to gwarancja bez furtki w warstwie S3, nieodwołalna także dla naszego supportu – dlatego retencję dobiera się z rozmysłem, a sprzątaniem zajmują się reguły lifecycle,
• WORM chroni integralność i odtwarzalność; poufność i dostęp to zadanie szyfrowania (SSE) i krótkotrwałych poświadczeń (STS) z poprzednich części cyklu.

W WebDisk Files znajdziesz to jako Anty-Ransomware: magazyn WORM na kopie zapasowe, uruchamiany jednym przełącznikiem, z ochroną od 90 dni do 7 lat i — opcjonalnie – automatycznym sprzątaniem po jej upływie. Przetestuj WebDisk Files albo napisz do nas, jeśli chcesz przegadać architekturę backupu odpornego na ransomware w swojej organizacji.

Artykuł jest częścią cyklu o bezpieczeństwie danych w usługach WebDisk — wcześniej ukazały się teksty o szyfrowaniu w spoczynku (SSE-S3, SSE-KMS, SSE-C) i o dostępie przez STS/SSO. Przykłady wykonasz na dowolnej platformie S3 z obsługą Object Lock; parametr --endpoint-url w aws CLI wskazuje endpoint Twojego dostawcy.