Immutable S3-бэкап с Object Lock против ransomware: тестируем Veeam + MinIO в Compliance-режиме

После волны ransomware-инцидентов в марте один из наших клиентов задал вполне резонный вопрос: «А если атакующий доберётся до учётки администратора бэкапов - он сможет удалить все копии?». Честный ответ на тот момент был «да, сможет». Что нас, откровенно говоря, не устраивало.

Производители хранилищ и облачных сервисов сейчас активно продвигают S3 Object Lock как ответ именно на этот сценарий. Мы взяли и проверили - что реально работает, а что маркетинг. На клиентах, которых ведём в рамках managed-сопровождения, запустили тестирование двух схем: Veeam + MinIO on-premise и Veeam + Yandex Object Storage.

Почему Governance-режим нас не устроил

В февральском посте про Veeam 10 мы уже упоминали, что Object Lock бывает двух видов: Governance и Compliance. Вернёмся к этому подробнее, потому что разница принципиальная.

Governance mode - блокирует удаление для обычных пользователей, но пользователь с правами s3:BypassGovernanceRetention может объект всё-таки удалить. На AWS это обходится через IAM. На MinIO - аналогично. То есть если атакующий скомпрометировал достаточно привилегированную учётку, защита снимается.

Compliance mode - другая история. Объект нельзя удалить или изменить до истечения retention period никому. Буквально никому - даже root-аккаунту AWS или суперадминистратору MinIO. Период хранения нельзя сократить. Можно только увеличить. Именно это нас и интересовало.

Veeam 10 поддерживает оба режима, но по умолчанию ставит Governance. Для переключения в Compliance нужно явно указать это в настройках репозитория.

Схема, которую мы тестировали

Стенд выглядел так: продуктивная среда клиента на VMware, Veeam Backup & Replication 10 как инструмент резервного копирования, Scale-Out Backup Repository с двумя уровнями - локальный репозиторий на NAS и capacity tier в объектное хранилище.

В качестве объектного хранилища тестировали два варианта параллельно:

• MinIO - on-premise, развёрнутый на отдельном хосте, версия с поддержкой Object Lock. Ключевой момент: MinIO для Object Lock требует инициализации в режиме с erasure coding, обычная single-node установка Object Lock не поддерживает. Это важно при планировании.
• Yandex Object Storage - облачный, поддержка Object Lock появилась, настройка через консоль или API аналогична AWS S3.

Retention period выставили 14 дней - достаточно для обнаружения инцидента и реакции, без чрезмерного роста хранилища.

Что проверяли

Нас интересовал один конкретный сценарий: атакующий получил ключи доступа к S3 (или credentials от MinIO) с полными правами. Что он может сделать с бэкапами?

Взяли тестовый бэкап, загруженный в Compliance-режиме, и попробовали несколько вариантов удаления:

Через AWS CLI / mc (MinIO client) напрямую. Команда aws s3 rm / mc rm возвращает ошибку: объект защищён Object Lock. Даже с ключами, у которых полные права на бакет. Ожидаемо, но приятно видеть это в действии.

Попытка удалить версию объекта. S3 Object Lock привязан к конкретной версии - если бакет с версионированием, можно попробовать удалить версию отдельно. С Compliance-режимом это тоже не работает - DeleteObjectVersion возвращает AccessDenied с указанием на Object Lock.

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

Удаление всего бакета. Нельзя удалить бакет, в котором есть объекты с активным Object Lock. Сначала нужно дождаться истечения retention на всех объектах.

Итог: при правильно настроенном Compliance-режиме бэкапы за retention-период действительно недоступны для удаления. Ни через прямой доступ к хранилищу, ни через Veeam Console.

Нюансы, которые обнаружили в процессе

Не всё прошло гладко, и это полезнее всего зафиксировать.

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

Veeam и Compliance mode. В настройках Veeam репозитория есть галочка «Make recent backups immutable for N days» и выбор режима. По умолчанию - Governance. Переключение на Compliance меняет поведение: Veeam предупреждает, что управление хранилищем станет строже. Это ограничивает гибкость расписания - уменьшить retention задним числом не выйдет, поэтому считаем объёмы заранее.

Тестовое восстановление - обязательно. После настройки Compliance-режима мы тут же проверили восстановление VM из этих бэкапов. Чтение объектов из Compliance-хранилища работает штатно - Object Lock блокирует только запись и удаление, но не чтение. Instant VM Recovery отработал без проблем. Это важно проверить, потому что бэкап, из которого нельзя восстановиться, - не бэкап.

Мониторинг дополнительных расходов на хранение. При Compliance-режиме данные гарантированно хранятся весь заявленный период. Если в расписании что-то поменялось и старые точки восстановления стали не нужны - они всё равно останутся до истечения срока. У одного клиента мы немного промахнулись с оценкой объёма на первый месяц.

Что в итоге порекомендовали клиентам

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

• Основной репозиторий - локально, изолированная сеть, без доступа с рабочих станций.
• Второй уровень - S3 с Object Lock в Compliance-режиме, retention 14-30 дней в зависимости от требований клиента.
• Доступ к S3 - только с Veeam-сервера, IAM/MinIO policy запрещает доступ с других хостов. Ключи ротируются.
• Тест восстановления - ежеквартально, из S3-копии, на изолированный стенд.

Это не панацея - у атакующего с длинным горизонтом (проник и ждёт дольше, чем retention period) этот механизм не сработает. Но против типичного ransomware, который действует за часы или дни, - работает. И это честный, проверяемый результат, а не обещание из брошюры.

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