Как это работает: детально и с примерами

Ландшафт угроз изменился. Современные операторы Ransomware (шифровальщиков) больше не атакуют «в лоб». Стандартный сценарий атаки включает скрытое присутствие в сети (dwell time), повышение привилегий, горизонтальное перемещение (lateral movement) и — как обязательный этап — уничтожение резервных копий перед началом шифрования.

Вот пара свежих цифр, чтобы показать глубину проблемы. В нынешнем году, по данным аналитиков каждая четвёртая организация (24%) столкнулась с кибер-вымогательством. При этом репозитории бэкапов подвергаются атакам почти всегда (96% случаев) и 2/3 случаев (76%) эти атаки успешны. В ответ все больше организаций пересматривают свои подходы к кибербезопасности — по последним данным 62% компаний уже применяют неизменяемые (immutable) резервные копии, а 82% имеют развернутые планы Disaster Recovery.

Неизменяемость как необходимость

Проблема в том, что традиционная архитектура резервного копирования, где репозитории управляются теми же учетными записями, что и продуктивная среда, стала уязвимой. Если административный доступ скомпрометирован, удаление копий занимает минуты. Ответ индустрии на этот вызов — переход к концепции Zero Trust Data Management, фундаментом которой являются Immutable Backups (неизменяемые копии) и Hardened Repository (усиленный репозиторий).

Неизменяемость резервных копий следует рассматривать не как опцию ПО, а как изолированный слой хранения данных. Технически это реализация принципа WORM (Write Once, Read Many) — технологии, при которой данные записываются в хранилище только один раз и впоследствии доступны только для чтения). Система фиксирует блоки данных на заданный период (Retention Policy). В течение этого срока никакие операции модификации или удаления невозможны на уровне файловой системы или API объектного хранилища. Даже имея root-права или доступ к консоли управления резервным копированием (Veeam Backup & Replication и др.), злоумышленник получит отказ в доступе при попытке удалить файл.

Это обеспечивает защиту как от внешних, так и от внутренних угроз безопасности. В первом случае хакер, даже если получает контроль над доменом и сервером бэкапов, не сможет очистить репозиторий; во второй ситуации — собственный злонамеренный сотрудник с правами администратора не сможет уничтожить данные компании. 

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

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

Но! Важно понимать, что неизменяемость резервных копий минимизирует (почти до нуля), но не полностью исключает риски потери данных. Даже самые современные WORM-решения и hardened-репозитории могут быть уязвимы при незапланированных сбоях оборудования, ошибках микропрограммного обеспечения или некорректном обновлении резервного ПО.

Теоретически возможен и «форсированный обход» при физическом доступе и низкоуровневой манипуляции с системой хранения (например, прямой доступ к блочному устройству, перепрошивка контроллера и т.п.). Но, это почти невероятный сценарий.

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

Техническая реализация защиты

Важно понимать разницу между Immutable Backup и Hardened Repository. Первая технология отвечает за неизменяемость самих данных — это WORM-логика, фиксирующая копии на заданный срок и блокирующая любые операции удаления или модификации. Hardened Repository, в свою очередь, защищает окружение, где эти данные хранятся: минимизирует поверхность атаки, исключает интерактивный доступ, убирает постоянные административные учётные данные и работает как изолированный узел (appliance). Первый слой обеспечивает неприкосновенность резервных копий, второй — делает хранилище недоступным для атакующего. Вместе они закрывают два разных класса угроз.

Если неизменяемость (Immutable) защищает данные, то Hardened Repository — саму платформу хранения. Это специализированная конфигурация, минимизирующая поверхность атаки (attack surface). В архитектуре De Novo мы используем подход, основанный на трех базовых принципах: 

• Изоляция прав доступа. Репозиторий работает на базе Linux с применением Single-use credentials. Учетные данные для доступа к хранилищу используются только в момент развертывания компонентов (Data Mover), после чего не сохраняются в системе резервного копирования.
• Отключение векторов удаленного управления. После развёртывания репозиторий переводится в режим single-purpose appliance: обеспечивается выполнение только сервисных процессов, необходимых для работы Veeam Data Mover, а любые средства удалённого администрирования (включая SSH) отключаются на уровне конфигурации и сетевого стека. Таким образом устраняются интерактивные каналы управления — репозиторий функционирует как изолированный компонент, а не как полноценный Linux-хост, доступный для эксплуатации уязвимостей.
• Immutability Flag. Используются файловые системы с поддержкой WORM-механизмов, в частности XFS с immutable-атрибутами, поверх которых Veeam включает собственный Retention Lock. Эта комбинация работает на двух уровнях — файловая система блокирует изменение объекта, а слой Veeam фиксирует саму retention-политику, не позволяя администратору укоротить срок хранения копий. Даже получив доступ к процессам резервного ПО, злоумышленник столкнётся с отказом уже на уровне ядра и заблокированной политики хранения.

Вот, как это работает на практике:

Сценарий 1: Злоумышленник скомпрометировал сервер управления бэкапами и отправил API-запрос на удаление цепочки резервных копий. Результат: операция отклонена репозиторием. Восстановление начато немедленно.

Сценарий 2: Эксплуатация уязвимости в сервисе мониторинга (RCE). Хакер попал внутрь периметра, но не смог развить атаку на репозиторий, так как сервисы работали в ограниченном окружении, а интерактивный шелл был недоступен.

Ещё один типичный пример — попытка использовать уязвимость в устаревшей версии OpenSSH, установленной по умолчанию в одной из старых инфраструктур. При переходе на hardened-модель такая поверхность атаки исчезла: лишние сервисы были отключены, а доступ оставался только у сервисных процессов, работающих в строго заданном режиме. Даже если бы атака прошла, прав для удаления данных всё равно бы не было.

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

Совет №1

Для максимальной надёжности работы резервного контура рекомендуется внедрять регулярные аудиты и автоматизированную отчётность о состоянии копий, а также интегрировать процессы управления резервным копированием с корпоративными политиками информационной безопасности. Особое внимание нужно уделять процедурам управления учётными данными, автоматизации обновлений ПО резервного копирования, а также детальному документированию изменений в инфраструктуре. Типичная ошибка внедрения — хранение учетных данных (credentials) в скриптах автоматизации или недостаточная изоляция административных сетей, что может свести на нет все усилия по построению защищённого резервного слоя.

Совет №2

Для объективной оценки эффективности резервного контура имеет смысл внедрять определённые KPI — такие как доля успешно восстановленных данных, среднее время восстановления сервисов (RTO), количество выявленных аномалий в ходе тестовых восстановлений (SureBackup) и частота аудитных проверок политик хранения. Также крайне важно обеспечить ролевое взаимодействие между командами кибербезопасности, эксплуатации и бизнеса — чтобы реакция на потенциальные инциденты была максимально быстрой и согласованной.

Интеграция с ПО Veeam: Верификация как часть процесса

Наличие «зеленой галочки» в отчете о создании бэкапа не гарантирует успешного восстановления. Логические сбои файловых систем, «битые» блоки или некорректная работа приложений могут сделать резервную копию бесполезной. Мы интегрируем механизмы автоматической валидации Veeam (SureBackup) в стандартный процесс обслуживания. В частности, проводятся регулярные проверки целостности данных на уровне низкоуровневых блоков хранилища (CRC Check), то есть сканирование блоков на предмет скрытых повреждений (bit rot) или сбоев дисковой подсистемы. Также обязательно и тщательно тестируется процесс восстановления — автоматический запуск виртуальных машин в изолированной «песочнице» с проверкой старта ОС, запуска сетевых интерфейсов, отклика приложений и пр.

Примеры из практики

Функция SureBackup особенно полезна для систем с распределёнными зависимостями — баз данных, сервисов с внешней аутентификацией, приложений, работающих в кластерных топологиях. В одной из инфраструктур резервное копирование завершалось без ошибок, но при поднятии в «песочнице» SQL-сервер не проходил инициализацию из-за некорректной загрузки драйвера после очередного обновления. В продуктиве этот дефект был незаметен благодаря кэшированию и постоянной связности сервисов, но при восстановлении привёл бы к критической задержке. Выполнение SureBackup заранее позволило устранить проблему до инцидента.

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

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

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

Резервный контур как сервис

Опыт показывает, что, если резервный контур управляется так же, как и продуктив, он падает первым. Стратегия De Novo заключается в создании архитектурного разрыва между средой заказчика и системой хранения копий. Мы предлагаем модель, где реализованы три важнейших аспекта защиты:

• Инфраструктурная изоляция: Репозитории находятся вне домена безопасности клиента (Off-site backup). Компрометация Active Directory заказчика никак не влияет на доступность архивов.
• Гарантированная неизменяемость: Политики Immutable настраиваются на стороне провайдера и не могут быть отключены администраторами клиента (защита от человеческого фактора и захвата учетных записей).
• SLA на восстановление: Мы превращаем бэкап из «набора файлов» в управляемый сервис с предсказуемым временем восстановления (RTO).

В условиях современных киберугроз Immutable Backup и Hardened Repository — это фактически тот «гигиенический минимум», который гарантирует, что у бизнеса всегда останется «чистая» копия данных, до которой не дотянется ни один шифровальщик, даже если он получил полные права в вашей основной сети.