Введение

Шифровальщик редко приходит один. Обычно вместе с ним в инфраструктуру приходит ещё одна проблема: атака не только на рабочие данные, но и на резервные копии. И вот это уже по-настоящему неприятно. Пока компания надеется на backup, злоумышленник тихо удаляет, перезаписывает или шифрует те самые копии, которые должны были спасти ситуацию.

Именно поэтому разговор о бэкапах сегодня уже не сводится к фразе «ну у нас же есть S3». Этого мало. Нужны immutable backups — неизменяемые резервные копии, которые нельзя тихо подправить, стереть или «почистить задним числом». В экосистеме S3 такую роль выполняет S3 Object Lock: механизм, который превращает обычное хранение в WORM-модель — write once, read many, то есть «записал и больше не трогаешь».

Разберёмся без сухой теории: как это работает, чем governance отличается от compliance, где компании чаще всего ошибаются и почему защита резервных копий сегодня начинается не с объёма хранилища, а с невозможности эти копии изменить.

Почему обычный backup уже не выглядит надёжным

Представьте сейф, ключ от которого лежит прямо на крышке. Формально сейф есть. По факту защита условная.

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

CISA в своих рекомендациях прямо подчёркивает: ransomware нередко пытается найти и уничтожить доступные резервные копии, поэтому копии должны быть изолированы, а сценарии восстановления — регулярно проверяться. Иначе «backup есть» превращается в опасную иллюзию.

Отсюда простой вывод: резервная копия должна быть не просто сохранена, а защищена от изменения. Причём защищена не морально, не регламентом в Confluence и не надеждой на аккуратность администраторов. Технически.

Что такое immutable backups простыми словами

Immutable backups — это резервные копии, которые нельзя изменить или удалить в течение заданного срока хранения.

Смысл очень практичный. Сегодня ночью ваш backup попал в хранилище. Завтра в сеть залетел шифровальщик. Он может пробовать всё что угодно — удаление, overwrite, массовую очистку, скрипты на API. Но правильно настроенный immutable backup не даст переписать или стереть уже защищённую копию до окончания retention period.

Это как если бы вы не просто положили договор в шкаф, а запечатали его в капсулу, которую нельзя открыть до конкретной даты. Капсула не спорит, не просит подтверждения и не верит, что «мы тут просто хотели чуть-чуть поправить файл». Она просто не даёт этого сделать.

Для бизнеса это означает очень важную вещь: даже если часть инфраструктуры скомпрометирована, у вас остаётся «золотая копия», на которую ещё можно опереться при восстановлении.

Как работает S3 Object Lock

S3 Object Lock — это механизм WORM-защиты в Amazon S3. Он не просто «ставит запрет на файл», а работает на уровне версий объектов. Для этого bucket должен быть versioned: без versioning Object Lock не работает. При этом AWS позволяет включать Object Lock как на новых, так и на уже существующих S3 bucket’ах; после включения Object Lock нельзя отключить сам Object Lock и нельзя suspend versioning для этого bucket’а.

Вот здесь и кроется главный смысл.

Когда вы храните backup как объект в S3, Object Lock защищает конкретную версию этого объекта на заданный срок. То есть система не говорит: «этот путь навсегда закрыт». Она говорит иначе: «эта версия объекта до такой-то даты неприкосновенна».

Это тонкое, но очень важное различие.

Предположим, у вас есть объект backup/db-latest.tar.zst. Ночью туда загрузили свежую копию и сразу применили retention на 30 дней. Через неделю злоумышленник попытается перезаписать этот же ключ. Что произойдёт? S3 создаст новую версию, но старая защищённая версия останется в bucket’е и не сможет быть удалена до окончания срока удержания. И именно это делает резервное копирование в S3 реально полезным в сценарии атаки: старая «чистая» версия не исчезает по щелчку. Это уже не абстрактная надёжность, а рабочий механизм выживания. Такая модель прямо вытекает из того, что Object Lock защищает версии объектов и при этом допускает запись новых версий под тем же ключом.

Retention period

Retention period — это срок, в течение которого защищённую версию нельзя удалить или перезаписать.

Можно задавать его на уровне отдельного объекта или как bucket default retention для новых объектов. После истечения срока объект снова становится обычным с точки зрения удаления. AWS также подчёркивает, что retention можно задавать в днях или годах.

Практически это выглядит так:

• ежедневные backup’ы БД — 14 дней;
• еженедельные полные копии — 60 дней;
• месячные архивы — 1 год.

Не обязательно навсегда «замораживать» всё подряд. Наоборот, хорошая схема почти всегда строится на сроках, а не на вечной блокировке.

Legal hold

Legal hold — это отдельный механизм. В отличие от retention period, у legal hold нет автоматической даты окончания: защита действует, пока её явно не снимут. AWS описывает legal hold как независимый от retention механизм: один и тот же объект может одновременно иметь и retention period, и legal hold.

Это удобно не только для юридических сценариев. Иногда компания расследует инцидент, готовит аудит или хочет временно «заморозить» конкретные backup-цепочки до отдельного решения. Тут legal hold очень к месту.

Governance mode и Compliance mode

У S3 Object Lock есть два режима удержания: governance и compliance. И путать их не стоит.

Governance mode — более гибкий вариант. Большинство пользователей не смогут удалить или изменить защищённый объект, но у специально уполномоченных ролей остаётся возможность обойти ограничение при наличии разрешения s3:BypassGovernanceRetention и явного запроса на bypass. Этот режим удобен для внутренней политики, тестового внедрения и тех случаев, когда бизнесу всё же нужен контролируемый «аварийный выход».

Compliance mode — совсем другой уровень строгости. В этом режиме защищённую версию нельзя удалить или укоротить срок удержания ни обычному администратору, ни даже root-пользователю аккаунта. AWS прямо пишет, что в compliance mode retention period нельзя сократить, а mode нельзя изменить, пока срок не истёк.

Если упростить до бытового сравнения:

• governance — это офисный сейф, к которому у директора есть спец-ключ;
• compliance — это банковская ячейка, которую не откроют раньше срока даже «очень важному человеку».

Для защиты от шифровальщиков второй вариант выглядит особенно привлекательно. Но именно с ним нужно аккуратнее всего: ошиблись со сроком хранения — сами же потом будете жить с последствиями.

Почему Object Lock действительно помогает против ransomware

Шифровальщик опасен не только шифрованием. Современные атаки часто идут по цепочке: проникновение, повышение привилегий, поиск backup-систем, удаление теневых копий, остановка агентских сервисов, зачистка хранилищ, а уже потом шифрование рабочих данных.

В этой логике backup — один из первых объектов для удара.

Поэтому неизменяемые резервные копии решают очень конкретную задачу: не дают атакующему «добить» последнюю линию обороны. Даже если учётка скомпрометирована, уже locked-версии объектов нельзя тихо стереть до окончания retention. Именно поэтому AWS называет Object Lock важным элементом cyber resilience, а CISA отдельно акцентирует необходимость недоступных для злоумышленника копий и регулярных проверок восстановления.

Но здесь важно не впасть в магическое мышление.

Object Lock не делает систему неуязвимой. Он не лечит слабые IAM-политики, не отменяет утечку ключей доступа и не заменяет сегментацию. Более того, атакующий всё ещё может записать новую вредоносную версию по тому же ключу, если у него есть право на запись. Просто старая защищённая версия останется в истории и не исчезнет. Это не «щит от всего», а очень сильная страховка от самого болезненного сценария — потери чистой backup-копии. Такой вывод логично следует из версиионной модели S3 Object Lock, где защищаются именно версии, а не весь namespace целиком.

Где компании ошибаются чаще всего

Ошибка №1. Включили Object Lock, но не настроили retention

Сам по себе флаг Object Lock на bucket — это не кнопка «сделать immutable навсегда». Это лишь возможность применять защиту.

Если не задать default retention или не выставлять retention на уровне объектов при загрузке, новые backup’ы могут попасть в bucket без фактической immutability. Формально функция включена. Практически — защиты нет.

Это один из тех случаев, когда галочка в консоли даёт ложное чувство безопасности.

Ошибка №2. Думают, что старые объекты уже защищены автоматически

Ещё одна тонкая ловушка. Object Lock теперь действительно можно включать и на существующих bucket’ах, но старые объекты от этого не становятся immutable по мановению руки. Для исторических данных защиту нужно применять отдельно. AWS прямо разделяет включение Object Lock на bucket и последующее применение retention или legal hold к объектам.

То есть сценарий «вчера включили Object Lock — значит, пятилетний архив уже в безопасности» неверный.

Ошибка №3. Используют governance, а права на bypass раздают слишком широко

Governance mode удобен, но только до тех пор, пока возможность обхода жёстко ограничена.

Если право на bypass retention висит на слишком широкой роли, если его унаследовал backup-сервер, automation-пользователь или полкоманды DevOps, вся идея immutability резко теряет вес. Технически защита есть. Организационно — дверца приоткрыта.

Ошибка №4. Не тестируют восстановление

Это классика, которая не стареет.

Бэкап без регулярного restore test — как запасное колесо, которое никто никогда не накачивал. На бумаге оно есть. На трассе может оказаться, что пользы от него немного.

CISA отдельно рекомендует не только хранить копии вне досягаемости ransomware, но и регулярно тестировать их доступность и целостность в disaster recovery-сценариях.

Ошибка №5. Ставят compliance «везде и навсегда»

Иногда после первой серьёзной тревоги компании хотят зацементировать вообще всё: любой backup на годы, без исключений.

Звучит решительно, но на практике это часто приводит к росту стоимости, неудобному lifecycle и тяжёлым операционным последствиям. В compliance mode срок удержания нельзя просто сократить по настроению. Поэтому здесь нужна не эмоциональная, а продуманная политика хранения.

Как внедрить immutable backup в S3 без лишнего герoizma

Самый рабочий подход — не пытаться сразу переделать всю систему хранения, а выделить отдельный контур для защищённых резервных копий.

Нормальная базовая схема выглядит так:

1. Создаётся отдельный bucket под backup’ы, а не «общая свалка» для логов, артефактов сборки и архивов.
2. На bucket включается versioning и Object Lock.
3. Назначается default retention для новых объектов.
4. Для критичных копий выбирается compliance mode, для менее жёстких сценариев — governance.
5. Права на удаление, изменение retention и особенно bypass governance сужаются до минимума.
6. Настраиваются lifecycle-правила для управления неактуальными версиями после окончания retention.
7. Регулярно проводится restore test на отдельной площадке или в изолированной среде. Основные требования и ограничения по настройке Object Lock именно такие: versioning обязателен, default retention применяется к новым объектам, а после включения Object Lock выключить его уже нельзя.

Если говорить совсем по-человечески, задача не в том, чтобы «заливать бэкапы в облако». Задача в том, чтобы создать для них такое место, где даже очень неудачный день не превратит backup в пустое место.

Какой режим выбрать: governance или compliance

Здесь нет универсальной кнопки «правильно».

Governance mode подойдёт, если:

• вы внедряете immutability поэтапно;
• у вас сложные процессы и нужны контролируемые исключения;
• вы хотите сначала обкатать retention-политику без риска навечно заблокировать не те данные.

Compliance mode уместен, если:

• речь о truly critical backups;
• вы защищаетесь не только от ошибки сотрудника, но и от сценария с компрометацией привилегированной учётки;
• важнее максимальная жёсткость, чем операционная гибкость.

Хорошее практическое правило простое: сначала думать не о названии режима, а о цене ошибки. Насколько больно будет, если эти копии исчезнут? Насколько больно будет, если они, наоборот, останутся заперты дольше нужного?

Когда ответы честные, выбор обычно становится очевиднее.

А если используется AWS Backup, а не прямые выгрузки в bucket

Тогда рядом с Object Lock стоит посмотреть и на AWS Backup Vault Lock. Это отдельный механизм immutable-защиты уже на уровне backup vault: в compliance mode после grace period lock нельзя удалить или изменить, а попытки удалить recovery points или поменять lifecycle AWS блокирует. Для команд, которые строят резервное копирование через AWS Backup, это полезное дополнение к общей стратегии защиты.

Проще говоря:

• если вы работаете с объектами и выгрузками в S3 — смотрите на S3 Object Lock;
• если централизуете backup’ы через AWS Backup — изучайте ещё и Vault Lock.

Иногда эти подходы комбинируют, и это вполне разумно.

Что особенно важно для S3-совместимого хранилища

Для блога о практической инфраструктуре здесь есть важный нюанс: бизнесу редко нужна «теория AWS ради AWS». Ему нужна воспроизводимая схема.

Если вы выбираете S3-совместимое хранилище под backup’ы, проверьте не только цену за гигабайт и API-совместимость. Смотрите глубже:

• поддерживается ли Object Lock;
• как реализованы versioning и lifecycle;
• можно ли задать retention policy без ручных костылей;
• насколько удобно проверять версии и восстанавливать данные;
• есть ли нормальная изоляция доступа и понятные политики безопасности.

Это не мелочи. Именно на этих деталях и решается, будет ли у вас просто ещё одно облачное ведро для файлов или по-настоящему рабочая защита резервных копий. Сам King Servers в своих материалах отдельно пишет про S3-совместимые решения для хранения резервных копий и объектных данных, так что тема для блога компании абсолютно органичная.

Вывод

Сегодня недостаточно просто сказать: «У нас есть backup». Это звучит спокойно, но в 2026 году уже не гарантирует почти ничего. Настоящую устойчивость дают immutable backups — резервные копии, которые не исчезнут в тот момент, когда они нужны больше всего.

S3 Object Lock хорош тем, что решает проблему не лозунгами, а механикой. Он заставляет систему хранения вести себя жёстко и предсказуемо: заданная версия backup’а остаётся неприкосновенной до нужной даты. Для защиты от шифровальщиков это не модная опция и не «приятный бонус», а один из самых практичных уровней обороны.

Если смотреть на тему трезво, формула получается простой: versioning, Object Lock, разумный retention, строгие IAM-права, отдельный backup-контур и регулярные тесты восстановления. Без драмы. Без иллюзий. Зато с куда более высокой вероятностью, что после инцидента вы будете восстанавливать систему, а не объяснять бизнесу, почему бэкапы тоже пропали.

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