S3 Object Lock: копія, яку неможливо видалити – WORM, ретенція та Anty-Ransomware

Блог WebDisk · категорія: Безпека · час читання: ~12 хвилин

Коротко:- S3 Object Lock перетворює об’єктне сховище на WORM (write once, read many): записаний файл можна читати, але протягом заданого періоду жоден запит S3 – зокрема надісланий адміністратором чи власником облікового запису – не змінить його й не видалить.- Це сьогодні базовий захист резервних копій від ransomware, яке зазвичай видаляє бекапи, перш ніж зашифрувати продакшн.- У WebDisk Files цей механізм називається Anty-Ransomware: ви вмикаєте його перемикачем на сховищі й маєте сховище класу WORM для резервних копій. >Не працюєте з терміналом? Пропустіть приклади коду – опис механізму та розділ про WebDisk дають повну картину.

Сучасна атака ransomware рідко починається з шифрування. Зловмисник, який здобув доступ до інфраструктури, спершу проводить у ній дні або тижні – і за цей час методично шукає резервні копії. Видаляє їх, шифрує або тихо псує. Аж тоді, коли жертві немає до чого повертатися, він запускає власне шифрування й висуває вимогу викупу. Логіка брутально проста: компанія, яка має справний бекап, не заплатить.

Висновок із тисяч таких інцидентів звучить так: резервна копія, яку можна видалити тими самими правами, якими її записано, не є захистом – вона є ілюзією захисту. Потрібна копія, якої не зітре ані зловмисник із викраденими ключами, ані помилковий скрипт, ані – що найважче прийняти – ми самі в поганий день. У світі S3 саме це робить Object Lock. У цій статті пояснюємо, як він працює, показуємо приклади використання й описуємо, як ми побудували на ньому функцію Anty-Ransomware у WebDisk Files.

WORM: ідея, старша за хмару

WORM (write once, read many – «запиши раз, читай багато разів») – це концепція, відома вже десятиліття. Найзвичніший приклад – диск CD-R: записаний один раз вміст можна читати скільки завгодно, але його не вдасться перезаписати чи стерти – фізика носія просто цього не дозволяє. Банки й архіви роками використовують носії та масиви WORM там, де закон вимагає, щоб запис лишався недоторканим: реєстри транзакцій, медична документація, кореспонденція, що підлягає нагляду.

S3 Object Lock переносить цю гарантію в об’єктне сховище – без спеціального обладнання. Блокування виконує сам шар сховища: запит на видалення або перезапис захищеної версії об’єкта відхиляється, незалежно від того, хто і з якими правами його надіслав. Це ключова відмінність від звичайних прав доступу (політик IAM): політику може змінити той, хто має відповідний доступ – а блокування WORM у режимі Compliance не зніме жоден запит S3.

Фундамент: версіонування

Object Lock не працює у вакуумі – він вимагає версіонування бакета (bucket – контейнер для файлів у сховищі S3, відповідник диска чи мережевого ресурсу; у послугах WebDisk ми називаємо його сховищем). Версіонування робить так, що сховище ніколи нічого не перезаписує на місці: кожен запис під наявним іменем створює нову версію об’єкта, а попередні залишаються. «Видалення» файлу у версіонованому бакеті теж не стирає даних – воно лише додає маркер видалення (delete marker), з-під якого старіші версії можна будь-коли дістати.

Лише на цьому фундаменті блокування має сенс, бо Object Lock захищає конкретні версії об’єктів. Практичний наслідок, який варто зрозуміти: запис нового вмісту під тим самим іменем не блокується – просто виникає чергова версія. Захищена версія лежить недоторканою поруч. Наочно:

файл «raport.pdf» у бакеті з Object Lock:

  [маркер видалення] ← файл «зник» зі списку…
  v2 запис ransomware ← …«перезаписане» сміття опинилося ПОРУЧ, а не замість
  v1 🔒 Compliance до 1.11 ← оригінал: недоторканний, готовий до відновлення

Отже, ransomware може «перезаписати» ваші файли зашифрованим сміттям і «видалити» їх зі списку, але оригінальні, заблоковані версії вціліють – і до них можна буде повернутися.

Два режими та два механізми блокування

Заблокувати версію можна двома способами й у двох режимах – і ці розрізнення є найважливішою технічною частиною цієї статті.

Ретенція (retention) – строкове блокування: версія має дату retain-until-date, до настання якої її не можна видалити ані змінити. Дату можна задати явно під час запису об’єкта або налаштувати типову ретенцію бакета (напр. «кожен новий об’єкт: 90 днів») – тоді захист охоплює все автоматично, без співпраці з боку інструмента, який пише дані.

Режими ретенції:

• Governance – блокування з лазівкою: звичайні користувачі не можуть нічого зробити, але визначені користувачі зі спеціальним правом (s3:BypassGovernanceRetention) можуть блокування скоротити або зняти. Добре для впорядкування процесів і на час тестів: захищає від помилки, не захищає від зловмисника, який захопить привілейований обліковий запис.
• Compliance – блокування без лазівки на рівні S3: до спливу дати ретенції версію не видалить жоден запит S3 – незалежно від того, чи надішле його власник облікового запису, адміністратор організації, чи зловмисник із захопленим привілейованим обліковим записом. Період можна виключно подовжити, ніколи скоротити. Це режим, придатний для захисту від ransomware і для юридичних вимог. (Поза шаром S3 у кожного постачальника лишається щонайбільше суворо контрольована, аудитована операторська процедура – як це виглядає в нас, чесно описуємо у FAQ.)
• Legal hold – безстрокове блокування, незалежне від ретенції: перемикач «зупини все до відкликання» на окремій версії. Немає дати завершення; знімає його свідоме рішення особи з відповідним правом. Використовується, коли триває судовий спір або розслідування й даних не можна чіпати, доки справа не завершиться.
• Тривалість – Governance: до дати ретенції · Compliance: до дати ретенції · Legal hold: до відкликання
• Чи можна скоротити/зняти? – Governance: так, зі спеціальним правом · Compliance: ні – жодним запитом S3 · Legal hold: так, правом legal hold
• Чи можна подовжити? – Governance: так · Compliance: так (лише подовжити) · Legal hold: не стосується
• Типове застосування – Governance: внутрішні процеси, тести · Compliance: ransomware, юридичні вимоги · Legal hold: судові спори, розслідування

Зробіть самі: WORM у терміналі

Перш ніж почати. Приклади використовують aws CLI, налаштований як у попередніх статтях циклу (aws configure + --endpoint-url вашого постачальника – нижче ми його опускаємо для читабельності). Обережно зі справжніми даними: блокувань Compliance не можна скасувати – тому всі вправи нижче використовують ретенцію 1 дня і тестовий бакет; продакшн-значення показуємо в коментарях.

Object Lock вмикається під час створення бакета (про доопрацювання наявного – у FAQ):

# 1. бакет з увімкненим Object Lock (версіонування вмикається автоматично)
aws s3api create-bucket --bucket backup-worm \
  --object-lock-enabled-for-bucket

# 2. типова ретенція Compliance – УВАГА: цей крок є незворотним за наслідками,
# кожен новий об’єкт буде недоторканним протягом заданого періоду
aws s3api put-object-lock-configuration --bucket backup-worm \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":1}}}'
# для вправ: 1 день · у продакшні для бекапів: {"Mode":"COMPLIANCE","Days":90}

# 3. звичайний upload – захист накладається сам, інструмент резервного копіювання
# не мусить нічого знати про Object Lock
aws s3 cp backup-2026-08-02.tar.gz s3://backup-worm/

Від цієї миті кожна записана версія є недоторканною протягом заданого періоду. Перевірмо:

# метадані версії: режим блокування та дата, до якої воно діє
aws s3api head-object --bucket backup-worm --key backup-2026-08-02.tar.gz
# "ObjectLockMode": "COMPLIANCE",
# "ObjectLockRetainUntilDate": "...",

# спроба остаточно видалити захищену версію
aws s3api delete-object --bucket backup-worm \
  --key backup-2026-08-02.tar.gz --version-id "<id-wersji>"
# → AccessDenied – саме про це й ідеться

А що зі звичайним aws s3 rm, без зазначення версії? Він відпрацює «успішно» – і це не діра в захисті:

aws s3 rm s3://backup-worm/backup-2026-08-02.tar.gz
# успіх – але це лише маркер видалення з розділу про версіонування!

aws s3api list-object-versions --bucket backup-worm
# захищена версія все ще існує під маркером – дані недоторкані

Файл зник зі списку, але не зі сховища; відновлення – це видалення маркера або завантаження версії за її ідентифікатором.

Захист окремої версії можна також задати явно під час запису (задана так дата має пріоритет над типовою ретенцією бакета) або пізніше – пам’ятаючи, що в режимі Compliance рух можливий лише в один бік:

# явне блокування під час запису (для вправ: дата на день уперед;
# у продакшні напр. рік: 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"

# подовження захисту наявної версії (скорочення → відмова)
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: зупини до відкликання (незалежно від дат ретенції)
aws s3api put-object-legal-hold --bucket backup-worm --key raport-roczny.pdf \
  --legal-hold '{"Status":"ON"}'

Ретенція – це не лише блокування, а й прибирання

Політика ретенції має два боки. Перший каже: «не можна видаляти до спливу терміну». Другий – не менш важливий – каже: «після спливу терміну видали автоматично». Другий реалізують правила lifecycle сховища. У парі з Object Lock це дає самоочисне сховище WORM: копії недоторканні протягом періоду захисту, а після його спливу зникають самі – без скриптів, без cron, без ручного перегляду. Правило lifecycle при цьому поважає активне блокування: захищена версія не буде видалена до своєї дати ретенції.

Замикаючи приклад із попереднього розділу – прибирання версій, узгоджене з 90-денною продакшн-ретенцією:

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 }
    }]
  }'

Добре налаштована ретенція – це завжди компроміс: надто коротка не захистить від зловмисника, який терпляче чекає (злам нерідко стається задовго до шифрування); надто довга множить витрати на зберігання й може конфліктувати з обов’язками видалення даних (про це у FAQ). Для резервних копій розумним мінімумом непорушного захисту є близько 90 днів – плюс довші, рідші архівні копії.

Чесний баланс: чого Object Lock не вирішить

• Compliance означає Compliance. Помилка діє в обидва боки: якщо заблокуєте 10 ТБ сміття на 7 років, зберігатимете (і оплачуватимете) його 7 років. Немає кнопки «видали як виняток» – винятки з невидаленості обмежуються суворо регульованими ситуаціями, описаними в регламенті послуги. Ретенцію встановлюють розважливо, а тести роблять на коротких періодах.
• Версії коштують. Сховище з версіонуванням і ретенцією зберігає все, що записано в періоді захисту – зокрема версії, «перезаписані» ransomware. Це ціна гарантії; плануючи бюджет на бекап WORM, рахуйте: обсяг × кількість копій у вікні ретенції.
• Блокування захищає цілісність, а не конфіденційність. Зловмисник із доступом усе ще може дані прочитати й викрасти. Від цього захищають шифрування (ми писали про SSE в цьому циклі), контроль доступу та короткочасні облікові дані (ми писали про STS).
• WORM не замінює правил резервного копіювання. Незмінна копія в одному сховищі – це все одно одна копія. Правило 3-2-1 (три копії, два носії, одна поза локацією) діє й надалі – Object Lock зміцнює одну з його ланок.
• Нові записи не блокуються. Object Lock знерухомлює наявні версії; він не завадить нікому досипати нові об’єкти в бакет. Ліміти, квоти й моніторинг записів – це окремий шар.

Anty-Ransomware у WebDisk Files

У WebDisk Files увесь описаний механізм загорнуто в одну функцію з однозначною назвою: Anty-Ransomware. Вона працює на рівні додаткового сховища (бакета) і вмикається перемикачем – з періодом захисту від 90 днів до 7 років (мінімум у 90 днів обрано свідомо: зломи випереджають шифрування на тижні, коротший захист буває ілюзією):

• Під капотом це просто S3 Object Lock у режимі Compliance: кожна версія кожного файлу у сховищі не піддається зміні та видаленню до спливу періоду захисту. Гарантію виконує шар сховища, а не застосунок – вона лишається чинною навіть при компрометації самого застосунку чи облікового запису адміністратора організації. Саме про таку модель ідеться в захисті від ransomware.
• Рішення є одностороннім – і ми говоримо про це прямо: сховище з увімкненим Anty-Ransomware не можна «розблокувати» ані скоротити період захисту його вмісту. Не можна також видалити сховище, доки воно захищає будь-які версії. Це не обмеження, яке ми намагаємося обійти – це суть продукту.
• До пари доступна автоматична ротація: правило ретенції, яке після спливу заданого періоду остаточно видаляє старі об’єкти – реалізоване політиками lifecycle на боці сховища, без жодного cron на боці застосунку. У сховищі з Anty-Ransomware період ротації дорівнює періоду захисту (файли зникають рівно із закінченням захисту); у звичайному сховищі період обираєте самі. У поєднанні це дає згадане самоочисне сховище WORM.
• Функція пройшла оцінку впливу на захист даних (DPIA, GDPR ст. 35) – бо неможливість видалення даних треба узгодити з правом на їх видалення; тому період захисту свідомо добирають до характеру даних. Документ надаємо клієнтам B2B на запит – як вхідні дані до їхніх власних оцінок впливу.

Сценарій використання, задля якого ми це побудували, простий: безпечна ціль резервного копіювання класу WORM. Вкажіть сховище Anty-Ransomware як ціль резервних копій – через S3 (будь-який інструмент резервного копіювання, що пише в S3 – захист накладає типова ретенція бакета, тож інструмент взагалі не мусить знати про Object Lock), через вебзастосунок або десктопний застосунок. Кожна копія, яку ви запишете, стає недоторканною автоматично. Резервні копії ключових елементів нашої власної платформи ми також тримаємо у сховищах WORM із S3 Object Lock.

Увага для користувачів інструментів із власною підтримкою Object Lock (напр. Veeam): таке програмне забезпечення саме керує ретенцією для кожного об’єкта і, відповідно до вимог виробника, потребує бакета з увімкненим Object Lock, але без типової ретенції та без правил lifecycle – документація інтеграції попереджає, що типові блокування на бакеті можуть призводити до непередбачуваної втрати даних. Сховище Anty-Ransomware (з примусовою ретенцією Compliance та автоматичною ротацією) спроєктоване для інструментів, які про Object Lock не знають; для Veeam і подібних потрібен окремо налаштований бакет, узгоджений із вказівками виробника – напишіть нам, допоможемо.

Додаткові шари у Files ви вже знаєте з попередніх статей циклу: версіонування файлів, шифрування в спокої (SSE-S3 на сховище, SSE-C на організацію) і контроль доступу. Object Lock замикає цей набір з боку цілісності: навіть якщо все інше підведе, копія з часу перед атакою існує і з неї можна повернутися.

Часті запитання

Чи можу я попросити WebDisk видалити файл зі сховища Anty-Ransomware до спливу захисту? Жодною операцією S3, через панель чи «одразу» – ні. Блокування виконує шар сховища, і його не зніме ані адміністратор вашої організації, ані зловмисник із викраденими ключами, ані наша підтримка. Винятки обмежуються суворо регульованими, аудитованими ситуаціями, передбаченими в регламенті послуги – такими як виконання юридичних обов’язків – і їх не можна запустити тихо, віддалено чи скомпрометованими ключами S3. Для сценарію ransomware це означає відсутність лазівки.

Я помилився й заблокував дані на надто довго. Що тепер? На рівні S3 – нічого; дані залишаться до спливу ретенції. Тому: нові політики тестуйте на коротких періодах і окремому бакеті, типову ретенцію встановлюйте обережно, а дуже довгі періоди резервуйте для даних, щодо яких ви впевнені. Режим Governance існує саме для того, щоб довести процеси до ладу, перш ніж перемкнутися на Compliance.

Чи може ransomware зашифрувати файли у сховищі з Object Lock? Воно може щонайбільше дописати зашифровані версії поруч із захищеними – оригінали залишаться недоторканими й придатними до відновлення. Воно не може перезаписати їх на місці ані видалити. Відновлення зводиться до повернення версії з часу перед атакою.

Чи можна ввімкнути Object Lock на наявному бакеті? Це залежить від платформи та версії: AWS дозволяє доопрацювати наявний бакет, у Ceph RGW це уможливлюють лише найновіші випуски – у цьому питанні важить версія, на якій працює ваш постачальник. У Files ми вирішуємо це прямо: Anty-Ransomware вмикається під час створення сховища (це може бути й наявне, порожнє сховище); для сховища з даними ви створюєте нове захищене й копіюєте їх до нього.

Що станеться зі сховищем Anty-Ransomware, коли я закрию обліковий запис? Захист не зникає разом з обліковим записом: сховище не можна видалити, доки воно захищає будь-які версії, тож його видалення планується й виконується аж після завершення періоду захисту. Правила розрахунків у цей період знайдете в регламенті послуги – врахуйте період захисту в рішенні щодо його тривалості.

Як WORM узгоджується з GDPR і правом на видалення даних? Свідомим добором обсягу й періоду. До сховища WORM потрапляють резервні копії та архіви, а не щоденний обіг персональних даних; період захисту добирають так, щоб він балансував ризик ransomware з обов’язками видалення. У Files функція пройшла DPIA (GDPR ст. 35) саме для того, щоб цей баланс був задокументований – а крайні випадки, як-от виконання юридичних обов’язків, обслуговуються в порядку, передбаченому регламентом послуги.

Governance чи Compliance – з чого почати? Якщо ви лише вибудовуєте процес резервного копіювання: Governance на час доведення процедур (захищає від помилки, дозволяє прибрати), потім Compliance для продакшн-копій. Якщо метою є захист від ransomware або юридична вимога – у підсумку завжди Compliance; лазівка Governance – це саме те, чим може скористатися захоплений привілейований обліковий запис.

Підсумок

Object Lock перевертає звичайну логіку прав доступу: замість стежити за тим, хто може видаляти дані, він робить так, що протягом заданого часу не може ніхто – жодним запитом S3. Три речі варто запам’ятати:

• фундаментом є версіонування – блокування захищає версії, тож «перезаписані» зловмисником файли мають недоторкані оригінали,
• Compliance – це гарантія без лазівки на рівні S3, невідклична також для нашої підтримки – тому ретенцію добирають розважливо, а прибиранням займаються правила lifecycle,
• WORM захищає цілісність і відновлюваність; конфіденційність і доступ – це завдання шифрування (SSE) та короткочасних облікових даних (STS) з попередніх частин циклу.

У WebDisk Files ви знайдете це як Anty-Ransomware: сховище WORM для резервних копій, що вмикається одним перемикачем, із захистом від 90 днів до 7 років і – опційно – автоматичним прибиранням після його спливу. Протестуйте WebDisk Files або напишіть нам, якщо хочете обговорити архітектуру резервного копіювання, стійкого до ransomware, у вашій організації.

Стаття є частиною циклу про безпеку даних у послугах WebDisk – раніше вийшли тексти про шифрування в спокої (SSE-S3, SSE-KMS, SSE-C) і про доступ через STS/SSO. Приклади ви виконаєте на будь-якій платформі S3 з підтримкою Object Lock; параметр --endpoint-url у aws CLI вказує на endpoint вашого постачальника.