Резервная копия доступна из сети — вымогатель может удалить и её

15 октября 2026 г. в 15:00|Автор: Редакция QUASA|6 мин чтения

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

Для проверки готовности нужны отдельные полномочия на хранение, защищённые инструкции и пробное восстановление чистой системы. Рекомендации NIST требуют изолировать копии от распространения программы-вымогателя и регулярно испытывать стратегию резервирования и восстановления. Успешное завершение задания копирования показывает лишь его штатный статус, но ещё не показывает, удастся ли вернуть работающий сервис после захвата основных учётных записей.

Через что можно потерять копии

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

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

Отдельно проверьте задержку обнаружения атаки. Если данные испорчены до очередного копирования, последние точки тоже могут содержать повреждённое состояние; нужен срок хранения, оставляющий шанс выбрать более раннюю пригодную точку. Это вопрос о возрасте доступных данных, а не только о числе сохранённых копий.

Как разделить полномочия

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

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

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

Когда копия действительно изолирована

Автономный носитель резервной копии отключён от рабочей сети и остаётся доступным для восстановления.

Автономная копия после записи физически отделена от систем, через которые действует атакующий. Для неё важны порядок подключения, место хранения и возможность получить носитель при аварии. Если диск отсоединяют лишь формально, а затем держат постоянно подключённым к тому же серверу, путь для удаления сохраняется.

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

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

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

Что должно сохраниться кроме данных

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

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

Как испытать восстановление

Во время пробной реставрации автономную копию подключают к отдельной чистой системе.

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

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

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