Как защитить резервные копии от шифровальщика

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

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

Почему шифровальщики атакуют не только рабочие файлы

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

Это не теоретический сценарий. По данным Positive Technologies, во втором полугодии 2025 года и первом полугодии 2026 года шифровальщики применялись в 29% успешных кибератак на российские организации. Для малого и среднего бизнеса их доля была ещё выше – 39%. В 45% рассмотренных инцидентов компании теряли доступ к данным или резервным копиям. В отдельных атаках злоумышленники находились в инфраструктуре от двух месяцев до года, прежде чем переходили к активному шифрованию.

F6 при разборе атак C77L отдельно отмечала интерес злоумышленников к ресурсам резервного копирования и базам 1С: атакующие останавливали службы баз данных и бэкапа, удаляли теневые копии и только после этого переходили к шифрованию. А опубликованное в ноябре 2026 года исследование Kaspersky ICS CERT показало ещё более широкий сценарий – атакующие смогли скомпрометировать в инфраструктуре разработчика в том числе серверы резервных копий.

Источники: исследование Positive Technologies о вымогателях и вайперах, исследование F6 о C77L, разбор Kaspersky ICS CERT.

Главный принцип: заражённая система не должна управлять историей копий

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

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

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

Конкретная реализация зависит от платформы: это может быть pull-модель, отдельная сервисная учётная запись с минимальными правами, неизменяемое хранение или офлайн-копия. Важен не модный термин, а результат – заражённый узел не должен иметь простой команды «удалить всё».

Правило 3-2-1 остаётся хорошей базой, но его нужно понимать правильно

Классическая схема 3-2-1 означает три экземпляра важных данных, два разных типа хранения и одну копию вне основной площадки. Она снижает зависимость от одного сервера, одного диска и одного провайдера.

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

Такой копией может быть отключаемый носитель, отдельное хранилище с жёстко разделёнными правами или неизменяемый слой, где записанные объекты нельзя удалить до окончания заданного срока. CISA рекомендует хранить резервные копии офлайн или в отделённой среде и регулярно проверять восстановление. NIST в актуализированных материалах 2026 года также выделяет регулярное создание, тестирование и использование копий в упражнениях по восстановлению.

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

Храните несколько поколений, а не только «последний успешный бэкап»

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

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

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

Шифрование копии полезно, но от удаления оно не спасает

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

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

Копировать нужно систему, а не просто папку

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

Особенно это заметно на базах данных. Для PostgreSQL и MySQL нужны корректные дампы или согласованные снимки, а не произвольная копия файлов работающей СУБД. То же относится к запросу «резервное копирование 1С»: файловая база и клиент-серверная 1С с отдельной СУБД требуют разного подхода. Подробный разбор 1С уместен отдельно, но принцип здесь один – заранее перечислить всё, без чего система не запустится после восстановления.

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

Контроль бэкапов важнее зелёной надписи «успешно»

Задание может завершиться без ошибки и при этом сохранить не то, что вы думаете. Например, база перестала попадать в архив после изменения пути, диск заполнился, размер копии внезапно уменьшился в десять раз или задача продолжает создавать пустой файл. Поэтому мониторинг должен отвечать не только на вопрос «команда запустилась?», но и на вопрос «получилась ли свежая и правдоподобная копия?».

Полезно контролировать как минимум:

• время последней успешной копии;
• наличие всех ожидаемых источников;
• резкие изменения размера архива;
• целостность файла или набора объектов;
• свободное место и состояние носителей;
• ошибки ротации и удаления старых поколений;
• доставку уведомлений ответственному человеку.

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

Проверка восстановления – единственный честный экзамен для бэкапа

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

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

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

Как выглядит минимальная устойчивая схема для малого бизнеса

Не каждой компании нужен дорогой кластер или отдельный отдел администраторов. Но даже небольшая инфраструктура может быть устроена без единой точки отказа.

1. Источник. Рабочий сервер, сайт, база данных, 1С или файловое хранилище.
2. Локальная или быстрая копия. Она позволяет не тянуть большой объём через интернет при обычном восстановлении, но находится под отдельными доступами.
3. Независимая внешняя копия. Другой сервер, площадка или хранилище, не управляемое рабочей учётной записью.
4. Изолированное или неизменяемое поколение. Хотя бы один слой, который нельзя штатно переписать из рабочей среды.
5. Мониторинг. Система сообщает о пропуске копии, аномалии размера, нехватке места и других сбоях.
6. Проверка восстановления. По регламенту копия разворачивается в тестовой среде, а результат фиксируется.

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

Проверьте себя за 10 минут

Для первичной проверки не нужно удалять файлы, отключать серверы или экспериментировать на рабочей системе. Достаточно ответить на несколько вопросов вместе с тем, кто отвечает за IT.

• Где физически или логически находятся наши резервные копии?
• Есть ли хотя бы одна копия вне основной площадки или рабочей сети?
• Может ли рабочий сервер своей учётной записью удалить все предыдущие поколения?
• Отдельны ли административные доступы к хранилищу резервных копий?
• Сколько поколений хранится и что произойдёт, если заражение заметят не сегодня?
• Что именно копируется: база, файлы, конфигурация, настройки и всё необходимое для запуска?
• Куда приходит сообщение, если ночной бэкап не создался?
• Когда в последний раз данные реально восстанавливали на отдельном сервере?

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

А если ваши файлы уже зашифрованы?

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

Что в итоге действительно защищает резервные копии

Не отдельный NAS, не слово «облако» и не галочка в панели бэкапа. Работает сочетание нескольких вещей: независимое хранение, ограниченные доступы, несколько поколений, хотя бы один изолированный или неизменяемый слой, мониторинг и проверенное восстановление.

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