Кратко
Резервные копии часто становятся последней точкой восстановления после атаки программы-вымогателя (ransomware). Проблема в том, что современные программы вымогатели все чаще атакуют не только рабочие данные, но и инфраструктуру резервного копирования.
Если злоумышленник получает доступ к серверу резервного копирования или хранилищу, он может удалить точки восстановления, изменить срок хранения или зашифровать доступные копии. В такой ситуации само наличие backup не гарантирует, что данные удастся вернуть.
Именно поэтому компании все чаще внедряют неизменяемые резервные копии. Такой подход помогает защитить резервные копии от удаления, перезаписи и изменения на заранее заданный срок.
Что такое Immutable Backup и как он работает
Immutable Backup — это резервная копия, которую нельзя изменить, перезаписать или удалить в течение заданного периода времени.
После создания такой копии система фиксирует срок защиты. Пока этот срок не закончился, данные остаются в режиме только для чтения. Даже администратор с широкими правами доступа не может просто удалить такую копию обычным действием через консоль управления.
Это важно для защиты от двух типов риска. Первый риск связан с действиями злоумышленника, который получил доступ к инфраструктуре резервного копирования. Второй риск связан с ошибками сотрудников, которые могут случайно удалить нужную точку восстановления или изменить политику хранения.
При этом нужно различать срок хранения резервной копии и срок неизменяемости. Срок хранения отвечает за то, как долго копия должна сохраняться. Период неизменяемости определяет, в течение какого времени ее нельзя изменить или удалить.
Почему обычного резервного копирования может быть недостаточно при ransomware атаке
Классический бэкап (backup) решает задачу создания резервных копий данных. Но этого мало, если атакующий получает доступ к инфраструктуре до запуска шифрования.
Обычно атака программы-вымогателя развивается поэтапно. Сначала злоумышленник закрепляется в среде, затем расширяет права доступа, изучает инфраструктуру и ищет критически важные сервисы. После этого он может перейти к backup системе, найти сервер резервного копирования, учетные записи администраторов и хранилища с точками восстановления.
На этом этапе цель понятна. Если удалить или повредить резервные копии заранее, у компании останется меньше шансов на быстрое восстановление. Поэтому успешное создание резервной копии еще не означает, что путь к восстановлению действительно сохранен.
Неизменяемые резервные копии (Immutable Backups) снижают этот риск. Даже если злоумышленник доберется до части инфраструктуры, защищенные резервные копии сохранятся до окончания срока блокировки.
Хранение резервных копий в Immutable Storage
Чтобы резервная копия была защищена от изменения, нужен не только процесс резервного копирования, но и подходящий тип хранения резервных копий. Именно на этом уровне работает Immutable Storage.
Immutable Storage — это хранилище, в котором для резервных копий действует политика неизменяемости. Она запрещает удаление, изменение или перезапись данных на определенный срок. Такой подход снижает риск изменения или удаления резервных копий при компрометации учетных записей и вредоносных действиях внутри сети.
Object Lock и S3 Object Lock
Object Lock — это механизм защиты данных в объектном хранилище. После записи объекта на него устанавливают срок защиты, в течение которого объект нельзя удалить или изменить.
S3 Object Lock реализует этот подход в S3-совместимых объектных хранилищах и использует модель WORM. Защищенные объекты нельзя перезаписать или удалить до окончания установленного срока.
WORM хранилище
WORM (Write Once, Read Many) — это система защиты данных, которая позволяет записать информацию только один раз, после чего её нельзя изменить или удалить в течение заданного времени.
Такой формат подходит для задач, где компании важно сохранить резервные копии в неизменном состоянии на весь срок хранения. WORM хранилище применяют в системах, где критична защита от изменения данных на уровне самой платформы хранения.
Immutable Backup и обычное резервное копирование: в чем разница
Обычная резервная копия и неизменяемая резервная копия решают похожие задачи, но уровень защиты у них разный.
| Критерий | Обычное резервное копирование | Неизменяемое резервное копирование |
|---|---|---|
| Изменение backup копии | Допускается | Не допускается до окончания срока защиты |
| Удаление точки восстановления | Возможно при наличии прав доступа | Блокируется на период неизменяемости |
| Риск при компрометации инфраструктуры резервного копирования | Выше | Ниже |
| Защита от случайного удаления | Ограниченная | Выше за счет блокировки |
| Восстановление после атаки программы-вымогателя | Зависит от сохранности backup | Есть защищенная точка восстановления |
| Требования к планированию хранения | Стандартные | Нужно заранее определить срок блокировки |
Правило резервного копирования 3-2-1 и его роль в защите данных
Правило резервного копирования 3-2-1 помогает выстроить базовую структуру защиты данных.
три копии данных
две разные среды хранения
одна копия вне основной площадки
Оно предполагает, что у компании должно быть три копии данных, две разные среды хранения и одна копия вне основной площадки. Такой подход снижает риск потери информации из-за отказа оборудования, ошибки администратора или локального инцидента.
Но для защиты от атак программ-вымогателей одного правила 3-2-1 недостаточно. Если удаленная копия доступна для изменения или удаления, злоумышленник может повредить и ее. Поэтому используют расширенную схему 3-2-1-1-0, в которой одна из копий должна быть изолированной или неизменяемой, а восстановление должно проходить без ошибок.
Как проверить, что резервная копия действительно пригодна для восстановления
Даже защищенная резервная копия не дает пользы, если из нее нельзя восстановить систему в нужный срок.
Поэтому стратегия резервного копирования должна включать регулярную проверку созданных копий. В первую очередь нужно тестировать само восстановление. Для критичных сервисов стоит заранее проверять, открываются ли нужные файлы, запускаются ли виртуальные машины и корректно ли работают восстановленные приложения.
Отдельно требуется контролировать доступные точки восстановления. Если атака оставалась незамеченной долгое время, последние копии могут уже содержать зараженные или поврежденные данные. В такой ситуации компании важно понимать, за какой период сохранились корректные резервные копии.
Также стоит проверять соответствие бизнес-требованиям. Для этого сравнивают фактическое восстановление с целевыми RPO и RTO. Если система восстанавливается слишком долго, формальное наличие backup не решает задачу непрерывности бизнеса.
Как выбрать период неизменяемости
Период неизменяемости определяют с учетом требований к восстановлению, глубины хранения и возможного времени обнаружения атаки. Слишком короткий срок может оставить компанию без чистой точки восстановления. Слишком длинный срок приведет к росту объема хранения резервных копий и усложнит управление ресурсами.
Еще один важный момент связан с объемом хранилища. Чем дольше действует правило неизменяемости, тем больше данных накапливается в защищенном от удаления виде. Поэтому при расчете ресурсов нужно учитывать все копии, которые должны сохраняться неизменными.
На практике период неизменяемости подбирают вместе с политикой хранения резервных копий, частотой backup и целями восстановления.
Как ITGLOBAL.COM защищает резервные копии от ransomware
ITGLOBAL.COM использует несколько подходов для защиты резервных копий и данных клиентов от атак программ-вымогателей.
Репликация виртуальных машин с vCloud Availability
Первый сценарий связан с периодической репликацией виртуальных машин в облако. Реплики передаются на удаленную площадку и хранятся отдельно от основной инфраструктуры.
Такой подход помогает сохранить альтернативную копию рабочей среды на случай инцидента в локальном контуре. При этом важно учитывать, что репликация и неизменяемость решают разные задачи. Реплика защищает от потери основной площадки и ускоряет восстановление, а неизменяемость защищает саму backup копию от удаления или изменения.
Облачное резервное копирование с Veeam Cloud Connect и Immutable Backup
Второй сценарий связан с облачным резервным копированием через Veeam Cloud Connect. Резервные копии передаются в удаленное хранилище и могут размещаться в неизменяемом (immutable) репозитории.
В этой схеме Veeam Cloud Connect отвечает за передачу резервных копий на удаленную площадку, а неизменяемый репозиторий — за их защищенное хранение.
Решение подходит компаниям, которым нужна удаленная площадка для хранения резервных копий и управляемый путь к восстановлению после инцидента.
NetApp SnapLock и SnapMirror
Третий сценарий связан с технологиями хранения на базе NetApp. SnapLock помогает зафиксировать данные в неизменном состоянии, а SnapMirror используется для репликации на удаленную площадку.
Здесь защита работает на уровне системы хранения данных. За счет этого компания получает отдельный слой контроля над резервными копиями и может выстроить более устойчивую архитектуру для критичных данных.
Стратегия резервного копирования и защита от программ вымогателей
Рабочая стратегия должна включать несколько слоев. Доступ к контуру резервного копирования ограничивают и защищают многофакторной аутентификацией, а сам контур отделяют от основной инфраструктуры. Его состояние контролируют, восстановление регулярно проверяют, а копии хранят на изолированной площадке.
Отдельное значение имеет организационная часть. До инцидента компания должна определить, какие системы восстанавливаются в первую очередь, кто отвечает за запуск сценария восстановления и как проверяется качество резервных копий. Это сокращает задержки при принятии решений в ходе атаки и делает процесс восстановления управляемым.
Итог
Главный результат такой стратегии можно проверить только в момент восстановления. У компании должны быть данные, которым можно доверять, понятный порядок действий и возможность вернуть критичные системы в работу за приемлемое время.
Поэтому резервное копирование стоит оценивать не по числу созданных копий, а по готовности компании использовать их после реального инцидента. Регулярная проверка восстановления показывает, насколько эта готовность соответствует требованиям бизнеса.
Предыдущая статья
