Veeam v11 preview: hardened Linux repository и immutable backup на практике

Veeam несколько недель назад опубликовал roadmap v11 с анонсом двух связанных функций: immutable backup и hardened Linux repository. Смысл - резервные копии, которые нельзя удалить или перезаписать даже с правами root на сервере бэкапов. Актуально на фоне участившихся атак где шифровальщик первым делом идёт за бэкапами. Мы вытащили бета-сборку и потратили пару дней на практические тесты.

Что такое hardened repository технически

Механизм построен на ext4 immutability flag - атрибуте i который выставляется через ioctl с кодом FS_IOC_SETFLAGS. Файл с таким флагом нельзя изменить, переименовать, удалить или перезаписать - даже от root. Снять флаг тоже нельзя раньше времени: Veeam управляет этим через собственного агента, который хранит retention-метаданные и снимает флаг только по истечении срока.

Ничего принципиально нового - chattr +i существует давно. Veeam просто интегрировал это в свой workflow: транспортный агент, который пишет бэкап на Linux-репозиторий, после завершения записи выставляет флаг на файл и прописывает retention period. До истечения периода файл физически нельзя тронуть.

Важный момент: hardened repository работает только с Linux. Windows-репозитории этот режим не поддерживают - там другая архитектура файловой системы.

Как мы это проверили

Поставили бета-агент Veeam на отдельную Ubuntu 20.04 VM, настроили её как hardened repository. Создали тестовый бэкап с retention на 7 дней.

Потом попробовали сломать:

• Прямое удаление файла от root - rm падает с Operation not permitted. lsattr показывает флаг ----i-----------.
• Попытка перезаписи через dd - аналогично.
• chattr -i для снятия флага - тоже отказ, потому что Veeam управляет флагом через своего агента: пока retention не истёк, агент сразу выставляет флаг обратно. Вручную снять его без агента на работающей системе не получается.
• Монтирование в другой системе и попытка удаления - здесь интереснее. Если примонтировать диск к другой машине без Veeam-агента, флаг i на уровне ext4 никуда не девается - он в inode. Удалить файл не получилось и там.

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

Схема 3-2-1 с тремя уровнями

На тестах мы параллельно прорабатывали клиентскую схему бэкапа, которая давно требовала пересмотра. Классический 3-2-1 (3 копии, 2 разных носителя, 1 offsite) - это минимум, но реализации бывают разные по степени изоляции.

flowchart LR
    A[Production\nVMs] --> B[Veeam Backup\nServer]
    B --> C[Level 1\nLocal SOBR\nextent]
    B --> D[Level 2\nHardened\nLinux Repo\next4 immutable]
    D -->|копирование\nраз в сутки| E[Level 3\nOffsite S3\nObject Lock]

Уровень 1 - локальный SOBR (Scale-Out Backup Repository). Быстрое восстановление, тот же датацентр, никакой защиты от ransomware - но это и не его задача. Здесь нужна скорость, retention короткий (3-5 дней).

Уровень 2 - hardened Linux repository в том же датацентре, но изолированная сеть. Это новинка v11. Отдельный Linux-сервер, никаких доменных учётных записей (ещё одно требование hardened mode - сервер не должен быть в AD), Veeam подключается к нему по отдельным credentials только для операций бэкапа. Retention - 14 дней с immutability.

Уровень 3 - offsite в S3 с Object Lock. Сюда копирование идёт раз в сутки через Capacity Tier SOBR или через отдельный Copy Job. Object Lock на стороне S3-провайдера даёт тот же эффект immutability, но уже в объектном хранилище. Retention - 30 дней.

Смысл двух уровней immutable-хранилища в том, что они атакуются через разные векторы. Hardened repo атакуется через сеть (нужно добраться до Linux-сервера и получить на нём root). S3 Object Lock атакуется через API-credentials. Скомпрометировать оба одновременно существенно сложнее.

Что показала бета

Производительность репозитория с immutability на наших тестах не просела заметно - накладные расходы на выставление флага ничтожны относительно времени записи самого бэкапа. Это ожидаемо: ioctl вызов на завершение файла.

Управление retention работает корректно: по истечении срока Veeam снимает флаг своим агентом и удаляет файл в рамках обычной процедуры housekeeping. До истечения - трогать нельзя ничем.

Конфигурирование через UI пока сыровато - несколько раз мастер настройки вёл себя непредсказуемо, пришлось перепройти. Это бета, так что претензий нет, но к GA надо будет перепроверить. CLI-интерфейс стабильнее.

Текущее состояние

Клиентская схема 3-2-1 с hardened repo задокументирована и согласована, ждём GA-релиза v11 для внедрения в managed-сопровождение. Бета показала что механизм работает и флаг реально защищает файлы на уровне файловой системы - не маркетинг. Дата релиза v11 Veeam не объявлял, по косвенным признакам - начало 2021 года, но это наши предположения.

Если у вас сейчас Windows-только репозитории - стоит начать планировать Linux-сервер под hardened repo заранее. Требования там конкретные: ext4, отдельные credentials, вне домена. Поставить сервер за день реально, а вот переосмыслить схему бэкапа требует времени.