S3 Object Lock для резервных копий: режимы Governance и Compliance, legal hold и защита от ransomware

S3 Object Lock, механизм WORM (write once, read many) в Amazon S3, запрещает удалять или перезаписывать конкретную версию объекта, пока не истёк retention period или пока не снят legal hold. Retention можно задать при загрузке или отдельным запросом к версии. В Compliance срок нельзя сократить даже root; в Governance предусмотрен авторизованный bypass. Legal hold независим от retention и снимается обладателем соответствующего права.

Для резервных копий это критично. Ransomware и скомпрометированные учётные записи атакуют бэкапы первыми: их удаляют, перезаписывают шифрованными данными, затирают версии, чтобы лишить компанию возможности восстановиться. Object Lock переносит защиту на сторону хранилища: возможность удаления защищённой версии зависит от режима, retention, legal hold и прав учётной записи.

Границы возможностей стоит понимать сразу. Object Lock работает только на бакетах с включённым versioning, включается на бакете и обратно не отключается, не позволяет удалить непустой бакет, включая защищённые версии, даже обычным запросом root и не заменяет офлайн-копию и проверку восстановления. Это слой защиты, а не абсолютная гарантия.

Что такое S3 Object Lock и зачем он нужен резервным копиям

Object Lock удерживает объект в неизменяемом состоянии через API S3: право s3:PutObjectRetention задаёт срок, право s3:PutObjectLegalHold включает и снимает удержание. Настройки живут на уровне отдельной версии объекта, поэтому в одном бакете спокойно соседствуют версии с разными сроками и разными статусами удержания.

Бакет с Object Lock создают либо включают блокировку сразу после активации versioning. Отключить её потом нельзя, и это ключевое отличие от большинства настроек S3: решение принимается один раз. Официальное описание механизма приведено в документации AWS по Object Lock.

WORM-модель и чем она отличается от обычного бэкапа в S3

Без версионирования обычный объект в S3 может быть потерян при DELETE или перезаписи. Скрипт бэкапа загружает daily-backup.tar.gz каждый день, и учётка с правом s3:DeleteObject стирает вчерашнюю копию за секунды. Ошибка в кроне, испорченный скрипт, украденный ключ, и данных больше нет.

Под Object Lock каждая загрузка создаёт новую версию, и у каждой версии свой срок неизменяемости. Дневной бэкап с retention 30 дней означает: 30 дней эту версию нельзя удалить и нельзя перезаписать. Блокировка привязана к object version ID, а не к бакету целиком, поэтому продление срока или отдельные условия для архива настраиваются точечно.

Что Object Lock не защищает

• Компрометация аккаунта и ключей шифрования. Object Lock не обеспечивает доступность аккаунта или ключа KMS и не запрещает чтение разрешённой учётке. Удаление непустого бакета не является обходом защиты версий.
• Обход в Governance. Если у атакующего есть необходимые права, включая s3:BypassGovernanceRetention, и запрос явно указывает bypass, он может обойти Governance retention. Legal hold этим не снимается.
• Рост расходов. Каждая версия хранится и тарифицируется. Чем длиннее retention, тем выше счёт.
• Отсутствие офлайн-копии и проверки восстановления. Object Lock не подменяет ни одну из этих практик.

Режимы S3 Object Lock: Governance и Compliance

Режим и срок задаются конкретной версии. На бакете можно настроить изменяемые defaults для новых объектов; изменение defaults не меняет уже защищённые версии. Режим версии определяет, кто может снять или укоротить retention. Пока retention на версии не установлен, она удаляется обычным DELETE с version ID, поэтому сам факт включённого Object Lock защищает меньше, чем ожидают.

Governance mode: гибкость с контролем

В Governance для обхода retention нужны соответствующие права, включая s3:BypassGovernanceRetention, и явный bypass в запросе. Само наличие права не снимает защиту автоматически; legal hold действует независимо. Для эксплуатации это удобно: ошибочный скрипт залил мусор, дежурный инженер с нужной ролью удаляет версию, не дожидаясь конца срока. То же право позволяет удалить объект, защищённый Governance, даже в течение срока хранения, в том числе через AWS CLI с параметром --bypass-governance-retention.

Право s3:BypassGovernanceRetention закрепляют за отдельной ролью break-glass, доступ к которой защищён MFA и выдаётся на время. У бэкап-учётки такого права нет. Аварийное снятие блокировки стоит логировать и отслеживать: настраивайте аудит вызовов, меняющих retention, чтобы у каждого такого действия оставался инициатор и время.

Слабое место Governance: роль с bypass и нужными правами может обойти Governance retention, но не активный legal hold или Compliance retention. Если злоумышленник получил необходимые права и в запросе указал bypass, Governance retention сам по себе не помешает удалению версии; legal hold проверяется отдельно.

Compliance mode: неизменяемость без исключений

В Compliance блокировку не отменяет никто до конца срока: ни администратор, ни root-аккаунт. Чтобы окончательно удалить такой объект, нужно дождаться окончания срока хранения или удалить связанный аккаунт AWS. Сократить retention period нельзя, срок только увеличивают. Любое lifecycle-правило, которое попытается убрать такой объект раньше срока, тоже не сработает.

Обратная сторона, необратимость. Retention 3650 дней, выставленный по ошибке вместо 30, означает десять лет оплаты хранения каждого объекта. Проверку режима делают на отдельном бакете с тестовыми данными, а не на проде.

Compliance закрывает сценарии, где нужна юридическая неизменяемость записей. S3 Object Lock был оценён Cohasset Associates для использования в средах, подпадающих под регулирование SEC 17a-4, CFTC и FINRA. При этом настройка бакета сама по себе соответствие не подтверждает: итоговый вывод делают аудитор и юристы по вашим процессам, а не по режиму Object Lock. Не выводи соответствие другим требованиям только из названия режима Compliance: проверяй конкретную нормативную задачу с ответственными специалистами.

Legal hold: удержание без срока

Legal hold это флаг ON/OFF на конкретной версии объекта. Срока у него нет: пока флаг включён, версию не удалить, даже если retention period давно истёк. Снимают его только явным вызовом API с правом s3:PutObjectLegalHold.

Retention может применяться через default retention бакета или явно задаваться бэкап-процессом для каждой версии. Legal hold включают вручную или отдельным процессом, когда объекту нужен бессрочный запрет на удаление: судебный запрос, расследование инцидента, внутренний аудит, разбор доступа уволенного сотрудника к данным.

Забытый legal hold превращается в вечное хранение и растущий счёт: версия с флагом не удаляется ни lifecycle-правилом, ни ручной командой. Держите реестр объектов под legal hold и сверяйте его при закрытии дела.

Versioning и Object Lock: как они работают вместе

Object Lock работает только в бакетах с включённым S3 Versioning. При включении блокировки версионирование включается автоматически, а отключить блокировку объектов, как и версионирование, после этого невозможно. Retention задаётся на конкретный object version ID, поэтому срок одного дня и срок в год уживаются в одном бакете без конфликтов.

Скрипт заливает backup.tar.gz ежедневно, каждая загрузка создаёт новую версию, и у каждой свой срок. Через 30 дней версия освобождается, и её можно удалить вручную или правилом lifecycle. Подробности настройки с готовыми конфигурациями собраны в гайде по версионированию и lifecycle-политикам в S3.

Delete marker и что происходит при попытке удалить защищённый объект

Простой DELETE без version ID можно выполнить для любого объекта в бакете с Object Lock независимо от настроек блокировки, и данные при этом не удаляются. S3 создаёт delete marker: объект пропадает из обычного листинга, а все версии остаются на месте. Сроки хранения и legal hold не мешают созданию новых версий объекта и добавлению delete-маркеров поверх него. Так выглядит типичная паника «бэкапов нет»: в консоли пусто, в хранилище всё цело.

Проверить, что версии живы и retention выставлен, можно листингом версий объекта (list-object-versions) и запросом retention по каждой версии. Для удаления бакета сначала требуется удалить все версии и delete markers; защищённую Compliance-версию нельзя удалить root до истечения retention. Отдельно защищай аккаунт, IAM и ключи шифрования.

Права IAM и политики для Object Lock

Права на Object Lock раздают точечно, а не пакетом. Что за чем закрепляется:

• s3:PutObjectRetention, установка и изменение retention версии в допустимых режимом пределах. Нужно процессу, который явно задаёт retention; при применении defaults набор прав зависит от конкретной операции.
• s3:PutObjectLegalHold, включение и снятие удержания. Отдельная роль, не бэкап-скрипт.
• s3:GetObjectRetention и s3:GetObjectLegalHold, чтение настроек для проверок и аудита.
• s3:BypassGovernanceRetention, обход Governance. Только break-glass роль с MFA.
• s3:DeleteObjectVersion, удаление версий. Бэкап-учётке не выдавать.

Принцип least privilege здесь работает буквально: широкий Allow s3:* включает bypass и удаление версий, если нет ограничивающего Deny; Governance retention тогда можно обойти явным запросом. Legal hold и Compliance оцениваются отдельно.

Пример политики для бэкап-скрипта

Политику собирают из двух частей. Allow на s3:PutObject и s3:PutObjectRetention для конкретного префикса бэкап-бакета, например arn:aws:s3:::backup-bucket/daily/*. Явный Deny на s3:BypassGovernanceRetention и s3:DeleteObjectVersion. Deny перекрывает любые Allow из других политик, и это его главная ценность.

Привязывайте политику к IAM-роли, а не к пользователю: временные креды роли живут ограниченное время, их сложнее передать коллеге и забыть. Как устроены IAM-политики и вызовы API на практике, разобрано в обзоре S3-протокола: архитектура, API и настройка клиентов.

Защита от компрометации учётных данных

Сценарий: ключи бэкап-учётки утекли. Доступные действия определяются всеми её правами. Отсутствие BypassGovernanceRetention и DeleteObjectVersion ограничивает удаление версий, но само по себе не запрещает чтение или создание delete markers. PutObject позволяет дописывать версии и увеличивать расходы. Legal hold и Compliance сохраняют свои ограничения даже при наличии bypass.

Ущерб снижают: отдельный AWS-аккаунт под бэкапы, MFA для роли с bypass, алерты на снятие retention и удаление версий, GuardDuty для аномальной активности ключей. Ротацию сервисных ключей и разбор аудит-логов описывает материал про аудит и ротацию паролей в корпоративном хранилище секретов. Дополнительно нужна защита самих данных: сравнение клиентской и серверной моделей шифрования собрано в статье про шифрование данных при передаче и хранении. Object Lock спасает от удаления, но не от чтения, если ключи расшифровки ушли на сторону.

При выборе облака для бэкапов сравни стоимость хранения, запросов и восстановления. Можно рассмотреть и Timeweb Cloud (партнёрская ссылка), но S3-совместимость сама по себе не подтверждает поддержку Object Lock: до выбора провайдера отдельно проверь WORM, режимы, retention и восстановление по его актуальной документации и тесту. Ниже описана семантика Amazon S3.

Архитектура неизменяемых резервных копий в S3

Схема, при которой бэкап не удалить даже с украденными ключами основной инфраструктуры, собирается по шагам.

1. Отдельный AWS-аккаунт под резервные копии, вне основного контура администраторов.
2. Бакет с включённым versioning и Object Lock. Настрой defaults для новых версий и проверь фактический retention каждой загруженной версии.
3. Retention period по классу данных и допустимому окну обнаружения инцидента; 30 дней или год — только примеры, а не универсальные нормативы.
4. Lifecycle-правила: переход в совместимые классы хранения возможен и во время retention; окончательное удаление защищённой версии ждёт окончания retention и снятия legal hold. Сроки выбирай по RTO и стоимости извлечения.
5. IAM-роль бэкап-скрипта с минимумом прав: PutObject и PutObjectRetention на префикс.
6. Bucket policy, запрещающая удаление версий всем, кроме отдельной роли администратора бэкапов.
7. Аудит, метрики и алерты на снятие retention, удаление версий и изменение политик.

Правило 3-2-1-1-0: три копии данных, два разных носителя, одна копия вне основной площадки, одна неизменяемая, ноль ошибок при проверке восстановления. Object Lock закрывает пункт «одна неизменяемая», но не заменяет офлайн-слой. Разбор этой схемы и смежных мер защиты есть в руководстве по защите резервных копий от удаления и шифрования.

Пример: основной аккаунт скомпрометирован, у атакующего админские права в проде. Cross-account доступ настроен только на PutObject, ключей от бэкап-аккаунта у него нет. Версии в бэкап-бакете остаются неизменными, восстановление идёт из них. В том же аккаунте риск общего компрометирования выше, но активный Compliance retention всё равно защищает версию от удаления; это не защита ключей шифрования и доступа к аккаунту.

Retention period и lifecycle: как не переплатить

Retention period задаёт минимальный срок, в течение которого версию нельзя удалить. Lifecycle управляет переходами между классами и удалением; переходы возможны до окончания retention, удаление защищённой версии — нет. Пример связки: retention 30 дней, перевод версий в Glacier Instant Retrieval через 30 дней, удаление через 365.

Lifecycle не обходит retention. Current-version Expiration может создать delete marker и сделать защищённую версию noncurrent; окончательное удаление самой версии под retention или legal hold не произойдёт. Для неактуальных версий отдельно настрой и проверь NoncurrentVersionExpiration. Это защищает от ошибки в правилах, но создаёт неожиданный для новичка расход: в биллинге версии продолжают копиться.

Стоимость сравнивай с учётом региона, запросов, минимального срока и извлечения. Glacier Instant Retrieval предоставляет миллисекундный доступ; Glacier Flexible Retrieval и Deep Archive требуют restore, длительность которого зависит от класса и режима извлечения. Для операционного восстановления держите горячий слой хотя бы на последние 7-14 дней, старые и редкие версии уводите в холодные классы. Точные цены, минимальные сроки хранения и время извлечения по классам сверяйте в актуальном прайсе AWS: они меняются по регионам.

Отдельный аккаунт для бэкапов: зачем и как

Бэкап-бакет в том же аккаунте, что прод, защищает плохо: одна скомпрометированная админская учётка открывает оба контура. Отдельный аккаунт с собственными креденшелами разрывает эту связь.

Схема доступа: основной аккаунт имеет право только на PutObject в бэкап-бакет. Чтение и удаление делают отдельной ролью внутри бэкап-аккаунта под MFA. AWS Organizations и SCP позволяют централизованно запретить удаление бакетов и изменение политик во всех аккаунтах организации.

Защита от ransomware: что реально блокирует Object Lock

Object Lock закрывает часть векторов атаки и не закрывает остальные. Разбор по пунктам:

Типовые атаки на бэкапы Object Lock ломает, но окно восстановления всё равно нужно держать. Если retention 30 дней истёк, а атака обнаружена на 40-й день, нужная версия могла быть удалена lifecycle или пользователем; само истечение retention не удаляет данные. Комбинируйте неизменяемые копии с офлайн-слоем и мониторингом: окно обнаружения и расследования должно укладываться в выбранную политику хранения.

Как проверить восстановление из неизменяемых бэкапов

Неизменяемая версия в бакете не доказывает, что бэкап рабочий. Проверку делают регулярно, по документу, а не по памяти дежурного.

1. Выбрать тестовую версию в бэкап-бакете, посмотреть её retention и legal hold.
2. Восстановить данные в отдельный тестовый бакет или на отдельный инстанс, не трогая прод.
3. Сверить целостность: размер, контрольные суммы, содержимое каталогов, успешный запуск восстановленного сервиса.
4. Замерить RTO (время восстановления) и RPO (насколько свежие данные в копии).
5. Записать результат, время, версию объекта и исполнителя в журнал проверок.

Периодичность выбирай по критичности и изменениям системы; месяц или квартал — лишь примеры, а после существенного изменения бэкап-процесса нужна внеплановая проверка. Проверять нужно до истечения retention: если lifecycle уже удалил версию, восстановление невозможно по определению.

Чек-лист проверки восстановления

• Версия доступна и открывается в бэкап-бакете.
• Retention period на версии соответствует политике хранения.
• Скачивание версии проходит от учётки с правом чтения.
• Контрольная сумма восстановленного файла совпадает с эталонной.
• Сервис из восстановленной копии стартует и отвечает на запросы.
• RTO и RPO укладываются в целевые значения.
• Legal hold на объектах расследований актуален, лишние флаги сняты.
• Результат проверки записан и подписан ответственным.

Ограничения Object Lock и типичные ошибки

1. Object Lock нельзя отключить после включения.
2. Versioning нельзя отключить.
3. Compliance retention нельзя сократить; Governance допускает авторизованный bypass. Legal hold действует отдельно.
4. Стоимость растёт с числом версий, долгий retention оборачивается дорогим сюрпризом в биллинге.
5. Compliance-режим необратим: ошибка в сроке означает оплату хранения до его конца.
6. Удаление бакета не обходит защиту версий: бакет должен быть пустым, а Compliance retention действует и для root.
7. Офлайн-копию Object Lock не заменяет.
8. Без проверки восстановления неизменяемая копия может оказаться бесполезной.

Перед продакшеном поднимите тестовый бакет и прогоните полный цикл: загрузка, установка retention, попытка удаления версии, попытка снять блокировку, срабатывание lifecycle, восстановление. Точные ограничения по регионам, версиям API и поддерживаемым классам хранения сверяйте в официальной документации AWS по S3 Object Lock, versioning и lifecycle: детали там обновляются чаще, чем в сторонних пересказах.

Итог: как выбрать режим и построить защиту

Governance берут для внутренних операционных бэкапов, где нужна гибкость и аварийное снятие через отдельную роль с MFA. Compliance выбирают для регуляторных сценариев, где неизменяемость нужна без исключений. Legal hold добавляют точечно под юридические удержания без срока.

Рабочая связка: отдельный аккаунт под бэкапы, бакет с versioning и Object Lock, retention по классу данных, lifecycle для холодных классов, минимальные права IAM, bucket policy против удаления версий, аудит с алертами, регулярная проверка восстановления. Object Lock здесь один из слоёв, а не гарантия абсолютной защиты.

Первый шаг: поднимите тестовый бакет, включите versioning и Object Lock, прогоните сценарий удаления версии и восстановление из неё. Задокументируйте процедуру и периодичность проверок: проверь не только отказ удаления, но и восстановление, права и доступ к ключам; время проверки зависит от системы.