Средства защиты резервных копий и данных внутри них

Введение

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

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

Далее мы расскажем, как обеспечить комплексную защиту уже созданных резервных копий от удаления, шифрования и компрометации. Рассмотрим реализацию правила хранения «3-2-1», разберем способы логической и физической изоляции хранилищ (включая сегментацию сети), а также уделим внимание неизменяемым (immutable) хранилищам, аппаратным решениям для защиты данных и важности мониторинга событий через журнал аудита или SIEM-системы.

Логическая и физическая изоляция хранилищ

Способы обеспечения логической изоляции хранилищ резервных копий

Логическая изоляция хранилищ данных — важнейший элемент защиты резервных копий от атак (в частности, от вирусов-шифровальщиков). Она достигается комплексом мер, которые можно разделить на сетевые, организационные (учетные записи), модельные (роли) и протокольные решения.

Сетевые и организационные методы изоляции

Хранилища могут быть выведены:

• В отдельный сегмент сети (VLAN) с собственной маршрутизацией и правилами доступа
• В полностью отдельную сеть, физически или логически изолированную от основной инфраструктуры
• С использованием отдельных учетных записей, не включенных в общий домен (например, локальные логины, не связанные со службами каталогов)

Ролевая модель разграничения доступа

Используемая в Кибер Бэкапе ролевая модель позволяет гибко распределять права между сотрудниками. Доступны следующие роли:

• «Полный доступ» — все операции с резервными копиями
• «Только чтение» — просмотр и восстановление без изменения настроек
• «Оператор мониторинга» — наблюдение за процессами без вмешательства
• «Аудит» — просмотр журналов событий и отчетов без доступа к данным

Управление учетными записями: локальные vs централизованные

Система поддерживает интеграцию с:

• Active Directory, Samba, FreeIPA
• Российскими службами каталогов (например, ALD Pro, РЕД АДМ и др.)

Сравнение подходов:

Усиленные механизмы доступа (MFA/2FA)

Применение двухфакторной аутентификации существенно повышает защиту:

• Даже при компрометации пароля злоумышленник не сможет получить доступ

• 2FA затрудняет или полностью останавливает проникновение в систему резервного копирования

• Поддержка 2FA уже действует в Кибер Бэкапе Облачном, а в Кибер Бэкапе появится в одной из следующих версий

Отказ от стандартных протоколов в пользу проприетарных

Использование нестандартных (проприетарных) протоколов передачи данных вместо общеизвестных (SMB, NFS, S3 и т.п.) — дополнительный способ предотвратить атаку на хранилища.

• Пример: протокол BSP (в Кибер Бэкапе) закрывает векторы атак, типичные для SMB/NFS (например, EternalBlue или захват сессии)

Архитектура Zero Trust для крупных компаний

Для организаций со сложной инфраструктурой актуально развертывание системы резервного копирования на принципах нулевого доверия (Zero Trust).

• Ни одна сущность (пользователь, устройство, сервис) внутри периметра не доверяется автоматически

• Каждый запрос к хранилищу проходит строгую проверку независимо от источника

Мы провели совместный с компанией «Мобиус Технологии» вебинар на тему «Как организовать надежное хранение резервных копий». Начало рассказа об архитектуре Zero Trust: на отметке 00:44:37.

Физически изолированное хранение

Существует два основных метода физически изолированного хранения резервных копий: на отдельных дисках/JBOD (Direct-Attached Storage, DAS) и на магнитных лентах (LTO). Сравним оба метода по основным характеристикам.

Когда что выбирать

• Диски — до 10 ТБ, частое восстановление файлов, быстрый монтирование, нет бюджета на приводы
• Ленты — архив от 5 лет, защита от вирусов (air gap + WORM), объемы от 20 ТБ, перевозка копий
• Гибридная схема: диски — последние 3 копии для быстрого восстановления, ленты — исторический архив и изоляция

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

Также в наших планах - сравнение совокупной стоимости владения (TCO) при хранении данных на дисках, лентах и в облаке. Следите за публикациями

Удаленное хранение резервных копий

Самый простой и относительно незатратный способ удаленного хранения резервной копии — разместить ее в облаке. Например, в S3-хранилище практически любого крупного провайдера. На стороне Кибер Бэкапа потребуется использовать компонент BGW (Шлюз резервного копирования), который входит в состав Кибер Инфраструктуры, Кибер Хранилища и Кибер Медиасервера. Резервные копии в S3-хранилище могут быть защищены от изменения и удаления механизмом Object Lock — об этом расскажем ниже. В текущих реалиях следует обратить внимание на ненулевую вероятность отключения интернета. Поэтому резервная копия, хранимая в облаке, не должна быть единственной. 

Репликация и георепликация

В Кибер Бэкапе выполнить правило «3-2-1» для обеспечения надежного хранения резервных копий можно с помощью механизма репликации. Для этого задаются дополнительные хранилища непосредственно в плане защиты, либо вынести операции по созданию реплик резервных копий в отдельный план репликации и назначить агента, который будет выполнять все необходимые действия. Практическую реализацию правила «3-2-1» разбирали на вебинаре «Быстрый старт: как реализовать правило "3-2-1"».

Георепликация хранилища резервных копий, созданного на базе Кибер Хранилища, может быть реализована между двумя географически распределенными ЦОД. Она обеспечивает защиту данных резервных копий от сбоя основного ЦОД. Георепликацию можно включить для хранилищ резервных копий, настроенных на различных серверных частях хранения данных: в локальном кластере хранилища данных, томе NFS или публичном облаке. Если главный кластер окажется недоступным, можно вручную выполнить переключение, повысив подчиненный кластер до главного. При этом конфигурация подчиненного кластера, включая его DNS-имя, поменяется с конфигурацией главного.

Также с помощью георепликации можно  перенести кластер хранилища резервных копий и его данные из одного экземпляра продукта Кибер Хранилище в другой.

Неизменяемые хранилища

Оптические диски

До недавнего времени проверенным и популярным способом хранения данных было использование оптических дисков — CD-ROM. DVD-ROM, Blue-ray и т.п. Потребителей привлекали такие достоинства, как невысокая себестоимость массовой репликации, устойчивость к магнитным полям и приемлемое для своего времени быстродействие. Однако с развитием интернета, облачных сервисов и появлением твердотельных накопителей (SSD) эпоха «болванок» начала стремительно уходить в прошлое, уступив место более емким решениям. Несмотря на этот тренд, даже в наше время оптические носители используются для хранения массивов архивных данных. См., например, про оптические накопители ЭЛАРобот НСМ.

Использование механизма Object Lock в S3-хранилище

При использовании S3-хранилища для размещения резервных копий (подробнее см. «Кибер Хранилище - Храним бэкапы в S3. Практическое руководство») можно включить механизм Object Lock, который предназначен для защиты объектов от случайного или преднамеренного удаления и изменения на заданный период времени. Он реализует две основные модели: срок хранения (retention) — с точным таймером, после которого объект можно удалить, и юридическое удержание (legal hold) — бессрочный запрет на удаление до ручного снятия. Это незаменимый инструмент для создания WORM-хранилищ (Write Once Read Many), где критически важны неизменяемость и сохранность данных после их записи. 

Активировать механизм Object Lock можно только при создании новой корзины, так как после создания корзины изменить этот параметр невозможно. При создании корзины через веб-консоль или API нужно установить соответствующий флаг; дополнительно можно задать режим блокировки по умолчанию (Governance или Compliance) и стандартный срок удержания (в днях или годах). Обратите внимание: включение механизма Object Lock также включает версионирование корзины.

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

Сценарий 1: Резервные копии удалены из интерфейса Кибер Бэкапа

Для этого использовался интерфейс командной строки Кибер Хранилища, либо удаление было сделано напрямую в хранилище S3:

• Восстанавливаем объекты в корзине с помощью специального скрипта
• Импортируем объекты в Кибер Хранилище
• Обновляем содержимое хранилища в Кибер Бэкапе

Сценарий 2: Резервные копии в хранилище повреждены

Текущая версия объектов в объектном хранилище содержит поврежденные данные и не подходит для восстановления:

• Определяем диапазон времени, в течение которого резервные копии были гарантировано неповрежденными
• С помощью скрипта восстанавливаем версии объектов, составляющие исправный архив
• Импортируем объекты, сканируем содержимое хранилища в Кибер Бэкапе

Сценарий 3: Потерян экземпляр Кибер Бэкапа

Также утерян шлюз резервных копий Кибер Хранилища, либо только Кибер Хранилище с настроенным хранением резервных копий во внешнем S3. Доступна только корзина с резервными копиями в объектном хранилище:

• Развертываем новый экземпляр Кибер Хранилища
• При необходимости развертываем новый экземпляр Кибер Бэкапа
• Включаем службу хранилища резервных копий, в качестве хранилища указываем корзину с существующими резервными копиями
• Указываем адрес существующего или нового экземпляра Кибер Бэкапа
• После создания службы импортируем существующие резервные копии
• В Кибер Бэкапе в списке узлов хранения выбираем вновь созданный, нажимаем «Добавить хранилище», ставим галочку «Использовать существующее», выбираем агента для обзора, резервные копии появятся в новом хранилище

Защита хранилища средствами BGW

Уже упомянутый ранее Шлюз резервного копирования может служить средством создания неизменяемого хранилища. Для этого используются моментальные снимки архивов. В текущей версии доступны следущие операции:

• Включение режима неизменяемости (неизменяемость будет включена только для новых резервных копий)
• Определение состояния защиты для всех учетных записей
• Экспорт архива (tibx) в локальную папку
• Экспорт архива (tibx) в локальный BGW
• Экспорт архива (tibx) в удаленный BGW
• Выключение режима неизменяемости

Модуль «Активная защита»

Модуль «Активная защита» встроен в агенты для ОС Windows и Linux и обеспечивает защиту данных от действий вирусов-шифровальщиков. Задача этого модуля — на дать зашифровать файлы и не дать зашифрованным данным проникнуть в резервные копии. Помимо этого, «Активная защита» предотвращает попытки шифрования резервных копий и внесения изменений в компоненты СРК, связанные записи реестра и DLL.

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

В следующей таблице показано, что защищает модуль «Активная защита»

В следующей таблице показаны реакции модуля «Активная защита» при обнаружении угрозы

Аппаратные решения

Решения класса Data Diode

В основе технологий класса Data Diode лежит принцип физической однонаправленности передачи данных, что делает их универсальным решением для сред с максимальными требованиями к кибербезопасности. Защита в таких устройствах реализована на аппаратном уровне: передатчик может только отправлять пакеты, а приемник — только принимать, без какой-либо возможности формирования ответного канала даже на физическом уровне. Это позволяет безусловно защищать критически важные данные от утечки и внешнего вторжения, гарантируя, что злоумышленник не сможет инициировать соединение из периметральной зоны внутрь контура. Таким образом, за счет отказа от двустороннего обмена достигается абсолютная целостность и необратимость потока данных. Примером решения такого класса является InfoDiode — продукт нашего технологического партнера.

Программные и аппаратные моментальные снимки уровня СХД

Многие современные системы хранения данных, например, YADRO TATLIN.BACKUP, поддерживают механизмы создания логических снимков хранимых данных.  Эта технология позволяет защитить данные от удаления, изменения и шифрования. Данные снимки не влияют на производительность, имеют опцию устаревания (защиты от удаления до определенного времени) и опцию защиты от полного удаления. Так TATLIN.BACKUP позволяет гарантировать максимальную надежность хранения. На уровне YADRO TATLIN.BACKUP поддерживается 3 типа моментальных снимков:

• Snapshot Basic — администратор СХД создает моментальный снимок, задает время его жизни, восстанавливает данные, удаляет моментальный снимок
• Snapshot Secure — администратор безопасности создает моментальный снимок, который не может быть никем, кроме него, удален
• Snapshot Locked — данный моментальный снимок никто не может удалить

Возможно создание моментальных снимков вручную, автоматически или через интеграцию с внешним ПО (например, СРК Кибер Бэкап — в настоящий момент интеграция находится в стадии разработки)

Мониторинг событий

Важно отметить, что какой бы подход к обеспечению защиты резервных копий вы не выбрали, необходимо обеспечивать мониторинг всех процессов, происходящих в СРК. Для этого в Кибер Бэкапе существуют встроенные средства — журнал аудита, который содержит сведения о событиях, произошедших в СРК вследствие действий пользователей или работы системных компонентов. Также поддерживается возможность передачи ключевых событий ИБ в SIEM — подробнее см. в статье «Интеграция СРК с корпоративными системами компании: задачи и сценарии реализации».

Заключение

Защита резервных копий давно перестала быть рутинной ИТ-операцией и превратилась в стратегический элемент киберустойчивости любого бизнеса. Как показывают современные инциденты, ни одно изолированное решение не способно гарантировать сохранность данных: только многоуровневая архитектура, объединяющая логическую и физическую изоляцию, неизменяемые хранилища, георепликацию, аппаратные барьеры и непрерывный мониторинг, создает по-настоящему отказоустойчивый контур. СРК Кибер Бэкап позволяет реализовать эту стратегию комплексно: от поведенческого анализа в модуле «Активная защита» и использования проприетарного шлюза BGW до поддержки механизма Object Lock и моментальных снимков уровня СХД, а также передачи событий в корпоративные SIEM-системы.

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