Неудаляемый бэкап: три режима Object Lock и цена неверного выбора

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

Так может случится в любой момент. Например, если будет взлом инфраструктуры компании, у которого основной источник общения с клиентов это сайт и почта и «резервные копии хранились на одном сервере с сайтом», то будет очень печально, так как восстановить будет крайне сложно.

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

Защититься от этого сценария помогает WORM-блокировка на уровне объектного хранилища. В публичном облаке её обычно реализуют через Object Lock: записанный объект нельзя удалить или перезаписать, пока не закончится срок хранения. Однако «неудаляемый бэкап» — это не один режим. Governance, Compliance и Legal Hold по-разному определяют, кто может снять блокировку, как долго она действует и какую цену придётся заплатить за ошибку в настройке.

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

Материал пригодится инженерам и архитекторам, которые проектируют резервное копирование в облаке и обосновывают выбор режима блокировки, а также специалистам по ИБ, которым нужно защитить копии от намеренного удаления. Для гибридных схем с физическими серверами применима часть об арифметике восстановления; конкретные механизмы блокировки нужно сверять с возможностями своей платформы.

Атакующий идёт в бэкап первым

Порядок действий атакующего в схеме с вымогательством повторяется от инцидента к инциденту.

Целенаправленные атаки на резервные копии подтверждают и отчёты. По данным Veeam 2025 Ransomware Trends, у 89% организаций, пострадавших от вымогателей, атакующие пытались получить доступ к хранилищам резервных копий. В среднем 34% таких хранилищ были изменены или удалены.

По оценке центра кибербезопасности «ЕСА Про», в 2025 году около 20% атак на бизнес были связаны с вымогательством.

Резервные копии обычно теряются по трём причинам.

1. Копии находятся в том же проекте и доступны через те же административные учётки, что и прод. Украденного токена хватает, чтобы добраться и до рабочих систем, и до бэкапов.

2. Срок хранения слишком короткий. Вредонос может оставаться в инфраструктуре неделями и успеть попасть во все актуальные точки восстановления.

3. Восстановление не проверяют заранее. Что копия повреждена или непригодна для запуска, выясняется только во время инцидента.

Копии на том же сервере, где и сайт

Первая причина из списка может выглядеть на практике, как цепочка проникновения в инфраструктуру: сервис загрузки файлов принял файл, который веб-сервер обработал как PHP-код, дальше выполнение команд внутри Docker‑контейнера, доступ во внутреннюю сеть, учётные данные от SVN‑репозиториев с паролями от баз данных и выполнение кода в продакшене.

Атакующие могут заранее получить доступы, например, за две недели до реализации и до момента «Х» расширяли права. Уязвимость может быть, в случае, если администраторы работают со старыми версиями ПО, а бэкапы лежат на одном сервере с сайтом или доступны по прямой записи в локальной сети.

На что я попрошу вас обратить внимание, как решение предотвращения масштаба ущерба, это использование объектного хранилища (реализация WORM) с опцией Object Lock. В рамках Object Lock выбирайте параметр Governance и Compliance.

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

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

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

Как устроен WORM в объектном хранилище

Механизм называется Object Lock и работает по модели WORM (write once, read many). Объект, записанный в бакет с включённой блокировкой, нельзя удалить или перезаписать до истечения срока хранения. Ограничение действует на уровне хранилища, ниже бэкапного приложения, поэтому обойти его через API резервного копирования не получится.

Срок защиты назначается отдельно для каждого объекта и отсчитывается с даты создания копии. В одном бакете могут храниться объекты с разными датами разблокировки. Снять защиту сразу со всех объектов нельзя даже теоретически.

У блокировки есть два независимых параметра: срок хранения и возможность снять ограничение досрочно. Legal Hold влияет на срок хранения, но не создаёт отдельный уровень защиты. Поэтому рабочих сочетаний остаётся три.

По сроку хранения предусмотрено два варианта:

1. Период хранения — Retention Period, фиксированный срок от даты создания копии. Его задаёт администратор при настройке расписания. Максимальный срок — три года по сроку исковой давности; при необходимости его можно продлить ещё на три года.

2. Бессрочное хранение — Legal Hold, блокировка без заранее заданной даты окончания. Она действует, пока уполномоченный пользователь не снимет её вручную. Основной сценарий — аудит и судебные разбирательства, когда данные нужно заморозить на неопределённый срок.

По стойкости есть два режима:

1. Governance — управляемая блокировка. Обычный пользователь не может удалить объект, но пользователь с особыми правами способен досрочно снять защиту.

2. Compliance — строгая блокировка. До истечения срока хранения копию не может удалить или изменить никто, включая владельца проекта и техническую поддержку.

Governance защищает от случайного удаления и ошибок пользователей, но только до тех пор, пока атакующий не получит учётную запись с правом снимать блокировку. Если нужно сохранить данные даже при компрометации администратора проекта, подходит только Compliance. 

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

Governance защищает от ошибок, Compliance — от атак. Legal Hold задаёт срок хранения, а уровень защиты определяют Governance и Compliance. Ошибку в сроке для Compliance нельзя исправить, и каждый лишний день увеличивает стоимость хранения.

Ограничения навсегда

Три решения принимают при создании бакета. Позже изменить их уже нельзя.

1. Бакет с блокировкой создаёт сам сервис. Вручную ничего настраивать не нужно: для каждого варианта блокировки система резервного копирования создаст в проекте отдельный бакет. Копии с блокировкой будут записываться только туда. Всего в проекте можно создать до пяти бэкап-бакетов: три с разными вариантами блокировки и два обычных — для виртуальных машин и баз данных.

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

3. Блокировка не распространяется на ранее созданные копии. Они останутся в обычном бакете без защиты, а новые копии будут записываться в бакет с блокировкой. Включить неудаляемые бэкапы можно в действующем плане резервного копирования: новый план не понадобится, но старые копии от удаления защищены не будут.

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

Как мы решаем это в Cloud Backup

Сервис резервного копирования VK Cloud работает без агентов в гостевых операционных системах. Плоскость управления обращается к API платформы: снимки дисков создаются через Cinder, образы виртуальных машин — через Nova, а для управляемых баз данных используются вызовы к Trove. Копии сохраняются в объектном хранилище, в бакетах класса BackupBucket.

Тарифицируются два объекта: сама копия в бакете и временный снимок диска, который существует около часа во время копирования. Перед сохранением данные диска сжимаются, поэтому размер резервной копии почти всегда отличается от размера диска.

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

Копии можно сделать неизменяемыми. Governance, Compliance и Legal Hold настраиваются при создании расписания в личном кабинете. Отдельная консоль не нужна: сервис сам создаст бакет для выбранного типа блокировки.

Согласованность приложения нужно обеспечивать отдельно. Безагентная схема создаёт копию на уровне диска и на время снятия снимка замораживает файловую систему. Для СУБД и брокеров под нагрузкой этого недостаточно: файлы сохранятся целыми, но состояние транзакций может оказаться несогласованным. Такие системы лучше копировать штатными средствами самой базы данных.

Управляемые базы данных пока не поддерживают неудаляемые резервные копии. Бэкап инстанса создаёт сам сервис. Для PostgreSQL доступно восстановление на момент времени по журналу транзакций WAL с точностью до секунды. В текущем релизе иммутабельность доступна только для виртуальных машин и их дисков.

Чтобы настроить неудаляемые бэкапы в личном кабинете, создайте расписание, включите «Неудаляемые бэкапы», выберите тип блокировки — период хранения или бессрочное хранение — и режим: Governance или Compliance. До включения плана калькулятор рассчитает стоимость хранения на выбранный срок.

Блокировку можно включить и для отдельного ручного бэкапа. После снятия блокировки клиент сможет удалить такую копию.

Восстановимость и цена инкрементов

Копию можно сохранить, но Object Lock ничего не говорит о том, сколько времени займёт её разворачивание.

На скорость восстановления влияют тип копии, тип диска и способ восстановления. Арифметику задаёт объём цепочки. При восстановлении из полной копии разворачивается один объект. При восстановлении из инкрементальной копии система сначала восстанавливает полную копию, затем последовательно накатывает все инкременты до нужной точки.

Инкременты в плане необязательны. Если их не использовать, каждая копия будет полной: цепочки не появятся, а для восстановления всегда потребуется развернуть один объект.

Считаем на простом примере. Полная копия создаётся раз в неделю, инкременты — ежедневно. Суточная дельта составляет 5% от общего объёма как допущение для расчёта. Виртуальная машина занимает 2 ТБ. Пропускную способность конвейера резервного копирования принимаем равной примерно 1 ТБ/ч по данным команды сервиса и считаем её одинаковой для копирования и восстановления. Точное значение покажет только тест на вашем профиле данных.

Расчёт сделан по документированной пропускной способности. В реальном RTO нужно добавить время на создание томов, подключение дисков и загрузку операционной системы. Тип диска тоже влияет на результат: SSD быстрее HDD. Восстановление в исходную машину выполняется быстрее, чем разворачивание в новую.

Инкрементальные копии экономят место, но увеличивают время восстановления. В приведённом примере оно меняется от 2,0 часа в день полной копии до 2,6 часа накануне следующей — разница достигает трети общего времени. День полной копии выбирают с учётом профиля нагрузки. Если отключить инкременты, время восстановления будет стабильным.

Object Lock отвечает за сохранность копии до момента восстановления, а на скорость влияют глубина цепочки инкрементов и тип диска. Эти параметры нужно настраивать одновременно.

Ретеншен считает только разблокированные копии

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

Схема GFS для полных копий с блокировкой недоступна. В плане можно выбрать только один подход к хранению полных копий.

При лимите в три копии порядок будет таким:

1. Заблокированные копии накапливаются в бакете, а счётчик ретеншена остаётся пустым.

2. У копии истекает срок блокировки, она переходит в список разблокированных и начинает учитываться в лимите.

3. Число разблокированных копий достигает трёх, лимит исчерпан.

4. Разблокируется четвёртая копия, после чего сервис удаляет самую старую из разблокированных.

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

Требование «восстановимся на любой день за прошлый год» упирается в лимит на количество копий, а не в срок блокировки. Глубину истории нужно считать до включения плана, учитывая лимит, частоту запуска и срок блокировки.

Чек-лист настройки

Порядок действий, который помогает сохранить и стойкость, и восстановимость:

1. Решите вопрос с режимом до создания бакета. Выбирайте Compliance, если нужно пережить компрометацию администратора, и Governance — если нужна защита от ошибки оператора. Смена решения потребует новый бакет. Система создаст его сама, но старые копии останутся в прежнем бакете со своим режимом.

2. Посчитайте стоимость срока хранения. Калькулятор в личном кабинете учитывает объём копий и временный снапшот диска на время копирования, поэтому отдельно оценивать их не нужно. При Compliance лишний месяц хранения удалить нельзя, поэтому итоговую стоимость нужно проверить до включения плана.

3. Задайте частоту. Расписание с блокировкой можно запускать раз в сутки или реже, поэтому минимальный RPO по расписанию составляет сутки. Более частые запуски доступны для управляемых баз данных, но блокировка на них пока не распространяется. Для базы возможен обходной путь: снять дамп штатными средствами СУБД и записать его в бакет объектного хранилища с включённым Object Lock. Блокировка сработает на уровне S3, в обход системы резервного копирования.

4. Выберите день полной копии. Он определяет худший случай по RTO для цепочки инкрементов. День полной копии задаётся всегда, но инкременты можно отключить — тогда расчёт по цепочке к плану не применяется.

5. Посчитайте глубину истории до включения плана. Точный объём бакета заранее определить нельзя: степень сжатия зависит от данных и не показывается в интерфейсе. Поэтому считайте количество копий: частота запуска, срок блокировки и лимит в 200 копий вместе определяют, на сколько дней назад можно будет восстановиться. Дальше самые старые копии будут удаляться автоматически.

6. Проверьте восстановление. Разворачивайте копию в новую ВМ и замеряйте время. Документация рекомендует делать это раз в квартал. Иммутабельная копия, из которой ни разу не восстанавливались, остаётся предположением.

7. Проверьте, у кого есть права на управление блокировкой. Снять бессрочную блокировку, досрочно снять Governance и продлить срок могут только владелец проекта и суперадминистратор. Снятие подтверждается паролем от аккаунта. Compliance нельзя снять досрочно никому, включая техническую поддержку. Расширенной ролевой модели пока нет, поэтому список владельцев проекта и суперадминистраторов определяет границу доступа. Пересмотрите его до включения блокировки.

Выводы

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

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

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

Настройку нужно продумать до включения плана. Бакет с Object Lock нельзя переделать, а срок хранения в Compliance нельзя уменьшить — его можно только продлить. Поэтому слишком большой запас по ретеншену превращается в обязательные расходы на хранение. Практичнее назначить срок, который покрывает модель угроз и требования к восстановлению, а затем при необходимости продлевать его.

Наконец, неудаляемая копия не гарантирует приемлемый RTO. Время восстановления зависит от размера данных, типа диска, способа развёртывания и глубины цепочки инкрементов. Расчёт даёт ориентир, но подтверждает его только регулярное восстановление в тестовую ВМ с замером времени. Иначе в момент инцидента окажется, что копия сохранилась, а прод всё равно нельзя поднять в нужный срок.