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

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

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

Говоря о Ransomware, в первую очередь мы имеем в виду логическую порчу данных и компрометацию учетной записи доменного администратора.

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

Технологии

Базовая гигиена

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

— Следование расширенной стратегии многоуровневого резервного копирования (3-2-1-1), согласно которой для обеспечения надежного хранения данных необходимо иметь:

• три копии данных;

• две копии на разных типах хранилищ (например, два разных дисковых массива, массив и лента или массив и облако);

• одну копию вне основной площадки (к примеру, «бункер» за пределами основного ЦОД);

• одну копию на неизменяемом хранилище, WORM-носителе или в офлайне.

— Хранение резервных копий (РК) не на продуктивных дисковых массивах (устройствах, предоставляющих доступ к продуктивным данным). Бэкапы должны лежать на отдельных устройствах.

— Регулярное и корректное создание РК, без ошибок и согласно установленному расписанию.

— Создание консистентных резервных копий не только на уровне файловой системы, но и на уровне СУБД и приложения. Необходимо копировать не только базу, но и полный ландшафт ИТ-системы.

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

• сеть передачи данных;

• сеть управления;

• сеть хранения данных;

• сеть резервного копирования.

— Изолированное хранение резервных копий (air-gapped backups) в офлайн-средах, которые не имеют постоянного подключения к основной сети, а также использование сменных носителей (ленты, внешние жесткие диски), хранящихся в защищенных местах.

— Регулярное резервное копирование централизованной БД дедупликации и каталога РК и/или сервера управления с его базой данных.

— Настройка встроенной защиты от шифровальщиков.

Защита каталога

Очень важный момент — обеспечение защиты метаданных ПО СРК: БД резервных копий или каталога резервного копирования. Наличие резервной копии метаданных ПО СРК позволит быстро восстановить работоспособность бэкапов и не потерять информацию о том, какая резервная копия на каком носителе находится.

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

Одним из эффективных вариантов защиты каталога может быть следующий сценарий:

РК каталога выполняется на отдельную NFS-шару с сервера в отдельном (изолированном) сегменте, не подключенном к службе каталогов. По расписанию, NFS-шара экспортируется, подключается к мастер-серверу, после сохранения РК отключается и депортируется. Данный сценарий можно реализовать средствами pre- и post-команд в составе любой СРКиВД в связке с планировщиком cron.

Встроенные в ПО СРК механизмы защиты от шифровальщиков

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

Киберпротект Кибер Бэкап

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

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

• Модуль «Оценка уязвимостей» сканирует защищаемые СРКиВД (система резервного копирования и восстановления данных) компьютеры на наличие уязвимостей, проверяет, обновлены ли операционные системы и установленные приложения, а также корректность их работы. Сканирование с оценкой уязвимостей поддерживается только для компьютеров на базе ОС Windows.

Функции доступны с 16-й версии. Кстати, в Acronis CyberBackup присутствуют аналогичные модули.

RuBackup (Группа «Астра»)

• Репликация (экспорт-импорт) выбранных резервных копий по расписанию в другую независимую инсталляцию RuBackup. Благодаря полной независимости второго домена от атакованной инфраструктуры шифровальщику не удастся повредить на нем резервные копии. Фича доступна с версии 2.1.

• Цифровая подпись резервных копий позволяет контролировать целостность и подлинность РК.

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

Вариант 1. СХД с блочным доступом к данным

В качестве одного из средств защиты можно рассмотреть вариант регулярного создания мгновенных снимков (снэпшотов) на продуктивных массивах и репликации снимков на выделенную СХД для резервных копий.

Снэпшот на продуктивной СХД — не сама РК, а удобное средство для оперативного снятия копии (важно: необходимо обеспечить консистентность данных в снимке!) и быстрого восстановления. Но при этом консистентный снэпшот, реплицированный на вторую СХД, предназначенную для хранения резервных копий, будет считаться полноценной резервной копией. Именно ПО СРК отвечает за консистентность данных при создании снэпшотов, а также за их ротацию.

В этом случае нужно понимать, что есть риски бесконтрольного роста объемов, что может сказаться на производительности (зависит от технологии использования — Copy-on-Write или Redirect-on-Write). Это может значительно увеличить стоимость хранения (например, если это отдельная лицензия). Главным преимуществом является возможность восстановления данных за достаточно короткий срок.

Промышленные ПО СРК (Veeam, Commvault) успешно интегрируются с продуктивными дисковыми массивами (например, Huawei, Netapp) для создания снэпшотов, которые в дальнейшем могут использоваться для оперативного или долгосрочного хранения (в качестве первого уровня хранения).

Создавать снэпшоты можно и без ПО СРК, средствами только лишь СХД, благодаря технологии CDP (Continuous Data Protection, «Непрерывная защита данных») у дисковых массивов ведущих производителей (Huawei, Dell, NetApp, Pure). Технология позволяет создавать большое число снэпшотов с заданным промежутком времени (вплоть до минут), обеспечивать их ротацию. Однако в данном случае все снэпшоты будут неконсистентными и их восстановление будет аналогично включению сервера после нештатного отключения питания. У отечественных производителей технологии CDP отсутствуют, но у ряда игроков (Yadro Gen2, Aerodisk Engine, Baum) есть возможность создания снэпшотов через командную строку или с помощью API.

Можно использовать отложенную асинхронную репликацию, отстающую от продуктивных данных, например, на Х часов/дней. Однако эта функция есть не у всех производителей дисковых массивов.

Вариант 2. СХД с файловым доступом к данным

Использование внешних файловых систем с защитой от перезаписи в течение заданного срока (Retention lock) может в значительной мере усложнить жизнь злоумышленникам, особенно в плане их удаления/порчи. Технологии неизменяемого хранилища (immutable storage) защищают данные резервных копий от изменений после их создания.

В данном случае необходима поддержка как со стороны СХД (NetApp SnapLock, Huawei Hyperlock), так и со стороны ПО СРК. В противном случае возможны ошибки в работе ПО СРК, так как управляющие компоненты (мастер-сервер, медиасерверы) не смогут корректно работать с заблокированными от записи файлами резервных копий. Наиболее простой вариант — использовать файловые системы в режиме WORM только для выполнения полных копий.

Вариант 3. Специализированные аплаенсы (дедупликаторы)

В контексте защиты от шифровальщика дедупликаторы в основном являются частным случаем «СХД с файловым доступом к данным».

Варианты наименования решений immutable storage зависят от конкретного вендора, в том числе в виде отдельных аппаратных Purpose-Built Backup Appliance (PBBA) — NetBackup Flex Appliance, StoreOnce, DataDomain, Quantum DXi, Tatlin Backup (функционал в разработке).

Использование проприетарных протоколов взаимодействия ПО СРК с PBBA (DDBoost, Catalyst) в значительной мере усложнит риск компрометации данных РК, так как они не будут явно присутствовать в системе, поскольку используют нестандартные способы взаимодействия ПО СРК и устройств хранения.

Например, в HPE StoreOnce это реализовано за счет StoreOnce Catalyst Store и API. StoreOnce Catalyst Store не использует стандартные команды и инструкции операционной системы для взаимодействия с клиентом или ПО СРК.  Доступ осуществляется через набор команд API, который напрямую интегрирован в медиасервер приложения резервного копирования, и включает в себя клиентскую библиотеку StoreOnce Catalyst (работа в составе плагина). При использовании StoreOnce Catalyst хранящиеся данные недоступны из ОС сервера управления (или медиасервера), а видны только из консоли ПО СРК или веб-интерфейса дедупликатора.

Главное отличие указанных PBBA: они не используют те же методы аутентификации или, что наиболее важно, тот же набор инструкций, что другие технологии файловых шар (CIFS, NFS, SMB), применяющие средства ОС. Устройства хранения, подключенные средствами PBBA, не будут доступны из ОС без применения соответствующих API.

Вариант 4. Ленточные библиотеки с картриджами LTO

Наиболее защищенными от атак шифровальщиков являются ленточные носители. Даже в случае полной потери мастер-сервера СРК, резервные копии на лентах можно будет импортировать — как правило, все ПО СРК умеют это делать. Однако это занимает много времени, поскольку приходится перечитывать каждую ленту. Затрачиваемое время зависит от объема, типа и скорости ленты. Чуть выше мы рекомендовали делать резервную копию каталога ПО СРК — это позволит значительно сократить время восстановления бэкапа, если его вдруг полностью порушили при атаке.

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

Применение WORM-лент целесообразно для резервных копий с фиксированным длительным сроком хранения по требованиям регулятора (3-5-10 лет защиты от намеренного изменения данных силами администраторов), либо в тех случаях, когда доступ к ленточной библиотеке физически ограничен. В остальном — это дорогой способ, так как WORM-ленты не перезаписываются. Возможность однократной записи предотвращает случайное или преднамеренное удаление данных, например, в случае атаки вирусов-шифровальщиков или человеческой ошибки.

WORM-картриджи практически не отличаются от RW-картриджей того же поколения за исключением того, что чип (Linear Tape-Open Cartridge Memory, LTO-CM) идентифицирует его как WORM. Также небольшие изменения касаются серво-треков, необходимых для проверки, что данные на ленте не изменялись. Нижняя часть картриджа обычно бывает серого цвета, он может быть оборудован винтами с защитой от несанкционированного доступа. Приводы, поддерживающие режим WORM, автоматически распознают WORM-картриджи и включают уникальный идентификатор (WORM ID) в каждый набор данных, записываемый на ленту.

Один из альтернативных вариантов — защищать от записи заполненные ленты в библиотеке. В идеале в конце каждого рабочего дня дежурный администратор СРК подходит к библиотеке, переключает на Full-лентах флажок защиты от записи и отщелкивает его на тех лентах, для которых истек Retention. Соблюдение регламента в непредсказуемое время проверяется офицером ИБ или обслуживающей организацией.

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

Вариант 5. СХД с объектным доступом к данным (S3), облачное хранение

Для хранения РК можно использовать S3-хранилища, доступные в нескольких вариантах:

• Публичное облако (Mail.ru, Yandex Cloud и другие);

• On-premise решение (на базе Open Source Ceph, Minio либо в виде проприетарных решений Hitachi Content Platform, NetApp StorageGrid, Tatlin Object и так далее).

ПО СРК должно управлять и обеспечивать поддержку основных функций (методов) S3-протокола. В стандартном S3-протоколе это механизм Object Lock с режимами Compliance mode, Governance mode и Legal Holds. В случае если ПО СРК не поддерживает интеграцию с S3-протоколом, необходимо заранее подготовить и выполнить настройки на уровне бакета, в котором будут размещать данные резервных копий.

1. Governance (наименее жесткий, управляемая блокировка). Пользователь с правами на загрузку объектов может установить блокировку. Пользователь, управляющий Object Storage, может обойти блокировку (удалить или перезаписать версию объекта), изменить срок блокировки или снять ее. Эти действия необходимо явно подтверждать: например, при запросе через REST API, совместимый с Amazon S3, — с помощью заголовка X-Amz-Bypass-Governance-Retention: true.

2. Compliance (наиболее жесткий, строгая блокировка). Пользователь с правами на загрузку объектов может установить блокировку. Пользователь, управляющий Object Storage, может только продлить блокировку. Обойти, сократить или снять блокировку до ее окончания нельзя.

3. Legal hold (бессрочная блокировка). Пользователь с правами на загрузку объектов может установить и снять блокировку. Обойти блокировку нельзя.

Необходимо помнить, что при использовании механизма Object Lock, ПО СРК также не сможет удалять копии, в том числе ротировать их согласно срокам хранения. Поэтому вопрос размещения резервных копий, не подлежащих изменениям, необходимо прорабатывать на этапе проектирования.

On-premise решение потребует дополнительных вложений в его проектирование, внедрение, эксплуатацию, поддержку и может быть не очень надежным вариантом, так как будет являться дополнительной точкой отказа с точки зрения потенциального наличия доступа к узлам кластера, который реализует сам протокол S3 (удаленный доступ, ОС и ФС).

Публичное облако с этой точки зрения выглядит более надежным, так как предоставляет доступ только к устройствам хранения (бакетам) с использованием пары access key/secret key. То есть исключает доступ к серверам, на которых организовано S3-хранилище, стандартными средствами и протоколами. С другой стороны, в зависимости от услуг, которые предоставляют провайдеры, необходимо помнить, что это потребует лишних затрат. Дополнительно могут тарифицироваться:

• организация каналов связи от инфраструктуры заказчика к провайдеру;

• объем, необходимый для хранения РК;

• количество операций ввода-вывода;

• объем исходящего трафика.

Типовая архитектура СРКиВД в enterprise может выглядеть, как на картинке ниже. Хотите так же? Приходите к нам!

Процессы

Все процессы резервного копирования и восстановления данных должны быть описаны в документации на СРК, согласованы с руководством и владельцами информационных систем. Актуализация процессов в документации должна проводиться каждые полгода независимо от масштаба компании. Среди утвержденных документов необходимо иметь:

• Единый регламент резервного копирования и восстановления данных;

• Планы восстановления по каждой информационной системе (включая и саму СРК);

• Регламент обновления системы резервного копирования;

• Регламент работы с отчуждаемыми копиями.

Для обеспечения эффективности все работы должны проводиться через заявки (RFC) с указанием ответственных лиц.

Для подготовки вышеупомянутых документов нужно провести аудит всех информационных систем, обозначить требования к RTO и RPO каждой системы, необходимые для выбора способа защиты данных (СРК может защитить от логической ошибки, но не всегда для больших объемов обеспечит быстродействие при восстановлении), а также определить сроки хранения исходя из внутренних регламентов или рекомендаций регуляторов. Для выбора схемы резервного копирования данных, целесообразности реализации катастрофоустойчивости/кластеризации на уровне приложения, обычно проводится оценка стоимости/критичности недоступности каждой информационной системы (в том числе с помощью BIA).

Тестовые восстановления

Чтобы иметь уверенность, что СРКиВД работает корректно, будет полезно проводить регулярные учения по восстановлению ИС из резервных копий в среде, максимально изолированной от продуктивного контура.

Это помогает понять несколько важных вещей:

1. Сколько времени займет восстановление данных в случае ЧС;

2. Узкие места в самом процессе восстановления данных (дальнейший шаг — их корректировка);

3. Насколько корректно делается резервная копия (например, будет ли восстановленная БД в целостном состоянии);

4. Все ли данные, необходимые для конкретной ИС, зарезервированы и могут быть восстановлены из РК (проверка на полноту РК с точки зрения прикладной ИС);

5. Возможно ли восстановить данные самой СРК (каталог) при используемых способах его резервирования.

Мониторинг

Единая система мониторинга и оповещения — важный инструмент, позволяющий как оперативно реагировать на любые инциденты в ИТ-инфраструктуре, так и проактивно отслеживать состояние самой СРК и ее отдельных компонентов.

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

Как минимум необходимо в полном объеме использовать систему мониторинга, встроенную в ПО СРК, и настроить мониторинг ее аппаратных компонентов (медиасерверы, устройства хранения).

Что может вызывать подозрение?

• Аномально большие объемы инкрементальных/дифференциальных копий;

• Нехарактерная нагрузка на файлы/LUN (например, растет количество последовательных чтений);

• Ручное удаление файлов резервных копий;

• Несанкционированный доступ персонала в СРК.

Персонал

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

Что может помочь?

• Регулярное обучение сотрудников по вопросам кибербезопасности. Еще одна важная тема — распознавание фишинговых атак и других методов распространения вредоносного ПО.

• Согласование ролевой модели для доступа как к ПО СРК, так и к ее составляющим компонентам.

• Назначение ответственных лиц за восстановление данных и/или четко прописанные границы (например, в случае критичных и больших БД требуется участие в восстановлении и администратора СРК, и DBA).

• Регулярные тестовые восстановления данных из резервных копий.

Информационная безопасность СРК

Доступ к ресурсам

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

1. Наиболее уязвимыми для шифровальщиков являются дисковые устройства хранения, доступные ОС как файловые системы, то есть созданные на внутренних дисках сервера; дисках, подключенных с внешних дисковых массивов как блочные устройства или же как сетевые диски, подключенные по файловым протоколам CIFS/NFS. В качестве сети хранения данных (SAN) предпочтительно использовать не Ethernet, а Fibre Channel как менее уязвимую с точки зрения внешних вторжений.

2. Во избежание потери доступа ко всей инфраструктуре (например, при компрометации учетных записей службы каталогов Active Directory) для сегментов управления/РК/СХД рекомендуется использовать локальные УЗ со строгой парольной политикой и регулярными сменами паролей.

3. Важно обеспечивать физическую безопасность к месту расположения аппаратных компонентов СРК (например, за счет СКУД, видеонаблюдения и так далее).

4. Своевременно устанавливать патчи на ОС как в продуктивной инфраструктуре, так и в инфраструктуре СРК. Особенно это касается обновлений, которые закрывают уязвимости нулевого дня.

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

6. Следить за обновлениями безопасности и немедленно реагировать на уязвимости.

7. Использовать брандмауэры для ограничения сетевого трафика между различными сегментами. Трафик резервного копирования не рекомендуется прогонять через брандмауэры по причине влияния на прод и ограниченной производительности межсетевых экранов.

8. Применять минимально необходимый набор портов (по возможности нестандартные) для обеспечения работоспособности СРК в целом и взаимодействия ее отдельных компонентов.

9. Обеспечивать резервное копирование конфигурационных файлов сетевых устройств (FC, Ethernet).

Например, в больших SAN-сетях, построенных на базе FC коммутаторов Brocade и/или Cisco MDS, восстановление зонинга, который обеспечивает взаимодействие медиасерверов и устройств хранения, может быть очень трудозатратным, что увеличит время восстановления. Поскольку зонинг является частью конфигурационного файла, рекомендуется делать его резервную копию после любых изменений, но не реже одного раза в месяц. У вышеуказанных производителей есть встроенный функционал сохранения. У Brocade это команда configupload с возможностью использования протоколов scp, ftp, sftp. У Cisco MDS это команда copy running-config startup-config с возможностью использования протоколов FTP, TFTP, SFTP, и SCP.

10. Реализовать ограничение доступа к административной консоли ПО СРК и ее отдельным компонентам только с выделенного терминального сервера при наличии аппаратного USB-токена.

11. Обеспечивать контроль доступа и аутентификацию за счет ограничения прав доступа к СРК и использование многофакторной аутентификации (MFA).

Выводы

Контур СРКиВД является последним рубежом ИБ в компании, который должен обеспечивать восстановление в случае повреждения основных продуктивных данных. Самый гарантированный способ восстановиться в случае проникновения вируса-шифровальщика — соблюдать правило «3-2-1-1».

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

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

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

Пост подготовлен командой СХД и СРК центра инфраструктурных решений «Инфосистемы Джет»

При участии: Андрея Янкина, директора центра информационной безопасности «Инфосистемы Джет»