Immutable backup по схеме 3-2-1-1-0: Veeam v12 + Selectel S3 Object Lock против ransomware

В феврале волна ESXiArgs прошла по тысячам хостов VMware. С тех пор нас не отпускает один вопрос: а что было бы с клиентами, у которых бэкапы хранились на той же инфраструктуре? Ответ очевидный - плохо было бы. Ransomware давно умеет находить и шифровать резервные копии прежде, чем добраться до основных данных. Поэтому с весны мы методично пересматриваем backup-стратегию у всех клиентов на сопровождении, и immutable-хранилище стало обязательным пунктом, а не опцией.

Что такое 3-2-1-1-0 и почему не 3-2-1

Классическая схема 3-2-1 - три копии, два разных носителя, одна офсайт - давно стала минимальным стандартом. Но у неё есть слабое место: она ничего не говорит о защите от удаления. Ransomware, получивший доступ к учётке Veeam, спокойно удаляет задания и копии - и офсайт-копия в том же Selectel S3 без Object Lock ничем не защищена.

Расширение до 3-2-1-1-0 добавляет два требования:

• +1 - одна копия immutable (object storage с Object Lock или ленточная библиотека с WORM, у нас это S3 Object Lock)
• +0 - ноль ошибок при проверке восстановления, то есть регулярный verify, а не просто «копия лежит»

Последний пункт - самый неудобный. Лежит - ещё не значит восстанавливается.

Что именно внедряем

Стек у нас конкретный: Veeam Backup & Replication v12 с direct-to-S3 на Selectel Object Storage с Object Lock. Мы уже тестировали эту связку в январе - там разобрали механику, теперь говорим про security-угол и массовое внедрение.

Схема выглядит так:

• основной репозиторий - локальный (on-prem или на нашем хранилище у клиента), короткое retention, быстрое восстановление
• secondary target - Selectel S3 bucket с Object Lock Governance, retention 30 дней, Scale-out Backup Repository в Veeam с Copy Job

Object Lock Governance - не Compliance - выбран осознанно. Compliance нельзя снять вообще никому до истечения срока, включая собственный аккаунт Selectel. Это максимальная защита, но и максимальные неудобства при ошибочном retention или тестовых объектах. Для большинства клиентов Governance достаточен: снять lock можно только с явными правами на уровне аккаунта хранилища - а это уже не та учётка, что скомпрометирована вместе с Veeam-сервером.

Отдельная учётка для S3 Object Lock - отдельная от Veeam-сервера, с минимальными правами: s3:PutObject, s3:GetObject, s3:ListBucket. Без s3:DeleteObject. Это означает, что даже полная компрометация Veeam-сервера не даст атакующему возможности удалить объекты из bucket-а.

Стоимость: честная арифметика

Вопрос, который задают первым. Selectel Object Storage - один из дешёвых вариантов на рынке РФ. Хранение за гигабайт в месяц считается в копейках, и для типичного SMB-клиента с 2-5 TB бэкапов итоговая сумма выходит в диапазон нескольких тысяч рублей в месяц. Это не ноль, но сопоставимо с ценой одного часа работы по восстановлению из плохого бэкапа.

Реальные суммы по конкретным клиентам не публикуем - слишком разный профиль данных. Но логика расчёта простая: берёшь объём данных, умножаешь на коэффициент дедупликации и компрессии Veeam (обычно 2-4x для типичной VMware-нагрузки), добавляешь глубину хранения в днях - получаешь объём в S3. Плюс трафик на восстановление, если нужно поднимать данные за пределами Selectel-сети.

Исходящий трафик - единственная статья, которая может неприятно удивить при восстановлении больших объёмов. Это надо считать заранее и учитывать в RTO-планировании.

Процедура верификации: нулевая терпимость к «лежит»

Пункт «0 ошибок» в схеме 3-2-1-1-0 - это не метафора. Veeam v12 умеет делать Sure Backup - автоматическую проверку восстановимости VM в изолированной среде. Мы настраиваем его как обязательный job раз в неделю на выборке критичных VM.

Что проверяем:

• Сам Sure Backup - Veeam поднимает VM из бэкапа в isolated virtual lab, запускает heartbeat-тест и application-тест (ping, VMware Tools, для серверов приложений - порт-тест)
• Проверку целостности S3-объектов - в Selectel это не тривиально, там нет built-in checksum-verify на уровне API на стороне клиента, поэтому мы скриптуем HEAD-запросы к объектам и сверяем ETag с тем, что записал Veeam в базу метаданных
• Lock status - раз в месяц скриптом проверяем, что retention lock на объектах активен и не истёк раньше срока

Результаты Sure Backup уходят в Zabbix - у нас там уже настроен мониторинг Veeam через SNMP и API. Если Sure Backup завершился с ошибкой - алерт на дежурного, не в очередь.

Что оказалось неочевидным при массовом внедрении

Несколько вещей, которые выяснились при прохождении по клиентам:

Bucket с Object Lock нельзя создать постфактум. Object Lock включается только при создании bucket, не на существующий. Это означает, что у клиентов, которые уже использовали Selectel S3 без Lock, нужно создавать новый bucket и переносить данные - или просто начинать с чистого листа с новым retention-окном.

Governance vs Compliance - разговор с клиентом. Технически разница понятна, но клиенту надо объяснять сценарий: «если атакующий получит доступ к вашему аккаунту Selectel» - это не паранойя, а реальный вектор при фишинге. Compliance против этого защищает, Governance - нет. У части клиентов мы перешли на Compliance именно после этого разговора.

Тест восстановления обязателен сразу. После настройки нового S3-репозитория, до того как считать задачу закрытой - полное восстановление тестовой VM. Не Sure Backup, а именно реальное восстановление. Два раза за весну мы нашли проблемы именно на этом шаге: один раз - несовместимость версий Veeam-агента, второй - неправильно настроенные права IAM на S3.

Работа с backup-стратегией у клиентов идёт планомерно - к концу лета планируем закрыть всех. Пока самый частый вопрос от клиентов: «это точно нужно, у нас же уже есть бэкапы?» Да, есть. Вопрос в том, выживут ли они при следующей волне. Если работаете с нами по managed-сопровождению - этот разговор уже в расписании.