Любой грамотный специалист вам подтвердит, что резервное копирование – это важная часть любой IT инфраструктуры. Наличие резервных копий – это не только возможность исправить последствия сбоев различного характера, но и порой последний рубеж обороны в нелегком деле противостояния вирусам-шифровальщикам (так называемым ransomware). На эту тему сломано немало копий, и на просторах Интернета легко найти множество практических советов о том, как можно максимально обезопасить себя от данной напасти. У нас также есть статья на эту тему в контексте использования технологии WORM, некогда считавшейся едва ли не панацеей против любых видов атак. Однако время не стоит на месте, технологии совершенствуются как на стороне злоумышленников, так и на стороне защиты от них. Поэтому представляем вашему вниманию технологию Qseal, призванную обеспечить максимально возможную защиту резервных копий средствами СХД.

Для начала нелишним будет напомнить основные принципы резервного копирования с точки зрения защиты резервных копий от последующего изменения/повреждения. Если рассматривать создание бэкапа средствами специального ПО на стороне хоста, то классическая схема подразумевает “выталкивание” (push) данных на сервер резервного копирования.

Схема хороша своей простотой. Но в случае успешной атаки на исходный сервер, злоумышленник получает контроль над хранилищем резервных копий (хотя бы потому, что потенциальный вирус будет иметь те же права доступа, что сервис резервного копирования). Поэтому сейчас повсеместно используется иная модель, когда ПО резервного копирования забирает/“втягивает” исходные данные с сервера. Такой подход позволяет нивелировать последствия взлома исходного сервера и не допустить контроля над хранилищем резервных копий вследствие такого взлома.

Уже достаточно долгое время акцент в создании бэкапа смещается с самого ПО резервного копирования в сторону СХД. Т.е. весьма популярно стало производить резервное копирование в сотрудничестве ПО с функционалом СХД или даже только средствами самой СХД. Тем более, что сегодня, пожалуй, все производители СХД имеют те или иные возможности для этого. Конечно, остается дискуссионным вопрос о целесообразности переноса нагрузки со стороны достаточно мощных серверов на куда более скромные ресурсы СХД с точки зрения CPU/RAM. Но, без сомнения, стоит отметить, что наличие еще одной резервной копии никогда не будет лишним, каким бы способом она не была сделана.

При создании резервных копий средствами СХД наиболее популярной технологией является репликация на другую физическую СХД с использованием общеизвестных или проприетарных протоколов. И практически всегда такое копирование производится в соответствии с концепцией “выталкивания”, поскольку такой механизм наиболее прост в реализации. Безусловно, получение контроля над резервными копиями в таком случае сильно затратнее и сложнее в реализации по сравнению с атакой на какой-либо сервер. Однако, например, при использовании синхронной репликации повреждение данных на СХД источнике означает также повреждение данных на СХД приемнике.

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

• Создание снапшотов. Недостатки:

  • Высокая зависимость от исходных данных;

  • Возможно случайное/преднамеренное удаление снапшотов.

• Создание immutable снапшотов. Недостатки:

  • Возможны проблемы со сбоем расписания по созданию снапшотов, проблемы с ротацией, пр.

• Использование папок с защитой WORM. Недостатки:

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

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

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

• Сетевая невидимость и плавающий IP во время сеансов передачи данных;

• Использование принципа push для доступа к исходным данным;

• Использование снапшотов для возможности отката на определенную временную отметку.

Для использования Qseal потребуется две СХД Qsan серии XCubeNXT (необязательно одинаковой конфигурации и модели) с FW не ниже 4.2.0. Первоначальная настройка и последующее управление процессом осуществляется через дополнительное ПО Xinsight (бесплатное для рынка РФ), которое устанавливается на любую доступную машину с Windows. Схема подключения максимально проста. Хосты производят ввод/вывод на основную СХД. А резервное копирование осуществляется через выделенные физические интерфейсы на вторую СХД. Важно отметить, что ПО Xinsight не имеет доступа к самим данным. Оно лишь взаимодействует с СХД через порты управления. Если в процессе работы Xinsight станет недоступно по какой-либо причине, это никак не повлияет на уже настроенные задачи резервного копирования, поскольку после настройки всё последующее общение между СХД осуществляется без посредников. Если говорить про физическое и логическое взаимодействие, то оно происходит через порты управления. Поэтому необходимо обеспечить сетевой маршрут между ними.

Сами данные при этом передаются через выделенные порты (можно использовать любые незанятые основным вводом/выводом). Рекомендуется подключать СХД друг с другом в режиме direct attach. Если это невозможно, то упаковать траффик между ними в изолированный VLAN как с целью повышения безопасности, так и из-за технических особенностей реализации канала обмена (поддерживается только плоская сеть без шлюзов и тегирования на портах).

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

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

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

На всякий случай также упомянем технические ограничения в работе Qseal:

• Не более 32 задач на систему;

• Не более 4 активных задач по синхронизации в каждый момент времени;

• Каждая папка на основной СХД может участвовать только в одном задании по резервному копированию.

Подводя итог обзору функционала Qseal, стоит отметить, что “параноики” будут довольны. Ну а если серьезно, то получилось весьма интересное и нетривиальное решение, позволяющее добиться максимальной защиты данных на случай различного рода атак на корпоративные данные. Безусловно, ограничиваться только Qseal в данном вопросе не стоит. Тем более, что в арсенале того же Qsan присутствуют и другие средства, помогающие организовать резервное копирование (заметьте, бесплатные!). А комбинация с прочим ПО резервного копирования позволит достичь еще более впечатляющих результатов. Добавьте к этому наш многолетний опыт в поддержке продукции Qsan, позволяющий застраховаться от любых проблем с оборудованием. В итоге вы получите максимально надежное решение, способное справиться с возложенными на него задачами.